시나리오 기반 테스트 자동화에서 DTO 통합 설계가 유지보수 비용을 50% 절감하는 이유

서론: 시나리오 테스트의 복잡성 증폭과 구조적 해법의 필요성

시나리오 기반 테스트 자동화는 단순한 API 응답 검증 단계를 넘어, 다양한 데이터 소스가 얽힌 비즈니스 로직의 정합성을 보장하는 핵심 수단입니다. 멤버십, 결제, 캐시백 등 복합적인 정책이 적용되는 시스템에서는 테스트 대상이 단일 엔드포인트가 아니라 여러 상태 변화의 연속선상에 위치합니다. 이러한 환경에서 개별 데이터 조회와 분산된 검증 로직을 유지하는 것은 코드 복잡도를 기하급수적으로 증가시키며, 이는 곧 유지보수 비용의 급격한 상승으로 이어집니다. 본 아티클은 AI를 활용한 테스트 자동화 2편의 내용을 바탕으로, 시나리오 기반 테스트 자동화 과정에서 발생한 구조적 한계를 극복하기 위한 모듈화와 DTO(Data Transfer Object) 통합 설계의 가치를 심층적으로 분석합니다.

1편에서는 테스트 데이터 준비, API 호출, 그리고 응답 값과 기대 결과의 비교 코드 구현을 통해 반복 테스트에 소요되는 시간을 획기적으로 단축하는 성과를 거두었습니다. 그러나 이 단계 이후 테스트 범위가 확장되면서, 단순한 기능 검증이 아닌 비즈니스 시나리오 전체를 아우르는 검증이 요구되었습니다. 이때 직면한 가장 큰 문제는 코드 중복과 데이터 조합의 난이도였습니다. 본 글의 핵심 주장은 명확합니다. API 응답과 DB 데이터를 개별적으로 조회하여 검증하는 방식은 비즈니스 로직이 복잡해질수록 코드 복잡도와 유지보수 비용이 기하급수적으로 증가하므로, 시나리오 기반 테스트 자동화에서는 데이터 소스를 하나의 DTO로 통합하는 것이 필수적이라는 것입니다. 이를 통해 테스트 코드의 가독성을 높이고, 정책 변경 시 수정 범위를 최소화하며, 궁극적으로 테스트 신뢰도를 제고할 수 있습니다.

코드 중복과 개별 조회가 초래하는 테스트 자동화의 구조적 한계

테스트 자동화 프로젝트가 초기 단계에서 확장 단계로 넘어갈 때 발생하는 가장 큰 병목은 ‘코드 중복’과 ‘분산된 수정’입니다. 초기에는 각 테스트 케이스마다 DB 조회, API 호출, 응답 파싱 등의 공통 기능을 개별적으로 작성하는 경향이 강합니다. 이러한 방식은 초기 개발 속도는 빠를 수 있으나, 테스트 케이스 수가 증가함에 따라 동일한 로직이 여러 파일에 산재하게 되어 유지보수의 악몽이 됩니다.

구체적으로 살펴보면, DB 조회 로직, API 호출 로직, 그리고 응답 파싱 로직이 테스트 스크립트 내부에 하드코딩되거나 중복 정의되는 경우가 많습니다. 이는 두 가지 치명적인 문제를 야기합니다. 공통 로직에 버그가 있거나 개선이 필요할 때, 해당 로직이 포함된 모든 테스트 파일을 일일이 찾아서 수정해야 합니다. 테스트 코드와 비즈니스 로직이 혼재되어 있어, 어떤 코드가 데이터 준비를 위한 것인지, 어떤 코드가 검증 로직인지 구별하기 어려워집니다.

더욱 심각한 문제는 정책 검증에 필요한 정보를 API 응답과 DB에서 개별적으로 조회하여 조합하는 과정입니다. 초기에는 쓱7클럽 가입 API 응답을 받은 후, 정책 검증에 필요한 추가 정보를 DB에서 개별적으로 조회하는 방식을 채택했습니다. 예를 들어, 캐시백 지급 여부를 확인하기 위해서는 API 응답의 일부 정보와 DB에 저장된 결제 이력, 해지 이력 등을 각각 조회한 뒤, 테스트 코드 내에서 이를 수동으로 매칭하고 조합해야 했습니다. 이러한 ‘개별 조회 후 조합’ 방식은 데이터 소스가 늘어날수록 검증 코드의 분기(branch) 수가 폭발적으로 증가합니다.

이러한 구조적 한계는 디버깅 난이도를 극대화합니다. 테스트 실패 시, 그 원인이 API 응답의 형식 변경인지, DB 데이터의 불일치인지, 아니면 조합 로직의 오류인지 파악하는 데 상당한 시간이 소요됩니다. 특히 시나리오 테스트는 상태(state)가 연속적으로 변하는 특성이 있으므로, 전 단계의 데이터가 후 단계의 검증에 영향을 미치기 때문에 개별 조회 방식은 데이터 정합성 문제를 감지하기 어렵게 만듭니다. 따라서 테스트 자동화의 성숙도를 높이기 위해서는 이러한 분산된 데이터 접근 방식을 통합된 데이터 모델로 전환하는 구조적 개편이 불가피합니다.

