"분명히 AI가 만들어주긴 했는데... 왜 내가 원하던 게 안 나오죠?"

해봤죠? AI한테 "앱 만들어줘" 해봤죠? 뭔가 나오긴 나와요. 처음엔 신기하기도 하고요.

근데 그거 실제로 쓸 수 있던가요? 기능 추가하려니까 이상하게 꼬이지 않던가요?

그게 정상이에요. 대부분 거기서 막혀요.

문제는 AI가 못해서가 아니에요. 시키는 방법이 잘못된 거예요.

오늘은 그 "시키는 방법"의 핵심을 알려드릴게요.


AI를 어떻게 생각하면 좋을까요?

AI를 갓 입사한 신입 개발자라고 생각해보세요.

AI = 유능한 신입사원
 - 시키면 열심히 해요                    
 - 밤새워도 불평 안 해요                 
 - 기본기는 갖춰져 있어요                 
 - 코딩 실력은 웬만한 개발자보다 나아요    
 근데 신입은 신입이에요.                  
 "알아서 잘 해줘"라고 하면?              
 뭔가 나오긴 하는데... 이게 뭐지?         

AI는 유능한 신입사원: 실력은 뛰어나지만 명확한 지시가 필요해요. AI는 유능한 신입사원: 실력은 뛰어나지만 명확한 지시가 필요해요

코딩 실력은 뛰어난데, 뭘 만들어야 하는지는 몰라요. 그건 여러분이 알려줘야 해요.


"알아서 해줘"의 함정

많은 사람들이 이렇게 생각해요.

"할 일 관리 앱이야.
 - 할 일 추가, 삭제, 완료 체크 가능해야 해
 - 완료한 건 아래로 내려가게
 - 오늘 할 일만 따로 보는 기능도 있으면 좋겠어
 - 스마트폰에서 돌아가게 만들어줘"

→ 이 정도면 구체적인 거 아냐?

아니에요. 이것도 "알아서 해줘"예요.

왜냐면, AI는 이런 걸 모르거든요:

  • "할 일 추가"할 때 버튼이 어디 있어야 하는지
  • 완료 체크하면 바로 내려가야 하는지, 애니메이션이 있어야 하는지
  • 오늘 할 일 화면에서 뒤로 가기 누르면 어디로 가야 하는지

기능 목록을 줘도, "사용자 경험"은 AI가 알아서 못 만들어요.


진짜 구체적 지시란?

진짜 구체적 지시는 이런 거예요.

진짜 구체적 지시 = 한 입 크기로
 1단계: 기획 문서 먼저 만들기                                
       "이 앱이 뭔지, 누가 쓰는지, 핵심 기능이 뭔지"          
       → AI한테 같이 정리하자고 해도 됨                      

 2단계: 기능 하나씩 지시하기                                 
       "먼저 할 일 추가 버튼만 만들어줘"                      
       → 확인하고, 피드백하고, 다음으로                      

 3단계: 바로바로 피드백                                      
       "버튼 위치가 좀 애매한데, 오른쪽 아래로 옮겨줘"         
       → 고치고, 확인하고, 다음으로                          

비결은 한 입 크기: 계획 → 기능 → 피드백의 반복 비결은 한 입 크기: 계획 -> 기능 -> 피드백의 반복

왜 이렇게 해야 할까요?

기술적인 이유가 있어요.

💡 AI의 구조적 한계
1. 토큰 제한
   AI가 한 번에 읽고 쓸 수 있는 양에 물리적 한계가 있어요.
   "토큰"이라는 단위로 제한되는데,
   복잡한 앱을 한 번에 다 만들라고 하면 이 한계에 부딪혀요.

2. 대화 압축 → 맥락 소실
   대화가 길어지면, AI는 이전 내용을 "압축"해서 기억해요.
   그 과정에서 중요한 맥락이 빠지거나 왜곡돼요.
   "아까 말한 그 기능"이 뭔지 AI가 헷갈리기 시작하는 거예요.

3. 사용자 컨펌 없이는 UX 불가능
   AI 내부에 아무리 똑똑한 시스템이 있어도,
   "이게 내가 원하던 느낌이야"는 결국 사람만 판단할 수 있어요.
   버튼 위치, 색상, 동작 속도... 이런 건 써봐야 알아요.

그리고 한 가지 더.

⚠️ "잘했겠지" 전제의 위험
기능 A 만들고 → 확인 안 하고 → 기능 B 만들고 → 확인 안 하고...

