22장. 한 번에 시키지 않고 잘게 나누어 시키는 법

AI 코딩 도구를 처음 쓰는 사람일수록 자주 이렇게 말합니다.

서비스 하나를 통째로 설명하고, 로그인도 넣고, 글 작성도 넣고, 검색도 넣고, 배포 준비도 같이 해달라고 하면 더 빠르지 않을까요?

마음은 충분히 이해됩니다. 한 번에 끝내고 싶으니까요. 하지만 실제로는 그 반대인 경우가 많습니다. 큰 요청은 처음엔 시원해 보이지만, 중간부터 방향이 흐려지고, 내가 무엇을 승인하는지도 모르게 만들기 쉽습니다. AI는 많은 일을 한 번에 처리할 수 있지만, 초보자가 그 결과를 한 번에 이해하고 검토하기는 어렵습니다.

그래서 중요한 원칙이 하나 있습니다.

복잡한 기능일수록 한 번에 시키지 말고, 잘게 나누어 시켜야 합니다.

이 원칙은 AI를 배려하는 요령이 아닙니다. 사실은 나 자신을 지키는 작업 방식입니다. 작은 단위로 나누면 무엇이 바뀌었는지 이해하기 쉽고, 어디서 꼬였는지 찾기 쉬우며, 잘못되었을 때 되돌리기도 쉽습니다. Claude Code의 계획 모드나 태스크 분할 흐름, Codex의 단계별 프롬프팅 가이드도 이런 방식을 권합니다.¹²³

이번 장에서는 복잡한 기능을 작은 작업으로 쪼개는 기준과, AI에게 단계별로 요청하는 실전 전략을 익혀보겠습니다.

왜 큰 요청은 자주 꼬일까

큰 요청이 위험한 이유는 단순합니다. 한 번의 답변 안에 너무 많은 결정이 섞이기 때문입니다. 화면 구조, 상태 관리, 서버 호출, 데이터 저장, 에러 처리, 스타일, 테스트까지 한꺼번에 들어가면, 어느 한 부분이 어긋났을 때 다른 부분까지 같이 흔들립니다.

예를 들어 이런 요청을 생각해봅시다.

우리 서비스에 회원가입, 로그인, 글 작성, 수정, 삭제, 검색, 정렬, 마이페이지까지 한 번에 추가해줘.

이 요청은 듣기만 해도 멋집니다. 하지만 실제로는 너무 많은 질문이 숨어 있습니다. 로그인은 이메일 기반인지 소셜 로그인인지, 글은 누구나 볼 수 있는지, 검색은 제목만 볼지 내용까지 볼지, 마이페이지에는 무엇을 보여줄지 전부 결정해야 합니다. AI는 빈칸을 만나면 그럴듯하게 채우려는 경향이 있습니다. 문제는 그 빈칸이 많을수록, 그럴듯하지만 내가 원하지 않는 방향으로 갈 가능성도 커진다는 점입니다.

큰 작업은 실수의 크기도 함께 키웁니다. 작은 작업은 작게 틀리고 빨리 고칠 수 있지만, 큰 작업은 크게 틀리고 나중에야 티가 납니다. 결국 처음엔 빨라 보였던 길이, 나중에는 가장 먼 길이 되곤 합니다.⁴⁵

잘게 나눈다는 것은 어디까지일까

그렇다고 모든 일을 원자 단위로 쪼개라는 뜻은 아닙니다. 너무 잘게 쪼개면 흐름이 끊기고, 오히려 전체 그림을 잃을 수 있습니다. 중요한 것은 가장 작은 단위가 아니라, 가장 검토하기 좋은 단위를 찾는 것입니다.⁴⁵

초보자에게는 다음 네 가지 기준이 특히 유용합니다.

• 한 번에 목표가 하나여야 합니다.

• 끝났는지 확인하는 방법이 분명해야 합니다.

• 바뀌는 범위가 좁아야 합니다.

• 이상하면 바로 되돌릴 수 있어야 합니다.

