올 봄, 휠 타이어 세트를 중고 장터에 올리려고 했다. 사진을 찍고 글을 쓰다가 막혔다. 이 부품, 언제 산 거더라?
스마트폰 사진첩을 뒤졌다. 영수증은 어디에 뒀는지 기억이 안 났다. 결국 “2년쯤 됐을 거예요” 같은 모호한 설명으로 글을 올렸고, 거래는 미적지근하게 흘러갔다.
그 일이 직접적인 계기였다. 차량에 손댄 기록을 한 곳에 정리해 두는 도구가 필요했다. 그리고 찾아본 결과, 마땅한 게 없었다. 그래서 직접 만들었다. 이 글은 그 과정의 기록이다.
기존 앱들을 찾아본 결과 — 정비 이력은 다들 약하다
먼저 정직하게 적는다. 나는 기존 차계부 앱을 진지하게 써본 적이 없다. 차량 관련 앱 시장을 둘러본 건 “내가 만들기 전에 이미 있나”를 확인하려는 탐색이었다. 구글 플레이 검색·앱 소개 페이지·후기 정독이 전부였고, 실제로 깔아서 한 달씩 굴려본 건 아니다.
탐색해 보니 차량 관련 앱은 크게 두 갈래였다.
1) 차계부 앱
주유비·세차비·보험료 같은 비용 기록이 중심. UI도 가계부에 가깝다. 부품 단위 이력은 “정비” 카테고리에 한 줄 메모로 들어가는 정도. 어떤 머플러를 언제 어떤 가게에서 얼마에 달았고, 다음에 교체할 시기가 언제인지를 부품 단위로 관리하기엔 구조 자체가 안 맞았다.
2) 정비소·딜러 연결 앱
정비소 예약, 견적 비교, 부품 쇼핑 같은 외부 거래가 중심. 차주가 자기 차의 이력을 누적해서 보는 용도가 아니었다.
내가 원한 건 둘의 중간이었다. 부품 단위로 장착 시점·가격·정비소를 기록하고, 나중에 그 부품을 거래할 때 한 번에 꺼내 볼 수 있는 형태. 튜닝 차주라면 이 필요가 쉽게 이해될 것이다. 일반 차주라도 타이어·배터리·브레이크 패드처럼 주기적으로 갈아주는 부품은 동일한 문제를 가진다.
이 빈자리가 비어 있다는 게 탐색의 결론이었다. 그래서 만들기로 했다.
만들기로 결정한 시점 — “1인 회사 대표라서 가능했다”
2025년 3월쯤 본격적으로 개발을 시작했다. 이런 종류의 도구는 회사에서 기획안으로 올리면 거의 통과되지 않는다. 시장이 너무 좁기 때문이다. “튜닝 차주 + 부품 이력 관리”는 한국 전체로도 잠재 사용자가 수십만 단위고, 그중 유료로 갈 사람은 훨씬 적다. 회사 제품 매니저(PM, 제품 기획자) 입장에서는 ROI(투자 대비 수익)가 안 나오는 주제다.
하지만 본업을 따로 가진 1인 개발자에게는 다르다. 내가 직접 쓰고 싶은 도구이기 때문에 사용자 0명이어도 가치가 있다. 시장이 좁아도 “내가 사용자 1번”이 보장된다. 그리고 같은 필요를 가진 차주가 한국에 몇 천 명만 있어도 광고와 광고 제거 유료권으로 운영비는 회수된다. 회사가 못 만드는 도구를 1인 회사 대표가 본업 사이에 만들 수 있는 이유가 여기 있다. 이 블로그도 같은 맥락의 사이드 프로젝트인데, 왜 SaaS가 아니라 직접 호스팅을 골랐는지는 별도 글에서 정리해 두었다.
스택은 본업에서 익숙한 도구로 골랐다. 프론트엔드는 Next.js 14 + TypeScript + Tailwind CSS, 백엔드와 데이터는 Supabase(인증·DB·파일 저장), 결제는 포트원 V2. 설치형 웹앱(PWA, Progressive Web App) 형태라 앱 스토어 심사 없이 웹 주소로 바로 설치·실행된다. 안드로이드·아이폰·데스크톱에서 같은 코드가 돌아가는 게 1인 개발자에게는 큰 장점이다.
새 도구 학습 비용을 최소화해야 퇴근 후 시간으로 진행이 됐다. 처음부터 두 가지 플랫폼을 따로 만들 여력은 없었다.
만들다 보니 차계부 기능까지 들어갔다
처음 설계는 단순했다. 부품 등록 → 장착 시점·가격·정비소 기록 → 사진 첨부. 딱 이 정도였다.
그런데 만들기 시작하니 자연스럽게 기능이 자라기 시작했다.
부품 가격을 기록하려면 결제 수단을 같이 적게 된다. 정비소 정보를 적으면 그 정비소에서 다음에 또 정비를 받을 때 검색이 필요해진다. 머플러를 갈았는데 그날 주유도 같이 했다면 주유 영수증도 같이 들어와야 자연스러워진다.
이 흐름을 따라가다 보니 결국 일반 차계부 앱이 가진 기능 대부분이 들어가게 됐다. “차계부 앱을 만들겠다”고 시작한 게 아니라, 부품 이력 관리 앱을 만들다 보니 차계부 영역까지 자연스럽게 넓어진 것이다.
이게 흥미로운 점이다. 기존 차계부 앱들은 비용 기록에서 시작해서 정비 이력은 약하게 끝났다. CarLog는 부품 이력에서 시작해서 비용 기록까지 자연스럽게 흡수했다. 출발점이 다르면 결과 구조가 다르다. 어느 쪽이 정답인지는 사용자마다 다르겠지만, 적어도 “내 부품들을 거래 가능한 형태로 관리하고 싶다”는 필요에는 후자가 더 맞는다고 본다.
1인 개발자가 결제 붙이는 현실
만드는 것보다 어려운 게 결제 연동이었다.
광고만 붙일 거면 며칠이면 끝난다. 하지만 웹에서 직접 결제를 받으려면 결제 대행사(PG, Payment Gateway)의 가맹점 심사를 통과해야 한다. 1인 개발자에게 PG 심사는 만만치 않다. 사업자 등록증·통장 사본·서비스 화면·환불 정책 페이지·이용 약관 같은 서류 묶음이 필요하고, 심사 담당자가 보내는 보완 요청에 며칠씩 답변해야 한다.
CarLog의 PG 심사는 4월에 신청해서 이 글을 쓰는 시점 기준 막바지에 와 있다. 승인이 나오면 정식 결제가 활성화되고 출시 준비가 마무리된다. PG 심사 통과 과정에서 배운 구체적인 내용은 별도의 글에서 다룰 예정이다.
그래서 — CarLog는 어떤 도구가 됐나
지금 CarLog는 다섯 가지 축으로 정리된다.
- 부품 단위 이력 관리 — 머플러·휠·서스펜션 같은 부품을 각각 등록하고 장착일·가격·정비소·사진을 묶어 보관
- 상태 자동 전환 — 장착 기록을 남기면 “장착 중”, 탈거를 남기면 “보관 중”, 판매를 남기면 “판매 완료”로 부품 상태가 알아서 흐름
- 판매글 자동 생성 — 보관 중인 부품을 고르면 네이버 카페·당근마켓·번개장터 각 플랫폼 양식에 맞춘 판매글 초안이 바로 만들어짐 (이게 가장 강력한 차별점)
- SNS 공유 카드 자동 생성 — 장착 완료 사진을 1:1(피드)·9:16(스토리)·4:5(인스타) 비율로 워터마크 포함해 자동 합성
- 차계부 기능 — 주유·충전·정비·세차·기타 비용을 같이 기록. 월별 추이와 연비도 같이 계산
처음 출발점인 “부품을 거래하려고 할 때 이력이 있어야 한다”는 필요는 결국 풀렸다. 그리고 그 김에 일상적인 차량 관리도 같이 풀렸다. 부품 이력을 모은다는 것 = 결국 그 부품을 거래로 보낼 때 가장 자연스럽다는 깨달음이 판매글 자동 생성으로 이어졌고, 차주들이 가장 시간을 많이 쓰는 작업이 사실 글쓰기였다는 점도 만들면서 확인했다.
마무리 — 접속 안내
CarLog는 PG 심사 마무리 후 정식 운영을 시작한다. 설치형 웹앱이라 앱 스토어 다운로드 없이 carlog.tunefit.net에 접속만 하면 바로 쓸 수 있다. 스마트폰 브라우저에서 “홈 화면에 추가”를 누르면 앱 아이콘처럼 설치된다.
이 글의 다음 편은 두 가지 방향 중 하나로 갈 예정이다. PG 심사 통과까지의 실제 과정, 또는 CarLog 기술 스택 회고. 둘 중 어느 쪽이 궁금한지 댓글로 알려주면 그쪽을 먼저 쓴다.
1인 회사 대표가 본업 사이에 자기 가려운 곳을 직접 긁어서 만든 도구가 어떻게 돌아가는지, 그 과정의 기록이 비슷한 입장의 1인 개발자에게도 참고가 됐으면 한다. 같은 결로, 1인 개발자가 SEO 도구 안 사고 6주 운영해본 기록도 함께 보면 흐름이 이어진다.