책에 포함된 노트딥러닝의 감각 — 신경망에서 파운데이션 모델까지, AI를 끝까지 이해하는 가장 현실적인 지도

모델을 서비스에 연결하기

2026-05-01Views 8약 11분생성형 AI 활용

모델을 잘 고르는 것과, 모델이 들어간 서비스를 잘 만드는 것은 전혀 다른 일입니다. 데모에서는 둘이 비슷해 보입니다. 프롬프트를 넣고 답을 받으면 끝이니까요. 하지만 제품이 되는 순간 질문이 달라집니다. 이 응답은 얼마나 빨리 오나, 비용은 얼마나 드나, 트래픽이 몰리면 버티나, 민감한 데이터는 안전한가, 공급자가 바뀌어도 서비스는 계속 돌아가나 같은 질문이 앞에 옵니다.

즉 서비스에서 중요한 것은 모델 그 자체보다 모델을 둘러싼 시스템입니다. 사용자의 요청을 받아 적절한 모델로 보내고, 필요한 문맥을 붙이고, 실패하면 우회하고, 결과를 기록하고, 다음 개선으로 이어지게 만드는 전체 구조 말입니다. 좋은 AI 제품은 답변을 잘하는 모델만 갖고 있는 것이 아니라, 망가지지 않게 설계된 연결 구조를 갖고 있습니다.

모델을 서비스에 연결하기

모델을 붙인다는 것은 사실 시스템을 설계하는 일이다

사용자는 보통 "AI에게 질문했다"고 느끼지만, 실제 서비스 내부에서는 훨씬 많은 일이 일어납니다. 요청은 곧바로 모델로 가지 않습니다. 먼저 어떤 기능인지 분류하고, 프롬프트 템플릿을 고르고, 세션 상태를 읽고, 필요하면 검색이나 내부 데이터 조회를 수행한 뒤, 적절한 모델에 보내고, 응답 형식을 검증한 다음, 로그와 비용 정보를 남기고 나서야 화면에 보입니다.

이 흐름을 한 문장으로 줄이면 이렇습니다. AI 기능은 모델 호출이 아니라 오케스트레이션, 즉 조율의 문제입니다. 같은 모델을 써도 이 앞뒤 설계가 다르면 품질, 속도, 비용이 완전히 달라집니다.

그래서 실무에서는 모델 레이어 위에 하나의 공통 인터페이스를 두는 경우가 많습니다. 애플리케이션은 "요약을 해 달라", "문서를 분석해 달라", "답변을 JSON 형식으로 달라"처럼 내부 계약만 알고, 실제 어떤 공급자의 어떤 모델을 쓸지는 라우터나 게이트웨이가 결정하는 식입니다. 이렇게 해야 모델을 바꾸거나 공급자를 추가할 때 서비스 전체를 뜯어고치지 않아도 됩니다.¹

또한 API를 AI 서비스에 연결할 때는 인증, 권한, 버전 관리, 속도 제한, 암호화 같은 전통적 API 문제를 더 엄격하게 다뤄야 합니다. 생성형 AI는 입력에 사용자 데이터와 기업 문서가 섞여 들어가기 쉬우므로, 평범한 웹 API보다 보안과 거버넌스 부담이 더 큽니다.²

외부 API, 통합 게이트웨이, 자체 호스팅은 무엇이 다른가

AI 제품을 만들 때 가장 먼저 부딪히는 선택은 "모델을 어디서, 어떤 방식으로 쓸 것인가"입니다. 이 선택은 단순히 정확도 비교표로 끝나지 않습니다. 제품의 성격, 예산, 보안 요구, 팀 역량까지 함께 들어갑니다.

외부 모델 API는 시작이 가장 빠릅니다. 최신 모델을 곧바로 붙일 수 있고, 인프라 운영 부담도 적습니다. 대신 공급자의 가격 정책, 속도 제한, 지역 장애, 데이터 정책에 크게 영향을 받습니다.
통합 게이트웨이는 여러 공급자를 같은 인터페이스로 묶어 줍니다. 이 방식은 모델 교체와 다중 공급자 운영을 쉽게 만들고, 키 관리나 사용량 통제도 중앙에서 처리하기 좋습니다. 반면 중간 계층이 하나 더 생기므로 추상화 비용과 운영 복잡도가 늘 수 있습니다.¹⁶
자체 호스팅은 데이터 통제권과 커스터마이징 자유도가 가장 큽니다. 보안·컴플라이언스 요구가 강하거나, 장기적으로 대규모 트래픽을 소화해야 할 때 유리할 수 있습니다. 하지만 인프라 운영, 모델 배포, 업데이트, 장애 대응을 모두 직접 감당해야 합니다.

