네트워킹과 보안

개발자가 "그건 인프라팀 일이지" 하고 넘기는 네트워크와 보안에서 프로덕션 장애의 상당수가 시작돼.

개발 환경에서는 localhost 호출이니까 네트워크 지연이 없잖아. 근데 프로덕션에서는 서울-미국 왕복만 150ms, 라우터와 방화벽 거칠 때마다 지연이 추가되고, 네트워크가 혼잡하면 패킷이 유실돼서 재전송이 필요해. **"네트워크는 신뢰할 수 있다"**는 분산 컴퓨팅의 8가지 오류 중 첫 번째이자 가장 위험한 착각이야. 연결이 끊어지고, 패킷이 사라지고, 응답이 안 오고, 방화벽이 유휴 커넥션을 조용히 끊는 것 — 이게 전부 정상이야.

눈에 안 보이지만 모든 통신의 첫 단계인 DNS도 위험해. DNS 서버가 다운되면 이름 해석이 안 되니까 모든 외부 호출이 실패하고, 캐시된 레코드가 만료됐는데 DNS 서버에 접속 못 하면 막막해지지. DNS 라운드 로빈은 헬스체크가 없어서 죽은 서버의 IP도 계속 돌려줘. DNS 서버를 이중화하고, TTL을 적절히 설정하고, 애플리케이션에서 결과를 캐싱하되 주기적으로 갱신해야 해.

로드밸런서도 잘못 설정하면 장애 원인이 돼. 라운드 로빈, 가중치 라운드 로빈, 최소 연결, IP 해시 — 알고리즘마다 특성이 다르고, 핵심은 헬스체크야. L4(TCP 포트 확인)보다 L7(HTTP 엔드포인트 호출)이 더 정확해 — 포트가 열려있어도 애플리케이션이 장애 상태일 수 있으니까. 세션 어피니티가 필요 없도록 무상태 서버를 만드는 게 이상적이고. CDN은 성능 도구가 아니라 안정성 인프라야. 정적 콘텐츠를 엣지에서 서빙하면 원본 서버 부하가 줄고, 마케팅 이벤트나 바이럴 상황에서 트래픽 폭증을 흡수하는 방패 역할을 해줘.

네트워크를 다뤘으니 이제 보안 이야기야. **보안은 나중에 추가하는 기능이 아니라 시스템의 속성(property)**이야. 설계 단계부터 녹아있어야 하는 거지. DDoS는 안정성 문제이기도 하고, SQL 인젝션은 데이터 무결성 문제이기도 해. 보안 사고가 나면 시스템이 다운되고, 시스템이 다운되면 백업 절차로 전환하면서 보안 수준이 낮아지는 악순환이 생기거든. **최소 권한 원칙(Principle of Least Privilege)**이 기본 중의 기본이야. DB 커넥션이 root로 연결되면 안 되고, 애플리케이션이 admin 권한으로 돌아가면 안 돼.

OWASP Top 10은 웹 보안의 최소 필수 지식이야. 인젝션 — 파라미터화된 쿼리를 써. XSS — 출력을 인코딩해. CSRF — 토큰으로 방어해. 이것들은 20년 넘게 반복되는 취약점이야. 기술이 바뀌어도 근본은 같아 — 사용자 입력을 신뢰하지 마, 출력을 인코딩하고, 모든 통신을 암호화해. **인증(Authentication)**과 **인가(Authorization)**도 혼동하면 안 돼. 인증은 "너 누구야?", 인가는 "너 이거 해도 돼?". 그리고 이걸 직접 구현하지 마. 검증된 프레임워크(OAuth, JWT)를 써. 자체 구현은 거의 반드시 취약점을 만들어. "암호화를 직접 구현하는 것"과 같은 수준의 위험이야.

프로덕션 소프트웨어는 수십~수백 개 의존 라이브러리를 쓰고 있잖아. Dependabot이나 Snyk 같은 도구로 CVE를 자동 탐지하고, 취약점이 발견되면 빠르게 패치하는 프로세스가 필요해. 보안은 한 번의 감사로 끝나는 게 아니라 지속적인 프로세스야. CI/CD에 보안 스캔을 넣고, 정기적으로 의존성을 업데이트하고. 심층 방어(Defense in Depth) — 방화벽 하나에 의존하지 말고, 네트워크, 애플리케이션, 데이터 레벨에서 다중 방어선을 쳐. 한 겹이 뚫려도 다음 겹이 막아줘야 하니까.

---

정리

5장 읽고 기억할 거 세 가지:

1. 네트워크는 신뢰할 수 없어 — 패킷 손실, 지연, 연결 끊김은 정상이야. DNS 이중화, 로드밸런서 헬스체크, CDN으로 방어해.
2. 보안은 나중에 추가하는 기능이 아니라 처음부터 녹여야 할 속성이야 — 최소 권한 원칙과 심층 방어를 설계 단계에서 적용해.
3. 인증/인가는 직접 구현하지 마 — 검증된 프레임워크와 프로토콜(OAuth, JWT)을 써. OWASP Top 10은 최소한의 필수 지식이야.