Claude Code 고급편: 토큰 최적화와 대규모 코드베이스 컨텍스트 다루기 (2026)

- 이 글의 명령어와 수치는 Anthropic 공식 문서(2026-08-20 조회)에서 가져왔습니다. Claude Code는 매우 자주 업데이트되므로, claude --version을 확인하고 본인 머신에서 /usage를 다시 실행해 비교해 보세요.

Claude Code는 왜 대규모 코드베이스에서 토큰을 태울까요?

많은 개발자가 "작은 질문 하나 했을 뿐인데 사용량이 하루 종일 오른다"며 답답해합니다. 원인은 그 질문이 아니라 언어 모델의 작동 방식에 있습니다. 모든 요청은 대화 전체를 다시 전송합니다(시스템 프롬프트, CLAUDE.md, 기록, 읽은 파일, 도구 결과)를 입력으로요. 세션이 길어질수록 뒤에 딸려오는 컨텍스트가 계속 늘어나기 때문에 주고받을 때마다 비용이 커집니다.

비용을 끌어올리는 세 가지 메커니즘이 복합적으로 작용합니다.

• 긴 컨텍스트 누적: 컨텍스트로 끌어들이는 파일이 많을수록 이후의 모든 턴이 무거워집니다 — 다시는 그 파일을 건드리지 않더라도요.
• 컨텍스트 부패(context rot): Anthropic의 글 Effective context engineering for AI agents(2025-09-29)에 따르면, 윈도우 안의 토큰 수가 늘어날수록 모델이 중요한 정보를 떠올리는 능력은 오히려 떨어집니다. 즉 비대해진 컨텍스트는 더 비쌀 뿐 아니라 Claude의 정확도도 낮춥니다.
• 캐시 미스: Claude Code는 프롬프트 앞부분을 캐시하므로 그 부분은 다시 청구되지 않습니다. 하지만 캐시는 만료됩니다. 너무 오래 자리를 비웠다가 돌아오면 컨텍스트 블록 전체가 다시 정가로 청구됩니다.

기본 비용에 관해, Anthropic의 "비용을 효과적으로 관리하기" 문서(docs, 2026년 8월 조회)는 활동한 하루당 평균 대략 ~$13/개발자라고 보고하며, 대부분의 사용은 월 $150~250 안팎이고 사용자의 90%가 하루 ~$30 미만에 머문다고 합니다. 대규모 코드베이스에서 이를 크게 초과하고 있다면, 예측 가능한 몇몇 지점에서 토큰이 낭비되고 있는 것이 거의 확실합니다. 요금제와 청구 방식을 이해하려면 Claude Code 요금과 요금제 가이드를 보세요. 이제 막 시작했다면 먼저 Claude Code란 무엇인가를 읽고 기본기를 다지세요.

최적화보다 측정 먼저 — /context, /usage, 상태 표시줄

감으로 최적화하지 마세요. 어떤 기법에 손대기 전에 현재 상태의 스냅샷을 찍어 토큰이 어디로 가는지 파악하세요. 이 두 명령이 출발점입니다.

/usage # token & cost overview: input, output, cache read/write, cost
/context # breaks down what is taking up your CURRENT context right now

/usage는 돈의 큰 그림을 보여 줍니다. 입력 토큰이 몇 개, 출력 토큰이 몇 개, 캐시에서 읽은 양(저렴)과 새 캐시에 쓴 양(비쌈)은 얼마인지요. 캐시 읽기 비율이 높으면 좋은 신호입니다. 최적화할 때는 둘 중 /context가 더 값집니다. 시스템 프롬프트, CLAUDE.md, 선언한 MCP 도구, 끌어온 파일을 갈라내어 무엇이 공간을 차지하는지 정확히 보여 줍니다.

/usage에는 알아 둘 만한 특정 출력 형식이 있습니다. 예를 들어 Session 블록입니다.

Total cost:            $0.55
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

Pro/Max/Team/Enterprise 요금제에서는 /usage가 Plan usage breakdown도 보여 줍니다. Attribution은 최근 사용량을 skill, subagent, plugin, 개별 MCP 서버에 배분하여 각각을 전체 대비 백분율로 표시합니다. Behavior flags는 긴 컨텍스트나 캐시 미스가 최근 사용량의 10% 이상을 차지할 때 경고합니다. d/w를 눌러 24시간 보기와 7일 보기를 전환하세요.

