드디어 1년 만에 MCP의 가치를 깨달았다

MCP라는 단어가 나온 지 1년 정도 됐다. 나는 그동안 실제 사용 사례 측면에서 항상 조금 회의적이었다.

나에게 MCP는 그저 API 자체에 대한 추가 정보가 담긴 API일 뿐이었다.

내 비판은 이렇다. MCP 서버에 포함할 모든 도구를 정의할 수 있을 정도라면, 나는 이미 결정론적 코드를 작성하는 것이 더 신뢰할 수 있는 결과를 준다는 것을 알 만큼 명확한 수준에 있다는 것이다.

하지만 내가 놓치고 있던 건 MCP가 내부 사용자가 아니라 외부 사용자를 위한 것이라는 점이다.

최근 내 경험은 이렇다.

지난 1년간 바이브 코딩을 시작하고 풀스택으로 전환하면서, 내 주된 병목 현상은 데브옵스였다.

데브옵스는 AI(나는 Cursor를 사용 중이다)로 처리하기에 매우 투박한 작업 중 하나다. 단일 코드베이스에 관한 것이 아니라, 깃허브, DNS, SSL, DB, 호스팅, 환경 변수 등 여러 벤더를 연결해서 처리해야 하기 때문이다.

그냥 내가 해야 할 지루한 설정이 너무 많았다. 게다가 벤더마다 UI가 달라서, 보통 이해하고 사용하기 위해 문서를 파고들어야 했다. 몇 달 뒤 새 프로젝트를 시작하면 모든 걸 잊어버린 채로 말이다.

하지만 최근에 (홍보하지는 않겠지만) 한 호스팅 업체의 MCP 서버를 테스트해 봤다.

AI 에이전트를 사용해서 서비스 제공자와 통신하게 했고, 내가 필요한 것을 정확히 자동으로 설정할 수 있었다.

백엔드 서버, 프론트엔드 서버, 둘 다 올바른 곳을 가리키는 환경 변수, DB, 볼륨, 버킷 등등.

그리고 드디어 MCP를 만드는 최적의 시나리오를 이해한 것 같다.

외부 사용자가 비정기적이고 반복적이지 않은 방식으로 서비스를 필요로 할 때다. MCP는 그들의 학습 시간과 마찰을 크게 줄여줄 것이다.

내 상황을 예로 들자면, 내가 만약 그 호스팅 업체의 내부 직원이라면, 아마 이미 내가 뭘 해야 할지 알고 있을 것이고 대부분의 표준 운영 절차를 하드코딩해 뒀을 테니 MCP는 필요 없을 것이다.

하지만 그 호스팅 서비스의 외부 사용자로서, 나는 가끔(새 프로젝트 시작 시) 그들의 서비스를 건드린다. 문서를 읽고 설정을 구성하는 데 시간을 들이는 건 내 시간을 가장 잘 활용하는 방법이 아니다. 이런 경우 MCP는 엄청나게 유용하다. 그래서 설정이 쉽다는 이유로 이 호스팅 업체를 추천할 것 같다.

뭔가 결론을 내야 할 것 같지만, 솔직히 잘 모르겠다. 하지만 이제 비개발자 친구들이 일상 업무에서 클로드 코드 같은 에이전트를 사용하는 걸 보기 시작했으니, 이게 꽤 중요한 변화가 될 거라는 생각은 든다.