정보처리기사 필기 2과목 소프트웨어 개발은 실제로 코드를 만들고 검증하는 전 과정을 다룹니다. 테스트 기법, 형상 관리(Git), 클린코드, 패키징까지 실무와 직결되는 내용이 많아서 이해하면 외우기 쉬운 과목입니다.

1. 소프트웨어 테스트

테스트의 기본 원칙 7가지

원칙설명
결함 존재 증명테스트는 결함이 있음을 보여주는 것. 결함이 없음을 증명할 수 없음
완벽 테스트 불가능무한한 경우의 수로 완전한 테스트는 불가능
조기 테스트개발 초기부터 테스트 시작. 결함은 초기에 발견할수록 수정 비용 낮음
결함 집중(파레토 법칙)결함의 80%는 전체 모듈의 20%에 집중되어 있음
살충제 역설동일한 테스트를 반복하면 새 결함 발견 능력이 떨어짐 → 주기적으로 테스트 케이스를 변경해야 함
테스트는 정황에 의존소프트웨어 특성에 따라 테스트 방식이 달라짐
오류 부재의 궤변결함이 없어도 사용자 요구사항을 충족하지 못하면 좋은 소프트웨어가 아님
🎯 빈출 포인트
✔ "같은 테스트를 반복하면 결함 발견 능력이 저하되는 현상은?" → 살충제 역설
✔ "결함의 80%가 20% 모듈에 집중된다는 원칙은?" → 결함 집중(파레토 법칙)

화이트박스 vs 블랙박스 테스트

구분화이트박스블랙박스
관점내부 코드 구조를 알고 테스트내부 구조를 모르고 입출력만 테스트
기법구문·결정·조건·경로 커버리지동치 분할, 경계값 분석, 원인-결과 그래프
수행자주로 개발자주로 QA/사용자

테스트 단계

단계대상방법
단위 테스트개별 모듈·함수화이트박스 위주. 드라이버/스텁 사용
통합 테스트모듈 결합 인터페이스상향식(드라이버), 하향식(스텁), 빅뱅
시스템 테스트완성된 전체 시스템기능·비기능 요구사항 검증
인수 테스트사용자 관점알파(내부), 베타(외부) 테스트

2. 테스트 커버리지

코드가 얼마나 테스트됐는지 나타내는 지표입니다. 강도가 높을수록 더 꼼꼼하게 검사하지만 그만큼 테스트 케이스가 많아집니다.

커버리지측정 기준강도
구문(Statement)모든 명령문 최소 1회 실행★☆☆☆☆
결정(Decision/Branch)모든 분기의 참·거짓 각 1회 이상★★☆☆☆
조건(Condition)각 조건식의 참·거짓 각 1회 이상★★★☆☆
조건/결정조건 + 결정 커버리지 동시 만족★★★★☆
변경 조건/결정 (MC/DC)각 조건이 독립적으로 결과에 영향. 항공 소프트웨어 표준★★★★★
다중 조건모든 조건 조합 실행. 가장 완전하지만 지수적 증가★★★★★+
💡 커버리지 강도 순서 암기
구문 → 결정 → 조건 → 조건/결정 → MC/DC → 다중 조건
"구결조조MC다" 로 외우면 편합니다.

3. 형상 관리(Configuration Management)

형상 관리 도구 비교

도구유형핵심 특징
Git분산형로컬 저장소 보유. 오프라인 작업 가능. 브랜치 전략 유연. 현재 업계 표준
SVN (Subversion)중앙집중형중앙 서버에 이력 저장. 파일·디렉터리 이름 변경 지원. 접근 권한 명확
CVS중앙집중형SVN의 전신. 파일 단위 버전 관리. 디렉터리 이동·이름 변경 불가
RCS로컬로컬 파일 단위 버전 관리. 단일 사용자 환경에서 사용

Git 주요 명령어 — 필기 출제 포인트

명령어기능
git init새 저장소 초기화
git clone원격 저장소를 로컬로 복사
git add변경 파일을 스테이징 영역에 추가
git commit스테이징 영역의 변경사항을 로컬 저장소에 저장
git push로컬 커밋을 원격 저장소에 업로드
git pull원격 저장소의 변경사항을 로컬에 가져와 병합
git branch브랜치 생성·조회
git merge브랜치를 현재 브랜치에 병합
🎯 형상 관리 빈출 문제
✔ "분산형 버전 관리 시스템으로 로컬 저장소를 가지는 도구는?" → Git
✔ "중앙집중형 버전 관리 시스템으로 Git의 이전 표준은?" → SVN
✔ 형상 관리 4단계: 형상 식별 → 형상 통제 → 형상 감사 → 형상 기록

4. 클린코드와 리팩토링

클린코드 작성 원칙

