에이전트가 읽을 수 있는 기업으로 나아가기

이번 달 초 저는 제가 만든 오픈 소스 데모 저장소의 참조 서버를 이전에 사용해 본 적 없는 AI 호스팅인 Mistral Vibe에 연결했습니다. 약 5분 후, 저는 우리 회사 건물에 대해 질문했고, 공공 정부 데이터를 기반으로 구축된 프로필과 상호작용 지도(interactive map)를 돌려받았습니다. 그 지도는 MCP 앱이었고, Claude와 ChatGPT에서 작동하는 방식과 정확히 동일하게 동작했습니다. Mistral에게는 아무것도 작성되지 않았습니다.

5분이라는 시간은 데모 수치이며, 해당 서버는 공공에 공개되어 있고 우리 기업의 신원이 앞에 붙지 않은 상태였기 때문에, 이 테스트는 우리의 권한(permissions)이 아니라 프로토콜과 인터페이스를 다루었습니다. 이것을 가능하게 한 것은 몇 달 전 우리가 내린 내부 시스템 결정이었습니다. 바로 도메인 역량(domain capabilities)을 에이전트 런타임 외부로 분리하는 것이었습니다.

많은 기업 AI 계획은 플랫폼 결정에서 시작합니다. 어떤 어시스턴트를 사용할지, 어떤 에이전트 프레임워크를 사용할지, 어떤 공급업체를 선택할지, 그리고 그 위에 어떤 사용 사례(use cases)를 구축할지를 정하는 식입니다. 이 계획은 에이전트를 중심으로 구성됩니다.

저는 다른 질문에서 시작했습니다. '어떤 유능한 에이전트라도 이 회사의 성장하는 일부 영역을 이해하고 안전하게 운영하려면 무엇이 필요할까?' 여기서 에이전트란 Claude, Codex, Mistral Vibe와 같은 범용 에이전트 하네스(general-purpose agent harness)를 의미합니다. 즉, 모델과 그 주변의 런타임으로 구성되어 계획을 세우고, 도구를 호출하며, 승인을 요청하고, 대화를 이어가는 시스템입니다. 이 질문에 답하면 플랫폼 결정은 더 작아집니다. 이러한 하네스들은 계속 개선되고 주인이 바뀌지만, 회사 측에서 요구하는 것은 대체로 동일합니다. AI 예산의 변화에 따라 관리팀이 바뀔지라도, 이름 있는 소유자(named owner)를 가진 재사용 가능한 역량들(reusable capabilities)은 AI 플랫폼 변경 시에도 다시 구축할 필요가 없습니다.

제가 이 목적지를 **에이전트가 읽을 수 있는 기업(agent-readable company)**이라고 부릅니다. 즉, 그 시스템들이 의미와 한계를 지닌 역량(capability)으로 노출되고, 업무 방식들은 절차(procedure)로 포착되며, 운영 리듬은 일정과 이벤트에 따라 돌아가는 곳입니다. 따라서 일반적인 에이전트가 이 기업의 증가하는 부분 전체에서 찾고, 해석하고, 행동할 수 있게 됩니다. '읽을 수 있다'는 표현으로는 다소 부족한데, 왜냐하면 행동(acting)도 그 일부이기 때문입니다. 하지만 정확하게 읽는 것이 선행되어야 하며, 대부분의 작업이 바로 여기에 있습니다.

본 포스트에서는 350명 규모의 빌딩 서비스 계약업체인 Warmtebouw에서 작동하는 이 아키텍처를 설명합니다. 일부는 이미 운영 중이며, 일부는 논문(thesis) 단계입니다. 어느 것이 무엇인지 명확히 말씀드리겠습니다. 각 섹션에 라벨이 붙은 더 긴 버전은 데모 저장소의 capability architecture page에서 확인할 수 있습니다.

다섯 가지 계층 (Five layers)

