AI 락인 없는 미래를 위한 게이트웨이 전략

URL: https://www.youtube.com/watch?v=s-glGHAa1a4 날짜: 2026-10-11 채널: AI Engineer 발표자: Remy Guercio, Tailscale Strategic Projects 팀 원문 제목: An AI Future Without the Lock-In — Remy Guercio, Tailscale 영상 길이: 19분 37초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 도입의 다음 단계는 가장 비싼 모델과 통합 생태계 하나를 고르는 일이 아니라, LLM·데이터 커넥터·인터페이스·샌드박스 각 층에서 선택권을 보존해 ROI를 극대화하는 일이다.==

• 백만 토큰 컨텍스트와 에이전틱 코딩은 가능성을 크게 넓혔지만, 비용·낭비 토큰·수직 통합형 도구 체인을 함께 만들었다.
• 비용 위기에서 단일 벤더로 통합하면 당장의 청구서를 단순화할 수 있어도 또 다른 락인과 확장 한계를 만든다.
• AI 게이트웨이는 모델 선택, 인증, 데이터 접근, 관찰 가능성, 비용 통제, 에이전트 진단을 하나의 분리된 계층으로 제공한다.
• Tailscale의 Aperture는 Tailscale의 identity-based mesh network와 AI 게이트웨이를 결합해 사용자·에이전트·기계의 신원을 보존한다.

지난 12개월의 AI 도입은 더 많은 컨텍스트를 모델에 밀어 넣는 ‘token maxing’으로 요약된다. 다음 12개월에는 저렴한 모델과 다양한 도구를 적재적소에 쓰고, 실제 가치를 증명하며, 새로운 실험을 막는 전환 비용을 줄이는 ‘ROI maxing’이 중심이 된다. 선택권을 한 곳에서 관리하는 AI 게이트웨이는 비용 절감 도구인 동시에 보안·관찰·실험을 가능하게 하는 공통 계층이다.

1. Token maxing에서 ROI maxing으로

1.1. 지난 12개월을 만든 백만 토큰 컨텍스트

1. Token maxing의 의미

   1. 거대한 컨텍스트 윈도우 활용: ‘token maxing’은 AI 열성 사용자 집단 밖에서 들리는 부정적 의미가 아니라, 백만 토큰 규모의 컨텍스트 윈도우로 무엇을 할 수 있는지 실험한 흐름을 뜻한다.
   2. 어디서든 컨텍스트 수집: MCP가 널리 퍼졌고, 코딩 도구가 CLI를 통해 필요한 컨텍스트를 찾아 모델로 가져오며, 파일·API·도구의 정보를 한 작업 흐름에 결합할 수 있게 됐다.
   3. 에이전틱 코딩의 실현: 모델이 충분한 컨텍스트를 스스로 수집하고 처리하는 능력은 진정한 에이전틱 코딩을 가능하게 했다.

2. 확장되는 에이전트 사용 사례

   1. 코딩 외 영역으로의 확장: 에이전틱 코딩이 자리 잡은 뒤 다른 에이전트 사용 사례도 계속 늘어난다.
   2. 도구와 모델의 결합: 새로운 사용 사례는 모델 하나만으로 생기지 않고, 컨텍스트를 찾는 코딩 도구·MCP·CLI·데이터 연결이 결합된 결과로 나타난다.

1.2. Token maxing이 만든 비용과 낭비

1. 높아진 추론 비용

   1. 무제한 AI 예산의 착시: 지난 1년 동안 많은 조직은 AI 예산이 사실상 무제한인 것처럼 사용했지만, 최근 몇 달 사이 AI 사용 비용을 어떻게 감당할지가 달라졌다.
   2. 토큰 규모 자체의 부담: 제대로 AI를 사용할수록 비용이 발생하며, 대규모 컨텍스트를 계속 유지하는 방식은 특히 비싸다.

