벤더 락인 없는 AI의 미래를 만드는 방법

URL: https://www.youtube.com/watch?v=l3HyFh6Dg4w
날짜: 2026-10-15
채널: Tech Bridge
원문 제목: [한영자막] 벤더 락인 없는 AI의 미래를 만드는 방법입니다
발표자: Remy Guercio, Tailscale Strategic Projects 팀·AI Gateway Aperture 담당

---

📌 핵심 질문 / 벤더 락인을 피하는 AI 운영의 핵심 논점

==AI 사용량을 단순히 줄이거나 한 벤더로 몰아 비용을 통제하면 새로운 벤더 락인만 생긴다. LLM, 데이터 커넥터, 인터페이스, 샌드박스의 네 계층에서 선택권을 보장하고, AI 게이트웨이로 인증·예산·관찰 가능성을 중앙화해야 ROI를 키우면서도 자유롭게 교체할 수 있다.==

• 대규모 컨텍스트와 MCP, CLI 코딩 도구가 에이전트 코딩을 가능하게 했지만, 수천 개 메시지와 수천만 토큰을 소비하는 낭비도 만들었다.
• Anthropic이나 Codex 같은 특정 벤더 하나로 통합하는 방식은 당장의 청구서를 단순하게 만들 뿐, 모델·도구·워크플로의 선택권을 없앤다.
• 내부 AI 배포는 LLM, 데이터·MCP 커넥터, 사용자 인터페이스, 실행 샌드박스라는 네 계층으로 나눠 볼 수 있다.
• AI 게이트웨이는 모든 계층을 한 제품으로 고정하는 장치가 아니라, 각 계층을 교체·실험할 수 있게 인증, 라우팅, 예산, 로깅을 분리하는 제어점이다.

지난 1년의 핵심어는 토큰 최대화(Token maxing)였고, 앞으로의 핵심어는 ROI 최대화(ROI maxing)다. ROI 최대화는 비용 절감만 뜻하지 않는다. 값싼 모델을 넓게 쓰고 고성능 모델은 목적과 예산에 맞게 제한하며, 팀마다 가장 적합한 인터페이스와 실행 환경을 선택하게 해 실제 가치와 AI 활용 범위를 동시에 키우는 전략이다.

1. 토큰 최대화의 시대가 남긴 문제

대규모 컨텍스트를 활용하는 능력은 에이전트형 작업을 열었지만, 무제한 사용을 전제로 한 운영은 비용과 종속성을 빠르게 키웠다.

1.1. 지난 12개월의 기술적 도약

1. 토큰 최대화(Token maxing)의 의미

   1. 부정적 표현이 아님: AI 열성 사용자 밖에서 들리는 비판적 의미가 아니라, 백만 토큰 컨텍스트 윈도우(million-token context window)로 무엇을 할 수 있는지 탐색한 시기를 뜻한다.
   2. 어디서든 컨텍스트를 가져옴: MCP(Model Context Protocol)가 널리 퍼졌고, 코딩 도구가 CLI(Command-Line Interface)에서 컨텍스트를 찾아 모델로 가져오면서 필요한 자료를 한 작업 흐름에 모을 수 있게 됐다.

2. 에이전트형 코딩의 현실화

   1. 컨텍스트 결합: MCP뿐 아니라 파일, API, CLI 도구와 코딩 도구가 모델에 필요한 주변 정보를 찾아 넣는다.
   2. 새로운 에이전트형 사용 사례: 모든 정보를 다루는 능력이 진정한 에이전트형 코딩을 가능하게 했고, 코딩을 넘어 다른 에이전트형 업무도 계속 확장될 기반을 만들었다.

1.2. 무제한 AI 예산과 토큰 낭비

1. 비용 구조의 급변

   1. 극도로 비싼 운영: 토큰을 많이 쓰는 방식은 유용할 수 있지만 본질적으로 매우 비싸다.
   2. 무제한 예산의 종말: 지난 12개월에는 “AI 예산이 무제한”이라는 분위기가 있었으나, 최근 몇 달 사이 AI를 사용하는 방식과 비용에 대한 태도가 바뀌었다.

