협업툴을 왜 그만뒀는지 물었더니, 절반은 직접 만들어 쓰고 있었습니다

협업툴을 왜 그만두셨는지 물으면, 가장 많이 돌아온 답은 기능이 아니라 도구에 익숙해지는 과정 자체가 부담이라는 것이었습니다.

AI가 빠르게 발전하면서 많은 SaaS가 제품에 AI를 붙이고, 제품의 방향 자체를 바꾸기도 했습니다. 개발자들이 막히면 찾던 Stack Overflow는 ChatGPT가 나온 뒤 새 질문이 빠르게 줄어, 2025년에는 월간 질문 수가 서비스를 처음 시작한 2009년 수준까지 내려갔습니다(The Pragmatic Engineer).

AI 시대에 Riido가 어떤 자리에 서야 하고 어떤 고객을 만나야 하는지, 저희도 이 질문을 피할 수 없었습니다. 방향을 잡는 데 저희 팀 모두가 큰 힘을 들였고, 저는 그 과정에서 실패를 여러 번 반복했습니다. 그러면서 저희의 본질인 '일하는 방법의 혁신'은 바뀌지 않는다는 확신을 얻었고, 지금은 정돈된 방향을 가지고 가설을 세우고 검증하기를 반복하고 있습니다.

이번 인터뷰의 시작은 저희 고객 한 곳이 떠난 일이었습니다. 부족한 기능 목록을 듣게 될 거라 생각하고 찾아갔는데, 돌아온 답은 일하는 방식의 전제가 달랐다는 것이었습니다.

이게 한 회사만의 이야기인지 알고 싶어, 2주 동안 그 고객을 포함한 IT / 소프트웨어 기업 여덟 곳의 대표와 책임자를 찾아가 인터뷰했습니다. 여덟 곳 중 일곱 곳이 쓰던 도구를 접었고, 네 곳은 필요한 도구를 직접 만들어 쓰고 있었습니다. 한 곳에서는 AI로 만드는 비용이 크게 줄었다는 이야기도 들었습니다.

프로젝트 관리 도구를 만들어 온 회사의 GTM으로서 반가운 답은 아니었습니다. 5명이 9주 만에 Riido를 다시 만든 이유가 팀 안에서 AI와 함께 일하는 방식을 바꾼 이야기라면, 이 글은 같은 시기 팀 밖에서 고객이 떠난 이유를 찾아다니며, 우리 고객이 누구인지에 대한 제 가설이 어떻게 틀렸고 무엇을 바꿨는지 적은 기록입니다.

1/ 떠난 고객에게 이유를 물었습니다

당시 제가 세운 가설은 단순했습니다. 고객사 프로젝트를 반복해서 수행하는 작은 IT / 소프트웨어 기업이라면, 프로젝트를 시작하고, 진행 상황을 고객에게 보고하고, 담당자가 바뀔 때 인수인계하는 일에서 같은 문제를 계속 겪을 것이라고 봤습니다. 그런 팀이라면 Riido가 도울 수 있고, 작은 기업은 결정권자와 바로 이야기할 수 있어 결정도 빠를 것이라고 생각했습니다. 떠난 고객도 바로 그런 회사였습니다.

저희 서비스를 떠난 이유를 정리해 보니 기능 몇 가지의 문제가 아니었습니다. 저희 제품은 한 회사 안에서 함께 일하는 팀을 기본으로 삼았는데, 이 회사는 고객사마다 참여하는 사람이 계속 바뀌는 프로젝트 단위로 일하고 있었습니다. 전제가 달랐습니다.

그래서 비슷하게 일하는 다른 팀들을 직접 찾아가 보기로 했습니다.

2/ 답장을 기다리지 않고 찾아갔습니다

그전까지는 이메일을 보내고 답장을 기다렸습니다. 답이 없으면 거기서 끝났습니다. 그래서 방식을 바꿔 직접 찾아가기로 했습니다.

경기와 서울의 사무실을 직접 찾아다녔습니다. 연락 없이 찾아간 사무실의 문이 잠겨 있어, 퇴근 시간까지 기다렸다가 만나고 온 날도 있었습니다. 하루 이틀 동안 전화를 60~80통 돌린 적도 있습니다. 대부분 이동하면서 건 전화였고, 바로 끊기거나 거절당하는 경우가 많았습니다. 가장 부담스러운 일이었지만, 상대가 실제로 어떻게 일하는지 들을 수 있었던 것도 결국 직접 만나거나 전화로 대화한 경우였습니다.

그렇게 만난 여덟 곳의 대표와 책임자에게 처음 물은 것은 이것이었습니다.

"AI를 적극적으로 쓰시면서, 프로젝트 관리에 어떤 문제가 새로 생겼나요?"

그런데 답을 듣다 보니, 대부분은 프로젝트 관리 도구 자체를 불필요한 마찰로 여겨 이미 그만둔 상태였습니다. 그래서 질문을 바꿔, 지금 무엇으로 프로젝트를 관리하고 무엇을 쓰다가 왜 그만두셨는지를 물었습니다.

3/ 기능이 아니라 배우는 비용이었습니다

