← 목록

소프트웨어 개발 · 오답노트

2025년 3회

Q1

ISO/IEC 9126의 소프트웨어 품질 특성 중 기능성(Functionality)의 하위 특성으로 옳지 않은 것은?

1학습성
2적합성
3정확성
4보안성
정답 1번 · 학습성

핵심 해설

ISO/IEC 9126은 소프트웨어 품질을 기능성(Functionality), 신뢰성(Reliability), 사용성(Usability), 효율성(Efficiency), 유지보수성(Maintainability), 이식성(Portability) 여섯 가지 특성으로 규정한 국제 표준이다. 이 중 기능성은 요구된 기능을 정확히 제공하는가에 관한 특성으로 하위 특성은 적합성(Suitability), 정확성(Accuracy), 상호운용성(Interoperability), 보안성(Security), 준수성(Compliance)이다. 학습성(Learnability)은 사용자가 소프트웨어의 사용법을 얼마나 쉽게 익히는가를 나타내므로 사용성(Usability)의 하위 특성이다. 따라서 기능성의 하위 특성이 아닌 것은 학습성이다.

보기별 해설

1. 학습성(Learnability)은 사용성(Usability)의 하위 특성이다. 사용자가 소프트웨어의 사용 방법을 얼마나 쉽고 빠르게 익힐 수 있는지를 나타내며, 사용성에는 이해성·학습성·운용성·친밀성이 함께 속한다. 기능 제공의 정확성과는 무관하므로 기능성에 들어가지 않는다.
2. 적합성(Suitability)은 기능성의 하위 특성이다. 지정된 작업과 사용자 목적에 맞는 기능 집합을 제대로 제공하는지를 평가하는 항목으로, 요구된 기능이 빠짐없이 갖춰졌는가를 본다.
3. 정확성(Accuracy)은 기능성의 하위 특성이다. 소프트웨어가 사용자가 요구한 결과를 정밀하고 올바르게 산출하는 정도를 나타내며, 계산 결과나 처리 결과의 정확도를 평가한다.
4. 보안성(Security)은 기능성의 하위 특성이다. 인가되지 않은 접근으로부터 데이터와 프로그램을 보호하고 정보 유출·변조를 차단하는 능력을 의미한다.

정리

ISO/IEC 9126 — 기능성(적합성·정확성·상호운용성·보안성·준수성), 신뢰성(성숙성·결함허용성·회복성), 사용성(이해성·학습성·운용성), 효율성, 유지보수성, 이식성.
#소프트웨어개발#보안
Q2

SW 패키징 도구 활용 시 고려사항과 거리가 먼 것은?

1패키징 시 사용자에게 배포되는 SW이므로 보안을 고려한다.
2사용자 편의성을 위한 복잡성 및 비효율성 문제를 고려한다.
3보안상 단일 기종에서만 사용할 수 있도록 해야 한다.
4제품 SW종류에 적합한 암호화 알고리즘을 적용한다. - 2
정답 3번 · 보안상 단일 기종에서만 사용할 수 있도록 해야 한다.

핵심 해설

소프트웨어 패키징 도구는 개발이 끝난 모듈을 사용자가 설치·실행할 수 있는 배포 단위로 묶으면서 콘텐츠 암호화와 DRM을 함께 적용하는 도구이다. 활용 시 고려 사항은 내부 콘텐츠에 대한 암호화와 보안, 제품 특성에 맞는 암호화 알고리즘 적용, 사용자 편의성을 해치는 복잡성·비효율성 제거, 그리고 다양한 이기종 환경에서 연동될 수 있도록 하는 호환성 확보이다. 사용자의 운영체제와 기기가 제각각이므로 이기종 지원은 필수 요건이며, 특정 기종에서만 동작하도록 제한하는 것은 오히려 배포 목적을 훼손한다. 따라서 거리가 먼 것은 단일 기종 전용으로 만들라는 3번이다.

보기별 해설

1. 패키징 시 보안을 고려한다는 것은 타당한 지침이다. 배포된 소프트웨어는 사용자 단말에 그대로 놓이므로 콘텐츠 암호화와 키 관리로 무단 복제·역공학을 막아야 한다.
2. 사용자 편의성을 위한 복잡성 및 비효율성 문제 고려도 타당한 지침이다. 설치 절차가 지나치게 복잡하거나 암·복호화로 실행 성능이 크게 떨어지면 제품 사용성이 훼손되므로 보안과 균형을 맞춰야 한다.
3. 보안상 단일 기종에서만 사용할 수 있도록 해야 한다는 것은 패키징 고려사항에 어긋난다. 패키징 도구는 오히려 다양한 운영체제·기기·플랫폼에서 동작하도록 이기종 연동을 지원해야 하며, 기종 제한은 보안 요건이 아니라 배포 범위를 좁히는 제약일 뿐이다.
4. 제품 소프트웨어 종류에 적합한 암호화 알고리즘 적용은 타당한 지침이다. 콘텐츠의 크기와 실시간성, 배포 방식에 따라 요구되는 암호 강도와 처리 속도가 다르므로 제품 특성에 맞춰 알고리즘을 선택한다.

정리

패키징 도구 고려사항 — 콘텐츠 암호화·키 관리, 제품 특성에 맞는 암호 알고리즘, 사용자 편의성(복잡성·비효율 최소화), 다양한 이기종 연동 지원, 배포 크기 최소화.
#소프트웨어개발#보안#암호화
Q3

하향식 통합에 있어서 모듈 간의 통합 시험을 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈을 무엇이라고 하는가?

1Stub
2Driver
3Procedure
4Function
정답 1번 · Stub

핵심 해설

통합 테스트에서는 아직 개발되지 않은 모듈을 대신할 가상 모듈이 필요하며, 이를 테스트 하네스(Test Harness)라 한다. 하향식 통합은 상위 모듈부터 아래로 내려가며 결합하므로 아직 없는 하위 모듈 자리를 채울 가짜 모듈이 필요한데, 이것이 스텁(Stub)이다. 스텁은 실제 로직 없이 호출을 받으면 미리 정해 둔 값만 되돌려 주는 최소한의 임시 모듈이다. 반대로 상향식 통합에서는 아직 없는 상위 모듈 대신 하위 모듈을 호출해 주는 드라이버(Driver)를 사용한다. 따라서 하향식 통합에서 임시로 제공되는 시험용 모듈은 Stub이다.

보기별 해설

