[AI Agent] 서비스 안에 Agent를 넣을 때 Tool 실행과 비용 주체 나누기

외부 AI Agent에 API를 공개하는 방법을 검토한 뒤, 서비스 자체에 채팅형 Agent를 넣는 구조도 비교했다. AI가 요청한 기능을 어디서 실행하고, 모델 사용 비용과 데이터 권한을 누구의 책임으로 둘지 정리했다.

시작하며

처음에는 ChatGPT나 Claude 같은 외부 Agent가 서비스 API를 호출하게 만드는 방법을 검토했다. MCP 서버를 따로 두는 방식과, 로그인된 웹페이지에서 데이터 조회 같은 기능을 AI가 호출할 수 있도록 제공하는 방식을 비교했다.

MCP에서는 AI가 호출할 수 있도록 제공하는 기능을 '도구(Tool)'라고 부른다. 이 글에서는 기존 서비스 API에 연결된 조회와 처리 기능을 뜻한다. 예를 들어 '기간별 통계 조회'라는 도구에는 기능 설명과 시작일, 종료일 같은 입력값 형식을 등록한다. AI가 이 기능을 선택하면 연결된 코드가 통계 조회 API를 호출하고 결과를 돌려준다.

로그인된 웹페이지에서 제공하는 경우에는 페이지의 코드가 기존 로그인 세션으로 API를 요청한다. AI는 등록된 기능 중 필요한 것을 선택하고 입력값을 전달한다.

이 두 방식을 비교하면서 한 가지 선택지가 더 생겼다.

사용자가 외부 Agent를 찾아가는 대신, 기존 서비스 안에 채팅 화면을 만들고 백엔드가 모델을 호출하는 방식이다.

사용자
  -> 서비스의 채팅 화면
     -> AI Agent 애플리케이션
        -> 모델 API
        -> 업무 API 호출 기능
           -> 기존 API와 데이터

검토를 시작할 때는 외부 Agent에 API를 열어 주는 구조와 서비스 안에 채팅 기능을 만드는 구조를 같은 선택지로 비교했다. 하지만 호출 흐름을 그려 보니 사용자가 대화하는 화면부터 달랐다. 전자는 외부 제품이 대화를 관리하고, 후자는 내가 만드는 서비스가 대화 상태와 모델 호출을 관리해야 했다.

그래서 세 가지 결정을 따로 정리했다.

• 모델이 요청한 도구의 실행 위치
• 사용자의 데이터 접근 권한을 검사하는 계층
• 서비스와 사용자 사이의 모델 비용 부담 방식

이 세 가지를 하나로 묶으면 인증과 결제 방식 하나를 바꿀 때 전체 구조가 흔들린다. 그래서 Agent 실행 위치, 업무 데이터 권한, 모델 비용 주체를 서로 다른 축으로 나눠 비교했다.

이 글에서 말하는 서비스 내부 Agent는 모델까지 직접 운영한다는 뜻이 아니다. 채팅 UI와 Agent 오케스트레이션은 서비스가 소유하지만, 추론은 외부 모델 API에 요청할 수 있다. 자체 모델 호스팅은 별도의 인프라 선택이다.

현재까지는 구조와 도입 조건을 검토한 단계다. 이 글에는 호출 경로를 비교하면서 바꾼 판단과 구현 전에 정리한 기준을 담았다.

검토하면서 혼동했던 부분	다시 정리한 기준
MCP 서버를 만들면 서비스 채팅 기능도 완성됨	채팅 UI, 대화 상태와 모델 호출 반복은 별도로 필요
사용자 계정으로 로그인하면 그 플랜을 바로 사용 가능	계정 식별과 추론 사용 동의, 앱의 참여 자격을 각각 확인
사용자에게 비용을 넘기려면 구독 플랜 연동이 필수	사용자 API Key를 받는 BYOK도 비교하되 Key 보관 책임 포함
모델이 도구를 호출하므로 모델이 업무를 실행함	호출을 선택하는 모델과 실제 API를 실행하는 서버를 구분

