# 소프트웨어 팩토리, 빛과 어둠 > Clean Markdown view of GeekNews topic #31731. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31731](https://news.hada.io/topic?id=31731) - GeekNews Markdown: [https://news.hada.io/topic/31731.md](https://news.hada.io/topic/31731.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-23T21:45:57+09:00 - Updated: 2026-07-23T21:45:57+09:00 - Original source: [substack.com/addyo](https://addyo.substack.com/p/software-factories-light-and-dark) - Points: 1 - Comments: 0 ## Topic Body - **소프트웨어 팩토리**는 컨텍스트 수집·행동·검증을 반복하는 루프를 하네스로 감싸 대규모로 운영하며, 인간이 판단하는 밝은 팩토리와 코드 검토까지 기계에 맡기는 다크 팩토리로 나뉨 - 코드 생성·테스트·스캔은 거의 비용 없이 확장되지만 인간의 **검토와 판단**은 확장하기 어려워, 생성량보다 결과를 저렴하고 신뢰성 있게 검증하는 속도가 병목이 됨 - 사람이 코드를 읽지 않으면 코드 규모와 인간의 이해 사이에 **이해 부채(comprehension debt)** 가 쌓이며, 테스트가 계속 통과해도 장기간 운영한 복잡한 시스템에서는 유지보수 문제가 뒤늦게 나타날 수 있음 - 완전 자동화는 즉각적이고 드리프트하지 않으며 조작하기 어려운 판정 기준을 갖춘 짧은 루프에만 허용하고, 인증·결제·공개 API처럼 잘못된 결정의 비용과 영향 범위가 큰 작업에는 사람의 검토를 유지해야 함 - 엔지니어의 역할은 개별 변경을 직접 작성하는 데서 **외부 루프**를 설계하고 지키는 일로 이동하며, 에이전트가 수행한 진단·구현·테스트의 증거를 검증하고 승인과 결과에 책임져야 함 --- ### 루프에서 소프트웨어 팩토리까지 - 소프트웨어를 반복 가능하고 계측 가능한 생산 공정으로 만들려는 발상은 [Bob Bemer](https://en.wikipedia.org/wiki/R._W._Bemer)가 1968년 발표한 「The economics of program production」까지 거슬러 올라감 - 아이디어를 자동차 부품처럼 찍어내기 어려웠기 때문에 지난 반세기 동안 이러한 시도는 대체로 기대에 미치지 못함 - 최근 2년간의 변화는 오래된 소프트웨어 팩토리 구상을 다시 검토할 만큼 컸지만, 과거의 함정이 새로운 기회처럼 포장될 수 있음 - 전체 체계는 **루프·하네스·팩토리**라는 세 계층으로 구성됨 - 루프는 하나의 에이전트가 컨텍스트를 모으고 행동한 뒤 결과를 확인하며, 종료 조건을 충족할 때까지 반복하는 최소 작업 단위임 - [루프 엔지니어링](https://addyosmani.com/blog/loop-engineering/)은 사람이 매번 프롬프트를 입력하는 대신 에이전트에 프롬프트를 제공하는 작은 시스템을 설계하는 방식임 - 하네스는 루프가 실행되는 샌드박스, 사용할 수 있는 도구, 실행 사이에 유지되는 메모리, 완료 여부를 판단하는 게이트를 포함함 - 하네스 없는 모델은 끝없이 반복할 수 있으므로, 하네스가 루프를 유용하고 안전하게 만듦 - [소프트웨어 팩토리](https://addyosmani.com/blog/factory-model/)는 작업 큐에서 항목을 받아 여러 하네스 기반 루프를 동시에 실행하고, 검토 게이트를 거쳐 프로덕션으로 내보내는 구조임 - 더 큰 단일 에이전트가 아니라 **루프로 구성된 조직도**에 가까움 - 엔지니어의 작업 단위도 개별 코드 변경에서 루프, 하네스, 루프 사이의 흐름으로 이동함 ### 팩토리의 작업 흐름과 병목 - 엔지니어링 리더십의 비전, 엔지니어의 의도, 장애와 사용자 요청에서 나온 신호가 하나의 **작업 큐**로 들어감 - 하네스가 항목을 선택해 변경을 만들고, CI·테스트·정적 분석·각종 스캔이 변경을 동시에 검사함 - 검토 게이트가 승인하면 변경을 배포하고, 프로덕션 모니터링 데이터는 다시 작업을 촉발하는 신호로 돌아감 - 생성·테스트·스캔은 무시할 만한 비용으로 확장할 수 있지만, **검토 게이트의 인간 판단**은 확장하기 어려움 - 개발 속도와 배포 빈도를 높일 수 있는지는 이 판단 병목을 어떻게 다루는지에 달려 있음 ### 다크 팩토리와 이해 부채 - 제조업의 다크 팩토리는 기계가 조명을 필요로 하지 않아 불을 끈 채 운영되는 시설임 - [FANUC은 2001년부터 이런 공장을 운영]()했고, Xiaomi도 2024년 고도로 자동화된 다크 팩토리를 열었음 - **다크 소프트웨어 팩토리**에서는 사람이 코드를 읽지 않고, 코드를 만든 기계가 수행한 검증만으로 변경을 배포함 - 여기서 어둠은 부정적인 분위기가 아니라, 사람이 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의 경험칙](https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-10-small-focused-agents.md)에 따르면 에이전트는 **3~10단계**에서는 잘 작동하지만 20단계를 넘으면 흐름을 잃기 시작함 - 컨텍스트가 누적될수록 에이전트가 경로를 벗어날 가능성이 커지며, 긴 루프는 구석에 오류를 숨김 - 잘못된 답의 비용이 크고 사람만 이를 발견할 수 있다면 불을 켜야 함 - 테스트로 잡히지 않는 미묘한 프로덕션 버그, 넓은 영향 범위, 1년 이상의 작업을 좌우하는 결정이 해당됨 - 이런 경우 [인간의 주의력이 실제 제품](https://addyosmani.com/blog/human-is-the-expensive-part/)이자 비싸지만 필수적인 자원임 - 모든 루프를 같은 모드로 설정하면 양쪽 모두 실패함 - 전부 어둡게 운영하면 몇 달 뒤 시스템을 해체해야 할 수 있음 - 전부 밝게 운영하면 리뷰가 거대한 병목이 됨 - 각 루프에서 어느 지점에 조명을 켤지 결정하는 일이 핵심 기술임 ### 루프를 감싸는 그래프와 상태 머신 - 에이전트 작업은 유한 상태 머신이나 조건부 서비스 호출로 부르더라도 결국 **방향 그래프**로 구성될 가능성이 큼 - 각 노드는 명시적 단계이고, 노드 사이의 간선은 명시적 조건임 - 모든 코드는 제어 흐름 그래프로 나타낼 수 있으므로 구조 자체는 새롭지 않음 - 에이전트의 자율성은 그래프 전체가 아니라 각 노드 내부로 제한됨 - 새로운 시도는 흐름도를 없애고 모델이 도구 호출마다 경로를 선택하다가 스스로 완료를 선언하게 만든 것이었음 - 오래된 코드베이스와 부딪힌 뒤 제어 흐름을 다시 소유하려는 움직임은 루프 주위에 기존 그래프를 복원하는 것과 같음 - 버그 수정 작업은 순수 루프와 그래프에서 다르게 진행됨 - 순수 루프에서는 문제 조사, 코드 변경, 테스트 선택과 실행 순서, 재시도와 완료 판단을 진행 중에 모두 결정함 - 그래프에서는 버그 재현 또는 추가 정보 요청, 원인 파악, 수정, 테스트, 검토를 미리 경로로 정의함 - 테스트 실패는 수정 단계로 돌아가고, 성공은 검토로 이동하며, 승인된 경우에만 완료됨 - 에이전트는 각 노드 안에서 지능적으로 행동하지만 허용되지 않은 경로로 이탈할 수 없음 - 그래프는 **백프레셔를 시각화**한 형태임 - 에이전트의 자유 일부를 포기하는 대신 필수 검사와 읽을 수 있는 실패 지점을 얻음 - 실행이 실패하면 어느 노드가 중단시켰는지 식별할 수 있음 - [12-factor agents](https://github.com/humanlayer/12-factor-agents)의 접근처럼 많은 에이전트 시스템은 “적절한 지점에 LLM 단계를 섞은 대부분 결정론적인 코드”에 가까움 - LangGraph와 LlamaIndex Workflows, Jerry Liu의 에이전트 위 하이브리드 작업 흐름 그래프, David Khourshid가 연결한 상태 머신과 액터 모델에서도 같은 패턴이 나타남 - 여기서 그래프는 지식 그래프가 아니라 작업 흐름과 조건부 간선을 미리 정의한 **방향 그래프**를 뜻함 ### 인간은 외부 루프를 소유함 - 인간은 팩토리에서 사라지는 대신 실행 라인에서 **외부 루프**로 이동함 - 에이전트는 버그 조사, 진단 작성, 수정 구현, 테스트 실행, 결과 보고라는 내부 루프를 수행함 - 엔지니어는 문제를 올바른 방식으로 해결하는지 판단하고, 진단과 구현을 검증하며, 변경을 승인하고 잘못된 결과에 책임짐 - 내부 루프와 외부 루프의 경계에는 diff, 테스트, 로그, 이를 연결하는 짧은 해설 같은 **증거**가 놓임 - 타입, 테스트 접점, 평가 기준표를 갖추면 변경마다 많은 수작업을 하지 않고도 에이전트 실행을 감독할 수 있음 - 엔지니어의 위치는 생산 라인에서 변경을 직접 작성하는 자리에서 라인을 설계하고 게이트를 지키는 자리로 이동함 - 모델과 하네스는 개선할 수 있지만 장기적으로 비싼 문제를 식별하는 인간 판단까지 자동화하기는 어려움 - 모든 작업 공간을 어둡게 만들어 사람이 무엇이 진행되는지 확인하거나 조명 스위치조차 찾지 못하는 상태가 가장 위험함 ## Comments _No public comments on this page._