백엔드 개발자와 인프라 협업
3줄 요약
- 백엔드와 인프라는 요청 경로의 다른 구간을 맡지만 장애는 DNS, TLS, LB, proxy, WAF, health, log, timeout 같은 경계에서 자주 난다.
- 좋은 협업은 “봐주세요”가 아니라 목적, 대상, 증상, 증거, 기대 결과, rollback, 검증 방법을 함께 전달하는 것이다.
- 개인 프로젝트부터 기업 운영까지 수준이 올라갈수록 운영 증거, 공통 계약, 변경 관리, 보안 경계, 회고 action item이 중요해진다.
핵심 정리
- 개인 프로젝트도 운영 서비스다. 도메인, HTTPS, reverse proxy, health check, access log, timeout, smoke test만 갖춰도 장애를 훨씬 빨리 좁힐 수 있다.
- 팀 서비스는 개인 기억이 아니라 timeout, retry, health, request id, metric, deploy, runbook 같은 공통 운영 계약으로 움직여야 한다.
- 기업 운영에서는 보안, 감사, SLO, multi-AZ, capacity, change management가 설계 입력이다. 절차는 장식이 아니라 전체 장애와 보안 사고를 줄이는 장치다.
- 인프라 팀에 요청할 때는 DNS, TLS, LB, proxy, WAF, firewall마다 필요한 식별자를 정확히 줘야 한다.
- 인프라 담당자의 고충은 넓은 공통 계층을 적은 단서로 뒤져야 한다는 데 있다. 백엔드는 request id, health/readiness, graceful shutdown, access log로 이 비용을 줄인다.
- 장애 회고는 blame이 아니라 다음에 더 빨리 감지하고 좁히기 위한 관측, runbook, alert, owner 있는 action item을 남기는 과정이다.
헷갈리는 지점
- 인프라는 서버 올려주는 팀이라고 생각하기 쉽다.
- 핵심 판단 포인트는 인프라는 traffic 경로, 보안 경계, 가용성, 변경 위험을 운영한다.
- 백엔드는 앱만 정상 만들면 된다고 생각하기 쉽다.
- 핵심 판단 포인트는 timeout, health, log, forwarded header, shutdown은 앱과 인프라의 공동 계약이다.
- 개인 프로젝트에는 운영 품질이 필요 없다고 생각하기 쉽다.
- 핵심 판단 포인트는 작은 서비스도 HTTPS, 로그, health, smoke test가 있으면 신뢰도가 달라진다.
- 인프라 요청은 많이 설명할수록 좋다고 생각하기 쉽다.
- 핵심 판단 포인트는 긴 설명보다 정확한 URL, 시각, request id, source/destination, port, 최근 변경, 재현 명령이 더 빨리 문제를 좁힌다.
- 회고는 근본 원인 하나를 찾으면 끝이라고 생각하기 쉽다.
- 핵심 판단 포인트는 감지 지연, 진단 지연, 완화 지연, 관측 공백, 남은 위험을 함께 정리해야 다음 장애 대응 능력이 올라간다.
확인 질문
- 인프라 팀에 장애를 전달할 때 중요한 정보는 무엇인가?
- 발생 시각, URL, status, 응답 주체, request id, 영향 범위, 최근 변경, 확인한 명령 결과다.
- readiness 없이 배포하면 왜 인프라가 힘든가?
- 프로세스는 떠 있지만 준비되지 않은 target에 traffic이 들어가 502/503이 발생하기 때문이다.
- 개인 프로젝트에서 가장 먼저 챙길 운영 기준은 무엇인가?
- 도메인, HTTPS, reverse proxy, timeout, access log, health check, 배포 후 smoke test다.
- 기업 운영에서 절차와 변경 관리가 느린 장식이 아닌 이유는 무엇인가?
- LB, WAF, firewall, DNS, 인증서 같은 공통 계층 변경은 여러 서비스와 보안 경계에 동시에 영향을 줄 수 있기 때문이다.
- 좋은 장애 회고 action item은 어떤 조건을 가져야 하는가?
- 구체적이고 실행 가능하며 owner, due date, 검증 방법, 남은 위험을 포함해야 한다.