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보다 훨씬 약함
    작은 프로젝트 정도에만 쓸 수 있었음
    괜찮은 세팅이 있다면 공유해줬으면 함