DevOps / CI·CD 면접 질문

CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery/Deployment)를 합쳐 놓은 용어입니다.

지속적 통합은 개발자들이 코드를 자주 공유하고 통합하는 것을 의미하며, 자동화된 빌드 및 테스트를 통해 코드 변경 사항을 빠르게 검증합니다. 이를 통해 통합 과정에서 발생하는 문제를 조기에 발견하고 해결할 수 있습니다.

지속적 배포는 통합된 코드를 자동으로 테스트 환경이나 운영 환경에 배포하는 것을 의미합니다. 이를 통해 릴리스 주기를 단축하고, 사용자에게 더 빠르게 새로운 기능을 제공할 수 있습니다.

CI/CD는 개발과 운영을 통합하는 DevOps의 핵심 요소이며, 소프트웨어 개발 프로세스의 효율성을 높이고 안정적인 릴리스를 가능하게 하기 때문에 중요합니다.

Docker 이미지와 컨테이너의 차이점을 설명드리겠습니다.

Docker 이미지는 컨테이너를 만들기 위한 템플릿이라고 생각하시면 됩니다. 마치 클래스와 인스턴스처럼요. 이미지는 애플리케이션 실행에 필요한 모든 것, 즉 코드, 런타임, 시스템 도구, 라이브러리, 설정 등을 포함하는 불변의 파일입니다. 한번 만들어진 이미지는 변경되지 않습니다.

반면 컨테이너는 이미지의 실행 가능한 인스턴스입니다. 이미지를 기반으로 생성되며, 격리된 환경에서 애플리케이션을 실행합니다. 컨테이너는 이미지를 읽기 전용으로 사용하고, 컨테이너 내에서 발생하는 변경 사항은 컨테이너 레이어에 저장됩니다. 따라서 컨테이너를 삭제해도 이미지는 그대로 유지됩니다. 컨테이너는 실행, 중지, 삭제가 가능하며, 여러 개의 컨테이너를 동일한 이미지에서 생성할 수 있습니다.

CI 파이프라인은 코드 변경 사항이 안정적으로 프로덕션 환경에 배포될 수 있도록 자동화된 일련의 과정입니다.

일반적으로 다음과 같은 단계로 구성됩니다.

1. 코드 통합 (Code Commit): 개발자가 코드를 버전 관리 시스템(예: Git)에 커밋하는 것으로 시작됩니다. 이것이 파이프라인 트리거가 됩니다.

2. 빌드 (Build): 커밋된 코드를 실행 가능한 애플리케이션으로 컴파일하고 필요한 종속성을 다운로드합니다. 예를 들어, Java 프로젝트라면 Maven이나 Gradle을 사용하여 빌드합니다.

3. 테스트 (Test): 빌드된 애플리케이션에 대해 다양한 종류의 테스트를 실행합니다. 단위 테스트, 통합 테스트, 인수 테스트 등이 포함되며, 코드의 품질과 기능적 정확성을 검증합니다.

4. 배포 (Deploy): 테스트를 통과한 애플리케이션을 스테이징 또는 프로덕션 환경에 자동으로 배포합니다. 이 단계는 실제 사용자에게 코드가 전달되기 전 마지막 검증 단계 역할을 합니다.

이러한 자동화된 파이프라인을 통해 개발팀은 코드 변경 사항을 더 빠르고 안정적으로 배포할 수 있습니다.

CI(지속적 통합)는 개발자들이 코드를 자주 통합하고, 각 통합마다 자동화된 빌드와 테스트를 실행하여 오류를 조기에 발견하는 방식입니다. CD(지속적 배포/전달)는 CI를 넘어, 빌드되고 테스트된 코드를 자동으로 프로덕션 환경까지 배포하는 것을 목표로 합니다.

Continuous Delivery와 Continuous Deployment의 차이는 배포 단계에서 사람의 승인이 필요한지 여부입니다. Continuous Delivery는 언제든지 프로덕션에 배포할 준비가 된 상태를 유지하지만, 실제 배포는 수동 승인을 거칩니다. 반면 Continuous Deployment는 모든 단계가 완전히 자동화되어, 테스트를 통과한 코드는 사람의 개입 없이 자동으로 프로덕션에 릴리스됩니다. 핵심은 자동화의 범위와 배포 승인 여부입니다.

