책에 포함된 노트처음부터 이해하는 Agent Skills: AI 에이전트를 제대로 일하게 만드는 설계법

도구, 메모리, 서브에이전트와 함께 쓰기

2026-03-30Views 8약 11분

Skill을 처음 배울 때는 종종 이렇게 생각합니다. "좋아, 이제 에이전트가 똑똑해졌네." 그런데 실전에 들어가면 곧 다음 질문이 따라옵니다.

그래서 실제 일은 누가 하지?

Skill은 일을 '직접' 처리하는 손이라기보다, 일을 어떻게 처리할지 알려 주는 작업 매뉴얼에 가깝습니다. 매뉴얼만으로는 택배를 보내지 못하고, 엑셀 파일을 열지 못하고, 데이터베이스를 조회하지도 못합니다. 실제 행동은 도구가 하고, 과거를 기억하는 일은 메모리가 맡고, 더 큰 문제를 쪼개는 일은 서브에이전트가 돕습니다. 그리고 MCP는 이런 외부 능력들을 비교적 표준화된 방식으로 연결해 주는 배선 역할을 합니다.¹²

이 장의 핵심은 단순합니다.

현실의 강한 에이전트는 Skill 하나로 완성되지 않는다. Skill, 도구, 메모리, MCP, 서브에이전트가 서로 역할을 나눌 때 비로소 강해진다.

Skill은 감독, 도구는 손이다

가장 먼저 머릿속에 넣어야 할 구분이 있습니다.

도구는 무언가를 실행합니다. API를 호출하고, 파일을 읽고, 브라우저를 조작하고, 코드를 실행합니다. 반면 Skill은 "이 상황에서 어떤 순서로 생각하고 어떤 기준으로 판단하며 어떤 형식으로 결과를 내야 하는가"를 알려 줍니다.²³

쉽게 비유해 봅시다.

요리를 하는 상황에서 칼, 냄비, 오븐은 도구입니다. 레시피는 Skill입니다. 냄비가 레시피를 이해하지는 못하고, 레시피가 수프를 직접 끓이지도 못합니다. 하지만 둘이 함께 있어야 저녁이 나옵니다.

에이전트도 똑같습니다. 예를 들어 "고객 문의를 분석하고 환불 가능 여부를 판단한 뒤 답변 초안을 작성하라"는 요청이 들어오면, Skill은 이런 식의 흐름을 정해 줄 수 있습니다.

먼저 고객 의도를 분류한다
정책 문서를 확인한다
주문 정보를 조회한다
예외 조건을 점검한다
근거를 포함해 답변을 작성한다

그런데 주문 조회는 도구가 해야 하고, 정책 문서 접근도 도구가 해야 하며, 실제 환불 처리 버튼을 누르는 것도 도구가 해야 합니다. Skill이 해 주는 일은 어떤 도구를 왜, 언제 써야 하는지 질서를 부여하는 것입니다.²⁴

Skill과 도구를 함께 쓸 때 생기는 변화

Skill 없이 도구만 많은 에이전트는 종종 "공구함은 큰데 일머리는 없는" 상태가 됩니다. 망치는 있는데 못을 언제 박아야 하는지 모르는 셈입니다.

예를 들어 웹 검색 도구, 데이터베이스 조회 도구, 파일 읽기 도구, 코드 실행 도구가 모두 연결된 에이전트를 떠올려 봅시다. 이런 에이전트는 겉보기에는 만능처럼 보이지만, 실제로는 다음과 같은 문제를 자주 겪습니다.

같은 질문에도 매번 다른 절차로 접근한다
불필요한 도구를 남발해 비용과 시간이 늘어난다
중요한 검증 단계를 건너뛴다
결과 형식이 들쭉날쭉하다

여기에 Skill을 얹으면 상황이 달라집니다. Skill은 도구 사용에 절차와 기준을 추가합니다. 예를 들어 "재무 리서치 Skill"이 있다면, 먼저 최신 데이터 출처를 확인하고, 그다음 과거 기록과 비교하고, 수치가 충돌하면 사용자에게 불확실성을 명시하라고 지시할 수 있습니다. 그러면 같은 도구 세트라도 더 일관된 결과를 냅니다.⁴

즉, 도구가 능력의 폭을 넓힌다면 Skill은 그 능력의 품질과 반복 가능성을 높입니다.

