Matt Pocock의 워크플로우를 보고 AI 코딩 방식을 바꿨습니다. 바뀐 점들을 공유합니다.

올해 전까지 내가 주워들은 AI 코딩 조언들은 죄다 프롬프트를 더 잘 짜라는 소리뿐이었어. 시스템 프롬프트 개선, 계획 모드 습관, 더 빡빡한 지시사항 같은 것들 말이야. 근데 정작 내가 계속 겪던 문제인 '세션이 길어질수록 AI가 멍청해지는 현상'은 아무도 안 건드리더라고. 눈치챘을 땐 이미 AI랑 나랑 합의도 안 된 계획으로 코드를 다 짜버린 뒤였지.

그러다 Matt Pocock이 한 강연에서 해결책을 하나 주워들었는데, 지난 몇 주 동안 그 사람 워크플로우를 거의 그대로 따라 해봤거든.

핵심 아이디어는 이거야. 컨텍스트 윈도우는 축구 리그랑 비슷해. 토큰을 추가할 때마다 모든 토큰 사이에 새로운 어텐션 관계가 생기거든. 그래서 광고하는 윈도우 사이즈가 얼마든 간에, 실제로는 10만 토큰 근처만 가도 기술적 한계치에 도달하기 훨씬 전부터 성능이 떡락해.

그 한계치를 알고 나면, 고민의 방향이 '어떻게 프롬프트를 잘 쓸까'에서 '어떻게 세션을 AI가 똑똑한 상태로 유지할까'로 바뀌게 돼.

내 결과물을 완전히 바꿔놓은 건, 코드 짜기 전에 자유 형식으로 계획 짜던 걸 구조화된 인터뷰 방식으로 바꾼 거야. 기능을 설명하고 AI가 바로 계획을 세우게 두는 대신, AI한테 나를 집요하게 인터뷰하라고 시키는 거지. 설계 트리의 모든 가지를 하나씩 질문하면서, 나와 AI가 완전히 같은 이해도에 도달할 때까지 파고드는 거야.

인증 기능을 만들 때 이걸 써봤는데, AI가 내가 생각지도 못한 질문을 던지더라고. "폰이 죽고 복구 코드도 잃어버리면 2단계 인증 복구는 어떻게 할 거냐"는 거였어. 이런 구멍이 나중에 출시 6주 뒤에 CS 티켓으로 터지는 거거든. 운영 환경에서 터지는 것보다 대화하면서 잡는 게 훨씬 싸게 먹히지.

그 인터뷰 내용이 PRD(제품 요구사항 정의서)의 소스가 되는데, 이건 그냥 문서 자체를 최적화하는 게 아니라 목적지 역할을 하는 거야. 일단 합의가 끝나면 그걸 정확하게 요약하는 건 AI가 원래 잘하는 일이니까, 결과물 문서를 한 줄 한 줄 붙잡고 있을 필요가 없어.

더 큰 변화는 PRD를 작업 단위로 쪼개는 방식이야. 그냥 두면 AI는 기본적으로 수평적 분할을 하려고 해. 1단계에 스키마 다 짜고, 2단계에 API 다 만들고, 프론트엔드는 마지막에 붙이는 식이지.

이러면 3단계가 될 때까지 제대로 된 피드백을 하나도 못 받아. 엔드 투 엔드로 돌아가는 게 하나도 없으니까. 수직적 분할, 즉 '트레이서 불릿(tracer bullets)' 방식을 쓰면 첫 번째 작업에서 모든 계층을 관통하는 얇은 경로를 만들어버려. 그럼 바로 클릭하고 테스트할 수 있는 결과물이 나오고, 그다음부터는 이미 작동하는 걸 확인한 시스템 위에서 작업을 쌓아 올리는 거지.

거기서부터는 작업을 번호 매긴 순차적 계획이 아니라, 명확한 차단 관계가 설정된 이슈 큐에 넣는 거야. 그래야 여러 에이전트가 동시에 일을 할 수 있거든.

구현은 테스트 우선으로 진행하고, 코드 리뷰는 코드를 짠 스레드가 아니라 새로 비워진 컨텍스트에서 해. 자기가 방금 짠 코드를 자기가 리뷰하면, 성능이 떨어진 똑같은 컨텍스트 안에서 리뷰하는 꼴이라 의미가 없거든.

확실히 말할 수 있는 건, 몇 주 동안 이렇게 해보니까 예전엔 밥 먹듯이 겪던 '오해를 바탕으로 짠 코드 배포하기' 같은 삽질이 거의 사라졌다는 거야.

너희는 AI가 짚어준 것 중에, 너희가 미처 생각 못 했던 가장 큰 '이해의 간극'이 뭐였어?