Claude Code에서 토큰 사용 최적화 방법

Greg 구독자 700명

요약

이 영상은 LLM API의 비용 구조를 이해하고, Claude Code를 포함한 AI 코딩 도구에서 토큰 사용을 최적화하는 방법을 다룬다. 먼저 토큰 개념과 입력·출력 토큰이 비용에 미치는 영향을 설명하고, LLM의 상태 비저장 특성과 이로 인한 비용 누적 현상을 사례로 보여준다. 이어서 /clear, /compact, /model 명령어를 활용해 대화 이력을 관리·요약하고, 작업에 맞는 모델을 선택하는 3가지 핵심 팁을 제시한다. 이를 통해 불필요한 토큰 낭비를 줄이고 API 비용을 크게 절감할 수 있다.

주요 키워드

토큰(Token) 컨텍스트 창(Context Window) 상태 비저장(Stateless) 토큰 압축(Token Compression) 컨텍스트 캐싱(Context Caching) Claude Code /clear 명령어 /compact 명령어 /model 명령어 모델 선택

하이라이트

🔑 LLM API 비용은 입력 토큰과 출력 토큰 사용량에 비례해 부과되므로 양쪽 모두 관리해야 한다.
⚡️ LLM은 상태 비저장(stateless)이어서 대화 이력을 매번 재전송하므로 토큰 사용량이 누적된다.
🌟 후속 메시지는 이전 대화 전체를 다시 처리하기 때문에 선형이 아닌 복리(compound)로 토큰이 증가한다.
📌 지나치게 긴 대화는 토큰 비용을 폭발적으로 늘릴 뿐 아니라 모델 성능 저하를 초래한다.
🚀 /clear 명령어로 채팅 이력을 완전히 초기화해 불필요한 컨텍스트 전송을 막을 수 있다.
🛠️ /compact 명령어로 대화를 요약하고 핵심 정보만 다음 세션에 남겨 토큰 사용을 최적화한다.
🎯 /model 명령어로 복잡도에 맞는 가벼운 모델을 선택해 비용과 속도, 성능 사이 균형을 맞출 수 있다.

용어 설명

토큰(Token)

LLM이 텍스트를 처리하기 위해 분할하는 최소 단위로, 하나의 문자나 단어 단위로 구성된다.

컨텍스트 창(Context Window)

모델이 한 번에 처리할 수 있는 대화 또는 텍스트의 최대 길이로, 초과 시 성능 저하가 발생한다.

상태 비저장(Stateless)

LLM이 이전 대화 내용을 기억하지 않고 매 요청마다 전체 이력을 다시 입력으로 받는 특성이다.

토큰 압축(Token Compression)

대화 이력 중 불필요한 부분을 압축하거나 요약해 토큰 사용량을 줄이는 최적화 기법이다.

모델 선택(Model Selection)

작업의 복잡도와 목적에 맞춰 비용과 성능 효율이 다른 LLM 버전을 직접 지정하는 과정이다.

LLM 비용 폭발 문제 제기, 토큰 과다 사용이 예산에 미치는 영향 설명, 영상의 목적과 주요 팁 안내.

[00:00] 대규모 언어 모델의 비용이 높은 이유와 무분별한 토큰 사용이 예산을 급속히 고갈시킬 수 있다는 문제를 제시합니다. Claude Code, Cursor, Clin 등 AI 기반 코딩 도구 사용자들이 필요 이상으로 많은 토큰을 사용하고 있을 가능성을 지적합니다.

[00:39] LLM 가격 책정이 토큰 사용량에 기반한다는 핵심 개념을 설명합니다. 토큰의 정의와 LLM이 텍스트를 처리하는 방식, 그리고 Anthropic과 OpenAI 같은 회사들의 요금 계산 방식을 구체적인 가격 예시와 함께 제시합니다.

LLM은 텍스트를 토큰으로 분할해 입력·출력 토큰 총합으로 비용을 산정한다. 토큰 개념과 분할 원리를 이해해야 예산 관리가 가능하다.

타임라인 정보가 없습니다.

입력 토큰(input)과 출력 토큰(output)의 차이를 설명하고 Claude Opus 4와 Sonnet 4 모델별 가격 비교 사례로 비용 구조를 구체화한다.

[02:23] LLM의 상태 비보존 특성이라는 중요한 개념을 강조합니다. 메시지 간에 기억하지 못하는 특성으로 인해 전체 대화 기록을 매번 다시 전송해야 하며, 이로 인해 대화가 길어질수록 각 요청의 크기와 비용이 급증한다는 핵심 문제점을 설명합니다.

LLM이 상태를 저장하지 않아 대화 이력을 매번 재전송해야 하는 구조를 실제 예시(두 번째 메시지 토큰 증가)로 보여준다.

