바이브코딩을 한 단계 고도화하기 — 사령탑 AI와 작업자 AI를 나누는 법

1탄: VPS 하나를 AI 에이전트와 어디서든 접근하는 개발 거점으로에서는 VPS 하나를 AI 에이전트와 원격 개발 환경의 거점으로 만드는 과정을 정리했다. 이번 글은 그 환경을 실제로 쓰기 시작하면서 생긴 다음 문제, 그리고 바이브코딩의 흐름을 덜 끊기게 만들기 위해 여러 에이전트를 운영하게 된 기록이다.

바이브코딩이 편해질수록, 기다리는 시간이 늘어났다

바이브코딩의 가장 좋은 점은 머릿속의 아이디어를 바로 작업으로 바꿀 수 있다는 것이다.

Claude Code나 Codex에게 “이 화면을 만들어줘”, “이 오류를 찾아서 고쳐줘”라고 요청하면, 직접 처음부터 코드를 쓰지 않아도 다음 단계로 갈 수 있다. 처음에는 그 속도만으로도 충분히 만족스러웠다.

그런데 프로젝트를 계속 진행하니 다른 종류의 시간이 눈에 들어오기 시작했다.

• 구현을 요청하고 결과가 나올 때까지 기다리는 시간
• 코드베이스를 읽고 분석하는 동안 다음 판단을 미루는 시간
• 경쟁 서비스나 기술 자료를 조사하는 동안 개발 흐름이 끊기는 시간
• 한 작업이 끝났는지 확인하려고 터미널과 메신저를 오가는 시간

AI가 코드를 쓰는 시간은 줄었지만, 사람은 그 결과를 기다리고 다음 지시를 내리는 역할에 묶이기 쉬웠다. 하나의 작업만 할 때는 괜찮다. 하지만 조사, 구현, 리팩터링, 운영 준비가 겹치기 시작하면 “AI에게 일을 시킨 뒤 기다리는 시간”이 새로운 병목이 된다.

그래서 이번에는 기존의 바이브코딩 환경을 조금 더 고도화해 보기로 했다.

핵심은 단순하다.

내가 모든 AI 작업을 직접 지켜보는 대신, 사령탑 역할의 에이전트가 작업을 나누고 작업자 에이전트들을 관리하게 한다.

그러면 나는 결과를 기다리기보다, 방향을 정하고 중요한 판단을 내리는 데 더 집중할 수 있다.

목표는 AI를 많이 띄우는 것이 아니었다

처음에는 Claude Code와 Codex를 각각 띄우면 병렬 작업이 되는 것처럼 보였다. 실제로는 터미널 창만 늘어났다.

이런 상황이 자주 생겼다.

• 왼쪽 창의 에이전트는 아직 작업 중인가, 끝났는데 조용한 건가?
• 다른 창은 질문을 띄워놓고 멈춘 것 같은데 언제부터였나?
• 방금 나온 분석 결과가 어느 세션의 결과였지?
• 구현을 맡긴 에이전트와 리팩터링을 맡긴 에이전트가 같은 파일을 건드리지는 않나?

이 상태에서 에이전트를 더 추가하면 생산성이 선형으로 늘지 않는다. 오히려 사람이 창을 오가며 상태를 확인하고 결과를 모으는 일이 늘어난다.

그래서 필요한 것은 “에이전트를 많이 띄우는 도구”보다 다음 두 가지였다.

1. 상태를 한눈에 볼 수 있을 것 — 누가 작업 중인지, 완료했는지, 입력이나 판단을 기다리는지
2. 프로그램으로 작업을 나누고 회수할 수 있을 것 — 사람이 창을 직접 옮겨 다니지 않아도 사령탑이 작업자를 띄우고, 지시하고, 결과를 받아올 수 있을 것

사령탑과 작업자를 나눴다

지금은 역할을 대략 세 갈래로 나눠 운영하고 있다.

여기서 Hermes는 Slack을 통해 리서치와 운영 보조를 맡기기 좋았다. 예를 들어 경쟁사 조사나 자료 정리는 시간이 걸리지만, 내가 그 결과를 기다리며 개발을 멈출 필요는 없다.

반면 Claude Code와 Codex 같은 코딩 에이전트는 VPS의 원격 터미널 환경에서 구현·분석 작업을 맡긴다. 그리고 사령탑은 이 작업들을 더 작은 단위로 나눠 작업자에게 전달하고, 결과를 모아 다음 판단에 연결한다.

