PDF 하나 던지면 알아서 분석하고, 정리하고, 알림까지 보내주는 시스템을 만들었다
AI 대학원 진학을 준비하면서 논문을 읽는 시간이 부쩍 늘었다. 관심 분야의 최신 연구를 따라잡으려면 일주일에 최소 5~10편은 훑어봐야 하는데, 문제는 논문을 읽는 행위의 상당 부분이 반복 작업이라는 것이다.
PDF 다운로드. Abstract 훑기. Introduction에서 contribution 찾기. Method 이해하기. Result 표 해석하기. 그리고 이걸 노션이나 구글 독스에 정리해서 스터디 전에 공유하기.
논문 한 편당 이 과정에 최소 30분에서 1시간. 일주일에 10편이면 그것만으로 하루가 통째로 날아간다. "진짜 깊이 있게 읽어야 하는 논문"에 집중하고 싶은데, 그 전단계의 반복적인 정리 작업에 에너지가 다 빠진다.
그래서 생각했다. "PDF만 넣으면 분석 결과가 Google Docs에 자동으로 올라가고, 좋은 논문이면 Discord에 알림까지 오면 얼마나 좋을까?" 이 생각에서 시작한 프로젝트다.
무엇을 만들었나
Paper Intelligence System — 논문 PDF를 업로드하면 AI가 자동으로 분석, 평가, 저장, 알림까지 처리하고, 이후 채팅으로 논문 내용을 질문할 수 있는 RAG 챗봇이다.
워크플로우 1: 논문 업로드 -> 분석 -> 저장
터미널에서
curl -X POST URL -F 'data=@paper.pdf' 한 줄이면 끝이다. 나머지는 전부 자동으로 돌아간다.- PDF가 Upstage Document Digitization을 거쳐 구조화된 HTML로 변환된다.
- Solar Pro 3 (reasoning_effort: high)가 논문을 통합 분석한다 -- 제목, 저자, contribution, 방법론, 실험 결과, 한계점, 핵심 인사이트까지 한 번에.
- 같은 모델이 분석 결과의 품질을 1~10점으로 자체 평가한다.
- 6점 이상이면 Google Docs에 보고서로 저장하고, Google Sheets에 로그를 남긴다.
- 9점 이상의 고품질 분석이면 Discord에 임베드 알림을 보낸다.
- 동시에 논문 내용을 의미 단위로 청킹하여 Upstage Embeddings로 벡터화하고, Supabase pgvector에 저장한다.
워크플로우 2: RAG 기반 논문 Q&A 챗봇
저장된 논문에 대해 채팅으로 질문하면, 벡터 유사도 검색으로 관련 컨텍스트를 찾아 Solar Pro 3가 답변을 생성한다. "이 논문의 baseline 모델이 뭐야?", "실험에서 사용한 데이터셋 크기는?" 같은 세부 질문에 정확하게 대답한다.
솔직히 처음에 이게 될까 반신반의했는데, 실제로 돌려보니 "아, 이거 진짜 되네" 하는 순간이 왔다. 그 순간의 쾌감이 이 프로젝트를 끝까지 밀어붙이게 한 원동력이었다.
기술 스택
역할 | 기술 | 설명 |
워크플로우 엔진 | n8n (셀프호스팅) | 노코드 자동화 플랫폼 |
문서 파싱 | Upstage Document Digitization | PDF -> HTML+Text 변환, OCR 자동 지원 |
LLM 분석 | Upstage Solar Pro 3 | 논문 분석, 품질 평가, RAG 답변 생성 |
벡터 임베딩 | Upstage Embeddings | embedding-passage (저장용) / embedding-query (검색용), 4096차원 |
벡터 DB | Supabase PostgreSQL + pgvector | 코사인 유사도 검색 |
문서 저장 | Google Docs + Sheets | 분석 보고서 + 이력 로그 |
알림 | Discord Webhook | 고품질 논문 발견 시 알림 |
Upstage Ambassador 2기 활동으로 받은 $300 API 크레딧 덕분에 비용 걱정 없이 다양한 실험을 해볼 수 있었다. 실제로 프로젝트를 만들면서 Document Digitization, Solar Pro 3, Embeddings 세 가지 API를 집중적으로 사용했는데, 이전에 I'MF 프로젝트에서 Document Parse와 Information Extract를 연동해본 경험이 있어서 API 구조가 익숙했다.
왜 n8n인가
잠깐 n8n에 대해 이야기하겠다. n8n은 오픈소스 노코드 자동화 플랫폼으로, 쉽게 말하면 "Zapier의 셀프호스팅 버전"이다. 하지만 Zapier와 다른 점이 있다. HTTP Request 노드 하나로 어떤 REST API든 직접 호출할 수 있고, Code 노드에서 JavaScript를 자유롭게 쓸 수 있다.
처음에는 Python 스크립트로 전체 파이프라인을 짤까 고민했다. LangChain으로 Agent를 구성하는 것도 생각해봤다. 하지만 결국 n8n을 선택한 이유는 디버깅의 투명성 때문이었다. n8n에서는 각 노드의 입력과 출력을 눈으로 직접 볼 수 있다. "Document Digitization에서 뭐가 나왔지?", "Solar Pro 3가 뭐라고 응답했지?"를 노드 하나하나 클릭해서 확인할 수 있으니, 문제가 생겼을 때 어디서 잘못됐는지 바로 찾을 수 있다.
워크플로우 상세 — 노드 하나하나 뜯어보기
1단계: PDF 파싱 — Upstage Document Digitization
논문 PDF는 단순한 텍스트 파일이 아니다. 2단 레이아웃, 수식, 표, 그림 캡션이 뒤섞여 있어서 일반 텍스트 추출로는 구조가 다 깨진다. AI_TOP_100 대회에서 입국 심사관 문제를 풀 때 PDF 파싱에 애먹었던 기억이 있어서, 이번에는 처음부터 제대로 된 파싱 도구를 쓰기로 했다.
Upstage Document Digitization은
model=document-parse 옵션으로 호출하면 문서의 논리적 구조를 이해하여 HTML과 Text 두 가지 포맷으로 출력해준다. OCR도 자동으로 처리되어 스캔 논문도 문제없다.POST <https://api.upstage.ai/v1/document-digitization> Body: document(파일), model=document-parse, output_formats=["html","text"]
여기서 한 가지 처리가 필요했다. 파싱 결과가 너무 길면 Solar Pro 3의 컨텍스트 윈도우를 초과할 수 있어서, HTML을 30,000자로 truncation하는 로직을 넣었다. 단순히 자르면 HTML 태그 중간에서 잘릴 수 있으니, 마지막
> 위치를 찾아서 깔끔하게 자르도록 했다.if (htmlContent.length > MAX_HTML_LENGTH) { htmlContent = htmlContent.substring(0, MAX_HTML_LENGTH); const lastTagClose = htmlContent.lastIndexOf('>'); if (lastTagClose > MAX_HTML_LENGTH * 0.9) { htmlContent = htmlContent.substring(0, lastTagClose + 1); } htmlContent += '\\n<!-- [TRUNCATED] -->'; }
사소한 디테일이지만, 이런 부분을 놓치면 LLM이 깨진 HTML을 파싱하면서 엉뚱한 분석 결과를 내놓는다. "가비지 인, 가비지 아웃"은 여기서도 마찬가지였다.
2단계: 논문 분석 — Solar Pro 3 (reasoning_effort: high)
이 단계가 이 워크플로우의 핵심이다. 처음에는 레퍼런스 워크플로우를 참고해서 "분석 -> 검증 -> 인사이트 생성"을 3개의 LLM 호출로 분리했었다. 그런데 Solar Pro 3의
reasoning_effort: high 옵션을 써보고 생각이 바뀌었다.
reasoning_effort 파라미터는 모델의 내부 추론 깊이를 조절하는 옵션이다. high로 설정하면 모델이 더 깊은 사고 과정을 거치는데, 이게 꽤 큰 차이를 만들어냈다. 한 번의 호출로 논문 제목, 저자, contribution, 방법론, 실험 결과, 한계점, 핵심 인사이트를 모두 구조화된 형태로 추출할 수 있었다.POST <https://api.upstage.ai/v1/chat/completions> Body: model=solar-pro3, reasoning_effort=high
3회 호출이 1회로 줄면서 API 비용과 지연 시간이 모두 크게 감소했다. LLM 성능이 올라가면 파이프라인이 단순해진다는 것을 체감한 순간이었다. 이전에 I'MF 프로젝트에서 Document Parse -> Information Extract -> Solar Pro 3 -> Groundedness Check로 4단계를 거쳤던 것과 비교하면, reasoning_effort 하나로 중간 단계를 합칠 수 있다는 점이 인상적이었다.
시스템 프롬프트에서 한국어로 분석하도록 지시하고, 섹션 구조를 명시적으로 지정했다. 논문 제목/저자, 핵심 Contribution, 방법론 요약, 주요 실험 결과, 한계점, 핵심 인사이트(기존 연구 대비 novelty, 실용적 함의, 연구 트렌드 연결점, 열린 질문들)까지 한 번에 나오도록 했다.
3단계: 품질 평가 — 자체 게이트키핑
모든 분석이 동일한 품질이 아니다. 논문 자체가 짧거나, 파싱이 불완전하거나, 분석이 피상적일 수 있다. 그래서 분석 결과를 다시 한 번 Solar Pro 3에게 평가시켰다.
이번에는
reasoning_effort: medium을 사용했다. 분석 자체보다 평가는 상대적으로 단순한 작업이기 때문에, 여기서 high를 쓰면 과잉이다. 작업 복잡도에 따라 reasoning_effort를 다르게 설정하는 것이 비용 최적화의 핵심이었다.평가 기준은 네 가지로 명확성, 포괄성, 정확성, 관련성에 대해서 각각 1부터 10점까지 세부 점수를 매기고, 종합 평점과 한국어 피드백을 JSON으로 반환하도록 했다.
{ "rating": 8, "criteria": { "clarity": 8, "comprehensiveness": 9, "accuracy": 7, "relevance": 8 }, "overall_feedback": "논문의 핵심 contribution과 방법론이 잘 정리되어 있으나..." }
JSON 파싱이 실패할 경우를 대비해서 기본값을 5점으로 설정하는 fallback 로직도 넣었다. LLM 응답에 마크다운 코드 블록이 섞여 나오는 경우가 가끔 있어서,
```json 태그를 먼저 제거하는 전처리도 추가했다.4단계: 저장 — Google Docs + Sheets + Discord
품질 6점 이상인 분석은 세 곳에 동시 저장된다.
Google Docs: "Paper Analysis: 파일명 (날짜)" 제목으로 문서가 자동 생성되고, 분석 결과와 품질 평가가 함께 기록된다. 나중에 논문 스터디 전에 이 문서만 열어보면 된다.
Google Sheets: 날짜, 파일명, 평점, 세부 점수, 토큰 사용량, 분석 요약이 한 행으로 append된다. 시간이 지나면 어떤 논문을 언제 분석했는지, 평균 품질은 어떤지 추적할 수 있다. 토큰 사용량을 기록한 것은 API 비용을 모니터링하기 위해서다. 크레딧이 무한한 게 아니니까.
Discord: 9점 이상 고품질 분석이면 Embed 형식의 알림이 발송된다. 파일명, 평점, 피드백, 분석 미리보기가 깔끔하게 정리되어 나온다. 혼자 쓸 때도 유용하지만, 스터디 그룹 채널에 연결하면 "이 논문 좋은데, 다 같이 읽어볼까?" 하는 자연스러운 공유가 가능해진다.
6점 미만은 저장하지 않고 스킵한다. 이 게이트키핑이 없으면 불필요한 노이즈가 Google Docs와 벡터 DB에 쌓인다. 처음에는 전부 저장했다가, 나중에 정리하는 게 더 귀찮다는 걸 깨닫고 추가한 로직이다.
5단계: 벡터 저장 — Embeddings + Supabase pgvector
분석과 동시에 RAG용 벡터 저장도 병렬로 진행된다. 이 부분이 워크플로우 2(Q&A 챗봇)의 기반이 된다.
원본 텍스트와 분석 결과를 의미 단위로 청킹한다. 논문의 단락 구조를 따라 500자 단위로 나누되, 1,500자 하드 리밋을 적용했다. 이 숫자가 나온 이유가 있다. Upstage Embeddings의 입력 제한이 4,000 토큰인데, 한국어와 영어가 혼합된 논문 텍스트에서는 글자 수와 토큰 수의 비율이 일정하지 않다. 한국어는 대략 1.5자/토큰, 영어는 약 4자/토큰 정도인데, 혼합 텍스트에서 안전하게 4,000 토큰 이내로 유지하려면 1,500자가 적당했다.
POST <https://api.upstage.ai/v1/embeddings> Body: model=embedding-passage, input=청크텍스트
4,096차원의 벡터가 반환되면 Supabase REST API로
paper_embeddings 테이블에 저장한다. 임베딩 API 호출은 batch size 8, 재시도 3회로 설정했고, Supabase 저장은 batch size 4에 500ms 간격으로 설정해서 DB 커넥션 부하를 분산했다. 이 설정값들은 몇 번의 시행착오를 거쳐 안정적으로 동작하는 값을 찾은 것이다.
6단계: RAG 챗봇 — 논문에게 질문하기
여기서부터가 워크플로우 2다. 저장된 논문에 대해 자연어로 질문할 수 있다.
질문이 들어오면
embedding-query 모델로 벡터화한 뒤, pgvector의 코사인 유사도 검색으로 가장 관련 있는 5개 청크를 가져온다. 여기서 중요한 것이 embedding-passage와 embedding-query의 구분이다. 저장할 때는 passage 모델을, 검색할 때는 query 모델을 사용한다. 같은 임베딩 모델처럼 보이지만 용도에 따라 최적화가 다르게 되어 있다.검색된 컨텍스트와 함께 Solar Pro 3에 RAG 프롬프트를 보낸다. 시스템 프롬프트에서 "컨텍스트에 있는 정보만 사용하여 답변하라", "컨텍스트에 없는 내용은 명시하라"는 규칙을 주었다. 할루시네이션 방지를 위한 기본적인 가드레일이다.
답변에는 참조한 컨텍스트 수와 토큰 사용량이 함께 표시되어, 답변의 근거를 투명하게 확인할 수 있다.
실제로 써보니 "이 논문에서 제안한 모델의 파라미터 수가 얼마야?", "baseline과 비교했을 때 어떤 메트릭에서 개선이 있었어?" 같은 구체적인 질문에 꽤 정확하게 답한다. 물론 논문을 직접 읽는 것을 완전히 대체할 수는 없지만, "이 논문 깊이 읽을 가치가 있는지" 판단하는 사전 스크리닝 단계로는 충분하다.
트러블슈팅 — 실제로 겪은 문제들
만들면서 겪은 여러 가지 삽질을 공유해보면,
pgvector 인덱스 2,000차원 제한
Supabase 무료 플랜에서 ivfflat과 hnsw 인덱스 모두 2,000차원 제한이 있었다. Upstage Embeddings는 4,096차원이라 인덱스 생성이 불가능했다. 이걸 알아내기까지 꽤 시간을 썼다. 에러 메시지가 직관적이지 않아서 처음에는 다른 문제인 줄 알았다.
해결 방법은 단순했다. 인덱스 없이 운용하기로 했다. 논문 수십 편 수준에서는 순차 스캔과 인덱스 스캔의 속도 차이가 체감되지 않는다. 수백, 수천 편이 쌓이면 문제가 될 수 있지만, 그때 가서 유료 플랜으로 올리거나 차원 축소를 적용하면 된다. 과잉 최적화보다는 일단 돌아가는 것이 중요했다.
Embedding 토큰 제한
앞서 청킹 부분에서 언급했지만, Upstage Embeddings의 입력당 4,000 토큰 제한 때문에 초반에 꽤 고생했다. 처음에는 1,000자 단위로 청킹했는데, 한국어가 많은 논문에서 토큰 제한을 초과하는 경우가 빈번했다. 결국 500자 청킹 + 1,500자 하드 리밋으로 줄이고, 문장 경계에서 자르도록 해서 의미 단위가 깨지지 않게 했다.
Batch 처리 안정성
임베딩 API를 연속으로 호출할 때 간헐적으로 타임아웃이 발생했다. 특히 긴 논문을 처리할 때, 청크가 30~40개씩 나오면 연속 호출이 부담이 된다.
n8n의 HTTP Request 노드에서 batch size를 8로 설정하고, 재시도 3회에 2초 대기를 추가하니 안정화되었다. Supabase 저장은 별도로 batch size 4, 500ms 간격으로 설정했다. 이 숫자들을 찾아가는 과정이 꽤 지루했지만, 한 번 잡아놓으니 이후에는 안정적으로 동작했다.
노드 구성 한눈에 보기
워크플로우 1: 논문 업로드 & 분석 (11개 노드)
Webhook (PDF 업로드) -> Upstage Document Digitization -> HTML 추출 & Truncation (30K자) -> Solar Pro 3 분석 (reasoning_effort: high) -> 분석 결과 추출 -> Solar Pro 3 품질 평가 (reasoning_effort: medium) -> 품질 평점 파싱 -> 품질 체크 (6점 이상?) |-- Yes -> Google Docs 생성 -> 업데이트 -> Sheets 로그 | -> 고품질 체크 (9점 이상?) | |-- Yes -> Discord 알림 | |-- No -> 종료 |-- No -> 스킵 -> (병렬) 청킹 -> Embeddings -> Supabase 저장
워크플로우 2: RAG Q&A 챗봇 (7개 노드)
Chat Trigger (질문 입력) -> Upstage Embeddings (embedding-query) -> pgvector 코사인 유사도 검색 (Top 5) -> RAG 컨텍스트 조합 -> Solar Pro 3 답변 생성 (reasoning_effort: high) -> 최종 답변 출력
전체 노드 수가 워크플로우 1이 11개, 워크플로우 2가 7개. 합쳐서 18개 노드로 이 정도 기능이 구현된다는 것이 n8n의 강점이다.
사용한 Upstage API 정리
API | 엔드포인트 | 용도 |
Document Digitization | /v1/document-digitization | PDF -> HTML/Text 변환 |
Solar Pro 3 | /v1/chat/completions | 논문 분석, 품질 평가, RAG 답변 |
Embeddings (passage) | /v1/embeddings | 텍스트 -> 4096D 벡터 (저장용) |
Embeddings (query) | /v1/embeddings | 질문 -> 4096D 벡터 (검색용) |
이 프로젝트에서 Upstage API를 4종류 사용했는데, 각각의 역할이 파이프라인 안에서 명확하게 분리되어 있다. Document Digitization이 입력을 정제하고, Solar Pro 3가 분석과 생성을 담당하고, Embeddings가 저장과 검색의 인터페이스가 된다. 이전에 I'MF 프로젝트에서 Document Parse -> Information Extract -> Solar Pro 3 -> Groundedness Check로 4단계 파이프라인을 만들어본 경험이 있어서, 이번에는 "어떤 단계를 합치고 어떤 단계를 분리할 것인가"를 더 의식적으로 설계할 수 있었다.
특히 Solar Pro 3의
reasoning_effort 파라미터가 인상적이었다. 같은 모델이지만 high와 medium으로 나눠서, 복잡한 논문 분석에는 깊은 추론을, 상대적으로 단순한 품질 평가에는 가벼운 추론을 적용할 수 있었다. 이건 비용 최적화 관점에서도 유의미했고, "모든 작업에 최대 성능을 쓸 필요는 없다"는 실무적 감각을 배우게 해준 포인트였다.만들면서 느낀 것들
노코드의 가능성과 한계
n8n에서 HTTP Request 노드 하나면 어떤 REST API든 연결할 수 있다. 코드를 한 줄도 안 쓰고 워크플로우를 구성할 수 있다는 점에서 진입장벽이 매우 낮았다. 하지만 실제로는 Code 노드에서 JavaScript를 꽤 많이 썼다. HTML truncation, JSON 파싱, 청킹 로직, 에러 핸들링 등은 노코드만으로는 한계가 있었다. 결국 "노코드 프레임워크 위에서 코드를 쓰는" 하이브리드 방식이 가장 현실적이었다.
"언제 LLM을 여러 번 부를까"의 판단
처음에는 분석, 검증, 인사이트를 3단계로 나눴는데, Solar Pro 3의 reasoning 능력이 충분히 강력해서 1회 호출로 통합할 수 있었다. 그런데 모든 것을 1회로 합치는 게 항상 좋은 건 아니다. 품질 평가는 분석과 분리했는데, 이건 "자기 자신의 결과물을 같은 호출에서 평가하면 객관성이 떨어질 수 있다"는 판단이었다.
LLM 호출 횟수를 줄이는 것이 항상 최적은 아니다. 비용, 지연 시간, 결과 품질, 그리고 각 단계의 독립성을 종합적으로 고려해서 결정해야 한다. 이런 판단 기준을 세우는 것 자체가 이 프로젝트에서 얻은 가장 큰 배움이었다.
벡터 DB는 DB수업을 들었다면 금방 이해할 수 있다
RAG를 처음 구현해봤는데, 생각보다 진입장벽이 낮았다. Supabase + pgvector 조합이면 별도 인프라 없이 무료로 벡터 검색을 구현할 수 있다. SQL 한 줄로 코사인 유사도 검색이 된다.
SELECT content, 1 - (embedding <=> query_vector) as similarity FROM paper_embeddings ORDER BY embedding <=> query_vector LIMIT 5
이 한 줄이 벡터 검색의 전부다. Pinecone이나 Weaviate 같은 전용 벡터 DB를 쓰지 않아도, PostgreSQL 확장만으로 충분히 실용적인 RAG 시스템을 만들 수 있었다.
파이프라인 설계는 프롬프트 엔지니어링보다 중요하다
이 프로젝트를 만들면서 가장 크게 깨달은 것은, 좋은 프롬프트보다 좋은 파이프라인 설계가 더 중요하다는 것이다. Document Digitization으로 깨끗하게 파싱된 HTML을 Solar Pro 3에 넣느냐, 깨진 텍스트를 넣느냐에 따라 분석 품질이 완전히 달라진다. 청킹을 어떤 단위로 하느냐에 따라 RAG 검색의 정확도가 달라진다. 품질 평가 기준을 어떻게 설정하느냐에 따라 저장되는 데이터의 질이 달라진다.
프롬프트는 파이프라인의 한 요소일 뿐이다. 전체 흐름을 어떻게 설계하느냐가 최종 결과를 결정한다.
향후 개선 사항
이 시스템은 아직 v1이다. 앞으로 개선하고 싶은 것들이 있다.
다중 논문 비교 분석. 현재는 논문 한 편씩 분석하는 구조인데, 여러 논문의 벡터를 교차 검색해서 "이 논문과 가장 유사한 논문은?", "이 분야의 연구 트렌드가 어떻게 변하고 있어?" 같은 질문에 답할 수 있게 만들고 싶다.
자동 스케줄링. arXiv RSS 피드를 연동하면 관심 키워드의 신규 논문을 자동으로 분석할 수 있다. 아침에 일어나면 밤사이에 올라온 논문들의 분석 결과가 이미 정리되어 있는 것이다.
Upstage Information Extract 활용. 논문의 표와 수치 데이터를 정형화해서 자동 비교하는 기능을 추가하고 싶다. 예를 들어 여러 논문의 실험 결과 표를 자동으로 통합해서 "어떤 모델이 어떤 벤치마크에서 가장 좋은 성능을 보였는가"를 한눈에 비교할 수 있으면 좋겠다. I'MF 프로젝트에서 Information Extract를 써본 경험이 있으니, 이 부분은 비교적 빠르게 구현할 수 있을 것 같다.
마무리
연구자에게 논문 읽기는 피할 수 없는 일이지만, 정리와 공유는 자동화할 수 있다.
이 프로젝트를 만들면서 가장 크게 느낀 것은, AI 도구를 "쓰는 것"과 "AI 도구를 연결해서 시스템을 설계하는 것"은 완전히 다른 차원의 작업이라는 점이다. ChatGPT에 논문을 붙여넣고 "요약해줘"라고 하는 것도 물론 유용하지만, PDF 파싱부터 분석, 평가, 저장, 검색, 답변 생성까지의 전체 흐름을 자동화 파이프라인으로 만드는 경험은 AI를 바라보는 시각 자체를 바꿔놓았다.
n8n + Upstage API 조합은 코드 한 줄 없이도 꽤 정교한 AI 파이프라인을 만들 수 있다는 것을 보여줬다. 물론 실제로는 Code 노드에서 JavaScript를 적잖게 썼지만, 핵심 로직은 API 호출과 데이터 흐름의 설계에 있었다. Solar Pro 3의 reasoning_effort 옵션은 작업 복잡도에 따라 추론 깊이를 조절할 수 있어서, 비용과 품질 사이의 균형을 잡기 좋았다.
AI 대학원에 가서 본격적으로 연구를 시작하면, 이 시스템이 논문 서베이의 첫 번째 관문 역할을 해줄 것 같다. 모든 논문을 처음부터 끝까지 꼼꼼히 읽는 것은 현실적으로 불가능하니까. AI가 1차 스크리닝을 해주고, 내가 깊이 읽을 논문을 골라서 집중하는 것. 이것이 AI 시대의 연구자가 가져야 할 워크플로우가 아닐까 생각한다.
이 프로젝트는 Upstage AI Ambassador 2기 활동의 일환으로 제작되었다.
Upstage Console: console.upstage.ai | Upstage 홈페이지: upstage.ai