도커 이미지는 여러 개의 읽기 전용 레이어들이 쌓여서 만들어집니다. 각 레이어는 파일 시스템의 변경 사항을 나타내며, 마치 겹겹이 쌓인 얇은 시트와 같다고 생각하시면 됩니다.

이러한 레이어 구조는 몇 가지 중요한 이점을 제공합니다. 첫째, 효율성입니다. 여러 이미지가 동일한 베이스 레이어를 공유할 경우, 해당 레이어는 한 번만 저장되고 여러 이미지에서 재사용됩니다. 이는 저장 공간을 크게 절약해 줍니다. 둘째, 빠른 전송입니다. 이미지를 다운로드하거나 업로드할 때, 이미 존재하는 레이어는 건너뛰고 변경된 레이어만 전송하면 되기 때문에 훨씬 빠르게 완료됩니다. 마지막으로 재사용성과 캐싱 측면에서도 유리합니다. 빌드 과정에서 각 레이어는 캐시될 수 있어, 동일한 명령이 다시 실행될 때 캐시된 레이어를 활용하여 빌드 시간을 단축할 수 있습니다.

Dockerfile로 이미지를 빌드할 때 레이어 캐시는 각 명령어 실행 결과를 이미지 레이어로 저장하고 재사용하는 메커니즘입니다. Docker는 각 레이어의 명령어와 해당 명령어에 사용된 파일(예: COPY, ADD)의 해시 값을 계산하여 캐시 히트를 결정합니다. 만약 명령어와 파일의 해시 값이 이전 빌드와 동일하면, 해당 레이어는 캐시에서 가져와 사용하며 빌드 시간을 단축시킵니다.

캐시를 효과적으로 활용하려면 변경이 적고 자주 사용되는 명령어(예: OS 패키지 설치, 라이브러리 의존성 설치)를 앞에 배치하고, 자주 변경될 수 있는 애플리케이션 소스 코드 복사(COPY)와 같은 명령어는 뒤에 배치하는 것이 좋습니다. 이렇게 하면 애플리케이션 코드가 변경되어도 이전 레이어의 캐시를 그대로 활용할 수 있어 빌드 속도를 크게 향상시킬 수 있습니다. 즉, 변경에 덜 민감한 부분을 먼저 빌드하여 캐시를 최대한 활용하는 것이 핵심입니다.

컨테이너와 가상머신(VM)의 가장 큰 차이는 격리 방식과 리소스 사용에 있습니다.

VM은 하이퍼바이저를 통해 하드웨어를 가상화하고, 각 VM마다 독립적인 게스트 운영체제(OS)를 실행합니다. 이 때문에 격리 수준은 매우 높지만, OS 전체를 실행해야 하므로 부팅 시간이 길고 리소스 사용량도 많습니다.

반면 컨테이너는 호스트 OS의 커널을 공유하는 OS 가상화 방식입니다. 각 컨테이너는 애플리케이션과 필요한 라이브러리만 포함하며, OS 자체를 포함하지 않습니다. 따라서 VM보다 훨씬 가볍고 빠르게 시작되며, 리소스 사용량도 적습니다. 격리 수준은 VM보다 낮지만, 대부분의 애플리케이션 배포 시나리오에서는 충분합니다.

Docker와 가상 머신(VM)은 둘 다 애플리케이션을 격리된 환경에서 실행하는 기술이지만, 격리 수준과 리소스 사용량에서 큰 차이가 있습니다.

VM은 하이퍼바이저를 통해 게스트 OS 전체를 가상화하여 격리합니다. 반면, Docker는 컨테이너를 사용하여 호스트 OS의 커널을 공유하고, 애플리케이션과 필요한 라이브러리만 패키징합니다.

이러한 차이점 때문에 Docker 컨테이너는 VM보다 훨씬 가볍고 빠르게 시작하며, 리소스 사용량도 적습니다. VM은 완전한 OS를 실행해야 하므로 오버헤드가 크지만, Docker는 호스트 OS의 자원을 효율적으로 공유합니다. 격리 수준은 VM이 더 높지만, Docker도 충분한 격리 수준을 제공하며, 더 효율적인 운영이 가능합니다.