1. Stub(스텁)은 하향식 통합 테스트에서 아직 구현되지 않은 하위 모듈을 대신하는 임시 모듈이다. 상위 모듈의 호출을 받아 실제 처리 없이 미리 정의된 결과만 반환하므로, 하위 모듈 완성 전에도 상위 제어 흐름을 검증할 수 있다.
2. Driver(드라이버)는 상향식 통합 테스트에서 아직 구현되지 않은 상위 모듈을 대신하는 임시 모듈이다. 하위 모듈에 테스트 입력을 넘겨 호출하고 결과를 받아 확인하는 역할을 하므로, 하향식이 아니라 상향식에서 쓰인다.
3. Procedure(프로시저)는 특정 작업을 수행하는 명령들을 하나의 이름으로 묶은 부프로그램을 가리키는 일반적인 프로그래밍 용어이다. 테스트를 위해 임시로 만드는 대체 모듈을 뜻하는 용어가 아니다.
4. Function(함수)은 입력을 받아 처리 결과를 반환값으로 돌려주는 프로그램 구성 단위이다. 언어의 기본 문법 요소일 뿐 통합 테스트용 가상 모듈의 명칭이 아니다.

정리

테스트 하네스 — 하향식 통합은 하위 모듈 대신 Stub, 상향식 통합은 상위 모듈 대신 Driver를 사용한다.
#소프트웨어개발
Q4

소프트웨어 재공학이 소프트웨어의 재개발에 비해 갖는 장점으로 거리가 먼 것은?

1위험부담 감소
2비용 절감
3시스템 명세의 오류억제
4개발 시간의 증가
정답 4번 · 개발 시간의 증가

핵심 해설

소프트웨어 재공학(Re-engineering)은 기존에 운영 중인 소프트웨어를 분석(Analysis)·재구성(Restructuring)·역공학(Reverse Engineering)·이식(Migration) 과정을 거쳐 재활용하는 유지보수 기법이다. 이미 검증된 자산을 그대로 살려 쓰기 때문에 처음부터 새로 만드는 재개발에 비해 개발 비용과 기간이 줄고, 기존 시스템에 이미 반영된 업무 규칙을 그대로 쓰므로 명세 오류와 실패 위험도 낮아진다. 즉 재공학의 장점은 비용 절감, 개발 기간 단축, 위험 부담 감소, 시스템 명세 오류 억제, 품질 향상 등이다. 개발 시간이 늘어난다는 것은 장점이 아니라 재개발 대비 이점을 정반대로 서술한 것이므로 거리가 멀다.

보기별 해설

1. 위험부담 감소는 재공학의 장점이다. 이미 현업에서 검증된 기존 시스템의 구조와 업무 규칙을 재활용하므로, 백지에서 시작하는 재개발보다 실패 가능성과 불확실성이 작다.
2. 비용 절감은 재공학의 대표적 장점이다. 기존 코드와 설계 자산을 재사용하기 때문에 요구 분석부터 다시 수행하는 재개발보다 투입 공수와 예산이 적게 든다.
3. 시스템 명세의 오류억제는 재공학의 장점이다. 기존 시스템에 이미 구현되어 검증된 업무 규칙을 역공학으로 추출해 활용하므로, 요구사항을 새로 정의하며 생기는 누락·오해를 줄일 수 있다.
4. 개발 시간의 증가는 장점이 아니라 단점에 해당하는 서술이며, 실제로도 재공학은 검증된 자산을 재사용해 개발 시간을 단축한다. 재공학의 이점은 시간·비용 절감이므로 방향이 반대이다.

정리

재공학 4단계 — 분석·재구성·역공학·이식. 재개발 대비 장점은 비용 절감, 개발 시간 단축, 위험 부담 감소, 명세 오류 억제, 품질·유지보수성 향상이다.
#소프트웨어개발
Q5

제품 소프트웨어의 형상 관리 역할로 틀린 것은?

1형상 관리를 통해 이전 리버전이나 버전에 대한 정보에 접근 가능하여 배포본 관리에 유용
2불필요한 사용자의 소스 수정 제한
3프로젝트 개발비용을 효율적으로 관리
4동일한 프로젝트에 대해 여러 개발자 동시 개발 가능
정답 3번 · 프로젝트 개발비용을 효율적으로 관리

핵심 해설

소프트웨어 형상 관리(SCM)는 개발 과정에서 산출되는 소스 코드와 문서 등의 변경 사항을 식별·통제·감사·기록해 가시성과 추적성을 확보하는 활동이다. 역할은 이전 리비전·버전 정보에 접근해 배포본을 관리하고, 승인되지 않은 임의의 소스 수정을 제한하며, 여러 개발자가 동일 프로젝트에서 동시에 작업할 수 있게 하고, 변경 이력으로 오류 원인을 추적하는 것이다. 반면 개발비용을 산정하고 예산을 배분·집행하는 것은 프로젝트 관리(비용 관리)의 영역으로, 형상 관리의 역할이 아니다. 따라서 틀린 것은 3번이다.

보기별 해설

1. 형상 관리를 통해 이전 리비전이나 버전 정보에 접근해 배포본을 관리하는 것은 형상 관리의 핵심 역할이다. 릴리스마다 기준선(Baseline)을 설정해 두면 특정 시점의 산출물로 언제든 되돌아갈 수 있다.
2. 불필요한 사용자의 소스 수정 제한은 형상 통제(Configuration Control)에 해당하는 형상 관리의 역할이다. 변경 요구를 형상 통제 위원회(CCB)가 심의해 승인된 것만 반영하도록 함으로써 무분별한 수정을 막는다.
3. 프로젝트 개발비용을 효율적으로 관리하는 것은 형상 관리가 아니라 프로젝트 관리의 비용 관리 영역이다. 비용 산정 모형(LOC, COCOMO 등)과 예산 통제가 다루는 대상이며, 형상 관리는 산출물의 변경 이력과 버전을 관리하는 활동이다.
4. 동일한 프로젝트에 대해 여러 개발자가 동시에 개발할 수 있게 하는 것은 형상 관리 도구가 제공하는 역할이다. 체크아웃·체크인과 브랜치·머지 기능으로 동시 수정 충돌을 조정해 협업을 가능하게 한다.

정리

형상 관리 역할 — 버전·배포본 관리, 무단 수정 통제(CCB 승인), 동시 개발 지원, 변경 이력 추적. 비용·일정 관리는 형상 관리가 아닌 프로젝트 관리의 영역이다.
#소프트웨어개발
Q6

제어흐름 그래프가 다음과 같을 때 McCabe의 cyclomatic 수는 얼마인가?

13
24
35
46
정답 2번 · 4

핵심 해설

