내 서버인데 왜 마음대로 못 쓰냐고요

Part I

개발자 서버의 역할과 범위

각 개발자에게 할당된 서버는 Proxmox(192.168.0.104) 위의 가상 머신(VM)이다. Chris(202), Lucy(203), Evan(204). 이 서버들의 목적은 단 하나 — 개인 개발과 테스트다.

운영 서비스를 올리는 공간이 아니다. 인프라를 실험하는 공간도 아니다. Docker 컨테이너를 띄우고, API를 테스트하고, 코드를 빌드하는 곳이다. 그 이상은 인프라 서버의 영역이다.

개발 환경

Docker 컨테이너 실행, 로컬 DB 구동, 개발 서버 기동. 모든 개발 작업의 기본.

테스트 환경

단위 테스트, 통합 테스트, API 호출 검증. 운영 데이터가 아닌 테스트 데이터로만 작업한다.

빌드 환경

프로젝트 빌드, 패키지 생성, CI/CD 전 로컬 검증. GitLab CI가 처리하기 전 사전 확인용이다.

Part II

해도 되는 것 vs 하면 안 되는 것

해도 되는 것

Docker 컨테이너 실행 (개발/테스트용)

로컬 DB 구동 (PostgreSQL, MySQL, Redis 등)

개발 서버 기동 (npm run dev, python manage.py runserver 등)

테스트 스크립트 실행

빌드 및 패키징 작업

팀원에게 IP:포트로 임시 공유 (사내 네트워크 한정)

하면 안 되는 것

Traefik/Nginx/HAProxy 등 리버스 프록시 설치

SSL 인증서 개별 발급 (Let's Encrypt 직접 호출)

Consul에 서비스 수동 등록

운영 서비스 배포 (고객 대상 서비스 금지)

인프라 서버(230~236) 설정 변경

도메인을 직접 연결하여 외부 공개

핵심은 인프라 계층을 건드리지 않는 것이다. 리버스 프록시, SSL, 서비스 디스커버리는 인프라 서버의 역할이다. 개발자 서버에서 이 영역을 침범하면 전체 인프라에 영향을 줄 수 있다.

Part III

실제 문제 사례 — Traefik 이중 설치

사고 시나리오

Evan(204) 서버 8080 포트에 Traefik을 설치한 경우

개발 중인 서비스를 외부에 노출하기 위해 자체 Traefik을 설치했다. 도메인도 붙이고 SSL도 직접 발급했다. 처음에는 작동하는 것처럼 보인다.

그러나 다음 문제가 발생한다.

역할 충돌

이중 라우팅 경로가 생성된다

중앙 Traefik(230)과 Evan의 Traefik(204)이 동시에 동일 도메인의 요청을 처리하려 할 수 있다. DNS 설정에 따라 트래픽이 어디로 흐를지 예측할 수 없다. 디버깅이 극도로 어려워진다.

Consul 연동 충돌

서비스 디스커버리가 꼬인다

두 Traefik이 동일한 Consul 클러스터(233~235)를 바라보면, 각각 다른 라우팅 규칙을 적용할 수 있다. 서비스 A는 중앙 Traefik을 타고, 서비스 B는 Evan의 Traefik을 타는 상황이 발생한다. 예측 불가능한 동작이다.

SSL 인증서 꼬임

Let's Encrypt Rate Limit 초과 위험

중앙 Traefik이 이미 해당 도메인의 인증서를 관리하고 있는데, Evan의 Traefik도 같은 도메인의 인증서를 요청한다. Let's Encrypt는 동일 도메인에 대해 주당 50개의 인증서 발급 제한이 있다. 갱신 주기가 꼬이면 인증서 만료로 서비스가 중단될 수 있다.

"내 서버니까 괜찮겠지"가
인프라 장애의 시작이다.

Part IV

올바른 방법

개발 중인 서비스를 외부에 노출하려면, 개발자 서버에 프록시를 설치하는 것이 아니라 중앙 Traefik(230)에 라우팅 규칙을 추가해야 한다.

올바른 절차

1단계. 개발자 서버에서 서비스를 원하는 포트로 실행한다. 예: 192.168.0.204:8080

2단계. 인프라 관리자에게 Traefik 라우팅 추가를 요청한다. 원하는 도메인과 포트를 전달한다.

3단계. 중앙 Traefik이 evan-app.yourdomain.com → 192.168.0.204:8080 라우팅을 설정한다.

4단계. SSL 인증서가 자동 발급되고, 접근 제어 정책이 일괄 적용된다.

이 방식의 장점은 명확하다. SSL 인증서 관리가 한 곳에서 이루어지고, 접근 제어 정책이 일관되며, 트래픽 흐름이 예측 가능하다. 개발자는 서비스 개발에만 집중하면 된다.

팀원에게 임시 공유할 때
# 사내 네트워크에서 IP:포트로 직접 접근 (Traefik 불필요)

http://192.168.0.204:8080

# 팀원이 같은 네트워크에 있으면 이것으로 충분하다
# 외부 공개가 필요할 때만 Traefik 라우팅을 요청한다

Part V

개발자 서버 사용 체크리스트

새 서버를 할당받았거나, 기존 서버에서 작업을 시작할 때 아래 체크리스트를 확인한다.

서버 초기 세팅

01SSH 키 등록 — GitLab(232)에 접근하기 위한 SSH 키를 설정한다
02Docker 설치 확인 — 개발 환경의 기본 도구. 없으면 설치 요청한다
03Git 설정 — git remote가 사내 GitLab을 가리키는지 확인한다
04방화벽 확인 — 사내 네트워크에서 필요한 포트가 열려있는지 확인한다

일상 작업 규칙

01리버스 프록시를 설치하지 않는다 — Traefik, Nginx, Caddy 등 모두 해당
02SSL 인증서를 직접 발급하지 않는다 — certbot, acme.sh 등 실행 금지
0380/443 포트를 점유하지 않는다 — 이 포트는 Traefik의 영역이다
04개발 서비스는 3000~9000 대역 포트를 사용한다
05사내 공유는 IP:포트로, 외부 공개는 Traefik 라우팅 요청으로 한다
06운영 데이터를 개발 서버에 복사하지 않는다 — 테스트 데이터를 사용한다

예외 허용 — 학습/테스트 목적

01Traefik을 학습 목적으로 설치하는 것은 허용된다
02단, Consul 및 중앙 Traefik과 완전히 격리된 상태여야 한다
03운영 트래픽이 흘러가지 않아야 한다 (도메인 연결 금지)
04학습이 끝나면 반드시 제거한다

이것만은 기억하라

개발자 서버는 개인 개발/테스트 전용이다 — 운영 서비스를 올리지 않는다
인프라 계층(프록시, SSL, 서비스 디스커버리)을 건드리지 않는다
외부 노출이 필요하면 중앙 Traefik에 라우팅 추가를 요청한다
"내 서버니까"라는 생각이 인프라 장애의 시작이다
의심이 들면 먼저 물어본다 — 사고 후 복구가 사전 질문보다 훨씬 비싸다

내 서버의 경계를 아는 것이
팀 인프라를 지키는 것이다

할 수 있는 것은 최대한 자유롭게, 하면 안 되는 것은 명확하게. 그 경계가 인프라의 안정성을 만든다.