Dockerfile은 이미지를 만들기 위한 레시피 같은 파일입니다. 주요 명령어는 다음과 같습니다.

• FROM: 베이스 이미지를 지정합니다. 예를 들어 FROM ubuntu:latest는 최신 우분투 이미지를 기반으로 시작하겠다는 의미입니다.

• RUN: 이미지를 빌드하는 과정에서 명령어를 실행합니다. 예를 들어 RUN apt-get update && apt-get install -y nginx는 패키지를 업데이트하고 nginx를 설치합니다.

• COPY: 로컬 파일을 이미지 안으로 복사합니다. COPY ./app /app은 현재 디렉토리의 app 폴더를 이미지 내 /app 폴더로 복사합니다.

• WORKDIR: 이후 RUN, CMD, ENTRYPOINT 명령어들이 실행될 작업 디렉토리를 설정합니다. WORKDIR /app을 설정하면 이후 명령어들은 /app 디렉토리에서 실행됩니다.

• CMD: 컨테이너가 시작될 때 실행할 명령어를 지정합니다. Dockerfile에 여러 개의 CMD가 있다면 마지막 CMD만 실행됩니다. CMD ["nginx", "-g", "daemon off;"] 처럼 실행 파일과 인자를 배열 형태로 지정하는 것이 좋습니다.

• ENTRYPOINT: CMD와 비슷하지만, 컨테이너 실행 시 항상 실행되는 명령어입니다. CMD는 ENTRYPOINT에 의해 오버라이드될 수 있습니다.

Docker Compose는 여러 개의 Docker 컨테이너를 정의하고 실행하는 데 사용되는 도구입니다. YAML 파일을 사용하여 애플리케이션의 서비스, 네트워크, 볼륨 등을 정의하고, docker-compose up 명령으로 한 번에 모든 컨테이너를 실행할 수 있습니다.

예를 들어, 웹 애플리케이션, 데이터베이스, 캐시 서버를 각각 컨테이너로 구성하고, 이들 간의 의존성을 Compose 파일에 명시하여 쉽게 관리할 수 있습니다. 서비스 간의 네트워킹도 자동으로 설정되어 컨테이너 간 통신이 편리해집니다.

Compose는 개발 환경, 테스트 환경, 그리고 간단한 프로덕션 환경에서 다중 컨테이너 애플리케이션을 관리하는 데 유용합니다. 복잡한 애플리케이션을 쉽게 배포하고 관리할 수 있도록 도와주는 강력한 도구입니다.

Kubernetes의 주요 개념에 대해 설명드리겠습니다.

가장 기본적인 단위는 Pod입니다. Pod는 하나 이상의 컨테이너를 묶어 놓은 논리적인 그룹으로, 컨테이너들이 네트워크와 스토리지를 공유하며 함께 실행됩니다.

Deployment는 Pod를 관리하는 역할을 합니다. 원하는 Pod의 개수를 정의하고, Pod에 문제가 발생했을 때 자동으로 재시작하거나 교체하여 항상 지정된 상태를 유지하도록 합니다. 업데이트 전략도 관리하여 무중단 배포를 가능하게 합니다.

Service는 Pod 집합에 대한 단일 진입점을 제공합니다. Pod는 IP 주소가 동적으로 변할 수 있기 때문에, Service를 통해 안정적인 주소와 포트로 접근할 수 있도록 해줍니다. 내부 로드 밸런싱 기능도 제공합니다.

마지막으로 Ingress는 외부 트래픽을 Kubernetes 클러스터 내부 Service로 라우팅하는 역할을 합니다. HTTP, HTTPS 요청을 기반으로 트래픽을 분산하고, SSL/TLS 암호화도 처리할 수 있습니다. Service를 외부로 노출시키는 방법 중 하나입니다.

이들은 서로 연관되어 작동하며, Kubernetes를 통해 컨테이너화된 애플리케이션을 효율적으로 관리하고 확장할 수 있도록 돕습니다.

ReplicaSet과 Deployment는 Kubernetes에서 애플리케이션을 관리하는 데 사용되지만, 주요 차이점은 업데이트 방식과 기능에 있습니다.

