12장. AI에게 잘 시키는 요구사항 작성법

지난 장에서 우리는 무엇을 만들지 정리했습니다. 이제 종이 위의 기획을 실제 작업으로 옮길 차례입니다. 여기서 많은 사람이 기대 반, 걱정 반으로 이런 말을 합니다.

"AI한테 시키면 알아서 잘 만들어주지 않을까?"

반은 맞고, 반은 틀립니다.

AI는 분명 강력합니다. 하지만 막연한 요청을 마법처럼 완벽한 결과로 바꿔주는 존재는 아닙니다. 오히려 AI와의 작업에서는 아주 인간적인 능력이 중요해집니다. 내가 원하는 것을 분명하게 설명하는 능력, 범위를 좁혀 말하는 능력, 결과를 보고 검토하는 능력입니다.

쉽게 말해, AI 실력의 절반은 모델이 아니라 요청을 쓰는 사람의 설명력에서 나옵니다.

같은 도구를 써도 어떤 사람은 금방 원하는 결과를 얻고, 어떤 사람은 계속 엉뚱한 답만 받습니다. 차이는 대개 "더 좋은 모델을 썼는가"보다 "더 좋은 요구사항을 썼는가"에서 갈립니다.

이 장에서는 AI에게 잘 시키는 법을 배웁니다. 좋은 프롬프트의 구조, 꼭 넣어야 할 제약 조건, 일을 잘게 나누는 방식, 그리고 받은 결과를 어떻게 검토할지를 차근차근 살펴보겠습니다. 이 장을 지나면 AI는 그저 신기한 도구가 아니라, 함께 일할 수 있는 조수처럼 느껴질 것입니다.

좋은 결과는 좋은 질문에서 시작된다

AI에게 요청할 때 초보자가 가장 자주 하는 실수는 이것입니다.

"로그인 기능 만들어줘."

이 말이 완전히 틀린 것은 아닙니다. 하지만 너무 넓습니다. 어떤 기술을 쓰는지, 지금 프로젝트 상태가 어떤지, 회원가입까지 포함하는지, 디자인도 필요한지, 에러 처리도 해야 하는지, 어디까지를 끝으로 볼 것인지가 빠져 있습니다.

이렇게 요청하면 AI는 빈칸을 스스로 채우기 시작합니다. 문제는 그 빈칸이 내가 원하는 방향과 다를 수 있다는 점입니다. AI는 열심히 상상해서 답하지만, 그 상상이 언제나 정답은 아닙니다.

반대로 이런 요청은 훨씬 낫습니다.

Next.js와 Supabase를 쓰는 초보자용 개인 기록 웹 서비스입니다. 이메일/비밀번호 회원가입과 로그인을 구현하고 싶습니다. 이번 단계에서는 디자인보다 기능 연결이 우선입니다. 먼저 필요한 파일과 구현 순서를 설명한 뒤, 한 단계씩 진행해 주세요.

이 요청은 훨씬 선명합니다. 도구가 보이고, 목표가 보이고, 우선순위가 보이고, 작업 방식도 보입니다. AI 입장에서는 훨씬 일하기 쉽습니다.

좋은 요청은 똑똑해 보이는 문장이 아닙니다. AI가 오해하지 않도록 상황을 정리한 문장입니다.

프롬프트는 명령문이 아니라 작업 브리프다

프롬프트라고 하면 거창하게 느껴질 수 있습니다. 하지만 이 책에서는 프롬프트를 어렵게 생각하지 않겠습니다. 프롬프트는 그냥 AI에게 건네는 작업 지시서입니다.

회사에서 디자이너에게 화면을 부탁할 때도, 동료에게 문서 정리를 요청할 때도, "알아서 예쁘게 해줘"라고만 하면 일이 꼬입니다. AI도 마찬가지입니다. 무엇을 원하는지, 무엇은 원하지 않는지, 어디까지가 이번 작업인지 알려줘야 합니다.

즉, 좋은 프롬프트는 특별한 주문이 아니라 정리된 업무 전달입니다.

