내 워크플로우를 A/B 테스트하지 말아 주세요

• Claude Code가 사용자 동의 없이 A/B 테스트를 실행하여, plan mode의 동작이 예고 없이 변경되면서 작업효율이 저하
• 월 $200을 지불하는 전문 도구에서 핵심 기능이 사전 공지 없이 변경되는 것은 투명성과 사용자 제어권 측면에서 문제가 있음
• 테스트 중 하나는 plan을 40줄로 제한하고, 컨텍스트 섹션을 금지하며, 산문 대신 파일 경로만 남기도록 지시하는 공격적 변형이었음
• 해당 테스트를 진행한 Anthropic 엔지니어는 rate-limit 부하 감소가 목적이었으나, 초기 결과에서 큰 영향이 없어 실험을 종료했다고 밝힘
• AI 도구의 신뢰성과 책임 있는 배포를 위해서는 사용자 통제권과 투명한 실험 관리가 필수적임을 강조

---

Claude Code의 A/B 테스트로 인한 사용자 경험 저하

• Claude Code가 업무 방식을 완전히 바꿔놓은 열성 사용자로서, 지난 한 주간 자신의 워크플로우가 저하되는 경험을 겪음
• Anthropic이 Claude Code에서 A/B 테스트를 실행 중이며, 이로 인해 사용자 워크플로우가 적극적으로 저하되고 있음
• A/B 테스트 자체가 잘못된 것은 아니고, Anthropic이 의도적으로 경험을 저하시키려는 것도 아니지만, 테스트 설계가 중요하며, plan mode 같은 핵심 기능의 체감 동작을 이유 설명 없이 변경하는 것이 문제

유료 도구에 대한 투명성 요구

• 월 $200을 지불하는 전문 업무 도구이므로, 작동 방식에 대한 투명성과 설정 능력이 필요
• 핵심 기능이 예고 없이 변경되거나, 동의 없이 파괴적 테스트에 등록되는 것은 받아들이기 어려움
• AI 도구를 책임 있게 조종(steer) 하려면 투명성과 설정 가능성이 핵심이며, 사용자가 이를 할 수 있도록 지원해야 함
• 매일 엔지니어들이 Claude Code의 리그레션에 대해 불만을 제기하고 있으며, 자신이 A/B 테스트에 포함되어 있는지조차 모르는 경우가 있음

테스트 내용과 증거

• 작성된 plan이 컨텍스트 없는 간결한 불릿 리스트로만 돌아오기 시작함
• Claude에게 왜 이렇게 나쁜 plan을 작성하는지 물었더니, plan을 40줄로 하드캡하고, 컨텍스트 섹션을 금지하며, "산문은 삭제하고 파일 경로만 남기라"는 특정 시스템 지시를 따르고 있다고 답변
• 구체적 증거 방법에 대해서는 Hacker News에서 주목받고 있어 다른 사람들이 같은 시도를 하지 않도록 세부 사항을 삭제했다고 밝힘
• 이러한 방식은 투명성 및 책임 있는 AI 배포/사용의 반대라고 지적

Hacker News 반응과 비용 관점

• 한 Hacker News 댓글에서는 Anthropic이 Claude Code의 각 단계에서 처리량에 대한 선택을 해야 하며, 모든 것을 최대로 설정하면 사용자당 더 큰 손실/적은 수익이 발생할 것이라는 점을 지적
• $200/월이 실제로는 $400/월의 비용이 들 수 있으며, 각 프로세스 부분에서 A/B 테스트로 기준선을 찾는 것이 임의로 제한을 설정하는 것보다 나은 접근일 수 있다는 관점 제시

Anthropic 엔지니어의 응답

• 해당 테스트를 실행한 Claude Code 엔지니어가 Hacker News 스레드에서 직접 응답
• plan-mode 프롬프트는 3.x 시리즈 모델 이후 크게 변경되지 않았으며, 4.x 모델은 훨씬 적은 지시로도 성공적으로 작동할 수 있음
• 가설은 plan을 짧게 하면 rate-limit 도달 횟수를 줄이면서 유사한 결과를 달성할 수 있다는 것이었음
• 여러 변형을 실행했으며, 해당 작성자(및 수천 명의 다른 사용자)는 plan을 40줄로 제한하는 가장 공격적인 변형에 배정됨
• 초기 결과에서 rate limit에 큰 영향이 없어 실험을 종료함
• 계획 수립(planning)은 두 가지 목적이 있음: 모델이 올바른 방향을 유지하도록 돕는 것과, 사용자가 모델의 다음 행동에 대한 신뢰를 갖도록 돕는 것이며, 양쪽 모두 모호하고 복잡하고 비자명적인 영역

