14-(2) Docker Compose는 어떤 상황에서 유용하며, 일반 Dockerfile과 어떤 차이가 있나요?
🟢 Docker Compose의 개념
결론부터 말하면, Dockerfile은 ‘단일 컨테이너’의 설계도이고, Docker Compose는 여러 개의 컨테이너로 구성된 ‘하나의 완전한 애플리케이션’을 정의하고 실행하는 도구이다. 즉, 관리하는 스케일이 다름!
⚪ Docker Compose는 어떤 상황에 유용한가?
Docker Compose는 두 개 이상의 컨테이너가 함께 작동해야 하는 ‘다중 컨테이너 애플리케이션’ 환경에서 빛을 발한다.
예를 들어, 일반적인 웹 서비스를 개발한다고 생각해보자. 보통 이런 구성으로 시작할 것이다.
- 웹 서버 컨테이너 (Nginx, Apache)
- 애플리케이션 서버 컨테이너 (Python/Django, Node.js/Express)
- 데이터베이스 컨테이너 (PostgreSQL, MySQL)
- 캐시 서버 컨테이너 (Redis)
이 컨테이너들은 각각 별개의 이미지를 기반으로 하지만, 서로 네트워크로 연결되어 데이터를 주고받아야 하나의 서비스로 동작할 수 있다.
만약 Docker Compose가 없다면, 터미널에 docker run ... 명령어를 복잡한 네트워크 옵션과 함께 여러 번 입력해서 각각의 컨테이너를 띄우고 서로 연결해줘야 해. 개발 환경을 새로 구축할 때마다 이 과정을 반복해야 하니 정말 번거롭겠지?
Docker Compose는 이 모든 과정을 docker-compose.yml이라는 파일 하나에 깔끔하게 정의해두고, docker-compose up이라는 명령어 한 방으로 전체 애플리케이션을 띄우고, docker-compose down으로 한 번에 내릴 수 있게 해줘. 개발 환경의 설정과 실행을 엄청나게 단순화시켜주는 거지.
⚪ Dockerfile vs. Docker Compose: 역할의 차이
둘은 완전히 다른 목적을 가진 도구야. 서로를 대체하는 게 아니라 함께 사용되는 관계지.
- Dockerfile: 컨테이너 이미지 ‘만들기’ (BUILD)
- 목적: 단일 Docker 이미지를 어떻게 만들지를 정의하는 설계도 또는 레시피야.
- 내용: 베이스 이미지(e.g.,
FROM python:3.9), 필요한 패키지 설치(RUN pip install ...), 소스 코드 복사(COPY . .), 실행 명령어(CMD ["python", "app.py"]) 등 이미지 생성에 필요한 절차를 순서대로 기술해. - 결과물:
docker build명령어를 통해 하나의 Docker 이미지가 만들어져.
- Docker Compose: 다중 컨테이너 애플리케이션 ‘실행하기’ (RUN & ORCHESTRATE)
- 목적: 여러 컨테이너들의 실행 환경(Runtime)을 정의하는 설정 파일이야.
- 내용: 어떤 이미지들을 사용할지 (
image: ...또는build: .), 컨테이너들의 네트워크는 어떻게 구성할지, 어떤 포트를 외부에 노출할지, 데이터를 저장할 볼륨은 무엇인지 등 여러 컨테이너의 ‘관계’와 ‘실행 옵션’을YAML형식으로 기술해. - 결과물:
docker-compose up명령어를 통해yml파일에 정의된 모든 컨테이너가 실행되고 서로 연결된 애플리케이션 환경이 구축돼.
⚪ 비교 및 결론
| 구분 | Dockerfile | Docker Compose |
|---|---|---|
| 주요 목적 | 단일 Docker 이미지 빌드 | 다중 컨테이너 애플리케이션 실행 및 관리 |
| 형식 | 일반 텍스트 파일 (Dockerfile) | YAML 파일 (docker-compose.yml) |
| 관리 단위 | 하나의 컨테이너 | 여러 컨테이너 (서비스) |
| 사용 명령어 | docker build | docker-compose up, down, ps |
| 비유 | 개별 요리 레시피 (스테이크 굽는 법) | 코스 요리 메뉴판 (애피타이저, 메인, 디저트 구성) |
요약하자면, 각 서비스(웹, DB 등)의 Dockerfile로 개별 이미지를 만들고, Docker Compose 파일에 이 이미지들을 어떻게 조합해서 하나의 완전한 애플리케이션으로 동작시킬지 정의하는 거야. 개발 환경에서는 Docker Compose가 정말 필수적인 도구라고 할 수 있지.
⚪
🟢 예시 답안 (코드잇 제공)
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 시스템은 훨씬 더 복잡한 질의에도 유연하게 대응할 수 있습니다.