AI 에이전트 프로필마다 Slack 봇을 만들려다, 간단하게 끝냈습니다

만들어둔 스킬을 정작 못 쓰고 있었습니다. 글감 수집, 키워드 분석, 안내문서 작성을 AI 에이전트 스킬로 만들어뒀는데 UI 가 없어서 터미널을 열어야만 부를 수 있었습니다. 그래서 Slack 을 입구로 삼기로 했습니다. 채팅창에 한 줄 쓰면 에이전트가 받아서 일하는 구조입니다.

동기가 하나 더 있었습니다. 지금은 혼자 하지만 사람이 들어온 뒤에 접근 경계를 긋는 일은 그때 가서 비싸집니다. 그리고 판단하다 만 것과 접었던 시도는 프로젝트 관리 도구에 남지 않습니다. 거기엔 굳은 결과만 들어갑니다.

프로필이 셋이니 봇도 셋이라고 생각했습니다

제가 쓰는 에이전트 도구는 프로필이라는 단위로 작업 환경을 나눕니다. 프로필마다 지시문, 스킬, 메모리, 대화 세션, 도구 연결, 인증이 따로 붙습니다. 사실상 서로 다른 역할의 에이전트입니다. 저는 셋을 뒀습니다. 전사 작업대 역할의 기본 프로필, 프랜차이즈 ERP, 웨딩홀 운영관리입니다.

이걸 Slack 에 붙이려니 자연스러운 결론은 1:1 이었습니다. 앱 하나가 보통 봇 하나와 멘션 이름 하나를 가지니, 멘션 이름만 보고 어느 역할을 부르는지 알 수 있어 깔끔해 보였습니다. 두 시스템이 나누는 축이 애초에 다르다는 것을 그때는 보지 않았습니다.

에이전트  프로필  =  독립된 작업 환경과 역할   → "무엇을 아는가"
채팅 도구  앱/봇   =  외부에서 연결된 한 주체   → "누가 접근할 수 있는가"

봇 하나에 여덟 단계가 딸려옵니다

봇을 하나 늘릴 때 무엇이 따라오는지 세어봤습니다.

앱 생성 → 워크스페이스 설치 → 권한 승인 → 봇 토큰 발급
       → 앱 토큰 발급 → 프로필 설정에 연결 → 게이트웨이 실행 → 채널 초대

여덟 단계이고, 프로필 하나당 반복됩니다. 늘어나는 것이 절차만도 아닙니다. 토큰이 셋, 상시 떠 있는 프로세스가 셋이 됩니다. 지금 굴리는 프로젝트가 아홉 개라, 프로젝트마다 프로필을 두면 이 여덟 단계가 아홉 번 반복됩니다.

첫 설계에는 「핵심 개발 과제」로 잡아둔 항목도 있었습니다. 메시지에서 역할을 파싱해 알맞은 프로필로 넘기는 역할 라우터입니다. 이건 결국 만들지 않았습니다.

세 가지 옵션을 놓고 봤습니다

두 번째 안의 단점이 이 맥락에서는 단점이 아니었습니다. 프로젝트마다 Slack 채널이 이미 따로 있었고, 채널이 갈려 있다는 것 자체가 접근 권한이 이미 갈려 있다는 뜻입니다.

실제로 필요했던 것은 설정 몇 줄이었습니다

앱 1개 (봇 토큰 1개)
      ↓
멀티플렉싱 게이트웨이 (기본 프로필이 소유)
      ↓
채널 ID → 프로필 매핑
      ↓
DM·기본 채널 → 기본   ·   ERP 채널 → ERP   ·   웨딩 채널 → 웨딩

게이트웨이 하나가 봇 토큰 하나로 붙고, 들어온 메시지의 채널 ID 를 보고 프로필을 고릅니다. 채널로 가르니 메시지 본문에서 역할을 파싱할 일이 없어졌습니다. 「핵심 개발 과제」가 사라진 이유가 이것입니다. 문제를 다르게 자르자 만들 것이 없어졌습니다.

이 기능을 처음엔 없다고 판단했습니다

채널 라우팅 설정은 공식 채팅 연동 문서에 없습니다. 「게이트웨이를 여러 개 동시에 돌리기」라는 다른 페이지에 적혀 있었습니다. 저는 연동 문서만 보고 미구현으로 결론냈고, 그 전제 위에서 디스패처를 만드는 설계를 잡고 있었습니다. 설치본을 직접 grep 했더니 라우팅 설정 키가 코드에 그대로 있었습니다.

「없다」고 결론내기 전에 설치본을 뒤집니다. 이번에는 없는 게 아니라 다른 페이지에 있었습니다.

