여행 가이드 앱 — 본업 옆에 자란 작은 프로젝트가 가르쳐 준 것

ERP를 만드는 와중에 개인 여행 가이드 앱을 따로 만들었습니다. 본업과 무관해 보이지만, 같은 서버 위에서 나란히 돌아가며 의외의 교훈을 줬습니다 — 인프라를 잘 갖춰 두면, 새 제품 하나를 얹는 비용이 얼마나 작아지는가에 대하여. 이 글은 “잘 만든 인프라의 진짜 가치는 어디서 드러나는가”에 대한 이야기입니다.

ERP를 만들던 같은 인프라 위에 얹은 개인 여행 가이드 앱. '우리 가족 대탐험' 홈 — 출발 D-112 카운트다운, 현지 날씨, 방문 도장 모으기까지. 새 제품 하나를 얹는 비용이 얼마나 작아졌는지를 보여 주는 증거입니다.

1. 본업 옆에 자란 사이드 프로젝트

여행 가이드 앱은 ERP와 직접적 관련이 없는 개인 프로젝트였습니다. 그런데 이걸 별도 서버에 새로 띄우지 않고, ERP가 돌아가는 같은 서버 위에 나란히(co-tenant) 올렸습니다. 한 서버에서 서로 다른 두 제품이 각자의 영역으로 격리된 채 공존하는 구조입니다. 이 앱도 현재 완성 단계로 본다는 것이 CEO의 판단입니다(1인 개발 단계).

용어: co-tenant (공동 입주)

하나의 서버(또는 한 대의 컴퓨터) 위에 서로 무관한 여러 서비스가 함께 살아가는 것입니다. 한 건물에 여러 세입자가 각자의 호실에 사는 것과 같습니다. 자원(전기·수도에 해당하는 CPU·메모리)은 공유하되, 생활 공간(서비스 경계)은 분리돼 있습니다.

2. 왜 같은 서버에 얹었나

ERP를 만들면서 이미 서버·프록시·배포 파이프라인·데이터베이스를 갖춰 뒀습니다. 새 앱을 위해 이 모든 걸 처음부터 다시 세팅하는 건 낭비였습니다. 핵심 장치는 리버스 프록시였습니다.

용어: 리버스 프록시(reverse proxy)

바깥에서 들어오는 요청을 받아, “이건 A 서비스로, 저건 B 서비스로” 갈라 주는 교통정리 담당입니다. 건물 1층의 안내 데스크처럼, 방문객을 알맞은 호실로 안내합니다. 도메인이나 주소에 따라 트래픽을 알맞은 서비스로 보냅니다.

리버스 프록시가 도메인별로 트래픽을 갈라 주니, 새 서비스 하나를 추가하는 건 사실상 **“프록시 규칙 한 줄과 프로세스 하나”**면 충분했습니다. 건물은 이미 서 있고, 안내 데스크에 “새 세입자 한 명, OO호” 한 줄만 추가하는 셈입니다.

한 서버 안에서 리버스 프록시가 트래픽을 ERP와 여행 앱으로 가릅니다. 둘은 서로를 전혀 모른 채 각자의 영역에서 삽니다. 새 앱을 얹는 비용 = "프록시 규칙 한 줄 + 프로세스 하나".

참고

여러 서비스를 한 서버에 공존시키면 자원을 공유해 비용이 낮아지고, 한 번 다듬어 둔 배포·모니터링 노하우를 그대로 재사용할 수 있습니다. 단, 한 서비스의 장애나 자원 폭주가 옆 서비스에 영향을 줄 수 있으니, **서비스 간 경계(영역·프로세스 격리)**는 분명히 해야 합니다. 여행 앱과 ERP는 서로를 전혀 모른 채 같은 땅 위에서 각자 살았습니다 — 이 “서로 모름”이 안전의 핵심입니다.

3. 작은 앱이 검증한 것 — 인프라의 건강검진

사이드 프로젝트는 본업 인프라의 “리허설”이기도 했습니다. 새 제품을 빠르게 얹어 보는 경험은, 우리 인프라가 정말로 재사용 가능하고 확장 가능한가를 시험하는 자리였습니다.

여기엔 숨은 진단 가치가 있습니다. 만약 새 앱 하나 올리는 게 며칠씩 걸렸다면, 그건 인프라가 특정 제품(ERP)에 너무 강하게 묶여 있다는 신호였을 것입니다. 좋은 인프라는 그 위에 무엇을 올리든 받아 줘야 합니다. 다행히 여행 앱은 가볍게 올라갔고, 그건 인프라가 건강하다는 증거였습니다.

