운영체제 리드·아키텍트 기술면접

외부 단편화는 페이징 기법을 통해 물리 메모리를 고정 크기로 나누어 해결할 수 있으며, 압축(Compaction)이나 Buddy System을 활용해 연속된 메모리 블록을 확보할 수 있습니다. 내부 단편화는 다양한 크기의 메모리 풀을 운영하거나 Slab Allocator처럼 객체 크기별로 캐시를 관리하는 방식으로 최소화합니다. 프로덕션 환경에서는 jemalloc이나 tcmalloc 같은 고성능 메모리 할당자를 사용하여 멀티스레드 환경에서의 경합을 줄이고 메모리 효율을 높입니다. 또한 메모리 풀링 전략을 애플리케이션 레벨에서 구현하여 빈번한 할당/해제로 인한 단편화를 방지하고, 주기적인 메모리 프로파일링을 통해 단편화 수준을 모니터링합니다. 컨테이너 환경에서는 메모리 제한(cgroup)과 OOM 정책을 적절히 설정하여 시스템 전체의 안정성을 확보해야 합니다.

Load Balancing은 모든 코어의 작업 부하를 균등하게 분산시켜 전체 시스템 처리량을 높이지만, 프로세스를 다른 코어로 이동시킬 때 기존 캐시 데이터가 무효화되어 Cache Affinity를 해칩니다. Cache Affinity는 프로세스를 동일 코어에 유지하여 캐시 히트율을 높이지만, 특정 코어에 부하가 집중될 수 있어 전체 성능이 저하될 수 있습니다. NUMA 환경에서는 프로세스와 해당 메모리를 동일 NUMA 노드에 배치하는 것이 중요하며, Linux의 CFS 스케줄러는 task affinity와 cpuset을 통해 이를 제어합니다. 최적 전략은 workload 특성에 따라 CPU-bound 작업은 Cache Affinity를 우선하고, I/O-bound 작업은 Load Balancing을 우선하며, NUMA-aware 메모리 할당 정책(numactl)을 함께 적용하는 것입니다. 프로덕션에서는 cgroup과 CPU pinning을 활용하여 중요한 서비스의 성능을 보장하고, 실시간 모니터링을 통해 NUMA 노드 간 메모리 접근 패턴을 분석해야 합니다.

Lock-based 자료구조는 뮤텍스나 세마포어로 임계 영역을 보호하며 구현이 직관적이지만, 락 경합 시 컨텍스트 스위칭과 대기 시간이 발생하고 데드락 위험이 있습니다. Lock-free 자료구조는 CAS 같은 원자적 연산을 사용해 락 없이 동기화하며, 컨텍스트 스위칭이 없어 고경합 상황에서 더 나은 성능을 보이지만 구현이 복잡하고 메모리 순서 보장이 어렵습니다. Lock-based는 경합이 낮고 임계 영역이 짧으며 정확성이 중요한 비즈니스 로직에 적합하고, Lock-free는 고경합 환경의 메시지 큐나 로그 버퍼처럼 높은 처리량이 필요한 곳에 적합합니다. ABA 문제는 CAS 연산 중 값이 A에서 B로 바뀌었다가 다시 A로 돌아와 변경을 감지하지 못하는 문제로, 버전 카운터나 태그를 함께 사용하거나 Hazard Pointer 기법으로 해결합니다. 실무에서는 검증된 라이브러리(Java의 ConcurrentHashMap, C++의 atomic)를 우선 사용하고, 커스텀 구현 시 철저한 테스트와 메모리 모델 이해가 필수입니다.

저널링 파일 시스템은 메타데이터와 데이터 변경사항을 먼저 저널 영역에 기록한 후 실제 위치에 쓰는 Write-Ahead Logging 방식으로 시스템 크래시 시 복구를 빠르고 안전하게 수행합니다. ordered 모드는 데이터를 먼저 쓰고 메타데이터를 저널에 기록해 일관성과 성능의 균형이 좋아 기본값으로 많이 사용되며, writeback 모드는 순서를 보장하지 않아 가장 빠르지만 크래시 시 데이터 손상 위험이 있고, journal 모드는 모든 것을 저널에 기록해 가장 안전하지만 성능이 떨어집니다. ext4는 범용성과 안정성으로 대부분의 서버에 적합하고, XFS는 대용량 파일과 병렬 I/O에 강해 미디어 서버나 빅데이터에 유리하며, Btrfs는 스냅샷과 압축 기능으로 백업이 중요한 환경에 적합합니다. 실무에서는 데이터베이스처럼 자체 WAL이 있는 애플리케이션은 writeback 모드로 성능을 높이고, 금융 시스템처럼 데이터 무결성이 최우선인 경우 journal 모드를 선택하며, 일반 웹 서버는 ordered 모드를 사용합니다.

Type 1 하이퍼바이저는 하드웨어 위에 직접 실행되며 각 VM이 독립적인 커널을 가져 완전한 격리를 제공하지만 오버헤드가 크고, Type 2는 호스트 OS 위에서 실행되어 관리가 쉽지만 성능이 더 낮습니다. 컨테이너는 호스트 커널을 공유하며 namespace로 프로세스, 네트워크, 마운트 등의 가시성을 격리하고, cgroup으로 CPU, 메모리, I/O 같은 리소스 사용량을 제한하여 경량화된 격리를 구현합니다. namespace는 PID, NET, MNT, UTS, IPC, USER 등 여러 종류가 있어 각 컨테이너가 독립된 환경을 가진 것처럼 보이게 하고, cgroup은 계층적 리소스 할당과 제한을 통해 noisy neighbor 문제를 방지합니다. 보안 측면에서 VM은 커널 레벨 격리로 더 강력하지만, 컨테이너는 커널을 공유해 커널 취약점에 노출될 위험이 있어 seccomp, AppArmor, SELinux 같은 추가 보안 계층이 필요합니다. 실무에서는 멀티테넌트 환경이나 보안이 중요한 경우 VM을, 마이크로서비스와 CI/CD처럼 빠른 배포와 높은 밀도가 필요한 경우 컨테이너를, 또는 Kata Containers처럼 두 방식을 결합한 하이브리드 접근도 고려합니다.