by
Apr 29. 2023
똑똑하게 데이터 10탄 : URL
브런치스토리 속 URL 빠르고 정확하게 구성하기
다시 보고 싶은 영상이 있거나, 잘 쓴 글을 발견했을 때 저는 해당 링크를 같이 공부하는 친구에게 보내줍니다. 그러다 보면 그 링크에 눈이 머물 때가 있습니다. 우선 너무 링크가 긴 경우 혹시 출처가 신뢰할만한 곳은 아니었는지 다시 살펴보게 됩니다. 직접 구글에서 그 제목만 다시 검색해서 더 간단한 링크를 찾기도 하고, 링크의 맨 끝이 "/3" 이렇게 끝난다면 3 대신 1 또는 2를 넣어서 이전 에디션을 찾아내기도 합니다.
브런치스토리에서 발견한
URL의 정의와 구조
편의상 '링크'라고 호칭하는 것은 사실 URL이라고 불립니다. 아무리 몇 번의 검색을 거쳐서 도달했어도 이제 URL만 알면, 특정 영상 파일이나 글이 게재된 HTML 페이지, 이미지로 바로 이동할 수 있게 되는 것입니다. 아래는 MDN Web Docs에서 제공하는 URL의 정의와 구조에 대한 설명입니다.
URL은 Uniform Resource Locator의 약자입니다.
URL은 웹에서 주어진 고유 리소스 주소에 지나지 않습니다. 이론적으로 각각의 유효한 URL은 고유한 리소스를 가리킵니다. 이러한 리소스는 HTML 페이지, CSS 문서, 이미지 등이 될 수 있습니다. 실제로는 몇 가지 예외가 있으며 가장 일반적인 예외는 더 이상 존재하지 않거나 이동된 리소스를 가리키는 URL입니다.
[1] 스키마(Scheme) : 브라우저가 리소스 요청하는 통신 방식
[2] 도메인(Domain Name) : 브라우저가 요청하는 웹 서버 이름
[3] 포트(Port) : 접속할 때 서버에서 열어주는 통로 개념
[4] 리소스 경로(Path) : 도달하고자 하는 리소스가 도메인의 홈에서 위치한 경로(단계)
[5] 매개변수(Parameters) : 특정 조건(key 항목 = value값)을 적용해서 도달하는 경우
[6] 앵커(Anchor) : 같은 리소스에서도 특정 위치(책갈피)를 명확히 지정하는 경우
자세한 설명을 이 글에서 다루기보다는, 실제로 브런치스토리에서 탐색하다 보면 만날 수 있는 URL 예시를 통해서 차이를 알아보겠습니다.
1. 브런치스토리팀 프로필
https://www.brunch.co.kr/@brunch#info
2. 브런치스토리팀 공지글
https://www.brunch.co.kr/@brunch/323
3. '글쓰기' 포함 프로필 검색
https://www.brunch.co.kr/search?q=글쓰기&k=출간작가&type=user
4. '글쓰기' 포함 글 검색
https://www.brunch.co.kr/search?q=글쓰기&type=article
우선 구글이나 사파리 같은 웹 브라우저로, '브런치스토리'에 로그인한 후이므로 [1] 스키마, [2] 도메인, [3] 포트까지는 동일하겠습니다.
[1] 스키마 https : 보안이 적용된 버전의 프로토콜입니다. 자물쇠를 띄우고 생략하기도 합니다.
[2] 도메인 www.brunch.co.kr : 예전 브런치 시절 등록한 도메인입니다.
[3] 포트 생략됨 : https 통신방식의 경우, 일반적인 443 포트이면 생략합니다.
그 말인즉슨 나머지 [4] ~ [6]은 결국 사용자가 우리 서비스를 왜 사용하고, 어떻게 사용할 것인가에 따라 필요한 페이지, 이미지, 영상 등 리소스를 위치하고 정의시킨 뒤에 결정된다는 것입니다.
URL에 대한 고민은 결국 사용자 경험에 대한 고민
어떤 경로를 거쳐서, 어떤 조건을 걸어서, 어떤 지점에 떨어뜨려줄 것인가?
첫째, 빨리 도달할 수 있게
경로를 단순하게 하다
브런치스토리의 주요 공지사항 등은 별도 게시판보다는 주로 '브런치스토리팀' 공식 계정으로 올리고 있습니다. 그 URL은 다음과 같습니다.
https://www.brunch.co.kr/@brunch#info
https://www.brunch.co.kr/@brunch#articles
https://www.brunch.co.kr/@brunch#works
[4] 리소스 경로 @brunch : 브런치스토리 홈에서 각 작가의 홈 (여기서는 브런치스토리팀)으로 이동
[6] 앵커 info(작가소개 탭), articles(글 탭), works(작품 탭) 페이지 이동 없이 (책갈피된) 그 탭 도달
그런데 브런치스토리팀의 '글 탭'에서 최근에 보았던 공지 글을 확인하였습니다. "브런치가 '브런치스토리'로 새롭게 출발합니다"라는 3월 말 이름 변경에 대한 글이었는데요.
브런치스토리 홈에서, 브런치스토리팀이라는 작가 홈으로 이동하기 위해 경로를 한 단계 추가했듯이,
브런치스토리팀 작가 홈에서, 글 탭이 있고, 그 아래에 이 공지 글로 가는 경로가 몇 단계 추가될 줄 알았습니
다. brunch.co.kr/@brunch/#articles/{공지글번호} 처럼요. 그런데 실제로는 아래와 같았습니다.
https://www.brunch.co.kr/@brunch/323
물론 # 뒤에 위치하는 앵커는 작가 홈을 구성하는 리소스 중 하나를 지정할 뿐, 별도의 리소스 경로 규칙을 따르지 않아 어차피 #articles 아래에 경로를 만들 수는 없었을 것입니다. 하지만 근본적으로 브런치스토리가 브런치 글 중심으로 서비스를 운영한다는 관점에서, 작가 홈의 경로 바로 아래에 글 번호를 놓는 의사결정이 타당하다고 생각했습니다. '브런치스토리의 브런치스토리팀 작가의 323번째 글이다'.
둘째, 원하는 검색을 정확하게
매개변수를 나열하다
브런치스토리에는 기획, 인공지능, 데이터분석, 글쓰기 등등 분야별로 잘 다듬어진 실무자의 인사이트가 많아서 자주 탐색해보고는 합니다. 주로 폰에서 브런치스토리 앱에서만 탐색하다가, 오랜만에 PC 버전으로 검색을 해보았는데요.
검색창에 진입했을 때, '글쓰기' 쪽 작가 프로필을 3개 정도 띄워주길래 클릭했더니, 첫 번째 사진처럼 '글쓰기'라는 텍스트 검색어와 '작가 검색결과'가 214건 나왔습니다. 그러나 저는 '글쓰기'에 관한 글 자체를 찾고 싶어서, 두 번째 사진처럼 '글 탭'을 클릭하여 다시 검색했습니다. 그랬더니 '글 검색결과'가 198건 나왔습니다.
https://www.brunch.co.kr/search?q=글쓰기&k=출간작가&type=user
https://www.brunch.co.kr/search?q=글쓰기&type=article
[4] 리소스 경로 search 검색창
[5] 매개변수 화면을 제어하는 검색어, 필터 등 (q=글쓰기, k=출간작가, type=user(작가))
'글쓰기'라는 검색어(q, query)로 결과를 조회하는데, 그 세부 조건(type)으로서 '글'에서 찾을 것인지 '작가 홈(프로필)'에서 찾을 것인지 검색 결과를 한정하는 것입니다. 첫 번째 사진처럼 '작가'에서 찾은 경우, 작가명, 작가의 소개, 그리고 작가가 직접 선택한 키워드 중에 '글쓰기'가 포함된 경우가 조회결과에 나옵니다. 두 번째 사진처럼 '글'에서 찾은 경우, 글의 제목과 내용 중에 '글쓰기'가 포함된 경우가 조회됩니다.
작가가 author나 writer가 아니라 user이라서 잠시 혼동은 있었지만, 검색 결과를 바꾸는 세부 조건을 명확하게 매개변수로 지정해 준 덕분에 인지가 가능했습니다.
가볍고 정확한 URL을 만들기 위한
통제 가능한 URL 3가지 요소 점검하기
좋은 URL은 꼭 필요한 매개변수만 사용해서 정확한 그 리소스 위치로 사용자를 이동시키는 것입니다. 세세하게 모든 경우를 고려하면 정확도는 높아지겠지만, 이는 해당 화면을 불러오는 데 컴퓨터 자원을 낭비하게 되고, 오히려 불안정해질 수 있습니다. 실제로 구글 검색센터에서 제시하는 표준 URL에 대한 가이드라인 중에, 중복 URL에 대한 경고를 제기합니다. 서로 다른 URL이 하나의 리소스를 가리킬 경우, 그 리소스의 위치나 내용이 변경되었을 때 정합성이 보장될 수 없으며, 사용자 행동 로그 분석할 때도 문제가 있기 때문입니다.
구글 검색 센터 / URL 구조 / 중복 URL 문제가 발생하는 원인 예시 1. 비슷한 검색 조건의 여러 가지 조합 모음
2. 생성일자(timestamp) 및 광고 등 변하는 값 (form처럼 동적으로 생성되는 문서의 경우)
3. 사용자가 접속하는 세션 ID
4. 여러 가지 정렬 필터
결국 해당 리소스(상품, 이미지, 영상 등)를 사용자가 왜 필요한지, 우리 서비스에서 어떻게 원하는 것을 찾아야 할 지에 대한 명확한 목적이 자리 잡아야 합니다. 그러고 나서 어떤 메뉴에서 어떤 조건으로 진입할 것인지를 그려봤을 때 '꼭 필요한' 경로가 무엇인지, '꼭 필요한' 조건이 무엇인지 지정이 가능하고 그것이 URL로 구현될 수 있습니다.
통제 가능한 URL 3가지 구성 요소
1. 리소스 경로(Path) : 도달하고자 하는 리소스가 도메인의 홈에서 위치한 경로(단계)
2. 매개변수(Parameters) : 특정 조건(key 항목 = value값)을 적용해서 도달하는 경우
3. 앵커(Anchor) : 같은 리소스에서도 특정 위치(책갈피)를 명확히 지정하는 경우
사진: Unsplash의 ali syaaban