API Gateway 도입 (단일 진입점, 공통 기능, 운영 복잡성)
API Gateway를 처음 도입할 때 이게 정말 필요한 건가 싶었습니다. 각 서비스마다 인증 방식이 달라서 클라이언트 개발자들이 매번 문의를 했고, 로깅도 제각각이라 문제 추적이 어려웠지만, Gateway를 추가하면 오히려 관리할 게 더 늘어나는 거 아닌가 하는 생각이 들었거든요. 그런데 실제로 적용해보니 예상과는 다른 결과가 나왔습니다. 마이크로서비스 환경에서 클라이언트와 내부 서비스 사이에 단일 진입점을 두면 시스템 구조가 훨씬 단순해지더군요. 모든 요청을 하나로 모으는 단일 진입점 구조 여러분은 클라이언트가 10개가 넘는 마이크로서비스를 각각 직접 호출하는 구조를 상상해보신 적 있으신가요? 초기에 그런 구조를 사용했는데, 서비스마다 엔드포인트가 다르고 인증 방식도 달라서 프론트엔드 개발자들이 매번 혼란스러워했습니다. API Gateway를 도입하면 이 모든 요청을 하나의 진입점에서 받아서 적절한 서비스로 라우팅할 수 있습니다. 클라이언트 입장에서는 Gateway 주소 하나만 알면 되니까 훨씬 편해지는 거죠. 제 경험상 Gateway 도입 후 클라이언트 코드가 30% 정도 줄어들었습니다. 내부 서비스 구조가 바뀌어도 Gateway의 라우팅 설정만 수정하면 되니까 클라이언트는 영향을 받지 않았고요. 이런 점에서 단일 진입점 구조는 시스템의 결합도를 낮추는 데 확실히 효과적이었습니다. 다만 초기 설정할 때 라우팅 규칙을 잘못 작성해서 일부 요청이 엉뚱한 서비스로 가는 실수도 있었습니다. 이 부분은 테스트 자동화로 해결했습니다. 인증과 로깅을 중앙에서 처리하는 공통 기능 관리 각 마이크로서비스마다 인증 로직을 따로 구현하면 어떤 문제가 생길까요? 실제로 그렇게 운영하다가 서비스마다 JWT 검증 방식이 조금씩 달라지는 문제를 겪었습니다. 한 서비스는 토큰 만료 시간을 1시간으로 설정했고, 다른 서비스는 30분으로 설정해서 사용자들이 자꾸 로그아웃되는 현상이 발생했거든요. API Gateway에서 인증을 중앙 관리하면 이런 일관성 문제를 한 번에 해결...