https://Hybridego.net/ <Ho Cheol Jeon>

이 스킬의 역할

Hallmark는 Claude Code, Codex CLI, Cursor, OpenCode를 위한 디자인 스킬입니다. Together AI가 개발했습니다. 여기서 스킬이란 에이전트가 웹페이지 코드를 작성하기 전에 읽는 지침과 스크립트 모음 폴더를 가리킵니다. Hallmark가 하는 일은 한 가지입니다. 시각적 재료를 고르고, 방문자가 수행하려는 핵심 행동을 중심으로 페이지를 구성하며, 에이전트가 작성한 페이지에서 흔히 나타나는 패턴을 검사합니다.

공식 사이트 주소는 usehallmark.com입니다. 저장소에는 50개 테마가 정리되어 있습니다. 50이라는 숫자는 카탈로그 크기일 뿐, 한 번의 빌드로 나오는 페이지 수가 아닙니다. 테마는 와이어프레임이 아닙니다. 어떤 섹션을 넣어야 하는지 지정하지 않으며, 섹션 순서를 강제하지도 않습니다. 용지 질감, 서체, 색상, 표면, 컴포넌트, 텍스처를 정의하고, 완성된 페이지 예시 이미지 1장을 함께 제공할 뿐입니다. 빌드 과정에서는 정확히 하나의 테마 파일만 읽습니다. 같은 테마를 쓰더라도 프롬프트가 다르면 서로 다른 두 페이지가 만들어집니다.

README의 v2 안내에는 카탈로그 외에 네 가지 동작 방식이 추가되었습니다. 첫째, 페이지는 본래 목적(job)에 맞게 만듭니다. 예약 페이지는 예약을 받고, 쇼핑몰은 상품을 판매하며, 뉴스레터 페이지는 구독을 유도해야 합니다. 해당 유형의 페이지에서 흔히 두는 자리에 핵심 액션 버튼을 배치하고, 페이지 끝도 그 액션으로 마무리합니다. 둘째, 커스텀 페이지를 요청하면 테마 카탈로그를 배제하고 프롬프트만으로 디자인하되, 기존 규칙과 검사는 동일하게 적용합니다. 셋째, URL이나 개발 서버, 앱 경로를 넘겨주면 스크린샷을 직접 캡처합니다. 넷째, 리디자인(Redesign)과 감사(Audit)는 별도 명령어로 구분됩니다. 리디자인은 기존 콘텐츠와 동작 연결(wiring)을 유지한 채 페이지를 다시 구성하고, 감사는 분석 보고서만 출력합니다.

검사 단계에서는 사전에 정의된 패턴을 찾아냅니다. README에 명시된 패턴은 다음과 같습니다. 모든 제목 위에 달리는 아이브로우 라벨(eyebrow label), 자간을 넓힌 대문자 라벨, 헤드라인 속 단어 하나에만 색을 넣는 기교, 빈 프레임으로만 채운 페이지, 사진만 나열한 페이지, 화면을 채우지 못하는 히어로 섹션, 모든 페이지 끝에 기계적으로 붙는 이메일 구독 폼, 실제로 전송하지도 않으면서 감사 메시지를 보여주는 폼 등입니다. 빌드가 끝나면 빌드 당시의 대화 기록이 없는 독립된 컨텍스트에서 리뷰어 에이전트가 최종 검토를 수행합니다.

별도의 디자인 스킬이 필요한 이유

에이전트 기반 페이지 빌더는 몇 가지 레이아웃 습관을 반복하는 경향이 있습니다. 이 습관들이 문법상 깨진 HTML을 뜻하지는 않습니다. 매번 같은 라벨 스타일, 뻔한 헤드라인 연출, 기계적인 마무리 폼, 텅 빈 카드 레이아웃처럼 판에 박힌 선택을 되풀이하는 것이 문제입니다. Hallmark는 이러한 선택들에 이름을 붙이고 검사 과정을 3단계 티어로 나누었습니다. "디자인 감각 있게 만들어 달라"는 식의 모호한 요구 대신, 에이전트가 따를 수 있는 명문화된 규칙을 제시한 셈입니다.

