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

AI 에이전트의 기본 구조 한눈에 보기

2026-03-30Views 15약 10분

에이전트는 "똑똑한 모델 하나"가 아니라 "움직이는 시스템"이다

Agent Skills를 이해하려면 먼저 아주 중요한 사실 하나를 잡고 가야 합니다. 에이전트는 LLM 하나를 멋지게 부르는 이름이 아닙니다. 에이전트는 모델을 중심으로, 프롬프트와 도구와 메모리와 제어 로직이 함께 움직이는 시스템입니다.¹²

보통 초보자는 이렇게 생각합니다. "좋은 모델만 쓰면 에이전트도 자동으로 좋아지는 것 아닌가?" 물론 좋은 모델은 중요합니다. 하지만 모델만으로는 실제 일을 끝내기 어렵습니다. 일정 확인도 해야 하고, 파일도 읽어야 하고, 이전 대화도 기억해야 하고, 지금 무엇을 해야 할지 순서도 정해야 합니다. 그러니 에이전트를 이해하는 가장 쉬운 방법은, 하나의 똑똑한 입이 아니라 작업을 처리하는 작은 팀으로 보는 것입니다.³

이 장에서는 그 팀의 핵심 멤버를 차례대로 살펴보겠습니다. 오늘 볼 구성요소는 여섯 가지입니다.

모델
프롬프트
도구
메모리
라우팅
상태

이 여섯 가지를 이해하면, 뒤에서 배울 Agent Skills가 왜 필요한지도 훨씬 선명해집니다. Skill은 허공에 떠 있는 문서가 아니라, 이 여섯 요소 사이에서 에이전트가 더 안정적으로 일하도록 돕는 장치이기 때문입니다.

먼저 큰 그림부터: 에이전트는 어떻게 한 바퀴 도는가

에이전트의 동작은 생각보다 단순한 반복으로 볼 수 있습니다. 대체로 다음 흐름을 따릅니다.¹⁴

입력을 받는다.
현재 상황을 해석한다.
다음 행동을 정한다.
필요하면 도구를 쓴다.
결과를 보고 다시 판단한다.
목표를 달성할 때까지 이 과정을 반복한다.

이 흐름은 사람의 일 처리와 꽤 비슷합니다. 예를 들어 "내일 부산 출장 일정을 정리해줘"라는 요청을 받았다고 해봅시다. 에이전트는 그냥 문장만 길게 쓰는 것이 아니라, 먼저 요청을 이해합니다. 그다음 일정 정보가 있는지 확인하고, 없으면 캘린더나 메일 같은 도구를 조회할 수 있습니다. 필요한 정보가 모이면 정리된 답을 만들고, 부족한 점이 있으면 다시 찾아봅니다.

여기서 핵심은 에이전트가 한 번에 정답을 툭 내놓는 존재가 아니라는 점입니다. 보고, 판단하고, 행동하고, 다시 보는 반복 구조가 에이전트의 본체입니다.²

이제 그 반복 구조를 이루는 부품을 하나씩 들여다보겠습니다.

모델: 에이전트의 두뇌

모델은 에이전트의 중심입니다. 사용자의 말을 이해하고, 현재 문맥을 읽고, 다음에 무엇을 해야 할지 추론하는 역할을 맡습니다. 흔히 "에이전트의 브레인"이라고 부르는 이유가 여기에 있습니다.²⁵

하지만 여기서 오해하면 안 됩니다. 모델은 만능 해결사가 아닙니다. 기본 LLM은 본질적으로 다음 토큰, 즉 다음 단어를 예측하는 기계입니다. 우리가 보기에는 꽤 자연스럽게 사고하는 것처럼 보이지만, 실제로는 문맥 속에서 가장 그럴듯한 다음 출력을 만들어내는 방식으로 작동합니다.¹

이 특성 때문에 모델은 아주 강력하면서도 동시에 한계가 있습니다. 언어 이해, 요약, 설명, 분류 같은 일은 훌륭하게 하지만, 최신 정보 확인이나 정확한 계산, 외부 시스템 조작은 혼자서 못 하거나 불안정할 수 있습니다. 그래서 에이전트는 모델 하나만 두지 않고, 다른 구성요소를 붙여서 모델의 약점을 메웁니다.¹³

쉽게 말하면 모델은 팀장입니다. 똑똑하고 판단력도 좋지만, 직접 회계 시스템에 로그인하거나 비행기 표를 결제하지는 못합니다. 그런 일은 다른 구성요소의 도움이 필요합니다.

프롬프트: 두뇌에게 주는 운영 지침서