얼마나 썼는지가 아니라 어떻게 일하는지를 알고 싶다면 /insights를 실행하세요. 이 머신의 최근 200개 세션까지 분석해, 마찰 지점과 Claude Code를 더 효과적으로 쓰기 위한 제안을 담은 HTML 보고서를 ~/.claude/usage-data/report.html에 씁니다. /usage를 대체하는 것이 아니라 보완합니다.

명령을 치지 않고도 계속 지켜볼 수 있도록 상태 표시줄에 컨텍스트 표시를 켜 두는 것도 좋습니다. 자세한 내용은 Claude Code 상태 표시줄 커스터마이즈 가이드를 보세요. 원칙은 이렇습니다. 오직 변경 전후의 수치만이 어떤 기법이 정말로 수고를 들일 가치가 있었는지 알려 줍니다. 아래 각 변경 직전과 직후에 /context를 실행해 실제 차이를 측정하세요.

그룹 1 — 능동적 컨텍스트 관리(/clear, /compact, resume)

이것은 존재하는 것 중 가장 저렴하고 효과가 큰 레버입니다. 낭비되는 토큰의 대부분은 오래되고 무관한 컨텍스트를 새 작업으로 끌고 들어오는 데서 나옵니다.

무관한 작업 사이에는 /clear. 방금 인증 모듈의 버그를 고치고 이제 결제 모듈의 테스트를 작성하려고요? /clear를 치세요. 컨텍스트가 처음 상태로 리셋되어, 새 작업의 "대화 꼬리" 비용이 다시 거의 $0으로 떨어집니다. 이것이 많은 사람이 건너뛰는, 토큰을 아끼는 가장 중요한 습관입니다.

흐름을 이어 가야 할 때는 /compact. 같은 작업 흐름을 계속하고 싶은데 컨텍스트가 부풀었다면, /compact가 대화를 요약으로 압축합니다. 중요한 점: 필요한 것을 정확히 잃지 않도록 방향을 지정한 compact를 쓰세요.

/compact Keep the database schema decisions and the files changed in the payment module; drop the long debug logs

CLAUDE.md에 "Compact instructions"를 미리 설정해 두면 모든 compact가 같은 우선순위를 유지합니다. Claude Code에는 자동 compact도 있습니다. 컨텍스트가 가득 차기 직전에 스스로 압축해 세션이 끊기지 않게 합니다. 편리하지만 솔직한 경고 하나 — 자동 compact는 세부 사항을 놓칠 수 있으므로 민감한 작업에서는 운에 맡기지 말고 방향을 지정한 수동 compact를 실행하세요.

요약에서 재개하기. 큰 세션을 다시 열 때는 전체 기록을 다시 불러오는 대신 요약에서 재개하도록 선택하세요. 수만 토큰이 아니라 수천 토큰에서 시작합니다. 이 메커니즘을 더 파고들려면 Claude Code의 컨텍스트와 메모리 관리 가이드를 읽으세요.

그룹 2 — 올바른 모델을 고르고 확장 사고(extended thinking)를 조율하기

모든 작업에 가장 강력한 모델이 필요한 것은 아닙니다. 비용 기준으로 배분하는 방법입니다(참고 API 가격: Opus 5는 100만 토큰당 입력/출력 $5/$25, Sonnet 5는 $2/$10, Haiku 4.5는 $1/$5).

• 대부분의 코딩은 Sonnet으로. Sonnet 5는 코드 작성과 편집의 대다수를 Opus의 극히 일부 비용으로 처리합니다.
• Opus는 아키텍처와 어려운 문제를 위해 아껴 두기. 깊은 추론이 필요한 지점에 이르면 세션 중간에 /model로 전환했다가 끝나면 Sonnet으로 되돌리세요.
• 단순한 subagent에는 Haiku. 순전히 기계적인 작업(grep, 요약, 서식 정리)을 하는 subagent라면 그 정의에 model: haiku를 설정하세요.

확장 사고(extended thinking)는 토큰에 있어 양날의 검입니다. "사고"는 출력 토큰으로 청구되며, 출력은 입력보다 몇 배 더 비쌉니다. 단순하고 반복적인 작업에서 무거운 사고는 그저 돈을 태우는 일입니다. 제어하는 방법입니다.