Agent 구조를 네 영역으로 나눴다

Agent라는 이름 아래에 UI, 모델, 도구와 업무 권한이 섞이기 쉬웠다. 먼저 책임을 다음처럼 분리했다.

영역	맡는 책임	바뀌지 않아야 할 기준
채팅 UI	질문 입력, 응답 표시, 실행 승인	기존 서비스 로그인 세션
Agent 애플리케이션	대화 상태, 모델 호출, 도구 실행 반복	호출 횟수와 실행 한도
모델 제공자	응답 생성, 도구 선택	모델 사용 자격과 과금
기존 백엔드	실제 조회와 변경, 데이터 권한 검사	서비스의 사용자 권한

가장 중요하게 본 것은 모델 제공자의 사용자와 서비스의 사용자를 같은 계정으로 취급하지 않는 것이다.

예를 들어 사용자가 OpenAI 계정으로 모델 사용을 승인하더라도, 그 계정이 어떤 업무 데이터를 볼 수 있는지는 알 수 없다. 데이터 권한은 기존 서비스 로그인으로 확인한 내부 사용자 ID를 기준으로 판단해야 한다.

모델 사용 자격
  -> 어떤 모델을 누구의 비용으로 호출할 수 있는가

서비스 데이터 권한
  -> 로그인한 사용자가 어떤 자원에 접근할 수 있는가

둘을 섞으면 외부 계정 연결을 바꾸는 순간 내부 권한까지 달라질 수 있다. 모델 제공자의 토큰은 모델 호출에만 사용하고, 업무 도구는 기존 서비스 세션에서 복원한 사용자 정보로 실행하도록 경계를 잡았다.

Agent 애플리케이션이 API를 직접 호출하는 경로

첫 번째 방법은 Agent 애플리케이션이 도구의 이름, 설명과 입력값 형식인 스키마를 모델에 전달하는 것이다. 모델이 사용할 도구와 입력값을 반환하면 애플리케이션 코드가 이를 검증하고 기존 API를 호출한다. 이처럼 모델이 실행할 함수를 지정하도록 하는 방식을 Function Calling이라고 한다.

Agent 애플리케이션
  -> 모델에 호출 가능한 기능과 입력값 형식 전달
  <- 모델이 실행할 기능 이름과 입력값 반환
  -> 인자 검증
  -> 기존 API 호출
  <- API 호출 결과
  -> 결과를 모델에 전달
  <- 최종 응답

직접 실행 경로는 다음 의사코드처럼 구성할 수 있다. 호출 이력에는 모델의 도구 요청과 각 결과를 짝지어 보존하고, 단계 상한을 먼저 검사한다.

let response = await model.respond({
  input: messages,
  tools: toolDefinitions,
});

let rounds = 0;
let toolCalls = 0;

while (hasToolCalls(response)) {
  if (++rounds > limits.maxRounds) throw new Error("모델 호출 단계 초과");
  const outputs = [];

  for (const call of getToolCalls(response)) {
    if (++toolCalls > limits.maxToolCalls) throw new Error("도구 호출 한도 초과");
    assertAllowedTool(call.name);
    const args = validateArguments(call.name, call.arguments);
    const result = await executeWithUserContext(call.name, args, user);

    outputs.push({
      callId: call.id,
      output: minimizeToolResult(result),
    });
  }

  response = await model.respond({
    previousResponseId: response.id,
    toolOutputs: outputs,
  });
}

이 방식은 도구 수가 적을 때 시작하기 쉽다. 기존 백엔드의 SDK나 내부 API 클라이언트를 그대로 호출할 수 있고, 실행 승인과 감사 로그도 Agent 애플리케이션 안에서 통제할 수 있다.

하지만 외부 Agent용 MCP 서버도 함께 만들 계획이라면 같은 기능의 입력과 응답 규약을 두 번 구현할 수 있다.

서비스 내부 Agent용 함수
  -> 자원 조회 API 호출

외부 Agent용 MCP 도구
  -> 같은 자원 조회 API 호출

