소프트웨어 팩토리: 밝은 곳과 어두운 곳

소프트웨어 팩토리라는 개념은 1968년 밥 베머(Bob Bemer)가 발표한 논문 "프로그램 생산의 경제학(The economics of program production)"으로 거슬러 올라간다. 반세기 동안 많은 이들이 소프트웨어를 개인의 고독한 수작업이 아니라 공장에서 자동차 부품을 찍어내듯 반복 가능하고 측정 가능한 생산 공정으로 만드는 세상을 꿈꿔왔다. 하지만 아이디어를 부품처럼 찍어내기가 어렵다는 점을 비롯한 여러 이유로, 이 꿈은 몇 가지 예외를 제외하면 대체로 실현되지 못했다.

그런데 지난 2년 사이 상황이 극적으로 바뀌면서, 이 오래된 꿈을 새로운 눈으로 들여다볼 만한 이유가 생겼다. 다만 쉽게 흘려넘길 수 있는 미묘한 차이들이 있기 때문에, 진정으로 새롭고 달라진 것이 무엇인지, 그리고 새로운 기회처럼 포장되었지만 실은 반복되는 함정은 무엇인지를 꼼꼼히 짚어볼 필요가 있다.

HumanLayer의 공동 창업자 Dex Horthy는 최근 AI Engineer World's Fair에서 이 주제와 관련해 주목할 만한 강연을 했다. 제목은 "Harness Engineering is not Enough: Why Software Factories Fail"로, 꼭 찾아볼 만하다.

루프는 원자다. 팩토리는 루프를 대규모로 구현한 것이다.

구조가 전부다. 그리고 모든 것은 작은 단위에서 시작된다. 전체 스택은 사실 세 가지 개념이 층층이 쌓인 구조다. 루프, 하네스(harness), 그리고 팩토리.

루프란 에이전트 하나가 동일한 작업을 반복하는 것이다. 컨텍스트를 수집하고, 행동을 취하고, 결과를 확인한 뒤, 특정 조건이 충족될 때까지 다시 시작한다. 에이전트 작업의 가장 작은 단위이며, 그 위에 쌓이는 모든 것은 루프 위에 루프를 얹은 구조다.

루프 엔지니어링(loop engineering)의 핵심은 에이전트에게 매번 직접 프롬프트를 입력하는 대신, 그 역할을 대신해줄 작은 시스템을 설계하는 데 있다.

하네스는 루프를 감싸는 경계다. 루프가 실행되는 샌드박스 환경, 접근할 수 있는 도구들, 실행 간에 유지되는 메모리, 그리고 '완료'의 기준을 결정하는 게이트가 여기에 해당한다. 루프가 행동이라면, 하네스는 그 행동이 펼쳐지는 환경이다.

하네스 없이 모델만 넘겨주면 모델은 영원히 실행되고 말 것이다. 하네스야말로 모델을 유용하고 안전하게 작동시키는 모든 것이다.

소프트웨어 팩토리란 하네스로 감싼 수많은 루프가 동시에 실행되는 구조다. 작업 큐(queue)로부터 입력을 받아 리뷰 게이트를 통해 프로덕션으로 배출되며, 사람이 전체를 위에서 관장한다. 더 똑똑한 에이전트가 아니라, 루프로 이루어진 조직도다.

마지막 패러다임 전환은 코드를 직접 작성하는 것에서 코드를 생성하는 팩토리를 만들고 운영하는 것으로의 이동이다. 작업 단위가 한 단계 올라가, 개별 코드 diff가 아니라 루프, 하네스, 그리고 그 사이의 흐름이 중심이 된다.

팩토리를 그려보면

Dex가 가장 많은 시간을 할애했던 핵심 슬라이드는 탁월했다. 자칫 뻔해 보일 수 있는 루프를 명확한 배선도로 시각화했기 때문이다. 내 해석을 덧붙이면 이렇다.

