명확성과 구체성: '애매함' 제거 기술

프롬프트가 실패하는 가장 흔한 이유는 '정보 부족'이 아니라 해석 여지가 남아 있기 때문입니다. 모델은 빈칸을 싫어합니다. 당신이 비워 둔 기준과 범위를, 모델이 대신 채웁니다. 그 결과가 당신의 기대와 다르면 우리는 "AI가 똑똑하지 않다"고 말하지만, 사실은 "요청이 작업 명세가 아니었다"에 가깝습니다.

이 장의 목표는 한 문장짜리 감상평—"더 좋게 해줘", "깔끔하게", "충분히 자세히"—를 측정 가능한 요구로 바꾸는 훈련을 하는 것입니다. 특히 범위, 대상, 기준, 길이 네 축을 고정하는 문장 패턴을 익히면, 같은 모델로도 결과가 안정됩니다.

애매함이 생기는 순간 3가지

애매함은 주로 아래 세 순간에 생깁니다.

• 목표가 '방향'만 있고 '도착점'이 없는 경우: "개선해줘", "매력적으로", "설득력 있게"처럼 방향만 말하면, 모델은 무엇을 개선해야 하는지(논리, 문장, 톤, 근거, 구성)를 스스로 추측합니다.

• 대상(독자/사용자)이 불분명한 경우: 같은 내용이라도 초보자용 설명과 실무자용 문서는 어휘, 예시, 생략 가능 범위가 달라집니다. 대상이 없으면 모델은 평균적인 독자를 가정합니다.

• 성공 기준이 테스트 불가능한 경우: "빠르게", "쉽게", "효율적으로" 같은 단어는 멋있지만 검증이 어렵습니다. 요구는 가능하면 테스트 가능한 문장이어야 한다는 원칙이 여기서 나옵니다.¹

이제부터는 애매함을 '나쁜 요청'으로 취급하지 않고, 번역 대상으로 취급하겠습니다. 감정/평가 언어를 요구사항 언어로 옮기는 연습입니다.

"더 좋게 해줘"를 번역하는 4가지 고정축

"더 좋게"는 대개 네 가지 중 하나를 의미합니다.

첫째, 범위입니다. 어디까지 바꾸고 어디는 건드리지 말아야 하는지의 문제입니다.

둘째, 대상입니다. 누구를 설득해야 하는지, 누가 읽어야 하는지의 문제입니다.

셋째, 기준입니다. 무엇을 '좋음'으로 판단할지의 문제입니다. 수치, 조건, 예/아니오로 검증되는 형태가 좋습니다.¹

넷째, 길이입니다. 상세함의 정도를 통제하는 가장 쉬운 손잡이입니다.

이 네 축은 다음 한 문장으로 기억해도 됩니다.

"무엇을(범위) 누구에게(대상) 어떤 기준으로(기준) 어느 정도로(길이) 만들지"를 말하면, 애매함이 급격히 줄어든다.

애매한 표현을 '요구'로 바꾸는 문장 패턴

아래 패턴은 "요청 → 명세"로 바꾸는 데 자주 쓰입니다. 한 번에 완벽한 문장을 만들려고 하지 말고, 빈칸 채우기처럼 쓰면 됩니다.

1) 목적부터 고정하는 패턴: "왜 필요한가?"

요청의 시작을 '산출물'이 아니라 '이유'로 두면, 모델이 선택해야 하는 순간에 기준이 생깁니다. 애매한 요구를 다룰 때 Why로 시작하라는 조언은 요구사항을 명확히 할 때 반복해서 등장합니다.²

• 원문 요청: "요약해줘."

• 번역: "의사결정자가 30초 안에 쟁점을 파악할 수 있게 요약해줘. (목적)"

목적이 들어가면 '어떤 내용이 중요하냐'가 정렬됩니다. 요약 길이나 형식보다 먼저, 요약이 해결해야 할 문제를 고정하는 게 순서입니다.

2) 대상을 고정하는 패턴: "누가 쓰는가?"

대상은 전문가 수준뿐 아니라, 관심사와 의사결정 권한도 포함합니다. 요구사항을 명확히 할 때 이해관계자를 확인하라는 흐름은 실무에서도 기본입니다.²

• 원문 요청: "이 문서 좀 다듬어줘."

• 번역: "인사팀 팀장(비전공자)이 읽을 문서야. 오해가 생길 표현을 줄이고, 용어는 쉬운 말로 바꿔줘. (대상)"

3) 범위를 고정하는 패턴: "포함/제외를 한 번에 말하기"

범위는 '해야 할 것'만큼이나 '하지 말아야 할 것'이 중요합니다. 특히 모델은 친절하게 덧붙이는 경향이 있어, 제외를 안 쓰면 과잉 생성이 잦습니다.

• 원문 요청: "기획안 더 탄탄하게 해줘."

• 번역: "문제정의와 가설은 강화해줘. 대신 기술 스택/구현 방식 추측은 하지 마. (범위)"

4) 기준을 고정하는 패턴: "테스트 문장으로 바꾸기"

'좋다/깔끔하다/쉽다' 같은 평가는 검증이 어렵습니다. 요구는 테스트 가능해야 하고, 모호한 부사를 피하고, 클릭 수나 시간 같은 측정 기준으로 바꾸면 명확해집니다.¹

• 원문 요청: "사용자가 쉽게 주문을 추가할 수 있게 해줘."

• 번역: "사용자가 주문을 5번 클릭 이내로 추가할 수 있게 설명/설계를 써줘. (기준)"

