모델이 당신이 신경 쓰는 모든 평가에서 최고 점수를 기록하더라도, 여전히 배포(ship)가 불가능할 수 있습니다.

에이전트(agent)가 실제 데이터, 실제 자격 증명(credentials), 그리고 무언가를 변경할 수 있는 권한이 필요해지기 전까지는 이 말이 앞뒤가 맞지 않는 것처럼 들릴 것입니다. 그 시점이 되면, 가공되지 않은 능력(raw capability)은 더 이상 어려운 부분이 아닙니다. 진짜 어려운 부분은 무언가 잘못되기 전에 팀이 설명할 수 있는 런타임(runtime)의 경계를 설정하는 것입니다.

어디에서 실행되는가? 해당 환경에서 무엇이 나갈 수 있는가? 어떤 컨텍스트(context)를 읽을 수 있는가? 무엇을 변경할 수 있는가? 실패한 작업은 어떻게 나타나는가? 변경 사항을 되돌릴 수 있는가?

만약 이러한 질문에 대한 답이 모호하다면, 벤치마크 점수는 사소한 정보(trivia)에 불과합니다.

프롬프트가 아닌 배치(placement)부터 시작하세요

대부분의 에이전트 데모는 작업(task)에서 시작합니다. 프로덕션 설계는 그보다 한 단계 낮은 수준인 배치(placement)에서 시작해야 합니다.

프로세스는 어딘가에 존재해야 합니다. 자격 증명(credentials)도 어딘가에 존재해야 합니다. 검색된 컨텍스트(context), 도구(tool) 결과, 캐시(cache), 그리고 로그(log)는 모두 모델 호출 자체보다 더 중요할 수 있는 경계들을 넘나듭니다.

이것이 "로컬(local)"이 유용하지만 불완전한 이유입니다. 로컬 프로세스라 할지라도 여전히 광범위한 자격 증명을 보유하거나, 인증되지 않은 포트를 노출하거나, 민감한 컨텍스트를 영구적으로 유지하거나, 배후에서 원격 서비스(remote services)를 호출할 수 있습니다. 로컬리티(Locality)는 일부 기본 노출을 줄여주지만, 보안 설계(security design)를 해결해주지는 않습니다.

평범한 이미지 워크플로우를 보면 이 차이가 명확해집니다. Resize Image For는 서버 측 처리를 위해 픽셀을 업로드하는 대신 브라우저 내에서 소스 이미지 변환을 수행합니다. 그렇다고 해서 모든 브라우저 도구가 안전해지는 것은 아닙니다. 다만 하나의 중요한 경계를 명확하게 해줄 뿐입니다: 소스 파일이 네트워크 경계의 사용자 측에 머문다는 점입니다.

에이전트 런타임(agent runtimes)에도 동일한 명확성이 필요합니다. "우리 인프라에서 실행된다"는 것은 첫 번째 답변일 뿐입니다. 데이터가 다음에 어디로 가는지 여전히 알아야 합니다.

컨텍스트는 운영 서브시스템입니다

팀들은 종종 컨텍스트(context)를 프롬프트 엔지니어링(prompt-engineering) 문제로 취급합니다. 즉, 더 나은 텍스트를 찾고, 더 많은 토큰(token)을 추가하며, 모델이 올바른 단락을 알아차리기를 바라는 식입니다.

그러한 프레임링 (framing)은 프로덕션 (production) 환경에서 무너집니다. 컨텍스트 (context)에는 가용성 (availability), 신선도 (freshness), 출처 (provenance), 캐시 동작 (cache behavior), 그리고 실패 상태 (failure states)가 존재합니다. 그것은 인프라 (infrastructure)입니다.

