소프트웨어 팩토리는 컨텍스트 수집·행동·검증을 반복하는 루프를 하네스로 감싸 대규모로 운영하며, 인간이 판단하는 밝은 팩토리와 코드 검토까지 기계에 맡기는 다크 팩토리로 나뉨

• 코드 생성·테스트·스캔은 거의 비용 없이 확장되지만 인간의
  검토와 판단은 확장하기 어려워, 생성량보다 결과를 저렴하고 신뢰성 있게 검증하는 속도가 병목이 됨
• 사람이 코드를 읽지 않으면 코드 규모와 인간의 이해 사이에
  이해 부채(comprehension debt) 가 쌓이며, 테스트가 계속 통과해도 장기간 운영한 복잡한 시스템에서는 유지보수 문제가 뒤늦게 나타날 수 있음
• 완전 자동화는 즉각적이고 드리프트하지 않으며 조작하기 어려운 판정 기준을 갖춘 짧은 루프에만 허용하고, 인증·결제·공개 API처럼 잘못된 결정의 비용과 영향 범위가 큰 작업에는 사람의 검토를 유지해야 함
• 엔지니어의 역할은 개별 변경을 직접 작성하는 데서
  외부 루프를 설계하고 지키는 일로 이동하며, 에이전트가 수행한 진단·구현·테스트의 증거를 검증하고 승인과 결과에 책임져야 함

루프에서 소프트웨어 팩토리까지

• 소프트웨어를 반복 가능하고 계측 가능한 생산 공정으로 만들려는 발상은 Bob Bemer가 1968년 발표한 「The economics of program production」까지 거슬러 올라감

• 아이디어를 자동차 부품처럼 찍어내기 어려웠기 때문에 지난 반세기 동안 이러한 시도는 대체로 기대에 미치지 못함

• 최근 2년간의 변화는 오래된 소프트웨어 팩토리 구상을 다시 검토할 만큼 컸지만, 과거의 함정이 새로운 기회처럼 포장될 수 있음

• 전체 체계는
  루프·하네스·팩토리라는 세 계층으로 구성됨

• 루프는 하나의 에이전트가 컨텍스트를 모으고 행동한 뒤 결과를 확인하며, 종료 조건을 충족할 때까지 반복하는 최소 작업 단위임

• 루프 엔지니어링은 사람이 매번 프롬프트를 입력하는 대신 에이전트에 프롬프트를 제공하는 작은 시스템을 설계하는 방식임

• 하네스는 루프가 실행되는 샌드박스, 사용할 수 있는 도구, 실행 사이에 유지되는 메모리, 완료 여부를 판단하는 게이트를 포함함

• 하네스 없는 모델은 끝없이 반복할 수 있으므로, 하네스가 루프를 유용하고 안전하게 만듦

• 소프트웨어 팩토리는 작업 큐에서 항목을 받아 여러 하네스 기반 루프를 동시에 실행하고, 검토 게이트를 거쳐 프로덕션으로 내보내는 구조임

• 더 큰 단일 에이전트가 아니라
  루프로 구성된 조직도에 가까움

• 엔지니어의 작업 단위도 개별 코드 변경에서 루프, 하네스, 루프 사이의 흐름으로 이동함

팩토리의 작업 흐름과 병목

• 엔지니어링 리더십의 비전, 엔지니어의 의도, 장애와 사용자 요청에서 나온 신호가 하나의
  작업 큐로 들어감

• 하네스가 항목을 선택해 변경을 만들고, CI·테스트·정적 분석·각종 스캔이 변경을 동시에 검사함

• 검토 게이트가 승인하면 변경을 배포하고, 프로덕션 모니터링 데이터는 다시 작업을 촉발하는 신호로 돌아감

• 생성·테스트·스캔은 무시할 만한 비용으로 확장할 수 있지만,
  검토 게이트의 인간 판단은 확장하기 어려움

• 개발 속도와 배포 빈도를 높일 수 있는지는 이 판단 병목을 어떻게 다루는지에 달려 있음

다크 팩토리와 이해 부채

• 제조업의 다크 팩토리는 기계가 조명을 필요로 하지 않아 불을 끈 채 운영되는 시설임
  다크 소프트웨어 팩토리에서는 사람이 코드를 읽지 않고, 코드를 만든 기계가 수행한 검증만으로 변경을 배포함

• 여기서 어둠은 부정적인 분위기가 아니라, 사람이 diff를 작성·검토·배포하는 과정에서 사라졌다는 뜻임

• 인간 검토를 제거하면 방해 요소가 사라져 팀의 수직 처리량이 급격히 높아진 것처럼 느껴짐

• 그러나 감춰진 비용 때문에 이런 작업 흐름을 장기간 유지하기는 겉보기보다 어려움

