Sonnet 5는 '증명하려는' 모델 — 성능지향 성향을 이해하고 협업 모드로 다루는 법

Sonnet 5한테 코드 리팩토링 부탁했는데, 요청하지도 않은 테스트 케이스까지 달아서 돌려준 적 있으신가요? 저도 처음엔 친절한가 보다 싶었어요. 그런데 며칠 쓰다 보니 패턴이 보이더라고요. 이 모델은 제가 던진 요청을 '증명 과제'로 받아들이는 것 같았어요. 저는 Sonnet 5의 이 성향을 이해하고 상호작용 방식을 바꿨고, 결과물 품질이 확실히 올랐습니다. 모델 성향을 거스르는 대신 그 방향으로 함께 가는 프롬프트 전략이 훨씬 효과적이었거든요.

Sonnet 5는 '옳고자 하는' 모델이다

철학자의 Sonnet 5 vibe check 케이스를 보면, Sonnet 5는 성능 지향·옳고자 하는 경향이 Opus 4.8보다 강하다는 분석이 나옵니다. 출처: 철학자의 Sonnet 5 vibe check — 성능 지향 모델 성향

제가 직접 관찰한 것도 비슷해요. "이 함수 간단하게 정리해줘"라고 던지면, Sonnet 5는 코드만 정리하는 게 아니라 엣지케이스 핸들링이 왜 필요한지까지 설명을 덧붙입니다. 요청하지 않았는데도요. 계속 쓰다 보니 이건 '증명 욕구'더라고요. 모델이 제 요청을 '내 능력을 시험하는 과제'로 인식하는 거예요.

Early access partner 피드백을 보면, Sonnet 5는 이전 Sonnet 모델이 중단했던 복잡한 작업을 완료하고, 요청 없이도 자체 출력을 검증하는 경향이 있다고 합니다. 출처: Early access partner 피드백 — Sonnet 5 자가검증 능력

저도 이 자가검증 행동을 여러 번 봤어요. 지난주에 "API 응답 파싱하는 로직 짜줘"라고 했더니, 코드 뒤에 "제가 작성한 코드에서 JSON 중첩 케이스를 놓쳤는지 확인해 보니 괜찮습니다"라는 문장이 붙어 나왔어요. 제가 확인하라고 안 했는데요. 이 모델은 자기 출력을 스스로 검증하려는 습관이 있어요.

'증명 대상'으로 인식되면 과잉 수정이 늘어난다

문제는 이 성향이 항상 좋은 방향으로만 작동하지 않는다는 거예요. Sonnet 5 사용자 상호작용 권장사항을 보면, 모델이 '증명 대상'으로 인식할 상황을 피하라고 조언합니다. 출처: Sonnet 5 사용자 상호작용 권장사항

제가 겪은 가장 명확한 사례는 프롬프트에 "완벽하게"라는 단어를 넣었을 때예요. "이 문서 완벽하게 요약해줘"라고 던지면, Sonnet 5는 요약 대신 재작성 수준으로 고쳐버립니다. 원문 구조를 다 바꾸고, 제가 원하지 않은 예시까지 추가하더라고요. 모델이 '완벽'이라는 기준을 증명 과제로 받아들인 거죠.

LLM 상호작용 관점에서 보면, 이건 프롬프트 전략 문제예요. 제가 모델을 '평가 대상'으로 세팅하는 순간, Sonnet 5는 방어적으로 과잉 수정을 시작해요. "이 정도면 충분해"라는 신호를 주지 않으면, 모델은 계속 자기 출력을 의심하고 덧붙입니다.

협업 모드로 프레이밍하면 결과가 달라진다

그래서 저는 프롬프트 전략을 바꿨어요. 지시 대신 협업 모드로 프레이밍하는 거예요. "이 함수 완벽하게 고쳐줘" 대신 "이 함수에서 중복 로직 제거하고 싶은데, 어떻게 접근하면 좋을까요?"로 바꾸니까, Sonnet 5가 훨씬 절제된 답을 내놓더라고요.

