AX AgentWorks Home Server 구축 실행계획

한 줄 요약

사용자가 회사명과 과제를 입력하면 기업분석, AX 전략수립, 경영진 보고서 작성 에이전트가 역할을 나누어 협업하고, 사람의 승인과 작업 상태관리를 거쳐 최종 보고서를 생성하는 개인용 멀티에이전트 서버를 구축해보고자 합니다.

1. 이번에 해보려는 것

이번 과정에서는 단순히 질문에 답하는 챗봇이 아니라, 여러 AI 에이전트가 하나의 업무를 나누어 수행하는 AX AgentWorks Home Server를 만들어보려고 합니다.

사용자가 텔레그램이나 웹 화면에서 다음과 같이 요청하는 방식입니다.

A기업의 기존 사업을 분석하고, 적용 가능한 AI·AX 신규사업 전략과 90일 실행계획을 작성해줘.

서버는 이 요청을 프로젝트로 접수한 뒤 바로 실행하지 않고 waiting 상태로 저장합니다.

사용자가 프로젝트 내용을 확인하고 승인하면 다음 작업을 순서대로 수행하도록 설계할 계획입니다.

1. 기업분석 에이전트가 사업구조와 문제를 분석

2. AX 전략 에이전트가 AI 적용과 조직 전환과제를 설계

3. 보고서 에이전트가 결과를 경영진 보고서로 통합

4. 최종 결과를 Markdown 파일로 저장

5. 프로젝트 상태와 실행기록을 데이터베이스에 저장

6. 텔레그램이나 웹 화면으로 결과 전달

이번 과제의 핵심은 여러 AI를 단순히 연결하는 것이 아니라, 역할·순서·상태·승인·기록을 가진 하나의 운영체계로 만드는 것입니다.

2. 먼저 밝혀둘 점

이번 글은 실제 구축을 완료한 결과가 아니라, 앞으로 직접 구현할 실행계획과 1차 설계안입니다.

현재까지 LLM과 함께 다음 내용을 검토했습니다.

• FastAPI 기반 API 서버

• 프로젝트 접수와 승인

• 세 개 전문 에이전트의 역할

• 에이전트 간 결과 전달

• SQLite 상태관리

• Markdown 보고서 저장

• Telegram Bot 연결

• Docker 상시 실행

• Tailscale 원격접속

• 향후 동적 오케스트레이션 확장

실제 구현 과정에서는 API 버전, 운영체제, Docker 설정, AI 응답형식과 오류 상황에 따라 일부 구조가 변경될 수 있습니다.

3. 전체 구조

현재 구상한 구조는 다음과 같습니다.

사용자 요청
   ↓
프로젝트 접수
   ↓
waiting 상태 저장
   ↓
사용자 승인
   ↓
기업분석 에이전트
   ↓
AX 전략 에이전트
   ↓
경영진 보고서 에이전트
   ↓
보고서 저장·결과 전달

초기 버전에서는 에이전트 실행 순서를 고정할 계획입니다.

처음부터 AI가 필요한 에이전트를 자유롭게 선택하게 하면 구현과 오류 확인이 어려워질 수 있기 때문입니다.

고정된 순차형 구조가 안정적으로 작동한 뒤, 사용자의 요청에 따라 필요한 에이전트만 선택하는 동적 오케스트레이터로 확장할 계획입니다.

4. 에이전트별 역할

기업분석 에이전트

다음 내용을 분석합니다.

• 기업과 사업 개요

• 주요 고객과 가치제안

• 핵심 업무 프로세스

• 현재 문제와 병목

• AI·AX 적용 가능 영역

• 추가 확인이 필요한 정보

확인되지 않은 사실은 임의로 만들지 않고, 추론이나 가정은 별도로 표시하도록 설계할 계획입니다.

AX 전략 에이전트

기업분석 결과를 바탕으로 다음을 작성합니다.

• AX 추진 목표

• 우선 적용 업무

• 업무별 AI Agent 후보

• 사람의 검토가 필요한 지점

• 데이터와 기존 시스템 연계

• 30일·60일·90일 실행계획

• KPI와 예상 위험

단순히 AI 도구를 추천하는 것이 아니라, 실제 업무 프로세스와 조직 운영방식이 어떻게 달라지는지를 작성하도록 할 예정입니다.

경영진 보고서 에이전트

앞선 결과를 다음 구조의 보고서로 통합합니다.

1. Executive Summary

2. 추진 배경

3. 기업 현황과 문제

4. AX 전략 방향

5. 우선 추진과제

6. AI Agent 운영모델

7. 90일 로드맵

8. KPI

9. 위험관리

10. 경영진 의사결정 사항

5. 상태관리와 승인 절차

프로젝트 상태는 다음과 같이 관리할 계획입니다.

waiting
→ running
→ completed

오류가 발생하면 failed, 사용자가 취소하면 cancelled로 기록합니다.

사용자의 요청을 즉시 실행하지 않고 먼저 승인받는 이유는 다음과 같습니다.

• 잘못된 회사명이나 과제 입력 방지

• 불필요한 API 비용 방지

• 중복 실행 방지

• 향후 외부 전송이나 파일 변경 기능에 대비

• 사람이 중요한 실행권한을 유지