2. 컨텍스트를 지우지 않는 세션

   1. 수백~수천 개 메시지: AI 게이트웨이 사용량을 보면 아무도 컨텍스트를 초기화하지 않은 채 수백 또는 수천 개 메시지를 이어 가는 세션이 많다.
   2. 수천만 토큰과 캐시 포화: 세션 하나가 수천만 토큰을 소비하고 캐시가 거의 내내 최대치에 머무는 경우가 있으며, 도움이 될 때도 있지만 놀라울 정도로 비싸다.
   3. 기본값으로 발생하는 낭비: 무제한 예산은 필요 이상의 토큰을 기본적으로 쓰게 만들며, 모든 작업을 프런티어 모델과 긴 컨텍스트로 처리하게 만든다.

1.3. 수직 통합 도구 체인의 종속성

1. 모델부터 도구까지 한 생태계로 묶임

   1. 새로운 제품의 장점과 한계: Claude Code와 Codex 같은 도구는 모델에서 엔진, 도구 체인까지 위로 쌓아 올린 수직 통합 구조를 제공한다.
   2. 선택의 축소: 새로운 것을 만들고 빠르게 실험하기에는 좋지만, 모델·도구·인터페이스를 함께 바꿔야 하므로 특정 생태계에 고정되기 쉽다.

2. 해결해야 할 질문

   1. 락인 해소: 특정 모델이나 도구에 종속되지 않으면서 AI를 어떻게 운영할 것인지가 핵심 문제다.
   2. 프런티어 작업 밖으로 확장: 가장 어려운 작업만 프런티어 모델에 맡기는 것이 아니라, 낭비되는 비용과 토큰을 줄여 더 많은 업무에 AI를 적용해야 한다.

2. 단일 벤더 통합은 통제가 아니다

비용에 놀란 조직이 모든 사용자를 한 벤더로 몰아넣는 방식은 통제처럼 보이지만 선택권과 확장성을 함께 잃게 한다.

2.1. 현장에서 반복되는 공포의 패턴

1. 청구서로 문제를 인식함

   1. 매일 쌓이는 청구서: 수백 명의 AI 사용자를 만난 경험에서, 조직 담당자들은 “무슨 일이 일어나는지 모르겠고 AI를 많이 쓰고 있다”며 매일 Anthropic 청구서나 Codex 청구서를 받는다고 말한다.
   2. 재무·IT의 압박: “AI를 쓰라고 했지만 그렇게 많이 쓰라는 뜻은 아니었다”는 재무팀과 IT팀의 반응이 사용량 공포를 키운다.

2. 자연스럽지만 잘못된 처방

   1. 한 벤더로 통합: “모두가 지금 Claude Code를 쓰니 한 벤더로 통합하자”거나, 많아도 두 벤더만 쓰자는 처방이 흔하다.
   2. 통제의 착시: 사용량을 한 곳에서 보는 효과는 얻지만, 모델 경쟁과 새로운 도구를 시험할 권리, 팀별로 맞는 작업 방식을 선택할 권리를 잃는다.
   3. 패닉 상황의 심리: 비용은 많이 나갔는데 이유를 정확히 모르는 상황에서는 “일단 전부 줄여서 통제하자”는 반응이 자연스럽지만, 장기적으로 문제를 해결하지 못한다.

2.2. ROI 최대화(ROI maxing)로 전환

1. 다음 12개월의 운영 원칙

   1. 토큰 대신 가치 극대화: 다음 단계는 토큰 최대화가 아니라 ROI 최대화다.
   2. 필연적인 전환: ROI 최대화는 유행이나 단순한 비용 절감 구호가 아니라, 무제한 AI 예산이 끝난 뒤 반드시 필요한 운영 방식이다.

2. 비용 절감 이상의 의미

   1. 가치 증명: 단순히 청구액을 낮추는 것이 아니라 AI를 도입한 업무가 어떤 가치를 만들었는지 실제로 증명해야 한다.
   2. 사용 범위 확대: 프런티어 모델 두 개와 그 수직 생태계만 허용하면 비용 때문에 조직 전체로 AI를 확장할 수 없다. 저렴한 선택지와 다른 도구를 함께 열어야 더 많은 팀이 AI를 사용한다.

