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

2025년 2회

EAI(Enterprise Application Integration)의 구축 유형으로 옳지 않은 것은?

1Point-to-Point

2Hub & Spoke

3Message Bus

4Tree - 2

정답 4번 · Tree - 2

핵심 해설

EAI(Enterprise Application Integration)는 기업 내 서로 다른 플랫폼과 애플리케이션을 연계해 데이터와 프로세스를 통합하는 솔루션이다. 구축 유형은 연결 구조에 따라 Point-to-Point, Hub & Spoke, Message Bus(ESB), Hybrid 네 가지로 분류된다. Point-to-Point는 1:1 직접 연결, Hub & Spoke는 중앙 허브 집중형, Message Bus는 미들웨어 버스 경유형, Hybrid는 그룹 내부는 Hub & Spoke·그룹 간은 Message Bus를 쓰는 혼합형이다. Tree라는 명칭의 EAI 구축 유형은 존재하지 않으므로 옳지 않다.

보기별 해설

1. Point-to-Point는 EAI 구축 유형 중 가장 단순한 형태로, 애플리케이션끼리 미들웨어 없이 1:1로 직접 연결한다. 구축 비용은 낮지만 연결 수가 n(n-1)/2로 늘어나 확장성과 유지보수성이 떨어진다.

2. Hub & Spoke는 중앙 허브 시스템을 두고 모든 애플리케이션을 허브에 연결하는 EAI 유형이다. 데이터 전송이 한곳으로 모여 관리와 확장이 쉽지만, 허브 장애 시 전체 연계가 중단되는 단일 장애점 문제가 있다.

3. Message Bus는 애플리케이션 사이에 메시지 버스(ESB)를 두어 통신을 중계하는 EAI 유형이다. 미들웨어가 라우팅과 변환을 담당해 대용량 처리와 확장성이 뛰어나며 느슨한 결합을 제공한다.

4. Tree는 EAI 구축 유형 분류에 존재하지 않는 명칭이다. 트리는 계층적 자료구조를 가리키는 용어이며, EAI 유형은 Point-to-Point, Hub & Spoke, Message Bus, Hybrid 네 가지뿐이다.

정리

EAI 구축 유형 4가지 — Point-to-Point(1:1 직접), Hub & Spoke(중앙 허브), Message Bus/ESB(버스 중계), Hybrid(그룹 내 허브 + 그룹 간 버스).

#소프트웨어개발

소프트웨어 형상 관리의 의미로 적절한 것은?

1비용에 관한 사항을 효율적으로 관리하는 것

2개발 과정의 변경 사항을 관리하는 것

3테스트 과정에서 소프트웨어를 통합하는 것

4개발 인력을 관리하는 것

정답 2번 · 개발 과정의 변경 사항을 관리하는 것

핵심 해설

소프트웨어 형상 관리(SCM, Software Configuration Management)는 개발 과정에서 산출되는 소스 코드, 문서, 설계서 등 형상 항목의 변경 사항을 식별·통제·기록하고 그 무결성을 유지하는 활동이다. 주요 절차는 형상 식별, 형상 통제(변경 요청 검토 및 승인), 형상 상태 보고, 형상 감사로 구성된다. 형상 관리의 대상은 사람이나 비용이 아니라 '산출물의 변경'이므로, 개발 과정의 변경 사항을 관리하는 것이 형상 관리의 정확한 의미이다.

보기별 해설

1. 비용에 관한 사항을 효율적으로 관리하는 것은 원가 관리 또는 프로젝트 비용 관리 영역이다. COCOMO 같은 비용 산정 모형이 다루는 대상이며 형상 관리의 정의가 아니다.

2. 개발 과정의 변경 사항을 관리하는 것이 형상 관리의 정의이다. 형상 식별·통제·상태 보고·감사를 통해 언제 누가 무엇을 왜 바꾸었는지 추적하고 이전 버전으로 복원할 수 있게 한다.

3. 테스트 과정에서 소프트웨어를 통합하는 것은 통합 테스트(하향식·상향식) 활동이다. 모듈 간 인터페이스 오류를 찾는 것이 목적이며 변경 이력 통제와는 다른 활동이다.

4. 개발 인력을 관리하는 것은 인적 자원 관리에 해당한다. 팀 구성과 역할 배분을 다루는 프로젝트 관리 영역이며 형상 항목의 변경 통제와 무관하다.

정리

형상 관리 = 산출물 변경의 식별·통제·기록. 절차는 형상 식별 → 형상 통제(변경 승인) → 형상 상태 보고 → 형상 감사.

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

소프트웨어 품질 측정을 위해 개발자 관점에서 고려해야 할 항목으로 거리가 먼 것은?

1정확성

2무결성

3사용성

4간결성

정답 4번 · 간결성

핵심 해설

소프트웨어 품질 목표(McCall 품질 요인 등)는 관점에 따라 나뉘는데, 사용자 관점 항목은 정확성·신뢰성·효율성·무결성·사용성처럼 실행되는 제품의 품질을 보는 것이고, 개발자 관점 항목은 이식성·재사용성·상호운용성·유지보수성·시험 용이성처럼 코드를 다루는 사람이 보는 품질이다. 문제는 개발자 관점에서 '고려해야 할 항목'을 묻고 있는데, 정확성·무결성·사용성은 모두 McCall이 정의한 표준 품질 요인에 포함된다. 반면 간결성은 코드 작성 스타일에 관한 권고일 뿐 소프트웨어 품질 측정 항목으로 정의된 요인이 아니므로 거리가 멀다.

보기별 해설

1. 정확성(Correctness)은 소프트웨어가 사용자의 요구 기능을 명세대로 충족하는 정도를 나타내는 품질 요인이다. 요구사항 대비 결과의 정합성을 측정하며 표준 품질 항목에 포함된다.

