AI 코딩을 프로덕션에 투입하려는 경쟁이 뜨겁다. 흔히 나오는 처방은 "루프를 더 많이 돌려라"는 것이다. 에이전트가 코드를 쓰고, 봇이 리뷰하고, 린터가 검사하는 자동화 파이프라인을 겹겹이 쌓으면 사람이 개입하지 않아도 소프트웨어가 알아서 만들어진다는 그림이다. StrongDM은 사람이 코드를 읽지도 쓰지도 않는 '불 꺼진 소프트웨어 공장(lights-off factory)'을 공유했고, OpenAI의 라이언 로포폴로는 사내 소프트웨어 공장 'Symphony'를 소개했다. HumanLayer를 운영하는 글쓴이 Dex는 이 흐름을 존중하면서도, 하네스(harness) 엔지니어링만으로는 풀 수 없는 근본 문제가 있다고 주장한다. 스스로도 편향이 있을 수 있음을 인정하면서 던지는 이야기다.
속도의 대가
경고 신호는 이미 나오고 있다. AI 엔지니어 유럽 콘퍼런스에서 마리오는 코딩 에이전트 사고로 장애를 낼 이유가 없는 기업들이 실제로 장애를 겪고 있다며 속도를 늦추자고 호소했다. 맷 포콕은 코드베이스가 그 어느 때보다 빨리 무너지고 있다고 표현했다. Faros AI 보고서는 올해 초 다들 AI 코딩 도구를 집어든 이후 풀 리퀘스트 리뷰 품질이 크게 떨어졌다고 지적한다. 글쓴이는 이 보고서가 인과의 결정적 증거가 아니라 상관 신호에 가깝다고 선을 그으면서도, 방향성만큼은 자신이 목격한 것과 맞아떨어진다고 본다.
이런 지적에 흔히 돌아오는 답이 "실력 문제"다. 결과가 안 나오면 당신이 아직 잘 다루지 못하는 것이고, 토큰을 더 쓰고 코드 읽기를 놓아버리면 된다는 식이다. 글쓴이는 자신도 지난여름 그렇게 생각했고 관련 발언이 유튜브에서 수백만 조회를 얻기도 했다며, 오랫동안 이 주제를 파고든 사람으로서 이제는 생각이 다르다고 말한다. 핵심 주장은 단순하다. 아무리 린터를 붙이고 리뷰 봇에 '적대적 리뷰' 같은 주문을 뿌려도, 이것은 본질적으로 모델 학습의 문제이지 하네스로 덮을 수 있는 문제가 아니라는 것이다.
불 꺼진 공장의 실패
소프트웨어 공장이라는 개념 자체는 새롭지 않다. 용어의 기원은 '소프트웨어 엔지니어링'을 낳은 1968년 NATO 콘퍼런스까지 거슬러 올라간다. AI 이전에도 공장에는 계획, 아키텍처 제안, 스프린트 계획 같은 여러 루프가 있었다. 빌드도 리뷰도 몇 시간에서 며칠이 걸리기에 팀은 작업을 앞단으로 몰아 함께 설계했다. 여기에 에이전트가 들어오면 '사람이 만드는' 자리를 '에이전트가 만드는' 자리로 바꾼 형태가 되고, 이제 병목은 리뷰로 옮겨간다. 그다음 단계로 장애 대응과 사용자 피드백까지 큐에 밀어 넣으면, 남는 질문은 '얼마나 많이 시킬 수 있는가'와 '얼마나 빨리 리뷰·테스트할 수 있는가' 둘뿐이다. 불 꺼진 공장은 여기서 거슬리는 코드 리뷰 단계마저 걷어낸 형태다.
글쓴이의 팀은 2025년 7월 완전한 불 꺼진 방식으로 전환했다. 스펙과 티켓만 읽고 자잘한 작업은 전부 백그라운드 에이전트에 맡겼다. 결말은 예상 가능한 방식으로 왔다. 아무리 정교한 프롬프트와 워크플로를 써도 에이전트가 풀지 못하는 고약한 문제가 결국 하나는 나왔고, 석 달 동안 읽지 않은 코드베이스를 파고들어 무엇이 망가졌는지 찾아야 했다. 첫 번째는 속도를 위해 감수할 만한 하방 리스크라고 넘겼지만, 11월 세 번째로 같은 일을 겪자 차라리 처음부터 다시 짜는 게 낫다고 판단했다. 공동창업자는 커서도 아닌 VS Code에서 꼬박 2주간 패턴을 손으로 다시 정리했다.
유지보수성은 벤치마크에 없다
여기서 드러나는 모델의 약점은 유지보수성이다. 마틴 파울러가 말한 '샷건 수술(shotgun surgery)', 즉 한 부분을 고치려면 다른 부분이 줄줄이 깨지는 상태를 모델은 사람의 상당한 방향 제시 없이는 시간이 지나며 좋게 유지하지 못한다. 오히려 시간이 갈수록 코드베이스를 더 다루기 어렵게 만드는 경향이 있다. 문제는 이를 증명할 방법조차 마땅치 않다는 점이다. 모델이 코드 품질을 유지하는 능력을 재는 좋은 벤치마크가 없기 때문이다. 에이전트가 만든 코드베이스는 이제 3~6개월이면 브라운필드처럼 삐걱대기 시작하고, 새 기능을 붙이는 방식 자체를 바꿔야 하는 순간이 온다.
왜 모델은 유지보수를 못할까. 글쓴이는 답을 학습 방식에서 찾는다. Claude Code가 1년도 안 되어 수십억 달러 규모로 커진 배경으로 통용되는 설명은, Anthropic이 실제로 출시할 도구 세트 안에서 모델을 강화학습(RL)시킨 첫 사례라는 점이다. read, write, edit, grep, bash 같은 도구는 aider나 cline 등 앞선 CLI 에이전트에도 있었지만 도구 호출이 종종 실패했다. 가중치를 소유하고 모델 자체를 특정 도구에 맞게 다듬는 것은, 도구 정의만 만지작거리는 것과는 차원이 다른 게임이다. OpenAI 팀도 하네스를 만들되 가중치를 소유하지 못하면 둘 다 가진 팀에 늘 밀린다고 지적했다.
그런데 그 학습의 채점 방식이 지나치게 일차원적일 수 있다. SWE-bench 같은 벤치마크의 과제는 Redis, jq, Django 같은 오픈소스 저장소에서 긁어온 약 15분짜리 작은 문제들이고, 보상은 테스트 통과 여부에 따른 1 또는 0이다. 예컨대 fastlane의 한 이슈는 옵션 파라미터에 곧바로 .empty?를 호출해 인자를 빼면 터지는 문제로, 정답 패치는 nil을 빈 배열로 바꾸는 두 줄짜리다. 이런 좁은 정오답 채점은 '동작하느냐'는 판단할 수 있어도 '이 변경이 코드베이스를 장기적으로 건강하게 유지하느냐'는 담아내지 못한다. 결국 하네스를 아무리 정교하게 다듬어도, 모델이 학습 단계에서 유지보수성을 보상받은 적이 없다면 그 능력은 저절로 생기지 않는다. 바이브 코딩이 즐겁다면 계속해도 좋지만, 복잡한 코드베이스에서 오래 굴러가는 프로덕션 소프트웨어를 다루는 이들에게 이 구분은 실무적으로 중요하다.