진정한 AI 코딩의 돌파구는 더 많은 컨텍스트가 아니라 더 나은 진단(Diagnostics)이다

Scarab Diagnostic Suite가 된 것을 만들기 시작했을 때, 저는 AI 지원 소프트웨어 개발 이론을 만들려고 했던 것이 아니었습니다.

저는 제 자신의 리포지토리(repo)에서 살아남으려 노력하고 있었습니다.

저는 Codex를 사용하여 복잡한 프론트엔드/백엔드(frontend/backend) 시스템을 구축하고 있었습니다. 장난감 앱이 아니었습니다. 랜딩 페이지도 아니었습니다. 공개 사이트, 내부 콘텐츠 아키텍처(content architecture), 회원 대상 인터페이스, 제품 로직, 백엔드 API, 프론트엔드 라우트(frontend routes), 편집 워크플로(editorial workflows), 운영 관련 사항, 그리고 서로 조화를 유지해야 하는 수많은 가동 부품들을 갖춘 실제 시스템이었습니다.

Codex는 빠르게 움직일 수 있었습니다. 매우 빠르게 말이죠.

Codex는 파일을 생성하고, 컴포넌트(components)를 연결하고, 마이그레이션(migrations)을 작성하고, 오류를 패치(patch)하고, 라우트를 구축하고, 테스트를 추가하고, 스스로를 설명하며 프로젝트를 계속 추진할 수 있었습니다. 처음에는 그것이 AI 코딩 에이전트(AI coding agents)의 모든 약속처럼 느껴졌습니다.

그러다 드리프트(drift, 표류)가 시작되었습니다.

정확히 말하면 실패는 아니었습니다.

드리프트였습니다.

이 차이는 중요합니다.

에이전트는 여전히 코드를 생성할 수 있었습니다. 빌드(build)도 여전히 통과할 수 있었습니다. 테스트도 여전히 통과(green)할 수 있었습니다. UI도 여전히 무언가를 렌더링할 수 있었습니다. 하지만 이러한 겉보기의 진전 아래에서, 리포지토리는 형태를 잃기 시작했습니다.

에이전트가 "딱 하나만 더"를 계속 추가하면서 파일 하나가 너무 커졌습니다. 실제 모듈 경계(module boundary)가 있어야 할 곳에 헬퍼(helper)가 나타났습니다. 프론트엔드 라우트가 백엔드에 속해야 할 동작을 소유하기 시작했습니다. 생성된 아티팩트(artifact)가 조용히 소스 진실(source truth)로 취급되었습니다. 테스트는 의도된 동작을 증명하는 대신 패치를 증명하게 되었습니다. 임시방편(workaround)이 아키텍처(architecture)가 될 정도로 오랫동안 살아남았습니다.

코드는 작동했습니다.

하지만 리포지토리는 응집력이 떨어졌습니다.

그 지점에서 Scarab이 시작되었습니다.

또 다른 코딩 에이전트로서가 아니었습니다. 테스트를 대체하기 위해서도 아니었습니다. 마법 같은 수리 도구로서도 아니었습니다. Scarab은 매우 구체적인 압박에 대한 응답으로 시작되었습니다. 어떻게 하면 AI 코딩 에이전트가 실제 소프트웨어 프로젝트를 서서히 정렬 상태에서 벗어나게 만드는 것을 막을 수 있을 것인가 하는 문제였습니다.

문제는 AI가 코딩을 할 수 없다는 것이 아니었습니다

AI는 코딩을 할 수 있습니다.

그것은 더 이상 흥미로운 질문이 아닙니다.

더 중요한 질문은 AI가 당신이 실제로 구축하려는 시스템의 형태 안에서 코딩을 계속 유지할 수 있느냐 하는 것입니다.

그것은 훨씬 더 어려운 일입니다.

리포지토리 (Repo)는 단순히 파일들의 더미가 아닙니다. 그것은 소유권 (Ownership)을 가집니다. 경계 (Boundaries)를 가집니다. 규칙 (Rules)을 가집니다. 가정 (Assumptions)을 가집니다. 진실이 존재해야 하는 장소들을 가집니다. 프레임워크 컨벤션 (Framework conventions)을 가집니다. 의미 있는 무언가를 증명해야 하는 테스트 (Tests)를 가집니다. 공개 동작 (Public behavior), 내부 동작 (Internal behavior), 생성된 동작 (Generated behavior), 런타임 동작 (Runtime behavior), 그리고 유지 관리자의 기대치 (Maintainer expectations)를 가집니다.

