AI가 소프트웨어를 집어삼킨다는 이야기는 여전히 이어지고 있습니다. 만드는 비용이 이렇게 싸졌는데 굳이 빌려 쓸 이유가 있느냐는 물음이죠.

2016년 11월부터 본격적으로 이메일 마케팅 SaaS(Software-as-a-Service)를 운영해 오면서 시장에 안착한 한국의 대표적인 이메일 뉴스레터 서비스인 스티비(Stibee)의 임호열 공동 대표를 만나 이야기를 나누었습니다. 예상보다 길게 이야기가 이어질 수밖에 없었는데요. 

현재 스티비라는 SaaS 스타트업이 AI가 침투한 현재의 시장 속에서 제품과 조직을 어떻게 바꿔 왔는지에 대해서 꼬리에 꼬리를 물며 이야기를 나누었습니다. 한 기업의 이야기지만, 지금 AI로 인해 변해가고 있는 산업의 중요한 일면을 볼 수 있는 이야기입니다. 

지금 월 구독제가 기본이니까 한 달에 결제하는 고객 수가 저희에게는 핵심 지표입니다. 이 숫자가 현재 6500명 정도 되고요. 작년 같은 시점 대비 10% 늘었습니다.

월 반복 결제 금액(MRR, Monthly Recurring Revenue)은 전년 대비 약 13% 증가했어요.

7 대 3 정도 돼요. 기업이 7입니다. 고객 수 기준으로도 그렇고 매출 기준으로도 그 정도예요. 매출 기준으로 하면 기업이 객단가가 높으니까 비중이 조금 더 올라가는데, 대략적으로는 7 대 3 정도라고 보시면 됩니다.

잠깐 조금 다른 이야기를 하자면, 코로나19 시기에 스티비 사용자가 굉장히 빠르게 증가했어요. 그때 유입되신 분들 중에 개인 크리에이터가 상당히 많아서, 그 이전과 비교했을 때 개인 비중이 그 시점에 많이 증가했습니다.

이후에 다시 줄어들 거라고 예상하기도 했는데 그렇지 않더라고요. (크리에이터 영역의 사용자 수도) 비슷하게 유지되고 있습니다.

2025년 가을부터 AI 때문에 SaaS가 영향을 크게 받을 것이라는 이야기들이 많이 나왔어요. '사스포칼립스(SaaSpocalypse)'라고요. 저도 장기적으로는 맞는 말이라고 생각합니다, 솔직히 말씀드리면요.

근데 단기간 내에 SaaS가 필요 없어지는 일은 없다고 봅니다. 저희도 기존에 필수적으로 사용하던 SaaS 서비스를 대체할 필요성은 아직 느끼지 못하고 있어요.

탈퇴하실 때 사유를 쓰시는데 거기에 종종 그런 게 보이긴 해요. "LLM으로 하려고 합니다" 같은 게 등장하죠. 의미 있는 숫자는 아닌데, 그래도 이런 피드백에 등장한다는 건 저희가 모르는 방식으로 그렇게 하시는 분들이 분명 꽤 있다는 뜻이겠죠. 

반대 방향도 있어요. 고객분들이 만든 홈페이지에 들어가 보면 AI로 만들어서 이제 막 시작하시는 분들도 보이거든요. 서비스 만들어서 시작하는 게 쉬워지니까 그런 분들이 결국 이메일 마케팅을 하겠죠.

그러면 저희 고객이 되겠구나 싶은 생각을 합니다. 그래서 단기적으로는 "AI를 활용해서 뭘 시작하는 게, 비즈니스를 하는 게 쉬워졌다"라는 현상이 저희한테는 어쨌든 긍정적인 방향으로 작용하고 있다는 생각이 들어요.

많지 않죠. 예를 들어 개인 지메일(Gmail) 계정에 연동해서 무엇을 자동화하는 에이전트, 아니면 저희 같은 이메일 마케팅 SaaS를 연동해서 뭘 해주는 에이전트, 이런 건 존재하지만 이 서비스 자체를 대체하는 수준의 제품이 금방 나올지는 아직 잘 모르겠어요.

이메일 마케팅 서비스가 단기에 없어진다는 생각을 안했습니다. 이메일의 기능이 (단기에) 대체될 것이라고 보지 않았거든요.