[03:05] 토큰 계산을 설명하기 위해 실제 예시를 통해 살펴봅니다. 클로드 코드에 함수 설명을 요청하는 첫 번째 메시지를 보낸다고 가정합니다.

[03:17] 첫 번째 요청에서는 1,000토큰의 입력과 2,000토큰의 출력으로 총 3,000토큰이 사용됩니다. 시스템 프롬프트나 메모리 같은 요소는 단순화를 위해 제외했습니다.

지나치게 긴 컨텍스트 창이 모델의 집중력을 분산시키고 핵심 정보를 놓치게 해 응답 정확도가 떨어지는 문제를 다룬다.

[03:40] 같은 채팅에서 두 번째 메시지를 보낼 때 중요한 변화가 일어납니다. 모델이 상태가 없기 때문에 새 메시지와 함께 이전 대화의 모든 내용을 다시 처리해야 합니다.

[04:15] 두 번째 메시지의 입력에는 첫 번째 프롬프트 1,000토큰, 첫 번째 출력 2,000토큰, 새 프롬프트 1,000토큰이 포함되어 총 4,000개의 입력 토큰이 됩니다.

[04:30] 두 번째 요청은 4,000개 입력 토큰과 2,000개 출력 토큰으로 총 6,000토큰이 되어 첫 번째 요청보다 거의 두 배의 비용이 듭니다.

[05:05] 세 번째 메시지에서는 이전 모든 대화 내용이 다시 처리되어 토큰 사용량이 더욱 복합적으로 증가합니다. 단순한 대화가 빠르게 비싼 스레드로 변하는 이유입니다.

[05:30] 토큰 사용량은 선형적이 아닌 복합적으로 증가합니다. 더 중요한 것은 긴 대화가 단순히 비용만 증가시키는 것이 아니라 모델 성능도 저하시킨다는 점입니다.

[05:40] 맥락 창이 커질수록 모델은 관련 없는 정보까지 처리해야 하며, 이는 핵심에 집중하기 어렵게 만듭니다. 결과적으로 정확성이 떨어지고 초점이 흐려진 응답을 생성할 수 있습니다.

[06:11] 실제 LLM 플랫폼들은 컨텍스트 캐싱, 토큰 압축 등의 최적화 기술을 사용하지만 완벽하지 않으며, 긴 대화에서는 토큰 사용량이 빠르게 누적되어 비용이 급증할 수 있다는 문제점을 설명합니다.

/clear 명령어로 기존 채팅 히스토리를 지워 불필요한 컨텍스트 전송을 방지하고, 하나의 작업당 하나의 채팅 윈도우를 유지하는 방법을 설명한다.

[06:42] 첫 번째 팁으로 '작업당 하나의 채팅 창' 원칙을 제시하며, 작업 완료 후 새로운 채팅을 시작해야 하는 이유를 설명합니다. 같은 스레드에서 대화를 계속하면 불필요한 이전 토큰들이 계속 전송되어 비용이 증가합니다.

[07:08] Claude Code에서 /clear 명령어 사용법을 실제 시연하며 설명합니다. 긴 대화 기록을 완전히 지우고 새로운 채팅 창을 시작하는 과정을 보여주며, 이를 통해 불필요한 토큰 사용을 방지할 수 있음을 강조합니다.

[08:21] 예외 상황과 두 번째 팁을 소개합니다. 다음 작업이 이전 작업을 기반으로 하거나 복잡한 장기 프로젝트의 경우, 컨텍스트 한계의 50%에 도달하거나 충분한 토론이 이루어졌을 때 대화를 요약하고 새로 시작하는 전략을 제안합니다.

/compact 명령어를 사용해 지정한 방식(최근 메시지만, 액션 아이템 등)으로 대화를 요약하고 새 채팅에 요약본만 남겨 토큰 사용을 줄이는 절차를 안내한다.

[08:58] 대화가 충분히 진행되었다고 느끼면 conversation을 요약하고 새롭게 시작하라고 조언합니다. 50% 지점이 Claude Code가 집중력을 잃기 시작하는 임계점이라고 설명합니다.

[09:14] Claude Code에서 대화 요약 방법을 맞춤 설정할 수 있는 기능을 소개합니다. 마지막 두 메시지만 요약하거나, 기술적 세부사항에만 집중하거나, XML/JSON 형식으로 요약하는 등의 옵션을 제공합니다.

[09:36] /compact 명령어 사용법을 설명하며, 전체 대화를 자동으로 요약하고 새 채팅 창을 실행하는 기능을 소개합니다.

[09:47] 실제 예시를 통해 긴 대화로 인해 컨텍스트의 66%를 사용한 상황을 보여줍니다. Claude Code의 95% 자동 압축 기능의 한계와 위험성을 경고합니다.