Five stacked layers. On top, with a dashed outline, the AI host: where the conversation happens, a vendor's agent harness such as Claude, Codex or Mistral Vibe, marked rented. Below it, grouped as owned by the company: activation (when work runs: a prompt, a schedule, an event), skills (how the work is done, owned by the people who do the work), capabilities (what the company can do, with its meaning; meaning from the domain owner, build by engineering) and systems of record (where the truth stays: ERP, BIM, energy, building automation).

**기록 시스템(Systems of record)**은 계속해서 진실의 원천으로 남습니다. 어떤 것도 AI 플랫폼으로 마이그레이션되지 않으며, 모델이 검색할 회사 사본도 만들어지지 않습니다. 에이전트는 주어진 질문에 대해 어떤 역량(capability)이 반환하는지 그 결과를 확인합니다.

**역량(Capabilities)**은 시스템이 무엇을 할 수 있는지 노출합니다: 이것을 읽거나, 저것을 계산하거나, 이런 변경 사항을 제안할 수 있습니다. 각 역량은 자신의 데이터 의미를 함께 지닙니다. 저희의 경우, 이들은 MCP 서버이며, 5명의 개발팀이 구축한 103개의 도구(tools)가 포함된 16개의 서버입니다.

**기술(Skills)**은 작성된 절차입니다. 활성 프로젝트를 찾고, 에너지 수치를 가져오며, 이러한 규칙을 적용하고, 승인 없이 절대 작성하지 않습니다. 역량은 '회사가 무엇을 할 수 있는가?'에 답합니다. 기술은 '이 작업이 여기서 어떻게 수행되는가?'에 답합니다.

**활성화(Activation)**는 기술이 언제 실행될지 결정합니다: 누군가 지금 요청하거나, 매일 아침 스케줄이 작동하거나, 이벤트가 도착할 때입니다.

**AI 호스트(The AI host)는 공급업체의 에이전트 하네스입니다: Claude, Codex, Mistral Vibe 또는 다음 세대 모델일 것입니다. 대화가 발생하는 곳이며, 추론을 수행하고 목표를 중심으로 아래 계층들을 구성합니다.

소유권 열(ownership column)이 가장 중요한 부분이며, 하나의 역량에 대해 두 가지로 나뉩니다. 도메인 측면은 데이터가 무엇을 의미하는지, 그리고 스스로 작성하지 않았더라도 어떤 규칙들이 유효한지에 대해 답변합니다. 엔지니어링은 구현, 보안 및 기술적 품질을 소유합니다. 실제로는 대부분의 의미가 지시되기보다는 발견됩니다. 저희에게 있어 엔지니어링은 다섯 명으로 구성된 팀이며, 대부분의 도메인 지식은 라이브 데이터를 연구하고 도구들이 어떻게 사용되는지를 분석하는 루프(Introspective Context Engineering)에서 나옵니다. 가능하다면 도메인 전문가가 마지막에 검토합니다. 그렇지 않은 경우, 의미는 데이터와 그 사용이 보여주는 것에 의존하게 되는데, 이는 기반이 약하므로 역량(capability)에서도 그렇게 명시해야 합니다. 기술(Skills)은 실제로 작업을 수행하는 사람들에게 소유됩니다. 왜냐하면 절차에 대한 지식이 그곳에 존재하기 때문입니다. 호스트는 공급업체가 소유하고 임대하는 것입니다.

이 계층들은 회사가 자체 운영에 대해 아는 것과 그것을 사용하는 소프트웨어 및 모델들을 분리합니다. 보통 그 지식은 비즈니스 애플리케이션, 통합 코드, 그리고 경험 많은 사람들의 머릿속에 흩어져 있습니다. 이 아키텍처에서는 그 지식이 에이전트 런타임 외부(out of the agent runtime)에 유지됩니다. 데이터가 무엇을 의미하고 어디까지의 한계가 있는지는 역량들이 소유하며, 작업 방식은 그것을 수행하는 사람들에게 속합니다. 이러한 분리가 다르게 작동하는 AI 호스트가 그 지식을 재구축할 필요 없이 동일한 회사 위에서 작동할 수 있게 합니다.

역량(A capability)은 의미를 내포한다

