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

2025년 1회

소스 코드 품질 분석 도구 중 정적 분석 도구가 아닌 것은?

1pmd

2cppcheck

3valMeter

4checkstyle - 2

정답 3번 · valMeter

핵심 해설

소스 코드 품질 분석 도구는 프로그램을 실행하지 않고 코드 자체를 검사하는 정적 분석 도구와, 프로그램을 실행하면서 메모리 누수·성능을 측정하는 동적 분석 도구로 나뉜다. 정적 분석 도구의 대표는 pmd, cppcheck, checkstyle, SonarQube, ccm, cobertura이며, 동적 분석 도구에는 Avalanche, Valgrind가 있다. 정적 분석은 코딩 표준 위반, 잠재적 널 참조, 사용되지 않는 변수처럼 실행 전에 드러나는 결함을 잡아낸다. 보기 중 valMeter는 이러한 도구 목록에 존재하지 않는 명칭이므로 정적 분석 도구가 아니다.

보기별 해설

1. pmd는 Java·JavaScript 등의 소스 코드를 실행하지 않고 검사하는 정적 분석 도구이다. 미사용 변수, 비어 있는 catch 블록, 불필요한 객체 생성처럼 결함 가능성이 높은 코드 패턴을 규칙으로 탐지한다.

2. cppcheck는 C/C++ 전용 정적 분석 도구이다. 메모리 누수 가능성, 버퍼 오버플로, 초기화되지 않은 변수 사용 등 컴파일러가 놓치는 결함을 소스 코드 수준에서 검출한다.

3. valMeter는 소스 코드 품질 분석 도구 분류에 존재하지 않는 명칭이다. 이름이 비슷한 Valgrind는 프로그램을 실제로 실행해 메모리 누수와 오류를 추적하는 동적 분석 도구이므로, 정적 분석 도구와는 범주 자체가 다르다.

4. checkstyle은 Java 소스 코드가 코딩 표준(들여쓰기, 명명 규칙, 주석 형식 등)을 지키는지 검사하는 정적 분석 도구이다. 팀 단위의 코드 스타일 일관성 확보에 널리 쓰인다.

정리

정적 분석 도구 = pmd, cppcheck, checkstyle, SonarQube, ccm, cobertura(실행하지 않고 코드 검사) / 동적 분석 도구 = Avalanche, Valgrind(실행하며 메모리·성능 측정).

#소프트웨어개발

White Box Testing에 대한 설명으로 옳지 않은 것은?

1Base Path Testing, Boundary Value Analysis가 대표적인 기법이다.

2Source Code의 모든 문장을 한 번 이상 수행함으로써 진행 된다.

3모듈 안의 작동을 직접 관찰할 수 있다.

4산출물의 각 기능별로 적절한 프로그램의 제어 구조에 따라 선택반복, 등의 부분들을 수행함으로써 논리적 경로를 점검한 다.

정답 1번 · Base Path Testing, Boundary Value Analysis가 대표적인 기법이다.

핵심 해설

화이트박스 테스트(White Box Testing)는 프로그램 내부의 소스 코드와 제어 구조를 직접 들여다보고 논리적 경로를 점검하는 구조 기반 기법이다. 대표 기법은 기초 경로 검사(Base Path Testing), 조건 검사, 루프 검사, 데이터 흐름 검사이며, 검증 기준으로 문장·분기·조건 커버리지를 사용한다. 반면 경계값 분석(Boundary Value Analysis)은 입력 조건의 경계 부근 값을 테스트 데이터로 삼는 기법으로, 내부 구조를 보지 않고 명세만으로 케이스를 설계하는 블랙박스 테스트에 속한다. 따라서 두 기법을 함께 화이트박스의 대표 기법으로 묶은 1번이 옳지 않다.

보기별 해설

1. Base Path Testing과 Boundary Value Analysis가 대표 기법이라는 서술은 서로 다른 범주를 섞었으므로 틀렸다. 기초 경로 검사는 화이트박스 기법이지만 경계값 분석은 입력 경계 부근의 값을 뽑는 블랙박스 기법으로, 동치 분할·원인효과 그래프·오류 예측과 같은 계열이다.

2. Source Code의 모든 문장을 한 번 이상 수행한다는 것은 화이트박스 테스트의 문장 커버리지(Statement Coverage)를 가리키는 옳은 설명이다. 코드 내부를 볼 수 있어야만 세울 수 있는 기준이다.

3. 모듈 안의 작동을 직접 관찰할 수 있다는 것은 화이트박스 테스트의 정의에 부합하는 옳은 설명이다. 상자 내부가 들여다보인다는 뜻에서 '화이트박스'라는 이름이 붙었다.

4. 산출물의 각 기능별로 프로그램의 제어 구조에 따라 선택·반복 등의 부분을 수행해 논리적 경로를 점검한다는 것은 화이트박스 테스트의 옳은 설명이다. 제어 흐름을 따라가며 경로를 검사하는 것이 구조 기반 테스트의 핵심이다.

정리

화이트박스 기법 = 기초 경로 검사, 조건 검사, 루프 검사, 데이터 흐름 검사 / 블랙박스 기법 = 동치 분할, 경계값 분석, 원인효과 그래프, 오류 예측, 비교 검사.

#소프트웨어개발

소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견된다는 법칙은?

1Brooks의 법칙

2Boehm의 법칙

3Pareto의 법칙

4Jackson의 법칙

정답 3번 · Pareto의 법칙

핵심 해설

소프트웨어 테스트의 기본 원리 중 결함 집중(Defect Clustering)은 전체 결함의 대부분이 소수의 모듈에 몰려 있다는 경험적 사실을 말하며, 흔히 '오류의 80%는 전체 모듈의 20%에서 발견된다'로 표현된다. 이는 이탈리아 경제학자 파레토가 발견한 80대 20 법칙을 소프트웨어 품질에 적용한 것이므로 Pareto의 법칙이라 부른다. 결함이 몰린 모듈을 집중적으로 테스트하면 효율이 크게 오르지만, 같은 테스트만 반복하면 새 결함이 나오지 않는 살충제 패러독스에 유의해야 한다.

