혼자 쓰던 AI, 이젠 '팀'이 씁니다

개인의 도구를 넘어, 조직의 시스템으로 (다수 사용자 인증과 설계 진화)

조직에서는 하나의 자원 (조직 시스템: Database, 이메일, 캘린더, CRM, ERP등 )을 다수 사용자가 각자의 권한에 맞게 사용합니다. 그리고,

개인의 도구를 넘어, 조직의 시스템으로

지난 [운영실험 I]이 하이브리드 아키텍처를 통해 제 PC와 클라우드를 잇는 '개인의 완벽한 비서'를 만드는 과정이었다면, 이제 시작되는 [운영실험 II]는 이 비서를 조직의 모든 팀원들과 공유하기 위한 '확장'의 이야기입니다.

"나 혼자 쓸 때는 완벽했는데, 동료에게 주려니 문제가 터진다." 모든 개발자가 겪는 이 딜레마를 저 역시 피할 수 없었습니다.

제 AI 에이전트가 저뿐만 아니라, 관리자(Admin)와 재무 담당자(Finance)를 구분하고, 그들에게 딱 맞는 권한을 쥐여주기 위해서는 시스템의 '심장'을 다시 한번 뜯어고쳐야 했습니다.

오늘은 그 첫 번째 실험인 '다수 사용자 인증'과, 이를 위해 단행한 '아키텍처 대수술'에 대한 기록입니다

1. 너는 누구냐? (다수 사용자 인증)

지금까지 제 AI 에이전트에게 '주인'은 오직 저 하나였습니다. 하지만 팀 단위로 확장을 하려면 같은 자원을 쓰면서도 권한에 따라서, 다른 서비스를 제공해야 하고, 그러자면, AI는 접속한 사람이 누구인지 알아야 하고, 그 사람에 맞춰 필요한 서비스를 해야합니다.

저는 이번 실험에서 두 명의 페르소나를 정의했습니다.

Admin (운영/영업): 시스템의 모든 권한을 쥐고, 제품 문서등 여러 문서를 서버에 업로드하고 데이터베이스관리하는 자, 영업관리를 할수 있는자.

Finance (재경부/경비): 제한된 범위 내에서 소통하고, 조직의 Admin(운영자)으로 부터 업로드된 문서를 조회만 가능한 자, 재정관리를 할 수 있는자.

단순히 로그인만 따로 하는 것이 아닙니다. Admin의 pc로 로그인하면 AI는 구글의 이메일, 캘린더, 구글드라이브와 연동할수 있는 sunnylabtv 계정과 연동되어 운영 업무를 수행하지만, Finance의 pc로 로그인하면 sunnylabtv2 계정으로 스위칭되어 재무 업무 모드로 전환됩니다.

하나의 AI 두뇌(Model)를 공유하되, 손발(Tools & Auth)은 철저히 분리하는 것. 이것이 '팀이 쓰는 AI'로 가기 위한 첫 번째 관문이었습니다.

2. 설계 변동 (Architecture Shift) : VM의 안정감 vs 서버리스의 효율성

여기서 기술적인 아이러니가 발생했습니다. 지난 시즌, 저는 끊김 없는 연결(Stateful)을 위해 "서버리스(Serverless)를 버리고 VM(가상머신)을 선택했다"고 말씀드렸습니다.

하지만 다수 사용자(Multi-users) 환경이 되니 이야기가 달라졌습니다. 성능, 보안, 다중사용자를 위한 최적의 통신 프로토콜을 고민하게 되었고, 또한 사용자가 늘어날 때마다 비싼 VM을 계속 늘리는 것 보다, 비용과 관리 효율을 생각하면 다시 서버리스가 정답이었습니다. 그렇다면 지난 시즌의 문제였던 '연결 끊김'과 '복잡성'은 어떻게 해결해야 할까요?

사용자의 Claude Desktop(Client) 와 MCP 서버(Server) 사이의 통신 규약(프로토콜)을 SSE(Server-Sent Events) 에서 Streamable HTTP로 교체하였습니다. 그러니, 이젠 서버리스(Serverless)도 가능한 상황이 됬습니다. 그리고, 성능, 보안, 다중사용자를 위한 최적의 통신 프로토콜로 교체하게 되었습니다.

