Skip to content
02 / 07 Featured · Research Tooling · 2026

ARES를 어떻게
만들었는가.

논문 검색 UI가 아니라, 연구 자산이 단계 사이를 이동하는 시스템을 만들기 위한 개발 노트입니다. 현재 구현된 Search/Reading 경로와 아직 scaffold인 단계의 경계를 함께 기록합니다.

From ARES · research asset handoff
Researcher Search
RAG reranker 비용을 줄이는 논문을 찾고, 바로 Reading 큐로 넘겨줘.
ARES · Scout Reading handoff
후보 논문을 저장했고 PDF가 있는 항목은 Reader가 열 수 있는 세션으로 연결했습니다. 다음 단계에서는 요약, notes, assets, chat이 같은 reading session에 누적됩니다.
asset handoff
Trigger 논문 수집과 연구 실행의 단절
Approach 연구 자산 중심 6단계 워크플로우
Real paths Search · Reading · PDF pipeline
Status MVP · 2026 · Solo

기존 연구 흐름에서는 논문을 찾고, 읽고, 재현하고, 결과를 비교하고, 글을 쓰는 과정이 서로 다른 도구와 파일에 흩어졌습니다. 논문을 읽어도 곧바로 재현 계획으로 이어지기 어렵고, 재현 실패나 성능 차이는 다음 연구의 자산으로 남기 어렵습니다.

  1. 01

    Paper collection is not enough

    논문 검색 결과는 목록으로 남지만, 이후 리딩·재현·결과 비교에 필요한 문맥은 별도로 다시 구성해야 했습니다.

  2. 02

    Reading does not become action

    논문에서 찾은 방법, 한계, 실험 조건이 곧바로 reproduction checklist나 실험 계획으로 이어지지 않았습니다.

  3. 03

    Failure is hard to reuse

    재현 실패, 성능 차이, 후속 가설이 문서와 로그 사이에 흩어져 다음 연구의 시작점으로 축적되지 않았습니다.

ARES는 ARIS의 agent 실행 경험에서 출발했지만, 런타임 모델은 다르게 잡았습니다. ARES에서 agent는 대화를 이어가는 존재라기보다, 논문·리딩 세션·실험 결과·인사이트 같은 연구 자산을 다음 단계로 넘기는 역할을 맡습니다.

Figure 1. 연구 자산이 6단계 워크플로우를 통과하는 구조
Search Paper Scout Reading Session Reader Lab Run plan Research Output Insight Writing Analyst

연구 자산 중심 저장소

프로젝트별 논문 라이브러리, Reading 세션, agent run 메타데이터를 하나의 흐름 안에서 다룹니다. 검색 결과는 곧바로 읽을 수 있는 paper asset이 되고, Reading 세션은 이후 Lab과 Insight 단계의 근거가 됩니다.

ARES는 장기적으로 6단계 플랫폼이지만, 처음부터 모든 단계를 완성하려 하지 않았습니다. 현재 가장 실제적인 경로는 Search와 Reading입니다. Scout 검색, 저장된 paper worklist, PDF viewer, parse/summarize/chat/notes/assets 흐름이 이 축에 놓입니다.

S1

Search dashboard

수집된 논문, Reading 큐, PDF 유무, worklist를 한 화면에서 확인하고 다음 단계로 보냅니다.

S2

Reading library

저장된 논문을 상태별로 필터링하고, PDF가 있는 항목을 Reader workspace로 엽니다.

S3

Reader workspace

PDF, outline, notes, chat, asset tab이 같은 Reading session 안에서 함께 움직입니다.

S4

Downstream stages

Research, Result, Insight, Writing은 제품 방향과 handoff를 보여주는 scaffold로 먼저 연결했습니다.

Reading v1은 PDF URL을 가진 논문을 기준으로 동작합니다. ARES는 PDF를 열고, 텍스트 레이어를 기반으로 parse/summarize/chat 기능을 제공하지만, 이미지뿐인 scanned PDF의 OCR은 현재 범위에 넣지 않았습니다.

PDF viewer

역할 · 논문 원문을 Reading workspace 안에서 직접 열어 본문과 작업 패널을 함께 보여줍니다.

경계 · 텍스트 레이어가 없는 스캔 문서는 열 수 있어도 요약과 인용 기반 chat에는 제한이 있습니다.

Parse/Summary

역할 · PDF에서 추출 가능한 텍스트를 섹션과 요약 카드로 바꿔 이후 작업의 근거를 만듭니다.

경계 · OCR은 별도 stage로 남겨 두고, 현재는 실패 사유를 명시하는 쪽을 우선했습니다.

Chat context

역할 · Reading 중 선택한 문맥과 논문 상태를 질문에 연결합니다.

경계 · 표시된 selection과 backend prompt가 같은 텍스트를 갖는지 검증하는 것이 핵심이었습니다.

ARES 상세 페이지는 제품 비전을 보여주되, 실제 구현 상태를 과장하지 않습니다. Search와 Reading은 backend/UI 경로가 있는 실제 MVP이고, Lab 이후 단계는 연구 워크플로우의 방향과 handoff 구조를 보여주는 초기 표면입니다.

Area Status Evidence
Search Real path

논문 검색, 저장, Reading 큐, worklist와 fallback 데이터 경로가 연결되어 있습니다.

Reading Real path

PDF view, parse, summarize, chat, notes, assets가 Reading session에 묶여 있습니다.

Lab onward Scaffold

Research, Result, Insight, Writing은 현재 제품 방향과 stage handoff를 보여주는 표면입니다.

Challenges

ARES 개발에서 가장 조심한 경계.

  • ARIS를 그대로 복사하지 않기 — ARIS는 agent runtime interface지만, ARES는 research asset workflow입니다. 실행 패턴만 참고하고 세션 중심 구조를 그대로 가져오지 않았습니다.
  • 시각적 완성도와 구현 현실 분리 — 6단계 화면은 제품 방향을 보여주지만, 포트폴리오 문장에서는 Search/Reading의 실구현과 scaffold 단계를 분리해 설명합니다.
  • 외부 API 의존 낮추기 — live search가 흔들려도 seed fallback과 file store로 화면과 개발 검증이 유지되도록 했습니다.

Lessons

다음 연구 도구로 가져갈 판단.

  • 연구 도구의 중심은 산출물이다 — 좋은 agent UX보다 중요한 것은 논문, 요약, 실험 결과, 인사이트가 다시 쓰일 수 있게 남는 구조였습니다.
  • fallback은 데모용 장식이 아니다 — 연구 도구는 네트워크와 외부 API가 흔들릴 때도 최소한의 흐름을 유지해야 합니다.
  • 구현 경계를 드러내야 다음 단계가 선명해진다 — 실제 동작하는 부분과 scaffold를 구분하면, 다음 개발 우선순위도 더 정확해집니다.
Next project 모두의입법 Legislative AI summary platform