AI 질문은 Angle·Cut·Number로 달라진다

AI에게 질문을 던졌는데 답이 길기만 하고 손에 잡히지 않을 때가 있다. 문장은 자연스럽고 항목도 많다. 그런데 막상 업무에 붙이려 하면 어디부터 해야 할지 모르겠다. 이럴 때 모델을 탓하기 전에 질문 구조를 봐야 한다.

좋은 LLM 질문은 예쁜 문장이 아니다. AI가 어떤 관점에서, 어떤 기준으로, 어떤 형태의 답을 내야 하는지 미리 정해 주는 일이다. "AI 활용 전략 알려줘" 같은 질문은 넓다. 넓은 질문은 넓은 답을 부른다. 넓은 답은 읽을 때는 그럴듯하지만 실행 단계에서 힘이 빠진다.

내가 쓰는 기준은 세 단어다. Angle, Cut, Number. 관점을 고정하고, 문제를 자르는 절단면을 정하고, 판단 기준을 숫자로 박아 둔다. 이 세 가지가 들어가면 AI는 설명을 늘어놓는 쪽에서 의사결정을 돕는 쪽으로 움직인다.

모델이 똑똑하면 질문도 해결된다는 착각

새 모델이 나오면 질문을 대충 던져도 알아서 잘해 줄 것 같은 기대가 생긴다. 어느 정도는 맞다. 최신 모델은 문맥을 잘 읽고, 빠진 조건도 일부 보완한다. 하지만 그것은 평균적인 보완이다. 내가 원하는 업무 맥락, 조직 제약, 판단 기준까지 정확히 알지는 못한다.

예를 들어 "사내 AI 도입 방안 알려줘"라고 묻는다고 하자. AI는 교육, 보안, 업무 자동화, 파일 정리, 챗봇, 회의록, 윤리 같은 항목을 넓게 꺼낼 가능성이 높다. 틀린 답은 아니다. 다만 팀장에게 보고할 1페이지 메모로 바로 쓰기는 어렵다. 중심축이 없기 때문이다.

질문이 약할 때 나타나는 신호는 비슷하다. 답변이 길다. 항목은 많다. 우선순위가 흐리다. 좋은 말은 많은데 다음 행동이 없다. 이런 답은 정보 부족보다 구조 부족에서 온다. AI가 몰라서 못 쓰는 게 아니라, 무엇을 기준으로 답해야 하는지 덜 받았기 때문이다.

Angle: 누구의 관점에서 볼지 고정한다

Angle은 관점이다. 같은 주제라도 누구의 눈으로 보느냐에 따라 답이 달라진다. 대표 입장인지, 팀장 입장인지, 실무자 입장인지, 보안 담당자 입장인지 먼저 고정해야 한다. 관점이 없으면 AI는 모두에게 무난한 답을 낸다. 모두에게 무난한 답은 대개 누구에게도 충분히 날카롭지 않다.

"AI 도입 전략"을 묻는 대신 "중견기업 운영팀장의 관점에서, 인력 충원 없이 반복 업무를 줄이는 AI 도입안을 제안해 줘"라고 쓰면 답의 방향이 달라진다. 생산성이라는 큰 단어도 운영팀장의 업무, 인력 제약, 반복 업무라는 조건 속으로 들어간다.

관점은 역할만 뜻하지 않는다. 무엇을 우선할지도 포함한다. 비용 절감인지, 품질 안정인지, 의사결정 속도인지, 고객 응대 품질인지에 따라 같은 도구도 전혀 다르게 평가된다. 그래서 질문의 첫 줄에는 "나는 무엇을 가장 중요하게 볼 것인가"가 들어가야 한다.

Cut: 문제를 어디서 자를지 정한다

Cut은 절단면이다. 문제를 어떻게 나눌지 정하는 일이다. 이 단계가 없으면 AI는 흔한 목차를 만든다. 기능, 디자인, 마케팅, 운영처럼 부서 이름으로 나누거나, 장점과 단점처럼 평범한 틀로 정리한다. 보기에는 깔끔하지만 원인을 찾거나 선택을 내리기에는 약할 수 있다.

