neozest : neo+zest

주말부터 틈틈이 읽은 책 한 권이 있다. 데이비드 토머스(David Thomas)의 《Simplicity》, 국내 번역 제목으로는 《미니멀리즘
프로그래머》다. 《실용주의 프로그래머(The Pragmatic Programmer)》 공동 저자로 잘 알려진 그의 신작이다. 분량은 약 190쪽 정도라 금방 읽을 수 있을 것 같았지만, 막상 읽기 시작하니 책장이 쉽게 넘어가지 않았다. 책의 내용이 어렵기 때문이라기보다는, 문장 하나하나가 개발자로서의 나를 되돌아보게 만들었기 때문이다.

읽는 내내 떠올랐던 책은 역시 저자의 전작 《실용주의 프로그래머》였다. 그 책이 개발자의 태도와 사고방식을 이야기했다면, 이 책은 그 연장선에서 '단순함(Simplicity)'이라는 관점으로 소프트웨어 개발을 다시 바라보게 만든다.

복잡함과 난해함은 다르다

책 초반에 등장하는 문장이 인상 깊었다.

"소프트웨어의 복합(complex)적인 면은 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 복잡함(complicated)이 찾아옵니다."

소프트웨어는 본질적으로 복잡한 시스템이다. 하지만 복잡함 자체가 문제는 아니다. 복잡한 시스템에도 일정한 구조와 규칙이 존재한다. 문제는 그 규칙을 이해하려 하지 않고 임의로 덧붙이고 얽어매기 시작할 때 발생한다. 그 순간 시스템은 '복합적(complex)'인 상태에서 '난해한(complicated)' 상태로 변한다.

개발을 하다 보면 이런 상황을 자주 보게 된다. 원래는 구조적으로 이해할 수 있는 문제였는데, 일정에 쫓기거나 임시방편이 반복되면서 결국 아무도 이해하지 못하는 시스템이 되어버리는 경우다. 책은 그런 상황을 피하기 위한 기본적인 태도를 반복해서 이야기한다.

배움은 시간을 '만들어야' 한다

책에서 또 하나 기억에 남는 문장이 있다.

"어떻게든 시간을 마련해야 합니다. 그렇지 않으면 배우고 개선할 수 없습니다."

누구나 알고 있는 말이다. 하지만 실천하기 가장 어려운 말이기도 하다.
개발자의 일정은 항상 바쁘다. 기능을 만들어야 하고, 버그를 수정해야 하고, 운영 이슈도 대응해야 한다. 그러다 보면 새로운 것을 배우는 일은 항상 뒤로 밀린다. 하지만 저자는 여기서 한 걸음 더 나아간다. 학습은 단순한 지식 축적이 아니라 '피드백 루프'의 일부라고 말한다.

책에서 제시하는 기본적인 흐름은 다음과 같다.

현행 파악 → 실행 → 학습 → 다시 개선

개발에서 흔히 말하는 feedback, retrospective, iteration과 같은 개념들이 자연스럽게 연결된다. 결국 좋은 개발 프로세스라는 것은 거창한 것이 아니라 지속적으로 피드백을 받으며 개선하는 루프를 만드는 일이라는 생각이 들었다.

의존성은 통제권을 넘기는 일

요즘 개발은 외부 모듈과 프레임워크 위에서 이루어지는 경우가 많다. 생산성 면에서는 분명 장점이 크다. 하지만 저자는 의존성에 대해 상당히 조심스러운태도를 보인다.

"의존성을 추가하면 미래의 내가 가져야 할 통제권의 일부를 남에게 넘겨주는 것이나 다름없다."

특히 프레임워크에 대해서는 더 강하게 경계한다.

"프레임워크가 API를 쥐고 있을 뿐만 아니라 애플리케이션 아키텍처를 어떻게 짤지까지 규정해 버리기 때문."

저자의 메시지는 프레임워크를 쓰지 말라는 것이 아니라, 사고의 주도권을 개발자가 가져야 한다는 것에 가깝다.

자동화는 인지적 부담을 줄인다

