바이브 코딩과 에이전틱 워크플로우

앞 장에서 우리는 스킬을 직접 만들었습니다. 이제는 한 단계 더 나아갈 차례입니다. 스킬 하나를 잘 만드는 것과, 스킬 여러 개를 연결해 흐름으로 굴리는 것은 완전히 다른 이야기입니다. 망치 한 자루를 잘 쓰는 것과, 공장 라인을 설계하는 것의 차이라고 해도 좋습니다.

바이브 코딩은 종종 "자연어로 대충 말하면 AI가 알아서 다 해 주는 것"처럼 오해됩니다. 하지만 실무에서 잘 먹히는 바이브 코딩은 대충의 예술이 아니라 구조의 기술에 가깝습니다. 말은 자연어로 하되, 흐름은 분명해야 합니다. 무엇을 만들지, 어디까지 만들지, 어떤 기준으로 끝났다고 볼지, 실패하면 어디로 되돌아갈지를 정해 두어야 합니다. 그때 스킬은 단일 도구가 아니라, 서로 바통을 주고받는 팀이 됩니다.

이 장의 핵심은 단순합니다. 스킬은 한 개씩 쓸 때보다 연결해서 흐름을 만들 때 진짜 생산성이 살아납니다.

4.1 자연어로 설계하고 에이전트로 구현하는 '바이브 코딩' 실전

바이브 코딩의 가장 큰 매력은 키보드보다 머리를 먼저 움직이게 한다는 점입니다. 예전에는 구현을 시작하려면 폴더 구조부터 만들고, 프레임워크를 고르고, 파일을 나누고, 테스트 틀을 깔아야 했습니다. 이제는 그보다 먼저 "내가 원하는 결과가 정확히 무엇인가"를 자연어로 설계할 수 있습니다.

하지만 여기에는 함정이 있습니다. 자연어가 편하다고 해서 모호해도 괜찮다는 뜻은 아닙니다. 오히려 반대입니다. 에이전트는 사람처럼 애매한 뉘앙스를 적당히 메워 주지 않습니다. 빈칸이 있으면 그럴듯하게 채우고, 우리는 그 그럴듯함 때문에 더 쉽게 속습니다. 그래서 좋은 바이브 코딩은 감각으로 시작하되, 곧바로 명세로 내려와야 합니다.¹

실무에서 유용한 시작 방식은 생각보다 간단합니다. 아래 네 가지를 먼저 자연어로 적으면 됩니다.

• 만들고 싶은 결과물

• 반드시 지켜야 할 제약 조건

• 이번 작업에서 하지 않을 범위

• 완료를 판단할 수 있는 기준

예를 들어 "사내 공지 대시보드 하나 만들어 줘"라고 말하면 에이전트는 너무 많은 자유를 갖게 됩니다. 반면 "사내 공지 대시보드를 React와 FastAPI로 만들고, 공지 목록·상세·검색은 포함하되 관리자 기능은 이번 범위에서 빼고, 최소한 로그인 사용자만 조회 가능하며, 테스트와 Docker 실행까지 통과하면 완료로 보자"라고 말하면 갑자기 일이 현실이 됩니다.

이 차이는 아주 중요합니다. 첫 번째는 소원이고, 두 번째는 설계입니다.

에이전틱 개발 도구들은 대체로 비슷한 흐름을 잘 처리합니다. 먼저 요구를 파악하고, 계획을 만들고, 코드를 작성하고, 테스트를 돌리고, 다시 검토하는 식입니다. 어떤 도구는 이 과정을 한 세션 안에서 자동으로 이어 주고, 어떤 도구는 연구용 모델과 구현용 모델을 나눠 쓰게 합니다. 표현은 달라도 공통점은 분명합니다. 잘 되는 흐름은 거의 항상 연구, 계획, 구현, 테스트, 리뷰의 단계를 갖습니다.¹²

여기서 사람의 역할이 사라지는 것은 아닙니다. 오히려 더 중요해집니다. 다만 역할이 바뀝니다. 손으로 다 치는 개발자에서, 방향과 품질 기준을 잡는 감독으로 이동하는 것입니다. 에이전트가 빨라질수록 인간은 더 자주 "무엇을 할지"와 "어디서 멈출지"를 결정해야 합니다.

그래서 실전에서는 처음부터 코딩을 시키기보다, 한 번 계획을 세우게 하고 체크포인트를 두는 편이 낫습니다. 예를 들면 이런 식입니다.