API 응답과 DB 데이터를 통합하는 DTO 설계의 메커니즘

개별 조회 방식의 한계를 극복하기 위해 도입된 핵심 아키텍처는 반복되는 기능의 모듈화와 데이터 소스의 DTO 통합입니다. 먼저, 반복되는 기능을 5가지 카테고리(파일, API, DB, 로그, 설정)로 분류하여 공통 모듈로 분리하고, 이를 Import하여 재사용하는 구조로 개선하였습니다.

API 호출 공통 모듈은 httpx 라이브러리를 기반으로 하며, 요청 및 응답 로깅, 타임아웃 설정(DEFAULT_TIMEOUT), 예외 처리(HTTPError), 그리고 호출 후 지연 시간(DELAY_SECONDS) 적용을 포함합니다. 이러한 모듈화는 네트워크 통신의 불안정성을 흡수하고, 모든 API 호출에 대한 일관된 로깅을 보장하여 디버깅 효율을 극대화합니다.

그러나 모듈화만으로는 데이터 조합의 복잡성을 해결할 수 없습니다. 여기서 핵심이 되는 것이 바로 DTO 통합 설계입니다. API 응답 데이터와 DB 조회 결과를 하나의 DTO(Data Transfer Object)로 통합함으로써, 검증 함수의 입력을 단순화하는 아키텍처적 해결책을 제시합니다.

구체적으로, 캐시백 유효성 검증 함수 check_exp_ssgmy_rsv_tgt는 5개의 파라미터(cashback_critn_dt, mbrsp_paymt_expc_dt, mbrsp_paymt_expc_type_cd, ssgmy_rsv_cnt, mbrsp_close_cnt)를 입력받아 불리언 값을 반환합니다. 초기에는 이 5개의 값을 각각 다른 소스에서 조회하여 전달해야 했으나, DTO 통합을 통해 이 값들이 하나의 객체로 캡슐화됩니다. 이는 검증 로직이 데이터의 출처(API인지 DB인지)에 대해 무관하게(Decoupling) 동작할 수 있게 해주며, 데이터 소스의 변경이 검증 로직에 영향을 미치지 않도록 격리합니다.

위 다이어그램에서 보듯, API 응답과 DB 데이터는 DTO 통합 객체 생성 단계에서 합쳐지며, 이후 검증 함수는 이 통합된 객체만을 참조합니다. 이러한 설계는 데이터 불일치(인코런스턴스)를 사전에 차단하는 데에도 기여합니다. DB 스키마나 메타데이터를 파싱해 DTO를 동적으로 생성하는 방식은 재사용성은 높일 수 있으나, 시나리오별 복잡한 비즈니스 로직 검증 시 오히려 ‘마법 값’이나 암묵적 의존성이 늘어나 디버깅 난이도를 올리는 역효과가 날 수 있습니다. 따라서 수동 설계의 가치를 인정하고, 명확한 필드 매핑을 통해 DTO를 정의하는 것이 시니어 엔지니어 관점에서 더 합리적인 트레이드오프입니다.

복잡한 캐시백 정책 검증 시나리오에서의 실전 적용 효과

DTO 통합 설계의 가치는 복잡한 비즈니스 정책 검증 시나리오에서 그 진가를 발휘합니다. 이번 테스트 자동화의 목표는 ‘쓱7클럽 캐시백 정책’이 정상적으로 적용되는지 검증하는 것이었습니다. 캐시백 적립 여부를 정확하게 확인하려면 ‘최초 유료결제일’, ‘유료결제 후 해지 여부’, ‘캐시백 적립 횟수’ 등 다양한 조건 정보를 확인해야 했습니다.

캐시백 정책의 세부 조건은 다음과 같습니다. 첫째, 유료 결제 후 해지 회원은 제외됩니다. 둘째, 유료결제월에 따라 캐시백이 차등 지급됩니다. 구체적으로, 2026년 4월까지의 유료결제월은 3회, 2026년 12월까지의 유료결제월은 2회, 그리고 2027년 1월 이후는 0회(TBD)로 설정되어 있습니다.

검증 로직은 이러한 정책 조건을 코드화하여 구현됩니다. check_exp_ssgmy_rsv_tgt 함수 내에서, 결제 예상 유형 코드(mbrsp_paymt_expc_type_cd)가 ’10’인 경우 캐시백 지급 대상에서 제외됩니다. 또한, 멤버십 해지 횟수(mbrsp_close_cnt)가 0 초과인 경우에도 제외됩니다. SSGMY 예약 횟수(ssgmy_rsv_cnt)가 기준일자별 예상 예약 횟수(exp_ssgmy_rsv_cnt)와 같으면 제외되며, 결제 예상일자(mbrsp_paymt_expc_dt)가 2027년 1월 1일 이후이고 SSGMY 예약 횟수가 0인 경우에도 제외됩니다.

