레거시 API에서 AI-Ready API로의 패러다임 전환 (feat. MCP)
최근 스터디와 여러 기술 논의를 거치며, 개발자로서 큰 망치를 맞은 듯한 깨달음을 얻은 주제가 있습니다.
바로 'AI Agent 시대의 API 설계'입니다.
과거에는 '어떻게 하면 인간 개발자가 쓰기 편한 API를 만들까?'를 고민했다면, 이제는 '어떻게 해야 LLM(대규모 언어 모델)이 우리의 API를 찰떡같이 알아듣고 알아서 쓰게 만들까?'로 무게 중심이 이동하고 있습니다.
오늘은 GUI에서 LUI로의 전환, 그리고 AI 시대의 표준 규격으로 떠오르는 MCP에 대해 정리해 보겠습니다.
1. GUI에서 LUI의 시대로
지금까지의 서비스는 UI라는 제한된 명령 체계 안에서 움직였습니다.
직관적으로 버튼을 누르고 화면을 이동하며 사용자가 직접 '판단'을 내렸죠.
하지만 이제는 자율적 판단을 AI가 수행하는 LUI 시대로 진입했습니다.
사용자는 모호하고 유연한 언어로 지시를 내리고, AI가 귀찮고 상세한 부분을 대신 처리합니다.
여기서 필연적으로 부각되는 문제가 바로 '할루시네이션'입니다.
할루시네이션은 버그가 아니다
우리는 흔히 AI가 거짓말을 하면 시스템이 고장 났다고 생각합니다.
하지만 LLM의 본질은 '사실을 밝히는 논리 시스템'이 아니라, '사전 학습된 데이터의 통계 분포를 바탕으로 가장 확률이 높은 다음 단어를 만들어내는 시스템'입니다.
즉, 문맥을 새롭게 정의하며 말을 지어내는 것이 원래의 동작 방식입니다.
따라서 이를 해결하려면 AI를 고치는 것이 아니라, AI 주변의 환경을 보완해야 합니다.
- 가드레일과 외부 도구: 도출된 답변을 외부 API로 재검증.
- 다단계 메모리 도입: 사용자의 컨텍스트와 이전 대화를 반영하여 상식의 오차 줄이기.
2. LLM과 외부 세상의 연결 고리
LLM이 할루시네이션을 극복하고 외부 데이터를 정확히 가져오려면 '도구'를 쥐여줘야 합니다.
하지만 세상에는 수많은 API가 있고, LLM마다 이를 연동하는 규격이 제각각이었습니다.
이 혼란을 평정하기 위해 등장한 표준 프로토콜이 바로 Model Context Protocol입니다.
MCP는 그 자체로 대단한 신기술이라기보다는, AI와 외부 서비스를 연결하는 명확한 통신 규약입니다.
그리고 이 바탕에는 굉장히 직관적이고 심플한 JSON RPC 2.0이 자리 잡고 있습니다.
왜 굳이 Dummy해 보이는 JSON RPC 2.0을 쓸까?
처음엔 "왜 이렇게 단순하고 텍스트 기반인 구식 프로토콜을 쓸까?" 의문이 들 수 있습니다.
핵심은 'LLM Agent 입장에서의 가독성과 문맥 파악'입니다.
구조가 단순하고 그 자체로 설명적(descriptive)이기 때문에 AI가 파싱하고 이해하기에 최적화되어 있는 것이죠.
[MCP 명령별 구체적인 RPC 규격 예시]
1. 도구 목록 요청
AI가 "너 무슨 도구 가지고 있어?"라고 묻고 확인하는 과정입니다.
// Request
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list"
}
// Response
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"tools": [...] // 사용 가능한 API(도구)들의 명세
}
}
2. 도구 실행
AI가 날씨 도구를 선택해 서울의 날씨를 물어봅니다.
// Request
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "Seoul" }
}
}
// Response
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [{
"type": "text",
"text": "맑음, 기온 1°C"
}]
}
}
3. 레거시 API vs AI-Ready API 디자인
가장 중요한 패러다임의 변화는 'API를 소비하는 주체가 누구인가'입니다.
- 레거시 API:
- 목적: 이용자가 다양한 조합으로 기능을 유연하게 쓸 수 있도록 설계.
- 특징: 복잡성을 추상화하고 널리 알려진 RESTful 구조 채택. 엔드포인트를 줄이고 파라미터를 다양하게 받는 형태를 선호.
- AI-Ready API:
- 목적: AI가 고민하지 않고 정확한 도구를 선택해 실행할 수 있도록 설계.
- 특징: 자연어 설명보다 JSON Schema 같은 엄밀한 타입 명세가 중요. 기능이 중복되지 않도록 단일 목적을 명확히 해야 함.
파라미터가 너무 많거나 유연하면 AI가 추론 과정에서 토큰을 낭비하고 길을 잃음.
4. 인간의 하찮은 판단을 버려라
다른분들과 토론하며 가장 인상 깊었던 대목이 있습니다.
"AI에게 제공할 API 커버리지를 어떻게 중복 없이 밸런스 있게 설계할 수 있을까?
t-SNE로 군집을 분석해 봐야 할까?"라는 깊은 고민에 대해, 이런 답변이 돌아왔습니다.
"인간이 하려니 어려운 것입니다. 툴을 다 던져주고 LLM에게 정리해서 필요한 조합을 찾으라고 하세요.
발상을 AI 친화적으로 바꿔야 합니다."
머리를 한 대 맞은 기분이었습니다. 우리는 자꾸 과거의 습관대로 인간 엔지니어가 시스템의 모든 경우의 수를 통제하고 설계하려고 합니다.
하지만 다대다 구조로 얽힌 수많은 API 환경에서 최적의 도구를 조합해 내는 것은 AI가 훨씬 잘하는 영역입니다.
말 탄 기수가 자동차와 달리기 경주를 하려 들면 안 되듯, 뇌를 조금 비우고 AI Agent 지향적으로 사고를 전환하는 것이 현시점 개발자에게 가장 필요한 덕목이 아닐까 싶습니다.
마무리
이번 논의들을 정리하면서 시스템 아키텍처를 대하는 관점이 한 차원 확장되는 느낌을 받았습니다.
사실 그동안 백엔드 생태계에서 좋은 설계를 구축하는 이유는 결국 '유지보수하는 인간 개발자'를 위해서였습니다.
그런데 이제는 시스템을 소비하는 거대한 주체로 'AI'가 편입되었습니다.
스프링으로 연동하는 사이드에서 "AI가 잘못된 게 아니라 허접한 AI를 쓰는 혹은 AI에게 불친절한 환경을 제공하는 내 잘못이다"라는 문장이 억이 떠올랐습니다.
앞으로 API를 설계할 때 Swagger나 API Docs를 예쁘게 꾸미는 것을 넘어, '이 엔드포인트를 LLM이 읽었을 때 한 치의 오해 없이 목적을 파악할 수 있을까?'를 먼저 고민하게 될 것 같습니다.
도구의 설계권은 여전히 우리에게 있지만, 도구를 조립하고 활용하는 주도권은 기꺼이 AI에게 내어주는 연습을 해야겠습니다.
