서론 (Introduction)

모두가 자율형 AI 에이전트 (autonomous AI agents)에 대해 이야기하고 있습니다.

에이전트에게 인터넷 접속 권한을 주고 LLM (Large Language Model)에 연결하면, 인간의 개입을 거의 하지 않고도 주제를 조사하고, 보고서를 작성하며, 비즈니스를 분석하고, 심지어 작업을 실행할 수도 있습니다.

자율형 에이전트를 방치한 채로 실행하기 전까지는 매우 인상적으로 들립니다.

실제로 AI 에이전트는 다음과 같은 문제를 일으킬 수 있습니다:

• 사실을 환각 (hallucinate) 함
• 무관한 정보를 수집함
• 무관한 정보를 수집함
• 검색 의도를 오해함
• 값비싼 API 토큰을 낭비함
• 부정확한 보고서를 자신 있게 생성함

프로토타입 (prototypes) 단계에서는 용납될 수 있을지 모릅니다.

하지만 프로덕션 시스템 (production systems)에서는 그렇지 않습니다.

이러한 의문은 저로 하여금 다른 철학을 바탕으로 프로젝트를 구축하게 만들었습니다:

AI는 작업을 자동화해야 하지만, 중요한 결정은 인간이 검증해야 한다.

또 다른 완전 자율형 에이전트를 만드는 대신, 저는 분석 전에 의도적으로 일시 중지하여 워크플로 (workflow)가 계속되기 전에 인간이 수집된 조사 내용을 검토할 수 있도록 설계된 멀티 에이전트 AI 리서치 시스템을 설계했습니다.

그 결과물은 다음을 결합합니다:

• CrewAI
• OpenAI GPT 모델
• Docker
• GitHub Actions
• Human-in-the-Loop 검증 및 단순한 AI 데모가 아닌 실제 프로덕션 시스템에서 영감을 받은 소프트웨어 엔지니어링 관행

왜 하나의 거대한 프롬프트를 사용하지 않는가? (Why Not Use One Giant Prompt?)

초기 설계 결정 중 하나는 모든 것을 하나의 프롬프트 (prompt) 안에 구축하는 것을 거부하는 것이었습니다.

GPT가 한 번의 요청으로 조사, 분석, 작성을 모두 할 수 있을까요?

물론 가능합니다.

하지만 그래야 할까요?

아마도 아닐 것입니다.

거대한 프롬프트는 다음과 같은 작업이 어려워집니다:

• 디버깅 (debug)
• 개선 (improve)
• 테스트 (test)
• 재사용 (reuse)
• 확장 (scale)

대신, 저는 책임을 독립적인 에이전트 (agents)로 분리했습니다.

에이전트 (Agent) | 책임 (Responsibility)
리서처 (Researcher) | 온라인 소스에서 정보 탐색
분석가 (Analyst) | 구조화된 추론을 사용하여 결과 평가
작성자 (Writer) | 다듬어진 Markdown 보고서 생성

이러한 분리는 단일 책임 원칙 (Single Responsibility Principle)을 따르며, 각 구성 요소를 독립적으로 최적화하기 쉽게 만듭니다.

전체 아키텍처 (Overall Architecture)

User
│
▼
Research Agent
│
▼
Human Validation (HITL)
│
Approve / Edit / Reject
│
▼
Analysis Agent
│
▼
Writer Agent
│
▼
Markdown Report

많은 AI 워크플로우 (workflows)와 달리, 여기에는 리서치 (research)와 분석 (analysis) 사이에 의도적인 일시 정지가 존재합니다.

그 일시 정지는 프로젝트 전체에서 가장 중요한 기능이 되었습니다.

Human-in-the-Loop 게이트웨이 (The Human-in-the-Loop Gateway)

대부분의 자율형 AI 데모 (demos)는 첫 번째 에이전트 (agent)가 항상 신뢰할 수 있는 출력을 생성한다고 가정합니다.

저는 의도적으로 그 가설에 도전했습니다.

리서치 결과를 분석가 (Analyst)에게 직접 전달하는 대신, CrewAI를 다음과 같이 설정했습니다:

human_input=True

실행이 해당 태스크 (task)에 도달하면:

1. 워크플로우 (workflow)가 일시 정지됩니다.
2. 리서치 결과가 터미널 (terminal)에 나타납니다.
3. 사용자가 이를 검토합니다.
4. 수정 사항을 반영할 수 있습니다.
5. 파이프라인 (pipeline)이 재개됩니다.

이 작은 변화가 보고서의 품질을 극적으로 향상시킵니다.

LLM (Large Language Model)에게 다른 LLM의 실수를 수정하라고 요청하는 대신, 이 워크플로우는 인간 검토자가 문제가 하류 에이전트 (downstream agents)로 전파되기 전에 개입할 수 있도록 허용합니다.

이는 엔터프라이즈 소프트웨어 (enterprise software)에서 흔히 볼 수 있는 승인 워크플로우 (approval workflows)를 반영합니다.

중요한 엔지니어링 결정 사항 (Engineering Decisions That Matter)

이 프로젝트를 통해 얻은 가장 큰 교훈 중 하나는 AI 시스템을 구축하는 것이 프롬프트 엔지니어링 (prompt engineering) 그 이상을 포함한다는 점이었습니다.

몇 가지 인프라 (infrastructure) 결정이 신뢰성을 크게 향상시켰습니다.

Docker

애플리케이션을 컨테이너화 (Containerizing)함으로써 여러 머신 (machines) 간에 환경이 일관되게 유지되도록 보장했습니다.

한 가지 흥미로운 과제는 Docker 컨테이너 내부에서 대화형 사용자 입력 (interactive user input)을 지원하는 것이었습니다.

