46일차 회고｜Docker Compose·멀티 에이전트·포트폴리오 정리｜AI 오케스트레이션 개발자 국비지원

 

46일차는 지금까지 배운 멀티 에이전트 구조를 실제 실행 가능한 형태로 만들고, 기존 프로젝트를 Docker 환경에서 재현할 수 있도록 구성하는 과정을 중심으로 진행했다. 오후에는 여기서 한 단계 더 나아가 1·2차 프로젝트를 포트폴리오 관점에서 다시 정리하는 방법까지 다뤘다.

특히 오늘은 단순히 새로운 기술을 하나 배웠다기보다, 그동안 만들었던 프로젝트를 실제로 다른 환경에서 실행할 수 있게 만들고, 다른 사람이 봤을 때 내가 무엇을 이해하고 만들었는지 보여주는 방법을 생각해보는 날이었다.

---

오늘 배운 내용

오늘은 7장으로 넘어가면서 Single Agent에서 Multi-Agent로 확장되는 구조부터 시작했다.

여러 Agent가 하나의 목적을 수행하기 위해서는 각 Agent의 역할뿐만 아니라 이를 조율하는 Orchestrator(오케스트레이터)가 필요하다. 쉽게 말하면 여러 연주자를 지휘하는 지휘자처럼, 사용자의 요청을 보고 어떤 Agent와 Tool을 사용할지 전체 흐름을 관리하는 역할이다.

이 과정에서 Anthropic의 대표적인 Workflow 패턴도 살펴봤다.

• Prompt Chaining
• Routing
• Parallelization
• Orchestrator-Workers
• Evaluator-Optimizer

특히 Workflow와 Agent의 차이도 정리했다. Workflow는 미리 정해진 코드 흐름에 따라 LLM과 Tool을 사용하는 방식이고, Agent는 LLM이 상황에 따라 다음 행동이나 Tool을 선택하는 방식이다.

기존에는 하나의 Agent가 여러 Tool을 사용하는 구조를 중심으로 봤다면, 이제는 여러 전문 Agent를 Orchestrator가 조율하는 구조로 생각을 확장하게 됐다.

---

Docker Compose를 통해 배포 구조 이해하기

오전에는 DevOps와 CI/CD의 개념도 함께 다뤘다.

DevOps는 특정 프로그래밍 언어나 프로그램을 의미하는 것이 아니라 개발과 운영을 연결해 소프트웨어를 안정적으로 만들고 배포·운영하기 위한 방식이라는 점을 배웠다.

또 GitHub에 코드를 Commit하면 GitHub Actions가 자동으로 빌드와 배포를 수행하고, 이후 AWS에서 서비스를 실행하는 형태의 CI/CD 구조도 앞으로 진행할 예정이라는 설명을 들었다.

그 과정에서 Docker Compose가 왜 필요한지도 연결해서 이해할 수 있었다.

Docker Image가 애플리케이션을 실행하는 데 필요한 환경과 코드를 패키징한 것이라면, Docker Compose는 여러 Image와 서비스를 어떻게 실행하고 서로 연결할 것인지 정의하는 설정에 가깝다.

예를 들어 LawPath 프로젝트라면,

Frontend
Backend
MCP Server
PostgreSQL
Redis

같은 서비스를 하나의 Compose 파일로 연결해서 실행할 수 있다.

---

직접 진행한 Docker 실습

오늘 실습에서는 기존에 만들었던 LawPath 프로젝트를 개인 PC에서 실행할 수 있는 Docker 환경으로 구성했다.

기존에는 팀 서버의 IP나 개발 환경에 의존하는 부분이 있었지만, 이를 Docker Compose 기반으로 전환했다.

최종적으로는 다음과 같은 흐름을 목표로 했다.

docker compose up
        ↓
Frontend
Backend
MCP Server
PostgreSQL + pgvector
Redis 실행
        ↓
Frontend에서 질문
        ↓
Backend Agent 실행
        ↓
MCP 검색
        ↓
실제 법령·판례·상담사례 검색
        ↓
최종 답변

