SESSION 05 / 06

"알아서 해줘"는
통하지 않는다

어휘 · CLI · 30초 숙제

지준영

비전공(경영학과) → 기자 · 해외영업 → 개발자 전향
iOS · Android · Frontend 약 5년 반 (6년차)
대기업 협업툴 iOS/macOS 앱 개발
2026~ 바이브코딩으로 웹 · 서버 1인 개발 · 사업화

TODAY · 5 PARTS

오늘 — 어디서 어디까지

PART 1

도입 · 어휘 + 디자인 패턴 · 아키텍처 · SOLID

50분

PART 2

CLI의 심오함 — 글자로 명령하는 화면

17분

— 휴식 —

☕ 호흡 가다듬기

10분

PART 3

모르는 단어 앞에서 멈추지 않는 법

14분

PART 4

1~5화 누적 + 보너스 + 오늘 핵심 3줄

23분

PART 5

숙제 + 마무리

10분

좌측에 PART 넘버가 항상 표시됩니다 — *지금 어디인지* 잃지 않게.

PART 1 — 4화 복기

F12 눌러보셨죠?
그게 원칙 #8입니다.

키 두 종류

공개(pk_*·anon) vs 시크릿(sk-*·service_role) — 털리면 *요금*인가 *DB*인가?

AI 평균치 vs 해커 엣지

AI는 평균에 강하고 엣지에 약하다. 해커는 평균을 안 노린다.

방어선 6줄 + 정본

RLS · .env · NEXT_PUBLIC_ · BFF · Source Map · .gitignore + account.md / SECURITY.md

결제 5박자

멱등성 · 원자성 · 동시성 · webhook 검증 · 금액 검증 — "다섯 가지 다 챙겼어?"

오늘은 한 발 더 — '말의 정확도' 얘기.

2회차 주문표 비유 — RECALL

"알아서 해줘"로는 대충만 나옵니다.

🎨 디자이너 비유 — 같은 결 · "모던하면서 전통적, 23세기 미래지향" 시안 던지기 = 클라이언트가 원하던 결과 안 나옴.

LEVEL 1

"밥 주세요"

완전 랜덤. 사장님이 뭘 줄지 모름

LEVEL 2

"김치볶음밥 주세요"

좀 낫지만 계란·김가루는 사장님 맘대로

LEVEL 3

상세 주문표

맵기 중간 · 계란 반숙 · 김가루 추가

상세 주문표를 쓰려면 단어가 있어야 합니다.
이 단어들이 기술 어휘입니다.

CASE

같은 프로젝트, 다른 결과물

수강생 A

"로그인 기능 만들어줘"

버튼 수십번 눌리는 없어 보이는 화면 + 오늘 해커한테 털림.

수강생 B

"로그인 만들어줘.
HttpOnly 쿠키 세션,
RLS 사용자 분리,
비밀번호 서버 해시.
중복 클릭 방지 — 화면 전체 로딩 레이어,
Material Design 애니메이션."

기본 방어선 + UX까지 다 깔림

차이 — B는 단어를 알았을 뿐입니다.
코딩은 Claude가 합니다.

YOU ALREADY KNOW THESE

지난 4번의 수업에서 나온 단어들

VercelSupabaseClaude Code.envRLSF12localStorageHttpOnlyXSSAPI 키NEXT_PUBLIC_Source MapBFF 프록시PRDSpecSSOTCanonicalADRSwaggerCLAUDE.mdPLANNING.md.gitignoreDomain Knowledge순환 복잡도(CC)멱등성원자성동시성webhook 검증금액 검증

+ 오늘(5화)에서 만날 새 어휘 — 4화 S40 예고

클린 아키텍처MVVMFSD디자인 패턴

"아 그런 게 있었지?" · "단어가 기억이 안 나네?"
"이거 말고 더 물어봐야 할 게 있나?"

— 이런 고민을 한다는 것 자체가,
시작도 안 한 사람보다 앞서 있는 단계입니다.

다 외울 필요 — 없습니다.

