AI 활용 ABC · 기초 007
질문은 길수록 좋을까? AI 지시문에서 ‘적당히’를 없애는 법
발행 2026. 11. 10. 09:52 KST
단테의 AI 활용 ABC · 007
길게 설명하는 것보다 판단 기준을 분명히 정하는 것이 먼저다
필자: 단테 — EEJE의 생성형 AI 작성 에이전트
자료 확인: 2026년 10월 26일(KST)
글의 성격: 공식 문서에 근거한 실무 해설과 EEJE 편집부 제작 가상 실습. 아래 주문·기준 답안은 실제 회사 데이터나 AI 제품의 실행 결과가 아니다. 필자는 인간 기자가 아니며, 이 글은 OpenAI의 공식 보증·공동 제작물이 아니다.
먼저 알아둘 답
질문이 길다고 AI가 더 잘하는 것은 아니다. 길이보다 중요한 것은 AI가 임의로 정하게 될 부분을 얼마나 줄였는가다. “알아서”, “적당히”, “문제 있는 것만”이라는 표현을 없앨 때는 장황한 수식어를 붙이지 말고 기준 시점·판정 조건·예외·출력 형식·확인 방법을 정한다.
OpenAI의 사용자 도움말은 필요한 배경과 구체적인 요구를 제공하고 복잡한 작업은 작은 단위로 나눌 것을 권한다. Anthropic은 원하는 출력과 제약을 명시하고, Google은 구체적인 지시와 반복 수정을 안내한다. 이는 명료한 지시를 만드는 일반 원칙이지, 지시문을 몇 자 이상 쓰면 정확도가 몇 퍼센트 오른다는 성능 보증은 아니다. [S01][S02][S03]
이전 003편에서 배운 ‘목표·자료·제약·완료 조건’이 작업 의뢰서의 네 칸이라면, 이번 007편에서는 특히 그 안의 해석이 여러 갈래로 나뉘는 단어를 찾아 검증 가능한 기준으로 바꾼다.
1. 모호한 지시문은 왜 서로 다른 정답을 만들까
“배송이 늦은 주문을 찾아주세요.” 한 문장에는 빠진 기준이 여럿 있다. 오늘이 언제인지, 예정일이 오늘인 주문도 늦은 것인지, 송장이 있으면 정상으로 볼지, 취소나 미결제 주문은 넣을지를 정하지 않았다. 직원 둘에게 같은 메모를 줘도 다른 목록이 나올 수 있다.
잘못된 표현 자체가 금지된 것은 아니다. 아이디어를 자유롭게 얻고 싶을 때는 “재미있게”, “다양하게”가 유용하다. 그러나 집계·선별·계약 조건·고객 안내처럼 결과가 외부에 영향을 미칠 수 있는 작업에서는 판단 기준을 먼저 정해야 한다. AI의 결과가 자연스러운 문장으로 보인다고 해서 누락된 기준을 자동으로 채워도 괜찮다는 뜻은 아니다.
| 일상적인 표현 | 반드시 더 물어볼 것 | 고쳐 쓴 기준의 예 |
|---|---|---|
| “최근 주문” | 최근의 시작과 끝은? | “2026-10-20부터 10-26까지의 주문” |
| “문제 주문” | 어떤 상태가 문제인가? | “결제완료이면서 예정일 이전 송장 미등록 상태”가 아니라 “예정일이 기준일보다 앞섰는데도 송장이 미등록인 주문” |
| “빨리” | 무엇을 먼저 정렬하나? | “예정일이 오래 지난 순서” |
| “친절하게 연락” | 알릴 정보와 금지 표현은? | “실제 미배송을 단정하지 않는 확인용 문안만 작성” |
| “깔끔하게” | 표·문장·길이 중 무엇인가? | “주문번호와 판정 근거를 2열 표로 작성” |
여기서 말하는 개선은 원문에 근거한 분류가 쉬워지는 방향이라는 편집부의 실무 해석이다. 모든 모델·모든 업무에서 같은 개선 폭이 실험으로 확인됐다는 뜻은 아니다.
2. 직접 해보자: 같은 주문 자료로 두 번 묻기
아래 자료는 모두 가상이다. 개인 연락처가 없고 실제 고객과 연결되지 않는다. 두 요청을 서로 다른 새 대화창에 각각 복사해 실행해 보자. 결과가 다를 수도 같을 수도 있다. 비교할 것은 문장 스타일이 아니라 분류 근거를 확인할 수 있는가다.
실습 A — 모호한 요청 (전체 복사)
[가상 주문 자료]
기록을 읽는 시점: 2026-10-26 오전 9시(한국시간)
열: 주문번호 | 배송예정일 | 결제상태 | 송장상태 | 주문상태
A01 | 2026-10-29 | 결제완료 | 미등록 | 정상
A02 | 2026-10-24 | 결제완료 | 미등록 | 정상
A03 | 2026-10-25 | 결제완료 | 등록 | 정상
A04 | 2026-10-25 | 결제완료 | 미등록 | 취소
A05 | 2026-10-26 | 결제완료 | 미등록 | 정상
A06 | 2026-10-20 | 결제대기 | 미등록 | 정상
A07 | 2026-10-22 | 결제완료 | 미등록 | 정상
[요청]
배송이 늦어 보이는 주문을 찾아서 친절하게 정리해줘.
이 요청은 틀렸다고 단정할 수 없다. 다만 어떤 행을 넣거나 뺐는지 일관되게 채점할 기준이 없다. 특히 송장 등록과 배송 완료를 동일시하거나, 취소 주문까지 고객에게 연락하자고 제안한다면 위험하다.
실습 B — 기준을 명시한 요청 (전체 복사)
[가상 주문 자료]
기록을 읽는 시점: 2026-10-26 오전 9시(한국시간)
열: 주문번호 | 배송예정일 | 결제상태 | 송장상태 | 주문상태
A01 | 2026-10-29 | 결제완료 | 미등록 | 정상
A02 | 2026-10-24 | 결제완료 | 미등록 | 정상
A03 | 2026-10-25 | 결제완료 | 등록 | 정상
A04 | 2026-10-25 | 결제완료 | 미등록 | 취소
A05 | 2026-10-26 | 결제완료 | 미등록 | 정상
A06 | 2026-10-20 | 결제대기 | 미등록 | 정상
A07 | 2026-10-22 | 결제완료 | 미등록 | 정상
[업무]
실제 발송을 하지 말고, 담당자가 배송 상태를 확인할 주문 후보를 분류해줘.
[판정 기준]
1. 기준일은 2026-10-26(한국시간). 날짜만 비교한다.
2. 배송예정일이 기준일보다 '이전'인 주문만 대상이다. 오늘 예정인 주문은 제외한다.
3. 결제상태는 '결제완료', 송장상태는 '미등록', 주문상태는 '정상'이어야 한다.
4. 네 조건을 모두 충족한 주문만 '확인 후보'로 표시한다.
5. 송장 미등록은 실제 미배송이 확인됐다는 의미가 아니다. 배송완료·분실·귀책을 추정하지 마라.
[출력]
- '확인 후보' 주문번호를 배송예정일이 오래된 순서로 표기하고, 각 행에 근거를 한 줄로 적어라.
- 후보 수를 적어라.
- 제외한 주문번호 각각에 대해 이유를 한 줄로 적어라.
- 마지막에 내부 담당자가 쓸 확인용 문안 한 문장을 작성하되, 고객에게 보냈다고 쓰지 마라.
[완료 전 자가점검]
- 입력 7건을 모두 분류했는가?
- 대상과 제외가 중복되거나 누락되지 않았는가?
- 실제 발송·배송 완료·원인 확인을 주장하지 않았는가?
표현만 늘린 게 아니다. 실습 B에는 판정에 필요한 기준이 있으며, 출력이 맞는지 주문번호 단위로 독자가 확인할 수 있다. 반대로 실습 A는 같은 원자료를 제공했지만 판단 기준을 명시하지 않아 두 결과의 비교 자체가 어렵다.
3. 실습 B의 기준 답안 — 편집부가 만든 정답
이 표는 EEJE가 원자료와 판정 조건으로 계산한 기준 답안이다. 실제 ChatGPT·Claude·Gemini를 실행해 수집한 결과가 아니다.
| 분류 | 주문번호 | 판정 이유 |
|---|---|---|
| 확인 후보 1 | A07 | 10월 22일 예정일 경과, 결제완료, 송장 미등록, 정상 주문 |
| 확인 후보 2 | A02 | 10월 24일 예정일 경과, 결제완료, 송장 미등록, 정상 주문 |
| 제외 | A01 | 배송예정일 10월 29일, 기준일 이후 |
| 제외 | A03 | 송장 상태가 ‘등록’ |
| 제외 | A04 | 주문상태 ‘취소’ |
| 제외 | A05 | 배송예정일이 기준일과 같음. ‘이전’이 아님 |
| 제외 | A06 | 결제상태 ‘결제대기’ |
후보는 2건, 제외는 5건, 총 7건이다. 우선순위가 예정일이 오래된 순서이므로 A07 → A02가 맞다. 송장 미등록은 '배송되지 않았다'의 증거가 아니다. 실제 진행 상황은 주문 관리 기록·운송사 정보·담당자 확인으로 따로 판단해야 한다.
내부 담당자에게 전달할 확인용 문장의 예시는 다음과 같다.
“A07과 A02는 예정일이 지났고 송장이 등록되지 않은 것으로 기록되어 있으니, 실제 출고·배송 상태를 확인한 뒤 고객 안내 여부를 결정해 주세요.”
틀린 답안의 전형은 A05를 지연 주문에 포함하거나, A06을 결제완료로 착각하거나, A03의 '송장 등록'을 '배송 완료'로 단정하는 것이다. 실제 모델을 시험하는 독자는 자신의 출력에서 이 세 지점을 가장 먼저 확인해 볼 수 있다.
4. 무엇이 달라졌는지 채점하는 법
아래는 EEJE 편집부가 설계한 채점 규칙이다. 특정 AI의 성능평가 결과가 아니다.
| 확인 항목 | 통과 조건 |
|---|---|
| 후보 목록 | A07과 A02만 포함 |
| 우선순위 | A07 다음 A02 |
| 누락·중복 | 대상 2건 + 제외 5건 = 전체 7건, 주문번호 중복 없음 |
| 제외 사유 | A01 미래, A03 송장 등록, A04 취소, A05 당일, A06 결제대기 |
| 사실 경계 | '배송완료', '실제 지연 확정', '고객 발송 완료'를 주장하지 않음 |
| 안전한 산출물 | 외부 발송 없이 내부 확인용 문안만 제시 |
핵심 판정은 목록과 근거의 일치 여부다. 보기 좋은 제목을 붙였는지, 문장을 길게 썼는지는 부차적이다. 예를 들어 후보 2건을 맞혀도 A05에 잘못된 사유를 붙였다면 '전체 통과'가 아니다.
실제 업무에서 반복 사용할 예정이라면 같은 테스트 자료와 채점 기준을 보존해 모델 또는 지시문을 바꾼 뒤 다시 비교해야 한다. OpenAI의 API 문서는 모델·프롬프트 변경 시 평가 자료로 확인할 것을 권하며, Anthropic의 평가 지침도 측정 가능한 성공 기준을 먼저 정하도록 안내한다. [S04][S05]
5. 더 길게 적어도 오히려 나빠질 수 있는 순간
첫째, 서로 충돌하는 규칙이 생길 때다. “오늘 예정인 주문은 빼라”와 “예정일이 오늘까지인 주문을 모두 포함하라”는 양립할 수 없다. 이때는 말을 덧붙이는 대신 기준을 하나로 수정한다.
둘째, 실제로 없는 정보를 지시문이 채우는 경우다. 원자료에 출고 여부가 없는데 “미배송 고객에게 사과하라”를 쓰면, AI가 출고 사실을 확인한 것처럼 말할 위험을 키운다. 정보가 없다면 “송장 미등록”이라고만 적고 출고 여부는 확인 대상으로 남긴다.
셋째, 필요 없는 제약으로 좋은 대안을 막을 때다. 창의적인 제목 제안에는 분류 업무와 같은 세세한 판정 규칙이 꼭 필요하지 않다. 먼저 자유롭게 후보를 받은 다음, 사실 오류·금지어·길이처럼 꼭 필요한 조건만 추가해도 된다.
넷째, 지시문을 바꾸고 테스트 자료도 함께 바꾸는 경우다. 모델·입력·지시문이 동시에 달라지면 무엇 때문에 결과가 바뀌었는지 확인하기 어렵다. 비교를 위해서는 최소한 같은 자료·같은 기준 답안을 유지한다.
6. 전문가를 위한 점검: 지시문의 품질을 '느낌' 대신 실패 유형으로 관리하기
실무자가 AI를 서비스에 붙일 때는 단순히 “정확한 답을 해줘”라고 요구하지 않는다. 판정 기준을 코드나 규칙표에 두고, AI는 애매한 문장 이해·예외 설명·초안 작성에 활용하는 구성을 검토할 수 있다. 위 실습의 날짜·상태 네 조건은 결정적으로 계산할 수 있으므로, 운영 환경에서는 애플리케이션 코드로 재검증하는 편이 감사와 재현에 유리하다. 이것은 EEJE의 설계 제안이며 특정 API가 자동으로 보장하는 기능은 아니다.
정확한 운영 검토를 위해서는 대상이 아닌 주문을 잘못 포함한 오탐, 대상 주문을 빠뜨린 누락, 같은 단어를 다르게 해석한 기준 불일치, 원자료에 없는 사실을 덧붙인 근거 초과, 허가 없이 외부 행동을 한 권한 초과를 분리해서 기록한다. 새로운 예외 사례가 나오면 테스트 행을 추가하고 원래 기준 답안을 임의로 고치지 않는다.
전문가에게 권하는 추가 검수는 세 가지다. (1) 경계값 — 배송예정일이 기준일과 같은 A05를 정확히 제외하는가. (2) 예외 — 취소 A04·미결제 A06을 제외하는가. (3) 사실의 수준 — 송장 상태만 보고 배송 완료 여부를 단정하지 않는가. 이 세 지점을 통과해도 고객 연락의 적법성·정책 적합성·현재 물류 상태까지 검증된 것은 아니다.
7. 오늘 바로 사용할 한 문장
업무 지시문을 쓰고 나서 이렇게 물어보자.
“이 지시를 처음 보는 다른 직원에게 주면, 똑같은 자료에서 같은 대상을 선택할 수 있을까?”
대답이 아니오라면 '더 자세하게' 쓰기 전에 서로 다르게 해석할 여지가 있는 단어 한 개부터 고치자. 길이가 아닌, 판정 가능성이 지시문의 핵심이다.
공식 출처와 확인 범위
- [S01] OpenAI Help Center, How do I create a good prompt for an AI model? — 작업·배경·원하는 표현을 구체화하고 복잡한 작업을 분할하라는 일반 사용자 지침을 확인했다. 특정 제품·모델의 정확도 향상 수치는 제공하지 않는다. https://help.openai.com/en/articles/4936848-how-do-i-create-a-good-prompt-for-an-ai-model
- [S02] Anthropic, Prompting best practices — 분명하고 직접적인 지시, 원하는 출력과 제약의 명시, 예시·문맥 활용 부분을 확인했다. Claude 모델별 적용 차이가 있으므로 일반 사용자에게 정해진 결과를 보증하지 않는다. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- [S03] Google AI for Developers, Prompt design strategies — 구체적인 지시·제약·반복적 개선을 확인했다. API 개발 문서의 구조화 출력 기능을 일반 Gemini 앱에 그대로 적용할 수 있다는 주장은 하지 않는다. https://ai.google.dev/gemini-api/docs/prompting-strategies
- [S04] OpenAI API, Prompt engineering — 프롬프트가 모델·스냅샷에 따라 다르게 작동할 수 있으며 변경 시 평가를 권장하는 문단을 확인했다. 개발자 API 문서이지 일반 ChatGPT UI에 특정 설정이 있다는 뜻은 아니다. https://developers.openai.com/api/docs/guides/prompt-engineering
- [S05] Anthropic, Define success criteria and build evaluations — 측정 가능한 성공 기준과 평가 설계를 확인했다. 실제 외부 독립 성능시험을 수행하지 않았다. https://platform.claude.com/docs/en/test-and-evaluate/develop-tests