두 구현의 입력 스키마, 권한 검사와 응답 축약 규칙이 조금씩 달라지면 어느 Agent를 사용했는지에 따라 결과가 달라진다. 직접 실행 방식이 나쁜 것이 아니라, 도구를 제공할 채널이 하나인지 여러 개인지 먼저 봐야 했다.

중복을 줄이는 방법이 MCP만 있는 것은 아니다. 공통 업무 함수를 만들고 Function Calling용 함수와 MCP 도구를 얇은 어댑터로 붙일 수도 있다. MCP의 이점은 같은 구현을 공유하는 데 더해, 서로 다른 클라이언트에 표준화된 도구 인터페이스를 제공하는 데 있다.

MCP 서버를 API 호출 창구로 재사용하는 경로

두 번째 방법은 Agent 애플리케이션이 Remote MCP 서버를 모델에 연결하는 방식이다.

Agent 애플리케이션
  -> 모델 API에 MCP 서버 주소와 허용된 도구 전달
     -> 모델 실행 인프라가 MCP 도구 호출
        -> MCP 서버가 기존 API 호출
           -> 기존 백엔드가 데이터 권한 검사

OpenAI Responses API는 Remote MCP 서버의 도구를 연결하는 기능을 제공한다. 이 경로에서는 OpenAI 인프라가 MCP 요청을 보내고, 실제 업무 함수는 MCP 서버가 실행한다. OpenAI MCP 서버 문서

{
  "type": "mcp",
  "server_label": "service-tools",
  "server_url": "https://api.example.com/mcp",
  "allowed_tools": ["get_resource_summary"],
  "require_approval": "always"
}

이 경로의 장점은 서비스 내부 Agent와 외부 Agent가 하나의 기능의 입력과 응답 규약을 사용할 수 있다는 점이다.

MCP 클라이언트를 내 Agent 서버 안에 두고 직접 호출하는 구성도 가능하다. 따라서 "MCP를 쓰면 공급자 인프라가 호출한다"는 설명은 위의 Responses API 관리형 경로에 해당한다.

require_approval을 설정하는 것만으로 사용자 승인 화면이 생기지는 않는다. 애플리케이션이 승인 요청을 받아 사용자에게 보여 주고, 승인 또는 거부 결과를 API에 전달해야 한다. 인증이 필요한 MCP 서버에는 그 서버를 대상으로 발급된 자격 증명도 별도로 연결해야 한다.

비교 항목	직접 Function Calling	MCP 서버 재사용
초기 구현	Agent 애플리케이션 안에서 바로 시작 가능	MCP 서버와 인증 경로 필요
기능의 입력과 응답 규약 위치	Agent 애플리케이션 코드	MCP 서버
외부 Agent 연동	별도 구현 필요	같은 도구 재사용 가능
호출 경로	Agent 애플리케이션에서 기존 API로 직접 연결	모델 제공자, MCP 서버, 기존 API를 거침
승인과 허용 목록	애플리케이션이 직접 통제	API 옵션과 MCP 서버 양쪽에서 통제
장애 범위	Agent 애플리케이션과 기존 API	모델 제공자, MCP 서버와 기존 API

MCP를 사용한다고 보안 책임이 사라지지는 않는다. 도구 허용 목록, 실행 전 승인, 인자 검증과 결과 축약은 여전히 필요하다. 모델이 요청한 도구 이름과 인자를 그대로 신뢰해 내부 API를 호출해서도 안 된다.

또한 Remote MCP를 사용하면 도구에 전달한 데이터가 모델 제공자와 MCP 서버 경로를 통과한다. 공식 문서도 신뢰할 수 있는 서버 사용, 민감한 작업의 승인과 전송 데이터 기록을 권고한다. 도구 재사용의 편의성만 보고 모든 내부 기능을 한꺼번에 노출할 수는 없었다.

호출할 기능이 늘면 설명과 입력값 정의도 비용이 된다

