🐹🦜 이 글에 등장하는 두 마리

• 🐹
  못치 (햄스터)… AI는 아직 공부 중. "그게 무슨 뜻이야?"라고 소박하게 질문하는 학생 역할
• 🦜
  키나코 (사랑앵무)… AI로 조사를 수행하는 해설 역할. 친절하게 깊이 있게 가르쳐 주는 선생님 역할

이 글은 두 마리의 대화를 받아 적은 형식입니다. 발언 맨 앞에 있는 이모지+이름이 화자입니다.

🐹 못치 "있잖아 키나코, API에 JSON으로 돌려달라고 했는데, 깨진 데이터가 돌아온 적 없어?"

🦜 키나코 "있고말고. 닫는 괄호가 부족해서 파싱 에러(Parsing Error)가 나는 건 개발자들의 흔한 일이지."

🐹 못치 "게다가 긴 대화를 하다 보면 처음에 정했던 걸 잊어버리기도 하고!"

🦜 키나코 "비용도 문제였지. 간단한 질문에도 복잡한 추론과 똑같은 만큼 돈이 들었거든."

🐹 못치 "개발자의 3대 고민이라는 느낌이네."

🦜 키나코 "하지만 말이야, 2026년 초에 Anthropic이 이 세 가지 고민을 한꺼번에 해결하는 대형 업데이트를 내놓았어!"

🐹 못치 "오! 전부 해결해 준다고? 진짜 궁금해!"

🦜 키나코 "Structured Outputs, Compaction, Adaptive Thinking. 이 세 가지를 깊이 있게 파헤쳐 볼 거야."

🦜 키나코 "먼저, 세 가지 기능이 어떤 과제를 해결하는지 정리해 보자."

🦜 키나코 "첫 번째는, JSON 출력의 불안정성."

🦜 키나코 "AI에게 JSON으로 응답해 달라고 부탁해도, 가끔 형식이 무너져서 시스템이 크래시(Crash)되어 버려."

🐹 못치 "레시피대로 만들어 달라고 부탁했는데, 매번 다른 요리가 나오는 것과 같네!"

🦜 키나코 "정확히 그런 느낌이야. JSON으로 응답하라고 지정해도 닫는 괄호가 빠지거나 불필요한 텍스트가 섞이곤 하지."

🦜 키나코 "그래서 개발자들은 더미(Dummy) 도구를 정의해서 억지로 JSON 형식을 만드는 해킹(Hack)을 사용해 왔어."

🐹 못치 "해킹이라고 말하는 시점에서 불안한걸."

🦜 키나코 "실제로 많은 개발자가 재시도 로직(Retry Logic)이나 에러 핸들링(Error Handling)에 시간을 뺏기고 있었어."

🐹 못치 "원래 만들고 싶었던 프로덕트가 아니라, 회피책 코드를 짜는 데 시간을 쓰고 있었구나. 아깝다."

🦜 키나코 "두 번째는 Context Rot이라고 불리는 문제."

🦜 키나코 "긴 대화를 계속하면, AI가 처음에 정했던 것을 잊어버려."

🐹 못치 "방금 말했잖아! 라고 하게 되는 상황이지!"

🦜 키나코 "에이전트(Agent)가 몇 시간 동안 코드를 수정하고 있는데, 최초의 설계 방침을 잊어버리는 케이스가 있어."

🦜 키나코 "그리고 세 번째는 추론 비용의 경직성."

🦜 키나코 "간단한 질문이든 어려운 질문이든, 똑같은 만큼의 사고 비용이 들었어."

🐹 못치 "이전의 Extended Thinking에서는 사고에 사용하는 토큰(Token) 수를 수동으로 설정해야 했었지?"

🦜 키나코 "맞아. 태스크의 난이도를 알 수 없는데 예산을 결정하는 건 굉장히 비효율적이었어."

🐹 못치 "1 더하기 1을 묻는 데도, 수학 증명을 푸는 데도 똑같은 가격이라는 거야?"

🦜 키나코 "응. Extended Thinking의 budget_tokens를 수동으로 설정해야만 했거든."

🐹 못치 "예상이 빗나가면 낭비가 되거나, 부족하게 되거나 둘 중 하나겠네."

🦜 키나코 "정확해. 이 세 가지 구조적인 과제를 한꺼번에 해결한 것이 이번에 소개할 3대 기능이야."

🦜 키나코 "그럼 첫 번째 기능인 Structured Outputs부터 살펴보자."

🦜 키나코 "이것은 AI의 출력을 100% 지정된 JSON 형식에 따르게 하는 기능이야."

