시스템 프롬프트를 넘어: Strands Skills를 활용한 모듈형 AI 에이전트 구축

다양한 능력을 갖춘 에이전트를 출시해 본 사람이라면 누구나 그 패턴을 알고 있습니다. 처음에는 깔끔하게 시작합니다. 그러다 제품에 더 많은 기능이 필요해집니다. 지침(instructions)을 추가합니다. 그다음에는 예외 케이스(edge cases)를 추가합니다. 그다음에는 각 기능에 대한 도메인 특화 규칙(domain-specific rules)을 추가합니다. 6개월 후, 당신의 시스템 프롬프트(system prompt)는 모델이 매 호출마다—그 컨텍스트가 필요하든 아니든—조정해야 하는 3,000 토큰 분량의 상충하는 지침들로 가득 차게 됩니다.

문제는 프롬프트 엔지니어링(prompt engineering) 기술이 아닙니다. 아키텍처(architecture)의 문제입니다. 당신은 지침 전달을 동적(dynamic)이어야 할 정적 설정 파일(static config file)처럼 취급하고 있습니다.

이는 소프트웨어 엔지니어링(software engineering)이 수십 년 전에 모듈형 설계(modular design)를 통해 해결했던 것과 동일한 문제입니다. 시작할 때 모든 라이브러리를 메모리에 로드하지 않습니다. 필요한 것을, 필요한 시점에 가져옵니다(import).

Skills는 이러한 원칙을 에이전트 지침 설계에 도입합니다.

Skills란 무엇인가

Skills는 에이전트가 필요할 때 요청하여 로드하는 독립적인 지침 패키지(instruction packages)입니다. 에이전트의 컨텍스트(context)는 가볍게 유지됩니다. 시작 시에는 스킬의 이름과 설명만 존재합니다. 에이전트가 특정 기능이 필요하다고 판단하면, 그 순간 전체 지침을 가져와 그 안에서 실행합니다.

다음 세 가지 속성이 대규모 환경에서 이를 의미 있게 만듭니다:

격리 (Isolation) — 각 스킬의 지침은 범위(scoped)가 지정되어 있습니다. 명시적으로 필요하지 않는 한 동시에 컨텍스트에 존재하지 않으므로 서로 충돌할 수 없습니다.

토큰 효율성 (Token efficiency) — 활성화된 부분에 대해서만 비용을 지불합니다. 10개의 스킬을 가진 에이전트가 매 호출마다 10세트의 지침을 모두 들고 다니지 않습니다.

유지보수성 (Maintainability) — 스킬은 독립적으로 버전 관리되고 업데이트됩니다. 에이전트가 하나의 도메인을 처리하는 방식을 변경해도 다른 부분에는 영향을 주지 않습니다.

이는 LLM 컨텍스트 관리(context management)에 적용된 점진적 공개(progressive disclosure)입니다.

Strands와 AgentSkills 플러그인

Strands는 Python 및 TypeScript를 위한 AWS의 오픈 소스 에이전트 SDK (Software Development Kit)입니다. 이 SDK는 모델 주도 방식 (model-driven approach)을 채택합니다. 즉, 오케스트레이션 (orchestration) 로직을 하드코딩하는 대신, LLM (Large Language Model) 스스로가 언제 도구를 호출할지, 단계를 어떤 순서로 실행할지, 그리고 응답하기에 충분한 정보를 확보했는지를 결정합니다. 이를 통해 복잡한 오케스트레이션 코드 없이도 에이전트를 훨씬 더 유연하게 만들 수 있습니다.

Strands는 내장된 도구 지원, 멀티 에이전트 오케스트레이션 (multi-agent orchestration), 그리고 에이전트의 동작을 확장하기 위한 플러그인 시스템을 함께 제공합니다. 그 플러그인 중 하나가 바로 AgentSkills로, 이는 점진적 공개 (progressive disclosure) 패턴을 프로덕션 환경에 구현한 것입니다.

Strands로 에이전트를 설정하는 데는 10줄도 채 걸리지 않습니다:

from strands import Agent

agent = Agent(system_prompt="You are a helpful assistant.")
...

스킬 (skills)을 추가하는 것은 한 단계만 더 추가하면 됩니다:

from strands import Agent, AgentSkills

plugin = AgentSkills(skills="./skills/")
...

이 시점부터 에이전트는 스킬 발견 (skill discovery) 및 활성화를 자동으로 관리하며, 사용자가 별도의 라우팅 (routing) 로직을 연결할 필요가 없습니다.

AgentSkills의 상세 작동 원리

이 플러그인은 세 가지 단계로 작동합니다:

1. 발견 (Discovery)
초기화 시, AgentSkills는 스킬 디렉토리를 스캔하고 스킬의 이름과 설명만을 시스템 프롬프트 (system prompt)에 주입합니다:

<available_skills>
  <skill>
    <name>email-drafter</name>
...

에이전트가 사전에 보는 것은 이것뿐입니다 — 즉, 이름과 설명입니다. 지침(instructions), 도메인 로직(domain logic), 또는 메타데이터 이상의 토큰 비용 (token cost)은 발생하지 않습니다.

