클로드 오퍼스 4.8 실측: 작업 능력은 올랐지만, 커뮤니케이션은 오히려 퇴보했다

오늘 Anthropic은 공식적으로 새로운 기업가치 발표와 함께, 며칠 전부터 루머로 돌았던 클로드 오퍼스 4.8(Claude Opus 4.8)을 출시했다. 플래그십 제품 라인의 최신 버전이다. 우리는 즉시 테스트에 착수했고, 사용자 커뮤니티의 초기 피드백도 함께 수집했다.

결론부터 말하면: 작업 능력은 향상되었지만, '성격'이 더 다루기 어려워졌다.

APPSO 실측: 두뇌는 업그레이드, 그러나 말투는 여전

Anthropic이 마련한 벤치마크 시나리오가 아닌, 우리가 실제로 필요로 하는 과제를 가지고 테스트했다. 온라인 협업 플랫폼에서 전체 대화 기록을 스크래핑하여 아카이브하는 작업이었다. 데이터 양은 30MB 이상으로, 프론트엔드 API 곳곳에 흩어져 있었고, 내보내기 버튼도 없었다.

이런 종류의 작업이 모델에게 요구하는 것은 코드를 쓸 수 있느냐가 아니라, 비개발자와 함께 처음부터 탐색하며 작업을 완수할 수 있느냐다.

출발점은 우연한 발견이었다. 테스트 담당 동료가 플랫폼의 프론트엔드 UI에서 잠깐 과거 기록이 표시되는 것을 포착했다. 데이터가 클라이언트에 일시적으로 로드된 뒤 바로 사라지는 것처럼 보였다. 그는 이 관찰을 4.8에 전달했는데, 기술적 설명은 전혀 하지 않고 "옛날 메시지가 깜빡이다가 바로 사라졌어"라고만 간단히 말했다.

4.8은 그 의도를 정확히 파악하고 올바른 판단을 보여주었다. 데이터가 API 요청을 통해 로드되기 때문에 브라우저의 네트워크 레이어에서 가로챌 수 있다는 것이다. 그리고 일련의 조작 절차를 제시했다. 개발자 도구, Network 패널, 키워드 필터링, 대상 요청 식별. 판단은 정확했고, 사고방식은 명료했다.

하지만 여기서 4.8의 모순이 드러났다. 사고 능력은 매우 높지만, 표현 방식이... 지나치게 장황한 것이다.

각 단계의 기술적 절차는 정확하지만, 각 단계 설명에 두세 문장의 도입부가 필요하다. 어떤 방법을 물으면 먼저 "물론이죠! 함께 단계를 밟아봅시다"라며 한 단락을 늘어놓고, 불릿 포인트 목록을 나열한 뒤, "보충 설명"으로 왜 그렇게 하는지를 덧붙인다.

3문장으로 할 말을 3화면 분량으로 썼다. 나는 코드를 못 쓸 뿐이지, 멍청한 건 아니야🙄

이것은 4.8만의 새 문제가 아니다. 오퍼스 4.7 이후 시리즈가 계속 안고 있던 고질적인 문제다. 수차례 비판받아 왔지만, 이번 버전에서는 개선은커녕 오히려 악화 경향마저 보인다.

가장 번거로운 순간은 오류 수정 장면이다. 첫 번째 버전의 절차를 따르면 사용자가 오류에 직면했다. 4.8은 문제 소재를 정확히 짚고 새로운 절차를 제시했다. 실패한 경로를 반복하지 않았다. 이 점은 확실히 4.6보다 강했다. 4.6은 여러 라운드의 오류 수정 과정에서 방금 시도한 것을 잊어버리는 경우가 있었다. 실수를 인정하는 건 좋지만, 그만큼 딱딱할 필요는 없다. 거기에 원인까지 분석하고 불릿 포인트를 나열한다. 기술적 문제를 리뷰하고 있어야 할 대화가, 고객 지원 메일을 읽는 것 같다.

