솔직히 말하면, 저도 수동 테스트 신봉자였습니다
솔직히 말하면, 저도 얼마 전까지만 해도 "수동 테스트가 최고"라고 생각했습니다.
"AI가 작성한 코드는 믿을 수 없어. 역시 사람이 직접 확인해야지"라고 생각했거든요.
그런데 한 프로젝트에서 뼈아픈 경험을 했습니다. ChatGPT와 Copilot을 사용해서 API 개발을 진행하다가, 수동 테스트가 완전히 따라잡을 수 없게 되었습니다.
처음에는 "좀 바쁠 뿐이야"라고 생각했어요. 그런데 어느새 테스트가 개발의 병목이 되어 팀 전체가 멈춰버렸습니다.
이 글에서는 제가 실제로 경험한 "수동 API 테스트의 붕괴"에서 배운 10가지 교훈을 공유합니다.
혹시 여러분도 "아직 수동으로 괜찮아"라고 생각하신다면, 이 이야기가 남의 일이 아닐 수 있습니다.
제가 경험한 붕괴의 순간
1. AI의 코드 생성 속도를 인간이 따라잡을 수 없는 현실
이게 가장 충격적이었습니다.
ChatGPT에게 "사용자 관리 API를 만들어줘"라고 요청하면, 5분 만에 엔드포인트 10개 분량의 코드가 나옵니다. 그런데 이걸 수동으로 테스트하려고 하면, 하루가 걸려도 끝나지 않습니다.
- 엔드포인트가 30분마다 5개씩 늘어남
- 요청 구조가 1시간에 3번씩 바뀜
- 영향 범위 확인만 해도 반나절 소요
"왜 나만 이렇게 느린 거지?"라고 생각했는데, 문제는 제 실력이 아니라 구조 자체였습니다.
2. AI 생성 코드의 '함정'에 빠진 이야기
AI가 만든 API는 겉보기에 완성도가 엄청 높아 보입니다.
// ChatGPT가 생성한 API (완벽해 보임)
app.post('/api/users', async (req, res) => {
const { name, email } = req.body;
const user = await User.create({ name, email });
res.json({ success: true, user });
});"오, 작동한다! 완벽하네!"라고 생각하고, 수동으로 정상 케이스만 테스트하고 끝냈습니다.
그런데 나중에 알고 보니,
- 빈 문자열 처리가 빠져있음
- 이메일 중복 체크 없음
- 에러 응답 형식이 제각각
수동 테스트는 "작동했으니 OK"로 끝나버리기 쉽습니다. 경계값이나 예외 케이스는 귀찮아서 나중으로 미루게 되죠.
3. 테스트 케이스 업데이트 지옥
이것도 힘들었습니다.
AI로 API 사양을 계속 변경하면, 테스트 케이스 업데이트가 전혀 따라가지 못합니다.
- 월요일: 사양서 업데이트
- 화요일: 구현 변경
- 수요일: "어? 테스트 케이스는 어떻게 됐지?"
- 목요일: "뭘 테스트하는지 모르겠어"
결과적으로, 오래된 테스트 케이스로 새로운 API를 테스트하는 말도 안 되는 상황이 발생했습니다.
4. 사람마다 테스트 결과가 다른 문제
팀 개발에서 가장 곤란했던 게 이겁니다.
- 저: "이 API는 정상 작동합니다"
- 동료 A: "에러가 발생했어요"
- 동료 B: "응답이 느려요"
같은 API인데 테스트하는 사람에 따라 결과가 다릅니다.
매뉴얼을 만들어도,
- 환경의 차이
- 확인 포인트의 차이
- 데이터 생성 방법의 차이
로 인해 결과가 달라집니다. 이건 품질 보증이 아니에요.
붕괴의 근본 원인을 분석해봤습니다
5. 테스트 결과가 '사라지는' 문제
수동 테스트 결과는 어디에 남나요?
- 제 로컬 환경의 Postman
- Slack의 "작동했어요!" 메시지
- 손으로 쓴 메모
전부 일시적입니다. 다음 날이면 "어제 뭘 테스트했더라?" 상태가 됩니다.
AI로 개발 속도가 빨라질수록, 이 '사라지는' 문제가 치명적이 됩니다.
6. CI/CD에서 완전히 소외됨
이것도 아팠습니다.
팀에서는 GitHub Actions로 CI/CD를 돌리는데, 수동 테스트만 완전히 따돌림을 당합니다.
- 코드는 푸시로 자동 배포
- 하지만 API 테스트는 수동
- 결과적으로 "배포 후 문제 발견"
"테스트는 마지막에 시간 있으면 하는 작업"이 되어버렸습니다.
7. 여러 API 연계 테스트가 현실적이지 않음
AI가 만드는 API는 단독이 아니라 여러 API가 연계되는 전제로 만들어지는 경우가 많습니다.
- 사용자 등록 → 인증 → 프로필 업데이트
- 상품 검색 → 장바구니 추가 → 결제 처리
이걸 매번 수동으로 테스트하는 건 현실적이지 않습니다.
8. '테스트 설계'가 속인화되는 악순환
가장 무서운 게 이겁니다.
AI가 코드를 작성 → 사람이 테스트 설계를 고민 → 특정인만 전체를 파악
제가 쉬면 아무도 API 테스트를 할 수 없는 상황이 되었습니다.
분리된 개발 플로우의 문제
9. 사양·테스트·구현이 따로 놈
이게 붕괴의 최대 원인이었다고 생각합니다.
- 사양서: Notion
- 테스트: Postman
- 구현: AI 생성 코드
전부 다른 곳에 있어서 일관성을 유지할 수 없습니다.
사양이 바뀌어도 테스트 케이스 업데이트를 잊어버립니다. 구현이 바뀌어도 사양서 업데이트를 잊어버립니다.
이 분리를 해소하기 위해, 최종적으로 API 사양과 테스트를 같은 곳에서 관리할 수 있는 도구(Apidog
같은)로 이전했습니다.
실제로 Apidog을 사용하기 시작한 후,
- 사양 변경 → 테스트 케이스 자동 업데이트
- 테스트 실행 → 결과가 이력으로 남음
- CI/CD 연계 → 자동화 테스트 실행
이라는 흐름이 만들어져서, "어디를, 무엇을 확인하는지 모르겠다"는 상황이 많이 줄었습니다.
10. '확인하고 있다는 착각'의 공포
가장 위험했던 건 안심감이었습니다.
"사람이 보고 있으니까 괜찮아" "만져봤더니 작동하니까 문제없어"
하지만 실제로는 사람이 전부를 볼 수 없게 되어 있었습니다.
수동 테스트는 '안심 재료'인 줄 알았는데, 사실은 '사각지대'가 되어 있었습니다.
수동 테스트를 완전히 부정하는 건 아닙니다
오해하지 말아주세요. 수동 테스트 자체가 나쁜 건 아닙니다.
지금도,
- 신기능 초기 검증
- UI 연계 확인
- 사용성 체크
에서는 수동 테스트가 중요합니다.
다만, 수동 테스트를 '메인'으로 계속 유지하는 구조가 붕괴한다는 겁니다.
실제로 저도 예전에는 사양서·테스트·실행 결과가 각각 다른 곳에 분산된 상태로 운영했습니다. 처음에는 수동으로도 돌아가지만, API 변경이 늘어나자마자 "확인하고 있다는 착각"만 남는 상태가 됩니다.
제가 찾은 해결책: 통합된 전제
결국, 다음을 같은 전제로 관리하는 것이 중요했습니다:
- API 사양
- 테스트 케이스
- 목 데이터
- 실행 결과
최근에는 이것들을 API 사양을 중심으로 통합 관리하는 접근법이 많이 사용됩니다.
예를 들어, API 정의와 테스트를 같은 전제로 다룰 수 있는 도구(Apidog등)를 사용하면, AI 생성 코드와의 차이를 조기에 감지하기 쉬워지는 경우도 있습니다.
※ 어디까지나 하나의 예시이며, 중요한 건 "구조적으로 붕괴하지 않는 체계"를 갖추는 것입니다.
정리: 바꿔야 할 건 '전제' 그 자체
AI 시대에 재검토해야 할 것은,
- 수동이냐 자동이냐
- 어떤 도구를 쓰느냐
가 아닙니다.
"사람이 전부 확인할 수 있다"는 전제 그 자체입니다.
저도 처음에는 저항감이 있었습니다. 하지만 그 전제를 내려놓았을 때, API 테스트 방식도 자연스럽게 바뀌었습니다.
혹시 여러분도 "수동 테스트의 한계"를 느끼고 계신다면, 한 번 멈춰서 생각해보세요.
문제는 개인의 실력이 아니라, 시대 구조 자체가 바뀐 결과일 수 있습니다.
