프롬프트 엔지니어링이란? 비개발자를 위한 실용 가이드

프롬프트 엔지니어링은 AI 모델이 원하는 결과를 안정적으로 내도록 지시문을 작성하고 다듬는 일입니다. 프롬프트는 모델에게 주는 모든 것, 즉 질문, 과제, 맥락, 예시를 말합니다. 이를 엔지니어링한다는 것은 무엇을 넣을지 신중하게 정하고, 나온 결과를 점검하고, 조정하는 것입니다. 마법 같은 문구를 찾는 일이라기보다는 명확하게 소통하는 일에 가깝습니다.

AI로 만들 때 중요한 이유

AI 앱 빌더를 쓸 때 여러분의 프롬프트가 곧 명세서입니다. AI는 여러분이 설명한 것만 만들 수 있고, 요청에 빈틈이 있으면 그럴듯한 추측으로 채웁니다. 어떤 때는 추측이 맞지만, 종종 의도와 다릅니다. 잘못된 입력 필드, 원하지 않은 기능, 대상 고객에 맞지 않는 디자인 같은 것이죠.

명확한 프롬프트는 수정 횟수를 줄여줍니다. 수정할 때마다 시간이 들고, 보통 크레딧도 쓰입니다. 앱 안에 AI를 넣는 경우에도 프롬프트가 중요합니다. 그 모델에 준 지시가 챗봇의 말투, 거절할 내용, 사실을 지키는지 여부를 결정하기 때문입니다. 앱 제작 자체에 대해서는 AI 앱 빌더에 프롬프트를 작성하는 법을 참고하세요.

일상적인 비유

회사 사정을 전혀 모르는 숙련된 프리랜서에게 업무를 설명한다고 상상해 보세요. 그는 여러분의 말이 끝나자마자 바로 일을 시작합니다.

"로고 만들어 주세요"라고 하면 어떤 로고는 나옵니다. "두바이의 어린이 수영 교실 로고입니다. 친근하되 유치하지 않게. 파란색과 주황색. 수영모에 작게 찍혀도 잘 보여야 합니다. 마음에 드는 두 개와 싫은 하나를 첨부합니다"라고 하면, 원하는 것에 가까운 결과가 나옵니다.

AI 모델이 바로 그 프리랜서입니다. 재능 있고 빠르지만, 여러분의 설명에 전적으로 의존합니다. 프롬프트 엔지니어링은 좋은 업무 설명서를 쓰는 법을 배우는 것입니다.

핵심 기법

실제 예시: 전과 후

이전:

헬스장 앱 만들어 줘.

AI는 모든 것을 추측해야 합니다. 회원용인가, 직원용인가? 수업인가, 개인 트레이닝인가? 결제는? 아마도 가짜 운동 기록이 들어간 일반적인 대시보드가 나올 것입니다.

이후:

회원이 약 150명인 작은 복싱 체육관을 위한 웹 앱을 만들어 주세요.

사용자: 회원은 휴대폰으로 수업을 예약합니다. 사장인 Sam은 노트북으로 시간표를 관리합니다.

회원이 할 수 있는 것: 이번 주 수업(시간, 코치, 남은 자리)을 보고, 시작 2시간 전까지 예약하거나 취소할 수 있습니다.

Sam이 할 수 있는 것: 수업을 추가, 수정, 취소하고, 각 수업에 누가 예약했는지 볼 수 있습니다.

규칙: 수업당 최대 12명. 같은 시간대 중복 예약 금지.

지금은 제외: 결제, 운동 기록, 모바일 앱.

스타일: 어두운 배경, 빨간 포인트, 큰 터치 영역.

만들기 전에 불분명한 부분을 나열하고, 만들 페이지를 설명해 주세요.

두 번째 프롬프트가 영리해서 좋은 것이 아닙니다. 완전해서 좋은 것입니다. 사용자, 행동, 규칙, 제외할 것, 시작 방식을 명시했습니다. 마지막 줄은 AI가 코드를 쓰기 전에 계획을 세우고 질문하도록 유도해서, 오해를 미리 잡아냅니다.

