[기초-2] 한 번에 다 시키지 마세요: 바이브 코딩에서 큰 요청을 잘게 나누는 법

지난 편에서는 좋은 요청의 기본 구조로 목표·맥락·제약·출력 형식을 정리했습니다. 그런데 이 네 가지를 알고 있어도, 막상 AI에게 “할 일 앱 하나 만들어줘”처럼 큰 요구를 한 번에 던지면 결과가 다시 흐려지기 시작합니다. 답변은 길어지고, 내가 지금 어디부터 확인해야 하는지도 애매해집니다.

초보자가 여기서 자주 오해하는 부분이 있습니다. 요청을 크게 던지면 오히려 빨리 끝날 것 같다는 생각입니다. 하지만 실제로는 그 반대인 경우가 많습니다. 한 번에 너무 많은 기능이 묶이면, 어떤 부분이 핵심이고 어떤 부분이 부가 기능인지 구분하기 어려워지고, 문제가 생겼을 때도 어디서부터 틀어졌는지 좁혀가기 힘들어집니다.

이번 편에서는 그 지점을 다뤄보겠습니다. 핵심은 복잡한 앱을 멋지게 설명하는 데 있지 않습니다. 큰 요구를 작은 작업 단위로 나눠서, AI가 이번 단계에서 무엇만 하면 되는지 분명하게 만드는 법을 익히는 데 있습니다. 예시는 할 일 앱으로 들겠지만, 실제로는 다른 웹페이지나 자동화 작업에도 거의 그대로 적용할 수 있습니다.

이번 글에서 먼저 잡아둘 핵심

겉으로 보이는 변화	실제로 달라지는 것	가장 먼저 봐야 할 지점
답변이 짧아지고 또렷해진다	AI가 이번 단계 범위만 보고 답하게 된다	이번 단계 목표가 한 문장으로 분명한지 먼저 본다
문제가 생겨도 원인을 좁히기 쉬워진다	어느 단계에서 틀어졌는지 확인 구간이 작아진다	방금 추가한 기능만 따로 테스트할 수 있는지 본다
기존 기능을 덜 흔들게 된다	“지금 되는 건 유지하고 이번에는 이것만”이라는 조건을 붙이기 쉬워진다	무엇을 바꾸고 무엇은 건드리지 말지 같이 적었는지 본다

이번 글의 핵심 한 줄
작업을 잘게 나누는 건 일을 느리게 만드는 방법이 아니라, 어디서 틀렸는지 빨리 알기 위한 방법에 가깝습니다.

---

왜 큰 요청이 자꾸 꼬이는가

AI에게 “할 일 앱 만들어줘”라고만 하면 겉보기에는 간단해 보입니다. 하지만 실제로 그 안에는 생각보다 많은 결정이 숨어 있습니다. 화면은 어떻게 구성할지, 입력값 검사는 어떻게 할지, 완료 상태는 어디에 저장할지, 새로고침 뒤에도 남겨둘지, 검색과 필터는 함께 넣을지, 수정 기능은 어떻게 다룰지 같은 문제들이 한꺼번에 따라옵니다.

문제는 초보자일수록 이 결정들이 서로 다른 종류의 작업이라는 점을 잘 구분하기 어렵다는 데 있습니다. 화면을 그리는 일과 데이터를 저장하는 일은 난이도도 다르고, 확인하는 방법도 다릅니다. 그런데 이걸 한 요청에 다 묶어버리면 AI는 빈칸을 스스로 메우기 시작합니다. 그 결과 답변은 그럴듯해 보여도, 지금 내 수준에서 바로 따라가기에는 지나치게 넓어질 수 있습니다.

• HTML 구조를 만드는 일
• 버튼 클릭과 입력 처리를 연결하는 일
• 현재 상태를 따로 기억하는 일
• 필터나 검색처럼 추가 조건을 얹는 일
• 브라우저 저장소나 서버와 연결하는 일

이 다섯 가지는 같은 “앱 만들기” 안에 들어가지만, 실제로는 서로 다른 단계로 보는 편이 훨씬 낫습니다. 초보자가 한 번에 큰 요청을 던졌을 때 자주 막히는 이유도 여기에 있습니다. 답변이 길어서가 아니라, 서로 다른 종류의 작업이 한 덩어리로 들어왔기 때문입니다.

오해하기 쉬운 지점
한 번에 많이 시킨다고 해서 항상 빨라지지는 않습니다. 오히려 수정 범위가 커지고, 문제 지점을 좁히기 어려워져서 다시 돌아가는 시간이 더 길어질 수 있습니다.

---

