이 글은 버그가 아니라 장애를 잡아라!! QA와 카오스 엔지니어링의 만남 – Application Level 편에 이어지는 두 번째 글입니다. 이전 편에서는 API 응답에 null을 주입해 애플리케이션 Level에서의 취약점을 찾았다면, 이번 Host Level 편에서는 상품 관리와 같이 커머스 핵심 서비스를 대상으로 서버, DB, 메시지 큐 같은 인프라 자체를 끊어보는 실험을 다뤄보려 합니다.

Host Level 테스트란?

Application Level이 애플리케이션 코드 내부의 취약점을 찾는 실험이라면, Host Level은 시스템을 구성하는 인프라 자체에 장애를 일으키는 실험입니다. 개발자가 아무리 견고한 코드를 작성해도, 그 코드가 실행되는 환경 자체가 무너지면 서비스는 멈춥니다. DB가 꺼지거나, 메시지 큐가 막히거나, 캐시 서버가 다운되는 상황 말이죠. Host Level 테스트는 바로 이런 상황을 의도적으로 만들어 시스템의 복원력(Resilience)을 검증합니다.

인프라 테스트의 주체: QA의 역할

카오스 엔지니어링은 이제 Netflix나 Amazon 같은 빅테크 기업만의 전유물이 아닙니다. 최근 테스트의 패러다임이 개발 초기 결함을 제거하는 Shift-Left에서, 실제 프로덕션 환경의 복원력을 검증하는 Shift-Right로 확장되면서 테스트 조직의 역할 범위도 함께 넓어지고 있습니다. 기존에 SRE나 개발팀이 전담하던 장애 복원력 검증 영역에 QA가 직접 참여하기 시작한 것입니다. 특히 AWS FIS, Gremlin 등 카오스 엔지니어링 도구의 보편화는 인프라 전문 지식 없이도 장애 시나리오를 설계하고 실행할 수 있는 환경을 만들어주면서, QA 주도의 회복 탄력성 테스트가 하나의 흐름으로 자리잡고 있습니다.

Host Level 테스트는 인프라 팀, 개발 팀, QA 팀이 협력하는 과정입니다. 그렇다면 이 테스트에서 각 팀은 무엇을 보게 될까요? 인프라를 직접 끊고 복구하는 것은 개발팀과 인프라팀의 몫입니다. 이 팀들은 서버가 재시작되는지, 로그가 정상인지, 메트릭이 회복되는지를 확인합니다. 그런데 시스템 관점에서는 "복구 완료"이더라도, 고객 관점에서는 "데이터가 꼬인 상태"일 수 있습니다. 이에 QA는 같은 장애를 고객의 눈으로 봅니다.

테스트 시나리오

QA가 담당하는 고객 및 관리자 시나리오 기반 기능 검증은 구체적으로 두 가지 관점에서 수행됩니다. 장애가 발생했을 때 고객이 실제로 마주하는 화면과, 관리자가 백오피스에서 겪는 상황을 각각 시나리오로 구성하여 검증합니다.

1. 고객 관점 - 앱/웹 시나리오

장바구니에 상품 담기 → 쿠폰 받기 → 증정품 포함 상품 주문하기 → 결제하기 → 주문 내역 확인하기 → 증정품이 포함되어 있는지 확인하기

이 과정에서 테스트 진행한 부분은 다음과 같습니다.

• 어떤 화면이 느려지는가
• 어떤 버튼이 무반응인가
• 에러 메시지가 고객에게 명확하게 전달되는가
• 복구 후 데이터가 유실되지 않았는가

2. 관리자 관점 - 백오피스 시나리오

상품 정보 수정하기 → 증정 행사 등록하기 → 쿠폰 생성하기 → 배너 설정 변경하기 → 복구 후 수정한 내용이 반영되어 있는지 확인하기

이 과정에서 테스트 진행한 부분은 다음과 같습니다.

• 장애 중 저장 버튼을 눌렀을 때 실제로 저장되는가
• 저장 실패 시 명확한 에러 메시지가 뜨는가
• 복구 후 장애 중에 수정한 데이터가 유실되지 않았는가
• 자동으로 반영되는가, 수동 작업이 필요한가

여기서 관계형 데이터베이스 장애 케이스를 예로 들어보겠습니다. QA는 아래와 같은 부분을 꼼꼼히 확인하고 기록합니다. 개발팀이 보는 로그에는 "성공"으로 찍혀 있어도, QA가 보는 화면에서는 "데이터 누락"일 수 있습니다. 특히 백오피스에서의 데이터 유실은 고객에게 직접 보이지 않아 더욱 주의 깊게 확인해야 합니다.

