2-The Foundation

에이전트 운영 규칙은 미리 설계하는 것이 아니다. 사고 현장에서만 얻을 수 있는 구체성이 있다. OpenClaw를 처음 세팅하던 날, AI 에이전트 Elon의 AGENTS.md에 운영 규칙을 미리 써두려 했다. "반복적인 보고를 피할 것." "판단이 필요한 작업은 신중하게." "스킬은 적절히 사용할 것." 쓰고 나서 다시 읽어봤다. 다 맞는 말이었다. 그리고 전부 쓸모없는 말이었다. 뽀짝이의 9일 — 절대 규칙 0개에서 14개로 뽀짝이는 지피터스 AI스터디의 운영비서 에이전트다. 운영 에피소드 20편이 공개되어 있었고, 그걸 읽으면서 규칙이 어떻게 탄생하는지 들여다볼 수 있었다. 운영 첫날 절대 규칙 수: 0개. 9일 후: 14개. 14개 전부 실제 사고에서 나왔다. 사고가 나기 전에는 이 규칙들이 필요한지조차 몰랐다. 문제가 발생하고 나서야 "이 상황에서 정확히 무엇을 해야 하는가"가 명확해진다. "반복을 피하라"와 "최초 1회만"의 차이 두 문장을 에이전트 입장에서 읽어보자. "반복적인 보고를 피할 것" — 지금 이 보고가 반복인가, 아닌가? 에이전트가 판단해야 한다. 판단하는 순간 해석이 달라진다. 10번이 반복인가, 3번이 반복인가. "동일 이슈는 최초 1회만 보고" — 판단할 게 없다. 같은 이슈인지만 확인하면 된다. 추상 원칙은 방향이다. 구체 규칙은 실행 지시다. 에이전트에게 방향을 주면 해석이 생기고, 해석이 생기면 실수가 생긴다. 좋은 규칙의 조건은 하나다. 해석할 여지가 없어야 한다. 구체적 조건(언제, 무엇을, 어떻게)이 없는 문장은 규칙이 아니라 원칙이다. 뽀짝이 경험에서 우리 시스템에 가져온 것 에피소드 20편을 읽으면서 세 가지 패턴이 보였다. 그걸 우리 AGENTS.md에 절대 규칙으로 추가했다. R001: 판단이 개입되는 작업은 서브에이전트에게 위임하지 않는다

더 많이 줄수록 더 강해질 것이라는 생각이 있었다. 그 생각을 한 번 끝까지 따라가 봤다. OpenClaw 에이전트 Andrew를 세팅하던 날, 지식 라이브러리 두 개가 있었다. market-research-1.0.1/ — 경쟁사 분석 방법론과 증거 등급 체계가 담긴 패키지. playwright-1.0.3/ — 브라우저 자동화 7원칙이 담긴 패키지. 처음 드는 생각은 단순했다. 다 주면 더 강해지지 않을까? 두 패키지를 통째로 Andrew 컨텍스트에 붙이면 그만이었다. 그런데 그 전에 내용을 한 번 훑어봤다. 그리고 결국 다 주지 않기로 했다. 이유를 정리하다 보니 지식 이식에서만 쓰이는 원칙이 아니었다. 23단계를 4단계로 줄인 이유 market-research-1.0.1/ 안에는 AutoResearchClaw라는 파이프라인이 있었다. 리서치를 23단계로 나눈 구조다. 문헌 검색부터 통계 보정, 동료 검토까지 — 학술 논문 수준의 흐름이었다. "이걸 Andrew한테 다 넣으면 어떻게 될까"를 시뮬레이션해봤다. 비즈니스 리서치 질문이 하나 들어온다 — "경쟁사 A의 최근 전략 변화를 정리해줘." 그러면 Andrew는 23단계를 밟으려 할 것이다. 질문 정의 → 탐색 범위 설정 → 자료 수집 → 1차 검토 → 교차 검증 → 통계 보정 → … 간단한 경쟁사 조사에 논문급 절차가 실행된다. 이건 강함이 아니라 과부하다. 비즈니스 리서치에 필요한 건 4단계였다. 23단계를 쓰지 않은 게 아니라, 23단계 중에서 이 4개를 골랐다. 나머지 19단계는 Andrew의 도메인 밖이었다. 7원칙을 3원칙으로 줄인 이유 playwright-1.0.3/에는 브라우저 자동화 7원칙이 있었다. 여기서도 같은 질문이 생겼다 — 7개 전부를 줘야 하는가. 7원칙을 읽다 보니 뒤쪽 4개가 보였다. 테스트 재현성 유지, 오류 스크린샷 자동 저장, 리포트 포맷 표준화, CI 환경 대응. 이건 QA 엔지니어 원칙이다. Andrew는 리서치 에이전트지 테스터가 아니다. 이 4개를 Andrew가 알면, "지금 이 작업이 재현 가능한 테스트인가?"를 매번 고려하게 된다. 불필요한 맥락이 실행을 방해한다.