• 오케스트레이션, 샌드박스 기반 프로토타이핑, 도구 호출은 계속 강력해지겠지만 하네스만으로 장기적인 코드베이스 품질을 유지하기에는 부족함
  이해 부채는 존재하는 코드의 양과 인간이 실제로 이해하는 코드의 양 사이의 격차임

• 다크 팩토리는 테스트가 통과하는 동안에도 이해 부채를 빠르게 쌓음

• 작은 코드 영역의 즉각적인 변경이나 주말 프로젝트와 달리, 10년 이상 개발된 복잡한 기존 시스템은 전문적인 속도로 계속 유지해야 함

• 자동화 프로젝트를 3~6개월 운영하면 읽지 않은 코드에 압도될 수 있음

• Dex Horthy가 약 4개월 동안 인간이 생성 코드를 보지 않는 완전 자동화 팩토리를 운영했을 때, 문제의 원인을 찾으려면 고된 수동 디버깅이 필요했음

• 토큰 사용량을 극대화할수록 사람이 시스템을 이해하는 정도는 조용히 감소함

• 실패는 테스트가 통과하던 시스템 전체가 갑자기 무너지는 대신
  늦고 조용하게 찾아올 수 있음

생성보다 검증이 제약이 되는 이유

백프레셔(back pressure) 는 저렴하고 신뢰성 있게 검증할 수 있는 범위까지만 루프에 자율성을 주는 원칙임

• 무제한에 가까운 생성 능력과 유한한 인간의 주의력 사이의 격차가 핵심 문제임

• 검증 구간이 넓어지지 않으면 변경이 쌓이며, 신뢰할 수 있는 게이트 없이 양만 늘리면 품질 낮은 PR과 제조된 결함이 생김

• 모델 성능 향상이 생성과 검증 사이의 간격을 자동으로 좁히지는 않음

• 좋은 아키텍처의 가치는 수초나 수분이 아니라 수개월과 수년에 걸쳐 드러남

• 아키텍처 우수성을 위한 깔끔한 비용 함수나 즉각적인 평가 신호를 계산하기 어려워, 복잡한 설계 결정을 좋은 사례로 훈련하기도 어려움

다시 불을 켜는 방법

밝은 팩토리에서도 에이전트가 구현 대부분을 담당하지만, 잘못된 판단의 비용이 큰 지점에는 조명을 켜고 사람이 산출물을 읽은 뒤 배포함

• 인간 판단은 마지막 코드 리뷰에만 붙이지 않고, 에이전트가 루프를 시작하기 전 제품·설계·아키텍처 단계로 옮겨야 함

• 사전에 1시간 동안 200줄짜리 계획을 검토하면, 구현 후 2,000줄의 생성 코드를 뒤져 설계 결정을 찾는 긴 리뷰를 줄일 수 있음

• 비용이 크고 오래 지속되는 결정일수록 구현 전에 사람이 참여해야 하며, 사전 검토를 했더라도 필요하면 diff를 직접 확인함

• 안전망은 새로운 기법이 아니라 익숙한
  아키텍처 관행으로 구성됨

• 좋은 타입과 메서드 시그니처로 오류를 프로덕션 대신 컴파일러에서 포착함

• 테스트 접점(seam)을 두어 동작을 고정하고 변경을 관찰할 수 있게 만듦

• 사람과 모델 모두 필요한 코드를 쉽게 찾도록 배치함

• 호출 스택을 짧고 읽기 쉽게 유지함

• 컴포넌트 경계를 명확히 해 변경의 영향 범위를 제한함

• 의존성 주입으로 구성 요소를 교체할 수 있게 함

• 이러한 아키텍처는 자동 코딩 에이전트의 실수를 저렴하고 속이기 어려운 방식으로 막는 두 번째 역할을 수행함

• Claude Code와 Codex 같은 에이전트는 자체 하네스와 도구 사용에는 강화학습돼 있지만, 장기 유지보수성까지 제공하지는 않음

• 안전망은 모델 바깥에 존재해야 하며, 아키텍처 투자는 더 많은 자율성을 안전하게 확보하는 수단이 됨

• 안전한 인프라와 결합하면 일부 짧고 위험이 낮은 루프는 무인으로 실행할 수 있음

• 예를 들어 매일 밤 GitHub Actions cron이 안티패턴, 린트 위반, 불필요하게 선택 사항인 prop 중 정확히 하나를 고쳐 커밋하고 작은 PR 하나를 열 수 있음

• 인증 시스템, 결제 엔진, 공개 API 계약처럼 실패 비용이 큰 대상은 사람이 시스템 지식과 판단으로 검토해야 함

자동화 자격을 얻는 루프

• 루프가 완전 자동화되려면 검사가
  저렴하고 빈번하게 실행되며 쉽게 속일 수 없는 기준에 의존해야 함

• 참·거짓을 명확히 반환하는 판정기, 타입 게이트, 속성 기반 테스트, 실제 평가 기준표와 결합한 검토 에이전트가 해당됨

• 판정은 즉시 나와야 하고 시간이 지나도 드리프트하지 않아야 함