세 티어는 각자 다른 역할을 합니다. '플로어(Floor)' 티어는 배포를 절대 허용하지 않는 필수 기준입니다. README에서는 대비(contrast), 키보드 포커스, 모션 줄이기(reduced motion), 사실 왜곡(invented facts), 깨진 모바일 화면 레이아웃 등을 이 티어에 배치했습니다. 이 중 하나라도 통과하지 못하면 빌드가 실패합니다. '리플렉스(Reflex)' 티어는 모델이 무의식적으로 빠지기 쉬운 기본 습관을 다룹니다. 합당한 사유를 기록으로 남길 때만 리플렉스 검사를 예외로 통과할 수 있습니다. '피니시(Finish)' 티어는 완성도를 다듬는 디테일 영역입니다. 피니시 검사는 배포를 가로막지 않습니다. 이처럼 검사 단계를 분리한 점이 핵심입니다. 배포를 막아야 할 결함과 단순한 취향 차이는 같은 선상에서 다룰 수 없기 때문입니다.

Hallmark는 임의로 자료를 지어내는 행위도 거부합니다. 사전 점검(Pre-flight) 단계에서 사진, 스크린샷, 실제 수치를 딱 한 번 요청합니다. 없는 내용을 임의로 꾸며내지 않는다는 원칙을 고수합니다.

사진 규칙 역시 이미지에 동일한 제약을 적용합니다. 라이브러리에는 오픈 라이선스 사진 755장이 등록되어 있습니다. 755는 목록에 포함된 항목 수이며, git 트리에 저장된 이미지 파일 수가 아닙니다. 이 목록은 skills/hallmark/scripts/photos.json에 있습니다. 실제 이미지 파일은 위키미디어 공용(Wikimedia Commons)에 올라와 있습니다. 각 사진은 CC0, 퍼블릭 도메인, CC BY, CC BY-SA 등 저마다의 라이선스를 유지합니다. 이 넷은 하나로 통합된 라이선스가 아닙니다. Hallmark는 사진을 사용할 때 페이지 안에 해당 사진의 출처와 라이선스를 밝힙니다. Unsplash, Pexels, Pixabay 같은 사이트에서는 이미지를 가져오지 않습니다. README에 따르면, 해당 사이트들의 이용약관에서 AI 도구의 이미지 수집을 금지하고 있기 때문입니다.

빌드 진행 방식

일반적인 빌드는 README에 적힌 단계를 차례대로 거칩니다.

먼저 사전 점검(Pre-flight) 단계에서 프로젝트를 읽어 들입니다. 폰트, 팔레트, 프레임워크를 확인하고, 프로젝트에 고정된 design.md 파일이 있다면 함께 읽습니다. 그리고 사진, 스크린샷, 실제 수치 같은 실자료를 딱 한 번 요청합니다.

이어서 scripts/theme.mjs deal 스크립트가 프롬프트에 들어맞고 로그 조건을 만족하는 테마 3가지를 제안합니다. 3은 제안하는 선택지 개수일 뿐, 페이지에 유지되는 테마 수가 아닙니다. 페이지는 오직 테마 하나만 씁니다. 스크립트 이름은 deal입니다. 두 번째 단계인 draw는 작업 목적, 즉 페이지가 완수해야 할 행동을 바탕으로 페이지 구조를 잡습니다.

히어로 섹션은 먼저 단독으로 만듭니다. 나머지 페이지를 만들기 전에 히어로 섹션만 따로 렌더링해서 검토합니다. 이 검토를 마친 뒤에 나머지 페이지를 작성합니다.

그다음 scripts/sloplint.mjs --render 스크립트가 8가지 너비에서 페이지를 검사합니다. 8가지 너비는 별개의 페이지 8장이 아니라 8가지 뷰포트 크기를 가리킵니다. README에 구체적인 픽셀 값은 나와 있지 않습니다. sloplint는 앞서 언급한 패턴들을 잡아내는 린트 스크립트입니다. 렌더링 검사가 끝나면 서브에이전트가 새로운 컨텍스트에서 페이지를 최종 검토합니다.

완성된 페이지는 외부 의존성 없이 독립적으로 동작하는 HTML과 CSS로 구성됩니다. CSS 첫 줄 주석에는 빌드 과정에서 내린 설계 결정들이 기록됩니다.

커스텀 모드에서는 테마 선택 단계를 건너뜁니다. 커스텀을 지정하면 Hallmark는 50개 테마를 쓰지 않습니다. 정해진 컴포넌트 구성이나 색상 팔레트 레시피도 적용하지 않습니다. 대신 플로어 기준과 관문 검사, 그리고 skills/hallmark/references/direction.md에 정의된 짧은 방향성 파일만 따릅니다. README에서는 이 파일을 '해당 고객만이 가진 단 하나의 아이디어를 찾아내 페이지 전체를 이끌어가게 만드는 장치'라고 설명합니다.

