AI 브랜딩 | IT 개발 철학
바이브코딩으로 사내 도구를 만들기 전 확인할 6가지 운영 비용 본문

첫 화면을 만드는 속도와 실제 업무를 책임지는 비용은 다릅니다.
SaaS 월 구독료가 아깝게 느껴질 때가 있습니다. 화면에 필요한 기능은 몇 개뿐인데 매달 비용이 나가고, AI에게 설명하면 비슷한 도구가 금방 만들어질 것처럼 보입니다.
실제로 첫 화면은 빠르게 만들 수 있습니다. 문제는 그다음입니다. 누가 로그인할 수 있는지, 데이터가 사라지면 어떻게 복구할지, 외부 서비스가 바뀌면 누가 고칠지까지 정하는 순간부터 직접 만든 도구는 작은 제품이 됩니다.
직접 만들기의 비용은 첫 화면이 아니라, 계속 책임질 항목의 수에서 나옵니다.
이 글의 핵심
구독료와 개발비만 비교하지 말고, 권한, 데이터, 장애, 외부 연동, 변경, 담당자까지 함께 계산해야 합니다.
1. 구독료와 개발비만 비교하면 판단이 틀어집니다
기존 SaaS를 쓰면 돈을 내는 대신 계정 관리, 백업, 장애 대응, 업데이트 같은 책임의 상당 부분을 공급자에게 맡깁니다. 직접 만들면 월 구독료를 줄일 수 있지만 그 책임이 다시 내 업무로 돌아옵니다.
비교표에는 가격 옆에 아래 항목을 함께 적어야 합니다.
- 로그인과 권한 관리
- 데이터 저장과 복구
- 오류 확인과 장애 대응
- 외부 서비스 연결과 변경 대응
- 기능 요청과 수정 기록
- 운영을 맡을 사람과 가능한 시간
이 여섯 칸을 채우면 저렴해 보였던 선택이 실제로도 저렴한지 확인할 수 있습니다.

가격표 밖으로 이동한 책임을 한눈에 적어보는 것이 출발점입니다.
2. 먼저 이 일이 우리만의 방식인지 확인합니다
모든 업무가 직접 만들 가치가 있는 것은 아닙니다. 일정 관리, 문서 작성, 일반적인 결제처럼 이미 표준이 잘 잡힌 일은 검증된 서비스를 쓰는 편이 빠를 수 있습니다.
반대로 고객 문의를 분류하는 방식, 견적을 승인하는 순서, 여러 도구 사이에서 상태를 옮기는 규칙처럼 우리 팀의 운영 방식이 경쟁력이 되는 부분은 작은 내부 도구로 만들 가치가 있습니다.
판단 질문 3가지
- 다른 팀도 거의 같은 방식으로 하는가?
- 우리가 다르게 처리해야만 하는 이유가 있는가?
- 그 차이가 고객 경험이나 작업 시간에 실제 영향을 주는가?
세 질문에 모두 분명히 답하기 어렵다면 기존 도구를 먼저 써보는 편이 안전합니다.
3. 만들기 전에 실패했을 때의 하루를 그려봅니다
정상적으로 작동하는 화면만 보면 직접 개발이 쉬워 보입니다. 운영 판단에는 멈춘 날의 모습이 필요합니다.
예를 들어 주문 상태를 정리하는 도구가 월요일 오전에 열리지 않는다고 가정해보세요. 원본 주문은 어디에 남아 있는지, 수동으로 처리할 방법이 있는지, 마지막 정상 데이터로 돌아갈 수 있는지, 고객 안내가 필요한지를 적습니다.
답이 없는 항목이 많다면 기능보다 복구 계획을 먼저 만들어야 합니다. 직접 만든 도구가 업무의 유일한 입구가 되지 않도록 원본 데이터와 수동 절차를 남기는 것이 좋습니다.
4. 외부 연동은 붙이는 순간보다 바뀌는 순간을 계산합니다
메일, 결제, 일정, 문서, 고객 관리 서비스와 연결하면 내부 도구의 효용은 커집니다. 하지만 상대 서비스의 인증 방식이나 응답 형식이 바뀌면 연결 부분도 함께 손봐야 합니다.
| 기록 항목 | 확인할 질문 |
|---|---|
| 데이터 | 어떤 정보를 주고받는가? |
| 영향 | 연결이 끊기면 어떤 업무가 멈추는가? |
| 관측 | 오류를 어디에서 확인하는가? |
| 담당 | 누가 다시 연결하거나 수정하는가? |
연결이 많을수록 기능 수보다 책임 경계가 중요합니다. 핵심 업무는 한 번에 모두 묶지 말고 실패해도 독립적으로 처리할 수 있도록 나누는 편이 좋습니다.
5. 30일 실험으로 유지할 수 있는지 확인합니다
처음부터 기존 SaaS를 완전히 대체하지 마세요. 한 가지 반복 업무만 골라 30일 동안 병행하면 직접 만든 도구의 실제 비용이 보입니다.
첫째 주, 입력과 결과를 한 가지씩 정합니다.
둘째 주, 실제 업무에 사용하되 원본 기록을 유지합니다.
셋째 주, 오류, 수정 요청, 수동 처리 시간을 기록합니다.
넷째 주, 절약한 시간과 새로 생긴 관리 시간을 비교합니다.
30일 뒤 남길 숫자
사용 횟수, 절약한 시간, 오류와 중단 횟수, 수정 시간, 수동 처리 횟수, 다음 달 담당자

만드는 데 성공했는지가 아니라, 다음 달에도 안정적으로 쓸 수 있는지를 봅니다.
6. 직접 만들기, 구독, 혼합 중 하나를 고릅니다
업무 방식이 독특하고 범위가 작으며 책임질 사람이 있다면 직접 만들기가 잘 맞습니다. 안정성과 규정 준수가 중요하고 담당자가 없다면 검증된 SaaS가 더 나은 선택일 수 있습니다.
가장 현실적인 답은 혼합인 경우가 많습니다. 메일, 결제, 인증처럼 신뢰성이 중요한 기반은 검증된 서비스를 쓰고, 우리 팀만의 분류와 알림, 기록 흐름은 작은 자동화로 연결합니다.
오늘 할 일
없애고 싶은 반복 업무 하나를 골라 기능 목록보다 책임 목록을 먼저 써보세요. 만들 수 있다는 사실과 운영할 수 있다는 사실을 구분하면 선택이 쉬워집니다.
자주 묻는 질문
바이브코딩으로 만든 내부 도구는 언제부터 업무에 써도 되나요?
원본 데이터가 별도로 남고, 실패했을 때 수동 처리 방법이 있으며, 로그인 권한과 복구 방법을 확인한 뒤 제한된 업무부터 병행하는 것이 좋습니다.
SaaS 구독료보다 직접 만드는 편이 항상 저렴한가요?
아닙니다. 수정, 장애 대응, 데이터 복구, 외부 연동 변경, 담당자 시간을 함께 계산해야 실제 비용을 비교할 수 있습니다.
기존 SaaS와 직접 만든 도구를 함께 써도 되나요?
가능합니다. 안정성이 중요한 기반은 기존 서비스를 유지하고, 우리 팀만의 분류, 알림, 기록 부분만 작은 도구로 연결하는 혼합 방식이 현실적입니다.
더 구체적인 연결 사례는 오피셜메일 외부 연동으로 기존 업무 흐름을 연결하는 방법에서 확인할 수 있습니다.
