정보처리기사 실기 — 1. 소프트웨어 구축

정처기 실기 6과목 중 소프트웨어 구축만 우선 정리.
나머지 5과목(데이터베이스 구축, 운영체제, 네트워크, 정보보안, 프로그래밍 언어)은 추후 추가 예정.

---

0. 과목 구조 한눈에 (시험용 지도)

---

1. 현행 시스템 분석 및 요구사항 확인

1.1 현행 시스템 분석

• 목적: 개발 범위 확인, 기술 요소·SW·HW·기능·타 시스템과의 정보 교환 파악.
• 파악 절차: 시스템 구성 → 기능 → 인터페이스 현황 → 아키텍처·SW 구성 → HW·네트워크.

주요 분석 항목

1.2 요구사항 확인

• 요구사항 개발 프로세스: 도출 → 분석 → 명세 → 확인.
• 분류:
  • 기능 요구사항: 기능성, 완전성, 일관성.
  • 비기능 요구사항: 성능, 보안, 품질, 안정성, 사용성.
• 도출 기법: 인터뷰, 설문, 브레인스토밍, 워크숍, 현장 관찰.
• 확인 기법: 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트.
• 기술적 타당성: 성능·용량 산정, 상호 운용성, 시장 성숙도·트렌드, 기술적 위험.

1.3 요구사항 분석 도구

★ DFD(자료흐름도) 구성 요소

• 처리(Process), 자료 흐름, 자료 저장소, 외부 엔티티(단말).
• 입력 화살표만 있고 출력이 없어도 됨(필수 대칭 아님).
• 자료저장소 입력 화살표 = 데이터 입력·수정 의미.

자료사전(DD): DFD의 자료를 상세 정의·기록.
=(정의), +(선택), {}(반복), [](생략), ()(순서 무관), **(주석) 등 표기.

소단위명세서(Mini-Spec): 처리(Process)의 세부 로직을 기술.

---

2. 데이터 입출력 구현 (DB 설계, 조작 프로시저)

• 애플리케이션이 데이터를 읽고·가공하고·저장·출력하는 구현 영역.
• 시험에서는 논리/물리 저장소, 정규화, SQL, 조인, JDBC, 해싱이 자주 섞여 출제됨.

2.1 논리 vs 물리 데이터 저장소

데이터 정의(자주 나오는 문장)

• 통합 데이터: 중복 최소화, 일관성 유지.
• 저장 데이터: 저장 매체에 존재하는 데이터.
• 운영 데이터: 업무 수행에 실질적으로 필요한 데이터.
• 공용 데이터: 여러 응용이 공동으로 사용·유지.

2.2 DB 설계

설계 단계

1. 개념적 설계: E-R 다이어그램 — 엔티티, 속성, 관계(1:1, 1:N, N:M).
2. 논리적 설계: 관계형 스키마, 정규화.
3. 물리적 설계: 인덱스, 파티셔닝, 저장 구조.

정규화(1NF ~ 3NF)

2.3 SQL — DDL / DML / DCL

조인(Join)

2.4 조작 프로시저(Stored Procedure)

• DBMS에 저장·컴파일되어 호출로 실행되는 SQL·로직 묶음.
• 장점: 네트워크 트래픽 감소, 보안(직접 SQL 노출 최소), 재사용·일관성.
• 단점: DB 종속, 디버깅·버전 관리 어려움.
• 트리거(Trigger): 특정 이벤트(INSERT/UPDATE/DELETE) 발생 시 자동 실행 — 프로시저와 구분.

2.5 JDBC(자바 DB 연동) 흐름

1. JDBC 드라이버 로드
2. Connection 획득
3. Statement / PreparedStatement 생성 — PreparedStatement는 파라미터 바인딩에 유리
4. 실행 → ResultSet 순회(또는 갱신 카운트)
5. 자원 해제(close) 및 커밋/롤백

2.6 해싱 — 함수 vs 충돌 처리 구분

해싱 함수(주소 계산): 제산법, 제곱 중간법, 폴딩, 기수 변환법, 숫자 분석법, 무작위법.

충돌 처리(별도 개념): 개방 주소법, 체이닝 — "함수 종류"가 아님.

---

3. 통합 구현 (모듈 연계)

• 개별 모듈·시스템을 연계·조립해 동작 가능한 형태로 만드는 활동.
• 시험에서는 형상 관리, 빌드 도구, 미들웨어·EAI, IPC, 통합 테스트 전략이 한 세트로 출제됨.

3.1 형상 관리(Configuration Management)