엔지니어링 리더십의 비전과 엔지니어들의 직접적인 입력이 수행할 작업의 큐로 흘러들어간다. 인시던트와 사용자 요청에서 비롯된 신호도 동일한 큐를 구동한다. 하네스는 큐에서 항목을 꺼내 해당 항목에 대한 변경 사항을 만들어내는 장치다. 하네스 이후에는 변경 사항이 프로덕션에 들어가기에 충분히 안전한지 검증하는 자동화 체크 단계들이 이어진다. CI, 테스트, 정적 분석, 각종 스캐닝 덕분에 엔지니어의 직접적인 개입 없이도 이 체크들은 대규모로 한꺼번에 실행된다. 유일한 의사결정 지점은 리뷰 게이트다. 승인이 떨어지면 변경 사항은 배포되고 프로덕션에서 모니터링되며, 모니터링 데이터는 루프를 최초로 가동시킨 신호로 다시 피드백된다.

이 다이어그램의 각 박스는 대부분 비용이 거의 없다. 코드 생성, 테스트, 스캐닝 모두 미미한 비용으로 대규모 실행이 가능하다. 단 하나, 규모 확장에 완강하게 저항하는 비싼 박스가 있다. 바로 리뷰 게이트다. 저 밝은 노란색 박스가 '판단력'이며, 개발을 더 빠르고 빈번하게 만들 수 있는가라는 논쟁의 핵심이 바로 거기에 있다.

'어두운'이라고 부르는 이유

어두운 팩토리는 말 그대로 불이 꺼진 채 돌아간다. 공장 바닥에는 기계뿐이고, 기계는 보기 위해 빛이 필요하지 않다. 어두운 소프트웨어 팩토리도 마찬가지다. 어떤 사람도 읽지 않은 코드가 기계의 검증만 거쳐 배포된다.

이 이미지는 제조업에서 빌려온 것이다. 불을 끄고 로봇이 작업을 수행하는 시설, 즉 디지털이 아닌 물리적 공간에 뿌리를 두고 있다. 일본의 FANUC은 2001년부터 이런 방식의 라이트아웃(lights-out) 팩토리를 운영해왔으며, 샤오미(Xiaomi)도 2024년 고도로 자동화된 어두운 팩토리를 열었다. 이 두 사례의 공통점은 단 한 명의 인간도 제품을 들여다보지 않은 채 조립되어 출하된다는 것이다. '어두운'이라는 표현은 바로 그 '읽는 행위'가 공정에서 사라질 때 등장한다.

이 개념을 분위기를 위해, 혹은 비판을 위해 빌려온 것이 아니다. 온갖 섬뜩한 뉘앙스에도 불구하고, 여기서 '어두운'은 단순한 물리적 진술이다. 원래의 공장 바닥, 단지 빛이 없는 것. 소프트웨어에서 공장 바닥은 diff다. diff를 작성한 사람도, 리뷰한 사람도, 배포한 사람도 사라지고, 남는 것은 그것을 만든 기계만이 검증한 diff뿐이다.

적어도 처음에는 이것이 놀라울 정도로 쉽다. 리뷰 단계가 모든 것을 가로막고 있었기 때문이다. 그것이 사라지면 팀의 처리량이 갑자기, 그것도 극적으로 높아진 것처럼 느껴진다. 마치 음속 장벽을 돌파한 것 같다. 하지만 겉보기와 달리, 숨겨진 비용이 잔뜩 쌓인 이 어두운 워크플로우를 살아남기란 생각보다 훨씬 어렵다.

하네스 엔지니어링만으로는 부족하다

오케스트레이션, 샌드박스 프로토타이핑, 툴 콜링으로 구성된 하네스는 모델이 세상 및 다른 모델과 상호작용하면서 점점 더 강력하고 효과적이 될 것이다. 그러나 코드베이스의 품질을 장기적으로, 그리고 점진적인 변경이 누적되는 과정에서 유지하려 할 때 모델 내부에는 본질적인 한계가 존재한다. 모델만으로는 결국 이해 부채(comprehension debt)와의 싸움에서 지게 될 것이라고 믿을 만한 충분한 이유가 있다.

이해 부채란 존재하는 코드의 양과 인간이 실제로 이해하는 코드의 양 사이에서 벌어지는 격차다. 어두운 팩토리는 이 부채를 갚지 않는다. 테스트를 통과시키면서 최대한 빠르게 부채를 쌓아갈 뿐이다.

