작은 팀이 제품을 매주 내보내는 방법: Claude Code, 서버 한 대, 그리고 운영 숫자

저스티스라이크버드(justicelikebird)는 큰 팀이 아닙니다. 그런데도 실거미는 공개 이후 거의 매일 바뀌었고, '5년 뒤를 생각해'는 두 달 만에 베타에 들어갔습니다. 비결은 특별하지 않습니다. 도구 하나와 원칙 하나입니다.

01도구: Claude Code

세 제품의 코드는 Claude Code로 씁니다. 기획 메모를 주고 화면을 받고, 버그 로그를 주고 수정을 받습니다. 사람이 하는 일은 무엇을 만들지 정하고, 결과를 보고, 아니라고 말하는 것입니다. 이 방식의 진짜 효과는 속도가 아니라 작게 만들 수 있다는 것입니다. 기능 하나를 만드는 비용이 낮아지면, 크게 기획하고 한 번에 내보낼 이유가 없어집니다. 작게 만들고, 올리고, 숫자를 보고, 다음 것을 만듭니다.

02인프라: 서버 한 대

실거미, 회사 홈페이지, '5년 뒤를 생각해'는 모두 서버 한 대에서 돌아갑니다. 메모리 2GB짜리 작은 서버입니다. 빌드는 로컬에서 하고 결과물만 올립니다. 데이터베이스는 파일 하나입니다. 트래픽이 커지면 바꿔야 하겠지만, 지금 단계에서 복잡한 인프라는 비용이 아니라 속도를 잡아먹습니다. 실거미의 AI 편집 비용은 하루 몇백 원, '5년 뒤'의 응원 문구 시제품은 하루 몇십 원입니다.

03원칙: 만든 사람이 운영한다

도구보다 중요한 건 이 원칙이었습니다. 만든 사람이 매일 쓰고, 통계를 보고, 서버 로그를 읽습니다. 그러면 고칠 것이 보고서 없이 보입니다. 순위에 오래된 기사가 붙어 있는 것, 봇이 통계를 부풀리는 것, 로그아웃이 안 되는 것. 전부 운영하면서 발견했고 그날 고쳤습니다. 기획-개발-운영이 분리된 조직이었다면 각 문제는 티켓이 되어 몇 주를 기다렸을 겁니다.

04솔직한 상태 표기

마지막으로, 우리는 제품의 상태를 있는 그대로 씁니다. 운영 중, 베타, 개발 중. 없는 기능을 있다고 쓰지 않고, 계획을 성과처럼 말하지 않습니다. 작은 팀이 신뢰를 얻는 방법은 큰 숫자가 아니라 정확한 숫자이기 때문입니다.