01. 개인 프로젝트에서 챙길 네트워크 기준 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 개인 프로젝트라도 “운영되는 백엔드”처럼 보이려면 어떤 네트워크 기준을 챙겨야 하는가?
• 도메인, HTTPS, reverse proxy, health, access log, smoke test를 어떻게 최소 구성으로 만들 수 있는가?
• 개인 프로젝트에서 수준 있는 결과물을 보여 주는 운영 증거는 무엇인가?

개요

개인 프로젝트도 누군가 접속한다면 운영 서비스다. 규모가 작다고 운영 품질이 필요 없는 것이 아니라, 규모가 작을 때 기본기를 갖추기 쉽다. 도메인, HTTPS, reverse proxy, timeout, health check, access log, 배포 후 smoke test만 있어도 “그냥 돌아가는 앱”에서 “장애를 좁힐 수 있는 앱”으로 바뀐다.

이 문서는 개인 프로젝트에서 과하게 복잡한 인프라를 만들지 않으면서도 백엔드 개발자로서 네트워크 운영 감각을 보여 주는 최소 기준을 정리한다.

왜 백엔드 개발자가 알아야 하는가

개인 프로젝트는 포트 하나 열고 배포하면 끝이라고 생각하기 쉽다. 하지만 실제 문제는 앱 코드 밖에서 자주 생긴다.

• 도메인이 이전 IP를 가리킨다.
• HTTPS 인증서가 만료되어 브라우저가 차단한다.
• reverse proxy timeout이 짧아 긴 API가 504를 낸다.
• access log가 없어 사용자의 장애 제보를 재현하지 못한다.
• /health가 없어 배포 후 앱이 준비됐는지 확인할 수 없다.
• CDN cache를 켰지만 purge 방법을 몰라 오래된 화면이 보인다.

이런 문제를 작은 프로젝트에서 직접 다뤄 보면 팀/기업 환경에서 인프라 담당자와 대화하는 감각이 빨리 생긴다.

요청 흐름에서의 위치

개인 프로젝트의 기본 요청 경로는 보통 이렇게 단순화된다.

Browser / Mobile
→ DNS
→ TLS
→ Reverse Proxy
→ Application
→ DB / Object Storage / External API

작아도 이 경로의 증거는 남겨야 한다. DNS는 어디를 가리키는지, TLS는 누가 종료하는지, proxy는 어떤 header와 timeout을 적용하는지, app은 request id와 health를 제공하는지 확인해야 한다.

원리

개인 프로젝트의 네트워크 기준은 “최소 운영 가능성”이다.

영역	최소 기준	수준을 올리는 기준
DNS	도메인과 A/CNAME 정리	TTL, 이전 IP 제거, 장애 시 변경 절차
HTTPS	자동 갱신 인증서	만료 알림, chain 확인, HTTP to HTTPS redirect
Reverse Proxy	NGINX/Caddy/Cloud proxy 사용	timeout, body size, forwarded header 명시
Health	/health 제공	readiness와 liveness 의미 구분
Logging	access log와 app log 위치 확인	request id를 응답 헤더와 로그에 남김
Timeout	기본값이 아니라 명시값 사용	app/proxy/external API timeout 표
Deploy	배포 후 접속 확인	curl smoke test와 rollback 명령
Backup	DB dump 또는 managed backup	복구 테스트
Monitoring	uptime check	latency, 5xx, cert expiry 알림

핵심은 멋진 도구가 아니라 “문제가 나면 내가 어디를 볼 수 있는가”다.

실무에서 자주 만나는 문제

• HTTPS 없이 배포하거나 인증서 만료를 모른다.
  • 브라우저와 모바일 앱은 TLS 문제를 강하게 차단한다.
  • 자동 갱신과 만료 알림을 둔다.
• reverse proxy 설정을 복사만 한다.
  • body size, timeout, forwarded header가 앱 동작을 바꾼다.
  • 설정값을 문서에 적고 smoke test한다.
• 로그가 없다.
  • 장애 제보를 받았을 때 시간, IP, path, status를 찾지 못한다.
  • access log와 app log를 남긴다.
• health check가 없다.
  • 배포 후 앱이 준비됐는지 브라우저로만 확인하게 된다.
  • /health endpoint와 curl check를 둔다.

디버깅 방법

개인 프로젝트 배포 후 최소 smoke test는 아래 정도면 충분히 가치가 있다.

dig +short example.com
curl -vI https://example.com
curl -sS -o /dev/null \
  -w "code=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://example.com/health