프롬프트는 모델에게 "지금 어떤 역할로, 어떤 기준으로, 어떤 형식으로 일해야 하는지" 알려주는 지시문입니다. 많은 초보자가 프롬프트를 단순히 질문 문장 정도로 생각하지만, 에이전트에서 프롬프트는 훨씬 더 큰 의미를 가집니다.⁶

에이전트의 프롬프트에는 보통 이런 정보가 담깁니다.

너는 어떤 역할의 에이전트인가
무엇을 우선해야 하는가
언제 도구를 써야 하는가
어떤 형식으로 답해야 하는가
실패했을 때 어떻게 다시 시도할 것인가

즉, 프롬프트는 에이전트의 성격과 행동 규칙을 정하는 운영 안내문에 가깝습니다. 같은 모델이라도 프롬프트가 달라지면 완전히 다른 에이전트처럼 행동할 수 있습니다. 한쪽은 친절한 여행 비서가 되고, 다른 한쪽은 꼼꼼한 코드 리뷰어가 됩니다.

여기서 중요한 점은 프롬프트가 에이전트의 전부는 아니라는 것입니다. 프롬프트는 방향을 잡아주지만, 실제 능력은 도구와 메모리와 상태 관리까지 함께 맞물릴 때 비로소 살아납니다. 나침반만 있다고 등산이 끝나지 않는 것과 비슷합니다.

도구: 에이전트가 바깥세상과 손을 맞잡는 방법

도구는 에이전트가 텍스트 바깥의 세계와 연결되는 통로입니다. 웹 검색, 계산기, 데이터베이스 조회, 코드 실행, 메일 발송, 캘린더 수정 같은 것이 모두 도구입니다.¹⁵

도구가 중요한 이유는 아주 간단합니다. 모델은 말은 잘하지만, 세상을 직접 만지지는 못하기 때문입니다. 오늘 날씨를 정확히 알려면 날씨 API가 필요하고, 재고를 확인하려면 데이터베이스가 필요하며, 회의 일정을 잡으려면 캘린더 시스템에 접속해야 합니다.

도구는 크게 두 부류로 나눠 생각하면 이해가 쉽습니다.¹

정보를 가져오는 도구
실제 행동을 수행하는 도구

첫 번째는 검색, 조회, 읽기입니다. 두 번째는 저장, 전송, 예약, 수정입니다. 예를 들어 "이번 주 매출 추이를 알려줘"는 정보를 가져오는 쪽이고, "금요일 오후 3시에 회의 잡아줘"는 행동을 수행하는 쪽입니다.

현대 에이전트는 이런 도구를 보통 함수 호출, 즉 function calling 형태로 사용합니다. 모델이 "어떤 도구를 어떤 인자로 부를지" 구조화된 형태로 출력하면, 바깥 시스템이 그 요청을 실제로 실행하고 결과를 다시 모델에게 돌려줍니다.¹

이 장면을 사람으로 바꾸면 이렇습니다. 팀장이 "재무팀, 지난달 숫자 좀 가져와 주세요"라고 요청합니다. 재무팀이 자료를 건네주면, 그다음 판단은 다시 팀장이 합니다. 에이전트의 도구 호출도 거의 같은 흐름입니다.

메모리: 에이전트가 방금 본 것과 오래전에 배운 것을 붙잡는 법

LLM은 기본적으로 상태가 없습니다. 다시 말해, 사람이 아무 장치 없이 매번 처음 보는 것처럼 반응하는 것과 비슷합니다. 우리가 대화의 앞부분을 기억한다고 느끼는 이유는, 실제로는 이전 내용이 다시 문맥에 포함되어 모델에게 전달되기 때문입니다.¹²

그래서 에이전트에는 메모리가 필요합니다. 메모리는 보통 두 층으로 나눠 설명합니다.¹⁵

단기 메모리: 지금 대화와 현재 작업의 흐름을 붙잡는 기억
장기 메모리: 세션이 끝난 뒤에도 남겨두고 나중에 다시 꺼내 쓰는 기억

단기 메모리는 현재 대화 기록, 최근 도구 사용 결과, 방금 세운 계획 같은 것을 담습니다. 쉽게 말해 책상 위 메모지입니다. 지금 당장 일하는 데 필요합니다.

장기 메모리는 조금 다릅니다. 사용자의 선호, 예전에 처리했던 비슷한 문제, 자주 쓰는 문서, 회사 규칙 같은 것을 외부 저장소에 보관했다가 필요할 때 다시 가져옵니다. 흔히 벡터 데이터베이스와 검색 기반 접근을 써서 관련 기억을 꺼내옵니다. 이것이 자주 말하는 RAG, 즉 검색 증강 생성과도 연결됩니다.¹⁵

