PR 리뷰가 병목이 될 때
이 글을 쓰려고 제 저장소를 열었다가 반대 사실을 봤어요. PR 7건 전부 리뷰 0건, 188파일짜리가 10분 만에 머지. 리뷰가 밀리는 팀과 리뷰가 없는 팀은 원인이 같습니다.
QR 찍으면 열리는 체크리스트 폼, 코딩 없이 만들기 — 완전 초보용
고객에게 QR을 보내 체크리스트를 받고 싶다면. 대부분은 구글폼 15분이면 끝나고, AI는 다른 데 써야 해요. 직접 만들어야 하는 경우와 초보가 꼭 막히는 다섯 지점까지 정리했습니다.
디자이너와 싸우지 않는 협업법
"이거 디자인이랑 다른데요"가 싸움이 되는 건 취향이 달라서가 아니라 허용 오차가 합의 안 돼서예요. hanui에서 쓰는 실제 검증 에이전트 규칙을 그대로 공개합니다.
프론트엔드 추정은 왜 항상 틀릴까
"이 화면 이틀이요"가 닷새가 되는 이유를 hanui 저장소의 실제 커밋으로 확인했어요. 블록 42개 중 16개가 완성 후 다시 열렸고, 늘어난 건 전부 상태 처리였습니다.
스프린트에서 컴포넌트 먼저 만드는 이유
화면 단위로 스프린트를 돌리면 3번째 스프린트에서 무너져요. 컴포넌트 인벤토리를 먼저 만드는 실전 방법과 과설계를 피하는 기준을 정리했습니다.
더 큰 걸 만들고 싶어지면 — 다음 도구로 건너가되, 목적은 잊지 않기
한 페이지 도구로 부족해지는 날이 와요. 그때 Lovable·Bolt 같은 도구로 다리를 건너면 돼요. 원리는 똑같아요 — 말로 만든다. 단, 크게 만드는 게 목적이 아니라 일을 더는 게 목적이에요.
동료·팀에 공유하고 자랑하기 — 링크 하나면, 혼자 편한 걸 다 같이
말로 만든 도구는 링크 하나로 옆자리와 나눌 수 있어요. 받은 사람은 AI를 몰라도 칸만 채워 써요. 단, 공유하기 전 판단 하나 — 도구는 나눠도 실제 숫자·개인정보는 빼고 나눕니다.
이상하게 나올 때 고쳐달라 하는 법 — 에러 글자를 그대로 붙여넣으세요
만든 도구가 이상하게 나오거나 빨간 에러가 떠도 그만둘 일이 아니에요. 그 에러 글자를 그대로 복사해 붙여넣으면 AI가 읽고 고쳐줘요. 포기와 완성을 가르는 건, 한 번 더 말 거는 것.
AI가 인쇄용 문서·양식을 만들어 줘요 — 공지문·신청서가 진짜 파일로
사내 공지나 신청서를 말로 만드는 것도 편하지만, 진짜는 이거예요 — 바로 인쇄하거나 붙일 수 있는 문서·PDF 파일로 나와요. 채워 쓰는 양식까지. 단, 우리 회사 형식에 맞추는 건 내 몫이에요.
지난 보고서를 주면 AI가 그 양식을 그대로 복제해요 — 이번 주 보고 초안이 뚝딱
한 일 몇 줄만 넣으면 보고서가 나오는 것도 편하지만, 진짜는 이거예요 — 지난달 보고서 하나를 예시로 주면 AI가 그 형식·말투를 그대로 복제해 이번 것을 채워줘요. 단, 사실과 추측은 내가 가릅니다.
AI가 긴 PDF를 통째로 읽어요 — 던지면 요약 + 내 할 일만 쏙
긴 글을 복사해 붙이는 것도 되지만, 진짜는 첨부예요 — 30쪽짜리 회의 자료 PDF를 그대로 던지면 AI가 통째로 읽어 세 줄 요약과 내 할 일을 뽑아줘요. 이 장의 판단은 요약이 버린 게 없나 확인하기.
AI가 영수증 사진을 읽어요 — 찍어서 던지면 날짜·금액 표로
카드 내역을 복사해 붙이는 것도 편하지만, 진짜는 이거예요 — 영수증을 사진으로 찍어 던지면 AI가 그 이미지를 읽어서 날짜·상호·금액을 표로 만들어줘요. 글자만 읽는 게 아니거든요.
AI가 엑셀 파일을 만들어 줘요 — 붙여넣으면 .xlsx로 뚝딱, 팀도 같이 쓰고
숫자 붙여넣고 "합계 내줘"는 다들 하죠. 그런데 그 결과를 회사 양식 그대로 채워진 진짜 엑셀 파일로 다운로드까지 된다는 건 의외로 몰라요. 채팅과 "도구"가 갈리는 지점이 여기예요.
AI를 믿는 선 — 숫자와 사실은 절대 안 믿어요
AI는 없는 사실도 아주 당당하게 지어내요. 경리한테 이건 사고예요. 뭘 AI한테 맡기고 뭘 끝까지 내 눈으로 지킬지 — 이 선 하나만 그으면 AI를 마음 놓고 씁니다.
"물어보기" vs "만들기" — 한 번 만들어 백 번 쓰기
매번 똑같은 걸 AI한테 다시 설명하고 있다면 그건 "만들기" 신호예요. 그때그때 계산을 부탁하는 것과, 계산기를 받아두는 것의 차이. 그리고 만들어 둔 도구는 파일도 뽑고 팀도 같이 써요.
부탁하듯 말 거는 법 — 좋은 부탁은 구체적인 부탁이에요
AI한테 시켰는데 엉뚱한 게 나왔다면, AI가 멍청해서가 아니라 부탁이 막연해서예요. 같은 부탁도 "누구에게·뭘·어떤 모양으로"를 짚으면 결과가 이렇게 달라져요 — 실제로 비교해서 보여드려요.
AI는 말귀 알아듣는 인턴이에요 — 무서워 말고 시켜보세요
엑셀과 영수증에 파묻힌 경리·사무직에게. AI는 똑똑한 기계가 아니라 말귀 잘 알아듣는 신입 인턴 한 명이에요. 게다가 이 인턴은 표도 만들고, 사진도 읽고, 엑셀 파일까지 뽑아줘요 — 전부 말로만.
AI가 내 말투를 흉내 내요 — 내 지난 메일을 보여주면, 매번 쓰던 그 메일이 버튼 하나로
AI한테 메일 써달라 하면 남의 말투로 나오죠. 그런데 내가 쓴 메일 몇 개를 보여주면, AI가 내 말투를 그대로 흉내 내요. 그걸 한 번 도구로 만들면, 다음부턴 칸만 채우면 끝. 2부의 첫 도구예요.
OMC 한 달 — 32개 에이전트 중 매일 쓰는 건 5개
Oh-My-Claude Code를 한 달 써봤다. 32개 에이전트가 있다는데, 정말 손에 익은 건 5개. 나머지는 모르는 채로도 충분했다.
Playwright로 CI E2E 자동화하기 — 기본 가이드
설치 한 줄, 설정 다섯 줄, 워크플로우 다섯 줄. Playwright로 E2E 테스트를 GitHub Actions에 붙이는 가장 간결한 방법을 정리했어요.
접근성 CI를 만들기로 한 이유 — VPAT, 수동 검사의 한계
월요일에 통과한 버튼이 금요일에 소송 대상이 된다. 운영 서비스에 접근성 CI를 붙이기로 한 이유를 사건·숫자·반박으로 정리했어요. 접근성 CI 구축기 1편.
Figma 디자인 검증 자동화 — 서브에이전트로 CSS 오차 잡기
Figma MCP로 UI를 구현하면 자잘한 CSS가 틀어지는 문제. Claude Code 서브에이전트로 생성 → 검증 → 패치를 한 턴에 해결하는 방법을 공유해요.
AI가 짠 코드, 시니어는 뭘 보는가
AI가 만든 코드를 리뷰할 때 시니어 개발자가 확인하는 5가지. 동작하는 코드와 좋은 코드의 차이.
AI 3개, 사람 1명 — 시니어 개발자의 리팩토링 워크플로우
Jira로 계획, Claude Code로 리팩토링, Claude로 검증. AI 도구 3개를 돌리는 1명이 하는 건 "판단"이다.
기발자, 디발자 시대 — AI가 역할 경계를 허물고 있다
기획+개발자 = 기발자, 디자인+개발자 = 디발자. AI 도구가 만든 새로운 역할의 등장과, 프론트엔드 개발자로서 나의 위치.
애자일에서 UI 개발자는 디자인을 기다리지 않는다
와이어프레임과 디자인 시스템만 있으면 UI 개발자는 디자인 완료 전에 화면을 칠 수 있어요. KRDS 사례로 설명합니다.
프론트엔드 팀에 게이트키핑 도입하기
OpenClaw의 5계층 품질 관문을 프론트엔드 6인 팀에 적용하는 법. 코드 리뷰에서 포맷팅 지적이 사라져요.
디자인 시스템에서 접근성 자동화하기 — axe + Storybook + CI
디자인 시스템에 접근성 자동화를 붙이는 방법. axe-core로 단위 테스트, Storybook a11y 애드온으로 시각 검사, GitHub Actions CI로 PR마다 자동 차단까지 실전 가이드.
스크린 리더 테스트 실전 — VoiceOver/NVDA로 내 앱 검증하기
VoiceOver(Mac)와 NVDA(Windows)로 웹 접근성을 직접 테스트하는 방법. 스크린 리더 기본 조작부터 실전 테스트 시나리오, 자주 발견되는 문제와 수정법까지 정리합니다.
키보드 네비게이션 완전 가이드 — Tab, Arrow, Esc 패턴
웹 접근성의 핵심인 키보드 네비게이션 패턴을 정리합니다. Tab/Arrow/Esc/Enter 각각의 역할과 WAI-ARIA 패턴, HANUI 컴포넌트 적용 사례를 공유해요.
금융 프론트엔드에서 접근성이 필수인 이유 — 전자금융 접근성 실무 가이드
전자금융 서비스의 웹접근성 의무와 프론트엔드 개발자가 실무에서 챙겨야 할 접근성 체크리스트. KWCAG 2.2 기반 HANUI 디자인 시스템 적용 사례를 공유합니다.
백엔드 잘 모르는 프론트가 Spring Boot API 짠 이야기
전자정부프레임워크가 뭔지도 몰랐던 프론트엔드 개발자가 Claude Code로 Spring Boot 백엔드를 짜게 된 과정. eGovFrame v5 블록 조합 + Claude Code 스터디 모드로 풀스택 구현.
Claude Code + MCP로 노션·피그마 연동하기
MCP(Model Context Protocol)로 Claude Code에 Notion, Figma를 연결하는 방법. 노션 페이지를 읽고, 피그마 디자인을 코드로 변환하는 실제 워크플로우를 공유해요.
나만의 Claude Code 커맨드 만들기 — 마크다운 하나로 자동화
Claude Code 슬래시 커맨드를 직접 만드는 법. /commit 커맨드를 처음부터 만드는 과정, 에이전트와 훅까지. 팀에 공유하는 방법도.
CLAUDE.md 하나로 AI가 내 코드 스타일을 따라한다
Claude Code의 핵심 설정 파일 CLAUDE.md 작성법. 실제 HANUI 프로젝트의 CLAUDE.md를 공개하고, 잘 쓰는 법과 못 쓰면 생기는 문제를 정리했어요.
Claude Code 슬래시 커맨드 21종 — 설치 한 줄이면 끝
Claude Code에 /commit, /api, /security 같은 슬래시 커맨드 21종 + 에이전트 4종 + 훅 5종을 원라인 설치. 프론트엔드/백엔드/풀스택 선택 가능.
Claude Code로 CMS 프로젝트 하루만에 만들기 — 기획부터 코딩까지 자동화
Claude Code로 노션 기획서 작성부터 읽기, GitHub 이슈 자동 생성, Tiptap 에디터 구현, PR 생성까지. 실제 CMS 프로젝트에서 18개 이슈를 하루만에 처리한 워크플로우.
HANUI Kits — 복사해서 바로 쓰는 기능 패턴
컴포넌트만으론 부족해요. 게시판, 인증, 대시보드 같은 기능을 API URL만 바꾸면 바로 쓸 수 있는 HANUI Kits를 소개합니다.
KRDS MegaMenu 완전정복 — 공공 웹사이트 네비게이션 만들기
공공 웹사이트 헤더 메뉴를 HANUI로 구현하는 법. 웹접근성 키보드 네비게이션, ARIA 속성, 포커스 관리까지 자동 처리되는 MegaMenu 사용법.
Next.js + HANUI 프로젝트 세팅 가이드
Next.js에서 HANUI(KRDS 기반 디자인 시스템)를 세팅하는 방법. npx hanui init 한 줄로 Tailwind, 토큰, 폰트까지 자동 설정.
rem vs px, 언제 뭘 써야 할까
CSS 단위 선택 기준 정리. 글자와 여백은 rem, 테두리와 아이콘은 px을 쓰는 이유와 접근성 관점, 62.5% 트릭을 권하지 않는 이유, KRDS 17px 기준까지 다룹니다.
KRDS React Form 컴포넌트 - Input, Select, 자동 접근성 연결
FormField로 감싸면 label 연결, 에러 메시지, aria 속성이 자동으로 처리됩니다. react-hook-form 연동 예시까지.
KRDS 디자인 토큰 Tailwind CSS 적용 방법 - 17px 폰트, 색상 시스템
KRDS의 17px 기본 폰트를 Tailwind CSS에서 처리하는 방법. 숫자 스케일과 시맨틱 토큰을 활용한 색상 시스템, 반응형 타이포그래피 구현.
Tailwind CSS v4 마이그레이션 가이드
Tailwind CSS v3에서 v4로 넘어갈 때 바뀐 것들. CSS-first 설정, @import 문법, 네이티브 CSS 변수부터 자주 나는 오류와 마이그레이션 판단 기준까지 정리했습니다.
KWCAG 2.2 웹접근성 자동 적용 - KRDS React 컴포넌트로 검수 통과하기
HANUI 컴포넌트에 내장된 웹접근성 기능. aria 속성, 키보드 네비게이션, 포커스 관리까지 자동 적용되어 KWCAG 2.2 검수를 통과할 수 있습니다.
공공 SI React 기술스택 2025
2025년 공공기관 React 프로젝트 권장 기술스택. Next.js 15, Tailwind 4, KRDS, Zustand, TanStack Query 등 실전 조합 가이드.
KRDS React Button 컴포넌트 설계 - variant, 접근성, cva 패턴
HANUI Button 컴포넌트의 설계 철학. 8개 variant, cva 패턴, 접근성(aria-busy, 포커스 링), asChild, 아이콘 지원까지.
KRDS React 컴포넌트 구현 시간 비교 - 직접 코딩 vs HANUI
버튼, 폼, 헤더+메가메뉴를 직접 구현할 때와 HANUI를 쓸 때의 실제 코드와 시간 비교. Before/After로 보여드립니다.
CSS 변수로 다크모드 구현하기
CSS 변수(Custom Properties)를 활용한 다크모드 구현법. 시맨틱 토큰, Tailwind 연동, SSR 깜빡임 방지까지 실전 가이드.
shadcn/ui 방식의 KRDS React 컴포넌트 - 왜 npm 패키지가 아닌가
HANUI가 npm 패키지 대신 shadcn/ui 방식의 소스 복사를 택한 기술적 이유. Tailwind CSS, Radix UI 기반 아키텍처 설명.
KRDS React 컴포넌트 라이브러리 HANUI - 그냥 가져다 쓰세요
KRDS 2.2 표준을 따르는 React 컴포넌트 라이브러리. shadcn/ui 방식으로 소스 코드를 복사해서 자유롭게 수정할 수 있습니다.
shadcn/ui 한국 프로젝트에서 제대로 쓰는 법
shadcn/ui를 한국 프로젝트에 적용할 때 필요한 한글 폰트, 색상 커스터마이징, DatePicker 한글화, 접근성 설정을 정리합니다.
Tailwind CSS로 디자인 시스템 만들기
Tailwind CSS로 색상 토큰, 타이포그래피, 간격 시스템을 설정하고 cva로 타입 안전한 컴포넌트를 만드는 방법. 공공기관은 KRDS 기반 HANUI 프리셋 활용법도 포함.
React 웹접근성 체크리스트 — 공공 SI 심사 통과하기
React 프로젝트에서 자주 걸리는 웹접근성 항목 TOP 5와 컴포넌트별 체크리스트를 정리합니다. eslint-plugin-jsx-a11y, axe DevTools 활용법까지.