ChatGPT의 동조를 넘어서는 비판적 질문법과 의사결정 점검

AI가 내 계획을 칭찬한다고 해서 그 계획이 검증된 것은 아닙니다. 생성형 AI의 답변은 질문에 제시한 전제와 표현 방식에 영향을 받습니다. 내가 장점만 설명하면 장점을 중심으로 답하고, 특정 결론을 강하게 요구하면 그 결론을 뒷받침하는 문장을 만들 수 있습니다. 업무에서 AI를 쓰려면 격려와 근거 검증을 구분하는 질문이 필요합니다.

이 글에서 말하는 비판적 질문법은 AI에게 무례한 말투나 공격적인 성격을 부여하는 기술이 아닙니다. 계획의 가정, 빠진 정보, 반대 근거, 대안과 실패 조건을 따로 확인하는 작업 방식입니다. 프롬프트 하나로 편향을 완전히 없애거나 AI를 전문가로 바꾸는 것은 불가능하며, 최종 결정은 검증 가능한 자료와 사람의 판단을 바탕으로 내려야 합니다.

왜 동의하는 답변을 경계해야 할까

AI의 유창한 문장은 확신을 주지만, 문장의 자연스러움과 사실의 정확성은 서로 다른 속성입니다. 질문에 잘 맞는 답을 만들려는 과정에서 사용자의 판단을 과도하게 긍정하거나 불확실성을 충분히 드러내지 않을 수 있습니다. 모델과 설정에 따라 정도가 다르므로, 모든 AI가 언제나 아첨한다고 일반화하기보다 실제 결과를 점검하는 편이 정확합니다.

사람도 자신이 믿는 내용에 맞는 정보를 더 쉽게 받아들이는 경향이 있습니다. 이미 정한 방향을 AI에게 설명한 뒤 승인받는 흐름은 이런 확증 편향을 강화할 수 있습니다. '이 계획이 왜 좋은지 써 줘'라는 요청만 반복하면, 처음 계획에서 빠진 조건을 발견하기 어렵습니다. 반대 근거를 묻는 단계와 사실 확인 단계를 별도로 두는 이유입니다.

또 다른 문제는 기존 결정에 투입한 시간과 비용입니다. 프로젝트를 오래 진행했을수록 중단이나 축소를 생각하기 어렵지만, 이미 들어간 비용과 앞으로 들어갈 비용을 구분해야 합니다. AI에게 과거의 노력을 평가해 달라고 하기보다, 현재 시점에서 선택할 수 있는 대안과 추가 비용을 비교해 달라고 요청하는 편이 유용합니다.

비판적인 말투도 검증의 증거가 되지는 않습니다. '냉정하게 지적해 줘'라는 지시를 받은 AI는 근거 없이 약점을 늘어놓을 수 있습니다. 지나치게 긍정적인 답변과 지나치게 부정적인 답변은 모두 같은 방식으로 검토해야 합니다. 각 주장에 근거를 붙이고, 근거가 없으면 가정으로 표시하게 하세요.

질문을 네 단계로 나누기

1. 사실·가정·목표를 분리한다

먼저 확정된 사실과 내가 추정한 조건, 달성하려는 목표를 별도 항목으로 정리합니다. 매출 자료나 사용자 조사처럼 실제 데이터가 있는 부분은 기간과 출처를 적습니다. 목표 수익이나 예상 반응처럼 아직 실현되지 않은 것은 가정으로 표시합니다. AI가 이 셋을 한데 섞어 말하지 않도록 요청합니다.

사용할 수 있는 질문은 다음과 같습니다. '아래 계획에서 확인된 사실, 검증되지 않은 가정, 가치 판단을 나누어 주세요. 입력에 없는 정보를 채워 넣지 말고, 판단에 필요한 추가 자료를 질문으로 정리해 주세요.' 이 요청은 분석의 출발점을 정돈하는 데 도움이 되지만, 분류 자체도 사람이 확인해야 합니다.

2. 결론을 뒤집을 근거를 찾는다

좋은 검토는 무조건 반대하는 것이 아니라 결론이 바뀌는 조건을 드러냅니다. '실패할 수 있는 이유를 써 줘'에서 한 걸음 더 나아가 '어떤 데이터가 관찰되면 이 계획을 축소하거나 중단해야 하는지'를 물어보세요. 반대 의견도 확인 가능한 지표와 연결해야 실무에 활용할 수 있습니다.

예를 들어 신규 서비스 출시를 검토한다면 사용자 관심, 실제 결제 의사, 운영 비용, 지원 부담을 따로 확인합니다. 긍정적인 인터뷰 몇 건만으로 수요가 충분하다고 판단하지 않습니다. AI는 빠진 항목을 제안하는 데 쓸 수 있지만, 고객 반응을 직접 측정한 것처럼 성과 수치를 만들어서는 안 됩니다.

