" style="max-width:100%;height:auto">
AI 코딩 도구로 앱을 만들고, 업무 자동화를 돌리고, 사이드 프로젝트를 띄우는 사람이 부쩍 늘었습니다. 그런데 한 가지 공통된 고민이 있습니다. 작업이 조금만 복잡해지는 순간 결과물이 완전히 무너진다는 것인데요. 프롬프트를 몇 번 더 다듬고, 플랜 모드를 켜 보고, 에러 나면 고치고, MCP를 붙여 보고, 랄프 루프까지 돌려 봐도 근본적으로 달라지지 않는다면, 문제는 도구가 아니라 순서에 있을 가능성이 큽니다.
오늘은 수많은 시행착오 끝에 정착한 실전 워크플로우를 공유합니다. 핵심 원칙은 단 하나입니다. 작성된 계획을 내가 직접 검토하고 승인하기 전까지, AI에게 코드를 절대 쓰게 하지 마라. 기획과 코딩의 분리 — 이 한 가지를 지키는 것만으로 삽질은 사라지고, 결과물의 완성도는 눈에 띄게 달라집니다.
📌 핵심 요약
• 핵심 원칙: 계획 승인 전까지 코드 작성 금지 — 기획과 코딩을 분리한다
• 4단계 흐름: 리서치 → 계획 → 구현 → 검증·반복
• 가장 비싼 실패는 문법 에러가 아니라, 주변 시스템을 슬금슬금 망가뜨리는 '멀쩡한' 구현
• 프롬프트에는 '깊이·매우 상세히·세부 사항' 같은 강도 조절 단어를 반드시 넣는다
| 단계 | 하는 일 | 핵심 포인트 |
| 1. 리서치 | 코드베이스를 깊이 읽히고 마크다운 보고서로 정리 | 채팅 요약이 아니라 파일로 남긴다 |
| 2. 계획 | 구현 계획을 문서로 받고 직접 검토·승인 | 승인 전까지 코드 작성 절대 금지 |
| 3. 구현 | 승인된 계획대로만 코드 작성 | 계획에서 벗어난 임의 판단 금지 |
| 4. 검증·반복 | 테스트·리뷰 후 피드백을 반영해 최소 한 번 이상 반복 | 한 번에 끝내려 하지 않는다 |
1단계 — 리서치: 코드부터 들이받지 마세요
의미 있는 작업은 전부 코드베이스를 깊이 읽는 것부터 시작합니다. AI에게 관련 부분을 철저하게 이해하라고 시키고, 발견한 내용을 반드시 마크다운 파일로 작성하게 하세요. 여기서 중요한 건 절대로 채팅창 안의 구두 요약으로 끝내면 안 된다는 점입니다. 문서로 남겨야 계획 단계에서 다시 참조할 수 있습니다.
프롬프트 예시는 이렇습니다. "이 폴더를 깊이 읽고 어떻게 동작하는지 깊이 이해하고, 모든 세부 사항을 파악해라. 끝나면 리서치의 상세 보고서를 작성해라." 알림 시스템을 다룬다면 "알림이 어떻게 작동하는지 모든 것을 담은 리서치 MD를 작성해라"처럼 대상을 콕 집어 주세요.
여기서 팁 하나. 깊이, 매우 상세히, 세부 사항 같은 단어가 진짜 중요합니다. 이런 단어 없이 그냥 시키면 AI가 대충 훑어보기만 합니다. 파일 하나 읽고 함수 시그니처 수준에서 "아, 이런 거구나" 하고 넘어가 버리죠. 사실상 AI의 구조는 사람의 뇌와 크게 다르지 않습니다. 인풋이 강력해야 아웃풋이 그나마라도 뽑히는 구조예요. 사람을 다루듯, 요구의 강도를 명확히 전달해야 합니다.
" style="max-width:100%;height:auto">
2단계 — 계획: 승인 도장을 찍기 전엔 손도 못 대게
리서치가 끝났다면 다음은 구현 계획입니다. AI에게 "이 작업을 어떻게 구현할지 단계별 계획을 마크다운으로 작성해라. 내가 승인하기 전까지는 코드를 한 줄도 쓰지 마라"라고 지시하세요. 그리고 실제로 계획을 읽고, 아키텍처 결정이 내 의도와 맞는지 검토한 뒤 승인합니다.
이렇게 하면 뭐가 좋을까요? 첫째, 쓸데없는 삽질이 사라집니다. 방향이 틀어진 채로 코드를 수백 줄 쌓는 일이 없어지니까요. 둘째, 아키텍처 결정의 주도권이 내 손에 남습니다. AI가 멋대로 정한 구조에 끌려다니지 않게 됩니다. 셋째, 코드부터 들이받는 방식보다 토큰도 훨씬 적게 쓰면서 결과물은 훨씬 좋아집니다.
💡 핵심 원칙 한 줄
작성된 계획을 내가 직접 검토하고 승인하기 전까지, AI에게 코드를 절대 쓰게 하지 마라. 기획과 코딩의 분리 — 이게 가장 중요한 단 한 가지다.
" style="max-width:100%;height:auto">
3·4단계 — 구현과 검증: 계획대로, 그리고 한 번 더
계획이 승인되면 그제야 코드를 작성하게 합니다. 이때도 원칙은 같습니다. 승인된 계획에서 벗어난 임의의 판단을 하지 못하게 하세요. 구현이 끝나면 테스트하고, 결과를 리뷰한 뒤 피드백을 반영해 최소 한 번 이상 반복합니다. 한 번에 끝내려는 욕심이 품질을 갉아먹습니다.
리서치 문서화
코드베이스를 읽히고 마크다운 보고서로 남긴다. '깊이·매우 상세히·세부 사항' 키워드 필수.
계획 작성과 승인
구현 계획을 문서로 받고 직접 검토한다. 승인 전까지 코드 작성 금지.
계획대로 구현
승인된 계획의 범위 안에서만 코드를 작성하게 한다.
검증과 반복
테스트·리뷰 후 피드백을 반영해 최소 한 번 이상 반복한다.
가장 비싼 실패는 '멀쩡해 보이는' 구현이다
AI 코딩에서 가장 비싼 실패가 뭔지 아세요? 문법 에러나 로직 버그가 아닙니다. 그 자체로는 멀쩡하게 돌아가는데, 주변 시스템을 슬금슬금 망가뜨리는 구현입니다. 예를 들면 기존 레이어를 완전히 무시하는 함수, ORM 관리를 고려하지 않은 마이그레이션, 이미 있는 로직을 그대로 복제해 놓은 코드 같은 것들이죠. 당장은 돌아가니까 문제를 알아차리기도 어렵습니다.
⚠️ 주의
계획 없는 구현은 이런 '조용한 파괴'를 양산합니다. 계획 단계에서 기존 아키텍처와의 정합성을 먼저 검토하는 이유가 바로 여기에 있습니다.
" style="max-width:100%;height:auto">
마무리
도구는 계속 좋아질 겁니다. 스킬이 나오고, 팀 에이전트가 나오고, MCP가 붙고, 랄프 루프 같은 기법이 유행해도, 복잡한 작업에서 무너지는 패턴은 결국 같은 곳에서 시작됩니다. 계획을 세우기도 전에 코드를 쓰게 하는 것. 순서를 바꾸는 것만으로 바이브코딩은 '운에 맡기는 도박'에서 '통제 가능한 공정'으로 바뀝니다. 오늘부터 한 가지만 지키세요. 승인 도장 찍기 전엔, 코드 한 줄도 쓰지 마라.
Q&A
Q. 간단한 작업에도 리서치·계획 단계를 다 거쳐야 하나요?
A. 아닙니다. 간단한 작업은 이 단계를 건너뛰어도 됩니다. 작업이 조금이라도 복잡해지는 순간부터 적용하세요. 기준은 '실패했을 때 되돌리기 어려운가'입니다.
Q. 계획 승인이 너무 번거로운데, 플랜 모드로 대체할 수 없나요?
A. 플랜 모드는 도구 차원의 기능이고, 핵심은 '내가 직접 검토하고 승인한다'는 행위입니다. 어떤 기능을 쓰든 승인 주체가 사람이어야 주도권이 유지됩니다.
Q. 리서치 문서를 파일로 남기는 이유가 뭔가요?
A. 채팅 요약은 휘발됩니다. 계획 단계에서 "리서치 문서를 읽고 계획을 세워라"라고 참조시킬 수 있어야 하고, 나중에 같은 영역을 다시 건드릴 때도 재사용됩니다.
Q. '깊이·매우 상세히' 같은 단어가 정말 효과가 있나요?
A. 네. 이런 강도 조절 단어 없이 지시하면 AI는 함수 시그니처 수준에서 훑고 넘어가는 경우가 많습니다. 요구의 강도를 언어로 명시하는 것이 품질 편차를 줄이는 가장 쉬운 방법입니다.
Q. 검증·반복은 몇 번이 적당한가요?
A. 최소 한 번 이상을 권장합니다. 첫 구현물을 곧바로 확정하지 말고, 테스트 결과와 리뷰 피드백을 한 사이클 이상 반영하세요. 반복 횟수보다 '피드백 사이클이 존재하는가'가 중요합니다.