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

LLM 이 외부 시스템과 상호작용하는 방식은 지난 2년 사이 꽤 빠르게 진화했다. 처음에는 각 제공사가 자기만의 function calling 형식을 정의했고, 이제는 모델 컨텍스트 프로토콜(MCP) 같은 더 넓은 표준화 시도가 등장하고 있다. 이 흐름이 실무에 어떤 의미인지 정리해봤다.

Function Calling 이 해결한 것

Function calling 은 LLM 이 단순히 텍스트를 생성하는 것을 넘어, “이 요청은 외부 함수를 호출해야 한다”는 판단을 할 수 있게 해줬다. 모델이 어떤 함수를 언제 호출할지 결정하고, 인자를 구조화된 형태로 출력하면 애플리케이션이 이를 실행하고 결과를 다시 모델에 넘기는 방식이다.

이 패턴은 자연어 → 도구 호출 → 결과 해석 흐름을 표준화했다는 점에서 의미가 컸다. 하지만 각 제공사마다 스키마 정의 방식, 도구 이름 규칙, 에러 처리 등이 달랐기 때문에 여러 모델을 함께 쓰는 환경에서는 어댑터 레이어가 필요했다.

MCP 가 추가하는 것

MCP(Model Context Protocol)는 이 레이어를 더 아래로 내리는 시도다. 도구(tool)뿐 아니라 리소스(resource), 프롬프트 템플릿까지 모델이 접근하는 방식을 단일 프로토콜로 정의하려 한다. 서버-클라이언트 구조로 도구를 분리할 수 있어서, 같은 도구를 여러 모델이 공유할 수도 있다.

# 개념적 구조 (단순화)
# MCP 서버: 도구를 정의하고 노출
server.expose_tool("search_documents", handler=search_fn)

# MCP 클라이언트(모델): 사용 가능한 도구 목록을 조회하고 호출
tools = client.list_tools()
result = client.call_tool("search_documents", {"query": "..."})

표준화의 어려움

문제는 생태계가 빠르게 움직인다는 점이다. OpenAI, Anthropic, Google 이 각자의 function calling 방식을 계속 발전시키고 있고, MCP 도 아직 초기 단계다. “표준”이라는 이름이 붙더라도 실제로 모든 제공사가 동일하게 따르기까지는 시간이 걸린다.

역사적으로 이런 상황에서 실질적 표준은 가장 많이 쓰이는 쪽이 된다. REST API 가 그랬고, JSON 이 그랬다. 지금 MCP 를 둘러싼 논의도 비슷한 경로를 따를 것으로 본다 — 제공사 간 경쟁이 있더라도 사용자 생태계가 특정 방식으로 모이면 그게 사실상의 표준이 된다.

우리 팀의 입장

우리는 지금 특정 표준에 베팅하기보다, 인터페이스를 얇은 추상 레이어로 감싸두는 방식을 택하고 있다. 모델이 바뀌거나 프로토콜이 바뀌더라도 교체 비용을 최소화하는 것이 목표다. 표준화 경쟁의 승자가 가려지면 그때 더 깊이 들어갈 계획이다.

— by slecs