물론 SaaS 중에 없어지는 것도 있을 겁니다. 단순한 기능을 가진 유틸리티성 SaaS*는 많이 없어질 수밖에 없다고 생각하고요. 

그러니까 그 회사에 중요한 자산이 쌓여 있는 SaaS라면 그걸 추출해 내기가 어렵기에 그 역할이 분명히 계속될거예요.

내가 여기에 구축을 해놨어도 그걸 통째로 옮기기가 너무 어렵거든요. 서비스 하는 쪽에서도 그걸 최대한 어떻게든 제한할 거고, 진짜 핵심적인 건 추출하지 못하게 막을 거고요. 다만 장기적으로는 비용을 봐야 합니다.

SaaS라는 것도 예전에는 다 직접 만들었잖아요. 외주로 SI(시스템 통합)를 맡겨서 내부에 우리 시스템을 구축했었는데, 이 비용이 너무 비싸니까 클라우드 환경이 생겨나고 그 위에서 각종 서비스를 여러 명이 빌려 쓰는 모델인 SaaS가 나온 거죠. 근데 그게 영원히 계속될 것 같지는 않아요.

한 달에 몇백만 원을 내는 서비스라면 그 돈 나가는 게 눈에 밟히니까 "만드는 비용이 싸졌네" 하고 계산을 해보겠죠. 하지만 계속 필수적으로 사용해야 하는 서비스이면서도 회사 입장에서 만들어 사용하고 관리하는 것보다 저렴한 서비스는 계속 사용하겠죠.

그럴 수 있죠.

한 달에 몇백만 원 쓰는 서비스에 대한 교체를 고민하는 것과 한 달에 몇만 원에서 십수 만 원 쓰는 서비스에 대한 교체를 고민하는 것은 다를 거라고 생각해요.

기본적인 생각은 이메일이 없어지진 않을 것 같고 오히려 사람들이 더 많이 보낼 거라는 겁니다. 

이메일이라는 게 프로토콜 같은 거여서요. 다른 기술이 어떻게 바뀌든, 문자를 보낸다든가 카카오톡은 안 쓸 수 있겠지만 문자라는 방식 자체가 없어지지는 않잖아요. 

이메일도 마찬가지라고 봐요. 슬랙이 생기고 다른 플랫폼들이 생긴다고 해도 결국 그것들 간에 크로스 커뮤니케이션을 할 수 있는, 글로벌하게 다 통용되는 건 이메일이니까 역할을 하지 않을까 싶습니다.

오히려 AI 때문에 이메일의 전체 양은 많아졌어요. 텍스트를 쓰는 비용이 낮아졌으니까요. 반대로 AI가 쓰지 않은 이메일이 더 필요해지겠다는 생각도 들어요.

사실 저희도 세일즈 메일을 보내거든요. 저희 서비스에 가입하신 분들 중에 검토를 해서 영업 가치가 있다고 판단되면 담당자가 메일을 보냅니다. 저희도 여러 시도를 했어요. 많이 보내는 게 맞나 싶어서 일단 최대한 많이 보내봤던 적도 있고요. 

근데 그건 좋은 방법이 아닌 것 같다고 결론을 내려서, 지금은 정말 이분은 보낼 만하다 싶으면 템플릿이 있어도 주요 내용은 다 하나하나 다시 씁니다. 옷을 파는 브랜드라면 저희가 그 브랜드에서 구매했던 경험을 넣기도 하고요.

물론 이런 메일도 많이 받으실 테니까 답이 안 오는 경우가 많아요. 그런데 종종 "이건 진짜 사람이 보내신 것 같아서 그래도 답장합니다" 하고 회신이 옵니다. 다른 사람들은 그렇게 안 썼다는 뜻이겠죠. 거절을 하시더라도 회신은 주시는 거예요.

일단 많아지는 거니까 1차적으로는 좋죠. 보내는 게 편해지면 제일 좋은 거잖아요. 뉴스레터를 하는 것에 대한 진입 장벽이 낮아지면 저희는 좋고요.

사실 콘텐츠 만드는 게 제일 괴로운 일인데, 그건 우리가 해결을 못 해주거든요. 그걸 AI가 해결해주면 좋죠.