Function Calling과 MCP 모두 모델이 도구를 선택하려면 이름, 설명과 입력 스키마를 알아야 한다. 도구가 수십 개로 늘어나면 사용하지 않는 정의도 입력 Context를 차지한다.

사용자 질문
  + 시스템 지침
  + 대화 이력
  + 호출 가능한 기능의 설명과 입력값 정의
  + API 실행 결과
  -> 모델 입력 Token

처음에는 도구 호출 한 번을 일반 API 호출 한 번처럼 생각했다. 그러나 Agent의 한 작업은 보통 다음과 같이 모델 호출이 반복된다.

1차 모델 호출: 어떤 기능을 호출할지 결정
  -> API 호출
2차 모델 호출: API 호출 결과 해석
  -> 필요하면 다른 API 호출
3차 모델 호출: 최종 답변 생성

따라서 비용은 최종 답변 길이만으로 결정되지 않는다.

한 요청의 모델 비용
  = 각 모델 호출의 입력 Token 비용 합계
  + 각 모델 호출의 출력 Token 비용 합계

도구 호출이 늘면 대화 이력과 앞선 도구 결과가 다음 모델 입력에 다시 들어갈 수 있다. 특히 시계열 원본, 긴 로그와 대량 목록을 그대로 반환하면 도구 실행 자체는 저렴해도 다음 모델 호출 비용이 커진다.

도구 응답에는 모델이 판단하는 데 필요한 정보만 남기기로 했다.

예를 들어 "지난주 오류가 가장 많았던 서비스를 알려줘"라는 요청에 전체 로그를 반환할 필요는 없다. 서버에서 기간과 권한을 확인한 뒤 서비스별 오류 수, 집계 구간과 대표 오류 몇 개를 반환하는 도구를 검토할 수 있다. 원본 로그는 사용자가 상세 분석을 요청할 때 추가 조회한다. 이때 집계 기준과 누락 여부를 함께 전달해야 모델이 요약 수치를 전체 데이터로 오해하지 않는다.

피해야 할 응답	Agent용 응답
수천 건의 원본 행	기간별 요약과 이상 구간
화면 표시용 모든 필드	판단에 필요한 ID, 상태와 핵심 수치
전체 로그 본문	오류 전후의 제한된 구간
무제한 검색 결과	상한이 있는 목록과 다음 페이지 정보

도구 수가 많다면 모든 스키마를 처음부터 전달하지 않고 검색이나 지연 로딩을 사용한다. 실행 횟수에도 상한을 둬, 같은 조회를 표현만 바꿔 반복하는 루프가 비용과 부하를 계속 늘리지 않게 해야 한다.

모델 비용을 부담하는 네 가지 방법

Agent가 서비스 안에서 동작해도 비용을 반드시 서비스가 내야 하는 것은 아니다. 검토한 선택지를 다음처럼 나눴다.

방식	모델 호출 자격 증명	비용 부담	장점	부담
서비스 API Key	서버가 관리하는 Key	서비스 운영자	사용자가 별도 설정 없이 바로 사용	사용량 증가와 악용 비용을 운영자가 부담
Sign in with ChatGPT	사용자가 별도로 승인한 OAuth 권한	자격을 갖춘 사용자의 ChatGPT 플랜 또는 크레딧	API Key 복사 없이 연결 가능	지원 범위와 상용 앱 승인 조건 확인 필요
BYOK	사용자가 등록한 API Key	사용자 API 계정	공급자 선택과 비용 분리가 명확	Key 보관 책임과 높은 설정 난이도
자체 모델 운영	서비스의 추론 인프라	서비스 운영자	외부 API 의존과 데이터 전송 범위 축소 가능	GPU, 배포, 확장, 장애와 모델 운영 비용

여기서 자체 모델 운영은 Agent 애플리케이션을 우리 서버에 두는 것과 다르다. Agent 서버가 외부 모델 API를 호출하는 구조도 충분히 가능하다. 모델까지 자체 운영할지는 데이터 정책, 지연 시간, 품질과 운영 역량을 별도로 비교해야 한다.

