AI로 검수하기, 버그 테스트

ALT

산과 산을 배경으로 한 한국 포스터

📝 한줄 요약

두 번의 검수(업무자, 개발자)를 다 통과한 버그들을 찾기 위해, 처음 보는 사람처럼 일부러 이상하게 썼습니다. 빈 값, 13월 45일, 거꾸로 시간 같은 엣지 케이스를 시도했을 때 4가지 버그가 드러났고, 그 중 2가지는 기존 검수에서 빠진 것이었습니다.

Before: 제출 검증은 다 된 줄 알았음
After: 검수 방법에 따라 버그의 종류가 달라짐을 배움

👥 이런 분께 추천

• 앱이나 폼을 만든 후 “다 완성했다”고 생각했던 개발자

• 사용자 검수와 자동화된 검증 사이의 간격을 줄이고 싶은 분

• 엣지 케이스 테스트가 왜 필요한지 구체적으로 알고 싶은 분

• 버그를 찾는 것보다 “버그를 놓치지 않는 방법”에 관심 있는 분

🙋 내 스펙 & 환경

진행 방법

1. 이미 통과한 두 가지 검수

화면을 만들고 이미 두 번을 검수했었습니다.

• 첫 번째: 업무를 아는 실사용자(제이리님)가 실제 업무 흐름 관점에서 본 검수

• 두 번째: 같은 실사용자가 처음 보는 사람 입장으로 버튼을 막 눌러본 검수

두 검수 모두 “잘 막혀있다”는 결론이 나왔습니다. 필수값 검증, 날짜 검증, 미래 날짜 차단, 거꾸로 시간 차단, 긴 미팅 확인 체크박스, 삭제 확인 창 등이 잘 작동했기 때문입니다.

2. 세 번째 검수: 일부러 틀리게 써보기

그런데 저는 한 가지 더 해봤습니다. “처음 보는 사람이 정말로 틀리게 쓸 때”를 직접 재현해보는 것입니다.

실제로 써본 입력들:

• 전부 빈칸으로 제출

• 13월 45일 같은 완전히 틀린 날짜

• 미래 날짜 (12월 25일)

• 끝 시간을 시작보다 앞으로 설정

• 12시간짜리 미팅

• 주소 검색이 안 될 때 수동 입력

• 삭제한 뒤 취소

• 로그인 API에 틀린 비번 입력

이 과정에서 4가지 버그가 나왔습니다.

3. 발견한 4가지 버그

버그 1: Work Type의 Other 빈칸이 통과함

Work Type을 “Other (please specify)“로 선택하면 입력칸이 나타납니다. 그 칸을 비워두고 제출하면?

• 화면 검증: 통과 (빈칸 체크를 하지 않음)

• 서버: 400 에러 (required field missing)

• 사용자 경험: “Failed to submit. Please try again.” 메시지만 뜸. 어느 칸이 문제인지 모름

이게 “반쯤 조용한 실패”입니다. 아예 안 되는 게 아니라 절반은 진행되고 절반만 실패하니까, 사용자는 계속 똑같이 시도하게 됩니다.

버그 2: 날짜 전체 교체 시 슬래시가 안 붙음

기존 날짜(08/01/2026, 10자)가 있을 때 전체 선택하고 숫자 8자리(12252026)를 붙여넣으면:

결과: “12252026” (슬래시 없음, 무효 처리)

원인: 코드에서 “글자 수가 줄면 지우는 중”이라고 판단했는데, 기존 10자를 새 8자로 바꾸면 지우기로 착각했습니다.

const isDeleting = raw.length < draft.length; // 이것만으로 판단

10 < 8이 true이니까 “지우는 중”이고, 지우는 중에는 슬래시를 안 붙입니다.

버그 3: 로그인 화면이 한국어

규칙 문서(DEV.md)에는 “화면은 전부 영어”라고 명시되어 있습니다. 그런데 로그인 문 화면은 한국어(“로그인”, “아이디”, “비밀번호”)였습니다.

앱을 배포한 후 고객이 제일 먼저 보는 화면이 이것이라, 규칙 어김이 눈에 띄었습니다.

버그 4: 수정 모달의 날짜 칸이 브라우저 기본값

확인된 건의 확인일을 고치는 모달에서 Confirmed Date 칸이 input type="date" (브라우저 기본)였습니다.

이것도 규칙 위반입니다. 브라우저 기본 날짜 칸은 보는 사람의 브라우저 언어를 따라가서, 한국어 환경에서는 “연도-월-일”로 표시됩니다. 화면 전체를 영어로 통일한 의도가 물거품입니다.

4. 같은 날 안에 고침

발견 당일 모든 버그를 고쳤습니다.

1번과 2번은 코드 수정:

• Work Type: workTypeFilled 변수를 새로 만들어 Reason과 같은 방식으로 처리

• 날짜 슬래시: isDeleting 조건에 draft.startsWith(raw) 추가

3번과 4번은 규칙 적용:

• 로그인 화면: 영어로 통일

• 수정 모달: 신청 폼과 같은 DateField 부품 사용

5. 검증: 고쳐진 걸 다시 시도

고친 후 같은 테스트를 다시 했습니다.

버그 1 (Other 빈칸):
- Before: 통과 → 서버 거절
- After: 화면에서 차단, "Please fill in: Work Type" 메시지

버그 2 (날짜 교체):
- Before: 12252026 (슬래시 안 붙음)
- After: 12/25/2026 (정상)

버그 3 (로그인 한국어):
- Before: "로그인", "아이디", "비밀번호"
- After: "Log In", "ID", "Password"

버그 4 (수정 모달 브라우저 기본):
- Before: input type="date"
- After: 신청 폼과 같은 DateField (달력 + MM/DD/YYYY)

모두 해결 확인.

배운 점

💡 핵심 교훈

1. 검수 방법의 종류에 따라 발견하는 버그도 달라집니다

업무를 아는 사람은 업무 흐름의 빈 곳을 잘 찾습니다. 새로운 사람은 설명 없이 못 넘어가는 곳을 찾습니다. 일부러 틀리게 쓰는 사람은 “사용자가 정말로 실수할 때”를 찾습니다.

우리가 찾은 버그 4개는:

• 버그 1, 2: 일부러 틀리게 쓸 때만 나옴 (기존 검수를 다 통과)

• 버그 3, 4: 규칙 위반 (규칙 문서가 있었는데도)

2. 반쯤 조용한 실패가 제일 위험합니다

Work Type Other 빈칸은 아예 작동하지 않는 게 아니라 “화면은 통과하고 서버만 거절”합니다. 그래서 사용자는 어디가 문제인지 모른 채 “왜 계속 실패하지?”를 반복합니다.

검증은 거절하는 것까지가 아니라 “왜 거절되는지”를 알려주는 것까지입니다.

3. 규칙 문서가 있어도 새 화면이 어깁니다

로그인 화면 한국어, 수정 모달의 브라우저 기본 날짜. 둘 다 DEV.md에 명확히 이유까지 적혀 있었습니다. 그런데 나중에 급하게 붙인 화면이 정확히 그 규칙을 어겼습니다.

규칙은 적어두는 것만으로 지켜지지 않고, 새 화면을 만들 때마다 대조해야 합니다.

적용할 점

🎯 결과

결론: 검수는 한 종류로는 부족합니다.

📋 복붙 가능한 테스트 케이스

다음 번에 앱을 만들 때 이 테스트를 체크리스트로 써도 됩니다.

폼 검증 체크리스트:
□ 전부 빈칸으로 제출 → 필수값 안내가 뜨는가? (각 칸에서, 그리고 요약에서 모두)
□ 범위를 벗어나는 값 (13월, 45일, 미래 날짜) → 각각 차단되는가?
□ 거꾸로 된 범위 (끝 시간 < 시작 시간) → 경고 또는 차단되는가?
□ 특수한 입력 (첫 선택 안 한 상태에서 관련 칸 채우기) → 좋은 에러 메시지가 나오는가?
□ 다국어 규칙 (숫자 형식, 언어) → 화면 전체가 일관되는가?

버그의 종류가 다르면 찾는 방법도 달라야 합니다.

🔜 다음 계획

1. 빌드 시점 검증 추가 - 완성 후 한 번만 체크하는 게 아니라, 매주 엣지 케이스 테스트를 루틴으로

2. 규칙 문서 체크 자동화 - 새 화면을 만들 때마다 DEV.md의 규칙을 읽는 것을 습관으로

3. 테스트 케이스 기록 - 찾은 버그마다 “이건 왜 놓쳤나” 메모를 남기기

솔직한 소감

아루나님 가이드에 따라 검수를 다시 실행해보았습니다.

두 번의 검수를 통과했다고 생각했는데 4가지가 남아있었다는 게 놀랐습니다. 특히 로그인 화면 한국어와 수정 모달의 브라우저 기본 달력은 규칙 문서가 있었는데도 어겼으니까요.

그걸 고칠 때 든 생각은 “규칙은 적어두는 것이 아니라 확인하는 것이다”였습니다. 문서만 있으면 충분하지 않고, 새 화면을 만들 때마다 대조하고 확인해야 한다는 걸 배웠습니다.

그리고 버그 1과 2처럼 기존 검수에서 빠진 버그를 찾는 경험은 신기했습니다. “일부러 틀리게 쓰는” 방법이 이렇게 구체적인 버그를 찾을 수 있다는 걸 처음 알았거든요.