기초편 6편까지 따라왔다면, 이제 감은 어느 정도 잡혔을 겁니다. AI에게 역할을 주는 법, 요청을 구조화하는 법, 작업을 잘게 나누는 법, 현재 상태를 넘기는 법, 검토와 디버깅 요청까지 한 바퀴 돌았기 때문입니다. 그런데 막상 실제로 써보려고 하면 또 다른 문제가 생깁니다. 알겠는데, 매번 처음부터 문장을 다시 쓰려니 손이 느려진다는 점입니다.

이건 아주 자연스러운 단계입니다. 처음에는 원리를 이해하는 것이 중요하지만, 어느 정도 익숙해지고 나면 그다음에는 반복해서 꺼내 쓸 수 있는 기본 틀이 필요해집니다. 매번 멋진 문장을 새로 만들어야 하는 게 아니라, 자주 쓰는 상황마다 쓸 만한 기본 템플릿을 하나씩 들고 있는 편이 훨씬 편합니다.

이번 확장편 1편에서는 바로 그 부분을 정리해보겠습니다. 핵심은 “마법 프롬프트”를 소개하는 데 있지 않습니다. 오히려 지금까지 배운 원리를 실제 작업에서 바로 꺼내 쓸 수 있는 형태로 묶는 것에 더 가깝습니다. 처음 만들 때, 디버깅할 때, 코드 검토를 받을 때, 설명을 다시 듣고 싶을 때처럼 자주 만나는 장면별로 정리해두면 훨씬 덜 흔들립니다.

이번 글에서 먼저 잡아둘 핵심
상황 템플릿이 필요한 이유 핵심 포인트
처음 만들 때 목표와 범위를 빠르게 정리할 수 있다 무엇을 만들지, 어디까지 할지, 무엇은 아직 안 할지를 같이 적는다
막혔을 때 문제를 재현 가능한 질문으로 바꿀 수 있다 현재 상태, 재현 순서, 기대 결과, 실제 결과를 빠뜨리지 않는다
결과를 다듬을 때 전체 재작성 없이 필요한 수정만 요청하기 쉽다 무엇이 맞고 무엇이 어긋났는지 먼저 짚고, 수정 범위를 좁힌다

이번 글의 핵심 한 줄
좋은 템플릿은 답을 대신 만들어주는 문장이 아니라, 내가 자주 놓치는 정보를 빠뜨리지 않게 해주는 작업용 틀에 가깝습니다.

왜 템플릿이 필요한가

입문자가 AI와 같이 작업할 때 가장 자주 겪는 피로는 생각보다 단순합니다. 매번 같은 종류의 상황이 반복되는데, 요청 문장은 늘 처음부터 다시 써야 하는 것처럼 느껴진다는 점입니다. 처음 앱을 만들 때도, 에러를 물을 때도, 결과를 다시 다듬을 때도 비슷한 구조가 반복되는데, 그때마다 머릿속에서 새로 조합하려고 하면 생각보다 금방 지칩니다.

그래서 템플릿이 필요합니다. 다만 여기서 말하는 템플릿은 인터넷에서 떠도는 짧은 비법 문장 같은 것이 아닙니다. 오히려 작업 상황별로 필요한 항목을 빠뜨리지 않게 해주는 기본 틀에 더 가깝습니다. 목표, 맥락, 제약, 출력 형식 같은 구조가 이미 익숙해졌다면, 이제는 그 구조를 상황별 문장으로 묶어두는 단계라고 보면 됩니다.

  • 처음 만들 때는 목표와 범위를 빠르게 정리하는 템플릿이 도움이 됩니다.
  • 막혔을 때는 재현 순서와 에러 정보를 놓치지 않는 템플릿이 필요합니다.
  • 결과를 다듬을 때는 무엇이 맞고 무엇이 어긋났는지 정리하는 틀이 유용합니다.
  • 이해가 안 될 때는 코드 설명을 다시 받는 전용 템플릿이 훨씬 효과적입니다.

