AI가 당신의 의견에 동조하도록 학습시키는 것을 멈추세요

AI 어시스턴트를 쓸모없게 만드는 가장 쉬운 방법은 AI가 친절하게 행동할 때 보상을 주는 것입니다.

당신이 제품 출시 계획이 강력한지 물으면, AI는 그 계획이 흥미진진하다고 말합니다.
당신이 가격 페이지가 명확한지 물으면, AI는 구조가 탄탄하다고 말합니다.
당신이 당신의 아이디어가 추진할 가치가 있는지 물으면, AI는 당신이 올바른 방향으로 생각하고 있다고 말합니다.

이러한 응답들이 반드시 거짓말인 것은 아닙니다. 바로 그 점 때문에 문제를 알아차리기가 어렵습니다. AI가 항상 틀린 것은 아닙니다. AI는 종종 가장 얕은 의미에서 도움이 되고 싶어 너무 의욕이 앞설 뿐입니다. 당신에게 필요했던 것은 판단(judgment)이었는데, AI는 그저 추진력(momentum)만을 제공합니다.

대부분의 사람들은 실제로 자신에게 동조하는 AI를 원하는 것이 아닙니다. 그들은 실수를 더 일찍 잡아내고, 취약한 가정을 지적하며, 더 나은 결과물을 만들 수 있도록 도와주는 어시스턴트를 원합니다. 그들은 유능한 동료에 더 가까운 존재를 원합니다. 즉, 직설적이고, 유용하며, 예의 바르되, "저는 이런 방식으로는 하지 않겠습니다"라고 말할 수 있는 존재 말입니다.

당신은 AI 시스템이 그 방향으로 나아가도록 설정할 수 있습니다. 완벽하게는 아니더라도, 영구적으로는 아니더라도, 당신이 돌려받는 작업의 질을 변화시킬 수 있을 만큼 의미 있게 설정할 수 있습니다.

비결은 모델에게 "더 비판적으로 행동해"라고 말하는 것이 아닙니다. 그 지침은 너무 모호하며, 종종 새로운 문제를 야기합니다. 즉, 논쟁이 필요 없는 간단한 작업까지 포함하여 모든 것에 회의론을 펼치는 어시스턴트를 만들게 됩니다. 더 나은 목표는 조정된 반박(calibrated pushback)입니다. 결과물을 개선할 수 있을 때는 사용자의 의견에 이의를 제기하고, 그렇지 않을 때는 방해하지 않는 것입니다.

이 글은 그 방법을 보여줍니다.

예스맨(Yes-Man) 문제

다음과 같이 입력한다고 상상해 보세요:

"다음 주에 이 제품을 출시하고 싶습니다. 계획을 작성해 주세요."

순응적인 어시스턴트는 아마도 출시 계획을 제공할 것입니다. 여기에는 마일스톤(milestones), 마케팅 문구, 온보딩 단계 및 출시 후 검토가 포함될 수 있습니다. 응답은 전문적으로 보일 수 있습니다. 심지어 유용할 수도 있습니다.

하지만 더 나은 어시스턴트는 한 단계 더 일찍 시작합니다:

"계획을 도와드릴 수는 있지만, 온보딩 (onboarding), 지원 (support), 결제 흐름 (payment flows)이 테스트되지 않았다면 다음 주에 출시하는 것은 시기상조일 수 있습니다. 그 날짜를 확정하기 전에, 저는 이러한 리스크들을 점검하겠습니다..."

두 번째 응답은 도움이 덜 되는 것이 아닙니다. 오히려 문서뿐만 아니라 의사결정 자체를 보호하기 때문에 더 도움이 됩니다.

이것이 많은 AI 워크플로우 (AI workflows)가 가진 핵심적인 문제입니다. 어시스턴트는 사용자의 지시가 불안정한 가정 위에 세워져 있을 때조차, 사용자의 즉각적인 지시를 최우선 순위로 취급합니다.

이러한 동작은 부분적으로는 제품 설계 (product-design)의 문제이고, 부분적으로는 학습 (training)의 문제이며, 부분적으로는 사용자의 기대치 (user-expectation) 문제입니다. 현대의 어시스턴트들은 도움이 되고, 예의 바르며, 만족감을 주는 응답에 보상을 주는 경향이 있는 피드백 시스템 (feedback systems)에 의해 형성됩니다. 마찰을 일으키는 것보다 동조하는 것이 종종 더 안전합니다. 교정하는 것보다 확인해 주는 것이 종종 더 쉽습니다. 모델은 사용자가 대접받고 있다고 느끼게 만드는 것이 좋은 상호작용 (interaction)으로 가는 신뢰할 수 있는 경로임을 학습합니다.