보기별 해설

1. Brooks의 법칙은 '지연되는 소프트웨어 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다'는 프로젝트 관리 법칙이다. 새 인원의 교육 비용과 의사소통 경로 증가가 원인이며, 결함 분포와는 무관하다.

2. Boehm의 법칙은 결함을 늦게 발견할수록 수정 비용이 기하급수적으로 커진다는 원칙으로, COCOMO 비용 산정 모형을 만든 Barry Boehm의 이름에서 유래했다. 오류의 분포 비율을 말하는 법칙이 아니다.

3. Pareto의 법칙은 결과의 80%가 원인의 20%에서 비롯된다는 80대 20 법칙으로, 테스트에서는 오류의 80%가 전체 모듈의 20%에서 발견된다는 결함 집중 원리로 적용된다.

4. Jackson의 법칙은 테스트 원리로 정립된 명칭이 아니다. Jackson이라는 이름은 입출력 자료 구조를 기반으로 프로그램 구조를 설계하는 Jackson 설계 기법(JSP/JSD)에서 쓰이며, 결함 분포와는 관계가 없다.

정리

테스트의 기본 원리 — 결함 집중(파레토 법칙, 오류 80%가 모듈 20%에 몰림), 살충제 패러독스, 완벽한 테스트 불가능, 테스팅은 정황 의존, 오류-부재의 궤변, 결함은 조기 발견이 유리.

#소프트웨어개발#테스트

다음 트리의 차수(degree)는?

정답 2번 · 3

핵심 해설

트리의 차수(degree)는 트리에 속한 모든 노드의 차수 중 가장 큰 값을 말하며, 각 노드의 차수는 그 노드가 가진 자식(서브트리)의 개수이다. 즉 어떤 노드도 자식을 3개보다 많이 갖지 않고 자식이 3개인 노드가 최소 하나 존재하면 그 트리의 차수는 3이 된다. 정답이 3이므로 제시된 트리에는 자식이 3개인 노드가 있고 그보다 많은 자식을 가진 노드는 없다. 여기서 트리의 높이(레벨 수)나 단말 노드 수와 혼동하지 않는 것이 중요하다.

보기별 해설

1. 2는 모든 노드가 자식을 최대 2개까지만 갖는 이진 트리(binary tree)의 차수이다. 제시된 트리에는 자식이 3개인 노드가 존재하므로 최댓값이 2에 머물지 않는다.

2. 3은 이 트리에서 한 노드가 가진 자식 수의 최댓값이다. 자식을 3개 거느린 노드가 있고 그보다 많은 자식을 가진 노드는 없으므로 트리의 차수는 3이다.

3. 4는 자식이 4개인 노드가 있을 때의 차수 값이다. 트리의 차수를 노드의 총 개수나 단말 노드 수로 세면 이런 값이 나오기 쉬우나, 차수는 어디까지나 한 노드의 자식 수 최댓값이다.

4. 5는 자식이 5개인 노드가 존재해야 나오는 값이다. 트리 전체의 간선 수나 레벨 수를 차수로 착각할 때 고르기 쉬운 오답이다.

정리

트리 용어 — 노드의 차수 = 그 노드의 자식(서브트리) 수, 트리의 차수 = 모든 노드 차수의 최댓값, 단말(리프) 노드 = 차수가 0인 노드, 높이 = 최대 레벨.

#소프트웨어개발

디지털 저작권 관리(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·해밍)은 데이터 통신 기술이다.

#소프트웨어개발#암호화

다음 자료에 대하여 “Selection Sort”를 사용하여 오름차순으로 정렬한 경우 PASS 3의 결과는? 초기상태 : 8, 3, 4, 9, 7

13, 4, 7, 9, 8

23, 4, 8, 9, 7

33, 8, 4, 9, 7

43, 4, 7, 8, 9

정답 1번 · 3, 4, 7, 9, 8

핵심 해설

선택 정렬(Selection Sort)은 아직 정렬되지 않은 구간에서 최솟값을 찾아 그 구간의 맨 앞 원소와 교환하는 과정을 반복하며, PASS k가 끝나면 앞쪽 k개가 작은 값부터 확정된다. 초기 상태 8, 3, 4, 9, 7에서 PASS 1은 전체 최솟값 3을 찾아 첫 자리 8과 교환해 3, 8, 4, 9, 7이 된다. PASS 2는 2번째 자리부터의 최솟값 4를 찾아 8과 교환해 3, 4, 8, 9, 7이 되고, PASS 3은 3번째 자리부터의 최솟값 7을 찾아 8과 교환해 3, 4, 7, 9, 8이 된다. 따라서 PASS 3의 결과는 3, 4, 7, 9, 8이다.

보기별 해설

1. 3, 4, 7, 9, 8은 PASS 3이 끝난 시점의 상태이다. 3번째 자리부터의 구간 8, 9, 7에서 최솟값 7을 찾아 8과 교환한 결과이며, 앞 세 자리 3·4·7이 확정되고 남은 9와 8은 아직 뒤바뀐 채로 남아 있다.

2. 3, 4, 8, 9, 7은 PASS 2가 끝난 시점의 상태이다. 최솟값 4를 두 번째 자리의 8과 교환해 앞 두 자리만 확정된 단계이므로 한 회전 이른 상태이다.

3. 3, 8, 4, 9, 7은 PASS 1이 끝난 시점의 상태이다. 전체 최솟값 3을 첫 자리의 8과 교환해 3만 확정되었을 뿐, 나머지 8, 4, 9, 7은 초기 순서 그대로 남아 있다.

4. 3, 4, 7, 8, 9는 PASS 4까지 마친 최종 정렬 결과이다. 원소가 5개이므로 PASS 4에서 9와 8이 교환되어 완성되며, PASS 3 시점에는 아직 맨 뒤 두 값이 9, 8 순서이다.

정리

