서버의 눈, Gateway

걸리버 개발기

며칠 전 사용하던 안경에 작은 흠집이 생겨 안경점을 찾았다. 안경을 쓰고 대중교통을 타면 어지러운 경험을 했던 터라 도수의 조정도 부탁드렸다. 검안을 하고 설명을 들으니 흔하지 않게 수직 방향으로 난시가 진행되어서 어쩔 수 없는 측면이 있다고 한다. 하루가 다르게 노쇠하고 비루해지는 몸뚱아리의 일부분에, 이제 내 눈도 포함되는 것 같아 서글픈 마음이 들었다. 우리 몸의 수천가지 기관중에서도 눈은 매순간 수만가지 정보들을 받아들이는 직접 받아들이는 통로가 아닌가? 눈은 안경의 렌즈를 그 앞에 두고 차량이 흔들렸다고 바로 멀미를 할 정도로 민감하기도 하다. 물론 이 모든 감정들은 안경점을 나와 별다른 수고 없이 보이는 눈 앞의 풍경들에 금방 둔감해졌다.

어플리케이션의 동작을 위해 수만가지 요청들을 받아들이는 서버에도 눈과 같은 기관이 있다. 바로 게이트웨이이다. 보다 정확히 말하자면 게이트웨이도 하나의 서버이다. 수만가지 요청들을 안전하고 빠르게 받아들여야 하는 모든 어플리케이션의 공통적인 요구사항에 맞추어, 다른 서버와 분리된 전문화된 서버이다. 개발자들은 안정성과 성능이라는 모순된 요구 사항을 충족시키기 위하여 비지니스 로직을 위한 서버의 앞에 모든 서버들이 거쳐야 하는 서버들 둔다. 비지니스 로직과는 분리된(분리되지 않았다면, 분리되어야 한다.) 네트워크의 안정성과 성능만을 위한 서버를 따로 두고 게이트웨이라 부른다.

게이트웨이는 말 그대로 서버로 들어오는 요청들을 막는 문지기 역할을 한다.

서버로 들어오는 요청에는 두가지 특징이 있다. 첫째, 신뢰할 수 없다. 둘째로, 그 양이 많(아야 좋)다. 신뢰할 수 없기 때문에 안전하게 보안을 통과해야 하며, 양이 많기 때문에 빠르게 처리되어야 한다. 안전한 게이트웨이와 빠른 게이트웨이는 동시에 실현되기 어려운 반비례적인 관계에 놓여져 있다. 안전한 게이트웨이를 구현하기 위해서는 요청이 들어오는 포트를 제한하여 검열하고, 요청으로 들어온 패킷을 철저하게 분석하여, 암호화와 복호화를 통한 인증작업 또한 거쳐야 한다. 물론 안전한 게이트웨이를 위한 작업들이 넓어지고 깊어질 수록 게이트웨이는 느려진다. 사용자들의 인내심을 게이트웨이에서 전부 소비하지 않기 위하여, 개발자들은 서버를 병렬적으로 늘린다. 병렬적인 서버들 앞에서도 라우팅과 캐싱을 통하여 일관성을 유지해야함은 물론이다.

2025년 한국의 개발자들에게 게이트웨이를 구현하는 대표적인 선택지를 묻노라면, 아마 오픈 소스인 nginx 나 자바/코틀린 진영의 가장 유명한 프레임워크로 꼽히는 spring의 spring cloud gateway를 들지 않을까 한다. 둘다 사용해본 바로는 nginx는 리버스 프록시나 콘텐츠 캐시, 로드 밸런싱과 같은 게이트웨이의 핵심적인 요구사항에 주목한 반면, spring cloud gateway는 요청량의 조절이나 헤더와 주소의 수정, 토큰 처리와 같은 어플리케이션에 특화된 로직을 구현하기에 좋다. 개발을 업으로 삼아 살아가면서 이 두가지 솔루션을 적절히 조합해 안전하고 빠른 게이트웨이를 구축해둔 선배들에게 감탄과 감사를 보낼 때가 많았다.

문제는 감탄과 감사를 넘어 직접 게이트웨이에 코드를 더해야 하는 순간이 온다는 점이다. 솔직히 말하자면 네트워크의 최전선에서 하위의 모든 서버들에게 요청을 분배하는 게이트웨이의 코드는 함부로 건드리고 싶지 않은 것이 사실이다. 다른 서버의 코드를 배포할 때보다 게이트웨이의 코드를 배포할 때에는 모니터링과 알람들에 좀 더 민감해지곤 한다. 개발자가 배포를 무서워해서는 안된다지만, 게이트웨이 배포의 공포에서는 앞으로도 쉽게 둔감해지기 어려울 것 같다.