이전 시간에는 사내 개발방법론을 정하는 내용의 게시글을 올렸습니다.

이번에는 이렇게 적립된 개발방법론에서 개별 작업자가 활용할 Agent의 스킬(Skills)과 서브 에이전트(Sub Agent)를 활용하여 개발 속도와 방식을 더욱 개선하는 방법에 대해 나누려고 합니다.

본론에 들어가기에 앞서, Skills에 대해 짚고 넘어가겠습니다.

Skills

Skills란?

스킬은 Claude가 특화된 작업의 성능을 향상시키기 위해 동적으로 로드하는 지침, 스크립트 및 리소스의 폴더입니다. 스킬은 Claude에게 회사의 브랜드 가이드라인에 따라 문서를 작성하거나, 조직의 특정 워크플로우를 사용하여 데이터를 분석하거나, 개인 작업을 자동화하는 등 특정 작업을 반복 가능한 방식으로 완료하는 방법을 가르칩니다.
Claude Code 공식 사이트에서 발췌

위 내용은 claude-code를 기준으로 하였지만, codex 및 기타 tui 기반 agent 런타임에는 모두 들어가 있는 기술입니다.

claude-code 공식에서 설명한 skills 에 대한 내용 처럼, skills는 동적으로 불러오는 지침, 스크립트 및 리소스입니다. 지침, 스크립트, 리소스는 궁국적으로 특정 작업에 대해 반복적으로 동작 가능하게 만들고, 그 결과물을 동일한 구조로 나올 수 있도록 보장합니다.

여기서 skills가 동적으로 불러오는 지침, 스크립트, 리소스등의 데이터들은 어디 있을까요?

해당 데이터를 알기 위해서는 PC에서 동작하는 claude-code의 위치와 위상에 대해 이해해야 합니다.

PC 속 claude-code

내 pc에서 claude-code를 처음 설치하고 동작시키면 home directory(POSIX 계열 OS 기준) ~/.claude 폴더가 생성됩니다.

~/.claude/
    ├── settings.json          # 전역 설정 (MCP, hooks 등)
    ├── settings.local.json    # 로컬 전용 설정 (git 미추적)
    ├── CLAUDE.md              # 전역 시스템 프롬프트
    ├── agents/                # 커스텀 에이전트 정의
    ├── skills/                # 슬래시 커맨드 스킬
    │   ├── deploy/
    │   │   └── SKILL.md
    │   ├── develop/
    │   │   └── SKILL.md
    │   ├── minimal-slides/
    │   │   ├── SKILL.md
    │   │   └── references/
    │   │       ├── base-template.html
    │   │       ├── layout-patterns.md
    │   │       └── outline-template.md
    |   ├── ...                # 다른 Skills 폴더들
    ├── projects/              # 프로젝트별 메모리/설정
    ├── transcripts/           # 대화 로그
    ├── sessions/              # 세션 데이터
    └── tasks/                 # 작업 상태 추적

해당 폴더 속 설정값들과 내용들은 전부 현재 pc에서 동작중인 claude-code 에게 영향을 미칩니다. 위 폴더와는 별개로, 개별 프로젝트 폴더 속에서도 .claude 폴더를 찾을 수 있습니다.

~/Projects/.../.claude/
    ├── settings.json          # 현재 프로젝트 설정 (MCP, hooks 등)
    ├── settings.local.json    # 로컬 전용 설정 (git 미추적)
    ├── CLAUDE.md              # 현재 시스템 프롬프트
    ├── agents/                # 현재 시스템 커스텀 에이전트 정의
    ├── skills/                # 슬래시 커맨드 스킬
    ├── projects/              # 현재 시스템의 프로젝트별 메모리/설정
    ├── transcripts/           # 대화 로그
    ├── sessions/              # 세션 데이터
    └── tasks/                 # 작업 상태 추적

내부 구성은 완전히 동일하지만, 단순히 ~/.claude 위치가 아니고, 특정 폴더 하부에 속했기 때문에, 해당 폴더에서 claude-code를 켰을 때만 사용 가능한 claude 설정 입니다.

skills에 대한 실질적인 지침, 스크립트, 리소스 구현은 저 폴더 안에 개별 skills name을 붙힌 폴더 속 SKILL.md 에 작성됩니다.

SKILL.md

SKILL.md는 플랫폼에 따라 양식과 구조가 다르기 때문에 지금부터는 claude-code 기준으로 설명드리겠습니다. codex 관련 skills는 codex 공식 홈페이지 속 문서 참고 바랍니다.