문장 자체에서 애매함을 만드는 표현 제거하기

프롬프트가 길어도 결과가 흔들릴 때가 있습니다. 그때는 '정보'가 아니라 문장 구조가 원인일 때가 많습니다. 아래 규칙은 요구사항 글쓰기에서 애매함을 줄이기 위한 고전적인 습관들인데, 프롬프트에도 그대로 적용됩니다.¹

누가 하는지 주어를 숨기지 않는다(능동태)

"보고서가 생성되고 결과가 표시된다"처럼 주어가 없으면, 누가 자동으로 하는지(시스템) 사용자가 하는지(수동)가 갈립니다. 주체를 적으면 해석이 줄어듭니다.¹

"이것/그것/그들" 같은 대명사를 아낀다

대명사는 문서 전체를 보고 있을 때는 덜 문제지만, AI는 문장을 조각으로 처리하며 "it"의 대상이 흔들리기 쉽습니다. 무엇을 가리키는지 명사로 반복해서 쓰는 편이 안전합니다.¹

should/would, "가능하면/적절히/필요 시" 같은 회피 문구를 줄인다

요구를 '선택 사항'처럼 만드는 표현은 결과를 불안정하게 만듭니다. INCOSE 가이드 기반 체크 항목은 "about, some, efficient, appropriate" 같은 모호어와 "to the extent practical, where possible" 같은 회피 문구가 애매함을 만든다고 정리합니다.³

숫자에는 단위를 붙이고, 시간 표현은 경계를 만든다

"빨리", "곧", "나중에"는 해석이 갈립니다. "10초 이내", "영업일 기준 2일"처럼 경계를 만들면 테스트가 쉬워집니다.¹³

애매함을 없애는 대화 루프: 질문 → 구조화 → 검증

실무에서 애매한 요구를 다루는 방식은 의외로 단순합니다. 왜(목적)를 묻고, 관련자를 확인하고, 선호/요구를 구체화한 뒤, 구조화해서 '이게 맞냐'고 검증합니다.²

프롬프트에서도 같은 루프가 통합니다. 특히 1회성 요청이 아니라, 대화를 통해 프롬프트를 다듬을 때 아래 2문장은 효과가 좋습니다.

첫 문장은 모델에게 요약을 시키는 문장입니다.

"내 요청을 한 문장 요구사항으로 다시 써줘. (범위/대상/기준/길이를 포함해서)"

둘째 문장은 부족한 정보를 질문으로 바꾸게 하는 문장입니다.

"애매한 부분이 있으면, 필수 확인 질문 3개만 먼저 해줘. 답이 없으면 합리적 가정을 적고 진행해줘."

이 루프의 핵심은 질문을 많이 하는 것이 아니라, 애매함을 제거하는 데 필요한 최소 질문만 남기는 것입니다.

변환 예시: 모호한 요청을 측정 가능한 요구로

아래는 실전에서 자주 나오는 "더 좋게" 요청을 네 축으로 번역한 예시입니다.

여기서 중요한 건 '정답'이 아니라, 검토 가능한 형태로 바뀌었다는 점입니다. 이제 결과물을 보고 "문단 4개인가?", "지표가 있는가?" 같은 방식으로 빠르게 판단할 수 있습니다.

셀프 점검 체크리스트(프롬프트를 보내기 전 30초)

아래 질문에 '예'가 많을수록 애매함이 줄어든 상태입니다.

• 누가 읽거나 사용할 결과물인지 적었는가?

• 왜 필요한지(의사결정/행동/설득 목적)가 한 문장으로 있는가?

• 포함해야 할 것과 제외해야 할 것이 분리되어 있는가?

• "빠르게/쉽게/적절히/가능하면" 같은 표현을 수치·조건으로 바꿨는가?

• 숫자를 썼다면 단위를 붙였는가?

• 대명사(이것/그것/it)가 무엇을 가리키는지 명확한가?

• 길이(문장 수/글자 수/분량 범위)를 지정했는가?

• 결과를 보고 합격/불합격을 판단할 기준(체크 항목)이 있는가?

훈련: '모호 → 명세' 5분 워크아웃

아래 문장을 보고, 각 문장을 범위·대상·기준·길이가 들어가게 다시 써보세요. 정답은 하나가 아닙니다. 중요한 건 "검토 가능한 문장"이 되는 것입니다.

문제 1

"이메일 문구 좀 더 설득력 있게."

문제 2

"회의록 요약해줘."

문제 3

"랜딩페이지 카피 개선해줘."

문제 4

"보고서를 더 깔끔하게 정리해줘."

문제 5

"온보딩 가이드를 더 친절하게 써줘."

다시 쓸 때는 아래 빈칸 템플릿을 사용하면 쉽습니다.

대상: (누가 읽나)
범위: (무엇을 포함/제외하나)
기준: (성공을 어떻게 판정하나—수치/조건/체크 항목)
길이: (분량 범위—문장 수/글자 수/항목 수)

이 템플릿으로 한 번만 제대로 번역해두면, 다음부터 "더 좋게"라는 말이 나왔을 때도 당황하지 않습니다. 그 말은 '감각'이 아니라 '요구사항 네 축 중 하나가 비어 있다'는 신호가 됩니다.

참고

¹Eliminating Ambiguity from Your Requirements

²How to Handle Ambiguous Requirements as a Business Analyst – The Meta Business Analyst

³How to Ensure Requirements Are Clear and Unambiguous