이러한 계층들이 일치할 때, 시스템은 일관성 있게 느껴집니다.

이들이 일치하지 않기 시작하면, 시스템은 표류 (Drifting)하기 시작합니다.

불편한 점은 우리가 종종 인간조차 실제로 안정화하지 못한 컨텍스트 (Context)를 AI에게 보존하라고 요구한다는 것입니다.

우리는 에이전트 (Agent)가 무엇이 중요한지 알기를 원합니다. 우리는 에이전트가 좁은 범위 내에서 패치 (Patch)하기를 원합니다. 우리는 에이전트가 아키텍처 (Architecture)를 존중하기를 원합니다. 우리는 에이전트가 어떤 파일이 어떤 책임을 갖는지 이해하기를 원합니다. 우리는 에이전트가 어떤 테스트가 권위 있고 어떤 것이 부수적인지 알기를 원합니다. 우리는 에이전트가 언제 임시방편 (Workaround)이 허용되는지, 그리고 언제 그것이 시스템에 대한 조용한 위반인지 알기를 원합니다.

하지만 매우 빈번하게, 리포지토리 (Repo) 자체는 이러한 것들을 명확히 알지 못합니다.

문서 (Docs)는 오래되었을 수 있습니다. 테스트는 동작의 일부만을 증명할 수도 있습니다. 런타임은 의도된 아키텍처와 모순될 수 있습니다. 이슈 (Issue)는 증상은 설명할 수 있지만 실패한 경계 (Boundary)는 설명하지 못할 수 있습니다. 인간은 규칙을 직관적으로 알고 있을지 모르지만, 리포지토리는 에이전트가 신뢰할 수 있게 준수할 수 있는 곳 어디에도 그 규칙을 보존하고 있지 않을 수 있습니다.

그래서 우리는 불안정한 영역에 AI 코딩 에이전트를 집어넣고, 그것이 표류할 때 놀란 척을 합니다.

하지만 시스템이 스스로의 경계를 정의하지 않았다면, 왜 우리가 AI가 그것을 강제할 것이라고 기대하겠습니까?

더 많은 컨텍스트가 안정적인 컨텍스트와 같은 것은 아니다

AI 코딩에 관한 많은 대화는 여전히 동일한 답변들의 궤도를 돌고 있습니다: 더 큰 컨텍스트 윈도우 (Context windows), 더 똑똑한 모델 (Models), 더 자율적인 에이전트 (Autonomous agents), 더 나은 프롬프트 (Prompts), 더 강력한 도구 (Tools), 더 많은 메모리 (Memory).

그러한 것들이 도움이 될 수는 있습니다.

하지만 그것들만으로는 근본적인 문제를 해결할 수 없습니다.

더 큰 컨텍스트 윈도우 (Context Window)는 더 많은 텍스트를 담을 수 있습니다. 하지만 그것이 어떤 텍스트가 권위 있는 정보인지 자동으로 결정해주지는 않습니다. 더 똑똑한 모델은 더 나은 추론 (Reasoning)을 할 수 있습니다. 하지만 여전히 잘못된 기준점을 향해 추론할 수 있습니다. 더 자율적인 에이전트 (Agent)는 더 빠르게 움직일 수 있습니다. 하지만 누군가 알아차리기 전에 잘못된 가정을 더 많은 영역으로 확산시킬 수도 있습니다.

문제는 단순히 AI에게 더 많은 컨텍스트가 필요하다는 것이 아닙니다.

문제는 컨텍스트에 소유권 (Ownership)이 필요하다는 것입니다.

어떤 컨텍스트는 모델과의 취약한 대화 형태로 존재해서는 안 됩니다. 어떤 컨텍스트는 에이전트가 세 번 전의 프롬프트 (Prompt)에서 나온 문장을 기억하느냐에 의존해서는 안 됩니다. 어떤 컨텍스트는 AI가 리포지토리 (Repo)를 건드릴 때마다 매번 다시 설명되어야 해서도 안 됩니다.

리포지토리는 다음과 같이 말할 수 있어야 합니다:

이 영역은 이 동작을 소유한다.

이 파일이 표준 (Canonical)이다.