2. 무결성(Integrity)은 허가되지 않은 접근이나 변경으로부터 소프트웨어와 데이터를 보호하는 정도를 뜻하는 품질 요인이다. 보안 통제 수준을 측정하는 항목으로 품질 목표에 포함된다.

3. 사용성(Usability)은 사용자가 소프트웨어를 배우고 조작하는 데 드는 노력의 정도를 나타내는 품질 요인이다. 학습 용이성과 조작 편의성을 측정하며 품질 목표 항목이다.

4. 간결성은 코드를 짧고 단순하게 쓰라는 클린 코드 작성 원칙에 가까운 표현으로, McCall 등의 소프트웨어 품질 요인 목록에 정의된 측정 항목이 아니다. 따라서 품질 측정 항목으로는 거리가 멀다.

정리

McCall 품질 요인 — 제품 운영: 정확성·신뢰성·효율성·무결성·사용성 / 제품 개정: 유지보수성·유연성·시험 용이성 / 제품 전이: 이식성·재사용성·상호운용성. '간결성'은 품질 요인이 아니다.

#소프트웨어개발

알파베타, 테스트와 가장 밀접한 연관이 있는 테스트 단계는?

1단위 테스트

2인수 테스트

3통합 테스트

4시스템 테스트

정답 2번 · 인수 테스트

핵심 해설

인수 테스트(Acceptance Test)는 개발이 끝난 소프트웨어가 사용자의 요구사항을 충족하는지 사용자가 직접 확인하는 최종 단계 테스트이다. 인수 테스트는 알파 테스트와 베타 테스트로 나뉘는데, 알파 테스트는 개발자 사이트에서 개발자가 지켜보는 통제된 환경에서 선정된 사용자가 수행하고, 베타 테스트는 실제 사용자 환경에서 개발자 없이 다수 사용자가 사용하며 문제를 보고한다. 따라서 알파·베타 테스트와 직접 연결되는 단계는 인수 테스트이다.

보기별 해설

1. 단위 테스트(Unit Test)는 모듈이나 함수 같은 최소 단위를 개별적으로 검증하는 테스트이다. 개발자가 화이트박스 기법으로 수행하며 스텁·드라이버가 필요할 수 있고, 사용자가 참여하는 알파·베타와 무관하다.

2. 인수 테스트(Acceptance Test)는 사용자 요구사항 충족 여부를 사용자가 확인하는 최종 테스트로, 개발자 사이트에서 하는 알파 테스트와 사용자 현장에서 하는 베타 테스트로 구분된다.

3. 통합 테스트(Integration Test)는 단위 테스트를 마친 모듈들을 결합해 모듈 간 인터페이스 오류를 찾는 테스트이다. 하향식·상향식·빅뱅 방식이 있으며 개발 조직 내부에서 수행한다.

4. 시스템 테스트(System Test)는 통합된 전체 시스템을 실제 운영 환경과 유사한 조건에서 기능·성능·보안 등 요구사항 전반에 대해 검증하는 테스트이다. 인수 이전 단계로 개발 조직이 수행한다.

정리

테스트 단계 순서 — 단위 → 통합 → 시스템 → 인수. 인수 테스트의 하위 유형이 알파(개발자 사이트, 통제 환경)와 베타(사용자 현장, 실사용).

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

제품 소프트웨어 패키징 도구 활용 시 고려사항이 아닌 것은?

1제품 소프트웨어의 종류에 적합한 암호화 알고리즘을 고려한 다.

2추가로 다양한 이기종 연동을 고려한다.

3사용자 편의성을 위한 복잡성 및 비효율성 문제를 고려한다.

4내부 콘텐츠에 대한 보안은 고려하지 않는다.

정답 4번 · 내부 콘텐츠에 대한 보안은 고려하지 않는다.

핵심 해설

제품 소프트웨어 패키징은 개발이 완료된 소프트웨어를 사용자가 설치·사용할 수 있는 형태로 묶는 작업으로, 사용자 중심으로 진행하는 것이 원칙이다. 패키징 도구 활용 시 고려사항은 암호화·보안 알고리즘 적용, 다양한 이기종 콘텐츠 및 단말 간 연동 고려, 사용자 편의성을 위한 복잡성·비효율성 최소화, 그리고 내부 콘텐츠에 대한 보안 고려이다. 패키징된 결과물은 외부로 배포되므로 내부 콘텐츠의 보안은 오히려 반드시 고려해야 할 핵심 사항이며, 이를 고려하지 않는다는 서술은 옳지 않다.

보기별 해설

1. 제품 소프트웨어의 종류에 적합한 암호화 알고리즘 고려는 패키징 도구 활용의 기본 사항이다. 콘텐츠 유형과 성능 요구에 맞는 알고리즘을 선택해 DRM 등 보호 기능을 적용한다.

2. 추가로 다양한 이기종 연동을 고려한다는 것은 패키징 시 반드시 반영해야 할 사항이다. 서로 다른 OS·단말·콘텐츠 형식에서도 설치와 실행이 가능하도록 호환성을 확보해야 한다.

3. 사용자 편의성을 위한 복잡성·비효율성 문제 고려도 패키징 도구 활용 시 필수 사항이다. 보안 적용으로 설치와 사용 절차가 과도하게 복잡해지지 않도록 균형을 맞춰야 한다.

4. 내부 콘텐츠에 대한 보안을 고려하지 않는다는 서술은 패키징 원칙에 어긋난다. 배포되는 패키지 안의 콘텐츠는 불법 복제와 변조에 노출되므로 암호화와 보안 인증을 함께 적용해야 한다.

정리

패키징 도구 고려사항 — 암호화/보안 알고리즘, 이기종 연동, 사용자 편의성(복잡성·비효율성 최소화), 내부 콘텐츠 보안. 원칙은 '개발자'가 아닌 '사용자' 중심이다.

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