[10:31] 마지막 메시지(API에 동물 추가 기능 구현 계획)만 유지하고 싶은 상황에서 /compact 명령에 맞춤형 지침을 추가하는 과정을 시연합니다.

[11:08] 압축 완료 후 새 채팅 창에서 불필요한 컨텍스트가 제거되고 상태 표시기가 재설정된 결과를 확인합니다. 이제 더 집중적이고 토큰 효율적인 대화가 가능해졌음을 강조합니다.

[11:46] 수천 개의 불필요한 토큰을 끌고 다니지 않고 상호작용을 집중적으로 유지하며 비용을 관리하는 방법을 설명합니다.

/model 명령어로 기본값 대신 작업 난이도에 맞는 가벼운 모델을 직접 지정해 비용과 성능 효율을 극대화하는 방법을 제시한다.

[11:53] 세 번째 팁으로 적절한 작업에 적절한 모델을 선택하는 것의 중요성을 강조하며, 대부분의 AI 코딩 도구가 자동으로 모델을 선택하지만 항상 최적의 선택은 아님을 설명합니다.

[12:04] Claude Code가 기본적으로 Opus 4를 사용하는데, 이는 가장 강력하지만 가장 비싼 모델로 복잡한 작업에는 좋지만 간단한 작업에는 과도하다고 설명합니다.

[12:18] 도구가 자동으로 선택하도록 맹목적으로 의존하지 말고, 직접 제어하여 작업에 적합한 모델을 선택하는 것이 좋다고 조언합니다.

[12:27] Claude Code에서 /model 명령어를 사용하여 모델을 수동으로 전환하는 방법을 실제 예시를 통해 단계별로 설명합니다.

[12:54] 새로운 채팅창에서는 기본값과 소넷만 사용할 수 있지만, 이전 모델들을 사용하려면 모델 웹사이트에서 모델 이름을 복사해야 한다고 설명합니다.

[13:16] Claude Sonnet 3.5를 예시로 하여 모델 이름을 복사하고 Claude Code에서 /model 명령어로 설정하는 구체적인 과정을 보여줍니다.

[13:36] 모델이 성공적으로 설정되면 새로운 옵션이 추가되고, 이후 모델 간 전환을 쉽게 할 수 있다고 설명합니다.

[14:00] 새로운 작업을 시작할 때의 추천 워크플로우를 제시합니다. 먼저 강력한 모델로 고수준 작업을 추론하고 계획을 세운 다음, 가볍고 저렴한 모델로 전환하여 후속 작업을 처리하는 방식입니다.

[14:27] 모든 것에 가장 강력한 모델을 기본으로 사용하지 말라고 경고하며, 비용 효율성이 떨어지고 간단한 작업에서 과도한 사고로 이어질 수 있다고 설명합니다.

[14:38] 적절한 시기에 적절한 모델을 선택하면 비용, 성능, 속도 간의 균형을 맞출 수 있으며, 매일 LLM을 사용할 때 시간이 지나면서 큰 차이를 만든다고 강조합니다.

LLM 비용 계산 원리와 토큰 최적화 3가지 핵심 팁을 정리하며, 이 방법들로 API 비용 절감과 개발 생산성을 높일 수 있음을 강조한다.

타임라인 정보가 없습니다.

[00:00] 대규모 언어 모델은 비용이 많이 드는데

[00:02] 무분별한 토큰 사용은 예산을 급속히 고갈시킬 수 있습니다.

[00:04] Claude Code를 사용하든

[00:06] Cursor, Clin 또는 다른 AI 기반 코딩 도구를 사용하든

[00:09] 필요 이상으로 많은 토큰을 사용하고 있을 가능성이 높습니다

[00:12] 그로 인해 API 비용을 더 많이 지불하고 있죠

[00:13] 이를 해결하는 핵심은

[00:16] 첫째, LLM이 실제로 비용을 계산하는 방식을 이해하고

[00:18] 둘째, 그에 맞춰 사용법을 최적화하는 것입니다

[00:21] 이 영상에서는

[00:24] LLM API 가격 책정이 정확히 어떻게 작동하는지 설명하겠습니다

[00:26] 그다음 토큰 사용량을 최적화하고

[00:29] 토큰 낭비를 줄이는 방법을 보여드려

[00:31] 더 적은 비용으로 더 많이 구축할 수 있도록 하겠습니다

[00:34] 더 적은 비용으로 더 많이 구축할 수 있도록 하겠습니다

[00:36] 시작해보겠습니다

[00:38] 먼저 LLM이 실제로 비용을 계산하는 방식을 알아보겠습니다

[00:40] LLM 가격 책정은 전적으로 토큰 사용량을 기반으로 합니다

[00:44] 이는 모델에 보내는 입력과

[00:46] 모델이 다시 생성하는 출력을 모두 포함합니다