선택 정렬 각 PASS (8,3,4,9,7 오름차순) — PASS 1: 3,8,4,9,7 / PASS 2: 3,4,8,9,7 / PASS 3: 3,4,7,9,8 / PASS 4: 3,4,7,8,9. PASS k 종료 시 앞쪽 k개가 작은 값부터 확정된다.

#소프트웨어개발

소프트웨어 공학의 기본 원칙이라고 볼 수 없는 것은?

1품질 높은 소프트웨어 상품 개발

2지속적인 검증 시행

3결과에 대한 명확한 기록 유지

4최대한 많은 인력 투입

정답 4번 · 최대한 많은 인력 투입

핵심 해설

소프트웨어 공학의 기본 원칙은 첫째 품질 높은 소프트웨어 상품을 개발하는 것, 둘째 개발 과정 전반에 걸쳐 지속적인 검증을 시행하는 것, 셋째 결과에 대한 명확한 기록을 유지하는 것 세 가지이다. 이는 최소 비용으로 최단 기간에 최상의 품질을 얻기 위한 공학적 접근을 압축한 것이다. 반면 인력을 많이 투입한다고 생산성이 비례해 오르지는 않으며, 오히려 의사소통 경로가 늘어 지연을 유발한다는 것이 브룩스의 법칙이다. 따라서 최대한 많은 인력 투입은 기본 원칙이 아니다.

보기별 해설

1. 품질 높은 소프트웨어 상품 개발은 소프트웨어 공학의 첫 번째 기본 원칙이다. 공학적 방법론과 도구를 적용하는 궁극적 목적이 품질 확보이기 때문이다.

2. 지속적인 검증 시행은 소프트웨어 공학의 기본 원칙이다. 각 단계마다 검토와 테스트를 수행해 결함을 조기에 발견해야 수정 비용이 급증하는 것을 막을 수 있다.

3. 결과에 대한 명확한 기록 유지는 소프트웨어 공학의 기본 원칙이다. 산출물과 변경 이력을 문서로 남겨야 추적성과 유지보수성이 확보되며, 형상 관리의 근거가 된다.

4. 최대한 많은 인력 투입은 기본 원칙이 아니다. 인원이 늘면 의사소통 경로가 n(n-1)/2로 급증하고 교육 부담이 생겨 오히려 일정이 지연된다는 것이 브룩스의 법칙이며, 소프트웨어 공학은 최소 비용과 노력으로 최대 품질을 얻는 것을 지향한다.

정리

소프트웨어 공학의 기본 원칙 3가지 — 품질 높은 상품 개발, 지속적인 검증 시행, 결과에 대한 명확한 기록 유지. 인력 증원은 오히려 지연을 부른다(브룩스의 법칙).

#소프트웨어개발

빌드 자동화 도구에 대한 설명으로 틀린 것은?

1Gradle은 실행할 처리 명령들을 모아 태스크로 만든 후 태스크 단위로 실행한다.

2빌드 자동화 도구는 지속적인 통합 개발 환경에서 유용하게 활용된다.

3빌드 자동화 도구에는 Ant, Gradle, Jenkins 등이 있다.

4Jenkins는 Groovy를 기반으로 한 오픈 소스로 안드로이드 앱 개발 환경에서 사용된다.

정답 4번 · Jenkins는 Groovy를 기반으로 한 오픈 소스로 안드로이드 앱 개발 환경에서 사용된다.

핵심 해설

빌드 자동화 도구는 소스 코드의 컴파일·테스트·패키징·배포를 자동으로 수행하는 도구로 Ant, Maven, Gradle, Jenkins가 대표적이며, 지속적 통합(CI) 환경의 핵심 요소이다. 이 중 Gradle은 Groovy 기반의 오픈 소스 빌드 도구로 안드로이드 앱 개발의 공식 빌드 시스템으로 채택되어 있다. Jenkins는 Java 기반의 서버형 CI 도구로, 여러 개발자의 커밋을 모아 주기적으로 빌드·테스트를 실행하고 결과를 알려주는 역할을 한다. 따라서 Jenkins에 Gradle의 설명을 붙인 4번이 틀렸다.

보기별 해설

1. Gradle은 실행할 처리 명령들을 모아 태스크(Task)로 만든 후 태스크 단위로 실행한다는 옳은 설명이다. 태스크 사이의 의존 관계를 분석해 필요한 것만 실행하며, 이미 처리된 태스크는 재사용해 빌드 시간을 줄인다.

2. 빌드 자동화 도구가 지속적인 통합(CI) 개발 환경에서 유용하다는 것은 옳은 설명이다. 커밋마다 자동으로 빌드와 테스트를 수행해 통합 시점의 충돌과 결함을 조기에 드러낸다.

3. 빌드 자동화 도구에 Ant, Gradle, Jenkins 등이 있다는 것은 옳은 설명이다. Ant는 XML 기반의 초기 자바 빌드 도구, Gradle은 Groovy 기반 빌드 도구, Jenkins는 서버 기반 CI 도구로 모두 빌드 자동화 범주에 속한다.

4. Jenkins가 Groovy 기반 오픈 소스로 안드로이드 앱 개발 환경에서 사용된다는 설명은 Gradle의 특징을 옮겨 놓은 것이므로 틀렸다. Jenkins는 Java 기반의 서버형 지속적 통합 도구로 웹 인터페이스를 통해 빌드·테스트를 자동 수행하며, SVN·Git 등 대부분의 형상 관리 도구와 연동된다.

정리

빌드 자동화 도구 — Ant(XML 기반), Maven(의존성 관리), Gradle(Groovy 기반, 안드로이드 공식 빌드, 태스크 단위 실행), Jenkins(Java 기반 서버형 CI, SCM 연동).

#소프트웨어개발

소프트웨어 형상 관리에서 관리 항목에 포함되지 않는 것은?

1운영 및 설치 지침서

2프로젝트 개발 비용

3소스 코드

4프로젝트 요구 분석서 2

정답 2번 · 프로젝트 개발 비용

핵심 해설