ReplicaSet은 지정된 수의 Pod 복제본을 항상 실행하도록 보장하는 기본적인 컨트롤러입니다. Pod의 상태를 감시하고, 지정된 수보다 적으면 Pod를 생성하고, 많으면 삭제합니다.

Deployment는 ReplicaSet을 관리하는 상위 수준의 컨트롤러입니다. 선언적인 업데이트와 롤백 기능을 제공하여 애플리케이션을 더 쉽게 배포하고 관리할 수 있도록 돕습니다. 예를 들어, Deployment를 사용하면 롤링 업데이트를 통해 애플리케이션을 중단 없이 업데이트할 수 있고, 문제가 발생했을 때 이전 버전으로 롤백할 수 있습니다. Deployment는 ReplicaSet을 생성하고 관리함으로써 이러한 기능을 제공합니다. 즉, Deployment는 ReplicaSet을 통해 Pod를 관리하는 방식에 대한 전략을 정의한다고 볼 수 있습니다.

Blue-Green 배포와 Canary 배포는 모두 무중단 배포 전략이지만, 트래픽 전환 방식과 리스크 관리에서 차이가 있습니다.

Blue-Green 배포는 기존 환경(Blue)과 동일한 새로운 환경(Green)을 구축하고, 모든 트래픽을 한 번에 Green 환경으로 전환합니다. 장점은 간단하고 빠르다는 것이지만, 롤백 시 전체 트래픽을 Blue 환경으로 되돌려야 하므로 리스크가 큽니다.

Canary 배포는 새로운 버전을 소수의 사용자에게 먼저 배포하여 테스트하고, 문제가 없으면 점진적으로 트래픽을 늘려나갑니다. 장점은 리스크를 최소화하고 실제 사용자 환경에서 테스트할 수 있다는 것이지만, Blue-Green 배포보다 복잡하고 시간이 오래 걸립니다. 또한, Canary 배포는 롤백이 쉽고, 문제 발생 시 영향 범위를 최소화할 수 있습니다.

어떤 배포 전략을 선택할지는 서비스의 특성, 리스크 감수 수준, 배포 복잡성 등을 고려하여 결정해야 합니다.

GitOps는 인프라와 애플리케이션 배포를 관리하는 방법론입니다. 핵심은 모든 인프라와 애플리케이션 설정을 Git 저장소에 선언적으로 정의하고, Git 저장소가 시스템의 '단일 진실 공급원' 역할을 한다는 점입니다.

전통적인 배포 방식에서는 명령형으로 직접 서버에 접속해서 설정을 변경하거나 배포 스크립트를 실행하는 경우가 많습니다. 반면 GitOps에서는 Git 저장소에 변경 사항을 커밋하면, 자동화 도구가 이를 감지하고 실제 시스템에 적용합니다.

이러한 방식은 다음과 같은 장점을 제공합니다. 첫째, 모든 변경 이력을 Git으로 관리하여 추적 및 감사가 용이합니다. 둘째, 멱등성을 보장하여 배포 과정에서 오류 발생 가능성을 줄입니다. 셋째, 시스템 상태를 Git 저장소와 비교하여 관찰 가능성을 높이고, 문제 발생 시 빠르게 롤백할 수 있습니다. 마지막으로, 자동화를 통해 배포 속도를 향상시키고 인적 오류를 줄일 수 있습니다.

서비스 메시는 마이크로서비스 아키텍처에서 서비스 간 통신을 효율적으로 관리하기 위한 인프라 계층입니다. 마이크로서비스 환경에서는 서비스 수가 많아지고 복잡해지면서 트래픽 관리, 보안, 관찰 가능성 확보가 어려워집니다.

서비스 메시는 이러한 문제들을 해결하기 위해 각 서비스 옆에 '사이드카' 프록시를 배치하여 서비스 간 통신을 가로채고 관리합니다. 이를 통해 트래픽 라우팅, 로드 밸런싱, 서비스 간 인증/인가, 모니터링 등의 기능을 중앙 집중적으로 제어할 수 있습니다. 결과적으로 개발자는 비즈니스 로직에 집중하고, 운영자는 전체 시스템의 안정성과 성능을 향상시킬 수 있습니다.

