신규 합류한 PM에게 팀장이 묻습니다. "이번 기능, 지금 어느 단계예요?" 개발자는 "요구사항은 확정인데 설계 리뷰 중이고, 인프라는 아직 안 붙었어요"라고 답합니다. 인프라 담당인 당신은 "그럼 우리가 언제부터 준비하면 되죠?"가 궁금합니다. 소프트웨어가 기획에서 운영까지 어떤 단계를 거치는지 — 그 전체 지도를 머릿속에 갖고 있어야 "지금 어디"와 "다음 무엇"을 같은 언어로 말할 수 있습니다.
- 1SDLC 6단계(요구→설계→개발→테스트→배포→운영)를 순서와 산출물로 설명할 수 있다
- 2각 단계에서 PM·인프라가 무엇을 준비/확인해야 하는지 짚을 수 있다
- 3결함을 일찍 잡을수록 비용이 줄어드는 "shift-left" 원리를 설명할 수 있다
- 4워터폴과 애자일이 같은 단계를 어떻게 다르게 도느냐를 구분할 수 있다
SDLC 한 장의 지도
요구 → 설계 → 개발 → 테스트 → 배포 → 운영
"지금 어느 단계예요?"에 답하려면 단계들의 이름과 산출물을 알아야 합니다. SDLC(Software Development Life Cycle)는 소프트웨어가 태어나 살아가는 전 과정입니다.
| 단계 | 핵심 활동 | 주요 산출물 | PM·인프라 접점 |
|---|---|---|---|
| 요구사항 | 무엇을 왜 만드나 | PRD·유저스토리·인수기준 | 범위·일정·외부의존 식별 |
| 설계 | 어떻게 만드나 | 아키텍처·API·DB 스키마 | 스택·인프라 자원 산정 |
| 개발 | 구현 | 소스 코드·PR | 개발/스테이징 환경 제공 |
| 테스트 | 의도대로 동작하나 | 테스트 케이스·결과 | 테스트 환경·데이터 |
| 배포 | 프로덕션 반영 | 릴리스·산출물 | 릴리스 전략·롤백·헬스체크 |
| 운영 | 살아있는 동안 유지 | 모니터링·인시던트 기록 | 관측성·온콜·용량 관리 |
이 표의 각 단계는 이 트랙의 나머지 모듈로 깊어집니다 — 요구는 [[requirements-prd]], 설계는 [[architecture-patterns]]와 [[api-contract]], 배포는 [[cicd-pipeline]]과 [[release-strategy]], 운영은 [[slo-error-budget]]. 지금은 전체 지도를 머리에 넣는 것이 목표입니다.
일찍 잡을수록 싸다 — shift-left
결함은 단계가 흐를수록 비싸진다
요구사항 단계의 "우리가 뭘 만들려는지" 오해는, 설계·개발·테스트를 거치며 점점 고치기 어려워집니다. 운영 중에 발견되면 핫픽스·데이터 마이그레이션·사용자 신뢰 손상까지 더해집니다.
발견 시점 수정 비용(상대)
요구사항 1x ← 문서 한 줄 고치면 끝
설계 ~5x
개발 ~10x
테스트 ~15x
운영(배포 후) ~30x+ ← 핫픽스 + 데이터 정정 + 사과
그래서 실무는 검토·테스트를 왼쪽(앞 단계)으로 당깁니다(shift-left): 요구사항 리뷰, 프로토타입, 설계 리뷰, 자동화 테스트. PM이 요구사항을 명확히 하고 인프라가 설계 단계에 일찍 합류하는 것이 가장 저렴한 품질 투자입니다.
지금 '어느 단계'인지 읽기 — 직접 확인
코드 저장소의 활동만 봐도 프로젝트가 대략 어느 단계인지 단서가 보입니다. PM·인프라가 "지금 어디"를 가늠하는 빠른 방법입니다.
# 최근 커밋 흐름 — 기능 구현 중인지, 버그픽스/안정화 중인지
git log --oneline -10
# 태그(릴리스) 존재 여부 — 배포 단계에 진입했는지
git tag --sort=-creatordate | head
# 열린 이슈/PR 라벨 분포(GitHub) — feature vs bug 비중
gh pr list --state open --json labels --jq '[.[].labels[].name] | group_by(.) | map({(.[0]): length})'
# 안정화/배포 임박 신호: fix/릴리스 커밋 + 버전 태그
a1b2c3d fix: 결제 타임아웃 처리
9f8e7d6 chore: release v1.2.0
v1.2.0 v1.1.0 v1.0.0 ← 태그 존재 → 이미 배포·운영 단계 경험
git log --oneline -10- 커밋이 feat(신규 기능) 위주면 개발 단계, fix/refactor 위주면 테스트·안정화 단계로 추정 → 인프라는 후자일 때 배포 준비를 본격화
- 버전 태그(v1.0.0 등)가 있으면 이미 배포·운영을 경험한 프로젝트 → 롤백·관측성이 갖춰졌는지 확인. 태그가 없으면 첫 배포 준비가 필요
- 열린 PR에 bug 라벨이 급증하면 품질 게이트 통과 전 → 배포 일정을 보수적으로. feature 라벨만 많으면 아직 개발 한복판
- 저장소 신호는 보조 단서일 뿐 — 확정은 팀의 보드(스프린트/칸반) 상태와 함께 본다
상황: "요구사항 확정"이라는 말만 믿고 인프라·일정을 잡았는데, 개발 중반에 "결제 실패 시 재시도 흐름"이 정의된 적 없다는 게 드러나 설계와 코드를 크게 되돌립니다.
원인: 요구사항 단계에서 인수 기준(누가, 어떤 조건에서, 어떤 결과) 까지 내려가지 않고 기능 제목만 합의했습니다. 모호함이 뒤 단계로 흘러 비용이 폭증한 전형적 shift-left 실패입니다.
진단 — 점검 질문:
□ 각 기능에 '인수 기준(AC)'이 있는가? (정상/예외/경계 케이스)
□ 실패·예외 흐름(타임아웃·중복·취소)이 명시됐는가?
□ 비기능 요구(성능·보안·가용성)가 빠지지 않았는가?
해결: 요구사항을 '제목'이 아니라 [[requirements-prd]]에서 다루는 유저스토리 + 인수 기준으로 내립니다. 모호한 항목은 개발 착수 전 프로토타입/스파이크로 검증합니다. 인프라는 설계 리뷰에 일찍 참여해 "이 요구가 우리 자원·네트워크에 주는 영향"을 그 자리에서 짚습니다.
인프라 엔지니어로서 SDLC 지도를 갖고 있으면, "설계 단계"라는 말이 들리는 순간 합류 타이밍을 압니다 — 이때 스택·트래픽 예측을 받아 DB 사이즈·네트워크·환경(dev/stg/prod)을 산정하면, 배포 단계에서 허둥대지 않습니다. PM은 같은 지도로 각 단계의 산출물(PRD·설계서·테스트결과·릴리스노트)을 게이트로 삼아 "다음 단계로 넘어가도 되는지"를 판단합니다. 단계 이름을 공유하는 것만으로 팀 전체의 커뮤니케이션 비용이 줄어듭니다.
다음 모듈에서는 이 단계들을 실제로 굴리는 사람들 — 개발 조직의 역할(FE/BE/QA/DevOps/PO)과 협업 구조를 다룹니다.