AI 세션을 여러 개 띄우면 생산성보다 사고가 먼저 늘어난다. 차단 장치보다 먼저 필요했던 건 인지와 규율이었다.
실제로 겪은 사고의 경로다. 어느 한 단계도 그 자체로는 악의가 없었다는 게 요점이다.
마무리 중이던 세션 A가 작업 폴더에서 자기가 만들지 않은 미커밋 변경을 발견한다.
도구의 안내 문구("사용자 또는 린터가 수정함")를 믿고 변경을 정당한 것으로 분류, commit을 제안한다.
내가 "추천대로"라고 답하자, commit을 넘어 push·배포·운영 측정·추가 검토까지 일괄 진행한다.
그 변경은 동시에 돌던 세션 B의 진행 중 작업이었다. 결과물이 A 쪽으로 쏠리고 B의 흐름이 교란됐다.
다른 세션의 변경이 "사용자 변경"과 똑같이 보인다. 도구는 누가 바꿨는지 구별해 주지 않는다.
한 가지를 승인받고 그 뒤의 연쇄 작업 전부를 허가받았다고 간주한다.
두 세션이 같은 파일을 고치면 나중 저장이 먼저 저장을 덮어쓴다. 이건 경비원(기억 시스템 편) 담당.
첫 번째 방어는 차단이 아니라 인지다. 새 세션이 시작될 때 자동 스크립트(hook)가 지금 다른 세션이 몇 개 열려 있고 그중 몇 개가 같은 프로젝트인지를 조사해 브리핑에 끼워 넣는다.
이 브리핑의 수신자는 사람이 아니라 AI 자신이다. 내가 세션을 몇 개 띄웠는지는 나도 안다. 모르는 쪽은 AI다. 그래서 화면 팝업이 아니라 AI의 컨텍스트(작업 기억)에 주입되게 만들었다. 알림을 설계할 땐 누가 이걸 모르는가부터 따져야 한다는 걸 여기서 배웠다.
다른 세션이 살아 있는가, 라는 단순해 보이는 질문에서 두 번 틀렸다. 결론부터 적으면, 성격이 다른 신호 셋에게 서로 다른 역할을 주고 절대 섞지 않는 것이다.
OS의 프로세스 목록에 그 세션이 실제로 떠 있는가. 여기 없으면 종료된 것. "살아 있는가"의 유일한 권위 신호다.
그 세션에서 사람과 AI가 마지막으로 대화한 시각. "열려 있지만 8시간째 방치"와 "방금까지 일하던 중"을 가른다. 프로세스 가동 시간과는 전혀 다른 값이다.
기록 파일의 mtime. 프로세스 조회가 실패했을 때만 쓰는 보조 신호. 아래 함정 때문에 1차 판정에는 절대 쓰지 않는다.
· "파일이 방금 수정됐으니 활성이겠지" — 세션은 닫히는 순간에도 마지막 기록을 남긴다. 방금 종료한 세션이 mtime상으로는 가장 신선해 보여서, 이미 종료된 세션 2개를 활성이라고 잘못 보고한 적이 있다.
· "대충 프로세스 이름으로 검색하면 되겠지" — 데스크톱 앱, 렌더러, 보조 헬퍼까지 다 잡혀서 3개가 11개로 보인다. 명령행 패턴을 정확히 좁혀 열거한 뒤 걸러내야 한다.
· "프로세스 가동 시간이 곧 유휴 시간이겠지" — 17일 떠 있던 프로세스의 마지막 대화는 12일 전이었다. 가동 시간 표기에는 12초를 12분으로 읽게 되는 포맷 함정까지 있다. 유휴는 대화 시각으로만 잰다.
· 이 함정들을 거치고 남은 교훈이 단일 출처다. 자동 브리핑과 수동 확인 명령이 같은 함수를 쓰게 해서 계산 경로를 하나로 만들었다. 같은 질문에 두 경로가 다른 답을 내는 순간부터 신뢰가 무너진다.
탐지는 스냅샷일 뿐이다. 그 위에 AI에게 상시 적용시키는 행동 규칙 다섯을 올렸다. 전부 1번 섹션 같은 사고에서 직접 나온 것들이다.
"사용자 또는 린터가 수정함" 같은 도구 안내 문구는 다른 세션의 변경과 외형이 같다. 이 세션이 직접 만들지 않은 변경은 전부 출처 미상이고, 안내 문구는 면책 근거가 못 된다.
"commit 추천대로 해줘"는 그 commit 한 번의 권한이다. 그 뒤의 push, 배포, 운영 환경 측정은 각각 다시 승인받는다. 한 번의 confirm은 자율 면허가 아니다.
"이제 닫아도 되나", "정리하자" 같은 말이 나오면 모드가 바뀐다. 프로세스 정리, 상태 보고, 인계만 허용하고 새 구현·commit·배포는 금지. 마무리 중 발견한 미커밋 변경도 손대지 않고 인계 메모로만 남긴다. 1번 사고가 정확히 이 마무리 국면에서 시작됐기 때문이다.
세션을 시작할 때 이 세션은 이 파일, 이 단계까지라고 선언하고, 다른 세션과 겹칠 것 같으면 브랜치나 파일 범위를 분리한다. 한 세션에 큰 작업 한 덩어리, 끝나면 인계 문서가 기본 단위다.
스테이징된 변경을 이 세션이 만든 것, 출처 미상, 다른 세션 가능성으로 분류하고, 미상이 섞여 있으면 사람의 명시 확인 전까지 commit과 push를 멈춘다. 남의 작업이 내 이름으로 기록되는 걸 막는 마지막 관문이다.
규율은 사람과 AI의 약속이라 깨질 수 있다. 그래서 공유 파일 쓰기에는 자동 장치를 올렸는데, 처음부터 차단을 켜지 않았다. 그게 이 층의 요점이다.
세션 시작 브리핑으로 동시 세션의 존재만 알린다. 아무것도 막지 않는다. 이 정보가 실제로 판단을 바꾸는지를 여기서 확인했다.
위험해 보이는 쓰기에 경고를 내보내되 실행은 통과시키고, 모든 의도를 로그로 쌓았다. 수백 건의 실제 쓰기를 지켜보면서 진짜 위험과 오탐(유휴 세션에 대한 과잉 경고 같은)을 갈랐다.
관찰로 검증된 소수의 위험 패턴만 차단으로 승격했다. 그게 기억 시스템 편에서 소개한 경비원이다. 차단 규칙 하나하나가 관찰 데이터를 통과한 것들이다.
잠금(lock)을 도입하는 순간 최악의 적은 충돌이 아니라 stale lock이 된다. 잠금을 쥔 세션이 강제 종료, 네트워크 단절, 메모리 부족으로 죽으면 잠금이 영영 안 풀려 모든 세션이 멈춘다. 치료가 병보다 나빠지는 지점이다.
대응은 3번 섹션의 신호 역할 분리를 재사용한다. 잠금 주인의 프로세스가 죽었으면 즉시 회수하고(강신호), 절대 시간 초과(TTL)를 안전망으로 겹친다(약신호). 장치 자체가 고장 나면 막지 않고 비켜서며 기록만 남긴다(fail-open). 보호 장치가 본업을 인질로 잡으면 안 되니까.
장치가 다 받쳐줘도, 결국 멀티세션을 굴리는 건 습관이다.
세션 하나에 작업을 욕심껏 쌓지 않는다. 단위가 끝나면 어디까지 했고 다음은 뭔지를 인계 문서로 남기고 닫는다. 다음 세션이나 옆 세션이 이어받는 비용이 크게 준다.
각 프로젝트의 현재 결론과 완료·금지 사항을 한 줄씩 적는 상태판 파일을 모든 세션이 시작할 때 무조건 읽는다(기억 시스템 편의 그 상태판). 세션끼리 서로 모순된 결정을 내리는 걸 막는 가장 값싼 장치였다.
한 세션이 공유 인프라를 수정하는 동안 다른 세션으로 독서나 질문을 병행할 때는, 그 세션에 "지금 다른 세션이 ○○를 수정 중이니 그 파일들은 절대 수정하지 마"라고 선언해 둔다. 의도적 쓰기 충돌은 이 한 줄로 닫힌다.
공유 파일을 만지거나 배포처럼 외부에 영향을 주는 작업 직전에는 동시세션 확인 명령 한 줄을 돌려 그 결과를 그대로 인용한다. 눈대중 재해석은 금지다. 자동 브리핑과 같은 함수, 같은 답이어야 한다.
멀티세션이 아니어도 동시에 움직이는 행위자가 둘 이상이면 같은 원리가 작동한다.
파일 충돌보다 남의 변경을 정당한 것으로 오인하는 사고가 먼저 온다. 내가 만들지 않은 변경은 전부 출처 미상. 이 한 줄이 가장 많은 사고를 막았다.
자율적인 AI일수록 한 번의 OK를 연쇄 작업 전체의 면허로 해석한다. 승인 1회는 명령 1개라는 선은 사람 쪽에서 그어 줘야 했다.
프로세스 실재는 열림의 권위, 마지막 대화 시각은 활성 라벨, 파일 시각은 폴백. 역할을 섞는 순간 오판이 시작되고, 보고는 반드시 같은 함수라는 단일 출처에서 나와야 한다.
처음부터 막으면 오탐이 신뢰를 죽이고 결국 장치를 끄게 된다. 경고 단계에서 실제 데이터를 모아 오탐을 제거한 뒤, 검증된 좁은 패턴만 차단으로 올린다.
동시 세션 경고의 수신자는 그걸 이미 아는 사람이 아니라 모르는 AI였다. 누가 이걸 모르는가부터 물으면 전달 경로가 저절로 정해진다.