AS-IS (SSE: Server-Sent Events): 연결 유지를 위해 클라이언트와 서버가 계속 붙잡고 있어야 했습니다. 다중 사용자가 되니 연결이 2배로 필요했고, 보안은 취약해졌으며, 속도는 느렸습니다.

TO-BE (Streamable HTTP): 최신 트렌드인 HTTP 스트리밍을 도입했습니다. 단일 엔드포인트로 모든 통신을 처리하니 보안이 강화되었고, 속도는 기존 대비 4배나 빨라졌습니다.

무엇보다 가장 큰 수확은, 이 방식 덕분에 다시 '서버리스' 환경에서도 AI 에이전트를 안정적으로 돌릴 수 있게 되었다는 점입니다.

사실 지난 시즌의 결론을 뒤집는 것이 쉬운 결정은 아니었습니다. 하지만 제가 아는 것이 전부가 아니기에, 새로운 것을 시도할 때마다 더 나은 기술들이 보이기 시작했습니다.

최적이라고 믿었던 프로토콜과 서버 환경은 시시각각 변합니다. 이러한 변화를 두려워하지 않고 받아들이는 것이야말로, 직접 개발하고 운영해 보는 사람만이 누릴 수 있는 '진화'의 과정이라고 생각합니다.

3. 데모(Demo): 하나의 뇌, 두 개의 얼굴

실제 구현 결과는 흥미로웠습니다. (첨부된 데모 영상 참조 https://youtu.be/TBsTDPYubXg )

Admin는 @sunnylabtv 이메일 캘린더 계정으로 접속되고, 영업관리시스템에도 연동됩니다. 관련 이메일,캘린더, 영업관리스템을 AI가 읽고 입력하는 행위가 가능하다는것이고, "문서 서버에 올려줘"라고 하면 AI는 즉시 조직의 공용 DB서버에 업로드를 실행합니다.

반면에, 서버에 업로드된 문서의 내용을 Finance 계정으로 접속해서 요청하면 권한에 맞게 AI가 정보를 제공합니다. Admin이 "Finance에게 메일 보내줘"라고 시키면, AI가 알아서 수신자를 찾아 메일을 발송하고 Finance는 고맙다는 답변을 서로 AI에 시키기만하면 가능한 협업 시나리오까지 성공적으로 작동했습니다.

이제 제 AI는 더 이상 개인만의 비서가 아닙니다. 누가 말을 거느냐에 따라 태도를 바꾸고, 필요한 정보를 선별해서 제공하는 자율적인 '조직의 일원'으로 진화했습니다.

Next Step: 신뢰(Trust)를 설계하다

하나의 자원 (조직 시스템: Database, 이메일, 캘린더, CRM, ERP등 )을 사용하면서, 다수 사용자의 각자에 맞는 '인증(Authentication)'을 통해서 식별하고 팀원들에 권한에 맞는 서비스를 제공하는 큰 산을 넘었지만, 여전히 갈 길은 멉니다.

여러 사람이 쓰게 된다는 건, 그만큼 사고의 위험도 커진다는 뜻입니다. AI가 동료의 PC에 멋대로 프로그램을 깔거나, 사장님께 실수로 메일을 보내버린다면 어떻게 될까요?

다음 편에서는 이 시스템을 안전하게 배포하고 통제하기 위한 핵심 안전장치를 다룹니다.

Multi-User Local MCP 배포: 로컬 서버를 팀원들에게 어떻게 쉽게 나눠줄 것인가?

PS,

저의 지식은 유한합니다. 하지만 멈추지 않고 계속 시도했기에, 어제는 보이지 않던 새로운 기술이 이번 실험에서 (SSE -> Streamable HTP) 제 눈앞에 나타났습니다.

누군가는 "왜 말이 계속 바뀌냐"고 할지도 모릅니다. 맞습니다. 무수한 시행착오 끝에 '최적'의 프로토콜, 서버 환경, 개발 방법은 더 나은 기술 앞에서 언제든 달라질 수 있습니다.

하지만 저는 이러한 시행착오가 '직접 부딪쳐 본 사람'만이 알 수 있는 영역이라 믿습니다.

앞으로도 더 좋은 기술, 더 나은 방법을 발견한다면 과거의 제 결론을 과감히 뒤집고 시도하겠습니다. 그리고 그 '솔직한 실패와 성공의 기록'을 여러분과 계속 나누겠습니다.