작업을 나누면 뭐가 달라지는가

작업을 나누면 가장 먼저 달라지는 것은 읽어야 할 양이 아니라 확인해야 할 기준입니다. 예를 들어 “기본 화면만 먼저 만들기”라고 요청하면, 이번 단계에서 볼 것은 화면 구조와 배치 정도입니다. 그다음 “할 일 추가 기능만 붙이기”라고 나누면, 이번에는 입력값 처리와 목록 렌더링만 보면 됩니다. 한 단계에 한 종류의 고민만 남기게 되는 셈입니다.

이렇게 해두면 좋은 점이 꽤 많습니다. 먼저, 결과를 읽는 부담이 줄어듭니다. 어떤 코드를 왜 넣었는지 따라가기 쉬워지고, 내가 바로 확인할 수 있는 범위도 선명해집니다. 둘째, 문제가 생겨도 마지막으로 건드린 구간이 좁기 때문에 디버깅이 훨씬 수월합니다. 셋째, 이미 잘 돌아가는 부분을 유지한 채 다음 단계만 얹는 흐름을 만들 수 있습니다.

1. 답변이 선명해진다
   이번 단계에서 무엇이 핵심인지 분명해진다.
2. 수정 요청이 쉬워진다
   “여기만 고쳐 달라”는 말이 실제로 가능해진다.
3. 기존 기능을 지키기 쉬워진다
   잘 되는 부분을 계속 갈아엎지 않아도 된다.
4. 초보자 기준으로 학습 흐름이 좋아진다
   보이는 변화와 내부 동작을 단계별로 연결해볼 수 있다.

특히 바이브 코딩에서는 이 흐름이 중요합니다. AI는 말을 많이 해줄 수 있지만, 이해는 사용자가 해야 합니다. 그래서 한 번에 많은 기능을 받기보다, 작은 성공을 여러 번 확인하는 방식이 더 오래 갑니다. 실제로는 그쪽이 덜 지치고, 나중에 고칠 때도 훨씬 편합니다.

---

초보자가 먼저 나눠야 할 기준 4가지

그렇다면 무엇을 기준으로 나누면 좋을까요. 처음에는 막연하게 느껴질 수 있지만, 입문자 기준에서는 아래 네 가지로 나누면 대부분 정리가 됩니다. 화면, 동작, 상태, 저장입니다.

초보자가 먼저 나눠보면 좋은 4가지 기준

기준	무엇을 뜻하나	할 일 앱 예시	먼저 확인할 것
화면	무엇이 어디에 보일지 정하는 단계	입력창, 추가 버튼, 목록 영역, 안내 문구 배치	브라우저에서 구조가 읽기 쉽게 보이는지
동작	버튼이나 입력이 실제 기능으로 연결되는 단계	할 일 추가, 완료 체크, 삭제	버튼을 눌렀을 때 기대한 변화가 바로 보이는지
상태	지금 어떤 조건으로 화면을 보여주는지 기억하는 단계	현재 필터, 검색어, 수정 중인 항목	무슨 값을 따로 들고 있고 언제 다시 그리는지
저장	새로고침 뒤에도 데이터를 남기거나 외부와 연결하는 단계	localStorage 저장, 서버 API 연결	새로고침 뒤에도 그대로 유지되는지

이 네 가지를 보면 순서도 어느 정도 보입니다. 초보자라면 보통 화면 → 기본 동작 → 추가 상태 → 저장 순서가 가장 안정적입니다. 반대로 저장을 너무 일찍 붙이면, 지금 막힌 게 화면 문제인지, 자바스크립트 문제인지, 저장소 문제인지 한꺼번에 섞일 수 있습니다.

핵심 포인트
초보자에게는 기능을 많이 붙이는 순서보다, 어떤 종류의 문제를 먼저 다룰지 정하는 순서가 더 중요합니다.

---

할 일 앱 예시로 보는 단계 분해

이제 같은 할 일 앱을 실제로 어떻게 나눌 수 있는지 보겠습니다. 중요한 건 단계 수가 정답이라는 뜻이 아니라, 한 단계에 한 가지 성격의 작업만 남기려는 감각입니다. 아래 정도로 나누면 입문자도 따라가기 훨씬 편합니다.