여기서 중요한 기준은 "가장 똑똑한 모델이 무엇인가"가 아닙니다. 실제로는 다음 질문이 더 중요합니다. 첫 응답이 얼마나 빨리 시작되는가, 호출당 비용이 얼마인가, 트래픽 급증을 흡수할 수 있는가, 민감한 데이터를 외부로 보내도 되는가, 모델을 다른 공급자로 갈아탈 때 비용이 얼마나 드는가.

많은 팀이 처음에는 최고 성능 모델 하나에 기대지만, 운영 단계로 가면 생각이 바뀝니다. 이유는 단순합니다. 최고 성능 모델은 종종 가장 느리고, 가장 비싸고, 가장 장애 영향도 큽니다. 그래서 실전에서는 한 모델을 숭배하기보다, 같은 인터페이스 뒤에 여러 모델을 연결하고 상황별로 라우팅하는 구조가 더 강합니다. 간단한 분류는 작은 모델로, 긴 문서 분석은 큰 모델로, 장애 시에는 백업 모델로 보내는 식입니다. 더 작은 모델이 대체로 더 빠르고 저렴하다는 점은 주요 API 제공자 문서에서도 반복해서 강조됩니다.³

API 호출 방식이 곧 사용자 경험을 만든다

"모델을 API로 호출한다"는 말은 너무 단순합니다. 실제로는 여러 패턴이 있고, 어떤 패턴을 택하느냐가 서비스의 느낌을 바꿉니다.

가장 기본은 일반적인 요청-응답 방식입니다. 짧고 확정적인 작업, 예를 들어 분류, 태깅, 간단한 추출처럼 한 번에 결과가 나오는 기능에는 이 방식이 가장 단순합니다. 실패 처리도 명확하고, 모니터링도 쉽습니다.

하지만 긴 생성형 응답에서는 이야기가 달라집니다. 사용자가 8초를 기다린 뒤 한 번에 긴 답을 받는 것과, 1초쯤 뒤부터 문장이 조금씩 흘러나오는 것은 체감이 완전히 다릅니다. 스트리밍은 총 소요 시간을 마법처럼 없애 주지는 않지만, 보이는 대기 시간을 크게 줄여 줍니다. 그래서 채팅형 인터페이스에서는 거의 표준에 가까운 선택이 되었습니다.⁴

다만 스트리밍은 구현이 더 어렵습니다. 응답이 중간에 끊길 수 있고, 부분 출력 상태를 UI와 서버가 함께 다뤄야 하며, 일반 요청처럼 단순 재시도를 걸기 어렵습니다. 특히 일부 스트리밍 방식은 서버 전송 이벤트, 즉 SSE 기반으로 동작하며, 이때는 연결이 끊겼을 때 어떤 범위까지 복구할지 따로 설계해야 합니다.⁵

또 하나는 함수 호출, 또는 툴 사용 패턴입니다. 여기서 모델은 직접 외부 시스템을 건드리는 것이 아니라, "이 도구를 이런 인자로 호출하라"는 구조화된 요청을 만듭니다. 실제 실행은 여러분의 백엔드가 담당합니다. 이 방식은 에이전트형 서비스에서 특히 중요합니다. 모델이 검색, 일정 조회, CRM 업데이트, 사내 데이터 조회 같은 행동을 선택할 수 있게 해 주기 때문입니다. 하지만 바로 그 이유로 권한 관리와 감사 로그가 핵심이 됩니다. 모델에게 열쇠를 쥐여 주는 것이 아니라, 모델은 제안하고 시스템은 허가한다는 구조가 안전합니다.⁶

정리하면, 짧은 요청은 일반 API 호출이 단순하고, 긴 생성 응답은 스트리밍이 사용자 경험을 개선하며, 도구를 쓰는 서비스는 함수 호출과 권한 설계가 본체가 됩니다. 연결 방식은 사소한 구현 차이가 아니라, 제품의 성격을 결정하는 선택입니다.

프롬프트 템플릿은 코드보다 덜 엄격하면 안 된다