2. 기본값이 된 토큰 낭비

   1. 컨텍스트를 지우지 않는 세션: AI 게이트웨이 사용량을 관찰하면 수백~수천 개 메시지로 이어지는 세션이 많고, 사용자가 컨텍스트를 비우지 않은 채 계속 진행한다.
   2. 수천만 토큰 세션: 긴 세션에는 때때로 실용적 가치가 있지만, 캐시가 거의 계속 최대치로 유지되면서 한 세션이 수천만 토큰에 이르는 사례도 있다.
   3. 모델별 차이: 저렴한 모델은 스스로 멈추는 데 약한 경우가 더 많아, 통제되지 않은 반복이나 불필요하게 길어진 세션이 자주 발생한다.

1.3. 수직 통합과 락인의 확산

1. 도구 체인의 수직 통합

   1. 모델부터 최상위 에이전트까지 묶기: Claude Code와 Codex 같은 도구는 모델 계층에서 최상위 사용자 경험까지 한 벤더의 생태계로 구축하는 방향을 보인다.
   2. 편리함과 종속성의 동시 증가: 통합된 도구 체인은 빠른 시작을 돕지만, 모델·에이전트·도구·인터페이스를 한꺼번에 교체하기 어렵게 만든다.

2. 해결해야 할 질문

   1. 락인 완화: 특정 벤더에 종속되지 않으면서 조직이 여러 모델과 사용 사례를 선택할 수 있는 방법이 필요하다.
   2. 프런티어 작업 밖으로 확장: 모든 작업에 최첨단 모델과 긴 컨텍스트를 쓰면 돈과 토큰을 낭비하므로, 더 적합하고 저렴한 방식으로 AI 사용을 넓혀야 한다.

2. 비용 공포에 대한 잘못된 대응과 ROI maxing

2.1. AI 비용 위기에서 흔히 나오는 단일 벤더 해법

1. 비용을 이해하지 못한 조직의 반응

   1. 사용량은 많은데 원인을 모르는 상황: AI 게이트웨이 사용량을 점검하는 과정에서 많은 조직이 매일 Anthropic 청구서나 Codex 청구서를 받고, AI를 많이 쓴다는 사실만 알 뿐 무엇이 비용을 만들었는지는 모르는 상태로 찾아온다.
   2. 재무팀의 압박: 회사가 AI를 쓰라고 했지만 너무 많이 쓰고 있다는 지적이 나오면, 재무팀의 질문에 대응하기 위한 즉각적인 통제책을 찾게 된다.

2. ‘모두 한 곳으로’라는 자연스러운 결론

   1. 한두 벤더로 통합: 모두가 Claude Code를 쓰는 것처럼 보인다는 이유로 한 벤더, 많아도 두 벤더를 정해 전사 사용을 통합하려 한다.
   2. 통제감의 확보: 서비스 수와 청구서를 줄이면 비용을 통제하고 있다는 느낌을 얻을 수 있다.
   3. 장기 문제의 재생산: 단일 벤더와 그 벤더의 모델·도구·인터페이스 생태계에 조직 전체가 의존하게 되므로, 비용 문제를 락인 문제로 바꾸는 셈이다.

2.2. ROI maxing의 정의

1. 비용 삭감 이상의 목표

   1. 가치 입증: ROI maxing은 단순히 청구액을 줄이는 일이 아니라, AI 사용이 실제로 어떤 가치를 만들어내는지 증명하는 일이다.
   2. 사용 가능 범위의 확대: 가장 비싼 두 개의 프런티어 모델과 그 위에 쌓인 생태계만 쓸 수 있다면 일정 비용 이하로 AI를 사용할 수 없고, 조직 전체로 확장하기도 어렵다.

2. 선택권을 통한 ROI 개선

   1. 층별 선택: 모든 층에서 특수한 독자 선택을 해야 한다는 뜻은 아니지만, 필요할 때 각 층에서 선택할 수 있어야 한다.
   2. 조직별 차이 허용: 팀과 개인마다 필요한 모델·데이터·인터페이스가 다르므로 조직 전체에 단일 사용 방식을 강제하지 않는다.
   3. 실험의 경제성: 더 싸고 빠른 모델이나 새로운 워크플로를 시도할 수 있어야 AI를 프런티어 작업에만 한정하지 않는다.

