사내 AI 에이전트의 슬랙·웹·CLI, 업무에 따라 역할을 나누다

사내 AI 에이전트 시리즈 3편. 1편 장기 기억과 온톨로지 · 2편 권한 설계 · 4편 문서 공유

TL;DR

• 사내 AI 에이전트 인포미를 Slack Socket Mode 봇에서 웹 SPA와 CLI(inf)로 확장하면서 업무에 맞게 역할을 나눴어요.
• 세 접점은 FastAPI 코어 하나를 공유하고, 웹과 CLI는 Cloudflare Access가 발급한 JWT로 사용자를 확인해 세션을 계정 기준으로 묶습니다. 슬랙 세션은 channel:thread_ts가 키예요.
• 슬랙은 팀이 함께 보는 회의실, CLI는 내 책상, 웹은 작업을 찾아보고 운영 상태를 살피는 서류함 역할을 맡아요.

채널에 남은 일과 내가 다시 찾을 일

마인드로직에서 쓰는 사내 AI 에이전트 인포미는 회사 자료를 찾고 업무를 도와요. Slack Socket Mode 봇으로 시작했고, 이제 웹과 CLI(명령줄 인터페이스)에서도 부릅니다. 팀이 함께 보는 질문과 개인이 파일을 다듬는 작업을 같은 방식으로 다루기는 어려웠어요.

슬랙에는 회의실 같은 장점이 있었어요. 누가 무엇을 물었고 에이전트가 어떻게 답했는지가 채널에 남으니까, 옆 사람이 답을 참고하고 틀린 내용을 바로잡기도 좋았거든요. 세션 키가 channel:thread_ts라서 스레드 하나가 곧 대화 하나이고, 팀이 공유해야 할 판단과 결과가 대화가 일어난 자리에 남습니다.

그런데 한 사람이 인포미를 부르는 자리는 한 곳이 아니었어요. 계약 관련은 사업 채널에서, 장애 조사는 개발 채널에서, 남에게 보여주기 전의 초안은 DM에서 묻죠. 어느 채널의 어느 스레드였는지는 본인이 기억해야 했고, 이번 주에 무엇을 어디까지 시켰는지 다시 보려면 채널을 돌아다니며 찾아야 했어요.

개인이 진행하는 작업을 다시 찾고 묶어 볼 화면이 필요했고, 동시에 팀의 대화가 남는 슬랙도 유지하고 싶었어요. 공유하는 자리와 혼자 작업을 이어가는 자리를 구분하면서 웹과 CLI의 역할을 정했습니다.

네 접점과 코어. 웹과 CLI는 Cloudflare Access JWT로, 슬랙은 Socket Mode 이벤트로 같은 SessionManager에 닿고, 세션·턴·실행 기록은 PostgreSQL 원장에 남아요.

작업 폴더를 떠나지 않고 묻기

파일을 다룰 때 불편이 뚜렷했어요. 로그를 분석해 달라고 하려면 슬랙에 올리고, 결과물을 받으려면 다시 내려받아야 했죠. 개발자들은 이미 터미널에서 코딩 에이전트를 쓰고 있는데 회사 데이터를 물어보려면 슬랙으로 옮겨 가야 한다고 했어요. 자기 작업 폴더에 있는 파일을 그대로 넘기고 싶다는 요구였어요.

그래서 CLI(명령은 inf)는 지금 작업 중인 파일을 붙여 묻고 결과를 같은 폴더로 받는 흐름에 집중했어요. Python typer + httpx로 만든 순수 API 클라이언트라 서버 변경 없이 SPA가 쓰는 턴 생성 API와 SSE 엔드포인트를 그대로 씁니다. 인증은 cloudflared access login으로 브라우저에서 Google SSO를 한 번 통과하면 cloudflared가 토큰을 캐시하고, CLI는 그 토큰을 요청 헤더로 보내요. 비밀번호도 API 키도 개발자 손에 남지 않습니다. 내 책상에서 서류를 꺼내 옆자리에 건네는 정도의 동작이면 충분해야 했어요.

inf --help의 실제 출력. --attach로 로컬 파일을 붙이면 세션 파일 API로 올라가 턴에 첨부되고, 결과 파일은 files get 명령으로 받아요.

설정과 관리 기능은 웹에 뒀어요. 모델을 바꾸거나 예약 작업을 손보거나 회사가 가르쳐 둔 기억을 살펴보는 일은 목록과 상태가 보이는 화면이 편하니까요. 터미널에 웹의 모든 기능을 옮기기보다, 파일을 다루던 흐름을 유지하도록 역할을 좁혔습니다. 세션·기억·스케줄을 읽는 명령은 있지만 편집은 웹에서 해요.

코딩 에이전트가 회사 데이터를 물을 때

CLI는 개발자가 직접 부르는 데서 한 걸음 더 나갔어요. 개발자가 쓰는 코딩 에이전트가 인포미를 하위 에이전트로 불러요. CLI 설치 명령이 코딩 에이전트용 스킬을 함께 깔아 두면, 로컬 코딩 에이전트는 회사 데이터가 필요할 때 CLI를 비대화 모드로 실행해 세션 키·실행 id·답변·비용을 JSON으로 받습니다. 다른 경로로 MCP 서버도 있어요.

예를 들어 결제 모듈을 고치는 중에 "이 엔드포인트에서 최근 일주일 동안 어떤 오류가 났지?"가 궁금해질 수 있어요. 코딩 에이전트는 코드만 볼 수 있으니 오류 추적 도구가 어디 있고 어떻게 조회하는지 몰라요. 그 질문을 인포미에게 넘기면, 인포미가 이미 연결된 오류 추적 API와 읽기 전용 DB 롤로 오류 현황을 확인해 돌려주고, 코딩 에이전트는 그 답을 근거로 수정 범위를 정합니다.

