30년 된 FastCGI가 HTTP보다 리버스 프록시에 더 나은 이유

왜 갑자기 FastCGI 이야기인가요

웹 개발 좀 해보신 분이라면 "FastCGI"라는 단어를 한 번쯤은 들어보셨을 거예요. PHP를 nginx에 붙일 때 php-fpm을 쓰는데, 그게 바로 FastCGI거든요. 1996년에 만들어진, 거의 30년 된 프로토콜이에요. 그런데 최근 한 보안 엔지니어가 "리버스 프록시(앞단에서 요청을 받아 뒤에 있는 앱 서버로 넘겨주는 중간 서버)에는 사실 HTTP보다 FastCGI가 더 나은 선택"이라는 글을 써서 다시 주목받고 있어요.

보통 우리가 nginx나 Caddy 같은 프록시를 두고 그 뒤에 Node.js, Go, Python 앱 서버를 둘 때 거의 무조건 HTTP로 통신하잖아요. 8080 포트로 띄우고 프록시가 그쪽으로 요청을 넘기는 식이죠. 너무 당연해 보이는데, 이게 사실은 여러 가지 미묘한 문제를 만든다는 게 글의 요지예요.

HTTP를 내부 통신에 쓸 때 생기는 문제들

가장 큰 문제는 HTTP 자체가 양쪽 끝(클라이언트-서버)을 위해 설계됐다는 점이에요. 중간에 프록시가 끼면 어디까지가 원래 클라이언트 정보고, 어디부터가 프록시가 추가한 정보인지 헷갈리거든요. 예를 들어 클라이언트의 진짜 IP를 뒷단 앱 서버에 알려주려면 X-Forwarded-For 헤더를 써야 해요. 그런데 이 헤더는 표준이 아니라서 구현마다 제각각이고, 더 큰 문제는 악의적인 클라이언트가 똑같은 헤더를 위조해서 보낼 수 있다는 것이에요. 프록시가 매번 "이 헤더는 내가 덮어쓸게" 하고 신경 써야 하죠. 빼먹으면? IP 스푸핑 사고가 납니다.

HTTPS도 비슷해요. 프록시에서 TLS를 종료시키고 뒷단에는 평문 HTTP로 넘기는 게 일반적인데, 그러면 "이 요청이 원래 HTTPS였나, HTTP였나"를 알려줘야 하잖아요. X-Forwarded-Proto 같은 헤더를 또 추가해야 하고, 앱 서버는 이걸 신뢰할지 말지 정책을 세워야 해요. 요청 본문을 어디까지 받았는지(Content-Length), 연결을 유지할지(Keep-Alive) 같은 것도 프록시가 한 번 해석하고 다시 만들어내야 하고요. 요청 스머글링(Request Smuggling) 같은 공격은 바로 이 "두 번 해석"의 빈틈을 노리는 거예요.

FastCGI는 뭐가 다른가요

FastCGI는 애초에 "프록시 뒤에 있는 앱 서버"를 위해 설계된 프로토콜이에요. 요청을 키-값 쌍의 환경변수처럼 전달해요. 클라이언트 IP는 REMOTE_ADDR, 원래 프로토콜은 HTTPS=on, 요청 경로는 REQUEST_URI 같은 식으로 명확하게 분리되어 있죠. 헤더와 메타데이터가 섞이지 않아요. 클라이언트가 REMOTE_ADDR를 위조해서 보내려고 해도, 그건 HTTP 헤더가 아니니까 애초에 프록시가 받지를 않아요. 위조 자체가 불가능한 거예요.

또 FastCGI는 요청과 응답을 레코드(record) 단위로 주고받아요. 각 레코드에 길이가 명시되어 있어서 "여기까지가 헤더, 여기부터가 본문" 같은 모호함이 없어요. HTTP에서 chunked transfer encoding과 Content-Length가 충돌해서 생기는 그 유명한 스머글링 취약점이 FastCGI에선 구조적으로 발생하기 어렵습니다.

그런데 왜 다들 HTTP를 쓰나요

현실은 "FastCGI는 PHP용"이라는 인식이 너무 강해요. Go, Node.js, Rust 생태계의 웹 프레임워크들은 대부분 HTTP 서버로 만들어져 있고, FastCGI 어댑터는 잘 안 쓰여요. 디버깅도 HTTP가 훨씬 편하죠. curl 한 번이면 되니까요. FastCGI는 전용 도구(cgi-fcgi 같은)가 필요해요.

비슷한 시도로는 AJP(Apache JServ Protocol), SCGI, 최근의 gRPC, HTTP/2 over Unix socket 등이 있어요. 다들 "내부 통신을 더 효율적이고 안전하게"라는 같은 문제를 풀려고 했죠. 하지만 표준화의 힘 앞에서 HTTP가 늘 이겼어요.

한국 개발자에게 주는 시사점

당장 내일부터 사내 인프라를 FastCGI로 바꾸자는 얘기는 아니에요. 다만 "왜 이 헤더를 신뢰하면 안 되는지", "왜 프록시 설정이 이렇게 까다로운지" 같은 질문에 대한 좋은 답을 얻을 수 있는 글이에요. 특히 사내에서 직접 인증 게이트웨이나 API 게이트웨이를 만드는 분이라면, 헤더 신뢰 정책을 어떻게 세울지 설계할 때 이 관점이 큰 도움이 됩니다. PHP-FPM을 운영하는 분이라면 "이게 그냥 옛날 방식이 아니라 의외로 잘 설계된 프로토콜이었구나" 하고 새롭게 보일 거예요.

마무리

오래된 기술이라고 무조건 낡은 건 아니에요. FastCGI는 "내부 프록시 통신"이라는 좁은 문제를 정확히 풀려고 만든 도구라, 30년이 지나도 그 자리에서는 여전히 잘 작동해요. 여러분은 사내 서비스 간 통신에 HTTP를 쓰면서 불편함을 느낀 적 있나요? 만약 새로 설계한다면 어떤 프로토콜을 골라보고 싶으세요?