Wigolo는 문서화된 표면 (surface)을 통해 이러한 우려 사항들을 명시적으로 드러내기 때문에 유용한 예시가 됩니다. Wigolo는 에이전트 (agent) 옆에 위치할 수 있는 로컬 우선 (local-first) 서비스 주변으로 검색 (search), 가져오기 (fetch), 크롤링 (crawl), 추출 (extraction), 그리고 캐싱 (caching)을 패키징합니다. Wigolo의 응답은 모든 검색 시도를 그럴싸해 보이는 텍스트로 평탄화 (flattening)하는 대신, 증거를 포함하거나 오래되었거나 차단된 결과를 보고할 수 있습니다. 또한 이 프로젝트는 루프백 (loopback) 사용과 액세스 토큰 (access token)이 배포 경계 (deployment boundary)의 일부가 되는 원격 노출 (remote exposure)을 구분합니다.

유용한 아이디어를 가져오기 위해 반드시 Wigolo를 채택할 필요는 없습니다: 바로 컨텍스트 계약 (context contract)을 가시화하는 것입니다.

에이전트는 다음의 차이점을 구별할 수 있어야 합니다:

• 신선한 콘텐츠 (fresh content)와 오래된 캐시 항목 (old cache entry)
• 사용 가능한 증거가 있는 페이지와 성능이 저하된 가져오기 (fetch)
• 접근이 허용된 소스와 정책에 의해 차단된 소스
• 로컬 처리 (local processing)와 원격 요청 (remote request)

이러한 구분이 없다면, 모델은 컨텍스트를 받지만 운영자 (operator)는 그것에 대해 추론할 수 있는 능력을 상실합니다. 확신에 찬 답변이 오래된 캐시, 불완전한 페이지, 또는 조용한 백엔드 실패 (silent backend failure)를 기반으로 구축될 수 있기 때문입니다.

더 많은 컨텍스트가 이를 해결해주지는 않습니다. 더 나은 컨텍스트 배관 (context plumbing)이 해결해 줍니다.

에이전트를 임베딩하는 것은 권한 문제 (authority problem)를 임베딩하는 것이다

GitHub Copilot SDK는 경계의 나머지 절반을 가리킵니다. 이는 애플리케이션이 여러 언어 생태계에 걸쳐 임베딩할 수 있는 에이전트 런타임 (agent runtime)을 노출합니다. 호스트 애플리케이션은 인증 (authentication), 도구 선택 (tool selection), 그리고 권한 처리 (permission handling)에 대한 책임을 유지합니다.

그 책임이 바로 제품 (product)입니다.

에이전트가 별도의 채팅 창에서 당신의 애플리케이션 내부로 이동하면, 도구 호출 (tool calls)은 애플리케이션의 동작 (behavior)이 됩니다. 광범위한 기본 도구 세트는 최소 권한 원칙 (least privilege)에 어긋납니다. 권한 콜백 (permission callback)은 나중에 뿌려주는 모달 (modal)이 아닙니다. 프로세스 배치 (process placement), 자격 증명 범위 (credential scope), 허용 목록 (allowlists), 그리고 호출당 결정 (per-call decisions)은 아키텍처 (architecture)입니다.

여기서는 사용자 대면 인터페이스 (user-facing surface) 또한 중요합니다. 인터페이스가 제안된 작업, 영향을 받는 리소스, 또는 롤백 경로 (rollback path)를 숨긴다면 승인 과정은 취약해집니다. 에이전트가 렌더링하는 컨트롤 (agent-rendered controls)을 탐색하는 팀은 Generative UI resources와 같은 컬렉션을 사용하여 MCP 호환 UI 도구, 렌더러 패턴 (renderer patterns), 그리고 SDK를 비교해 볼 수 있습니다. 프로토콜의 참신함보다는 호스트가 신뢰할 수 있는 구성 요소에 대한 제어권을 유지하고, 작업이 일어나는 순간에 권한 (authority)을 이해할 수 있게 만드는지가 더 중요합니다.

훌륭한 에이전트 UX는 좁은 기능 범위를 실제로 좁게 보이도록 만들어야 합니다.

"이슈 184의 라벨을 needs-triage에서 bug로 업데이트한 다음, 결과 이벤트를 보여줘"는 검토 가능합니다. 반면 "저장소 관리"는 친근한 버튼의 탈을 쓴 백지 수표와 같습니다.

가역성 (reversibility)을 확장 메커니즘으로 사용하세요