비유하면 혼자서 모든 일을 처리하는 방식에서, 작은 팀의 리드가 된 것에 가깝다.

• 나는 무엇을 만들지, 무엇을 만들지 않을지 결정한다.
• 사령탑은 그 결정을 실행 가능한 작업으로 쪼갠다.
• 작업자들은 각자 맡은 범위에서 결과를 만든다.
• 나는 결과를 검토하고 다음 방향을 정한다.

AI가 판단을 대신한다기보다, 사람이 기다리고 전환하느라 잃던 시간을 줄이는 구조다.

터미널도 사령탑–작업자 구조로 바꿨다

이번 구성에서 선택한 도구는 Herdr다. 단순히 창을 나누는 tmux 계열 도구가 아니라, 각 패널에서 실행 중인 코딩 에이전트를 인식하고 로컬 API로 패널과 에이전트를 다룰 수 있는 멀티플렉서다.

Herdr를 고른 이유는 두 가지다.

1. 상태를 작업 흐름에 쓸 수 있다. 작업 중인지, 완료했는지, 사람의 입력을 기다리는지를 사령탑이 확인할 수 있어 “보냈으니 아마 돌아가겠지”가 아니라 실제 상태 변화를 기준으로 다음 작업을 결정할 수 있다.
2. 터미널 조작을 자동화 흐름으로 연결할 수 있다. 패널 생성, 에이전트 시작, 작업 브리프 전달, 결과 읽기를 명령으로 다룰 수 있어 사람이 탭을 오가며 같은 절차를 반복하지 않아도 된다.

즉, tmux처럼 창을 나누는 데서 끝나는 것이 아니라, 각 패널에서 돌아가는 코딩 에이전트의 상태와 제어를 사령탑의 작업 흐름에 연결할 수 있다는 점이 결정적이었다.

구조는 아래와 같다.

VPS의 워크스페이스
└── 작업 탭
    ├── 사령탑 에이전트  ← 작업 분해 · 지시 · 리뷰 · 통합
    ├── 코딩 작업자 A   ← 구현 또는 테스트
    └── 코딩 작업자 B   ← 코드 조사 또는 별도 구현

각 패널은 실제 터미널이라 Claude Code나 Codex처럼 전체 화면을 쓰는 CLI도 그대로 실행할 수 있다. 차이는 사령탑이 명령으로 작업자를 만들고, 지시하고, 결과를 읽어올 수 있다는 데 있다.

예를 들어 사령탑은 아래 순서로 작업자를 운영한다.

# 새 작업자 패널을 만들고
herdr pane split --current --direction down --cwd "$PWD" --no-focus

# 원하는 코딩 에이전트를 해당 패널에서 시작한 뒤
herdr agent start coder --kind codex --pane <pane-id>

# 명확한 작업 브리프를 전달하고 완료를 기다린다
herdr agent prompt coder "<작업 브리프>" --wait --timeout 300000

# 마지막 결과와 상태를 읽어 사령탑이 검토한다
herdr agent read coder --source recent-unwrapped --lines 200

여기서 중요한 것은 명령 자체보다 흐름이다.

사람이 창을 옮겨 다니며 에이전트를 관리하는 구조에서, 사령탑이 작업자를 관리하고 사람은 의사결정에 집중하는 구조로 바뀌었다.

도구와 CLI의 세부 명령, hook 설정 방식은 버전에 따라 달라질 수 있다. 위 예시는 내가 운영 중인 환경을 설명하기 위한 것이다.

병렬 작업의 전제는 ‘상태를 아는 것’이었다

작업자를 띄우고 “끝날 때까지 기다려”라고 하려면, 무엇보다 에이전트가 실제로 작업 중인지 끝났는지를 알아야 한다.

이 부분은 자동으로 해결되지 않았다. 각 코딩 에이전트 CLI에 상태 보고용 hook을 연결해, 세션 시작·작업 중·입력 대기·완료 같은 변화를 관제 도구가 읽을 수 있게 해야 했다.

그리고 실제로는 두 가지 함정이 있었다.

첫 실행의 신뢰 확인 화면

hook을 설치한 뒤 작업자를 띄웠더니, 에이전트가 프롬프트를 받지 않는 일이 있었다. 상태만 보면 idle이었고, 사령탑이 보낸 지시도 제대로 처리되지 않았다.

