프로젝트공모전

미래에셋증권 AI 페스티벌

D+162026-09-06할 일 0/2공고 링크공모전 트래커

할 일

펼치면 기간·담당자·상태를 고칠 수 있습니다

ncp에 업로드2026-09-02 ~ 2026-09-06서훈

테스트2026-09-02 ~ 2026-09-06서훈

일정

공고상의 마감·발표일

과제 제출 마감09-06D+16

파일

1건

미래에셋_AI_Festival_우승전략_보고서.pdf

프로젝트 정보

두 저장소를 모두 확인했습니다. 이제 프레임워크의 실제 구조를 파악했으니, 이를 활용해 세 주제 각각에 대한 구체적 AI Agent 설계를 제안하겠습니다.

먼저 두 저장소가 무엇인지 명확히 정리하면 다음과 같습니다. **JB_Project-Compliance-Sentinel**은 JB금융 대회 지정주제(금융 마케팅 콘텐츠 준법 심의)를 위한 **도메인 특화 완성작**입니다 — 6인 컴플라이언스 보드, 규칙+LLM 결합, RAG, HITL, audit 등이 특정 도메인에 맞춰 구현돼 있습니다. 사용자께서 "도메인을 배제한다"고 하신 게 정확한 판단인데, 이건 미래에셋 대회에 그대로 쓸 수 없고 **설계 패턴의 참고용**입니다. 반면 **AITHOR-Agent-Framework**는 도메인 중립적인 **재사용 가능한 엔진+빌더 템플릿**으로, ReAct 루프·도구·메모리·오케스트레이션(4패턴)·가드레일·오류회복 5종·관측(L3 트레이스)·평가(골든셋 게이트)·진화·안전망(HITL)을 stdlib 기반 opt-in으로 제공하고, `init-domain-pack`으로 도메인 팩을 스캐폴딩할 수 있습니다. 미래에셋 대회는 **이 프레임워크 위에 세 개의 도메인 팩을 올리는 방식**이 정석입니다.

이 프레임워크의 핵심 강점이 미래에셋 대회의 승리 조건과 정확히 맞아떨어진다는 점을 먼저 짚겠습니다. 앞서 역대 수상작에서 확인한 공통 DNA는 "신뢰받는 Agent(근거 제시)", "구체적 시나리오", "HyperCLOVA X 활용", "결과물의 가시성"이었습니다. AITHOR의 L3 트레이스·골든셋 회귀 게이트·오류회복·HITL은 그대로 "신뢰성"을 코드로 증명하는 장치이고, `MockLLMProvider`를 `HyperCLOVA X provider`로 교체하는 지점(§6, provider 비고정 설계)이 대회 필수 요건과 맞습니다. 다만 한 가지 반드시 확인할 점 — README상 프로바이더가 OpenAI/Anthropic/Gemini/OpenRouter/Mock으로 되어 있어, **HyperCLOVA X를 붙이려면 `llm_providers.py`에 CLOVA Studio API용 provider를 새로 구현**해야 합니다. 이게 세 주제 공통의 첫 번째 개발 과제입니다.

이제 세 주제별 구체적 Agent 제안입니다.

## 주제1 — 금융상품 Agent: "ETF·펀드·채권 Cross-Product Finder & Comparator"

핵심 컨셉은 단순 상품 검색 챗봇이 아니라, **모호한 자연어 니즈를 정량 조건으로 번역하고 여러 상품을 근거와 함께 비교표로 제시하는 Agent**입니다. 오케스트레이션은 AITHOR의 **Supervisor 패턴**(`team_orchestrator`)이 적합합니다. 사용자 질의를 받으면 감독자가 세 개의 하위 도구 에이전트(채권 조회, ETF/펀드 조회, 정량 비교·랭킹)로 작업을 분배하는 구조입니다.

데이터 계층은 앞서 조사한 `apis.data.go.kr/1160100/...`의 채권기본정보·펀드상품기본정보·증권상품시세정보를 각각 **ToolContract(permission="read")로 등록**합니다. 이 지점에서 AITHOR의 오류회복 5종이 결정적입니다 — 정부 API는 일 갱신·타임아웃 이슈가 있으므로 `RetryPolicy`+`CircuitBreaker`+`timeout`을 read 도구에 합성하면 안정성을 코드로 보장할 수 있습니다. Generated UI archetype은 **analytics-dashboard**를 채택해 상품 비교표·수익률/보수/듀레이션 차트를 시각화하면 "결과물 가시성" 가점을 확보합니다.

차별화·안전 포인트로는, 특정 상품 매수 권유는 투자자문 규제 리스크가 있으므로 AITHOR의 **output 가드레일(schema_guard)로 "단정적 추천" 표현을 차단**하고 "정보·비교" 프레이밍을 강제합니다. 또한 채권 데이터가 공공누리 제2유형(상업적 이용금지)임을 UI 하단 출처 표기로 노출하면 데이터 거버넌스 이해도를 보여줄 수 있습니다.

## 주제2 — 연금 Agent: "Pension Tax-Aware Advisor (상품+제도+세제 하이브리드)"

이 주제는 **정량 시뮬레이션 도구 + 세제 법령 RAG의 결합**이 승부처입니다. 오케스트레이션은 **Plan-and-Execute 패턴**(`plan_execute`)이 적합한데, "사용자 조건 파악 → 세액공제 한도 계산 → 관련 상품 조회 → 근거 법령 인용 → 종합 답변"이 비교적 예측 가능한 단계로 흐르기 때문입니다.