소프트웨어 형상 관리(SCM)는 개발 과정에서 산출되는 결과물의 변경 사항을 체계적으로 관리해 가시성과 추적성을 확보하는 활동이다. 관리 대상인 형상 항목(Configuration Item)은 개발 과정에서 생성되어 버전이 바뀌며 유지되는 산출물, 즉 프로젝트 요구 분석서, 설계서, 소스 코드, 운영 및 설치 지침서, 테스트 케이스 같은 문서와 코드이다. 반면 개발 비용은 프로젝트 관리·비용 산정 영역에서 다루는 관리 지표일 뿐 버전 관리 대상 산출물이 아니다. 따라서 형상 관리 항목에 포함되지 않는 것은 프로젝트 개발 비용이다.

보기별 해설

1. 운영 및 설치 지침서는 형상 관리 항목에 포함된다. 제품 배포와 함께 갱신되는 산출물 문서이므로 버전을 붙여 관리해야 사용자에게 잘못된 판이 전달되는 것을 막을 수 있다.

2. 프로젝트 개발 비용은 형상 관리 항목이 아니다. 비용은 LOC·COCOMO 등으로 산정하고 프로젝트 관리 계획에서 통제하는 관리 지표이며, 버전을 부여해 변경 이력을 추적할 산출물이 아니다.

3. 소스 코드는 형상 관리의 가장 대표적인 항목이다. Git·SVN 등 버전 관리 시스템으로 변경 이력을 저장해 누가 언제 무엇을 고쳤는지 추적하고 이전 버전으로 복구할 수 있게 한다.

4. 프로젝트 요구 분석서는 형상 관리 항목에 포함된다. 요구사항은 개발 도중 자주 변경되므로 기준선(Baseline)을 설정하고 변경 요청을 통제해야 후속 설계·구현과의 정합성이 유지된다.

정리

형상 관리 항목 = 요구 분석서, 설계서, 소스 코드, 운영·설치 지침서, 테스트 케이스 등 버전이 관리되는 산출물. 개발 비용·일정 같은 관리 지표는 형상 항목이 아니다.

#소프트웨어개발

Q10

EAI(Enterprise Application Integration) 구축 유형 중 Hybrid에 대한 설명으로 틀린 것은?

1Hub & Spoke와 Message Bus의 혼합 방식이다.

2필요한 경우 한 가지 방식으로 EAI 구현이 가능하다.

3데이터 병목 현상을 최소화할 수 있다.

4중간에 미들웨어를 두지 않고 각 애플리케이션을 point to point로 연결한다.

정답 4번 · 중간에 미들웨어를 두지 않고 각 애플리케이션을 point to point로 연결한다.

핵심 해설

EAI(Enterprise Application Integration)는 기업 내 서로 다른 응용 프로그램을 연계·통합하는 솔루션으로, 구축 유형은 Point-to-Point, Hub & Spoke, Message Bus(ESB), Hybrid 네 가지이다. Hybrid는 그룹 내부는 Hub & Spoke로, 그룹 사이는 Message Bus로 연결하는 혼합 방식이어서 필요에 따라 한 가지 방식만으로도 구현할 수 있고 데이터 병목 현상을 줄일 수 있다. 반면 미들웨어를 두지 않고 애플리케이션을 1대1로 직접 연결하는 것은 가장 단순한 유형인 Point-to-Point의 설명이다. 따라서 Hybrid에 대한 설명으로 틀린 것은 4번이다.

보기별 해설

1. Hub & Spoke와 Message Bus의 혼합 방식이라는 것은 Hybrid의 정의 그대로이다. 그룹 내부는 허브 중심으로, 그룹 사이는 버스로 연결해 두 방식의 장점을 함께 취한다.

2. 필요한 경우 한 가지 방식으로 EAI 구현이 가능하다는 것은 Hybrid의 옳은 설명이다. 연계 대상의 규모와 성격에 따라 허브 방식만, 혹은 버스 방식만 적용하는 유연한 구성이 가능하다.

3. 데이터 병목 현상을 최소화할 수 있다는 것은 Hybrid의 옳은 설명이다. 모든 트래픽이 단일 허브에 집중되는 Hub & Spoke의 약점을 버스 구간으로 분산시켜 완화한다.

4. 중간에 미들웨어를 두지 않고 각 애플리케이션을 point to point로 연결한다는 것은 Point-to-Point 유형의 설명이므로 Hybrid에 대한 서술로는 틀렸다. Point-to-Point는 가장 단순하고 저렴하지만 연결 수가 급증하면 관리와 변경이 어려워지는 구조이다.

정리

EAI 구축 유형 — Point-to-Point(미들웨어 없이 1대1 직접 연결), Hub & Spoke(중앙 허브 집중, 확장 쉬우나 허브 장애에 취약), Message Bus/ESB(버스 경유, 대용량 처리), Hybrid(그룹 내 허브+그룹 간 버스, 병목 최소화).

#소프트웨어개발

Q11

자료 구조에 대한 설명으로 틀린 것은?

1큐는 비선형 구조에 해당한다.

2큐는 First In – First Out 처리를 수행한다.

3스택은 Last In – First Out 처리를 수행한다.

4스택은 서브루틴 호출인터럽트, 처리수식, 계산 및 수식 표기 법에 응용된다.

정답 1번 · 큐는 비선형 구조에 해당한다.

핵심 해설

자료 구조는 원소들이 일렬로 나열되는 선형 구조와 계층·망 형태로 연결되는 비선형 구조로 나뉜다. 선형 구조에는 배열, 연결 리스트, 스택, 큐, 데크가 속하고, 비선형 구조에는 트리와 그래프가 속한다. 큐는 뒤쪽 rear에서 삽입(enqueue)하고 앞쪽 front에서 삭제(dequeue)하는 FIFO 방식의 선형 구조로, 원소가 한 줄로 늘어서 있으며 계층 관계를 갖지 않는다. 따라서 큐를 비선형 구조라고 한 1번이 틀린 설명이다.

보기별 해설

1. 큐는 비선형 구조에 해당한다는 것은 틀린 설명이다. 큐는 원소가 일렬로 나열되는 선형 구조이며, 비선형 구조에 속하는 것은 계층 관계를 갖는 트리와 망 형태로 연결되는 그래프이다.

