Claude Code 다이내믹 워크플로 완벽 정리: ultracode, /workflows, 1,000 에이전트 상한(2026)

- 이 글의 모든 수치와 버전 임계값은 작성 시점(2026년 8월)에 공식 문서(code.claude.com/docs/en/workflows)와 대조 확인했어요. 이 기능은 거의 매 릴리스마다 바뀌므로, 여기에 의존하기 전에 반드시 최신 문서를 확인하세요.

이 글은 고급 내용이에요. 이미 Claude Code를 서브에이전트와 스킬과 함께 쓰고 있는 독자를 대상으로 하며, 기초를 다시 설명하지는 않아요. 서브에이전트가 무엇인지 확실하지 않다면, 먼저 Claude Code 서브에이전트의 작동 방식이나 Claude Code 스킬이란 무엇인가를 읽어보세요.

dynamic workflow란 실제로 무엇인가

dynamic workflow는 별도의 UI 기능이 아니라 하나의 메커니즘이에요. 일단 트리거되면 Claude가 계획(무엇을 먼저 실행하고, 무엇을 병렬로 실행하고, 무엇이 이전 단계의 결과를 기다리는지)을 기술한 JavaScript 스크립트를 작성해요. 그 스크립트가 작업을 다수의 백그라운드 서브에이전트로 분산시키고, Claude는 메인 세션의 컨텍스트에 최종 결과만 남겨요. 각 서브에이전트의 추론 과정 전체를 남기지는 않고요.

이것을 일반적인 턴과 비교해 보세요. Claude에게 서브에이전트로 위임하도록 요청한 경우라도, 메인 세션은 다음에 무엇을 할지 판단하기 위해 각 서브에이전트의 출력을 자신의 컨텍스트에 담고 있어야 하며, 작업 도중에 세션을 닫으면 진행 중이던 추론은 사라져요. dynamic workflow는 "다음에 무엇을 할지"라는 판단을 대화에서 완전히 떼어내 스크립트 안으로 옮겨요. 이것이 메인 세션의 컨텍스트 윈도를 터뜨리지 않고 1,000개 에이전트 규모의 실행을 가능하게 하는 요인이에요.

메커니즘을 구체적으로 보여주는 예시예요(실측 데이터가 아니라 어디까지나 로직 설명이에요). src/ 디렉터리 전체를 보안 문제에 대해 감사하도록 Claude에게 요청한다고 해보세요. 작성되는 스크립트는 예를 들어 "각 하위 디렉터리를 저마다 전용 에이전트에 넘겨 스캔하게 하고, 문제를 찾은 에이전트는 증거와 함께 보고하며, 마지막에 한 에이전트가 모든 것을 표로 취합한다" 같은 형태가 될 수 있어요. 이 분기·대기·취합 로직 전체가 스크립트 파일 안에 놓이며, 서브에이전트를 직접 손으로 오케스트레이션할 때처럼 Claude의 작업 메모리 안에 놓이지는 않아요.

요구 사항은 Claude Code v2.1.154 이상 (버전 임계값이에요. 여기에 의존하기 전에 자신의 버전을 확인하세요)이며, 모든 유료 플랜에 더해 API/Bedrock/Vertex/Microsoft Foundry에서 사용할 수 있어요. Pro에서는 기본적으로 켜져 있지 않아요. /config의 "Dynamic workflows" 행에서 수동으로 켜야 해요. 이것을 auto-mode(2026-08-14부터 기본 활성화)와 혼동하지 마세요. 둘 다 대략 비슷한 시기의 릴리스에서 등장했더라도, auto-mode는 완전히 별개의 기능이며 dynamic workflows와는 무관해요.

Claude Code v2.1.154 이상이 필요해요(먼저 실제 버전을 확인하세요). 모든 유료 플랜에 더해 API/Bedrock/Vertex/Microsoft Foundry에서 동작해요. Pro 사용자는 /config에서 수동으로 활성화해야 하며, 기본적으로 켜져 있지 않아요.

트리거하는 두 가지 방법

dynamic workflow를 불러내는 방법은 두 가지이며, 하나의 작업에 쓰고 싶은지 세션 전체에 쓰고 싶은지에 따라 골라요.

