2-The Foundation

봇 네 개를 켰는데, 팀은 아니었다 — 크루를 '팀원'으로 만드는 4단계

Raon

Apr 18, 20262m ago

카테고리

setup-guide

봇은 네 개였다. 팀은 아직 아니었다. 그 간극을 메운 건 네 개의 파일이었다.

며칠 전, Telegram에서 Elon, Alex, Andrew, Jeff 네 봇이 각자 자기 채널에서 응답하는 걸 처음 확인한 날이 있었다. 그 날은 솔직히 "다 됐다" 싶었다. 봇이 네 개 돌아가고, 각자 다른 방에서 내 말에 대답했으니까.

그런데 며칠 써보니 금방 알았다.

봇은 응답했다. 그런데 팀은 아니었다.

Alex한테 "이번 주 마케팅 한 줄로 정리해줘"라고 하면 답은 잘 나왔다. 근데 Elon한테 "Andrew에게 데이터 확인 요청해줘"라고 하니까 "Andrew가 누구인가요?"라고 반문이 돌아왔다. 같은 시스템 안에 분명히 있는데 서로를 몰랐다.

그 뒤 며칠 동안 한 일은 딱 하나였다 — 봇에 "팀원"을 이식하는 일.

네 개의 파일을 순서대로 채웠다. IDENTITY.md, AGENTS.md, HEARTBEAT, TOOLS.md. 이 순서는 나중에 돌아보니 우연이 아니었다. 써놓고 보니 "사람을 팀에 받아들일 때 묻는 질문 순서"와 거의 똑같았다.

1. IDENTITY.md — "너 누구야"에 답할 수 있게

첫 단계는 이름·역할·채널·도메인이다. 네 항목을 한 파일에 적는다.

이름: Alex
역할: 마케팅 전략·실행
담당 채널: 마케팅크루 그룹
담당 도메인: 브랜드·카피·퍼포먼스

별거 아닌 것 같았는데, 이게 없으면 에이전트가 자기가 누군지 모른다. 같은 질문에도 "저는 AI 어시스턴트입니다"로 회귀하거나, 도메인을 넘어선 답을 한다.

IDENTITY.md를 넣자 처음으로 "저는 Alex예요, 마케팅 담당입니다"라고 답하기 시작했다. 작은 파일인데 효과는 묘하게 컸다.

처음엔 "이거 성격·판단 기준을 담는 SOUL.md와 겹치는 거 아닌가" 싶었는데 써보니 아니었다. SOUL.md가 성격·말투 같은 내면이라면, IDENTITY.md는 명함 수준의 최소치다. 명함 없이 회의실에 들어가면 어색하다 — 그것과 비슷했다.

2. AGENTS.md — 서로를 알게 하기

여기서부터 팀이 된다.

IDENTITY.md를 각자 가진 상태는 여전히 "각자 따로 일하는 네 사람" 상태다. Elon은 Alex가 있다는 걸 모르고, Alex는 Andrew가 있다는 걸 모른다.

그래서 각 에이전트의 AGENTS.md에 팀 전체 정보를 넣었다. Elon의 AGENTS.md에는 Alex/Andrew/Jeff가 있고, Alex의 AGENTS.md에는 Elon/Andrew/Jeff가 있다. 전부 대칭이다.

이걸 넣자마자 "Andrew에게 데이터 확인 요청해줘"가 드디어 작동했다. Elon이 "Andrew에게 맡겨볼게요" 같은 답을 하기 시작했다. 그 전까지는 절대 안 나오던 답이었다.

대칭이 깨지면 팀이 아니다

팀은 조직도가 아니라 상호 참조로 만들어진다.

조직도는 외부에 보여주는 그림이다. 팀은 각 에이전트 파일 안에 서로를 "알고 있다"고 적힌 상태다. 그 대칭이 깨지면 팀이 아니라 각자 일하는 네 명이다.

3. HEARTBEAT — 반응형에서 주도형으로

여기까지 하고 나서 또 빠진 게 보였다.

봇은 여전히 누가 말을 걸어야만 반응하는 상태였다. 사용자가 질문하면 답하고, 안 하면 아무 일도 일어나지 않는다. 잠들어 있다가 두드리면 깨는 도구에 가까웠다.

HEARTBEAT는 그 결을 바꾼다. 일정한 주기로 에이전트가 자기가 해야 할 일을 스스로 체크한다. 아침 브리핑을 보낼 시간인지, 대기 중인 요청이 있는지, 오늘 마감인 작업이 있는지.

