정보처리기사 2과목 소프트웨어 개발 핵심 요약 — 테스트·형상관리 완전 정복 | NUGUNA

📚 2과목 소프트웨어 개발, 왜 어렵게 느껴질까

소프트웨어 개발 과목은 테스트 기법, 형상관리(버전관리 포함), 빌드·배포 도구, 소스코드 품질 관리를 다룹니다. 암기보다 "왜 이런 개념이 필요한가"를 이해하면 훨씬 오래 남습니다. 특히 테스트 기법과 형상관리는 필기뿐 아니라 실기(단답형·서술형)에서도 반복 출제되는 핵심 단원이므로, 이 글에서는 두 영역을 시험에 나오는 수준까지 빠짐없이 정리합니다.

📊 출제 빈도 높은 개념

분야	핵심 개념	출제 빈도
테스트 기법	블랙박스·화이트박스 테스트 종류	매회 필수
테스트 원리·레벨	테스트 7원리, 단위·통합·시스템·인수 테스트	매회 출제
형상관리	형상관리 4대 기능, Git·SVN 명령어	매회 출제
빌드 도구	Ant·Maven·Gradle 차이	80% 출제
코드 품질	코드 인스펙션·정적분석 도구	70% 출제

🎯 소프트웨어 테스트의 목적과 7가지 원리

테스트의 목적은 "결함을 모두 제거하는 것"이 아니라 결함의 존재를 발견하고 신뢰성을 높이는 것입니다. 이 차이를 묻는 문제가 꾸준히 출제되므로 아래 7원리를 개념 위주로 이해해두세요.

결함 존재 증명: 테스트는 결함이 있다는 것은 보여줄 수 있어도, 결함이 없다는 것은 증명하지 못한다.
완벽한 테스트 불가능(Exhaustive Testing): 모든 입력·경로를 다 테스트하는 것은 현실적으로 불가능하다.
초기 테스트(Early Testing): 결함은 개발 초기(요구분석·설계 단계)일수록 수정 비용이 적으므로 테스트도 일찍 시작한다.
결함 집중(Defect Clustering): 결함은 소수의 특정 모듈에 몰리는 경향이 있다(파레토 법칙, 80:20).
살충제 패러독스(Pesticide Paradox): 같은 테스트 케이스를 반복하면 더 이상 새로운 결함을 찾지 못하므로 테스트 케이스를 주기적으로 갱신해야 한다.
테스트는 정황 의존적(Context Dependent): 금융 소프트웨어와 게임 소프트웨어는 테스트 방식·강도가 다르다.
오류-부재의 궤변(Absence of Errors Fallacy): 결함을 모두 제거해도 사용자 요구사항을 충족하지 못하면 품질이 좋다고 할 수 없다.

🔍 화이트박스 테스트 — 코드 내부 구조 기반

화이트박스 테스트는 프로그램의 내부 로직·구조를 보면서 테스트 케이스를 설계하는 방식입니다. 대표 기법은 다음과 같습니다.

기초 경로 검사(Basis Path Testing): McCabe가 제안한 기법으로, 순환복잡도(Cyclomatic Complexity)를 계산해 독립 실행 경로 수를 구하고 그 수만큼 테스트 케이스를 설계한다. 계산식은 V(G) = E - N + 2(E: 간선 수, N: 노드 수) 또는 V(G) = 조건문(분기) 개수 + 1로 구한다. 실기 계산 문제로 자주 출제된다.
제어 구조 검사:
- 조건 검사(Condition Testing): 프로그램 내의 논리적 조건식을 테스트한다.
- 루프 검사(Loop Testing): 반복문(단순 루프·중첩 루프·연결 루프)의 경계를 집중적으로 검사한다.
- 데이터 흐름 검사(Data Flow Testing): 변수의 정의(define)와 사용(use) 위치를 추적해 이상 흐름을 찾는다.
커버리지(Coverage) 종류: 구문(Statement) 커버리지 → 분기/결정(Branch/Decision) 커버리지 → 조건(Condition) 커버리지 → 조건/결정(Condition/Decision) 커버리지 → 변경 조건/결정(MC/DC) 커버리지 순으로 검증 강도가 강해진다.

📦 블랙박스 테스트 — 입력·출력 명세 기반

블랙박스 테스트는 내부 구조를 몰라도 입력에 대한 출력이 명세대로 나오는지만 확인하는 방식입니다.