지난 장에서 만든 PRD가 서비스의 큰 지도였다면, 이번 장에서 배우는 프롬프트는 지금 당장 할 한 걸음의 지시서입니다. PRD가 "무엇을 만들지"를 정리했다면, 프롬프트는 "지금 무엇부터 어떻게 하게 할지"를 정리합니다.

좋은 프롬프트의 기본 구조

AI에게 일을 맡길 때는 아래 순서로 생각하면 훨씬 안정적입니다.

• 지금 무엇을 만드는지

• 현재 상태가 어떤지

• 이번 요청에서 정확히 무엇을 해달라는지

• 무엇을 하면 안 되는지

• 어떤 형태로 답을 받고 싶은지

• 결과를 무엇으로 확인할 것인지

이 여섯 가지가 들어가면 프롬프트가 훨씬 단단해집니다. 하나씩 쉽게 풀어보겠습니다.

1. 목표를 먼저 말하기

가장 먼저 필요한 것은 목표입니다. AI가 지금 어떤 방향으로 달려야 하는지 알아야 하기 때문입니다.

예를 들어 이렇게 시작할 수 있습니다.

개인 기록 웹 서비스의 로그인 기능을 만들고 싶습니다.

이 문장은 짧지만 방향을 줍니다. 더 좋게 하려면 기술과 맥락도 덧붙일 수 있습니다.

Next.js와 Supabase를 사용하는 개인 기록 웹 서비스에서 이메일/비밀번호 로그인 기능을 구현하고 싶습니다.

이 정도만 써도 AI는 훨씬 덜 헤맵니다. 목표가 없으면 답은 길어질 수 있어도 쓸모는 줄어듭니다.

2. 현재 상태를 알려주기

AI는 프로젝트 폴더를 열어보지 않는 한, 지금 어디까지 되었는지 모릅니다. 그래서 현재 상태를 짧게 알려주는 것이 중요합니다.

예를 들어 이런 식입니다.

프로젝트는 생성되어 있고, 홈 화면과 글 목록 화면의 기본 UI는 있습니다. 아직 로그인 기능과 데이터 연결은 없습니다.

이 한두 문장이 아주 중요합니다. 그래야 AI가 이미 있는 것을 또 만들지 않고, 없는 부분에 집중할 수 있습니다.

특히 초보자는 이 부분을 자주 빼먹습니다. 그러면 AI는 처음부터 끝까지 새로 설계하려 하고, 사용자는 "아니, 그건 이미 했는데?" 하며 다시 설명하게 됩니다. 이런 왕복이 반복되면 금방 지칩니다.

3. 이번 요청의 범위를 딱 잘라 말하기

AI와 작업할 때 가장 중요한 습관 하나를 꼽으라면 이것입니다.

한 번에 하나의 덩어리만 시킨다.

예를 들어 "회원가입, 로그인, 글 작성, 검색, 배포까지 다 해줘"라고 하면, 얼핏 시원해 보이지만 실제로는 좋지 않습니다. 범위가 너무 넓으면 결과도 뭉뚱그려지고, 중간에 어디서 잘못됐는지 찾기도 어렵습니다.

그래서 이번 요청의 범위를 명확히 끊어줘야 합니다.

이번 단계에서는 로그인 화면과 로그인 처리만 구현하고 싶습니다. 회원가입 화면, 비밀번호 재설정, 소셜 로그인은 아직 하지 않습니다.

이 문장 하나로 일이 훨씬 쉬워집니다. AI도 덜 욕심내고, 나도 덜 흔들립니다.

4. 제약 조건을 분명하게 넣기

초보자가 AI와 협업할 때 결과가 흔들리는 가장 큰 이유 중 하나는 제약 조건이 빠져 있기 때문입니다. AI는 빈칸이 있으면 채우려는 성향이 있습니다. 그때 기준이 없으면, 너무 어려운 구조를 제안하거나, 아직 배우지 않은 기술을 끌고 올 수 있습니다.

그래서 제약 조건은 꼭 적어야 합니다. 예를 들어 이런 것들입니다.

• 사용하는 기술 스택은 무엇인가

• 이번 작업에서 수정 가능한 범위는 어디까지인가

