완성의 기준을 먼저 적으면 덜 고칠까?

AI가 만든 여행 준비물 앱에서 추가·챙김 표시·삭제가 작동했다. 첫 화면에는 예시 6개가 있었고 새로고침해도 목록이 남았다. 평가 기준에는 빈 시작과 새로고침 초기화가 정해져 있었지만, 처음 요청에는 없던 조건이었다.

2026년 9월 27일, 가상 데이터로 짧은 요청(A)과 기준을 더한 요청(B)을 한 번씩 비교했다. 기대를 언제 알렸는지 살핀 한 쌍이며, 생산성이나 시간 절감의 증거는 아니다.

출처로 보는 기준: 무엇을 확인하면 끝인가

Scrum Alliance 용어집은 합격 기준(수용 기준, acceptance criteria)을 사용자 기대를 충족하는지 시험할 수 있는 조건으로 설명한다. 이 글에서는 이를 ‘확인 기준’이라 부르고, “공백만 제출하면 오류 문구가 보이고 목록은 그대로다”처럼 결과를 적는다.

2020 Scrum Guide의 완료 정의(Definition of Done)는 제품의 품질 조건을 충족한 상태에 대한 공통 이해다. 이 글 제목의 ‘완성의 기준’은 이 공식 개념이 아니라 한 기능의 확인 목록을 뜻한다. 두 출처 모두 AI 작업 시간 단축의 증거는 아니다.

기록된 관찰: 같은 기능, 서로 다른 정보

같은 HTML 뼈대와 빈 CSS·JavaScript 시작 파일로 로컬 앱을 한 번씩 만들었다. 둘 다 혼자 쓸 여행 준비물 목록의 추가·챙김 표시·삭제와 보기 편한 화면을 부탁했다. 외관은 채점하지 않았다. B에는 목적·사용자·동작·화면 상태·예외·제외 범위, 확인 기준 8개와 항목별 관찰 보고 지시를 더했다. 두 조건 모두 질문을 허용했고, A를 먼저 실행했다. 평가와 변경 요청은 기대를 미리 아는 별도 AI 운영 에이전트(Claude Opus 5.5)가 맡았다. A는 정해 둔 기대를 뒤늦게 알린 조건으로, 일반적인 초보자를 대표하지 않는다.

기록상 도구는 Codex CLI 0.153.4, 요청 모델은 gpt-6-astra, 추론 설정은 medium이었다. 실제 응답 모델 식별자는 보존되지 않아 두 실행의 실제 모델이 같았는지는 확인할 수 없다. macOS 27.0에서 제작했고, 운영 에이전트가 별도 Chrome 153.0.8010.53으로 화면을 확인했다(화면 창 없이 실행, 1280×900). 두 제작 에이전트의 자체 브라우저 실행은 실패했다. B는 브라우저 격리 보호를 끄는 --no-sandbox 옵션으로도 재시도했지만 실패했고, B는 모든 화면 확인을 ‘확인하지 못함’으로 보고했다. A는 실제 브라우저 대신 흉내 낸 실행 환경의 검사 통과를 보고했다. 아래 표는 제작 AI의 보고가 아니라 운영 에이전트의 브라우저 관찰이다. 보고 지시만으로 브라우저 증거가 확보되지는 않았다.

A에는 브라우저가 경고 말풍선을 띄우게 하는 코드가 있어 ‘오류 처리 자체가 없음’은 아니다. 자동 검사는 페이지 본문만 찾아 이 방식의 알림을 감지할 수 없었다. 보존된 화면으로는 그 순간 읽을 수 있는 알림이 떴는지 확정하지 못했다.

앞뒤 공백 제거, 챙김 표시를 두 번 바꿔 되돌리기, 같은 이름 두 개 중 하나만 삭제하기는 양쪽 첫 결과에서 기대대로 작동했다. 이 세부 동작은 A에 끝내 요청하지 않았으므로 브리프 덕으로 돌릴 수 없다. <b>책</b>도 A에 요청하지 않았지만 글자 그대로 보였다. 입력이 화면 코드로 해석되는지 본 한 사례로, 굵은 글씨용 HTML 요소가 생기지 않았다는 결과가 전체 보안 검증은 아니다.

