2026.08.19 | 전공자·정보처리기사 수준 | 인프라 직무 대비 | 총 80문항 · ★★★ 최빈출 / ★★ 자주 출제 / ★ 기본
이 파일 하나로 모든 단원이 포함되어 있어 어디로 옮겨도 동작합니다.
| 단원 | |
|---|---|
| 클라우드 컴퓨팅 개론 최빈출 | 10문항 |
| 서버 구축 기초 | 10문항 |
| AWS 핵심 서비스 최빈출 | 10문항 |
| AWS 실습 최빈출 | 10문항 |
| Docker 기초 최빈출 | 10문항 |
| Docker 실전 활용 | 10문항 |
| 쿠버네티스 기초 개념 최빈출 | 10문항 |
| 쿠버네티스 실무 마스터 최빈출 | 10문항 |
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 클라우드 서비스 모델은 사용자가 직접 관리하는 범위에 따라 구분됩니다. IaaS(Infrastructure as a Service)는 서버, 스토리지, 네트워크 같은 하드웨어 자원을 가상화해 제공하며 OS 설치부터 애플리케이션까지 사용자가 직접 관리합니다(예: AWS EC2, GCP Compute Engine). PaaS(Platform as a Service)는 OS와 미들웨어, 런타임 환경까지 제공업체가 관리하고 사용자는 애플리케이션 코드 배포에만 집중합니다(예: AWS Elastic Beanstalk, Heroku). SaaS(Software as a Service)는 완성된 애플리케이션을 그대로 사용하는 형태로 사용자는 인프라나 코드에 전혀 관여하지 않습니다(예: Gmail, Salesforce). 관리 부담이 IaaS → PaaS → SaaS로 갈수록 줄어드는 대신 커스터마이징 자유도는 줄어드는 트레이드오프가 있습니다.
관련 개념 공유 책임 모델, 온프레미스, 서버리스(FaaS), 관리형 서비스, 벤더 종속(Lock-in)
답안 온프레미스는 기업이 직접 서버와 데이터센터를 구축·소유하는 방식으로 초기 투자 비용(CAPEX)이 크고, 하드웨어 조달부터 유지보수, 전력, 냉각까지 모두 자체적으로 책임집니다. 클라우드는 필요한 만큼 자원을 임대해 쓰는 방식으로 초기 투자 없이 사용한 만큼 지불하는 OPEX 구조이며, 확장·축소가 빠르고 물리적 유지보수 부담이 없습니다. 다만 온프레미스는 데이터 주권과 커스터마이징, 장기적으로는 대규모 고정 워크로드에서 비용 효율이 유리할 수 있고, 클라우드는 트래픽 변동이 큰 서비스나 빠른 시장 진입이 필요한 경우에 유리합니다. 실무에서는 두 방식을 혼합한 하이브리드 클라우드로 민감 데이터는 온프레미스에, 탄력적 워크로드는 클라우드에 배치하는 전략도 많이 사용됩니다.
관련 개념 CAPEX/OPEX, 하이브리드 클라우드, 멀티 클라우드, TCO(총소유비용), 데이터 주권
답안 확장성은 시스템이 부하 증가에 대응해 자원을 늘릴 수 있는 능력 자체를 의미하며, 미리 계획된 용량 증설도 포함하는 넓은 개념입니다. 탄력성은 트래픽 변화에 따라 자원을 자동으로, 그리고 신속하게 늘리거나 줄이는 능력으로 클라우드의 핵심 특성 중 하나입니다. 확장 방식은 수직 확장(Scale-up)과 수평 확장(Scale-out)으로 나뉘는데, 수직 확장은 서버 자체의 CPU·메모리를 증설하는 방식이고 수평 확장은 서버 대수를 늘려 부하를 분산하는 방식입니다. 클라우드는 오토스케일링을 통해 수평 확장을 자동화함으로써 탄력성을 실현하며, 이는 온프레미스 대비 클라우드의 대표적인 장점으로 면접에서 자주 비교됩니다.
관련 개념 Scale-up/Scale-out, 오토스케일링, 로드밸런서, 탄력적 과금(종량제)
답안 리전은 지리적으로 독립된 데이터센터 집합이 위치한 특정 지역(예: 서울, 도쿄)을 의미하며, 각 리전은 물리적으로 멀리 떨어져 있어 재해나 장애가 다른 리전에 전파되지 않도록 설계됩니다. 가용영역(AZ)은 하나의 리전 내에 존재하는 물리적으로 독립된 데이터센터(또는 데이터센터 그룹)로, 각 AZ는 별도의 전력·냉각·네트워크를 가지지만 저지연으로 연결되어 있습니다. 고가용성을 확보하려면 하나의 AZ에만 자원을 배치하지 않고 여러 AZ에 걸쳐 애플리케이션을 이중화하여 한 AZ에 장애가 발생해도 서비스가 지속되도록 설계해야 합니다. 리전 선택 시에는 사용자와의 물리적 거리(지연시간), 데이터 규제 준수, 서비스 가용 여부 등을 함께 고려합니다.
관련 개념 고가용성(HA), 재해복구(DR), 멀티 AZ 배포, 지연시간(Latency), 데이터 레지던시
답안 클라우드 도입의 핵심 이유는 첫째, 초기 자본 투자 없이 빠르게 인프라를 구축할 수 있다는 점입니다. 둘째, 트래픽 변동에 맞춰 자원을 유연하게 조절하는 탄력성으로 비용 효율을 높일 수 있습니다. 셋째, 전 세계 여러 리전에 손쉽게 배포할 수 있어 글로벌 서비스 확장이 용이합니다. 넷째, 관리형 서비스(RDS, 매니지드 쿠버네티스 등)를 통해 운영 부담을 줄이고 개발팀이 핵심 비즈니스 로직에 집중할 수 있습니다. 다만 장기적 비용, 벤더 종속, 보안 책임 소재 등은 도입 시 함께 고려해야 할 단점으로 언급하는 것이 좋습니다.
관련 개념 민첩성(Agility), TTM(Time to Market), 관리형 서비스, 벤더 종속, 비용 최적화
답안 고가용성은 시스템이 장애 발생 시에도 서비스 중단 없이 지속적으로 동작할 수 있는 능력을 의미하며, 보통 가동률(예: 99.9%, 99.99%)로 수치화합니다. 이를 구현하기 위한 대표적인 방법은 단일 장애점(SPOF)을 제거하는 것으로, 서버를 다중화하고 로드밸런서로 트래픽을 분산하며, 데이터베이스는 마스터-슬레이브 또는 멀티 AZ 복제 구성을 사용합니다. 또한 여러 가용영역이나 리전에 자원을 분산 배치해 특정 데이터센터 장애가 전체 서비스 장애로 이어지지 않도록 설계합니다. 헬스체크를 통해 장애 인스턴스를 자동 감지하고 트래픽에서 제외하는 자동 장애조치(Failover)도 고가용성 설계의 핵심 요소입니다.
관련 개념 SPOF(단일 장애점), 가동률(SLA), Failover, 이중화(Redundancy), 헬스체크
답안 백업은 데이터를 별도로 복사·보관해 데이터 손실에 대비하는 것이고, 재해복구(DR)는 대규모 장애(리전 전체 장애, 자연재해 등)가 발생했을 때 서비스 전체를 다른 위치에서 신속히 복구하는 절차와 체계를 의미합니다. DR 전략의 목표는 RTO(Recovery Time Objective, 목표 복구 시간)와 RPO(Recovery Point Objective, 목표 복구 시점)로 정의되는데, RTO는 장애 발생 후 서비스가 복구되기까지 허용 가능한 최대 시간이고, RPO는 복구 시 허용 가능한 최대 데이터 손실 시점(얼마나 과거 데이터까지 복구되어도 되는가)을 의미합니다. 클라우드에서는 멀티 리전 복제, 자동 백업 스냅샷, 파일럿 라이트(Pilot Light)나 웜 스탠바이 같은 DR 아키텍처 패턴을 통해 RTO/RPO를 낮출 수 있습니다.
관련 개념 RTO, RPO, 멀티 리전 복제, 스냅샷, 웜 스탠바이/파일럿 라이트
답안 서버리스는 개발자가 서버 프로비저닝이나 용량 관리를 신경 쓰지 않고 코드 실행 단위(함수)만 작성하면 클라우드 제공업체가 실행 환경을 자동으로 관리해주는 모델입니다(예: AWS Lambda). 요청이 들어올 때만 함수가 실행되고 사용한 만큼만 과금되며, 트래픽이 없으면 비용이 발생하지 않는다는 것이 큰 장점입니다. 이벤트 기반 처리(파일 업로드 트리거, API 요청 처리)나 트래픽 변동이 크고 예측하기 어려운 워크로드에 적합하지만, 콜드 스타트 지연, 실행 시간 제한, 상태 유지가 어려운 점(Stateless) 등의 제약이 있어 항상 켜져 있어야 하는 상시 서비스나 긴 처리 시간이 필요한 작업에는 적합하지 않습니다.
관련 개념 FaaS, 콜드 스타트, 이벤트 기반 아키텍처, 종량 과금, Stateless
답안 온디맨드(종량제) 방식은 사용한 만큼만 시간 단위나 초 단위로 비용을 지불하는 방식으로 유연하지만 단가는 상대적으로 높습니다. 예약 인스턴스(Reserved Instance)는 1년 또는 3년 등 장기간 사용을 약정하는 대신 대폭 할인된 단가를 적용받는 방식으로, 트래픽이 예측 가능하고 지속적인 워크로드에 적합합니다. 이 외에도 여유 자원을 저렴하게 활용하는 스팟 인스턴스가 있는데, 가격이 변동하고 자원 회수(중단)될 수 있어 배치 작업이나 장애 허용이 가능한 워크로드에 사용됩니다. 실무에서는 기본 트래픽은 예약 인스턴스로, 피크 트래픽은 온디맨드나 스팟으로 처리하는 혼합 전략을 자주 사용합니다.
관련 개념 온디맨드, 예약 인스턴스(RI), 스팟 인스턴스, Savings Plan, 비용 최적화
답안 멀티 클라우드는 하나의 클라우드 제공업체가 아닌 여러 업체(AWS, Azure, GCP 등)의 서비스를 함께 사용하는 전략입니다. 장점으로는 특정 벤더에 종속되지 않아 벤더 락인(Lock-in)을 완화하고, 각 클라우드의 강점 서비스를 선택적으로 활용할 수 있으며, 한 업체의 전체 장애 시에도 다른 업체로 대체할 수 있는 리스크 분산 효과가 있습니다. 단점으로는 여러 플랫폼의 운영·보안 정책을 각각 관리해야 해 운영 복잡도와 인력 학습 비용이 증가하고, 클라우드 간 데이터 전송 비용과 네트워크 지연이 발생할 수 있습니다. 따라서 멀티 클라우드는 명확한 목적(재해복구, 규제 준수, 특정 서비스 활용)이 있을 때 신중하게 도입하는 것이 일반적입니다.
관련 개념 벤더 락인, 하이브리드 클라우드, 데이터 전송 비용, 운영 복잡도, 클라우드 애그노스틱
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 물리서버는 하나의 하드웨어에 하나의 OS만 설치되어 자원을 독점하는 전통적인 방식으로, 자원 활용률이 낮고 확장에 시간이 걸립니다. 가상화는 하이퍼바이저를 통해 하나의 물리 서버 위에 여러 개의 독립된 가상머신(VM)을 생성하며, 각 VM은 자체 커널을 포함한 완전한 OS를 가지므로 격리성이 강하지만 상대적으로 무겁고 부팅이 느립니다. 컨테이너는 호스트 OS의 커널을 공유하면서 애플리케이션과 라이브러리만 격리된 프로세스 형태로 실행하는 방식으로, VM보다 훨씬 가볍고 시작 속도가 빠르며 이식성이 뛰어납니다. 다만 커널을 공유하기 때문에 VM만큼의 강력한 격리 수준은 제공하지 못한다는 차이가 있습니다.
관련 개념 하이퍼바이저, 커널 공유, 격리 수준, 리소스 오버헤드, 이식성(Portability)
답안 Type 1 하이퍼바이저(Bare-metal)는 하드웨어 위에 직접 설치되어 동작하는 방식으로, 별도의 호스트 OS 없이 하이퍼바이저 자체가 하드웨어 자원을 직접 제어합니다(예: VMware ESXi, Microsoft Hyper-V, Xen, KVM). 호스트 OS를 거치지 않아 오버헤드가 적고 성능이 뛰어나 데이터센터나 클라우드 인프라의 표준으로 사용됩니다. Type 2 하이퍼바이저(Hosted)는 일반 운영체제 위에 애플리케이션처럼 설치되어 동작하며(예: VMware Workstation, VirtualBox), 호스트 OS를 거쳐야 하므로 성능은 상대적으로 낮지만 설치와 사용이 간편해 개발·테스트 환경에서 주로 사용됩니다. 실무 인프라에서는 성능과 안정성이 중요하므로 대부분 Type 1 방식을 채택합니다.
관련 개념 Bare-metal, KVM, Xen, VM 오버헤드, 게스트 OS
답안 서버 스펙 산정 시에는 먼저 예상 트래픽과 동시 접속자 수를 기준으로 필요한 CPU 코어 수와 클럭 성능을 산정하고, 애플리케이션의 특성(CPU 바운드인지 I/O 바운드인지)에 따라 CPU와 메모리 비중을 조절합니다. 메모리는 애플리케이션, 캐시, DB 버퍼풀 등이 사용할 용량을 고려해 여유분을 두고 산정하며, 디스크는 I/O 성능(IOPS)과 저장 용량, 그리고 SSD/HDD 여부를 트래픽 패턴에 맞게 결정합니다. 네트워크 대역폭은 예상 트래픽 피크치를 기준으로 산정하고, 향후 트래픽 증가를 고려해 확장 여지를 반드시 확보해야 합니다. 실무에서는 벤치마크 테스트나 부하 테스트를 통해 실측 데이터를 기반으로 스펙을 재조정하는 것이 일반적입니다.
관련 개념 CPU 바운드/I/O 바운드, IOPS, 부하 테스트, 캐패시티 플래닝, 피크 트래픽
답안 로드밸런싱은 여러 대의 서버에 트래픽을 고르게 분산시켜 특정 서버에 부하가 집중되는 것을 방지하고, 서버 장애 시 자동으로 트래픽을 다른 서버로 우회시켜 가용성을 높이는 기술입니다. 대표적인 알고리즘으로는 각 서버에 순서대로 요청을 분배하는 라운드 로빈(Round Robin), 현재 연결 수가 가장 적은 서버로 보내는 최소 연결 방식(Least Connection), 서버 성능에 따라 가중치를 부여하는 가중 라운드 로빈(Weighted Round Robin), 그리고 클라이언트 IP 등을 해싱해 항상 같은 서버로 보내는 IP 해시 방식이 있습니다. 로드밸런서는 동작 계층에 따라 IP/포트 기반으로 분산하는 L4와 URL·HTTP 헤더 등 애플리케이션 정보를 기반으로 분산하는 L7로 나뉘며, L7은 더 세밀한 라우팅(경로 기반 라우팅 등)이 가능합니다.
관련 개념 L4/L7 로드밸런서, 라운드 로빈, 세션 지속성(Sticky Session), 헬스체크
답안 이중화는 시스템의 특정 구성요소가 장애를 일으켜도 서비스가 중단되지 않도록 동일하거나 대체 가능한 자원을 복수로 구성하는 것을 의미합니다. 대표적으로 웹 서버를 두 대 이상 두고 로드밸런서로 트래픽을 분산하는 서버 이중화, 마스터 DB 장애 시 슬레이브가 즉시 승격하는 DB 이중화(Replication), 네트워크 경로가 끊겨도 우회할 수 있는 네트워크 이중화(이중 회선, 이중 스위치) 등이 있습니다. 이중화의 궁극적인 목적은 단일 장애점(SPOF)을 제거하여 전체 시스템의 가용성을 높이는 것이며, 이를 위해서는 이중화된 자원 간 자동 장애 감지 및 전환(Failover) 메커니즘이 함께 구축되어야 실질적인 효과를 볼 수 있습니다.
관련 개념 SPOF, Failover, Active-Active/Active-Standby, 복제(Replication)
답안 Active-Active는 이중화된 두 개 이상의 시스템이 모두 동시에 트래픽을 처리하는 구성으로, 평상시에도 자원을 놀리지 않고 활용하며 로드밸런서를 통해 부하를 분산합니다. 장애 발생 시 남은 노드가 트래픽을 흡수하지만, 남은 노드가 전체 부하를 감당할 수 있는 용량을 갖춰야 합니다. Active-Standby는 평상시 하나의 시스템(Active)만 트래픽을 처리하고, 다른 시스템(Standby)은 대기 상태로 있다가 Active 장애 시 전환(Failover)되어 서비스를 이어받는 구성입니다. Active-Active는 자원 활용도가 높고 확장성이 좋지만 구성이 복잡하고, Active-Standby는 구성이 단순하지만 평상시 Standby 자원이 낭비된다는 차이가 있습니다.
관련 개념 Failover, 자원 활용률, VIP(가상 IP), 클러스터링
답안 DAS(Direct Attached Storage)는 서버에 스토리지를 직접 케이블로 연결하는 방식으로 구성이 단순하지만 다른 서버와 공유가 어렵습니다. NAS(Network Attached Storage)는 네트워크(주로 이더넷/TCP-IP)를 통해 파일 단위로 스토리지를 공유하는 방식으로, 여러 서버나 클라이언트가 동시에 파일 시스템에 접근할 수 있어 공유 스토리지 용도로 많이 사용됩니다. SAN(Storage Area Network)은 별도의 고속 전용 네트워크(주로 광채널)를 통해 블록 단위로 스토리지에 접근하는 방식으로, NAS보다 성능이 뛰어나 대규모 데이터베이스나 고성능 트랜잭션 처리에 적합합니다. 클라우드 환경에서는 이러한 개념이 각각 블록 스토리지(EBS)와 파일 스토리지(EFS), 오브젝트 스토리지(S3) 서비스로 대응됩니다.
관련 개념 블록 스토리지, 파일 스토리지, 오브젝트 스토리지, 광채널(FC), iSCSI
답안 서버 모니터링의 핵심 지표는 크게 네 가지로, 먼저 CPU 사용률은 처리 능력의 여유를 나타내며 지속적으로 높으면 병목의 신호입니다. 메모리 사용률은 애플리케이션이 사용 가능한 메모리와 스왑 발생 여부를 확인해 메모리 부족으로 인한 성능 저하를 예방합니다. 디스크 I/O는 읽기/쓰기 속도와 IOPS, 디스크 사용량을 확인해 저장소 병목을 파악하며, 네트워크 트래픽은 대역폭 사용량과 패킷 손실률, 지연시간을 모니터링해 네트워크 장애를 조기에 감지합니다. 이 외에도 애플리케이션 레벨에서는 응답시간, 에러율, 처리량(TPS) 같은 지표를 함께 모니터링하며, 임계치를 넘으면 알림이 발생하도록 설정하는 것이 실무의 기본입니다.
관련 개념 APM, 임계치 알림(Alerting), 스왑(Swap), TPS, 병목 현상
답안 클러스터링은 여러 대의 서버를 하나의 논리적인 시스템처럼 묶어 가용성 향상 또는 성능 향상을 목적으로 운영하는 기술입니다. 목적에 따라 장애 발생 시 다른 노드가 즉시 서비스를 이어받는 고가용성 클러스터(HA Cluster)와, 여러 노드가 작업을 나눠 처리해 처리 성능을 높이는 로드 밸런싱 클러스터로 구분할 수 있습니다. 클러스터 내 노드들은 하트비트(Heartbeat) 통신으로 서로의 상태를 감시하며, 특정 노드에 장애가 발생하면 이를 감지해 자동으로 다른 노드로 전환하는 방식으로 동작합니다. 데이터베이스 영역에서는 이러한 개념이 액티브-패시브 DB 클러스터나 분산 데이터베이스 클러스터 형태로 구현됩니다.
관련 개념 하트비트, HA 클러스터, VIP, 페일오버, 쿼럼(Quorum)
답안 가상화를 도입하면 하나의 물리 서버에서 여러 개의 독립된 서버 환경을 동시에 운영할 수 있어 하드웨어 자원 활용률을 크게 높일 수 있습니다. 또한 새로운 서버가 필요할 때 물리적인 하드웨어 구매·설치 없이 VM 이미지 복제나 템플릿을 통해 수 분 내에 프로비저닝할 수 있어 민첩성이 향상됩니다. 스냅샷 기능을 통해 특정 시점 상태로 손쉽게 롤백할 수 있고, 하나의 물리 서버에 장애가 발생해도 VM을 다른 물리 호스트로 마이그레이션(Live Migration)하여 서비스 중단을 최소화할 수 있습니다. 이러한 특성 덕분에 가상화는 클라우드 인프라의 기본 토대가 되며, 클라우드 제공업체는 이 위에 자동화된 프로비저닝과 과금 체계를 얹어 서비스를 제공합니다.
관련 개념 프로비저닝, 스냅샷, 라이브 마이그레이션, 자원 활용률, VM 템플릿
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 EC2(Elastic Compute Cloud)는 AWS의 대표적인 IaaS 서비스로, 가상 서버(인스턴스)를 필요한 만큼 생성해 사용할 수 있는 컴퓨팅 서비스입니다. 인스턴스를 생성할 때는 CPU·메모리 사양을 결정하는 인스턴스 타입, OS와 초기 소프트웨어가 담긴 AMI(Amazon Machine Image), 트래픽을 제어하는 보안 그룹, 그리고 데이터를 저장하는 EBS 볼륨을 함께 설정합니다. 인스턴스는 온디맨드, 예약 인스턴스, 스팟 인스턴스 등 다양한 과금 방식으로 사용할 수 있으며, 특정 AZ에 배치되기 때문에 고가용성을 위해서는 여러 AZ에 걸쳐 인스턴스를 분산 배치하는 것이 일반적입니다.
관련 개념 AMI, EBS, 보안 그룹, 인스턴스 타입, 탄력적 IP(EIP)
답안 S3(Simple Storage Service)는 파일을 객체(Object) 단위로 저장하는 오브젝트 스토리지 서비스로, 사실상 무제한에 가까운 확장성과 높은 내구성(설계상 매우 높은 데이터 내구성)을 제공합니다. 데이터는 버킷(Bucket)이라는 논리적 컨테이너 안에 키-값 형태로 저장되며, 파일 시스템처럼 계층 구조를 갖지는 않지만 접두어(Prefix)를 이용해 폴더처럼 관리할 수 있습니다. 접근 빈도에 따라 표준 스토리지, 접근 빈도가 낮은 데이터용 클래스, 장기 보관용 아카이브 클래스 등 여러 스토리지 클래스를 선택할 수 있어 비용을 최적화할 수 있으며, 정적 웹사이트 호스팅, 백업, 로그 저장, 빅데이터 원본 저장소 등 다양한 용도로 사용됩니다.
관련 개념 오브젝트 스토리지, 버킷 정책, 수명주기 정책(Lifecycle), 버저닝, 내구성/가용성
답안 VPC(Virtual Private Cloud)는 AWS 클라우드 내에 사용자가 논리적으로 격리된 가상 네트워크 공간을 구성할 수 있게 해주는 서비스로, IP 대역(CIDR), 서브넷, 라우팅 테이블, 게이트웨이 등을 자유롭게 설계할 수 있습니다. VPC가 필요한 이유는 각 리소스를 원하는 네트워크 구조로 격리하고 접근을 통제함으로써 보안성을 확보하고, 온프레미스 네트워크와 유사한 방식으로 퍼블릭/프라이빗 영역을 구분해 트래픽 흐름을 세밀하게 관리할 수 있기 때문입니다. VPC 내부는 서브넷 단위로 나뉘며, 인터넷 게이트웨이를 통해 외부와 통신하는 퍼블릭 서브넷과, 외부에서 직접 접근이 불가능한 프라이빗 서브넷으로 구성해 다계층 아키텍처(웹-앱-DB)를 설계하는 것이 일반적입니다.
관련 개념 CIDR, 서브넷, 라우팅 테이블, 인터넷 게이트웨이, NAT 게이트웨이
답안 IAM(Identity and Access Management)은 AWS 리소스에 대한 인증과 인가를 관리하는 서비스로, "누가 어떤 자원에 어떤 작업을 할 수 있는가"를 정의합니다. 사용자(User)는 개별 계정으로 사람이나 애플리케이션에 발급되며, 그룹(Group)은 여러 사용자를 묶어 동일한 권한을 일괄 부여할 때 사용합니다. 역할(Role)은 특정 개체(EC2 인스턴스, 다른 AWS 계정, Lambda 등)가 일시적으로 위임받아 사용하는 권한 집합으로, 고정된 자격 증명을 코드에 하드코딩하지 않고 안전하게 권한을 위임할 수 있습니다. 정책(Policy)은 JSON 형식으로 허용/거부할 작업과 리소스를 명시한 문서로, 최소 권한 원칙(Least Privilege)에 따라 필요한 권한만 부여하는 것이 보안 모범 사례입니다.
관련 개념 최소 권한 원칙, 역할 기반 접근제어(RBAC), Assume Role, 정책 문서(JSON), MFA
답안 RDS(Relational Database Service)는 MySQL, PostgreSQL, MariaDB 등 관계형 데이터베이스 엔진을 관리형으로 제공하는 서비스로, AWS가 백업, 패치, 장애 복구, 스케일링 같은 운영 작업을 대신 처리해줍니다. 자체 구축(EC2에 DB 설치) 대비 장점은 자동 백업과 스냅샷, 장애 발생 시 대기 인스턴스로 자동 전환하는 Multi-AZ 구성, 읽기 부하 분산을 위한 읽기 전용 복제본(Read Replica) 생성이 손쉽다는 점입니다. 또한 마이너 버전 패치나 보안 업데이트가 자동화되어 운영 부담이 크게 줄어듭니다. 다만 관리형 서비스이기 때문에 OS 레벨 접근이나 특정 엔진 설정에 대한 세밀한 커스터마이징에는 제약이 있을 수 있습니다.
관련 개념 Multi-AZ, Read Replica, 자동 백업, 관리형 서비스, 패치 관리
답안 CloudFront는 AWS의 CDN(Content Delivery Network) 서비스로, 전 세계에 분산된 엣지 로케이션(Edge Location)에 콘텐츠를 캐싱해 사용자와 물리적으로 가까운 위치에서 콘텐츠를 제공함으로써 지연시간을 줄이고 원본 서버(Origin)의 부하를 경감합니다. 정적 파일(이미지, CSS, JS)뿐 아니라 동적 콘텐츠도 배포할 수 있으며, S3나 EC2, 온프레미스 서버를 오리진으로 지정할 수 있습니다. 또한 HTTPS 처리를 엣지에서 담당하고, DDoS 방어나 WAF와 연동해 보안을 강화할 수 있으며, 오리진으로 향하는 요청 수를 줄여 비용 절감 효과도 있습니다. 글로벌 서비스를 운영할 때 사용자 경험 개선을 위한 필수 구성 요소로 자주 언급됩니다.
관련 개념 엣지 로케이션, 캐시 무효화(Invalidation), 오리진, TTL, WAF 연동
답안 Route 53은 AWS의 DNS(도메인 네임 시스템) 서비스로, 도메인 이름을 IP 주소로 변환해주는 역할과 함께 도메인 등록, 헬스체크, 트래픽 라우팅 기능을 제공합니다. 다양한 라우팅 정책을 지원하는데, 단순히 하나의 리소스로 연결하는 단순 라우팅, 여러 리소스에 가중치를 부여해 트래픽을 분산하는 가중치 기반 라우팅, 사용자와 가장 가까운 리전으로 연결하는 지연시간 기반 라우팅, 그리고 장애 발생 시 자동으로 대기 리소스로 전환하는 장애조치(Failover) 라우팅이 있습니다. 헬스체크 기능과 결합하면 특정 엔드포인트에 장애가 발생했을 때 자동으로 정상 엔드포인트로 트래픽을 우회시킬 수 있어 고가용성 아키텍처 구축에 활용됩니다.
관련 개념 DNS, 헬스체크, 가중치 기반 라우팅, 지연시간 기반 라우팅, Failover 라우팅
답안 공유 책임 모델은 클라우드 환경에서 보안 책임이 AWS와 고객 사이에 나뉘어 있다는 것을 명시한 원칙입니다. AWS는 "클라우드 자체의 보안(Security OF the Cloud)"을 책임지는데, 여기에는 데이터센터의 물리적 보안, 하드웨어, 네트워크 인프라, 가상화 계층 등이 포함됩니다. 반면 고객은 "클라우드 내부의 보안(Security IN the Cloud)"을 책임지는데, 여기에는 OS 패치, 애플리케이션 보안 설정, 데이터 암호화, IAM 권한 관리, 보안 그룹 및 네트워크 ACL 설정 등이 포함됩니다. 서비스 모델(IaaS/PaaS/SaaS)에 따라 고객이 책임지는 범위가 달라지며, 관리형 서비스일수록 AWS가 더 많은 부분을 책임집니다. 실제 보안 사고의 상당수가 고객 측 설정 실수(예: 잘못된 S3 버킷 권한)에서 발생하기 때문에 면접에서 중요하게 다뤄집니다.
관련 개념 Security of/in the Cloud, IAM, 데이터 암호화, 보안 그룹, 컴플라이언스
답안 Lambda는 AWS의 대표적인 서버리스(FaaS) 서비스로, 서버를 직접 프로비저닝하지 않고 이벤트가 발생했을 때 정의된 함수 코드를 실행해주는 컴퓨팅 서비스입니다. S3 파일 업로드, API Gateway를 통한 HTTP 요청, DynamoDB 데이터 변경, 스케줄(EventBridge) 등 다양한 이벤트 트리거에 반응해 실행되며, 실행 시간만큼만 과금되어 트래픽이 없을 때는 비용이 발생하지 않습니다. 이미지 리사이징, 실시간 데이터 처리, 간단한 API 백엔드 등 짧고 이벤트 기반인 작업에 적합하지만, 최대 실행 시간 제한과 콜드 스타트 지연이 있어 장시간 실행되는 배치 작업이나 상시 연결이 필요한 서비스에는 적합하지 않습니다.
관련 개념 FaaS, 이벤트 트리거, API Gateway, 콜드 스타트, EventBridge
답안 CloudWatch는 AWS 리소스와 애플리케이션의 모니터링 및 로깅을 담당하는 서비스로, EC2의 CPU/메모리 사용률, RDS의 커넥션 수, Lambda의 실행 시간 등 다양한 메트릭을 수집하고 시각화합니다. 특정 임계치를 초과하면 알람(Alarm)을 발생시켜 SNS를 통해 담당자에게 통지하거나, 오토스케일링과 연동해 자동으로 인스턴스를 증설·축소할 수 있습니다. 또한 CloudWatch Logs를 통해 애플리케이션 로그를 중앙에서 수집·검색할 수 있어 장애 발생 시 원인 분석에 활용됩니다. 인프라 운영에서 장애를 조기에 감지하고 자동 대응 체계를 구축하는 핵심 도구이기 때문에, 실무 면접에서는 "어떤 지표를 어떻게 모니터링할 것인지"를 함께 묻는 경우가 많습니다.
관련 개념 메트릭, 알람(Alarm), CloudWatch Logs, 오토스케일링 연동, SNS
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 EC2 인스턴스 생성 시에는 먼저 OS와 기본 소프트웨어가 담긴 AMI를 선택하고, 워크로드 특성(CPU 집약적, 메모리 집약적, 범용 등)에 맞는 인스턴스 타입을 결정합니다. 이후 인스턴스가 위치할 VPC와 서브넷(퍼블릭 또는 프라이빗)을 지정하고, 트래픽 접근을 제어할 보안 그룹을 설정하며, SSH 접속에 사용할 키 페어를 생성하거나 선택합니다. 스토리지 항목에서는 EBS 볼륨의 크기와 타입(범용 SSD, 프로비저닝된 IOPS 등)을 결정하고, 필요시 초기 설정 스크립트를 자동 실행하는 User Data를 등록합니다. 마지막으로 인스턴스에 부여할 IAM 역할을 지정해 다른 AWS 서비스에 접근할 권한을 안전하게 위임합니다.
관련 개념 AMI, 키 페어, EBS, User Data, IAM 역할
답안 보안 그룹은 인스턴스 단위(ENI 단위)로 동작하는 가상 방화벽으로 상태 저장(Stateful) 방식이기 때문에, 인바운드 요청을 허용하면 그에 대한 응답 트래픽은 아웃바운드 규칙과 무관하게 자동으로 허용됩니다. 또한 허용(Allow) 규칙만 설정할 수 있고 거부(Deny) 규칙은 지정할 수 없습니다. 네트워크 ACL은 서브넷 단위로 동작하며 상태 비저장(Stateless) 방식이기 때문에 인바운드와 아웃바운드 규칙을 각각 명시적으로 설정해야 하고, 허용과 거부 규칙을 모두 지정할 수 있으며 규칙 번호 순서대로 평가됩니다. 실무에서는 보안 그룹으로 인스턴스 단위의 세밀한 접근 제어를 하고, NACL로 서브넷 단위의 넓은 범위의 차단(예: 특정 악성 IP 대역 전체 차단)을 보완적으로 사용합니다.
관련 개념 Stateful/Stateless, ENI, 서브넷 단위 제어, 규칙 우선순위, 인바운드/아웃바운드
답안 퍼블릭 서브넷은 라우팅 테이블에 인터넷 게이트웨이(IGW)로 향하는 경로(0.0.0.0/0 → IGW)가 설정되어 있어 외부 인터넷과 직접 통신이 가능한 서브넷으로, 로드밸런서나 배스천 호스트처럼 외부에서 접근이 필요한 리소스를 배치합니다. 프라이빗 서브넷은 IGW로 향하는 직접 경로가 없어 외부에서 직접 접근할 수 없는 서브넷으로, 데이터베이스나 내부 애플리케이션 서버처럼 보안이 중요한 리소스를 배치합니다. 프라이빗 서브넷의 리소스가 외부로 나가는 트래픽(예: 패키지 업데이트)이 필요할 경우, 퍼블릭 서브넷에 위치한 NAT 게이트웨이를 경유하도록 라우팅 테이블을 구성해 외부 요청은 가능하지만 외부에서의 인바운드 접근은 차단하는 구조로 설계합니다. 이러한 구조는 일반적으로 웹(퍼블릭)-앱(프라이빗)-DB(프라이빗)의 다계층 아키텍처로 확장됩니다.
관련 개념 인터넷 게이트웨이, NAT 게이트웨이, 라우팅 테이블, 배스천 호스트, 다계층 아키텍처
답안
최소 권한 원칙은 사용자나 역할에게 업무 수행에 반드시 필요한 권한만 부여하고 그 이상은 허용하지 않는 보안 원칙입니다. 실무에서는 먼저 관리형 정책 중 광범위한 권한을 가진 AdministratorAccess 같은 정책 대신, 필요한 서비스와 액션만 명시한 사용자 지정(Customer Managed) 정책을 작성합니다. 정책 문서에서는 Effect(허용/거부), Action(허용할 API 동작), Resource(대상 리소스의 ARN)를 구체적으로 명시하며, 가능하다면 특정 리소스 ARN이나 조건(Condition, 예: 특정 IP 대역에서만 접근 허용)을 추가해 범위를 더욱 좁힙니다. 또한 정기적으로 IAM Access Analyzer 등을 통해 실제 사용되지 않는 과도한 권한을 점검하고 축소하는 것이 모범 사례입니다.
관련 개념 관리형 정책 vs 사용자 지정 정책, ARN, Condition 키, Access Analyzer
답안 오토스케일링 그룹(ASG)은 CloudWatch 지표(예: 평균 CPU 사용률)를 기준으로 EC2 인스턴스 수를 자동으로 증가시키거나 감소시키는 기능입니다. ASG는 최소 용량, 최대 용량, 원하는 용량(Desired Capacity)을 설정하며, 시작 템플릿(Launch Template)을 통해 새로 생성될 인스턴스의 AMI, 인스턴스 타입, 보안 그룹 등을 미리 정의해둡니다. 스케일링 정책은 CPU 사용률이 특정 임계치를 초과하면 인스턴스를 추가하는 동적 스케일링, 특정 시간대에 미리 용량을 조정하는 예약 스케일링, 목표 지표 값을 유지하도록 자동 조절하는 목표 추적 스케일링 등이 있습니다. ASG는 일반적으로 로드밸런서와 연동되어, 새로 생성된 인스턴스가 자동으로 대상 그룹에 등록되고 헬스체크를 통과해야 트래픽을 받도록 구성합니다.
관련 개념 Launch Template, 목표 추적 스케일링, Desired Capacity, 대상 그룹(Target Group), 쿨다운
답안 일반적인 연동 구조는 사용자 요청이 ALB로 먼저 도착하고, ALB는 등록된 대상 그룹(Target Group) 내의 여러 EC2 인스턴스로 트래픽을 분산합니다. ALB는 주기적으로 각 인스턴스에 헬스체크 요청을 보내 응답이 정상인 인스턴스에만 트래픽을 전달하고, 비정상 인스턴스는 자동으로 대상에서 제외합니다. 이 대상 그룹은 오토스케일링 그룹(ASG)과 연결되어 있어서, ASG가 트래픽 증가에 따라 새 인스턴스를 생성하면 자동으로 대상 그룹에 등록되고, 인스턴스를 종료할 때도 자동으로 대상 그룹에서 제거됩니다. 이러한 구조를 통해 트래픽 변화에 유연하게 대응하면서도 특정 인스턴스 장애가 전체 서비스 장애로 이어지지 않는 고가용성 아키텍처를 구현할 수 있으며, 여러 AZ에 걸쳐 인스턴스를 분산 배치하면 AZ 장애에도 대응할 수 있습니다.
관련 개념 Target Group, 헬스체크, 크로스 존 로드밸런싱, Multi-AZ 배포
답안 배스천 호스트는 프라이빗 서브넷에 있는 서버들에 직접 접근할 수 없는 상황에서 안전하게 접속하기 위한 중계 서버로, 퍼블릭 서브넷에 위치해 외부에서 SSH나 RDP로 접속할 수 있는 유일한 진입점 역할을 합니다. 관리자는 먼저 배스천 호스트에 접속한 뒤, 그곳을 경유해 프라이빗 서브넷의 인스턴스에 접속함으로써 프라이빗 리소스를 외부에 직접 노출하지 않고도 관리할 수 있습니다. 보안을 강화하기 위해 배스천 호스트의 보안 그룹은 특정 관리자 IP 대역에서만 접근을 허용하도록 제한하는 것이 일반적이며, 최근에는 배스천 호스트를 별도로 운영하지 않고 AWS Systems Manager Session Manager를 이용해 SSH 포트를 아예 열지 않고도 안전하게 접속하는 방식이 권장되기도 합니다.
관련 개념 Session Manager, 점프 서버, SSH 터널링, 프라이빗 서브넷 접근 제어
답안 VPC 피어링은 서로 다른 두 VPC 간에 프라이빗 네트워크 연결을 맺어 마치 같은 네트워크에 있는 것처럼 서로 통신할 수 있게 해주는 기능으로, 인터넷을 거치지 않고 VPC와 VPC를 직접 연결할 때 사용합니다. 다만 피어링은 전이적(transitive)이지 않아서 A-B, B-C가 피어링되어 있어도 A와 C는 직접 통신할 수 없다는 제약이 있습니다. VPC 엔드포인트는 VPC 내부에서 인터넷 게이트웨이나 NAT 게이트웨이를 거치지 않고 S3, DynamoDB 같은 AWS 서비스에 프라이빗하게 직접 접근할 수 있게 해주는 기능으로, 프라이빗 서브넷에서도 인터넷 경유 없이 AWS 서비스를 안전하게 이용할 수 있게 해줍니다. 두 기능 모두 트래픽을 인터넷에 노출시키지 않아 보안성과 지연시간 측면에서 이점이 있습니다.
관련 개념 전이적 라우팅 제약, Gateway 엔드포인트, Interface 엔드포인트, Transit Gateway
답안 EBS(Elastic Block Store)는 EC2 인스턴스에 연결되는 네트워크 기반 블록 스토리지로, 인스턴스와 독립적으로 존재하기 때문에 인스턴스가 종료되어도 데이터를 유지할 수 있습니다(설정에 따라 다름). 백업 전략의 핵심은 EBS 스냅샷으로, 특정 시점의 볼륨 상태를 S3에 증분 방식으로 저장하며 이후 스냅샷은 이전 스냅샷과의 변경분만 저장해 비용과 시간을 절약합니다. 스냅샷을 이용하면 동일한 볼륨을 다른 AZ나 리전에 복제해 새로운 인스턴스를 생성할 수 있어 재해복구나 환경 복제에 활용됩니다. 실무에서는 AWS Backup이나 수명주기 정책을 이용해 정기적인 스냅샷 생성과 오래된 스냅샷의 자동 삭제를 자동화하는 것이 일반적입니다.
관련 개념 증분 스냅샷, AWS Backup, 볼륨 복제, 리전 간 복제, 수명주기 정책
답안 먼저 사용자 트래픽을 받는 웹 계층은 퍼블릭 서브넷에 ALB를 배치하고, 그 뒤에 오토스케일링 그룹으로 관리되는 웹 서버 EC2 인스턴스를 여러 AZ에 걸쳐 배치합니다. 애플리케이션 계층은 프라이빗 서브넷에 위치시켜 외부에서 직접 접근할 수 없도록 하고, 웹 계층에서만 트래픽이 유입되도록 보안 그룹을 설정하며, 필요시 내부 로드밸런서로 트래픽을 분산합니다. 데이터베이스 계층은 더 깊은 프라이빗 서브넷에 RDS를 Multi-AZ로 구성해 배치하고, 애플리케이션 계층에서만 접근 가능하도록 보안 그룹을 제한합니다. 전체적으로 각 계층은 서로 다른 서브넷과 보안 그룹으로 격리되어 있으며, 외부에서 접근 가능한 것은 웹 계층뿐이라는 것이 이 아키텍처의 핵심 보안 설계 원칙입니다.
관련 개념 다계층 아키텍처, 서브넷 분리, 보안 그룹 체이닝, Multi-AZ RDS, 최소 노출 원칙
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 VM은 하이퍼바이저 위에서 각각 독립된 게스트 OS 전체를 실행하기 때문에 격리 수준이 높지만 이미지 용량이 크고 부팅에 수십 초 이상이 걸립니다. 컨테이너는 호스트 OS의 커널을 공유하면서 프로세스, 파일시스템, 네트워크 등을 격리된 네임스페이스로 분리해 실행하기 때문에 이미지 용량이 작고 수 초 이내에 시작할 수 있습니다. 이러한 차이로 컨테이너는 하나의 호스트에서 훨씬 더 많은 인스턴스를 동시에 실행할 수 있어 자원 효율이 뛰어나며, 마이크로서비스 아키텍처와 궁합이 좋습니다. 다만 커널을 공유하기 때문에 완전히 다른 OS(예: 리눅스 컨테이너를 윈도우 커널에서)를 직접 실행할 수는 없고, VM 대비 격리 수준이 상대적으로 낮다는 한계가 있습니다.
관련 개념 네임스페이스, cgroups, 커널 공유, 부팅 속도, 마이크로서비스
답안 Docker 이미지는 컨테이너 실행에 필요한 애플리케이션 코드, 라이브러리, 환경설정을 모두 포함한 읽기 전용 템플릿입니다. 이미지는 Dockerfile의 각 명령어(RUN, COPY 등)마다 하나씩 생성되는 레이어들이 쌓여 만들어지며, 각 레이어는 이전 레이어와의 차이만 저장하는 방식으로 동작합니다. 이러한 레이어 구조 덕분에 여러 이미지가 동일한 레이어를 공유(캐싱)할 수 있어 저장 공간을 절약하고, 이미지를 빌드할 때 변경되지 않은 레이어는 캐시를 재사용해 빌드 속도를 크게 높일 수 있습니다. 컨테이너가 실행될 때는 이 읽기 전용 레이어들 위에 쓰기 가능한 컨테이너 레이어가 하나 추가되어, 컨테이너 내부에서 발생하는 변경사항은 이 최상위 레이어에만 기록됩니다.
관련 개념 Union File System, 빌드 캐시, Copy-on-Write, 읽기 전용 레이어
답안
FROM은 이미지의 베이스 이미지를 지정하는 명령어로 Dockerfile의 첫 줄에 위치합니다. RUN은 이미지 빌드 시점에 실행할 명령어(패키지 설치 등)를 정의하며 실행 결과가 새로운 레이어로 저장됩니다. COPY는 호스트의 파일이나 디렉토리를 이미지 내부로 복사하고, ADD는 COPY와 유사하지만 압축 해제나 URL 다운로드 같은 추가 기능을 지원합니다. CMD는 컨테이너가 실행될 때 기본으로 수행할 명령어를 지정하며 docker run 시 인자로 덮어쓸 수 있는 반면, ENTRYPOINT는 컨테이너의 주 실행 파일을 고정하는 용도로 사용됩니다. 이 외에 WORKDIR(작업 디렉토리 지정), EXPOSE(사용 포트 명시), ENV(환경변수 설정)도 자주 사용되는 명령어입니다.
관련 개념 베이스 이미지, CMD vs ENTRYPOINT, WORKDIR, 빌드 컨텍스트
답안 컨테이너는 삭제되면 컨테이너 레이어에 기록된 모든 데이터가 함께 사라지는 휘발성(Stateless) 특성을 갖기 때문에, 데이터베이스 파일처럼 영속적으로 유지해야 하는 데이터는 컨테이너 외부에 별도로 저장해야 합니다. 이를 해결하는 것이 볼륨으로, 대표적으로 Docker가 관리하는 전용 저장 영역을 사용하는 볼륨(Volume) 방식, 호스트의 특정 디렉토리를 컨테이너에 직접 연결하는 바인드 마운트(Bind Mount) 방식, 그리고 메모리 기반의 임시 저장 영역인 tmpfs 마운트가 있습니다. 볼륨 방식은 Docker가 생명주기를 관리해 백업이나 마이그레이션이 용이하고 여러 컨테이너 간 데이터 공유에도 적합해 프로덕션 환경에서 권장되며, 바인드 마운트는 개발 중 소스코드를 실시간으로 반영할 때 유용합니다.
관련 개념 바인드 마운트, tmpfs, 데이터 영속성, 컨테이너 생명주기
답안
bridge는 Docker의 기본 네트워크 모드로, 컨테이너마다 격리된 가상 네트워크 인터페이스를 부여하고 내부 브리지를 통해 호스트 및 다른 컨테이너와 통신하며, 외부와 통신하려면 포트 매핑(-p)이 필요합니다. host 모드는 컨테이너가 별도의 네트워크 네임스페이스를 갖지 않고 호스트의 네트워크를 그대로 공유하는 방식으로, 포트 매핑 없이 호스트의 포트를 바로 사용할 수 있어 성능은 좋지만 격리성이 낮아지고 포트 충돌 위험이 있습니다. none 모드는 컨테이너에 네트워크 인터페이스를 아예 부여하지 않아 외부와 통신이 완전히 차단되며, 네트워크가 필요 없는 배치 작업 등에 사용됩니다. 이 외에도 여러 컨테이너를 같은 네트워크 네임스페이스로 묶는 container 모드나 사용자 정의 브리지 네트워크도 실무에서 자주 사용됩니다.
관련 개념 포트 매핑, 사용자 정의 브리지, 네트워크 네임스페이스, 컨테이너 간 통신
답안
Docker 이미지의 태그는 동일한 이미지 이름 안에서 버전을 구분하는 식별자로, 이미지명:태그 형식으로 표기됩니다. latest는 태그를 명시하지 않았을 때 기본으로 적용되는 태그일 뿐 "항상 최신 버전"을 보장하는 특별한 의미를 가진 것이 아니며, 빌드 시점에 따라 실제 내용이 계속 바뀔 수 있습니다. 프로덕션 환경에서 latest를 그대로 사용하면 어떤 버전이 배포되어 있는지 추적이 어렵고, 재배포 시 의도치 않게 다른 버전이 배포될 위험이 있습니다. 따라서 실무에서는 커밋 해시나 시맨틱 버전(예: v1.2.3)처럼 명시적이고 고유한 태그를 사용해 배포 이력을 추적 가능하게 관리하는 것이 권장됩니다.
관련 개념 시맨틱 버저닝, 이미지 다이제스트(digest), 태그 불변성, 배포 추적성
답안 Docker 컨테이너의 격리는 리눅스 커널의 두 가지 핵심 기능으로 구현됩니다. 네임스페이스(Namespace)는 프로세스, 네트워크, 마운트, 사용자 등 시스템 자원을 논리적으로 분리해 각 컨테이너가 독립된 환경(자신만의 PID 목록, 자신만의 네트워크 인터페이스 등)을 가진 것처럼 보이게 합니다. cgroups(Control Groups)는 CPU, 메모리, 디스크 I/O 같은 물리적 자원의 사용량을 제한하고 격리하는 기능으로, 특정 컨테이너가 과도한 자원을 사용해 다른 컨테이너나 호스트에 영향을 주지 않도록 통제합니다. 즉 네임스페이스가 "무엇이 보이는가"를 격리한다면 cgroups는 "얼마나 사용할 수 있는가"를 제어하는 역할을 하며, 이 두 기술의 조합이 컨테이너 격리의 근간을 이룹니다.
관련 개념 PID 네임스페이스, 네트워크 네임스페이스, 자원 제한, chroot
답안 Docker Hub는 Docker에서 공식 제공하는 퍼블릭 이미지 저장소로, 공식 베이스 이미지(Ubuntu, Nginx, MySQL 등)나 커뮤니티가 배포한 이미지를 검색하고 내려받을 수 있는 공간입니다. 다만 기업 내부에서 개발한 애플리케이션 이미지를 외부에 공개된 저장소에 올리는 것은 보안상 바람직하지 않기 때문에, 조직 내부 전용으로 프라이빗 레지스트리를 구축하거나 클라우드 제공업체의 관리형 레지스트리(예: ECR)를 사용합니다. 프라이빗 레지스트리는 접근 권한을 세밀하게 통제할 수 있고, CI/CD 파이프라인과 연동해 빌드된 이미지를 자동으로 푸시·배포하는 워크플로우의 핵심 구성요소로 사용됩니다.
관련 개념 이미지 push/pull, ECR, 이미지 스캐닝, CI/CD 연동
답안
이미지 크기를 줄이기 위한 대표적인 방법은 먼저 알파인 리눅스(Alpine)처럼 경량화된 베이스 이미지를 선택하는 것입니다. 또한 여러 개의 RUN 명령어를 &&로 연결해 하나의 레이어로 묶으면 불필요한 중간 레이어 생성을 줄일 수 있고, 패키지 설치 후 캐시 파일이나 임시 파일을 같은 레이어 안에서 즉시 삭제해야 실제로 이미지 크기가 줄어듭니다. 빌드에만 필요한 도구와 실행에 필요한 파일을 분리하는 멀티스테이지 빌드를 사용하면 최종 이미지에는 실행에 필요한 산출물만 남길 수 있어 크기를 크게 줄일 수 있습니다. 또한 .dockerignore 파일을 작성해 불필요한 파일이 빌드 컨텍스트에 포함되지 않도록 하는 것도 빌드 속도와 이미지 크기 관리에 도움이 됩니다.
관련 개념 Alpine 이미지, 멀티스테이지 빌드, .dockerignore, 레이어 병합
답안 컨테이너는 언제든 재시작되거나 다른 노드로 재배치될 수 있기 때문에, 애플리케이션의 상태(세션 정보, 업로드 파일 등)를 컨테이너 내부에만 저장하면 컨테이너가 사라질 때 데이터도 함께 유실됩니다. Stateless 설계는 애플리케이션 자체는 상태를 갖지 않도록 하고, 세션 정보는 Redis 같은 외부 저장소에, 파일은 S3 같은 외부 스토리지에, 영속 데이터는 별도의 데이터베이스에 저장하는 방식입니다. 이렇게 설계하면 컨테이너를 자유롭게 확장(스케일 아웃)하거나 장애 시 새 컨테이너로 즉시 교체할 수 있어 쿠버네티스 같은 오케스트레이션 환경에서 무중단 배포와 자동 복구가 가능해집니다. 결과적으로 Stateless 설계는 컨테이너 기반 아키텍처의 확장성과 복원력을 뒷받침하는 핵심 원칙입니다.
관련 개념 외부 세션 저장소, 12 Factor App, 무중단 배포, 오케스트레이션
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안
docker-compose는 여러 개의 컨테이너로 구성된 애플리케이션을 하나의 YAML 파일로 정의하고, 단일 명령어로 전체를 함께 생성·실행·종료할 수 있게 해주는 도구입니다. 예를 들어 웹 서버, 애플리케이션 서버, 데이터베이스, 캐시 서버가 각각 별도의 컨테이너로 실행되는 애플리케이션에서, 각 서비스의 이미지, 환경변수, 포트, 볼륨, 의존 관계(depends_on)를 하나의 파일에 정의해두면 docker compose up 한 번으로 전체 스택을 손쉽게 실행할 수 있습니다. 이는 특히 로컬 개발 환경 구성이나 간단한 테스트 환경 배포에 유용하며, docker-compose는 기본적으로 컨테이너 간 통신을 위한 전용 네트워크를 자동으로 생성해 서비스 이름만으로 서로를 참조할 수 있게 해줍니다. 다만 다중 호스트에 걸친 대규모 오케스트레이션에는 적합하지 않아 그런 경우에는 쿠버네티스를 사용합니다.
관련 개념 YAML 정의, depends_on, 서비스 디스커버리, 단일 호스트 오케스트레이션
답안
멀티스테이지 빌드는 하나의 Dockerfile 안에 여러 개의 FROM 단계를 두어, 빌드 환경과 실행 환경을 분리하는 기법입니다. 예를 들어 첫 번째 스테이지에서는 컴파일러나 빌드 도구가 포함된 무거운 이미지로 소스코드를 빌드하고, 두 번째 스테이지에서는 실행에 필요한 최소한의 런타임 이미지에 첫 번째 스테이지에서 생성된 산출물(바이너리, 정적 파일 등)만 COPY --from으로 복사해옵니다. 이렇게 하면 최종 이미지에는 빌드 도구나 소스코드, 중간 산출물이 전혀 남지 않아 이미지 크기를 대폭 줄이고 공격 표면(불필요한 도구로 인한 보안 취약점)도 줄일 수 있습니다. Java, Go, Node.js처럼 빌드와 실행 환경이 다른 언어의 컨테이너화에서 특히 널리 사용되는 기법입니다.
관련 개념 COPY --from, 빌드 환경/런타임 환경 분리, 공격 표면 축소, 이미지 경량화
답안
Docker는 리눅스 cgroups를 이용해 컨테이너별로 CPU와 메모리 사용량을 제한할 수 있습니다. docker run 실행 시 --memory 옵션으로 최대 메모리 사용량을, --cpus 옵션으로 사용할 수 있는 CPU 코어 수를 제한할 수 있으며, docker-compose에서도 deploy.resources 항목으로 동일하게 설정할 수 있습니다. 리소스 제한이 필요한 이유는 하나의 호스트에서 여러 컨테이너가 함께 실행될 때, 특정 컨테이너가 메모리 누수나 무한 루프로 인해 자원을 독점하면 다른 컨테이너나 호스트 자체에 영향을 줄 수 있기 때문입니다(Noisy Neighbor 문제). 메모리 제한을 초과하면 컨테이너 내 프로세스가 OOM Killer에 의해 강제 종료되므로, 애플리케이션의 실제 사용량을 모니터링한 뒤 적절한 여유를 두고 제한값을 설정하는 것이 중요합니다.
관련 개념 cgroups, OOM Killer, Noisy Neighbor, requests/limits(쿠버네티스 연계)
답안
Docker는 컨테이너의 표준 출력(stdout)과 표준 에러(stderr)를 로그로 자동 수집하며, docker logs 명령어로 확인할 수 있습니다. 기본 로깅 드라이버는 json-file이지만, 컨테이너가 많아지고 여러 호스트에 분산될 경우 각 호스트에 로그가 흩어져 있어 통합 분석이 어려워지므로, 실무에서는 로그를 중앙 집중화하는 것이 일반적입니다. 대표적으로 Fluentd나 Logstash 같은 로그 수집기를 통해 로그를 Elasticsearch에 적재하고 Kibana로 시각화하는 ELK/EFK 스택을 사용하거나, 클라우드 환경에서는 CloudWatch Logs 같은 관리형 로그 서비스로 전송합니다. 모니터링 측면에서는 컨테이너의 CPU/메모리 사용률을 확인할 수 있는 docker stats 외에, Prometheus와 Grafana를 이용해 메트릭을 수집하고 대시보드로 시각화하는 방식이 널리 사용됩니다.
관련 개념 로깅 드라이버, ELK/EFK 스택, Prometheus/Grafana, 중앙 집중 로깅
답안 이미지 보안 관리를 위해서는 먼저 신뢰할 수 없는 출처의 베이스 이미지를 사용하지 않고, 공식 이미지나 검증된 이미지를 사용하는 것이 기본입니다. 이미지에 알려진 취약점(CVE)이 포함되어 있는지 CI/CD 파이프라인에 이미지 스캐닝 단계를 추가해 빌드나 배포 전에 자동으로 검사하며, 취약점이 발견된 이미지는 배포를 차단하도록 정책을 설정합니다. 또한 컨테이너 안에서 불필요하게 root 권한으로 프로세스를 실행하지 않도록 Dockerfile에 별도 사용자를 생성해 지정하고, 민감한 정보(API 키, 비밀번호)를 이미지에 하드코딩하지 않고 환경변수나 시크릿 관리 도구를 통해 런타임에 주입해야 합니다. 레지스트리 접근 권한도 최소 권한 원칙에 따라 통제하고, 이미지에 서명을 추가해 신뢰된 이미지만 배포되도록 하는 것도 보안 강화 방법입니다.
관련 개념 CVE 스캐닝, non-root 사용자, 시크릿 관리, 이미지 서명
답안
docker-compose는 실행 시 기본적으로 프로젝트 전용의 사용자 정의 브리지 네트워크를 자동 생성하며, 같은 네트워크에 속한 서비스들은 IP 주소가 아닌 서비스 이름을 호스트명처럼 사용해 서로 통신할 수 있습니다(내장 DNS를 통한 서비스 디스커버리). 서비스 간 실행 순서를 제어하려면 depends_on을 사용해 특정 서비스가 먼저 시작되도록 지정할 수 있지만, 이는 컨테이너의 "시작"만 보장할 뿐 애플리케이션이 실제로 요청을 받을 준비가 되었는지는 보장하지 않기 때문에, 데이터베이스처럼 초기화 시간이 필요한 서비스는 healthcheck와 condition: service_healthy를 함께 사용해 실제 준비 상태까지 확인하는 것이 안전합니다. 이러한 메커니즘 덕분에 개발자는 IP 관리 없이 서비스 이름만으로 안정적인 멀티 컨테이너 애플리케이션을 구성할 수 있습니다.
관련 개념 서비스 디스커버리, 내장 DNS, healthcheck, depends_on 한계
답안
컨테이너가 정상적으로 실행 중(Running)이라는 상태와, 애플리케이션이 실제로 정상 동작하며 요청을 처리할 수 있는 상태는 다를 수 있습니다. 예를 들어 프로세스는 살아있지만 내부 로직이 무한 대기 상태에 빠져 응답하지 못하는 경우가 있는데, 이를 감지하기 위해 Dockerfile이나 docker-compose에 HEALTHCHECK 명령어를 정의해 주기적으로 특정 명령(예: HTTP 엔드포인트 호출)을 실행하고 그 결과로 컨테이너의 건강 상태를 판단합니다. 헬스체크가 실패하면 컨테이너 상태가 unhealthy로 표시되며, 이를 오케스트레이션 도구나 로드밸런서와 연동하면 비정상 컨테이너를 트래픽 대상에서 자동으로 제외하거나 재시작할 수 있습니다. 이는 쿠버네티스의 liveness/readiness probe와 개념적으로 동일한 역할을 합니다.
관련 개념 HEALTHCHECK 명령어, unhealthy 상태, liveness/readiness probe, 자동 재시작
답안 전형적인 컨테이너 CI/CD 파이프라인은 개발자가 소스코드를 저장소에 푸시하면 시작됩니다. CI(지속적 통합) 단계에서는 코드를 빌드하고 단위 테스트를 실행한 뒤, 문제가 없으면 Dockerfile을 기반으로 이미지를 빌드하고 취약점 스캔을 거쳐 고유한 태그(커밋 해시 등)를 붙여 컨테이너 레지스트리에 푸시합니다. CD(지속적 배포) 단계에서는 새로 푸시된 이미지를 실제 운영 환경(쿠버네티스 클러스터나 EC2 등)에 배포하는데, 이때 롤링 업데이트나 블루-그린 배포 전략을 사용해 무중단으로 새 버전을 반영합니다. 이러한 파이프라인은 GitHub Actions, Jenkins, GitLab CI 같은 도구로 자동화되며, 배포 후에는 헬스체크와 모니터링을 통해 정상 동작을 확인하고 문제 발생 시 이전 버전으로 신속히 롤백할 수 있는 체계를 갖추는 것이 중요합니다.
관련 개념 CI/CD 파이프라인, 롤링 업데이트, 블루-그린 배포, 롤백
답안 여러 컨테이너가 동일한 데이터를 공유해야 하는 경우, Docker의 명명된 볼륨(Named Volume)을 생성해 여러 컨테이너의 마운트 경로에 동일한 볼륨을 연결하면 됩니다. 예를 들어 로그를 생성하는 애플리케이션 컨테이너와 이를 수집하는 로그 수집 컨테이너가 같은 볼륨을 공유하도록 구성하면, 컨테이너 간 프로세스 격리는 유지하면서도 파일 시스템 레벨에서 데이터를 주고받을 수 있습니다. 다만 단일 호스트를 벗어나 여러 노드에 컨테이너가 분산된 환경(쿠버네티스 등)에서는 로컬 볼륨만으로는 데이터 공유가 어렵기 때문에, NFS 같은 네트워크 파일시스템이나 클라우드의 관리형 파일 스토리지를 이용한 분산 스토리지 솔루션이 필요합니다.
관련 개념 Named Volume, NFS, 분산 스토리지, PersistentVolume(쿠버네티스 연계)
답안
가장 흔한 실수는 비밀번호나 API 키를 Dockerfile에 하드코딩하거나 이미지 자체에 포함시키는 것으로, 이미지가 유출되면 시크릿도 함께 노출되므로 반드시 피해야 합니다. 대신 런타임에 환경변수로 주입하는 방법이 있지만, 환경변수는 docker inspect나 프로세스 정보를 통해 노출될 위험이 있어 완전히 안전하지는 않습니다. 더 안전한 방법은 Docker Swarm의 secrets 기능이나 쿠버네티스의 Secret 오브젝트처럼 전용 시크릿 관리 메커니즘을 이용해 파일 형태로 컨테이너 내부의 특정 경로에만 마운트하는 방식이며, 대규모 조직에서는 HashiCorp Vault나 AWS Secrets Manager 같은 외부 시크릿 관리 서비스와 연동해 시크릿을 중앙에서 관리하고 접근 이력을 감사하는 방식을 사용합니다.
관련 개념 Docker secrets, 쿠버네티스 Secret, HashiCorp Vault, Secrets Manager
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 쿠버네티스(Kubernetes)는 다수의 컨테이너를 여러 서버(노드)에 걸쳐 자동으로 배포, 확장, 관리해주는 컨테이너 오케스트레이션 플랫폼입니다. docker-compose가 단일 호스트에서의 멀티 컨테이너 관리에 초점을 둔다면, 쿠버네티스는 여러 대의 서버를 하나의 클러스터로 묶어 컨테이너가 어느 노드에서 실행될지 자동으로 스케줄링하고, 장애가 발생한 컨테이너를 자동으로 재시작하며, 트래픽 증가에 따라 컨테이너 수를 자동으로 조절합니다. 대규모 마이크로서비스 아키텍처에서는 수백, 수천 개의 컨테이너를 수동으로 관리하는 것이 불가능하기 때문에, 쿠버네티스가 제공하는 자동 복구(Self-healing), 선언적 배포, 오토스케일링 기능이 필수적입니다.
관련 개념 컨테이너 오케스트레이션, 선언적 구성(Declarative), Self-healing, 클러스터
답안 Pod는 쿠버네티스에서 배포할 수 있는 최소 단위로, 하나 이상의 컨테이너를 포함하며 같은 Pod 안의 컨테이너들은 네트워크(같은 IP, 포트 공간)와 스토리지(볼륨)를 공유합니다. 컨테이너 자체가 아닌 Pod를 최소 단위로 삼은 이유는, 서로 밀접하게 연관되어 항상 함께 배포되고 함께 스케일링되어야 하는 컨테이너들(예: 메인 애플리케이션과 로그 수집 사이드카)을 하나의 논리적 단위로 묶어 관리할 필요가 있기 때문입니다. 대부분의 Pod는 하나의 컨테이너만 포함하지만, 사이드카 패턴처럼 보조 컨테이너를 함께 배치해야 하는 경우 멀티 컨테이너 Pod를 구성합니다. Pod는 기본적으로 일시적(Ephemeral)인 존재로, 삭제되면 새로운 IP를 가진 새 Pod로 교체된다는 특징이 있습니다.
관련 개념 사이드카 패턴, Pod 네트워크, 일시성(Ephemeral), 컨테이너 그룹
답안 노드(Node)는 쿠버네티스 클러스터를 구성하는 개별 서버(물리 서버 또는 VM)로, 실제 Pod가 배치되어 실행되는 작업 단위입니다. 노드는 역할에 따라 클러스터 전체를 관리하는 컨트롤 플레인(마스터) 노드와 실제 애플리케이션 워크로드가 실행되는 워커 노드로 구분됩니다. 클러스터(Cluster)는 이러한 여러 노드들을 하나로 묶어 관리하는 전체 시스템으로, 사용자는 개별 노드를 직접 다루기보다 클러스터 전체를 하나의 대상으로 삼아 애플리케이션을 배포하고 관리합니다. 워커 노드에는 컨테이너 런타임, kubelet, kube-proxy 같은 컴포넌트가 실행되어 컨트롤 플레인의 지시에 따라 실제 Pod를 실행하고 상태를 보고합니다.
관련 개념 컨트롤 플레인, 워커 노드, kubelet, kube-proxy
답안 컨트롤 플레인은 클러스터의 두뇌 역할을 하며 여러 컴포넌트로 구성됩니다. API 서버(kube-apiserver)는 모든 요청이 거쳐가는 유일한 진입점으로, 사용자와 다른 컴포넌트 간의 통신을 중개합니다. etcd는 클러스터의 모든 상태 정보(어떤 Pod가 어디에 있는지 등)를 저장하는 분산 키-값 저장소입니다. 스케줄러(kube-scheduler)는 새로 생성된 Pod를 자원 상황에 맞는 적절한 노드에 배치하는 역할을 하고, 컨트롤러 매니저(kube-controller-manager)는 현재 상태를 원하는 상태(Desired State)와 지속적으로 비교하며 차이가 있으면 이를 조정하는 여러 컨트롤러(레플리케이션 컨트롤러 등)를 실행합니다. 이 컴포넌트들이 함께 동작하며 "선언한 상태를 계속 유지"하는 쿠버네티스의 핵심 원리를 구현합니다.
관련 개념 kube-apiserver, etcd, kube-scheduler, controller-manager, Desired State
답안 ReplicaSet은 지정된 개수의 Pod 복제본이 항상 유지되도록 보장하는 컨트롤러로, Pod가 예기치 않게 종료되면 자동으로 새 Pod를 생성해 개수를 맞춥니다. Deployment는 이 ReplicaSet을 한 단계 더 추상화한 상위 오브젝트로, 애플리케이션의 버전 관리와 배포 전략(롤링 업데이트, 롤백)을 담당합니다. 사용자가 Deployment의 이미지 버전을 변경하면, Deployment는 새로운 ReplicaSet을 생성하고 기존 ReplicaSet의 Pod 수를 점진적으로 줄이면서 새 ReplicaSet의 Pod 수를 늘리는 방식으로 무중단 롤링 업데이트를 수행합니다. 실무에서는 대부분 ReplicaSet을 직접 다루기보다 Deployment를 통해 애플리케이션을 배포하고 관리합니다.
관련 개념 ReplicaSet, 롤링 업데이트, 롤백(Rollback), Desired State 관리
답안 Pod는 재시작되거나 재배치될 때마다 IP 주소가 바뀌는 일시적인 존재이기 때문에, 클라이언트가 특정 Pod의 IP를 직접 참조하면 연결이 끊어질 위험이 큽니다. Service는 여러 Pod 앞에 위치해 고정된 가상 IP와 DNS 이름을 제공하고, 그 뒤에 있는 Pod들에게 트래픽을 자동으로 분산해주는 오브젝트입니다. 즉 Service는 쿠버네티스 내부의 로드밸런서 역할을 하며, Label Selector를 통해 어떤 Pod들이 이 Service의 대상이 되는지를 지정합니다. 클라이언트는 개별 Pod의 생성·삭제와 무관하게 항상 동일한 Service 이름이나 IP로 접근할 수 있어, Pod의 동적인 생명주기로부터 클라이언트를 격리시키는 추상화 계층 역할을 합니다.
관련 개념 Label Selector, ClusterIP, NodePort, LoadBalancer 타입, 쿠버네티스 DNS
답안
ClusterIP는 기본 타입으로 클러스터 내부에서만 접근 가능한 가상 IP를 부여하며, 주로 애플리케이션 계층 간 내부 통신에 사용됩니다. NodePort는 모든 워커 노드의 특정 포트를 열어 외부에서 노드IP:포트로 접근할 수 있게 해주는 타입으로, 간단하게 외부 노출이 가능하지만 노드 IP가 바뀌거나 포트 범위 제약이 있어 프로덕션에서는 잘 사용되지 않습니다. LoadBalancer는 클라우드 제공업체의 외부 로드밸런서(예: AWS ALB/NLB)를 자동으로 프로비저닝해 외부 트래픽을 클러스터로 유입시키는 타입으로, 프로덕션 환경에서 외부에 서비스를 노출할 때 가장 일반적으로 사용됩니다. 이 외에 여러 서비스를 경로 기반으로 라우팅하는 Ingress를 함께 사용해 하나의 진입점으로 여러 서비스를 관리하기도 합니다.
관련 개념 Ingress, 클라우드 로드밸런서 연동, 외부 노출 전략, 포트 범위
답안
새로운 Pod가 생성되면 아직 어떤 노드에도 배정되지 않은 상태(Pending)이며, kube-scheduler가 이를 감지해 적절한 노드를 선택하는 과정을 거칩니다. 스케줄링은 크게 두 단계로 이루어지는데, 먼저 필터링(Filtering) 단계에서 자원이 부족하거나 조건에 맞지 않는 노드를 후보에서 제외하고, 이후 스코어링(Scoring) 단계에서 남은 후보 노드들에 점수를 매겨 가장 적합한 노드를 선택합니다. 이때 Pod가 요청한 CPU/메모리 자원(requests), 특정 노드에만 배치되도록 지정하는 nodeSelector/Affinity, 특정 노드에는 배치되지 않도록 하는 Taint/Toleration 같은 설정이 스케줄링 결과에 영향을 줍니다. 스케줄러가 노드를 결정하면 해당 노드의 kubelet이 실제로 컨테이너를 실행합니다.
관련 개념 requests/limits, Node Affinity, Taint/Toleration, kubelet
답안 Namespace는 하나의 물리적인 쿠버네티스 클러스터 안에서 리소스를 논리적으로 격리된 여러 가상 클러스터처럼 분리해 관리할 수 있게 해주는 개념입니다. 예를 들어 개발, 스테이징, 운영 환경을 하나의 클러스터 안에서 각각 다른 네임스페이스로 분리해 운영하거나, 팀별로 네임스페이스를 나눠 자원 사용량과 접근 권한을 독립적으로 관리할 수 있습니다. 네임스페이스 단위로 리소스 쿼터(ResourceQuota)를 설정해 특정 팀이 사용할 수 있는 CPU·메모리 총량을 제한할 수 있고, RBAC(역할 기반 접근제어)와 결합해 네임스페이스별로 접근 권한을 세밀하게 통제할 수 있습니다. 다만 노드나 퍼시스턴트 볼륨처럼 클러스터 전체에 걸친 일부 리소스는 네임스페이스로 격리되지 않는다는 점도 알아둘 필요가 있습니다.
관련 개념 ResourceQuota, RBAC, 멀티 테넌시, 클러스터 전역 리소스
답안
명령형 방식은 "무엇을 어떻게 할지" 단계별 명령을 직접 실행하는 방식으로, 예를 들어 kubectl run, kubectl scale 같은 명령어로 즉시 특정 동작을 수행합니다. 선언적 방식은 YAML 매니페스트에 "최종적으로 어떤 상태가 되어야 하는지(Desired State)"만 기술하고, kubectl apply로 이를 클러스터에 적용하면 쿠버네티스의 컨트롤러들이 현재 상태를 그 목표 상태와 지속적으로 비교하며 스스로 필요한 조치를 취합니다. 선언적 방식의 장점은 매니페스트 파일 자체가 시스템의 상태를 코드로 기록하는 IaC(Infrastructure as Code) 역할을 해 버전 관리와 재현이 쉽고, 컨트롤러가 지속적으로 상태를 감시하며 자동으로 복구해주기 때문에 운영 안정성이 높다는 점입니다. 실무에서는 대부분 선언적 방식을 기본으로 사용하며 GitOps 같은 워크플로우와도 잘 결합됩니다.
관련 개념 Desired State, kubectl apply, IaC, GitOps, 컨트롤 루프
대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무(네트워크·클라우드·시스템·보안) 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 ConfigMap은 애플리케이션의 설정값(환경 변수, 설정 파일 등)처럼 민감하지 않은 구성 정보를 코드와 분리해 관리하기 위한 오브젝트로, Pod에 환경변수나 볼륨 파일 형태로 주입할 수 있습니다. Secret은 비밀번호, API 키, 인증서처럼 민감한 정보를 저장하기 위한 오브젝트로, 기본적으로 base64로 인코딩되어 저장되지만 이는 암호화가 아니라 인코딩일 뿐이므로 etcd 암호화나 외부 시크릿 관리 도구와 함께 사용해야 실질적인 보안이 확보됩니다. 두 오브젝트 모두 설정 정보를 애플리케이션 이미지와 분리함으로써, 동일한 이미지를 서로 다른 환경(개발/운영)에 재사용할 수 있게 해주는 것이 핵심 목적입니다. 실무에서는 Secret을 etcd 암호화, RBAC 접근 제어와 함께 사용하고, 더 나아가 Vault 등의 외부 시크릿 관리 서비스와 연동하는 것이 권장됩니다.
관련 개념 base64 인코딩, etcd 암호화, 환경변수 주입, 볼륨 마운트, 외부 시크릿 연동
답안
HPA는 CPU 사용률이나 메모리 사용률, 또는 사용자 정의 메트릭을 기준으로 Pod의 개수를 자동으로 늘리거나 줄이는 오토스케일링 기능입니다. HPA는 주기적으로 메트릭 서버(Metrics Server)로부터 대상 Pod들의 현재 리소스 사용률을 수집하고, 이를 사용자가 설정한 목표 값과 비교해 필요한 Pod 개수를 계산한 뒤 Deployment나 ReplicaSet의 replica 수를 조정합니다. 예를 들어 목표 CPU 사용률을 50%로 설정했는데 실제 평균 사용률이 80%라면, HPA는 replica 수를 늘려 평균 사용률을 목표치에 가깝게 낮추려고 시도합니다. 다만 HPA가 효과적으로 동작하려면 Pod에 requests(자원 요청량)가 반드시 설정되어 있어야 사용률 계산이 가능하며, 급격한 스케일링을 방지하기 위한 안정화 기간(Stabilization Window) 설정도 함께 고려해야 합니다.
관련 개념 Metrics Server, requests 설정, Stabilization Window, VPA(수직 오토스케일러)
답안
롤링 업데이트는 Deployment의 기본 배포 전략으로, 기존 버전의 Pod를 한꺼번에 종료하지 않고 점진적으로 새 버전 Pod를 추가하면서 기존 Pod를 하나씩 제거하는 방식으로 진행됩니다. 이 과정에서 maxSurge(원래 개수보다 추가로 생성할 수 있는 최대 Pod 수)와 maxUnavailable(동시에 사용 불가능해도 되는 최대 Pod 수) 값을 조절해 배포 속도와 안정성의 균형을 맞출 수 있습니다. 새로 생성된 Pod는 readiness probe를 통과해야 Service의 트래픽 대상에 포함되기 때문에, 아직 준비되지 않은 새 버전 Pod로 트래픽이 유입되는 것을 방지할 수 있습니다. 배포 중 문제가 발생하면 kubectl rollout undo 명령으로 이전 ReplicaSet으로 즉시 롤백할 수 있어, 이러한 메커니즘 전체가 결합되어 서비스 중단 없는 배포를 가능하게 합니다.
관련 개념 maxSurge/maxUnavailable, readiness probe, rollout undo, 카나리 배포
답안 Liveness Probe는 컨테이너가 여전히 살아서 정상 동작하고 있는지를 주기적으로 확인하는 헬스체크로, 이 검사에 실패하면 kubelet이 해당 컨테이너가 비정상 상태(예: 데드락에 빠짐)라고 판단해 컨테이너를 재시작합니다. Readiness Probe는 컨테이너가 트래픽을 받을 준비가 되었는지를 확인하는 헬스체크로, 이 검사에 실패하면 컨테이너를 재시작하지는 않지만 해당 Pod를 Service의 엔드포인트에서 일시적으로 제외해 트래픽이 전달되지 않도록 합니다. 예를 들어 애플리케이션이 시작 후 초기 데이터 로딩에 시간이 걸리는 경우, 그 기간 동안 readiness probe를 실패시켜 트래픽을 받지 않게 하다가 준비가 완료되면 다시 트래픽을 받도록 할 수 있습니다. 두 프로브를 적절히 함께 사용하는 것이 안정적인 서비스 운영과 무중단 배포의 핵심입니다.
관련 개념 헬스체크, 컨테이너 재시작, 엔드포인트 제외, startupProbe
답안 기본적으로 쿠버네티스 클러스터 내의 모든 Pod는 네임스페이스와 무관하게 서로 자유롭게 통신할 수 있는데, 이는 편리하지만 특정 Pod가 침해당했을 때 공격이 클러스터 내부 전체로 확산될 위험을 키웁니다. NetworkPolicy는 Label Selector를 이용해 특정 Pod 그룹에 대해 허용할 인바운드(Ingress)와 아웃바운드(Egress) 트래픽 규칙을 정의함으로써, 필요한 통신만 허용하고 나머지는 차단하는 마이크로 세그멘테이션을 구현하는 오브젝트입니다. 예를 들어 데이터베이스 Pod는 애플리케이션 계층 Pod로부터의 특정 포트 접근만 허용하고 그 외 모든 트래픽은 차단하도록 설정할 수 있습니다. 다만 NetworkPolicy는 이를 지원하는 CNI(Container Network Interface) 플러그인(예: Calico, Cilium)이 클러스터에 설치되어 있어야 실제로 동작한다는 점에 유의해야 합니다.
관련 개념 마이크로 세그멘테이션, CNI 플러그인, Ingress/Egress 규칙, 최소 권한 네트워크
답안
PersistentVolume(PV)은 클러스터 관리자가 미리 준비해두거나 스토리지 클래스에 의해 동적으로 프로비저닝되는 실제 스토리지 자원을 나타내는 오브젝트입니다. PersistentVolumeClaim(PVC)은 사용자(개발자)가 "이만큼의 용량과 특정 접근 모드를 가진 스토리지가 필요하다"고 요청하는 오브젝트로, 쿠버네티스는 이 요청에 맞는 PV를 찾아 자동으로 연결(바인딩)합니다. 이러한 분리 구조 덕분에 애플리케이션 개발자는 실제 스토리지가 NFS인지, 클라우드 블록 스토리지인지 등 구체적인 구현을 알 필요 없이 PVC만 선언하면 되고, 인프라 관리자는 스토리지 프로비저닝을 별도로 관리할 수 있습니다. Pod가 삭제되어도 PV의 데이터를 유지할지 여부는 Reclaim Policy(Retain, Delete 등) 설정에 따라 결정됩니다.
관련 개념 StorageClass, 동적 프로비저닝, Reclaim Policy, 접근 모드(ReadWriteOnce 등)
답안
Deployment는 관리하는 Pod들이 서로 동일하고 상호 교체 가능하다고 가정하기 때문에, Pod 이름이 임의로 생성되고 삭제 시 순서를 보장하지 않으며 저장소도 공유되거나 임시적입니다. StatefulSet은 데이터베이스나 분산 시스템처럼 각 Pod가 고유한 정체성(고정된 이름, 고정된 네트워크 식별자)과 독립적인 영속 스토리지를 가져야 하는 애플리케이션을 위한 오브젝트입니다. StatefulSet이 관리하는 Pod는 앱이름-0, 앱이름-1처럼 순서가 있는 이름을 부여받고, 생성과 삭제도 순차적으로 이루어지며, 각 Pod는 자신만의 PVC를 가져 재시작되어도 동일한 스토리지에 다시 연결됩니다. 이러한 특성 때문에 MySQL 클러스터, Kafka, Elasticsearch처럼 노드 간 순서와 정체성이 중요한 분산 스테이트풀 애플리케이션 배포에 StatefulSet이 사용됩니다.
관련 개념 순서 보장, 고정 네트워크 식별자, Headless Service, 분산 스테이트풀 애플리케이션
답안 DaemonSet은 클러스터 내의 모든(또는 특정 조건에 맞는) 노드마다 정확히 하나씩 특정 Pod를 실행하도록 보장하는 오브젝트입니다. 새로운 노드가 클러스터에 추가되면 자동으로 해당 노드에도 DaemonSet Pod가 생성되고, 노드가 제거되면 해당 Pod도 함께 정리됩니다. 대표적인 사용 사례로는 각 노드의 로그를 수집하는 로그 에이전트(Fluentd 등), 각 노드의 자원 사용률을 모니터링하는 메트릭 수집 에이전트(Node Exporter 등), 그리고 각 노드에 네트워크 기능을 제공하는 CNI 플러그인이나 kube-proxy 등이 있습니다. 이는 "노드 단위로 반드시 실행되어야 하는 인프라성 워크로드"를 배포할 때 표준적으로 사용되는 패턴입니다.
관련 개념 노드당 하나씩 배포, 로그/모니터링 에이전트, kube-proxy, 인프라성 워크로드
답안 requests는 컨테이너가 정상 동작을 위해 최소한으로 필요로 하는 자원량을 나타내며, 스케줄러가 Pod를 어느 노드에 배치할지 결정할 때 이 값을 기준으로 해당 노드에 충분한 여유 자원이 있는지 판단합니다. limits는 컨테이너가 사용할 수 있는 최대 자원량으로, 이를 초과해 메모리를 사용하면 OOM Killer에 의해 컨테이너가 강제 종료되고, CPU의 경우 초과 사용 시 스로틀링(제한)이 걸립니다. 이 두 값을 설정하지 않으면 특정 Pod가 노드의 자원을 과도하게 점유해 같은 노드의 다른 Pod에 영향을 줄 수 있는 Noisy Neighbor 문제가 발생할 수 있으므로, 프로덕션 환경에서는 반드시 적절한 requests/limits를 설정하는 것이 권장됩니다. 또한 앞서 다룬 HPA도 requests 값을 기준으로 사용률을 계산하기 때문에, 이 설정은 오토스케일링의 정확도에도 직접적인 영향을 미칩니다.
관련 개념 QoS 클래스(Guaranteed/Burstable/BestEffort), OOM Killer, CPU 스로틀링, Noisy Neighbor
답안 각 워커 노드는 주기적으로 컨트롤 플레인에 상태(Heartbeat)를 보고하는데, 특정 노드로부터 일정 시간 이상 응답이 없으면 컨트롤 플레인이 해당 노드를 NotReady 상태로 표시합니다. 이후 일정 유예 시간이 지나도 노드가 복구되지 않으면, 해당 노드에서 실행 중이던 Pod들은 자동으로 축출(Eviction)되고, 그 Pod들을 관리하던 ReplicaSet이나 Deployment 컨트롤러가 이를 감지해 다른 정상 노드에 동일한 개수의 새 Pod를 다시 생성합니다. 이 과정에서 Service는 Label Selector를 통해 새로 생성된 Pod를 자동으로 엔드포인트에 포함시키므로 클라이언트는 특별한 조치 없이도 계속 서비스를 이용할 수 있습니다. 다만 StatefulSet처럼 특정 스토리지에 종속된 Pod의 경우 복구 시간이 더 걸릴 수 있으며, PV의 종류(예: 특정 AZ에 종속된 볼륨)에 따라 다른 AZ의 노드로는 즉시 이동하지 못할 수도 있다는 점을 함께 언급할 수 있습니다.
관련 개념 Node Heartbeat, NotReady, Pod Eviction, 컨트롤러의 자동 복구, AZ 종속 볼륨