• 아직 하지 않을 기능은 무엇인가

• 초보자 기준으로 쉽게 설명이 필요한가

• 코드만 받을지, 설명과 함께 받을지

이 책의 독자에게 특히 중요한 제약 조건은 아래와 같습니다.

• 초보자도 이해할 수 있는 방식으로 설명해 달라고 요청하기

• 너무 복잡한 패턴이나 과도한 추상화는 피하라고 요청하기

• 현재 책의 범위를 벗어나는 기능은 넣지 말라고 요청하기

• 기존 파일을 모두 갈아엎지 말고 필요한 부분만 수정하라고 요청하기

예를 들어 좋은 제약 문장은 이렇습니다.

초보자가 따라가는 프로젝트이므로 복잡한 설계 패턴은 피하고, 파일 구조를 과하게 늘리지 말아 주세요. 기존 화면은 유지하고 필요한 최소 수정만 해 주세요.

이 문장은 생각보다 강력합니다. AI가 괜히 멋진 구조를 보여주겠다고 프로젝트를 거대하게 바꾸는 일을 줄여줍니다.

5. 답변 형식을 지정하기

AI는 같은 질문에도 다양한 방식으로 답할 수 있습니다. 설명 위주로 답할 수도 있고, 코드만 줄 수도 있고, 순서를 나눠 제안할 수도 있습니다. 그래서 어떤 형태로 답을 원하는지 미리 말해주는 것이 좋습니다.

예를 들어 아래처럼 요청할 수 있습니다.

• 먼저 구현 순서를 설명한 뒤 코드를 제안해 주세요.

• 수정할 파일 목록을 먼저 보여주세요.

• 한 번에 다 하지 말고 1단계만 진행해 주세요.

• 코드와 함께 왜 그렇게 했는지 짧게 설명해 주세요.

• 마지막에 내가 확인할 체크리스트를 붙여 주세요.

이렇게 답변 형식을 정하면, AI의 대답이 훨씬 읽기 쉬워집니다. 특히 초보자는 긴 코드보다 구조가 보이는 답변이 더 도움이 됩니다.

6. 완료 기준을 넣기

요청을 잘 썼는데도 결과가 애매한 경우가 있습니다. 이유는 끝의 기준이 없기 때문입니다. 어디까지 되면 "완료"인지 정해주지 않으면, AI도 적당히 끝낸 듯한 답을 줄 수 있습니다.

예를 들어 이런 완료 기준이 좋습니다.

완료 기준: 사용자가 이메일과 비밀번호를 입력해 로그인할 수 있고, 성공하면 글 목록 페이지로 이동해야 합니다. 실패하면 에러 메시지가 보여야 합니다.

이제 AI는 단순히 로그인 폼만 만드는 데 그치지 않고, 성공과 실패 흐름까지 챙기게 됩니다.

한 번에 잘 쓰기 어려우면 이 순서로 적어라

처음부터 완벽한 프롬프트를 쓰기는 어렵습니다. 그럴 때는 아래 틀을 그대로 따라 써도 됩니다.

목표:
무엇을 만들고 싶은지 한 문장으로 적는다.

현재 상태:
지금까지 된 것과 안 된 것을 짧게 적는다.

이번 요청 범위:
이번 단계에서 해달라는 작업만 적는다.

제약 조건:
사용 기술, 하지 않을 것, 복잡도를 적는다.

답변 형식:
설명 방식, 코드 제시 방식, 단계 진행 방식을 적는다.

완료 기준:
어떤 상태가 되면 끝인지 적는다.

이 틀은 단순하지만 매우 실용적입니다. AI와 협업할 때는 화려한 문장보다 빠진 정보가 없는 문장이 훨씬 중요합니다.

나쁜 프롬프트와 좋은 프롬프트 비교하기

실감 나게 보기 위해, 같은 작업을 두 방식으로 요청해보겠습니다.

먼저 나쁜 프롬프트입니다.

로그인 기능 만들어줘.

