한 줄 요약

책을 다 썼습니다! 뭐, 거의 그렇다고 해두죠.

하이라이트

• 책의 전체 22개 챕터를 모두 완성했습니다.
• AI가 프로토타이핑을 더 빠르게 만든다고 생각했는데, 이제는 확신이 서지 않습니다.

목표 평가

매달 초에 이달에 이루고 싶은 목표를 정합니다. 이번 달 결과는 다음과 같습니다.

Refactoring English 콘텐츠 완성하기

• 결과: 모든 챕터를 완성했습니다.
• 점수: A

6주 동안 계속 ‘일주일만 더 하면 끝나겠다’는 느낌이었는데, 드디어 모든 챕터를 끝내서 정말 다행입니다.

Refactoring English 독자가 책을 읽으며 피드백을 남길 수 있는 도구 만들기

• 결과: 도구는 약 40% 정도 완성되었습니다.
• 점수: C

원래 2~3일이면 끝날 작업이라고 생각했는데, 생각보다 훨씬 어려웠습니다. 특히 거대한 장벽 때문이 컸습니다.

Refactoring English 지표

헉, 계속 마케팅을 소홀히 했더니 수치가 그대로 드러나네요.

마지막 몇 개 챕터를 어떻게든 끝내야 한다는 생각에 마케팅에는 전혀 투자하지 않고 집필에만 집중했습니다.

버그 바운티 지표

보안 버그 바운티도 계속하고 있지만 투입 시간을 줄였습니다. 원래 계획했던 70대 30 비중은 아니고, 대략 60대 40 정도입니다.

주로 함께 작업하던 벤더에서 보고서에 대해 7,000달러를 추가로 지급해 총 17,000달러가 되었습니다. 다만 해당 벤더의 보고서 처리 속도가 느려져서 이제는 그쪽 코드에서 새로운 버그를 찾는 일을 거의 중단했습니다.

다른 프로그램 몇 곳에도 버그를 제보해 보고서 처리가 빠른지 확인해 봤지만, 어디도 빠르지 않았습니다.

• KeePassXC - 5월 18일에 Zero Day Initiative를 통해 RCE 취약점을 제보했지만 아직 답변이 없습니다.
  • KeePassXC 사용자분들께 참고로, 이번 취약점은 제로 클릭 공격이 아니며 악성 웹사이트에 방문하는 것만으로 데이터베이스가 탈취되는 유형이 아니니 너무 걱정하지 않으셔도 됩니다.
• Cloudflare - 5월 22일에 HackerOne을 통해 DoS / 로직 우회 취약점을 제보했습니다. 답변이 없습니다.
• Proton - 심각도가 낮은 이슈 하나를 제보했습니다. 개념 증명 영상을 요청해서 5월 29일에 만들어 보냈고, 답변을 기다리라는 회신을 받았습니다.

책은 언제 ‘완성’되는 걸까?

책의 모든 챕터를 완성하니 한시름 놓이긴 하지만, 아직 공식적으로 ‘완성’됐다고 생각하지는 않습니다.

지난 1년 반 동안 보통 한 번에 한 챕터씩 집중해서 썼습니다. 아직 제 책을 처음부터 끝까지 통독하며 전체 일관성을 점검한 적이 없습니다. 진짜 완성이라고 부르기 전에 최소 몇 번은 전체를 정독하고 싶습니다.

왜 책을 계속 고쳐 쓰지 않았을까?

원래는 독자 피드백을 바탕으로 책을 계속 수정할 계획이었습니다. 그렇게 하면 마지막 챕터에 도달했을 때 나머지 부분은 이미 독자 의견으로 수없이 다듬어졌으니 책이 거의 완성된 상태일 거라고 생각했습니다.

실제로는 생각했던 것보다 피드백을 훨씬 덜 반영했습니다.

과거 챕터를 고치는 일과 새로운 챕터를 쓰는 일을 병행하기가 어려웠습니다. 일주일을 들여 예전 챕터를 고쳐도 앞으로 나아가는 느낌이 들지 않았습니다. 반면 새 챕터를 하나 추가하면 공개된 진행률 바가 조금 더 차오르니 동기 부여가 됐습니다.

지속적으로 수정하지 않은 또 다른 이유는 계획만큼 독자에게 적극적으로 다가가지 않았기 때문입니다. 늘 책 진행이 뒤처져 있다는 느낌이 있어서 ‘이번 챕터만 끝내고 나면 독자 소통에 더 투자해야지’라는 생각이 계속 들었습니다.