3. 유지·개선·축소·중단을 비교한다

선택지를 '계속한다'와 '그만둔다' 두 가지로만 제한하면 중간 대안을 놓치기 쉽습니다. 범위를 줄이거나 특정 고객군에만 시험하거나 일정과 인력 배분을 바꾸는 방법도 있습니다. 각 대안의 장점, 손해, 실행 조건, 되돌릴 수 있는 정도를 같은 기준으로 비교합니다.

질문 예시는 '현재 방식을 유지하는 안, 범위를 축소하는 안, 핵심 절차를 개선하는 안을 동일한 기간과 자원 조건에서 비교해 주세요. 비용을 임의로 추정하지 말고 계산에 필요한 변수를 먼저 제시해 주세요'입니다. 이렇게 하면 그럴듯한 결론보다 필요한 자료를 먼저 얻을 수 있습니다.

4. 검증과 최종 결정을 분리한다

AI가 제안한 숫자와 인용, 사례는 원자료를 확인해야 합니다. 확인되지 않는 인물의 성공담이나 구체적인 매출 증가율을 그대로 보고서에 옮기지 않습니다. 조직의 승인 기준, 계약 조건, 고객 관계와 관련된 판단은 담당자가 검토하고 결정합니다. AI 출력은 검토 자료이지 결정의 책임을 대신하는 주체가 아닙니다.

사전 실패 분석을 실무에 적용하기

사전 실패 분석은 프로젝트가 이미 실패했다고 가정하고 가능한 원인을 찾아보는 방법입니다. '출시 후 기대한 결과가 나오지 않았다면 어떤 원인이 있을까'라는 질문으로 낙관적인 계획에서 빠진 조건을 확인합니다. 상상한 실패 원인은 실제 사건이 아니므로 가정이라고 표시해야 합니다.

처음에는 원인을 자유롭게 나열하되, 다음 단계에서 발생 가능성과 영향을 구분합니다. 그 후 실제로 점검할 수 있는 신호와 대응 담당자를 정합니다. '고객이 싫어할 수 있다'처럼 넓은 문장보다 '사용자가 첫 설정 단계에서 중단하는지 확인한다'처럼 관찰 가능한 조건이 유용합니다.

가장 중요한 것은 위험 목록의 길이가 아니라 후속 행동입니다. 조사할 항목, 시험할 범위, 확인할 날짜, 판단할 사람이 정해지지 않으면 실패 분석도 문서 작업으로 끝납니다. 중요한 가정 두세 가지를 골라 작은 실험으로 검증하고, 결과에 따라 계획을 바꾸는 흐름을 마련하세요.

직무별 활용 예시

다음 예시는 질문 설계를 설명하기 위한 가상 상황입니다. 실제 기업의 성과 사례나 검증된 개선 수치를 의미하지 않습니다. 자신의 업무 조건에 맞춰 수정하고 민감한 정보는 조직이 승인한 환경에서만 다루세요.

프리랜서와 소규모 사업자: 수임 조건을 점검한다

작업량에 비해 수정 요청이 많고 일정이 자주 바뀌는 프로젝트가 있다고 가정합니다. AI에게 '이 고객을 끊어야 하나'라고 묻기보다, 계약 범위와 추가 작업, 소통 시간, 수금 조건을 분리해 정리하도록 요청합니다. 고객 개인을 평가하는 대신 현재 업무 조건이 지속 가능한지 검토합니다.

질문은 '프로젝트의 범위·일정·비용 중 합의가 필요한 부분을 정리하고, 조건 재협상·범위 축소·일정 조정이라는 대안을 비교해 주세요. 계약 내용에 없는 권리나 의무를 단정하지 마세요'처럼 작성할 수 있습니다. 종료 여부는 계약과 관계를 확인한 뒤 사람이 결정합니다.

제품 관리자: 사용이 적은 기능을 검토한다

사용 빈도가 낮다는 사실만으로 기능을 삭제해야 하는 것은 아닙니다. 소수의 중요한 사용자에게 꼭 필요한지, 발견이 어려운지, 계절적 사용인지, 측정 방식에 문제가 있는지 확인해야 합니다. 사용량과 고객 가치, 유지 비용을 따로 보아야 합니다.

AI에게 '낮은 사용량을 설명할 수 있는 가설을 나누고, 각 가설을 확인할 조사나 로그 항목을 제안해 주세요. 유지·개선·제거 시 사용자에게 미치는 영향도 비교해 주세요'라고 요청합니다. 특정 결론을 증명하라고 요구하기보다, 결론이 바뀔 조건을 찾는 편이 유익합니다.

