당신의 AI 코딩 에이전트에게 필요한 것은 더 똑똑한 모델이 아니라 백로그(Backlog)입니다

코딩 에이전트(Coding agents)가 실제 업무에서 성공하고 실패하는 과정을 1년 동안 지켜보며 제가 내린 불편한 결론은 다음과 같습니다. 모델(Model)은 거의 결코 병목 현상(Bottleneck)의 원인이 아닙니다. Claude Code와 Codex는 모두 당신이 요청하는 기능을 수행할 능력이 충분합니다. 실행을 망치는 것은 에이전트가 자신이 구축해야 할 진실을 볼 수 없다는 점입니다. 즉, 스토리(Story), 수락 기준(Acceptance criteria), 준수해야 할 아키텍처 결정(Architecture decision), 그리고 재작성하려는 대상에 대해 이미 존재하는 테스트(Test)를 보지 못하는 것입니다.

그래서 에이전트는 추측합니다. 그 추측은 국소적으로는 합리적이지만 전체적으로는 틀리며, 당신은 그 오류를 되돌리는 데 오후 시간을 허비하게 됩니다. 본능적으로 더 똑똑한 모델을 찾게 되겠지만, 진짜 해결책은 모델에게 당신의 백로그(Backlog)를 제공하는 것입니다.

컨텍스트(Context)를 붙여넣는 방식이 작동하지 않는 이유

우리 대부분은 컨텍스트를 붙여넣는 방식으로 에이전트에게 정보를 제공합니다. 티켓(Ticket)을 붙여넣고, 몇 개의 파일 경로를 넣고, 아마도 배경 설명 한 단락 정도를 넣은 뒤 실행을 맡깁니다. 이는 독립적인 작업에는 효과적이지만, 작업이 시스템의 나머지 부분과 맞닿는 순간 무너집니다.

이유는 간단합니다. 붙여넣은 컨텍스트는 스냅샷(Snapshot)이며, 스냅샷은 동일한 세션 내에서도 유효 기간이 지나버립니다. 에이전트가 세 번째 단계에서 변경을 수행하면 첫 번째 단계에서 붙여넣었던 가정이 무효화되지만, 붙여넣은 텍스트는 업데이트되지 않습니다. 따라서 일곱 번째 단계에 이르면 에이전트는 더 이상 존재하지 않는 프로젝트 버전을 바탕으로 추론하게 됩니다. 당신은 에이전트에게 컨텍스트를 주는 것이 아니라, 컨텍스트를 찍은 사진을 주면서 움직이는 방 안을 항해하라고 요구하는 것과 같습니다.

두 번째 문제는 실제 기능을 구현하는 데 정말 중요한 것은 단락(Paragraph)이 아니라 관계(Relationship)라는 점입니다. 어떤 아키텍처 결정이 이 스토리를 제약하는지, 어떤 테스트가 이 수락 기준을 검증하는지, 이 영역에서 마지막으로 발견된 결함(Defect)이 무엇인지와 같은 것들 말입니다. 이 중 그 어떤 것도 당신이 붙여넣을 수 있는 단락 안에 들어있지 않습니다. 그것들은 산출물(Artifacts) 사이의 연결 고리 속에 존재하며, 붙여넣기 방식은 이 모든 것을 에이전트가 다시 추론해야 하는 산문(Prose)으로 평면화시켜 버립니다.

분명히 말씀드리자면, 이것은 모델이 중요하지 않다는 주장이 아닙니다. 더 나은 모델은 적절한 입력값(Inputs)이 주어졌을 때 진정으로 더 뛰어난 추론(Reasoning) 능력을 보여줍니다. 제 주장은 더 좁고 유용한 범위에 있습니다. 대부분의 팀이 더 큰 작업에서 실제로 맞닥뜨리는 실패 사례들에 있어서는, 모델을 업그레이드하는 것보다 입력값을 수정하는 것이 더 효과적이며 비용도 저렴합니다.

에이전트에게 실제로 필요한 것

에이전트에게 필요한 것은 한 번 붙여넣은 텍스트의 벽이 아니라, 필요할 때마다 즉시 쿼리(Query)할 수 있는 신뢰할 수 있는 정보원(Source of truth)입니다.

에이전트가 쿼리를 할 수 있게 되면, 에이전트는 자신이 필요로 하는 바로 그 순간의 현재 상태(Current state)를 가져옵니다. 코드를 작성하기 직전에 "이 스토리의 수락 기준(Acceptance criteria)은 무엇인가?"라고 묻습니다. 세션 시작 시점에 물어보고 그 사이 내용이 어긋나버리는 방식이 아닙니다. 모듈을 다시 작성하기 전에 "이 모듈을 이미 커버하고 있는 테스트는 무엇인가?"라고 물어봄으로써, 존재조차 몰랐던 기능을 망가뜨리는 일을 방지합니다. 경계를 넘어가기 전에 "어떤 결정 사항이 이 경계를 규정하는가?"라고 묻습니다. 컨텍스트(Context)는 기억되는 것이 아니라 가져오는 것이기에 실시간(Live) 상태를 유지합니다.

