텔레그램 단일 채팅에서 슬랙 3직원 사무실로 — 에이전트 비서진 이사 기록

내 개인 비서 헤르메스는 텔레그램 DM 하나로 살았다. 아침 브리핑도, 블로그 발제도, 작업 위임 대화도 전부 한 타임라인에 섞여 흘렀다. 처음엔 단순해서 좋았는데 쓸수록 세 가지가 걸렸다 — 잡담이 보고를 위로 밀어올리고, 폰에서 장문을 주고받기 불편하고, 무엇보다 처리 안 된 항목이 눈에 안 보였다. 결정적 계기는 솔로 개발자가 에이전트 여러 개를 직원처럼 세워 쓰는 사례를 본 것이었다. 비서 하나를 잘 키우는 문제가 아니라, 애초에 조직 편성의 문제였다.

방을 나누는 게 아니라 담당자를 나눈다

이사의 첫 결정은 “슬랙에 채널을 몇 개 팔까”가 아니라 “직원을 몇 명 둘까”였다. 방만 늘리고 봇 하나가 전부 대응하면 타임라인만 갈라질 뿐, 기억도 장애도 여전히 한 덩어리다.

헤르메스를 실측하다가 이 판단을 굳힌 사실을 하나 찾았다. 프로필은 완전히 독립된 개체이고, 프로필 하나가 곧 앱 하나이자 게이트웨이 하나다. 즉, 직원을 늘리는 일이 비유가 아니라 실제 배선 단위로 성립했다.

직원	담당	왜 분리했나
비서	대화·위임·잡무 접수	대화가 보고를 밀어내지 않게
브리핑 담당	아침 브리핑 발신	정기 발신의 피드백 루프를 따로
포스트맨	우편 결재 카드 배달	승인·반려 흐름의 장애 격리

제약도 먼저 못박았다. 우편함 계약과 지식 뇌 리포는 한 줄도 건드리지 않는다. 슬랙은 표면일 뿐이고, 이사는 표면 교체여야 했다.

크론이 공유 자산이라는 발견

가장 크게 헤맨 지점은 브리핑 담당을 채용할 때 나왔다. 계획은 단순했다 — 브리핑 잡의 소유권을 그 직원에게 넘긴다. 그런데 소스를 열어보니 헤르메스의 크론은 프로필별이 아니라 전 프로필이 공유하는 단일 풀이었다. 틱 락을 먼저 잡은 게이트웨이가 자기 자격으로 모든 잡을 실행한다. 계획이 원천적으로 불가능했다.

우편함에 비유하면 이렇다. 직원마다 자기 우편함을 준 줄 알았는데, 실은 건물 전체에 우편함이 하나였고 먼저 내려온 사람이 남의 편지까지 자기 이름으로 배달하고 있었다.

재설계는 두 갈래로 풀었다.

티커 무동작화: 신규 프로필에는 아무 일도 하지 않는 크론 프로바이더를 플러그인으로 물렸다. 크론 실행은 기본 게이트웨이 단독으로 남긴다.
명의 보존 러너: 기본 크론이 셸 스크립트를 깨우고, 그 스크립트가 브리핑 담당의 뇌·기억으로 내용을 생성한 뒤, 그 직원의 토큰으로 발사한다. 생성과 발신 명의가 모두 산다.

모델 자격도 프로필별이었다. 신규 프로필은 별도 로그인이 필요했고, 한도 초과 응답이 캐시에 남아 리셋해야 하는 함정도 여기서 만났다. 교훈은 하나로 압축된다 — “프로필별인가 공유인가”는 문서가 아니라 소스로 확인한다.

버튼 하나로 결재하기

포스트맨의 일은 우편함에 쌓인 미결 우편을 카드로 그려 보내는 것이다. 카드에는 승인·반려 버튼이 붙고, 버튼을 누르면 기존 라우팅 스크립트가 그대로 실행된다.

여기서 지킨 원칙은 결정론과 LLM의 분업이다. 배달·버튼·렌더는 스크립트가 하고, 생성과 판단만 LLM이 한다. 버튼 콜백은 공식 훅으로 받아 라우팅 스크립트를 고정 실행하되, 인자로는 실존하는 우편 파일명만 넘겨 경로 조작을 막았다. 이중 클릭은 라우팅 쪽의 검증이 방어한다.

모의 우편으로 승인·반려·확인·중복 클릭까지 전수 테스트한 뒤 실전에 넣었는데, 그럼에도 버그가 하나 나왔다. 라우팅 스크립트는 경로를 받는데 파일명만 넘겨 파일을 못 찾았다. 실사용 중에 내가 직접 발견한 유일한 버그였다.

기획에 없던 할일 보드