동치 분할(Equivalence Partitioning): 입력 데이터를 유효·무효 클래스로 나누고, 각 클래스에서 대표값 하나만 테스트한다.
경계값 분석(Boundary Value Analysis): 입력 범위의 경계(최솟값, 최댓값, 경계 바로 안팎)에서 결함이 자주 발생한다는 경험에 기반해 경계 부근을 집중 테스트한다.
원인-결과 그래프(Cause-Effect Graphing): 입력 조건(원인)과 결과를 그래프로 표현해 논리적 관계를 정리하고, 이를 결정 테이블로 변환해 테스트 케이스를 도출한다.
오류 예측(Error Guessing): 과거 결함 경험이나 직관을 바탕으로 결함이 발생할 만한 부분을 추측해 테스트한다.
비교 검사(Comparison Testing): 동일 입력에 대해 여러 버전(구현체)의 결과를 비교한다.
결정 테이블(Decision Table) 테스트: 여러 조건 조합에 따른 결과를 표로 정리해 빠짐없이 테스트 케이스를 만든다.

화이트박스 vs 블랙박스 비교

구분	화이트박스 테스트	블랙박스 테스트
기준	내부 로직·구조	입력·출력 명세
대표 기법	기초경로검사, 조건검사, 루프검사, 데이터흐름검사	동치분할, 경계값분석, 원인-결과그래프, 결정테이블
주요 지표	커버리지(구문·분기·조건 등)	명세 충족 여부
주 사용 단계	단위·통합 테스트	시스템·인수 테스트

🧪 테스트 레벨(단위 → 통합 → 시스템 → 인수)

테스트는 개발 단계에 맞춰 아래 순서로 진행되며, 순서 자체를 묻는 문제가 자주 출제됩니다.

단위 테스트(Unit Test): 모듈(함수·클래스) 하나를 독립적으로 검증한다.
통합 테스트(Integration Test): 모듈 간 인터페이스와 상호작용을 검증한다. 방식에 따라 나뉜다.
- 빅뱅(Big Bang) 통합: 모든 모듈을 한 번에 결합해 테스트한다. 문제 위치 파악이 어렵다.
- 하향식(Top-Down) 통합: 상위 모듈부터 결합하며, 미구현 하위 모듈 자리에 스텁(Stub)을 사용한다.
- 상향식(Bottom-Up) 통합: 하위 모듈부터 결합하며, 상위 모듈을 대신할 드라이버(Driver)를 사용한다.
- 샌드위치(Sandwich) 통합: 하향식과 상향식을 혼합한 방식이다.
시스템 테스트(System Test): 전체 시스템이 요구사항(기능·성능·보안 등)을 충족하는지 검증한다.
인수 테스트(Acceptance Test): 실제 사용자·발주자 관점에서 인수 여부를 판단한다. 개발사 내부에서 소수 사용자가 테스트하는 알파 테스트, 실사용 환경에서 다수 사용자가 테스트하는 베타 테스트로 나뉜다.

🗂️ 형상관리(SCM)란 무엇인가

형상관리(Software Configuration Management)는 소프트웨어 개발 전 과정에서 산출되는 요구사항 정의서, 설계서, 소스코드, 매뉴얼 등의 형상 항목(Configuration Item)을 체계적으로 식별하고, 변경 사항을 통제·기록해 산출물의 무결성과 추적성을 유지하는 활동입니다. 버전 관리는 형상관리의 핵심 수단 중 하나일 뿐이며, 형상관리는 그보다 넓은 개념이라는 점이 시험에서 자주 헷갈리는 포인트입니다.

형상관리 4대 기능

기능	설명
형상 식별 (Configuration Identification)	형상 항목을 선정하고 식별번호·버전을 부여해 관리 대상을 명확히 한다.
형상 통제 (Configuration Control)	변경 요청을 검토·승인하고 반영하는 절차. 형상통제위원회(CCB, Configuration Control Board)가 승인 여부를 결정한다.
형상 감사 (Configuration Audit)	변경이 요구사항대로 정확히 이루어졌는지 검증. 기능적 요구사항 충족을 확인하는 기능 감사(FCA)와 실제 물리적 산출물을 확인하는 물리 감사(PCA)로 나뉜다.
형상 기록 (Configuration Status Accounting)	형상 항목의 변경 이력과 처리 상태를 기록·보고해 추적 가능하게 한다.

🔧 버전관리 도구 — SVN과 Git

버전관리 방식은 저장소 구조에 따라 나뉩니다.

