AI가 추측하지 않게 | 요구사항·기술 스택

Overview

Plan Mode 레슨에서 AI가 코드베이스를 탐색한 뒤 계획을 세우게 만들었습니다. 그런데 Plan Mode에 들어가기 전에 한 단계가 더 있습니다. AI에게 무엇을, 어떤 기술로 만들지 알려주는 일입니다. 이 두 자리가 비어 있으면 AI는 같은 방식으로 추측합니다.

이 레슨은 그 원리인 AI는 빈칸을 추측으로 메운다를 정의하고, 그 원리가 요구사항과 기술 스택에서 각각 어떻게 드러나는지, 두 공백을 어떻게 메우는지 살펴봅니다.

학습 목표

• AI가 빈칸을 추측으로 메우는 원리를 이해합니다
• 요구사항의 공백이 AI에게 어떤 결정을 넘기는지 설명할 수 있습니다
• AI 협업에 유리한 기술 스택의 선택 기준을 이해합니다

AI의 빈칸 추측 메우기

LLM은 입력받은 프롬프트에 비어 있는 부분이 있으면 확률적으로 그럴듯한 값으로 채웁니다. LLM 기초 레슨에서 본 "다음 단어를 예측하는 확률 시스템"이라는 본성에서 바로 이어지는 성질입니다. 비어 있는 자리가 많을수록 추측이 넓어지고, 의도에서 벗어난 코드가 나올 확률이 높아집니다.

"Todo 앱 만들어줘"가 AI에게 주는 것

프롬프트 하나를 해부해 보겠습니다.

"Todo 앱 만들어줘"

AI가 이 문장에서 확정 지을 수 있는 것은 하나입니다. "Todo 앱"이라는 대략적 카테고리. 나머지는 전부 빈칸입니다.

• 완료 표시는 체크박스인가, 스와이프인가, 길게 누르기인가
• 정렬은 생성순인가, 마감일순인가, 수동 순서인가
• 삭제는 즉시인가, 확인 창인가, 되돌리기가 있는가
• 프레임워크는 React 인가, Vue 인가, Svelte 인가

AI는 이 빈칸을 전부 "가장 그럴듯한 값"으로 채운 뒤 코드를 씁니다. 결과를 본 개발자가 "이건 내가 원한 게 아닌데"라고 말하는 순간은, AI가 잘못한 게 아니라 개발자가 비워둔 자리에서 일어난 일입니다.

이 빈칸은 두 영역에 몰려 있습니다. 무엇을 만들지(요구사항), 어떤 기술로 만들지(기술 스택). 각각이 AI에게 어떤 추측을 넘기는지 이어서 봅니다.

요구사항의 공백: AI에게 넘어가는 세부 결정

요구사항이 모호하면 AI는 자율적으로 세부를 정합니다. 앞 섹션의 "Todo 앱 만들어줘"가 전형적입니다. AI는 도움이 되도록 훈련돼 있어서, 되묻기보다 일단 만들어 보는 쪽으로 기웁니다. 개발자가 세부를 채워 주지 않으면 AI가 채워 버립니다.

나쁜 예: "빈 입력 처리를 해줘"

좋은 예: "사용자가 빈 입력 상태에서 Enter를 누르면, Todo가 추가되지 않고 입력 필드에 빨간 테두리가 표시된다"

나쁜 예에서 AI는 "빈 입력을 어떻게 처리할지"를 스스로 정합니다. 에러 메시지인가, 토스트인가, 무반응인가. 좋은 예에서는 행동과 결과가 명시되어 있어 AI가 결정할 자리가 없습니다.

공백을 메우는 두 섹션: 기능 목록 + 범위 제한

요구사항 문서에 특별한 포맷은 필요 없습니다. 자연어로 두 섹션만 정리해도 빈칸 대부분이 사라집니다.

① 기능 목록: 무엇을 만드는가. 각 기능을 "사용자가 ~하면, ~한다" 형식으로 적습니다. 한 줄에 하나의 동작, 동작과 결과를 함께.

## 기능 목록

1. 사용자가 텍스트를 입력하고 Enter 를 누르면, 새 Todo 가 목록 맨 위에 추가된다
2. 사용자가 Todo 의 체크박스를 클릭하면, 완료 상태로 표시되고 텍스트에 취소선이 그어진다
3. 사용자가 Todo 의 삭제 버튼을 클릭하면, 해당 항목이 목록에서 제거된다
4. 페이지를 새로고침하면, 이전 Todo 목록이 유지된다 (localStorage)

② 범위 제한: 무엇을 만들지 않는가. AI가 "있으면 좋을 것 같아서" 덧붙이는 기능을 차단합니다.

## 범위 제한

- 사용자 인증/로그인
- 서버 사이드 데이터 저장 (localStorage 만)
- 드래그 앤 드롭 정렬
- 카테고리/태그 시스템
- 다크 모드

기술의 공백: 낯선 스택일수록 커지는 추측

