AI 에이전트를 실무에 도입할 때, 팀은 "자체 개발할 것인가, SaaS를 구매할 것인가, 외부 파트너를 활용할 것인가, OSS를 유용할 것인가"라는 선택에 직면합니다. 이 글에서는 이러한 판단을 아키텍처와 거버넌스(Governance)의 관점에서 정리합니다. 구체적으로는 다음의 관점들을 다룹니다.

• 각 조달 수단(Build / Buy / Partner / Borrow)에 적합한 유스케이스(Use Case)와 기술적 트레이드오프(Trade-off)
• 레이어 단위로 조달처를 나누는 "하이브리드 조달" 설계 패턴
• 조달처가 혼재된 환경에서 필요한 에이전트 레지스트리(Agent Registry), 상호 운용성 표준(Interoperability Standard), 리스크 기반 분류(Risk-based Classification), 공통 거버넌스(Common Governance)

경영론이 아니라, 시스템 설계·API 연동·권한·감사·운영에 적용할 수 있는 내용을 목표로 합니다.

AI 에이전트는 단순한 API 호출이 아닙니다. **프로세스 로직(Process Logic), 컨텍스트 데이터(Context Data), 툴 연동(Tool Integration), 감사 추적(Audit Trail)**을 내포하는 실행 단위입니다. 이 실행 단위를 어디에서 조달하느냐는 다음과 같은 아키텍처 특성을 직접 결정합니다.

• 제어 경계(Control Boundary): 에이전트의 동작을 어디까지 커스터마이징 및 감사할 수 있는가
• 데이터 경계(Data Boundary): 컨텍스트나 결정 로그가 어느 환경에서 처리 및 저장되는가
• 의존 방향(Dependency Direction): 벤더의 로드맵 변경이나 OSS의 유지보수 중단에 어느 정도 영향을 받는가
• 운영 부하(Operational Load): 자체적으로 평가 하네스(Evaluation Harness)나 라이프사이클 관리를 구축해야 하는가

이 선택을 그르치면 다음과 같은 세 가지 함정에 빠지게 됩니다.

• 조기 벤더 락인(Vendor Lock-in): 프로세스 로직이나 감사를 벤더에 맡겨, 탈출 비용(Exit Cost)이 급증함
• 에이전트 사일로화(Agent Siloing): 부서마다 서로 다른 조달처·평가 기준·거버넌스로 인해 혼란이 발생함
• 무한 프로토타이핑(Infinite Prototyping): 자체 프레임워크 구축에만 매몰되어, 실제 프로덕션 유스케이스가 전혀 나오지 않음

Build가 적절한 조건: 에이전트가 다루는 로직이 자사의 경쟁 우위의 핵심이며, 독점적인(Proprietary) 데이터나 판단 규칙에 깊게 의존하는 경우. 또는 높은 감사 요구사항이나 런타임 제어가 필요한 경우.

• 차별화 로직: 보험 인수 판단, 독자적인 가격 엔진, 공급망 운영 지능 등, 구매해서 해결하면 경쟁력이 훼손되는 영역
• 고기밀 데이터·중요 제어: 리스크 판단, 고객 보호 데이터, 재무 제어 로직 등, 데이터 경계를 자사 환경 내에 가두고 싶은 영역
• 깊은 감사성 및 정책 제어: 에이전트가 사용한 컨텍스트, 호출한 툴, 판단 이유, 에스컬레이션 경로를 완전히 추적하고 설명해야 하는 영역

Build를 선택한다면 다음과 같은 기반이 갖춰져 있는 것이 전제 조건입니다.

• 에이전트 플랫폼 패턴: 오케스트레이션(Orchestration), 툴 호출, 메모리 관리의 공통 기반
• API 통합의 건전성: 내부 시스템과의 API 연동이 표준화 및 관리되고 있음
• 데이터 거버넌스의 성숙도: 데이터 권한, 보관 기간, 감사 로그 관리가 확립되어 있음
• 모델 리스크 리뷰(Model Risk Review): LLM의 출력 품질·편향성·안전성을 평가하는 프로세스
• 운영 모델: 에이전트의 소유·개선·폐기를 담당하는 팀과 라이프사이클 관리

이러한 기반 없이 Build에 돌입하면, 프로토타입이 실무에 도달하지 못하고 무한 프로토타이핑의 함정에 빠지게 됩니다.

Buy가 적절한 조건: 기능이 비교적 범용화(Commoditized)되어 있으며, SaaS나 엔터프라이즈 플랫폼으로서 성숙해 있는 영역. 차별화가 되지 않는 업무.

• 서비스 데스크 어시스턴트
• CRM 내장 영업 에이전트
• 직원 셀프 서비스 에이전트
• 지식 어시스턴트

Buy의 최대 리스크는 어느샌가 구조적 의존 상태가 되어 있다는 점입니다. 계약 전에 탈출 전략(Exit Strategy)을 명확히 해두지 않으면 되돌릴 수 없게 됩니다.

Partner가 적절한 조건: 가치 영역은 명확하지만, 구현 패턴이나 운영 준비가 갖춰지지 않은 경우. 특히 다음과 같은 상황에서 유효합니다.

• 글로벌 역량 센터(GCC)가 재무 업무의 에이전트화를 추진하고 싶지만, 운영 모델이나 거버넌스 설계 경험이 없는 경우
• 특정 도메인(예: 구매 발주 자동화)에서 처음으로 에이전트를 도입하며, 레퍼런스 아키텍처(Reference Architecture)가 필요한 경우