결국 템플릿의 장점은 글을 멋지게 만드는 데 있지 않습니다. 내가 지금 무엇을 요청해야 하는지 빠르게 정리하고, AI가 넓게 추정할 부분을 줄여주는 데 더 큰 의미가 있습니다. 초보자일수록 이 차이가 큽니다. 한두 줄 덜 쓰는 것보다, 중요한 정보를 한 번 덜 놓치는 편이 훨씬 도움이 되기 때문입니다.

오해하기 쉬운 지점
템플릿은 문장을 기계적으로 복붙하라는 뜻이 아닙니다. 기본 틀을 들고 있다가, 지금 상황에 맞는 정보만 바꿔 넣으라는 뜻에 더 가깝습니다.

이번 편에서는 어떤 템플릿을 다룰 것인가

이번 글에서는 실제로 가장 자주 쓰게 되는 네 가지 상황을 중심으로 템플릿을 정리하겠습니다. 이유는 단순합니다. 너무 많은 템플릿을 한꺼번에 늘어놓으면 오히려 입문자에게 부담이 커지기 때문입니다. 지금 단계에서는 자주 꺼내 쓰는 기본형 몇 개만 들고 있어도 충분합니다.

  • 처음 만들 때 쓰는 기본 템플릿
  • 막혔을 때 쓰는 디버깅 템플릿
  • 결과를 점검하고 다시 고칠 때 쓰는 검토·수정 요청 템플릿
  • 설명이 부족해서 다시 배우고 싶을 때 쓰는 학습용 템플릿

반대로 이번 편에서는 아래 내용은 깊게 다루지 않겠습니다.

  • 도구별 전용 문법 차이
  • 팀 문서나 저장소에 넣는 고정 지침
  • 긴 대화에서 맥락을 유지하는 운영 방식
  • 반복 작업용 개인 지침 정리법

그 내용은 다음 확장편에서 따로 다루는 편이 더 자연스럽습니다. 이번 편은 어디까지나 지금 당장 복사해서 손봐서 쓸 수 있는 템플릿 모음에 집중하는 편이 좋습니다.

처음 만들 때 쓰는 기본 템플릿

가장 먼저 필요한 템플릿은 역시 처음 무언가를 만들 때 쓰는 기본형입니다. 초보자가 AI에게 가장 많이 하는 요청도 보통 이 범주에 들어갑니다. 문제는 많은 경우 “앱 하나 만들어줘”에서 출발한다는 점입니다. 이렇게 물으면 결과가 넓어지기 쉽습니다.

그래서 기본 템플릿에는 아래 네 가지가 꼭 들어가면 좋습니다.

  • 무엇을 만들지
  • 지금 내 수준과 상황이 어떤지
  • 이번 단계에서는 어디까지 할지
  • 어떤 순서로 답을 받고 싶은지
너는 코딩 초보에게 설명하는 웹 개발 튜터다.

[목표]
지금 만들고 싶은 것은
____________________________ 이다.

[맥락]
나는 ____________________________ 수준이고,
현재 ____________________________ 상태다.

[제약]
이번 단계에서는

까지만 하고 싶다.

아직 아래 내용은 넣지 말아줘.

[출력 형식]
답변은 아래 순서로 정리해줘.

무엇을 만들지 짧게 요약

바뀌는 파일 구조

전체 코드 또는 필요한 코드

핵심 설명

내가 직접 확인할 체크리스트

예를 들어 할 일 앱 첫 화면을 만들고 싶다면 이렇게 바꿔 쓸 수 있습니다.

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

[목표]
HTML, CSS, JavaScript로
간단한 할 일 앱의 첫 화면을 만들고 싶다.

[맥락]
나는 HTML, CSS 기초만 알고 있고,
JavaScript는 기본 문법 정도만 안다.

[제약]
이번 단계에서는

입력창

추가 버튼

목록 영역
까지만 보이면 된다.

아직 아래 내용은 넣지 말아줘.

localStorage 저장

검색 기능

필터 기능

[출력 형식]
답변은 아래 순서로 정리해줘.

이번 단계 목표

필요한 파일