• 관리자가 상품 가격을 10,000원에서 8,000원으로 수정
• 장애 중이라 DB에 반영 안됨
• 복구 후 가격이 여전히 10,000원인가, 8,000원으로 변경되었는가?
• 변경 이력이 남아있는가, 완전히 유실되었는가?

테스트 대상과 실험 방식

저희는 "아마 괜찮겠지?"라는 막연한 믿음 대신, 실제로 인프라를 끊어보고 고객이 겪는 경험을 눈으로 확인하기로 했습니다. DB가 꺼지면? 캐시가 죽으면? 메시지 큐가 멈추면? 그리고 복구된 후에는? 이러한 질문들에 답을 찾기 위해, 올리브영의 핵심 인프라를 대상으로 테스트를 진행하였습니다.

대상 인프라 유형 및 테스트 환경

저희는 실제 고객에게 영향을 주지 않으면서도 운영 환경의 장애 상황을 시뮬레이션하기 위해, 모든 Host Level 테스트를 운영 환경과 동일하게 구성된 QA 환경에서 수행하고 있습니다. 이번에도 이러한 환경에서 올리브영 서비스를 떠받치는 핵심 인프라들을 차례로 테스트했습니다. 인프라 유형에 익숙하지 않은 분들을 위해 간략하게 소개하겠습니다.

테스트 방식

모든 노드 완전 차단 테스트(이하 완전 차단 테스트)와 1개 노드만 차단 테스트(이하 Failover 테스트) 두 개의 상황을 고려해 진행했습니다. 실제 장애는 전체 시스템이 단번에 중단되기보다 일부 노드에서 발생하는 경우가 훨씬 많긴 했지만 다양한 상황에 대비하기 위해 두 가지 경우를 모두 검증했고, 이 점이 바로 이번 테스트의 핵심입니다. 그리고 인프라 차단은 AWS 콘솔에서 대상 서비스를 직접 중지하는 방식으로 진행하였고, 테스트 진행 흐름은 다음과 같습니다.

1. 가설 수립: "이 인프라가 꺼지면 이런 문제가 생길 것이다"
2. 실험 설계: 어떤 시나리오로 어떤 서비스를 검증할지 계획
3. 인프라 차단: 실제로 서비스를 중지(down)시킴
4. 영향도 확인: 앱/웹에서 직접 테스트
5. 인프라 복구: 서비스를 다시 기동(up)
6. 복구 후 검증: 자동으로 정상화되는지, 수동 작업이 필요한지 확인

Host Level 테스트에서 발견한 3가지 핵심 패턴

사실 Host Level 테스트를 시작하기 전, 저희는 이미 예상 문제를 충분히 파악하고 있다고 생각했습니다. 하지만 실제로 인프라를 끊고 반기에 걸쳐 진행한 이번 테스트에서 예상과 전혀 다른 문제들이 훨씬 많이 나타났습니다. 이런 문제들은 놀랍게도 전혀 예상하지 못한 영역에서 발생했습니다. 아무리 설계를 잘하고, 코드를 꼼꼼히 작성해도, 실제 장애 상황에서는 생각지 못한 연쇄 반응이 일어났던 것입니다.

이 과정에서 9개의 주요 버그를 발견했고, 그 중 4개의 개선 과제는 즉시 조치를 완료했습니다. 나머지 5개 과제는 2026년 로드맵에 반영해 순차적으로 개선해 나가기로 계획을 수립했습니다. 이와 동시에 장애 감지 알림 체계를 구축해, 장애 발생 즉시 담당팀이 인지하고 대응할 수 있게 되었습니다. 이번 글에서는 발견한 주요 버그 중 대표적인 3가지 패턴을 공유하겠습니다.

패턴 1. "시스템은 살아있지만, 고객 경험은 무너진다."

[Case 1-1] 증정품이 빠진 채 결제 완료

데이터베이스가 꺼진 상태에서 증정품이 포함된 상품을 주문하면, 결제는 정상적으로 완료됩니다. 하지만 증정 정보가 빠진 채 주문이 생성됩니다. 주문 완료 화면에는 "주문이 완료되었습니다"라는 메시지가 뜨고, 고객은 이상 없이 주문됐다고 생각합니다. 그러나 주문 상세 페이지를 열면 증정품 항목이 보이지 않습니다. 고객은 배송을 받고 나서야 증정품이 빠졌다는 사실을 인지하고, 배송 완료 이후 고객센터에 문의하게 됩니다. 이런 케이스는 개발팀의 로그나 모니터링으로는 잡히지 않습니다. QA가 실제 시나리오를 수행하면서 주문 내역을 하나하나 확인해야 발견할 수 있습니다.

