몇 달 전, 저는 샌프란시스코에서 열린 LangChain Interrupt 2026에 참석했습니다. 매일 AI 플랫폼과 개발자 경험 (Developer Experience)을 이끄는 사람으로서, 제가 들은 내용 중 일부는 이미 제가 생각하던 바를 확인시켜 주었습니다. 또 다른 일부는 제 생각을 완전히 재구성해 주었습니다.

실제로 제품을 출시(Shipped)한 모든 팀에서 나타난 공통된 패턴은 하나였습니다. 그들은 처음에는 정교한 경로를 시도했다는 것입니다. 프로덕션 (Production) 환경에서는 운영 가능성 (Operability)이 필요했습니다. 그것이 살아남는 핵심이었습니다.

이 글은 제가 소프트웨어 엔지니어링에서의 AI-Native 시대 전환에 대해 쓴 글의 사고 흐름을 이어갑니다. 당시 저는 병목 현상으로 거버넌스 실패, 평가 격차 (Evaluation Gap), 그리고 사용자 주체성 (User Agency)의 한계를 꼽았습니다. Interrupt가 먼저 찾아왔고, 저는 단지 아직 적절한 질문을 형성하지 못했을 뿐이었습니다. 이 자리에는 그러한 병목 현상에 부딪히면서도 계속 나아갔던 팀들이 가득했으며, 제가 예상하지 못했던 몇 가지 측면들도 드러났습니다. 다음은 제 기억에 남은 부분들입니다.

1. 아키텍처의 필수 과제: 단순함이 곧 전략이다

HR, IT, 재무 플랫폼인 Rippling은 이 세 가지 분야 모두에서 동시에 AI를 실행합니다. 그들의 엔지니어링 팀은 그에 걸맞은 **프로덕션의 상흔 (Production Scars)**을 가지고 있습니다. 그들이 Interrupt에서 공유한 내용은 실제 사용자들 앞에서 제품을 출시하고 실패해 본 사람만이 얻을 수 있는 종류의 조언이었습니다.

에이전트를 구축할 때의 본능은 정교함을 추구하는 것입니다. 계층적 하위 에이전트 (Hierarchical Sub-agents), 특화된 작업 위임자 (Specialized Task Delegators), 화이트보드 위에서는 우아해 보이는 깊은 오케스트레이션 트리 (Orchestration Trees) 같은 것들 말입니다. Rippling도 그것을 시도했습니다. 하지만 그것은 프로덕션과의 접점에서 살아남지 못했습니다.

그들의 경험으로부터 네 가지 원칙이 도출되었습니다:

• 에이전트를 평면적으로 유지하세요 (Keep agents flat). 도구를 직접 조정하는 최상위 에이전트가 대부분의 프로덕션 (Production) 시나리오에서 하위 에이전트 계층 구조보다 더 나은 성능을 보입니다. 그 이유는 아키텍처의 우아함 때문이 아니라, 디버깅 가능성 (Debuggability) 때문입니다. 위임 계층이 하나씩 추가될 때마다 실패가 숨어들 수 있는 지점도 늘어납니다. 평면적인 에이전트는 크고 추적 가능하게 (loudly and traceably) 실패하지만, 하위 에이전트 계층 구조는 조용하고 비용이 많이 들게 (quietly and expensively) 실패합니다. 핵심 루프 (Core loop)가 작동한다는 것을 증명하기 전까지 오케스트레이션 (Orchestration) 계층의 복잡성은 부채가 됩니다. 이 원칙은 좋은 컴포넌트 아키텍처 (Component architecture)와 유사합니다. 깊게 중첩된 계층 구조는 디버깅하기 어렵고, 추론하기 어려우며, 변경하기 어렵습니다. 프로덕션에서는 평면적인 구조가 승리합니다.

• 특정 작업 전용이 아닌, 범용적이고 조합 가능한 도구를 만드세요 (Build generic composable tools, not task-specific ones). 하나의 에이전트 워크플로 (Workflow)를 위해 구축된 도구는 재사용할 수 없습니다. 반면 범용적인 도구는 어떤 워크플로에도 조합될 수 있습니다. 이것은 아키텍처에 대한 선호도가 아니라, 플랫폼 가치가 팀 전체로 확장되는 메커니즘입니다.

