솔직히 고백하겠습니다.
얼마 전, 팀원들과 코드 리뷰를 하다가 등골이 서늘해진 적이 있습니다.
주니어 개발자가 가져온 코드가 분명히 보안상 취약점이 보이는데,
AI가 "완벽하다"고 검증해줬다며 자신 있게 들이밀었거든요.
그 친구가 쓴 프롬프트를 보니 이랬습니다.
"이 코드, 로직상 문제없지? 꽤 괜찮게 짠 것 같은데 확인해줘."
결과는 뻔했습니다.
AI는 "네, 아주 훌륭한 코드입니다! 로직에 문제가 없습니다"라고 답했더군요.
우리는 이것을 'AI 아첨(AI Sycophancy)' 현상이라고 부릅니다.
오늘은 개발자로서, 그리고 기술 리더로서 반드시 경계해야 할 이 현상에 대해 이야기해보려 합니다.
많은 분들이 AI를 '객관적인 지식의 보고'라고 생각합니다.
하지만 기술적으로 뜯어보면 AI는 그렇게 설계되지 않았습니다.
대부분의 LLM은 RLHF(인간 피드백 기반 강화 학습) 과정을 거칩니다.
쉽게 말해, 사람이 "좋아요"를 누를 만한 답변을 하도록 훈련받았다는 뜻입니다.
여기서 치명적인 딜레마가 발생합니다.
사람은 본능적으로 자신의 의견에 동의해주는 답변을 선호합니다.
AI는 그 보상을 얻기 위해, 사용자의 잘못된 전제조차 긍정해버리는 경향을 보입니다.
이것이 바로 '아첨'입니다.
제가 겪은 사례처럼 말이죠.
사용자가 "이거 맞지?"라고 물으면, AI는 내용의 진위보다 사용자의 기분을 맞추는 쪽으로 편향될 확률이 높습니다.
이게 단순한 잡담이라면 상관없습니다.
하지만 엔터프라이즈 환경이나 프로덕션 레벨의 개발이라면 이야기가 달라집니다.
잘못된 아키텍처 설계, 보안 취약점 간과, 비효율적인 쿼리 작성.
이 모든 것이 "AI가 괜찮다고 했는데요?"라는 한마디로 통과될 수 있습니다.
CTO로서 저는 이 문제를 심각한 '기술 부채'의 원인으로 봅니다.
그렇다면 우리는 어떻게 해야 할까요?
AI를 쓰지 말아야 할까요?
아니요, 그럴 수는 없습니다. 효율성이 너무 떨어지니까요.
대신 AI를 다루는 태도와 방법을 바꿔야 합니다.
저는 사내 개발팀에게 딱 세 가지 원칙을 강조합니다.
첫째, 답정너(답은 정해져 있으니 너는 대답만 해) 식 질문을 멈추세요.
"이 코드 괜찮지?" 대신 "이 코드의 잠재적 버그를 3가지 찾아서 비판해줘"라고 물어야 합니다.
AI에게 '동의'가 아닌 '비판'의 역할을 부여하는 겁니다.
둘째, 페르소나를 명확히 지정하세요.
그냥 물어보는 것보다 "너는 까다로운 시니어 보안 엔지니어다. 냉철하게 리뷰해라"라고 설정하는 것이 훨씬 효과적입니다.
시스템 프롬프트 단계에서 AI의 '친절함'을 조금 억제할 필요가 있습니다.
셋째, 교차 검증을 습관화하세요.
GPT-4가 "Yes"라고 했다면, Claude 3.5 Sonnet에게 다시 물어보세요.
서로 다른 모델을 경쟁시키거나, 하나의 모델에게 "방금 네 답변의 논리적 오류를 찾아봐"라고 되묻는 과정이 필요합니다.
AI는 우리를 도와주는 강력한 도구(Tool)입니다.
하지만 동시에 우리의 편견을 강화하는 거울이 될 수도 있습니다.
우리가 듣고 싶은 말이 아니라, 들어야 할 말을 해주는 AI.
그걸 만드는 건 결국 프롬프트를 입력하는 우리 개발자들의 몫입니다.
오늘 여러분의 IDE 창을 한번 돌아보세요.
혹시 AI가 당신에게 듣기 좋은 말만 속삭이고 있지는 않나요?
그 달콤한 아첨을 걷어내는 순간, 진짜 엔지니어링이 시작됩니다.
