[기초-1] 좋은 요청의 기본 구조: 목표·맥락·제약·출력 형식 쉽게 잡는 법

지난 글에서 다룬 페르소나는 쉽게 말해 “AI를 어떤 역할로 부를 것인가”에 대한 이야기였다. 그런데 역할만 정했다고 해서 결과가 바로 좋아지지는 않는다. 실제로 초보자가 많이 막히는 지점은 그다음이다. AI에게 무엇을 부탁해야 하는지, 어디까지를 원하는지, 어떤 방식으로 답을 받아야 하는지가 요청 안에 제대로 들어 있지 않기 때문이다.

예를 들어 “할 일 관리 앱 만들어줘”라고만 말하면, AI는 빈칸을 스스로 채우기 시작한다. 어떤 도구는 기능을 과하게 붙이고, 어떤 답변은 설명 없이 코드만 길게 내놓고, 또 어떤 경우에는 지금 내 수준과 맞지 않는 구조를 들고 올 수도 있다. 그럴 때 종종 “AI가 별로다”라고 느끼지만, 사실은 요청의 뼈대가 너무 비어 있었던 경우가 많다.

좋은 요청은 문장을 길게 쓰는 기술이 아니다. 중요한 정보가 빠지지 않게 정리하는 기술에 가깝다. 입문자 기준으로 보면 그 뼈대는 네 가지로 정리하면 가장 다루기 쉽다. 목표, 맥락, 제약, 출력 형식. 이번 글에서는 이 네 가지를 왜 써야 하는지, 각각 어떻게 적으면 되는지, 그리고 초보자가 바로 복붙해서 쓸 수 있는 형태까지 차근차근 정리해보겠다.

---

왜 요청 구조가 중요한가

AI에게 모호한 요청을 던지는 건, 택시 기사에게 “좋은 데로 가주세요”라고 말하는 것과 조금 비슷하다. 어딘가는 가겠지만, 내가 생각한 목적지와 같을 가능성은 높지 않다. 요청이 비어 있으면 AI는 그 빈칸을 자기 방식으로 메운다. 문제는 그 방식이 지금 내 수준, 목적, 상황과 맞지 않을 수 있다는 점이다.

특히 바이브 코딩에서는 한 번의 답변이 꽤 길어지기 쉽다. 그래서 처음 요청이 조금만 흐려도 뒤로 갈수록 수정 비용이 커진다. 처음부터 정답을 완벽하게 맞히는 게 목적은 아니다. 다만 엉뚱한 방향으로 새지 않게 만드는 최소한의 가이드는 필요하다. 그 역할을 하는 것이 바로 목표, 맥락, 제약, 출력 형식이다.

좋은 요청은 말을 거창하게 꾸미는 기술이 아니라, AI가 제멋대로 추정할 부분을 줄이는 기술에 가깝다.

요소	한 줄로 말하면	왜 필요한가	빠졌을 때 생기기 쉬운 문제
목표	무엇을 만들거나 해결할지	답변의 종착점을 정해준다	결과가 너무 넓어지거나 엉뚱한 방향으로 간다
맥락	지금 내 상태와 조건이 어떤지	현재 상황에 맞는 답을 받게 해준다	내 수준과 맞지 않거나 이미 해본 설명이 반복된다
제약	무엇을 빼고 어디까지 할지	범위를 과하게 키우지 않게 막아준다	불필요한 기능, 복잡한 설계, 과한 기술 선택이 붙는다
출력 형식	어떤 순서와 모양으로 답을 받을지	읽기 쉽고 재사용하기 쉬운 답변을 만든다	답이 산만하거나 필요한 정보가 빠진다

지난 글의 페르소나가 “누가 답하나”에 가깝다면, 이번 글의 네 가지 요소는 “무엇을, 어떤 상황에서, 어디까지, 어떤 모양으로 받을 것인가”를 정하는 일이다. 둘은 따로 노는 개념이 아니라, 같이 붙을 때 훨씬 안정적으로 작동한다.

---

목표: 원하는 결과를 먼저 좁히기

