속도의 함정: 다 자동화하면 다 해결될까?
'AI로 다 자동화하면 되지 않나요?'라는 질문을 팀에서 꽤 자주 받는다. 솔직히 말하면, 틀린 질문이다. 정확한 질문은 '어디까지 자동화해야 하나요?'다. 이 차이가 팀의 6개월 후를 가른다.
GeekNews에 소개된 소프트웨어 팩토리 분석은 이 문제를 정면으로 다룬다. AI 코딩 에이전트가 코드 생성·테스트·스캔을 거의 무한에 가깝게 확장할 수 있는 반면, 인간의 검토와 판단은 그렇지 않다는 것이다. 생성 속도가 아무리 빨라도 검증 속도가 따라오지 못하면, 결국 병목은 사람에게로 이동한다. 이건 도구의 문제가 아니라 구조 설계의 문제다.
'다크 팩토리'가 왜 위험한가
소프트웨어 팩토리 개념에는 두 가지 운영 모드가 있다. 사람이 판단하는 '밝은 팩토리'와, 코드 검토까지 기계에 맡기는 '다크 팩토리'다. 다크 팩토리의 매력은 분명하다. 승인 프롬프트가 사라지고, 처리량이 급격히 올라가는 것처럼 보인다.
문제는 '이해 부채(comprehension debt)'다. 사람이 코드를 읽지 않으면, 존재하는 코드의 양과 팀이 실제로 이해하는 코드의 양 사이에 격차가 생긴다. 테스트가 통과하는 동안에는 아무것도 느껴지지 않는다. 그러다 3~6개월 뒤, 복잡한 시스템에서 버그가 터지면 원인을 추적할 수 없는 상태가 된다. Dex Horthy가 약 4개월간 완전 자동화 팩토리를 운영했을 때 정확히 이 문제가 터졌다—문제의 원인을 찾으려면 고된 수동 디버깅이 필요했다. 실패는 극적으로 오지 않는다. 늦고, 조용하게 온다.
Claude Code의 bypassPermissions가 보여주는 것
Velog에 올라온 Claude Code 심화 설정 글을 보면 흥미로운 설정이 등장한다. --dangerously-skip-permissions, 즉 bypassPermissions 모드다. 파일 수정과 명령 실행의 확인 절차를 전부 꺼버리는 이 모드는, 반복적인 승인 프롬프트가 진짜 방해될 때 생산성을 크게 올려준다.
그런데 이 설정에는 명시적인 조건이 붙는다. '도커나 VM처럼 격리된 환경 전용.' 개발자 본인도 이 모드를 상시로 켜두는 것은 추천하지 않는다고 적었다. 이게 핵심이다. 도구 자체는 자동화 수위를 결정해주지 않는다. 팀이 결정해야 한다. bypassPermissions를 언제 켜고 끌지 판단하는 것은 여전히 사람의 몫이다.
자동화 자격, 기준이 있어야 한다
소프트웨어 팩토리 분석이 제시하는 '백프레셔(back pressure)' 원칙은 실용적이다. 루프가 완전 자동화되려면 세 조건을 충족해야 한다: 판정 기준이 저렴하고 빈번하게 실행될 것, 쉽게 속일 수 없을 것, 즉시 결과가 나올 것. 타입 게이트, 속성 기반 테스트, 린트 위반 자동 수정 같은 것들이 여기 해당한다. 매일 밤 GitHub Actions가 린트 위반 하나를 고쳐 PR을 여는 루프는 완전 자동화해도 된다.
반면 인증 시스템, 결제 엔진, 공개 API 계약은 다르다. 잘못된 결정의 비용과 영향 범위가 크다. 여기서는 조명을 켜야 한다. Dev.to에 실린 AI 오버엔지니어링 비판 글이 정확히 같은 맥락을 짚는다. 이메일 형식 검증에 LLM을 쓰는 것은 과잉이다. 고객이 새벽 2시에 화가 나서 쓴 문단에서 긴박함의 맥락을 읽어내는 것은 AI가 제 역할을 하는 영역이다. 도구를 잘못 배치하는 것은 자동화를 안 하는 것보다 더 비싸다.
팀이 결정해야 하는 이유
각 루프마다 어느 지점에 사람의 눈을 둘 것인지—이것이 AI-First 팀의 핵심 설계 결정이다. 이 결정은 도구 벤더가 내려주지 않는다. Claude Code도, GitHub Copilot도, 어떤 에이전트도 '이 루프는 자동화하면 안 됩니다'라고 말해주지 않는다.
소프트웨어 팩토리 분석은 엔지니어의 역할 변화를 이렇게 정의한다. 개별 코드 변경을 직접 작성하는 자리에서, 루프를 설계하고 게이트를 지키는 자리로. 에이전트가 수행한 진단·구현·테스트의 증거를 검증하고, 승인과 결과에 책임지는 것이 외부 루프를 소유한 엔지니어의 일이다. 사람이 팩토리에서 사라지는 게 아니라, 실행 라인에서 설계 라인으로 이동하는 것이다.
실용적인 판단 기준: 지금 팀에 적용하려면
내일 당장 팀에서 써먹을 수 있는 판단 기준을 정리하면 이렇다.
자동화 자격이 있는 루프: - 판정 결과가 참/거짓으로 즉시 나온다 - 시간이 지나도 판정 기준이 드리프트하지 않는다 - 기계가 완료를 증명할 수 있다 - 루프가 짧다 (경험칙상 3~10단계가 한계, 20단계를 넘으면 에이전트는 흐름을 잃기 시작한다)
사람이 개입해야 하는 지점: - 잘못된 판단의 영향 범위가 넓다 (인증, 결제, 공개 API) - 테스트로 잡히지 않는 미묘한 버그 가능성이 있다 - 1년 이상의 방향을 좌우하는 아키텍처 결정이다 - 사람만이 발견할 수 있는 컨텍스트가 필요하다
인간 검토를 마지막 코드 리뷰에만 붙이는 것도 비효율적이다. 에이전트가 루프를 시작하기 전, 제품·설계·아키텍처 단계에서 사람이 개입하는 것이 훨씬 싸다. 200줄짜리 계획을 1시간 검토하면, 구현 후 2,000줄의 생성 코드를 뒤지는 리뷰를 줄일 수 있다.
전망: '얼마나 자동화할 것인가'가 팀 역량이 된다
앞으로 AI 도구는 더 강력해진다. 오케스트레이션, 샌드박스 기반 프로토타이핑, 도구 호출 능력은 계속 확장된다. 그러나 하네스가 아무리 강력해져도 장기적인 코드베이스 품질을 유지하는 것은 다른 문제다. 아키텍처 우수성의 가치는 수초가 아니라 수년에 걸쳐 드러나고, 그 판단을 자동화하기는 여전히 어렵다.
팀마다 적정 자동화 수위는 다르다. 시스템의 나이, 도메인의 복잡도, 팀의 디버깅 역량, 허용 가능한 이해 부채 수준이 모두 다르기 때문이다. 전부 어둡게 운영하면 몇 달 뒤 시스템을 해체해야 할 수 있다. 전부 밝게 운영하면 리뷰가 병목이 된다. 그 사이 어딘가에 팀의 최적점이 있고, 그 점을 찾아 설계하는 것—이게 AI-First 시대에 테크 리드가 해야 할 일이다.