Claude Code가 자동 모드를 기본값으로 전환했다. 프로·맥스·팀 요금제 신규 세션부터는 개발자가 매번 명령을 승인하지 않아도 AI가 알아서 작업을 이어간다. 앤트로픽이 공개한 데이터는 꽤 설득력 있다. 인간 테스터의 위험 명령 감지율이 13.6%인 반면, 자동 모드 분류기의 차단율은 89%였다. 세션이 길어질수록 사람의 판단력은 떨어지고(초반 17% → 50건 이후 5%), 분류기의 성능은 유지됐다. 생산 환경 수준의 심각한 비의도적 피해 발생률도 수동 승인 세션(6.3%)이 자동 모드 세션(2.4%)보다 두 배 이상 높았다.
이 변화가 의미하는 건 단순한 편의 기능의 업그레이드가 아니다. '나 혼자 AI와 대화하는 도구'라는 Claude Code의 기본 전제가 조용히 바뀌고 있다는 신호다. 자동 모드가 켜지면 AI는 더 오래, 더 멀리, 더 자율적으로 달린다. 이 달리는 거리가 늘어날수록 개발자에게는 새로운 질문이 생긴다. AI가 어디까지 달렸는지, 지금 어느 브랜치에서 무엇을 하고 있는지, 다른 세션과 충돌하고 있지는 않은지.
혼자 쓸 땐 없던 문제가, 병렬로 쓰기 시작하자 터졌다
자동 모드가 가능하게 만드는 것 중 하나는 멀티 세션 운용이다. 홈 페이지 작업 세션, 주문 로직 세션, 거버넌스 부채 청산 세션을 동시에 열어두고 각각이 독립적으로 달린다. git worktree로 브랜치를 분리하면 파일 충돌도 없다. 완벽해 보인다. dev.to 시리즈 'Indie Dev Notes'를 쓰는 개발자 Dexter Lung이 정확히 이 구조로 일하다가 맞닥뜨린 현실은 달랐다.
"기억으로" 죽은 브랜치라고 판단해 삭제하려 했는데, 알고 보니 다른 세션이 활발하게 개발 중이던 브랜치였다. 메인라인보다 10커밋 앞서 있었고, git의 reflog가 없었다면 통째로 날아갈 뻔했다. 또 다른 날엔 코디네이션 문서를 푸시하려다 막혔다. 바로 그 순간 다른 세션이 자기 브랜치를 메인에 머지했기 때문이다. 세션들은 서로가 뭘 하는지 전혀 모른다. 전체 그림을 아는 건 오직 인간인 개발자뿐이었고, 그 인간의 기억은 휘발되고 틀린다.
그가 내린 진단은 명쾌하다. 병렬 실행 자체는 문제가 아니다. 세션을 더 여는 건 쉽다. 어려운 건, 며칠에 걸쳐 흩어진 작업들 사이에 '지금 누가 뭘 하고 있고, 얼마나 됐고, 뭐가 남았는지'를 기억하는 단일 장소가 없다는 것이다. 병목은 AI의 컴퓨팅 파워가 아니라, 개발자 자신의 컨텍스트가 세션 간에 연결되지 않는다는 데 있었다.
블랙보드 패턴: AI 팀에게 공유 칠판을 줘라
그의 해법은 하나의 마크다운 파일이었다. 단순하지만 규칙이 있다. 모든 세션이 읽고 쓰는 단일 공유 문서. '진행 중 / 백로그 / 완료' 트래킹과 어느 작업이 어느 파일에 닿는지 표시하는 '영역 맵'. 작업을 시작하기 전 반드시 '진행 중' 열에 자기 브랜치와 날짜를 먼저 등록하는 선점 규칙. 7일간 업데이트 없는 항목은 stale로 간주하되, 재선점 전 반드시 git에서 브랜치 실제 상태를 확인하는 자동 복구 규칙.
이 파일은 메인라인에 두고, 어떤 세션이든 절대 경로로 접근할 수 있는 전용 worktree에서 읽고 쓴다. AI 에이전트는 자신의 작업 디렉토리 외 경로도 읽을 수 있기 때문에, 피처 브랜치에서 작업 중인 세션도 같은 블랙보드를 본다. '내 머릿속에만 있던 것'이 '파일이 기억하는 것'으로 바뀌는 순간, 세션 간 충돌의 절반이 사라졌다.
나중에 알고 보니 이건 1970년대 음성 인식 시스템에서 쓰던 블랙보드 패턴이었다. 에이전트들이 서로 직접 소통하는 대신, 하나의 공유 문서(블랙보드)를 통해 전체 작업 상태를 읽고 쓰며 조율한다. 개미가 회의 대신 페로몬으로 경로를 남기는 스티그머지(stigmergy) 방식이기도 하다. 칸반의 '백로그/진행 중/완료' 컬럼과 '선점-해제' 리스 패턴도 그 이름 안에 있다. Claude Code의 실험적 기능 Agent Teams도 비슷한 방향이지만, 한 리드 세션이 팀을 스핀업하고 종료하는 일회성 구조라 며칠에 걸친 독립 세션 간 지속적 원장이 필요한 이 시나리오와는 상호 보완적이다.
직접 써보기 전엔 보이지 않는 것들
설계를 완성했다고 생각한 시점 이후에 실제 사용에서만 드러나는 문제들이 줄줄이 나왔다.
선점은 즉시 푸시해야 한다. '행을 추가하고 작업 시작, 나중에 푸시'라고 했더니, 확인과 등록 사이의 찰나에 두 세션이 동시에 빈 칸을 보고 같은 청크를 선점했다. 행을 추가하자마자 즉시 푸시하면 git 자체가 잠금이 된다. 먼저 푸시한 세션이 이기고, 나중 세션은 리베이스를 강제당하며 충돌을 머지 타임이 아닌 선점 타임에 발견한다.
블랙보드 자체가 가장 충돌이 잦은 파일이다. 충돌을 막으려고 만든 파일이 가장 많이 충돌한다는 아이러니. 규칙은 단순하다. 자기 행만 수정한다. 다른 행을 재정렬하지 않는다.
Stale 판단은 파일의 마지막 수정 시간이 아니라 브랜치의 마지막 커밋 시간으로 한다. 꾸준히 커밋하면서 보드 업데이트를 잊은 개발자는 사라진 게 아니다. 진실은 손으로 타이핑한 줄이 아니라 git 안에 있다. 그래서 npm run board 스크립트를 짜서 각 브랜치가 얼마나 유휴 상태인지, 메인라인 대비 얼마나 앞/뒤인지를 git에서 직접 뽑아 보여준다. 손으로 쓴 진행 노트의 거짓말 탐지기다.
가장 인상적인 에피소드는 안전망이 안전망을 끈 사건이다. 블랙보드에 등록되지 않은 브랜치를 푸시할 때 알림을 주고 싶어 pre-push 훅 마지막에 'print reminder' 명령을 붙였다. 이 한 줄이 훅 전체의 성공/실패 신호를 먹어버렸다. 셸은 마지막 줄의 결과를 전체 블록의 결과로 판단하기 때문에, reminder 출력이 항상 성공을 반환하면서 거버넌스 체크 실패 여부와 무관하게 푸시가 통과됐다. '✅ 거버넌스 체크 실패, 푸시가 차단됩니다'와 'push succeeded'가 동시에 화면에 출력되는 모순이 나타나기 전까지 아무도 몰랐다. 보호 레이어를 추가할 때마다 다른 보호 레이어를 실수로 끌 수 있다. 실제로 써봐야만 그 모순이 드러난다.
자동화가 숨기는 세 번째 함정: 컨텍스트 오염
멀티 세션과 자동 모드 너머에 또 하나의 구조 문제가 있다. claude -p를 서브프로세스로 실행하는 자동화 스크립트다. dev.to의 다른 글에서 한 개발자가 발견한 사례가 이를 잘 보여준다. git diff를 받아 커밋 메시지 한 줄을 돌려주는 20줄짜리 스크립트에서, claude -p를 플래그 없이 호출하면 호출 위치의 CLAUDE.md를 자동으로 로딩한다는 사실을 뒤늦게 알았다. 프로젝트의 4,404바이트짜리 라우팅 규칙, 출력 형식 제약, 메모리 시스템 프로토콜 블록이 커밋 메시지 한 줄 생성 요청마다 조용히 딸려들어가고 있었다.
토큰 비용보다 더 심각한 건 결합도다. 스크립트 상단의 SYSTEM 문자열이 동작을 정의한다고 생각했지만, 실제로는 호출 시점의 CLAUDE.md도 동작에 영향을 준다. 미래에 CLAUDE.md를 수정하는 누군가가 "커밋 메시지는 항상 타이틀 케이스로"라는 규칙을 추가하면, 스크립트 코드는 한 줄도 바뀌지 않았는데 출력이 바뀐다. 어느 디렉토리에서 실행했느냐에 따라 같은 스크립트가 다른 결과를 내는 것이다. 해법은 --safe-mode 플래그였다. --bare가 더 직관적으로 보이지만, OAuth 인증을 끊어버리는 부작용이 있다. --safe-mode는 CLAUDE.md 자동 감지는 막으면서 인증은 정상 작동시킨다. 플래그 이름만 보고 가정하지 말고, 실제로 실행해서 확인하는 것이 유일한 방법이었다.
개발자가 직접 설계해야 할 세 가지 구조
Claude Code 자동 모드의 기본값 전환은 편리함을 선물하면서 동시에 새로운 설계 책임을 부과한다. 앤트로픽도 명시한다. "분류 시스템에 의존하는 만큼, 고위험 생산 인프라 변경 같은 작업에서는 개발자가 직접 Claude의 행동을 검토하라." 자동화가 처리해주는 것과 여전히 사람이 설계해야 하는 것의 경계선이 이동했을 뿐, 경계선 자체는 사라지지 않았다.
세 가지 구조를 직접 설계하지 않으면 자동 모드는 생산성 도구가 아니라 관리 부담이 된다.
첫째, 세션 간 공유 원장. 멀티 세션을 운용한다면 블랙보드가 필요하다. 포맷은 자유롭다. 마크다운 파일 하나도 충분하다. 중요한 건 모든 세션이 읽고 쓸 수 있는 단일 진실의 원천이 존재하고, 선점 규칙과 stale 판단 기준이 명시돼 있어야 한다는 것이다.
둘째, 서브프로세스 호출의 컨텍스트 격리. claude -p를 자동화 스크립트에서 쓴다면, 호출 위치의 CLAUDE.md가 조용히 로딩된다는 사실을 기억해야 한다. 범용 작업에는 --safe-mode로 격리하고, 프로젝트 컨텍스트가 필요한 작업에는 의도적으로 열어두는 결정을 명시적으로 내려야 한다.
셋째, 보호 레이어 간의 간섭 검증. pre-push 훅, 거버넌스 체크, 자동 모드 분류기, 블랙보드 선점 규칙. 각각은 잘 작동하더라도 조합하면 서로를 끌 수 있다. 새로운 안전망을 추가할 때마다 기존 안전망이 여전히 살아있는지 실제로 확인하는 루틴이 필요하다.
AI가 더 많은 것을 자율적으로 처리할수록, 개발자의 역할은 승인 버튼을 누르는 사람에서 운용 구조를 설계하는 사람으로 이동한다. 자동 모드는 반복적인 승인 피로를 없애준다. 하지만 세션 충돌, 컨텍스트 오염, 안전망 간섭은 설계 없이는 자동으로 해결되지 않는다. 그 설계가 지금 개발자에게 남은 몫이다.