3. 내부 AI 배포를 구성하는 네 계층

3.1. 네 가지 독립 구성 요소

1. LLM 계층

   1. 모델 선택: 하나의 LLM만 고정하는 대신 작업·팀·예산에 따라 여러 LLM을 선택할 수 있어야 한다.
   2. 예산과 품질의 조정: 프런티어 모델의 높은 품질이 필요한 작업과 저렴한 모델로 충분한 작업을 구분한다.

2. 데이터 커넥터 계층

   1. MCP의 역할: 많은 조직에서 MCP가 데이터 접근 계층의 대표적인 방식이 됐다.
   2. MCP 밖의 모든 접근 방식: CLI, API, 파일 읽기 등 에이전트 시스템으로 데이터를 가져오는 모든 방법이 데이터 커넥터에 포함된다.

3. 인터페이스 계층

   1. 채팅에서 모바일·메시징으로: 출발점은 채팅 인터페이스였지만, 휴대폰에서 사용하는 방식으로 바뀌었고 Slack 스레드에서 에이전트와 대화하는 방식도 부상했다.
   2. 팀별 인터페이스: 엔지니어링 팀 전체가 Slack 스레드로만 코딩할 필요는 없지만, 마케팅 팀은 Slack에서 데이터 질문을 하고 업무를 처리하는 방식이 잘 맞을 수 있다.

4. 샌드박스 계층

   1. 에이전트 실행 환경: 샌드박스는 에이전트가 실제로 실행되는 환경이며, 네 계층 중 하나로 분리해 선택해야 한다.
   2. 요구사항의 다양성: 사람마다 샌드박스의 정의와 필요한 격리 수준이 다르므로 하나의 환경을 모두에게 강제하기 어렵다.

3.2. 계층 분리와 선택권

1. 구성 요소를 교체할 수 있는 구조

   1. 독립 교체: LLM, 데이터 커넥터, 인터페이스, 샌드박스를 서로 독립적으로 바꿀 수 있어야 전체 도구 체인을 다시 구축하지 않는다.
   2. 필요 시점의 선택: 특정 시점에 필요한 층에서 필요한 선택을 할 수 있으면, 조직의 변화와 새로운 도구를 빠르게 흡수할 수 있다.

2. 팀별로 다른 조합

   1. 엔지니어링: 코드 작업에는 IDE나 에이전트 전용 도구와 GitHub 접근, 격리된 실행 환경이 중요할 수 있다.
   2. 마케팅: Slack에서 Google Calendar·Gmail·데이터 질문을 연결하는 흐름이 더 자연스러울 수 있다.
   3. 개인 사용자: 자기 노트북에서 사용하는 Claude Code와 뒤에서 실행되는 에이전트를 같은 접근 계층으로 관리할 수 있다.

4. AI 게이트웨이와 Tailscale Aperture

4.1. 게이트웨이가 맡는 위치와 기능

1. 중간 계층의 위치

   1. 에이전트와 엔드포인트 사이: AI 게이트웨이는 에이전트와 에이전트 인터페이스, 그리고 LLM·MCP·API 같은 모든 엔드포인트 사이에 위치한다.
   2. 중앙 제어점: 여러 엔드포인트를 한 곳에서 연결하고, 조직이 원하는 조합을 독립적으로 선택할 수 있게 한다.

2. 통제와 관찰

   1. 보안 관점: 누가 어떤 모델과 데이터에 접근하는지 통제한다.
   2. 비용 관점: 모델별 사용량과 예산을 관리한다.
   3. 행동 관점: 사용자나 에이전트가 무엇을 하는지 학습할 수 있도록 사용 로그를 남긴다.
   4. 실패 진단: 에이전트가 답을 내지 못하고 통제 없이 반복하거나 작업을 망친 경우, 로그를 거슬러 올라가 무엇이 일어났는지 확인한다.

