▲

MCP, 분산 시스템에서 얻어진 소중한 교훈을 간과함

 (julsimon.medium.com)
3P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • MCP(Model Context Protocol) 는 AI 도구 통합 표준화를 내세우지만, 40년간 축적된 분산 시스템과 RPC 베스트 프랙티스를 무시하는 문제점이 있음
  • 이로 인해 엔터프라이즈 환경에서는 운영의 신뢰성, 유형 안전성, 보안, 관찰 가능성, 코스트 관리 등 핵심 기능이 결여됨
  • MCP는 필수적인 기능을 외부 라이브러리에 의존할 뿐 아니라, 프로토콜 파편화와 통합 복잡성, 감사·보안 관리 부담을 야기함
  • 분산 추적, 스키마 버전 관리, 서비스 디스커버리, 성능 최적화 등 주요 운영 요구사항이 여전히 부족함
  • MCP의 조기 도입은 AI 붐에 기대어 엔터프라이즈에 심각한 장애, 운영 리스크, 중복 개발, 불필요한 비용 발생으로 이어질 위험이 있음

MCP의 단순함이 초래할 위험

MCP(Model Context Protocol)는 AI 도구 간 통합을 'AI 분야의 USB-C'로 표방하며 도입 장벽을 낮추는 단순함을 강조함. 하지만 이 단순함이 오히려 분산 시스템에서 40년간 축적된 교훈을 무시하고 있어, 실제 운영 환경에서는 치명적인 기능 결함을 초래함. MCP를 현재 도입하는 기업들은 본질적으로 필수적인 RPC 시스템 기능이 빠진 기반 위에 시스템을 쌓고 있는 셈임.

현실과 기대의 위험한 격차

MCP 옹호자들은 이 프로토콜을 프로덕션-ready 인프라로 소개하지만, 실제 설계 철학은 개발편의성에 치우쳐 운영의 견고함이 부족함. 단기간 내 AI 도구를 연결할 수 있지만, 수백만 요청 단위로 실제 비즈니스에서 활용될 때는 치명적인 부실함을 드러냄. AI에 대한 과도한 시장 기대로 건축적 성숙 없이 도입이 앞당겨지고 있으며, 이는 결국 운영 실패로 이어질 위험이 큼.

40년 역사에서 반복되는 실수

  • UNIX RPC(1982년) 에서는 32비트 정수와 같은 이종 시스템 간 데이터 호환을 위해 XDR(External Data Representation) 및 IDL(Interface Definition Language) 을 도입, 빌드타임에 타입 불일치 오류를 검출함
    MCP는 이 경험을 무시하고 스키마 없는 JSON과 비강제적 힌트만 제공함. 런타임에 타입 오류가 발생하며, AI가 잘못된 날짜를 생성하거나, 금융·헬스케어·제조 등 실제 현업에서 치명적 데이터 변환 오류와 품질 문제로 이어질 수 있음

  • CORBA(1991년) 는 여러 언어 간 동일한 인터페이스 보장을 위해 OMG IDL을 사용했음. MCP는 각 언어가 별개로 구현되어, 직렬화 방식과 오류 처리 등에서 언어·라이브러리마다 일관성이 없어 통합의 악몽을 야기함

  • REST(2000년) 는 stateless 구조, 버브(verb) 기반 의미 명확화, 캐시 헤더 등으로 대규모 확장성과 신뢰성을 확보함
    MCP는 stateful/stateless 구분이 모호하고, 캐시·표준 요청 의미 구분·idempotency 지원이 없음. 서버 확장과 리트라이, 로드밸런싱이 극도로 어려움

  • SOAP/WSDL은 강력한 기계 판독 계약, 자동화 가능성, 보안 확장성을 갖춤
    MCP는 단순 JSON 스키마만 제공, 머신리더블 계약, 자동 생성, 유형 안전성, 보안 감사 등 기능이 부재함. OAuth 2.1도 뒤늦게 HTTP 전송에만 추가, stdio는 환경변수에 의존하는 등 보안 통제도 미비함

  • gRPC(2016년) 는 관찰 가능성, 분산 추적, 양방향 스트리밍, 데드라인, 구조적 오류 코드를 내장 제공
    MCP는 Event 형태의 단방향 스트리밍만 지원하며, 복잡한 상호작용 구현에는 비효율적임. 추적 컨텍스트, 데드라인, 오류 분류 등의 필수 요소가 부족함

‘이 라이브러리만 쓰세요’라는 위험

