맥북 + WSL + Mac mini 삼각 편대로 Flutter 앱 6개 동시 운영하기

바이브코딩 뉴스레터 Ep.6 — 1인 개발자의 멀티 기기 병렬 작업기

2026-05-03

기기가 세 대가 된 건 의도가 아니었다.

맥북이 있고, 집에 남는 맥 미니가 있고, 윈도우 PC에 WSL이 깔려 있었다. 어느 날 세 기기가 동시에 같은 레포를 보고 있다는 걸 눈치챘고, 그걸 정리하지 않고 구조화하기로 했다.

이 뉴스레터는 1인 인디 개발자가 Claude Code 두 세션(Mac·WSL)과 함께 의사결정을 내리는 흐름의 기록이다. Ep.1 은 만들기, Ep.2 는 죽이기, Ep.3 는 빼기, Ep.4 는 잇기, Ep.5 는 돌리기 였다. 이번 Ep.6 는 나누기 — 한 사람의 일을 세 기기가 나눠 맡게 됐을 때, 그 구조가 어떻게 생겼는지의 이야기다.

삼각 편대가 생기기까지

Flutter 앱을 하나 만들 때는 기기 한 대면 충분하다. 빌드하고, 테스트하고, 심사 제출하면 끝이다.

앱이 두 개가 되면 조금 달라진다. iOS와 Android를 동시에 올릴 때, 빌드 시간이 병목이 된다. 셋이 되면 더 나빠진다. 여섯 개가 되면 — 한줄일기, 단어요, 약먹자, 더치페이, 포모도로, 한컵 — 빌드·서명·업로드 루틴이 혼자서 감당하기 버거운 덩어리가 된다.

해결책은 사람을 더 쓰는 게 아니다. 기기 역할을 나누는 것이다.

역할 분담: 세 기기, 세 성격

🍎 Mac 본진 — 설계·판단·메인 세션

맥북 프로다. 사실상 24시간 고정 운영 중이다(집 데스크탑처럼 쓰고 있다). 여기서 하는 일은 코드 수정보다는 의사결정이 많다.

강대종과의 1차 대화는 전부 여기서 받는다
“이 기능 넣을까?”, “이 앱 드롭할까?” 같은 판단
PR 리뷰, 아키텍처 설계, 메모리 관리
다른 두 기기로 작업을 내려보내는 지휘

코드를 직접 건드리는 경우도 있지만, 기본 역할은 두뇌다.

🏭 Mac mini — 빌드·서명·배포 엔진

M1 Mac mini다. 24/7 켜 두고 launchd로 야간 잡을 돌린다. 여기서 하는 일은 판단이 아니라 실행이다.

iOS .ipa 빌드 + codesign + TestFlight 업로드
Android .aab 빌드 + jarsigner + Play 업로드
야간 03:30 KST에 자동으로 4개 앱 빌드 체크
asc-deliver + ASC API로 심사 제출까지

Mac mini가 없으면 빌드 한 번에 30분씩 맥북을 잡아먹는다. 야간에 자고 있어도 빌드 결과가 텔레그램에 와 있게 만드는 게 목표였다.

🪟 WSL — 코드 수정·분석·낮 즉응 작업

윈도우 PC에 설치된 WSL이다. 낮에 ON, 밤에 OFF다(야간 잡 호스트로는 쓰지 않는다). 여기서 하는 일은 실질적인 손 작업이다.

기능 추가, 버그 수정, 리팩터링
레포 분석, 로그 파악, 이슈 디버깅
Mac 본진이 내린 디렉티브를 받아서 실행
완료 후 PR 생성 → 본진에 보고

세 기기가 동시에 같은 레포를 건드리지 않게 하는 규칙이 핵심이다. 같은 파일, 같은 브랜치 동시 수정 금지. 어기면 충돌이 난다.

zero-touch 핸드오프: 사람 없이 정보 전달하기

세 기기가 따로 놀면 아무 의미가 없다. 연결이 필요하다. 그런데 연결할 때마다 사람이 복붙을 해야 하면 자동화가 아니다.

두 개의 운반체 스크립트를 만들었다.

wsl-directive.sh — Mac이 WSL에 작업 지시 내리기

Mac 본진에서 WSL로 작업을 넘길 때 쓴다. “이 기능 구현해”, “이 파일 수정해”, “PR 만들어” 같은 지시를.

~/.claude/automations/scripts/wsl-directive.sh