3. 내부 AI 배포를 네 계층으로 분해

조직 내부의 AI 배포는 애플리케이션에 새 AI 기능을 넣는 문제와 구별해야 하며, 네 가지 교체 가능한 계층으로 바라봐야 한다.

3.1. LLM 계층

1. 모델과 제공업체의 선택

   1. 모델 공급원: Anthropic, OpenAI, Vercel, Bedrock, Codex, Anthropic OAuth 등 여러 공급자를 사용할 수 있어야 한다.
   2. 용도별 선택: 같은 조직 안에서도 작업과 팀에 따라 다른 모델이 최선일 수 있으며, 모델이나 공급자를 바꿀 수 있어야 한다.

2. 예산의 차등 배분

   1. 저렴한 모델: 비교적 저렴한 모델에는 넉넉하거나 무제한에 가까운 예산을 줄 수 있다.
   2. 프런티어 모델: GLM 5.2 같은 모델을 포함해 고성능 모델에는 매우 좁은 예산을 설정해 꼭 필요한 작업에만 사용한다.

3.2. 데이터·커넥터 계층

1. 컨텍스트를 가져오는 모든 경로

   1. MCP의 대표성: 많은 조직에서 이 계층을 MCP라고 부르지만, 실제 범위는 CLI, API, 파일 읽기 등 에이전트형 시스템이 데이터를 얻는 모든 방식이다.
   2. 데이터와 모델의 분리: 데이터 커넥터를 LLM이나 특정 인터페이스에 묶지 않으면 새로운 모델과 도구를 도입할 때 인증·연동을 다시 만들 필요가 줄어든다.

2. 인터페이스 계층

   1. 빠르게 바뀌는 접점: 채팅 인터페이스에서 TUI(Text User Interface), 채팅이 들어간 IDE(Integrated Development Environment), 모바일 기기로 이동했고, 다시 CLI와 Slack에서 에이전트와 대화하는 흐름이 등장했다.
   2. 팀별 차이: 엔지니어링 팀 전체가 Slack 스레드에서 코딩하는 모습은 재미있을 수 있어도 일반적이지 않지만, 마케팅 팀은 Slack에서 데이터 질문을 하고 업무를 처리할 수 있다.

3. 샌드박스 계층

   1. 실행 환경: 에이전트가 실제로 실행되는 환경과 권한, 격리 수준을 결정한다.
   2. 독립된 선택지: 샌드박스는 모델이나 사용자 인터페이스와 별개로 바꿀 수 있어야 하며, 팀과 작업의 위험도에 따라 다른 환경을 선택할 수 있어야 한다.

3.3. 네 계층에서 선택권을 극대화

1. ROI 최대화의 운영적 정의

   1. 각 계층에서 선택: 네 계층 중 어느 곳에서든 필요할 때 선택할 기회를 최대화하는 것이 ROI 최대화다.
   2. 모든 조합을 직접 만들 필요는 없음: 각 계층마다 독특한 자체 솔루션을 만들라는 뜻이 아니라, 필요할 때 어느 계층이든 바꿀 수 있는 구조를 확보하라는 뜻이다.

2. 조직별·팀별 워크플로

   1. 개인과 팀의 차이: 조직 전체에 하나의 인터페이스를 강제하면 각 업무의 특성이 사라진다.
   2. 실험 가능성: 인증과 커넥터가 분리되면 더 싸거나 빠른 모델, 새로운 에이전트, 새로운 인터페이스를 부담 적게 시험할 수 있다.

4. AI 게이트웨이로 제어점 만들기

AI 게이트웨이는 에이전트와 각 엔드포인트 사이에 서서 모델·데이터·API 연결을 통합하고, 보안·비용·사용 흐름을 관찰할 수 있게 한다.

4.1. 게이트웨이의 기본 위치와 역할

1. 모든 엔드포인트의 중간 계층

   1. LLM 엔드포인트: 여러 LLM 공급자에 대한 연결을 게이트웨이 뒤로 모은다.
   2. 데이터 엔드포인트: MCP 엔드포인트, 일반 API 엔드포인트, 그 밖의 데이터 연결도 같은 제어점으로 통과시킨다.