다음 트리를 Preorder 운행법으로 운행할 경우 가장 먼저 탐색되는 것은?

정답 1번 · A

핵심 해설

Preorder(전위) 운행법은 루트(Root) → 왼쪽 서브트리(Left) → 오른쪽 서브트리(Right) 순으로 방문하고 이를 각 서브트리에 재귀적으로 적용한다. 정의상 첫 번째 방문 노드는 항상 트리의 최상위 루트이므로, 트리 그림이 없어도 보기 중 루트에 해당하는 노드를 고르면 된다. 관례적으로 노드에 A부터 레벨 순서로 이름을 붙인 트리에서 루트는 A이며, 실제로 정답도 A이다. 참고로 Inorder는 Left→Root→Right, Postorder는 Left→Right→Root로, Postorder에서는 루트가 가장 마지막에 방문된다.

보기별 해설

1. A는 트리의 루트 노드이므로 Root→Left→Right 순인 전위 운행에서 가장 먼저 방문된다. 어떤 이진 트리든 Preorder 결과의 첫 노드는 루트이다.

2. B는 루트 A의 왼쪽 자식으로, 전위 운행에서는 A 다음인 두 번째로 방문된다. 왼쪽 서브트리의 루트일 뿐 트리 전체의 루트는 아니다.

3. D는 루트에서 두 단계 아래 레벨에 있는 노드로, 자신의 조상인 A와 B가 먼저 방문된 뒤에 탐색된다. Inorder에서는 왼쪽 최하단 노드가 먼저 나올 수 있지만 Preorder의 첫 노드는 될 수 없다.

4. G는 트리 하단부에 위치한 노드로, 전위 운행에서는 모든 조상 노드가 방문된 이후에야 탐색된다. Postorder에서 마지막 근처에 나오는 유형의 노드이며 첫 방문 노드가 아니다.

정리

운행법 3종 — Preorder: Root→Left→Right(첫 방문이 루트), Inorder: Left→Root→Right, Postorder: Left→Right→Root(마지막 방문이 루트).

#소프트웨어개발

인터페이스 보안을 위해 네트워크 영역에 적용될 수 있는 솔루션과 거리가 먼 것은?

1IPSec

2SSL

3SMTP

4S-HTTP

정답 3번 · SMTP

핵심 해설

인터페이스 보안은 적용 영역을 네트워크 영역, 애플리케이션 영역, 데이터베이스 영역으로 나눈다. 네트워크 영역에서는 송수신 구간의 스니핑과 데이터 변조를 막기 위해 IPSec, SSL/TLS, S-HTTP 같은 암호화·인증 프로토콜을 적용한다. SMTP는 메일 서버 간 전자우편을 전달하는 응용 계층 전송 프로토콜로, 자체에 암호화나 인증 기능이 없어 기본적으로 평문으로 통신한다. 따라서 네트워크 영역 보안 솔루션과 거리가 먼 것은 SMTP이다.

보기별 해설

1. IPSec은 IP 계층에서 패킷 단위로 인증(AH)과 암호화(ESP)를 제공하는 보안 프로토콜이다. 전송 모드와 터널 모드를 지원하며 VPN 구축의 기반 기술이다.

2. SSL(Secure Socket Layer)은 전송 계층에서 서버·클라이언트 인증과 데이터 암호화를 수행하는 보안 프로토콜이다. HTTP와 결합해 HTTPS를 구성하며 현재는 TLS로 표준화되었다.

3. SMTP(Simple Mail Transfer Protocol)는 메일 서버 사이에서 전자우편을 송신하는 응용 계층 프로토콜이다. 메일 전달이 목적이고 암호화·인증 기능이 내장되어 있지 않아 전송 구간 보호 솔루션이 아니다.

4. S-HTTP(Secure HTTP)는 HTTP 메시지 본문 단위로 암호화와 전자서명을 적용하는 보안 프로토콜이다. 채널 전체를 감싸는 SSL과 달리 개별 요청·응답 단위로 보호한다.

정리

인터페이스 네트워크 영역 보안 = IPSec(IP 계층) / SSL·TLS(전송 계층) / S-HTTP(응용 메시지 단위). SMTP·FTP·Telnet은 평문 전송 프로토콜이라 보안 솔루션이 아니다.

#소프트웨어개발#네트워크#보안

저작권 관리 구성 요소에 대한 설명이 틀린 것은?

1콘텐츠 제공자(Contents Provider) : 콘텐츠를 제공하는 저작 권자

2콘텐츠 분배자(Contents Distributor) : 콘텐츠를 메타 데이터 와 함께 배포 가능한 단위로 묶는 기능

3클리어링 하우스(Clearing House) : 키 관리 및 라이선스 발급 관리

4DRM 컨트롤러 : 배포된 콘텐츠의 이용 권한을 통제

정답 2번 · 콘텐츠 분배자(Contents Distributor) : 콘텐츠를 메타 데이터 와 함께 배포 가능한 단위로 묶는 기능

핵심 해설

디지털 저작권 관리(DRM)의 구성 요소는 콘텐츠 제공자(Contents Provider), 콘텐츠 분배자(Contents Distributor), 패키저(Packager), 클리어링 하우스(Clearing House), 콘텐츠 소비자(Consumer), DRM 컨트롤러, 보안 컨테이너로 구분된다. 이 중 콘텐츠를 메타 데이터와 함께 배포 가능한 단위로 묶어 암호화하는 역할은 패키저(Packager)의 기능이며, 콘텐츠 분배자는 쇼핑몰이나 서비스 포털처럼 패키징된 콘텐츠를 소비자에게 유통·중개하는 주체이다. 따라서 콘텐츠 분배자의 설명으로 패키저의 기능을 적어놓은 2번이 틀렸다.

보기별 해설