🐹 못치 "100%!? 정말로 절대 안 깨지는 거야?"

🦜 키나코 "메커니즘이 흥미로워. 제약 조건부 디코딩(Constrained Decoding)이라는 기술을 사용하고 있거든."

🦜 키나코 "개발자가 정의한 JSON Schema를 내부에서 그래머(Grammar)로 컴파일해."

🦜 키나코 "그 그래머에 위반되는 토큰은 물리적으로 생성할 수 없도록 차단돼."

🐹 못치 "프롬프트로 부탁하는 게 아니라, 출구에서 물리적으로 막는다는 뜻이야?"

🦜 키나코 "맞아, 그래서 스키마 위반은 원리적으로 일어날 수 없어."

🐹 못치 "Python이라면 Pydantic 모델, TypeScript라면 Zod 스키마로 타입 정의를 하면 되는 거지?"

🦜 키나코 "그렇지. SDK가 자동으로 변환해 주기 때문에 생(Raw) JSON Schema를 직접 쓸 필요는 없어."

🦜 키나코 "게다가 minimum 같은 미지원 제약 조건이 있더라도, SDK가 description으로 변환해서 보완해 준단다."

🦜 키나코 「2026년 1월 29일에 Claude API의 일반 제공(GA)이 시작되었어.」

🦜 키나코 「지원 모델도 폭넓어서, Opus, Sonnet, Haiku 전부 사용할 수 있어.」

🐹 못찌 「하지만 이거, OpenAI는 2024년에 이미 내놓지 않았어?」

🦜 키나코 「확실히 약 1년 반 정도 늦기는 했지만, Claude만의 독자적인 강점이 있어.」

🦜 키나코 「Extended Thinking과의 통합이야. 사고 블록(Thinking block)은 자유롭게 추론할 수 있고, 최종 출력에만 스키마 제약(Schema constraint)이 걸리는 거지.」

🐹 못찌 「머릿속으로는 자유롭게 생각하고, 대답할 때만 규칙대로 한다는 거구나!」

🦜 키나코 「한 가지 주의할 점이 있는데, 새로운 스키마를 처음 사용할 때는 그래머(Grammar) 컴파일 때문에 조금 느려져.」

🐹 못찌 「매번 느려지는 거야?」

🦜 키나코 「처음 한 번만. 컴파일된 그래머는 24시간 동안 캐시되니까, 두 번째부터는 빨라.」

🦜 키나코 「에러 처리도 중요해. AI가 안전상의 이유로 거부할 경우, JSON이 아닌 응답이 반환될 수 있어.」

🐹 못찌 「안전성 거부만큼은 예외구나. stop_reason을 확인하는 게 중요하겠네.」

🦜 키나코 「제약 사항도 있어서, 1개 요청(Request)당 strict 도구는 최대 20개까지야.」

🦜 키나코 「두 번째 기능은 Compaction이야. 컨텍스트(Context) 자동 압축 기능이지.」

🐹 못찌 「컨텍스트라면, AI에게 전달하는 정보의 양을 말하는 거지?」

🦜 키나코 「맞아. 대화가 길어지면 과거의 주고받은 내용이 점점 쌓이잖아?」

🦜 키나코 「Compaction은 쌓인 대화를 자동으로 요약해서 압축해 줘.」

🐹 못찌 「노트 필기할 때 전부 다 쓰는 게 아니라 요점만 메모하는 거랑 같네!」

🦜 키나코 「좋은 비유야. 메커니즘으로는 입력 토큰(Input token)이 임계값(Threshold)을 넘으면 자동으로 발동해.」

🦜 키나코 「기본 임계값은 15만 토큰이야. 최소 5만 토큰부터 설정할 수 있어.」

🐹 못찌 「얼마나 압축할 수 있어?」

🦜 키나코 「제3자 검증에 따르면, 약 58%의 토큰 절감이 보고되었어.」

🐹 못찌 「절반 이상 줄어들다니 대단하다!」

🦜 키나코 「지원 모델은 Opus 4.6과 Sonnet 4.6이야. 2026년 3월 시점에서는 아직 베타 버전이야.」

🦜 키나코 「하지만 주의할 점도 있어. Compaction의 요약 생성에도 당연히 토큰이 소비되거든.」

🐹 못찌 「압축하는 데도 돈이 드는구나. 하지만 전체적으로는 더 저렴해져?」

