SaaS 계약을 끊다 — "심장은 자체, 주변은 외주"라는 기준
외주 ERP, 외주 전자결재, 외주 메신저 — 매달 구독료가 나갔습니다. 편했지만, 우리 시스템과 따로 노는 섬들이었습니다. AI 네이티브 ERP를 직접 만들기로 하면서, 이 구독들을 하나씩 정리했습니다. 단순한 비용 절감이 아니라 데이터와 흐름의 주권을 되찾는 일이었습니다. 다만 핵심은 “모든 SaaS를 끊자”가 아닙니다 — 이 글은 무엇을 직접 쥐고 무엇을 외주에 맡길지 가르는 단 하나의 기준에 대한 기록입니다.
1. SaaS가 뭔데, 왜 끊는다는 건가
섹션 제목: “1. SaaS가 뭔데, 왜 끊는다는 건가”외주 SaaS는 빠르고 편합니다. 가입하면 바로 씁니다. 처음엔 그게 옳습니다. 하지만 회사가 여러 SaaS를 쓰다 보면 각각이 독립된 섬이 됩니다. ERP는 ERP대로, 전자결재는 전자결재대로, 메신저는 메신저대로 — 데이터가 서로 흐르지 않고, 우리가 원하는 대로 엮을 수 없습니다.
2. 편리함의 대가는 “섬”이었다
섹션 제목: “2. 편리함의 대가는 “섬”이었다”섬이 왜 문제인가요? 그림으로 보면 분명합니다.
AI 에이전트가 이 흐름을 가로질러 일하려면, 이 섬들이 치명적 장벽이었습니다. 에이전트가 “출퇴근 정정을 결재로 올리고, 승인되면 근태에 반영하라”를 하려면 결재와 근태가 한 데이터 위에 있어야 합니다. 섬으로는 불가능합니다.
섬의 비용은 추상적이지 않습니다. 아주 구체적으로 나타납니다. 예를 들어 “지난달 출장 결재가 승인된 직원의 출장비가 실제로 회계에 잡혔는가”를 알고 싶다고 합시다. 결재가 외주 A에, 회계가 외주 B에 있으면 두 시스템을 각각 열어 사람이 눈으로 대조해야 합니다. 자동으로 잇고 싶어도 두 업체의 닫힌 상자 사이에 다리를 놓을 방법이 마땅치 않습니다. 섬이 늘어날수록 이런 수작업 대조와 누락이 기하급수로 늘어납니다. 통합이 안 되는 시스템은 결국 “사람이 시스템 사이를 메우는” 노동을 만들어냅니다 — 우리가 ERP로 없애려던 바로 그 노동을.
3. 무엇을 끊고, 무엇으로 바꿨나
섹션 제목: “3. 무엇을 끊고, 무엇으로 바꿨나”| 해지/전환한 것 | 대체 | 핵심 동기 |
|---|---|---|
| 외주 ERP | 자체 ERP(단일 백엔드) | 업무 흐름을 직접 통제 · 에이전트 연동 |
| 외주 전자결재 | 자체 전자결재 | 상태머신·법적 효력을 우리 손에 |
| 외주 메신저 | Slack 협업 도구 | 에이전트가 일하는 광장으로 전환 |
눈치챘겠지만, 메신저는 자체로 안 갔습니다. 외주(Slack)로 갔습니다. 이게 핵심입니다 — 우리는 “모든 걸 자체로”를 하지 않았습니다.
여기엔 우리가 실제로 겪은 학습이 깔려 있습니다. 메신저를 한때 사내에 직접 호스팅해 봤다가 운영 부담 때문에 걷어낸 경험입니다(그 이야기는 메신저 여정에 따로 적었습니다). “데이터 주권”이라는 매력에 끌려 자체로 갔지만, 정작 우리가 풀려던 문제(에이전트 연동)는 자체 호스팅이 더 잘 풀어 주지 않았고, 대신 운영이라는 새 짐만 늘었습니다. 그 경험이 “심장과 주변을 가르는 기준”을 날카롭게 만들었습니다. 모든 걸 자체로 끌어안는 건 통제가 아니라 과부하였습니다.
4. 가르는 단 하나의 기준 — “심장인가, 주변인가”
섹션 제목: “4. 가르는 단 하나의 기준 — “심장인가, 주변인가””이 기준을 적용하는 법은 간단한 자문(自問) 한 줄로 압축됩니다. “이 기능이 멈추면 회사의 핵심 업무가 멈추는가, 아니면 불편해지기만 하는가?” 결재가 멈추면 회사가 멈춥니다 — 심장입니다. 메신저가 멈추면 불편하지만 다른 채널로 우회할 수 있습니다 — 주변입니다. 이 한 줄이 “직접 만들까, 사 쓸까”의 끝없는 논쟁을 대부분 정리해 줬습니다.
| 자문 | 심장(자체) | 주변(외주) |
|---|---|---|
| 멈추면 회사가 멈추나? | 예 — 결재·ERP | 아니오 — 우회 가능 |
| 통합이 필요한가? | 핵심 — 흐름이 한 몸이어야 | 덜 중요 |
| 운영 부담을 질 이유가 있나? | 통제를 위해 진다 | 없음 — 외주에 맡김 |
5. 자체 구축이 진짜로 푸는 것 — 통합
섹션 제목: “5. 자체 구축이 진짜로 푸는 것 — 통합”자체 ERP의 진짜 가치는 비용이 아니라 통합이었습니다. 출퇴근 정정이 전자결재로 흐르고, 결재 결과가 근태에 반영되고, 모든 도메인이 단일 백엔드 위에서 한 데이터를 공유합니다. 외주 SaaS 조합으로는 절대 만들 수 없는 흐름입니다. 그리고 이렇게 흐름이 한 몸이 되어야, 비로소 에이전트가 그 흐름 전체를 가로질러 일할 수 있습니다.
구체적인 예가 바로 출퇴근 정정의 결재 통합입니다. 직원이 모바일에서 “어제 퇴근 시각이 잘못 찍혔어요”를 신청하면, 같은 작업 단위(트랜잭션) 안에서 전자결재 문서가 자동 생성되어 결재선을 타고, 최종 승인이 떨어지는 순간 근태가 고쳐집니다. 근태 모듈과 결재 모듈과 인사 데이터가 한 백엔드 위에 있기 때문에 가능한 일입니다. 만약 근태가 외주 A, 결재가 외주 B에 있었다면, 이 한 줄의 흐름을 만들기 위해 두 업체의 연동 규격을 맞추고, 둘 다 바뀌지 않기를 빌어야 했을 것입니다. 통합은 “있으면 좋은 것”이 아니라, 에이전트가 일하기 위한 전제 조건이었습니다.
6. 구독은 비용, 자체 시스템은 자산
섹션 제목: “6. 구독은 비용, 자체 시스템은 자산”회계적으로도 의미가 있습니다. SaaS 구독료는 매달 사라지는 비용입니다. 반면 직접 만든 시스템은 회사에 남는 자산입니다.
| SaaS 구독 | 자체 시스템 |
|---|---|
| 매달 사라지는 비용 | 회사에 남는 자산 |
| 데이터·흐름이 업체 울타리 안 | 데이터·흐름을 직접 소유 |
| 빠른 시작 | 만드는 시간이 듦 |
1인 개발자가 AI와 협업해 빠르게 만들 수 있게 된 지금, 이 등식의 균형점이 자체 구축 쪽으로 옮겨갔다는 것이 CEO의 판단입니다. 예전엔 “직접 만들 시간이면 그냥 사 쓰자”가 합리적이었지만, AI 협업이 그 “만드는 시간”을 크게 줄이면서 계산이 바뀐 것입니다.
이 판단을 실제 적용할 때 우리가 따른 순서는 이렇습니다. “전부 한꺼번에 자체로” 같은 무모한 전환이 아니라, 기준에 따라 하나씩 가른 것입니다.
- 쓰고 있는 SaaS를 “심장 / 주변”으로 분류합니다(멈추면 회사가 멈추는가?).
- 심장(ERP·결재)부터 자체로 옮깁니다 — 통합·통제·에이전트 연동을 얻기 위해.
- 주변(메신저·운영 인프라)은 외주를 유지하거나 더 나은 외주로 바꿉니다.
- 자체로 옮긴 심장들끼리 한 데이터로 통합합니다 — 여기서 진짜 가치가 나옵니다.
핵심은 “자체냐 외주냐”를 도덕 문제처럼 다루지 않은 것입니다. 그건 비용과 통제의 균형 문제였고, 그 균형은 “이게 심장인가”라는 한 질문으로 매번 새로 계산됐습니다.
이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.