바이브 코딩(Vibe coding)은 레벨이 아니라 축입니다

Karpathy는 우리에게 바이브 코딩(vibe coding)을 제시했습니다: "무언가를 보고, 말하고, 실행하고, 복사해서 붙여넣으면 대부분 작동한다." 그 이후로 업계는 이를 깔끔한 자율성 사다리(autonomy ladder) — Level 0, Level 1부터 완전 자율 개발에 이르기까지 — 로 만들려고 계속 시도해 왔습니다.

그 사다리는 유용합니다. 하지만 불완전하기도 합니다.

그것은 한 가지, 즉 당신이 '빌딩(building)'의 얼마나 많은 부분을 AI에게 위임하는지를 측정합니다.

하지만 두 사람이 동일한 양을 위임하더라도 근본적으로 다른 결과를 얻을 수 있습니다. 한 명은 복리(compounds)를 만들어내고, 다른 한 명은 엔트로피(entropy)를 축적합니다. 동일한 자율성 레벨이지만, 운영 체제(operating system)가 다른 것입니다.

그것이 바로 누락된 축인 운영자 규율 (operator discipline) 입니다.

운영자 규율이란 한 가지를 의미합니다: 당신의 작업 중 얼마나 많은 부분이 검사 가능한 상태(inspectable state)로서 세션 경계(session boundary)를 넘어 살아남느냐 하는 것입니다.

수직 축이 측정하는 것

Karpathy에게서 영감을 얻고, AI 보조 개발에 관한 최근 글들을 통해 강화되었으며, 수십 가지의 업계 변형으로 반복되어 온 자율성 사다리(autonomy ladder)는 하나의 수직 축을 측정합니다: 당신이 모델에게 얼마나 많은 작업을 맡기도록 지시하는지, 그리고 그 위임을 지시하는 데 얼마나 유창한지를 측정합니다.

• L0: AI 없음
• L1: 자동 완성(autocomplete)으로서의 AI
• L2: 의도 기반 (you specify the what, AI fills the how)
• L3: 협업 페어 프로그래밍(collaborative pair-programming)
• L4: 반자율 (AI가 다단계 작업을 실행하고, 당신은 검토함)
• L5: 완전 자율 (AI가 루프(loop)를 소유함)

각 단계는 하나의 도메인 — 소프트웨어 빌딩 — 내부의 기술 사다리입니다. 당신은 프롬프트(prompts), 분해(decomposition), 빠른 속도의 코드 리뷰(code review-at-speed), 그리고 비결정론(non-determinism)에 대한 인내심을 개선함으로써 올라갑니다.

이것은 실재하며 측정할 가치가 있습니다. 다만 이것이 유일한 축은 아닐 뿐입니다.

수평 축이 가장 과소평가되는 부분

여기 수직 축이 답할 수 없는 질문이 있습니다:

두 개발자가 모두 레벨 4에 있습니다. 한 명은 복리로 쌓이는 (compound) 기능을 출시합니다. 코드베이스는 더 깨끗해지고, 운영 컨텍스트 (operating context)는 더 날카로워지며, 다음 프롬프트는 더 적은 것으로 더 많은 것을 해냅니다. 다른 한 명은 쇠퇴하는 (decay) 기능을 출시합니다. 코드베이스는 엔트로피 (entropy)가 증가하고, 모델에 대한 신뢰는 저하되며, 새로운 프롬프트를 던질 때마다 매번 새로 협상해야 합니다.

바이브 코딩 (vibe coding) 레벨은 같습니다. 결과는 다릅니다. 차이점은 무엇일까요?

그것은 구축하는 기술의 문제가 아닙니다. 그것은 시간이 흐름에 따라 그 사람이 도구와 관계를 맺는 방식입니다.

