▲

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

 (xania.org)
1P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • Compiler Explorer는 초기에는 모든 상태를 URL에 직접 저장하는 방식을 사용했음
  • URL이 너무 길어져 Google의 goo.gl 단축 URL 서비스를 도입했고, 이 구조는 여러 번의 리디렉션을 거치는 복잡함을 유발했음
  • 2018년부터 URL 길이 제한 문제와 유지보수의 어려움으로 자체 S3와 DynamoDB 기반 저장소를 활용하는 구조로 전환함
  • 하지만 Google이 goo.gl 서비스를 2025년 8월에 종료함에 따라 과거 단축 링크의 지속성을 스스로 관리해야 하는 상황이 됨
  • 현시점까지 12,000개가 넘는 레거시 링크를 구출했고, 이는 프로그래밍 지식 보존과 지속 가능한 서비스 운영의 중요성을 보여줌

Compiler Explorer 링크의 영구 보장과 역사

초기 설계 방식과 goo.gl 도입 배경

  • 2012년, Compiler Explorer는 모든 컴파일러 상태를 URL에 직접 인코딩하는 구조를 도입함
  • 상태 정보가 많아질수록 URL이 지나치게 길어지는 문제 발생
  • URL 짧게 만들기 위해 2014년 Google의 goo.gl 단축 서비스를 적용함
    • goo.gl/abc123 형식의 단축 링크를 제공했고, 클릭 시 원래의 긴 URL로 리디렉션 후 상태 복원
  • Stack Overflow가 단축링크 사용 금지(2016년) 조치로 인해 기존 방식에 제약 발생
    • 악성 링크 감춤 위험 때문에 모든 goo.gl 기반 링크가 영향을 받음
  • 사용자 데이터 저장을 원치 않아 임시 방안으로 godbolt.org/g/abc123 형식의 자체 경로를 만듦
    • godbolt.org/g/abc123로 접근 시 goo.gl/abc123로 다시 리디렉션
    • 이 과정에서 최종적으로 godbolt.org 긴 URL로 복귀
    • 복수의 리디렉션 발생으로 구조가 복잡해지는 문제 발생
  • 이후 Google API 사용으로 리디렉션 절차 일부 단순화