네트워크 정책은 쿠버네티스에서 Pod 간의 네트워크 트래픽을 제어하는 중요한 기능입니다. 기본적으로 쿠버네티스 클러스터 내의 모든 Pod는 서로 통신할 수 있지만, 네트워크 정책을 사용하면 이를 제한하여 보안을 강화할 수 있습니다.

네트워크 정책은 Pod 셀렉터를 기반으로 Ingress (들어오는 트래픽) 및 Egress (나가는 트래픽) 규칙을 정의합니다. 예를 들어, 특정 레이블을 가진 Pod로 들어오는 트래픽만 허용하거나, 특정 namespace의 Pod로 나가는 트래픽만 허용하는 규칙을 설정할 수 있습니다.

이를 통해 개발 환경, 스테이징 환경, 프로덕션 환경과 같이 namespace를 기준으로 네트워크 격리를 구현하거나, 특정 서비스 간의 통신만 허용하는 등 다양한 시나리오에 적용할 수 있습니다. 네트워크 정책을 적용하면 클러스터의 보안을 강화하고, 잠재적인 공격으로부터 보호할 수 있습니다.

CI 환경마다 빌드 캐시가 잘 적중하지 않는 문제는 주로 Dockerfile의 명령어 순서나 빌드 컨텍스트 변경 때문입니다. Docker는 각 명령어를 독립적인 레이어로 관리하는데, 이전 레이어가 변경되면 이후 레이어의 캐시가 무효화됩니다.

이를 해결하기 위해 몇 가지 전략을 사용할 수 있습니다. 첫째, 자주 변경되지 않는 의존성 설치 명령어를 먼저 배치하여 해당 레이어의 캐시를 최대한 활용합니다. 둘째, 애플리케이션 소스 코드 복사 명령어를 의존성 설치 이후에 배치하여 코드 변경 시에도 의존성 레이어 캐시는 유지되도록 합니다.

또한, 멀티스테이지 빌드를 활용하면 최종 이미지 크기를 줄이고 불필요한 빌드 의존성을 제거하여 캐시 효율성을 높일 수 있습니다. 빌드 컨텍스트를 최소화하는 것도 중요합니다. .dockerignore 파일을 잘 설정하여 불필요한 파일이 빌드 컨텍스트에 포함되지 않도록 하면 빌드 속도 향상과 캐시 무효화 방지에 도움이 됩니다.

멀티 스테이지 빌드는 주로 두 가지 문제를 해결합니다. 첫째, 최종 컨테이너 이미지에 불필요한 빌드 도구나 종속성이 포함되어 이미지 크기가 커지는 문제를 해결합니다. 둘째, 빌드 과정에서 사용된 민감한 정보나 시크릿이 최종 이미지에 노출될 위험을 줄여 보안을 강화합니다.

빌더 스테이지와 런타임 스테이지를 분리하면, 빌더 스테이지에서는 애플리케이션을 빌드하고 필요한 아티팩트만 생성합니다. 이후 런타임 스테이지에서는 이 빌드 산출물만을 복사하여 최종 이미지를 만듭니다.

이러한 분리는 이미지 크기를 크게 줄여줍니다. 왜냐하면 컴파일러, SDK, 테스트 도구 등 빌드에만 필요한 요소들이 런타임 이미지에 포함되지 않기 때문입니다. 또한, 빌드 시 사용된 API 키나 비밀번호 같은 민감한 정보가 런타임 이미지에 남지 않아 보안 측면에서도 훨씬 안전해집니다. 결국, 더 작고 안전한 이미지를 얻을 수 있습니다.

컨테이너는 호스트 커널을 공유하기 때문에 VM과는 격리 수준에서 차이가 있습니다.

namespace는 프로세스가 접근할 수 있는 시스템 자원을 격리하는 역할을 합니다. 예를 들어, PID namespace는 각 컨테이너마다 고유한 프로세스 ID를 부여하고, Network namespace는 독립적인 네트워크 인터페이스를 제공하여 컨테이너 간의 네트워크 통신을 격리합니다. 즉, namespace는 컨테이너가 '무엇을 볼 수 있는지'를 제어합니다.