3. 로그가 주는 사후 분석

   1. 실패 지점 확인: 에이전트가 기대한 결과에 도달하지 못한 요청·도구 호출·컨텍스트 흐름을 되짚을 수 있다.
   2. 저렴한 모델의 보완: 저렴한 모델이 멈추지 못하고 반복하는 문제도 사후 분석을 통해 원인을 파악할 수 있다. 저렴한 모델은 스스로 멈추는 데는 약해도 어디서 잘못됐는지 분석하는 데는 유용할 수 있다.

4.2. Aperture와 Tailscale의 결합

1. 제품의 위치

   1. Aperture: Tailscale의 AI 게이트웨이로서 LLM 및 데이터 엔드포인트의 중앙 접근 계층을 제공한다.
   2. 특정 제품을 넘어선 권고: 핵심 주장은 Aperture를 써야 한다는 데 한정되지 않으며, 어떤 AI 게이트웨이든 조직의 선택·관찰·통제를 돕는다는 데 있다.

2. Tailscale의 네트워크 기반

   1. Identity-based mesh network: Tailscale은 WireGuard 위에 구축된 신원 기반 메시 네트워크다.
   2. 모든 필요한 위치에 에이전트 설치: 컨테이너, 노트북, GPU 서버 등 필요한 곳에 Tailscale 에이전트를 설치한다.
   3. 연결마다 신원 전달: tailnet을 통해 만들어지는 모든 연결에는 반대편 기계나 사용자의 신원이 따라온다.

4.3. 사용자·에이전트·기계의 신원

1. 기계와 에이전트의 식별

   1. 태그 기반 신원: 연결의 주체는 특정 기계 ID나 ‘PR review bot’ 같은 태그로 식별할 수 있다.
   2. 에이전트 인스턴스 구분: 하나의 PR review bot 아래에서도 실제로 실행 중인 각각의 인스턴스가 별도의 노드 ID를 받을 수 있다.

2. 사람의 신원과 그룹 정보

   1. 사용자 인증: 개인이 노트북에서 Claude Code를 사용하는 경우에도 그 사용자의 신원이 연결에 함께 전달된다.
   2. 조직 디렉터리 연동: Entra 또는 Okta를 사용하면 그룹 정보를 동기화해 사용자가 어느 그룹에 속하는지도 반대편에서 확인할 수 있다.

3. TSNet 라이브러리

   1. 오픈 소스 구성 요소: TSNet은 이런 종류의 앱을 만들기 위한 오픈 소스 라이브러리다.
   2. Aperture의 기반: Aperture가 사용자나 에이전트의 반대편 신원을 볼 수 있는 방식도 TSNet을 활용한다.

5. LLM 계층과 모델별 예산

5.1. 여러 제공자를 한 게이트웨이에 등록

1. 중앙에 모이는 자격 증명

   1. 다수의 제공자: Aperture에는 Anthropic, OpenAI, Vercel 등이 설정될 수 있으며, Anthropic OAuth와 Amazon Bedrock의 Codex 같은 방식도 한 게이트웨이에 포함할 수 있다.
   2. 사용자의 추가 키 생성 제거: 사용자가 각 LLM 제공자마다 별도 API 키와 신원을 새로 만들 필요 없이 게이트웨이에 연결한다.

2. 신원에 따른 접근 결정

   1. 자동 인식: 게이트웨이는 연결한 사용자·에이전트·기계를 알고, 해당 주체가 어떤 모델과 제공자에 접근할 수 있는지 결정한다.
   2. 도구 전환 단순화: 모델 제공자를 바꿀 때마다 새 계정과 인증 흐름을 반복하지 않아도 된다.

5.2. 모델별 예산 정책