자체 저장소 도입과 링크 관리

  • 2018년부터는 URL 길이 한계와 데이터 압축의 불편함이 자주 문제로 대두됨
  • S3 및 DynamoDB 활용한 자체 저장구조 구현
    • 입력값을 해시하여 JSON 문서 형태로 S3에 저장
    • 짧은 링크(godbolt.org/z/hashbit)로 접근 시 DynamoDB에서 매핑을 조회
    • 해시 값에 욕설 등 부적절한 단어 포함 시 랜덤 요소 추가로 우회하는 체크 기능 구현
    • 해시 기반 링크의 부적절성 문제 해결 및 관련 버그 경험(예: issue #1297)
  • 현재도 여전히 godbolt.org/g/abc123 주소 형식 지원
  • Google의 공식 안내에도 불구하고 goo.gl 서비스가 읽기 전용으로 전환되었고, 2025년 8월 완전 종료 예정
  • goo.gl 기반 단축 링크는 더 이상 해석 불가 예정
  • godbolt.org/g/abc123 형태는 직접 관리로 생명 연장 가능하므로 이들 링크 구조에 대해 구조화된 구제작업 진행

레거시 링크 대량 수집과 아카이빙 작업

  • 최근 모든 가능한 소스(검색, 데이터 덤프, 웹로그 등)에서 레거시 링크들을 크롤링 및 데이터베이스화 진행
    • Google 웹검색 API
    • GitHub API
    • 자체 서버 로그
    • archive.org의 Stack Overflow 데이터 덤프
    • Archive.org의 저장된 웹페이지 데이터
  • 약 12,298개의 단축 링크 복구 성공
  • 내부적으로 goo.gl 대신 자체 링크 데이터베이스 활용을 시작함 (관련 PR: #7724)
  • 앞으로도 발견되지 않은 godbolt.org/g/abc123 링크를 지속적으로 수집 및 확보 예정
  • 커뮤니티에 아직 미등록된 링크가 있다면 직접 접속하거나 관리자에게 알려 데이터베이스 보완 요청

프로젝트 철학과 인프라 소유의 중요성

  • 이번 사례를 통해 중요한 인프라를 외부 서비스(예: Google)의 지속성에만 의존하는 위험성 확인
  • 단축 링크 관리 및 백업 구조는 임시 방편이었고, 완전히 영구적 URL을 약속하려면 서비스 전체를 직접 관리할 필요가 있음
  • 디지털 고고학처럼 오래된 레거시 링크를 구조하는 과정에서 하나하나의 링크가 누군가의 지식 공유, 질문, 개념 설명의 흔적임을 인식
  • 이 저장 및 보존 행위는 프로그래밍 커뮤니티의 역사 아카이빙과도 직결
  • 옛날 Compiler Explorer 링크를 발견했다면 지금이라도 한 번씩 눌러 보는 것이 인터넷 지식 보존에 기여하는 길임
  • 이번에는 서드파티가 아닌, 직접 제어하는 인프라에 의존함으로써 지속 보장의 약속을 이행할 수 있게 됨

Disclaimer

  • 본 글은 사람이 작성하였으며, 링크 추천 및 문법 검사 과정에서 LLM을 활용함
▲
GN⁺ 6일전  [-]
Hacker News 의견
  • 2010년 이전에는 링크는 영원히 지속된다는 가정이 당연한 것처럼 느껴졌음, 그래서 브라우저의 북마크 기능을 적극적으로 사용했음, 하지만 시간이 지나면서 많은 북마크가 링크 부패(linkrot)로 인해 사실상 사용할 수 없게 되는 경험을 했음, 이후 웹페이지를 PDF로 저장하는 습관을 들였음, 리더 뷰(Reader view)가 대중화되고 나서는 리더 뷰에서 내용을 복사해서 RTF 파일로 저장하는 방식으로 바뀜
    • 내가 방문하는 모든 페이지를 아카이브하기 위해 SingleFile 확장 프로그램을 사용함, 설치 설정이 간단한 편이지만 상당한 저장공간을 차지한다는 점에 주의가 필요함, 예시로 웹페이지 아카이브 디렉토리가 1.1TB에 달함 SingleFile GitHub 링크
    • 공식 Web Archive 브라우저 확장 프로그램을 설치하면 방문하는 모든 페이지를 자동으로 아카이브하도록 설정할 수 있음
    • 내 방식은 중요한 정보나 최소한 어디에서 그것을 찾을 수 있는지 기억해두는 것임, 아직까지 살아 있으니 이 방법도 나름 효과적임
    • 혹시 링크가 타임아웃될 때 자동으로 web.archive.org로 이동해주는 브라우저 확장 프로그램이 있는지 궁금함
    • WARC 포맷을 WebRecorder와 함께 사용하는 방법이 있음 WARC 정보, WebRecorder
  • ArchiveTeam의 Goo.gl 프로젝트와 협력하는 것이 가치 있는 일일 수도 있음 프로젝트 상세 정보, URL 단축은 정말 최악의 아이디어였다는 생각임 URLTeam 설명
    • 해당 프로젝트의 실시간 현황에 따르면 425억 개의 goo.gl URL 중 75억 개가 발견된 상태임 실시간 상태 링크
    • ArchiveTeam은 아마도 '알려진' 링크가 아니라 Goo.gl 단축 URL을 브루트포싱하는 방식을 썼을 것 같음, Compiler Explorer의 URL 대부분 또는 전부가 그들의 데이터에 포함되어 있을 것으로 봄, 그래서 연락해보는 게 좋은 아이디어라는 생각임
  • URL이 영원히 지속된다는 건 이상적인 꿈이었음, 현실적으로는 실제로 99%의 URL이 영구적이지 않음, 실패할 싸움에 계속 맞서기보다는 인프라가 영구적이지 않다는 가정 하에 기술을 구축해나가는 게 맞지 않을지 생각해봄
    • 인프라가 영구적이지 않다는 가정 하에 기술을 만드는 게 맞는 방향임, 그리고 URL 단축 서비스를 인프라처럼 사용하는 것도 피해야 한다고 생각함
    • URN(Uniform Resource Name)은 위치와 무관하게 자원의 정체성을 부여하기 위해 고안된 시스템임, 하지만 대중화되지 못했고, 오히려 URL 단축 서비스들이 이 개념을 제대로 구현하지 못한 채 비슷하게 시도한 수준임 URN 위키피디아 설명
    • 도메인 네임은 자주 소유주가 바뀌고, 영구적일 것 같은 URL도 시간이 지나면 악성 피싱 링크로 변질될 수 있다는 점이 있음
    • URL은 네트워크 상에서 자원의 위치만 식별할 뿐, 자원 자체를 식별하는 건 아님, 그래서 영구적이거나 유일할 필요가 없음, 그래서 'Uniform Resource Locator’라는 명칭임, 이 문제를 인식해서 1997년에 Digital Object Identifier가 발명됨
  • 링크 단축 서비스를 데이터베이스처럼 남용하다가, 나중에 소중한 링크를 인터넷 구석구석에서 다시 찾아야 하는 상황이 뭔가 시적임을 느낌
    • URL 단축의 본래 목적은 긴 URL을 짧게 만드는 것임, 오히려 문제는 단축 URL을 통해 스팸·사기·불법 사이트를 숨기려고 도메인을 남용하는 사람들이라고 생각함
    • 그들도 단순히 URL을 압축하기 위해 단축 서비스를 사용한 것 같음, 원래 그들의 URL 자체가 컴파일러 상태를 ‘데이터베이스’처럼 보유하고 있었던 것임
  • https://killedbygoogle.com/, Google Go Links(2010~2021)는 약 11년 운영되다 4년 전에 종료된 Google의 URL 단축 서비스였음, Google Workspace 고객은 커스텀 도메인도 사용할 수 있었음
    • 새로운 단축 URL을 더 이상 만들 수 없게 서비스 종료(“minting new ones”)하는 건 별로 심각한 문제라고 보지 않음, 기존에 만들어진 URL까지 종료시키는 게 훨씬 부당하다고 생각함, 특히 Google은 내부적으로 일부 앱에서 여전히 이 기능을 계속 사용 중임
  • ‘이 글은 사람이 작성했지만, 링크 제안과 문법 검사는 LLM이 했다’는 문구가 두 번째로 눈에 띔, 뭔가 새로운 트렌드의 시작을 보는 듯한 느낌임
    • 사람들이 이런 식의 안내문구를 넣어야 한다고 느끼는 현실이 흥미로움
    • 나로선 그런 안내문구의 필요성을 전혀 못 느끼겠음, 콘텐츠 자체가 스스로를 증명한다면 그걸로 충분하다고 생각함, 만약 콘텐츠의 질이 떨어진다면 그게 AI 생성이든 사람이 만든 것이든 상관 없는 문제임, 안내문구를 원하는 사람들은 아마도 스스로 내용을 평가할 역량이 없어서 AI 생성 콘텐츠를 품질이 낮은 것으로 간주하는 일종의 대리 판단 도구처럼 여기는 듯함
  • Google이 굳이 읽기 전용 버전까지도 종료하려는 게 의외임, 비공개 링크 리디렉션을 남겨두는 것 때문에 혹시 법률적 위험을 우려하는 것일지도 의문임
    • 내부적으로 정확한 사정은 모르겠지만, 운영 중인 서비스가 구식이거나 보안에 취약한 라이브러리나 런타임에 의존하기 때문에 중단하고 싶을 수 있음, 사실 사소한 비용이더라도 결국 비용절감을 위해 서비스 종료를 선택하는 모습이고, 기업의 선의나 과거 약속 같은 건 신경 쓰지 않는 듯한 인상임
  • Google 직원에게 부탁해서 godbolt.org로 리디렉션되는 단축 URL만 데이터베이스에서 뽑아줄 수 있는 방법이 전혀 존재하지 않을지 궁금함
  • 솔직히 말해, 충분히 자금이 확보된 재단이 개입하지 않는 한 Compiler Explorer와 godbolt.org도 언젠가는 영원하지 않게 될 운명임, 언젠가 모든 정보가 엄청난 파라미터를 가진 거대 모델에 추상화되어 담기게 될지도 모름
    • 우리는 현재까지 잘 운영해왔음, 이번 주가 13주년이고, 모든 후원사가 지원을 중단하더라도 1년 남짓 더 운영할 자금이 쌓여 있음, 최근에는 재단 설립 같은 것도 고민하고 있음, 실제로 취약점은 자금 부족이 아니라 개인(나)이 단일 실패지점이라는 점임
    • 맞는 말임, 이제는 Compiler Explorer 링크가 중단되는 시점은 진짜 Compiler Explorer 자체가 사라질 때뿐임, 그 전까지는 링크가 살아있을 것임, 특히 버그 리포트에 남기는 Compiler Explorer 링크는 매우 가치 있다고 생각함, 나 역시 그러한 링크와 함께 코드를 직접 리포트에도 포함시키고, 어떤 컴파일러와 버전을 썼는지도 명시함, Compiler Explorer가 곧 사라질 거라 생각하진 않지만, 버그 리포트를 이렇게 자급적으로 만들어두면 예기치 않은 사라짐에도 대비할 수 있음
    • no-hiding 정리에 따르면 정보는 영원히 살아남는다는 농담이 생각남
  • 도메인 유지에도 비용이 들어가는데, URL이 어떻게 영원히 지속될 수 있을지 알 수 없다고 생각함, URL의 소멸 자체가 오히려 긍정적일 수도 있는지 궁금함, 인류는 가치 있는 정보만 특별히 보존하고, 나머지는 자연스럽게 역사 속으로 사라지는 방식임
    • 그러나 역사가들은 그런 ‘쓰레기’ 데이터라도 더 많이 원함, 그래야 당시 실제 삶과 맥락을 더 잘 이해할 수 있음, 타임머신을 탈 수 있다면, 천 년 후 역사가들이 디지털 미디어가 소멸하면서 대부분의 정보가 사라진 이 시기를 어떻게 바라볼지 궁금함
    • 나 역시 URL이 소멸되는 게 좋은 점이 있다는 의견에 동의함, 관련해서 쓴 글이 있음 인터넷의 휘발성에 대해
답변달기