MCP는 치명적 결함 제기 시마다 서드파티 라이브러리 추가(예: mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator)를 답변으로 내세움. 그러나 이는 프로토콜의 핵심 실패 지점임. 주요 기능이 외부에 분산될수록 파편화, 비일관성, 유지보수·보안·연동 책임 분산 문제가 심화됨.
엔터프라이즈에서 수개월 내 표준화·감사·통합 부담이 커지고, 개발자 교육·외부 의존도 역시 비정상적으로 높아짐.

점점 덧대어지는 임시방편 패치

MCP의 2025–03–26 판은 생산 환경에서 뒤늦게 발견한 결함들을 임시 추가해 놓은 패치노트와 다름없음. OAuth, 세션 관리, 툴 속성(annotation), 진행 상태 알림 등은 최초부터 필수였던 기능의 사후 추가에 불과함.
툴 속성 구분 등도 초창기에는 부재, 보안 인증 역시 초기에 불필요하다고 간주됨. 이는 엔터프라이즈 요구사항에 대한 본질적 이해 부족임을 방증함.

디버깅 악몽 및 운영 추적 불가

gRPC 환경에서는 분산 추적, 트레이스 ID로 빠르고 일관된 디버깅 가능
반면 MCP는 요청 간 상관관계 ID 미존재, 로그 포맷 불일치, 자체 구현 요구 등으로 디버깅·오류 추적에 수일 소요
운영·비즈니스 측면에서도 비용 분배 및 사용량 관리(header, 토큰 카운팅, 쿼터 등) 불가.
클라우드 환경에서는 기본적인 기능이 MCP에서는 아예 제공되지 않아, AI 사용 비용과 책임 소재 추적이 거의 불가능함

아직 남아 있는 주요 운영상 문제점

  • 서비스 디스커버리 부재로 가용성·다중 리전 확장·무정지 업데이트가 불가능함
  • 툴 별 스키마 버전 관리 부재로, 도구 업데이트 시 예고 없이 클라이언트 전체가 깨질 위험이 상존
  • 퍼포먼스 한계: JSON 오버헤드, 커넥션 풀링 부재, 이진 프로토콜·압축 등 미흡, 프로세스 단위 통신 방식 등 구식 패턴 반복

엔터프라이즈 적용 시 심각한 위험

AI가 실제 수익·안전·품질 책임 영역(금융, 의료, 제조, 고객지원 등)에 진입하면서, MCP 도입의 위험성이 커짐
오랜 기간 구축한 견고한 통합 패턴을 버리고, 보안·감사·유형 안전성·운영 안정성을 사후 적용으로 임시 보완하는 셈이 됨
시범적 프로토타입 수준에서 "빠르게 만들고 깨지는" 전략은 중요한 서비스에는 치명적 결과를 초래함

개선 방향 및 장기적 요구조건

  • 단기: 프로토콜 내장 수준에서 타입 안전성, 분산 추적(상관관계 ID), 권한 부여, 표준감사 포맷, 도구별 독립적 스키마 버전 관리 필수
  • 운영 측면: 서비스 디스커버리, 연결 풀, 이진 전송, 데드라인, 표준화된 오류·리트라이 정책 등 요구
  • 장기: 양방향 스트리밍, 내장 쿼터·비용 관리, SLA enforcement, 워크플로우 오케스트레이션 등 엔터프라이즈급 기능 필요

결론

MCP의 단순성 지향 설계는 실험적·짧은 주기의 AI 도구 통합에는 적합하지만, 엔터프라이즈급 운영 환경에서는 치명적으로 운용 리스크와 운영 비용으로 이어짐
AI 붐에 편승하여 도입이 앞서가며, 보안·관찰성·운영 안정성 등 필수 기능을 나중에 덧붙이는 임시방편적인 행태가 반복되고 있음
결국, 프로토콜이 방지하고자 했던 파편화와 중복 개발이 오히려 MCP 위에서 재현될 위험
AI 산업은 40년간의 분산 시스템 발전사를 무시하고, 이미 해결된 문제들을 다시 겪을지, 역사에서 배울지의 기로에 있음
이대로라면 실패한 도입, 보안 결함, 운영 악몽이 반복되고, 그 비용은 전적으로 엔터프라이즈가 부담할 것임

▲
GN⁺ 3일전  [-]
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용 토큰이나 툴 호출 스타일 생성 등을 쉽게 해주는 데 있다고 봄

    • 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 사양을 거의 다 유지해야 하고, 오히려 더 복잡해짐

    • 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분 묵념이 필요함. 우리가 살 수도 있었던 세상: 제대로 동작하는 웹 폼 유효성, 마이크로데이터...

답변달기