엔터프라이즈 에이전트 도입에 관한 최근의 커뮤니티 논의는 동일한 실질적인 패턴을 반복하고 있습니다: 읽기 전용 (read-only)으로 시작하여, 하나의 워크플로를 증명하고, 하나의 가역적인 작업 유형을 추가한 뒤, 감사 증거 (audit evidence)를 바탕으로 확장하는 것입니다. 이는 보편적인 산업 결과라기보다는 일화적인 정서에 가깝지만, 그 순서는 타당합니다.

실수는 권한 (permissions)을 출시 체크리스트로 취급하는 것입니다. 권한은 확장 루프 (expansion loop)를 형성해야 합니다.

1. 에이전트에게 이름이 지정된 작은 컨텍스트 표면 (context surface)을 부여합니다.
2. 에이전트가 올바른 증거를 검색하고 실패를 정직하게 보고하는지 관찰합니다.
3. 명확한 역작업 (inverse)이 있는 쓰기 작업 (write action)을 하나 추가합니다.
4. 요청, 결정, 도구 결과, 그리고 그로 인한 시스템 상태를 기록합니다.
5. 해당 기록들이 경계 (boundary)가 제대로 작동함을 보여줄 때만 확장합니다.

이는 배포에 관한 대화의 성격을 바꿉니다. 당신은 더 이상 에이전트가 "프로덕션에 투입될 준비가 되었는가"를 단일한 예/아니오 질문으로 묻지 않습니다. 대신, 테스트된 하나의 경계를 조금 더 넓힐 수 있을지를 결정하게 됩니다.

가역성은 그 결정을 더 저렴하게 만듭니다. 초안을 작성하는 것은 게시하는 것보다 안전합니다. 라벨을 추가하는 것은 이슈를 닫는 것보다 안전합니다. 패치 (patch)를 준비하는 것은 머지 (merge)하는 것보다 안전합니다. 정확한 단계는 시스템에 따라 다르겠지만, 각 단계는 관찰 가능한 결과와 알려진 되돌아가는 방법을 가져야 합니다.

실제로 의미 있는 배포 전 테스트

또 다른 모델 리더보드(Leaderboard)를 비교하기 전에, 팀원들이 다음 질문들에 대해 쉬운 언어로 답변하게 하십시오:

• 런타임(Runtime)이 어디에서 실행되며, 자격 증명(Credentials)은 어디에 저장되는가?
• 로그, 캐시, 모델 요청을 포함하여 해당 환경을 벗어날 수 있는 데이터는 무엇인가?
• 어떤 컨텍스트 소스(Context sources)를 읽을 수 있으며, 최신성(Freshness), 출처(Provenance), 그리고 검색 실패(Retrieval failure)는 어떻게 노출되는가?
• 기본적으로 사용 가능한 도구(Tools)는 무엇이며, 어떤 호출이 명시적인 결정을 필요로 하는가?
• 가장 좁은 범위의 유용한 쓰기 작업(Write action)은 무엇인가?
• 해당 작업이 발생했다는 것을 증명하는 증거는 무엇이며, 어떻게 되돌릴(Reverse) 수 있는가?

만약 답변을 위해 다이어그램이 필요하다면, 다이어그램을 그리십시오. 만약 답변이 "프롬프트에 따라 다릅니다"라면, 경계(Boundary)가 아직 준비되지 않은 것입니다.

모델의 능력(Capability)은 여전히 중요합니다. 주의 깊은 런타임 내부의 약한 모델은 여전히 약한 모델입니다. 하지만 실제로는 그 반대가 더 중요합니다. 모호한 권한과 보이지 않는 실패를 가진 뛰어난 모델은 사고 유발자(Incident generator)가 됩니다.

최고의 프로덕션 에이전트(Production agent)는 데모에서 가장 많은 일을 할 수 있는 모델이 아닙니다. 실행하기 전에 팀이 그 경계를 설명할 수 있고, 작동하는 동안 검사할 수 있으며, 추측 없이 확장할 수 있는 모델이 최고의 에이전트입니다.

출처 노트

• Wigolo
• GitHub Copilot SDK
• What blocks agents at real companies isn't capability anymore, it's where they're allowed to run