에이전트는 내가 요청한 것을 정확히 수행했고, 그것이 문제였다

2022년 당시, AI 코딩 어시스턴트(AI coding assistant)와 함께 일한다는 것은 브라우저 탭을 하나 열어두어야 한다는 것을 의미했습니다.

질문을 입력하면, 코드 블록을 받았습니다. 그리고 그것이 어디에 들어가야 할지 직접 파악해야 했습니다. 그게 전부였습니다.

그 제안들은 사전(dictionary)이 유용한 방식과 비슷하게 유용했습니다. 기술적으로는 정확했지만, 당신이 실제로 무엇을 만들고 있는지는 전혀 알지 못했습니다. 당신은 출력된 결과물들을 직접 하나하나 이어 붙이고 다음 단계로 넘어갔습니다.

컨텍스트(Context) 문제가 좁혀지기 시작하다

그러다 2024년 말에 이르렀습니다.

MCP(Model Context Protocol)가 등장했습니다. 컨텍스트 파이프라인(Context pipelines). 당신의 패턴을 읽고, 명명 규칙(naming conventions)을 따르며, 당신이 작업 중인 도메인(domain)을 이해할 수 있는 코드베이스 인식 에이전트(Codebase-aware agents)가 나타났습니다. 에이전트는 더 이상 단순히 질문에 답만 하는 존재가 아니었습니다. 에이전트는 프로젝트와 구조, 그리고 당신이 이미 구축해 놓은 용어들을 알고 있었습니다.

이것은 진정한 단계적 변화(step change)였습니다. 과장이 아니었습니다.

하지만 복잡한 작업에서는 여전히 무언가 제대로 작동하지 않았습니다.

단일 기능 작업은 괜찮았습니다. 고립된 변경 사항들은 깔끔하게 적용되었습니다. 하지만 범위가 모듈을 넘나들고, 경계를 넘고, 코드베이스의 전체 표면적을 가로지르게 되면 에이전트는 표류하기 시작했습니다. 에이전트는 눈에 보이는 문제는 해결했지만, 눈에 보이지 않는 문제들을 남겨두었습니다.

저는 이를 알아차렸습니다. 저는 더 나은 계획이 필요하다고 가정했습니다.

그 점에 대해서는 제 생각이 맞았습니다. 하지만 그 외의 거의 모든 것에 대해서는 틀렸습니다.

에이전트는 내가 요청한 것을 정확히 수행했습니다. 그것이 문제였습니다.

작업 내용: 전체 React Native 애플리케이션에 걸친 글로벌 이벤트 메커니즘(global event mechanism) 및 컴포넌트 통신 레이어(component communication layer) 구축.

이것은 작은 작업이 아니었습니다. 집중력 있는 엔지니어가 수작업으로 진행한다면 최소 2주는 걸릴 작업이었습니다. 에이전트는 도메인을 잘 이해하고 있었습니다. 저는 2주가 2일로 단축될 것을 기대하며 작업을 맡겼습니다.

저는 계획을 세웠습니다. 검토했습니다. 승인했습니다.

에이전트도 저도 계획이 다루지 못한 부분을 알아차리지 못했습니다. 바로 이벤트 완화 범위(event mitigation scope) 밖에 존재하는 조건부 로드되는 수동적 컴포넌트(conditionally-loaded passive components)들이었습니다. 영향 지도(impact map)도 없었습니다. 폭발 반경 분석(blast radius analysis)도 없었습니다. 검증 시나리오(verification scenarios)도 없었습니다. 제대로 된 엔지니어링 스프린트(engineering sprint)라면 이를 1~2 스프린트 분량의 프로덕션 아티팩트(production artifact)로 취급했을 것입니다. 하지만 우리는 이것을 단순한 채팅 출력물(chat output)로 취급했습니다.

에이전트는 승인된 계획을 실행했습니다. 정확하게 말이죠.

그 문장은 성공처럼 들려야 합니다. 하지만 그렇지 않습니다.

완료된 것처럼 보였습니다. 하지만 아니었습니다.

수동적(Passive)이고 조건부(conditional)인 컴포넌트들은 이벤트 완화 범위(event mitigation scope)에서 완전히 벗어나 있었습니다. 해당 섹션의 상태 변경(State changes)이 올바르게 렌더링되지 않았습니다. UI는 아무도 확인해 볼 생각을 하지 못했던 부분에서 깨졌고, 이는 제가 계획에서 조용히 건너뛴 앱의 부분들을 사용함으로써에야 비로소 그 문제들을 발견했음을 의미했습니다.