생성형 AI 서비스에서는 프롬프트가 종종 임시 메모처럼 취급됩니다. 하지만 운영 단계에서는 절대 그렇게 다루면 안 됩니다. 프롬프트 템플릿은 모델의 행동을 규정하는 실질적인 제품 로직이기 때문입니다.

예를 들어 같은 질문이라도 시스템 지시문이 다르고, 출력 형식 요구가 다르고, 참고 문서의 위치가 다르면 결과는 크게 달라집니다. 따라서 프롬프트 템플릿은 버전 관리되어야 하고, 어떤 기능이 어떤 템플릿 버전을 쓰는지 추적 가능해야 합니다. 그래야 응답 품질이 갑자기 변했을 때 원인을 찾을 수 있습니다.

여기서 많은 팀이 놓치는 부분이 세션 상태와 대화 이력입니다. 채팅형 제품에서는 "이전 대화를 얼마나, 어떤 방식으로 넣을 것인가"가 품질과 비용을 동시에 좌우합니다. 모든 이력을 계속 붙이면 문맥은 풍부해지지만 토큰 비용이 커지고, 중요하지 않은 말들까지 모델을 혼란스럽게 만들 수 있습니다. 반대로 너무 많이 잘라 내면 사용자는 모델이 방금 전 대화도 잊었다고 느낍니다.

그래서 실무에서는 최근 대화 일부만 유지하거나, 오래된 대화를 요약해 압축하거나, 사용자 프로필·업무 상태·검색 결과를 분리된 문맥 블록으로 관리하는 식의 전략을 씁니다. 핵심은 "많이 넣는 것"이 아니라 필요한 것을 질서 있게 넣는 것입니다.

같은 맥락에서 캐싱은 단순한 최적화 팁이 아닙니다. 반복되는 질문이 많다면 정확히 같은 요청에 대한 응답을 저장해 두는 기본 캐시만으로도 비용과 지연 시간을 크게 줄일 수 있습니다. 더 나아가 의미가 비슷한 요청을 같은 범주로 묶어 재사용하는 의미 기반 캐시는 비용 절감 효과가 큽니다.⁷ 일부 제공자는 긴 공통 문맥 자체를 캐시해 다음 요청에서 재사용하는 기능도 제공합니다. 제품 설명서, 정책 문서, 긴 시스템 지침처럼 반복적으로 붙는 문맥에서는 이런 캐시가 특히 유용합니다.⁸

여기서 중요한 감각은 이것입니다. 좋은 응답은 좋은 모델만으로 나오지 않는다. 좋은 컨텍스트 조립에서 나온다. 모델 호출 전후의 오케스트레이션이 바로 품질의 절반입니다.

캐싱과 라우팅은 비용 절감이 아니라 제품 설계다

AI 기능은 잘 만들수록 호출량이 늘어납니다. 사용자가 만족하면 더 자주 쓰기 때문입니다. 그래서 제품이 성공할수록 비용 문제가 뒤늦게 폭발하는 일이 흔합니다. 이를 막으려면 처음부터 "모든 요청을 가장 큰 모델에 보낸다"는 설계를 피해야 합니다.

실무에서는 보통 요청을 나눠 봅니다. 짧은 요약, 제목 생성, 분류, 감정 분석처럼 비교적 단순하고 반복이 많은 작업은 작은 모델이나 규칙 기반 처리로도 충분한 경우가 많습니다. 반대로 긴 추론, 복잡한 도메인 답변, 고난도 생성은 더 큰 모델이 필요할 수 있습니다. 이 구분이 잘되면, 사용자는 대부분 비슷한 경험을 얻으면서도 비용 구조는 훨씬 건강해집니다.

캐싱도 같은 맥락입니다. 자주 반복되는 FAQ 응답, 정형 프롬프트, 동일 문서에 대한 반복 요약은 매번 새로 생성할 이유가 없습니다. 이때 캐시는 단순한 속도 향상 장치가 아니라, 서비스가 같은 돈으로 더 많은 사용자를 받게 만드는 제품 레버가 됩니다.⁷⁹

또 한 가지 실전 팁이 있습니다. 모델 라우팅과 캐싱은 따로 움직이지 않습니다. 예를 들어 간단한 요청은 작은 모델로 보내고, 실패하면 큰 모델로 올리며, 이미 비슷한 결과가 있으면 캐시에서 먼저 꺼내는 식으로 함께 설계해야 합니다. 결국 중요한 것은 모델 하나의 평균 점수가 아니라, 전체 요청 집합을 어떤 비용 구조로 처리하느냐입니다.