데이터 계층은 두 성격으로 나뉩니다. 정량 데이터는 `GetRetirementPensionInfoService`(퇴직연금기본정보, 이용허락 제한 없음+실시간이라 조건 우수)와 통합연금포털 비교공시를 tool로 붙이고, 제도·세제는 **국가법령정보센터(law.go.kr) Open API**로 소득세법 제59조의3(연금계좌세액공제)·제20조의3 등을 `rag.ingest`로 인덱싱합니다. 여기서 AITHOR가 빛나는 부분은 **세액공제 계산을 LLM이 아니라 deterministic tool로 처리**하는 설계 원칙(§12 "결정론 권위, LLM 보조")입니다 — 나이·소득·납입액을 입력받아 세액공제액을 코드로 정확히 계산하고, LLM은 그 결과를 자연어로 설명·근거 인용만 담당하게 하면 금융 계산의 환각을 원천 차단합니다.

신뢰성 장치로는, 세제 답변마다 **RAG citation(조문·연도·출처 링크)을 필수 출력**으로 강제하고, 개인 재무정보를 다루므로 입력 가드레일의 **PII 마스킹**을 활성화합니다. Generated UI는 세액공제 시뮬레이션 결과를 보여주는 대시보드형이 적합합니다.

## 주제3 — 공시 Agent: "DART Disclosure Analyst (근거-우선 검증형)"

세 주제 중 데이터 소스가 가장 성숙(DART Open API)해 개발 리스크가 낮고, "긴 문서→핵심 추출"이라는 LLM 강점이 가장 잘 발휘됩니다. 오케스트레이션은 **그래프/상태머신 패턴**(`state_graph`)이 적합합니다 — "공시 검색 → 원문/재무데이터 수집 → 분석 → 검증 → 리포트"의 흐름을 엄격히 통제하는 프로덕션형 구조가 재무 분석의 정확성에 유리하기 때문입니다.

데이터 계층은 DART의 세 계열을 모두 활용합니다. 공시검색(`/api/list.json`)으로 접수번호를 얻고, 재무정보 계열(단일회사 전체 재무제표·주요 재무지표)을 **정형 tool로 등록**해 수치를 파싱 없이 정확히 가져오며, 공시 원문 XML을 `rag`로 인덱싱해 정성 정보(사업 위험·경영 설명)를 검색합니다. 여기서 Compliance Sentinel의 설계를 참고할 만한 부분이 **verifier(검증자) 패턴**입니다 — AITHOR의 `judge`·`oracle_gate`·`evaluation.evaluate_trajectory`를 써서, Agent가 생성한 재무 분석 주장을 **원문 데이터와 대조 검증**하는 레이어를 넣으면 "신뢰받는 Agent"라는 심사 키워드에 정면으로 부합합니다.

차별화 포인트는 단순 요약을 넘어 **여러 공시 간 비교(전년 대비 변화 탐지)와 위험 신호 자동 플래깅**입니다. Generated UI archetype은 **evidence-review-dashboard**(증거 우선 검토·검증자 레일·사람 승인)가 이 주제와 정확히 맞아, 각 분석 주장 옆에 원문 근거를 붙여 보여주는 화면을 그대로 활용할 수 있습니다. 재무 수치의 오탐이 치명적일 수 있는 고위험 판단은 HITL로 라우팅합니다.

## 세 주제 공통 실행 전략과 우선순위

세 제안 모두 **동일한 AITHOR 코어를 공유하고 도메인 팩(데이터 tool + RAG corpus + UI archetype + 골든셋)만 교체**하는 구조라, 팀이 하나의 엔진에 집중 투자하면서 배정받은 주제에 맞춰 빠르게 특화할 수 있다는 게 전략적 이점입니다. 앞서 정리한 주제 배정 알고리즘과 경쟁 밀집도를 함께 고려하면, 데이터 성숙도·엔지니어링 난이도 관점에서 **주제3(공시)이 가장 안정적이고 프레임워크의 verifier/evidence 강점이 가장 잘 드러나는 선택**입니다. 반대로 RAG 정확성과 도메인 정합성에 강점이 있다면 **주제2(연금)가 계산 tool + 세제 RAG 결합으로 차별화 여지가 가장 큽니다.**

공통 개발 로드맵은 네 단계로 잡으시길 권합니다. 먼저 **HyperCLOVA X provider를 `llm_providers.py`에 구현**해 `AITHOR_LLM_PROVIDER`로 붙이는 것(대회 필수·세 주제 공통), 다음으로 배정 주제의 데이터 소스를 `ToolContract`로 등록하고 오류회복을 합성하는 것, 이어 RAG corpus 인덱싱과 golden 데이터셋 구축(제출 전 회귀 게이트), 마지막으로 Generated UI archetype 선택과 데모 시나리오 완성입니다.

한 가지 확인드릴 점은, 이 프레임워크는 provider가 HyperCLOVA X를 기본 지원하지 않으므로 CLOVA Studio API 연동이 첫 개발 관문이라는 것과, 대회 주최 측이 별도 데이터셋을 제공할 가능성이 있어(제출 양식이 부문별로 다르다고 예고됨) 설명회에서 제공 데이터 범위를 확인한 뒤 위 공개 API를 보강용으로 쓰는 게 안전하다는 점입니다.