예를 들어 서비스 성장이 막혔다면 "기능, 디자인, 마케팅"보다 "획득, 활성, 유지"로 자르는 편이 더 쓸모 있을 때가 많다. 사용자가 들어오지 않는지, 들어와도 첫 행동을 못 하는지, 한 번 쓰고 떠나는지 구분되기 때문이다. 같은 문제도 절단면을 바꾸면 AI가 볼 수 있는 병목이 달라진다.

비용 절감도 비슷하다. "인건비, 재료비, 광고비"로 묻는 것보다 "고정비와 변동비로 나눠, 고객 경험을 해치지 않는 감축안을 찾아줘"라고 묻는 편이 더 직접적이다. 절단면은 분류표가 아니다. 행동 방식을 다르게 만드는 기준이다.

좋은 Cut은 두 가지를 만족한다. 서로 겹치지 않아야 하고, 빠진 영역이 적어야 한다. 그리고 더 중요한 조건이 하나 있다. 핵심이 드러나야 한다. 항목이 예쁘게 나뉘어도 의사결정에 도움을 주지 못하면 좋은 구조가 아니다.

Number: 판단 기준을 숫자로 박아 둔다

Angle과 Cut이 들어가도 답변은 아직 느슨할 수 있다. "빠르게", "효율적으로", "적절히" 같은 말이 남기 때문이다. Number는 이 느슨함을 줄이는 장치다. 기간, 목표치, 예산, 인원, 우선순위 개수처럼 판단 기준을 숫자로 고정한다.

"신규 사용자를 늘리는 방법"과 "3개월 안에 신규 가입을 20% 늘리되 광고비는 월 100만 원 안으로 제한하는 방법"은 완전히 다른 질문이다. 후자는 AI가 효과 크기와 제약을 같이 봐야 한다. 무엇을 먼저 할지, 무엇을 버릴지, 어느 지점에서 실패로 볼지도 더 분명해진다.

숫자는 정답을 보장하지 않는다. 그래도 답변의 검증 가능성을 높인다. 숫자가 없는 질문은 마음에 드는 문장을 고르기 쉽다. 숫자가 있는 질문은 조건을 만족했는지 따져 볼 수 있다. LLM 답변을 업무에 쓰려면 이 차이가 중요하다.

바로 쓰는 질문 템플릿

아래 문장을 복사해 빈칸만 바꿔도 질문 품질이 올라간다.

내 목표는 [목표]다.
독자는 [대상]이고, 결과물은 [형식]으로 필요하다.
관점은 [Angle]로 고정한다.
문제는 [Cut] 기준으로 나눠서 봐라.
제약은 [예산/기간/인원/권한]이다.
성공 기준은 [Number]다.
먼저 가정을 3개만 적고, 그다음 우선순위 순서로 답해라.

예시는 이렇게 바뀐다.

내 목표는 고객 문의 처리 시간을 줄이는 것이다.
독자는 5명 규모 고객지원팀의 팀장이고, 결과물은 1페이지 실행 메모로 필요하다.
관점은 고객 경험보다 응답 품질 안정으로 고정한다.
문제는 문의 유입, 분류, 답변 초안, 검수, 후속 처리 기준으로 나눠서 봐라.
제약은 새 인력 채용 없음, 유료 도구 월 30만 원 이하, 개인정보 외부 전송 금지다.
성공 기준은 8주 안에 1차 응답 시간을 30% 줄이는 것이다.
먼저 가정을 3개만 적고, 그다음 우선순위 순서로 답해라.

이 정도로 묻는다고 AI가 항상 맞는 답을 내는 것은 아니다. 대신 틀렸을 때 고치기 쉬워진다. 관점이 틀렸는지, 절단면이 틀렸는지, 숫자가 비현실적인지 분리해서 볼 수 있다. 질문을 고칠 수 있다는 것은 답변을 운영할 수 있다는 뜻이다.

답변이 흐릴 때 점검할 것

AI 답변이 마음에 들지 않으면 프롬프트를 길게 꾸미기 전에 아래 항목부터 확인한다.