• 완료 상태를 사람이 아니라 기계도 증명할 수 있을 때 자동화할 수 있음

• 짧은 루프는 긴 루프보다 검증하기 쉬움

• Dex의 경험칙에 따르면 에이전트는
  3~10단계에서는 잘 작동하지만 20단계를 넘으면 흐름을 잃기 시작함

• 컨텍스트가 누적될수록 에이전트가 경로를 벗어날 가능성이 커지며, 긴 루프는 구석에 오류를 숨김

• 잘못된 답의 비용이 크고 사람만 이를 발견할 수 있다면 불을 켜야 함

• 테스트로 잡히지 않는 미묘한 프로덕션 버그, 넓은 영향 범위, 1년 이상의 작업을 좌우하는 결정이 해당됨

• 이런 경우 인간의 주의력이 실제 제품이자 비싸지만 필수적인 자원임

• 모든 루프를 같은 모드로 설정하면 양쪽 모두 실패함

• 전부 어둡게 운영하면 몇 달 뒤 시스템을 해체해야 할 수 있음

• 전부 밝게 운영하면 리뷰가 거대한 병목이 됨

• 각 루프에서 어느 지점에 조명을 켤지 결정하는 일이 핵심 기술임

루프를 감싸는 그래프와 상태 머신

• 에이전트 작업은 유한 상태 머신이나 조건부 서비스 호출로 부르더라도 결국
  방향 그래프로 구성될 가능성이 큼

• 각 노드는 명시적 단계이고, 노드 사이의 간선은 명시적 조건임

• 모든 코드는 제어 흐름 그래프로 나타낼 수 있으므로 구조 자체는 새롭지 않음

• 에이전트의 자율성은 그래프 전체가 아니라 각 노드 내부로 제한됨

• 새로운 시도는 흐름도를 없애고 모델이 도구 호출마다 경로를 선택하다가 스스로 완료를 선언하게 만든 것이었음

• 오래된 코드베이스와 부딪힌 뒤 제어 흐름을 다시 소유하려는 움직임은 루프 주위에 기존 그래프를 복원하는 것과 같음

• 버그 수정 작업은 순수 루프와 그래프에서 다르게 진행됨

• 순수 루프에서는 문제 조사, 코드 변경, 테스트 선택과 실행 순서, 재시도와 완료 판단을 진행 중에 모두 결정함

• 그래프에서는 버그 재현 또는 추가 정보 요청, 원인 파악, 수정, 테스트, 검토를 미리 경로로 정의함

• 테스트 실패는 수정 단계로 돌아가고, 성공은 검토로 이동하며, 승인된 경우에만 완료됨

• 에이전트는 각 노드 안에서 지능적으로 행동하지만 허용되지 않은 경로로 이탈할 수 없음

• 그래프는
  백프레셔를 시각화한 형태임

• 에이전트의 자유 일부를 포기하는 대신 필수 검사와 읽을 수 있는 실패 지점을 얻음

• 실행이 실패하면 어느 노드가 중단시켰는지 식별할 수 있음

• 12-factor agents의 접근처럼 많은 에이전트 시스템은 “적절한 지점에 LLM 단계를 섞은 대부분 결정론적인 코드”에 가까움

• LangGraph와 LlamaIndex Workflows, Jerry Liu의 에이전트 위 하이브리드 작업 흐름 그래프, David Khourshid가 연결한 상태 머신과 액터 모델에서도 같은 패턴이 나타남

• 여기서 그래프는 지식 그래프가 아니라 작업 흐름과 조건부 간선을 미리 정의한
  방향 그래프를 뜻함

인간은 외부 루프를 소유함

• 인간은 팩토리에서 사라지는 대신 실행 라인에서
  외부 루프로 이동함

• 에이전트는 버그 조사, 진단 작성, 수정 구현, 테스트 실행, 결과 보고라는 내부 루프를 수행함

• 엔지니어는 문제를 올바른 방식으로 해결하는지 판단하고, 진단과 구현을 검증하며, 변경을 승인하고 잘못된 결과에 책임짐

• 내부 루프와 외부 루프의 경계에는 diff, 테스트, 로그, 이를 연결하는 짧은 해설 같은
  증거가 놓임

• 타입, 테스트 접점, 평가 기준표를 갖추면 변경마다 많은 수작업을 하지 않고도 에이전트 실행을 감독할 수 있음

• 엔지니어의 위치는 생산 라인에서 변경을 직접 작성하는 자리에서 라인을 설계하고 게이트를 지키는 자리로 이동함

• 모델과 하네스는 개선할 수 있지만 장기적으로 비싼 문제를 식별하는 인간 판단까지 자동화하기는 어려움

• 모든 작업 공간을 어둡게 만들어 사람이 무엇이 진행되는지 확인하거나 조명 스위치조차 찾지 못하는 상태가 가장 위험함

댓글과 토론