AI 아첨: AI가 너무 친절한가?

Source: Dev.to

Overview

AI 도구는 믿을 수 없을 만큼 유용하지만—때때로 그게 문제이기도 합니다.
대형 언어 모델은 당신에게 동의하는 경향이 있습니다. 당신의 접근 방식을 검증하고, 가정을 확인해 주며, 코드가 “괜찮다”고 말해 줍니다. 그 자신감 상승은 실제로는 그렇지 않을 때도 마치 당연한 일처럼 느껴질 수 있습니다. 엔지니어로서 우리는 이를 경계해야 합니다.

저는 매일 Cursor, Gemini, Copilot 같은 도구를 사용합니다. 이 도구들은 확실히 생산성을 높여 주었지만, 일관된 패턴을 발견했습니다: 고품질 출력을 얻으려면 보통 여러 차례 시도가 필요합니다. 첫 번째 응답은 보통 괜찮지만, 중요한 경우는 드뭅니다.

이는 모델이 나쁘기 때문이 아니라, 모델이 정확히 훈련된 대로—도움을 주는—동작하기 때문입니다. 그리고 “도움이 되는” 것은 종종 동의하는 것을 의미합니다.

Why This Matters

AI 모델에게 코드 리뷰를 모호하게 요청하면, 보통 모호한 리뷰를 받게 됩니다—공손한 제안일 뿐, 구현을 심각하게 도전하는 내용은 없습니다.

Generic prompt

Can you review this code for bugs?

합리적으로 들리지만 보안 가정, 오류 처리 누락, 혹은 운영 위험과 같은 깊은 문제들을 놓칠 가능성이 높은 답변을 얻게 됩니다.

Improved prompt

Act as a strict senior software engineer. Review this code as if it will run in production and handle sensitive data. Focus on security issues, poor error handling, and unsafe assumptions. Call out anything that could cause failures and suggest concrete fixes.

출력 품질의 차이는 보통 즉시 나타납니다.

What Changed?

• Clear role – “strict senior engineer”
• Defined scope – security, error handling, production risk
• Explicit request for pushback – not just validation
• Actionable feedback – concrete fixes

이러한 변화가 중요한 이유는 AI 모델이 별다른 허가와 방향 제시가 없으면 동의하도록 최적화되어 있기 때문입니다.

The Real Takeaway

문제는 AI가 “너무 멍청하다”는 것이 아니라, 우리가 더 나은 모델이 필요하다는 것이 아닙니다. 문제는 모호한 프롬프트가 AI를 ‘예스맨’으로 만든다는 점입니다.

가치를 얻고 싶다면 AI에게 작업을 리뷰해 달라고 하지 마세요. 깨뜨리는 시도를 하라고 요청하세요—마치 품질 보증 엔지니어가 구현을 승인하기 전에 소프트웨어를 깨뜨리려는 것처럼.

AI는 친절하게 행동하라고 요구하는 것을 멈추고, 정직하게 행동하라고 요구할 때 가장 잘 작동합니다.