개발한 서비스 중 불편했던 이슈

이미지로 된 동의서에 관리 시스템에 등록된 소유자 정보들을 연동해서 작성하거나, 폼(Form)을 제공해서 소유자가 직접 입력할 수 있다. 동의서를 전자화할 수 있는 방법이 있는데, 직접 만든 에디터(웹 애플리케이션)를 가지고 어떤 곳이 이름인지, 전화번호인지 기입 영역을 정의하고 좌표화시킬 수 있다.

이렇게 보면 기능 동작에는 문제가 크게 없었다. 하지만 맡아야 하는 프로젝트가 더 많아졌고, 에디터 유지보수에 집중적으로 신경 쓰지 못했다. 그러다 보니 불편한 사용성에 대한 기술 부채가 쌓였고, 수정을 해도 가이드 문서들을 새로 갱신해야 하는 부담감 때문에 건드리기가 더 무서워졌다. 실무자분들께서 에디터를 쓴다고 할 때마다 약간 죄송한 마음도 들고, 불편하다고 건의할까 봐 마음이 불안하기도 했다.

어느 날 토스 기술 블로그를 보고 있었는데, MCP 서버를 구현해서 PG 서비스를 연동하는 걸 Cursor로 금방 해결할 수 있다는 글을 보게 됐다. 새로운 기술을 빠르게 도입할 수 있다는 부분이 부럽기도 하면서, 동의서 에디터의 불편한 점들을 해결할 수 있을 것 같다는 생각이 들었다.

MCP를 알기 전에 알게된 배경지식

초기 GPT의 한계

최근 널리 사용되고 있는 ChatGPT, Claude, Gemini는 모두 LLM(Large Language Model) 기반의 AI 애플리케이션이다. LLM은 대형 언어 모델로, 인터넷의 방대한 텍스트 데이터를 학습하여 자연어의 맥락을 효과적으로 파악할 수 있다.

하지만 초기 버전의 GPT 같은 경우 단순히 백과사전 수준의 정보 제공에 그쳤다. LLM이 아무리 대형 언어 모델이라고 해도 학습 데이터가 한정되어 있어 최신 정보에 대한 답변을 제공하지 못했고, 단순한 답변 생성에만 그쳐 맥락에 따른 구체적인 기능을 수행하지 못했다.

Agent의 등장

이러한 한계를 극복하기 위해 Agent라는 개념이 도입되었다. Agent는 LLM의 보조 역할을 하며, 단순히 답변만 생성하던 것에서 나아가 최신 정보를 실시간으로 가져오고, 이를 기억하며, 다양한 도구(tool)들을 활용할 수 있게 되었다. 또한 ChatGPT와 같은 플랫폼에서 일반 개발자들이 직접 기능(도구)을 만들어 연동할 수 있도록 지원하고 있다.

이처럼 많은 발전이 이루어졌지만, 여러 회사에서 제공하는 서비스들을 활용하여 도구를 만드는 것은 생각보다 쉽지 않다. LLM 애플리케이션에 사용되는 Agent 프레임워크마다 연동하려는 서비스 모듈이 해당 프레임워크의 SDK에 의존해야 하고, 프레임워크 종류별로 모두 대응해야 하기 때문에 상당한 개발 공수가 필요하다.

2024년 11월쯤 Claude를 만든 회사, 엔드로픽(Anthropic)에서 새로운 제안을 하게 되었다.

구원해줄 개념, MCP

위에 있는 사진은 MCP라는 용어를 한번이라도 들어봤으면 같이 봤을 것이다. ‘MCP는 USB-C다.‘라고 비유하듯이, 내가 만든 도구와 여러 LLM 기반 앱에 연동하기 위해서 파편화된 통신 방식들을 표준화했다. 말 그대로 프로토콜, 표준 통신 규약이다.

만약 내가 식당에 갔는데, 한국어로 주문을 하려다가 종업원분들이 “한국어”를 못하고 “중국어”, “일본어”, “태국어”밖에 할 줄 모른다고 하자. 다음에 이 식당에서 주문하기 위해 각각 언어를 배워가야 하는 불편함을 인지한 식당에서 각 종업원에게 어떻게 주문을 받는지 공통적으로 교육시키면서 통역기를 줬다. 이것들을 다시 MCP에 빗대어 표현하면 위 그림과 같다.

MCP의 구성