근데 이게 너무 많아지면 하향 평준화가 돼서 이 매체 자체에 대한 신뢰가 떨어지면 어떡하지, 하는 걱정도 있어요. 예를 들어, 우리가 플랫폼이면 그걸 컨트롤할 수도 있어요.

최근에 링크드인에 'AI 슬롭' 신고 버튼이 생겼어요. 누르면 리뷰를 한다고 하죠. AI로 만든 슬롭 콘텐츠인지를요. 스팸 메일에 대한 관리를 하듯이, 저희도 AI 생성 콘텐츠를 관리하는 역할에 대한 고민도 해야 하는 순간이 올 수 있을 거라 봅니다.

사실 작년부터 "우리 어떡하지"라는 고민을 많이 했었어요. MCP(Model Context Protocol, AI와 외부 데이터 및 프로그램을 연결해 주는 표준화된 통신 규약)가 나왔을 때는 "이거 MCP 만들어야 된다" 싶었다가, 여러 고민을 거쳐서 결과적으로 했던 건 '매직 완드(Magic Wand)' 성격의 AI 기능이었어요. 버튼 하나 누르면 결과가 나오는 그런 느낌으로, 제목을 추천해주는 기능이랑 본문을 다듬어주는 기능을 만들었습니다.

하지만 이 기능을 내놓고 다시 깨달은 점들이 있어요. 사실 내가 작성한 이메일 내용을 내가 쓰는 AI 프롬프트에 넣어서 "제목 써줘" 하면 써주잖아요. 그래서 "이걸 굳이 스티비에서 왜 하지" 하는 거였어요. 뉴스레터 본문을 다듬어 주는 기능도 마찬가지예요. 스티비 에디터 영역에서 버튼을 누르면 다듬어주는 기능인데, 그것도 사실 AI 챗봇에 복사해서 붙여넣고 "다듬어줘" 하면 다듬어 주잖아요. 

하지만 내부적으로는 고민이 계속 되고 있기도 해요. 우리가 아무리 정확도나 품질을 높이려고 다른 맥락을 부어준다고 해도 우리가 가진 맥락이라는 게 결국 그 사람이 기존에 보냈던 메일 중에 비슷한 걸 찾아서 제목 스타일을 맞춰주는 정도일 텐데, 클로드 같은 범용 LLM 모델의 성능이 좋아지면 그 차이가 없어질 거라는 얘기를 많이 했죠.

결국 "우리가 죽어라 컨텍스트를 넣어봤자 그냥 범용 LLM에 짧게 넣어서 하는 거랑 별반 차이가 없을 거다. 얘네가 너무 빠른 속도로 좋아지고 있기 때문에"라는 이야기죠. 저희 같은 서비스 입장에서는 범용 LLM의 결과물과 어떤 차이를 만들어낼 수 있는지 계속 고민해야 한다고 생각해요.

냉정하게 말하면 아직 없는 것 같아요. 제품 안에 AI가 동작하는 부분은 없습니다. 구분을 해보면 제품을 만드는 과정이 많이 바뀌었고, 운영하는 과정에도 AI가 많이 스며들었어요.

구체적으로는, 개발자분들은 코딩할 때 안 쓰는 분이 없고 코드 생산량 자체가 정말 상상 못할 정도로 달라졌습니다. 그리고 저희 서비스가 오래됐다 보니까 레거시가 쌓여 있거든요. 여기 고치면 저기서 터지고 하는 게 되게 많은데, 그걸 해결하려면 리팩토링(Refactoring, 코드의 내부 구조 개선 작업)을 열심히 하고 코드도 다시 써야 하는데, 그러려면 읽어야 되는 코드의 양이 많아요.

오래됐으니까 산발적으로 퍼져 있는 코드들이 어떻게 영향을 주고받는지 이해를 하고, 그걸 피해서 수정을 해야 되는데, 그러려면 그 많은 양의 코드를 이해해야 돼요. 근데 AI가 이걸 기가 막히게 합니다.

예전 같으면 프로토타입 만드는 것도 소프트웨어 개발하는 것보다는 싸니까 개발 전에 만들어서 검증하는 거였는데, 그래도 그것도 비용이 들거든요. 시간도 들고요. 근데 지금은 프로토타입이 진짜 딸깍하면 나오는 것 같아요.