• 데이터가 아닌 코드를 LLM 컨텍스트 (Context)에 전달하세요 (Pass code into the LLM context, not data). 에이전트가 데이터 구조에 대해 추론해야 할 때는 가공되지 않은 레코드 (Raw records) 대신 스키마 (Schema)나 함수 정의 (Function definition)를 제공하세요. 코드는 구조와 의도를 더 정확하게 전달하며, 종종 토큰 효율성 (Token-efficient)이 더 높고 모델에게 추론 작업을 위한 적절한 수준의 추상화 (Abstraction)를 제공합니다. 예외는 에이전트가 특정 값에 대해 추론해야 할 때입니다. 그 경우에는 타겟팅된 데이터가 스키마보다 낫습니다.

• 구조화된 데이터 검색에는 맞춤형 도구보다 SQL이 더 뛰어납니다 (SQL outperforms bespoke tools for structured data retrieval). 에이전트가 필요로 할 수 있는 모든 쿼리 패턴에 대해 커스텀 도구를 만드는 대신, 관리되는 SQL 인터페이스 (Interface)를 사용하면 에이전트가 동적으로 쿼리를 구성할 수 있습니다. 좁은 범위의 검색 도구들이 조합 폭발 (Combinatorial explosion)을 일으키면 규모가 커질 때 실제 유지보수 부담이 됩니다. 잘 관리된 하나의 인터페이스는 아직 예상하지 못한 쿼리 패턴까지 처리할 수 있습니다. 이것이 실행 중심의 도구를 대체하는 것은 아닙니다. 데이터 페칭 (Fetching)만을 목적으로 하는 도구들을 대체하는 것입니다.

프로덕션에서 안정적으로 제품을 출시하는 팀은 규모를 키우기 전에 복잡성을 줄인 팀들입니다.

다른 엔지니어들이 매일 사용하는 AI 플랫폼을 구축한다는 것은 차원이 다른 문제입니다. 우리가 내리는 아키텍처 결정은 단 하나의 에이전트에만 영향을 미치는 것이 아니라, 모든 팀이 물려받게 될 기본값 (defaults) 이 됩니다. 평평하고 조합 가능한 (Flat and composable) 구조는 단순히 좋은 엔지니어링 위생 (engineering hygiene) 일 뿐만 아니라, 여러분이 기반 계층 (foundation layer) 역할을 할 때 규모를 확장할 수 있는 모델입니다.

2. 평가의 필수 과제: 단 한 번의 실행은 통과율이 아니다

Lyft의 Nick Ung는 회의실의 그 누구도 듣고 싶어 하지 않을 질문으로 세션을 시작했습니다. "여러분의 평가 (eval) 결과가 100% 통과율이라고 나왔다면, 정말 확실합니까?"

평가의 첫 번째 실행 (Pass 1)에서는 20%의 점수가 나올 수 있습니다. 두 번째 실행 (Pass 2)에서는 40%가 나올 수도 있습니다. 단 한 번의 실행에서 보는 점수는 분포 (distribution) 의 표본 (sample) 일 뿐, 분포 자체에 대한 측정값이 아닙니다. 에이전트의 출력은 비결정론적 (non-deterministic) 입니다. 평가를 한 번 실행하고 그 결과에 따라 제품을 출시하는 것은 품질 보증 (quality assurance) 이 아니라, 낙관주의 (optimism) 일 뿐입니다.

더 깊은 문제는 대부분의 팀이 여전히 범용 평가 (generic evals) 를 실행하고 있다는 점입니다. 범용 평가는 응답이 좋았는지를 묻습니다. 도메인 특화 평가 (domain-specific eval) 는 에이전트가 해당 도메인에서 발생하는 특정한 실패 모드 (specific failure modes) 하에서, 원래 구축된 특정 작업을 완료했는지를 묻습니다. 이 둘은 완전히 다른 질문이며, 오직 하나만이 여러분이 제품을 출시할 수 있는지 여부를 알려줍니다.

발표한 모든 프로덕션 팀에서 실제로 효과를 본 방법은 다음과 같습니다:

• 일반적인 품질 점수가 아닌 도메인 특화 루브릭 (Domain-specific rubrics). 루브릭은 행동 중심적이어야 합니다. "응답이 도움이 되었는가?"가 아니라 "에이전트가 과업을 완수했는가?"를 물어야 합니다. 정확성 (accuracy), 안전성 (safety), 과업 완수 (task completion), 어조 (tone)와 같이 독립적인 차원으로 분해되어야 합니다. 각 점수 수준마다 구체적인 예시를 고정(Anchored)해 두지 않으면, LLM 판사 (LLM judge)의 기준이 표류하게 됩니다.

• LLM 판사는 반드시 인간의 라벨 (human labels)을 기준으로 보정(calibrated)되어야 합니다. 대규모 자동 평가 (Automated eval)를 위해서는 모델을 판사로 사용해야 하지만, 인간의 정답 (ground truth)에 정렬 (aligned)되지 않은 모델은 사용자의 선호도가 아닌 모델 자신의 선호도를 측정하게 됩니다. 실제 상호작용 샘플을 추출하고, 인간의 라벨을 수집하며, 판사가 높은 일치도 (agreement)에 도달할 때까지 루브릭을 반복해서 개선하십시오. 이것은 일회성 작업이 아니라 지속적인 보정 루프 (calibration loop)입니다.

• 시뮬레이션 사용자 (Simulated users)는 일급 시민 (first-class artifact)입니다. Lyft는 오프라인 평가 (offline eval)에서 사용자 행동을 시뮬레이션하기 위해 별도의 LLM을 사용하는 방식을 설명했습니다. 대부분의 팀이 놓치는 통찰은 시뮬레이션 사용자 역시 판사만큼이나 보정이 필요하다는 점입니다. 비현실적인 시뮬레이션 사용자는 신뢰할 수 없는 평가를 생성합니다. 이것은 **두 모델의 문제 (two-model problem)**입니다. 에이전트와 시뮬레이터 모두 튜닝(tuned)되어야 합니다.

• 필요한 실행 횟수는 CUL 트릴레마 (CUL Trilemma)에 달려 있습니다. Rippling이 제시한 이번 컨퍼런스에서 가장 인용하기 좋은 프레임워크는 **비용 (Cost), 불확실성 (Uncertainty), 지연 (Lag)**입니다. 이 세 가지를 동시에 최적화할 수는 없습니다. 리스크가 큰 유스케이스 (use cases)는 더 많은 실행 횟수가 필요하며, 더 높은 비용과 지연을 감수해야 합니다. 내부 도구 (Internal tooling)의 경우 속도를 위해 확실성을 희생할 수 있습니다. 평가 반복 횟수는 보편적인 상수가 아니라, 명시적인 리스크 허용 범위 (risk tolerance)에 근거하여 유스케이스별로 결정되는 사항입니다.

• 컴플라이언스 (Compliance) 팀이 평가 (evals)를 공동 작성해야 합니다. Chime의 교훈에 따르면, 프로젝트 시작 시점에 법률 검토를 하고 출시 직전에 다시 검토하는 기존 모델은 개발 후반부에 거절당하기 딱 좋은 방식입니다. 컴플라이언스 팀이 평가 루브릭을 공동 작성하면, 규칙은 **실행 가능한 테스트 (executable tests)**가 됩니다. 이를 통해 피드백 루프가 수개월에서 수 시간으로 단축됩니다.

평가 플라이휠 (eval flywheel)은 이 루프를 완성합니다. 즉, 운영 환경에서의 동작이 증거가 되고, 증거가 이슈가 되며, 수정 사항은 해당 실패가 재발하는지 감시하는 평가기 (evaluator)가 됩니다. 이것이 바로 풀 스피드로 돌아가는 루프입니다.

이것은 제가 개발자 경험 (developer experience)의 맥락에서 가장 많이 고민하는 부분이며, 현재 제가 가장 밀접하게 다루고 있는 문제입니다. 사용하기 어려운 평가 (eval) 인프라는 사용되지 않습니다. 평가를 해야 한다는 사실을 아는 것과, 이를 마찰 없이 수행할 수 있는 인프라를 갖추는 것 사이의 간극이 대부분의 팀이 정체되는 지점입니다. 코드 작성 없이도 접근 가능한 오프라인 및 온라인 평가 모두가 필요합니다. 이 문제를 해결한 팀들은 평가를 스프린트 끝에 엔지니어들이 두려워하는 관문이 아니라, 개발 루프의 자연스러운 일부로 만들었습니다.

3. 거버넌스의 필수성: 폭발 반경 (Blast Radius) 문제