공유 폴더 방식: 로컬 저장소를 여러 사람이 공유 폴더로 접근한다(예: RCS). 소규모에 적합하다.
클라이언트/서버 방식(중앙집중형): 중앙 서버에 저장소를 두고 클라이언트가 접근한다. CVS, SVN(Subversion)이 대표적이며, 서버가 다운되면 버전 관리 자체가 불가능하다는 한계가 있다.
분산 저장소 방식(분산형): 각 개발자가 로컬에도 저장소 전체 사본을 가진다. Git이 대표적이며, 오프라인에서도 커밋이 가능하고 원격 저장소(GitHub 등)와 별도로 로컬 이력 관리를 한다.

Git의 기본 명령어와 의미는 실기에서 서술형으로도 나올 수 있으니 흐름 위주로 기억하세요.

git init — 로컬 저장소 생성
git add — 변경 파일을 스테이징 영역에 등록
git commit — 스테이징된 변경 사항을 로컬 저장소에 기록
git branch — 브랜치 생성·조회, 기능 단위 병렬 개발에 사용
git merge — 다른 브랜치의 변경 사항을 현재 브랜치에 병합
git clone — 원격 저장소를 로컬로 복제
git push / git pull — 로컬 변경을 원격에 반영 / 원격 변경을 로컬로 가져와 병합
git fetch — 원격 변경 이력만 가져오고 병합은 별도로 수행

🚀 빌드 도구와 배포 파이프라인

형상관리로 정리된 소스코드는 빌드 도구를 거쳐 실행 가능한 산출물로 만들어지고, CI/CD(지속적 통합·배포) 파이프라인을 통해 자동으로 테스트·배포됩니다. 형상관리 → 빌드 → 테스트 → 배포로 이어지는 흐름을 이해하면 관련 문제를 통으로 풀 수 있습니다.

Ant: XML 기반으로 빌드 절차를 직접 기술하는 절차적 방식. 자유도는 높지만 설정이 장황해질 수 있다.
Maven: POM.xml로 프로젝트 구조와 의존성을 선언하며, 정해진 빌드 생명주기(Lifecycle)를 따른다. 의존성 자동 관리가 강점이다.
Gradle: Groovy/Kotlin DSL 기반으로 설정이 간결하고, 증분 빌드(변경분만 재빌드)로 속도가 빠르다. 안드로이드 공식 빌드 도구로 채택되어 있다.

빌드 산출물은 최종적으로 패키징되어 배포되며, 이때 변경 이력·설치 방법·주의사항을 담은 릴리즈 노트를 함께 작성하는 것이 표준 절차입니다.

📌 자주 출제되는 용어 한눈에 정리

스텁(Stub) / 드라이버(Driver): 하향식·상향식 통합 테스트에서 각각 하위·상위 모듈을 대신하는 임시 모듈
순환복잡도(Cyclomatic Complexity): 프로그램의 독립 실행 경로 수를 나타내는 정량 지표
회귀 테스트(Regression Test): 변경 이후 기존 기능이 정상 동작하는지 재확인하는 테스트
형상통제위원회(CCB): 변경 요청의 승인·반려를 결정하는 조직
정적 분석 / 동적 분석: 코드를 실행하지 않고 분석(정적) / 실제 실행하며 분석(동적)
코드 인스펙션(Code Inspection): 정해진 규칙에 따라 동료가 코드를 검토하는 정적 분석 기법의 일종

❓ 자주 묻는 질문

Q. Git 명령어를 실제로 다 외워야 하나요?: 필기에서는 개념과 용도를 구분하는 수준이면 충분합니다. commit·push·pull·branch·merge의 차이와 중앙집중형(SVN) vs 분산형(Git)의 구조 차이를 확실히 이해하세요.
Q. 순환복잡도 계산 문제, 실수하기 쉬운 함정은?: 제어 흐름도의 노드·간선을 잘못 세는 경우가 가장 흔합니다. 조건문(분기) 개수를 먼저 세고 "조건문 개수 + 1" 공식으로 검산하면 실수를 줄일 수 있습니다.
Q. 테스트와 형상관리, 어떤 순서로 공부하는 게 좋나요?: 테스트 기법(화이트박스·블랙박스) → 테스트 레벨 → 형상관리 4대 기능 → 버전관리 도구 → 빌드 도구 순으로 학습하면, 개발 프로세스 흐름을 따라가며 자연스럽게 암기할 수 있습니다.

🚀 자격증 취득 시작