리디자인은 명령어로 직접 호출해야만 시작됩니다. 명령어는 경로와 함께 전달하는 /hallmark redesign과 /hallmark audit입니다. 전체 리디자인은 콘텐츠와 동작 연결(wiring)을 그대로 유지한 채 시각 시스템과 레이아웃을 바꿉니다. "레이아웃 유지(keep the layout)"라는 표현을 쓰면 스타일만 바꾸는 리스타일(restyle)을 진행합니다. "다듬어줘(polish)"라는 표현을 쓰면 앞서 정의된 패턴만 골라 정리합니다. 리디자인을 진행하기 전, sloplint --before가 모든 링크, 입력 필드, 핸들러, 제목을 빠짐없이 기록합니다. 리디자인이 끝나면 sloplint --kept가 이 요소 중 누락된 것이 있는지 대조하여 하나라도 빠졌다면 빌드를 실패 처리합니다. 최종 전달물은 작업 전후(before-and-after) 한 쌍으로 제공됩니다.

설치 및 최초 실행

설치하려면 Node.js 18 이상이 필요합니다. Node 18은 최소 런타임 버전이며 패키지 개수가 아닙니다. -g 플래그를 붙이면 모든 프로젝트에서 사용할 수 있도록 전역으로 설치합니다. 현재 프로젝트에만 설치하려면 -g를 붙이지 않습니다. 브라우저 기반 검사를 실행하려면 puppeteer-core 전역 설치와 Chrome 브라우저라는 추가 설치가 필요합니다. 이 둘이 없어도 정적 검사는 그대로 실행되지만, 렌더링 검사와 스크린샷 캡처는 동작하지 않습니다.

npx skills add nutlope/hallmark -g
npx skills add nutlope/hallmark -g --agent claude-code
npm i -g puppeteer-core

첫 번째 명령어는 지원하는 모든 환경(harness)을 대상으로 전역 설치를 진행합니다. 두 번째 명령어는 특정 환경으로 설치 대상을 제한합니다. README에 명시된 --agent 옵션 값은 claude-code, codex, opencode, cursor, github-copilot입니다. 위 예시에서는 claude-code를 사용했습니다. 다른 도구를 쓴다면 해당 값으로 바꾸면 됩니다. 세 번째 명령어는 스킬 자체가 아니라 브라우저 검사를 돌리기 위한 의존성 패키지입니다.

파일이 설치되는 경로는 도구 환경에 따라 다릅니다. Claude Code는 ~/.claude/skills/hallmark에 설치합니다. 실행할 때는 /hallmark 뒤에 프롬프트를 덧붙이거나 새 빌드 요구사항을 설명합니다. Codex CLI는 ~/.agents/skills/hallmark에 설치합니다. $hallmark 뒤에 프롬프트를 적거나 새 빌드를 설명하여 호출합니다. Cursor와 OpenCode는 이 경로에 설치된 복사본을 자동으로 찾아내며, 둘 다 /hallmark 뒤에 프롬프트를 붙이거나 새 빌드를 요청하는 방식으로 실행합니다.

Claude Code 플러그인 경로도 문서에 나와 있습니다. /plugin marketplace add nutlope/hallmark를 실행한 다음 /plugin install hallmark@hallmark를 입력하면 됩니다. 이 플러그인은 /hallmark:hallmark 형태로 호출합니다.

저장소를 로컬에 복제(clone)한 경우, node skills/hallmark/scripts/install.mjs를 실행하면 파일을 복사하기 전에 모든 테마와 레퍼런스를 먼저 검증합니다. node skills/hallmark/scripts/install-hook.mjs는 Claude Code에 코드 편집 시점의 플로어 검사 훅을 추가합니다. 이미 작성된 페이지를 린트하려면 파일이나 디렉터리 경로 뒤에 --render 플래그를 붙여 node skills/hallmark/scripts/sloplint.mjs를 실행합니다. 스킬이 자동으로 실행되지 않는다면, README 안내대로 프롬프트에 "use hallmark to build"를 적고 그 뒤에 요청 사항을 입력하면 됩니다.

저장소 구성 살펴보기

GitHub 기준 nutlope/hallmark의 스타 수는 52,153개입니다. 스타는 개인 계정의 공개 북마크일 뿐, 설치 횟수나 빌드를 직접 돌려본 사용자 수가 아닙니다. 포크 수는 2,777개입니다. 포크는 다른 계정 아래 생성된 별도 복제본을 뜻하며, 복제된 저장소가 계속 유지보수되고 있음을 보장하지는 않습니다. 열려 있는 이슈는 52개입니다. 이 숫자는 현재 닫히지 않은 이슈 스레드 수로, 버그 보고, 질문, 기능 요청이 뒤섞여 있으며 이미 닫힌 스레드는 제외한 수치입니다.