이러다 나중에 보면 기능 A에 버그가 있어요.
근데 그 위에 B, C, D를 쌓아버렸어요.

마치 1층 기둥이 비뚤어진 줄 모르고
2층, 3층 올린 아파트처럼요.

나중에 고치려면? 거의 처음부터 다시 해야 해요.

그래서 "하나 만들고 → 확인하고 → 다음"이 결국 더 빨라요.

좋은 지시 vs 나쁜 지시

❌ 나쁜 지시 (한 번에 다 시키기)
"할 일 앱 만들어줘. 추가, 삭제, 완료, 오늘 할 일 보기 기능 있어야 해"
→ 뭔가 나오긴 하는데, 내가 원하던 게 아님

⚠️ 그나마 나은 지시 (기능 목록)
"할 일 앱인데, 이런 기능들이 필요해: [목록]"
→ 돌아가긴 하는데, UX가 별로임

✅ 좋은 지시 (한 입 크기 + 피드백)
"할 일 앱 만들 건데, 먼저 기획 문서부터 같이 정리하자"
→ "좋아, 이제 할 일 추가 화면부터 만들어보자"
→ "버튼이 너무 작은데, 더 크게 해줘"
→ "완료 체크하면 0.3초 뒤에 아래로 내려가게 해줘"
→ 진짜 쓸 만한 앱

핵심은 "대화"예요.

AI한테 뭔가 시키면, 터미널(검은 화면)에 AI가 뭘 하고 있는지 다 보여요.

🎯 실시간으로 확인하세요
- AI가 지금 어떤 파일을 열고 있는지
- 어떤 코드를 고치고 있는지
- 터미널에서 다 보여요

"어? 내가 시킨 게 이게 아닌데?" 싶으면
ESC 눌러서 멈추고, 다시 프롬프트하면 돼요.
엄한 짓 하고 있는 거 끝까지 기다릴 필요 없어요.

그리고 이게 중요해요.

AI가 뭘 하고 있는지 알려면, 코드도 볼 줄 알아야 해요.

⚠️ 잠깐, 코드를 알아야 한다고요?
"짜는 것"과 "보는 것"은 달라요.

❌ 코드를 직접 짜는 것 → AI가 해줌
✅ 코드를 읽고 이해하는 것 → 여러분이 해야 함

AI가 "login.js 파일을 수정했어요"라고 하면,
뭘 어떻게 고쳤는지 대충이라도 알아야
"아 그거 말고 다른 거 고쳐줘"라고 할 수 있거든요.

이 시리즈에서 코드 읽는 법도 천천히 알려드릴게요.

프로젝트의 로직은 결국 만드는 사람 머리에 있어야 해요.

AI가 코드를 짜주지만, "이게 맞는 방향인지"는 여러분이 판단해야 해요. 그래야 AI가 엄한 길로 갈 때 잡아줄 수 있거든요.

🎯 바이브 코딩이란?
처음부터 완벽하게 만들 수 없어요.
그건 AI도 마찬가지예요.

대화를 통해서
→ 빠르게 만들고
→ 확인하고 (코드도 보면서)
→ 고치고
→ 다시 만들고

이렇게 진전시켜 나가는 게 바이브 코딩이에요.

유능한 매니저의 3가지 조건

AI라는 신입사원한테 좋은 결과물을 받으려면, 유능한 매니저가 되어야 해요.

유능한 매니저가 되는 법
1. 뭘 만들지기획 문서로 정리하기
명확히 하기"이런 사람이 이렇게 쓸 앱이야"
2. 한 입 크기로한 번에 하나씩 시키기
나누기"먼저 이 화면만 만들어줘"
3. 바로바로결과 보고 즉시 피드백
피드백하기"여기 이렇게 고쳐줘" → 확인 → 다음

"잠깐, 그러면 오래 걸리지 않아요?"

처음엔 그렇게 느껴질 수 있어요. 근데 "한 번에 다 시키고 → 마음에 안 들어서 처음부터 다시"보다 훨씬 빨라요.

마치 건축 현장 소장이 "집 한 채 알아서 지어줘"라고 안 하듯이, "기초 먼저 → 기둥 세우기 → 벽 쌓기" 순서로 하나씩 확인하면서 가는 거예요.


이 시리즈에서 배울 것

이 시리즈는 코딩을 가르치지 않아요.

대신 이런 걸 알려드릴 거예요:

✅ 어떤 종류의 프로그램이 있는지
   → 웹? 앱? 자동화? 각각 뭐가 다른지