그래서 그걸 만들어서 다른 팀원들에게 보여주고 의견 받고, 동작하는 걸 보면서 얘기하고. 과정 자체가 완전히 달라졌어요. 그걸 실제로 돌아갈 제품으로 개발자가 만들 때는 또 여러 어려움이 있겠지만요.

예전에 혼자서 할 수 있는 일에 비해서 지금은 그게 훨씬 많아졌어요. 저는 원래 직무별 구성이 완결된 하나의 팀이 갖춰져야 한다고 생각했어요. 그게 6명씩이었고, PM 한 명, 프로덕트 디자이너 한 명, 프론트엔드와 백엔드 두 명씩 해서 그런 팀이 제품팀 안에 두 개 있었습니다.

생각이 바뀐 계기가 있었는데, 빨리 만들어야 하는 기능이 있어서 세 분이 맡아서 하신 적이 있어요. 근데 정말 빨리 하시더라고요. 결정도 진짜 빨리 하시고요. 그렇게 일한 분들의 만족감도 높았어요.

그래서 좀 불완전하더라도 최대한 사람을 줄여서 팀을 만들어야겠다고 생각을 바꿨고, 몇 달 전부터 제품팀을 한두 명 단위로 쪼갰습니다. 두세 명이 일하면 서로 뭐 하고 있는지 다 아니까 그냥 말만 툭툭 해도 무슨 상황인지 알잖아요.

근데 그게 조직 차원에서의 바탕인지는 모르겠고, 아직까지는 그냥 개인들의 LLM 활용 능력인 것 같아요. LLM은 각자 너무 잘 쓰시거든요. 더 잘 활용하시는 분은 그걸 또 열심히 전파해주시기도 하고요.

그런데도 여전히 개인의 역량 차원에서 강화되는 것처럼 느껴지고, 조직 관점에서 어떤 변화가 있어야 하는지가 항상 고민입니다.

개인이 LLM을 활용한 경험치라는 게 결국 자기 환경에 갇혀 있는 거고, 그걸 통해 만든 결과물만 조직의 환경에 노출되는 거잖아요. 이걸 어떻게 메우지 싶어서 몇 가지 시도해 본 게 있는데요.

예를 들어, 저희는 일할 때 노션에 태스크를 관리하는 데이터베이스가 있어요. 원칙은 "내가 하는 모든 태스크는 거기에 올리세요"인데 이게 진짜 귀찮거든요.

노션 문서가 만들어지는 상황을 생각해보면, 슬랙에서 뭔가 이슈가 있어서 대화를 하다가 "그러면 OO님이 언제까지 뭐 하셔야겠네요" 이런 식으로 대화가 마무리되잖아요. 그게 노션 문서로 생성되기를 바라는 거예요. 

그걸 AI로 했으면 좋겠다 싶어서, 슬랙에서 커맨드 같은 걸 입력하면 그 대화 내용을 가지고 문서가 만들어지는 걸 만들었어요. AI가 가이드 안에서 초안을 생성하니 일관성도 높아졌고요.

추가로 CS(Customer Service) 대화를 하는 슬랙 채널이 있어요. 거기에 CS 담당자가 "이런 상황인데 뭐가 문제인가요" 하고 올리면 개발자분들이 데이터를 찾아보고 답을 해주시는 과정이 있는데, 종종 예전에 똑같은 일이 있었는데 또 물어보는 경우가 있어요.

그걸 기억하고 있는 사람이 있으면 "작년에 비슷한 케이스 있었고 그때 이렇게 해결했습니다" 하고 바로 나오는데, 이게 약간 복불복이죠. 슬랙이랑 노션에 쌓여 있으니까 검색하면 나오기도 하는데 그것도 사실 운이에요. 무슨 키워드로 검색하느냐에 따라 나올 수도 있고 안 나올 수도 있으니까요.

그래서 일정 시점부터는 CS가 올라오면 그 내용이 압축돼서 어딘가에 계속 쌓이게 해놨고, 새 CS가 올라오면 거기서 비슷한 게 있는지 찾아보게 해놨습니다. 사례가 1년쯤 쌓이면 본격적으로 도움이 되지 않을까 생각합니다.

