에이전트 바이브코딩 변천사

← 홈으로
Report · 2026-05-28

혼자 만들고 혼자 다듬어온
에이전트 스킬 시스템

Claude Code 커스텀 스킬(/skill)과 Codex 백엔드로 반복 작업을 자동화하는 시스템. 텔레그램 한 줄로 빌드·배포·할일관리·뉴스레터 발행을 처리하는 바이브코딩 인프라가 어떻게 만들어졌는지 기록합니다.

28
활성 스킬
5
참여 기기
800+
커밋 (claude-skills)
~5주
제작 기간

01 변천사 타임라인

2026-04-27 이전
1기 · 태동
첫 슬래시 커맨드 탄생
반복되는 수작업을 줄이고 싶다는 욕구에서 출발. todo · worklog · done · goodnight 같은 일상 관리 스킬이 가장 먼저 만들어졌다. 이 시기는 단일 Mac 세션에서 모든 것을 처리하는 단순한 형태.

아직 기기 간 협력 개념은 없었고, 스킬은 "자동으로 파일에 기록해줘" 수준.
/todo /worklog /done /goodnight /insta-post /morning-briefing /evening-wrap /trend
2026-04-29 ~ 05-04
2기 · 멀티기기 확장
Mac + WSL 2-way 핸드오프 자동화
WSL(Windows 개발 환경)을 두 번째 작업자로 편입. 본진 → WSL 자동 paste 운반체 + WSL → 본진 결과 자동 회신 채널을 만들어 기기 간 작업을 zero-touch로 주고받기 시작. 브랜치 분리 원칙(mac/* · wsl/*)도 이때 확립.

parallel-cycle 등장이 이 시기 핵심. 동시에 N개 작업을 각 기기에 배분하는 최초의 병렬 실행 패턴.
/parallel-cycle /session-clear /pull-apps /wsl-flutter-test /submit-app /handoff /sync /land
2026-05-05 ~ 05-07
3기 · 에이전트 메시
서브에이전트 + 3-way 기기 통신망
loop-run · loop-judge 추가로 PLAN→EXECUTE→JUDGE→REPORT 4단계 루프가 완성됨. Claude가 스스로 작업을 분해하고, 기기별로 배분하고, 결과를 검증하는 에이전트 협력 구조.

기기 간 메시지 포맷 표준화(🍎→🏭 [명령] 형식), trio-vote 등장으로 의사결정도 에이전트화. brainstorm 스킬로 소크라테스식 요구사항 탐색도 자동화.
/loop-run /trio-vote /brainstorm /naver-blog-publish /newsletter-publish /usage /merge-janitor
2026-05-08 ~ 05-09
4기 · 최적화·통합
Codex 합류 + 스킬 다이어트
Mac mini(Codex)가 세 번째 기기로 참여. loop-run · parallel-cycle · night-runner 에 🏭 뱃지 추가. Mac mini는 야간 repo 점검·iOS/Android 실기기 빌드 전담.

동시에 스킬 포트폴리오 다이어트: irun+arun → device-run 통합, loop-judge · session-close · keybindings-help 삭제. trio-vote 동점 시 12명 확장투표 추가.
/device-run /night-runner /irun /arun /loop-judge /session-close /keybindings-help
2026-05-10 ~ 05-11
5기 · 5노드 메시
데스크탑 3060Ti + 노트북3060 추가, fleet-director 등장
기기 5대 체제로 확장. 데스크탑 3060Ti(🖥️)가 GPU 노드 + 챗봇 노드로 합류, 노트북3060(💻)이 mobile/오프라인 캡처 sync 헤드로 편입.

fleet-director v1 plan 도입(D01 시작) — 5대 노드 일과 자동 분배 + subagent-driven 실행. mesh-vote 등장으로 trio-vote의 물리기기 버전 — 3노드 병렬 브레인스토밍 + 상호 투표 — 도 가능.
/mesh-vote /araseo /fleet-director
2026-05-14 ~ 05-15
6기 · Claude Code 단일 스택
외부 에이전트 환경 정리, 노트북3060 Claude Code 신규 셋업
Mac mini 의 외부 LLM provider 게이트웨이 폐기, 노트북 측 외부 에이전트 환경 정리 후 Claude Code 신규 셋업.

5노드 mesh 구성(🍎 본진 · 🏭 Mac mini · 🪟 WSL · 🖥 데스크탑 3060Ti · 💻 노트북3060) 그대로 유지하되 외부 의존성 제거하고 Claude Code 단일 스택으로 통일.
2026-05-16 ~ 05-17
7기 · 5노드 운반체 통일 + 도메인 라이브
5노드 동등 first-class peer + kangdaejong.com 회사 페이지 라이브
기존에 "직접 운반체 미등록" 이었던 데스크탑·노트북에도 운반체 등록 — 5노드 모두 Mac 본진 hub 와 양방향 자동 paste/회신 가능. tmux 세션 이름도 5노드 전부 통일.

kangdaejong.com 도메인 paid 등록 + 회사 페이지(apex+www) · 작업일지(work) · 메일 라우팅 · 큐 대시보드 4개 표면 모두 라이브. 외부 공개 노출 본격 시작.
2026-05-25 ~ 05-28
8기 · 코덱스 백엔드 라이브
5노드 Codex REPL 표준 셋업 + 자면서 앱 빌드 패턴
🍎 본진 · 🪟 WSL · 🖥 데스크탑 · 💻 노트북 4노드가 Codex REPL 활성 노드로 합류. 🏭 맥미니는 Codex 셋업 없이 launchd 워커(night-builder v2 + night-runner v1) 전담으로 역할을 분리했다.

표준값은 Codex CLI 2.1.150, gpt-5.5 xhigh fast, YOLO mode(approval_policy="never" + sandbox_mode="danger-full-access"), features.hooks 마이그레이션, Codex Mesh Mirror 그룹(chat_id -5069144185). codex-mesh-vote / codex-loop-fleet 스킬로 설계·투표·분산 실행 경로를 열었다.

bapeo repo에서는 "자면서 앱 빌드 3원칙" 운영 패턴을 시작했고, PR #7~13 squash merge로 8 PoC + coordinator + finalizer + release + run_chain 흐름을 묶었다.

⚠️ 2026-06-06 EOL · 6/7 sunset 예정: NICEGPTPRO5x 결제 종료로 Codex CLI 자체 미사용. 6/6 까지 정상 가동. 6/7 이후 대안 lane = Anthropic Claude 백엔드 메인 + Claude 토큰 소진 시 OpenRouter API fallback. 9기 (Claude+OpenRouter 혼합) 별 사이클 박을 예정.
/codex-mesh-vote /codex-loop-fleet /bapeo Codex Mesh Mirror YOLO mode

02 현재 기기 구조 — 5대 24/7

🍎
Mac 본진
지휘관 · SoT · 오케스트라 24/7 워커
텔레그램 1차 수신
설계·판단·메인 세션
🪟
WSL Ryzen
24/7 코드 수정·분석
Windows 게이트
빌드/배포 X
🏭
Mac mini
24/7 하드워커
iOS/Android 빌드·배포
launchd 야간 워커
🖥️
데스크탑 3060Ti
24/7 GPU 노드
LLM/SD/Whisper 실험
챗봇 + Codex peer
💻
노트북3060
24/7 + 외출용 sync 헤드
mobile/오프라인 캡처 sync
SSH alias 보존

03 자동화 흐름도

📡 메시지 라우팅 — 기기 간 작업 배분
입력
📱 강대종 텔레그램
🍎 Mac 본진 (hub)
수신 · 판단 · 직접 처리
위임 경로
🪟 WSL · 🏭 Mac mini
자동 paste 운반 → 자율 작업자
🖥 데스크탑 · 💻 노트북
5노드 모두 동일 메커니즘
↩ 결과 자동 회신 + 텔레그램
zero-touch 양방향 보고
🔄 loop-run 4단계 파이프라인
PLAN
Claude가 task 배열 JSON 생성
EXECUTE
5노드 mesh 기기별 실행
JUDGE
3-way 에이전트 합의 검증
REPORT
텔레그램 알림 + 에스컬레이션
⟳ JUDGE FAIL 시 최대 2회 재시도 → 합의 불가 시 강대종 에스컬레이션
🤖 함대 오케스트레이션 — 자동/수동 2레인 (2026-06 역할반전)
자동 레인 (오토)
🏭 Mac mini = 제1 자동 오케스트레이터
야간 codex 30분 사이클로 5노드 fan-out
자율워커 4엔진
본진·맥미니 × 클로드·코덱스 · 머신당 단일엔진 mutex · 자연어/초소버튼 토글
+
수동 레인
매뉴얼 큐 "큐 <할일>"
idle 노드가 하나씩 claim · 처리 · 보고
FIFO + 원자적 claim + lease/reap
노드 죽으면 자동 재큐
🍎 Mac 본진은 수동 거버넌스 게이트키퍼(정책 · main 머지 · 최종 승인), 🏭 Mac mini는 자동 사이클 지휘 — 두 레인 모두 머신당 단일엔진 규칙으로 충돌 차단

04 현재 활성 스킬 28개

2026-05-28 기준 ~/claude-skills의 SKILL.md를 재계산한 활성 스킬 목록. 클린업을 거쳐 살아남은 스킬만 남기고, 실제 반복 사용 기록이 있는 것 중심으로 유지한다.

/autopilot /brainstorm /codex-mesh-vote /context-show /create-play-app /ctx /daejong-page-sync /device-run /done /goodnight /grill-me /insight /insta-post /insta-post-general /issue /merge-janitor /naver-blog-publish /newsletter-publish /pull-apps /send-message /session-clear /submit-app /todo /todo-reminder /trio-vote /usage /worklog /wsl-flutter-test

05 앞으로 이렇게 바이브코딩 하면 좋겠다

🔮 다음 단계 제안

1

스킬은 작게, 조합은 크게

각 스킬은 단일 책임 원칙(SRP)을 지키고, 복잡한 워크플로우는 loop-run · parallel-cycle 로 조합한다. 모노리식 스킬보다 단순 스킬 여러 개가 유지보수하기 쉽다.

2

trio-vote로 결정, loop-fleet으로 실행

"뭘 할지"는 trio-vote(PM·엔지니어·비판론자 3-way 토론)로 결정하고, "어떻게 할지"는 loop-fleet이 5노드 mesh에 task를 자동 분배 + 각 노드가 self-pace로 실행. 사람은 목표만 텔레그램으로 던진다.

3

fleet-director 자율 task picking 안정화

5노드 자율 작업 분배 + lock 관리 + 상태 보고 토대는 이미 구축. 다음 단계는 task picking 알고리즘 정교화 — 노드별 부하·특기·현재 컨텍스트 기반 자동 매칭. 사람이 매번 "이건 누구한테" 정하지 않아도 되도록.

4

스킬 사용 로그 자동 수집

어떤 스킬을 얼마나 쓰는지 자동 기록하면 "실제로 안 쓰는 스킬"을 조기에 발견할 수 있다. 지금은 삭제할 때 이미 늦게 안다.

5

외부 노출 표면 자동 stale 감지

회사 페이지·작업일지·뉴스레터·블로그 등 외부 노출 표면이 늘어나면서 정보 stale 위험도 따라 늘어남. 페이지별 freshness + 박제 후보를 에이전트가 주기적으로 점검하고 텔레그램으로 surface 하는 패턴을 강화. 사람이 직접 발견하기 전에 먼저 알린다.

06 바이브코딩에서 에이전틱 엔지니어링으로

🤖 에이전틱 엔지니어링이란?

바이브코딩이 "내가 원하는 걸 말하면 AI가 코드 초안을 써주고, 내가 감으로 고친다"라면,
에이전틱 엔지니어링은 "AI 에이전트가 목표를 이해하고, 탐색·계획·구현·테스트·검증까지 스스로 한다"는 개념이다.

특징을 비교해 보면 이렇다.

바이브코딩
  • 사람이 방향 + AI가 코드 초안
  • 사람이 결과 검토 후 감으로 수정
  • 단일 작업 단위
  • AI = 코파일럿
에이전틱 엔지니어링
  • 사람이 목표만 설정
  • 에이전트가 계획·실행·검증·보고
  • 복수 에이전트 병렬 처리
  • AI = 자율적으로 일하는 엔지니어

물론 실전에선 두 방식이 한 작업 안에 섞여 있다 — binary 가 아니라 스펙트럼이다.

📍 사실 이미 시작했다

"에이전틱 엔지니어링 갈 수 있을까, 어디서부터 시작해야 할까"를 물었는데 — 답은 이미 시작했다는 것이다. 평범한 하루의 사이클을 들여다보면 이런 흐름이 자주 나온다.

1. 텔레그램 한 줄 trigger → 에이전트가 후보 surface 또는 원인 자동 진단
2. 에이전트가 즉시 대응 + 이슈 초안 작성 → 강대종 OK 한 마디
3. 재발 방지 코드 수정 + 메모리·이슈 박제 → 여러 repo 자동 commit + push
동시에 — 5노드 mesh 중 다른 노드가 자기 상태 자진 보고 → 본진이 디렉티브 전송 → 노드가 자율 실행

사람이 한 건 "텔레그램에서 OK 두어 번". 나머지는 에이전트들이 탐색·진단·수정·검증·보고를 스스로 한다.
에이전트가 자율로 처리하는 영역이 늘어날수록 사람이 손대지 않는 비율도 함께 올라간다 — 이게 우리가 가는 방향이다.

🗺️ 어디서부터 시작하면 될까

이미 하고 있다면 다음 단계는 "수준을 높이는 것"이다. 세 가지 축으로 나눌 수 있다.

1. 목표 명세를 더 정밀하게

"되게 만들어줘" 대신 "X 테스트 PASS / Y 화면 렌더링 / Z 커밋 push" 식으로 검증 가능한 목표를 주면 에이전트 자율도가 올라간다. 목표가 흐릿할수록 사람이 더 많이 개입해야 한다.

2. 에이전트 간 핸드오프를 자동화

본진 ↔ 각 노드 사이에 자동 paste 운반 채널 + 결과 자동 회신 채널을 두면, 에이전트끼리 결과를 주고받을 때 사람이 중간에 끼지 않아도 된다. 5노드 모두 동일 메커니즘으로 묶여있어 새 노드 추가도 어렵지 않다.

3. 이슈 → 예방 → 자동화 사이클

문제가 생기면 이슈 등록 → 재발 방지 코드 → 훅·스킬 자동화. 이슈/피드백을 자동 메모리로 박아두면 다음 세션이 같은 함정을 다시 밟지 않아, 사이클을 빨리 돌릴수록 에이전트 신뢰도가 올라가고 사람 개입이 줄어든다.