이것이 작동하려면 두 가지 조건이 충족되어야 합니다. 첫째, 정보(Truth)가 구조화되고 연결된 형태(Structured, linked form)로 존재해야 하며, 둘째, 에이전트가 그 정보에 도달할 수 있는 방법이 있어야 합니다. 첫 번째는 제품(Product)의 문제이며, 두 번째는 프로토콜(Protocol)의 문제인데, 이제 그 프로토콜이 존재합니다.

MCP는 이 과정을 매우 쉽게 만들어준 요소입니다

Model Context Protocol (MCP)은 이것이 단순한 연구 프로젝트가 아니라 갑자기 실용적인 기술이 된 이유입니다. MCP는 Claude Code나 Codex와 같은 에이전트가 외부 시스템을 호출하여 구조화된 데이터(Structured data)를 읽거나 쓸 수 있는 표준 방식입니다. 여러분이 백로그(Backlog)를 프롬프트(Prompt)에 복사해 넣는 대신, 에이전트는 다른 도구를 호출하는 것과 동일한 방식으로 서버에 연결하여 백로그를 직접 쿼리합니다.

이것이 왜 거의 항상 벡터 검색 (Vector Search)을 의미하는 일반적인 "당신의 데이터를 아는 AI"라는 홍보 문구보다 뛰어난지 정확히 짚고 넘어갈 가치가 있습니다. 문서를 임베딩 (Embedding)하고 가장 유사한 구절을 검색하는 방식은 "이 페이지를 요약해줘"와 같은 작업에는 괜찮지만, "어떤 결정 사항이 이 스토리를 제약하는가"와 같은 질문에는 쓸모가 없습니다. 왜냐하면 유사성 (Similarity)은 관계 (Relationship)와 같지 않기 때문입니다. 그래프 (Graph)는 순회 (Traversal)를 통해 관계 질문에 답합니다. 즉, 이 스토리에서, 해당 에픽 (Epic) 내의 결정 사항들로, 그리고 동일한 경계 (Boundary)를 접하는 결정 사항들로 이어지는 식입니다. 검색이 통계적 (Statistical)인 것이 아니라 구조적 (Structural)으로 이루어지며, 구조야말로 작업이 하나 이상의 파일에 걸쳐 있을 때 코딩 에이전트 (Coding Agent)에게 정확히 필요한 것입니다.

구체적인 전후 비교

일반적인 요청을 예로 들어보겠습니다: API 엔드포인트 (Endpoint)에 속도 제한 (Rate Limiting) 기능을 추가하라.

복사-붙여넣기 (Paste) 워크플로우에서는 티켓을 복사하고, 엔드포인트를 언급한 뒤 에이전트에게 맡깁니다. 에이전트는 합리적인 속도 제한 코드를 작성합니다. 하지만 코드베이스에 이미 속도 제한 유틸리티 (Utility)가 있다는 사실은 알지 못합니다. 왜냐하면 복사한 내용에 포함되지 않았기 때문이며, 결과적으로 이제 두 개의 유틸리티가 존재하게 됩니다. 또한, 제한 사항은 핸들러 (Handler)가 아닌 게이트웨이 (Gateway)에 위치해야 한다는 아키텍처 결정 (Architecture Decision) 사항도 알지 못합니다. 해당 ADR (Architecture Decision Record)이 아무도 연결해두지 않은 별도의 도구에 있기 때문입니다. 에이전트는 테스트를 작성하지만, 테넌트별 (Per-tenant) 제한에 관한 수락 기준 (Acceptance Criterion, AC)에 부합하는 테스트는 작성하지 못합니다. AC가 다른 탭에 있었기 때문입니다. 코드는 리뷰 단계에서 괜찮아 보이지만, 세 가지 조용한 방식으로 잘못되어 있습니다.

쿼리 가능 (Queryable) 워크플로우에서는 에이전트가 스토리를 읽고, 테넌트별 수락 기준을 확인하며, 해당 영역의 아키텍처 결정 사항을 쿼리하여 게이트웨이 규칙을 찾아냅니다. 또한 기존 테스트를 확인하여 유틸리티를 찾아내고, 이 모든 것을 바탕으로 코드를 작성합니다. 결과로 돌아오는 풀 리퀘스트 (Pull Request, PR)는 단순히 그럴듯한 수준을 넘어, 당신의 시스템이 이미 작동하는 방식과 일관성을 유지합니다. 당신은 고고학적 발굴 (Archaeology)이 아니라 의도 (Intent)를 리뷰하게 됩니다.