실패는 예외가 아니라 기본 상황이다

AI 서비스를 처음 운영해 보면 의외로 빨리 깨닫게 됩니다. 장애는 특별한 사건이 아니라, 언젠가 반드시 오는 일상이라는 점입니다. 특히 외부 모델 API에 의존한다면 더 그렇습니다. 속도 제한이 걸리고, 일시적 5xx 오류가 나고, 응답이 비정상적으로 느려지고, 출력 형식이 갑자기 어긋나고, 모델 버전이 바뀌며 동작이 미묘하게 달라집니다.⁹

이때 가장 위험한 태도는 "실패하면 다시 한 번 호출해 보자" 하나로 모든 문제를 처리하려는 것입니다. 재시도는 필요하지만, 모든 실패에 같은 방식으로 적용하면 오히려 상황을 악화시킵니다. 권한 오류나 잘못된 요청은 재시도해도 낫지 않고, 429나 503처럼 일시적 문제는 지수 백오프와 지터를 써서 조심스럽게 다시 시도해야 합니다.⁹¹⁰

운영 관점에서 보면 실패 대응은 계층형으로 설계하는 편이 좋습니다. 먼저 짧은 재시도를 하고, 그래도 안 되면 같은 공급자의 다른 모델이나 두 번째 공급자로 우회하고, 그것도 어렵다면 기능 축소 모드로 내려가는 식입니다.¹⁰ 예를 들어 긴 분석 답변을 못 만들 때는 핵심 문장 추출만 제공하거나, 실시간 생성 대신 "결과를 준비 중이며 잠시 후 알려 주겠다"는 비동기 처리로 돌릴 수 있습니다.

여기서 폴백 모델은 단순한 보험이 아닙니다. 사용자 신뢰를 지키는 장치입니다. 다만 폴백이 있다고 해서 아무 모델이나 붙이면 안 됩니다. 출력 형식이 같은지, 프롬프트가 호환되는지, 안전 필터 동작이 지나치게 다르지 않은지 확인해야 합니다. 같은 질문에 백업 모델이 전혀 다른 JSON 구조를 내놓는다면, 장애는 막아도 서비스는 깨집니다.

그래서 좋은 설계는 보통 이런 원칙을 따릅니다.

모델 공급자별 SDK를 서비스 곳곳에 흩뿌리지 않는다.
내부적으로는 공통 요청·응답 계약을 둔다.
출력 스키마 검증과 후처리를 중앙에서 한다.
정상 경로보다 장애 경로를 먼저 테스트한다.

특히 긴 작업은 비동기화가 중요합니다. 요약, 보고서 생성, 이미지 생성처럼 몇 초 이상 걸릴 수 있는 작업을 모든 사용자가 동기적으로 기다리게 하면 서비스는 금방 답답해집니다. 이런 경우에는 작업 큐에 넣고, 진행 상태를 보여 주거나 완료 알림을 보내는 방식이 훨씬 안정적입니다. AI 서비스는 계산이 길어질수록 "응답"보다 "흐름 관리"가 중요해집니다.

인증, 버전 호환성, 데이터 통제는 뒤로 미루면 안 된다

AI 기능은 눈에 보이는 답변이 화려해서, 그 뒤의 눈에 덜 띄는 문제를 자꾸 뒤로 미루게 만듭니다. 하지만 실제 장애의 많은 부분은 아주 평범한 곳에서 납니다. 만료된 토큰, 잘못된 권한 범위, 응답 스키마 변경, 공급자의 API 버전 업데이트, 프런트엔드에 노출된 키 같은 문제들입니다.²⁹

가장 기본 원칙은 하나입니다. 모델 API 키는 반드시 백엔드 뒤에 숨겨야 한다는 것입니다. 브라우저나 모바일 앱에서 직접 외부 모델 API를 호출하면 편해 보이지만, 키 유출과 비용 폭탄의 지름길입니다.⁹

또한 공급자 응답 형식을 그대로 서비스 내부 계약으로 삼지 않는 편이 좋습니다. 오늘은 choices[0].message.content였던 값이 내일 다른 필드로 바뀌거나, 함수 호출 구조가 조정될 수도 있기 때문입니다. 내부적으로는 여러분의 서비스가 이해하는 표준 응답 형식을 만들고, 공급자별 어댑터가 그 안으로 변환하게 하는 편이 훨씬 안전합니다. 이 구조가 있어야 모델 교체 난이도가 내려갑니다.