1. 작업에 따른 예산 차등

   1. 저렴한 모델: GLM 5.2 같은 저렴한 모델에는 넉넉하거나 무제한에 가까운 예산을 부여할 수 있다.
   2. 프런티어 모델: 비용이 높은 프런티어 모델에는 매우 제한적인 예산을 부여해 꼭 필요한 작업에만 사용한다.

2. 설정의 단순성

   1. 추가 화면 최소화: 사용자는 별도의 API 키 생성·신원 생성 화면을 반복해서 거치지 않고 게이트웨이에 연결하면 된다.
   2. 조직 확장: LLM 계층을 한 곳에 모아 조직 안에서 팀별 모델 접근과 예산을 확장할 수 있다.
   3. 제공자 전환: 어떤 모델이나 제공자를 쓸지 바꿔도 에이전트·인터페이스 전체를 다시 구성할 필요가 없다.

6. MCP·API·데이터 접근 관리

6.1. AI 게이트웨이라는 더 넓은 이름

1. LLM 게이트웨이만으로 부족한 이유

   1. 데이터도 중앙화: AI 시스템은 모델뿐 아니라 데이터와 도구에도 접근하므로, 모델 호출만 중계하는 계층으로는 전체 문제를 다루기 어렵다.
   2. MCP 게이트웨이의 역할: Aperture는 LLM 게이트웨이인 동시에 MCP 게이트웨이이므로 ‘LLM 게이트웨이’보다 넓은 ‘AI 게이트웨이’라는 이름을 사용한다.

2. 기존 API의 재노출

   1. 인증 주입: 일반 API에도 인증을 주입할 수 있다.
   2. MCP로 재노출: 인증된 표준 API를 MCP로 다시 노출해 에이전트가 동일한 접근 계층을 통해 사용할 수 있다.

6.2. MCP 표준의 현실과 관리

1. 서로 다른 표준 구현

   1. 표준은 있지만 버전은 제각각: 모두가 MCP라는 표준을 따르더라도 실제 서버마다 서로 다른 버전과 인증 방식을 채택한다.
   2. 구현 시기를 드러내는 인증: MCP 서버가 어떤 방식으로 인증을 결정했는지 보면 언제 만들어졌는지 추측할 수 있다.
   3. ‘고고학 수업’ 같은 설정 경험: 여러 MCP 서버를 직접 설치하면 표준의 변천과 구현 차이를 추적하는 고고학 수업을 받는 것과 같은 경험을 하게 된다.

2. 관리자가 승인한 서버 목록

   1. 허용 목록 구성: 관리자는 조직에서 사용할 MCP 서버를 미리 설정하고 허용된 목록으로 관리한다.
   2. 검증된 내장 서버: Aperture에는 미리 점검해 사용하기 쉽게 만든 내장 MCP 서버도 있다.
   3. 클라이언트와 서버의 분리: 사용자가 쓰는 클라이언트나 인터페이스가 서버마다 제각각 인증을 처리하는 대신 게이트웨이가 공통 접근을 맡는다.

6.3. 팀·하위 팀별 권한

1. 부서별 커넥터 권한

   1. 마케팅 팀: Google Calendar와 Gmail에 접근할 수 있게 설정한다.
   2. 엔지니어링 팀: 마케팅 권한에 더해 GitHub 접근 권한을 받을 수 있다.

2. 세분화된 권한

   1. 하위 팀 분리: 엔지니어링 조직 안에서도 특정 하위 팀에만 GitHub 접근 권한을 부여할 수 있다.
   2. 읽기 전용 권한: GitHub에 대한 전체 권한 대신 read-only 접근을 부여하는 등 세밀한 정책을 설정할 수 있다.
   3. 신원 정보의 재사용: Tailscale로 전달된 사용자·에이전트·그룹 신원을 바탕으로 권한을 판단하므로 별도 도구마다 권한을 다시 만들지 않는다.

7. 인증을 한 곳에 두고 인터페이스를 열어두기

7.1. 도구를 바꿀 때 사라지는 인증 마찰