• 목적: 산출물의 변경 이력·버전·병합을 체계적으로 관리.
• 대표 도구: CVS, SVN, Git.
• 용어: 저장소, 체크아웃/커밋, 브랜치·머지, 태그.

형상 관리 도구 유형

3.2 빌드·자동화

• CI(지속적 통합): 변경을 자주 통합하고 자동 빌드·테스트 — Jenkins 등.

3.3 미들웨어·EAI

미들웨어: 분산 환경에서 애플리케이션과 OS·DB·네트워크 사이를 매개.

EAI 연계 방식

• Point-to-Point: 1:1 직접 연결 — 단순, 관리 난이도↑
• Hub & Spoke: 허브가 중앙 라우팅·변환
• Message Bus(ESB): 메시지 버스 기반 느슨한 결합
• Hybrid: 위 방식 조합

3.4 IPC(프로세스 간 통신)

• 공유 메모리, 세마포어, 소켓, 메시지 큐, 파이프(일반/Named).

3.5 통합 테스트 — 스텁·드라이버 ★

---

4. 서버 프로그램 구현 (형상 관리, 공통 모듈, 테스트)

• 업무 프로세스를 기반으로 서비스 제공에 필요한 서버 로직을 구현하는 영역.
• 시험에서는 개발환경 구축, 형상 관리 절차, 공통 모듈 구현 절차, MVC, 배치 프로그램이 핵심.

4.1 개발환경 구축

서버 환경 구성

개발 도구 분류

4.2 형상 관리 절차 ★

• 소프트웨어 개발 전 과정의 변경 사항을 관리하는 활동.
• 유지보수 단계에도 지속. 전체 비용 절감·문제 요인 최소화 목적.

형상 관리 4단계(암기: 식통감기)

• 베이스라인(Baseline): 각 단계 산출물 변화를 통제하는 기준 시점.

4.3 공통 모듈 구현

• 모듈: 기능 단위로 분해·추상화하여 재사용·공유 가능한 단위.
• 모듈화: 성능 향상, 디버깅·수정·통합 용이.
• 공통 모듈: 자주 쓰는 기능을 독립 패키지로 제공 — 화면, 서비스, 트랜잭션 컴포넌트 등.

설계 원칙: 낮은 결합도, 높은 응집도.

공통 모듈 구현 절차 ★

DTO/VO 정의 → SQL 작성 → DAO 구현 → Service 구현 → Controller 구현 → View(화면)

MVC 패턴

재사용 수준: 함수/객체 → 컴포넌트 → 애플리케이션.

4.4 배치 프로그램

• 대량 데이터를 정해진 시간·주기에 자동 처리.
• 예: 일마감, 정산, 로그 집계, 데이터 동기화.
• 온라인(OLTP) vs 배치 — 실시간 트랜잭션 vs 주기적 일괄 처리.

4.5 서버 프로그램 테스트

• 공통 모듈 테스트: 화이트박스 — IDE 디버깅, 단위 테스트.
• 팬 인(Fan-In): 한 모듈에 들어오는 모듈 수.
• 팬 아웃(Fan-Out): 한 모듈에서 나가는 모듈 수.

---

5. 인터페이스 구현 (설계·기능 구현·검증)

• 시스템·모듈·외부와의 데이터 교환 규약을 설계·구현·검증하는 영역.

5.1 인터페이스 설계 산출물

5.2 데이터 교환 형식

JSON

• 속성-값 쌍 경량 데이터 교환. 배열·객체 중첩.

XML

• 확장 가능한 마크업. 사용자 정의 태그로 구조화.
• Well-formed(문법) vs Valid(DTD/스키마 유효성).

AJAX

• 페이지 전체 새로고침 없이 서버와 비동기 통신 → 일부 영역만 갱신.

RESTful API

• 리소스 중심 URI, HTTP 메서드(GET/POST/PUT/DELETE), 무상태성.
• SOAP과 대비: SOAP는 메시지·엔벨로프 중심 프로토콜.

5.3 인터페이스 요구사항 검증

5.4 미들웨어(인터페이스 관점)

---

6. 화면 설계 (UI 요구사항, 프로토타입)

6.1 사용자 인터페이스 구분

6.2 UI 기본 원칙(4가지) ★

• 직관성: 누구나 쉽게 이해·사용.
• 유효성: 사용자 목적을 정확히 달성.
• 학습성: 쉽게 배우고 익힘.
• 유연성: 요구사항을 최대한 수용.

6.3 UI 설계 도구