빈칸은 요구사항 쪽에만 있는 게 아닙니다. 개발자가 선택한 프레임워크·라이브러리를 AI가 얼마나 정확히 아는가에도 공백이 생깁니다. 이 공백은 Hallucination의 주무대입니다. AI는 낯선 API에 대해서도 자신만만하게 틀립니다.

학습 데이터에 자주 등장한 기술일수록 AI의 기억이 촘촘하고, 드물게 등장한 기술일수록 빈칸이 많아 추측이 커집니다. 같은 AI에게 같은 일을 시켜도, 어떤 스택 위에서 시키느냐에 따라 결과 품질이 달라집니다.

AI 친화 스택: Next.js + Shadcn

이 강의는 실습 스택으로 Next.js + Shadcn을 씁니다. 선택 기준은 하나입니다. AI가 얼마나 잘 아는가.

Next.js는 React 위에 얹은 full-stack 프레임워크입니다. React 자체가 가장 널리 쓰이는 프론트엔드 라이브러리이고, Next.js는 그 위에서 학습 데이터가 가장 두텁습니다. 다른 프레임워크보다 최신 패턴에 가까운 코드가 나올 확률이 높습니다.

Shadcn은 UI 컴포넌트 라이브러리지만 작동 방식이 다릅니다. 일반 UI 라이브러리는 node_modules 에 설치돼 블랙박스로 동작합니다. AI가 컴포넌트 속을 보려면 문서에 기댈 수밖에 없습니다. Shadcn은 컴포넌트 소스를 프로젝트 안으로 복사합니다. components/ui/button.tsx 처럼 내 코드가 됩니다. 덕분에 AI가 파일을 열어 구조를 직접 읽고, 필요하면 바로 수정합니다. 추측 대신 보고 판단합니다.

Shadcn 컴포넌트는 내부적으로 Tailwind CSS로 스타일링됩니다. Tailwind는 스타일을 별도 CSS 파일이 아니라 HTML 클래스에 직접 적습니다. 덕분에 AI가 컴포넌트 파일 하나만 읽으면 구조와 스타일을 동시에 파악합니다. Shadcn을 고르면 Tailwind는 자연스럽게 따라오므로 별도로 고민할 필요가 없습니다.

핵심 포인트 정리

1. AI는 빈칸을 추측으로 메웁니다: 프롬프트에 비어 있는 자리가 많을수록 결과가 의도에서 멀어집니다. 빈칸의 크기가 곧 추측의 크기입니다.
2. 요구사항의 공백은 두 섹션으로 메웁니다: 기능 목록("사용자가 ~하면, ~한다")으로 무엇을 만들지, 범위 제한으로 무엇을 만들지 않을지 명시하면 AI가 대신 결정할 자리가 사라집니다.
3. 기술의 공백은 스택 선택으로 메웁니다: Next.js처럼 학습 데이터가 두터운 기술과, Shadcn처럼 소스가 프로젝트 안에 있는 라이브러리를 고르면 AI의 추측 여지가 줄어듭니다.

FAQ

• Q: 요구사항을 영어로 써야 더 좋은 결과가 나오나요?

  • A: Claude는 한국어 요구사항을 잘 이해합니다. 영어로 쓸 때 약간의 정확도 향상이 있을 수 있지만, 구체성이 언어보다 훨씬 큰 영향을 미칩니다. 편한 언어로 구체적으로 쓰는 것이 최선입니다.

• Q: Next.js·Shadcn 외에 다른 스택은 AI와 잘 안 맞나요?

  • A: 그렇지 않습니다. 기준은 "학습 데이터에 충분히 등장하는가" 이고, 이에 해당하는 기술은 많습니다. Amplifying.ai가 Claude Code 응답 2,430 건을 분석한 결과, UI 컴포넌트는 shadcn/ui(90%), 스타일링은 Tailwind CSS(68%), DB는 PostgreSQL(58%), 상태 관리는 Zustand(65%)를 선호했습니다. 자세한 데이터는 What Claude Code Actually Chooses에서 확인할 수 있습니다.

• Q: 낯선 라이브러리는 쓰지 말아야 하나요?

  • A: 그렇지 않습니다. 빈칸을 외부에서 채우면 됩니다. 공식 문서·예제 코드를 직접 컨텍스트에 넣거나(CLAUDE.md·llms.txt), Context7 같은 MCP 서버로 최신 문서를 자동 주입하는 방법이 있습니다. 다만 학습 단계에서는 AI가 잘 아는 스택으로 시작하는 편이 빠르고, MCP 활용은 Part 3에서 다룹니다.

이어서 배울 내용

요구사항의 공백과 기술의 공백을 메우는 방법을 배웠습니다. 다음 레슨에서는 이 개념들을 한 사이클로 이어서 실행합니다. 프로젝트 생성부터 CLAUDE.md 설정, 요구사항 작성, Plan Mode 계획 수립, 구현, 브라우저 검증까지 다룹니다.

• bun 설치와 프로젝트 생성
• Shadcn preset으로 디자인 토큰 설정
• CLAUDE.md 작성
• 요구사항 → Plan Mode → 구현 → 검증 전체 사이클