메모리가 없으면 Skill은 매번 새로 입사한 인턴이 된다

Skill이 아무리 좋아도, 에이전트가 이전 대화와 사용자 선호를 전혀 기억하지 못한다면 매번 처음부터 다시 설명해야 합니다. 오늘은 존댓말로 답했다가 내일은 너무 가볍게 말하고, 지난주에 정한 프로젝트 규칙을 이번 주에는 잊어버리는 식입니다.

이때 필요한 것이 메모리입니다. 여러 자료에서 공통적으로 강조하는 점은, 메모리는 단순히 긴 대화 기록을 더 많이 집어넣는 문제가 아니라 세션을 넘어 유지되는 상태를 설계하는 문제라는 것입니다.⁵⁶

이 차이는 초보자에게 아주 중요합니다. 많은 사람이 "컨텍스트 창이 커지면 기억도 해결되는 것 아닌가?"라고 생각하지만, 큰 컨텍스트는 큰 메모장일 뿐입니다. 대화가 끝나면 사라집니다. 메모리는 바깥 저장소에 남아 있다가 다음 작업 때 다시 불려오는 정보입니다.⁵

Skill과 메모리가 결합되면 에이전트는 훨씬 인간적으로 보입니다. 예를 들어 글쓰기 Skill이 있고, 메모리에 "사용자는 짧은 문단을 선호한다", "영문 약어는 처음에 풀어서 설명해 달라고 요청했다", "이 팀은 보고서 끝에 다음 액션을 반드시 넣는다" 같은 정보가 저장되어 있다고 해 봅시다. 그러면 같은 Skill이라도 사용자마다 다른 결과를 자연스럽게 낼 수 있습니다.⁶⁷

Skill이 업무 매뉴얼이라면, 메모리는 "이 팀은 원래 이렇게 일해요"라고 적힌 사내 수첩입니다.

메모리도 한 종류가 아니다

메모리를 하나로 뭉뚱그리면 설계가 금방 꼬입니다. 실전에서는 최소한 몇 가지 층으로 나눠 생각하는 편이 좋습니다.

가장 이해하기 쉬운 분류는 다음과 같습니다. 현재 작업 중에만 필요한 작업 메모리, 한 대화 동안 유지되는 세션 메모리, 여러 대화에 걸쳐 남는 장기 메모리입니다. 여기에 더 세분하면 절차를 기억하는 절차적 메모리, 사실과 선호를 담는 의미적 메모리, 과거 사건과 실패 경험을 남기는 에피소드 메모리로 나눌 수 있습니다.⁵⁷⁸

이 분류가 왜 중요할까요? Skill마다 의존하는 메모리 종류가 다르기 때문입니다.

예를 들어 "코드 리뷰 Skill"은 다음 정보를 필요로 할 수 있습니다.

작업 메모리: 지금 보고 있는 PR의 변경 파일, 현재 검토 중인 이슈
장기 메모리: 이 저장소의 코딩 규칙, 팀의 커밋 관례, 자주 발생하는 실수
에피소드 메모리: 지난번 비슷한 수정에서 테스트가 깨졌던 사례

VS Code의 에이전트 메모리 문서도 비슷한 감각을 보여 줍니다. 사용자 전역에 걸친 기억, 저장소 단위 기억, 현재 세션에서만 쓰는 기억을 서로 다른 범위로 나눕니다. 이 구분 덕분에 "어떤 정보는 오래 남겨야 하고, 어떤 정보는 대화가 끝나면 버려야 한다"는 설계가 가능해집니다.⁶

좋은 Skill은 종종 메모리를 이렇게 다룹니다. "이 정보는 이번 세션 계획에만 남겨라", "이 선호는 사용자 장기 메모리에 기록해도 된다", "저장소 규칙으로 승격할 만한 사실인지 먼저 검증하라."

여기서 보이듯 Skill은 메모리를 대체하지 않습니다. 오히려 메모리를 어떻게 읽고 쓸지 안내하는 안내자가 됩니다.

RAG와 메모리는 비슷해 보여도 다르다

초보자가 자주 헷갈리는 지점이 하나 더 있습니다. 문서를 검색해서 답변에 넣는 RAG와 메모리가 비슷해 보인다는 점입니다.