McCabe의 순환 복잡도(Cyclomatic Complexity)는 제어 흐름 그래프에서 V(G) = E − N + 2로 계산한다(E는 간선 수, N은 노드 수). 같은 값을 '그래프가 나누는 영역(region)의 개수'로 세거나, 조건문·반복문 같은 분기점의 개수에 1을 더해 구할 수도 있다. 정답이 4라는 것은 이 그래프가 간선 수 − 노드 수 = 2인 형태, 예를 들어 노드 6개에 간선 8개(8 − 6 + 2 = 4)이거나 분기 노드가 3개인 구조임을 뜻한다. 순환 복잡도 4는 모든 경로를 덮는 데 필요한 독립 경로가 4개, 즉 기초 경로 검사에서 최소 4개의 테스트 케이스가 필요함을 의미한다.

보기별 해설

1. 3은 E − N + 2가 3이 되는 그래프, 즉 분기점이 2개인 경우의 값이다. 이 문제의 그래프는 그보다 분기가 하나 더 많아 3이 될 수 없다.
2. 4는 E − N + 2 = 4를 만족하는 값으로, 간선이 노드보다 2개 많은 구조(예: 노드 6·간선 8)에서 얻어진다. 독립 경로가 4개이므로 기초 경로 검사에서 최소 4개의 테스트 케이스가 필요하다.
3. 5는 간선이 노드보다 3개 많은 그래프의 복잡도 값이다. 분기점이 4개일 때 나오는 수치로, 이 그래프보다 조건 분기가 하나 더 많은 경우에 해당한다.
4. 6은 간선이 노드보다 4개 많은 그래프의 값이며, 분기점 5개에 해당한다. 순환 복잡도가 이 정도로 커지면 모듈 분리를 검토하라는 기준선(보통 10 초과 시 위험)에 가까워지는 수치이다.

정리

McCabe 순환 복잡도 V(G) = E − N + 2 = (분기점 수 + 1) = 폐영역 수 + 1. 값은 독립 경로 수이자 기초 경로 검사에 필요한 최소 테스트 케이스 수이다.
#소프트웨어개발
Q7

디지털 저작권 관리(DRM) 기술과 거리가 먼 것은?

1콘텐츠 암호화 및 키 관리
2콘텐츠 식별체계 표현
3콘텐츠 오류 감지 및 복구
4라이선스 발급 및 관리
정답 3번 · 콘텐츠 오류 감지 및 복구

핵심 해설

디지털 저작권 관리(DRM)는 디지털 콘텐츠의 생성부터 유통·사용까지 전 과정에서 저작권을 보호하고 이용 권한을 통제하는 기술이다. 기술 요소로는 콘텐츠 암호화 및 키 관리, 암호화 파일 생성(패키저), 콘텐츠 식별체계(DOI·URI), 저작권 표현(XrML 등 권리 표현 언어), 정책 관리, 라이선스 발급·관리, 크랙 방지(Tamper Resistance), 인증(Authentication)이 있다. 반면 데이터 전송·저장 중 발생한 비트 오류를 검출하고 되살리는 것은 패리티·CRC·해밍코드 같은 오류 제어 기술의 영역으로, 저작권 보호와는 목적이 다르다. 따라서 DRM 기술과 거리가 먼 것은 콘텐츠 오류 감지 및 복구이다.

보기별 해설

1. 콘텐츠 암호화 및 키 관리는 DRM의 핵심 기술 요소이다. 콘텐츠를 암호화해 유통하고 복호화 키를 안전하게 생성·분배함으로써 정당한 라이선스를 가진 사용자만 열람하게 한다.
2. 콘텐츠 식별체계 표현은 DRM 기술 요소이다. DOI(Digital Object Identifier)나 URI로 콘텐츠마다 고유 식별자를 부여해 유통 경로 추적과 권리 처리의 기준으로 삼는다.
3. 콘텐츠 오류 감지 및 복구는 전송·저장 중 발생한 비트 오류를 다루는 오류 제어 기술이다. 패리티 검사, CRC, 해밍 코드 등이 여기에 속하며 데이터 무결성 회복이 목적일 뿐 저작권 보호나 이용 권한 통제와는 무관하므로 DRM 기술 요소가 아니다.
4. 라이선스 발급 및 관리는 DRM 기술 요소이다. 클리어링 하우스가 사용 조건과 기간·횟수를 담은 라이선스를 발급하고 사용 내역을 집계해 과금·정산까지 처리한다.

정리

DRM 기술 요소 — 암호화·키 관리, 패키저, 식별 기술(DOI/URI), 저작권 표현(XrML), 정책 관리, 라이선스 발급, 크랙 방지, 인증. 오류 검출·정정(패리티·CRC·해밍)은 오류 제어 기술이다.
#소프트웨어개발#암호화
Q8

다음이 설명하는 테스트 용어는? ㆍ테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법 및 활 동을 말한다. ㆍ종류에는 참, 샘플링, 휴리스틱, 일관성 검사가 존재 한다.

1테스트 케이스
2테스트 시나리오
3테스트 오라클
4테스트 데이터
정답 3번 · 테스트 오라클

핵심 해설

테스트 오라클(Test Oracle)은 테스트 결과가 참인지 거짓인지 판정하기 위해 사전에 정의해 둔 참값을 실제 실행 결과와 비교하는 기법과 활동을 말한다. 종류는 네 가지로, 모든 입력값에 대해 기대 결과를 준비해 검증하는 참(True) 오라클, 일부 입력값에만 기대 결과를 제공하는 샘플링(Sampling) 오라클, 샘플링을 개선해 나머지 입력은 추정으로 처리하는 휴리스틱(Heuristic) 오라클, 변경 전후의 실행 결과가 동일한지를 확인하는 일관성 검사(Consistent) 오라클이 있다. 참·샘플링·휴리스틱·일관성 검사라는 네 종류가 곧 오라클의 분류이므로 설명에 해당하는 용어는 테스트 오라클이다.

보기별 해설

1. 테스트 케이스(Test Case)는 특정 요구사항을 검증하기 위한 입력값, 실행 조건, 기대 결과의 집합이다. 검증 대상과 데이터를 정의한 문서일 뿐, 결과의 참·거짓을 판정하는 기법 자체를 가리키지는 않는다.
2. 테스트 시나리오(Test Scenario)는 여러 테스트 케이스를 업무 흐름이나 기능 순서에 맞게 묶어 놓은 실행 절차 목록이다. 테스트를 어떤 순서로 수행할지를 정하는 것이며 참값 비교 기법이 아니다.
3. 테스트 오라클(Test Oracle)은 사전에 정의된 참값을 실행 결과와 비교해 테스트의 성공 여부를 판정하는 기법이자 활동이다. 참, 샘플링, 휴리스틱, 일관성 검사 네 종류로 나뉘며 제한된 검증·수학적 기법 적용·자동화 가능이라는 특징을 갖는다.
4. 테스트 데이터(Test Data)는 테스트를 수행하기 위해 프로그램에 입력하는 실제 값들을 뜻한다. 판정의 재료가 될 뿐 옳고 그름을 판단하는 기준값 비교 활동은 아니다.