사내 공지 대시보드를 만들고 싶다.
먼저 요구사항을 정리하고, 필요한 화면과 API를 계획한 뒤,
수정될 파일 목록과 테스트 전략까지 포함한 구현 계획만 먼저 제시해 줘.
아직 코드는 쓰지 마.

이 한 줄에는 중요한 안전장치가 숨어 있습니다. "아직 코드는 쓰지 마."

이 문장이 있으면 에이전트는 바로 구현으로 뛰어드는 대신, 먼저 머릿속 지도를 꺼내 보입니다. 그리고 우리는 그 지도를 검토할 수 있습니다. 바이브 코딩의 품질은 여기서 갈립니다. 바로 만드는 속도보다, 만들기 전에 한 번 멈출 수 있는 용기에서 갈립니다.

또 하나 기억할 점은 모든 작업이 에이전틱 모드에 적합한 것은 아니라는 사실입니다. 탐색이 필요한 초기 아이디어 단계, 아키텍처 선택처럼 판단이 중요한 단계, 인증·결제·데이터 마이그레이션처럼 사고 비용이 큰 구간은 사람의 개입 밀도를 높여야 합니다. 반대로 파일 여러 개를 고치되 성공 기준이 분명한 작업, 반복적인 테스트 작성, 문서 업데이트, 리팩터링 보강 같은 일은 에이전트가 아주 잘합니다.¹

요컨대 바이브 코딩은 "말로 코딩한다"가 아닙니다. 더 정확히 말하면 "자연어로 설계하고, 에이전트에게 실행을 맡기되, 중간 검문소는 사람이 잡는다"에 가깝습니다.

4.2 복합 스킬 체이닝: 여러 개의 스킬을 조합하여 복잡한 과제 해결하기

스킬 하나는 능숙한 전문가 한 명과 비슷합니다. 리뷰를 잘하는 전문가, 버전 확인을 잘하는 전문가, 테스트를 꼼꼼히 쓰는 전문가처럼 말입니다. 하지만 제품은 보통 전문가 한 명으로 완성되지 않습니다. 요구사항 정리도 필요하고, 구현도 필요하고, 검증도 필요합니다. 그래서 스킬의 진짜 힘은 개별 성능보다 연결 방식에서 나옵니다.²

가장 쉬운 체이닝 구조는 세 구간으로 나누는 것입니다. 시작 전에 생각을 정리하는 준비 구간, 실제로 코드를 만드는 실행 구간, 만든 결과가 괜찮은지 확인하는 검증 구간입니다. 이 구조만 잡아도 에이전트는 훨씬 덜 흔들립니다.²

예를 들어 새로운 API 기능을 추가하는 작업을 생각해 봅시다. 사람 머릿속에서는 보통 한 덩어리처럼 보이지만, 에이전트에게는 다음처럼 나누는 편이 좋습니다.

• 준비 스킬: 요구사항 정리, 애매한 부분 질문, 범위 제한

• 실행 스킬: 구현 계획 생성, 파일 수정, 테스트 초안 작성

• 검증 스킬: 테스트 실행, 리뷰, 누락 점검, 정리

이렇게 나누면 장점이 많습니다. 먼저 실패 위치가 보입니다. 어디서 잘못됐는지 추적하기 쉽습니다. 다음으로 재사용이 가능합니다. 요구사항 정리 스킬은 API 작업에도, 배치 작업에도, UI 작업에도 붙일 수 있습니다. 마지막으로 품질이 안정됩니다. 구현 스킬이 잘 돌아도 검증 스킬이 별도로 제동을 걸 수 있기 때문입니다.

실제 현장에서는 이 체이닝이 더 촘촘해지기도 합니다. 먼저 질문으로 요구를 다듬고, 그다음 PRD나 작업 명세를 만들고, 이후 합의된 계획을 세운 뒤, 구현을 병렬로 진행하고, 마지막에 QA와 검증 루프를 돌리는 식입니다. 좋은 자율 실행 흐름일수록 "무엇을 만들까?"와 "정말 제대로 만들었나?"를 같은 스킬에 몰아넣지 않습니다.²

예를 들어 팀에서 다음과 같은 체인을 운영할 수 있습니다.

요구 정제 → 구현 계획 → 기능 구현 → 테스트 생성 → 보안/품질 리뷰 → 최종 배포 체크

겉으로는 단순한 화살표 몇 개지만, 이것이 곧 에이전틱 워크플로우의 뼈대입니다. 중요한 것은 순서보다 역할 분리입니다. 설계하는 스킬과 구현하는 스킬, 구현하는 스킬과 검증하는 스킬을 분리할수록 결과가 더 객관적이 됩니다.

