어느 날 팀 Slack 채널을 열었더니 하루 만에 다섯 개의 주제가 쏟아졌다. 65줄짜리 Markdown 파일로 AI를 길들이는 법, MCP 대신 CDP를 써서 토큰 비용을 82% 줄인 이야기, 브라우저 안에서 AI가 웹앱을 직접 제어하는 WebMCP의 등장, 그리고 무신사가 2000명의 지원자에게 AI 코딩 도구를 쥐여주고 "AI 활용 능력"을 평가하겠다고 선언한 뉴스까지.
처음엔 각각 별개의 소식처럼 보였다. 그런데 한 발 물러서 보니, 이 다섯 가지가 하나의 흐름을 가리키고 있었다. AI 도구 자체가 아니라, AI를 맥락에 맞게 판단하고 활용하는 사람의 역량이 가치의 원천이 되는 시대가 왔다는 것.
1. CLAUDE.md 열풍 — 프롬프트 한 장이 마법은 아니다
Andrej Karpathy의 LLM 코딩 비판에서 영감을 받아 커뮤니티가 만든 65줄짜리 CLAUDE.md가 GitHub에서 화제가 되었다. "Think Before Coding", "Simplicity First", "Surgical Changes", "Goal-Driven Execution" — 네 가지 원칙을 프롬프트로 주입하면 Claude가 과잉 행동을 줄이고 안정적인 코드를 작성한다는 것이다.
팀원들의 반응은 즉각적이었다. "바로 복붙", "내 것도 똑똑해져라." 하지만 잠깐 멈춰서 생각해보면 몇 가지 질문이 떠오른다.
이건 프롬프트 엔지니어링의 재포장 아닌가? "구체적으로 지시하면 더 잘 따른다"는 LLM 사용의 기본이다. Karpathy의 이름값과 GitHub 바이럴이 마법의 해결책이라는 인상을 만들었을 뿐, 새로운 기술적 돌파구는 아니다. 참고로, 이 파일은 Karpathy 본인이 만든 것도 아니다.
"넣었더니 나아졌다"는 확증 편향일 수 있다. LLM 출력은 본질적으로 확률적이다. 같은 프롬프트에도 결과가 달라지는데, 잘 된 케이스만 기억하고 "역시 효과 있어!"라고 말하기 쉬운 구조다.
원칙끼리 충돌한다. "Simplicity First"는 최소한의 코드를 요구하는데, "Goal-Driven Execution"은 테스트를 먼저 작성하라고 한다. 또 "요청 안 한 에러 처리를 하지 마라"는 프로덕션 코드에서는 오히려 위험한 조언이 될 수 있다.
그렇다면 진짜 효과를 보려면 어떻게 해야 할까?
범용 원칙 대신 프로젝트 고유 컨텍스트를 넣어라. "단순하게 작성하라"는 모델이 이미 안다. "우리는 monorepo이고, packages/ 간 의존성을 함부로 추가하지 마라"처럼 프로젝트에서 실제로 반복되는 실수를 막는 지시가 훨씬 강력하다.
"하지 마라"보다 "이렇게 해라"로 써라. LLM은 금지 지시를 잘 어긴다. "불필요한 추상화를 하지 마라" 대신 "새 함수를 만들기 전에, 기존 코드에서 같은 역할을 하는 함수가 있는지 먼저 확인하고 알려줘"가 훨씬 잘 먹힌다.
Claude가 실제로 삽질한 케이스를 모아서 하나씩 추가하라. 살아있는 문서로 운영하되, 길이는 10~15개 규칙 이내로 관리하라. 컨텍스트가 길어질수록 모델이 앞부분을 무시할 확률이 높아진다.
CLAUDE.md는 여정의 출발점이 될 수 있지만, 종착점은 아니다.
2. CDP vs MCP — LLM에게 물고기 대신 낚싯대를 달라
같은 날, 한 팀원이 흥미로운 실험 결과를 공유했다. Notion 페이지를 시각화하는 동일한 작업에서 MCP 대신 CDP(Chrome DevTools Protocol)를 사용했더니 토큰을 82% 아꼈다는 것이다. 67개 블록을 만드는데 결과물은 같은데 비용이 5배 넘게 차이났다.
| MCP | CDP | |
|---|---|---|
| Tool calls | 11회 | 2회 |
| 총 토큰 | 64,448 | 11,837 |
왜 이런 차이가 날까? 이건 MCP의 문제가 아니라 LLM의 구조적 한계 때문이다.
LLM은 메모리가 없다. 매 턴마다 이전 대화 전체를 처음부터 다시 읽는다. MCP 방식은 "블록 만들어줘" → 결과 확인 → context 전체 다시 읽기 → "다음 블록"을 11번 반복하니 비용이 급격히 치솟는다. 반면 CDP 방식은 Claude가 puppeteer 스크립트를 한 번 작성하면, 이후 조작은 LLM 바깥에서 실행된다. 턴 2번이면 끝.
이 팀원의 비유가 인상적이었다.
"LLM에게 물고기를 잡아달라고 하지 말고, 낚싯대(스크립트)를 만들어달라고 하세요."
Notion뿐 아니라 Slack, Figma 등 Chromium 기반 앱이라면 전부 CDP로 조작 가능하다. MCP 서버 설치·설정 없이, 앱을 디버깅 모드로 열고 Claude Code에게 부탁하면 된다.
여기서 도출되는 인사이트는 명확하다. 같은 결과를 내는 데 비용이 5배 차이난다면, 도구 선택 자체가 핵심 역량이다. AI를 잘 쓴다는 건 프롬프트를 잘 쓰는 것만이 아니라, LLM의 비용 구조를 이해하고 적절한 도구를 선택하는 판단력을 포함한다.
3. WebMCP — 웹이 두 개의 층으로 나뉘고 있다
그리고 WebMCP가 등장했다. Google Chrome 146 프리뷰에 탑재된 이 프로토콜은, AI 에이전트가 브라우저 화면을 스크린샷으로 인식하거나 UI를 흉내 내는 대신 웹사이트가 구조화된 호출 가능한 도구를 직접 노출하는 방식이다.
쉽게 말해, 에이전트에게 "네이버 쇼핑에서 어떤 제품 찾아서 주문해줘"라고 하면, 화면을 보고 클릭하는 게 아니라 네이버 쇼핑의 WebMCP 도구를 직접 호출해서 처리하는 것이다. Google과 Microsoft가 공동 개발하고 W3C 표준화 트랙에 올라갔다.
웹이 점점 두 층으로 나뉘고 있다. 사람을 위한 UI 레이어와 기계를 위한 구조화된 인터페이스 레이어. WebMCP는 후자의 접점이다. 한 팀원은 "이제는 웹 표준이 아니라, 웹 AI 표준이 생기겠군요"라고 했는데, 정확한 포착이다.
다만 현실적으로는 아직 실험 단계다. Chrome 146 Canary에서 플래그를 켜야만 사용할 수 있고, 스펙은 초기 드래프트이며, 보안 이슈(프롬프트 인젝션, 데이터 유출 등)가 해결되지 않았다. 다른 브라우저의 구현 타임라인도 발표되지 않았다.
그래도 주목해야 하는 이유가 있다. Google과 Microsoft가 함께 코드를 작성하고, W3C가 제도적 기반을 제공하며, Chrome에서 이미 구현이 돌아가고 있다. 웹 표준이 직면하는 가장 어려운 허들 — 제안에서 작동하는 소프트웨어로 가는 것 — 을 이미 넘었다.
CDP가 "현재 쓸 수 있는 무기"라면, WebMCP는 "준비해야 할 미래"다. 지금은 스펙을 파악하고 HTML 폼 구조를 정리해두는 정도가 현실적인 준비일 것이다.
4. 무신사가 보낸 신호 — 개발자의 정의가 바뀌고 있다
이 모든 기술적 변화가 채용 시장에서 어떤 의미를 갖는지, 무신사의 사례가 명확하게 보여줬다.
무신사는 신입 개발자 공채에서 모든 지원자에게 AI 코딩 에이전트를 제공하고, "코딩 실력"이 아닌 "AI 활용 능력"을 평가하겠다고 선언했다. 2000명이 넘는 지원자가 몰렸다.
무신사가 사용한 "AI 네이티브"라는 표현은 세 가지를 내포한다. AI가 전제된 환경에서 자연스럽게 사고하고 작업하는 능력, AI의 강점과 한계를 이해하고 적절히 활용하는 감각, 그리고 AI가 생성한 결과물을 비판적으로 검토하고 개선할 수 있는 역량이다.
이것은 오늘 우리가 논의한 모든 주제와 직결된다.
CLAUDE.md를 그대로 복붙하는 게 아니라 프로젝트에 맞춰 커스터마이징하는 것이 AI 네이티브다. CDP와 MCP의 비용 구조를 이해하고 상황에 맞는 도구를 선택하는 것이 AI 네이티브다. WebMCP의 성숙도를 냉정하게 판단하고 적절한 시점에 준비하는 것이 AI 네이티브다.
그리고 이 변화는 개발자만의 이야기가 아니다. 무신사는 "향후 전사적으로 오픈AI 기술 도입 확대를 검토한다"고 밝혔다. 기획, 마케팅, 운영 등 모든 직군에서 AI 활용 능력이 기본 역량으로 자리잡을 것이다.
하나의 그림
오늘 하루 동안 팀 채널에서 나온 주제들을 연결하면 하나의 그림이 보인다.
CLAUDE.md는 AI에게 더 나은 지시를 내리는 방법이었다. CDP vs MCP는 AI 도구의 비용 구조를 이해하고 최적화하는 방법이었다. WebMCP는 AI 에이전트가 웹을 직접 제어하는 미래를 보여줬다. 그리고 무신사의 채용은 이 모든 역량이 실제 채용 기준이 되는 현실을 확인시켜줬다.
결국 AI 시대에 가치 있는 사람은 도구를 많이 아는 사람이 아니라, 어떤 도구를 언제 어떻게 써야 하는지 판단할 수 있는 사람이다. 범용 65줄을 복붙하는 사람이 아니라 자기 맥락에 맞는 가이드라인을 만드는 사람, MCP가 유행이라고 무조건 따라가는 사람이 아니라 CDP가 더 적합한 상황을 알아차리는 사람, WebMCP가 나왔다고 바로 도입하는 사람이 아니라 실험 단계임을 냉정하게 판단하고 준비하는 사람.
AI가 사람을 대체하는 게 아니라, AI를 판단력 있게 활용하는 사람이 그렇지 못한 사람을 대체한다. 무신사의 2000명 지원 열풍은 이미 많은 사람들이 이 사실을 체감하고 있다는 증거다. 문제는 이제 우리 각자가 어떻게 준비하느냐에 달려 있다.