2. 콘텐츠 분배자(Contents Distributor)는 패키징된 콘텐츠를 소비자에게 유통·중개하는 쇼핑몰이나 서비스 포털을 가리킨다. 콘텐츠를 메타 데이터와 함께 배포 단위로 묶는 것은 패키저(Packager)의 기능이므로 설명이 서로 뒤바뀐 것이다.

3. 클리어링 하우스(Clearing House)는 저작권 관련 이용 권한을 중개·정산하는 기관으로, 라이선스 발급과 암호화 키 관리, 사용량에 따른 대금 정산을 담당한다는 설명이 맞다.

4. DRM 컨트롤러(DRM Controller)는 소비자 단말에서 배포된 콘텐츠의 이용 권한을 통제하는 프로그램으로 설명이 맞다. 라이선스에 명시된 재생 횟수·기간 등의 규칙을 강제한다.

정리

#소프트웨어개발

소프트웨어 설치 매뉴얼에 대한 설명으로 틀린 것은?

1설치 과정에서 표시될 수 있는 예외상황에 관련 내용을 별도로 구분하여 설명한다.

2설치 시작부터 완료할 때까지의 전 과정을 빠짐없이 순서대로 설명한다.

3설치 매뉴얼은 개발자 기준으로 작성한다.

4설치 매뉴얼에는 목차개요기본사항, , 등이 기본적으로 포함되 어야 한다.

정답 3번 · 설치 매뉴얼은 개발자 기준으로 작성한다.

핵심 해설

소프트웨어 설치 매뉴얼은 사용자가 제품을 직접 설치할 수 있도록 돕는 문서이므로 개발자가 아니라 '사용자 기준'으로 작성하는 것이 기본 원칙이다. 설치 시작부터 완료까지 모든 과정을 순서대로 빠짐없이 기술하고, 화면 캡처와 참고 사항·주의 사항을 함께 제공한다. 또한 설치 중 발생할 수 있는 오류 메시지와 예외 상황은 본문과 구분해 별도로 정리한다. 기본 구성은 목차 및 개요, 서문(문서 이력·설치 도구 구성·설치 환경), 기본 사항, 설치 절차, 설치 완료 및 참고 사항, FAQ, 오류 발생 시 조치 순이다.

보기별 해설

1. 설치 과정의 예외 상황을 별도로 구분해 설명하는 것은 옳은 지침이다. 오류 메시지와 조치 방법을 본문 절차와 분리해 정리하면 사용자가 문제 발생 시 빠르게 찾을 수 있다.

2. 설치 시작부터 완료까지 전 과정을 순서대로 빠짐없이 설명하는 것도 옳은 지침이다. 각 단계마다 실제 화면과 안내 문구를 함께 제시해 사용자가 따라 할 수 있게 한다.

3. 설치 매뉴얼을 개발자 기준으로 작성한다는 서술이 틀렸다. 설치 매뉴얼은 제품을 처음 접하는 사용자가 읽는 문서이므로 사용자 기준으로, 전문 용어를 최소화해 작성해야 한다.

4. 설치 매뉴얼에 목차·개요·기본 사항 등이 포함되어야 한다는 서술은 옳다. 설치 매뉴얼의 표준 구성은 목차 및 개요, 서문, 기본 사항, 설치 절차, 참고 사항, FAQ, 오류 조치 항목으로 이루어진다.

정리

설치·사용자 매뉴얼은 모두 '사용자 기준'으로 작성한다. 구성 = 목차/개요 → 서문(이력·설치 환경) → 기본 사항 → 설치 절차 → 참고 사항/FAQ → 오류 조치.

#소프트웨어개발

Q10

다음 중 블랙박스 검사 기법은?

1경계값 분석

2조건 검사

3기초 경로 검사

4루프 검사 2

정답 1번 · 경계값 분석

핵심 해설

블랙박스 테스트는 프로그램의 내부 구조를 보지 않고 요구사항 명세를 근거로 입력과 출력의 관계만 검증하는 기법으로, 동치 분할 검사, 경계값 분석, 원인-효과 그래프, 오류 예측, 비교 검사가 여기에 속한다. 반면 화이트박스 테스트는 소스 코드의 논리 구조와 제어 흐름을 직접 보고 검증하는 기법으로, 기초 경로 검사, 조건 검사, 루프 검사, 데이터 흐름 검사가 대표적이다. 보기 중 명세 기반으로 입력 경계 부근의 값을 골라 테스트 케이스를 만드는 경계값 분석만이 블랙박스 기법이다.

보기별 해설

1. 경계값 분석(Boundary Value Analysis)은 블랙박스 기법이다. 입력 조건의 경계 부분에서 오류가 자주 발생한다는 점에 착안해 경계값과 그 직전·직후 값을 테스트 케이스로 선정한다.

2. 조건 검사(Condition Testing)는 화이트박스 기법이다. 프로그램 내 논리 조건식의 각 참·거짓 조합이 모두 수행되도록 테스트 케이스를 설계하며 소스 코드를 봐야 적용할 수 있다.

3. 기초 경로 검사(Base Path Testing)는 화이트박스 기법의 대표 격이다. 제어 흐름 그래프에서 순환 복잡도를 계산해 독립적인 실행 경로 수만큼 테스트 케이스를 만든다.

4. 루프 검사(Loop Testing)는 화이트박스 기법이다. 단순 루프·중첩 루프·연결 루프 등 반복 구조를 대상으로 0회, 1회, 최대 반복 등 경계 반복 횟수에서의 동작을 검증한다.

정리

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

#소프트웨어개발

Q11

스택에 대한 설명으로 틀린 것은?

1입출력이 한쪽 끝으로만 제한된 리스트이다.

2Head(front)와 Tail(rear)의 2개 포인터를 갖고 있다.

3LIFO 구조이다.

4더 이상 삭제할 데이터가 없는 상태에서 데이터를 삭제하면 언더플로(Underflow)가 발생한다.