/effort # tune the reasoning effort to fit the task
MAX_THINKING_TOKENS=8000 # cap thinking tokens (environment variable)

/config에서 확장 사고를 끌 수도 있습니다. 솔직한 단서: 사고를 끄면 깊은 추론이 필요한 작업(알고리즘 설계, 다층 디버깅)의 품질이 떨어집니다 — 이것은 트레이드오프이지 "돈을 아끼려고 항상 끄기" 같은 규칙이 아닙니다. 작업이 정말로 많은 추론을 요구하지 않을 때만 낮추거나 끄세요.

그룹 3 — MCP와 도구 오버헤드 줄이기

정정: Claude Code는 이제 기본적으로 MCP 도구 정의를 지연 로딩합니다. 처음에는 도구 이름만 컨텍스트에 올라가고, 전체 설명과 매개변수 스키마는 Claude가 실제로 그 도구를 사용할 때 한 번만 로드됩니다. 따라서 실제 컨텍스트 "세금"은 두 가지입니다. (a) 오래된 Claude Code 버전이나 도구 검색이 꺼진 세션은 여전히 모든 것을 처음에 로드합니다. (b) 매우 많은 수의 도구를 가진 서버는 이름만으로도 쌓이고, 게다가 도구가 처음 호출될 때 일회성 비용이 붙습니다. 이를 살펴보려면 /context를 쓰세요.

• 쓰지 않는 서버는 비활성화: /mcp로 연결된 서버를 보고 관리하며, 현재 세션에 필요 없는 것은 끄세요.
• 가능하면 MCP보다 CLI를 우선. 이미 커맨드라인 도구가 있는 작업 — gh(GitHub), aws, gcloud — 은 동등한 MCP 서버를 엮는 대신 Claude가 Bash를 통해 CLI를 직접 호출하게 하세요. CLI는 컨텍스트에 상주하는 "도구 목록" 비용을 지지 않습니다.
• 타입 있는 언어에는 코드 인텔리전스. TypeScript/Java/Go에서는 "정의로 이동" 플러그인을 쓰면 Claude가 grep하고 파일 더미를 읽는 대신 정의로 곧장 점프할 수 있어, 대규모 코드베이스에서 파일 읽기 토큰을 눈에 띄게 줄입니다.

MCP를 이해하고 언제 쓰고 언제 쓰지 말지 알려면, 다음 그룹의 Claude Code의 hook 글을 보세요 — 이 두 메커니즘은 컨텍스트를 줄이기 위해 자주 함께 작동합니다.

그룹 4 — 무거운 작업을 hook과 skill에 넘기기

이것은 보상이 가장 크지만 활용하는 사람은 가장 적은 그룹입니다. 발상은 이렇습니다. 부피 큰 출력이 Claude의 컨텍스트로 곧장 흘러들지 않게 — 스크립트 계층에서 먼저 걸러 내거나 요약하세요.

테스트 출력을 거르는 hook. 큰 테스트 스위트를 한 번 돌리면 수만 줄이 찍힐 수 있지만, Claude가 알아야 할 것은 무엇이 FAILED했는지뿐입니다. FAIL/ERROR 줄만 남기는 PreToolUse/후처리 hook은 토큰 수를 수만에서 수백으로 끌어내릴 수 있습니다("비용을 효과적으로 관리하기" 문서에 따름). 필터 스크립트의 뼈대 예시입니다.

#!/usr/bin/env bash
# filter-test-output.sh - keep only failing lines, cut the noisy log
npm test 2>&1 | grep -E "(FAIL|ERROR|✕|Error:|Expected|Received)" | head -n 100

"codebase-overview" skill. 프로젝트 구조를 이해하려고 매번 Claude에게 20개 파일을 읽히는 대신, 아키텍처와 관례, 주요 모듈의 위치를 설명하는 skill을 패키지화하세요. skill은 필요할 때 로드되므로 컨텍스트에 영구히 상주하지 않습니다 — 하지만 필요할 때는 파일 읽기 세례 대신 즉각적인 컨텍스트를 줍니다.