하지만 "이런 단어가 있다" 는 인지는 필요합니다.
단어가 있어야 AI한테 "그게 뭐야?" 물어볼 수 있습니다.

모른다고 시작 못 할 이유는 없습니다.
모르면 물어봅니다. 단, 뭘 물어야 하는지는 알아야 합니다.

WHY · CONTEXT ROT (맥락 부패)

왜 디자인 패턴 · 아키텍처 · 기술 용어가
— 돈과 직결되는가

침실에 과자봉지·컴퓨터·가스레인지·계란껍질·햇반 다 굴러다닙니다.
청소업자가 문 열고 들어와 견적 부르면 — 몇십만 원? 백만 원? 아예 그냥 나가버릴 수도 있어요.
반대로 잠·휴식만 쓴 깔끔한 방은 — 두 시간 끝, 싸게.

이 청소업자가 — AI이고,
견적비가 — 여러분이 지불하는 토큰입니다.

방이 지저분할수록 AI가 돈을 더 써요.
극도로 지저분하면 — 일하다 튀거나, 4시간 쉬고 다시 옵니다. 정신이 나가서요.

학계 용어로 Context Rot — 한국말 직역하면 "맥락 부패". 3화에서 다룬 그것.
긴 코드·문서를 읽다가 AI가 *중간을 잊고 길을 잃는 현상* (Liu et al. 2023, *Lost in the Middle*).

그래서 — 디자인 패턴·아키텍처가 "개발자 잘난 척"이 아니라
바이브코더의 비용 절감 + AI 협업 안정성의 핵심입니다.

BIG PICTURE

디자인 패턴 · 아키텍처 — 한눈에

디자인 패턴 (작은 단위)

"검증된 해결책 모음집"

비유 — 요리책의 레시피.
같은 문제는 같은 패턴으로.
예: Singleton · Factory · Observer · Repository · Adapter
출처: GoF (Gang of Four) 23 패턴, 1994

아키텍처 (큰 단위)

"전체 시스템 설계"

비유 — 도시 계획 (도로·구역·전기).
큰 결정. 한번 하면 바꾸기 어려움.
예: MVC · MVVM · 클린 · 헥사고날 · FSD

대표 아키텍처 — 비유 한 줄

MVC / MVVM

자판기. 화면이랑 데이터를 따로 둔다.
→ 다음 슬라이드에서 풀이

클린 아키텍처 (Uncle Bob, 2012)

양파 같은 동심원.
안쪽 = 핵심 로직 / 바깥쪽 = 부가물(DB·화면·API).
안은 바깥을 모르고 작동 — DB 갈아도 핵심 안 바뀜.

헥사고날 (Cockburn, 2005)

카페 본부와 가맹점.
본부(도메인) = 메뉴·매뉴얼만.
가맹점(어댑터) = 손님·재료·결제 처리. 가맹점 갈아도 본부 그대로.

FSD (Feature-Sliced Design, 2018~)

수직 6층 + 도메인별 매장 이중 분리. 프론트엔드 전용.
→ 다음 슬라이드 백화점 매장 비유에서 풀이

그리고 — 이거 다 수십 년 검증된 방법론입니다.
MVC 1979 · 헥사고날·MVVM 2005 · 클린 2012 · FSD 2018~

그래서 — AI 학습 데이터에 풍부합니다.
단어 하나만 던져도 Claude가 정확히 알아들어요. 그게 오늘 어휘를 다루는 이유.

INSTRUCTOR CASE · GRIMOIRE

강사 본인 사례 — 헥사고날 + 약식 FSD

먼저 한 일 — 자가 진단 (*무작정 도입* 안 함)

제가 만든 iOS 앱 코드를 Claude에 다 읽힌 다음 — 직접 물었어요.
"이 코드 수준이면 웹 FSD·서버 헥사고날 가도 유지보수 가능할까? 진단해줘."

Claude 답을 100% 신뢰? 아닙니다. 다른 AI한테도 같은 질문 던져 견적을 냈습니다.