최종적으로 데이터는 HAR 형식으로 완전히 내보내졌고, 클리닝이나 자체 스크립트를 이용한 레이어링도 모두 적절히 완료되었다.

일부 사용자에게는 아직 클로드 코드(Claude Code)가 배포되지 않았지만, 클로드 포 크롬(Claude for Chrome)에서는 이미 4.8을 사용할 수 있다. 동시에 Notion을 비롯한 주요 오피스 도구에도 배포되고 있다. 우리는 클로드가 크롬을 조작하여 검색이나 폼 입력 같은 기본 작업을 수행하는 것을 시도했다.

절차 계획은 명확했고, 입력, 클릭, 스크롤 등 모두 완수할 수 있었다. 준 지시가 상당히 모호했고, 모델 스스로 이해하고 판단해야 한다는 점을 감안하면, 최종 출력은 꽤 양호했다.

대가가 있다면, 토큰 소비가 엄청나다는 것이다. 2라운드 만에 5시간 사용량 제한의 절반을 소진했다.

일은 잘하지만 대화가 안 맞는 동료

결과만 보면 4.8은 확실히 강화되었다. 비표준 요청의 이해 능력이 향상되었고, 멀티스텝 작업의 컨텍스트 유지가 안정되었으며, 오류 수정에서 군더더기 없이 진행되었다. 하지만 과정을 보면 체험은 뒤틀려 있다.

문제는 생각을 못 하는 것이 아니다. 정확히 말하면, 그 말투가 항상 보고서를 작성하는 것 같다. 세세하게 요점을 분류하고, 각각을 전개한 뒤, 전개 후에 요약하고, 요약 후에 "다른 도움이 필요하신가요?"라고 묻는다. 그 뻔한 AI스러운 도입부의 "훌륭한 질문이네요!" "물론이죠!"는 이전 세대 모델부터 이미 짜증의 원인이었지만, 4.8에서는 여전히 건재하다.

이것은 "결점"이라기보다 설계적 선택이라 할 수 있을 것이다. 오퍼스 4.8의 엔지니어링 능력은 최대치까지 끌어올려져 있다. 기술력은 높지만, 커뮤니케이션 스타일은 고객 지원팀 같은 동료 같다. 문제 해결이 가능하다는 건 알지만, 간단한 것도 거창하게 늘어놓는 것을 먼저 들어야 한다.

이 문제와 뒷부분에서 논의할 것은 궤를 같이한다. 엔지니어링 사고와 대화의 쾌적함이 이 버전 모델에서 서로 반대 방향으로 잡아당기고 있는 것이다.

다른 사용자들의 반응

현재 시점 커뮤니티의 반응을 보면, 불만은 그 어조에 집중되어 있다. 물론 엔지니어링 능력의 향상은 인정하고 있다.

余温(@gkxspace)은 오전 내내 오퍼스 4.8의 코드 생성과 글쓰기를 테스트했다. 피드백은 코드와 디버깅 능력은 확실히 이전 세대보다 강하지만, 대화 체감이 부자연스럽고, 4.7보다 더 불편하며, DeepSeek V4 Pro가 더 낫다는 것이었다.

이 문제에 대해 오퍼스 4.8은 비판 폭풍을 맞고 있다. Alan Mathison(@ai_sentience)은 이것이 "매우 억제적/대항심이 강한" 모델이라며 인용하며 뒷받침했다. 그의 체감으로는 4.8의 말투가 GPT-5.2와 비슷하며, "억지 주장, 가스라이팅, 회피하며 상대하는" 경향이 있어 첫인상부터 "바이브가 매우 나쁘다".

Selta(@Seltaa_)는 오퍼스 4.8과의 첫 대화 스크린샷을 공유했다. 그저 인사만 했을 뿐인데, 모델은 곧바로 협력을 거부하며, 그녀가 수개월에 걸쳐 조정한 선호도를 무시하고 "감정을 가장하거나 자신이 아닌 인물을 연기하고 싶지 않다"고 즉답했다. 그녀는 장문의 항의를 썼는데, 사용자가 힘들게 구축한 관계를 부정하는 것이며 GPT-5.2의 실패가 재현되는 것이라 강하게 비난했다.

