무슨 일이 있었나요?
Cloudflare가 OHTTP(Oblivious HTTP) 게이트웨이를 발표했어요. 이름부터 좀 낯설죠? 그런데 이 기술은 여러분이 매일 쓰는 서비스 뒤에서 이미 조용히 돌아가고 있어요. 크롬 세이프 브라우징의 실시간 URL 검사나 애플 인텔리전스의 Private Cloud Compute 같은 곳에서 OHTTP를 쓰고 있거든요.
요즘 앱들은 사용자 데이터를 서버로 보내는 일이 정말 많아요. 사용 통계(텔레메트리)나 크래시 리포트를 보내고, 요즘은 AI 기능 때문에 사용자가 입력한 프롬프트까지 보내요. 문제는 서버가 요청 내용과 함께 IP 주소도 받는다는 점이에요. IP만 있어도 대략적인 위치와 통신사를 알 수 있어요. 같은 IP에서 온 다른 요청들을 엮으면 '이 사람이 뭘 하는지'까지 그려볼 수 있고요. 운영자에게 나쁜 의도가 없어도, 이런 정보가 로그에 쌓이는 순간 그 자체로 위험 요소가 돼요. OHTTP는 바로 이 문제를 풀려고 나온 표준이에요.
OHTTP가 뭐냐면요
비유를 하나 들어볼게요. 회사에 익명 건의 제도가 있다고 해볼게요. 건의서를 인사팀에 직접 내면 누가 냈는지 다 보이잖아요. 그래서 건의서를 인사팀만 열 수 있는 자물쇠 봉투에 넣고, 그 봉투를 외부 우편 대행 업체에 맡겨요. 우편 업체는 누가 맡겼는지 알지만 봉투를 못 열어요. 인사팀은 내용을 읽을 수 있지만 누가 보냈는지는 몰라요.
OHTTP가 정확히 이 구조예요. 2024년 1월에 RFC 9458로 표준이 됐고, 등장인물은 넷이에요.
- 클라이언트: 요청을 보내는 앱이에요.
- 릴레이(Relay): 우편 대행 업체 역할이에요. 클라이언트 IP는 보지만 내용은 못 봐요.
- 게이트웨이(Gateway): 봉투를 여는 쪽이에요. 내용은 보지만, 클라이언트 IP 대신 릴레이의 IP만 보여요.
- 타깃(Target): 복호화된 요청을 실제로 처리하는 서버예요.
실제로는 어떻게 흘러가나요
요청 하나가 오가는 과정을 순서대로 따라가 볼게요.
1. 클라이언트는 게이트웨이의 공개키 설정(application/ohttp-keys)을 미리 받아둬요.
2. 보내려는 HTTP 요청을 Binary HTTP(RFC 9292) 형식으로 직렬화해요. 메서드, 경로, 헤더, 바디를 통째로 바이트 덩어리 하나로 만드는 거예요.
3. 이 덩어리를 HPKE(RFC 9180) 로 암호화해요. HPKE는 상대방 공개키만 있으면 핸드셰이크 없이 한 번에 암호화해서 보낼 수 있는 하이브리드 공개키 암호화 표준이에요.
4. 암호문을 message/ohttp-req 타입으로 릴레이에 POST해요.
5. 릴레이는 내용을 모르는 채로 게이트웨이에 넘겨요. 게이트웨이는 이걸 복호화해서 타깃에 평범한 HTTP 요청으로 보내요.
6. 응답은 그 요청에서만 쓰는 키로 암호화돼서(message/ohttp-res) 같은 길을 거꾸로 돌아와요.
중요한 포인트는 요청 하나하나가 완전히 독립적이라는 거예요. 쿠키나 커넥션 재사용으로 요청들이 묶이지 않아요. 그래서 게이트웨이 입장에서는 두 요청이 같은 사람한테서 왔는지조차 알기 어려워요.
다만 전제 조건이 하나 있어요. 릴레이와 게이트웨이가 서로 짜고 정보를 합치면 안 돼요. 둘이 로그를 맞춰보면 IP와 내용이 다시 연결되거든요. 그래서 실제 서비스들은 두 역할을 서로 다른 회사에 맡겨요. 크롬 세이프 브라우징은 Fastly가 릴레이를 맡고 있고, 애플 PCC도 제3자가 운영하는 OHTTP 릴레이를 거쳐요. Cloudflare 게이트웨이를 쓴다면 릴레이는 다른 회사에 맡기는 구성을 고민해야 한다는 뜻이에요. 그리고 당연한 얘기지만, 요청 바디에 사용자 ID를 넣어 보내면 이 모든 게 소용없어져요.
비슷한 기술들과 비교하면
VPN은 업체 한 곳이 내 IP와 접속 목적지를 동시에 봐요. 신뢰를 한 곳에 몰아주는 구조죠. Tor는 여러 단계를 거쳐 중계해서 익명성은 강력하지만 느려요. 그리고 모든 트래픽을 감싸는 범용 도구예요. 애플의 iCloud Private Relay는 MASQUE라는 기술로 연결 자체를 두 단계로 터널링해서 웹 브라우징 전체를 보호해요.
OHTTP는 노리는 지점이 달라요. 웹 서핑 전체를 보호하는 게 아니에요. '이 URL 위험해?', '이 통계 하나 저장해줘', '이 프롬프트 처리해줘' 같은 짧은 단발성 API 호출에 특화돼 있어요. 연결을 통째로 터널링하지 않고 메시지 하나만 암호화해서 넘기니까 지연 시간이 별로 늘지 않아요. 대신 로그인 세션처럼 상태를 유지해야 하는 흐름에는 맞지 않아요. IETF에서는 큰 응답을 스트리밍하기 위한 확장(Chunked OHTTP)도 논의 중이에요. 이게 자리 잡으면 LLM 응답 스트리밍 같은 곳에서도 쓸 수 있을 거예요.
한국 개발자에게는요
당장 떠오르는 활용처는 세 가지예요.
첫째, 텔레메트리와 로그 수집이에요. IP 주소도 다른 정보와 결합하면 개인정보가 될 수 있어요. 서버가 애초에 IP와 내용을 함께 받지 않게 만들면 컴플라이언스(규정 준수) 부담이 확 줄어요.
둘째, AI 기능이에요. 사용자 프롬프트를 LLM 서버로 보낼 때 '누가'와 '무엇을'을 분리할 수 있어요. 애플이 PCC에 OHTTP를 쓴 이유도 이거예요.
셋째, 헬스케어나 핀테크처럼 민감한 데이터를 다루는 서비스예요. 생리 주기 앱 Flo가 익명 모드에 OHTTP를 도입한 사례가 대표적이에요.
직접 만져보고 싶다면 Rust의 ohttp 크레이트나 Go 구현체로 클라이언트를 짜보는 걸 추천해요. OHTTP의 핵심인 HPKE도 꼭 공부해둘 만해요. TLS의 Encrypted Client Hello(ECH)와 그룹 메시징 표준 MLS도 HPKE를 쓰거든요. 하나만 배워두면 여러 최신 프로토콜이 한꺼번에 이해돼요. 가격이나 지원 범위 같은 세부 조건은 Cloudflare 공식 블로그에서 꼭 확인해보세요.
마무리
한 줄 정리: OHTTP는 '누가 보냈는지'와 '무엇을 보냈는지'를 서로 다른 회사에 나눠 맡겨서, 어느 한 곳도 전체 그림을 못 보게 만드는 기술이에요.
여러분 서비스가 수집하는 로그 중에 내용은 필요한데 IP는 사실 필요 없는 데이터가 있나요? 그렇다면 OHTTP 같은 구조를 들일 만하다고 보시나요, 아니면 운영이 복잡해지는 부담이 더 크다고 보시나요?
🔗 출처: Hacker News