중복 문제는 눈에 보이지 않았기에 더 심각했습니다. 이벤트 핸들링(Event handling)이 여러 위치에 걸쳐 연결되어 있었습니다. 저는 이벤트 흐름(event flow)을 추적하기 위해 콘솔 로그(console logs)를 추가하고, 동일한 이벤트가 한 번 이상 발생하는 것을 지켜본 후에야 이를 포착할 수 있었습니다.

세 번째 실패는 달랐습니다. 에이전트는 이벤트 기반 아키텍처(event-driven architecture)를 위해 Context와 Redux를 조합하여 사용했습니다. 요청하지도 않은 보일러플레이트(boilerplate)를 추가했고, 범위(scope)에도 없고, 계획에도 없으며, 제가 원하지도 않는 구현 패턴(implementation pattern)을 만들어냈습니다. 저는 다시 일반 텍스트로 돌아가 실제로 어떻게 작동해야 하는지 설명하고 수정을 요청해야 했습니다.

그것은 제가 계속해서 되묻게 되는 질문을 던졌습니다: 왜 AI는 요청하지 않은 것, 범위 밖의 일을 수행하는가?

그 답은 결함(defect)이 아닙니다. 그것은 제약(constraint)의 부재입니다. 달리 규정하는 규칙이 없었습니다. 에이전트는 그 공백을 자신의 최선의 추측으로 채웠습니다. 그리고 그 최선의 추측은 틀렸습니다.

추적 없음. 체크포인트 없음. 바닥 없음.

태스크 추적(task tracking)이 존재하지 않았습니다. 검증 로그(verification log)도 없었습니다. 회귀 체크포인트(regression checkpoints)도 없었습니다.

제가 피드백으로 제공한 각 관찰 사항은 즉시 구현되었습니다.

코드 위에 코드가 층층이 쌓였습니다. 채팅 스레드(chat thread)는 너무 길어졌습니다.

저는 내용을 요약하여 새 채팅을 시작했습니다. 거기서부터 다시 시작했습니다.

잠시 작동했습니다. 그러다 새로운 문제들을 일으켰습니다.

패턴이 계속 반복되었습니다.

3일째 되는 날, 구현은 원래 계획과 70-75% 일치했습니다. 무엇이 검증되었고, 무엇이 검증되지 않았으며, 무엇이 여전히 인간의 결정이 필요한지에 대한 명확한 기록이 없었습니다. 그저 긴 채팅 메시지 시퀀스와 취약한 코드뿐이었습니다.

3일째 되는 날 끝에 저는 그것을 작동시켰습니다. 만족스럽긴 했지만, 깔끔하지는 않았습니다.

코딩은 결코 문제가 아니었습니다

저는 실패의 원인이 코드 품질에 있을 것이라고 가정하고 접근했습니다. 복잡한 로직, 엣지 케이스 (edge cases), 놓친 조건들 같은 것 말이죠.

하지만 그것이 아니었습니다.

에이전트는 충분한 컨텍스트 (context)를 가지고 있었습니다. 코드를 작성할 수도 있었습니다. 에이전트가 할 수 없었던 것은 실제 작업이 무엇인지 결정하는 것이었습니다. 이것은 도구의 한계가 아닙니다. 역할의 경계 (role boundary) 문제입니다.

프로세스 도중도, 끝난 후도 아닙니다. 바로 시작 단계에서 말입니다.

프로세스 도중에는 인간의 검토 (human review)가 실수가 발생한 후에 이를 잡아냅니다. 하지만 시작 단계에서는 인간의 판단 (human judgment)이 무언가가 시작되기 전에 그 표면적 (surface area)을 정의합니다.

그 깨달음은 저를 탐색하게 만들었습니다. 3일 후, 저는 기존 솔루션들을 조사하고 몇 가지를 테스트해 보았습니다. 그것들은 작동합니다. 매우 잘 설계되어 있습니다. 하지만 그것들은 일반적인 사례 (general case)를 위해 만들어졌습니다. 그것들을 진지하게 사용하려면, 여러분의 스택 (stack), 여러분의 컨벤션 (conventions), 프로젝트의 특정 제약 조건에 맞게 조정해야 합니다. 그 간극이야말로 아무도 여러분을 위해 패키징해 주지 않는 부분입니다.

저는 직접 만들고, 망가뜨리고, 다시 만들어보지 않은 것을 추천하고 싶지 않았습니다. 직접 경험하기보다 읽어서만 알고 있는 워크플로우 (workflow)에 대해 쓰고 싶지도 않았습니다. 그 워크플로우가 버텨낼 수 있을지도 확신할 수 없었습니다.

제가 놓치고 있었던 것은 더 나은 도구가 아니었습니다. 그것은 계약 (contract)이었습니다.

7단계 (Seven phases). 다음 단계가 시작되기 전, 인간이 모든 인수인계 (handoff)를 승인합니다.

다음 섹션에서 이 내용을 다룹니다.