설계자가 다르면 중력도 다르다
도구를 고른다는 건 단순히 기능 목록을 비교하는 행위가 아니다. 그 도구가 어떤 방향으로 진화할지, 누가 그 방향을 결정할지, 그리고 그 결정이 나의 코드베이스와 팀의 선택지를 어떻게 좁혀갈지를 함께 선택하는 일이다. 최근 두 가지 사건이 이 질문을 다시 수면 위로 끌어올렸다.
React 거버넌스: "오픈소스"라는 이름의 독점 구조
dev.to에 게재된 글 "React lost the mass and Vercel is wearing its skin"은 불편한 사실을 직접적으로 짚는다. React 코어 팀의 상당수가 Vercel 소속이다. 이것 자체가 문제는 아니다. 문제는 그 구조가 React의 로드맵을 특정 기업의 비즈니스 모델과 정렬시키는 방향으로 작동한다는 점이다.
Server Components와 App Router는 커뮤니티의 수요에서 올라온 기능이 아니었다. 서버 중심 아키텍처를 전제하고, 셀프 호스팅은 이론상 가능하지만 현실적으로 불편하며, Next.js 위에서 가장 자연스럽게 작동하도록 설계되어 있다. 공식 문서조차 점점 Next.js를 기본 경로로 가정한다. MIT 라이선스라는 사실은 변하지 않지만, 거버넌스의 무게중심은 이미 기울어져 있다.
핵심 비판은 이것이다. "모두에게 이롭다"는 주장과 "주로 한 회사에 이롭다"는 사실은 동시에 참일 수 있다. Svelte, SolidJS, Vue는 코어 라이브러리와 배포 레이어 사이에 명확한 경계를 유지해왔다. React는 그 경계를 허물었고, 이제 개발자들은 묻기 시작했다. 이 프레임워크는 누구를 위해 설계된 것인가?
MCP 서버: 신뢰의 인프라를 IDE 안으로 끌어오다
한편 Correctover는 MCP(Model Context Protocol) 서버를 공식 레지스트리에 등록하며 전혀 다른 방향의 신호를 보낸다. VS Code 1.102+, Cursor, Claude Desktop에서 correctover를 MCP 설정에 추가하면, AI 어시스턴트가 LLM API 응답의 계약 조건을 실시간으로 검증할 수 있다.
이 도구가 흥미로운 이유는 기능 자체보다 그것이 다루는 문제의 성격에 있다. LLM 기반 워크플로우에서 가장 조용하고 위험한 실패는 명시적 에러가 아니다. GPT-4o를 요청했는데 GPT-4o-mini가 응답하는 모델 치환, 구조화 출력에서 필수 필드가 사라지는 스키마 드리프트, 응답은 정상처럼 보이지만 의미적으로 틀린 세맨틱 품질 저하—이런 실패들은 기존의 페일오버 메커니즘이 감지하지 못한다. 페일오버는 "응답이 왔는가"를 확인하지만, Correctover는 "그 응답이 올바른가"를 묻는다.
CANON 엔진이 수행하는 6차원 계약 검증(구조, 스키마, 레이턴시, 비용, 모델 신원, 무결성)은 P50 기준 22μs 안에 완료된다. BYOK(Bring Your Own Key) 방식으로 미들맨 없이 직접 프로바이더에 연결되며, 개발자가 직접 API 키를 관리한다. 도구가 데이터를 보유하거나 토큰을 재판매하지 않는다는 명시적 설계 원칙이다.
두 이슈가 만나는 지점: 신뢰의 구조 설계
표면적으로 두 이슈는 달라 보인다. 하나는 오픈소스 거버넌스 문제이고, 다른 하나는 LLM 신뢰성 검증 도구다. 그러나 둘 다 같은 질문 위에 서 있다. 이 도구의 신뢰성은 누가, 어떤 구조로 보장하는가?
React-Vercel 구조에서 개발자들이 느끼는 불안은 단순한 벤더 종속 공포가 아니다. 프레임워크의 진화 방향을 예측할 수 없다는 것, 그 방향이 내 문제보다 누군가의 인프라 매출과 더 강하게 정렬되어 있을 수 있다는 것이다. 마찬가지로 LLM API를 사용하는 파이프라인에서 개발자들이 진짜 두려워하는 것은 장애보다 조용한 품질 저하다. 눈에 보이지 않는 실패가 프로덕션에 스며드는 구조.
MCP라는 레이어가 중요해지는 이유도 여기에 있다. IDE 내부에서 AI 어시스턴트와 외부 도구 사이의 프로토콜이 표준화될수록, 그 프로토콜 위에 어떤 신뢰 검증 도구가 올라오는지가 개발자 경험의 안전망이 된다. Correctover가 공식 MCP 레지스트리에 진입했다는 사실은 단순한 도구 출시가 아니라, AI 워크플로우 신뢰성 검증이 IDE 인프라 레이어로 편입되기 시작했다는 신호다.
프론트엔드 개발자에게 실제로 의미하는 것
두 이슈를 실무 관점에서 정리하면 선택의 체크리스트가 달라진다.
프레임워크를 고를 때: "이 기능이 누구의 인프라를 전제하는가"를 로드맵과 함께 읽어야 한다. React를 쓰지 말라는 게 아니다. 하지만 App Router를 채택할 때 셀프 호스팅 복잡도와 Next.js 종속성을 명시적 트레이드오프로 팀 안에서 다뤄야 한다. 거버넌스 구조가 불투명한 프레임워크일수록, 마이그레이션 비용은 조용히 쌓인다.
AI 도구를 워크플로우에 통합할 때: 도구가 단순히 "잘 작동하는가"가 아니라 "잘못 작동할 때 누가 어떻게 감지하는가"를 설계해야 한다. LLM 파이프라인에서 페일오버는 필요조건이지 충분조건이 아니다. 응답의 계약 준수 여부를 검증하는 레이어, 즉 Correctover가 다루는 영역이 없으면 AI 어시스턴트의 신뢰성은 운에 맡기는 것과 다름없다.
전망: 생태계 거버넌스가 DX의 일부가 된다
앞으로 개발자 경험(DX)의 정의는 넓어질 것이다. 단순히 "코드 작성이 편한가"를 넘어, 내가 의존하는 도구들이 얼마나 투명한 거버넌스 구조 위에 있는가, 그리고 AI 워크플로우 안에서 품질이 조용히 저하되지 않는다는 신뢰를 어떻게 구조적으로 확보하는가까지 포함하게 된다.
React 생태계가 재단이나 운영위원회 형태의 독립적 거버넌스로 이동한다면 그것은 기술적 사건이기 전에 신뢰 회복의 사건이다. MCP 표준 위에 계약 검증 도구들이 쌓여간다면 그것은 편의 기능이 아니라 AI 워크플로우의 안전 설계다.
도구를 선택한다는 것은 결국 그 도구의 미래를 함께 선택하는 일이다. 누가 그 미래를 설계하고 있는지를 묻는 것, 그것이 프로덕트 사고를 가진 개발자가 스택을 고르기 전에 먼저 해야 할 일이다.