두 실행 모두에서 사용된 모델은 동일했습니다. 입력값 (Inputs)이 달랐을 뿐입니다.

컨텍스트 (Context)가 문제인지 확인하는 빠른 방법

최근 발생한 에이전트의 실패 사례 5가지를 살펴보고 분류해 보세요. 만약 에이전트가 당신의 시스템이 작동하는 방식에 대해 잘못된 코드를 생성했다면, 그것은 컨텍스트 (Context) 문제이며, 플러밍 (Plumbing, 연결 구조) 작업이 이를 해결합니다. 만약 기술적으로는 문제가 없지만 잘못된 문제를 해결하는 코드를 생성했다면, 그것은 명확성 (Clarity) 문제이며, 더 나은 수락 기준 (Acceptance criteria)이 이를 해결합니다. 만약 단순한 작업에서 단순히 품질이 낮은 코드를 생성했다면, 그것은 더 나은 모델 (Model)이 실제로 도움이 되는 유일한 경우입니다. 제 경험상 첫 번째 범주가 압도적으로 가장 크며, 해결 비용도 가장 저렴합니다.

이것이 도움이 되지 않는 경우, 그리고 단순함이 정답인 경우

만약 당신의 작업이 진정으로 작고 독립적이라면 — 즉, 스크립트, 단일 파일 변경, 일회성 프로토타입 등이라면 — 이 모든 것은 중요하지 않습니다. 그냥 컨텍스트를 붙여넣고 넘어가면 됩니다. 화면 하나에 들어오는 작업에 대해 신뢰할 수 있는 단일 출처 (Source of truth)를 연결하는 것은 과잉 대응 (Overkill)입니다.

만약 당신의 컨텍스트 문제가 실제로는 명확성 문제라면, 어떤 플러밍 작업도 이를 해결할 수 없습니다. "에이전트가 잘못된 일을 했다"는 사례의 절반은 사실 "누구도 완료(Done)의 의미를 검증 가능한 용어로 정의한 적이 없다"는 뜻입니다. 만약 당신의 수락 기준 (Acceptance criteria)이 모호한 산문 형태라면, 에이전트 또한 모호한 산문을 만들어낼 것입니다.

그리고 만약 당신이 에이전트와 이미 깊게 통합되어 있는 하나의 도구 안에서만 완전히 생활한다면, 이미 충분한 환경을 갖추고 있을 수도 있습니다. 격차 (Gap)는 에이전트가 필요로 하는 진실이 트래커 (Tracker), 문서 (Docs), 다이어그램 (Diagrams), 테스트 도구 (Test tool) 등에 흩어져 있고, 이들이 서로 소통하지 않을 때 나타납니다.

에이전트를 바라보는 나의 사고방식의 변화

예전에는 에이전트를 개선해야 할 대상으로 취급했습니다. 더 나은 프롬프트 (Prompts), 더 나은 모델 (Model), 프롬프트 주변의 더 나은 툴링 (Tooling). 이제 저는 에이전트를 고정된 값으로 보고, 컨텍스트 (Context)를 변수로 취급합니다. 유능한 모델이 주어졌을 때, 출력의 품질은 대부분 에이전트가 행동하는 순간에 무엇을 볼 수 있는지에 따른 함수입니다. 에이전트가 볼 수 있는 것을 개선하면, 동일한 모델이 동일한 작업에서, 동일한 날에 눈에 띄게 더 나은 성능을 보여줍니다.

그러한 관점의 전환은 해방감을 줍니다. 왜냐하면 컨텍스트 (Context)는 당신이 통제할 수 있는 영역이기 때문입니다. 오늘 오후에 모델을 더 똑똑하게 만들 수는 없습니다. 하지만 오늘 오후에 당신의 백로그 (Backlog)를 모델에게 제공하는 것은 확실히 가능합니다.

이것이 제가 결국 Stride를 구축하게 된 핵심 논지입니다. 즉, 스토리 (Stories), 테스트 (Tests), 그리고 아키텍처 결정 사항 (Architecture decisions)들이 하나의 연결된 그래프 (Graph)로 이루어져 있으며, 이것이 MCP를 통해 코딩 에이전트 (Coding agents)에게 노출되어 에이전트가 복사해서 붙여넣은 내용이 아닌 실제 데이터를 읽을 수 있도록 하는 것입니다. 하지만 이 아이디어는 당신이 무엇을 사용하든 그 자체로 유효합니다. 에이전트에게 백로그의 사진을 보여주지 말고, 백로그 그 자체를 제공하십시오.

작업 단위가 단일 파일보다 커졌을 때, 에이전트가 현실에 기반을 두도록 (Grounded) 하기 위해 여러분은 무엇을 하고 계신가요? 저는 다양한 접근 방식들을 수집하고 있으며, 여러분의 의견을 진심으로 듣고 싶습니다.