회사에서 쓰던 그룹웨어를 볼 때마다 저는 생각에 잠겼습니다. 전자결재 말고는 거의 열어보지 않는 메뉴들, 그런데도 매달 인당 44,000원씩 빠져나가는 비용. '이거 정말 이대로 계속 써야 하나' 하는 질문이 머릿속을 떠나지 않았습니다.
그래서 저는 직접 클로드코드로 회사에 맞는 그룹웨어를 만들어보기로 했습니다. 처음부터 완벽하게 설계한 게 아니라, 가장 만만한 기능부터 미완성인 채로 먼저 내놓았어요.
오늘은 그 과정에서 무엇을 배웠는지, 그리고 완성도보다 속도를 택한 선택이 왜 유효했는지에 대해 이야기해보려고 합니다.
1. SaaS 구독은 더 이상 당연한 선택이 아니다
회사에서 쓰던 그룹웨어는 전자결재 기능 외에는 활용도가 낮았습니다. 그런데도 매달 비용은 꼬박꼬박 나가고 있었죠. 저는 이 상황이 이상하다고 느꼈어요. 우리가 실제로 쓰지도 않는 기능에 왜 계속 돈을 내야 하는 걸까, 라는 질문에서 이 작업이 시작됐습니다.
이런 문제의식에서 출발해, 저는 클로드코드를 활용해 회사에 실제로 필요한 기능만 선별해 직접 그룹웨어를 만들기 시작했습니다. 개발자가 아닌 제가 혼자 클로드코드로 개발하고, 동료들은 UI/UX 관점에서 피드백을 주는 방식으로요.
[WHY] 이것이 왜 중요한가요?
지금까지는 외부 SaaS 솔루션을 구독하는 것이 당연한 선택지였습니다. 필요한 기능이 몇 개 안 되더라도, 그 몇 개를 위해 전체 패키지를 통째로 구독하는 것이 유일한 방법이었으니까요.
하지만 이제는 다릅니다. 비개발자인 저도 클로드코드를 통해 회사 실정에 딱 맞는 도구를 직접 만들 수 있는 시대가 됐습니다. 외부 솔루션에 회사를 맞추는 것이 아니라, 회사에 맞는 도구를 직접 만드는 방향으로 전환할 수 있게 된 것이죠. 이게 바로 이 사례가 다른 SaaS 이탈 시도들과 근본적으로 다른 지점입니다.
다만 중요한 것은, 이건 '전면 대체'의 이야기가 아니라는 점입니다. 저는 그룹웨어 전체를 하루아침에 갈아엎지 않았습니다. 활용도가 낮고 리스크가 적은 기능부터 순차적으로 대체하는 전략을 택했어요. 전자결재처럼 회사의 중요한 의사결정이 걸린 기능은 훨씬 더 신중한 검토가 필요하다고 판단했기 때문입니다.
[HOW] 실제로 어떻게 했고, 우리는 어떻게 따라할 수 있나요?
1) 매달 비용은 나가지만 실제로는 거의 쓰지 않는 사내 툴이 있는지 점검해보세요. 그룹웨어일 수도, 협업 툴일 수도 있습니다. 실제 사용 로그를 들여다보면 생각보다 활용도가 낮은 기능이 꽤 많다는 걸 발견하게 됩니다.
2) 그중에서 가장 활용도가 낮고 리스크가 적은 기능 하나를 고르세요. 저는 그 시작점을 전사 주간보고 기능으로 잡았습니다. 반대로 전자결재처럼 민감도가 높은 기능은 후순위로 미뤄야 합니다. 이 순서를 지키는 것이 안전한 대체의 핵심입니다.
3) 골라낸 기능을 클로드코드로 직접 프로토타입 제작해보세요. 코드를 몰라도, 문제를 명확히 정의하고 AI와 대화하며 만들어가는 방식으로 충분히 시작할 수 있습니다.
2. 완벽한 기획보다, 미완성인 채로 먼저 내놓기
제가 가장 먼저 만든 기능은 전사 주간보고였습니다. 완벽하게 기획하고 시작한 게 아니라, 최소한의 기능만 갖춰 빠르게 만들고 바로 런칭했어요.
'개발자도 아닌데, 이렇게 급하게 만들어서 내놓아도 괜찮은 걸까?'
이런 의문이 들 수 있습니다. 그런데 실제로 런칭하고 나서야 보이는 문제들이 있었습니다.
[WHY] 이것이 왜 중요한가요?
런칭 직후, 예상하지 못했던 이슈가 바로 나타났습니다. 이번 주 보고를 다음 주 보고서에 제출해버리는 사용자가 생긴 것이죠. 이건 기획 단계에서 아무리 고민해도 미리 발견하기 어려운, 실제 사용자가 시스템을 만졌을 때만 드러나는 문제였습니다.
만약 제가 완벽한 기획을 마칠 때까지 런칭을 미뤘다면, 이 문제를 훨씬 늦게 발견했을 겁니다. 미완성인 채로 먼저 내놓았기 때문에, 실사용 과정에서 나온 진짜 피드백을 빠르게 반영할 수 있었습니다. 완성도보다 속도를 택한 선택이 결과적으로 더 나은 완성도로 이어진 셈입니다.
KPI 조회 기능도 마찬가지였습니다. 처음에는 분기별 조회만 가능했는데, 실제로 써보니 연도별로 모든 분기를 한눈에 보고 싶다는 요구(분기별 조회→연도별 조회)가 나왔고, 이를 반영해 기능을 고도화했습니다. 처음부터 이 요구를 완벽하게 예측해서 설계했다면, 오히려 시간만 더 걸렸을 겁니다.
[HOW] 실제로 어떻게 했고, 우리는 어떻게 따라할 수 있나요?
1) 가장 단순하고 반복적인 업무부터 최소 기능으로 만드세요. 저는 매주 반복되는 주간보고 작성·취합 업무를 첫 타깃으로 잡았습니다. 복잡한 기능을 한 번에 완성하려 하지 않았어요.
2) 완벽을 기다리지 말고 빠르게 런칭하세요. 런칭이 늦어질수록 실제 사용자 피드백을 받는 시점도 늦어집니다. 오제출 이슈처럼, 실제로 써봐야만 보이는 문제들이 분명히 있습니다.
3) 짧은 주기로 사용자 피드백을 반영해 고도화하세요. KPI 조회 기능을 분기별에서 연도별로 개선한 것처럼, 실사용 요구가 쌓이는 대로 빠르게 반영하는 것이 완벽한 초기 설계보다 훨씬 효율적입니다.
지금 전사 주간보고 기능은 전 직원이 실사용하고 있고, KPI 조회 기능까지 개발이 완료된 상태입니다. 미완성으로 시작했지만, 그 미완성함이 오히려 진짜 필요한 기능을 더 빠르게 완성하게 만든 셈입니다.
3. 다음 리스크: 데이터가 쌓일수록 커지는 관리 부담
여기까지 읽으시면 이런 생각이 드실 수 있습니다.
'그럼 이제 뭐든 다 직접 만들면 되는 거 아닌가?'
하지만 이 작업을 직접 해보면서 제가 가장 신경 썼던 부분은 따로 있었어요.
[WHY] 이것이 왜 중요한가요?
데이터가 쌓일수록 관리 이슈는 커질 수밖에 없습니다. 처음에는 간단한 주간보고 정도였지만, 기능이 늘어날수록 다뤄야 하는 정보의 민감도도 함께 올라갑니다.
특히 개인 KPI 같은 정보는 연봉과 직결되기 때문에, 서로 볼 수 없도록 철저히 통제해야 합니다. 회사 직원만 접근 가능하도록 OAuth(회사 계정으로 안전하게 로그인·권한을 확인하는 인증 방식) 기반 권한 정책을 설계하는 것, 그리고 기능·화면 단위로 권한을 세밀하게 관리하는 것이 이 작업 전체의 신뢰를 좌우하는 부분이었습니다. 이 부분을 소홀히 하면, 아무리 편리한 기능을 만들어도 조직 내 신뢰를 잃을 수 있습니다.
그리고 이건 제 사례에만 국한된 문제가 아닙니다. 다른 조직이 유사한 시도를 하더라도 데이터가 쌓이고 기능이 늘어나는 순간 반드시 마주치게 되는 구조적인 리스크입니다. 이 때문에 저는 전자결재처럼 민감도가 높은 기능은 지금도 신중하게 뒤로 미뤄두고 있습니다.
[HOW] 실제로 어떻게 했고, 우리는 어떻게 따라할 수 있나요?
1) OAuth 등 보안·권한 정책을 처음부터 설계에 포함시키세요. 나중에 추가하려면 훨씬 큰 리스크를 감수해야 합니다.
2) 기능·화면 단위로 권한을 관리하세요. 저는 개인 KPI처럼 연봉과 연결되는 정보는 본인 외에는 볼 수 없도록 화면 단위로 접근을 통제했습니다.
3) 민감도가 높은 기능은 후순위로 미루세요. 전자결재처럼 회사의 중요한 의사결정이 걸린 기능은, 리스크가 낮은 기능부터 충분히 검증한 뒤에 접근하는 것이 안전합니다.
이 그룹웨어로 기존 SaaS 비용을 완전히 대체하고 정산까지 마친 것은 아직 아닙니다. 매달 인당 44,000원이라는 기존 비용을, 활용도 낮은 기능부터 자체 개발로 대체하면 줄일 수 있다는 가능성을 확인한 단계입니다. 그렇지만 이 가능성 자체가, 지금까지 당연하게 여겨온 SaaS 구독 구조를 다시 생각해보게 만드는 계기가 됐습니다.
마무리: 완성도보다 먼저, 쓰이게 하라
오늘 나눈 이야기를 정리해보면 이렇습니다. SaaS 구독은 더 이상 유일한 선택지가 아니며, 비개발자도 클로드코드로 회사에 꼭 필요한 기능만 골라 직접 만들 수 있습니다. 다만 전면 교체가 아니라 활용도 낮고 리스크 적은 기능부터 순차적으로 대체하는 것이 안전합니다. 그리고 완벽한 기획을 기다리기보다 빠르게 만들고 런칭한 뒤 실사용 피드백으로 고도화하는 방식이, 결과적으로 더 나은 완성도를 만들어냅니다. 마지막으로 데이터와 기능이 늘어날수록 권한·보안 설계의 중요성도 함께 커진다는 것을 잊지 말아야 합니다.
오늘 이 글을 읽고 내일 당장 해볼 수 있는 것:
Step 1) 매달 비용이 나가지만 실제로는 거의 쓰지 않는 사내 툴이 있는지 점검해보세요.
Step 2) 그중 가장 활용도가 낮고 리스크가 적은 기능 하나를 골라 클로드코드로 직접 대체를 시도해보세요.
Step 3) 완벽하게 기획하려 하지 말고, 빠르게 프로토타입을 만들어 런칭한 뒤 실사용 피드백을 받아 점진적으로 고도화해보세요.
완벽한 기획을 기다리는 동안에도 비용은 계속 빠져나갑니다. 지금 여러분의 조직에도, 미완성인 채로 먼저 내놓아 볼 만한 작은 기능 하나가 분명히 있을 겁니다. 그 작은 시작이 여러분 조직의 일하는 방식을 바꾸는 첫걸음이 되길 응원합니다.
감사합니다.
의견을 남겨주세요