정리

테스트 오라클 4종 — 참(모든 입력에 기대값), 샘플링(일부 입력만), 휴리스틱(샘플링 + 나머지는 추정), 일관성 검사(변경 전후 결과 동일 여부).
#소프트웨어개발#테스트
Q9

다음 트리에 대한 INORDER 운행 결과는?

1D B A E C F
2A B D C E F
3D B E C F A
4A B C D E F 2
정답 1번 · D B A E C F

핵심 해설

INORDER(중위) 운행법은 왼쪽 서브트리 → 루트 → 오른쪽 서브트리 순으로 방문하며 각 서브트리에 재귀적으로 적용한다. 정답 D B A E C F를 역산하면 루트 A를 기준으로 왼쪽 서브트리는 {D, B}, 오른쪽 서브트리는 {E, C, F}이며, 노드 6개짜리 완전 형태의 트리에서 A의 왼쪽 자식은 B, 오른쪽 자식은 C이다. 왼쪽 부분 D B는 B의 왼쪽 자식이 D임을 뜻하고, 오른쪽 부분 E C F는 C의 왼쪽 자식이 E, 오른쪽 자식이 F임을 뜻한다. 이 트리의 PREORDER는 A B D C E F, POSTORDER는 D B E F C A가 되며, 보기 2번이 바로 이 트리의 전위 순회 결과라는 점이 구조를 확인해 준다.

보기별 해설

1. D B A E C F는 중위 순회 결과이다. 왼쪽 서브트리(B의 왼쪽 자식 D → B) → 루트 A → 오른쪽 서브트리(C의 왼쪽 자식 E → C → 오른쪽 자식 F) 순서로 Left-Root-Right를 재귀 적용한 결과와 일치한다.
2. A B D C E F는 같은 트리의 PREORDER(전위) 운행 결과이다. Root-Left-Right 순서로 A → B → D → C → E → F가 되며, 루트 A가 맨 앞에 오는 것이 전위 순회의 표식이므로 중위 결과가 아니다.
3. D B E C F A는 POSTORDER와 혼동하기 쉬운 배열로, 루트 A가 맨 뒤에 놓인 후위형 순서이다. 다만 이 트리의 실제 POSTORDER는 Left-Right-Root에 따라 D B E F C A이므로, E와 F의 순서가 어긋나 어느 운행법의 결과와도 일치하지 않는다.
4. A B C D E F는 루트부터 같은 레벨끼리 훑어 내려가는 레벨 순회(너비 우선)의 결과 형태이다. 중위 순회는 루트가 왼쪽 서브트리 뒤인 세 번째에 나와야 하므로 A가 맨 앞에 오는 이 배열은 답이 될 수 없다.

정리

이진 트리 운행 — Preorder: Root-Left-Right(A B D C E F), Inorder: Left-Root-Right(D B A E C F), Postorder: Left-Right-Root(D B E F C A). 루트의 위치(맨 앞/가운데/맨 뒤)로 구분한다.
#소프트웨어개발
Q10

검증(Validation) 검사 기법 중 개발자의 장소에서 사용자가 개발자 앞에서 행해지며오류와, 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법은?

1디버깅 검사
2형상 검사
3자료구조 검사
4알파 검사
정답 4번 · 알파 검사

핵심 해설

검증(Validation) 검사는 완성된 소프트웨어가 사용자의 요구를 실제로 만족하는지 확인하는 인수 테스트 단계의 활동이며, 대표적으로 알파 검사와 베타 검사가 있다. 알파 검사는 개발자의 사업장(통제된 환경)에서 사용자가 개발자가 지켜보는 가운데 프로그램을 사용하고, 발견된 오류와 사용상의 문제점을 개발자가 그 자리에서 기록하는 방식이다. 반대로 베타 검사는 실제 사용자 환경에서 다수의 사용자가 개발자 없이 사용해 본 뒤 문제점을 보고하는 방식이다. 개발자 장소에서 개발자 앞에서 함께 확인한다는 조건에 부합하는 것은 알파 검사이다.

보기별 해설

1. 디버깅(Debugging) 검사는 이미 발견된 오류의 원인 위치를 찾아 코드를 수정하는 활동이다. 결함을 찾아내는 테스트 이후에 수행하는 교정 작업이므로 사용자 요구 충족을 확인하는 검증 검사 기법이 아니다.
2. 형상 검사는 소프트웨어 형상 관리에서 변경이 계획대로, 요구대로 이루어졌는지를 확인하는 형상 감사에 해당한다. 산출물의 버전과 변경 이력을 점검하는 관리 활동이지 사용자가 프로그램을 실행해 보는 검사가 아니다.
3. 자료구조 검사는 모듈 내부에서 사용하는 자료 구조와 변수가 올바르게 선언·사용되는지 확인하는 단위 테스트 항목이다. 개발자가 코드 수준에서 수행하는 검사이므로 사용자가 참여하는 인수 검증과는 층위가 다르다.
4. 알파 검사(Alpha Test)는 개발자의 장소에서 사용자가 개발자 앞에서 프로그램을 사용하고, 개발자가 옆에서 오류와 사용상의 문제점을 함께 확인·기록하는 검증 기법이다. 통제된 환경에서 수행된다는 점이 사용자 현장에서 개발자 없이 진행되는 베타 검사와 구별된다.

정리

인수 검증 — 알파 검사: 개발자 장소, 개발자 입회하에 사용자가 사용(통제된 환경) / 베타 검사: 사용자 현장, 개발자 없이 다수 사용자가 사용 후 문제 보고.
#소프트웨어개발#자료구조
Q11

해싱 함수(Hashing Function)의 종류가 아닌 것은?

1제곱법(Mid-Square)
2숫자 분석법(Digit Analysis)
3개방주소법(Open Addressing)
4제산법(Division)
정답 3번 · 개방주소법(Open Addressing)

핵심 해설