[00:48] 모델에 더 많은 토큰을 제공할수록

[00:50] 계산 비용이 높아지고

[00:53] 그만큼 API 비용도 높아집니다

[00:54] 그렇다면 토큰이 정확히 무엇일까요?

[00:57] 대부분의 사람들이 생각하는 것과 달리

[00:59] LLM은 인간처럼 원시 텍스트를 읽지 않습니다

[01:02] 대신 토큰이라는 더 작은 단위로 분해합니다

[01:04] 높은 수준에서 보면, 토큰은 단순히 텍스트 덩어리로

[01:07] 한 글자만큼 짧을 수도 있고 전체 단어만큼 길 수도 있습니다

[01:09] 토큰을 LLM이 실제로 이해하는 언어라고 생각하면 됩니다

[01:12] 입력을 처리하기 전에

[01:14] 모델은 모든 것을 토큰으로 변환합니다

[01:17] 그렇다면 Anthropic이나 OpenAI 같은 LLM 회사들은

[01:19] 어떻게 청구 금액을 계산할까요?

[01:22] 모든 것은 사용하는 토큰 수와

[01:24] 사용하는 모델에 따라 결정됩니다

[01:26] 가격은 일반적으로 토큰 100만 개당으로 책정되며

[01:28] 입력과 출력 토큰 모두에 대해 청구됩니다

[01:31] 각 모델마다 고유한 요금이 있습니다

[01:33] 예를 들어, Claude Opus 4는

[01:36] 입력 토큰 100만 개당 15달러,

[01:38] 출력 토큰 100만 개당 75달러입니다

[01:40] 반면 Claude Sonnet 4는 더 저렴합니다

[01:44] 입력 토큰 100만 개당 3달러,

[01:46] 출력 토큰 100만 개당 15달러입니다

[01:49] 그렇다면 입력 토큰에는 무엇이 포함될까요?

[01:52] 모델에 보내는 모든 것이 포함됩니다

[01:55] 프롬프트, 업로드된 파일이나 이미지,

[01:58] 시스템 지침, 메모리 조회 또는 설정 등이 포함됩니다

[02:00] 출력 토큰의 경우

[02:03] 모델이 반환하는 모든 것입니다

[02:05] 응답, 코드, 요약, 이미지 등

[02:08] 모델이 생성하는 모든 것이 포함됩니다

[02:11] 그리고 여기서 대부분의 사람들이 놓치는 부분이 있습니다

[02:13] LLM과 작업할 때 특히 중요한데

[02:16] LLM은 상태를 보존하지 않습니다

[02:18] 메시지 간에 아무것도 기억하지 않습니다

[02:20] 후속 메시지를 보낼 때

[02:23] 모델은 이전에 일어난 일을 전혀 기억하지 못합니다

[02:25] 컨텍스트를 유지하기 위해

[02:27] 전체 대화 기록, 모든 프롬프트,

[02:30] 모든 지침과 모든 출력을

[02:32] 새로운 입력의 일부로 다시 보내야 합니다

[02:34] 즉, 모든 후속 메시지에는

[02:37] 방금 입력한 내용뿐만 아니라

[02:39] 채팅의 이전 모든 내용도 포함됩니다

[02:41] 대화가 길어질수록

[02:44] 각 요청의 크기도 커지고

[02:46] 새로운 메시지마다 더 많은 비용이 듭니다

[02:49] 새로운 메시지마다 더 많은 비용이 듭니다

[02:51] 방금 입력한 내용뿐만 아니라

[02:53] 채팅의 이전 모든 내용도 포함됩니다

[02:56] 대화가 길어질수록

[02:58] 각 요청의 크기도 커지고

[03:00] 새로운 메시지마다 더 많은 비용이 듭니다

[03:03] 처리하기 위해 더 많은 비용이 발생합니다

[03:05] 처리됩니다. 이를 더 명확하게 하기 위해

[03:08] 예시를 살펴보겠습니다. 클로드 코드에

[03:10] 이런 메시지를 보낸다고 해봅시다. 이 함수가

[03:12] 무엇을 하는지 이해하는 데 도움을 주세요.

[03:14] 토큰 사용량이 어떻게 보이는지 확인해봅시다.

[03:17] 입력 토큰의 경우, 이 프롬프트가

[03:19] 간단히 하기 위해 1,000토큰이라고 가정합시다.

[03:22] 이제 시스템 프롬프트나 메모리 같은

[03:23] 다른 요소들도 있지만, 지금은

[03:25] 그런 것들은 무시하겠습니다. 모델이

[03:27] 입력을 처리하면 출력을 생성합니다.

[03:29] 출력이 2,000토큰이라고 가정해봅시다.

[03:32] 따라서 단일 요청에 대해

[03:34] 1,000개의 입력 토큰과 2,000개의 출력 토큰을

