14장. 외부 API와 내부 시스템 연결하기

LLM이 진짜 일을 시작하는 순간

LLM은 말을 잘합니다. 설명도 잘하고, 요약도 잘하고, 문장도 그럴듯하게 만듭니다. 하지만 서비스 관점에서 더 중요한 질문은 따로 있습니다. 그래서 무엇을 실제로 바꿨는가 하는 질문입니다.

사용자에게 고객사를 요약해 주는 답변만 보여주는 것과, CRM에서 최근 미팅 기록을 읽어 와서 다음 액션을 추천하고, 확인을 받은 뒤 실제 후속 작업을 생성하는 것은 완전히 다른 수준의 기능입니다. 전자는 똑똑한 대화이고, 후자는 업무가 움직이는 서비스입니다.

LLM이 가치 있어지는 순간은 보통 여기서 시작됩니다. 검색 API에서 최신 정보를 가져오고, 사내 데이터베이스에서 필요한 수치를 확인하고, CRM에서 고객 맥락을 읽고, 워크플로 시스템에 다음 단계를 등록할 때입니다. 다시 말해, 언어 모델이 혼자 생각만 할 때가 아니라 시스템과 연결되어 조직의 실제 흐름에 들어갈 때 비로소 서비스가 됩니다.

이번 장에서는 바로 그 연결의 패턴을 다룹니다. 핵심 메시지는 단순합니다. LLM은 중심이 아니라 조정자여야 하고, 실제 시스템 변경은 언제나 여러분의 애플리케이션이 통제해야 합니다.

연결 구조는 반드시 한 겹 두어라

외부 API나 내부 시스템을 붙일 때 가장 먼저 기억할 원칙은, LLM을 CRM이나 데이터베이스에 직접 꽂지 않는다는 점입니다. 실무에서는 보통 OAuth 인증, 웹훅, 내부 API, 미들웨어를 조합한 중간 계층을 두고 그 계층이 실제 시스템 접근을 통제합니다. 또 AI 호출을 코드 곳곳에 흩뿌리지 말고, 프롬프트 구성, 모델 선택, 재시도, 로깅, 검증을 한곳에서 맡는 오케스트레이션 서비스로 모으는 편이 유지보수와 감사 대응에 훨씬 유리합니다.¹²

좋은 구조는 대체로 다음 흐름을 가집니다.

사용자 요청이 들어오면, 애플리케이션은 먼저 누가 요청했는지와 무엇을 해도 되는지를 확인합니다. 그다음 LLM에 필요한 최소한의 컨텍스트만 모읍니다. CRM에서 최근 활동 몇 건을 가져오고, 검색 API에서 최신 자료를 조회하고, 데이터베이스에서 필요한 집계만 읽습니다. LLM은 이 정보를 바탕으로 답변 초안이나 액션 제안을 만듭니다. 그리고 마지막 실제 실행은 모델이 아니라 애플리케이션이 담당합니다.

이 구조가 중요한 이유는 간단합니다. LLM은 확률적으로 말하지만, CRM 업데이트나 결제 승인, 티켓 상태 변경은 결정적으로 처리되어야 하기 때문입니다. 모델은 제안할 수 있어도, 시스템은 확인된 규칙에 따라 움직여야 합니다.

이 관점에서 보면 LLM은 사람과 시스템 사이에 선 통역사이자 판단 보조 장치에 가깝습니다. 직접 데이터의 주인이 되면 안 됩니다.

읽는 연결: CRM, 검색 API, 사내 데이터베이스

연결의 첫 단계는 보통 읽기입니다. 먼저 읽고, 그다음 이해하고, 마지막에 행동합니다. 순서를 거꾸로 하면 사고가 납니다.

세 가지 데이터 소스는 역할이 다릅니다.

• CRM은 고객과 거래의 맥락을 담고 있습니다.

• 검색 API는 외부 세계의 최신 사실을 가져옵니다.

• 사내 데이터베이스는 수치, 상태, 이력 같은 확정 데이터를 제공합니다.

예를 들어 영업 보조 기능을 만든다고 해봅시다. 사용자가 이 고객에게 오늘 어떤 메일을 보내면 좋을까라고 묻는 순간, LLM이 자기 기억만으로 답하면 위험합니다. 고객의 최근 미팅 기록, 현재 딜 단계, 미결 이슈, 지난 이메일 반응률 같은 정보는 CRM에 있습니다. 따라서 애플리케이션은 먼저 CRM API를 호출해 필요한 필드만 가져오고, 그 결과를 LLM에 전달해야 합니다. 이렇게 하면 답변은 더 구체적이 되고, 헛소리할 여지도 줄어듭니다.