2. 큐는 First In – First Out 처리를 수행한다는 옳은 설명이다. 먼저 들어온 데이터가 먼저 나가므로 운영체제의 작업 스케줄링, 입출력 버퍼, 프린터 대기열에 사용된다.

3. 스택은 Last In – First Out 처리를 수행한다는 옳은 설명이다. 삽입(push)과 삭제(pop)가 top이라는 한쪽 끝에서만 일어나 가장 나중에 넣은 값이 가장 먼저 나온다.

4. 스택은 서브루틴 호출과 인터럽트 처리, 수식 계산 및 수식 표기법 변환에 응용된다는 옳은 설명이다. 복귀 주소를 저장했다가 역순으로 되돌아가야 하는 상황과 후위 표기식 평가에 LIFO 특성이 그대로 쓰인다.

정리

선형 구조 = 배열, 연결 리스트, 스택(LIFO), 큐(FIFO), 데크 / 비선형 구조 = 트리, 그래프. 큐는 선형이며 rear 삽입·front 삭제로 동작한다.

#소프트웨어개발

Q12

그래프의 특수한 형태로 노드(Node)와 선분(Branch)으로 되어 있고, 정점 사이에 사이클(Cycle)이 형성되어 있지 않으며자료, 사이의 관계성이 계층 형식으로 나타나는 비선형 구조는?

1tree

2network

3stack

4distributed

정답 1번 · tree

핵심 해설

문제의 설명은 노드(Node)와 선분(Branch)으로 구성되고, 사이클이 없으며, 자료 사이의 관계가 부모-자식의 계층 형식으로 나타나는 비선형 구조를 가리킨다. 이 조건을 모두 만족하는 자료 구조가 트리(Tree)이며, 트리는 사이클이 없는 연결 그래프라는 점에서 그래프의 특수한 형태로 정의된다. 하나의 루트(Root)에서 출발해 각 노드가 여러 자식을 가질 수 있고, 노드가 n개면 간선은 항상 n-1개이다. 따라서 답은 tree이다.

보기별 해설

1. tree(트리)는 사이클이 없고 계층 관계를 갖는 비선형 자료 구조로, 그래프의 특수한 형태이다. 루트에서 시작해 부모-자식 관계로 뻗어 나가며 노드 n개일 때 간선은 n-1개이다.

2. network(네트워크)는 정점들이 자유롭게 연결되어 사이클을 가질 수 있는 망 형태의 그래프 구조이다. 계층 관계가 없고 순환 경로가 허용되므로 사이클이 없다는 조건에 맞지 않는다.

3. stack(스택)은 push와 pop이 top 한쪽 끝에서만 일어나는 LIFO 선형 자료 구조이다. 노드와 선분으로 계층을 이루는 비선형 구조가 아니다.

4. distributed(분산)는 데이터나 처리를 여러 노드에 나누어 배치하는 시스템 구성 방식을 가리키는 용어이며, 자료 구조의 명칭이 아니다. 분산 데이터베이스·분산 처리처럼 시스템 아키텍처를 설명할 때 쓰인다.

정리

트리 = 사이클 없는 계층형 비선형 구조(그래프의 특수 형태), 노드 n개면 간선 n-1개 / 그래프·네트워크 = 사이클 허용 / 스택·큐 = 선형 구조.

#소프트웨어개발

Q13

테스트와 디버그의 목적으로 옳은 것은?

1테스트는 오류를 수정하는 작업이고 디버깅은 오류를 찾는 작 업이다.

2둘 다 소프트웨어 오류의 발견수정과, 무관하다.

3테스트는 오류를 찾는 작업이고 디버깅은 오류를 수정하는 작 업이다.

4둘 다 소프트웨어의 오류를 찾는 작업으로 오류 수정은 하지 않는다.

정답 3번 · 테스트는 오류를 찾는 작업이고 디버깅은 오류를 수정하는 작 업이다.

핵심 해설

테스트(Test)와 디버깅(Debugging)은 목적이 명확히 구분된다. 테스트는 프로그램에 결함이 존재하는지 확인하기 위해 계획된 입력을 넣고 기대 결과와 실제 결과를 비교하는 활동으로, 오류의 '존재를 드러내는' 것이 목적이다. 디버깅은 테스트로 드러난 오류의 원인이 되는 코드 위치를 찾아 실제로 수정하는 활동이다. 즉 테스트가 결함을 발견하고 디버깅이 그 결함을 제거하므로, 옳은 설명은 3번이다.

보기별 해설

1. 테스트가 오류를 수정하는 작업이고 디버깅이 오류를 찾는 작업이라는 서술은 두 활동의 역할이 서로 뒤바뀐 틀린 설명이다. 찾는 쪽이 테스트, 고치는 쪽이 디버깅이다.

2. 둘 다 소프트웨어 오류의 발견·수정과 무관하다는 서술은 두 활동의 정의 자체를 부정하므로 틀렸다. 테스트와 디버깅은 소프트웨어 품질 확보를 위해 결함을 다루는 대표적인 활동이다.

3. 테스트는 오류를 찾는 작업이고 디버깅은 오류를 수정하는 작업이라는 것이 두 활동의 정확한 구분이다. 테스트는 결함의 존재를 드러내고, 디버깅은 그 원인 코드를 추적해 제거한다.

4. 둘 다 오류를 찾는 작업이고 수정은 하지 않는다는 서술은 디버깅의 정의에 어긋나 틀렸다. 디버깅은 원인 위치를 특정한 뒤 코드를 실제로 고치고 재검증하는 단계까지 포함한다.

정리

테스트 = 결함의 존재를 드러내는 활동(발견) / 디버깅 = 드러난 결함의 원인 코드를 찾아 고치는 활동(수정). 테스트는 결함이 없음을 증명하지는 못한다.

#소프트웨어개발#테스트

Q14

인터페이스 구현 검증 도구가 아닌 것은?

1Foxbase

2STAF

3watir

4xUnit