2. 활성화 (Activation)
에이전트가 특정 스킬이 필요하다고 판단되는 메시지를 받으면, 스킬 이름을 인자로 하여 내장된 스킬 도구를 호출합니다. 이는 표준적인 도구 호출 (tool call)이며, 에이전트가 다른 도구를 사용할 때와 동일한 메커니즘입니다. 사용자 측에서 별도의 라우팅이나 조건부 로직을 작성할 필요가 없습니다.

3. 실행 (Execution)
도구는 SKILL.md의 전체 내용—지침(instructions), 규칙(rules), 출력 형식(output format) 등 모든 것—을 반환합니다. 이제 에이전트는 해당 응답에 대해 그 지침 내에서 동작합니다. 활성화된 기술(skills)은 세션이 남은 동안 에이전트 상태(agent state)에 유지되므로, 동일한 도메인의 후속 메시지에서 이를 다시 가져올 필요가 없습니다.

기술 (Skill) 정의하기

기술(skill)은 단일 SKILL.md 파일을 포함하는 디렉토리입니다. 이 파일은 두 부분으로 구성됩니다. 플러그인이 읽는 YAML 프론트매터(frontmatter) 헤더와 에이전트의 지침이 되는 마크다운(markdown) 본문입니다.

skills/
└── bug-investigator/
└── SKILL.md

---
name: bug-investigator
description: "에러 메시지 또는 스택 트레이스(stack trace)를 분석하여 근본 원인과 해결책이 포함된 구조화된 진단을 반환합니다."
...

name 필드는 하이픈(-)을 포함한 소문자 영문 숫자 조합이어야 하며, 길이는 1~64자여야 합니다. description은 에이전트가 해당 기술을 활성화할지 결정하기 위해 읽는 내용이므로, 명확하고 구체적인 한 줄 문장으로 작성해야 합니다. 모호한 설명은 잘못된 활성화를 초래합니다.

선택 사항인 allowed-tools 필드는 해당 기술이 사용할 수 있는 도구를 제한합니다.

---
name: pdf-processor
description: 쉘 스크립트(shell scripts)를 사용하여 PDF 파일에서 텍스트와 표를 추출합니다.
...

기술을 정의하는 두 가지 방법

파일 시스템 기반 (Filesystem-based) 방식은 표준적인 접근법입니다. 각 기술이 자체 디렉토리에 존재하며, 코드와 함께 버전 관리(versioned)가 가능하고, 독립적으로 검토 및 업데이트하기 쉽습니다.

**프로그래밍 방식 (Programmatic)**은 지침을 런타임(runtime)에 생성해야 할 때 유용합니다. 예를 들어 데이터베이스에서 가져오거나, 환경 설정(environment config)으로부터 구축하거나, 테넌트(tenant)별로 동적으로 구성해야 하는 경우입니다.

from strands import Skill, AgentSkills, Agent

skill = Skill(
...

두 방식 모두 깔끔하게 조합할 수 있습니다.

plugin = AgentSkills(skills=["./skills/", dynamic_skill])

이것이 대부분의 프로덕션 에이전트를 위한 실질적인 설정입니다. 안정적인 기능에는 정적 기술(static skills)을, 환경이나 사용자 컨텍스트에 따라 변하는 기능에는 프로그래밍 방식의 기술(programmatic skills)을 사용합니다.

기술을 사용해야 하는 시점

모든 에이전트에게 기술(Skills)이 적합한 도구인 것은 아닙니다. 만약 에이전트의 작업이 단 하나라면, 잘 설계된 시스템 프롬프트(system prompt)가 더 간단하고 충분합니다.

기술(Skills)은 다음과 같은 경우에 효과적입니다:

지침 세트(instruction sets)가 서로 충돌할 수 있는 진정으로 다른 도메인(domains)을 에이전트가 처리해야 할 때
대량의 호출이 발생하는 상황에서 토큰 비용(token cost)을 대규모로 최적화해야 할 때
팀 전체에서 기능(capabilities)에 대한 독립적인 버전 관리(versioning)가 필요할 때
시간이 지남에 따라 확장될 다중 기술(multi-skill) 에이전트를 구축하고 있을 때

기술(Skills)은 완전한 다중 에이전트 오케스트레이션(multi-agent orchestration)의 바로 아래 단계입니다. 즉, 단일 구조의 프롬프트(monolithic prompt)보다는 더 구조적이며, 기능마다 별도의 에이전트를 생성하는 것보다는 오버헤드(overhead)가 적습니다.

직접 시도해 보세요
Streamlit UI가 포함된 전체 프로젝트 GitHub 링크:

👉 https://github.com/miladrezaei-ai/strands-agent-skills

git clone https://github.com/miladrezaei-ai/strands-agent-skills
cd strands-agent-skills
uv sync
...

현재 사용 중인 에이전트 프롬프트에서 이러한 종류의 분리가 필요한 부분은 어디인가요? 여러분이 무엇을 만들고 있는지 정말 듣고 싶습니다.