[03:38] 사용하여 총 3,000토큰입니다.

[03:40] 이제 같은 채팅에서 두 번째

[03:43] 메시지를 보낸다고 해봅시다. 이 함수가

[03:45] 무엇을 하는지 이해하는 데 도움을 주세요.

[03:47] 함수 XYZ. 토큰 사용량이 어떻게

[03:50] 보이는지 확인해봅시다. 프롬프트가

[03:52] 다시 한 번 약 1,000토큰이라고 가정하고

[03:54] 출력도 다시 약 2,000토큰이라고

[03:57] 가정해봅시다. 하지만 여기서

[03:59] 중요한 부분이 있습니다. 이것이

[04:01] 같은 채팅 스레드의 후속 메시지이기 때문에

[04:03] 모델은 새 메시지만 처리하는 것이 아닙니다.

[04:06] 첫 번째 메시지의 모든 내용도 다시 처리합니다.

[04:08] 이는 이러한 모델들이 상태가 없고

[04:11] 이전 맥락이 여전히 관련이 있다고

[04:13] 가정하기 때문입니다. 메시지 2의

[04:15] 입력에는 이제 프롬프트 1의 1,000토큰,

[04:19] 출력 1의 2,000토큰, 그리고

[04:21] 프롬프트 2의 1,000토큰이 포함되어

[04:24] 총 4,000개의 입력 토큰이 됩니다.

[04:27] 메시지 2의 2,000개 출력 토큰을 더하면

[04:30] 두 번째 요청의 총 토큰은 6,000개입니다.

[04:33] 메시지 1과 메시지 2가 그 자체로는

[04:35] 각각 1,000토큰 프롬프트와

[04:38] 2,000토큰 출력으로 동일함에도 불구하고

[04:40] 메시지 2는 거의 두 배의 비용이 듭니다.

[04:43] 왜일까요? 메시지 2를 후속으로 보내기 때문에

[04:46] 모델은 맥락을 유지하기 위해

[04:48] 새 입력의 일부로 1번의 모든 내용을

[04:51] 다시 처리해야 합니다. 따라서

[04:54] 메시지 1처럼 3,000토큰이 드는 대신

[04:57] 메시지 2는 실제로 6,000토큰,

[04:59] 즉 입력 4,000토큰과 출력 2,000토큰이

[05:02] 듭니다. 이제 같은 채팅에서

[05:05] 세 번째 메시지를 보낸다고 상상해보세요.

[05:08] 입력은 메시지 1의 모든 내용

[05:10] 플러스 메시지 2의 모든 내용

[05:12] 플러스 새로운 메시지 3이 됩니다.

[05:14] 모든 후속 메시지마다 모델은

[05:17] 이전의 모든 입력과 출력을 다시 처리합니다.

[05:20] 더 이상 관련이 없더라도 말입니다.

[05:23] 단순한 주고받기로 느껴지는 것이

[05:25] 빠르게 비싼 스레드로 변할 수 있습니다.

[05:28] 그리고 그것은 총 토큰 사용량이

[05:30] 선형적으로 증가하지 않기 때문입니다.

[05:33] 복합적으로 증가합니다. 그리고 여기서

[05:35] 마찬가지로 중요한 것이 있습니다. 긴 대화는

[05:37] 단순히 더 많은 비용이 드는 것이 아닙니다.

[05:40] 실제로 모델 성능을 떨어뜨립니다.

[05:42] 맥락 창이 커질수록 모델은

[05:45] 대화의 더 많은 부분을 처리해야 하며

[05:47] 더 이상 관련이 없을 수도 있는 부분까지

[05:50] 처리해야 합니다. 그런 추가적인 노이즈는

[05:52] 모델이 중요한 것에 집중하기 어렵게 만듭니다.

[05:54] 핵심 세부사항을 놓치기 시작하거나, 반복하거나,

[05:57] 너무 많은 정보에 압도되어

[05:59] 정확성이 떨어지는 응답을 할 수 있습니다.

[06:02] 따라서 복합적인 비용 증가에 더해

[06:04] 긴 채팅은 정확성 감소와

[06:06] 초점이 흐려진 응답으로 이어질 수 있습니다.

[06:09] 그리고 명확히 하자면, 이것은 개념을

[06:11] 개념을 설명하기 위한 예시입니다. 실제

[06:14] 환경에서는 LLM 플랫폼들이 컨텍스트

[06:16] 캐싱, 토큰 압축, 또는 경량 모델을

[06:19] 사용해 이전 메시지를 요약하는 등의

[06:21] 최적화를 적용하곤 합니다. 이런

[06:24] 기술들이 도움이 되긴 하지만

[06:26] 완벽하지는 않고, 핵심 문제를

[06:28] 완전히 해결하지는 못합니다. 긴

