Vibe coding with context engineering 요약

한줄 요약

• 이 글의 핵심은 컨텍스트 엔지니어링 자체의 소개보다, sprint + bkit PDCA 사이클을 프로젝트에 이식한 뒤 한 사람이 sprint-orchestrator로 AI 스튜디오를 지휘하며 인간과 AI의 역할을 재배치해 생산 능력을 크게 끌어올린 사례에 있다.¹

밤하늘을 배경으로 한 미래형 작업 공간에서 한 인물이 여러 개의 홀로그램 화면을 통해 코드와 데이터, AI 시각화를 동시에 분석하고 있다.

핵심 주장

• 출발점은 "하루에 9개의 리팩터링 스프린트를 출하할 수 있는가"라는 질문이다. 저자는 이를 과시가 아니라, AI는 어디서 시작하고 인간은 어디서 끝나는가를 관찰하는 기록으로 다룬다.¹

• 결과적으로 과거 방식이라면 대략 25인주 규모로 볼 만한 작업을 혼자 하루에 처리했다. 감으로 밀어붙인 것이 아니라, sprint + bkit PDCA를 컨텍스트 엔지니어링으로 프로젝트에 이식한 뒤 스프린트 단위로 AI를 오케스트레이션한 결과다.¹

• 사용 데이터도 짧게 제시된다. 28일 동안 3,514 messages, 175 sessions, 7,939 Bash calls, 1,072 sub-agent invocations가 누적됐고, 이 수치가 생산성 주장의 근거로 쓰인다.¹

• 그래서 이 글의 진짜 메시지는 "프롬프트를 더 잘 쓰자"보다 "AI가 일할 프로젝트 운영체계를 먼저 만들자"에 가깝다. 생산성은 대화 기술보다 기억, 규칙, 워크플로우, 게이트를 설계하는 쪽에서 나온다.¹

주요 개념 정리

• prompt engineering: 입력창에 무엇을 쓰는가를 최적화하는 일

• context engineering: 사용자가 입력하기 전 이미 깔려 있는 프로젝트의 기억, 규칙, 워크플로우, 산출물 흐름을 설계해 같은 맥락을 다시 설명하지 않게 만드는 일

• 핵심 차이는 한 턴 최적화와 프로젝트 메모리 최적화의 차이다. 전자가 좋은 질문을 만드는 일이라면, 후자는 AI를 새 직원처럼 온보딩해 팀의 문맥 안에서 계속 일하게 만드는 일에 가깝다.¹

• 그래서 이 글은 AI를 "똑똑한 답변기"보다, 잘 설계된 스택 안에서 움직이는 실행자이자 작업자 집합으로 본다.

4-layer context stack 설명

• Layer 1: CLAUDE.md 3종

• root, common, sprint-master로 나뉘며 매 프롬프트에 자동 주입되는 헌법 계층이다.

• 프로젝트 정체성, 30-sprint plan, 금지사항, 작업 원칙을 고정해 AI가 매번 기본 맥락을 다시 묻지 않게 만든다.¹

• Layer 2: .claude/rules/ + hooks

• pre-commit, PreToolUse:Write 같은 훅과 규칙으로 위반 쓰기를 거부하는 enforcement 계층이다.

• 권고문이 아니라, 아키텍처 위반이나 금지된 변경이 실제로 기록되기 전에 막는 가드레일에 가깝다.¹

• Layer 3: .claude/skills/, .claude/agents/, .claude/commands/

• 재사용 가능한 워크플로우, 36개 도메인 전문가, 조합 명령을 제공하는 실행 계층이다.

• 자주 하는 일을 skill과 command로 감싸고, 필요할 때 전문가 agent를 붙여 매번 긴 프롬프트를 쓰지 않게 만든다.¹

• Layer 4: docs/01-plan/, docs/02-design/, docs/04-report/, docs/05-qa/

• 이전 단계 출력이 다음 단계 입력이 되도록 plan, design, report, qa 산출물을 누적하는 계층이다.

• 스프린트가 끝날수록 stack이 richer해지고, 남겨진 문서가 다음 스프린트의 컨텍스트로 재사용된다.¹

실제 운영 방식과 품질 게이트

• 작업 흐름은 plan / design / do / analyze / iterate / qa / report를 유지하지만, 실제로는 bkit의 범용 PDCA 명령 위에서 돌아간다.¹

• 예시 흐름은 /sprint-start로 스프린트를 열고, 내부적으로 /pdca plan → design → do → analyze → iterate → qa → report를 따라가는 구조다.

• 그래서 하루 9개 스프린트는 영웅적 몰입의 산물이라기보다, 같은 패턴을 안정적으로 반복한 orchestration의 결과로 읽는 편이 맞다.

• 저자의 표현을 빌리면, AI 도움을 받아 코딩했다기보다 AI로 구성된 작은 스튜디오를 운영한 것에 가깝다. 사용 통계도 이를 뒷받침한다: Bash 7,939, Edit 2,837, Read 2,676, TaskUpdate 1,997, Write 1,327, Agent 1,072, multi-clauding 36%, 그리고 한 번에 26개 서브에이전트를 병렬로 돌린 아키텍처 감사 사례가 나온다.¹

• 품질 게이트 예시는 다음과 같이 정리된다.

• Match Rate >= 95% -- gap-detector

• Architecture violation delta = 0 -- measure-arch-violations.ts

• Matrix sync >= 95% -- verify-api-matrix.ts

• typecheck 0 errors -- tsc --noEmit

• lint 0 warnings -- eslint --max-warnings 0

• test PASS -- pnpm test¹

• Match rate가 낮으면 iterate를 최대 5회 자동 반복하고, architecture delta가 생기면 다음 단계로 못 넘어가며, matrix sync가 부족하면 matrix-synchronizer agent를 호출해 보정한다.¹

