신규 합류한 PM에게 팀장이 묻습니다. "이번 기능, 지금 어느 단계예요?" 개발자는 "요구사항은 확정인데 설계 리뷰 중이고, 인프라는 아직 안 붙었어요"라고 답합니다. 인프라 담당인 당신은 "그럼 우리가 언제부터 준비하면 되죠?"가 궁금합니다. 소프트웨어가 기획에서 운영까지 어떤 단계를 거치는지 — 그 전체 지도를 머릿속에 갖고 있어야 "지금 어디"와 "다음 무엇"을 같은 언어로 말할 수 있습니다.
- 1SDLC 6단계(요구→설계→개발→테스트→배포→운영)를 순서와 산출물로 설명할 수 있다
- 2각 단계에서 PM·인프라가 무엇을 준비/확인해야 하는지 짚을 수 있다
- 3결함을 일찍 잡을수록 비용이 줄어드는 "shift-left" 원리를 설명할 수 있다
- 4워터폴과 애자일이 같은 단계를 어떻게 다르게 도느냐를 구분할 수 있다
SDLC 한 장의 지도
요구 → 설계 → 개발 → 테스트 → 배포 → 운영
"지금 어느 단계예요?"에 답하려면 단계들의 이름과 산출물을 알아야 합니다. SDLC(Software Development Life Cycle)는 소프트웨어가 태어나 살아가는 전 과정입니다.
| 단계 | 핵심 활동 | 주요 산출물 | PM·인프라 접점 |
|---|---|---|---|
| 요구사항 | 무엇을 왜 만드나 | PRD·유저스토리·인수기준 | 범위·일정·외부의존 식별 |
| 설계 | 어떻게 만드나 | 아키텍처·API·DB 스키마 | 스택·인프라 자원 산정 |
| 개발 | 구현 | 소스 코드·PR | 개발/스테이징 환경 제공 |
| 테스트 | 의도대로 동작하나 | 테스트 케이스·결과 | 테스트 환경·데이터 |
| 배포 | 프로덕션 반영 | 릴리스·산출물 | 릴리스 전략·롤백·헬스체크 |
| 운영 | 살아있는 동안 유지 | 모니터링·인시던트 기록 | 관측성·온콜·용량 관리 |
이 표의 각 단계는 이 트랙의 나머지 모듈로 깊어집니다 — 요구는 요구사항 정의, 설계는 모놀리식 vs 마이크로서비스와 API와 계약, 배포는 CI/CD 파이프라인과 릴리스 전략, 운영은 SLO·에러버짓·포스트모템. 지금은 전체 지도를 머리에 넣는 것이 목표입니다.
확대
위 그림처럼 SDLC 6단계는 각 단계마다 PM과 인프라가 준비해야 할 산출물과 접점이 다르며, 전체 지도를 공유하는 것만으로도 팀의 커뮤니케이션 비용이 줄어듭니다.
일찍 잡을수록 싸다 — shift-left
결함은 단계가 흐를수록 비싸진다
요구사항 단계의 "우리가 뭘 만들려는지" 오해는, 설계·개발·테스트를 거치며 점점 고치기 어려워집니다. 운영 중에 발견되면 핫픽스·데이터 마이그레이션·사용자 신뢰 손상까지 더해집니다.
발견 시점 수정 비용(상대)
요구사항 1x ← 문서 한 줄 고치면 끝
설계 ~5x
개발 ~10x
테스트 ~15x
운영(배포 후) ~30x+ ← 핫픽스 + 데이터 정정 + 사과
그래서 실무는 검토·테스트를 왼쪽(앞 단계)으로 당깁니다(shift-left): 요구사항 리뷰, 프로토타입, 설계 리뷰, 자동화 테스트. PM이 요구사항을 명확히 하고 인프라가 설계 단계에 일찍 합류하는 것이 가장 저렴한 품질 투자입니다.
확대
위 그림처럼 요구사항 단계에서 1x 비용으로 잡을 결함이 운영 단계에서 발견되면 30x+ 비용으로 폭증합니다. 조기 리뷰와 자동화 테스트로 왼쪽으로 당기는 것이 핵심입니다.
확대
위 그림처럼 워터폴은 각 단계를 한 번에 길게 순차로 통과하고, 애자일은 전체 단계를 2주 스프린트 단위로 짧게 반복합니다. 방법론의 차이는 단계 자체가 아니라 "몇 번에 어떤 크기로 도는가"입니다.
지금 '어느 단계'인지 읽기 — 직접 확인
코드 저장소의 활동만 봐도 프로젝트가 대략 어느 단계인지 단서가 보입니다. 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)'이 있는가? (정상/예외/경계 케이스)
□ 실패·예외 흐름(타임아웃·중복·취소)이 명시됐는가?
□ 비기능 요구(성능·보안·가용성)가 빠지지 않았는가?
해결: 요구사항을 '제목'이 아니라 요구사항 정의에서 다루는 유저스토리 + 인수 기준으로 내립니다. 모호한 항목은 개발 착수 전 프로토타입/스파이크로 검증합니다. 인프라는 설계 리뷰에 일찍 참여해 "이 요구가 우리 자원·네트워크에 주는 영향"을 그 자리에서 짚습니다.
심화 — 단계는 활동이지 부서가 아니다
심화: SDLC가 관료제로 굳는 신호 — 그리고 shift-left의 오독
SDLC 지도를 익힌 다음에 만나는 진짜 문제는 단계 이름이 아니라 단계를 조직이 어떻게 운영하느냐입니다. 같은 6단계라도 살아 있는 프로세스가 되기도, 통과 의례의 나열이 되기도 합니다.
- 단계의 부서화: 요구=기획팀, 개발=개발팀, 테스트=QA팀, 운영=운영팀으로 단계가 부서 경계와 일치하면, 경계마다 핸드오프 대기열이 생깁니다. 사흘짜리 개발이 리드타임 6주가 되는 이유의 대부분은 작업 시간이 아니라 단계 사이의 대기입니다. 단계는 유지하되 한 팀이 여러 단계를 관통하게 하는 것(교차기능 팀, 개발 조직의 역할)이 처방입니다.
- shift-left의 오독: '앞 단계를 두껍게'로 읽으면 분석 마비에 빠집니다 — 요구 문서 50장을 다듬는 동안 시장이 바뀝니다. 왼쪽으로 당길 것은 문서량이 아니라 검증(프로토타입·리뷰·자동 테스트)이고, 앞 단계 산출물의 기준은 '결정을 검증 가능하게 만드는 최소량'입니다.
- shift-right도 있다: '운영 발견 = 30x'라는 곡선은 배포가 크고 비싸던 시절의 이야기입니다. 배포가 하루 수십 번으로 싸지면(CI/CD 파이프라인) 곡선이 완만해져, 일부 검증을 오히려 오른쪽으로 보낼 수 있습니다 — 피처 플래그·카나리(릴리스 전략)·관측성으로 프로덕션에서 안전하게 확인하는 전략입니다. shift-left와 배타가 아니라, 배포 비용에 따라 배합이 달라지는 것입니다.
- 게이트가 죽는 신호: 설계 리뷰가 '이미 정한 것을 공유하는 자리'가 되고, 게이트를 통과한 산출물을 그 뒤 아무도 갱신하지 않는다면 그 게이트는 품질 장치가 아니라 도장 찍는 절차입니다. 점검 질문은 하나 — "이 게이트에서 실제로 뒤집힌 결정이 최근에 있었는가?" 없다면 이미 죽은 게이트입니다.
팀 규모에 따라 답이 다릅니다. 5인 팀은 대화가 곧 게이트라 명시적 게이트가 거의 없어도 되고, 100인 조직은 명시적 게이트 없이는 어긋납니다. 문제는 게이트의 개수가 아니라, 각 게이트가 살아 있는가입니다.
상황: 경영진이 "왜 이렇게 오래 걸리냐"고 묻자 개발팀은 "실제 개발은 사흘이었다"고 답합니다. 타임라인을 복원해 보니 — 기획 확정 후 개발 착수까지 대기 8일(개발팀 백로그 순번), 개발 3일, QA 배정 대기 9일(QA팀이 다른 프로젝트에 묶임), 테스트 2일, 배포 승인 대기 12일(릴리스 위원회가 월 1회). 실작업 5일, 총 리드타임 34일입니다.
원인: SDLC 단계가 각각 다른 부서의 소유가 되면서, 단계 전환마다 '다른 팀의 대기열에 줄 서기'가 발생했습니다. 여기에 월 1회 배치 릴리스가 마지막 대기를 12일까지 늘렸습니다. 어느 한 사람의 잘못이 아니라 구조가 만드는 지연이라, 각 부서는 저마다 "우리는 밀리지 않았다"고 답합니다.
진단: 최근 완료된 기능 몇 개의 타임라인을 복원해 단계별로 '작업 시간 vs 대기 시간'을 나눠 적습니다(밸류 스트림 매핑). 이 팀은 전체 리드타임 중 실작업 비율이 15%였습니다 — 개발 속도를 두 배로 올려도 리드타임은 8% 줄어들 뿐이라는 뜻입니다. 개선 대상이 '사람의 속도'가 아니라 '대기열'임이 수치로 확정됩니다.
해결: 가장 긴 대기부터 구조를 바꿉니다 — ① 릴리스 위원회의 수동 승인을 자동화된 품질 게이트(테스트·보안 스캔 통과)로 대체해 배치 릴리스를 해체 ② QA를 별도 대기열이 아니라 팀에 상주(embedded)시켜 핸드오프 제거 ③ 남는 핸드오프에는 대기 SLA를 겁니다. 석 달 뒤 같은 크기의 기능이 리드타임 9일로 나왔습니다. 단계를 없앤 것이 아니라, 단계 사이의 줄 서기를 없앤 것입니다.
인프라 엔지니어로서 SDLC 지도를 갖고 있으면, "설계 단계"라는 말이 들리는 순간 합류 타이밍을 압니다 — 이때 스택·트래픽 예측을 받아 DB 사이즈·네트워크·환경(dev/stg/prod)을 산정하면, 배포 단계에서 허둥대지 않습니다. PM은 같은 지도로 각 단계의 산출물(PRD·설계서·테스트결과·릴리스노트)을 게이트로 삼아 "다음 단계로 넘어가도 되는지"를 판단합니다. 단계 이름을 공유하는 것만으로 팀 전체의 커뮤니케이션 비용이 줄어듭니다.
다음 모듈에서는 이 단계들을 실제로 굴리는 사람들 — 개발 조직의 역할(FE/BE/QA/DevOps/PO)과 협업 구조를 다룹니다.
실전 랩으로 손에 익히기: SDLC 매핑 실습 — SDLC 단계별 산출물·게이트를 매핑하고 팀 상황에 맞춥니다.
관련 모듈로 더 깊이:
- 개발 조직의 역할 — SDLC 단계를 굴리는 개발 조직의 역할과 협업 구조
- 애자일과 스크럼 — SDLC를 반복적으로 돌리는 애자일·스크럼 흐름
- 칸반 vs 스크럼 vs 워터폴 — 워터폴 vs 애자일, SDLC를 운영하는 두 방식 비교