메신저 여정 — 외주 → 자체 호스팅 → 다시 외주

신진형 · 에스엘파워 · 2026.06.17

사내 메신저 하나를 정하는 데 우리는 세 번의 결정을 거쳤습니다. 외주 서비스에서 시작해, 사내에 직접 호스팅하는 오픈소스를 도입했다가 걷어냈고, 결국 협업 도구로는 다른 외주를 택했습니다. 출발점으로 “돌아온” 것처럼 보이지만, 매 단계가 선택 기준을 다듬는 과정이었습니다. 이 글은 “되돌아가는 것”이 왜 후퇴가 아닌지, 그리고 1인·소규모 조직에서 “자체 호스팅이 공짜”라는 착각이 왜 위험한지에 대한 기록입니다.

1. 세 번의 결정, 한눈에 보기

먼저 전체 여정을 지도로 펼쳐 봅니다. 똑같이 “외주 → 외주”로 끝났지만, 1막과 3막의 외주는 고른 이유가 완전히 다릅니다.

메신저 선택의 3막. 핵심은 아래 빨강/초록 한 줄 — 각 단계에서 무엇을 기준으로 골랐는가. 기준이 "빠르게 → 통제 → 에이전트 연동"으로 선명해집니다.

2. 1막 — 외주 메신저로 시작

처음엔 외주 협업 서비스(메신저+전자결재가 묶인 패키지)를 썼습니다. 가입하면 바로 쓸 수 있다는 장점이 있었습니다. 빠른 시작이 그 시점에선 옳았습니다.

하지만 우리 시스템과 깊게 엮을 수 없다는 한계가 점점 뚜렷해졌습니다. 메신저가 우리 ERP·에이전트와 따로 노는 섬이었습니다. 알림 하나를 우리 흐름에 끌어오는 것조차 닫힌 상자 바깥에서는 어려웠습니다.

3. 2막 — 사내 자체 호스팅을 시도하다

“우리 서버에 직접 메신저를 올리면 모든 걸 통제할 수 있지 않을까?” 그래서 오픈소스 메신저(Mattermost)를 같은 서버에 도입해 봤습니다. 데이터 주권과 커스터마이징 자유는 분명 매력적이었습니다.

자체 호스팅이 약속한 것	실제로 청구된 것
라이선스 “공짜”	운영·보안·백업·장애 대응 시간
무제한 커스터마이징	실제로 손볼 시간은 없었음
데이터 주권	정작 목적(에이전트 연동)은 미해결

여기서 배운 게 컸습니다. 1인·소규모 조직에서 가장 비싼 자원은 라이선스 비용이 아니라 시간입니다. 운영에 쓰는 시간은 제품을 만드는 시간을 그대로 갉아먹습니다.

자체 호스팅의 비용은 “설치”가 아니라 “그 다음”에 있습니다. 처음 올리는 건 하루면 됩니다. 문제는 그 뒤로 영원히 따라붙는 책임입니다 — 보안 패치가 나오면 적용해야 하고, 디스크가 차면 정리해야 하고, 어느 날 서비스가 죽으면 한밤중에라도 살려야 합니다. 이걸 떠안을 전담 인력이 없는 1인 조직에서, 메신저 한 대를 살아 있게 유지하는 것만으로도 제품 개발 시간이 야금야금 빠져나갔습니다. 게다가 같은 서버에 ERP·백엔드가 함께 돌고 있었으니, 메신저의 장애가 핵심 시스템에까지 영향을 줄 위험도 떠안는 셈이었습니다. “공짜”의 진짜 청구서는 이렇게 뒤늦게, 그리고 가장 바쁠 때 날아옵니다.

4. 3막 — 다시 외주, 그러나 완전히 다른 기준으로

최종적으로 협업 도구는 Slack으로 정했습니다. 1막의 외주로 “회귀”한 것처럼 보이지만, 선택 기준이 완전히 달라졌습니다.

“회귀”라는 단어가 주는 인상과 달리, 3막의 Slack은 1막의 외주와 같은 자리가 아닙니다. 1막에선 “메신저”라는 칸을 채우려고 아무 외주나 골랐습니다. 3막에선 “연동성”이라는 또렷한 기준 하나로 후보를 줄여 골랐습니다. 지도 위 좌표는 비슷해 보여도, 거기 도달한 경로와 이유가 다르면 그건 다른 지점입니다. 그리고 그 또렷한 기준은, 앞의 두 막을 겪지 않았다면 손에 쥘 수 없었습니다.

	1막 외주	3막 외주(Slack)
고른 이유	”메신저가 필요해서"	"에이전트가 사람과 일할 연동성”
판단 렌즈	채팅 도구로서	업무의 광장으로서
운영 부담	외주에 맡김	외주에 맡김(의도적)
핵심 관심	빠른 시작	봇·웹훅 연동·에이전트 경험

운영 부담은 외주에 맡기고, 우리는 연동과 에이전트 경험에 집중하기로 한 것입니다. 1막에선 “메신저가 필요해서” 골랐다면, 3막에선 **“AI 에이전트가 사람과 함께 일할 수 있는 연동 가능성”**을 기준으로 골랐습니다.

여기서 짚어 둘 것이 있습니다. 3막의 선택은 2막을 “안 해봤다면” 나오지 못했을 결론이라는 점입니다. 자체 호스팅을 실제로 도입해 운영 부담을 몸으로 겪어 봤기 때문에, “데이터 주권”이라는 매력이 실은 우리 목적(에이전트 연동)을 직접 풀어주지 않는다는 걸 깨달았습니다. 만약 책상 앞에서 장단점 표만 그렸다면 “자유로우니까 자체로 가자”는 매력에 계속 끌렸을 것입니다. 도입했다가 걷어낸 경험 자체가 기준을 날카롭게 만든 학습 비용이었습니다. 시행착오는 낭비가 아니라, 그 다음 결정의 정확도를 높이는 투자였습니다.

5. 도구는 목적의 함수다

이 여정이 가르쳐 준 건, 도구 선택은 “무엇이 가장 좋은가”가 아니라 **“우리가 진짜 풀려는 문제가 무엇인가”**의 함수라는 것입니다. 우리 목적은 “사내 메신저”가 아니라 “에이전트가 일하는 광장”이었습니다. 그 렌즈로 보니 자체 호스팅의 매력은 빛이 바랬고, 연동성이 가장 중요한 기준이 됐습니다.

같은 도구라도 목적이 바뀌면 점수가 뒤집힙니다. “사내 메신저”라는 목적으로 채점하면 자체 호스팅의 데이터 주권이 높은 점수를 받습니다. 그런데 “에이전트가 일하는 광장”이라는 목적으로 다시 채점하면, 데이터 주권은 부차적이 되고 연동성이 1순위로 올라옵니다. 우리가 1막→2막→3막을 거치며 한 일은 도구를 바꾼 게 아니라, 채점표 자체를 바꾼 것이었습니다. 목적이 흐릿하면 채점표도 흐릿하고, 그러면 “남들이 좋다는 것”에 휩쓸립니다. 목적을 한 문장으로 못 박는 일이 도구 비교표를 그리는 것보다 먼저입니다.

잘못된 질문 — “어떤 메신저가 제일 좋은가?” (정답이 없습니다, 목적이 빠졌으니까)
올바른 질문 — “우리가 진짜 풀려는 문제는 뭔가?” → “에이전트가 사람과 함께 일하는 것”
그 다음 — 그 문제를 가장 잘 푸는 도구는? → 연동성이 가장 깊은 것

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.