원칙설명
가독성이해하기 쉽게 코드를 작성. 명확한 네이밍, 들여쓰기 통일
단순성한 함수는 하나의 기능만 수행. 불필요한 복잡성 제거
의존성 최소화모듈 간 결합도를 낮추어 변경 영향 최소화
중복 제거DRY(Don't Repeat Yourself) 원칙. 같은 코드를 여러 곳에 두지 않음
추상화공통 기능을 함수·클래스로 묶어 세부 구현을 숨김

리팩토링(Refactoring)

외부 동작은 그대로 유지하면서 내부 코드 구조를 개선하는 작업입니다. 버그를 수정하는 것이 아니라 코드의 품질을 높이는 것이 목적입니다.

리팩토링 기법설명
메서드 추출 (Extract Method)긴 메서드의 일부를 새 메서드로 분리
메서드 이동 (Move Method)메서드를 더 적절한 클래스로 이동
변수 이름 변경의미 없는 변수명을 의미 있는 이름으로 변경 (i → studentCount)
중복 코드 제거반복되는 코드를 공통 메서드로 추출
조건문 분해복잡한 조건문을 읽기 쉬운 형태로 분해
💡 리팩토링 vs 최적화 차이
리팩토링: 코드 구조 개선 (가독성·유지보수성). 기능 변화 없음
최적화: 성능 향상 (속도·메모리). 내부 구조 변경
둘 다 외부 동작은 동일하게 유지합니다.

코드 악취(Code Smell) — 리팩토링이 필요한 신호

코드 악취증상
긴 메서드하나의 함수가 너무 많은 일을 함 → 메서드 추출 필요
중복 코드같은 코드가 여러 곳에 반복 → 공통 메서드 추출
거대 클래스하나의 클래스가 너무 많은 책임 → 클래스 분리
긴 파라미터 목록함수 파라미터가 4개 이상 → 파라미터 객체 도입
산탄총 수술하나 바꾸면 여러 클래스를 수정해야 함 → 결합도 높음

5. 제품 소프트웨어 패키징

패키징 관련 개념

용어설명
DRM (Digital Rights Management)디지털 콘텐츠의 저작권을 보호하는 기술. 무단 복사·배포 방지
워터마킹콘텐츠에 보이지 않는 저작권 정보를 삽입하는 기술
핑거프린팅구매자 정보를 콘텐츠에 삽입. 불법 유포 시 유포자 추적 가능
패키지 다이어그램UML의 구조 다이어그램 중 하나. 모듈·패키지를 그룹화하여 표현

소프트웨어 버전 관리 전략 (브랜치 전략)

브랜치역할
main/master배포 가능한 안정적인 코드
develop개발 통합 브랜치. 기능 브랜치들이 이곳에 병합
feature기능 개발 브랜치. develop에서 분기, 완료 후 develop에 병합
release배포 준비 브랜치. 최종 버그 수정 후 main에 병합
hotfix운영 중 긴급 버그 수정. main에서 직접 분기
🎯 패키징 빈출 포인트
✔ "디지털 콘텐츠 저작권 보호 기술은?" → DRM
✔ "콘텐츠에 보이지 않는 저작권 정보를 삽입하는 기술은?" → 워터마킹
✔ "구매자 정보를 삽입하여 불법 유포 추적이 가능한 기술은?" → 핑거프린팅

6. 애플리케이션 성능

성능 측정 지표

지표설명
처리량(Throughput)단위 시간에 처리 가능한 트랜잭션 수. 클수록 좋음
응답 시간(Response Time)요청 후 첫 응답까지 걸리는 시간. 짧을수록 좋음
경과 시간(Turnaround Time)요청 후 최종 결과 받기까지의 전체 시간
자원 사용률(Resource Usage)CPU·메모리·디스크·네트워크 사용 비율

성능 개선 기법

기법설명
캐싱(Caching)자주 쓰는 데이터를 메모리에 저장하여 DB 접근 최소화
DB 인덱싱검색 속도 향상을 위해 인덱스(목차)를 생성
커넥션 풀(Connection Pool)DB 연결을 미리 만들어 두고 재사용. 연결 생성 비용 절감
로드 밸런싱여러 서버에 요청을 분산하여 부하 균등 처리
비동기 처리작업 완료를 기다리지 않고 다음 작업을 진행하여 응답 속도 향상
📚 2과목 필기 고득점 전략

① 테스트 7가지 원칙은 설명을 읽고 해당 원칙 이름을 맞히는 연습이 핵심입니다. 특히 "살충제 역설"과 "결함 집중"은 매 회차 출제 수준입니다.

② 형상 관리 도구의 분산형(Git) vs 중앙집중형(SVN, CVS) 구분을 명확히 하세요. "오프라인 커밋 가능 = 분산형 = Git"으로 연결하면 됩니다.

③ DRM·워터마킹·핑거프린팅의 차이를 표로 정리해두면 헷갈리지 않습니다.

④ 커버리지 강도 순서는 반드시 암기하세요. "구결조조MC다"로 소리 내어 외우는 것이 효과적입니다.