해싱 함수(Hashing Function)는 키 값을 저장 주소(버킷 번호)로 변환하는 계산식으로, 종류에는 제산법(Division), 제곱법(Mid-Square), 폴딩법(Folding), 기수 변환법(Radix Conversion), 대수적 코딩법, 숫자 분석법(Digit Analysis), 무작위법(Random)이 있다. 반면 개방주소법(Open Addressing)은 서로 다른 키가 같은 주소로 계산되는 충돌(Collision)이 일어났을 때 다른 빈 버킷을 찾아 저장하는 충돌 해결 방법이다. 즉 주소를 만들어 내는 함수가 아니라 주소가 겹친 뒤의 처리 방식이므로 범주가 다르다. 따라서 해싱 함수의 종류가 아닌 것은 개방주소법이다.

보기별 해설

1. 제곱법(Mid-Square)은 해싱 함수의 한 종류이다. 키 값을 제곱한 뒤 결과의 중간 부분 자릿수를 잘라내 그 값을 저장 주소로 사용하며, 키 전체가 결과에 고르게 반영되는 장점이 있다.
2. 숫자 분석법(Digit Analysis)은 해싱 함수의 한 종류이다. 키를 이루는 각 자릿수의 값 분포를 조사해 편중이 심한 자리는 버리고 고르게 분포된 자리들만 골라 주소로 삼는 방법이다.
3. 개방주소법(Open Addressing)은 해싱 함수가 아니라 충돌 해결 방법이다. 충돌이 발생하면 선형 조사, 이차 조사, 이중 해싱 등으로 해시 테이블 내의 다른 빈 버킷을 찾아 저장하며, 체이닝(Chaining)과 함께 오버플로 처리 기법으로 분류된다.
4. 제산법(Division)은 가장 기본적인 해싱 함수이다. 키 값을 해시 테이블 크기(주로 소수)로 나눈 나머지를 주소로 사용하며, 계산이 간단해 널리 쓰인다.

정리

해싱 함수 = 제산법·제곱법·폴딩법·기수 변환법·대수적 코딩법·숫자 분석법·무작위법 / 충돌(오버플로) 해결 = 개방주소법(선형·이차 조사, 이중 해싱), 체이닝, 재해싱.
#소프트웨어개발
Q12

퀵 정렬에 관한 설명으로 옳은 것은?

1레코드의 키 값을 분석하여 같은 값끼리 그 순서에 맞는 버킷에 분배하였다가 버킷의 순서대로 레코드를 꺼내어 정렬한다.
2주어진 파일에서 인접한 두 개의 레코드 키 값을 비교하여 그 크기에 따라 레코드 위치를 서로 교환한다.
3레코드의 많은 자료 이동을 없애고 하나의 파일을 부분적으로 나누어 가면서 정렬한다.
4임의의 레코드 키와 매개변수(h)값만큼 떨어진 곳의 레코드 키를 비교하여 서로 교환해 가면서 정렬한다.
정답 3번 · 레코드의 많은 자료 이동을 없애고 하나의 파일을 부분적으로 나누어 가면서 정렬한다.

핵심 해설

퀵 정렬(Quick Sort)은 분할 정복 방식의 정렬로, 기준값인 피봇(Pivot)을 정해 이보다 작은 값은 왼쪽, 큰 값은 오른쪽으로 몰아 파일을 두 부분으로 나눈 뒤 각 부분에 같은 과정을 재귀적으로 적용한다. 인접 원소를 하나하나 교환하지 않고 멀리 떨어진 원소끼리 한 번에 자리를 바꾸므로 불필요한 자료 이동이 크게 줄어드는 것이 특징이다. 평균 시간 복잡도는 O(n log n)이고, 피봇이 항상 최솟값이나 최댓값으로 선택되면 최악의 경우 O(n²)이 된다. 따라서 '자료 이동을 없애고 파일을 부분적으로 나누어 가며 정렬한다'는 설명이 퀵 정렬에 해당한다.

보기별 해설

1. 레코드 키 값을 분석해 같은 값끼리 버킷에 분배했다가 순서대로 꺼내는 것은 기수 정렬(Radix Sort, 버킷 정렬)의 설명이다. 값을 비교하지 않고 자릿수별로 분배·수집을 반복하며, 시간 복잡도는 O(dn)이다.
2. 인접한 두 레코드의 키를 비교해 크기에 따라 위치를 교환하는 것은 버블 정렬(Bubble Sort)의 설명이다. 한 Pass마다 최댓값이 뒤쪽에 확정되며 시간 복잡도는 항상 O(n²)이다.
3. 많은 자료 이동을 없애고 파일을 부분적으로 나누어 가며 정렬한다는 것이 퀵 정렬(Quick Sort)의 설명이다. 피봇을 기준으로 작은 값과 큰 값을 양쪽으로 분할한 뒤 각 부분을 재귀 정렬하는 분할 정복 방식이며, 평균 O(n log n)·최악 O(n²)이다.
4. 매개변수 h만큼 떨어진 곳의 레코드 키와 비교해 교환하는 것은 셸 정렬(Shell Sort)의 설명이다. 간격 h를 점점 줄여 가며 부분 삽입 정렬을 반복하는 방식으로, 삽입 정렬의 먼 거리 이동 비효율을 개선한 기법이다.

정리

정렬 식별 키워드 — 퀵: 피봇 기준 분할 정복 / 버블: 인접 두 값 비교·교환 / 셸: 간격 h만큼 떨어진 값 비교 / 기수(버킷): 키를 분배했다 순서대로 수집.
#소프트웨어개발
Q13

소프트웨어 설치 매뉴얼에 포함될 항목이 아닌 것은?

1제품 소프트웨어 개요
2설치 관련 파일
3프로그램 삭제
4소프트웨어 개발 기간
정답 4번 · 소프트웨어 개발 기간

핵심 해설

소프트웨어 설치 매뉴얼은 사용자가 제품을 설치하는 전 과정을 순서대로 안내하는 문서로, 목표 독자는 최종 사용자이다. 포함 항목은 제품 소프트웨어 개요, 설치 관련 파일과 설치 아이콘, 설치 환경(하드웨어·운영체제 요구사항), 설치 절차와 화면별 안내, 설치 시 주의사항 및 오류 메시지 대처법, 설치 이후의 프로그램 삭제(제거) 방법, 저작권 정보와 기술 지원 연락처 등이다. 반면 개발에 몇 개월이 걸렸는지 같은 개발 기간은 프로젝트 관리 정보로, 사용자가 설치를 수행하는 데 아무런 도움이 되지 않는다. 따라서 설치 매뉴얼에 들어가지 않는 항목은 소프트웨어 개발 기간이다.