예를 들어 글 작성 기능을 만든다고 합시다. 이때 글 작성 화면 만들기, 입력값 저장 연결하기, 저장 후 목록에 반영하기, 빈값 검증 넣기, 작성자만 수정 가능하게 하기까지를 한 번에 묶으면 큽니다. 반면 글 작성 페이지 레이아웃 만들기처럼 눈으로 바로 확인할 수 있는 단위는 작고 좋습니다.

좋은 작업 단위는 보통 이런 느낌입니다.

오늘 이 단계가 끝나면 무엇이 달라졌는지 한 문장으로 말할 수 있다.

이 기준이 의외로 강력합니다. 한 문장으로 설명이 안 되면, 아직 작업이 너무 큰 경우가 많습니다.

초보자에게 특히 좋은 세 가지 분해 방식

기능을 쪼갤 때 늘 같은 방식만 쓸 필요는 없습니다. 상황에 따라 자르는 기준이 달라집니다.

화면 기준으로 나누기

가장 쉬운 방식입니다. 사용자가 실제로 보는 화면 단위로 나누는 것입니다. 예를 들어 홈 화면, 글 목록 화면, 글 상세 화면, 글 작성 화면처럼 나누면 초보자도 이해하기 쉽습니다.

이 방식의 장점은 결과가 눈에 잘 보인다는 점입니다. 무엇이 바뀌었는지 바로 확인할 수 있으니 검토가 쉽습니다. 프론트엔드를 만들 때 특히 잘 맞습니다.

흐름 기준으로 나누기

사용자의 행동 순서대로 나누는 방식입니다. 예를 들어 회원가입에서는 입력, 제출, 성공 메시지, 로그인 화면 이동처럼 흐름을 따라 자를 수 있습니다.

이 방식은 폼, 버튼, 이동, 성공과 실패 처리처럼 한 덩어리의 사용자 경험을 다룰 때 좋습니다. 실제 서비스 감각을 익히기에도 좋습니다.

층위 기준으로 나누기

화면, 서버, 데이터베이스처럼 기술 층으로 나누는 방식입니다. 예를 들어 먼저 테이블 만들기, 다음 API 연결, 마지막으로 화면 붙이기처럼 진행합니다.

이 방식은 백엔드나 데이터 저장 흐름이 섞일 때 유용합니다. 특히 선행 작업이 분명한 기능에서 강합니다. 예를 들어 데이터베이스 구조가 없는데 저장 버튼부터 만드는 일은 겉보기에만 진도 나간 것처럼 느껴질 뿐입니다.

실전에서는 이 세 가지를 섞어 쓰게 됩니다. 예를 들어 먼저 층위 기준으로 데이터 구조를 만들고, 그다음 화면 기준으로 UI를 붙이고, 마지막에 흐름 기준으로 실제 사용 경험을 다듬는 식입니다.

가장 먼저 시킬 일은 구현이 아니라 분해다

초보자가 자주 하는 실수는 처음부터 구현을 시키는 것입니다. 하지만 복잡한 작업일수록 첫 질문은 이렇게 바뀌어야 합니다.

무엇을 만들지보다, 어떻게 쪼갤지를 먼저 정리해줘.

Claude Code는 복잡한 변경 전에 읽기 전용으로 코드를 살펴보고 계획을 세우는 Plan Mode를 지원합니다. 여러 파일을 건드리는 작업에서 먼저 계획만 세우게 하면 훨씬 안전합니다.¹ Codex 쪽 가이드도 큰 작업은 먼저 계획하고, 다단계 작업일수록 순서를 나누어 진행하라고 권합니다.³⁶

실제로는 이런 요청이 좋습니다.

글 작성 기능을 추가하려고 해. 바로 구현하지 말고, 초보자가 검토하기 쉬운 5단계 작업으로 나눠줘. 각 단계마다 목적, 수정될 가능성이 큰 파일, 완료 조건, 다음 단계로 넘어가기 전 확인할 점을 써줘.

이 요청의 장점은 명확합니다. AI가 코드를 쓰기 전에 일을 구조화하게 만듭니다. 그리고 그 구조를 내가 먼저 읽고 승인할 수 있습니다. 즉, 운전대를 다시 내 손으로 가져오는 것입니다.