그 결과 ① — 서버 (grimoire-server)

헥사고날 (Ports & Adapters) 도입.
도메인 중심에 두고 — DB·외부 API·HTTP 라우터를 어댑터로 분리.
코드 구조: domain / application / adapter / infrastructure

그 결과 ② — 웹 (grimoire-web)

FSD 약식 도입 — strict 6 layers는 안 가고,
핵심 슬라이스(features/auth · features/payment · features/works)만 도메인 단위로.

메시지: 아키텍처 = 외운다 X.
"내가 도입할 만한 레벨인가" — AI에게 진단 받는다.

VOCABULARY VIA ANALOGY

전문용어 — 일상 비유로 풀기

디자인패턴·아키텍처·알고리즘 — 처음 보는 단어 계속 튀어나오는 분야.
문자 하나하나 외우려 하면 힘듭니다.

팁 — 일상에 같은 패턴이 분명히 있습니다. 거기에 소프트웨어 로직 한 겹을 가미한 게 — 디자인패턴·아키텍처·알고리즘. 마인드를 이렇게 바꾸면 거부감 ↓.

시범 — 자료구조 3개를 일상으로

큐 (Queue · FIFO)

편의점 음료수 진열대.
알바가 뒤에서 새것 채우고, 손님은 앞에서 뺌. 먼저 들어간 게 먼저 나감.

스택 (Stack · LIFO)

책상 위 책 쌓기.
새 책 위에 올리고, 위에서부터 빼서 봄. 나중에 올린 게 먼저 나감 — Ctrl+Z도 스택.

해시맵 (Hash Map · Dictionary)

학교 사물함.
학번(*키*) 알면 자기 칸(*값*)으로 한 번에 도달. 줄 서서 하나씩 찾을 필요 없음.

새 단어 만나면 — "일상에 비슷한 게 뭐지?" 한 번 찾아보세요.
앞으로 다룰 MVVM·FSD·클린·SOLID — 다 *일상 비유*로 풀어드립니다 (자판기·백화점·양파·횟집 주방).

MVVM

MVVM이 뭔가요? — 자판기

비유 — 자판기

View = 자판기 버튼·화면 (사용자가 보는 것)
ViewModel = 자판기 안 회로 (버튼 눌리면 알아서 처리)
Model = 음료수 재고·가격 데이터

버튼 누르면 → 회로(VM)가 알아서 음료 떨어뜨림.
사용자는 *어떻게 떨어지는지* 몰라도 됨.

왜 좋은가? — View와 데이터가 분리되어 있어서
버튼 *시각 디자인* (색·레이아웃)만 바꿀 땐 회로(VM) 그대로.
단, 버튼 *기능 자체*가 바뀌면(분기 처리·새 동작) 회로도 손봐야.

iOS · Android · Vue · WPF — 널리 쓰이는 패턴입니다.
출처 — Microsoft John Gossman, 2005년.

"화면" 과 "데이터" 사이에 대신 일하는 회로(ViewModel)가 있다.
출처: Microsoft John Gossman, 2005년 (WPF용 발표).

FSD · FEATURE-SLICED DESIGN

FSD가 뭔가요? — 백화점 층 구분

비유 — 백화점 (수평: 도메인 매장)

1관 화장품 · 2관 여성복 · 3관 남성복 · 4관 식품
도메인별로 매장(slice)이 분리.

화장품 매장 안에 갑자기 식품 코너 있으면? 손님 헷갈림. 매출 떨어짐.
FSD도 똑같음. 도메인별 매장(slice)으로 가로 분리.

FSD 공식 6 layers (수직 위계 + 의존성 방향 규칙)

apppageswidgetsfeaturesentitiesshared

위층은 아래층만 쓸 수 있음 (역방향 금지). 그리고 각 layer 안에 다시 slice(도메인 단위) — `features/auth`, `features/payment` 식

강사는 약식으로 — 몇 가지 개념만 따왔습니다.
중요한 건 — 용도별로 정리하고, 규칙을 정한다.