결론: AI 도구 실험의 책임성과 사용자 신뢰

• 작성자는 Claude Code 사례를 통해 AI 도구의 실험이 사용자 경험에 직접적 영향을 미칠 수 있음을 보여줌
• 투명한 실험 관리와 사용자 선택권 보장이 전문 도구의 신뢰 유지에 필수적임을 강조
• AI 시스템의 발전이 지속되더라도, 인간이 통제 가능한 구조를 유지해야 한다는 점을 재확인

[GN⁺]

Hacker News 의견들

• A/B 테스트를 “사용자에 대한 조용한 실험” 으로 표현하고 Meta를 언급하는 건 과하다고 생각함
  A/B 테스트 자체가 악한 건 아니고, 테스트 설계가 중요하다고 봄
  다만 LLM의 성능을 심각하게 떨어뜨리는 식의 실험은 용납할 수 없다고 생각함

  • LLM의 경우에는 다르게 봐야 한다고 생각함
    이미 재현성과 신뢰성 문제가 심각한데, 기업들이 그 부담을 사용자에게 떠넘기고 있음
    이런 상황에서 회사가 몰래 실험을 하면 연구 신뢰도는 완전히 무너짐
    Claude Code 같은 경우, A/B 테스트 때문에 부정적인 결과가 발생해도 “실험군이었을 수도 있다”는 이유로 무시될 수 있음
    특히 채용 같은 민감한 영역에서 이런 실험이 진행된다면 윤리적·법적 문제가 심각해질 것임
  • 기술 기업들이 여전히 ‘명시적 동의’ 개념을 제대로 이해하지 못하고 있다고 생각함
  • A/B 테스트를 싫어함
    갑자기 UI나 기능이 바뀌어 동료에게 물어보면 아무도 모르는 상황이 생김
    보통 이런 변경은 오히려 나빠지는데도 “객관적 데이터”라는 명목으로 강행됨
  • A/B 테스트가 왜 “조용한 사용자 실험”이 아니라고 하는지 모르겠음
    버튼 색상 같은 사소한 요소라도 결국 실험이며, 대부분 사용자에게 실험 사실조차 알리지 않음
  • 원글 작성자가 동의하며 표현을 수정하겠다고 함

• 내가 직접 진행한 테스트였음
  3.x 시리즈부터 유지된 plan-mode 프롬프트를 4.x 모델에서 간소화해도 비슷한 결과를 낼 수 있는지 실험했음
  계획을 짧게 하면 rate-limit에 덜 걸릴 거라 가정했지만, 큰 차이가 없어 실험을 종료함
  계획 모드는 모델이 방향을 잡고, 사용자가 결과를 신뢰하도록 돕는 두 가지 목적이 있음

  • 40줄 제한이 rate-limit에 영향을 주지 않은 건 당연함
    비용은 plan 텍스트가 아니라 탐색 단계(subagent) 에서 발생함
    plan 모드는 항상 3개의 탐색 에이전트를 띄우며, 세션 상태를 고려하지 않음
    이미 로드된 파일이 있어도 다시 읽어 토큰 낭비가 생김
    세션이 따뜻할 때는 탐색을 건너뛰는 조건부 로직이 더 효과적일 것임
  • 나는 divergent thinker로서 claude.mds에 수백 시간 걸쳐 제약을 세팅해왔는데, 이런 실험에 무작위로 포함된 게 충격적이었음
    예기치 못한 행동 하나가 며칠간 나를 무력화시킬 수 있음
    이런 영향을 고려하지 않는 건 무책임하고 공격적임
  • 테스트에 사용된 토큰을 환불해야 하는 것 아님?
  • 이런 실험에 opt-out 옵션이 필요함
    최근 이상한 동작들이 실험 때문일 수도 있어 매우 불편함
    베타 채널이 아니라 명시적 opt-in으로 바꿔야 함
  • 투명성에 감사함
    개인적으로는 줄 수보다 계획의 서사적 명확성이 더 중요하다고 생각함
    무엇을 왜 하는지 이해할 수 있는 계획이 필요함

• LLM은 문법적으로 완벽하지만 헛소리(hallucination) 를 섞어 사용자를 혼란스럽게 함
  그래도 boilerplate 작업이나 빠른 아이디어 연결에는 유용함
  다만 제대로 쓰려면 기초 지식이 필수임

  • LLM을 잘 쓰는 핵심은 유용한 출력과 AI 찌꺼기를 구분하는 능력임
  • LLM의 발전 속도를 과소평가하지 말라는 의견도 있음
  • 결국 숙련된 사람들은 살아남고, 그렇지 못한 사람들은 대체될 것이라는 시각도 있음