예를 들어 사용자가 "지난번처럼 짧고 딱딱하지 않은 톤으로 써줘"라고 말했을 때, 에이전트가 그 선호를 기억하고 있다면 훨씬 자연스럽게 일할 수 있습니다. 반대로 메모리가 없으면 매번 처음 만난 사람처럼 굴게 됩니다.

하지만 메모리도 마법은 아닙니다. 너무 많이 넣으면 문맥이 무거워지고, 불필요한 기억이 섞이면 오히려 판단이 흐려질 수 있습니다. 그래서 좋은 에이전트는 많이 기억하는 것보다 지금 필요한 기억을 잘 꺼내는 것이 중요합니다.

라우팅: 지금 누구를 부를지, 어디로 보낼지 정하는 교통정리

라우팅은 초보자가 가장 놓치기 쉬운 요소인데, 실제 시스템에서는 굉장히 중요합니다. 라우팅은 말 그대로 입력을 어디로 보낼지 결정하는 과정입니다.³⁷

예를 들어 사용자의 요청이 들어왔을 때 에이전트는 이런 판단을 할 수 있습니다.

이 질문은 그냥 모델이 바로 답해도 되는가
검색 도구를 먼저 써야 하는가
계산기로 보내야 하는가
특정 전문 에이전트나 특정 Skill을 불러야 하는가
안전 검토를 먼저 거쳐야 하는가

즉, 라우팅은 도로 위 신호등 같은 역할을 합니다. 모든 차를 한 차선으로 몰아넣으면 막히고 사고도 납니다. 적절한 차선으로 보내야 흐름이 살아납니다.

간단한 예를 들어보겠습니다. 사용자가 "2분기 매출이 1분기보다 몇 퍼센트 늘었어?"라고 물으면, 좋은 라우팅은 이 요청을 그냥 일반 대화로 처리하지 않습니다. 먼저 데이터 조회 도구로 숫자를 가져오고, 그다음 계산 도구로 증가율을 구한 뒤, 마지막에 모델이 읽기 쉬운 설명으로 바꾸게 할 수 있습니다.³⁸

반대로 "이 문장을 더 공손하게 바꿔줘" 같은 요청은 굳이 데이터베이스나 계산기를 거칠 필요가 없습니다. 그냥 모델에게 직접 보내는 것이 빠르고 효율적입니다.

앞으로 Agent Skills를 다룰 때도 이 라우팅 개념은 계속 중요합니다. Skill은 늘 무조건 다 읽는 것이 아니라, 현재 작업과 관련 있을 때 선택적으로 불러오는 경우가 많기 때문입니다. 다시 말해 Skill이 잘 작동하려면, 그 Skill을 언제 불러야 하는지 판단하는 라우팅도 좋아야 합니다.

상태: 에이전트가 "지금 어디까지 왔는지" 잊지 않게 하는 작업판

메모리와 상태는 비슷해 보여서 많이 헷갈립니다. 하지만 구분해두면 이해가 훨씬 쉬워집니다.

메모리가 "기억의 저장"에 가깝다면, 상태는 "지금 작업의 현재판"에 가깝습니다.⁷ 메모리가 도서관이라면, 상태는 지금 책상 위에 펼쳐둔 노트입니다.

상태에는 보통 이런 것들이 들어갑니다.⁷

현재 사용자 요청
지금까지의 대화 기록
중간 계산 결과
어떤 도구를 이미 호출했는지
현재 단계가 무엇인지
실패했는지, 재시도 중인지

예를 들어 여행 예약 에이전트를 생각해봅시다. 사용자가 출발 도시를 말했고, 날짜를 정했고, 항공권 검색까지 끝냈다고 합시다. 이때 상태가 없다면 에이전트는 다음 턴에서 다시 처음부터 물을 수 있습니다. "어디서 출발하시나요?" 같은 질문을 반복하면 금세 답답해집니다.

상태가 잘 관리되면 에이전트는 "지금 항공권 후보는 찾았고, 이제 호텔만 고르면 된다"는 것을 압니다. 즉, 상태는 작업의 진행 상황을 붙잡아 주는 고리입니다.

실무에서는 이 상태 관리가 에이전트 품질을 크게 좌우합니다. 겉으로는 말 잘하는데, 중간 결과를 잊어버리거나 도구 결과를 덮어쓰거나, 이미 끝난 단계를 반복하면 실제 업무에는 쓸 수 없기 때문입니다.

메모리와 상태는 뭐가 다를까

이 둘은 자주 함께 등장하므로 한 번 더 또렷하게 구분해봅시다.

메모리는 비교적 오래 남길 수 있는 정보입니다. 사용자의 취향, 과거 사례, 회사 정책, 이전 세션의 핵심 요약처럼 "나중에도 다시 꺼내볼 만한 것"이 여기에 가깝습니다.