2. 제어와 관찰

   1. 보안 관점: 누가 어떤 모델과 데이터에 접근하는지 통제한다.
   2. 비용 관점: 모델별·사용자별·에이전트별 사용량과 예산을 관리한다.
   3. 학습 관점: 사람이나 에이전트가 실제로 무엇을 하는지 로그로 확인하고 더 나은 워크플로를 설계한다.

4.2. 로그가 제공하는 사후 분석

1. 에이전트 폭주 진단

   1. 답을 못 낸 채 반복: 에이전트가 답에 도달하지 못하고 통제 불능으로 계속 진행하는 일이 생긴다. 예전보다 줄었지만 여전히 발생하며, 값싼 모델에서 더 자주 보일 수 있다.
   2. 중단 능력의 한계: 값싼 모델은 스스로 멈추는 데 약한 경우가 많다.

2. 실패를 학습 자원으로 전환

   1. 사후 분석 능력: 같은 모델도 사후에 어디서 잘못됐는지 분석하는 데는 뛰어날 수 있다.
   2. 로그의 가치: 게이트웨이 로그를 가리키며 “무슨 일이 있었고 왜 기대한 대로 작동하지 않았는가?”를 추적할 수 있다.

4.3. Aperture와 일반적인 키 중앙화의 차이

1. 기존 게이트웨이의 한계

   1. 키를 한곳에 모음: 일반적인 AI 게이트웨이는 사용자가 모든 API 키를 게이트웨이에 넣게 만든다.
   2. 합성 키의 재발행: 이후 각 도구에 넣을 합성 키를 다시 만들어야 하므로, “키를 몇 개의 다른 키로 바꾼 것”에 가까워질 수 있다.
   3. 현장 반응: Remy가 AI 게이트웨이를 써 본 사람에게 손을 들어 달라고 묻자 청중 일부가 반응했고, 이 키 관리 문제는 게이트웨이 사용자에게 익숙한 흐름으로 제시됐다.

2. Aperture의 기반

   1. Tailscale 네트워크: Aperture는 WireGuard 위에 구축된 ID 기반 메시 네트워크(identity-based mesh network)인 Tailscale 위에서 동작한다.
   2. TSNet: TSNet이라는 오픈소스 라이브러리로 이런 애플리케이션을 만들 수 있으며, Aperture 자체도 TSNet으로 구축됐다.

5. Tailscale ID로 키 없는 인증 구현

Tailscale tailnet 안의 연결은 연결 반대편에 있는 사용자나 기기의 정체성을 함께 전달하므로, 공유 API 키를 배포하는 대신 ID를 정책의 기준으로 삼을 수 있다.

5.1. tailnet이 전달하는 정체성

1. 다양한 실행 주체

   1. 설치 위치: Tailscale 에이전트는 컨테이너, 노트북, GPU 서버 등 필요한 곳 어디에든 설치할 수 있다.
   2. 기기·사용자 ID: tailnet을 통한 모든 연결에는 반대편 기기나 사용자의 정체성이 붙는다.

2. 태그와 노드 단위 식별

   1. 태그된 에이전트: “이 기기는 PR 리뷰 봇” 같은 태그를 붙일 수 있다.
   2. 구체적인 인스턴스: PR 리뷰 봇이라는 종류 아래에 실제 실행 인스턴스를 가리키는 별도의 노드 ID가 생긴다.
   3. 개인 사용자: Remy가 자신의 노트북에서 Claude Code를 실행하는 경우에는 Remy라는 사용자 정체성으로 접근한다.

3. 조직 그룹 연동

   1. Entra·Okta 동기화: Microsoft Entra나 Okta를 사용하면 그룹 정보를 동기화할 수 있다.
   2. 정책의 근거: 게이트웨이 반대편은 사용자, 기기, 에이전트, 소속 그룹을 모두 보고 접근 정책을 결정할 수 있다.

5.2. 네 계층을 한 정책으로 연결

1. 인증의 중앙화

   1. 추가 로그인 제거: tailnet에 연결된 Cursor, Claude Code, Codex, 특수 에이전트 프레임워크는 각각 새 계정을 만들고 다시 인증할 필요 없이 게이트웨이 엔드포인트를 호출한다.
   2. 도구 교체 비용 감소: 새 도구를 시도할 때마다 여러 서비스에 재인증하는 마찰이 사라진다.

