모킹을 멈추세요: 터미널에서 API 복원력을 테스트하는 방법 (Curl + Chaos Proxy)

Source: Dev.to

Introduction

“It works on my machine.”

우리는 모두 이렇게 말해 본 적이 있습니다. 하지만 서드‑파티 API가 응답하는 데 15 초가 걸린다면 여러분의 bash 스크립트는 제대로 동작할까요? 결제 제공업체에서 503 오류가 급격히 폭증할 때 백엔드 서비스는 이를 우아하게 처리할 수 있을까요?

간단한 재시도 로직을 테스트하기 위해 전체 모크 서버를 구축하는 것은 과도한 작업일 때가 많습니다. 이번 튜토리얼에서는 터미널에서 바로 Chaos Engineering을 수행하는 더 빠른 방법을 보여드리겠습니다.

curl과 클라우드 기반 Chaos Proxy를 사용해 애플리케이션 코드를 한 줄도 수정하지 않고 실제 네트워크 요청에 실패를 주입합니다.

The Problem: Localhost is Too Perfect

로컬에서 개발할 때 네트워크 지연은 거의 없습니다. API는 200 OK이든 아니면 (Connection Refused) 이든 두 가지 경우뿐이죠. 하지만 프로덕션에서는 다음과 같은 상황을 마주합니다:

• 높은 지연 – 서버가 바쁩니다.
• 간헐적인 실패 – 요청의 5 %가 떨어집니다.
• 쓰로틀링 – 레이트 리밋에 걸립니다.

터미널에서 이를 시뮬레이션하려면 보통 복잡한 iptables 규칙이나 tc(Traffic Control) 같은 로컬 도구가 필요합니다. 더 쉬운 방법이 있습니다.

The Solution: Cloud Chaos Proxy

운영체제를 설정하는 대신, 정의한 규칙에 따라 트래픽을 깨는 프록시를 통해 특정 요청을 라우팅합니다.

여기서는 chaos‑proxy.debuggo.app을 사용하지만, 개념은 어떤 프로그래머블 프록시에도 적용됩니다.

Video Guide (1:27)

시각적인 설명을 원하시나요? 90초짜리 워크플로우를 확인하세요.

Step‑by‑Step Tutorial

1. Define the Failure

프록시에게 어떤 실패를 줄지 알려줍니다.

• Target: httpbin.org (또는 여러분의 API 도메인).
• Delay: 7 seconds (지연을 시뮬레이션).
• Failure Rate: 1 (요청의 100 %가 실패).
• Error Code: 503 Service Unavailable.

2. Trust the Certificate (The “One‑Time” Setup)

HTTPS 트래픽을 가로채기 때문에 프록시의 CA 인증서를 신뢰해야 합니다.

1. 대시보드에서 mitmproxy-ca-cert.pem을 다운로드합니다.
2. macOS – Keychain Access → System에 추가하고 Always Trust로 설정합니다.
3. Linux – /usr/local/share/ca-certificates/에 복사하고 update-ca-certificates를 실행합니다.

3. The Magic Command

-x (proxy) 옵션을 사용해 curl을 실행합니다:

curl -v -x http://user:pass@chaos-proxy.debuggo.app:13979 https://httpbin.org/get

Understanding the Output

명령을 여러 번 실행하면 두 가지 시나리오가 나타납니다.

Scenario A – The Chaos (Delay + Failure)

터미널이 약 7 초 동안 멈춘 뒤 다음과 같이 반환됩니다:

< HTTP/1.1 500 Internal Server Error
< content-length: 56
< content-type: text/plain
...
Debuggo Chaos Injection: 500 Error

Scenario B – Success

절반 정도의 경우 요청이 실제 서버로 전달되어 다음과 같이 성공합니다:

< HTTP/1.1 200 OK
...
{
  "args": {},
  "headers": { ... }
}

Real‑World Use Cases

• Testing CI Pipelines – 종속성이 느려져도 배포 스크립트가 중단되지 않는지 검증합니다.
• Cron Jobs – 야간 데이터 동기화가 실패 시 올바르게 재시도되는지 확인합니다.
• Quick Sanity Checks – 코드를 푸시하기 전에 API 클라이언트가 503 오류를 어떻게 처리하는지 확인합니다.

Conclusion

네트워크 복원력을 테스트하기 위해 무거운 인프라가 필요하지 않습니다. 간단한 프록시 설정만으로 curl, wget, 혹은 Python/Node.js 스크립트 등 모든 HTTP 클라이언트에 혼돈을 주입할 수 있습니다.

Happy breaking! 🔨