인식한 상황
여러 개의 API 서버와 Django 기반 유사도 검색 서버를 각각 80 포트로 서비스하던 환경에서 다음과 같은 문제가 제기되었다.
직접적 요청 처리로 인한 보안 우려: 모든 요청이 개별 서버의 IP
조합으로 직접 접근됨에 따라, 보안 측면에서 노출 면이 넓어졌다. 공격자가 서버별 엔드포인트를 직접 파악하고 악용할 가능성이 존재했다. 접근성·편의성 저하: 서로 다른 서버마다 다른 주소 체계를 사용하는 것은 클라이언트(예: Android 앱) 입장에서 관리 및 접속 방식 통일이 어렵고, 설정 복잡성이 증가한다.
해결 과정
이러한 문제를 해결하기 위해 단일 진입점(Entry Point)을 통한 트래픽 라우팅 방식이 필요했다. 찾아본 결과 Nginx를 사용하여 해결해 보기로 했다.
Nginx 기반 프록시 서버 도입
최소 비용의 서버에 Nginx를 배포하여, 하나의 도메인으로 모든 요청을 받는 구조를 구현했다.
도메인 통합: http://naemansan.dcs-hyungjoon.com이라는 단일 도메인을 기준으로 Nginx에서 설정한 라우팅 규칙에 따라 내부 서버로 트래픽을 전달한다.
경로 기반 라우팅(Prefix Routing)
http://naemansan.dcs-hyungjoon.com/api/ → 내부 API 서버로 전달
http://naemansan.dcs-hyungjoon.com/similarity/ → Django 유사도 검색 서버로 전달
이를 통해 클라이언트는 복수의 서버 주소를 기억하거나 관리할 필요 없이, 도메인 + 접두사 형태로 쉽게 접근할 수 있었다.
Let’s Encrypt로 SSL 적용
하지만 안드로이드에서 http로 요청하니 요청 자체가 가지 않았다… (App은 신비로운 세상인가…)
이를 해결하기 위해 Nginx에 Let’s Encrypt 인증서를 연동해 HTTPS를 지원하게 했다.
찾아보니 모든 통신 구간이 TLS로 암호화되어 중간자 공격(MITM) 위험이 크게 감소한다. (이건 3 ~ 4학년 때 배우지 않을까…)
적용한 결과로 Android 기존에는 HTTP를 차단하는 환경 때문에 제약이 있었지만, 이제 HTTPS로 통합 접근이 가능했다!!
결과
일관된 API 주소 체계로 개발/운영 편의성 향상 되었다. 클라이언트에서 2개의 IP 주소를 알 필요가 없었고, 만약 내부적으로 서버를 추가하거나 서버 주소를 변경하는 경우에도 Nginx 설정만 변경하면 클라이언트 측 주소 변경 없이 손쉽게 구조를 개편할 수 있다. 또한, 직접 서버 접근 대신 통합 프록시를 거치게 됨으로써 서버 노출을 줄이고, 보안성을 높일 수 있었다.
하지만 사용한 기술인 Nginx에 대한 깊은 이해가 부족한 걸 너무 느꼈다… GZIP 이 뭐지… 이런 점을 새롭게 공부해 봐야겠다…