요새 Claude Code 좀 이상하지 않나요

Claude Code 사용하다보면 이런 경험이 다들 있으실 겁니다. 분명 Opus 4.6, Sonnet 4.6을 쓰고 있는데, 코드 검증도 똑바로 안 하고 자신 있게 틀린 답을 내놓을 때. 존재하지 않는 API 버전을 지어내거나, 읽지도 않은 파일 구조를 단정하거나, 아무것도 확인 안 하고 "이 부분은 정상입니다"라고 선언하고는 실제로는 에러가 그대로 남아있는 식인 일들.

근데 이게 개인의 설정 문제가 아니었습니다. 2026년 2월부터 누적된 제품 회귀이고, Anthropic도 공식적으로 인정한 문제였습니다. 다행히 이 문제는 환경 변수 하나로 임시 우회할 수 있습니다.

해결책

export CLAUDE_CODE_EFFORT_LEVEL=high
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

Max 200$/100$ 요금제를 사용하신다면 CLAUDE_CODE_EFFORT_LEVEL=max로 사용하셔도 좋습니다.

첫 번째 명령어는 effort를 high로 고정하는 겁니다. 기본값이 medium으로 낮춰졌기 때문에, 명시적으로 올려줘야 이전 수준의 추론 깊이를 되찾습니다.

두 번째는 adaptive thinking을 비활성화하고 고정 thinking budget으로 돌리는 겁니다. 모델이 턴마다 '이걸 생각할까 말까'를 판단하는게 아니라, 매번 일정한 추론 토큰을 사용하게 하는겁니다. Boris Cherny가 공식 워크어라운드로 제시한 설정입니다.

영구적인 적용은 ~/.zshrc or ~/.bashrc에 추가하고 쉘을 재시작하시면 됩니다.

echo 'export CLAUDE_CODE_EFFORT_LEVEL=high' >> ~/.zshrc
echo 'export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1' >> ~/.zshrc
source ~/.zshrc

설정이 적용됐는지는 Claude Code를 실행했을 때 로고 옆에 "with high effort"가 표시되는지로 확인할 수 있습니다.

배경

이게 이렇게 된 이유가 있습니다.

Anthropic은 2월에 Opus 4.6을 출시하면서 adaptive thinking을 기본 활성화했습니다. 이 기능은 모델이 매 턴마다 "이 요청이 얼마나 복잡한가"를 스스로 판단하고, 복잡하다고 느끼면 깊게, 간단해보이면 얕게 생각합니다. (아예 넘길수도 있구요.) 이론적으로는 토큰 효율과 품질을 동시에 잡는 전략이죠.

문제는 실제 동작입니다. Claude Code 팀 리드 Boris Cherny가 직접 밝혔는데, 특정 턴에서 모델이 thinking을 0 토큰으로 할당하는 경우가 생깁니다. 생각을 전혀 하지 않은 상태에서 답변을 생성하니 환각이 그대로 나오는데, 문제는 모델이 이 답변에 확신하는 겁니다. 그래서 생각 안 한 턴에서 자신만만한 거짓말이 섞여 나오는 패턴이 반복됩니다.

여기에 3월 3일에 기본 effort 수준이 high에서 medium으로 낮춰졌고, 3월 8일부터 thinking redaction이 단계적으로 롤아웃됐습니다. 이런 변경이 누적되면서 복잡한 코딩 작업에서 품질이 엄청 떨어진거죠...

한 커뮤니티 분석에 따르면 코드 수정 전 리서치 행위가 70% 감소했고, 사용자가 모델을 중단시키는 빈도가 12배 증가했고, 벤치마크상 점수는 유지되지만, 실사용에서는 망가진 상태라고 합니다.

해결책은 위에 적힌대로 하시면 됩니다.

주의 사항

토큰 소진이 엄청 빨라집니다. Medium effort + adaptive 조합은 원래 토큰을 아끼는 방향으로 최적화돼 있어요. 이걸 끄면 당연히 같은 작업에 더 많은 토큰이 소비됩니다.

Pro ($20) 플랜 사용자분들은 특히 주의하셔야 해요. 5시간당 약 44,000 토큰 제한에 걸려있는데, 여기에 max effort + adaptive 끄기 조합을 돌리면 한두 시간 안에 제한에 도달할 수 있습니다. Pro 쓰시는 분들은 위에서 알려드린대로 high까지만 올리는 게 현실적입니다. Max 플랜이라고 해도 effort를 max로 박아두는 건 복잡한 리팩토링이나 디버깅 세션에만 쓰고, 간단한 작업(git status, 파일 읽기, 짧은 질문 같은 것들)은 기본값으로 두는 게 좋아요.