단계별 요청 전략: 한 번에 끝내지 말고, 한 단계씩 잠가라

작업을 잘게 나누었다면 이제는 요청 순서가 중요합니다. 초보자에게 가장 안전한 흐름은 다음과 같습니다.

1단계: 계획만 받기

이 단계에서는 절대 바로 코드를 쓰게 하지 않습니다. 해야 할 일, 순서, 위험 요소, 선행 조건만 받습니다.

이때 꼭 물어보면 좋은 것은 네 가지입니다.

• 어떤 순서가 자연스러운가

• 어떤 단계가 다른 단계의 선행 조건인가

• 어느 단계부터 눈으로 확인할 수 있는가

• 어디서 가장 자주 막히는가

이 질문을 하면, 나중에 왜 갑자기 데이터베이스 파일이 바뀌었는지 같은 일을 덜 겪게 됩니다.

2단계: 지금은 1단계만 하라고 제한하기

계획을 받았다고 해서 곧바로 전부 실행하게 하면 다시 큰 작업이 됩니다. 그래서 반드시 범위를 잠가야 합니다.

예를 들면 이렇게 말합니다.

좋았어. 지금은 1단계만 진행해줘. 다른 단계는 건드리지 말고, 이번 단계에서 필요한 최소한의 파일만 수정해줘. 끝나면 바뀐 파일과 확인 방법을 요약해줘.

여기서 핵심은 다른 단계는 건드리지 말라고 분명히 말하는 것입니다. AI는 종종 친절하게 다음 단계까지 미리 해두려 합니다. 하지만 초보자에게 그 친절은 종종 과잉 서비스입니다.

3단계: 내가 직접 확인하기

작업이 끝나면 곧바로 다음 단계로 넘어가지 않습니다. 화면을 보고, 입력해보고, 파일 변경을 읽고, 설명을 듣습니다. 이 부분은 지난 장에서 배운 검토 습관과 정확히 연결됩니다.

즉, 작은 작업은 검토를 쉽게 만들기 위해 존재합니다.

4단계: 다음 단계로 넘어가기 전에 방향을 수정하기

여기서 아주 중요한 일이 생깁니다. 작은 단위에서는 중간에 방향을 바꾸기가 쉽습니다. 버튼 위치가 어색하면 지금 고치면 되고, 필드 이름이 이상하면 지금 바꾸면 됩니다. 큰 작업에서는 이 사소한 수정이 전체 구조를 다시 흔들 수 있지만, 작은 작업에서는 부담이 훨씬 작습니다.

그래서 단계가 끝날 때마다 이렇게 묻는 습관이 좋습니다.

다음 단계로 넘어가기 전에, 지금 단계에서 더 단순하게 고칠 수 있는 부분이 있는지 알려줘.

완료 조건을 꼭 붙여라

좋은 요청은 단지 무엇을 할지 말하지 않습니다. 무엇을 끝으로 볼지도 함께 말합니다. Codex 관련 가이드들이 반복해서 강조하는 것도 바로 이 점입니다. 프롬프트에는 작업 내용뿐 아니라 완료 조건이 있어야 합니다.³⁶

예를 들어 아래 두 요청을 비교해봅시다.

나쁜 요청:

글 작성 기능 만들어줘.

좋은 요청:

글 작성 페이지에서 제목과 내용을 입력할 수 있게 해줘. 저장 버튼을 누르면 Supabase에 저장되고, 저장 성공 시 글 목록으로 이동해야 해. 제목이나 내용이 비어 있으면 저장되지 않고 에러 메시지가 보여야 해. 이번 단계에서는 이미지 업로드와 태그 기능은 제외해줘. 끝나면 내가 확인할 수 있는 테스트 방법도 알려줘.

둘의 차이는 아주 큽니다. 두 번째 요청은 AI에게 자유를 주되, 경계선도 함께 줍니다. 어디까지 해야 하는지, 무엇은 하지 말아야 하는지, 끝났다고 판단할 기준이 무엇인지가 분명합니다.

완료 조건은 초보자의 안전벨트입니다.