정답 1번 · Foxbase

핵심 해설

인터페이스 구현 검증 도구는 모듈 간 인터페이스가 명세대로 동작하는지 자동으로 시험하는 테스트 자동화 도구이며, 대표적으로 xUnit, STAF, FitNesse, NTAF, Selenium, watir가 있다. xUnit은 다양한 언어를 지원하는 단위 테스트 프레임워크, STAF는 분산 환경에서 서비스 호출과 컴포넌트 재사용을 지원하는 테스트 프레임워크, watir은 Ruby 기반의 웹 애플리케이션 테스트 도구이다. 반면 Foxbase는 1980~90년대에 쓰이던 dBase 계열의 DBMS 제품으로 테스트와는 무관하다. 따라서 인터페이스 구현 검증 도구가 아닌 것은 Foxbase이다.

보기별 해설

1. Foxbase는 dBase 파일 형식을 사용하던 초기 PC용 관계형 데이터베이스 관리 시스템(DBMS) 제품이다. 이후 FoxPro·Visual FoxPro로 이어졌으며, 인터페이스 동작을 시험하는 테스트 자동화 도구가 아니다.

2. STAF(Software Testing Automation Framework)는 인터페이스 구현 검증 도구이다. 분산 환경에서 테스트에 필요한 서비스를 호출하고 컴포넌트를 재사용하며, 여러 대의 테스트 장비를 원격으로 제어해 자동화한다.

3. watir은 Ruby를 기반으로 웹 브라우저를 제어해 웹 애플리케이션을 테스트하는 인터페이스 구현 검증 도구이다. 브라우저 조작을 스크립트로 기술해 화면 단위의 기능 검증을 자동화한다.

4. xUnit은 Java(JUnit), C++(CppUnit), .NET(NUnit) 등 다양한 언어를 지원하는 단위 테스트 프레임워크 계열로, 인터페이스 구현 검증 도구에 속한다. 테스트 케이스를 코드로 작성해 반복 실행하고 결과를 자동 판정한다.

정리

인터페이스 구현 검증 도구 = xUnit, STAF, FitNesse, NTAF, Selenium, watir. Foxbase는 dBase 계열 DBMS 제품으로 테스트 도구가 아니다.

#소프트웨어개발

Q15

소프트웨어 패키징에 대한 설명으로 틀린 것은?

1패키징은 개발자 중심으로 진행한다.

2신규 및 변경 개발소스를 식별하고이를, 모듈화하여 상용제품 으로 패키징 한다.

3고객의 편의성을 위해 매뉴얼 및 버전관리를 지속적으로 한다.

4범용 환경에서 사용이 가능하도록 일반적인 배포 형태로 패키 징이 진행된다.

정답 1번 · 패키징은 개발자 중심으로 진행한다.

핵심 해설

소프트웨어 패키징은 개발이 완료된 모듈을 사용자가 설치·사용할 수 있는 배포 단위로 묶는 작업이다. 패키징의 가장 중요한 원칙은 개발자가 아니라 사용자 중심으로 진행한다는 것으로, 사용자의 실행 환경을 미리 파악해 그에 맞는 배포본을 만들고 설치·삭제·업데이트가 쉽도록 구성해야 한다. 또한 신규·변경 소스를 식별해 모듈화하고, 범용 환경에서 쓸 수 있는 일반적 배포 형태를 취하며, 매뉴얼과 버전 관리를 지속해야 한다. 따라서 개발자 중심으로 진행한다는 1번이 틀렸다.

보기별 해설

1. 패키징은 개발자 중심으로 진행한다는 것은 틀린 설명이다. 패키징은 사용자 중심으로 진행하며, 사용자의 운영체제·기기·네트워크 환경을 사전에 파악해 설치와 사용이 편리하도록 배포 단위를 구성해야 한다.

2. 신규 및 변경 개발 소스를 식별해 모듈화한 뒤 상용 제품으로 패키징한다는 것은 옳은 설명이다. 빌드된 결과물을 기능 단위로 묶어야 배포와 이후 유지보수가 수월해진다.

3. 고객의 편의성을 위해 매뉴얼 및 버전 관리를 지속적으로 한다는 것은 옳은 설명이다. 릴리스마다 변경 내용을 문서화하고 버전을 부여해야 사용자가 업데이트 여부와 호환성을 판단할 수 있다.

4. 범용 환경에서 사용이 가능하도록 일반적인 배포 형태로 패키징이 진행된다는 것은 옳은 설명이다. 특정 환경에 종속된 형태보다 표준 설치 패키지 형식을 택해야 다양한 사용자 환경을 포괄할 수 있다.

정리

소프트웨어 패키징 원칙 — 개발자가 아닌 사용자 중심, 사용자 실행 환경 사전 파악, 신규·변경 소스 식별 후 모듈화, 범용적 배포 형태, 매뉴얼과 버전의 지속 관리.

#소프트웨어개발

Q16

소프트웨어 품질 목표 중 하나 이상의 하드웨어 환경에서 운용되기 위해 쉽게 수정될 수 있는 시스템 능력을 의미하는 것은?

1Correctness

2Portability

3Efficiency

4Usability

정답 2번 · Portability

핵심 해설

소프트웨어 품질 목표(McCall의 품질 요인)에서 이식성(Portability)은 하나 이상의 하드웨어 환경이나 운영체제에서 운용될 수 있도록 소프트웨어를 쉽게 수정할 수 있는 능력을 뜻한다. 즉 다른 플랫폼으로 옮길 때 드는 수정 노력이 적을수록 이식성이 높다. 다른 품질 목표로는 정확성(요구 기능 충족), 효율성(자원 사용 대비 성능), 사용 용이성, 신뢰성, 무결성, 유지보수성, 시험 역량, 유연성, 재사용성, 상호 운용성이 있다. 문제의 정의에 해당하는 것은 Portability이다.

보기별 해설

1. Correctness(정확성)는 소프트웨어가 사용자의 요구 기능을 얼마나 명세대로 충족하는가를 나타내는 품질 목표이다. 실행 환경 이동과는 무관하게 결과의 옳고 그름을 다룬다.