코드 라이선스는 MIT입니다. 라이선스 고지만 코드에 유지한다면 상용 프로젝트를 포함해 사용, 복제, 수정, 배포를 모두 허용합니다. 사진은 이 라이선스 대상에 포함되지 않습니다. 각 사진은 라이브러리 목록에 명시된 개별 라이선스를 그대로 따릅니다.

저장소 생성일은 2026-04-27입니다. GitHub 저장소가 처음 만들어진 날짜입니다. 마지막 푸시 일자는 2026-11-05입니다. 가장 최근 기록된 푸시 일자일 뿐, 특정 버전 라벨을 뜻하거나 그날 모든 테마가 바뀌었다는 뜻은 아닙니다.

전체 디렉터리 트리에는 파일 850개와 SKILL.md 파일 1개가 들어 있습니다. 850은 문서, 테마 레퍼런스, 스크립트, 웹사이트 파일, 설정 파일까지 모두 합친 전체 파일 수이며, 스킬이 850개라는 뜻이 아닙니다. SKILL.md가 1개라는 것은 이 저장소가 단 하나의 스킬을 배포한다는 의미입니다. 스킬 팩이었다면 이 이름의 파일이 여러 개 들어갔을 것입니다. 각 테마 파일 크기는 최대 8KB에 불과합니다. 8KB는 아주 작은 텍스트 파일 크기입니다. 빌드 시에는 skills/hallmark/references/themes/에서 테마 파일 1개와 옆에 딸린 예시 이미지를 읽어옵니다.

루트 디렉터리의 항목은 .claude-plugin, .gitattributes, .github, .gitignore, LICENSE, README.md, ROADMAP.md, docs, eval, package.json, site, skills, vercel.json입니다. .claude-plugin은 Claude Code 플러그인 패키지임을 나타냅니다. skills에는 앞서 언급한 레퍼런스와 스크립트를 포함한 스킬 본체가 들어 있습니다. site와 vercel.json은 공식 웹사이트용 파일입니다. package.json은 Node 패키지 매니페스트입니다. docs에는 README에 링크된 테마 스크린샷 등 참고 자료가 들어 있습니다.

README에는 50개 테마 중 10개를 샘플 제품과 연결해 소개합니다. 10이라는 숫자는 표에 정리된 예시 개수일 뿐 축소된 카탈로그를 뜻하지 않습니다. 10가지 예시는 다음과 같습니다. 은행 대사 페이지 Closewise를 위한 Dusk, 웹훅 API Relay를 위한 Cobalt, 브랜드 아이덴티티 스튜디오 Field Office를 위한 Studio, 향수 아틀리에 Maison Orla를 위한 Atelier, 수면 사운드 앱 Lull을 위한 Ribbon, 농장 기록 관리 Fieldbook을 위한 Furrow, 가족 복약 관리 앱 Tandem을 위한 Dose, 야외 수영장 Bellwater Lido를 위한 Refract, 건설 현장 스캔 서비스 Swath를 위한 Vantage, 증류소 Five Mile Gin을 위한 Hedgerow입니다. 이 예시들은 디자인 재료가 얼마나 폭넓은 작업 목적에 쓰일 수 있는지 보여주며, 그대로 베껴 써야 하는 템플릿이 아닙니다.

또한 README에는 영향을 준 이전 공개 작업물들이 명시되어 있습니다. Impeccable, frontend-design, Open Design, Kami, taste-skill, huashu-design, UI UX Pro Max, Emil Kowalski의 스킬들, Web Interface Guidelines 등입니다. 이 목록은 프로젝트의 계보를 밝힐 뿐이며, 해당 프로젝트들의 작업 결과를 이 저장소에 그대로 가져왔음을 뜻하지는 않습니다.

다른 스킬 저장소와의 스타 수 비교

같은 날 동일 출처를 기준으로 보면, 다른 에이전트 스킬 저장소 3곳이 훨씬 더 많은 스타를 받았습니다. 아래 수치는 GitHub 스타 수입니다. 스타는 공개 북마크일 뿐입니다. 아래 비율 역시 단순 스타 수 비율이며, 다운로드 수나 품질 점수가 아닙니다.

448,601은 52,153의 약 8.6배입니다. 320,318은 약 6.1배, 315,418은 약 6.0배에 달합니다. 차이가 크지만, 다루는 영역 자체가 완전히 다릅니다. rea는 리버스 엔지니어링 스킬이고, mattpocock/skills는 개인 스킬 모음이며, superpowers는 방법론 프레임워크입니다. 반면 Hallmark는 SKILL.md 단 1개로 구성된 디자인 스킬입니다. 성격이 다른 프로젝트의 스타 수가 높다고 해서 Hallmark가 명시된 클리셰 패턴을 제대로 잡아내는지 판별할 수는 없으며, 스타 수가 낮다고 해서 그 반대를 뜻하지도 않습니다.