점검 항목	좋은 질문의 기준	흐린 답변의 신호
Angle	누구의 관점과 우선순위인지 보인다	모두에게 맞는 일반론이 나온다
Cut	문제가 행동 가능한 기준으로 나뉜다	목차는 깔끔한데 선택이 안 된다
Number	기간, 목표치, 예산, 개수가 있다	"빠르게", "효율적으로" 같은 말이 많다
형식	메모, 표, 체크리스트처럼 결과물 모양이 정해져 있다	읽기는 좋은데 붙여 넣을 곳이 없다
가정	AI가 먼저 가정을 밝힌다	숨은 전제가 틀렸는데 끝까지 이어진다

LLM을 잘 쓰는 사람은 질문을 길게 쓰는 사람이 아니다. AI가 추측하면 안 되는 곳을 먼저 막는 사람이다. 관점, 절단면, 숫자가 들어가면 AI는 덜 떠돌고 더 좁게 움직인다. 그 좁아진 답변이 실무에서는 더 쓸모 있다.

비슷한 방식으로 여러 AI 도구의 답을 검증하는 법은 AI 코드 검증 워크플로 글에도 정리했다. 질문을 잘 만드는 것과 답을 검증하는 것은 같은 선 위에 있다. 입력 조건이 선명해야 출력도 비교할 수 있다.

다음에 AI에게 묻기 전, 한 줄만 먼저 쓴다. "누구의 관점에서, 무엇을 기준으로, 어느 숫자를 만족해야 하는가." 이 질문에 답하지 못하면 아직 AI에게 물을 차례가 아니다. 먼저 문제를 좁혀야 한다.

흐린 질문을 5분 안에 고치는 순서

실제 업무에서는 처음부터 완벽한 질문을 쓰기보다, 이미 받은 흐린 답을 보고 질문을 역으로 고치는 편이 빠르다. 먼저 답변에서 당장 실행할 수 없는 문장 하나를 고른다. 예를 들어 "고객 응대를 효율화하라"는 문장을 골랐다면, 그 문장이 왜 실행되지 않는지 표시한다. 누가 결정하는지 없으면 Angle 문제, 응대 과정의 어느 지점인지 없으면 Cut 문제, 언제까지 어느 수준으로 바꿀지 없으면 Number 문제다. 세 요소를 한꺼번에 다시 쓰기 전에 비어 있는 칸부터 찾는 것이 핵심이다.

1. 출력물을 먼저 고정한다. 보고서인지 실행 메모인지, 표인지 체크리스트인지 한 가지를 정한다. 결과물 모양이 없으면 같은 내용도 끝없이 설명문으로 늘어난다.
2. 결정권자를 한 명으로 좁힌다. "회사 관점"처럼 넓게 쓰지 말고, 실제로 이 답을 읽고 선택할 사람의 역할과 우선순위를 적는다.
3. 행동이 달라지는 절단면을 고른다. 항목 이름만 달라지고 대책이 같다면 Cut이 아니다. 각 칸에서 서로 다른 다음 행동이 나오는지 확인한다.
4. 확정된 수치와 목표 수치를 구분한다. 예산·인원·마감처럼 이미 정해진 값은 제약으로 적고, 달성하고 싶은 값은 성공 기준으로 따로 적는다.
5. 모르는 값은 빈칸으로 숨기지 않는다. "현재 기준값은 제공되지 않았으므로 필요한 측정 항목부터 제안하라"고 써서 AI가 숫자를 지어내지 못하게 한다.
6. 가정을 먼저 출력시킨다. 답변 본문 전에 가정 세 개만 쓰게 한 뒤, 틀린 가정이 있으면 본문을 읽기 전에 질문을 수정한다.

여기서 Number를 넣는다는 말은 아무 숫자나 붙이라는 뜻이 아니다. 현재 처리 시간이 몇 분인지 모르는 상태에서 "30% 단축"을 적으면 문장은 구체적으로 보이지만 검증 기준은 오히려 비어 있다. 이때는 목표치를 꾸미지 말고, 먼저 현재 1차 응답 시간과 문의량을 확인해야 한다고 명시하는 편이 낫다. 확인된 숫자, 조직이 정한 목표, 아직 모르는 값을 세 칸으로 나누면 사실과 희망이 섞이지 않는다.