전체 코드

중요한 부분 설명

내가 직접 확인할 항목

이 템플릿의 좋은 점은 “처음 만들기” 상황에서 가장 자주 빠지는 정보를 한 번에 잡아준다는 점입니다. 특히 이번 단계에서 아직 하지 않을 것을 같이 적는 부분이 중요합니다. 초보자는 대개 “무엇을 넣을까”만 생각하는데, 실제로는 “무엇을 이번에는 빼둘까”가 결과를 훨씬 안정적으로 만듭니다.

핵심 포인트
처음 만들 때 쓰는 템플릿은 결과를 풍성하게 만드는 문장이 아니라, 이번 단계의 범위를 작게 유지하게 해주는 문장에 가깝습니다.

막혔을 때 쓰는 디버깅 템플릿

두 번째로 자주 쓰게 되는 템플릿은 디버깅용입니다. 기능 요청과 디버깅 요청은 다르게 써야 한다는 이야기를 앞에서 이미 했습니다. 실제로 막혔을 때는 “왜 안 되지?”라는 감정이 먼저 올라오지만, AI에게는 그 감정 자체보다 현재 상태와 재현 순서가 더 중요합니다.

그래서 디버깅 템플릿에는 아래 항목이 들어가야 합니다.

  • 현재 어디까지는 정상 동작하는지
  • 문제가 무엇인지 한 줄 요약
  • 문제가 다시 나타나는 순서
  • 기대한 결과와 실제 결과
  • 에러 메시지와 관련 코드
  • 원하는 답변 방식
[현재 작업]

____________________________ 기능까지는 정상 동작

지금은 ____________________________ 작업 중

[현재 문제]

[재현 순서]

[기대한 결과]

[실제 결과]

[에러 메시지]

또는

콘솔 에러 없음

[관련 코드]

관련 파일:

관련 함수:

최근에 바꾼 부분:

[원하는 답변]

가장 가능성 큰 원인 몇 가지

먼저 확인할 순서

전체 재작성 없이 필요한 수정 포인트만 제안

검색 기능에서 문제가 생겼다고 가정하면 이런 식으로 쓸 수 있습니다.

[현재 작업]

추가, 삭제, 완료 체크, 필터까지는 정상 동작

지금은 검색 기능을 붙이는 중

[현재 문제]

검색어를 입력해도 목록이 줄어들지 않음

[재현 순서]

검색창에 "회의"를 입력한다

목록 변화를 본다

[기대한 결과]

"회의"가 들어간 항목만 보여야 함

[실제 결과]

전체 목록이 그대로 보임

[에러 메시지]

콘솔 에러 없음

[관련 코드]

관련 파일: script.js

관련 함수: handleSearchInput, getFilteredTodos, renderTodos

최근에 바꾼 부분: searchInput 요소와 bindSearchEvents 추가

[원하는 답변]

가장 가능성 큰 원인 3개

확인 순서

필요한 수정 코드만 제안

이 템플릿은 디버깅의 핵심을 잘 잡아줍니다. 증상을 말하는 데서 끝나지 않고, 문제를 다시 만들어볼 수 있는 정보까지 같이 넘기기 때문입니다. 초보자에게는 이 차이가 특히 중요합니다.

코드 검토와 수정 요청 템플릿

세 번째 템플릿은 결과를 받은 뒤 다시 다듬을 때 쓰는 템플릿입니다. 이건 초보자에게 생각보다 중요합니다. 많은 사람이 AI가 코드를 주면 바로 실행하고 끝내려 하지만, 실제로는 무엇이 맞았고, 무엇이 빠졌고, 무엇이 과하게 바뀌었는지를 다시 정리해서 요청하는 일이 자주 생깁니다.

이 템플릿의 핵심은 두 가지입니다. 하나는 맞은 부분도 같이 적는 것이고, 다른 하나는 전체 재작성 대신 수정 범위를 좁히는 것입니다.

[현재 결과에서 맞는 부분]

[어긋난 부분]

[이번에 다시 요청하는 목표]

[유지할 것]