만난 곳 대부분이 Jira, Notion, Flow, Linear 같은 도구를 이미 여러 개 써 봤습니다. 네 곳은 필요한 도구를 직접 만들어 쓰고 있었고, 두 곳은 스프레드시트나 Notion 같은 더 단순한 도구로 돌아갔습니다. 한 곳은 Jira를 정착시키지 못하고 Linear로 옮겼습니다.

가장 많이 들은 이유는 기능 부족이 아니었습니다.

프로젝트 관리 툴을 사용하려면 제가 그 툴의 방식에 익숙해져야 합니다. 저는 그 과정이 싫습니다.

저희는 프로젝트 개수도 많고 대부분 속도 우선입니다. 지라에 맞춰서 프로세스를 하나하나 만들어가는 것보다는 빨리 개발해서 빨리 납품하고 프로젝트를 끝내는 게 중요한 경우가 많아요. 그런데 지라를 프로젝트마다 구축하면 그 리소스도 아깝잖아요.

이분들에게는 도구가 주는 이득보다 도구의 방식을 배우는 비용이 더 컸습니다.

AI는 이 계산을 한 번 더 바꾸고 있었습니다. 한 기업에서는 이런 이야기를 들었습니다.

과거에 개발자 다섯 명이 6개월 정도 걸렸을 일을 지금은 한 사람이 한 달 안에 처리할 수 있다고 느낄 정도로 생산성이 달라졌습니다.

같은 자리에서 "요즘은 AI가 있으니 필요한 관리 도구를 내부에서 직접 만들어 쓰는 회사도 많습니다"라는 말도 들었습니다. 이런 내용의 아티클을 수없이 읽어보았는데, 양산형 아티클이라고만 생각했지 현실로 만나는 것은 처음이었습니다. 만드는 비용이 이렇듯 획기적으로 줄면, 도구를 사서 배우기보다 직접 만드는 팀은 더 늘어날 것 같았습니다.

4/ 문제가 있다고 해서 사는 것은 아니었습니다

예상했던 문제는 실제로 있었습니다. 다만 셋 중 둘은 이미 각자의 방식으로 풀려 있었습니다. 프로젝트 착수는 템플릿과 자체 도구로, 고객 보고는 Notion에 고객을 초대하거나 AI로 보고서를 만드는 방식으로 해결하고 있었습니다.

담당자 인수인계는 여전히 어려운 문제로 남아 있었습니다. 그런데 한 곳은 이마저 AI로 풀고 있었습니다.

예전에는 담당자가 나가면 정보도 같이 날아가는 경우가 많았습니다. 지금은 고객사 미팅을 모두 녹음합니다. (…) 이전 담당자가 없는데 어떤 의사결정을 어떻게 했는지 궁금하면 Claude에게 물어봅니다.

제가 만난 곳에서는 문제가 분명한 팀도 이미 자기 방식으로 대응해 두고 있었습니다. 그 방식이 있는 한 새 도구를 들일 이유는 크지 않아 보였습니다. 그 주 팀 회의에서 저는 이렇게 정리했습니다.

💡 문제가 없는 게 아니었습니다. 문제는 있었지만, 이미 자기 방식으로 풀었거나 AI가 우리보다 먼저 풀고 있었습니다.

좋다는 말을 들어도, 날짜를 정한 다음 약속까지 가기는 어려웠습니다.

5/ 가설을 계속 바꿨습니다

제가 찾던 것은 한두 건의 계약이 아니었습니다. 같은 방식으로 반복해서 넓혀 갈 수 있는 고객군, GTM에서는 ICP(이상적인 고객 프로필)라고 부르는 고객이었습니다. 충분히 규모가 있고, 닿을 수 있는 채널이 있고, 돈을 내서라도 풀고 싶은 문제를 가진 새로운 집단을 찾고 싶었습니다.

그래서 가설이 맞지 않으면 바로 바꾸고, 바뀐 가설을 들고 다시 현장에 나갔습니다. 가설이 틀리는 것보다 무서운 건, 틀린 줄 모르고 같은 가설을 붙잡고 있는 일이었습니다.

처음에는 AI 도입을 돕는 컨설팅을 팔 수 있다고 봤습니다. 이미 만나고 있던 팀에 각자의 문제에 맞춘 컨설팅을 제안하면 계약으로 이어질 거라 생각했습니다. 하지만 한 곳은 그 문제가 지금 얼마나 크고 급한지를, 다른 한 곳은 들이는 수고에 비해 얻는 것을 따졌습니다. 둘 다 가격 때문은 아니었습니다. 그 뒤로는 제안하기 전에, 그 문제가 정말 지금 그 팀의 문제인지부터 확인했습니다.

다음에는 같은 문제를 반복해서 겪는 팀을 찾았습니다. 1번에서 쓴 가설입니다. 문제는 있었지만, 앞에서 본 것처럼 대부분 이미 자기 방식이나 AI로 풀고 있었습니다.

