김민석

CS면접 질문 - 운영체제

민석 개발일지 — Wed, 20 May 2026 19:33:00 +0900

프로세스(Process)와 스레드(Thread)의 차이는 무엇인가요?

프로세스는 독립된 메모리 공간을 가진 실행 단위
스레드는 프로세스 내에서 Stack만 독립적으로 갖고 나머지 메모리는 공유하는 실행 단위
프로세스는 격리성이 높고, 스레드는 자원 공유가 쉽지만 하나가 잘못되면 전체에 영향을 줄 수 있습니다.

스레드는 왜 Stack만 독립적으로 가지나요?
- 스레드는 독립적인 실행 흐름을 가지므로 함수 호출 정보를 저장하는 Stack은 각자 가져야 합니다. Code, Data, Heap은 공유해도 실행에 문제가 없고 오히려 메모리 효율과 통신 속도를 높일 수 있어 공유합니다.
크롬 브라우저는 탭마다 프로세스인가요, 스레드인가요?
- 탭마다 별도 프로세스를 사용합니다. 하나의 탭이 죽어도 다른 탭에 영향을 주지 않는 안정성과 탭 간 메모리 격리를 통한 보안을 위한 설계입니다.
프로세스 간 통신(IPC)은 어떻게 하나요?
- IPC 방법으로는 파이프, 소켓, 공유 메모리, 메시지 큐, 시그널 등이 있습니다. 공유 메모리가 가장 빠르고, 소켓은 다른 머신 간 통신도 가능합니다.

멀티프로세스와 멀티스레드의 장단점을 설명해주세요.

멀티프로세스
- 장점 : 독립된 메모리로 안정성이 높음
- 단점 : Context Switching 비용과 IPC 오버헤드가 큼
멀티스레드
- 장점 : 메모리를 공유해 통신이 빠르고 효율적
- 단점 : 동기화 문제와 한 스레드 오류가 전체에 영향을 줄 수 있음

CPU 코어 수와 스레드 수는 어떤 관계인가요?
- 코어 수만큼만 진짜 병렬 실행이 가능합니다. 스레드가 더 많으면 Context Switching으로 동시에 실행되는 것처럼 보이는 동시성입니다. CPU-bound 작업은 코어 수에 맞추고, I/O-bound 작업은 더 많은 스레드가 유리합니다.

프로세스의 상태(New, Ready, Running, Waiting, Terminated)에 대해 설명해주세요.

프로세스는 생성(New) → 준비(Ready) → 실행(Running) → 대기(Waiting) → 종료(Terminated) 상태를 가집니다.

Running 중 타임슬라이스가 끝나면 Ready로 돌아가고, I/O 요청이 생기면 Waiting으로 전환됩니다. Waiting은 I/O가 완료되면 다시 Ready로 돌아옵니다.

Ready 상태와 Waiting 상태의 차이는 무엇인가요?
- Ready는 CPU만 있으면 즉시 실행 가능한 상태이고, Waiting은 I/O 완료 등 외부 이벤트를 기다리는 상태로 CPU를 줘도 실행할 수 없습니다. 이벤트가 완료되면 Waiting → Ready로 전환됩니다.
좀비 프로세스(Zombie Process)란 무엇인가요?
- 자식 프로세스가 종료됐지만 부모가 종료 상태를 수거하지 않아 PCB가 남아있는 상태입니다. 실행은 끝났지만 프로세스 테이블 자리를 차지해 너무 많아지면 새 프로세스 생성이 불가해집니다.
고아 프로세스(Orphan Process)란 무엇인가요?
- 부모 프로세스가 먼저 종료되어 부모가 없어진 자식 프로세스입니다. Unix/Linux에서는 init 프로세스가 새 부모가 되어 종료 처리를 담당합니다.

CPU 스케줄링 알고리즘에는 어떤 것들이 있나요? (FCFS, SJF, Round Robin 등)

FCFS(선착순) : First Come First Served

SJF(짧은 작업 우선) : Shortest Job First

Round Robin(타임슬라이스 순환)

Priority Scheduling(우선순위) :

FCFS는 단순하지만 Convoy Effect, SJF는 효율적이지만 Starvation 문제가 있습니다. 현대 OS는 공평하고 응답이 빠른 Round Robin을 주로 사용합니다.

선점형과 비선점형 스케줄링의 차이는 무엇인가요?
- 비선점형은 프로세스가 자발적으로 CPU를 놓을 때까지 기다리고, 선점형은 OS가 타임슬라이스나 우선순위에 따라 강제로 CPU를 빼앗습니다. 현대 OS는 응답성이 좋은 선점형을 주로 사용합니다.

교착상태(Deadlock)란 무엇이며, 발생 조건 4가지를 설명해주세요.

1. 상호 배제 (Mutual Exclusion): 자원을 한 번에 하나의 프로세스만 사용 가능

2. 점유와 대기 (Hold and Wait): 자원을 가진 채로 다른 자원을 기다림

3. 비선점 (No Preemption): 다른 프로세스의 자원을 강제로 빼앗을 수 없음

4. 순환 대기 (Circular Wait): 프로세스들이 원형으로 서로의 자원을 기다림

교착상태는 프로세스들이 서로의 자원을 기다리며 무한히 대기하는 상태입니다. 상호 배제, 점유와 대기, 비선점, 순환 대기 4가지 조건이 모두 충족될 때 발생

하나의 조건을 깨는 예방, 안전 상태만 허용하는 회피, 발생 후 회복하는 방법으로 해결할 수 있습니다.

Deadlock과 Starvation의 차이는?
- Deadlock은 프로세스들이 서로 자원을 기다리며 모두 멈추는 상태이고, Starvation은 특정 프로세스만 자원을 계속 못 받아 혼자 못 진행하는 상태입니다. Deadlock은 순환 대기, Starvation은 불공평한 자원 배분이 원인입니다.
실제 OS에서는 Deadlock을 어떻게 처리하나요?
- 대부분의 범용 OS는 Deadlock을 무시하고 발생 시 재시작에 의존합니다. 오버헤드 대비 발생 빈도가 낮기 때문입니다. DB 같은 시스템은 Deadlock을 탐지해 트랜잭션을 롤백하는 방식을 사용합니다.

세마포어(Semaphore)와 뮤텍스(Mutex)의 차이는 무엇인가요?

뮤텍스 : 락을 획득한 하나의 스레드만 접근을 허용하고 락을 획득한 스레드만 해제할 수 있습니다.

세마포어 카운터로 N개까지 동시 접근을 허용하며 누구든 signal()로 해제할 수 있습니다.

뮤텍스는 상호 배제에, 세마포어는 자원 개수 제한이나 순서 동기화에 주로 사용됩니다.

스핀락(Spinlock)이란 무엇인가요?
- 락을 획득할 때까지 루프를 돌며 대기하는 방식입니다. 락 대기 시간이 짧을 때 Context Switching 비용을 아낄 수 있지만, 대기 시간이 길면 CPU를 낭비합니다.
모니터(Monitor)란 무엇인가요?
- 공유 자원과 접근 메서드를 묶어 한 번에 하나의 스레드만 실행되도록 보장하는 고수준 동기화 도구입니다. Java의 synchronized가 모니터 기반으로 동작하며 세마포어보다 사용이 안전하고 편리합니다.
세마포어로 Deadlock이 발생할 수 있나요?
- 발생할 수 있습니다. 두 프로세스가 세마포어를 하나씩 점유한 채 서로의 세마포어를 기다리면 순환 대기가 생겨 Deadlock이 됩니다. 획득 순서를 통일하거나 타임아웃으로 예방합니다.

Race Condition이란 무엇이며 어떻게 해결할 수 있나요?

Race Condition은 여러 스레드가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과가 달라지는 문제
임계 영역에 한 번에 하나의 스레드만 접근하도록 뮤텍스, 세마포어, synchronized 키워드 등으로 해결

임계 영역(Critical Section)의 3가지 조건은 무엇인가요?
- 상호 배제(Mutual Exclusion): 한 번에 하나의 프로세스만 임계 영역에 진입 가능
- 진행(Progress): 임계 영역에 아무도 없으면 진입 희망 프로세스 중 하나는 반드시 진입할 수 있어야 함 (무한 대기 방지)
- 유한 대기(Bounded Waiting): 진입 요청 후 유한한 시간 내에 반드시 진입할 수 있어야 함 (Starvation 방지)

가상 메모리(Virtual Memory)는 왜 필요한가요?

가상 메모리는 RAM이 부족할 때 디스크 일부를 메모리처럼 사용하고, 필요한 페이지만 RAM에 올리는 기술
프로세스마다 독립된 가상 주소 공간을 제공해 메모리 격리도 가능하고, 실제 RAM보다 큰 프로그램 실행도 가능

스왑 영역(Swap Space)이란 무엇인가요?
- RAM이 부족할 때 사용하는 디스크 공간으로, 사용하지 않는 페이지를 디스크로 내리고 필요 시 다시 올립니다. 디스크 접근이라 RAM보다 훨씬 느립니다.
메모리 매핑(Memory Mapping)이란 무엇인가요?
- 파일을 가상 주소 공간에 매핑해 메모리처럼 직접 접근하는 기술입니다. 시스템 콜 없이 파일을 읽고 쓸 수 있고, 프로세스 간 공유 메모리 용도로도 사용됩니다.
스래싱(Thrashing)이란 무엇인가요?
- 페이지 폴트가 너무 자주 발생해 CPU가 페이지 교체만 반복하는 상태입니다. 프로세스가 너무 많아 RAM이 부족할 때 발생하며 CPU 사용률이 오히려 급격히 떨어집니다.

페이징(Paging)과 세그멘테이션(Segmentation)의 차이를 설명해주세요.

페이징은 메모리를 고정 크기로 나눠 외부 단편화가 없지만 내부 단편화가 발생할 수 있음

세그멘테이션은 Code, Stack 등 논리 단위로 가변 크기로 나눠 내부 단편화는 없지만 외부 단편화가 발생

페이지 크기가 크면 어떤 문제가 생기나요?
- 내부 단편화가 심해져 메모리 낭비가 커집니다. 반대로 너무 작으면 페이지 테이블이 커지고 페이지 폴트가 잦아집니다. 보통 4KB를 표준으로 사용합니다.
페이지 테이블이 너무 커지는 문제는 어떻게 해결하나요? (다단계 페이지 테이블)
- 페이지 테이블을 계층적으로 나눠 실제 사용하는 영역의 테이블만 생성합니다. 사용하지 않는 주소 공간의 하위 테이블은 만들지 않아도 되어 메모리를 절약합니다.
세그멘테이션 폴트(Segmentation Fault)란 무엇인가요?
- 프로세스가 접근 권한이 없는 메모리 영역에 접근할 때 발생하는 오류입니다. NULL 포인터 역참조, 배열 범위 초과 등이 원인이며 OS가 프로세스를 강제 종료합니다.

페이지 폴트(Page Fault)가 발생하면 운영체제는 어떻게 동작하나요?

페이지 폴트는 접근하려는 페이지가 RAM에 없을 때 발생하는 인터럽트

OS가 디스크에서 해당 페이지를 RAM으로 올리고, RAM이 가득 찼다면 LRU 같은 교체 알고리즘으로 페이지를 골라 스왑아웃한 뒤 해당 명령어를 재실행

스래싱(Thrashing)을 방지하는 방법은 무엇인가요?
- 워킹셋 모델로 자주 쓰는 페이지를 유지하거나, 동시 실행 프로세스 수를 줄여 각 프로세스에 충분한 메모리를 확보하는 방법이 있습니다.
페이지 폴트가 많이 발생하면 어떤 성능 문제가 생기나요?
- 페이지 폴트마다 디스크 I/O가 발생해 매우 느려집니다. 폴트가 잦아지면 CPU가 페이지 교체만 반복하는 스래싱으로 이어져 전체 시스템 성능이 급격히 저하됩니다.

CS면접 질문 - 컴퓨터 구조

민석 개발일지 — Wed, 20 May 2026 19:02:37 +0900

1. CPU의 구성 요소(ALU, 제어장치, 레지스터)에 대해 설명해주세요.

CPU는 ALU, 제어장치, 레지스터로 구성됩니다.

ALU는 산술·논리 연산을 실제로 수행하고,

제어장치는 명령어를 해석해 각 장치에 신호를 보내는 지휘자 역할을 합니다.

레지스터는 CPU 내부의 가장 빠른 임시 저장 공간으로, PC가 다음 명령어 주소를 가리키는 등 각각 특수한 역할을 담당합니다.

꼬리질문

레지스터, 캐시, RAM의 속도와 용량 차이를 비교해주세요.
- 속도는 레지스터 > 캐시 > RAM, 용량은 그 반대입니다. 빠를수록 CPU에 가깝고 비싸서 용량이 작습니다.
PC(Program Counter)는 언제 업데이트되나요?
- 명령어를 Fetch한 직후 자동으로 다음 주소로 증가하고, jump나 인터럽트 발생 시 특정 주소로 덮어씌워집니다.
ALU가 연산 결과를 어디에 저장하나요?
- 범용 레지스터에 저장하고, 연산 결과의 상태(오버플로우, 0 여부 등)는 플래그 레지스터에 저장됩니다.

2. 프로세스가 실행될 때 메모리에는 어떤 영역(Code, Data, Heap, Stack)이 생성되나요?

프로세스가 실행되면 Code, Data, Heap, Stack 4가지 영역이 생성됩니다.

Code는 실행 명령어, Data는 전역·정적 변수, Heap은 런타임 동적 할당 영역, Stack은 함수 호출 시 지역변수와 리턴 주소를 저장합니다.

Heap은 위로, Stack은 아래로 자라며 서로 침범하면 overflow가 발생합니다.

꼬리질문

전역 변수와 지역 변수는 각각 어느 영역에 저장되나요?
- 전역 변수는 Data 영역에, 지역 변수는 Stack 영역에 저장됩니다. 전역 변수 중 초기화된 것은 Data, 초기화되지 않은 것은 BSS 영역에 들어갑니다.
메모리 누수(Memory Leak)는 어느 영역에서 주로 발생하나요?
- Heap 영역에서 발생합니다. 동적 할당 후 해제하지 않거나 참조를 계속 유지하면 메모리가 반환되지 않아 누수가 생깁니다.
Java와 C에서 메모리 관리 방식이 어떻게 다른가요?
- C는 개발자가 직접 할당·해제를 관리하고, Java는 GC가 참조가 끊긴 객체를 자동으로 해제합니다. Java가 편리하지만 GC 실행 타이밍을 제어하기 어렵다는 단점이 있습니다.

3. Stack 영역과 Heap 영역의 차이점은 무엇인가요?

Stack은 컴파일러가 자동 관리하며 함수 호출 시 지역변수와 리턴 주소를 LIFO 구조로 빠르게 저장·해제합니다.

Heap은 런타임에 개발자가 동적으로 할당하는 영역으로, 크기가 유연하지만 속도가 느리고 메모리 누수 위험이 있습니다.

꼬리질문

Stack Overflow는 왜 발생하나요?
- Stack 영역은 크기가 제한되어 있어서, 재귀 함수처럼 함수 호출이 너무 깊어져 스택 프레임이 한계를 초과하면 Stack Overflow가 발생합니다.
메모리 단편화(Fragmentation)란 무엇인가요?
- 메모리 할당·해제를 반복하면서 중간중간 작은 빈 공간이 흩어져, 총 여유 공간은 충분해도 연속된 공간이 없어 큰 메모리를 할당하지 못하는 현상입니다.

4. 캐시 메모리(Cache Memory)는 왜 사용하며, 지역성(Locality)이란 무엇인가요?

캐시 메모리는 CPU와 RAM의 속도 차이를 줄이기 위한 고속 임시 저장 장치입니다.

지역성 원리를 기반으로 동작
- 시간적 지역성은 최근 접근 데이터를 곧 다시 쓸 가능성이 높다는 것
- 공간적 지역성은 인접 주소 데이터도 곧 접근할 가능성이 높다는 원리

꼬리질문

캐시 라인(Cache Line)이란 무엇인가요?
- 캐시가 메모리에서 데이터를 가져오는 최소 단위(보통 64바이트)입니다. 한 번에 인접 데이터를 묶어 올려 공간적 지역성을 활용합니다.
배열과 링크드리스트 중 캐시 효율이 높은 자료구조는 무엇인가요? 이유는?
- 배열입니다. 연속된 메모리 구조라 캐시 라인에 여러 원소가 한꺼번에 올라오지만, 링크드리스트는 노드가 흩어져 있어 캐시 미스가 자주 발생합니다.

