소프트웨어 팩토리, 밝음과 어둠

소프트웨어 팩토리는 대규모로 루프를 활용합니다. 인간이 루프에 참여하게 할 수도 있습니다(라이트 팩토리). 이때 판단력과 집중력을 속도 및 결함 위험과 맞바꾸게 됩니다. 또는 인간을 배제하고(다크 팩토리), 에이전트가 아무도 세부 사항을 제대로 읽지 않은 채 코드의 범위 설정, 구현, 배포를 수행하게 할 수도 있습니다. 하지만 사람들이 읽기를 멈추면, 여러분의 소프트웨어를 이해하는 일도 멈추게 됩니다. 이제 가장 어려운 일은 어떤 검사를 구축하고 얼마나 많은 자율성을 위임할지 아는 것입니다.

소프트웨어 팩토리라는 개념은 1968년에 발표된 Bob Bemer의 논문 「프로그램 생산의 경제학」까지 거슬러 올라갑니다. 반세기 동안 많은 사람이 소프트웨어가 개인의 고립된 장인 작업이 아니라, 공장에서 자동차 부품을 찍어 내듯 반복 가능하고 계측 가능한 생산 과정이 되는 세상을 꿈꿔 왔습니다. 역사적으로 이 꿈은, 보편적이지는 않지만 대체로 실현되지 못했습니다. 아이디어를 찍어 내는 일이 어렵기 때문이기도 합니다.

하지만 지난 2년 사이 상황은 극적으로 달라졌고, 이제는 그 오래된 꿈을 새롭게 살펴볼 만합니다. 또한 몇몇 미묘한 점은 쉽게 간과될 수 있으므로, 정확히 무엇이 정말 새롭고 다른지, 또 새로운 기회로 꾸며진 반복적 함정은 무엇일지를 어느 정도 정밀하게 짚어 볼 가치가 있습니다.

HumanLayer의 공동 창립자인 Dex Horthy는 최근 AI Engineer World’s Fair에서 이 주제와 관련해 꼭 볼 만한 훌륭한 발표를 했습니다. 제목은 **「하니스 엔지니어링만으로는 충분하지 않다: 소프트웨어 팩토리가 실패하는 이유」**입니다.

구조가 전부이며, 모든 것은 작은 단위에서 시작합니다. 전체 스택은 사실 세 개의 개념이 서로 쌓인 것입니다. 루프, 하니스, 그리고 팩토리입니다.

루프는 하나의 에이전트가 단일 작업을 반복해서 수행하는 것입니다. 즉, 맥락을 수집하고, 행동을 취하고, 결과를 확인한 뒤, 어떤 조건이 충족될 때까지 다시 수행합니다. 이는 에이전트 작업의 가장 작은 단위이며, 그 위의 모든 것은 루프 위에 쌓인 루프일 뿐입니다.

루프 엔지니어링의 핵심은 에이전트에게 매번 차례대로 프롬프트를 주는 일을 멈추고, 대신 그 프롬프트를 대신 제공할 작은 시스템을 설계하는 데 있습니다.

하니스는 루프를 둘러싼 벽입니다. 즉, 루프가 실행되는 샌드박스, 접근할 수 있는 도구, 실행 사이에 유지되는 메모리, 그리고 무엇을 ‘완료’로 볼지 결정하는 관문입니다. 루프는 행동이고, 하니스는 그 행동이 실행되는 환경입니다.

하니스 없이 원시 모델을 넘겨주면, 모델은 기꺼이 영원히 반복할 것입니다. 하니스는 모델을 유용하고 안전하게 실행할 수 있게 만드는 그 주변의 모든 것입니다.

소프트웨어 팩토리는 하니스가 갖춰진 많은 루프가 동시에 실행되는 구조입니다. 작업 대기열에서 일을 받아 검토 관문을 거쳐 프로덕션으로 내보내며, 인간은 위에서 그 전체를 책임집니다. 이는 더 큰 에이전트가 아니라, 루프로 이루어진 조직도입니다.

