제1회·제2회 기사에서 기존의 .NET 자산으로부터 Skill을 생성했습니다.

이 단계에서 만들어지는 것은 1개의 함수 = 1개의 Skill이라는 입도(Granularity)의 것입니다.

select_order_list ← 발주 목록을 취득한다
get_inventory ← 재고를 취득한다
update_order_status ← 발주 상태를 갱신한다
...

이것들을 AI가 조합하여 움직이게 할 수는 있습니다. 하지만 실제 업무를 처리하게 하면 다음과 같은 문제가 발생합니다.

"이 처리, 매번 AI에게 절차를 설명해야 한다"

"발주 잔량이 있으면 담당자에게 통지해줘"라는 의뢰에 대해, AI는 매번 "먼저 목록을 취득하고, 다음으로..."라고 다시 생각합니다. 절차가 정해져 있음에도 불구하고, 의뢰할 때마다 추론(Inference)이 실행됩니다.

그 '정해진 절차'를 Skill로서 고정시킨 것이 업무 플로우 Skill입니다.

2종류의 Skill을 대비하면 다음과 같습니다.

API 레벨 Skill은 "부품", 업무 플로우 Skill은 "절차서가 실행 가능해진 것"이라는 이미지입니다.

제1회에서는 "기존 소스 코드가 AI의 사양서가 된다"라고 썼습니다. 업무 플로우 Skill에서는 업무 매뉴얼이 사양서가 됩니다.

업무 매뉴얼 (안내서·규정·절차서)
↓ 읽기
처리 순서·판단 조건·필수 체크·예외 처리
...

예를 들어 "발주 잔량 점검 및 통지"라는 업무 매뉴얼에 다음과 같은 기재가 있다고 가정합니다.

1. 당월 발주 잔량 목록을 취득한다
2. 납기 초과(14일 이상)인 것을 추출한다
3. 담당자별로 집계한다
...

이 절차와 판단 조건을 그대로 Skill로서 구현합니다.

# 업무 플로우 Skill의 내부 (개략)
def run(target_month):
# ① 목록 취득
...

AI가 매번 절차를 추론하는 것이 아니라, 매뉴얼에 기반한 판단 로직이 Skill 안에 고정되어 있습니다.

업무 플로우 Skill은 여러 개의 API Skill을 묶은 래퍼(Wrapper)입니다.

업무 플로우 Skill
├── SKILL.md ← 업무의 목적·트리거·준거 매뉴얼을 기재
└── run.py ← 여러 API Skill을 호출하는 처리 플로우
...

SKILL.md에는 어떤 업무 매뉴얼에 기반하고 있는지를 명기합니다.

## 준거 매뉴얼
- 발주 관리 규정 제3장 (납기 초과 대응)
## 트리거
...

이를 통해 왜 이 판단 로직이 되어 있는지의 근거가 Skill에 남습니다. 매뉴얼이 개정되었을 경우, 어떤 Skill을 업데이트해야 하는지도 명확해집니다.

업무 플로우 Skill을 만들다 보니, 처리 구조가 몇 가지 패턴으로 수렴한다는 것을 알게 되었습니다.

데이터 취득 → 조건으로 필터 → 집계·목록화 → 보고

가장 안전한 패턴. DB를 바꾸지 않기 때문에 어떤 환경에서도 안심하고 실행할 수 있습니다.

"~의 상황을 확인해줘", "~에 문제가 없는지 점검해줘"라는 의뢰에 대응합니다.

현상 확인 → 처리 실행 → 결과 확인 → 통지

갱신계(Update)를 포함하는 패턴. 실행 전에 현상을 확인하고, 실행 후에 결과를 재취득하여 정합성을 확인합니다.

데이터 취득 → 제시 (여기서 멈춤) → 사람이 확인 → 확정 실행

불가역적인 처리나 금액이 큰 처리는 도중에 사람의 확인을 거칩니다.

에이전트(Agent)가 "여기까지 준비했습니다, 내용을 확인하고 승인해 주세요"라고 멈추고, 사람이 승인한 후에 다음 단계로 진행하는 설계입니다.

자율적으로 움직이는 에이전트라도, 모든 것을 자동화하지 않는다는 설계 판단이 중요합니다.

특히 다음과 같은 케이스는 사람의 확인을 필수적으로 하고 있습니다.

사람 게이트(Human Gate)가 있는 Skill은 "준비까지"와 "확정 실행"을 명확하게 나누어 구현합니다.

준비 페이즈
─ 데이터 취득·검증·초안 생성
─ 담당자에게 "내용을 확인해 주세요"라고 통지
...

에이전트가 "준비하고 기다린다", 사람이 "확인하고 승인한다"라는 분업이 자연스럽게 성립합니다.

2종류의 Skill은 발견 및 호출 경로도 분리하여 관리하고 있습니다.

업무 플로우 (Workflow) Skill (소수·업무 담당자가 사용)
─ AI가 "발주 잔량 확인"이라고 들으면 직접 매칭
─ SKILL.md에 트리거 문구(Trigger Phrase)를 명시
...

업무 담당자가 "~해줘"라고 요청했을 때, AI는 업무 플로우 Skill을 선택합니다. 그 내부에서 API 레벨 Skill이 동작하는 2층 구조입니다.

• ✅ 절차가 고정됨 ─ 매번 AI가 추론할 필요가 없어 결과가 안정적임

• ✅ 매뉴얼과의 대응이 명확함 ─ 어떤 규정·절차서에 기반하는지가 Skill에 남음

• ✅ 사람의 개입(Human Gate)을 설계에 포함할 수 있음 ─ 자동화와 사람의 판단 경계를 명시할 수 있음

• ✅ 제1회·제2회의 Skill 자산을 그대로 활용할 수 있음 ─ 기존의 API Skill을 묶기만 하면 됨

API 레벨 Skill (제1회·제2회): 함수 단위의 부품
업무 플로우 Skill (이번): 매뉴얼에 기반한 절차의 구현

이 2층 구조를 조합함으로써, "자연어로 의뢰한다 → 업무 매뉴얼대로 처리된다"라는 흐름이 완성됩니다.

업무 플로우 Skill이 늘어날수록 에이전트가 대응할 수 있는 업무의 폭이 넓어집니다. 그리고 Skill의 수가 늘어났을 때 새로운 과제가 발생합니다 ─ 다음 회차에서는 그 이야기(Skill이 너무 많아졌을 때의 컨텍스트 관리)를 다루겠습니다.