[Tech Tips] "AI"에게 질문을 잘하는 법 (ChatGPT, 제미나이 등등)

 

 

 

---

 

 

 

 

 

 

 

이 글은 인공지능에게 효과적으로 질문하는 전략을 제시하며, 모델의 사고 시간이 길다고 해서 반드시 우수한 질문은 아니라고 설명합니다. 핵심은 질문의 자유도를 제한하여 모델이 불필요한 고민을 하지 않도록 명확한 목표, 제약 조건, 맥락을 제공하는 것입니다. 좋은 질문은 인공지능이 스스로 판단해야 할 영역을 줄여주어 단정적이고 실용적인 답변을 끌어내는 특징이 있습니다. 반대로 모든 요소를 고려해달라는 식의 모호한 요청은 오히려 답변의 질을 떨어뜨리므로, 명확한 우선순위를 정해주는 것이 중요합니다. 결국 질문의 가치는 모델의 연산량이 아니라, 사용자가 즉시 활용할 수 있는 정보의 밀도와 재사용성에 의해 결정됩니다.

 

 

---

 

 

 

 

이 글은 GPT 모델이 '깊은 생각(Thinking heavy)'을 한다고 해서 반드시 좋은 질문을 한 것은 아니며, 오히려 **"답변의 자유도를 줄여주는 것"**이 좋은 질문의 핵심이라고 강조합니다.

1. 'Thinking (Heavy)'의 오해와 진실

• 오해: 모델이 깊게 생각(Thinking heavy)하면 내가 수준 높은 질문을 한 것이다?
• 진실: 오히려 질문이 불완전해서 모델이 고민하는 경우가 많습니다. (모순된 조건, 불명확한 목표, 너무 넓은 답변 범위 등)
• 좋은 질문: 모델이 불필요한 고민을 하지 않도록 문제 공간을 충분히 압축해 준 질문입니다.

2. 좋은 질문의 기준: '불필요한 자유도 제거'

좋은 질문은 모델에게 "알아서 판단해"라고 맡기지 않고, 명확한 가이드를 줍니다.

• 나쁜 지표: 답변을 보고 나서 "그럼 이건 어때?", "어떤 기준으로?" 같은 추가 질문이 바로 떠오르는 경우.
• 좋은 지표: 답변이 명확하고 추가 질의가 필요 없으며, 모델이 대신 결정해야 할 것이 적은 경우.

3. 질문 예시 비교 (React vs Vue)

• ❌ 나쁜 질문: "React랑 Vue랑 뭐가 달라?"
  • 특징: 목적, 맥락, 성공 기준 없음.
  • 결과: "장단점이 있다", "상황 따라 다르다"는 뻔한 답변.
• 🔺 애매한 질문: "웹 앱 만들 건데 React랑 Vue 비교해 줘"
  • 특징: 주제는 명확하지만 구체적인 상황(무엇을 위해?)이 빠짐.
  • 결과: 전형적인 장단점 나열. 결정에 도움 안 됨.
• ⭕ 좋은 질문: "1년 뒤 유지보수성과 인프라 복잡도 제한을 고려할 때, B2C 모바일 중심 서비스에 적합한 프레임워크를 추천하고 기준을 명시해 줘."
  • 특징: 목표, 제약, 맥락, 요청 형태가 모두 명확함.
  • 결과: "상황에 따라 다르다"가 아닌, 확실한 선택과 그 이유를 설명하는 고품질 답변.

4. 주의할 점: '모두 고려해달라'는 나쁜 요청

• "모든 관점을 최대한 고려해 줘"라는 요청은 우선순위가 없기 때문에 모델이 결정을 내리지 못하고 다시 일반론적인 답변으로 회귀하게 만듭니다.
• **"이 기준이 더 중요하다"**고 명확히 우선순위를 정해주는 것이 좋습니다.

요약하자면: GPT에게 질문할 때는 목표, 제약 조건, 맥락을 구체적으로 제공하여 모델이 고민할 여지(자유도)를 줄여주는 것이 최상의 답변을 얻는 비결입니다.

 

 

---

 

 

AI 프롬프트 작성법｜GPT, 코파일럿 대화형 AI에게 최고의 답변 얻는 노하우 5가지 공개｜