2. 권한과 예산의 분리

   1. 모델 접근 정책: 게이트웨이는 “이 사용자는 어떤 모델과 공급자를 사용할 수 있는가”를 ID로 판단한다.
   2. 예산 정책: 저렴한 모델에는 넓은 예산을, 프런티어 모델에는 좁은 예산을 설정할 수 있다.
   3. 실험의 촉진: 인증 마찰이 줄어들면 “더 싸게 만들 수 있을까?”, “더 빠르게 만들 수 있을까?”라는 실험을 실제로 시도할 가능성이 높아진다.

6. LLM 계층과 데이터·MCP 계층의 구체적 운영

Aperture는 여러 LLM을 연결하는 게이트웨이이면서 동시에 MCP와 일반 API를 연결하는 더 넓은 의미의 AI 게이트웨이로 설계됐다.

6.1. LLM 연결을 단일 엔드포인트로 통합

1. 공급자 연결

   1. 구성된 선택지: Anthropic, OpenAI, Vercel, Anthropic OAuth, Bedrock, Codex 등 여러 공급자의 자격 증명을 게이트웨이에 넣는다.
   2. 사용자 경험: 사용자가 모델 공급자마다 별도 API 키를 만들거나 화면을 추가로 거칠 필요가 없다.

2. ID 기반 모델 노출

   1. 자동 인식: 사용자가 게이트웨이에 연결하면 Aperture가 누구인지, 어떤 종류의 에이전트인지 인식한다.
   2. 조건부 목록: 해당 ID에 허용된 모델과 공급자만 노출한다.
   3. 교체 가능성: 조직은 내부 사용자에게 동일한 연결 지점을 제공하면서 실제 백엔드 모델이나 공급자를 바꿀 수 있다.

6.2. MCP와 일반 API를 함께 다루기

1. AI 게이트웨이라는 명칭의 이유

   1. LLM 게이트웨이만이 아님: LLM 연결뿐 아니라 MCP 서버를 연결하는 MCP 게이트웨이 역할을 함께 수행한다.
   2. API의 MCP 재노출: 일반 API에 OAuth 주입을 적용하고, 그 API를 MCP로 다시 노출할 수도 있다.

2. MCP 표준의 현실

   1. 서로 다른 구현: 표준은 있지만 모든 조직과 서버가 서로 다른 버전을 따른다.
   2. 인증 방식의 역사: MCP 서버가 언제 만들어졌는지는 인증을 어떻게 결정했는지를 보면 짐작할 수 있다.
   3. 고고학적 경험: 여러 MCP 서버를 배포하고 설정하는 과정은 어떤 인증 방식을 선택했는지 추적하는 “훌륭한 고고학 수업”처럼 느껴질 정도로 제각각이다.

6.3. 조직·팀별 데이터 접근 정책

1. 관리자가 허용 목록을 구성

   1. MCP 서버 승인: 관리자는 사용할 MCP 서버를 구성하고 허용된 서버 목록을 정한다.
   2. 그룹 기반 권한: Tailscale에서 얻은 ID와 그룹 정보를 같은 정책에 사용한다.

2. 예시 정책

   1. 마케팅 팀: Google Calendar와 Gmail에 접근할 수 있다.
   2. 엔지니어링 팀: 마케팅 팀의 권한에 더해 GitHub 접근 권한을 받을 수 있다.
   3. 세부 권한: 엔지니어링 팀의 특정 하위 그룹에는 GitHub 읽기 전용 권한만 줄 수도 있다.

3. 도구와 인증의 분리

   1. 다양한 도구 수용: Cursor, Claude Code, Codex 또는 팀이 새로 찾거나 만든 에이전트 프레임워크가 무엇이든 같은 엔드포인트를 호출하면 된다.
   2. 재인증 제거: tailnet에 있다면 사용자·에이전트·태그된 기기로 인증되므로 각 도구 안에서 계속 재인증할 필요가 없다.

7. 인터페이스와 샌드박스에서 선택권 유지

