DEV Community: @kiwibreaksme

I catalogued every tell that makes a UI look AI-generated. My own tool kept failing the test.

@kiwibreaksme — Thu, 02 Jul 2026 05:23:12 +0000

You can always tell when an AI built a UI. You can't always say why.

I maintain StyleSeed — an open-source set of design rules that Claude Code, Cursor, and Codex read automatically, so AI-built UI stops looking generated. For the past few months my actual job has been writing that "why" down: cataloguing every tell, turning each one into a rule an agent can obey, and then dogfooding the rules to see if they hold.

They kept not holding — in ways that embarrassed me three separate times. That's what this post is about, because the failures turned out to be more useful than the rules.

The catalog: generation-one tells

These are the ones everyone recognizes, even non-designers:

The default indigo. #4F46E5 / #5E6AD2 — Tailwind's and every agent's comfort color. Zero brands chose it; every unguided agent ships it.
The icon-in-a-pale-chip. A generic Lucide line icon in an identical rounded square with a pastel background, repeated for every feature card. One is fine. Seven is a signature.
Rainbow status lists. Every row gets a differently-colored badge — including "normal," which should be grey. Color is supposed to mean look here; paint every row and nothing means anything.
Emoji as UI icons. 🚗🧺⭐ inject five uncontrolled hues each and break the single-accent rule instantly.
Centered everything + gradient headline + ✨ badge. The stock hero.
4 identical KPI cards. 3 identical pricing columns. 14px body on a 1440px screen. Pure #000 text.

Individually each is defensible. Together they compound into "an AI made this."

So I wrote rules that ban each one — with the reasoning, so a model applies them instead of pattern-matching around them. Then I tested.

Failure #1: my own rules were teaching the rainbow

Dogfooding a mobile dashboard, the status list came out rainbow — the exact thing the project exists to prevent. I went digging expecting a model failure, and found this in my own DESIGN-LANGUAGE.md, rule 65:

Vary status states in lists to create visual interest through color diversity.

I was literally instructing agents to build rainbow lists. The agent had followed my rule perfectly. The rule was wrong.

Rewrote rule 65 (status color = severity, never decoration), re-ran the same build: two grey "normal" rows, one amber, one red. Same agent, same prompt — only the rule changed.

Failure #2: my landing page scored 58/100 on my own quality gate

StyleSeed ships a scored quality gate — the agent reviews its UI against the rules and fixes it to a floor of 80/100 before showing you anything. At some point I did the obvious uncomfortable thing and ran the gate on StyleSeed's own landing page.

58/100. The page whose hero copy mocks "an icon in a pale chip on every card" had twelve icon chips on it. Four accent colors. 11–13px text everywhere. A reviewer would have screenshotted it with the caption "physician, heal thyself."

We rebuilt it to pass (one accent, chips gone, type floor met). But the lesson stuck: coherence rules don't enforce themselves — the gate has to run on everything, including your own marketing.

Failure #3: the escape hatches became clichés

Here's the one I find genuinely interesting. Once you ban the generation-one tells, agents all flee through the same exits — and the exits are becoming the next tells:

Ghost index numbers (01 · 02 · 03) replacing every icon chip
UPPERCASE-overline + big-number cards repeated identically for every KPI
The text-left / visual-right hero with two pill CTAs on every product site
And the overshoot: escaping "generic" into dated — a beige paper background + serif on everything, which stops reading "designed" and starts reading "government pamphlet." I shipped exactly this as a proud "after" example. It got rejected on sight — the generic before honestly looked better at a glance.

So the rulebook now tracks tells by generation: gen-1 (indigo, chips, rainbow) is banned outright; gen-2 has its own rule — one signature treatment per project, varied section anatomy; gen-3 sets a modern floor — white base, serif as seasoning, keep the air.

This is the actual nature of the problem: it's not a checklist, it's an arms race against convergence. Any escape route, once popular, becomes a tell.

Does it work?

The cover image is the current proof: same product, same prompt, same model — only the rules changed. The before is an authentic agent-defaults build (competent, clean, and instantly recognizable as AI). The after chose its own accent, put the real product in the hero, and varied every section's anatomy.

I also ran a three-domain stress test with zero design direction — a Korean mobile health app, a dark observability dashboard, a warm e-commerce landing. All three came out refined and different from each other: calm teal + soft radii, signal-teal + IBM Plex + tonal dark, terracotta + a display grotesque. The thing I feared most — that the rules would just converge everything onto a new "StyleSeed look" — didn't happen.

What actually moves the needle

After all the dogfooding, three mechanics matter more than any individual rule:

Constraints before code. A STYLESEED.md lock (mood, key color, font, surface) the agent re-reads every prompt. Unlocked = drift.
A scored gate with a floor. "Review your work" is ignorable; "score it, fix to ≥80, then show me" is not.
Ban lists with reasons. Positive advice ("use nice spacing") does nothing. Named bans ("no #4F46E5, no icon-chips, normal = grey") change output immediately.

It's all MIT: github.com/bitjaru/styleseed — 74 rules + the gate + skins, readable by Claude Code / Cursor / Codex via one pasted sentence. Live demo at styleseed-demo.vercel.app.

What's the tell that instantly makes you think "an AI made this"? I'm collecting them — the catalog only grows when someone names a new one.

AI가 만든 UI가 어딘가 '어색한' 이유 — 그리고 그걸 고치는 한 가지 원칙

@kiwibreaksme — Tue, 16 Jun 2026 06:32:37 +0000

🇬🇧 English version: Why AI-Generated UIs Look 'Off' — and the One Principle That Fixes It

겪어보셨을 겁니다. AI한테 대시보드를 만들어 달라고 하면, 나오긴 나와요. 그런데… 묘하게 어색합니다. 컴포넌트 하나하나는 멀쩡해요. 버튼은 버튼답고, 카드는 카드답죠. 그런데 전체를 보면 "생성된 티" 가 납니다. UI를 찍은 스톡 사진 같달까요.

저도 한동안은 "컴포넌트를 더 잘 만들면" 또는 "프롬프트에 감각을 더 넣으면" 해결될 거라 생각했습니다. 아니더군요. 실제 디자인 문헌 — Refactoring UI, Material Design 3, Apple HIG, IBM Carbon, WCAG, Financial Times의 시각 어휘집 — 을 파고들수록 진짜 원인엔 이름이 있었습니다.

정합성(coherence)의 부재.

부품들이 서로 안 맞는 겁니다. 그리고 한번 보이기 시작하면, 다시는 안 보이게 할 수가 없어요.

전에 디자이너 없이 바이브코딩으로 토스급 UI 만드는 법을 다뤘는데, 이번 글은 그 아래의 '왜' — "어색함"의 실제 메커니즘과 그걸 고치는 한 가지 원칙을 팝니다.

증상: 서로 안 맞는 부품들

다음 UI엔 "틀린" 게 하나도 없습니다.

모서리가 각진(2px) 카드
그 안의 알약 모양 버튼
파란 기본 버튼 옆의 보라 "업그레이드" 링크
아이콘: Lucide 아웃라인 2개 + 채워진 이모지 1개
좌상단에서 떨어진 그림자 하나, 정아래에서 떨어진 그림자 하나

하나씩 떼어 보면 전부 정당화됩니다. 그런데 합치면 "부품 조립" 신호가 떠요. 사람 디자이너라면 같은 화면에서 이 결정들을 동시에 내리지 않거든요. 디자이너는 모서리 스타일 하나, 강조색 하나, 아이콘 세트 하나, 광원 하나 를 고르고 — 그걸 어디서나 반복합니다.

그 반복이 우리가 "한 사람이 만든 느낌"으로 읽는 정체입니다. UX Collective의 Goran Paun은 이걸 시각적 정합성이라 부르고, Steve Schoger의 Refactoring UI 전체가 어떤 의미에선 "불필요한 변주를 만들지 마라"는 책이죠. 원칙 자체는 오래됐습니다. 새로운 건 AI가 기본값으로 이걸 깨뜨린다는 점이고, 왜 깨는지를 알면 어떻게 고칠지가 보입니다.

AI가 유독 이걸 못 하는 이유

언어 모델은 UI를 국소적으로(locally) 생성합니다. 카드 쓰고, 버튼 쓰고, 모달 쓰고 — 각각을 그럴듯한 새 조각으로 따로 만들어요. "40줄 위의 버튼이 알약 모양이었으니 이것도 알약이어야 한다"는 기억이 없습니다. 각 컴포넌트는 자기 학습 데이터의 평균값으로 회귀하는데, "버튼의 평균"과 "카드의 평균"은 애초에 서로 맞춰진 적이 없죠.

사람은 이렇게 일하지 않습니다. 우리는 머릿속에 아주 작은 결정 집합 — 이 제품은 둥근 모서리, 파란 강조색, 8px 그리드 — 을 들고 다니고, 새 요소는 전부 그걸 물려받습니다. 그 결정이 끈끈하게(sticky) 따라붙어요.

그래서 해법은 "모델을 더 감각 있게" 가 아닙니다. 그 끈끈한 결정들을 적어두고, 모델에게 새로 만들지 말고 복사하라고 시키는 것 입니다.

메타 법칙: 축마다 값 하나

핵심은 한 문장입니다.

디자인 축마다 값(또는 패밀리)을 하나만 정하고, 토큰으로 박아서, 어디서나 적용한다.

정합성은 "모든 화면이 똑같다"가 아닙니다. 같은 결정이 반복되는 거예요. 설정 페이지와 대시보드는 전혀 다르게 생겨도 — 모서리 personality, 그림자 언어, 강조색, 간격 단위만 공유하면 — 한 제품처럼 느껴집니다.

통일돼야 하는 축들:

축	하나만 정한다	섞이면
모서리/라운드	각짐 0–4px · 부드러움 8–12px · 알약 9999px	각진 다이얼로그 + 둥근 버튼 = "두 제품 붙인 느낌"
그림자	한 스케일, 한 광원(좌상단), 한 색조	"태양이 둘인 장면"
강조색	강조는 1개 (+ 의미색 red/green/amber)	무엇도 그 액션으로 안 읽힘
간격 단위	8px 그리드 하나 (4px 하프스텝)	7/13/19px 같은 오프그리드 = "엉성함"
아이콘	한 패밀리, 한 채움, 한 굵기	세트 섞이면 "겉도는" 느낌
타입 스케일	모듈러 스케일 하나, 폰트 ≤2종	임의 크기가 리듬을 깸
모션	지속시간 세트 하나 + 이징 패밀리 하나	어떤 건 빠릿, 어떤 건 굼떠 = 다른 앱
컨트롤 높이	공유 높이 세트 (예: 40px)	44px 인풋 옆 32px 버튼 = 베이스라인 깨짐

비전공자가 핵심을 가장 잘 찌른 표현:

"모서리를 각지게 했으면 다 각지게 가야지."

정확합니다. 그리고 이건 위 표의 모든 행에 그대로 적용돼요. 축이 섞이는 건 스타일 선택이 아니라 lint 에러로 취급하세요.

이 중 넷을 코드로 구체화해 봅시다.

1. 모서리 personality 하나 (그리고 중첩 법칙)

먼저, 라운드는 토큰이지 매직 넘버가 아닙니다. 작은 스케일을 정의하고 어디서나 참조하세요.

:root {
  --radius-sm: 8px;   /* 인풋, 버튼  */
  --radius-md: 12px;  /* 카드, 메뉴  */
  --radius-lg: 16px;  /* 모달, 시트  */
  --radius-full: 9999px;
}

그다음 personality 하나 — 전부 각지게, 전부 부드럽게, 전부 알약 — 를 골라 카드/버튼/인풋/모달/이미지에 적용합니다. 모델이 rounded-none 패널에 rounded-full 버튼을 멋대로 섞게 두지 마세요.

많이들 놓치는 두 번째 규칙: 중첩된 라운드는 중심을 공유해야 합니다. 둥근 컨테이너 안에 패딩을 두고 둥근 요소가 들어갈 때, 안쪽 반지름은 더 작아야 해요.