민감한 데이터 처리도 마찬가지입니다. 고객 상담 기록, 사내 문서, 의료 정보, 재무 정보처럼 민감한 입력은 어디까지 외부에 보내도 되는지, 저장은 되는지, 어떤 리전에 남는지부터 확인해야 합니다. 성능 차이가 3% 나는 것보다, 데이터 통제권을 잃는 것이 훨씬 큰 사고가 될 수 있습니다.

로그와 추적은 사후 점검이 아니라 학습 데이터다

AI 제품은 종종 "모델이 똑똑해지면 저절로 좋아질 것"처럼 보이지만, 실제 개선은 관측 가능한 운영 데이터에서 나옵니다. 어떤 프롬프트가 실패했는지, 어떤 문맥 조합에서 환각이 늘었는지, 어느 공급자에서 첫 토큰이 늦었는지, 어느 기능이 캐시 덕분에 가장 큰 비용 절감을 만들었는지를 알아야 다음 선택이 가능해집니다.¹¹

여기서 로그는 단순한 텍스트 기록이 아닙니다. 최소한 다음 정도는 남길 수 있어야 합니다.

요청 유형과 기능 이름
사용한 프롬프트 템플릿 버전
세션 요약 또는 문맥 구성 방식
선택된 모델과 공급자
첫 토큰 시간과 전체 응답 시간
입력·출력 토큰 수와 예상 비용
캐시 적중 여부
재시도, 폴백, 기능 축소 여부
출력 스키마 검증 성공 여부
사용자 피드백

특히 추적, 즉 트레이싱이 중요합니다. RAG나 도구 호출이 섞인 시스템에서는 "느리다"는 한마디가 너무 거칠기 때문입니다. 검색이 300밀리초 걸렸는지, 재랭킹이 느렸는지, 모델이 늦었는지, 후처리 파서가 실패했는지 구간별로 보여야 병목을 잡을 수 있습니다.¹¹

다만 아무 로그나 다 남기면 안 됩니다. 프롬프트와 응답에는 민감한 정보가 섞일 수 있으므로, 원문 저장 범위와 마스킹 규칙을 설계해야 합니다. 좋은 관측성은 많이 저장하는 것이 아니라, 필요한 정보를 안전하게 저장하는 것입니다.

그리고 AI 운영 지표는 전통적인 API 오류율보다 더 넓어야 합니다. 성공률만 보면 멀쩡해 보여도, 사용자가 답을 싫어하면 실패입니다. 그래서 응답 품질, 사용자 만족, 토큰 사용량, 폴백 발동률, 캐시 적중률, 모델별 실패 패턴까지 함께 봐야 합니다. AI 서비스의 관측성은 기술 지표와 제품 지표가 붙어 있어야 제대로 작동합니다.

좋은 AI 제품은 모델보다 시스템이 더 잘 짜여 있다

이 장의 핵심은 단순합니다. 모델은 엔진이고, 서비스는 자동차 전체라는 점입니다. 엔진이 좋아도 브레이크가 없고 계기판이 고장 나 있고 연료 공급이 불안정하면 좋은 차가 될 수 없습니다.

AI 서비스도 같습니다. 외부 API를 쓸지, 게이트웨이를 둘지, 자체 호스팅할지 결정해야 하고, 스트리밍으로 체감 속도를 개선할지, 함수 호출로 내부 시스템을 연결할지, 캐시로 비용을 줄일지, 폴백으로 장애를 흡수할지, 로그와 피드백으로 개선 루프를 만들지 정해야 합니다. 이 선택들이 모여 비로소 "쓸 만한 제품"이 됩니다.

결국 실전에서 중요한 것은 모델 하나가 아닙니다. 모델을 둘러싼 서비스 전체 구조입니다. 같은 모델을 붙여도 어떤 팀은 멋진 데모에서 멈추고, 어떤 팀은 신뢰할 수 있는 제품을 만듭니다. 그 차이는 대개 모델 크기가 아니라, 시스템을 얼마나 성실하게 설계했는가에서 벌어집니다.

다음 장에서는 여기서 한 걸음 더 나아가, 모델이 단순히 답하는 존재를 넘어 도구를 사용하고 행동을 선택하는 에이전트로 확장될 때 어떤 구조 변화가 필요한지 살펴보겠습니다.