왜 AI는 항상 몇 개의 블록을 빠뜨릴까?

您的瀏覽器不支援音檔播放。下載音檔

당신이 분명히 겪어봤을 고통

나는 AI에게 브랜드 웹사이트를 만들어 달라고 요청했습니다. 결과물로 돌아온 것은 두 개의 링크가 있는 헤더, "About" 페이지는 아예 없고, 관리자 패널은 작동하지만 사이트 어디에도 그곳으로 연결되는 버튼이 없는 상태였습니다. 백엔드(Backend)는 90%인데 프론트엔드(Frontend)는 10%뿐이었죠.

처음에는 AI가 게으름을 피우는 것이라고 추측했습니다. 하지만 그렇지 않았습니다. 이것은 구조적인(structural) 문제입니다. 그리고 이를 해결하는 설계 원칙은 제가 인지하지 못한 채 제 작업 도구 체인(toolchain)에서 이미 일곱 번이나 재사용했던 것이었습니다.

이 글은 그 원칙에 관한 것입니다. 하지만 그전에 "몇 개의 블록을 빠뜨리는" 고통에 대해 먼저 이야기하겠습니다. 왜냐하면 그것에는 이름이 있기 때문이며, 아무도 아직 그 이름을 붙이지 않았을 것이라고 생각하기 때문입니다.

누락된 것은 바로 완전성 기준 (completeness baseline) 입니다

나는 왜 이러한 도구들(내가 만든 것을 포함하여)이 "몇 개의 블록을 빠뜨리는지" 파헤쳐 보았고, 그들이 모두 동일한 것을 검증한다는 사실을 발견했습니다:

"당신이 선언한(declared) 모든 것이 내부적으로 일관성이 있는가?"

그리고 결코 다음과 같이 묻지 않습니다:

"이러한 **종류(kind)**의 결과물은 당연히 갖추어야 할 것들을 갖추고 있는가?"

이 간극은 치명적입니다. 당신이 브랜드 사이트를 요청하며 두 개의 페이지를 언급하면, 모든 검증 과정은 그 두 페이지가 서로 연결되는지를 충실히 확인한 뒤 통과(green) 판정을 내립니다. 시스템 내에 브랜드 사이트가 어떤 모습이어야 하는지에 대한 표준이 아무것도 없기 때문에, "브랜드 사이트라면 당연히 About 페이지가 있어야 한다"라고 묻지 않는 것입니다. 쓰레기가 들어가면, 검증된 쓰레기가 나옵니다.

그것이 바로 누락된 조각인 완전성 기준 (completeness baseline) 입니다. 즉, _실제 결과물을 대조하여 확인할 수 있도록, 특정 종류의 산출물이 무엇을 포함해야 하는지에 대한 표준_입니다. 내부적 일관성이 아니라, 그곳에 있어야 할 것이 실제로 있는지를 확인하는 것입니다.

이런 느낌을 받은 것은 저뿐만이 아닙니다. Thomson Reuters의 Claude Forge에 관한 글에서 저자는 한 줄을 남겼습니다: "테스트를 통과하는 것은 필요하지만, 그것만으로는 충분하지 않다." 그는 다음 단계의 층위를 느꼈지만, 그것을 구축하지는 못했습니다. 모두가 이 고통을 겪었지만, 아무도 기준(baseline)을 키워내지 못했습니다.

내가 한 일: 산출물 유형별 완전성 축 (completeness axis)

저의 해결책은 "내장된 웹사이트 템플릿을 제공하는 것"이 아닙니다. 그렇게 하면 API, 자동화, 봇 등 웹이 아닌 것을 구축하는 사람들에게 피해를 줄 것입니다. 그것은 하나의 축 (axis) 입니다. 먼저 이것이 _어떤 종류_의 것인지 분류하고, 각 종류가 스스로의 "완성된 모습이 무엇인지"에 대한 기준(baseline)을 갖게 하는 것입니다.

• 브랜드 사이트 (Brand site) → 어떤 섹션이 있어야 하는지, 각 표면(surface)에 접근 가능한지, 신뢰 페이지가 실제 존재하는지.
• 순수 API (Pure API) → 문서 (docs), 에러 코드 (error codes), 버전 관리 (versioning), 속도 제한 (rate limits).
• 자동화 (Automation) → 실행되는지, 관찰 가능한지 (observable), 실패 시 누군가에게 알림을 보내는지.

그리고 완성도 (completeness)는 예/아니오의 문제가 아니라 세 가지 계층으로 나뉩니다: 존재함 (exists) → 접근 가능함 (reachable) → 입증됨 (substantiated). 마지막 단계가 가장 많이 누락됩니다. 사진이 필요한 '소개(About)' 페이지는, 단순히 텍스트만 나열된 것이 아니라 페이지에 _이미지 슬롯 (image slot)_이 있고 동시에 실제로 사진을 넣을 수 있는 백엔드 경로가 있어야만 완료된 것입니다. 웹 완성도는 이 축 위의 _하나_의 셀일 뿐입니다. 이것이 바로 "'웹 앱'을 유일한 표준으로 만들 수 없다"는 원칙이 예외가 아닌 설계에 의해 (by design) 충족되는 이유입니다.

