1. 요구사항의 종류
CONCEPT + JUDGMENT기능 요구사항은 시스템이 해야 할 일, 비기능 요구사항은 성능·보안·품질 같은 제약을 다룹니다.
판별 기준 · 기능/비기능을 '해야 할 일 vs 얼마나 잘/어떤 조건으로'로 구분
자주 틀리는 지점 · 성능 요구를 기능 요구로 착각하지 않기
정보처리기사 필기 요약
2027 정보처리기사 필기 요약을 찾는 수험생을 위해 필기 5과목을 암기표가 아니라 개념 연결과 선지 판별 기준으로 정리합니다. 과목당 20문항, 총 100문항의 시험 구조에 맞춰 각 과목 핵심축을 먼저 잡습니다.
소프트웨어 설계
전체 흐름 · 요구사항 → 분석 모델 → UML·UI → 구조 설계 → 인터페이스
2. 요구사항 개발 절차
CONCEPT + JUDGMENT도출 → 분석 → 명세 → 확인(검증)의 흐름으로 이해합니다.
판별 기준 · 각 단계의 산출물보다 목적을 먼저 구분
자주 틀리는 지점 · 검증을 마지막 문서작성 단계로만 보지 않기
3. 요구사항 추적성
CONCEPT + JUDGMENT요구사항이 설계·구현·테스트까지 어디에 반영됐는지 연결해 변경 영향과 누락을 확인합니다.
판별 기준 · 요구 ↔ 설계 ↔ 코드 ↔ 테스트 연결
자주 틀리는 지점 · 단순 버전관리와 동일시하지 않기
4. UML 구조/행위
CONCEPT + JUDGMENTClass·Object·Component·Deployment는 구조, Use Case·Sequence·Activity·State 등은 행위를 표현합니다.
판별 기준 · 무엇을 정적으로 보나 / 시간·동작을 보나
자주 틀리는 지점 · Sequence와 Activity를 혼동하지 않기
5. UML 관계
CONCEPT + JUDGMENTAssociation, Aggregation, Composition, Generalization, Dependency, Realization의 의미를 구분합니다.
판별 기준 · 전체-부분 강도와 상속/구현 관계를 중심으로
자주 틀리는 지점 · Aggregation과 Composition 생명주기 차이
6. UI 설계 원칙
CONCEPT + JUDGMENT직관성·유효성·학습성·유연성과 일관성·접근성·피드백을 사용자 관점에서 봅니다.
판별 기준 · 사용자가 예측하고 복구할 수 있는가
자주 틀리는 지점 · 화려한 화면을 좋은 UI로 판단하지 않기
7. 모듈 설계
CONCEPT + JUDGMENT응집도는 높이고 결합도는 낮추며, 책임과 변경 이유를 좁게 유지합니다.
판별 기준 · 모듈 내부 집중도 ↑ / 외부 의존도 ↓
자주 틀리는 지점 · Control coupling과 Stamp coupling 혼동
8. 아키텍처 패턴
CONCEPT + JUDGMENTLayered, Client-Server, MVC, Pipe-Filter, Repository 등의 책임 배치를 이해합니다.
판별 기준 · 구성요소와 의존 방향을 그리기
자주 틀리는 지점 · 패턴 이름만 보고 장단점 외우지 않기
9. GoF 디자인 패턴
CONCEPT + JUDGMENT생성·구조·행위 패턴을 객체 생성, 조합, 책임/메시지 관점으로 구분합니다.
판별 기준 · Factory/Builder/Singleton, Adapter/Decorator/Facade, Observer/Strategy/Command
자주 틀리는 지점 · MVC를 GoF 23개 중 하나로 착각하지 않기
10. SOLID·인터페이스
CONCEPT + JUDGMENTSRP/OCP/LSP/ISP/DIP로 변경에 유연한 설계를 만들고 인터페이스 계약을 명확히 합니다.
판별 기준 · 구체 구현보다 추상에 의존, 클라이언트별 작은 인터페이스
자주 틀리는 지점 · DIP를 단순 DI 프레임워크 사용으로만 이해하지 않기
이제 이 과목 20문항으로 확인합니다
요약을 읽은 뒤 선지 판별이 실제로 되는지 확인하세요.