마지막 패러다임 전환은 코드를 작성하는 일에서, 코드를 작성하는 팩토리를 구축하고 운영하는 일로 이동하는 것입니다. 작업의 단위는 개별 코드 변경분이 아니라, 루프와 하니스, 그리고 그 사이의 흐름으로 한 단계 올라갑니다.

루프 → 하니스 → 팩토리. 팩토리는 더 똑똑한 에이전트가 아닙니다. 하나의 검토 관문으로 흘러가는 여러 하니스 루프이며, 인간이 바깥 루프를 책임집니다.

Dex가 가장 많은 시간을 할애한 핵심 슬라이드는 훌륭했습니다. 달리 보면 자명한 루프를 시각화한, 이해를 명확하게 해 주는 배선도이기 때문입니다. 다음은 제가 해석한 내용입니다.

팩토리는 폐쇄 루프입니다. 의도와 프로덕션 신호가 대기열로 흘러들고, 하니스가 구축하며, 자동화된 검사와 검토가 관문 역할을 하고, 배포가 이를 내보내며, 모니터링이 프로덕션을 다시 신호로 전환합니다.

의도는 엔지니어링 리더십의 비전과 엔지니어들로부터 직접, 수행해야 할 일의 대기열로 흘러갑니다. 인시던트와 사용자 요청에서 비롯된 신호도 같은 대기열로 들어갑니다. 하니스는 대기열에서 항목 하나를 골라 그에 대한 변경 사항을 만드는 존재일 뿐입니다. 하니스 다음에는 변경 사항을 프로덕션에 넣어도 충분히 안전하게 만들기 위해 필요한 모든 자동 검사가 보입니다. CI, 테스트, 정적 분석, 온갖 종류의 스캐닝 덕분에 이 자동 검사들은 엔지니어의 의식적인 개입 없이도 동시에, 수월하게 실행됩니다. 여기서 유일한 의사결정 지점은 검토 관문입니다. 승인 뒤 변경 사항은 프로덕션에 배포되고 모니터링되며, 모니터링 데이터는 처음에 루프를 움직이게 했던 신호로 다시 피드백됩니다.

대체로 이 다이어그램의 모든 상자는 거의 비용이 들지 않습니다. 생성, 테스트, 스캐닝 모두 무시할 만한 비용으로 대규모 실행이 가능합니다. 확장에 완강히 저항하는 비싼 상자는 단 하나, 검토 관문뿐입니다. 반짝이는 호박색 상자는 ‘판단’이며, 개발을 더 빠르고 빈번하게 할 수 있는지에 관한 논쟁의 핵심이 자리한 곳입니다.

다크 팩토리는 물리적으로 불을 끈 채 운영됩니다. 작업장에 있는 것이 기계뿐이고, 기계에는 보기 위한 빛이 필요 없기 때문입니다. 다크 소프트웨어 팩토리도 같은 방식입니다. 인간이 읽지 않은 코드가 다른 기계의 검증만 거쳐 배포됩니다.

이 비유는 제조업에서 가져왔습니다. 그 기원은 디지털이 아니라 물리적이며, 불을 끄고 로봇이 작업을 수행하는 시설에 뿌리를 둡니다. 일본의 FANUC는 2001년부터 이런 종류의 무인 공장을 운영해 왔고, Xiaomi는 2024년에 고도로 자동화된 자체 다크 팩토리를 열었습니다. 이들이 공유하는 특성은 단 한 명의 인간도 그 어떤 부분도 읽지 않은 채 제품이 조립되고 출하된다는 것입니다. ‘어둠’은 읽는 행위가 과정에서 제거될 때 생깁니다.