도구가 자기 능력을 잘못 말하는 상황은 처음이 아니었습니다. 같은 에이전트 도구에서 작은 모델에게 수집 작업을 시켰을 때도 「못 한다」는 답을 받았는데, 실제로는 할 수 있었습니다.

붙이면서 실제로 밟은 함정 다섯 개

보조 프로필에 채팅 설정을 넣지 않습니다. 같은 봇 토큰을 두 프로필이 물면 시작 자체가 실패합니다

보조 프로필의 게이트웨이를 따로 실행하지 않습니다. 멀티플렉서가 하드 에러로 죽습니다

프로필 목록에서 보조 프로필이 stopped 로 보이는 것은 정상입니다. 판정은 실제 채널 응답으로 합니다

멀티플렉싱 활성화 설정에서 「인식되지 않는 키」 경고가 뜨지만 오탐입니다. 값은 제대로 들어갑니다

새로 만든 프로필은 인증 파일이 없어 실패합니다. 기본 프로필의 인증 파일을 복사하면 됩니다

네 번째가 특히 시간을 먹었습니다. 경고를 액면대로 믿고 설정 키 이름을 세 번 고쳤는데, 처음부터 값은 정상으로 들어가고 있었습니다.

프로필의 축은 역할이 아니라 프로젝트입니다

프로필을 영업, 마케팅, 개발로 가르는 안도 검토했습니다. 그렇게 가르면 「유지보수 범위를 넓혀 견적을 낼까」 같은 질문에 어느 프로필도 반쪽만 아는 상태가 됩니다. 견적은 영업 축이고 유지보수 범위는 개발 축이라 한 질문이 두 프로필에 걸칩니다.

역할은 프로필의 축이 아니라 요청 문장의 축입니다. 이걸 프로필로 삼으면 프로젝트 아홉 개 곱하기 역할 다섯 개가 되어 관리 대상이 곱셈으로 늡니다. 도구 쪽에서도 같은 모양이 나타납니다.

채널이 곧 권한 경계가 됩니다

라우팅 기준이 채널이라 채널이 그대로 접근 경계가 됩니다. 사람이 들어오면 채널 초대가 곧 그 프로젝트 에이전트에 대한 접근 허용입니다. 별도의 권한 시스템이 필요 없어졌습니다. 다만 금액과 원가는 도구 권한으로 막습니다. 지시문으로 적어둔 금지는 어떤 식으로든 샙니다.

다른 프로필을 채널 밖에서 호출할 수 없다는 제약도 확인했습니다. 그런데 써보니 호출할 필요가 없었습니다. 기본 프로필에서 내부 프로젝트 관리 도구를 조회하면 사실 관계는 다 나옵니다. 프로필이 독점하는 것은 메모리와 지시문뿐입니다.

축이 다른 두 시스템을 붙일 때

양쪽 축을 곱하지 않습니다. N 대 N 으로 맞추면 관리 대상이 제곱으로 늡니다

이미 나뉘어 있는 것을 먼저 봅니다. 새 경계를 만들기 전에 있는 경계를 쓸 수 있는지 확인합니다

자연스러운 1:1 이 대개 가장 비쌉니다. 그 직관의 대가가 여덟 단계 곱하기 N 입니다

눈에 보여야 할 때만 나눕니다. 필요해지면 그때 나눠도 늦지 않습니다

도입 전에 확인할 것

붙이려는 두 시스템이 각각 무엇을 기준으로 나뉘는지 한 줄로 적어봅니다

새 단위를 하나 늘릴 때 따라오는 절차를 실제로 세어봅니다

조직에 이미 있는 경계를 그대로 쓸 수 있는지 봅니다

「핵심 개발 과제」로 잡아둔 항목이 설정으로 되는지 확인합니다

민감 정보 차단은 지시문이 아니라 도구 권한 층에서 겁니다

아직 확인 안 된 것

지금 만든 것은 구조이지 효과가 아닙니다. 기본 프로필 하나로 이미 꽤 많은 일이 되고 있고, 프로필을 셋으로 나눈 이득은 아직 드러나지 않았습니다. 대신 프로필을 더 채울 트리거를 적어뒀습니다. 대화가 프로젝트끼리 섞여 답이 흐려질 때, 같은 도메인 설명을 반복하게 될 때, 사람이 들어올 때입니다.

한계도 분명합니다. 채널이 곧 역할이라 한 방에서 두 역할을 부를 수 없습니다. 채널이 프로젝트별로 안 갈려 있는 조직이면 전제가 무너집니다. 봇 하나에 모든 프로필이 매달리므로 그 하나가 죽으면 전부 죽는다는 점도 남아 있습니다.

그래도 하나는 건졌습니다. 새 경계를 만들기 전에 이미 갈려 있는 경계를 먼저 세어보면, 만들어야 한다고 믿었던 것의 상당수가 설정 몇 줄로 줄어듭니다.