| 항목 | 설명 |
|---|---|
| 개발 배경 | IPv4 주소 고갈 문제 해결을 위해 개발 |
| 주소 길이 | 128비트 (16비트 × 8부분) |
| 표현 방식 | 각 부분을 16진수로 나타내며, 콜론(:) 으로 구분 |
| 보안성 | 인증성, 기밀성, 무결성을 기본적으로 지원 (IPSec 내장) |
| 확장성·유연성 | 주소 공간이 매우 넓어 IoT, 모바일 등 대규모 연결 환경에 적합 |
| 멀티미디어 지원 | 실시간 흐름 제어 가능 – 멀티미디어 트래픽 품질 보장 |
| 기타 특징 | 자동 주소 설정 (stateless), Anycast 지원, 헤더 단순화 등 |
| 항목 | 설명 | 특징 |
|---|---|---|
| 정의 | UML의 구조 다이어그램 중 하나로, 관련 요소(클래스, 인터페이스 등)를 패키지 단위로 그룹화하고 그들의 관계를 표현 (geeksforgeeks.org, miro.com) | 복잡한 모델을 모듈화 및 네임스페이스화 |
| 패키지(Package) | UML 요소를 논리적으로 묶는 단위, 폴더 형태로 표현 | 네임스페이스 제공, 중첩 가능 |
| 종속 관계(Dependency) | 한 패키지가 다른 패키지 기능에 의존할 때 점선 화살표로 표시 | 패키지간 영향 분석 가능 |
| <<import >> | 대상 패키지의 이름 또는 요소를 자신의 네임스페이스에 포함 | 명시적 가져오기 |
| <<access >> | 대상 패키지의 기능을 참조해서 사용 | 접근 의존성 표현 |
| <<merge >> | 한 패키지가 다른 패키지의 내용을 통합(병합) | 합성, 기능 확장 표현 |
| 사용 목적 | - 복잡한 클래스 구조 단순화 - 레이어/구성 요소 그룹화 - 네임스페이스 명확화 | 대규모 시스템의 관리·가시성 향상 |
| 표현 방식 | 탭(folder) 모양 박스로 패키지 표시, 점선 화살표로 관계 표현 | 시각적 이해 용이 |
| 중첩 및 계층구조 | 패키지 안에 다른 패키지 포함 가능 | 계층적 모듈 구조 표현 가능 |
| 항목 | 설명 |
|---|---|
| 즉시 갱신 방식 (Immediate Modification) | 트랜잭션이 진행 중일 때도 **즉시 실제 데이터베이스(DB)**에 변경 내용을 반영하는 방식. 장애에 대비하여 모든 변경 내용을 로그에 저장(Log) |
| 로그 기반 복구 (Log-Based Recovery) | 장애 발생 시, 로그를 이용하여 🔹 Undo: 아직 커밋되지 않은 트랜잭션을 되돌림 🔹 Redo: 커밋된 트랜잭션을 다시 적용 참고: Log based Recovery in DBMS – GeeksforGeeks |
| Redo/Undo 수행 조건 | 즉시 갱신 방식에서는 Redo와 Undo 모두 수행 가능 → 중간 갱신이 있기 때문에 장애 발생 시 복구를 위해 두 작업 모두 필요 |
| 항목 | 설명 |
|---|---|
| 정의 | 네트워크 상에서 흐르는 데이터 패킷을 가로채서(Capture) 분석하는 행위. 합법적(네트워크 분석)·불법적(정보 탈취) 모두 사용됨 (lenovo.com, geeksforgeeks.org) |
| 도구 종류 | 소프트웨어(예: Wireshark, tcpdump), 하드웨어 스니퍼 등 |
| 주요 유형 | 수동 스니핑 (Passive Sniffing): 네트워크를 조작하지 않고 읽기 전용으로 수집 능동 스니핑 (Active Sniffing): ARP 스푸핑 등 공격으로 트래픽을 유도하거나 주입 |
| 취약 대상 | 암호화되지 않은 HTTP, FTP, Telnet, SMTP 등 |
| 공격 예시 | 로그인 정보 탈취, 세션 쿠키 가로챔, DNS/ARP 스푸핑, 악성 코드 주입 |
| 방어 방안 | - 네트워크 암호화 (SSL/TLS, VPN 등) - 불필요한 프로토콜 비활성화 - Promiscuous 모드 탐지(예: Anti‑Sniff, Snort) - 안전한 네트워크 환경 사용 |
| 항목 | Java | Python |
|---|---|---|
| 배열 초기화 여부 | 배열 선언 시 자동으로 **기본값(0, false, null 등)**으로 초기화됨 | 리스트 선언 시 초기화하지 않으면 값이 없음 (에러) |
| 정수형 배열 초기값 | int[] arr = new int[5]; → 0 0 0 0 0 | arr = [0]*5 처럼 명시적으로 초기화 필요 |
| 출력문 예시 | System.out.print(item + " "); | print(item, end=' ') |
| 한 줄 출력 방식 | + " " 또는 printf() 사용 | end=' ' 옵션 사용 |
| 출력 결과 | 각 요소 뒤에 한 칸씩 띄워짐 → 1 2 3 4 | 동일하게 1 2 3 4 형식으로 출력됨 |
| 구문 요소 | 설명 | 예시 |
|---|---|---|
SELECT | 출력할 컬럼을 지정 | 학과, COUNT(*) |
COUNT(*) | 집계 함수로, 각 그룹의 튜플 수를 계산 | COUNT(*) → 행 개수 세기 |
AS | **Alias(별칭)**을 지정하는 키워드 | COUNT(*) AS 학과별튜플수 |
FROM | 데이터를 조회할 테이블 지정 | FROM 학생 |
GROUP BY | 지정한 컬럼(또는 표현식) 기준으로 그룹핑 수행 | GROUP BY 학과 |
| 항목 | 설명 |
|---|---|
❌ WHERE 사용 불가 | GROUP BY 사용 시 조건절은 HAVING 사용 |
✅ GROUP BY 필수 | 집계함수를 사용하면 반드시 그룹 기준이 필요 |
| ✅ 집계 함수 사용 | SUM, COUNT, AVG, MIN, MAX 등 |
| ✅ Alias 사용 | AS 별칭 형식으로 출력 컬럼명 변경 가능 |
| ✅ 세미콜론(;) 생략 가능 | SQL 문장 끝은 보통 ;로 마감하지만 생략해도 실행 가능 |
✅ 문자열은 ' ' 사용 | SQL에서 문자열 리터럴은 단일 따옴표로 감쌈 |
| 항목 | 내용 |
|---|---|
| 정의 | 내부 사설 IP 주소를 공인 IP 주소로 변환하여 인터넷에 접속할 수 있도록 해주는 기술 |
| 한글 의미 | ‘네트워크 주소 변환’ |
| 주요 기능 | - 사설 IP → 공인 IP 변환 - IP 주소 절약 - 내부 네트워크 보호 |
| 활용 예 | 하나의 공인 IP로 여러 내부 장비가 인터넷 사용 가능 (공유기 사용 시 대표적) |
| 장점 | IP 주소 부족 문제 해결, 보안성 증가 (내부 IP 노출 방지) |
| 단점 | 연결 추적 어려움, 일부 프로토콜(예: VoIP) 호환성 문제 가능 |
| 항목 | 내용 |
|---|---|
| 정의 | 오픈 소스 기반의 분산 컴퓨팅 플랫폼 |
| 주요 기능 | 대용량 데이터를 **분산 저장(HDFS)**하고, 병렬 처리(MapReduce) 수행 |
| 데이터 처리 방식 | 데이터를 여러 노드에 나눠 저장하고, 클러스터 환경에서 병렬 처리 |
| 설계 목적 | 일반 PC급 컴퓨터를 이용해 가상화된 대형 스토리지와 병렬 처리 환경 구축 가능 |
| 핵심 구성 요소 | - HDFS (Hadoop Distributed File System) – MapReduce (구글의 모델 기반 처리 엔진) |
| 개발자 | 더그 커팅(Doug Cutting), 마이크 캐퍼렐라(Mike Cafarella) |
| 적용 분야 | 빅데이터 분석, 로그 수집 및 처리, 기계학습 데이터 전처리 등 |
| 특징 | - 수평 확장성 우수 - 내결함성 제공 - 저가의 장비로 클러스터 구성 가능 |
| 이상 종류 | 설명 | 예시 | 문제점 |
|---|---|---|---|
| 삽입 이상 (Insertion Anomaly) | 필요한 정보가 누락된 상태로 데이터 입력이 불가능한 경우 | 새로운 강좌 등록 시 학생이 없으면 등록이 안 됨 | 데이터 추가가 제약됨 |
| 삭제 이상 (Deletion Anomaly) | 일부 데이터를 삭제하면 원치 않은 관련 정보가 함께 손실됨 | 특정 학생 정보 삭제 → 해당 학생만 수강했던 강좌 정보도 같이 삭제됨 | 정보 손실 발생 |
| 갱신 이상 (Update Anomaly) | 같은 내용을 여러 곳 수정해야 할 경우 일부만 수정되어 데이터 불일치 발생 | 학생 주소를 여러 행에서 업데이트 시 일부만 변경되어 주소 불일치 발생 | 데이터 일관성 위배 |
| 항목 | 설명 |
|---|---|
| 정의 | 테스트 대상 전체의 모든 값을 확인하지 않고, 대표적인 샘플에 대한 몇 가지 검증 규칙만으로 결과의 정확성을 판단하는 오라클 유형 (crosslaketech.com) |
| 사용 이유 | 모든 테스트 케이스를 나열하기 어려운 경우에, 전체 데이터 중 일부만 검증하면서 간편하고 빠르게 신뢰 확보 가능 |
| 실행 방법 | - 리스트된 규칙(rule)을 기반으로 - 샘플 데이터를 오라클과 시스템에 동시에 투입 - 두 결과가 일치하는지 비교 |
| 예시 규칙 | - 전체 행 수가 N과 같은가? - 키 값이 연속적인 증가를 보이는가? - 필수 컬럼이 누락되지 않았는가? |
| 장점 | - 복잡한 전체 검증보다 관리가 쉬움 - 오라클 코드가 단순하면 유지보수 용이 |
| 주의점 | - SUT와 동일한 알고리즘 사용은 피해야 함 (단순 비교용이 아니라 오차 식별용) - 모든 값을 검사하지 않으므로 보장 범위가 제한적일 수 있음 |
| 항목 | 설명 | 예시 |
|---|---|---|
| 정의 | 입력값 또는 출력값의 영역을 유사한 특징을 가진 ’동치 클래스’로 분할하고, 각 클래스에서 대표값 하나만 테스트하는 블랙박스 테스트 기법 (codezeroman.tistory.com) | 나이 입력(0–100): 유효(0–100), 무효(<0, >100) |
| 목적 | 불필요한 중복 테스트 제거 ✅ 효율성과 커버리지 유지 | 클래스당 하나씩만 테스트 |
| 절차 | ① 입력 도메인 정의 ② 유효/무효 클래스 도출 ③ 대표값 선택 ④ 테스트 케이스 설계 및 실행 | 시험 점수 → 60, 75 등 |
| 동치 클래스 분해 | 전체 범위를 상호 배타적이고, 전체 덮는(clean) 그룹으로 분할 | 시험점수: <0, 0–59, 60–79, …, >100 |
| 대표값 선택 | 각 클래스에서 대표적인 값을 하나 뽑아 테스트 | 유효: 50, 70 등 / 무효: -5, 150 |
| 특징 | - ✳️ 블랙박스 방식 - 내부 알고리즘 몰라도 설계 가능 - 경계값분석과 함께 사용하면 효과 극대 | |
| 적용 범위 | 단위/통합/시스템/인수 테스트 전 레벨에서 사용 가능 |
| 항목 | 설명 |
|---|---|
| 개발 시기/기관 | 1960년대 후반, AT\&T 벨 연구소, MIT, General Electric이 공동 개발 |
| 설계 목적 | **시분할 시스템(Time Sharing System)**을 위한 대화형 운영체제 |
| 언어 기반 | 대부분 C 언어로 작성되어 이식성(다른 시스템으로의 이전)이 높음 |
| 특징 | - 장치 및 프로세스 간 호환성 우수 - 다양한 기기에서 유연한 운영 가능 |
| 파일 시스템 | 트리(Tree) 구조의 계층적 파일 시스템 채택 |
| 철학 | “작고 단순한 프로그램을 조합해 강력한 기능을 만든다” (도구 철학) |
| 대표 유닉스 계열 | AIX, HP-UX, Solaris, BSD 등 |
| 현대 영향 | 리눅스, macOS, Android의 기반 철학에 큰 영향 |
| 항목 | 설명 |
|---|---|
| 정의 | P2P 네트워크에서 온라인 금융 거래 정보를 분산 저장하는 기술로, 중앙 서버 없이 여러 노드가 공동 유지하는 분산 원장(Distributed Ledger) (wired.com) |
| 구조 | 거래 데이터는 블록(Block) 단위로 **암호화(hash)**하여 연결(chain), 변경 불가능하도록 설계됨 |
| P2P 네트워크 | 블록체인은 탈중앙화된 P2P 네트워크 위에서 작동하며, 각 참여 노드들은 거래 기록 사본을 보관하고 공유 |
| 합의 알고리즘 | 네트워크 노드 간 거래 유효성 검증을 위한 합의 프로토콜(Proof‑of‑Work, Proof‑of‑Stake 등) 사용 |
| 주요 특징 | - 변조 방지(Immutable): 블록 변경 불가 - 투명성 & 신뢰성 확보 - 보안성: 공개키/비밀키 기반 암호화 |
| 대표 사용 사례 | 암호화폐(비트코인, 이더리움), 금융·보험·공공· 공급망 추적, 스마트 계약(DeFi 포함) |
| 구성 요소 | 블록, 거래(transaction), 해시, Merkle Tree, 노드, 합의 메커니즘 |
| 상태 번호 | 상태 이름 | 설명 | 전이 조건 |
|---|---|---|---|
| ① | 준비 상태 (Ready) | CPU 할당을 기다리는 상태. 프로세스는 메모리에 올라가 있으며 실행 대기 중 | Job 스케줄러 → Dispatch에 의해 실행 상태로 이동 |
| ② | 실행 상태 (Running) | CPU를 할당받아 실제 명령어를 수행 중인 상태 | - I/O 요청 → → 대기 상태 - Time-out → → 준비 상태 - 작업 완료 → → 종료 |
| ③ | 대기 상태 (Waiting, Blocked) | 입출력 완료 등 외부 이벤트를 기다리는 상태 | 이벤트 완료 시 → 깨움(Wake up) → 준비 상태로 복귀 |
| 항목 | 설명 | 대응 방안 & 예시 |
|---|---|---|
| 정의 | 권한 있는 사용자 또는 시스템이 필요할 때 원하는 데이터나 DB에 접근 가능해야 하는 속성 (datasunrise.com) | - 서버 다운·디스크 고장 시에도 서비스 연속성 유지 - 예: 은행 입출금, 웹 서비스 등 |
| 중요성 | 업무 중단을 방지하고, 기업 운영과 신뢰, 서비스 품질 유지를 위한 핵심 요소 | - 홈페이지 24/7 서비스 - 재해복구 및 백업 정책 |
| 위협 요인 | 하드웨어 오류, 전원·네트워크 중단, DDoS 공격, 소프트웨어 버그 등 | - 예: DB 서버 마비 시 모든 트랜잭션 중단 |
| 대응 전략 | - 이중화/클러스터 구성 - 장애 조치(Failover) 및 자동 전환 시스템 구축 | - 마스터-슬레이브, 멀티마스터 복제 - RAID, 백업, 핫 스왑 |
| 표준 모범 | - HA 클러스터: 장애 발생 시 자동으로 다른 노드로 서비스 이행 - CAP 이론: 분산 환경에서 P(Partition) 발생 시 가용성과 일관성 간의 균형 필요 (en.wikipedia.org) | - AWS RDS 다중 AZ, 쿠버네티스 |
| 구체 방안 | - 백업+복원 - 네트워크 재연결, UPS 전원 등 인프라 준비 | - 일일/시간 단위 백업 - 무정전 전원 |
| 비즈니스 영향 | 가용성 저하 시 서비스 중지, 고객 이탈, 데이터 유실, 재정 손실, 평판 악화로 이어짐 | - e‑commerce 마비 → 매출 급감 |
| 관련 용어 | - Fault Tolerance: 장애 발생해도 서비스 유지 - High‑Availability Cluster: 최소 다운타임 시스템 구성 (en.wikipedia.org) | - 99.99% 가용성 목표 |