A에는 빈 시작·추가 뒤 총 개수·공백 입력 오류·새로고침 초기화 네 항목의 기대와 실제를 한 메시지로 전달했다. 처음 두 항목은 예시 6개라는 같은 원인이다. 다음 결과는 빈 목록에서 시작하고, 오류 문구를 화면에 표시하며, 자동 저장을 없앴다. 처음 말하지 않은 기대를 뒤늦게 공개한 변경이며, 항목 추가 동작의 고장이나 저장 자체의 잘못은 아니다. 빈 시작과 저장 없음은 이 앱의 정책 선택이며, 어느 쪽이 여행자에게 더 유용한지는 시험하지 않았다. 보존된 수정 검사에서 A의 두 번째 결과와 B의 첫 결과는 8개 기준을 충족했다. 다만 검사 코드가 실험 전 고정본과 같지는 않다. 기준·순서·판정 규칙을 유지했다는 운영 기록은 있으나, 코드의 변경 전후 대조 근거는 불완전하다.

시간 기록: 최초 작성 비용은 모른다

두 요청 모두 미리 작성돼 있었다. 아래 시간에는 최초 작성 비용이 없으며, 두 시간의 차이는 수정 한 번에 든 시간이나 절감량이 아니다.

변경 요청·응답 1회는 여러 항목을 담은 메시지 하나와 그 응답을 뜻한다.

준비는 기존 요청 복사뿐으로, 초 단위 기록에서 약 0분이었다. 요청문과 질문 대비 답변 모음을 처음 쓴 시간, 공통 환경 준비와 확인 도구 사전 점검 시간은 모른다. 운영 에이전트가 실제 확인·기록 작업에 쓴 시간도 분리하지 못했다. 전체 제작 시간이나 절감률로 읽을 수 없다. 구독 자원은 사용했지만 실제 추가 청구액은 별도 확인되지 않았다.

기록의 한계

검사 기록에도 한계가 있다. A의 첫 자동 검사는 화면 요소를 잘못 찾아 무효가 됐고, 수정한 검사로 덮어써 원본이 남지 않았다. 운영 에이전트가 검사 도구 점검용 기준 앱을 먼저 만든 것도 계획에서 벗어났다. B가 A 폴더 이름과 무관한 지침 파일 경로를 열거하는 등 격리도 불완전했다. 상대 코드 내용을 읽은 기록은 없다. 조건별 60분 상한 전에 최종 확인으로 종료했지만, 절차를 모두 준수했다고 할 수는 없다. 세부 근거는 별도로 보관한 실험 기록(영문)에 남겼다.

작성자 판단: 다음 요청에 남길 확인 질문

A는 기대를 알리는 메시지 한 번 뒤 네 항목이 기대대로 바뀌었고 B는 변경 요청이 없었다. 그렇다고 먼저 적으면 덜 고친다는 답은 낼 수 없다. 기대와 실제를 나란히 남기는 것은 변경 내용을 설명하는 기록 습관으로 제안한다. 정보량·길이·공개 시점·검증 지시가 함께 달랐고, 평가자는 기대 결과를 미리 알고 A부터 확인했다. 실제 모델 동일 여부도 미확인이며, A에 남은 필터·진행 표시·그림의 시간 기여는 모른다. 조건당 한 번이므로 브리프의 효과나 일반적인 수정 감소를 결론 낼 수 없다. 8개 기준도 독립 실험 8회가 아니다.

아래는 복사해 채울 수 있는 한 기능용 브리프다. 효과를 검증한 양식은 아니며, 초보자의 작성 부담도 시험하지 않았다. 예시는 이 연습 앱의 선택이다.

만들 것/목적: 무엇을 하기 위한 기능인가?
사용자·기기: 누가 어디에서 쓰는가?
동작: 무엇을 누르고 입력하는가?
화면 상태: 처음·성공 뒤·잘못 입력했을 때 무엇이 보이는가?
예외: 예) 빈 입력·같은 이름·새로고침은 어떻게 처리할까?
이번엔 안 함: 예) 로그인, 저장, 동기화
확인 기준 — 입력·행동 → 기대 결과:
  정상 예) 빈 목록에 물병 제출 → 챙기지 않은 상태로 1개, 입력칸 비움
  거절 예) 공백 세 칸 제출 → 읽을 수 있는 오류, 목록 그대로
완료 보고 방식: 실행 방법과 항목별 실제 관찰을 적기.
  확인 못 한 것은 표시하고, 코드만 보고 통과라 하지 않기.

AI가 확인하지 못했다고 하면 페이지를 직접 열어 입력해 보자. 변경 요청에는 입력·행동 → 기대 → 실제를 남길 수 있다. 적은 조건도 다르게 해석될 수 있고, 기준 자체가 빠뜨린 동작도 있을 수 있다. 이번에는 한글 조합 입력·긴 글·모바일·키보드·접근성·유지보수를 확인하지 않았고, 연습용 조건 통과가 실사용 준비 완료를 뜻하지 않는다. 새 요구가 생기면 기준도 고칠 수 있다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.