개발자와 기술 리더: 기술 부채의 우선순위를 정한다

기술 부채는 오래된 코드라는 이유만으로 모두 제거할 대상이 되지는 않습니다. 변경 빈도, 장애 영향, 보안 위험, 팀의 이해도와 개선 비용을 함께 검토해야 합니다. 최신 기술로 전환하면 생산성이 자동으로 높아진다는 가정도 검증이 필요합니다.

AI는 코드나 문서를 검토하는 질문 목록과 테스트 관점을 제안하는 데 활용할 수 있습니다. '현재 구조를 유지할 때와 부분 개선할 때의 위험을 비교하고, 측정할 지표와 되돌리는 계획을 정리해 주세요'라고 요청해 보세요. 운영 환경의 변경은 별도의 검토와 시험을 거쳐야 합니다.

마케팅 담당자: 보기 좋은 지표와 사업 성과를 구분한다

조회 수나 클릭 수가 높아도 실제 문의나 구매로 이어지는지는 따로 확인해야 합니다. 채널마다 측정 조건이 다르고, 같은 사람의 반복 행동이나 집계 기간의 차이가 있을 수 있습니다. AI에게 성과를 부풀리는 보고서를 쓰게 하기보다 지표의 정의와 연결 관계를 점검하게 합니다.

질문은 '조회·클릭·문의·구매 지표의 분모와 기간이 일치하는지 점검하고, 인과관계를 단정할 수 없는 부분을 표시해 주세요'입니다. 전환 개선을 주장하려면 실제 비교 자료가 필요합니다. 분석 결과는 예산을 자동 배분하는 결론보다 후속 실험의 설계에 활용합니다.

커리어 준비: 목표와 제약을 함께 본다

커리어 고민에 AI를 쓰더라도 사람의 성향이나 능력을 단정하는 평가는 피합니다. 현재 경험, 원하는 업무, 필요한 학습, 시간과 경제적 제약을 구분하고 여러 경로를 비교하는 방식이 좋습니다. 과격한 피드백이 동기 부여를 보장한다는 생각도 경계하세요.

AI에게 '내가 제시한 경험을 바탕으로 가능한 경로와 부족한 근거를 정리하고, 한 달 안에 시험할 수 있는 작은 행동을 제안해 주세요. 취업 가능성이나 연봉을 보장하지 마세요'라고 요청할 수 있습니다. 판단에 중요한 조건은 관련 분야 사람과 대화하거나 실제 정보를 확인해 보완합니다.

검토용 프롬프트를 반복 가능한 문서로 만들기

한 번 효과가 좋았던 질문을 그대로 만능 템플릿으로 쓰기보다, 입력 항목과 출력 형식을 명확히 해 두세요. 계획의 목표, 사실 자료, 기간, 제약, 검토할 대안, 결정권자를 정리하면 다른 프로젝트에도 적용하기 쉽습니다. 모델 이름과 실행 날짜도 기록하면 결과가 달라졌을 때 비교할 수 있습니다.

출력 형식은 '가정 목록→근거 부족 항목→반대 근거→대안 비교→검증 계획'처럼 고정할 수 있습니다. 모르는 내용은 모른다고 표시하고, 수치를 제시하려면 입력 자료의 계산 근거를 함께 적도록 요청합니다. 다만 형식을 지켰다고 정확성이 보장되지는 않으므로 검수 항목은 계속 필요합니다.

AI가 질문을 되묻는 상황을 실패로 볼 필요는 없습니다. 필요한 정보가 부족한 상태에서 단정적인 결론을 받는 것보다, 기간·예산·고객 조건을 추가로 확인하는 편이 낫습니다. 정보를 제공하기 어려우면 여러 가정의 시나리오로 나누고 각 시나리오가 실제 사실이 아님을 표시합니다.

검토 결과를 문서에 옮기기 전 확인할 항목

AI의 답변에서 주장과 제안을 먼저 나눕니다. '사용자가 이 기능을 원한다'는 주장은 근거를 확인해야 하고, '사용자 인터뷰를 진행해 보자'는 제안은 실행 가능성을 판단해야 합니다. 제안을 근거처럼 취급하거나, 가상의 사례를 실제 성과로 옮기지 않는 것이 중요합니다. 확인된 사실과 판단을 다른 칸에 적으면 검토 과정이 분명해집니다.

근거 자료에는 작성 날짜와 조사 범위, 원문의 표현을 기록할 수 있습니다. 오래된 사례를 현재의 확정 조건으로 사용하지 않고, 다른 업종의 결과가 우리 업무에도 적용되는지 확인하세요. 조사나 통계는 분모와 표본, 질문 방식에 따라 의미가 달라질 수 있습니다. AI가 요약한 문장만 보고 원자료의 조건을 생략하지 않습니다.

