통과 표시를 넷으로 나눕니다. 내부 검증과 사람이 써 본 결과는 다른 상태입니다.
개발 기록에서 가장 자주 부풀려지는 단어가 「통과」입니다. 자동 검사가 초록으로 나온 것과 사람이 실제 환경에서 써 보고 문제가 없다고 판단한 것은 전혀 다른 상태인데, 기록에는 똑같이 통과로 적힙니다. 그러다 배포 직전에 처음으로 열어 보고 안 되는 걸 발견합니다. 제가 쓰는 개발 운영 규칙은 상태를 네 가지로 쪼개 이 문제를 막습니다. 내부 자동검증 통과, 전체 개발 완료 전, 사용자 최종 통과, 실패입니다. 자동 테스트를 통과했다는 이유만으로 사용자 최종 통과를 표시하지 않는다는 문장이 규칙에 그대로 들어 있습니다.
같은 단어가 두 가지 뜻으로 쓰인다
개발 중에 「통과」라고 적을 수 있는 상황은 최소 두 가지입니다. 자동 검사가 오류 없이 끝난 것, 그리고 사람이 실제로 써 보고 문제가 없다고 판단한 것입니다.
두 상태의 신뢰도는 크게 다릅니다. 자동 검사는 미리 적어 둔 항목만 봅니다. 적어 두지 않은 상황은 검사하지 않고, 검사하지 않은 것은 오류로도 나오지 않습니다.
그런데 기록에는 둘 다 통과로 남습니다. 나중에 그 줄만 읽는 사람은 어느 쪽인지 구분할 수 없습니다.
그래서 상태를 네 가지로 늘렸습니다. 표기를 늘리면 적는 사람이 매번 어느 쪽인지 판단하게 됩니다.
| 상태 | 뜻 | 이때 할 수 있는 일 |
|---|---|---|
| 내부 자동검증 통과 | 자동 검사와 내부 실행 확인 완료 | 다음 단계로 계속 진행 |
| 전체 개발 완료 전 | 약속한 기능이 아직 다 안 됨 | 실사용 테스트를 요구하지 않음 |
| 사용자 최종 통과 | 실제 환경에서 사람이 확인 | 완료로 기록 |
| 실패 | 내부 또는 최종 테스트에서 문제 확인 | 수정 또는 복구 |
중간에 실사용 테스트를 요구하지 않는 이유
규칙 문서의 최신 버전에서 바뀐 항목이 바로 이 부분입니다. 단계마다 저장하는 체크포인트는 그대로 두되, 사람이 직접 써 보는 테스트는 모든 기능이 끝난 뒤 한 번에 하도록 고정했습니다.
이전에는 단계가 끝날 때마다 「사용자 실사용 테스트 대기」 상태를 만들었습니다. 문제는 이 상태가 계속 쌓인다는 점이었습니다.
쌓인 대기 항목은 사람을 붙잡아 둡니다. 기능이 절반만 완성된 상태에서 써 보게 하면 판단하기도 어렵고, 다음 단계에서 어차피 바뀝니다.
그래서 개발 중에는 내부 자동검증만 하고 다음 단계로 계속 나아갑니다. 대신 각 단계의 결과물과 기록은 반드시 저장합니다.
최종 테스트는 한 번에 몰아서
약속한 기능을 모두 구현하면 그때 테스트 환경을 정리합니다. 그리고 사람과 함께 한 번에 확인합니다.
확인하는 항목은 계정 로그인, 실제 게시, 여러 곳에 동시 발행, 알림과 연동, 콘텐츠 제작, 실패와 복구, 중복 방지, 업데이트 흐름입니다.
최종 테스트를 모두 통과한 항목만 사용자 최종 통과로 바꿉니다. 일부만 확인하고 전체를 통과로 올리지 않습니다.
이 순서를 지키면 사람이 테스트에 쓰는 시간이 한 번으로 모입니다. 개발 중에 여러 번 나뉘어 들어가던 시간이 줄어듭니다.
- 약속한 기능을 모두 구현한다
- 각 단계에서는 자동검증과 회귀 테스트만 한다
- 각 단계가 끝나면 결과물과 기록을 저장한다
- 전체가 끝나면 테스트 환경을 정리한다
- 사람과 함께 한 번에 확인한다
- 통과한 항목만 최종 통과로 바꾼다
무엇을 테스트하나
의미 있는 변경 뒤에 확인하는 항목도 정해 뒀습니다. 잘 되는 경우만 보면 테스트가 아니라 시연입니다.
화면은 정상 상태만이 아니라 데이터가 없는 상태, 불러오는 중인 상태, 오류가 난 상태를 함께 봅니다.
동작은 저장하고 복원하고 다시 켜는 흐름, 지우고 되살리는 흐름을 봅니다. 지우는 기능만 만들고 되살리는 흐름을 안 보면 나중에 크게 다칩니다.
화면 크기도 나눠 봅니다. 그리고 빌드와 문법 검사, 타입 검사, 자동 테스트를 함께 돌립니다.
| 구분 | 확인할 상태 |
|---|---|
| 화면 | 정상 · 비어 있음 · 불러오는 중 · 오류 |
| 권한 | 막혔을 때의 화면과 안내 |
| 데이터 | 저장 · 복원 · 재시작 |
| 되돌리기 | 삭제 · 복구 |
| 환경 | 작은 화면 · 큰 화면 |
| 자동 | 빌드 · 문법 · 타입 · 자동 테스트 |
기록에서 하지 않기로 한 것
테스트하지 않은 상태를 통과로 기록하지 않습니다. 확인하지 못한 것은 미확인으로 남깁니다.
내부 통과를 사용자 최종 통과로 올려 적지 않습니다. 이 한 줄이 네 단계 표기의 핵심입니다.
전체 개발이 끝나기 전에 사람에게 단계별 실사용 테스트를 요구하지 않습니다.
완료 보고에는 확인한 것과 확인하지 못한 것을 나눠 적습니다. 하나라도 부족하면 완료라고 쓰지 않습니다.
| 하지 않는 것 | 대신 |
|---|---|
| 안 해 본 것을 통과로 적기 | 미확인으로 남긴다 |
| 내부 통과를 최종 통과로 적기 | 표기를 분리한다 |
| 단계마다 실사용 테스트 요구 | 최종에 한 번에 한다 |
| 부족한 채로 완료 선언 | 확인·미확인을 나눠 적는다 |
자주 묻는 질문
Q. 자동 테스트를 통과하면 완료 아닌가요?
A. 자동 검사는 미리 적어 둔 항목만 봅니다. 적어 두지 않은 상황은 검사하지 않으므로 사람이 실제 환경에서 확인한 것과 같은 상태로 볼 수 없습니다.
Q. 왜 중간에 직접 써 보지 않나요?
A. 기능이 절반만 된 상태에서는 판단하기 어렵고 다음 단계에서 어차피 바뀝니다. 대기 항목만 쌓여서 사람이 계속 붙잡히게 됩니다.
Q. 그럼 중간에는 무엇을 하나요?
A. 내부 자동검증과 회귀 테스트를 하고, 그 단계의 결과물과 기록을 저장한 뒤 다음 단계로 넘어갑니다.
Q. 테스트에서 무엇까지 봐야 하나요?
A. 정상 화면만이 아니라 비어 있음·불러오는 중·오류 상태, 권한이 막혔을 때, 저장과 복원, 삭제와 복구, 화면 크기별 동작을 함께 봅니다.
확인 자료
- AI 개발 운영 규칙 문서 v1.3 — 8장 테스트, 15장 상태 표기와 최종 테스트 원칙 (확인 2026-09-09)
- 개발 에이전트 운영 지침 v1.1 — 테스트 상태 분리 규칙 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.