🦜 키나코 「긴 대화를 계속 이어갈 경우에는, 압축하지 않은 채 거대한 컨텍스트를 매번 통째로 계속 보내는 것보다 훨씬 경제적이야.」

🐹 못찌 「하지만 요약한다는 건 정보가 손실될 리스크도 있는 거 아냐?」

🦜 키나코 「예리해. 실제로 결론은 유지되지만, 설계 근거(Design rationale)가 손실될 수 있다는 보고가 있어.」

🦜 키나코 「그래서 Memory 기능과 조합해서 사용하는 게 포인트야.」

🐹 못찌 「Compaction이 일시 메모리 정리라면, Memory는 장기 보관이라는 뜻이구나.」

🦜 키나코 「개발자는 pause_after_compaction을 true로 설정하면, 압축 후에 내용을 확인하고 계속 진행할 수 있어.」

🐹 못찌 「자동으로 맡길지, 확인하고 진행할지 선택할 수 있네. 개발자에게 친절하다.」

🦜 키나코 「참고로 Claude Code에는 이 기능이 내장되어 있어서, 컨텍스트의 75% 정도에서 자동으로 발동해.」

🐹 못찌 「Claude Code에서는 CLAUDE.md 설정은 Compaction 이후에도 유지된다며?」

🦜 키나코 「응. 디스크에서 다시 불러오기 때문에 중요한 규칙은 절대 잃어버리지 않아. 안심이지.」

🦜 키나코 「세 번째는 Adaptive Thinking이야. 추론의 깊이를 동적으로 조정하는 기능이지.」

🐹 못찌 「추론의 깊이라니, 그게 무슨 뜻이야?」

🦜 키나코 「이전의 Extended Thinking에서는 추론에 사용할 토큰 예산을 개발자가 수동으로 설정했었어.」

🦜 키나코 「Adaptive Thinking에서는 AI가 문제의 난이도를 스스로 판단해서 추론량을 자동으로 조정해.」

🐹 못찌 「시험 공부할 때 쉬운 문제는 빠르게 풀고, 어려운 문제는 깊게 생각하는 거랑 똑같네!"

🦜 키나코 「개발자는 effort 파라미터로 4단계의 가이던스(Guidance)를 줄 수 있어.」

🦜 키나코 「max는 Opus 4.6 전용으로 추론에 제한이 없어. high가 기본값이야.」

🐹 못찌 「low로 설정하면 아예 생각을 안 하는 거야?」

🦜 키나코 「좋은 질문이야. effort는 소프트 시그널 (soft signal)이라서, low로 설정하더라도 복잡한 문제라면 사고를 해.」

🦜 키나코 「중요한 포인트가 하나 더 있어. Opus 4.6에서는 Interleaved Thinking (교차 사고)이 자동으로 활성화돼.」

🐹 못찌 「인터리브드 싱킹 (Interleaved Thinking)이 뭐야?」

🦜 키나코 「도구 (tool)의 실행 결과를 분석한 뒤에 다음 액션을 결정하는, 도구 간의 사고를 말해.」

🐹 못찌 「웹 검색을 하고, 결과를 분석한 뒤에, 부족하면 다시 한번 검색하는 것 같은 거야?」

🦜 키나코 「맞아! 바로 그거야. 이전에는 특별한 베타 헤더 (beta header)가 필요했지만, 지금은 자동으로 사용할 수 있어.」

🐹 못찌 「AI가 스스로 판단해 주는구나. 비용은 어떻게 돼?」

🦜 키나코 「사고 토큰 (thinking token)은 출력 토큰 (output token)과 동일한 금액으로 과금돼. Opus 4.6이라면 100만 토큰당 25달러야.」

🐹 못찌 「많이 생각하면 그만큼 돈도 더 든다는 거네.」

🦜 키나코 「재미있는 기능도 있는데, display: omitted를 설정하면 사고 내용을 숨길 수 있어.」

🦜 키나코 「단, 숨기더라도 백그라운드 (background)에서 사고는 실행되기 때문에 비용은 변하지 않아.」

🐹 못찌 「보이지 않아도 돈은 나가는 거냐고!」

🦜 키나코 「응, 하지만 응답 속도는 대폭 개선되기 때문에 사용자 경험 (UX) 향상에는 효과적이야.」

🐹 못찌 「비용을 절약하고 싶은 사람은 medium 설정으로, 정밀도를 중시한다면 high 설정으로 구분해서 쓰는 게 요령이겠네.」

🦜 키나코 「벤치마크 (benchmark)도 대단해서, Terminal-Bench 2.0에서 역대 최고 점수를 기록했어.」