보기별 해설

1. 제품 소프트웨어 개요는 설치 매뉴얼의 포함 항목이다. 설치할 제품이 어떤 기능과 구성을 갖는지 사용자가 먼저 파악하도록 서두에 기술한다.
2. 설치 관련 파일은 설치 매뉴얼의 포함 항목이다. 실행 파일과 설정 파일, 설치 아이콘 등 설치에 필요한 구성 요소와 그 위치를 안내해 사용자가 올바른 파일로 설치를 시작하게 한다.
3. 프로그램 삭제는 설치 매뉴얼의 포함 항목이다. 설치한 제품을 제거하는 절차와 주의사항을 함께 제공해야 사용자가 재설치나 정리를 스스로 수행할 수 있다.
4. 소프트웨어 개발 기간은 프로젝트 수행 이력에 해당하는 관리 정보이며 설치 절차와 무관하다. 사용자가 제품을 설치·운용하는 데 필요한 내용이 아니므로 설치 매뉴얼 항목에 포함되지 않는다.

정리

설치 매뉴얼 구성 — 제품 개요, 설치 관련 파일·아이콘, 설치 환경(HW/OS 요구사항), 설치 절차, 주의사항·오류 대처, 프로그램 삭제, 저작권·기술 지원 정보.
#소프트웨어개발
Q14

다음 중 단위 테스트를 통해 발견할 수 있는 오류가 아닌 것은?

1알고리즘 오류에 따른 원치 않는 결과
2탈출구가 없는 반복문의 사용
3모듈 간의 비정상적 상호 작용으로 인한 원치 않는 결과
4틀린 계산 수식에 의한 잘못된 결과
정답 3번 · 모듈 간의 비정상적 상호 작용으로 인한 원치 않는 결과

핵심 해설

단위 테스트(Unit Test)는 코딩 직후 모듈이나 컴포넌트 하나를 독립적으로 실행해 내부 로직의 결함을 찾는 테스트로, 구조 기반(화이트박스) 기법이 중심이 된다. 검출 대상은 모듈 내부의 알고리즘 오류, 잘못된 계산식, 자료 구조·변수 사용 오류, 탈출 조건이 없는 무한 반복문, 경계값 처리 오류 등 모듈 하나만 실행해도 드러나는 결함이다. 반면 모듈 간 인터페이스 규격 불일치나 파라미터 전달 오류처럼 두 개 이상의 모듈이 결합되어야 나타나는 결함은 통합 테스트(Integration Test)의 대상이다. 따라서 단위 테스트로 발견할 수 없는 것은 모듈 간 비정상적 상호 작용으로 인한 오류이다.

보기별 해설

1. 알고리즘 오류에 따른 원치 않는 결과는 모듈 내부 로직의 결함이므로 단위 테스트로 발견할 수 있다. 모듈 하나에 입력을 넣고 기대 출력과 비교하는 것만으로 로직의 잘못이 드러난다.
2. 탈출구가 없는 반복문의 사용은 모듈 내부 제어 흐름의 결함이므로 단위 테스트 대상이다. 루프 검사나 기초 경로 검사 같은 화이트박스 기법으로 반복 종료 조건을 확인해 무한 루프를 잡아낸다.
3. 모듈 간의 비정상적 상호 작용으로 인한 오류는 두 개 이상의 모듈을 결합해야 나타나므로 통합 테스트에서 발견된다. 인터페이스 규격 불일치나 파라미터 전달 오류가 대표적이며, 모듈 하나만 실행하는 단위 테스트로는 드러나지 않는다.
4. 틀린 계산 수식에 의한 잘못된 결과는 모듈 내부 연산의 결함이므로 단위 테스트로 발견된다. 대표값과 경계값을 입력해 산출 결과를 기대값과 대조하면 수식 오류를 즉시 확인할 수 있다.

정리

테스트 레벨 — 단위(모듈 내부 로직·계산·자료구조·루프) → 통합(모듈 간 인터페이스·상호작용) → 시스템(전체 기능·성능) → 인수(사용자 요구 충족 여부).
#소프트웨어개발#테스트
Q15

다음 설명의 소프트웨어 버전 관리 도구 방식은? ㆍ버전 관리 자료가 원격 저장소와 로컬 저장소에 함께 저장되어 관리된다. ㆍ로컬 저장소에서 버전 관리가 가능하므로 원격 저장소 에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업 할 수 있다. ㆍ대표적인 버전 관리 도구로 Git이 있다.

1단일 저장소 방식
2분산 저장소 방식
3공유 폴더 방식
4클라이언트서버· 방식
정답 2번 · 분산 저장소 방식

핵심 해설

소프트웨어 버전 관리 도구는 저장소 운영 방식에 따라 공유 폴더 방식, 클라이언트/서버 방식, 분산 저장소 방식으로 나뉜다. 분산 저장소 방식은 원격 저장소의 이력 전체를 로컬 저장소에도 복제해 두는 방식으로, 개발자가 네트워크에 연결되지 않았거나 원격 서버에 장애가 생겨도 로컬에서 커밋·이력 조회 같은 버전 관리 작업을 계속할 수 있다. 대표 도구는 Git과 Bitkeeper이며, 로컬 작업 결과는 나중에 push로 원격 저장소에 반영한다. 자료가 원격과 로컬에 함께 저장되고 Git이 대표 도구라는 설명은 분산 저장소 방식에 해당한다.

보기별 해설

1. 단일 저장소 방식은 버전 관리 도구의 표준 분류 명칭이 아니다. 저장소가 하나뿐이라는 의미로 쓰인다면 서버 한 곳에만 이력을 두는 클라이언트/서버 방식에 가까우며, 로컬에 이력이 복제되는 분산 방식과는 반대 개념이다.
2. 분산 저장소 방식은 원격 저장소의 버전 관리 자료를 로컬 저장소에도 그대로 복제해 관리하는 방식이다. 원격 서버에 장애가 발생해도 로컬 이력만으로 커밋과 조회가 가능하며, 대표 도구가 Git이다.
3. 공유 폴더 방식은 네트워크로 공유된 폴더에 파일을 복사해 두고 담당자가 이를 확인해 반영하는 초기 형태의 방식이다. RCS, SCCS가 여기에 속하며 자동 이력 관리나 원격·로컬 이중 저장 개념이 없다.
4. 클라이언트/서버 방식은 버전 관리 자료를 중앙 서버에만 두고 개발자들이 각자 클라이언트로 접속해 작업하는 방식이다. CVS와 Subversion(SVN)이 대표적이며, 서버에 장애가 생기면 작업이 중단된다는 점이 분산 방식과 결정적으로 다르다.