CLAUDE_CODE_EFFORT_LEVEL 환경변수는 모든 다른 설정을 덮어씁니다. 평소에 슬래시 커맨드 /effort로 세션별 조정하던 습관이 있으시다면, 환경변수 설정한 순간부터 그 커맨드들이 무시됩니다. 세션별로 유동적으로 제어하고 싶으시면 환경변수 대신 --effort 플래그나 /effort 커맨드 쓰시는 게 낫습니다.

그리고 이게 근본 해결은 아닙니다. 이 설정은 Anthropic이 공식 문서에 "interim workaround(임시 우회)"라고 대놓고 써놓은 임시방편이에요. Adaptive thinking의 under-allocation 문제는 아직 조사 중이고, 향후 모델 업데이트에서 수정될 가능성이 있습니다. 그러니까 이 설정을 평생 유지해야 한다는 뜻이 아니라, 지금 시점의 임시 방어선 정도로 생각하시면 됩니다.

작업 종류별 설정 전략

단일 설정으로 모든 작업을 커버하려고 하지 마시고, 작업 성격에 맞춰서 조정하시는 게 훨씬 효율적입니다.

복잡한 리팩토링, 멀티 파일 디버깅, 아키텍처 설계 같은 고부하 작업에는 max effort + adaptive 끄기 조합이 맞습니다. 토큰을 더 쓰더라도 환각 없는 일관된 품질이 중요한 영역이죠.

커밋 메시지 작성, 코드 리뷰, 간단한 Q&A 같은 일상 작업은 high effort 정도면 충분해요. Adaptive는 켜둬도 됩니다. 이런 작업에서는 under-allocation 문제가 덜 치명적이거든요.

Subagent나 자동화 파이프라인 내부에서 단순 작업을 반복하는 경우에는 오히려 low effort가 적절합니다. Subagent의 frontmatter에 effort: low를 명시하면 해당 agent가 실행될 때만 낮은 수준으로 동작합니다.

마치며

AI 도구 품질이 공지 없이 조용히 바뀌는 상황은 사용자 입장에서 진짜 답답한 일입니다. 벤치마크 수치와 실사용 체감 사이의 간극, 소리 소문 없이 진행되는 기본값 변경, 숨겨진 환경변수로만 우회 가능한 설정들... 이런 게 쌓이면 내가 뭘 잘못하고 있나 를 계속 디버깅하게 되죠.

요즘 Anthropic 참 이상하네요. Claude Code 유출이나 Mythos 배포 안 하는 거도 이상하고, 전체적으로 토큰 용량도 체감상 상당히 많이 줄었기도 하구요. Threads 같은 플랫폼에선 OpenAI의 Codex가 많이 바이럴되기도 하던데, 요즘 행보의 연쇄 작용이겠죠.

그래도 이번 adaptive thinking 이슈는 최소한 Anthropic이 공식 문서에 해결책을 등재했고, 팀 리드가 공개적으로 인정했다는 점에서 드러난 케이스입니다. 이 글이 같은 문제 겪으시는 분들한테 도움이 되면 좋겠어요.

참고 링크

• Anthropic 공식 문서: Model Configuration
• Boris Cherny HN 답변 스레드
• Claude Code Feb–Mar 2026 기술 분석 (dev.to)

React는 번들 사이즈만 크고 Virtual DOM? 오버헤드죠?

jQuery는 무려 10년 넘게 사용되는 최고의 라이브러리입니다. 애초에 지금 React, Next.js 이런 거 다 굳이에요, 굳이.

아니 아직도 깃허브에서 무려 59.6k 스타를 가지고 있고요???

JavaScript 라이브러리 중에서 무려 사용률이 70%가 넘습니다. 이걸 왜 안 씁니까? 저희 소수가 되지 말고 다수가 됩시다. 지금 리액트 너무 홍대병이에요.

뭣보다 이거 2025년 기준입니다. 글 쓴 시점에서 방금 사진 찍어온거에요. 여기에 들어가셔서 확인도 가능합니다.

그냥 잔잔하게 저희 나대지 말고 다시 jQuery 씁시다...

.

.

.

.

.

죄송합닏다. 헛소리는 줄이고 본론으로 들어가겠습니다.

Why do you dislike jQuery?

근데 jQuery 왜 싫어하세요?

사실 최근에 개발을 시작하셨다면, 특히 요즘 AI로 바이브 코딩 하시는 분들은 애초에 jQuery를 모르실 수도 있습니다. 그니까 '할 줄 모른다'가 아니라 '그게 뭔데?'를 말하는거에요.

jQuery를 안 쓰는 분들의 의견을 제가 인터넷 바다에서 탐색을 해왔습니다. 대부분 이유가 비슷하시더라구요.

