이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Spring 백엔드 개발자와 인프라 담당자는 운영에서 무엇을 각각 책임지는가?
- 장애 중 역할 경계가 불분명하면 어떤 문제가 생기는가?
- 인프라 담당자에게 어떤 자료를 주면 운영 판단이 빨라지는가?
개요
백엔드와 인프라의 역할 경계는 “누가 더 많이 아는가”가 아니라 “어떤 증거와 결정을 누가 책임지는가”의 문제다.
백엔드 개발자는 서비스 코드, API 계약, Spring 설정, DB 접근, 로그와 metric의 의미를 가장 잘 안다.
인프라 담당자는 서버, 네트워크, 배포 런타임, 권한, Load Balancer, TLS, 관측 시스템, 자원 한계를 가장 잘 본다.
운영 장애는 이 둘의 접점에서 자주 발생한다.
역할을 나누는 기준
역할은 기술 이름보다 변경의 소유권으로 나누는 편이 정확하다.
백엔드가 주로 책임지는 것:
- API 동작과 에러 처리
- Spring profile과 application 설정 계약
- DB migration과 트랜잭션 경계
- Actuator health가 무엇을 의미하는지
- 로그 필드, correlation id, business error code
- timeout, retry, circuit breaker 정책
- 배포 후 smoke test 시나리오
- 장애 회고에서 코드 변경 맥락
인프라가 주로 책임지는 것:
- VM, container runtime, Kubernetes 같은 실행 환경
- CPU, memory, disk, network 자원
- Nginx, Load Balancer, DNS, TLS
- Secret 저장소와 배포 권한
- 로그 수집, metric 저장, alert routing
- autoscaling, rollout, rollback 도구
- 백업, 스냅샷, 네트워크 접근 제어
공동으로 봐야 하는 것:
- health check 기준
- 배포 전략
- DB 연결 총량
- 장애 severity
- 복구 우선순위
- 변경 동결 여부
- 사용자 공지와 incident report
좋은 협업 요청
좋은 요청은 사실과 모르는 부분을 분리한다.
확인한 것:
- 15:20부터 payment-api POST /api/payments p95가 300ms에서 6s로 증가
- 같은 시간대 5xx가 0.2%에서 2.7%로 증가
- 15:05에 payment timeout 설정 변경 배포
- Spring 로그에는 ExternalPaymentTimeoutException 증가
- Hikari pending은 정상 범위
모르는 것:
- Nginx upstream별 502 비율
- 외부 결제망으로 나가는 egress 지연
- 해당 인스턴스의 network error 증가 여부
요청:
- 15:10~15:35 Load Balancer target별 5xx와 network 지표 확인이 요청은 인프라 담당자가 어디를 봐야 하는지 명확하게 만든다.
Spring 설정 계약
백엔드와 인프라가 반드시 맞춰야 하는 대표 계약은 설정이다.
server.port=8080
management.server.port=8081
management.endpoint.health.probes.enabled=true
spring.profiles.active=prod
spring.datasource.hikari.maximum-pool-size=20이 값들은 코드만의 문제가 아니다.
Nginx나 Load Balancer는 어떤 port로 health check를 보낼지 알아야 한다.
운영자는 pool size와 인스턴스 수를 곱해 DB max connections와 비교해야 한다.
profile과 Secret 주입 방식이 바뀌면 배포 도구도 함께 바뀐다.
Health Check 경계
Health check는 역할 경계가 특히 자주 어긋나는 지점이다.
백엔드는 /actuator/health/liveness와 /actuator/health/readiness가 무엇을 검사하는지 정해야 한다.
인프라는 그 endpoint를 어떤 주기, timeout, 실패 횟수로 호출할지 정해야 한다.
둘 중 하나라도 틀리면 다음 문제가 생긴다.
- 아직 준비되지 않은 인스턴스가 트래픽을 받는다.
- 일시적인 외부 API 장애 때문에 모든 인스턴스가 빠진다.
- DB 장애 중 liveness까지 실패해 불필요한 restart가 반복된다.
- health endpoint는 정상이지만 핵심 API가 실패한다.
장애 중 의사결정 경계
장애 중에는 역할을 더 좁게 나눈다.
백엔드는 다음을 빠르게 제공한다.
- 최근 배포와 설정 변경
- 문제 API와 business impact
- 관련 로그 샘플과 trace id
- 기능 차단 가능 여부
- read-only mode 가능 여부
- rollback 시 코드 호환성
인프라는 다음을 빠르게 제공한다.
- 인스턴스별 resource 사용률
- Load Balancer target health
- Nginx status code 분포
- 네트워크 오류와 TLS 오류
- 로그/metric 수집 지연 여부
- 배포 도구와 권한 상태
공동 결정은 다음이다.
- 추가 배포 중단 여부
- rollback 실행 여부
- 특정 endpoint rate limit 여부
- 사용자 공지 여부
- incident severity
- 장애 회고 담당자
운영 체크리스트
- 서비스별 owner와 escalation channel이 있는가?
- 배포 권한자와 rollback 권한자가 분리되어 있는가?
- Spring profile, port, health endpoint 계약이 문서화되어 있는가?
- 로그 필드와 trace id를 인프라 로그 수집기가 보존하는가?
- DB pool 총량을 백엔드와 인프라가 같은 숫자로 계산하는가?
- Secret 변경 절차와 재시작 영향이 정리되어 있는가?
- 장애 중 변경 동결을 누가 선언하는지 정해져 있는가?
장애 신호
- 백엔드는 정상이라고 하지만 Load Balancer target health는 실패한다.
- 인프라는 서버가 정상이라고 하지만 Spring 로그에는 dependency timeout이 증가한다.
- Nginx 502와 Spring 5xx를 구분하지 않고 같은 장애로 말한다.
- pool size를 백엔드가 올렸는데 DB max connections를 아무도 계산하지 않았다.
- Secret rotation 후 특정 인스턴스만 인증 실패를 낸다.
- health check 정책 변경 후 restart loop가 발생한다.
하지 말아야 할 대응
- “인프라 문제”라고 단정하고 코드 변경 이력을 제공하지 않는다.
- “애플리케이션 문제”라고 단정하고 서버와 네트워크 지표를 보지 않는다.
- 장애 중 소유자 없이 여러 사람이 동시에 설정을 바꾼다.
- Load Balancer health check를 임시로 끄고 트래픽을 계속 받게 한다.
- pool size, timeout, retry를 한 번에 올린다.
- incident report를 팀별로 따로 작성해 타임라인이 달라지게 한다.
인프라 담당자에게 줄 자료
운영 협업 요청에는 다음을 포함한다.
- 서비스명과 환경
- 배포 버전과 적용 시간
- 문제 endpoint와 사용자 영향
- 오류 로그 샘플과 trace id
- 관련 Spring 설정 값
- health check 결과
- metric 변화 전후
- 이미 수행한 완화 조치
- 확인을 요청하는 계층
요청 범위: Nginx/LB 계층 확인
근거: Spring access log에는 요청이 없는데 client는 502를 받음
시간대: 16:02~16:15 KST
서비스: order-api prod
최근 변경: 15:55 Nginx upstream weight 조정이처럼 범위를 좁혀야 협업이 빨라진다.
실전 팁
- 역할 경계 문서는 조직도가 아니라 장애 중 질문 목록이어야 한다.
- 백엔드는 관측 가능한 application signal을 제공하고, 인프라는 runtime signal을 제공한다.
- 설정 값은 “누가 바꿀 수 있는가”와 “바꾸면 무엇을 재시작해야 하는가”까지 적는다.
- health check는 백엔드와 인프라가 함께 리뷰한다.
- 장애 회고는 코드, 설정, 인프라, 커뮤니케이션 타임라인을 하나로 합친다.
위험 신호!
- 운영 설정의 실제 owner가 없다.
- 인프라 담당자가 Spring health endpoint 의미를 모른다.
- 백엔드 개발자가 Load Balancer timeout과 application timeout의 관계를 모른다.
- 장애 중 “확인 부탁드립니다”만 오가고 증거가 없다.
- rollback 권한은 있지만 rollback 판단 기준이 없다.
확인 질문
확인 질문
- 백엔드와 인프라 역할 경계가 필요한 이유는 무엇인가?
- 장애 중 각 계층의 증거와 의사결정 책임을 분리해야 원인 격리와 완화가 빨라지기 때문이다.
- Health check는 왜 공동 책임인가?
- 백엔드는 endpoint의 의미를 정하고 인프라는 그 신호로 트래픽과 재시작을 결정하기 때문이다.
- 인프라 담당자에게 “서버가 느립니다” 대신 제공해야 하는 정보는 무엇인가?
- 시간대, 서비스, endpoint, 배포 버전, 오류율, latency, 로그 샘플, trace id, 최근 변경, 확인 요청 계층이다.