실습: 글 작성 기능을 작은 작업으로 쪼개기

이제 우리가 만들 서비스에 실제로 들어갈 만한 기능으로 연습해보겠습니다. 목표는 글 작성 기능입니다. 회원가입된 사용자가 제목과 내용을 입력해 글을 저장하는 기능까지 만드는 상황을 가정하겠습니다.

처음부터 통째로 시키면 대개 이런 식이 됩니다.

로그인한 사용자가 글을 작성하고 수정하고 삭제할 수 있게 해줘. 목록과 상세에도 반영하고 검색도 되게 하고 모바일도 예쁘게 맞춰줘.

이 요청은 한마디로 너무 큽니다. 그래서 다음처럼 나눕니다.

1단계: 계획만 세우기

먼저 이렇게 요청합니다.

글 작성 기능을 추가하려고 해. 바로 구현하지 말고, 초보자가 검토하기 쉬운 단계로 나눠줘. 각 단계마다 목표, 바뀔 수 있는 파일, 완료 조건, 이번 단계에서 제외할 범위를 적어줘.

이때 AI가 대략 다음과 같은 구조를 제안하면 좋습니다.

• 글 작성 페이지 화면 뼈대 만들기

• 입력 폼 상태와 버튼 연결하기

• 데이터베이스 저장 로직 연결하기

• 성공과 실패 메시지 처리하기

• 저장 후 목록 반영 확인하기

이렇게만 나와도 작업은 훨씬 덜 무섭습니다.

2단계: 화면 뼈대만 만들기

이제 구현은 아주 좁게 시킵니다.

1단계만 진행해줘. 글 작성 페이지의 화면 뼈대만 만들어줘. 제목 입력창, 내용 입력창, 저장 버튼, 취소 버튼이 보이게 해줘. 아직 데이터 저장은 연결하지 말아줘. 끝나면 바뀐 파일과 확인 방법을 설명해줘.

이 단계가 좋은 이유는 결과가 눈에 바로 보이기 때문입니다. 화면이 열리는지, 입력창이 있는지, 버튼이 보이는지 초보자도 쉽게 확인할 수 있습니다.

3단계: 입력 상태만 연결하기

화면이 마음에 들면 다음으로 갑니다.

이제 2단계를 진행해줘. 제목과 내용 입력이 상태에 반영되게 해줘. 저장 버튼을 눌렀을 때 지금은 콘솔 로그만 찍어도 괜찮아. 아직 데이터베이스 저장은 하지 말아줘.

여기서는 저장까지 한 번에 붙이지 않습니다. 버튼과 입력 흐름이 제대로 이어지는지만 먼저 봅니다. 이 단계는 사용자의 행동 흐름을 확인하는 용도입니다.

4단계: 저장 로직 연결하기

이제야 저장을 붙입니다.

이제 제목과 내용을 Supabase posts 테이블에 저장하도록 연결해줘. 이번 단계에서는 저장 성공 시 목록 페이지로 이동만 처리해줘. 실패 처리와 상세 에러 문구는 다음 단계에서 하자.

이렇게 하면 무엇이 저장 문제인지, 무엇이 UI 문제인지 분리해서 볼 수 있습니다.

5단계: 빈값 검증과 실패 처리 넣기

이번 단계에서는 제목이나 내용이 비어 있으면 저장하지 않게 해줘. 사용자에게 이해하기 쉬운 에러 메시지를 보여줘. 저장 실패 시에도 화면이 멈추지 않게 처리해줘.

여기서 중요한 것은 성공 경로와 실패 경로를 분리해 다룬다는 점입니다. AI는 성공 경로를 먼저 잘 만드는 편이므로, 실패 처리 단계는 따로 잡는 것이 좋습니다.⁷

6단계: 마지막 점검

지금까지 만든 글 작성 기능을 기준으로, 실제 사용자처럼 확인할 체크리스트를 만들어줘. 정상 저장, 빈값, 너무 긴 입력, 저장 직후 목록 반영까지 포함해줘.

이 단계는 기능 추가가 아니라 점검 단계입니다. 그런데 실제 완성도는 여기서 크게 달라집니다.