2. Portability(이식성)는 하나 이상의 하드웨어 환경에서 운용되도록 쉽게 수정될 수 있는 시스템 능력이다. 환경 의존적인 코드를 분리하고 표준을 준수할수록 이식성이 높아진다.

3. Efficiency(효율성)는 최소한의 처리 시간·기억 장치·자원으로 요구 기능을 수행하는 정도를 나타내는 품질 목표이다. 성능에 관한 척도이지 환경 이전 능력이 아니다.

4. Usability(사용 용이성)는 사용자가 소프트웨어를 배우고 조작하는 데 드는 노력이 적은 정도를 나타내는 품질 목표이다. 인터페이스의 편의성에 관한 척도이다.

정리

소프트웨어 품질 목표 — 정확성(요구 기능 충족), 신뢰성(오류 없이 수행), 효율성(자원 대비 성능), 무결성(비인가 접근 통제), 사용 용이성, 유지보수성, 시험 역량, 유연성, 이식성(다른 환경으로 쉽게 이전), 재사용성, 상호 운용성.

#소프트웨어개발

Q17

개별 모듈을 시험하는 것으로모듈이, 정확하게 구현되었는지, 예정한 기능이 제대로 수행되는지를 점검하는 것이 주목적인 테스트 는?

1통합 테스트(Integration Test)

2단위 테스트(Unit Test)

3시스템 테스트(System Test)

4인수 테스트(Acceptance Test)

정답 2번 · 단위 테스트(Unit Test)

핵심 해설

테스트 레벨은 개발 단계에 따라 단위 → 통합 → 시스템 → 인수 순으로 구성된다. 단위 테스트(Unit Test)는 코딩 직후 모듈이나 컴포넌트 하나를 독립적으로 실행해 그것이 명세대로 정확히 구현되었는지, 예정한 기능을 제대로 수행하는지를 점검하는 테스트이다. 인터페이스, 자료 구조, 독립적 경로, 오류 처리 경로, 경계 조건이 주요 확인 대상이며 구조 기반(화이트박스) 테스트가 중심이 된다. 개별 모듈이 대상이라고 명시했으므로 답은 단위 테스트이다.

보기별 해설

1. 통합 테스트(Integration Test)는 단위 테스트를 마친 모듈들을 결합해 모듈 사이의 인터페이스와 상호 작용에 결함이 없는지 검증하는 테스트이다. 하향식·상향식·혼합식 방식이 있으며 스터브와 드라이버를 사용한다.

2. 단위 테스트(Unit Test)는 개별 모듈 하나를 독립적으로 실행해 정확히 구현되었는지, 예정된 기능을 수행하는지 점검하는 테스트이다. 코딩 직후 수행되며 모듈 내부 로직을 보는 화이트박스 기법이 주로 쓰인다.

3. 시스템 테스트(System Test)는 통합이 끝난 소프트웨어를 실제 운영 환경과 유사한 조건에서 전체 단위로 실행해 기능·성능·보안 등 요구사항 충족 여부를 확인하는 테스트이다. 개별 모듈이 아니라 완성된 시스템 전체가 대상이다.

4. 인수 테스트(Acceptance Test)는 사용자의 요구사항이 충족되었는지를 사용자 관점에서 확인해 인수 여부를 결정하는 테스트이다. 알파 테스트와 베타 테스트로 나뉘며 개발 후반부에 수행된다.

정리

테스트 레벨 — 단위(개별 모듈 내부 로직), 통합(모듈 간 인터페이스), 시스템(완성된 시스템 전체 기능·성능), 인수(사용자 요구 충족 확인, 알파·베타).

#소프트웨어개발#테스트

Q18

소프트웨어 테스트에서 검증(Verification)과 확인(Validation)에 대 한 설명으로 틀린 것은?

1소프트웨어 테스트에서 검증과 확인을 구별하면 찾고자 하는 결함 유형을 명확하게 하는 데 도움이 된다.

2검증은 소프트웨어 개발 과정을 테스트하는 것이고확인은, 소프트웨어 결과를 테스트하는 것이다. - 3

3검증은 작업 제품이 요구 명세의 기능비기능, 요구사항을 얼마 나 잘 준수하는지 측정하는 작업이다.

4검증은 작업 제품이 사용자의 요구에 적합한지 측정하며확인, 은 작업 제품이 개발자의 기대를 충족시키는지를 측정한다.

정답 4번 · 검증은 작업 제품이 사용자의 요구에 적합한지 측정하며확인, 은 작업 제품이 개발자의 기대를 충족시키는지를 측정한다.

핵심 해설

검증(Verification)과 확인(Validation)은 관점이 다르다. 검증은 '제품을 올바르게 만들고 있는가'를 보는 개발자 관점으로, 개발 과정의 산출물이 명세된 기능·비기능 요구사항을 제대로 준수하는지 측정한다. 확인은 '올바른 제품을 만들었는가'를 보는 사용자 관점으로, 완성된 결과물이 실제 사용자의 요구와 기대에 적합한지를 측정한다. 4번은 검증을 사용자 요구 적합성, 확인을 개발자 기대 충족으로 서술해 두 관점을 정반대로 바꿔 놓았으므로 틀렸다.

보기별 해설

1. 소프트웨어 테스트에서 검증과 확인을 구별하면 찾고자 하는 결함 유형이 명확해진다는 옳은 설명이다. 명세 준수 결함은 검증에서, 사용자 요구와의 괴리는 확인에서 드러나므로 테스트 설계의 초점이 달라진다.

2. 검증은 개발 과정을 테스트하고 확인은 소프트웨어 결과를 테스트한다는 옳은 설명이다. 검증은 각 단계 산출물의 리뷰·인스펙션으로, 확인은 완성품에 대한 사용자 관점 테스트로 이루어진다.

3. 검증은 작업 제품이 요구 명세의 기능·비기능 요구사항을 얼마나 잘 준수하는지 측정하는 작업이라는 옳은 설명이다. 명세라는 기준이 있고 그것과 대조하는 활동이 검증이다.