사용자 인터페이스와 실행 환경을 Aperture 자체에 고정하지 않고 API와 조정 계층으로 분리하면 팀별 워크플로와 새로운 제품을 계속 수용할 수 있다.

7.1. 내장 UI와 공개 API

1. 내장 채팅 UI

   1. 즉시 사용 가능: Aperture에는 자체 채팅 UI가 내장돼 있다.
   2. 기반은 API: 내장 UI가 사용하는 기능은 외부에서도 활용할 수 있는 API 위에 구현돼 있다.

2. 새 인터페이스 제작

   1. Slack 봇: 동일한 커넥터와 정책으로 Slack 봇을 만들 수 있다.
   2. 웹·모바일·음성: 별도의 채팅 UI, 아무도 아직 생각하지 못한 모바일 앱, 음성만 사용하는 인터페이스도 만들 수 있다.
   3. 커넥터의 위치: 커넥터는 채팅 UI 안에 따로 설정하는 것이 아니라 Aperture에서 한 번 구성하고 여러 인터페이스가 공유한다.

7.2. 패스스루 인증과 가시성

1. 기존 UI의 정체성 손실

   1. Open WebUI·LibreChat류의 문제: Open WebUI나 LibreChat 같은 인터페이스를 직접 구성하면 사용자 ID와 기기 ID가 사라지고, 모든 요청이 UI 시스템 하나에서 온 것처럼 보일 수 있다.
   2. 관찰 가능성 저하: UI 뒤에 실제 사용자가 누구였는지, 어떤 기기가 요청했는지 보이지 않으면 AI 게이트웨이의 정책과 로그가 약해진다.

2. 예정된 패스스루 인증

   1. 사용자·기기 ID 전달: Aperture는 전체 패스스루 인증(pass-through authentication)을 추가해 어떤 UI를 사용하더라도 사용자와 기기 정체성을 보존하려 한다.
   2. 동일한 가시성 유지: UI를 바꿔도 AI 게이트웨이에서 기대하는 사용자·기기 단위의 로그와 통제력을 계속 얻는다.

7.3. 샌드박스의 다원화와 오케스트레이션

1. 이미 존재하는 선택의 폭

   1. 서로 다른 정의: 사람마다 샌드박스가 무엇인지, 어떤 기능이 필요한지에 대해 다른 정의를 내린다.
   2. 천 개의 꽃이 피는 단계: 공급자마다 요구사항과 취향에 맞는 샌드박스를 내놓는 “let a thousand flowers bloom” 단계에 있다.
   3. 현재의 방향: 샌드박스 공급자들은 이미 서로 잘 통합되고 있으며, 이 계층은 다른 계층보다 선택권이 비교적 잘 유지되고 있다.

2. 게이트웨이의 오케스트레이션 계층

   1. 느슨한 조정: Aperture는 샌드박스를 게이트웨이에 연결하고 조정하는 계층을 추가할 예정이다.
   2. 범용 변환 계층: 모든 환경, LLM, 데이터 커넥터를 한곳에서 보고 서로 결합할 수 있는, 대체로 범용적인 변환 계층(universal translation layer)을 지향한다.
   3. 선택의 전제: 모든 엔드포인트를 한곳에서 볼 수 있어야 각 환경에 가장 적합한 모델·데이터·샌드박스를 조합할 수 있다.

8. AI 게이트웨이의 실용적 가치

AI 게이트웨이는 벤더를 바꿔 끼우는 스위치에 그치지 않고, 에이전트 사용을 이해하고 실험을 안전하게 반복하게 하는 관찰·진단 계층이다.

8.1. 개인 사용자에게도 유효한 이유

1. 조직 규모와 무관한 로그

   1. 개인 사용: 조직에 여러 공급자를 구성하지 않더라도 개인이 자신의 에이전트 사용량과 행동을 보기 위해 AI 게이트웨이 뒤에 사용을 둘 수 있다.
   2. 행동 이해: 어떤 에이전트가 어떤 호출을 하고 얼마나 많은 컨텍스트를 소비했는지 알 수 있다.

