Function Calling 과 MCP — 표준은 누가 정하는가

Function Calling이 결제 자동화의 문을 열었다 — 그런데 어느 문?

Function calling 이전에 LLM을 결제·정산 워크플로에 연결하려면, 모델이 출력한 자연어 문장을 다시 코드가 파싱해서 액션으로 변환해야 했다. "이 거래는 취소 처리가 필요합니다"라는 텍스트를 받아서 담당 코드가 다시 의미를 해석하는 구조였다. 파싱 오류, 모호한 표현, 예외 케이스 처리가 레이어마다 쌓였고, LLM이 판단한 결과를 실제 시스템 액션으로 연결하는 신뢰도는 항상 불안했다.

HEDVION 팀이 Function calling의 실용성을 직접 체감한 건 2023년 말, 정산 예외 처리 자동화를 시도하면서부터다. 하루 수백 건의 정산 건 중 금액 불일치나 상태 오류가 발생한 건을 탐지해 재처리를 요청하는 파이프라인을 만들고 싶었다. flag_settlement_anomaly(transaction_id, reason)와 request_reprocess(transaction_id, priority) 같은 도구를 정의하고 나자, 모델이 직접 판단과 호출을 구조화된 형태로 출력할 수 있게 됐다. 자연어 해석 레이어가 사라졌고, 불필요한 중간 파싱 코드도 제거됐다. 문제는 이 "문"이 OpenAI용인지, Anthropic용인지, Google용인지에 따라 자물쇠 모양이 달랐다는 점이다.

제공사 차이가 만드는 실무 마찰 — 추정 공수 반나절의 의미

OpenAI는 tools 배열에 JSON Schema로 함수를 정의하고 tool_calls 배열로 결과를 반환한다. Anthropic은 tool_use 콘텐츠 블록 구조를 쓰고, 병렬 호출 방식과 스트리밍 중 도구 호출 처리가 다르다. Google Gemini는 FunctionDeclaration 객체를 사용하며, 에러 응답 구조도 독자적이다. 스키마 필드 이름, 필수값 처리 방식, 다중 도구 동시 호출 지원 여부가 세 제공사 모두 미묘하게 다르다.

작은 팀에서 이 차이는 즉시 비용으로 잡힌다. Anthropic Claude로 구축한 정산 이상 탐지 파이프라인을 GPT-4o로 전환 테스트했을 때, tool_use 응답 처리 로직을 전부 재작성해야 했다. 실제 소요 시간: 약 반나절. 숫자만 보면 작아 보이지만, 이 경험이 팀 내에 "그냥 한 모델 고정하자"는 관성을 만들었다. 모델 교체 실험에 드는 예상 마찰이 실험 자체를 꺼리게 만드는 심리적 비용으로 작동한 것이다. 표준화 부재의 실질적 피해는 기술적 복잡도가 아니라 실험 속도 저하로 나타난다.

MCP가 제시하는 구조: 가능성과 현실 사이의 거리

MCP(Model Context Protocol)는 Anthropic이 2024년 말 공개한 오픈 프로토콜로, 도구(tool)·리소스(resource)·프롬프트 템플릿을 모델이 접근하는 방식을 서버-클라이언트 구조로 분리한다. 핵심 가치 제안은 이렇다: PG사 환불 API 래퍼를 MCP 서버로 한 번 만들어두면, 이후 Claude든 다른 MCP 클라이언트든 같은 서버에 붙어서 도구를 쓸 수 있다. 어댑터를 모델마다 따로 만들 필요가 없어진다.

현실은 아직 간극이 있다. OpenAI는 2025년 MCP 지원을 발표했지만 구현 성숙도는 초기 단계이고, Google은 자체 생태계를 병행 운영 중이다. 더 중요한 건 운영 현실이다. MCP 서버를 프로덕션에 올리려면 별도 인프라와 가용성 관리가 필요하다. 결제 시스템에서 MCP 서버 장애가 PG사 API 호출 실패로 전파되는 시나리오는 허용할 수 없다. HEDVION 팀이 내부 PoC에서 MCP 서버를 활용해 슬랙 알림·정산 DB 조회·PG사 API 래퍼를 노출시켰을 때, 기능 자체는 잘 동작했지만 회로 차단기(circuit breaker) 패턴 없이 프로덕션에 올릴 수는 없다는 결론을 냈다. 프로토콜의 가능성과 운영 준비도 사이의 거리가 아직 존재한다.

표준화 경쟁의 역학: 누가 이기는가