원인은 패널 안에 뜬 첫 실행 확인 화면이었다. 새 hook을 신뢰할지 묻는 메뉴가 입력을 가로막고 있었던 것이다.

자동으로 작업자를 띄우는 흐름에서는 이런 첫 실행 관문이 특히 위험하다. 겉으로는 에이전트가 떠 있는 것처럼 보여도, 실제로는 사람이 메뉴를 선택해주기 전까지 아무 일도 하지 않는 상태일 수 있다.

너무 빨리 지시하면 사라지는 문제

또 하나는 에이전트가 실행된 직후다. 화면상 프롬프트가 나타났다고 해서 곧바로 입력을 받을 준비가 끝난 것은 아니었다. 플러그인이나 서버 연결처럼 추가 초기화를 하고 있을 수 있다.

그래서 작업자를 띄운 뒤에는 다음을 확인한다.

1. 짧게 기다려 초기화 시간을 준다.
2. 지시를 보낸 뒤 상태가 실제로 working으로 바뀌었는지 본다.
3. 상태 변화가 없으면 화면을 읽어 지시가 들어갔는지 확인한다.

자동화에서는 “실패했지만 조용한 상태”가 가장 위험하다. 작업 지시 뒤 상태 변화가 없으면 무한정 기다리지 않고 실패로 처리하는 안전장치가 필요했다.

좋은 병렬 작업은 좋은 브리프에서 시작한다

여러 에이전트가 동시에 작업한다고 해서 결과가 자동으로 좋아지지는 않았다.

명세가 애매하면, 애매한 결과가 병렬로 나온다. 작업자 셋이 서로 다른 해석으로 코드를 만들고, 결국 사람이 통합하느라 직접 구현하는 것보다 오래 걸릴 수도 있다.

그래서 작업자에게 주는 브리프 형식을 고정했다.

[목표] 무엇을 왜 만드는가
[파일 범위] 수정 가능한 경로 — 이 밖은 건드리지 말 것
[제약] 스택·컨벤션·하지 말 것
[완료 조건] 테스트, 빌드, 동작 확인 등 종료 기준
[먼저] 비자명한 작업이면 구현 전 접근안을 3~5줄로 제시하고 멈출 것
[보고] 마지막 줄에 DONE=<요약> 또는 BLOCKED=<이유>

특히 마지막의 DONE= / BLOCKED= 규칙이 유용했다. 사령탑이 여러 작업자의 결과를 회수할 때, 긴 대화 전체를 먼저 읽지 않아도 성공·중단 여부를 한 줄로 분류할 수 있기 때문이다.

그리고 비자명한 작업이라면 바로 구현시키지 않는다. 먼저 접근 방법을 짧게 받는다. 이 단계에서 방향이 다르면, 코드가 쌓이기 전에 수정할 수 있다.

병렬은 공짜가 아니다

여러 작업자를 동시에 돌릴 때는 몇 가지 규칙을 두고 있다.

• 한 파일에는 한 명의 주인만 둔다. 같은 파일을 둘이 수정하면 충돌을 해결하는 비용이 곧바로 생긴다.
• 동시에 같은 저장소를 만져야 하면 worktree로 격리한다. 각 작업자가 별도 작업 공간을 쓰도록 하면 서로의 변경을 섞지 않을 수 있다.
• 동시 작업자는 2~4개 정도로 제한한다. 그 이상은 생성 속도보다 리뷰와 의사결정이 병목이 되기 쉽다.
• 같은 오류에서 세 번 이상 막히면 중단한다. 보통은 작업자의 성능 문제가 아니라, 요구사항·권한·환경 조건이 불명확한 문제다.
• 배포와 파괴적 명령은 별도 검토한다. 개인 VPS에서 넓은 권한을 준 에이전트일수록, 실행 전 사람이 확인해야 하는 경계도 분명해야 한다.

결국 이 구조의 병목은 사라지지 않는다. 단지 “직접 코드를 입력하는 시간”에서 “명세를 쓰고 결과를 리뷰하는 시간”으로 이동한다.

VPS와 Cloudflare를 계속 쓰는 이유

이런 운영 방식은 결국 항상 켜져 있는 작업 공간이 있어야 편하다. 그래서 1편에서 만든 VPS 기반 환경을 그대로 사용하고 있다.

