'그냥 만들어줘'가 실패하는 순간 | 요구사항·기술 스택
"Todo 앱 만들어줘"가 어긋나는 이유를 짚고, 요구사항과 기술 스택의 공백을 메워 AI의 추측을 줄이는 법을 배웁니다
Overview
이제 작은 Todo 앱을 만들 차례입니다. 그런데 빈 폴더에서 AI에게 "Todo 앱 만들어줘"라고 입력하면, 원하지 않은 결과가 나오기 쉽습니다. 같은 한 줄에서 AI가 무엇을, 어떤 기술로 만들지를 스스로 추측해서 채우기 때문입니다.
이 레슨은 그 원리인 'AI는 빈칸을 추측으로 메운다'를 짚고, 무엇을 만들지와 무엇으로 만들지를 미리 정해 AI의 추측을 줄이는 법을 다룹니다.
학습 목표
- AI가 빈칸을 추측으로 메우는 원리를 이해합니다
- 요구사항의 공백이 AI에게 어떤 결정을 넘기는지 설명할 수 있습니다
- AI 협업에 유리한 기술 스택의 선택 기준을 이해합니다
AI의 빈칸 추측 메우기
LLM은 입력받은 프롬프트에 비어 있는 부분이 있으면 확률적으로 그럴듯한 값으로 채웁니다. LLM 기초 레슨에서 본 "다음 단어를 예측하는 확률 시스템"이라는 본성이 그대로 드러나는 작동 방식입니다. 비어 있는 자리가 많을수록 추측이 넓어지고, 의도에서 벗어난 코드가 나올 확률이 높아집니다.
"Todo 앱 만들어줘"가 AI에게 주는 것
프롬프트 하나를 해부해 봅니다.
"Todo 앱 만들어줘"
AI가 이 문장에서 확정 지을 수 있는 것은 하나입니다. "Todo 앱"이라는 대략적 카테고리. 나머지는 전부 빈칸입니다.
- 완료 표시는 체크박스인가, 스와이프인가, 길게 누르기인가
- 정렬은 생성순인가, 마감일순인가, 수동 순서인가
- 삭제는 즉시인가, 확인 창인가, 되돌리기가 있는가
- 프레임워크는 React 인가, Vue 인가, Svelte 인가
AI는 이 빈칸을 전부 "가장 그럴듯한 값"으로 채운 뒤 코드를 씁니다. 결과를 본 개발자가 "이건 내가 원한 게 아닌데"라고 말하는 순간은, AI가 잘못한 게 아니라 개발자가 비워둔 자리에서 일어난 일입니다.
이 빈칸은 두 영역에 몰려 있습니다. 무엇을 만들지(요구사항), 어떤 기술로 만들지(기술 스택). 각각에서 AI가 무엇을 대신 정하게 되는지 하나씩 풀어보겠습니다.
요구사항의 공백: AI에게 넘어가는 세부 결정
모호한 요구사항
AI 가 해석을 채움- 에러 메시지?
- 토스트 알림?
- 무반응?
AI 가 “가장 그럴듯한” 해석 하나를 고름
구체적 요구사항
동작이 명시됨AI 가 결정할 자리가 없음
위에서 본 "Todo 앱 만들어줘"가 전형적입니다. 요구사항이 모호하면 AI는 질문을 멈추고 기다리기보다, 그럴듯한 기본값을 정해 작업을 이어 갑니다. 개발자가 정하지 않은 결정은 그 기본값을 따라갑니다.
나쁜 예: "빈 입력 처리를 해줘"
좋은 예: "사용자가 빈 입력 상태에서 Enter를 누르면, Todo가 추가되지 않고 입력 필드에 빨간 테두리가 표시된다"
나쁜 예에서 AI는 "빈 입력을 어떻게 처리할지"를 스스로 정합니다. 에러 메시지인가, 토스트인가, 무반응인가. 좋은 예에서는 행동과 결과를 명시해 AI가 결정할 자리가 없습니다.
공백을 메우는 두 섹션: 기능 목록 + 범위 제한
요구사항 문서에 특별한 포맷은 필요 없습니다. 자연어로 두 섹션만 정리해도 빈칸 대부분이 사라집니다.
① 기능 목록: 기능 목록에는 사용자의 행동과 그 결과를 함께 적습니다. "사용자가 ~하면, ~된다"처럼 한 줄에 하나의 동작만 담습니다.
## 기능 목록
1. 사용자가 텍스트를 입력하고 Enter 를 누르면, 새 Todo 가 목록 맨 위에 추가된다
2. 사용자가 Todo 의 체크박스를 클릭하면, 완료 상태로 표시되고 텍스트에 취소선이 그어진다
3. 사용자가 Todo 의 삭제 버튼을 클릭하면, 해당 항목이 목록에서 제거된다
4. 페이지를 새로고침하면, 이전 Todo 목록이 유지된다 (localStorage)② 범위 제한: 무엇을 만들지 않는가. AI가 "있으면 좋을 것 같아서" 덧붙이는 기능을 차단합니다.
## 범위 제한
- 사용자 인증/로그인
- 서버 사이드 데이터 저장 (localStorage 만)
- 드래그 앤 드롭 정렬
- 카테고리/태그 시스템
- 다크 모드범위 제한이 필요한 이유
경계를 명시하지 않으면 AI가 "이것도 있으면 좋을 것 같습니다" 라며 요청하지 않은 기능을 구현하기 시작합니다. 범위 제한은 "여기까지만"이라는 울타리를 쳐서, AI가 채울 자리 자체를 없애는 장치입니다.
기술의 공백: 낯선 스택일수록 커지는 추측
빈칸은 요구사항 쪽에만 있는 게 아닙니다. 개발자가 선택한 프레임워크·라이브러리를 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 라이브러리 | Shadcn | |
|---|---|---|
| 컴포넌트 위치 | node_modules (블랙박스) | components/ui/ (내 코드) |
| AI의 접근 방식 | 문서·추측 | 파일을 직접 열어 읽음 |
| 수정 방식 | props·테마로 조정 | 컴포넌트 코드 직접 편집 |
소스 코드가 프로젝트 안에 있으니 AI가 추측하는 대신 코드를 직접 읽고 판단합니다. Tailwind CSS 클래스가 컴포넌트 코드 안에 함께 적혀 있어, AI가 구조와 스타일을 한 파일에서 같이 읽을 수 있습니다.
왜 이 조합이 AI 친화적인가
이 조합이 AI 친화적인 이유는 두 가지입니다. AI는 Next.js처럼 학습 데이터가 많이 쌓인 기술을 더 익숙하게 다루고, Shadcn처럼 소스 코드가 프로젝트 안에 있는 도구는 직접 읽고 판단할 수 있습니다. 둘 다 AI가 추측해야 할 빈칸을 줄입니다.
핵심 포인트 정리
- AI는 빈칸을 추측으로 메웁니다: 프롬프트에 비어 있는 자리가 많을수록 결과가 의도에서 멀어집니다. 빈칸의 크기가 곧 추측의 크기입니다.
- 요구사항의 공백은 두 섹션으로 메웁니다: 기능 목록("사용자가 ~하면, ~된다")으로 무엇을 만들지, 범위 제한으로 무엇을 만들지 않을지 명시하면 AI가 대신 결정할 자리가 사라집니다.
- 기술의 공백은 스택 선택으로 메웁니다: Next.js처럼 학습 데이터가 많이 쌓인 기술과, Shadcn처럼 소스 코드가 프로젝트 안에 있는 라이브러리를 고르면 AI의 추측 여지가 줄어듭니다.
FAQ
이어서 배울 내용
요구사항과 기술 스택을 정해도 AI는 아직 지금 프로젝트의 구조를 모릅니다. 다음 레슨에서는 Plan Mode로 AI가 먼저 프로젝트 구조를 읽고 계획을 세우게 만드는 방법을 다룹니다.
- Plan Mode가 쓰기 도구를 막아 탐색을 강제하는 방식
- 탐색 → 계획 → 실행 사이클