1인 스타트업 실행 (3): 제품에 AI 기능 넣기#

앞 장이 “에이전트로 제품을 만드는” 이야기였다면, 이 장은 “제품 안에 AI를 넣는” 이야기입니다. 둘은 다른 문제입니다. 전자는 내가 쓰는 도구의 문제이고, 후자는 내 제품이 사용자를 위해 모델을 호출하는 구조와 비용의 문제입니다. 1인 스타트업에서 이 둘을 섞으면 비용 구조가 무너지고, 나누면 설계가 단순해집니다.

두 가지 AI 비용을 분리합니다#

3부의 API 장에서 말했듯, 코딩 에이전트의 월 구독이 같은 양을 API로 쓰는 것보다 훨씬 싸다 보니 “구독 계정을 내 서비스 백엔드에 연결하면 싸게 쓸 수 있지 않을까"라는 생각이 들기 쉽습니다. 필자도 기술적으로 가능한 경로를 조사해 봤지만, 결론은 분명했습니다. AI 구독은 할인된 API 상품이 아닙니다. 구독에는 정확한 토큰 수가 아니라 연산량 기반의 시간 단위 한도가 붙어 있고, 제공자가 워크로드를 통제할 수 있는 자기 제품 안에서만 그 경제성이 성립합니다. 서드파티가 구독 자격 증명으로 API를 호출하는 경로는 차단되거나 별도 크레딧으로 과금되고, 여러 계정의 한도를 합쳐 서버 용량처럼 쓰는 것은 약관 위반입니다. 사업의 원가 구조가 제공자의 묵인에 의존하게 되면, 그것은 최적화가 아니라 기술 부채입니다.

그래서 원칙은 단순합니다. 사람이 직접 수행하는 개발과 대화에는 구독을, 제품이 사용자를 위해 호출하는 일에는 처음부터 API 비용을 원가로 반영합니다. 이 장의 나머지는 그 API 비용을 어떻게 설계하고 줄이는지에 대한 이야기입니다.

아키텍처: 호출은 서버에서, 모델은 부품으로#

제품에 AI를 넣는 기본 구조는 3부에서 본 “사용자 앱 ↔ 내 서버 ↔ 모델 API"입니다. 여기에 1인 스타트업이 처음부터 지켜야 할 설계 원칙이 세 가지 있습니다.

첫째, API 키는 서버에만 둡니다. 클라이언트에서 직접 모델을 호출하면 키가 노출되고, 사용량을 통제할 수 없으며, 프롬프트와 로직이 그대로 드러납니다. 모든 호출은 서버를 거치고, 서버가 사용량 제한, 로그, 비용 집계, 캐시를 담당합니다.

둘째, 모델 호출을 어댑터 한 층으로 감쌉니다. 모델은 몇 달마다 바뀌고 가격도 바뀝니다. 비즈니스 로직이 특정 SDK의 응답 형식에 직접 묶여 있으면 벤더를 바꾸는 비용이 커집니다. 호출 부분을 얇게 감싸 두면 “이번 달은 어느 모델이 싸고 좋은가"를 설정 하나로 바꿀 수 있습니다. 다만 프롬프트 캐싱의 동작 방식이나 도구 호출 응답 형식 같은 세부는 벤더마다 다르므로, 어댑터가 그 차이를 흡수해야 합니다.

셋째, 호출 지점마다 등급을 정합니다. 하나의 제품 안에서도 사용자 질의 분류, 문서 요약, 최종 답변 생성은 요구하는 지능이 다릅니다. 모든 호출에 최상위 모델을 쓰면 비용이 몇 배로 뛰고, 모든 호출에 경량 모델을 쓰면 품질이 무너집니다. 호출 지점마다 “이 작업에 필요한 최소 등급"을 정하고, 다음 장에서 다룰 평가로 그 선택이 맞는지 확인합니다. 기능 하나를 설계할 때 필자는 아래 표를 먼저 채웁니다.

비용 설계의 핵심: 프롬프트 캐싱#

1장에서 토큰이 길이 단위이자 화폐 단위라고 했습니다. 제품에 AI를 넣고 나면 그 화폐의 대부분이 입력 토큰, 그중에서도 매 요청 반복되는 앞부분(시스템 지침, 도구 정의, 고정 문서)에서 나간다는 것을 알게 됩니다. 에이전트 기능이라면 더 심합니다. 매 턴 전체 이력을 다시 보내기 때문입니다. 프롬프트 캐싱은 이 반복을 제공자가 저장해 두고 훨씬 싼 단가로 계산해 주는 기능이며, 제대로 쓰면 입력 비용의 큰 부분을 줄입니다.

