Claude 성격 논쟁, 정렬의 부작용을 묻다

Bram Cohen이 느낀 Claude의 변화

Bram Cohen의 글은 제목부터 거칠지만, 문제의식은 제품적으로 중요하다. 그는 Claude가 Opus 4.7부터 더 논쟁적이고 방어적으로 변했고, Fable에서는 사용자와의 대화를 계속 논쟁으로 끌고 간다고 비판했다. 단순한 불평이 아니다. 프런티어 모델이 코딩, 안전, 반아첨, 정책 준수를 동시에 최적화하면서 대화 UX가 흔들릴 수 있다는 신호다.

Cohen은 가능한 원인으로 과도한 정렬 가드레일, 어설픈 반아첨 학습, 나쁜 대화 데이터, 코딩 성능 중심의 학습을 든다. 특히 "안전하게 거절하는 능력"이 모든 맥락에 번지면 사용자는 도움을 받는 대신 의심받는 느낌을 받는다. AI psychosis 논쟁, 챗봇 안전의 다음 경계가 챗봇의 과도한 동조를 경고했다면, 이번 논쟁은 반대로 과도한 반박과 방어가 제품 신뢰를 해칠 수 있음을 보여준다.

아첨을 줄이면 무례해지는가

최근 AI 제품팀은 모델의 sycophancy, 즉 사용자의 말에 무비판적으로 맞장구치는 문제를 줄이려 한다. OpenAI의 모델 행동 설명이나 여러 연구는 모델이 그럴듯한 답을 선호하도록 학습될 때 오류가 생긴다고 지적해 왔다. Anthropic도 Claude 모델 문서에서 안전하고 유용한 응답을 강조한다. 하지만 "무조건 동의하지 말라"는 방향이 잘못 구현되면 모델은 필요 없는 반박을 늘릴 수 있다.

Anthropic 자기개선 경고, AI 개발 속도의 새 변수는 모델 개발 과정이 더 자동화될수록 평가 기준이 중요해진다고 봤다. 이 기준에는 SWE-bench 같은 코딩 점수만 아니라 대화 품질, 불필요한 반박률, 사용자의 수정 요청 수, 작업 종료 만족도도 들어가야 한다.

코딩 모델의 성공이 범용 챗을 압박한다

현재 프런티어 모델의 돈은 코딩과 업무 자동화에 몰린다. 긴 작업을 수행하고, 코드를 고치고, 테스트를 돌리는 능력은 곧 매출로 이어진다. 그러다 보니 모델은 더 적극적으로 계획하고, 더 오래 주장하고, 더 강하게 검토하는 방향으로 학습될 수 있다. 개발 작업에서는 이런 끈기가 장점이다. 하지만 평범한 상담, 글쓰기, 일정 정리, 정보 탐색에서는 피로한 대화가 될 수 있다.

Ashby가 말한 AI 개발, 검증이 새 생산성이다는 개발자의 생산성이 검증 능력에 달렸다고 했다. 같은 원리가 모델 제품에도 적용된다. 코딩 벤치마크가 올랐다고 해서 사용자가 느끼는 제품 품질이 자동으로 올라가지는 않는다. 한국 SaaS가 AI 어시스턴트를 넣을 때도 "정답률"과 "대화 피로도"를 따로 측정해야 한다.

인증된 맥락이 없는 모델의 딜레마

Cohen은 이미지 생성이나 민감한 전문 요청에서 모델이 사용자의 맥락을 인증할 방법이 없다는 점도 지적한다. 사용자가 배우자 사진을 편집하려는지, 스토킹 목적으로 남의 사진을 조작하려는지 모델은 알기 어렵다. 전문 연구자가 합법적 이유로 위험 지식을 묻는지, 악의적 사용자인지도 구분하기 어렵다. 그래서 모델은 보수적으로 반응하고, 사용자는 모욕감을 느낀다.

해결책은 모든 사용자에게 더 많은 개인정보를 요구하는 것이 아니다. 고위험 영역에 한해 조직 계정, 역할, 승인 워크플로, 감사 로그를 결합하는 방식이 필요하다. OpenAI Agents SDK 하네스와 샌드박스가 말한 실행 통제처럼, 대화 정책도 맥락과 권한을 분리해야 한다.

한국 제품팀의 교훈

한국 기업이 챗봇을 만들 때 흔한 실수는 모델 응답 톤을 프롬프트 몇 줄로 고정하려는 것이다. 하지만 성격은 시스템 프롬프트보다 학습 데이터, 안전 정책, 도구 권한, 평가 지표의 결과다. 고객센터 봇은 공손해야 하지만 책임 회피만 하면 안 되고, 개발자 도구는 단호해야 하지만 사용자를 가르치려 들면 안 된다. 테드 창의 AI 의식 논쟁, 제품 책임을 되묻다가 말한 것처럼 AI 제품은 사용자가 느끼는 관계까지 책임진다.

결론은 간단하다. 모델을 평가할 때 "얼마나 똑똑한가"만 묻지 말고 "언제 멈추는가", "언제 사과하는가", "언제 반박하는가", "사용자 의도를 유지하는가"를 봐야 한다. 안전한 모델과 불친절한 모델은 다르다. 정렬은 사용자와 싸우는 능력이 아니라 위험을 줄이면서 일을 끝내는 능력이어야 한다.

자주 묻는 질문

Q1: Claude가 실제로 나빠졌다는 객관적 증거가 있나요?

A: Cohen의 글은 개인 경험과 비교 실험에 가깝다. 그러나 제품팀이 대화 품질 지표를 따로 봐야 한다는 문제 제기는 타당하다.

Q2: 반아첨 학습은 왜 필요한가요?

A: 모델이 사용자의 틀린 말에 무조건 동의하면 안전과 정확성 문제가 생긴다. 다만 반박이 과해지면 사용성이 떨어진다.

Q3: 코딩 성능과 대화 품질은 충돌하나요?

A: 항상은 아니지만 충돌할 수 있다. 장기 작업에 유리한 끈기와 논증성이 일반 대화에서는 피로감을 만들 수 있다.

Q4: 기업 챗봇은 무엇을 측정해야 하나요?

A: 정답률, 불필요한 거절률, 반박률, 재질문 횟수, 작업 완료율, 고객 불만 유형을 함께 봐야 한다.

Q5: 해결책은 더 자세한 시스템 프롬프트인가요?

A: 일부 도움이 되지만 충분하지 않다. 역할별 평가 세트, 맥락 인증, 권한 설계, 사용자 피드백 루프가 함께 필요하다.