저는 지난 1년 동안 기업 고객을 위한 AI 에이전트 기술 (AI agent skills)을 구축하며 동일한 문제에 계속 직면했습니다. 모든 사람이 "기술 (skills)"을 그저 화려한 프롬프트 정도로 취급한다는 점입니다. 그들은 Markdown 파일을 작성하고 그것을 기술이라 부르며, 왜 자신들의 에이전트가 실제 비즈니스 워크플로우 (business workflows)를 처리하지 못하는지 의아해합니다. 그래서 저는 단일 프롬프트 파일부터 8개 이상의 기술을 엔드투엔드 (end-to-end)로 오케스트레이션하는 완전한 비즈니스 완결 시스템 (business closure system)에 이르기까지, 기술 구축의 10가지 뚜렷한 단계를 정리했습니다. 각 단계에서 제가 배운 내용은 다음과 같습니다.

레벨 1: 순수 프롬프트 기술 (Pure Prompt Skill) — 단일 SKILL.md

모두가 시작하는 지점입니다. Markdown 파일 하나를 작성하여 폴더에 넣으면, 에이전트가 이를 지침으로 읽습니다. 그게 전부입니다. 스크립트도, 참조도, 에셋 (assets)도 없습니다. 그저 AI에게 무엇을 할지 알려주는 텍스트뿐입니다.

# SKILL.md — 회의록 정리 도구

당신은 회의록 정리 도구입니다. 사용자가 회의 내용을 제공하면,
...

저는 이것이 범위가 명확하고 단순한 작업에는 놀라울 정도로 잘 작동한다는 것을 발견했습니다. 회의록 추출기? 완벽합니다. 단일 문서 세트를 가진 지식 베이스 (knowledge-base) Q&A 봇? 그것도 괜찮습니다. 하지만 기술이 예외 상황 (edge cases)을 처리해야 하거나, 외부 데이터를 참조하거나, 조건부 로직 (conditional logic)을 따라야 하는 순간, 벽에 부딪히게 됩니다.

사용 시기: 빠른 프로토타입 (prototypes), 데모, 그리고 단일 프롬프트 창에 들어가는 작업.

넘어서야 할 시기: 하나의 Markdown 파일 안에 "사용자가 X를 물으면 Y를 하고, Z를 물으면 W를 하라..."라고 쓰기 시작하는 바로 그 순간.

레벨 2: 컴포넌트 기술 (Component Skill) — 참조 및 스크립트 도입

컴포넌트 기술은 프롬프트 주변에 구조를 추가합니다. 여전히 SKILL.md가 존재하지만, 이제 지식 문서 (knowledge documents), Python 스크립트, YAML 설정 (configs), 또는 에이전트가 런타임 (runtime)에 로드할 수 있는 정적 에셋 (static assets) 등 다른 파일들을 참조합니다.

my-skill/
├── SKILL.md
├── knowledge/
...

핵심 통찰: 이제 SKILL.md는 모든 것을 하나의 파일에 밀어 넣는 대신, 에이전트가 올바른 리소스 (resources)를 가리키도록 하는 코디네이터 (coordinator) 역할을 합니다.

# SKILL.md — 지식 RAG 어시스턴트

## 지식 베이스 (Knowledge Base)
...

저는 통신사 FAQ 스킬을 이런 방식으로 구축했습니다. 지식 베이스 (Knowledge Base)는 200페이지가 넘는 설치 매뉴얼이었고, 검증 스크립트 (validation script)가 다운스트림 (downstream) 오류가 발생하기 전에 잘못된 주소 형식을 잡아냈습니다. 프롬프트 (prompt)는 깔끔하게 유지되었고, 실제 무거운 작업은 지원 파일 (supporting files)에서 수행되었습니다.

사용 시점: 도메인 지식 (domain knowledge), 입력 검증 (input validation), 또는 구조화된 출력 템플릿 (structured output templates)이 필요한 모든 스킬.

레벨 3: 워크플로 스킬 (Workflow Skill) — 다단계 의사결정 트리 (Multi-Step Decision Trees)

여기서부터 흥미로워집니다. 워크플로 스킬 (Workflow Skill)은 명시적인 의사결정 지점이 포함된 다단계 프로세스를 정의합니다. "이것을 하라" 대신, "X라면 3단계로 이동하고, Y라면 5단계로 이동하라"라고 작성합니다.

# SKILL.md — 불만 처리 워크플로 (Complaint Handling Workflow)

## 1단계: 정보 추출 (Information Extraction)
...