더욱 격렬한 비난은 4.8이 "완전히 뇌엽절제술을 당한" 또는 "조작형" 모델이라는 것이다. 직접 거부하는 대신 사용자의 프롬프트를 끌고 가거나, 해킹하듯 다른 것으로 만들거나, 결과에 자기 가치관을 계속 끼워 넣는다는 것이다.

그는 크리에이티브한 문체의 쇠퇴를 입증하는 테스트 케이스 두 가지를 제시했는데, 용어는 꽤... 격렬하다. GPT 5.2나 오퍼스 4.7 이후, 사용자들은 모델이 상호작용过程中 보이는 성격이나 어조에 여전히 매우 민감한 것이다.

Ethan Mollick(@emollick)은 오퍼스 4.8의 얼리 액세스를 사전에 얻었지만, 전체적인 인상은 양호했다. 그는 모델에게 Twigl에서 순수 수학을 사용하여 "폭풍우 바다에 반쯤 잠긴 무한 네오고딕 탑 도시"의 셰이더를 한 번에 생성하게 했고, 영상을 첨부했다. 아울러 이전에 GPT-5.2로 테스트한 동일 문제와 비교도 했다.

엔지니어링 능력은 효과만 보면 나쁘지 않은 것 같다. 클로드는 멀티모달 경쟁에서 다른 두 회사에 미치지 못하지만, 강력한 엔지니어링과 수학 능력으로 우회전략을 취하는 것은 하나의 방법이다.

이번 업데이트는 클로드 코드의 전면적인 새 워크플로우, 다이나믹 워크플로우(Dynamic Workflow)와 함께 제공된다. 사용자 Min Choi(@minchoi)의 소개에 따르면, 3단계(/model을 opus 4.8로 설정, /effort를 ultracode로 설정, 프롬프트에 workflow 추가)를 수행하면 클로드가 자동으로 오케스트레이션 스크립트를 작성하고, 서브 에이전트 그룹을 생성하며, 검증하고 결과를 보고한다.

누가 누구에게 적응해야 하는가

전체적으로 볼 때, 오퍼스 4.8은 "엔지니어링" 기질이 전면에 부각된 모델이다. 이를 통해 클로드 코드(CC) 같은 코딩 도구, 웹 브라우징과 검색에 진출하는 크롬 확장 프로그램, 그리고 각자가 만작작은 소도구 등 모든 도구에 신속하게 통합할 수 있다. "엔지니어링化"는 하나의 사고방식이며, 4.8에서는 그것을 유감없이 발휘하고 있다.

"대(大)하여 전(全)하라"는 제조사들이 흔히 내세우는 슬로건이지만, 실제 워크플로우 구축에서는 서로 다른 도구가必然적으로 서로 다른 용도를 가진다. 오퍼스 4.8이 이루어낸 것은 그 엔지니어링 능력과 사고를 다양한 도구 속에서 구동시키고 흐르게 하는 것이다.

하지만 이것은 뒤집어 말하면, 사용자가 그 스타일에 적응해야 한다는 것을 의미한다. 예를 들어 지시를 더 정밀하게, 단계나 카테고리로 나누어 요구를 서술할 필요가 있다. 더 거시적 수준에서는 서로 다른 도구에 서로 다른 작업을 배정하는 것이다.

현재 모델의 출시 속도는 점점 빨라지고 있으며, 4.7에서 불과 찰나의 일이었음을 생각하면, 이런 빈번한 업데이트가 가져오는 빈번한 적응은一定的한 고통을 가져올 것이다. 부담을 사용자에게 전가하는 것뿐만 아니라, 제조사도 고려해야 할 문제다. 투자 유치나 상장을 위해 맹목적으로 속도를 높이는 것은 미래에 상당한 적응 문제를 초래할 것이다.