소프트 웨어 개발
21. EAI(Enterprise Application Integration)의 구축 유형
- Point-to-Point
- Hub & Spoke
- Message Bus
- Tree
🧠 해설
**EAI(Enterprise Application Integration)**는
기업 내 여러 **이기종 시스템(ERP, CRM, DB 등)**을
연동하고 통합하기 위한 소프트웨어 아키텍처 또는 프레임워크야.
즉, 각기 다른 시스템들이 서로 데이터를 주고받고 기능을 공유할 수 있도록 중간 허브 역할을 해주는 구조지.
✅ EAI의 대표적 구축 유형 3가지
| 1. Point-to-Point | - 시스템 간을 직접 연결 - 구조가 단순하지만, 시스템이 많아질수록 연결이 복잡해짐 (N(N-1)/2)* |
| 2. Hub & Spoke | - **중앙 허브(Hub)**를 통해 각 시스템(Spoke)을 연결 - 메시지 변환/중재를 허브가 담당 (구조적이며 관리 용이) |
| 3. Message Bus | - **표준 메시지 버스(ESB: Enterprise Service Bus)**를 사용 - 시스템들이 버스를 통해 메시지를 주고받음 - 확장성, 유연성 최고, 가장 현대적인 방식 |
❌ 오답: Tree
- Tree 구조는 계층적, 트리 형태의 구조를 의미하지만
이는 EAI 구축 방식과는 무관한 용어야. - 즉, EAI 표준 구축 유형에는 해당되지 않음.
22. 검증 검사 기법 중 개발자의 장소에서 사용자가 개발자 앞에서 행하는 기법이며 일반적으로 통제된 환경에서 사용자와 개발자가 함께 확인하면서 수행되는 검사는?
- 동치 분할 검사
- 형상 검사
- 알파 검사
- 베타 검사
항목 알파 검사 (Alpha Test) 베타 검사 (Beta Test) 동치 분할 검사 (Equivalence Partitioning) 형상 검사 (Configuration Audit)
| 검사 목적 | 기능/사용성 확인 및 조기 피드백 | 사용자 관점에서 문제 발견 | 입력 데이터를 그룹으로 나눠 효율적 테스트 | 형상 관리 상태 및 변경 이력 점검 |
| 수행 장소 | 개발자 사무실 (내부) | 실제 사용자 환경 (외부) | 테스트 환경 내 | 개발 프로세스 내 (문서/도구 기반) |
| 참여자 | 사용자 + 개발자 함께 | 사용자 단독 (개발자 관여 없음) | 개발자 또는 테스터 | 형상 관리자, 검토자 |
| 테스트 시기 | 출시 전, 내부 검증 단계 | 출시 직전, 외부 검증 단계 | 단위 테스트 또는 초기 단계 | 전 개발 단계에 걸쳐 수행 가능 |
| 테스트 방식 | 통제된 환경에서 직접 실행 및 관찰 | 실사용 환경에서 피드백 수집 | 값들을 동등한 범위로 나눠 케이스 설계 | 문서 및 구성 요소 비교/검토 |
| 기타 특징 | 오류를 직접 관찰하고 바로 수정 가능 | 실환경 이슈 수집, 대규모 피드백 확보 | 범위를 줄이고, 테스트 수 줄임 | 제품 품질과 변경 추적 관리 |
23. 다음 트리의 치수는?
✅ 트리의 차수를 구하는 방법
- **각 노드의 자식 수(=차수)**를 센다
- 그중 가장 큰 값이 트리의 차수
A
/ | \
B C D
/ \ |
E F G 여기서 3차
24. 인터페이스 구현 시 사용하는 기술 중 다음 내용이 설명하는 것은
- JavaScript를 사용한 비동기 통신기술, 클라이언트와 서버 간에 XML 데이터를 주고받는 기술
- Procedure
- Trigger
- Greedy
- AJAX
| AJAX(Asynchronous JavaScript and XML) | JavaScript를 이용한 비동기 통신 기술브라우저가 페이지 전체를 새로 고침하지 않고 서버와 데이터 주고받기 가능 | - 비동기 통신- 주로 XML 또는 JSON 사용- 사용자 경험(UX) 향상 | ✅ 문제 설명과 정확히 일치 |
| Procedure | 데이터베이스에서 사용되는 저장된 실행 절차여러 SQL문을 묶어놓은 함수 개념 | - 입력값 받아 여러 SQL 실행- 호출 시마다 처리 수행 | ❌ 통신 기술 아님, DB 내부 로직임 |
| Trigger | 특정 이벤트(삽입, 수정, 삭제 등)가 발생했을 때 자동 실행되는 DB 명령 | - 자동 실행- INSERT/UPDATE/DELETE 감지 | ❌ 서버/클라이언트 통신과 무관 |
| Greedy(탐욕 알고리즘) | 항상 그 순간의 최적 선택을 반복해 전체 최적을 찾는 알고리즘 방식 | - 지역 최적이 전체 최적이 되도록- 대표 예: 거스름돈, 회의실 배정 | ❌ 알고리즘 전략으로, 인터페이스나 통신과는 무관 |
25. 해싱 함수 중 레코드 키를 여러 부분으로 나누고, 나눈 부분의 각 숫자를 더하거나 XOR한 값을 홈 주소로 사용하는 방식은?
- 제산법
- 폴딩법
- 기수 변환법
- 숫자 분석법
| 제산법(Division Method) | 레코드 키를 어떤 수로 나눈 나머지를 해시 주소로 사용 | - 구현 간단- 보통 소수로 나눔 | key % 17 | ❌ | 키를 나누지 않음, 나머지만 사용 |
| ✅ 폴딩법(Folding Method) | 키를 여러 부분으로 나눈 후, 그 숫자들을 더하거나 XOR하여 주소 생성 | - 큰 키를 효과적으로 줄일 수 있음- 자릿수 무시 가능 | 123456 → 123 + 456 = 579 | ✅ | 문제 조건과 정확히 일치 |
| 기수 변환법(Radix Conversion Method) | 키를 다른 진법으로 바꿔서 해시 주소로 사용 | - 진법에 따라 해시 분포 달라짐 | 10진수 → 2진수 → 일부 선택 | ❌ | 키를 나누지 않고 진법 변환만 함 |
| 숫자 분석법(Digit Analysis Method) | 여러 키를 분석하여 자주 변하는 자릿수만 선택해 해시 주소로 사용 | - 키의 분포 분석 필요- 특정 위치 숫자만 사용 | 주민번호의 뒤 4자리만 사용 | ❌ | 키를 나누고 더하거나 XOR하지 않음 |
26. 다음 자료에 대하여 선택(Selection) 정렬을 이용하여 오름차순으로 정렬하고자 한다 3회전 후의 결과로 옳은 것은
- 37,14,17,40,35
✅ 3회전 후 결과: [14, 17, 35, 40, 37]
정렬 알고리즘 방식 평균 시간복잡도 공간복잡도 특징
| 선택 정렬 | 가장 작은 값을 찾아 맨 앞과 교환 | O(n²) | O(1) | 구현 쉬움, 교환 횟수 적음 |
| 버블 정렬 | 인접한 요소끼리 비교해 swap | O(n²) | O(1) | 안정 정렬, 느림 |
| 삽입 정렬 | 정렬된 부분에 값을 끼워 넣음 | O(n²) | O(1) | 거의 정렬된 자료에 빠름 |
| 퀵 정렬 | 피벗 기준 분할 정복 | O(n log n) 평균O(n²) 최악 | O(log n) | 빠르지만 불안정 정렬 |
| 병합 정렬 | 반으로 나누고 병합 | O(n log n) | O(n) | 안정 정렬, 분할 정복 |
| 힙 정렬 | 힙 구조 사용 | O(n log n) | O(1) | 불안정 정렬, 항상 일정한 속도 |
27. 소스 코드 품질 분석 도구 중 정적 분석 도구가 아닌 것은?
- pmd
- checkstyle
- valance
- cppcheck
도구 이름 분석 유형 설명 정답 여부
| PMD | ✅ 정적 분석 | Java, JavaScript 등에서 불필요한 코드, 중복, 잠재적 버그 탐지 | ❌ |
| Checkstyle | ✅ 정적 분석 | Java 코드의 코딩 스타일, 문법 규칙 위반을 검사 | ❌ |
| Cppcheck | ✅ 정적 분석 | C/C++ 코드에서 버그, 메모리 누수 가능성을 코드 수준에서 분석 | ❌ |
| Valgrind (valance는 오타) | ❌ 동적 분석 | C/C++ 프로그램을 실행하면서 메모리 누수, 접근 오류 분석 | ✅ 정답 |
28. 다음 트리에 대한 중위 순회 운행 결과는
왼쪽 → 루트 → 오른쪽 순서로 방문하는 트리 순회 방식이야
중위 순회(in-order traversal) 순서
단계별로 방문해 보자:
- 왼쪽 서브트리로 간다 → 루트: a → 왼쪽은 b
- b의 왼쪽: d → 왼쪽 없음 → 방문: d
- b 방문
- b의 오른쪽 없음 → 돌아와서 a 방문
- a의 오른쪽: c
- c의 왼쪽: e → 왼쪽 없음 → 방문: e
- c 방문
- c의 오른쪽: f → 왼쪽 없음 → 방문: f
d → b → a → e → c → f
29. 소프트웨어 테스트와 관련한 설명으로 틀린 것은?
- 화이트박스 테스트는 모듈의 논리적인 구조를 체계적으로 점검 할 수 있다
- 블랙박스 테스트는 프로그램의 구조를 고려하지 않는다
- 테스트 케이스에는 일반적으로 시험 조건, 테스트 데이터, 예상 결과가 포함되어야 한다
- 화이트박스 테스트에서 기본 경로(Basis Path)란 흐름 그래프의 시작 노드에서 종료 노드까지의 서로 독립된 경로로 싸이클을 허용하지 않는 경로를 말한다
보기 설명 맞는지 여부
| 화이트박스 테스트는 모듈의 논리적인 구조를 체계적으로 점검할 수 있다 | ✅ 내부 코드를 보고 조건/분기/루프 등 논리적 구조를 테스트함 | ✔ 맞음 |
| 블랙박스 테스트는 프로그램의 구조를 고려하지 않는다 | ✅ 내부 코드를 보지 않고 입력-출력만으로 기능을 테스트함 | ✔ 맞음 |
| 테스트 케이스에는 일반적으로 시험 조건, 테스트 데이터, 예상 결과가 포함되어야 한다 | ✅ 테스트는 조건, 입력, 기대 결과가 있어야 검증이 가능함 | ✔ 맞음 |
| 화이트박스 테스트에서 기본 경로(Basis Path)란 흐름 그래프의 시작 노드에서 종료 노드까지의 서로 독립된 경로로 싸이클을 허용하지 않는 경로를 말한다 | ✅ 기본 경로는 싸이클을 포함할 수 있고, 모든 조건 분기문을 테스트할 수 있는 최소 테스트 경로 집합을 구성하는 게 핵심이야. | 틀림 |
소프트웨어 테스트 개요
| 구분 | 설명 |
| 목적 | 프로그램이 명세대로 잘 작동하는지 확인 |
| 종류 | - 화이트박스 테스트: 코드 내부 구조 검사 - 블랙박스 테스트: 기능(입출력 중심) 검사 |
| 테스트 단계 | 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트 |
| 테스트 케이스 | 시험 조건, 입력 데이터, 예상 출력이 포함되어야 함 |
| 항목 | 화이트박스 테스트 | 블랙박스 테스트 |
| 관점 | 코드 내부 중심 | 기능/동작 중심 |
| 접근 대상 | 내부 로직 (분기, 루프 등) | 외부 입력/출력 |
| 예시 기법 | 조건 커버리지, 루프 테스트, 기본 경로 테스트 | 동등 분할, 경계값 분석 |
| 장점 | 세밀한 테스트 가능 | 사용자 관점 테스트 가능 |
| 단점 | 복잡하고 구현 의존 | 내부 오류는 놓칠 수 있음 |
30. 소프트웨어 형상 관리에 대한 설명으로 거리가 먼 것은?
- 소프트웨어에 가해지는 변경을 제어하고 관리한다
- 프로젝트 계획, 분석서,설계서,프로그램,테스트케이스 모두 관리 대상이다
- 대표적인 형상 관리 도구로 Ant,Maven,Gradle 등이 있다
- 유지 보수 단계뿐만 아니라 개발 단계에도 적용할 수 있다
소프트웨어 형상 관리란?
소프트웨어 개발 과정에서 발생하는 **산출물(코드, 문서 등)**의
변경을 체계적으로 관리하고 추적하는 활동
✅ 형상 관리의 목적
| 변경 추적 | 누가 언제 어떤 변경을 했는지 기록 |
| 일관성 유지 | 여러 사람이 동시에 작업해도 충돌 없이 관리 |
| 품질 확보 | 무분별한 수정 방지, 검토 및 승인 절차 포함 |
✅ 형상 관리 대상 예시
- 소스 코드
- 분석/설계 문서
- 테스트 케이스
- 매뉴얼
- 빌드 스크립트
- 등 모든 산출물
✅ 형상 관리는 개발 + 유지보수 전체에 적용됨
| 개발 단계 | 여러 개발자의 협업, 버전 관리 |
| 테스트 단계 | 테스트 환경과 결과 추적 |
| 유지보수 단계 | 과거 변경 이력 기반으로 빠른 대응 가능 |
📌 정답 정리
| 소프트웨어에 가해지는 변경을 제어하고 관리한다 | 형상 관리의 핵심 정의 | ❌ (맞음) |
| 프로젝트 계획, 분석서,설계서,프로그램,테스트케이스 모두 관리 대상이다 | 모든 산출물이 형상 관리 대상 | ❌ (맞음) |
| 대표적인 형상 관리 도구로 Ant, Maven, Gradle 등이 있다 | ❌ 이들은 빌드 도구지, 형상 관리 도구가 아님 | ✅ (정답) |
| 유지 보수 단계뿐만 아니라 개발 단계에도 적용할 수 있다 | 형상 관리는 전체 생명주기에 적용 | ❌ (맞음) |
✅ 요약
- **형상 관리(CM)**는 소프트웨어 변경사항을 체계적으로 관리하는 활동
- Git, SVN 등이 형상 관리 도구
- Ant, Maven, Gradle은 빌드 도구 → ❌ 형상 관리 도구 아님
31. 다음 중 최악의 경우 검색 효율이 가장 나쁜 트리 구조는?
- 이진 탐색 트리
- AVL트리
- 2-3트리
- 레드블랙 트리
트리 비교표
| 트리 종류 | 구조 특징 | 자동 균형 유지 | 최악의 시간 복잡도 | 비고 |
| 이진 탐색 트리 (Binary Search Tree) |
노드당 최대 2개의 자식, 왼쪽 < 부모 < 오른쪽 | ❌ X (편향 가능) | ❌ O(n) | 입력 순서에 따라 성능 급락 |
| AVL 트리 | 이진 트리 + 균형 인수(높이 차) 유지 | ✅ 항상 균형 | ✅ O(log n) | 삽입/삭제 시 회전 필요 |
| 2-3 트리 | 노드당 2개 또는 3개의 자식 허용 균형 다진 트리 |
✅ 균형 유지 | ✅ O(log n) | 다진 트리 구조 |
| 레드블랙 트리 | 이진 트리 + 노드 색상 규칙으로 균형 유지 | ✅ 균형 유지 | ✅ O(log n) | AVL보다 균형은 느슨하지만 빠름 |
32. 다음 중 선형 구조로만 묶인 것은?
- 스택, 트리
- 큐, 데크
- 큐, 그래프
- 리스트, 그래프
1. 선형 구조 (Linear Structure)
데이터를 순서대로 일렬로 나열하는 구조
앞/뒤가 명확하고, 탐색, 삽입, 삭제가 순차적으로 이루어짐
| 자료구조 | 설명 | 특징 |
| 배열 (Array) | 고정 크기의 메모리 공간에 데이터 저장 | 인덱스로 접근 가능, 크기 변경 어려움 |
| 연결 리스트 (Linked List) | 포인터로 노드끼리 연결된 구조 | 삽입/삭제 쉬움, 순차 탐색 |
| 스택 (Stack) | LIFO (후입선출) 구조 | push, pop, 맨 위(top)만 접근 |
| 큐 (Queue) | FIFO (선입선출) 구조 | enqueue, dequeue, 맨 앞/뒤 관리 |
| 데크 (Deque) | 양쪽에서 삽입/삭제 가능한 큐 | append, appendleft, pop, popleft |
2. 비선형 구조 (Non-Linear Structure)
데이터가 계층적(트리) 또는 복잡하게 얽힌 구조(그래프)
하나의 요소가 여러 개와 연결될 수 있음
| 자료구조 | 설명 | 특징 |
| 트리 (Tree) | 계층 구조 (부모-자식 관계) | 루트, 노드, 자식/리프, 순회 가능 |
| 이진 트리 | 각 노드가 최대 2개의 자식을 가짐 | 탐색, 삽입, 삭제 논리화 가능 |
| 힙 (Heap) | 우선순위 큐 구현에 사용되는 완전 이진 트리 | 최소힙/최대힙, 정렬 알고리즘 기반 |
| 그래프 (Graph) | 정점(Vertex)과 간선(Edge)으로 구성 | 방향/무방향, 가중치, 순환 가능 |
| 트라이 (Trie) | 문자열 저장에 특화된 트리 | 검색 속도 빠름, 자동완성 구현에 유리 |
33. 화이트박스 검사 기법에 해당하는 것으로만 짝지어진 것은
- 데이터 흐름 검사
- 루프 검사
- 동등 분할 검사
- 경계값 분석
- 원인 결과 그래프 기법
- 오류 예측 기법
해설: 화이트박스 검사 기법이란?
화이트박스(White-box) 테스트는 **프로그램의 내부 로직(소스코드)**을 기준으로
조건, 분기, 경로, 루프 등을 직접 분석해서 테스트하는 방법이야.
즉, “코드를 열어서 안을 들여다보고” 검사하는 방식이야.
✅ 보기별 기법 분류표
| 기법 | 설명 | 분류 |
| 데이터 흐름 검사 | 변수의 정의와 사용 위치 추적 | ✅ 화이트박스 |
| 루프 검사 | 반복문(while, for 등)의 수행 횟수 및 종료 조건 검사 | ✅ 화이트박스 |
| 동등 분할 검사 | 입력값을 유효/무효 그룹으로 나눠 테스트 | ❌ 블랙박스 |
| 경계값 분석 | 입력값의 경계(최솟값/최댓값 등) 위주로 테스트 | ❌ 블랙박스 |
| 원인-결과 그래프 기법 | 입력(원인)과 결과 간의 조합을 그래프로 표현 | ❌ 블랙박스 |
| 오류 예측 기법 | 개발자가 예상하는 오류 상황을 가정해 테스트 | ❌ 블랙박스 |
34. 단위 테스트에서 테스트의 대상이 되는 하위 모듈을 호출하고, 파라미터를 전달하는 가상의 모듈로 상향식 테스트에 필요한 것은
- 테스트 스텁(Test Stub)
- 테스트 드라이버 (Test Driver)
- 테스트 슈트(Test Suites)
- 테스트 케이스(Test Case)
| 용어 | 역할/정의 | 사용 방향 | 사용 위치 | 비고 |
| ✅ Test Driver | 하위 모듈을 테스트하기 위해 호출자 역할을 하는 상위 모듈 대체품 | 상향식 | 하위 모듈 테스트 | 정답 |
| Test Stub | 아직 구현되지 않은 하위 모듈을 흉내 내는 가짜 모듈 | 하향식 | 상위 모듈 테스트 | 주로 출력/반환값만 흉내 |
| Test Suite | 여러 테스트 케이스의 집합 | 전체 구조 관리용 | 단위/통합/시스템 등 전체 | JUnit에서 테스트 묶음 실행 |
| Test Case | 입력, 조건, 예상 결과가 포함된 개별 테스트 단위 | 모든 테스트에서 사용 | 단위/시스템 테스트 핵심 요소 | 테스트 하나하나의 구체적 시나리오 |
35. 인터페이스 구현 시 사용하는 기술로 속성-값 쌍(Attribute-Value Pairs)으로 이루어진 데이터 오브젝트를 전달하기 위해 사용하는 개방형 표준 포멧은?
- JSON
- HTML
- AVPN
- DOF
문제 요약
- **속성-값 쌍(Attribute-Value Pairs)**으로 구성됨
- 데이터 오브젝트를 전달
- 인터페이스 구현 시 사용
- 개방형 표준 포맷
| 포맷 | 전체 이름 | 역할 및 특징 | 적절성 | 비고 |
| ✅ JSON | JavaScript Object Notation | - 속성-값 쌍으로 구성- 가볍고 읽기 쉬움- API와 데이터 교환 표준- JavaScript 기반이지만 모든 언어에서 사용 가능 | ✅ 정답 | "name": "홍길동" 형식 |
| HTML | HyperText Markup Language | - 웹페이지 구조 설계용- UI 표시용 언어 | ❌ | 데이터 교환용 아님 |
| AVPN | 없음 (잘못된/가공된 보기로 추정) | - 표준 포맷 아님 | ❌ | 존재하지 않는 표기 |
| DOF | Distributed Object Framework (가능성) | - 객체 프레임워크 혹은 특정 도메인용 포맷- 표준 데이터 교환 포맷은 아님 | ❌ | 일반적인 API 포맷 아님 |
| 포맷 | 전체 이름 | 구조 특징 | 장점 | 단점 | 사용 예 |
| ✅ JSON | JavaScript Object Notation | "속성": 값 형식의 텍스트 | - 가볍고 간결- 대부분 언어 지원 | - 숫자 정밀도 제한- 바이너리 미지원 | 웹 API, 모바일 앱 |
| ✅ XML | eXtensible Markup Language | <태그>내용</태그> 구조 | - 스키마 정의 가능- 계층 표현 강력 | - 무겁고 복잡 | SOAP, 금융, 공공 데이터 |
| ✅ YAML | YAML Ain’t Markup Language | 들여쓰기로 계층 표현 | - 사람이 읽기 쉬움- 간결 | - 들여쓰기 민감- 파싱 복잡할 수 있음 | 설정 파일 (예: Docker, GitHub Actions) |
| ✅ Protocol Buffers | by Google | 바이너리 형식, .proto 정의 필요 | - 빠르고 용량 작음- 이식성 뛰어남 | - 사람이 직접 읽기 어려움- 별도 컴파일 필요 | 대규모 시스템, gRPC |
| ✅ MessagePack | Message Pack | JSON의 이진 버전 | - 속도 빠름- 바이너리 지원 | - 사람 읽기 어려움 | IoT, 모바일 데이터 전송 |
36. DRM(Digital Rights Management)과 관련한 설명으로 틀린것은
- 디지털 컨텐츠와디바이스 사용을 제한하기 위해 하드웨어 제조압자, 저작권자, 출반업자 등이 사용할 수 있는 접근 제어 기술
- 디지털 미디어의 생명 주기 동안 발생하는 사용권한 관리,과금,유통 단계를 관리하는 기술들로 볼 수 있다
- 클리어링 하우스(Clearing House)는 사용자에게 콘텐츠 라이센스를 발급하고 권한을 부여해주는 시스템을 말한다
- 원본을 안전하게 유통하기 위한 전자적 보안은 고려하지 않기 때문에 불법 유통과 복제의 방지는 불가능하다
🧠 DRM(Digital Rights Management)이란?
디지털 콘텐츠(음악, 영화, 전자책 등)의 저작권 보호를 위해 사용되는 전자적 접근 제어 기술
사용자가 콘텐츠를 어떻게 사용할 수 있는지를 제한·관리함
✅ DRM의 주요 기능
| 기능 | 설명 |
| 접근 제어 | 인증된 사용자만 콘텐츠에 접근 가능 |
| 사용 권한 관리 | 복제, 인쇄, 스크린샷, 공유 등 행동 제한 가능 |
| 라이선스 발급 | 정해진 조건(예: 사용기간, 기기 수) 안에서만 사용 허용 |
| 암호화 | 콘텐츠 자체를 암호화해 불법 복제 차단 |
| 사용 이력 추적 | 누가, 언제, 어디서, 어떻게 사용했는지 기록 |
✅ 관련 구성 요소
| 콘텐츠 제공자 (CP) | 콘텐츠를 만드는 저작권자 |
| DRM 에이전트 (클라이언트) | 사용자의 기기나 앱에서 DRM 제약을 관리 |
| 클리어링 하우스 (Clearing House) | 라이선스 발급/검증을 담당하는 중앙 관리 시스템 |
| 유통 채널 | DRM 콘텐츠를 유통하는 플랫폼 (예: Netflix, eBook Store 등) |
❌ 보기별 해설
| ① 디지털 콘텐츠 사용을 제한하기 위한 기술 | DRM의 정의 그대로 | ✅ |
| ② 미디어 생명 주기 전반을 관리 | 유통, 과금, 권한 관리 모두 포함 | ✅ |
| ③ 클리어링 하우스는 라이선스 발급/권한 부여 시스템 | DRM 시스템의 핵심 컴포넌트 | ✅ |
| ④ DRM은 보안을 고려하지 않기 때문에 불법 복제 방지는 불가능 | ❌ DRM은 바로 그걸 위해 존재하는 기술 | ❌ 정답 |
📌 한 줄 요약
DRM은 디지털 콘텐츠를 암호화하고, 사용 권한을 제어하여 불법 복제와 유통을 막기 위한 전자적 보안 기술이다.
37. 다음중 테스트 오라클에 대한 설명으로 옳지 않은 것은
- 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클이다
- 토탈 오라클 : 모든 테스트 케이스의 입력 값을 제공하는 오라클이다
- 휴리스틱 오라클 : 특정 테스트 케이스의 입력 값에 대해 기다하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클이다
- 일관성 검사 오라클 : 애플리케이션 변경이있을 경우 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클이다
테스트 오라클(Test Oracle) 이란?
테스트 수행 시, 테스트 결과가 올바른지 판단하는 기준 또는 메커니즘을 말해.
즉, 테스트 결과가 **"정답인지 아닌지"**를 알려주는 판단 기준이 바로 오라클이야.
✅ 정답: ② 토탈 오라클
❌ 왜 틀렸는가?
- **토탈 오라클(Total Oracle)**이라는 용어는 공식적인 테스트 오라클 분류에 존재하지 않음
- 모든 입력값에 대한 기대 결과를 제공하는 오라클은 완벽한 오라클(Perfect Oracle) 혹은 True Oracle이라고 부르기도 하지만, 일반적으로 샘플링/휴리스틱/일관성 오라클처럼 실제 사용되는 명칭은 아님
📊 테스트 오라클 유형 비교표
| ✅ 샘플링 오라클 | 일부 테스트 케이스에 대해서만 정답을 알고 있음 | 제한된 입력값에 대해만 검증 | 비용 절감, 일반적인 현실적 방법 |
| ✅ 휴리스틱 오라클 | 일부는 정답 제공, 나머지는 추정 판단 | 예: 출력이 "정상 범위"에 있으면 OK | 완전하지 않아도 유용함 |
| ✅ 일관성 검사 오라클 | 변경 전/후 결과가 동일한지 비교 | 리팩토링/패치 후 안정성 검증에 사용 | 스냅샷 테스트에 활용 |
| ❌ 토탈 오라클 | ❌ 정식 용어 아님 (모든 입력에 정답 제공은 이론적 모델에 가까움) | 현실적으로 구현 거의 불가 | ❌ 정답 (틀린 설명) |
✅ 한 줄 요약
테스트 오라클은 테스트 결과의 옳고 그름을 판단하는 기준이며, 현실적인 오라클은 완벽하지 않다. "토탈 오라클"은 실제 사용되지 않는 잘못된 용어다.
38. 인터페이스 구현 검증 도구가 아닌것은
- ESB
- xUnit
- STAF
- NTAF
| 도구 이름 | 정의 / 역할 | 인터페이스 검증 도구 여부 | 비고 |
| ❌ ESB(Enterprise Service Bus) | 다양한 시스템 간 메시지를 중개·통합하는 미들웨어→ 데이터 흐름 설계, 서비스 통합에 사용 | ❌ 검증 도구 아님 | 통합 아키텍처, 메시지 라우팅 |
| ✅ xUnit | 다양한 언어용 단위 테스트 프레임워크 통칭(JUnit, NUnit, PyTest 등) | ✅ | 단위 테스트 도구지만 인터페이스 검증에 활용 가능 |
| ✅ STAF(Software Testing Automation Framework) | 인터페이스 테스트 자동화 프레임워크분산 환경 지원 | ✅ | IBM에서 개발한 자동 테스트 플랫폼 |
| ✅ NTAF(Next-generation Testing Automation Framework) | 다양한 테스트 환경 통합을 위한 자동화 도구 프레임워크 | ✅ | 테스트 환경 통합 중심의 오픈 소스 기반 툴 |
39. 정점이 5개인 방향 그래프가 가질 수 있는 최대 간선 수는?(단, 자기 간선과 중복 간선은 배제한다)
계산 방법
✔ 가능한 정점 쌍 (i ≠ j)
- 정점이 5개면,
한 정점당 자기 자신을 제외한 4개의 정점에 간선 가능
→ 즉, 정점당 4개 간선 가능
→ 총: 5 × 4 = 20개
또는:
- 가능한 방향 쌍: n × (n - 1)
- 여기서 n = 5
→ 5 × 4 = 20
40. 물리 데이터 저장소의 파티션 설계에서 파티션 유형으로 옳지 않은 것은?
- 범위 분할(Range Partitioning)
- 해시 분할(Hash Partitioning)
- 조합 분할(Composite Partitioning)
- 유닛 분할(Unit Partitioning)
| 파티션 유형 | 정의 / 설명 | 예시 | 존재 여부 |
| ✅ 범위 분할 (Range Partitioning) | 특정 범위 값 기준으로 나누는 방식 | 날짜별 (2023-01 |
✅ 사용됨 |
| ✅ 해시 분할 (Hash Partitioning) | 해시 함수를 사용해 데이터를 고르게 분산 | ID % 4 → 파티션 0~3 | ✅ 사용됨 |
| ✅ 조합 분할 (Composite Partitioning) | 범위 + 해시 또는 범위 + 리스트처럼 2개 방식 조합 | 월별로 나눈 후, 각 월을 해시로 다시 나눔 | ✅ 사용됨 |
| ❌ 유닛 분할 (Unit Partitioning) | ❌ 공식 용어 아님. 파티션 방식 중 존재하지 않음 | 없음 | ❌ 존재하지 않음 |
| ✅ 리스트 분할 (List Partitioning) | 미리 정의된 값 목록에 따라 파티션 |
| ✅ 키 분할 (Key Partitioning) | 하나 이상의 컬럼 키 조합을 기준으로 파티션 |
'TIL' 카테고리의 다른 글
| 데이터베이스 구축 - 2024 1회 (1) | 2025.04.30 |
|---|---|
| 소프트웨어 설계 2024 1회 (0) | 2025.04.30 |
| 사전캠프 24일차 (1) | 2024.11.21 |
| 사전캠프 23일차 (0) | 2024.11.21 |
| 사전캠프 16일차 (0) | 2024.11.11 |