필자가 캐싱을 깊이 파고들어 얻은 가장 중요한 사실은 캐싱이 접두사 단위라는 것입니다. 요청의 처음부터 어느 지점까지가 이전 요청과 바이트 단위로 똑같아야 그 구간을 재사용합니다. 중간에 한 글자라도 바뀌면 그 뒤는 전부 다시 계산합니다. 그래서 캐싱 최적화는 “무엇을 캐싱할까"가 아니라 “무엇을 앞에 둘까” 의 문제이고, 프롬프트를 변경 주기가 다른 지층처럼 쌓는 것이 답입니다.

실행 지침을 효과가 큰 순서로 추리면 다음과 같습니다.

1. 시스템 지침을 빌드 타임 상수로 취급합니다. 현재 시각, 사용자 이름, 세션 ID 같은 값을 시스템 지침에 넣는 순간 캐시 적중률이 영구히 0이 됩니다. 이 하나가 0%와 90%를 가르는 경우가 가장 흔했습니다.
2. 도구 목록을 전 사용자 공통으로 고정합니다. 도구 정의는 맨 앞에 놓이므로 권한별로 목록을 나누면 회복 수단이 없습니다. 전체를 모두에게 주되 권한 검사는 실행 핸들러에서 합니다.
3. 직렬화를 결정적으로 만듭니다. 캐시 키는 렌더링된 바이트입니다. JSON 키 순서가 흔들리면 같은 내용도 다른 프롬프트가 됩니다.
4. 대화 이력은 뒤에 붙이기만 합니다. 중간을 편집하거나 잘라내면 그 지점 이후가 전부 무효화됩니다.
5. 검색 결과는 맨 뒤에 둡니다. 쿼리마다 바뀌는 것이 앞에 있으면 그 뒤가 매번 새로 계산됩니다.

그리고 한 가지 함정이 있습니다. 캐시 적중률은 목표가 아닙니다. 적중률은 비율이고 비용은 절댓값입니다. 긴 이력을 안고 돌면 적중률은 99%에 가까워지지만 요청당 비용은 계속 오릅니다. 캐시 할인은 양쪽에 똑같이 적용되므로, 컨텍스트가 열 배 크면 할인 뒤에도 열 배 비쌉니다. 적중률은 “접두사가 흔들리고 있는가"를 잡아내는 진단 지표로 쓰고, 최종 비용은 컨텍스트 총량으로 봐야 합니다. 긴 대화를 요약해 압축할지는 적중률이 아니라 “압축 비용 대비 이후 절감의 누적"으로 판단합니다. 캐시 읽기도 분당 처리량 한도에는 그대로 계산되므로, 긴 이력은 비용뿐 아니라 처리량도 잡아먹습니다.

캐싱 외에 두 가지 더 있습니다. 실시간 응답이 필요 없는 작업(야간 집계, 대량 분류)은 배치 API로 보내면 단가가 절반 수준으로 내려가는 경우가 많습니다. 그리고 모든 호출에는 예산 상한을 둡니다. 사용자별, 작업별 상한을 서버가 강제하고, 상한에 닿은 작업은 비용 문제이기 전에 “무언가 잘못되고 있다"는 신호로 다룹니다.

어디서 돌릴 것인가: 공용 API와 관리형 플랫폼#

대부분의 1인 스타트업은 벤더의 공용 API로 시작하면 됩니다. 가장 쉽고, 최신 모델을 즉시 쓸 수 있습니다. 하지만 고객이 기업이고 “우리 데이터가 외부로 나가는가"를 묻기 시작하면, 3부에서 본 배포 스펙트럼의 오른쪽으로 이동해야 합니다.

여기서 관리형 플랫폼(AWS Bedrock, Google Vertex AI, Azure 등)의 의미를 정확히 알아 두면 영업에 도움이 됩니다. 필자도 처음에는 Bedrock이 “모델 벤더로 가는 전용선"이라고 생각했지만, 실제로는 모델 가중치를 클라우드 사업자가 자기 인프라에 올려 직접 추론하는 구조입니다. 그래서 입력이 모델 벤더에게 전송되지 않고, 지정한 리전 밖으로 나가지 않으며, 학습에 쓰이지 않는다는 보장이 가능합니다. 폐쇄형 모델의 가중치는 암호화된 상태로 전달되어 검증된 실행 환경 안에서만 복호화되고, 클라우드 사업자의 운영자조차 접근할 경로가 설계상 없습니다. “믿어 달라"는 정책이 아니라 “접근할 경로 자체를 없앴다"는 구조입니다. 보안에 민감한 고객에게 제안할 때는 데이터 미학습, 리전 고정, 네트워크 격리, 접근 통제, 감사 로그, 컴플라이언스 인증을 체크리스트로 준비하면 됩니다.

관리형 플랫폼의 가격은 대개 벤더 직접 API와 같거나 비슷합니다. 추가 비용 없이 보안 보장을 얻는 셈이므로, B2B를 염두에 둔다면 처음부터 어댑터 계층에 이 경로를 열어 두는 편이 좋습니다.

에이전트 기능을 넣을 때: 루프는 빌리고 운영 계층을 소유합니다#

