14-(3) Kubernetes의 기본 개념은 무엇이며, Docker와는 어떤 관계가 있나요?
🟢 Kubernetes의 기본 개념과 Docker와의 관계
이번엔 Docker 다음 단계인 Kubernetes에 대해 포스팅하고자 한다.
이 포스트는 공신력 있는 블로그 몇개를 참고하여 작성하였으니 참고바란다.
⚪ Kubernetes의 기본 개념
쿠버네티스(Kubernetes, 줄여서 K8s)는 컨테이너 오케스트레이션(Container Orchestration) 도구이다. Docker로 컨테이너 한두 개를 띄우는 건 쉽지만, 수십, 수백 개의 컨테이너가 얽혀있는 복잡한 서비스를 운영하려면 이걸 자동으로 관리해줄 시스템이 필요하다. 바로 그 역할을 K8s가 하는 것.
K8s가 해결해주는 핵심 문제들은 다음과 같음:
- 자동화된 배포와 롤백: 새 버전의 앱을 배포하거나 문제가 생겼을 때 이전 버전으로 쉽게 되돌릴 수 있음.
- 서비스 디스커버리와 로드 밸런싱: 여러 개의 컨테이너에 네트워크 트래픽을 알아서 분산시켜줌.
- 자동 복구 (Self-healing): 특정 컨테이너가 죽으면? K8s가 알아서 감지하고 다시 실행시켜줌.
- 자동 확장 (Auto-scaling): 사용량이 몰리면 자동으로 컨테이너 수를 늘리고, 줄어들면 다시 줄여서 자원을 효율적으로 사용하게 함.
이런 마법 같은 일들을 하기 위해 K8s는 몇 가지 중요한 개념을 사용함.
- 클러스터 (Cluster): K8s의 전체 시스템. 여러 대의 컴퓨터(서버)가 하나처럼 동작하는 집합.
- 노드 (Node): 클러스터를 구성하는 개별 컴퓨터(물리 서버 또는 가상 머신). 컨테이너들이 실제로 실행되는 장소.
- 파드 (Pod): K8s에서 생성하고 관리하는 가장 작은 배포 단위. 하나 이상의 컨테이너 그룹. 보통 하나의 파드에는 하나의 메인 컨테이너를 넣어서 관리함. 파드는 고유한 IP 주소를 가지며, 함께 묶인 컨테이너들은 이 IP와 저장 공간(볼륨)을 공유함.
- 디플로이먼트 (Deployment): “우리는 이 파드를 항상 3개 유지하고 싶어”와 같이, 파드의 상태를 정의하고 관리하는 역할이다. 앱을 업데이트하거나 확장할 때 주로 사용됨.
- 서비스 (Service): 여러 파드에 걸쳐 안정적인 네트워크 연결(고정 IP 주소와 DNS 이름)을 제공하는 방법. 파드는 언제든 죽고 새로 생길 수 있어서 IP가 계속 바뀌는데, 서비스는 이 변화와 상관없이 외부에서 파드에 접근할 수 있는 고정된 창구 역할을 해줌.
⚪ Docker와 Kubernetes의 관계
둘은 경쟁 관계가 아니라, 파트너 관계.
- Docker는 ‘컨테이너’를 만들고 실행하는 역할 (Build & Run)
- Docker는
Dockerfile을 이용해 애플리케이션을 이미지로 패키징하고, 그 이미지를 컨테이너로 실행시키는 컨테이너 런타임(Container Runtime) 기술.
- Docker는
- Kubernetes는 그 ‘컨테이너’들을 관리하고 조율하는 역할 (Orchestrate)
- Kubernetes는 Docker가 만든 컨테이너들을 가져다가, 어느 서버(노드)에 몇 개를 배치할지, 트래픽은 어떻게 분배할지, 문제가 생긴 컨테이너는 어떻게 처리할지를 총괄 지휘함.
비유하자면, Docker는 표준 규격의 해상 운송 컨테이너를 만드는 기술이고 *Kubernetes는 수많은 컨테이너들을 배에 싣고 내리며, 전 세계 항구를 오가는 거대한 물류 시스템.
즉, K8s는 Docker 같은 컨테이너 런타임 위에서 동작. K8s가 “이 컨테이너를 실행시켜 줘!”라고 명령하면, 각 노드에 설치된 Docker가 그 명령을 받아 실제로 컨테이너를 띄우는 구조다. (최근에는 Docker 외에 containerd나 CRI-O 같은 다른 컨테이너 런타임을 사용하기도 하지만, 개념적으로는 동일하다.)
⚪ 비교 및 결론
| 구분 | Docker | Kubernetes |
|---|---|---|
| 주요 역할 | 컨테이너 생성 및 실행 | 컨테이너 관리 및 조율 (오케스트레이션) |
| 작동 범위 | 단일 노드 (개별 컴퓨터) | 다중 노드로 구성된 클러스터 |
| 핵심 단위 | 컨테이너 (Container) | 파드 (Pod) |
| 비유 | 표준화된 ‘컨테이너 박스’ | 컨테이너를 관리하는 ‘거대 항만 시스템’ |
| 관계 | Kubernetes가 관리할 ‘대상’ | Docker 컨테이너를 관리하는 ‘관리자’ |
결론적으로, Docker로 앱을 컨테이너화하고, Kubernetes를 이용해 그 컨테이너들을 대규모 서비스 환경에서 안정적으로 운영하는 것이 현대적인 클라우드 개발의 표준 방식이다. 이 둘의 관계를 이해하면 MSA(마이크로서비스 아키텍처)나 클라우드 네이티브 환경을 이해하는 데 큰 도움이 될 것이다.
🟢 예시 답안 (코드잇 제공)
RAG 시스템에서 ‘Agent’는 단순히 질문에 대한 검색과 답변 생성만 수행하는 고정된 흐름이 아니라, 질문을 이해하고 상황에 따라 필요한 행동을 스스로 결정하며 여러 단계를 유연하게 수행할 수 있는 실행 주체입니다.
예를 들어, 일반적인 RAG 시스템은 사용자의 질문을 받으면 관련 문서를 검색하고, 그 내용을 바탕으로 답변을 생성하는 정해진 구조를 따릅니다. 하지만 어떤 질문은 단순하지 않고, 질문을 쪼개거나, 여러 정보를 종합하거나, 추가적인 판단이 필요한 경우가 많습니다. 이럴 때 Agent는 질문의 목적을 이해하고, 어떤 도구를 언제 사용해야 할지 스스로 판단하며, 검색 → 요약 → 비교 → 응답 생성 같은 복합적인 과정을 순차적으로 수행할 수 있습니다.
Agent는 일종의 ‘지능형 문제 해결자’라고 보면 됩니다. LLM을 기반으로 하고, 다양한 도구와 상호작용하면서 복잡한 태스크를 해결하는 구조죠.
Agent를 구현하려면 다음과 같은 요소가 필요합니다.
첫째, 언어 모델(LLM)이 핵심입니다. Agent는 LLM을 기반으로 사용자의 질문을 분석하고 다음 행동을 결정합니다.
둘째, Tool 또는 Function이 필요합니다. 예를 들어 검색기, 계산기, 데이터베이스 조회기, 요약기 같은 기능이 대표적입니다. Agent는 이 도구들을 상황에 따라 호출해서 결과를 얻고, 다시 다음 행동으로 이어갑니다.
셋째, 메모리(Memory) 기능이 있다면 더 유용합니다. 이전 질문이나 중간 결과를 기억하고 활용할 수 있어 더 자연스럽고 일관성 있는 작업이 가능해집니다.
LangChain 같은 프레임워크에서는 Agent를 구현하는 기능을 기본적으로 지원합니다. initialize_agent 함수로 LLM과 사용할 도구들을 등록하고, 어떤 스타일의 Agent를 사용할지 정의하면 됩니다. 예를 들어, 검색기와 요약기를 도구로 등록해 두면, Agent가 사용자의 질문에 따라 먼저 검색을 하고, 그 결과를 요약한 뒤 최종 응답을 만드는 식으로 자동으로 동작하게 만들 수 있습니다.
정리하면, RAG 시스템에서 Agent는 단순한 검색-생성 구조를 넘어서 질문을 해석하고, 적절한 전략을 스스로 선택하며, 필요한 작업을 단계적으로 수행할 수 있는 유연한 실행 엔진이라고 할 수 있습니다. Agent가 들어가면 RAG 시스템은 훨씬 더 복잡한 질의에도 유연하게 대응할 수 있습니다.