진단 도구를 만들고 있다고 생각했습니다. 하지만 AI 에이전트를 위한 운영 계층(Operating Layer)을 발견했습니다.

Scarab Diagnostic Suite가 형태를 갖추기 시작했을 때, 저는 제가 진단 도구(diagnostics)를 만들고 있다고 생각했습니다.

그것이 가장 명확한 표현이었기 때문입니다.

AI 코딩 에이전트들은 코드를 빠르게 변경하고 있었습니다. 저장소(Repos)는 표류하고 있었습니다. 버그는 이상한 곳에서 나타났습니다. 테스트는 올바른 것을 증명하지 못한 채 통과되었습니다. 파일들은 소유해서는 안 될 동작의 소유권을 가져가고 있었습니다.

그래서 첫 번째 질문은 간단했습니다:

시스템이 엉망이 된 저장소에 투입되어, 실제 실패 지점(failure surface)을 찾아내고, 상황을 악화시키지 않으면서 좁은 수리 경로(repair lane)를 식별할 수 있는가?

그것이 Scarab이 시작된 지점입니다.

그리고 그 모드(mode)가 중요합니다.

AI 지원 소프트웨어 개발(AI-assisted software development)을 진지하게 수행하는 사람이라면 누구나 이제는 이 패턴을 보았을 것이기 때문입니다.

에이전트가 한 가지 문제를 패치합니다.

그 패치가 시스템의 다른 부분을 방해합니다.

에이전트가 그것을 다시 패치합니다.

그러면 또 다른 숨겨진 가정이 깨집니다.

그러면 테스트가 조정됩니다.

그러면 임시방편(workaround)이 구조(structure)가 됩니다.

그러다 결국, 저장소는 더 이상 스스로의 모습과 완전히 닮지 않은 방식으로 "작동"하게 됩니다.

시스템은 돌아갑니다.

하지만 진실은 표류했습니다.

실패 유형 (The failure class)

그것이 Scarab Systems가 구축된 중심이 되는 실패 유형입니다.

단순히 깨진 코드가 아닙니다.

소프트웨어 표류(Software drift).

경계 실패(Boundary failures).

저장소-진실 불일치(Repo-truth misalignment).

검증 격차(Verification gaps).

엔트로피(Entropy).

코드는 기능적으로 보이지만, 저장소가 자체 아키텍처, 의무, 그리고 의도된 형태로부터 멀어져 버린 조용한 순간 말입니다.

지난 몇 주 동안, Scarab은 주요 오픈 소스 플랫폼에 대한 패치 및 진단 보고서를 포함하여 30개 이상의 공개 소프트웨어 실패 지점(failure surfaces)에서 현장 테스트를 거쳤습니다.

이러한 공개적인 현장 기록이 중요한 이유는 첫 번째 모드를 증명하기 때문입니다:

Scarab은 활성화된 실패 지점에 진입하여, 진실을 보존하는 것을 중단시킨 경계를 식별하고, 저장소의 나머지 부분을 무심코 망가뜨리지 않는 좁은 수리 경로를 안내할 수 있습니다.

하지만 더 흥미로운 발견은 Scarab이 버그를 찾는 데 도움을 줄 수 있다는 것뿐만이 아니었습니다.

더 흥미로운 발견은 진실된 수리(truthful repair)는 다르게 작동한다는 것이었습니다.

진실된 수리는 다르게 작동합니다

대부분의 패칭 (patching) 작업은 증상을 쫓는 경향이 있습니다.

여기에 버그가 나타납니다.

저기에 임시 방편 (workaround)이 나타납니다.

다른 어딘가에서 테스트가 조정됩니다.

저장소 (repo)는 눈에 보이는 오류와 국소적인 패치 (local patches) 사이의 협상 과정으로 서서히 변해갑니다.

하지만 수리 (repair)가 저장소의 실제 진실 (actual truth)과 일치할 때는 다른 일이 일어납니다.

