누군가가 AI 코딩 에이전트(AI coding agent)를 사용하여 실제로 복잡한 시스템을 구축하는 데 시간을 들였는지는 보통 바로 알 수 있습니다.

단순히 빠른 앱을 생성하고, 작동하게 만든 뒤 떠나버리는 것을 의미하는 것이 아닙니다. 저는 여러 스택(stacks)에 걸쳐, 긴 세션 동안, 반복적인 변경을 거치며, 한 명의 개발자와 에이전트 사이의 수백 번의 주고받는 과정(back-and-forth turns)을 통해 시간이 흐르며 구축하는 것을 의미합니다.

그 과정을 한 번이라도 경험해 본다면, 드리프트(drift)가 어디서 시작되는지 눈에 보이기 시작할 것입니다.

드리프트는 Scarab 진단 스위트(diagnostic suite)의 이론적 핵심입니다.

Scarab은 코드베이스(codebases) 내부의 드리프트를 탐색합니다. 즉, 저장소(repository)가 더 이상 스스로와 일관성을 유지하지 못하는 지점을 찾습니다. 그러한 드리프트는 개발자가 작성한 코드, AI가 생성한 코드, 또는 두 가지가 결합되어 구축된 코드 모두에서 존재할 수 있습니다.

하지만 AI 코딩 에이전트와 함께 Scarab을 개발하면서, 저는 별개의 종류의 드리프트를 주목하기 시작했습니다.

저는 이미 드리프트라는 관점으로 소프트웨어를 바라보고 있었기 때문에, 에이전트 자체가 맥락을 놓치기 쉬운 지점—워크플로(workflow), 책임(responsibility), 또는 아키텍처 경계(architectural boundary)에 대한 에이전트의 해석이 제가 실제로 의도한 바에서 벗어나기 시작하는 지점—을 볼 수 있었습니다.

이것들이 바로 AI 특유의 드리프트 표면(AI-specific drift surfaces)입니다.

이는 Scarab이 진단하는 저장소 드리프트(repository drift)와는 별개이지만, 하나가 결국 다른 하나를 만들어낼 수도 있습니다.

에이전트가 모호한 무언가를 마주합니다. 그것을 한 가지 방식으로 해석합니다. 그리고 그 해석을 코드에 반영합니다. 에이전트의 이해 과정에서 시작된 드리프트는 나중에 저장소 내부의 드리프트로 변할 수 있습니다.

명명(Naming)은 가장 단순한 예 중 하나입니다.

명명은 소프트웨어에서 항상 중요했지만, 코드를 읽고 수정하는 주체가 언어 모델(language model)일 때는 그 중요성이 다르게 작용합니다.

AI 코딩 에이전트는 언어를 통해 시스템을 재구성합니다.

함수 이름(Function names), 파일 이름(filenames), 워크플로 이름(workflow names), 주석(comments), 스키마(schemas), 테스트(tests), 문서화(documentation), 그리고 폴더 구조(folder structures) 모두가 에이전트가 코드베이스를 이해하는 방식을 형성합니다.

저장소는 지속적인 프롬프트(persistent prompt)가 됩니다.

두 개의 문서 검색 워크플로가 있는 시스템을 상상해 보십시오.

첫 번째는 소유권과 경계(ownership and boundaries)를 검색합니다. 즉, 책임이 어디에 존재하는지, 시스템의 어느 부분이 이를 제어하는지, 그리고 어떤 규칙이 이를 지배하는지를 찾습니다.

두 번째는 구현 사례(implementation examples)를 검색합니다. 해당 책임이 어떻게 표현되었는지를 보여주는 실제 코드, 구문(syntax), 또는 스크립트를 찾습니다.

이 둘은 서로 연관되어 있지만, 동일한 작업을 수행하는 것은 아닙니다.

하나는 경계를 찾습니다.

다른 하나는 구현을 찾습니다.

이제 두 워크플로가 모두 어떤 형태의 "가이드 검색(guidance search)"으로 기술되어 있다고 상상해 보십시오.

개발자는 각 워크플로가 왜 존재하는지 기억하고 있기 때문에 그 차이를 이해할 수 있을지도 모릅니다.

하지만 이름(naming)은 그 구분을 보존하지 못합니다.

그것이 바로 에이전트(agent)를 위한 드리프트 표면(drift surface)입니다.

나중에 에이전트에게 해당 워크플로 중 하나를 확장하라는 요청을 받게 되면, 언어(language)가 에이전트를 잘못된 추상화(abstraction)로 이끌 수 있습니다. 분리되어 있어야 할 책임들을 결합하거나, 아키텍처(architecture)에 대한 모호한 해석을 바탕으로 새로운 코드를 생성할 수도 있습니다.

코드는 여전히 작동할 수도 있습니다.

하지만 시스템에 대한 에이전트의 이해는 어긋나(shifted) 있습니다.

그리고 그 어긋난 이해가 새로운 코드를 형성하기 시작하면, 저장소(repository) 또한 드리프트(drift)되기 시작할 수 있습니다.

이것은 단순히 빠른 래퍼(wrapper)를 만들거나 수명이 짧은 프로토타입(prototype)을 만들 때는 반드시 눈에 띄는 현상은 아닙니다.

작은 규모의 빌드에서는 개발자가 여전히 시스템의 외부 메모리(external memory) 역할을 할 수 있습니다. 개발자는 모든 것이 무엇을 의미하는지 기억하며, 에이전트가 혼란을 겪을 때 방향을 다시 잡아줄 수 있습니다.

하지만 그것은 확장(scale)될 수 없습니다.

더 큰 시스템에서는 코드베이스(codebase)가 스스로의 의미를 담고 있어야 합니다. 중요한 경계가 개발자의 머릿속에만 존재해서는 안 됩니다. 에이전트가 나중에 이를 재구성할 수 있을 만큼 충분히 명확하게 표현되어야 합니다.

이것이 모호한 명명(ambiguous naming)이 단순히 지저분한 코드에 그치지 않는 이유입니다.

그것은 AI 드리프트(AI drift)가 시작될 수 있는 지점입니다.

취약한 이름은 에이전트에게 취약한 지도(map)를 제공합니다. 그리고 취약한 지도는 에이전트가 검색하고, 컨텍스트(context)를 검색(retrieve)하며, 추상화를 선택하고, 새로운 코드가 어디에 속해야 하는지를 결정하는 방식에 영향을 미칩니다.

코드베이스의 드리프트를 탐지하는 제품을 만들면서, 저는 AI로 무언가를 만드는 과정 속에서 드리프트를 포착하는 법을 배웠습니다.

그리고 AI가 실제 소프트웨어 시스템을 유지 관리하고 확장하는 데 더 많이 관여하게 됨에 따라, 우리는 이러한 드리프트 표면 (drift surfaces)에 대해 훨씬 더 나은 이해가 필요할 것이라고 생각합니다.

왜냐하면 때때로 코드는 여전히 작동할 수도 있기 때문입니다.

하지만 아키텍처 (architecture)는 이미 드리프트 (drift)된 상태일 수 있습니다.