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

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

인프라/DevOps/보안

대상자

• *소프트웨어 개발자, 인프라 관리자, DevOps 엔지니어**
• 난이도: 중간

- URL 단축 서비스의 안정성 문제와 영구성 고려에 대한 이해가 필요

- S3, DynamoDB, 해시 기반 저장 시스템에 대한 기술적 지식이 유리

핵심 요약

• URL 단축 서비스(goo.gl) 종료로 인해 Compiler Explorer는 자체 저장소(S3 + DynamoDB)로 전환
• godbolt.org/g/abc123 형식의 해시 기반 링크를 사용하여 데이터를 저장 및 복구
• 12,298개의 레거시 링크 복구 성공
• URL의 영구성 보장을 위해 자체 인프라를 운영해야 함
• URL 단축 서비스는 임시 방편이었으며, 완전한 영구성 보장을 위해서는 직접 제어하는 인프라 구축이 필수

섹션별 세부 요약

1. 초기 URL 저장 방식

• Compiler Explorer는 초기에 모든 컴파일러 상태를 URL에 직접 인코딩
• 상태 정보가 많아질수록 URL이 지나치게 길어지는 문제 발생
• 2014년 Google의 goo.gl 단축 서비스 도입
• goo.gl/abc123 형식의 단축 링크 사용
• 클릭 시 원래의 긴 URL로 리디렉션 후 상태 복원

2. goo.gl 단축 서비스의 문제점

• Stack Overflow가 단축링크 사용 금지 조치로 인해 기존 방식에 제약 발생
• 악성 링크 감춤 위험으로 인해 모든 goo.gl 기반 링크가 영향을 받음
• 2018년부터 URL 길이 한계와 데이터 압축의 불편함이 자주 문제로 대두
• goo.gl 서비스 종료 예정(2025년 8월)
• 기존 링크가 해석 불가 예정
• godbolt.org/g/abc123 형식은 직접 관리로 생명 연장 가능

3. 자체 저장소 구축 및 레거시 링크 복구

• S3 및 DynamoDB 활용한 자체 저장구조 구현
• 입력값을 해시 하여 JSON 문서 형태로 S3에 저장
• 짧은 링크(godbolt.org/z/hashbit)로 접근 시 DynamoDB에서 매핑 조회
• 해시 값에 부적절한 단어 포함 시 랜덤 요소 추가로 우회하는 체크 기능 구현
• 관련 버그 경험(예: issue #1297)
• 모든 가능한 소스(검색, 데이터 덤프, 웹로그 등)에서 레거시 링크 크롤링 및 데이터베이스화
• Google 웹검색 API, GitHub API, archive.org 데이터 등 활용
• 12,298개의 단축 링크 복구 성공

4. URL 영구성에 대한 인식과 대응

• 중요한 인프라를 외부 서비스의 지속성에만 의존하는 위험성 확인
• URL 단축 서비스는 임시 방편이었고, 완전한 영구성 보장을 위해서는 직접 제어하는 인프라 구축이 필수
• URL 단축 서비스를 데이터베이스처럼 남용하는 것은 위험
• 스팸·사기·불법 사이트 숨기기에 악용 가능성
• URN(Uniform Resource Name)은 자원의 정체성을 부여하기 위해 고안되었으나 대중화되지 못함
• URL 단축 서비스들이 이 개념을 제대로 구현하지 못한 채 비슷하게 시도한 수준임

결론

• Compiler Explorer는 goo.gl 서비스 종료에 대응해 자체 S3 + DynamoDB 기반 저장소를 구축하여 URL의 영구성을 보장
• 레거시 링크 복구 작업을 통해 12,298개의 링크를 구출, 프로그래밍 지식 보존과 지속 가능한 서비스 운영의 중요성 강조
• URL 단축 서비스는 임시 방편이었으며, 완전한 영구성 보장을 위해서는 직접 제어하는 인프라 구축이 필수
• URL 단축 서비스 사용은 위험하며, 인프라 영구성에 대한 가정 하에 기술을 구축하는 것이 올바른 방향