이 패턴은 더 이상 사용되지 않는다 (Deprecated).

이 테스트가 이 경계 (Boundary)를 증명한다.

이 생성된 출력물은 소스 진실 (Source Truth)이 아니다.

이 임시 방편 (Workaround)은 일시적이다.

이 프레임워크 컨벤션 (Framework Convention)은 반드시 유지되어야 한다.

여기서 "완료 (Done)"란 바로 이것을 의미한다.

이것은 "AI가 알아서 하게 두라"는 태도와는 매우 다른 자세입니다.

이것은 AI에게 더 나은 직무를 부여합니다.

에이전트에게 설계자, 기록가, 유지보수자, 테스터, 리뷰어, 빌더의 역할을 한꺼번에 수행하라고 요구하는 대신, 리포지토리가 모델 외부에서 시스템 규칙을 보유할 수 있습니다. 그러면 AI는 자신이 실제로 잘하는 일, 즉 제한된 구조 (Bounded Structure) 안에서 빠르게 움직이는 일을 할 수 있습니다.

그때 비로소 AI는 약해지는 것이 아니라 더 강력해집니다.

진정한 돌파구는 AI에게 더 많은 책임을 떠넘기는 것이 아닙니다.

불안정한 컨텍스트의 무게를 AI로부터 덜어주는 것입니다.

진지한 시스템에서 진단 (Diagnostics)은 선택 사항이 아니다

공상 과학 영화 속의 우주선부터 휴머노이드 기계에 이르기까지, 상상 가능한 모든 첨단 시스템이 항상 진단 (Diagnostics)을 수행하는 데에는 이유가 있습니다.

시스템이 행동하기 전에, 스스로를 점검합니다.

하위 시스템들이 온라인 상태인가?

측정값들이 일관적인가?

신호가 실제인가?

장애가 격리되었는가?

어느 경계가 침해되었는가?

그러한 패턴이 존재하는 이유는 그것이 근본적인 무언가를 반영하기 때문입니다. 즉, 중대한 시스템(serious systems)은 자신의 운영 상태를 검증할 수 있는 방법이 필요하다는 점입니다.

소프트웨어도 다르지 않습니다.

그리고 AI 보조 소프트웨어는 이 기능이 적게 필요한 것이 아니라, 오히려 훨씬 더 많이 필요합니다.

만약 AI 코딩 에이전트(AI coding agent)가 수십 개의 파일을 빠르게 수정할 수 있다면, 저장소(repo)는 이러한 변경 사항들이 시스템의 진실(truth)을 보존했는지 판단할 수 있는 방법이 필요합니다. 단순히 코드가 컴파일되는지 여부만으로는 부족합니다. 단순히 테스트가 통과했는지 여부만으로도 부족합니다. 단순히 에이전트가 작업이 완료되었다고 말하는 것만으로는 충분하지 않습니다.

저장소는 다음과 같은 질문을 던져야 합니다:

이 변경 사항이 소유권(ownership)을 존중했는가?

경계(boundary)를 보존했는가?

동작(behavior)을 올바른 계층(layer)으로 이동시켰는가?

테스트를 더 진실되게 만들었는가, 아니면 단순히 연극적으로(theatrical) 만들었는가?

드리프트(drift)를 줄였는가, 아니면 단순히 눈에 보이는 실패를 침묵시켰는가?

수정 후에 시스템이 더 일관성(coherent) 있게 되었는가?

이것이 바로 Scarab이 목표로 하는 진단 계층(diagnostic layer)입니다.

Scarab은 코딩 에이전트가 되려는 것이 아닙니다. 주관적인 제품 결정을 내리려는 것도 아닙니다. 유지보수 담당자나 개발자를 대체하려는 것도 아닙니다.

Scarab은 AI 외부에서 저장소의 진실(repo truth)을 유지하려고 노력합니다.

그 차이점이 바로 제품의 전부입니다.

첫 번째 유스케이스는 능동적인 AI 보조 개발이었습니다

Scarab의 원래 유스케이스는 공개 오픈 소스 복구(public open-source repair)가 아니었습니다.

원래 유스케이스는 능동적인 개발(active development)이었습니다.

저는 Codex가, 제 머릿속에 항상 전부 담아두기에는 너무 크고 복잡해지는 저장소의 경계 안에서 계속 작동할 수 있게 만드는 방법이 필요했습니다.