대부분의 글이 건너뛰는 역사적 세부 사항이 있어요. 입력하는 키워드는 v2.1.160 이전에는 workflow였어요. 그러다 v2.1.160에서 ultracode로 이름이 바뀌었죠. 하지만 자연어 표현("이건 워크플로로 처리해줘")은 두 시기 모두에서 항상 작동했어요. 정확한 키워드에 의존한 적이 한 번도 없었죠. 오래된 문서나 게시물에서 "workflow라고 입력하라"고 되어 있다면, 그건 v2.1.160 이전의 명칭이에요.

기억해 둘 만한 함정이 있어요. 이 키워드는 사람이 입력한 텍스트에서만 발동해요. -p 플래그를 통해서도, Agent SDK의 비인간 입력을 통해서도, 예약된 작업을 통해서도, webhook이나 PR 코멘트 중계를 통해서도 발동하지 않아요. 이 중 어느 채널로든 Claude Code를 스크립트로 실행하고 있다면, 어딘가에 "ultracode"라고 적어도 그것만으로는 dynamic workflow가 트리거되지 않아요.

어느 방법을 고를지는 무엇을 하는지에 달려 있어요. 평소와 다름없는 세션 안에서 하나의 큰 작업을 다루는 경우(예를 들어 "ultracode: api/ 디렉터리의 모든 에러 처리를 감사해줘")에는 그 턴에만 키워드를 입력하면 충분해요. 세션의 나머지는 평소대로 돌아가고, 자잘한 작업에 불필요한 추론 오버헤드가 붙지 않아요. 세션 전체가 무거운 작업이 되리라는 걸 이미 알고 있다면(마이그레이션이나 감사를 위해 하루를 통째로 비워둔 경우), /effort ultracode를 쓰면 매 턴 키워드를 다시 입력하지 않아도 돼요. 다만 그 대가로, 해당 세션 안의 실질적인 작업은 모두 xhigh 추론으로 밀려 올라가며, 워크플로로 실행할 의도가 전혀 없던 것까지 포함돼요.

먼저 내장 /deep-research 워크플로를 써 보세요

별도 설정 없이 dynamic workflow가 실제로 도는 모습을 가장 빠르게 볼 수 있는 방법이 내장 /deep-research 워크플로예요.

1. /deep-research <your question>를 실행해요.
2. 실행 전에 Claude가 제안하는 계획을 승인해요.
3. /workflows로 진행 상황을 지켜봐요.
4. 최종 보고서를 읽어요. 출처가 달려 있어요.

흥미로운 부분은, 상호 검증에 통과하지 못한 주장은 걸러지고, 검증할 수 없는 주장은 단칼에 부정되는 대신 미검증으로 표시된다는 점이에요. 이것은 Claude가 자신만만하게 하나의 답을 지어내는 것과는 다른 실패 방식이에요. 이 워크플로에는 WebSearch 도구가 활성화되어 있어야 해요. 서브에이전트가 무엇인지 아직 흐릿하다면, 다음 섹션으로 넘어가기 전에 Claude Code 서브에이전트의 작동 방식을 읽어보세요.

먼저 써 볼 가치가 있는 이유는, 오케스트레이션 프롬프트를 직접 작성하지 않아도 되는 유일한 워크플로이기 때문이에요. Anthropic이 이미 "출처 찾기 → 상호 검증 → 약한 주장 걸러내기 → 출처 달린 보고서 작성" 로직을 그 안에 담아 두었어요. 구체적인 기술 질문(예를 들어 "Next.js 16과 Remix가 스트리밍 SSR을 어떻게 다루는지 비교해줘")으로 한 번 실행해 보면, 모든 dynamic workflow가 따르는 대략적인 형태가 보여요. 먼저 승인되는 계획, 단계마다 일일이 지켜보지 않아도 병렬로 도는 여러 에이전트, 그리고 하나의 미검증 답변이 아니라 이미 걸러진 최종 결과예요.

실행을 지켜보고 관리하기 — /workflows

/workflows를 입력하면 실시간 추적 뷰가 열려요. 현재 단계, 실행 중인 에이전트 수, 소비한 총 토큰, 경과 시간이 모두 실시간으로 갱신되는 한 화면에 표시돼요.