목표는 가장 기본적인 항목이지만, 의외로 제일 자주 흐려진다. 많은 초보자가 바라는 것은 대체로 맞다. 앱을 만들고 싶고, 페이지를 고치고 싶고, 오류를 해결하고 싶다. 그런데 AI가 바로 쓸 수 있는 요청으로 바꾸려면, 바람이 아니라 결과물의 형태로 적어야 한다.

예를 들어 “투두 앱 만들어줘”는 방향만 있고 끝점이 없다. 반면 “HTML, CSS, JavaScript만 사용해서 할 일 추가·완료·삭제가 되는 1차 버전의 할 일 관리 페이지를 만들어줘”는 훨씬 다르다. 무엇을 만들지, 어느 정도까지 만들지, 어떤 기술로 할지가 한 번에 들어간다.

좋은 목표는 보통 아래 세 가지를 포함한다.

• 무엇을 만들지: 로그인 페이지인지, 예약 폼인지, 간단한 계산기인지
• 어디까지 할지: 1차 화면까지만인지, 기능까지 포함할지
• 무엇이 되면 끝인지: 추가/삭제만 되면 되는지, 저장까지 필요한지

[나쁜 예] 
투두 앱 만들어줘. 

[조금 나아진 예] 
할 일 관리 페이지의 1차 버전을 만들어줘. HTML, CSS, JavaScript만 사용해줘.

이번 단계에서 필요한 기능은 1. 할 일 추가 2. 할 일 완료 표시 3. 할 일 삭제 까지야.
회원가입, 데이터베이스 저장, 배포는 아직 필요 없어.

여기서 중요한 건 문장을 길게 만드는 게 아니다. AI가 어디서 멈춰야 하는지 알게 만드는 것이다. 목표가 좁혀지면 답변도 안정되고, 수정 요청도 쉬워진다. 초보자 입장에서는 바로 이 차이가 크다. 처음부터 큰 앱을 통째로 받기보다, 작은 목표를 분명하게 주는 쪽이 따라가기도 훨씬 낫기 때문이다.

---

맥락: 지금 상태를 알려줘야 답이 맞아진다

맥락은 “지금 나는 어떤 상황인가”를 알려주는 부분이다. AI는 내 화면을 보고 있는 것도 아니고, 내가 어디까지 이해했는지도 자동으로 알지 못한다. 그래서 같은 요청이라도 맥락이 없으면 너무 쉬운 답, 너무 어려운 답, 이미 해본 설명이 섞인 답이 나올 수 있다.

초보자가 맥락에 넣으면 좋은 정보는 대체로 이 정도다.

• 내 수준: 코딩 초보인지, JavaScript 기초만 아는지
• 현재 기술 선택: 바닐라 JS인지, React인지, Python인지
• 지금까지 한 것: 파일은 만들었는지, 일부 기능은 구현했는지
• 현재 문제: 오류 메시지가 있는지, 어떤 동작이 안 되는지
• 사용 목적: 공부용인지, 사내 업무 자동화 초안인지

맥락은 길게 쓴다고 무조건 좋은 게 아니다. 중요한 건 지금 답변에 직접 영향을 주는 정보만 넣는 것이다. 내 컴퓨터 브랜드, 지난주에 본 강의 제목 같은 정보는 보통 도움이 되지 않는다. 반대로 “나는 React는 아직 안 배웠다” 같은 정보는 결과를 꽤 많이 바꾼다.

[맥락을 잘 넣은 예] 
나는 코딩 초보다. HTML, CSS, JavaScript의 기본 문법만 안다. 
프레임워크는 아직 배우지 않았고, 지금은 로컬에서 바로 실행되는 예제로 구조를 익히는 중이다.
현재 index.html, style.css, script.js 파일은 만들어 둔 상태다. 
할 일 추가 버튼까지는 연결했는데, 입력값이 비어 있어도 항목이 추가되는 문제가 있다.

이 정도만 있어도 AI는 설명 수준을 낮추고, 프레임워크를 섞지 않고, 지금 막힌 문제를 중심으로 답할 가능성이 높아진다. 맥락이 빠진 요청은 자주 “정답 같지만 지금 내 문제에는 안 맞는 답”으로 흘러간다.

---

제약: 범위를 정해야 결과가 흔들리지 않는다

