원문은 devopsdiary.blog에 게시되었습니다. "기업 내 AI 거버넌스" 시리즈의 F-AID2 포스트입니다.

지난 2년 동안의 조언은 간단했습니다. 에이전트(agent)에게 더 많은 것을 주라는 것이었습니다. 더 많은 도구(tools). 더 큰 컨텍스트 윈도우(context window). 또 다른 규칙 파일(rules file). AI Dev 26 강연의 절반은 이와 반대되는 주장을 펼쳤으며, 그들은 데이터를 제시했습니다.

그 제안은 옳게 들리기 때문에 널리 퍼집니다. 만약 에이전트가 잘못된 답변을 내놓았다면, 무언가 부족했을 것이라고 생각하기 때문입니다. 그래서 또 다른 MCP 서버를 연결하고, 더 많은 문서를 붙여넣고, 두 번째 CLAUDE.md를 추가합니다. 하지만 결과물은 더 나빠집니다. 이제 당신은 정보가 너무 적어서가 아니라, 읽어야 할 것이 너무 많아서 발생하는 시스템을 디버깅하게 됩니다.

사람들이 믿고 있지만 사실이 아닌 네 가지

한 Stripe 엔지니어가 에이전트에게 컨텍스트(context)를 제공하는 것에 관한 네 가지 신화(myths)를 나열한 슬라이드를 올렸는데, 저 또한 불과 한 달 전에 그중 적어도 두 가지를 입 밖으로 말한 적이 있습니다.

문서에 대한 단순한 RAG (Retrieval-Augmented Generation)는 컨텍스트 엔진이 아닙니다. 더 큰 컨텍스트 윈도우(context window)가 출력 품질을 해결해주지 않습니다. 더 많은 MCP 서버를 연결한다고 해서 해결되지 않습니다. 그리고 더 많은 규칙 파일(rule files)은 확실히 도움이 되지 않습니다. 각각의 조치들은 당신이 취할 수 있는 행동이기 때문에 마치 진전이 있는 것처럼 느껴집니다.

하지만 그 중 어느 것도 실제 문제에 닿지 않습니다.

근본적인 문제는 '접근(access)'이 '이해(understanding)'는 아니라는 점입니다. 우리는 에이전트를 코드, 로그, 티켓, 문서에 연결하며, 정보를 근처에 두는 것이 모델이 그것을 이해하는 것과 같다고 가정합니다. 에이전트는 컴파일은 되지만 인간의 검토에서는 실패하는, 그럴듯한 출력을 생성합니다. 왜냐하면 에이전트에게 필요했던 것이 에이전트가 도달할 수 있는 곳 어디에도 기록되어 있지 않았기 때문입니다.

기억에 남는 슬라이드는 빙산이었습니다. 수면 위에는 에이전트가 가리킬 수 있는 코드, 문서, 티켓이 있습니다. 수면 아래에는 원래의 의도(original intent), 무언가가 그런 방식으로 구축된 이유, 아무도 문서화하지 않은 마이그레이션 플래그(migration flag), 8개월 전 Slack에서 논의된 후 삭제된 트레이드오프(trade-off)가 있습니다. 이 잠겨 있는 부분이 출력의 정답 여부를 결정합니다. 이 중 그 어떤 것도 인덱싱(index)할 수 있는 곳에 존재하지 않습니다.

더 많은 컨텍스트에는 비용이 따르며, 이는 복리로 쌓입니다

더 많은 컨텍스트를 쏟아붓는 것에는 비용이 따르며, CodeRabbit은 이것이 문제를 일으키는 네 가지 방식(bloat, dilution, conflict, latency)을 명명했습니다.

Bloat(비대화)는 명백한 문제입니다. 토큰 예산(token budget)을 초과하게 됩니다. Dilution(희석)은 더 심각합니다. 모델이 필요로 하는 신호(signal)가 여전히 그 안에 존재하지만, 모델이 이를 찾아내기 위해 헤쳐 나가야 하는 노이즈(noise) 아래에 파묻혀 있기 때문입니다. Conflict(충돌)는 위험한 문제입니다. 모델에게 서로 상충하는 두 가지 소스를 제공하면, 모델은 그중 하나를 선택하고 경계선을 숨긴 채 잘못된 절반을 바탕으로 확신에 찬 답변을 내놓습니다. Latency(지연 시간)는 이 모든 것에 부과되는 세금입니다. 매 호출마다 더 느려지고, 더 비싸집니다.

그리고 이 비용은 일정하지 않습니다. 에이전트가 사용자의 키보드에서 멀어질수록 비용은 커집니다. 탭 완성(tab-complete) 단계에서는 잘못된 제안을 1초 만에 잡아낼 수 있습니다. 하지만 관리되지 않고 실행되는 백그라운드 에이전트의 경우, 첫 번째 단계에서의 잘못된 컨텍스트는 며칠 뒤 리뷰 과정에서, 혹은 더 최악의 경우 프로덕션(production) 환경에서 발견되는 조용한 실패(silent failure)를 의미합니다.

