[정처기 필기] 2. 소프트웨어 개발
소프트웨어 개발 - 데이터 입출력 · 통합 · 패키징 · 테스트 · 인터페이스
1. 데이터 입출력 구현
- 애플리케이션이 데이터를 읽고·가공하고·저장·출력하는 구현을 다룸.
- 시험에서는 논리/물리 저장소 구분, 파일·DB 접근 개념, SQL·조인, JDBC 흐름, 해싱(함수 vs 충돌 처리) 등이 자주 섞여 출제됨.
1.1 논리 데이터 저장소 vs 물리 데이터 저장소
| 구분 | 설명 |
|---|---|
| 논리 데이터 저장소 | 데이터·데이터 간 연관·제약을 식별해 논리적 구조로 조직화한 저장 관점(구현 매체와 독립에 가깝게 이해) |
| 물리 데이터 저장소 | 논리 구조를 실제 하드웨어·파일·DB 페이지 등 운용 환경에 맞게 구체화해 둔 저장 |
1.2 데이터베이스 관점의 데이터 정의(자주 나오는 문장)
- 통합 데이터: 중복을 최소화해 일관되게 유지하려는 데이터 집합.
- 저장 데이터: 컴퓨터가 접근 가능한 저장 매체에 존재하는 데이터.
- 운영 데이터: 조직 업무 수행에 실질적으로 필요한 데이터.
- 공용 데이터: 여러 응용이 공동으로 사용·유지하는 데이터.
1.3 파일·저장 접근(개념)
- 순차 파일: 레코드를 물리적 순서대로 저장·접근(삽입·삭제 시 재배열 비용이 큰 편).
- 직접(랜덤) 파일: 키·상대 주소 등으로 원하는 레코드 위치에 직접 접근.
- 색인 순차: 색인으로 탐색 범위를 줄이고, 실제 데이터는 순차 영역에 두는 방식(교재·시험에서 “색인”과 “순차”의 결합으로 설명되는 경우가 많음).
1.4 SQL 기초(입출력 구현과 맞닿는 부분)
- DDL: 구조 정의(
CREATE,ALTER,DROP등). - DML: 데이터 조작(
SELECT,INSERT,UPDATE,DELETE). - DCL: 접근 통제(
GRANT,REVOKE등) — 교재에 따라 “제어 기능” 범주로 묶이는 경우가 많음.
조인(Join) 한눈에
| 유형 | 요지 |
|---|---|
| 내부 조인(INNER) | 양쪽에 매칭되는 행만 결과에 포함 |
| 외부 조인(LEFT/RIGHT/FULL) | 한쪽에만 있어도 기준 테이블 쪽 행은 유지하고, 없는 쪽은 NULL로 채움 |
| 교차 조인(CROSS) | 가능한 모든 조합(카티션 곱) — 조건 없이 쓰면 결과 폭증에 유의 |
| 자체 조인(SELF) | 동일 테이블을 별칭으로 두 번 두고 행 간 관계를 표현 |
1.5 JDBC(자바 DB 연동) 흐름(개념)
- JDBC 드라이버 로드(또는 드라이버 매니저를 통한 등록)
Connection획득(URL, 계정 등)Statement/PreparedStatement생성 — PreparedStatement는 SQL 파라미터 바인딩에 유리(바인딩 변수 처리)- 실행 →
ResultSet으로 조회 결과 순회(또는 갱신 카운트) - 사용 역순으로 자원 해제(
close) 및 필요 시 커밋/롤백
1.6 해싱(Hashing) — “함수 종류” vs “충돌 처리” 구분
해싱 함수(주소 계산 방식) 예
- 제산법: 키를 소수(보통 표 크기에 맞는 소수)로 나눈 나머지를 주소로 사용.
- 제곱 중간법: 키를 제곱한 뒤 중간 자릿수를 추려 주소로 사용.
- 폴딩(Folding): 키를 여러 부분으로 나눠 합/XOR 등으로 주소 생성.
- 기수 변환법: 진수 변환 후 일부 자릿수를 잘라 주소 범위에 맞춤.
- 숫자 분석법(계수 분석법): 키 숫자 분포를 보고 고른 자리를 택해 주소 생성.
- 무작위법: 난수 기반 주소.
충돌 처리(별도 개념)
예: 개방 주소법(Open Addressing), 체이닝 등은 “해싱 함수의 종류”가 아니라 충돌이 났을 때의 처리 기법으로 분류하는 것이 일반적이며, 시험에서 이 구분을 그대로 묻는 경우가 있음.
2. 통합 구현
- 개별 모듈·시스템을 연계·조립해 동작 가능한 형태로 만드는 활동.
- 시험에서는 형상 관리, 빌드 도구, 미들웨어·EAI, IPC, **통합 테스트 전략(스텁/드라이버)**이 한 세트로 자주 출제됨.
2.1 형상 관리(Configuration Management)
- 목적: 산출물의 변경 이력·버전·병합을 체계적으로 관리해 재현 가능한 빌드/배포를 지원.
- 대표 도구: CVS, SVN, Git 등.
- 흔한 용어(도구마다 표현은 다름): 저장소(Repository), 체크아웃/체크인 또는 커밋, 업데이트(동기화), 브랜치·머지, 태그(릴리즈 지점 표시).
2.2 빌드·자동화
| 도구 | 특징(시험 관점) |
|---|---|
| Ant | XML 기반 빌드 스크립트, 자바 생태계에서 오래된 빌드 도구로 자주 언급 |
| Maven | POM·의존성(Dependency) 중심 관리, 표준 디렉터리·라이프사이클 |
| Gradle | DSL 기반 스크립트 + 의존성/태스크 유연성 |
- CI(지속적 통합): 변경을 자주 통합하고 자동 빌드·테스트로 회귀를 조기에 발견하는 흐름(대표 도구로 Jenkins 등이 자주 등장).
2.3 미들웨어(Middleware)
- 분산 환경에서 애플리케이션과 OS·DB·네트워크 사이를 매개하는 중간 소프트웨어.
- 분류 예:
- RPC: 원격 프로시저 호출
- MOM: 메시지 지향(큐 기반 비동기 연계)
- ORB: 객체 요청 중개(분산 객체)
- DB 미들웨어: ODBC, JDBC 등 DB 접근 표준/드라이버 층
2.4 EAI(Enterprise Application Integration)
- 기업 내 이기종 애플리케이션·DB를 업무 단위로 연계하는 구조.
- 연계 방식 예:
- Point-to-Point: 시스템 간 1:1 직접 연결 — 단순하나 연결 수 증가로 관리 난이도 상승
- Hub & Spoke: 허브가 중앙에서 라우팅·변환
- Message Bus(ESB 성격): 메시지 버스 기반 느슨한 결합
- Hybrid: 위 방식의 조합
2.5 IPC(프로세스 간 통신)
- 공유 메모리, 세마포어, 소켓, 메시지 큐, 파이프(일반/Named) 등이 대표 예시로 묶여 출제되는 경우가 많음.
2.6 통합 테스트와 스텁·드라이버(암기 정확도 최우선)
| 통합 전략 | 진행 방향 | 보조 모듈 | 역할 요지 |
|---|---|---|---|
| 하향식(Top-Down) | 상위 → 하위 | 스텁(Stub) | 아직 없는 하위 기능을 가짜로 대체해 상위 흐름을 검증 |
| 상향식(Bottom-Up) | 하위 → 상위 | 드라이버(Driver) | 아직 없는 상위 호출부를 가짜로 대체해 하위 모듈을 검증 |
| 빅뱅(Big-Bang) | 완성 후 한꺼번에 통합 | (필요 시 혼용) | 일정은 짧아 보일 수 있으나 원인 분석이 어려울 수 있음 |
| 샌드위치 | 상·하위 동시에 중간 집중 | 스텁+드라이버 혼용 | 대형에서 흔한 절충 |
3. 제품 소프트웨어 패키징
- 개발 산출물을 배포 가능한 형태로 묶고, 설치·운영·사용을 위한 정보를 제공하는 활동.
- 시험에서는 DRM 구성 요소, 매뉴얼 종류, 릴리즈 노트, 오픈소스 라이선스 성격, **배포 채널(온/오프라인)**이 자주 출제됨.
3.1 패키징·배포 흐름(개념)
- 기능·모듈 식별 → 빌드(실행 파일·리소스 생성) → 대상 환경에서의 설치·구동 검증(적용 시험) → 배포(온라인 저장소 등록, 오프라인 매체 포함) → 문제 발생 시 수정·재배포 루프.
- 모듈화: 기능 단위로 코드·구성을 정리하는 활동으로 이해하고, “실행 파일 생성”은 주로 빌드 단계의 결과로 구분하는 문제가 나오기도 함.
3.2 릴리즈 노트(Release Note)
- 변경된 기능, 수정 결함, 호환성·업그레이드 주의사항, 영향 범위 등을 사용자·운영자에게 전달하는 문서.
- 시험에서는 작성 순서·포함 항목을 순서 배열 형태로 묻는 경우가 있음.
3.3 매뉴얼
| 종류 | 용도 |
|---|---|
| 설치 매뉴얼 | 최초 설치 절차, 환경 요구사항, 권한·포트·의존 컴포넌트 등 |
| 사용자 매뉴얼 | 화면 조작, 기능 사용법, 예외 상황 안내 |
| 운영자 매뉴얼 | 백업·장애 대응·로그·모니터링·계정·보안 설정 등 운영 관점 |
3.4 DRM(디지털 저작권 관리) 주요 역할(용어 혼동 주의)
- 콘텐츠 제공자/분배자/소비자 등 이해관계자 역할과, 암호화·키 관리·라이선스(정책), 크랙 방지 같은 기술 요소를 구분해 암기.
- 클리어링 하우스(Clearing House): 이용 권한·과금·라이선스 발급 등 권리·거래 처리를 담당하는 주체로 설명되는 경우가 많음.
- 보안 컨테이너(Security Container): 콘텐츠 안전 유통·보호를 위한 전자적 보호 수단으로 설명되는 경우가 많음 — 위 두 용어를 서로 바꿔 쓰는 오답이 자주 출제됨.
3.5 오픈소스 라이선스(개념 수준)
| 예시 | 시험에서 강조되는 성격(요지) |
|---|---|
| GPL | 카피레프트가 강함 — 파생·결합 조건이 엄격해 코드 공개 의무 이슈가 자주 언급 |
| LGPL | 라이브러리 링크 상황에서 GPL보다 완화된 조건으로 소개되는 경우가 많음(세부는 버전별 차이가 있으므로 시험은 원리 중심) |
| MIT, Apache | 비교적 허용적(permissive) — 의무 범위가 상대적으로 작은 편으로 묶여 출제 |
4. 애플리케이션 테스트 관리
- 결함을 조기·체계적으로 찾아 품질 리스크를 낮추는 활동.
- 시험에서는 테스트 레벨, 화이트/블랙박스, 커버리지, 통합 전략, V&V, 리뷰(워크스루/인스펙션), 테스트 케이스·시나리오·오라클 정의가 핵심.
4.1 검증(Verification) vs 확인(Validation)
| 구분 | 관점 | 질문 |
|---|---|---|
| Verification | 명세·설계 대비 구현 일치(“올바르게 만들었는가”) | 스펙대로 동작하는가 |
| Validation | 사용자·비즈니스 요구 충족(“올바른 것을 만들었는가”) | 진짜로 필요한 가치를 제공하는가 |
4.2 테스트 레벨(대표)
- 단위 테스트: 최소 단위(함수·모듈) — 구현자 관점, 화이트박스 비중이 큰 편으로 출제되는 경우가 많음.
- 통합 테스트: 모듈·서브시스템 인터페이스·연동.
- 시스템 테스트: 요구사항 대비 전체 시스템 동작·비기능(성능·보안 등) 포함 문제도 가능.
- 인수 테스트: 고객·사용자 관점의 최종 확인(알파/베타 등 표현이 붙는 경우도 있음).
4.3 테스트 설계 기법
명세 기반(블랙박스에 가까운 경우가 많음)
- 동치 분할: 입력을 동등한 결과 클래스로 나눠 대표값 테스트.
- 경계값 분석: 경계와 경계±1 등 경계 인접값에 취약점이 많다는 전제.
- 결정 테이블, 상태 전이, 유스케이스 기반 등.
구조 기반(화이트박스)
- 문장/분기/조건/경로 커버리지 등 — 구분 커버리지·결정 커버리지는 구조 기반으로 분류하는 문제가 자주 나옴.
- 대표 유형 명칭: 기초 경로 검사, 제어 구조 검사, 데이터 흐름 검사, 루프 검사 등(교재 표기 기준).
4.4 블랙박스 vs 화이트박스(한 줄)
| 구분 | 관점 | 비고 |
|---|---|---|
| 블랙박스 | 외부에서 보이는 기능·입출력 관계 | 명세 기반 기법과 함께 묶임 |
| 화이트박스 | 내부 제어·데이터 흐름 | 커버리지 지표와 함께 묶임 |
4.5 테스트 케이스·시나리오·오라클
- 테스트 케이스: 식별자, 입력/전제 조건, 기대 결과, 환경 등을 한 단위 실행 단위로 기술.
- 테스트 시나리오: 여러 케이스를 업무 흐름·우선순위에 맞게 묶고 수행 절차를 명세한 문서로 출제되는 경우가 많음(“케이스 나열”과 구분).
- 테스트 오라클: 결과가 옳은지 판단하기 위한 기준(기대값·규칙·참 모델).
4.6 리뷰: 워크스루 vs 인스펙션(개념)
- 워크스루: 통상 작성자 중심으로 짧게 설명하며 결함을 찾는 비형식적 성격이 강한 편.
- 인스펙션: 역할 분담·체크리스트 등이 있는 형식적 검토로, 워크스루보다 절차가 엄격하게 설명되는 경우가 많음.
- 시험에서는 “워크스루가 즉석 설계 변경/문제 해결에 초점”처럼 과장된 진술을 오답으로 내는 경우가 있음 — 조기 결함 발견 쪽이 정답인 경우가 많음.
4.7 테스트 자동화(장단)
- 장점: 반복 실행, 회귀 테스트 효율, 기록·재현성.
- 단점/비용: 초기 스크립트 구축·유지보수, 도구 학습 비용, 자동화하기 어려운 영역(탐색적·사용성 등) 존재.
5. 인터페이스 구현
- 시스템·모듈·외부와의 데이터 교환 규약을 구현·문서화하는 영역.
- 시험에서는 JSON/XML, REST 개념, AJAX, 인터페이스 명세서 항목, UI-서버 연동 흐름이 자주 출제됨.
5.1 인터페이스 설계 산출물(이름만 헷갈리기 쉬움)
- 인터페이스 목록/현황: 연계 대상·채널·주기 등 목록화.
- 인터페이스 설계서: 정적/동적 관점의 구조, 흐름, 제약을 설계 관점으로 기술.
- 인터페이스 명세: 요청/응답 필드, 데이터 타입, 오퍼레이션(기능)명, 반환값, 오류 코드, 보안·인증 등 호출 규약을 상세화.
5.2 JSON
- 속성-값 쌍으로 이루어진 경량 데이터 교환 형식.
- 배열·객체 중첩, 키-값 표기가 기본.
5.3 XML
- 확장 가능한 마크업으로, 특정 도메인을 위한 사용자 정의 태그를 정의해 구조화 데이터를 표현.
- Well-formed vs Valid(DTD/스키마에 대한 유효성) 같은 기초 개념이 나올 수 있음.
5.4 AJAX(비동기 통신 개념)
- 브라우저가 페이지 전체 새로고침 없이 서버와 데이터를 주고받아 일부 영역만 갱신하는 방식.
- 전통적으로 XMLHttpRequest가 대표 예로 언급되며, 실무에서는 JSON 응답과 함께 쓰는 경우가 많음.
5.5 RESTful API(원리 수준)
- 리소스 중심 URI, HTTP 메서드 의미(조회
GET, 생성POST, 수정PUT/PATCH, 삭제DELETE등 교재 정의)로 무상태성을 지향하는 설계로 이해. - SOAP은 메시지 기반 프로토콜·엔벨로프 중심으로, REST와 대비되는 개념 문제로 등장할 수 있음.
5.6 인터페이스 오류·보안(개략)
- 전송 계층 보안(TLS 등), 응용 계층 인증/인가, DB 연결·세션 오류, 스키마 불일치 등이 연계 장애 원인으로 묶여 출제.
- “어느 한 계층만 보안”처럼 절대적 배제형 지문은 출제 의도에 따라 달라질 수 있으므로, 요구사항·위협 모델에 따른 다층 방어 관점으로 이해하는 것이 안전.
6. (보강) 단위 모듈·기능 모듈 구현 관점
- 통합 구현 단원과 맞물려 기능별 모듈 유형이 객관식으로 나오는 경우가 있음(용어 매칭).
- 예시 분류(교재 표기): 디바이스 드라이버, 네트워크, 파일, 메모리(가상 메모리 매핑·프로세스 간 통신 등), 프로세스 생성 등.
7. 시험 포인트(암기 체크)
- 하향식=스텁, 상향식=드라이버는 반드시 세트 암기(표 방향 뒤집힌 자료 주의).
- 해싱은 **“함수 종류”**와 **“충돌 처리 기법”**을 다른 카테고리로 구분해 선택지를 읽을 것.
- Verification(명세 일치) vs Validation(요구 충족) 문장을 바꿔 놓는 오답이 자주 나옴.
- 단위 테스트는 화이트박스 비중 문제, 블랙박스 기법(동치·경계) 문제를 번갈아 암기.
- **구분/결정 커버리지는 구조 기반(화이트박스)**으로 분류하는 지문이 반복됨.
- 테스트 케이스의 출력 명세는 기대 결과, 수행 후 실제 결과는 별도 기록인 경우가 많음.
- 시나리오=케이스 묶음+수행 절차로 정의되는 문제가 반복됨.
- DRM에서는 클리어링 하우스 vs 보안 컨테이너의 역할 뒤바꾸기 오답을 조심.
- Ant/Maven/Gradle은 의존성 관리·표준화에서 Maven/Gradle이 더 자주 “특징 비교”로 나옴.
- JSON/XML/AJAX/REST는 정의 문장 한 줄을 정확히 구분(특히 JSON=속성-값, XML=확장 마크업).