CLAUDE.md는 가볍게 유지. Anthropic 문서는 CLAUDE.md를 ~200줄 미만으로 유지할 것을 권합니다. 이 파일의 모든 내용은 모든 요청에 로드되므로, 꽉 채우면 영구적인 토큰 세금이 됩니다. 전문적인 지시(배포 절차, 어느 모듈의 관례)는 필요할 때 로드되는 skill로 옮기고, CLAUDE.md에는 매 세션 정말로 쓰는 것만 남기세요.

그룹 5 — 대규모 코드베이스를 위한 subagent와 적시 검색

모노레포에서 첫째가는 적은 단일 컨텍스트가 저장소 전체를 "스캔"하게 두는 것입니다. 해법은 무거운 읽기를 메인 컨텍스트에서 떼어 내는 것입니다.

조사는 subagent에게 위임. "기능 X가 어디에 구현되어 있는지"를 조사해야 할 때는 그것을 subagent에게 넘기세요. subagent는 자신의 컨텍스트에서 여러 파일을 읽고 요약만 반환합니다 — Anthropic 엔지니어링 글에 따르면, 파일 내용 전체를 메인 컨텍스트에 쏟아붓는 대신 보통 겨우 ~1,000~2,000 토큰입니다. 자세한 절차는 Claude Code의 subagent 가이드를 보세요.

@ 참조로 적시 검색. Claude가 무턱대고 추측하고 grep하며 돌아다니게 두지 마세요. 필요한 것을, 필요할 때, 곧장 가리키세요.

@src/payment/checkout.ts # load exactly one file when needed
@src/payment/ # load exactly one directory

값비싼 재작업을 피하는 Plan 모드. Shift+Tab을 눌러 plan 모드에 들어가면 Claude는 편집하기 전에 계획을 세웁니다. 계획을 검토하는 것이, 여러 파일을 잘못 편집하게 두었다가 다시 해야 하는 것보다 훨씬 저렴합니다 — 재작업 루프는 하나하나가 토큰을 씁니다. 잘못된 방향으로 가면, 모든 것을 처음부터 다시 설명하는 대신 /rewind(또는 Esc를 두 번)로 이전 체크포인트로 돌아가세요.

이 그룹 전체를 묶는 원칙은 Anthropic에서 빌려 온 것입니다. 고신호 토큰을 최소한으로 지향하기 — 컨텍스트에 가능한 한 적게, 그러나 가장 값진 조각들만 정확히 넣는 것. 이것은 글 앞머리에서 언급한 컨텍스트 부패의 처방이기도 합니다.

그룹 6 — Advisor: 강력한 모델을 하루 종일 돌리지 않고 second opinion 얻기

Advisor는 메인 모델을 보통 더 강력한 두 번째 모델과 짝지웁니다 — 언제 상의할지는 Claude가 정하며, 대개 접근 방식을 확정하기 전, 반복되는 오류가 있을 때, 또는 작업 완료를 선언하기 전이지 매 턴은 아닙니다. 이것은 진짜배기 토큰 최적화 기법입니다. 강력한 모델을 세션 내내 돌리는 것보다 의미 있게 저렴하기 때문입니다.

/advisor opus(또는 다른 모델)로 켜거나, 설정에서 advisorModel을 지정하거나, 단일 세션용으로 --advisor를 넘기세요. 끄려면 /advisor off입니다.

비용 구조: 각 호출은 advisor 모델의 요율로 메인 모델 사용량 위에 얹혀 청구됩니다. 구독 요금제에서는 advisor 사용량도 다른 모든 것처럼 요금제 한도에 계산됩니다 — 단, Fable 5 advisor는 해당되는 요금제에서 사용 크레딧으로 청구됩니다. 세션 중간에 advisor를 토글해도 메인 모델의 프롬프트 캐시는 무효화되지 않습니다(advisor 자신의 대화 읽기만 캐시되지 않습니다).

솔직한 단서: 이것은 실험적 기능으로, Anthropic 직접 API를 통해서만 이용할 수 있고 — Amazon Bedrock, Google Cloud의 Agent Platform, Microsoft Foundry에서는 안 됩니다 — 동작과 가격은 바뀔 수 있습니다.

토큰 함정: 에이전트 팀, 동적 워크플로, 하루 종일 세션

이 두 가지는 알아채기 어려운 방식으로 조용히 사용량을 부풀립니다.

