10월 1일 목요일

신호 수집부터 구현, 독립 검증, 프로덕션 학습까지 이어지는 팩토리는 어디에서 책임을 나눠야 하는가?

1. 1

   1. 입력을 분류 가능한 작업으로 바꾼다

   아이디어, 사용자 이슈, 로그와 모니터링 이벤트를 한 입구로 모은 뒤 쉬우면서 명확한 작업은 구현으로 보내고, 복잡한 작업은 제품 명세와 기술 명세를 먼저 만든다. 사람은 코드가 생기기 전에 의도와 보존해야 할 동작을 검토한다. 모든 작업에 같은 계획 비용을 강제하지 않되, 모호한 요구를 구현 단계에 그대로 넘기지 않는 분기 규칙이 필요하다.

2. 2

   2. 제어 평면과 실행층을 분리한다

   작업 유입층은 신호를 받고 제어 평면은 명세·구현·리뷰·검증 중 다음 목적지를 정한다. 실행층은 샌드박스에서 하네스와 모델을 구동하고, 데이터 평면은 과거 결과와 실패를 보존한다. 장기 Mission에서는 오케스트레이터가 완료 조건을 쓰고 워커가 순차적으로 인계해 새 컨텍스트로 이어 가며, 각 워커 내부에서만 조사나 파일 작업을 병렬화할 수 있다.

3. 3

   3. 작성자와 판정자를 갈라 놓는다

   코드를 만든 에이전트가 자기 결과를 승인하게 두지 않는다. 한 검증자는 린터·타입 검사·테스트로 구조를 확인하고, 다른 검증자는 가상 컴퓨터에서 실제 화면을 조작해 사용자가 원하는 동작이 되는지 본다. 기존 CI/CD도 계속 유지한다. 소개된 16시간 Mission에서 검증이 40%를 차지했다는 사례는 검증을 잔여 단계가 아니라 별도 예산과 책임을 가진 작업으로 봐야 함을 보여 준다.

4. 4

   4. 컨텍스트와 코드베이스를 실행 가능하게 정리한다

   수백 개 도구의 전체 명세를 처음부터 넣으면 긴 작업의 컨텍스트가 부풀고 비슷한 도구를 잘못 고를 수 있다. 짧은 목록만 먼저 주고 필요할 때 세부 명세를 불러오는 점진적 공개가 필요하다. 동시에 재현 가능한 개발 환경, 유용한 테스트, 타입 검사, 린터, 문서화된 구조와 관례가 갖춰져야 한다. 팀의 암묵지는 재사용 가능한 스킬과 컨텍스트로 패키징하고 변경 이력을 남긴다.

5. 5

   5. 출하 뒤 신호로 다시 루프를 연다

   배포는 종료가 아니다. 모니터링 에이전트가 충돌과 실제 사용을 관찰해 새 입력을 만들고, 사람의 리뷰 교정은 관찰자 에이전트가 다음 스킬의 개선 제안으로 바꾼다. 공장 성능은 생성 코드량이 아니라 실제 출하량과 품질, 사람의 시간, 토큰 시간과 비용을 함께 비교한다. 잘못된 학습을 되돌릴 측정과 롤백이 없다면 자기개선이라는 이름만으로 품질 상승을 주장할 수 없다.

공장의 최소 경계는 입력 분류, 검증 가능한 명세, 격리된 실행, 독립된 코드·사용자 검증, 프로덕션 되먹임이다. 오래 실행되거나 많은 코드를 만드는 것 자체는 신뢰성의 증거가 아니다. 완료 조건이 실제 사용자 결과를 측정하는지, 모델 라우팅의 재작업까지 포함한 비용이 줄었는지, 사람의 제품 판단이 어느 관문에 남는지를 함께 확인해야 한다.