SDLC, 들어보신 적 있나요?

SDLC는 Software Development Life Cycle의 약자로, 정보 구조 (Information system)을 계획하고, 만들고, 테스트하고, 배포하는 일련의 과정을 의미합니다.

 

SDLC는 System Development Life Cycle을 의미하기도 하는데요. 이 둘의 차이는 업무의 포함 범위에 있습니다.

 

 

 

 

 

 

 

 

 

 

 

위 이미지와 같이, System Development Life Cycle은 사람, 프로세스, 구조, 배움의 과정, 조직적인 Announcement를 포함한다면, Software Development Life Cycle은 그보다는 조금 더 개발에 가까운 측면만을 담고 있습니다. (사실 리서치를 해보면 System DLC 역시 Software DLC의 의미로 혼용되고 있기도 합니다.)

 

SDLC는 다음의 6개 단계로 나눠볼 수 있습니다.

1. 요구 사항 수집

2. 디자인 솔루션

3. 개발

4. 테스트

5. 배포

6. 유지 및 보수

 

이러한 단계를 수행하기 위해 다양한 방법론이 사용되고 있는데요.

여기서는 5개의 방법론을 다룹니다. 각 방법론마다 업무를 어떻게 진행하는지 알아보겠습니다.

 

1. Waterfall model (폭포수 모델)

우리가 익히 알고 있는 전통적 모델입니다. 선형의 프로세스라 할 수 있습니다. 가장 큰 특징은 이전 단계가 완료되어야 다음 단계를 진행할 수 있다는 것인데요. 각 단계는 이전 단계의 산출물을 토대로 진행됩니다. 이전 단계로 다시 돌아갈 수는 없으며, 초기부터 개발 일정과 예산이 모두 계획되어 있다는 것도 특징입니다. 주로 formal한 승인 단계와 문서를 수반합니다.

예시

1.1 요구사항 수집

사업적 분석 필요

요구사항 도출 및 문서화

 

1.2 디자인

1.1의 요구사항을 만족하는 디자인

시스템뿐만 아니라 하드웨어적 요구사항도 결정

큰 그림을 분절

 

1.3 개발

1.2의 분절을 각각 개발

1.2의 분절을 각각 유닛 테스트

 

1.4 테스트

각 분절을 시스템 차원에서 테스트 (QA 또는 BA)

사업적 측면/고객 측면에서 요구사항 인수 조건에 도달하는지 확인

각 분절을 순서대로 나열하여 처음부터 끝까지 테스트

 

1.5 배포

프로덕션 환경에 배포

마켓에 배포

 

1.6 유지 및 보수

버그 수정 및 패치

새로운 요구사항 발생 시 업데이트

 

위의 예시와 같이, Waterfall model은 각 단계에서 진행하는 업무가 굉장히 명확합니다.

 

장점

일정, 예산, 자원에 대해 명확하게 예측하기 쉽습니다.

작성한 문서는 퀄리티와 신뢰도, 유지보수성(Maintainability)를 보장합니다.

진척도를 쉽게 측정할 수 있습니다.

 

단점

유연하게 변경하기 어렵고 번거롭습니다.

프로젝트 시작과 실제 결과 간 간극이 존재할 우려가 있습니다.

사용자 테스트에서 문제가 발견되기도 합니다.

문서가 최신 상태를 유지하지 못해 활용도가 떨어질 수 있습니다.

고객/사업팀과 개발팀 간 갭이 커질 수 있습니다.

 

언제 쓰면 좋을까요?

목표와 솔루션이 명확할 때

규모가 크고, 복잡하고, 비용이 많이 들 때

즉각적인 투자 수익률에 대한 부담이 없을 때

팀이 솔루션과 소프트웨어에 대해 잘 알고 있을 때

요구사항 변동이 잦지 않을 때

리소스에 제약이 있을 때

마일스톤 변경에 대한 룰이 엄격할 때

 

2. Incremental Model

미니 폭포수 모델이라고도 하는 Incremental Model은 명확한 업무 순서가 여러 세트 반복되는 형식을 의미합니다. 폭포수 모델보다 요구사항에 더 유연하게 대응할 수 있다는 장점이 있습니다. 주로 프로젝트에서 고객 가치를 빠르게 전달하는 데 초점을 맞추고 있습니다.

 

 

 

 

 

 

 

 

 

 

장점

개발 초기 단계에도 고객 가치를 제공할 수 있습니다.

반복 도중에 변경되는 요구사항을 적용할 수 있습니다.

Waterfall model보다 더 이른 단계에서 문제를 감지할 수 있습니다.

반복 과정에서 학습된 노하우를 활용할 수 있습니다.

단점

문서 양이 많아집니다.

제품 자체를 관통하는 전반적인 문제를 발견하기 어렵습니다.

어려운 문제는 다음 이터레이션으로 미루고 미루게 되는 경향이 있습니다.

 

언제 쓰면 좋을까요?

요구사항이 명확하지 않은 큰 규모의 프로젝트일 때

익숙하지 않은 분야일 때

급변하는 기술로 인해 요구사항이 변할 우려가 있을 때

사업팀이 자주 관여하는 조직일 때

기능적 요구사항을 빠르게 가시화해야 할 때

 

3. Spiral model