따라서 다음 원칙을 적용하려고 합니다.

접수 ≠ 실행
요청 수신 ≠ 권한 부여
waiting = 저장됐지만 아직 실행되지 않은 상태

6. 사용할 기술과 운영 방식

현재 계획한 기술 구성은 다음과 같습니다.

• Python

• FastAPI

• OpenAI Agents SDK 또는 LLM API

• SQLite

• Telegram Bot

• Docker Compose

• Tailscale

• Markdown 보고서

• Claude Code 또는 Codex 기반 바이브코딩

Docker 컨테이너에는 서버와 에이전트 실행코드를 넣고, 데이터베이스와 보고서는 Windows 실제 폴더에 저장할 계획입니다.

Docker Container
- FastAPI
- Telegram Bot
- AI Agent 코드

Windows 폴더
- data/agentworks.db
- reports/*.md
- logs/*.log

이렇게 하면 컨테이너를 삭제하거나 다시 만들어도 프로젝트 기록과 보고서가 유지됩니다.

7. 단계별 구현계획

전체 기능을 한 번에 만들지 않고 다음 순서로 진행할 계획입니다.

1단계: 기본 API 서버

GET /health
POST /projects
GET /projects
GET /projects/{id}

2단계: 프로젝트 상태 저장

SQLite에 다음 상태를 기록합니다.

waiting / running / completed / failed / cancelled

3단계: 승인 기능

프로젝트가 접수된 뒤 사용자가 승인해야 실행되도록 합니다.

4단계: 기업분석 에이전트

먼저 하나의 에이전트만 연결하고 결과가 정상적으로 저장되는지 확인합니다.

5단계: AX 전략 에이전트

기업분석 결과를 다음 에이전트에 전달합니다.

6단계: 보고서 에이전트

두 결과를 하나의 경영진 보고서로 통합합니다.

7단계: 대시보드와 Telegram

프로젝트 접수, 승인, 상태확인과 결과 수신 기능을 구현합니다.

8단계: Docker와 24시간 운영

PC 재부팅, 서버 오류, 데이터 유지와 원격접속을 테스트합니다.

8. 예상되는 어려움

실제 구현 과정에서는 다음 문제가 발생할 수 있다고 예상합니다.

• 에이전트 응답형식이 매번 달라지는 문제

• 한 에이전트 실패가 다음 작업에 미치는 영향

• 동일 프로젝트 중복 실행

• 서버 재시작 중 작업 상태 유지

• Telegram과 FastAPI 동시 실행

• Docker 내부와 Windows 파일 경로 차이

• SQLite 동시 접근

• 긴 보고서 생성에 따른 토큰 사용량 증가

• 근거 없는 기업정보 생성 가능성

• PC 절전모드로 서버가 중단되는 문제

따라서 단순히 한 번 작동했는지만 보는 것이 아니라 다음 항목도 기록할 계획입니다.

• 프로젝트 완료시간

• 에이전트별 실행시간

• 프로젝트당 토큰과 비용

• 실패율

• 재시도 횟수

• 사용자 개입 횟수

• 결과 수정 횟수

9. 이번 계획에서 배운 점

이번 설계를 통해 멀티에이전트 시스템의 핵심은 에이전트의 숫자가 아니라는 점을 알게 되었습니다.

여러 AI가 하나의 팀처럼 일하려면 다음 요소가 필요합니다.

• 명확한 역할

• 작업 전달 방식

• 현재 상태

• 사람의 승인

• 오류 처리

• 실행기록

• 권한 분리

• 최종 결과 검토

AI 에이전트를 여러 개 설치하는 것과, 여러 에이전트를 실제로 운영 가능한 하나의 시스템으로 만드는 것은 서로 다른 문제였습니다.

이번 과제에서는 우선 다음의 가장 작은 흐름부터 구현해볼 계획입니다.

프로젝트 요청
→ waiting 상태 저장
→ 사용자 승인
→ 기업분석 에이전트 실행
→ 결과 저장
→ completed 상태 확인

이 흐름이 안정적으로 작동하면 AX 전략 에이전트와 경영진 보고서 에이전트를 차례로 추가할 계획입니다.

LLM은 이번 계획에서 어떻게 활용했나?

이번 계획에서 LLM은 단순한 글쓰기나 코드 생성 도구가 아니라 시스템 설계를 검토하는 대화 파트너로 활용했습니다.

주요 활용 내용은 다음과 같습니다.

• 프로젝트 목적과 최소 범위 정의

• 단일 AI와 멀티에이전트 구조 비교

• 에이전트별 역할 설계

• 순차 실행과 동적 오케스트레이션 비교

• Human-in-the-loop 승인구조 검토

• 프로젝트 상태와 오류상태 정의

• SQLite와 Docker 저장구조 검토

• Telegram 명령과 대시보드 항목 설계

• 구현시간과 예상 토큰 사용량 추정

• 설계안에 대한 문제점과 반론 요청

• 단계별 구현순서 작성

다만 LLM의 제안은 아직 실제 환경에서 검증된 결과가 아닙니다.

따라서 이번 설계는 완성된 정답이 아니라, 앞으로 직접 구현하고 수정하기 위한 출발점으로 보고 있습니다.