수리는 단순히 눈에 보이는 실패를 침묵시키는 데 그치지 않습니다.

저장소를 자기 자신에게 더 가깝게 이동시킵니다.

그 차이가 중요합니다.

저장소는 추상적인 "작동하는 버전"이 될 필요가 없습니다.

저장소는 자신이 실제로 지켜야 할 의무가 있는 시스템을 보존해야 합니다.

이것이 제가 Scarab을 개별적인 실패를 위한 진단 도구로만 생각하기를 멈춘 이유입니다.

두 번째 모드는 단계적 수리 (stepwise repair)입니다.

엔트로피 관리 (entropy management)가 아닌 단계적 수리

엉망이 된 AI 보조 저장소 (AI-assisted repos)에서 실패는 항상 고립되어 있지 않습니다.

실패는 핫스팟 (hot spots)에 모입니다.

하나의 버그는 더 깊은 경계 문제 (boundary problem)의 눈에 보이는 가장자리일 수 있습니다.

하나의 테스트 실패는 이동된 책임 (responsibility)을 반영하는 것일 수 있습니다.

하나의 런타임 (runtime) 이슈는 퍼져 나간 잘못된 가정을 드러내는 것일 수 있습니다.

하나의 생성된 아티팩트 (artifact)가 조용히 소스 진실 (source truth)로 취급되었을 수도 있습니다.

만약 코딩 에이전트 (coding agent)가 저장소의 진실된 경계 (truthful boundaries)를 이해하지 못한 채 한 번에 하나의 버그만 수리한다면, 영원히 굴레를 돌 수 있습니다:

• 버그를 패치합니다.
• 패치가 망가뜨린 것을 패치합니다.
• 새로운 임시 방편 (workaround)을 패치합니다.
• 테스트를 패치합니다.
• 부작용 (side effect)을 패치합니다.
• 패치를 패치합니다.

그것은 수리가 아닙니다.

그것은 엔트로피 관리 (entropy management)입니다.

Scarab은 다른 이론을 바탕으로 개발되고 있습니다:

만약 수리가 저장소의 진실된 경계를 따라 일어난다면, 시스템을 단계적으로 고요함 (quiet)을 향해 이끌 수 있습니다.

오류가 숨겨져서 고요한 것이 아닙니다.

저장소가 더 일관성 (coherent) 있게 변하고 있기 때문에 고요한 것입니다.

그것은 매우 다른 차원의 이야기입니다.

진실된 경계 수리 (truthful boundary repair)는 좋은 방향으로 파동을 일으킬 수 있습니다.

인접한 실패 표면 (failure surfaces)에 가해지는 압력을 줄일 수 있습니다.

소유권 (ownership)을 명확히 할 수 있습니다.

임시 방편 (workaround)의 필요성을 제거할 수 있습니다.

테스트를 다시 의미 있게 만들 수 있습니다.

소스 진실 (source truth)과 다운스트림 출력 (downstream output) 사이의 차이를 복구할 수 있습니다.

이는 시스템을 패치된 추상화(patched abstraction) 속으로 끌어들이는 대신, 베이스라인(baseline)에 더 가깝게 가져다줄 수 있습니다.

그 부분이 바로 AI 코딩 에이전트의 미래에 중요하다고 생각하는 지점입니다.

Scarab은 코딩 에이전트를 대체하지 않습니다

다음 단계의 중대한 도약은 단순히 에이전트를 더 빠르게 만드는 것이 아닙니다.

그들은 이미 빠릅니다.

다음 도약은 그들이 움직이는 동안 일관성(coherence)을 파괴하지 않도록 보장하는 것입니다.

하지만 이 부분이 중요합니다:

Scarab은 AI 코딩 에이전트를 대체하려는 것이 아닙니다.

그것은 또 다른 모델이 아닙니다.

두 번째 개발자도 아닙니다.

마법 같은 정답을 알려주는 오라클(oracle)도 아닙니다.