모델이 잘 해내는 작업들이 있기 때문에 이 구분은 중요하다. 그러나 코드베이스의 일부를 즉각적으로 수정하는 것 이상의 작업, 특히 복잡한 브라운필드(brownfield) 시스템에서는 모델만으로 진행하는 자동화 코딩이 넘기 어려운 장벽에 부딪힌다. 주말 토이 프로젝트나 사이드 프로젝트는 몇 달간의 개발 사이클이면 대체로 동작하는 상태에 도달할 수 있다. 하지만 10년 이상 개발되어온 엔터프라이즈 시스템은 다른 문제다. 전문적인 환경에서 전문적인 속도로 유지보수해야 한다. 프로젝트를 시작하고 3~6개월이 지나면 이미 읽지 않은 코드에 파묻힌다. 프로덕션 코드가 부과하는 제약들은 아무리 강력한 에이전트라도 부진할 수밖에 없는 환경을 만들며, 이는 주말 토이 프로젝트에서 즐기는 바이브 코딩(vibe-coding)과는 완전히 다른 세계다.

Dex는 직접 경험을 통해 이것이 심각한 실패임을 보고했다. 문제를 정확히 짚어내기까지 고통스러운 수동 디버깅이 필요했을 정도다. 이 경험은 약 4개월간 완전 자동화 코드 팩토리를 운영하면서, 그동안 작성된 코드를 어떤 사람도 들여다보지 않은 데서 비롯됐다. 이 경험의 바탕에는 두 가지 상충하는 지표 사이의 트레이드오프가 있다. 하나는 토큰 활용률을 극대화하는 것으로, 현재 우리가 진보의 척도로 삼는 지표다. 다른 하나는 그것이 조용히 최소화시키는 지표로, 어느 시점에서든 시스템 참여자 중 누군가가 실제로 이해하고 있는 시스템의 범위다.

어두운 팩토리가 진정으로 빛을 발하는 곳은 테스트를 통과시키면서 깔끔한 코드를 빠르게 소진하는 능력이다. 결국 청구서가 날아올 때, 그것은 극적인 '모든 것이 한순간에 무너지는' 순간이 아닐 것이다. 조용히, 그리고 늦게 올 것이다.

병목은 처음부터 생성이 아니었다

소프트웨어 팩토리의 근본적인 제약은 코드를 얼마나 빠르게 찍어낼 수 있느냐가 아니라, 얼마나 빠르게 검증할 수 있느냐에 있다.

백프레셔(back pressure)란 루프에 부여할 수 있는 자율성의 한계는 저렴하고 신뢰할 수 있는 방식으로 검증 가능한 범위까지라는 원칙이다. 팩토리의 실질적인 제약은 생성이 아니라 검증이다.

무한히 확장 가능한 생성 능력과 유한하고 확장되지 않는 인간의 주의력 사이에는 영원한 긴장이 존재하기 때문에, 핵심 문제는 저렴한 생성과 한정된 리뷰 사이의 간극이다. 깔때기를 보면 알 수 있다. 검증을 나타내는 목 부분이 넓어지지 않는 한 병목은 계속된다. Dex가 지적하듯, 볼륨 자체가 문제가 아니다. 진짜 문제는 형편없는 PR의 과잉이다. 신뢰할 수 있는 게이트 없이 높은 볼륨이 이어지면 결함 양산은 피할 수 없다. 이것 역시 백프레셔다. 저렴하고 신뢰할 수 있는 검증 범위를 넘어서는 자율성은 허용할 수 없다.

2차 문제는 모델을 개선한다고 해서 생성 가능한 것과 검증 가능한 것 사이의 간극이 자동으로 좁혀지지 않는 이유다. 잘 설계된 시스템을 학습하는 것은 단순한 테스트 통과보다 훨씬 어려운 과제다. 아키텍처적 우수성을 측정하는 비용 함수는 초나 분 단위가 아닌 월과 연 단위로 측정되기 때문이다. 명확한 그래디언트는 사실상 계산이 불가능하다. 복잡한 설계 결정에 대한 즉각적이고 명확한 평가를 기대하는 시스템은 좋은 예시로 훈련되기 어렵다.

다시 불을 켜다

밝은 팩토리는 판단력이 필요한 곳에 빛을 남겨둔 동일한 파이프라인이다. 에이전트가 여전히 대부분의 빌드를 담당하지만, 배포 전에 사람이 결과물을 읽고 검토하며, 잘못된 판단이 비싼 대가를 치르는 곳에는 빛이 켜져 있다.