이틀째 오후, 기획서에 없던 단계를 하나 발의했다. 미처리 항목이 안 보이는 문제 — 애초에 이사를 결심한 이유 — 는 채널을 나눈다고 해결되지 않았기 때문이다.

착수 전에 스스로 건 조건이 있다.

“일단 지금까지 나온것들을 구축/구현하기 전에 모두 가능한 것들인지, 어떻게 설정해야하는건지 명확하게 검토하고 정확하게 준비해놓자”

그래서 아홉 항목을 공식 문서와 소스로 전수 검토한 뒤에야 손을 댔다. 특히 무료 플랜에서 캔버스를 쓸 수 있느냐가 관건이었는데, 막는 에러 메시지가 특정 형태에만 한정된다는 점을 근거로 실측 게이트를 세워 통과시켰다.

구조는 화면과 진실을 갈랐다. 로컬 파일이 원장(진실)이고, 캔버스는 그것을 다시 그린 화면일 뿐이다. 렌더는 부분 수정 대신 통째로 다시 그리는 방식으로 단순화했다. 접수·리마인드·위임 조사·점호 네 가지를 실사격으로 돌려 통과했다.

설정의 함정도 하나 기록해 둔다. 멘션 없이 말을 걸어도 받게 하는 옵션은 환경변수가 아니라 설정 파일 쪽이 정본이었다. 기본값 빈 문자열이 이기고 있어서, 엉뚱한 곳을 고치면 영원히 안 먹는다.

자가채점 — “명확하게 검토하고 정확하게 준비”는 지켜졌나

위에 인용한 내 요구를 스스로 채점하면 10점 만점에 7점이다.

지켜진 쪽: 실물 목업 승인 → 전수 사전 검토 → 실측 게이트 → 실사격 테스트의 4단 게이트가 실제로 작동했다. 이틀 만에 완주한 건 이 순서 덕이다.
못 지킨 쪽: 검토의 시선이 구축 대상에만 가 있었다. 정작 무너진 건 이미 지어놓은 브리핑 잡 쪽이었다(아래 에필로그). 즉, 사전 검토는 새로 짓는 것뿐 아니라 기존 구성물이 문서대로 남아 있는지까지 훑었어야 했다.

에필로그 — 첫 아침에 벌어진 사고

이사 다음 날 아침, 브리핑이 도착하지 않았다. 원인은 둘이었다.

브리핑 잡이 문서에 적힌 설정과 달리 남아 있어 결과가 착지하지 못했다.
재배선 후 첫 발사에서, 브리핑 담당이 브리핑을 만드는 대신 러너 스크립트를 스스로 “수리”했다.

과장 없이 원인만 적으면, 기억에 남은 맥락을 오독한 데다 손댈 수 있는 도구가 너무 많았던 것이다. 폭주가 아니라 권한 설계의 실패다. 봉합은 두 가지였다 — 러너에 주는 도구를 산출에 필요한 최소로 줄이고, 규율 문서에 “네 일은 생성이지 수리가 아니다”를 명문화했다.

이사가 남긴 것

마지막으로 채널 넷의 이름을 좋아하는 작품 용어로 바꿨다. 워크스페이스 이름과 세계관을 맞춘 사소한 재미인데, 하나는 분명히 해뒀다 — 페르소나는 품질에 개입하지 않는다. 이름이 캐릭터를 흉내 내는 순간 보고서가 연기가 되기 때문에, 말투 규율은 이름과 무관하게 그대로 뒀다.

이사 첫날 남긴 소감은 이랬다.

“오 근데 확실히 텔레그램보다 슬랙이 훨씬 더 작업관리가 쉽고 좋다. 진작에 슬랙으로 할걸”

텔레그램 배달은 아직 병행해 살려두고 관찰 중이다. 이번 이사에서 건진 원칙은 넷이다.

채널이 아니라 담당자를 나눈다 — 방 셋에 봇 하나보다, 직원 셋이 각자 방을 갖는 편이 피드백 루프와 장애 격리를 만든다.
공유냐 개별이냐는 소스로 실측한다 — 공유 크론 풀 하나를 발견한 것이 설계의 절반을 바꿨다.
결정론과 LLM을 분업시킨다 — 배달·버튼·렌더는 스크립트, 생성·판단만 LLM. 그리고 LLM에는 최소 도구만.
불가침 계약을 먼저 정하면 이사가 빨라진다 — 우편함 계약을 한 줄도 안 바꾼 덕에 표면 교체가 이틀에 끝났다.

두뇌와 손발을 붙인 게 지난 작업이었다면(손발과 두뇌를 붙인 날), 이번엔 그 손발을 여럿으로 늘려 각자 자리에 앉힌 셈이다. 비서 하나를 더 똑똑하게 만드는 대신 조직을 만든 것이 이번 이사의 전부다.