저는 분위기 때문에, 또는 비난하려고 이 개념을 빌려오는 것이 아닙니다. 섬뜩하게 들릴 수 있지만, 여기서 ‘다크’는 단순한 물리적 주장입니다. 원래의 공장 바닥에서 빛만 없는 상태입니다. 소프트웨어에서 작업장은 변경분입니다. 변경분을 작성한 사람, 검토한 사람, 배포한 사람이 모두 사라지고, 남는 것은 이를 만든 기계만이 검증한 변경분입니다.

이는 적어도 처음에는 놀랄 만큼 쉽게 할 수 있습니다. 누락된 검토 단계가 모든 것을 방해하기 때문에 쉽습니다. 그것이 사라지면 팀의 수직 처리량에 대한 인식은 갑자기 급진적으로 높아진 듯 보입니다. 음속 장벽을 깬 것처럼 느껴집니다. 그러나 겉보기에 쉬워도, 묻혀 있는 모든 비용을 안고 그러한 다크 워크플로를 견뎌 내기는 보기보다 어렵습니다.

모델이 세상 및 서로와 상호작용할 때 활용하는 오케스트레이션, 샌드박스 프로토타이핑, 도구 호출의 하니스는 점점 더 강력하고 효과적으로 발전할 것입니다. 그러나 장기전에 걸쳐 누적되는 변경 속에서 코드베이스 품질을 유지하려는 시도에는 모델 내부에 내재한 실패가 있습니다. 모델만으로는 결국 이해 부채와의 싸움에서 질 만한 충분한 이유가 있다고 봅니다.

이해 부채는 존재하는 코드의 양과 여전히 어떤 인간이 이해하는 코드의 양 사이에서 점점 넓어지는 격차입니다. 다크 팩토리는 이를 갚지 않습니다. 테스트가 계속 통과하는 내내 가능한 한 빠르게 그 부채를 떠안습니다.

이는 중요한 구분입니다. 모델은 몇몇 과제에서는 잘하기 때문입니다. 하지만 코드베이스의 작은 부분을 즉시 변경하는 일이 아닌 모든 것, 특히 복잡한 기존 시스템에서는 모델만으로 하는 자동화 코딩이 넘을 수 없는 장애물에 맞닥뜨립니다. 주말 장난감 프로젝트와 사이드 프로젝트는 몇 달의 개발 주기면 대개 작동 가능한 상태, 또는 적어도 충분히 가까운 상태에 도달한다는 점에서 비슷합니다. 그러나 10년 이상 개발되어 온 엔터프라이즈 시스템은 다른 짐승입니다. 전문적 환경에서 전문적 속도로 유지보수되어야 합니다. 프로젝트를 시작하고 3개월에서 6개월만 지나도 읽지 않은 코드에 이미 빠져 허우적거리게 됩니다. 이런 환경, 특히 프로덕션 코드가 강제하는 제약은 강력한 에이전트조차 잘 수행하지 못하게 만들 것입니다. 주말 장난감 프로젝트를 만드는 개발자들이 누리는 바이브 코딩과는 대조적입니다.

Dex는 경험상 이것이 중대한 실패라고 말합니다. 원인을 특정하려면 고된 수동 디버깅이 필요할 정도였습니다. 이는 약 4개월 동안 완전 자동화된 코드 팩토리를 운영하며, 작성된 코드를 어떤 인간도 들여다보지 않았을 때의 경험에서 나왔습니다. 이 경험의 바탕에는 서로 충돌하는 두 지표의 상충 관계가 있습니다. 하나는 현재 우리가 진전으로 취급하는 수치인 토큰 활용도를 극대화하는 것입니다. 다른 하나는 조용히 최소화되는 수치로, 어느 순간이든 인간 참여자가 여전히 이해하는 시스템의 양입니다.

다크 팩토리가 진정 빛나는 곳은 테스트가 계속 통과하는 동안 깨끗한 코드를 빠르게 쏟아 내는 능력입니다. 마침내 치르게 될 대가는 극적인 ‘모든 것이 틀어지는’ 순간으로 오지 않을 것입니다. 조용히, 그리고 늦게 올 것입니다.