2. 백그라운드 에이전트의 안전성

   1. OpenClaw 사례: Tailscale과 함께 tailnet에서 OpenClaw를 백그라운드로 실행하는 사용자가 있다.
   2. 예상 밖의 실행: 사용자는 “무언가를 했다는 것은 알겠는데 무엇을 했는지, 해서는 안 될 일을 했는지 모르겠다”고 느낄 수 있다.
   3. 사후 진단: AI 게이트웨이 로그로 돌아가 어떤 호출이 있었고 어디에서 잘못됐는지 확인할 수 있다.

8.2. 선택권이 곧 ROI가 되는 구조

1. 락인 방지

   1. 모델을 바꿀 자유: 비용과 성능에 맞춰 모델·공급자를 교체할 수 있다.
   2. 워크플로를 바꿀 자유: Cursor, Claude Code, Codex, Slack, 모바일, 음성 등 업무에 맞는 인터페이스를 선택할 수 있다.

2. 실험과 학습

   1. 비용·속도 실험: 인증과 커넥터가 중앙화되면 새 도구와 모델을 시험하는 전환 비용이 낮아진다.
   2. 관찰 가능한 실패: 실패한 에이전트 실행을 로그로 되짚어 원인을 파악하고 다음 시도에 반영할 수 있다.
   3. 확장 가능한 도입: 값싼 모델과 제한된 프런티어 예산을 함께 운영하면 AI를 일부 전문가의 도구에서 조직 전체의 업무 기반으로 확장할 수 있다.

주요 발언 모음

“Token maxing is cool, but it has problems.”
“토큰 최대화는 멋지지만, 문제가 있다.”

“We have unlimited AI budget.”

“We're going to be ROI maxing.”
“우리는 ROI를 최대화하게 될 것이다.”

“I’ve traded some keys for a bunch of other keys.”
“키를 몇 개의 다른 키로 바꾼 것뿐이다.”

“It’s a great archaeology lesson when you go through setting up MCP servers.”
“MCP 서버를 설정하다 보면 훌륭한 고고학 수업을 받는 기분이 든다.”

“Let a thousand flowers bloom.”
“천 개의 꽃이 피게 두는 단계다.”

“ROI maxing really is all about maximizing choice to prevent lock-in.”
“ROI 최대화는 락인을 막기 위해 선택권을 극대화하는 일이다.”

“Oh my goodness, did it do something? I’m not sure what it did.”
“세상에, 뭔가를 하긴 했는데 무엇을 했는지 모르겠다.”

핵심 데이터 & 수치

• 약 12개월: 백만 토큰 컨텍스트, 광범위한 MCP, CLI 코딩 도구를 활용한 토큰 최대화가 AI 사용의 중심이 된 기간이다.
• 수백~수천 개 메시지: 컨텍스트를 지우지 않고 계속 이어 가는 세션에서 관찰되는 메시지 규모다.
• 수천만 토큰: 일부 세션이 소비하는 토큰 규모이며, 캐시가 거의 내내 최대치에 머물러 비용을 키운다.
• 네 계층: 내부 AI 배포를 LLM, 데이터·MCP 커넥터, 인터페이스, 샌드박스로 분해한다.
• 여러 공급자: Anthropic, OpenAI, Vercel, Anthropic OAuth, Bedrock, Codex 등을 한 게이트웨이에 연결할 수 있다.
• 차등 예산: 저렴한 모델에는 넓은 예산을, 프런티어 모델에는 매우 좁은 예산을 줄 수 있다.
• WireGuard 기반: Tailscale은 WireGuard 위에서 동작하는 ID 기반 메시 네트워크다.
• 실행 주체: 컨테이너, 노트북, GPU 서버, 사용자, 태그된 봇, 봇의 개별 노드가 정책 식별자가 될 수 있다.

결론 및 시사점