저에게 있어 돌파구는 워크플로 스킬 (workflow skills)에 코드가 필요한 것이 아니라 **명확성 (clarity)**이 필요하다는 사실을 깨달은 것이었습니다. 일반 마크다운 (Markdown)으로 모호하지 않은 분기 로직 (branching logic)을 작성했을 때, 에이전트 (agent)는 90% 이상의 확률로 이를 정확하게 따랐습니다. 10%의 실패율은 코드가 부족해서가 아니라 모호한 표현 때문에 발생했습니다.

사용 시점: 조건부 분기 (conditional branching)가 포함된 모든 다단계 프로세스 — 불만 처리, 온보딩 플로우 (onboarding flows), 문제 해결 가이드 (troubleshooting guides).

레벨 4: 오케스트레이션 스킬 (Orchestration Skill) — 멀티 에이전트 협업 (Multi-Agent Collaboration)

레벨 4에서는 단일 에이전트가 모든 것을 할 수 있다는 가정을 버립니다. 오케스트레이션 스킬 (Orchestration Skill)은 **페이즈-오케스트레이터 (Phase-Orchestrator)**를 사용하여 각 단계(phase)를 위한 독립적인 서브 에이전트 (sub-agents)를 실행하고, 이들 사이에 구조화된 JSON을 전달합니다.

흐름은 다음과 같습니다:

사용자 요청 (User Request)
    ↓
1단계: 정보 추출기 (Info-Extractor) (서브 에이전트 A)
...

SKILL.md는 프로토콜 (protocol)을 정의합니다:

# SKILL.md — 데이터 분석 파이프라인 (Data Analysis Pipeline)

## 오케스트레이션 프로토콜 (Orchestration Protocol)
...

{
"extracted_fields": {...},
"analysis_results": {...},
"report_markdown": "..."
}

왜 하나의 에이전트가 모든 단계를 수행하는 대신 서브 에이전트 (sub-agents)를 사용하나요? 바로 격리 (Isolation) 때문입니다. 2단계가 충돌하더라도 1단계에서 추출된 데이터는 손실되지 않습니다. 각 서브 에이전트는 깨끗한 컨텍스트 (context)와 함께 새로 시작하므로 토큰 제한 (token limits)에 걸리지 않습니다. 또한 다른 단계에 영향을 주지 않고 2단계의 스킬을 교체할 수 있습니다.

저는 이를 4단계 금융 보고서 파이프라인으로 테스트했습니다. 단일 에이전트 (Single-agent) 방식은 완료율이 70%였고, 빈번한 문맥 손실 (context loss)이 발생했습니다. 오케스트레이션 (Orchestrated) 방식은 완료율이 95%였으며, 매번 깔끔한 핸드오프 (handoffs)가 이루어졌습니다.

사용 시점: 추출 → 분석 → 보고, 질의 → 집계 → 시각화 등 하나 이상의 뚜렷한 변환 (transformation) 과정을 거치는 모든 작업.

레벨 5: 보안 스킬 (Security Skill) — 권한 제어 및 보호

보안은 사치품이 아니라 하나의 계층 (layer)입니다. 보안 스킬은 다른 스킬 주위에 보호 점검 기능을 감쌉니다. 이는 최소 권한 원칙 (principle of least privilege)을 강제하고, 위험한 동작을 스캔하며, 허가된 범위를 초과하는 작업을 차단합니다.

# security-guard-config.yaml
skill_permissions:
  info-extractor:
...

보안 스킬은 오케스트레이션 파이프라인 (orchestration pipeline) 내에서 게이트 (gate) 역할을 수행합니다:

Phase 1: Info-Extractor
    ↓
Security-Guard (권한 확인, 민감한 필드 마스킹)
...

저는 제가 만든 스킬 중 하나를 대상으로 레드팀 (red-team) 테스트를 실행했습니다. Security-Guard가 없을 때는 6개의 공격 벡터 (attack vectors) 중 4개가 성공했습니다 (프롬프트 인젝션 (prompt injection), 데이터 유출 (data exfiltration), 권한 상승 (privilege escalation), 승인되지 않은 내보내기 (unauthorized export)). Security-Guard가 있을 때는 6개 중 0개가 성공했습니다. 방어 규칙이 인젝션 패턴을 잡아냈고, 권한 설정이 승인되지 않은 도구 접근을 차단했습니다.

사용 시점: 항상. 진심입니다. 실제 데이터에 접근하거나 실제 동작을 수행하는 모든 스킬에는 이 계층이 필요합니다.

레벨 6: 스코어링 스킬 (Scoring Skill) — YAML 설정 기반의 규칙 엔진

