← 목록으로

[정처기 필기] 1. 소프트웨어 설계

2026-04-10

소프트웨어 설계 - 개발 생명주기 · 개발 방법론 · 요구사항 공학

정보처리기사 필기 1과목(소프트웨어 설계) 중, 자주 나오는 핵심만 압축 정리.

1. 소프트웨어 개발 생명주기(SDLC)

소프트웨어를 만들고 운영·유지보수까지 진행하는 전 과정.
일반 흐름: 계획 → 분석 → 설계 → 구현 → 테스트 → 유지보수.
시험에서는 생명주기 모형별 특징/장단점/적용 상황을 묻는 문제가 자주 출제됨.

1.1 대표 생명주기 모형

모형	설명	장점	단점
폭포수(Waterfall)	단계를 순차적으로 진행하는 전통적 모형	단계/산출물 관리가 명확	요구사항 변경 대응이 어려움
프로토타입(Prototype)	시제품을 먼저 만들어 요구사항을 구체화	사용자 피드백 빠름, 요구사항 파악 용이	시제품을 최종품으로 오해할 수 있음
나선형(Spiral)	반복 개발 + 위험 분석 중심 모형(보헴)	위험 관리에 강함, 대형 프로젝트에 적합	관리 복잡, 비용/기간 증가 가능
반복/점진적(Iterative/Incremental)	기능을 나눠 반복적으로 완성도 향상	우선순위 기능부터 제공 가능	전체 구조 관리가 어려울 수 있음

1.2 핵심 비교 포인트

폭포수: 안정적 요구사항, 문서 중심, 변경 적은 프로젝트에 적합.
프로토타입: 요구사항이 불명확할 때 유리.
나선형: 고위험/대규모 프로젝트에서 위험 통제가 핵심일 때 유리.
최근 실무는 변경 대응을 위해 반복/점진 및 애자일 방식 비중이 높음.

2. 소프트웨어 개발 방법론

개발 전 과정을 수행하는 절차·원칙·기법의 체계.
정처기에서는 전통 방법론과 애자일 방법론의 차이, 애자일 프레임워크 특징을 구분하는 문제가 자주 나옴.

2.1 전통적 방법론 vs 애자일 방법론

구분	전통적 방법론(구조적/계획 중심)	애자일 방법론(변화 대응 중심)
진행 방식	초기에 계획/분석을 크게 수립 후 단계 진행	짧은 주기 반복(Iteration/Sprint)
요구사항 변경	상대적으로 어려움	비교적 유연하게 수용
문서/절차	문서와 승인 절차 비중 큼	협업·소통·작동 소프트웨어 중시
고객 참여	특정 단계 중심	전 과정에서 지속적 참여

2.2 애자일(Agile) 핵심

가치: 개인과 상호작용, 작동하는 소프트웨어, 고객 협업, 변화 대응 중시.
목표: 빠른 피드백으로 품질 향상 + 변경 비용 최소화.
실무 포인트: 작은 단위로 개발/통합/테스트를 자주 반복.

2.3 주요 애자일 개발 방법

1) 스크럼(Scrum)

제품 백로그(Product Backlog) 기반으로 우선순위 작업 수행.
스프린트(Sprint): 고정된 기간(보통 2~4주) 동안 개발.
주요 이벤트: 스프린트 계획, 데일리 스크럼, 리뷰, 회고.
주요 역할: 제품 책임자(PO), 스크럼 마스터(SM), 개발팀.

2) XP(eXtreme Programming)

고객 요구 반영과 빠른 피드백을 매우 강하게 적용.
핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백.
대표 실천: 짝 프로그래밍, 테스트 주도 개발(TDD), 지속적 통합(CI), 리팩토링.

3) 칸반(Kanban)

작업 흐름을 시각화(보드)하고 **WIP(동시 진행 작업)**를 제한.
병목 구간을 빠르게 찾아 흐름을 개선하는 데 강점.

3. 요구사항 공학 (요구사항 분석/명세)

요구사항 공학은 이해관계자 요구를 정의·분석·명세·검증하는 체계적인 활동.
정처기에서는 특히 요구사항 분석 기법과 요구사항 명세 품질 기준이 자주 출제됨.