현재 구조는 최대한 유지

기존 기능은 깨지지 않게 유지

전체 리팩터링은 하지 않기

[원하는 답변]

무엇이 어긋났는지 요약

어떤 파일이나 함수만 고치면 되는지

필요한 수정 코드만 제시

내가 확인할 테스트 항목 정리

예를 들어 검색 기능이 거의 맞는데, 완료 필터와 연동이 어긋났다면 이렇게 바꿔 쓸 수 있습니다.

[현재 결과에서 맞는 부분]

검색 입력창이 잘 들어감

입력할 때 목록이 줄어드는 기능도 동작함

검색 지우기 버튼도 있음

[어긋난 부분]

완료 보기 상태에서는 검색 결과가 맞지 않음

검색 기능과 관계없는 함수 이름 변경이 너무 많음

[이번에 다시 요청하는 목표]

완료 필터와 검색이 함께 적용되도록 수정

현재 구조는 최대한 유지

[유지할 것]

전체 파일 구조는 그대로 둘 것

기존 추가, 삭제, 완료 체크 기능은 유지할 것

전체 리팩터링은 하지 말 것

[원하는 답변]

왜 완료 보기에서만 어긋나는지 설명

관련 함수만 추려서 수정

수정 후 테스트 순서까지 정리

이 템플릿은 특히 “이상한데 다시 만들어줘” 같은 넓은 재요청을 줄여줍니다. AI도 이미 맞은 부분은 유지하고, 지금 어긋난 부분만 다시 다루게 되기 때문에 결과가 훨씬 덜 흔들립니다.

핵심 포인트
수정 요청 템플릿은 불만을 말하는 문장이 아니라, 현재 결과를 기준으로 어디까지만 다시 손볼지 정리하는 문장에 가깝습니다.

설명을 다시 받는 학습용 템플릿

네 번째 템플릿은 입문자에게 의외로 가장 중요할 수 있습니다. 코드는 돌아가는데, 왜 그렇게 짰는지 모르겠는 경우가 많기 때문입니다. 이럴 때 그냥 넘어가면 다음 수정 요청에서 더 크게 막힐 가능성이 높습니다. 그래서 설명을 다시 받는 전용 템플릿이 필요합니다.

이 템플릿의 핵심은 “초보자 기준으로 다시 설명해달라”는 말만 하는 것이 아니라, 무엇이 특히 헷갈리는지를 같이 적는 것입니다.

방금 제안한 코드에서 아래 부분이 아직 헷갈린다.

[헷갈리는 지점]

[설명 요청]
초보자 기준으로 아래 순서로 다시 설명해줘.

각 변수나 상태값이 무엇을 뜻하는지

어떤 순서로 코드가 실행되는지

왜 이런 구조가 필요한지

내가 직접 바꿔보면 좋은 작은 연습 2개

[제약]

어려운 용어는 바로 쉬운 말로 풀어줘

전체 이론 설명보다 지금 코드와 연결해서 설명해줘

너무 길게 추상적으로 설명하지 말고, 현재 예제로 설명해줘

예를 들어 검색 기능 코드가 돌아가는데 currentSearchQuery와 getFilteredTodos() 흐름이 잘 안 보인다면 이렇게 쓸 수 있습니다.

방금 제안한 검색 기능 코드에서 아래 부분이 아직 헷갈린다.

[헷갈리는 지점]

currentSearchQuery를 왜 따로 두는지

getFilteredTodos가 필터와 검색을 어떤 순서로 적용하는지

[설명 요청]
초보자 기준으로 아래 순서로 다시 설명해줘.

currentSearchQuery가 무엇을 저장하는지

검색창에 입력하면 어떤 함수가 먼저 움직이는지

getFilteredTodos가 목록을 어떻게 다시 고르는지

내가 직접 바꿔보면 좋은 연습 2개

[제약]

어려운 용어는 바로 풀어서 설명

현재 할 일 앱 예제로만 설명

코드 전체를 다시 쓰지는 말 것