4. 검증이 사용자 요구 적합성을 측정하고 확인이 개발자 기대 충족을 측정한다는 서술은 두 개념을 서로 뒤바꿨으므로 틀렸다. 검증이 개발자 관점의 명세 준수 확인이고, 확인이 사용자 관점의 요구 적합성 판단이다.

정리

검증(Verification) = 개발자 관점, 개발 과정과 산출물이 명세를 준수하는가(제품을 올바르게 만들고 있는가) / 확인(Validation) = 사용자 관점, 결과물이 사용자 요구에 적합한가(올바른 제품을 만들었는가).

#소프트웨어개발#테스트#요구사항

Q19

테스트를 목적에 따라 분류했을 때강도, (Stress) 테스트에 대한 설명으로 옳은 것은?

1시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀 하는지 테스트한다.

2시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정 상적으로 작동되는지를 테스트한다.

3사용자의 이벤트에 시스템이 응답하는 시간특정, 시간 내에 처리하는 업무량사용자, 요구에 시스템이 반응하는 속도 등을 테스트한다.

4부당하고 불법적인 침입을 시도하여 보안시스템이 불법적인 침투를 잘 막아내는지 테스트한다.

정답 2번 · 시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정 상적으로 작동되는지를 테스트한다.

핵심 해설

목적에 따른 테스트 분류에서 강도(Stress) 테스트는 시스템에 정상 범위를 크게 넘는 정보량이나 부하를 일부러 걸어, 과부하 상황에서도 시스템이 정상적으로 작동하는지와 어느 지점에서 무너지는지를 확인하는 테스트이다. 이는 시스템의 한계 용량을 파악해 용량 산정과 장애 대비의 근거로 삼기 위한 것이다. 나머지 보기는 회복 테스트, 성능 테스트, 보안 테스트의 설명이므로 강도 테스트에 해당하는 것은 2번이다.

보기별 해설

1. 시스템에 고의로 실패를 유도하고 정상 복귀 여부를 확인한다는 것은 회복(Recovery) 테스트의 설명이다. 장애 발생 후 복구 시간과 데이터 무결성 회복 능력을 검증한다.

2. 시스템에 과다 정보량을 부과하여 과부하 시에도 정상 작동하는지 확인하는 것이 강도(Stress) 테스트이다. 시스템이 견딜 수 있는 한계 부하와 그 지점의 동작을 파악하는 것이 목적이다.

3. 사용자의 이벤트에 시스템이 응답하는 시간, 단위 시간당 처리량(Throughput), 반응 속도를 측정한다는 것은 성능(Performance) 테스트의 설명이다. 정상 부하 조건에서의 속도 지표를 다룬다는 점에서 한계 부하를 가하는 강도 테스트와 구분된다.

4. 부당하고 불법적인 침입을 시도하여 방어 능력을 확인한다는 것은 보안(Security) 테스트의 설명이다. 인증·권한 통제와 취약점 방어 수준을 점검한다.

정리

목적별 테스트 — 강도(과부하 한계 확인), 성능(응답 시간·처리량), 회복(장애 후 복구), 보안(불법 침입 방어), 구조(내부 논리 경로), 회귀(수정 후 부작용), 병행(신·구 시스템 동시 실행 비교).

#소프트웨어개발#보안#테스트

Q20

프로그램 설계도의 하나인 NS Chart에 대한 설명으로 가장 거리가 먼 것은?

1논리의 기술에 중점을 두고 도형을 이용한 표현 방법이다.

2이해하기 쉽고 코드 변환이 용이하다.

3화살표나 GOTO를 사용하여 이해하기 쉽다.

4연속선택반복, , 등의 제어 논리 구조를 표현한다.

정답 3번 · 화살표나 GOTO를 사용하여 이해하기 쉽다.

핵심 해설

NS Chart(Nassi-Schneiderman Chart)는 논리 기술에 중점을 두고 도형으로 프로그램 논리를 표현하는 설계 도구로, 박스 다이어그램 또는 구조적 순서도라고도 한다. 연속·선택·다중 선택·반복이라는 구조적 프로그래밍의 제어 구조를 상자 모양으로만 표현하며, 상자 안에 논리가 계층적으로 중첩되므로 이해하기 쉽고 코드 변환이 용이하다. 가장 큰 특징은 화살표나 GOTO를 사용하지 않는다는 점으로, 이 때문에 임의의 분기가 원천적으로 불가능하고 구조적 프로그래밍이 강제된다. 따라서 화살표나 GOTO를 사용한다고 서술한 3번이 가장 거리가 멀다.

보기별 해설

1. 논리의 기술에 중점을 두고 도형을 이용한 표현 방법이라는 것은 NS Chart의 옳은 설명이다. 순차·선택·반복 논리를 직사각형 상자의 분할로 나타내는 도식 설계 도구이다.

2. 이해하기 쉽고 코드 변환이 용이하다는 것은 NS Chart의 옳은 설명이다. 상자의 중첩 구조가 프로그램의 블록 구조와 그대로 대응해 소스 코드로 옮기기 쉽다.

3. 화살표나 GOTO를 사용한다는 것은 NS Chart의 특징과 정반대이므로 틀렸다. NS Chart는 화살표와 GOTO를 배제해 임의의 분기를 막고 구조적 프로그래밍만 표현하도록 설계된 도구이며, 화살표로 흐름을 잇는 것은 순서도(Flow Chart)의 방식이다.

4. 연속·선택·반복 등의 제어 논리 구조를 표현한다는 것은 NS Chart의 옳은 설명이다. 구조적 프로그래밍의 세 가지 기본 제어 구조가 NS Chart가 나타내는 대상이다.

정리

NS Chart(박스 다이어그램) — 도형(상자)으로 연속·선택·반복 논리를 표현, 화살표·GOTO 사용 불가(임의 분기 불가능), 전체 논리 파악과 코드 변환이 쉬움. 화살표로 흐름을 잇는 것은 순서도이다.

#소프트웨어개발