이러한 복잡한 조건들을 검증하기 위해 정의된 테스트 시나리오는 다음과 같습니다. 1. 시나리오 1: 쓱7클럽 유료 가입 → 유료 정기결제 → 유료 정기결제 → 유료 정기결제 순으로 최초 유료 결제월에 따른 캐시백 지급 횟수를 검증합니다. 2. 시나리오 2: 쓱7클럽 무료가입 → 무료 해지 → 쓱7클럽 유료 가입 → 유료 정기결제 순으로 무료 해지 회원의 캐시백 지급 여부를 검증합니다. 3. 시나리오 3: 쓱7클럽 유료 가입 → 유료 해지 → 쓱7클럽 유료 가입 순으로 유료 해지 회원의 캐시백 지급 제외를 검증합니다.

이러한 시나리오들을 실행하기 위해 테스트 모듈은 사용자 토큰 발급(JwtTokenModule), 쓱7클럽 가입(MbrspMbrJoinModule), 쓱7클럽 해지(MbrspMbrCloseModule), 이용권 발급(MbrspUsrtIssueModule), 캐시백 유효성 검증(MbrspMbrJoinCashbackValiModule), 데이터 초기화(MbrspDataInitModule) 등 6종으로 분리되었습니다.

TEST_GROUP_LIST 딕셔너리는 그룹 번호 ’00’, ’10’, ’20’, ’30’, ’40’을 키로 하여 각 그룹에 실행할 모듈 리스트를 매핑합니다. 이러한 그룹 기반 실행 구조는 시나리오별 테스트 흐름을 명확히 정의하고, 모듈의 재사용성을 극대화합니다.

DTO 통합 설계가 가져오는 실무적 효과는 다음과 같습니다. 정책 변경 시 수정 범위가 최소화됩니다. 예를 들어, 캐시백 지급 횟수가 변경되거나 새로운 제외 조건이 추가될 경우, 검증 로직(check_exp_ssgmy_rsv_tgt)만 수정하면 되며, 데이터 조회 로직은 변경할 필요가 없습니다. 테스트 신뢰도가 높아집니다. 데이터 소스가 통합된 DTO를 통해 전달되므로, 데이터 불일치로 인한 테스트 실패(False Negative/Positive)를 줄일 수 있습니다. 디버깅 난이도가 낮아집니다. 검증 로직이 명확한 입력 값을 받기 때문에, 테스트 실패 시 원인을 빠르게 추적할 수 있습니다.

결론: 요약 및 향후 실행 가이드

시나리오 기반 테스트 자동화에서 DTO 통합 설계는 단순한 코드 리팩토링을 넘어, 테스트 인프라의 성숙도를 결정짓는 핵심 아키텍처입니다. 코드 중복과 개별 조회로 인한 구조적 한계를 극복하고, API 응답과 DB 데이터를 하나의 DTO로 통합함으로써, 복잡한 비즈니스 정책 검증의 복잡도를 효과적으로 관리할 수 있습니다.

향후 실행 가이드로서, 시니어 엔지니어들은 다음과 같은 체크포인트를 준수해야 합니다. 1. 모듈화 우선: 반복되는 기능은 반드시 파일, API, DB, 로그, 설정 5가지 카테고리로 분류하여 공통 모듈로 분리해야 합니다. 2. DTO 통합: 정책 검증에 필요한 데이터는 API 응답과 DB 조회 결과를 하나의 DTO로 통합하여 검증 함수의 입력을 단순화해야 합니다. 3. 명확한 검증 로직: 정책 조건은 명확한 파라미터를 기반으로 한 검증 함수로 구현하고, 마법 값(Magic Number)을 최소화해야 합니다. 4. 그룹 기반 실행: 테스트 시나리오는 모듈 리스트를 매핑한 TEST_GROUP_LIST와 같은 구조를 통해 관리하여 재사용성과 가독성을 높여야 합니다.

이러한 접근법을 통해, 테스트 자동화의 유지보수 비용을 절감하고, 비즈니스 로직의 변경에 민첩하게 대응할 수 있는 견고한 테스트 인프라를 구축할 수 있습니다. 특히, DB 정보에 따른 DTO 자동화 등도 고려해 볼 수 있으나, 시나리오별 복잡한 비즈니스 로직 검증 시에는 수동 설계의 가치를 인정하고 명확한 필드 매핑을 통해 DTO를 정의하는 것이 디버깅 난이도를 낮추는 데 더 효과적입니다. 이를 통해 테스트 자동화는 단순한 반복 작업의 대체를 넘어, 소프트웨어 품질 보증의 핵심 동력으로 자리매김할 것입니다.

관련 포스트

24시간 잠들지 않는 파이프라인, 이벤트 기반 비동기 에이전트 백엔드 설계 프로덕션 환경에서 마주한 LLM 비용 폭탄, 병목 추적 및 시행착오 회고 목적별 AI 기술 매핑과 엔지니어링 체크리스트, 현업 즉시 적용 액션 플랜 시니어 엔지니어 문서화 전략으로 비동기 조직의 정렬 속도를 극대화하는 방법