정보처리기사(필기) 📝 05. 정보시스템 구축 관리
📒 1️⃣ 소프트웨어 개발 방법론
소프트웨어를 체계적이고 효율적으로 개발하기 위해 정립된 절차와 기법을 의미한다.
주로 개발 방법론의 종류, 특징, 비교 위주로 출제됨!
✅ 폭포수(Waterfall) 모델
📌 개념
- 고전적인 개발 방법론으로, 개발 단계를 순차적으로 진행
- 각 단계가 끝나야 다음 단계로 넘어갈 수 있음
📌 절차
1
요구사항 👉🏻 설계 👉🏻 구현 👉🏻 테스트 👉🏻 유지보수
📌 장점
- 계획과 일정 수립이 명확
- 문서화가 철저해서 유지보수 용이
📌 단점
- 요구사항 변경에 취약
- 후반에 발견되는 오류 수정이 어렵고 비용이 큼
🎯 예시 문제 스타일
Q. 다음 중 폭포수 모델의 특징으로 옳지 않은 것은?
① 순차적으로 개발 단계가 진행된다
② 반복적으로 피드백하며 유연하게 대응한다 ❌
③ 요구사항 변경에 약하다
④ 문서화가 철저하다
✅ 프로토타입 모델
📌 개념
- 시제품(Prototype)을 먼저 만들어 사용자 피드백을 반영해 개발
- 요구사항을 명확히 파악하기 어려울 때 유용
📌 절차
1
요구사항 파악 👉🏻 프로토타입 제작 👉🏻 사용자 검토 👉🏻 수정 👉🏻 본개발
📌 장점
- 사용자 요구를 빠르게 파악 가능
- 초기 오류 발견이 쉬움
📌 단점
- 프로토타입에 너무 의존할 경우, 최종 제품과 괴리 발생 가능
- 문서화 미흡 시 유지보수 어려움
✅ 나선형(Spiral) 모델
📌 개념
- 계획, 위험 분석, 개발, 평가의 사이클을 반복하며 점진적으로 개발
- 위험 분석이 핵심 요소
🔁 반복 구조
1
계획 👉🏻 위험 분석 👉🏻 개발 👉🏻 고객 평가 👉🏻 (반복)
📌 장점
- 위험 관리에 효과적
- 점진적 개발로 대규모 프로젝트에 적합
📌 단점
- 복잡하고 관리 어려움
- 비용과 시간이 많이 들 수 있음
🎯 예시 포인트
나선형 모델은 어떤 절차를 반복할까요? → 계획, 위험 분석, 개발, 평가
✅ 애자일(Agile) 모델
📌 개념
- 변화에 유연하게 대응하는 개발 방식
- 작은 단위의 반복과 지속적인 피드백 중시
대표 방식
- XP (익스트림 프로그래밍): 페어 프로그래밍, 지속적 통합 등
- 스크럼(Scrum): 제품 백로그 → 스프린트 계획 → 일일 스탠드업
📌 장점
- 변화에 빠르게 대응 가능
- 고객과의 소통 활발
📌 단점
- 일정 계획이 어려움
- 큰 규모나 명확한 요구가 필요한 프로젝트에는 부적합
🎯 예시 포인트
XP에서 사용하는 기법은? (페어 프로그래밍, 리팩토링 등)
스크럼에서 일정 단위는? (스프린트)
✨ 정리표 비교
| 항목 | 폭포수 | 프로토타입 | 나선형 | 애자일 |
|---|---|---|---|---|
| 구조 | 순차적 | 시제품 기반 | 반복+위험 관리 | 반복+유연 |
| 장점 | 계획 수립 용이 | 빠른 피드백 | 위험 관리 | 변화 대응 |
| 단점 | 변경에 취약 | 유지보수 어려움 | 복잡, 비용↑ | 대형 프로젝트엔 부적절 |
📒 2️⃣ 요구사항 분석
소프트웨어가 사용자 요구에 맞기 동작하려면, 명확하고 구체적인 요구사항 정리가 필수이다.
이 파트는 시스템을 만들기 전 “무엇을 만들어야 하는가”를 명확히 정의하는 과정이다.
✅ 기능 vs 비기능 요구사항
📌 기능 요구사항 (Functional Requirements)
- 시스템이 무엇을 해야 하는지를 정의
- 예: 로그인 기능, 게시글 작성 기능 등
📌 비기능 요구사항 (Non-functional Requirements)
- 시스템의 품질 특성, 성능, 제약조건 등
- 예: 하루 1만 명 동시 접속 가능, 응답 시간 2초 이내, 보안성 등
🎯 예시 문제 스타일
다음 중 비기능 요구사항에 해당하는 것은?
① 게시판 글 등록 기능 ❌
② 사용자 로그인 처리 ❌
③ 2초 이내 응답 시간 ✅
④ 글 목록 페이징 처리 ❌
✅ 요구사항 개발 프로세스
요구사항은 단순히 “필요한 것”을 나열하는 게 아니라, 체계적으로 다듬어야 한다.
🧭 개발 단계
1
도출 → 분석 → 명세 → 확인
| 단계 | 설명 |
|---|---|
| 도출 | 사용자 인터뷰, 브레인스토밍, 설문 등으로 요구 수집 |
| 분석 | 요구 간 충돌, 중복 확인 및 정리 |
| 명세 | 정형화된 문서/모델로 표현 (텍스트, 다이어그램 등) |
| 확인 | 요구사항이 올바르고 완전한지 사용자와 검토 |
✅ 요구사항 명세 기법
📌 정형 명세 vs 비정형 명세
- 정형 명세: 수학적 표현, 모델 기반 (정확하지만 어렵고 비용↑)
- 비정형 명세: 자연어 기반 설명 (작성 쉬움, 해석 오류 가능성↑)
📌 주요 명세 기법
- Use Case Diagram (유스케이스 다이어그램)
- 사용자와 시스템의 상호작용 표현
- ‘누가’, ‘무엇을 한다’를 그림으로 표현
- UML 표기법 사용
- DFD (Data Flow Diagram)
- 데이터 흐름 중심 분석 도구
- 프로세스, 데이터 저장소, 외부 개체, 데이터 흐름으로 구성
- ERD (Entity-Relationship Diagram)
- 데이터베이스 중심 요구사항 명세에 적합
- 엔터티와 관계 중심으로 데이터 구조 표현
🎯 예시 문제 포인트
다음 중 유스케이스 다이어그램의 구성 요소가 아닌 것은?
→ ① 액터 ② 유스케이스 ③ 데이터 흐름 ❌ ④ 시스템
요구사항 분석 과정에서 ‘요구사항 명세’를 수행하는 목적은?
→ 사용자와 개발자 간의 의사소통 명확화, 명확한 문서화 등
✨ 간단 정리
| 구분 | 기능 요구 | 비기능 요구 |
|---|---|---|
| 의미 | 시스템이 해야 할 기능 | 시스템의 품질, 성능 등 |
| 예시 | 게시글 작성, 검색 | 처리속도, 보안, 확장성 |
| 분석 단계 | 핵심 활동 |
|---|---|
| 도출 | 요구 수집 |
| 분석 | 충돌 제거 |
| 명세 | 문서화 |
| 확인 | 검토 및 피드백 |
📒 3️⃣ 설계 관련 이론
✅ 소프트웨어 아키텍처 스타일
📌 아키텍처란?
시스템의 전반적인 구조, 구성요소 간 관계, 설계 원칙 등을 정의하는 설계 청사진
📌 대표적인 아키텍처 스타일
- 계층형(Layered) 아키텍처
- 시스템을 계층으로 분리 (ex: 표현층, 비즈니스 로직, 데이터 접근층)
- 모듈 간 의존성 줄이기에 좋음
- MVC(Model-View-Controller)
- Model: 데이터 처리
- View: 사용자 인터페이스
- Controller: 사용자 요청 처리
- 클라이언트-서버(Client-Server)
- 서버는 서비스 제공, 클라이언트는 요청
- 네트워크 기반 분산 시스템에 사용
- 마이크로서비스 아키텍처
- 시스템을 독립적인 작은 서비스들로 분할
- 배포/관리/유지보수 용이
✅ 모듈화 원칙
📌 응집도 (Cohesion)
- 한 모듈 내의 기능들이 얼마나 밀접하게 관련되어 있는가
- 응집도가 높을수록 좋음
| 응집도 종류 (좋음 → 나쁨) | 설명 |
|---|---|
| 기능적 응집 | 한 기능만 수행 |
| 순차적 응집 | 순서대로 수행 |
| 통신적 응집 | 동일한 데이터 사용 |
| 절차적 응집 | 절차는 같지만 연관 적음 |
| 논리적 응집 | 여러 기능 중 선택 |
| 우연적 응집 | 관련 없음 ❌ |
📌 결합도 (Coupling)
- 모듈 간의 의존성 정도
- 결합도는 낮을수록 좋음
| 결합도 종류 (낮음 → 높음) | 설명 |
|---|---|
| 자료 결합 | 단순 데이터만 전달 |
| 스탬프 결합 | 구조체나 객체 전달 |
| 제어 결합 | 제어 정보(플래그 등) 전달 ❌ |
| 외부 결합 | 외부 기기, 시스템 의존 ❌ |
| 공통 결합 | 전역변수 공유 ❌ |
| 내용 결합 | 내부 직접 참조 ❌ |
✅ 설계 기법
📌 자료사전(Data Dictionary)
- DFD, ERD 등에서 사용하는 데이터 요소에 대한 정의서
- 용어 정의, 형식, 길이, 설명 등을 기록
📌 ERD(Entity-Relationship Diagram)
- DB 중심 설계 도구
- Entity(개체), Attribute(속성), Relationship(관계) 구성
📌 구조적 차트(Structure Chart)
- 시스템의 모듈 구조를 계층적으로 표현
🎯 예시 문제 포인트
다음 중 결합도가 가장 낮은 것은?
→ ① 자료 결합 ✅ ② 제어 결합 ③ 내용 결합 ④ 공통 결합
응집도가 가장 높은 유형은?
→ 기능적 응집
MVC 아키텍처에서 사용자 입력을 처리하는 구성요소는?
→ Controller
✨ 간단 정리
| 요소 | 설명 | 특징 |
|---|---|---|
| 응집도 | 모듈 내부 일관성 | 높을수록 좋음 |
| 결합도 | 모듈 간 의존도 | 낮을수록 좋음 |
| 아키텍처 스타일 | 시스템 구조 설계 방식 | MVC, 계층형 등 |
| 자료사전 | 데이터 요소 정의 | 이름, 형식, 설명 등 기록 |
📒 4️⃣ 테스트
소프트웨어의 오류를 발견하고 품질을 보증하기 위해 수행되는 활동
정처기에서는 테스트 종류, 기법, 자동화, 화이트/블랙박스 중심으로 자주 출제된다.
✅ 테스트의 종류 (수행 단계 기준)
| 테스트 종류 | 설명 |
|---|---|
| 단위(Unit) 테스트 | 하나의 모듈/함수를 독립적으로 검증 |
| 통합(Integration) 테스트 | 모듈 간 연결과 인터페이스 검증 |
| 시스템(System) 테스트 | 전체 시스템 기능이 요구사항에 부합하는지 검증 |
| 인수(Acceptance) 테스트 | 실제 사용자가 사용 환경에서 수용 가능한지 검증 |
🎯 단위 → 통합 → 시스템 → 인수
✅ 테스트의 종류 (기법 기준)
📌 화이트박스 테스트 (구조 기반 테스트)
- 코드 내부 구조를 알고 테스트
- 조건/경로 커버리지 확인
📌 블랙박스 테스트 (기능 기반 테스트)
- 입출력 중심 테스트
- 내부 로직은 고려하지 않음
✅ 블랙박스 테스트 기법
| 기법 | 설명 |
|---|---|
| 동치 분할 (Equivalence Partitioning) | 입력값을 유효/무효 그룹으로 나눠 대표값만 테스트 |
| 경계값 분석 (Boundary Value Analysis) | 경계 근처 값을 집중적으로 테스트 |
| 원인-결과 그래프 | 조건과 결과를 논리적으로 조합 |
| 상태 전이 테스트 | 상태 변화에 따른 반응을 테스트 |
| 의사결정 테이블 | 복잡한 조건 조합을 표로 정리해 테스트 |
🎯 예시
- 입력 범위가 1~100일 때:
0, 1, 100, 101같은 경계값 테스트가 중요
✅ 테스트 자동화와 도구
📌 테스트 자동화
- 반복적인 테스트를 스크립트나 도구로 자동 수행
- 시간 절약 + 일관성 유지
📌 대표 도구
| 도구 | 용도 |
|---|---|
| JUnit | Java 단위 테스트 |
| Selenium | UI 테스트 자동화 |
| Jest | JavaScript 테스트 |
| Postman | API 테스트 |
✅ 테스트 관련 개념
| 용어 | 의미 |
|---|---|
| 테스트 케이스(Test Case) | 입력값, 수행 조건, 기대 결과의 집합 |
| 테스트 시나리오(Test Scenario) | 전체 흐름과 상황 중심의 테스트 계획 |
| 결함(Bug) | 기대 결과와 실제 결과의 불일치 |
| 디버깅(Debugging) | 결함을 찾아 수정하는 과정 |
🎯 예시 문제 포인트
테스트 케이스 설계 시, 입력값을 유효/무효로 나누는 기법은?
→ 동치 분할
내부 코드 구조를 고려한 테스트 기법은?
→ 화이트박스 테스트
모듈 간 인터페이스를 검증하는 테스트는?
→ 통합 테스트
테스트 자동화 도구가 아닌 것은?
→ ① JUnit ② Selenium ③ Excel ❌ ④ Jest
✨ 간단 정리
| 기준 | 화이트박스 | 블랙박스 |
|---|---|---|
| 접근 방식 | 내부 구조 기반 | 외부 기능 기반 |
| 기법 | 조건/경로 커버리지 | 경계값, 동치 분할 등 |
| 테스트 단계 | 초점 |
|---|---|
| 단위 테스트 | 코드 단위 오류 |
| 통합 테스트 | 모듈 연결 검증 |
| 시스템 테스트 | 전체 기능 만족 여부 |
| 인수 테스트 | 사용자 수용성 확인 |
📒 5️⃣ 형상관리 (Configuration Management)
소프트웨어 개발 중 발생하는 산출물의 변경을 통제하고 관리하는 체계
코드, 문서, 설계서 등 모든 버전의 변경 사항을 추적해 오류를 줄이고 혼란을 방지해준다.
✅ 형상관리의 주요 개념
| 용어 | 설명 |
|---|---|
| 형상 항목 (CI, Configuration Item) | 형상 관리 대상으로 등록된 모든 산출물 (코드, 문서, 모델 등) |
| 베이스라인 (Baseline) | 변경 통제 대상이 되는 최초 확정본 |
| 버전 (Version) | 변경 이력이 포함된 항목의 각 상태 |
| 릴리즈 (Release) | 실제 배포되는 소프트웨어 구성 |
| 빌드 (Build) | 소스코드를 컴파일해 실행 파일로 만든 결과물 |
✅ 형상관리 절차
1
① 형상 식별 → ② 형상 통제 → ③ 형상 감사 → ④ 형상 기록 및 보고
| 단계 | 설명 |
|---|---|
| 형상 식별 | 관리 대상 항목(CI)을 정의하고 명확히 식별 |
| 형상 통제 | 변경 요청을 접수하고 승인/반영 여부 결정 |
| 형상 감사 | 형상 항목이 표준에 따라 관리되고 있는지 점검 |
| 형상 기록/보고 | 변경 내역, 상태 등을 기록하고 보고서로 작성 |
✅ 형상관리 도구
📌 대표 도구 예시
| 도구 | 설명 |
|---|---|
| Git | 분산 버전 관리 시스템, CLI or GitHub 등과 함께 사용 |
| SVN (Subversion) | 중앙 집중형 버전 관리 시스템 |
| CVS | 구버전 중앙형 시스템 (현재는 거의 안 씀) |
📌 Git 기본 개념 연결 예시
commit: 버전 생성branch: 독립적 작업 흐름merge: 변경 내용 병합pull request: 변경 요청 → 형상 통제 프로세스와 유사!
✅ 형상관리 vs 버전관리
| 구분 | 형상관리 | 버전관리 |
|---|---|---|
| 포괄성 | 넓음 (전체 변경 통제) | 좁음 (버전 중심) |
| 대상 | 전체 산출물 | 주로 소스코드 |
| 예시 도구 | Git, SVN | Git, CVS 등 |
🎯 예시 문제 포인트
형상관리 절차 중, 변경 요청을 승인하거나 반영하는 단계는?
→ 형상 통제
형상 항목의 변경 이력을 확인하기 위해 사용하는 개념은?
→ 버전
Git에서 ‘변경 승인 요청’을 표현하는 작업은?
→ Pull Request
다음 중 형상관리 도구가 아닌 것은?
→ ① Git ② SVN ③ Excel ❌ ④ CVS
✨ 요약 정리
| 개념 | 설명 |
|---|---|
| 형상 항목 | 관리 대상 산출물 (CI) |
| 베이스라인 | 최초 확정본 |
| 버전 | 변경 이력의 단위 |
| 릴리즈 | 배포용 구성 |
| 형상관리 절차 | 식별 → 통제 → 감사 → 기록 |
📒 6️⃣ 품질 보증 (Software Quality Assurance)
소프트웨어가 사용자 요구와 품질 기준을 만족하는지 확인하는 전반적인 절차
개발 프로세스 전반에 걸쳐 품질을 계획하고, 점검하고, 개선하는 활동
✅ 소프트웨어 품질의 정의
품질(Quality)이란?
“소프트웨어가 요구된 기능과 성능을 오류 없이, 효율적으로, 사용자의 기대에 맞게 제공하는 정도”
✅ 소프트웨어 품질 특성 (ISO/IEC 9126 기준)
📌 국제 표준 ISO/IEC 9126은 품질을 6가지 큰 분류로 나눔
| 대분류 | 세부 항목 | 설명 |
|---|---|---|
| 기능성 | 적절성, 정확성, 상호운용성 | 요구된 기능을 제대로 수행 |
| 신뢰성 | 성숙성, 결함 허용성, 복구성 | 오류 발생에 대한 견고함 |
| 사용성 | 이해성, 학습성, 운용성 | 사용하기 쉬운가 |
| 효율성 | 시간 효율성, 자원 효율성 | 성능, 자원 사용 측면 |
| 유지보수성 | 분석성, 변경성, 안정성 | 수정 및 개선이 쉬운가 |
| 이식성 | 적응성, 설치성, 대체성 | 다른 환경으로 옮기기 쉬운가 |
✅ 소프트웨어 품질보증 활동
| 단계 | 활동 |
|---|---|
| 품질 계획 | 품질 목표와 기준 정의, 전략 수립 |
| 품질 통제 | 검사, 테스트 등을 통해 품질 수준 유지 |
| 품질 개선 | 결함 분석 후 개선 활동 수행 |
✅ 품질보증 관련 문서
| 문서명 | 역할 |
|---|---|
| SQA 계획서 | 품질 목표, 일정, 역할 등 기재 |
| 결함 기록표 | 발견된 오류의 내용, 심각도, 상태 등을 정리 |
| 검토 및 점검 보고서 | 리뷰 결과 요약, 품질 상태 보고 |
🎯 예시 문제 포인트
소프트웨어 품질 특성 중 “다른 환경에서도 잘 작동하는가?”와 관련된 것은?
→ 이식성
ISO/IEC 9126 품질 특성에 해당하지 않는 것은?
→ ① 기능성 ② 유연성 ❌ ③ 유지보수성 ④ 효율성
품질보증 계획에 포함되는 요소가 아닌 것은?
→ ① 품질 목표 ② 일정 ③ 개발자 월급 ❌ ④ 테스트 방법
✨ 간단 정리
| 구분 | 주요 포인트 |
|---|---|
| 품질보증(QA) | 계획 → 점검 → 개선 순서 |
| 품질 특성 (ISO/IEC 9126) | 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 |
| 문서 | 계획서, 결함 기록표, 점검 보고서 등 |
📒 7️⃣ 개발 보안 (시큐어 코딩 & 보안 공격)
보안은 개발 초반부터 미리 고려해야 할 필수 요소
정처기에서는 시큐어 코딩 원칙, 7대 취약점, 대표적인 공격 유형이 단골로 나온다.
✅ 시큐어 코딩의 개념
보안 취약점을 방지하고, 안전한 코드를 작성하는 개발 방법
- 해킹, 악성 코드, 데이터 유출 등을 사전에 방지
- 프로그램의 신뢰성, 안전성 확보
✅ 시큐어 코딩 7대 취약점 (행안부 가이드 기준)
| 취약점 | 설명 | 예시 |
|---|---|---|
| 입력 데이터 검증 미흡 | 사용자 입력값 필터링 안 됨 | SQL Injection, XSS |
| 보안 기능 오류 | 인증/암호화 기능 부적절 | 로그인 우회, 약한 암호화 |
| 시간 및 상태 문제 | Race Condition 등 동시성 문제 | 동시에 계좌 이체 두 번 되는 등 |
| 에러 처리 미흡 | 상세한 에러 메시지 노출 | 시스템 경로 노출 등 |
| 코드 오류 | 잘못된 로직, 초기화 안 된 변수 등 | Null 접근, 논리 오류 |
| 캡슐화 파괴 | private 데이터에 외부 접근 가능 | setter 없이 데이터 변경 |
| API 오용 | API의 사용법 잘못 사용 | 잘못된 순서, 취약한 라이브러리 |
✅ 주요 보안 공격 유형
| 공격명 | 설명 |
|---|---|
| SQL Injection | 입력값을 SQL 쿼리에 삽입하여 DB 조작 |
| XSS (Cross Site Scripting) | 악성 스크립트를 사용자 브라우저에서 실행 |
| CSRF (Cross Site Request Forgery) | 사용자의 인증 정보를 도용해 요청 수행 |
| 무차별 대입 공격 (Brute Force) | 암호를 무작위로 계속 입력해서 맞추기 |
| 피싱(Phishing) | 가짜 사이트 등으로 사용자 정보를 탈취 |
✅ 보안 관련 도구
| 도구 | 용도 |
|---|---|
| Static Code Analyzer | 코드 정적 분석 도구 (예: SonarQube) |
| OWASP Top 10 | 웹 보안 취약점 리스트 제공 |
| Vulnerability Scanner | 시스템/코드의 취약점 탐지 |
🎯 예시 문제 포인트
다음 중 시큐어 코딩 7대 취약점에 해당하지 않는 것은?
→ ① 입력 데이터 검증 미흡 ② 캡슐화 파괴 ③ 에러 처리 미흡 ④ 데이터베이스 정규화 ❌
악성 스크립트를 사용자 브라우저에서 실행하는 공격은?
→ XSS
입력값 검증이 제대로 되지 않아 발생할 수 있는 공격은?
→ SQL Injection
✨ 간단 정리
| 항목 | 포인트 |
|---|---|
| 시큐어 코딩 | 7대 취약점 외우기 (입력 검증, 보안 기능, 에러 처리 등) |
| 주요 공격 | SQLi, XSS, CSRF 등 구분 |
| 보안 도구 | 정적 분석, OWASP 등 |