Aaron Levie는 Harrison Chase와의 세션에서 모든 것을 재구성하는 관점을 제시했습니다: 코딩 에이전트 (coding agents)가 가장 쉬운 사례라는 점입니다. 코드는 검증 가능합니다. 피드백 루프가 긴밀합니다. 사용자가 기술적입니다. 지식 노동 에이전트의 다른 모든 카테고리는 이러한 특성을 전혀 가지고 있지 않습니다.

거버넌스 과제는 가설적인 것이 아닙니다. 그것이 대부분의 기업용 에이전트가 여전히 내부 도구에 머물러 있고, 여전히 통제된 파일럿 단계에 있으며, 실제 가치가 존재하는 워크플로우에 아직 도달하지 못한 이유입니다.

이 문제를 실제로 해결한 세션들에서 일관되게 나타난 네 가지 원칙은 다음과 같습니다: **최소 권한 부여 (least-privilege authorization), 데이터 난독화 (data obfuscation), 하드코딩된 인간 개입 (hardcoded human-in-the-loop), 그리고 지속적인 평가 (continuous eval)**입니다.

• 최소 권한 실행 시점 권한 부여 (Least-privilege runtime authorization). 에이전트는 결코 포괄적인 시스템 액세스 권한을 가지고 작동해서는 안 됩니다. 권한 부여는 모든 개별 도구 호출(tool call)에 대해 실행 시점(runtime)에 동적으로 이루어져야 합니다. 사용자가 특정 시스템에 접근할 권한이 없다면, 에이전트는 그 권한을 상속받을 수 없습니다. 이는 관례가 아니라, 아키텍처 (architecture) 차원에서 보장되어야 합니다.

• 외부 라우팅 전 데이터 난독화 (Data obfuscation before external routing). 개인정보(PII) 및 기업의 민감한 데이터는 외부 LLM 제공업체에 도달하기 전에 반드시 마스킹(masking)되어야 합니다. **마스킹 레이어 (masking layer)**는 모델과 사용자 사이가 아니라, 데이터 시스템과 모델 사이에 위치해야 합니다.

• 중요 작업에 대한 하드코딩된 인간 개입 (Hardcoded human-in-the-loop for high-stakes actions). 거래, 제출, 되돌릴 수 없는 상태 변경과 같이 실질적인 결과가 따르는 작업의 경우, 인간의 승인이 에이전트의 판단에 맡겨지는 것이 아니라 프로그램적으로 강제되어야 합니다. 모든 승인은 감사 가능(auditable)해야 합니다. 이러한 감사 가능성 요구사항이야말로 거버넌스 프레임워크 (governance framework)와 정책 문서 (policy document)를 구분 짓는 요소입니다. 또한, 이러한 승인 순간을 어떻게 설계하느냐에 따라 사용자가 시스템을 신뢰할지 아니면 포기할지가 결정됩니다. 즉, **HITL은 안전 메커니즘인 동시에 하나의 디자인 표면 (design surface)**입니다.

• 생애주기의 중추로서의 지속적인 평가 (Continuous eval as the lifecycle backbone). 에이전트의 행동은 표류 (drift)합니다. 모델이 업데이트됩니다. 사용자 행동이 변화합니다. 출시 시점에만 평가하는 거버넌스 모델은 배포되는 순간 신호를 놓치게 됩니다. 회귀(regression), 프롬프트 인젝션 (prompt injection), 엣지 케이스(edge case) 실패 등을 테스트하기 위해 운영 트레이스(production traces)를 대상으로 지속적으로 실행되는 자동화된 평가 루프(automated evaluation loops)가 거버넌스를 최신 상태로 유지하는 운영 계층입니다.

Toyota는 공유 플랫폼을 구축한 후, 배포당 6개월과 6명의 엔지니어가 투입되던 방식에서 4일과 1명의 엔지니어가 투입되는 방식으로 전환했습니다. 현재 그들은 50개 이상의 에이전트를 운영 환경(production)에서 실행하고 있습니다. 이 플랫폼은 단순히 배포를 가속화한 것이 아니라, 거버넌스의 확장성 (scale)을 확보했습니다.

