1인 개발자가 클로드코드로 SaaS 11개 만든 기록

2026년 10월 20일 · @martin

기획부터 배포·운영까지 혼자 맡으며, AI에게 맡긴 일과 직접 챙긴 일을 어떻게 나눴는지 정리합니다.

다시 코드를 잡기까지

PHP를 26년 가까이 다뤘습니다. CodeIgniter 책을 쓰고, CI Korea 포럼을 운영하고, 여러 행사에서 강연도 했습니다. 그러다 한동안 현업 개발에서 손을 놓고 있었습니다.

약 1년 전, 클로드코드를 계기로 다시 개발을 시작했습니다. 지금은 파주 집 다락방에서 혼자 AIvance라는 이름으로 SaaS 제품을 만들고 있습니다. 그동안 클로드코드로 만든 솔루션이 11개가 되었습니다.

이 글은 그 과정에서 무엇을 AI에게 넘겼고, 무엇은 끝까지 제 손에 남겨뒀는지에 대한 기록입니다.

무엇을 만들었나

제품 이름은 모두 'AI + 라틴어' 규칙으로 지었습니다. 이름을 정하는 규칙 하나만 있어도 제품이 늘어날 때 정체성이 흐트러지지 않습니다.

제품 라인 밖에서도 "그때그때 생각나서" 만든 것들이 있습니다. varius라는 모노레포에 따로 모아 두었고, 그중 두 개는 실제로 운영 중입니다.

제품보다 기반을 먼저 만들었다

11개를 혼자 만들 수 있었던 가장 큰 이유는 첫 제품 전에 공통 기반부터 깔았기 때문입니다.

ci4-board라는 API 보일러플레이트를 한 달 동안 AI와 함께 만들었습니다. JWT 인증, 구글·카카오·네이버 소셜로그인, API 버저닝, Swagger 문서, 다국어, 통합 테스트 149개가 들어 있습니다. 이후 제품들은 이 위에서 출발했습니다.

같은 방식으로 웹 쪽은 AICreo를 기반으로 삼았습니다. 새 제품인 AILign은 AICreo 위에 기능을 플러그인으로 얹는 구조로 설계했습니다.

인증·로그인·문서화 같은 반복 작업을 매번 새로 시키면 AI도 매번 조금씩 다르게 만듭니다. 기반을 고정해 두니 AI가 할 일이 '제품 고유의 기능'으로 좁혀졌습니다.

AI에게 맡긴 일

기준은 단순했습니다. 정답의 형태가 명확하고, 테스트로 검증할 수 있는 일은 AI에게 넘겼습니다.

• 구현 코드 작성: 명세에 따라 컨트롤러, 서비스, 리포지토리 계층을 작성하는 일
• 테스트 작성과 실행: 테스트는 코드가 바뀔 때마다 자동으로 돌도록 설정했습니다
• 레거시 이식: AILicet의 CI3 코드를 CI4로 옮기는 작업
• 문서화: API 문서, README, 명세 초안 정리
• 반복 설정: 가상호스트, 배포 스크립트, 환경 설정 파일
• 리서치 정리: 경쟁 서비스 비교, 모델별 요금 비교 같은 조사

제품 안의 AI 기능도 같은 원칙을 따랐습니다. AICassa의 세금계산서 파싱은 Claude Vision으로 처리하되, Sonnet을 기본으로 쓰고 실패하면 Opus로 넘기도록 구성했습니다. 이를 위해 CI4에 AiService 계층을 두어 모델을 바꿔 끼울 수 있게 했습니다.

직접 챙긴 일

반대로, 틀렸을 때 되돌리기 어렵거나 사업 판단이 들어가는 일은 직접 결정했습니다. AI는 선택지를 펼쳐주는 데까지만 썼습니다.

• 무엇을 만들지: 부동산 분양관리 아이템은 조사까지 했지만 월정액 모델과 맞지 않아 접었습니다. 철강 ERP는 업계 지인 인터뷰로 검증하는 중입니다.
• 아키텍처의 경계: 웹 채팅 상담 솔루션 AIFid는 처음에 Node.js 풀스택으로 구상했습니다. 검토 끝에 어드민과 상담 API는 CI4, 실시간 전송만 Node.js WebSocket이 맡는 하이브리드로 바꿨습니다.
• MVP 범위: AILign은 계산 엔진까지 욕심내지 않고 '견적서 발행 도구'로 시작하기로 했습니다. 공방 대부분이 감으로 견적을 내는 현실을 봤기 때문입니다.
• 과금과 배포 모델: AILign은 설치형이 아닌 호스팅형으로, 플러그인을 일회성·구독·크레딧으로 판매하는 구조로 정했습니다.
• 보안과 인증 정책: AITessera의 토큰 서명 방식(RSA/ECDSA)과 요청 제한(인증 분당 10회, 일반 분당 120회)은 직접 정했습니다.
• 결제 연동: 토스페이먼츠는 계약 전에 샌드박스로 흐름을 직접 확인했습니다.
• 브랜드: 로고, 제품명, 한 줄 소개는 AI의 시안을 참고하되 최종 선택은 제가 했습니다.

