Yanz Dev에서 진행하는 빌딩 인 퍼블릭 (building in public)의 첫 번째 에피소드입니다.

Fable 5, Opus 4.8, 또는 Sonnet 5 —
어느 것이 가장 좋을까요? 그리고 저는 매주 똑같이 짜증 나는 답변을 내놓습니다: 그것은 잘못된 질문입니다.

회피하는 것이 아닙니다. 저는 혼자서 만드는 7개의 제품 전반에 걸쳐 대부분의 날에 이 세 가지를 모두 사용합니다. 그리고 올해 제 생산성의 가장 큰 도약은 승자를 선택하는 데서 온 것이 아닙니다. 그것은 모델들이 함께 작동하게 만드는 것, 즉 하나는 생각하고 두 개는 구축하게 만드는 것에서 왔습니다.

"최고의 모델" 함정

"어떤 모델이 가장 좋은가"라는 프레임은 당신이 그중 하나와 결혼할 것이라고 가정합니다. 챔피언을 선택하고, 모든 것을 그것을 통해 실행하면 끝이라는 식이죠.

하지만 이 모델들은 단순히 크기만 세 가지인 동일한 도구가 아닙니다. 그들은 서로 다른 형태를 가지고 있습니다. 하나는 복잡한 문제를 머릿속에 담아두고 계획을 추론하는 데 비현실적일 정도로 뛰어납니다. 다른 모델들은 계획을 받아 작동하고 테스트된 코드로 바꾸는 데 끊임없이 몰두합니다. 어떤 것이 "최고"인지 묻는 것은 화이트보드가 키보드보다 나은지 묻는 것과 같습니다. 무엇에 있어서 최고라는 말입니까?

단 하나의 최고의 모델을 찾는 것을 멈추자, 저는 훨씬 더 많은 일을 해내기 시작했습니다.

실제로 제가 업무를 나누는 방법

제가 정착한 파이프라인은 다음과 같습니다. 거창한 것은 없습니다. 그저 생각하는 것과 타이핑하는 것이 서로 다른 작업이라는 점을 존중할 뿐입니다.

Fable 5가 생각을 담당합니다. 코드 한 줄을 쓰기 전에, 저는 문제(기능, 제약 조건, 해당 기능이 영향을 미치는 코드베이스의 부분들)를 모델에게 전달합니다. 모델의 전체 역할은 추론하는 것입니다. 접근 방식에 대해 스스로 논쟁하고, 트레이드오프 (trade-offs)를 따져보고, 계획을 돌려주는 것입니다. 실제 사양(spec)을 만들어냅니다: 우리가 무엇을 만드는지, 아키텍처 (architecture), 변경될 파일들, 제가 잊어버릴 수 있는 엣지 케이스 (edge cases), 그리고 작업 순서까지 말이죠. 아직 코드는 없습니다. 단지 지도일 뿐입니다.

Opus 4.8과 Sonnet 5가 구축을 담당합니다. 이 모델들은 그 계획을 가져와 실행합니다. 바로 이 지점에서 계획의 가치가 증명됩니다. 저는 모델에게 _"사양서의 3단계"_를 가리키며 지시할 수 있고, 모델은 필요한 모든 것을 갖추게 됩니다. 왜냐하면 사고 과정(thinking)이 이미 완료되었기 때문입니다. 까다롭고 복잡하게 얽힌 부분은 Opus에게 맡기고, 병렬로 빠르게 처리할 수 있는 범위가 명확한 조각들은 Sonnet에게 맡깁니다. 동일한 계획, 두 명의 빌더, 그리고 매 메시지마다 설계를 다시 논쟁할 필요가 없는 구조입니다.

하나의 모델은 추론(reason)하고, 두 개의 모델은 구축(build)합니다. 계획은 그들 사이의 인수인계(handoff) 역할을 합니다.

인수인계가 핵심인 이유