이걸 회사 전체에 적용한다고 생각하면, 누군가 궁금한 게 있을 때 지금은 사람한테 물어봐야 하잖아요. 그러면 이걸 누가 아는지도 내가 알아야 하고, 물어봤을 때 답변도 기다려야 하고, 그 사람도 답을 찾는 데 시간이 걸리고, 모를 수도 있고, 그러면 또 다른 사람한테 물어봐야 하고요. 그런데 그 사람들 머릿속에 있는 게 다 어딘가에 끄집어내져서 정리되어 있다면 그 LLM에 물어보면 되겠지요.

저희는 다행히 (업무 메신저 서비스) 슬랙이랑 (팀 업무 생산성 관리 툴) 노션을 회사 초창기부터 썼고, 말로 한 것도 가능하면 어딘가에 남겨놓으라고 하는 회사여서 기록이 좀 잘 남아 있긴 해요. 잘 정리해서 쌓아두면 훨씬 잘 활용하게 되겠다는 생각이 듭니다. 

저희는 지금 개발자분들을 사용자로 더 많이 데리고 와야 한다고 생각하고 있어요. 성장 속도를 다시 높일 기회 중 하나인 것 같아요.

API(Application Programming Interface, 응용 프로그래밍 인터페이스)를 연동하는 분들이요. 한번 연동해놓으면 이탈을 잘 안 하시는 분들입니다. 락인이 되니까요. 그리고 꾸준합니다. 보내다 말다 하는 게 아니라, API 연동해서 쓴다는 건 연속적으로 계속 쓴다는 의미니까요.

주로 데이터를 분석하실 때 쓰세요. 예전에는 스티비에서 이메일 상세 통계를 다 받아서 다운로드한 다음에 엑셀에서 가공해야 했거든요. "최근 몇 달 동안 내가 보낸 이메일 중에 이런 식으로 반응한 구독자를 찾아줘" 같은 건데요.

그걸 하려면 이메일마다 상세 통계를 다 받아서 하나로 합친 다음에 엑셀에서 찾아야 합니다. 근데 그걸 조회하는 API가 있어요. LLM한테 권한을 주고 "네가 이거 조회해서 이 조건에 맞는 구독자를 찾아줘" 하면 찾아주죠.

작년에 API를 크게 한번 업데이트하면서 많이 강화가 됐는데, 그런 시나리오를 구현할 때 아직 빠져 있는 부분들이 있어서 보완하고 있고요. 그리고 API 요청을 MCP 서버로 저희가 제공하면 사용자 입장에서는 LLM 에이전트를 끼고 훨씬 편하게 호출해서 쓸 수 있어요. 그래서 MCP도 준비하고 있습니다.

API 연동을 하려면 API 키를 만들어야 하는데, 딱 정확하게 비교할 만한 지표가 마땅치가 않아서 신규 가입자 대비 API 키를 생성하는 사람의 비율을 봤습니다. 그게 올해 작년보다 두 배가 늘었어요.

네. 기존 개발자분들이 갑자기 스티비를 더 많이 쓰려는 게 아니라, API 연동을 해서 API 콜을 할 수 있는 것의 허들이 낮아진 겁니다. 

API를 콜해서 뭘 하려는 사람을 지금까지 우리가 개발자로 봤는데 그 경계가 흐려진 거죠. 예전에도 좀 찾아보면 할 수 있긴 했어요. 꼭 코딩을 해야 되는 것도 아니고요. API 콜이라는 게 뭔지도 대부분 모르고, 그걸 할 수 있다는 것도 모를 수 있는데 지금은 LLM이 도와주니까요.

예전에는 주로 개발자들이 쓰는 서비스들이 그런 모양새였어요. 자기가 만든 UI에서 API를 호출해서 원하는 대로 구성해 쓸 수 있으니까요. 근데 지금은 이게 쉬워져서 더 많은 사람들이 UI로 접근하지 않고 필요한 기능만 가져다가 자기 입맛에 맞게 쓰는 거죠.