5. 캐시 히트(Cache Hit)와 캐시 미스(Cache Miss)는 무엇인가요?

Cache Hit는 CPU가 필요한 데이터를 캐시에서 찾은 경우
Cache Miss는 캐시에 없어 RAM까지 접근해야 하는 경우
미스가 발생하면 데이터를 캐시 라인 단위로 올려 이후 접근 속도를 높임
히트율을 높이려면 지역성 원리를 고려한 코드 작성이 중요함

꼬리질문

캐시 교체 정책(LRU, FIFO 등)에 대해 설명해주세요.
- 캐시가 꽉 찼을 때 어떤 데이터를 내보낼지 결정하는 정책입니다. 가장 오래 사용 안 된 것을 교체하는 LRU가 시간적 지역성을 잘 반영해 가장 널리 쓰입니다.
이중 for문에서 행 우선 vs 열 우선 접근이 성능에 미치는 영향은?
- 2차원 배열은 행 단위로 연속 저장되므로 행 우선 접근이 캐시 히트율이 높아 성능이 좋습니다. 열 우선 접근은 매번 캐시 미스가 발생해 느립니다.

6. CPU 스케줄링에서 Context Switching이란 무엇이며, 왜 비용이 발생하나요?

Context Switching 과정

인터럽트 또는 시스템 콜 발생
현재 프로세스의 Context를 PCB에 저장
스케줄러가 다음 실행할 프로세스 선택
선택된 프로세스의 Context를 PCB에서 복원
복원된 프로세스 실행

Context Switching은 CPU가 실행 중인 프로세스를 바꿀 때 현재 상태를 PCB에 저장하고 다음 프로세스 상태를 복원하는 작업
PCB 저장·복원 시간과 함께 이전 프로세스가 올려놓은 캐시가 무효화되어 캐시 미스가 증가하기 때문에 비용이 발생
스레드 전환은 메모리를 공유하므로 이보다 비용이 적음

꼬리질문

Context Switching을 줄이는 방법은 무엇인가요?
- 프로세스 대신 스레드를 사용하거나, OS 개입 없이 전환하는 코루틴을 활용하는 방법이 있습니다.
프로세스와 스레드의 Context Switching 비용 차이는 왜 생기나요?
- 프로세스 전환은 메모리 공간이 바뀌어 페이지 테이블과 TLB까지 교체해야 하지만, 스레드는 메모리를 공유해 레지스터 상태만 교체하면 되므로 비용이 더 적습니다.

7. 인터럽트(Interrupt)란 무엇이고, 폴링(Polling)과 어떤 차이가 있나요?

인터럽트는 이벤트 발생 시 장치가 CPU에 신호를 보내 ISR을 실행하는 방식
폴링은 CPU가 장치 상태를 주기적으로 직접 확인하는 방식
인터럽트는 CPU 효율이 높고 반응이 빠르지만 구현이 복잡하며, 폴링은 단순하지만 CPU 자원을 낭비

인터럽트 발생 시 CPU는 어떤 순서로 처리하나요?
- 현재 상태를 저장 → 인터럽트 벡터에서 ISR 주소 확인 → ISR 실행 → 원래 상태 복원 순서로 처리됩니다.
소프트웨어 인터럽트와 하드웨어 인터럽트의 차이는?
- 하드웨어 인터럽트는 외부 장치가 발생시키고, 소프트웨어 인터럽트는 프로그램 내부에서 시스템 콜이나 예외 상황으로 발생합니다.

8. 시스템 콜(System Call)이란 무엇이며 왜 필요한가요?

시스템 콜은 유저 모드 프로그램이 파일 I/O, 네트워크 등 커널 기능을 사용하기 위해 OS에 요청하는 인터페이스
유저 모드에서 직접 하드웨어 접근을 막아 보안과 안정성을 보장
시스템 콜 호출 시 트랩이 발생해 커널 모드로 전환된 후 처리가 완료되면 유저 모드로 복귀합니다.

꼬리질문

커널 모드와 유저 모드를 왜 분리하나요?
- 모든 프로그램이 하드웨어에 직접 접근하면 보안과 안정성이 무너지기 때문입니다. 유저 모드를 분리해 OS를 통해서만 자원에 접근하게 강제합니다.
fork()와 exec()의 차이는 무엇인가요?
- fork()는 현재 프로세스를 복사해 자식 프로세스를 생성하고, exec()는 현재 프로세스를 새 프로그램으로 교체합니다. 보통 fork() 후 자식에서 exec()를 호출하는 패턴으로 사용됩니다.
시스템 콜 호출 비용이 일반 함수 호출보다 비싼 이유는?
- 시스템 콜은 유저 모드에서 커널 모드로 전환하는 과정에서 레지스터 저장, 권한 검사, 스택 전환 등 추가 작업이 발생하기 때문에 일반 함수 호출보다 비쌉니다.

9. 컴파일 과정과 실행 과정을 설명해주세요. (전처리 → 컴파일 → 어셈블 → 링크 등)

1단계: 전처리 (Preprocessing) #include, #define, #ifdef 등 전처리 지시어를 처리합니다. 헤더 파일 내용을 소스에 삽입하고, 매크로를 치환합니다. 결과물: .i 파일 (확장된 C 소스)

2단계: 컴파일 (Compilation) 전처리된 소스 코드를 어셈블리 코드로 변환합니다. 문법 검사, 타입 체크, 최적화 등이 이뤄집니다. 결과물: .s 파일 (어셈블리 코드)

3단계: 어셈블 (Assembly) 어셈블리 코드를 기계어(오브젝트 파일)로 변환합니다. 결과물: .o 파일 (오브젝트 파일). 아직 다른 파일의 심볼(함수, 변수)은 미완성 상태.

4단계: 링킹 (Linking) 여러 오브젝트 파일과 라이브러리를 합쳐 하나의 실행 파일을 만듭니다. 미완성 심볼들의 주소를 연결(심볼 해석)합니다. 결과물: 실행 파일(.exe, ELF 등)

정적 링킹: 라이브러리 코드를 실행 파일에 포함 → 파일 크기 큼, 독립 실행 가능
동적 링킹: 런타임에 공유 라이브러리(.dll, .so)를 참조 → 파일 작음, 라이브러리 필요

컴파일 과정은 전처리 → 컴파일 → 어셈블 → 링킹 순입니다.

전처리는 헤더 삽입·매크로 치환
컴파일은 어셈블리 코드 변환
어셈블은 기계어 오브젝트 파일 생성
링킹은 여러 오브젝트 파일을 합쳐 최종 실행 파일을 만드는 단계

꼬리질문

정적 링킹과 동적 링킹의 차이와 장단점은?
- 정적 링킹은 라이브러리를 실행 파일에 포함시켜 독립 실행이 가능하지만 파일이 크고, 동적 링킹은 런타임에 공유 라이브러리를 참조해 파일이 작지만 라이브러리 의존성이 생깁니다.
인터프리터 언어(Python, JS)는 컴파일 언어와 어떻게 다른가요?
- 컴파일 언어는 실행 전 전체를 기계어로 변환해 빠르고, 인터프리터 언어는 실행 시 한 줄씩 해석해 느리지만 플랫폼 독립적입니다. Java는 바이트코드 + JVM + JIT로 중간 형태입니다.

10. 동기식(Synchronous)과 비동기식(Asynchronous)의 차이를 설명해주세요.

동기는 작업 완료를 기다린 후 다음을 진행하고, 비동기는 완료를 기다리지 않고 다음 작업을 진행하다가 완료 시 콜백 등으로 결과를 받는 방식입니다. 비동기는 I/O 대기 시간에 CPU를 다른 작업에 활용할 수 있어 처리량이 높습니다.

꼬리질문

비동기 방식의 단점은 무엇인가요?
- 코드 흐름이 비선형적이라 가독성과 디버깅이 어렵고, 콜백 중첩으로 콜백 지옥이 생길 수 있습니다. 또한 실행 순서가 보장되지 않아 경쟁 조건 같은 동시성 문제도 발생할 수 있습니다.

11. Blocking과 Non-Blocking의 차이를 설명해주세요.

Blocking/Non-Blocking은 호출된 함수가 호출한 함수의 제어권을 가져가느냐의 문제입니다. 동기/비동기와 혼동하기 쉬우므로 구분이 중요

Blocking 함수를 호출하면 제어권이 호출된 함수로 넘어가고, 작업이 완료될 때까지 호출한 쪽은 아무것도 못 합니다. 결과가 반환될 때 제어권이 돌아옵니다.

Non-Blocking 함수를 호출해도 제어권이 호출한 쪽에 남아있어 다른 작업을 계속할 수 있습니다. 호출된 함수는 즉시 반환(결과가 없으면 없다고 즉시 반환)합니다.

동기/비동기 vs Blocking/Non-Blocking 조합

	Blocking	Non-Blocking
Synchronous	결과 기다리며 대기 (일반적인 함수 호출)	결과 날 때까지 반복 확인 (Busy-wait)
Asynchronous	비효율적 조합 (드묾)	요청 후 다른 일 하다가 완료 통보 받음 (가장 효율적)

### 동기/비동기 vs Blocking/Non-Blocking

두 개념은 비슷해 보이지만 바라보는 관점이 다릅니다.

동기/비동기는 작업의 결과를 언제 처리하느냐의 문제입니다. 동기는 결과가 날 때까지 기다렸다가 처리하고, 비동기는 결과를 기다리지 않고 나중에 콜백이나 이벤트로 처리합니다.

Blocking/Non-Blocking은 함수를 호출했을 때 제어권, 즉 다음 코드를 실행할 권리를 언제 돌려받느냐의 문제입니다. Blocking은 호출한 함수가 완료될 때까지 제어권을 넘겨줘 호출한 쪽이 대기하고, Non-Blocking은 즉시 제어권을 돌려줘 호출한 쪽이 계속 진행할 수 있습니다.

CS면접 질문 - 네트워크

민석 개발일지 — Tue, 12 May 2026 19:11:34 +0900

Q1. OSI 7계층에 대해 각 계층의 역할과 함께 설명해주세요.

OSI 7계층은 네트워크 통신을 표준화한 참조 모델
실제 구현에서는 TCP/IP 4계층으로 단순화되며, OSI는 이론적 참조 모델로 주로 사용
- 1계층 물리는 비트를 전기 신호로 전송
- 2계층 데이터 링크는 MAC 주소로 같은 네트워크 내 전달을 담당
- 3계층 네트워크는 IP 주소로 경로를 결정(라우팅)
- 4계층 전송은 TCP/UDP로 포트 기반의 신뢰성 있는 종단 간 통신을 담당
- 5계층 세션은 연결 세션의 수립과 유지
- 6계층 표현은 암호화·압축·인코딩
- 7계층 응용은 HTTP, FTP 등 사용자와 맞닿는 서비스 프로토콜을 제공

Q. 4계층(전송)과 3계층(네트워크)의 차이가 헷갈리는데요?

3계층은 다른 네트워크까지 어떤 경로로 갈지(IP 기반 라우팅), 4계층은 목적지 호스트 내 어떤 프로세스에게 줄지(포트 기반)를 담당합니다. IP가 집 주소라면, 포트는 그 집의 몇 호실인지에 해당합니다.

Q. SSL/TLS는 몇 계층인가요?

OSI 기준으로는 6계층(표현 계층)에 해당하지만, TCP/IP 모델에서는 4계층(전송)과 7계층(응용) 사이에서 동작하는 것으로 봅니다. 계층 구분이 모델마다 다르기 때문에 "응용 계층과 전송 계층 사이에서 동작한다"고 설명하는 게 더 정확합니다.

Q2. OSI 7계층과 TCP/IP 4계층의 차이점은 무엇인가요?

OSI는 ISO가 만든 이론적 참조 모델이고, TCP/IP는 실제 인터넷 구현에 사용되는 실용적 모델
가장 큰 차이는 계층 수
- OSI는 7계층인데, TCP/IP는 4계층으로 단순화
- OSI의 세션·표현·응용 3계층이 TCP/IP에서는 응용 계층 하나로 통합
- OSI의 물리·데이터링크 계층이 네트워크 접근 계층으로 합쳐집니다.
현재 인터넷은 TCP/IP 모델로 동작, OSI는 네트워크 문제를 계층별로 진단하거나 개념을 설명하는 공통 언어로 여전히 활용

Q3. 캡슐화(Encapsulation)와 역캡슐화(Decapsulation) 과정을 설명해주세요.

캡슐화는 데이터를 송신할 때 상위 계층에서 하위 계층으로 내려가면서 각 계층이 자신의 헤더를 붙여나가는 과정
- 전송 계층은 포트 번호가 담긴 TCP 헤더를
- 네트워크 계층은 IP 헤더를
- 데이터링크 계층은 MAC 헤더를 추가하고
- 물리 계층에서 최종적으로 비트 신호로 변환해 전송
역캡슐화는 수신 측에서 반대로 하위에서 상위 계층으로 올라가며 각 계층이 자신의 헤더를 확인하고 제거하는 과정
- 각 계층은 헤더 정보를 보고 자신에게 온 데이터가 맞는지 확인한 뒤 상위로 넘김
- 중간 장비도 자신이 동작하는 계층까지만 역캡슐화합니다. 스위치는 2계층까지, 라우터는 3계층까지 열어봄

Q4. 네트워크 장비 중 허브, 스위치, 라우터, L7 스위치의 차이를 설명해주세요.

네 장비는 OSI 계층 기준으로 구분

허브는 1계층 장비로 들어온 신호를 모든 포트에 그대로 복사해 전달하며, 충돌이 발생할 수 있어 현재는 거의 사용하지 않음.
스위치는 2계층 장비로 MAC 주소 테이블을 학습해 목적지 포트에만 데이터를 전달하며 LAN 구성에 사용됨.
라우터는 3계층 장비로 IP 주소와 라우팅 테이블을 기반으로 서로 다른 네트워크 간 패킷을 전달하며 인터넷 연결에 사용됨.
L7 스위치는 7계층까지 패킷을 열어 URL, 쿠키, HTTP 헤더 등 콘텐츠 내용을 보고 트래픽을 분산하는 로드밸런서로 사용됨.

Q5. TCP와 UDP의 차이점을 설명하고, 각각 어떤 상황에 사용하는 것이 적합한지 말해주세요.

TCP는 연결 지향 프로토콜로 3-way handshake로 연결을 수립한 뒤 데이터를 전송
- 패킷 손실 시 재전송하고 순서를 보장하는 신뢰성이 핵심
- TCP는 정확성이 중요한 웹 브라우징, 파일 전송, 이메일에 적합

UDP는 비연결 프로토콜로 연결 수립 없이 데이터를 바로 전송하며 손실돼도 재전송하지 않아 빠른 속도가 핵심
- UDP는 약간의 손실보다 지연이 더 치명적인 실시간 스트리밍, 온라인 게임, VoIP, DNS 조회에 적합

Q6. TCP의 3-way Handshake와 4-way Handshake 과정을 설명해주세요. 왜 4-way에서는 한 단계가 더 필요할까요?

3-way Handshake는 TCP 연결 수립 과정
- 클라이언트가 SYN을 보냄
- 서버가 SYN+ACK로 응답
- 클라이언트가 ACK를 보내면 연결이 수립
4-way Handshake는 연결 종료 과정
- FIN → ACK → FIN → ACK 4단계로 이루어짐.
- 종료가 4단계인 이유는, 한쪽이 FIN을 보내도 상대방이 아직 보낼 데이터가 남아있을 수 있기 때문
- 서버는 클라이언트의 FIN에 ACK만 먼저 보내고, 남은 데이터를 다 전송한 뒤에 FIN을 보냄
- ACK와 FIN을 분리해야 하므로 3-way보다 한 단계가 더 필요함

Q. TIME_WAIT 상태가 왜 필요한가요?

클라이언트가 마지막 ACK를 보낸 뒤 바로 종료하면, 그 ACK가 유실됐을 때 서버가 FIN을 재전송해도 받아줄 주체가 없습니다. TIME_WAIT 동안 대기하면서 서버의 재전송 FIN을 받아줄 수 있습니다.

Q7. TCP의 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)의 차이를 설명해주세요.

흐름 제어는 송신자와 수신자 간의 속도 차이를 조절하는 것
- 슬라이딩 윈도우 방식으로, 수신자가 자신의 버퍼 여유 공간을 윈도우 크기로 알려주면 송신자가 그 크기만큼만 전송
혼잡 제어는 송신자와 네트워크 간의 부하를 조절하는 것
- 송신자가 네트워크 상태를 패킷 손실로 간접 추정하며 조절
- 처음엔 슬로우 스타트로 지수적으로 증가시키다가 임계값 이후엔 선형적으로 증가시키고, 패킷 손실이 감지되면 전송량을 줄임.