검색 API도 비슷합니다. 사용자가 경쟁사 최신 가격 정책을 반영해 제안서를 수정해 달라고 요청했다면, 모델 내부 지식만 믿을 수는 없습니다. 검색 API나 사내 검색 시스템에서 최신 문서를 가져와 근거를 붙여야 합니다. 검색이 먼저이고 생성은 나중입니다.

사내 데이터베이스는 특히 더 조심해야 합니다. 숫자는 말투보다 무섭습니다. 매출, 재고, 사용량, 정산 데이터처럼 실제 의사결정에 쓰이는 값은 한 자리만 틀려도 문제가 커집니다. 그래서 자연어 질문을 곧바로 임의 SQL로 바꿔 실행하게 두기보다, 읽기 전용 복제본이나 허용된 쿼리 템플릿을 사용하고, 실행 전에 범위와 조건을 검증하는 편이 안전합니다. OpenAI의 SQL 연결 가이드도 데이터베이스 앞에 미들웨어 애플리케이션을 두는 방식을 전제로 설명합니다.⁵

또 하나 흥미로운 지점은 서로 다른 시스템 사이의 필드 매핑입니다. 현장에서는 customer_name, accountName, bp_company_name처럼 이름만 달라도 같은 뜻인 필드가 잔뜩 나옵니다. LLM은 이런 스키마 매칭이나 변환 로직 초안을 만드는 데 꽤 유용합니다. 다만 실제 운영 규칙은 사람이 검토하고 버전 관리해야 합니다. 실제 기업 데이터는 빈값이 많고, 열 이름이 불친절하고, 회사별 커스텀 필드가 뒤섞여 있어서 공개 예제보다 훨씬 지저분하기 때문입니다.⁴

정리하면 읽기 연결의 목표는 모든 데이터를 한꺼번에 밀어 넣는 것이 아닙니다. 지금 질문에 필요한 최소한의 사실만 정확히 가져오는 것입니다.

쓰는 연결: 워크플로 시스템으로 행동을 넘겨라

읽기만 잘해도 도움이 되지만, 서비스의 체감 가치는 대개 쓰기에서 폭발합니다. 티켓을 생성하고, 담당자를 배정하고, CRM 활동 로그를 남기고, 승인 워크플로를 시작할 때 사용자는 비로소 AI가 일을 했다고 느낍니다.

그렇다고 LLM에게 바로 쓰기 권한을 주면 곤란합니다. 실전 패턴은 거의 항상 같습니다. 모델이 액션을 제안하면, 애플리케이션이 그 제안을 구조화된 형태로 받고, 권한과 정책을 확인한 뒤, 실제 워크플로 시스템이나 내부 API를 호출합니다. 그리고 결과를 다시 LLM에 넘겨 사용자에게 자연어로 설명하게 합니다.³

여기서 중요한 원칙은 세 가지입니다.

첫째, 상태를 바꾸는 액션은 가능한 한 좁은 도구로 노출합니다. update_crm_note처럼 목적이 분명한 도구는 괜찮지만, run_any_sql이나 call_any_endpoint 같은 만능 도구는 재앙에 가깝습니다.

둘째, 쓰기 액션에는 승인 단계를 끼워 넣을 수 있어야 합니다. 예를 들어 환불 승인, 가격 인하, 고객 등급 변경처럼 영향이 큰 작업은 사람이 마지막 버튼을 누르게 하는 편이 안전합니다.

셋째, 실행 결과는 기계가 읽기 쉬운 형식으로 남겨야 합니다. 성공, 실패, 오류 코드, 생성된 리소스 ID가 분명해야 나중에 재시도와 감사가 가능합니다.

워크플로 시스템 연동은 특히 이벤트 기반으로 잘 맞습니다. 새 문의가 들어오면 웹훅이 발동되고, 작업이 큐에 들어가고, 워커가 LLM 분류를 수행한 뒤, 티켓 시스템에 우선순위와 담당 팀을 기록하는 식입니다. 이렇게 하면 사용자 요청-응답 한 번에 모든 일을 끝내려 하지 않아도 됩니다.¹³

연결을 시스템으로 만들기 위한 계약

많은 팀이 이 단계에서 실수합니다. 모델이 대충 이런 뜻이겠지 하고 내놓은 문장을 다음 시스템이 그대로 받아 먹게 만들면, 언젠가 반드시 깨집니다. 연결이 길어질수록 프롬프트보다 계약이 중요해집니다.

여기서 말하는 계약은 사람이 읽는 문서가 아니라, 코드가 검증할 수 있는 출력 형식입니다. 예를 들어 LLM에게 다음 액션을 정하게 할 때는 자유 문장이 아니라 action_type, target_id, reason, confidence 같은 필드를 가진 구조화 출력으로 받는 편이 낫습니다. 그리고 서버에서 스키마 검증을 통과한 결과만 실제 시스템 호출에 사용해야 합니다. 생산 환경의 LLM 파이프라인이 입력 정규화, 프롬프트 조립, 실행, 검증, 후처리, 관측으로 수렴하는 이유가 바로 여기에 있습니다.³