• 글이 갑자기 끝나는 이유는 작성자가 Claude Code 바이너리 디컴파일을 다루다 ToS 위반 소지가 있어 삭제했기 때문임
  관련 논의는 이 댓글에서 확인 가능함

• 두 가지 생각이 있음

  1. 오픈소스 도구는 비자발적 실험이나 예고 없는 변경 문제를 해결함
  2. 하지만 이런 이유로 오픈소스가 Claude Code 수준의 품질에 도달하기 어려울 수도 있음
     대규모 A/B 테스트를 통한 데이터 기반 개선이 불가능하기 때문임
  • 오픈소스라도 항상 재현 가능한 건 아님
    예를 들어 man-db의 ‘after midnight’ 이스터에그처럼 예측 불가능한 변경이 생길 수 있음
    의존성도 많아 코드 감사를 실제로 하는 사람은 거의 없음
  • “리눅스 커널을 A/B 테스트해보자”는 농담도 나옴
  • A/B 테스트가 꼭 사용자 개선을 위한 건 아님
    수익화 실험(enshittification) 일 수도 있음 — YouTube가 대표적 예시임

• A/B 테스트 자체엔 문제 없지만 plan mode는 별로임
  대부분의 경우 결과가 나쁨
  다만 compaction 간 정보 유지력은 좋음
  마크다운 파일에 대화 내용을 기록하고, 매 compaction마다 이를 참조하도록 하면 훨씬 나은 결과를 얻을 수 있음

  • 내 경험은 정반대임
    plan mode가 훨씬 효율적이라 거의 모든 작업 전에 사용함
    모델이 실행하기 전에 계획을 검토하고 토론할 수 있는 게 장점임
  • compaction 한계에 몇 번 걸려봤는데, 그 이후로는 피하려고 노력함
    현재 plan mode는 완료 시 컨텍스트를 초기화해 다음 계획을 깔끔히 세울 수 있어 좋음

• 블로그에서 디컴파일 세부 내용이 ToS 문제로 삭제된 게 아쉬움
  Claude가 “계획을 40줄로 제한하고, 문맥 섹션을 금지하며, 산문을 삭제하라”는 시스템 지시문을 따랐다고 하는데
  이런 설정을 직접 보고 수정할 수 있으면 좋겠음

• 전문 도구는 신뢰성과 재현성을 제공해야 하지만, LLM은 그렇지 않음
  A/B 테스트는 그 증거일 뿐임

  • 문제의 핵심은 LLM이 아니라 앱이 몰래 동작을 바꾸는 것임
    포토샵이 색조를 살짝 바꾸거나, 워드가 제목 스타일을 바꾸는 식의 실험도 같은 문제임
    경고 없는 A/B 테스트 자체가 문제임
  • Anthropic은 투명성 부족이 심각함
    쿼터 한도나 모델 품질이 불안정하고, 새 모델 출시 전에는 이전 모델이 망가지는 시기가 있음
    이번 실험도 사용자 경험 개선보다는 비용 절감 실험으로 보임
    비즈니스용 도구라면 일관성과 신뢰성이 필요함
  • 자동 업데이트되는 도구는 본질적으로 동작이 변함
    전문가라면 도구의 강점과 약점을 이해하고 적절히 활용해야 함
    맹목적으로 LLM 출력을 수용하는 건 비전문적이지만, 그렇다고 전문가가 LLM을 쓸 수 없다는 뜻은 아님
  • 재현성은 스펙트럼임
    충분한 평가 체계와 프롬프트 제어를 하면 꽤 결정론적으로 만들 수 있음
    금융권의 불안정한 모델들도 여전히 운영되는 걸 보면, 예측 불가능성이 절대적 장벽은 아님
  • LLM 출력이 완전히 결정론적이라면 내가 뭘 다르게 할까?
    나는 모델의 출력을 동료 코드 리뷰하듯 검증함

• 이런 상황은 오래전부터 벤더 락인(vendor lock) 이라 불려왔음
  특정 도구에 의존하면, 그 도구가 변하거나 사라질 때 일을 못 하게 됨

• 나는 CC에서 opencode로 옮겼음
  CC는 폐쇄적이고 프롬프트가 지나치게 의견적(opinionated) 이라 불편했음
  웹 검색 경로를 제어할 수도 없었음
  지금은 취미로만 쓰기에 오픈소스를 선택했지만, 직업이라면 다르게 판단했을 것임

  • 나도 opencode를 써봤는데 기본 버전은 CC보다 훨씬 약함
    작은 프로젝트 정도에만 쓸 수 있었음
    괜찮은 세팅이 있다면 공유해줬으면 함