조금 뻔한데 저는 데이터라고 생각합니다. 이게 AI 때문에 더 강조되는 해자이지 원래도 대부분의 SaaS가 똑같죠. 고객이 우리한테 데이터를 계속 쌓게 하고, 그렇게 쌓인 게 밖으로 들고 나가기 어려워지는 것. 그게 해자가 된 것 같은데요.

예를 들면 저희는 이메일을 보냈을 때 사람들이 반응한 이력이 쌓여 있는 게 제일 큽니다. 마케팅 하는 사람 입장에서는 내 마케팅에 대해 누가 어떻게 반응했는지에 대한 데이터인 거니까요.

아까 제목 추천 같은 기능에서, 사용자가 자기 LLM 환경에서 하는 것과 스티비에서 하는 것 사이에 차이가 있어야 한다고 말씀드렸잖아요. 저는 그 차이가 데이터에서 나온다고 생각해요.

스티비를 안 쓰는 사람이 LLM을 끼고 뉴스레터를 쓰는 것과, 스티비에 3년치 반응 데이터가 쌓여 있는 사람이 쓰는 건 다를 수밖에 없거든요. 내가 어떤 식으로 뉴스레처를 썼을 때 오픈율이 좋았는지, 클릭률이 좋았는지를 반영해서 만들 수 있으니까요.

다 똑같을 것 같은데요. 예를 들어 HR SaaS라면 그 회사의 HR 정보를 그 SaaS에 다 넣었을 거고, 그러면 그 SaaS 입장에서는 그걸 레버리지 삼아서 그 위에 에이전트를 올리겠죠. 이 에이전트가 이 데이터를 가지고 뭘 더 할 수 있냐를 보는 거죠.

만들기가 너무 쉬워져서 동작하는 기능, 동작하는 도구를 만드는 건 정말 쉬워진 것 같거든요. 앞서도 말씀드렸듯이 유틸리티성 SaaS 같은 것들은 거기에 데이터를 쌓아놓는 게 아니라 지금 필요한 기능 수행이 필요해서 쓰는 거잖아요. 보통의 SaaS는 대부분 데이터를 계속 쌓는 식으로 동작하게 되어 있기 때문에 그런 것들은 해자가 될 수도 있다는 겁니다.

이 말인즉슨 이미 업력이 어느 정도 있어야 된다는 거기도 합니다. 데이터가 많이 쌓여 있어야 이게 말이 되니까요. 새로 만든 SaaS는 그게 없는 상태니까, 데이터가 없는 다른 수많은 저렴한 비용으로 만들어진 소프트웨어들과 같은 상황에서 경쟁하게 될 수도 있죠. 이미 어느 정도 쌓아놓은 SaaS들이 유리할 수밖에 없는 환경입니다.

국내에서 이메일 마케팅 시장이 갑자기 커질 거라고는 생각하지 않습니다. 다만, 새로운 기회는 계속 있을거라고 생각해요. 

저희가 커머스 고객도 되게 중요하게 생각하는데, 항상 겪는 어려움이 우리나라 커머스 회사들이 이메일 마케팅을 잘 안 한다는 거예요. 우리나라 고객들은 이메일 마케팅으로 프로모션을 받지 않으니까요. 카카오톡으로 받죠. 그래서 이메일 마케팅은 임팩트 있는 지표가 안 나옵니다.

근데 해외에서는 이메일 마케팅이 너무 일반적이에요 해외 브랜드들은 이메일 마케팅을 잘 하고요. 그래서 국내 브랜드가 해외에 진출할 때는 이메일 마케팅을 합니다. 할 수밖에 없어요. 

앞으로 좋은 사례가 쌓이면서 이메일 마케팅을 해야겠다고 생각하는 국내 커머스 회사들이 많아질 것으로 기대합니다. 지금도 그런 사례가 늘고 있고요.

두 번째는 스티비 자체의 해외 진출인데요. 저는 개발자 대상 API나, 비밀번호 재설정이나 회원가입 인증 메일 같은 '트랜잭셔널 이메일(Transactional Email)' 서비스가 준비되면 해외 진출을 좀 더 용이하게 해볼 수 있지 않을까 싶어요.

물론 해외에서는 경쟁이 더 치열합니다. 하지만 시도해 볼 수 있는 영역이라고 생각합니다.

오늘 콘텐츠 어떻게 보셨나요?