IT 자격증 강의에서 정보처리기사 2과목을 실기까지 이어지는 흐름으로 한번에 정복하세요.

📚 2과목 소프트웨어 개발, 왜 어렵게 느껴질까

📊 출제 빈도 높은 개념

분야	핵심 개념	출제 빈도
테스트 기법	블랙박스·화이트박스 테스트 종류	매회 필수
테스트 원리·레벨	테스트 7원리, 단위·통합·시스템·인수 테스트	매회 출제
형상관리	형상관리 4대 기능, Git·SVN 명령어	매회 출제
빌드 도구	Ant·Maven·Gradle 차이	80% 출제
코드 품질	코드 인스펙션·정적분석 도구	70% 출제

🎯 소프트웨어 테스트의 목적과 7가지 원리

결함 존재 증명: 테스트는 결함이 있다는 것은 보여줄 수 있어도, 결함이 없다는 것은 증명하지 못한다.
완벽한 테스트 불가능(Exhaustive Testing): 모든 입력·경로를 다 테스트하는 것은 현실적으로 불가능하다.
초기 테스트(Early Testing): 결함은 개발 초기(요구분석·설계 단계)일수록 수정 비용이 적으므로 테스트도 일찍 시작한다.
결함 집중(Defect Clustering): 결함은 소수의 특정 모듈에 몰리는 경향이 있다(파레토 법칙, 80:20).
살충제 패러독스(Pesticide Paradox): 같은 테스트 케이스를 반복하면 더 이상 새로운 결함을 찾지 못하므로 테스트 케이스를 주기적으로 갱신해야 한다.
테스트는 정황 의존적(Context Dependent): 금융 소프트웨어와 게임 소프트웨어는 테스트 방식·강도가 다르다.
오류-부재의 궤변(Absence of Errors Fallacy): 결함을 모두 제거해도 사용자 요구사항을 충족하지 못하면 품질이 좋다고 할 수 없다.

🔍 화이트박스 테스트 — 코드 내부 구조 기반

화이트박스 테스트는 프로그램의 내부 로직·구조를 보면서 테스트 케이스를 설계하는 방식입니다. 대표 기법은 다음과 같습니다.

기초 경로 검사(Basis Path Testing): McCabe가 제안한 기법으로, 순환복잡도(Cyclomatic Complexity)를 계산해 독립 실행 경로 수를 구하고 그 수만큼 테스트 케이스를 설계한다. 계산식은 V(G) = E - N + 2(E: 간선 수, N: 노드 수) 또는 V(G) = 조건문(분기) 개수 + 1로 구한다. 실기 계산 문제로 자주 출제된다.
제어 구조 검사:
- 조건 검사(Condition Testing): 프로그램 내의 논리적 조건식을 테스트한다.
- 루프 검사(Loop Testing): 반복문(단순 루프·중첩 루프·연결 루프)의 경계를 집중적으로 검사한다.
- 데이터 흐름 검사(Data Flow Testing): 변수의 정의(define)와 사용(use) 위치를 추적해 이상 흐름을 찾는다.
커버리지(Coverage) 종류: 구문(Statement) 커버리지 → 분기/결정(Branch/Decision) 커버리지 → 조건(Condition) 커버리지 → 조건/결정(Condition/Decision) 커버리지 → 변경 조건/결정(MC/DC) 커버리지 순으로 검증 강도가 강해진다.

📦 블랙박스 테스트 — 입력·출력 명세 기반

블랙박스 테스트는 내부 구조를 몰라도 입력에 대한 출력이 명세대로 나오는지만 확인하는 방식입니다.

동치 분할(Equivalence Partitioning): 입력 데이터를 유효·무효 클래스로 나누고, 각 클래스에서 대표값 하나만 테스트한다.
경계값 분석(Boundary Value Analysis): 입력 범위의 경계(최솟값, 최댓값, 경계 바로 안팎)에서 결함이 자주 발생한다는 경험에 기반해 경계 부근을 집중 테스트한다.
원인-결과 그래프(Cause-Effect Graphing): 입력 조건(원인)과 결과를 그래프로 표현해 논리적 관계를 정리하고, 이를 결정 테이블로 변환해 테스트 케이스를 도출한다.
오류 예측(Error Guessing): 과거 결함 경험이나 직관을 바탕으로 결함이 발생할 만한 부분을 추측해 테스트한다.
비교 검사(Comparison Testing): 동일 입력에 대해 여러 버전(구현체)의 결과를 비교한다.
결정 테이블(Decision Table) 테스트: 여러 조건 조합에 따른 결과를 표로 정리해 빠짐없이 테스트 케이스를 만든다.