여기서 많은 팀이 한 번쯤 저지르는 실수가 있습니다. "만능 스킬"을 만들려는 것입니다. 이름만 봐도 위험한 느낌이 듭니다. ultimate-dev-genius 같은 식입니다. 이런 스킬은 대개 처음 며칠은 멋져 보이지만, 곧 모든 요청에 끼어들고, 책임 경계가 흐려지고, 맥락도 금방 비대해집니다. 결국 에이전트는 똑똑해지는 대신 산만해집니다.

그래서 체이닝을 설계할 때는 세 가지 원칙이 유용합니다.

• 스킬 하나에는 역할 하나를 준다.

• 다음 단계로 넘길 산출물을 분명히 남긴다.

• 검증 스킬은 작성 스킬과 가능하면 분리한다.

이 원칙을 지키면 스킬은 사람 팀처럼 움직입니다. 기획자가 정리한 문서를 설계자가 받아 보고, 설계자가 만든 계획을 개발자가 구현하고, 개발자가 만든 결과를 QA와 리뷰어가 다시 확인하는 식입니다.

복합 스킬 체이닝이 특히 강력한 순간은 반복 작업이 쌓일 때입니다. 처음에는 기능 하나가 빨라진 것처럼 느껴집니다. 그런데 몇 주가 지나면 다른 변화가 보입니다. 팀이 같은 순서로 일하고, 같은 체크포인트에서 멈추고, 같은 형식으로 결과를 남깁니다. 즉, 속도보다 운영 방식이 표준화됩니다. 이때부터 생산성은 한 사람의 요령이 아니라 팀의 시스템이 됩니다.

4.3 워크스페이스 최적화: .system/skills를 활용한 프로젝트별 맞춤 에이전트

좋은 스킬이 늘어나기 시작하면 곧 새 문제가 생깁니다. 어디에 둘 것인가 하는 문제입니다. 개인 노트처럼 여기저기 흩어 놓으면 처음엔 편하지만, 프로젝트가 둘셋만 넘어가도 금방 헷갈립니다. 어떤 스킬은 내 개인 습관이고, 어떤 스킬은 팀 표준이며, 어떤 스킬은 특정 저장소에서만 써야 합니다. 이 차이를 구조로 표현하지 않으면 워크플로우는 오래가지 못합니다.

실무에서는 .system/skills 같은 폴더를 "원본 저장소"로 두고, 실제 에이전트가 읽는 런타임 디렉터리로 배포하거나 링크하는 방식이 꽤 실용적입니다. 다시 말해 .system/skills는 팀이 관리하는 source of truth이고, .agents/skills, .gemini/skills, .cursor/skills 같은 경로는 각 도구가 실제로 발견하는 배포 지점이 됩니다.³⁴⁵

예를 들어 프로젝트 루트를 이렇게 정리할 수 있습니다.

.system/
  skills/
    api-review/
      SKILL.md
      references/
    db-migration-guard/
      SKILL.md
      scripts/
    release-check/
      SKILL.md
  agents/
    AGENTS.md
  rules/
    coding-standards.md

이 구조의 장점은 분명합니다. 스킬의 원본은 한곳에서 관리하고, 도구별 차이는 배포 단계에서 해결할 수 있습니다. 예를 들어 Gemini CLI는 작업 공간의 .agents/skills나 .gemini/skills를 우선 발견하고, 사용자 전역 스킬보다 작업 공간 스킬을 더 높게 칩니다. 즉, 프로젝트 안에 둔 스킬이 개인 전역 스킬을 덮어쓸 수 있습니다.³

이 특성은 프로젝트 맞춤형 에이전트를 만드는 데 아주 유용합니다. 같은 code-review 스킬이라도 어떤 저장소에서는 성능 기준이 중요하고, 어떤 저장소에서는 보안 기준이 더 중요할 수 있습니다. 전역 스킬 하나로 모든 프로젝트를 커버하려고 하면 결국 누구에게도 완벽하지 않은 규칙이 됩니다. 반면 프로젝트 로컬 스킬은 "이 저장소에서만 꼭 지켜야 하는 것"을 분명하게 강제할 수 있습니다.

다만 여기서 중요한 경고가 하나 있습니다. 스킬은 많을수록 좋은 것이 아닙니다. 필요한 것만 골라야 합니다. 관련 없는 스킬까지 한꺼번에 실어 놓으면 문맥이 희석되고, 에이전트는 자꾸 엉뚱한 패턴을 섞어 씁니다. 쉽게 말해 팀 회의에 안 불러도 될 사람까지 모두 들어오면 오히려 결론이 늦어지는 것과 비슷합니다.³⁹