루프(loop)는 다음과 같은 모습이었습니다:

인간이 프로젝트의 방향을 정의합니다.

저장소는 규칙, 경계, 그리고 수용된 구조를 보존합니다.

AI 코딩 에이전트가 코드를 작성하거나 변경합니다.

Scarab은 변경 사항이 여전히 저장소의 수용된 진실(accepted truth)과 일치하는지 확인합니다.

모순(contradiction)이 나타나면, Scarab은 진단 경계(diagnostic boundary)를 드러냅니다.

인간이나 코딩 에이전트가 지침에 따라 수정합니다.

Scarab이 다시 실행되어 모순이 실제로 해결되었는지 검증합니다.

이것은 "AI가 코드를 작성하고 테스트가 이를 잡아내기를 바란다"는 방식과는 매우 다릅니다.

또한 이는 “AI가 코드를 작성하고 나중에 누군가가 이를 정리한다”는 방식과도 다릅니다.

핵심은 저장소(repo)가 변경되는 동안 저장소의 진실(truth)을 계속 감시하는 것입니다.

그것이 바로 미래 지향적인 유스케이스(use case)입니다: 드리프트(drift)가 정상적인 상태가 되는 것을 방지하는 것입니다.

그 후 현장 테스트가 이론의 형태를 바꾸었습니다

Scarab이 능동적인 가드레일(guardrail)로서 작동하기 시작하자, 더 큰 질문이 나타났습니다.

Scarab이 드리프트가 형성되는 동안 이를 감지할 수 있다면, 드리프트가 이미 누적된 후에도 이를 감지할 수 있을까요?

그 질문이 Scarab을 공개 현장 테스트로 밀어 넣었습니다.

저는 장난감 저장소나 연출된 데모가 아닌, 실제 오픈 소스 이슈들을 대상으로 진단 패스(diagnostic passes)를 실행하기 시작했습니다. 다양한 언어, 프레임워크, 런타임(runtime), 그리고 관리자 문화에 걸쳐 있는 실제 소프트웨어 프로젝트의 실제 이슈들을 대상으로 했습니다.

목표는 모든 버그가 AI에 의해 발생했다는 것을 증명하는 것이 아니었습니다.

그것은 너무 좁은 시각이며, 솔직히 사실도 아닙니다.

목표는 근본적인 진단적 관점(diagnostic lens)이 제 저장소 외부에서도 유효한지 테스트하는 것이었습니다.

Scarab이 도착하기 전부터 이미 드리프트가 발생하고 있던 시스템에도 동일한 경계 이론(boundary theory)을 적용할 수 있을까요?

그 대답은 '예'로 기울기 시작했습니다.

그 부분이 저에게 제품의 성격을 바꾼 지점이었습니다.

Scarab은 AI 보조 개발을 감독하는 방법으로 시작되었습니다. 하지만 현장 테스트를 통해 동일한 원리가 역방향으로도 작동할 수 있다는 것이 드러나기 시작했습니다. Scarab은 기존의 실패 표면(failure surface)에 진입하여, 진실을 보존하는 것을 중단시킨 경계를 식별하고, 좁은 범위의 수정 후보(repair candidate)를 도출하도록 도울 수 있습니다.

이것이 중요한 이유는 드리프트가 인간, 팀, AI 코딩 에이전트, 마이그레이션, 오래된 테스트, 런타임 변경, 또는 5년간의 “일단 지금은 패치만 하자”는 식의 태도 중 무엇에 의해 도입되었는지는 상관하지 않기 때문입니다.

드리프트는 그냥 드리프트입니다.

시스템이 자기 자신과의 정렬(alignment)에서 벗어난 것입니다.

현장 테스트가 공개적으로 이론을 증명하고 있습니다

현장 테스트에서 가장 중요한 것은 테스트가 패치(patch)를 만들어낸다는 점이 아닙니다.

중요한 점은 동일한 진단적 질문이 매우 다른 시스템들 사이에서도 계속해서 작동한다는 것입니다:

이 시스템이 보존해야 했던 진실은 무엇이었으며, 어떤 경계(boundary)가 그 보존을 막았는가?