1. 1단계. 기본 화면만 만든다 입력창, 추가 버튼, 목록 영역, 안내 문구가 보이게 합니다. 아직 아무 기능도 연결하지 않아도 됩니다. 이 단계의 목표는 “브라우저에서 구조가 보이는가”입니다.
2. 2단계. 할 일 추가 기능만 붙인다 입력한 텍스트가 목록에 추가되게 만듭니다. 빈 입력값은 막고, 추가 후 입력창을 비우는 정도까지 보면 충분합니다. 아직 삭제나 완료는 넣지 않아도 됩니다.
3. 3단계. 완료 체크와 삭제를 붙인다 이제 목록 안의 각 항목에 체크박스와 삭제 버튼을 넣습니다. 여기서부터는 “항목 하나의 상태가 바뀐다”는 감각이 생깁니다. 그래도 검색이나 필터는 아직 안 들어가도 됩니다.
4. 4단계. 필터 같은 상태 기능을 추가한다 전체, 진행 중, 완료 같은 보기 조건을 붙입니다. 이 단계는 단순 동작보다 현재 어떤 상태로 목록을 보고 있는가를 다루는 연습에 가깝습니다.
5. 5단계. 저장 기능을 마지막에 붙인다 localStorage처럼 새로고침 뒤에도 남는 기능은 앞 단계들이 안정된 뒤에 넣는 편이 좋습니다. 저장을 너무 이르게 붙이면, 문제가 생겼을 때 원인을 좁히기 어려워집니다.

여기서 중요한 것은 2단계와 3단계를 굳이 합치지 않는 이유입니다. “추가, 완료, 삭제까지 한 번에”도 가능은 합니다. 하지만 초보자에게는 입력값 처리와 항목별 조작이 서로 다른 감각으로 다가옵니다. 그래서 눈에 보이는 변화가 분명한 작은 단계로 나누는 편이 더 배우기 좋습니다.

마찬가지로 검색, 수정, 순서 변경 같은 기능도 각각 따로 떼는 편이 낫습니다. 기능 수가 많아서가 아니라, 그 안에서 새로 등장하는 상태와 예외 처리가 다르기 때문입니다. 즉, 같은 “기능 추가”처럼 보여도 내부에서 다루는 문제가 다르면 단계도 나누는 게 맞다고 보는 편이 좋습니다.

---

AI에게는 이렇게 나눠서 요청하면 된다

작업을 잘게 나누는 감각이 생기면, 이제 그걸 요청 문장에 옮기면 됩니다. 핵심은 세 가지입니다. 이번 단계 목표, 아직 하지 않을 것, 기존에 되는 것은 유지할 것. 이 세 줄만 들어가도 답변의 안정감이 많이 올라갑니다.

1. 전체 계획부터 먼저 뽑아달라고 요청하기

바로 구현으로 들어가기 전에, 먼저 단계를 나눠달라고 요청하는 방식입니다. 초보자에게는 이 단계가 특히 유용합니다. 내가 무엇부터 해야 할지 감을 잡는 데 도움이 되기 때문입니다.

너는 코딩 초보에게 설명하는 웹 개발 튜터다.

할 일 앱을 HTML, CSS, JavaScript만으로 만들고 싶다.
앱을 한 번에 완성하지 말고,
초보자가 따라가기 쉬운 5단계로 나눠서 계획을 제안해줘.

각 단계마다 아래 형식으로 정리해줘.

이번 단계 목표

바뀌는 파일

완료 기준

아직 넣지 않을 것

다음 단계로 넘어가기 전 확인할 점

2. 지금 단계만 구현해달라고 요청하기

계획이 잡혔다면, 그다음에는 현재 단계만 좁혀서 요청하면 됩니다. 이때는 “무엇을 하지 말아야 하는가”를 같이 적는 편이 좋습니다.

지금은 1단계만 진행하자.

할 일 앱의 기본 화면만 만들어줘.
입력창, 추가 버튼, 목록 영역, 안내 문구가 보이면 된다.

아직 JavaScript 기능 연결은 하지 말고,
localStorage, 검색, 필터, 수정 기능도 넣지 말아줘.

답변은 아래 순서로 정리해줘.

바뀌는 파일 설명

전체 코드

직접 확인할 체크리스트

3. 다음 단계로 이어갈 때는 현재 상태를 짧게 요약하기

초보자가 많이 놓치는 부분이 여기입니다. 다음 단계로 넘어갈 때는, 방금까지 어디까지 되었는지 짧게 정리해주는 편이 좋습니다. AI는 내 화면을 보고 있는 것이 아니기 때문에, 현재 상태를 한두 문단으로 다시 넘겨주는 것이 중요합니다.

지금까지는

기본 화면이 보이는 상태이고

입력창과 추가 버튼도 이미 있다.

이번에는 할 일 추가 기능만 연결해줘.
입력값이 비어 있으면 추가되지 않게 해줘.