✅ AI한테 뭘 시켜야 하는지
   → "예쁘게 만들어줘" 대신 뭐라고 해야 하는지

✅ 필요한 도구 세팅하는 법
   → 클로드 코드 설치부터 첫 실행까지

✅ 실제로 뭔가 만들어보기
   → 웹페이지, 자동화 봇, 데이터 다루기

다 읽고 나면, AI한테 **"진짜 쓸 만한 것"**을 만들어달라고 할 수 있게 될 거예요.


코딩을 배우는 게 아니에요

다시 한번 강조할게요.

❌ 우리가 할 것: 코드 직접 짜기
✅ 우리가 할 것: AI한테 잘 시키기

AI가 코드를 짜요. 여러분은 **"뭘 만들지 결정하고, 방향을 잡아주는 사람"**이에요.

🎯 바이브 코딩이란?
"만들고 싶은 것의 느낌(vibe)을 AI한테 전달해서 만드는 것"

코드는 몰라도 돼요.
근데 뭘 만들고 싶은지는 알아야 해요.
그리고 그걸 AI가 알아들을 수 있게 말해줘야 해요.

셀프체크

오늘 배운 내용, 제대로 이해했는지 확인해볼까요?

□ AI한테 "알아서 해줘"라고 말하면 될까요?
□ AI는 코딩을 잘하나요, 기획을 잘하나요?

(정답: 안 됨, AI는 방향을 모르니까 / 코딩은 잘하지만 기획과 판단은 못 함)

다음 글 예고

오늘은 가장 중요한 개념을 배웠어요.

  • AI는 유능한 신입사원 (코딩은 잘하지만 방향은 모름)
  • 기능 목록만 줘도 "알아서 해줘"임 (UX는 못 만듦)
  • 한 입 크기로 나눠서 + 바로바로 피드백해야 함
  • 코딩이 아니라 "AI와 대화하는 법"을 배울 것

다음 글에서는 바이브 코딩이 뭔지 조금 더 구체적으로 알아볼게요.

  • 전통적인 코딩과 뭐가 다른지
  • 어떤 사람들이 바이브 코딩으로 뭘 만들고 있는지
  • 왜 지금이 시작하기 좋은 타이밍인지

이 시리즈 로드맵

PART 1: 마인드셋 (4편)
[ 1편 ] AI는 유능한 신입사원이다 ← 지금 여기! ✅
[ 2편 ] 바이브 코딩이란 무엇인가
[ 3편 ] 바이브 코더가 알아야 할 것
[ 4편 ] 목표 수준: 기술적 지시가 가능한 매니저
   ↓
PART 2: 기술 개념 - 큰 그림 (6편)
[ 5편 ] 프로그램의 종류 (웹앱 vs 네이티브앱)
[ 6편 ] 프론트엔드 vs 백엔드
[ 7편 ] 데이터는 어디에 저장되나
[ 8편 ] 서비스들이 대화하는 방법: API
[ 9편 ] 프로젝트 구조
[ 10편 ] 데이터 흐름
   ↓
PART 3: 기술 개념 - 설계 (5편)
[ 11~15편 ] 자료구조, 아키텍처, 디자인 패턴, 상태 관리
   ↓
PART 4: 도구 세팅 (5편)
[ 16~20편 ] Claude Code, 터미널, VS Code, Git, 환경 세팅
   ↓
PART 5: 첫 프로젝트 - 할 일 관리 웹앱 (4편)
PART 6: 두 번째 프로젝트 - 자동화 봇 (4편)
PART 7: 세 번째 프로젝트 - 데이터 대시보드 (4편)
   ↓
PART 8: 독립 성장 (3편)
[ 33~35편 ] 에러 읽기, AI와 디버깅, 앞으로의 여정

오늘의 핵심 정리

✅ AI = 유능한 신입사원
   → 코딩 실력은 뛰어나지만, 뭘 만들지는 모름

✅ 기능 목록만 줘도 "알아서 해줘"임
   → AI는 사람의 의도와 UX를 알아서 못 만들어요

✅ 진짜 구체적 지시 = 한 입 크기 + 피드백
   → 기획 먼저 → 기능 하나씩 → 바로 피드백 → 다음

✅ 코딩을 배우는 게 아니라 "AI와 대화하는 법"을 배우는 것
   → 한 번에 완성품 X, 같이 만들어 나가기 O

AI 시대에 필요한 건 코딩 실력이 아니에요. "뭘 만들지 아는 것", 그리고 "그걸 AI한테 잘 전달하는 것"이에요.

궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!