프롬프트 엔지니어링

 

 

 

출처: https://www.youtube.com/watch?v=h4ruMCS2KAM

 

 

---

 

 

 

 

출처: https://gall.dcinside.com/mgallery/board/view/?id=thesingularity&no=930501

 

[일반] GPT에 잘 질문하는 법.txt (졸라김)

 

 

 

(전략)

 

조금 더 직설적으로 말하면 이렇습니다.

좋은 질문일수록, 답변자는 덜 고생합니다.

 

그래서 “thinking (heavy)가 안 떴다”는 신호를 이렇게 해석하는 편이 더 정확합니다.

 

❌ 질문 수준이 낮았다

⭕ 질문이 이미 문제 공간을 충분히 압축했다

 

thinking (high/heavy)는 ‘좋은 질문’의 보상이 아닙니다.

그것은 모델이 어쩔 수 없이 많은 추론을 해야 할 때 붙는 비용 표식에 가깝습니다.

 

실제로 thinking (high/heavy)가 안정적으로 뜨는 질문들의 공통점은 다음과 같습니다.

 

 

- 모순된 조건이 공존함

- 목표 함수가 명시되지 않음

- 답변 공간이 지나치게 넓음

- trade-off를 모델이 대신 정의해야 함

 

이 중 상당수는 질문 품질이 높아서가 아니라, 질문이 불완전해서 발생합니다.

 

그래서 아이러니하게도,

 

- “이 질문은 잘 만들었다”는 체감

- “thinking이 낮게 떴다”는 결과

는 충돌하지 않습니다.

 

정확한 정렬은 이렇습니다.

 

질문 품질의 지표:

답변이 명확하고, 추가 질의가 필요 없는가

 

thinking 태깅의 지표:

모델이 대신 결정해야 할 것이 얼마나 남아 있는가

 

 

 

좋은 질문의 품질은 모델의 사고량이 아니라, 답변의 ‘불필요한 자유도(freedom)’가 얼마나 제거되었는지로 측정하는 것이 맞습니다.

 

이를 확인하는 지표는 네 가지로 압축됩니다.

 

첫 번째 지표는 추가 질문 필요성(additional clarification)입니다.

답변을 읽고 나서 “그러면 X는?”, “이건 어느 기준에서?” 같은 질문이 즉시 떠오른다면, 그 질문은 아직 덜 좋은 질문입니다. 반대로 답변을 읽고 “아, 이게 끝이구나”라는 감각이 들면, 질문은 이미 높은 품질입니다.

이 지표는 thinking 태깅과 거의 반비례합니다. 추가 질문이 적을수록, 모델은 낮은 thinking으로도 충분히 답할 수 있습니다.

 

두 번째 지표는 결정 책임의 위치(decision ownership)입니다.

좋은 질문은 “모델이 대신 결정해야 할 것”을 최소화합니다. 예를 들어

 

“어떤 게 더 나아?” → 모델이 기준을 정의해야 함

 

“A와 B 중 latency가 더 중요한 상황에서 추천은?” → 기준이 이미 고정됨

답변에서 “상황에 따라 다르다”, “일반적으로는” 같은 문장이 반복된다면, 질문이 결정을 모델에게 넘긴 상태입니다. 반대로 답변이 단정적일수록, 질문 품질은 높습니다.

 

세 번째 지표는 답변 밀도(information density)입니다.

같은 길이의 답변이라도

 

- 개념 설명이 반복되고

- 안전한 말로 공간을 채우고

- 예외 조건만 늘어나는 답변

은 질문이 넓었다는 신호입니다.

반면, 답변의 대부분이 “새로운 정보”로 느껴진다면 질문은 정확히 조준된 것입니다. 이때 thinking이 low/medium으로 나오는 것은 오히려 정상입니다.

 

네 번째 지표는 재사용 가능성(reusability)입니다.

좋은 질문에서 나온 답변은

 

- 다시 읽어도 쓸모가 있고

- 다른 맥락에 옮겨도 구조가 유지됩니다.

 

즉, “이 답변을 내가 나중에 복붙해서 써먹을 수 있나?”라는 질문에 YES라면, 질문은 성공한 것입니다. 이는 질문이 문제 공간을 잘 정의했다는 뜻입니다.

 