답변에서 보이는 증상	먼저 고칠 칸	다시 물을 때 넣을 조건
여러 부서에 모두 맞는 말만 나온다	Angle	결정권자의 역할과 가장 중요한 우선순위
항목마다 제안이 거의 같다	Cut	각 구간에서 다른 행동이 나오는 분류 기준
"빠르게"와 "적절히"가 반복된다	Number	확정된 마감·예산·인원 또는 먼저 측정할 값
내용은 맞지만 붙여 넣을 곳이 없다	형식	1페이지 메모, 비교표, 실행 체크리스트 중 하나
전제가 틀린 채 결론까지 이어진다	가정	본문보다 먼저 가정을 제한된 개수로 표시

수정 전후를 비교할 때는 문장이 더 그럴듯해졌는지가 아니라 선택이 가능해졌는지를 본다. 답변을 읽은 사람이 첫 행동을 고를 수 있는지, 제약을 넘은 제안을 버릴 수 있는지, 실패 여부를 같은 기준으로 판정할 수 있는지가 기준이다. 셋 중 하나라도 안 되면 프롬프트를 더 길게 붙이지 말고 해당 칸만 다시 고친다. Angle, Cut, Number는 장식용 공식이 아니라 어디가 틀렸는지 분리해서 재수정하기 위한 진단표다.

이 방식에도 한계는 있다. 입력 자료가 틀렸거나 필요한 사실이 빠졌다면 질문 구조만으로 정답을 만들 수 없다. 또한 숫자를 고정하면 비교는 쉬워지지만, 그 숫자 자체가 현실적인지는 별도로 확인해야 한다. 그러므로 최종 답변에는 "제공된 사실", "AI가 둔 가정", "추가 확인이 필요한 값"을 나눠 달라고 요구하는 것이 좋다. 구조가 선명한 질문은 사실 검증을 대신하지 않는다. 대신 어디부터 검증해야 하는지를 보이게 만든다.

위 고객지원 예시를 검수한다면 답변의 제안 수보다 조건 위반부터 지운다. 개인정보를 외부로 보내야 하는 제안은 제외하고, 월 30만 원을 넘는 도구는 제외하며, 새 인력을 전제로 한 방안도 제외한다. 남은 제안은 문의 유입·분류·답변 초안·검수·후속 처리 중 어디를 바꾸는지 표시한다. 어느 단계에도 연결되지 않으면 Cut에 맞지 않는 제안이다. 마지막으로 8주 뒤 1차 응답 시간을 비교하려면 시작 전 기준값을 어떻게 남길지 확인한다. 현재 시간이 제공되지 않았다면 AI에게 효과 수치를 추정시키지 말고, 측정 시작 시점과 기록할 항목을 먼저 제안하게 한다. 이렇게 하면 제약을 지킨 선택지와 추가 측정이 필요한 선택지가 섞이지 않는다.

두 번째 질문에서는 전체 프롬프트를 다시 꾸미지 않는다. 예산을 넘은 답만 나왔다면 Number의 예산 조건과 제외 규칙을 더 선명하게 쓰고, 단계별 제안이 겹쳤다면 Cut만 바꾼다. 무엇을 수정했는지 한 요소로 제한해야 다음 답변이 달라진 이유도 추적할 수 있다. 세 요소를 매번 동시에 바꾸면 답이 나아져도 어느 조건이 효과가 있었는지 알기 어렵다.

자주 묻는 질문

Angle에는 역할만 적으면 충분한가?

역할만 적으면 부족하다. 대표·팀장·실무자처럼 누구의 눈으로 볼지와 함께 비용 절감, 품질 안정, 의사결정 속도처럼 무엇을 우선할지도 첫 줄에 고정해야 답이 무난한 일반론으로 흐르지 않는다.

좋은 Cut인지 무엇으로 판단하나?

서로 겹치지 않고 빠진 영역이 적어야 하며, 무엇보다 핵심 병목과 행동 차이가 드러나야 한다. 기능·디자인처럼 보기 좋은 분류라도 선택이나 원인 파악에 도움이 안 되면 좋은 Cut이 아니다.

Number를 넣으면 답이 항상 맞아지나?

아니다. 숫자는 정답을 보장하지 않지만 기간·목표치·예산·인원 같은 제약을 고정해 조건 충족 여부를 확인하게 한다. 답이 틀렸을 때도 숫자가 비현실적인지 따로 고치기 쉬워진다.