에이전트 팀은 ~7배 토큰 — 단, 팀원이 plan 모드로 돌 때만. 여러 에이전트로 이루어진 "팀"을 병렬로 돌리는 것은 강력해 보이지만, "비용을 효과적으로 관리하기" 문서는 팀원이 plan 모드로 돌 때 표준 세션의 대략 ~7배 토큰을 쓴다고 경고합니다 — 각 팀원이 자신의 컨텍스트 윈도우를 유지하고 별개의 Claude 인스턴스로 돌기 때문입니다. 쓰지 말아야 할 때: 순차적 작업, 작은 범위, 또는 토큰 예산이 빠듯할 때. 꼭 써야 한다면 팀원을 Sonnet으로 돌리고 끝나는 즉시 팀을 닫으세요.

동적 워크플로도 상한을 두지 않으면 사용량을 부풀릴 수 있습니다. 프롬프트에 키워드 ultracode를 치거나(또는 평이한 말로 "여기에 워크플로를 써"라고 부탁하면) Claude가 여러 subagent를 지휘하는 동적 워크플로를 작성하고 실행합니다 — 한 번 실행에 최대 1,000개 에이전트, 동시에 최대 16개까지요. 진행 상황은 /workflows로 지켜보세요. "Large workflow" 경고는 실행이 25개 에이전트를 넘겨 스케줄하거나 예상 토큰이 150만을 넘을 때 나타납니다(25개 에이전트 임계값은 /config에서 설정한 크기 가이드라인으로 대체됩니다 — 기본값은 medium, 15개 에이전트 미만입니다) — 이는 자문용일 뿐 실행을 멈추지 않습니다. 솔직히: 전체 워크플로 실행에 대한 공식 달러 수치는 없습니다. 전부 돌리기 전에 작은 조각으로 테스트하세요. 전체 메커니즘은 Claude Code의 동적 워크플로에서 보세요.

하루 종일 세션. 단일 세션을 아침부터 저녁까지 켜 두는 것은 토큰을 태우는 지름길입니다. 긴 컨텍스트는 부풀고, 자리를 비울 때마다 캐시가 계속 미스납니다. 캐싱에 관해 문서는 수명을 구독 요금제에서는 1시간, 사용 크레딧/API에서는 5분이라고 밝힙니다. 1시간 캐시는 환경 변수로 켤 수 있습니다.

ENABLE_PROMPT_CACHING_1H=1

좋은 습관: 작업을 바꿀 때는 /clear, 긴 휴식에는 세션을 닫기, 돌아오면 요약에서 재개하기. (안심을 위한 작은 메모: Claude Code 자동 작업의 백그라운드 토큰은 매우 저렴합니다 — 문서는 < $0.04/세션을 인용하니 그 부분은 걱정 마세요.)

요약 표 — 기법과 토큰 절감의 대응

토큰 ROI 순(높은 레버리지 / 낮은 노력이 위)으로 정렬했습니다. "절감" 열에 Anthropic 출처가 있는 경우 검증된 수치를 인용했습니다. 실제 코드베이스에서 측정하는 부분은 Jasmine이 테스트 세션에서 채울 자리입니다.

기성 키트(AgentKit)로 속도 높이기

위 기법의 상당수 — "codebase-overview" skill, 전문화된 subagent, 출력 거르는 hook — 은 효과적이지만 직접 만들고 다듬는 데 실제로 품이 듭니다. 컨텍스트가 최적화된 skill, subagent, hook 세트를 기성으로 갖고 싶다면, Claude Code용 AgentKit 키트가 이 도구 세트를 패키지화해 두어 처음부터 쓸 필요가 없습니다.

혼동을 피하기 위한 메모: 여기서 AgentKit(agentkit.best, CLI ak)은 Claude Code / Codex / Copilot용 키트로, OpenAI의 AgentKit과는 완전히 다른 것입니다. AgentKit 살펴보기(링크로 20% 할인) 하고 직접 판단해 보세요. 이것은 선택적 제안이지 필수가 아닙니다 — 이 글의 모든 기법은 손으로도 할 수 있습니다.

자주 묻는 질문(FAQ)

/compact와 /clear는 언제 구분해 쓰나요?