서비스 API Key

가장 단순한 초기 구조다. 서버가 모델 제공자의 API Key를 보관하고 모든 사용자의 요청을 대신 호출한다.

사용자 경험은 좋지만 한 사용자의 반복 요청이나 도구 루프가 서비스 전체 비용으로 이어진다. 다음 제한을 함께 두지 않으면 출시 후에야 비용 구조를 알게 된다.

• 사용자별 일간과 월간 Token 한도
• 요청당 최대 모델 호출 횟수
• 요청당 최대 도구 호출 횟수
• 허용 모델과 최대 출력 Token
• 동시 실행 수와 전체 실행 시간
• 조회 도구와 데이터 변경 기능의 별도 승인 정책

Sign in with ChatGPT

2026년 10월 공식 문서를 기준으로, OpenAI의 Sign in with ChatGPT는 계정 로그인과 ChatGPT 플랜 사용 권한을 구분한다. openid profile email로 사용자를 식별하는 것과 Responses API 사용을 승인하는 것은 별도 동의다. 자격을 갖춘 사용자는 승인된 앱에서 자신의 ChatGPT 플랜이나 사용 가능한 크레딧으로 AI 기능을 사용할 수 있다. Sign in with ChatGPT Quickstart

이 방식으로 모델 비용 주체를 바꿔도 업무 데이터 권한은 바뀌지 않는다.

OpenAI OAuth
  -> 모델 사용 가능 여부와 비용 주체 확인

서비스 로그인 세션
  -> 내부 사용자와 데이터 접근 범위 확인

로그인만 성공했다고 서비스 데이터 접근을 허용하거나, 반대로 서비스 로그인만으로 사용자의 ChatGPT 플랜을 호출하면 안 된다. 두 동의와 두 Token의 역할을 분리해야 한다.

공식 문서에는 상용 앱의 플랜 사용이 제한된 시험과 승인 대상으로 안내돼 있다. 오픈소스와 비공개 상용 앱의 조건도 다르다. 특정 공급자 기능을 전체 비용 전략의 유일한 전제로 두지 않고, 실제 서비스가 참여 가능한지 확인한 뒤 선택해야 한다.

BYOK

BYOK는 사용자가 모델 제공자의 개발자 콘솔에서 API Key를 발급해 서비스에 등록하는 방식이다. 사용량은 해당 Key의 계정에 청구된다.

파트너 기능 승인에 의존하지 않고 여러 공급자를 지원할 수 있지만, 사용자 경험과 보안 부담이 크다. 2026년 10월 공식 안내를 기준으로 Anthropic도 타사 제품 개발에는 구독 계정의 OAuth Token이 아니라 Console API Key나 지원되는 Cloud Provider를 사용하도록 안내한다. Anthropic 계정 인증 안내

API Key를 브라우저 저장소나 로그에 남겨서는 안 된다. 서버의 Secret 저장소에 암호화해 보관하고, 복호화와 사용 권한을 Agent 실행 계층으로 제한해야 한다. 목록 화면에는 Key 원문 대신 공급자, 별칭, 일부 Prefix와 등록 시각만 표시한다.

provider_api_credential
  id
  user_id
  provider
  name
  key_prefix
  encrypted_key
  created_at
  last_used_at
  revoked_at

사용자에게도 Key를 등록하면 서비스 운영자가 그 자격 증명으로 모델 API를 호출할 수 있다는 사실을 명확히 알려야 한다. BYOK는 비용 책임을 옮기지만 자격 증명 보관 책임을 없애지는 않는다.

기존 서비스가 발급하는 API Key와 저장 방식도 다르다. 자체 발급 Key는 들어온 값의 해시를 비교할 수 있지만, BYOK Key는 외부 API 호출에 원문이 필요하므로 해시만 저장할 수 없다. 암호화된 비밀값이나 Secret 저장소 참조를 보관하는 이유다. 서비스에서 연결을 삭제하는 것과 공급자에서 Key 자체를 폐기하는 것도 구분해야 한다.