화이트박스 vs 블랙박스 비교

구분	화이트박스 테스트	블랙박스 테스트
기준	내부 로직·구조	입력·출력 명세
대표 기법	기초경로검사, 조건검사, 루프검사, 데이터흐름검사	동치분할, 경계값분석, 원인-결과그래프, 결정테이블
주요 지표	커버리지(구문·분기·조건 등)	명세 충족 여부
주 사용 단계	단위·통합 테스트	시스템·인수 테스트

🧪 테스트 레벨(단위 → 통합 → 시스템 → 인수)

테스트는 개발 단계에 맞춰 아래 순서로 진행되며, 순서 자체를 묻는 문제가 자주 출제됩니다.

단위 테스트(Unit Test): 모듈(함수·클래스) 하나를 독립적으로 검증한다.
통합 테스트(Integration Test): 모듈 간 인터페이스와 상호작용을 검증한다. 방식에 따라 나뉜다.
- 빅뱅(Big Bang) 통합: 모든 모듈을 한 번에 결합해 테스트한다. 문제 위치 파악이 어렵다.
- 하향식(Top-Down) 통합: 상위 모듈부터 결합하며, 미구현 하위 모듈 자리에 스텁(Stub)을 사용한다.
- 상향식(Bottom-Up) 통합: 하위 모듈부터 결합하며, 상위 모듈을 대신할 드라이버(Driver)를 사용한다.
- 샌드위치(Sandwich) 통합: 하향식과 상향식을 혼합한 방식이다.
시스템 테스트(System Test): 전체 시스템이 요구사항(기능·성능·보안 등)을 충족하는지 검증한다.
인수 테스트(Acceptance Test): 실제 사용자·발주자 관점에서 인수 여부를 판단한다. 개발사 내부에서 소수 사용자가 테스트하는 알파 테스트, 실사용 환경에서 다수 사용자가 테스트하는 베타 테스트로 나뉜다.

🗂️ 형상관리(SCM)란 무엇인가

형상관리 4대 기능

기능	설명
형상 식별 (Configuration Identification)	형상 항목을 선정하고 식별번호·버전을 부여해 관리 대상을 명확히 한다.
형상 통제 (Configuration Control)	변경 요청을 검토·승인하고 반영하는 절차. 형상통제위원회(CCB, Configuration Control Board)가 승인 여부를 결정한다.
형상 감사 (Configuration Audit)	변경이 요구사항대로 정확히 이루어졌는지 검증. 기능적 요구사항 충족을 확인하는 기능 감사(FCA)와 실제 물리적 산출물을 확인하는 물리 감사(PCA)로 나뉜다.
형상 기록 (Configuration Status Accounting)	형상 항목의 변경 이력과 처리 상태를 기록·보고해 추적 가능하게 한다.

🔧 버전관리 도구 — SVN과 Git

버전관리 방식은 저장소 구조에 따라 나뉩니다.

공유 폴더 방식: 로컬 저장소를 여러 사람이 공유 폴더로 접근한다(예: RCS). 소규모에 적합하다.
클라이언트/서버 방식(중앙집중형): 중앙 서버에 저장소를 두고 클라이언트가 접근한다. CVS, SVN(Subversion)이 대표적이며, 서버가 다운되면 버전 관리 자체가 불가능하다는 한계가 있다.
분산 저장소 방식(분산형): 각 개발자가 로컬에도 저장소 전체 사본을 가진다. Git이 대표적이며, 오프라인에서도 커밋이 가능하고 원격 저장소(GitHub 등)와 별도로 로컬 이력 관리를 한다.

Git의 기본 명령어와 의미는 실기에서 서술형으로도 나올 수 있으니 흐름 위주로 기억하세요.

git init — 로컬 저장소 생성
git add — 변경 파일을 스테이징 영역에 등록
git commit — 스테이징된 변경 사항을 로컬 저장소에 기록
git branch — 브랜치 생성·조회, 기능 단위 병렬 개발에 사용
git merge — 다른 브랜치의 변경 사항을 현재 브랜치에 병합
git clone — 원격 저장소를 로컬로 복제
git push / git pull — 로컬 변경을 원격에 반영 / 원격 변경을 로컬로 가져와 병합
git fetch — 원격 변경 이력만 가져오고 병합은 별도로 수행