둘 다 "필요한 정보를 다시 꺼내온다"는 점에서는 닮았습니다. 하지만 RAG는 보통 외부 지식, 즉 누구에게나 공통인 정보를 가져오는 데 강합니다. 반면 메모리는 사용자별 선호, 이전 대화에서 정한 결정, 과거 실패 사례처럼 이 사용자 또는 이 작업 맥락에 특화된 상태를 다룹니다.⁵⁹

예를 들어 "우리 회사 환불 정책이 뭐지?"는 RAG가 잘하는 일입니다. "이 고객은 지난번에 부분 환불 대신 포인트 적립을 선호한다고 말했지?"는 메모리가 더 적합합니다.

Skill 설계에서 이 구분은 중요합니다. Skill 안에 모든 배경지식을 다 박아 넣으려 하면 금방 무거워집니다. 보편적 문서는 RAG나 문서 리소스에서 가져오고, 사용자 특화 정보는 메모리에서 가져오게 분리해야 합니다. 그래야 Skill이 매뉴얼로서 깔끔하게 남습니다.⁴⁹

MCP는 Skill의 경쟁자가 아니라 협력자다

최근 에이전트 생태계에서 자주 나오는 말이 MCP입니다. 어렵게 들리지만, 초보자에게는 이렇게 이해하면 충분합니다.

MCP는 에이전트가 외부 시스템과 연결되는 표준화된 통로입니다. 데이터베이스, 파일 시스템, 브라우저, SaaS 도구, 사내 시스템 같은 것들이 MCP 서버를 통해 도구와 리소스로 노출될 수 있습니다.¹¹⁰

중요한 점은 Skill과 MCP가 같은 층의 개념이 아니라는 것입니다. MCP는 "연결"에 관한 것이고, Skill은 "사용 방법"에 관한 것입니다.²¹⁰

예를 들어 사내 PostgreSQL 데이터베이스에 접속하는 MCP 서버가 있다고 해 봅시다. 이 MCP 서버는 query_orders, get_customer, list_refund_requests 같은 도구를 제공할 수 있습니다. 그런데 이것만으로는 아직 충분하지 않습니다. 에이전트는 다음 같은 운영 지식이 필요합니다.

먼저 읽기 전용 조회로 사실을 확인할 것
기간 필터를 걸지 않은 전체 조회는 피할 것
고객 식별 정보는 응답에 그대로 노출하지 말 것
데이터가 비어 있으면 추측하지 말고 부족하다고 말할 것

이런 지침은 MCP가 아니라 Skill이 잘 맡는 영역입니다.²¹⁰

한마디로 요약하면 이렇습니다.

MCP가 능력을 열어 주고, Skill이 그 능력을 안전하고 일관되게 쓰는 법을 가르친다.

Skill과 MCP를 함께 설계하는 실전 감각

실무에서는 "MCP만 연결하면 되겠지"라고 생각하기 쉽습니다. 하지만 MCP로 노출된 도구가 많아질수록 오히려 에이전트는 선택 장애에 빠질 수 있습니다. 도구 이름과 설명을 보고 적절한 것을 골라야 하기 때문입니다.¹¹

그래서 Skill이 필요합니다. 특히 도구가 많은 환경에서는 Skill이 일종의 현장 사용 설명서 역할을 합니다.

예를 들어 "재고 관리 Skill"은 다음처럼 MCP 도구 사용 순서를 정할 수 있습니다.

search_product로 상품 ID를 먼저 확인한다
get_inventory로 현재 수량과 창고 위치를 조회한다
부족하면 list_open_purchase_orders로 입고 예정 여부를 본다
수치가 충돌하면 즉시 inventory_reconciliation_note 리소스를 참고한다
실제 수정은 승인 전에는 절대 하지 않는다

이렇게 되면 MCP 도구는 그대로인데, 에이전트의 행동은 훨씬 예측 가능해집니다. 마치 잘 정리된 주방에서 "이 칼은 채소용, 이 팬은 약불 전용"이라고 라벨을 붙인 것과 비슷합니다.

서브에이전트가 필요한 순간은 언제일까

지금까지의 이야기를 들으면 "그럼 Skill만 잘 만들면 다 되는 것 아닌가?"라는 생각이 들 수 있습니다. 많은 경우 실제로 단일 에이전트 + Skill + 도구 + 메모리 조합만으로 충분합니다. 여러 아키텍처 가이드도 처음부터 멀티에이전트로 가지 말고, 가장 낮은 복잡도에서 시작하라고 권합니다.¹²