서비스별 환경변수도 확인했다.

frontend/.env
backend/.env
legal_mcp/.env
database/.env

실제 API Key나 비밀번호는 이미지나 Git에 포함하지 않고 .env.example을 통해 필요한 환경변수만 전달하는 구조로 정리했다.

또 Docker 컨테이너 내부에서는 기존처럼 무조건 127.0.0.1이나 localhost를 사용하는 것이 아니라, Docker Compose의 서비스명을 이용해 서로 통신하도록 수정했다.

예를 들어 Backend에서 DB와 Redis, MCP Server에 접근할 때 Docker 네트워크를 고려해야 했다.

---

Docker 실습에서 실제로 발생한 오류와 해결

이번 실습에서 가장 기억에 남았던 부분은 Docker 파일을 만드는 것 자체보다 각 서비스가 실제로 연결되는 과정에서 발생한 오류를 찾아 해결하는 과정이었다.

Redis Healthcheck 오류

Redis에 비밀번호가 설정되어 있었지만 healthcheck에서는 인증 없이 Redis에 접근하고 있었다.

Redis 실행 시 비밀번호를 사용하도록 수정하고, healthcheck에서도 인증 정보를 사용하도록 변경했다.

---

Backend Healthcheck 개선

처음에는 Backend가 실행되고 있는지만 확인하는 형태였지만, 실제 서비스에서는 Backend가 살아 있어도 DB나 Redis, MCP와 연결되지 않으면 정상적인 서비스라고 보기 어렵다.

그래서 Health endpoint가 다음과 같이 주요 의존 서비스의 상태까지 확인하도록 수정했다.

{
  "status": "ok",
  "dependencies": {
    "mcp": "ok",
    "database": "ok",
    "redis": "ok"
  }
}

이 과정을 통해 "서버가 켜져 있다"와 "서비스가 정상적으로 동작한다"는 서로 다른 문제라는 것을 이해했다.

---

MCP 검색 실패

MCP healthcheck 자체는 정상으로 보였지만 실제 법률 검색을 실행하면 실패하는 문제가 있었다.

확인 결과 legal_mcp/.env에 OPENAI_API_KEY가 제대로 전달되지 않은 것이 원인이었다.

MCP에서는 검색어를 벡터 임베딩으로 변환하기 위해 OpenAI API를 사용하고 있었기 때문에 단순히 MCP 서버가 실행되고 있는 것만으로는 검색 기능이 정상이라고 판단할 수 없었다.

필요한 환경변수를 전달한 뒤 실제 검색까지 다시 확인했다.

---

Agent Timeout 문제

Backend의 입력 판단 timeout이 8초로 설정되어 있었는데 실제 LLM 응답이 끝나기 전에 요청이 종료되는 문제가 발생했다.

기존 설정:

INPUT_ASSESSMENT_TIMEOUT_SECONDS=8

이를 60초로 변경하고 Backend를 재생성했다.

docker compose up -d --force-recreate backend

수정 후 Agent 분석이 정상적으로 완료되는 것을 확인했다.

이 과정에서 애플리케이션의 로직이 잘못된 것이 아니라 실행 환경의 timeout 설정 때문에 기능이 실패할 수도 있다는 점을 다시 확인했다.

---

실제 법률 데이터를 Docker 환경에서 재현

이번 실습에서 특히 의미 있었던 부분은 단순히 목업 데이터를 넣고 Docker가 실행되는 것만 확인한 것이었다면, 실제 프로젝트에서 사용하던 법률 검색 데이터를 Docker 환경에서도 재현하도록 구성했다는 점이다.

개인 PostgreSQL에 있던 공개 검색 데이터를 기준으로 다음 데이터를 준비했다.

• 법령 8건
• 판례 16건
• 소비자 상담사례 678건
• 전체 문서 702건
• 전체 청크 2,797건
• 임베딩 누락 0건

그리고 실제 질문을 넣어 검색을 확인했다.

신용카드 일시불 결제 후 할부로 전환했는데 물건이 배송되지 않았습니다. 카드사에 할부항변권을 행사할 수 있나요?