openssl s_client -connect example.com:443 -servername example.com </dev/null

확인할 것은 다음이다.

• 도메인이 기대한 IP나 proxy로 가는가?
• HTTPS 인증서가 정상인가?
• /health가 빠르게 200을 주는가?
• 첫 바이트가 비정상적으로 길지 않은가?
• 배포 직후 access log에 요청이 남는가?

코드로 확인하기

단순한 NGINX reverse proxy도 request id와 timeout을 명시하면 훨씬 좋아진다.

server {
    listen 443 ssl;
    server_name example.com;
 
    location / {
        proxy_pass http://app:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Request-ID $request_id;
 
        proxy_connect_timeout 2s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
        client_max_body_size 10m;
    }
}

간단한 smoke test 스크립트도 남긴다.

#!/usr/bin/env bash
set -euo pipefail
 
BASE_URL="${1:-https://example.com}"
 
curl -fsS "$BASE_URL/health" >/dev/null
curl -fsSI "$BASE_URL" | grep -i '^server\\|^x-request-id\\|^content-type'

스크립트가 있으면 배포 후 매번 같은 기준으로 확인할 수 있다.

주니어가 자주 하는 오해

• 개인 프로젝트는 운영 기준이 필요 없다고 생각한다.
  • 작은 서비스에서도 TLS, 로그, health, timeout은 사용자 신뢰와 직결된다.
• 브라우저에서 열리면 배포 검증이 끝났다고 생각한다.
  • DNS/TLS/status/timing/log를 함께 확인해야 한다.
• NGINX 설정은 복사해도 된다고 생각한다.
  • proxy header와 timeout은 앱의 redirect, cookie, client IP, 장애 양상을 바꾼다.
• monitoring은 회사에서만 필요하다고 생각한다.
  • uptime, certificate expiry, 5xx 알림만 있어도 대응 품질이 크게 달라진다.

시니어의 설계 판단 기준

• 개인 프로젝트라도 request path를 설명할 수 있어야 한다.
• 장애 시 볼 로그와 실행할 명령을 README나 runbook에 남긴다.
• 비용이 작은 managed service와 직접 운영의 trade-off를 안다.
• 보안 기본값인 HTTPS, secret 관리, backup, 최소 권한을 챙긴다.
• 배포 성공은 “프로세스 실행”이 아니라 “사용자 경로에서 smoke test 통과”로 본다.

인프라 협업 포인트

• 개인 프로젝트에서 직접 DNS/TLS/proxy를 다뤄 보면 인프라 팀의 언어가 익숙해진다.
• 인증서 자동 갱신, DNS 전파, proxy timeout, access log는 기업 환경에서도 그대로 쓰는 기본 개념이다.
• 작은 프로젝트의 runbook 경험은 장애 회고와 팀 운영 문서 작성으로 이어진다.

실전 팁

• README에 dig, curl -I, curl -w, 로그 위치, rollback 명령을 적어 둔다.
• 도메인과 인증서 만료일을 캘린더나 uptime monitor에 걸어 둔다.
• 파일 업로드가 있다면 body size와 storage 장애를 테스트한다.
• 외부 API를 쓰면 connect/read timeout과 fallback 메시지를 명시한다.

위험 신호!

• 서버 IP만 있고 도메인/HTTPS가 없다.
• 로그 위치를 모른다.
• /health가 없다.
• 배포 후 검증이 브라우저 새로고침 한 번이다.
• DB backup은 있지만 복구를 해 본 적이 없다.

확인 질문

확인 질문

• 개인 프로젝트에서 가장 먼저 챙길 네트워크 운영 기준은 무엇인가?
  • 도메인, HTTPS, reverse proxy, health check, access log, timeout, 배포 후 smoke test다.
• reverse proxy에서 X-Forwarded-Proto가 중요한 이유는 무엇인가?
  • 앱이 원래 요청 scheme을 알아야 HTTPS redirect, Secure cookie, absolute URL 생성이 올바르게 동작하기 때문이다.
• 개인 프로젝트 smoke test가 브라우저 확인보다 나은 점은 무엇인가?
  • DNS/TLS/status/timing/header를 반복 가능한 명령으로 확인할 수 있기 때문이다.

참고 문서

• NGINX Admin Guide, Reverse Proxy
• Spring Boot, Actuator Endpoints
• OWASP, Transport Layer Security Cheat Sheet
• Cloudflare Learning Center, What is DNS?