인공지능 에이전트가 더욱 강력해지는 데에는 완전히 다른 두 가지 경로가 있습니다. 첫 번째는 기술인데, 이는 기술을 습득하고 새로운 능력을 직접적으로 머릿속에 집어넣는 것을 의미합니다. 다른 접근 방식은 서브에이전트(SubAgent)인데, 이는 마치 부하 직원을 보내 업무를 처리하게 하고 자신은 보고서만 보는 것과 같습니다. 이 두 가지 접근 방식 모두 에이전트를 더 강력하게 만드는 것처럼 보일 수 있지만, 적용 가능한 시나리오가 다릅니다. 잘못된 방식을 사용하면 에이전트가 사용할수록 속도가 느려지고 혼란스러워질 수 있습니다. 스킬은 메인 에이전트의 플러그인과 같습니다. 예를 들어, 상담원이 채팅만 할 수 있었는데 이제 파워포인트 프레젠테이션을 만들 수 있도록 하고 싶다면, 스킬 기능을 통해 파워포인트 제작 기능에 대한 설명, 도구 사용 방법, 중요 참고 사항 등을 상담원 컨텍스트에 삽입할 수 있습니다. 상담원은 이 컨텍스트를 통해 해당 스킬을 학습하고 스스로 파워포인트를 제작할 수 있게 됩니다. 두 번째 유형은 서브에이전트라고 하며, 아웃소싱과 유사합니다. 마찬가지로 PowerPoint 프레젠테이션을 제작할 때 서브에이전트 방식은 다음과 같이 작동합니다. 메인 에이전트가 프레젠테이션 제작 작업을 전담 서브에이전트에 할당하면, 서브에이전트는 독립적으로 작업을 완료하고 결과를 제출합니다. 메인 에이전트는 실제 실행에는 참여하지 않고, 작업 할당 및 승인 테스트만 담당합니다. 하나는 내재화된 역량이고, 다른 하나는 아웃소싱된 역량입니다. 둘 다 업무를 처리할 수 있는 것처럼 보이는데, 그렇다면 차이점은 무엇일까요? 차이점은 컨텍스트 관리 방식에 있는데, 여기서 컨텍스트는 AI의 메모리를 의미합니다. AI의 컨텍스트를 작업대라고 생각해 보세요. 작업대의 크기는 고정되어 있습니다. 그 위에 물건을 많이 올려놓을수록 필요한 문서를 찾기가 더 어려워집니다. 이것이 바로 컨텍스트 용량의 문제입니다. 스킬 모드에서는 모든 능력 설명이 하나의 표에 표시됩니다. 장점은 정보 공유가 용이하다는 점입니다. 메인 에이전트는 모든 중간 결과를 확인할 수 있어 추론 과정이 일관성 있게 진행됩니다. 단점은 표가 빠르게 복잡해지고, 안내 메시지가 길어지며, 능력 간 충돌이 발생하고, AI가 혼란스러워질 수 있다는 것입니다. 서브에이전트 모드에서 서브에이전트는 별도의 테이블에서 작업합니다. 작업이 완료되면 결과를 전달하고, 과정 중에 생성된 모든 초안 및 중간 파일은 남겨둡니다. 메인 에이전트의 데스크톱은 깨끗하게 유지됩니다. 하지만 이 모드의 단점은 정보 전달 방식을 신중하게 설계해야 한다는 것입니다. 그렇지 않으면 인수인계 과정에서 중요한 정보가 손실될 수 있습니다. 이것이 바로 맥락적 오염 문제입니다. 이 오염은 과장된 비유가 아니라 엔지니어링 분야에서 실제로 발생하는 병목 현상입니다. 어떤 상황에서 어떤 방법을 사용해야 할까요? 판단 기준은 사실 꽤 간단합니다. 하위 작업의 복잡성과 작업 완료 과정에서 생성되는 정보가 필요한지 여부입니다. 스킬은 작업 자체가 너무 복잡하지 않거나, 메인 에이전트가 완전한 제어 권한을 가져야 하는 시나리오에 적합합니다. 예를 들어, 에이전트는 진입점 경로 역할을 하여 사용자의 요청에 따라 YouTube 요약 모드나 보고서 작성 모드와 같은 다양한 "시나리오 모드"를 로드할 수 있습니다. 바로 이 부분에서 스킬의 지연 로딩 기능이 빛을 발합니다. 초기에는 능력 이름과 설명만 로드하고, 실제로 스킬이 필요할 때만 전체 설명을 로드하는 것입니다. 모든 도구에 대한 상세 문서를 컨텍스트에 모두 집어넣는 MCP와는 대조적입니다. SubAgent는 하위 작업이 많고 시간이 많이 소요되며 중간 프로세스가 장황한 시나리오에 적합합니다. 가장 대표적인 예는 브라우저 디버깅 도구입니다. Chrome DevTools의 MCP 기능은 강력하지만 문서가 너무 방대하고, 이를 메인 에이전트에 포함시키면 컨텍스트를 심각하게 소모하게 됩니다. 이를 서브에이전트로 캡슐화하면 "로그를 확인하고, 스크린샷을 찍고, 분석하세요"라고만 명령하면 서브에이전트가 프로세스를 실행하고 분석 결과를 반환합니다. 모든 스크린샷, DOM 트리 세부 정보, 네트워크 요청 세부 정보는 서브에이전트에 남아 메인 에이전트의 컨텍스트를 오염시키지 않습니다. 고급 게임플레이 흥미롭게도 스킬 모드와 서브에이전트 모드를 결합할 수 있습니다. 이 기술은 @yan5xu 님(https://t.co/uSkwSUvNiJ)에게서 배웠습니다. 첫 번째 접근 방식은 "먼저 확장한 다음 압축"이라고 합니다. 예를 들어, 두 시간 동안 브레인스토밍을 한다고 상상해 보세요. 화이트보드에는 초안, 주장, 그리고 거부된 해결책들이 가득합니다. 하지만 결국 회의록에는 단 세 가지 결론만 기록됩니다. 이러한 중간 과정은 결론에 도달하는 데 중요하지만, 나중에 그 결론을 실행하는 사람들에게는 그저 불필요한 잡음일 뿐입니다. 에이전트는 이런 방식으로도 작동할 수 있습니다. 메인 에이전트는 특정 기술의 필요성을 감지하고, 해당 기술을 로드한 후, 일련의 작업을 수행하고 결과를 얻습니다. 그런 다음 "기술 로드"부터 "결과 도출"까지의 전체 과정을 축소하고 최종 결론만 남깁니다. 후속 추론을 위해서는 마치 회의를 열되 회의록만 남겨두는 것과 같습니다. 두 번째 접근 방식은 파일 시스템을 "전송 스테이션"으로 사용하는 것입니다. 아웃소싱 팀을 관리한다고 상상해 보세요. 요구사항 세부 정보를 하나의 위챗 메시지에 모두 담지는 않겠죠. 대신 "요구사항 문서는 이 링크에 있으니 확인해 보세요."라고 말할 겁니다. 마찬가지로 아웃소싱 팀도 소스 코드를 단순히 복사해서 붙여넣기만 하지는 않을 겁니다. 대신 "코드는 이 저장소에 있고, 배포 문서는 여기 있습니다."라고 말하겠죠. 에이전트들은 이런 방식으로 협업할 수도 있습니다. 메인 에이전트가 작업을 위임할 때, 명령에 장황한 배경 정보를 포함하는 대신, 해당 정보를 문서로 저장하고 하나의 주소만 전송합니다. 서브 에이전트도 같은 방식으로 응답합니다. "완료됨/멈춤/결정 필요"와 같은 간략한 상태 요약과 함께 자세한 문서 주소를 전달합니다. 메인 에이전트는 상황에 따라 세부 정보를 확인하기 위해 링크를 클릭할지 여부를 결정합니다. 이렇게 하면 양측 모두에게 간결한 맥락을 유지할 수 있습니다. 세 번째 유형은 클로드 코드의 실용적인 기법입니다. 컨텍스트 작업이 거의 완료되면 클로드에게 현재 완료된 작업을 문서로 요약하도록 하세요. 그런 다음 되감기 기능을 사용하여 작업 시작 이전 상태로 되돌리고 "이 작업을 완료하고 이 파일에 기록했습니다."라고 알려주세요. 이게 대체 뭐에 비유할 수 있을까요? 마라톤을 뛰다가 결승선 근처에서 완전히 지쳐버린 걸 깨닫는 순간과 같아요. 그래서 이미 달려온 경로를 지도에 표시하고 저장한 다음, 마치 "순간이동"이라도 한 것처럼 에너지가 넘치는 상태로 출발점으로 돌아가서 "길을 알아, 지도 여기 있어."라고 말하는 거죠. 맥락은 사라지지만 결과는 보존되는 겁니다. 이 방법을 사용하면 맥락이 완전히 사라지기 전에 상황을 수습할 수 있어요. 마침내 에이전트 간의 경쟁은 "얼마나 많은 도구를 호출할 수 있는가"에서 "이러한 도구를 어떻게 효율적으로 관리할 수 있는가"로 바뀌고 있습니다. 많은 사람들이 최신 에이전트 프레임워크와 화려한 기능 확장에만 매달리지만, 가장 근본적인 문제를 간과합니다. 바로 AI의 작업 기억 용량이 제한적이며, 이를 어떻게 구성하느냐에 따라 AI가 수행할 수 있는 작업의 복잡성이 결정된다는 점입니다. 스킬과 서브에이전트는 서로 배타적인 선택지가 아니라, 적절한 맥락에서 사용될 때 비로소 진가를 발휘하는 두 가지 도구입니다. 결론적으로, 에이전트 아키텍처 설계와 소프트웨어 아키텍처 설계는 많은 유사점을 가지고 있습니다. 로직을 거대한 함수 안에 작성해야 할까요, 아니면 모듈화된 마이크로서비스로 분해해야 할까요? 전역 변수를 공유하는 것이 더 쉬울까요, 아니면 엄격한 격리를 통해 변수의 일관성을 유지하는 것이 더 쉬울까요? 이러한 오래된 문제들이 새로운 모습으로 다시 나타났습니다.
