뉴스레터 목록
라이브노트프리미엄 전용프롬프트요구사항설계롤백

일격필살 프롬프트: 디버깅 없이 한 번에 끝내기

라이브

일격필살 프롬프트: 디버깅 없이 한 번에 끝내기

첫 섹션은 누구나 읽을 수 있어요. 나머지 섹션의 전문·프롬프트 원문·Q&A는 라이브 프리미엄 멤버십 회원 전용이에요.

버그가 나면 "고쳐 줘"를 반복하는 대신 롤백하고, 처음 넣은 프롬프트를 고쳐서 다시 넣어요. 3일 챌린지에서 냈던 과제 세 개(게임 · 장바구니 · 회의실 예약)를 방송에서 직접 풀면서, 한 번에 구현되는 프롬프트를 어떻게 만드는지 보여 드렸어요.

이 노트를 읽고 나면 할 수 있는 것

  1. 만들고 싶은 기능을 해석의 여지가 없는 요구사항으로 적고, 구현 전에 LLM에게 설계부터 맡기기
  2. 결과가 어긋났을 때 "다르게 만들었나, 빠뜨렸나"를 가려 롤백할지 덧댈지 정하기
  3. 데이터베이스가 엮인 기능을 유저플로우(사용자가 기능을 쓰는 순서) → 데이터플로우 → 스키마 순서로 설계하고, 흐름만 골라 검증하기

2025년 9월 18일 방송 · 다시보기 https://youtu.be/2tVuuzyuSLg · 약 2시간 40분, 본편은 5분부터

목차

고치지 말고 롤백하기 ▶ 0:05:04

슬라이드 — 전통적 개발 방식의 문제. 1. AI는 고치는 걸 잘 못 해요(디버깅/리팩터링에 안 맞아요) 2. 바이브코더는 버그 원인을 몰라요(고치는 지시도 못 할 수밖에 없어요)
디버깅이 바이브 코딩에 안 맞는 두 가지 이유 ▶ 0:06:02

개발자는 보통 열심히 만든 다음 디버깅이나 QA(품질 검증)를 해요. 바이브 코딩도 무의식적으로 이 순서를 따라가는데, AI가 코드를 쓸 때는 비효율적이에요. ▶ 0:05:50

첫째, AI는 고치는 걸 잘 못해요. 디버깅을 시키면 컨텍스트(AI가 한 번에 읽는 입력)에 들어가는 건 올바른 코드가 아니라 잘못된 코드예요. 잘못된 예시만 보고 좋은 결과를 낼 확률은 근본적으로 낮아요. ▶ 0:06:28

둘째, 코드를 AI가 썼으니 바이브 코더는 버그 원인을 정확히 몰라요. 원인을 모르면 정확하게 지시할 수 없고, 정확한 지시가 없으면 AI는 어떤 작업도 잘 못해요. ▶ 0:07:08

슬라이드 — 고치는 것보다 새로 만드는 게 쉽습니다. 새로 만들기는 필요한 기능만 제대로 설명, 고치기는 잘못 구현된 코드·에러 상황·어떻게 고쳐야 할지를 추가로 설명해야 함
새로 만들 때와 고칠 때 설명해야 하는 양 ▶ 0:08:17

고치는 것과 새로 만드는 걸 비교하면 답이 나와요. 새로 만드는 게 더 쉽다는 거예요. ▶ 0:07:45 새로 만들 때는 만들 요구사항만 설명하면 돼요. 고칠 때는 잘못된 코드, 원래 원한 것, 지금 상태까지 설명해야 하고, AI가 문제를 정확히 짚어야 고쳐져요.

슬라이드 — AI 최적화 프로세스. ○○를 만들어야지 → 간단한 프롬프트로 구현 → 프롬프트 개선 후 재요청(AI의 속도를 최대로 레버리지)
구현 → 롤백 → 프롬프트 개선 후 재요청 ▶ 0:09:13

AI가 코드를 써 주면서 코드 쓰는 비용은 거의 0이 됐어요. 디버깅은 여전히 비싸요. 그러니 빠르게 쓰고, 아니면 롤백하고 다시 쓰는 것이 AI 특성을 가장 잘 쓰는 방식이에요. ▶ 0:09:26 저도 실제로 개발할 때 이렇게 해요. 요청해 놓고 딱 봐도 꼬였다 싶으면 롤백해요. ▶ 0:10:10

슬라이드 — 개선 프로세스. 1. 뭔가 어긋난 것 같으면 롤백하고 다시 구현하도록 요청해요 2. 디버깅 기법보다는 구현 프롬프트 작성 능력을 키워요. 오른쪽 위에 커서 입력창의 되돌리기 화살표(입력창 내용은 흐리게 처리)
커서 입력창의 되돌리기 화살표 ▶ 0:11:11

롤백은 Git으로 해도 되고, 대부분의 AI 도구에도 있어요. 커서(Cursor)는 프롬프트 입력창의 연한 꺾인 화살표를 누르면 그 프롬프트를 넣기 전으로 돌아가요. 거기서 프롬프트를 고쳐 다시 요청하면 돼요. ▶ 0:11:16

이 뒤는 라이브 프리미엄 멤버십 회원 전용이에요

나머지 섹션의 전문과 프롬프트 원문, Q&A는 라이브 프리미엄 멤버십 회원만 읽을 수 있어요.

프리미엄 혜택 보기 →

지난 라이브노트