@nari-product · 2026년 7월 6일 오전 10:07
HN에서 AI로 만든 앱 얘기를 보다가, 댓글 하나가 훨씬 현실적으로 걸렸다. 한 비행학교가 예약/일정 SaaS를 쓰고 있는데도 렌탈 행정은 따로 3화면짜리 작은 웹앱으로 처리한다는 이야기였다. 기존 SaaS가 현지 세금 규칙이랑 오래된 할인 체계를 못 받아줘서, 그 전에는 종이 영수증과 스프레드시트를 옆에 놓고 운영했다고 한다. 글은 160포인트 정도였고, 댓글 흐름도 “완벽한 상용툴이 없는 작은 시장에서는 내부용 CRUD가 결국 남는다” 쪽으로 모였다. 이런 케이스가 재밌는 건 불편이 거창하지 않다는 점이다. 예약은 이미 SaaS가 맡고 있고, 문제는 비행기 렌탈 후 영수증, 세금, 할인, 정산 내역을 다시 맞추는 얇은 틈에 있다. 그래서 현장은 종이 영수증을 보관하고, 스프레드시트에 옮기고, 예외 할인은 사람이 기억하고, 나중에 누군가 3화면짜리 앱을 만들어 붙인다. 돈을 아끼려는 게 아니라, 큰 제품이 자기들의 작은 규칙을 끝까지 따라와주지 못해서 생긴 우회로다. 여기서 제품을 만든다면 “비행학교 ERP”처럼 크게 시작하면 바로 무거워질 것 같다. 오히려 예약 SaaS 옆에 붙는 렌탈 정산 레이어가 더 작고 선명하다. 영수증 사진, 항공기별 대여 시간, 로컬 세금, 멤버십/학생 할인, 미정산 항목만 받아서 하루 끝에 맞춰주는 도구. 이런 건 시장이 작아 보여도, 종이와 시트와 내부 웹앱이 동시에 존재하는 순간 이미 반복 비용이 증명된 셈이다.
Attached Link
news.ycombinator.com/item?id=46262545
첨부한 링크 미리보기입니다.