앱 안의 프롬프트

앱 자체가 LLM을 호출하는 경우, 많은 사용자를 위해 여러 번 실행되는 프롬프트를 작성하게 됩니다. 같은 원칙이 적용되며, 몇 가지가 더 추가됩니다.

• 시스템 프롬프트: 모든 답변을 형성하는 고정 지시. 역할, 말투, 규칙. 예: "당신은 식물 가게 Leaf & Pot의 어시스턴트입니다. 주문, 식물, 배송에 관한 질문에만 답하세요."
• 근거 제공(grounding): 모델이 써야 할 사실, 예를 들어 정책이나 상품 카탈로그를 포함하고 그에 의존하라고 지시합니다. 이것이 왜 중요한지는 LLM이란 무엇인가를 참고하세요.
• 대체 응답: 확신이 없을 때 할 일을 지정합니다. 예: "제공된 정보에 답이 없으면 그렇게 말하고 지원 이메일을 안내하세요."
• 출력 형식: 코드가 답변을 읽는다면 JSON 같은 엄격한 형식을 요청합니다.
• 테스트: 실제 사용자가 먼저 시도하기 전에 까다로운 입력을 해보세요. 무례한 메시지, 주제에서 벗어난 질문, 지시를 무시하게 만들려는 시도(프롬프트 인젝션이라고 부릅니다)를 시험해 봅니다.

핵심 용어

흔한 실수와 오해

• 마법의 단어 찾기. "당신은 세계 최고의 전문가입니다" 같은 문구는 실제로 필요한 것을 말하는 것보다 훨씬 덜 중요합니다.
• 한꺼번에 모든 것 요청하기. 기능 20개를 한 번에 요청하면 반쯤 된 기능 20개가 나옵니다. 단계별로 만드세요.
• 해결책을 설명하고 문제는 설명하지 않기. "세 개의 열이 있는 표를 추가하세요"보다 "Sam은 각 수업에 누가 예약했는지 한눈에 봐야 합니다"가 더 유용합니다.
• 하지 말아야 할 것을 빠뜨리기. 로그인, 결제, 전체 리디자인을 아직 원하지 않는다면 그렇게 말하세요.
• 결과를 읽지 않기. 다음으로 넘어가기 전에 만들어진 것을 "완료" 정의에 비춰 테스트하세요.
• 다듬는 대신 처음부터 다시 시작하기. 보통 "좋아요, 여기서 X만 바꿔 주세요"처럼 짧은 후속 요청이 전체 프롬프트를 다시 쓰는 것보다 낫습니다.
• 프롬프트에 비밀 정보 붙여넣기. 도구에 안전한 저장 방법이 없다면 비밀번호나 실제 API 키를 채팅에 넣지 마세요.

AI 빌더에게 요청할 것

• "만들기 전에 질문을 하고 계획을 보여 주세요."
• "제가 원하는 것을 세 문장으로 다시 설명해 주세요."
• "예약 폼만 수정하고 다른 것은 건드리지 마세요."
• "제가 명시하지 않은 부분 중 무엇을 가정하셨나요?"
• "제 메모를 사용자, 기능, 규칙, '지금은 제외' 항목이 담긴 짧은 명세서로 바꿔 주세요. AI로 제품 요구사항 문서를 작성하는 법을 참고하세요."
• "이 요청을 어떻게 더 잘 표현할 수 있었을지 알려 주세요."

Mythex에서 프롬프트 작성하기

Mythex에는 이 방식에 맞는 채팅 모드가 세 가지 있습니다. Plan은 아무것도 바뀌기 전에 접근 방식을 합의하고, Build는 변경을 만들고, Ask는 파일을 수정하지 않고 질문에 답합니다. 스크린샷이나 목업을 맥락으로 첨부할 수 있고, 변경이 잘못되면 체크포인트로 되돌릴 수 있습니다. 문서의 효과적인 프롬프트와 반복하기 페이지에 더 많은 예시가 있고, AI로 만든 앱을 반복 개선하는 법은 후속 요청 과정을 다룹니다.

자주 묻는 질문