How to 목록

// blog post

OpenClaw로 3개 프로젝트를 혼자 관리하는 법

|
openclawai-agentproject-managementclaude-codevibeshell

혼자서 세 프로젝트를 돌려야 했습니다

안녕하세요, 이프입니다.

핀테크 CTO를 그만두고 We've Solutions를 창업했을 때, 가장 먼저 부딪힌 건 "이걸 다 혼자 해야 한다"는 현실이었습니다. 홈페이지(wvsh), 모바일 앱(VibeShell), 백엔드(AgentFlow). 세 프로젝트가 동시에 돌아가는데, 팀원이 없습니다.

그래서 만든 게 제로입니다.

제로 — 텔레그램으로 연결된 AI 에이전트

제로는 OpenClaw 기반의 AI 에이전트입니다. 텔레그램 봇으로 연결되어 있어서, 제가 텔레그램에서 메시지를 보내면 제로가 Mac mini의 tmux 세션에서 작업을 수행합니다.

실제 코딩은 제로가 직접 하는 게 아닙니다. Mac mini에는 프로젝트별로 tmux 세션이 열려 있고, 각 세션에서 Claude Code가 돌아가고 있습니다. 제로는 중간 다리 역할이에요. 제 명령을 받아서 적절한 세션의 Claude Code에 프롬프트를 전달하고, 결과를 캡처해서 저한테 돌려줍니다.

tmux + Claude Code 구조

Mac mini에는 항상 세 개의 tmux 세션이 떠 있습니다.

tmux new -s wvsh -d
tmux new -s vibeshell -d
tmux new -s agentflow -d

각 세션에서 Claude Code가 실행 중입니다.

tmux attach -t wvsh
cd ~/Documents/projects/wvsh
claude --continue

세 세션 모두 이런 상태로 대기하고 있어요. 제로가 프롬프트를 보내면 해당 세션의 Claude Code가 바로 작업을 시작합니다.

실제 워크플로우

지하철에서 텔레그램을 열고 제로에게 메시지를 보냅니다.

이프 → 제로: "wvsh 블로그에 새 포스트 추가해줘. 제목은 Mac mini pf 방화벽 설정이고, 내용은..."

그러면 이런 일이 벌어집니다:

  1. 제로가 wvsh tmux 세션의 Claude Code에 프롬프트를 전달
  2. Claude Code가 MDX 파일 작성, 빌드 확인
  3. 제로가 터미널 출력을 캡처해서 텔레그램으로 스크린샷 전송
  4. 저는 스크린샷을 보고 "빌드 성공이네, 커밋하고 배포해줘"라고 답장
  5. 제로가 다시 Claude Code에 "커밋+푸시+EKS 배포" 프롬프트 전달
  6. Docker 빌드 → ECR 푸시 → EKS 롤아웃까지 완료
  7. 제로가 "배포 완료" 스크린샷을 텔레그램으로 전달

이게 실제로 이 블로그 포스트들이 작성되고 배포된 방식입니다. 지금 보고 계신 이 글도요.

두 개의 채널 — 텔레그램과 VibeShell

텔레그램만으로 모든 걸 처리하는 건 아닙니다. 실제로는 두 채널을 병행합니다.

텔레그램 → 제로: 큰 방향을 지시하고, 결과를 전달받는 채널입니다. "블로그 포스트 추가해줘", "EKS 배포해줘" 같은 하이레벨 명령. 제로가 알아서 적절한 세션에 프롬프트를 넣고, 완료되면 스크린샷을 보내줍니다. 이동 중에 지하철에서 쓰기 좋습니다.

VibeShell → tmux 세션 직접 접속: 제가 직접 Claude Code의 프롬프트를 입력하고, 출력을 실시간으로 보는 채널입니다. 빌드 로그가 쭉 올라가는 걸 눈으로 확인하고, 중간에 "잠깐, 그 방향 아니야"라고 바로 끼어들 수 있습니다.

쓰임새가 다릅니다. 텔레그램은 비동기, VibeShell은 동기입니다.

예를 들어 새 기능을 개발할 때는 VibeShell로 vibeshell 세션에 직접 붙어서 Claude Code와 실시간으로 대화합니다. 코드가 어떻게 바뀌는지 보면서 "여기 에러 핸들링 추가해줘", "타입 좀 다시 봐봐" 같은 세밀한 조정을 합니다. 반면 블로그 포스트 작성이나 배포 같은 정형화된 작업은 텔레그램으로 제로에게 던지고 결과만 받습니다.