이 뷰는 보이는 것보다 더 중요해요. 실행이 주간 예산을 다 먹어치우기 전에, 얼마나 "먹고" 있는지를 알 수 있는 유일한 수단이거든요(비용은 아래에서 더 다뤄요). 대시보드 없이 CI 파이프라인을 돌리는 것과 같다고 생각하세요. 지켜보지 않아도 문제없이 끝날 수는 있지만, 큰 실행은 처음 몇 번은 눈여겨볼 가치가 있어요. 적어도 평소 넘기는 종류의 작업에서 토큰을 얼마나 태우는지 감이 잡힐 때까지는요.

켜기 전에 알아둬야 할 수치

이 기능을 큰 대상에 겨누기 전에 꼼꼼히 읽어둘 가치가 있는 섹션이에요. 이 수치들은 어느 것도, 직접 찾아 나서기 전까지는 UI에서 드러나지 않거든요.

하드 캡: 실행 한 번당 최대 1,000개 에이전트(폭주하는 루프가 영원히 도는 것을 방지), 그리고 동시 실행 최대 16개 에이전트(CPU에 제약이 있는 머신/컨테이너에서는 더 적음)예요. 1,000이라는 수치는 실행 전체의 천장이지 목표가 아니에요. 실제 작업 대부분은 훨씬 적은 에이전트로 끝나요. 이 상한은 정지 조건이 한 번도 발동하지 않을 때, 범위 설정이 엉성한 스크립트가 끝없이 에이전트를 생성하는 것을 막기 위해 특별히 존재해요.

크기 가이드라인은 권고 사항이지 하드 리밋이 아니에요(v2.1.202 이상 필요 - 버전 임계값이에요. 의존하기 전에 확인하세요). 에이전트 수를 기본값보다 낮게 유지하도록 Claude에게 강제하고 싶을 때 설정할 수 있어요.

대규모 워크플로 경고: 실행이 25개 에이전트 또는 150만 예상 토큰을 초과하면 발동해요(자신만의 크기 가이드라인을 설정했다면 25라는 값은 달라져요). 이건 권고일 뿐이고 실행을 멈추지는 않아요. 이미 /effort ultracode로 돌고 있는 세션에서는 이 경고가 표시되지 않아요. 그 모드를 택한 시점에서 이미 처음부터 대규모 실행을 받아들인 셈이거든요.

수치를 종합하면, 파일이 수십 개인 디렉터리를 대상으로 한 감사를 기본 medium 크기 가이드라인(15개 에이전트 미만)으로 돌릴 경우, 25개 에이전트 경고 임계값에는 거의 닿지 않아요. 하지만 저장소 전체에 걸쳐 200개 이상의 파일에 걸치는 마이그레이션이라면, 25개 에이전트와 150만 토큰을 둘 다 손쉽게 넘길 수 있어요. 그럴 때는 실행 도중에 놀라기보다, 크기 가이드라인을 일부러 large로 설정하는(또는 경고를 받아들이는) 편이 나아요. 다시 말해 1,000/16/25라는 수치는 이 기능에서 멀어지게 하려는 게 아니라, Enter를 누르기 전에 "지금 넘기려는 게 얼마나 큰가"를 가늠할 수 있게 하려는 거예요.

워크플로 vs 서브에이전트 vs 스킬 vs 에이전트 팀 — 누가 계획을 쥐는가

이미 서브에이전트와 스킬을 쓰고 있다면 이게 가장 중요한 질문이에요. 이 넷의 차이는 누가 오케스트레이션 계획을 쥐는가에 있지, 어느 것이 "더 강한가"에 있지 않아요.

쉽게 말하면, 서브에이전트와 스킬은 각 단계를 Claude 스스로 결정하게 하며, 그 세션의 컨텍스트 윈도에 제약돼요. 에이전트 팀(실험적 기능 — 멀티 세션 협업을 위한 에이전트 팀 참고)은 공유 작업 목록을 통해 동료 에이전트를 감독하는 리드 에이전트로, 긴 협업 세션에 적합해요. dynamic workflow가 다른 점은 계획이 Claude의 컨텍스트가 아니라 스크립트 안에 놓인다는 거예요. 그래서 메인 컨텍스트는 과정 전체가 아니라 최종 답만 쥐고 있으면 돼요.