Q8. TIME_WAIT 상태가 무엇이며, 왜 필요한가요?

TIME_WAIT은 TCP 4-way Handshake에서 능동적으로 연결을 종료한 쪽이 마지막 ACK를 보낸 후 바로 종료하지 않고 2MSL 시간 동안 대기하는 상태

첫째, 마지막 ACK가 유실됐을 때 상대방이 FIN을 재전송하면 받아서 ACK를 다시 보낼 수 있어야 하기 때문
둘째, 이전 연결의 지연 패킷이 새 연결에 섞이는 것을 방지하기 위해 네트워크에서 모든 패킷이 소멸될 때까지 기다리는 것

다만 대규모 서버 환경에서는 TIME_WAIT 소켓이 대량 누적되어 포트 고갈로 이어질 수 있어, Keep-Alive로 연결을 재사용

Keep-Alive 사용

HTTP Keep-Alive로 연결을 재사용
→ 매 요청마다 연결/종료를 반복하지 않음
→ TIME_WAIT 소켓 수 감소

[연결 1번으로 여러 요청 처리]
──연결──▶ 요청1 → 응답1 → 요청2 → 응답2 → 요청3 → 응답3 ──종료──

Q9. HTTP와 HTTPS의 차이점은 무엇이며, HTTPS는 어떻게 보안을 제공하나요?

HTTP는 데이터를 평문으로 전송해서 도청과 변조에 취약
HTTPS는 HTTP에 TLS 암호화 계층을 추가해 기밀성, 무결성, 인증을 보장
HTTPS의 보안 동작 방식
- 먼저 TLS Handshake에서 서버가 CA가 서명한 인증서를 전달하면 클라이언트가 이를 검증해 서버의 신원을 확인
- 이후 비대칭키로 Session Key를 안전하게 교환하고, 실제 데이터는 이 대칭키로 암호화해서 주고받음
- 비대칭키로 키 교환 문제를 해결하고, 대칭키로 빠른 암호화 통신을 하는 방식

Q. HTTPS인데도 보안이 뚫리는 경우가 있나요?

네, 몇 가지 경우가 있습니다. 중간자 공격(MITM)으로 가짜 인증서를 심거나, SSL Stripping으로 HTTPS를 HTTP로 다운그레이드시키거나, 인증기관(CA) 자체가 해킹당하는 경우입니다. 또한 HTTPS는 전송 구간만 암호화하므로, 서버에 도달한 후의 데이터 보안은 별개의 문제입니다.

Q10. HTTP 메서드(GET, POST, PUT, PATCH, DELETE)의 차이를 설명해주세요.

HTTP 메서드는 리소스에 대한 행위를 정의
- GET은 데이터 조회
- POST는 생성
- PUT은 전체 수정
- PATCH는 부분 수정
- DELETE는 삭제에 사용

GET과 POST의 차이 :

GET은 데이터를 URL 쿼리스트링에 담아 캐시 가능하고 멱등하지만 URL에 노출
POST는 바디에 담아 URL에 노출되지 않으며 호출마다 새 리소스를 생성하므로 멱등하지 않음

PUT과 PATCH의 차이:

PUT은 리소스 전체를 교체해서 보내지 않은 필드가 사라짐
PATCH는 보낸 필드만 수정해서 나머지는 유지

일부 필드만 수정할 때는 PATCH가 더 적합함

Q. GET 요청에도 바디를 넣을 수 있나요?

기술적으로는 가능하지만 권장하지 않습니다. HTTP 스펙상 금지는 아니지만, 많은 서버와 프록시가 GET 바디를 무시하거나 거부합니다. Elasticsearch처럼 GET에 바디를 쓰는 예외 케이스도 있지만, 표준적인 REST API에서는 GET 바디 사용을 피하는 것이 좋습니다.

Q. POST로 조회, PUT으로 삭제하면 안 되나요?

기술적으로 동작은 하지만 REST 설계 원칙에 어긋납니다. HTTP 메서드의 의미론(Semantics)을 지키는 것이 API의 가독성, 유지보수성, 캐시/프록시 동작에 중요합니다. 특히 캐시 서버나 미들웨어가 메서드를 기준으로 동작을 결정하므로, 메서드를 잘못 사용하면 예상치 못한 동작이 발생할 수 있습니다.

Q11. HTTP 상태 코드 1xx ~ 5xx의 의미를 설명하고, 자주 보는 코드를 말해주세요.

HTTP 상태 코드는 1xx 정보성, 2xx 성공, 3xx 리다이렉션, 4xx 클라이언트 오류, 5xx 서버 오류로 구분

200(OK) 성공

201(Created) 리소스 생성 성공

204(No Content) 성공이지만 반환 없음

301(Moved Permanently) 영구 이동

304(Not Modified) 캐시 유효

400(Bad Request) 잘못된 요청

401(Unauthorized) 인증 필요

403(Forbidden) 권한 없음

404(Not Found) 리소스 없음

409(Conflict) 충돌

500(Internal Server Error) 서버 내부 오류

502(Bad Gateway 게이트웨이 오류

503(Service Unavailable) 서비스 불가

401과 403의 차이 :

401은 로그인 자체가 안 된 상태고 403은 로그인은 됐지만 해당 리소스에 접근 권한이 없는 상태

Q. 401과 403을 실무에서 어떻게 구분해서 쓰나요?

401은 JWT 토큰이 없거나 만료된 경우, 403은 토큰은 유효하지만 해당 리소스에 접근 권한이 없는 경우에 씁니다. 다만 보안상 공격자에게 리소스 존재 여부를 숨기기 위해 둘 다 404로 통일하거나, 403 대신 404를 반환하는 경우도 있습니다.

Q. 500 에러가 났을 때 상세 에러 메시지를 클라이언트에 보여줘도 되나요?

안 됩니다. 스택 트레이스나 DB 오류 메시지를 그대로 노출하면 내부 구조, DB 종류, 파일 경로 등이 공격자에게 노출되어 보안 취약점이 됩니다. 클라이언트에는 "서버 오류가 발생했습니다" 같은 일반 메시지만 보내고, 상세 로그는 서버 내부에만 기록해야 합니다.

Q. REST API 설계 시 어떤 상태 코드를 써야 할지 헷갈릴 때 기준이 있나요?

기본 원칙은 "HTTP 스펙의 의미에 맞게 쓰기"입니다. 성공은 2xx, 클라이언트 문제는 4xx, 서버 문제는 5xx를 씁니다. 자주 쓰는 패턴은 조회 성공→200, 생성→201, 삭제→204, 유효성 실패→400, 인증→401, 권한→403, 없음→404, 중복→409입니다. 모든 응답을 200으로 통일하고 바디에 성공/실패를 담는 방식은 HTTP 의미론을 무시하는 안티패턴입니다.

Q12. HTTP/1.1, HTTP/2, HTTP/3의 주요 차이점은 무엇인가요?

HTTP/1.1은 텍스트 기반으로 Keep-Alive로 연결을 재사용하지만, 요청을 순차 처리해서 앞 요청이 느리면 뒤 요청이 모두 대기하는 HOL Blocking이 발생하고 헤더를 매번 중복 전송하는 문제가 있음.

HTTP/2는 바이너리 기반으로 멀티플렉싱으로 하나의 TCP 연결에서 여러 요청을 동시에 처리하고, HPACK으로 헤더를 압축합니다. 다만 TCP 패킷 손실 시 모든 스트림이 대기하는 TCP 레벨 HOL Blocking은 남아있음

HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용해 각 스트림을 완전히 독립적으로 처리해 HOL Blocking을 완전히 해결하고, TLS가 기본 내장되어 연결 수립이 빠르며, Connection ID로 네트워크가 바뀌어도 연결을 유지할 수 있습니다.

Q. HTTP/3가 UDP를 쓰면 신뢰성이 없는 거 아닌가요?

UDP 자체는 신뢰성이 없지만, QUIC이 애플리케이션 레벨에서 신뢰성을 직접 구현합니다. 재전송, 순서 보장, 흐름 제어, 혼잡 제어를 모두 QUIC이 처리합니다. 오히려 TCP보다 더 유연하게 구현할 수 있어서 성능이 좋습니다.

Q. 현재 HTTP/3 사용률은 어느 정도인가요?

구글, 유튜브, 페이스북 등 대형 서비스들은 이미 HTTP/3를 사용 중입니다. 크롬, 파이어폭스 등 주요 브라우저도 지원합니다. 다만 일부 방화벽이나 네트워크 장비가 UDP 443 포트를 차단하는 경우 HTTP/2로 폴백되는 경우도 있습니다.

Q13. REST API와 RESTful이란 무엇이며, REST의 6가지 제약 조건은 무엇인가요?

REST는 웹 아키텍처 설계 원칙
이를 따르는 API를 REST API라 함
제약 조건을 잘 지킨 API를 RESTful하다고 함

6가지 제약 조건

클라이언트-서버로 UI와 비즈니스 로직을 분리하고
무상태로 서버가 클라이언트 상태를 저장하지 않음
캐시 가능으로 응답에 캐시 가능 여부를 명시
균일한 인터페이스로 URI로 리소스를 식별하고 HTTP 메서드를 의미에 맞게 사용
계층화 시스템으로 로드밸런서나 게이트웨이 같은 중간 계층을 자유롭게 추가할 수 있고
선택적으로 코드 온 디맨드로 서버가 실행 코드를 전송할 수 있습니다.

실무에서는 HATEOAS 구현이 복잡해 완전한 RESTful보다는 REST 원칙을 최대한 따르는 방향으로 설계

Q14. 대칭키 암호화와 공개키(비대칭키) 암호화의 차이를 설명하고, HTTPS는 이 두 방식을 어떻게 함께 사용하나요?

대칭키 암호화
- 장점 : 암호화와 복호화에 같은 키를 사용해 속도가 빠름
- 단점 : 키를 안전하게 전달하는 키 배송 문제가 있음
비대칭키 암호화
- 장점 : 공개키로 암호화하고 개인키로 복호화해서 키 배송 문제를 해결
- 단점 : 속도가 느립니다.

HTTPS는 두 방식을 조합
- 먼저 비대칭키로 대칭키(Session Key)를 안전하게 교환하고, 이후 실제 데이터 통신은 교환한 대칭키로 빠르게 암호화
- 비대칭키의 안전성과 대칭키의 속도를 모두 확보하는 방식

Q15. SSL/TLS Handshake 과정을 설명해주세요.

TLS Handshake는 TCP 연결 이후 암호화 통신을 위한 준비 과정

TLS 1.2 기준

클라이언트가 ClientHello로 지원하는 TLS 버전과 암호화 방식 목록, 랜덤값을 보내면

서버가 ServerHello로 선택한 방식과 랜덤값을, Certificate로 공개키가 담긴 인증서를 전송

클라이언트는 인증서를 CA로 검증한 뒤 Pre-Master Secret을 서버 공개키로 암호화해서 전송하고

양측이 Client Random, Server Random, Pre-Master Secret으로 동일한 Session Key를 생성

이후 Finished 메시지로 핸드셰이크 무결성을 확인하고 암호화 통신을 시작

TLS 1.3

ClientHello에 키 교환 정보를 포함시켜 1-RTT로 단축하고

RSA 키 교환을 제거해 Perfect Forward Secrecy를 강제.

Q16. CORS(Cross-Origin Resource Sharing)란 무엇이며, 왜 발생하고 어떻게 해결하나요?

CORS는 브라우저의 SOP(동일 출처 정책)를 기반으로, 다른 Origin의 리소스 접근을 제어하는 메커니즘
- Origin은 프로토콜, 호스트, 포트가 모두 같아야 동일 Origin으로 인정
CORS 에러는 브라우저가 다른 Origin으로 요청 시 서버 응답에 Access-Control-Allow-Origin 헤더가 없으면 JS의 응답 접근을 차단하면서 발생
PUT, DELETE나 커스텀 헤더 사용 시엔 실제 요청 전 OPTIONS 메서드로 Preflight 요청을 먼저 보내 서버의 허용 여부를 확인
해결 방법은 서버에서 허용할 Origin을 Access-Control-Allow-Origin 헤더로 명시하거나, 개발 환경에서는 프록시 서버를 사용해 같은 Origin에서 요청하는 것처럼 우회할 수 있음

Q. CORS 에러는 서버가 막는 건가요, 브라우저가 막는 건가요?

브라우저가 막습니다. 서버는 요청을 받아서 응답을 보내지만, 브라우저가 응답 헤더에 Access-Control-Allow-Origin이 없거나 Origin이 불일치하면 JS에서 응답에 접근하는 것을 차단합니다. 그래서 Postman 같은 도구에서는 CORS 에러가 없는 것입니다.

Q. 프록시 서버를 만들어서 우회하는 방식으로 개발할 때 사용한다고 하셨는데, 실제로 악의적인 사용자가 프록시 서버를 만들어 타깃 서버에 요청을 보내는 것도 가능하지 않나요?

네, 기술적으로는 가능합니다. 다만 그렇게 해도 결국 보안은 서버의 인증/인가에서 담보됩니다.
인증이 필요없는 공개 API라면 프록시로 우회가 가능하지만, 애초에 공개 API는 누구나 호출할 수 있는 데이터이므로 보안 문제가 아닙니다. 인증이 필요한 민감한 API라면 프록시 서버가 사용자의 토큰이나 쿠키를 가져올 방법이 없어서 결국 401이 반환됩니다.
따라서 CORS는 브라우저 레벨의 1차 방어선일 뿐이고, 민감한 데이터를 다루는 API는 반드시 인증/인가로 보호해야 합니다. CORS만 믿고 인증 없이 민감한 데이터를 반환하는 API 설계 자체가 잘못된 것입니다.

Q17. 쿠키(Cookie)와 세션(Session)의 차이는 무엇이며, 각각 언제 사용하는 게 좋을까요?

쿠키
- 데이터를 클라이언트(브라우저)에 저장
- 쿠키는 서버 부하가 없고 만료 기간 동안 유지되어 자동 로그인, 사용자 설정 저장에 적합
- 데이터가 클라이언트에 노출되어 민감한 정보 저장에는 부적합
세션
- 데이터를 서버에 저장하고 클라이언트는 Session ID만 보관
- 세션은 민감한 데이터를 서버에서 관리해 보안이 높고 강제 로그아웃이 가능
- 서버 메모리를 사용하고 분산 환경에서 Redis 같은 별도 저장소가 필요

->보안이 중요한 로그인 인증에는 세션을, 장기간 유지해도 되는 설정값이나 자동 로그인에는 쿠키를 사용하는 것이 적합함.

Q18. 브라우저 주소창에 www.google.com을 입력하고 Enter를 누르면 어떤 일이 일어나나요?

① URL 파싱

② 브라우저 캐시 확인

③ DNS 조회 (IP 주소 획득)

④ TCP 연결 (3-way Handshake)

⑤ TLS Handshake (HTTPS)

⑥ HTTP 요청 전송

⑦ 서버 응답 수신

⑧ 브라우저 렌더링

- URL을 파싱해 프로토콜과 도메인을 확인하고, 브라우저/OS DNS 캐시를 먼저 확인합니다.
- 캐시가 없으면 DNS 조회를 통해 로컬 DNS 서버 → Root DNS → .com DNS → google.com DNS 순서로 IP 주소를 얻습니다.
- IP를 얻으면 TCP 3-way Handshake로 연결을 수립하고, HTTPS라면 TLS Handshake로 암호화 채널을 만듭니다.
- 이후 HTTP GET 요청을 보내 HTML을 수신하면, 브라우저가 DOM과 CSSOM을 생성하고 Render Tree를 만들어 화면에 출력합니다.

Q19. JWT(JSON Web Token)란 무엇이며, 세션 기반 인증과 비교했을 때 장단점은 무엇인가요?

JWT는 인증 정보를 Header, Payload, Signature 세 부분으로 나눠 토큰 자체에 담는 방식
서버가 비밀키로 서명하고, 이후 요청마다 서명 검증만으로 인증하므로 DB 조회가 필요 없음

세션 대비 장단점

장점 : 서버에 상태를 저장하지 않아 서버를 자유롭게 확장할 수 있고, 마이크로서비스 환경에서 여러 서비스가 같은 토큰으로 인증할 수 있습니다.

단점 : 한번 발급한 토큰을 만료 전에 강제 무효화하기 어렵다는 점

-> 실무에서는 만료가 짧은 Access Token과 만료가 긴 Refresh Token을 함께 사용해서 보안과 편의성을 모두 챙깁니다. Refresh Token은 서버 DB에 저장해 강제 만료가 필요할 때 삭제하는 방식으로 JWT의 단점을 보완

Q20. DNS의 동작 원리를 설명해주세요. (재귀적 질의, 반복적 질의, 캐싱 포함)

DNS는 도메인을 IP 주소로 변환하는 계층형 분산 시스템
Root DNS, TLD DNS(.com, .kr), 권한 DNS(도메인 소유자 운영) 순서로 계층화되어 있음

조회 방식은 두 가지
- 클라이언트가 DNS Resolver에게 결과만 요청하는 재귀적 질의
- DNS Resolver가 Root → TLD → 권한 DNS를 단계별로 직접 찾아다니는 반복적 질의가 있음

실제로는 클라이언트↔Resolver는 재귀적, Resolver↔각 DNS 서버는 반복적으로 동작
성능을 위해 각 단계에서 TTL 시간 동안 캐싱
- 브라우저 캐시 → OS 캐시 → DNS Resolver 캐시 순서로 확인
- 캐시에 있으면 Root DNS까지 가지 않고 바로 반환합니다.

Q21. IPv4와 IPv6의 차이점은 무엇이며, IPv6가 등장한 이유는 무엇인가요? 서브넷팅에 대해서도 간단히 설명해주세요.

IPv4는 32비트로 약 43억 개의 주소를 제공하는데, 스마트폰과 IoT 기기 폭증으로 2011년 주소가 고갈됨.

-> 이를 해결하기 위해 128비트의 IPv6가 등장했으며 사실상 무한에 가까운 주소를 제공.

IPv6는 주소 확장 외에도 헤더 단순화, IPSec 기본 내장, 브로드캐스트 제거, SLAAC 자동 주소 설정 등이 개선됐음.

다만 IPv4와 직접 호환되지 않아 현재는 듀얼 스택으로 공존 중입니다.

서브넷팅

하나의 큰 네트워크를 서브넷 마스크를 이용해 작은 네트워크로 분할하는 것
/24처럼 CIDR 표기법으로 네트워크 비트 수를 표시하며, 나머지 비트가 호스트 주소가 됨.
부서별 트래픽 분리, IP 주소 효율적 사용, 보안 정책 분리 등을 위해 활용

CS면접 질문 - 자료구조

민석 개발일지 — Wed, 6 May 2026 19:40:14 +0900

1. 자료구조란 무엇이며, 선형 자료구조와 비선형 자료구조의 차이점을 설명해주세요. 각각의 대표적인 예시도 함께 들어주세요.

자료구조 : 데이터를 효율적으로 저장하고 관리하기 위한 구조
선형 자료구조 : 데이터가 순차적으로 나열되어 1:1 관계를 가짐 (배열·스택·큐가 대표적)
비선형 자료구조 : 데이터 간 1:N 또는 N:M 관계로 계층적이거나 망 형태를 가짐 (트리·그래프가 대표적)
선형은 순서 기반 처리에, 비선형은 계층적 관계나 복잡한 연결 관계 표현에 적합

2. 배열(Array)과 ArrayList, LinkedList의 차이점을 설명하고, 각각의 시간 복잡도(접근, 삽입, 삭제)를 비교해주세요. 어떤 상황에서 어떤 자료구조를 선택해야 하나요?

Array : 고정 크기의 연속 메모리 구조로 인덱스 접근이 O(1)이지만 크기 변경이 불가
ArrayList : 내부적으로 배열을 사용하는 동적 배열로, 인덱스 접근은 O(1)이지만 중간 삽입·삭제는 shift가 발생해 O(n)
LinkedList : 노드와 포인터로 연결된 구조로 중간 삽입·삭제가 O(1)이지만, 인덱스 접근은 순회가 필요해 O(n)

조회가 잦으면 ArrayList, 삽입·삭제가 잦은 양 끝 연산이면 LinkedList를 선택.

다만 실제로는 캐시 효율 때문에 ArrayList가 전반적으로 더 빠른 경우가 많음.

Q1. ArrayList는 크기가 꽉 찼을 때 어떻게 동작하나요?

→ 내부적으로 현재 크기의 1.5배짜리 새 배열을 생성하고, 기존 데이터를 전부 복사해. 이 시점에 O(n) 비용이 발생하지만, amortized(분할 상환)하면 평균 O(1)로 봄.

Q2. Java에서 LinkedList가 ArrayList보다 느린 경우가 많은 이유가 뭔가요?

→ LinkedList는 메모리가 불연속적으로 분산되어 있어서 CPU 캐시 효율이 낮음.

ArrayList는 연속 메모리라 캐시 히트율이 높아서 실제로는 더 빠른 경우가 많음.

Q3. ArrayList와 Vector의 차이는 무엇인가요?

→ Vector는 동기화(synchronized) 가 적용된 ArrayList.

멀티스레드 환경에서 안전하지만, 그만큼 성능이 느림.

요즘은 Vector보다 CopyOnWriteArrayList 나 Collections.synchronizedList() 를 더 많이 씀.

Q4. 배열과 ArrayList 중 primitive 타입을 다룰 때 어느 게 효율적인가요?

→ 배열이 효율적.

ArrayList는 제네릭 타입이라 int 같은 primitive를 쓰면 Integer로 오토박싱이 발생해서 메모리와 성능 오버헤드가 생김.

3. 단일 연결 리스트(Singly Linked List), 이중 연결 리스트(Doubly Linked List), 원형 연결 리스트(Circular Linked List)의 차이점과 각각의 장단점을 설명해주세요.

단일 연결 리스트 : next 포인터만 가져 단방향 순회만 가능하고, 메모리가 가장 효율적

이중 연결 리스트 : prev, next 포인터를 모두 가져 양방향 순회가 가능(Java의 LinkedList가 이 방식으로 구현)

원형 연결 리스트 : 마지막 노드가 첫 노드를 가리켜 순환 구조를 형성하며, 라운드 로빈 스케줄링 같은 순환 처리에 활용

선택 기준은 역방향 탐색 필요 여부와 메모리 효율의 트레이드오프로 결정합니다.

Q1. Java의 LinkedList는 어떤 연결 리스트로 구현되어 있나요?

→ 이중 연결 리스트로 구현되어 있어. 그래서 getFirst(), getLast(), addFirst(), addLast() 같은 양방향 연산을 O(1)로 지원해.

Q2. 원형 연결 리스트는 실제로 어디에 쓰이나요?

→ 대표적으로 라운드 로빈 스케줄링 (CPU가 프로세스를 순서대로 돌아가며 실행), 미디어 플레이어 반복 재생, 원형 버퍼(Circular Buffer) 등에 활용돼.

4. 스택(Stack)이 무엇이며 LIFO 구조를 어떻게 활용하나요? 실제 사용 사례(예: 재귀 호출, 괄호 검사, 뒤로 가기)를 들어 설명해주세요.

스택은 LIFO(후입선출) 구조로 가장 마지막에 삽입된 데이터가 먼저 나오는 자료구조.
push, pop, peek 모두 O(1)임
대표적인 활용 사례로는 함수 호출 시 사용되는 콜 스택, 괄호 유효성 검사, 브라우저 뒤로 가기, 실행 취소(Undo) 기능이 있음
Java에서는 Stack 클래스보다 동기화 오버헤드가 없는 ArrayDeque 사용을 권장합니다.

Q1. Stack 클래스 대신 ArrayDeque를 권장하는 이유가 뭔가요?

→ Stack은 Vector를 상속받아 모든 연산에 synchronized가 걸려 있어. 싱글 스레드 환경에서도 불필요한 동기화 비용이 발생해서 느려. ArrayDeque는 동기화가 없고 배열 기반이라 훨씬 빠르고 캐시 효율도 좋아.

5. 큐(Queue)와 스택의 차이점을 설명하고, 일반 큐의 단점을 보완한 원형 큐(Circular Queue)와 연결 리스트 기반 큐의 동작 방식을 설명해주세요.

스택은 LIFO, 큐는 FIFO 구조로 삽입은 rear에서, 삭제는 front에서 일어남
배열 기반 일반 큐는 dequeue 후 앞 공간을 재사용하지 못하는 공간 낭비 문제가 있음.
원형 큐는 (index+1) % size 연산으로 배열을 순환시켜 이 문제를 해결하지만 크기는 여전히 고정.
연결 리스트 기반 큐는 동적으로 크기가 늘어나 크기 제한이 없지만 포인터 오버헤드가 존재.

6. Deque(덱)이란 무엇이며, 스택과 큐로 어떻게 활용될 수 있는지 설명해주세요.

덱은 양쪽 끝에서 삽입과 삭제가 모두 가능한 자료구조로, 모든 연산이 O(1).
한쪽 끝만 사용하면 스택, 한쪽에서 삽입하고 반대쪽에서 삭제하면 큐로 동작.
덱 고유의 활용으로는 슬라이딩 윈도우, 회문 검사 등이 있음.

Q1. ArrayDeque와 LinkedList 기반 덱의 차이는 뭔가요?

→ ArrayDeque는 배열 기반이라 캐시 효율이 좋고 메모리 오버헤드가 적어서 대부분의 경우 더 빠름. LinkedList는 포인터 기반이라 메모리 오버헤드가 있지만 크기 제한이 없고 중간 삽입/삭제가 자유로워. 단순 스택/큐 용도라면 ArrayDeque가 더 효율적이야.

7. 우선순위 큐(Priority Queue)는 무엇이며, 일반 큐와 어떻게 다른가요? 어떤 자료구조로 구현하는 것이 가장 효율적이며 그 이유는 무엇인가요?

우선순위 큐는 FIFO가 아닌 우선순위가 높은 데이터가 먼저 나오는 자료구조.
배열로 구현하면 삽입 또는 삭제 시 O(n)이 발생하지만, 힙으로 구현하면 삽입과 삭제 모두 O(log n), 최솟값 조회는 O(1)로 가장 효율적.
실제로 다익스트라 알고리즘의 최단 경로 탐색, CPU 프로세스 스케줄링 등에 활용.

Java에서는 PriorityQueue 클래스가 내부적으로 최소 힙으로 구현되어 있음

8. 해시 테이블(Hash Table)의 동작 원리와 해시 함수(Hash Function)에 대해 설명해주세요. 평균/최악의 시간 복잡도는 어떻게 되나요?

해시 테이블은 해시 함수로 Key를 배열 인덱스로 변환해서 Value를 저장하는 자료구조
평균 O(1)로 탐색/삽입/삭제가 가능
좋은 해시 함수는 빠른 계산, 균등한 분포, 결정론적 특성을 가져야 함
Java HashMap은 로드 팩터 0.75를 초과하면 배열을 2배로 확장하고 rehashing을 수행
최악의 경우 모든 Key가 같은 인덱스로 해싱되면 O(n)이 발생, 이게 해시 충돌 문제

로드 팩터 (Load Factor)

로드 팩터 = 저장된 데이터 수 / 배열 크기

ex) 데이터 7개, 배열 크기 10 → 로드 팩터 = 0.7