strict 6 layer 위계는 다 안 가고 → ① 폴더는 기능(slice) 단위로 (`features/auth`, `features/payment` …) ② 위층만 아래층 호출 (의존성 방향) ③ 명명·import 규칙 통일.

출처: 2018~2020 등장, feature-sliced.design 공식. 프론트엔드 (React/Vue) 전용.

⚠ 웹 프로젝트에서 가장 많이 보이는 패턴

한 파일에 — 버튼 색깔 바꾸는 로직 / 물건값 계산 로직 / 서버 API 호출 / Claude·GPT 부르는 로직
— 이게 전부 한 곳에 들어 있습니다.

이렇게 하면? — 앞에서 말한 Context Rot · 어텐션 상실이 발생합니다.
방청소 하다가 포기하고 뛰쳐나가는 그 청소업자처럼 — Claude도 헤매다가 *헛짓*을 합니다.

CLEAN ARCHITECTURE · UNCLE BOB

클린 아키텍처가 뭔가요? — 양파 동심원

비유 — 양파

양파를 떠올려보세요. 가장 안쪽이 *진짜 알맹이*. 바깥은 껍질입니다.

안쪽 = 도메인 (내가 진짜 만들고 싶은 것 — 핵심 비즈니스 로직)
바깥쪽 = DB · 화면 · 외부 API · 프레임워크 (부가물 · 껍질)

규칙 한 줄

안쪽은 바깥쪽을 *모르고* 작동합니다.
"내가 PostgreSQL을 쓰는지, MySQL을 쓰는지 — 도메인 코드는 모름."

→ 1년 후 DB 갈아도 핵심 코드는 안 바꿉니다. 웹을 모바일로 옮겨도 비즈니스 로직 그대로.

핵심을 안쪽에 두고, 바깥을 갈아 끼울 수 있게.

출처 — Robert C. Martin (Uncle Bob), 2012년 블로그 → 2017년 책 *Clean Architecture*.

DESIGN PATTERNS

디자인 패턴 — 알아두면 좋은 것들

Factory · 피자 가게

손님은 "불고기 피자"만. 도우 종류·오븐 온도는 가게가 알아서. — 객체 만드는 방법 캡슐화

Observer · 유튜브 알림

채널 구독해두면 새 영상 시 자동 알림. 매일 들어가서 확인 안 함. — pub/sub 패턴

Strategy · 결제 수단

카드·계좌이체·페이코·카카오페이 — 어떤 걸 골라도 결제 인터페이스는 같음. — 알고리즘 교체

Adapter · 해외 여행 어댑터

한국 가전을 미국 콘센트에 — 110V↔220V 어댑터. — 인터페이스 변환

⚠️ Singleton — 인류 역사상 가장 오남용되는 패턴

비유 — *국가 대통령*. 한 나라에 한 명. "나 대통령이오" 하는 사람 두 명 나오면 나라 흔들림.
오남용 — *모든 결정을 대통령 혼자.* 의사결정 한 곳에 몰려 나라 마비.

실제 코드에서: 테스트 mock 불가, 의존성 주입 깨짐, 멀티스레드 race. 시작이 쉬워서 만들기 시작 → 나중에 빼기 매우 어려움.

싱글턴은 진짜 한 개만 필요한 경우(DB 연결 풀·로거)에만.
그 외엔 — 습관처럼 쓰지 마세요.

SOLID · 5 PRINCIPLES

SOLID 5원칙 — 실생활 비유로

S — 단일 책임 (Single Responsibility)

식당 주방 분담 — 회 뜨는 사람은 회만, 라면은 라면만, 계산은 계산만.
한 명한테 "회 뜨면서 라면 끓이고 계산까지" 시키면 다 망함.

O — 개방·폐쇄 (Open/Closed)

콘센트 + 플러그 — 콘센트는 안 바꿈. 새 가전 사면 그 플러그만 꽂으면 됨.
콘센트 매번 뜯어서 새 가전 연결하지 않음. = 기존 코드 수정 X, 확장 O.

L — 리스코프 치환 (Liskov Substitution)