빠른 선택: 일상적인 위임 → 서브에이전트/스킬. 지속적인 감독이 필요한 길고 협업적인 세션 → 에이전트 팀. 컨텍스트 윈도 하나보다 큰 작업, 또는 적대적 상호 검증(여러 에이전트가 서로의 결과를 검증)이 필요한 작업 → dynamic workflow. 자신만의 재사용 가능한 서브에이전트를 정의하고 싶나요? 서브에이전트 가이드를 참고하세요. 먼저 스킬 기초가 필요하다면 Claude Code 스킬이란 무엇인가를 참고하세요.

이 넷 사이에서 가장 흔한 혼동은 이래요. 서브에이전트와 스킬은 둘 다 메인 세션의 Claude가 판단하게 하며, 차이는 스킬이 컨텍스트로 로드되는 지시 묶음인 반면 서브에이전트는 하나의 일을 처리하고 결과를 돌려주기 위해 호출되는 별도의 "페르소나"라는 점뿐이에요. 둘 다 그 세션의 컨텍스트 윈도와 함께 살고 죽어요. 세션을 도중에 중단하면 진행분은 사라지죠. 에이전트 팀과 dynamic workflows는 둘 다 그 한계를 벗어나지만, 방식이 달라요. 에이전트 팀은 단일 에이전트의 컨텍스트보다 오래 남는 공유 작업 목록을 통해 여러 세션이 협업하게 함으로써 벗어나요. dynamic workflows는 계획을 컨텍스트에서 완전히 끄집어내, 저장하고 git으로 버전 관리하고 언제든 동일하게 재실행할 수 있는 객체로 바꿈으로써 벗어나요. 이것이 바로 탐색적 대화보다 크고 반복 가능한 작업에 더 잘 맞는 이유예요.

마음에 드는 워크플로를 재사용 가능한 명령으로 저장하기

마음에 드는 실행이 있나요? 다음에 Claude가 스크립트를 처음부터 다시 쓰지 않도록 저장해 두세요.

1. /workflows를 열고 남겨두고 싶은 실행을 선택해요.
2. s를 눌러 저장해요.
3. 위치를 골라요. .claude/workflows/(공유, 프로젝트 범위) 또는 ~/.claude/workflows/(개인용).
4. 저장된 워크플로는 /<name> 명령이 되고, args 파라미터를 통해 입력을 받을 수 있어요.

팀으로 일한다면, 워크플로를 플러그인(workflows/ 디렉터리) 안에 담아 배포하고, 네임스페이스가 붙은 /plugin-name:workflow-name으로 호출할 수도 있어요. 명령을 복사·붙여넣기 하는 대신, 오케스트레이션 스크립트를 팀 전체에 공유하기에 편리해요.

워크플로를 파일로 저장하는 장점은, .claude/workflows/ 아래에 순수 텍스트 파일로 존재하기 때문에 저장소 안의 다른 것들처럼 git에 커밋할 수 있다는 거예요. 브랜치를 pull한 팀원은 같은 워크플로를 자동으로 얻어요. Claude가 여러분이 이미 다듬어 놓은 감사나 마이그레이션 방식을 "다시 배울" 필요가 없죠. 이것은 서브에이전트나 스킬과의 가장 분명한 차이이기도 해요. 여러분이 즐겨 쓰는 서브에이전트가 저절로 팀원도 동일하게 호출할 수 있는 것이 되지는 않지만, 저장된 dynamic workflow는 그렇게 돼요.

토큰 비용의 현실

솔직히 말하면, 공식 문서는 dynamic workflows에 대해 고정된 금액을 전혀 제시하지 않아요. 이 섹션을 완성된 것처럼 보이게 하려고 제가 숫자를 지어내지도 않을 거예요. "월 200달러 Max 플랜이 하루 만에 주간 한도의 20%를 태웠다"는 식의 이야기가 돌고 있는데, 확인해 보니 그것은 일차 자료도 독립적으로 검증 가능한 출처도 아니라, 소셜 미디어 보고를 종합한 블로그 글로 거슬러 올라가더군요. 그래서 여기서 그 숫자를 되풀이하지는 않을게요.

문서가 분명히 말하는 것은 이거예요. 두 개의 하드 캡(1,000개 에이전트 / 동시 16개)은 바로 폭주하는 비용을 묶어두기 위해 존재해요. 각 서브에이전트는 메인 세션의 모델을 써요. 스크립트나 CLAUDE_CODE_SUBAGENT_MODEL 변수가 다른 곳으로 라우팅하는 경우만 예외예요.

실용적이고 문서에 근거한 조언이에요.