[06:30] 대화에서는 토큰 사용량이 빠르게

[06:33] 누적되고, 주의하지 않으면 비용이

[06:35] 급격히 증가할 수 있습니다. 이제 LLM이

[06:37] 비용을 계산하는 방식을 이해했으니,

[06:40] 토큰 낭비를 줄이고 사용량을

[06:42] 최적화하는 방법을 알아보겠습니다. 첫 번째 팁은

[06:45] 작업을 완료하면 새로운 채팅을 시작하는 것입니다.

[06:48] 서로 관련 없는 여러 작업에 같은

[06:50] 채팅 창을 재사용하지 마세요. 앞서

[06:52] 예시에서 본 것처럼, 같은 스레드에서

[06:54] 대화를 계속할 때마다 이전

[06:56] 상호작용의 모든 토큰을 함께 끌고

[06:59] 다니게 됩니다. 더 이상 관련이 없어도

[07:01] 말이죠. 그러니 작업이 끝나면 새로운

[07:03] 채팅을 시작하는 습관을 기르세요.

[07:06] 방법은 다음과 같습니다. Claude Code를

[07:08] 사용한다면 clear 명령을 사용해서

[07:11] 전체 채팅 기록을 지우고 새로운

[07:12] 채팅 창을 시작하세요. 지금 열려있는

[07:15] 이 채팅 창에는 많은 메시지들이 있고

[07:17] 계속해서 이어지고 있습니다. 이런

[07:19] 상황은 원하지 않죠. 가능하면 이렇게

[07:22] 긴 대화를 피해야 합니다. 왜냐하면

[07:24] 새로운 메시지를 보낼 때마다 이 긴

[07:26] 대화 전체가 LLM으로 전송되기

[07:28] 때문입니다. 따라서 단순히 '1+1은

[07:30] 무엇인가요?'와 같은 간단한 요청을

[07:32] 보내더라도 모델은 전체 대화를

[07:35] 처리하게 되고, 이는 많은 토큰을

[07:37] 소모하게 됩니다. 그래서 작업을

[07:40] 완료하면 항상 /clear를 실행해야

[07:42] 합니다. 이 명령은 전체 대화 기록을

[07:44] 지워줍니다. 모든 내용을 지우고

[07:46] 모든 컨텍스트를 해제해줍니다. 그리고

[07:49] 새로운 채팅 창을 열어줍니다. 지금

[07:52] 당장 해보겠습니다. 엔터를 누르면

[07:54] 더 이상 이전 기록이 없는 것을 볼 수

[07:55] 있습니다. 뒤로 스크롤해봐도 더 이상

[07:57] 이전 기록이 없습니다. 컨텐츠가

[07:59] 없습니다. 이것은 모든 것이 지워진

[08:01] 완전히 새로운 채팅 창입니다. 이것이

[08:03] 바로 여러분이 습관으로 만들어야 할

[08:05] 것입니다. 이제 '1+1은 무엇인가요?'라고

[08:06] 물어보면 단순히 이 부분만 처리하게

[08:08] 됩니다. 입력에 추가되는 다른 것은

[08:10] 없습니다. 경험상 간단한 규칙이

[08:12] 있습니다. 작업당 하나의 채팅 창을

[08:14] 사용하는 것입니다. 물론 다음 작업이

[08:16] 이전 작업을 직접적으로 기반으로 하거나

[08:17] 지속적인 컨텍스트가 필요한 길고

[08:19] 복잡한 작업을 하는 경우와 같은

[08:21] 예외는 있습니다. 이제 두 번째 팁으로

[08:24] 넘어가겠습니다. 두 번째 팁은 채팅이

[08:27] 길어지기 전에 요약하는 것입니다.

[08:29] 때로는 주요 기능을 구축하는 것과

[08:31] 같은 크고 복잡한 작업을 하게 되는데,

[08:33] 이런 경우 바로 새로운 채팅을 시작하는

[08:36] 것은 실용적이지 않습니다. 이전

[08:38] 대화의 컨텍스트가 여전히 필요하기

[08:41] 때문입니다. 이런 경우에는 다음과

[08:43] 같이 하세요. 채팅이 컨텍스트 한계의

[08:45] 약 50%에 도달하거나 상당한 양의

[08:47] 주고받기 토론이 있었다고 느끼면

[08:50] 대화를 요약하고 새롭게 시작하세요.

[08:51] 내 경험상 이런 방식이 효과적입니다.

[08:54] 채팅이 길어지기 전에 요약하는

[08:56] 것입니다. 때로는 주요 기능을 구축하는

[08:58] 충분한 토론이 오갔다고 느끼면

[09:00] 대화를 요약하고

[09:02] 새롭게 시작하세요. 제 경험상

[09:04] 50% 정도가 Claude Code가

[09:07] 집중력을 잃기 시작하는 지점이지만

