이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 인프라 팀에 장애나 변경 요청을 할 때 어떤 정보를 함께 줘야 확인이 빨라지는가?
- DNS, TLS, LB, proxy, WAF, firewall 요청은 각각 어떤 언어로 말해야 하는가?
- 인프라 담당자의 고충을 백엔드 개발자는 어떻게 이해하고 줄일 수 있는가?
개요
인프라 협업은 “봐주세요”가 아니라 “확인 가능한 요청”을 주고받는 일이다. 인프라 팀은 DNS, 인증서, LB, proxy, WAF, firewall, service discovery, observability 같은 공통 경로를 관리한다. 이 영역은 여러 서비스와 보안 경계를 함께 건드리기 때문에 변경이 조심스러울 수밖에 없다.
백엔드 개발자가 좋은 증거와 명확한 요청을 주면 인프라 팀은 훨씬 빠르게 움직일 수 있다. 반대로 발생 시각, URL, request id, status, 영향 범위 없이 “네트워크 문제 같아요”라고 말하면 확인 범위가 지나치게 넓어진다.
왜 백엔드 개발자가 알아야 하는가
백엔드와 인프라는 요청 경로의 다른 구간을 맡지만 장애는 경계에서 자주 난다.
- 앱이 readiness 없이 traffic을 받으면 인프라는 정상 target으로 보고 traffic을 보낸다.
- 앱이 request id를 넘기지 않으면 인프라 로그와 app 로그가 연결되지 않는다.
- 앱이 client IP 신뢰 경계를 모르고
X-Forwarded-For를 그대로 믿으면 보안 문제가 된다. - 백엔드가 timeout/retry를 무제한으로 두면 인프라가 막는 것처럼 보이지만 실제로는 앱이 traffic을 증폭한다.
- 인프라가 WAF rule을 바꾸면 정상 요청도 차단될 수 있으므로 app payload 특성을 알아야 한다.
협업은 역할을 떠넘기는 것이 아니라 경계를 명확히 하는 것이다.
요청 흐름에서의 위치
소통 지점은 주로 앱 앞뒤의 경계다.
DNS / CDN / WAF
→ LB / Gateway
→ Reverse Proxy
→ Application
→ Internal DNS / Firewall / Private Endpoint
→ DB / External API각 경계에는 owner가 있을 수 있다. 따라서 요청할 때 “어느 경계의 어떤 값을 확인하려는지”를 말해야 한다.
원리
좋은 요청은 여섯 가지를 포함한다.
| 요소 | 예시 |
|---|---|
| 목적 | 주문 API 502 원인 확인 |
| 대상 | api.example.com, listener 443, target group order-api |
| 증상 | 14:05부터 502, first byte 0.07s, app log 없음 |
| 증거 | request id, curl timing, response header, source IP |
| 기대 | backend health reason과 probe 결과 확인 |
| 안전장치 | 변경 시 rollback 값과 검증 명령 |
이 구조는 변경 요청에도 장애 요청에도 사용할 수 있다.
요청 유형별로 필요한 정보
| 요청 | 함께 전달할 정보 |
|---|---|
| DNS 변경 | 도메인, record type, 현재 값, 목표 값, TTL, 적용 시각, rollback 값 |
| 인증서 | 도메인, SAN, 발급 방식, termination 위치, chain, 만료일 |
| LB 설정 | listener, rule, target group, backend port, protocol, health path |
| Proxy timeout | endpoint, expected duration, body size, streaming 여부, app timeout |
| Client IP | 신뢰할 proxy hop, X-Forwarded-For, Forwarded, 보안 경계 |
| WAF 차단 | request id, source IP, path, method, 차단 시각, rule id, payload 특징 |
| Firewall | source, destination, port, protocol, 방향, 기간, 근거 |
| 장애 분석 | 발생 시각, 영향 범위, 응답 주체, trace id, 최근 변경 |
정보가 구체적일수록 인프라 팀은 로그 검색 범위를 줄이고 변경 위험을 판단하기 쉽다.
인프라 담당자의 고충
인프라 팀이 조심스러워 보이는 데에는 이유가 있다.
- 하나의 LB/WAF/DNS 설정이 여러 서비스에 영향을 줄 수 있다.
- DNS와 인증서는 전파 시간과 cache 때문에 즉시 되돌려도 즉시 복구되지 않을 수 있다.
- firewall/WAF 예외는 보안 사고 경로가 될 수 있어 근거가 필요하다.
- 앱 readiness가 부정확하면 인프라 health check가 틀린 신호를 받는다.
- timeout과 retry가 앱, proxy, service mesh에 중복되면 장애 중 누가 traffic을 만들었는지 찾기 어렵다.
- 로그 요청도 time range, request id, source IP가 없으면 검색 비용이 크다.
백엔드가 이 고충을 이해하면 요청 방식이 달라진다. “열어주세요”보다 “이 source에서 이 destination의 443 outbound가 필요하고, 검증은 이 curl로 하겠습니다”가 훨씬 낫다.
실무에서 자주 만나는 문제
- “네트워크 문제”라고만 말한다.
- 인프라 팀은 DNS, route, firewall, LB, proxy, WAF, service mesh 전체를 의심해야 한다.
- 확인한 계층과 아직 모르는 계층을 분리한다.
- 방화벽 변경을 즉시 반영되는 토글처럼 생각한다.
- 보안 검토, change window, audit, rollback이 필요할 수 있다.
- 근거와 기간을 명확히 요청한다.
- health check 200과 실제 기능 성공을 구분하지 않는다.
- readiness가 부정확하면 인프라가 잘못된 target에 traffic을 보낸다.
- 앱 팀이 readiness 의미를 책임진다.
- 인프라 로그를 요청할 때 식별자를 주지 않는다.
- time range, request id, source IP, path가 없으면 검색 비용이 커진다.
- 장애 보고 템플릿을 사용한다.
디버깅 방법
인프라 팀과 대화할 때는 요청 문장을 이렇게 바꾼다.
나쁜 요청:
LB 문제 같은데 확인 부탁드립니다.
좋은 요청:
2026-06-30 14:05 KST부터 POST /orders에서 502가 증가했습니다.
curl timing상 first_byte가 0.05s이고 app access log에는 request id가 없습니다.
ALB access log의 elb_status_code/target_status_code와 target health reason,
최근 listener rule 또는 target group 변경 이력을 확인 부탁드립니다.변경 요청도 마찬가지다.
나쁜 요청:
방화벽 열어주세요.
좋은 요청:
order-api pod에서 payment.internal.example.com:443으로 outbound HTTPS 호출이 필요합니다.
source namespace는 order, destination은 payment VPC endpoint이며,
검증 명령은 `curl -v https://payment.internal.example.com/health`입니다.
적용 후 5xx와 connection timeout metric을 확인하고, 문제 시 rule을 rollback하겠습니다.코드로 확인하기
백엔드가 제공하면 인프라 확인 범위가 줄어드는 로그 필드가 있다.
{
"timestamp": "2026-06-30T14:05:12+09:00",
"requestId": "7f0f0d6a7c1a4b87",
"method": "POST",
"path": "/orders",
"status": 502,
"clientIp": "203.0.113.10",
"xForwardedFor": "203.0.113.10, 10.0.1.20",
"upstream": "payment-api",
"durationMs": 57
}이런 구조화 로그는 인프라 로그와 app 로그를 연결하는 공통 언어가 된다. 단, client IP와 forwarded header는 신뢰할 proxy 경계를 정한 뒤 해석해야 한다.
주니어가 자주 하는 오해
- 인프라 팀은 서버를 열고 닫는 팀이라고 생각한다.
- 실제로는 traffic 경로, 보안 경계, 변경 위험, 공통 장애 영향을 함께 운영한다.
- 내가 원하는 변경이 작으니 바로 적용될 수 있다고 생각한다.
- 작은 rule 하나가 여러 서비스나 보안 정책에 영향을 줄 수 있다.
- app log가 없으면 인프라 문제라고 말한다.
- app 앞단에서 끝났을 수도 있지만, app의 health/readiness/header 설정이 원인일 수도 있다.
- header는 그냥 전달하면 된다고 생각한다.
X-Forwarded-*는 신뢰 경계가 없으면 spoofing 위험이 있다.
시니어의 설계 판단 기준
- 인프라 요청에는 목적, 대상, 증거, 검증, rollback을 포함한다.
- 변경 전에 현재 상태와 기대 상태를 둘 다 적는다.
- 앱이 인프라에 제공해야 할 계약을 명확히 한다. health, readiness, request id, access log, shutdown이 여기에 속한다.
- 보안 예외는 범위와 만료를 둔다.
- 장애 중에는 비난보다 영향 완화와 증거 보존을 우선한다.
인프라 협업 포인트
- DNS/TLS/LB/WAF/firewall 변경은 적용 전후 검증 명령을 공유한다.
- 앱 팀은 endpoint 특성, body size, expected latency, streaming 여부를 알려야 proxy/LB 설정이 맞는다.
- 인프라 팀은 가능한 경우 gateway status와 target status, upstream timing, rule id를 노출해 앱 팀이 스스로 좁힐 수 있게 한다.
- 서로의 고충을 줄이는 가장 좋은 방법은 공통 dashboard와 runbook이다.
실전 팁
- 요청 전에
내가 확인한 것,내가 확인할 수 없는 것,확인이 필요한 것을 세 줄로 나눈다. - 인프라 변경 요청은 ticket으로 남겨 감사와 회고가 가능하게 한다.
- 장애 중에는 “원인 같습니다”보다 “이 가설을 확인하려면 이 로그가 필요합니다”라고 말한다.
- 고마운 협업은 다음 장애에서 돌아온다. 회고에 인프라 팀이 제공한 유용한 신호도 남긴다.
위험 신호!
- “네트워크 문제”라는 말만 있고 DNS/TCP/TLS/HTTP 중 확인한 계층이 없다.
- 방화벽/WAF 예외가 영구적이고 owner가 없다.
- proxy/LB 설정 변경 후 앱 팀이 어떤 header와 path가 들어오는지 모른다.
- request id가 계층별 로그에서 서로 다르다.
- readiness가 부정확해 인프라 health check를 속인다.
확인 질문
확인 질문
- 인프라 팀에 장애 확인을 요청할 때 최소한 포함할 정보는 무엇인가?
- 발생 시각, 영향 범위, URL, method, status, response header, request id, source IP, 최근 변경, 확인한 명령 결과다.
- 방화벽 변경 요청에 source/destination/port/protocol이 필요한 이유는 무엇인가?
- 보안 경계를 정확히 제한하고 변경 영향과 rollback을 판단하기 위해서다.
- 인프라 담당자의 가장 큰 고충 중 하나는 무엇인가?
- 식별자 없는 넓은 요청을 받아 여러 공통 계층을 모두 뒤져야 하는 것이다.