URI vs URL

김키핑·2026년 2월 11일

URI

서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.
서버 리소스를 식별하기 위한 표준 문자열을 URI(리소스 식별자) 라고 한다.

예시 )

ㄴ HTTPS 프로토콜을 사용하여 typesomething.vercel.app으로 이동해 leaderboard라고 불리는 리소스를 가져와라.

라는 의미이다.

통합 자원 지시자는 리소스 식별자의 가장 흔한 형태다. URL은 특정서버의 한 리소스에 대한 구체적인 위치를 서술한다. 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 분명히 알려주는 것이다.

예시 )

ㄴ HTTPS 프로토콜을 사용하여 typesomething.vercel.app으로 이동해 leaderboard라고 불리는 리소스를 가져와라.

라는 의미이다.

URI와 URL의 예시가 같은 이유는,
URL이 URI의 하위 개념이기 때문이다.
즉, 모든 URL은 URI이다.

단, URI라고 해서 반드시 URL인 것은 아니다.
예를 들어, urn:isbn:0451450523과 같은 URN은
리소스의 위치(location)가 아니라 이름(name)만을 식별하므로
URI에는 해당하지만 URL은 아니다.

또한 google.com과 같이 스킴(scheme)이 명시되지 않은 문자열은
브라우저가 자동으로 https://를 보완하여 URL로 해석할 뿐,
완전한 URI 형식은 아니다.

오늘은 본인의 도메인에서 URI URL이 쓰이는 방식을 가져가야하는데,,,

모임의 흥미로움 측면에서 대우석, 대민성과 겹치지 않을만한 주제를 가져가는것이 좋을 듯 하다는 생각이 들어 깊은 고민을 해보았다.

그렇게 준비된 주제는, 멋진 백엔드 개발자라면 누구나 좋아하는 ^^ 데이터 병목현상에 관한 것.

※ 데이터 병목(Data Bottleneck) : 컴퓨터, 네트워크, 혹은 데이터 처리 시스템에서 데이터가 이동하거나 처리되는 속도가 시스템의 특정 부분에서 제한되어, 전체 시스템의 성능이 떨어지는 현상

잘못 설계된 DB와 URI는 특정 자원에 트래픽을 집중시키고,
그 결과 데이터 병목을 유발할 수 있다.

GET /api/products?search=노트북

모든 요청이 /api/products라는 단일 진입점으로 집중된다.
트래픽이 증가할 경우 특정 자원이나 테이블에 부하가 집중될 가능성이 있어
데이터 병목을 유발할 수 있는 것이다.

GET /api/brands/samsung/products
GET /api/categories/electronics/products

DB를 자원 단위로 재설계하고, 이를 URI에 반영해
자원 계층 구조를 명확히 드러내면
도메인 단위 서비스 분리, 캐시 전략 분리, 트래픽 분산 설계에 유리하다.

이는 특정 단일 엔드포인트로 요청이 집중되는 구조를 완화하고,
자원 단위의 확장 전략을 적용하기 쉽게 만든다.

즉, 이러한 설계는 시스템 확장성과 유지보수 측면에서
데이터 병목 가능성을 줄이는 데 기여할 수도 있다는 것이다.

양치기소녀