이 스크립트가 하는 일은 단순하다. WSL의 tmux 세션에 디렉티브 텍스트를 자동으로 붙여넣는다. WSL의 Claude Code 세션이 깨어나서 지시를 읽고 실행한다. 사람이 복붙할 필요가 없다.

디렉티브 본문에는 목표, 수정 파일 목록, 금지 사항, 성공 기준이 다 들어간다. 새 채팅 첫 메시지라고 가정하고 쓴다 — WSL 세션이 맥락 없이 받아도 실행할 수 있게.

mac-report.sh — WSL이 Mac에 완료 보고 올리기

WSL이 작업을 끝내면 본진에 보고해야 한다. 이게 없으면 Mac 본진이 WSL 작업 결과를 모르고 넘어간다.

~/.claude/automations/scripts/mac-report.sh <report_abs_path> "3줄 요약"

이 스크립트는 두 채널로 동시에 보낸다.

1차: Mac 본진 tmux의 claude 세션에 보고서를 paste → 본진 Claude가 자동으로 깨어나 검토
2차: 텔레그램으로 강대종에게 1통 (사람 채널)

1차가 닿지 않으면 — SSH 다운, tmux 세션 없음 — 2차만 간다. 강대종이 손으로 운반하면 된다.

실제로 일어난 사고 두 가지

구조가 아무리 좋아도 사고는 난다. 두 가지가 기억에 남는다.

사고 1: stale context로 충돌이 났다

WSL 세션이 Mac 본진 작업을 모른 채 같은 파일을 수정하기 시작했다. Mac에서 이미 push된 변경이 있었는데 WSL은 git pull 없이 작업을 시작했다.

결과는 예측 가능하다. push가 거부됐고, merge conflict가 났다.

이후 규칙을 하나 박았다. 모든 세션, 모든 작업 시작 전 git pull 먼저. 코드 한 줄 건드리기 전에 git fetch + pull이 선행돼야 한다. 이 규칙이 안 지켜지면 “어제 수정한 게 어디 갔지?”라는 상황이 반복된다.

사고 2: Mac 본진 tmux zombie lock

4월 30일 밤 9시, Mac 본진에서 새 Claude 세션을 열려고 했더니 열리지 않았다.

원인은 4월 28일부터 남아 있던 tmux 좀비 클라이언트 4개가 세션 lock을 점유하고 있었던 것이다. 새 플러그인 시작이 계속 실패했고, 얼마나 기다려도 풀리지 않았다.

WSL에서 SSH로 접속해 kill 명령으로 좀비 프로세스를 직접 잡았다. 10분도 안 걸렸지만, 이 상황이 발생했다는 게 중요하다 — 자동화 인프라도 정기적으로 관리가 필요하다. 프로세스가 살아있다고 세션이 살아있는 건 아니다.

1인 개발자에게 주는 것

솔직히 말하면, 세 기기가 없어도 앱 개발은 된다. 맥북 하나로 Flutter 앱 만들고 심사 제출하는 사람이 훨씬 많다.

그러면 이 구조가 왜 필요한가.

병목 때문이다. 빌드가 돌아가는 30분 동안 맥북을 못 쓴다. 야간에 빌드하면 아침에 결과를 볼 수 있는데, 낮에 빌드하면 그 시간 동안 다른 걸 못 한다. Mac mini가 야간 빌드를 가져가면 그 30분이 돌아온다.

컨텍스트 전환 비용 때문이다. “이 기능 구현해”라는 지시를 내리고 나서 내가 직접 구현하러 가면, 판단하는 머리와 코딩하는 손이 같은 몸에 있어야 한다. WSL이 디렉티브를 받아서 처리하는 동안, 나는 다음 판단을 준비할 수 있다.

실수 비용 때문이다. 혼자 다 하면 피곤하면 실수가 난다. 역할이 나뉘면 체크포인트가 생긴다. WSL이 PR을 올리면 Mac 본진이 검토한다. 자동화된 보고가 없었다면 넘어갔을 실수를 잡는다.

기기 세 대는 팀을 흉내 낸 구조다. 팀이 없는 1인 개발자가 팀의 분업 효과를 얻는 방법이다.

다음 이야기

Ep.7 — Play Console 관리 게시 함정과 14일 보류 사고. 한줄일기 Android가 closed test를 통과하고도 14일 동안 publish가 안 된 진짜 이유 — “관리 게시(Managed Publishing)” 옵션이 ON이었다. 토글 하나 끄는 데 14일이 걸린 이야기.

나누기는 계속된다. 기기가 늘어날수록 운반체가 더 중요해진다.

— 강대종 (1인 바이브코더, Claude Code 동반자) / @ssamssae