[09:09] 본인의 경험에 따라

[09:11] 임계값을 조정해도 됩니다. Claude Code는

[09:14] 대화를 요약하는 방법에 대한

[09:16] 맞춤형 지침을

[09:18] 제공할 수도 있습니다. 예를 들어

[09:20] 마지막 두 메시지만 요약하도록 하거나

[09:23] 기술적 세부사항에만 집중하고

[09:26] 일반적인 토론은 건너뛰거나

[09:28] 액션 아이템이나 미해결 사항만 요약하거나

[09:30] XML이나 JSON과 같은

[09:33] 특정 형식으로 요약하도록 할 수 있습니다.

[09:36] 방법은 다음과 같습니다. Claude Code를 사용 중이라면

[09:38] compact 명령을 실행하세요.

[09:40] 전체 대화를 자동으로 요약하고

[09:42] 해당 요약이 미리 로드된

[09:44] 새 채팅 창을 실행합니다.

[09:47] 예시를 살펴보겠습니다.

[09:49] Claude Code에서 새 채팅

[09:51] 창을 열었습니다. 매우 긴 대화가

[09:53] 진행되고 있었습니다.

[09:54] 여러 질문을 했는데, 관련된 것도 있고 아닌 것도 있었습니다.

[09:57] 정말 많은 페이지의 텍스트입니다.

[09:59] 우측 하단의 상태 표시기를 보면

[10:01] 여유 컨텍스트가 34% 남았다고 나와 있는데

[10:04] 이는 66%를 사용했다는 뜻입니다.

[10:06] 좋지 않은 상황이죠. 여기서 언급할 점은

[10:08] Claude Code가 용량이 95%에 도달하면

[10:10] 자동 압축을 통해

[10:12] 채팅을 압축하려고 하지만

[10:15] 이에 의존하면 안 됩니다. Claude는

[10:18] 컨텍스트가 95% 가득 찰 때까지 기다렸다가

[10:21] 자동 압축을 시작하기 때문입니다.

[10:23] 대화 요약을 완료하기 전에

[10:25] 공간이 부족해져서

[10:27] 불완전한 요약이 나오거나

[10:29] 오류가 발생할 수 있습니다.

[10:31] 예시로 돌아가서, 이 채팅에서는

[10:33] 마지막 메시지만 요약하고 유지하고 싶다고 해봅시다.

[10:36] 현재 작업 중인 내용이고

[10:38] 이전의 모든 내용은 더 이상 관련이 없기 때문입니다.

[10:40] 이 경우 마지막 메시지는

[10:43] Claude Code에게 이 API에

[10:45] 동물을 추가하는 새로운 기능의

[10:47] 구현 계획을 만들어 달라고 요청한 것이었습니다.

[10:50] 이를 위해 /compact을 입력하겠습니다.

[10:52] 여기서 맞춤형 요약 지침을

[10:55] 추가할 수 있는 옵션이 보입니다.

[10:57] "마지막 메시지만

[10:59] 요약하고 유지해 주세요"라고

[11:03] 입력하겠습니다. 이제 엔터를 누르고

[11:05] 처리되도록 하겠습니다. Claude Code가

[11:08] 압축을 완료한 것 같습니다.

[11:10] 이전 대화의 요약이 포함된

[11:11] 새 채팅 창이 보입니다.

[11:13] 앞서 본 구현 계획만

[11:16] 포함되어야 합니다.

[11:17] 이것이 새로운

[11:19] 구현 계획입니다. 우측 하단을 보면

[11:21] 더 이상 상태 표시기가 없습니다.

[11:23] 이는 컨텍스트 창의

[11:24] 66%를 사용했다는 표시가

[11:27] 없어졌음을 의미합니다. 이제 재설정되었기 때문입니다.

[11:29] 이제 불필요한

[11:31] 컨텍스트를 모두 제거했습니다. 대화를 계속하게 되면

[11:33] 더 집중적일 뿐만 아니라

[11:36] 토큰 효율성도 더 높아집니다.

[11:38] 이것이 compact 명령을

[11:40] 사용하는 것이 중요한 이유입니다.

[11:42] 이러한 접근 방식은

[11:44] 긴 다단계 작업을 관리하는 데 도움이 됩니다.

[11:46] 수천 개의 불필요한 토큰을 끌고 다니지 않고

[11:48] 상호작용을 집중적으로 유지하고

[11:50] 비용을 관리할 수 있습니다. 세 번째 팁은

[11:53] 적절한 작업에 적절한 모델을 선택하는 것입니다.

[11:55] 대부분의 AI 코딩 도구는

[11:58] 자동으로 모델을 선택해주지만

[12:00] 항상 가장 비용 효율적이거나

[12:02] 성능이 가장 뛰어난 옵션을 의미하지는 않습니다.