그럼에도 서브에이전트가 필요한 순간은 분명히 있습니다. 대표적으로 세 가지입니다.

한 작업 안에 서로 다른 전문성이 강하게 섞여 있을 때
메인 대화의 컨텍스트가 너무 쉽게 오염될 때
서로 다른 도구 권한이나 보안 경계가 필요할 때

서브에이전트는 하나의 작은 전문가 팀원처럼 생각하면 쉽습니다. 메인 에이전트가 전체 목표를 이해하고, 특정 부분을 별도 컨텍스트 창을 가진 서브에이전트에게 맡기는 구조입니다. 이렇게 하면 메인 대화가 잡다한 세부 분석으로 부풀어 오르는 것을 줄일 수 있고, 각 서브에이전트마다 허용 도구를 다르게 줄 수도 있습니다.¹⁰¹³

예를 들어 코드 작업에서는 다음처럼 나눌 수 있습니다.

security-auditor: 읽기 전용 도구만 사용, 보안 위험 분석 전담
test-writer: 테스트 생성과 실행 전담
refactor-reviewer: 구조 개선 제안 전담

여기서 Skill은 각 서브에이전트의 전문성을 더 날카롭게 만드는 역할을 합니다. 즉, 서브에이전트는 역할 분리, Skill은 행동 규칙과 전문 지식 주입입니다.¹⁰¹³

Skill과 서브에이전트의 차이를 감각적으로 이해하기

둘 다 전문화를 돕기 때문에 헷갈리기 쉽습니다. 하지만 역할은 꽤 다릅니다.

Skill은 대개 하나의 에이전트 안에 로딩되는 전문 지식 묶음입니다. 반면 서브에이전트는 독립적인 실행 단위입니다. 각자 자신만의 컨텍스트 창, 시스템 지시, 도구 권한을 가질 수 있습니다.¹⁰¹³

비유하자면 Skill은 같은 사람의 머릿속에 들어 있는 체크리스트이고, 서브에이전트는 아예 다른 동료에게 일을 맡기는 것입니다.

예를 들어 "보안 리뷰 Skill"은 메인 에이전트가 스스로 보안 관점으로 생각하도록 돕습니다. 반면 "보안 감사 서브에이전트"는 메인 에이전트가 실제로 보안 전문가에게 검토를 의뢰하는 것에 가깝습니다.

언제 무엇을 쓸까요?

반복되는 절차와 지식이 필요하지만 메인 흐름 안에서 처리해도 된다면 Skill이 좋습니다. 별도 권한, 별도 컨텍스트, 별도 관점이 필요하다면 서브에이전트가 더 낫습니다.¹⁰

멀티에이전트는 '더 멋진 구조'가 아니라 '더 비싼 구조'이기도 하다

여기서 한 번 브레이크를 밟아야 합니다. 멀티에이전트는 강력하지만, 공짜가 아닙니다. 조율 비용, 지연 시간, 디버깅 난이도, 실패 지점이 모두 늘어납니다. Azure 아키텍처 가이드가 강조하듯, 단일 모델 호출로 충분한 문제에는 에이전트도 필요 없고, 단일 에이전트로 충분한 문제에는 멀티에이전트가 과합니다.¹²

이 원칙은 정말 중요합니다. 에이전트를 처음 만드는 사람일수록 "여러 명이 협업하면 더 똑똑하겠지"라고 상상하기 쉽지만, 현실에서는 회의가 늘어나면 일이 느려지는 경우도 많습니다. 사람 팀과 비슷합니다.

그래서 좋은 기본 전략은 이렇습니다.

먼저 단일 에이전트에 Skill과 필요한 도구를 붙입니다. 그다음 메모리를 넣어 반복 작업 품질을 높입니다. 그래도 컨텍스트 오염, 보안 경계, 병렬 처리, 전문성 분리가 문제라면 그때 서브에이전트를 도입합니다.¹²

즉, 멀티에이전트는 "기본값"이 아니라 "복잡도를 정당화할 이유가 있을 때 쓰는 확장 카드"입니다.

자주 쓰이는 조합 패턴 1: 단일 에이전트 + Skill + 도구

가장 먼저 추천할 만한 패턴입니다. 구조가 단순하고, 초보자도 다루기 쉽습니다.