검사 기능의 한계

문서에 정의된 규칙을 살펴보면 몇 가지 분명한 한계가 드러납니다.

플로어 검사는 배포를 차단하지만, 리플렉스 검사는 사유를 기록하면 배포를 막지 않고, 피니시 검사는 어떤 경우에도 배포를 막지 않습니다. 따라서 해당 요소가 피니시 티어에 있거나 예외 처리된 리플렉스 관문에 걸려 있다면, 사람이 직접 검토했을 때 퇴짜를 놓을 만한 디자인이라도 검사를 통과할 수 있습니다.

8가지 너비의 렌더링 검사가 언제나 실행되는 것도 아닙니다. puppeteer-core와 Chrome이 깔려 있지 않으면 정적 검사만 돌아가고 렌더링 검사는 건너뜁니다. 이런 상황에서 통과한 결과는 정적 검사를 통과했다는 뜻일 뿐입니다.

/hallmark redesign이나 /hallmark audit을 명시하지 않으면 기존 페이지를 다시 디자인하지 않습니다. 새 빌드를 요청하는 프롬프트는 기존 프로젝트 트리를 리스타일하는 작업과 전혀 다른 경로로 작동합니다.

테마 파일은 구체적인 문구나 섹션 순서를 고정하지 않습니다. 주어진 재료와 작업 구조 안에서 실제 카피와 순서를 고르는 역할은 여전히 AI 모델의 몫입니다. 커스텀 모드에서는 테마 파일조차 빠집니다. 방향성 파일이 의도적으로 짧게 쓰인 만큼, 정해진 구조가 적을수록 페이지의 완성도는 스킬을 실행하는 AI 모델의 성능에 크게 좌우됩니다.

사진은 원격으로 불러옵니다. 저장소에는 이미지의 실제 파일 데이터가 들어 있지 않습니다. 위키미디어 공용에 접속할 수 없는 환경이라면 안내된 방식대로 사진 라이브러리를 쓸 수 없습니다. 페이지 내 출처 표기와 개별 사진 라이선스 준수 의무도 그대로 남습니다. 코드에 적용된 MIT 라이선스가 사진의 라이선스까지 바꿔주지는 않습니다.

스킬을 환경 디렉터리에 복사해 두었다고 해서 빌드가 알아서 시작되는 것도 아닙니다. README에서도 스킬이 자동으로 실행되지 않을 때는 프롬프트에 Hallmark를 직접 지정하라고 안내합니다.

이 글에서 다룬 자료에는 린트 검사의 통과율, 사용자 수, 소요 시간 같은 수치가 공개되어 있지 않습니다. 52개의 열린 이슈 역시 아직 닫히지 않은 논의 스레드일 뿐이며, 소프트웨어의 버그 개수를 뜻하지는 않습니다.

누구에게 필요한 스킬인가

현재 Claude Code, Codex CLI, Cursor, OpenCode를 쓰고 있으면서, 단 하나의 테마 파일로 독립적인 HTML/CSS 페이지를 생성하거나 링크·필드·핸들러·제목이 그대로 유지되는지 검증하며 특정 경로의 스타일을 개편해 주는 단일 스킬이 필요하다면 Hallmark를 설치해 볼 만합니다. 모든 프로젝트에서 스킬을 쓰고 싶다면 전역 설치를, 그렇지 않다면 현재 프로젝트에만 설치하면 됩니다.

반면 리버스 엔지니어링 에이전트, 범용 엔지니어링 스킬 팩, 소프트웨어 개발 방법론을 찾는다면 이 스킬은 맞지 않습니다. 그런 작업은 앞서 표에 나온 스타 수가 더 높은 다른 저장소들의 몫입니다. puppeteer-core와 Chrome을 설치할 수 없다면 렌더링 검사 경로는 생략해야 합니다. 정적 검사는 여전히 동작하지만, 검사 범위는 훨씬 축소됩니다.

Hallmark는 명문화된 플로어 기준과 최대 8KB짜리 테마 파일 1개, 그리고 린트 스크립트의 조합일 뿐이며, 완성된 페이지가 무조건 디자인 감각을 갖추도록 보장해주지는 않습니다.

출처: GitHub 저장소 nutlope/hallmark, https://github.com/nutlope/hallmark.