선형과 반복의 조합이라고들 합니다. 리스크 최소화에 초점을 둡니다. 따라서 프로젝트를 더 작은 단위로 나누어서 위험을 최소화합니다. '목표 설정 > 위험 분석 > 개발/검증 > 고객 평가 및 다음 계획 수립'을 반복합니다.

 

예시

1. 목표 설정

고객의 요구사항을 분석하고 타당성을 검토한 뒤, 수행 여부를 결정합니다.

단계별 목표를 수립합니다.

한 iteration이 끝나면 목표는 바뀝니다.

 

2. 위험 분석

예측 가능한 위험을 추출하고, 대처 방안을 수립합니다.

위험을 최소화하기 위한 단계입니다.

 

3. 개발/검증

개발 ~ 유닛 테스트가 이루어지는 단계입니다.

 

4. 고객 평가 및 다음 계획 수립

개발 및 테스트가 끝난 결과물이 인수 조건을 충족했는지 확인합니다.

인수 조건을 충족하지 못할 경우 동일 목표로 추가 iteration을 진행합니다.

 

장점

리스크를 명확하게 인지, 관리하고 최소화합니다.

문제를 조기 식별하고 해결합니다.

프로젝트 종료 단계의 산출물 수준을 정확히 추정할 수 있습니다.

 

단점

완성까지 시간이 많이 걸립니다.

비용이 많이 듭니다.

 

언제 쓰면 좋을까요?

위험을 최소화하는 것이 중요한 프로젝트

고객이 자신의 니즈를 확신하지 못할 때

요구사항이 복잡할 때

프로토타입이 필요할 때

프로젝트 분야에 대한 경험이 적을 때

 

4. Scrum model (애자일)

굉장히 유명한 모델입니다. 주로 스프린트라는 iteration을 사용하며, 외부 변화에 유연하게 대처하기 용이합니다. 프로세스나 사용하는 툴보다는 개인과 상호작용에 더 무게를 둡니다.

 

특성

요구사항 분석, 기획, 개발, 테스트가 모두 2~4주 (14 ~30일) 내에 완료됩니다.

요구사항은 제품 백로그로 관리하며, 이를 기반으로 개발을 진행합니다.

프로젝트 팀은 주로 Product Owner, Scrum master, Scrum 개발 팀 등으로 구성됩니다.

순서

1. 스프린트 계획

백로그에서 개발할 항목을 선정합니다.

 

2. 데일리 스크럼

매일 약 5~15분 정도의 짧은 시간에 오늘 할 일, 내가 겪고 있는 어려움 등을 공유합니다.

 

3. 스프린트 리뷰

제품을 직접 시연/구동하고 피드백을 받습니다.

 

4. 스프린트 회고

진행한 스프린트를 점검하고, 개선할 부분이나 잘 진행된 부분 등을 공유합니다.

 

장점

요구사항이 변해도 유연하게 적응 및 변경할 수 있습니다.

실행 가능한 형태의 제품을 보다 빠르게 확보할 수 있습니다.

기획 - 개발 팀 간 협업을 촉진합니다.

데일리 피드백을 통해 문제가 되는 부분을 빠르게 쳐낼 수 있습니다.

 

단점

종료 일정을 찍지 않고 기간 단위로 이루어져 상대적으로 시작 - 끝이 불명확합니다.

팀원들의 자발성에 의존합니다.

기존 개념과 많이 다르다 보니, 적용 초기에는 진입장벽이 있습니다.

팀원이 바뀌거나 팀원이 나갈 경우 다른 방식보다 여파가 큽니다.

 

언제 쓰면 좋을까요?

프로젝트 예측이 어려울 때

요구사항 변경 여지가 클 때

가시적인 제품을 빠르게 개발해야 할 때

개발팀의 경우 리소스 제약이 적을 때

 

5. Scrum model (RAD)

RAD는 Rapid Application Development의 약자입니다. 개발 기간이 일반적 Scrum model보다 더 촉박하고, 구동 가능한 프로토타입을 빠르게 개발한 뒤 피드백을 받아 다듬는 작업을 진행합니다. 제품이 요구사항을 충족할 때까지 반복합니다. Scrum model과 유사하기 때문에, 관련 이미지와 RAD 모델만의 장단점만 언급하겠습니다.

 

장점

개발 기간을 단축할 수 있습니다.

개발 과정에서 제작했던 컴포넌트를 재활용하기 쉽습니다.

 

단점

시스템을 모듈화해야 합니다.

굉장히 숙련된 개발자나 디자이너가 필요합니다.

 

언제 쓰면 좋을까요?

단기간 (주로 2-3개월) 내에 모듈화 및 완료가 필요할 때

숙련된 디자이너의 가용 리소스가 클 때

 

 

마무리하며

요즘은 Dual track scrum, Hybrid model 등 다양한 방법론이 활용되고 있습니다. 그러나 기본적인 모델에 대한 이해가 없는 채로 방법론을 적용할 경우, 개발 전반에서 혼란이 발생하게 됩니다. 당연히 개발 산출물 역시 불명확할 가능성이 높습니다.

 

특히나 PM은 명확한 체계와 방식을 토대로 프로젝트를 관리할 필요가 있기에, 어찌보면 당연한 내용일지라도 한 번쯤 정리해보면 좋을 듯 하여 아티클을 작성해보았습니다. 이 아티클은 전반적인 방향성이나 개괄적인 내용을 다루고 있으니, 우리 조직에 적합해 보이는 방법에 대해 조금 더 깊이있게 조사하는 것도 추천드립니다.