3.1 요구사항 분석(Requirement Analysis)

도출된 요구사항을 분류·정제하고, 충돌/중복/누락을 찾아 해결하는 단계.
핵심 목적: 무엇을 개발해야 하는지를 명확히 하고, 개발 범위를 확정.
주요 활동:
- 기능/비기능 요구사항 구분
- 우선순위 부여 및 타당성 검토
- 모호한 표현 제거, 이해관계자 합의
- 모델링(DFD, UML 등)으로 요구사항 시각화

3.2 요구사항 분석 모델

1) 자료흐름도(DFD)

시스템 내 데이터가 어디서 들어와 어떻게 처리/저장/출력되는지 표현.
구성 요소: 처리(Process), 자료 흐름, 자료 저장소, 외부 엔티티.
출제 포인트: 구성 요소 의미와 표기 해석.

2) 자료사전(DD)

DFD에서 사용하는 데이터의 구조/의미/형식을 정의한 사전.
데이터 요소를 표준화해 분석자-개발자 간 해석 차이를 줄여줌.

3.3 요구사항 명세(Requirement Specification)

분석한 요구사항을 문서화한 결과물(요구사항 명세서, SRS).
개발·테스트·검수의 기준 문서가 되므로 명확성/일관성이 중요.

좋은 요구사항 명세서 조건

완전성: 필요한 요구사항이 빠짐없이 포함.
일관성: 요구사항 간 충돌 없음.
명확성: 중의적 표현 없이 해석이 하나로 수렴.
검증 가능성: 테스트/검토로 충족 여부 판단 가능.
추적 가능성: 요구사항 출처와 변경 이력 추적 가능.

3.4 분석 vs 명세 한 번에 구분

구분	요구사항 분석	요구사항 명세
목적	요구사항 정제·이해·합의	요구사항을 표준 문서로 기록
산출물	분석 모델(DFD/UML), 정제 요구사항	SRS(요구사항 명세서)
관점	문제를 구조화하고 해석	구현·테스트 기준으로 전달

4. 소프트웨어 설계 (아키텍처/모듈 설계)

소프트웨어 설계 단계는 요구사항을 실제 구현 가능한 구조로 바꾸는 과정.
정처기에서는 아키텍처 패턴, **모듈 설계 원리(결합도/응집도)**를 자주 물음.

4.1 소프트웨어 아키텍처 개요

시스템의 구성 요소와 관계, 상호작용 방식을 정의한 전체 구조.
목표: 품질 속성(성능, 확장성, 보안, 유지보수성) 확보.
설계 시 고려: 기술 스택, 트래픽 규모, 장애 대응, 운영/배포 방식.

4.2 대표 아키텍처 패턴

패턴	설명	특징
계층형(Layered)	프레젠테이션-비즈니스-데이터 계층으로 분리	역할 분리 명확, 유지보수 용이
클라이언트-서버(Client-Server)	요청(클라이언트)과 처리(서버) 구조	구현 직관적, 중앙집중 관리 가능
MVC	모델-뷰-컨트롤러 분리	UI/로직 분리로 변경 영향 축소
마이크로서비스(MSA)	기능 단위 서비스를 독립 배포	확장성/배포 유연성 높음, 운영 복잡도 증가

4.3 모듈 설계 핵심

모듈은 특정 기능을 수행하는 독립 단위.
좋은 모듈 설계 기준:
- 모듈 내부는 강하게 묶이고(높은 응집도),
- 모듈 사이는 느슨하게 연결(낮은 결합도) 되어야 함.

4.4 결합도(Coupling) - 낮을수록 좋음

순서(나쁨→좋음)	결합도	설명
1	내용(Content)	다른 모듈 내부를 직접 참조
2	공통(Common)	전역 데이터 공유
3	외부(External)	외부 형식/장치/프로토콜 공유
4	제어(Control)	제어 정보(플래그 등) 전달
5	스탬프(Stamp)	구조체/레코드 단위 전달
6	자료(Data)	필요한 데이터만 전달(가장 바람직)

4.5 응집도(Cohesion) - 높을수록 좋음