Scarab Diagnostic Suite는 코딩 에이전트가 실행에 옮길 수 있도록, 저장소(repo)에 근거한 올바른 종류의 결과물(findings)을 생성하는 기술적 진단 계층(diagnostic layer)입니다.

에이전트는 여전히 구현자(implementer)입니다.

인간은 여전히 의도(intent)를 제공합니다.

Scarab은 저장소를 읽고, 관련 있는 진실의 표면(truth surfaces)을 식별하며, 경계 조건(boundary conditions)을 노출하고, 에이전트가 올바른 경로를 유지할 수 있도록 증거에 기반한 결과물을 반환합니다.

이것이 바로 이 시스템이 소프트웨어 불가지론적(software-agnostic)이고 에이전트 불가지론적(agent-agnostic)일 수 있는 이유입니다.

저장소를 소유할 필요가 없습니다.

워크플로우를 대체할 필요도 없습니다.

개발자가 Codex, Claude Code, Cursor, Copilot, Devin, 로컬 모델, 또는 인간 엔지니어를 사용하는지 여부를 신경 쓸 필요도 없습니다.

그 역할은 더 단순하고 기술적입니다:

• 구현자에게 더 나은 결과물을 제공합니다.
• 저장소의 진실을 더 쉽게 볼 수 있게 만듭니다.
• 복구 또는 빌드 경로가 이미 존재하는 시스템과 일치하도록 유지합니다.

에이전트는 자신의 정확성을 스스로 채점해서는 안 됩니다

진정한 자율 코딩 에이전트는 추측만으로는 구축될 수 없습니다.

모델 외부에 결정론적 계층(deterministic layer)이 필요합니다.

에이전트에게 다음과 같이 말해줄 수 있는 계층 말입니다:

• 이 표면(surface)이 이 동작을 소유하고 있습니다.
• 이 경계는 함부로 움직일 수 없습니다.
• 이 아티팩트(artifact)는 소스 진실(source truth)이 아닙니다.
• 이 테스트가 이 주장을 증명합니다.
• 이 설정(config)은 이 런타임 의무(runtime obligation)를 수반합니다.
• 이 복구 경로(repair lane)는 좁습니다.
• 이 변경 사항은 저장소를 보존했습니다.
• 이 변경 사항은 드리프트(drifted)되었습니다.

에이전트는 작업을 열 때마다 저장소(repo)의 아키텍처를 매번 새로 만들어낼 필요가 없어야 합니다.

컨텍스트(context)에 우연히 들어맞는 것들 중에서 무엇이 정전(canonical)인지 결정해야 해서도 안 됩니다.

자신의 정답 여부를 스스로 채점해서도 안 됩니다.

시스템 경계(system boundaries)를 조용히 옮겨놓고 나서 빌드가 통과되었다고 발표해서도 안 됩니다.

그것은 복잡한 시스템 내부의 확률적 작업자(probabilistic worker)에게 너무 과도한 권한입니다.

저장소는 진실(truth)에 대해 자체적으로 통제된(governed) 관계를 가질 필요가 있습니다.

Scarab의 세 가지 모드

그것이 바로 Scarab이 나아가고자 하는 방향입니다.

현재 저는 세 가지 운영 모드가 형성되는 것을 보고 있습니다.

1. 공개 필드 진단 (Public field diagnostics)

실패 표면(failure surface)에 진입합니다.

경계를 식별합니다.

좁은 복구 경로(repair lane)를 생성합니다.

이 모드는 오픈 소스 이슈, 패치, 필드 리포트에서 나타나기 때문에 공개적으로 확인하기 가장 쉬운 모드입니다.

저장소에 가시적인 실패가 발생합니다.

무언가 드리프트(drifted)되었습니다.

Scarab은 다음과 같이 묻습니다:

이 시스템이 보존해야 했던 진실은 무엇인가?

어떤 경계가 그것의 보존을 중단했는가?