다크와 라이트는 빛이 놓인 위치만 다른 동일한 파이프라인입니다. 라이트 버전은 끝에 검토를 다시 붙이는 데 그치지 않고, 인간의 판단을 설계와 아키텍처로도 앞당깁니다.

소프트웨어 팩토리의 근본 제약은 우리가 얼마나 많은 코드를 쏟아 낼 수 있느냐가 아닙니다. 얼마나 빨리 그것을 검증할 수 있느냐입니다.

역압은 저렴하고 신뢰성 있게 검증할 수 있는 만큼의 자율성만 루프에 맡길 수 있으며, 그 이상은 한 치도 안 된다는 규칙입니다. 팩토리의 진짜 제약은 생성이 아니라 검증입니다.

무한한 생성 능력은 유한하고 확장되지 않는 자원인 인간의 주의력과 끊임없이 긴장 관계에 있으므로, 핵심 문제는 저렴한 생성과 제한된 검토 사이의 격차입니다. 깔때기를 보십시오. 검증을 나타내는 목이 넓어지지 않는 한, 작업은 계속 밀려 쌓입니다. Dex가 지적하듯 문제는 양만이 아닙니다. 우리가 실제로 겪는 것은 나쁜 PR의 과잉입니다. 신뢰할 수 있는 관문 없이 많은 양이 쏟아지면, 인위적으로 만들어진 결함은 피할 수 없습니다. 이것 역시 역압입니다. 저렴하고 신뢰성 있게 검증할 수 있는 범위를 넘어 자율성이 확장될 수는 없습니다.

한 단계 더 나아간 문제는 모델을 개선한다고 해서 모델이 생성할 수 있는 것과 검증할 수 있는 것 사이의 격차가 자동으로 좁아지지 않는 이유입니다. 잘 설계된 시스템으로 학습하는 일은 단순한 테스트 통과보다 더 어려운 과제라고 할 수 있습니다. 아키텍처적 탁월성을 측정하는 비용 함수는 수초나 수분 단위가 아니라 수개월과 수년 단위로 측정된다는 점을 기억하십시오. 깔끔한 그래디언트를 계산하는 것은 사실상 불가능하므로, 복잡한 설계 결정에 대한 명확하고 즉각적인 평가를 기대하는 시스템은 좋은 사례로 학습되지 못할 것입니다.

생성은 넓은 입구이고 검증은 좁은 목입니다. 입구의 속도를 높이면 목에 쌓이는 더미만 깊어집니다.

라이트 팩토리는 판단이 존재하는 곳에 불을 켜 둔 동일한 파이프라인입니다. 에이전트는 여전히 대부분의 구축을 수행하지만, 인간이 결과물을 배포 전에 읽으며, 잘못된 판단의 비용이 큰 곳에서는 계속 불이 켜져 있습니다.

라이트 버전은 끝에 검토를 덧붙이지 않습니다. 에이전트가 루프를 시작하기 전에 인간 판단의 지점을 제품, 설계, 아키텍처로 앞당깁니다.

그 초반 한 시간의 좋은 점은 구현 시간이 줄어든다는 것입니다. 길고 답답한 코드 검토를 200줄짜리 계획을 빠르게 읽는 일로 바꿉니다. 만들어지기 전에 결정을 검토할 수 있으므로, 나중에 그 결정이 무엇이었는지 찾기 위해 생성된 2,000줄의 코드를 뒤쫓을 필요가 없습니다. 어떤 결정은 비용이 크고 오래 지속되므로 비용이 누적되기 전에 일찍부터 사람이 참여하길 원할 것입니다. 물론 사전에 시간을 들였더라도 변경분을 살펴봐야 할 때는 여전히 있습니다.