cgroup은 컨테이너가 사용할 수 있는 CPU, 메모리, 디스크 I/O 등의 시스템 자원 사용량을 제한하고 관리하는 역할을 합니다. 이를 통해 특정 컨테이너가 과도한 자원을 사용하여 호스트 시스템이나 다른 컨테이너에 영향을 미치는 것을 방지합니다. 즉, cgroup은 컨테이너가 '얼마나 많은 자원을 사용할 수 있는지'를 제어합니다.

VM 대비 격리 수준이 약하다고 평가되는 이유는 바로 이 '커널 공유' 때문입니다. VM은 자체적인 커널을 가지므로 호스트 커널의 취약점이 컨테이너에 영향을 미치지 않습니다. 하지만 컨테이너는 호스트 커널을 공유하기 때문에, 호스트 커널에 보안 취약점이 존재할 경우 이를 통해 컨테이너 간 또는 컨테이너에서 호스트로의 탈출(escape) 공격이 발생할 가능성이 있습니다. namespace와 cgroup은 논리적인 격리를 제공하지만, 근본적으로는 동일한 커널 위에서 동작하기 때문에 VM 수준의 강력한 하드웨어 기반 격리에는 미치지 못합니다.

Deployment 롤링 업데이트 중 5xx 오류는 주로 새 파드 준비 완료 시점과 기존 파드 트래픽 종료 시점 간의 타이밍 불일치로 발생합니다.

readinessProbe는 파드가 트래픽을 받을 준비가 되었는지 판단합니다. 이 프로브가 통과해야 서비스가 해당 파드로 트래픽을 보내기 시작합니다. 만약 새 파드의 readinessProbe가 너무 빨리 통과하거나, 기존 파드가 아직 트래픽을 처리 중인데 엔드포인트에서 제거되면 문제가 발생할 수 있습니다.

terminationGracePeriodSeconds와 preStopHook은 파드 종료 시점에 중요합니다. terminationGracePeriodSeconds는 파드가 종료 신호(SIGTERM)를 받은 후 정상적으로 종료될 시간을 제공합니다. preStopHook은 이 기간 동안 실행되어, 파드가 더 이상 새 요청을 받지 않도록 하고 기존 요청을 안전하게 처리하도록 할 수 있습니다.

이 둘이 제대로 설정되지 않으면, SIGTERM을 받은 기존 파드가 아직 요청을 처리 중인데 엔드포인트에서 제거되어 5xx 오류를 반환하거나, 새 파드가 완전히 준비되지 않은 상태에서 트래픽을 받게 되어 오류가 발생할 수 있습니다. 즉, readinessProbe로 새 파드의 준비 상태를, terminationGracePeriodSeconds와 preStopHook으로 기존 파드의 안전한 종료를 보장하는 것이 중요합니다.

ClusterIP Service로 들어온 트래픽은 kube-proxy가 관리하는 iptables 또는 IPVS 규칙을 통해 파드로 전달됩니다.

iptables 모드에서는 Service의 각 IP와 포트 조합에 대해 수많은 iptables 규칙이 생성됩니다. 트래픽이 들어오면 iptables는 이 규칙들을 순차적으로 검사하며 일치하는 규칙을 찾아 해당 파드로 포트 포워딩합니다. 규칙 수가 많아질수록 룩업 비용이 증가하여 성능 저하가 발생할 수 있습니다.

IPVS 모드는 리눅스 커널의 IP Virtual Server 모듈을 사용합니다. IPVS는 Service를 가상 서버로, 파드를 실제 서버로 간주하고 연결 테이블을 관리합니다. 트래픽이 들어오면 IPVS는 이 연결 테이블을 기반으로 해싱 알고리즘 등을 사용하여 빠르게 실제 파드를 선택합니다. iptables처럼 규칙을 순차적으로 검사하지 않기 때문에 규칙 수가 많아져도 성능 저하가 적고, 다양한 로드밸런싱 알고리즘(Round Robin, Least Connection 등)을 지원하여 더 효율적인 트래픽 분산이 가능합니다. 따라서 대규모 환경에서는 IPVS 모드가 일반적으로 더 나은 성능을 제공합니다.