Hacker News 2026.04.16 24

SaaS에 끌려다니지 말고, 내가 주도권을 잡자 — 클라이언트 사이드 인젝션으로 뒤집는 SaaS 스택

우리는 언제부터 SaaS에 종속되었을까

요즘 개발팀이라면 하나쯤은 겪어봤을 거예요. 분석 도구를 바꾸고 싶은데, 기존 SaaS가 데이터를 다 들고 있어서 마이그레이션이 엄두가 안 나는 상황. 혹은 A/B 테스트 툴이 페이지 로딩을 느리게 만드는데, 이미 마케팅팀이 그 위에 수십 개의 실험을 올려놨으니 쉽게 빼지도 못하는 상황 말이에요.

SaaS(Software as a Service)라는 건 원래 "우리가 서버 관리할 필요 없이 서비스만 갖다 쓰면 된다"는 멋진 약속이었는데요, 현실에서는 조금 다른 모습이 됐어요. 우리 서비스의 프론트엔드에 제3자 스크립트가 잔뜩 박혀 있고, 데이터는 각 SaaS 벤더 서버에 흩어져 있고, 뭔가 바꾸려면 벤더의 대시보드에서 설정을 만져야 하는 거죠. 제어권(control)이 완전히 SaaS 쪽에 가 있는 상태예요.

이 글에서 소개하는 아이디어는 바로 이 구조를 뒤집자는 건데요. 소프트웨어 엔지니어링에서 오래된 디자인 원칙인 "제어의 역전(Inversion of Control, IoC)"을 SaaS 스택에 적용하자는 제안이에요.

제어의 역전이 뭐냐면

프로그래밍을 배울 때 보통 내가 코드를 짜고, 내가 라이브러리의 함수를 호출하잖아요? 이게 일반적인 제어 흐름이에요. 그런데 IoC는 이걸 뒤집어요. 내가 라이브러리를 호출하는 게 아니라, 프레임워크가 내 코드를 호출하는 거예요.

React를 쓰는 분이라면 이미 익숙한 개념이에요. 우리가 useEffect를 직접 타이밍 맞춰 호출하는 게 아니라, React 프레임워크가 적절한 시점에 우리 컴포넌트를 렌더링하고 이펙트를 실행해주잖아요? 그게 바로 IoC예요.

이걸 SaaS에 적용하면 어떻게 될까요? 기존에는 SaaS가 자기 스크립트를 우리 페이지에 심고, 자기 서버로 데이터를 보내고, 자기 대시보드에서 모든 걸 관리했어요. IoC를 적용하면, 우리 쪽 코드가 주도권을 잡고 SaaS의 기능을 필요한 방식으로 끌어다 쓰는 구조가 되는 거예요.

구체적으로 어떻게 동작하나요

이 접근법의 핵심은 클라이언트 사이드 인젝션(Client-Side Injection)이에요. 이름이 좀 무서워 보이지만, 보안 공격이 아니라 아키텍처 패턴이에요. 쉽게 말하면 이런 거예요.

기존 방식에서는 예를 들어 분석 툴을 쓸 때, 그 회사의 JavaScript SDK를 우리 사이트에 <script> 태그로 넣었어요. 그러면 그 스크립트가 알아서 사용자 행동을 수집하고, 자기네 서버로 데이터를 쏴요. 우리는 그저 스크립트 한 줄 붙여넣기만 하면 되니까 편하긴 한데, 데이터가 어디로 가는지, 어떤 형식으로 저장되는지 우리가 통제하기 어렵죠.

IoC 방식에서는 우리가 먼저 표준화된 이벤트 인터페이스를 정의해요. "사용자가 버튼을 클릭했다", "페이지를 봤다" 같은 이벤트를 우리 방식으로 만드는 거죠. 그리고 이 이벤트를 어떤 분석 툴로 보낼지는 우리 코드가 결정해요. 마치 전기 콘센트 규격을 통일해놓으면 어떤 가전제품이든 꽂을 수 있는 것처럼, 분석 툴을 바꾸고 싶으면 "플러그"만 교체하면 되는 거예요.

이렇게 하면 몇 가지 큰 변화가 생기는데요. 첫째, 데이터 흐름을 우리가 완전히 제어할 수 있어요. 민감한 정보가 외부로 나가기 전에 필터링하거나 익명화할 수 있죠. 둘째, SaaS 벤더를 바꿀 때 기존 코드를 거의 건드리지 않아도 돼요. 인터페이스는 그대로 두고 구현체만 갈아끼우면 되니까요. 셋째, 여러 SaaS를 동시에 쓰거나, 자체 솔루션으로 점진적으로 전환하는 것도 훨씬 쉬워져요.

기존 방식과 뭐가 다른가요

사실 이런 고민을 한 사람들이 처음은 아니에요. Segment 같은 CDP(Customer Data Platform)가 비슷한 문제를 풀려고 했었는데요. Segment는 "분석 데이터를 한 곳에 모아서 여러 툴로 뿌려주겠다"는 접근이었어요. 좋은 생각이었지만, 결국 Segment 자체가 또 하나의 SaaS 종속이 되어버린 거예요. Segment를 빼려면 또 대공사가 필요한 상황이 된 거죠.

오픈소스 진영에서는 RudderStack이나 Jitsu 같은 프로젝트가 있어요. 이것들은 데이터 파이프라인 자체를 우리 인프라에서 돌릴 수 있게 해줘요. 방향은 비슷하지만, 서버 사이드에 초점이 맞춰져 있어요.

이번에 소개하는 클라이언트 사이드 인젝션 방식은 프론트엔드에서부터 제어를 가져온다는 점이 차별화돼요. 서버를 거치기 전에, 브라우저 레벨에서 이미 데이터 흐름을 통제하는 거죠. 성능 면에서도 이점이 있는데, 제3자 스크립트를 여러 개 로드하는 대신 우리 번들 안에서 가벼운 어댑터만 실행하니까 페이지 로딩이 빨라질 수 있어요.

물론 트레이드오프도 있어요. SaaS가 제공하는 풍부한 UI 대시보드를 직접 만들어야 할 수도 있고, 벤더가 새 기능을 출시했을 때 어댑터를 업데이트하는 유지보수 부담도 생겨요. "편하게 갖다 쓴다"는 SaaS의 장점을 일부 포기하는 셈이니까, 팀 규모와 역량에 따라 판단이 필요해요.

한국 개발자에게 어떤 의미가 있을까

최근 한국에서도 데이터 주권이나 개인정보 보호에 대한 관심이 높아지고 있잖아요. 해외 SaaS에 사용자 데이터를 보내는 것에 대한 법적·보안적 리스크가 커지면서, 데이터 흐름을 우리가 통제해야 한다는 목소리가 점점 커지고 있어요.

스타트업에서 일하시는 분이라면 특히 공감할 텐데요. 초기에는 편하게 SaaS를 여러 개 붙여서 빠르게 서비스를 런칭하지만, 규모가 커지면서 비용도 늘고 종속도 깊어지는 딜레마를 겪게 되거든요. 이때 처음부터 인터페이스를 추상화해놓으면 나중에 훨씬 유연하게 대응할 수 있어요.

당장 실무에 적용한다면, 예를 들어 프론트엔드에서 analytics 모듈을 만들 때 analytics.track('button_click', { ... }) 같은 공통 인터페이스를 먼저 설계하고, 그 뒤에 Google Analytics로 보낼지, Mixpanel로 보낼지, 자체 서버로 보낼지를 구현체로 분리하는 것부터 시작할 수 있어요. 이 정도만 해도 나중에 툴을 교체하거나 추가할 때 작업량이 확 줄어들어요.