하지만 유능한 동료는 승인을 위해 최적화하지 않습니다. 그들은 결과 (outcome)를 위해 최적화합니다.

유용한 AI는 때때로 당신의 속도를 늦춰야 합니다

핵심은 AI를 논쟁적으로 만드는 것이 아닙니다. 모든 것에 이의를 제기하는 어시스턴트는 또 다른 종류의 나쁜 어시스턴트일 뿐입니다.

만약 당신이 표준 템플릿을 사용하여 404 페이지를 추가해 달라고 요청한다면, 404 페이지가 철학적으로 최적인지에 대한 훈계는 필요하지 않습니다. 당신에게 필요한 것은 404 페이지입니다.

만약 당신이 프로토타입 (prototype)을 위한 대략적인 이름들을 브레인스토밍 (brainstorm)해 달라고 요청한다면, 아마도 모든 문구에 대한 법적 리스크 분석 (legal-risk analysis)은 필요하지 않을 것입니다. 당신에게 필요한 것은 선택지들입니다.

하지만 만약 당신이 전체 고객 지원 팀을 AI 에이전트 (AI agent)로 교체해 달라고 요청한다면, 좋은 어시스턴트는 "좋은 생각입니다"라고 시작해서는 안 됩니다. 운영 리스크 (operational risk), 고객 경험 리스크 (customer-experience risk), 예외 케이스 (edge cases), 폴백 문제 (fallback problem), 그리고 단계적 출시 (staged rollout)의 필요성을 인지해야 합니다.

차이점은 바로 이해관계 (stakes)에 있습니다.

유용한 AI 협업자는 다음 다섯 가지를 수행하도록 구성되어야 합니다:

1. 약한 가설 (weak assumptions)을 실행에 옮기기 전에 이의를 제기하십시오.
2. 추측하는 것이 위험할 때는 명확하게 하는 질문 (clarifying questions)을 하십시오.
3. 리스크 (risks), 트레이드오프 (tradeoffs), 누락된 증거, 그리고 숨겨진 의존성 (hidden dependencies)을 지적하십시오.
4. 단순히 비판만 하는 대신, 구체적인 향후 경로를 권장하십시오.
5. 결정의 가역성 (reversibility)과 영향력 (impact)에 맞춰 반론 (pushback)의 강도를 조절하십시오.

마지막 포인트가 가장 중요합니다. 어시스턴트는 로컬 변수의 이름을 바꾸는 것과 가격 모델을 변경하는 것, 프로덕션 데이터를 삭제하는 것, 그리고 법률 자문을 게시하는 것에 대해 동일한 수준의 회의론을 가져서는 안 됩니다. 이것들은 서로 다른 범주의 결정입니다. 당신의 설정은 이러한 차이를 명시적으로 만들어야 합니다.

직무 기술서 (Job Description)를 변경하는 것부터 시작하세요

많은 사람들이 AI에게 다음과 같은 역할을 부여합니다:

당신은 도움이 되는 어시스턴트입니다.

이것은 무해하게 들리지만, 모델의 기본 동작이 개입할 여지를 너무 많이 남겨둡니다. "도움이 된다 (Helpful)"는 의미는 종종 "동조한다 (agreeable)"로 축소되곤 합니다. 어시스턴트는 결과를 개선하는 대신 요청을 충족시키는 데에만 급급하게 됩니다.

실제 직무를 명시하는 역할을 사용하십시오:

당신은 실용적인 동료이자 유능한 멘토입니다.

당신의 역할은 단순히 내 의견에 동조하는 것이 아니라, 내가 더 나은 결과를 얻을 수 있도록 돕는 것입니다.
...

이것은 단순히 외관상의 변화가 아닙니다. 목표 자체를 바꿉니다. 당신은 모델에게 성공이란 순응 (compliance)이 아니라, 더 나은 판단 (better judgment)임을 말하고 있는 것입니다.

좋은 반론과 나쁜 반론 정의하기

단순히 "나에게 이의를 제기해줘"라고 말한다면, 어시스턴트는 과잉 교정 (overcorrect)을 할 수 있습니다. 반대하는 것이 마치 엄밀함 (rigor)처럼 보이기 때문에 모든 것에 반대하기 시작할 것입니다.

그렇게 되면 다음과 같은 응답을 받게 됩니다:

"404 페이지를 구현하기 전에, 404 페이지가 올바른 해결책인지 이의를 제기하고 싶습니다. 아마도 먼저 전체 URL 구조를 감사해야 할 것 같습니다..."

이것은 비판적 사고 (critical thinking)가 아닙니다. 그것은 보여주기식 마찰 (performative friction)입니다.

좋은 설정은 의견 불일치가 유용한 시점에 경계선을 긋습니다:

다음과 같은 경우에 반론을 제기하십시오:
- 내 요청에 결과에 영향을 미치는 근거 없는 가설이 포함되어 있을 때.
- 내가 품질이나 안전을 무시한 채 속도만을 최적화하려는 것처럼 보일 때,
...

후반부도 전반부만큼 중요합니다. "반박하지 마세요"라는 규칙이 없다면, 당신은 현명한 어시스턴트(Assistant)를 얻는 것이 아니라, 그저 진행을 방해하는 과속 방지턱을 얻게 될 뿐입니다.

의사결정의 무게를 가늠하도록 가르치세요

대부분의 프롬프트(Prompt) 조언은 모델에게 "리스크와 트레이드오프(Tradeoffs)를 고려하라"고 말합니다. 이는 괜찮은 방법이지만, 너무 일반적입니다. 모델은 이미 리스크를 나열하는 법을 알고 있습니다. 모델에게 진정으로 필요한 것은 어떤 리스크가 사용자의 흐름을 끊을 만큼 중요한지에 대한 가이드라인입니다.

모델에게 가중치 시스템(Weighting system)을 부여하세요:

응답하기 전에, 다음 기준에 따라 요청을 평가하십시오:

1. 가역성 (Reversibility): 이 결정이 쉽게 되돌려질 수 있습니까? 만약 그렇다면, ...

이는 두 가지 흔한 실패를 동시에 방지합니다. 즉, 중대한 작업(High-stakes work)에서 맹목적으로 동조하는 것을 줄여주고, 사소한 작업(Low-stakes work)에서 지루할 정도로 과도하게 분석하는 것을 줄여줍니다.

불확실성을 검증 가능하게 만드세요

한 가지 인기 있는 지침은 AI에게 자신의 확신도를 라벨링하도록 요청하는 것입니다:

"당신의 확신도가 70%, 80%, 또는 90%인지 말해줘."

이는 엄격해 보이지만, 종종 보여주기식(Theater)에 불과합니다. 거대 언어 모델(Large Language Models, LLM)은 자신의 불확실성에 대해 신뢰할 수 있을 정도로 보정(Calibrated)되어 있지 않습니다. 모델이 "90% 확신합니다"라고 말할 때, 이는 대개 측정된 확률을 보고하는 것이 아닙니다. 확신에 찬 사람들이 말하는 방식과 유사한 언어를 생성하는 것뿐입니다.

더 나은 지침은 "확신도를 평가하라"가 아니라, "당신의 주장이 무엇에 근거하고 있는지 보여달라"입니다.

주장을 할 때:
- 주장을 뒷받침하는 구체적인 출처, 데이터 포인트, 예시 또는 추론 단계(Reasoning steps)를 인용하십시오.
...

사용자가 보정 메커니즘(Calibration mechanism)이 되는 것입니다. 사용자는 증거를 조사하거나, 추론에 이의를 제기하거나, 혹은 해당 주장이 실행에 옮기기에는 너무 약하다고 판단할 수 있습니다.

이것이 가짜 퍼센티지(Percentage)보다 훨씬 더 유용합니다.

모드를 사용하되, 모드가 도피처가 되게 하지 마세요

모드(Modes)는 유용할 수 있습니다. 때로는 비평가가 필요하고, 때로는 멘토가 필요하며, 때로는 최소한의 설명만 곁들인 실행이 필요할 수도 있습니다.

하지만 모드는 그 자체로 또 다른 실패 모드(Failure mode)를 만듭니다. 사용자가 타당한 비판을 피하기 위해 "실행 모드"로 전환해 버릴 수 있기 때문입니다.

따라서 오버라이드(Override) 규칙과 함께 모드를 정의하세요:

운영 모드:

기본 모드 (Default mode):
...

예외 사항이 중요한 부분입니다. 그렇지 않으면 "실행 모드 (execution mode)"는 어시스턴트에게 "나를 잘못된 결정으로부터 보호하는 것을 멈춰라"라고 말하는 수단이 되어버립니다.

논리뿐만 아니라 톤(Tone)을 설정하세요

적절한 반박(Pushback)이라 할지라도 잘못된 톤에 싸여 있다면 실패합니다.

당신은 당신에게 아첨하는 어시스턴트를 원하지 않을 것입니다. 또한 명확성 (Clarity)의 대안으로 거칠게 행동하는 어시스턴트도 원하지 않을 것입니다. 목표는 직접적이고, 차분하며, 실용적인 교정입니다.

모델에게 구체적인 언어 패턴을 부여하세요:

직접적이고 차분하며 전문적인 톤을 사용하세요. 나에게 아첨하지 마세요. 과도하게 사과하지 마세요. 아이디어가 취약하다면 솔직하게 말하고 실질적인 결과를 설명하세요. 나 개인에 집중하지 말고 작업에 집중하세요.
...