1. 다양한 클라이언트 수용

   1. 도구의 예시: 사용자는 Cursor, Claude Code, Codex, 새로 발견하거나 직접 만든 에이전트 프레임워크 중 어느 것이든 선택할 수 있다.
   2. 단일 엔드포인트: 클라이언트가 게이트웨이 엔드포인트에 연결하면 tailnet 위에서 사용자·에이전트·태그 기계의 신원으로 인증된다.

2. 재인증의 제거

   1. 반복 로그인 방지: 새 도구를 쓸 때마다 모든 서비스에 다시 로그인하고 인증하는 과정을 반복하지 않는다.
   2. 전환 비용 감소: 인증을 중앙화하면 새 도구·워크플로·경험을 실제로 시험해 보는 비용이 낮아진다.
   3. 실험을 가로막는 작은 마찰 제거: 사람들은 ‘더 싸게 만들 수 있을까’, ‘더 빠르게 만들 수 있을까’라는 생각이 있어도 작은 인증·설정 마찰 때문에 새로운 사용 사례를 시도하지 않을 수 있다.

7.2. 내장 채팅 UI보다 중요한 API

1. Aperture의 내장 채팅

   1. 기본 UI 제공: Aperture에도 내장 채팅 UI가 있다.
   2. 목적은 UI 고정이 아님: 내장 UI는 편의 기능이며, 그 위에 사용자가 직접 활용할 수 있는 API가 놓여 있다.

2. 직접 만드는 인터페이스

   1. Slackbot: 조직의 업무 흐름에 맞는 Slackbot을 만들 수 있다.
   2. 새로운 채팅 UI: 제공되는 API와 도구로 독자적인 채팅 인터페이스를 만들 수 있다.
   3. 모바일·음성 전용 경험: 아직 아무도 만들지 않은 모바일 앱이나 음성 전용 인터페이스도 같은 계층 위에서 구축할 수 있다.
   4. 커넥터의 중앙 설정: 커넥터는 채팅 UI에서 따로 설정하지 않고 Aperture에서 설정하며, UI는 Aperture를 통해 이미 구성된 커넥터를 사용한다.

7.3. 인터페이스 뒤에서도 신원 보존

1. 기존 UI의 신원 손실

   1. Open WebUI·LibreChat 유형의 문제: 이런 인터페이스를 직접 구축하면 모든 요청이 UI에서 온 것처럼 보이고, 실제 사용자나 기계의 신원 정보가 사라지는 경우가 많다.
   2. 관찰 가능성 약화: 모든 호출이 시스템 하나에서 발생한 것처럼 기록되면 어떤 사용자가 어떤 에이전트를 통해 무엇을 했는지 알기 어렵다.

2. 계획된 pass-through OAuth

   1. 신원 전달: Aperture는 향후 full pass-through OAuth를 추가해 사용 중인 인터페이스를 통과하더라도 사용자 및 기계 신원을 볼 수 있게 할 계획이다.
   2. AI 게이트웨이 가시성 유지: 어떤 UI를 사용하든 AI 게이트웨이에서 기대하는 수준의 사용자·기계별 가시성을 유지한다.

8. 샌드박스 선택과 게이트웨이 오케스트레이션

8.1. 이미 존재하는 샌드박스 선택지

1. 다양한 정의

   1. 사람마다 다른 요구: 샌드박스가 무엇인지, 어느 정도의 격리가 필요한지, 어떤 기능을 원하는지에 대해 사람마다 답이 다르다.
   2. 풍부한 공급자: 이런 정의의 다양성 때문에 샌드박스 분야에는 온갖 요구와 취향에 맞는 공급자가 생겨났다.

2. ‘천 송이 꽃을 피우자’ 단계

   1. 실험적 생태계: 샌드박스 생태계는 ‘let a thousand flowers bloom’ 단계처럼 다양한 접근이 동시에 자라는 상태다.
   2. 통합의 진전: 각 공급자는 이미 다른 시스템과의 통합을 꽤 잘 수행하고 있다.