책에서 반복적으로 등장하는 또 하나의 주제는 인지적 부담(cognitive load)이다. 훌륭한 개발자는 시스템의 인지적 부담을 줄이는 사람이라고 저자는 말한다. 그 방법 중 하나가 자동화다.

반복적인 작업을 자동화하면 개발자는 문제 해결에 더 많은 집중력을 사용할 수 있다. 이 부분을 읽으면서 자연스럽게 떠오른 것이 CLI 기반 자동화였다. 최근 AI Agent 분야에서 "스킬 + CLI" 방식이 주목받는 것도 같은 맥락이라고 생각한다.

팀과 커뮤니케이션도 시스템이다

이 책이 흥미로운 이유는 기술 이야기만 하지 않는다는 점이다. 팀과 커뮤니케이션도 하나의 시스템으로 바라본다.

특히 인상 깊었던 문장은 다음이다.

"다양성은 회복력입니다."

그래서 저자는 팀 리더의 역할을 정보 흐름을 설계하는 사람으로 본다. 회의 방식, 의사결정 구조, 참석자 구성 등도 모두 시스템 설계의 일부다. 이 부분을 읽으면서 "프로그래머"라는 책 제목이 조금 좁게 느껴졌다. 오히려 PO, PM, 팀 리더 같은 역할을 하는 사람들에게 더 도움이 될 수도 있는 책이라는 생각이 들었다.

"할 수 있다"와 "해야 한다"는 다르다

책 후반부에서 특히 공감했던 문장이 있다.

"할 수 있다고 해서 좋은 생각인 것은 아니다."

기술적으로 가능한 것만 강조하는 대화는 개발 현장에서 자주 등장한다. 하지만 엔지니어링의 본질은 가능한 것을 만드는 것이 아니라 문제에 가장 적절한 해답을 찾는 것일지도 모른다.

상태 머신에 대한 공감

책에서 상태 머신(state machine)을 활용하라는 부분도 개인적으로 공감이 컸다. 대부분의 업무 로직은 상태 기반으로 동작한다. 로그인 상태, 주문 상태, 결제 상태, 실행 상태 등 거의 모든 시스템이 상태 변화를 중심으로 움직인다. 그런데도 많은 코드가 이를 명시적으로 표현하지 않는다.

저자의 말처럼 상태를 명확히 모델링하는 것만으로도 시스템은 훨씬 단순해질 수 있다.

결국, 다시 《실용주의 프로그래머》

책을 다 읽고 나니 자연스럽게 떠오른 생각이 하나 있다.

"다시 《실용주의 프로그래머》를 읽어보고 싶다."

이 책은 개발 기술 자체를 가르쳐주는 책이라기보다는 개발자가 어떤 태도와 사고방식을 가져야 하는지를 다시 점검하게 만드는 책이다. 190쪽 남짓한 얇은 책이지만, 읽는 동안 계속해서 스스로에게 질문하게 만든다.

• 지금 내가 만들고 있는 시스템은 정말 단순한가?
• 내가 사용하는 도구와 프레임워크는 문제 해결을 위한 것인가?
• 나는 배우고 개선할 시간을 제대로 만들고 있는가?

* 이 글은 책을 읽으면서 트위터에 남겼던 기록을 기반으로 GPT가 글 초안을 작성했고, 다시 Neo가 다듬어 보았습니다.

팀원들에게 AI 코딩 도구 활용법을 알려주고 싶은데, 마땅한 책이 없었습니다. 프롬프트 작성법을 다룬 책은 많고, AI 동작원리를 설명하는 책도 많은데, 정작 "개발자가 일상 업무에서 어떻게 쓸 것인가"를 다룬 책은 찾기 어려웠습니다. 그러다 발견한 책이 <개발자를 위한 생성형 AI 활용 가이드>(길벗, 핫토리 유우키 저)입니다.

한마디로 요약하면 챗팅 형태의 AI 활용을 고민하는 개발자라면 읽어보는 것이 좋겠습니다. 또한 팀 전체의 AI 코딩 활용을 고민하는 관리자에게도 유용합니다. Neo의 평점은 별 네 개. 일본서 특유의 느낌이 있습니다. 앞에서 읽었던 <바이브코딩 너머 개발자 생존법>은 전체 프로세스를 중심에 놓고 이야기를 풀어가는 반면, <개발자를 위한 생성형AI 활용 가이드>는 지금 당장 써먹을 수 있는 활용방안을 배경지식과 함께 정리해 소개합니다.

