바이브코딩에 입문하기 어려운 이유 중 하나는 쏟아지는 용어들 때문입니다.
Command, Skill, Agent... 뭐가 뭔지 헷갈리죠.
Claude Code를 쓰다 보면 한 번쯤 이런 생각이 듭니다.
"/command는 알겠는데, skill은 뭐고, agent는 또 언제 쓰는거지?"
이걸 모르면 생기는 일
저도 바이브 코딩 입문 후 "설정 많이 하면 좋겠지?" 하고 skill 20개, agent 5개를 만들었어요.
결과는 .. Claude가 오히려 더 혼란스러워졌습니다. (^^..)
어떤 땐 skill A를 따르고, 어떤 땐 agent B의 규칙을 따르고, 가끔은 둘 다 무시하고 제멋대로 하더라고요.
결국 다 지우고 필요한 것만 남기니 오히려 일이 잘 돌아갔습니다.
그때 깨달았습니다! "많이 설정하는 게 아니라, 제대로 설계하는 게 핵심이구나."
이 개념이 애매하면 설정을 아무리 늘려도 체감은 나빠집니다.
왜냐하면 대부분 Claude를 "더 똑똑하게" 만들려고만 하기 때문인데요.
정작 중요한 건 "일이 잘 굴러가게" 만드는 구조를 세팅하는 거니까요!
회사에 비유하면 바로 이해됩니다
Claude Code를 하나의 회사라고 생각해보세요.
당신 = 대표
Claude = 팀원들
문제는 "똑똑한 팀원 한 명"을 채용한다고 해결되지 않습니다.
업무가 흘러가는 방식(프로세스) 을 설계해야 회사가 잘 돌아가죠.
개념
회사 비유
핵심 역할
/Command
버튼 (즉시 지시)
"이거 해" → 바로 실행
Skill
사내 규정
"이런 상황엔 이렇게"
Agent
부서
역할별로 업무 분리
이 3가지의 주요한 개념을 이 글 하나만 봐도 이해할 수 있게 정리해보았습니다
1) /COMMAND는 '버튼'입니다
누르면 바로 실행되는 단일 동작
/command는 즉시 실행되는 지시입니다.
"문서 정리해"
"테스트 돌려"
"커밋 메시지 작성해"
누르는 순간 정해진 동작을 수행합니다.
/command는 판단을 거의 하지 않고 유저가 직접 동작시키는건데요.
그래서 빠르고 편하지만, 상황이 복잡해지면 한계가 생깁니다.
실제 예시
/commit → 변경사항 보고 커밋 메시지 자동 작성
/test → 테스트 실행
/review → 코드 리뷰 요청
👩🏻💻 언제 쓰나요?
매번 똑같이 반복하는 단순 작업
유저가 트리거가 되어 통제하는게 좋은 업무
2) SKILL은 '업무 규정'입니다
반복되는 판단을 미리 정해두는 방식
skill은 "명령"이 아니라 "판단 기준"을 저장해두는 겁니다.
예를 들어:
코드 정리할 때 어떤 기준으로 "불필요한 코드"를 판단할지
테스트는 어디까지 작성해야 '충분'한지
문서는 언제 만들고, 언제 만들지 말아야 하는지
이걸 매번 길게 설명하면 Claude도, 당신도 피곤해집니다.
그래서 skill은 "이 상황이면 이렇게 해"라는 기준을 미리 정해두고, Claude가 필요할 때 꺼내 쓰는 겁니다.
앞선 비유처럼 사내 운영 규정과 같습니다.
"회의록은 이 양식으로 작성한다"
"배포 전 테스트는 최소 3가지 한다"
"새 문서는 만들지 말고 기존 문서에 추가한다"
이런 규정이 있으면 팀원들은 매번 대표에게 묻지 않고도 일관되게 움직이죠.
skill의 진짜 가치는 "일을 더 잘한다"가 아니라, 결정 피로를 줄여서 품질을 안정화한다는 데 있습니다.
실제 예시
# 커밋 메시지 작성 규칙 (skill)
- 제목은 50자 이내, 한글로 작성
- 본문은 "왜" 이 변경이 필요한지 설명
- 이모지 사용하지 않음
- 예시: "로그인 실패 시 에러 메시지 명확하게 수정"
# 코드 리뷰 기준 (skill)
- 보안 취약점 최우선 확인
- 성능 이슈는 측정 가능한 경우만 지적
- 스타일 관련 지적은 3개 이하로 제한
- "이렇게 하면 어떨까요?" 형태로 제안
👩🏻💻 언제 쓰나요?
같은 작업인데 매번 결과물이 달라져 통일이 필요할 때
"이번엔 이렇게 해줘"라고 매번 설명하기 귀찮을 때
품질 기준을 일정하게 유지하고 싶을 때
3) AGENT는 '부서'입니다
똑똑한 한 명이 아니라, 역할을 쪼개는 조직 설계
agent는 '똑똑한 Claude'를 만드는 기능이 아니라, '덜 똑똑해도 되는 Claude'를 만드는 기능입니다.
왜냐하면 agent는 역할과 권한을 제한하기 때문이에요.
"코드 검토자" agent → 코드를 '작성'하지 않고 '검토'에만 집중
"기획자" agent → 실행하지 않고 계획만 수립
"보안 검토자" agent → 보안 관점에서만 점검
메인 에이전트만 쓰는 경우: 기획자에게 개발까지 시키고, 개발자에게 법무 검토까지 시키면? → 한 사람이 모든 걸 하다가 무너집니다.
에이전트를 잘 활용하는 경우:하지만 기획, 개발, 리뷰, 보안을 부서로 분리하면? → 각자는 단순해지고, 전체 시스템은 강해집니다.
실제 예시
# code-reviewer agent
역할: 코드 검토만 수행
권한: 코드 읽기만 가능, 수정 불가
검토 기준:
- 버그 가능성이 있는 로직
- 성능 문제가 될 수 있는 부분
- 보안 취약점
출력 형식:
- 심각도: 높음/중간/낮음
- 위치: 파일명:라인번호
- 설명: 무엇이 문제인지
- 제안: 어떻게 고치면 좋을지
# planner agent
역할: 작업 계획 수립만 수행
권한: 분석과 계획만 가능, 코드 작성 불가
출력 형식:
1. 현재 상황 분석
2. 해야 할 작업 목록
3. 예상되는 리스크
4. 권장 진행 순서
👩🏻💻 언제 쓰나요?
하나의 작업을 여러 관점에서 검토해야 할 때
서로 다른 작업을 동시에 진행해야 할 때
역할 간 맥락이 섞이면 안 될 때
Skill과 Agent의 결정적 차이
여기까지 오셨으면 skill과 agent는 어떻게 구분해서 사용하면 되는지 헷갈리실텐데요!
(저는 많이 헷갈렸습니다..) 간단하게 표로 정리해봤습니다.
Skill
Agent
정체
규칙/기준
독립된 역할자
작동 방식
하나의 Claude가 규칙을 참고
별도의 Claude가 독립 실행
맥락
기존 대화 맥락 공유
맥락이 섞이지 않음 (독립적)
병렬 처리
불가능
가능 (여러 작업 동시 진행)
질문
답
똑같은 작업 반복?
→ /Command
매번 기준이 필요?
→ Skill
역할 분리 필요?
→ Agent
잘 모르겠다?
→ 일단 대화로 하다가 패턴이 보이면 추가
결국 Claude Code로 바이브 코더들이 구축해야하는 것은!
"대표가 일을 잘하는 회사"가 아니라, "대표가 없어도 굴러가는 회사"를 만드는 것 과 같습니다.
