# 내 워크플로우를 A/B 테스트하지 말아 주세요 > Clean Markdown view of GeekNews topic #27509. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27509](https://news.hada.io/topic?id=27509) - GeekNews Markdown: [https://news.hada.io/topic/27509.md](https://news.hada.io/topic/27509.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-15T07:00:42+09:00 - Updated: 2026-03-15T07:00:42+09:00 - Original source: [backnotprop.com](https://backnotprop.com/blog/do-not-ab-test-my-workflow/) - Points: 4 - Comments: 1 ## Topic Body - **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 시스템의 발전이 지속되더라도, **인간이 통제 가능한 구조**를 유지해야 한다는 점을 재확인 ## Comments ### Comment 53029 - Author: neo - Created: 2026-03-15T07:00:42+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47375682) - 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 위반 소지가 있어 삭제했기 때문임 관련 논의는 [이 댓글](https://news.ycombinator.com/item?id=47375787)에서 확인 가능함 - 두 가지 생각이 있음 1. 오픈소스 도구는 **비자발적 실험**이나 예고 없는 변경 문제를 해결함 2. 하지만 이런 이유로 오픈소스가 **Claude Code 수준의 품질**에 도달하기 어려울 수도 있음 대규모 A/B 테스트를 통한 데이터 기반 개선이 불가능하기 때문임 - 오픈소스라도 항상 **재현 가능**한 건 아님 예를 들어 [man-db의 ‘after midnight’ 이스터에그](https://gitlab.com/man-db/man-db/-/commit/002a6339b1fe8f83f4808022a17e1aa379756d99)처럼 예측 불가능한 변경이 생길 수 있음 의존성도 많아 코드 감사를 실제로 하는 사람은 거의 없음 - “리눅스 커널을 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보다 훨씬 약함** 작은 프로젝트 정도에만 쓸 수 있었음 괜찮은 세팅이 있다면 공유해줬으면 함