밝은 버전은 끝에 리뷰를 붙이는 것이 아니라, 에이전트가 루프를 시작하기 전에 제품, 설계, 아키텍처 단계로 인간의 판단 지점을 앞당긴다.

초반에 한 시간을 투자하는 것의 큰 장점은 이후 구현 시간이 줄어든다는 것이다. 길고 힘든 코드 리뷰가 200줄짜리 계획서를 간단히 읽는 것으로 바뀐다. 결정이 구현되기 전에 검토할 수 있으므로, 나중에 2,000줄의 생성된 코드를 뒤지며 애초에 어떤 결정이 내려졌는지 추적할 필요가 없다. 어떤 결정들은 비용이 크고 오래 지속되기 때문에, 비용이 눈덩이처럼 불어나기 전에 초반에 사람이 개입하는 것이 합리적이다. 물론 초반에 시간을 투자했더라도 diff를 직접 봐야 할 때는 여전히 있다.

별로 화려하지 않다고 생각할 수 있다. 맞다. 안전망은 우리가 항상 알고 있었지만 대체로 무시해온 평범한 아키텍처 관행들로 구성된다. 실수가 프로덕션이 아닌 컴파일러에서 잡히도록 하는 좋은 타입과 메서드 시그니처, 동작을 고정하고 변경을 관찰 가능하게 만드는 테스트 심(seam), 다음 독자(사람이든 모델이든)가 원하는 것을 찾을 수 있도록 코드를 구성하는 방식, 짧고 읽기 쉬운 콜 스택, 변경 사항의 파급 범위를 최소화하는 명확한 컴포넌트 경계, 한 부분을 다른 것으로 교체할 수 있는 의존성 주입. 이 중 새로운 것은 없다. 우리는 항상 좋은 아키텍처를 중요시한다고 말해왔다. 그런데 이제 자동화된 코딩 에이전트를 사용하면서, 그 아키텍처가 드디어 두 번째 역할을 맡게 됐다. 에이전트가 저지를 실수에 대한 저렴하고 속이기 어려운 안전망으로서.

이 안전망은 모델 외부에 있어야 한다. 모델이 스스로 공급하지 않기 때문이다. 가장 유능하다고 느껴지는 코딩 에이전트들, Claude Code와 Codex를 포함해, 자체 하네스와 도구를 기반으로 강화 학습되어 있다. 이 도구들과 업계의 관용구에는 유창하지만, 장기적인 유지보수성 같은 것에는 그렇지 못하다. 우리가 항상 이야기해온 의도적인 아키텍처가 바로 그 부채를 잡아내는 도구이며, 거기에 투자하는 것은 우리의 자율성을 되사는 행위다. 이것을 안전한 인프라와 결합하면, 무인으로 실행할 수 있는 타이트하고 저위험의 루프들이 생긴다. Horthy는 최근 포스트에서 하나를 소개했다. 매일 밤 GitHub Actions 크론이 린트 위반이나 불필요하게 optional한 prop 같은 딱 하나의 안티패턴을 수정하고, 커밋하고, 작은 풀 리퀘스트 하나를 스스로 열어서, 팀이 아침에 일어나면 약간 더 나아진 코드베이스와 읽을 수 있을 만큼 짧은 diff를 받아보게 되는 것이다. 하지만 위험 부담이 충분히 높은 루프라면, 망가진 인증 시스템이나 결제 엔진, 퍼블릭 API 계약을 아침에 마주치고 싶지 않을 것이다. 그런 곳에는 불을 켜두고, 판단력과 시스템에 대한 실질적인 이해를 갖춘 사람이 실수를 잡아낼 것이라고 신뢰하자.

루프가 어둠을 얻는 조건

이 규칙은 백프레셔라고 부르든, 검증이라고 부르든, 스위치라고 부르든 동일하게 적용된다.

루프가 완전 자동화 지위를 얻으려면, 검증이 저렴하고, 고빈도로 실행되며, 쉽게 속일 수 없는 방식에 의존해야 한다. 그린/레드 오라클, 타입 게이트, 프로퍼티 테스트, 실제 루브릭과 결합된 리뷰 에이전트가 여기에 해당한다. 또한 오라클이 즉시 답을 내려야 하고 시간이 지나도 흔들리지 않아야 한다. 기계가 '완료'를 증명할 수 있을 때, 비로소 자동화에 도달한 것이다.

