"딸깍"도 쉽지 않다. AI 프롬프트 잘 쓰는 방법!

웃긴 이야기지만, AI에게 업무를 맡길 때도 비슷한 일이 생깁니다. “광고 문구 잘 써줘”, “보고서 보기 좋게 정리해줘”, “신청 관리 기능 만들어줘.” 내 머릿속에는 분명한 그림이 있는데, 결과물은 그 그림과 조금씩 다릅니다.



이 글은 특정 모델의 성능 실험이 아니라, 카드뉴스의 비유를 바탕으로 업무 지시를 구체화하는 방법을 정리한 실무 가이드입니다.

1. 좋은 프롬프트는 길이가 아니라 해석의 여지를 줄입니다

우유 이야기를 명확하게 바꾸면 간단합니다. “우유는 1개 사 와. 아보카도가 있으면 아보카도를 6개 사고, 없으면 사지 마.” 대상과 수량, 조건과 예외를 분리한 것입니다.

업무 지시도 같습니다. “잘”, “깔끔하게”, “매력적으로”는 원하는 인상을 표현하지만, 결과를 판정하는 기준으로는 부족합니다. “광고 제목 3개”와 “인스타그램 무료 체험 광고용 제목을 공백 포함 20자 이내로 3개”는 서로 다른 요청입니다.

그렇다고 모든 프롬프트를 장문으로 만들 필요는 없습니다. 이미 합의된 정보는 자료로 연결하고, 이번 작업에서 달라지는 조건만 선명하게 적으면 됩니다. 핵심은 길게 설명하는 것보다, AI가 임의로 결정하면 안 되는 부분을 지정하는 것입니다.

2. 시작 전에 채워야 할 여섯 가지

3. “광고 문구 써줘”를 실무 요청으로 바꾸면

다음은 무료 체험 광고를 가정한 예시입니다. 대괄호를 실제 업무 정보로 바꾸고, 무료 체험이 제공되는지부터 확인해 사용하세요. 조건을 확인하지 않은 채 그럴듯한 문구부터 만드는 순서를 피하는 것이 중요합니다.




이 요청은 단순히 문장을 예쁘게 만드는 데서 끝나지 않습니다. 사용 가능한 사실, 만들면 안 되는 정보, 검수할 형식을 함께 정합니다. AI가 근거 위치를 적으면 담당자는 소개서의 해당 부분과 대조하기도 쉬워집니다.

다만 “확인된 사실만 쓰라”고 지시했다고 정확성이 보장되지는 않습니다. 글자 수는 실제 편집기나 별도 도구로 다시 세고, 무료 체험 기간·대상·결제 전환 조건처럼 중요한 내용은 원자료와 대조해야 합니다. 최종 광고의 책임을 완료 메시지에 넘기지 않는 것이 핵심입니다.

4. 보고서도 ‘정리’보다 판단 기준을 먼저

이 원칙은 문구 작성에만 적용되지 않습니다. 광고 성과 보고서를 맡긴다고 가정해 보겠습니다. “이번 달 성과를 분석해줘”에는 어떤 전환을 볼지, 무엇과 비교할지, 부가세나 취소 건은 어떻게 처리할지 등이 빠져 있을 수 있습니다.




예를 들어 캠페인별 전환당 비용을 단순 평균한 값은 전체 지출을 전체 전환수로 나눈 값과 다를 수 있습니다. 원하는 산식을 미리 정하면 그럴듯한 숫자를 받아 놓고 뒤늦게 집계 방식을 다시 확인하는 일을 줄일 수 있습니다. 이는 특정 광고 계정의 분석 결과가 아니라 집계 원칙을 설명하기 위한 예시입니다.

5. 바이브코딩은 화면 밖의 조건까지 말해야 합니다

자연어로 요구사항을 설명하며 AI와 코드를 만드는 작업에서는 지시의 빈칸이 더 넓게 영향을 줄 수 있습니다. 목록 화면에 필터 하나를 추가해도 검색, 정렬, 페이지 이동, 조회 권한이 함께 연결되어 있기 때문입니다.

“신청 관리 기능 만들어줘” 대신 누가 어떤 데이터를 볼 수 있는지, 상태가 어떤 순서로 바뀌는지, 어디까지 수정해도 되는지를 나눠야 합니다. 화면이 정상적으로 보이는 것만으로 기능이 안전하게 완성됐다고 판단할 수는 없습니다.




여기서 중요한 것은 상태 필터라는 기능 자체보다 변경 범위와 유지할 동작을 함께 선언한 점입니다. 특히 권한은 화면에서 버튼을 숨기는 것과 서버가 접근을 차단하는 것이 다릅니다. 허용되지 않은 사용자의 직접 요청도 거부되는지 확인해야 합니다.

작업은 계획 → 구현 → 검증으로 나누세요. 계획에서는 영향 범위를 확인하고, 구현은 작은 단위로 진행하며, 검증에서는 새 기능뿐 아니라 원래 되던 기능도 점검합니다. 이것이 회귀 테스트입니다. 테스트를 실행할 수 없는 환경이라면 “통과”가 아니라 “미검증”으로 남겨야 합니다.

6. 매번 설명하는 내용은 문서로 옮깁니다

고객 정의, 제품 정보, 권한 기준을 매번 새 대화에 적다 보면 일부가 빠지거나 버전이 달라질 수 있습니다. 반복되는 맥락은 프로젝트 문서로 남기고, 이번 작업에서 읽어야 할 경로를 지정하는 편이 관리하기 좋습니다.

아래는 카드뉴스에서 제안한 문서 구성 예시입니다. 반드시 폴더 8개를 만들어야 한다는 뜻은 아닙니다. 작은 프로젝트라면 하나의 문서 안에 항목별로 나누어 시작해도 됩니다.




SOT는 Source of Truth, 판단의 기준이 되는 정본을 뜻합니다. 파일 이름을 00-SOT로 만들었다고 기준이 저절로 생기는 것은 아닙니다. 팀이 합의한 정책, 문서 담당자, 갱신일, 규칙이 충돌할 때 누구에게 확인할지가 있어야 합니다.

마케팅 팀이라면 먼저 고객 정의, 제품에서 주장할 수 있는 사실, 금지 표현, 전환 집계 기준, 검수 체크리스트를 한곳에 모으는 것부터 시작할 수 있습니다. 민감한 고객 정보나 비밀번호를 문서에 그대로 넣기보다 승인된 보관 위치와 접근 방법을 안내하세요.

문서를 만들었다는 사실만으로 AI가 내용을 읽었다고 볼 수도 없습니다. 작업 시작 시 관련 경로를 지정하고, 이번 작업에 적용할 규칙을 요약하게 하세요. 문서와 실제 구현이 다르면 임의로 선택하게 하지 말고 차이를 보고하도록 요청해야 합니다.

7. “완료했습니다” 다음에 확인할 것

AI의 완료 보고는 검수의 출발점입니다. 광고 문구라면 원자료와 일치하는지, 보고서라면 집계 기준과 산식이 맞는지, 기능이라면 권한과 예외 상황에서도 동작하는지를 실제 결과로 확인해야 합니다.




AI 활용에서 줄여야 할 것은 클릭 수만이 아닙니다. 같은 설명을 반복하는 시간, 잘못 해석된 결과를 고치는 시간, 확인되지 않은 내용을 다시 검수하는 시간도 함께 줄여야 합니다.