| 구문 | 설명 |
|---|---|
SELECT name, score | name과 score 컬럼을 조회함 |
FROM 성적 | 성적이라는 테이블에서 데이터를 조회 |
ORDER BY score DESC | score 값을 기준으로 내림차순 정렬함 |
| 항목 | 설명 |
|---|---|
| 객체 변수 / 배열 이름 | 객체 변수나 배열의 시작 주소를 가리킴 |
implements | extends처럼 상속에 사용하는 예약어로, 인터페이스 상속 시 사용 |
| Runnable | 스레드 클래스를 만들 때 사용하는 인터페이스 |
| 인터페이스 개체 | 변수와 메소드를 가질 수 있으며, 역할이 인터페이스로 고정된 클래스와 유사한 개체 |
| 스레드(Thread) | 시스템 자원을 할당받아 실행되는 프로그램의 단위 |
run() 메소드 | Runnable을 구현했다면, 스레드가 수행할 작업 정의 필수 메소드 |
| InterruptedException | 인터럽트로 발생하는 예외를 처리하는 객체이며, Exception으로 대부분의 예외 처리 가능 |
start() 메소드 | 스레드를 시작하며, 내부에서 run() 메소드를 자동 실행 |
| 단계 | 설명 |
|---|---|
| Step 1: 약수 구하기 | 13195를 나눠서 나머지가 0이 되는 수를 찾음 → 1, 5, 7, 13, 29, 65, 91, 145, 203, 455, 1015, 13195 |
| Step 2: 소수 추출 | 약수 중에서 소수만 선택 → 5, 7, 13, 29 (소수: 1과 자기 자신만으로 나누어짐) |
| Step 3: 최댓값 찾기 | 선택된 소수 중 가장 큰 값 → ✅ 29 |
| RAID 레벨 | 구성 방식 | 최소 드라이브 수 | 장점 | 단점 |
|---|---|---|---|---|
| RAID 0 | 스트라이핑 (데이터 분할 저장) | 2 | 용량 전체 활용, 읽기·쓰기 속도 대폭 향상 (techtarget.com, en.wikipedia.org) | 장애 시 전체 데이터 손실 (무중단 성능 지향) |
| RAID 1 | 미러링 (동일 데이터 복제) | 2 | 단일 드라이브 장애시에도 데이터 유지, 읽기 성능 개선 가능 | 저장 효율 50% (드라이브 두 배 필요), 쓰기 속도는 단일 디스크 수준 |
| RAID 5 | 스트라이핑 + 분산 패리티 | 3 | 용량 효율 중간(∼(N−1)/N), 단일 장애 견딤, 읽기 성능 좋음 | 쓰기 시 패리티 연산 오버헤드, 복원 중 재장애 위험 |
| RAID 6 | 스트라이핑 + 이중 분산 패리티 | 4 | 두 개 드라이브 실패 허용, 더 높은 데이터 보호성 | 쓰기 성능 저하 심각, 회복 시간 오래 걸림 |
| RAID 10 (1+0) | 미러링 + 스트라이핑 (미러 배열을 스트라이핑) | 4 | 고속+고신뢰성, 미러 내 하나만 복구하면 됨 | 저장 효율 50%, 드라이브 수 많이 필요 |
| 용어/개념 | 설명 |
|---|---|
| RAID | 여러 개의 하드디스크를 하나의 디스크 배열로 구성하여, 속도 향상 또는 데이터 안정성을 제공하는 기술 |
| 디스크 배열 | RAID를 구성하기 위해 여러 하드디스크를 하나처럼 연결한 구조 |
| 스트라이핑 | 데이터를 블록 단위로 나누어 여러 디스크에 분산 저장하는 방식으로, 읽기/쓰기 속도 향상 효과가 있음 |
| 패리티 | 오류 검출 및 복구를 위한 데이터로, RAID 일부 구성에서 사용됨 (예: RAID 5, 6) |
| RAID 0 | 스트라이핑 방식으로, 2개 이상의 디스크를 병렬 연결하여 속도와 저장 용량을 증가시키지만, 하나라도 손상 시 전체 데이터 손실 발생 |
| 용어 / 개념 | 설명 |
|---|---|
| ROLLBACK / UNDO | 완료되지 않은 트랜잭션을 되돌림(undo). 로그를 참고해 변경 전 상태로 복원(geeksforgeeks.org) |
| REDO | 커밋된 트랜잭션의 변경 사항을 재적용(redrive). 로그를 사용해 손실된 정상 상태 복원 |
| LOG / Transaction Log | 트랜잭션의 시작, 변경 내역, 커밋/롤백 등을 기록한 시스템 로그 파일 |
| COMMIT | 트랜잭션을 정상 종료하고, 변경 내용을 영구 반영. 이후 재실행 가능성 있음 |
| BACKUP | 데이터베이스 전체 또는 일부를 저장해, 장애 시 복원 자료로 사용 |
| CHECKPOINT | 특정 지점의 데이터 상태를 기록. 장애 시 복구 범위 축소 |
| RECOVERY | 시스템 장애 후 UNDO/REDO/LOG/백업/체크포인트 활용하여 일관성 있는 상태로 복원 |
| 용어 | 설명 |
|---|---|
| DBMS 로그(Log) | 트랜잭션의 작업 시작 시점부터 종료 시점까지의 변경 사항을 기록하는 파일. 장애 발생 시 복구에 사용됨 |
| 트랜잭션 시작 (start) | 트랜잭션이 시작되었음을 나타내는 로그 항목 |
| 트랜잭션 완료 (commit) | 트랜잭션이 정상적으로 완료되어 변경 사항을 데이터베이스에 확정했음을 나타내는 로그 항목 |
| REDO | start와 commit 모두 로그에 존재하는 트랜잭션의 작업 내용을 재실행하여 복구하는 방식 |
| UNDO | start는 있으나 commit 로그 항목이 없는 트랜잭션의 작업 내용을 무시하고 되돌리는 방식 |
| 이상 유형 | 설명 | 예시 및 영향 |
|---|---|---|
| 삽입 이상 (Insertion Anomaly) | 새 데이터를 삽입할 수 없는 경우. 관련 정보가 없을 시 삽입 불가. | '코스' 정보를 따로 저장 못하고, 학생이 등록돼야만 코스 테이블에 기록 가능 (medium.com) |
| 삭제 이상 (Deletion Anomaly) | 특정 행을 제거할 때 의도치 않게 다른 중요한 정보도 함께 삭제됨. | 학생 탈퇴 시 그 학생의 유일한 강의 정보도 함께 삭제되어 정보 손실 |
| 갱신 이상 (Update Anomaly) | 중복된 정보를 수정할 때 일관되지 않게 일부만 갱신됨. | 한 학생의 주소 변경 시 일부 레코드만 변경되어 불일치 발생 |
| 메소드 | 역할 | 반환값 및 특이사항 |
|---|---|---|
| pop([i]) | 지정한 위치(i)의 요소를 제거하고 반환 i 없으면 마지막 요소 대상 (docs.python.org) | 제거한 요소 반환, 리스트에서 삭제됨 |
| push() | 파이썬 리스트에는 없음 대신 append() 사용 | – |
| write() | 파일 객체에 문자열을 쓰기 | 쓰인 문자 수 반환 가능 |
| sort() | 리스트를 제자리 정렬 (기본 오름차순) | None 반환 |
| reverse() | 리스트 내부 요소 순서를 반전 | None 반환 |
| extend(iterable) | 다른 반복 가능한 객체의 항목을 뒤에 추가 | 원본 변경, None 반환 |
| index(x) | 값 x가 처음 나타나는 인덱스 반환 | 없는 경우 ValueError |
| copy() | 리스트의 얕은 복사본 반환 | 새로운 리스트 객체 생성 |
| 프로토콜 | 시기 / 표준 | 암호화 방식 & 키 관리 | 주요 보안 기능 및 특징 |
|---|---|---|---|
| WEP | 1997, IEEE 802.11 | RC4 + 고정 IV, CRC‑32 | 취약점 많아 사용 중단됨 |
| WPA (TKIP) | 2003, WPA 초기 도입 | RC4 + per‑packet 키 혼합, 128비트 TKIP 키 (en.wikipedia.org, portnox.com) | WEP보다 향상되었으나 TKIP 자체의 구조적·암호학적 취약점 존재 (MITM·패킷 재생 공격 등) |
| WPA2 (AES‑CCMP) | 2004, 802.11i‑2004 | AES‑128 CCM + CCMP, 강력한 메시지 무결성 | KRACK 등 핸드쉐이크 기반 공격 있으나 패치로 안정화됨 |
| WPA3 (SAE, OWE) | 2018 인증, 2020 의무화 | 개인: AES‑128‑CCM, 기업: AES‑GCM/192비트 SAE(Dragonfly PAKE), PMF, OWE 옵션 지원 | 전방 비밀성(PFS), 오프라인 딕셔너리 공격 방지, 관리 프레임 보호, IoT 연결 개선 |
| 항목 | 설명 |
|---|---|
| 정의 | 무선랜 보안을 위해 사용된 웹 방식의 보안한 데이터 보안 프로토콜이며, 임시 키 무결성 프로토콜이라고도 함 |
| 기존 WEP의 문제점 | 암호 알고리즘이 취약하고, 입력 키 길이 짧으며, 키 관리 방식 미흡 |
| 개선된 방식 | - 암호 알고리즘 개선 - 입력 키 길이를 128비트로 증가 - 패킷당 키 혼합 - 키 재설정과 재사용 제한을 포함한 키 관리 방식 개선 |
| 용어 | 설명 |
|---|---|
| Static Analysis | 실행 없이 정적 코드 분석 수행. 소스코드 구조, 표준 준수, 보안 취약점 등을 검증합니다 (vfunction.com) |
| Dynamic Analysis | 코드 실행 중에 런타임 동작을 분석. 메모리 누수, 성능 병목, 동시성 이슈 등을 찾습니다 |
| Test Execution | 테스트 케이스를 실제 소프트웨어에 실행하여 기능 및 동작 검증을 수행합니다 |
| Test Control | 테스트 진행 과정을 조정 및 제어(예: 시작, 중단, 패러미터 설정)를 담당합니다. |
| Test Harness | 테스트 자동화를 위한 프레임워크 또는 도구 집합으로, 테스트 실행 환경을 구성합니다. |
| Performance | 응답 시간, 처리량, 자원 사용량 등을 측정하여 시스템의 성능 특성을 평가합니다 |
| Test Monitoring | 테스트 실행 중 시스템의 **상태(메모리, CPU, 네트워크 등)**과 로그를 모니터링하여 병목이나 오류를 감지합니다 |
| 프레임워크 | 언어 | 특징 |
|---|---|---|
| JUnit (JUnit 5) | Java | xUnit 계열의 표준 - 애너테이션 기반 테스트 라이프사이클 활용 (@Test, @BeforeEach 등) - IDE/CI 연동 우수(reliasoftware.com, en.wikipedia.org) |
| NUnit | .NET | - .NET용 xUnit 계열 - 데이터 드리븐 테스트, 병렬 실행 지원 |
| pytest | Python | - 간결한 문법과 플러그인 생태계 풍부 (fixtures, parametrize, pytest-mock)- assert 재작성으로 오류 디버깅 쉬움 |
| unittest | Python | - 표준 라이브러리 포함 xUnit 스타일 - TestCase 기반 구조, 호환성과 안정성 우수 |
| Jest | JavaScript | - React/Node 생태계에서 널리 사용 - 제로 설정, 자동 mocking 지원 |
| Mocha | JavaScript | - 유연성과 확장성 높은 테스트 러너 - 비동기 지원, 다양한 assertion 라이브러리와 연동 |
| Jasmine | JavaScript | - BDD 스타일, describe/it 구조- 자체 assertion과 매처 제공 |
| 기법 | 분류 | 설명 |
|---|---|---|
| Equivalence Partitioning | 블랙박스 | 입력 값을 **동일한 그룹(Partition)**으로 나누고, 각 그룹에서 대표값만 테스트해 효율적으로 오류를 찾는 방법 (kavithavcet.files.wordpress.com) |
| Boundary Value Analysis | 블랙박스 | 입력의 **경계값(최소±, 최대±)**을 중심으로 테스트 케이스를 설계하는 기법 |
| Cause–Effect Graph | 블랙박스 | 입력 원인과 출력 결과를 그래프 형태로 나타내어, 테스트 케이스를 설계하는 방식 |
| Base Path Testing | 화이트박스 | 코드의 **제어흐름 그래프(CFG)**를 기반으로 독립 경로들을 찾아 테스트하는 기법 |
| Condition Testing | 화이트박스 | 조건문 내의 불리언 조건들이 모두 참/거짓 값을 가질 수 있도록 케이스 설계 |
| Data Flow Testing | 화이트박스 | 변수의 정의(define)와 사용(use) 흐름을 분석하여 문제 지점을 찾는 방식 |
| 용어 | 설명 |
|---|---|
| 정보 자산 | 조직이 보호해야 할 대상인 정보와 정보가 저장된 하드웨어·소프트웨어 등의 자산 |
| 보호 절차와 대책 | 정보 자산을 안전하게 보호하기 위한 실천적 수단과 방법 |
| 정보보호 관리 체계 | 조직의 정보 자산을 보호하기 위해 정책 수립, 위험 대응, 관리를 수행하는 체계 |
| 정보보호 정책 | 조직의 특성과 환경에 맞춰 수립한 보호 목적 및 방향을 정한 규범 |
| 위험 대응 | 보안 위협 발생 시 이에 신속하게 대응하고 피해를 줄이기 위한 절차 |
| 예방 및 보안 대책 | 위험 발생을 사전에 차단하거나 완화하기 위한 조치 및 기술 |
| KISA (한국인터넷진흥원) | 정보보호 관리 체계 평가 및 인증을 수행하는 국가 기관 |
| 용어 | 의미 |
|---|---|
| ISMS (Information Security Management System) | 조직의 정보자산을 보호하기 위한 종합적인 관리 체계로, 계획 → 구축 → 운영 → 점검을 통해 위험을 관리하고 보안을 유지하는 시스템입니다. (secu.lascom.co.kr, isms.kisa.or.kr) |
| PIMS (Personal Information Management System) | 개인정보보호 관리 체계, 개인정보를 안전하게 처리하기 위한 정책 및 절차 체계입니다. |
| ISMS‑P | ISMS와 PIMS를 통합한 인증제도로, 정보보호와 개인정보보호를 동시에 포함한 관리 체계입니다. 2018년 도입되었으며, 과기정통부와 개인정보보호위원회가 공동 고시합니다. |
| 용어 | 정의 |
|---|---|
| 키 (Key) | 데이터베이스에서 조건에 맞는 튜플을 찾거나 정렬할 때 기준이 되는 속성 |
| 슈퍼키 (Super Key) | 릴레이션 내 속성들의 집합으로 구성된 키. 튜플을 유일하게 식별할 수 있으며, 중복 없음 조건을 만족함 |
| 후보키 (Candidate Key) | 슈퍼키 중에서 최소한의 속성만으로 튜플을 유일하게 식별할 수 있는 키 → 유일성 + 최소성 조건을 모두 만족함 |
| 용어 | 정의 | 예시 (학생 테이블 기준) |
|---|---|---|
| 기본키 (Primary Key) | 테이블에서 각 튜플을 유일하게 식별하는 키. 후보키 중 하나를 선택. | 학번 (ex. 2023001, 2023002) → 중복 ❌, NULL ❌ |
| 슈퍼키 (Super Key) | 튜플을 유일하게 식별할 수 있는 속성들의 집합. 중복 속성 포함 가능. | 학번, 학번+이름, 학번+전화번호, 학번+이메일 등 |
| 후보키 (Candidate Key) | 슈퍼키 중 중복이 없는 최소 속성 집합. 기본키 후보. | 학번, 주민등록번호 → 둘 다 중복 없고, 최소 조건 만족 |
| 외래키 (Foreign Key) | 다른 테이블의 기본키를 참조하는 속성. 관계 연결용. | 수강 테이블의 학생ID → 학생 테이블의 학번 참조 |
| 공격 기법 | 설명 | 대표 사례 / 특징 |
|---|---|---|
| Pharming | DNS 또는 로컬 설정을 변조하여, 사용자를 가짜 사이트로 유도하는 공격 (en.wikipedia.org) | hosts 파일 변경, 라우터 DNS 변조 |
| Phishing | 이메일·메시지를 통해 스미싱·피싱 사이트 접속 유도 후 정보 탈취 | 스피어·보이스 피싱 포함 |
| Drive‑by Download | 사용자가 모르는 사이에 취약한 웹사이트 방문만으로 악성코드 다운로드 | 브라우저 취약점 자동 이용 |
| Watering Hole | 특정 그룹이 자주 방문하는 사이트를 미리 감염시켜, 대상자 감염 유도 | 기업·기관 직원 타깃 |
| Ransomware | 시스템 암호화 후 금전 요구하는 악성코드 | 복구 불가능 시 몸값 지불 |
| Cyber Kill Chain | 침투 과정(정찰→정찰→악성 삽입 등)을 단계별로 분석한 공격 단계 모델 | 공격 흐름 이해 및 방어에 활용 |
| Business Scam | 기업·조직을 표적으로 한 비즈니스 형태의 사기 공격 (CEO 사칭, 가짜 송금 요청 등) | BEC(비즈니스 이메일 사기 포함) |
| Sniffing | 네트워크 트래픽을 도청·패킷 가로채기하여 데이터 수집 | 암호화되지 않은 패킷 대상 |
| 개발 단계 | 설명 | 대응 테스트 단계 | 설명 |
|---|---|---|---|
| 1. 요구사항(Requirements) | 사용자 및 비즈니스 요구 분석 ⟶ Acceptance 테스트 계획 수립 | 인수 테스트 (Acceptance Testing) | 실제 사용자 환경에서 요구사항 충족 여부 검증 (qt.io, geeksforgeeks.org) |
| 2. 분석(System Design) | 시스템 기능과 구조 설계 ⟶ 시스템 테스트 계획서 작성 | 시스템 테스트 (System Testing) | 전체 시스템이 설계된 요구사항을 충족하는지 검증 |
| 3. 설계(Architecture/Module Design) | 모듈 구조 설계 및 인터페이스 정의 ⟶ 통합 테스트 계획 작성 | 통합 테스트 (Integration Testing) | 모듈 간 연계성과 데이터 흐름이 올바른지 확인 |
| 4. 구현(Implementation/Coding) | 실제 코드 작성 및 구현 완료 | 단위 테스트 (Unit Testing) | 각 모듈(함수/클래스)이 설계대로 동작하는지 개별 테스트 |