순서(나쁨→좋음)	응집도	설명
1	우연적(Coincidental)	관련 없는 기능이 우연히 묶임
2	논리적(Logical)	유사 성격 기능을 조건으로 선택 수행
3	시간적(Temporal)	특정 시점에 함께 수행
4	절차적(Procedural)	순서대로 수행되지만 기능 목적은 약함
5	교환적(Communication)	같은 입력/출력 데이터 사용
6	순차적(Sequential)	앞 결과가 뒤 입력으로 사용
7	기능적(Functional)	하나의 명확한 기능 수행(가장 바람직)

4.6 시험에서 자주 나오는 포인트

결합도는 자료 결합도 쪽이 좋고, 내용 결합도 쪽이 나쁨.
응집도는 기능적 응집도 쪽이 좋고, 우연적 응집도 쪽이 나쁨.
실무 관점 핵심 문장: 낮은 결합도 + 높은 응집도.

5. 화면/UI 설계 및 감성공학 요소

화면 설계는 사용자가 시스템과 상호작용하는 접점을 설계하는 단계.
정처기에서는 UI 설계 원칙, 설계 도구(와이어프레임/목업/프로토타입/스토리보드), 감성공학 개념을 자주 묻는다.

5.1 UI 설계 기본 원칙

원칙	설명
직관성	누구나 쉽게 이해하고 바로 사용할 수 있어야 함
유효성	사용자가 원하는 작업을 정확하게 달성해야 함
학습성	처음 쓰는 사용자도 빠르게 익힐 수 있어야 함
유연성	다양한 사용자/환경/요구사항을 수용할 수 있어야 함

5.2 UI 설계 도구 한 번에 정리

도구	목적	특징
와이어프레임(Wireframe)	화면 구조/레이아웃 설계	색상·디자인보다 배치/흐름 중심
목업(Mockup)	실제 화면과 유사한 시각안 공유	정적 화면 중심, 빠른 피드백에 유리
프로토타입(Prototype)	동작 검증 및 사용성 테스트	클릭/이동 등 인터랙션 확인 가능
스토리보드(Storyboard)	화면 전개와 정책 문서화	화면 설명, 전환 조건, 예외 흐름까지 포함

5.3 UI 설계 프로세스(실무형 흐름)

사용자/업무 분석
화면 구조 설계(정보 구조, 메뉴 구조)
와이어프레임/목업 작성
프로토타입으로 사용성 검증
피드백 반영 후 상세 UI 설계 확정

5.4 사용성(Usability) 체크 포인트

일관성: 버튼 위치, 용어, 색상 규칙 유지
가시성: 현재 상태(로딩, 성공, 실패)를 즉시 인지 가능
오류 예방: 잘못된 입력을 사전에 막는 입력 제약/가이드
오류 복구: 취소/되돌리기/재시도 등 복구 경로 제공
접근성: 명도 대비, 키보드 접근, 대체 텍스트 등 고려

5.5 감성공학(Emotional Engineering) 요소

감성공학은 사용자의 감성·심리 반응을 분석해 제품/화면 설계에 반영하는 방법.
핵심은 단순 기능 만족을 넘어 만족감, 신뢰감, 즐거움을 높이는 것.

감성공학 적용 요소

색채/타이포그래피: 브랜드 이미지와 감정 톤 일치
모션/전환 효과: 과하지 않게 상태 변화를 자연스럽게 전달
마이크로카피(문구): 짧고 친절한 안내 문구로 불안 감소
피드백 디자인: 클릭/완료/오류 상황을 감정적으로 안정되게 안내

시험에서 기억할 포인트

감성공학 = 사용자의 주관적 느낌을 정량/정성으로 반영하는 설계 접근
UI 설계 원칙 + 사용성 + 감성 요소는 서로 분리 개념이 아니라 함께 적용됨

6. 데이터베이스/모델링 관련 기초

소프트웨어 설계에서는 데이터 구조를 정확히 정의하는 것이 핵심.
정처기에서는 ERD 구성 요소, 개념/논리/물리 모델링 차이, DBMS 기본 개념을 구분하는 문제가 자주 출제됨.

6.1 ERD(Entity Relationship Diagram) 기초