제약은 초보자가 가장 자주 빼먹는 부분이다. 그런데 실제로는 이 항목이 결과를 꽤 많이 바꾼다. AI는 기본적으로 가능한 선택지를 넓게 떠올리는 편이라, 제약이 없으면 답이 자꾸 커진다. 간단한 예제가 필요했는데 폴더 구조가 갑자기 복잡해지고, 아직 필요 없는 기능이 달라붙고, 입문자에게는 벅찬 기술 스택이 튀어나오기도 한다.

제약은 AI를 답답하게 묶는 장치가 아니다. 오히려 지금 필요한 답을 고르게 만드는 필터에 가깝다. 초보자일수록 “무엇을 넣을까”보다 “무엇을 아직 넣지 않을까”를 정하는 편이 훨씬 중요하다.

제약에는 보통 이런 것들이 들어간다.

• 기술 제약: React 사용 금지, HTML/CSS/JS만 사용
• 범위 제약: 로그인과 결제는 제외, 1차 화면까지만
• 설명 제약: 어려운 용어는 바로 풀어서 설명
• 복잡도 제약: 파일 수 최소화, 지나친 추상화 피하기
• 판단 제약: 불확실한 건 단정하지 말고 전제부터 구분

[제약을 적는 예] 
이번 답변에서는 
- React, Vue 같은 프레임워크는 사용하지 말 것 
- 파일은 3개 이하로 유지할 것
- 로그인, 회원가입, 데이터 저장 기능은 포함하지 말 것
- 디자인보다 기능 이해를 우선할 것 - 어려운 용어는 바로 쉬운 말로 풀어서 설명할 것
- 애매한 부분은 추정하지 말고 필요한 전제를 먼저 짚을 것

초보자에게는 “무엇을 더 넣을지”보다 “무엇을 이번에는 빼둘지”를 정하는 일이 더 중요할 때가 많다.

제약을 잘 걸면 AI는 화려한 답보다 지금 다룰 수 있는 답을 내놓기 쉬워진다. 그리고 바로 그 점이 바이브 코딩 초반에는 꽤 큰 차이를 만든다.

---

출력 형식: 답변 모양까지 정해두기

같은 내용이라도 어떤 순서로 받느냐에 따라 이해 난도가 크게 달라진다. 초보자에게 특히 그렇다. 설명이 먼저 와야 하는 사람도 있고, 코드 전체를 먼저 보고 나중에 해설을 읽는 편이 편한 사람도 있다. 그래서 출력 형식은 사소한 포장 문제가 아니라, 답을 활용할 수 있게 만드는 구조 문제라고 보는 편이 맞다.

출력 형식을 정해두면 이런 점이 좋아진다.

• 답변이 산만하게 흩어지지 않는다.
• 빠진 정보를 다시 요청하는 횟수가 줄어든다.
• 복붙할 부분과 읽어야 할 부분이 분리된다.
• 나중에 같은 형식으로 반복 사용하기 쉽다.

상황	추천하는 출력 형식
처음 배우면서 만들 때	개념 요약 → 파일 구조 → 전체 코드 → 핵심 설명 → 연습 과제
오류를 고칠 때	원인 추정 → 확인할 부분 → 수정 코드 → 테스트 방법
코드 검토를 받을 때	문제점 → 왜 문제인지 → 수정 우선순위 → 개선 예시

입문자라면 출력 형식을 너무 복잡하게 짤 필요는 없다. 다만 아래 정도는 미리 써두는 편이 좋다.

[출력 형식 예시] 
답변은 아래 순서로 작성해줘.
1. 내가 만들게 될 결과를 두세 문장으로 먼저 요약 
2. 필요한 파일 구조 정리 
3. 전체 코드 제시 
4. 핵심 코드가 왜 필요한지 설명 
5. 내가 직접 확인할 체크리스트 정리

이렇게 적어두면 AI가 중간에 설명을 빼먹거나, 코드만 길게 던지고 끝내는 일을 줄일 수 있다. 특히 글을 보면서 따라치는 초보자에게는 답의 순서가 생각보다 중요하다.

---

실전 예시와 초보자용 템플릿

이제 네 가지를 한 번에 묶어보면 훨씬 감이 잘 온다. 아래 예시는 코딩 초보가 간단한 할 일 관리 페이지를 부탁한다고 가정한 요청이다. 일부러 길이를 과하게 늘리지 않고, 실제로 바로 가져다 쓸 수 있는 수준으로 정리했다.