짧고 편하긴 하지만, 문제가 많습니다. 어떤 프로젝트인지 모르고, 어떤 기술인지 모르고, 어느 정도까지 원하는지도 모릅니다. 이 요청은 AI에게 일을 시키는 것이 아니라, 거의 추측 게임을 시키는 수준입니다.

이제 같은 요청을 조금만 다듬어보겠습니다.

Next.js와 Supabase를 사용하는 개인 기록 웹 서비스입니다.
현재 홈 화면과 글 목록 UI는 만들어져 있고, 아직 인증 기능은 없습니다.
이번 단계에서는 이메일/비밀번호 로그인 화면과 로그인 처리만 구현하고 싶습니다.
회원가입, 소셜 로그인, 비밀번호 재설정은 이번 작업에 포함하지 마세요.
초보자가 이해할 수 있도록 복잡한 구조는 피하고, 필요한 파일만 최소한으로 수정해 주세요.
먼저 어떤 파일을 만들거나 수정할지 설명하고, 그다음 코드를 제안해 주세요.
완료 기준은 사용자가 로그인에 성공하면 /posts로 이동하고, 실패하면 에러 메시지가 보이는 것입니다.

이제 AI는 훨씬 정확하게 일할 수 있습니다. 핵심은 문장이 길어졌다는 점이 아니라, 오해할 빈칸이 줄어들었다는 점입니다.

잘 시키는 사람은 "무엇을 하지 말지"도 말한다

초보자는 보통 "무엇을 해달라"는 말은 잘합니다. 하지만 "무엇을 하지 말라"는 말은 자주 빠뜨립니다. 그런데 실제 작업에서는 이 금지선이 아주 중요합니다.

예를 들어 이런 말을 넣을 수 있습니다.

Tailwind CSS만 사용하고, 새로운 UI 라이브러리는 추가하지 마세요.

지금은 기능 구현이 목적이므로 디자인 리뉴얼은 하지 마세요.

데이터베이스 구조 변경은 하지 말고, 화면과 연결만 진행해 주세요.

아직 배우지 않은 고급 상태 관리 도구는 사용하지 마세요.

이런 제약은 AI를 답답하게 만드는 것이 아니라, 오히려 정확하게 일하게 만드는 울타리입니다. 울타리가 있으면 속도가 느려지는 것이 아니라, 길을 잃지 않게 됩니다.

일을 잘게 나누면 AI도, 사람도 덜 지친다

AI에게 일을 맡길 때 생기는 대표적인 문제는 "한 번에 너무 많은 것을 시킨다"는 점입니다. 그러면 답도 길어지고, 검토도 힘들어지고, 어디서부터 적용해야 할지 감이 사라집니다.

그래서 큰 기능은 작은 단계로 나누는 것이 좋습니다.

예를 들어 로그인 기능도 사실은 여러 단계로 쪼갤 수 있습니다.

• 필요한 화면과 흐름 정리

• 로그인 폼 UI 만들기

• 입력값 검증 붙이기

• 인증 로직 연결하기

• 성공/실패 처리하기

• 이동 경로와 보호 페이지 점검하기

이렇게 나누면 무엇이 됐고 무엇이 안 됐는지 분명해집니다. AI도 더 안정적으로 답할 수 있고, 사람도 한 단계씩 이해하며 따라갈 수 있습니다.

단계 분할은 이렇게 하면 쉽다

작업을 나눌 때는 보통 아래 순서가 편합니다.

먼저 설계만 시킨다

처음부터 코드부터 받지 말고, 먼저 구조를 물어보는 방식입니다.

예를 들면 이렇게 묻습니다.

로그인 기능을 붙이기 전에 필요한 화면, 파일, 흐름을 먼저 정리해 주세요.

이렇게 하면 AI가 큰 그림을 보여줍니다. 초보자에게는 이 단계가 매우 중요합니다. 코드를 보기 전에 "무엇이 생길지" 알아야 덜 무섭기 때문입니다.

다음은 가장 작은 기능부터 만든다

설계를 봤다면, 이제 가장 작은 한 조각만 요청합니다.

먼저 로그인 화면 UI만 만들어 주세요. 아직 실제 로그인 처리 연결은 하지 마세요.