코딩 에이전트와 인포미가 일을 나누는 순서. 질문은 코딩 에이전트가, 조회는 인포미가, 수정은 다시 코딩 에이전트가 맡아요.

개발자 노트북마다 DB 연결과 자격증명을 다시 구성하고 어떤 테이블을 볼지 가르치는 부담을 덜려는 선택이었어요. 인터페이스가 늘어도 로그인과 권한 확인은 그대로 거칩니다. CLI가 보내는 것은 그 개발자 본인의 Access 토큰이라, 서버는 JWT를 검증해 슬랙에서와 같은 사람으로 확인하고 사용량도 그 사람에게 귀속시켜요. 서비스 토큰은 사람이 아니어서 턴을 만들 수 없고, 봇 자신이 돌릴 일은 서버 안의 로컬 실행기가 맡습니다.

세션은 누구를 기준으로 묶을까?

웹과 CLI의 세션은 사용자 계정을 기준으로 관리해요. 세션 키는 계정 이메일과 id의 조합이고, 어느 인터페이스에서 시작했는지는 세션 메타데이터로 남기고, 사용자는 자신의 작업을 목록에서 찾아 프로젝트 단위로 묶어 봅니다. 사용량도 원장 DB의 턴 테이블에서 사람 기준으로 집계해요.

여기서 작업을 한 계정 아래에서 관리하는 것과 모든 대화를 다른 인터페이스에서 그대로 재개하는 것은 달라요. 웹과 CLI는 같은 세션 키를 쓰니 CLI에서 이어 쓴 대화가 웹 Chats에 바로 보이지만, 슬랙 세션은 channel:thread_ts가 소유자라 개인 목록에는 링크로만 참조돼요. 회의실에서 나눈 이야기와 내 책상 위의 메모를 한 서류함에 섞어 넣지 않는 것과 같아요.

여러 메신저를 하나의 게이트웨이로 받는 개인 에이전트의 발상도 참고했는데, 창구와 작업을 구분해 생각하는 데는 도움이 됐고, 개인 세션과 팀의 공유 대화를 어디까지 나눌지는 회사 사정에 맞게 따로 정했습니다.

브라우저에서는 목록이 필요했다

회의록을 모아 결정 사항을 뽑거나 초안을 여러 번 고치는 일은 질문 한 번으로 끝나지 않아요. 파일을 올리고 결과를 보고 다시 수정하는 동안 이전 대화를 찾아야 하죠. 웹에서는 대화 목록과 프로젝트를 중심에 두고, 작업을 나중에 다시 찾을 수 있게 했어요. 대화에는 제목도 자동으로 붙습니다.

웹의 Chats 화면. 실제 SPA와 같은 내비게이션으로 다시 그렸고 세션 제목과 계정은 가렸어요. web·cli 세션은 한 목록에, slack 세션은 링크로 보여요.

개발자가 아닌 분들에게는 무엇을 시킬 수 있는지 보이는 것도 중요했어요. 슬랙에서는 에이전트가 어떤 기능을 갖고 있는지부터 물어봐야 했거든요. 회사가 가르쳐 둔 기억과 스킬, 내가 걸어 둔 정기 작업이 목록으로 보이면 다음에 맡길 일을 떠올리기가 쉬워져요.

웹에는 Chats 외에 Skills, Memory, Schedules, Usage, Files 화면이 있고, 관리자 화면에서는 Audit 로그와 사람별 사용량, 정기 작업의 마지막 실행 결과를 살펴봅니다. 슬랙만 쓸 때는 에이전트가 무엇을 알고 어떤 작업을 정기적으로 돌리는지 보려면 서버의 기억 디렉터리와 systemd 타이머를 열어야 했는데, 목록으로 보이자 중복되거나 낡은 내용을 찾기 쉬워졌고 화면에서 바로 고칠 수 있게 됐어요. 웹에서 고친 공용 기억과 스킬은 고친 사람 이름으로 git에 커밋됩니다.

모델 선택도 웹에서 다뤄요. 문장을 다듬는 작업과 코드를 살펴보는 작업에서 답의 차이를 비교하고, 그 대화에 맞는 모델을 고릅니다. 파일을 주고받는 데 집중한 CLI와 달리, 웹은 작업을 살펴보고 설정을 조정하는 역할까지 맡아요.

업무에 맞게 나눈 역할

슬랙에서는 팀이 함께 볼 질문과 답을 그 대화가 일어난 자리에 남겨요. CLI에서는 개발자가 작업 폴더를 떠나지 않고 파일과 회사 데이터를 다루고, 웹에서는 개인 작업을 프로젝트로 모아 대화와 에이전트의 운영 상태를 살펴봅니다. 회의실, 내 책상, 서류함이 각자 할 일을 맡은 셈이에요.

같은 FastAPI 코어와 같은 MCP 서버를 쓰더라도 대화의 소유와 공유 범위는 자리마다 다르게 두었어요. 웹·CLI는 Cloudflare Access가 확인한 계정 중심으로 관리하고, 슬랙의 공유 대화는 채널·스레드 맥락을 유지합니다. 인포미를 여러 곳에서 부르게 하면서 저희가 정리한 것은 각 자리에서 어떤 일을 편하게 할지였어요.

어디에서 부르든 질문에 맞는 담당자와 자료를 찾는 바탕은 같아요. 그 바탕이 되는 회사 지식과 장기 기억은 1편에서, 에이전트가 만든 결과물을 어떻게 돌려주는지는 4편 문서 공유에서 이어집니다.