짧은 루프는 긴 루프보다 검증하기 쉽다. Dex의 경험 법칙: 에이전트는 3~10단계까지는 잘 버티지만, 20단계를 넘으면 흐름을 잃기 시작한다. 이유는 컨텍스트 축적이다. 에이전트가 끌고 다니는 것이 많아질수록 방황할 가능성이 높아진다. 루프가 짧으면 검증 비용이 낮다. 복잡하게 뻗어나간 루프는 구석에 실수를 숨긴다. 다시 말해, 그런 루프는 처음부터 라이트아웃 자격을 얻지 못한 것이다.

빛을 켜두는 것은 반대의 경우다. 잘못된 답이 비싸고 사람만이 잡아낼 수 있다면 루프는 리뷰를 받아야 한다. 테스트로 잡기 어려운 미묘한 프로덕션 버그, 넓은 파급 범위, 1년 이상의 작업 방향을 결정하는 의사결정이 여기에 해당한다. 그런 경우, 당신의 주의력이 곧 제품이다. 비싸고 없어서는 안 될 제품.

위험은 각각의 스위치를 개별적으로 설정하는 것을 잊고 모두 같은 모드로 맞춰버리는 것이다. 전부 어둡게 하면 4개월 뒤에 모든 것을 허물어야 하는 상황에 빠진다. 전부 밝게 하면 아무도 제때 리뷰를 완료하지 못하고 거대한 병목에 갇힌다. 어렵고 숙련된 작업은 어느 스위치를 어디에 설정할지를 결정하는 것이다.

루프, 그래프, 상태 머신?

에이전트에게 작업을 넘길 때, 유한 상태 머신(finite state machine)이라고 부르든 조건부로 연결된 서비스 호출의 집합이라고 부르든, 그 주변에 그래프를 구축하게 될 것이다. 이 프레이밍에서 소프트웨어는 추상적인 규칙을 따르는 것이 아니라 구조화된 워크플로우를 따른다. 모든 노드는 명시적인 단계이고, 노드 사이의 모든 엣지는 명시적인 조건이다. 많은 구조처럼 들리지만, 어떤 코드든 제어 흐름 그래프로 표현할 수 있기 때문에 대부분의 구조는 이미 어떤 소프트웨어에나 존재한다. 따라서 진정한 새로움은, 자율성을 주장하는 에이전트가 실은 특정 그래프를 돌아다니고 있을 뿐이며 그 자유는 노드 안에 제한된다는 것이다. 그리고 여기 사람들이 잊곤 하는 부분이 있다. Dex가 1년 전에 기록했듯이, 소프트웨어는 원래부터 그런 구조를 가지고 있었다. 예전에 프로그램을 순서도로 그리던 데는 이유가 있었다. 진정으로 새로운 시도는 다이어그램을 버리고, 모델이 툴 콜 하나씩 경로를 선택하다가 스스로 완료를 선언할 때까지 루프에 의존하는 것이었다. 그것은 해방처럼 느껴졌다. 10년 된 코드베이스를 만나기 전까지는. 그리고 모두가 지금 재발견하고 있는 원칙, 즉 제어 흐름을 직접 소유하는 것은 실은 그래프를 루프 주위로 다시 돌리는 것에 불과하다. 루프에서 그래프로 다시 전환해야 하는가라는 질문은, 사실 처음부터 순서도가 필요했음을 인정하는 것과 다름없다.

실제로 어떤 모습인지 살펴보자. 버그를 고친다고 가정하자. 순수한 루프 방식에서는 앉아서 생각한다. 무엇이 잘못됐는지 파악하고, 코드를 수정하고, 테스트를 실행하고, 결과를 확인한다. 그 라운드가 실행을 끝내지 못하면 다시 루프로 돌아간다. 전체 여정은 진행되면서 결정된다. 어떤 문제를 추적할지, 정확히 어떤 코드를 변경할지, 어떤 테스트를 어떤 순서로 실행할지, 테스트를 실행할지 여부, 그리고 다시 시도할지 아니면 완료로 선언할지. 그래프 방식에서는 먼저 무슨 일이 일어나야 하는지를 설계한다. 버그를 재현하거나 더 많은 정보를 요청하고, 원인을 찾고, 수정을 시도하고, 테스트를 실행한다. 실패한 실행은 수정 단계로 돌아가고, 통과한 실행은 리뷰로 넘어가며, 승인만이 완료에 도달한다. 에이전트는 각 박스 안에서 여전히 영리하게 작동하지만, 승인된 경로에서 벗어날 수 없다. Santi는 그 차이를 분명하게 보여주는 다이어그램으로 이것을 정리했다.

