자동 코딩 공장, 어디까지 맡길 수 있을까 | DAKER 커뮤니티
밤새 돌아간 자동화가 아침이면 pull request를 쌓아 두는 장면은 분명 매력적입니다. 다만 초록 체크가 많아질수록, 정작 누가 diff를 읽고 무엇을 이해했는지는 더 흐려지기 쉽습니다.
Addy Osmani가 소프트웨어 공장을 밝은 공장과 어두운 공장으로 나눠 설명한 이유도 여기에 있습니다. 지금 중요한 질문은 에이전트가 코드를 얼마나 빨리 쓰느냐가 아니라, 그 속도를 사람이 이해 가능한 검증 속도 안에 둘 수 있느냐입니다.
자동화의 한계는 생성 속도가 아니라 검증 비용과 검증 속도에서 드러납니다.
소프트웨어 팩토리라는 개념
오스마니가 말하는 소프트웨어 팩토리는 하나의 에이전트 루프를 하네스로 감싸고, 그런 루프 여러 개를 작업 큐와 리뷰 게이트에 연결해 코드 생산 공장처럼 움직이게 하는 구조입니다. 여기서 밝은 공장은 사람이 설계, 리뷰, 승인 지점에 남아 있는 형태이고, 어두운 공장은 기계가 만든 코드를 기계 검사만으로 계속 흘려보내는 형태를 가리킵니다.
이 구분의 핵심은 단순히 자동화 수준이 아닙니다. 생성은 빠르고 싸지만, 사람의 주의력은 느리고 비쌉니다. 그래서 실제 병목은 코드 작성이 아니라 검증에서 생기고, 그 병목이 커질수록 back pressure가 쌓입니다.
언제 이런 구조가 유용한가
Claude Code나 Codex로 여러 작업을 병렬 처리하고 싶을 때 이 개념이 특히 잘 맞습니다. 예를 들어 lint 자동 수정, 작은 타입 오류 수정, 문서 링크 검사처럼 판정이 싸고 즉시 가능한 작업은 자동화 후보가 됩니다.
반대로 인증, 결제, 공개 API 계약, 장기 아키텍처 결정처럼 틀렸을 때 비용이 큰 작업은 사람이 불을 켠 상태로 설계와 리뷰 지점에 서 있는 것이 좋습니다. 이런 영역에서는 마지막 diff만 보는 방식으로는 늦을 수 있습니다.
자동화 여부는 얼마나 많이 만들 수 있느냐보다 얼마나 싸고 안정적으로 검증할 수 있느냐로 정하는 편이 맞습니다.
루프, 하네스, 리뷰 게이트의 관계
루프는 최소 작업 단위입니다
루프는 한 에이전트가 맥락을 모으고, 행동하고, 결과를 검사한 뒤 조건이 맞을 때까지 반복하는 최소 단위입니다.
하네스는 루프의 경계입니다
하네스는 그 루프를 둘러싼 벽입니다. 샌드박스, 도구, 메모리, 완료 게이트가 여기에 포함되고, 이 경계가 있어야 루프가 쓸모 있고 안전하게 작동합니다.
팩토리는 여러 루프를 연결한 구조입니다
소프트웨어 팩토리는 더 똑똑한 단일 에이전트 하나를 뜻하지 않습니다. 여러 하네스 루프가 작업 큐에서 일을 받아 처리하고, 하나의 리뷰 게이트로 빠져나오는 구조에 가깝습니다.
비유하자면 에이전트 루프는 컨베이어벨트입니다. 그런데 검증 게이트가 좁은데 벨트만 빠르게 돌리면, 창고에 쌓이는 것은 생산성이 아니라 읽지 못한 diff가 됩니다.
적용할 때 먼저 봐야 할 기준
실무에서는 반복 작업 하나를 고르고, 그 작업이 실패했을 때 비용이 얼마나 큰지부터 나눠 보는 것이 좋습니다. 작은 스타일 수정인지, 데이터 손상 가능성이 있는 변경인지에 따라 자동화의 범위가 달라집니다.
그다음에는 판정 오라클을 정해야 합니다. 타입 검사, 단위 테스트, 속성 테스트, 스냅샷, 링크 검사처럼 초록과 빨강으로 답할 수 있는 기준이 있어야 루프를 짧고 안정적으로 운영할 수 있습니다.
검증이 싸고 즉시 가능하다면 Claude Code 루프를 짧게 두면 됩니다. 한 번에 하나의 anti-pattern, 하나의 lint 위반, 하나의 문서 누락만 맡기는 식이 적합합니다.
반대로 검증이 비싸거나 사람의 판단이 필요한 작업이라면, 시작 전에 설계, 아키텍처, 제품 결정 리뷰를 두는 편이 낫습니다. 마지막 diff 리뷰만으로는 중요한 판단을 놓치기 쉽습니다.
실행 뒤에는 변경 요약, 테스트 결과, 남은 위험, 사람이 실제로 읽은 지점을 기록해 두는 것이 좋습니다. 이 기록은 다음 루프에서 back pressure를 판단하는 기준이 됩니다.
결국 꺼야 할 불과 켜 두어야 할 불
자동 코딩 공장의 매력은 분명합니다. 하지만 모든 불을 끈 채로 속도만 높이면, 생산량이 아니라 검증되지 않은 변경이 쌓일 수 있습니다. 그래서 중요한 것은 자동화를 더 세게 거는 일이 아니라, 어디까지는 기계에 맡기고 어디부터는 사람이 outer loop에 남아야 하는지 구분하는 일입니다.
어두운 공장의 위험은 코드 생성 자체보다 사람이 이해하지 못한 변경이 시스템 안으로 들어오는 데 있습니다.
참고 자료
여러분은 자동화된 코드 생성에서 어느 지점까지는 불을 꺼도 된다고 보시나요?