한 줄 요약

책이 완성됐다! 뭐, 거의 그렇다는 얘기다.

하이라이트

• 책의 22개 챕터를 모두 완성했다.
• AI 덕분에 프로토타이핑이 빨라진 줄 알았는데, 이제는 확신이 서지 않는다.

목표 평가

매달 초에 달성하고 싶은 목표를 정한다. 이번 달에는 목표를 얼마나 달성했을까?

Refactoring English ‘콘텐츠 완성’까지 마치기

• 결과: 모든 챕터를 완성했다.
• 평가: A

6주 동안 계속 ‘일주일만 더 하면 끝나겠지’ 하는 느낌이었는데, 마침내 모든 챕터를 끝내서 다행이다.

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

• 결과: 도구는 약 40% 정도만 완성됐다.
• 평가: C

원래 2~3일이면 끝날 줄 알았는데, 생각보다 훨씬 어려웠다. 특히 거대한 장벽 때문이다.

Refactoring English 지표

으악, 여전히 마케팅을 뒷전으로 미루고 있고 수치는 그 여파를 그대로 보여준다.

마지막 몇 개 챕터를 끝내는 데 필사적이어서 마케팅에는 전혀 투자하지 않고 그것에만 집중했다.

버그 바운티 지표

보안 버그 바운티는 계속하고 있지만 투입하는 시간은 줄였다. 계획했던 70/30 비율까지는 아니지만 대략 60/40 정도다.

주로 협업하던 벤더에서 리포트 대가로 7천 달러를 추가로 지급해 총 1만 7천 달러가 됐다. 다만 리포트 처리가 느려져서 더 이상 그쪽 코드에서 새로운 버그를 찾지는 않고 있다.

다른 프로그램 몇 곳에도 버그를 제보하며 리포트를 빨리 처리하는 곳이 있는지 알아봤지만, 어디도 빠르지 않았다:

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

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

책의 모든 챕터를 완성하긴 했지만 아직 공식적으로 ‘완성’됐다고 생각하지는 않는다.

지난 1년 반 동안 보통 한 번에 한 챕터씩 집중해서 책을 썼다. 한 번도 내 책을 처음부터 끝까지 통독하며 전체적으로 일관성이 있는지 확인한 적이 없다. 진짜 완성이라고 부르기 전에 최소 몇 번은 전체를 정독하고 싶다.

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

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

현실에서는 생각보다 피드백을 훨씬 덜 반영했다.

예전 챕터를 고치는 일과 새 챕터를 쓰는 일 사이에서 집중력을 나누기가 어려웠다. 예전 챕터를 고치는 데 일주일을 쓰면 앞으로 나아가고 있다는 느낌이 들지 않았다. 반면 새 챕터를 하나 추가하면 공개된 진행률 바가 조금 채워져서 동기부여가 됐다.

계속 수정하지 않은 또 다른 이유는 생각만큼 독자들에게 적극적으로 다가가지 못했기 때문이다. 책 진도가 계속 밀려 있다는 느낌이 들어서 늘 ‘이 챕터만 끝내고 나면 독자 소통에 더 투자해야지’라고 생각했다.

그렇다고 독자에게 연락했을 때 책에 큰 영향을 준 것도 아니었다. 독자들에게서 가장 많이 들은 반응은 “책이 마음에 든다”거나 “아직 읽기 시작 안 했다”는 말이었다.

자세한 피드백을 받을 때도 어떻게 반영해야 할지 확신이 서지 않는 경우가 많았다. 피드백에 동의할 때는 결정이 쉬웠다. 하지만 보통은 독자가 굳이 필요 없다고 생각하는 내용을 추가하자고 제안하는 경우가 많았다. 독자가 틀렸다는 뜻은 아니지만, 내 직감과 다른 방향으로 가려면 비슷한 피드백이 반복되는 패턴을 확인하고 싶었고, 그런 패턴을 볼 만큼 충분한 피드백을 받지 못했다.

독자 피드백 도구

이제 모든 챕터를 완성했으니 독자들에게 다가갈 여유가 좀 더 생긴 것 같다.

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

줄리아 에반스가 자신의 제품에 맞춰 직접 독자 피드백 도구를 만든 것을 보고 괜찮다고 생각해서, 나도 비슷한 걸 만들고 있다.

AI 프로젝트와 거대한 장벽

전반적으로 프로그래밍할 때 AI 덕분에 생산성이 올라갔다고 느낀다. git 병합 충돌을 해결하거나 낯선 코드를 디버깅하거나 간단한 도구를 만들 때처럼 AI가 확실히 도움이 되는 작업들이 있다.

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

AI에게 프로토타입을 맡기기

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

그런데 지저분한 프로토타입을 정리하는 게 생각보다 훨씬 어렵다는 걸 알게 됐다. 프로토타입이 충분히 엉망이면 코드가 도대체 뭘 하려는 건지조차 파악하기 어렵다.

AI는 이미 존재하는 코드를 정당화하려는 이상한 편향을 가진 것 같다. 어떤 컴포넌트가 같은 데이터를 세 번이나 순회해서 헷갈린다고 말하면 X, Y, Z 때문에 세 번 순회해야 한다고 계속 우긴다. 그런데 X, Y, Z가 인위적인 제약인지는 절대 의심하지 않는다.

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