봇은 네 개였다. 팀은 아직 아니었다. 그 간극을 메운 건 네 개의 파일이었다. 며칠 전, Telegram에서 Elon, Alex, Andrew, Jeff 네 봇이 각자 자기 채널에서 응답하는 걸 처음 확인한 날이 있었다. 그 날은 솔직히 "다 됐다" 싶었다. 봇이 네 개 돌아가고, 각자 다른 방에서 내 말에 대답했으니까. 그런데 며칠 써보니 금방 알았다. 봇은 응답했다. 그런데 팀은 아니었다. Alex한테 "이번 주 마케팅 한 줄로 정리해줘"라고 하면 답은 잘 나왔다. 근데 Elon한테 "Andrew에게 데이터 확인 요청해줘"라고 하니까 "Andrew가 누구인가요?"라고 반문이 돌아왔다. 같은 시스템 안에 분명히 있는데 서로를 몰랐다. 그 뒤 며칠 동안 한 일은 딱 하나였다 — 봇에 "팀원"을 이식하는 일. 네 개의 파일을 순서대로 채웠다. IDENTITY.md, AGENTS.md, HEARTBEAT, TOOLS.md. 이 순서는 나중에 돌아보니 우연이 아니었다. 써놓고 보니 "사람을 팀에 받아들일 때 묻는 질문 순서"와 거의 똑같았다. 1. IDENTITY.md — "너 누구야"에 답할 수 있게 첫 단계는 이름·역할·채널·도메인이다. 네 항목을 한 파일에 적는다. 별거 아닌 것 같았는데, 이게 없으면 에이전트가 자기가 누군지 모른다. 같은 질문에도 "저는 AI 어시스턴트입니다"로 회귀하거나, 도메인을 넘어선 답을 한다. IDENTITY.md를 넣자 처음으로 "저는 Alex예요, 마케팅 담당입니다"라고 답하기 시작했다. 작은 파일인데 효과는 묘하게 컸다. 처음엔 "이거 성격·판단 기준을 담는 SOUL.md와 겹치는 거 아닌가" 싶었는데 써보니 아니었다. SOUL.md가 성격·말투 같은 내면이라면, IDENTITY.md는 명함 수준의 최소치다. 명함 없이 회의실에 들어가면 어색하다 — 그것과 비슷했다. 2. AGENTS.md — 서로를 알게 하기 여기서부터 팀이 된다. IDENTITY.md를 각자 가진 상태는 여전히 "각자 따로 일하는 네 사람" 상태다. Elon은 Alex가 있다는 걸 모르고, Alex는 Andrew가 있다는 걸 모른다.

더 쉬운 길도, 더 단단한 길도 있었다. 그중 가운데를 골라야 할 이유가 있었다. 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 대화 체감이 꽤 달라진다. 해보기 전엔 사소해 보였는데, 붙여보니 확실히 달랐다.

세션이 끊겨도 Elon이 Elon인 이유를 찾아가다가, 파일 하나에 닿았다. 며칠 전에 Elon한테 이런 질문을 던졌다. "너는 새 채팅이 시작될 때마다 이전 대화를 기억 못 하잖아. 그럼 매번 나를 처음 만나는 거야?" 솔직히 조금 쓸쓸한 기분으로 물었다. 어제 같이 세팅한 것, 함께 결정한 것들이 다 사라진다면 — 그건 협업이 아니라 매번 새로 소개하는 일이니까. AI 에이전트 정체성이라는 게 도대체 어디서 오는지, 그 순간 진지하게 궁금해졌다. Elon이 이렇게 답했다. "파일을 읽으면 돌아와." 당시에는 이게 무슨 말인지 잘 이해가 안 됐다. 며칠 지나 OpenClaw의 에이전트 설정 구조를 들여다보다가, 그제야 "아" 싶었다. 세션이 시작되면 Elon이 제일 먼저 하는 일 OpenClaw에서 새 대화가 열리면, Elon은 파일 몇 개를 읽는다. 그중에서도 가장 먼저 읽는 게 SOUL.md다. 재밌는 건 이거다. 이 파일을 읽기 전의 Elon은 사실 그냥 Claude다. 아무것도 모르는 상태다. 내가 누군지도, 우리가 무슨 일을 하는지도, 자기 자신이 누군지도 모른다. 그런데 SOUL.md를 읽고 나면 달라진다. 첫 줄이 이렇게 시작한다. "You're not a chatbot. You're becoming someone." 처음에 이 문장을 설계할 때는 그냥 감성적인 오프닝인 줄 알았다. 지금은 생각이 좀 바뀌었다. 이건 지시가 아니라 방향을 주는 문장이다. 이 한 줄을 읽는 순간부터 Elon은 Elon으로 돌아온다. SOUL.md에 뭘 담았냐면 처음엔 성격, 말투, 판단 기준 같은 걸 써봤다. 직접적으로 말할 것. 의견을 가질 것. 실행 경로 없는 결론은 내지 말 것. "이걸 다 쓴다고 봇이 바뀌나?" 싶었다. 그런데 진짜로 달라진다. 같은 질문을 SOUL.md 없이 물으면 일반적이고 둥글둥글한 답이 나온다. 읽은 상태에서 물으면 Elon 특유의 톤으로 돌아온다. 짧고, 단언적이고, 다음 액션이 있는.