하지만 독자에게 연락을 해도 책에 반영되는 경우는 거의 없었습니다. 가장 흔한 반응은 ‘책이 마음에 든다’거나 ‘아직 읽기 시작하지 않았다’는 것이었습니다.

자세한 피드백을 받을 때도 어떻게 반영해야 할지 확신이 서지 않는 경우가 많았습니다. 피드백에 동의하면 결정이 쉬웠지만, 보통은 제가 꼭 필요하지 않다고 생각하는 내용을 추가하자는 제안이었습니다. 독자가 틀렸다는 뜻은 아니지만, 제 직감과 다른 방향으로 가려면 여러 독자에게서 비슷한 패턴이 보여야 하는데, 그러기엔 피드백 자체가 충분히 모이지 않았습니다.

내 독자 피드백 도구

이제 모든 챕터를 끝냈으니 독자에게 다가갈 여유가 좀 생긴 것 같습니다.

전자책 안에서 바로 피드백을 남길 수 있는 웹 앱인 Help this Book의 아이디어는 마음에 들었지만, 모든 피드백을 외부 서비스에 저장하고 매달 비용을 내고 싶지는 않았습니다.

Julia Evans가 자신의 제품에 맞춰 직접 독자 피드백 도구를 만든 것을 보고 괜찮다고 생각해서, 저도 비슷한 도구를 만들고 있습니다.

AI 프로젝트와 거대한 장벽

전반적으로 프로그래밍할 때 AI 덕분에 생산성이 높아졌다고 느낍니다. git 병합 충돌을 해결하거나 낯선 코드를 디버깅하거나 간단한 도구를 만드는 같은 작업에서는 AI가 확실히 도움이 됩니다.

예전에는 AI가 프로젝트를 시작하는 데 큰 도움이 된다고 생각했지만, 이제는 확신이 서지 않습니다. 제가 ‘거대한 장벽’이라고 부르는 문제에 계속 부딪히고 있기 때문입니다.

그냥 AI에게 프로토타입을 만들게 하기

6개월 전만 해도 AI 에이전트에게 원하는 내용을 개괄적으로 설명하고 기본적인 v1을 구현하라고 했습니다. 결과물이 지저분할 거라는 건 알았지만 어차피 프로토타입이니까, 제 코딩 감각에 맞을 때까지 계속 피드백을 주면 된다고 생각했습니다.

막상 보니 엉망인 프로토타입을 정리하는 일이 생각보다 훨씬 어려웠습니다. 프로토타입이 어느 정도 이상 엉망이 되면, 코드가 도대체 무엇을 하려는 건지 파악하는 것조차 힘들어집니다.

AI는 이미 존재하는 코드를 정당화하려는 이상한 편향이 있는 것 같습니다. 같은 데이터를 세 번 반복해서 훑으니 헷갈린다고 말하면, AI는 X, Y, Z 때문에 세 번 훑어야 한다고 계속 주장합니다. 정작 X, Y, Z가 인위적인 제약인지는 전혀 의심하지 않습니다.

이게 바로 장벽입니다. AI가 쌓아 올린 혼란스러운 코드라는 거대한 벽을 넘어서려다 막혀 버립니다.

핵심 로직을 고치지 않으면 문제는 계속 악화됩니다. 코드 스멜이 곰팡이처럼 번져 코드베이스 전체로 퍼집니다. 약한 기초 위에 계속 쌓아 올리는 셈이고, AI는 이미 존재하는 나쁜 패턴을 계속 복제할 뿐입니다.

프로토타입을 쪼개기

좋습니다, 간단한 해결책이 있습니다. AI 에이전트가 프로토타입을 더 작은 단위로 만들게 하는 것입니다. AI를 더 짧은 줄에 묶어 너무 깊이 빠지지 못하게 하는 거죠. AI에게 전체 프로토타입을 한 번에 만들게 하는 대신, 환영 페이지부터 시작하게 합니다. 그게 검토되고 병합되면 단순한 기능 하나를 추가하는 식으로 진행합니다.

이 방법은 인증 같은 복잡한 덩어리에 도달할 때까지는 잘 작동합니다. AI가 2천~5천 줄짜리 혼란스러운 코드로 풀 리퀘스트를 만들어 내면, 그게 또 하나의 거대한 벽이 됩니다. 기능을 더 쪼갤 방법을 떠올릴 수 없어서, 이 거대한 PR에 또 막혀 버립니다.