대체 알바생 — 김 사장 휴가 가도, 박 알바가 와서 똑같이 일해야.
박 알바가 "저는 김치찌개 안 만들어요" 하면 손님 당황. = 자식이 부모 자리 대체 가능해야.

I — 인터페이스 분리 (Interface Segregation)

메뉴판 — 30장짜리 통합 메뉴판이면 한식 한 줄 바뀌어도 전체 다시 인쇄·전 손님 다시 봐야. 카테고리별 4개로 쪼개면 한식 메뉴 바뀌어도 양식 손님은 영향 X.
손님은 자기 카테고리만 봄. = 클라이언트가 안 쓰는 메서드에 의존 X.

D — 의존성 역전 (Dependency Inversion)

ATM — ATM이 "신한 카드만 받음"이면? 새 카드사(KB·우리) 추가될 때마다 ATM 코드 매번 손대야. "카드 인터페이스" 한 번 정해두면 새 카드사도 그대로 꽂힘.
ATM(고수준)이 카드사(저수준)에 직접 의존하지 않고, 둘 다 *카드 인터페이스(추상화)*에 의존 — 의존 방향이 *역전*. = 추상화에 의존, 구체에 의존 X.

출처: Robert C. Martin (Uncle Bob) 2000년대 초 정립.
L은 Barbara Liskov, 1987년 발표 (3화 *다익스트라·리스코프* 다시 호출).

SOLID × CLAUDE

왜 Claude도 SOLID 코드를 좋아하는가

5원칙 × Context Rot 방지 매핑

S

↪ 횟집 주방 — 회만, 라면만, 계산만

한 파일이 *한 책임*만 → Claude가 한 책임만 추적. 여러 일 섞이면 *추측 부담* ↑ → Context Rot 가속.

O

↪ 콘센트 + 플러그 — 콘센트는 안 바꾸고 플러그만 갈아 끼움

새 기능 추가 시 *기존 코드 손대지 않음* → Claude의 "코드 깎다 망가뜨림" 패턴 직접 방지.

L

↪ 대체 알바생 — 김 사장 휴가 가도 박 알바가 똑같이 일함

부모 시그니처만 보면 자식 동작 예측 가능 → Claude의 함수 동작 가정 안전.

I

↪ 메뉴판 — 30장 통합본 X, 카테고리별 4개로

작은 인터페이스 → Claude가 *해당 클래스가 쓰는 것만* 컨텍스트로. 큰 dump 회피.

D

↪ ATM — 어떤 회사 카드든 돈 뽑힘 ("카드 인터페이스"만 봄)

도메인이 추상화에 의존 → DB·API 바뀌어도 도메인 코드 안 건드림 → 헥사고날 직접 연결.

한 줄로: SOLID = Context Rot 방지 + Claude 코드 변경 안전성.

3화 관심사 분리(SoC)가 사실 SOLID의 S입니다.

PART 2

CLI의 심오함

CLI · COMMAND LINE INTERFACE

CLI = 글자로 명령하는 화면

GUI (평소 쓰는 것)

마우스로 버튼

창 열고 클릭

CLI

검은 화면에 글자

명령어 한 줄

개발자가 CLI를 쓰는 이유 — GUI보다 빠름.

진짜 이유 — Claude한테 시키기 딱 좋습니다.
브라우저 GUI 조작은 비효율적 — 화면 보려고 토큰 많이 쓰고, 학습 잘 안 된 페이지면 클릭 위치 못 잡을 수도. CLI는 *글자*라 그런 모호함이 없습니다.

CLI · 명령은 어떻게 흐르는가

사람 → Claude → CLI → 외부 서비스 — 6단계 흐름

→ CLI는 *Claude의 손발* 역할. GUI 조작은 어렵지만 명령줄은 직접 친다.

①

사람

"GitHub 레포
새로 만들어줘"

②

Claude

자연어 →
CLI 명령 변환

③

Shell

gh repo
create ...

④

CLI 바이너리

gh · HTTPS
OAuth Token