그래서 워크스페이스 스킬을 고를 때는 "현재 프로젝트의 반복 업무"에 집중해야 합니다. 예를 들어 다음처럼 생각하면 편합니다.

• 프론트엔드 중심 프로젝트라면 접근성 리뷰, UI 카피 점검, 디자인 시스템 준수 스킬

• 백엔드 중심 프로젝트라면 API 계약 점검, DB 마이그레이션 가드, 로깅 규칙 스킬

• 운영 자동화 중심 프로젝트라면 배포 체크, 인프라 변경 리뷰, CI 실패 분류 스킬

이 구조를 더 단단하게 만들고 싶다면 스킬 배포까지 자동화하면 됩니다. 최근에는 여러 에이전트 호스트에 맞춰 스킬을 설치·업데이트·버전 고정하는 도구도 등장했습니다. 특히 gh skill 같은 흐름은 저장소에서 스킬을 검색하고, 미리 내용을 살펴보고, 특정 버전이나 커밋으로 고정 설치하는 방식을 제공합니다. 스킬도 이제 복사해 붙이는 파일이 아니라, 의존성처럼 관리해야 하는 자산이 되어 간다는 뜻입니다.⁵

여기서 버전 고정은 꽤 중요합니다. 스킬은 단순 문서가 아니라 에이전트의 행동을 바꾸는 실행 컨텍스트입니다. 따라서 어느 날 조용히 바뀌면 팀 전체의 작업 방식이 흔들릴 수 있습니다. 프로젝트에 들어가는 스킬은 코드처럼 버전과 출처를 추적해야 합니다.⁵

결국 .system/skills의 핵심은 폴더 이름이 아닙니다. 메시지입니다. "에이전트가 일하는 방식도 프로젝트 자산으로 관리하자"라는 선언입니다.

4.4 에이전트 스킬 기반의 CI/CD 및 자동 배포 전략

에이전트가 코드를 잘 쓰는 것만으로는 부족합니다. 잘못 쓴 코드를 빨리 잡아내는 구조가 함께 있어야 합니다. 사람 개발자에게 테스트가 안전벨트라면, 에이전트에게 CI/CD는 가드레일입니다. 둘 다 없으면 빠른 속도는 곧장 사고로 이어집니다.⁶

그래서 에이전틱 워크플로우의 마지막 목적지는 IDE가 아니라 파이프라인입니다. 작업은 자연어로 시작할 수 있지만, 배포 직전에는 결국 기계가 검사해야 합니다. lint, 타입 체크, 단위 테스트, 통합 테스트, 빌드, 보안 점검을 통과하지 못하면 사람이 썼든 AI가 썼든 멈춰야 합니다. 좋은 CI는 작성자를 차별하지 않습니다. 오직 결과만 봅니다.¹⁶

기본 품질 게이트는 익숙한 구조면 충분합니다.

name: CI
on: [pull_request, push]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build

겉보기엔 평범한 GitHub Actions 예제지만, 에이전트 시대에는 의미가 더 커집니다. 이 파이프라인은 단지 코드 검사가 아닙니다. 에이전트가 다음 번에 무엇을 고쳐야 할지 알려 주는 피드백 루프이기도 합니다. CI가 실패하면, 그 로그 자체가 다음 작업 지시가 됩니다.⁶

예를 들어 이런 흐름이 가능합니다.

1. 에이전트가 기능 구현 PR을 엽니다.

2. CI가 타입 오류와 테스트 실패를 잡습니다.

3. 실패 로그를 다시 에이전트에게 넘깁니다.

4. 에이전트가 수정 커밋이나 추가 푸시를 만듭니다.

5. CI가 다시 검증합니다.

이 구조가 안정되면 사람은 매번 처음부터 설명하지 않아도 됩니다. 실패 메시지가 곧 다음 입력이 되기 때문입니다. 에이전트는 행동하고, CI는 판단하고, 사람은 승인 시점을 고릅니다. 이것이 실전적인 에이전틱 개발 루프입니다.⁶⁸

한 걸음 더 나아가면, 에이전트는 로컬 도구를 넘어 이벤트 기반으로 움직일 수 있습니다. 이슈가 열리면 버그 수정 초안을 만들고, PR 코멘트가 달리면 문서를 갱신하고, 매주 정해진 시간마다 의존성 업데이트 PR을 올리는 식입니다. 즉, 사람이 직접 터미널을 두드릴 때만 일하는 조수가 아니라, 저장소 이벤트를 계기로 움직이는 작업자에 가까워집니다.⁸