정리하면, AI는 '어떻게'에 강하고 저는 '무엇을, 왜'를 붙잡았습니다.

클로드코드와 일하는 방식

혼자 일하면 "이렇게 해줘"를 매번 반복하게 됩니다. 그 반복을 줄이는 장치를 하나씩 쌓았습니다.

1. 명세 문서 먼저: 새 프로젝트는 코드보다 docs/SPEC.md와 CLAUDE.md(개발지시서)를 먼저 씁니다. AILign은 명세를 v0.3까지 다듬고 나서 개발을 시작했습니다.
2. CLAUDE.md 계층: 모든 프로젝트에 공통인 규칙은 사용자 수준에, 프로젝트 고유 규칙은 프로젝트 수준에 둡니다. 한국어 응답 일관성도 여기서 잡았습니다.
3. 훅: .claude/settings.json에 PreToolUse·PostToolUse 훅을 걸어 테스트가 자동으로 돌게 했습니다.
4. 커스텀 스킬: 반복되는 작업은 스킬로 만들었습니다(아래 표). 첫 스킬은 MSA 공통 에러 응답 규약인 api-error-contract입니다. RFC 9457 Problem Details를 기반으로, 에러 코드를 .. 형식으로 통일했습니다.
5. 서브에이전트와 컨텍스트 관리: 작업 단위를 나누고, 한 세션에 너무 많은 맥락이 쌓이지 않게 관리합니다.

지금 쓰는 스킬들

스킬은 직접 만든 것과 가져다 쓰는 것을 합쳐 10개가 넘습니다. 용도별로 나누면 이렇습니다.

가장 효과가 큰 것은 이슈 사이클 스킬입니다. start-issue, end-issue, prune-branch 같은 작은 스킬을 먼저 만들고, 이를 엮어 dev-issue와 finish-issue라는 상위 스킬을 만들었습니다. 이제 "이슈 231 개발" 한 줄이면 브랜치 생성부터 이슈 종료까지 한 흐름으로 끝납니다.

스킬에는 저장소만의 사정도 적어 둡니다. 예를 들어 feature → dev를 Squash merge로 합치기 때문에 git branch --merged로는 병합 여부를 알 수 없습니다. 그래서 prune-branch에 PR 상태까지 확인하라고 적어 두었고, AI가 이 함정에 빠지지 않습니다.

여러 제품이 같은 에러 형식, 같은 계층 구조를 쓰게 되니 AI가 만든 코드를 리뷰하는 시간이 눈에 띄게 줄었습니다.

varius 모노레포에서는 한 걸음 더 나갔습니다. 루트와 프로젝트마다 CLAUDE.md와 AGENTS.md를 함께 두어, 클로드코드와 Codex 어느 쪽으로 작업해도 같은 규칙을 따르게 했습니다. 규칙을 도구가 아니라 저장소에 두면, 도구를 바꿔도 일하는 방식은 그대로 남습니다.

가장 규모가 큰 AIFid에서는 품질 게이트를 로컬로 끌어왔습니다. 커밋할 때 PSR-12로 자동 정리하고, dev로 푸시할 때 PHPStan(level 6)과 전체 테스트를 돌리며, main으로의 직접 푸시는 막았습니다. 테스트는 작업 폴더마다 별도 DB를 쓰게 해서, 워크트리 여러 개에서 AI가 동시에 테스트를 돌려도 서로의 스키마를 건드리지 않습니다. 이렇게 해서 CI4 백오피스, Node 채팅엔진, React 상담원 콘솔, Preact 위젯으로 이뤄진 구조를 M0부터 M6까지 로드맵대로 마쳤습니다.

배포와 운영도 혼자

서버는 Ubuntu, 스택은 CI4와 PHP 8.2 이상입니다. 개발 도구는 PhpStorm, 품질 관리는 PHPUnit과 PHPStan을 씁니다.