로드 팩터가 높아질수록 충돌 확률이 증가해서 성능이 저하. Java HashMap은 기본 로드 팩터가 0.75이고, 이를 초과하면 배열을 2배로 확장(rehashing).

rehashing:
1. 2배 크기의 새 배열 생성
2. 기존 데이터를 새 배열에 전부 재삽입
3. 해시값이 바뀌기 때문에 전부 다시 계산
→ O(n) 비용 발생! (ArrayList 확장과 비슷한 개념)

Q. 로드 팩터를 너무 낮게 설정하면 어떤 문제가 있나요?

→ 충돌은 줄어들어서 탐색 성능은 좋아지지만, 메모리 낭비가 심해지고 rehashing이 자주 발생해서 오히려 성능이 저하될 수 있어. 0.75가 시간/공간 트레이드오프의 균형점.

9. 해시 충돌(Collision)이란 무엇이며, 이를 해결하는 방법(Chaining, Open Addressing)을 비교 설명해주세요.

해시 충돌은 서로 다른 Key가 같은 인덱스로 해싱되는 현상.
Chaining은 충돌 시 연결 리스트로 데이터를 연결하는 방식으로 구현이 단순하지만 포인터 오버헤드와 캐시 효율 저하가 있음.
- Java HashMap이 이 방식을 사용하며, Java 8부터 버킷 크기가 8 이상이면 Red-Black Tree로 변환해 O(log n)으로 성능을 보완.
Open Addressing은 빈 슬롯을 탐사해서 저장하는 방식으로 메모리 효율과 캐시 효율이 좋지만, 로드 팩터가 1 미만이어야 하고 삭제 시 Tombstone 처리가 필요.

그렇다면 Hash 버킷에서 데이터가 줄어들때 어떻게 되나?

: 트리→리스트 변환 기준은 6개 이하. 8(트리)과 6(리스트) 사이에 버퍼를 둬서 데이터가 경계값 근처에서 왔다갔다할 때 변환이 반복되는 thrashing을 방지해.

10. 트리(Tree) 자료구조의 기본 용어(루트, 부모, 자식, 리프, 깊이, 레벨, 차수)를 설명하고, 트리와 그래프의 차이점은 무엇인가요?

트리는 계층적 구조를 표현하는 비선형 자료구조.
트리와 그래프의 핵심 차이는 트리는 사이클이 없고, 루트가 존재하며, 노드 간 경로가 유일하고, 간선 수가 노드 수 - 1이라는 점.
트리는 그래프의 특수한 형태로, 사이클이 없고 모든 노드가 연결된 그래프가 트리.

Q3. 실생활에서 트리 구조의 예시를 들어주세요.

→ 파일 시스템 (폴더 안에 폴더), 조직도 (대표 → 부서장 → 팀원), HTML DOM 트리 (html → head/body → 각 태그), 댓글의 대댓글 구조 등

11. 이진 트리(Binary Tree)의 종류(완전 이진 트리, 포화 이진 트리, 정 이진 트리)를 설명하고, 트리 순회 방식 4가지(전위, 중위, 후위, 레벨 순회)를 설명해주세요.

포화 이진 트리(Perfect Binary Tree) : 모든 노드가 자식 2개이고 리프가 같은 레벨
완전 이진 트리(Complete Binary Tree) : 마지막 레벨만 왼쪽부터 채워진 구조
정 이진 트리(Full Binary Tree) : 자식이 0개 또는 2개만 존재하는 구조
순회 방식은 전위(루트→왼→오), 중위(왼→루트→오), 후위(왼→오→루트), 레벨 순회(너비 우선) 4가지
- 전위/중위/후위 -> 스택(재귀)
- 레벨 순회 -> 큐를 사용

12. 이진 탐색 트리(BST)의 특징과 핵심 연산의 시간 복잡도를 설명해주세요. BST의 단점과 그 단점이 발생하는 상황은 무엇인가요?

BST는 왼쪽 서브트리의 모든 노드가 부모보다 작고, 오른쪽 서브트리의 모든 노드가 부모보다 큰 이진 트리.
탐색할 때마다 범위가 절반씩 줄어들어 평균 O(log n)이지만, 정렬된 데이터를 순서대로 삽입하면 편향 트리가 되어 최악 O(n)이 됨.
이 편향 문제를 해결하기 위해 삽입/삭제 시 자동으로 균형을 맞추는 AVL Tree와 Red-Black Tree가 등장함.

13. BST 노드 삭제의 3가지 케이스(자식 노드가 없는 경우, 1개인 경우, 2개인 경우)에 대해 설명해주세요.

BST 노드 삭제는 자식 수에 따라 3가지 케이스로 나뉨
자식이 없으면 그냥 제거
자식이 1개면 자식을 삭제된 자리에 연결
자식이 2개면 오른쪽 서브트리의 최솟값(후계자) 또는 왼쪽 서브트리의 최댓값(전임자)으로 대체

14. 균형 이진 탐색 트리(AVL Tree, Red-Black Tree)가 왜 필요한가요? Red-Black Tree의 주요 규칙을 설명해주세요.

BST는 편향 트리가 되면 O(n)으로 성능이 저하되는 문제가 있어서 균형 이진 탐색 트리가 필요
AVL Tree는 Balance Factor를 -1~1로 엄격하게 유지해서 탐색이 빠르지만, 삽입/삭제 시 회전이 빈번해 쓰기 작업이 많으면 비효율적
Red-Black Tree는 색상 규칙으로 느슨하게 균형을 유지해서 삽입/삭제 시 회전이 적고 실무에서 더 많이 쓰입니다.