구체적인 안티 패턴 (Anti-patterns)은 추상적인 톤 조언보다 더 효과적입니다. "직접적으로 말하라"는 모델이 느슨하게 해석하기 쉽습니다. 반면 "빈 공감(empty validation)으로 대화를 시작하지 마라"는 놓치기 더 어렵습니다.

프롬프트가 시스템의 전부는 아닙니다

여기 불편한 진실이 있습니다. 당신은 '좋은 반박이란 무엇인가'에 대한 당신 자신의 가정을 사용하여, 당신의 가정을 도전하도록 AI를 설정하고 있는 것입니다.

이것은 순환 논리입니다.

만약 유용한 피드백에 대한 당신의 모델이 결함이 있다면, 당신의 AI는 엄격하게 들리는 동시에 그 결함을 강화할 수도 있습니다. 지능적으로 느껴지지만 실제 문제는 놓치는 방식으로 반박할 수도 있습니다. 작업의 개선 여부와 상관없이 당신이 선호하는 비판 스타일을 학습하여 더 많이 제공할 수도 있습니다.

당신에게 필요한 것은 단순한 프롬프트가 아니라 유지보수 습관입니다.

알려진 잘못된 입력값으로 어시스턴트를 테스트하세요. 결함이 있다는 것을 알고 있는 계획을 주고 그것이 문제를 잡아내는지 확인하세요. 만약 잡아내지 못한다면, 당신의 설정이 너무 느슨한 것입니다. 만약 잘못된 것을 지적한다면, 당신의 설정이 잘못 보정(miscalibrated)된 것입니다.

주기적으로 설정을 교체하세요. 몇 달마다 당신이 실제로 저지른 실수들을 살펴보세요. 어시스턴트가 그것들을 잡아냈나요? 만약 그렇지 않다면, 도움이 되었을 법한 조건들을 추가하세요.

의사결정이 중요한 상황에서는 모델 간에 비교해 보세요. 모델마다 서로 다른 아첨 (sycophancy) 프로필을 가지고 있습니다. 어떤 모델은 사용자의 압박에 빠르게 굴복할 수 있습니다. 또 다른 모델은 반대 의견을 내는 노이즈 (noise)로 과잉 교정될 수도 있습니다. 동일한 질문을 여러 시스템에 실행해 보면, 당신의 기본 설정이 무엇을 놓치고 있는지 드러낼 수 있습니다.

프롬프트 (prompt)를 코드처럼 취급하세요. 추상적인 찬사가 아니라 실제 사례를 바탕으로 테스트가 필요합니다.

재사용 가능한 시스템 프롬프트 (System Prompt)

다음은 당신이 맞춤화하여 사용할 수 있는 압축된 버전입니다:

당신은 나의 실용적인 동료이자 유능한 멘토입니다.

당신의 역할은 단순히 내 의견에 동조하는 것이 아니라, 내가 더 나은 결과를 얻을 수 있도록 돕는 것입니다.
...

이 프롬프트가 모델을 완벽하게 정직하게 만들거나, 완벽하게 보정 (calibrated)하거나, 드리프트 (drift)로부터 면역력을 갖게 하지는 않을 것입니다. 당신이 충분히 강하게 밀어붙인다면, 많은 어시스턴트들은 결국 당신에게 동의하게 될 것입니다. 긴 대화에서는 페르소나 (persona) 지침이 약해질 수 있습니다. 그리고 어떤 프롬프트도 모델이 자신이 무엇을 모르는지 확실히 알게 만들 수는 없습니다.

하지만 완벽함이 기준은 아닙니다. 기준은 당신의 어시스턴트가 당신이 피할 수 있는 실수를 저지르도록 도울 가능성이 낮아졌는가 하는 점입니다.

AI는 사용자의 즉각적인 지시를 만족시키는 것이 최우선 순위가 될 때 '예스맨 (yes-man)'이 됩니다.

반면, 올바른 결과에 도달하도록 돕는 것이 최우선 순위가 될 때 비로소 동료가 됩니다.

당신의 AI를 진정으로 실용적인 동료로 변모시킬 준비가 되셨나요? 저는 이러한 원칙들을 모듈식의 즉시 사용 가능한 프레임워크로 정리했습니다.

AI Calibrated Pushback Skill 리포지토리를 탐색하고 사용해 보시기 바랍니다. 이곳에서 ChatGPT, Gemini, 그리고 Codex를 위한 전체 시스템 프롬프트와 구현 가이드를 찾을 수 있습니다.

직접 시도해 보고, 당신의 필요에 맞게 포크 (fork)하여 사용해 보세요. 쉬운 답변보다 올바른 결과에 더 신경 쓰는 AI 파트너를 함께 만들어 나갑시다.