이 패턴에서는 하나의 메인 에이전트가 여러 Skill을 상황에 따라 불러오고, 도구를 사용해 실제 행동을 합니다. 예를 들어 마케팅 팀의 에이전트라면 "블로그 초안 작성 Skill", "경쟁사 분석 Skill", "SEO 체크 Skill"을 가지고 있을 수 있습니다. 웹 검색 도구와 문서 작성 도구가 함께 붙으면 꽤 많은 일을 처리할 수 있습니다.³¹⁴

이 패턴의 장점은 디버깅이 쉽고, 어디서 문제가 났는지 비교적 명확하다는 점입니다. 단점은 복잡한 문제를 오래 다루다 보면 메인 컨텍스트가 점점 부풀어 오른다는 것입니다.

그래도 대부분의 팀은 여기서 시작하는 편이 맞습니다. 처음부터 거대한 멀티에이전트 건물을 짓기보다, 튼튼한 원룸부터 짓는 셈입니다.

자주 쓰이는 조합 패턴 2: Skill + 메모리

이 조합은 반복 사용에서 빛납니다. 특히 사용자 선호, 프로젝트 규칙, 이전 결정이 중요한 업무에서 유용합니다.

예를 들어 "회의 요약 Skill"이 있다고 해 봅시다. 메모리가 없다면 매번 회의록을 요약하고 끝입니다. 하지만 메모리와 결합하면 다음 같은 행동이 가능합니다.

이전 회의에서 미해결로 남은 항목을 끌어온다
팀이 선호하는 요약 형식을 기억한다
자주 언급되는 용어를 조직 내부 표현으로 맞춘다
지난번 약속한 액션 아이템의 완료 여부를 확인한다

이 조합의 핵심은 Skill이 메모리의 쓰기 기준과 읽기 기준을 정한다는 점입니다. 무엇을 저장할지, 얼마나 오래 보관할지, 다시 불러올 때 어떤 우선순위를 둘지 Skill이 설명해 줄수록 메모리는 덜 지저분해집니다.⁶⁷

메모리는 서랍이고, Skill은 "무엇을 서랍에 넣고 어떤 라벨을 붙일지" 정하는 정리 습관이라고 생각하면 쉽습니다.

자주 쓰이는 조합 패턴 3: Skill + MCP + 안전 규칙

기업 환경에서는 이 조합이 특히 중요합니다. 외부 시스템 접근이 많고, 잘못된 호출의 비용이 크기 때문입니다.

예를 들어 "계약 검토 Skill"이 사내 문서 시스템 MCP, CRM MCP, 전자결재 MCP와 연결된다고 해 봅시다. 여기서 Skill은 단순히 문서 읽는 법만 알려 주는 것이 아니라, 다음과 같은 운영 규칙도 담을 수 있습니다.

초안 작성 전에는 원본 계약서와 최신 부속 문서를 모두 확인할 것
고객 등급 정보는 CRM에서 읽되, 계약서 본문에 그대로 복사하지 말 것
결재 요청은 사람이 승인한 뒤에만 생성할 것
데이터가 누락되면 추정하지 말고 확인 요청을 반환할 것

이처럼 Skill은 MCP 연결 위에 절차적 안전장치를 얹습니다.²¹⁰¹⁵

자주 쓰이는 조합 패턴 4: 메인 에이전트 + 서브에이전트 + Skill

문제가 복잡해질수록 자주 보게 되는 형태입니다. 메인 에이전트는 오케스트라 지휘자처럼 전체 흐름을 관리하고, 세부 작업은 서브에이전트에게 맡깁니다. 각 서브에이전트는 자신만의 Skill을 통해 전문성을 갖춥니다.¹²¹⁶

예를 들어 "분기 실적 분석 보고서 작성"이라는 큰 업무를 생각해 봅시다.

메인 에이전트는 전체 목표를 이해하고 작업을 나눕니다. 재무 데이터 검증 서브에이전트는 숫자를 확인하고, 뉴스 분석 서브에이전트는 외부 요인을 요약하고, 보고서 작성 서브에이전트는 초안을 만듭니다. 마지막으로 메인 에이전트가 결과를 합쳐 최종 문서를 만듭니다.