이렇게 하면 화면 구조부터 눈에 익힐 수 있습니다. 갑자기 모든 것이 한꺼번에 움직이지 않아서 훨씬 덜 부담스럽습니다.

그다음 연결 작업을 붙인다

UI가 되면 로직을 연결합니다.

이제 로그인 버튼을 눌렀을 때 Supabase 인증이 동작하도록 연결해 주세요.

이제 작업 범위가 분명합니다. 화면은 이미 있으니, 이번에는 동작에만 집중할 수 있습니다.

마지막에 예외 처리를 요청한다

처음부터 모든 예외를 다 잡으려 하면 머리가 복잡해집니다. 그래서 마지막에 정리하는 방식이 좋습니다.

로그인 실패, 빈 입력값, 로딩 상태를 처리해 주세요.

이제 서비스가 조금 더 진짜처럼 보이기 시작합니다.

이 흐름은 로그인뿐 아니라 글 작성, 검색, 수정, 삭제, 배포에도 거의 그대로 적용됩니다. 설계 → 작은 구현 → 연결 → 예외 처리 → 점검의 순서라고 생각하면 됩니다.

AI에게 질문할 때는 추상어보다 장면을 써라

초보자가 흔히 쓰는 표현 중에는 너무 추상적인 말이 많습니다.

"깔끔하게 만들어줘." "좋은 UX로 해줘." "실무적으로 해줘."

이 말들은 사람이 들어도 애매합니다. AI에게는 더 애매합니다. 대신 장면이 보이게 써야 합니다.

예를 들어 이렇게 바꿀 수 있습니다.

"사용자가 모바일에서 봐도 버튼이 잘 눌리게 해줘."

"글 목록에서 제목과 작성일이 한눈에 보이게 해줘."

"로그인 실패 시 폼 아래에 빨간 글씨로 메시지를 보여줘."

좋은 요구사항은 멋있는 단어보다 사용자가 실제로 겪을 장면을 담고 있습니다. 장면이 보이면 구현도 쉬워집니다.

AI에게 설명이 아니라 판단을 맡길 때 주의할 점

AI는 선택지도 잘 제안합니다. 예를 들어 "로그인 후 어디로 보내는 게 좋을까?" 같은 질문에도 답할 수 있습니다. 다만 이럴 때는 판단의 기준을 함께 줘야 합니다.

예를 들어 이렇게 묻는 것이 좋습니다.

초보자용 개인 기록 서비스입니다. 로그인 후 이동 경로를 홈과 글 목록 중 어디로 잡는 것이 좋을지 추천해 주세요. 기준은 사용자가 바로 자신의 글을 확인하고 행동을 이어가기 쉬운가입니다.

이 질문은 좋습니다. 왜냐하면 AI가 그냥 취향으로 고르는 것이 아니라, 기준을 따라 추천하게 만들기 때문입니다.

AI에게 판단을 맡길 때는 늘 이렇게 생각하면 됩니다.

"정답을 달라고 하지 말고, 기준을 주고 추천을 받자."

결과를 받았을 때 바로 적용하지 말아야 하는 이유

AI가 코드를 줬다고 해서 곧바로 복사해서 붙여넣는 습관은 위험합니다. 결과가 그럴듯해 보여도, 실제 프로젝트에는 맞지 않을 수 있습니다. 파일 이름이 다를 수도 있고, 이미 있는 코드와 충돌할 수도 있고, 보안상 좋지 않은 방법이 숨어 있을 수도 있습니다.

그래서 결과를 받으면 먼저 짧게 검토해야 합니다. 초보자일수록 이 검토 습관이 중요합니다. AI는 빠르지만, 책임은 결국 사용자에게 있기 때문입니다.

결과 검토에서 꼭 봐야 할 네 가지

AI의 답을 받았을 때는 아래 네 가지를 먼저 확인하면 됩니다.

첫째, 내가 시킨 일에 답했는가

이것이 가장 중요합니다. 놀랍게도 AI는 꽤 자주 질문보다 넓게 답합니다. 로그인만 부탁했는데 회원가입, 프로필, 리다이렉트 정책까지 한꺼번에 제안할 수 있습니다.

