요약
생성형 AI로 기능을 만들기 위해 모델을 호출하는 것은 어렵지 않습니다. 하지만 실제 서비스에 적용하려면 사용할 모델과 데이터의 처리 범위를 정하고, 예상 비용과 필요한 처리 용량도 검토해야 합니다.
서비스 팀마다 이 과정을 따로 준비하면 비슷한 작업을 반복하게 됩니다. 모델 공급자별 연동 코드를 작성하고, 권한을 확인하고, 사용량을 집계해야 하죠. 운영을 시작한 뒤에는 호출이 왜 실패했는지, 요청이 몰릴 때 어떻게 처리할지도 고민해야 합니다.
토스 AI Platform 팀은 이 중 여러 서비스에 공통으로 필요한 일을 플랫폼이 맡도록 했습니다. 서비스 팀이 사용 목적과 필요한 모델을 정하면, 검토한 조건을 실제 호출에 적용하고 그 결과를 운영 중에도 확인할 수 있게 만드는 데 초점을 맞췄습니다.
GenAI Portal은 모델 사용 신청과 설정을 관리하는 웹 서비스입니다. 실제 호출은 서비스와 모델 사이에서 요청을 처리하는 LLM Gateway 서버인 GenAI Gateway가 맡습니다.
Portal에서 정한 사용 조건을 Gateway가 실제 요청에 적용하도록 연결했습니다. 사내 도구를 호출할 때는 MCP Gateway가 실행 권한을 확인합니다.
검토한 사용 조건을 실제 호출까지 연결하기
서비스에 맞는 모델을 찾았더라도 바로 사용할 수 있는 것은 아닙니다. 성능이 충분하더라도 처리할 데이터와 실행 환경에 맞는지 확인해야 하고, 예상 요청량을 감당할 용량도 필요합니다.
Portal에서는 위 화면처럼 필요한 비교 항목을 골라 모델별 가격과 사양을 살펴볼 수 있습니다.
가격과 성능을 함께 비교할 때는 리더보드를 사용합니다. 가로축과 세로축에 비교할 지표를 선택해 모델별 차이를 볼 수 있습니다. 공개 벤치마크 점수와 사내 서빙 환경에서 측정한 응답 지연 시간은 구분해 제공합니다.
사용할 모델을 정하면 프로젝트에서 사용을 신청합니다. 권한과 비용을 관리하는 단위도 바로 이 프로젝트입니다.
위 화면처럼 처리할 데이터의 등급과 서비스 중단 시 영향을 입력하도록 안내합니다. 담당자와 실행 환경, 사용할 모델, 예산과 사용량 제한을 프로젝트에 등록한 뒤 API 키를 발급받습니다.
키가 여러 개여도 같은 프로젝트라면 모델 권한과 예산을 함께 관리하고 사용량도 합쳐서 볼 수 있습니다. 서비스의 운영 조건이 개별 키마다 흩어지지 않도록 통일하고 있습니다.
금융 서비스에 필요한 검토도 이 프로젝트를 기준으로 진행합니다. 담당자가 사용 목적과 데이터 처리 범위를 정하면 담당 조직이 검토하고, 혁신금융서비스의 허용 범위에 맞는지 확인합니다. 모델을 추가하거나 사용량 한도를 바꿀 때도 변경 내용을 신청하고 필요한 승인을 받습니다.
위 화면처럼 추가할 모델과 변경 전후의 사용량 한도, 예산을 보여주고 신청 사유와 함께 검토할 수 있도록 했습니다. 승인 결과는 프로젝트 설정에 반영하고, 모델과 공급자 정보, 변경 이력도 Portal에서 확인할 수 있습니다.
신청자가 가이드를 미리 읽지 않아도 필요한 내용을 알 수 있도록, 각 단계의 안내도 실제 사용 과정에서 겪는 불편을 바탕으로 다듬고 있습니다.
데이터 등급은 실제로 다루는 정보 중 가장 민감한 항목을 기준으로 정합니다. 토스 내부 기준에서는 다음과 같이 구분합니다.
- L1: 주민등록번호와 계좌번호 등 최고 민감 정보
- L2: 일반 개인정보와 개인신용정보, 행태로그
- L3: 영업비밀과 가명화한 개인정보
- L4: 익명화 정보와 집계정보
등급이 같더라도 데이터를 쓰는 목적과 환경은 다를 수 있습니다. 그래서 등급만으로 사용을 허가하지 않고, 사용할 모델과 실행 환경을 함께 검토합니다.
서비스는 모델을 지정하고, Gateway는 호출을 처리합니다
검토한 조건은 요청을 받을 때도 확인해야 합니다. GenAI Gateway는 API 키로 요청 프로젝트임을 인증하고, 활성 상태와 모델 사용 권한을 확인합니다. 사용량 한도와 입력 가드레일을 통과한 요청만 모델로 전달합니다.
여기서 서비스가 지정하는 모델과 실제 요청을 처리하는 배포를 구분했습니다. 같은 모델이라도 공급자와 배포 환경에 따라 호출 조건이 다르기 때문입니다. Gateway는 해당 혁신금융서비스 정책에 따른 공급자 설정과 배포 상태를 반영해 호출할 곳을 선택합니다.
공급자별 인증과 요청 형식 변환은 어댑터가 맡고, 권한 확인과 사용량 제한은 공통 로직으로 분리했습니다. 공급자가 늘어날 때마다 서비스에서 이런 제어를 다시 구현하지 않아도 되도록 만든 것입니다.
사내 GPU에서 운영하는 모델도 같은 Gateway를 통해 호출합니다. 이 경우 모델 서빙은 자체 플랫폼인 Toss Dynamo가 담당합니다. 다만 호출 형식을 맞춰도 모델의 기능까지 같아지지는 않습니다. 도구 호출이나 구조화된 출력 지원 여부는 서비스에서 모델을 선택할 때 따로 살펴봐야 합니다.
모델을 호출할 권한과 사내 도구를 실행할 권한은 별개입니다. 그림처럼 모델 호출은 GenAI Gateway를, 도구 호출은 MCP Gateway를 거치도록 나눴습니다.
하나의 MCP(Model Context Protocol) 서버에는 여러 도구를 등록할 수 있습니다. 등록할 때는 기술적 보안 요건과 개인정보 처리 등급, 데이터 처리 방식을 검토합니다.
등록을 마친 도구도 프로젝트에서 사용을 신청해야 목적에 맞는 권한을 부여받을 수 있습니다. MCP Gateway는 호출마다 프로젝트와 서버, RPC 메서드, 도구 이름을 확인해 실행을 허용할지 판단합니다.
도구 실행 권한과 데이터 접근 권한은 여기서도 구분해야 합니다. 검색 도구를 실행할 수 있다고 해서 모든 문서를 읽을 수 있는 것은 아니니까요. 도구 실행 여부는 MCP Gateway가 판단하지만, 데이터 접근 권한은 연결된 서비스에서 별도로 확인해야 합니다.
터미널이나 코딩 에이전트에서 개발할 때는 GenAI CLI로 모델 목록과 등록된 MCP 도구를 조회할 수 있습니다. 웹 화면을 열지 않고도 개발 중에 필요한 정보를 찾아볼 수 있도록 했습니다.
본문을 보호하면서도 문제를 추적할 수 있어야 합니다
사용 범위를 검토해 두어도 실제 요청에는 예상하지 못한 정보가 섞일 수 있습니다. 사용자가 자유롭게 입력한 글이나 외부 문서를 다룬다면 특히 그렇습니다. 이때 승인된 처리 범위를 지키기 위해 외부 모델 호출 전에 가드레일로 입력을 검사합니다.
하지만 요청을 차단해도 본문이 일반 로그에 그대로 남으면 보호할 정보가 다른 경로로 노출될 수 있습니다. 반대로 기록을 모두 없애면 운영 중 문제가 생겼을 때 원인을 찾기 어렵습니다.
그림에서 모델로 전달하는 경로와 로그를 남기는 경로를 나눈 이유입니다. 모델 호출 전에는 프롬프트 공격과 개인정보를 검사합니다. 개인정보는 규칙과 문맥을 판단하는 모델로 찾고, 탐지 결과가 프로젝트의 차단 조건에 해당하면 호출을 중단합니다. 응답 검사를 지원하는 API에서는 차단 대상인 응답도 반환하지 않습니다.
로그를 남길 때는 본문과 운영 정보를 구분합니다. 일반 운영 로그를 전송하기 전에 규칙이나 모델이 탐지한 개인정보 영역을 마스킹합니다. 프로젝트 설정에 따라 본문을 기록하지 않을 수도 있습니다.
본문을 가리더라도 호출 상태와 지연 시간, 사용량, 실패한 단계는 따로 확인할 수 있게 했습니다. 무엇을 탐지했는지와 실제로 차단했는지도 구분해 남깁니다. 같은 유형을 탐지해도 프로젝트 설정에 따라 처리 결과가 달라질 수 있기 때문입니다.
보안 검토용 기록은 일반 운영 로그와 목적과 처리 경로를 구분해 관리합니다.
여기까지는 개별 모델 호출의 기록입니다. 문서를 검색한 뒤 모델을 여러 번 호출하는 서비스라면, 어느 단계에서 시간이 오래 걸렸는지 파악하려면 서비스 전체 흐름이 필요합니다.
서비스 전체 흐름은 Langfuse 트레이스로 확인하고, Gateway 로그에도 서비스가 전달한 같은 추적 식별자를 남깁니다. 전체 처리 과정을 보다가 특정 모델 호출이 궁금하면 같은 식별자로 상세 기록을 찾을 수 있습니다.
연동을 시작하는 과정도 사내 배포 환경에 맞췄습니다. Portal에서 배포 파이프라인을 선택하면 Langfuse 프로젝트를 만들고 발급된 키를 파이프라인의 시크릿에 등록합니다. 키를 복사해 옮기는 작업을 줄이기 위한 연동입니다.
서비스 내부의 각 단계는 서비스에서 직접 계측해야 합니다. Langfuse에 남길 데이터 범위와 접근 권한도 별도로 관리합니다.
예산이 남아 있어도 요청을 처리하지 못할 수 있습니다
호출을 허용할지 결정할 때는 비용뿐 아니라 처리 용량도 봐야 합니다. 월 예산이 넉넉해도 짧은 시간에 요청이 몰리면 모델이 감당하지 못할 수 있습니다. 반대로 요청이 원활하게 처리되더라도 호출이 계속 늘면 예상보다 많은 비용이 나올 수 있고요.
그래서 예산은 누적 비용으로 관리하고, 요청을 받을 때는 분당 토큰 수(TPM) 등의 한도를 따로 적용합니다.
위 화면에서는 호출 기록을 불러와 월 예상 비용을 계산합니다. 기록에서 구한 평균 입력 토큰 수와 출력 토큰 수에 모델 단가와 예상 요청량을 적용합니다. 토큰 수를 임의로 정하기보다 실제 사용을 참고해 예산을 잡을 수 있도록 했습니다.
운영 중에는 누적 비용이 예산의 일정 비율에 도달하면 담당자에게 알립니다. 예산을 넘겼을 때도 알림과 유예 기간, 프로젝트 비활성화 조건을 나눠 관리합니다.
처리 용량은 서비스의 운영 조건에 맞춰 준비합니다. 잠시 늦어져도 괜찮은 실험과 중단되면 사용자에게 바로 영향을 주는 기능에 같은 기준을 적용하기는 어렵습니다. 이를 구분하는 것이 사내 SLA(Service Level Agreement) 등급입니다.
- High: 전용 파이프라인에서 가용성과 응답 시간, 처리량 보장이 필요한 서비스
- Standard: 공유 모델에서 필요한 최소 처리량을 확보하는 서비스
- Flex: 처리량을 보장하지 않는 실험이나 지연을 허용할 수 있는 작업
앞서 본 데이터 등급이 정보의 민감도를 구분한다면, SLA 등급은 필요한 운영 수준을 정합니다. High와 Standard는 플랫폼팀의 용량 검토를 거치고, 등급이나 요청량이 달라지면 다시 검토합니다. 모델 전체 한도를 적용한 경우에는 요청이 몰릴 때 우선순위가 낮은 요청부터 제한합니다.
아직 끝나지 않은 요청도 사용량에 포함하기
한도를 정한 뒤에는 현재 얼마나 사용 중인지 계산해야 합니다. 여기에는 LLM 호출의 특성이 영향을 줍니다. 최종 토큰 수를 응답이 끝나야 알 수 있어, 완료된 요청만 집계하면 처리 중인 요청이 계산에서 빠집니다. 실제로는 여유가 없는데 새 요청을 계속 받게 될 수 있죠.
토큰 단위로 요청량을 제한할 때는 입력과 예상 출력에 필요한 토큰 수를 먼저 예약하고, 응답이 끝나면 실제 사용량으로 보정합니다. 최종 사용량을 받지 못한 스트리밍 응답은 추정치를 사용하고, 캐시에서 반환해 모델을 호출하지 않았다면 예약분을 뺍니다.
이 계산은 요청 한도를 관리하기 위한 것으로 비용 청구와는 별개입니다.
응답이 늦게 끝나더라도 처음 예약한 시점의 값을 고쳐야 합니다. 완료 시점의 사용량에서 빼면 엉뚱한 시간대의 한도가 늘어날 수 있기 때문입니다. 스트리밍과 호출 실패, 재시도에서도 이 계산이 맞도록 관리하는 일은 Gateway에서 담당하고 있습니다.
확보한 처리 용량과 종량제 경로를 함께 사용하기
요청량을 제어하는 것과 함께, 사용할 수 있는 처리 용량을 활용하는 것도 중요합니다. 외부 모델에 미리 확보한 약정 용량이 있다면 이를 우선 쓰고, 부족할 때는 사용한 토큰만큼 비용을 내는 종량제(PAYG) 경로를 이용할 수 있습니다.
그림의 PTU(Provisioned Throughput Unit)는 미리 확보하는 처리 용량의 단위입니다. PTU 우선 라우팅이 설정된 모델은 확보한 용량부터 사용하다가 요청을 처리하기 어려워지면 같은 모델의 PAYG 경로로 전환합니다.
여기서 중요한 것은 전환한 뒤의 동작입니다. 일시적인 용량 제한이 풀렸는데도 PTU를 계속 제외하면 확보한 용량을 쓰지 못한 채 PAYG 비용이 발생합니다. 그렇다고 장애가 난 배포에 계속 요청을 보내면 실패와 지연이 늘어납니다.
Gateway는 오류 유형에 따라 해당 배포로의 요청을 잠시 중단하거나 재시도 간격을 늘립니다. 다른 경로를 사용하는 동안에도 기존 배포가 복구됐는지 확인하고, 다시 사용할 수 있으면 확보한 용량을 활용합니다.
이때 바뀌는 것은 같은 모델의 호출 경로입니다. 모델 자체를 바꾸면 응답 품질도 달라질 수 있으므로, 별도로 평가한 뒤 서비스 담당자가 전환 여부를 판단해야 합니다.
서비스 팀이 풀어야 할 문제에 집중할 수 있도록
서비스 팀이 정한 사용 목적을 바탕으로 거버넌스와 보안 담당자는 사용 조건을 검토하고, 모델과 서빙 담당 팀은 필요한 처리 용량을 살펴봅니다. AI Platform 팀은 이렇게 여러 조직이 검토한 내용이 프로젝트 설정과 실제 요청 처리에 반영되도록 연결합니다.
서비스에 어떤 모델이 맞는지, 결과가 사용자에게 충분히 좋은지는 여전히 서비스 팀과 함께 풀어야 할 문제입니다. 그 판단에 시간을 쓸 수 있도록, 권한 확인과 공급자 연동, 사용량 관리 같은 공통 운영 기능은 플랫폼에서 계속 해서 다듬고 있습니다.
그리고 플랫폼을 운영하면서 모델의 응답 품질과 비용을 어떻게 함께 개선할지도 함께 고민하고 있는데요. 토스 서비스에 맞는 평가 기준을 세우고, 그 결과를 모델 선택과 운영 최적화에 활용하는 과정도 이어서 소개해 보겠습니다.