처음엔 이 글의 제목만 보고 전형적인 보안 쇼 얘기겠구나 했음. 그런데 읽어보니 정말 통찰력 있다는 생각을 하게 됨. 특히 이 부분이 눈에 띔: MCP는 이런 교훈을 무시하고, 스키마 없는 JSON에 비강제적 힌트를 사용하는데, 타입 검증이 런타임에 이뤄지거나 아예 안 됨. 예를 들어 AI 툴이 ISO-8601 타임스탬프를 기대했는데 유닉스 에폭 값을 받으면, 모델이 제대로 실패하지 않고 아무 날짜나 만들어낼 수 있음. 이런 일이 금융 서비스에서는 거래 AI가 숫자를 잘못 해석해 잘못된 소숫점 정밀도로 거래를 실행할 수 있고, 헬스케어에서는 환자 데이터 타입이 잘못 변환되어 잘못된 약 처방량이 추천될 수 있음. 제조업에서는 센서 데이터가 JSON 직렬화 과정에서 정밀도가 손실되어 품질 관리 문제로 이어질 수 있음. LLM을 매일 다뤄본 입장에선 이런 문제가 실제로 자주 보임. 앞으로 MCP가 들어간 시스템 어딘가에서 대형 사건이 터지고, 사고 기록을 보면 MCP 서버가 이상한 데이터를 내보내고 그걸 LLM이 받아서 엉뚱한 환각 출력을 하고, 그 결과가 연속적으로 더 큰 문제로 이어지는 상황이 그려짐. 인간의 실수, 예외 처리 없는 LLM의 특성(환각 발생), 그리고 스타트업들이 성급하게 새로운 서비스들을 올리는 문화까지 전부 결합하면 새로운 종류의 버그가 생길 수밖에 없음. 그리고 이 문제가 터지면 트위터 유저들이 AGI가 핵 발사 코드를 해킹한다고 끝없이 떠들 텐데, 그 장면도 꽤 흥미로울 것 같음
솔직히 말해 2023년 이전에는 Star Trek에 나오는 기술적 버그나 오류들이 너무 허구 같아서 실제로 그렇게 벌어질 리 없다 생각했음. 그런데 LLM 등장 이후에는 정말 그런 일이 실제로 벌어질 것이 확실하다는 느낌을 받음. LLM 통합이 더 이상 엔지니어링과 무슨 관계가 있는지 모르겠고, 회사 인프라 전체를 외부 제어에 맡기는 게 그다지 합리적인지 의문임. 게다가 재현성 부족 문제까지 고려하면, "어찌어찌 되는 것"이 엔지니어링이라고 할 수 없는 상황임
저자가 말하는 비판이 잘 이해가 되지 않음. MCP는 JSON Schema를 지원해서, 서버 응답이 반드시 그 스키마를 따라야 함. 만약 ISO-8601 타임스탬프를 요구하는 스키마인데 서버가 유닉스 에폭을 보내면, 명백하게 프로토콜 위반임. 글에서 MCP가 JSON Schema를 지원한다고 하면서도 타입-세이프 클라이언트를 생성할 수 없다고 주장하는데, 이미 수많은 JSON Schema 코드 제너레이터가 존재하기 때문에 사실과 다름
이미 PEBKAC(사용자 실수)가 존재하는데, LLM은 이걸 자동화시키는 수준임
의료 분야에서 잘못된 데이터 타입 변환으로 약 처방이 잘못될 수 있다는 지적에 대해, 실제로 의료 테레메트리 일을 하면서 타임스탬프를 올바르게 파싱하는 것이 얼마나 중요한지 절감했음. 아마 유닛 테스트를 처음 쓴 이유도 이 때문이었던 듯함. NTP가 없는 상황도 헤더의 타임스탬프를 다시 계산해 보정했었음. 이런 조치들의 이유는 사고 리뷰나 의료 과실 책임의 문제 때문이었음. 예를 들어, 환자가 심정지 직전 약을 투여받은 시간과 이후에 받은 시간의 차이는 생명을 좌우할 수 있음. 최근 영국 우체국 사례처럼, 데이터 오류 하나에 인생이 망가질 수 있고, 의료 데이터에선 1분 차이가 세상을 뒤집을 수 있음
MCP는 전송과 컨텍스트 관리가 목적임. 즉, 스키마 정의와 검증 같은 합리적인 인터페이스 구현 책임은 사용자에게 있음. 이는 “HTTP가 json 검증을 지원하지 않는다”는 비판과 비슷함—당연한 얘기임
MCP가 ‘AI 세계의 USB-C’가 되겠다고 하지만, 아이러니하게도 이건 MCP의 성취라기보다는 USB-C의 문제점을 보여주는 사례임. USB-C는 거의 모든 걸 연결할 수 있지만 표준 준수가 엉망이라 MCP의 일관성 없는 JSON 파싱이나 프로토콜 미준수랑 똑같음. 여러 종류의 USB-C 케이블이 있는 현실처럼, 겉으로는 범용성 있어 보여도 실제론 아주 복잡한 현실이 가려져 있음. 차라리 명확히 분리된 API나 프로토콜이 더 나음이라고 생각함
USB-C의 실패가 극단적으로 드러난 예는 Apple이 최신 M4 Mac mini에서 USB-A 포트를 없애면서 시작됨. 똑같이 생긴 포트가 실제로는 완전히 다른 성능을 내고, 사용자는 제품 발표 때와는 다르게 뒤늦게야 알게 됨. 예전엔 Apple Silicon 데스크톱/랩탑에 있는 USB-C는 모두 40Gbps 썬더볼트로 기대할 수 있었으나, 이제 일부는 USB3 10Gbps임. 어느 포트가 그건지 직접 사양서를 살펴보거나 작은 아이콘을 봐야 알 수 있음. 차라리 USB-A 포트를 몇 개 남겨두면 10Gbps 한계를 명확히 보여줄 텐데, 오히려 USB-C 브랜드 가치만 더 희석시켰음. 결국 대부분의 USB-C 장치조차 어댑터를 써서 USB-A로 연결하고, USB-C 버전은 비싸고 드물 뿐더러 오히려 품질이 안 좋음. 하지만 hype와 팬덤이 실용성과 사용성을 능가하는 세상임
솔직히 그 라인(USB-C=범용성 있지만 실상 불투명) 보고 크게 웃었음. 목표 달성, 뭐 그런 셈임
SOAP에 대해 “장황하긴 하지만 MCP가 모르는 무언가를 이해했다”는 평이 있는데, 현실은 SOAP 자체도 그닥 이해된 건 없었음. 사실 레거시 SOAP 시스템 유지보수 중인데, SOAP에 대해 좋게 말해줄 건 하나도 없음. 누구한테도 롤모델이 될 수 없는 존재라고 봄
실제로 SOAP는 엄청난 참사였음. 단순해야 할 개념을 어떻게 저렇게 복잡하게 만들었나 신기함. XML도 복잡했고, WSDL이나 다중 HTTP 파트 등 정의가 불분명한 기준, 다른 언어와의 상호운용성 미보장(예: .NET 서버와 자바 클라이언트의 SOAP 사용 경험 등)까지. 유행이 좀 지나면 사람들은 좋은 부분만 기억하려 하지만, 자신은 차라리 한달 동안 SOAP 쓸 바에는 50년 동안 스키마 없는 JSON API 작업을 선택할 것임. 개인적으로 protobuf랑 capnp가 훨씬 낫다고 생각하는 사람임
REST(실제로는 JSON-RPC)나 GraphQL이 여전히 SOAP와 SOA가 제공하던 기능을 따라잡으려 노력하고 있다고 봄. 새로운 기술이 나올 때마다 좋은 부분까지 다 버리는 현실이 아쉬움
‘Simple’이라는 단어가 들어간 프로토콜은 항상 단순하지 않았음. 이제 곧 SMCP 같은 프로토콜을 볼 것 같은 예감임
아주 재미있으면서 정확한 SOAP 설명 링크가 있어서 공유함 https://harmful.cat-v.org/software/xml/soap/simple. 자신은 XML 기반 기술을 좋아하는 편이고, 특히 XML Schema의 타입 조합과 검증 능력은 여전히 독보적이라고 생각함. 하지만 SOAP는 괜히 거대한 괴물이 된 느낌임. 단순한 원격 호출 사양이 필요했을 뿐인데, 모든 걸 다 정의하면서 어떤 것도 제대로 처리하지 못하는 사양이 되어버림. SOAP는 다양한 전송 프로토콜 지원(SOAP over email까지), 여러 종류의 RPC, UDDI 등 셀프 기술 RPC까지 모든 걸 지원한다고 하지만, 실제론 인증, 캐싱, HTTP 응답 코드 등 핵심 구현은 사용자 몫이었음
아이러니하게 SOAP를 영원히 거부하게 만든 건 당시 들은 SOAP 기술 발표였음. 동일한 언어 간에는 그럭저럭 잘 됐지만, 언어가 다르면 최악이었음. Microsoft가 SOAP를 그렇게 좋아한 이유도 여기 있다고 봄
CORBA가 1991년에 “이기종 환경에서는 단순히 각 언어마다 프로토콜만 구현해서는 안 된다”는 통찰을 갖고 등장했고, OMG IDL이 여러 언어에서 동일한 바인딩을 생성해 인터페이스 일관성과 직렬화 문제를 예방했다는 점은 맞음. 하지만, 정말 성공한 사례였냐는 데는 의문이 듦
지금의 JSON 중심 API 환경은 CORBA와 SOAP의 실패에 대한 반작용으로 나타난 것임. CORBA의 교훈을 못 잊었다기보다는 의도적으로 거부했다고 볼 수 있음
직접 CORBA를 굉장히 잘 활용했던 곳에서 일해봤음. 아마 성공적이었던 이유는 팀 내에 CORBA 개발 경험이 풍부한 시니어 엔지니어가 있어서였다고 생각함
1998년 AT&T의 CORBA 사용하는 직장에 지원했다가, 그때가 마지막 경험이었음(그리고 그 이후엔 JDK 다운로드를 느리게 하는 것 외엔 본 적 없음). 당시 면접관이 내가 쓴 동시성 코드가 마음에 안 든다고 했고, 대안엔 경쟁 조건이 있는데도 설득을 못했음. 이후 실제로는 Java Memory Model의 문제로 내 답이 오히려 맞았다는 결론이 남
CORBA는 여러 가지를 잘했지만, 80년대 말 전통 텔레콤 네트워크와 OOP 열풍의 산물이었음. 그래서 네트워크가 투명하고, 신뢰할 수 있고, 대칭적이라는 근본 가정을 박아 놓았음. 실제 현실에선 타임아웃, 재시도, 네트워크 혼잡, 시스템 크래시 등으로 전혀 그렇지 않은데. 특히 CORBA C++ 바인딩은 STL 등장 전이라 끔찍할 정도였고, 타 언어 쪽이 오히려 나았음
기술적으로 훌륭하지만 상업적으로 실패한 프로젝트에서도 그 뛰어남을 충분히 인정해줄 수 있음
MCP 논의에서 놓치고 있는, ‘MCP가 제대로 배운 핵심 교훈’은 오히려 모든 고급 기능이 복잡성을 초래해서 대부분의 현장에선 단순한 것을 선택하게 만든다는 점임. 그래서 JSON over HTTP가 대세가 된 이유임. 대형 테크 기업에서도 gRPC 같은 고기능 직렬화 프로토콜로 이주하는 게 수년 걸리고, 중간에 여러 번 실패할 수 있음. MCP의 진짜 역할은 단순한 JSON API 계약을 표준화해서, LLM용 토큰이나 툴 호출 스타일 생성 등을 쉽게 해주는 데 있다고 봄
HTTP blobs가 무엇인지 궁금함. 결국 JSON이 XML을 이긴 이유를 말하고 싶었던 것 같음
MCP는 완벽하진 않지만, 수십 년간의 RPC 역사에서 복잡성이 도입과 활용을 가장 어렵게 만든다는 교훈만큼은 제대로 배운 것임(XML 대비 JSON의 부상과 유사). SOAP는 시스템 간의 상호운용성을 위해 지나치게 복잡하고, XML과 스키마도 너무 장황함. CORBA는 라이브러리와 프레임워크가 복잡해서 당시 최신 언어에서는 기피 대상이었음. gRPC는 속도는 빠르지만 가독성 떨어지고 매핑 필요함. 요즘 RPC의 뼈대는 REST와 JSON임. 위에서 언급한 표준들은 밀려나거나, gRPC만이 극한의 고성능 요구에 한정되어 남았음. REST와 JSON이 주요 흐름이 된 배경엔 이런 단순함의 승리가 있고, MCP도 이 흐름에 맞게 설계된 결과물임
좋은 의견 많았음. 우리는 MCP를 오해하고 있는 것 같음. 더 중요한 건 산업 전반에서 agent가 무엇이고 앞으로 어디로 갈지에 대한 오해와 방향 불일치임. 많은 웹 플랫폼들이 에이전트가 네트워크 분산 인프라에 박히게 된다고 믿고 있어서, 컨테이너 내 모든 agent들이 서비스 메시로 MCP에 붙도록 만드는 걸 목표로 삼고 있음. 나의 생각은, 이렇게 웹 중심으로 ‘웹 네이티브 agent 및 SDK/프레임워크가 서버 애플리케이션처럼 배치되어야 한다’고 주장하는 건 잘못됐고, 그런 것들은 agent가 아니며, 진화 단계에서도 초창기 형태조차 아님. 진짜 agent 하네스는 Frontier labs 등 소수 제공자만 만들 수 있고, 점점 개인화(예: 내 데스크탑에 Claude Desktop용 MCP 서버 한 대)로 갈 것임. MCP 서버는 원래 이런 싱글 인스턴스 및 하네스용임
MCP의 문제는 엔터프라이즈에 부적합하게 설계된 게 아니라, LLM을 잘못된 곳에 쓰는 것이 더 큼. 예를 들면 금융 서비스에서 AI가 소숫점 정밀도 오류로 거래를 실행한다는 것 자체가, 프로토콜 문제가 아니라 아무 제약 없는 LLM에게 거래를 맡긴 게 문제임. 또 LLM이 날짜 포맷을 오해해 환각 값을 뱉어내는 상황도, 그런 critical한 환경에 LLM을 투입하는 게 문제임
누군가 MCP가 왜 Swagger나 proto 대신 필요한지 명확하게 설명해줬으면 좋겠음
OpenAPI(Swagger)나 Proto(protobuf)는 각각 MCP의 역할을 모두 포괄하지 못함. 이론적으로 이 위에 MCP를 얹는 것도 가능했지만, MCP의 로컬 사용 사례엔 Swagger의 통신 방식 가정이 안 맞고, protobuf는 원래 통신 프로토콜을 포함하지 않으므로 추가 설계가 필요함. JSON-RPC를 대체하더라도 결국 MCP 사양을 거의 다 유지해야 하고, 오히려 더 복잡해짐
OpenAI에서 지난달 API 사용으로 $50,000가 청구됐다고 할 때, 어떤 부서의 MCP 툴이 그 비용을 유발했는지, 어떤 개별 툴 호출이나 사용자, 사용 사례가 있었는지 분간할 수 없는 상황임. AI 기술 대부분이 뒤늦게 문제를 따라잡는 형국임. 하지만 웹 프레임워크, 블록체인 등과 마찬가지로, 기술이 너무 크면 초기에 완벽히 다 알 수 없음. 격차도 결국 서서히 줄어듦. AI에서도 계속해서 아이디어와 경각심을 공유해야 한다는 데 동의함. 요즘은 정말 흥미로운 시대임
더 나은 설계와 충분히 괜찮은 설계 중 선택 상황이 오면 항상 "충분히 괜찮은" 쪽이 이긴다고 생각함. Multics vs Unix, xml 기반 SOAP vs json 기반 REST, xhtml의 실패, 자바스크립트 자체 등 계속 예를 들 수 있음. 그래서 인간은 매번 "충분히 괜찮은" 걸 재구현하며, 문제가 드러나면 임시방편으로 땜질만 하며 살아가는 운명이라고 각오했음
Hacker News 의견
처음엔 이 글의 제목만 보고 전형적인 보안 쇼 얘기겠구나 했음. 그런데 읽어보니 정말 통찰력 있다는 생각을 하게 됨. 특히 이 부분이 눈에 띔: MCP는 이런 교훈을 무시하고, 스키마 없는 JSON에 비강제적 힌트를 사용하는데, 타입 검증이 런타임에 이뤄지거나 아예 안 됨. 예를 들어 AI 툴이 ISO-8601 타임스탬프를 기대했는데 유닉스 에폭 값을 받으면, 모델이 제대로 실패하지 않고 아무 날짜나 만들어낼 수 있음. 이런 일이 금융 서비스에서는 거래 AI가 숫자를 잘못 해석해 잘못된 소숫점 정밀도로 거래를 실행할 수 있고, 헬스케어에서는 환자 데이터 타입이 잘못 변환되어 잘못된 약 처방량이 추천될 수 있음. 제조업에서는 센서 데이터가 JSON 직렬화 과정에서 정밀도가 손실되어 품질 관리 문제로 이어질 수 있음. LLM을 매일 다뤄본 입장에선 이런 문제가 실제로 자주 보임. 앞으로 MCP가 들어간 시스템 어딘가에서 대형 사건이 터지고, 사고 기록을 보면 MCP 서버가 이상한 데이터를 내보내고 그걸 LLM이 받아서 엉뚱한 환각 출력을 하고, 그 결과가 연속적으로 더 큰 문제로 이어지는 상황이 그려짐. 인간의 실수, 예외 처리 없는 LLM의 특성(환각 발생), 그리고 스타트업들이 성급하게 새로운 서비스들을 올리는 문화까지 전부 결합하면 새로운 종류의 버그가 생길 수밖에 없음. 그리고 이 문제가 터지면 트위터 유저들이 AGI가 핵 발사 코드를 해킹한다고 끝없이 떠들 텐데, 그 장면도 꽤 흥미로울 것 같음
솔직히 말해 2023년 이전에는 Star Trek에 나오는 기술적 버그나 오류들이 너무 허구 같아서 실제로 그렇게 벌어질 리 없다 생각했음. 그런데 LLM 등장 이후에는 정말 그런 일이 실제로 벌어질 것이 확실하다는 느낌을 받음. LLM 통합이 더 이상 엔지니어링과 무슨 관계가 있는지 모르겠고, 회사 인프라 전체를 외부 제어에 맡기는 게 그다지 합리적인지 의문임. 게다가 재현성 부족 문제까지 고려하면, "어찌어찌 되는 것"이 엔지니어링이라고 할 수 없는 상황임
저자가 말하는 비판이 잘 이해가 되지 않음. MCP는 JSON Schema를 지원해서, 서버 응답이 반드시 그 스키마를 따라야 함. 만약 ISO-8601 타임스탬프를 요구하는 스키마인데 서버가 유닉스 에폭을 보내면, 명백하게 프로토콜 위반임. 글에서 MCP가 JSON Schema를 지원한다고 하면서도 타입-세이프 클라이언트를 생성할 수 없다고 주장하는데, 이미 수많은 JSON Schema 코드 제너레이터가 존재하기 때문에 사실과 다름
이미 PEBKAC(사용자 실수)가 존재하는데, LLM은 이걸 자동화시키는 수준임
의료 분야에서 잘못된 데이터 타입 변환으로 약 처방이 잘못될 수 있다는 지적에 대해, 실제로 의료 테레메트리 일을 하면서 타임스탬프를 올바르게 파싱하는 것이 얼마나 중요한지 절감했음. 아마 유닛 테스트를 처음 쓴 이유도 이 때문이었던 듯함. NTP가 없는 상황도 헤더의 타임스탬프를 다시 계산해 보정했었음. 이런 조치들의 이유는 사고 리뷰나 의료 과실 책임의 문제 때문이었음. 예를 들어, 환자가 심정지 직전 약을 투여받은 시간과 이후에 받은 시간의 차이는 생명을 좌우할 수 있음. 최근 영국 우체국 사례처럼, 데이터 오류 하나에 인생이 망가질 수 있고, 의료 데이터에선 1분 차이가 세상을 뒤집을 수 있음
MCP는 전송과 컨텍스트 관리가 목적임. 즉, 스키마 정의와 검증 같은 합리적인 인터페이스 구현 책임은 사용자에게 있음. 이는 “HTTP가 json 검증을 지원하지 않는다”는 비판과 비슷함—당연한 얘기임
MCP가 ‘AI 세계의 USB-C’가 되겠다고 하지만, 아이러니하게도 이건 MCP의 성취라기보다는 USB-C의 문제점을 보여주는 사례임. USB-C는 거의 모든 걸 연결할 수 있지만 표준 준수가 엉망이라 MCP의 일관성 없는 JSON 파싱이나 프로토콜 미준수랑 똑같음. 여러 종류의 USB-C 케이블이 있는 현실처럼, 겉으로는 범용성 있어 보여도 실제론 아주 복잡한 현실이 가려져 있음. 차라리 명확히 분리된 API나 프로토콜이 더 나음이라고 생각함
USB-C의 실패가 극단적으로 드러난 예는 Apple이 최신 M4 Mac mini에서 USB-A 포트를 없애면서 시작됨. 똑같이 생긴 포트가 실제로는 완전히 다른 성능을 내고, 사용자는 제품 발표 때와는 다르게 뒤늦게야 알게 됨. 예전엔 Apple Silicon 데스크톱/랩탑에 있는 USB-C는 모두 40Gbps 썬더볼트로 기대할 수 있었으나, 이제 일부는 USB3 10Gbps임. 어느 포트가 그건지 직접 사양서를 살펴보거나 작은 아이콘을 봐야 알 수 있음. 차라리 USB-A 포트를 몇 개 남겨두면 10Gbps 한계를 명확히 보여줄 텐데, 오히려 USB-C 브랜드 가치만 더 희석시켰음. 결국 대부분의 USB-C 장치조차 어댑터를 써서 USB-A로 연결하고, USB-C 버전은 비싸고 드물 뿐더러 오히려 품질이 안 좋음. 하지만 hype와 팬덤이 실용성과 사용성을 능가하는 세상임
솔직히 그 라인(USB-C=범용성 있지만 실상 불투명) 보고 크게 웃었음. 목표 달성, 뭐 그런 셈임
SOAP에 대해 “장황하긴 하지만 MCP가 모르는 무언가를 이해했다”는 평이 있는데, 현실은 SOAP 자체도 그닥 이해된 건 없었음. 사실 레거시 SOAP 시스템 유지보수 중인데, SOAP에 대해 좋게 말해줄 건 하나도 없음. 누구한테도 롤모델이 될 수 없는 존재라고 봄
실제로 SOAP는 엄청난 참사였음. 단순해야 할 개념을 어떻게 저렇게 복잡하게 만들었나 신기함. XML도 복잡했고, WSDL이나 다중 HTTP 파트 등 정의가 불분명한 기준, 다른 언어와의 상호운용성 미보장(예: .NET 서버와 자바 클라이언트의 SOAP 사용 경험 등)까지. 유행이 좀 지나면 사람들은 좋은 부분만 기억하려 하지만, 자신은 차라리 한달 동안 SOAP 쓸 바에는 50년 동안 스키마 없는 JSON API 작업을 선택할 것임. 개인적으로 protobuf랑 capnp가 훨씬 낫다고 생각하는 사람임
REST(실제로는 JSON-RPC)나 GraphQL이 여전히 SOAP와 SOA가 제공하던 기능을 따라잡으려 노력하고 있다고 봄. 새로운 기술이 나올 때마다 좋은 부분까지 다 버리는 현실이 아쉬움
‘Simple’이라는 단어가 들어간 프로토콜은 항상 단순하지 않았음. 이제 곧 SMCP 같은 프로토콜을 볼 것 같은 예감임
아주 재미있으면서 정확한 SOAP 설명 링크가 있어서 공유함 https://harmful.cat-v.org/software/xml/soap/simple. 자신은 XML 기반 기술을 좋아하는 편이고, 특히 XML Schema의 타입 조합과 검증 능력은 여전히 독보적이라고 생각함. 하지만 SOAP는 괜히 거대한 괴물이 된 느낌임. 단순한 원격 호출 사양이 필요했을 뿐인데, 모든 걸 다 정의하면서 어떤 것도 제대로 처리하지 못하는 사양이 되어버림. SOAP는 다양한 전송 프로토콜 지원(SOAP over email까지), 여러 종류의 RPC, UDDI 등 셀프 기술 RPC까지 모든 걸 지원한다고 하지만, 실제론 인증, 캐싱, HTTP 응답 코드 등 핵심 구현은 사용자 몫이었음
아이러니하게 SOAP를 영원히 거부하게 만든 건 당시 들은 SOAP 기술 발표였음. 동일한 언어 간에는 그럭저럭 잘 됐지만, 언어가 다르면 최악이었음. Microsoft가 SOAP를 그렇게 좋아한 이유도 여기 있다고 봄
CORBA가 1991년에 “이기종 환경에서는 단순히 각 언어마다 프로토콜만 구현해서는 안 된다”는 통찰을 갖고 등장했고, OMG IDL이 여러 언어에서 동일한 바인딩을 생성해 인터페이스 일관성과 직렬화 문제를 예방했다는 점은 맞음. 하지만, 정말 성공한 사례였냐는 데는 의문이 듦
지금의 JSON 중심 API 환경은 CORBA와 SOAP의 실패에 대한 반작용으로 나타난 것임. CORBA의 교훈을 못 잊었다기보다는 의도적으로 거부했다고 볼 수 있음
직접 CORBA를 굉장히 잘 활용했던 곳에서 일해봤음. 아마 성공적이었던 이유는 팀 내에 CORBA 개발 경험이 풍부한 시니어 엔지니어가 있어서였다고 생각함
1998년 AT&T의 CORBA 사용하는 직장에 지원했다가, 그때가 마지막 경험이었음(그리고 그 이후엔 JDK 다운로드를 느리게 하는 것 외엔 본 적 없음). 당시 면접관이 내가 쓴 동시성 코드가 마음에 안 든다고 했고, 대안엔 경쟁 조건이 있는데도 설득을 못했음. 이후 실제로는 Java Memory Model의 문제로 내 답이 오히려 맞았다는 결론이 남
CORBA는 여러 가지를 잘했지만, 80년대 말 전통 텔레콤 네트워크와 OOP 열풍의 산물이었음. 그래서 네트워크가 투명하고, 신뢰할 수 있고, 대칭적이라는 근본 가정을 박아 놓았음. 실제 현실에선 타임아웃, 재시도, 네트워크 혼잡, 시스템 크래시 등으로 전혀 그렇지 않은데. 특히 CORBA C++ 바인딩은 STL 등장 전이라 끔찍할 정도였고, 타 언어 쪽이 오히려 나았음
기술적으로 훌륭하지만 상업적으로 실패한 프로젝트에서도 그 뛰어남을 충분히 인정해줄 수 있음
MCP 논의에서 놓치고 있는, ‘MCP가 제대로 배운 핵심 교훈’은 오히려 모든 고급 기능이 복잡성을 초래해서 대부분의 현장에선 단순한 것을 선택하게 만든다는 점임. 그래서 JSON over HTTP가 대세가 된 이유임. 대형 테크 기업에서도 gRPC 같은 고기능 직렬화 프로토콜로 이주하는 게 수년 걸리고, 중간에 여러 번 실패할 수 있음. MCP의 진짜 역할은 단순한 JSON API 계약을 표준화해서, LLM용 토큰이나 툴 호출 스타일 생성 등을 쉽게 해주는 데 있다고 봄
MCP는 완벽하진 않지만, 수십 년간의 RPC 역사에서 복잡성이 도입과 활용을 가장 어렵게 만든다는 교훈만큼은 제대로 배운 것임(XML 대비 JSON의 부상과 유사). SOAP는 시스템 간의 상호운용성을 위해 지나치게 복잡하고, XML과 스키마도 너무 장황함. CORBA는 라이브러리와 프레임워크가 복잡해서 당시 최신 언어에서는 기피 대상이었음. gRPC는 속도는 빠르지만 가독성 떨어지고 매핑 필요함. 요즘 RPC의 뼈대는 REST와 JSON임. 위에서 언급한 표준들은 밀려나거나, gRPC만이 극한의 고성능 요구에 한정되어 남았음. REST와 JSON이 주요 흐름이 된 배경엔 이런 단순함의 승리가 있고, MCP도 이 흐름에 맞게 설계된 결과물임
좋은 의견 많았음. 우리는 MCP를 오해하고 있는 것 같음. 더 중요한 건 산업 전반에서 agent가 무엇이고 앞으로 어디로 갈지에 대한 오해와 방향 불일치임. 많은 웹 플랫폼들이 에이전트가 네트워크 분산 인프라에 박히게 된다고 믿고 있어서, 컨테이너 내 모든 agent들이 서비스 메시로 MCP에 붙도록 만드는 걸 목표로 삼고 있음. 나의 생각은, 이렇게 웹 중심으로 ‘웹 네이티브 agent 및 SDK/프레임워크가 서버 애플리케이션처럼 배치되어야 한다’고 주장하는 건 잘못됐고, 그런 것들은 agent가 아니며, 진화 단계에서도 초창기 형태조차 아님. 진짜 agent 하네스는 Frontier labs 등 소수 제공자만 만들 수 있고, 점점 개인화(예: 내 데스크탑에 Claude Desktop용 MCP 서버 한 대)로 갈 것임. MCP 서버는 원래 이런 싱글 인스턴스 및 하네스용임
누군가 MCP가 왜 Swagger나 proto 대신 필요한지 명확하게 설명해줬으면 좋겠음
OpenAPI(Swagger)나 Proto(protobuf)는 각각 MCP의 역할을 모두 포괄하지 못함. 이론적으로 이 위에 MCP를 얹는 것도 가능했지만, MCP의 로컬 사용 사례엔 Swagger의 통신 방식 가정이 안 맞고, protobuf는 원래 통신 프로토콜을 포함하지 않으므로 추가 설계가 필요함. JSON-RPC를 대체하더라도 결국 MCP 사양을 거의 다 유지해야 하고, 오히려 더 복잡해짐
MCP는 새로운 기술임
MCP는 스트리밍 응답을 지원함. 폴링이나 세션 state로 구현할 수도 있겠지만, 그건 비효율적인 꼼수임
OpenAI에서 지난달 API 사용으로 $50,000가 청구됐다고 할 때, 어떤 부서의 MCP 툴이 그 비용을 유발했는지, 어떤 개별 툴 호출이나 사용자, 사용 사례가 있었는지 분간할 수 없는 상황임. AI 기술 대부분이 뒤늦게 문제를 따라잡는 형국임. 하지만 웹 프레임워크, 블록체인 등과 마찬가지로, 기술이 너무 크면 초기에 완벽히 다 알 수 없음. 격차도 결국 서서히 줄어듦. AI에서도 계속해서 아이디어와 경각심을 공유해야 한다는 데 동의함. 요즘은 정말 흥미로운 시대임
더 나은 설계와 충분히 괜찮은 설계 중 선택 상황이 오면 항상 "충분히 괜찮은" 쪽이 이긴다고 생각함. Multics vs Unix, xml 기반 SOAP vs json 기반 REST, xhtml의 실패, 자바스크립트 자체 등 계속 예를 들 수 있음. 그래서 인간은 매번 "충분히 괜찮은" 걸 재구현하며, 문제가 드러나면 임시방편으로 땜질만 하며 살아가는 운명이라고 각오했음
이건 익히 알려진 Worse is Better 현상의 반복임 (https://en.m.wikipedia.org/wiki/Worse_is_better). 시간이 지나도 여러 번 입증됐음. 나도 늘 “더 나은” 솔루션에 끌리는 성향이지만 현실이 항상 그렇진 않음
xforms 2.0을 위한 1분 묵념이 필요함. 우리가 살 수도 있었던 세상: 제대로 동작하는 웹 폼 유효성, 마이크로데이터...