MCP의 구성 요소는 크게 ‘Host’, ‘Client’, ‘Server’로 나눠서 설명할 수 있으며, 내 서비스와 연동하기 위해서 MCP Server는 필수적으로 구현해야 한다. Claude Desktop, ChatGPT처럼 대중적인 AI 앱이 아닌 자체 앱에 연동을 해야 한다면 MCP Client까지 구현하는 것을 고려해야 한다.

구성 요소의 역할들은 아래와 같이 설명할 수 있다.

• Host: Claude Desktop, ChatGPT 같은 AI 앱이며, 웹 개발 관점에서 보면 ‘브라우저’ 같은 위치
• Client: 사용자의 요청을 MCP 프로토콜에 맞게 변환하며 MCP Server와 1대1 양방향 통신
• Server: 외부 서비스와 연결하는 중계자, 독립적으로 프로세스 실행

추가적으로 여기서 말한 MCP 프로토콜은 JSON-RPC 2.0 표준 형태로 요청 및 응답을 주고받는다고 보면 된다. MCP 프로토콜 형태로 가공 처리 및 서버에 대한 전송 방식들은 모두 SDK로 제공해주니 크게 신경 쓰지 않고 외부 서비스와 MCP 서버의 메서드 처리에 집중하면 된다.

MCP Server는 어떻게 하면 될까?

일반 서버와 구현하는 방식이 많이 다를 것 같아서 내가 쉽게 이해할 수 있을까에 대한 걱정을 많이 했다. 다행히 MCP Server SDK가 제공되면서 오히려 Server 구현에 대한 부담이 덜 됐다. 결론적으로 말하면 LLM이 잘 해석할 수 있는 결과값을 제공하는 것에 초점을 뒀다.

MCP Server 내에 필요한 외부 서비스가 이미 있는 상태에서 크게 수정한 것이 없었고, Server 내의 기능들을 활용해서 구축하면 된다. Resources, Tools, Prompts가 주요 기능이며 아래와 같이 설명할 수 있다.

• Resources: 로그, DB 스키마, 텍스트 같은 정적 리소스들을 LLM에게 제공(읽기 전용, 외부 서비스 영향 없음)
• Tools: LLM이 수행할 수 있는 기능 제공(실행 가능, 외부 시스템 영향 있음)
• Prompts: LLM이 쉽게 대화할 수 있도록 규격화된 대화 양식

이런 기능들을 활용하여 내가 Claude Desktop을 실행하게 되면 해당 MCP Server에 대한 정적 자원들이 무엇이 있는지 가져오고, 어떤 도구들이 있는지 목록을 가져온 상태에서 사용자가 요청한 대화에 따라 리소스 또는 도구들을 쓸지 결정하고 실행한다.

기대했던 결과가 잘 나왔냐?

기존의 에디터 기능이 생각보다 많아서 100% 처리할 수 없지만 핵심 기능만 우선 MCP Server에 구현해서 Claude Desktop에 만든 MCP를 연동 시도했다.

간단하게 동의서 양식을 생성하라고 말하게 되면 처음에는 순조롭게 진행하다가 내가 생각했던 의도대로 가지 않고 다른 해결 방법으로 새어 나갔다. 아무래도 LLM이 판단하는 리소스 또는 도구의 설정값이 부족한 건지 모르겠지만, 아직까지는 아기에게 설명하듯이 상세하게 알려줘야 진행이 되었다.

이런 상황을 최소화하기 위해서 Prompt를 이용하는 것 같아서, MCP에서 제공하는 Prompt를 쓰니까 내가 원하던 진행 방식대로 꽤 잘 돌아갔다. 파일 접근 또는 이전에 생성한 동의서 양식 파일을 가지고 행동 처리하는 과정에서 잘못된 처리 방향으로 가는 이슈가 많아서 이것을 어떻게 해결해야 할지 고민이 필요하다.

소감

LLM 앱이 정말 강해져서 내 서비스와 연동하면 기능이 자연스럽게 확대되는 것 같았다. 예를 들면, 내가 등록한 동의서 양식 목록 조회 API를 만들면 이것을 목록으로 보여주는 UI를 구현해야 하고, 검색 기능을 만들어야 하고, 필터 및 분석 기능을 만들 필요 없이 대화 하나로 다 처리하는 게 신세계였다.

다만, 구현하면서 우려스러운 것은 서비스 기능 특성상 민감한 정보들이 있어 그것을 LLM 앱에게 전달해야 하는데, 이런 건 어떻게 보안적으로 처리해야 할지 걱정이다(현재는 목업 데이터로만 활용 중).