정답 2번 · Head(front)와 Tail(rear)의 2개 포인터를 갖고 있다.

핵심 해설

스택(Stack)은 삽입(push)과 삭제(pop)가 리스트의 한쪽 끝인 top에서만 일어나는 선형 자료구조로, 나중에 들어온 것이 먼저 나오는 LIFO(Last In First Out) 방식이다. 따라서 위치를 가리키는 포인터는 top 하나만 필요하다. front와 rear 두 개의 포인터를 사용해 한쪽에서 삽입하고 반대쪽에서 삭제하는 것은 FIFO 구조인 큐(Queue)의 특징이다. 스택이 가득 찬 상태에서 push하면 오버플로, 비어 있는 상태에서 pop하면 언더플로가 발생한다.

보기별 해설

1. 입출력이 한쪽 끝으로만 제한된 리스트라는 서술은 스택의 정의 그대로이다. top이라는 하나의 위치에서만 push와 pop이 이루어진다.

2. Head(front)와 Tail(rear) 2개 포인터를 갖는 구조는 스택이 아니라 큐(Queue)이다. 큐는 rear에서 삽입하고 front에서 삭제하는 FIFO 구조이며, 스택은 top 포인터 하나만 사용한다.

3. LIFO(Last In First Out) 구조라는 서술은 스택의 핵심 특징이 맞다. 가장 마지막에 삽입된 데이터가 가장 먼저 삭제되며 함수 호출 스택, 되돌리기 기능 등에 쓰인다.

4. 더 이상 삭제할 데이터가 없는 상태에서 삭제하면 언더플로(Underflow)가 발생한다는 서술도 맞다. 반대로 스택이 가득 찬 상태에서 push하면 오버플로(Overflow)가 발생한다.

정리

스택 = top 포인터 1개, LIFO, 빈 상태 pop은 Underflow / 큐 = front·rear 포인터 2개, FIFO, rear 삽입·front 삭제.

#소프트웨어개발

Q12

디지털 저작권 관리(DRM)에 사용되는 기술 요소가 아닌 것은?

1키 관리

2방화벽

3암호화

4크랙방지

정답 2번 · 방화벽

핵심 해설

디지털 저작권 관리(DRM)의 기술 요소는 암호화, 키 관리, 암호화 파일 생성(패키저), 식별 기술(DOI·URI), 저작권 표현(XrML 등 권리 표현 언어), 정책 관리, 크랙 방지(Tamper Resistance), 인증(Authentication)이다. 이들은 모두 콘텐츠 자체를 보호하고 이용 권한을 통제하는 데 초점이 있다. 반면 방화벽은 네트워크 경계에서 IP·포트·프로토콜을 기준으로 패킷을 필터링해 비인가 접근을 차단하는 네트워크 보안 장비로, 콘텐츠의 저작권을 보호하는 기술이 아니다.

보기별 해설

1. 키 관리는 DRM의 핵심 기술 요소이다. 콘텐츠 암·복호화에 사용하는 키를 안전하게 생성·저장·분배하며, 중앙 집중형과 분산형 방식으로 구현한다.

2. 방화벽(Firewall)은 네트워크 경계에서 패킷의 출발지·목적지 IP와 포트를 검사해 허용되지 않은 트래픽을 차단하는 네트워크 보안 장비이다. 시스템 접근 통제가 목적이며 콘텐츠 자체의 권리 보호를 수행하지 않으므로 DRM 기술 요소가 아니다.

3. 암호화는 DRM의 기반 기술 요소이다. 콘텐츠와 라이선스 정보를 암호화해 저장·유통함으로써 정당한 권한을 가진 사용자만 복호화해 이용할 수 있게 한다.

4. 크랙방지(Tamper Resistance)는 DRM 기술 요소이다. DRM 보호 모듈을 우회하거나 변조해 콘텐츠를 무단으로 추출하려는 시도를 코드 난독화와 무결성 검사로 차단한다.

정리

DRM 기술 요소 — 암호화, 키 관리, 패키저, 식별 기술(DOI/URI), 저작권 표현(XrML), 정책 관리, 크랙 방지, 인증. 방화벽·IDS 같은 네트워크 장비는 포함되지 않는다.

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

Q13

버전 관리 항목 중 저장소에 새로운 버전의 파일로 갱신하는 것을 의미하는 용어는?

1형상 감사(Configuration Audit)

2롤백 (Rollback)

3단위 테스트(Unit Test)

4체크인(Check-In)

정답 4번 · 체크인(Check-In)

핵심 해설

버전 관리의 주요 활동은 인출(Check-Out), 체크인(Check-In), 커밋(Commit), 동기화(Update), 가져오기(Import)로 이루어진다. 이 중 체크인(Check-In)은 개발자가 수정을 마친 파일을 공유 저장소에 새로운 버전으로 갱신해 등록하는 작업을 말한다. 반대로 체크아웃은 저장소에서 파일을 자신의 작업 공간으로 내려받는 작업이며, 커밋은 체크인 과정에서 변경 사항을 실제로 반영해 확정하는 단계이다. 따라서 저장소에 새 버전 파일로 갱신하는 것은 체크인이다.

보기별 해설

1. 형상 감사(Configuration Audit)는 형상 관리 절차의 하나로, 변경이 요구사항대로 정확히 반영되었는지와 기준선의 무결성을 검토·확인하는 활동이다. 파일을 저장소에 올리는 작업이 아니다.

2. 롤백(Rollback)은 변경 작업을 취소하고 이전의 정상 상태로 되돌리는 작업이다. 트랜잭션이나 배포 실패 시 복구에 쓰이며 새 버전을 등록하는 것과는 반대 방향의 동작이다.