어떤 지도들은 이것의 파편들을 명시합니다. 신뢰 (trust), 검증 (verification), 코드 리뷰 부담 (code review burden), 그리고 AI 코드가 틀릴 수 있다는 것을 아는 것과 실제로 그것을 잡아낼 수 있는 것 사이의 "인식-행동 간극 (perception–action gap)" 같은 것들 말이죠. 그것들은 실재하며 읽어볼 가치가 있습니다. 하지만 그것들은 자율성 (autonomy) 이야기 내부의 주의 사항으로 머무는 경향이 있지, 그 자체의 구조를 가진 두 번째 축으로서 존재하지는 않습니다.

그래서 제가 직접 그 축을 그려보겠습니다.

추상적인 개념에는 구체적인 예시가 필요하므로, 작은 사례를 하나 들어보겠습니다. 약 3개월 동안 저는 몇 세션마다 동일한 아키텍처 결정 사항을 모델에게 계속 다시 설명해야 했습니다. 매번 모델은 제가 이미 거절했던 대안을 정중하게 제안하곤 했습니다. 매번 저는 다시 그것을 논박해야 했습니다. 단일 세션 내에서의 작업은 괜찮게 느껴졌습니다. 하지만 한 달이 지나자 그것은 진을 빼놓는 일이 되었습니다.

그러다 저는 상태 (status) 필드를 포함하여 별도의 저장소에 이러한 결정 사항들을 기록하기 시작했습니다. proposed (제안됨) → accepted (수락됨) → locked (잠김). 일단 결정이 locked 상태가 되면, 모델에게 명시적인 잠금 해제(unlock) 없이는 해당 사항을 다시 논쟁(relitigate)하지 말라고 지시합니다.

재논쟁이 멈췄습니다. 작업은 더 차분해졌습니다. 코드베이스는 흔들리는 대신 한 방향으로 움직이기 시작했습니다.

제 바이브 코딩 레벨에서 변한 것은 아무것도 없습니다. 변한 것은 결정 사항이 제가 실시간으로 방어해야 하는 대상이 아니라, 하나의 상태 (state)가 되었다는 점입니다.

그것이 바로 축입니다. "당신은 프롬프팅을 잘하는가"가 아니라, _당신의 컨텍스트 중 얼마만큼이 상태 머신 (state machine)인가, 반대로 얼마만큼이 매 세션마다 처음부터 다시 재구성되는가_의 문제입니다.

2×6 매트릭스

자율성 (autonomy)이 L0–L5이고 운영자 규율 (operator discipline)이 낮음/높음이라면, 총 12개의 셀 (cells)이 생성됩니다. 여기서 중요한 대각선은 "모든 것이 낮음 → 모든 것이 높음"이 아닙니다. 핵심은 교차 축 (cross-axis)에 대한 주장입니다:

L1 + 높은 운영자 규율 > L5 + 낮은 운영자 규율 (스프린트보다 긴 모든 시간 지평에서)

세 가지 샘플 셀:

• L3 + 낮음: 빠르지만 취약함 (brittle). 코드베이스 엔트로피 (codebase entropy)가 상승함. 특정 세션 내에서의 모델에 대한 신뢰도는 높지만, 오류에 대한 피드백이 전혀 이루어지지 않기 때문에 세션이 거듭될수록 신뢰도가 저하됨.
• L3 + 높음: 빠르고 안정적임. 샘플링 (sampling)을 통해 신뢰도가 교정됨. 오류가 제약 조건으로서 지속적인 컨텍스트 (persistent context)에 피드백되므로, 다음 세션은 더 나은 사전 확률 (prior)에서 시작함.
• L5 + 낮음: 최대 속도로 최대의 혼란을 향해 달려감. 이는 자율 에이전트 (autonomous agents)에 관한 모든 정직한 보고서가 결국 인정하게 되는 실패 모드 (failure mode)입니다. 즉, 전역적 제약 조건 (global constraints)을 놓치는 국소적으로 타당한 결정들이 내려지지만, 그 편차 (drift)를 잡아낼 기질 (substrate)이 없는 상태입니다.