역사적으로 기술 표준 경쟁에서 이기는 쪽은 사양이 완벽한 쪽이 아니라 가장 넓은 생태계를 먼저 만든 쪽이었다. SOAP vs REST, XML vs JSON이 그 예다. REST와 JSON이 승리한 건 기술적 우월성보다 개발자 도구 지원과 생태계 관성 때문이었다. 지금 MCP를 둘러싼 구도도 유사하다. Anthropic은 Claude.app, Claude Code, 서드파티 개발 도구(VS Code, Cursor 등)에 MCP를 빠르게 통합하며 생태계를 선점하는 전략을 쓰고 있다.

반면 OpenAI는 Assistants API와 자체 function calling 고도화에 집중하고 있고, Google은 Vertex AI Function Calling과 Extensions 생태계를 독자 발전시키고 있다. 우리 팀의 판단은, 20262027년 사이에는 "OpenAI 방식의 function calling"과 "MCP"가 사실상의 양대 표준으로 공존하는 구도가 될 가능성이 높다는 것이다. 하나가 지배적 표준으로 수렴하더라도 23년은 더 걸릴 것이고, 그 기간 동안 어느 한 쪽에 완전히 베팅하는 건 과도한 리스크다.

HEDVION이 지금 택한 포지션: 얇은 추상 레이어와 조건부 MCP

우리 팀이 현재 운영하는 방식은 모델 호출과 도구 실행 사이에 얇은 어댑터 레이어를 두는 것이다. 도구 정의를 JSON Schema 형태로 중립적으로 관리하고, Anthropic용 변환기와 OpenAI용 변환기를 각각 유지한다. 이 어댑터 코드는 전체 200줄 이내로, 유지보수 부담이 크지 않다. 이 레이어 덕분에 지난 6개월 사이 Claude 3 Opus → Claude 3.5 Sonnet → Claude 3.5 Sonnet(20241022)으로 두 번 모델을 교체했는데, 정산 파이프라인 핵심 코드는 단 한 줄도 바꾸지 않았다. 실험 마찰이 사라지니 모델 교체 판단이 빨라졌다.

MCP에 대해서는 두 가지 조건이 갖춰질 때 프로덕션 전환을 결정하기로 했다. 첫째, MCP 서버 장애가 결제 파이프라인 가용성에 전파되지 않도록 circuit breaker 패턴이 코드베이스에 통합될 것. 둘째, 카드사 API 자격증명·고객 식별자 같은 민감한 파라미터는 MCP 서버 레이어에서 런타임 주입하고, 모델 컨텍스트에는 절대 노출하지 않을 것. 이 두 조건은 표준 경쟁 결과와 무관하게 우리 시스템의 보안·가용성 기준이기도 하다. 조건이 갖춰지기 전까지는 추상 레이어 방식을 유지하면서 PoC를 계속 진행한다.

지금 바로 써먹을 시사점

표준이 정해질 때까지 기다리는 건 전략이 아니다. 결제·정산 자동화처럼 외부 시스템 연동이 핵심인 환경에서 표준 승자 확정을 기다리면 그만큼 자동화 기회를 놓친다. 지금 시작하되 다음 세 가지를 설계에 처음부터 넣으면, 표준이 바뀌어도 전환 비용이 최소화된다.

① 도구 정의를 중립 포맷으로 관리하라. JSON Schema로 도구 스펙을 작성하고, 모델별 변환은 얇은 어댑터에서만 처리한다. LangChain 등 프레임워크를 쓰더라도 도구 정의 자체는 프레임워크 종속 포맷이 아닌 순수 데이터 구조로 관리한다. 교체 비용이 어댑터 200줄로 수렴한다.

② 민감한 파라미터는 도구 실행 레이어에서 주입하라. API 키, DB 자격증명, 고객 개인정보가 모델 컨텍스트에 들어가는 순간 감사(audit) 경계가 흐려지고, 프롬프트 인젝션 공격 면적이 넓어진다. 결제 데이터를 다루는 시스템에서 이 패턴은 선택이 아니라 필수다.

③ MCP는 지금 PoC 수준으로 미리 익혀두어라. 사양 문서를 읽는 것과 실제 MCP 서버를 띄워 Claude Code나 Claude Desktop에 연결해보는 건 체감이 완전히 다르다. 내부 도구 하나(예: 슬랙 알림, 정산 상태 조회)를 MCP 서버로 감싸는 실험을 지금 해두면, 생태계가 성숙해서 전환이 유리해지는 시점에 빠르게 움직일 수 있다. 실험 비용은 반나절이면 충분하다.

표준은 우리가 정하는 게 아니다. 하지만 표준이 결정되는 방향을 관망하면서도 지금의 기회를 활용하는 방법은 있다. 얇게 추상화하고, 빠르게 실험하고, 보안 경계를 명확히 긋는 것 — 이 세 가지가 HEDVION 팀이 이 싸움에서 고른 포지션이다.