기존 HTML 구조는 최대한 유지하고,
이번 답변에서는 삭제, 완료 체크, 검색, 필터는 넣지 말아줘.

기존 코드 전체를 처음부터 다시 쓰기보다
바뀌는 부분 위주로 설명해줘.
마지막에는 내가 직접 눌러볼 테스트 순서도 적어줘.

4. 단계가 끝난 뒤에는 검토도 따로 부탁하기

구현 요청과 검토 요청을 한 번에 다 하지 말고, 구현이 끝난 뒤 검토를 따로 한 번 더 돌리는 것도 좋습니다. 특히 입문자에게는 “이번 목표 밖의 변경이 들어갔는지”를 다시 확인하는 과정이 꽤 도움이 됩니다.

방금 구현한 결과를 기준으로 다시 검토해줘.

이번 단계 목표 밖의 변경이 들어갔는지

기존 기능을 깨뜨릴 만한 부분이 있는지

초보자가 복붙했을 때 바로 막힐 수 있는 부분이 있는지

위 세 가지를 체크리스트로 정리해줘.

이 흐름을 보면 알 수 있듯, 좋은 요청은 거창한 문장 하나로 끝나는 경우가 드뭅니다. 오히려 작은 요청을 이어붙이는 방식이 더 현실적이고, 실제 사용에서도 안정적입니다.

---

자주 하는 실수와 확인 체크리스트

작업을 나눈다고 해도, 몇 가지 실수를 반복하면 다시 답이 흔들리기 쉽습니다. 아래 표에 있는 정도만 먼저 피해도 결과가 훨씬 안정됩니다.

작업 분해를 할 때 자주 하는 실수

실수	왜 꼬이는가	어떻게 바꾸면 좋은가
한 단계에 기능을 너무 많이 묶는다	문제가 생겼을 때 어디서 깨졌는지 다시 넓어진다	추가, 삭제, 필터, 저장을 한 번에 넣지 말고 기능 성격별로 나눈다
현재 상태를 설명하지 않고 바로 다음 단계로 넘어간다	AI가 이미 구현된 구조를 추정하게 된다	“지금은 어디까지 됐다”를 짧게라도 먼저 써준다
기존 기능 유지 조건을 빼먹는다	잘 되던 부분까지 통째로 다시 바뀔 수 있다	“기존 구조는 유지하고 이번에는 이것만”을 같이 적는다
단계가 끝났는데 테스트 없이 넘어간다	작은 오류가 다음 단계에서 더 크게 번질 수 있다	매 단계마다 직접 눌러볼 체크리스트를 남긴다

실제로는 아래 다섯 가지만 확인해도 꽤 도움이 됩니다.

• 이번 단계 목표를 한 문장으로 말할 수 있는가
• 이번 단계에서 바뀌는 파일이 무엇인지 알고 있는가
• 아직 넣지 않을 기능을 적어두었는가
• 기존에 되던 기능은 유지하라고 명시했는가
• 구현 뒤에 직접 눌러볼 테스트 3가지를 정했는가

핵심 정리
작업 분해의 목적은 요청을 잘게 자르는 데서 끝나지 않습니다. 각 단계마다 무엇이 성공인지, 무엇은 아직 하지 않을지 같이 정해두는 데 의미가 있습니다.

---

마무리

지난 편에서 좋은 요청의 뼈대를 목표·맥락·제약·출력 형식으로 잡았다면, 이번 편에서는 그 요청을 한 번에 크게 던지지 않고 작은 단계로 나누는 법을 살펴봤습니다. 둘은 따로 노는 기술이 아니라 함께 붙을 때 힘이 납니다. 요청의 구조가 분명해도 단계가 너무 크면 다시 흔들리고, 단계를 잘게 나눠도 맥락이 비어 있으면 엉뚱한 답이 나올 수 있습니다.

결국 초보자에게 중요한 것은 한 번에 멋진 결과를 통째로 받는 일이 아닙니다. 이번 단계에서 무엇이 달라졌는지 이해하고, 그다음 단계를 무리 없이 이어가는 것이 더 중요합니다. 그렇게 해야 AI가 준 답을 그냥 복붙하는 수준을 넘어서, 왜 이렇게 나눴는지까지 조금씩 감이 잡히기 시작합니다.

다음 편에서는 여기서 자연스럽게 이어서, 현재 코드·에러 메시지·화면 상태를 AI에게 어떻게 전달해야 답이 더 정확해지는지를 다루면 흐름이 좋습니다. 작업을 잘게 나누는 법을 익혔다면, 이제는 그 작업의 현재 상태를 덜 헷갈리게 넘기는 법도 같이 알아둘 차례입니다