여기서 각 서브에이전트의 Skill은 아주 다를 수 있습니다. 숫자 검증 에이전트는 보수적으로, 근거 중심으로 행동해야 하고, 보고서 작성 에이전트는 독자 친화적인 구성과 문체를 중시해야 합니다. 이런 차이를 하나의 에이전트 안에 모두 밀어 넣는 것보다 역할을 나누는 편이 훨씬 깔끔할 때가 많습니다.¹²¹⁶

멀티에이전트 패턴을 너무 어렵게 볼 필요는 없다

멀티에이전트 이야기가 나오면 갑자기 시스템이 엄청 거대해 보입니다. 하지만 본질은 생각보다 단순합니다. 여러 자료가 공통적으로 소개하는 패턴도 결국 몇 가지 익숙한 협업 방식으로 요약됩니다.¹²¹⁶¹⁷

가장 많이 쓰이는 것은 순차형, 병렬형, 관리자-작업자형입니다.

순차형은 한 에이전트의 출력이 다음 에이전트의 입력이 되는 파이프라인입니다. 초안 작성 → 검토 → 수정 같은 흐름에 맞습니다.¹²

병렬형은 여러 에이전트가 동시에 같은 문제를 다른 관점에서 보고, 마지막에 결과를 합칩니다. 속도가 중요하거나 서로 다른 시각이 필요한 경우에 좋습니다.¹²

관리자-작업자형은 메인 에이전트가 일을 쪼개고 작업자 에이전트들에게 맡긴 뒤 결과를 모읍니다. 가장 직관적이고 실무 친화적인 형태입니다.¹⁶¹⁷

중요한 것은, 어떤 패턴이든 Skill이 각 에이전트의 행동 기준을 선명하게 만들어 준다는 점입니다. 패턴은 협업 구조이고, Skill은 각 참가자의 플레이북입니다.

예시로 보는 전체 설계: '고객 지원 에이전트'

이제 모든 요소를 한 장면에 모아 봅시다. 고객 지원 에이전트를 만든다고 가정하겠습니다.

사용자가 "지난주 주문이 아직 안 왔고, 지난번 상담원은 부분 환불 가능하다고 했어요"라고 말합니다.

메인 에이전트는 우선 고객 지원 Skill을 활성화합니다. 이 Skill은 문제 분류, 사실 확인, 정책 검토, 응답 작성 순서를 안내합니다. 주문 조회는 MCP를 통해 연결된 주문 시스템 도구를 사용합니다. 환불 정책은 문서 리소스나 RAG에서 확인합니다. 메모리에는 이 고객이 지난번 대화에서 빠른 해결보다 정확한 설명을 선호한다고 기록돼 있을 수 있습니다.⁶¹⁰

상황이 더 복잡하다면 메인 에이전트는 배송 추적 서브에이전트와 환불 정책 검토 서브에이전트로 일을 나눌 수 있습니다. 배송 쪽은 물류 시스템 도구에 집중하고, 정책 쪽은 환불 기준과 예외 조항을 본 뒤 결과를 반환합니다. 마지막으로 메인 에이전트가 둘의 결과를 합쳐 답변합니다.

이 장면에서 각 요소의 역할은 분명합니다.

Skill: 절차, 판단 기준, 답변 형식 제공
도구/MCP: 실제 주문 조회와 정책 문서 접근 수행
메모리: 고객 선호와 과거 맥락 유지
서브에이전트: 복잡한 문제를 역할별로 분해

바로 이런 조합이 "현실의 에이전트"입니다. 어느 하나가 단독 주인공이 아닙니다.

설계 원칙 1: Skill에 모든 것을 넣지 말기

초보자가 가장 자주 하는 실수는 Skill을 만능 창고처럼 만드는 것입니다. 모든 규칙, 모든 문서, 모든 예외, 모든 도구 사용법을 한 파일에 때려 넣으면 처음엔 든든해 보입니다. 하지만 곧 읽기도 어렵고, 유지보수도 어렵고, 에이전트도 헷갈립니다.

좋은 분리는 대체로 이렇습니다.

Skill에는 절차, 판단 기준, 사용 시점, 출력 형식을 넣는다
도구와 MCP에는 실제 실행 능력을 맡긴다
메모리에는 반복적으로 재사용될 상태를 남긴다
서브에이전트에는 독립적 전문성과 권한 경계를 맡긴다

이 선이 흐려질수록 구조는 복잡해지고 문제 원인을 찾기 어려워집니다.²¹⁰¹²

설계 원칙 2: 메모리는 많이 저장하는 것보다 잘 잊는 것이 중요하다