무관한 작업으로 전환할 때는 /clear를 쓰세요 — 컨텍스트를 리셋하고 "대화 꼬리" 비용을 거의 0으로 줄입니다. 같은 작업 흐름을 계속하고 싶은데 컨텍스트가 부풀었을 때는 /compact를 쓰세요 — 흐름을 유지하면서 기록을 요약으로 압축합니다.

Claude Code는 자동으로 compact하나요?

네. 컨텍스트가 가득 차기 직전에 세션이 끊기지 않도록 Claude Code가 자동 compact합니다. 편리하지만 세부 사항을 놓칠 수 있으니, 중요한 작업에서는 운에 맡기지 말고 직접 방향을 지정한 /compact를 실행하세요.

Opus를 쓰면 훨씬 비싼가요?

네 — 참고 API 가격 기준으로 Opus 5(100만 토큰당 입력/출력 $5/$25)는 Sonnet 5($2/$10)보다 약 2.5배 비쌉니다. 코딩의 대부분은 Sonnet에 맡기고, 아키텍처나 어려운 문제일 때만 /model로 Opus로 전환하세요.

내가 쓰는 토큰은 어떻게 보나요?

/usage를 치면 입출력 토큰 합계, 캐시 읽기/쓰기, 비용을 볼 수 있습니다. /context를 치면 현재 컨텍스트를 어떤 구성 요소가 차지하는지(CLAUDE.md, MCP 도구, 읽은 파일) 볼 수 있습니다. 각 변경 전후에 이 둘로 측정하세요.

대규모 코드베이스에서는 어디서부터 최적화해야 하나요?

먼저 /context로 측정한 다음, 가장 저렴한 두 레버를 우선하세요. 작업 사이의 /clear와 CLAUDE.md를 ~200줄 미만으로 줄이기. 그다음 과도한 MCP 줄이기, 조사에 subagent 쓰기, 테스트 출력을 거르는 hook으로 넘어가세요.

확장 사고를 끄는 것은 해로운가요?

그럴 수 있습니다. 사고를 끄면 출력 토큰은 아끼지만 깊은 추론이 필요한 작업(알고리즘 설계, 다층 디버깅)에서 품질이 낮아집니다. 단순한 작업에서만 /effort나 MAX_THINKING_TOKENS=8000으로 낮추고, 추론이 필요한 작업에는 사고를 남겨 두세요.

advisor 도구는 추가 토큰을 쓰나요?

네 — 각 호출은 advisor 모델의 요율로 메인 모델 사용량 위에 얹혀 청구되고, 다른 것과 마찬가지로 /usage에 계산됩니다. 하지만 Claude는 결정 지점(접근 방식 확정, 반복되는 오류, 완료 선언 전)에서만 advisor를 부르지 매 턴이 아니므로, 강력한 모델을 세션 내내 돌리는 것보다는 대개 여전히 저렴합니다.

동적 워크플로는 토큰을 얼마나 쓰나요?

공식 달러 수치는 없습니다. 런타임에는 폭주하는 비용을 묶어 두는 하드 상한이 있습니다 — 합계 최대 1,000개 에이전트, 동시에 최대 16개. 25개 에이전트/150만 토큰의 "Large workflow" 경고는 자문용일 뿐 실행을 멈추지 않습니다. 전부 돌리기 전에 작은 조각으로 테스트하세요.

결론과 다음 단계

Claude Code 토큰 최적화의 공식은 하나의 사슬에 담깁니다. 측정 → 컨텍스트 줄이기 → 모델 고르기 → hook/skill에 넘기기 → 대규모 코드베이스에는 subagent → 세션 내내 모델을 바꾸는 대신 advisor. 한꺼번에 다 하지 마세요. /context와 /usage로 측정하고, 표에서 ROI가 높은 2~3개 레버를 골라 적용한 뒤 다시 측정하세요. 절감 효과는 여러분의 코드베이스와 습관에 달려 있음을 기억하세요 — 본인 머신에서 측정하세요.

다음으로 읽기: compaction을 더 깊이 파려면 컨텍스트와 메모리 관리, 사용에 맞는 요금제를 고르려면 Claude Code 요금과 요금제, 큰 작업에서 여러 에이전트를 지휘해야 한다면 Claude Code의 동적 워크플로. 손으로 최적화하기보다 기성 도구 세트를 쓰고 싶다면 Claude Code용 AgentKit 리뷰를 확인하세요.