PURL이란?

❐ PURL (Persistent URL)

---

개요

리소스의 실제 위치가 변경되더라도, 외부에 노출되는 URL을 고정하기 위한 개념

• PURL은 새로운 프로토콜이 아니라 아키텍처 개념이다.
• 고정된 URL(PURL)과 변경 가능한 실제 URL(Target URL)을 분리한다.
• HTTP 리다이렉트를 이용해 이를 구현한다.
• 목적은 ‘영구 식별자 유지’ 하나에 집중한다.

기본 구조

고정 주소와 실제 주소 사이에 중개 서버를 둔다

• PURL 서버는 별도의 서버로 존재한다.
• PURL 서버는 PURL과 Target URL의 매핑 테이블을 관리한다.
• 실제 리소스는 기존 BE 서버에 그대로 존재한다.
• PURL 서버는 리소스를 직접 제공하지 않는다.

동작 방식

요청을 처리하지 않고, 위치만 안내한다

• 클라이언트는 PURL로 요청을 보낸다.
• PURL 서버는 매핑 테이블을 조회한다.
• 실제 리소스의 URL을 Location 헤더에 담아 리다이렉트 응답을 보낸다.
• 클라이언트는 리다이렉트를 따라 실제 서버로 다시 요청한다.
• 실제 데이터는 PURL 서버를 거치지 않고 직접 전달된다.

FE / BE 협업 관점

주소 변경에 대한 책임을 분리한다

• FE는 실제 BE API 엔드포인트를 알 필요가 없다.
• FE는 항상 동일한 PURL만 호출한다.
• BE는 PURL의 존재를 인식하지 않아도 된다.
• BE 엔드포인트가 변경되면 PURL 매핑만 수정하면 된다.
• FE 코드와 배포에는 영향을 주지 않는다.

API Gateway / 프록시와의 관계

구조는 유사하지만 목적이 다르다

• PURL은 라우팅 테이블을 가진 프록시와 구조적으로 유사하다.
• 그러나 요청을 중계하지 않고 리다이렉트만 수행한다.
• API Gateway가 트래픽·보안·정책을 처리하는 것과 달리, PURL의 목적은 오직 식별자 안정성이다.
• PURL은 API Gateway의 최소 기능 집합에 가깝다.

404에 대한 관점

위치 변경은 흡수하지만, 리소스 소멸은 막지 못한다

• BE API 엔드포인트가 변경되더라도, PURL 매핑이 갱신되어 있다면 FE에서는 404가 발생하지 않는다.
• PURL 매핑이 갱신되지 않으면 결국 404가 발생한다.
• 리소스가 실제로 삭제된 경우, PURL도 이를 막을 수 없다.
• PURL은 리소스의 이동만 흡수한다.

운영 관점의 한계

관리 지점이 하나 더 추가된다

• PURL 서버는 추가적인 관리 지점(SPOF)이 된다.
• 매핑 테이블, 리다이렉트 정책, 모니터링이 필요하다.
• 요청이 한 번 더 발생하므로 네트워크 홉이 증가한다.
• 운영 비용 대비 효과가 명확하지 않은 경우가 많다.

내 생각

이론적으로는 우아하지만, 실무에서는 비용 대비 효용이 제한적이다

• PURL은 관리해야 할 서버와 설정이 하나 더 늘어난다.
• BE 엔드포인트 변경 문제는 API Gateway, Reverse Proxy, DNS 전략으로도 충분히 해결 가능하다.
• 대부분의 서비스에서는 필수적인 구조라고 보기는 어렵다.
• 링크 안정성이 매우 중요한 도메인에서만 의미가 있다고 판단된다.