AI 코딩 워크플로우 완벽 정리: 스마트 존, 그릴링, 칸반, 수직 슬라이스, TDD

핵심 메시지

• AI는 새로운 패러다임이지만, 사람과 일할 때 쓰던 소프트웨어 공학의 기본기가 AI와 일할 때도 그대로 잘 통한다.
• LLM에는 컨텍스트가 적을 때 똑똑하게 작동하는 '스마트 존'과, 토큰이 약 10만을 넘어가며 점점 멍청해지는 '덤 존'이 있다. 작업을 스마트 존 안에 맞춰 쪼개야 한다.
• 구현에 들어가기 전 '그릴링(grill me)'으로 AI에게 끈질기게 질문받아 같은 이해(설계 개념)에 도달하는 정렬 단계가 가장 중요하며, 이 단계는 반드시 사람이 개입해야 한다.
• 계획은 PRD(목적지 문서)와 독립적으로 집어 갈 수 있는 이슈들의 칸반 보드로 만들어, 여러 에이전트가 병렬로 일하게 한다.
• 수직 슬라이스로 일감을 나누고 TDD와 피드백 루프를 갖추면, 구현은 사람이 자리를 비운(AFK) 상태에서도 진행할 수 있다.

쉽게 이해하기

발표의 핵심 주장은 'AI는 많은 것을 바꾸지만, 인간과 협업하기 위해 쌓아 온 소프트웨어 공학의 기본기는 AI와의 협업에서도 똑같이 강력하게 작동한다'는 것이다. 그래서 새로운 도구에 휩쓸리기보다 검증된 원칙을 AI에 적용하는 방식을 권한다.

출발점은 LLM의 두 가지 제약을 이해하는 것이다. 첫째, LLM에는 '스마트 존'과 '덤 존'이 있다. 대화 초기에는 어텐션 관계가 가장 단순해 최고의 결과를 내지만, 토큰을 더할 때마다 관계가 제곱으로 늘어나 약 10만 토큰을 넘어서면 점점 멍청한 결정을 내린다. 따라서 AI가 감당할 수 있을 만큼 작은 작업으로 쪼개야 한다. 둘째, LLM은 영화 '메멘토'의 주인공처럼 매번 기억을 잃고 초기 상태로 되돌아간다. 발표자는 대화 기록을 압축(compact)하기보다 아예 비우는(clear) 방식을 선호하는데, 압축으로 쌓인 기록이 오히려 판단을 흐린다고 보기 때문이다.

구현 전 가장 중요한 단계는 '그릴링'이다. 작은 스킬 하나로 AI가 사용자를 끈질기게 인터뷰하게 만들어, 계획서가 아니라 '같은 파장(설계 개념)'에 도달하는 것을 목표로 한다. 이는 명세를 코드로 곧장 변환하고 코드는 들여다보지 않는 '스펙 투 코드' 방식에 대한 반론이기도 하다. 발표자는 코드야말로 우리가 통제해야 할 전장이라고 강조한다. 정렬이 끝나면 그 대화를 요약해 PRD(목적지 문서)를 만든다.

다음으로 PRD를 독립적으로 집어 갈 수 있는 이슈들의 칸반 보드로 쪼갠다. 이때 AI가 좋아하는 수평 분할(계층별로 DB→API→프론트 순서)을 피하고, 모든 계층을 가로지르는 얇은 '수직 슬라이스(추적 탄환)'로 나눠야 한다. 그래야 첫 단계부터 전체 흐름에 대한 피드백을 얻을 수 있다. 블로킹 관계가 있는 이슈들은 방향성 비순환 그래프 형태가 되어 여러 에이전트의 병렬 작업을 가능하게 한다.

구현 단계는 사람이 자리를 비운 'AFK' 작업으로 돌릴 수 있다. 이슈들을 모아 프롬프트와 함께 Claude에 넘기는 'Ralph 루프'를 Docker 샌드박스 안에서 돌리고, TDD(레드-그린-리팩터)로 실패하는 테스트를 먼저 작성하게 한다. 발표자는 피드백 루프의 품질이 곧 AI 코드 품질의 상한이라고 말한다. 검수(QA)는 사람의 취향을 코드에 다시 새겨 넣어 '슬롭(저품질 양산물)'을 막는 단계이며, 검수 과정에서 새 이슈가 다시 칸반 보드로 쌓인다.

주요 인사이트

• 약 10만 토큰을 스마트 존의 경계로 보고, 현재 토큰 사용량을 항상 확인하며 작업 크기를 그 안에 맞추는 것이 실전의 핵심이다. 100만 토큰 컨텍스트는 검색에는 좋지만 코딩에는 '덤 존을 더 많이 받은 것'에 가깝다.
• 서브 에이전트는 격리된 컨텍스트에서 탐색을 대신하고 요약만 올려보내므로, 메인 컨텍스트를 아끼면서 무거운 탐색을 위임하는 수단이 된다(예: 서브 에이전트가 9만 토큰을 써도 메인 사용량은 거의 늘지 않음).
• 작업은 사람이 반드시 붙어야 하는 '휴먼 인 더 루프'(정렬·계획)와 자리를 비워도 되는 'AFK'(구현)로 나뉜다. 무엇을 자동화하고 무엇을 사람이 지킬지 구분하는 것이 워크플로우 설계의 뼈대다.
• 오스터하우트의 '깊은 모듈'(작은 인터페이스·풍부한 기능)은 테스트하기 쉽고 AI가 다루기에도 좋다. 인터페이스만 설계하고 내부 구현은 '회색 상자'로 위임하면, 빠르게 움직이면서도 코드베이스에 대한 감각을 잃지 않을 수 있다.
• 코딩 표준은 '풀(구현자가 필요할 때 스킬에서 끌어옴)'과 '푸시(자동 리뷰어에게 표준을 밀어 넣음)'를 구분해 적용한다. 발표자는 구현에는 Sonnet, 리뷰에는 더 똑똑한 Opus를 쓴다고 밝혔다.

자주 묻는 질문

관련 AI 소식