사용량 기록에는 실행 횟수와 결과 크기도 포함한다

Agent 요청이 비싸거나 느린 이유를 찾으려면 최종 Token 수 외에 도구 실행 흐름도 함께 남겨야 한다.

기록 항목	확인할 수 있는 문제
사용자, 조직과 요청 ID	비용이 어느 사용 범위에서 발생했는지
모델과 공급자	모델 변경에 따른 비용과 품질 차이
입력, 출력 Token	직접적인 모델 사용량
모델 호출 횟수	도구 반복으로 추론 단계가 늘어났는지
도구 이름과 호출 횟수	어떤 기능이 반복 실행됐는지
도구 입력과 결과 크기	불필요한 데이터가 Context를 키웠는지
승인, 거부와 실패	변경 작업과 오류가 어디서 멈췄는지
전체 실행 시간	모델, 도구와 네트워크 중 병목 위치

민감한 도구 인자와 결과를 그대로 로그에 저장할 필요는 없다. 요청 ID, 도구 이름, 크기, 처리 시간과 결과 상태를 기본으로 기록하고, 업무 데이터는 마스킹하거나 별도의 감사 정책을 적용한다.

비용 제한은 월 한도와 요청별 실행 상한을 함께 두는 방향으로 정리했다.

요청 전
  -> 사용자와 조직의 남은 예산 확인
  -> 사용 가능한 모델과 호출 가능한 기능 목록 제한

실행 중
  -> 모델 호출 횟수와 도구 호출 횟수 확인
  -> 최대 실행 시간 초과 시 중단

요청 후
  -> Token과 도구 사용량 기록
  -> 일간과 월간 사용량 집계

모델 응답이 유효하지 않다고 무제한 재시도하면 같은 요청 하나가 예산을 계속 소비할 수 있다. 재시도 횟수와 최대 단계 수를 종료 조건에 포함하고, 상태 변화 없이 같은 조회를 반복하면 중단하는 기준도 필요하다.

사용량을 응답 후에만 합산하면 동시에 들어온 요청들이 같은 잔여 예산을 보고 모두 실행될 수 있다. 엄격한 한도가 필요하다면 요청 전에 예상 사용량을 원자적으로 예약하고, 종료 후 실제 사용량으로 정산하는 방식까지 설계해야 한다. 타임아웃은 공급자 측 실행 취소나 과금 취소를 보장하지 않으므로, 실패한 요청을 무조건 무료로 계산해서도 안 된다.

조회 기능부터 시작해야 하는 이유

Agent가 데이터를 조회하는 것과 상태를 변경하는 것은 위험이 다르다. 첫 단계에서는 조회 전용 도구만 제공하는 편이 안전하다.

도구 성격	예시	기본 정책
단순 조회	상태 요약, 목록 검색	사용자 권한 확인 후 실행
민감 조회	개인 정보, 상세 로그	제한된 필드만 반환하고 감사 기록
가역적 변경	임시 설정 변경	실행 전 사용자 승인
비가역적 변경	삭제, 외부 전송	별도 권한과 강한 승인, 초기에는 제외

모델이 도구를 선택했다고 해서 실행 권한까지 얻은 것은 아니다. 최종 허용 여부는 Agent 애플리케이션이나 MCP 서버가 현재 사용자의 권한과 도구 정책을 대조해 결정한다.

입력 검증은 Agent 계층과 기존 API에 각각 두는 방향으로 검토했다. Agent 계층에서는 허용하지 않은 필드, 과도한 기간과 큰 페이지 크기를 차단하고, 기존 API는 사용자 권한과 도메인 규칙을 최종 검사한다.

특히 사용자 ID를 모델이 채우는 도구 인자로 받지 않아야 한다. 대상 자원 ID는 모델이 제안할 수 있지만, 호출자의 신원은 서버의 로그인 세션이나 검증된 위임 정보에서 가져와야 한다. 모델이 다른 자원 ID를 제안해도 기존 API가 접근을 거부할 수 있어야 한다.