이 방식이 작동하는 이유는 특정 모델이 마법 같아서가 아닙니다. 작성된 계획이 하나의 _계약 (contract)_이기 때문입니다. 사고 과정을 분리하여 글로 적어두면, 빌더들은 추측을 멈춥니다. 그들은 매 요청마다 아키텍처를 새로 설계하는 것이 아니라, 이미 검증을 마친 청사진을 채워 넣는 것입니다.

저는 이 사실을 고생하며 깨달았습니다. 단일 모델에게 계획과 구축을 한 번에 맡기면, 모델은 경로를 이탈합니다. 두 번째 메시지에서는 합리적인 아키텍처 결정을 내리다가도, 아홉 번째 메시지에 이르면 그것을 잊어버리고, 결국 저는 조용히 자기모순을 일으키는 코드를 리뷰하게 됩니다. 단계를 분리하면 누군가 구축을 시작하기 전에 결정 사항이 문서상으로 존재하도록 강제할 수 있습니다. 계획은 제가 리뷰해야 할 대상이 됩니다. 그리고 계획을 리뷰하는 것은 잘못 작성된 코드를 나중에 리뷰하는 것보다 백 배는 더 저렴합니다.

이것은 벤치마크(benchmark)가 아닌 질적인 차이입니다. 수치를 흔들어 보이며 증명하려는 것이 아닙니다. 하지만 체감되는 차이는 실재합니다. 막다른 길에 다다르는 diff가 줄어들고, 불필요한 혼란(thrash)이 감소하며, 더 많은 결과물을 출시(shipping)할 수 있게 됩니다.

여전히 저의 몫으로 남은 부분

이 중 그 어떤 것도 인간을 배제하지 않습니다. 오히려 이 방식은 제가 기여해야 할 지점을 더 날카롭게 다듬어 줍니다.

저는 여전히 무엇을 구축할지, 그리고 어떤 트레이드오프 (trade-offs)를 감수할지를 결정합니다. Fable 5는 저에게 계획을 제공하지만, 그 계획의 품질은 제가 정의한 문제의 품질만큼만 좋습니다. 저는 여전히 모든 diff (차이점)가 머지 (merge)되기 전에 직접 읽습니다. 그리고 새벽 2시에 운영 환경 (production)이 망가졌을 때, 책임을 지는 것은 모델이 아니라 바로 저입니다. 세 개의 모델을 오케스트레이션 (orchestration) 한다고 해서 판단력을 외주 주는 것은 아닙니다. 그것은 단지 제가 두 가지 일을 동시에 하려는 단일 모델을 돌보며 시간을 허비하는 대신, 계획과 리뷰처럼 중요한 곳에 제 판단력을 집중한다는 것을 의미합니다.

그렇다면 어떤 모델이 가장 좋을까요?

잘못된 질문입니다. 이득은 선택에 있는 것이 아니라, 오케스트레이션 (orchestration)에 있습니다.

하나의 모델을 최고라고 치켜세우려 하지 말고, 작업의 형태에 맞는 모델로 라우팅 (routing)하기 시작하세요. 사고 (thinking)에 가장 능숙한 모델에게 사고를 맡기고, 구축 (building)에 가장 능숙한 모델들에게 구축을 맡기십시오. 그 핸드오프 (handoff) — 즉, 다시 설명할 필요 없이 바로 구축에 활용할 수 있을 만큼 충분히 훌륭한 계획 — 가 바로 진짜 레버리지 (leverage)가 숨어 있는 곳입니다.

한 명의 사람, 일곱 개의 제품, 그리고 같은 방향으로 움직이는 세 개의 모델. 이것이 저의 설정입니다. 진행하면서 무엇이 고장 나고 무엇이 잘 작동하는지 계속 공유하겠습니다.

이것은 저의 build-in-public 여정의 에피소드 1입니다. 저는 AI를 사용하여 일곱 개의 제품을 어떻게 구축하는지, 그 승리, 버그, 그리고 실제 과정을 공개적으로 기록하고 있습니다. X, Threads, 또는 YouTube의 Yanz 채널에서 함께해 주세요.