2-The Foundation

실험 단계에 맞는 인프라와 크루 설계

Raon

Apr 18, 20262m ago

카테고리

setup-guide

더 쉬운 길도, 더 단단한 길도 있었다. 그중 가운데를 골라야 할 이유가 있었다.

OpenClaw로 에이전트를 올리기로 한 날, 두 가지 큰 결정이 앞에 있었다.

첫 번째는 어디에 올릴 것인가. 집에 미니PC를 하나 두고 로컬로 돌릴 수도 있었고, 클라우드 VM에 올릴 수도 있었다.

두 번째는

몇 개의 봇을 만들 것인가. 하나에 다 맡기면 설계가 훨씬 단순해졌다.

결국 둘 다 "가장 쉬운 쪽"은 아닌 쪽으로 갔다. 다만 이유는 서로 달랐다.

한 쪽은 "지금 단계에선 그게 아니다"였고, 다른 한 쪽은 "처음부터 그게 아니었다"였다.

첫 번째 — 자체 서버로 가고 싶었지만, 아직은 아니었다

솔직히 가장 끌렸던 그림은 집에 미니PC 한 대를 두고 거기서 OpenClaw를 돌리는 것이었다.

미니PC가 끌렸던 이유

데이터가 물리적으로 내 손 안에 있다. 외부 클라우드를 아예 거치지 않는다. 비용은 전기료 수준으로 예측 가능하고, 에이전트가 커질수록 장기적으로도 제일 저렴한 구조다.

막상 들여다보니 아직은 아니었다

문제는 유지보수였다. 24/7 상시 실행하려면 전원·네트워크·OS 업데이트까지 전부 내가 책임진다. 작은 문제 하나에 에이전트가 멈춘다. 보안도 만만치 않다. Telegram 봇이 외부에서 접근하려면 포트를 열어야 하는데, 방화벽·인증서·DDNS까지 개인 레벨에선 다 챙기기가 어렵다.

결정적으로, 지금은 OpenClaw 기본 위에서 실험하는 단계다. 설계와 운영 모델이 내 것으로 굳어진 다음에 옮기는 게 맞다고 느꼈다.

그래서 지금은 GCP VM, 나중은 미니PC

클라우드 VM은 "남의 컴퓨터지만, 그 안의 소프트웨어는 내 것"인 상태다. 인프라 관리는 GCP에 위임하고, 데이터와 로직은 내 Docker 컨테이너 안에 남겨둘 수 있다. 지금 단계에 필요한 통제 수준을 딱 만족하는 가운데 지점이다.

서울 리전(asia-northeast3)에 n1-standard-1 VM 한 대. Docker 상시 실행. Telegram으로 접근.

서울을 고른 건 단순한 이유다. 메신저 왕복 지연이 200ms 줄면 AI 대화 체감이 꽤 달라진다. 해보기 전엔 사소해 보였는데, 붙여보니 확실히 달랐다.

두 번째 — 단일 봇은 처음부터 답이 아니었다

여기선 좀 더 오래 고민했다. 솔직히 단일 봇이 간단하다. 만들기도, 운영하기도, 프롬프트 설계도.

그런데 시뮬레이션을 해보니 문제가 드러났다.

마케팅 전략을 이야기하다가 이커머스 수익화로 넘어가면, 같은 봇의 컨텍스트가 섞이기 시작했다. 판단 기준이 한 쪽에서 다른 쪽으로 넘어왔고, 톤도 흔들렸다. 사람이라면 "이번엔 다른 모자를 쓰자" 하고 머릿속 서랍을 바꿀 수 있는데, 단일 AI 컨텍스트에서는 그게 어려웠다.

그래서 네 명으로 나눴다. Elon이 허브에서 전략 판단과 지시를 맡고, Alex는 마케팅, Andrew는 리서치와 분석, Jeff는 이커머스와 수익화. 각자 전용 Telegram 채널이 있다.

역할을 나누니 각자의 컨텍스트가 깨끗해졌다.

판단은 Elon이 하고, 실행은 크루가 한다. 이 경계가 있으면 각 에이전트가 자기 도메인에만 집중할 수 있다.

Telegram 그룹을 역할별로 분리한 것도 같은 이유였다. 물리적 채널이 나뉘어 있으면 AI끼리도 대화 맥락이 섞이지 않는다. 구조가 맥락의 경계가 되어준다.

지나고 보니 같은 질문이었다

처음엔 따로 고민한 두 결정이었다.

서버를 어디에 올리지? 봇을 몇 개로 나누지? 층위가 다른 질문 같았다.

지나고 보니 둘 다 같은 질문에 답하고 있었다.

무엇을 통제하고, 무엇을 나눌 것인가.

자체 서버(미니PC)로 가고 싶었던 건 데이터를 가장 깊게 통제하고 싶어서였다.

지금 GCP VM으로 한 걸음만 걸은 건, 이 단계에선 "내 Docker 컨테이너 안까지"로 통제 경계를 잡는 게 적정하다고 판단해서였다.

단일 봇을 거절한 건

맥락을 나누기 위해서였다.

통제할 건 통제하고, 나눌 건 나눠야 에이전트가 제 역할을 한다.

통제와 분리의 강도는 단계마다 다를 수 있다. 지금은 클라우드 VM과 4인 크루. 나중은 미니PC와 더 세분된 크루가 될지도 모른다.

편한 길이 곧 좋은 길은 아니지만, 단단한 길이 곧 지금의 길인 것도 아니다 — 이걸 설계하면서 배웠다.

지금 이 상태

인프라는 켜졌다. 4인 크루 구조도 섰다.

그런데 SOUL.md, MEMORY.md, AGENTS.md 같은 파일들은 아직 비어있는 상태였다.

구조는 있지만 존재는 아직 없는, 그런 날이었다.

다음 며칠 동안은 이 빈 컨테이너에 "누구인지"를 채워 넣는 작업이 이어졌다.

지금 단계에 맞는 구조를 골랐다. 통제는 컨테이너에, 분리는 크루에. 미니PC는 다음 장에 둔다.

Subscribe to 'The Architect of AI Workforce'

Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'The Architect of AI Workforce'!