실무에서 특히 효과적인 안전장치는 다음과 같습니다.

• 구조화 출력과 스키마 검증을 기본값으로 둔다.

• 프롬프트 버전, 모델명, 토큰 수, 지연 시간을 로그에 남긴다.

• 같은 요청의 중복 실행을 막기 위해 idempotency key를 둔다.

• 긴 작업은 스트리밍보다 비동기 잡으로 넘긴다.

• 실패 시 사람이 이어받을 폴백 경로를 준비한다.²³

여기서 폴백은 매우 중요합니다. AI가 실패하면 기능 전체가 멈추는 구조는 서비스가 아닙니다. 예를 들어 자동 요약이 실패하면 원문을 보여주고, 자동 분류가 실패하면 기본 규칙 기반 분류기로 넘기고, 자동 티켓 생성이 실패하면 대기열에 보류 상태로 저장해 사람이 처리하게 해야 합니다.²

결국 좋은 연결은 똑똑한 연결이 아니라, 실패해도 덜 위험한 연결입니다.

실전 패턴 1: CRM 영업 코파일럿

가장 흔하고, 가장 효과가 잘 나는 패턴입니다. 영업 담당자는 늘 문맥을 찾느라 시간을 씁니다. 지난 통화에서 무슨 이야기를 했는지, 지금 딜 단계가 어디인지, 어떤 반대 의견이 있었는지, 다음 메일에 무엇을 넣어야 하는지 매번 여러 화면을 뒤집어 봐야 합니다.

이때 LLM은 직접 영업을 대신하는 존재가 아니라, 고객 맥락을 읽고 다음 행동을 정리하는 보조자 역할을 맡으면 좋습니다.

흐름은 이렇습니다. 사용자가 계정 페이지에서 다음 후속 메일 초안 만들기를 누릅니다. 서버는 CRM에서 최근 활동, 오픈 딜, 최근 이메일 스레드, 고객 속성 정보를 읽습니다. 필요하면 외부 검색 API로 해당 회사의 최신 뉴스도 가져옵니다. 그런 다음 LLM은 메일 초안, 핵심 포인트, 다음 추천 액션을 구조화된 형태로 반환합니다. 사용자가 검토 후 승인하면, 그때 애플리케이션이 CRM에 활동 로그를 남기고 메일 발송 워크플로를 시작합니다.

이 패턴의 장점은 분명합니다. 모델은 글쓰기를 잘하고, CRM은 사실을 잘 저장합니다. 둘이 자기 역할만 하면 됩니다.

반대로 나쁜 구현은 이런 모습입니다. 모델에게 고객 정보를 전부 던지고 알아서 다음 행동도 하고 CRM도 업데이트해 달라고 맡기는 것입니다. 겉보기에는 자동화가 세 보여도, 실제로는 무슨 근거로 어떤 필드를 바꿨는지 추적이 안 됩니다.

실전 패턴 2: 자연어로 묻는 사내 데이터 질의

팀장이나 운영 담당자는 늘 비슷한 질문을 합니다. 지난주 환불률이 왜 올랐지, 어떤 요금제가 해지율이 높지, 지역별 재구매율이 어떻게 다르지. 이 질문마다 데이터 팀에 티켓을 만들게 하면 조직이 느려집니다.

그래서 많이 만드는 것이 자연어 질의 인터페이스입니다. 다만 여기에도 함정이 있습니다. 사용자의 질문을 그대로 SQL로 바꿔 실행하면, 편하긴 해도 통제가 어렵습니다.

더 안전한 방식은 두 단계로 나누는 것입니다. 먼저 LLM이 질문을 해석해 의도를 분류합니다. 예를 들어 이 질문은 주간 환불률 비교이고, 필요한 차원은 지역과 상품군이며, 기간은 최근 4주라고 정리합니다. 그다음 서버는 미리 정의된 쿼리 템플릿이나 승인된 분석 함수 중 하나를 선택해 실행합니다. 즉, LLM이 쿼리를 직접 책임지는 것이 아니라, 어떤 분석을 해야 하는지 설명하는 역할을 맡는 것입니다.

이 방식은 장점이 많습니다. 권한 제어가 쉽고, 성능이 안정적이며, 잘못된 SQL로 운영 데이터베이스를 흔들 위험도 줄어듭니다. 읽기 전용 연결, 미들웨어, 제한된 쿼리 범위는 이 패턴의 기본 장치입니다.⁵

또 이 패턴은 검색 API와도 잘 결합됩니다. 숫자는 데이터베이스에서, 정책 문서는 내부 검색에서, 설명 문장은 LLM에서 가져오면 됩니다. 그러면 답변은 단순히 수치를 뱉는 수준을 넘어서, 왜 그 숫자가 나왔는지까지 자연스럽게 설명할 수 있습니다.

