Toss의 MCP 서버 API 연동 자동화로 개발 생산성을 극대화하는 비결

급변하는 IT 환경 속에서 개발 생산성은 기업의 핵심 경쟁력으로 자리 잡았습니다. 특히 수많은 서비스와 시스템이 유기적으로 연결되는 현대 소프트웨어 아키텍처에서 API 연동 자동화는 더 이상 선택이 아닌 필수가 되었죠. 오늘은 국내 핀테크를 선도하는 Toss가 어떻게 사내 MCP(Multi-Channel Platform) 서버를 구축하여 API 연동을 자동화하고 개발 효율성을 극대화했는지, 그 생생한 사례를 깊이 있게 파헤쳐 보겠습니다. 이 글은 Toss Tech의 아티클(https://toss.tech/article/internal-mcp-server)을 참고하여 작성되었습니다.

1. 왜 API 연동 자동화가 필요한가: 복잡성의 시대, 개발 생산성의 위기

IT 전문가로서 오랫동안 현장을 지켜봐 온 저에게, 최근 몇 년간 가장 두드러지는 변화 중 하나는 바로 시스템 복잡성의 증가입니다. 마이크로서비스 아키텍처(MSA)의 확산과 클라우드 기반 인프라의 보편화는 개발의 유연성과 확장성을 가져다주었지만, 동시에 수많은 서비스 간의 API 연동이라는 새로운 숙제를 안겨주었죠.

복잡성의 시대, 개발 생산성의 위기

과거 모놀리식 아키텍처에서는 하나의 거대한 애플리케이션 안에서 모든 기능이 동작했기에, 서비스 간의 연동은 상대적으로 단순했습니다. 하지만 MSA 환경에서는 수십, 수백 개의 마이크로서비스가 독립적으로 배포되고 운영됩니다. 각 서비스는 고유의 API를 가지며, 이들이 서로 데이터를 주고받으며 하나의 거대한 시스템을 이루죠.

이 과정에서 개발자들은 다음과 같은 문제에 직면합니다:

• 반복적인 연동 작업: 새로운 기능 개발 시마다 관련 서비스들의 API를 일일이 확인하고 연동 코드를 작성해야 합니다.
• 다양한 연동 방식: 각 서비스마다 RESTful API, gRPC, 메시지 큐 등 다양한 통신 방식을 사용하면, 이를 모두 이해하고 대응하는 데 많은 노력이 필요합니다.
• 의존성 관리의 어려움: 특정 서비스의 API 변경은 이에 의존하는 다른 서비스들에 연쇄적인 영향을 미 미칠 수 있어, 변경 관리가 복잡해집니다.
• 개발자 온보딩 시간 증가: 새로운 개발자가 팀에 합류했을 때, 방대한 API 문서와 복잡한 연동 구조를 학습하는 데 상당한 시간이 소요됩니다.

실제로 업계 보고서에 따르면, API 통합에 소요되는 시간은 전체 개발 시간의 20~30%에 달하기도 합니다. 이는 곧 엄청난 개발 비용과 생산성 저하로 이어지는 것이죠. 이러한 문제를 해결하지 않고서는 빠르게 변화하는 시장에 대응하기 어렵다는 공감대가 형성되고 있습니다.

MSA와 API

이제 API는 단순한 기술적 인터페이스를 넘어 비즈니스 가치를 창출하는 핵심 요소가 되었습니다. 기업들은 외부 서비스와 연동하여 새로운 가치를 만들고, 내부적으로도 각 팀이 API를 통해 협업하며 시너지를 냅니다.

하지만 이러한 API 경제의 이면에는 복잡한 API 관리 및 연동이라는 그림자가 드리워져 있습니다. 특히 금융과 같은 규제 산업에서는 보안과 안정성까지 고려해야 하므로, API 연동에 대한 부담은 더욱 커질 수밖에 없습니다. 결국, API 연동의 복잡성을 줄이고 자동화하는 것이 개발 생산성을 높이는 핵심 열쇠가 되는 것이죠.

많은 API들이 어디에 어떤 기능들로 구현되어 있고, 이러한 복잡한 API들의 정의를 관리하고, 다양한 Cloud 서비스에서 제공하는 Service Mesh에 관리하기 위해서는 API의 Map이 필요합니다.

이미 오래전부터 API의 구조를 쉽게 이해할 수 있도록, 그리고 개발자가 가장 힘들어하는 문서화 작업을 하지 않아도 API의 설계서를 작성하기 쉽도록 해주는 도구로 Swagger 가 인정을 받았고, 이미 표준으로 지정되어 Open API Specification으로 지위를 인정받았습니다. 사용법도 기존의 많은 legacy code들을 swagger 도구를 통해 문서화할 수 있도록 빠르게 적용할 수 있는 장점도 있습니다.

새로운 기술이라기에는 이미 오래되어 이제는 사람들에게 익숙한 단어로 자리잡고 있는 것 같아요. 저는 microsoft의 공식 사이트에서 .net C#에서 swagger를 활용하는 방법에 대해 소개하는 글을, 기억이 잘 안나지만 10여년 전에 보고 그때부터 사용한 것 같네요.

이제는 많은 서비스들이 API 기반으로 전환되었고, 또 Micro Service Archtecture(MSA)로 국내의 많은 서비스들도 기본으로 생각할 정도로 Cloud 서비스에 대한 인식이 많이 변하였습니다. 이제는 필수가 되었다고 봐야겠죠.

2. Toss의 현명한 선택: 사내 MCP(Model Context Protocol) 서버

국내 핀테크 시장을 선도하는 Toss는 끊임없이 혁신하고 성장해왔습니다. 그 과정에서 Toss 또한 위에서 언급한 시스템 복잡성 문제에 직면하게 되었죠.

Toss의 성장통과 시스템 복잡도

Toss는 송금 서비스를 시작으로 증권, 보험, 대출 등 다양한 금융 서비스로 영역을 확장하며 급성장했습니다. 이 과정에서 필연적으로 수많은 내부 시스템과 외부 연동이 늘어났고, 각 서비스 간의 API 연동 복잡도는 감당하기 어려운 수준에 도달했습니다.

예를 들어, 하나의 신규 금융 상품을 출시하기 위해서는 결제, 정산, 고객 정보, 알림 등 수많은 백오피스 시스템 및 외부 파트너사 API와의 연동이 필수적이었습니다. 각 연동마다 개별적인 개발이 필요했고, 이는 개발 시간 지연과 유지보수 부담 증가로 이어졌습니다. 개발자들이 비즈니스 로직에 집중하기보다는 연동 작업에 더 많은 시간을 할애해야 하는 상황이었죠.

MCP 서버, 그 탄생 배경과 목표

이러한 문제를 해결하기 위해 Toss는 과감한 결정을 내립니다. 바로 사내 MCP(Model Context Protocol) 서버를 구축하는 것이었습니다. MCP 서버는 이름 그대로 다양한 채널(서비스, 시스템)을 하나로 묶어주는 플랫폼 역할을 합니다. Toss의 MCP 서버는 다음과 같은 명확한 목표를 가지고 탄생했습니다.

• API 연동의 표준화 및 추상화: 복잡한 내부 및 외부 API들을 MCP 서버를 통해 일원화된 방식으로 호출할 수 있도록 합니다.
• 개발 생산성 극대화: 개발자들이 반복적인 연동 작업에서 벗어나 핵심 비즈니스 로직 개발에 집중할 수 있도록 돕습니다.
• 안정성과 확장성 확보: 연동 로직의 중앙 집중화를 통해 시스템의 안정성을 높이고, 새로운 서비스 추가 시 유연하게 확장할 수 있는 기반을 마련합니다.
• 개발자 경험(DX) 개선: 직관적인 개발 환경과 풍부한 가이드라인을 제공하여 개발자들이 쉽고 빠르게 API를 활용할 수 있도록 합니다.

Toss의 MCP 서버는 단순히 API를 모아두는 것을 넘어, API 연동의 '자동화'와 '표준화'를 핵심 가치로 삼았습니다.

3. MCP 서버, 기술적으로 무엇이 특별한가?

Toss의 MCP 서버가 어떻게 이러한 목표를 달성했는지, 그 기술적인 접근 방식을 좀 더 자세히 들여다보겠습니다.

API 통합의 허브 역할

MCP 서버는 말 그대로 API 통합의 허브 역할을 수행합니다. 내부의 수십 개 마이크로서비스와 외부 금융 기관, PG사 등 파트너사들의 API를 MCP 서버가 일괄적으로 관리하고 중계합니다. 이는 마치 복잡한 도로망의 교차로와 같습니다. 모든 차량(API 호출)이 교차로(MCP 서버)를 거쳐 목적지로 향하되, 교차로가 교통 흐름을 원활하게 제어하는 것이죠.

이러한 복잡성이 모이는 API 통합 허브의 역할을 적절히 수행하기 위해서는 Swagger를 통한 Open API Specification으로 API 문서화로 MAP을 정리하는 것이 어떤 기업이든 중요한 시점이 되고 있습니다. 또한 이러한 맵을 정리하면 필연적으로 따라오는 보안에 대한 경각심. 기존에는 사내 API를 관리할 때 서로 약속한 Key 값을 생성해서(예: jwt의 token을 생성해서 연동 시 이를 키로 사용하는 고정된 방식) 많이 사용했었습니다. 요즘은 많은 SaaS 서비스가 API Key를 제공하는 방식을 많이 사용하니 많이 써보셨겠지요. 그리고 인증 뿐 아니로 보안 통신 채널의 구성도 중요합니다. 역시나 보안 채널에는 보안 키 발급과 관리, 보안 키를 통한 통신 구간을 암호화 적용하는 방식, 정교한 Key 관리 서버, AWS의 KMS나 오래전부터 사용되던 MS Windows Server의 인증기관 서버를 통한 kerberos 인증이나 보안의 중요성도 상당히 더 높아질 것으로 보입니다. 

표준화와 추상화의 마법

MCP 서버의 가장 큰 강점은 API의 표준화와 추상화입니다. 각기 다른 프로토콜(REST, gRPC, SOAP 등)과 데이터 형식, 인증 방식 등을 가진 API들을 MCP 서버가 한 번 걸러내어, 개발자에게는 통일된 인터페이스를 제공합니다. 개발자는 더 이상 복잡한 연동 방식을 일일이 신경 쓸 필요 없이, MCP 서버가 제공하는 표준화된 API만 호출하면 됩니다.

예를 들어, 특정 금융기관의 계좌 정보를 조회하는 API가 있다고 가정해 봅시다. 이 API는 SOAP 프로토콜을 사용하고 복잡한 XML 요청/응답 형식을 가질 수 있습니다. 하지만 MCP 서버를 통해 이 API를 호출하면, 개발자는 단순히 RESTful API 형태로 간결한 JSON 요청을 보내고 JSON 응답을 받는 식이죠. MCP 서버 내부에서 SOAP 변환 및 XML 파싱 등의 복잡한 로직을 처리해 주는 것입니다. 이러한 추상화는 개발자에게 엄청난 편리함을 제공합니다.

개발자 경험(DX)의 혁신

결국 MCP 서버는 개발자 경험(DX)을 혁신하는 데 초점을 맞추고 있습니다. Toss는 MCP 서버를 통해 다음을 제공했습니다.

• 직관적인 API 문서: 표준화된 API는 문서화가 용이하며, 개발자들은 쉽고 빠르게 필요한 API 정보를 찾을 수 있습니다.
• 자동화된 코드 생성: 일부 MCP 서버는 연동 API를 기반으로 클라이언트 코드를 자동으로 생성해주는 기능도 제공하여, 개발 시간을 더욱 단축시킵니다.
• 테스트 환경 지원: 연동 API에 대한 테스트 환경을 제공하여 개발자들이 실제 서비스에 배포하기 전에 충분히 테스트할 수 있도록 돕습니다.

국내 기업들이 이러한 API MAP을 사내에 구축하고, MCP 서버를 공식화 하는 것이 기업의 보안에 취약해진다고 헛소리들을 떠드는 경우가 꽤 있는데, 편의를 제공하기 위해서는 당연히 ACL(Access control level)을 관리하고, 권한 부여를 위한 신청/발급/해지의 key 관리를 하고, 보안 통신을 강화하는 것이 맞겠죠.

4. API 연동 자동화가 가져온 실질적 변화

Toss의 MCP 서버 구축은 단순히 기술적인 개선을 넘어, 조직 전체의 개발 문화와 비즈니스 성과에 긍정적인 영향을 미쳤습니다.

개발 속도 향상과 비용 절감

가장 눈에 띄는 변화는 개발 속도의 비약적인 향상입니다. 개발자들은 더 이상 복잡한 API 연동 로직에 매달리지 않고, 오직 비즈니스 가치를 창출하는 핵심 기능 개발에만 집중할 수 있게 되었습니다. 이는 신규 서비스 출시 시간을 단축하고, 시장의 변화에 더욱 민첩하게 대응할 수 있도록 했습니다.

또한, 반복적인 연동 작업에 투입되던 인력과 시간을 절감하여 개발 비용 절감 효과도 가져왔습니다. 개발팀의 리소스가 더욱 효율적으로 배분될 수 있었던 것이죠.

안정성과 유지보수의 용이성

API 연동 로직이 MCP 서버로 중앙 집중화되면서, 시스템 전체의 안정성이 크게 향상되었습니다. 각 서비스가 개별적으로 연동 로직을 관리할 때 발생할 수 있는 오류나 비일관성을 줄일 수 있었기 때문입니다. 특정 연동 방식이 변경되더라도, MCP 서버 내부의 로직만 수정하면 되므로 유지보수가 훨씬 용이해졌습니다.

새로운 비즈니스 기회 창출

개발 생산성 향상은 단순히 코드를 빨리 만드는 것을 넘어, 새로운 비즈니스 기회를 창출하는 원동력이 됩니다. 더 적은 리소스로 더 많은 아이디어를 빠르게 구현하고 시장에 선보일 수 있게 되면서, Toss는 핀테크 서비스 영역을 더욱 공격적으로 확장할 수 있었습니다. 기술 부채를 줄이고 혁신에 더 많은 에너지를 쏟을 수 있는 환경이 조성된 것이죠.

5. 구현 과정에서 마주한 도전과 해결 전략

물론, 이러한 성공적인 시스템 구축은 결코 순탄하지만은 않았을 겁니다. Toss 역시 MCP 서버를 구현하는 과정에서 여러 도전 과제에 직면했을 것이고, 이를 현명하게 극복했습니다.

레거시 시스템과의 조화

어느 정도 규모가 있는 기업이라면 레거시 시스템과의 연동은 피할 수 없는 과제입니다. Toss 역시 기존의 시스템들과 MCP 서버를 어떻게 조화롭게 연결할 것인가에 대한 고민이 있었을 것입니다. 이 문제를 해결하기 위해 Toss는 점진적인 전환 전략과 함께, 레거시 시스템의 API를 MCP 서버가 이해할 수 있는 형태로 변환하는 어댑터 패턴과 같은 디자인 패턴을 적극 활용했을 것입니다.

다양한 프로토콜 지원

내부 서비스는 물론, 외부 파트너사들은 각기 다른 통신 프로토콜을 사용합니다. 이를 모두 지원하면서도 표준화된 인터페이스를 제공하는 것은 상당한 기술적 난이도를 요구합니다. Toss는 이를 위해 유연한 플러그인 아키텍처를 설계하여, 새로운 프로토콜이나 연동 방식이 추가될 때마다 손쉽게 확장할 수 있도록 했을 것입니다. 또한, API 게이트웨이와 같은 기술을 활용하여 다양한 프로토콜을 통합 관리했을 가능성이 높습니다.

지속적인 개선과 진화

MCP 서버는 한 번 구축하고 끝나는 시스템이 아닙니다. Toss의 비즈니스가 성장하고 새로운 기술이 등장함에 따라 MCP 서버 역시 지속적으로 개선하고 진화해야 합니다. 이를 위해 Toss는 애자일 개발 방법론을 적용하고, 개발자들의 피드백을 적극적으로 반영하여 MCP 서버의 기능과 성능을 꾸준히 고도화했을 것입니다.

6. Toss 사례에서 배우는 교훈과 우리 기업에의 시사점

Toss의 MCP 서버 구축 사례는 단순한 기술 도입을 넘어, 전략적인 사고와 실행력이 얼마나 중요한지를 보여줍니다. 이 사례에서 우리는 몇 가지 중요한 교훈을 얻을 수 있습니다.

"일단 만들고 보자"가 아닌 "왜 만드는가"

Toss는 API 연동 자동화라는 목표를 설정하기 전에, 현재 겪고 있는 문제점과 이로 인해 발생하는 비즈니스 손실을 명확히 정의했습니다. 그리고 MCP 서버가 이 문제들을 어떻게 해결하고 어떤 가치를 가져다줄 것인지에 대한 확고한 비전이 있었죠. 이는 단순히 유행하는 기술을 쫓는 것이 아니라, 기업의 필요에 따라 최적의 솔루션을 찾아 나서는 '문제 해결 중심'의 접근 방식입니다.

내부 플랫폼 구축의 전략적 가치

많은 기업이 외부 솔루션 도입을 우선적으로 고려하지만, Toss는 내부 플랫폼 구축이라는 어려운 길을 선택했습니다. 이는 Toss의 비즈니스 특성과 성장 속도를 고려했을 때, 자체적인 플랫폼이 장기적으로 더 큰 유연성과 통제력을 제공할 것이라는 전략적 판단이 있었기 때문입니다. 내부 플랫폼은 기업의 핵심 역량을 내재화하고, 미래 성장을 위한 강력한 기반을 마련해 줍니다.

결론: 미래 개발 환경을 위한 필수 인프라

Toss의 사내 MCP 서버 구축 및 API 연동 자동화 사례는 현대 기업이 직면한 개발 생산성 저하 문제를 해결할 수 있는 매우 효과적인 솔루션임을 증명합니다. 복잡한 API 연동을 표준화하고 추상화함으로써, 개발자들은 본연의 업무인 비즈니스 로직 개발에 집중할 수 있게 되었고, 이는 곧 기업의 혁신 속도를 가속화하는 원동력이 되었습니다.

MSA와 API 경제가 더욱 심화될수록, Toss와 같은 내부 플랫폼 전략은 기업의 핵심 경쟁력이 될 것입니다. 여러분의 기업 또한 반복되는 연동 작업과 복잡한 시스템 구조로 개발 생산성에 어려움을 겪고 있다면, Toss의 사례를 참고하여 API 연동 자동화 전략을 고민해 볼 때입니다. 이는 단순히 기술적인 개선을 넘어, 기업의 미래를 위한 전략적 투자가 될 것입니다.

FAQ: 자주 묻는 질문

• Q: MCP 서버는 API 게이트웨이와 어떻게 다른가요?
  A: API 게이트웨이는 주로 외부로 노출되는 API에 대한 인증, 권한 부여, 라우팅, 로깅 등을 담당하는 반면, MCP 서버는 내부 및 외부의 다양한 API를 통합하고 표준화하며, 복잡한 연동 로직을 추상화하여 개발자가 쉽게 사용할 수 있도록 돕는 것에 더 초점을 맞춥니다. MCP 서버는 API 게이트웨이의 기능을 포함하거나, 그 위에 추가적인 비즈니스 로직 및 통합 기능을 제공할 수 있습니다.
• Q: MCP 서버 구축은 어떤 기업에 가장 적합한가요?
  A: Toss처럼 수많은 마이크로서비스를 운영하고 있거나, 다양한 외부 파트너사 및 내부 시스템과 복잡하게 연동해야 하는 기업, 그리고 개발자 생산성 향상과 DX(Developer Experience) 개선에 적극적인 투자를 고려하는 기업에 특히 효과적입니다.
• Q: MCP 서버를 직접 구축하는 것과 상용 솔루션을 사용하는 것 중 어느 것이 더 좋을까요?
  A: 기업의 규모, 내부 개발 역량, 비즈니스 특성, 예산에 따라 다릅니다. Toss처럼 고유한 비즈니스 로직과 빠른 성장이 필요한 경우 직접 구축하여 높은 유연성과 통제력을 확보하는 것이 유리할 수 있습니다. 반면, 초기 투자 비용이나 개발 리소스가 부족하다면 상용 솔루션을 고려해 볼 수도 있습니다. 중요한 것은 '왜 필요한가'에 대한 명확한 이해를 바탕으로 최적의 선택을 하는 것입니다.
• Q: MCP 서버 구축 시 가장 중요하게 고려해야 할 점은 무엇인가요?
  A: 첫째, API 표준화 및 추상화 전략을 명확히 수립해야 합니다. 둘째, 확장성을 고려한 아키텍처 설계가 필수적입니다. 셋째, 개발자들의 피드백을 지속적으로 반영하여 사용성을 개선해야 합니다. 마지막으로, 구축 후에도 지속적인 모니터링과 유지보수 계획을 세우는 것이 중요합니다.

참고자료

• 카카오페이 OpenAPI
• Toss OpenAPI Specification
• Swagger OpenAPI Specification
• Open API 3.0 and OAS