실제 결과에서 법령, 판례, 소비자원 상담사례가 각각 검색되고 Agent 분석까지 정상적으로 완료되는 것을 확인했다.

단순히 "Docker 컨테이너가 실행된다"에서 끝난 것이 아니라 "실제 프로젝트 기능까지 Docker 환경에서 동작한다"는 것을 검증한 것이다.

또한 database/seed/010_legal_search_data.sql.gz 형태로 실제 검색 데이터를 재현할 수 있도록 구성하고, PostgreSQL Image에도 검색 데이터를 포함하는 방식까지 실습했다.

---

Docker Compose 개발용과 릴리스용 분리

이번 작업에서는 Compose 파일도 용도에 따라 구분했다.

compose.yml
→ 로컬에서 Dockerfile을 직접 build

compose.release.yml
→ Docker Hub Image를 pull해서 실행

Docker Hub에 사용할 Image Tag도 준비했다.

jso4603/lawpath-frontend:1.0.0
jso4603/lawpath-backend:1.0.0
jso4603/lawpath-mcp:1.0.0
jso4603/lawpath-postgres:1.0.0

아직 실제 Docker Hub push까지 진행한 것은 아니지만, 로컬에서 만든 Image를 다른 환경에서 가져와 실행할 수 있는 배포 구조까지 생각해볼 수 있었다.

---

Frontend 문제도 Docker 환경에서 해결

Frontend에서는 Streamlit 기본 다크 테마와 LawPath CSS가 충돌하면서 일부 버튼과 입력창이 검은색으로 보이는 문제가 발생했다.

이를 확인하고

frontend/.streamlit/config.toml

에서 라이트 테마를 명시해 해결했다.

또 기존 개발 과정에서 사용하던 팀 서버 연결 테스트 영역도 일반 화면에서는 보이지 않도록 설정했다.

이런 문제를 해결하면서 Docker 작업이 단순히 Backend 서버만 컨테이너에 넣는 작업이 아니라 실제 사용자가 보는 화면부터 서버와 DB까지 전체 실행 환경을 맞추는 작업이라는 점도 체감했다.

---

오늘 새롭게 이해한 점

오늘 가장 크게 이해한 것은 "개발 환경을 구성하는 것"과 "재현 가능한 실행 환경을 만드는 것"은 다르다는 점이다.

내 컴퓨터에서 정상적으로 실행된다고 해서 다른 사람의 컴퓨터에서도 바로 실행되는 것은 아니다.

DB가 필요하고, Redis가 필요하고, MCP 서버가 필요하고, 각각의 환경변수와 실행 순서도 필요하다.

Docker와 Compose를 사용하면 이런 요소들을 하나의 실행 구조로 묶을 수 있다.

결국 오늘 실습은 단순히 Docker 명령어를 외우는 것이 아니라,

내 컴퓨터에서 실행된다
        ↓
필요한 실행 환경을 정의한다
        ↓
각 서비스를 Image로 패키징한다
        ↓
Compose로 연결한다
        ↓
다른 환경에서도 같은 구조를 재현한다

라는 흐름을 이해하는 과정이었다.

---

포트폴리오는 "많이 보여주는 것"보다 "이해시키는 것"

8교시에는 Docker 실습에서 잠시 벗어나 1차·2차 프로젝트의 포트폴리오를 다시 구성하는 방법에 대한 피드백을 받았다.

특히 기억에 남았던 것은 Codex가 프로젝트를 많이 만들어줬다는 사실을 보여주는 것이 포트폴리오의 목적이 아니라는 것이었다.

포트폴리오를 보는 사람 입장에서는 모든 코드를 처음부터 끝까지 읽지 않는다.

그래서 첫 화면에서 바로 다음 내용이 보여야 한다.

• 무엇을 만든 프로젝트인지
• 어떤 기술을 사용했는지
• 시스템이 어떻게 구성되어 있는지
• DB는 어떻게 설계했는지
• AI Agent가 어떻게 동작하는지
• 내가 어떤 부분을 담당했는지
• 실제로 어떻게 실행되는지