4천 줄짜리 변경은 400줄짜리 변경보다 검토에 20배나 오래 걸릴 뿐 아니라, 더 긴 검토 시간을 필요로 합니다. 20분 정도 시간이 있으면 400줄 변경은 처리할 수 있지만, 4천 줄 변경은 맥락을 파악하는 데만 20분이 필요합니다. 맥락 파악에 시간을 허비하지 않고 4천 줄 변경에서 의미 있는 진전을 만들려면 90분 정도의 연속된 시간이 필요한데, 특히 주말 프로젝트에서는 그런 시간을 확보하기가 어렵습니다.

예시: Little Moments에 인증 기능 구현하기

예를 들어 보겠습니다. Little Moments에서는 매직 로그인 이메일 방식으로 인증을 구현하고 있습니다. 몇 주 동안은 죽은 코드나 깨진 기능을 만들지 않고 이 기능을 쪼갤 방법을 전혀 떠올릴 수 없었습니다. 로그인 흐름의 절반만 구현할 수는 없다고 생각했습니다.

거대한 PR을 몇 주 동안 조금씩 깎아내다가, 사실 로그인 절반도 구현할 수 있다는 걸 깨달았습니다. 제가 유지보수하는 다른 앱인 PicoShare는 인증 흐름이 아주 단순합니다. 단일 인증 사용자만 가정하기 때문에 인증은 아이디/비밀번호 조합이 아니라 패스프레이즈 하나뿐입니다. 인증 없음 상태에서 이메일 기반 인증으로 한 번에 크게 전환하는 대신, 인증 없음에서 패스프레이즈 인증으로 먼저 갈 수 있었습니다.

그래서 패스프레이즈 인증을 먼저 동작하게 만들었습니다. 하지만 패스프레이즈에서 매직 이메일 로그인으로 넘어가는 것도 여전히 검토에만 몇 주가 걸릴 만큼 거대한 PR이었습니다. 며칠 동안 붙잡고 있다가, 이것도 더 쪼갤 수 있다는 걸 깨달았습니다.

실제로 로그인 링크가 담긴 이메일을 보내는 대신, 원래 보냈을 링크로 사용자를 즉시 리다이렉트하면 됐습니다. 그래도 1,700줄짜리 PR이었지만, 실제로 이메일을 발송하는 것보다는 훨씬 관리하기 쉬웠습니다. 그리고 실제로 이메일을 보내는 부분은 1,000줄 정도로 줄일 수 있었습니다.

AI가 이 과정을 더 어렵게 만드는 이유

이런 유형의 작업에서 AI가 과연 도움이 되는지 의문이 드는 이유는, AI를 쓰지 않았다면 이런 쪼갤 기회를 제가 분명히 발견했을 거라는 걸 알기 때문입니다. 저는 4천 줄짜리 PR을 만들어 놓고 ‘음, 좀 크네’라고 말하는 일을 절대 하지 않습니다. PR이 커질수록 다루기가 더 고통스러워지기 때문에, 자연스럽게 변경을 더 작은 조각으로 나눌 기회를 찾게 됩니다.

AI는 이런 자연스러운 피드백 루프를 방해합니다. AI를 쓰면 4천 줄짜리 PR을 만드는 데 고통이 없습니다. 제가 이메일을 확인하는 2분 사이에 뚝딱 만들어지니까요. 그리고 그 거대한 PR에 대해 개선 의견을 쉽게 덧붙이며 진전이 있는 것처럼 느낄 수 있지만, 정작 변경이 너무 커서 어떤 부분을 따로 떼어내 더 작게 만들 수 있는지 파악하기가 어렵습니다.

복잡한 변경에서 이렇게 거대하고 감당하기 어려운 PR이 얼마나 쉽게 생성되는지 알게 된 만큼, 이제는 AI 활용 방식을 바꿔 기능 개발 초기부터 더 잘게 쪼개는 데 투자를 더 하려고 합니다.

마무리

무엇을 했나?

• 책의 마지막 챕터들을 공개했습니다.
• 책 피드백 앱의 부분 프로토타입을 만들었습니다.
• Little Moments의 인증 기능을 부분적으로 구현했습니다.
• PicoShare 신규 릴리스 두 개를 배포했습니다.

배운 점

• AI를 사용하면 소프트웨어를 더 작은 단위로 만들도록 동기 부여하는 자연스러운 피드백 사이클이 사라집니다.
  • 해결책은 복잡한 기능의 초기 단계에서 더 열심히 쪼개고, AI의 결과물을 더 엄격하게 검토하는 것이라고 생각합니다.

다음 달 목표

• Refactoring English 웹사이트 개선에 최소 5시간 투자하기.
• Refactoring English 웹사이트에 순 방문자 3만 명 유치하기.
• 독자 피드백 도구 완성하기.