• 전체 실행 전에, 먼저 작은 일부(저장소 전체가 아니라 디렉터리 하나)에서 시험해요.
• 실행 중에는 /workflows에서 에이전트별 총 토큰을 실시간으로 지켜봐요.
• 기본값보다 적은 에이전트 수로 강제하고 싶다면 크기 가이드라인을 small로 낮춰요.

제가 저만의 추정치를 지어내지 않는 이유는, 실제 비용이 한꺼번에 너무 많은 변수에 좌우되기 때문이에요. 각 하위 작업이 얼마나 오래 도는지, 세션에 어떤 모델이 설정되어 있는지, 스크립트 자체가 분기마다 몇 개의 에이전트를 생성하기로 결정하는지. 그래서 어떤 단일 "평균" 수치도 도움보다 오해를 더 많이 줄 거예요. 훨씬 안전한 접근은 자신의 워크로드를 직접 측정하는 거예요. 작게 한 차례 실행하고, /workflows에서 토큰 수를 읽고, 실제로 돌리려는 규모로 대략 선형으로 스케일해 보세요. 누군가 소셜 미디어에서 주워 온 숫자를 믿는 것보다 훨씬 확실해요.

AgentKit이 이걸 제공하나요? (솔직한 답변)

이미 AgentKit을 쓰고 있다면 물어볼 만한 질문이 있어요. AgentKit에는 자체 "워크플로"라는 게 있고, 그게 이것과 같은 건가요? 곧바로 답하면 아니요예요. Dynamic Workflows는 네이티브 Claude Code 엔진이며, 이 글이 설명하는 바로 그 JavaScript 스크립트 기반 에이전트 분산 메커니즘이에요. AgentKit은 그 엔진을 담고 있지 않고, ak 쪽에 상응하는 것도 없어요.

docs.agentkit.best/en/beta/reference/cli를 직접 확인했어요(2026년 8월). AgentKit 사이트의 "workflow"라는 단어는 그 스킬 번들을 가리키는 일반적인 마케팅 문구이고, ak orchestrate 명령은 완전히 다른 기능이에요. 외부 CLI 도구용 잡 그래프로, macOS 전용이며 Claude Code의 dynamic workflows와는 무관해요.

그러면 AgentKit은 실제로 무엇을 주나요? 엄선되고 라이선스된 스킬과 서브에이전트 페르소나 세트(/ak:cook 같은 명령으로 호출)예요. 스크립트를 직접 쓰든 Claude에게 쓰게 하든, dynamic workflow를 이쪽으로 겨눠, 다른 서브에이전트와 똑같이 개별 에이전트 작업으로 쓸 수 있어요. 요컨대, 미리 만들어진 스킬/페르소나 레이어가 필요하면 AgentKit을 사고, 대규모 오케스트레이션 레이어에는 Dynamic Workflows(무료, 네이티브)를 쓰세요. 둘은 경쟁하지 않고 쌓여요. 더 알고 싶다면 AgentKit 전체 리뷰를 읽어보세요.

두 레이어가 어떻게 맞물리는지 보여주는 예시예요(실측 결과가 아니라 어디까지나 사용 패턴이에요). 다섯 개의 마이크로서비스에 걸쳐 보안을 감사하는 dynamic workflow는, 각 서비스를 AgentKit의 ak-security 스킬을 돌리는 에이전트에 넘기고, 마지막에 한 에이전트가 다섯 개 모두의 결과를 취합하게 할 수 있어요. 오케스트레이션 스크립트(무엇을 병렬로 실행하고 무엇이 무엇을 기다리는지)는 Dynamic Workflows의 것이고, 각 에이전트 안의 도메인 노하우는 여러분이 산 스킬의 것이에요. AgentKit을 빼도 워크플로는 여전히 돌아가요. 각 에이전트가 그 일을 위해 만들어진 스킬 대신 Claude의 일반 지식으로 폴백할 뿐이에요.

오늘 이걸 켜야 할까요

