실버리즘, 1년간의 창업 여정과 요양기관 경로 최적화 서비스 개발기
이 글에서는 제가 지난 1년 넘게 직접 개발하고 운영한 실버리즘이라는 서비스에 대해 이야기해보려고 합니다.
실버리즘은 요양기관 차량운행표를 자동으로 최적화해주는 웹 서비스입니다.
처음엔 단순히 포트폴리오를 만들기 위해 시작했지만, 지금은 전국의 실제 요양기관들에서 사용하는 서비스로 성장했습니다.
실버리즘은 어떤 서비스인가요?
실버리즘은 요양기관에서 매일 작성하는 차량 운행표를
AI 알고리즘으로 자동 생성할 수 있도록 도와주는 서비스입니다.
기능은 크게 세 가지로 나뉩니다:
- 메인 화면에서 차량 운행표를 생성, 수정
- 특정 경로에 대해 빠르게 길 찾기
- 이전 배치 기록을 조회해 반복 작성 시간 절감
요양기관에서는 직원들이 어르신을 픽업하고 데려다주는 차량 운행표를 매일 작성해야 합니다.
출석자가 바뀌거나, 특정 어르신이 빠지는 경우엔 다시 처음부터 만들어야 하죠.
이 과정을 자동화해주고 싶었습니다.
시작은 작고 개인적인 문제였습니다
처음 이 아이디어가 나온 건, 어머니가 운영하시는 요양기관에서였습니다.
차량 스케줄을 매번 손으로 짜는 게 너무 힘들다는 얘기를 들었습니다.
당시 저는 취업 준비 중이었고, 실제 사용자의 문제를 해결하는 프로젝트를 포트폴리오로 만들고 싶었습니다.
그렇게 시작한 프로젝트였지만, 만들다 보니
“우리 기관만 겪는 문제는 아닐 수도 있겠다”는 생각이 들었고,
한두 기관에서 사용해보고 싶다는 얘기를 듣게 되면서 본격적으로 상용화를 고민하게 되었습니다.
토스 페이먼츠와 계약을 맺고 결제 기능을 붙였고,
사업자 등록까지 진행하며 의도치 않게 창업의 길로 들어서게 되었습니다.
개발 중 마주한 현실적인 문제들
1. 경로 최적화 알고리즘 – 단순한 문제가 아니었습니다
처음에는 단순한 그리디 알고리즘이나 브루트포스로도 가능할 거라 생각했습니다.
하지만 직원 30명, 어르신 60명을 배치하는 상황에선
조합만 수천, 수만 가지가 나왔고, 연산량은 감당이 안 됐습니다.
결국 최적화 알고리즘인 유전 알고리즘(Genetic Algorithm)을 사용해
효율적으로 여러 조건을 만족하면서 배치가 가능한 알고리즘을 직접 개발했습니다.
반영해야 할 조건도 많았습니다:
- 앞자리에 태워야 하는 어르신
- 부부는 같은 차량에 태워야 함
- 특정 직원은 특정 어르신만 담당 가능 등
기존의 배송 경로 최적화 알고리즘이나 오픈소스 툴로는 (Google OR tools ... etc) 해결이 어려워
직접 요구사항에 맞는 알고리즘을 짜야했습니다.
2. 알고리즘 성능 최적화 – 20분 걸리던 연산을 2분으로 줄이기까지
초기에 알고리즘 하나 돌리는 데 20분 가까이 걸렸습니다.
서버는 EC2 미디엄 인스턴스를 썼는데 CPU 사용량이 70%를 넘었습니다.
이 상태로 여러 기관이 동시에 쓰게 된다면, 서버비를 감당하기 어려웠습니다.
그래서 다음과 같은 최적화를 진행했습니다:
- Redis 캐시로 거리 행렬 저장
- StringBuilder로 문자열 연산 최적화
- 원시 타입 배열로 참조 타입 제거 → CPU/메모리 사용량 절감
- 불필요한 조건문 정리 및 early return 도입
- MiniPC를 알고리즘 전용 서버로 분리, EC2는 API만 처리
이런 작업들을 통해 연산 시간은 2~3분 수준으로 줄었고,
CPU 사용량도 대폭 낮출 수 있었습니다.
특히 참조 타입 대신 원시 배열을 썼을 때의 성능 차이는 매우 컸습니다.
3. 경로 데이터를 확보하는 문제 – API 한계와 OSRM
경로를 계산하려면 지도 API가 필요했습니다.
카카오, 네이버, 티맵 등 다양한 API를 테스트해봤지만,
모두 하루 요청량 제한이 있었습니다.
예를 들어 직원 30명, 어르신 60명이면
한 번 운행표를 만들 때만도 3,000개 이상의 경로 요청이 필요합니다.
이 문제를 해결하기 위해 OSRM(Open Source Routing Machine)이라는
오픈소스 길찾기 서버를 도커로 EC2에 배포하고,
자체 길찾기 API 서버를 구축했습니다.
그리고 Redis를 사용해 경로 데이터를 위도/경도 기준으로 캐싱해
같은 요청이 반복될 때마다 연산을 줄였습니다.
4. 안정적인 서비스 운영을 위한 구조 개선
서비스가 사용자에게 신뢰를 주기 위해선,
서버가 언제나 정상적으로 돌아가야 했습니다.
그래서 다음과 같은 구조 개선을 했습니다:
- 알고리즘 연산 서버와 API 서버 분리
- RabbitMQ 도입 → 동시에 많은 요청이 와도 순차 처리
- CPU 사용량 75% 넘을 경우 요청 차단 및 사용자 안내
- SSE(Server-Sent Events)로 알고리즘 진행 상태 실시간 전송
- 5분 이상 응답이 없을 경우 에러 알림 표시
이렇게 하자, 연산 중 서버가 끊기거나 장애가 발생했을 때
사용자에게 제대로 알려줄 수 있었고, 안정성도 높아졌습니다.
5. DB 마이그레이션 – Flyway 도입
서비스 운영 중에는 데이터 구조 변경이 자주 필요했습니다.
기존에는 직원(employee) 객체가 회사 정보를 직접 갖고 있었는데,
회사 주소 변경 기능을 만들면서 문제가 생겼습니다.
회사 정보를 따로 분리해 Company 객체로 만들고,
모든 employee에 연결된 데이터를 바꿔야 했습니다.
직접 쿼리를 날리면 데이터 손상 위험이 있어
Flyway를 도입해 점진적이고 안전한 마이그레이션을 구현했습니다.
6. 결제 시스템 구축
가장 민감한 기능이었습니다.
돈이 걸린 부분이기 때문에, 작은 실수도 신뢰를 잃을 수 있었습니다.
그래서:
- 일일 DB 백업 자동화
- 결제 성공/실패 시 슬랙 알림
- 토스페이먼츠 로그를 참고해 오류 추적
- 향후 확장을 위한 결제 단계 분리 및 로깅 구조 설계
작지만 실제로 유료 결제를 받는 서비스였기에
꼼꼼하게 관리할 필요가 있었습니다.
실제 성과와 느낀 점
실버리즘은 아직 큰 서비스는 아닙니다.
하지만 진주 지역에서만도 10곳 넘는 요양기관이 사용했고,
서울, 인천, 창원, 강원도 등 전국 곳곳에서 회원가입이 있었습니다.
어머니가 소속된 협회 모임에서 직접 피칭한 적도 있었습니다.
갑작스럽게 하루 만에 발표 자료를 만들고, 고깃집에서 서비스를 소개했던 기억은
아직도 선명합니다.
앞으로
이 서비스를 만들면서 기술적인 역량도 많이 키웠지만,
그보다 더 크게 배운 건 시장 검증의 중요성이었습니다.
서비스를 완성한 뒤에야 알게 됐습니다.
이 정도 복잡한 기능이 필요한 요양기관은 사실 그리 많지 않다는 걸요.
규모가 크지 않은 기관은 대부분 차량 배치가 고정되어 있고,
굳이 비용을 들여 자동화할 필요성을 크게 느끼지 않았습니다.
앞으로는 이런 실수를 줄이기 위해
최소 기능(MVP)을 먼저 만들고, 유저 반응을 보고 개발을 이어가는 방식을 쓰려고 합니다.
마무리하며
1년 동안 정말 많은 걸 배웠습니다.
DB 백업, 마이그레이션, 경로 최적화, 서버 분리, 캐싱 전략, 결제 연동, 실 사용자 대응까지…
단순한 사이드 프로젝트였다면 절대 겪지 못했을 일들을 직접 부딪히며 하나씩 해결해나갔습니다.
비록 수익적으로 성공했다고 말하긴 어렵지만,
이 경험 덕분에 어떤 서비스를 만들든 더 빠르게, 더 안정적으로 구현할 수 있는 기초 체력을 갖추게 됐다고 생각합니다.
실버리즘은 지금도 운영 중이지만,
AI 경로 계산이라는 서비스 특성상 성능이 좋은 CPU 자원이 필요하고,
이 때문에 AWS 인프라 비용이 한 달에 10만 원 가까이 나옵니다.
실버리즘 외에도 다른 서비스들을 운영하고 있고 사회 초년생인 저에게는 버거운 비용인 게 사실입니다.
현실적인 고민이 생기고 있지만, 할 수 있는 데까지는 계속 운영해보려고 합니다.
1년 넘게 애정을 쏟아 만든 서비스라 쉽게 종료한다는 결정을 내리긴 어렵습니다.
하지만 아마 이런 고민과 과정을 통해 제가 조금씩 더 성장해가는 것 아닐까 싶습니다.
앞으로도 실버리즘을 통해 배운 것들을 바탕으로
더 나은 서비스, 더 단단한 시스템을 만들어가고 싶습니다.
실버리즘
요양기관 인공지능 차량 운행표 작성 서비스
www.silverithm.co.kr