LLM 시대, “어떤 API를 호출해야 할까?”라는 질문이 더 이상 의미 없는 이유

이 글은 소프트웨어 인터페이스가 어떻게 변화해 왔는지, 그리고 왜 LLM(대규모 언어 모델) 시대에는 기존의 API 중심 사고방식이 한계에 도달했는지를 설명합니다. 특히 Model Context Protocol(MCP) 이라는 개념을 중심으로, 인터페이스가 코드 기반 호출에서 자연어 기반 ‘의도(Intent)’ 중심으로 이동하고 있는 배경과 그 의미, 기업과 개발자에게 어떤 변화가 요구되는지를 정리합니다.

반응형

---

소프트웨어 인터페이스의 진화: 명령에서 의도로

소프트웨어 역사에서 인터페이스는 항상 “기계의 언어를 사람이 배우는 방식”이었습니다.

• CLI 시대(1980년대): 사용자는 grep, ssh, ls 같은 명령어를 외워야 했습니다.
• API 시대(2000년대 중반): GET /users 같은 REST 엔드포인트를 호출하며 시스템을 연동했습니다.
• SDK 시대(2010년대): client.orders.list() 같은 라이브러리를 통해 HTTP를 직접 다루지 않아도 됐습니다.

형태는 달라졌지만 공통점은 분명합니다.
사용자는 항상 “어떤 함수를 호출해야 하는지”를 알고 있어야 했습니다.

하지만 LLM의 등장은 이 전제를 흔들고 있습니다.

---

LLM 시대의 핵심 변화: 함수가 아니라 결과를 말한다

이제 질문은 더 이상 “Which API do I call?”이 아닙니다.
대신 이렇게 바뀝니다.

“내가 얻고 싶은 결과는 무엇인가?”

현대 LLM은 사용자가 원하는 결과와 의도를 자연어로 표현하면, 그 의도를 해석해 필요한 기능을 찾고 실행할 수 있습니다. 이 흐름에서 등장한 개념이 바로 MCP(Model Context Protocol) 입니다.

MCP는 소프트웨어 기능을 개발자가 알고 있는 함수 형태가 아니라,
모델이 이해할 수 있는 ‘의도 기반 능력(capability)’ 으로 노출하는 추상화 계층입니다.

---

MCP란 무엇인가: API를 ‘호출’하지 않고 ‘발견’하는 방식

MCP 환경에서도 내부적으로는 기존과 같은 요소들이 존재합니다.

• 데이터 접근
• 비즈니스 로직
• 오케스트레이션

차이점은 이것들이 직접 호출되지 않는다는 점입니다.

예를 들어 기존 방식에서는 다음과 같았습니다.

• billingApi.fetchInvoices(customerId=…)

하지만 MCP 기반 자연어 인터페이스에서는 이렇게 말합니다.

• “1월 이후 Acme Corp의 모든 청구서를 보여주고, 연체된 항목을 강조해줘”

모델은 이 요청을 분석해

• 고객 엔티티를 식별하고
• 적절한 시스템을 선택하며
• 필요한 데이터 호출과 필터링을 수행한 뒤
• 구조화된 결과를 반환합니다

개발자의 역할은 엔드포인트를 연결하는 것이 아니라,
어떤 능력이 존재하는지 정의하고, 안전한 경계(가드레일)를 설정하는 것으로 이동합니다.

---

기업 관점에서 MCP가 중요한 이유

대부분의 기업 문제는 “도구가 없어서”가 아니라 “도구가 너무 많아서” 발생합니다.

• 내부 시스템이 너무 많고
• 각 시스템마다 인터페이스가 다르며
• 사용자 교육과 연동 비용이 계속 증가합니다

자연어가 인터페이스가 되면, 사용자는 더 이상 함수명이나 파라미터를 알 필요가 없습니다.
“무엇을 하고 싶은지”만 말하면 됩니다.

실제로 자연어 인터페이스(NLI)는

• 마케터가 SQL 없이 데이터에 접근하고
• 분석 대기 시간을 줄이며
• 데이터 요청을 대화 수준의 속도로 바꾸고 있습니다

시간 단위의 작업이 초 단위의 대화로 바뀌는 셈입니다.

---