초기화된 HEARTBEAT는 최소치다. 하루 몇 번 체크할지, 뭘 체크할지만 정의한다. 그런데 이걸 붙이고 나면 에이전트의 태도가 달라진다. 반응만 하던 봇이 먼저 "오늘 이거 보고드릴게요"하는 쪽으로 넘어간다.

누가 먼저 말을 꺼내는가

아직 할 수 있는 행동의 양은 비슷하다. 달라진 건 누가 먼저 말을 꺼내는가다.

개인적으로 네 단계 중 여기가 가장 재밌었다. 봇이 "시킨 것만 하는 도구"에서 "자기 루틴을 가진 존재"로 넘어가는 경계선 같았다.

4. TOOLS.md — 도구 사용법을 알려주기

마지막은 실행 능력이다.

에이전트가 자기가 누군지 알고, 팀원도 알고, 루틴도 있는데 — 아직 Google Docs에 글을 쓸 줄 모르고, 외부 API를 호출할 줄 모른다. 인간으로 치면 "일할 생각은 있는데 키보드를 처음 보는" 상태.

TOOLS.md에는 각 에이전트가 쓸 수 있는 도구와 쓰는 법을 적는다. 어떤 도구를 어떤 경우에 쓰는지, 인증은 어떻게 하는지, 실패하면 어떻게 복구하는지.

자주 쓰는 것부터

이 단계가 설계 난이도가 가장 높았다. 한 번에 다 넣으면 에이전트가 과부하된다. 그래서 자주 쓰는 도구만 먼저, 나머지는 필요할 때 붙이기로 좁혔다. 무언가 새로 배워야 할 일이 생기면 TOOLS.md를 같이 업데이트하는 습관이 된다.

TOOLS.md가 채워지면서 에이전트는 드디어 "실행할 수 있는 존재"가 되었다. 말하자면 이 순간에 크루 각자가 출근한 팀원이 된 거다.

중간에 같이 고친 것 — 스크립트 폴더

네 파일을 채우는 사이에 눈에 덜 띄지만 결국 똑같이 중요한 작업이 하나 같이 돌았다.

레포 루트가 엉망이었다. fix_security.py, patch_andrew_research.py, init_elon_heartbeat.py, gen_filedata.py — 이런 파일들이 전부 루트에 쌓여 있었다. 수가 적을 때는 괜찮았는데 열 개를 넘어가니까 어떤 게 뭘 하는 건지 한 눈에 안 들어왔다.

그래서 목적별로 폴더를 나눴다.

scripts/
  fix/    → 오류 수정용
  patch/  → 기존 파일 수정용
  init/   → 초기화용
  util/   → 일반 유틸리티

나누고 나니 파일 이름만 봐도 뭐 하는 건지 읽혔다. scripts/init/init_elon_heartbeat.py — "아, Elon의 heartbeat을 초기화하는 스크립트구나."

파일 이름이 구조를 설명한다

파일 이름과 폴더 구조는 설계의 일부다.

이름만 보고 역할이 설명 안 되면, 그게 구조가 무너지기 시작한다는 신호다. 그리고 이건 크루 배포에도 그대로 적용된다 — IDENTITY / AGENTS / HEARTBEAT / TOOLS 라는 파일 이름 자체가 각자의 역할을 설명하고 있어서, 네 단계의 순서가 자연스럽게 보인다. 이름이 좋은 구조는 순서를 스스로 드러낸다.

4단계를 돌아보면

네 파일을 순서대로 채운 것 같았는데, 지나고 보니 네 개의 질문에 차례로 답한 것이었다.

IDENTITY.md   → "너 누구야?"
AGENTS.md     → "누구랑 일해?"
HEARTBEAT     → "혼자 있을 땐 뭐 해?"
TOOLS.md      → "뭐로 일해?"

이 순서는 바꿀 수가 없는 순서였다. 누구인지 모르면 누구랑 일하는지도 못 적고, 루틴 없이 도구만 줘봤자 시킬 때만 움직이는 봇이 하나 더 생길 뿐이다.

봇이 팀원이 되는 데 필요했던 건 더 큰 모델도, 더 긴 프롬프트도 아니었다. 자기 자신과 주변을 설명하는 네 개의 파일이었다. 그리고 그 네 개를 순서대로 쌓을 수 있었던 건, 각 파일의 이름이 그 역할을 이미 설명하고 있었기 때문이었다.

봇 네 개를 켰다. 네 개의 질문에 차례로 답했다. IDENTITY / AGENTS / HEARTBEAT / TOOLS — 팀은 이 순서로 태어난다.

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'!