특히 화면 캡처를 많이 넣는 것보다 핵심 기능이 실제로 실행되는 GIF나 영상을 보여주는 것이 더 효과적이라는 점도 배웠다.

예를 들어 법률 AI Agent라면 단순히 검색 화면만 보여주는 것보다,

사용자 질문
→ Agent 판단
→ MCP 호출
→ 법률 데이터 검색
→ Agent 분석
→ 최종 답변

이라는 흐름을 보여주는 것이 프로젝트의 기술적인 특징을 더 잘 전달할 수 있다.

---

Database와 시스템 구조도 다시 보기

프로젝트 포트폴리오에서 DB 설계도 중요하다는 피드백을 받았다.

아직 데이터베이스를 깊게 공부한 것은 아니지만, 실제 프로젝트에서 데이터를 저장하고 조회하고 수정하는 역할을 직접 경험했기 때문에 DB가 프로젝트에서 어떤 역할을 했는지 설명할 수 있어야 한다는 것이다.

따라서 ERD와 함께 주요 테이블과 관계를 보여주고, 전체 시스템 구성에서는 Frontend, Backend, MCP Server, LLM, Database 등이 어떻게 연결되어 있는지를 한눈에 보여주는 방향으로 정리할 필요가 있다.

결국 포트폴리오에서 중요한 것은 화면 개수가 아니라 프로젝트를 구성한 기술과 시스템을 내가 이해하고 있다는 것을 보여주는 것이라고 느꼈다.

---

오늘의 회고

46일차에는 지금까지 배웠던 AI Agent 기술이 실제 서비스 환경으로 넘어가기 위해 어떤 것들이 필요한지 조금 더 구체적으로 볼 수 있었다.

특히 Multi-Agent → Orchestrator → Docker → Compose → DB/Redis/MCP 연결 → 실제 데이터 → 재현 가능한 실행 환경으로 이어지는 흐름이 하나의 과정으로 연결됐다.

처음에는 Docker가 단순히 "프로그램을 컨테이너에서 실행하는 기술" 정도로만 느껴졌는데, 오늘 직접 여러 서비스와 환경변수를 연결하고 오류를 해결하면서 애플리케이션 전체 실행 환경을 하나의 구조로 관리하는 기술이라는 점을 조금 더 이해하게 됐다.

동시에 아직 부족한 부분도 분명하다.

Docker Compose 구조를 직접 처음부터 설계하는 것, 컨테이너 네트워크를 정확하게 이해하는 것, DB 초기화와 데이터 구조를 설계하는 것, 그리고 이후 AWS에서 실제로 배포하는 과정까지는 더 공부가 필요하다.

무엇보다 오늘 포트폴리오 피드백을 통해 "무엇을 만들었는가"뿐만 아니라 "내가 무엇을 이해하고 어떤 문제를 해결했는가"를 보여주는 것이 중요하다는 것도 다시 생각하게 됐다.

앞으로 프로젝트를 정리할 때 단순히 결과물과 기술 스택을 나열하기보다는, 시스템 구조와 실제 구현 과정, 문제 해결 경험, 그리고 내가 담당한 부분이 자연스럽게 드러나도록 정리해봐야겠다.

---

오늘 복습할 내용

• Multi-Agent와 Orchestrator의 관계
• Workflow와 Agent의 차이
• Docker Image와 Container의 차이
• Docker Compose의 역할
• Docker 컨테이너 간 네트워크 통신
• .env와 .env.example 관리
• Healthcheck의 의미
• DB Schema와 Seed 데이터
• pgvector 기반 검색 데이터 재현
• Docker Compose 개발용/릴리스용 구성
• 포트폴리오에서 Architecture와 개인 역할을 보여주는 방법
• Agent의 실제 동작 과정을 GIF/영상으로 표현하는 방법

46일차는 "AI Agent를 만드는 것"에서 한 단계 더 나아가, 만든 시스템을 실제 실행 가능한 형태로 패키징하고 다른 사람에게 제대로 설명하는 방법까지 생각해본 날이었다.