그다음에는 배우는 비용을 저희가 대신 지기로 했습니다. 돌아보니 지금까지 결제한 고객은 대부분 영업 없이 스스로 찾아와 구매했습니다. 필요가 분명했기 때문에 따로 온보딩을 도울 일이 많지 않았습니다. 하지만 저희가 먼저 찾아가 만난 고객은 달랐습니다. 영업으로 만난 고객에게는 온보딩이 필수였습니다. 그래서 기존 방식과 다르게 접근했습니다. 세팅과 온보딩을 저희가 직접 맡기로 했고, 부산 K-ICT Week 이후에는 회사마다 실제로 있을 법한 업무를 넣은 테스트 워크스페이스를 만들어 보내, 설명하기 전에 먼저 써 볼 수 있게 했습니다.

그리고 지금은 협업이 복잡해지는 순간을 맞은 팀을 찾고 있습니다.

6/ 고객을 찾는 일도 AI와 함께 했습니다

현장을 뛰는 동안에는 AI 에이전트와 거의 상시로 대화했습니다. 이동하며 미팅과 전화를 이어 가는 빡빡한 일정을 AI가 관리했고, 쌓이는 이메일도 AI가 읽어 주었습니다.

미팅이 끝나면 먼저 제 생각을 Notion에 정리하고, Claude가 그 기록을 읽게 한 뒤 대화하고, 다시 다른 AI와 논의했습니다. 그러다 보니 같은 이야기를 도구마다 반복하는 일이 잦았습니다. AI와 나눈 대화와 맥락이 도구마다 흩어져, 한곳으로 이어지지 않았던 겁니다.

AI가 그럴듯하게 틀린 적도 많았습니다. 리서치를 통해 추린 회사 여덟 곳을 AI가 "리드 후보 목록"으로 정리한 적이 있는데, 연락처도 확인하지 않은 이름일 뿐이었습니다. 행사에서 만난 회사들의 적합도를 표로 정리했을 때는, 실제로 조사한 곳은 넷뿐이고 나머지는 이메일 도메인과 직함만 보고 추정한 것이었습니다. 직접 꼼꼼히 검토해 보고 나서야 알아차렸습니다.

떠난 고객을 두고 AI가 낸 제안도 있었습니다. 프로젝트마다 사람이 바뀌는 회사는 고객 대상에서 빼자는 것이었습니다. 하지만 그 회사가 떠난 건 고객이 될 수 없어서가 아니라, 저희가 처음에 전제한 일하는 방식과 맞지 않았기 때문이었습니다. 고객을 대상에서 빼기 전에, 그 이유가 고객에게 있는지 저희의 전제에 있는지부터 가려야 했습니다.

그 뒤로는 같은 실수를 하지 않도록 프로토콜을 만들었습니다. 확인한 것과 추정한 것을 나눠 적고, AI가 만든 문장은 근거로 쓰지 않는다는 기준입니다. 지금은 이 기준을 자동으로 점검하도록 만들어, 같은 실수가 반복되지 않게 하고 있습니다.

7/ 지금 찾고 있는 팀

찾는 팀이 달라졌습니다. 직접 만들어 쓰거나 스프레드시트로 돌아간 팀들을 다시 보니, 팀만의 확고한 방식이 있거나, 업무가 반복적이거나, 협업 구조가 복잡하지 않은 경우가 많았습니다. 그런 팀에게는 각자의 방식이 잘 맞고 있었습니다.

Riido는 복잡해진 협업을 단순하게 정리해, 프로젝트 관리에 드는 수고를 줄이고 일에 집중하도록 돕는 도구로 시작했습니다. 지금은 여기에 더해 사람과 AI가 같은 맥락에서 일하고, 그 과정과 결과를 다음 일로 이어 가도록 돕고 있습니다. 그렇다면 저희가 만나야 할 팀은 협업이 복잡해지는 순간을 맞은 팀입니다.

그래서 지금은 AI를 실제 업무에 쓰는 팀 가운데, 회사가 커지면서 기존의 방식이 무너져 이제 구조와 체계를 잡아야 하는 팀, 그리고 AI라는 새로운 지식 노동자가 합류하면서 작은 팀이 갑자기 큰 팀처럼 움직여야 하는 팀을 찾고 있습니다. 현장에서 본 것과 저희가 풀려는 문제를 겹쳐 세운 제 가설이라, 맞는지는 계속 만나며 확인하겠습니다.

인터뷰를 하며 저는 각자 AI와 나눈 대화와 작업의 맥락이 팀의 기록에 바로 남지 않는 데서 빈틈을 봤습니다. Riido 2.0이 풀려는 문제도 여기에 있습니다. 이 문제를 돈을 내고 풀려는 팀이 얼마나 되는지는 아직 모릅니다. 지금 현장에서 확인하려는 것도 이 부분입니다.

그동안 가장 크게 배운 것은 관심과 구매가 다른 말이라는 점입니다. 좋다는 반응보다 다음 약속이 잡히는지, 실제로 써 보는지를 먼저 보게 됐습니다.

AI와 함께 일하는 방식을 팀 전체로 넓히려는 팀이라면, Riido를 써 보며 이야기를 나누고 싶습니다. 편하게 jymin@swyg.im으로 연락 주세요.