1. 자유롭고 쉬운 코드 구조가 스파게티 코드를 유발함.
2. 대부분의 jQuery 기능을 ES6+ JavaScript가 해결함.
3. Virtual DOM 기반 프레임워크와 철학 자체가 충돌. (DOM 직접 조작 패러다임)
4. 그저 레거시.

따지고 보면 다 팩트입니다. 저는 JavaScript 말고 jQuery 강의와 함께 개발에 입문을 했었는데, 쉽지만 자유로운 코드 구조가 존재하는 거도 팩트고, 애초에 jQuery의 대표적인 기능인 $() 마저 이제 ES6+ 에서 다른 형태로 사용할 수 있습니다.

예시를 들어볼까요.

선택자 $()는 document.querySelector()로 대체됐습니다.

// jQuery
$('.btn')
$('#app')

// ES6+
document.querySelectorAll('.btn')
document.querySelector('#app')

클래스 조작은 선택한 요소에 .classList로 접근할 수 있고요.

// jQuery
$(el).addClass('active')
$(el).removeClass('active')
$(el).toggleClass('active')
$(el).hasClass('active')

// ES6+
el.classList.add('active')
el.classList.remove('active')
el.classList.toggle('active')
el.classList.contains('active')

jQuery의 대표 기능인 Ajax는 Fetch API로 더 간결하게 쓸 수 있고요?

// jQuery
$.ajax({ url: '/api', method: 'GET' })
$.get('/api')
$.post('/api', data)

// ES6+
fetch('/api')
fetch('/api', { method: 'POST', body: JSON.stringify(data) })

DOM 조작이나 애니메이션도 네이티브 API로 대체됐습니다.

// jQuery
$(el).attr('href')
$(el).attr('href', 'url')
$(el).text()
$(el).html()
$(el).append(child)
$(el).remove()

$(el).fadeIn()
$(el).animate({ opacity: 0 }, 500)

// ES6+
el.getAttribute('href')
el.setAttribute('href', 'url')
el.textContent
el.innerHTML
el.append(child)
el.remove()

el.animate([{ opacity: 0 }, { opacity: 1 }], { duration: 500 })
// 또는 CSS transition/animation 활용

솔직히 애니메이션은 ES6+가 더 장황하고, 문법 자체도 jQuery가 더 단순하긴 해요. 근데 외부 의존성 없이 대부분의 기능이 대체된 현 시점에서, jQuery를 굳이 다시 쓰긴 힘든 게 사실입니다.

근데 솔직히...

레거시 같긴 해요. 근데 아쉬운 점도 분명히 있는 거 같습니다.

jQuery는 장점도 가지고 있는데 이런 큰 단점들 때문에 특유의 장점이 완전히 묻히네요.

위에 코드를 보시면 아실 수 있듯 솔직히 JavaScript 진영에 입문하기 위해서는 ES6+이 좀 장황하게 느껴질 수도 있습니다. 그리고 React처럼 Virtual DOM 원리를 쓰는 라이브러리가 아니라면 jQuery 정도는 그냥 깔아서 문법 짧게 쓰기 좋구요.

그냥 예시를 봅시다!

// jQuery
$('.card')
  .addClass('active')
  .removeClass('hidden')
  .find('.title')
  .text('새 제목')
  .end()
  .find('.content')
  .html('<p>새 내용</p>')
  .end()
  .fadeIn()
  .delay(1000)
  .slideUp()

// ES6+
const card = document.querySelector('.card')
card.classList.add('active')
card.classList.remove('hidden')
card.querySelector('.title').textContent = '새 제목'
card.querySelector('.content').innerHTML = '<p>새 내용</p>'
card.style.display = 'block'
card.animate([{ opacity: 0 }, { opacity: 1 }], { duration: 400 })
  .finished.then(() => {
    return new Promise(resolve => setTimeout(resolve, 1000))
  })
  .then(() => {
    card.animate([
      { height: card.offsetHeight + 'px' },
      { height: 0 }
    ], { duration: 400 }).finished.then(() => {
      card.style.display = 'none'
    })
  })

한눈에 봐도 jQuery가 간단해보이지 않나요. 애초에 저런 코드가 나오는 거 자체가 코드를 못 짠 거긴 하지만 저런 식으로 ES6+에 부딪힐 빠엔 혼자할 땐 jQuery를 사용하는게 더 편해보입니다.

아깝다 아까워 이런 그렇게 구리지 않은 친구가 레거시가 되다니. 트렌드가 무섭죠? 곧 React도 이렇게 되려나 ~

근데 반전이 있습니다. 사실 꽤 화제가 됐던 내용이기도 해요.

얘 아직도 업데이트 되고 있습니다.

jQuery 공식 사이트 들어가면 볼 수 있는 글자가 있습니다.

