로그인 인증은 어느 계층에서 해야할까?

인증 위치는 아키텍처 설계에 따라 달라지며 공식적인 규칙은 없다.

 

우선 로그인 인증이 가능한 계층은 크게 총 3곳이다. 

 

- API Gateway 레이어

- Backend(서비스 서버, Spring 등)

- 파일 서버 / 별도 서비스

 

*선택적으로 Nginx에서 기본적인 접근제어가 가능하지만 토큰 인증까지는 대체로 안 한다.

 

실제 프로젝트에서 가장 많이 사용되는 패턴을 4가지로 나누면 아래와 같다. 

 

1) 게이트웨이 단독 인증 구조

JWT/AccessToken 검증을 하고 백엔드에서는 인증로직을 두지 않는다. 

장점: 백엔드 서버가 여러개일 경우 관리가 편하다.

 

사용처 예시)

쿠팡, 네이버, 카카오처럼 API Gateway를 제대로 운영하는 기업

Kong / Tyk / Apigee / AWS Gateway 기반 대규모 서비스

 

 

2) 백엔드(Spring) 단독 인증 구조 (한국 SI·공공에서 가장 흔함)

게이트웨이는 단순 프록시 역할만 하고 백엔드에서 로그인, JWT 검증을 모두 수행한다.

장점: 구조가 단순하고 구현이 쉽다. 게이트웨이가 없어도 돌아가고 기존 모놀리식 시스템과 잘 맞는다. 

 

사용처 예시)

한국의 대부분 SI, 공공기관, 전통 기업

도시가스 GIS, ERP, MIS 같은 업무 중심 시스템

단일 백엔드(Spring) 기반의 프로젝트

 

3) 게이트웨이 + 백엔드 이중 인증 구조 (현실에서 매우 흔함)

게이트웨이에서 1차로 토큰을 검증하고 백엔드에서 자체적으로 다시 2차 토큰 검증을 수행한다. 

장점: 당연하게도 보안이 강화되고 게이트웨이를 우회하는 경로가 있어도 백엔드에서 막힌다. 외부서비스를 연동할 시 안전한 구조이다. 

 

사용처 예시)

도메인 복잡한 금융, 공공기관

외부 시스템과 연동이 잦은 PG/페이/정산 시스템

인증 정책이 자주 바뀌는 엔터프라이즈 환경

 

 

4) 파일 서버 별도 인증 구조 (게이트웨이 우회)

게이트웨이를 거치치 않으므로 백엔드에서 파일인증 URL을 생성해서 파일서버 내에서 presigned URL, 헤더 검증, 내부망 제한 등으로 인증을 수행한다.

장점: 대용량 파일 트래픽을 게이트웨이를 거치지 않기 때문에 성능이 좋다.

 

사용처 예시)

이미지/문서 처리 시스템

파일 렌더링 서버(EntroLens 같은 역할)

지도 타일 서버(GIS)

AWS S3 presigned URL 패턴 따라감

 

 

결론

로그인 인증은 Gateway·Backend·FileServer 어느 레이어에서도 가능하며,

프로젝트 성격에 따라 단독/이중/분리형 등 다양한 조합으로 구성된다.

정해진 공식은 없고 “프로젝트 구조에 가장 자연스러운 위치”에 두는 것이 정답이다.