불 꺼진 소프트웨어 공장은 3개월 뒤에 무너져요

3개월 후, 아무도 못 읽는 코드가 프로덕션에 있어요

2025년 7월, HumanLayer 팀은 완전 lights-off 로 갔어요. 티켓만 읽고, 스펙만 쓰고, 나머지는 백그라운드 에이전트에게 전부 맡기는 방식. 4개월이 지난 11월, 세 번째 심각한 장애를 겪은 뒤 공동창업자가 결심해요 — 다시 짜자. VS Code 를 켜고 (Cursor 도 아니고 그냥 VS Code) 2주 동안 손으로 패턴을 다시 배선했어요.

이야기가 낯설지 않다면 계속 읽어주세요. 요즘 국내에서 코딩 에이전트로 수직 SaaS 를 짓는 빌더들을 매주 만나는데, 비슷한 벽에서 멈춰요. 처음 두 달은 마법 같고, 그 다음 두 달은 이상하게 느려지고, 5~6개월째에는 자기가 만든 코드베이스를 자기가 못 읽어요.

이건 “AI 가 위험하다”는 얘기가 아니에요. 저도 여전히 에이전트로 코드를 짜요. 다만 프로덕션 코드베이스에서는 리뷰 단계의 사람을 빼면 안 된다는 게 지난 1년의 결론이에요. 왜 그런지, 그리고 월요일 아침에 무엇을 바꿔야 하는지 순서대로 짚어볼게요.

리뷰가 새로운 병목이에요

1968년 NATO 컨퍼런스가 말한 소프트웨어 공장의 뼈대는 단순해요. 사람이 무엇을 만들지 정하고 → 티켓에 넣고 → 누군가 짜고 → PR 리뷰 → 배포 → 모니터링 → 유저 피드백 → 다시 티켓. 이 루프가 공장이에요.

2022년까지 병목은 “짜는 시간”이었어요. 하루 이틀. 코딩 에이전트가 오면서 짜는 시간은 분·시간 단위로 줄었고, 병목은 리뷰로 옮겨갔어요. 사람이 코드를 읽고 이해하고 판단하는 시간 말이에요. Ramp, Stripe, WorkOS, Brex 같은 회사들이 코드의 75% 를 에이전트로 출하한다고 말할 때, 사실상 승부처는 “얼마나 빨리 짜느냐”가 아니라 “리뷰 파이프라인을 어떻게 설계했느냐”에 있어요. 자동 리뷰 봇, 회귀 테스트 에이전트, 샌드박스, 롤아웃 툴 — 전부 리뷰 병목을 뚫으려는 장치들이죠.

여기까지는 자연스러운 진화예요.

Lights-off 의 유혹 — “그럼 사람 리뷰도 빼면?”

문제는 그 다음이에요. 리뷰 파이프라인을 자동화할수록 이런 말이 나와요. “자동 리뷰가 이 정도면 사람이 굳이 코드를 읽어야 해?” Dan Shapiro 가 lights-off software factory 라고 부른 상태예요. 불이 꺼진 공장 — 아무도 코드를 읽지 않는 공장.

겉으론 매끈해 보여요. 큐에 이슈를 밀어넣고, 에이전트가 짜고, 자동 테스트가 돌고, PR 이 자동 머지되고, 유저 버그 리포트도 큐로 자동 라우팅. 새벽 3시에 서버가 죽어도 알람 대신 이미 고쳐진 PR 이 도착해 있어요.

현실에선 오래 가지 않아요. 정확히는 3~6개월 동안은 잘 돌아가는 것처럼 보여요. 그리고 어느 날 도메인 임계 로직에서 이상한 버그가 터지는데, 그 코드를 짠 사람이 아무도 없어요. 두 가지 장면을 떠올려볼게요.

시나리오 A. BIM 자동화 툴을 짜는 국내 AEC 스타트업. 지오메트리 계산 모듈이 있는데, 지난 4개월 동안 에이전트가 이 모듈을 리포트 생성기, 도면 익스포터, 충돌 검사기 세 곳에 소리 없이 결합해놨어요. 아무도 이 커플링을 리뷰한 적 없어요. 어느 날 지오메트리 계산의 부동소수점 처리를 살짝 고쳤는데, 세 시스템이 다 깨져요. 에이전트한테 고쳐달라고 하니까 세 시스템을 각각 임시로 패치하고 커플링은 그대로 남겨요. 3주 뒤 또 터져요.

시나리오 B. 국내 어느 백엔드 팀이 새벽 인시던트를 에이전트 큐로 자동 라우팅하기 시작했어요. 두 달간 잘 돌아가는 듯 보였는데, 결제 관련 회귀가 자동 테스트를 통과해서 프로덕션에 올라가요. 유저 CS 폭주. 코드를 열어보니 팀 누구도 읽어본 적 없는 5000줄. 일주일 동안 파일을 손으로 뒤져요.

이 상태를 HumanLayer 팀은 “claude 스파게티”라고 불러요. 표현이 정확해요.

3~6개월 — 코드베이스가 썩는 속도

전통적으로 “brownfield” 는 10년 된 자바 시스템 같은 걸 뜻했어요. 요즘 에이전트로 짠 코드베이스는 3~6개월이면 이미 brownfield 에요. 손대기 무서운 상태.

왜 이렇게 빠를까요? 두 가지 이유예요.

첫째, 에이전트는 새 기능을 붙일 때 기존 구조를 이해하기보다 복사·붙여넣기·유사한 로직 하나 더 만들기를 선호해요. 리뷰가 없으니 걸러지지 않아요. 3개월 뒤 같은 로직이 7개 파일에 미묘하게 다른 버전으로 존재해요. Martin Fowler 가 shotgun surgery 라고 부른 안티패턴이에요 — 한 가지 변경을 하려면 여러 파일을 다 건드려야 하는 상태.