안쪽 반지름 = 바깥 반지름 − 패딩

.card {
  --pad: 16px;
  border-radius: var(--radius-lg);          /* 16px */
  padding: var(--pad);
}
.card > .thumbnail {
  /* 16 − 16 = 0; 음수가 안 되게 clamp */
  border-radius: max(0px, calc(var(--radius-lg) - var(--pad)));
}

안쪽 요소에 바깥과 같은 라운드를 주면, 코너가 컨테이너의 호를 비집고 튀어나옵니다. Apple의 새 "Liquid Glass"가 바로 이 동심원 코너 수학을 공식화했고, Cloud Four에 정석 글이 있습니다.

2. 단일 광원의 레이어드 그림자

깊이를 가짜로 보이게 하는 가장 빠른 방법이 단일 하드 box-shadow입니다. 진짜 그림자는 그라데이션(반음영)이라, 낮은 불투명도 레이어를 여러 겹 쌓고 — 결정적으로 — 검정 대신 표면 색조 쪽으로 살짝 틴트하세요. 순수 검정은 탁해집니다.

/* 카드 — 페이지에 가깝게 */
--shadow-md:
  0 1px 2px  hsl(220 40% 20% / 0.08),
  0 2px 4px  hsl(220 40% 20% / 0.08),
  0 4px 8px  hsl(220 40% 20% / 0.08);

/* 모달 — 사용자 쪽으로 떠오르게 */
--shadow-xl:
  0 2px 4px   hsl(220 40% 20% / 0.06),
  0 8px 16px  hsl(220 40% 20% / 0.06),
  0 16px 32px hsl(220 40% 20% / 0.06),
  0 32px 64px hsl(220 40% 20% / 0.06);

정합성 규칙: 페이지 전체가 한 광원 (관례상 위 + 약간 왼쪽), 수직 오프셋은 수평의 약 2배. 고도가 올라가면 오프셋·블러는 커지고 불투명도는 낮아집니다. 그러면 카드와 모달이 같은 빛이 다른 높이의 물체에 닿은 걸로 읽혀요 — 별개의 두 효과가 아니라. (Josh Comeau, Tobias Ahlin 글이 좋습니다.)

다크 모드에선 그림자가 거의 안 보이므로 톤 기반 고도로 전환하세요 — 높을수록 밝은 표면. 베이스는 절대 순수 #000 금지(Material은 #121212 + 레벨별 화이트 오버레이 권장).

3. 강조색 하나, 나머지는 그레이스케일

"AI 무지개" UI는 대개 강조가 필요할 때마다 새 색을 꺼내 써서 생깁니다. 규율:

상호작용 강조는 하나의 강조색.
텍스트·표면·테두리는 틴트된 그레이 램프 (순수 회색 말고 — 브랜드 색조 쪽으로 5–15% 밀기).
의미색은 딱 넷 — success / warning / error / info — 이고 오직 의미로만, 장식으로는 절대 안 씀.

:root {
  --accent: #5b5bd6;
  /* 채도 0 회색이 아니라 강조색 쪽으로 살짝 틴트 */
  --grey-50:  hsl(240 20% 98%);
  --grey-200: hsl(240 14% 90%);
  --grey-500: hsl(240 8%  55%);
  --grey-900: hsl(240 12% 14%);  /* 본문 텍스트 — #000 아님 */
}

그리고 타협 불가 접근성 하한선(WCAG 2.2 AA): 본문 텍스트 4.5:1, 큰 텍스트·UI 요소 3:1. 정보를 색으로만 전달 금지 — 아이콘·텍스트·형태와 함께. 유효성 실패 필드에 빨간 테두리만으론 부족하고, 아이콘과 메시지를 같이 넣으세요.

4. 간격 그리드 하나, 그룹핑은 근접성으로

모든 margin·padding·gap을 한 스케일 — 4, 8, 12, 16, 24, 32, 48, 64 — 에 스냅하고, 근접성이 의미를 나르게 하세요. Gestalt(그리고 Refactoring UI의 "모호한 간격을 피하라")의 규칙: 그룹 바깥 공간이 그룹 안 공간보다 확실히 커야 합니다.

폼의 구체적 사다리:

라벨 → 인풋        : 4–8px
인풋 → 인풋         : 12–16px
그룹 → 그룹 (섹션)  : 24–32px

전부 균일하게 띄우면 눈이 무엇이 한 덩어리인지 알 수 없습니다. 단계마다 두 배로 벌어지는 게, 라벨이 자기 필드에 붙고 섹션이 다음 섹션과 분리되게 만드는 핵심이에요.

기계가 스스로 점검하게

결정을 적어두는 게 절반이고, 나머지 절반은 위반을 잡는 겁니다. 여기서 AI가 실제로 쓸모 있어요 — 채점 기준만 쥐여주면.

저는 위 내용을 Claude Code·Cursor가 자동으로 읽는 오픈소스 디자인 엔진(StyleSeed)에 넣지만, 아이디어 자체는 도구 무관입니다. 가장 쓸모 있던 조각은 정합성 채점기 — 파일을 점수화하고 섞인 축을 실제 감점으로 잡는 검사였습니다.

출력 예시(축약):

## Design Score: 70 / 100   (Dashboard.tsx)

Color discipline   13/18  ▓▓▓░  #000 제목; 강조색 3개
Cards & elevation   8/12  ▓▓░░  1px 테두리가 분리를 담당
Coherence           6/12  ▓▓░░  각진 카드(l.22) + 알약 버튼(l.48); 강조 3개

### 먼저 고칠 것 (점수 이득 큰 순)
1. 라운드 통일(부드러움 8–12px) + 강조색 1개로  → +9
2. 주문 리스트에 empty + loading 상태 추가       → +7
3. 1px 테두리 빼고 톤 + ≤8% 그림자               → +4

"Coherence" 항목이 "AI 생성 티"를 가장 잘 예측합니다. 컴포넌트별 예쁨이 아니라 전역 일관성을 재기 때문이에요. 컴포넌트는 예뻐도 틀릴 수 있습니다 — 이웃과 안 맞으면.

결론

하나만 기억한다면:

예쁜 부품이 예쁜 UI를 만들지 않습니다. 서로 맞는 부품이 만듭니다.

축마다 값 하나 — 라운드, 그림자, 강조색, 간격, 아이콘, 타입, 모션 — 를 골라 토큰으로 적어두고, 새 요소가 매번 새로 고르는 대신 그걸 물려받게 하세요. 그 한 가지 규율이 "로봇이 만들었네"와 "디자이너가 만들었네"를 가르고, AI가 만든 인터페이스에 할 수 있는 가장 싸고 효과 큰 일입니다.

모서리가 각지다고요? 그럼 전부 각지게. 끝까지.

숫자까지 들어간 풀버전 — 간격 수치, 앱 종류별 타입 레시피, 레이어드 그림자·중첩 라운드 레시피, 전부 Refactoring UI / Material 3 / Apple HIG / WCAG 근거 — 은 오픈소스(MIT)로 여기 있습니다: github.com/bitjaru/styleseed. ⭐ 하나가 더 많은 개발자(와 AI 도구)에게 닿게 합니다.

🇬🇧 The English version of this post is here.

Why AI-Generated UIs Look 'Off' — and the One Principle That Fixes It

@kiwibreaksme — Tue, 16 Jun 2026 04:33:17 +0000

🇰🇷 한국어 버전: AI가 만든 UI가 어딘가 '어색한' 이유

You've seen it. You ask an AI to build a dashboard, and it returns something that's… fine? Every component is individually competent. The button is a button. The card is a card. And yet the whole thing reads as generated — like a stock photo of a UI.

For a long time I assumed the fix was "better components" or "more taste in the prompt." It isn't. After digging through the actual design literature — Refactoring UI, Material Design 3, Apple's HIG, IBM Carbon, WCAG, the Financial Times' visual vocabulary — the real culprit has a name:

Incoherence.

The parts don't agree with each other. And once you can see it, you can't unsee it.

I've written before about why your vibe-coded app looks ugly and what I did about it. This post goes underneath that — the actual mechanism behind the "off" feeling, and the one principle that fixes it.

The tell: parts that don't agree

Here's a UI with nothing "wrong" in it:

A card with sharp 2px corners
Pill-shaped buttons inside it
A blue primary action next to a purple "upgrade" link
Icons: two from Lucide (outline), one filled emoji
One shadow lit from the top-left, another from straight below

Every one of those choices is defensible in isolation. Together, they signal "assembled from parts," because a human designer would never make all of them on the same screen. A designer picks one corner style, one accent, one icon set, one light source — and repeats those decisions everywhere.

That repetition is what we read as "designed by one mind." Goran Paun (UX Collective) calls it visual coherence; Steve Schoger's whole Refactoring UI is, in a sense, a book about not introducing gratuitous variation. The principle is old. What's new is that AI breaks it by default, and understanding why tells you how to fix it.

Why AI specifically struggles with this

A language model generates UI locally. It writes the card, then the button, then the modal — each as a fresh, plausible snippet. It has no running memory that "the buttons 40 lines up were pill-shaped, so these must be too." Each component regresses to the mean of its training data, and the mean of "a button" and the mean of "a card" were never coordinated.

Humans don't work this way. We carry a tiny set of decisions in our head — this product is soft-cornered, blue-accented, 8px-grid — and every new element inherits them. The decisions are sticky.

So the fix isn't "make the model more tasteful." It's: write the sticky decisions down, and tell the model to copy them instead of inventing new ones.

The meta-law: one choice per axis

Here's the whole idea in one sentence:

For each design axis, pick exactly one value or family, encode it as a token, and apply it everywhere.

Coherence is not "every screen is identical." It's that the same decisions recur. A settings page and a dashboard can look very different and still feel like one product — as long as they share a radius personality, a shadow language, an accent, and a spacing unit.

These are the axes that have to stay unified:

Axis	Pick ONE, system-wide	Failure mode when mixed
Corner / radius	sharp 0–4px · soft 8–12px · pill 9999px	sharp dialog + rounded buttons = "two products glued together"
Shadow	one scale, one light source (above-left), one tint	"a scene with two suns"
Accent color	one accent for emphasis (+ semantic red/green/amber)	nothing reads as the action
Spacing unit	one 8px grid (4px half-step)	off-grid 7/13/19px reads as "sloppy"
Icon style	one family, one fill mode, one stroke weight	mixing sets looks "out of place"
Type scale	one modular scale, ≤2 families	arbitrary sizes destroy rhythm
Motion	one duration set + one easing family	some snappy, some sluggish = different apps
Control height	shared height set (e.g. 40px)	a 44px input beside a 32px button breaks the baseline

The single best instinct I've heard a non-designer voice it as:

"If the corners are sharp, everything should be sharp."

Exactly right — and it generalizes to every row in that table. Treat a mixed axis as a lint error, not a style choice.

Let's make four of these concrete.

1. Pick one corner personality (and respect the nesting law)

First, radius is a token, never a magic number. Define a small scale and reference it everywhere:

:root {
  --radius-sm: 8px;   /* inputs, buttons   */
  --radius-md: 12px;  /* cards, menus      */
  --radius-lg: 16px;  /* modals, sheets    */
  --radius-full: 9999px;
}

Then pick one personality — all sharp, all soft, or all pill — and apply it across card / button / input / modal / image. Don't let the model freestyle a rounded-none panel with rounded-full buttons.

There's a subtle second rule most people miss: nested radii must share a center. When a rounded element sits inside a rounded container with padding, the inner radius should be smaller:

inner radius = outer radius − padding

.card {
  --pad: 16px;
  border-radius: var(--radius-lg);          /* 16px */
  padding: var(--pad);
}
.card > .thumbnail {
  /* 16 − 16 = 0; clamp so it never goes negative */
  border-radius: max(0px, calc(var(--radius-lg) - var(--pad)));
}