Java의 TreeMap, TreeSet이 Red-Black Tree로 구현되어 있고, Java 8부터 HashMap의 버킷도 크기가 8 이상이면 Red-Black Tree로 변환

15. 힙(Heap)이란 무엇이며, 최대 힙(Max Heap)과 최소 힙(Min Heap)의 차이점은 무엇인가요? 힙의 삽입과 삭제 과정을 설명해주세요.

힙 : 완전 이진 트리 기반으로 부모-자식 간 대소 관계를 유지하는 자료구조

최대 힙은 부모가 항상 자식보다 크거나 같고, 최소 힙은 항상 작거나 같음
- 삽입 시 마지막 위치에 추가 후 Heapify Up
- 삭제 시 루트를 제거하고 마지막 노드를 루트로 올린 뒤 Heapify Down을 수행
- 둘 다 O(log n)입니다.

루트가 항상 최댓값/최솟값이라 O(1) 조회가 가능해서 우선순위 큐 구현에 사용되고, 힙 정렬에도 활용.

Q1. 힙이 완전 이진 트리여야 하는 이유가 있나요?

→ 완전 이진 트리여야 배열로 빈 공간 없이 표현할 수 있음. 또한 완전 이진 트리 조건을 항상 유지하기 때문에 높이가 항상 O(log n)으로 보장되기 때문에 삽입/삭제의 시간복잡도가 O(log n)이 보장됨.

Q2. 힙과 BST의 차이점은 뭔가요?

→ BST는 왼쪽 < 부모 < 오른쪽 규칙으로 완전한 정렬 구조를 유지하고 탐색에 특화돼 있음. 힙은 부모 >= 자식(또는 <=) 만 보장하고 형제 간 순서는 없음. 힙은 최댓값/최솟값을 빠르게 꺼내는 데 특화돼 있음.

Q3. 힙 생성이 O(n log n)이 아니라 O(n)인 이유는?

→ 하나씩 삽입하면 O(n log n)이지만, 아래에서 위로 Heapify 하는 방식을 쓰면 O(n)이야. 리프 노드는 Heapify가 필요 없고, 위로 올라갈수록 노드 수가 줄어들기 때문에 수학적으로 O(n)으로 수렴.

Q4. 퀵 정렬 대비 힙 정렬의 장단점은?

→ 힙 정렬은 최악에도 O(n log n) 을 보장하고 추가 메모리가 O(1). 퀵 정렬은 평균 O(n log n)이지만 최악 O(n²)이고 추가 메모리가 O(log n) 필요해. 하지만 퀵 정렬이 캐시 효율이 좋아서 실제로는 더 빠른 경우가 많음.

16. B-Tree와 B+Tree의 차이점은 무엇이며, 데이터베이스의 인덱스로 B+Tree가 주로 사용되는 이유를 설명해주세요.

B-Tree : 하나의 노드에 여러 키와 데이터를 저장하는 균형 트리
B+Tree : 내부 노드에 키만 저장하고 실제 데이터는 리프 노드에만 저장하며 리프끼리 연결 리스트로 연결된 구조

DB 인덱스로 B+Tree를 쓰는 이유

리프 노드 연결 리스트로 범위 검색이 빠름
내부 노드에 키만 저장해서 같은 공간에 더 많은 키를 저장할 수 있어 트리 높이가 낮아짐
트리 높이가 낮아서 디스크 I/O 횟수가 최소화됨

Q. B-Tree가 이진 탐색 트리(BST)보다 DB에 적합한 이유는?

→ BST는 노드당 키가 1개라 트리 높이가 높아져서 디스크 I/O가 많이 발생. B-Tree는 하나의 노드에 여러 키를 저장해서 트리 높이가 낮고, 하나의 디스크 블록에 노드 전체를 올릴 수 있어서 I/O 횟수가 훨씬 적음

17. 트라이(Trie) 자료구조란 무엇이며, 주로 어떤 상황에서 활용되나요? (예: 자동완성, 사전 검색) 그래프 / Java Collections / 응용

트라이는 문자열 탐색에 특화된 트리 자료구조
각 노드가 문자 하나를 나타내고 루트에서 노드까지의 경로가 문자열을 표현
삽입과 탐색 모두 문자열 길이 L에만 비례하는 O(L)로, 저장된 문자열 수와 무관하게 빠른 탐색이 가능
자동완성, 검색어 추천, 사전 검색처럼 접두사(prefix) 기반 탐색이 필요한 경우에 주로 활용
단, 노드마다 자식 포인터를 저장해야 해서 메모리 사용량이 크다는 단점

트라이에서 발생하는 오버헤드 - 노드마다 자식 포인터 배열을 유지해야 해서 메모리 사용량이 크다는 단점

18. 그래프(Graph) 자료구조의 표현 방법(인접 행렬 vs 인접 리스트)을 설명하고, 각각의 장단점과 어떤 상황에 적합한지 설명해주세요.

그래프 표현 방법은 인접 행렬과 인접 리스트 두 가지

인접 행렬 : V×V 배열로 간선 존재 확인이 O(1)이지만 공간이 항상 O(V²)라 노드가 많고 간선이 적은 희소 그래프에서 메모리 낭비가 심함
인접 리스트 : 연결된 노드만 저장해서 O(V+E) 공간을 사용하고 탐색이 효율적이라 대부분의 경우에 적합
따라서 밀집 그래프이거나 간선 존재 확인이 잦으면 인접 행렬, 그 외 대부분의 경우엔 인접 리스트를 사용함

19. DFS(깊이 우선 탐색)와 BFS(너비 우선 탐색)의 차이점은 무엇이며, 각각 어떤 자료구조(스택/큐)를 활용하나요? 어떤 상황에서 어떤 알고리즘을 사용해야 하나요?

DFS는 깊이 우선으로 스택(재귀)을 사용, BFS는 너비 우선으로 큐를 사용

둘 다 시간복잡도는 O(V+E)입니다.

DFS는 모든 경로 탐색, 백트래킹, 사이클 감지에 적합
BFS는 가중치 없는 그래프에서 최단 경로 탐색에 적합
BFS가 최단 경로를 보장하는 이유는 레벨 단위로 탐색하기 때문에 목적지를 처음 발견하는 순간이 곧 최단 경로이기 때문

Q. DFS와 BFS의 시간복잡도가 둘 다 O(V+E)인 이유는? → 두 알고리즘 모두 모든 노드(V)를 한 번씩 방문하고, 각 노드에서 모든 간선(E)을 한 번씩 확인하기 때문이야. 인접 리스트 기준이고, 인접 행렬이면 O(V²)야.

20. Java의 Collection Framework에서 List, Set, Map 인터페이스의 차이점과 각각의 대표적인 구현체(ArrayList, LinkedList, HashSet, TreeSet, HashMap, TreeMap)의 특징을 비교 설명해주세요.

Java Collection Framework는 List, Set, Map 인터페이스로 나뉨

List는 순서가 있고 중복을 허용
- ArrayList는 배열 기반으로 조회가 O(1)
- LinkedList는 이중 연결 리스트로 앞뒤 삽입/삭제가 O(1)

Set은 중복을 허용하지 않음
- HashSet은 O(1) 탐색
- TreeSet은 Red-Black Tree 기반으로 정렬을 보장하지만 O(log n)

Map은 Key-Value 쌍으로 저장
- HashMap은 O(1) 탐색, TreeMap은 Key 기준 정렬을 보장.
- 순서 유지가 필요하면 Linked 계열을 사용

Q. HashSet이 내부적으로 HashMap으로 구현된다는 게 무슨 뜻인가요?

→ HashSet은 내부에 HashMap을 가지고 있고, 저장할 값을 HashMap의 Key로 사용. Value는 의미 없는 더미 객체(PRESENT)를 넣음. Key의 중복을 허용하지 않는 HashMap의 특성을 그대로 활용.

21. HashMap과 HashTable, ConcurrentHashMap의 차이점은 무엇이며, 각각 어떤 상황에서 사용해야 하나요? Java 8 이후 HashMap의 내부 구조 변화(Treeify)에 대해서도 설명해주세요.

세 가지 비교

구분	HashMap	HashTable	ConcurrentHashMap
동기화	❌	메서드 전체	버킷 단위
null 허용	Key/Value 모두 ✅	❌	❌
성능	가장 빠름	가장 느림	중간 (실용적)
스레드 안전	❌	✅	✅
사용 시점	단일 스레드	사용 비권장	멀티 스레드
등장 버전	JDK 1.2	JDK 1.0	JDK 1.5

HashMap : 동기화가 없어 단일 스레드에서 가장 빠르고 null Key/Value를 허용

HashTable : 모든 메서드에 synchronized가 적용되어 스레드 안전하지만, 테이블 전체에 락을 걸어 성능이 낮아 현재는 사용을 권장하지 않음

ConcurrentHashMap : 버킷 단위로 락을 걸어 멀티스레드 환경에서도 높은 성능을 보장

Java 8부터는 Segment 방식에서 버킷 단위 락과 CAS 연산으로 변경되어 더욱 효율적

Java 8에서 HashMap은 버킷의 연결 리스트 길이가 8 이상이면 Red-Black Tree로 변환(Treeify)하여 최악의 경우 O(n)에서 O(log n)으로 성능을 개선

hashtable은 컬렉션 프레임워크 이전에 있던 것임

Q1. ConcurrentHashMap에서 null을 허용하지 않는 이유가 있나요?

→ 멀티스레드 환경에서 map.get(key)가 null을 반환했을 때 Key가 없는 건지, Value가 null인 건지 구분이 불가능해. 단일 스레드면 containsKey()로 확인할 수 있지만 멀티스레드에서는 확인하는 사이에 다른 스레드가 값을 바꿀 수 있어서 null 자체를 허용하지 않도록 설계했어.

Q2. ConcurrentHashMap의 버킷 단위 락이 HashTable보다 빠른 이유는?

→ HashTable은 테이블 전체에 락을 걸어서 한 번에 스레드 하나만 접근 가능. ConcurrentHashMap은 버킷 단위로 락을 걸어서 서로 다른 버킷에 접근하는 스레드들은 동시에 작업할 수 있어. 병렬 처리가 가능하니까 훨씬 빠름

CS면접 질문 - 자바

민석 개발일지 — Thu, 9 Apr 2026 21:41:32 +0900

Q. OOP 4대 특징(캡슐화, 상속, 다형성, 추상화)을 설명해 주세요

OOP는 캡슐화, 상속, 다형성, 추상화 네 가지 특징을 가집니다.

캡슐화 : 데이터와 메서드를 하나의 클래스로 묶고, 내부 구현을 숨기는 것입니다. private필드 +getter/setter로 외부 접근을 제어해 객체의 무결성을 보장합니다.
상속 : 부모 클래스의 속성과 메서드를 자식이 물려받는 것으로 코드 재사용성을 높입니다. 단, 부모-자식 간 강한 결합이 생기는 단점이 있습니다.
다형성 : 같은 타입으로 서로 다른 객체를 다룰 수 있는 능력입니다.
- 오버로딩(Overloading) → 컴파일타임 다형성
- 오버라이딩(Overriding) → 런타임 다형성 (동적 바인딩)
추상화 : 복잡한 구현을 숨기고 필요한 인터페이스만 노출하는 것입니다.
- "무엇을 할 수 있는가(What)"에 집중하게 합니다.

Q. SOLID 원칙에 대해 설명해 주세요.

SOLID는 객체지향 설계의 다섯 가지 원칙입니다.

원칙	이름	핵심 내용
S	단일 책임 원칙 Single Responsibility Principle	클래스는 단 하나의 목적을 가져야 하며, 클래스를 변경하는 이유는 단 하나의 이유여야 한다.
O	개방-폐쇄 원칙 Open/Closed Principle	확장에는 열려 있고, 수정에는 닫혀 있어야 한다
L	리스코프 치환 원칙 Liskov Substitution Principle	자식 클래스는 부모 클래스를 완전히 대체할 수 있어야 한다
I	인터페이스 분리 원칙 Interface Segregation Principle	사용하지 않는 메서드에 의존하면 안 된다
D	의존 역전 원칙 Dependency Inversion Principle	추상화에 의존해야 한다 — 스프링 DI가 대표 예시

Q. 추상 클래스와 인터페이스의 차이는 무엇인가요?

둘 다 추상화를 위한 도구인데 목적이 다릅니다.

구분	추상 클래스	인터페이스
구현 포함	O (일부 가능)	X (Java 8+ `default` 제외)
상속/구현 수	단일 상속	다중 구현 가능
상태(필드)	가질 수 있음	가질 수 없음
관계	IS-A	CAN-DO (능력 정의)
사용 시기	공통 상태/구현 공유	관련 없는 클래스에 공통 행동 부여

Java 8 default 메서드가 생긴 이유: 기존 인터페이스에 메서드를 추가하면 모든 구현체를 수정해야 하는 문제를 해결하기 위함. 하위 호환성 유지가 목적입니다.

저는 기본적으로 인터페이스를 먼저 고려하고, 공통 상태나 구현을 공유해야 할 때만 추상 클래스를 씁니다. 인터페이스가 훨씬 유연하기 때문입니다.

인터페이스끼리 default 메서드가 충돌하면 어떻게 되나요?

-> 구현 클래스에서 반드시 오버라이딩해야 합니다. 안 하면 컴파일 에러.

Q. 상속과 컴포지션, 무엇을 선호하나요?

둘 다 코드 재사용 방법이지만 결합도가 다릅니다.

상속 (Inheritance)

IS-A 관계. 부모의 구현을 물려받음
❌ 부모에 강하게 결합 → 부모 변경 시 자식 영향
❌ 캡슐화가 깨질 수 있음

컴포지션 (Composition)

HAS-A 관계. 다른 객체를 필드로 가져 기능을 위임
✅ 인터페이스에만 의존 → 유연성 높음
✅ 런타임에 구현체 교체 가능

GoF 원칙: "Favor composition over inheritance" 명확한 IS-A 관계가 아닌 이상 컴포지션을 우선 선택합니다.

나쁜 예시: Java의 Stack이 Vector를 상속하는 구조 → Stack은 Vector의 모든 메서드를 노출할 필요가 없어서 컴포지션으로 구현했어야 합니다.

상속을 써야 할 때는 언제인가요?

-> 명확한 IS-A 관계이고, 부모 API를 그대로 노출할 의도가 있으며, 부모 변경 가능성이 낮을 때.

Q. equals()와 hashCode()의 관계를 설명해 주세요.

equals() : 두 객체의 논리적 동등성(내용)을 비교합니다. ==은 참조(주소)를 비교, equals()는 값을 비교합니다.
hashCode() : 객체를 정수로 변환한 해시값. HashMap / HashSet 같은 해시 기반 컬렉션에서 버킷을 찾는 데 사용됩니다.

⚠️ 핵심 계약

equals()가 true → hashCode()도 반드시 같아야 한다
(반대는 성립하지 않아도 됨 — 해시 충돌 허용)

이 계약을 어기면 → HashMap에서 같은 키를 찾지 못하는 버그 발생

equals()를 재정의할 때는 반드시 hashCode()도 함께 재정의해야 합니다.

String의 ==과 equals() 차이는?

-> ==은 참조 비교, equals()는 내용 비교. 리터럴은 String Pool에서 같은 참조를 쓰지만 new String()은 항상 새 객체를 만듭니다.

Q. JVM 메모리 구조(Heap, Stack, Method Area)를 설명해 주세요.

Method Area (메서드 영역): 클래스 정보, static 변수, 상수, 메서드 코드가 저장되는 영역입니다.JVM이 클래스를 로드할 때 이곳에 저장되며 모든 스레드가 공유합니다.
Heap (힙): 객체 인스턴스와 배열이 저장되는 영역입니다.GC(가비지 컬렉터)가 관리하며 모든 스레드가 공유합니다.Young/Old Generation으로 나뉩니다.
- Young Generation: 새로 생성된 객체가 저장되는 곳. Minor GC 발생
- Old Generation: Young에서 오래 살아남은 객체가 이동. Major GC 발생
Stack (스택): 메서드 호출 시 스택 프레임이 쌓이는 영역입니다.지역 변수, 매개변수, 리턴 주소가 저장됩니다. 스레드마다 독립적으로 생성됩니다.

GC가 Heap만 관리하는 이유는?