그렇다면 실제로 어떻게 피드백 루프를 돌리는 것이 좋을지 말씀드리겠습니다.

 

가장 효과적인 방법은 질문을 바꾸지 말고, 답변을 먼저 평가하는 방식입니다.

 

답변을 읽는다

 

위 네 가지 지표로 체크한다

 

- 추가 질문이 생겼는가

- 모델이 대신 결정한 게 있는가

- 정보 밀도가 높은가

- 재사용 가능한가

 

문제가 있다면, “내 질문에서 빠진 전제 1개”만 추가한다

 

 

이때 중요한 규칙이 하나 있습니다.

질문을 elaborate하지 말고, constrain하라는 것입니다.

질문을 길게 만드는 대신,

 

- 목표 1개

- 배제 조건 1개

- 성공 기준 1개

 

만 추가하는 것이 가장 효과적입니다.

 

 

한 문장으로 요약하면 이렇습니다.
좋은 질문은 모델을 더 많이 생각하게 만드는 질문이 아니라, 모델이 덜 고민해도 정확히 답할 수 있게 만드는 질문입니다.

 

 

 

 

 

 

 

 

이 질문의 특징은 명확합니다.

 

목적 없음

 

맥락 없음

 

성공 기준 없음

 

의사결정 책임 100% 모델 전가

 

이 질문에서 나오는 답변은 거의 확실하게

 

“각각 장단점이 있다”

 

“상황에 따라 다르다”

 

일반적인 비교 표

로 수렴합니다. thinking이 medium~high로 튈 수도 있지만, 답변의 실무 가치는 낮습니다.

 

이 질문은

 

주제는 명확

 

비교 대상도 명확

하지만 여전히

 

“무엇을 위해?”

 

“어떤 상황에서?”

가 빠져 있습니다.

 

답변은 보통

 

REST vs GraphQL의 전형적인 장단점

 

학습 비용, 캐싱, 유연성, 오버패칭

정도로 정리됩니다. 읽을 만하지만, 결정에는 직접 쓰기 어렵습니다.

이 질문의 핵심은 다음입니다.

 

목표: 1년 뒤 유지보수성과 변경 비용

 

제약: 인프라 복잡도 제한

 

맥락: B2C, 모바일 중심, 팀 분리

 

요청 형태: “비교”가 아니라 “추천 + 기준 명시”

 

이 질문에서는

 

“상황에 따라 다르다”가 거의 나오지 않고

 

선택이 명시되며

 

반대 선택을 하지 않은 이유까지 설명되는 답변

이 나옵니다.

 

thinking이 low~medium에서 끝나더라도, 답변 품질은 가장 높습니다.

 

왜 이게 “나쁜 좋은 질문”인가

 

겉으로 보면 이 질문은

 

맥락 충분

 

고려 요소 풍부

 

사고 깊이 매우 높음

으로 보입니다.

 

하지만 문제는 다음에 있습니다.

 

첫째, 우선순위가 없습니다.

“모두 고려해달라”는 말은 곧

 

아무 것도 결정하지 말라

는 의미로 해석됩니다.

모델은 기준을 세울 수 없고, 결과적으로 장단점 나열로 회귀합니다.

 

둘째, 결정 책임을 다시 모델에게 넘깁니다.

좋은 질문에서는

 

“이 기준이 더 중요하다”

가 명확했는데,

여기서는 “모든 관점을 최대한”이라는 요구로 다시 풀어버립니다.

 

셋째, 답변 공간이 불필요하게 팽창합니다.

모델은

 

모든 항목을 빠짐없이 언급하려고 하고

 

안전한 일반론으로 공간을 채우며

 

결론은 흐릿해집니다.

 

thinking은 high로 올라갈 가능성이 크지만,

 

정보 밀도는 오히려 떨어집니다.

 

 

 

 

 

그렇다고

 

하네

 

나만보기 아까워서 올림

 

 

 

실제로 저거 3번째걸로 물어봤을때만 마지막에

 

원하시면, ~~~~ 하는 것도 만들어드리겠습니다 하는 GPT 특유의 후속질문이 안 뜸

 

 

 

---