• 로컬 환경: macOS에 Apache 가상호스트를 구성해 여러 프로젝트를 MSA 형태로 로컬에서 함께 띄웁니다.
• CI/CD: Ubuntu 26.04 서버에 GitHub Actions 셀프호스티드 러너를 직접 띄워 테스트를 돌립니다. 통과하면 ED25519 배포 키와 SSH로 운영 서버에 배포한 뒤 spark 명령까지 실행합니다.
• 운영 서버: aivance.kr 아래 creo, copia, cura 같은 서브도메인으로 제품을 나눠 올렸습니다. PHP는 Ondrej PPA로 8.5까지 올렸습니다.
• 장애 대응: 다른 사이트의 가상호스트 ServerAlias 충돌로 aivance.kr이 엉뚱하게 연결된 적이 있습니다. 원인을 좁히는 데 AI 도움을 받았지만, 운영 서버에서 설정을 고치는 것은 직접 했습니다.

배포 파이프라인을 처음 한 번 제대로 만들어 두니, 이후 제품은 같은 방식을 복사해 쓰면 됐습니다.

돌아보며

1년 전 다시 코드를 잡을 때는 혼자서 제품 하나를 끝까지 만들 수 있을지도 확신이 없었습니다. 지금은 제품 11개가 저장소에 있고, 곁가지로 만든 Iter와 Pagus는 실제로 운영 중입니다. 그 사이 분명해진 것들을 정리합니다.

잘 된 것

1. 기반이 속도를 만든다. ci4-board를 만드는 데 한 달을 썼지만, 그 한 달이 이후 모든 제품의 출발점이 됐습니다. AILign은 아예 AICreo 위에 플러그인으로 얹었습니다. 기반을 고정하면 AI의 결과물이 일정해지고, 제품마다 처음부터 다시 시작할 필요가 없습니다.
2. 명세가 곧 지시다. AI에게 잘 시키는 능력은 결국 잘 기획하는 능력입니다. AILign은 명세를 v0.3까지 다듬은 뒤 개발을 시작했고, AIFid는 문서로 정한 M0~M6 로드맵을 그대로 따라 끝냈습니다.
3. 규칙은 대화가 아니라 저장소에 남긴다. 채팅으로 한 당부는 세션이 끝나면 사라집니다. CLAUDE.md, AGENTS.md, 훅, 스킬에 적어 둔 규칙은 다음 세션에도, 다른 AI 도구에도 그대로 이어집니다.
4. 검증은 기계에게, 판단은 사람에게. 코드 정리, 정적 분석, 테스트는 로컬 훅과 셀프호스티드 러너가 빠짐없이 돌립니다. 덕분에 저는 AI가 짠 코드 한 줄 한 줄보다 설계가 맞는지에 시간을 씁니다.

여전히 사람의 몫인 것

1. 되돌리기 어려운 결정. 아키텍처의 경계, MVP 범위, 과금 모델, 보안 정책은 AI가 선택지를 잘 펼쳐줘도 결국 제가 정해야 했습니다.
2. 무엇을 만들지 고르는 일. 조사까지 마치고 접은 아이템도 있습니다. 철강 ERP처럼 현장의 목소리를 들어야 하는 아이템은 지금도 업계 지인 인터뷰로 검증하고 있습니다.
3. 고객을 만나는 일. 만드는 속도는 AI 덕분에 몇 배로 빨라졌습니다. 하지만 고객을 찾고, 쓰게 만들고, 돈을 받는 일은 이제 시작입니다. 다음 기록은 아마 이 이야기가 될 것입니다.

26년의 경험은 어디에 쓰였나

흔히 AI가 경력을 무의미하게 만든다고 합니다. 제 경험은 반대였습니다. 코드를 치는 손은 AI가 대신했지만, 어디서 문제가 터질지 미리 아는 눈은 대신하지 못했습니다. 인증을 어떻게 나눌지, 실시간 처리를 어디까지 PHP로 감당할지 같은 판단은 오래 부딪혀 본 경험에서 나왔습니다. AI는 경험을 대체하지 않았고, 경험이 낼 수 있는 속도를 바꿔 놓았습니다.

지금은 이 경험을 바탕으로 'AI 개발환경 구축 컨설팅'을 준비하고 있습니다. 혼자서도 팀처럼 일하는 방법이 궁금한 분들께 이 기록이 작은 참고가 되었으면 합니다.