워크플로우가 인간의 승인을 위해 일시 정지되기 때문에, 표준 컨테이너 실행만으로는 충분하지 않았습니다.

해결책으로 터미널 상호작용 (terminal interaction)이 가능하도록 Docker Compose 내부에서 다음을 활성화해야 했습니다:

• stdin_open
• tty

이 플래그 (flags)들이 없다면, 컨테이너 내부에서 Human-in-the-Loop 단계가 실패하게 됩니다.

GitHub Actions

리포지토리 (repository)를 프로덕션 레디 (production-ready) 상태로 유지하기 위해, 모든 푸시 (push) 시 다음 작업이 자동으로 실행됩니다:

• 의존성 설치 (dependency installation)
• flake8을 이용한 린팅 (linting)
• 코드 검증 (code validation)

단순하지만, 지속적 통합 (CI)은 변경 사항이 병합되기 전에 기본적인 품질 검사가 수행되도록 보장합니다.

또한 이는 중요한 엔지니어링 원칙을 보여줍니다:

자동화는 배포 훨씬 이전에 코드를 검증해야 합니다.

비용 최적화 (Cost Optimization)

여러 에이전트를 실행한다는 것은 모든 작업이 API 토큰을 소비함을 의미합니다.

개발 과정에서 저는 다양한 OpenAI 모델들을 실험했습니다.

리서치 워크플로 (research workflows)의 경우, GPT-4o Mini로 전환함으로써 대부분의 작업에서 수용 가능한 품질을 유지하면서도 비용을 상당히 절감할 수 있었습니다.

이 경험은 중요한 교훈을 확인시켜 주었습니다:

가장 비싼 모델을 선택하는 것이 항상 최선의 엔지니어링 결정은 아니라는 점입니다.

품질, 지연 시간 (latency), 그리고 비용 사이의 균형을 맞추는 것이 종종 원시 지능 (raw intelligence)을 극대화하는 것보다 더 가치 있습니다.

직면했던 과제들 (Challenges I Encountered)

프로젝트에 장애물이 없었던 것은 아닙니다.

가장 흥미로운 엔지니어링 문제 중 일부는 다음과 같았습니다:

• 에이전트 간의 구조화된 출력 (structured outputs) 유지
• 컨텍스트 드리프트 (context drift) 방지
• Docker 내에서의 대화형 터미널 세션 처리
• 반복 대신 추론 (reasoning)을 유도하는 프롬프트 설계
• 인간의 개입 (human intervention)이 이루어져야 할 지점 결정

각 과제는 이 프로젝트를 단순한 AI 데모를 넘어 실제적인 프로덕션 워크플로 (production workflow)에 더 가깝게 밀어붙였습니다.

다음에 개선하고 싶은 점 (What I'd Improve Next)

이 프로젝트를 계속 개발한다면, 다음과 같은 기능들을 추가하고 싶습니다:

• 더 높은 품질의 리서치를 위한 검색 증강 생성 (RAG)
• PostgreSQL을 사용한 지속성 저장소 (persistent storage)
• Redis 작업 큐 (task queues)
• 비동기 에이전트 실행 (asynchronous agent execution)
• OpenTelemetry를 이용한 관찰 가능성 (observability)
• 에이전트 성능을 위한 평가 지표 (evaluation metrics)
• 외부 통합을 위한 FastAPI 엔드포인트 (endpoints)
• Kubernetes 배포
• 인증 (authentication) 및 사용자 역할 (user roles)
• 보고서 버전 이력 (report version history)

이러한 추가 사항들은 프로젝트를 기업용 AI 플랫폼 (enterprise-ready AI platform) 단계로 이동시킬 것입니다.

배운 점 (Lessons Learned)

이 프로젝트를 구축하면서 AI 시스템에 대해 생각하는 방식이 바뀌었습니다.

가장 가치 있는 교훈은 여러 에이전트를 어떻게 오케스트레이션 (orchestrate) 하느냐가 아니었습니다.

신뢰성은 단순히 지능에서 오는 것이 아니라 엔지니어링에서 온다는 것을 배우는 것이었습니다.

프로덕션 (Production) AI 시스템에는 다음이 필요합니다:

• 검증 (validation)
• 관측 가능성 (observability)
• 자동화 (automation)
• 테스트 (testing)
• 비용 최적화 (cost optimization)
• 인간의 감독 (human oversight)

강력한 언어 모델 (language models)은 솔루션의 일부분일 뿐입니다.

훌륭한 소프트웨어 아키텍처 (software architecture)가 바로 모델을 신뢰할 수 있는 시스템으로 변모시키는 핵심입니다.

마치며 (Final Thoughts)

자율적인 AI 에이전트 (autonomous AI agents)를 둘러싼 기대감은 충분히 가치가 있습니다.

하지만 자율성만으로는 충분하지 않습니다.

기업이 신뢰할 수 있는 시스템은 자동화와 책임감 (accountability) 사이의 균형을 맞추는 시스템이 될 것입니다.

이 프로젝트는 전문화된 AI 에이전트와 Human-in-the-Loop 검증을 결합하여, 프로덕션 중심의 엔지니어링 관행을 따르면서도 더욱 신뢰할 수 있는 리서치를 생성하고자 했던 저의 탐구 과정이었습니다.

AI 엔지니어링 (AI Engineering), MLOps, 또는 멀티 에이전트 시스템 (multi-agent systems)에 관심이 있으시다면 여러분의 의견을 듣고 싶습니다.

전체 소스 코드는 GitHub에서 확인하실 수 있으며, 기여(contributions)나 피드백은 언제나 환영합니다.