그럴 때는 먼저 봐야 합니다.

"내가 시킨 범위 안에 있는가?"

좋은 답은 많이 해주는 답이 아니라, 지금 필요한 만큼 정확히 해주는 답입니다.

둘째, 범위를 넘어선 변경이 없는가

AI가 프로젝트를 크게 뜯어고치려 할 때가 있습니다. 예를 들어 폴더 구조 전체를 바꾸거나, 새 라이브러리를 여러 개 추가하거나, 아직 배우지 않은 패턴을 도입하는 경우입니다.

이때는 멋있어 보여도 한 번 멈춰야 합니다. 첫 서비스에서는 화려함보다 통제가 중요합니다.

"이 변경이 지금 꼭 필요한가?"

이 질문에 자신 있게 예라고 답하기 어렵다면, 더 단순한 방향을 요청하는 편이 좋습니다.

셋째, 성공만 있고 실패가 없는가

초보자는 동작하는 화면을 보면 안심합니다. 하지만 실제 서비스는 성공하는 경우만 있는 것이 아닙니다. 실패도 있고, 빈 상태도 있고, 로딩도 있습니다.

AI가 제안한 결과에 아래 장면이 있는지 꼭 보세요.

• 입력값이 비었을 때 어떻게 되는가

• 서버 요청 중일 때 사용자는 무엇을 보는가

• 실패했을 때 메시지가 보이는가

• 데이터가 없을 때 화면이 어색하지 않은가

이 네 가지를 챙기기 시작하면 결과물의 완성도가 눈에 띄게 올라갑니다.

넷째, 내가 이해할 수 있는가

이 질문은 의외로 중요합니다.

"지금 이 코드와 설명을 내가 대충이라도 이해하는가?"

완전히 다 알 필요는 없습니다. 하지만 어느 파일이 왜 바뀌는지, 어떤 흐름으로 동작하는지는 알아야 합니다. 그래야 나중에 에러가 나도 고칠 수 있습니다.

만약 설명이 너무 어렵다면 이렇게 다시 요청하면 됩니다.

초보자 기준으로, 지금 수정한 파일이 각각 어떤 역할을 하는지 쉬운 말로 설명해 주세요.

이 한 문장으로 AI는 다시 친절한 선생님 모드로 돌아옵니다.

검토 요청도 잘하면 품질이 좋아진다

많은 사람이 AI에게 "만들어줘"는 잘하지만, "검토해줘"는 잘 안 합니다. 하지만 실제로는 검토 요청이 아주 유용합니다.

예를 들어 이런 식으로 말할 수 있습니다.

방금 제안한 로그인 구현에서 초보자가 놓치기 쉬운 문제를 점검해 주세요.

이 코드가 요구사항과 맞지 않는 부분이 있는지 체크리스트 형식으로 검토해 주세요.

보안, 에러 처리, 사용자 경험 관점에서 빠진 점이 있는지 알려 주세요.

이렇게 하면 AI는 단순 생성기가 아니라 리뷰어처럼 일하기 시작합니다. 하나의 도구를 여러 역할로 활용하는 셈입니다.

막혔을 때는 "왜 안 되지?" 대신 "어디부터 봐야 하지?"라고 묻기

에러가 나면 초보자는 당황하기 쉽습니다. 이때 흔히 이렇게 말합니다.

"왜 안 돼?"

이 질문은 마음은 이해되지만, AI에게는 너무 넓습니다. 대신 진단이 가능하도록 바꿔야 합니다.

예를 들어 이렇게 묻는 편이 좋습니다.

로그인 버튼을 눌러도 이동이 되지 않습니다. 콘솔에는 어떤 메시지를 먼저 확인해야 하는지, 가능한 원인을 우선순위대로 알려 주세요.

또는 이렇게도 좋습니다.

Supabase 로그인 호출 뒤에 에러가 나는 것 같습니다. 초보자 기준으로 확인할 지점을 1단계씩 알려 주세요.

이런 질문은 훨씬 실용적입니다. 막막함을 바로 해결 가능한 행동으로 바꿔주기 때문입니다.