메모리를 넣기 시작하면 자꾸 모든 것을 저장하고 싶어집니다. 하지만 오래된 선호, 틀린 사실, 우연히 나온 임시 계획까지 다 남겨 두면 에이전트는 점점 더 이상한 확신을 갖게 됩니다.

여러 메모리 자료가 공통적으로 강조하는 것도 바로 이것입니다. 메모리는 저장만이 아니라 갱신과 삭제, 즉 forgetting이 중요합니다.⁶⁷⁹

그래서 Skill이 메모리를 쓸 때는 다음 같은 규칙이 유용합니다.

일시적 작업 상태는 세션이 끝나면 버린다
사용자 선호는 반복 확인된 것만 장기 메모리에 올린다
저장소 규칙은 코드베이스에서 검증 가능한 사실만 남긴다
오래된 사실은 재검증 후 계속 사용할지 결정한다

좋은 기억력은 많은 것을 외우는 능력이 아니라, 버릴 것을 버리는 능력이기도 합니다.

설계 원칙 3: 서브에이전트는 병렬성보다 책임 분리에 먼저 써라

서브에이전트를 이야기하면 많은 사람이 먼저 "병렬 실행하면 빨라지겠다"를 떠올립니다. 물론 맞는 말입니다. 하지만 더 중요한 이유는 속도보다 책임의 분리와 오염 방지입니다.¹³

보안 검토 에이전트가 코드 수정 권한까지 가질 필요는 없습니다. 테스트 생성 에이전트가 운영 데이터베이스를 만질 이유도 없습니다. 이런 경계가 명확할수록 실수가 줄고, 사고 범위도 작아집니다.

즉, 서브에이전트는 "더 빨리 일하기 위한 분신술"이라기보다 "한 명이 너무 많은 일을 하다 사고 내지 않게 하는 분업"에 가깝습니다.

설계 원칙 4: 언제나 가장 단순한 구조부터 시작하라

이 장 전체를 관통하는 가장 실용적인 원칙입니다. 화려한 아키텍처보다 중요한 것은 현재 문제에 맞는 최소 복잡도입니다.¹²

처음에는 이 정도 질문만 던져도 충분합니다.

정말 외부 실행이 필요한가, 아니면 답변만 하면 되는가?
반복 절차가 있는가, 그렇다면 Skill이 필요한가?
사용자나 프로젝트 맥락이 누적되는가, 그렇다면 메모리가 필요한가?
도구가 많아졌는가, 그렇다면 MCP와 Skill의 결합이 필요한가?
한 에이전트가 감당하기 벅찬가, 그렇다면 서브에이전트를 도입할 때인가?

이 순서대로 커지면 됩니다. 처음부터 우주선을 만들 필요는 없습니다. 먼저 잘 달리는 자전거를 만들고, 필요할 때 기어를 추가하면 됩니다.

결국 Skill은 조합의 중심축이다

이 장을 읽고 나면 Skill이 예전보다 조금 다르게 보일 것입니다. Skill은 혼자 빛나는 초능력이 아닙니다. 오히려 다른 요소들을 서로 잘 엮어 주는 중심축에 가깝습니다.

도구만 있으면 에이전트는 손발은 있지만 일관성이 부족합니다. 메모리만 있으면 과거는 기억하지만 어떻게 행동할지 기준이 부족합니다. MCP만 있으면 연결은 되지만 사용법이 제각각일 수 있습니다. 서브에이전트만 늘리면 사람은 많아지지만 팀플레이가 흐트러질 수 있습니다.

Skill은 그 사이에서 "누가 무엇을 언제 어떤 순서로 왜 하는가"를 정리합니다. 그래서 Skill은 단순한 문서가 아니라, 도구를 질서 있게 쓰게 하고, 메모리를 의미 있게 읽고 쓰게 하며, MCP를 안전하게 활용하게 하고, 서브에이전트의 역할을 선명하게 만드는 설계 장치입니다.¹²¹⁰

현실의 강한 에이전트는 하나의 큰 재능으로 일하지 않습니다. 잘 정리된 매뉴얼, 믿을 만한 도구, 필요한 기억, 올바른 연결, 적절한 분업이 함께 움직입니다.

그리고 그 조합을 자연스럽게 묶어 주는 가장 실용적인 고리가 바로 Skill입니다.