올해 초, 저희 8090 팀은 대규모 법인의 청구 엔진을 분해했습니다. 그 엔진은 일부 엔지니어가 태어나기도 전부터 축적된 1,800만 줄의 COBOL 과 Assembly 코드였습니다. 아무도 완전히 이해하지 못했지만, 저희는 Software Factory 를 사용하여 40일 만에 10만 개 이상의 일반 영어 규칙으로 리버스 엔지니어링했습니다. 그 작업을 마무리하면서 '소프트웨어 팩토리'라는 용어가 갑자기 다른 모든 사람들 사이에서도 사용되는 이유를 깨달았습니다.
이 개념은 기업이 원하지만 얻지 못하고 있는 일정 수준의 산업적 신뢰성을 암시하기 때문에 차용되고 있습니다. 소프트웨어 팩토리에는 50년의 역사가 있으며, 그 고유의 특징은 기업들이 그 어느 때보다 필요로 하는 것, 즉 결과물을 보장하는 생산 시스템입니다. 이는 개인에게 권한을 부여하지만 전체 시스템을 더 혼란스럽게 만드는 광범위한 도구 집합에 대한 증가하는 불만과 대조를 이룹니다.
용어는 대부분이 생각하는 것보다 오래되었다
히타치(Hitachi)는 1969년에 "Software Works"를 문자 그대로의 공장으로 열었습니다. 통계적 품질 관리 하에 소프트웨어가 생산되고, 코드 천 줄당 결함률이 측정되며, 표준화된 프로세스와 출력 품질에 책임을 지는 관리 팀이 있는 건물이었습니다. 도시바, NEC, 후지쯔가 그 뒤를 따랐고, 1970년대와 1980년대를 거쳐 이 일본 소프트웨어 공장들은 지금까지 작성된 코드 중 가장 신뢰할 수 있는 코드를 일부 출시했습니다. 이들이 생산한 시스템은 수십 년 동안 은행, 철도 및 전력 인프라를 운영했습니다.
2004년, 두 명의 Microsoft 아키텍트가 "Software Factories"라는 책을 출판하여 소프트웨어는 자동차가 만들어지는 방식, 즉 검증된 부품으로, 반복 가능한 생산 라인에서, 변형은 사후 히어로들의 노력이 아닌 사전 설계에 의해 제어되어야 한다고 주장했습니다. 미 공군은 오늘날에도 소프트웨어 팩토리를 운영합니다. Kessel Run 은 국방부를 위한 임무 소프트웨어를 구축하고 운영하며, 해당 소프트웨어가 고장 나면 그들이 책임을 집니다.
60년 동안, 이 AI 물결이 오기 전까지 한 가지는 일관되게 유지되었습니다. 공장은 아무리 훌륭해도 도구나 생산성 향상 해킹이 아니었습니다. 공장은 투입물을 받아 완제품을 생산하고 그 제품의 품질에 대해 책임을 지는 생산 시스템이었습니다. 다르게 말하면, 포드는 렌치와 부품 몇 개를 판매하고 행운을 빌어주지 않았습니다. 포드는 자동차를 판매했고, 자동차에 문제가 생기면 포드가 리콜했습니다. 그 자동차를 생산한 것은 바로 그들의 공장이었기 때문입니다.
이것이 기준이며, 현대의 소프트웨어 팩토리도 이 기준을 따라야 한다고 저는 주장합니다.
다섯 가지 테스트
소프트웨어 팩토리는 다섯 가지 테스트를 통과해야 합니다. 하나라도 놓치면 그것은 다른 것입니다. 그 다른 것은 아마도 개발자 도구일 가능성이 높으며, 유용할 수는 있지만 다른 의무를 가진 다른 제품입니다.
테스트 1: 공장은 비즈니스 의도에서 시작된다. 공장의 투입물은 비즈니스가 필요로 하는 것이며, 비즈니스의 언어, 즉 요구사항, 규칙, 규제 제약, 원하는 결과로 표현됩니다. 대신 투입물이 엔지니어가 다른 엔지니어를 위해 작성한 Jira 티켓이라면, 당신은 기존 프로세스에 부착된 전동 공구를 보고 있는 것입니다. 공장의 요점은 고객이 제품을 설명하고 공장이 생산을 알아서 처리한다는 것입니다.
테스트 2: 공장은 지속적인 변화 속에서도 일관성을 유지한다. 이것은 가장 어려운 테스트이며, AI 도구 시장의 거의 모든 업체가 이야기하지 않는 테스트입니다. 왜냐하면 그들의 제품이 상황을 악화시키기 때문입니다.
새로운 코드를 작성하는 것은 엔터프라이즈 소프트웨어에서 결코 병목 현상이 아니었습니다. 병목 현상은 실제 시스템이 수십 명의 사람들에 의해 매주 변경된다는 사실입니다. 모든 변경은 시스템이 분리될 기회입니다. 요구사항은 문서화에서 이탈합니다. 문서화는 코드에서 이탈합니다. 코드는 테스트에서 이탈합니다. 이러한 이탈이 20년 동안 축적되도록 놔두면, 제가 처음에 설명한 청구 엔진, 즉 아무도 완전히 이해하지 못하는 1,800만 줄, 매년 5~8%씩 증가하는 공급업체 유지보수 계약, 그리고 더 이상 두려움 없이 자체 소프트웨어를 변경할 수 없는 조직이 탄생합니다.
현실은 코드 생성이 이탈을 가속화한다는 것입니다. 에이전트가 동기화되지 않은 명세에 대해 10배 더 많은 코드를 생성한다면, 전례 없는 속도로 이탈을 유발하는 것입니다. 1,800만 줄 문제는 수동으로 구축하는 데 40년이 걸렸지만, 거버넌스가 없는 에이전트 플릿은 몇 년 안에 이를 구축할 것입니다.
제대로 기능하는 소프트웨어 팩토리는 의도, 명세, 코드, 테스트 및 프로덕션 동작을 하나의 관리되는 객체로 동기화된 상태로 유지합니다. 요구사항이 변경되면 코드가 변경됩니다. 코드를 핫픽스하면 요구사항이 업데이트됩니다. 공급업체에게 이 루프가 실제 시스템에서 실시간으로 닫히는 것을 보여달라고 요청하십시오. 그렇게 할 수 없다면 그들은 코드 생성을 판매하는 것입니다. 그리고 유용하긴 하지만, 그것은 다른 것입니다.
테스트 3: 공장은 특정 개인과 무관하게 운영된다. 도구는 그것을 쥔 사람만큼만 좋습니다. 동일한 코딩 에이전트를 두 명의 엔지니어에게 주면, 누가 프롬프트를 작성하고, 누가 diff를 검토하고, 누가 실수를 발견하는지에 따라 완전히 다른 결과가 나옵니다. 이러한 차이는 도구에서는 허용될 수 있습니다. 하지만 생산 시스템에서는 실격 사유입니다. 공장은 누가 교대 근무를 하든 예측 가능한 속도와 품질로 생산해야 하며, 이것이 바로 히타치의 통계적 관리가 보장하기 위해 구축된 것입니다: 운영자가 아닌 라인의 속성으로서의 품질.
공장이 이를 달성하는 방법은 지식이 개인이 아닌 시스템에 축적된다는 것입니다. 사람이 합류하면 공장은 이미 배운 모든 것을 그 사람에게 전달합니다. 사람이 떠나면 아무것도 밖으로 나가지 않습니다. 대부분의 엔터프라이즈 소프트웨어는 이 테스트를 참담하게 실패합니다. 청구 엔진이 판독 불가능해지는 이유는 나쁜 코드 때문이 아닙니다. 코드에 대한 이해가 사람 속에 살아 있고, 수년에 걸쳐 사람들이 바뀌기 때문입니다. 그들의 지식이 시스템에 의해 포착되지 않으면, 시스템은 서서히 블랙박스가 될 것입니다.
분명히, 이것은 사람이 중요하지 않거나 공장이 책임을 요구하지 않는다는 것을 의미하지 않습니다. 공장에는 항상 결과물에 대해 책임을 지는 특정인이 있습니다. 단지 그들 중 누구도 대체 불가능한 존재에 의존하지 않을 뿐입니다. 기능하기 위해 히어로가 필요한 시스템은 책임성도 공장도 없습니다. 히어로가 있을 뿐이며, 히어로는 결국 새로운 모험을 찾아 떠납니다.
테스트 4: 모든 출력 단위는 추적 가능하다. 실제 공장에서는 모든 부품에 "로트 번호"가 있습니다. 무언가 실패하면, 생산 라인을 거슬러 배치, 기계 및 교대 근무까지 추적합니다. 규제 산업은 소프트웨어에 정확히 이것을 요구하며, 이것이 AI 코딩 도구 채택이 가장 느린 이유입니다. "모델이 작성했습니다"는 감사관이 수용하는 답변이 아닙니다. 소프트웨어 팩토리는 생산 자체의 부산물로 감사 추적을 생성합니다: 이 규칙은 이 요구사항 때문에 존재하며, 이 사람의 승인을 받았고, 이 변경으로 구현되었으며, 이 테스트로 검증되었고, 이 시간에 배포되었습니다. 출처(Provenance)가 생산 라인에 내장되어야 하므로, 사후에 작성된 문서는 인정되지 않습니다.
테스트 5: 누군가 완제품에 대해 책임을 진다. 이것은 소프트웨어 팩토리와 개발자 도구를 구분하는 테스트입니다. 대부분의 도구 공급업체가 기꺼이 충족시키려 하지 않기 때문입니다.
공장은 자신이 보증하는 제품을 출시합니다. 청구 엔진이 클레임을 잘못 계산하거나, 거래 시스템이 잘못된 숫자를 생성하거나, 제조 검증이 불량 부품을 승인할 때, 특정인이 이에 대해 책임을 지고, 수정하고, 비용을 부담합니다. 저는 지금까지 많은 AI 도구 계약서를 읽어보았습니다. 지식 재산권 섹션은 수 페이지에 걸쳐 있지만, 책임 섹션은 대개 한 문장이며, 그 문장은 출력물이 있는 그대로 제공되며 검증은 귀하의 책임입니다라고 말합니다. 이것은 공장으로서 완전히 실격입니다.
저희 고객 중 하나인 상장된 건강 보험사는 지불 가능한 청구 규칙을 결정론적 사전 필터로 전환하여 건당 수수료(Pay-per-Catch)를 받는 공급업체로 라우팅되는 청구를 80% 이상 줄였고, 4년 동안 2천만 달러 이상의 비용을 절감했습니다. 이와 같은 수치는 작업을 수행하는 당사자가 결과에 대해 책임을 질 때만 발생합니다.
공장이 아닌 것
테스트를 적용해 보면, 스스로를 공장이라고 부르는 많은 것들이 실제로는 다른 것입니다.
코딩 에이전트는 아무리 훌륭해도 도구입니다. 이들은 엔지니어링 작업을 입력으로 받아 코드를 출력으로 생성하고, 모든 검증 및 책임을 고객의 엔지니어에게 전가합니다. 이들의 플릿을 공장이라고 부르는 것이 이것을 바꾸지는 않습니다.
에이전트 오케스트레이션 대시보드는 감독 도구입니다. 에이전트가 작업하는 것을 더 쉽게 관찰할 수 있게 해줍니다.
벤치마크는 도구를 위한 측정 하네스입니다. 높은 점수는 도구가 벤치마크된 작업에 능숙하다는 것을 알려줍니다. 인간과 에이전트로 구성된 혼합 팀이 2년 동안 지속적으로 변경한 후에도 시스템이 일관성을 유지하는지 여부는 알려줄 수 없습니다.
지금 정의가 중요한 이유
소프트웨어를 생산하는 비용은 급락하고 있습니다. 그리고 생산 비용이 급락하면, 가치는 결과물을 보장할 수 있는 사람에게 이동할 것입니다. 이것은 이전의 모든 산업화 과정에서 일어났으며, 지금 AI 에서도 다시 일어날 것입니다.
"공장"이라는 단어를 붙잡으려는 스타트업들은 본능적으로 이것을 이해합니다. 그러나 많은 이들이 그 신뢰성을 창출한 의무를 수용하지 않고 산업적 생산의 신뢰성에 도달하려고 합니다.
따라서 데모와 벤치마크는 무시하고, 모든 소프트웨어 팩토리에 한 가지 질문을 하십시오: 시스템이 프로덕션에서 고장 났을 때, 누가 전화를 받습니까?
소프트웨어 팩토리의 경우, 답변은 "저희가 받습니다"여야 합니다.
