AI 소프트웨어 공장은 배운 지식을 밖으로 가져올 수 있어야 한다

패트릭 드부아(Patrick Debois)는 AI 기반 소프트웨어 공장을 고를 때 지식을 안으로 가져올 수 있는지만큼, 공장이 쌓은 지식을 다른 도구와 시스템으로 옮길 수 있는지도 살펴야 한다고 말한다. 코드뿐 아니라 조직의 맥락과 작업 방식, 검증 기준까지 재사용할 수 있어야 공급자를 바꾸더라도 배운 내용을 잃지 않는다.

AI 공장은 저장소와 문서, 도구를 연결하는 데서 그치지 않는다. 엔지니어가 아키텍처 결정을 설명하고 검토자가 반복되는 오류를 바로잡으며, 사고를 통해 문서에 없던 제약이 드러난다. 이런 과정에서 조직은 자사 소프트웨어 개발에 관한 지식을 쌓는다. 생성된 코드의 소유권이 있어도 그 코드를 만든 판단과 노하우를 한 플랫폼에 의존한다면, 시스템을 바꿀 때 결정을 다시 구성하고 예외를 재발견해야 할 수 있다.

여러 모델 지원, 외부 코딩 에이전트 연결, 고객이 관리하는 환경에서의 실행, 기존 도구용 인터페이스는 개방성을 높이는 요소다. 하지만 어느 하나만으로 생산 과정에서 축적한 지식을 다른 곳으로 옮길 수 있는지는 알 수 없다. 드부아는 맥락과 학습 결과를 조직이 통제하고 이해하며 재사용할 수 있어야 한다고 주장한다.

조직의 맥락은 저장소와 내부 문서, 티켓, 아키텍처 결정, 업무 시스템, 구성원의 경험에 흩어져 있다. 문서를 가져오는 것만으로는 충분하지 않다. 어떤 문서가 최신인지, 서로 다른 합의가 충돌할 때 무엇을 우선하는지, 예외가 어디에 적용되는지도 알아야 한다. 기존 기술과 지침, 모델 게이트웨이, 평가 도구, 관측 시스템, 승인 절차를 공장에 연결할 수 있어야 한다. 조직은 제공된 작업 흐름을 개선하거나 대체해 맥락을 수집하고 행동을 점검하며 피드백을 반영하는 방식을 통제할 수 있어야 한다.

반복되는 오류를 한 번의 수정으로 끝내지 않고 지속적인 개선으로 만들려면, 배운 내용을 재사용 가능한 산출물로 남길 수 있다. 예를 들어 코딩 에이전트가 내부 서비스를 우회해 데이터베이스에 직접 쓰고, 검토자가 해당 서비스가 제공하는 권한 확인과 감사 기능을 놓쳤다고 설명하는 상황을 생각해 볼 수 있다. 이때 교훈은 여러 형태로 정리할 수 있다.

• 경계와 그 이유를 설명하는 아키텍처 결정
• 해당 유형의 변경 방법을 안내하는 스킬
• 에이전트가 경계를 지키는지 확인하는 평가 사례
• 검토 전에 위반을 찾아내는 자동 검사

대화 기록을 내보내는 것만으로는 어떤 교훈을 받아들였는지, 어디에 적용되는지, 다른 시스템이 제대로 활용하는지 알기 어렵다. 유용한 지식 추출에는 출처와 적용 범위, 검토 상태, 근거가 포함돼야 한다. 스킬에는 의존성이, 평가에는 다시 실행하는 데 필요한 환경 정보가 있어야 한다. 임시 해결책을 정책으로 굳히거나 한시적 예외를 보편 규칙으로 만드는 일을 막으려면 무엇을 보존할지 판단하고 개선 효과를 검증해야 한다.

드부아는 개방성을 실제로 확인할 수 있는 기준으로 투명성, 재현성, 상호운용성, 생태계 재사용을 제시한다. 팀은 실행을 이끈 맥락과 사용된 자료, 피드백 뒤에 바뀐 내용을 살펴보고 생산 규칙에 이의를 제기할 수 있어야 한다. 결과 뒤의 지침과 버전, 도구 응답, 조건도 재구성할 수 있어야 한다. 확률적 시스템은 결과가 달라질 수 있지만, 맥락을 보존하고 로컬 테스트 환경을 갖추면 실행을 다시 살펴보고 비교할 수 있다.

모델뿐 아니라 애플리케이션, 실행 절차, 메모리 시스템, 도구도 특정 공급자에 대한 의존성을 만들 수 있다. 어댑터를 마련하거나 다시 시험해야 할 수는 있지만, 조직의 지식을 다시 구축하는 일이 공급자를 바꾸는 대가가 되어서는 안 된다. 한 도구로 만든 스킬을 다른 도구로 평가하고 여러 작업 흐름에서 쓸 수 있는지, 기존 게이트웨이와 연결 도구, 모니터링을 유지할 수 있는지도 살펴야 한다. 공통 형식만으로 동등한 동작이나 권한, 메모리 처리까지 보장되지는 않는다. 다른 시스템에서 산출물을 사용하고 조직의 검사를 통과하는지가 더 중요한 증거다.

지식을 명시적인 산출물로 만들면 조직 내부의 협업에도 도움이 된다. 개인 대화에서만 공유되던 서비스 규칙을 제품팀이 찾아볼 수 있고, 반복되는 검토 의견을 팀이 논의할 수 있는 기준으로 바꿀 수 있다. 여러 팀이 변경을 제안하고 근거를 검토하며 권위 있는 버전을 확인할 수 있다. 다만 공유 맥락이 모두에게 공개돼야 한다는 뜻은 아니다. 민감한 정보는 적절한 권한을 유지하면서 승인된 사람과 도구가 필요한 업무에서 활용할 수 있어야 한다.

시작부터 전체 플랫폼을 만들 필요는 없다. 같은 맥락을 반복해 설명하거나 같은 오류를 되풀이하는 범위가 분명한 작업 흐름 하나를 고르고, 권위 있는 자료를 연결해 유용한 교훈을 기록한 뒤 스킬과 평가 사례로 관리하는 방법을 제안한다. 이후 그 산출물을 다른 코딩 에이전트나 실행 환경, 다른 팀에서 사용해 보면 원래 환경에 묶여 있던 부분과 별도 조정이 필요한 부분을 파악할 수 있다. 이런 시험은 공급자를 바꿔야 할 때가 오기 전에 숨은 가정을 드러낸다.

로컬, 온프레미스, VPC, 호스팅 방식은 각각 활용할 수 있지만 배포 위치만으로 지식을 살펴보고 재사용할 수 있는지는 알 수 없다. 맥락은 낡을 수 있고 평가에는 관리가 필요하며 통합에도 비용이 든다. 범용적인 작업에는 관리형 제품이 적합할 수 있다. 드부아는 재구성 비용이 큰 차별화 지식에 투자를 집중하되, 공장을 사용하며 조직의 역량을 키우면서도 선택지를 보존해야 한다고 강조한다.