AI 에이전트에게 맥락(context) 은 매우 중요하지만 동시에 유한한 자원이다. 이 글에서는 에이전트를 움직이게 하는 맥락을 어떻게 효과적으로 선별하고 관리할 수 있는지에 대한 전략을 살펴본다.
적용형 AI 분야에서 몇 년 동안 프롬프트 엔지니어링 이 주목의 중심이었다면, 이제는 새로운 용어인 컨텍스트 엔지니어링(context engineering) 이 부상하고 있다. 언어 모델을 활용한 개발은 더 이상 프롬프트에 어떤 단어와 표현을 넣을지의 문제가 아니라, “모델이 우리가 원하는 행동을 하도록 만들기 위해 어떤 맥락 구성이 가장 적절한가?”라는 더 넓은 질문으로 옮겨가고 있다.
여기서 맥락(context) 이란 대형 언어 모델(LLM)이 응답을 생성할 때 함께 주어지는 토큰들의 집합을 뜻한다. 컨텍스트 엔지니어링의 핵심 과제는, LLM이 가진 본질적 제약 안에서 이 토큰들의 효용을 최적화하여 원하는 결과를 일관되게 얻도록 만드는 것이다. 효과적으로 LLM을 다루려면 결국 맥락 중심으로 사고해야 한다. 즉, 특정 시점에 모델에게 어떤 전체 상태가 주어져 있는지, 그리고 그 상태가 어떤 행동을 유도할 수 있는지를 총체적으로 고려해야 한다는 뜻이다.
이 글에서는 컨텍스트 엔지니어링이라는 새롭게 떠오르는 기술과 감각을 살펴보고, 보다 조종 가능하고 효과적인 에이전트를 구축하기 위한 정교한 사고 모델을 제안한다.
컨텍스트 엔지니어링 vs. 프롬프트 엔지니어링
Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 확장으로 본다. 프롬프트 엔지니어링은 좋은 결과를 얻기 위해 LLM 지시문을 작성하고 정리하는 방법을 뜻한다. 반면 컨텍스트 엔지니어링은, 추론 시점에 최적의 토큰 집합(정보) 을 선별하고 유지하는 전략 전반을 의미한다. 여기에는 프롬프트뿐 아니라, 그 외에 맥락 안으로 들어오는 여러 정보까지 모두 포함된다.
초기 LLM 활용 시기에는 프롬프트가 AI 엔지니어링 작업의 핵심이었다. 일상적인 대화를 제외한 대부분의 활용 사례가, 한 번의 분류나 텍스트 생성 같은 작업에 최적화된 프롬프트를 필요로 했기 때문이다. 말 그대로 프롬프트 엔지니어링은, 특히 시스템 프롬프트를 어떻게 잘 쓸 것인가에 초점을 맞춘다. 하지만 이제 여러 차례 추론을 반복하고 더 긴 시간 동안 동작하는 고도화된 에이전트를 설계하게 되면서, 우리는 단순히 프롬프트만이 아니라 전체 맥락 상태(system instructions, tools, MCP, 외부 데이터, 메시지 이력 등) 를 어떻게 관리할지를 고민해야 한다.
루프 안에서 동작하는 에이전트는 다음 추론에 도움이 될 수 있는 데이터를 점점 더 많이 만들어낸다. 이 정보는 매 턴마다 다시 정제되어야 한다. 따라서 컨텍스트 엔지니어링이란, 계속 변화하는 방대한 정보 후보군 속에서 제한된 컨텍스트 창에 무엇을 넣을지 선별하는 기술이자 과학 이라고 할 수 있다.
프롬프트 작성이 비교적 한 번의 설계 작업에 가깝다면, 컨텍스트 엔지니어링은 반복적이다. 매번 모델에 무엇을 넘길지 결정할 때마다 이 선별 작업이 다시 일어난다.
왜 컨텍스트 엔지니어링이 중요한가
LLM은 빠르고 많은 데이터를 다룰 수 있지만, 사람처럼 일정 수준을 넘어서면 초점을 잃거나 혼란을 겪는다. 이른바 “needle in a haystack”류의 벤치마크에서는 context rot 라는 개념이 드러난다. 즉, 컨텍스트 창 안에 들어가는 토큰 수가 많아질수록, 모델이 그 안의 정보를 정확히 회상하는 능력이 떨어진다.
모델마다 저하 양상이 완만한 경우도 있지만, 이런 특성은 사실상 모든 모델에서 나타난다. 따라서 컨텍스트는 유한한 자원 이며, 많이 넣는다고 항상 더 좋아지는 것도 아니다. 사람의 작업 기억이 한정돼 있듯, LLM 역시 큰 맥락을 처리할 때 사용하는 일종의 주의(attention) 예산 이 있다. 새로운 토큰이 추가될 때마다 이 예산은 소모되고, 그만큼 어떤 토큰을 넣을지 더 신중하게 골라야 한다.
이 주의 자원의 희소성은 LLM의 구조적 특성에서 비롯된다. LLM은 트랜스포머 구조를 기반으로 하고, 이 구조에서는 모든 토큰이 전체 컨텍스트 내의 다른 모든 토큰을 바라볼 수 있다. 따라서 토큰 수가 n개라면, 가능한 쌍 관계는 n² 수준으로 늘어난다.
컨텍스트 길이가 길어질수록 모델이 이 많은 관계를 모두 포착하기는 점점 어려워진다. 자연스럽게 컨텍스트 크기와 집중력 사이의 긴장 관계 가 생긴다. 게다가 모델은 학습 데이터에서 보통 짧은 시퀀스를 더 많이 접했기 때문에, 긴 컨텍스트 전반에 걸친 의존관계에 대해서는 상대적으로 덜 최적화되어 있다.
위치 인코딩 보간 같은 기법을 통해 원래보다 긴 시퀀스를 처리할 수 있게 만들 수는 있지만, 이 경우 토큰 위치를 이해하는 정밀도에는 다소 손실이 생긴다. 그래서 성능 저하는 절벽처럼 갑자기 무너지는 형태가 아니라 점진적 하락 곡선 으로 나타난다. 긴 컨텍스트에서도 모델은 여전히 강력하지만, 정보 검색이나 장거리 추론의 정밀도는 짧은 컨텍스트에서보다 떨어질 수 있다.
이런 이유 때문에, 강력한 에이전트를 만들려면 컨텍스트 엔지니어링이 필수적이다.
효과적인 컨텍스트의 구조
LLM이 유한한 주의 예산 안에서 동작한다는 점을 감안하면, 좋은 컨텍스트 엔지니어링이란 결국 원하는 결과를 최대한 잘 끌어내는 최소한의 고신호(high-signal) 토큰 집합 을 찾는 일이다. 말은 쉽지만 실제 구현은 어렵다. 아래에서는 이 원칙이 컨텍스트의 각 구성 요소에 대해 실제로 무엇을 의미하는지 살펴본다.
시스템 프롬프트
시스템 프롬프트는 아주 명확해야 하며, 단순하고 직접적인 언어로 적절한 추상화 수준에서 아이디어를 전달해야 한다. 여기서 적절한 수준이란 흔히 보이는 두 가지 실패 지점 사이의 “골디락스 존”이다.
한쪽 극단에서는, 원하는 에이전트 행동을 끌어내기 위해 지나치게 복잡하고 깨지기 쉬운 로직을 프롬프트 안에 하드코딩하는 경우가 있다. 이런 방식은 취약하고 유지보수 비용도 커진다. 반대 극단에서는, 너무 추상적이고 두루뭉술한 지침만 주어서 모델이 실제로 무엇을 해야 하는지 구체적 신호를 받지 못하거나, 마치 이미 맥락이 공유된 것처럼 가정하는 경우도 있다. 최적의 수준은 행동을 효과적으로 유도할 만큼 구체적이되, 동시에 모델이 스스로 판단할 수 있는 유연성도 남겨두는 것 이다.
Anthropic은 시스템 프롬프트를 <background_information>, <instructions>, ## Tool guidance, ## Output description 같은 식으로 구분된 섹션으로 나누고, XML 태그나 Markdown 헤더로 구획하는 방식을 권장한다. 다만 모델이 점점 더 강력해짐에 따라, 정확히 어떤 형식을 쓰는지가 예전만큼 중요하지는 않을 수 있다.
어떤 구조를 쓰든 핵심은, 기대하는 행동을 충분히 설명하면서도 가능한 최소한의 정보만 제공하는 것 이다. 단, 최소하다고 해서 무조건 짧아야 한다는 뜻은 아니다. 에이전트가 올바르게 행동하려면 필요한 정보는 충분히 줘야 한다. 가장 좋은 방법은 우선 강력한 모델에 최소 프롬프트로 테스트해 보고, 실제 실패 사례를 바탕으로 명확한 지시나 예시를 점진적으로 추가해 나가는 것이다.
도구(tools)
도구는 에이전트가 환경과 상호작용하고, 작업 중 새로운 맥락을 끌어올 수 있게 해준다. 도구는 에이전트와 정보/행동 공간 사이의 계약을 정의하기 때문에, 토큰 효율적인 정보를 반환하고 효율적인 에이전트 행동을 유도하는 방식으로 설계되는 것 이 매우 중요하다.
Anthropic은 이전 글 Writing tools for AI agents – with AI agents 에서, LLM이 잘 이해할 수 있고 기능 중복이 적은 도구를 설계하는 방법을 다룬 바 있다. 잘 설계된 코드베이스의 함수처럼, 도구도 자기완결적이고 오류에 강하며, 어떤 상황에서 써야 하는지가 아주 명확해야 한다. 입력 파라미터 역시 설명적이고 모호하지 않아야 하며, 모델의 장점을 잘 활용할 수 있어야 한다.
자주 보이는 실패 사례 중 하나는 기능이 지나치게 많거나, 어떤 상황에서 어느 도구를 써야 할지 애매한 비대한 도구 세트 다. 인간 엔지니어도 특정 상황에서 어떤 도구를 써야 할지 분명히 말하지 못한다면, AI 에이전트가 더 잘해주길 기대할 수는 없다. 또한 나중에 설명하겠지만, 에이전트에게 필요한 최소한의 도구 집합만 선별하는 것은 장기 상호작용에서 컨텍스트를 유지·정리하는 데도 더 유리하다.
예시(few-shot examples)
예시를 제공하는 것, 즉 few-shot prompting은 여전히 강력한 모범 사례다. 하지만 많은 팀이 가능한 모든 엣지 케이스를 프롬프트에 몰아넣어, 모델이 따라야 할 모든 규칙을 설명하려고 한다. Anthropic은 이런 방식은 권장하지 않는다. 대신 에이전트가 기대된 행동을 잘 드러내는 다양하고 대표적인 예시 세트 를 선별할 것을 권한다. LLM에게 예시는 말 천 마디보다 강한 “그림”과도 같다.
시스템 프롬프트, 도구, 예시, 메시지 이력 등 컨텍스트의 모든 요소에 대해 Anthropic이 일관되게 제시하는 원칙은 이것이다. 정보는 충분히 담되, 군더더기 없이 타이트하게 유지하라. 이제 런타임에 동적으로 컨텍스트를 가져오는 방법으로 넘어가 보자.
컨텍스트 검색과 에이전트형 탐색
Anthropic은 Building effective AI agents 에서 LLM 기반 워크플로우와 에이전트의 차이를 설명했다. 그 이후, 에이전트를 아주 단순하게 정의하게 되었다. 즉, LLM이 도구를 자율적으로 반복 사용하면서 동작하는 것 이다.
고객들과 함께 작업하면서, 업계가 이 간단한 패러다임으로 수렴하고 있음을 보았다. 기반 모델이 더 강력해질수록 에이전트의 자율성도 커진다. 더 똑똑한 모델일수록 복잡한 문제 공간을 스스로 탐색하고, 오류에서도 회복할 수 있기 때문이다.
이제 많은 AI 네이티브 애플리케이션은, 추론 전에 임베딩 기반 검색을 통해 중요한 맥락을 먼저 불러오는 방식을 쓴다. 그런데 점점 더 에이전트적인 접근으로 옮겨가면서, 팀들은 이런 사전 검색 시스템에 “just in time” 컨텍스트 전략 을 덧붙이기 시작했다.
이 접근에서는 관련 데이터를 미리 전부 넣는 대신, 파일 경로, 저장된 쿼리, 웹 링크 같은 가벼운 식별자 만 들고 있다가, 필요할 때 도구를 통해 데이터를 동적으로 불러온다. Anthropic의 코딩 에이전트인 Claude Code는 이 방식을 이용해 큰 데이터베이스에 대한 복잡한 분석을 수행한다. 모델은 필요한 쿼리를 직접 작성하고, 결과를 저장하고, head, tail 같은 Bash 명령어를 활용해 거대한 데이터를 분석하면서도 전체 객체를 한 번에 컨텍스트에 올리지 않는다.
이 방식은 인간의 인지 방식과도 닮아 있다. 우리는 방대한 정보를 통째로 외우기보다, 파일 시스템, 받은편지함, 북마크 같은 외부 정리 체계를 만들어 놓고 필요할 때 찾아 쓴다.
이 방식의 장점은 저장 효율성만이 아니다. 이런 참조 정보의 메타데이터는 에이전트의 행동을 효율적으로 조정하는 단서도 된다. 예를 들어 파일 시스템 안에서 에이전트가 tests 폴더에 있는 test_utils.py 를 보면, 같은 이름의 파일이 src/core_logic/ 안에 있을 때와는 다른 역할을 암시받는다. 폴더 구조, 이름 규칙, 타임스탬프 같은 것들이 모두 어떤 정보가 무엇이고 언제 활용해야 하는지에 대한 신호 가 된다.
에이전트가 스스로 탐색하며 데이터를 불러오게 하면 점진적 공개(progressive disclosure) 도 가능해진다. 즉, 탐색을 통해 조금씩 관련 맥락을 발견해 가는 방식이다. 각 상호작용은 다음 결정을 돕는 새로운 맥락을 제공한다. 파일 크기는 복잡도를 암시하고, 이름 규칙은 용도를 짐작하게 하며, 타임스탬프는 관련성의 단서가 될 수 있다. 에이전트는 이렇게 한 층씩 이해를 조립해 나가면서, 당장 필요한 정보만 작업 기억 안에 유지하고 나머지는 메모 같은 외부 장치에 맡길 수 있다. 이 자기주도형 컨텍스트 관리 덕분에, 에이전트는 방대한 전체 정보에 압도되지 않고 필요한 부분에 집중할 수 있다.
물론 대가도 있다. 런타임 탐색은 미리 계산된 데이터를 가져오는 것보다 느리다. 게다가 LLM이 정보 공간을 효과적으로 탐색할 수 있도록 하려면, 적절한 도구와 휴리스틱을 신중하게 설계해야 한다. 그렇지 않으면 에이전트는 도구를 잘못 쓰거나, 막다른 길을 쫓거나, 핵심 정보를 놓치면서 컨텍스트를 낭비할 수 있다.
어떤 환경에서는 하이브리드 전략이 더 좋을 수도 있다. 일부 데이터는 속도를 위해 미리 불러오고, 나머지는 에이전트가 필요할 때 자율적으로 탐색하도록 두는 방식이다. 어떤 수준의 자율성이 적절한지는 작업의 성격에 달려 있다. Claude Code 역시 이 하이브리드 방식을 쓴다. CLAUDE.md 파일은 단순하게 초기에 컨텍스트에 넣고, glob 이나 grep 같은 기본 기능을 통해 환경을 탐색하며 파일을 적시에 불러온다. 이렇게 하면 오래된 인덱스나 복잡한 구문 트리 문제를 피해갈 수 있다.
법률이나 금융처럼 비교적 덜 동적인 영역에서는 이런 하이브리드 전략이 더 잘 맞을 수 있다. 모델 성능이 좋아질수록 에이전트 설계는 점점 더 “똑똑한 모델이 똑똑하게 행동하도록” 허용하는 방향으로 가게 될 것이다. 하지만 지금으로서는, Claude 위에서 에이전트를 만드는 팀에게 가장 좋은 조언은 여전히 이것이다. “작동하는 가장 단순한 방법부터 하라.”
장기 과제를 위한 컨텍스트 엔지니어링
장기 과제(long-horizon tasks)는 수많은 행동을 거치는 동안 일관성, 맥락, 목표 지향적 행동을 유지해야 한다. 그런데 그런 과제는 대개 필요한 토큰 수가 LLM의 컨텍스트 창 한계를 넘어서게 된다. 수십 분에서 몇 시간에 이르는 작업, 예를 들어 대규모 코드베이스 마이그레이션이나 종합 리서치 프로젝트 같은 경우, 컨텍스트 창 한계를 우회하기 위한 특별한 기법이 필요하다.
“그냥 더 큰 컨텍스트 창을 기다리면 되지 않나?”라고 생각할 수도 있다. 하지만 적어도 강력한 에이전트 성능이 필요한 상황에서는, 앞으로도 한동안 컨텍스트 오염과 정보 관련성 문제 는 컨텍스트 크기와 무관하게 계속 남을 가능성이 높다. 그래서 Anthropic은 이 문제를 직접 다루는 몇 가지 기법을 발전시켜 왔다. 대표적으로 컴팩션(compaction), 구조화된 메모(note-taking), 멀티 에이전트 구조 가 있다.
컴팩션
컴팩션은 컨텍스트 창 한계에 가까워진 대화를 요약한 뒤, 그 요약을 바탕으로 새로운 컨텍스트 창을 다시 시작하는 방식이다. 보통 장기적 일관성을 확보하기 위한 첫 번째 수단으로 쓰인다. 본질적으로 컴팩션은 기존 컨텍스트의 내용을 충실하게 압축 하여, 성능 저하를 최소화한 채 작업을 이어가게 해준다.
예를 들어 Claude Code에서는 메시지 이력을 모델에 넘겨, 가장 중요한 내용을 요약하고 압축하게 한다. 모델은 아키텍처 결정, 미해결 버그, 구현 세부사항은 남기고, 중복된 도구 출력이나 불필요한 메시지는 버린다. 이후 에이전트는 이 압축된 요약과 최근에 접근한 파일 다섯 개만 가지고 작업을 이어간다. 사용자는 컨텍스트 창 한계를 의식하지 않아도 자연스럽게 연속성을 유지할 수 있다.
컴팩션의 핵심은 무엇을 남기고 무엇을 버릴지 정하는 데 있다. 지나치게 공격적으로 압축하면, 나중에서야 중요성이 드러나는 미묘하지만 핵심적인 맥락을 잃을 수 있다. 컴팩션 시스템을 설계하는 엔지니어에게 Anthropic은 복잡한 에이전트 실행 로그를 바탕으로 프롬프트를 세심하게 튜닝할 것을 권한다. 먼저 재현율(recall) 을 최대화해 중요한 정보를 빠짐없이 잡아내고, 그다음 정밀도(precision) 를 높여 불필요한 내용을 덜어내는 방식이다.
가장 손쉬운 불필요 요소 제거 예시는 도구 호출 결과 지우기 다. 오래전에 호출한 도구의 원시 결과를 에이전트가 계속 다시 볼 필요가 있을까? Anthropic은 이런 방식의 가벼운 컴팩션을 Claude Developer Platform에 이미 기능으로 도입했다.
구조화된 메모
구조화된 메모, 또는 에이전트 메모리는 에이전트가 정기적으로 메모를 작성해 컨텍스트 창 밖의 외부 저장소에 남겨두고, 나중에 다시 불러오는 기법이다.
이 방식은 적은 오버헤드로도 지속적인 기억을 제공한다. Claude Code가 할 일 목록을 만들거나, 사용자 정의 에이전트가 NOTES.md 파일을 유지하는 것처럼, 단순한 패턴만으로도 복잡한 작업 속에서 진행 상황과 의존관계를 추적할 수 있다. 그렇지 않으면 수십 번의 도구 호출 사이에서 잃어버릴 맥락을 붙잡아 둘 수 있다.
Anthropic은 “Claude playing Pokémon” 사례를 통해, 메모리가 비개발 영역에서도 에이전트 능력을 어떻게 바꾸는지 보여준다. 이 에이전트는 수천 단계에 걸친 게임 진행 동안, 예를 들어 “지난 1,234스텝 동안 Route 1에서 포켓몬 훈련을 했고, Pikachu가 목표 10레벨 중 8레벨을 올렸다” 같은 정밀한 누적 정보를 유지했다. 별도의 메모 구조 지시 없이도, 탐험한 지역의 지도, 해금한 주요 업적, 전투 전략 같은 것들을 기록하며, 어떤 공격이 어떤 상대에게 잘 통하는지도 학습한다.
컨텍스트가 초기화된 뒤에도 에이전트는 자기 메모를 읽고 다시 이어서 장시간의 훈련이나 던전 탐험을 계속할 수 있다. 이런 요약 이후에도 이어지는 일관성 덕분에, LLM 컨텍스트 창만으로는 불가능한 장기 전략이 가능해진다.
Anthropic은 Sonnet 4.5 출시와 함께 Claude Developer Platform에 메모리 도구 베타도 공개했다. 이를 통해 에이전트는 파일 기반 시스템으로 컨텍스트 밖의 정보를 저장하고 참조할 수 있다. 장기적으로 지식 베이스를 쌓고, 프로젝트 상태를 세션 간에 유지하며, 모든 것을 컨텍스트 안에 넣지 않고도 이전 작업을 참조할 수 있게 된다.
서브에이전트 구조
서브에이전트 구조는 컨텍스트 한계를 우회하는 또 다른 방법이다. 하나의 에이전트가 프로젝트 전체 상태를 계속 유지하려 하기보다, 전문화된 서브에이전트들이 각자 깨끗한 컨텍스트 창 안에서 특정 작업을 담당 하게 한다. 메인 에이전트는 상위 계획을 관리하고, 서브에이전트는 깊은 기술 작업이나 정보 탐색을 수행한다. 각 서브에이전트는 수만 토큰 이상을 탐색에 써도 되지만, 최종적으로는 보통 1,000~2,000토큰 정도의 압축된 요약만 메인 에이전트에게 돌려준다.
이 방식의 장점은 관심사의 분리 다. 세부 탐색에 필요한 방대한 맥락은 서브에이전트 안에 격리되고, 메인 에이전트는 결과를 종합하고 해석하는 데 집중할 수 있다. Anthropic이 How we built our multi-agent research system 에서 다룬 것처럼, 이 패턴은 복잡한 리서치 작업에서 단일 에이전트보다 상당한 성능 향상을 보였다.
어떤 접근이 더 적합한지는 작업 특성에 따라 다르다. 예를 들면 다음과 같다.
- 컴팩션: 잦은 왕복 대화가 필요한 작업에서 흐름을 유지하기 좋다.
- 구조화된 메모: 분명한 마일스톤이 있는 반복적 개발 작업에 잘 맞는다.
- 멀티 에이전트 구조: 병렬 탐색이 이득이 큰 복잡한 연구·분석 작업에 적합하다.
모델이 더 좋아지더라도, 장시간 상호작용 속에서 일관성을 유지하는 문제는 앞으로도 효과적인 에이전트 설계의 핵심 과제로 남을 것이다.
결론
컨텍스트 엔지니어링은 LLM을 활용한 개발 방식의 근본적인 전환을 보여준다. 모델이 더 강력해질수록 과제는 단순히 “완벽한 프롬프트를 쓰는 것”이 아니라, 매 순간 모델의 제한된 주의 예산 안으로 어떤 정보를 들여보낼지 신중하게 큐레이션하는 것 으로 옮겨간다.
장기 과제를 위해 컴팩션을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 환경을 적시에 탐색하도록 만들든, 핵심 원칙은 같다. 원하는 결과를 최대한 잘 이끌어내는 최소한의 고신호 토큰 집합을 찾아라.
Anthropic이 소개한 기법들은 앞으로도 모델의 발전과 함께 계속 진화할 것이다. 이미 더 똑똑한 모델일수록 덜 과도한 엔지니어링만으로도 더 자율적으로 작동할 수 있음을 확인하고 있다. 하지만 성능이 아무리 높아져도, 컨텍스트를 귀하고 유한한 자원으로 다루는 태도 는 신뢰할 수 있고 효과적인 에이전트를 만드는 데 계속 핵심으로 남을 것이다.
오늘 바로 Claude Developer Platform에서 컨텍스트 엔지니어링을 시작해 보고, 메모리 및 컨텍스트 관리 관련 cookbook에서 유용한 팁과 모범 사례도 확인해보길 바란다.
감사의 말
이 글은 Anthropic Applied AI 팀의 Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, Jeremy Hadfield가 작성했으며, Rafi Ayub, Hannah Moran, Cal Rueb, Connor Jennings의 기여가 있었다. 또한 Molly Vorwerck, Stuart Ritchie, Maggie Vo의 지원에도 특별한 감사를 전한다.