블로그나 문서에 GitHub 코드를 넣을 때 흔히 두 가지 선택지가 있습니다. 링크만 걸면 독자가 GitHub로 이동해야 하고, 코드를 직접 복사하면 원본과 어긋나기 쉽습니다.
github-code는 이 사이의 불편을 줄이려는 실험적 Web Component입니다. GitHub 코드 조각을 HTML 태그처럼 삽입하면, 컴포넌트가 GitHub blob URL을 raw.githubusercontent.com 형식으로 바꾸고 fetch()로 코드를 가져와 지정한 줄 범위를 줄 번호와 함께 표시합니다.1
<github-code href="https://github.com/simonw/sqlite-ast/blob/437c759129154f05296324a7f82aa1246340dd14/sqlite_ast/parser.py#L9-L18"></github-code>왜 Web Component인가
Web Component는 브라우저 네이티브 API로 사용자 정의 HTML 요소를 만드는 방식입니다. 특정 프레임워크 없이도 <my-widget> 같은 태그를 정의하고, 필요한 동작과 렌더링을 그 요소 안에 묶을 수 있습니다.
코드 임베드 기능은 이 방식과 잘 맞습니다. 페이지 전체를 애플리케이션으로 만들 필요 없이, “GitHub URL을 받아 코드 조각을 보여주는 작은 태그”만 있으면 되기 때문입니다. GitHub도 Web Components를 프런트엔드 캡슐화와 재사용을 위한 기술로 활용해 왔고, 특정 프레임워크에 대한 선결 투자가 적다는 장점을 언급한 바 있습니다.2
핵심은 작은 기능의 캡슐화
github-code가 하는 일은 거창하지 않습니다. 하지만 GitHub URL 해석, raw URL 변환, 코드 가져오기, 줄 범위 처리, 줄 번호 렌더링을 하나의 요소 안에 모은다는 점이 중요합니다.
이 구조는 Web Components의 실용적인 장점을 보여줍니다. 예제 수준의 Web Components 프로젝트도 Shadow DOM, Template API, 브라우저 ES 모듈을 함께 사용해 프레임워크나 번들러 없이 프런트엔드를 구성할 수 있음을 보여줍니다.3 즉, 작고 독립적인 UI 기능이라면 대형 프레임워크를 도입하지 않고도 충분히 구현할 수 있습니다.
적용 전에 볼 기준
github-code를 그대로 쓸지보다 더 중요한 질문은 “이 문제에 Web Component가 맞는가”입니다. 다음 조건에 가까울수록 적합합니다.
기능이 작고 독립적이다.
여러 사이트나 프레임워크 환경에서 재사용해야 한다.
빌드 단계 없이 브라우저 표준만으로 동작하면 충분하다.
특정 데이터 입력을 받아 제한된 UI를 렌더링하는 위젯 형태다.
반대로 복잡한 상태 관리, 라우팅, 앱 전체의 일관된 데이터 흐름이 필요하다면 별도의 프레임워크가 더 자연스러울 수 있습니다. github-code의 가치는 “모든 것을 Web Component로 만들자”가 아니라, 작고 반복되는 UI 문제를 표준 HTML 요소처럼 다룰 수 있다는 점에 있습니다.
github-code가 GPT-5.5로 만들어졌다는 점도 흥미롭습니다.1 다만 핵심은 AI 자체보다 문제의 크기와 경계입니다. 입력은 GitHub URL, 출력은 줄 번호가 있는 코드 조각입니다. 이렇게 범위가 명확한 문제는 브라우저 표준 API와 결합했을 때 빠르게 실용적인 도구가 될 수 있습니다.
결국 github-code는 코드 임베드 도구인 동시에 Web Components의 적절한 사용 사례입니다. 페이지 전체를 바꾸지 않고도 작은 기능을 태그 하나로 추가하고 싶을 때, Web Component는 여전히 현실적인 선택지입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.