Claude Code는 아직 당신의 키보드를 못 잡고 있다
인프라 작업에 Claude Code를 쓰는 팀이라면 이 패턴을 너무 잘 안다. Claude에게 명령어를 물어보고, 답을 읽고, 터미널을 열고, 복사-붙여넣기, 결과를 다시 Claude에 붙여넣기—그리고 반복. 한 개발자는 이걸 두고 "키보드를 못 만지게 한 시니어 엔지니어를 고용한 것 같다"고 표현했다. 정확한 비유다.
지금 대부분의 팀에서 Claude Code는 여전히 '제안 도구'다. 그런데 2026년 현재, 이 구도를 바꿀 수 있는 레이어가 세 개 동시에 성숙해지고 있다. MCP 실행 권한, CLAUDE.md 컨텍스트 계층화, 그리고 에이전트 편집기 시장의 재편이다. 이 세 축을 묶어서 설계하지 않으면, 도구를 쓰는 게 아니라 도구에 끌려다니는 상태가 계속된다.
MCP 서버: Claude에게 실제 실행 권한 주기
Conduit이라는 오픈소스 프로젝트(Apache 2.0)는 이 문제를 정면으로 파고든 사례다. SSH·RDP·VNC·웹 세션을 하나의 MCP 서버로 묶어, Claude Code가 명령어를 제안하는 게 아니라 직접 실행하도록 설계했다. Claude Code에 MCP 서버를 등록하면 60개 이상의 툴 호출이 가능해진다—터미널 명령 실행, 화면 캡처, GUI 클릭, 웹 폼 입력까지.
실제 워크플로우 차이가 얼마나 나는지 보자. "모든 프로덕션 서버의 디스크 사용량을 확인하고, 가장 여유가 없는 서버의 주요 디렉토리를 알려줘"라는 요청 하나로 Claude가 서버 목록 조회→각 서버 df -h 실행→문제 서버 식별→du -sh 실행→분석 결과 리포팅까지 자동 처리한다. 기존에 10분이 걸리던 작업이 30초 대화로 끝난다.
물론 "모든 서버에 AI가 SSH 접근"이라는 신뢰 경계는 냉정하게 봐야 한다. Conduit의 안전 모델은 이 지점을 어떻게 처리하는지가 핵심이다. 읽기 작업은 초록, 실행은 노랑, 쓰기는 주황, 크리덴셜 접근은 빨강으로 색상 코딩된 승인 프롬프트가 뜨고, 120초 내 응답이 없으면 자동 거부된다. 분당 30회 호출 제한과 모든 툴 호출의 감사 로그도 기본 내장이다. 완벽한 솔루션은 아니지만, 설계 방향은 맞다—AI에게 실행 권한을 줄 때는 반드시 가시성과 취소 가능성이 함께 와야 한다.
팀에 MCP 실행 권한을 도입할 때 체크해야 할 것: 승인 프롬프트 없이 자동 실행되는 범위가 어디까지인지, 감사 로그가 팀 전체에서 공유되는지, 크리덴셜이 에이전트 프로세스 메모리에 노출되지 않는지. 이 세 가지가 정의되지 않은 상태에서 실행 권한을 주면 Mercor 사례처럼 공급망 보안 사고로 이어진다.
CLAUDE.md 계층화: 컨텍스트를 예산처럼 써야 한다
실행 권한을 줬다고 끝이 아니다. Claude가 실제로 우리 팀의 판단으로 행동하게 하려면 컨텍스트 관리가 선행돼야 한다. 그리고 여기서 대부분의 팀이 막힌다—매 세션마다 같은 15줄의 프로젝트 컨텍스트를 붙여넣는 루프에서 못 빠져나온다.
CLAUDE.md는 프로젝트와 함께 진화해야 한다. 프로토타입 단계에선 10줄이면 충분하다. MVP 단계에서 가장 중요한 섹션은 역설적으로 "우리가 선택하지 않은 것과 그 이유"다. GraphQL을 왜 보류했는지, Redux를 왜 쓰지 않는지를 적어두지 않으면 Claude는 매 세션마다 같은 대안을 재제안한다. 이미 합의된 결정을 반복 설명하는 건 토큰 낭비이자 팀 에너지 낭비다.
프로덕션 단계에서 CLAUDE.md에서 가장 효과가 큰 섹션은 "절대 하지 말 것"이다. localStorage에 JWT 저장 금지, SQL 문자열 연결 금지, 프로덕션 브랜치 직접 푸시 금지—이걸 명시하면 Claude는 구현 옵션에서 그 선택지를 아예 제거한다. 코드 리뷰 캐치가 필요 없어지는 게 아니라, 해당 패턴의 코드 자체가 생성되지 않는다.
팀 규모가 커지면 단일 CLAUDE.md가 300줄을 넘어 컨텍스트 윈도우를 잡아먹는다. 이때의 해법은 계층화다—코어 50줄 + frontend.md / backend.md / devops.md 분리, 그리고 프롬프트 키워드 기반으로 관련 컨텍스트만 자동 주입하는 훅 스크립트. 한 팀의 실제 사례에서 이 구조로 평균 컨텍스트 사용량이 40% 줄었다. 컨텍스트 윈도우는 예산이다. 매 세션마다 전체를 소비하지 않아야 한다.
시장 변화: 에이전트 편집기 독립 플레이어의 시간이 줄고 있다
Conduit와 CLAUDE.md 설계는 도구 레벨의 이야기다. 그런데 상위 레벨—어떤 에이전트 편집기를 기반으로 팀 워크플로우를 구축할 것인가—에서도 중요한 변화가 진행 중이다.
Cursor 3가 Composer 2를 공개했다. 서드파티 모델 위에 파인튜닝한 게 아니라 처음부터 학습한 인하우스 코딩 모델이다. OpenAI는 Windsurf를 인수해 GPT-5 기반 코딩 서페이스로 통합 중이다. 주요 에이전트 편집기 세 개 중 두 개가 이미 프런티어 랩 소유가 됐다. 서드파티 API 위에 UX를 쌓는 독립 에디터의 포지셔닝 공간이 압축되고 있다.
이게 팀 설계에 주는 시사점은 명확하다. 에이전트 편집기에 팀 워크플로우를 깊이 의존할수록, 그 플랫폼이 어느 랩으로 귀속되느냐가 코드 데이터 파이프라인과 직결된다. Windsurf Pro 플랜이 12개월 유지되더라도 이후 기능은 OpenAI 계정 종속이다. 도구 선택은 기능 비교가 아니라 데이터 귀속과 벤더 락인 리스크의 문제다.
Claude Code 기반으로 워크플로우를 구축하는 팀이라면, MCP 레이어와 CLAUDE.md 계층화를 선 설계하고 편집기 독립성을 유지하는 게 현재로선 가장 실행 가능한 포지션이다.
실행 체크리스트: 내일 당장 할 수 있는 것
세 가지를 순서대로 점검하라.
1. CLAUDE.md 현행화부터. 현재 CLAUDE.md가 언제 마지막으로 업데이트됐는지 확인하라. 프로토타입 시절 파일을 프로덕션 앱에 그대로 쓰고 있다면, 지금 당장 "거절한 기술 스택과 이유" 섹션과 "절대 하지 말 것" 섹션을 추가하라. 팀 규모가 5명 이상이라면 계층화 구조로의 전환을 이번 스프린트 안에 계획에 넣어라.
2. MCP 실행 범위 정의. 팀에 MCP 서버를 도입하기 전에 실행 허용 범위, 승인 필요 범위, 절대 자동화 불가 범위를 명시적으로 정의하라. Conduit 같은 도구는 이 경계를 기술적으로 구현해주지만, 경계 자체는 팀이 먼저 설계해야 한다.
3. 편집기 의존성 감사. 현재 팀이 쓰는 에이전트 편집기의 소유 구조와 데이터 정책을 다시 읽어라. 특히 Windsurf 사용 팀은 인수 이후 약관 변화를 추적해야 한다.
Claude Code가 제안 도구에서 실행 주체로 올라서는 건 하나의 설정 변경으로 되는 일이 아니다. MCP 실행 권한, 컨텍스트 계층화, 편집기 플랫폼 선택—이 세 레이어를 동시에 설계한 팀만이 속도와 통제권을 함께 쥘 수 있다.