이 모든 것이 화려하지 않다고 생각할 수 있습니다. 맞습니다. 안전망은 우리가 늘 알고 있었지만 대체로 무시해 온 지극히 평범한 아키텍처 관행으로 이루어집니다. 즉, 실수가 프로덕션이 아니라 컴파일러에서 잡히도록 하는 좋은 타입과 메서드 시그니처, 행동을 고정하고 변경을 관찰할 수 있는 테스트 심, 다음 독자(인간이든 모델이든)가 자신이 신경 쓰는 대상을 어디서 찾을지 알도록 코드를 배치하는 일, 짧고 읽기 쉬운 호출 스택 유지, 변경의 영향 범위가 지나치게 커지지 않도록 잘 정의된 컴포넌트 경계 유지, 그리고 한 부분을 다른 부분으로 교체할 수 있게 하는 의존성 주입입니다. 어느 것도 새롭지 않습니다. 우리는 늘 좋은 아키텍처를 중요하게 여긴다고 말해 왔습니다. 하지만 이제 자동화된 코딩 에이전트를 사용하면서, 그 아키텍처는 마침내 에이전트가 저지를 실수에 맞서는 저렴하면서도 속이기 어려운 안전망이라는 두 번째 일을 하고 있습니다.

그 안전망은 모델 밖에 존재해야 합니다. 모델이 이를 제공하지 않기 때문입니다. 가장 유능하게 느껴지는 코딩 에이전트, 그중 Claude Code와 Codex는 자신들의 하니스와 도구에 맞춰 강화 학습되었습니다. 즉, 업계의 모든 도구와 관용구에는 능숙하지만 장기 유지보수성 같은 것에는 능숙하지 않습니다. 우리가 늘 이야기해 온 신중한 아키텍처는 그 부채를 포착하는 도구이며, 여기에 투자하는 일은 우리의 자율성을 되사 오는 일입니다. 이를 안전한 인프라와 결합하면, 감독 없이 실행할 수 있는 촘촘하고 저위험의 루프가 생깁니다. Horthy는 최근 글에서 한 사례를 설명했습니다. 매일 밤 GitHub Actions 크론 작업이 린트 위반이나 불필요하게 선택적인 속성처럼 정확히 하나의 안티패턴을 수정하고, 커밋한 뒤 작은 풀 리퀘스트 하나를 스스로 엽니다. 그러면 팀은 약간 더 나아진 코드베이스와 읽을 수 있을 만큼 짧은 변경분을 맞이합니다. 하지만 위험도가 충분히 높은 루프라면, 망가진 인증 시스템, 결제 엔진, 또는 공개 API 계약을 맞이할 위험을 감수하고 싶지 않을 것입니다. 그런 곳에서는 불을 켜 두고, 판단력과 시스템에 대한 실제 작업 지식을 가진 사람이 실수를 잡아낼 것이라 믿으십시오.

이 규칙은 이를 역압, 검증, 혹은 전등 스위치라 부르든 적용됩니다.

어떤 루프가 완전 자동화 상태를 얻으려면, 검사가 저렴하고 높은 빈도로 실행되며 쉽게 속일 수 없는 무언가에 의존해야 합니다. 참 또는 거짓 오라클, 타입 관문, 속성 테스트, 실제 루브릭과 결합한 검토 에이전트가 모두 여기에 들어맞습니다. 오라클은 즉시 답해야 하며 시간이 지나도 표류하지 않아야 합니다. 완료를 당신뿐 아니라 기계도 증명할 수 있을 때 자동화에 도달한 것입니다.

짧은 루프는 긴 루프보다 검증하기 쉽습니다. Dex의 경험칙에 따르면, 에이전트는 3단계에서 10단계까지는 버티지만 20단계를 넘어서면 맥락을 놓치기 시작합니다. 이유는 맥락 누적입니다. 에이전트가 끌고 가는 것이 많을수록 딴길로 샐 가능성이 커집니다. 루프가 짧으면 검증 비용도 낮습니다. 지나치게 넓게 펼쳐진 루프는 구석에 실수를 숨기며, 이는 곧 무인 운영 자격을 결코 얻지 못했다는 다른 표현입니다.