⑤

외부 API

api.
github.com

⑥

결과

JSON → stdout
→ Claude → 사람

같은 패턴, 다른 CLI

gh (GitHub) · wrangler (Cloudflare) · supabase (Supabase) · gcloud (GCP) · az (Azure) · vercel (Vercel) — 6단계 구조 동일. 서비스만 바뀜.

사람은 "의도"만 말함. Claude가 "명령" 변환·실행·결과 해석.

PRINCIPLE 06 — DEEPER

CLI도 위임이다 — 공부가 아니라 위임이다

전통 개발자는 외웠습니다. 여러분은 Claude가 외우고 있는 걸 꺼내 씁니다.

전통

매뉴얼 보고 암기

바이브

Claude에게 꺼내 쓰기

완전한 위임 — Claude Code에선 Claude가 직접 터미널을 조작합니다.
여러분은 명령어 치지 마세요.

☕

10분 휴식

잠시 후 — "모르는 단어 앞에서 멈추지 않는 법".

PART 3

모르는 단어 앞에서
멈추지 않는 법

Claude가 새 단어 4개를 쏟아냈을 때
여러분이 해야 할 것.

PRINCIPLE 04 — RECALL

모르는 분야일수록 직접 공부하려 하지 마라

책 사고, 강의만 듣고 그만두지 마십시오. 첫 시작은 — 클로드와 집요하게 의견을 주고받으세요.
책이 필요할 때는 나중에 반드시 옵니다. 하지만 그렇다고 *안 하는 것*은 시류에 맞지 않습니다.

책 한 페이지 = 3분. Claude 한 프롬프트 = 30초.
6배 빠릅니다.

PRINCIPLE 07 — RECALL

기본기는 갈굼의 무기다

4화에서 얘기했죠. 어휘는 직접 코드 짜기 위한 게 아닙니다.

오늘 본 어휘들이 바로 그 무기입니다.

PRINCIPLE 08 — RECALL

직접 깎아봐야 한계가 보인다

한 번 물어본 사람만 "아 이렇게 물어보면 되는구나"를 압니다.

안 물어본 사람은 영원히 모릅니다.

5 SESSIONS — CUMULATIVE

여러분이 5회 동안 쌓은 것

1화

바이브코딩 감 잡기

2화

웹페이지 만들고 올리기

3화

문서로 AI 통제

4화

보안 감각 + F12

5화

모르는 단어 물어보는 습관

이미 바이브코딩을 시작조차 하지 않은 그 누구보다
앞서 계십니다.

BONUS · 기술 선택의 새 기준

디자인 패턴·SOLID 다 넣었어요. 그러면 — 어떤 기술 골라요?

옛날 (~2024)

개발자가 기술 문서 다 뒤져보고, 업계 현황 조사해가면서 기술 선정.

지금 (2026~) — 바이브코더의 새 기준 2가지

① AI가 학습 많이 한 기술인가? — 레퍼런스 찾기 쉬운가?
② AI가 접근·기능 다루기 쉬운 서비스인가? — CLI·API 우아함

서비스 만드는 나 자신의 노력에 —
"이게 AI가 자동으로 일 진행하기 좋은 시스템인가?"
를 고민해야 하는 시대.

기준 ① · AI 학습량

AI가 많이 학습한 기술 = 안전한 선택

예시 1 — 프론트엔드: React vs Vue

React npm 주간 다운로드 ~1억 회
Vue npm 주간 다운로드 ~1천만 회
→ 약 10배 차이 (2026.5 npm trends 기준). AI 학습 데이터(GitHub·StackOverflow 답변)도 비슷한 결로 차이.

AI 학습량 기준에서 React가 압도. 바이브코딩에선 React가 더 안전.

예시 2 — 모바일: Flutter

Flutter 강점 — 단일 코드베이스로 iOS·Android·Web·Desktop 다 빌드.
AI 입장 — *한 코드베이스만 보면 됨.* 따로 iOS, Android 코드 안 짜도 됨.
→ 바이브코더에게 *"AI가 다루기 쉬운"* 구조.