요청문을 더 잘게 만드는 문장 습관

작업 분해를 잘하는 사람은 거창한 문장을 쓰지 않습니다. 오히려 요청문이 짧고 분명합니다. 다음 습관이 특히 도움이 됩니다.

첫째, 한 요청에는 목표를 하나만 넣습니다. 둘째, 이번 단계에서 하지 않을 일을 같이 씁니다. 셋째, 끝났는지 확인하는 방법을 붙입니다. 넷째, AI가 바꾼 파일을 요약하게 만듭니다.

예를 들어 아래 문장은 매우 실용적입니다.

• 이번 단계에서는 UI만 해줘.

• 아직 서버 연결은 하지 말아줘.

• 수정 범위는 글 작성 페이지와 관련 컴포넌트로 제한해줘.

• 끝나면 내가 브라우저에서 확인할 방법을 알려줘.

• 다음 단계로 넘기기 전에 위험한 부분이 있는지 말해줘.

이런 문장은 화려하지 않지만, 실제로는 품질을 크게 올립니다.

Claude Code와 Codex에 공통으로 잘 먹히는 요청 패턴

도구가 달라도 기본 원리는 비슷합니다. Claude Code는 계획 모드와 태스크 분해가 강하고, Codex는 파일 단위의 구체적 요청과 단계별 구현에 강한 편입니다. 하지만 둘 모두 큰 작업을 잘게 쪼개고, 파일과 완료 조건을 분명히 적어줄 때 더 안정적으로 움직입니다.¹²³⁶

초보자는 아래 패턴만 기억해도 충분합니다.

패턴 1: 계획 요청

이 기능을 바로 구현하지 말고 4~6단계 작업으로 나눠줘. 단계별 목표와 완료 조건을 적어줘.

패턴 2: 범위 제한 실행

지금은 2단계만 진행해줘. 다른 단계는 건드리지 말아줘. 필요한 최소 파일만 수정해줘.

패턴 3: 결과 요약

어떤 파일을 왜 바꿨는지 설명해줘. 내가 확인할 포인트도 함께 적어줘.

패턴 4: 다음 단계 제안

지금 결과를 기준으로 다음에 가장 안전하게 진행할 한 단계를 제안해줘.

이 네 문장만 잘 써도, 작업이 훨씬 덜 엉키기 시작합니다.

순서가 중요한 작업은 의존성을 생각하라

모든 단계를 무조건 독립적으로 처리할 수 있는 것은 아닙니다. 어떤 작업은 반드시 먼저 끝나야 다음 단계가 가능합니다. 예를 들어 데이터베이스 테이블이 없는데 저장 기능부터 붙일 수는 없습니다. 인증이 없는데 내 글만 수정 가능하게 만들 수도 없습니다.

Claude Code의 Tasks 기능은 이런 선후 관계를 구조적으로 관리할 수 있게 설계되어 있습니다. 어떤 태스크가 다른 태스크에 막혀 있는지 표시하고, 선행 작업이 끝나면 다음 작업이 자동으로 준비 상태가 됩니다.²⁸

초보자라면 아주 어렵게 생각할 필요는 없습니다. 그냥 이렇게만 기억하면 됩니다.

먼저 있어야 다음이 가능한 것은, 절대 한 덩어리로 시키지 않는다.

예를 들어 이런 순서가 자연스럽습니다.

• posts 테이블 구조 정리

• 글 저장 함수 만들기

• 글 작성 화면 연결

• 에러 처리와 검증 추가

• 수정과 삭제 권한 붙이기

이 순서를 무시하면, AI도 인간도 같이 헤매기 쉽습니다.

너무 크게 시켰다는 신호들

작업을 하다 보면 어느 순간 감이 옵니다. 아, 이건 너무 크게 시켰구나. 하지만 초보자에게는 그 감이 아직 희미할 수 있습니다. 그래서 신호를 알아두면 좋습니다.

다음과 같은 상황이면 작업을 다시 쪼개는 편이 좋습니다.

• 바뀐 파일이 예상보다 훨씬 많다.

