AX LABS
← 블로그 AX 전략

락인은 런타임에서 온다

모델 교체보다 실행층 분리가 먼저다

AX LABS 4분 읽기

현장에서 에이전트 논의는 대개 모델 비교로 시작한다. 어떤 모델이 더 잘 추론하는지, 더 싸게 호출되는지, 더 긴 컨텍스트를 주는지가 먼저 올라온다. 그런데 실제 락인은 모델명에서 생기지 않는다. 한 번 만든 tool schema, memory store, guardrail, tracing, approval flow가 특정 SDK와 콘솔에 붙을 때 생긴다.

락인은 모델이 아니라 실행 경계에서 생긴다

에이전트는 단순 API 호출이 아니다. 사용자의 요청을 해석하고, 도구를 고르고, 권한을 확인하고, 중간 결과를 저장하고, 실패하면 재시도한다. 이 반복 루프가 곧 런타임이다.

벤더 SDK는 이 루프를 빠르게 시작하게 해준다. OpenAI Agents SDK는 Responses API 기반의 에이전트 실행, handoff, guardrail, tracing을 제공한다. Anthropic Claude Agent SDK는 MCP 연동과 hooks를 통해 실행 중 개입 지점을 제공한다. Google ADK는 모델·도구·멀티에이전트 구성을 프레임워크로 다룬다. 모두 쓸 만하다. 문제는 어느 하나를 업무 운영의 유일한 실행 언어로 만들 때다.

모델은 바꿀 수 있다. 런타임에 묻힌 업무 규칙은 쉽게 못 바꾼다.

추상화는 세 겹으로 나눠야 한다

락인을 피한다는 말은 “아무 벤더도 쓰지 말자”가 아니다. 벤더 기능은 써야 한다. 다만 업무 핵심을 벤더 고유 객체에 직접 쓰지 않는다.

계층 추상화 대상 내부에 남길 것 벤더에 위임할 것
모델 계층 모델명, 파라미터, structured output 평가 기준, fallback 정책 추론 성능, 토큰 처리
도구 계층 tool schema, MCP server, 권한 업무 API 계약, 감사 로그 connector, function calling
런타임 계층 memory, orchestration, HITL, tracing 상태 전이, 승인 규칙, 실패 처리 SDK 실행기, sandbox, dashboard

이 구분이 없으면 교체 비용이 누적된다. “나중에 추상화하자”는 말은 대개 실패한다. PoC 때 만든 호출 구조가 운영 표준이 되고, 운영 표준이 예산 구조가 된다.

따라서 첫 설계 산출물은 아키텍처 그림이 아니라 교체 가능한 경계표다. 어느 계층을 3개월 안에 바꿀 수 있어야 하는지, 어느 계층은 1년 동안 고정할지, 어떤 로그와 평가 데이터가 벤더 밖에 남아야 하는지를 먼저 정한다.

표준은 선택지를 늘리지만 책임을 없애지 않는다

최근 1년의 방향은 분명하다. MCP는 모델과 외부 도구·데이터 연결을 표준화하는 축으로 자리 잡고 있다. A2A는 에이전트 간 통신과 협업을 별도 계층으로 분리하려는 흐름이다. OpenAI, Google, Anthropic, Microsoft, AWS 문서는 모두 모델 단독 호출보다 agent harness, tool orchestration, tracing, guardrail을 전면에 둔다.

하지만 표준을 쓴다고 락인이 사라지지는 않는다. MCP server를 특정 인증 방식, 특정 데이터 스키마, 특정 approval flow에 묶으면 또 다른 내부 락인이 생긴다. A2A를 붙여도 agent identity와 권한 위임을 설계하지 않으면 운영팀은 장애 원인을 추적하지 못한다.

AX 전략에서 표준은 “탈출구”가 아니라 “경계 언어”다. 표준 위에 어떤 운영 규칙을 얹을지 정해야 한다.

참고와 다음 결정이 분리되면 안 된다

참고한 최근 12개월 내 1차 출처는 다음과 같다.

지금 정할 것은 “어느 벤더가 이길까”가 아니다. 우리 업무 규칙이 어느 계층에 남아야 하는지다. 모델은 빠르게 바뀐다. 런타임은 조직의 운영 방식으로 굳는다. 에이전트 투자를 장기 자산으로 만들려면 모델 추상화보다 런타임 추상화를 먼저 설계해야 한다. 이 경계 설계부터 운영 정착까지 한 사이클로 다루는 접근은 AX Ops 방법론 →에서 확인할 수 있다.