소프트웨어 공장의 빛과 어둠
TMT소프트웨어 공장이란 루프를 하네스로 감싸 대규모로 돌리는 것입니다. 루프 안에 사람을 두고 돌릴 수도 있습니다(불 켜진 공장). 판단력과 집중력을 들이는 대신 속도를 내주고, 그만큼 망가지는 일도 줄이는 방식입니다. 아니면 사람을 배제하고(불 꺼진 공장) 에이전트들이 알아서 작업 범위를 잡고, 코드를 만들고, 배포까지 하게 둘 수도 있습니다. 세부 내용은 아무도 제대로 읽지 않은 채로 말입니다. 하지만 사람이 코드를 읽지 않게 되면, 소프트웨어를 이해하는 일도 멈춥니다. 이제 가장 어려운 일은 어떤 검증 장치를 만들지, 그리고 자율성을 어디까지 위임할지를 아는 것입니다.
소프트웨어 공장이라는 개념은 밥 비머(Bob Bemer)가 1968년에 발표한 논문 "The economics of program production"까지 거슬러 올라갑니다. 반세기 동안 많은 사람이 소프트웨어가 개인의 고립된 장인 기술이 아니라, 공장에서 자동차 부품을 찍어내듯 반복 가능하고 계측 가능한 생산 공정이 되는 세상을 꿈꿔 왔습니다. 하지만 아이디어라는 것은 찍어내기가 어렵다 보니, 이 꿈은 역사적으로 대체로(전부는 아니지만) 실패로 끝났습니다.
그런데 지난 2년 사이 상황이 극적으로 달라져, 이제는 이 오래된 꿈을 새로운 눈으로 다시 들여다볼 만해졌습니다. 미묘한 지점들이 쉽게 얼버무려질 수 있으니, 무엇이 정말 새롭고 달라졌는지, 그리고 무엇이 새로운 기회로 포장된 해묵은 함정인지 어느 정도 정확히 짚어 볼 필요가 있습니다.
HumanLayer 공동 창업자인 덱스 호르티(Dex Horthy)가 최근 AI Engineer World's Fair에서 이 주제로 "Harness Engineering is not Enough: Why Software Factories Fail"이라는 훌륭한 발표를 했으니 한번 볼 만합니다.
루프는 원자이고, 공장은 그 루프를 대규모로 돌리는 것이다
구조가 전부이고, 모든 것은 작은 단위에서 시작합니다. 전체 스택은 사실 세 가지 개념이 층층이 쌓인 것입니다. 루프(loop), 하네스(harness), 그리고 공장(factory)입니다.
루프는 에이전트 하나가 한 가지 일을 반복하는 것입니다. 컨텍스트를 모으고, 행동하고, 결과를 확인하고, 어떤 조건이 충족될 때까지 다시 도는 식입니다. 에이전트 작업의 최소 단위이며, 그 위에 있는 모든 것은 결국 루프 위에 루프를 쌓은 것에 지나지 않습니다.
루프 엔지니어링의 핵심은, 에이전트에 턴마다 일일이 프롬프트를 입력하는 대신 그 일을 대신해 줄 작은 시스템을 설계하는 데 있습니다.
하네스는 루프를 둘러싼 벽입니다. 루프가 도는 샌드박스, 손이 닿는 도구들, 실행 사이에도 살아남는 메모리, 그리고 무엇을 "완료"로 볼지 정하는 게이트가 여기에 해당합니다. 루프가 행동이라면, 하네스는 그 행동이 돌아가는 환경입니다.
하네스 없이 날것의 모델만 놓아 두면 하염없이 헛돌기만 합니다. 모델을 쓸모 있고 안전하게 돌아가게 만드는 주변 장치 전부가 하네스입니다.
소프트웨어 공장은 하네스를 갖춘 루프 여러 개가 동시에 돌아가는 것입니다. 작업 큐에서 일감을 받아, 리뷰 게이트를 거쳐 프로덕션으로 흘려보내며, 사람은 그 전체를 위에서 총괄합니다. 더 큰 에이전트가 아니라, 루프로 짠 조직도인 셈입니다.
마지막 패러다임 전환은 코드를 직접 쓰는 일에서, 코드를 써 주는 공장을 짓고 운영하는 일로 옮겨 가는 것입니다. 작업 단위가 개별 코드 diff가 아니라 루프, 하네스, 그리고 그 사이의 흐름으로 한 단계 올라갑니다.
루프 → 하네스 → 공장. 공장은 더 똑똑한 에이전트가 아니라, 하네스를 갖춘 여러 루프가 하나의 리뷰 게이트로 모이고, 사람이 바깥 루프를 책임지는 구조입니다.
공장을 그림으로 그리면
덱스가 가장 오래 설명한 핵심 슬라이드는 훌륭했습니다. 그냥 두면 뻔해 보이는 루프를 명료한 배선도로 시각화해 주기 때문입니다. 제 나름대로 다시 그려 보면 이렇습니다.
공장은 닫힌 루프입니다. 의도와 프로덕션 신호가 큐를 채우고, 하네스가 변경을 만들고, 자동 검사와 리뷰가 관문 역할을 하고, 배포가 내보내고, 모니터링이 프로덕션을 다시 신호로 되돌립니다.
의도는 엔지니어링 리더십의 비전에서, 그리고 엔지니어들에게서 직접 흘러나와 할 일 큐로 들어갑니다. 장애와 사용자 요청에서 나온 신호도 같은 큐를 채웁니다. 하네스는 큐에서 항목 하나를 집어 그에 맞는 변경을 만들어 내는 장치일 뿐입니다. 하네스 다음에는 변경을 프로덕션에 들여보내도 될 만큼 안전하게 만드는 데 필요한 자동 검사들이 늘어서 있습니다. CI, 테스트, 정적 분석, 각종 스캐닝 덕분에 이 자동 검사들은 엔지니어가 신경 쓰지 않아도 한꺼번에, 힘들이지 않고 돌아갑니다. 여기서 유일한 의사결정 지점이 리뷰 게이트입니다. 승인이 나면 변경은 배포되어 프로덕션에서 모니터링되고, 모니터링 데이터는 애초에 이 루프를 돌게 만든 신호로 다시 흘러 들어갑니다.
대체로 이 다이어그램의 상자들은 비용이 거의 들지 않습니다. 생성, 테스트, 스캐닝 모두 무시할 만한 비용으로 대규모로 돌아갑니다. 규모 확장이 좀처럼 안 되는 비싼 상자는 딱 하나, 리뷰 게이트입니다. 저 눈에 띄는 호박색 상자가 바로 "판단"이고, 개발을 더 빠르고 더 자주 할 수 있느냐는 논쟁의 핵심이 거기에 있습니다.
왜 "불 꺼진" 공장이라 부르는가
불 꺼진 공장(dark factory)은 말 그대로 조명을 끈 채 돌아갑니다. 작업장에 기계밖에 없고, 기계는 보는 데 빛이 필요 없기 때문입니다. 불 꺼진 소프트웨어 공장도 같은 이치입니다. 사람이 한 번도 읽지 않은 코드가, 다른 기계들의 검증만 거친 채 배포됩니다.
이 이미지는 제조업에서 빌려 온 것입니다. 디지털이 아니라 물리적인 데서 유래했습니다. 조명을 꺼 두고 로봇이 작업을 수행하는 시설 말입니다. 일본의 FANUC은 2001년부터 이런 소등 공장을 운영해 왔고, 샤오미도 2024년에 고도로 자동화된 자체 불 꺼진 공장을 열었습니다. 이들의 공통점은 사람이 한 명도 들여다보지 않은 채 제품이 조립되고 출하된다는 점입니다. 들여다본다는 행위가 공정에서 빠지는 순간 "불이 꺼진" 것입니다.
분위기를 내려고, 혹은 비하하려고 이 개념을 빌린 것이 아닙니다. 으스스한 어감과 달리 여기서 "불 꺼진"이란 단순한 물리적 진술입니다. 원래의 공장 바닥에서 빛만 빠진 상태라는 뜻입니다. 소프트웨어에서 그 바닥은 diff입니다. diff를 쓴 사람도, 리뷰한 사람도, 배포한 사람도 사라지고, 남는 것은 그것을 만든 기계들만 검증한 diff입니다.
이렇게 하기는 의외로 쉽습니다. 적어도 처음에는요. 쉬운 이유는, 빠져 버린 그 리뷰 단계가 원래 모든 일의 발목을 잡는 단계이기 때문입니다. 리뷰가 사라지면 팀의 처리량이 갑자기 급격하게 높아진 것처럼 느껴집니다. 음속 장벽을 돌파한 기분마저 듭니다. 하지만 겉보기의 쉬움과 달리, 비용이 곳곳에 묻혀 있는 이 불 꺼진 워크플로를 버텨 내기는 생각보다 어렵습니다.
하네스 엔지니어링만으로는 부족하다
모델이 세상과, 그리고 서로와 상호작용하게 해 주는 오케스트레이션, 샌드박스 프로토타이핑, 도구 호출 같은 하네스는 갈수록 강력하고 효과적이 될 것입니다. 하지만 긴 승부에서, 변경이 계속 쌓여 가는 와중에 코드베이스 품질을 따라잡는 일에는 모델 자체에 내재한 한계가 있습니다. 모델만으로는 결국 이해 부채(comprehension debt)와의 싸움에서 질 것이라고 믿을 만한 충분한 이유가 있다고 생각합니다.
이해 부채란 존재하는 코드의 양과 사람이 여전히 이해하고 있는 양 사이에서 점점 벌어지는 간극입니다. 불 꺼진 공장은 이 부채를 갚기는커녕, 테스트를 내내 초록불로 유지한 채 최대한 빠르게 부채를 쌓아 갑니다.
모델이 어떤 작업은 잘 해내기 때문에 이 구분이 중요합니다. 하지만 코드베이스의 작은 부분을 즉시 고치는 수준을 넘어서는 일, 특히 복잡한 브라운필드 시스템에서는 모델만으로 하는 자동 코딩이 넘을 수 없는 벽에 부딪힙니다. 주말 장난감 프로젝트든 사이드 프로젝트든, 몇 달 정도 개발을 돌리면 대개 굴러가는 상태나 적어도 그 비슷한 데까지는 갑니다. 그러나 10년 넘게 개발되어 온 엔터프라이즈 시스템은 전혀 다른 짐승입니다. 전문적인 환경에서 전문적인 속도로 유지보수해야 합니다. 프로젝트가 3~6개월만 지나도 이미 읽지 않은 코드에 파묻히게 됩니다. 그런 환경, 특히 프로덕션 코드가 강제하는 제약 앞에서는 아무리 강력한 에이전트라도 힘을 못 씁니다. 주말 장난감을 만드는 개발자들이 즐기는 바이브 코딩과는 전혀 다른 세계입니다.
덱스는 경험을 근거로 이것이 심각한 실패라고 전합니다. 원인을 짚어내는 데 고통스러운 수동 디버깅이 필요했을 정도라고 합니다. 완전 자동화된 코드 공장을 약 4개월 동안 돌리면서, 그동안 작성된 코드를 아무도 들여다보지 않은 데서 나온 경험입니다. 이 경험의 밑바닥에는 서로 충돌하는 두 지표 사이의 트레이드오프가 있습니다. 하나는 토큰 사용량 극대화로, 지금 우리가 진척으로 취급하는 숫자입니다. 다른 하나는 그 과정에서 조용히 최소화되는 것으로, 어느 시점에든 참여자 중 누군가가 여전히 이해하고 있는 시스템의 비율입니다.
불 꺼진 공장이 정말 빛을 발하는 지점은, 테스트가 초록불인 채로 멀쩡한 코드를 태워 없애는 능력입니다. 최후의 심판은 닥쳐와도 "모든 게 한꺼번에 무너지는" 극적인 순간으로 오지 않을 것입니다. 조용히, 뒤늦게 올 것입니다.
불 꺼진 공장과 불 켜진 공장은 같은 파이프라인에서 조명 위치만 다릅니다. 불 켜진 버전은 끝에 리뷰만 다시 붙이는 게 아니라, 사람의 판단을 설계와 아키텍처라는 상류로도 옮깁니다.
병목은 애초에 생성이 아니었다
소프트웨어 공장의 근본 제약은 코드를 얼마나 뽑아낼 수 있느냐가 아니라, 그것을 얼마나 빨리 검증할 수 있느냐입니다.
배압(back pressure)이란, 싸고 확실하게 검증할 수 있는 만큼만 루프에 자율성을 줄 수 있고 한 치도 더 줄 수 없다는 규칙입니다. 공장의 진짜 제약은 생성이 아니라 검증입니다.
무한한 생성 능력은 유한하고 확장되지 않는 자원인 사람의 주의력과 늘 긴장 관계에 있기 때문에, 핵심 문제는 값싼 생성과 한계가 있는 리뷰 사이의 간극입니다. 깔때기를 떠올려 보십시오. 검증에 해당하는 목 부분이 넓어지지 않는 한, 위쪽은 계속 밀려서 쌓입니다. 덱스가 지적하듯 물량 자체가 문제가 아닙니다. 정말 우리를 괴롭히는 것은 넘쳐나는 질 낮은 PR입니다. 믿을 만한 게이트 없이 물량만 많으면 불량품이 나올 수밖에 없습니다. 이것 역시 배압 이야기입니다. 자율성은 싸고 확실하게 검증할 수 있는 범위를 넘어 커질 수 없습니다.
한 단계 더 들어간 문제는, 모델이 좋아진다고 해서 생성할 수 있는 것과 검증할 수 있는 것 사이의 간극이 저절로 좁혀지지는 않는다는 점입니다. 아키텍처가 잘 잡힌 시스템을 학습 대상으로 삼는 것은 단순한 테스트를 통과시키는 것보다 훨씬 어려운 일입니다. 아키텍처의 우수성을 재는 비용 함수는 초나 분 단위가 아니라 몇 달, 몇 년 단위로 측정된다는 점을 기억해야 합니다. 깔끔한 그래디언트를 계산하기가 사실상 불가능하므로, 복잡한 설계 결정에 대한 명쾌하고 즉각적인 평가를 전제로 하는 시스템은 좋은 사례로 학습될 수 없습니다.
생성은 넓은 입구이고 검증은 좁은 목입니다. 입구를 빠르게 만들어 봐야 목에 쌓이는 더미만 깊어집니다.
다시 불을 켜다
불 켜진 공장(lit factory)은 같은 파이프라인에서, 판단이 필요한 자리에 불을 켜 둔 것입니다. 여전히 대부분의 제작은 에이전트가 하지만, 배포 전에 사람이 산출물을 읽고, 잘못된 판단의 대가가 큰 곳에는 불이 계속 켜져 있습니다.
불 켜진 버전은 끝에 리뷰를 덧붙이는 것이 아니라, 사람이 판단하는 지점을 상류로 옮깁니다. 에이전트가 루프를 시작하기 전의 제품, 설계, 아키텍처 단계로 말입니다.
이렇게 앞단에 한 시간을 들이면 구현에 드는 시간이 줄어든다는 큰 장점이 있습니다. 길고 지치는 코드 리뷰가 200줄짜리 계획서를 빠르게 읽는 일로 바뀝니다. 결정이 구현되기 전에 검토할 수 있으니, 나중에 생성된 코드 2,000줄을 뒤지며 대체 무슨 결정이었는지 찾아 헤맬 일이 없습니다. 어떤 결정은 비용이 크고 수명이 길어서, 대가가 불어나기 전에 일찌감치 사람이 끼는 편이 좋습니다. 물론 앞단에 시간을 들였더라도 diff를 들여다봐야 할 때는 여전히 있습니다.
하나도 화려하지 않게 들린다고 생각할지 모르겠습니다. 맞습니다. 이 안전망은 우리가 늘 알고 있었으면서 대체로 무시해 온, 지극히 평범한 아키텍처 관행들로 이루어져 있습니다. 실수를 프로덕션이 아니라 컴파일러가 잡아 주도록 하는 좋은 타입과 메서드 시그니처, 동작을 고정하고 변경을 관찰할 수 있게 해 주는 테스트 심(seam), 다음에 읽는 이가 사람이든 모델이든 원하는 것을 어디서 찾을지 알 수 있게 하는 코드 배치, 짧고 읽기 쉬운 콜 스택, 변경의 파급 범위가 커지지 않도록 잘 정의된 컴포넌트 경계, 부품 하나를 다른 것으로 갈아 끼울 수 있게 해 주는 의존성 주입까지. 새로운 것은 하나도 없습니다. 좋은 아키텍처가 중요하다고 우리는 늘 말해 왔습니다. 다만 자동 코딩 에이전트를 쓰는 지금, 그 아키텍처가 마침내 두 번째 일을 하게 됐습니다. 에이전트가 저지를 실수에 대비하는, 값싸고 속이기 어려운 안전망 역할 말입니다.
이 안전망은 모델 바깥에 있어야 합니다. 모델이 알아서 제공해 주지 않기 때문입니다. 가장 유능하게 느껴지는 코딩 에이전트들, Claude Code나 Codex 같은 것들은 자기 하네스와 도구에 맞춰 강화학습된 존재입니다. 업계의 온갖 도구와 관용구에는 능숙하지만, 장기 유지보수성 같은 것에는 그렇지 않습니다. 우리가 늘 이야기해 온 의도적인 아키텍처가 그 부채를 잡아내는 도구이고, 거기에 들이는 투자는 우리의 자율성을 되사 오는 일입니다. 여기에 안전한 인프라까지 갖추면, 사람이 지켜보지 않아도 돌릴 수 있는 촘촘하고 위험이 낮은 루프가 몇 가지 생깁니다. 호르티는 최근 글에서 그런 예를 하나 소개했습니다. 매일 밤 GitHub Actions 크론이 안티패턴 딱 하나(lint 위반이나 불필요하게 optional로 선언된 prop 같은 것)를 고치고, 커밋하고, 작은 풀 리퀘스트 하나를 스스로 엽니다. 그러면 팀은 아침에 조금 더 나아진 코드베이스와 읽을 수 있을 만큼 짧은 diff를 마주하게 됩니다. 하지만 판돈이 충분히 큰 루프에서는, 자고 일어났더니 인증 시스템이나 결제 엔진, 공개 API 계약이 망가져 있는 위험을 감수하고 싶지 않을 것입니다. 그런 곳에는 불을 켜 두고, 판단력과 시스템에 대한 실전 지식을 갖춘 사람이 실수를 잡아내리라 믿는 편이 낫습니다.
어떤 루프가 소등 자격을 얻는가
배압이라 부르든, 검증이라 부르든, 조명 스위치라 부르든 이 규칙은 똑같이 적용됩니다.
루프가 완전 자동화 지위를 얻으려면 검사가 저렴하고, 자주 돌고, 쉽게 속일 수 없는 무언가에 기대야 합니다. 초록불 아니면 빨간불로 답하는 오라클, 타입 게이트, 속성 테스트(property test), 제대로 된 루브릭을 갖춘 리뷰 에이전트가 모두 여기에 해당합니다. 오라클이 즉시 답하고 시간이 지나도 어긋나지 않는 것도 필요합니다. "완료"를 나뿐 아니라 기계도 증명할 수 있게 되면, 그때 자동화에 도달한 것입니다.
짧은 루프가 긴 루프보다 검증하기 쉽습니다. 덱스의 경험칙에 따르면 에이전트는 3~10단계까지는 버티다가, 20단계를 넘어가면 맥락을 놓치기 시작합니다. 원인은 컨텍스트 축적입니다. 끌고 다니는 것이 많을수록 에이전트는 옆길로 샐 가능성이 커집니다. 루프가 짧으면 검증도 쌉니다. 넓게 퍼진 루프는 구석구석에 실수를 숨기는데, 이는 애초에 소등 자격을 얻은 적이 없다는 말의 다른 표현일 뿐입니다.
불을 켜 두는 것은 그 반대의 경우입니다. 오답의 대가가 크고 사람만이 그것을 잡아낼 수 있다면, 그 루프는 리뷰가 필요합니다. 테스트로는 못 잡는 미묘한 프로덕션 버그, 넓은 파급 범위, 1년 이상의 작업 방향을 좌우할 결정이 모두 여기에 해당합니다. 이런 경우에는 사람의 주의력이야말로 진짜 산출물입니다. 비싸지만 없어서는 안 되는 산출물 말입니다.
위험한 것은 스위치를 하나하나 조정할 생각을 잊고 전부 같은 모드로 놓아 버리는 일입니다. 전부 끄면 4개월 뒤에 모든 것을 뜯어내야 하는 처지가 되고, 전부 켜면 아무도 제때 리뷰를 끝내지 못해 거대한 병목에 갇힙니다. 스위치 하나하나를 어디에 둘지 정하는 것이야말로 어렵고 숙련이 필요한 일입니다.
루프인가, 그래프인가, 상태 기계인가?
에이전트에게 작업을 맡기면, 결국 그 주위에 그래프를 짓게 됩니다. 그 그래프를 유한 상태 기계라 부르든, 조건부로 연결된 서비스 호출들의 집합이라 부르든 말입니다. 소프트웨어가 어떤 추상적인 규칙이 아니라 구조화된 워크플로를 따른다는 관점입니다. 모든 노드는 명시적인 단계이고, 노드 사이의 모든 엣지는 명시적인 조건입니다. 구조가 과해 보일 수 있지만, 사실 그 대부분은 어떤 소프트웨어에나 이미 들어 있습니다. 어떤 코드든 제어 흐름 그래프로 표현할 수 있으니까요. 그러니 정말 새로운 점은 하나뿐입니다. 자율성을 주장하는 에이전트도 실은 특정 그래프 위를 돌아다니고 있을 뿐이고, 그 자유는 노드 내부로 제한된다는 것입니다. 그리고 사람들이 잊고 있는 대목, 덱스가 1년 전에 적어 둔 대목이 있습니다. 소프트웨어는 어차피 그런 구조를 갖게 되어 있었다는 것입니다. 우리가 예전에 프로그램을 순서도로 그리던 데는 이유가 있습니다. 정말 새로웠던 시도는 오히려 그 다이어그램을 내다 버리는 쪽이었습니다. 모델이 도구 호출 하나하나마다 경로를 골라, 스스로 완료를 선언할 때까지 도는 루프에 기대는 방식 말입니다. 그것은 해방처럼 느껴졌습니다. 10년 묵은 코드베이스를 만나기 전까지는요. 그리고 지금 모두가 다시 발견하고 있는 규율, 즉 제어 흐름을 직접 소유하라는 원칙은, 결국 루프를 다시 그래프 위로 되돌려 걷게 하는 일입니다. 그러니 루프에서 그래프로 돌아가야 하느냐는 질문 자체가, 애초부터 순서도가 필요했다는 자백이나 다름없습니다.
실제로는 이런 모습입니다. 고쳐야 할 버그 하나를 예로 들어 봅시다. 순수한 루프라면 이렇게 진행됩니다. 무엇이 잘못됐는지 파악하고, 코드를 좀 고치고, 테스트를 돌리고, 결과를 보고, 그 판에서 실행이 끝장나지 않았으면 되돌아가 다시 시작합니다. 어떤 문제를 쫓을지, 정확히 어떤 코드를 고칠지, 어떤 테스트를 어떤 순서로 돌릴지, 테스트를 돌리기는 할지, 다시 시도할지 아니면 승리를 선언할지, 이 모든 여정이 가면서 즉석에서 결정됩니다. 그래프라면 가장 먼저 무슨 일이 일어나야 하는지부터 지도로 그립니다. 버그를 재현하거나 정보를 더 요청하고, 원인을 찾고, 수정을 시도하고, 테스트를 돌리고, 실패한 실행은 수정 단계로 되돌리고 통과한 실행은 리뷰로 넘기며, 승인된 것만 완료에 도달하게 합니다. 에이전트는 여전히 각 상자 안에서는 영리하게 움직입니다. 다만 허가받은 경로 밖으로 벗어날 수 없을 뿐입니다. 산티(Santi)는 이 차이가 한눈에 보이는 다이어그램으로 이를 정리한 바 있습니다.
물론 이 그래프의 진짜 매력은, 그것이 배압을 다이어그램으로 그린 것이라는 데 있습니다. 에이전트의 자유를 일부 포기하는 대신 필수 검사와 읽어 낼 수 있는 실패 지점을 얻습니다. 그래서 실행이 죽으면 어느 노드가 죽였는지 짚을 수 있습니다. 소위 에이전트라는 것들 대부분이 사실 별로 에이전트답지 않다는, "대부분은 결정론적 코드이고, 딱 맞는 지점에 LLM 단계를 뿌려 넣은 것"이라는 덱스의 직설도 같은 직관에서 나온 말입니다. 그리고 이것은 지금 사람들이 우연히 이런 방식으로 만들고 있어서 생긴 현상이 아닙니다. LangGraph와 LlamaIndex Workflows에서, 실행 중에 그래프의 일부를 키워 가는 바깥 루프를 두고 에이전트 위에 워크플로 그래프를 얹은 제리 류(Jerry Liu)의 하이브리드에서, 그리고 이것이 결국 상태 기계와 액터 모델이 새 옷을 입고 나타난 것일 뿐이라는 데이비드 쿠르시드(David Khourshid)의 지적에서 같은 패턴을 볼 수 있습니다.
용어가 워낙 여러 뜻으로 쓰이니 하나만 짚고 넘어가겠습니다. 여기서 계속 그래프라고 부르는 것은 지식 그래프가 아닙니다. 작업이 어떻게 흘러야 하는지를 조건부 엣지까지 포함해 미리 정의해 둔 유향 그래프, 즉 루프에 실제로 믿을 수 있는 형태를 부여하는 그래프를 말합니다.
그렇다면 사람은 어디로 가는가
주목할 점은, 사람이 공장을 떠난 적이 없다는 것입니다. 자리를 옮겼을 뿐입니다.
엔지니어는 갈수록 바깥 루프를 책임져야 한다고 생각합니다. 에이전트는 버그를 조사하고, 진단을 정리하고, 수정을 구현하고, 테스트를 돌리고, 보고서를 쓸 수 있습니다. 그것이 안쪽 루프의 실행이고, 에이전트는 그 일을 누구 못지않게 효율적으로 해냅니다. 하지만 그것은 애초에 우리의 일이 아니었습니다. 우리가 책임지는 부분은 제가 바깥 루프라고 부르는 것들입니다. 그것이 문제를 푸는 올바른 방법인지 결정하고, 진단과 구현이 건전한지 확인하고, 변경을 승인하고, 틀렸을 때의 결과를 감당하는 일 말입니다. 두 루프 사이의 경계는 증거입니다. diff, 테스트, 로그, 그리고 이것들을 이어 주는 짧은 설명이 그것입니다. 타입과 심(seam)과 루브릭이 있으면, 변경 하나하나에 많은 품을 들이지 않고도 이 전체를 감독할 수 있습니다.
이렇게 표현하면 이해가 쉬울 것 같습니다. 이제 우리는 라인에 내려가 변경을 직접 만드는 사람이 아니라, 생산 라인의 끝에 서서 라인을 설계하고 게이트를 지키는 사람입니다. 모델을 더 좋게, 하네스를 더 유능하게 만들기 위해 할 수 있는 일은 많지만, 장기적으로 비용이 큰 문제를 알아보는 일만큼은 좀처럼 자동화로 대체되지 않는다는 것을 지켜봐 왔습니다. 여전히 남는 핵심 업무는, 그 어떤 서류의 흐름이나 컴퓨팅 파워보다 사람의 판단을 더 잘 발휘하는 것입니다.
로봇은 어둠 속에서도 잘 움직이지만, 사람은 자기가 무엇을 하는지 볼 수 있어야 합니다. 공장 바닥이 온통 캄캄해서 아무것도 보이지 않고, 조명 스위치조차 찾을 수 없다면, 위험은 바로 거기에 있습니다.
Pangram은 이 글을 100% 사람이 쓴 글로 판정했습니다.