그래프의 진정한 매력은, 물론, 백프레셔를 다이어그램으로 그린 것이라는 점이다. 에이전트의 자유를 일부 포기하는 대신 필수 체크와 명확한 실패 지점을 얻는다. 실행이 실패했을 때 어떤 노드가 원인인지 짚어낼 수 있다. 대부분의 이른바 에이전트는 사실 그다지 에이전틱하지 않다는 Dex의 직설적인 표현 뒤에 있는 본능도 같다. "주로 결정론적 코드이며, 딱 맞는 지점에 LLM 단계가 뿌려진 것이다." 이것은 단순히 현재 사람들이 구축하는 방식의 산물이 아니다. LangGraph와 LlamaIndex Workflows에서, 런타임에 그래프의 일부를 성장시키는 아우터 루프를 가진 Jerry Liu의 하이브리드 워크플로우-그래프-오버-에이전트에서, 그리고 이것이 실은 새로운 옷을 입은 상태 머신과 액터 모델이라는 David Khourshid의 지적에서 이 패턴을 볼 수 있다.

한 가지 명확히 할 것이 있다. 이 용어는 심하게 중의적으로 쓰이기 때문이다. 내가 계속 그래프라고 부를 때, 지식 그래프(knowledge graph)를 말하는 것이 아니다. 조건부 엣지를 포함해 작업이 어떻게 흘러야 하는지를 미리 정의한 방향성 그래프, 즉 루프에 실제로 신뢰할 수 있는 형태를 부여하는 것을 의미한다.

사람은 실제로 어디로 가는가

사람은 팩토리를 떠나지 않았다. 이동했을 뿐이다.

엔지니어들은 점점 더 아우터 루프(outer loop)를 직접 소유해야 한다고 생각한다. 에이전트는 버그를 조사하고, 진단을 작성하고, 수정을 구현하고, 테스트를 실행하고, 보고서를 작성할 수 있다. 이것이 이너 루프(inner loop)의 실행이고, 에이전트는 누구 못지않게 효율적으로 처리할 수 있다. 하지만 그것은 원래부터 핵심 업무가 아니었다. 당신이 소유해야 할 부분은 내가 아우터 루프라고 부르는 것이다. 이 방식이 문제를 해결하는 올바른 접근인지 판단하고, 진단과 구현이 타당한지 확인하고, 변경을 승인하고, 틀렸을 때의 결과를 책임지는 것. 두 루프 사이의 경계는 증거다. diff, 테스트, 로그, 그리고 이것들을 연결하는 간략한 설명. 타입, 심, 루브릭은 모든 변경에 많은 노력을 들이지 않고도 이 모든 것을 감독할 수 있게 해준다.

이렇게 생각하면 유용하다. 당신은 더 이상 생산 라인 위에서 코드를 작성하는 것이 아니라, 라인의 끝에서 그것을 설계하고 게이트를 지키고 있다. 모델을 더 좋게 만들고 하네스를 더 유능하게 만들 수 있는 것들이 많지만, 장기적으로 비싼 문제를 식별하는 것은 자동화로 없애기 어렵다는 것을 나는 관찰해왔다. 여전히 핵심 업무로 남는 것은, 어떤 문서 더미나 컴퓨팅 파워의 흐름보다도 더 뛰어나게 인간의 판단력을 발휘하는 것이다.

로봇은 어둠 속에서 잘 작동하지만, 인간은 자신이 무엇을 하는지 봐야 한다. 공장 바닥 전체가 어둡고, 아무것도 보이지 않고, 스위치조차 찾을 수 없다면, 그곳이 바로 위험한 곳이다.

Pangram이 이 글을 평가한 결과 100% 인간 작성으로 분류됐다.