AI 소프트웨어 팩토리: 코드보다 먼저 확인할 ‘완료 증거’ 카드
Greg Isenberg의 Software Factory 영상에서 나온 isolate·build·prove·ship 흐름을 작은 팀의 완료 기준으로 바꿨습니다. AI에게 기능을 맡기기 전, 무엇이 바뀌고 어떻게 확인할지 한 장에 적는 방법입니다.
Greg Isenberg의 9월 14일 Building a Software Factory 영상은 AI 코딩 흐름을 isolate, build, prove, ship으로 나눕니다. 이 글에서 주목할 부분은 도구 이름이 아니라 prove, 즉 증명 단계입니다. 여러 에이전트가 코드를 만들 수 있을수록 사람이 “완료됐다”는 말만으로 검토하기 어려워집니다.
AI 소프트웨어 팩토리는 특정 제품을 사는 일이 아닙니다. 작은 변경을 분리하고, 유지할 수 있게 만들고, 눈으로 확인 가능한 결과를 남기고, 검토를 거쳐 내보내는 운영 습관입니다. 이미 보안 검사나 코드 리뷰가 있다면 대체하지 말고, 그 사이에 완료 증거를 연결하세요.
코드보다 결과를 먼저 정의해야 하는 이유
“문의 폼을 개선해 주세요”라는 요청은 AI에게는 너무 넓습니다. 어떤 화면이 바뀌는지, 오류가 날 때 무엇을 보여야 하는지, 모바일에서도 버튼이 보이는지, 저장된 데이터가 어떻게 확인되는지가 빠져 있습니다. 코드가 만들어져도 요청자가 원한 결과와 다를 수 있습니다.
완료 증거 카드는 구현 방법을 강제하는 문서가 아닙니다. 요청자와 개발자, AI가 같은 결과를 보게 하는 합의입니다. 그래서 기능 이름보다 사용자가 실제로 하는 행동과, 그 행동이 끝났다는 신호를 적는 것이 좋습니다.
네 단계는 짧아도 분리합니다
| 단계 | 질문 | 남길 증거 |
|---|---|---|
| 분리 | 이번 변경이 만지는 화면·데이터·권한은 어디까지인가? | 작업 브랜치, 범위 메모, 제외 항목 |
| 구현 | 사용자의 어떤 행동이 달라지는가? | 변경 파일, 의도, 제한 사항 |
| 증명 | 요청한 결과를 다른 사람이 다시 볼 수 있는가? | 전후 화면, 테스트 결과, API 응답, 측정값 |
| 검토·배포 | 누가 승인하고 문제면 어떻게 멈추는가? | 검토자, 배포 범위, 되돌리기 기준 |
네 단계를 모두 거대한 문서로 만들 필요는 없습니다. 작은 버그 수정이라도 “증명”과 “검토”를 빼지 않는 것이 핵심입니다. 반대로 기능이 커질수록 분리 단계에 데이터·권한·영향 범위를 더 자세히 적으세요.
완료 증거 카드 예시
아래 카드처럼 한 장에 쓰면 AI에게 요청을 줄 때도, 리뷰어가 볼 때도 기준이 같습니다. 모르는 것은 “확인 필요”로 남기세요. 빈칸을 그럴듯한 약속으로 채우는 것이 가장 위험합니다.
변경: AX 자가진단 결과 화면에 “다음 행동”을 한 문장으로 표시 사용자 결과: 점수를 확인한 뒤 바로 읽을 가이드 링크를 볼 수 있다 범위: 결과 화면과 링크 문구만 / 질문 점수 계산과 개인정보 저장은 제외 완료 증거: 390px·1440px 전후 화면, 링크 200 응답, 기존 점수 테스트 통과 사람 확인: 콘텐츠 담당자가 문구·링크를 확인, 개발 담당자가 결과 상태를 확인 배포 후 관찰: 링크 오류 또는 모바일 가로 스크롤이 생기면 이전 버전으로 되돌림 확인 필요: 외부 가이드 페이지의 최신 공개 상태
전후 화면만으로 충분하지 않은 변경도 있습니다. 계산·권한·데이터 저장처럼 보이지 않는 부분은 자동 테스트 결과나 실제 요청·응답을 함께 남기세요. 반대로 문구·레이아웃 같은 변경은 실제 화면과 키보드 이동, 모바일 폭을 보는 편이 더 직접적입니다.
AI의 자기 보고와 독립 확인을 나누세요
AI가 “테스트를 통과했습니다”라고 말하는 것은 시작점일 뿐입니다. 어떤 명령을 실행했는지, 실패한 테스트는 없었는지, 확인하지 못한 영역은 무엇인지가 필요합니다. 동일한 에이전트의 설명만 반복해서 받으면 같은 가정이 오류를 놓칠 수 있습니다.
작은 팀이라면 다른 사람이 카드의 증거만 보고 확인해도 됩니다. 개발 담당자가 아닌 콘텐츠 담당자가 전후 화면과 링크를 보고, 개발 담당자는 데이터와 테스트를 보는 식입니다. 영향이 큰 변경은 별도 리뷰어, 제한된 배포, 되돌리기 기준을 추가하세요.
측정값은 약속이 아니라 비교입니다
성능이나 전환처럼 수치가 필요한 작업에서는 “빨라집니다”라고 쓰지 말고 비교 대상을 명시하세요. 어떤 페이지를 어떤 조건에서 측정했는지, 이전 값과 새 값을 누가 확인하는지 적습니다. 한 번의 측정이 좋아도 네트워크나 데이터가 달랐을 수 있으므로, 결과를 보장 문구로 바꾸면 안 됩니다.
이 기준은 AI 작업을 늦추기 위한 것이 아닙니다. 쓸모 없는 반복 검토를 줄이고, 정말 판단이 필요한 곳에 사람의 시간을 쓰기 위한 것입니다. 증거가 정해져 있으면 에이전트도 더 구체적으로 작업할 수 있습니다.
병합 전 다섯 질문
- 이번 변경의 사용자 결과가 한 문장으로 적혀 있는가?
- 바뀌지 않아야 할 범위와 권한이 보이는가?
- 전후 상태를 독립적으로 확인할 증거가 있는가?
- 실행하지 못한 테스트나 확인하지 못한 위험을 숨기지 않았는가?
- 문제가 생겼을 때 멈추고 되돌릴 담당자와 기준이 있는가?
AI가 코드를 더 빨리 만들어도 책임 있는 완료의 기준은 바뀌지 않습니다. 사용자가 본 결과, 검증 기록, 사람이 내린 최종 판단이 함께 있어야 다음 변경도 안전하게 이어집니다.
출처: Greg Isenberg의 Software Factory 영상과 OpenAI Agents API 발표를 2026년 9월 19일 확인했습니다. 이 글의 완료 증거 카드는 LeanX의 제안입니다.
자주 묻는 질문
AI 소프트웨어 팩토리는 특정 제품인가요?
아닙니다. 이 글에서는 AI가 만드는 변경을 분리하고, 만들고, 증명하고, 검토하는 운영 흐름을 뜻합니다. 사용하는 모델이나 개발 도구와 별개로 완료 기준을 정하는 데 초점을 둡니다.
완료 증거는 꼭 영상으로 남겨야 하나요?
아닙니다. 변경 성격에 따라 전후 화면, 자동 테스트 결과, API 응답, 성능 측정, 수동 확인 기록 중 적절한 것을 고르면 됩니다. 핵심은 요청한 결과를 다른 사람이 다시 확인할 수 있는가입니다.
AI가 테스트를 통과했다고 말하면 충분한가요?
충분하지 않습니다. 어떤 테스트를 어떤 환경에서 실행했는지와 실제 결과를 확인하세요. 고객 정보, 권한, 결제처럼 영향이 큰 흐름은 사람이 별도로 시나리오를 확인해야 합니다.
팀의 AI 활용과 검수 기준을 함께 점검해 보세요.
무료 AX 자가진단