6.4 UI 요구사항·설계 프로세스

• UI 시나리오 문서 요건: 추적 용이성, 수정 용이성, 가독성, 일관성, 완전성, 이해성.
• 설계 프로세스: 문제 정의 → 사용자 모델 → 작업 분석 → 오브젝트·기능 정의 → UI 정의 → 디자인 평가.
• 10대 원칙(한국HCI연구회): 가시성, 조작결과 예측성, 일관성, 단순성, 지식배분, 조작오류 방지, 제한사항 선택, 표준화, 행동유도성, 접근성.

---

7. 애플리케이션 테스트 (케이스 설계, 통합 테스트)

• 결함을 조기·체계적으로 찾아 품질 리스크를 낮추는 활동.

7.1 Verification vs Validation ★

7.2 테스트 레벨

7.3 테스트 설계 기법

명세 기반(블랙박스)

• 동치 분할: 입력을 동등 결과 클래스로 나눠 대표값 테스트.
• 경계값 분석: 경계·경계±1 — 취약점 많음.
• 결정 테이블, 상태 전이, 유스케이스 기반.

구조 기반(화이트박스)

• 문장/분기/조건/경로 커버리지.
• 구분 커버리지·결정 커버리지 → 구조 기반.
• 기초 경로 검사, 제어 구조 검사, 데이터 흐름 검사, 루프 검사.

7.4 테스트 케이스·시나리오·오라클

• 테스트 케이스: 식별자, 입력/전제 조건, 기대 결과, 환경.
• 테스트 시나리오: 여러 케이스를 업무 흐름·우선순위로 묶은 수행 절차 문서.
• 테스트 오라클: 결과가 옳은지 판단하는 기준(기대값·규칙).

7.5 리뷰 — 워크스루 vs 인스펙션

• 워크스루: 비형식적, 작성자 중심 설명.
• 인스펙션: 형식적, 역할 분담·체크리스트 — 조기 결함 발견이 핵심.

---

8. 제품 소프트웨어 패키징 (버전 관리, 매뉴얼 작성)

• 개발 산출물을 배포 가능한 형태로 묶고, 설치·운영·사용 정보를 제공.

8.1 패키징·배포 흐름

• 기능·모듈 식별 → 빌드 → 적용 시험(설치·구동 검증) → 배포 → 수정·재배포.
• 모듈화: 기능 단위 정리 — 실행 파일 생성은 주로 빌드 단계.

8.2 버전 관리

• 형상 관리와 연계 — 릴리즈 태그, 변경 이력, 호환성 명시.
• 릴리즈 노트(Release Note): 변경 기능, 수정 결함, 호환성·업그레이드 주의, 영향 범위.

8.3 매뉴얼 ★

8.4 DRM·오픈소스(개념)

DRM 주요 역할(용어 혼동 주의)

• 클리어링 하우스: 권한·과금·라이선스 거래 처리.
• 보안 컨테이너: 콘텐츠 안전 유통·보호 — 역할 뒤바꾸기 오답 주의.

오픈소스 라이선스

---

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

• 하향식=스텁, 상향식=드라이버 — 방향 뒤집힌 지문 주의.
• 형상 관리 4단계: 식별 → 통제 → 감사 → 기록 (식통감기).
• 공통 모듈 구현 순서: DTO/VO → SQL → DAO → Service → Controller.
• Verification(명세 일치) vs Validation(요구 충족) 문장 바꿔 놓는 오답 주의.
• 해싱 함수 종류 vs 충돌 처리 — 다른 카테고리.
• 단위 테스트=화이트박스, 동치·경계=블랙박스.
• 테스트 시나리오=케이스 묶음+수행 절차 — 케이스 나열과 구분.
• DRM 클리어링 하우스 vs 보안 컨테이너 역할 혼동 주의.
• UI 4원칙: 직관·유효·학습·유연.
• JSON=속성-값, XML=확장 마크업, AJAX=비동기 부분 갱신.

---

10. 스스로 검토할 때 쓰는 오답 노트(빈칸)

1. 형상 관리 절차 4단계: (　　　) → 통제 → 감사 → 기록
2. 하향식 통합 테스트에서 쓰는 보조 모듈은 (　　　) 이다.
3. 공통 모듈 구현 시 DB 접근 추상화 객체는 (　　　) 이다.
4. "올바른 것을 만들었는가"를 확인하는 것은 (　　　) 이다.
5. UI 설계에서 테스트 가능한 동적 모형은 (　　　) 이다.

---