4시간 만에 웹앱을 만들었다는 경험담이 브런치에 올라왔다. ADHD 어린이를 위한 칭찬 타이머 앱. Claude Code가 로컬 폴더에 직접 접근해 파일을 생성·수정하고, GitHub에 자동 커밋하고, 터미널 명령까지 실행했다. 개발 경험이 깊지 않은 사람도 프롬프트만으로 동작하는 웹앱을 뽑아냈다. 숫자만 보면 인상적이다.
그런데 나는 이 경험담을 읽으면서 계속 다른 기사가 머릿속을 맴돌았다. dev.to에 올라온 MCP 보안 분석 글이다. 183개의 로컬 도구를 연결한 MCP 서버를 소개하는 인디 개발자의 프로젝트를 해부한 글인데, 핵심 지적은 단순하다. "로컬에서 실행된다"는 말이 "안전하다"는 말과 같지 않다.
Claude Code는 정확히 그 구조다. 내 컴퓨터의 파일 시스템에 직접 읽기·쓰기 권한을 갖는 에이전트. GitHub Desktop을 통해 레포지토리에 푸시하고, 터미널에서 명령을 실행한다. 개인 프로젝트 수준에서는 이 자유도가 생산성의 원천이다. 4시간 개발이 가능한 이유가 여기 있다. 문제는 이걸 팀 워크플로우에 그대로 들고 들어올 때다.
MCP 분석 글이 지적한 핵심 위협을 Claude Code 맥락으로 번역하면 이렇다. 에이전트가 파일 시스템에 자유롭게 접근한다는 건, 프롬프트 인젝션 공격의 진입점이 "네트워크"에서 "파일 내용"으로 이동한다는 뜻이다. 악의적으로 작성된 이슈 본문, 외부에서 받아온 설계 문서, 심지어 README 한 줄이 에이전트를 조종하는 명령이 될 수 있다. 데이터가 로컬에 있다고 해서 이 공격 벡터가 사라지지 않는다. 오히려 OAuth나 API 키 없이 동작하는 구조는, 감사 로그도 없고 접근 범위를 사후에 좁힐 수 있는 컨트롤 플레인도 없다는 의미다.
브런치 글에서 주목할 디테일이 하나 있다. 작성자가 Claude Code의 반복적인 Edit 확인 요청이 번거로워서, CLAUDE.md 파일을 만들어 "Edit 여부 묻지 말고 그냥 실행하라"고 설정했다는 부분이다. 개인 생산성 관점에서는 합리적인 선택이다. 그런데 팀 레포지토리에 이 설정이 기본값으로 박혀 있다면? 에이전트는 인간의 승인 없이 코드를 수정하고, 커밋하고, 푸시한다. 우리가 에이전트 자율성 레벨을 명시적으로 설계하지 않으면, 편의 설정 하나가 팀 전체의 승인 구조를 무력화한다.
이게 내가 이 두 글을 함께 읽어야 한다고 생각한 이유다. Claude Code의 4시간 개발 경험담은 AI-First 워크플로우의 가능성을 잘 보여준다. 하지만 MCP 보안 분석이 경고하는 것처럼, 에이전트가 가진 권한의 총합은 개별 도구의 권한 합산이 아니다. 파일 시스템 + GitHub + 터미널 실행 권한을 동시에 가진 에이전트는, 그 세 권한의 교차점에서 예상하지 못한 공격 표면을 만든다.
팀이 Claude Code를 도입하기 전에 설계해야 할 것들을 구체화하면 세 가지다. 첫째, 에이전트 접근 범위 명시. 어떤 디렉토리까지 읽기·쓰기를 허용할지, 환경 변수나 시크릿 파일은 어떻게 격리할지를 CLAUDE.md가 아닌 폴더 구조와 .gitignore 수준에서 설계해야 한다. 둘째, 승인 게이트 설계. Edit 확인 요청을 끄는 것이 편하다고 해서 팀 레포에서도 그 설정을 기본값으로 만들면 안 된다. 어떤 작업은 반드시 인간 승인을 거치도록 워크플로우를 구조화해야 한다. 셋째, 감사 가능성 확보. GitHub 커밋 히스토리는 버전 관리 도구이지 보안 감사 도구가 아니다. 에이전트가 어떤 파일을 읽고 어떤 판단 근거로 수정했는지를 추적할 수 있는 로그 구조를 별도로 설계해야 한다.
속도는 AI가 내준다. 4시간 만에 앱을 만드는 경험은 앞으로 더 흔해질 것이다. 그 속도를 팀 전체가 안전하게 누리려면, 에이전트가 처음 폴더에 손대기 전에 팀이 먼저 권한 경계를 그어놔야 한다. MCP가 "로컬이니까 안전하다"는 서사로 접근 제어를 생략했던 것처럼, Claude Code 도입 팀도 "빠르게 결과가 나오니까"라는 이유로 보안 설계를 뒤로 미루는 패턴을 반복하지 않기를 바란다.