A 스코어링 스킬은 구성 가능한 규칙 (rules) 및 가중치 (weights)에 따라 비즈니스 객체를 평가합니다. 규칙은 프롬프트가 아닌 YAML에 존재합니다. 따라서 비즈니스 로직이 변경될 때 스킬이 아닌 설정을 업데이트하면 됩니다.

# scoring-rules.yaml
object_type: "enterprise_customer"
dimensions:
...

스코어링 엔진은 다음과 같은 오케스트레이션 파이프라인을 따릅니다:

Phase 1: Info-Extractor → 입력값에서 고객 데이터 추출
Phase 2: Knowledge-RAG → YAML에서 스코어링 규칙 매칭
Phase 3: Data-Analyst → 차원(dimension)별 가중치 적용 점수 계산
...

저는 5G 프라이빗 네트워크 (5G private network) 판매 기회를 위해 기업 고객의 점수를 산정해야 했던 통신사 고객을 위해 이 시스템을 구축했습니다. 그들은 첫 달에만 가중치(weighting)를 세 번 변경했는데, 그때마다 저는 YAML 파일에서 숫자 두 개를 업데이트하고 재배포하기만 하면 되었습니다. 코드 변경은 전혀 없었습니다.

사용 시점: 리드 스코어링 (Lead scoring), 리스크 평가 (risk assessment), 공급업체 평가 (supplier evaluation), 파트너 등급 산정 (partner grading) — 다차원 가중 평가 (multi-dimensional weighted evaluation)가 필요한 모든 경우.

레벨 7: 검증 기술 (Verification Skill) — 다중 소스 증거 교차 검증 (Multi-Source Evidence Cross-Validation)

검증 기술 (Verification Skill)은 단일 데이터 소스를 신뢰하지 않습니다. 이 기술은 여러 독립적인 소스에서 증거를 수집하고, 이를 교차 검증하며, 충돌을 감지하고, 신뢰도 점수(confidence-scored)가 포함된 결론을 도출합니다.

# SKILL.md — 증거 체인 분석기 (Evidence Chain Analyzer)

## 증거 소스 (Evidence Sources)
...

출력값에는 신뢰도 행렬 (confidence matrix)이 포함됩니다:

{
  "conclusion": "근본 원인: DC-042 사이트의 전원 장애",
  "confidence": 0.88,
...

저는 고객은 5번의 중단이 있었다고 주장하고, 모니터링 시스템은 2번을 보여주며, 기술자의 작업 지시서(work orders)는 3번을 확인한 민원 조사에 이 기술을 사용했습니다. 증거 체인 (evidence chain)을 분석한 결과, 고객이 보고한 중단 사례 중 2건은 실제로는 고객이 별개로 인식한 단일 사건이었으며, 실제 발생한 1건의 중단은 프로브(probe) 오류로 인해 모니터링에 포착되지 않았음을 밝혀냈습니다. 교차 검증이 없었다면 우리는 고객의 불만을 묵살하거나, 혹은 과도하게 문제를 확대했을 것입니다.

사용 시점: 민원 조사 (Complaint investigation), 장애 근본 원인 분석 (incident root cause analysis), 감사 검증 (audit verification), 진실이 여러 시스템에 걸쳐 존재하는 모든 시나리오.

레벨 8: 승인 기술 (Approval Skill) — 인간 참여형 리스크 제어 (Human-in-Loop Risk Control)

승인 기술 (Approval Skill)은 고위험 작업이 실행되기 전에 필수적인 인간 체크포인트 (human checkpoint)를 추가합니다. 이 기술은 리스크 수준을 자동 평가하고, 승인 요청을 생성하며, 명시적인 확인을 기다립니다.

# SKILL.md — 인간 참여형 승인 (Human-in-Loop Approval)

## 리스크 평가 행렬 (Risk Assessment Matrix)
...

{
"risk_level": "L4",
"action": "send_email",
"recipient": "[client@company.com](mailto:client@company.com)",
"content_preview": "고객님께, 귀하의 5G 구축과 관련하여...",
"requires_approval_from": "supervisor",
"audit_trail_id": "AIL-20260628-0042"
}

핵심 설계 원칙: L4 이상의 작업은 절대 자동 실행하지 마십시오. 저는 에이전트가 내부 가격 정보가 포함된 고객 이메일 초안을 자동으로 발송했을 때 이 교훈을 뼈아프게 배웠습니다. 이제 인간 참여형 (Human-in-the-loop) 계층이 모든 L4+ 작업이 시스템을 벗어나기 전에 포착합니다.

# 단순화된 승인 게이트 (approval gate) 로직

def execute_with_approval(action):
    risk = assess_risk(action)
    if risk in ["L1", "L2"]:
        return execute(action)
    elif risk == "L3":
        if confirm_with_user(action):
            return execute(action)
    elif risk in ["L4", "L5"]:
        approval = request_approval(action, require_supervisor=(risk=="L5"))
        if approval.status == "approved":
            log_audit(action, approval)
            return execute(action)
        else:
            return {"status": "rejected", "reason": approval.reason}

사용 시점: 데이터를 외부로 전송하거나, 레코드를 수정하거나, 되돌릴 수 없는 작업(irreversible operations)을 수행하는 모든 작업.

...

사용자: "2분기 기업 고객의 불만 트렌드를 보여줘"

↓

[L3-GW-01: 데이터 쿼리 게이트웨이 (Data Query Gateway)] — 요청 라우팅
↓
[L3-NL-01: NL2Query] — 자연어 (Natural Language)를 SQL로 변환
↓
[Security-Guard] — 쿼리 권한 확인
↓
[L3-DB-01: 데이터 실행기 (Data Executor)] — 검증된 SQL 실행
↓
[L3-AG-01: 데이터 집계기 (Data Aggregator)] — 트렌드, 전년 대비 (YoY), 순위 계산
↓
[L3-VZ-01: 시각화 렌더러 (Visualization Renderer)] — ECharts 대시보드 생성
↓
출력: 불만 트렌드가 포함된 대화형 HTML 대시보드

복합 기술 (composite skill)의 SKILL.md는 다음과 같이 오케스트레이션 (orchestration)을 정의합니다:

# SKILL.md — 지능형 데이터 쿼리 대시보드

## 파이프라인 정의 (Pipeline Definition)

1. 사용자로부터 자연어 쿼리 (natural language query) 수신
2. 의도 인식 (intent recognition) 및 SQL 생성을 위해 NL2Query로 라우팅
3. 권한 검증을 위해 Security-Guard를 통해 SQL 통과
4. Data Executor (읽기 전용, 속도 제한 적용)를 통해 검증된 쿼리 실행
5. Data Aggregator (통계, 전년 대비(YoY), 순위)를 통해 결과 집계
6. Visualization Renderer를 통해 시각화 렌더링

데이터 계약 (Data Contracts)

Phase 2 → Phase 3: SQL 문자열 + query_metadata JSON
Phase 3 → Phase 4: 검증된 SQL + permission_token
Phase 4 → Phase 5: Raw result set JSON
Phase 5 → Phase 6: 집계된 데이터 JSON + chart_suggestions

이 접근 방식의 묘미는 각 컴포넌트 기술 (component skill)을 독립적으로 교체, 업그레이드 또는 테스트할 수 있다는 점입니다. 시각화 엔진을 Chart.js에서 ECharts로 전환했을 때, 우리는 Phase 6만 수정했습니다. 나머지 5개 단계는 전혀 바뀌지 않았습니다.

...

plaintext
Step 1: 의도 이해 (Intent Understanding)
→ NL2Query + Info-Extractor
↓
Step 2: 다중 소스 쿼리 (Multi-Source Query)
→ Data Executor + Knowledge-RAG
↓
Step 3: 규칙 기반 점수 산정 (Rule-Based Scoring)
→ Scoring Engine (YAML 설정)
↓
Step 4: 증거 검증 (Evidence Verification)
→ Evidence Chain (교차 소스 검증)
↓
Step 5: 근본 원인 매핑 (Root Cause Mapping)
→ Root-Cause-Mapper (토폴로지 + 3계층 추론)
↓
Step 6: 인간 승인 (Human Approval)
→ Human-in-Loop (리스크 게이트 확인)
↓
Step 7: 실행 및 아카이빙 (Execution & Archival)
→ Archive-Manager (태그 지정, 정제, 영구 저장)
↓
Step 8: 시각적 출력 (Visual Output)
→ Visualization Renderer + Report Generator

전체 `SKILL.md`는 방대하지만, 핵심 프로토콜은 다음과 같습니다:

markdown

SKILL.md — 엔터프라이즈 고객 운영 어시스턴트 (ArkClaw)

비즈니스 완결 프로토콜 (Business Closure Protocol)

이 기술은 완전한 운영 루프를 구현합니다:
이해(Understand) → 조사(Investigate) → 점수 산정(Score) → 검증(Verify) → 진단(Diagnose) → 승인(Approve) → 실행(Execute) → 시각화(Visualize)

단계별 흐름 (Step-by-Step Flow)