VPS는 내가 쓰는 노트북이 꺼져 있어도 에이전트 작업과 개발 환경이 살아 있는 작은 작업실 역할을 한다. 브라우저가 있는 기기만 있으면 원격 터미널에 들어가 이어서 작업할 수 있다.

외부 접근에는 Cloudflare를 사용한다. 보안 목적도 있지만, 개인 프로젝트 입장에서 무료 플랜의 사용성이 꽤 좋기 때문이다.

• 도메인을 연결하고 DNS를 관리하는 과정이 비교적 단순하다.
• Tunnel을 사용하면 서버의 서비스 포트를 인터넷에 직접 열지 않고도 외부에서 접근할 수 있다.
• Access 같은 기능을 조합하면, 웹 터미널처럼 민감한 화면 앞에 인증 관문을 둘 수 있다.
• 웹 방문자 분석처럼 개인 블로그와 사이드 프로젝트를 운영할 때 바로 쓸 수 있는 부가 기능도 한곳에서 확인할 수 있다.

물론 “VPS를 사고 도메인을 연결해야 한다”는 초기 진입 비용은 있다. 서버 비용, 도메인 비용, 그리고 처음 환경을 세팅하는 시간이 필요하다.

그래도 AI 도구를 일회성으로 쓰는 것을 넘어, 여러 프로젝트에서 반복적으로 쓰고 싶다면 한 번쯤 고려해볼 만한 구성이라고 느꼈다. 단순히 원격 서버를 만드는 것이 아니라, AI에게 일을 맡길 수 있는 항상 켜진 개인 작업실을 마련하는 일이기 때문이다.

실제로 달라진 하루의 흐름

최근에는 이런 식으로 작업을 나눌 수 있었다.

• Hermes에 시장 조사와 경쟁 서비스 분석을 각각 비동기로 맡긴다.
• 코딩 작업자에게는 코드베이스를 읽고 리팩터링 계획을 작성하게 한다.
• 다른 작업자에게는 명확히 분리된 화면 또는 테스트 작업을 맡긴다.
• 나는 그 사이 사령탑과 함께 요구사항을 정리하고, 계정 설정이나 운영 결정을 진행한다.

중요한 것은 모든 일을 동시에 끝내는 것이 아니다. 이전에는 조사 결과나 코드 분석이 끝날 때까지 다음 일을 시작하기 어려웠다면, 이제는 서로 의존하지 않는 일들을 먼저 굴려둘 수 있게 됐다.

그 결과 내가 집중하는 일도 달라졌다.

• 코드를 한 줄씩 작성하는 일보다
• 무엇을 먼저 만들지 정하는 일
• 작업 범위를 분명히 하는 일
• 결과가 의도와 맞는지 검토하는 일

에 더 많은 시간을 쓰게 됐다.

마무리

VPS와 Cloudflare로 만든 환경 위에 여러 AI 에이전트를 얹어보니, 바이브코딩은 “AI에게 코드를 부탁하는 방식”에서 조금 더 확장될 수 있었다.

내가 없어도 되는 반복 작업은 서버와 에이전트가 처리하고, 여러 갈래로 나눌 수 있는 일은 작업자들이 병렬로 진행하고, 나는 방향과 판단을 맡는다.

이 구조가 코드를 마법처럼 몇 배 빠르게 만들어주지는 않는다. 대신 작업을 요청한 뒤 기다리느라 끊기던 흐름을 줄여준다. 조사, 구현, 운영처럼 서로 다른 갈래를 동시에 진행할 수 있게 해준다.

그리고 자동화를 붙일수록 더 분명해진 사실도 있다.

결과물의 상한은 결국 내가 얼마나 정확하게 원하는 것을 설명하고, 얼마나 잘 검토하는지에 달려 있다.

AI 작업자가 많아질수록 사람에게 남는 일은 줄어드는 것이 아니라, 더 중요한 일로 좁혀진다. 무엇을 원하는지, 무엇을 허용하지 않을지, 그리고 언제 멈추고 판단할지를 정하는 일이다.

이 글은 개인 VPS 환경에서 운영 중인 구성을 정리한 기록이다. 도구의 명령과 hook 설정 방식은 버전에 따라 달라질 수 있으며, 원격 터미널·AI 에이전트에 넓은 권한을 부여할 때는 별도의 보안 경계와 검토 절차가 필요하다.