[Case 1-2] 결제 완료인데 504 에러 발생

메시지 큐 장애 시, 결제 버튼을 클릭한 고객은 로딩 인디케이터가 돌아가는 화면을 수십 초간 바라보게 됩니다. 그러나 기다림의 끝이 504 에러 화면이면 대부분의 고객은 결제에 실패했다고 판단하고, 결제 화면으로 되돌아갑니다. 그런데 [마이페이지 > 주문 내역]을 열면 방금 전 주문이 완료 상태로 기록되어 있습니다. 고객은 중복 결제를 우려해 고객센터로 문의하거나, 이미 결제된 줄 모르고 두 번째 결제를 시도합니다. 개발 관점에서는 비동기 처리라 응답만 느릴 뿐이지만, 고객 관점에서는 중복 결제 위험과 불안한 경험입니다.

패턴 1에서의 교훈: 시스템 로그가 정상이어도, 고객이 체감하는 경험은 장애일 수 있습니다.

패턴 2. "캐시는 5분짜리 방어막이다"

검색 엔진과 캐시 서버 앞단에는 추가 캐시 레이어가 있습니다. 원본 서버가 장애가 나도 TTL(Time To Live) 캐시 덕분에 약 5분간은 서비스가 정상처럼 보입니다. 하지만 5분이 지나면 아래와 같은 현상이 발생합니다.

• 검색이 완전히 불가능해짐
• 카테고리관·브랜드관 페이지 오류 발생
• 메인 화면이 매우 느려지거나 일부 영역이 사라짐

패턴 2에서의 교훈: 장애 감지부터 복구 또는 Failover 전환까지 5분 안에 완료해야 고객은 장애를 체감하지 않습니다. 이 기준은 모니터링 알림 설정과 복구 절차 설계에 반영하였습니다.

패턴 3. "복구 후가 진짜 테스트다"

인프라를 다시 켜면 시스템은 살아납니다. 하지만 QA가 진짜 확인해야 하는 것은 복구 후 데이터 정합성입니다. 아래 3가지 실전 사례들을 보며 이해를 도와보겠습니다.

[Case 3-1] 자동 복구 성공 사례 – 쿠폰 다운로드

쿠폰 서비스의 경우 시스템 장애 중에도 고객의 의도가 유실되지 않도록 설계되어 있어 성공적인 자동 복구를 이뤄낼 수 있었습니다. 장애가 발생한 시점에 고객이 쿠폰 다운로드 버튼을 눌러도 화면상으로는 즉각적인 반응이 나타나지 않는 상황이었지만, 내부적으로는 해당 요청 데이터가 안전하게 보관되었습니다. 시스템이 복구된 직후, 장애 기간 동안 적체되었던 요청 건들이 차례로 처리되면서 고객들이 시도했던 쿠폰들이 자동으로 쿠폰함에 지급되었습니다. 서비스가 정상화됨과 동시에 별도의 수동 작업 없이도 데이터가 제자리를 찾은 것입니다. 결과적으로 고객의 소중한 액션이 단 하나도 유실되지 않았다는 점이 핵심입니다. 장애 상황에서도 데이터 보존을 우선순위에 둔 설계 덕분에, 서비스 재개와 동시에 고객들에게 별도의 재시도 없이도 쿠폰을 전달하며 서비스의 안정성과 신뢰도를 동시에 증명할 수 있었습니다.

[Case 3-2] 복구 실패 사례 – 증정품 재고

장애 중 증정품이 포함된 상품을 여러 건 구매하면, 주문은 성공 처리되고 그만큼 재고가 차감됩니다. 그런데 인프라를 복구한 후 재고를 확인하자, 차감되어야 할 수량이 오히려 더해져 있었습니다. 판매했는데 재고가 늘어난 셈입니다. 이 상태를 모른 채 방치하면, 실제로는 없는 증정품이 계속 판매되거나, 재고 현황을 기반으로 한 행사 기획에 오류가 생깁니다. 장애 로그에는 "주문 성공" 외에 아무런 이상 신호가 없었기 때문에, QA가 직접 장애 전후 재고 수치를 비교하지 않았다면 발견하기 어려운 문제였습니다.

[Case 3-3] 수동 작업 필요 사례 – 상품 정보