능력(capability)은 단순히 모델이 앞에 붙는 엔드포인트를 넘어섭니다. 건물 등록 시스템은 temperatuuroverschrijding: 3.59와 같은 과열 지표를 반환할 수 있으며, 이 값은 완벽하게 도달 가능한 상태입니다. 오직 이것만 주어진다면, 모델은 임의로 단위를 선택하고 3.59를 '도(degree)'로 읽어 낮은 위험이라고 보고합니다. 하지만 이 지표는 단위가 없고, 기준치는 1.5이며, 위험도는 상당합니다 (실시간 데모). 원래 그 데이터 앞에 있던 애플리케이션은 '상당하다'고 말했습니다. 에이전트는 아무런 단위가 없는 숫자만 보게 되는데, 능력(capability)이 더 많은 정보를 알려주지 않는 한 그렇지 못합니다.

따라서 능력은 사람이 설명해야 할 것들을 담고 있습니다: 단위와 출처(provenance), 상태가 무엇을 의미하고 무엇을 의미하지 않는지, 어떤 값이 측정되었고 어떤 값이 계산되었는지, 데이터가 어떤 결론을 뒷받침하지 못하는지 말입니다. 저는 이것을 **풍부한 도메인(rich domain)**이라고 부릅니다. '도메인 풍부함(Domain-rich)'은 양적인 느낌을 주어 더 많은 설명, 더 많은 규칙, 더 많은 산문처럼 들릴 것입니다. 하지만 측정값들은 다른 방향을 가리킵니다. 데모 저장소의 평가(evals)에서는 잘못된 메타데이터가 누락된 메타데이터보다 더 큰 피해를 입혔으며, 긴 설명의 대부분은 모델에게 아예 도달하지 못했습니다 (The Missing Layer에 자세한 내용이 있습니다).

결과가 정확해야 하는 경우, 능력(capability)이 그것을 계산합니다. 우리의 기술적 계산은 하나의 라이브러리 안에 있으며, 테스트된 핵심 기능 하나를 가지고 있고, API, 웹 인터페이스, MCP 도구 뒤에 숨겨져 있습니다. 결과는 단위, 가정, 범위, 중간 단계 및 출처를 함께 가집니다. 모델은 올바른 계산을 찾아 호출합니다. 모델이 공식을 소유하는 것이 아닙니다. 평가에서 서버 측에서 결정적인 수치를 계산하는 것이 모든 실행에서 값과 그 도출 과정을 모두 정확하게 얻어낸 유일한 접근 방식이었습니다 (evidence, L1).

능력을 구축하고 질문을 조합하세요

일반적인 아키텍처는 사용 사례에서 시작됩니다. 즉, 재무 에이전트, 계획 에이전트, 부서별 에이전트가 있으며, 각각 자체 프롬프트, 통합 기능 및 비즈니스 규칙 사본을 가집니다. 이에 대한 반론은 Scale Capabilities Before You Scale Agents에 나와 있으므로, 여기서는 그 결과만 다룹니다. ERP 기능, BIM 기능, 에너지 기능을 구축하고 각각을 독립적으로 신뢰할 수 있게 만듭니다. ERP와 BIM을 결합하거나, BIM과 에너지를 결합하거나, 세 가지를 모두 별도의 프로젝트로 만드는 것이 아닙니다. 사람들은 질문이 여러 개 이상의 것을 필요로 할 때 그 기능들을 조합합니다.

재사용은 고유의 실패 모드를 가져옵니다. 기능을 결합하면 오류가 복합적으로 작용할 수 있습니다. 각각 약간씩 틀린 두 기능이, 단독으로는 어떤 방식으로도 보여주지 못하는 방식으로는 자신감 있게 잘못된 답변을 생성할 수 있습니다. 각 기능은 먼저 그 자체로 정확해야 하며, 그것만으로는 여전히 충분하지 않습니다. 두 개의 올바른 기능이 제대로 결합되려면, 건물을 식별하는 기준, 수치가 커버하는 기간, 용어의 정의에 대해 합의해야 합니다.