불을 켜 두는 경우는 반대입니다. 잘못된 답의 비용이 크고 오직 사람만 잡아낼 수 있다면 루프를 검토해야 합니다. 테스트로 잡을 수 없는 미묘한 프로덕션 버그, 큰 영향 범위, 1년 이상 작업의 방향을 결정할 판단이 모두 해당합니다. 그런 경우 여러분의 주의력은 실제 제품이며, 비용이 크지만 필수적인 제품입니다.

위험은 각 스위치를 전환하는 일을 잊고 모두 같은 모드로 설정하는 데 있습니다. 전부 다크로 두면, 4개월 뒤 모든 것을 허물고 다시 지어야 하는 상황에 갇힙니다. 전부 라이트로 두면, 아무도 제때 검토를 끝내지 못해 거대한 병목에 갇힙니다. 어렵고 숙련이 필요한 일은 각 스위치를 어디에 놓을지 결정하는 것입니다.

에이전트에게 작업을 맡기면, 그것을 유한 상태 기계라고 부르든 조건부로 연결된 서비스 호출 집합이라고 부르든, 아마도 그 주위에 그래프를 구축하게 될 것입니다. 이는 소프트웨어가 단지 어떤 추상적 규칙을 따르는 것이 아니라 구조화된 워크플로를 따르는 틀입니다. 모든 노드는 명시적인 단계이고, 노드 사이의 모든 간선은 명시적인 조건입니다.

구조가 많아 보이지만, 모든 코드는 제어 흐름 그래프로 표현할 수 있으므로 대부분은 이미 어떤 소프트웨어에나 존재합니다. 따라서 진짜 새로움은 자율성을 요구하는 에이전트가 사실 특정 그래프 안을 돌아다니는 것일 뿐이며, 그 자유는 노드 내부로 제한된다는 점입니다. 그리고 사람들이 잊는 부분, Dex가 1년 전에 적어 둔 부분은 이렇습니다. 소프트웨어에는 언제나 그 구조가 있게 마련이었습니다. 과거에 프로그램을 흐름도로 그렸던 데는 이유가 있습니다. 진정으로 새로운 시도는 다이어그램을 버리려 했던 것입니다. 모델이 도구 호출을 하나씩 선택하는 루프에 기대어, 모델이 스스로 완료되었다고 선언할 때까지 진행하게 한 것입니다. 10년 된 코드베이스를 만나기 전까지는 해방처럼 느껴졌습니다. 이제 모두가 재발견하는 규율, 즉 자신의 제어 흐름을 소유하는 일은 사실 그래프를 다시 루프 주위로 되돌려 놓는 일입니다. 그러므로 루프에서 그래프로 돌아가야 하는지의 질문은, 애초부터 흐름도가 필요했다는 사실을 거의 인정하는 셈입니다.

실제 모습은 이렇습니다. 수정할 버그 하나를 생각해 봅시다. 순수한 루프라면 앉아서 이렇게 생각합니다. 무엇이 잘못됐는지 파악하고, 코드를 조금 바꾸고, 테스트를 실행하고, 어떤 일이 일어나는지 본 뒤, 그 시도가 실행을 죽이지 않았다면 다시 돌아가 처음부터 시작합니다. 어떤 문제를 추적할지, 정확히 어떤 코드를 바꿀지, 어떤 테스트를 어떤 순서로 실행할지, 테스트를 아예 실행할지, 다시 시도할지 승리를 선언할지까지 여정 전체가 진행하면서 결정됩니다. 그래프로는 우선 어떤 일이 일어나야 하는지 지도를 그립니다. 버그를 재현하거나 정보를 더 요청하고, 원인을 찾고, 수정을 시도하고, 테스트를 실행합니다. 실패한 실행은 수정 단계로 되돌아가고, 통과한 실행은 검토로 향하며, 승인만이 완료에 도달합니다. 에이전트는 각 상자 안에서는 여전히 영리합니다. 단지 여러분이 승인한 경로 밖으로 벗어날 수 없을 뿐입니다. Santi는 차이를 명확히 보여 주는 다이어그램으로 이를 설명했습니다.