Partner를 선택할 때의 계약상 필수 조항:

• IP 귀속 (IP Attribution): 공동 개발한 에이전트의 지적 재산권
• 데이터 이용 제한: 파트너사의 자사 데이터 2차 이용 금지
• 운영 모델 및 SLA: 누가 무엇을 운영할 것인가, 서비스 수준 목표 (Service Level Agreement)
• 감사권 (Audit Rights): 파트너사의 보안 및 데이터 취급을 감사할 권리
• 지식 전수 계획 (Knowledge Transfer Plan): 단계적인 내재화를 위한 이행 계획

Partner는 '책임을 위임하는 것'이 아니라 '실행력을 가속하는' 수단입니다. 계약이 모호하면 소프트웨어 벤더에서 서비스 벤더로 의존처만 변경하는 것에 불과합니다.

Borrow가 적절한 조건: 본격적인 플랫폼 결정 전에 오케스트레이션 패턴(Orchestration Pattern)이나 도구 호출(Tool Calling) 요건을 검증하고 싶은 경우.

구체적인 활용 예시:

• 구매 팀이 "발주 요청을 읽고, 정책을 체크하며, 계약 데이터를 참조하고, 승인 경로를 준비하는" 에이전트를 테스트하고 싶을 때
• LangChain이나 LlamaIndex와 같은 OSS (Open Source Software) 프레임워크를 사용하여 컨텍스트 레이어(Context Layer) 설계를 단기간에 프로토타이핑할 때

Borrow의 한계:

• 컴포넌트의 품질과 보안이 천차만별임
• 장기적인 소유권이 불명확함
• OSS 의존 관계 관리 부하가 증가함
• 프로토타입이 운영 환경으로 승격되지 못하고, 프로토타이핑의 늪에 빠질 리스크

Borrow는 어디까지나 **탐색 경로 (Exploration Path)**입니다. 표준화를 늦추는 이유로 삼아서는 안 됩니다.

현실의 대기업에서는 Build / Buy / Partner / Borrow가 혼재합니다. 문제는 혼재 그 자체가 아니라, 공유 아키텍처와 거버넌스 없이 혼재가 확대되는 것입니다. 다음의 4가지를 정비하십시오.

1. 에이전트 레지스트리 (Agent Registry)

모든 에이전트를 관리하는 카탈로그입니다. 최소한 다음 사항을 기록합니다.

• 에이전트 이름 및 ID
• 비즈니스 오너 및 테크니컬 오너
• 조달원 (Build / Buy / Partner / Borrow)
• 사용 데이터 및 도구
• 리스크 레벨 (후술)
• 라이프사이클 상태 (실험 중 / 운영 중 / 폐기 예정)

레지스트리 없이는 에이전트 포트폴리오를 관리할 수 없습니다.

2. 상호 운용성 표준 (Interoperability Standards)

서로 다른 조달원의 에이전트가 동일한 에코시스템에서 동작하기 위한 표준입니다.

• ID 관리: 에이전트의 인증 및 인가 (OAuth2 / OIDC 기반)
• 도구 호출 (Tool Calling): OpenAPI 스키마를 준수하는 도구 정의
• 이벤트 (Events): 에이전트 간 또는 에이전트에서 인간으로의 핸드오프(Handoff) 이벤트 표준 형식
• 로깅 및 관측 가능성 (Logging & Observability): 공통 로그 스키마, 트레이스 ID (Trace ID), 메트릭스 (Metrics)
• 평가 (Evaluation): 에이전트의 출력 품질을 평가하는 공통 하네스 (Harness)

이러한 표준이 없으면 에이전트는 모두 고립된 섬이 됩니다.

3. 리스크 기반 거버넌스 (Risk-based Governance)

모든 에이전트에 동일한 통제를 적용하는 것은 비효율적입니다. 리스크와 비즈니스 영향도에 따라 분류하고, 그에 비례하는 통제를 적용합니다.

조달원이 무엇이든, 운영 환경에 투입되는 에이전트는 공통의 거버넌스 프로세스를 통과해야 합니다.

• 보안 리뷰
• 데이터 권한(Permission) 설정
• 평가 (오프라인 평가 + 운영 모니터링)
• 승인 임계값(Threshold) 설정
• 관측 가능성 (로그, 메트릭스, 알람)
• 인시던트 관리
• 폐기 프로세스

조달원은 달라도 엔터프라이즈 표준은 공통입니다.

4. 계층별 조달 전략 (Layered Sourcing Strategy)

하나의 유스케이스에 대해 반드시 하나의 조달원만 선택할 필요는 없습니다. 다음과 같이 레이어 단위로 최적의 조달원을 선택할 수 있습니다.

**"어느 레이어가 차별화 영역인가", "어느 레이어가 범용 제품(Commodity)인가", "어느 레이어를 가속화해야 하는가"**라는 질문이 조달 전략의 본질입니다.

---

AI 에이전트의 조달 전략은 'Build냐 Buy냐'의 이분법적 선택이 아닙니다. 제어, 속도, 차별화를 적절한 레이어에 배치하는 포트폴리오 판단입니다.

성숙한 기업은 모든 것을 자체 구축하지 않습니다. 하지만 맹목적으로 미래를 구매하지도 않습니다. 에이전트를 엔터프라이즈 역량의 포트폴리오로서 관리하며, 아키텍처의 규율, 거버넌스의 엄격함, 그리고 책임 소재를 적용합니다.

첫걸음으로, 자사의 에이전트 레지스트리를 구축하여 현재의 조달원을 가시화하는 것부터 시작하십시오.