이 템플릿은 “코드를 받았는데 아직 내 것이 되지 않은 상태”를 줄이는 데 도움이 됩니다. 입문자에게는 아주 중요합니다. 결국 기초를 지나서 응용으로 가려면, 돌아가는 코드를 그냥 복붙하는 단계에서 조금씩 빠져나와야 하기 때문입니다.

템플릿을 쓸 때 자주 하는 실수

템플릿은 분명 편리하지만, 잘못 쓰면 오히려 더 기계적으로 보이거나 맥락이 빠질 수 있습니다. 그래서 아래 실수는 같이 기억해두는 편이 좋습니다.

템플릿을 쓸 때 자주 하는 실수
실수 왜 문제가 되나 어떻게 바꾸면 좋은가
빈칸만 채우고 현재 상황을 안 넣는다 템플릿은 있는데 실제 맥락이 부족해진다 최근에 바꾼 것, 정상 동작 범위, 현재 문제를 꼭 같이 적는다
템플릿이 너무 길어져서 핵심이 흐려진다 정작 AI가 봐야 할 문제 지점이 묻힐 수 있다 문제와 직접 연결된 정보만 남기고 줄인다
모든 상황에 같은 템플릿을 쓴다 기능 요청과 디버깅 요청이 같은 문장으로 섞인다 상황별로 기본 템플릿을 나눠서 쓴다
템플릿을 절대 규칙처럼 생각한다 실제 문제에 맞게 줄이거나 바꾸는 유연함이 사라진다 기본 틀로 쓰되, 지금 상황에 맞게 줄이거나 바꾼다

결국 템플릿은 문장을 자동화하는 도구가 아니라, 사고 순서를 안정화하는 도구에 더 가깝습니다. 이걸 이해하면 템플릿을 더 잘 쓸 수 있습니다.

  • 지금 상황이 무엇인지 먼저 고른다.
  • 그 상황에 맞는 템플릿을 꺼낸다.
  • 현재 상태와 관련 정보만 채워 넣는다.
  • 불필요한 항목은 과감히 줄인다.
  • AI가 답한 뒤에는 다음 단계용 템플릿으로 넘어간다.

짧은 정리
템플릿을 잘 쓴다는 것은 문장을 많이 외우는 게 아니라, 지금 상황이 기능 요청인지, 디버깅인지, 수정 요청인지 먼저 구분할 줄 아는 데서 시작합니다.

마무리

기초편을 지나 확장편으로 넘어오면, 결국 필요한 것은 새로운 이론보다 자주 꺼내 쓸 수 있는 작업 습관입니다. 이번 편에서 정리한 템플릿들은 그 시작점에 가깝습니다. 처음 만들 때, 막혔을 때, 다시 고칠 때, 설명을 다시 듣고 싶을 때처럼 반복해서 만나게 되는 장면마다 기본 틀을 하나씩 갖고 있으면 훨씬 덜 흔들립니다.

중요한 건 템플릿을 외우는 것이 아닙니다. 왜 이 항목이 들어가는지 이해한 뒤, 내 상황에 맞게 줄여서 쓰는 것이 더 중요합니다. 그래야 AI와의 대화가 점점 덜 즉흥적으로 바뀌고, 같은 문제를 다시 만났을 때도 훨씬 빨리 정리할 수 있습니다.

 

'바이브코딩 > 기초' 카테고리의 다른 글

[번외-1] 매번 다시 설명하지 마세요: 대화 맥락 관리와 반복 지침 정리법  (0) 2026.04.28
[기초-5] 막혔을 때 이렇게 물어보세요: 초보자를 위한 AI 디버깅 요청의 기본  (0) 2026.04.14
[기초-4] 돌아간다고 끝은 아니다: AI 코드 검토와 다시 요청하는 법  (0) 2026.04.07
[기초-3] AI가 엉뚱하게 답하는 이유: 코드·에러·화면 상태를 제대로 전달하는 법  (0) 2026.03.31
[기초-2] 한 번에 다 시키지 마세요: 바이브 코딩에서 큰 요청을 잘게 나누는 법  (0) 2026.03.24