물론 그 그래프의 진짜 매력은 역압을 다이어그램으로 그렸다는 점입니다. 에이전트의 자유를 일부 포기하는 대신 필수 검사와 읽기 쉬운 실패 지점을 얻습니다. 따라서 실행이 죽으면 그것을 죽인 노드를 가리킬 수 있습니다. 이는 대부분의 이른바 에이전트는 사실 그다지 에이전트답지 않다는 Dex의 직설적인 말과 같은 본능입니다. “대부분 결정론적 코드에, 정확히 알맞은 지점마다 LLM 단계를 뿌린 것”이라는 말입니다. 또한 이것은 사람들이 현재 우연히 무언가를 구축하는 방식의 산물만도 아닙니다. LangGraph와 LlamaIndex Workflows, 실행 중 그래프의 일부를 확장하는 바깥 루프를 둔 Jerry Liu의 에이전트 위 하이브리드 워크플로 그래프, 그리고 이것이 사실 새 옷을 입고 나타난 상태 기계와 액터 모델일 뿐이라는 David Khourshid의 지적에서도 그 패턴을 볼 수 있습니다.

용어가 심하게 과적되어 있으므로 한 가지를 분명히 하겠습니다. 제가 계속 이를 그래프라고 부를 때, 지식 그래프를 뜻하는 것이 아닙니다. 조건부 간선을 모두 포함해 작업이 어떻게 흘러야 하는지를 미리 정의한 방향 그래프를 말합니다. 즉, 실제로 신뢰할 수 있는 형태를 루프에 부여하는 그래프입니다.

사람은 결코 팩토리를 떠나지 않았습니다. 자리를 옮겼을 뿐입니다.

엔지니어는 점점 더 바깥 루프를 책임져야 한다고 생각합니다. 에이전트는 버그를 조사하고, 진단을 작성하고, 수정을 구현하고, 테스트를 실행하고, 보고서를 작성할 수 있습니다. 그것은 안쪽 루프의 실행이며, 에이전트는 누구 못지않게 효율적으로 수행할 수 있습니다. 하지만 그것은 본래 일이 아니었습니다. 여러분이 책임지는 부분은 바깥 루프라고 부를 수 있는 것입니다. 그것이 문제를 해결하는 올바른 방식인지 결정하고, 진단과 구현이 타당한지 검증하고, 변경을 승인하며, 틀렸을 때의 결과를 감당하는 일입니다. 두 루프의 경계는 증거입니다. 변경분, 테스트, 로그, 그리고 그것들을 연결하는 간단한 설명입니다. 타입, 심, 루브릭은 변경마다 많은 일을 직접 하지 않고도 이 모든 것을 감독할 수 있게 합니다.

이렇게 표현하는 것이 유용하다고 생각합니다. 이제 여러분은 생산 라인 아래에서 변경을 작성하는 사람이 아닙니다. 생산 라인의 끝에서 그것을 설계하고 관문을 지키는 사람입니다. 모델을 더 좋게 만들고 하니스를 더 유능하게 만드는 일은 많이 할 수 있습니다. 하지만 장기적으로 비용이 큰 문제를 식별하는 일은 대개 자동화로 없앨 수 있는 일이 아니라는 점을 관찰했습니다. 여전히 핵심 업무는 어떤 문서 흐름과 컴퓨팅 파워보다 더 나은 인간 판단을 발휘하는 것입니다.

로봇은 어둠 속에서 작동해도 괜찮지만, 인간은 자신이 무엇을 하는지 볼 필요가 있습니다. 공장 바닥의 모든 것이 어둡고 아무것도 보이지 않으며 전등 스위치조차 찾을 수 없다면, 위험은 바로 거기에 있습니다.

Pangram은 이 글을 100% 인간이 작성한 글로 평가했습니다.