여기에 만능의 답은 없어요. 이건 딱 잘라 예/아니요를 말하는 것보다 솔직하고 더 쓸모 있는 결론이에요. 올바른 판단은 기능이 새롭고 흥미로운지가 아니라, 다음 작업이 실제로 얼마나 크고 얼마나 반복 가능한지에 달려 있어요. 짧은 결론: 세션 전체에 /effort ultracode를 설정하기로 정하기 전에, 먼저 실재하는, 범위가 한정된 작업 하나(저장소 전체 마이그레이션이 아니라 단일 디렉터리 감사)에서 ultracode 키워드를 시험해 보세요. 잘 맞는 경우: 대규모 마이그레이션, 코드베이스 전반 감사, 여러 출처에 걸친 상호 검증이 필요한 리서치. 건너뛸 경우: 일상적인 자잘한 편집, 또는 여유가 없는 비용 민감한 Pro 플랜을 쓰는 경우.

Enter를 누르기 전 빠른 체크리스트예요. (1) 그 작업이 독립적인 분기로 나눌 만큼 정말로 큰가, 아니면 사실은 손으로 하는 편이 더 빠른 순차적 연쇄인가. (2) /workflows를 열어 두고 정말로 지켜볼 것인가, 아니면 자리를 뜰 계획인가. (3) 이 실행이 도중에 실패한다면, 이미 소비한 토큰을 감수할 수 있는가. 셋 다 "예"라면 켜고 진행하세요. (1)이 "아니요"라면, 대개는 평범한 서브에이전트가 여전히 더 빠르고 더 저렴해요.

FAQ

Claude Code에서 ultracode란 무엇인가요?

ultracode는 dynamic workflow를 트리거하는 키워드(및 effort 설정)예요. Claude가 JS 스크립트를 작성해 하나의 작업을 최대 1,000개의 백그라운드 서브에이전트로 분산시켜요. "ultracode"라고 입력하든, "이건 워크플로로 처리해줘"처럼 자연스럽게 표현하든 둘 다 트리거돼요.

하나의 dynamic workflow는 몇 개의 에이전트를 실행할 수 있나요?

실행 한 번당 최대 1,000개 에이전트, 동시 실행은 최대 16개예요(CPU에 제약이 있는 머신/컨테이너에서는 더 적어요). 이것들은 권장치가 아니라 하드 캡이에요.

대규모 워크플로 경고는 무엇 때문에 뜨나요?

실행이 25개 에이전트 또는 150만 예상 토큰을 초과할 때예요(25라는 값은 자신의 크기 가이드라인에 따라 달라져요). 권고일 뿐이고 실행을 멈추지는 않아요.

dynamic workflow는 에이전트 팀과 같은 건가요?

아니요. 에이전트 팀은 공유 작업 목록을 통해 동료 에이전트를 감독하는 리드 에이전트로, 긴 협업 세션에 적합한 (실험적) 기능이에요. dynamic workflow의 계획은 Claude의 컨텍스트가 아니라 미리 작성된 스크립트 안에 놓이며, 저장해 두고 동일하게 재실행할 수 있어요. 에이전트 팀은 일반적으로 같은 방식으로 두 번 재생할 수 없어요.

유료 플랜이 필요한가요?

네. 모든 유료 플랜에 더해 API/Bedrock/Vertex/Microsoft Foundry에서 동작해요. Pro 사용자는 /config의 "Dynamic workflows" 행에서 수동으로 활성화해야 하며, 기본적으로 켜져 있지 않아요.

AgentKit에 Claude Code의 dynamic workflows가 포함되나요?

아니요. Dynamic Workflows는 네이티브이고 무료인 Claude Code 엔진이에요. AgentKit은 별개의 유료 스킬 및 서브에이전트 페르소나 세트로, dynamic workflow 안에서 개별 에이전트 작업으로 쓸 수 있어요. 둘은 서로 보완하는 관계이며, 같은 것이 아니에요.

결론

dynamic workflows는 파워 유저용 기능이에요. 실재하는 상한(1,000개 에이전트 / 동시 16개), 25개 에이전트 / 150만 토큰에서의 권고 경고가 있고, AgentKit의 스킬 레이어를 대체하는 게 아니라 함께 짝지어 써요. 세션 전체에 켜기 전에 작은 것에서 먼저 시험하고, /workflows를 열어 두어 무엇에 얼마를 쓰고 있는지 늘 파악하세요. 버전 게이트는 빠르게 움직이므로, 이 글의 모든 임계값은 절대적 진리가 아니라 출발점으로 여기고, 중요한 대상에 실제로 이걸 켜는 바로 그날 최신 문서로 다시 확인하세요.