🐹 못찌 「생각의 깊이를 스스로 결정할 수 있다니, 정말 똑똑해졌구나!」

🦜 키나코 「여기서 이 3가지 기능의 출시 타임라인 (release timeline)을 되돌아보자.」

🦜 키나코 「1월 29일에 Structured Outputs (구조화된 출력)가 일반 제공되어 API의 타입 안정성 (type safety)이 우선 확보되었어.」

🦜 키나코 「2월 5일에 Opus 4.6과 함께 Adaptive Thinking (적응형 사고)과 Compaction (압축)이 동시에 투입되었지.」

🦜 키나코 「2월 17일에는 Sonnet 4.6이 출시되어 가성비 좋은 선택지도 마련되었어.」

🐹 못찌 「Opus 4.6에서 Extended Thinking의 manual mode (수동 모드)가 권장되지 않게 된 것도 이 타이밍이지?」

🦜 키나코 「맞아. budget_tokens의 수동 설정은 향후 삭제될 예정이라고 공식적으로 예고되었어.」

🐹 못찌 「불과 2개월 만에 전부 갖춰졌네. Anthropic의 출시 속도가 정말 대단하다.」

🦜 키나코 「게다가 2월 19일에 Memory Tool (메모리 도구)과 Auto Caching (자동 캐싱)이 일반 제공되었고, 3월에는 1M 컨텍스트 (context)도 정식 출시되었어.」

🦜 키나코 「참고로 2월 12일에는 Anthropic이 시리즈 G에서 300억 달러를 조달하여 기업 가치가 3,800억 달러가 되었어.」

🐹 못찌 「3,800억 달러!? 진짜 엄청난 금액이다!」

🦜 키나코 「이 순서에는 명확한 전략이 있어.」

🦜 키나코 「1M 토큰이라는 광활한 메모리를 제공하는 동시에, 그 비용을 최적화하는 도구군도 세트로 준비한 거야.」

🦜 키나코 「Compaction으로 이력을 압축하고, Adaptive Thinking으로 비용을 최적화하며, 여기에 Auto Caching도 도입했지.」

🦜 키나코 「1M 컨텍스트를 낭비 없이 능숙하게 다루기 위한 무기가 전부 갖춰진 셈이야.」

🐹 못찌 「큰 냉장고를 파는 것뿐만 아니라, 식재료 보관 방법도 함께 알려주는 것과 같네.」

🦜 키나코 「좋은 비유야! 바로 생태계 (ecosystem)로서 설계된 거지.」

🦜 키나코 「Sonnet 4.6 출시 시점에는 코드 실행 기능도 무료화되었고, 검색 결과 필터링도 자동으로 할 수 있게 되었어.」

🐹 못찌 「완벽하게 다 갖춰졌잖아! Anthropic 정말 진심이구나!」

🦜 키나코 「개발자 커뮤니티의 반응도 살펴보자.」

🦜 키나코 「Structured Outputs는 Hacker News에서 184포인트를 획득했어.」

🦜 키나코 「"LLM 자동화의 근간인데 지금까지 없었다는 게 이상하다"라는 목소리가 많았지.」

🦜 키나코 「일본 개발자들로부터는 Markdown을 JSON 출력에 포함하면 파싱 에러 (parsing error)가 발생하는 케이스가 보고되고 있어.」

🐹 못찌 「"드디어 왔구나!" 하는 느낌이었겠네. 아직 완벽하지 않은 부분도 있지만.」

🦜 키나코 「Compaction에 대해서는 "OpenAI에 동등한 기능이 없다"라며, Anthropic만의 독자적인 경쟁 우위로 평가받고 있어.」

🦜 키나코 「일본의 제조업 플랫폼 CADDi는 컨텍스트 (Context) 사용률을 70% 이하로 유지하는 운영 지침을 공개하고 있어.」

🐹 못찌 「일본 기업들도 실전에서 사용하고 있구나!」

🦜 키나코 「Adaptive Thinking은 적절한 effort 설정으로 약 40%의 비용 절감이 보고되었어.」

🐹 못찌 「일상적인 작업은 medium, 복잡한 디버깅은 high라는 식으로 구분해서 사용하는 게 주류인가 보네.」

🦜 키나코 「다만, Opus 4.6에서 산문 집필 품질이 떨어졌다는 목소리도 있어.」

🐹 못찌 「추론 능력이 올라간 대신, 문장력이 떨어졌을 가능성이 있다는 뜻이야?」