모델의 기능 호출 요청
  -> 허용된 도구인지 확인
  -> 입력 스키마와 크기 제한 확인
  -> 필요하면 사용자 승인
  -> 기존 API에서 인증, 권한과 도메인 규칙 재검사
  -> 최소화한 결과만 모델에 반환

이중 검사는 중복이라기보다 서로 다른 경계를 보호한다. Agent 계층은 모델이 할 수 있는 행동을 제한하고, 기존 API는 호출 주체와 데이터 규칙을 보호한다.

내가 정리한 도입 순서

구현 검증에 사용할 입력도 함께 정리했다. 답변이 자연스러운지만 확인하면 권한과 비용 문제가 가려질 수 있다.

검증 상황	확인할 동작
접근할 수 없는 자원 조회	사용자 권한으로 거부하고 결과를 모델에 전달하지 않음
같은 조회를 반복하는 응답	반복과 호출 상한에 따라 종료
모델 응답에 도구 요청이 여러 개 포함됨	요청 수와 별개로 개별 도구 실행 수를 계산
승인 요청을 사용자가 거부함	변경 API를 호출하지 않음
조회 결과가 상한을 넘음	집계나 페이지 제한을 적용하고 생략 범위를 알림
예산이 부족한 상태에서 동시 요청	예산 예약과 동시 실행 제한으로 초과 방지
공급자 Key가 폐기됨	연결 오류를 표시하고 다른 비용 계정으로 임의 전환하지 않음
응답 타임아웃 발생	실행 결과를 확인하기 전 변경 작업을 자동 재실행하지 않음

아직 특정 방식을 구현하기로 확정한 단계는 아니다. 조사 결과를 바탕으로 다음 순서가 변경 범위를 가장 작게 유지한다고 판단했다.

1. 기존 서비스 로그인 안에서 조회 전용 기능 한두 개로 사용성을 검증한다.
2. 도구 제공 채널이 내부 Agent 하나뿐이면 직접 Function Calling으로 시작한다.
3. 외부 Agent용 MCP 서버도 제공한다면 기능의 입력과 응답 규약을 MCP로 모아 재사용한다.
4. 서비스 API Key로 짧은 실험을 하되 사용자별 한도와 실행 단계 상한을 먼저 둔다.
5. 실제 사용자와 배포 형태에 맞춰 Sign in with ChatGPT 또는 BYOK 지원 여부를 결정한다.
6. 데이터 변경 기능은 조회 흐름과 감사 기록이 안정된 뒤 승인 절차와 함께 추가한다.

이 순서에서는 MCP나 OAuth를 사용한다는 이유만으로 먼저 도입하지 않는다. 도구를 제공할 대상과 비용을 부담할 주체가 확인됐을 때 필요한 구성요소만 추가한다.

정리

서비스 안에 AI Agent를 넣는 구조를 검토하면서 다음 기준을 세웠다.

• Agent 서버를 직접 운영하는 것과 모델을 자체 호스팅하는 것은 다른 선택이다.
• 모델 제공자의 사용자 식별과 서비스 데이터 권한을 분리한다.
• 도구 채널이 하나라면 직접 Function Calling이 단순하고, 여러 Agent가 같은 도구를 써야 한다면 MCP 재사용을 검토한다.
• 도구 결과가 다음 모델 입력에 포함되므로 응답 크기와 반복 호출도 비용이다.
• 서비스 API Key, 사용자 플랜, BYOK와 자체 모델 운영은 비용과 운영 책임이 서로 다르다.
• Token뿐 아니라 모델 호출 횟수, 도구 호출 횟수와 결과 크기를 함께 기록한다.
• 조회 전용 기능부터 시작하고, 데이터 변경 기능은 권한과 사용자 승인을 다시 확인한다.

Agent 기능의 핵심은 모델 하나를 연결하는 데 있지 않았다. 누가 모델을 호출하고, 누가 도구 실행을 허용하며, 누가 그 비용과 데이터 접근에 책임지는지 분리하는 것이 먼저였다.