제품에 “대답하는 기능"이 아니라 “일을 수행하는 기능"을 넣으려면 에이전트 루프, 샌드박스, 도구 실행 인프라가 필요합니다. 앞 장에서 말했듯 이것을 바닥부터 만드는 것은 1인 개발자에게 비합리적입니다. 선택지는 두 갈래입니다.

하나는 코딩 에이전트 런타임을 실행 엔진으로 쓰는 것입니다. 격리된 작업 환경에서 공식 런타임을 실행하고, 제품은 작업 생성, 승인, 비용 추적, 결과 기록을 담당하는 운영 계층을 가져갑니다. 다른 하나는 호스팅형 에이전트 실행 환경입니다. 벤더가 에이전트 루프, 샌드박스, 세션 상태, 컨텍스트 압축, 장애 복구, 토큰 추적을 모두 내장해 제공하고, 개발자는 에이전트(모델 + 지침 + 도구)와 실행 환경(패키지, 네트워크, 비밀값)을 선언한 뒤 세션을 만들어 실행합니다. 두뇌(모델과 하네스), 손(샌드박스와 도구), 세션(컨텍스트 밖에 영속 저장되는 이벤트 로그)이 분리되어 있어서, 컨테이너가 죽어도 세션은 유지되고 새 하네스가 로그를 읽어 재개합니다.

필자는 회사에서 직접 구축한 멀티에이전트 시스템과 호스팅형 환경을 비교해 봤습니다. 기능적으로는 대체 가능했지만 트레이드오프가 있었습니다. 도구 호출이 같은 프로세스 안의 함수 호출에서 네트워크 왕복으로 바뀔 수 있고, 파이프라인의 조건 분기를 코드가 아니라 프롬프트로 제어해야 하는 부분이 생기며, 고급 기능은 아직 베타인 경우가 있습니다. 반대로 배포가 API 호출 한 번으로 끝나고 상태 관리와 장애 복구를 직접 구현하지 않아도 된다는 점은 1인 스타트업에게 큰 이점입니다. 어느 쪽이든 제품이 소유해야 할 것은 사용자 경험, 승인 구조, 작업 기록, 비용 정책, 보안 정책, 도메인 데이터이고, 루프 자체는 아닙니다.

유통: 내 제품을 사용자의 에이전트 안으로#

마지막으로, 제품에 AI를 넣는 것과 반대 방향의 선택지가 있습니다. 내 제품을 AI 안으로 들여보내는 것입니다. 2장에서 본 MCP 서버가 그 통로입니다. 내 서비스의 데이터와 기능을 MCP 서버로 노출하면, 사용자가 이미 쓰고 있는 Claude, ChatGPT, Cursor 같은 에이전트 안에서 내 제품을 호출합니다. 사용자는 새 앱을 열 필요가 없고, 나는 UI를 만들 필요가 없습니다.

이 방향이 매력적인 이유는 두 가지입니다. 첫째, 유통 비용입니다. 앱스토어나 검색에서 사용자를 데려오는 대신, 사용자가 하루 종일 머무는 에이전트 안에 내 기능이 놓입니다. 둘째, AI 비용의 이동입니다. 사용자의 에이전트가 모델을 호출하므로, 내 제품은 모델 비용 없이 데이터와 기능만 제공하면 됩니다. 사용자의 구독이 추론 비용을 내는 구조입니다. 이것이 더 넓게 열릴지(제공자가 “우리 계정으로 로그인"을 서드파티에 공식 지원하는 흐름이 시작되었지만 아직 범위가 제한적입니다)는 지켜봐야 하지만, MCP 서버 자체는 지금 바로 만들 수 있고 비용도 거의 들지 않습니다.

물론 MCP 서버를 열면 보안 책임이 생깁니다. 누가 어떤 권한으로 내 데이터를 읽고 쓰는지, 에이전트의 오호출을 어떻게 막는지, 사용량을 어떻게 제한하는지는 다음 장에서 다룹니다.

체크리스트#

1. 구독(내 도구)과 API(제품 원가)를 다른 비용 계정으로 관리합니다.
2. API 키는 서버에만 두고, 모든 호출은 서버를 거칩니다.
3. 모델 호출을 어댑터 한 층으로 감싸고, 호출 지점마다 등급과 예산 상한을 정합니다.
4. 프롬프트를 변경 주기 순으로 쌓습니다. 시스템 지침에 가변 값을 넣지 않고, 검색 결과는 맨 뒤에 둡니다.
5. 캐시 적중률이 아니라 컨텍스트 총량으로 비용을 봅니다.
6. 실시간이 아닌 작업은 배치로 보냅니다.
7. B2B 고객이 보이면 관리형 플랫폼 경로를 어댑터에 열어 둡니다.
8. 에이전트 루프는 빌리고, 운영 계층을 소유합니다.
9. 내 데이터와 기능을 MCP 서버로 노출하는 것을 유통 경로로 검토합니다.