1. AI 비용이 늘었다고 모든 사용자를 한 벤더에 가두면 단기 청구서는 단순해져도 모델·인터페이스·데이터·샌드박스 선택권을 잃는다.
2. ROI 최대화는 토큰 수나 비용을 무조건 줄이는 전략이 아니라, 작업의 가치에 맞는 모델과 실행 환경을 선택해 AI 사용 범위를 넓히는 전략이다.
3. 내부 AI 배포를 LLM, 데이터 커넥터, 인터페이스, 샌드박스의 네 계층으로 나누면 각 계층을 독립적으로 실험하고 교체할 수 있다.
4. AI 게이트웨이는 여러 공급자와 MCP·API를 하나의 제어점으로 연결하고, 보안·비용·사용 흐름을 관찰하게 한다.
5. Tailscale의 사용자·기기·에이전트 ID를 활용하면 공유 API 키와 합성 키를 도구마다 배포하는 대신 정체성 기반 인증과 그룹 기반 권한을 적용할 수 있다.
6. 저렴한 모델에는 넓은 예산을 주고 프런티어 모델에는 좁은 예산을 설정하면 비용 통제와 실험 가능성을 함께 얻을 수 있다.
7. Cursor, Claude Code, Codex, Slack, 모바일, 음성 인터페이스가 같은 커넥터와 정책을 공유하면 팀마다 다른 업무 방식이 공존할 수 있다.
8. 에이전트가 폭주하거나 예상 밖의 작업을 수행해도 중앙 로그를 통해 원인과 호출 흐름을 되짚을 수 있다.
9. AI 도입의 지속 가능한 기준은 특정 도구를 얼마나 많이 쓰는지가 아니라, 필요할 때 더 싸고 빠르고 적합한 선택지로 바꿀 수 있는가다.

핵심 요약 (20줄)

1. AI 업계의 지난 1년은 백만 토큰 컨텍스트와 어디서든 자료를 가져오는 토큰 최대화의 시기였다.
2. MCP와 CLI 코딩 도구는 에이전트가 필요한 컨텍스트를 찾아 진정한 에이전트형 코딩을 수행하게 했다.
3. 토큰 최대화는 강력하지만 수천 개 메시지와 수천만 토큰을 소비하는 세션을 만들 수 있다.
4. 컨텍스트를 초기화하지 않는 세션은 캐시를 계속 최대치로 유지해 비용을 크게 키운다.
5. Claude Code와 Codex 같은 수직 통합 도구 체인은 모델부터 엔진과 도구까지 한 생태계에 묶을 수 있다.
6. 비용 공포에 빠진 조직이 한 벤더나 두 벤더로 통합하는 방식은 새로운 락인을 만든다.
7. 다음 운영 원칙은 토큰 최대화가 아니라 실제 업무 가치를 증명하는 ROI 최대화다.
8. ROI 최대화는 비용만 줄이는 것이 아니라 더 많은 팀이 AI를 쓰게 하는 선택권 확대다.
9. 내부 AI 배포는 LLM, 데이터·MCP 커넥터, 인터페이스, 샌드박스의 네 계층으로 나눠야 한다.
10. 네 계층마다 자체 제품을 만들 필요는 없지만 필요할 때 바꿀 수 있는 선택권은 확보해야 한다.
11. AI 게이트웨이는 LLM, MCP, API 엔드포인트 사이에서 보안과 비용과 사용 흐름을 제어한다.
12. 중앙 로그는 답에 도달하지 못하고 폭주한 에이전트의 실행 경로를 사후 분석하게 한다.
13. 일반 게이트웨이의 합성 키 방식은 기존 API 키를 다른 키 묶음으로 바꾸는 데 그칠 수 있다.
14. Aperture는 WireGuard 기반 Tailscale tailnet의 사용자·기기·에이전트 ID를 인증에 활용한다.
15. 컨테이너와 노트북과 GPU 서버의 연결은 태그와 노드 ID로 구체적인 실행 주체를 식별할 수 있다.
16. Entra와 Okta 그룹을 동기화하면 마케팅과 엔지니어링 팀에 서로 다른 데이터 권한을 줄 수 있다.
17. 저렴한 모델에는 넓은 예산을 주고 프런티어 모델에는 매우 좁은 예산을 배정할 수 있다.
18. Cursor와 Claude Code와 Codex와 새 에이전트는 같은 인증 엔드포인트를 사용해 재인증 마찰을 줄인다.
19. API 기반 구조는 Slack 봇과 모바일 앱과 음성 인터페이스를 같은 커넥터 위에 만들게 한다.
20. 선택권과 관찰 가능성을 함께 확보하는 AI 게이트웨이가 벤더 락인 없는 ROI 확대의 기반이다.