Compiler Explorer와 “영원히 지속되는 URL”의 약속

 (xania.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Compiler Explorer는 공유 링크가 오래 살아남도록 2012년부터 저장 방식을 바꿔왔지만, goo.gl 종료로 과거 godbolt.org/g/abc123 링크 보존이 급해짐
  • 처음에는 전체 컴파일러 상태를 URL에 담았고, 2014년에는 Google URL 단축 서비스를 붙였으며, 2016년 Stack Overflow의 단축 URL 금지 이후 godbolt.org/g/abc123 우회 링크를 만들었음
  • URL 길이 한계가 커진 2018년부터는 상태를 S3의 JSON 문서로 저장하고, DynamoDB로 짧은 해시와 전체 경로 매핑을 관리하는 자체 방식으로 전환함
  • Google이 goo.gl 링크를 2025년 8월 종료하면 기존 goo.gl 기반 링크 해석이 어려워져, 공개 웹과 로그에서 찾은 약 12,000개 g 링크와 리디렉션 대상을 자체 데이터베이스로 모으고 있음
  • 오래된 Compiler Explorer 링크를 가진 사용자가 지금 링크를 방문하면 보존 목록에 들어갈 가능성이 있으며, 오래 유지돼야 하는 공유 지식은 핵심 인프라를 직접 소유할 때 더 안전함

Compiler Explorer 링크 저장 방식의 변화

  • 2012년에는 Compiler Explorer의 전체 상태를 URL 안에 저장했음
  • 전체 컴파일러 상태를 URL에 인코딩하는 방식은 길이가 길어져 다루기 어려웠고, 2014년 3월 Google의 goo.gl 단축 URL 지원이 추가됨
  • 당시 짧은 링크는 goo.gl/abc123 형태였고, 클릭하면 Compiler Explorer 사이트의 전체 URL로 리디렉션된 뒤 URL 안의 상태를 디코딩했음

Stack Overflow 금지 이후의 우회 링크

  • 2016년 Stack Overflow는 실제 목적지를 숨길 수 있다는 이유로 링크 단축 서비스를 금지함
  • 이 조치로 Compiler Explorer 링크도 영향을 받았고, 당시에는 사용자 데이터를 직접 저장할 의도가 없었음
  • 우회책은 goo.gl을 계속 쓰되 사용자에게는 godbolt.org/g/abc123 형태의 링크를 제공하는 방식이었음
    • abc123은 goo.gl의 고유 ID였음
    • /g/abc123 접근은 goo.gl/abc123으로 리디렉션됨
    • goo.gl은 다시 상태가 담긴 godbolt.org 전체 URL로 리디렉션했음
  • 이후에는 Google API를 사용해 여러 단계의 리디렉션 체인을 피했음

2018년 자체 저장소 전환

  • 2018년에는 URL 길이 제한이 더 큰 문제가 되었고, 이미 URL 안의 데이터를 압축하고 있었음
  • Compiler Explorer는 상태를 직접 저장하는 구조로 바꿈
    • 입력을 해시함
    • 상태를 JSON 문서로 S3에 저장함
    • 해시의 짧은 형태를 godbolt.org/z/hashbit URL로 제공함
    • DynamoDB로 짧은 해시와 전체 경로의 매핑을 저장함
  • 짧은 링크 해시에 불쾌한 단어가 들어가는지도 검사함
    • 불쾌한 단어가 나오면 문서에 의도적으로 추가 정보를 넣어 다른 해시가 나오게 함
    • 이 동작은 bug #1297로 이어졌음

goo.gl 종료가 만든 보존 문제

  • Compiler Explorer는 아직 godbolt.org/g/abc123 링크를 지원함
  • Google은 기존 링크가 의도한 목적지로 계속 리디렉션된다고 했지만, goo.gl은 몇 년 전 읽기 전용이 되었고 2025년 8월 최종 종료될 예정임
  • 종료 이후에는 goo.gl 기반 링크를 더 이상 해석할 수 없음
  • 실제 goo.gl 링크 자체는 Compiler Explorer 쪽에서 해결할 수 없지만, godbolt.org/g/abc123 링크는 자체 데이터베이스로 보존할 수 있음

기존 링크 수집과 자체 데이터베이스

  • 지난 며칠 동안 공개된 여러 출처에서 기존 링크와 그 리디렉션 대상 URL을 모으고 있음
  • 현재까지 약 12,000개 링크를 찾음
    • Google 웹 검색 API
    • GitHub API
    • 자체 웹 로그
    • archive.org의 Stack Overflow 데이터 덤프
    • Archive.org가 보관한 웹페이지 목록
  • 내부적으로는 goo.gl보다 자체 데이터베이스를 우선 사용하도록 변경했음
  • 아직 데이터베이스에 없는 새로운 g 링크도 감시하고 있음
  • 로컬에는 sqlite 데이터베이스가 있고, 프로덕션 쪽은 Dynamo를 사용함

사용자가 도울 수 있는 일

  • 오래된 godbolt.org/g/abc123 링크를 따로 보관하고 있다면 지금 각 링크를 방문하는 것이 도움이 됨
  • 링크를 방문하면 웹 로그에 남고, 이후 데이터베이스에 추가될 수 있음
  • 그렇지 않으면 2025년 8월 이후 해당 링크는 동작하지 않을 수 있음
  • 이 사례는 중요한 인프라를 서드파티 서비스에 의존하는 위험을 보여줌
  • “영원히 지속되는 URL”이라는 약속을 지키려면 전체 스택을 직접 소유해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 2010년 전에는 링크가 영원히 유지되는 것이라고 당연하게 믿었고, 브라우저 북마크를 많이 썼음
    나중에 북마크 상당수가 링크 부패로 사실상 쓸 수 없게 된 걸 발견했고, 그 뒤로는 웹페이지를 PDF로 인쇄해 저장했음
    리더 보기 기능이 꽤 안정적으로 보급된 뒤에는 리더 보기 내용을 복사해 RTF 파일로 저장하는 방식으로 바뀜

    • 방문하는 모든 페이지를 보관하려고 SingleFile 확장을 씀
      설정은 쉽지만 디스크 공간을 많이 먹는다는 점은 주의해야 함

      $ du -h ~/archive/webpages
      1.1T /home/andrew/archive/webpages

      https://github.com/gildas-lormeau/SingleFile

    • 공식 Web Archive 브라우저 확장을 설치하면 방문하는 모든 페이지를 자동으로 보관하도록 설정할 수 있음

    • 내 해결책은 중요한 내용 자체를 기억하거나, 적어도 어디서 찾을 수 있는지 기억하는 쪽이었음
      아직 죽지 않았으니 작동하는 셈임

    • 링크가 시간 초과되면 자동으로 web.archive.org로 가는 브라우저 확장이 있는지 궁금함

    • 브라우저들이 아직도 이 깨달음을 반영해 북마크 기능을 고치지 않은 건 정말 말이 안 됨
      모든 북마크는 링크뿐 아니라 렌더링된 페이지 전체 사본도 저장해야 함. 더 이상 존재하지 않을 동적 콘텐츠에 의존할 수 있는 원본 소스만 저장해서는 안 됨

      열린 탭도 같은 방식이어야 함. 인터넷 연결이 없는 상태에서 탭으로 돌아갔을 때, 브라우저가 친절하게 그 탭을 메모리에서 쫓아냈다는 이유로 네트워크 오류를 보고 싶지 않음
      이 경우에는 내가 수동으로 새로고침하기 전까지 네트워크가 아니라 디스크에서 상태를 다시 불러와야 함

  • Goo.gl에 대해서는 ArchiveTeam 프로젝트[1]와 협력해볼 만함
    “URL 단축은 정말 끔찍한 아이디어였다”[2]

    [1] https://wiki.archiveteam.org/index.php/Goo.gl

    [2] https://wiki.archiveteam.org/index.php/URLTeam

    • 기억이 맞다면 ArchiveTeam은 ‘알려진’ 링크를 따라간 게 아니라 Goo.gl 짧은 URL을 무차별 대입하고 있었음
      그래서 Compiler Explorer URL도 상당수 또는 전부 갖고 있을 가능성이 크고, 연락해보는 게 좋아 보임
    • 해당 프로젝트의 실시간 상태를 보면 420억 개 goo.gl URL을 스캔해 75억 개를 찾은 상태임: https://tracker.archiveteam.org:1338/status

  • URL이 영원히 지속된다는 건 아름다운 꿈이었지만, 현실에서는 URL의 99%가 영원하지 않아 보임
    계속 지는 싸움을 하기보다, 인프라가 영구적이지 않다는 전제 위에 기술을 만들어야 할지도 모름

    • 맞음. 그리고 URL 단축 서비스를 인프라로 쓰지 않는 것도 필요함

    • URN은 사물의 정체성과 위치를 분리해서 이 문제를 해결하려던 것이었음
      하지만 널리 쓰이지 못했고, 이후 링크 단축 서비스가 그 아이디어를 형편없이 다시 구현했음

      https://en.m.wikipedia.org/wiki/Uniform_Resource_Name

    • 도메인 이름은 자주 주인이 바뀌고, 영원해야 할 URL도 시간이 지나면 악성 피싱 링크로 변할 수 있음

    • URL은 네트워크상 리소스의 위치를 식별하지, 리소스 자체를 식별하지 않으므로 영구적이거나 유일할 필요가 없음
      그래서 이름도 “uniform resource locator”임

      이 문제는 1997년에 이미 인식됐고, 그래서 Digital Object Identifier가 만들어졌음

  • 링크 단축 서비스를 데이터베이스처럼 남용해놓고, 나중에 원래 참조를 잃어버려 인터넷 곳곳에서 소중한 링크를 회수해야 한다는 건 뭔가 시적임

    • 긴 URL을 줄이는 건 URL 단축 서비스의 의도된 사용 사례임
      진짜 남용하는 쪽은 단축 서비스를 이용해 사기, 스팸, 불법 웹사이트를 공통 도메인 뒤에 숨기고 여기저기 뿌리는 사람들임
    • 그냥 URL을 압축하려고 링크 단축 서비스를 쓴 것 아닌가
      데이터베이스로 쓴 건 단축 URL이 아니라 자기들의 URL, 즉 컴파일러 상태를 담고 있던 부분으로 보임

  • https://killedbygoogle.com/

    “Google Go Links (2010–2021)”

    “약 4년 전에 종료됨. Google Short Links라고도 알려졌고, URL 단축 서비스였음. Google Workspace 고객을 위한 맞춤 도메인도 지원했음. 약 11년 된 서비스였음”

    • 새 링크 생성을 중단한다는 의미에서 서비스를 “죽이는” 건 별일도 아니고 굳이 언급할 가치도 거의 없음
      하지만 기존 링크까지 끊는 것은 훨씬 더 나쁜 행동임. 특히 Google이 자기 앱 내부용으로는 여전히 어떤 형태로든 유지하고 있다면 더 그렇다

  • Google이 읽기 전용 버전까지 종료할 만큼 그게 수고를 들일 가치가 있다는 점이 다소 놀라움
    온라인에 남아 있는 비공개 링크 리디렉션 때문에 법적 위험을 우려하는 게 아니라면 말임

    • 밖에서 알기는 어렵지만, 그 서비스가 더 이상 운영하고 싶지 않은 낡았거나 안전하지 않은 라이브러리, 런타임, 서비스 등에 의존할 가능성은 있음
      솔직히 말하면 비용이 사소하더라도 여전히 순비용이니, 호감도나 과거 약속은 제쳐두고 그냥 자르는 것일 가능성도 비슷하게 있어 보임

  • “이 글은 사람이 썼지만, 링크 제안과 문법 검사는 LLM이 했습니다”

    오늘 이런 LLM 사용 고지를 본 게 두 번째임. 새로운 유행이 시작되는 걸 보는 듯함

    • 사람들이 이런 고지를 넣어야 한다고 느낀다는 게 이상함

    • 그런 고지가 전혀 필요하다고 보지 않음
      내용이 스스로 설 수 있으면 충분함. 내용이 쓰레기라면, 그게 AI가 만든 쓰레기인지 사람이 만든 쓰레기인지가 왜 중요함?

      누군가 고지를 원하거나 알고 싶어 하는 유일한 이유는, 스스로 내용의 품질을 판별하지 못하고 AI 생성 여부를 낮은 품질의 대리 지표로 쓰기 때문임

  • 말하기 싫지만, 아주 자금이 탄탄한 재단이 관여하지 않는 한 Compiler Explorer와 godbolt.org도 영원하지는 않을 것임
    그때쯤에는 모든 정보가 487경 개 매개변수를 가진 만물 모델 안에 증류돼 있을지도 모름

    • 지금까지는 꽤 잘해왔음. 이번 주로 13년째임
      성장세가 이어지고 현재 후원사가 전부 빠진다고 가정해도 1년 조금 넘게 버틸 자금은 있음

      다만 재단 같은 건 생각하고 있음. 단일 장애 지점은 자금이 아니라 “나”임

    • 맞는 말이지만, 적어도 이제 Compiler Explorer 링크는 Compiler Explorer가 사라질 때 끊기지, 그 전에는 끊기지 않음
      오래 살아남을 가치가 큰 Compiler Explorer 링크는 버그 리포트에 있는 것들이라고 봄
      편의상 버그 리포트에 Compiler Explorer를 링크하긴 하지만, 리포트 자체에도 코드를 넣고 버그를 재현할 때 쓴 컴파일러와 버전도 명시함
      Compiler Explorer가 곧 사라질 거라 기대하진 않지만, 이렇게 버그 리포트를 자기완결적으로 만들면 그 경우에도 보호됨

    • 무은닉 정리 덕분에 정보는 영원히 남을 것임 ;)

  • Google 내부의 누군가에게 데이터베이스를 조회해서 godbolt.org로 향하는 단축 링크를 모두 찾아달라고 할 방법은 아마 없을 듯함

  • 도메인 이름을 유지하는 데 돈이 드는데, URL이 어떻게 영원히 지속될 수 있는지 모르겠음
    URL의 죽음이 좋은 일일 수도 있는지 궁금함. 인류는 좋은 것을 남기려고 특별히 노력하고, 나머지는 역사의 가비지 컬렉션으로 들어감

    • 역사학자들은 오히려 역사 속 쓰레기가 더 많기를 바랄 것임
      보존할 가치가 있다고 여긴 부분뿐 아니라 “진짜” 삶에 대한 더 많은 통찰을 얻을 수 있기 때문임

      시간 이동을 할 수 있다면, 디지털 매체가 썩으면서 많은 정보가 흔적 없이 사라질 우리 시대를 천 년 뒤 역사학자들이 어떻게 돌아볼지 보는 게 흥미로울 듯함

    • 동의함. 예전에 여기에 관련 생각을 적었음: https://boehs.org/node/internet-evanescence

답변달기