둘째는 더 근본적이에요. 모델은 아키텍처 품질을 판단할 능력이 없어요. 정확히는, 좋은 설계와 나쁜 설계를 안정적으로 구분할 수 있었다면 애초에 좋은 설계로 짰겠죠. 유지보수성엔 즉시적인 오라클이 없어요. 테스트는 초 단위로 피드백이 오지만, 나쁜 아키텍처의 비용은 몇 주, 몇 달 뒤에 청구서로 도착해요.

벤치마크가 유지보수를 채점하지 않아요

지난 1년간 가장 조용하지만 큰 문제였어요. Claude Code 가 1년 만에 매출 $9B 근처로 간 이유는 Anthropic 이 자기가 팔 도구 (read, write, edit, grep, bash) 바로 그 harness 안에서 모델을 RL 했기 때문이에요. 즉, 모델이 특정 도구를 잘 부르도록 가중치를 조정했어요. 큰 도약이었어요.

문제는 RL 의 채점 방식이에요. SWE-bench Multilingual 같은 대표 벤치마크를 보면 채점 기준은 두 개예요.

• FAIL_TO_PASS — 요청받은 걸 고쳤냐?
• PASS_TO_PASS — 다른 걸 안 깼냐?

딱 이 두 가지예요. 예를 들어 fastlane 의 zip action 이슈를 풀 때, 인간이 짠 정답은 nil 을 [] 로 기본값 처리하는 두 줄짜리 diff 예요. 그런데 모델이 만약 이 문제를 15개 다른 파일에 방어 코드를 뿌려서 해결했다고 쳐요. 테스트만 통과하면 만점이에요. 커플링을 늘렸다는 페널티가 없어요.

즉, 우리가 쓰는 모든 코딩 에이전트는 테스트를 통과시키는 데 최적화됐지, 유지보수성 있는 코드를 짜도록 최적화된 적이 없어요. 이건 모델 크기나 세대 문제가 아니에요. 채점 신호 자체에 유지보수라는 축이 없어요.

“모델이 좋아졌으니 이제 괜찮지 않을까?” 라는 질문엔 이렇게 답해요. 일회성 문제 풀기, 새 프로토타입 만들기 — 훨씬 좋아졌어요. 6개월 된 프로덕션 코드베이스의 품질을 유지하며 기능을 붙이기 — 여전히 어려워요. 그리고 이걸 측정할 벤치마크가 아직 없어요.

Front-load — 코딩 전에 정렬하세요

해법은 AI 이전부터 있었어요. 시니어 엔지니어 팀들은 오래전에 깨달았죠. 짜는 데 며칠, 리뷰하는 데 며칠 걸리니 먼저 정렬하자 — 아키텍처 제안서, 스프린트 플래닝, RFC. 코드가 써지기 전에 팀이 방향을 맞추면 리워크가 줄고, 리뷰가 빨라져요. 잘 쓴 긴 PR 을 리뷰해본 적 있다면 알 거예요. 정렬이 되어 있으면 리뷰가 몇 배 빨라져요.

에이전트 시대엔 이게 더 중요해요. 정렬이 없으면 에이전트는 아무 방향으로나 빠르게 가거든요. 잘못된 방향으로 이틀치 코드를 쌓아오는 게 지금 가장 흔한 실패예요.

구체적인 실천안 세 가지예요.

하나, PR 전에 architecture proposal 을 강제하세요. 에이전트에게 코딩을 시키기 전에 사람이 “이 기능은 이 모듈에 붙고, 이 인터페이스로 노출되고, 이런 코너 케이스가 있어”를 문서로 써서 넘겨요. 이 문서가 프롬프트의 일부가 돼요.

둘, 리뷰의 사람 체크포인트를 최소 하나는 남기세요. 자동 리뷰 봇을 다 붙여도 좋아요. 그런데 도메인 임계 로직(AEC 라면 구조 계산·간섭 검사, 핀테크라면 정산·이자 계산)에는 사람이 최종 승인을 찍는 규칙을 코드베이스 레벨로 넣어요. CODEOWNERS 파일이나 required reviewer 로.

셋, 3개월마다 코드베이스 감사를 스케줄에 박으세요. 팀원 한 명이 이틀 동안 최근 3개월치 에이전트 PR 중 20개를 무작위로 골라 읽어요. 이해 안 되는 코드가 30% 를 넘으면 lights-off 를 잠깐 끄고 리팩터링에 시간을 써요.

월요일 아침, 이걸 해보세요

이번 주에 딱 한 가지만 한다면 이거예요. 지금 팀의 코드베이스에서 최근 30일간 에이전트가 짠 PR 중 5개를 무작위로 뽑아 직접 읽어보세요. 30분씩, 총 2시간 반.

두 가지 질문을 던지세요.

1. 이 PR 이 왜 이 파일들을 건드렸는지 5분 안에 설명할 수 있나?
2. 이 로직에 지금 프로덕션 장애가 나면 내가 고칠 수 있나?

둘 중 하나라도 “아니오”인 PR 이 3개 이상이면, 공장은 이미 불이 꺼져 있어요. 아직 3개월 안이라면 지금 리뷰 체크포인트를 다시 넣을 때예요. 6개월이 지났다면 — HumanLayer 팀처럼 2주짜리 재작성 스프린트를 슬랙 캘린더에 잡을 시간이 온 걸 수도 있어요.

에이전트는 계속 쓰세요. 저도 계속 써요. 다만 공장의 조명은 켜두세요. 그게 3개월 뒤 팀에 돌아올 가장 큰 선물이에요.