🚀 빌드 도구와 배포 파이프라인

Ant: XML 기반으로 빌드 절차를 직접 기술하는 절차적 방식. 자유도는 높지만 설정이 장황해질 수 있다.
Maven: POM.xml로 프로젝트 구조와 의존성을 선언하며, 정해진 빌드 생명주기(Lifecycle)를 따른다. 의존성 자동 관리가 강점이다.
Gradle: Groovy/Kotlin DSL 기반으로 설정이 간결하고, 증분 빌드(변경분만 재빌드)로 속도가 빠르다. 안드로이드 공식 빌드 도구로 채택되어 있다.

📌 자주 출제되는 용어 한눈에 정리

스텁(Stub) / 드라이버(Driver): 하향식·상향식 통합 테스트에서 각각 하위·상위 모듈을 대신하는 임시 모듈
순환복잡도(Cyclomatic Complexity): 프로그램의 독립 실행 경로 수를 나타내는 정량 지표
회귀 테스트(Regression Test): 변경 이후 기존 기능이 정상 동작하는지 재확인하는 테스트
형상통제위원회(CCB): 변경 요청의 승인·반려를 결정하는 조직
정적 분석 / 동적 분석: 코드를 실행하지 않고 분석(정적) / 실제 실행하며 분석(동적)
코드 인스펙션(Code Inspection): 정해진 규칙에 따라 동료가 코드를 검토하는 정적 분석 기법의 일종

❓ 자주 묻는 질문

Q. Git 명령어를 실제로 다 외워야 하나요?: 필기에서는 개념과 용도를 구분하는 수준이면 충분합니다. commit·push·pull·branch·merge의 차이와 중앙집중형(SVN) vs 분산형(Git)의 구조 차이를 확실히 이해하세요.
Q. 순환복잡도 계산 문제, 실수하기 쉬운 함정은?: 제어 흐름도의 노드·간선을 잘못 세는 경우가 가장 흔합니다. 조건문(분기) 개수를 먼저 세고 "조건문 개수 + 1" 공식으로 검산하면 실수를 줄일 수 있습니다.
Q. 테스트와 형상관리, 어떤 순서로 공부하는 게 좋나요?: 테스트 기법(화이트박스·블랙박스) → 테스트 레벨 → 형상관리 4대 기능 → 버전관리 도구 → 빌드 도구 순으로 학습하면, 개발 프로세스 흐름을 따라가며 자연스럽게 암기할 수 있습니다.

🚀 자격증 취득 시작

IT 자격증 강의에서 정보처리기사 2과목을 실기까지 이어지는 흐름으로 한번에 정복하세요.

정보처리기사 2과목 소프트웨어 개발 핵심 요약 — 테스트·형상관리 완전 정복

📚 2과목 소프트웨어 개발, 왜 어렵게 느껴질까

📊 출제 빈도 높은 개념

🎯 소프트웨어 테스트의 목적과 7가지 원리

🔍 화이트박스 테스트 — 코드 내부 구조 기반

📦 블랙박스 테스트 — 입력·출력 명세 기반

화이트박스 vs 블랙박스 비교

🧪 테스트 레벨(단위 → 통합 → 시스템 → 인수)

🗂️ 형상관리(SCM)란 무엇인가

형상관리 4대 기능

🔧 버전관리 도구 — SVN과 Git

🚀 빌드 도구와 배포 파이프라인

📌 자주 출제되는 용어 한눈에 정리

❓ 자주 묻는 질문

🚀 자격증 취득 시작

댓글

관련 글

정보처리기사 2과목 소프트웨어 개발 핵심 요약 — 테스트·형상관리 완전 정복

📚 2과목 소프트웨어 개발, 왜 어렵게 느껴질까

📊 출제 빈도 높은 개념

🎯 소프트웨어 테스트의 목적과 7가지 원리

🔍 화이트박스 테스트 — 코드 내부 구조 기반

📦 블랙박스 테스트 — 입력·출력 명세 기반

화이트박스 vs 블랙박스 비교

🧪 테스트 레벨(단위 → 통합 → 시스템 → 인수)

🗂️ 형상관리(SCM)란 무엇인가

형상관리 4대 기능

🔧 버전관리 도구 — SVN과 Git

🚀 빌드 도구와 배포 파이프라인

📌 자주 출제되는 용어 한눈에 정리

❓ 자주 묻는 질문

🚀 자격증 취득 시작

댓글

관련 글