ERD는 데이터베이스의 구조를 **개체(Entity)·속성(Attribute)·관계(Relationship)**로 표현한 다이어그램.
목적: 시스템이 다루는 데이터와 데이터 간 관계를 시각적으로 명확히 정의.

ERD 핵심 요소

개체(Entity): 관리 대상(예: 회원, 주문, 상품)
속성(Attribute): 개체의 성질(예: 회원명, 이메일)
관계(Relationship): 개체 간 연관(예: 회원-주문)
식별자(Identifier): 개체를 유일하게 구분하는 속성(PK 후보)

관계 차수(Cardinality)

1:1: 한 개체가 다른 한 개체와만 관계
1:N: 한 개체가 여러 개체와 관계
N:M: 여러 개체끼리 다대다 관계(실제 구현 시 보통 교차 테이블로 분해)

6.2 데이터 모델링 단계

단계	관점	산출물	핵심
개념 모델링	업무 중심(현실 세계)	개념 ERD	업무 용어/규칙 기반으로 핵심 개체 도출
논리 모델링	데이터 구조 중심(DBMS 독립)	논리 스키마, 정규화 모델	속성·관계·무결성 제약을 체계화
물리 모델링	구현 중심(DBMS 종속)	물리 스키마, 인덱스/테이블 정의	성능·저장 구조·접근 경로 반영

한 줄 비교

개념: "무엇을 관리할까"
논리: "어떻게 구조화할까"
물리: "DBMS에서 어떻게 구현할까"

6.3 정규화(Normalization) 기초

데이터 중복을 줄이고 이상(삽입/수정/삭제 이상)을 방지하기 위한 과정.
일반적으로 1NF, 2NF, 3NF 수준까지 개념 문제가 자주 출제됨.

핵심 포인트

1NF: 원자값(컬럼 하나에 값 하나)
2NF: 부분 함수 종속 제거(복합키 일부에만 종속 제거)
3NF: 이행 함수 종속 제거(키가 아닌 속성이 다른 비키 속성에 종속 X)

6.4 DBMS 기본 개념

DBMS(Database Management System)는 데이터베이스를 생성·조회·수정·관리하는 소프트웨어.
주요 목적: 데이터 독립성, 무결성, 보안성, 동시성, 복구 기능 제공.

기본 용어 정리

스키마(Schema): DB 구조에 대한 정의
인스턴스(Instance): 특정 시점의 실제 데이터 집합
DDL/DML/DCL
- DDL: 정의(CREATE, ALTER, DROP)
- DML: 조작(SELECT, INSERT, UPDATE, DELETE)
- DCL: 제어(GRANT, REVOKE)

6.5 트랜잭션과 무결성

트랜잭션(Transaction): 데이터 처리의 논리적 작업 단위.
핵심 성질(ACID):
- 원자성(Atomicity): 전부 수행 또는 전부 취소
- 일관성(Consistency): 실행 전후 데이터 규칙 유지
- 고립성(Isolation): 동시 실행 시 서로 간섭 최소화
- 지속성(Durability): 완료 결과는 장애 후에도 보존

무결성 제약

개체 무결성: 기본키는 NULL 불가, 중복 불가
참조 무결성: 외래키는 참조 가능한 값이어야 함
도메인 무결성: 컬럼 타입/범위/형식 준수

7. 시험 포인트(암기 체크)

생명주기 모형 문제는 모형명-특징-장단점을 세트로 암기.
나선형 = 위험 분석 중심, 프로토타입 = 요구사항 구체화 연결해서 기억.
방법론은 전통 vs 애자일 차이를 표 형태로 비교 암기.
애자일 프레임워크는 스크럼(역할/이벤트), XP(핵심 가치/실천 기법) 중심으로 정리.
요구사항 공학은 분석(정제/모델링) vs 명세(SRS 문서화) 차이를 구분해 암기.
설계 파트는 아키텍처 패턴 특징, 결합도/응집도 순서를 묶어서 암기.
화면 설계는 와이어프레임→목업→프로토타입→스토리보드 목적 차이를 구분해 암기.
감성공학은 기능 중심 설계와 달리 사용자 감정/경험 반영이 핵심.
DB 파트는 ERD 요소, 모델링 3단계, ACID, 무결성 제약을 묶어서 암기.