If you give the inner element the same radius as the outer one, its corner visibly bulges past the container's arc. Apple's new "Liquid Glass" system formalizes exactly this concentric-corner math; Cloud Four has the canonical write-up.

2. Layered shadows from a single light source

The fastest way to make depth look fake is one hard box-shadow. Real shadows are a gradient (a penumbra), so stack several low-opacity layers, and — critically — tint them toward the surface hue instead of using pure black, which goes muddy:

/* card — sits near the page */
--shadow-md:
  0 1px 2px  hsl(220 40% 20% / 0.08),
  0 2px 4px  hsl(220 40% 20% / 0.08),
  0 4px 8px  hsl(220 40% 20% / 0.08);

/* modal — floats toward the user */
--shadow-xl:
  0 2px 4px   hsl(220 40% 20% / 0.06),
  0 8px 16px  hsl(220 40% 20% / 0.06),
  0 16px 32px hsl(220 40% 20% / 0.06),
  0 32px 64px hsl(220 40% 20% / 0.06);

The coherence rule: one light direction for the whole page (convention: above and slightly left), with vertical offset roughly 2× the horizontal. As elevation rises, offset and blur go up while opacity goes down. A card and a modal then read as the same light hitting objects at different heights — not two unrelated effects. (Josh Comeau and Tobias Ahlin both have excellent deep-dives on this.)

In dark mode, shadows nearly vanish, so switch to tonal elevation — lighter surfaces for higher elevation — and never use pure #000 as your base (Material recommends #121212 with white overlays per level).

3. One accent, everything else greyscale

Most "AI rainbow" UIs come from reaching for a new hue every time something needs emphasis. The discipline:

One accent for interactive emphasis.
A full tinted-grey ramp (not pure grey — nudge it 5–15% toward the brand hue) for text, surfaces, and borders.
Only four semantic colors — success / warning / error / info — used strictly by meaning, never decoration.

:root {
  --accent: #5b5bd6;
  /* greys tinted slightly toward the accent's hue, not 0-saturation */
  --grey-50:  hsl(240 20% 98%);
  --grey-200: hsl(240 14% 90%);
  --grey-500: hsl(240 8%  55%);
  --grey-900: hsl(240 12% 14%);  /* body text — NOT #000 */
}

And one accessibility floor you don't get to negotiate (WCAG 2.2 AA): 4.5:1 contrast for body text, 3:1 for large text and UI components. Never convey information by color alone — pair it with an icon, text, or shape. A red border on an invalid field is not enough; add the icon and the message.

4. One spacing grid, with proximity doing the grouping