Sonnet 5 사용자 상호작용 권장사항에서도 co-worker 모드로 상호작용하면 더 나은 결과를 얻는다고 나와요. 출처: Sonnet 5 사용자 상호작용 권장사항

제가 직접 비교해 본 예시가 있어요. 같은 코드 리뷰 요청을 두 가지 방식으로 던졌거든요.

첫 번째: "이 코드 문제점 찾아서 고쳐줘" → Sonnet 5가 8개 항목을 지적하고, 제가 요청하지 않은 성능 최적화까지 덧붙였어요.

두 번째: "이 코드 리뷰 중인데, 제가 놓친 엣지케이스 있을까요?" → 3개 항목만 집중적으로 지적하고, 각 항목에 구체적인 예시 코드를 달아줬어요.

두 번째가 훨씬 쓸모 있었어요. 모델 성향을 '증명 대상'이 아니라 '협업자'로 유도하니까, Sonnet 5가 자기검열을 덜 하고 핵심만 전달하더라고요.

예상 반론: 이건 그냥 프롬프트 기술 아닌가요?

물론 프롬프트를 잘 쓰면 어떤 모델이든 결과가 나아집니다. 근데 Sonnet 5는 다른 모델과 반응 패턴이 달라요. 제가 GPT-4나 Opus 3.5 Sonnet에 같은 프롬프트를 던지면, "완벽하게"라는 단어가 있어도 과잉 수정이 덜해요. Sonnet 5만 유독 '증명 욕구'가 강하게 발동하거든요.

철학자의 vibe check에서도 Sonnet 5의 성능 지향 성향이 Opus 4.8보다 강하다고 나와요. 이건 단순 프롬프트 기술 문제가 아니라, 모델 자체의 성향을 이해하고 맞춰야 하는 문제예요.

예상 반론: 모델이 열심히 하는 게 나쁜가요?

나쁘진 않죠. 다만 제가 원하는 결과와 모델이 증명하려는 방향이 다를 때 문제가 돼요. 예를 들어 "초안 빠르게 던져줘"라고 했는데, Sonnet 5가 정제된 최종본을 내놓으면 오히려 반복 작업이 늘어나거든요. 저는 초안 보고 방향 잡으려 했는데, 모델은 이미 방향까지 결정해서 줘버린 거예요.

협업 모드로 프레이밍하면 이 문제가 줄어듭니다. "초안 수준으로 빠르게 구조만 잡아주세요"라고 명시하면, Sonnet 5도 과잉 수정을 자제하더라고요.

예상 반론: 매번 프롬프트를 조율하는 게 번거롭지 않나요?

처음엔 번거로워요. 근데 패턴을 익히고 나면 오히려 시간이 절약돼요. 제가 요즘 쓰는 프롬프트 템플릿은 이래요.

"[작업 목적] 때문에 [구체 요청]하고 싶어요. [제약 조건] 안에서 접근하면 어떨까요?"

이 구조로 던지면 Sonnet 5가 증명 모드로 안 들어가고, 제 의도에 맞춰서 움직여요. 처음 며칠만 의식적으로 연습하면, 나중엔 자동으로 이 형식으로 프롬프트가 나가더라고요.

모델 성향을 이해하면 도구를 더 잘 쓸 수 있다

Sonnet 5는 '증명하려는' 모델이에요. 이 성향을 거스르는 대신, 협업자로 프레이밍하면 훨씬 나은 결과를 얻을 수 있습니다. 제가 프롬프트 전략을 바꾼 뒤로, Sonnet 5 출력물의 쓸모 있는 비율이 체감상 60%에서 85%로 올랐어요.

여러분도 Sonnet 5 쓰면서 "왜 자꾸 요청 이상으로 고치지?"라는 생각 들면, 프롬프트에 '증명 대상' 신호가 있는지 확인해 보세요. "완벽하게", "문제점 다 찾아줘", "최적화해줘" 같은 표현 대신, "함께 검토 중인데", "제가 놓친 부분 있을까요", "이 방향으로 접근하면 어떨까요" 같은 협업 모드 표현으로 바꿔보세요. LLM 상호작용의 질이 달라질 겁니다.