Zeron 프로젝트 에이전트 설계 딜레마와 아키텍처 진화 리포트
1. SEC 공시 자동화라는 출발점과 초기 기대
Zeron 프로젝트를 설계하면서 가장 먼저 부딪힌 핵심 과제는 방대하고 복잡한 SEC 공시 데이터를 어떻게 안정적으로 구조화할 것인가였다. 8-K, 10-K, 10-Q와 같은 공시 문서는 길고 비정형적이며, 사건의 발생 시점과 재무적 의미, 기업 활동의 맥락이 문서 곳곳에 흩어져 있다.
처음에는 LLM의 텍스트 이해 능력을 활용하면 이 문제를 비교적 단순하게 해결할 수 있을 것이라고 생각했다. 에이전트에게 SEC RSS 피드를 읽게 하고, 새로 올라온 공시를 분석하게 한 뒤, 의미 있는 이벤트를 추출하여 데이터베이스에 바로 적재하도록 만들면 전체 파이프라인을 자동화할 수 있을 것처럼 보였다.
2. 자율 에이전트 접근의 한계와 운영상 딜레마
그러나 실제 운영 환경을 고려하기 시작하면서 이러한 접근은 곧 한계를 드러냈다. 처음의 구상은 생성형 AI가 가진 능력에 대한 기대에 가까웠고, 소프트웨어 시스템으로서의 안정성, 통제 가능성, 비용 구조를 충분히 반영하지 못한 방식이었다. 에이전트에게 네트워크 접근, 공시 수집, 데이터 해석, DB 적재까지 모두 맡기면 겉으로는 자율적인 시스템처럼 보이지만, 실제로는 실패 지점이 지나치게 많아졌다.
가장 먼저 문제가 된 것은 실행 환경의 불안정성이었다. SEC 피드나 원문 수집 과정에서는 네트워크 타임아웃, API 제한, 일시적인 응답 실패가 언제든 발생할 수 있다. 데이터베이스 연결 역시 항상 안정적이라고 보장할 수 없다. 이런 I/O 영역까지 에이전트에게 맡기면, 모델은 시스템 오류와 의미 해석 오류를 구분하지 못한 채 스스로 복구를 시도하거나 불필요한 행동을 반복할 위험이 있었다. 결국 에이전트가 자율적으로 움직일수록 시스템 전체의 통제권은 오히려 약해졌다.
더 치명적인 문제는 환각이었다. 금융 데이터 처리에서는 작은 오류도 전체 시스템의 신뢰를 무너뜨릴 수 있다. 공시 원문에 날짜가 명확히 드러나지 않거나, 특정 이벤트의 해석이 애매한 경우 모델은 빈칸으로 남기기보다 그럴듯한 정보를 만들어낼 수 있다. 일반적인 요약 업무라면 어느 정도 허용될 수 있는 표현상의 유연성이지만, Zeron 프로젝트에서는 절대 허용할 수 없는 위험이었다. 공시 데이터는 “그럴듯함”이 아니라 “검증 가능성”이 핵심이기 때문이다.
비용 문제도 분명했다. 긴 공시 원문 전체를 매번 에이전트 프롬프트에 넣고, 모델이 스스로 탐색하고 판단하게 하면 토큰 사용량은 빠르게 증가한다. 특히 공시 처리량이 늘어날수록 비용은 선형이 아니라 운영상 감당하기 어려운 수준으로 커질 수 있었다. 여기에 에이전트가 불필요하게 도구를 호출하거나 주변 파일을 탐색하는 행동까지 더해지면, 비용은 물론 실행 시간과 디버깅 난이도도 함께 증가했다.
또 하나의 중요한 우려는 코드베이스의 안전성이었다. 에이전트에게 명령어 실행 권한을 부여하면 개발 편의성은 높아지지만, 동시에 레포지토리의 파일을 임의로 수정하거나 부적절한 커밋을 남길 가능성도 생긴다. 특히 Zeron처럼 데이터 파이프라인, 스키마, 추출 규칙이 긴밀하게 맞물려 있는 프로젝트에서는 작은 코드 변경도 전체 시스템의 정합성을 해칠 수 있다. 따라서 에이전트를 개발 보조자로 활용하더라도, 코드 변경과 형상 관리는 반드시 인간의 통제 안에 있어야 했다.
3. 제약된 에이전트 모듈 중심의 아키텍처 전환
이러한 시행착오를 거치며 Zeron의 아키텍처는 “자율 에이전트 중심”에서 “제약된 에이전트 모듈 중심”으로 방향을 전환하게 되었다. 핵심 판단은 명확했다. 에이전트가 잘하는 일과 시스템이 반드시 통제해야 하는 일을 분리해야 했다.
공시 수집, 파일 생성, 데이터베이스 적재와 같은 I/O 작업은 안정적인 파이썬 CLI가 담당하고, 에이전트는 준비된 Task MD 파일을 읽어 구조화된 Result JSON을 생성하는 역할로 한정했다. 다시 말해 에이전트를 전체 파이프라인의 지휘자가 아니라, 비정형 텍스트를 구조화하는 순수 함수에 가깝게 재정의한 것이다.
이 변화는 에이전트의 자율성을 줄이는 선택이었지만, 결과적으로 시스템의 안정성을 크게 높였다. 에이전트는 더 이상 네트워크 오류나 DB 커넥션 문제를 직접 처리하지 않는다. 입력은 명확히 준비된 텍스트 파일이고, 출력은 정해진 JSON 스키마이다. 실패 여부도 훨씬 분명하게 판단할 수 있다.
이렇게 I/O와 추론 로직을 분리함으로써 파이프라인은 테스트 가능하고, 재현 가능하며, 운영 가능한 구조에 가까워졌다.
4. Human-in-the-Loop와 프로토콜 기반 통제 구조
환각 문제를 줄이기 위해서는 Human-in-the-Loop 구조를 도입했다. 에이전트에게 모든 공시를 무조건 완벽하게 해석하라고 요구하지 않고, 애매한 경우에는 human_review_required: true 플래그를 올리도록 설계했다.
이는 단순한 예외 처리 장치가 아니라 금융 데이터 시스템에서 매우 중요한 안전장치다. 모델이 모르는 것을 모른다고 표시할 수 있어야 하고, 불확실한 판단은 사람이 검토할 수 있어야 한다. Zeron에서 중요한 것은 자동화율을 무작정 높이는 것이 아니라, 신뢰 가능한 자동화와 검토 가능한 예외를 구분하는 것이다.
또한 에이전트의 행동 범위를 문서와 프로토콜로 강하게 제한했다. SKILL.md에는 스킬 실행 중 git 관련 명령을 수행하지 않는다는 제약을 두고, 에이전트가 불필요한 도구 탐색이나 코드 변경을 하지 않도록 했다. AGENTS.md에는 에이전트가 따라야 할 협업 규칙과 승인 흐름을 명시했다.
에이전트는 제안할 수 있지만, 인간의 승인 없이 레포지토리를 변경하거나 원격 저장소에 반영할 수 없다. 이는 에이전트를 배제하는 것이 아니라, 안전하게 활용하기 위한 최소한의 운영 원칙이다.
5. 마법적 자동화에서 소프트웨어 엔지니어링으로
결국 Zeron 프로젝트의 설계 과정은 LLM을 “마법 같은 자동화 도구”로 바라보던 관점에서 벗어나, 하나의 소프트웨어 컴포넌트로 다루는 방향으로 진화한 과정이었다.
처음에는 에이전트에게 가능한 한 많은 권한을 주는 것이 더 강력한 시스템이라고 생각하기 쉽다. 그러나 실제 프로덕션 환경에서는 반대에 가깝다. 에이전트의 자유도를 줄이고, 입력과 출력을 제한하며, 실패 경로와 검토 경로를 명확히 설계할수록 시스템은 더 강해진다.
Zeron에서 에이전트는 더 이상 모든 것을 알아서 처리하는 자율 실행자가 아니다. 대신 공시 원문이라는 비정형 데이터를 정해진 규칙에 따라 구조화하는 전문 모듈에 가깝다. 수집과 적재는 CLI가 맡고, 해석과 추출은 에이전트가 맡으며, 애매한 판단은 사람이 검토한다. 이 구조는 겉보기에는 덜 화려하지만, 실제 운영 환경에서는 훨씬 더 현실적이고 신뢰할 수 있다.
따라서 Zeron의 현재 아키텍처는 AI의 가능성을 부정한 결과가 아니라, AI를 제대로 사용하기 위해 필요한 엔지니어링적 타협의 결과라고 볼 수 있다. 에이전트의 자율성을 의도적으로 억제하고, 명확한 제약과 프로토콜 안에 배치함으로써 오히려 프로덕션 레벨에서 사용할 수 있는 자동화 파이프라인에 가까워졌다.
이 과정은 AI 도입의 핵심이 “얼마나 많은 일을 모델에게 맡길 것인가”가 아니라, “모델이 잘하는 일을 얼마나 안전하고 재현 가능하게 시스템 안에 배치할 것인가”에 있음을 보여준다.