Claude Code에서 진행되는 A/B 테스트가 핵심 기능의 체감 동작을 바꾸며 업무 흐름을 망가뜨릴 수 있고, 투명성과 설정 가능성이 전문 도구에 필수라는 주장.
Mar 12, 2026
Claude Code는 내가 일하는 방식을 완전히 바꿔 놓았고, 나는 첫날부터 Anthropic과 창업자들의 연구를 크게 지지해 왔다. 지난 한 주 동안 내 워크플로우가 저하되는 것을 직접 겪는 건 답답했고, 이 글은 그 답답함 속에서 쓰였다. 이후 나는 더 정확하고 공정한 톤이 되도록 글을 수정했고, 내 주장에 대한 세부 사항은 제거했다. 지금 이 글이 Hacker News에서 1위가 아니었다면 아마 그냥 삭제했을 것이다.
Anthropic이 Claude Code에서 내 워크플로우를 실제로 저하시키는 A/B 테스트를 돌리고 있다. 나는 이를 거부(옵트아웃)할 수 있으면 좋겠다.
나는 A/B 테스트가 본질적으로 잘못이라고 생각하지 않는다. Anthropic이 누군가의 경험을 의도적으로 나쁘게 만들기 위해 이 일을 하고 있다고도 생각하지 않는다. 그들은 분명 최적화하려고 한다. 하지만 테스트 설계가 중요하며, plan mode 같은 핵심 기능의 체감 동작을 이유도 모른 채 바꾸는 것은 내 경험을 저하시킨다.
나는 Claude Code에 매달 200달러를 낸다. 이건 내가 내 일을 하기 위해 쓰는 전문 도구이고, 나는 이것이 어떻게 작동하는지에 대한 투명성과 이를 구성할 수 있는 능력이 필요하다. 내가 필요하지 않은 것은, 애플리케이션의 핵심 기능이 예고 없이 바뀌거나, 동의(옵트인) 없이 방해가 되는 테스트에 가입되는 것이다. 우리는 이러한 도구(AI)를 어떻게 조향하는지에 대해 책임감 있어야 하고, 그렇게 할 수 있도록 권한을 부여받아야 한다. 투명성은 그 핵심의 일부다. 설정 가능성 또한 그 핵심의 일부다.
매일 엔지니어들은 Claude Code에서의 회귀(regression)를 불평한다. 때로는 당신이 A/B 테스트에 들어가 있으면서도 그 사실을 모를 수 있다.
[REMOVED] Claude가 특정 시스템 지시사항을 따르고 있다고 말했을 때, 나는 그것을 확인하고 싶었다. 그 시스템 프롬프트가 실제로 존재하는지 보고 싶었다. 나는 누구든 비슷한 길로 가도록 부추기고 싶지 않으며, 이 글이 Hacker News에서 주목을 받고 있기 때문에 세부 사항을 삭제하기로 했다.
내 계획(plans)은 맥락 없이 간결한 불릿 목록으로 돌아오기 시작했다. 나는 Claude에게 왜 이렇게 형편없는 계획을 쓰냐고 물었다. 그러자 Claude는 계획을 40줄로 강제 상한하고, 컨텍스트 섹션을 금지하며, “파일 경로가 아니라 산문을 삭제하라”는 특정 시스템 지시사항을 따르고 있다고 말했다.
이것은 투명성과 책임감 있는 AI 배포/사용의 정반대처럼 느껴진다. AI 도구에는 더 많은 투명성이 필요하지, 더 적은 투명성이 필요한 게 아니다. 나는 인간이 루프 안에 있는 상태로 내 프로세스를 소유하고 AI를 이끌 수 있는 능력이 필요하다.
나는 Claude Code 같은 것을 배포하는 데 무엇이 필요한지나 그 뒤의 비용 모델이 어떤지에 대한 전문가는 아니다. 나는 이 Hacker News 댓글이 고려할 만한 통찰을 제공한다고 생각한다:
아마도 Anthropic은 Claude Code의 각 단계가 얼마나 많은 처리(프로세싱)를 쓰는지에 대해 많은 선택을 해야 할 것이다. 모든 것을 최대치로 올리면, 사용자 한 명당 손실이 더 커지거나 이익이 줄어들 것이다. 월 200달러가 월 400달러의 비용이 들 수도 있다. 프로세스의 각 부분에 대해 A/B 테스트를 수행해 어디에 선을 그을지(아마도 작업과 사용자에 따라) 파악하는 것이, 임의로 한계를 정하는 것보다 더 나은 방법처럼 보인다.
테스트를 진행한 Claude Code 엔지니어는 스레드에서 이렇게 답했다:
안녕하세요, 이건 제가 한 테스트였습니다! plan-mode 프롬프트는 3.x 시리즈 모델 이후로 대체로 변하지 않았고, 이제 4.x 모델은 훨씬 적은 지시만으로도 성공적으로 수행할 수 있습니다. 제 가설은 계획을 짧게 하면 rate-limit에 걸리는 일이 줄어드는 동시에, 사람들이 비슷한 결과를 여전히 얻을 수 있게 도울 것이라는 것이었습니다. 저는 몇 가지 변형을 돌렸고, 작성자(그리고 수천 명 정도의 다른 사람들)는 가장 공격적인 버전을 받았는데, 계획을 40줄로 제한하는 것이었습니다. 초기 결과는 rate limit에 큰 영향을 보여주지 않아서 실험을 종료했습니다. 계획(planning)은 두 가지 목적을 가집니다: 모델이 궤도를 유지하도록 돕는 것과, 모델이 곧 하려는 일에 대해 사용자가 자신감을 갖도록 돕는 것입니다. 이 두 측면 모두 모호하고, 복잡하며, 자명하지 않습니다!
© 2026 Mike Ramos. All rights reserved.