대안을 비교할 때는 기준의 중요도도 함께 봅니다. 비용이 가장 중요한 경우와 납기나 안전이 중요한 경우의 결론은 다를 수 있습니다. AI에게 하나의 최적안을 고르라고 하기보다 기준이 달라졌을 때 선택이 어떻게 바뀌는지 설명하게 할 수 있습니다. 다만 중요도의 숫자도 사람이 정한 가정임을 표시해야 합니다.

회의에서는 반대 의견을 낸 사람을 설득해야 할 대상으로만 보지 않습니다. 그 의견이 다른 자료나 현장 경험을 반영하는지 확인하고, 필요한 검증 항목으로 옮깁니다. AI의 분석을 근거로 동료의 우려를 무시하면 검토 도구가 오히려 확증 편향을 강화할 수 있습니다. AI 답변과 현장의 의견 모두 같은 기준으로 비교하세요.

질문이 유도적으로 쓰이지 않았는지 점검하기

'우리 계획이 경쟁사보다 훨씬 좋은 이유'처럼 결론을 질문에 포함하면 결과도 그 방향으로 치우칠 수 있습니다. '계획을 동일한 기준에서 비교하고 근거가 없는 부분을 표시해 달라'처럼 표현을 바꿔 보세요. 비교 대상의 자료가 불균형하면 AI가 임의로 채우지 말고 부족한 자료를 먼저 묻게 합니다.

'반드시 다섯 가지 오류를 찾아 달라'는 요청도 없는 문제를 만들어 내게 할 수 있습니다. 중요한 문제의 수를 고정하기보다 확인되는 문제만 나열하고 추가 점검이 필요한 가능성을 구분하도록 요청합니다. 반대로 문제를 찾지 못했다고 안전이 입증되는 것은 아닙니다. 검토 범위와 제공 자료의 한계를 함께 기록하세요.

AI에게 근거를 요구했더라도 존재하지 않는 출처를 만들 수 있습니다. 링크를 직접 열어 주장이 실제로 쓰여 있는지 확인하고, 인용의 맥락과 날짜를 봅니다. 출처가 없는 일반적인 조언은 조언으로 표시하고 실제 사실과 섞지 않습니다. 핵심 결정에 영향을 주는 근거를 우선 확인하면 검수 시간을 효율적으로 쓸 수 있습니다.

작은 실험의 결과를 받으면 처음 계획과 연결합니다. 어떤 가정이 지지되었고 어떤 가정이 약해졌는지, 다음 행동은 무엇인지 적으세요. 기대와 다른 결과를 AI에게 다시 긍정적으로 설명해 달라고 요청하기보다 실제 자료에 맞춰 계획을 수정합니다. 검토의 목적은 처음 생각을 방어하는 것이 아니라 더 나은 판단을 만드는 것입니다.

자주 묻는 질문

강한 말투를 요구하면 더 정확한 답이 나오나요?

말투와 정확성은 다릅니다. '잔인하게 비판하라'보다 근거, 불확실성, 대안과 검증 방법을 요구하는 편이 실무에 유용합니다. 반대 의견도 근거가 없으면 가정으로 취급해야 합니다.

같은 질문을 여러 번 하면 결론을 믿어도 되나요?

반복된 답변이 같은 오류를 공유할 수 있습니다. 다른 표현으로 질문하는 것은 빠진 관점을 찾는 데 도움이 되지만 원자료 확인을 대체하지는 않습니다. 중요한 주장은 독립적인 근거와 실제 데이터로 검증합니다.

AI에게 최종 결정을 맡겨도 되나요?

AI는 선택지와 검토 항목을 정리하는 데 쓰고, 중요한 업무 결정은 책임 있는 사람이 내립니다. 특히 계약·인사·개인정보와 관련된 판단은 조직의 절차와 전문적인 검토를 따릅니다.

검토가 너무 길어지면 어떻게 하나요?

결론을 바꿀 가능성이 큰 가정부터 검증하세요. 사소한 위험을 끝없이 나열하기보다 영향이 큰 두세 가지 조건을 골라 자료를 수집하고 작은 실험을 합니다. 검토에 쓸 시간과 다음 판단 날짜를 정해 두면 실행을 놓치지 않습니다.

AI를 좋은 검토 도구로 만드는 핵심은 칭찬을 줄이는 말투가 아니라 검증 가능한 질문입니다. 사실과 가정을 나누고, 반대 근거와 대안을 비교하고, 작은 실험과 사람의 검수로 연결하면 유창한 답변을 실제 의사결정에 더 신중하게 활용할 수 있습니다.