인터페이스 사다리로 보는 변화 흐름

시대	인터페이스	대상
CLI	쉘 명령어	숙련 사용자
API	웹/RPC 엔드포인트	개발자
SDK	라이브러리 함수	프로그래머
자연어(MCP)	의도 기반 요청	사람 + AI 에이전트

이 흐름의 핵심은 명확합니다.
기계에 맞추던 언어를, 이제는 기계가 사람의 언어를 이해합니다.
이는 단순한 UX 개선이 아니라, 아키텍처 자체의 변화입니다.

---

개발과 통합 방식의 변화

MCP 기반 시스템에서는 온보딩 방식도 달라집니다.

기존:

• 스키마 매핑
• 글루 코드 작성
• 사용자 교육

변화 후:

• 비즈니스 엔티티 정의
• 능력(capability) 선언
• 자연어로 발견 가능하게 노출

사용자는 호출 순서나 파라미터 이름을 몰라도 됩니다.
연구 결과에서도 LLM을 API 인터페이스로 사용할 경우, 챗봇이나 자동화 워크플로 개발에 드는 시간과 리소스가 줄어드는 것으로 나타났습니다.

---

생산성 측면에서의 효과

자연어 기반 인터페이스는 단순한 편의성을 넘습니다.

예를 들어 과거에는

• CSV 추출
• 데이터 가공
• 슬라이드 작성

이 필요했던 작업이, 이제는 이렇게 바뀝니다.

• “지난 분기 이탈 위험 상위 5가지 요인을 요약해줘”

결과는 내러티브와 시각 자료 형태로 바로 제공됩니다.
사람의 역할은 데이터 처리자가 아니라 의사결정자로 이동합니다.

---

새로운 아키텍처 요구사항과 리스크

자연어는 본질적으로 모호합니다.
따라서 MCP 기반 시스템에는 다음이 반드시 필요합니다.

• 인증과 접근 제어
• 로깅과 감사 추적
• 의도 해석의 투명성
• 가드레일과 거버넌스

자연어 인터페이스가 강력한 만큼, 잘못 설계되면

• 잘못된 시스템 호출
• 데이터 노출
• 의도 오해
  로 이어질 수 있습니다.

---

조직과 역할의 변화

API 중심 시대에는 통합 엔지니어가 중요했습니다.
MCP 시대에는 새로운 역할이 등장합니다.

• 비즈니스 의미 체계를 설계하는 역할
• 능력과 엔티티를 정의하는 아키텍트
• 에이전트 컨텍스트를 관리하는 전문가

기술 스킬뿐 아니라 도메인 이해, 의도 설계, 평가와 감독 능력이 핵심 역량이 됩니다.

---

지금 기업이 해야 할 일

1. 자연어를 ‘추가 기능’이 아닌 인터페이스 계층으로 인식합니다.
2. 자연어로 안전하게 호출 가능한 업무 흐름을 식별합니다.
3. 이미 보유한 데이터 서비스와 API를 목록화합니다.
4. 그것들이 의도 기반으로 발견 가능한지 점검합니다.
5. 작은 도메인부터 MCP 스타일 레이어를 파일럿으로 적용합니다.

---

질문은 이미 바뀌었다

자연어는 새로운 프론트엔드가 아닙니다.
소프트웨어의 기본 인터페이스 계층이 되고 있습니다.

MCP는 이 변화를 가능하게 하는 핵심 추상화입니다.
더 빠른 통합, 더 높은 생산성, 그리고 새로운 역할의 탄생까지 이어집니다.

이제 남은 질문은 하나입니다.

“어떤 API를 호출해야 하지?”가 아니라
“나는 무엇을 하고 싶은가?”

https://venturebeat.com/orchestration/why-which-api-do-i-call-is-the-wrong-question-in-the-llm-era?fbclid=IwY2xjawPISQdleHRuA2FlbQIxMQBzcnRjBmFwcF9pZBAyMjIwMzkxNzg4MjAwODkyAAEed46gzQ4UAkDwRsLNT5TQnqf3DVTUeFv0CKtPGhX4LobyhzvVzOYrETyWplc_aem_ANT5EnqLbx-19GySILC0Tg

Why “which API do I call?” is the wrong question in the LLM era