이 책의 장점은 개발자 관점에서 코딩 AI를 제대로 활용하기 위해 알아야할 것을 모두 모아두었다는 점입니다. 앞부분에서는 AI가 소프트웨어 개발 프로세스를 어떻게 바꾸고 있는지를 소개하면서 개발과정에서 프롬프트를 작성하는 방법을 자세히 소개합니다. 이 과정에서 단순히 프롬프트 작성만 알려주는 것이 아니라 개발 업무의 특성은 이러한데 생성형 AI는 이렇게 동작하니까 프롬프트를 이렇게 활용해 보세요라는 내용이 많은 것이 마음에 들었습니다.(예: BUD프레임워크를 활용한 코드 최적화. BUD 프레임워크: Bottleneck, Unnecessary, Duplicated )

또한 AI와의 협업을 전제로 코드 구성요소의 역할 변경도 생각해 볼 거리인 것 같습니다. 예를 들어 저자는 AI가 해석할 수 없는 부분이나 토큰을 낭비할 수 있는 부분에 초점을 맞춰 주석을 작성하는 것이 효과적이라고 이야기합니다. 또한 의도 전달에 치우쳐 너무 많은 맥락을 제공하여 혼선이 유발될 수 있으니 적절한 수준을 유지하라는 조언도 도움이 되었습니다. 결국 AI와의 협업을 바탕에 깔고 어떻게 하면 우리의 의도를 잘 전달하여 AI에게 일을 시킬까에 대한 저자의 고민과 나름의 해결방안이 정리되어 있습니다.  

7장과 9장의 내용은 코딩 AI를 팀 개발 프로세스에 어떻게 녹여내고, 그 효과나 성과를 어떻게 측정할 것인지에 대해 고민하는 팀장들에게 몇 가지 키워드를 알려주는 내용이 들어 있습니다.(Four Keys, SPACE 프레임워크등, 짤막하게 소개가 되어 있습니다.) 그리고 어떤 식으로 팀에 도입해야 하는지에 대한 저자의 생각도 살짝 엿들을 수 있습니다.

책 읽으면서 몇가지 밑줄 친 부분은 다음과 같습니다.

프롬프팅 기법에만 집착하면 본질적인 문제 해결 능력이라는 관점을 잃어버릴 수 있습니다.(p.38)

프롬프트를 작성할 때 가장 중요한 것은 AI에 원하는 답을 자신이 이해하고 있어야 한다는 것입니다. 완벽한 답을 알지 못하더라도, 문제해결의 접근 방식을 파악하고, AI의 도움 없이도 해결책을 도출할 수 있는 상태가 이상적입니다.(p.92)

예측할 수 있고 신뢰성이 높은 코드를 생성하려면 개발자는 이러한 언어의 특성을 이해하고 있어야 하며, AI에 적절한 프롬프트를 제공하는 것이 중요합니다.(p.168)

AI에 모든 것을 맡기거나 제대로 활용하지 않고 반복적으로 AI에만 요구하기 보다는 필요한 부분에서는 인간의 판단을 개입시키는 것이 AI를 활용한 코드 개선의 핵심입니다. (p.187)

AI는 아이디어를 발산하는데는 능하지만, 수렴시키는 것은 서툽니다. 수렴에는 의사결정이 따르고, 책임이 수반됩니다. 언제나 최종적으로 책임을 지는 것은 인간입니다.(p.231)

조직의 경쟁력을 높이기 위해서는 '사람에게 의존하는 AI 활용'수준을 넘어서야 합니다. 이러한 문제를 해결하려면 조직 자체의 구조와 방식을 재검토해야 하고, 뛰어난 개인과 팀의 지식을 AI가 제대로 활용할 수 있는 환경을 만드는 것이 경쟁력향상의 핵심입니다. (p.281)