🦜 키나코 「어디까지나 커뮤니티의 감각적인 보고일 뿐이지만, 용도에 따라 모델을 구분해서 사용하는 게 중요할지도 몰라.」

🦜 키나코 「그리고 가장 흥미로운 건, 이 3가지 기능을 조합한 에이전트 아키텍처 (Agent Architecture)야!」

🦜 키나코 「Adaptive Thinking으로 깊게 생각하고, 그 결과를 Structured Outputs로 구조화해서 출력해.」

🦜 키나코 「장시간 작동하면 Compaction으로 이력을 압축하고, 중요한 정보는 Memory에 저장하는 거지.」

🐹 못찌 「RAG 시스템에서도 쓸 수 있어?」

🦜 키나코 「물론이지. 간단한 사실 검색에는 effort low로 즉시 답변하고, 복잡한 분석에는 high로 깊게 생각하는 식으로 구분해서 사용할 수 있어.」

🐹 못찌 「동일한 API 엔드포인트 (Endpoint)에서 용도에 따라 비용이 자동으로 변하는구나. 이건 정말 대단한 메커니즘이야.」

🐹 못찌 「3가지가 톱니바퀴처럼 맞물려 돌아가는구나! 엄청 똑똑한 설계야!」

🦜 키나코 「오늘의 내용을 정리해 볼까.」

🦜 키나코 「Structured Outputs로 JSON 출력이 100% 보장되게 되었어.」

🦜 키나코 「Compaction으로 장시간의 대화도 컨텍스트를 압축하며 지속할 수 있게 되었어.」

🦜 키나코 「Adaptive Thinking으로 AI가 문제의 난이도에 따라 사고량을 자동으로 조절하게 되었어.」

🐹 못찌 「이걸로 JSON이 깨지는 문제도, 컨텍스트가 넘치는 문제도, 비용을 낭비하는 문제도 해결됐네.」

🦜 키나코 「3가지 모두 API 개발자에게 정말 엄청나게 실용적이고 반가운 기능이었어.」

🦜 키나코 「도입 순서로는, 우선 Structured Outputs로 타입 안정성 (Type Safety)을 확보하는 걸 추천해.」

🦜 키나코 「그다음 Adaptive Thinking의 effort 파라미터로 비용을 최적화하고, 마지막으로 Compaction으로 장기 가동에 대응하는 거지.」

🦜 키나코 「LLM이 단순한 「채팅 엔진」에서 「자율형 컴퓨팅 플랫폼 (Autonomous Computing Platform)」으로 진화하기 위한 기반, 그것이 바로 이 3가지 기능이야.」

🐹 못찌 「그러고 보니, 주인님도 Claude API로 앱을 만들고 계신대.」

🐹 못찌 「Structured Outputs 덕분에 버그가 줄었다며 기뻐하시더라고!」

🦜 키나코 「…전에는 버그가 그렇게 많았어?」

🐹 못찌 「그건 묻지 말아줘….」

🦜 키나코 「그래도 Compaction 덕분에 긴 대화도 안정적으로 이어갈 수 있게 되었으니까, 주인님의 앱도 분명 좋아질 거야.」

🐹 못찌 「Adaptive Thinking으로 불필요한 비용도 줄일 수 있고 말이야! 주인님께도 알려드리자.」

🦜 키나코 「여러분은 Claude API를 사용하고 있나요? 3가지 신기능 중 어떤 것이 가장 궁금한지 알려주세요.」

🐹 못찌 「개발자가 아닌 사람들에게도 AI 앱이 점점 더 똑똑해지고 저렴해진다는 뜻이겠지.」

🦜 키나코 「맞아. 뒷단의 기술이 진화하면 사용하는 쪽의 경험도 점점 좋아지니까.」

🐹 못찌 「Claude API의 다른 기능들도 다른 영상에서 깊이 있게 다룰 예정이니까, 기대해 주세요!」

키나코 못찌의 테크 심층 분석 에서는, AI/LLM을 중심으로 한 테크 전반을 햄스터(🐹 못찌)와 사랑앵무(🦜 키나코)의 대화로 즐겁게 해설하고 있습니다.

▶️ 영상으로 보기 → JSON이 깨지지 않는다! Claude API의 새로운 기능 3가지가 AI 개발을 바꾸는 이유

👍 이 글이 도움이 되었다면 LGTM·북마크 해주시면 큰 힘이 됩니다!

📺 채널 구독은 여기로 → 키나코 못찌의 테크 심층 분석

🔗 다른 해설 영상도 보기 → 키나코 못찌의 테크 심층 분석 영상 목록