• 중요한 해석은 이 게이트가 AI보다 인간을 위한 장치라는 점이다. 사람이 놓치기 쉬운 체크리스트를 시스템이 강제로 기억하게 만든다.

sprint-orchestrator의 역할

미래적인 인터페이스로 구성된 책상 위에서 ‘MASTER PLAN’ 보드와 메모지를 활용해 아이디어, 우선순위, 마감일을 체계적으로 정리하는 모습입니다. 프로젝트 기획과 일정 관리를 시각적으로 보여주는 장면입니다.

• sprint-orchestrator는 범용 PDCA를 프로젝트 문맥으로 감싸는 thin wrapper다.¹

• 프로젝트 로컬 skill로서 /sprint-start NN을 가로채 해당 스프린트에 필요한 문맥을 자동 주입한 뒤, 내부적으로 bkit의 /pdca를 실행한다.

• 예를 들어 sprint 17에는 payment matrices, payment-expert, 관련 품질 게이트와 baselines가 붙고, 24에는 seo-expert, 27에는 arch-auditor가 자동 연결된다.¹

• 예전에는 스프린트당 약 8개 명령이 필요해 9개 스프린트면 72개 프롬프트 수준이었지만, wrapper 이후에는 같은 작업이 대략 9개 수준으로 줄어든다.¹

• 생산성의 핵심은 AI를 더 세게 몰아붙인 것이 아니라, 프로젝트 문맥 주입을 명령 한 번으로 축약한 데 있다.

실천 팁

• CLAUDE.md를 단순 소개문이 아니라 프로젝트 목적, 30-sprint roadmap, 금지사항이 들어간 운영 헌법으로 만든다.¹

• 규칙 문서를 훅과 연결해 위반 시 경고만 띄우지 말고, 실제 쓰기와 커밋을 거부하는 enforcement까지 건다.¹

• 반복 작업은 skills, commands, agents로 감싸고, 스프린트 번호에 따라 필요한 전문가가 자동으로 붙게 만든다.¹

• plan, design, qa, report 문서를 다음 단계 입력으로 다시 읽히게 설계하면 스프린트가 쌓일수록 문맥 자산이 커진다.¹

• 핵심은 AI에게 "잘해봐"라고 맡기는 것이 아니라, 어떤 기준으로 어떻게 일해야 하는지를 프로젝트 스택에 미리 심어 두는 것이다.

30-sprint master plan 관점

• 이 시스템은 단일 스프린트 자동화가 아니라, 4개월 로드맵 아래 30개 스프린트와 7개 phase를 관리하는 체계다.¹

• /sprint-status는 pdca-status.json, arch-baseline.json, GitHub issue list, master plan markdown 네 소스를 읽어 현재 상태를 한 화면으로 보여준다.¹

• 그래서 "지금 어디쯤인가"를 채팅 스크롤에서 찾지 않아도 되고, 의존성 강제(requires)도 플랜에 내장된다.

• 이 점이 중요하다. 컨텍스트 엔지니어링은 한 번의 작업을 빠르게 하는 기술이 아니라, 장기 로드맵을 흔들리지 않게 추적하는 운영 기술에 가깝다.

인간과 AI의 역할 재배치

• AI가 맡는 것은 대규모 Bash/Edit/Read/Write 실행, 1,072회의 sub-agent 호출, 최대 26개 parallel agents 운영, 품질 게이트 수행, 그리고 plan/design/report 문서 초안 생성 같은 대량 실행 작업이다.¹

• 반대로 인간이 끝까지 쥐는 것은 다음 판단들이다.

• 방향 설정과 우선순위 결정

• 완료 기준과 품질 바 정의

• 컨벤션과 트레이드오프 결정, 검증 도구 선택

• 무엇이 빠졌는지 알아차리는 제품 판단과 취향 판단¹

• 실제로 orchestrator가 멈추고 물어본 것도 Auth Guard naming, poll-vote business rule, component name, SDK namespace 같은 기술 문제라기보다 제품 판단과 취향 판단이었다.¹

• 결론적으로 필요한 것은 단순 자동화가 아니라 AX-redesign이다. AI가 일을 더 많이 할수록 인간의 역할은 사라지기보다 orchestration과 judgment 중심으로 다시 설계된다.

인상적인 포인트

• 인상적인 점은 9개의 리팩터링 스프린트를 하루에 끝냈다는 사실 자체보다, 그 속도가 sprint-orchestrator, PDCA, rules, docs, agents가 맞물린 스택에서 나왔다는 점이다.¹

• 실패 사례도 선명하다. audit-logger의 무한 재귀 때문에 장시간 자율 실행 중 682GB 디스크 폭주가 발생했는데, 교훈은 "AI는 못 믿는다"가 아니라 장시간 자율성에는 circuit breaker와 guardrail이 필수라는 것이다.¹

• 이후 safety-rules 보강, PreToolUse:Bash 감시, QA의 디스크 체크 추가처럼 사고가 stack을 바꾸는 방향으로 대응했다. 한 번의 사고가 stack을 바꾸지 않으면 다음 사고는 결국 같은 사고가 된다.

• 마지막으로 남는 메시지는 간단하다. 더 좋은 프롬프트보다 더 좋은 프로젝트가 필요하다. rules, skills, docs, hooks 없이 하는 vibe coding은 도움보다 노이즈에 가깝고, leverage는 stack이 있을 때만 생긴다. 이 글이 보여주는 핵심은 자동화 자체가 아니라, context engineering으로 AI와 인간의 역할을 재배치해 창업자와 개발자의 일을 orchestration과 judgment 중심으로 바꿨다는 점이다.¹

참고

¹Vibe coding with context engineering: 1 person, 9 sprints, 1 day