3. 단위 테스트(Unit Test)는 모듈이나 함수 단위의 동작을 개별 검증하는 테스트 활동이다. 소프트웨어 테스트 단계에 속하며 버전 관리 항목이 아니다.

4. 체크인(Check-In)은 개발자가 수정한 파일을 공유 저장소에 새로운 버전으로 갱신·등록하는 작업이다. 충돌이 있으면 커밋 전 차이를 확인하고 병합(Merge)한 뒤 반영한다.

정리

버전 관리 용어 — 가져오기(Import), 체크아웃(내려받기), 체크인(새 버전으로 저장소 갱신), 커밋(변경 확정 반영), 동기화(Update).

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

Q14

정렬된 N개의 데이터를 처리하는 데 O(Nlog2N)의 시간이 소요되는 정렬 알고리즘은?

1합병 정렬

2버블 정렬

3선택 정렬

4삽입 정렬

정답 1번 · 합병 정렬

핵심 해설

정렬 알고리즘의 시간 복잡도는 비교 횟수의 증가율로 구분된다. 합병 정렬은 배열을 절반씩 분할해 log₂N 단계의 깊이를 만들고, 각 단계마다 N개 원소를 병합하므로 최선·평균·최악 모두 O(N log₂N)이다. 반면 버블·선택·삽입 정렬은 매 회전마다 남은 원소 전체를 비교하는 이중 반복 구조여서 평균·최악이 O(N²)이다. 특히 '이미 정렬된 데이터'라는 조건에서 버블과 삽입은 O(N)까지 빨라지고 선택은 여전히 O(N²)이므로, N log₂N을 항상 보장하는 것은 합병 정렬뿐이다.

보기별 해설

1. 합병 정렬(Merge Sort)은 분할 정복 방식으로 배열을 절반씩 나눈 뒤 정렬된 부분들을 병합한다. 분할 깊이가 log₂N, 각 깊이의 병합 비용이 N이므로 최선·평균·최악 모두 O(N log₂N)이다.

2. 버블 정렬(Bubble Sort)은 인접한 두 원소를 비교·교환하며 큰 값을 뒤로 밀어내는 방식으로, 비교 횟수가 N(N-1)/2이라 평균·최악 O(N²)이다. 이미 정렬된 입력이면 교환 없이 1회전에 끝나 최선이 O(N)이다.

3. 선택 정렬(Selection Sort)은 남은 구간에서 최솟값을 찾아 맨 앞과 교환하는 방식이다. 입력 상태와 무관하게 항상 N(N-1)/2번 비교하므로 최선·평균·최악이 모두 O(N²)이다.

4. 삽입 정렬(Insertion Sort)은 두 번째 원소부터 앞쪽의 정렬된 부분에 알맞은 위치를 찾아 끼워 넣는 방식으로 평균·최악이 O(N²)이다. 이미 정렬된 입력에서는 비교만 N-1번 하고 끝나 최선이 O(N)이다.

정리

정렬 복잡도 — 합병·힙 정렬: 항상 O(N log₂N) / 퀵 정렬: 평균 O(N log₂N), 최악 O(N²) / 버블·선택·삽입: 평균·최악 O(N²)(버블·삽입만 최선 O(N)).

#소프트웨어개발

Q15

클린 코드 작성 원칙에 대한 설명으로 틀린 것은?

1코드의 중복을 최소화 한다.

2코드가 다른 모듈에 미치는 영향을 최대화하도록 작성한다.

3누구든지 코드를 쉽게 읽을 수 있도록 작성한다.

4간단하게 코드를 작성한다.

정답 2번 · 코드가 다른 모듈에 미치는 영향을 최대화하도록 작성한다.

핵심 해설

클린 코드(Clean Code)는 누구나 쉽게 읽고 이해할 수 있으며 수정이 용이하도록 작성한 코드를 말한다. 작성 원칙은 가독성(이해하기 쉬운 이름과 주석), 단순성(한 번에 한 가지만 처리, 최소 단위로 분리), 의존성 배제(다른 모듈에 미치는 영향 최소화), 중복성 최소화(중복 코드 제거), 추상화(상위 클래스에서 애플리케이션 특성을 나타내고 세부 내용은 하위 클래스에서 구현)이다. 따라서 다른 모듈에 미치는 영향을 '최대화'한다는 서술은 의존성 배제 원칙과 정반대이므로 틀렸다.

보기별 해설

1. 코드의 중복을 최소화하는 것은 클린 코드의 중복성 최소화 원칙이다. 같은 로직이 여러 곳에 흩어지면 수정 누락과 오류가 늘어나므로 공통 부분을 분리해 재사용한다.

2. 코드가 다른 모듈에 미치는 영향을 최대화한다는 서술은 클린 코드의 의존성 배제 원칙에 정면으로 어긋난다. 결합도를 낮춰 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화해야 한다.

3. 누구든지 코드를 쉽게 읽을 수 있게 작성하는 것은 가독성 원칙이다. 이해하기 쉬운 변수·함수 이름을 쓰고 필요한 곳에 주석을 달아 의도를 드러낸다.

4. 간단하게 코드를 작성하는 것은 단순성 원칙이다. 한 번에 한 가지 기능만 처리하도록 클래스와 메소드를 최소 단위로 분리해 복잡도를 낮춘다.

정리

클린 코드 5원칙 — 가독성, 단순성, 의존성 배제(영향 최소화), 중복성 최소화, 추상화. '영향 최대화'는 항상 오답이다.

#소프트웨어개발

Q16

테스트 케이스 자동 생성 도구를 이용하여 테스트 데이터를 찾아내는 방법이 아닌 것은?

1스터브(Stub)와 드라이버(Driver)

2입력 도메인 분석

3랜덤(Random) 테스트

4자료 흐름도

정답 1번 · 스터브(Stub)와 드라이버(Driver)

핵심 해설