jQuery 4.0 is coming soon! Prepare by ~~...

다시 돌아온답니다. 4.0 버전으로요. 이제 다시 React의 시대는 가겠네요 ㅇㅇ 저희 다시 이거 씁시다.

뭐가 바껴서 돌아오는지 제가 정리를 해봤습니다.

jQuery 4.0 주요 변경사항

묘하게 괜찮은 거 같음.

IE 지원 이제 필요 없죠? 누가 씁니까. 앵간해선 안 쓰는 브라우저 관련 기능 지워서 용량 관리 하는 거 상당히 좋아보입니다~ 당연히 레거시 브라우저 관련도 엄청 좋아보이구요.

소스 구조도 현대적으로 바뀌었고, 슬림 빌드 추가도 좋은 거 같습니다. $() 문법만 쓰고 싶을 때 쓰면 좋을 듯요.

제거된 API는 다 이제 대체됐기에 그런 거라 생각이 되고, 추가된 기능도 상당합니다.

현대적이에요.

근데 전 딱히 안 내키네요;

이게 그래서 무슨 의미를 가지는가?

사실 그렇게 큰 의미는 없습니다. 앵간한 스타트업이나 신생 프로젝트에선 당연하듯 jQuery는 고려하지도 않을 거고, 옛날 레거시 프로젝트나 취미로 개발을 하는게 아니라면 굳이일 겁니다.

레거시로 남아있던 상징과도 같던 jQuery가 오히려 레거시와는 정반대의 행보를 보이는게 상당히 흥미롭기도 하네요.

그리고 현재 jQuery의 취급을 나중에 React나 Next.js 같은 프레임워크가 이어 받을 수도 있으려나 잘 모르겠네요.

메인 프로젝트에 사용하긴 솔직히 안 땡기는데, 사이드 프로젝트에 한 번 써보는 건 나쁘지 않은 선택이 될 수도 있을 거 같네요. 긴 글 읽어주셔서 감사합니다.ㅎㅎ 아니아니 좀 더 이어쓸게요

jQuery 4.0 출시

다운로드 버튼 눌러도 여기선 다운로드 안 됩니다.

결국엔 출시를 했습니다. jQuery가 업데이트를 했다구요!! 여러가지 변경 사항이 적용을 했고, 해커뉴스 같은 커뮤니티에서도 반응이 긍정적입니다.

다시 태어난 제이쿼리를 사용해서 이 친구를 22세기까지 사용해봅시다.

나도 해보고 싶다!!!!

라는 생각을 가지게 됐습니다.

봤던 문서 1 / 봤던 문서 2

근데 막상 제가 뭐 기여할만한 오픈 소스가 없었어요... 그래서 이 목표를 좌절할 때 쯤...

이런 오타를 찾게 됐었습니다. 평소에도 React 문서를 자주 보던 저한테 이런 오타는 엄청나게 크고 불편하고 나쁜 요소 중 하나였어요.

이걸 수정하고 싶었어요. 어차피 이 문서도 오픈 소스인데? 이걸 수정하면 나도 오픈 소스에 기여한 멋진 사람이 될 수 있을 거 같았습니다!!

바로 실행

일단 어떻게 하는지 알아보기 위해서 한국어 리액트 공식 문서 레포지토리를 돌아다녀 봤습니다. 이슈들이랑 PR도 딱 보니까 어떤 식으로 하면 좋을지 감이 잡히더라구요!!

그래서 이슈를 팠습니다. 다른 이슈에서는 '수정 부탁드립니다'라고 됐었는데, 전 제가 수정하고 싶어서 '수정하겠습니다..!' 라고 했어요.

이제 어떻게 수정해야 하는지를 알아야했습니다.

이걸 또 git clone을 받고, IDE를 켜서 하나하나 보면서 고치면 되는 줄 알았는데, 생각해보니까 깃헙 내에서 수정을 할 수 있잖아요. 그래서 포크를 해서? 바로 인기인는이라는 글자를 인기 있는으로 수정했습니다.

그리고 PR을 올렸어요!

PR

짠. 저렇게 PR을 올렸어요. 필수 확인 사항을 하나하나 구경하고? 괜찮을 거를 확인해서 체크박스에 체크를 한 뒤, PR을 올리고 몇 분이 지나니까...

LGTM과 함께 approved 됐습니다.

이걸 통해 얻은 것

간지 작살 reactjs의 레포지토리를 제 프로필에 pin하게 됐습니다. 엄청 기분이 좋았어요 ㅎㅎㅎ

그리고

제 커밋이 남겨졌습니다!!

너무 멋져요. 행복해

감사합니다

너무 자랑하고 싶어서 썼습니다. 하트 하나씩만 부탁드려요.