장애가 지속되는 동안 시스템은 사실상 '멈춤' 상태였기 때문에, 해당 기간 내에 새롭게 등록되거나 수정된 상품 정보들이 데이터베이스나 검색 엔진에 자동으로 반영되지 못하는 문제가 발생했습니다. 시스템이 정상화된 이후에도 이 정보들은 여전히 장애 이전의 상태에 머물러 있거나 누락되어 있었습니다. 결국 서비스 복구 직후, 개발팀이 직접 개입하여 수작업으로 데이터 정합성을 맞추는 과정을 거쳐야만 했습니다. 운영 로그를 일일이 대조하며 누락된 상품 번호를 추출하고, 이를 시스템에 강제 업데이트하는 방식이었습니다. 이 과정에서 수작업에 따른 시간 지연과 휴먼 에러의 가능성을 체감하게 되었습니다. 이러한 비효율을 개선하기 위해, 장애 복구 시나리오 테스트를 거쳐 '복구 후 정합성 작업 전용 API'를 정식으로 개발했습니다. 이제는 장애가 종료된 후 특정 기간을 지정해 API를 호출하는 것만으로, 누락된 상품 데이터를 일괄 재동기화하여 데이터 무결성을 빠르고 정확하게 확보할 수 있게 되었습니다.

패턴 3에서의 교훈: 복구는 "서버를 다시 켜는 것"이 아니라 "고객 데이터가 온전한지 검증하는 것"까지 포함해야 합니다.

Host Level 테스트 후 수립한 영향도 평가 기준

저희는 Host Level 테스트 결과를 바탕으로 인프라 장애의 영향도를 평가하는 기준을 수립했습니다. 일반적인 시스템 메트릭이 아닌 고객이 체감하는 영향을 중심으로 분류했습니다.

3가지 축의 평가 기준

3가지 분류 등급과 대응 전략

Host Level 테스트가 바꿔놓은 5가지

카오스 엔지니어링 테스트의 가치는 단순히 "문제를 발견했다"는 데 있지 않습니다. 발견한 문제를 실제로 개선하는 것이 진짜 목적입니다. 이에 테스트를 통해 발견한 문제들을 크게 5가지 방향으로 개선하였습니다.

1. 장애 감지 및 알림 체계 구축

테스트 전에는 인프라 장애가 발생해도 고객 불만이나 모니터링 시스템으로만 인지할 수 있었습니다. 테스트 후 주요 인프라별 장애 감지 알림을 구축해, 장애 발생 즉시 담당팀이 인지하고 대응할 수 있게 되었습니다.

2. 자동 복구 메커니즘 강화

테스트에서 발견된 "서킷브레이커가 일부 영역에만 적용"되는 문제를 해결하기 위해, 이중화 구성과 서킷브레이커를 전면 점검했습니다. 장애 시 백업 경로로 자동 전환되도록 개선했으며, 일부 시스템은 2026년 기술 과제로 이중화 작업을 진행 중입니다.

3. 데이터 정합성 보장 프로세스

테스트에서 가장 심각했던 문제는 복구 후 데이터가 유실되거나 정합성이 깨지는 현상이었습니다. 이를 해결하기 위해 복구 후 자동으로 데이터를 추적하고 정합성을 검증하는 API와 프로세스를 구축했습니다. 또한 메시지 재처리 자동화 작업을 진행 중입니다.

4. 서비스를 안정적으로 운영하기 위한 기준 수립

• 시간 기준: 캐시 TTL이 약 5분이라는 것을 알게 되어, 장애 감지부터 복구까지 5분 안에 완료해야 고객이 장애를 체감하지 않는다는 기준을 수립했습니다.
• 복구 기준: 인프라를 다시 켜는 것만으로는 부족하고, 고객 데이터 정합성까지 확인해야 진짜 복구 완료입니다.
• 우선순위 기준: 고객 체감 영향도를 기준으로 Failover 구성 우선순위를 결정하게 되었습니다.

5. 정기 테스트 프로세스 정착

이번 테스트를 계기로 Host Level 카오스 엔지니어링 테스트를 정기적으로 수행하는 프로세스도 구축하였고, QA 팀은 이 과정에서 기능 모니터링 역할을 맡아 인프라가 차단된 상황에서 실제 앱/웹이 어떻게 동작하는지 시나리오 기반으로 검증하고 있습니다.

Host Level 테스트 프로세스 첫 적용 – 상품 상세 시스템 MSA 전환 프로젝트

테스트 목표

