1. 요구사항 분석
요구사항 분석은 소프트웨어 개발에서 ‘무엇을 만들 것인지’를 명확하게 정의하는 단계로 사용자와 이해관계자의 요구를 수집하고, 이를 구체적이고 검증 가능한 형태로 문서화한다. 수집된 요구사항은 기능 요구사항(무엇을 해야 하는가)과 비기능 요구사항(성능, 보안, 사용성 등)으로 구분한다.
예를 들어, ‘사용자가 회원가입을 할 수 있어야 한다’는 기능 요구사항이고, ‘페이지 로딩 시간은 2초 이내여야 한다’는 비기능 요구사항이다.
<요구사항 정의서>, 출처: https://velog.io/@juyeon/
또한, 요구사항 분석은 일반적으로 두 가지 과정으로 나뉘는데,
새로운 요구사항을 식별하고 문서화하는 과정인 요구사항 개발(Requirements Development)과, 요구사항이 지속적으로 변경될 수 있는 환경에서 이를 효과적으로 유지·관리하는 과정인 요구사항 관리(Requirements Management)가 있다.
<요구사항 분석 과정>, 출처: https://blog.skby.net
1-1. 요구사항 개발
- 요구사항 도출 (Requirement Elicitation)
- 이해관계자 인터뷰, 설문, 워크숍, 문서 분석 등을 통해 필요한 기능·제약 사항을 수집
- 사용 환경, 업무 흐름, 기존 시스템 한계 조사
- “무엇을 원하는가”를 명확히 정의하는 초기 초안 작성
- 요구사항 분석 (Requirement Analysis)
- 수집된 요구사항을 구조화·정리하여 기능/비기능 요구사항으로 분류
- 기술적 타당성과 비즈니스 목표 부합성 검토
- 중복·충돌·누락 여부 점검 및 우선순위 설정(MoSCoW 방법을 활용하여 개발 리소스를 효율적으로 배분하고, MVP(최소기능제품) 범위를 설정함)
<MoSCoW>, 출처: https://www.bitesizelearning.co.uk/
- 요구사항 명세 (Requirement Specification)
- 분석 결과를 문서화하여 이해관계자와 개발팀이 공유할 수 있도록 작성
- 기능 목록, 조건, 인터페이스, 데이터 흐름 등을 포함
- Use Case, ERD, 시퀀스 다이어그램 등 시각 자료로 모호성 최소화
- 요구사항 검증 (Requirement Validation)
- 명세서가 사용자 기대와 프로젝트 목표를 충족하는지 확인
- 프로토타입, 시뮬레이션, 리뷰 회의를 통해 정확성·일관성 점검
- 변경 사항 반영 후 이해관계자 승인 확보
1-2. 요구사항 관리
- 요구사항 추적(Requirement Traceability)
- 요구사항 ID를 부여하여 설계·개발·테스트 간 연계 관리
- 추적 매트릭스(Traceability Matrix) 작성
- 변경 관리(Change Control)
- 변경 요청서(Change Request) 접수
- 영향 분석(Impact Analysis) 후 승인 여부 결정
- 변경 내역을 문서 및 관련 시스템에 반영
- 버전 관리(Version Control)
- 요구사항 명세서 변경 이력 관리
- Git, Jira, Confluence 등 협업 도구 활용
- 이해관계자 커뮤니케이션(Stakeholder Communication)
- 변경 사항, 일정 변동, 영향도 등을 이해관계자에게 주기적으로 공유
- 승인 절차와 책임자 명확화
2. 시스템 설계
시스템 설계는 수집된 요구사항을 토대로 전체 시스템의 구조와 동작 방식을 정의하는 단계다.
하드웨어, 소프트웨어, 네트워크, 데이터베이스 등 구성 요소 간의 관계를 설계하며, 아키텍처 다이어그램과 데이터 흐름도를 작성한다.
예를 들어, 3계층 구조(프레젠테이션, 비즈니스 로직, 데이터 계층)를 선택하고, 각 계층 간의 데이터 흐름을 정의하는 것이 포함된다. 이 단계는 건축 설계도처럼 개발 전반의 ‘청사진’을 만드는 과정이다.
2-1. 상위 수준 설계 (HLD: High-Level Design)
- 목적: 시스템의 전체 구조와 주요 컴포넌트, 데이터 흐름을 정의
- 주요 내용:
- 아키텍처 스타일 선택 (예: 모놀리식, 마이크로서비스)
- 주요 모듈 및 컴포넌트 식별
- 데이터 흐름도(DFD), 아키텍처 다이어그램 작성
- 주요 기술 스택 결정 (프레임워크, DB, API 방식 등)
- 산출물 예시: 아키텍처 다이어그램, 기술 명세서
2-2. 하위 수준 설계 (LLD: Low-Level Design)
- 목적: 각 모듈을 구현 가능한 수준으로 세부화
- 주요 내용:
- 클래스 다이어그램, 시퀀스 다이어그램 설계
- DB 스키마 및 쿼리 구조 설계
- API 엔드포인트 상세 명세
- 알고리즘 및 데이터 구조 선택
- 산출물 예시: DB ERD, 클래스 명세서, API 스펙 문서
2-3. 설계 절차
- 요구사항 분석
- 기능 요구사항과 비기능 요구사항을 명확히 파악
- 아키텍처 초안 작성
- 주요 컴포넌트, 모듈, 데이터 흐름 구상
- 세부 설계
- 모듈 설계, DB 설계, API 설계, UI/UX 설계
- 검토 및 개선
- 설계 리뷰, 코드 리뷰 전 설계 검증 및 수정
2-3. 설계 원리
- SOLID 원칙
- 단일 책임, 개방-폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전
- 모듈화(Modularity)
- 기능 단위로 나누어 유지보수성과 재사용성 향상
- 느슨한 결합(Loose Coupling)
- 모듈 간 의존성을 최소화해 변경에 유연하게 대응
- 고응집도(High Cohesion)
- 각 모듈이 명확한 역할과 책임을 가짐
- 확장성(Scalability)
- 성능 저하 없이 기능 및 규모 확장이 가능하도록 설계
- 보안(Security)
- 데이터 보호와 접근 제어를 고려한 구조 설계
3. 객체 설계
객체 설계는 시스템 설계에서 정의한 구조를 실제 개발에 사용할 클래스와 객체 단위로 구체화하는 단계로 클래스 다이어그램을 활용해 속성(변수)과 메서드(기능), 그리고 객체 간의 관계(상속, 연관, 의존)를 설계한다.
예를 들어, ‘사용자’ 클래스에는 이름·이메일 속성과 로그인·로그아웃 메서드가 포함될 수 있다.
이 과정은 추후 코드 작성 시 유지보수성과 확장성을 높이는 데 중요한 역할을 한다.
<UML Diagram>, 출처: https://www.dragon1.com
4. 개발 테스트
개발 테스트는 구현된 기능이 요구사항에 맞게 동작하는지 검증하는 과정으로 이 단계에서는 기능 단위, 모듈 단위, 통합 테스트 등을 거쳐 소프트웨어의 품질을 보장한다.
특히 테스트 자동화를 도입하면 개발 속도와 안정성을 높일 수 있다.
4-1. 블랙박스/화이트박스 테스트
-
블랙박스 테스트: 내부 동작을 몰라도 입력과 출력만으로 기능을 검증하는 방식.
예) 로그인 기능에서 올바른 아이디/비밀번호 입력 시 정상 동작 확인. -
화이트박스 테스트: 코드 내부 구조를 분석하여 모든 경로와 로직이 정상적으로 실행되는지 검증하는 방식.
예) if-else 분기문 모든 조건 테스트.
4-2. 테스트 문서 종류
| 문서 | 설명 |
|---|---|
| 테스트 계획서(Test Plan) | 테스트 범위, 목표, 전략, 일정, 리소스 등을 정의 |
| 테스트 케이스(Test Case) | 테스트 목적, 입력값, 기대 결과, 실행 절차 포함 |
| 테스트 시나리오(Test Scenario) | 사용자 관점의 기능 흐름 기반 테스트 항목 |
| 결함 보고서(Bug Report) | 결함 발생 상황, 재현 절차, 로그, 심각도 등 기록 |
| 테스트 요약 보고서(Test Summary Report) | 전체 테스트 결과 요약, 통과율, 결함 통계, 이슈 정리 등 |
4-3. Python 테스트 자동화 도구: pytest
pytest는 Python에서 있다 가장 널리 쓰이는 테스트 프레임워크 중 하나로, 간결한 문법과 강력한 기능을 제공한다. 함수 이름만 test_로 시작하면 자동으로 테스트를 인식하며, 다양한 플러그인을 활용해 커버리지 측정, 데이터 매개변수화, 비동기 테스트 등을 지원한다.
def add(a, b):
return a + b
def test_add():
assert add(2, 3) == 5이처럼 pytest를 활용하면 테스트 코드를 간단히 작성하고 자동 실행할 수 있어, 코드 품질 유지에 큰 도움이 된다.