테스트 케이스 자동 생성 도구는 프로그램 명세나 구조를 분석해 테스트 데이터를 자동으로 만들어 내는 도구로, 자료 흐름도(Data Flow Diagram)를 이용한 경로 분석, 기능 테스트를 위한 입력 도메인 분석, 무작위 값을 생성하는 랜덤 테스트가 대표적인 방법이다. 반면 스터브와 드라이버는 테스트 데이터를 만들어 내는 것이 아니라, 아직 개발되지 않은 하위 모듈이나 상위 모듈을 대신해 테스트 환경을 갖춰 주는 가상의 모듈(테스트 하네스 구성 요소)이다. 따라서 테스트 데이터를 찾아내는 방법이 아닌 것은 스터브와 드라이버이다.

보기별 해설

1. 스터브(Stub)와 드라이버(Driver)는 테스트 하네스를 구성하는 가상 모듈이다. 스터브는 하향식 통합에서 아직 없는 하위 모듈을, 드라이버는 상향식 통합에서 없는 상위 모듈을 대신하며, 테스트 데이터를 생성하는 도구가 아니다.

2. 입력 도메인 분석은 테스트 케이스 자동 생성 방법이다. 프로그램의 입력 변수가 가질 수 있는 값의 범위와 유형을 분석해 유효·무효 영역의 대표 데이터를 도출한다.

3. 랜덤(Random) 테스트는 테스트 케이스 자동 생성 방법이다. 입력 값을 무작위로 대량 생성해 프로그램에 주입함으로써 개발자가 예상하지 못한 입력에서의 오류를 찾아낸다.

4. 자료 흐름도(Data Flow Diagram)는 테스트 케이스 자동 생성에 활용되는 방법이다. 데이터의 입력·처리·출력 흐름을 분석해 검증이 필요한 경로와 그에 맞는 테스트 데이터를 도출한다.

정리

테스트 케이스 자동 생성 방법 = 자료 흐름도, 입력 도메인 분석, 랜덤 테스트. 스터브·드라이버는 데이터 생성이 아니라 없는 모듈을 대신하는 테스트 하네스이다.

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

Q17

순서가 A, B, C, D로 정해진 입력 자료를 스택에 입력한 후 출력한 결과로 불가능한 것은?

1D, C, B, A

2B, C, D, A

3C, B, A, D

4D, B, C, A

정답 4번 · D, B, C, A

핵심 해설

스택은 LIFO 구조이므로 입력 순서 A, B, C, D 사이사이에 pop을 끼워 넣을 수 있고, 이때 '먼저 push된 것보다 나중에 push된 것이 먼저 나온다'는 제약이 걸린다. 판정 규칙은 간단한데, 출력 순서에서 어떤 원소 뒤에 그보다 늦게 입력된 원소가 두 개 이상 나오면서 그 두 원소가 입력 역순이 아니면 불가능하다. 4번 D, B, C, A는 D를 꺼낸 시점에 스택이 아래에서부터 A, B, C 순으로 쌓여 있어 top이 C이므로 다음에 반드시 C가 나와야 하는데 B가 나오므로 불가능하다. 나머지는 push/pop 순서를 적절히 배치해 모두 만들 수 있다.

보기별 해설

1. D, C, B, A는 push A, push B, push C, push D로 모두 넣은 뒤 네 번 연속 pop하면 얻어지는 완전 역순 출력이다. 스택 출력의 가장 전형적인 형태이다.

2. B, C, D, A는 push A → push B → pop(B) → push C → pop(C) → push D → pop(D) → pop(A) 순서로 가능하다. A를 바닥에 남겨둔 채 나머지를 넣는 즉시 꺼내는 방식이다.

3. C, B, A, D는 push A → push B → push C → pop(C) → pop(B) → pop(A) → push D → pop(D) 순서로 가능하다. 앞의 세 개를 역순으로 비운 뒤 D를 따로 처리하는 형태이다.

4. D, B, C, A는 불가능하다. D가 첫 출력이려면 A, B, C, D가 모두 push된 상태여야 하는데, D를 pop한 직후 스택은 아래부터 A, B, C이고 top이 C이므로 다음 출력은 반드시 C여야 한다. 실제로 D 다음에 C가 오는 D, C, B, A는 1번처럼 가능하지만 B가 먼저 나오는 순서는 만들 수 없다.

정리

스택 출력 가능성 판정 — 이미 스택에 쌓인 원소들은 반드시 입력 역순으로만 나온다. 늦게 들어간 원소가 아직 스택에 남아 있는데 그보다 먼저 들어간 원소가 나오면 불가능하다.

#소프트웨어개발

Q18

프로젝트에 내재된 위험 요소를 인식하고 그 영향을 분석하여 이를 관리하는 활동으로서프로젝트를, 성공시키기 위하여 위험 요소를 사전에 예측대비하는, 모든 기술과 활동을 포함하는 것은?

1Critical Path Method

2Risk Analysis

3Work Breakdown Structure

4Waterfall Model

정답 2번 · Risk Analysis

핵심 해설

위험 분석(Risk Analysis)은 프로젝트에 내재된 위험 요소를 식별하고 발생 확률과 영향도를 평가해 대응 전략을 세우는 활동이다. 절차는 위험 식별 → 위험 분석 및 평가 → 위험 관리 계획 수립 → 위험 감시 및 조치로 이어지며, 사전 예측과 대비를 통해 프로젝트 실패 가능성을 낮추는 모든 기술과 활동을 포함한다. 나선형(Spiral) 모형이 각 주기마다 위험 분석 단계를 두는 것도 같은 취지이다. 따라서 문제의 설명에 해당하는 것은 Risk Analysis이다.

보기별 해설

1. Critical Path Method(CPM, 임계 경로 기법)는 작업 간 선후 관계를 네트워크로 표현해 프로젝트 최단 완료 기간과 여유 없는 임계 경로를 산출하는 일정 관리 기법이다. 일정 계획 도구이지 위험 관리 활동이 아니다.