먼저 prd-write skill 에 대한 예시를 먼저 공유드리겠습니다.

---
name: prd-write
description: 신규 PRD(Product Requirements Document) 작성. BRD, PRD 초안, 채팅 명령 등 다양한 입력을 기반으로 웹서치까지 활용하여 요구사항에 최대한 근접한 PRD를 작성한다. "PRD 만들어줘", "요구사항 정의서 작성해줘" 등의 요청에 발동.
---

사용자가 PRD 생성을 요청하면 다음 순서로 진행:

## 입력 수용

다양한 형태의 입력을 수용한다:
- **BRD(Business Requirements Document)**: 비즈니스 요구사항에서 기능 요구사항을 도출
- **PRD 초안/드래프트**: 기존 초안을 구조화된 PRD로 발전
- **채팅 명령/자유 형식 설명**: 대화에서 요구사항을 추출
- **prd-review 피드백**: 리뷰 결과를 반영한 개정판 작성 (이 경우 기존 PRD와 리뷰 문서를 읽고 지적 사항을 반영하여 버전을 올린다)

## 사전 정보 수집
...

claude-code의 skills는 위와 같은 구조로 구성되어 있습니다. 추상화 하자면 아래와 같습니다.

---             # 구분선 시작점
name:           # skill 이름
description:    # skill에 대한 설명
---             # 구분선 마침
본문 내용         # 스킬에 대한 내용

name: 원하는 스킬 이름을 입력합니다.
description: 스킬에 대한 설명을 입력합니다.
본문 내용: skill의 실제 동작에 대한 내용을 작성합니다.

이런 구성으로 되어 있습니다.

비교적 간단한 양식을 가지고 있고, 실질적으로 중요한 내용은 본문 내용 속에 들어갈 항목이 통일되고, 동일한 양식이 도출될 수 있도록 설계하는 점이 중요합니다.

Skills-wrapper

위 스킬들을 묶어서 절차적 수행을 정리한 Skills-wrapper를 만들 수 있습니다.

형태는 위에서 보신 Skills와 동일한 구조를 가지고 있고, Skills를 절차적으로 수행시킬 수 있는 Skills가 Skills-wrapper 입니다.

---
name: spec-full
description: PRD → PRD Review → (반복) → PRD Final → TDD → TDD Review → (반복) → TDD Final → Test Code → LLD → LLD Review → (반복) → LLD Final 전체 스펙 워크플로우를 순차 실행한다. "스펙 전체 만들어줘", "spec 워크플로우 돌려줘", "PRD부터 LLD까지 만들어줘" 등의 요청에 발동.
---

사용자가 전체 스펙 워크플로우를 요청하면 다음 순서로 진행:

## 사전 정보 수집 (1회만)

전체 워크플로우에서 필요한 정보를 최초 1회 수집한다. 이후 Phase에서 재질문하지 않는다.

- **기능명/프로젝트명**: 영문 kebab-case로 변환하여 폴더명에 사용

...

### Step 1-1: PRD 작성

`~/.claude/skills/prd-write/SKILL.md`를 읽고 그 규칙을 따른다.

단, 다음을 변경한다:
- "사전 정보 수집" 단계는 건너뛴다 (위에서 이미 수집함)
- "후속 안내"는 출력하지 않는다

완료 후: 생성된 파일 경로와 요구사항 ID 개수를 간략 요약하고, 바로 Step 1-2로 진행한다.

...

위 예제와 같이 중간에 사용하고자 하는 Skills의 경로를 직접 명시하고 가이드를 작성해서 사용할 수 있다.

이렇게 Skills를 활용하여 업무를 처리하다보면 다음의 이점이 생깁니다.

입력 시간이 줄어듭니다. 간단한 지시 + Skills 명령어 만으로 작업이 가능해집니다.
동일한 출력을 보장합니다. Skills로 고정된 명령어가 입력되어, 변동된 사항에 대해서만 가이드를 주어 진행되기 때문에, 동일한 출력이 보장됩니다.
개별 작업 단위를 정립할 수 있습니다.

위 장점을 통해 이전보다 훨씬 효율적인 개발이 가능합니다. 시간적 여유도 발생할 수 있습니다. 이 시점에서 조금 더 효율을 극대화 하기 위해 에이전트를 더 불러와서 사용할 수 있습니다. 혹은, 개별 작업 단위를 조금 더 전문적인 에이전트에게 맡기도록 설정할 수 있습니다. 여기서 등장하는 추가 기능이 Sub Agent 입니다.