이때 중요한 것은 신뢰 수준을 단계별로 올리는 것입니다. 처음부터 자율 병합까지 맡기면 대부분의 팀은 불안해서 오래 못 갑니다. 보통은 다음 순서가 자연스럽습니다.⁸

• 처음에는 초안 PR만 생성하게 합니다.

• 다음에는 CI 통과 시 자동 리뷰 요청까지 맡깁니다.

• 충분히 검증된 저위험 작업에만 자동 병합을 검토합니다.

문서 수정, 포맷 정리, 릴리스 노트 생성, 사소한 테스트 보강처럼 사람이 거의 고무 도장만 찍던 영역부터 자동화를 시작하면 부담이 적습니다. 반대로 인증, 결제, 권한, 데이터 변경처럼 사고 비용이 큰 영역은 끝까지 인간 승인 단계를 남겨 두는 편이 좋습니다.

스킬도 이 파이프라인 안으로 넣을 수 있습니다. 예를 들어 릴리스 노트 작성 스킬, CI 실패 분류 스킬, 보안 리뷰 스킬을 CI 단계에서 호출하도록 설계할 수 있습니다. 최근의 스킬 관리 도구들은 이런 배포를 위해 스킬 설치, 미리보기, 업데이트, 버전 고정까지 지원합니다. 특히 설치 전에 내용을 살펴보고, 특정 태그나 커밋으로 고정하는 습관은 공급망 위험을 줄이는 데 중요합니다.⁵

에이전트 전용 평가 체계도 점점 중요해지고 있습니다. 일반 소프트웨어 CI가 코드의 정합성을 본다면, 에이전트 CI는 여기에 더해 행동의 일관성까지 검사합니다. PR마다 평가 세트를 돌려 응답 품질이나 안전성을 확인하고, 브랜치마다 다른 환경으로 점진 배포하는 식입니다. 에이전트를 소프트웨어처럼 다룬다는 말은, 결국 프롬프트와 스킬도 테스트 대상이라는 뜻입니다.⁷

자동 배포 전략에서도 원칙은 같습니다. 자주, 작게, 되돌릴 수 있게 배포해야 합니다. 에이전트가 만든 변경은 특히 더 그렇습니다. 큰 한방보다 작은 여러 번이 안전합니다. 그래서 스테이징을 먼저 거치고, 기능 플래그로 노출을 조절하고, 롤백 경로를 미리 준비하는 방식이 잘 맞습니다.⁶

결국 CI/CD는 에이전트를 못 믿어서 붙이는 장치가 아닙니다. 믿을 수 있을 만큼 반복 검증하기 위해 붙이는 장치입니다. 사람도 실수하고, 에이전트도 실수합니다. 차이는 누가 더 똑똑하냐가 아니라, 누가 더 빨리 피드백을 받고 수정 루프에 들어가느냐입니다.

스킬 기반 CI/CD가 자리를 잡으면 개발 문화도 달라집니다. "누가 이걸 짰지?"보다 "이 변경은 어떤 검증을 통과했지?"가 더 중요한 질문이 됩니다. 그 순간부터 팀은 AI를 잘 쓰는 수준을 넘어, AI가 일해도 흔들리지 않는 시스템을 가진 팀이 됩니다.

바이브 코딩은 감으로 시작해도 괜찮습니다. 하지만 실무는 결국 흐름이 책임집니다. 자연어로 설계하고, 스킬을 엮어 실행하고, 프로젝트에 맞게 워크스페이스를 정리하고, CI/CD로 끝까지 검증하는 것. 이 네 단계가 맞물리면 에이전트는 더 이상 재주 좋은 채팅 상대가 아닙니다. 함께 일하는 개발 파이프라인의 일부가 됩니다.

참고

¹Agentic Vibe Coding: Multi-Agent AI Coding Workflows | VibeWerks

²Vibe Auto Coding — Agent 자율 코딩 완전 가이드 :: GilliLab - TechLog

³Agent Skills | Gemini CLI

⁴GitHub - ChristopheZhao/vibe-coding-skills: A reusable skills library for vibe coding agents and workflows

⁵Manage agent skills with GitHub CLI

⁶agent-skills-google/skills/ci-cd-and-automation/SKILL.md at main · InformationX/agent-skills-google · GitHub

⁷Continuous Integration (CI/CD) - Agent CI Documentation

⁸Agentic Workflows Explained: How AI Agents Are Changing CI/CD Pipelines

⁹GitHub - microsoft/skills: Skills, MCP servers, Custom Agents, Agents.md for SDKs to ground Coding Agents