🛠️ 09. 에이전트보다 스킬부터

영상 제목은 강하게 시작하지만, 실무 관점에서 핵심은 더 현실적입니다. “에이전트를 만들지 마라”가 아니라, 범용 에이전트를 먼저 크게 짜기보다 재사용 가능한 스킬 단위부터 설계하라는 메시지에 가깝습니다.

현장에서 실패가 많은 이유도 비슷합니다. 처음부터 큰 자동화 파이프라인을 만들면 멋있어 보이지만, 유지보수와 품질 검증이 어려워집니다. 반대로 작은 스킬 단위로 쪼개면 검증·교체·재사용이 쉬워져서 결과적으로 더 빨리 갑니다.

flowchart LR
A[문제 인지<br/>에이전트만 키우다 복잡도 증가] --> B[원인 분해<br/>업무 단위/기준 미정의]
B --> C[대응 선택<br/>스킬 단위로 분해]
C --> D[실행/검증<br/>작은 실험 반복]

🧠 칠판 치트시트

• 큰 에이전트 1개보다, 검증 가능한 스킬 3개가 운영에 강하다.
• 스킬은 “입력/출력/실패 처리” 3가지만 먼저 고정한다.
• 재사용률이 올라가면 속도보다 품질 편차가 먼저 줄어든다.
• 도입 첫 주에는 ‘완성도’보다 ‘반복 가능성’을 확인한다.

영상 핵심 요약

• 매번 에이전트를 새로 만들기보다 스킬 레이어를 먼저 쌓는 전략을 제안한다.
• 스킬 단위는 도메인 지식을 빠르게 붙이고 재사용하기 쉽다.
• 실제 데모(웹사이트 GEO 감사)처럼 서비스형 산출물까지 연결할 수 있다.
• 대상은 개발자뿐 아니라 마케터·운영자·사업팀까지 확장 가능하다.

왜 이 방식이 실무에서 유리한가

에이전트 중심 접근은 초반 데모는 빠른데, 운영 단계에서 무너지기 쉽습니다. 원인은 대체로 같습니다.

• 입력 조건이 조금만 바뀌어도 결과 품질이 흔들림
• 실패 상황(예외 입력, 누락 데이터) 처리 규칙이 없음
• 팀원이 바뀌면 사용법이 달라져 재현이 어려움

스킬 중심 접근은 이 문제를 줄입니다. 업무를 작은 단위로 나누고 각 단위에 기준을 붙여두면, 새 요구가 와도 전체를 다시 뜯지 않고 일부만 교체하면 됩니다.

영상에서 건질 실행 포인트 4가지

1) 스킬은 문서부터 만든다 (코드보다 기준)

먼저 무엇을 받아서 무엇을 내보내는지를 고정해야 합니다. 여기서 흔히 말하는 스킬 문서(SKILL.md류)는 사람 설명서가 아니라 실행 계약서에 가깝습니다.

실행 순서:

• 입력 형식(필수/선택) 정의
• 출력 형식(길이/포맷/품질 기준) 정의
• 실패 시 행동(재시도/폴백/중단) 정의

검증:

• 같은 입력 3회 실행 시 결과 편차가 줄었는지 확인

2) 큰 파이프라인 대신 작은 스킬 체인으로 시작

“리서치→요약→리라이팅→검수”처럼 단계를 쪼개면 어디서 문제가 나는지 바로 보입니다.

실행 순서:

• 현재 업무를 3~5단계로 분해
• 각 단계별 성공 기준 1개씩 지정
• 가장 불안한 1단계부터 파일럿 적용

미니 사례:

• Before: 한 번에 긴 프롬프트로 처리, 오류 원인 파악 어려움
• After: 단계 분리 후 병목 구간이 명확해져 수정 속도 개선

3) 재사용 가능한 스킬은 “도메인 지식”이 붙는다

영상 데모처럼 특정 주제(GEO/감사/리포트)에 맞춘 스킬은 반복할수록 빨라집니다. 범용 에이전트보다 결과 일관성이 좋아지는 이유입니다.

실행 순서:

• 업무 도메인 핵심 규칙 5개를 먼저 문서화
• 스킬 출력에 반드시 포함할 체크 포인트를 고정
• 산출물 템플릿(보고서, 체크리스트)과 연결

검증:

• 신규 작업 온보딩 시간(처음부터 결과까지) 비교

4) ‘도입 여부’보다 ‘도입 구조’가 성과를 가른다

같은 툴을 써도 어떤 팀은 성과가 나고 어떤 팀은 피곤해집니다. 보통 차이는 도입 구조에 있습니다.

실행 순서:

• 도입 첫 주 목표를 ‘완성’이 아닌 ‘재현 가능’으로 설정
• 매일 1회 회고: 실패 1개, 개선 1개 기록
• 주말에 스킬 문서를 한 번 정리해 다음 주 기준으로 확정

20분 도입 루틴 (바로 실행)

1. 반복 업무 1개를 고른다. (예: 주간 리포트 초안)
2. 입력/출력/실패 처리 3항목을 10줄 안에 적는다.
3. 오늘은 1단계만 자동화해 결과를 본다.
4. 결과 품질보다 편차(들쭉날쭉함)부터 체크한다.
5. 내일은 가장 흔한 실패 1개만 고쳐서 다시 실행한다.

점검 메모

• 영상의 주장(“에이전트 대신 스킬”)은 맥락이 중요합니다. 모든 상황에서 에이전트가 불필요하다는 뜻은 아닙니다.
• 초기 운영 단계에선 스킬 단위 설계가 특히 유리하다는 실무 관찰로 받아들이는 편이 안전합니다.

다음 읽기

• 54. Claude Code Skills, 더 강해지는 운영법
• 56. 스킬 없는 멀티 에이전트는 그냥
• 58. 앤쓰로픽 개발자가 알려준 12가지, 실무에 남기는 법

영상 메타

• 채널: Zubair Trabzada | AI Workshop
• 제목: STOP Building AI Agents. Do THIS Instead.
• 길이: 약 11분 50초
• 영상: https://www.youtube.com/watch?v=wqH1hTkA6qg

이 문서는 생성형 AI를 활용해 초안을 구성했고, 영상 설명과 공식 문서를 교차 확인해 실무형으로 재정리했습니다.