pnpm 필드 테스트(field test)에서 발생한 문제는 광범위한 의미에서 "자가 업그레이드(self-upgrade)가 고장 났다"는 것이 아니었습니다. 경계는 더 좁았습니다. pnpm 바이너리를 업그레이드하려는 명령이, 프로젝트 매니페스트(manifest)가 존재하지 않을 때 프로젝트 의존성(dependency) 동작으로 잘못 흘러 들어갔던 것입니다. 수정 사항이 수용되고 병합(merge)될 수 있었던 이유는 경계가 구체적이었기 때문입니다. 즉, 매니페스트가 없는 조건이 의도적인 경우에는 의존성 상태 자동 설치 경로를 건너뛰되, 프로젝트 매니페스트가 존재하는 기존의 폴백(fallback) 동작은 유지하도록 한 것입니다.

이것은 느낌(vibes)에 기반한 수정이 아닙니다.

이것은 경계 수정(boundary repair)입니다.

Rust 컴파일러 필드 테스트에서 눈에 보이는 문제는 무한 재귀적인 중첩 구조체(nested structs)가 릴리스 모드(release mode)에서 컴파일되기 시작했다는 것이었습니다. 외부에서 보기에는 엄청난 문제처럼 들립니다. 하지만 수정 범위는 더 좁았습니다. 로우 포인터(raw pointer) 메타데이터는 보수적으로 유지되어야 하는 반면, 최적화/코드 생성(codegen) 경로는 불가능한 재귀적 레이아웃이 통과되지 않도록 포인티(pointee) 레이아웃 검증을 여전히 강제해야 했습니다.

다시 말하지만, 유용한 진단(diagnostic)은 "Rust가 고장 났다"가 아니었습니다.

그것은 "이 특정 검증 소유권 경계(validation ownership boundary)가 이 특정 최적화 경로에서 유실되었다"는 것이었습니다.

Playwright 필드 테스트에서 눈에 보이는 증상은 멈춤(hang) 현상이었습니다. iframe 내부에서 로드된 워커 스크립트(worker script)에 대해 response.allHeaders()가 완료(settle)되지 않을 수 있었습니다. 하지만 진단 경계는 "Playwright가 멈춘다"보다 더 작았습니다. 응답 메타데이터 완료 경로가 워커 프레임 세션(worker-frame session)에서 소유권을 잃은 것이었습니다. 일반적인 Chromium 응답 메타데이터 동작은 온전하게 유지되어야 하지만, 워커-메인-스크립트 케이스는 공개 API가 영원히 도착하지 않을 메타데이터를 기다리는 대신 완료될 수 있도록 제한된 폴백(bounded fallback)이 필요했습니다.

서로 다른 스택.

서로 다른 언어.

서로 다른 증상.

동일한 패턴.

시스템의 다른 부분이 의존하고 있는 진실을 무언가가 보존하는 것을 멈춘 것입니다.

이것이 바로 Scarab 레인(lane)입니다.

좁은 수정은 작은 사고가 아니다

현장 보고서(field reports)에서 제가 계속해서 강조하고 있는 한 가지 문구는 바로 “좁은 수정 (narrow repair)”입니다.

그것이 사소하게 들릴 수도 있습니다.

하지만 그렇지 않습니다.

좁은 수정이 작은 이유는 버그가 중요하지 않기 때문이 아닙니다. 경계(boundary)가 명확하기 때문입니다.

그것이 바로 여러분이 원하는 것입니다.

광범위한 패치 (broad patch)는 종종 실패의 경계가 여전히 모호하다는 것을 의미합니다. 수정 사항이 주변 코드에 영향을 주기 시작합니다. 가드 (guards)를 추가합니다. 테스트를 다시 작성합니다. 증상 주변의 동작을 변경합니다. 빨간 불(에러)은 사라지게 만들지만, 더 깊은 모순은 그대로 남겨둘 수 있습니다.

좁은 수정은 다음과 같이 말합니다:

결함은 여기에 있다.

이 핸드오프 (handoff) 과정에서 소유권 (ownership)을 잃었다.

이 테스트가 경계를 증명한다.

이 동작은 변경되지 않은 상태로 유지되어야 한다.

이것은 범위 외 (out of scope)이다.

이것이 일관성 (coherence)을 회복할 수 있는 가장 작은 레인 (lane)이다.

이는 단순히 오픈 소스 기여에만 유용한 것이 아닙니다. 일반적인 AI 보조 개발 (AI-assisted development) 전반에 유용합니다.