그것이 완성도의 기준(baseline)입니다.

그리고 동일한 법칙이 계속 나타났습니다

그 기준을 세운 후, 저는 계속해서 구축해 나갔습니다. 아이디어(또는 기존 프로젝트의 감사/audit)에서부터 최종 전달까지 이어지는 파이프라인을 연결했습니다. 그러다 이상한 점을 발견했습니다: 제가 추가한 모든 조각은 단지 다른 옷을 입고 있을 뿐, 동일한 설계 결정이었습니다.

(1) 정체성(identity)이 아닌 능력(capability)에 의한 제한.
도구는 "내가 Claude인가?"라고 묻지 않습니다. 대신 "_이 능력 (capability)_이 존재하는가?"라고 묻습니다. 존재한다면 풍부한 상호작용 (rich interaction)을 사용하고, 존재하지 않는다면 일반 텍스트로 우아하게 기능 저하 (degrade gracefully)를 수행합니다. 이것이 중요한 이유: 동일한 기능이 Claude Code, Cursor, 또는 아무런 기능이 없는 순수 LLM에서도 깨지지 않고 실행됩니다. 정체성이 아니라 능력을 감지하세요 (Detect the capability, not the identity).

(2) 공개된 엔진, 비공개된 가치 (Public engine, private values).
엔진은 오픈 소스 (open-source)로 공개하지만, 제가 어렵게 얻은 노하우 — 하우스 컨벤션 (house conventions), 보안 트랩 목록, 테이블 이름 등 — 는 비공개 (private) 저장소에 보관하며, 동일한 능력 게이트 (capability gate)를 통해 런타임 (runtime)에 주입하여 절대 유출되지 않도록 합니다. 제 비공개 파일이 없는 공개 사용자는 그저 중립적인 기본값 (defaults)을 받게 되며, 전혀 방해받지 않습니다. 저의 습관은 저의 것으로 남습니다. 강요되지도, 노출되지도 않습니다.