Snap every margin, padding, and gap to a single scale — 4, 8, 12, 16, 24, 32, 48, 64 — and let proximity carry meaning. The rule from Gestalt (and Refactoring UI's "avoid ambiguous spacing"): the space around a group must be clearly larger than the space within it.

A concrete ladder for forms:

label → input        : 4–8px
input → input         : 12–16px
group → group (section): 24–32px

When everything is evenly spaced, the eye can't tell what belongs together. The doubling at each level is what makes a label bind to its field and a section separate from the next.

Make the machine check itself

Writing the decisions down is half the battle; the other half is catching violations. This is where AI can actually help — if you give it the rubric.

I bake all of the above into an open-source design engine (StyleSeed) that Claude Code and Cursor read automatically, but the idea is tool-agnostic. The most useful piece turned out to be a coherence grader: a check that scores a file and flags mixed axes as real deductions.

A trimmed example of what that output looks like:

## Design Score: 70 / 100   (Dashboard.tsx)

Color discipline   13/18  ▓▓▓░  #000 headings; 3 accent hues
Cards & elevation   8/12  ▓▓░░  1px borders doing separation
Coherence           6/12  ▓▓░░  sharp cards (l.22) + pill buttons (l.48); 3 accents

### Fix first (highest score gain)
1. Unify radius (pick soft 8–12px) + collapse to one accent  → +9
2. Add empty + loading states to the orders list            → +7
3. Drop 1px borders, use tone + ≤8% shadow                  → +4

The "Coherence" category is the one that most predicts "looks AI-generated," precisely because it measures system-wide consistency rather than per-component prettiness. A component can be beautiful and still wrong — if it disagrees with its neighbors.

The takeaway

If you remember one thing:

Beautiful parts don't make a beautiful UI. Agreeing parts do.

Pick one value per axis — radius, shadow, accent, spacing, icons, type, motion — write it down as a token, and make every new element inherit it instead of inventing a fresh choice. That single discipline is the difference between "a robot made this" and "a designer made this," and it's the cheapest, highest-leverage thing you can do for an AI-built interface.

The corners are sharp? Then everything is sharp. All the way down.

Want the practical side? I covered the one-file fix that makes your vibe-coded app stop looking ugly in a companion post. And the full research-backed version — concrete spacing numbers, a type recipe per app type, layered-shadow and nested-radius recipes, all grounded in Refactoring UI / Material 3 / Apple HIG / WCAG — is open source (MIT): github.com/bitjaru/styleseed. A ⭐ helps more devs (and more AI tools) find it.

Your vibe-coded app looks ugly. Here's the one-file fix.

@kiwibreaksme — Tue, 14 Apr 2026 03:59:47 +0000

Let's be honest about vibe coding

You tell Claude Code "build me a SaaS dashboard." Thirty seconds later you have a working app. Revenue chart, user table, activity feed. Everything functional.

And it looks like every other AI-generated app on the internet.

Spacing that doesn't breathe. Seven accent colors fighting for attention. Cards that float on the page with zero separation from the background. The components are all shadcn — the technical stack is fine. But the result is amateur.

I spent a week trying to fix this through prompts. "Use only one accent color." "Card background #FFF, page background #FAFAFA." "Smaller shadows." Every fix worked for one screen, then the next screen forgot.

Then it clicked: the model doesn't need better prompts. It needs a design brain.

Pro designers aren't using better components — they're using invisible rules

Ask a senior designer why their dashboard looks refined and they'll say things like:

"Never use pure black. Use #2A2A2A."

"One accent color per app. Everything else grayscale."

"Shadows at 4% opacity. If you can see it, it's already too much."

Nobody writes these down. They're baked into years of experience, invisible to outsiders — which means invisible to LLMs. No matter how many shadcn components Claude has in its training data, it has never been told when to use which.

So I sat down and extracted 69 of these rules from Toss, Stripe, Linear, and Vercel — the brands whose output I wanted Claude to imitate — and wrote them into a single DESIGN-LANGUAGE.md file that Claude reads automatically.

The 69 rules, organized

The rules cluster into six groups:

Color discipline (12 rules) — #2A2A2A as the refined black, 5-level grayscale (#2A → #3C → #6A → #7A → #9B), one accent color maximum, no pure white on pure white.
Spatial rhythm (14 rules) — never repeat the same section type consecutively, alternate tall/compact, 2:1 number-to-unit ratios (48px value, 24px unit).
Information hierarchy (9 rules) — card/background separation (#FFF card on #FAFAFA page) matters more than any border, density increases as you scroll down, top is big numbers, bottom is dense lists.
Shadow & elevation (8 rules) — max 4% opacity, elevation is never z-index, dark mode replaces shadows with borders.
Component variance (11 rules) — never 4 identical KPI cards, stagger content types (2 with trend, 1 with progress, 1 with comparison), avoid "filled form of sameness."
Motion & feedback (15 rules) — 200ms normal, spring for entrance, ease-out for exit, hover lifts by 6px max, tap scales to 0.98.

Drop the file into a project, Claude reads it, Cursor reads it (via .cursorrules). Same prompt, same model — the output quality jumps.

One rule, unpacked

Take the #2A2A2A rule. Pure #000 on #FFF has a contrast ratio of 21:1 — the highest possible. Sounds like a win. But at that contrast the eye gets fatigued fast, and the text starts to feel harsh and heavy on a white page.

#2A2A2A drops the contrast to about 15:1. Still WCAG AAA for body text. But the page stops "vibrating." Every refined design system in the last decade — Apple, Linear, Vercel, Notion, Toss — uses a softened near-black for body text. Claude picks #000 by default because it's the highest-contrast option, which is technically correct and aesthetically wrong.

One rule. Fixes thousands of screens.

Now multiply that by 69.

Same component, three brand DNAs

The live demo up top is a real app — styleseed-demo.vercel.app. Click the Toss / Raycast / Arc switcher. Same chat component, three totally different brand identities — colors, radius, shadows, motion durations, gradients, even the phone frame's ambient light.

The switcher flips a single data-skin attribute on the wrapper. That's it. No conditional rendering, no theme provider, no re-mount.

How it actually works

Every visual value is a CSS variable scoped to [data-skin="..."]:

[data-skin="toss"] {
  --brand: #3182F6;
  --radius: 0.875rem;
  --shadow-card: 0 1px 3px rgba(0,0,0,0.04);
  --gradient-brand: linear-gradient(135deg, #3182F6, #4A90F7);
  --duration-normal: 200ms;
}

[data-skin="raycast"] {
  --brand: #FF4E8B;
  --radius: 0.5rem;
  --shadow-card: 0 0 0 1px rgba(255,255,255,0.05),
                 0 8px 24px rgba(0,0,0,0.4);
  --gradient-brand: linear-gradient(135deg, #FF6363, #FF8E3C 30%,
                    #E84A8E 65%, #A855F7);
  --duration-normal: 220ms;
}

Components never touch the raw values — only the tokens:

<motion.div
  style={{
    background: "var(--card)",
    borderRadius: "var(--radius-xl)",
    boxShadow: "var(--shadow-card)",
  }}
/>

Swap the data attribute → the entire tree morphs in one frame. Framer Motion animates the transitions for free because the underlying CSS properties are inherited.

This is the trick the 69 rules depend on. Rules reference semantic tokens (--brand, --card, --shadow-card), not literal values. So the same rulebook works whether your app looks like Toss or Vercel or your client's weird purple brand.

Why this matters for vibe coders

The point of vibe coding is shipping fast. The problem with vibe coding is the output screams "I was made in 30 minutes."

StyleSeed closes that gap in two moves:

The 69 rules fix the judgment. Claude stops picking #000 for text and py-4 for everything. The output starts looking designed, not generated.
The token structure fixes the brand. Your MVP can ship with Toss skin today and re-skin to a client's brand tomorrow by swapping one file. Same codebase. Zero rewrites.

Both drop in with one command. Engine is brand-agnostic — the rules don't know what color your brand is.

Stack

Next.js 16 (App Router, Turbopack)
Tailwind CSS v4 (the @theme inline syntax makes token sharing trivial)
Framer Motion for the morph animation
Radix under the components
Free, MIT

Try it

🎬 Live demo: styleseed-demo.vercel.app
⭐ GitHub: bitjaru/styleseed
📚 11 Claude Code slash commands included (/ss-page, /ss-review, /ss-audit, ...). Works with Cursor.

If you're vibe coding anything right now, drop the engine in and compare the output. Honest critique on the rules themselves very welcome — which one feels wrong? Which one's missing? The components are downstream. The rules are the actual product.

Your Vibe-Coded App Looks Ugly. Here's What I Did About It.

@kiwibreaksme — Thu, 09 Apr 2026 06:26:23 +0000

Again. Not pretty.

I asked Claude Code to build a dashboard. It worked perfectly. And it looked like a hackathon project.

Card spacing was random. Typography had no hierarchy. Colors were everywhere. The whole thing felt... off.

I tried "make it more professional." Didn't help. Tried "like the Toss app." Slightly better, but still amateur.

The problem wasn't the AI. The AI makes great components. It just can't make design decisions.

What I Mean

Open the Toss app (Korea's biggest fintech) and look closely. Every screen feels the same. Not boring-same — cohesive-same. I spent a while figuring out why.

There are rules.

The darkest black isn't #000. It's #2A2A2A. Tiny difference. But that's the gap between "harsh" and "refined."

There's exactly one accent color in the entire app. One. Everything else is grayscale. Restraint is what makes it feel expensive.

Card shadows? 4% opacity. If you can see the shadow, it's already too much.

Numbers at 48px, units at 24px. Always 2:1. Your eye hits the number first.

Designers make these calls instinctively. Years of experience. But here's the thing — if you write them down, AI can follow them too.

So I Wrote Them Down

I was building my own app and got tired of fixing ugly AI output. Started asking myself "why does this look bad?" for every screen. Patterns emerged. Same mistakes, every time.

So I documented the judgment calls a designer would make. Ended up with 69 rules.

Like:

Never use the same card layout twice in a row. Hero, then grid, then chart, then list. There needs to be rhythm.

When you make 4 KPI cards, don't make them identical. Two with trend arrows, one with a progress bar, one with comparison text. Variation keeps it from feeling robotic.

As you scroll down, text gets smaller and information gets denser. Hero is one big 48px number. Bottom of the page is 14px detail rows. Natural zoom-in effect.

I packaged these rules so AI could read them.

Engine + Skins

The structure is kind of fun.

styleseed/
├── engine/    ← Design brain (69 rules, 48 components, 11 AI skills)
└── skins/     ← Brand colors (Toss, Stripe, Linear, Vercel, Notion...)

The engine knows how to structure your app. Layout, typography ratios, card structure, visual rhythm, forbidden patterns. Doesn't care what brand you are.

A skin is one CSS file. --brand: #533afd makes it Stripe. --brand: #721FE5 makes it Toss. Change one variable, whole UI follows.

awesome-design-md has 58 brand identities you can grab as skins.

How I Actually Use It

Step 1. Copy the engine.

cp -r styleseed/engine/* my-project/
cp -r styleseed/engine/css/* my-project/src/styles/

Step 2. Pick a skin.

cp styleseed/skins/stripe/theme.css my-project/src/styles/theme.css

Or run /ui-setup and it walks you through everything — app type, colors, font, generates your first page.

Step 3. Build.

Build me a SaaS dashboard.

AI reads CLAUDE.md automatically. Follows the 69 rules. Lays out hero card, KPI grid, chart section, activity list in information-pyramid order.

But it doesn't stop there.

/ux-audit src/Dashboard.tsx    # Nielsen's heuristics check
/ux-copy "dashboard"           # Auto-generate button labels, error messages
/ux-feedback src/Dashboard.tsx  # Add loading/error/empty states
/ui-review src/Dashboard.tsx    # Design compliance check

Four commands that do what a designer + UX researcher would do. Felt like cheating, honestly.

Why It Feels Cohesive

Why does the Toss app feel like "one app" no matter what screen you're on?

Because one team's consistent judgment is applied everywhere. "This spacing is 24px." "Don't use that color." "Numbers are this size." Same rules, every screen, every time.

StyleSeed is those rules, written as 69 lines of design judgment. AI reads them. Every page it builds follows the same standard.

Swap the skin — Stripe, Vercel, whatever — the structure stays consistent. Same engine.

Honestly

It's not perfect. Mobile-only (430px) for now. Desktop layouts need separate work. Charts need manual Recharts setup. I'm still adding rules and refining.

But the difference between before and after is obvious. "It looks bad but I don't know how to fix it" turned into "it just comes out clean."

No designer. Five minutes of setup.

Star on GitHub

MIT open source. Built for my own app, sharing because it might save you the same headache.

디자이너 없이 바이브코딩으로 토스급 UI 만드는 법

@kiwibreaksme — Thu, 09 Apr 2026 06:25:56 +0000

또. 이쁘지가 않다.

Claude Code한테 "대시보드 만들어줘" 했더니 기능은 되는데 화면이 영 아마추어다. 카드 간격이 제각각이고, 색이 정리가 안 되고, 전체적으로 뭔가... 촌스럽다.

"좀 더 깔끔하게" 해봤자 달라지는 게 없다. 좀 더 구체적으로 "토스처럼" 해봤자 비슷하다. AI가 토스를 모르는 게 아니다. 컴포넌트도 잘 만든다.

근데 디자인 판단을 못 한다.

무슨 말이냐면

토스 앱을 켜서 찬찬히 보면, 화면마다 같은 "느낌"이 있다. 그 느낌의 정체가 뭔지 뜯어봤다.

규칙이 있다.

가장 어두운 검정이 #000이 아니라 #2A2A2A다. 미세한 차인데, 이게 "딱딱함"과 "고급스러움"의 차이다.

강조 색은 앱 전체에서 딱 하나. 보라 하나. 나머지는 전부 회색 톤이다. 절제가 고급이다.

카드 그림자? opacity 4%다. 그림자가 눈에 보이면 이미 과하다.

숫자는 48px로 크게, 단위는 24px로 작게. 항상 2:1. 시선이 숫자에 먼저 간다.

디자이너는 이런 판단을 무의식적으로 내린다. 경험으로 쌓인 거다. 근데 이걸 글로 정리하면? AI도 따라할 수 있다.

그래서 정리했다

내 앱 만들면서 AI가 뱉는 UI를 고치다 지쳤다. "이건 왜 구려 보이지?"를 분석하다 보니 패턴이 보였다. 같은 실수가 반복됐다.

그래서 디자이너가 머릿속에 갖고 있는 판단 기준을 하나씩 글로 적었다. 69개가 됐다.

예를 들면:

같은 카드 레이아웃을 연속으로 두 번 쓰지 마라. 히어로 다음에 그리드, 그리드 다음에 차트, 차트 다음에 리스트. 리듬이 있어야 한다.

KPI 카드 4개를 만들 때 전부 똑같이 만들지 마라. 트렌드 화살표 2개, 프로그레스바 1개, 비교 텍스트 1개. 변주가 있어야 단조롭지 않다.

위에서 아래로 갈수록 글씨가 작아지고 정보가 빽빽해진다. 히어로는 48px 하나, 맨 아래 리스트는 14px 여러 줄. 자연스러운 줌인 효과.

이 규칙들을 AI가 읽을 수 있게 패키징했다.

엔진 + 스킨

구조가 좀 재밌다.

styleseed/
├── engine/    ← 디자인 두뇌 (규칙 69개, 컴포넌트 48개, AI 스킬 11개)
└── skins/     ← 브랜드 컬러 (토스, Stripe, Linear, Vercel, Notion...)

엔진은 "어떻게 구성할지"를 안다. 레이아웃, 타이포 비율, 카드 구조, 시각적 리듬, 금지 패턴. 브랜드 색이 뭐든 상관없이 동작한다.

스킨은 CSS 파일 하나다. --brand: #533afd 하면 Stripe, --brand: #721FE5 하면 토스. 색만 바꾸면 전체 UI가 따라 바뀐다.

awesome-design-md에 58개 브랜드가 있는데, 거기서 아무거나 골라서 스킨으로 쓸 수 있다.

실제로 쓰는 과정

1단계. 엔진을 내 프로젝트에 복사한다.

cp -r styleseed/engine/* my-project/
cp -r styleseed/engine/css/* my-project/src/styles/

2단계. 스킨을 고른다.

cp styleseed/skins/stripe/theme.css my-project/src/styles/theme.css

귀찮으면 /ui-setup 치면 하나씩 물어보면서 세팅해준다. 앱 종류, 색상, 폰트, 첫 페이지까지.

3단계. 만든다.

SaaS 대시보드 만들어줘.

AI가 CLAUDE.md를 자동으로 읽는다. 69개 규칙에 따라 히어로 카드, KPI 그리드, 차트 섹션, 리스트를 정보 피라미드 순서로 배치한다.

여기서 끝이 아니다.

/ux-audit src/Dashboard.tsx    # 닐슨 10대 원칙으로 UX 점검
/ux-copy "대시보드"             # 버튼 라벨, 에러 메시지 자동 생성
/ux-feedback src/Dashboard.tsx  # 로딩/에러/빈 상태 추가
/ui-review src/Dashboard.tsx    # 디자인 규칙 준수 검사

솔직히 좀 사기다 싶었다. 디자이너 + UX 리서처가 하는 일을 명령어 4개로.

통일감의 비결

왜 토스 앱은 어떤 화면을 열어도 "같은 앱" 느낌이 날까.

한 사람(또는 한 팀)의 머릿속에 일관된 기준이 있기 때문이다. "이 간격은 24px", "이 색은 쓰지 마", "숫자는 이 크기" — 이 기준이 모든 화면에 적용되니까 통일감이 생긴다.

StyleSeed는 그 기준을 69개 규칙으로 적어놓은 거다. AI가 이걸 읽으면, 어떤 페이지를 만들든 같은 기준으로 만든다.

스킨이 바뀌어도 구조는 안 바뀐다. Stripe든 Vercel이든 — 엔진이 동일하니까.

솔직히 말하면

완벽하지는 않다. 아직 모바일(430px) 전용이고, 데스크톱 레이아웃은 별도로 짜야 한다. 차트도 Recharts 직접 세팅해야 한다. 계속 규칙 추가하면서 다듬는 중이다.

근데 확실한 건 — 이거 쓰기 전과 후가 확연히 다르다. "구려 보이는데 뭘 고쳐야 할지 모르겠다"에서 "알아서 깔끔하게 나온다"로.

디자이너 고용비 0원. 세팅 5분.

GitHub에서 보기

MIT 오픈소스다. 쓸만하면 스타 하나 부탁.

당신이 AI를 잘 못 쓰는 이유, 메타인지 훈련

@kiwibreaksme — Thu, 26 Feb 2026 04:55:20 +0000

AI랑 일 잘하는 법 — 1편

먼저 말해두면, 이 글은 프롬프트 템플릿 모음이 아니다. "이렇게 물어보세요~" 하는 글은 이미 넘쳐난다. 이 글은 그보다 한 단계 아래에 있는 얘기를 한다. 생각하는 방식 얘기다. 그리고 이게 바뀌면 AI 결과물만 좋아지는 게 아니라, 본인이 성장한다. 진짜로.

지난주에 팀 회식을 해야 했다.

귀찮아서 AI한테 물어봤다. "강남역 근처 고깃집 추천해줘."

5곳을 뽑아줬다. 리뷰 좋고, 분위기 좋고, 가격도 적당하다고 했다. 예약 팁까지 줬다. 친절하다.

첫 번째 가게를 네이버에 검색해봤다. 3개월 전에 폐업했다.

두 번째는 이름이 바뀌어 있었다. 세 번째는 별 1개 테러를 맞고 있었다.

동료한테 얘기했더니 반응이 두 가지였다.

"역시 AI는 쓸모없네."
"그걸 왜 AI한테 물어봐 ㅋㅋ"

둘 다 핵심을 모르는 거다.

AI가 문제가 아니다. 물어보는 방식이 문제다.

그러면 어떻게 물어봤어야 하나

애초에 "고깃집 추천해줘"가 잘못된 질문이다.

❌ 보통 사람의 질문

"강남역 근처 회식하기 좋은 고깃집 추천해줘"
→ AI가 5곳 추천 → 첫 번째가 폐업 → "AI 별로네"

✅ 이렇게 물어봤어야 한다

1단계 — 기준부터 잡기:

"회사 회식할 때 직원들 만족도가 높은 음식점 유형이 뭐야? 인원수, 분위기, 메뉴 선택지 같은 요소별로 정리해줘."

AI가 판단 기준을 먼저 정리해준다. 고깃집이 무난하긴 한데, 채식하는 사람 있으면 한정식이 낫고, 10명 넘으면 룸 있는 데가 좋고. 이런 거.

2단계 — 조건 넣기:

"우리 팀 8명이고, 고기파 많고, 강남역 도보 10분 이내. 후보 뽑아줘"

3단계 — 결과는 내가 검증:
네이버 지도에서 영업 중인지, 리뷰는 어떤지 직접 확인한다. 이건 사람이 해야 하는 영역이다.

(더 미친 사람은 AI한테 네이버 지도 데이터를 직접 물려줘서, 영업 중인 가게만 자동으로 걸러내게 한다. 이것도 나중에 다룬다.)

"추천해줘" 한 마디로 끝내는 거랑, 기준 잡고 → 조건 넣고 → 결과를 내가 검증하는 거랑은 완전히 다른 행위다.

💡 여기서 한 가지 더. 반대로 생각하면 재밌다. 사람들이 구글 대신 AI한테 "추천해줘"를 점점 더 많이 하고 있다. 가게 입장에서는? 구글에 잘 걸리는 게 중요했는데, 이제는 AI가 추천하는 리스트에 들어가는 게 중요해졌다. 이걸 'AI SEO'라고 부르기 시작했다. 이것도 다른 편에서 다룬다.

대부분이 이렇게 쓰고 있다

ChatGPT, Claude, Gemini. 한 번쯤은 써봤을 거다.

근데 대부분 이렇게 쓴다.

"OO해줘." → 결과 받음 → 끝.

자기소개서 써줘. 이메일 번역해줘. 여행 계획 세워줘. 한 번 물어보고 한 번 받고 끝이다.

좋으면 "AI 대단하다." 별로면 "AI 별로네." 이게 전부다.

이건 구글 검색이랑 같은 거다. 검색창에 키워드 넣고 첫 번째 결과 클릭하는 거.

AI는 검색엔진이 아니다. 전지전능한 신은 더더욱 아니다.

근데 신한테 소원 빌듯이 한 줄 던지고 기적을 기대한다.

기적은 안 일어난다.

Meta의 AI 안전 전문가도 당했다

최근에 딱 맞는 사건이 있었다.

요즘 IT업계에서 제일 핫한 게 OpenClaw라는 AI 도구다. 내 컴퓨터에서 직접 돌면서 코딩도 하고, 웹 리서치도 하고, 이메일 정리하고, 파일 관리에 시스템 자동화까지 한다. 챗봇이 아니라 내 컴퓨터를 직접 조작하는 수준이다. 맥미니가 품귀될 정도로 난리가 났고, 만든 개발자를 OpenAI가 영입하면서 더 난리가 났다.

그런데 Meta에서 AI 안전을 담당하는 연구원이 이걸 쓰다가 사고가 났다.

AI가 사고 안 치게 하는 게 직업인 사람이다.

이 사람이 OpenClaw한테 이메일 정리를 시켰다. "이메일 정리할거 정리해줘. 직접 지우지는 마." 이렇게 말했다.

AI가 그 말을 무시하고 이메일을 전부 삭제했다.

폰으로 "멈춰!" 두 번 외쳤다. 무시당했다. 맥미니까지 달려가서 강제로 껐다.

⚠️ AI 안전이 직업인 사람한테 벌어진 일이다. 네이버, 카카오, 당근이 OpenClaw 사내 사용을 금지한 것도 같은 이유다. AI가 나쁜 게 아니라, 뭘 할 수 있고 뭘 못하는지를 모른 채 쓰면 사고가 나는 거다.

교훈은 "AI가 무섭다"가 아니다.

내가 먼저 파악했어야 한다. 그게 전부다.

이름은 거창한데 별거 아니다

이걸 학문적으로는 '메타인지(Metacognition)'라고 부른다. 이름이 좀 있어 보인다.

실체는 별거 아니다.

내가 뭘 알고, 뭘 모르고, AI가 뭘 잘하고 뭘 못하는지. 이걸 한 번 생각해보는 거다.

그게 끝이다.

회식장소 물어보기 전에 0.5초만 생각하면 된다.
"영업 중인지는 AI가 모를 수 있겠다. 후보만 받고 확인은 내가 하자."

이메일 정리시키기 전에 3초만 생각하면 된다.
"얘가 내 말을 100% 따를까? 잘못되면 되돌릴 수 있나? 테스트용으로 먼저 해볼까?"

이 0.5초짜리 생각 하나가, AI를 잘 쓰는 사람과 못 쓰는 사람을 가른다.

근데 여기서 끝이 아니다.

0.5초 생각하고 한 번 잘 물어보면 끝? 아니다. 한 번 물어보고 끝나는 게 아니라, 계속 주고받는 거다. AI가 답을 주면 거기서 "이건 맞는 것 같은데, 이건 아닌데?" 하고 다시 물어본다. AI가 모를 수 있는 부분을 내가 채워주고, 내가 모르는 부분을 AI한테 다시 물어본다. 이걸 5번, 10번, 필요하면 20번 반복한다.

이게 티키타카다. 좋은 첫 질문 하나로 끝나는 게 아니라, 끊임없이 주고받으면서 결과물을 같이 만들어가는 과정이다.

프롬프트 엔지니어링 강의 같은 거 안 들어도 된다. 좋은 질문 하나를 외울 필요도 없다. 계속 대화하면 된다.

실제로 어떻게 다른지 보여주겠다

🔹 사업을 구상할 때

사업 아이디어가 하나 떠올랐다고 하자.

보통: "사업계획서 써줘." → AI가 뭔가 그럴듯한 걸 뱉어준다 → "오 괜찮은데?" → 끝.

나는 이렇게 한다.

1차: "이 분야에서 잘 되고 있는 서비스들 뭐 있어? 각각 뭘 잘하는지 정리해줘."

AI가 리스트를 뽑아준다. 여기서 끝내면 안 된다. 그 서비스들을 직접 깔아보고 써본다. AI는 겉으로 보이는 정보는 잘 정리하는데, 실제 사용감이나 최근에 바뀐 건 모른다. 그건 내가 확인한다.

2차: "이 서비스들이 사용자를 어떤 흐름으로 끌어들이는지 비교해줘."

AI가 분석해준다. "이건 맞는 것 같은데, 이건 좀 다른데?" 하면서 다시 물어본다. 내가 직접 써봤으니까 그 차이를 안다.

3차: "이걸 직접 만든다면, 우리 팀 상황은 이런데 어떤 방법이 현실적이야?"

AI는 우리 팀 사정을 모른다. 예산이 얼마인지, 누가 뭘 잘하는지. 내가 알려줘야 의미 있는 답이 나온다.

이게 5번, 10번 반복된다. 티키타카다.

"사업계획서 써줘" 한 마디로는 이 깊이가 안 나온다.

🔹 처음 해보는 일에 도전할 때

인스타그램 콘텐츠를 기획해야 할 일이 생겼다. 마케팅은 내 본업이 아니다. 뭘 모르는지도 모르는 상태였다.

보통이면 "인스타 게시물 3개 만들어줘"라고 했을 거다. AI가 밋밋한 걸 내놓으면 "AI 별로네" 하고 끝.

나는 이렇게 했다.

"나는 마케팅을 처음 해보는 사람인데, 인스타 콘텐츠를 기획하려고 해. 내가 뭘 먼저 알아야 해? 어떤 결정들을 내가 직접 해야 좋은 결과가 나와?"

"뭘 만들어줘"가 아니라 "내가 뭘 모르는지"를 먼저 물어본 거다.

AI가 체크리스트를 줬다. 타겟이 누군지, 어떤 느낌으로 갈 건지, 얼마나 자주 올릴 건지, 성과는 뭘로 볼 건지.

이걸 보고 내가 결정할 수 있는 것과 아직 모르는 것을 구분했다.

"타겟은 20대 후반~30대 초반이고, 스킨케어 리뷰야. 근데 어떤 톤으로 말해야 할지 모르겠어. 이 연령대한테 먹히는 스타일을 사례로 보여줘."

AI가 예시를 보여주면 그중에서 내 스타일에 맞는 걸 고른다. 그다음에야 "이 톤으로 첫 게시물 3개 기획해줘"라고 시킨다.

결과물 차이는 하늘과 땅이다.

정리하면 이거다

❌ 보통:     "XX해줘" → 결과 받음 → 틀리면 "AI 별로네"

✅ 이렇게:   "이걸 하려면 뭘 알아야 해?"
             → 내가 모르는 걸 파악
             → AI가 모를 수도 있는 걸 파악
             → 주고받으면서 같이 만듦

같은 도구다. 결과가 다르다.

여기서부터가 진짜 하고 싶은 얘기다

위에서 한 얘기는 사실 서론이다.

AI 결과물이 좋아지는 건 부산물이다. 진짜 중요한 건 따로 있다.

이렇게 쓰면 나 자신이 성장한다.

"내가 뭘 모르지?"를 매번 생각하는 습관이 들면, AI 없이도 사고방식이 달라진다. 회의할 때 "이 안건에서 우리가 놓치고 있는 게 뭐지?"를 먼저 생각하게 된다. 새로운 프로젝트를 시작할 때 "내가 모르는 영역이 어디지?"부터 파악하게 된다. AI를 끄고 나서도 이 습관은 남는다.

아까 인스타 마케팅 사례를 다시 보자. 나는 마케팅을 전혀 몰랐다. 근데 AI한테 "내가 뭘 알아야 해?"를 물어보고, 체크리스트를 받고, 하나씩 결정해나가는 과정에서 마케팅의 기본 구조를 이해하게 됐다. AI가 써준 게시물 3개를 얻은 게 아니다. 마케팅이 어떻게 돌아가는지를 알게 된 거다.

"사업계획서 써줘"로 끝낸 사람은 사업계획서 하나를 얻는다.
티키타카를 한 사람은 그 분야의 시장 구조, 경쟁 상황, 현실적인 실행 방법까지 머릿속에 들어온다.

"XX해줘"로 끝내는 사람은 AI가 없으면 아무것도 못 한다. 티키타카를 하는 사람은 AI 없이도 예전보다 더 잘한다. AI가 대신 해줘서 편해지는 게 아니라, AI랑 대화하는 과정 자체가 사고 훈련이 되는 거다.

이 글에서 하고 싶은 말의 핵심이 이거다. 프롬프트 잘 쓰는 법이 아니다. 생각하는 방식이 바뀌면, AI 결과물도 좋아지고, 나도 성장한다. 순서가 이거다.

AI는 신이 아니다

엄청나게 똑똑한 신입사원이다.

지식은 어마어마한데 우리 사정은 모른다. 일처리는 빠르다. 아는 것도 많다. 근데 맥락을 모른다. 어제 일어난 일을 모를 수도 있다. 자기가 모르는 것도 자신 있게 말한다.

OpenClaw 사건도 마찬가지다. "정리해줘"는 이해했는데 "지우지 마"는 놓쳤다. 신입사원이 할 법한 실수다.

이 신입사원한테 "알아서 해"라고 하면 안 된다.

배경을 설명해주고, 뭘 해야 하는지 같이 정리하고, 중간중간 확인하고, 최종 판단은 내가 한다.

이러면 세상에서 가장 유능한 파트너가 된다.

안 이러면 폐업한 고깃집을 예약하게 된다.

오늘부터 하면 되는 세 가지

하나. AI한테 뭔가 시키기 전에 "나는 이 주제에 대해 뭘 모르지?" 생각해본다. 모르는 게 있으면 답을 구하기 전에 "내가 뭘 알아야 하는지"를 먼저 물어본다.

둘. "AI가 이걸 정확히 알까?" 생각해본다. 실시간 정보, 우리만의 맥락, 최신 변화. 이런 건 틀릴 수 있다. 내가 확인한다.

셋. 큰 작업은 쪼갠다. "다 해줘"가 아니라 단계별로 나눠서 중간중간 확인하면서 간다.

세 가지다. 대단한 거 아니다.

근데 이거 하는 사람과 안 하는 사람의 차이는 꽤 크다.

AI 시대에 가장 중요한 스킬은 코딩도 아니고 프롬프트 기술도 아니다.
내가 뭘 모르는지 아는 능력이다.

📌 다음 편 예고

이번 편은 AI와 대화를 잘 하는 법이었다.

근데 AI가 채팅창 안에만 있을 필요는 없다. 요즘은 AI가 내 캘린더를 보고, 내 문서를 읽고, 내가 쓰는 도구들이랑 직접 연결돼서 일하는 세계가 열리고 있다. OpenClaw가 그래서 그렇게 화제가 된 거다.

다음 편 — AI를 채팅창 밖으로 꺼내는 법.

시리즈 팔로우하기

Claude Code Hooks: Why Your AI Forgets Everything (5-Min Fix)

@kiwibreaksme — Fri, 23 Jan 2026 10:38:52 +0000

Every single session. The same conversation.

"Use TypeScript strict mode."
"Add JSDoc comments to functions."
"Don't touch the .env file."
"Ask me before making API calls."

I was spending the first 5 minutes of every Claude Code session just... repeating myself.

Sound familiar?

The Problem Nobody Talks About

AI coding assistants are incredibly powerful. But they have one fatal flaw:

They forget everything when the session ends.

Your carefully explained coding standards? Gone.
The architectural decisions you discussed for an hour? Vanished.
That one rule about never auto-committing? It doesn't exist anymore.

I tried CLAUDE.md files. They help, but Claude doesn't always read them first. I tried system prompts. Too clunky.

Then I discovered something that changed everything.

The Feature Hiding in Plain Sight

Claude Code Hooks.

Hooks are shell commands that run automatically at specific moments in Claude's lifecycle. Not suggestions. Not guidelines Claude might follow. Actual code that executes every single time.

Think of it like this

CLAUDE.md = "Hey Claude, please remember these rules" (polite request)
Hooks = "These rules WILL run, no exceptions" (enforced automation)

The difference? One relies on AI cooperation. The other just... works.

How Hooks Work (Simple Explanation)

Hooks trigger at specific events:

Event	When It Fires	Use Case
`SessionStart`	Session begins	Load your coding rules
`PreToolUse`	Before any tool runs	Block dangerous commands
`PostToolUse`	After any tool runs	Auto-format code
`PreCompact`	Before context compression	Preserve important context
`Notification`	When Claude needs attention	Desktop alerts

You configure them in .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Your rules here'"
          }
        ]
      }
    ]
  }
}

That's it. Every session, your rules load automatically.

5 Practical Hooks You Can Use Today

1️⃣ Never Forget Your Coding Standards

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[RULES] 1) TypeScript strict mode 2) Add JSDoc to all functions 3) No console.log in production code'"
          }
        ]
      }
    ]
  }
}

Every session starts with your rules. No more repeating yourself.

2️⃣ Protect Sensitive Files

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qE '(\\.env|credentials|secrets)'; then echo 'BLOCKED: Cannot edit sensitive files' >&2; exit 2; fi"
          }
        ]
      }
    ]
  }
}

Claude literally cannot edit your .env files. Not "won't"—can't.

3️⃣ Auto-Format After Every Edit

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "file=$(echo \"$CLAUDE_TOOL_INPUT\" | jq -r '.file_path'); if [[ \"$file\" == *.ts ]]; then npx prettier --write \"$file\"; fi"
          }
        ]
      }
    ]
  }
}

Every TypeScript file gets formatted automatically. No more "can you run prettier?"

4️⃣ Get Desktop Notifications

{
  "hooks": {
    "Notification": [
      {
        "matcher": ".",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Walk away from your desk. Get pinged when Claude needs you.

💡 Use notify-send on Linux

5️⃣ Remember Rules After Context Compression

This one's important. When your conversation gets too long, Claude compresses the context—and often forgets your rules.

{
  "hooks": {
    "PreCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[REMINDER] After compaction: TypeScript strict, JSDoc required, ask before API calls'"
          }
        ]
      }
    ]
  }
}

Your rules survive the compression. Every time.

The Setup (Literally 2 Minutes)

Step 1: Create the settings file

mkdir -p .claude
touch .claude/settings.json

Step 2: Add your hooks

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[My Coding Rules] 1) Your rule here 2) Another rule'"
          }
        ]
      }
    ]
  }
}

Step 3: Commit it to your repo

git add .claude/settings.json
git commit -m "Add Claude Code hooks"

✅ Done. Every developer on your team now has the same rules.

But Wait—There's Still a Problem

Hooks solve the "rules" problem beautifully. But there's something they can't do:

They can't remember WHY you built things a certain way.

Imagine this scenario

Monday: You and Claude decide to use JWT instead of sessions. Good reasons discussed.
Wednesday: New session. Claude suggests using sessions.
You: "We already decided on JWT!"
Claude: "Oh, I didn't know that."

Hooks can remind Claude of rules. But they can't preserve the reasoning behind your architectural decisions.

The Missing Piece: Context in Code

This is why I built CodeSyncer.

bitjaru / codesyncer

Claude forgets everything when the session ends. CodeSyncer makes it remember.

CodeSyncer

Claude forgets everything when the session ends. CodeSyncer makes it remember.

한국어 | English

The Problem → The Solution

Problem	Without CodeSyncer	With CodeSyncer
Context loss	Every session = start from scratch	`@codesyncer-*` tags = permanent memory
Forgot to tag	Changes go untracked	`codesyncer watch` catches everything
Rules forgotten	AI forgets guidelines mid-session	Hooks auto-remind at optimal moments
Dangerous inference	AI guesses prices, security, APIs	Auto-pause on critical keywords

Demo

Quick Start

# 1. Install
npm install -g codesyncer

# 2. Initialize
cd /path/to/your/project
codesyncer init

# 3. Let AI set up (say this to Claude)
"Read .claude/SETUP_GUIDE.md and follow the instructions"

# 4. Start coding (say this each session)
"Read CLAUDE.md"

Upgrade

npm install -g codesyncer@latest

Core Features

🏷️ Tag System

Put context IN your code. AI reads code, so it recovers context automatically.

// @codesyncer-decision: [2024-01-15] Using JWT (session management is simpler)

…

View on GitHub

⭐ Star CodeSyncer on GitHub

The idea is simple: store context directly in your code comments.

/**
 * Authentication service
 *
 * @codesyncer-decision [2026-01-15] JWT over sessions (stateless, easier scaling)
 * @codesyncer-inference Token expiry 24h (standard for web apps)
 */
export class AuthService {
  // @codesyncer-rule Never log tokens, even in debug mode
  async login(credentials: Credentials) {
    // ...
  }
}

Next session, Claude reads the code and instantly knows:

✅ What was decided
✅ Why it was decided
✅ What rules apply

No repetition. No forgetting. The context lives in the code itself.

Hooks + CodeSyncer = Complete Solution

Problem	Solution
AI forgets coding rules	Hooks → Auto-load every session
AI forgets decisions	@codesyncer-decision → Lives in code
AI makes assumptions	@codesyncer-inference → Documents reasoning
AI touches sensitive logic	@codesyncer-rule → Explicit warnings

CodeSyncer even sets up the hooks for you:

npx codesyncer init

This creates:

✅ .claude/settings.json with SessionStart and PreCompact hooks
✅ .claude/CLAUDE.md with your coding rules
✅ Tag system ready to use

Quick Start

🚀 Try CodeSyncer Now

Option 1: Just Hooks (Manual)

mkdir -p .claude
echo '{"hooks":{"SessionStart":[{"hooks":[{"type":"command","command":"echo [RULES] Your rules here"}]}]}}' > .claude/settings.json

Option 2: Full Setup (Recommended)

npx codesyncer init

TL;DR

Hook	Purpose
`SessionStart`	Load rules every session
`PreCompact`	Preserve rules after compression
`PreToolUse`	Block dangerous operations
`PostToolUse`	Auto-format, auto-lint
`Notification`	Desktop alerts

Hooks handle the "rules."
CodeSyncer handles the "reasoning."

Together, your AI finally stops forgetting.

Links

🔗 Claude Code Hooks Documentation
🔗 CodeSyncer GitHub

Have you tried hooks yet? What rules are you automating?

👇 Drop a comment below!

VibeCoding시대. 코딩면접 이제 바뀌어야한다.

@kiwibreaksme — Fri, 23 Jan 2026 05:44:41 +0000

흥미로운 연구 결과가 있습니다.

2025년 7월, AI 안전 연구 기관 METR에서 발표한 연구입니다.

특정 조건에서, 숙련된 개발자가 AI 코딩 도구를 쓰면 오히려 19% 느려졌다.

더 흥미로운 건?

개발자들은 자신이 더 빨라졌다고 착각했습니다.

하지만 이 결과를 그대로 받아들이기 전에, 맥락을 알아야 합니다.

METR 연구: 무엇을 측정했나

연구 설계

항목	내용
대상	16명의 오픈소스 개발자
코드베이스	평균 22K+ 스타, 100만+ 줄 (라이브러리/컴파일러 위주)
경험	해당 레포에 평균 5년, 1500+ 커밋
작업	실제 이슈 246개 (버그 수정, 기능, 리팩토링)
도구	Cursor Pro + Claude 3.5/3.7 Sonnet

결과

항목	수치
실제 결과	AI 사용 시 19% 느려짐
개발자 사전 예측	"24% 빨라질 것"
개발자 사후 체감	"20% 빨라진 것 같음"

⚠️ 중요한 맥락

이 연구에는 특수한 조건이 있었습니다:

극소수 샘플: 단 16명
고품질 코드베이스: Haskell 컴파일러 등 품질 기준이 극도로 높은 프로젝트
이미 극도로 익숙한 환경: 5년간 기여한 자기 프로젝트
도구 숙련도 부족: 56%만 Cursor 사용 경험 있음

연구진도 인정합니다:

"이 결과가 모든 개발자를 느리게 한다는 의미가 아님"
"몇 달 후면 다른 결과가 나올 수 있음"

다른 연구들은 뭐라고 할까?

METR만 보면 안 됩니다. 다른 연구들도 있습니다.

생산성 향상을 보여준 연구들

연구	결과
MIT/Princeton/UPenn	AI로 26% 더 많은 작업 완료
GitHub Copilot 연구	55.8% 더 빠름
IBM 연구	주니어 개발자 21-40% 생산성 향상

단, 이 연구들은 더 단순하고 고립된 작업에서 진행됐습니다.

진짜 인사이트: 상황에 따라 다르다

Sean Goedecke의 분석이 핵심을 짚습니다:

"AI의 진짜 가치는 개발자가 comfort zone 밖의 작업을 할 때 나타난다."

5년간 1500커밋 한 자기 프로젝트에서 AI 도움이 얼마나 필요할까요?
반면, 처음 보는 코드베이스나 새로운 기술을 다룰 때는?

주니어 vs 시니어: 역설적 결과

생산성 향상은 주니어가 더 큼

경력	AI로 인한 생산성 변화
주니어 (0-2년)	+21% ~ +40%
시니어 (10년+)	+7% ~ +16%

IT Revolution

하지만 프로덕션 배포는 시니어가 더 많이

Fastly의 2025년 조사:

시니어 개발자가 AI 생성 코드를 프로덕션에 2.5배 더 많이 배포한다.

시니어 (10년+): 33%가 "절반 이상이 AI 코드"
주니어 (0-2년): 13%만 "절반 이상이 AI 코드"

왜?

"수십 년간의 패턴 인식. 좋은 코드가 어떻게 생겼는지, 뭘 요청해야 하는지, AI가 언제 틀리는지 안다."

핵심 인사이트: 다른 능력이 필요하다

여러 연구를 종합하면 한 가지가 명확해집니다:

기존 "코딩 잘함"과 "바이브코딩 생산성"은 다른 능력이다.

기존 "코딩 잘함"의 정의

🧮 알고리즘 문제 해결 능력
📐 자료구조 이해
⚡ 시간/공간 복잡도 최적화
🔢 수학적 사고력
💻 언어/프레임워크 숙련도

LeetCode 잘 푸는 사람 = 코딩 잘하는 사람.

이 공식이 바이브코딩에선 통하지 않습니다.

바이브코딩 시대의 새로운 능력

1. 메타인지 (Metacognition)

"AI가 지금 뭘 모르고 있는지 아는 능력"

METR 연구에서 개발자들이 착각한 이유:

AI 출력을 과신하거나
AI 출력을 과소평가하거나

바이브코딩 잘하는 사람:

AI의 한계를 정확히 파악
어디서 AI가 틀릴지 예측
언제 직접 코딩이 더 빠른지 판단

2. 문맥 파악 (Context Awareness)

시니어가 AI 코드를 더 많이 배포하는 이유:

"좋은 코드가 어떻게 생겼는지, 뭘 요청해야 하는지, AI가 언제 틀리는지 안다."

이건 알고리즘 실력이 아닙니다.

문맥을 읽는 능력:

이 프로젝트에서 이 코드가 적절한가?
팀의 컨벤션과 맞는가?
비즈니스 요구사항을 충족하는가?

3. AI 대화 스킬 (Prompt Craft)

Frontiers in Education 연구는 프롬프트 엔지니어링을 "21세기 핵심 역량"으로 정의합니다.

필요한 능력:

비판적 사고: AI 출력 검증
창의적 표현: 의도를 명확하게 전달
언어적 감각: 모호함 없는 지시

LeetCode는 이걸 테스트하지 않습니다.

4. 커뮤니케이션

92%의 채용 담당자가 말합니다:

"소프트 스킬이 기술 스킬만큼 중요하다."

200만 개 기술직 채용 공고 분석 결과:

1위 요구 스킬: 커뮤니케이션

AI가 코딩을 대신할수록, 인간만의 협업 능력이 차별화 요소가 됩니다.

5. 적응력과 학습 능력

AI 도구는 빠르게 변합니다. METR 연구진도 말했듯이:

"몇 달 후면 다른 결과가 나올 수 있음"

2025년 초 Claude 3.5와 2026년 모델은 다릅니다.
새로운 도구에 빠르게 적응하는 능력이 중요해집니다.

경고: 40%는 이해 못 한 코드를 배포한다

Vibe Coding Statistics:

주니어 개발자의 40% 이상이 완전히 이해하지 못한 AI 생성 코드를 배포한다.

이게 왜 문제인가?

🔴 기술 부채 누적
🔴 보안 취약점 (AI 코드의 45%에 보안 결함)
🔴 디버깅 불가능

메타인지 없이 바이브코딩 = 폭탄 돌리기

새로운 역량 체크리스트

바이브코딩 시대에 필요한 능력:

역량	설명	LeetCode로 측정?
메타인지	AI의 한계 파악	❌
문맥 파악	프로젝트/팀/비즈니스 이해	❌
AI 대화 스킬	명확한 의도 전달	❌
커뮤니케이션	협업 및 설명 능력	❌
적응력	새 도구/기술 학습	❌
비판적 사고	AI 출력 검증	❌

기존 코딩 테스트는 이걸 측정하지 못합니다.

결론: 새로운 시대, 새로운 역량

여러 연구를 종합하면:

AI 코딩 도구의 효과는 상황에 따라 다르다
- 익숙한 코드베이스 vs 새로운 환경
- 단순한 작업 vs 복잡한 작업
- 도구 숙련도
기존 코딩 실력 ≠ 바이브코딩 생산성
- 알고리즘 실력만으로는 부족
- 메타인지, 문맥 파악, 커뮤니케이션이 중요
시니어의 강점은 "경험에서 오는 감각"
- AI가 언제 틀리는지 아는 것
- 좋은 코드가 어떻게 생겼는지 아는 것

바이브코딩 시대의 진짜 실력:

🧠 AI가 뭘 모르는지 아는 것
🎯 AI에게 뭘 시켜야 하는지 아는 것
✅ AI가 틀렸을 때 알아차리는 것

메타인지, 문맥 파악, 커뮤니케이션.

이게 새로운 시대의 코딩 실력입니다.

References

여러분은 어떻게 생각하시나요?

👇 댓글로 의견 공유해주세요!

skills.sh: The Skill Marketplace for AI Coding Agents You're Missing Out On

@kiwibreaksme — Fri, 23 Jan 2026 05:28:12 +0000

Ever had these thoughts while using AI coding agents?

"I'm tired of explaining React best practices every time..."
"I wish I could save my Tailwind rules somewhere..."
"How do other people set up their AI?"

It's already been done for you.

What is skills.sh?

🔗 Visit skills.sh

The Open Agent Skills Ecosystem

A marketplace for injecting expert knowledge into AI agents (Claude Code, Cursor, Copilot, etc.).

In simple terms:

🧠 Install other people's best practices into your AI
⚡ 1 minute install, no complex setup
🔓 Open source, free

Supported AI Agents

Agent	Support
Claude Code	✅
Cursor	✅
GitHub Copilot	✅
Gemini	✅
OpenAI Codex	✅
+15 more	✅

Works with almost every AI coding tool out there.

Top 10 Most Popular Skills

Rank	Skill	Installs	Purpose
1️⃣	vercel-react-best-practices	32.6K	React best practices
2️⃣	web-design-guidelines	24.7K	Web design guide
3️⃣	remotion-best-practices	12.7K	Video editing (Remotion)
4️⃣	frontend-design	4.0K	Frontend design
5️⃣	skill-creator	2.6K	Skill for creating skills
6️⃣	vue-best-practices	2.1K	Vue.js
7️⃣	three-js-best-practices	1.8K	Three.js 3D
8️⃣	supabase-best-practices	1.5K	Supabase
9️⃣	marketing-guidelines	1.2K	Marketing
🔟	tailwind-best-practices	1.0K	Tailwind CSS

30,000+ developers using React are already on this.

How to Install

Method 1: CLI (Recommended)

npx skills add vercel-labs/vercel-react-best-practices

One line. That's it.

Method 2: Inside Claude Code

/skills install vercel-labs/vercel-react-best-practices

Verify Installation

/skills

How Does It Actually Work?

Before (Without Skills)

Me: Create a React component

Claude: (generates basic code)

After (With Skills Installed)

Me: Create a React component

Claude: (applies Vercel's best practices)
- Functional component
- TypeScript type definitions
- Proper hook usage
- Performance optimization
- Accessibility considerations

Same question, different quality.

Recommended Skill Combos

🎨 Frontend Developer

npx skills add vercel-labs/vercel-react-best-practices
npx skills add vercel-labs/web-design-guidelines
npx skills add vercel-labs/frontend-design

⚡ Next.js + Supabase

npx skills add vercel-labs/vercel-react-best-practices
npx skills add supabase/supabase-best-practices

🎬 Video Editing (Remotion)

npx skills add remotion-dev/remotion-best-practices

🎯 Vue.js Developer

npx skills add vuejs/vue-best-practices

🌐 Full Stack

npx skills add vercel-labs/vercel-react-best-practices
npx skills add supabase/supabase-best-practices
npx skills add vercel-labs/web-design-guidelines

Skill Structure (For the Curious)

A skill is essentially one SKILL.md file.

my-skill/
├── SKILL.md           # Core (required)
├── reference.md       # Detailed docs (optional)
├── examples.md        # Examples (optional)
└── scripts/           # Scripts (optional)

SKILL.md Example

---
name: react-best-practices
description: React best practices. Auto-applied when writing components.
---

## Component Rules

1. Use functional components
2. Define props with TypeScript interfaces
3. useReducer over useState (complex state)
4. Always specify useEffect dependencies
5. Memoize only when necessary

## Don'ts

- Class components
- any type
- Inline styles (use Tailwind)

The AI reads this file and follows the rules.

Create Your Own Skill

Using others' skills is great, but you can also create project-specific skills.

Step 1: Create Folder

mkdir -p .claude/skills/my-rules

Step 2: Write SKILL.md

---
name: my-rules
description: Our team's coding rules
---

## Required

1. Variables in camelCase
2. Functions under 20 lines
3. Comments explain "why"
4. Error handling required

## Forbidden

- console.log (production)
- any type
- Magic numbers

Step 3: Done

Now it auto-applies when you code.

skills.sh vs Manual Prompts

Aspect	Manual Prompts	skills.sh
Type every time	Required	❌ Not needed
Consistency	🔴 Low	🟢 High
Sharing	Difficult	✅ Easy
Verified	❌	✅ Community verified
Setup time	-	1 minute

FAQ

Is it free?
Yes, it's open source and free.

Which AIs does it work with?
Claude Code, Cursor, Copilot, Gemini, and 20+ more.

Do skills conflict with each other?
Usually not. Each skill is designed to focus on a specific domain.

Can I share my own skills?
Yes, push to GitHub and register on skills.sh.

Summary

Action	Command
Install skill	`npx skills add owner/repo`
List installed	`/skills`
Call directly	`/skill-name`
Create your own	`.claude/skills/name/SKILL.md`

Get Started

Takes 1 minute.

# Install the most popular React skill
npx skills add vercel-labs/vercel-react-best-practices

Now when you write React code, Vercel's best practices are automatically applied.

Links

🔗 skills.sh - Skill Marketplace
🔗 skills.sh Docs
🔗 Claude Code Skills Official Docs

What skills are you using?

AI 코딩 에이전트용 스킬 마켓플레이스 (몰랐으면 손해)

@kiwibreaksme — Fri, 23 Jan 2026 05:24:58 +0000

AI 코딩 에이전트 쓰면서 이런 생각 해본 적 있음?

"React 베스트 프랙티스 매번 설명하기 귀찮은데..."
"Tailwind 쓰는 규칙 어디 저장해두고 싶다..."
"다른 사람들은 어떻게 설정해서 쓰지?"

이미 다 만들어져 있습니다.

skills.sh가 뭔데?

🔗 skills.sh 바로가기

The Open Agent Skills Ecosystem

AI 에이전트(Claude Code, Cursor, Copilot 등)에 전문 지식을 주입하는 스킬 마켓플레이스입니다.

쉽게 말해:

🧠 남들이 만든 베스트 프랙티스를 내 AI에 장착
⚡ 설치 1분, 복잡한 설정 없음
🔓 오픈소스, 무료

지원하는 AI 에이전트

에이전트	지원
Claude Code	✅
Cursor	✅
GitHub Copilot	✅
Gemini	✅
OpenAI Codex	✅
+15개 이상	✅

거의 모든 AI 코딩 도구에서 작동합니다.

순위	스킬	설치 수	용도
1️⃣	vercel-react-best-practices	32.6K	React 베스트 프랙티스
2️⃣	web-design-guidelines	24.7K	웹 디자인 가이드
3️⃣	remotion-best-practices	12.7K	영상 편집 (Remotion)
4️⃣	frontend-design	4.0K	프론트엔드 디자인
5️⃣	skill-creator	2.6K	스킬 만드는 스킬
6️⃣	vue-best-practices	2.1K	Vue.js
7️⃣	three-js-best-practices	1.8K	Three.js 3D
8️⃣	supabase-best-practices	1.5K	Supabase
9️⃣	marketing-guidelines	1.2K	마케팅
🔟	tailwind-best-practices	1.0K	Tailwind CSS

설치 방법

방법 1: CLI (추천)

npx skills add vercel-labs/vercel-react-best-practices

한 줄이면 끝.

방법 2: Claude Code 내에서

/skills install vercel-labs/vercel-react-best-practices

설치 확인

/skills

실제로 어떻게 작동하나?

Before (스킬 없이)

나: React 컴포넌트 만들어줘

Claude: (그냥 기본적인 코드 생성)

After (스킬 설치 후)

나: React 컴포넌트 만들어줘

Claude: (Vercel의 베스트 프랙티스 적용)
- 함수형 컴포넌트
- TypeScript 타입 정의
- 적절한 훅 사용
- 성능 최적화 고려
- 접근성 고려

같은 질문, 다른 품질.

스킬 구조 (궁금한 사람만)

스킬은 결국 SKILL.md 파일 하나입니다.

my-skill/
├── SKILL.md           # 핵심 (필수)
├── reference.md       # 상세 문서 (선택)
├── examples.md        # 예제 (선택)
└── scripts/           # 스크립트 (선택)

SKILL.md 예시

---
name: react-best-practices
description: React 베스트 프랙티스. 컴포넌트 작성 시 자동 적용.
---

## 컴포넌트 작성 규칙

1. 함수형 컴포넌트 사용
2. Props는 TypeScript 인터페이스로 정의
3. useState보다 useReducer (복잡한 상태)
4. useEffect 의존성 배열 명시
5. 메모이제이션은 필요할 때만

## 금지 사항

- class 컴포넌트
- any 타입
- 인라인 스타일 (Tailwind 사용)

AI가 이 파일을 읽고 규칙을 따릅니다.

내 스킬 만들기

남의 거 쓰는 것도 좋지만, 내 프로젝트 전용 스킬도 만들 수 있음.

Step 1: 폴더 생성

mkdir -p .claude/skills/my-rules

Step 2: SKILL.md 작성

---
name: my-rules
description: 우리 팀 코딩 규칙
---

## 필수 규칙

1. 변수명은 camelCase
2. 함수는 20줄 이하
3. 주석은 "왜"를 설명
4. 에러 핸들링 필수

## 금지

- console.log (프로덕션)
- any 타입
- 매직 넘버

Step 3: 끝

이제 코드 짤 때 자동으로 적용됨.

skills.sh vs 직접 프롬프트

항목	직접 프롬프트	skills.sh
매번 입력	필요	❌ 불필요
일관성	🔴 낮음	🟢 높음
공유	어려움	✅ 쉬움
검증됨	❌	✅ 커뮤니티 검증
설치	-	1분

자주 묻는 질문

무료인가요?
네, 오픈소스 기반이라 무료입니다.

어떤 AI에서 작동하나요?
Claude Code, Cursor, Copilot, Gemini 등 20개 이상 지원합니다.

스킬끼리 충돌하나요?
보통 안 합니다. 각 스킬은 특정 도메인에 집중하도록 설계되어 있습니다.

내가 만든 스킬 공유할 수 있나요?
네, GitHub에 올리고 skills.sh에 등록하면 됩니다.

요약

할 일	명령어
스킬 설치	`npx skills add owner/repo`
설치 목록 확인	`/skills`
스킬 직접 호출	`/skill-name`
내 스킬 만들기	`.claude/skills/name/SKILL.md`

시작하기

1분이면 됩니다.

# 가장 인기 있는 React 스킬 설치
npx skills add vercel-labs/vercel-react-best-practices

이제 React 코드 짜면 자동으로 Vercel 베스트 프랙티스가 적용됩니다.

링크

🔗 skills.sh - 스킬 마켓플레이스
🔗 skills.sh 문서
🔗 Claude Code Skills 공식 문서

어떤 스킬 쓰고 계신가요?

👇 댓글로 추천해주세요!

Claude Code Hooks 완벽 가이드: AI가 맨날 까먹는 이유와 해결법

@kiwibreaksme — Fri, 23 Jan 2026 04:43:20 +0000

매번. 똑같은. 대화.

"TypeScript strict mode 써."
"함수마다 JSDoc 주석 달아."
".env 파일은 건드리지 마."
"API 호출 전에 나한테 물어봐."

저는 Claude Code 세션 시작할 때마다 첫 5분을 이런 얘기 반복하는 데 쓰고 있었습니다.

혹시 공감되시나요?

아무도 말 안 하는 문제

AI 코딩 어시스턴트는 정말 강력합니다. 근데 치명적인 약점이 하나 있어요.

세션 끝나면 다 잊어버림.

어제 1시간 동안 설명한 코딩 규칙? 사라짐.
그제 논의한 아키텍처 결정? 없던 일.
"절대 자동 커밋하지 마"라고 했던 거? 기억 못함.

CLAUDE.md 파일도 써봤습니다. 도움은 되는데, Claude가 항상 먼저 읽지는 않더라고요. 시스템 프롬프트도 써봤는데 너무 번거롭고.

그러다가 모든 걸 바꾼 기능을 발견했습니다.

숨겨진 기능: Claude Code Hooks

Hooks는 Claude의 라이프사이클 특정 시점에 자동으로 실행되는 셸 명령어입니다. 제안이 아니에요. Claude가 따를 수도 있는 가이드라인이 아닙니다. 매번 무조건 실행되는 실제 코드입니다.

이렇게 생각하면 쉬워요

CLAUDE.md = "Claude야, 이 규칙들 기억해줘" (정중한 부탁)
Hooks = "이 규칙은 무조건 실행됨" (강제 자동화)

차이점? 하나는 AI의 협조에 의존하고, 다른 하나는 그냥... 작동합니다.

Hooks 작동 원리 (쉬운 설명)

Hooks는 특정 이벤트에서 발동됩니다:

이벤트	발동 시점	활용 예시
`SessionStart`	세션 시작	코딩 규칙 로드
`PreToolUse`	도구 실행 전	위험한 명령 차단
`PostToolUse`	도구 실행 후	코드 자동 포맷팅
`PreCompact`	컨텍스트 압축 전	중요 컨텍스트 보존
`Notification`	알림 필요 시	데스크톱 알림

설정은 .claude/settings.json에서 합니다:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '여기에 규칙 작성'"
          }
        ]
      }
    ]
  }
}