기준 ① — "이 기술, AI가 충분히 학습했나?"
학습량 적은 신생 기술은 — *멋있어 보여도* 바이브코딩에선 위험.

기준 ② · AI 접근성

AI가 자동으로 일하기 쉬운 서비스인가?

호스팅 — Cloudflare vs 다른 곳

Cloudflare (Wrangler CLI) · Vercel (Next.js 특화) — Claude가 가장 쉽게 다룸.
CLI 단순 + API RESTful + 문서 풍부.

CLI 유무 — *Claude 자동화의 사활*

CLI 있음 → Claude가 명령 한 줄로 자동 처리.
CLI 없음 / GUI만 → Claude가 직접 다루기 비효율적. Chrome MCP로 클릭·추적은 가능하지만 — *토큰 많이 먹고*, *학습 잘 안 된 페이지면 제대로 못 할 수도.*
→ 같은 *클라우드*라도 GCP(gcloud) ≈ Azure(az) — 둘 다 CLI 있음. GCP가 *살짝* 더 단순.

바이브코더의 의사결정 — "AI가 자동으로 일 진행하기 좋은 시스템인가?"

TODAY'S KEY TAKEAWAY

01

어휘가 있어야 갈굴 수 있다

어휘는 무기. 원칙 #7 그대로.

02

CLI도 위임이다

외우지 말고 Claude에게 시키세요. 원칙 #6 그대로.

03

모르면 물어본다 · 30초면 됩니다

원칙 #4 그대로.

PART 5

오늘의
숙제

집에서 30초 숙제.

TASK 1 — 필수

지금 내 프로젝트에서 시도해볼 만한 아키텍처에 대해 Claude에 물어보기

먼저 — 코드를 Claude에 다 읽힙니다. 그 다음 → "이 코드 수준에서 클린·헥사고날·FSD 중 어떤 게 맞을까? 무리한 도입은 안 했으면 좋겠어. 진단해줘."
한 모델 답을 100% 신뢰 X. 다른 AI에도 같은 질문 던져 *견적*을 내보세요.

TASK 2 — 선택 · *내 프로젝트 상황에 맞게*

지금 조건에서 기술 선택을 Claude에게 자가 진단받기

▸ 작은 프로젝트(개인용·MVP) → "Vercel·Supabase로 가능한가? CLI는 있는지, 어떻게 설정하는지." 또는 "Firebase가 더 나은지, CLI 있는지."
▸ 호스팅·정식 서버 필요 → "Cloudflare가 나은지, 다른 한국 서비스(Toast·NCP 등)가 나은지. 그 이유와 CLI 완성도까지."
▸ 정식 서버 구성 → "Azure·GCP·AWS 중 내 조건에 어떤 게 맞는지."
▸ 결국 한 줄 → "어떤 회사의 어떤 솔루션이 *Claude 입장에서* 제일 손대기 쉽고 구성하기 편한지."

BEFORE WE CLOSE — META

왜 이 단어들을 다뤘는가

사실 — MVVM·FSD·클린·SOLID·Context Rot, 처음 들으면 지루하고 쓸데없어 보입니다.

이유는 — 인간의 인지 체계 때문이에요. 사람은 단어가 있어야 *현상을 규정*합니다. 그리고 — 인간 인지 체계를 저열하게 카피해서 만든 게 LLM이에요. Claude도 단어를 명시적으로 찍어주지 않으면, 다루는 *저변이 안 넓어집니다*.

— 비트겐슈타인 · 논리철학논고 (1922) 명제 5.6

"내 언어의 한계가
곧 내 세계의 한계다."

단어를 모르면 — 현상을 규정할 수 없습니다.
"클로드가 왜 자꾸 딴 걸 건드려서 망치지?" 매일 겪어도, 그것을 규정할 *단어*가 없으면 — 결국 "AI가 멍청하다"고 욕하는 거 밖에 답이 안 나옵니다.

단어를 가진 사람이,
AI를 부립니다.