8.2. 샌드박스 오케스트레이션 계층

1. 게이트웨이에 추가될 기능

   1. 환경 선택의 중앙화: Aperture는 샌드박스를 AI 게이트웨이에서 오케스트레이션하는 계층을 추가할 예정이다.
   2. 독립된 실행 환경 유지: 게이트웨이는 샌드박스를 하나로 통일하기보다 여러 환경을 선택하고 연결하는 지점을 제공한다.

2. 보편적 변환 계층

   1. 모든 엔드포인트를 한곳에서 보기: 최적의 선택을 하려면 환경, LLM, 데이터 커넥터 등 서로 다른 엔드포인트를 한곳에서 볼 수 있어야 한다.
   2. 서로 바꿔 쓰기: 한곳에서 연결된 요소를 다른 요소와 조합해 사용할 수 있어야 한다.
   3. 거의 보편적인 번역 계층: AI 게이트웨이는 각기 다른 환경·모델·데이터 커넥터를 서로 연결하는 거의 보편적인 변환 계층처럼 작동한다.

9. AI 게이트웨이가 주는 운영 가치

9.1. 락인 방지 이상의 가치

1. 선택권 극대화

   1. ROI maxing의 핵심: ROI를 극대화하는 일은 단순한 지출 축소가 아니라 선택지를 최대한 늘려 락인을 피하는 것이다.
   2. 비용·속도 실험: 여러 모델과 도구를 비교하면 특정 모델에만 의존하지 않고 작업별 비용과 속도를 개선할 수 있다.

2. 조직 전체 확장

   1. 고비용 구조의 한계 탈피: 두 개의 프런티어 모델과 각각의 생태계만 쓰는 구조는 조직 내 AI 확장을 비싸게 만든다.
   2. 계층별 최적화: 필요한 작업에는 프런티어 모델을 쓰고 반복·저위험 작업에는 저렴한 모델과 적절한 샌드박스를 배치해 AI 사용 범위를 넓힌다.

9.2. 개인 사용자도 얻는 관찰 가능성

1. 개인용 게이트웨이

   1. 조직에만 필요한 도구가 아님: AI 게이트웨이는 여러 제공자를 관리해야 하는 기업뿐 아니라 개인 사용자에게도 유용하다.
   2. 에이전트 행동 확인: 개인이 자신의 에이전트 사용을 게이트웨이 뒤에 두면 에이전트가 실제로 무엇을 하는지 확인할 수 있다.

2. OpenClaw와 tailnet 사례

   1. 백그라운드 에이전트: OpenClaw를 Tailscale과 함께 tailnet에 올려 백그라운드에서 실행하는 사용 사례가 있다.
   2. 예상 밖의 행동: 사용자는 ‘무언가를 했는데 무엇을 했는지 모르겠고, 해서는 안 될 일을 한 것 같다’고 느낄 수 있다.
   3. 문제 재현과 진단: AI 게이트웨이 로그를 확인하면 에이전트가 어디서 잘못됐고 무슨 요청과 도구 호출을 거쳤는지 되짚을 수 있다.
   4. 실험과 이해: 따라서 게이트웨이는 락인 방지뿐 아니라 에이전트 실험을 안전하게 하고 그 행동을 이해하는 수단이다.

9.3. 마무리 메시지

1. 실행 권고

   1. AI 게이트웨이 검토: Aperture를 선택하지 않더라도 조직과 개인 모두 AI 게이트웨이 도입을 검토할 필요가 있다.
   2. 모델 전환 이상의 효과: 게이트웨이는 세 제공자를 번갈아 쓰는 편의성만 제공하는 것이 아니라, 보안·비용·신원·관찰·실험을 하나의 운영 계층으로 묶는다.

2. 행사의 마지막 발표

   1. 짧고 압축된 발표: 19분 남짓한 마지막 세션으로서 선택권, 게이트웨이, 관찰 가능성에 관한 메시지를 압축해 마무리했다.
   2. AI Engineer World’s Fair: AI Engineer World’s Fair에 대한 만족과 참석자들의 좋은 컨퍼런스 경험을 바라는 인사로 끝맺었다.

