설계에서 실제 AI 에이전트 실행까지
한 줄 요약
지난주에 설계했던 개인용 멀티에이전트 서버를 실제로 구현하기 시작했습니다. 프로젝트 접수·승인·실행 상태관리부터 실제 OpenAI 기반 기업분석 에이전트와 업무 프로세스 분석 에이전트까지 구현했고, 이제 두 에 이전트가 분석 결과를 근거와 함께 전달하는 Agent-to-Agent Handoff 단계로 넘어가고 있습니다.
1. 지난주 계획에서 실제 구현으로
지난주에는 다음과 같은 구조를 계획했습니다.
사용자 요청
→ 프로젝트 접수
→ waiting
→ 사용자 승인
→ 기업분석
→ AX 전략수립
→ 경영진 보고서당시에는 아직 설계 단계였기 때문에 “과연 실제로 이렇게 작동할까?”가 가장 큰 궁금증이었습니다.
이번 주에는 전체 시스템을 한꺼번에 만들기보다 작은 버전으로 나누어 하나씩 구현하고 테스트했습니다.
현재까지 구현한 큰 흐름은 다음과 같습니다.
프로젝트 생성
↓
waiting
↓
사용자 승인
↓
execution 생성
↓
Company Analyst
↓
Process Analyst
↓
결과·상태·실행기록 저장아직 AX 전략 에이전트와 보고서 에이전트까지 연결하지는 않았습니다.
대신 그 전에 각 에이전트가 믿을 수 있는 결과를 만들고, 그 결과가 다음 에이전트로 안전하게 전달되는 구조를 만드는 데 집중했습니다.
2. 먼저 프로젝트 상태와 사람의 승인을 구현
가장 먼저 만든 것은 AI가 아니었습니다.
프로젝트를 접수하고 상태를 저장하고, 사람이 승인한 뒤에만 실행할 수 있도록 하는 구조부터 만들었습니다.
waiting
→ approved
→ running
→ completed
문제 발생 시
→ failed여기서 중요하게 생각한 원칙은 지난주 계획과 같습니다.
요청을 받았다는 것과 실행 권한을 줬다는 것은 다르다.
앞으로 에이전트가 이메일을 보내거나, 파일을 변경하거나, 외부 시스템을 조작하게 된다면 이 구분은 더 중요해질 것 같습니다.
3. 첫 번째 실제 AI 직원, Company Analyst
다음으로 기업분석 에이전트(Company Analyst)를 만들었습니다.
처음에는 실제 OpenAI를 연결하지 않고 Fake Provider를 이용해 전체 구조부터 테스트했습니다.
그 다음 LLM Gateway와 OpenAI Provider를 분리해 실제 API를 연결했습니다.
현재 Company Analyst는 입력받은 기업정보를 다음과 같이 구조화합니다.
기업 개요
사업영역
제품·서비스
고 객·시장
조직과 업무 특성
핵심 프로세스
IT·디지털 현황
문제점
AI·AX 적용기회
추가 확인이 필요한 정보
여기서 특히 신경 쓴 것은 AI가 모르는 기업정보를 사실처럼 만들어내지 못하게 하는 것이었습니다.
그래서 결과를 대략 다음과 같이 구분하도록 했습니다.
USER_PROVIDED
사용자가 직접 제공한 정보
FACT
출처로 확인된 정보
INFERENCE
AI가 근거를 바탕으로 추론한 내용
UNKNOWN
현재 정보로 확인할 수 없는 내용실제 OpenAI API를 연결하여 테스트했고 정상적으로 기업분석 결과가 생성되고 DB에 저장되는 것까지 확인했습니다.
4. 두 번째 AI 직원, Process Analyst
기업을 분석하는 것만으로는 AX 과제를 제대로 찾기 어렵다고 판단했습니다.
실제 AX는 결국 “회사의 업무가 지금 어떻게 돌아가고 있으며, 그중 무엇을 AI가 도울 것인가?”의 문제이기 때문입니다.
그래서 당초 계획을 조금 발전시켜 두 번째 에이전트로 Process Analyst를 추가했습니다.
예를 들어,
기업 고객 문의 → 요구사항 정리 → 기존 자료 검색 → 제안서 작성 → 내부 검토 → 수정 → 승인 → 고객 제출
이라는 업무를 입력하면 Process Analyst가 이를 단계별로 구조화합니다.
실제 OpenAI 테스트에서는 다음과 같이 7개 업무 단계로 분석했습니다.
고객 문의 및 요구사항 정리
↓
기존 내부 자료 탐색·검토
↓
제안서 초안 작성
↓
내부 검토
↓
제안서 수정
↓
최종 승인
↓
고객 제출그리고 여기서 다시
담당자
입력정보
수행업무
산출물
사용 시스템
Pain Point
병목
반복업무
AI 적용기회
자동화 가능영역
AX Use Case
추가 확인정보
를 구조화하도록 했습니다.
흥미로운 점은 입력하지 않은 Salesforce, SAP 같은 시스템을 임의로 만들어내지 않고 UNKNOWN으로 남겼다는 것입니다.
5. 구현하면서 발견한 중요한 문제
실제 개발을 해보니 프롬프트만 잘 작성한다고 해결되는 것이 아니었습니다.
예를 들어 AI가 출처가 있는 source_fact 하나를 제시하면서 그 옆에 실제 출처에는 없는 시스템명이나 담당자를 추가할 가능성이 있었습니다.
즉,
출처가 있는 사실
+
AI가 만들어낸 세부정보가 하나의 FACT처럼 저장될 수도 있었습니다.
코드 리뷰 과정에서 이 문제를 발견했고, FACT로 저장되는 업무 단계는 실제 근거가 해당 내용을 뒷받침하는지 추가 검증하도록 수정했습니다.
이 과정을 거치면서 느낀 점은 기업용 AI 에이전트에서는 단순한 “좋은 답변”보다
왜 이런 답을 했는지, 무엇이 사실이고 무엇이 추론인지 추적할 수 있는 구조
가 훨씬 중요하다는 것입니다.
6. 테스트도 에이전트의 일부라는 것을 배웠다
이번에는 기능을 하나 추가할 때마다 자동 테스트를 계속 추가했습니다.
초기 버전에서 시작해 현재는 전체 183개 테스트가 모두 통과하는 상태까지 왔습니다.
또한 코드 작성 후 별도의 코드 리뷰를 돌려 문제를 찾고,
구현
→ 단위 테스트
→ 전체 회귀 테스트
→ 코드 리뷰
→ 수정
→ 다시 전체 테스트
→ 실제 OpenAI 1회 검증순서로 진행했습니다.
덕분에 “한 번 실행됐으니 성공”이 아니라 기존 기능을 깨뜨리지 않으면서 새로운 기능을 추가하는 방식을 조금씩 익혀가고 있습니다.
7. 이제 두 AI 직원이 서로 인수인계하게 만든다
현재 다음 단계는 Company Analyst → Process Analyst Handoff입니다.
지금까지 두 에이전트는 각각 독립적으로 실행됩니다.
앞으로는 다음과 같이 연결하려고 합니다.
Company Analyst
↓
기업 분석결과
↓
Handoff
↓
Process Analyst그런데 단순히 앞 에이전트가 만든 JSON 전체를 다음 에이전트에게 넘기지는 않을 계획입니다.
필요한 정보만 선별하면서 다음 정보도 함께 전달하려고 합니다.
어느 Agent가 만들었는가?
어느 실행에서 만들어졌는가?
어떤 원본 항목에서 왔는가?
USER_PROVIDED인가?
FACT인가?
INFERENCE인가?
UNKNOWN인가?특히 앞 에이전트의 INFERENCE가 다음 에이전트로 넘어가면서 갑자기 FACT가 되지 않도록 해야 합니다.
이것이 이번에 처음 구현해보는 Agent Provenance와 Traceability입니다.
8. 지난주와 비교하면 생각이 조금 바뀌었다
지난주에는 멀티에이전트 시스템을 주로 이렇게 생각했습니다.
“기업분석 AI → AX 전략 AI → 보고서 AI를 순서대로 연결하면 되지 않을까?”
직접 구현해보니 그 사이가 훨씬 중요했습니다.
누가 만들었는가
↓
무슨 근거로 만들었는가
↓
사실인가 추론인가
↓
어느 Agent에게 넘길 것인가
↓
넘긴 정보가 변형되지는 않았는가
↓
실패하면 어디에서 멈췄 는가결국 멀티에이전트의 핵심은 AI의 숫자가 아니라 AI 사이의 운영체계라는 지난주의 생각이 실제 개발을 하면서 더 분명해졌습니다.
9. 다음 주 목표
다음 단계에서는 우선 가장 작은 Agent 협업을 완성해보려고 합니다.
사용자 승인
↓
Company Analyst
↓
Company → Process Handoff
↓
Process Analyst
↓
결과 저장이 흐름이 안정적으로 작동하면 다음에는 AX Strategist를 추가해볼 생각입니다.
그러면 처음으로
기업을 이해하는 AI
↓
업무를 이해하는 AI
↓
AX 전략을 설계하는 AI라는 작은 AI 컨설팅팀이 만들어집니다.
그 이후에 보고서 에이전트, Telegram, Docker, 대시보드 등을 단계적으로 붙여볼 계획입니다.
이번 주에 가장 크게 배운 점
지난주에는 “AI 에이전트를 어떻게 연결할 것인가?”가 가장 중요한 문제라고 생각했습니다.
이번 주 직접 만들어보면서 질문이 조금 바뀌었습니다.
“AI에게 일을 맡길 때, 그 AI의 판단을 어떻게 믿고 다음 AI에게 넘길 것인가?”
좋은 멀티에이전트 시스템은 AI가 많이 들어간 시스템이 아니라, 역할과 근거, 상태와 승인, 인수인계와 책임을 추적할 수 있는 시스템에 더 가까운 것 같습니다.
아직 갈 길은 멀지만, 지난주 종이에 그렸던 구조가 이번 주에는 실제 API와 데이터베이스, 그리고 실제 LLM 을 통해 하나씩 움직이기 시작했습니다.
다음 주에는 계속해서 두 AI 직원이 처음으로 제대로 업무를 인수인계하는 과정을 만들어보겠습니다.