(3) 제안하되, 자동으로 진행하지 마세요 (Propose, don't auto-advance).
각 단계의 끝에서 시스템은 다음 단계를 선제적으로 제안 (proactively offers) 하지만, 결정은 인간이 합니다. 자동화되는 것은 흐름 (flow)이지, 판단 (judgment)이 아닙니다. 저는 심지어

• 이미 질리도록 말해진 것들 (나의 핵심 셀링 포인트가 아님): "파일을 통해 느슨하게 결합된 도구들 (tools loosely coupled through files)" (수십 년 된 Unix 철학이며, BMAD-METHOD와 Claude Forge 모두 이를 수행함) 그리고 "매 단계마다 인간에게 질문하기 (ask the human at every step)" (Spec Kit, AWS Kiro, Forge; Thoughtworks는 이미 이를 2025년의 합의된 관행(consensus practice)으로 명명함). 저는 이것들을 전면에 내세우지 않을 것입니다.
• 찾아볼 수 있는 명확한 선행 기술(prior art)이 없음: 위의 세 가지 — 역량 게이팅 (capability-gating), 공개 엔진/비공개 가치 (public-engine/private-values), 그리고 완결성 기준선 (completeness baseline). 가장 유사한 이웃인 BMAD-METHOD는 느슨한 결합(loose coupling)과 역할 분담(role division)을 다루지만, 역량 게이트(capability gate), 공개/비공개 주입(public/private injection), 완결성 기준선(completeness baseline)은 갖추고 있지 않습니다.

따라서 저의 독창성(novelty)은 단일 요소에 있는 것이 아니라, 이들을 _하나의 법칙 (one law)_으로 바라보는 **결합 (combination)**과 프레임워크에 있습니다. 누군가의 인덱싱되지 않은 저장소(repo)나 개인 에세이에 유사한 내용이 있을 수 있으므로, 보수적으로 접근하여 이렇게 말씀드리는 것입니다. 하지만 세 차례의 검색에도 불구하고 이를 발견하지 못했다는 사실 자체가 하나의 신호입니다.

작은 증거 하나: 저렴한 모델로 충분한가?

설계는 차치하고, 나머지는 비용의 문제입니다. 저는 단일 통제 실험 (single controlled experiment) (N=1, 솔직하게 라벨링함)을 수행했습니다: 동일한 사양(spec), 동일한 분해 규칙(decomposition rules), 동일한 프롬프트 — 오직 모델만 변경했습니다. Sonnet 대 Opus, 각각 한 번의 분해를 수행했습니다.

• 객관적 지표: Sonnet 75k 토큰, Opus 86k (14% 더 많음). 약 80%의 중복, 둘 다 유효하며 둘 다 정직함.
• 질적 차이가 바로 신호입니다: 기계적인 (mechanical) 부분에서 Sonnet은 비슷하거나 더 나았습니다 (수락 예시 테이블을 더 완전하게 작성했고, 이중 브로드캐스트 충돌을 더 명시적으로 포착함) — 게다가 더 저렴했습니다. Opus는 정확히 한 곳에서 추가 비용의 가치를 증명했습니다: Opus는 숨겨진 전제 조건 (hidden prerequisite) — "계정 시스템이 없고 연결 ID가 변경되는 재연결 상황에서, 서버는 이 플레이어가 누구인지 어떻게 알 수 있는가?" — 을 포착했으며, 가짜 해결책을 지어내기를 거부하고 이를 인간에게 다시 가져가야 할 진정한 공백(gap)으로 표시했습니다. Sonnet은 실제로 문제를 해결하지 못하는 결정으로 이를 대충 덮어버렸습니다 (papered over it). Opus는 또한 Sonnet이 놓친 내부 사양 모순(internal spec contradiction)도 포착했습니다.

그러한 오류들은 정확히 통합 단계의 중단(integration breaks)으로 이어지는 하류로 전파(propagate downstream)되는 오류들입니다. 따라서 이 N=1(저는 이를 확실한 증거로 취급하기 전에 N≥3이 될 때까지 지켜볼 것입니다)이 말해주는 바는 다음과 같습니다: 저렴한 모델은 기계적인 작업량(mechanical bulk)을 처리합니다 — 80%까지 수행하며 더 저렴합니다; 비싼 모델은 오류의 전파를 방지하는 "지어내기를 거부하고 모순을 포착하는" 판단력 측면에서만 그 비용만큼의 가치가 있습니다. 이것이 바로 제 파이프라인이 목표(goal)마다 모델을 할당하고, 안전망으로서 독립적인 감사(independent audit)를 유지하는 정확한 이유입니다.

"비싼 모델이 더 좋다"는 뜻이 아닙니다. 핵심은 다음과 같습니다: 흐름은 자동화하되, 판단은 계층화하고, 오류가 전파되는 지점에는 인간의 게이트(human gate)를 유지하라.

따라서 이 단계는 "마법 같은 앱 생성기"가 아닙니다

만약 제가 이것을 "아이디어에서 인도까지의 AI 파이프라인"이라고 포지셔닝했다면, Devin, v0, bolt 등과 비교되었을 것이고, 저는 그들의 사분면에 속하지 않습니다. 그들은 마법, 원클릭, 핸즈오프(hands-off)를 판매합니다. 저는 그와 정반대의 것을 구축했습니다:

• 교체 안전성 (Swap-safe) (느슨한 결합(loose coupling) — 각 도구는 단독으로 유용하며, 고장 나면 교체 가능함)
• 개인정보 보호 (Privacy-preserving) (공용 엔진, 개인적 가치 — 당신의 해자(moat)를 유출하지 않고도 오픈 소스화 가능)
• 실제로 완전함 (Actually complete) (완전성 기준선(completeness baseline) — "몇 개의 블록을 빠뜨리는" 일이 없음)
• 인간이 판단을 유지함 (Human keeps the judgment) (자동 진행이 아닌 제안 방식)

1인 기업이나 소규모 팀에게 이것은 "더 강력한 에이전트"가 아닙니다. 이것은 **해자 설계 패턴(moat design pattern)**입니다: 내부를 들여다볼 수 없는 블랙박스에 모든 것을 거는 대신, 엔진은 오픈 소스로 공개하고, 당신만의 프라이빗한 노하우를 축적하여, 이를 고객에게 제공하는 것입니다.

결론: 일곱 번째는 반복이 아니라 법칙입니다

제가 배운 가장 실질적인 것은 다음과 같습니다: 더 강력한 모델이나 더 많은 마법을 사용한다고 해서 "몇 개의 블록을 빠뜨리는" 일이 멈추지는 않습니다. 그것을 멈추는 방법은 (1) 어떤 종류의 결과물이 어떻게 보여야 하는지 아는 완전성 기준선(completeness baseline)을 시스템에 부여하고, (2) 당신의 컨벤션(conventions)을 재사용 가능한 부품으로 구워 넣으며(baking), (3) 흐름은 자동화하되 판단은 결코 자동화하지 않는 것입니다.

그리고 — 당신이 똑같은 설계 결정(design decision)을 일곱 번째 내리고 있다는 사실을 깨달았을 때, 멈추십시오. 그것은 당신이 단순히 반복하고 있는 것이 아닙니다. 그것은 당신이 사용해 왔지만 한 번도 입 밖으로 내뱉지 않은 하나의 법칙입니다. 그것에 이름을 붙이십시오. 그것은 어쩌면 다른 모든 사람도 사용하고 있지만, 아직 아무도 말하지 않은 바로 그 무엇일지도 모릅니다.

출처: "헤더에는 링크가 두 개뿐이다"라는 대화에서 시작하여 "휴대 가능한 보안 게이트 + 엔드 투 엔드 핸드오프(end-to-end handoffs)"로 확장된 2026년 6월의 대화. 설계 결정 사항들은 공개 리포지토리(public repos)의 DESIGN-NOTES에 ADR-001부터 007까지 기록되어 있습니다. 선행 기술(Prior-art) 및 전체 A/B 데이터는 별도로 보관됩니다.

본문은 제 블로그에 게재되었습니다: "Why does the AI always leave a few blocks out?"