실전 패턴 3: 티켓 분류와 워크플로 자동 시작

고객 지원이나 운영 문의에서는 속도가 생명입니다. 문의가 들어왔는데 어느 팀이 맡아야 하는지, 긴급도는 어느 정도인지, 어떤 템플릿으로 첫 응답을 보내야 하는지 정하는 데 시간이 오래 걸리면 사용자 경험이 금세 나빠집니다.

여기서 잘 맞는 패턴이 웹훅과 비동기 작업입니다. 문의가 들어오면 티켓 시스템이 이벤트를 발행합니다. 백엔드는 이 이벤트를 받아 큐에 넣고, 워커가 본문과 메타데이터를 LLM에 보내 분류를 수행합니다. LLM은 카테고리, 긴급도, 필요한 내부 팀, 권장 응답 초안을 구조화해서 반환합니다. 서버는 이를 검증한 뒤 티켓 시스템에 라우팅 결과를 기록하고, 필요한 경우 워크플로 엔진에서 후속 작업을 생성합니다.³⁶

이 패턴이 좋은 이유는 사용자에게 즉시 응답을 돌려줄 수 있기 때문입니다. 접수는 바로 끝내고, 무거운 분류나 연계 작업은 뒤에서 처리하면 됩니다. 긴 작업을 억지로 동기 요청 안에 밀어 넣지 않는다는 점이 중요합니다.³

그리고 여기에도 사람 검토 단계를 자연스럽게 끼울 수 있습니다. 예를 들어 긴급도가 높다고 판단된 티켓만 팀 리더 승인 대기 상태로 보내거나, 환불이나 법무 이슈가 의심되면 자동 실행 대신 검토 큐로 넘길 수 있습니다.

안티패턴: 멋져 보이지만 오래 못 가는 설계

실무에서 자주 보이는 나쁜 패턴도 짚고 넘어가겠습니다.

• LLM이 데이터베이스에 직접 붙어 임의 쿼리와 업데이트를 수행하는 구조

• 프런트엔드가 모델의 원시 응답을 그대로 파싱해 화면과 로직에 사용하는 구조

• 여러 테넌트의 데이터를 한 컨텍스트에 섞어서 보내는 구조

• 실패했을 때 재시도, 폴백, 감사 로그가 전혀 없는 구조

이런 설계는 데모에서는 반짝입니다. 하지만 운영에서는 거의 반드시 문제를 일으킵니다. 권한 누수, 비용 폭주, 설명 불가능한 상태 변경, 조용한 품질 저하가 차례대로 찾아옵니다.

특히 테넌시와 권한은 절대 타협하면 안 됩니다. 사용자가 볼 수 없는 데이터를 LLM 컨텍스트에 섞는 순간, 설령 화면에 직접 노출되지 않더라도 이미 경계는 무너진 것입니다.²

연결은 거창한 에이전트보다 작은 자동화에서 시작한다

외부 API와 내부 시스템을 연결한다고 해서 처음부터 거대한 에이전트를 만들 필요는 없습니다. 오히려 처음에는 단일 목적 흐름이 훨씬 낫습니다. 예를 들어 고객 요약 만들기, 문의 자동 라우팅, 회의록을 CRM 활동으로 정리하기처럼 입력과 출력이 분명한 작업부터 시작하는 편이 좋습니다.

작게 시작하면 무엇이 보일까요. 어떤 시스템의 데이터 품질이 낮은지, 어떤 필드 매핑이 자주 깨지는지, 어디서 사람이 마지막 확인을 원하지, 어떤 작업이 동기 요청에 어울리고 어떤 작업이 비동기로 가야 하는지가 보입니다. 그다음에야 여러 툴을 오가며 계획을 세우는 에이전트가 필요한지 판단할 수 있습니다.

결국 실전 LLM 서비스의 경쟁력은 모델 하나의 지능에서 나오지 않습니다. 고객 데이터, 업무 규칙, 승인 흐름, 실패 처리, 로그와 같은 서비스의 뼈대와 얼마나 자연스럽게 결합되느냐에서 나옵니다. 말을 잘하는 모델은 많습니다. 하지만 시스템을 안전하게 읽고, 제대로 이해하고, 필요한 순간에만 정확히 행동하는 서비스는 여전히 드뭅니다.

바로 그 차이가 기능과 서비스의 차이입니다.

참고

¹AI Integration Architecture: Connecting LLMs to Your CRM, ERP & Legacy Systems

²LLM Integration in Enterprise Applications: Patterns and Pitfalls

³LLM API Integration Patterns for Applications (2026 Guide)

⁴How LLMs Are Transforming Enterprise Integration Patterns

⁵GPT Actions library - SQL Database

⁶LLM Integration Patterns for Enterprise: Beyond the Chatbot