너는 코딩 초보에게 설명하는 웹 개발 튜터다. 
[목표] 
할 일 관리 페이지의 1차 버전을 만들어줘. HTML, CSS, JavaScript만 사용해줘. 
이번 단계에서는 1. 할 일 추가 2. 완료 표시 3. 삭제 기능까지만 있으면 된다.

[맥락]
나는 코딩 초보다. HTML, CSS, JavaScript 기초만 알고 있다. 프레임워크는 아직 배우지 않았고, 로컬에서 바로 실행되는 예제로 구조를 익히고 싶다. 

[제약] 
React, Vue 같은 프레임워크는 쓰지 말아줘. 
파일은 index.html, style.css, script.js 정도로 단순하게 나눠줘.
회원가입, 데이터베이스 저장, 배포 기능은 이번 답변에 넣지 말아줘.
어려운 용어는 바로 쉬운 말로 풀어서 설명해줘. 

[출력 형식]
답변은 아래 순서로 정리해줘. 
1. 무엇을 만들지 짧게 요약 
2. 파일 구조 
3. 전체 코드
4. 핵심 코드 설명 
5. 내가 직접 바꿔볼 연습 과제 3개

이 요청이 좋은 이유는 화려해서가 아니다. AI가 추정해야 할 부분을 많이 줄여놨기 때문이다. 무엇을 만들지, 지금 내 수준이 어떤지, 어디까지 할지, 어떤 모양으로 답을 받을지가 다 들어가 있다. 그래서 결과가 완벽하지 않더라도, 수정 요청을 이어가기가 쉬워진다.

처음엔 이 정도의 짧은 템플릿만 써도 된다

처음부터 긴 요청을 쓰기 어렵다면, 아래 네 줄만 적어도 출발은 꽤 괜찮다.

[목표] 
무엇을 만들거나 고칠지 한 줄로 적기 

[맥락]
내 수준, 현재 상태, 이미 한 작업 적기

[제약]
쓰지 않을 기술, 제외할 범위, 설명 수준 적기 

[출력 형식] 
답을 어떤 순서로 받고 싶은지 적기

자주 하는 실수도 같이 알아두면 좋다

• 목표가 너무 넓다
  “쇼핑몰 만들어줘”처럼 큰 요구를 한 번에 던지면 결과가 쉽게 흐려진다.
• 맥락이 없다
  내가 초보자인지, 이미 어디까지 했는지 빠지면 답변 난도가 맞지 않기 쉽다.
• 제약이 없다
  지금 필요 없는 기능이 붙고 구조가 과하게 커진다.
• 출력 형식을 안 적는다
  코드만 길게 나오거나, 설명과 결과가 뒤섞여 읽기 어려워질 수 있다.
• 한 번의 요청으로 끝내려 한다
  좋은 요청은 한 번에 완성되는 마법 문장이 아니라, 수정하기 좋은 초안을 만드는 도구에 가깝다.

이 마지막 부분이 특히 중요하다. 좋은 요청을 쓴다고 해서 한 번에 모든 것이 해결되지는 않는다. 다만 대화가 망가지지 않게 만드는 출발점은 만들어준다. 그 차이가 실제 사용에서는 꽤 크다.

---

마무리

페르소나가 “누가 답하느냐”를 정하는 일이라면, 이번 글에서 다룬 네 가지는 “무엇을, 어떤 상황에서, 어디까지, 어떤 모양으로 받을 것인가”를 정하는 일이다. 둘이 함께 붙으면 AI의 답변은 훨씬 덜 흔들린다. 입문자 입장에서는 이것만으로도 이미 시행착오가 꽤 줄어든다.

결국 좋은 요청의 핵심은 거창한 표현이 아니다. 목표를 좁히고, 맥락을 알려주고, 제약을 걸고, 출력 형식을 정하는 것. 이 네 가지가 들어가면 AI가 내 의도를 덜 오해하게 된다. 다음 단계는 여기서 한 걸음 더 나아가, 큰 요청을 한 번에 던지지 않고 작은 작업 단위로 나누는 법이다. 바이브 코딩이 조금씩 편해지는 지점도 보통 그때부터다.