-> Stack은 메서드가 끝나면 자동으로 해제되고, Method Area의 클래스 정보는 명시적으로 언로드되기 때문입니다. 생성/소멸이 예측 불가능한 객체를 담은 Heap만 GC가 관리합니다.

Q. JRE, JDK, JVM의 차이를 설명해 주세요.

세 가지는 포함 관계입니다.

JVM (Java Virtual Machine): 자바 바이트코드를 OS에 맞게 해석하고 실행하는 가상 머신입니다. "Write Once, Run Anywhere"를 가능하게 합니다.
JRE (Java Runtime Environment): JVM + 표준 라이브러리(java.lang, java.util 등)의 묶음입니다. 자바 프로그램을 실행하는 데 필요한 최소 환경입니다.
JDK (Java Development Kit): JRE + 개발 도구(javac 컴파일러, javadoc, debugger 등)의 묶음입니다. 자바 프로그램을 개발할 때 필요합니다.

배포 서버에는 JRE만, 개발 환경에는 JDK가 필요합니다. Java 11부터 JRE 단독 배포가 없어지고 JDK만 제공됩니다.

"Write Once, Run Anywhere"가 어떻게 가능한가요?

-> 자바 소스코드는 OS 독립적인 바이트코드(.class)로 컴파일되고, 각 OS에 맞는 JVM이 이 바이트코드를 해석해서 실행하기 때문입니다.

JIT 컴파일러가 뭔가요?

-> JVM 내부의 최적화 장치입니다. 자주 실행되는 바이트코드를 런타임에 네이티브 코드로 변환해서 성능을 높입니다.

Q. Java 코드가 컴파일되고 실행되는 과정을 설명해 주세요. ClassLoader도 포함해서요.

Java 실행 과정은 크게 컴파일과 실행으로 나뉩니다.

먼저 javac 컴파일러가 .java 파일을 플랫폼 독립적인 바이트코드인 .class 파일로 변환합니다.
실행 시점에는 ClassLoader가 .class 파일을 JVM의 Method Area에 로드합니다.
- ClassLoader는 Loading, Linking, Initialization 세 단계를 거치며 특히 static 변수 초기화와 static 블록 실행이 이 시점에 일어납니다.
로드된 바이트코드는 인터프리터가 한 줄씩 실행하고, JIT 컴파일러가 자주 실행되는 코드를 네이티브 코드로 변환해서 성능을 최적화합니다.

① 소스코드 작성  →  Hello.java
② javac 컴파일  →  Hello.class (바이트코드)
③ ClassLoader   →  .class 파일을 JVM 메모리에 로드
④ Bytecode Verifier  →  바이트코드 유효성 검증
⑤ 인터프리터 / JIT  →  바이트코드를 네이티브 코드로 실행

ClassLoader 역할:.class 파일을 읽어 Method Area에 올리는 역할입니다. 세 단계로 동작합니다.

Loading: .class 파일을 메모리에 읽어들임
Linking: 검증(Verify) → 준비(Prepare) → 분석(Resolve)
Initialization: static 변수 초기화, static 블록 실행

ClassLoader 계층 구조: Bootstrap → Extension → Application 순으로 위임 방식(Delegation)으로 동작합니다.

인터프리터와 JIT의 차이는?

-> 인터프리터는 바이트코드를 한 줄씩 번역해서 실행하고, JIT은 자주 쓰이는 코드를 미리 네이티브 코드로 컴파일해서 캐시합니다. JIT 덕분에 초기 실행 이후 속도가 빨라집니다.

static 블록은 언제 실행되나요?

-> 클래스가 처음 로드될 때 단 한 번 실행됩니다. 인스턴스 생성 이전에 실행되므로 클래스 초기화 용도로 사용합니다.

Java는 Call by Value인가요, Call by Reference인가요?

Java는 항상 Call by Value입니다.

단, 전달되는 "값"이 무엇이냐에 따라 헷갈릴 수 있습니다.

기본형(primitive): 값 자체가 복사되어 전달됩니다.
참조형(reference): 객체의 참조(주소)가 복사되어 전달됩니다. 참조를 통해 객체 내부를 변경하면 원본에 반영되지만, 참조 자체를 다른 객체로 바꿔도 원본 참조는 변하지 않습니다.

기본형

참조형 - 필드 변경

참조형 - 참조 교체

C++의 Call by Reference와 Java의 차이는?

-> C++은 변수 자체의 참조를 전달해서 참조를 교체해도 원본이 바뀝니다. Java는 참조의 복사본을 전달하므로 교체해도 원본에 영향이 없습니다.

Q. Mutable과 Immutable의 차이는 무엇이고, String은 왜 Immutable인가요?

Mutable (가변): 생성 후 상태를 변경할 수 있는 객체. 예) StringBuilder, ArrayList
Immutable (불변): 생성 후 상태를 변경할 수 없는 객체. 예) String, Integer, LocalDate
String이 Immutable인 이유:
1. String Pool 재사용 가능: 같은 문자열을 여러 변수가 공유하는데, 한 곳에서 바꾸면 다른 곳도 영향받으면 안 되기 때문입니다.
2. Thread-safe: 값이 변하지 않으므로 동기화 없이도 멀티스레드 환경에서 안전합니다.
3. HashCode 캐싱: HashMap의 키로 자주 쓰이는데, 값이 불변이어야 해시값도 일관되게 유지됩니다.

String s = "hello";
s = s + " world";  // 새로운 "hello world" 객체 생성, 기존 "hello"는 그대로

→ 반복적인 문자열 연결이 필요하면 StringBuilder (단일 스레드) 또는 StringBuffer (멀티스레드)를 사용합니다.

StringBuilder와 StringBuffer의 차이는?

-> 둘 다 가변 문자열 객체지만, StringBuffer는 메서드에 synchronized가 붙어있어 멀티스레드 환경에서 안전합니다. 단일 스레드에서는 오버헤드가 없는 StringBuilder가 더 빠릅니다.

String + 연산이 느린 이유는?

String은 불변이라 + 할 때마다 새 String 객체가 Heap에 생성됩니다. n번 이어 붙이면 n개의 객체가 생기고 GC 부담도 늘어납니다.

- 연산시 과정내부적으로 이렇게 됨

s = new StringBuilder("hello") .append(" world") .toString(); //← 여기서 new String() 호출
String s = "hello"; s = s + " world";

String Pool이 아닌 일반 Heap에 생성

Q. Java Collection Framework 구조를 설명해 주세요. List, Set, Map의 차이도 포함해서요.

Collection
├── List     순서 O, 중복 O
│   ├── ArrayList
│   ├── LinkedList
│   └── Vector (레거시)
├── Set      순서 X, 중복 X
│   ├── HashSet
│   ├── LinkedHashSet  (입력 순서 유지)
│   └── TreeSet        (정렬 순서 유지)
└── Queue    선입선출
    ├── LinkedList
    └── ArrayDeque  (권장)

Map  (Collection 상속 아님, 별도 계층)
├── HashMap         (순서 X, 빠름)
├── LinkedHashMap   (입력 순서 유지)
└── TreeMap         (키 정렬 순서 유지)

List: 순서가 있고 중복을 허용합니다. 인덱스로 접근 가능합니다.

ArrayList: 내부적으로 배열. 조회 O(1), 중간 삽입/삭제 O(n)
LinkedList: 노드 연결. 중간 삽입/삭제 O(1), 조회 O(n)

Set: 순서가 없고 중복을 허용하지 않습니다. equals()와 hashCode()로 중복 판단합니다.

HashSet: 가장 빠름. 내부적으로 HashMap 사용
TreeSet: 정렬 상태 유지. Red-Black Tree 기반

Map: Key-Value 쌍으로 저장. Key는 중복 불가, Value는 중복 가능합니다.

HashMap: 가장 많이 씀. 평균 O(1) 조회
TreeMap: 키 기준 정렬. O(log n) 조회

Map은 Collection 인터페이스를 상속받지 않습니다. 별도 계층입니다.

ArrayList vs LinkedList 언제 각각 쓰나요?

조회가 많으면 ArrayList, 앞/중간 삽입·삭제가 많으면 LinkedList.

단, 실무에서는 대부분 ArrayList가 더 빠릅니다. LinkedList는 노드마다 포인터를 저장해 메모리도 더 쓰고, 캐시 지역성도 나쁘기 때문입니다.

HashSet이 중복을 어떻게 판단하나요?

hashCode()로 버킷 위치를 찾고, 같은 버킷에 있는 요소와 equals()로 비교합니다. 둘 다 같으면 중복으로 판단해 추가하지 않습니다.

Map이 Collection을 상속받지 않는 이유는?

Collection은 단일 요소를 다루는 인터페이스인데, Map은 Key-Value 쌍을 다루는 구조라 설계가 근본적으로 달라서 별도 계층으로 분리되었습니다.

Q. HashMap의 내부 동작 원리를 설명해 주세요. 충돌은 어떻게 해결하나요?

기본 구조

HashMap은 내부적으로 배열(버킷) + 연결리스트(또는 트리) 구조입니다.

버킷 배열 (기본 크기 16)
index 0  →  null
index 1  →  [Key:"apple", Value:1] → [Key:"apricot", Value:2]  (충돌 시 연결)
index 2  →  null
index 3  →  [Key:"banana", Value:3]
...

put(key, value) 과정

① key.hashCode() 호출          → 정수 해시값 생성
② hash % 배열크기              → 버킷 인덱스 결정
③ 해당 버킷에 저장
   - 비어있으면 바로 저장
   - 이미 있으면 (충돌) → equals()로 키 비교
     - 같은 키면 Value 덮어씀
     - 다른 키면 연결리스트로 이어붙임

충돌 해결 — Separate Chaining

같은 버킷에 여러 요소가 들어오면 연결리스트로 연결합니다.

Java 8부터 연결리스트 길이가 8 이상이 되면 Red-Black Tree로 자동 변환합니다.

연결리스트: O(n) 탐색
Red-Black Tree: O(log n) 탐색

Load Factor & Rehashing

Load Factor = 저장된 요소 수 / 버킷 크기
기본값: 0.75

저장 요소가 전체 버킷의 75%를 넘으면 배열 크기를 2배로 늘리고 모든 요소를 재배치(Rehashing)합니다. 이 작업은 O(n)으로 비용이 크기 때문에, 저장할 데이터 크기를 미리 알면 초기 용량을 지정하는 게 좋습니다.

equals()와 hashCode()를 반드시 같이 재정의해야 하는 이유가 HashMap과 어떻게 연결되나요?

hashCode()가 다르면 버킷 위치가 달라서 같은 키로 넣어도 다른 버킷에 저장됩니다. 꺼낼 때 엉뚱한 버킷을 뒤져서 못 찾는 버그가 생깁니다.

HashMap은 Thread-safe한가요?

아닙니다. 멀티스레드 환경에서 동시에 Rehashing이 일어나면 무한루프가 생길 수 있습니다. Thread-safe가 필요하면 ConcurrentHashMap을 사용합니다.

HashMap의 평균 시간복잡도가 O(1)인 이유는?

해시 충돌이 없다고 가정하면 hashCode()로 버킷을 바로 찾아서 O(1)입니다. 충돌이 많아지면 O(n) 또는 트리화 후 O(log n)으로 떨어집니다.

초기 용량을 설정하면 왜 좋은가요?

Rehashing은 O(n) 비용이 드는 작업입니다. 데이터 크기를 미리 알면 new HashMap<>(initialCapacity)로 지정해서 Rehashing 횟수를 줄일 수 있습니다.

Q. String, StringBuilder, StringBuffer의 차이를 설명해 주세요.

String — Immutable (불변) 한 번 생성하면 값을 변경할 수 없습니다. + 연산 시마다 새 객체가 Heap에 생성됩니다.

String s = "hello";
s = s + " world";  // 새 객체 생성, 기존 "hello"는 GC 대상

StringBuilder — Mutable, Thread-unsafe 내부 버퍼에 문자열을 이어붙입니다. 새 객체를 만들지 않아서 빠릅니다. 단일 스레드에서 사용합니다.

StringBuffer — Mutable, Thread-safe StringBuilder와 동일하지만 메서드에 synchronized가 붙어 있어 멀티스레드 환경에서 안전합니다. 동기화 오버헤드가 있어서 단일 스레드에선 StringBuilder보다 느립니다.

불변 여부	Immutable	Mutable	Mutable
Thread-safe	O	X	O
속도	느림(반복 시)	빠름	중간
사용 상황	변경 없는 문자열	단일 스레드	멀티 스레드

실무에서는 대부분 StringBuilder를 씁니다. 멀티스레드 환경에서 문자열을 공유하는 경우는 드물고, 필요하면 다른 동기화 방식을 씁니다.

Q. Wrapper Class가 무엇이고, AutoBoxing/Unboxing은 어떻게 동작하나요?

Wrapper Class 기본형(primitive)을 객체로 감싼 클래스입니다. 컬렉션은 객체만 저장할 수 있기 때문에 필요합니다.

int    →  Integer
long   →  Long
double →  Double
boolean → Boolean
char   →  Character

AutoBoxing / Unboxing 기본형 ↔ Wrapper 클래스 간 변환을 컴파일러가 자동으로 처리합니다.

// AutoBoxing: int → Integer (컴파일러가 Integer.valueOf(1) 삽입)
Integer a = 1;

// Unboxing: Integer → int (컴파일러가 a.intValue() 삽입)
int b = a;

// 컬렉션에서 자주 발생
List<Integer> list = new ArrayList<>();
list.add(1);      // AutoBoxing
int x = list.get(0);  // Unboxing

주의: Integer 캐싱Integer.valueOf()는 -128 ~ 127 범위의 값을 캐싱합니다.

Integer a = 127;
Integer b = 127;
System.out.println(a == b);   // true  (캐시된 같은 객체)

Integer c = 128;
Integer d = 128;
System.out.println(c == d);   // false (캐시 범위 초과, 새 객체)
System.out.println(c.equals(d)); // true

Wrapper 객체 비교는 항상 equals()를 사용해야 합니다.

Q. GC(Garbage Collection)란 무엇이고, Minor GC와 Full GC의 차이는 무엇인가요?

GC란? 더 이상 참조되지 않는 객체를 자동으로 메모리에서 해제하는 JVM의 메커니즘입니다.

Heap 구조

Heap
├── Young Generation  (새 객체)
│   ├── Eden         (new로 생성된 객체가 처음 위치)
│   ├── Survivor 0
│   └── Survivor 1
└── Old Generation   (오래된 객체)

Minor GC Young Generation이 꽉 찼을 때 발생합니다. Eden의 살아남은 객체를 Survivor로 이동시킵니다. Survivor에서 일정 횟수(기본 15회) 이상 살아남으면 Old Generation으로 이동(Promotion)합니다.

Full GC (Major GC) Old Generation이 꽉 찼을 때 발생합니다. Heap 전체를 검사하므로 Minor GC보다 훨씬 오래 걸립니다. GC 동안 애플리케이션이 멈추는 STW(Stop The World) 가 발생합니다.

Full GC는 애플리케이션을 멈추기 때문에 최대한 발생 빈도를 줄여야 합니다.

Q. Java에서 스레드를 만드는 방법을 설명해 주세요.

방법 1 — Thread 클래스 상속

class MyThread extends Thread {
    @Override
    public void run() {
        System.out.println("Thread 실행");
    }
}
new MyThread().start();

방법 2 — Runnable 인터페이스 구현 (권장)

class MyTask implements Runnable {
    @Override
    public void run() {
        System.out.println("Thread 실행");
    }
}
new Thread(new MyTask()).start();

// 람다로 더 간결하게
new Thread(() -> System.out.println("Thread 실행")).start();

이유 1 — Java는 단일 상속이라서

이유 2 — 역할 분리(Runnable로 작업만 정의해두면, 나중에 실행 방식을 바꿔도 작업 코드를 건드릴 필요가 없음. OCP랑 연결되는 부분)

방법 3 — ExecutorService (실무 권장)

ExecutorService executor = Executors.newFixedThreadPool(4);
executor.submit(() -> System.out.println("Thread 실행"));
executor.shutdown();

Thread를 직접 만드는 것보다 ExecutorService로 스레드 풀을 관리하는 것이 실무 표준입니다. 스레드 생성 비용이 크기 때문에 재사용하는 것이 효율적입니다.

Q. 고유 락(Intrinsic Lock)이란 무엇인가요?

Java의 모든 객체는 고유 락, 즉 모니터 락을 하나씩 가지고 있습니다. synchronized 키워드를 사용하면 해당 객체의 고유 락을 획득하고, 블록을 벗어나면 자동으로 반납합니다.