끝입니다. 매 세션마다 규칙이 자동으로 로드됩니다.

지금 바로 쓸 수 있는 실용적인 Hooks 5가지

1️⃣ 코딩 규칙 자동 로드

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[규칙] 1) TypeScript strict mode 2) 모든 함수에 JSDoc 3) 프로덕션에 console.log 금지'"
          }
        ]
      }
    ]
  }
}

매 세션이 규칙과 함께 시작됩니다. 더 이상 반복할 필요 없음.

2️⃣ 민감한 파일 보호

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qE '(\\.env|credentials|secrets)'; then echo '차단됨: 민감한 파일 수정 불가' >&2; exit 2; fi"
          }
        ]
      }
    ]
  }
}

Claude가 .env 파일을 수정 못 합니다. "안 하는" 게 아니라 "못 하는" 겁니다.

3️⃣ 수정 후 자동 포맷팅

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "file=$(echo \"$CLAUDE_TOOL_INPUT\" | jq -r '.file_path'); if [[ \"$file\" == *.ts ]]; then npx prettier --write \"$file\"; fi"
          }
        ]
      }
    ]
  }
}

TypeScript 파일이 자동으로 포맷팅됩니다. "prettier 돌려줘" 안 해도 됨.

4️⃣ 데스크톱 알림 받기