정리

버전 관리 방식 — 공유 폴더(RCS·SCCS), 클라이언트/서버(CVS·SVN, 중앙 집중), 분산 저장소(Git·Bitkeeper, 원격+로컬 이중 저장으로 오프라인 작업 가능).
#소프트웨어개발
Q16

다음 중 최악의 경우 검색 효율이 가장 나쁜 트리 구조는?

1이진 탐색 트리
2AVL 트리
32-3 트리
4레드블랙- 트리
정답 1번 · 이진 탐색 트리

핵심 해설

이진 탐색 트리(BST)는 왼쪽 서브트리에 작은 값, 오른쪽 서브트리에 큰 값을 두는 트리로 평균 검색 시간은 O(log n)이다. 그러나 균형을 스스로 맞추는 장치가 전혀 없어 오름차순으로 정렬된 데이터를 차례로 삽입하면 모든 노드가 한쪽으로만 이어지는 편향 트리(사향 이진 트리)가 되어 사실상 연결 리스트와 같아지고, 이때 검색은 최악 O(n)이 된다. 반면 AVL 트리, 2-3 트리, 레드-블랙 트리는 삽입·삭제 시 회전이나 노드 분할로 높이를 스스로 조정하는 균형 트리라서 최악의 경우에도 높이가 O(log n)으로 유지된다. 따라서 최악의 경우 검색 효율이 가장 나쁜 것은 이진 탐색 트리이다.

보기별 해설

1. 이진 탐색 트리는 균형 유지 기능이 없는 기본 탐색 트리로, 최악의 경우 검색 시간이 O(n)까지 나빠진다. 정렬된 순서대로 삽입하면 한쪽으로만 뻗은 편향 트리가 되어 높이가 n에 이르기 때문이다.
2. AVL 트리는 모든 노드에서 좌우 서브트리 높이 차(균형 인수)를 −1, 0, 1로 유지하는 자가 균형 이진 탐색 트리이다. 균형이 깨지면 LL·LR·RL·RR 회전으로 즉시 복구하므로 최악에도 검색이 O(log n)이다.
3. 2-3 트리는 한 노드가 자식을 2개 또는 3개 가질 수 있고 모든 리프가 같은 깊이에 놓이는 균형 다진 탐색 트리이다. 노드가 넘치면 분할해 높이를 조절하므로 최악에도 O(log n)을 보장한다.
4. 레드-블랙 트리는 노드에 빨강·검정 색을 부여하고 색 규칙으로 최장 경로가 최단 경로의 2배를 넘지 않도록 제한하는 자가 균형 이진 탐색 트리이다. 삽입·삭제 시 회전과 색 변경으로 균형을 유지해 최악에도 O(log n)이다.

정리

탐색 트리 최악 성능 — 이진 탐색 트리는 편향 시 O(n), AVL·2-3·레드-블랙 등 자가 균형 트리는 최악에도 O(log n)을 보장한다.
#소프트웨어개발
Q17

코드의 간결성을 유지하기 위해 사용되는 지침으로 틀린 것은?

1공백을 이용하여 실행문 그룹과 주석을 명확히 구분한다.
2복잡한 논리식과 산술식은 괄호와 들여쓰기(Indentation)를 통 해 명확히 표현한다.
3빈 줄을 사용하여 선언부와 구현부를 구별한다.
4한 줄에 최대한 많은 문장을 코딩한다.
정답 4번 · 한 줄에 최대한 많은 문장을 코딩한다.

핵심 해설

소스 코드 작성 지침에서 간결성(단순성)은 코드를 한눈에 읽고 이해할 수 있게 유지하라는 원칙이다. 실행문 그룹과 주석을 공백으로 구분하고, 복잡한 수식은 괄호와 들여쓰기로 계산 순서를 드러내며, 빈 줄로 선언부와 구현부를 나누는 것이 모두 가독성을 높이는 구체적 방법이다. 반대로 한 줄에 여러 문장을 몰아 넣으면 각 문장의 경계가 흐려지고 디버깅 시 문제 지점을 특정하기 어려워져 오히려 코드가 난해해진다. 클린 코드의 단순성 원칙은 '한 번에 한 가지 처리만 수행'하는 것이므로, 한 줄에 최대한 많은 문장을 코딩하라는 4번이 틀렸다.

보기별 해설

1. 공백을 이용해 실행문 그룹과 주석을 명확히 구분하는 것은 옳은 지침이다. 코드 블록과 설명이 시각적으로 분리되어 어느 주석이 어느 코드에 붙는지 즉시 파악된다.
2. 복잡한 논리식과 산술식을 괄호와 들여쓰기로 명확히 표현하는 것은 옳은 지침이다. 연산자 우선순위에 의존한 암묵적 해석을 없애 계산 순서 오해로 인한 논리 오류를 예방한다.
3. 빈 줄을 사용해 선언부와 구현부를 구별하는 것은 옳은 지침이다. 변수·상수 선언 영역과 실제 처리 로직이 나뉘어 코드의 구조를 빠르게 훑을 수 있다.
4. 한 줄에 최대한 많은 문장을 코딩하라는 것은 간결성 지침에 어긋난다. 한 줄에는 한 문장만 작성해야 각 처리의 경계가 분명해지고 디버깅 시 오류 위치를 행 단위로 특정할 수 있으며, 클린 코드의 단순성 원칙도 한 번에 한 가지 처리를 요구한다.

정리

코드 간결성 지침 — 한 줄에 한 문장, 괄호·들여쓰기로 수식 명확화, 빈 줄로 선언부·구현부 분리, 공백으로 주석과 실행문 구분. 클린 코드 원칙: 가독성·단순성·의존성 배제·중복 최소화·추상화.
#소프트웨어개발
Q18

다음 중 선형 구조로만 묶인 것은?

1스택트리,
2큐데크,
3큐그래프,
4리스트그래프, - 3
정답 2번 · 큐데크,

핵심 해설

자료 구조는 원소들이 한 줄로 나열되어 앞뒤 관계가 1:1로 정해지는 선형 구조와, 계층이나 망 형태로 연결되어 1:N 또는 N:M 관계를 갖는 비선형 구조로 나뉜다. 선형 구조에는 배열, 연결 리스트, 스택, 큐, 데크가 속하고, 비선형 구조에는 트리와 그래프가 속한다. 큐는 rear에서 삽입하고 front에서 삭제하는 FIFO 선형 구조이고, 데크(Deque)는 양쪽 끝 모두에서 삽입·삭제가 가능한 선형 구조이다. 따라서 선형 구조로만 묶인 것은 큐와 데크이다.