[12:04] 예를 들어, Claude Code는 현재

[12:06] Opus 4를 기본값으로 사용하는데

[12:08] 이는 가장 강력하지만 가장 비싼 모델입니다.

[12:11] 복잡하고 추론이 많이 필요한

[12:13] 작업에는 훌륭하지만, 간단한

[12:15] 작업에는 과도합니다.

[12:18] 도구가 선택하도록 맹목적으로 의존하는 대신

[12:20] 직접 제어하여 작업에 맞는

[12:23] 적절한 모델을 선택하는 것이 좋습니다.

[12:25] 방법을 알려드리겠습니다.

[12:27] Claude Code에서는 /model 명령어를 사용하여

[12:31] 모델을 수동으로 전환할 수 있습니다.

[12:33] 간단한 예시를 살펴보겠습니다.

[12:35] 여기는 완전히 새로운 채팅 창입니다.

[12:37] /model을 실행하면 현재

[12:40] 모델 선택이 기본값으로 설정된 것을 볼 수 있습니다.

[12:42] 이는 Claude Code가

[12:44] 사용할 모델을 결정한다는 의미인데

[12:47] 대부분의 경우 Opus 4가 되며

[12:49] 이는 가장 강력하지만 가장 비싼

[12:51] 모델입니다. 여기 창에서

[12:54] 처음에 사용할 수 있는 옵션은

[12:56] 기본값과 소넷뿐입니다.

[12:58] 하지만 Sonnet 3.7이나

[13:02] Sonnet 3.5 같은 이전 모델을 사용하려면

[13:04] 먼저 모델 웹사이트로 가야 합니다.

[13:07] 이 웹사이트로 가세요.

[13:09] 첫 번째 열을 보고 원하는

[13:11] 모델을 찾습니다. 그런 다음 해당

[13:13] 모델의 이름을 복사합니다. 예를 들어

[13:16] Claude Sonnet 3.5를 사용하고 싶다면

[13:18] 여기 있는 이름을 복사하겠습니다.

[13:20] 그런 다음 Claude Code로 돌아가서

[13:22] 우선 이것을 종료하겠습니다.

[13:23] 홈페이지로 돌아가서 /model을 입력합니다.

[13:26] 그러면 여기서 사용하고 싶은

[13:29] 특정 모델을 지정할 수 있습니다.

[13:31] 복사해서 붙여넣겠습니다.

[13:32] 이것은 Sonnet 3.5를 사용하겠다는

[13:34] 의미입니다. 엔터를 누르면

[13:36] 모델이 Sonnet 3.5로 설정된 것을

[13:38] 볼 수 있습니다. 모델 간에

[13:40] 전환하고 싶다면

[13:43] 모델에서 선택하기만 하면 됩니다.

[13:45] 모델로 다시 가면 이제

[13:47] 방금 입력한 세 번째 옵션인

[13:49] 사용자 정의 옵션을 볼 수 있습니다.

[13:51] 기본값, Sonnet 3.5가 있고

[13:52] 둘 중에서 선택할 수 있습니다.

[13:54] Sonnet을 선택하면 다시 Sonnet 4로

[13:56] 돌아갑니다. 이것이

[13:58] Claude Code에서 사용자 정의 모델을 추가하는 방법입니다.

[14:00] 새로운 작업을 시작할 때 추천하는

[14:03] 간단한 워크플로우입니다.

[14:05] 먼저 강력한 모델로 시작하여

[14:07] 고수준 작업을 추론합니다. 모든 관련

[14:10] 정보를 매핑하고, 예외 상황을

[14:12] 식별하고, 시스템

[14:14] 아키텍처를 계획하고, 구현

[14:16] 계획을 스케치합니다. 그런 다음

[14:18] 더 가볍고 저렴한 모델로 전환하여

[14:21] 후속 작업을 처리합니다.

[14:22] 출력을 개선하거나 지원 코드와

[14:25] 문서를 작성하는 것처럼 말이죠.

[14:27] 모든 것에 가장 강력한 모델을

[14:29] 기본으로 사용하지 마세요.

[14:31] 비용 효율적이지 않고

[14:33] 간단한 작업에서 과도한 사고로

[14:35] 이어질 수도 있습니다.

[14:38] 참고로 여기에 강력한

[14:40] 모델과 가볍고 저렴한 모델을

[14:42] 언제 사용할지에 대한 더 많은 예시가 있습니다.

[14:44] 적절한 시기에 적절한 모델을 선택하면

[14:47] 비용, 성능, 속도 간의 균형을

[14:49] 맞출 수 있습니다. 그리고 시간이 지나면서

[14:52] 매일 LLM을 사용할 때

[14:54] 큰 차이를 만들어냅니다.

[14:56] 이상으로 LLM이 비용을 계산하는 방법과