주요 발언 모음

“Token maxing은 멋지지만, 명백한 문제가 있다. 매우 비싸다.”

“우리는 token maxing이 아니라 ROI maxing을 하게 될 것이다.”

“ROI maxing은 단지 비용을 줄이는 뜻이 아니다. 실제로 무엇인가의 가치를 증명하는 뜻이다.”

“내부 AI 배포에는 LLM, 데이터 커넥터, 인터페이스, 샌드박스라는 네 가지 구성 요소가 있다.”

“ROI maxing은 락인을 막기 위해 선택을 극대화하는 일이다.”

“AI 게이트웨이는 락인만을 위한 것이 아니다. 실험과 이해 전체를 위한 것이다.”

“Aperture를 쓰지 않더라도 AI 게이트웨이를 검토하기 시작하길 강하게 권한다.”

핵심 데이터 & 수치

• 영상 길이: 19분 37초다.
• 관찰된 세션 규모: AI 게이트웨이 사용량에서 수백~수천 개 메시지로 이어지고 컨텍스트를 지우지 않는 세션이 발견된다.
• 토큰 낭비 규모: 일부 세션은 캐시가 거의 계속 최대치인 상태로 수천만 토큰을 사용한다.
• 컨텍스트 규모: 최근 AI 흐름은 백만 토큰 컨텍스트 윈도우를 활용하는 방향으로 전개됐다.
• 구성 계층 수: 내부 AI 배포는 LLM, 데이터 커넥터, 인터페이스, 샌드박스 네 계층으로 나뉜다.
• 모델 예산 예시: GLM 5.2 같은 저렴한 모델에는 넉넉한 예산을, 프런티어 모델에는 매우 제한적인 예산을 줄 수 있다.
• 네트워크 기반: Tailscale은 WireGuard 위에 구축된 identity-based mesh network다.
• 통합 신원: Tailscale 연결은 사용자, 태그 기계, 에이전트 인스턴스, Entra·Okta 그룹 정보를 전달할 수 있다.

결론 및 시사점

1. AI 운영의 기준을 “어떤 모델을 고정할까”에서 “각 작업에 어떤 선택을 열어둘까”로 바꿔야 한다.
2. 비용이 급증했을 때 단일 벤더로 서둘러 통합하면 단기 통제감은 얻지만 장기적인 락인을 강화할 수 있다.
3. LLM, 데이터 커넥터, 인터페이스, 샌드박스를 독립된 계층으로 분리하면 팀별·작업별 최적 조합을 만들 수 있다.
4. AI 게이트웨이는 모델 호출 중계기가 아니라 보안 정책, 비용 예산, 사용자·에이전트 신원, 로그, 실패 진단을 모으는 운영 계층이다.
5. MCP 표준의 구현 차이와 일반 API 인증을 중앙에서 흡수하면 에이전트 도구를 교체하는 전환 비용이 줄어든다.
6. Tailscale 같은 신원 기반 네트워크를 결합하면 UI 뒤에 숨은 실제 사용자와 기계의 신원을 보존할 수 있다.
7. 저렴한 모델에는 넓은 예산을, 프런티어 모델에는 좁은 예산을 배정하는 방식이 비용과 품질 사이의 선택지를 만든다.
8. 개인 사용자는 OpenClaw 같은 백그라운드 에이전트의 로그를 AI 게이트웨이로 확인해 예상 밖 행동을 진단할 수 있다.
9. 최종 목표는 Aperture라는 특정 제품에 종속되는 것이 아니라, 여러 모델·데이터·인터페이스·샌드박스를 자유롭게 바꿀 수 있는 AI 운영 구조를 갖추는 것이다.
10. ROI maxing은 비용 절감, 실험 확대, 에이전트 이해, 조직 확장을 함께 달성하기 위한 선택권 극대화 전략이다.