실제로 효과가 있는 것은 큐레이션(curation)입니다

flowchart TD
    S["모든 소스:<br/>코드, 문서, 티켓, Slack"] --> N{"에이전트에게
어떻게 전달하는가?"}
    N -->|모두 쏟아붓기| B["Bloat, dilution,
conflict, latency"]
...

동일한 소스, 두 가지 전략. "더 많은 컨텍스트"는 왼쪽 경로를 택합니다. 큐레이션된 컨텍스트는 오른쪽 경로를 택합니다.

이 문제를 극복한 팀들은 단순히 정보를 추가하는 것을 멈추고, 에이전트가 보는 내용을 엔지니어링하기 시작했습니다. Stripe의 프레임레이밍(framing)은 6가지 역할을 수행하는 컨텍스트 엔진(context engine)이었으며, 이는 프롬프팅 팁(prompting tip)이라기보다 플랫폼 사양(platform spec)처럼 읽힙니다:

• 모든 소스의 신호(signals)를 하나의 뷰(view)로 병합
• 관련이 있을 법한 모든 것이 아니라, 작업에 꼭 필요한 것만 검색(retrieve)
• 토큰이 낭비되지 않도록 순위를 매기고 압축(compress)
• 충돌을 숨기는 대신 최신성(recency)과 권위(authority)를 기준으로 해결
• 접촉하는 모든 시스템에 대해 권한(permissions) 및 거버넌스(governance) 강제
• 리포지토리(repos), 팀, 작업 이력에 맞춰 관련성(relevance) 범위 설정

그 목록을 다시 읽어보고 어떤 부분이 프롬프트 엔지니어링 (prompt-craft)인지 말해보세요. 단 하나도 없습니다. 그것은 검색 (retrieval), 랭킹 (ranking), 충돌 해결 (conflict resolution), 액세스 제어 (access control) 및 거버넌스 (governance)입니다. 이것은 인프라 (infrastructure)입니다. 팀들이 새로운 소비자(consumer)를 향해 수년 동안 다른 시스템들을 위해 수행해 온 작업입니다.

정확히 이러한 시스템을 전문적으로 구축하는 Unblocked는 동일한 프롬프트와 동일한 모델을 사용하되 컨텍스트 (context)만 변경했을 때의 전후(before-and-after)를 보여주었습니다. 그들의 엔진이 없을 때, 팀의 컨벤션 (conventions)을 준수하고 기존 코드를 깨뜨리지 않는 등의 항목에서 출력값은 10점 만점에 2점에서 3.5점에 그쳤습니다. 엔진을 사용했을 때는 8점에서 9.5점까지 올라갔습니다. 동일한 모델, 동일한 프롬프트였습니다. 유일한 변수는 에이전트 (agent)가 무엇을 볼 수 있도록 허용되었는지, 그리고 그 조각 (slice)이 얼마나 잘 큐레이션 (curated)되었는지뿐이었습니다.

이것이 플랫폼 팀의 업무인 이유

"컨텍스트 엔지니어링 (Context engineering)"은 시니어 개발자들이 틈틈이 익히는 프롬프트 작성 기술이 아닙니다. 그것은 누군가가 구축하고 소유해야 하는 시스템입니다. 소스 (sources)를 통합하고, 점수를 매기며, 액세스 (access)를 관리하고, 적절한 시점에 적절한 모델에 적절한 조각을 전달하는 무언가가 반드시 필요합니다.

하이프 (hype)는 병목 현상 (bottleneck)이 모델 지능 (model intelligence)이라고 말했습니다. 그다음에는 병목 현상이 컨텍스트 (context)라고 말했습니다. 두 진단 모두 증상에 대해서는 옳았습니다. 하지만 그 누구도 누가 이를 해결해야 하는지는 말하지 않았습니다. 컨텍스트는 조립되고, 랭킹이 매겨지며, 거버넌스 (governed)되어야 하며, 그것이 바로 플랫폼 엔지니어링 (platform engineering)입니다.

따라서 다음 벤더 (vendor)가 해결책으로 MCP 서버를 하나 더 추가하라고 말할 때, 40개의 서버를 연결했을 때 여러분의 토큰 예산 (token budget), 충돌 (conflicts), 그리고 권한 (permissions)에 어떤 일이 벌어질지 그들에게 물어보십시오. 목표는 언제나 올바른 컨텍스트를 제공하는 것이었습니다. 그 차이를 아는 시스템을 구축하는 것이 바로 업무이며, 플랫폼 팀이 이를 위해 인력을 충원했든 아니든 이 업무는 플랫폼 팀의 몫이 될 것입니다.