권한(Permissions)이 또 다른 문제입니다. 시스템을 결합한다고 해서 권한이 누적되어 더 많은 권위를 가지게 되어서는 안 됩니다. BIM, 에너지, ERP를 읽어들이는 워크플로우는 합리적이지만, 각 기능이 쓰기(write)를 허용하기 때문에 이 세 가지 모두를 변경할 수 있는 워크플로우는 아무도 승인하지 않은 위험입니다. 프로토콜이나 신원 확인 절차로는 이를 막을 수 없습니다. 사용자가 각각의 쓰기를 개별적으로 허용받았을지라도 말입니다. 원칙은 기능(capabilities)을 조합한다고 해서 권한이 자동으로 조합되어서는 안 된다는 것입니다. 현재 우리의 정책은 이 원칙의 보수적인 버전이며, 모든 쓰기 도구가 어떻게 구축되는지를 강제합니다: 시스템 전반에 걸친 워크플로우는 각 시스템에 대해 읽기 접근 권한을 얻고, 최대 그것이 설계된 단 하나의 좁은 범위의 쓰기 권한만을 가집니다. 일부 프로세스는 합법적으로 여러 시스템에 대한 통제된 쓰기를 필요로 할 것입니다. 그럴 경우, 이는 조합이 우연히 허용한 것이 아니라 자체적인 승인이 필요한 명시적인 결정이어야 합니다. 쓰기 도구가 아직 적을 때는 어떤 도구를 구축할지 선택하는 것만으로 충분합니다. 하지만 개별적으로 허용되는 쓰기가 여러 개 존재하게 되면, 워크플로우당 제한 사항을 강제해야 하며, 이것이 이 아키텍처가 여전히 충족해야 할 요구사항입니다.

스킬(Skills): 절차 계층 (Procedure layer)

스킬은 에이전트가 실행하는 방식으로 작업을 패키징합니다: 어떤 기능을 사용할지, 어떤 순서로 사용할지, 어떤 규칙이 적용되는지, 그리고 사람이 결정해야 하는 부분이 어디인지를 정의합니다. 한 번 작성되면, 아래의 기능에 접근할 수 있는 누구나 반복적인 워크플로우를 위해 새로운 애플리케이션을 만들 필요 없이 재사용할 수 있습니다.

약한 스킬은 도구 시퀀스입니다: A 호출, B 호출, 답변. 좋은 스킬은 신중한 동료가 작업을 처리하는 방식대로 작동합니다: 현재 위치를 파악하고, 불확실한 부분을 해결하며, 증거를 수집하고, 결정하며, 행동하고, 검증합니다. 각 단계마다 작성자는 사람이 무엇을 보거나 승인해야 하는지, 그리고 어떤 형식(텍스트, 질문, 차트 또는 표, 승인 양식, 수정 사항이 포함된 거절)으로 해야 하는지를 결정합니다. 인간의 개입은 최대 자율성이나 최대 통제에 대한 전역 설정이 아니라 단계별 디자인 결정이 됩니다.

개발자가 아닌 사람도 시스템 내부 접근 권한 없이 스킬을 작성할 수 있습니다. 스킬 자체는 어떠한 권한도 가지지 않습니다. 상호작용(interactively)하여 실행될 경우, 시작한 사용자의 권한으로 작동하며 모든 기능은 회사가 이미 사용하는 ID 공급자(identity provider)에 해당 사용자의 역할을 확인합니다. 예약된 실행(scheduled run)의 경우 키보드 앞에 사람이 없으므로, 스케줄링을 한 사람의 계정으로 실행됩니다. 권한은 스킬이 도달할 수 있는 범위를 제한할 뿐이며, 잘못 설계된 스킬이 올바른 답변을 내놓게 하지는 못합니다. 그리고 의미는 기능(capability) 안에 남아 있습니다. 어떤 필드가 무엇을 의미하는지 설명하는 스킬은 그 기능의 역할을 대신하게 되었고, 다르게 설명하는 다음 스킬과 의견 충돌을 일으킬 것입니다.