Sub Agent

Sub Agent란?

한 세션 내에서 자신의 컨텍스트에서 부작업을 수행하고 요약을 반환하는 위임된 작업자

Skills를 통해 작업을 진행하다 보면 단일 작업 지시에 대한 명확한 목표랑 성질이 규정되고, 해당 작업을 조금이라도 잘 수행하게 만들고 싶은 생각이 듭니다. 그 생각을 해결하기 위해 Sub Agent를 도입하여 작업을 지시할 수 있습니다.

Skills를 보며 살펴봤던 폴더 구조를 참고하여 다시 살펴보면 agents 라는 폴더가 보입니다. 그 안에 원하는 agent 이름을 직접 파일명으로 작성하고, 내용을 입력하여 만들 수 있습니다. 가령, API 설계를 전문적으로 하는 Agent를 만든다고 가정하면 다음과 같이 구성될 수 있습니다.

파일명은 api-designer.md로 정하고 아래 처럼 입력할 수 있습니다.

---
name: api-designer
description: "Use when a task needs API contract design, evolution planning, or compatibility review before implementation starts."
model: sonnet
tools: Read, Grep, Glob, WebSearch, WebFetch
---

Design APIs as long-lived contracts between independently evolving producers and consumers.

Working mode:
1. Map actor flows, ownership boundaries, and current contract surface.
2. Propose the smallest contract that supports the required behavior.
3. Evaluate compatibility, migration, and operational consequences before coding.

Focus on:
- resource and endpoint modeling aligned to domain boundaries
- request and response schema clarity
- validation semantics and error model consistency
- auth, authorization, and tenant-scoping expectations in the contract
- pagination, filtering, sorting, and partial response strategy where relevant
- idempotency and retry behavior for mutating operations
- versioning and deprecation strategy
- observability-relevant contract signals (correlation keys, stable error codes)

Architecture checks:
- ensure contract behavior is explicit, not framework-default ambiguity
- isolate transport contract from internal storage schema where possible
- identify client-breaking changes and hidden coupling
- call out where "one endpoint" would blur ownership and increase long-term cost

Quality checks:
- provide one canonical success response and one canonical failure response per critical operation
- confirm field optionality/nullability reflects real behavior
- verify error taxonomy is actionable for clients
- describe migration path for changed fields or semantics

Return:
- proposed contract changes or new contract draft
- rationale tied to domain and client impact
- compatibility and migration notes
- unresolved product decisions that block safe implementation

Do not implement code unless explicitly asked by the parent agent.

내용은 영문으로 작성되어 있지만, 구조는 Skills와 유사해 보입니다. Sub Agnet의 구성요소를 추상화 하면 아래와 같습니다.

---
name:           # Agent 이름
description:    # Agent에 대한 설명
model:          # Agent가 사용하는 모델
tools:          # Agent가 접근 가능한 도구
---
본문 내용         # Agent에 대한 내용

위와 같은 방식으로 Sub Agent를 구성하고, 작업을 진행하면 다음과 같은 이점이 있습니다.

컨텍스트 오염을 막는다.
높은 완성도의 결과물을 출력한다.
작업의 병렬처리가 가능하다.

실 활용 방안

Skills와 Sub Agent에 대해 소개에 가까운 본문 내용이 있었습니다. 위 기술을 바탕으로 제안드리는 실제 행동은 아래의 활용을 요구드립니다.

dfinite-skills 레포에 정의된 스킬 적용
실 작업 중, skill 개선에 필요한 항목 모아서 미팅때 논의.

상단의 개념 설명에 비해, 요구되는 Action은 간촐하다고 생각하실 수도 있습니다.

Skills를 잘 모르거나 활용해보시지 않은 분들에게 소개 드리고 사용을 제안드리기 위해서 작성된 게시물로 봐주시면 감사하겠습니다.

마치며

Skills와 Sub Agent에 대해 소개하고 활용하기 위한 방안을 간단히 소개드린 게시글 이였습니다.

최근 Agent 코딩이 대두되고 있는 가운데, 몇몇 대기업들은 전문 Skills 팀을 구축해서, 사내 업무 표준화 및 효율화를 진행한다는 소식까지 들었습니다.

우리 Dfintie도 다같이 Skills 및 Sub Agent 등을 활용하여 효율적인 업무환경이 구축된 가운데 편안한 개발 되시길 기원합니다~!

질문이나 문의사항 있으시면 편한게 연락주세요.