새 서비스를 얹는 비용	상대적 부담
건강한 인프라	규칙 한 줄 (짧음)
묶여 있는 인프라	며칠 (김)

새 서비스 하나를 얹는 데 드는 비용이 그 인프라의 건강을 말해 줍니다. 짧을수록 건강합니다.

새 앱을 얹을 때	건강한 인프라	특정 제품에 묶인 인프라
서버 준비	이미 있음 (재사용)	새로 세팅
트래픽 분배	프록시 규칙 한 줄	설정 전반을 다시
배포·모니터링	기존 노하우 그대로	처음부터 다시 익힘
걸리는 시간	며칠 이내	막연히 길어짐

이 표가 곧 진단 도구입니다. 오른쪽 칸에 자꾸 해당된다면, 그건 인프라가 본업 제품 하나에만 최적화돼 다른 걸 받아 줄 유연성을 잃었다는 신호입니다. 여행 앱은 왼쪽 칸으로 깔끔히 떨어졌고, 그게 인프라가 건강하다는 조용한 증거였습니다.

4. 제조업 회사가 여행 앱을?

“배터리 만드는 회사가 왜 여행 앱을?”이라고 물을 수 있습니다. 답은 단순합니다 — AI와 협업하면 한 사람이 만들 수 있는 제품의 폭이 넓어집니다. 인프라가 갖춰져 있고 AI가 코드를 빠르게 써 주면, 새로운 아이디어를 시험하는 비용이 극적으로 낮아집니다.

여정 화면. 11박 12일 일정을 날짜별로 펼치고, 각 장소에 지도·길안내·'예약 필수' 표시까지 붙였습니다. 본업과 무관해 보이는 앱이지만, 같은 서버·같은 패턴으로 빠르게 완성됐습니다.

여행 앱은 그 **“1인이 여러 제품을 동시에”**라는 가능성의 작은 증거였습니다. 본업(배터리·BMS)을 하면서도, 인프라와 AI라는 두 지렛대 위에서 곁가지 제품 하나를 가볍게 띄울 수 있다는 것. 이게 작은 조직이 AI 시대에 얻는 새로운 자유입니다.

두 지렛대 — 인프라와 AI

이 가벼움이 가능했던 건 두 개의 지렛대가 동시에 받쳐 줬기 때문입니다. 하나만으로는 부족합니다.

• 인프라 지렛대 — 서버·프록시·배포·DB가 이미 서 있으니, 새 앱의 “땅값”이 0에 가깝습니다. 한 번 잘 닦아 둔 길을 계속 재사용합니다.
• AI 지렛대 — 앱의 실제 코드를 AI가 빠르게 써 주니, 아이디어에서 동작하는 결과물까지의 거리가 짧습니다.

두 지렛대가 곱해지면, “1인이 본업 외에 곁가지 제품 하나를 더”가 무모한 욕심이 아니라 현실적 선택이 됩니다. 예전엔 새 제품 하나가 “팀 하나, 서버 하나, 몇 달”을 뜻했습니다. 지금은 “기존 인프라 + AI + 며칠”일 수 있습니다. 이 차이가 작은 조직에 주는 자유는 생각보다 큽니다.

팁

흔히 사이드 프로젝트를 “본업에서 한눈파는 비용”으로만 봅니다. 하지만 잘 격리해 두면, 사이드 프로젝트는 내 인프라가 정말 재사용 가능한지를 공짜로 알려 주는 건강검진이 됩니다. 가볍게 올라가면 건강, 며칠씩 걸리면 경고. 본업을 해치지 않으면서 인프라의 상태를 읽는 좋은 신호입니다.

교훈

잘 갖춘 인프라의 진짜 가치는 **“다음 제품을 얼마나 싸게 얹을 수 있는가”**로 드러납니다. 새 서비스 하나를 추가하는 게 프록시 규칙 한 줄로 끝난다면, 그 인프라는 건강한 것입니다. 사이드 프로젝트를 같은 서버에 공존시키는 건 비용을 아끼는 동시에, 내 인프라가 특정 제품에 갇혀 있지 않은지 검증하는 좋은 시험입니다. 단, 서비스 간 경계는 처음부터 분명히 그어 두세요 — 한 세입자의 사고가 옆집까지 번지지 않게.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.