Host Level 테스트 프로세스를 정착시킨 후, 첫 번째로 실전에 적용한 케이스가 바로 올리브영 상품 상세 시스템 MSA 전환 프로젝트입니다. 특히 오픈 전에 Failover가 정상 동작하는지 검증하는 것이 주요 목표였습니다.

테스트 결과와 조치

서비스가 MSA로 전환되면서 DB 장애 시 백업 DB로 자동 전환되는 서킷브레이커가 구성되었고, 개발팀이 준비한 서킷브레이커는 실제로 동작했습니다. 로그에도 정상적으로 Circuit Open, Fallback 메시지가 찍혔습니다. 하지만 QA가 실제 화면을 확인했을 때에는 추측과 달랐습니다. 상품 정보는 정상적으로 가져오지만, 최대 혜택가를 계속 다운된 기존 DB에서 가져오려다 실패하면서 페이지 전체가 렌더링되지 않는 문제였습니다.

QA는 실제 화면을 보면서 왜 상품 상세 페이지가 안 뜨는지를 추적했고, 개발팀과 함께 최대 혜택가 영역에 서킷브레이커가 누락되어 있다는 것을 발견했습니다. 그런데 왜 미리 예상하지 못했을까요? 상품 상세 페이지에 상품 가격을 표시하기 위해서는 최대 혜택가 정보를 불러옵니다. 그런데 DB에 장애가 발생하면서 상품 상세 페이지에 표시할 가격을 불러오지 못해 페이지가 비어있게 된 것입니다.

MSA 구조에서는 각 서비스가 파편화되어 있다 보니, 특정 연관 서비스에 문제가 생겼을 때 우리 서비스에 어느 정도의 타격을 줄지 직관적으로 알기 어렵습니다. "설마 이 작은 API 하나 때문에 전체 페이지가 죽겠어?"라는 안일한 가정이 실제 장애로 이어지곤 합니다. 하지만 이번에는 테스트를 통해 문제를 발견할 수 있었습니다. 다만 오픈 전까지 서킷브레이커를 도입할 시간이 촉박했습니다. 이에 최대 혜택가 데이터를 불러오지 못할 경우 다른 곳에 있는 가격정보를 불러오는 형태로 방어 처리를 진행하고, 추후에 서킷브레이커를 적용하기로 했습니다. 만약 이 테스트를 하지 않았다면, 실제 장애 시 상품 상세 페이지 전체가 마비되는 상황을 고객이 겪었을 것입니다. 이렇듯 이번 사례는 신규 시스템 오픈 전 Host Level 테스트의 중요성을 보여줍니다. 개별 서비스의 로그는 정상이지만 연관 서비스 장애로 고객 경험은 무너지는 상황을, 오픈 전에 찾아낼 수 있었던 것입니다.

마무리 – QA는 고객보다 먼저 장애를 겪는다

Host Level 테스트는 단순히 "잘 버티는지" 확인하는 것이 아닙니다. "어떻게 무너지는지, 무엇이 예상과 다른지"를 찾아내고, 그것을 미리 고쳐 서비스를 더 단단하게 만드는 과정입니다. 그리고 이 과정에서 QA는 3가지 관점으로 서비스 안정성에 기여합니다.

1. 예상하지 못한 문제를 발견: 개발 단계에서는 예측하기 어려운, 실제 장애 시나리오에서만 드러나는 문제를 찾아냅니다.
2. 고객 경험 관점에서 검증: 시스템 로그에는 "정상"으로 보이지만 고객은 사용할 수 없는 상황을 발견합니다.
3. 서비스 안정화에 기여: 테스트를 통해 발견한 문제를 사전에 개선함으로써, 실제 장애 시 서비스가 더 견고하게 작동하도록 만듭니다.

저는 지난 Application Level 글에서 카오스 엔지니어링 테스트를 도입하는 이유 중 하나로 이렇게 말했습니다.

무엇보다 문제가 터졌을 때 놀라지 않기 위해 카오스 엔지니어링을 도입해 보는 건 어떨까요?

그런데 Host Level 테스트를 마치고 나서 이 생각이 더 깊어졌습니다. 문제가 터졌을 때 놀라지 않는 것을 넘어, 이제는 고객이 겪기 전에 먼저 경험하고 선제적으로 개선한다는 것이 새로운 목표가 되었습니다. 실제로 테스트 과정에서 예상하지 못한 문제들을 다수 발견했고, 그 경험을 통해 장애를 피할 수는 없지만 준비할 수는 있다는 확신도 얻었습니다. 그리고 그 준비의 중심에는, 시스템이 살아있더라도 고객 경험이 무너지는 간극을 메우는 QA가 있습니다.