보기별 해설

1. 스택, 트리 조합은 선형 구조로만 묶인 것이 아니다. 스택은 top 한쪽에서만 push·pop이 일어나는 LIFO 선형 구조이지만, 트리는 부모-자식 계층 관계로 이루어진 비선형 구조이다.
2. 큐, 데크는 모두 선형 구조이다. 큐는 rear 삽입·front 삭제의 FIFO 구조이고, 데크(Deque)는 양쪽 끝에서 모두 삽입과 삭제가 가능한 구조로 둘 다 원소가 일렬로 나열된다.
3. 큐, 그래프 조합은 선형 구조로만 묶인 것이 아니다. 큐는 선형 구조이지만, 그래프는 정점과 간선의 집합으로 사이클까지 가질 수 있는 대표적인 비선형 구조이다.
4. 리스트, 그래프 조합도 선형 구조로만 묶인 것이 아니다. 선형 리스트·연결 리스트는 선형 구조에 속하지만, 그래프는 정점 간 연결이 N:M으로 얽히는 비선형 구조이다.

정리

선형 구조 = 배열, 연결 리스트, 스택(LIFO), 큐(FIFO), 데크(양쪽 삽입·삭제) / 비선형 구조 = 트리(계층), 그래프(망).
#소프트웨어개발
Q19

코드 인스펙션과 관련한 설명으로 틀린 것은?

1프로그램을 수행시켜보는 것 대신에 읽어보고 눈으로 확인하 는 방법으로 볼 수 있다.
2코드 품질 향상 기법 중 하나이다.
3동적 테스트 시에만 활용하는 기법이다.
4결함과 함께 코딩 표준 준수 여부효율성, 등의 다른 품질 이슈 를 검사하기도 한다.
정답 3번 · 동적 테스트 시에만 활용하는 기법이다.

핵심 해설

코드 인스펙션(Code Inspection)은 소프트웨어 검토(Review) 기법의 하나로, 프로그램을 실행하지 않고 소스 코드를 여러 명이 읽으며 결함을 찾아내는 정적 테스트에 속한다. 사전에 배포된 자료를 참가자들이 미리 검토한 뒤 회의를 열어 결함을 지적하고, 발견된 문제는 기록해 수정 여부를 추적하는 공식적 절차를 따른다. 코딩 표준 준수 여부, 성능·효율성, 가독성 같은 품질 이슈도 함께 점검하는 코드 품질 향상 기법이다. 프로그램을 실제로 수행하며 결과를 확인하는 동적 테스트와 정반대이므로, 동적 테스트 시에만 활용한다는 3번이 틀렸다.

보기별 해설

1. 프로그램을 수행시키는 대신 읽어보고 눈으로 확인하는 방법이라는 것은 옳은 설명이다. 코드 인스펙션은 실행 없이 소스를 검토하는 정적 분석 기법의 대표 사례이다.
2. 코드 품질 향상 기법 중 하나라는 것은 옳은 설명이다. 개발 초기 단계에서 결함을 조기에 발견해 수정 비용을 낮추고 코딩 표준을 정착시키는 효과가 있다.
3. 동적 테스트 시에만 활용하는 기법이라는 것은 틀린 설명이다. 코드 인스펙션은 프로그램을 실행하지 않고 코드를 검토하는 정적 테스트이며, 테스트 데이터를 넣고 실제로 실행해 결과를 확인하는 것은 화이트박스·블랙박스 같은 동적 테스트이다.
4. 결함과 함께 코딩 표준 준수 여부, 효율성 등 다른 품질 이슈도 검사한다는 것은 옳은 설명이다. 인스펙션은 버그 검출뿐 아니라 명명 규칙·주석·구조 등 코드 품질 전반을 점검 대상으로 삼는다.

정리

정적 테스트 = 코드 인스펙션, 워크스루, 동료 검토(실행 없이 검토) / 동적 테스트 = 화이트박스·블랙박스(실제 실행 후 결과 확인).
#소프트웨어개발#테스트
Q20

소프트웨어를 재사용함으로써 얻을 수 있는 이점으로 가장 거리가 먼 것은?

1생산성 증가
2프로젝트 문서 공유
3소프트웨어 품질 향상
4새로운 개발 방법론 도입 용이
정답 4번 · 새로운 개발 방법론 도입 용이

핵심 해설

소프트웨어 재사용(Reuse)은 이미 개발되어 검증된 모듈이나 컴포넌트를 새 시스템에 다시 활용하는 기법으로, 합성 중심(부품 조립)과 생성 중심(명세로부터 생성) 방식이 있다. 기대 효과는 개발 시간과 비용 절감에 따른 생산성 향상, 검증된 자산 사용에 따른 품질 및 신뢰성 향상, 프로젝트 문서의 공유와 표준화, 시스템 구축 시간 단축이다. 반면 재사용은 기존 자산의 구조와 인터페이스에 새 시스템을 맞추게 하므로 오히려 낡은 기술·구조에 묶여 새로운 개발 방법론을 도입하기 어려워지는 요인이 된다. 따라서 이점과 가장 거리가 먼 것은 새로운 개발 방법론 도입 용이이다.

보기별 해설

1. 생산성 증가는 재사용의 대표적 이점이다. 이미 만들어진 모듈을 가져다 쓰므로 설계·구현·테스트에 드는 공수가 줄고 같은 기간에 더 많은 기능을 완성할 수 있다.
2. 프로젝트 문서 공유는 재사용의 이점이다. 재사용 대상 모듈의 명세서와 설계 문서를 여러 프로젝트가 함께 사용하면서 문서 표준화와 지식 축적이 이루어진다.
3. 소프트웨어 품질 향상은 재사용의 이점이다. 이미 여러 현장에서 사용되며 결함이 걸러진 검증된 자산을 쓰기 때문에 새로 작성한 코드보다 신뢰성이 높다.
4. 새로운 개발 방법론 도입 용이는 재사용의 이점이 아니다. 재사용은 기존 자산의 구조·인터페이스·기술 스택에 새 시스템을 맞추도록 강제하므로 오히려 새로운 방법론이나 기술의 도입을 제약하는 요인으로 작용한다.

정리

재사용 이점 — 개발 시간·비용 절감(생산성 향상), 검증된 자산에 의한 품질·신뢰성 향상, 문서·표준 공유, 시스템 구축 시간 단축. 단, 기존 자산에 종속되어 새 방법론 도입은 오히려 어려워진다.
#소프트웨어개발