품질, 속도, 자율성 — 셋 다 챙기기!
Quality, Velocity, Autonomy -- Pick Three!
핵심 요약
AI를 활용한 자율적 코딩 워크플로우에서 아키텍처와 품질을 유지하며 개발 속도를 높이는 전략을 공유합니다.
- 아키텍처 중심의 바이브 코딩 — 코드 한 줄마다 신경 쓰기보다 전체적인 아키텍처와 품질을 관리하는 방식이 더 빠름.
- 교차 에이전트 리뷰 — Claude가 Claude를 검토하는 방식에서 벗어나 서로 다른 에이전트 간의 상호 검토를 통해 품질을 확보함.
- 검증 중심의 워크플로우 — 계획 단계부터 검증 단계를 포함하고, AI가 스스로 테스트를 수행하도록 유도함.
- 지식 관리 파일 활용 — LEARNINGS.md와 ARCHITECTURE.md를 통해 시니어 엔지니어의 지혜를 AI가 기억하고 적용하게 함.
">... but doing it properly would have required a deeper fix, so I used the shortcut." [Claude, too often]
지난 분기 동안 저는 직접 코딩할 때보다 더 높은 품질의 코드를 생산하고, 일반적인 '바이브 코딩'보다 더 빠른 속도를 내는 매우 자율적인 AI 워크플로우(1~3시간 실행)를 사용해 왔습니다. 사람들에게 이 방법을 알려주고 싶었어요! 저는 여러분께 팔 만한 플러그인이나 레포지토리는 없습니다. 단지 몇 가지 워크플로우 제안일 뿐입니다.
바이브 코딩에는 두 가지 다른 접근 방식이 있습니다:
- 코드에 대해 알지도 못하고 신경도 쓰지 않는 바이브 코딩: 제품의 최종 동작에만 집중합니다. 즉, 인간으로서의 가치는 "제품적 감각(product taste)"을 가져오는 것입니다.
- 코드 한 줄 한 줄에 신경 쓰지는 않더라도 아키텍처를 잘 알고 코드의 형태를 이해하는 바이브 코딩: 인간으로서의 가치는 "아키텍처적 감각(architecture taste)"과 품질을 가져오는 것입니다.
놀랍게도 저는 두 번째 방식인 "품질 우선 바이브 코딩"이 더 빠르다는 것을 발견했습니다! 적어도 숙련된 엔지니어들에게는 말이죠. 저 자신도 30년 경력의 시니어 엔지니어입니다. 아키텍처와 품질을 유지하는 데는 조금 더 노력이 들지만, 이 작업이 AI가 더 빠르게 움직일 수 있도록 하여 일주일 안에 그 성과를 보상받는다는 것을 알게 되었습니다. OpenAI의 훌륭한 블로그 포스트인 Harness Engineering은 왜 이것이 더 빠른지 잘 보여줍니다:
[아키텍처 감각에 대하여] "이것은 보통 수백 명의 엔지니어가 생길 때까지 미뤄두는 종류의 아키텍처입니다. 코딩 에이전트와 함께라면, 이는 초기 필수 조건입니다. 제약 조건이야말로 품질 저하나 아키텍처 드리프트 없이 속도를 낼 수 있게 해주는 요소입니다."
[AI에 대한 품질 가이드에 대하여] "인간 중심 워크플로우에서는 이런 규칙들이 지나치게 깐깐하거나 제약처럼 느껴질 수 있습니다. 하지만 에이전트와 함께라면, 이 규칙들은 곱셈 효과를 냅니다. 일단 인코딩되면 어디에나 즉시 적용되기 때문입니다."
모든 코드 라인을 읽느라 시간을 낭비하지 않으면서 아키텍처 감각과 코드 품질을 제어하는 가장 좋은 방법은 무엇일까요? 답은 AI가 잡무를 처리하게 하고, 여러분은 중요한 영역에만 집중하는 것입니다:
- 루프 닫기 리뷰(Close-the-loop review). AI가 코드를 검토하고 리뷰 피드백에 잘 대응하는 능력은 애초에 코드나 계획을 작성하는 능력보다 더 중요합니다. AI 리뷰의 첫 3~5라운드에서는 항상 큰 개선이 이루어집니다. 리뷰 반복이 안정화되기 전까지는 저를 개입시킬 이유가 없습니다.
- 교차 에이전트 리뷰(Cross-agent review). 오바마가 스스로에게 메달을 수여하는 밈을 아시나요? Claude가 Claude의 작업을 검토하거나 Codex가 Codex의 작업을 검토할 때 발생하는 '동일 에이전트 편향'이 바로 그것입니다. 그들은 너무 자주 중요한 것을 놓칩니다. 우리는 교차 에이전트 리뷰가 필요합니다.
- 피드백은 선물입니다. 리뷰 단계에서 모든 AI는 리뷰어가 차단 요소를 찾지 못하면 멈추려는 강한 본능을 가지고 있습니다. 저는 대신 리뷰어가 더 이상 개선할 점이 없다고 할 때만 멈추게 했습니다. (이는 리뷰어의 문제 발견 욕구와 오케스트레이터의 완료 욕구 사이의 균형을 맞추고, 어떤 제안이 실제 개선인지 판별하는 미세 조정의 문제였습니다.)


