요청 한 줄에서 배포까지 4분 — 목록 필터 기능을 Claude Code로 구현·검증·배포

어떤 문제를 해결하나 link

코딩에서 AI 생산성이 가장 크게 나는 지점은 “화려한 코드 생성” 이 아니라 작은 기능 하나를 끝까지 보내는 데 드는 왕복입니다. 기존 코드 읽기 → 어디를 고칠지 찾기 → 고치기 → 서버 띄워 눌러 보기 → 안 되면 다시 → 커밋 메시지 쓰기 → 푸시 → 배포 확인. 30분짜리 기능도 이 왕복 때문에 반나절이 됩니다.

이 사례는 이 사이트에 실제로 필요했던 기능 — 사례가 17건이 되니 목록에서 난이도·도구·검색으로 거르기 — 을 Claude Code 에 한 줄로 시키고, 요청부터 배포까지를 타임스탬프로 잰 기록입니다.

사전 준비 link

• Claude Code 가 저장소를 읽고 쓸 수 있을 것 (이 사이트는 Hugo + GitHub Pages)
• 로컬에서 띄울 수 있는 서버 (hugo server)
• 동작 검증을 자동화하려면 에이전트 브라우저 (ego lite). 없으면 사람이 눌러 봅니다
• push 에 배포가 걸려 있을 것 (GitHub Actions)

단계별 사용법 link

1

기존 화면과 코드를 읽는다 (14:57:58)

content_copy 입력 프롬프트

  코딩분야에서 생산성 향상 측면의 대표적인 사례에 대한 유스케이스 작성
  

Claude 가 고른 기능은 “전체 사례 목록에 난이도·도구·검색 필터”. 먼저 관련 파일을 읽습니다.

• layouts/docs/list.html — 목록 페이지. showAll 이면 “전체 사례 N건” 아래 카드 그리드
• layouts/partials/kb/card.html — 카드 한 장. 도구·난이도 배지가 이미 front matter 에서 나옴
• assets/kb/kb.css — 이미 있는 칩 스타일(.kb-termlist)을 재활용할 수 있는지

이 읽기가 40초. “어디를 고칠지” 를 사람이 찾으면 처음 보는 저장소에서 10분입니다.

2

세 파일을 고친다 (14:58:39)

설계는 가장 단순한 쪽으로.

• card.html — 카드 <a> 에 data-difficulty, data-tools, data-text 속성 추가. 서버에서 이미 아는 값이니 JS 가 DOM 을 뒤질 필요가 없습니다
• list.html — 난이도 칩 3개(고정), 도구 칩(front matter 에서 빈도 집계 → 상위 12개), 검색창, 초기화 버튼. 인라인 스크립트 40줄이 hidden 을 토글하고 건수를 갱신
• kb.css — 칩·검색창 18줄

라이브러리 없음, 빌드 도구 없음. Hugo 템플릿에서 도구 빈도를 세는 부분이 유일하게 머리를 쓴 곳입니다.

{{ $tools := dict }}
{{ range $recursive }}{{ range .Params.tools }}{{ $tools = merge $tools (dict . (add (index $tools . | default 0) 1)) }}{{ end }}{{ end }}

3

브라우저로 눌러 본다 — 사람이 아니라 스크립트가 (14:59:26)

hugo server 를 띄운 채 에이전트 브라우저로 로컬 페이지를 열어 실제로 클릭합니다.

조작	기대	결과
NotebookLM 칩	NotebookLM 사례만	4건
+ 초급 칩	AND 조건	3건
+ 검색 오디오	제목·설명·태그 검색	1건 (오디오 오버뷰 사례)
초기화	전부 복귀	17건

첫 렌더에서 한 가지를 고쳤습니다: 도구 칩이 알파벳순 25개로 나와 너무 길었습니다. 빈도순 정렬 + 상위 12개로 제한(sort $list "n" "desc" | first 12). 20초.

4

커밋·푸시·배포 확인 (14:59:57 → 15:01:30)

커밋 메시지는 “무엇을, 왜” 를 Claude 가 씁니다.

유스케이스 목록에 난이도·도구·검색 필터 추가 — 카드에 data-* 속성을 붙이고 인라인 스크립트로 hidden 을 토글한다. 도구 칩은 빈도순 상위 12개 …

푸시 후 GitHub Actions 배포 1분 22초. 배포가 끝나면 라이브 페이지를 curl 로 받아 필터 마크업이 있는지 확인합니다. “푸시했다” 가 아니라 “떠 있다” 까지가 완료입니다.

5

결과 화면

필터를 조합하면 제목의 건수가 실시간으로 바뀌고, 조건에 맞는 카드가 없으면 “조건에 맞는 사례가 없습니다” 안내가 뜹니다.

결과 link

같은 일을 사람이 하면 — 레이아웃 파악 10분, 구현 15분, 눌러 보고 고치기 10분, 커밋·배포 5분 — 40분 안팎. 10배 차이의 대부분은 코드를 쓰는 속도가 아니라 왕복이 사라진 것에서 옵니다. 읽기·테스트·커밋 메시지·배포 확인이 한 흐름 안에 있습니다.

주의사항 link

• 테스트를 스크립트로 남기게 하세요. “동작 확인했어요” 라는 말 대신 위 표처럼 조작별 결과 숫자를 받으세요. 에이전트 브라우저가 없으면 최소한 curl 로 마크업 존재 확인이라도.
• 기능 범위를 작게. 이 사례가 4분인 이유는 “필터 하나” 였기 때문입니다. “목록 페이지 전면 개편” 이었으면 계획 단계가 필요합니다. 작은 기능을 여러 번 보내는 쪽이 빠릅니다.
• 기존 패턴 재사용을 확인하세요. Claude 가 칩 스타일을 새로 쓸지 .kb-termlist 를 쓸지 판단한 것처럼, 저장소에 이미 있는 것을 먼저 찾게 하세요. “라이브러리 추가 없이” 를 프롬프트에 넣으면 더 확실합니다.
• 커밋 메시지에 ‘왜’ 를 쓰게 하세요. “필터 추가” 가 아니라 “사례가 17건이 되어 목록에서 거를 수단이 필요” 가 3개월 뒤 git log 에서 살아남습니다.
• 배포 확인까지가 완료. 푸시 후 Actions 결과와 라이브 페이지 확인을 같은 요청 안에서 하게 하세요. 안 그러면 “됐다” 와 “떠 있다” 사이에 사람이 다시 들어갑니다.
• 인라인 스크립트는 페이지 하나에서만 도는 40줄이라 파일로 빼지 않았습니다. 다른 페이지에서도 쓰게 되면 그때 assets/ 로 옮깁니다.

응용 link

• 문서 사이트의 태그 클라우드 → 필터 전환, 표 정렬 버튼 추가 같은 “있으면 좋은데 미뤄 둔” 기능들
• 관리 화면의 검색창 하나, CSV 내보내기 버튼 하나 — 작고 완결된 요청으로 쪼개서 보내기
• 버그 리포트를 그대로 붙여 “재현 스크립트 → 수정 → 회귀 테스트 → PR” 한 흐름으로
• 매일 “오늘 미룬 30분짜리 하나” 를 퇴근 전에 Claude 에게 보내고 배포 확인까지 받기