2. Risk Analysis(위험 분석)는 프로젝트의 위험 요소를 식별하고 발생 확률과 영향을 평가해 사전에 대비·관리하는 활동이다. 위험 식별, 분석·평가, 관리 계획 수립, 감시 및 조치의 절차로 수행된다.

3. Work Breakdown Structure(WBS, 업무 분류 체계)는 프로젝트 산출물과 작업을 계층적으로 분해해 관리 단위를 정의하는 도구이다. 범위와 일정 산정의 기초가 되지만 위험 예측 활동은 아니다.

4. Waterfall Model(폭포수 모형)은 계획, 분석, 설계, 구현, 시험, 유지보수를 순차적으로 진행하는 소프트웨어 생명 주기 모형이다. 개발 절차 모형일 뿐이며, 주기마다 위험 분석을 수행하는 모형은 나선형(Spiral) 모형이다.

정리

위험 관리 = 위험 식별 → 분석·평가 → 관리 계획 → 감시·조치. CPM은 일정, WBS는 범위 분해, 위험 분석을 반복 주기에 포함한 생명 주기 모형은 나선형 모형이다.

#소프트웨어개발

Q19

인터페이스 간의 통신을 위해 이용되는 데이터 포맷이 아닌 것은?

1AJTML

2JSON

3XML

4YAML

정답 1번 · AJTML

핵심 해설

인터페이스 간 통신에 사용하는 데이터 포맷은 시스템 간에 데이터를 구조화해 주고받기 위한 표준 표기 형식으로, JSON, XML, YAML, CSV 등이 대표적이다. 이들은 모두 이기종 시스템이 파싱할 수 있는 텍스트 기반 직렬화 형식이라는 공통점이 있다. AJTML은 이러한 데이터 포맷 목록에 존재하지 않는 명칭으로, 비동기 통신 기법인 AJAX나 문서 표현 언어인 HTML과 철자가 섞인 형태의 가짜 용어이다. 따라서 데이터 포맷이 아닌 것은 AJTML이다.

보기별 해설

1. AJTML은 실제로 존재하지 않는 명칭이다. 비동기 통신 방식인 AJAX와 웹 문서 표현 언어인 HTML을 뒤섞은 형태의 가짜 용어이며, 인터페이스 데이터 포맷 표준에 이런 이름은 없다.

2. JSON(JavaScript Object Notation)은 속성-값 쌍으로 데이터를 표현하는 경량 데이터 교환 포맷이다. XML보다 구조가 간결하고 파싱이 빨라 REST API의 기본 포맷으로 널리 쓰인다.

3. XML(eXtensible Markup Language)은 사용자가 태그를 직접 정의해 데이터의 구조와 의미를 기술하는 마크업 언어이다. 스키마로 형식 검증이 가능해 SOAP 등 기업 간 데이터 교환에 사용된다.

4. YAML(YAML Ain't Markup Language)은 들여쓰기로 계층 구조를 표현하는 사람이 읽기 쉬운 데이터 직렬화 포맷이다. 설정 파일과 인터페이스 데이터 표현에 널리 쓰이며 JSON의 상위 집합에 해당한다.

정리

인터페이스 데이터 포맷 — JSON(속성-값 쌍, 경량), XML(사용자 정의 태그 마크업), YAML(들여쓰기 기반), CSV(구분자 기반). AJTML은 존재하지 않는 용어이다.

#소프트웨어개발

Q20

정형 기술 검토(FTR)의 지침으로 틀린 것은?

1의제를 제한한다.

2논쟁과 반박을 제한한다.

3문제 영역을 명확히 표현한다.

4참가자의 수를 제한하지 않는다. - 3

정답 4번 · 참가자의 수를 제한하지 않는다. - 3

핵심 해설

정형 기술 검토(FTR, Formal Technical Review)는 소프트웨어 산출물의 결함을 발견하고 표준 준수 여부를 확인하기 위해 수행하는 정적 검토 회의이다. 지침은 제품의 검토에만 집중할 것(개발자 개인을 비판하지 말 것), 의제를 제한할 것, 논쟁과 반박을 제한할 것, 문제 영역을 명확히 표현할 것, 해결책이나 개선책은 다루지 말 것, 참가자의 수를 제한하고 사전 준비를 강요할 것, 검토 과정과 결과를 기록으로 남길 것 등이다. 회의 효율을 위해 참가자 수를 제한해야 하므로 '제한하지 않는다'는 서술은 지침에 어긋난다.

보기별 해설

1. 의제를 제한한다는 것은 FTR의 옳은 지침이다. 한 번의 검토 회의에서 다룰 범위를 미리 정해 두어야 논점이 흩어지지 않고 정해진 시간 안에 결함을 찾을 수 있다.

2. 논쟁과 반박을 제한한다는 것도 FTR의 옳은 지침이다. 회의는 결함을 식별하는 자리이며, 의견 충돌은 기록해 두고 추후 별도로 해결한다.

3. 문제 영역을 명확히 표현한다는 것 역시 옳은 지침이다. 결함의 위치와 내용을 구체적으로 지적해야 후속 조치가 가능하며, 다만 해결책까지 제시하려 들지는 않는다.

4. 참가자의 수를 제한하지 않는다는 서술이 지침에 어긋난다. FTR은 참가자 수를 제한하고 사전 준비를 강요해야 검토가 효율적으로 진행되므로, 인원을 무제한으로 두어서는 안 된다.

정리

FTR 지침 — 제품 검토에 집중(개발자 비판 금지), 의제 제한, 논쟁·반박 제한, 문제 영역 명확화, 해결책 논의 금지, 참가자 수 제한 및 사전 준비 강요, 검토 결과 문서화.

#소프트웨어개발