Java의 모든 객체는 고유 락(모니터 락) 을 하나씩 가지고 있습니다. synchronized 키워드를 사용하면 이 락을 획득/해제하는 방식으로 동기화합니다.

// 메서드 전체에 락
public synchronized void increment() {
    count++;
}

// 특정 블록에만 락 (더 좁은 범위 → 더 효율적)
public void increment() {
    synchronized (this) {
        count++;
    }
}

동작 방식

스레드 A가 synchronized 진입  →  락 획득
스레드 B가 같은 블록 진입 시도  →  락 반납될 때까지 대기
스레드 A가 블록 종료  →  락 반납
스레드 B가 락 획득  →  진입

고유 락의 특징

재진입 가능(Reentrant): 같은 스레드가 이미 가진 락을 다시 획득할 수 있음
락은 객체 단위: synchronized(this)는 해당 객체, synchronized(MyClass.class)는 클래스 단위

synchronized는 간단하지만 성능 병목이 생길 수 있습니다. 실무에서는 ReentrantLock, ConcurrentHashMap 같은 더 세밀한 도구를 많이 씁니다.

synchronized의 단점은?

락을 기다리는 스레드가 많을수록 성능이 저하됩니다. 또한 데드락 가능성이 있습니다. 더 세밀한 제어가 필요하면 ReentrantLock을 사용합니다.

데드락이란?

두 스레드가 서로 상대방이 가진 락을 기다리며 영원히 대기하는 상태입니다. A가 락1을 갖고 락2를 기다리고, B가 락2를 갖고 락1을 기다리는 경우입니다.

Q. JVM의 Xms, Xmx 옵션이 무엇인지 설명해 주세요.

Xms는 JVM 시작 시 Heap의 초기 크기, Xmx는 Heap의 최대 크기를 설정하는 옵션입니다.

-Xms512m   JVM 시작 시 Heap 초기 크기 (Initial heap size)
-Xmx2g     Heap이 늘어날 수 있는 최대 크기 (Maximum heap size)

사용 예시

java -Xms512m -Xmx2g -jar myapp.jar

Xms와 Xmx를 같게 설정하는 이유

Xms < Xmx 일 때
→ Heap이 부족해지면 JVM이 Heap을 동적으로 늘림
→ 이 과정에서 Full GC 발생 가능
→ 애플리케이션 응답 지연

Xms = Xmx 일 때
→ 처음부터 최대 크기로 할당
→ Heap 크기 조정 과정 없음
→ GC 빈도 감소, 응답 안정적

운영 서버에서는 Xms와 Xmx를 동일하게 설정하는 것이 일반적입니다.

주의할 점

Xmx를 너무 크게 설정하면 Full GC 발생 시 STW 시간이 길어집니다.
OS 메모리보다 크게 설정하면 OOM(Out of Memory) 발생합니다.
Xmx를 너무 작게 설정하면 OutOfMemoryError: Java heap space 발생합니다.

Q. Exception과 Error의 차이는 무엇인가요?

둘 다 Throwable을 상속받지만 성격이 다릅니다.

Throwable
├── Error           JVM 레벨의 심각한 오류 — 복구 불가
│   ├── OutOfMemoryError
│   ├── StackOverflowError
│   └── VirtualMachineError
└── Exception       애플리케이션 레벨의 오류 — 복구 가능
    ├── IOException         (Checked)
    ├── SQLException        (Checked)
    └── RuntimeException    (Unchecked)
        ├── NullPointerException
        ├── ArrayIndexOutOfBoundsException
        └── IllegalArgumentException

Error JVM이나 시스템 레벨의 심각한 문제입니다. 개발자가 처리할 수 없고, 처리하려 해서도 안 됩니다.

OutOfMemoryError: Heap 메모리 부족
StackOverflowError: 재귀 호출 무한 반복으로 Stack 초과

Exception 애플리케이션 코드의 문제로 발생합니다. 개발자가 예측하고 처리할 수 있습니다.

Error를 catch로 잡으면 안 되는 이유는?

OutOfMemoryError를 catch해도 이미 메모리가 부족한 상태라 정상 동작을 보장할 수 없습니다. 잡는 척만 하고 실제로는 아무것도 못 합니다. 근본적인 원인(메모리 설정, 코드 개선)을 해결해야 합니다.

Checked Exception과 Unchecked Exception의 차이를 설명해 주세요.

Checked Exception 컴파일러가 처리를 강제하는 예외입니다. try-catch로 잡거나 throws로 선언해야 합니다. RuntimeException을 상속받지 않은 Exception입니다.

// IOException은 Checked → 반드시 처리해야 컴파일됨
void readFile() throws IOException {
    FileInputStream fis = new FileInputStream("file.txt");
}

// 또는
void readFile() {
    try {
        FileInputStream fis = new FileInputStream("file.txt");
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Unchecked Exception (RuntimeException) 컴파일러가 처리를 강제하지 않는 예외입니다. RuntimeException과 그 하위 클래스입니다.

// NullPointerException은 Unchecked → 처리 강제 안 함
void process(String s) {
    s.length();  // s가 null이면 NPE 발생하지만 컴파일 에러는 없음
}

CheckedUnchecked

상속	Exception	RuntimeException
컴파일 강제	O	X
예시	IOException, SQLException	NPE, IllegalArgumentException
발생 원인	외부 환경 (파일, DB, 네트워크)	개발자 실수, 프로그래밍 오류

실무에서는 Unchecked Exception을 선호합니다. Checked는 throws가 메서드 시그니처에 노출되어 계층 간 결합도가 높아지기 때문입니다. Spring도 대부분 Unchecked Exception을 사용합니다.

커스텀 예외를 만들 때 어떤 걸 상속받나요?

실무에서는 대부분 RuntimeException을 상속받아 Unchecked로 만듭니다. class OrderNotFoundException extends RuntimeException { ... } 처럼요.

Checked를 Unchecked로 바꾸는 패턴이 있나요?

네. Checked를 catch해서 Unchecked로 감싸 던지는 방식을 씁니다. Spring의 DataAccessException이 대표적으로, SQLException(Checked)을 감싸서 RuntimeException으로 변환합니다.

Q. Lambda와 Functional Interface를 설명해 주세요.

Functional Interface는 추상 메서드가 하나인 인터페이스입니다. Lambda는 이 Functional Interface의 구현을 익명 클래스 없이 간결하게 표현하는 문법입니다.

Functional Interface 추상 메서드가 딱 하나인 인터페이스입니다. @FunctionalInterface 어노테이션을 붙입니다.

@FunctionalInterface
interface Calculator {
    int calculate(int a, int b);  // 추상 메서드 1개
}

Lambda Functional Interface의 구현을 익명 클래스 대신 간결하게 표현하는 방식입니다.

// 익명 클래스 방식 (Java 8 이전)
Calculator add = new Calculator() {
    @Override
    public int calculate(int a, int b) {
        return a + b;
    }
};

// 람다 방식 (Java 8+)
Calculator add = (a, b) -> a + b;

Java 표준 Functional Interface (java.util.function)

// Function<T, R>  T를 받아 R을 반환
Function<String, Integer> toInt = s -> Integer.parseInt(s);

// Predicate<T>    T를 받아 boolean 반환
Predicate<Integer> isEven = n -> n % 2 == 0;

// Consumer<T>     T를 받아 소비 (반환 없음)
Consumer<String> print = s -> System.out.println(s);

// Supplier<T>     아무것도 안 받고 T 반환
Supplier<String> hello = () -> "hello";

// BiFunction<T,U,R>  두 개 받아 R 반환
BiFunction<Integer, Integer, Integer> add = (a, b) -> a + b;

메서드 참조 (Method Reference)

람다를 더 간결하게 표현합니다.

// 람다
list.forEach(s -> System.out.println(s));

// 메서드 참조
list.forEach(System.out::println);

람다와 익명 클래스의 차이는?

람다는 this가 람다를 감싼 외부 클래스를 가리키지만, 익명 클래스는 this가 익명 클래스 자신을 가리킵니다. 람다는 새 스코프를 만들지 않아요.

@FunctionalInterface를 꼭 붙여야 하나요?

필수는 아닙니다. 단, 붙이면 컴파일러가 추상 메서드가 2개 이상이 되는 실수를 잡아줍니다.

Q. Stream API가 무엇이고 어떻게 사용하나요?

Stream API는 컬렉션을 선언적으로 처리하는 API입니다. 스트림 생성, 중간 연산, 최종 연산 세 단계로 동작합니다.

Stream이란? 컬렉션 데이터를 선언적으로 처리하는 API입니다. for문 없이 필터링, 변환, 집계를 간결하게 표현할 수 있습니다.

기본 구조

컬렉션.stream()          // ① 스트림 생성
    .중간연산()           // ② 데이터 가공 (여러 개 가능, 지연 실행)
    .최종연산();          // ③ 결과 수집 (1개만 가능, 이때 실행됨)

중간 연산 (Intermediate Operation)

List<String> names = List.of("Kim", "Lee", "Park", "Choi", "Kang");

names.stream()
    .filter(s -> s.startsWith("K"))   // 필터링: K로 시작하는 것만
    .map(String::toUpperCase)          // 변환: 대문자로
    .sorted()                          // 정렬
    .limit(2)                          // 2개만
    .forEach(System.out::println);     // 최종 연산

// 출력
// KANG
// KIM

최종 연산 (Terminal Operation)

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

// collect: 결과를 리스트로
List<Integer> evens = numbers.stream()
    .filter(n -> n % 2 == 0)
    .collect(Collectors.toList());  // [2, 4, 6, 8, 10]

// reduce: 하나의 값으로 합산
int sum = numbers.stream()
    .reduce(0, Integer::sum);  // 55

// count, min, max, anyMatch, allMatch
long count = numbers.stream().filter(n -> n > 5).count();  // 5
boolean anyOver9 = numbers.stream().anyMatch(n -> n > 9);  // true

지연 실행 (Lazy Evaluation) 중간 연산은 최종 연산이 호출될 때까지 실행되지 않습니다.

List<String> result = names.stream()
    .filter(s -> { System.out.println("filter: " + s); return true; })
    .map(s -> { System.out.println("map: " + s); return s.toUpperCase(); })
    .limit(2)  // 2개만 필요하므로 전체를 처리하지 않음
    .collect(Collectors.toList());

// filter, map이 3번째 요소부터는 실행되지 않음 → 효율적

for문과 비교

// for문 방식
List<String> result = new ArrayList<>();
for (String name : names) {
    if (name.startsWith("K")) {
        result.add(name.toUpperCase());
    }
}

// Stream 방식
List<String> result = names.stream()
    .filter(s -> s.startsWith("K"))
    .map(String::toUpperCase)
    .collect(Collectors.toList());

Stream과 for문 중 성능은 어떤 게 더 좋나요?

소규모 데이터는 for문이 오버헤드가 없어서 빠릅니다. 대용량 데이터는 parallelStream()으로 병렬 처리 시 Stream이 유리할 수 있습니다. 단, parallelStream은 공유 상태가 있으면 동시성 문제가 생기므로 주의해야 합니다.

Stream은 재사용이 가능한가요?

아닙니다. 최종 연산이 호출되면 스트림이 닫혀서 재사용할 수 없습니다. 재사용하려면 스트림을 다시 생성해야 합니다.

map과 flatMap의 차이는?

map은 1:1 변환, flatMap은 1:N 변환입니다. List<List<Integer>>를 List<Integer>로 평탄화할 때 flatMap을 씁니다.

MySQL FullText에서Elasticsearch로키워드 검색 개선기

민석 개발일지 — Thu, 2 Apr 2026 22:52:35 +0900

MySQL FullText에서 Elasticsearch로 — 키워드 검색 개선기

백엔드 개선기

MySQL FullText에서
Elasticsearch로
키워드 검색 개선기

기존 MySQL FullText 검색의 한계를 넘어, Elasticsearch를 도입해 검색 속도를 4~5배 개선하고 한국어 형태소 분석 기반의 정확한 검색 품질을 확보하기까지의 과정을 정리합니다.

2026.03.26 Elasticsearch · MySQL · Spring Boot

4~5× 검색 속도 개선

~0.17s 대량 키워드 응답시간
(기존 ~0.8s)

배경 — 왜 바꾸게 됐나

서비스에서 키워드 자동완성 검색을 제공하고 있었는데, 기존 구현은 MySQL의 FullText 검색을 사용하고 있었습니다. 운영하면서 두 가지 문제가 뚜렷하게 드러났습니다.

문제 1 — 한 글자 검색 불가
MySQL FullText는 기본적으로 최소 토큰 길이(ft_min_word_len) 제한이 있어, "금", "주", "암" 같은 한 글자 키워드를 검색하면 결과가 아예 반환되지 않았습니다. 자동완성 기능 특성상 사용자가 첫 글자만 입력한 시점에도 결과를 보여줘야 하는데, 이게 원천적으로 막혀 있었습니다.

문제 2 — 대량 결과 검색 시 느린 응답
데이터가 늘어나면서 "대통령" 같이 결과 수가 1,000개를 넘는 키워드를 검색할 때 응답이 눈에 띄게 느려졌습니다. 실제로 API를 반복 호출해보니 응답 시간이 700~1,200ms 수준이었습니다.

두 문제를 한꺼번에 해결하기 위해 Elasticsearch 도입을 검토하게 됐습니다.

검색 대상: keywords 인덱스 — 뉴스 관련 키워드 데이터. 대표 키워드 "대통령" 검색 시 총 1,049개 결과.

1단계 — Elasticsearch 연동 및 성능 비교

Elasticsearch 검색 확인

먼저 Elasticsearch에 키워드 인덱스를 구성하고, 같은 쿼리를 날려 결과를 확인했습니다.

bash

# "대통령" 키워드로 match 검색, 상위 3개 반환
curl -s 'http://localhost:9200/keywords/_search' \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {"match": {"keyword": "대통령"}},
    "size": 3
  }'

결과는 총 1,049개로 MySQL과 동일하게 나왔고, 상위 결과도 "대통령 대통령실 공사", "대통령 폴란드 대통령과" 등 관련도 높은 키워드들이 잘 잡혔습니다.

실제 서비스 API와 연동 후 성능 측정

Spring Boot 서비스에서 같은 요청을 MySQL과 ES 양쪽 모두 실행하고 시간을 로깅해 비교했습니다.

2026-03-26T22:48:33 INFO KeywordService : === 검색 성능 비교: '대통령' ===
2026-03-26T22:48:33 INFO KeywordService : [MySQL FullText] 1049개 결과, 1193ms
2026-03-26T22:48:33 INFO KeywordService : [Elasticsearch] 1049개 결과, 310ms
2026-03-26T22:48:33 INFO KeywordService : 속도 차이: ES가 883ms 빠름 (MySQL 1193ms vs ES 310ms)

2026-03-26T22:49:01 INFO KeywordService : [MySQL FullText] 1049개 결과, 776ms
2026-03-26T22:49:01 INFO KeywordService : [Elasticsearch] 1049개 결과, 138ms
2026-03-26T22:49:01 INFO KeywordService : 속도 차이: ES가 638ms 빠름 (MySQL 776ms vs ES 138ms)

반복 요청할수록 MySQL은 600~1,200ms를 오가는 반면, ES는 꾸준히 130~310ms 대를 유지했습니다. 전체적으로 약 0.8초 → 0.17초로, 4~5배 수준의 개선이 확인됐습니다.

대통령 키워드 검색 — 응답시간 비교 (ms)

MySQL

FullText

~800ms

nori

~170ms

2단계 — 결과 수가 적을 때는 ES가 느리다?

"주식", "아이폰", "부동산" 등 결과 수가 적은 키워드(10~20개)도 테스트해봤더니 예상 외의 결과가 나왔습니다.

2026-03-26T22:35:39 INFO KeywordService : === 검색 성능 비교: '주식' ===
2026-03-26T22:35:39 INFO KeywordService : [MySQL FullText] 18개 결과, 77ms
2026-03-26T22:35:39 INFO KeywordService : [Elasticsearch] 18개 결과, 85ms
2026-03-26T22:35:39 INFO KeywordService : 속도 차이: ES가 8ms 느림

결과 수가 적을 때는 MySQL이 더 빠를 수 있습니다.
MySQL FullText는 같은 프로세스 내 직접 DB 호출이라 오버헤드가 없지만, ES는 HTTP 통신 (localhost라도 네트워크 왕복) + JSON 직렬화/역직렬화 고정 비용이 30~50ms 붙습니다. 결과가 18개처럼 소량이면 MySQL이 쿼리를 금방 끝내지만, ES는 이 고정비용 때문에 오히려 느려집니다.

결과 수	유리한 쪽	이유
소량 (~수십 개)	MySQL	HTTP 오버헤드 없음, 직접 DB 호출
대량 (수백~수천 개)	Elasticsearch	역인덱스 기반 검색이 압도적으로 빠름

3단계 — 갯수 차이가 발생하는 이유 (반도체 케이스)

"삼성" (366개 vs 355개), "반도체" (49개 vs 46개)처럼 MySQL과 ES의 결과 수가 미묘하게 달랐습니다. 왜 그런지 파고들었습니다.

원인: 한국어 토크나이저의 차이

엔진	방식	설명
MySQL FullText	BOOLEAN MODE	단순 문자열 포함 여부 매칭
Elasticsearch	nori 형태소 분석	형태소 분해 후 토큰 단위로 매칭

직접 Elasticsearch의 analyze API로 확인해봤습니다.

bash

curl -s 'http://localhost:9200/keywords/_analyze' \
  -H 'Content-Type: application/json' \
  -d '{"analyzer":"korean_analyzer","text":"반도체법"}'

# 결과:
# tokens: ["반", "도", "체법"]  ← "반도체" 토큰이 없음!

핵심 원인: nori가 decompound_mode: mixed로 설정돼 있어 "반도체법"을 반 / 도 / 체법으로 분해합니다. "반도체" 토큰이 생성되지 않아 "반도체법"이 "반도체" 검색 결과에 포함되지 않습니다. MySQL은 단순 문자열 포함이라 "반도체법"에서도 "반도체"를 찾아냅니다.

분석 대상	nori 토큰 결과	"반도체" 매칭?
반도체	반도체, 반, 도체	✅ 매칭
반도체법	반, 도, 체법	❌ 미매칭

4단계 — 해결방법: ngram 서브필드 추가

"반도체법"에서 "반도체"를 찾으려면 부분 문자열 매칭이 필요합니다. nori 분석기는 그대로 두되, ngram 서브필드를 추가해 두 가지를 함께 활용하는 방식을 선택했습니다.

쿼리 전략: nori에 높은 가중치, ngram에 낮은 가중치

elasticsearch query

{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "keyword": { "query": "반도체", "boost": 3 }
          }
        },
        {
          "match": {
            "keyword.ngram": { "query": "반도체", "boost": 1 }
          }
        }
      ],
      "minimum_should_match": 1
    }
  }
}

