1년간 SaaS 유지보수 실무 경험기

지난 1년여간 saas 서비스 운용 및 유지보수 개발을 ‘cursor ai’ 기반 프로젝트 환경에서 경험했던 경험을 나누고자 합니다.

비개발자로 웹디와 플젝 구축 경험은 있지만 깊지 못해 고전하다 ai가 기회다 싶어 자체 플젝을 꾸역꾸역 혼자 운영 중인 늦깍이 1인 창업자입니다. 첨엔 깃이 뭔지 배포가 뭔지, DB마이그레이션이 뭐고 기술스택이 뭔지 헤매고 사고 몇 번 터져 멘붕을 오락가락 하다보니 경험치가 누적되어 안정기에 접어들었다 판단됩니다.

23년 즈음 원팀웍스(1teamworks.com)라는 saas형의 도급현장 업무관리와 팀기반 협업서비스인데 조금씩 기능을 늘리다보니 비대해지며 유지공수는 증가함에 비해 수익은 크지않아 결국 외주 개발자를 정리하고 직접 관리했던게 계기가 되었습니다.

25년 초 때마침 ai의 바이브코딩 실력이 고도화됨을 목도했기에 정말 직접 개발해보자 맘 먹었고, 몇가지 툴과 LLM모델을 마구잡이로 써보고 결과물의 품질을 경험하니 뚜렷한 확신이 들기 시작해 본격적으로 유료결제에 도전했습니다.

커서 ai IDE 환경에서 초반에 고사양 언어모델로 상당한 토큰을 소비했는데 결과물이 시원치 않았답니다. 레딧과 유툽을 통해 나만의 AI 플로우를 만들어 보려고 애 쓰다보니 요구 아젠다 별 난이도에 맞춘 단계별 모델(하이쿠4.5=70%, 컴포저2=20%, 소넷4.6=10% / 월 15~ 20만원 전후) 운용 사이클을 찾아냈고 조합 효율이 확실히 토큰소비량을 현저하게 줄이는 모양새입니다. 대신 개발단위를 쪼개 자동화 아닌 인간개입 필수입니다.

초기 PRD작성과 프로젝트 절대 규칙(커서롤 루트 내 상세 지침) 구성과 핵심 서브에이전트 구현에 많은 시간을 들인것이 현재의 안정적 운용성 확보에 유효했던 걸로 판단됩니다. 프로젝트의 지침을 기능 별로 쪼개고 컨택스트 윈도우 한계를 고려해 기능 내 모듈 단위로도 지침 분화시켰고 현재도 지속적으로 보완중입니다.

그래도 여전히 기존 운용성과 토큰절약 가능성에 방법론을 기웃거리다가 최근 ‘하네스 워크플로우’형태의 에이전트 시스템으로 반자동화된 코딩 파이프 라인을 구축하고 초반 운용합니다. 확실히 요구 아젠다와 배경되는 전체 로직 맥락을 잘 유지하면서 만족스러운 구현결과를 보여줍니다.

--

개발 스택

-FrameWork : sveltekit

-Programming language : typescrip