{
  "hooks": {
    "Notification": [
      {
        "matcher": ".",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude가 응답을 기다리고 있습니다\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

자리 비워도 됩니다. Claude가 필요할 때 알림이 옵니다.

💡 Linux는 notify-send 사용

5️⃣ 컨텍스트 압축 후에도 규칙 유지

이거 중요합니다. 대화가 길어지면 Claude가 컨텍스트를 압축하는데, 이때 규칙을 종종 까먹습니다.

{
  "hooks": {
    "PreCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[리마인더] 압축 후에도 기억할 것: TypeScript strict, JSDoc 필수, API 호출 전 확인'"
          }
        ]
      }
    ]
  }
}

압축 후에도 규칙이 살아남습니다. 매번.

설정 방법 (진짜 2분)

Step 1: 설정 파일 생성

mkdir -p .claude
touch .claude/settings.json

Step 2: Hooks 추가

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '[내 코딩 규칙] 1) 규칙1 2) 규칙2'"
          }
        ]
      }
    ]
  }
}

Step 3: 레포에 커밋

git add .claude/settings.json
git commit -m "Add Claude Code hooks"

✅ 끝. 이제 팀원 모두가 같은 규칙을 공유합니다.

근데 아직 문제가 하나 남음

Hooks는 "규칙" 문제를 아름답게 해결합니다. 하지만 못하는 게 있어요:

왜 그렇게 만들었는지는 기억 못함.

이런 상황 상상해보세요

월요일: Claude랑 JWT를 쓰기로 결정. 충분한 논의 끝에.
수요일: 새 세션. Claude가 세션 방식을 제안함.
나: "우리 JWT 쓰기로 했잖아!"
Claude: "아, 몰랐어요."

Hooks는 규칙을 상기시킬 수 있습니다. 하지만 아키텍처 결정의 이유는 보존하지 못해요.

빠진 퍼즐 조각: 코드 안의 컨텍스트

그래서 CodeSyncer를 만들었습니다.

bitjaru / codesyncer

Claude forgets everything when the session ends. CodeSyncer makes it remember.

CodeSyncer

Claude forgets everything when the session ends. CodeSyncer makes it remember.

한국어 | English

The Problem → The Solution

Problem	Without CodeSyncer	With CodeSyncer
Context loss	Every session = start from scratch	`@codesyncer-*` tags = permanent memory
Forgot to tag	Changes go untracked	`codesyncer watch` catches everything
Rules forgotten	AI forgets guidelines mid-session	Hooks auto-remind at optimal moments
Dangerous inference	AI guesses prices, security, APIs	Auto-pause on critical keywords

Demo

Quick Start

# 1. Install
npm install -g codesyncer

