스파게티 소프트웨어 공장 점검하기

Factorio 리뷰가 묘사한 것처럼, AI 에이전트를 쓰는 개발은 어느새 공장을 운영하는 일에 가까워진다. Claude Code 세션 하나로 시작해 둘, 넷으로 늘리고, worktree와 CLAUDE.md, skills, MCP를 붙이다 보면 생산성은 올라가지만 구조는 쉽게 스파게티가 된다.

문제는 코드를 더 많이 만드는 속도가 아니라, 그 코드가 다음 에이전트 세션의 입력이 되어 더 나쁜 코드를 학습시키는 데 있다. Shriram Krishnamurthi가 지적한 bookstore 앱 예시처럼, 돈 계산에 부동소수점을 쓰거나, 표준 라이브러리 대신 CSV 파서를 새로 만들고, filterByTitle 같은 이름으로 실제 검색을 구현하는 식의 사소한 결함이 쌓이면 전체 코드베이스가 슬롭을 재생산한다. Joseph Ruscio가 말한 write-only code 문제도 같은 흐름이다.

해결책의 핵심은 문서만 늘리는 것이 아니라, 체크를 실행 가능한 형태로 만드는 것이다. AGENTS.md, 스펙, skills, 계획 같은 markdown은 기준을 적어두는 데는 유용하지만, 강제하지는 못한다. 그래서 필요한 것은 각 표준을 한 가지씩 검증하는 체크이고, 그 체크를 사람 대신 AI 에이전트가 읽고, 파일을 살펴보고, 명령을 실행하고, 실패 시 수정안을 제시하는 구조다.

이 방식은 본질적으로 테스트와 같다. 예를 들어 "새 엔드포인트에는 auth middleware를 붙여라", "의존성 추가는 근거를 남겨라", "metrics pipeline을 건드리면 대시보드를 확인하라" 같은 규칙을 코드가 아닌 의미 수준에서 검증한다. 실제로 텔레메트리 이벤트 이름 변경을 잡아낸 체크, 디자인 시스템에 하드코딩 색상이 들어오는 것을 막은 체크처럼, 에이전트 체크는 사람과 CI가 놓치기 쉬운 문제를 잡아낸다.

하지만 로컬에서만 돌리는 체크는 곧 한계를 드러낸다. 사람마다 프롬프트 구성, 컨텍스트 길이, 툴 설정이 다르고, 잊거나 건너뛰는 일도 생긴다. 더 큰 문제는 silent drift다. 나쁜 패턴이 몇 개 PR을 통과하면, 다음 에이전트는 그 코드를 기준으로 더 비슷하게 작성하게 된다.

그래서 체크는 PR 위에서, merge 전에, 전체 팀이 볼 수 있게 실행돼야 한다. Martin Fowler가 CI에서 강조한 것처럼, 실패는 즉시 공유되어야 하고, 한 번의 경고가 축적되기 전에 잡혀야 한다. 그래야 코드베이스가 내부에서 서서히 망가지는 일을 막을 수 있다.

다음 단계로는 이런 체크를 CI에 넣는 발상이 자연스럽다. GitHub Actions로 Claude Code를 띄워 .continue/checks/를 평가하게 만들 수는 있고, 처음에는 80줄 정도의 YAML로 충분해 보인다. 하지만 시간이 지나면 백그라운드 프로세스 관리, stdout 분리, API rate limit 회피, JSON 파싱 fallback, 종료된 세션의 디버깅, 대시보드, auth, diff viewer, 승인 버튼, loop detection, 저장소가 필요해진다.

문제는 여기서 끝나지 않는다. 체크의 품질이 중요해질수록, 어떤 체크가 실제 문제를 잡고 어떤 체크가 헛경보를 내는지에 대한 피드백 루프가 필수다. 메트릭이 없으면 체크는 금세 화석이 되거나 소음만 내고, 결국 꺼버리게 된다. 게다가 조직 전체 정책, Sentry나 Snyk 같은 외부 신호 연동, 코드베이스 전체 스캔, PR merge 이후 트리거까지 생각하면, 직접 다 만드는 방식은 곧 또 다른 스파게티 공장이 된다.

그래서 마지막 결론은 단순하다. .continue/checks/에 표준을 적고, 그 표준을 엔지니어링 시스템으로 운영하라는 것이다. 저자들은 이를 Mission Control의 방향으로 제시한다. 복잡한 비결정성, 결과 파싱, 동시성, 인증 격리, loop detection은 아래에서 해결되고, 사용자는 체크를 만들고, 피드백하고, 개선하는 데 집중한다.

이 흐름은 결국 Toyota Production System으로 수렴한다. jidoka는 인간의 손길이 있는 자동화, kaizen은 지속적 개선, andon은 라인을 멈추는 경고줄이다. 코드 품질 체크가 corrupted dashboard를 막고, 사용자의 피드백으로 더 나아지며, 인간이 최종 판단을 내리는 구조 자체가 그 현대적 구현이다.

결론적으로, AI 에이전트가 만드는 공장은 더 빨리 커질수록 더 강한 품질 제어가 필요하다. 공장은 커져야 하지만, 그냥 커지기만 하면 스파게티가 된다. 공장을 제대로 키우려면, 체크를 걸고 계속 점검해야 한다.