1인 개발자로서 약 10개의 라이브 프로젝트를 운영 중이며, 프로젝트당 하나의 Claude Code 세션을 사용하고 있습니다. 지난주 한 세션이 큐(queue)를 집계하여 보고했습니다: 미결 항목 180개, 13일 이상 된 항목 없음, 그리고 254개 항목 중 221개가 내가 아닌 AI 세션에 의해 생성됨. 시스템 내에서 가장 큰 단일 메일함은 시스템이 스스로를 작업하고 있는 것이었습니다: 36개의 작업 중 약 30개가 자체 툴링(tooling)을 개선하는 작업이었습니다. 아무것도 고장 나지 않았습니다. 그 작업들은 모두 합리적이었고, 바로 그것이 실제 문제였습니다. 어떤 실제 저장소(repository)에서든 세션을 열면 10가지의 진정한 개선 사항을 찾아낼 것입니다: 더 깔끔하게 만들 수 있는 리팩터링 (refactor), 최신 상태가 아닌 문서 (doc), 더 엄격하게 만들 수 있는 테스트 (test). 이를 15개의 저장소로 곱하면 한 사람이 결코 다 처리할 수 없는 흐름이 됩니다. 큐는 실수로 채워지는 것이 아니라, 좋은 아이디어로 채워지고 있었습니다.

비슷한 환경을 운영 중인 분들에게 유용할 수 있는 두 가지 사항입니다: 입증 책임(burden of proof)을 역전시키십시오. 이전에는 누군가 삭제하기 전까지 작업은 존재하는 상태였습니다. 이제는 명확한 트리거가 지정되어야만 작업이 생성됩니다: 사용자에게 발생한 결함, 보안/자금/데이터에 대한 리스크, 배포 차단 요소(deploy blocker), 또는 내가 요청하는 경우입니다. "더 깔끔해질 것이다"나 "지나가다 발견했다"와 같은 내용은 파이프라인(pipeline)이 아닌 내가 읽는 세션 요약(session summary)에 포함됩니다. 이 방식을 역으로 적용하여 한 번에 19개의 메타 작업(meta-tasks)을 아카이브(archive)했습니다.

나는 유입을 필터링하기 위한 AI 게이트키퍼(gatekeeper)를 의도적으로 구축하지 않았습니다. 같은 주에 문구가 잘못된 작업 하나가 들어왔는데, 길고 구조가 잘 잡혀 있으며 매우 그럴싸해 보였지만, 문자 그대로 받아들였다면 186개 고객 메일함의 발신 메일을 잘못된 서비스로 라우팅했을 작업이었습니다. 모델 기반의 게이트키퍼는 그런 작업을 그대로 통과시켜 버릴 것입니다. 그 작업은 게이트키퍼가 잡아내기로 되어 있는 바로 그 실패 유형을 정확히 포함하고 있을 것이기 때문입니다.

그 과정에서 다른 두 가지 문제도 발생했습니다. 하나는 세 개의 병렬 세션이 하나의 공유 설정 파일(shared config file)에 대해 읽기-수정-쓰기(read-modify-write)를 수행한 것이었습니다(마지막 작성자가 승리하는 방식이며, 에이전트들은 프로세스이기 때문에 서로를 인지하지 못합니다). 다른 하나는 명령어를 패턴 매칭하여 저장소 간 쓰기(cross-repo writes)를 방지하던 프리-툴 훅(pre-tool hook)이었는데, Python 헤레독(heredoc)이 어떤 패턴과도 일치하지 않은 채 21개의 외부 저장소에 내용을 작성하면서 무력화되었습니다. 이 문제는 의도를 추측하는 대신 git 상태를 전후로 비교하는 방식으로 현재 해결되었습니다. 다이어그램과 아직 해결되지 않은 항목들에 대한 솔직한 수치를 포함한 전체 글은 다음에서 확인할 수 있습니다: https://martin-schenk.es/blog/every-gate-in-my-system-is-a-scar/ (/u/ma8nk 제출) [link] [comments]