'1인 개발로 SaaS를 만든다'는 말은 이제 어렵지 않게 들린다. 하지만 실제로 670개 이상의 커밋을 쌓고, OCR·다중 테넌트 격리·Kafka 이벤트 흐름까지 갖춘 금융 플랫폼을 혼자 프로덕션에 올린 사람의 이야기는 다르다. Dev.to에 올라온 한 DevOps 엔지니어의 회고록이 흥미로운 이유는 '어떤 AI를 썼냐'가 아니라 '언제 어떤 AI를 썼냐'를 정직하게 기록했기 때문이다.
모델은 만능이 아니라 전문가다
그의 결론은 단순하다. 모델마다 잘하는 영역이 뚜렷하게 다르다. Gemini Advanced는 React 대시보드와 데이터 테이블 컴포넌트를 짤 때 '레이아웃 감각'이 좋았다. 반면 FastAPI 백엔드의 복잡한 리팩토링이나 다중 테넌트 격리 버그를 추적할 때는 '표면적인 이해'에 그치는 느낌이었다고 한다. Claude Pro로 전환한 이후 달라진 점은 하나였다—코드의 의도를 읽는다는 것. 함수 하나를 붙여넣어도 전체 아키텍처 맥락에서 어디가 깨졌을지를 먼저 추론했다. 빠른 보일러플레이트 생성에는 Windsurf SWE-1.5와 Grok Code가 충분했고, OCR처럼 정확도가 비즈니스 임팩트와 직결되는 영역에서는 무료 모델의 80% 정확도가 실전에서 얼마나 비싼 대가인지를 직접 경험했다.
그가 정리한 역할 맵은 이렇다.
| 태스크 | 선택 모델 |
|---|---|
| 버그 추적·리팩토링 | Claude Pro |
| UI·프론트엔드 컴포넌트 | Gemini |
| 빠른 코드 생성·보일러플레이트 | Windsurf SWE-1.5 / Grok Code |
| 로컬·프라이빗 작업 | Ollama (속도 여유 있을 때) |
| 리서치·긴 컨텍스트 읽기 | Gemini / Mistral |
| 대규모 OCR | 유료 모델 필수 |
이 표가 단순한 벤치마크처럼 보일 수 있지만, 실제로는 비용·속도·품질의 트레이드오프를 실전에서 체화한 결과물이다.
컨텍스트 손실이 진짜 병목이다
모델 선택 다음 문제는 세션 관리다. Dev.to에 공유된 또 다른 실전 워크플로우는 Claude Code를 기반으로 하는데, 핵심 인사이트는 예상외로 단순하다—컨텍스트는 대화 히스토리가 아니라 파일에 저장해야 한다. Claude Code는 세션이 길어질수록 앞서 결정한 내용을 잊거나 이미 만든 코드를 다시 생성하는 '컨텍스트 드리프트'가 발생한다. 이를 막는 방법으로 SPEC.md 패턴이 제안된다.
흐름은 이렇다. 먼저 플랜 모드(Shift+Tab)에서 기능 요구사항을 논의하고, 접근 방식과 결정 사항이 확정되면 SPEC.md로 저장한다. 이후 새 세션을 시작할 때마다 @SPEC.md Continue from the next unchecked task. 한 줄로 AI를 정확한 지점에서 재개한다. /clear는 컨텍스트를 잃는 게 아니라 노이즈를 제거하고 신뢰할 수 있는 소스 오브 트루스로 초기화하는 행위라는 관점의 전환이 흥미롭다.
SPEC.md가 실용적인 이유는 AI만을 위한 도구가 아니기 때문이다. 팀원이 중간에 합류할 때 온보딩 문서가 되고, PR 설명 템플릿이 되며, 몇 달 뒤 디버깅할 때 '왜 localStorage를 선택했는가'를 추적하는 기록이 된다. 스펙을 쓰는 습관은 AI보다 오래된 엔지니어링 원칙이고, AI 시대에 오히려 더 중요해졌다.
도구 선택의 또 다른 축: 프라이버시와 거버넌스
1인 개발자의 워크플로우와는 결이 다른 문제지만, 팀 단위로 AI 코딩 어시스턴트를 도입할 때 GitHub Copilot과 Tabnine 비교는 이 역할 분리 프레임에 또 다른 축을 추가한다. Copilot은 GPT-4o·Claude Opus 4·Gemini 같은 프론티어 모델을 활용해 완성도 높은 코드 제안을 제공하지만, 코드가 외부 클라우드를 경유한다. Tabnine은 완성도보다 데이터 주권을 선택한 제품으로, 온프레미스·에어갭 배포를 지원하는 유일한 메인스트림 도구다. 금융·의료·국방 도메인에서 Tabnine이 선택받는 이유가 여기 있다.
1인 개발자에게 이 비교가 의미하는 것은 다르다. 같은 Claude Opus 4를 쓰더라도 어떤 레이어에서 접근하느냐—직접 API, Copilot 번들, 혹은 Claude Code 직접 실행—에 따라 컨텍스트 관리 방식과 비용 구조가 달라진다. 도구를 고르는 것은 곧 워크플로우의 제약 조건을 고르는 일이다.
AI 제한이 오히려 생산성을 높인다는 역설
YourFinanceWORKS를 만든 개발자가 남긴 가장 예상치 못한 인사이트는 Claude의 사용량 제한에 관한 것이었다. 처음엔 불편했지만, 결국 이 제약이 '생각 없이 AI에 쿼리를 던지는 습관'을 끊어줬다고 한다. 질문을 보내기 전에 스스로 먼저 생각하게 되었고, 실제로 문제 해결 능력이 회복됐다는 것. 무한한 자동완성이 오히려 개발자의 추론 근육을 약화시킬 수 있다는 경고는, Copilot vs Tabnine 비교에서 '완성도'를 최우선 기준으로 삼는 시각에 균형추를 제공한다.
시사점: 도구 스택이 아니라 역할 설계가 먼저다
세 가지 소스를 교차하며 드러나는 공통 원칙은 하나로 수렴한다. AI를 잘 쓴다는 것은 가장 좋은 모델 하나를 고르는 게 아니라, 각 모델의 강점을 역할로 고정하고 그 역할 간 전환 비용을 최소화하는 설계를 하는 것이다. Claude가 의도를 읽고, Gemini가 레이아웃 감각을 채우고, Windsurf가 반복 작업을 흡수하는 구조—그리고 SPEC.md가 이 모든 세션을 하나의 맥락으로 묶는 역할을 한다.
전망: '1인 팀'이라는 새로운 단위
1인 개발자가 다중 테넌트 SaaS를 프로덕션에 올리는 시대는 이미 왔다. 다음 질문은 이 구조가 얼마나 유지 가능한가다. 기술적 복잡도가 쌓일수록 AI 모델만으로는 해결되지 않는 병목—시스템 설계 판단, 보안 아키텍처 검토, 사용자 피드백 해석—이 다시 사람의 몫으로 돌아온다. 도구가 점점 강력해질수록, 역설적으로 어디서 AI를 멈추고 직접 판단할 것인가를 설계하는 능력이 1인 개발자의 진짜 경쟁력이 된다. AI 역할 분리는 워크플로우의 효율 문제가 아니라, 지속 가능한 1인 프로덕트의 아키텍처 문제다.