이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Postman을 사용한 API 테스트에서 가장 중점을 둔 것은 컬렉션을 단순 요청 목록이 아닌 테스트 흐름으로 구성하는 것이었습니다. 인증 토큰 획득, 데이터 생성, 조회, 삭제 순서로 실제 사용 시나리오를 그대로 컬렉션으로 표현하면 통합 관점의 문제를 더 잘 잡을 수 있었습니다.
사전 스크립트로 이전 요청의 응답 값을 다음 요청에 자동으로 전달하도록 설정했습니다. 예를 들어 생성 응답에서 ID를 추출해 환경 변수에 저장하면 다음 요청에서 자동으로 참조되어 수동 복사 없이 시나리오가 연결됐습니다.
검증 스크립트도 각 요청에 추가했습니다. 응답 코드, 필드 존재 여부, 값 범위를 자동으로 검사하는 코드를 붙여 테스트 통과 여부를 리포트로 확인할 수 있었습니다. Newman으로 CI에 연결하면서 배포 후 자동 실행이 가능해졌습니다.
인증이 포함된 API를 Postman으로 테스트할 때 매번 토큰을 수동으로 갱신하는 것이 가장 번거로웠습니다. 토큰이 만료되면 401이 떨어지고, 다시 로그인해서 토큰을 복사해야 했습니다. Pre-request Script에 토큰 만료 시간을 확인해 만료 전이면 재발급 요청을 자동으로 보내는 로직을 짰습니다. 이후엔 컬렉션 전체를 돌리는 동안 토큰을 신경 쓰지 않아도 됐습니다. 권한 분기 테스트도 이 구조로 확장했는데, 관리자·일반 사용자·비로그인 세 역할별로 환경 변수를 전환하면서 같은 컬렉션을 돌렸습니다.
403이 나야 하는 케이스가 200으로 오는 버그를 이 방식으로 발견했습니다. Postman은 인증 흐름이 복잡해질수록 스크립트 관리 부담이 커진다는 한계도 있었습니다.
Postman이 모든 API 테스트에 적합하지 않다는 걸 복잡한 인증 플로우를 자동화하려다 벽에 부딪히면서 알게 됐습니다. OAuth 다단계 인증이 포함된 API를 Newman으로 CI에서 돌리려 했는데, 인터랙티브 로그인 단계를 스크립트로 흉내 내는 게 한계였습니다. 결국 해당 플로우는 Postman 대신 pytest + requests 조합으로 전환했습니다. 그 경험 이후로는 간단한 CRUD·헬스체크·컨트랙트 검증에는 Postman, 복잡한 상태·세션·인증 플로우는 코드 기반 테스트로 역할을 나눴습니다. Postman의 강점은 팀 전체가 코드 없이 API를 탐색하고 공유하는 협업 도구로서의 면에 있다고 봅니다. 도구를 선택할 때 무엇을 잘하는지 만큼 무엇을 못하는지를 아는 게 더 중요하다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.