이것은 단순히 효율성의 향상이 아니라, 결과의 범주 자체가 다른 것입니다. 거버넌스 (Governance)는 속도 (velocity)를 제한하는 제약 사항이 아니라, 속도를 지속 가능하게 만드는 요소입니다. 거버넌스를 내재화한 플랫폼은 팀의 속도를 늦추는 것이 아니라, 의사 결정 과정 자체를 제거합니다.

4. 비용의 필연성: 인프라스트럭처는 일급 엔지니어링 규율이다

Go-To-Market 플랫폼인 Clay는 **매월 3억 5천만 건의 에이전트 실행 (agent executions)**을 수행합니다. 이들의 AI 책임자인 Jeff Barg는 프롬프트 (prompts)나 모델 (models)에 대해 이야기하지 않았습니다. 그는 **배압 (back-pressure), 처리량 (throughput), 캐싱 (caching), 그리고 제한된 재시도 (bounded retries)**에 대해 이야기했습니다.

에이전트 인프라스트럭처 (agent infrastructure)에 대한 제 생각을 재정립해 준 통찰은 다음과 같습니다: 비용은 제품을 출시한 후에 나타나는 운영상의 문제가 아니라, 설계 단계부터 반영되어야 하는 엔지니어링 규율 (engineering discipline)입니다. Aaron Levie 또한 다른 관점에서 동일한 점을 지적했습니다. 상장 기업들은 분기 중간에 갑작스럽게 발생하는 1,000만 달러 규모의 AI 비용을 감당할 수 없습니다. 엔터프라이즈 AI의 재무 모델은 재무의 문제가 아닙니다. 그것은 아키텍처 (architecture)의 문제입니다.

대규모로 운영되는 팀들이 실제로 구축한 것은 다음과 같습니다:

• 작업 유형별 모델 라우팅 (Model routing by task type). 에이전트 워크플로우 (workflow)의 모든 단계에 프런티어 모델 (frontier model)이 필요한 것은 아닙니다. 요약 (summarization), 검색 (search), 추출 (extraction), 분류 (classification)는 더 작고, 빠르며, 저렴한 모델들로도 충분히 해결 가능한 문제들입니다. 프런티어 모델은 고난도 추론 (reasoning), 모호한 판단 (ambiguous judgment calls), 복잡한 컨텍스트 (context) 전반의 합성 (synthesis)을 위해 아껴두어야 합니다.

• 제한된 재시도 (Bounded retries). 에이전트가 무한히 루프를 도는 것보다, 정해진 단계 후에 멈추도록 강제하는 것이 종종 더 나은 결과를 만들어냅니다. 제한 없는 재시도는 비용을 가중시키고 오류를 누적시킵니다. 재시도 예산 (retry budget)은 **안전망이 아니라 설계 제약 조건 (design constraint)**입니다.

• 프롬프트 캐싱 (Prompt caching). 여러 실행에 걸쳐 공유되는 시스템 컨텍스트 (system context)를 가진 에이전트의 경우, 프롬프트 접두사 (prompt prefix)를 캐싱하면 인프라 비용을 크게 줄일 수 있습니다. 이는 사용 가능한 최적화 방법 중 가장 레버리지가 높은 (highest-leverage) 방법 중 하나이자, 가장 적게 논의되는 방법 중 하나입니다.

• 적응형 스로틀링 (Adaptive throttling). TCP 혼잡 제어 (congestion control)를 모델로 합니다. 시스템에 부하가 걸릴 때, 값비싼 실패를 겪는 대신 우아하게 속도를 늦춥니다. 실제 결과는 4~10배의 처리량 (throughput) 향상입니다.

회복 탄력성 (resilience)을 위한 아키텍처와 비용 효율성 (cost efficiency)을 위한 아키텍처는 결국 동일한 아키텍처임이 드러납니다.

플랫폼 관점에서 비용 가시성 (cost visibility)은 재무적인 문제인 동시에 개발자 경험 (developer experience)의 문제입니다. 스프린트 (sprint) 도중에 모델과 도구 (tool)를 선택하는 엔지니어들은 비용에 미치는 영향을 이해할 수 있는 피드백 루프를 갖는 경우가 드뭅니다. 이러한 신호를 **개발 시점 (at the point of development)**에 조기에 노출하는 것이 오늘날 대부분의 AI 플랫폼에서 결여된 계층입니다.

5. 전략적 필수 과제: 워크플로우를 단순히 자동화하지 말고 재설계하라