¶ 0권 — 시리즈 소개: 성장 단계로 읽는 개발 조직 만들기 로드맵
스타트업이나 중소 개발 조직을 운영하다 보면 다음과 같은 질문을 끊임없이 마주치게 된다.
- "우리 회사도 이제 Jira를 써야 하나"
- "CI/CD는 언제부터 갖춰야 하나"
- "AWS로 옮겨야 할 시점인가"
이 시리즈는 이런 질문에 획일적인 정답을 주는 대신, "우리 조직은 지금 어느 성장 단계에 있는가"를 먼저 진단하고, 그 단계에 맞는 도구·프로세스·인프라를 고르는 판단 기준을 제공하는 것을 목표로 삼는다.
다음 두 가지 모두 "단계에 맞지 않는" 선택이라는 문제의식에서 이 시리즈는 출발한다.
- 5명짜리 팀에 대기업 수준 MSA·쿠버네티스를 들이미는 것
- 50명 조직이 여전히 스프레드시트로 이슈를 관리하는 것
¶ 성장 5단계 + 선택적 심화 트랙이라는 구조
시리즈는 팀 인원수나 투자 라운드가 아니라 "무엇을 갖추어야 다음 문제가 풀리는가"를 기준으로 조직 성장을 5개 부(部)로 나눈다.
- 1부 시작하기: 막 팀을 꾸린 단계. 공식 절차가 없고 빠른 의사결정이 강점이자 비효율의 원인이 되는 시기다.
- 협업 도구 도입 (1권)
- 최소한의 팀 규칙 수립 (2권)
- 2부 만들 준비하기: 제품을 실제로 세상에 내놓을 준비를 갖추는 단계.
- GitHub 기반 브랜치 전략·PR 워크플로 (3권)
- 무료/저비용 서비스로의 배포 (4권)
- 3부 만들기: 제품 개발이 본격화되고 팀이 커지며 프로세스와 인프라 없이는 확장이 불가능해지는 단계.
- 개발 방법론 정의 (5권)
- API 설계·관리 원칙 (6권)
- CI/CD 파이프라인 (7권)
- 이슈·버그 관리 (8권)
- 본격 클라우드 전환 (9권)
- 4부 잘 만들기: 서비스가 커지며 안정성·비용·운영 복잡도가 새로운 문제로 떠오르는 단계.
- 모놀리식에서 MSA로의 분리 (10권)
- 쿠버네티스 도입 (11권)
- 클라우드 비용 관리 (12권)
- 모니터링·관측 체계 (13권)
- 장애 대응과 포스트모템 문화 (14권)
- 5부 성장하기: 조직으로서 지속 가능하게 성장하기 위한 문화·제도의 단계.
- 회고 문화 (15권)
- AI 활용 극대화 (16권)
- 기술부채 관리 (17권)
- 외부 R&D 과제 수행 (18권)
- 품질 인증과 개발비 관리 (19권)
여기에 더해 6부 직접 구축하기는 성장 단계 축과 성격이 다른 선택적 심화 트랙이다. 5부 다음에 자동으로 오는 단계가 아니라, SaaS·무료 서비스로 시작했던 조직이 비용·보안·데이터 주권·커스터마이징 필요 등 조직마다 다른 이유로 자체 인프라 전환을 실제로 검토하게 될 때만 참조하는 서가다.
- 형상관리 자체 구축 (20권)
- 자체 GitLab 기반 CI/CD (21권)
- 자체 개발·테스트 환경 (22권)
- 지식관리시스템 자체 구축 (23권)
"모든 조직이 언젠가 반드시 거쳐야 하는 단계"가 아니라는 점을 반복해서 강조한다.
¶ 시리즈를 관통하는 예시 프로젝트: TodoBox
이번 개정(v3)부터 24권 전체를 하나로 꿰는 가상의 예시 프로젝트 TodoBox가 도입되었다. TodoBox는 개인용 할 일 관리 웹 서비스다. TodoBox가 거쳐 가는 성장 단계는 다음과 같다.
- 초기: Next.js 풀스택 구조로 가볍게 배포 (1~4권)
- 팀이 3~5명으로 늘며 표준화 단계 진입 (5~8권)
- 트래픽 증가로 본격적인 클라우드 인프라로 확장 (9권)
- 서비스 분리 (10권)
- 쿠버네티스 도입 (11권)
- 자동 감지 체계 (13권)
- 성숙 단계 과제: 비용 관리·장애 대응·회고·기술부채 정리 (12·14·15·17권)
각 권을 읽을 때 TodoBox가 어느 단계에 있는지 짚어보면 실제 조직의 성장 과정을 대입해 이해하기 쉽도록 설계되었다.
¶ 조직 규모별 실제 활용 예시
시리즈는 "어떤 순서로 읽을지"에 대한 일반 원칙을 제시한다.
- 순서대로 읽기
- 자기 단계부터 골라 읽기
- 6부는 필요할 때만 참조
여기에 더해 규모별 구체적 시작점도 제시한다.
| 조직 규모 | 필요해지는 권 | 비고 |
|---|---|---|
| 1~10명 스타트업 | 1권 → 2권 (협업 도구, 최소 규칙) → 3권 → 4권 (GitHub 워크플로, 무료 클라우드 배포) | CI/CD 체계·API 관리·MSA·쿠버네티스·회고 제도화·자체 인프라는 대부분 시기상조 |
| 20~30명 규모 | 배포 충돌과 수동 배포 실수 증가로 5권(개발 프로세스)·7권(CI/CD)·8권(이슈 관리)이 필요해지고, 트래픽 증가로 9권(클라우드 확장)과 10~14권(MSA·쿠버네티스·비용·모니터링·장애 대응)까지 순차적으로 현실적인 과제가 됨 | SaaS 종량제 비용이 가파르게 늘거나 보안·데이터 주권 우려가 커질 경우 20권·23권 같은 6부 항목도 검토 대상에 오름 (조건이 맞을 때만 선택하는 트랙이라는 원칙은 변하지 않음) |
¶ 각 권의 공통 구조와 핵심 원칙
24권 모두 동일한 4단계 구조를 따른다.
- 왜 필요한가 — 도입하지 않을 때 생기는 문제
- 언제 도입할 것인가 — 검토를 시작해야 할 조직의 신호
- 어떻게 시작할 것인가 — 공식 문서·사례 기반 실행 절차
- 흔한 실수와 함정
이는 독자가 어느 권을 펼치더라도 같은 흐름으로 필요한 정보를 찾을 수 있게 하기 위한 장치다.
시리즈가 반복해서 강조하는 핵심은, 조직이 겪는 문제가 크게 두 방향에서 온다는 것이다.
| 유형 | 설명 |
|---|---|
| 과잉 엔지니어링 | 아직 오지 않은 규모와 트래픽을 가정해 미리 복잡한 체계를 갖추는 것 |
| 너무 늦은 정비 | 이미 문제를 겪고 있는데도 체계 없이 버티다가 장애나 고객 이탈 같은 더 큰 비용을 치르는 것 |
원인은 다르지만 결과는 같다 — 팀의 시간과 에너지가 제품이 아닌 곳으로 새어 나간다는 것.
시리즈는 또한 스스로 다루지 않는 것과 스스로를 규정하는 원칙을 분명히 한다.
- 특정 회사의 내부 작업 이력이나 구체적 설정값·데이터는 다루지 않는다
- "무조건 이렇게 하라"는 단정 대신 상황별 판단 기준을 제시한다
- 근거 없는 수치를 지어내지 않고 공개 자료를 인용·출처 표기한다
- 조직을 대신해 결정을 내려주는 컨설팅 보고서가 아니라, 실무자가 스스로 판단·실행하도록 돕는 참고서로 스스로를 규정한다
¶ 참고할 만한 사례
- 37signals는 클라우드에서 자체 인프라로 전환해 연간 인프라 비용을 상당폭 절감했다고 밝힌 바 있다.
- 블레임리스 포스트모템 문화는 Google SRE 사례에서 체계적으로 정리되어 있다.
- GS인증은 국제표준 기반의 소프트웨어 품질 인증 제도로, 조달청 단가계약 등의 혜택이 따른다.
- 스타트업 성장 단계별 개발팀 구성 변화는 여러 스타트업 사례에서 공통으로 관찰된다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.