• 설명을 들어도 무엇이 핵심 변경인지 잘 모르겠다.

• 화면, 서버, 데이터베이스가 한 번에 다 바뀌었다.

• 성공 경로는 되는데 실패 경로가 불안하다.

• 한 군데를 고치려다가 다른 기능까지 함께 흔들린다.

이때는 고집스럽게 계속 밀지 말고, 이렇게 말하면 됩니다.

지금 변경은 범위가 큰 것 같아. 작업을 다시 더 작은 단계로 나눠줘. 특히 UI, 저장, 검증, 권한을 분리해서 제안해줘.

이 한마디가 프로젝트를 살리는 경우가 많습니다.

작은 작업이 주는 가장 큰 이점은 자신감이다

초보자에게 가장 무서운 순간은 이런 때입니다.

분명 뭔가 바뀌었는데, 내가 무엇을 승인하는지 잘 모르겠을 때.

큰 작업은 바로 이 두려움을 키웁니다. 반면 작은 작업은 지금 내가 무엇을 만들고 있고, 무엇을 확인했고, 어디까지는 이해했는지를 선명하게 보여줍니다. 이 감각이 쌓이면 어느 순간 이런 생각이 들기 시작합니다.

나도 할 수 있겠는데?

그 감각이 중요합니다. AI와 개발하는 힘은 문법 암기보다 먼저, 작업을 다루는 감각에서 나옵니다. 작은 작업으로 나누는 습관은 결국 개발 지식보다 먼저 배우는 운영 기술입니다.

오늘 바로 써먹는 실전 프롬프트

마지막으로, 이 장의 핵심을 바로 적용할 수 있게 짧은 프롬프트 틀을 남겨두겠습니다.

기능 분해 요청

이 기능을 바로 구현하지 말고, 초보자가 검토하기 쉬운 작업 단위로 나눠줘. 각 단계마다 목표, 관련 파일, 완료 조건, 제외 범위를 적어줘.

한 단계만 실행 요청

지금은 n단계만 진행해줘. 다른 단계는 건드리지 말고, 필요한 최소 파일만 수정해줘. 끝나면 변경 파일과 확인 방법을 요약해줘.

범위 축소 요청

변경 범위가 큰 것 같아. UI, 데이터 저장, 검증을 따로 나눠서 다시 제안해줘.

마무리 점검 요청

지금 단계가 끝났다고 볼 수 있는 수동 테스트 체크리스트를 만들어줘.

이 네 가지는 거의 만능에 가깝습니다. 막힐 때마다 돌아와도 좋습니다.

이번 장의 핵심 문장

복잡한 요구를 잘게 나누는 순간, 초보자도 AI와 함께 개발할 수 있습니다.

AI와 일할 때 실력은 거대한 요청을 한 번에 던지는 데서 나오지 않습니다. 오히려 큰 문제를 작은 단계로 바꾸고, 한 단계씩 확인하며 앞으로 나아가는 데서 나옵니다. 잘게 나눈 작업은 AI의 품질을 높이고, 내 검토를 쉽게 만들고, 실패의 크기를 줄입니다.

그러니 다음부터는 이렇게 시작해보세요.

한 번에 다 하지 말고, 먼저 쪼개자.

그 한마디가 여러분의 첫 서비스 완성 확률을 크게 올려줄 것입니다.

다음 장에서는 이렇게 잘게 나누어 진행하다가도 결국 마주치게 되는 순간, 즉 에러가 나거나 예상과 다른 결과가 나왔을 때 AI와 어떻게 대화해야 하는지 살펴보겠습니다.

참고

¹Claude Code Common Workflows

²Claude Code Tasks: Complete Guide

³Codex Prompting Guide

⁴The Secret Life of Claude Code: Why Small Tasks Are the Key to Working with AI

⁵Task Engineering in AI Coding: How to Break Problems Into AI-Ready Pieces

⁶Open AI 공식문서 번역 Codex Prompting Guide 정리

⁷10 Codex Prompts Every Developer Should Save

⁸Claude Code Tasks로 복잡한 프로젝트 효율적으로 진행하기