글쓰기와 독서, 추상화 그리고 AI
개발자로서 글을 쓰는 것에 대한 생각, 독서에 대한 생각, 추상화와 AI에 대한 생각을 정리합니다.
저는 다른 개발자의 블로그 글을 읽거나, 기술문서, 개발 책을 보는 것을 좋아합니다. 여러 기술 블로그 글을 보다보면, 문득 이런 생각이 듭니다.
글이 잘 읽힌다는 것은 이해하기 쉽게 글을 작성했다는 것이고, 보통 이런 글은 좋은 글이라고 말할 수 있습니다.
제가 생각하는 좋은 코드의 기준도 이것과 비슷합니다. 코드가 잘 읽힌다는 것은 이해하기 쉽게 코드를 작성한 것이고, 좋은 코드라고 할 수 있습니다.
1. 글쓰기
자신의 생각을 글로 표현한다는 것은 생각보다 쉬운 일이 아닙니다. 어떤 말로 시작하고, 목차는 어떻게 구성하며, 각 목차별 길이는 어떻게 할지, 자신이 적는 내용이 사실인지, 오타는 없는지 등 생각할 것이 정말 많습니다.
이런 것들을 생각하지 않고, 그냥 혼자 보는 일기장처럼 두서없이 적으면 좋을 텐데 왜 이렇게 고민하며 글을 쓰는 것일까요? 다들 알고 계신 것처럼, 다른 사람들이 보는 글이기 때문입니다.
내가 쓴 글이 잘 읽히고, 쉽게 이해되었으면 좋겠다.
개발자들은 코드를 작성할 때도 비슷한 생각을 합니다.
내가 작성한 코드가 잘 읽히고, 쉽게 이해되었으면 좋겠다.
함수를 동작이 예측가능하게 작성하고, 컴포넌트의 인터페이스를 다른 사람이 보았을 때 놀라지 않도록 설계합니다.
코드 리뷰를 할 때도 그 코드를 작성한 의도를 이해하고, 본인의 생각을 글로 표현하고, 서로 생각을 주고 받습니다. 우리는 이미 글쓰기를 하고 있습니다.
이런 생각에 닿으니, 결국 코드를 잘 작성한다는 것과 글을 잘 쓴다는 것은 크게 다르지 않게 느껴졌습니다. 아키텍처를 설계하고, 컴포넌트의 인터페이스를 구성하고, 파일의 길이는 어떻게 할지, 동작의 오류는 없는지. 언어만 다를 뿐, 코드라는 글을 작성할 뿐입니다.
물론, 글만 열심히 쓰고 개발을 소홀히 하자는 것은 아닙니다. 좋은 글을 쓰기 위해 노력하는 것과 좋은 코드를 작성하기 위해 노력하는 것의 본질이 같다는 것을 말해보고 싶었습니다.
2. 독서
개발자들은 일상 속에서 이미 많은 독서를 하고 있습니다. 1번에서 예상할 수 있듯이 코드를 보는 것은 결국 독서를 하는 것과 같습니다.
독서의 범주는 시대에 따라 계속 넓어지고 있습니다. 좁게 정의하면 활자로 된 책을 읽는 행위지만, 넓게 정의하면 문자를 통해 다른 사람의 생각과 지식을 습득하는 모든 행위라고 볼 수 있습니다.
종이책이나 전자책을 보는 것부터 React 공식 문서, 기술 블로그를 보는 행위, 나아가 코드를 읽거나 Github Issue, Code Review를 읽는 것도 독서로 볼 수 있습니다. 요즘 많이들 사용하는 ChatGPT나 Claude와의 대화를 읽는 것도 이 범주에 속할 수 있습니다.
이 지점에서 짚고 넘어가야 할 게 있습니다. LLM과의 대화도 넓은 의미의 독서에 포함될 수 있다고 했지만, 여기엔 함정이 하나 숨어 있습니다.
책을 읽을 때 우리는 저자의 논리를 따라가며 스스로 이해하고, 동의하거나 반박하고, 본인만의 언어로 재구성하는 과정을 거칩니다. 이 과정 자체가 사고입니다.
그런데 LLM과의 대화는 이 과정을 생략하기 쉽게 만듭니다. 질문을 던지고 답을 받아 그대로 수긍하는 순간, 우리는 사고의 과정을 통째로 LLM에 위임하게 됩니다. 과거에 개발자들이 구글링을 통해 Ctrl+C+V만으로 코드를 작성하는 것과 별반 다르지 않습니다.
이런 과정이 반복될 수록 ‘인지 부채’는 쌓여가고, 부채가 쌓이면 쌓일수록, 코드를 직접 읽고, 이해하고, 정리하는 능력이 약해집니다. 우리는 정보를 이해를 바탕으로 학습할 때 더 오래 기억할 수 있고, 편하게 얻은 정보는 빠르게 사라집니다.
그럼 어떻게 해결할 수 있을까요?
답은 단순합니다. LLM에게 사고의 결과만 받지 말고, 그 결과를 다시 읽는 쪽으로 습관을 옮기는 것입니다.
답이 왜 그렇게 나왔는지 되묻고, 코드를 한 줄씩 따라가며, 내 말로 다시 정리해 보는 일. 결국 LLM을 쓰는 시대에도 남는 일은 읽기입니다. 다만 그 읽기는 답을 소비하는 읽기가 아니라, 앞에서 말한 사고의 과정을 스스로 되살리는 읽기여야 합니다.
글을 잘 읽는 힘이 코드를 읽는 힘이 되고, 코드를 읽는 힘이 LLM이 만든 결과를 검토하는 힘이 됩니다. 인지 부채를 막는 방법은 멀리 있지 않습니다. 이미 하고 있는 독서를, 조금 더 의도적으로 하는 것뿐입니다.
3. 추상화 & AI
개발자들에게 추상화는 뗄래야 뗄 수 없는 단어입니다. 사람마다 정의는 다르지만, 본질은 같습니다. 세부적인 것(HOW)은 숨기고, 꼭 필요한 정보(WHAT)만 남기는 일.
제가 생각하는 개발자는 단순히 코드를 작성하는 사람이 아닙니다. 복잡한 문제를 컴퓨팅 사고로 단순하게 풀어가는 사람입니다. 한 줄로 말하면, 개발자는 추상화하는 사람입니다.
새 AI 모델이 나올 때마다 “개발자는 이제 필요 없는 것 아닌가”라는 말이 돕니다. ‘코드를 작성하는 개발자’라면 그럴 수도 있습니다. 하지만 ‘복잡한 문제를 단순하게 풀어가는 개발자’는 사라지지 않습니다.
AI는 HOW를 빠르게 채워줄 수 있습니다. 무엇을 숨기고 무엇을 드러낼지, 어디에 경계를 그을지 정하는 WHAT의 문제는 여전히 사람의 몫입니다. 맥락을 읽고 추상화의 경계를 고민하는 일. 그게 AI 시대에도 개발자에게 남는 일입니다.