상태는 현재 실행 중인 작업의 임시 진행판입니다. 이번 요청에서 몇 번째 단계인지, 어떤 도구 결과를 받았는지, 다음에 무엇을 해야 하는지 같은 것이 상태입니다.

아주 짧게 정리하면 이렇습니다.

메모리: 기억해 둘 것
상태: 지금 진행 중인 것

둘 다 없으면 에이전트는 금붕어처럼 굴고, 둘 다 과하면 어수선해집니다. 좋은 설계는 "오래 남길 것"과 "지금만 필요할 것"을 분리하는 데서 시작합니다.

이 모든 것이 합쳐질 때: 에이전트의 실제 동작 예시

이제 여섯 요소가 한 번에 어떻게 맞물리는지 예시로 보겠습니다.

사용자가 이렇게 말합니다.

"다음 주 화요일 오후에 팀 회의 잡고, 지난 회의에서 미뤄진 안건도 요약해줘."

먼저 모델은 요청의 뜻을 파악합니다. 회의 예약과 안건 요약이라는 두 작업이 섞여 있다는 것을 알아차립니다. 여기서 프롬프트는 모델에게 우선순위와 행동 규칙을 알려줍니다. 예를 들어 "일정 변경 같은 실제 행동은 확인 후 수행하라" 같은 규칙이 있을 수 있습니다.

그다음 라우팅이 작동합니다. 일정 관련 부분은 캘린더 도구로, 지난 회의 내용은 노트나 문서 검색 도구로 보내는 것이 적절하다고 판단합니다. 캘린더 조회 결과와 회의록 검색 결과가 돌아오면, 그것들이 상태에 기록됩니다. "회의 가능 시간 확인 완료", "지난 회의 안건 3개 검색 완료" 같은 식입니다.

메모리는 여기서 두 가지로 움직일 수 있습니다. 단기 메모리는 지금 검색한 회의록과 도구 결과를 붙잡고, 장기 메모리는 사용자가 늘 45분 회의를 선호한다는 과거 선호를 꺼내올 수도 있습니다.

마지막으로 모델은 이 모든 정보를 묶어서 답합니다. "화요일 오후 3시가 비어 있어 회의를 제안할게요. 지난 회의에서 미뤄진 안건은 A, B, C입니다." 만약 캘린더에 이미 일정이 있다면, 다시 다른 시간을 찾는 루프가 돌아갑니다.

이 예시를 보면 에이전트는 한 줄 생성기가 아니라는 사실이 훨씬 분명해집니다. 모델은 중심이지만, 혼자 일하지 않습니다.

에이전트를 이해할 때 흔한 오해 세 가지

모델이 곧 에이전트다

아닙니다. 모델은 핵심 부품이지만, 에이전트는 그 모델이 도구와 메모리와 제어 흐름 속에서 움직이는 시스템입니다.²³

도구만 붙이면 에이전트가 된다

반은 맞고 반은 틀립니다. 도구가 있어도 언제 무엇을 써야 하는지 모르면 엉뚱한 행동을 하거나 불필요하게 헤맬 수 있습니다. 그래서 프롬프트, 라우팅, 상태 관리가 함께 필요합니다.¹³

기억을 많이 넣을수록 더 똑똑해진다

그렇지 않습니다. 너무 많은 문맥은 오히려 집중을 흐릴 수 있습니다. 좋은 에이전트는 모든 것을 늘 들고 다니지 않고, 필요한 정보만 골라서 씁니다.¹⁷

왜 이 구조를 먼저 알아야 Agent Skills를 이해할 수 있을까

이제 핵심 질문으로 돌아와 봅시다. 왜 Skill을 배우기 전에 이런 구조를 먼저 알아야 할까요?

이유는 간단합니다. Skill은 이 구조 바깥에 따로 존재하는 장식품이 아니기 때문입니다. Skill은 프롬프트를 더 잘 조직하고, 도구 사용법을 더 정확히 알려주고, 라우팅 판단을 돕고, 상태를 덜 흔들리게 만드는 쪽으로 작동합니다. 즉, Skill은 에이전트의 기본 구조 위에 얹히는 실무용 능력 패키지입니다.

기본 구조를 모르면 Skill도 그저 긴 문서처럼 보입니다. 하지만 구조를 이해하고 나면 다르게 보입니다. "아, 이 Skill은 어떤 도구를 언제 쓰라고 알려주는구나." "이 Skill은 상태를 어떤 형식으로 유지하라고 정리해주는구나." "이 Skill은 특정 상황에서 어떤 라우팅을 해야 하는지 기준을 주는구나." 이런 식으로 읽히기 시작합니다.

다시 말해, 에이전트의 구조를 아는 것은 지도를 먼저 펼치는 일입니다. 지도가 있어야 길안내 앱도 이해할 수 있습니다.