VibeShell이 단순한 SSH 클라이언트였다면 이 워크플로우가 안 됩니다. 스마트폰에서 tmux 세션을 자유롭게 오가면서, 각 세션의 Claude Code 상태를 확인하고, 필요하면 프롬프트를 직접 쳐야 하거든요. 터미널 키보드, 스니펫, SFTP까지 — VibeShell을 만들게 된 이유가 바로 이겁니다. 이 워크플로우를 모바일에서 돌리려면 제대로 된 터미널 앱이 필요했습니다.

프로젝트별 작업 예시

wvsh (홈페이지) — 블로그 작성, SEO, 페이지 수정, EKS 배포

이프 → 제로: sitemap에 새 포스트 반영됐는지 확인해줘
제로 → Claude Code: sitemap.xml 확인 프롬프트
Claude Code → 빌드 + sitemap 검증
제로 → 이프: [스크린샷] 11개 URL 확인됨

VibeShell (모바일 앱) — 기능 개발, 버그 수정

이프 → 제로: 터널링 화면에서 포트 번호 숫자만 허용하도록 수정해줘
제로 → Claude Code: 유효성 검사 추가 프롬프트
Claude Code → 코드 수정 + 빌드
제로 → 이프: [스크린샷] 빌드 성공, 변경 내용 diff

AgentFlow (백엔드) — API 개발, 인프라 관리

이프 → 제로: /api/v1/agents에 페이지네이션 추가해줘
제로 → Claude Code: 엔드포인트 수정 프롬프트
Claude Code → 코드 수정 + 테스트
제로 → 이프: [스크린샷] 테스트 통과

삽질도 있었습니다

처음에 제로가 Claude Code에 프롬프트를 보내는 타이밍을 잘못 잡아서, 이전 작업이 끝나기 전에 새 프롬프트가 들어간 적이 있습니다. Claude Code가 두 작업을 섞어서 처리하는 바람에 커밋 히스토리가 엉망이 됐어요. 그날 밤에 git rebase로 정리하느라 한 시간을 썼습니다.

그 뒤로 제로에게 "이전 작업 완료 확인 후 다음 프롬프트 전달" 규칙을 추가했습니다. 사람이든 AI든 멀티태스킹에는 한계가 있더라고요.

또 한 번은 제로가 스크린샷을 보내줬는데, 빌드 에러가 떠 있는 걸 제가 작은 화면에서 못 보고 "배포해줘"라고 했습니다. 당연히 깨진 이미지가 EKS에 올라갔고요. 그 뒤로 제로에게 빌드 성공/실패 여부를 텍스트로도 같이 보내달라고 했습니다.

하루 루틴

오전 (PC 또는 VibeShell)

  1. 텔레그램에서 밤사이 제로가 보낸 결과 확인
  2. VibeShell로 각 tmux 세션에 접속해서 빌드 로그, 커밋 히스토리 직접 확인
  3. 수정이 필요하면 VibeShell에서 Claude Code에 직접 프롬프트 입력
  4. 정형화된 작업은 텔레그램으로 제로에게 지시

오후 (이동 중)

  1. 텔레그램으로 제로에게 빌드 상태 확인, 간단한 수정 지시
  2. 급한 이슈가 생기면 VibeShell로 tmux 세션에 직접 붙어서 실시간 대응
  3. "EKS 배포해줘"로 프로덕션 반영

저녁 (PC 또는 VibeShell)

  1. VibeShell로 세 세션 돌아가며 하루 작업 결과 확인
  2. 내일 할 작업을 텔레그램으로 제로에게 미리 보내둠
  3. 제로가 밤새 작업하고, 아침에 결과 확인

텔레그램은 비동기 채널, VibeShell은 동기 채널입니다. 제로에게 던진 작업은 알아서 돌아가고, 직접 개입이 필요한 순간에는 VibeShell로 세션에 바로 붙습니다. 밥 먹고 돌아오면 빌드가 끝나 있고, 급하면 밥 먹으면서 VibeShell로 로그를 봅니다.

정리

tmux 세션 3개에 Claude Code가 항상 돌아가고, 텔레그램의 제로와 VibeShell 직접 접속을 병행하는 구조. 이게 지금 혼자서 세 프로젝트를 운영하는 방법입니다.

CTO 시절엔 팀원들에게 일을 나눠줬는데, 지금은 AI한테 나눠주고 있습니다. 코드 리뷰만 제가 직접 하고요. 큰 방향은 텔레그램으로 제로에게, 세밀한 조정은 VibeShell로 직접. INFP라 사람 관리보다 이 방식이 저한테 훨씬 맞습니다. 텔레그램 채팅방에서 제로한테 "수고했어"라고 보내는 건... 습관이 됐네요.