이 책 실습에 맞는 프롬프트 예시

이제 우리가 만들 서비스에 맞는 실제 예시를 하나 보겠습니다.

Next.js, Supabase, Tailwind CSS를 사용하는 초보자용 개인 기록 웹 서비스입니다.
현재 프로젝트는 생성되어 있고, 홈 화면과 글 목록의 기본 레이아웃만 있습니다.
이번 단계에서는 글 작성 페이지 UI만 만들고 싶습니다.
제목 입력창, 본문 입력창, 저장 버튼이 필요합니다.
아직 데이터베이스 저장 연결은 하지 말아 주세요.
디자인은 단순하게 유지하고, 새로운 라이브러리는 추가하지 마세요.
먼저 수정할 파일을 알려주고, 그다음 전체 코드를 제안해 주세요.
마지막에는 내가 확인할 체크리스트 3~5개를 붙여 주세요.
완료 기준은 사용자가 글 작성 화면에서 제목과 본문을 입력할 수 있고, 저장 버튼이 보이는 상태입니다.

이 프롬프트가 좋은 이유는 분명합니다. 무엇을 만드는지 보이고, 지금 하지 않을 일도 보이고, 답변 형식도 보이고, 완료 기준도 보입니다.

처음에는 길어도 괜찮다

좋은 프롬프트를 쓰려다 보면 "너무 길어지는 것 아닌가?"라는 걱정이 들 수 있습니다. 하지만 초보자 단계에서는 조금 길어도 괜찮습니다. 오히려 짧지만 애매한 요청보다, 길더라도 선명한 요청이 낫습니다.

중요한 것은 문장을 멋있게 쓰는 것이 아닙니다. 필요한 정보가 빠지지 않았는지입니다.

익숙해지면 점점 짧아질 것입니다. 하지만 처음에는 친절하게 많이 설명하는 편이 더 안전합니다. AI에게도, 나 자신에게도 그렇습니다.

좋은 요청은 결국 좋은 생각 정리다

여기까지 오면 눈치챘을지도 모릅니다. AI에게 잘 시키는 능력은 사실 AI 전용 기술이 아닙니다. 생각을 정리하고, 우선순위를 세우고, 범위를 구분하고, 원하는 결과를 말하는 능력입니다.

즉, 좋은 프롬프트는 말재주가 아니라 생각 정리 능력의 결과물입니다.

그래서 AI에게 잘 시키는 사람은 개발에서도 강합니다. 무엇을 만들지 알고, 지금 무엇을 할지 알고, 무엇을 미룰지도 알기 때문입니다. 이 감각이 쌓이면 AI는 점점 더 유능한 조수가 됩니다.

이 장에서 꼭 기억할 것

AI와 협업할 때 좋은 결과는 우연히 나오지 않습니다. 대부분은 좋은 요구사항에서 시작됩니다. 목표, 현재 상태, 이번 작업 범위, 제약 조건, 답변 형식, 완료 기준을 넣으면 프롬프트의 품질이 크게 올라갑니다.

또한 큰 작업은 잘게 나눠야 합니다. 설계부터 묻고, 작은 화면을 만들고, 기능을 연결하고, 마지막에 예외 처리를 점검하는 흐름이 초보자에게 특히 잘 맞습니다.

무엇보다 중요한 것은 AI의 답을 그대로 믿고 지나가지 않는 습관입니다. 내가 시킨 일에 답했는지, 범위를 넘지 않았는지, 실패 상황도 다뤘는지, 내가 이해할 수 있는지를 확인해야 합니다.

좋은 프롬프트는 AI를 더 똑똑하게 만드는 마법 주문이 아닙니다. 내 생각을 더 선명하게 전달하는 기술입니다.

이제 우리는 기획을 정리했고, 사용자 흐름을 그렸고, 데이터를 설계했고, AI에게 요구사항을 전달하는 방법까지 익혔습니다. 다음 부부터는 드디어 개발 환경을 준비하고, 실제 프로젝트를 만들며, 이 모든 준비가 어떻게 현실의 서비스로 바뀌는지 본격적으로 경험하게 될 것입니다.