핵심 로직을 고치지 않으면 문제는 계속 악화된다. 코드 스멜이 곰팡이처럼 자라 코드베이스 전체로 퍼진다. 취약한 기반 위에 계속 쌓아 올리는 셈이고, AI는 이미 존재하는 나쁜 패턴을 계속 복제한다.

프로토타입을 잘게 쪼개기

좋아, 간단한 해결책이 있다: AI 에이전트가 프로토타입을 더 작은 단위로 만들게 하자. AI가 너무 멀리 벗어나지 못하도록 더 짧은 목줄을 채우는 거다. AI에게 전체 프로토타입을 만들게 하는 대신 환영 페이지부터 시작하자. 그걸 검토하고 병합한 뒤 간단한 기능을 하나씩 추가하는 식이다.

이 방법은 인증 같은 복잡한 덩어리에 도달하기 전까지는 잘 작동한다. AI가 혼란스러운 코드 2~5천 줄짜리 풀 리퀘스트를 만들면 그게 또 하나의 거대한 벽이 된다. 기능을 더 쪼갤 방법이 떠오르지 않아서 이 거대한 PR에 가로막혀 버린다.

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

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

예를 하나 들어보자. Little Moments에서는 매직 로그인 이메일로 인증을 구현하고 있다. 몇 주 동안은 죽은 코드나 망가진 기능을 만들지 않고는 이 기능을 더 쪼갤 방법이 떠오르지 않았다. 로그인 플로우의 절반만 구현할 수는 없지 않은가.

거대한 PR을 조금씩 다듬으며 몇 주를 보낸 뒤에야 사실 로그인 절반도 구현할 수 있다는 걸 깨달았다. 내가 유지보수하는 또 다른 앱인 PicoShare는 단순한 인증 플로우를 쓴다. 단일 승인 사용자만 가정하므로 인증은 아이디/비밀번호 조합조차 아니라 그냥 패스프레이즈 하나다. 인증이 없는 상태에서 이메일 기반 인증으로 한 번에 바꾸는 대신, 인증 없음에서 패스프레이즈 인증으로 가는 중간 단계를 둘 수 있었다.

그래서 패스프레이즈 인증을 먼저 동작하게 했고, 패스프레이즈에서 매직 이메일 로그인으로 넘어가는 과정도 여전히 꽤 큰 PR이라 리뷰하는 데 몇 주가 걸릴 것 같았다. 며칠 더 작업하다 보니 더 잘게 쪼갤 수 있다는 걸 깨달았다.

실제로 로그인 링크가 담긴 이메일을 보내는 대신 원래 보냈을 링크로 사용자를 바로 리다이렉트시키면 됐다. 그래도 1.7천 줄짜리 PR이었지만 실제로 이메일을 보내는 것보다는 관리하기 쉬웠다. 그리고 실제로 이메일을 보내는 부분은 고작 1천 줄로 줄었다.

AI가 이걸 더 어렵게 만드는 이유

AI를 쓰지 않았다면 이런 식으로 문제를 잘게 쪼갤 기회를 분명히 포착했을 텐데, AI 때문에 오히려 더 어렵다는 생각이 들어 AI가 순수하게 도움이 되는지 의문이 든다. 내가 직접 작업한다면 4천 줄짜리 PR을 만들고 “음, 이거 좀 크네”라고 말하는 일은 절대 없을 것이다. PR이 커질수록 다루기가 더 고통스러워지니 자연스럽게 변경을 더 작은 조각으로 나눌 기회를 찾게 된다.

AI는 이런 자연스러운 피드백 루프를 방해한다. AI를 쓰면 4천 줄짜리 PR을 만드는 데 고통이 없다. 이메일을 확인하는 2분 사이에 뚝딱 만들어지니까. 그리고 그 4천 줄짜리 PR에 코멘트를 달아 개선하면서 진전이 있는 것처럼 느낄 수 있지만, 변경이 워낙 커서 어떤 부분을 따로 떼어내 더 작은 변경으로 만들 수 있을지 파악하기가 어렵다.

이제 복잡한 변경에서 얼마나 쉽게 거대하고 관리 불가능한 PR이 생기는지 알게 됐으니, AI를 쓰는 방식을 바꿔 복잡한 기능의 초기 단계에서부터 기능을 더 잘게 쪼개는 데 더 많은 시간을 투자하고 AI의 결과물을 더 엄격하게 검수하려 한다.

마무리

무엇을 해냈나?

• 책의 마지막 챕터들을 출간했다.
• 책 피드백 앱의 부분적인 프로토타입을 만들었다.
• Little Moments에 인증 기능을 부분적으로 구현했다.
• PicoShare의 새 릴리스 두 개를 냈다.

배운 점

• AI를 사용하면 소프트웨어를 더 작은 단위로 만드는 동기를 부여하는 자연스러운 피드백 사이클이 사라진다.
  • 해결책은 복잡한 기능의 생명주기 초반에 더 많은 노력을 들여 더 작은 단위로 쪼개고, AI의 결과물을 더 엄격하게 검수하는 것이라고 생각한다.

다음 달 목표

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