그 일이 어디에서 발생했음을 증명하는 증거는 무엇인가?

2. 단계적 저장소 안정화 (Stepwise repo quieting)

증상만을 영원히 쫓는 대신, 시스템을 일관성(coherence)에 더 가깝게 만드는 순서에 따라 핫스팟(hot spots)을 통과합니다.

이것이 중요한 이유는 엉망인 저장소가 항상 한 번에 하나의 버그로만 실패하지 않기 때문입니다.

저장소는 종종 압박 지점(pressure points)을 중심으로 실패합니다.

만약 복구가 저장소의 진실된 경계를 따른다면, 하나의 제대로 된 복구가 다른 곳의 압박을 낮출 수 있습니다.

시스템이 마법처럼 고쳐졌기 때문이 아닙니다.

복구가 저장소를 실제 의무(obligations)에 더 가깝게 이동시켰기 때문입니다.

3. 능동적 에이전트 거버넌스 (Active agentic governance)

이것은 제가 현재 목표로 하고 있는 모드입니다.

AI 지원 개발이 진행되는 동안 지속적인 모니터링을 수행합니다.

단순히 다음과 같은 질문이 아니라:

무엇이 고장 났는가?

다음과 같은 질문을 던집니다:

• 에이전트가 무엇을 기반으로 구축하려 하는가?
• 에이전트가 저장소의 진실(repo truth) 위에 구축하고 있는가, 아니면 잔여물(residue) 위에 구축하고 있는가?
• 이 기능이 시스템을 강화하고 있는가, 아니면 숨겨진 드리프트 표면(drift surface)을 도입하고 있는가?
• 이 레이어가 그 아래의 경계들을 보존했는가?
• 변경 이후 저장소가 더 일관성(coherent) 있게 되었는가?

그것이 제가 관심을 두고 있는 미래입니다.

누락된 레이어

인간은 자연어(natural language)로 의도(intent)를 설명합니다.

저장소(Repos)는 기계적으로 진실을 보존합니다.

AI 코딩 에이전트(AI coding agents)는 규정된 경계(governed boundaries) 안에서 작동합니다.

진단(Diagnostics)은 시스템이 일관성(coherent)을 유지했는지 검증합니다.

각각의 새로운 기능이 저장소를 더 무겁고, 생소하며, 신뢰하기 어렵게 만들어서는 안 됩니다.

각 작업 계층은 저장소 그 자체로서 저장소를 강화해야 합니다.

그것이 AI 지원 개발(AI-assisted development)의 진정한 약속입니다.

단순히 더 많은 코드가 아닙니다.

단순히 더 빠른 코드가 아닙니다.

인간이 자신에게 레버리지(leverage)를 제공해야 할 대상을 하루 종일 돌보며(babysitting) 시간을 보내는 세상이 아닙니다.

운영 경계(operating boundary)가 명확하기 때문에 에이전트가 빠르게 움직일 수 있는 세상입니다.

인간이 모든 아키텍처적 진실(architectural truth)을 머릿속에 수동으로 담아둘 필요가 없는 세상입니다.

저장소가 에이전트에게 무엇이 진실로 남아야 하는지를 말해줄 수 있는 세상입니다.

그것이 바로 진지한 자율 소프트웨어 개발(autonomous software development)에 결여되어 있다고 생각하는 레이어입니다.

그리고 그것이 Scarab Systems가 탐구하기 위해 구축되고 있는 것입니다.

공개된 필드 보고서(field reports)가 이야기의 끝은 아닙니다.

그것들은 증거의 흔적(proof trail)입니다.

더 큰 함의는 저장소 측면의 결정론적 거버넌스(deterministic governance)가 진정한 자율 코딩 에이전트를 위한 누락된 토대 중 하나일 수 있다는 점입니다.

진실 없는 자율성(autonomy)은 그저 가속(acceleration)일 뿐이기 때문입니다.

그리고 진실 없는 가속은 표류(drift)입니다.