주장의 핵심은 시간이 흐를수록 두 번째 축이 첫 번째 축을 압도한다는 것입니다. 저는 이 말이 맞다고 생각하며, 이는 검증 가능합니다. 만약 당신이 6개월 동안 실력이 비슷하게 유창한 두 AI 사용자가 서로 다른 방향으로 갈라지는 것을 목격했다면, 이미 그 패턴을 본 것입니다.

운영자 규율 (operator discipline)의 실체

제가 개인적으로 실행하고 있는 방식을 설명하겠습니다. 이것이 정답이라는 뜻이 아니라, 여러분이 구체적으로 반박할 수 있는 대상을 제공하기 위함입니다.

모델이 매 세션마다 불러오는 페르소나 파일 (persona file): 정체성, 커뮤니케이션 선호도, 엄격한 규칙, 이전에 마찰을 일으켰던 사항들. 세션에서 새로운 엣지 케이스 (edge case)가 발견될 때마다 업데이트됨.

세 가지의 추가 전용 저장소 (append-only stores). 결정에는 생명 주기 (proposed → accepted → locked)가 있음. 스레드 (threads)는 활성 워크스트림 (active workstreams)이며, 각 스레드는 현재 단계, 차단 요소 (blocker), 다음 행동을 포함함. 노트 (notes)는 출처 고정 (source-anchoring)이 된 원자적 사실 (atomic facts)임 — 모든 사실은 출처(provenance)를 가짐: 어떤 이메일, 어떤 통화, 어떤 파일, 어떤 라인인지.

기록하는 습관 (capture habit). 결정 사항은 세션이 끝난 후의 요약이 아니라, 결정이 내려진 바로 그 턴 (turn)에 저장소로 들어감. 요약은 내용이 어긋나기 쉽지만 (drift), 실시간 캡처 (live captures)는 그렇지 않음.

확정된 결정(Locked decisions)은 끊임없이 다시 의심하며 발생하는 루프(death-by-second-guessing loop)를 차단합니다. 소스 앵커링(Source-anchoring)은 환각(hallucination)으로 가는 쉬운 경로 하나를 제거합니다. 워크플로가 출처(provenance)를 시야에 강제로 노출시키면, 모델이 특정 "사실"을 자신 있게 재진술할 가능성이 낮아지기 때문입니다.

이 중 어느 것도 새로운 아키텍처(architecture)는 아닙니다. 새로움은 이것이 암시되는 것이 아니라, 기록되고 강제된다는 점에 있습니다. 이것은 프롬프트 트릭(prompt trick)이 아니라 상태 머신(state machine)입니다.

당신의 자율성(autonomy) 레벨이 무엇이든, 이 축 위에서 높거나 낮을 수 있습니다. 그것이 바로 축(axis)입니다.

내가 주장하지 않는 것

규율(Discipline)이 유창함(fluency)을 이기는 것은 아닙니다. 이 둘은 곱해지는 관계입니다. 높은 규율을 가진 L1 사용자는 여전히 높은 규율을 가진 L4 사용자보다 느리게 움직입니다.

자율성 사다리(autonomy ladder)가 틀린 것은 아닙니다. 그것은 실재하며 올라갈 가치가 있습니다.

내가 주장하는 것: 지도는 두 개의 축을 가지고 있으며, 대중적인 대화의 대부분은 그중 하나에 대해서만 이루어져 왔습니다. 만약 "더 많은 AI"가 당신에게 "더 많은 레버리지(leverage)"로 이어지지 않았다면, 그 답은 더 똑똑한 모델이 아닐 수도 있습니다. 그것은 당신이 측정하지 않았던 축일 수도 있습니다.

당신의 운영자 규율(operator discipline)은 어떤 모습인가요? 무엇이 상태(state)로 캡처되고, 무엇이 매 세션마다 재구성되나요? 댓글을 통해 구체적인 설정들을 듣고 싶습니다 — 특히 제 의견과 다른 설정들을 환영합니다.

— Mike