nori로 매칭된 결과 → boost 3 → 상위 노출 (정확 매칭 우선)
ngram으로만 매칭된 결과 ("한반도", "도체") → boost 1 → 하위 노출
min_score 설정 시 점수 낮은 과매칭 결과 자동 필터링 가능

인덱스 크기 영향 측정

인덱스	크기	비율
nori만 (기존)	106.9 MB	1x
nori + ngram	188.0 MB	1.76x

예상했던 2~3배보다 적은 약 76% 증가 (81MB 추가)로, 허용 가능한 수준입니다.

ngram 추가 후 결과

2026-03-26T23:48:09 INFO KeywordService : === 검색 성능 비교: '반도체' ===
2026-03-26T23:48:09 INFO KeywordService : [MySQL FullText] 49개 결과, 141ms
2026-03-26T23:48:09 INFO KeywordService : [Elasticsearch] 74개 결과, 290ms

과매칭 주의: ngram 추가 후 ES 결과가 74개로 MySQL(49개)보다 오히려 많아졌습니다. "도체 저항 실험", "한반도 평화" 같이 관련 없는 키워드까지 포함된 것입니다. boost + min_score로 관련도 낮은 결과를 잘라내는 튜닝이 필요합니다.

최종 결론 및 의사결정

정리

항목	결과
대량 키워드 검색 속도	ES 4~5배 빠름
소량 키워드 검색 속도	MySQL이 오히려 빠름
한국어 형태소 매칭 정확도	ES (nori) 우위
복합어 부분 매칭	ngram 서브필드로 보완 (과매칭 주의)
인덱스 크기 증가	nori+ngram 기준 약 76% 증가

권장 적용 전략

결과 수가 많은 대형 키워드 검색 → Elasticsearch 사용
결과 수가 적은 정확 매칭 검색 → MySQL FullText도 충분
복합어 포함 포괄적 검색이 필요하면 → nori + ngram + boost 조합
ngram 과매칭 제어 → min_score 또는 상위 N개만 반환
nori의 decompound_mode를 none으로 바꾸면 갯수는 맞출 수 있지만 검색 품질(복합어 분해) 저하

[코딩 테스트] 트리의 부모 찾기

민석 개발일지 — Tue, 11 Mar 2025 13:04:35 +0900

https://www.acmicpc.net/problem/11725

트리의 부모 찾기

시간 제한메모리 제한제출정답맞힌 사람정답 비율

1 초

256 MB

101747

46543

32592

43.306%

문제

루트 없는 트리가 주어진다. 이때, 트리의 루트를 1이라고 정했을 때, 각 노드의 부모를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 노드의 개수 N (2 ≤ N ≤ 100,000)이 주어진다. 둘째 줄부터 N-1개의 줄에 트리 상에서 연결된 두 정점이 주어진다.

출력

첫째 줄부터 N-1개의 줄에 각 노드의 부모 노드 번호를 2번 노드부터 순서대로 출력한다.

예제 입력 1

예제 출력 1

예제 입력 2

예제 출력 2

처음에 나는 Find-Union을 생각하여 나오는 노드 중 하나를 부모로 지정하려고 하였다. 밑에 코드와 같이

입력받은 노드 2개중에 하나가 parent가 지정돼있는지 확인
지정이 안돼있으면 둘 중하나가 나머지의 부모이다.

import java.io.*;
import java.util.*;


class Main {
  public static void main(String[] args)throws IOException {
    BufferedReader br= new BufferedReader(new InputStreamReader(System.in));
    int N =Integer.parseInt(br.readLine());
    int[] parent = new int[N+1];
    Arrays.fill(parent,-1);
    parent[1] = 0;
    for(int i = 0 ; i <N-1;i++){
      String[] input = br.readLine().split(" ");
      int front = Integer.parseInt(input[0]);
      int back = Integer.parseInt(input[1]);
      if(parent[front]!=-1){
        parent[back] =front;
      }else{
        parent[front] = back;
      }
    }

    for(int i = 2 ; i<=N;i++){
      System.out.println(parent[i]);
    }

  }
}

이런식으로 간단하게 부모 노드를 정하려고 하였다.

이렇게 하면 예제문제는 간단하게 풀리게 됨.

그렇지만 예제는 부모노드가 정의된 노드 순서대로 예제를 아주 이쁘게 주었기 때문에 문제가 발생하지 않는다.

예를 들면

7
1 6
6 3
3 5
4 1
2 4
4 7

이렇게 되면

1 6 // 1은 root로 지정돼있으므로, 1은 6의 부모이다.

6 3 // 6은 부모가 1로 지정돼있으므로, 6은 3의 부모이다.
3 5 // 3은 부모가 6으로 지정돼있으므로, 3은 5의 부모이다.
4 1 // ...
2 4 // ...
4 7 // ...

같은 방식으로 끝까지 도달하게 되면 부모 노드를 저장하게 된다.

하지만 만약에

3 5

6 3
4 1
2 4
4 7

이런식으로 첫 번째 줄과, 두 번째 줄이 바뀌게 된다면 어떻게 될까?

그러면 3이랑 5는 둘 다 부모가 아직 없기 때문에 , 꼬여버리게 된다.

그래서 어떻게 할까? 하다가 나는 BFS로 문제를 풀어보았다.

import java.io.*;
import java.util.*;


class Main {
    public static void main(String[] args)throws IOException {
        BufferedReader br= new BufferedReader(new InputStreamReader(System.in));
        int N =Integer.parseInt(br.readLine());
        boolean[] visited = new boolean[N+1];
        int[] parent = new int[N+1];

        ArrayList<Integer>[] adList = new ArrayList[N+1];
        for(int i = 0;  i <=N ; i++){
            adList[i]=new ArrayList<>();
        }
        for(int i = 0 ; i < N-1 ; i ++){
            String[] input= br.readLine().split(" ");
            int v1 = Integer.parseInt(input[0]);
            int v2 = Integer.parseInt(input[1]);
            adList[v1].add(v2);
            adList[v2].add(v1);
        }

        ArrayDeque<Integer> queue= new ArrayDeque<>();
        queue.add(1);

        while(!queue.isEmpty()){
            int now = queue.poll();


            for(int next: adList[now]){
                if(!visited[next]){
                    visited[next] =true;
                    parent[next] = now;
                    queue.add(next);
                }
            }


        }
        for(int i = 2 ; i <= N ; i++){
            System.out.println(parent[i]);
        }
    }
}

[코딩 테스트] 좋은 친구

민석 개발일지 — Tue, 4 Feb 2025 18:19:26 +0900

문제 출처

https://www.acmicpc.net/problem/3078

문제 풀이 생각과 과정

한명씩 조사하면서, K 범위에있는 친구를 조사하는건 절대 안될 거라는 생각이 들었다.
K가 N만큼 커지게 된다면 N^2 만큼 조사하게 되고, (3 ≤ N ≤ 300,000, 1 ≤ K ≤ N) 같은 범위에서는 무조건 시간초과가 나게 될 것이다.
어떻게 할까 고민하다가 결국에 생각해내지 못하고 힌트를 참고하였다....

예시를 보면서 설명하는게 편할 것 같아서 문제에서 보여준 2번째 예시를 사용해보도록 하겠다.

예제 입력 2

6 3
CYNTHIA
LLOYD
STEVIE
KEVIN
MALCOLM
DABNEY

다음과 같은 예시에 먼저 배열을 두개를 생성해준다.

첫 번째 배열은, 각 사람마다의 이름의 크기를 저장한다
두 번째 배열은, 이름의 길이를 인덱스로한 배열이다
- 최대 20자라고 하였으니 int[20+1]의 배열을 선언해주면 되겠다.

K만큼 조사하면서 확인한다.

첫 번째 학생(1등 학생, 이름길이:7)의 count 수를 보고서 answer에 추가하면된다. 여기서 중요한 점은 자신을 제외하여야 하기 때문에

answer += nameLengthCount[ 7 ] - 1 이라는 점이다.

그래서 처음 학생과 좋은 친구 쌍은 없다.

다음 과정을 하기위해서 1등 친구(이름 길이 7)의 count를 빼주고, 4등 친구(이름 길이 5)의 count를 추가해준다.

이렇게 되면

answer + = nameLengthCount[5] - 1

즉, answer+ = 2 - 1

이 되게 된다. 두 번째 친구와의 좋은 친구 쌍이 하나 있다는 말이다.

이런식으로 쭉 진행하면 된다.

소스코드

import java.io.*;


public class Main {
    public static void main(String[] args)throws IOException{
        BufferedReader br= new BufferedReader(new InputStreamReader(System.in));
        String[] input =br.readLine().split(" ");
        int N =Integer.parseInt(input[0]);
        int K =Integer.parseInt(input[1]);

        long answer=0;

        //이름 길이를 저장할 배열 생성(최대 20자니까 20+1으로 생성)
        int[] nameLengthCount = new int[21];

        int[] nameLength = new int[N];
        for(int i =0;i<N;i++){
            nameLength[i]=br.readLine().length();
        }

        for(int i=0;i<K;i++){
            nameLengthCount[nameLength[i]]++;
        }

        for(int i=0;i<N-1;i++){
            if((i+K)<=N-1) nameLengthCount[nameLength[i+K]]++;
            answer+=nameLengthCount[nameLength[i]]-1;
            nameLengthCount[nameLength[i]]--;
        }

        System.out.println(answer);

    }
}

[코딩 테스트] 오큰수

민석 개발일지 — Tue, 4 Feb 2025 15:13:29 +0900

문제 출처

https://www.acmicpc.net/problem/17298

문제 풀이 생각과 과정

먼저 어떤자료구조를 사용할 지에 대해서 고민을 많이 했다.
이 문제는 결국에는 스택을 사용하는 문제를 알아차리는게 중요해 보인다.

그 다음 슈도코드는 다음과 같다.

배열의 오른쪽에서 왼쪽으로 역순으로 확인한다(오른쪽에 큰 수 가 있었는지 확인해야 하므로)
스택의 최상단에 있는 수가 내가 지금 확인하는 수보다 크면, 그 숫자를 배열에 저장한다.
- 스택에 지금 내가 확인한 수를 push한다.
스택의 최상단에 있는 수가 내가 지금 확인하는 수보다 작거나 같으면, 스택에 있는 수를 빌때까지 pop한다.
- 스택이 비게 되면 -1를 저장하게 됨(오큰수가 없는 경우임)

그림으로 설명해보도록 하겠다.

먼저 다음은 초기 상태이다. 스택은 비어져있고 배열의 마지막부터 접근을 하게 된다.

그 다음 스택이 비어져 있으므로, answer 배열에 -1을 추가한다.

다음 2를 확인하러가고, 스택에는 7이 있다.
스택의 최상단(7) 이랑, 현재 비교하는 수(2) 중에서 스택에 있는 수가 더 크므로 answer배열에 저장

그리고 스택에 추가해준다.
다음 5랑 스택의 최상단(2)이랑 확인하는데 스택에 있는 수가 더 작다

스택에서 2를 pop해준다음
7이랑 비교를 한다.
7이 5보다 더 크니까 7을 answer에 저장

그 다음 5랑 3이랑 비교를 하면 5가 더 크니까, 5를 저장하면 끝나게 된다.

정답으로

5 7 7 -1 을 출력해주면 된다.

스택을 알아차린다면 코드는 길지 않은 문제였던 것 같다.

코드

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());
        int[] numbers = Arrays.stream(br.readLine().split(" ")).mapToInt(Integer::parseInt).toArray();
        int[] answer = new int[n];
        ArrayDeque<Integer> stack =new ArrayDeque<>();
        A:for(int i = n-1  ; i>=0; i--){
            while(!stack.isEmpty()){
                if(stack.peek()>numbers[i]){
                    answer[i]=stack.peek();
                    stack.push(numbers[i]);
                    continue A;
                }else{
                    stack.pop();
                }
            }
            stack.push(numbers[i]);
            answer[i] =-1;
        }

        StringBuilder sb =new StringBuilder();
        for(int i = 0 ; i<n;i++){
            sb.append(answer[i]);
            sb.append(" ");
        }
        System.out.println(sb.toString().trim());
    }
}

[코딩 테스트] 칸토어 집합

민석 개발일지 — Sun, 26 Jan 2025 01:21:47 +0900

문제 출처

https://www.acmicpc.net/problem/4779

문제풀이 생각과 과정

재귀를 통해서 왼쪽 부분과 오른쪽 부분을 계속 호출해야 할 것 같았음
- 재귀 종료 조건은 마지막 한 개 남았을 경우 재귀 종료

이렇게 간단하게 생각하고 문제에 들어갔다.

문제 들어가서 인덱스 계산하는데 조금 햇갈려서 그림을 그려보았다.

예시는 N이 2일 경우이고, 즉 3^2 = 9 개의 집합이 있을 때이다.

(아래 참고)

이런식으로 재귀를 호출하면서 분할 정복으로 마지막 정복이 됐을 때 결과를 Print해주면 된다. StringBuilder를 통해서 String을 관리해주었다.

자바 문법 알게된 점

StringBuilder에 있는 replace(start,end,..) 메서드를 통해서 빈 문자열로 바꾸는 작업을 했는데 여기서 주의할 점이 있었다.

replace(start, end ,바꿀 문자열) 인데

여기서 end는 end-1의 내용까지를 바꾸는 것이다.

코드 예시를 보면서 말하자면

StringBuilder sb = new StringBuilder();
sb.append("Hello!");
sb.replace(0,3,"X");

라는 코드가 있으면

나는 "Hello!" 문자열에서 0번부터 3번 인덱스. 즉, H,e,l,l 까지 X로 바뀌어서

"Xo!" 라는 문자열이 나올 줄 알았지만

end-1 인덱스 까지. 즉, H,e,l 까지 X로 바뀌어서

결과는 "Xlo!"라는 문자열이 출력이 되게 된다.

또한 String에서 repeat()메서드를 사용하면 특정 문자열을 반복하는 문자열을 생성할 수 있다.

예를 들면

String space = "-".repeat(10);

를 하게되면

String space = "----------"

이렇게 선언한 것과 같게 된다.