| 항목 | 설명 |
|---|---|
| 정수 크기 (C언어) | 정수형은 4바이트(32비트) 사용 |
| 정수 2진수 표현 | 29 → 00000000 00000000 00000000 00011101 |
| 비트 이동 | 29를 왼쪽으로 2비트 이동 시, 오른쪽 빈 자리(패딩 비트)는 0으로 채움 |
| new (Java) | 객체 생성 예약어 → heap 영역에 공간 할당 |
| 객체 선언만 한 경우 | heap에 할당되지 않고 stack에 이름만 존재 → 사용 불가 |
| 항목 | 설명 |
|---|---|
| LRU 기법 | Least Recently Used: 가장 오래된 미사용 페이지를 교체 |
| 배열 뒤집기 반복문 | for(int i =0, j=len-1; i<j; i++, j--) |
| 항목 | 설명 |
|---|---|
| 자식 생성자 호출 순서 | 자식 생성자 먼저 → 내부적으로 super()로 부모 생성자 호출 |
super() 명시 여부 | 명시하지 않아도 컴파일러가 자동 삽입 (생성자 첫 줄에 super() 추가) |
| 부모 = new 자식() | 부모 타입 참조 변수에 자식 객체 할당 시 → 업캐스팅(형 변환) 발생 |
| 항목 | 설명 |
|---|---|
| 메서드 오버로딩 | 메서드명이 같아도 매개변수 타입이 다르면 다른 메서드로 간주됨 |
| 메서드 형변환 | 메서드에 형변환이 적용되어도 시그니처가 다르면 다른 메서드 |
| 항목 | 설명 |
|---|---|
isdigit() | 인수가 숫자이면 true 반환 |
SQL의 AND 연산자 | AND의 우선순위는 OR보다 높다 |
| 항목 | 설명 |
|---|---|
| 프로토콜 종류 | 링크 상태 라우팅 프로토콜 (Link State Routing Protocol) |
| 등장 배경 | RIP의 한계(홉 수 제한, 느린 수렴 등)를 해결하기 위해 등장 |
| 경로 탐색 알고리즘 | Dijkstra 알고리즘(최단 경로 우선 알고리즘) 사용 |
| 사용 환경 | 대규모 네트워크에서 주로 사용 |
| 라우팅 방식 | 전체 네트워크 토폴로지를 기반으로 최단 경로 계산 |
| 링크 상태 반영 방식 | 링크 상태 변화 시 즉시 반영하여 라우팅 정보 갱신 |
| 계층적 구조 | Area 단위로 네트워크를 분리하여 라우팅 효율성 향상 |
| IP 프로토콜 번호 | 89 |
| 내부/외부 구분 | 내부 라우팅 프로토콜 (IGP) |
| 인증 지원 여부 | 네트워크 보안을 위해 라우터 간 인증 기능 지원 가능 |
| 정규형 | 정의/조건 | 목적 | 예시 설명 |
|---|---|---|---|
| 제1정규형 (1NF) | 모든 속성 값이 **원자값(Atomic)**을 가질 것 (중복값, 반복그룹 없음) | 중복 제거, 테이블 기본 구조화 | 주소 필드에 서울/대전 → 분리 필요 |
| 제2정규형 (2NF) | 1NF 만족 + 기본키의 부분적 함수 종속 제거 (복합키인 경우, 모든 속성이 전체 키에 종속되어야 함) | 부분 종속 제거, 서브 테이블 분리 | (주문번호, 제품번호) → 제품명은 제품번호에만 종속 → 분리 |
| 제3정규형 (3NF) | 2NF 만족 + 이행적 함수 종속 제거 즉, 기본키 → A → B 관계 제거 | 비핵심 속성 간의 종속 제거 (비정규성 해소) | 주문번호 → 고객번호 → 주소 → 주소는 고객 테이블로 분리 |
| 용어 | 설명 |
|---|---|
| 함수적 종속 (A → B) | A 값을 알면 B 값을 유일하게 결정할 수 있음 |
| 이행적 함수 종속 (A → B → C) | A가 B를 결정하고, B가 C를 결정 → A가 C를 결정하지만 직접 종속이 아님 |
| 무손실 분해 | 테이블을 나누더라도 원래의 정보를 잃지 않는 분해 |
| 응집도 종류 | 설명 | 예시 | 평가 |
|---|---|---|---|
| Coincidental (우연적 응집) | 의미 없이 우연히 모인 기능들 | 한 함수에서 로그인, 출력, 수학계산을 모두 처리 | ❌ 가장 낮은 수준 (최악) |
| Logical (논리적 응집) | 유사한 논리적 기능이 하나의 모듈에 묶임 (선택적으로 실행) | 키보드/마우스 입력 처리를 같은 함수에서 if문으로 구분 | ❌ 낮은 응집 |
| Temporal (시간적 응집) | 동일한 시점에 수행되는 작업을 모아놓음 | 시스템 시작 시 초기화 함수에 여러 초기작업 포함 | ❌ 낮은 응집 |
| Procedural (절차적 응집) | 특정 순서로 수행되어야 할 작업들이 포함됨 | 파일 열기 → 처리 → 닫기 작업이 같은 함수 안에 있음 | ⚠️ 중간 수준 |
| Communicational (통신적 응집) | 동일한 데이터 구조를 공유하는 기능들이 포함됨 | 동일한 고객 정보 구조를 읽고/저장/검증하는 기능들 | ✅ 꽤 좋은 응집 |
| Sequential (순차적 응집) | 한 기능의 출력이 다음 기능의 입력이 되는 경우 | 데이터 읽기 → 처리 → 결과 저장 | ✅ 매우 좋은 응집 |
| Functional (기능적 응집) | 하나의 명확한 기능을 수행하는 데 필요한 요소들만 포함 | 로그인 처리, 수학 계산기 등 명확한 하나의 목적 | ✅ 최고 수준 (이상적) |
| 구분 | Sequential (순차적 응집) | Procedural (절차적 응집) |
|---|---|---|
| 관계 | 한 작업의 출력이 다음 작업의 입력이 됨 | 작업들이 단순히 순서대로 실행되어야 함 |
| 데이터 흐름 | ✅ 데이터가 흐름 (출력 → 입력) | ❌ 데이터 흐름 없음 (단지 순서) |
| 예시 | readData() → processData(data) → save(data) | openFile(), process(), closeFile() (각 함수 간 데이터 공유 없음) |
| 응집도 강도 | 높음 (실제로 서로 관련된 작업들이 연결됨) | 중간 수준 (관련 있지만 약한 연결) |
| 비유 | 컨베이어 벨트: 하나의 부품이 가공 → 다음 가공 | 스케줄러: 시간 순서대로 정해진 일들을 수행 |
| 분류 | 철학적 목표 (설계 철학) | 핵심 키워드 | 해결하고자 하는 문제 |
|---|---|---|---|
| 생성(Creational) | 객체 생성 방법과 시점을 유연하고 일관성 있게 관리하여 객체 생성을 캡슐화함 | "객체를 어떻게 만들 것인가" | 객체 생성 방식이 코드에 하드코딩되면 재사용과 확장이 어려움 |
| 구조(Structural) | 객체와 클래스 간 구조적 관계를 유연하게 구성하여 유지보수성과 확장성 향상 | "객체를 어떻게 구성할 것인가" | 객체 간 의존성이 강할 때 구조 변경이 어렵고, 유연성이 떨어짐 |
| 행위(Behavioral) | 객체 간의 책임 분산과 효과적인 소통 방식을 설계하여 유연한 동작 흐름 제공 | "객체가 어떻게 상호작용할 것인가" | 복잡한 제어 흐름이나 객체 간 통신 로직으로 인해 결합도가 높아짐 |
| 패턴 유형 | 패턴 이름 | 설명 |
|---|---|---|
| 생성 패턴 | Abstract Factory | 관련된 객체를 생성하는 인터페이스 제공. 구체 클래스 지정 없이 제품군 생성 |
| Builder | 복합 객체의 생성 과정을 분리하여, 동일한 절차에서 다른 표현 가능 | |
| Factory Method | 객체 생성을 하위 클래스에 위임. 부모는 공통 인터페이스만 제공 | |
| Prototype | 기존 객체를 복제(clone)하여 새 객체 생성 | |
| Singleton | 애플리케이션 전체에서 단 하나의 인스턴스만 존재하도록 보장 |
| 패턴 유형 | 패턴 이름 | 설명 |
|---|---|---|
| 구조 패턴 | Adapter | 호환되지 않는 인터페이스를 서로 연결 |
| Bridge | 구현부와 추상부를 분리하여 독립적으로 확장 가능하게 함 | |
| Composite | 객체를 트리 구조로 구성하여 부분-전체 계층 표현 | |
| Decorator | 객체에 동적으로 기능 추가 (상속 대신 구성 사용) | |
| Proxy | 실제 객체 대신 대리 객체로 접근 제어, 성능/보안/지연 로딩 처리 |
| 패턴 유형 | 패턴 이름 | 설명 |
|---|---|---|
| 행위 패턴 | Command | 요청을 객체로 캡슐화하여 실행 취소, 큐잉 등 지원 |
| Interpreter | 문법 규칙을 객체로 표현하여 해석기 구현 | |
| Iterator | 내부 구조와 무관하게 컬렉션 요소를 순차적으로 접근 | |
| Mediator | 객체 간 복잡한 통신을 중재자 객체 하나로 집중 | |
| Observer | 한 객체 상태 변화 시 의존 객체들에게 자동 알림 |
| 조인 종류 | 설명 |
|---|---|
| 자연 조인 (Natural Join) | 두 테이블의 동일한 이름의 컬럼을 자동으로 조인 조건으로 사용하여 결합 |
| 외부 조인 (Outer Join) | 일치하지 않는 행도 포함시킴. LEFT, RIGHT, FULL 등으로 나뉨 |
| 셀프 조인 (Self Join) | 같은 테이블을 두 번 사용하여 자기 자신과 조인하는 방식 |
| 세타 조인 (Theta Join) | =, >, < 등의 비교 연산자를 사용한 일반적인 조인 |
| 동등 조인 (Equi Join) | 두 테이블의 컬럼을 = (동등 조건) 으로 연결하는 조인. 가장 기본적인 조인 형태 |
| 교차 조인 (Cross Join) | 조건 없이 **모든 행을 서로 곱집합(Cartesian Product)**으로 조인 |
| 자동 조인 (Natural Join과 유사) | DBMS에 따라 자동으로 조인 조건을 설정해주는 기능. 자연 조인 또는 동등 조인의 축약형 |
| 조인 종류 | 예시 SQL |
|---|---|
| 자연 조인 | SELECT * FROM A NATURAL JOIN B; |
| 외부 조인 | SELECT * FROM A LEFT OUTER JOIN B ON A.id = B.id; |
| 셀프 조인 | SELECT * FROM EMP E1, EMP E2 WHERE E1.mgr = E2.empno; |
| 세타 조인 | SELECT * FROM A, B WHERE A.value > B.value; |
| 동등 조인 | SELECT * FROM A, B WHERE A.id = B.id; |
| 교차 조인 | SELECT * FROM A CROSS JOIN B; |
| 항목 | 설명 | 예시 |
|---|---|---|
p[i] - 'A' | 대문자 A | 'I' - 'A' = 8 |
+5 | 알파벳을 5칸 시프트 (암호화 시 흔히 사용되는 Caesar Cipher 방식) | 8 + 5 = 13 |
% 25 | 알파벳 범위를 초과하지 않게 순환 처리 (0~24) | (13) % 25 = 13 |
+ 'A' | 숫자를 다시 문자로 복원 | 13 + 'A' = 'N' |
| 🔹 최종 결과 | 'I' → 'N' |
| 항목 | 설명 | 예시 |
|---|---|---|
p[i] - '0' | 문자 '0' | '3' - '0' = 3 |
+3 | 숫자를 3만큼 시프트 (암호화 방식 중 하나) | 3 + 3 = 6 |
% 10 | 한 자리 숫자(0~9) 범위로 유지 | 6 % 10 = 6 |
+ '0' | 숫자를 다시 문자로 복원 | 6 + '0' = '6' |
| 🔹 최종 결과 | '3' → '6' |
| 개념 | 설명 |
|---|---|
char *p | 문자열(문자 배열)을 가리키는 포인터 |
p[i] | 문자열의 i번째 문자 |
| 숫자처럼 생긴 문자 | '1', '9' 등은 실제 숫자가 아니라 문자형 숫자 (char) |
| 커버리지 | 목적 | 기준 | 설명 |
|---|---|---|---|
| Statement (문장 커버리지) | 코드의 각 문장이 최소 한 번 실행되었는지 확인 | 모든 문(statement)이 실행됨 | 가장 기본적인 커버리지 (mathworks.com, en.wikipedia.org) |
| Decision (분기/판단 커버리지) | 모든 분기문이 반드시 true/false로 실행되었는지 확인 | 분기문에서 가능한 모든 결과가 실행됨 | if, while의 분기 결과 모두 실행 |
| Condition (조건 커버리지) | Boolean 표현식 내 각각의 조건이 true/false를 모두 갖는지 확인 | 모든 부분 조건이 각각 true/false 실행됨 | 복합 조건 내부까지 검사 |
| Condition/Decision (C/DC) | 판단과 조건 기준을 모두 만족함 | Decision + Condition 커버리지 모두 충족 | 복합 조건 + 분기 모두 고려 |
| Multiple Condition (다중 조건 커버리지) | 조건의 모든 조합이 실행되었는지 확인 | 조건 조합이 모두 실행됨 | 조합하는 경우의 수가 많아 매우 비효율 |
| MC/DC (Modified C/DC) | 안전성 기준 (항공/자동차 등) 충족용 강화 방식 | - Decision 모든 결과 - 각 조건이 독립적으로 결과에 영향 - 조건 true/false 모두 충족 | 개별 조건이 분기 결과에 독립적으로 영향 |
| All Path (경로 커버리지) | 모든 실행 경로를 통과하도록 테스트 케이스 설계 | 가능한 모든 제어 흐름 경로 실행됨 | 경로 수 많아 현실적으론 불가능 |
| 용어 | 정의 | 한 줄 요약 |
|---|---|---|
| Worm (웜) | 네트워크를 통해 자기 자신을 복제하며 자동 전파되는 악성 코드 | 사용자 개입 없이 스스로 퍼짐 |
| Logic Bomb (논리 폭탄) | 특정 조건(날짜, 상태 등)이 만족될 때 악의적인 행동을 수행하는 코드 | 트리거 조건이 충족되면 작동함 |
| Spyware (스파이웨어) | 사용자 모르게 설치되어 행동 추적, 개인정보 수집을 수행 | 사용자 몰래 정보 수집 |
| Honeypot (허니팟) | 공격을 유도하고 침입 기술/패턴을 분석하기 위한 가짜 시스템 | 공격자 덫으로 사용됨 |
| Bug Bounty | 보안 취약점을 발견한 외부인에게 보상을 제공하는 프로그램 | 화이트 해커 장려 프로그램 |
| Rootkit (루트킷) | 시스템 또는 커널 내부에 숨어, 권한 상승이나 은닉 기능을 수행하는 멀웨어 | 시스템 내부 깊숙이 숨어 악행 |
| Bootkit (부트킷) | 루트킷 변종으로, 부팅 단계(MBR/VBR)에 침투하는 형태의 멀웨어 | 부트 과정을 감염 |
| Ransomware (랜섬웨어) | 파일 암호화 또는 시스템 잠금 후 금전(주로 암호화폐) 요구 | 돈을 요구하는 악성 코드 |
| 용어 | 정의 | 한 줄 요약 |
|---|---|---|
| MITM (Man‑in‑the‑Middle) | 통신 당사자 사이에 공격자가 몰래 끼어들어 메시지를 가로채거나 변조하는 공격 방식 (fortinet.com) | 사용자 모르게 통신 중간에서 도청·변조 |
| Key Logger Attack | 사용자의 키 입력을 몰래 기록해 인증 정보나 민감한 데이터를 탈취하는 공격 | 키 입력을 기록해 비밀번호 등 탈취 |
| SOCIAL ENGINEERING (사회공학 기법) | 인간 심리를 이용해 기만, 안전절차 우회 등으로 정보·권한을 탈취하는 공격 | 사람의 심리를 이용한 속임수 공격 |
| XDR (Extended Detection & Response) | 네트워크·엔드포인트·클라우드 등 여러 보안 계층의 데이터를 통합해 위협을 탐지 및 대응하는 솔루션 | 다양한 보안 계층의 경보를 통합 분석·대응 |
| APT (Advanced Persistent Threat) | 특정 대상을 오랫동안 은밀히 공격해 지속적·정밀한 침투를 시도하는 고도화된 공격 집단 | 오랫동안 은밀히 표적 공격 실행 |
| Teardrop Attack | TCP/IP 재조립 시 버그를 악용해 패킷 분할 조작으로 시스템을 다운시키는 DoS 공격 | 조각난 패킷 재조립 오류로 시스템 다운 |
| SMURFING (Smurf Attack) | IP 스푸핑으로 브로드캐스트로 ICMP 요청을 보내, 네트워크 전체의 응답을 공격 대상에 집중시켜 DoS 유발 | ICMP 스푸핑 브로드캐스트로 트래픽 증폭 후 DoS |
| ATM | 보안 분야보다는 금융 기기(현금인출기)로 알려지며, 네트워크에는 다른 의미 없음. | 금융 자동화기기 (기타 보안 약어 아님) |
| Bootkit 등은 이전에 정리했으므로 여기에 포함하지 않았습니다. 필요 시 다시 추가해드릴게요. |
💡 예시로 비유:
우리가 어떤 자동화 시스템(예: 온라인 쇼핑몰 주문 처리)을 만들고 싶다고 해볼게요.
그 시스템이 하는 일은
주문 입력 → 결제 처리 → 출고 및 배송 같은 과정이 있을 겁니다.
이 과정을 아래처럼 HIPO로 표현합니다:
[ 전체 주문 처리 시스템 ]
└── 입력 : 사용자 주문 정보
└── 처리 : 결제/재고 확인/출고 지시
└── 출력 : 주문 확인서, 출고 요청 등