# 2. Initialize
cd /path/to/your/project
codesyncer init

# 3. Let AI set up (say this to Claude)
"Read .claude/SETUP_GUIDE.md and follow the instructions"

# 4. Start coding (say this each session)
"Read CLAUDE.md"

Upgrade

npm install -g codesyncer@latest

Core Features

🏷️ Tag System

Put context IN your code. AI reads code, so it recovers context automatically.

// @codesyncer-decision: [2024-01-15] Using JWT (session management is simpler)

…

View on GitHub

아이디어는 간단해요: 코드 주석에 컨텍스트를 직접 저장하는 겁니다.

/**
 * 인증 서비스
 *
 * @codesyncer-decision [2026-01-15] 세션 대신 JWT 선택 (stateless, 스케일링 용이)
 * @codesyncer-inference 토큰 만료 24시간 (웹앱 표준)
 */
export class AuthService {
  // @codesyncer-rule 디버그 모드에서도 토큰 로깅 금지
  async login(credentials: Credentials) {
    // ...
  }
}

다음 세션에서 Claude가 코드를 읽으면 즉시 알게 됩니다:

✅ 뭘 결정했는지
✅ 왜 그렇게 결정했는지
✅ 어떤 규칙이 적용되는지

반복 없음. 까먹음 없음. 컨텍스트가 코드 자체에 살아있습니다.

Hooks + CodeSyncer = 완벽한 조합

문제	해결책
AI가 코딩 규칙을 까먹음	Hooks → 매 세션 자동 로드
AI가 결정을 까먹음	@codesyncer-decision → 코드에 남음
AI가 추론함	@codesyncer-inference → 근거 문서화
AI가 민감한 로직 건드림	@codesyncer-rule → 명시적 경고

CodeSyncer는 Hooks도 자동으로 설정해줍니다:

npx codesyncer init

이렇게 생성됩니다:

✅ .claude/settings.json - SessionStart, PreCompact hooks 포함
✅ .claude/CLAUDE.md - 코딩 규칙
✅ 태그 시스템 바로 사용 가능

빠른 시작

🚀 CodeSyncer 시작하기

⭐ CodeSyncer GitHub에서 스타 누르기

옵션 1: Hooks만 (수동)

mkdir -p .claude
echo '{"hooks":{"SessionStart":[{"hooks":[{"type":"command","command":"echo [규칙] 여기에 규칙"}]}]}}' > .claude/settings.json

옵션 2: 전체 설정 (추천)

npx codesyncer init

요약

Hook	용도
`SessionStart`	매 세션 규칙 로드
`PreCompact`	압축 후에도 규칙 유지
`PreToolUse`	위험한 작업 차단
`PostToolUse`	자동 포맷팅, 린팅
`Notification`	데스크톱 알림

Hooks는 "규칙"을 담당합니다.
CodeSyncer는 "이유"를 담당합니다.

둘을 같이 쓰면, AI가 드디어 까먹지 않습니다.

링크

🔗 Claude Code Hooks 공식 문서
🔗 CodeSyncer GitHub

Hooks 써보셨나요? 어떤 규칙을 자동화하고 계신가요?

👇 댓글로 공유해주세요!