교육생 모집글에 의하면, H-모빌리티 클래스는 로보틱스, 자율주행, 전동화, 에너지솔루션, 파워트레인에 대한 교육 기회를 제공하는 현대자동차 연구소 주관 역량 향상 프로그램이다.

빠르게 변화하는 모빌리티 미래기술을 대학생 및 대학원생들에게 전파하고 이해도를 향상시킴으로써 청년들의 취업 경쟁력 향상을 지원한다

2026 H-모빌리티 클래스 합격 후기

1. 전동화

#모터 #전력변환

2. 에너지 솔루션

#연료전지 #배터리

3. 자율주행

#인지 #판단 #제어 #통신 및 네트워크 #임베디드SW

4. 파워트레인

#엔진 #변속기 #HEV #EREV

5. 로보틱스

#소프트웨어 플랫폼 #기구학 · 역기구학 및 동작계획 #제어 및 동역학 #인지 · 센서 · 상태추정

자기소개서 작성

Q1. 신청 이유와 이를 통해 얻고자 하는 목표 (최대 500자) Q2. 자기주도적 학습을 통해 성과를 만들었던 경험 (최대 500자)

이번 2026년 모집에서 자기소개서 문항은 2개였다. 나는 5개의 트랙중에 자율주행 판단 트랙에 지원하였고, 모빌리티에 관련해서 과거에 진행했었던 프로젝트 경험과 국제학술대회 논문 게재를 위해 스스로 모르는 부분에 대해서 지속적으로 찾아보고 꾸준히 공부했었던 경험을 자소서에 잘 녹여내려고 노력했는데, 이를 좋게 평가해주셔서 운이 좋게 합격했다고 생각한다.

H-mobility class란?

H-모빌리티 클래스 기본 및 심화 교육 일정

2026년 4월 20일부터 2026년 6월 26일까지 온라인 콘텐츠 수강을 통해 기본 교육이 진행된다. 여러 기준을 통해 심화교육이 선정되고 7월 20일부터 8월 14일 중 최대 6일 동안 온라인/오프라인 심화교육이 이루어 지게 된다.

나의 단기 목표는 기본교육을 성실히 이수해서 우수한 성적을 받아 심화교육 대상자로 선정되는 것이다. 따라서 앞으로 꾸준히 온라인 교육을 수강하면서 교육 내용들을 포스팅하고 공부한 내용들을 기록해갈 예정이다. 더불어 내가 H-mobility class 앰버서더에 지원을 하게된 계기도 이 교육 프로그램에 애착과 관심을 갖고 무사히 잘 수료하고 싶은 바람이 있었기 때문이기도 하다.

기본교육 입교자들을 위한 웰컴키트도 배송될 예정이고 4월 20일부터 교육이 본격적으로 시작되어 매우 설레고 기쁘다. 평소에 자율주행 영역에 대해서 관심이 많고 궁금한 부분들이 상당히 많았는데 이번 교육 프로그램으로 인해 좋은 기회를 받게 된것 같아 한편으로는 H 모빌리티 클래스 운영자분들께 감사드린다.

이 교육 프로그램이 앞으로 나의 커리어에 있어서 특히 모빌리티 분야에 대한 첫걸음이자 훌륭한 이정표가 되어 줄 것 같다. 마지막까지 유종의 미를 거두기 위해 최선을 다해보려고 한다.

지금까지 "최적의 결정을 설계하는 자율주행 판단 전문가" 자율주행 판단 트랙 앰버서더 남서현 이였습니다!

감사합니다.

#H모빌리티클래스, #H모클앰버서더, #현대자동차, #H_mobility_class

Reference

https://h-mobility-class.com/ https://blog.naver.com/h-mobility-class https://www.hyundai-ngv.com/main/index.jsp https://www.instagram.com/h_mobility_class/

주제: 쉽게 이해하는 온톨로지 기술 실무 (그래프 모델의 선택과 온톨로지 구축 전략) 일시: 2026년 3월 11일 (수) 오후 7시 장소: GS타워 25층 (역삼역 인근) 오픈이노베이션 오픈홀

먼저, 우리는 왜 온톨로지를 구축하려고 하는것인가?

우리는 현재 저장의 시대에서 탐색, 연결, 해석, 재사용의 시대로 데이터의 주요 소비자와 환경이 변화하였다.

> 현재 우리가 겪는 가장 큰 어려움은 "데이터 양의 부족"이 아니라 여러 시스템과 문서에 흩어진 "같은 대상"을 "서로 다른 이름과 구조"로 표현하고 있는 것이 가장 큰 장애물 이라는 의미이다.

고유한 맥락과 의미구조에 대한 보장/ 검증이 되는가? 따라서 우리는 단순 검색을 넘어 개체 간 관계를 따라가며 여러 단계를거쳐 답을 도출하는 과정에서 무엇이 무엇과 연결되고, 어떤 제약과 규칙 아래에 있으며, 무엇을 근거로 실행해야 하는지를 판단해야 한다.

즉, 우리는 데이터와 지식을 묶는 공통의 언어가 필요하다.

--> 온톨로지 구축은 있으면 좋은 지식표현 기술, 단순 RDF/OWL 문서를 AI, 데이터, 통합, 자동화를 동시에 성립시키는 기반이 되며, 사람과 AI가 대상 세계를 온전하게 이해하게 만드는 확실한 방법이다.

1. 시멘틱 웹과 온톨로지

• RDF/RDFS/OWL, 지식그래프, Property Graph

Semantic Web의 개념

"의미를 이해하는 웹" 웹이 인간의 두뇌를 닮기 위해서는 정보를 단지 축적하거나 연결하는 것만이 아닌, 그 의미까지 이해하고 기계가 처리할 수 있어야 한다.

Tim Berners-Lee : WWW의 창시자로서, 인터넷 상의 하이퍼미디어를 넘어 데이터의 의미까지 기계가 이해하고 처리할 수 있는 형태로 확장한 '시멘틱 웹' 개념과 아키택처를 제안함

• 기존 웹 (Web of Documents)

  문서(Web page) 중심의 분산 네트워크, URL(Uniform Resource Locator)를 사용해 문서의 '위치'를 참조하고 하이퍼링크로 연결

• 시멘틱 웹 (Web of Data)

  데이터(Data) 차원의 분산 네트워크, URI (Uniform Resource identifier)를 사용해 데이터/엔티티 자체를 전역적으로 식별하고 연결

• 계층적 구조 (Layered Cake)

  팀 버너스 리가 제안한 웹 아키텍처로, 하위 계층은 상위 계층을 위한 기반을 제공한다. 위로 올라갈수록 데이터의 의미(Semantics)와 추론 능력이 강화된다.

RDF (Resource Description Framework)

• 웹 자원 기술의 표준, 웹상에 존재하는 자원의 속성과 관계를 기술하기 위한 W3C 표준 데이터 모델
• 트리플 (Triple) 구조: 모든 정보는 주어 (Subject) - 서술어 (Predicate) - 목적어 (Object)의 3요소 (Triple) 형태로 표현됨
• 기계 해석 가능성: 그래프 구조로 연결된 데이터는 기계가 그 의미와 맥락을 파악하고 자동으로 처리/추론 할 수 있게함

RDF의 주요 구성 요소: 자원의 식별(Identifier), 값의 표현(Literal), 데이터셋 관리(Graphs)

식별자 (Identifiers)

• URI (Uniform Resource Identifier) 웹상의 자원을 고유하게 식별하는 전역 식별자, UR의 개념을 확장하여, 문서 뿐만이 아니라 개념, 사물 등 모든 엔티티를 유일하게 지칭함, 다른 시스템에서도 동일한 대상을 식별/재사용 가능

• Compact URI (CURIE) 긴 URI를 효율적으로 표현하기 위해 Name Space(접두어)를 사용하여 축약한 형태

값과 그래프 (Values & Structure)

• Literal (리터럴) 자원의 속성 값(문자열, 숫자, 날짜 등)을 표현, 오직 Object(목적어) 위치에만 등장 가능

• Multiple Graphs 여러개의 RDF 그래프를 하나의 데이터셋으로 관리, 출처(Provenance), 접근제어, 메타데이터 관리를 위해 사용 ex) Default graph: 이름 없는 기본 그래프, Named graph: IRI로 식별되는 그래프 (Quad 구조)

RDF 표현

기계와 사람이 읽을 수 있는 다양한 표현 방식

Turtle (Terse RDF Triple language): 가장널리 사용되는 인간 친화적 포맷, 중복을 줄이고 가독성을 높인 문법 N-Triples: 가장 단순한 형태, 한줄에 하나의 트리플을 온전한 URI로 표현, 파싱이 매우 빠름 JSON-LD: JSON 기반의 Linked Data 포맷, 웹 개발자에게 친숙하면 API 응답용으로 주로 사용 RDF/XML: 초기 표준 형식, XML의 복잡성으로 인해 현재는 가독성이 좋은 Trutle 등을 선호

RDFS (RDF Schema)

어휘의 의미와 상하위 관계를 정의하는 시맨틱 웹의 분류체계

• 어휘 및 의미정의 단순 데이터 연결을 넘어, Class(개념)와 Property(속성)를 정의하여 데이터가 어떤 의미를 갖는지 기계에게 설명하는 사전역할을 함

• 분류 체계 (Taxonomy) subClassOf(하위 클래스)와 subPropertyOf(하위 속성)를 사용하여 개념 간의 계층 구조와 상속 관계를 형성

• 관계의 제약 조건 속성이 연결돌 수 있는 주어의 타입(Domain)과 목적어의 타입(Range)를 지정하여 논리적 무결성을 보장하고 추론의 근거를 제공

• RDFS 추론 메커니즘 스키마 정보 (Domain, Range, SubClass)를 기반으로 새로운 사실을 도출하는 과정

OWL

Web Ontology Language, 지식표현을 위한 상위 논리 모델링 계층

• Description Logic 기반 RDFS 위에서 동작하며, 서술논리를 기반으로 하여 사물간의 복잡하고 풍부한 관계를 명확하게 정의하고 추론(Resoning)할 수 있는 언어

• 향상된 표현력 단순 계층 구조를 넘어 집합 연산(교집합, 합집합), 카디널리티(개수 제한), 속성 특성(대칭, 전이, 역관계) 등 정교한 제약조건을 표현할 수 있음

• OWL 버전과 Profile 2004년 OWL에 이어 2009년 OWL2가 발표되었으며, 사용 목적과 연산 복잡도에 따라 EL, QL, RL 등 다양한 profile을 제공함

What is Ontology?

지식 표현을 위한 인공물로서의 온톨로지 개념

"An ontology is an explicit and formal specification of a shared conceptualization of a domain of interest" - Tom Gruber (1993)

• 철학(존재론): '존재의 본질'을 탐구하며 세상에 무엇이 존재하는가를 다룸
• 정보기술(IT): 특정 도메인의 지식 공유와 재사용을 위한 '설계된 인공물(Artifact)'
• 철학적 뿌리를 가지지만, IT에서는 기계가 처리가 가능한 명세에 초점

온톨로지의 구성요소

지식 표현을 위한 구성 요소

• 개념 (Concept): 특정 영역의 사물이나 현상에 대한 추상적 분류 (Class)
• 인스턴스: 개념에 속하는 구체적인 개별 실체 (Individual)
• 속성 (Property): 개념이 가지는 특성이나 데이터 값 (Attribute)
• 관계: 개념간의 상호작용 및 연결 구조 (Relation)
• 공리 (Axiom): 증명없이 참으로 간주되는 논리적 규칙
• 제약조건: 속성 값이나 관계에 대한 논리적 제한

Knowledge Graph

의미모델과 데이터가 결합된 지식표현구조

• 스키마와 데이터의 결합: 단순한 node와 edge의 연결이 아니라, 도메인의 개념적 정의인 스키마(Schema/Ontology)와 그 정의에 기반한 실제 데이터(Instance)가 결합된 결과물
• 의미 기반 추론 가능: 의미(Semantics)의 공유와 일관성을 보장하며, 정의된 관계와 규칙을 바탕으로 새로운 사실을 도출하는 추론(Resoning) 및 탐색이 가능
• 구성의 필수 요소: 지식그래프는 스키마(필수)와 데이터(필수)가 모두 존재해야 하며, 이는 단순한 Graph DB와 구분되는 가장 큰 특징임

Property Graph (PG)

Node와 Edge 내부에 Key-Value 속성을 저장하는 구조 중심의 모델

• Key-Value 속성 중심: 노드와 엣지 자체가 내부 속성(Property)를 가질 수 있는 구조, 엔티티와 관계에 대한 상세 데이터를 직관적으로 저장하고 그래프 순회에 유리한 모델
• 구조 및 분석 중심: 개념적 타입 (label)은 필수 요소가 아니며, 관계의 의미보다 연결 구조와 데이터 분석에 최적화된 네트워크 모델
• 표준 퀴리 언어의 부재: RDF의 SPARQL과 같은 단일 글로벌 표준이 없으며 주로 Gremlin 쿼리 언어를 사용하여 데이터를 조회함

Labeled Property Graph (LPG)

Property Graph에 명시적 Label이 추가된 모델

• PG 구현 모델 (Implementation): 추상적인 Property Graph 개념을 실제 시스템에서 사용할 수 있도록 구체화한 모델, Neo4j, TigerGraph, Azure, Cosos DB등 대부분의 상용 그래프 DB가 채택하고 있으며, 실무에서 가장 많이 사용됨
• 명시적 타입 시스템: PG와 달리, Node Label (개념 타입)과 Edge Type (관계유형)이 구조 수준에서 명시적으로 필수화되어 있음. 이를 통해 효율적인 인덱싱과 탐색이 가능
• 퀴리 언어 지원: Cypher, GQL, GSQL 등 종속성이 강한 쿼리 언어가 사용됨, 비록 공식 글로벌 표준은 아니지만, 실무에서 널리 쓰이는 사실상의 표준 (De facto) 역할을 함

RDF vs PG vs LPQ 비교분석

2. Semantic Layer

Data governance의 문제점

• 분산된 메트릭 정의: 팀별로 다른 "매출"의 정의, 불일치하는 계산로직
• 비효율적인 업무 반복: 매번 동일한 지표 추출을 위해 쿼리 새로 작성, 핵심 업무 (인사이트 도출)보다 데이터 조달에 시간 낭비

영향

• 도구 간 사일로화: BI 도구별 파편화 및 단절, 일관된 정보 소스 없음, 일관된 정보 소스 없음
• 데이터 품질 악화: 데이터 파이프라인 전체로 오류 확산, 일관된 지표 통제 불가

Semantic layer의 정의

기존 팩트 데이터는 그대로 유지하되, 그 위에 온토로지, 메타데이터, 관계 정의를 포함하는 의미 계층을 덧씌우는 것

• 특성 기존 fact data는 변경하지 않고, 위에 의미 계층을 추가 (온톨로지, 메타데이터), 여러 계층으로 구성 가능, 유기적으로 성장 (자동), 인위적으로 관리 (수동)

시맨틱 레이어는 고정된 한 계층이 아니라, 여러 계층의 집합이며 시간에 따라 성장한다.

시맨틱 레이어의 성장방식

1. 유기적 성장 (자동)

• 데이터 패턴 학습
• 고객이 자주 사는 제품 조합 발견
• 자동으로 "상품 번들" 관계 추가
• 비즈니스 규칙의 진화: 초기 매출 = 주문금액, 6개월 후: 매출 = 주문금액 - 반품

2. 인위적 관리 (수동)

• 새로운 팀 온보딩 시 계층 추가: 마케팅 메트릭 계층, 캠페인 메타데이터
• 규제 준수 계층 추가: 개인정보보호 규칙, 감사 (audit) 메타데이터
• 불필요한 계층 제거/통합

아래는 시맨틱레이어의 잘못된 설명이다.

• 시맨틱 레이어는 고정된 한 계층
• 한번 설계하면 끝
• 변하지 않는 구조
• 모든 데이터를 RDF로 변환해야함

올바른 이해는 아래와 같다.

• 시맨틱 레이어는 여러 계층의 집합이다.
• 시간에 따라 성장하고 진화한다.
• 조직의 필요에 따라 유연하게 관리 및 조정한다.
• 필요시 추가/삭제가 가능하다.

데이터 마트는 물리적 데이터 복사본이지만, 시맨틱 레이어는 추상화 계층이다. 데이터를 복제하지 않고 의미만 정의한다.

RDF가 필요한 경우 vs 불필요한 경우

RDF가 적합 (특수한 경우)

• 복잡한 의미 추론: OWL 온톨로지 자동 추론, 복잡한 관계 쿼리
• 극도로 불규칙한 스키마: 각 엔티티가 다른 속성, RDF의 유연성 필요
• 연합 데이터: 여러 조직 간 데이터 공유, 표준 온톨로지 기반 통합

RDF 피해야 할 경우

• 고주파 시계열 데이터: 0.1초 센서 데이터, 1 데이터 = 3 트리플 (오버헤드)
• ACID 필수 금융거래: RDF는 최종 일관성만 보장, 프랜잭션 무결성 불가
• 밀리초 응답 시스템: 주문 처리, 실시간 API, RDF 쿼리 지연 높음

Semantic Layer 핵심 요약

1. 기존 DB는 그대로, 위에 의미계층 추가
2. 시맨틱 레이어는 성장하고 진화하는 구조
3. 대부분의 경우 RDF/트리플 스토어 불필요
4. LLM으로 비정형 문서 구조화 가능

Acknowledgement

본 포스팅은 지그재그 세미나 4회에서 제공된 pdf 발표자료를 기반으로 작성되었다. 원본 자료와 발표자 정보가 궁금하다면, 아래 Reference에 지그재그 hompage 링크를 올려두었으니 참고하길 바란다.

Reference

https://slashpage.com/zigzag/4w67rj24gqx4jm5yq8ep https://joyhong.tistory.com https://github.com/LangChain-OpenTutorial/LangChain-OpenTutorial/blob/main/19-Cookbook/03-GraphDB/05-TitanicQASystem.ipynb SPARQL in 11 minutes (youtube) https://github.com/gazgiz

NeurIPS 란?

• 매년 12월 개최되는 세계 최대 규모이자 최고 권위의 인공지능 및 기계학습 학술대회
• 머신러닝, 신경과학 분야의 핵심 기술이 발표되며, 이곳에 논문이 채택되면 세계적인 기술력을 인정받는 것으로 간주됨
• NeurIPS 2025의 경우 21,575편 제출, 5,290편 승인
• 우수 논문의 경우 구두발표(oral) 및 spotlight
• Main conference와 workshop으로 구분

프로그램 개요

행사명: [랩 활동 공유회] 모두의 NeurIPS: 저자들과 함께하는 연구수다 접수 기간: 2026.2.9(월) 일시: 2026.2.10(화) 19:0021:30 장소: 모두의연구소 강남캠퍼스 라운지(서울 강남구 강남대로 324 역삼디오슈페리움 2층) 참가 방법: 모두의연구소 홈페이지에서 신청( https://biz.modulabs.co.kr/event/387 ) 프로그램 요약: 글로벌 탑티어 AI 학회 NeurIPS 및 AAAI 저자들의 후기를 듣고 교류하는 세미나

프로그램 세부 • Long-tailed 분포의 생성 모델 개선 연구 성과 및 NeurIPS 2025 후기 ▷ 연사 : 김민중 랩장님 (모두의연구소 <생성모델 개선연구> LAB | 국가수리과학연구소) • 아이디어에서 논문까지: 두 학회로 보는 LLM 연구 실전기 ▷ 연사 : 명지윤 랩장님 (모두의연구소 LAB | 삼성 SDS) • Q&A 및 네트워킹

중앙대학교 레인보우 시스템

중앙대학교 레인보우시스템은 대학교 소속 학생들을 위한 학생자기계발통합 관리시스템으로 진로설정, 역량개발, 취업정보, 커뮤니티 활동을 도와주는 플랫폼이다. 나는 가끔씩 비교과 프로그램이나 외부 프로그램 (직무경험 및 교육, 인턴정보 및 청년일경험) 관련해서 정보가 필요하거나, 궁금할 때 평소에 많이 해당 웹사이트를 이용하고 스스로 찾아보려고 한다.

-_ 해당 세미나 또한 후기 이벤트를 진행하긴 했으나, 현장 당일 이벤트 였기 때문에 본 포스팅과는 아무런 관련이 없다._

국제학회 구두 발표 경험이 있으나, NeurIPS, ICML, EMNLP, NAACL과 같은 AI 관련 최상위 국제학술대회를 경험해본 적은 없어서 이런 학회에 실제로 경험이 있는 사람들이 전달해주는 정보와 경험이 궁금했다. 더불어 이런 학회에 논문투고를 설사 하지 못한다 하더라도, 기본적으로 이런 학회를 마음속에 목표를 두고 연구를 해야한다는 생각을 가지고 있기 때문에, 여러방면에서 나에게 의미있는 경험이 될 것 같았다.

세미나 참석 후기

세미나 참석이 확정되어 사전 안내 메시지를 받았다. 행사 당일 조금 일찍 연구실에서 나와 중앙대 병원 앞에서 452번 버스를 타고 강남역 4번출구 앞에서 내렸다. 이날 유독 비가 많이 내렸던 것으로 기억한다. 도보로 조금 걷다보니 에슐리 퀸즈 옆 2층에 모두의 연구소 간판이 보였다.

자리에 착석해서 WIFI를 연결을 하려고 자세히 봤더니 password가 (from MODULABS import future ..ㅋㅋ)

NeurIPS 누구에게 좋은지?

이 부분은 김민중 국가수리과학연구소장님께서 말씀해주신 내용을 토대로 정리해 보려고 한다.

Tips

1. 영어발표나 포스터 내용을 거의 이해하지 못하는 수준이면, 실제로 얻어가는 것이 많지 않을 수 있음
2. 공식 프로그램과 행사 일정이 매우 빡빡해서 체력 관리가 중요함
3. 처음보는 사람들과 대화하고 교류하는 데 큰 부담이 없는 사람일수록 경험이 훨씬 더 풍부해짐
4. 전공, 관심 분야가 다른 한국 사람들과 번개 모임을 해도 기대한 만큼의 정보나 인맥 측면에서 소득이 없을 수 있음
5. 점심(lunch box) 제공, (비건, 할랄, 코서 등)
6. Social program을 참석하면 네트워킹과 무료 저녁 식사가 가능함

직장인 (연구원, 엔지니어, 데이터 사이언티스트)의 경우

1. AI, ML 등 실무에 바로 이어지는 최신 트렌드를 한번에 파악해보고 싶은 사람
2. 회사에서 ML을 쓰고 있고, "지금 우리가 하는 방법이 최선인가?"를 벤치마크하고 싶은 사람
3. 해외 이직, 커리어 전환을 고민하며, 부스-소셜에서 업계 사람들과 네트워킹, 채용 정보를 얻고 싶은 사람

AAAI의 경우, 삼성 SDS 명지운 엔지니어님께서 관련 내용을 설명해 주셨는데, 현재 삼성전자 가전제품에서 활용될 수 있는 RAG, 챗봇 서비스를 개발관련 업무를 하고 계셨다. 요즘 연구 키워드가 Agentic workflow, AI Reliability, Deployability (Enterprise Application) 크게 3개의 축으로 이루어져 있다고 말씀해주셨다.

실제로 AAAI에 게제가 확정된 논문에 대해서는, 대기업에서 진행하는 연구이다보니 현업에서 협업을하는 구조가 많이 있고 (근데 이건 꼭 대기업이라서 그런건 아닌것 같다) 실제로 다양한 부서에서의 의견을 반영한점을 연구에 적용하다보니 이것이 차별화 포인트가 되었다고 했다.

실무에서는 multi-turn 대화 맥락속에서, multi-querying, top-k를 늘리는 방법을 주로 많이 이용하고 있으며 초기에 prompting을 최대한 자세히하려고 노력한다고 말씀하셨다. fine-tuning이라고 하는것이 꼭 practical한 방법이 될 수는 없다고도 덧붙여 설명해 주셨다.

Reference

https://rainbow.cau.ac.kr/site/main/index007 https://modulabs.co.kr/?NaPm=ct%3Dmlmktp5z%7Cci%3Dcheckout%7Ctr%3Dds%7Ctrx%3Dnull%7Chk%3Dcec682c3ee701b13880ce6c3c152d35a31a427ca

Document digitization은 문서를 정보 검색이나 요약과 같은 후속 작업을 위해 텍스트, HTML, Markdown 등의 기계가 읽을 수 있는 형식으로 변환하는 과정을 의미한다.

Upstage에서 제공하는 Document digitization 기술에는 2가지가 있다.

Document parsing

문서 레이아웃 분석과 함께 텍스트를 감지하고 인식하여, 문서를 HTML 또는 Markdown과 같은 structured, LLM-readable 형식으로 변환하는 기술.

Document OCR

문서에서 text를 감지하고 인식하며, 각 text의 location 정보까지 함께 추출하는 기술.

해당 글에서는 Document parsing에 대해서 좀 더 구체적으로 다루어 보려고 한다. 해당 기술은 Multi-page documents 에서 압도적인 속도를 자랑하는데, Upstage Document Parse는 100페이지 문서를 1분 이내에 처리한다. 50–100페이지 범위의 문서를 동일한 설정으로 처리하는 경우, 경쟁 서비스인 Unstructured와 AWS Textract보다 평균 10배, LlamaParse보다 평균 4배 더 빠른 성능을 보였다.

So what exactly is Document parsing?

Document parsing은 어떤 문서든 자동으로 HTML 또는 Markdown과 같은 구조화된 텍스트로 변환하는 과정을 말한다. 이 과정에서는 문서의 문단, 표, 이미지 등 레이아웃 요소를 감지하여 문서의 구조를 파악한다. 이후 API가 읽기 순서에 따라 요소들을 직렬화하고, 최종적으로 문서를 구조화된 텍스트로 변환한다. 현재 2가지 모델을 사용할 수 있다.

Upstage Document Parse는 입력문서에서 다양한 레이아웃 카테고리를 식별하고 이를 HTML tag로 변환한다. 아래 표는 문서 내 레이아웃 카테고리와 각각에 매핑되는 HTML tag를 설명한다. 만약 특정 레이아웃 카테고리에 적절한 tag가 존재하지 않으면, 모델이 감지한 레이아웃 유형을 설명하기 위해 "p" tag에 data-category 속성을 추가하여 표현한다.

문서 안의 차트에는 유용한 정보가 포함되어 있지만, 일반적으로 이미지로만 파싱되기 때문에 검색, QA, RAG 같은 작업에서 활용하기 어렵다. 차트에서 수치 데이터를 추출해 table로 변환하면 기존의 텍스트 기반 파이프라인과 자연스럽게 통합되며, 차트 정보를 효과적으로 활용할 수 있다.

멀티모달 LLM을 사용해 이 문제를 해결할 수도 있지만, 비용이 더 높고 파이프라인이 복잡해지는 단점이 있다. 반면 Upstage Document parse의 경우 텍스트 기반 LLM과 호환되는 방식이 더 효율적이다. 차트 인식 기능은 아래에 제시된 차트 유형들을 감지하고 표 형식으로 변환한다.

다음과 같이 여러 페이지에 걸쳐 존재하지만 동일한 구조를 가진 표를 자동으로 감지하고 병합하는 기능 또한 제공한다. 이 기능을 활성화하려면 요청 시 merge_multipage_tables=true parameter를 설정하면 된다. 표가 병합되면, 연결된 표들 중 첫 번째 표 요소에 전체 내용이 통합되고, 이후 병합된 다른 표 요소들은 병합 결과가 반영된 상태로 업데이트된다.긴 데이터 표가 page 구분으로 인해 여러 페이지에 걸쳐 나뉘어 있을 때, page 경계를 넘더라도 데이터의 연속성을 유지해야 할 때 특히 유용하다.

Upstage console "playground"기능을 활용해서 Document parsing 기능을 사용해보겠다.

우측의 "Configuration" 설정 창에서 document-parse-250618, document-parse-nightly 모델 2가지 중에서 하나를 선택해서 사용하면 된다. Document parse의 경우 2가지 mode가 있는데, "Standard", "Enhanced" 둘 중 하나를 선택할 수 있다. 구조가 명확하고 정돈되어 있는 문서는 "Standard" 모드를 선택하면 되고, 만약 레이아웃이 복잡하거나 scan quality가 낮은 문서의 경우에는 "Enhanced" 모드를 선택하면 된다. 다만, 최근에 출시된 "Enhanced" mode 같은 경우에는 document-parse-nightly 모델을 선택해야지만 사용가능하다. 상세하게 옵션을 살펴보면, 위에서 언급했던, "Merge Multipage Tables" 기능도 활성화하여 사용할 수 있는 모습을 볼 수 있다.

Reference

https://console.upstage.ai/docs/capabilities/digitize https://console.upstage.ai/docs/capabilities/digitize/document-parsing https://console.upstage.ai/api/document-digitization/document-parsing https://developers.llamaindex.ai/python/cloud/llamaparse/ https://console.upstage.ai/playground/document-parsing https://www.upstage.ai/blog/en/let-llms-read-your-documents-with-speed-and-accuracy https://www.upstage.ai/blog/en/difference-of-ie-and-dp https://docs.reducto.ai/parsing/configs/enrich-configuration

Document classification 기술을 설명하기 전에 먼저 핵심적으로 알아야할 2가지 기술을 이해하기 쉬운 예시를 들어 설명하겠다.

고객사에서 아래와 같은 요청이 있다고 가정해보자.

1. “이 계약서에서 계약 금액을 추출해줘.”
2. “이 계약서에서 위약금 조항을 찾아서 설명해줘.”

두 요청 모두 문서를 처리한다는 점에서는 동일하지만, 필요한 기술은 근본적으로 다르다. 서로 다른 팀 / 부서마다 발생하는 문제와 필요한 요구사항이 다르기 때문에 각각 상황에 부합하는 해결방안을 제시하는 것이 매우 중요하다.

첫 번째 요구사항에서 활용할 수 있는 기술: Information Extraction, 두 번째 요구사항에서 사용할 수 있는 기술: Document Understanding (Parse)

Document Parse는 Document를 HTML이나 Markdown과 같은 LLM이 읽을 수 있는 형식으로 변환하는 기술이고, Information Extract는 필요한 데이터만을 structured JSON 형태의 key–value 쌍으로 추출하는 기술이다.

여기서 "Structured outputs"의 장점을 부연 설명하자면, 이는 사용자가 제공한 JSON schema를 기반으로 JSON 형식의 결과를 생성하여 정보를 표준화된 방식으로 추출·정리할 수 있게 해주는 기능이다. 이를 통해 추출된 데이터는 기계가 읽기 쉽고, 다양한 애플리케이션과 시스템에 유연하게 연동할 수 있다.

아래 캡쳐 사진은 Upstage official tech-blog "Document parse vs Information extract: What's the difference?"을 주제로 작성된 포스팅 내용에서 참고한 비교분석 표이다.

Document Classification이란?

문서 분류는 입력된 문서를 사용자가 정의한 category 중 하나로 자동 분류하는 기술이다. 스캔된 이미지, 사진, digital PDF 등 형태에 관계없이 적용할 수 있으며, 템플릿이나 모델 fine-tuning없이 사용할 수 있다.

Advantages

• 어떤 문서든 처리 가능: 스캔본, 사진, 디지털 문서 등 형식에 상관없이 높은 인식 성능 제공
• 유연한 분류 체계: 도메인에 맞게 라벨을 자유롭게 정의하고 수정 가능
• no fine-tuning: 템플릿이나 학습 과정 없이 즉시 배포 가능 운영 비용 절감
• 일관된 운영: 문서 라우팅 및 자동화 분기 처리에 바로 적용 가능

Upstage model들은 playground에서 직접 사용해 볼 수 있다. Document classification기능을 체험해보기 위해 "Upstage Playground"에서 sample 자료들을 가지고 이 기술이 어떻게 활용될 수 있는지 실습해보겠다. Upstage console에서 samples (US Tax & Income & Logistics) 문서들을 다운로드 받고 하단 우측의 "Classify all" 버튼을 클릭한다. 대용량의 문서를 업로드 한게 아니여서 짧은시간 안에 process가 마무리 되었다.

우측 Class description을 확인해보면 "label"(category)과 그에 해당하는 "description"이 matching되어 분류가 잘 된 모습을 확인할 수 있다. 해당 기술은 앞서 설명한 예시 이외에도 다양한 산업분야에 적용 가능하고 업무의 효율성을 극대화 할 수 있는 매우 우수한 솔루션이라고 생각한다.

Reference

https://console.upstage.ai/docs/capabilities/classify https://console.upstage.ai/api/document-classification https://www.upstage.ai/blog/en/difference-of-ie-and-dp https://console.upstage.ai/docs/capabilities/generate/structured-outputs https://json-schema.org/overview/what-is-jsonschema https://www.upstage.ai/

Information extraction은 어떤 종류의 문서라도 핵심 정보를 추출할 수 있는 기술을 의미한다. 기존의 사전 구축형 정보 추출(prebuilt IE)은 특정 문서 유형에 맞춰 fine-tuning을 해야 하지만, Universal IE는 추가적인 학습이나 customizing process없이 아무 문서나 바로 처리하고 필요한 정보를 추출할 수 있다.

Schema

정보추출을 위한 스키마를 얻는 방법에는 2가지가 있다.

1. Automatic schema generation
2. Manual schema design

Automatic schema generation

스키마를 수동으로 직접 설계하는 일은 번거롭다. 반면, Schema Generation API를 사용하면 최대 3개의 샘플 파일만으로 초기 스키마를 손쉽게 생성할 수 있다.

추출된 스키마는 문자열 형태의 JSON 객체로 메시지 내용에 반환된다. 이 스키마는 Information Extract API의 JSON Schema 문법 및 입력 스키마 규칙을 따른다. 또한 사용자는 system message를 통해 스키마 생성에 대한 의도를 API에 전달할 수 있다.

Manual schema design

Schema는 JSON schema syntax에 따라 작성되어야 하고 사용가능한 type은 아래와 같다. type에는 총 6개의 종류가 존재하며, string, number, integer, boolean, array, object가 있다.

여기서 주의해야할 점은 root object는 반드시 object type 이어야 한다는 것이다.

{
  "type": "object",
  "properties": {
    "transactions": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "transaction_date": {
            "type": "string",
            "description": "Date on which each transaction occurred."
          },
          "transaction_description": {
            "type": "string",
            "description": "Description of each transaction."
          }
        }
      }
    }
  }
}

Arrays

같은 key에 대해 여러 값을 추출해야 한다면, array type을 사용할 수 있다. {"type": "array"} 형태로 작성할 때에는, 배열 내부값의 구조를 정의하기 위해 "items" keyword를 반드시 포함해야한다.

Objects

하나의 key 아래에 여러 properties를 정의하려면 object type을 사용한다. {"type": "object"}로 선언한 후, 구조를 정의하기 위해서 "properties" keyword가 이어져야 한다. 더불어, object type은 array의 items로도 사용될 수 있어, table처럼 여러 row를 표현할 때 활용된다.

Schema design restrictions

직접 스키마를 설계할 때는 다음과 같은 제약사항들이 존재한다.

스키마 내 모든 property 이름과 definition 이름의 총 문자열 길이는 10,000자를 초과할 수 없다.

• 동기(synchronous) API: 최대 100개의 object property / 최대 15,000자까지 허용

• 비동기(asynchronous) API: 최대 5,000개의 object property / 최대 120,000자까지 허용

{
  "type": "object",
  "properties": {
    "bank_name": {
      "type": "object",  # ❌ Object type properties are not allowed in the first-level
      "properties": {
          ...
      }
    }
  }
}

first-level property는 반드시 다음 타입 중 하나여야 한다. string, integer, number, array (object 타입은 최상위 레벨에 허용되지 않는다.)

{
  "type": "object",
  "properties": {
    "bank": {
      "type": "array",
      "items": { "type": "array", "items": {...}}  # ❌ Nested arrays are not allowed
    }
  }
}

좀 더 쉬운 이해를 위해 아래 표를 참고하여 동기 API와 비동기 API의 차이점을 설명하도록 하겠다.

Synchronous API

요청이 발생하면, 처리가 완료될때까지 기다리고 즉시 결과를 반환한다. 동기 API는 작은 문서 처리, 간단한 스키마, 빠른 응답이 필요한 경우에 적합하다. 제한사항으로는 동기 API가 문자수와 property 수 제한에 더 엄격하다는 것이다. 동기 API는 결과를 받을때까지 연결을 유지해야한다.

Asynchronous API

요청이 발생하면, 즉시 task ID를 반환하고 나중에 별도 요청으로 결과를 조회한다. 비동기 API는 대용량의 문서, 복잡한 스키마, 여러문서를 한번에 처리하는 batch 작업에 적합하며 긴 처리시간이 예상되는 경우에 적절하다. 비동기 API는 더 넓은 범위(최대 5,000 properties, 120,000 chars)를 지원한다. 비동기 API는 연결을 유지할 필요없기 때문에 네트워크 risk 감소효과가 있다.

Advantages of using Asynchronous API?

비동기 API는 다음과 같은 장점이 있다.

1. 대용량 문서와 복잡한 스키마를 장시간 연결을 유지하지 않고도 처리가 가능하다.
2. 하나의 요청에 여러 문서를 batching하여 대량으로 처리 가능하다.
3. 대규모 문서처리 workflow에서 resources 사용 최적화가 가능하다.

간단하게 정리하자면, 비동기 API를 사용함으로써 오래 걸리는 작업이나 대규모 문서처리가 효율적이게 된다. 반대로, 단일 문서를 빠르게 처리해야하고 즉시 결과물이 필요한 경우에는 비동기 API 대신 동기 API를 사용하는 것이 좋다.

Additional parameters

비동기 API는 동기 API와 동일하게 데이터 추출 능력을 강화하기 위해 다양한 추가 파라미터를 지원한다.

1. Mode: standard와 Enhanced 중 선택 가능
2. doc_split: 하나의 파일안에 여러 문서가 포함되어 있을 경우, 이를 자동으로 분할해 각각의 문서에서 정보를 추출하는 기능
3. location: 추출된 각 field에 대해 page number, bounding box 좌표(x,y) 등의 위치 정보를 함께 제공하도록 설정
4. Confidence: 각 추출 field에 대해 high / low 형태의 confidence score를 포함하여 결과의 신뢰성을 평가할 수 있게 하는 option

data = {
    "model": "information-extract",
    "schema": json.dumps(schema),
    "mode": "enhanced",  # Use enhanced mode
    "location": True,  # Get location coordinates
    "confidence": True  # Get confidence scores
}

response = requests.post(
    f"{BASE_URL}/async",
    headers=headers,
    files=files,
    data=data
)

Basic Async job workflow

import requests
import time
import json

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.upstage.ai/v1/information-extraction"

#Step 1: Create async job
headers = {"Authorization": f"Bearer {API_KEY}"}
files = {
    "documents": [
        ("documents", open("document1.pdf", "rb")),
        ("documents", open("document2.pdf", "rb"))
    ]
}
data = {
    "model": "information-extract",
    "schema": json.dumps({
        "type": "object",
        "properties": {
            "bank_name": {
                "type": "string",
                "description": "The name of bank in bank statement"
            }
        }
    })
}

response = requests.post(f"{BASE_URL}/async", headers=headers, files=files, data=data)
job_data = response.json()
job_id = job_data["job_id"]
print(f"Job created: {job_id}")

#Step 2: Poll job status
while True:
    response = requests.get(f"{BASE_URL}/jobs/{job_id}", headers=headers)
    job_info = response.json()
    status = job_info["status"]
    print(f"Job status: {status}")

    if status in ["COMPLETED", "FAILED", "CANCELED"]:
        break

    time.sleep(5)  # Wait 5 seconds before checking again

#Step 3: Retrieve results
if status == "COMPLETED":
    response = requests.get(
        f"{BASE_URL}/jobs/{job_id}?with_result=true",
        headers=headers
    )
    results = response.json()
    print(json.dumps(results, indent=2))

Upstage Information extract?

• 어떤 문서 타입도 처리 가능 복잡한 PDF, 스캔 이미지, Microsoft Office 문서 등 다양한 형식의 문서를 안정적으로 처리하여 데이터를 추출할 수 있다.
• 스키마에 구애받지 않는 처리(schema-agnostic) 주어진 schema에 따라 동적으로 구조화된 출력을 생성할 수 있어, 다양한 사용 사례에 맞춰 즉석에서 customizing이 가능하다.
• 숨겨진 정보까지 추출 문서에 명시적으로 적혀 있지 않은 정보도 추론하여 추출할 수 있다. 예를 들어, 여러 라인 아이템을 기반으로 total amount을 계산하거나, 문서에 직접적으로 라벨링되지 않은 핵심 정보를 찾아낼 수 있다.
• 추가 학습 불필요 사전에 만들어진 템플릿이나 모델 재학습 없이도 문서에서 필요한 정보를 바로 추출할 수 있다.

Reference

https://www.upstage.ai https://console.upstage.ai/docs/capabilities/extract/writing-a-schema https://console.upstage.ai/docs/capabilities/extract/universal-extraction-async

과학적 글쓰기의 5가지 핵심 원칙

1. 독자를 고려할 것
2. KISS: Keep it short and simple
3. Story 중심으로 글을 이끌어갈 것
4. 독자의 읽기 패턴을 고려할 것
5. Title과 Abstract으로 글의 강점을 살릴 것

가장 중요한 질문

"내 글을 읽는 독자는 누구인가?"

• 어디에 쓸것인가?
• 무엇을, 어떻게 쓸 것인가?
• 어떻게 스토리를 구성하고 관심을 유도할 것인가?

독자가 원하는 것 = 당신이 원하는 것

여기서 핵심 포인트는 "Keep it short & simple" 개념이다. 간단한 단어와 구문을 사용하고 간단한 문장구조 (능동태)를 사용해야 한다.

과학적 글쓰기에서의 스토리텔링

1. 전하고자 하는 이야기의 핵심은 무엇인가?
2. 스토리라인이 명확하고 완성도 있는가?
3. 이 이야기가 과거에도 전달된 적이 있는가?

잘 구성된 스토리의 특성

1. 명확한 줄거리와 메시지 (핵심 메시지, 목적의식)
2. 내용에 알맞은 적절한 길이 (과장 없는 내용, 실질적인 내용 중심)
3. 흐름과 방향성 (우연이나 억지 설정 없는 흐름, 불완전함 또는 한계를 솔직히 표현, 일부 불완전함에도 논리적 일관성/흐름 유지)
4. 결론에 이르는 듯 하다가...
5. 후속 논의나 탐구를 위한 여지를 남김 (독자의 공감, 후속 연구 가능성 시사)

제목 최적화

• 논문 제목 최적화가 중요하다.

• 좋은 제목이 모든 것을 좌우한다.

• 인용자의 20%만이 논문 원문을 읽기 때문이다. "Read before you cite". Complex systems 14 (2003) 269-274

• 독자들은 검색엔진/AI를 통해 논문을 검색한다. Google은 논문 제목의 40-60자 / 요약문의 약 160자만 보여준다.

• 최근에는 AI를 통해 keyword 중심으로 논문을 검색하며, 유명 학술지를 구독해서 간행물 전체를 읽는 사람은 많지 않다.

초록 최적화

초록의 기능: 독자가 본문을 빠르고 정확하게 파악하도록 돕는다. 따라서 간단하고, 완전하며, 핵심을 잘 전달해야 한다. 이는 논문이 읽힐지를 결정짓는 주요요소이다. 독자가 가장 먼저 읽은 부분 중 하나이다. 심사자에게 전달되는 정보는 제목과 초록 뿐이다.

여기까지는 오유진 박사님의 강의 내용이였고 논문을 투고하고 Linkedin을 통해 게재한 논문을 홍보하는 것이 필요하다고 말씀해 주셨다.

아래 첨부한 사진은 "중앙대학교 AI대학원 핵심기술 세미나"의 일환으로 진행 되었던 안수남 대표님의 좋은 논문을 작성하기 위해서 알아야할 내용이다.

해당 세미나에서 중요하게 말씀하셨던 부분은 Gemini와 Chat GPT가 AI쪽으로는 사전학습이 잘 되어 있기 때문에 활용하면 굉장히 유용하다는 것과 좋은 논문을 쓰기 위해서는 어쩔 수 없이 지속적으로 논문들을 많이 읽어봐야한다는 것이다.

Acknowledgment

본 포스팅은 중앙대학교 학술정보원과 WILEY의 "효과적인 해외 학술지 투고 전략"을 주제로한 오유진 박사님의 강의 내용과 AI대학원 CAU-AI 핵심기술 세미나 "AI 기반으로 좋은 논문을 작성하는 방법"을 주제로한 안수남 대표님의 강의 내용에 기반하여 작성되었다.

Reference

Yujin Oh - Google scholar https://onlinelibrary.wiley.com/ Wiley Education - Certificate 중앙대학교 학술정보원 - homepage 안수남 대표 - Linkedin https://www.murfy.ai/

keynote: 2025년 11월 6일 (목), Seoul Coex

1. 검색을 넘어 실행까지 사용자 경험의 진화
2. 도구를 넘어 파트너로 비즈니스 에이전트의 시작
3. 입체적 경험이 가능한 컨텐츠 플랫폼
4. AI, 모두를 위한 도전

네이버는 내년부터 순차적으로 선보인 AI 에이전트를 통해 기업의 정체성을 전면 개편한다. '검색 중심의 플랫폼'에서 벗어나 사용자의 의도를 이해하고 직접 행동을 수행하는 AI 에이전트 플랫폼으로 진화하겠다는 구상이다. 에이전트 N은 온서비스 AI를 통해 축적된 Vertical AI역량을 고도화해 사용자의 맥락을 이해하고 다음 행동을 예측 및 제안하며 실행까지 이어지는 구조롤 만들어졌다.

Agent N

네이버는 검색부터 실행까지 아우르는 사용자 맟춤형 통합 에이전트 Agent N을 구현한다. 모든 서비스가 유기적으로 연결되는 경험을 제공하고, 사용자의 탐색 과정 속에서 필요한 행동을 제안하는 실행성이 특징이다. 에이전트 N은 네이버의 서비스와 컨텐츠, 데이터를 하나로 통합한 사용자 개개인을 위한 맞춤형 통합 에이전트이다. 내년부터 검색, 쇼핑에 AI agent를 본격으로 도입해 사용자 이해를 바탕으로 행동에 더욱 적극적으로 개입하는 통합 대리인 Agent N을 통해 서비스 경험을 혁신할 계획이다.

2000년대 후반 모바일의 전환기에 local, 개인화, 인포테인먼트 영역에서 사용자 중심의 서비스를 선보였던 네이버는 이번 행사를 통해 AI 대전환의 흐름 속에서 전 서비스의 '에이전트화'를 추진한다. 이번 키노트세션에서는 네이버가 AI기술로 사용자의 관심과 행동 흐름을 학습해 자연스러운 연결을 실현하는데에 주력하였고, 에이전트 N은 그간 네이버가 On-service AI로 만들어낸 경험을 바탕으로 네이버의 모든 서비스와 컨텐츠를 결합한 통합 에이전트라고 설명했다.

검색을 넘어 실행까지: 사용자 경험의 진화

에이전트 N은 네이버의 모든 서비스가 '하나의 서비스'처럼 유기적으로 연결되는 '심리스한 경험'을 구현한다. 사용자가 직접 명령을 입력하지 않아도 지도, 캘린더, 예약, 컨텐츠 등 네이버의 다양한 서비스가 사용자의 탐색과정속에 자연스럽게 녹아 들어 필요할 때 제안하고 실행한다. 또한 데이터의 결합이 정교한 '초개인화'를 가능하게 한다. 네이버는 초거대 언어모델 기술을 활용해 다양한 서비스 로그를 통합 분석, 사용자의 행동을 예측하고 이에 맞는 제안을 수행한다. 사용자의 관심사와 패턴을 종합적으로 이해해 '페르소나'를 구축하고 여기에 기반해 가장 적합한 정보와 엑션을 제시하는 방법이다.

따라서 단순한 추천이나 제안을 넘어 실제 행동까지 연결할 수 있는 실행형 에이전트를 지향한다는 것이다. 에이전트 N은 부동산, 캘린더, 블로그, 카페, 네이버플러스스토어 등 네이버 생태계 내 이용자 행동 데이터를 기반으로 한다. 내년여름 출시예정인 신규 서비스 AI 탭의 예를 들어보겠다.

AI탭에서 '초보자 러닝코스'를 입력하면 플레이스, 카페, 블로그 데이터를 기반으로 관련 코스와 후기 정보를 보여주고, 러닝 인플루언서를 구독하거나 체온 유지에 좋은 윈드브레기커 등 개인화된 상품을 탐색, 구매할 수 있다.

이때, 구매과정에는 '쇼핑 에이전트'가 연동된다.

AI agent의 경쟁력의 핵심은 신뢰성 있는 데이터로, 네이버는 이를 위해서 '메타데이터'를 활용해 에이전트가 참조하고 이용하는 데이터의 신뢰성을 확보하겠다는 계획이다. 메타데이터의 정의는 데이터의 생산,유통,소비과정에서 생성되는 데이터를 설명하는 데이터로 단순히 크롤링만으로는 얻기 쉽지 않다. 이를 통해서 AI가 참고하는 컨텐츠가 실제 사용자의 경험기반인지, 혹은 자동 생성된 데이터인지를 판별가능하다.

B2B 분야에서는 풀스택 AI역량을 기반으로 반도체,조선,방산, 바이오 등 한국을 이끄는 산업들의 AX를 주도한다. 기반이 될 인프라 구축을 위해 내년 중 GPU에만 1조원 이상을 투자한다. 이를 통해 대한민국을 AI 3대 강국으로 도약시키는데 최선을 다하겠다는 방침이다. Physical AI를 구현하기 위해 국내 최대, 최고수준의 인프라를 목표로 AI 생태계 경쟁력을 위한 데이터센터와 컴퓨팅 투자를 적극적으로 확대한다. 네이버 사옥 1784와 각 세종 데이터센터를 연결하는 physical AI의 테스트 베드가 본격적으로 운영된다. 네이버 클라우드는 이같은 기술과 인프라를 기반으로 산업 특화 AI 생태계를 확장해나간다. 조선, 에너지, 바이오 등 주요 산업기업과 협력해 AI기반 공정 운영, 설비관리, 품질 예측 등 제조 전과정에서의 AI활용을 지원한다. 또한 산업 현장에 최적화된 기술이 빠르게 자리잡을 수 있도록 지원을 해나갈 예정이다. 피지컬 AI의 하드웨어 부분 중 하나인 로봇 가운데 MIT와 협력해서 개발하고 있는 소형 휴머노이드 로봇 '미니노이드'또한 공개되었다. 아래 사진속 네이버의 로봇 클라우드 '아크'와 웹기반 로봇 운영체제(OS) '아크 마인드'를 통해서 구동이 된다. 로봇 OS 및 제어 플랫폼또한 최고 수준의 역량을 가지고 신성장 동력을 확보할 수 있을 것이라고 자신했다.

도구를 넘어 파트너로: 비즈니스 에이전트의 시작

더불어 에이전트 N을 개인부터 기업까지 아우르도록 확장할 계획으로 내년 비즈니스 통합 에이전트 '에이전트 B for 비즈니스'를 선보일 예정인데, 쇼핑, 광고, 플레이스 등 전 사업자를 위한 AI 솔루션으로 사업자가 AI로 사업환경과 현황, 개선사항을 분석하는 형태이다. 네이버는 실구매자, 실예약자만 작성 가능한 리뷰, POS 시스템과 연동된 실시간 예약 현황, 판매자와 직접 연결된 재고 정보 등 신뢰성 높은 데이터를 확보하고 있다. 해당 서비스는 쇼핑, 광고, 플레이스 등 모든 사업자들을 위한 AI solution으로 그동안 분산되어 있던 사업자 솔루션과 데이터를 하나의 비즈니스 허브로 통합해 사업자가 AI를 기반으로 비즈니스환경을 분석하고 상황을 진단, 개선하는데 도움을 준다는게 회사의 설명이다.

Reference

https://dan.naver.com/25 https://zdnet.co.kr/view/?no=20251106093818 https://zdnet.co.kr/view/?no=20251106152756 https://n.news.naver.com/article/092/0002397366?cds=news_my_20s https://n.news.naver.com/article/018/0006158033?cds=news_my_20s https://n.news.naver.com/article/031/0000978689?cds=news_my_20s https://n.news.naver.com/article/119/0003021857?cds=news_my_20s

홈페이지에 접속에서 상단 메뉴 중 "Products"를 클릭하면 Generative intelligence, Document intelligence, Intelligence spaces 세가지가 있는데 이중에서 AI Space는 The command center for teams buried in paperwork라고 부연설명되어 있다.

Upstage AI Space

Upstage AI space에서는 다음과 같은 기능들을 제공한다. 내가 직접 활용해본 예시는 아래에 첨부하도록 하겠다.

먼저 아래 캡쳐화면을 보면, 상단 왼쪽의 new project의 경우 다양한 경로를 통해 문서를 받아올 수 있다. local 환경에 저장되어 있는 파일, 혹은 google drive, gmail을 연동하거나 외부 URL link를 통해서 데이터를 불러오는 것이 AI Space에서 가능하다.

나의 경우, 구글 드라이브에 저장되어 있던 논문을 불러와 봤는데, 일단 해당 기능을 사용하기 위해 클릭하면, 위에 캡쳐 사진처럼, Link google drive account라는 창이 뜨게 되고 이후 Connect 버튼을 누르면, 내 구글 계정에 저장되어 있는 파일들을 AI Space에 불러오는 것이 가능해진다.

What you can do

그렇다면 AI Space를 활용하면 어떠한 기능들을 구체적으로 사용해 볼 수 있을까? Upstage homepage에 나와있는 공식 설명은 아래와 같다.

Document Chat: Ask natural-language questions and get accurate, source cited answers Information Extraction: Pull structured data from invoices, forms and reports using plain language Summarization: Generate clear overviews from long or complex documents Compliance Check: Validate that each document meets required formats and content rules-flag non-compliant sections with citations Document Comparison: Identify version changes across policies, contracts, Invoices, and clinical guidelines

Usability

Upstage AI space는 위에 "Built for your industry"를 확인해 보면 알 수 있듯이, 보험, 금융, 제조업 등 여러 비즈니스 환경에서 활용 가능한 서비스이며 위와 같은 기능들을 제공한다. 더불어 업로드 되는 모든 문서, 채팅 내용, 도출된 결과물들은 HIPAA, ISO 27001, SOC 2의 철저한 enterprise-grade 보안 인증에 의해 개인정보가 보호된다.

나는 6개의 파일들을 업로드 해보았고, Solar Pro 2 model에게 해당 문서에 관해 simple Question & Answering task를 진행해 보았다. 위에서 언급한 바와 같이, Upstage AI space는 자연어로 질의를 하면 거기에 맞는 근거를 제공한다. 왼쪽 문서에 보라색으로 해당 영역에 표시가 되기 때문에 내가 필요한 특정 부분에 정보를 쉽고 빠르게 찾을 수 있다. 또한 상단에 HTML 버튼을 클릭하면, Document structure를 HTML format으로 변환하는 기능도 제공한다. 더불어, Solar chat 하단에는 information extraction 기능도 제공하는데, 이를 활용하기 위해서는 우선적으로 해당 문서에 대한 schema가 필요하다.

Advantages of using Upstage information extract

Information extraction의 "set schema" 부분에 대해서는 "Upstage official tech blog"의 글을 참고하여 구체적으로 설명해보도록 하겠다.

예를 들어, 보험 업계의 경우 지난 분기까지만 해도 보험 서류에 47개 항목이 있었는데 이번 분기엔 63개로 늘어나고, 다음 분기엔 또 달라진다. 매번 새 상품이 출시되고 규제가 바뀌며, 기업이 합병되면 용어나 데이터 구조가 순식간에 바뀐다. 여기서 문제는 대부분의 문서 자동화 시스템이 이런 변화를 전제로 설계되지 않았다는 점이다. 대부분의 시스템은 ‘한 번 구축하면 끝’이라는 방식으로 만들어져 있어서, 필드나 구조가 조금만 달라져도 전체 logic이 깨진다. 그때마다 IT팀은 시스템을 다시 수정하고, 운영팀은 기다리며, 그 사이에 문서 처리가 멈춘다. 결국 자동화가 중단되고 다시 수작업이 늘어난다.

Ontology는 IT 스프린트보다 훨씬 빠르게 변하지만, Automation는 그 속도를 따라가지 못한다. 지금 필요한 것은 단순한 자동화가 아니고, 변화를 견딜 수 있는 자동화 따라서, 온톨로지가 바뀌어도 멈추지 않는 시스템이 필요하다. Upstage information extract 는 데이터 구조가 바뀌는 순간에도 스스로 적응할 수 있는 추출 시스템을 활용한다. 즉, Ontology가 변하더라도, 변화에 흔들리지 않는 자동화가 핵심 차별화 포인트가 된다.

Upstage의 핵심은 스키마를 학습된 모델이 아닌 설정으로 다루는 것이다. 새로운 필드를 추가하거나 설명을 수정해도 모델을 다시 학습시킬 필요가 없다. 보험 서류 항목이 47개에서 63개로 늘어나더라도 스키마만 업데이트하면 된다. 재학습도, 긴 IT 스프린트도 필요하지 않다.

문서 10개만 업로드하면 AI가 자동으로 스키마를 제안하고, 검토 후 바로 배포할 수 있다. 약 3분이면 끝난다. 초기 정확도는 약 80% 수준으로 충분히 실무에 쓸 수 있다. 새로운 용어가 생기면 2~3개의 예시만 추가해주면 된다. 내부 테스트에서는 이런 방식으로 평균 6.65% 정확도가 향상됐다. 더불어 검증 기능도 내장하고 있다. 신뢰도가 낮은 값은 자동으로 표시되어 검토 대상임을 알려주고, 추출된 값이 원본 문서의 어느 페이지, 어느 좌표에서 나왔는지도 바로 확인할 수 있다. 검토 중 발견된 오류는 피드백되어 스키마를 자동으로 개선한다. PDF든, 스캔 문서든, 입력 형식이 달라도 문제되지 않는다. 모든 문서는 Document Parse를 통해 표준화되어, 형식이 바뀌어도 추출 로직이 깨지지 않는다.

만약 밤새 50개의 새 필드가 추가되더라도 복잡하지 않다. 스키마를 업데이트하고, 샘플 배치를 검증한 뒤 배포하면 된다. 몇 분이면 끝난다. 두가지 시나리오 예시를 통해 이 시스템이 이러한 문제 발생상황에서 어떻게 대응 가능한지 설명하도록 하겠다.

Scenario 1: New insurance product launch

보험사가 새 상품을 출시하면서 신청서 양식이 바뀌었다. 기존엔 47개의 필드였지만, 새 상품에는 63개의 필드가 필요하다. 문제는 기존 시스템이 새 필드를 인식하지 못해 신청서를 처리할 수 없다는 점이다. 금요일 출시를 앞두고 이미 수천 건의 신청서가 접수된 상태다. 일반적인 시스템이라면 모델을 다시 학습시키고 코드를 수정해야 하지만, Upstage에서는 스키마만 수정하면 된다. 즉, 새 필드 16개를 추가하고 검증한 뒤 바로 배포할 수 있다. 따라서 몇 분 만에 새 상품 양식을 반영하고 업무를 이어가능 것이 가능하다.

Scenario 2: Regulatory compliance update

새로운 개인정보 보호 규제가 즉시 시행되었다. 기존에는 ‘환자 동의’ 항목 하나만 있었지만, 이제는 ‘치료 동의’, ‘데이터 공유 동의’, ‘연구 동의’ 세 항목으로 나뉘어야 한다. 기존 시스템은 하나의 값을 추출하도록 설계되어 있어 법적으로 바로 위반 상태가 된다. Upstage에서는 필드 구조를 세 개로 나누는 스키마 변경만 하면 된다. 모델을 다시 학습할 필요 없이, 새 규제를 반영한 스키마를 바로 배포할 수 있다. 이를 통해 당일 안에 법적 요건을 충족하고, 업무를 멈추지 않고 지속할 수 있게된다.

Reference

When Ontology Changes Faster Than IT: Upstage - tech blog Upstage console Upstage AI Space Upstage - homepage

딥러닝 이전의 자연어 처리는 단어를 하나의 기호로만 봤다. Bag-of-Words나 TF-IDF는 단어의 의미나 순서를 몰랐다.

예를 들어 “king”과 “queen”은 완전히 다른 차원의 벡터였다.

2013년, 구글의 Tomas Mikolov이 제안한 Word2Vec은 단어를 고정된 벡터 공간의 점으로 매핑함으로써 의미적으로 비슷한 단어는 가까이 위치하도록 학습시켰다.

CBOW는 주변 단어로 중심 단어를 예측하고, Skip-gram은 중심 단어로 주변 단어를 예측한다. 이 단순한 아이디어로 Word2Vec은 단어 의미의 연속성(king – man + woman ≈ queen) 을 포착했다.

하지만 이 모델은 고정된 window 안에서만 학습하기 때문에 문장 전체의 흐름이나 순서, 장거리 문맥을 파악하지 못한다는 한계가 있었다.

2. 순서를 기억하게 하다 — RNN & LSTM

단어의 순서를 이해하기 위해 Recurrent Neural Network(RNN)이 등장했다. RNN은 이전 단어의 정보를 hidden state에 저장하고, 다음 입력에 전달하여 시퀀스 데이터(sequential data)를 단계적으로 처리한다.

그러나 문장이 길어질수록 과거의 정보가 희미해지는 Gradient Vanishing 문제가 발생했다. 이를 해결하기 위해 LSTM(Long Short-Term Memory)과 GRU가 제안되었다. 이들은 게이트(gate)를 사용해 정보를 선택적으로 기억하거나 잊는다.

덕분에 “I grew up in France … I speak fluent ___” 문장에서 ‘French’를 예측할 수 있을 정도로 장기 의존성을 다룰 수 있게 됐다.

하지만 여전히 순차적 계산으로 병렬화가 어렵다는 근본적 한계가 있었다. 즉, 긴 문장을 처리하려면 시간이 너무 오래 걸렸다.

3. 한눈에 보는 주의집중 — Seq2Seq & Attention

2014년, Google Brain의 Bahdanau와 Luong 연구팀은 Encoder–Decoder 구조에 Attention 메커니즘을 도입했다. 기존 Seq2Seq는 입력 문장을 하나의 고정된 벡터로 요약했기 때문에 문장이 길면 정보 손실이 심했다.

Attention은 Decoder가 단어를 생성할 때마다 입력 문장 전체에서 어디를 더 봐야 하는지를 계산하게 했다. 이 덕분에 모델은 긴 문장에서도 필요한 부분에 집중할 수 있었다.

예를 들어 “Je t’aime”를 “I love you”로 번역할 때, 각 출력 단어가 대응되는 입력 단어에 주의를 기울이는 방식이다.

Attention은 단순히 도움이 되는 기능을 넘어, 이후 모든 딥러닝 구조의 중심 사상으로 자리 잡는다.

4. 순서를 버리고 관계를 보다 — Transformers

“Attention Is All You Need.” 이 한 문장으로 정리되는 2017년의 혁신.

Vaswani et al.은 RNN의 순차성을 완전히 제거했다. Transformer는 모든 단어가 Self-Attention을 통해 서로의 관계를 한 번에 계산한다.

Query, Key, Value로 이루어진 Attention 구조는 각 단어가 문맥 속에서 얼마나 중요한지를 수치적으로 학습한다.

Multi-Head Attention은 서로 다른 의미적 관계를 병렬적으로 탐색한다. Positional Encoding은 순서 정보를 보완한다.

그 결과, RNN보다 훨씬 빠르고 정확하며 병렬화가 가능한 모델이 탄생했다. 이 아이디어는 이후 모든 대형 언어모델(BERT, GPT, T5)의 근간이 된다. 일반적으로 Transformer의 encoder부분만 활용하는 BERT는 텍스트를 "이해" 하는데, Transformer의 decoder부분만을 활용하는 GPT의 경우 텍스트를 "생성" 하는데 강점이 있다고 알려져 있다.

5. 시각의 세계로의 확장 — Vision Transformers & DETR

Transformer의 전역 Attention 개념은 언어를 넘어 이미지로 확장되었다. ViT(Vision Transformer)는 이미지를 패치 단위로 나누어 단어처럼 처리했다. DETR(Detection Transformer) 는 기존 Object Detection의 복잡한 구조를 단순화했다.

기존 Faster R-CNN은 Region Proposal → Feature Extraction → Classification 의 다단계 과정을 거쳤지만, DETR은 Transformer Decoder의 Object Query가 직접 객체를 1:1로 예측하는 Set Prediction Problem으로 정의했다.

이 덕분에 NMS(Non-Max Suppression)같은 후처리가 사라지고, 탐지 과정 전체가 End-to-End로 통합되었다.

다만 작은 객체나 세밀한 경계 탐지에는 여전히 약하다는 단점이 있다.

6. 현실을 창조하는 모델 — GAN & Diffusion model

같은 시기, 생성 모델 분야에서는 GAN(Generative Adversarial Network)이 세상을 바꿨다. Generator는 가짜 이미지를 만들고, Discriminator는 이를 구분하며 서로 경쟁적으로 학습한다.

GAN은 데이터를 직접 생성하는 딥러닝이라는 새로운 패러다임을 열었다. 그러나 학습이 불안정하고, 특정 패턴만 생성하는 Mode Collapse 문제가 있었다.

최근에는 이를 보완한 Diffusion Model(Stable Diffusion, Imagen)이 주류가 되었다. Transformer 기반 텍스트 인식과 결합하여 텍스트에서 이미지로 (text-to-image) 생성하는 시대를 열었다.

7. 거대한 통합 — GPT & RAG

Transformer 이후의 모델들은 단순한 구조 개선이 아니라 범용성을 추구한다. GPT 시리즈는 Self-Attention을 이용한 자동회귀 언어모델로, 거대한 사전학습 데이터에서 패턴을 학습한다.

T5(Text-to-Text Transfer Transformer) 는 모든 문제를 “입력 텍스트 → 출력 텍스트”로 통일해 번역, 요약, 질의응답을 한 모델로 수행하게 했다.

RAG(Retrieval-Augmented Generation)은 Transformer 기반 생성모델에 검색(Retrieval)기능을 결합해 모델이 스스로 외부 지식을 참조하도록 진화했다. 이 개념은 ChatGPT, Gemini, Claude 같은 현대 LLM의 핵심 구조로 이어진다.

딥러닝의 발전은 결국 한계의 인식 → 구조적 재해석 → 전이와 확장의 연속이다.

Word2Vec은 단어 의미를 “숫자”로 표현하려 했고, RNN은 “순서”를 기억하려 했으며, Transformer는 “관계”를 전부 모델링하려 했다. 그 뒤 DETR과 GAN은 “시각과 생성”으로 확장했고,

오늘날 GPT는 이 모든 걸 통합하는 언어적 사고의 틀로 작동한다.

Acknowledgment

이번 포스팅은 중앙대학교 소프트웨어학부 김범수 교수님의 수업자료에 기반하여 작성되었음을 분명히 명시하며 좋은 수업내용을 들을 수 있어 감사한 마음을 전해드리고 싶다. 더불어, 첨부된 그림들의 자세한 설명을 학습하고 싶다면, 아래 Reference에 원문 논문들을 첨부해두었으니, 찾아서 읽어보길 권한다. https://bmsookim.github.io/

Reference

Attention is all you need (2017, Vaswani et al) Efficient estimation of word representations in vector space (2013) Retrieval-augmented generation for knowledge intensive NLP tasks (NeurIPs’20) attention-based Dropout Layer for Weakly Supervised Object Localization (CVPR) Rich feature hierarchies for accurate object detection and semantic segmentation tech report (Ross Girshick et al, UC Berkeley) Fast R-CNN (Ross Girshich, Microsoft Research) Faster R-CNN: Towards real-time object detection with region proposal networks (Shaoqing Ren, et al) Focal loss for dense object detection (Facebook AI research) Mask R-CNN (Facebook AI research, Kaiming He - MIT) End-to-End object detection with transformers (Facebook AI) Generative Adversarial Nets (Ian J. Goodfellow et al)

1. HTTP Request로 Open Access로되어있는 논문 PDF를 받아 이에 대한 내용을 Upstage Solar LLM에게 질의응답이 가능한 워크플로우
2. Solar Chat Model을 활용한 simple Question & Answering Chatting AI Agent

내가 이를 어떻게 만들었는지 처음부터 단계적으로 설명하도록 하겠다.

n8n 설치

먼저 n8n을 실행하여야 한다. NPX를 이용한 간단한 설치, Node.js만 설치되어 있다면 몇분만에 실행할 수 있는 가장 간단한 방법, Docker를 이용한 설치, 크게 방법이 2가지 있는데 이중 나는 Docker로 이미지를 pull한뒤, 이를 실행하였다. Container name은 내 마음대로 지정하면 된다. 나는 "seohyun"으로 지정하였고 아래 Run을 클릭하여 다음 단계로 진행하였다.

이렇게 되면, 이제 local에서 실행이 가능한 상태가 되어 다음 작업을 할 수 있게 된다. n8n을 처음 접속하는 이용자라면, 관리자 설정 및 license를 활성화해야 한다. 즉, 이름, 이메일, 비밀번호를 사용하여 관리자 계정을 생성하는 초기 admin setting을 해야하고, license key를 요청하여 이를 activation key에 입력해야 n8n의 모든 기능을 자유롭게 사용할 수 있다.

Upstage API 사용법

Upstage API를 사용하는 방법도 2가지가 있는데, 하나는 HTTP Request 방식, 두번째는 Community Node 방식이다. 첫번째 HTTP Request 방식은 직접 API를 호출하고, 세밀한 제어가 가능하다는 장점이 있지만, 복잡한 설정이 필요하다는 단점이 있다. Community Node 방식으로는 API key 관리를 자동화하는 Credential, 최적모델 사전 선택, 검증된 기본값 적용하는 parameter, 오류 처리를 내장할 수 있는 Error Handling의 미리 최적화되어 있는 세팅된 설정 옵션들이 있다. 이는 개발시간을 80% 이상 절약하고, 복잡한 API 문서 학습의 불필요, 즉시 사용 가능한 완성형 도구로서 사용가능하다는 장점이 있다.

나의 경우, n8n community node를 설치하여 Upstage API를 사용하였다. 위와 같은 창이 떳다면, Community node가 최종적으로 설치되었다는 의미이고, 이제 Upstage에서 제공하는 모든 제품들을 n8n에서 활용할 수 있게 된다.

1. PDF Q&A Workflow

앞서 설명했듯이, 나는 2가지의 workflow를 제작해 보았다. 먼저, 첫번째 워크플로는 HTTP Request를 사용해 .pdf 형식의 파일을 받아 Solar LLM에게 질문하여 이에대한 답변을 받는 것이다. HTTP Request는 restapi 기능을 제공한다. 위에 보이는 사진은 HTTP Request node의 parameters 설정 모습이다. 나는 Web에서 공개되어 있는 .pdf 파일확장자를 HTTP의 GET Method를 사용해서 "file"로 불러왔다. Solar LLM model은 위 캡쳐화면에서 보다싶이, solar-mini, solar-pro, solar-pro2 3가지 중에서 하나를 선택하면 되는데, 나는 solar-pro2를 사용하였다. 아래는 해당 워크플로우를 실행한 모습이다. 상단의 INPUT에는 Schema, Table, JSON, Binary 4가지 형식을 선택할 수 있고, 오른쪽에 OUTPUT 출력화면을 보면 Schema, Table, JSON 형태로 결과값을 볼 수 있다. 앞서 내가 언급했듯이, 나는 HTTP Request를 통해서 논문.pdf 형식의 파일을 불러왔기 때문에, Upstage Solar LLM에 "이 논문의 핵심 기여가 뭐야?" 라는 질문을 해보았고 이에 대한 답을 LLM model이 해준 모습이다. 번외로, "Role" 설정 또한 가능하다.

2. Chatting Agent Workflow

내가 제작한 두번째 Workflow는 Solar Chat Model을 활용한 AI Agent이다. Model들을 아래 처럼 8개의 모델 중 하나를 선택할 수 있다. 이번에는 solar-pro 모델을 선택하여 작업을 진행해 보았다.

아래 캡쳐화면 처럼, Solar model에 "안녕" 이라고 입력해보았다. 그림에서 확인할 수 있듯이, Logs에 process가 다 입력이 되고, Input, Output이 출력됨을 볼 수 있다.

더불어 Solar Chat Model 노드를 상세 클릭하여 Parameter와 setting창에 들어가면, 다시 아래 화면처럼, 입력과 출력값을 Schema, Table, JSON 형태로 출력가능하다는 것을 확인할 수 있다.

마지막으로, 아래 화면에서 Solar Model에게 직접 "Solar model에 대해서 어떻게 생각해?" 라는 질문을 던져보았다. 아래 화면에서 볼 수 있듯, 다국어 및 한국어 최적화에 강점이 있다고 답변하였다. 특히, Solar model은 한국어와 영어에 특화되어 있어서 다른 글로벌 모델보다 한국어 처리 능력이 뛰어나고, 이 때문에 한국어 사용자에게 더 자연스럽고 정확한 응답을 제공할 수 있다는 장점이 있다. 또한, 한국어의 복잡한 문법이나 문화적인 맥랑을 이해하는데에 강점을 보일 수 있다고 설명한다.

이번 실습을 통해 나의 개인적인 견해로는, n8n은 UI는 복잡한 코딩 없이 Node와 Edge만으로 간단한 AI Agent workflow를 만들 수 있는 훌륭한 플랫폼이라고 생각한다. 더불어 Upstage API를 활용해 Upstage 제품들을 사용해볼 수 있는 좋은 기회였다.

Reference

n8n -homepage Docker Upstage Console Upstage - homepage

업스테이지 콘솔에서는 자체 개발한 production model들을 직접 경험할 수 있다. 복잡한 문서작업, Q&A service, 핵심 information extract 등의 작업에 LLM을 활용해보고 싶은 경우 여기서 실험해 볼 수 있다. 왼쪽 상단 메뉴중 "Models"를 클릭하면 아래와 같이 여러 AI model들을 확인해 볼 수 있다.

더불어 "compare" 기능이 있어 모델들을 직접 사용해보고 서로 비교분석이 가능하다. "Playground"에는 모델과 함께 이를 직접 테스트 해볼 수 있게끔 예시 자료들을 제공한다. Document Parse의 경우, Json, HTML 형식 모두 제공한다. 상세 내용을 아래 해당 부분들을 자세히 읽어보면 된다.

나는 이들 중 Information Extract model을 사용해 보았다. 아래 화면은 내가 읽고 있는 논문을 직접 업로드해본 모습이다. Set schema 하단에 Auto-generate 버튼을 누르게 되면, 내가 업로드한 문서에 대한 내용들을 손쉽게 잘 정리해 준다. 이 중 에서 Type은 String, Integer, Boolean, Number로 구성되어 있다.

하단의 "Confirm and extract" 버튼을 누르면 다음과 같은 화면이 출력되는데, 나의 경우 다음과 같이 extraction result가 나왔다.

해당 부분이 어디에서 추출된 내용인지 궁금하다면, 클릭하여 해당 위치를 파악할 수 있다. 추가적으로 Json 형식으로도 데이터를 확인해 볼 수 있기 때문에 내가 어떤 작업을 하느냐에 따라서 취사선택이 가능하다. 추가적으로 이 단계까지 마무리 되었다면, 다시 오른쪽 하단에 "Use API with this schema" 버튼을 통해 Upstage API를 사용할 수 있다. Python외에도, cURL, JavaScript를 활용할 수 있다.

Information extract model 말고도, Document parsing 모델을 사용해 볼 수도 있다. 아래 화면을 보면, Business, General, Government, Foreign languages 들의 보고서들을 Parsing 작업을 토해 HTML, JSON 형식으로 추출 한 것을 확인해 볼 수 있다.

아래 화면은 Document OCR을 활용해본 예시로, 위와 유사하게 Business, Commerce, Finance, Foreign languages 다양한 도메인 영역에 해당 기술을 적용하여 내가 원하는 형태의 데이터를 추출 가능하다.

사용법이 궁금하거나, 이 모델이 어떤 서비스를 제공하는지, 작동원리가 어떻게 되는지, API는 어떻게 사용해야 하는지가 궁금하다면, Upstage console에서는 각 해당 모델마다 Documentation과 API Reference를 제공하므로, 해당문서를 확인하면 상세한 설명을 확인해 볼 수 있다. 하단 Reference에 참고링크를 참조해 두겠다.

Upstage에서 개발한 Document intelligence 기술이 어떤식으로 사회의 다양한 영역에 적용되고 활용될 수 있는지 궁금하다면, 업스테이지 콘솔을 적극적으로 활용해 보길 권한다.

Reference

console.upstage.ai Document OCR API Reference Document OCR Documentation Upstage - hompage

업스테이지에서 제공하는 다양한 AI 교육 프로그램들은 아래 링크를 통해 접속해서 확인해볼 수 있다.

edu.upstage.ai

나는 해당 프로그램들을 수강하면서 Upstage의 Document Intelligence 기술과 Solar Pro 2 LLM model에 대해서 공부하였고, Upstage API를 활용한 개인 prototype 프로젝트를 제작하여 제출하였다. 최종적으로는 Upstage AI Ambassador 1기에 선발되었다.

홈페이지에 접속하게 되면 아래와 같은 화면을 볼 수 있고, 위에 세부 메뉴 중 "Courses" 들을 통해서 더 많은 프로그램들을 접할 수 있다.

아래처럼 내가 등록한 프로그램들이 무엇인지 확인할 수 있고, 진행상황 또한 한눈에 파악할 수 있다.

나는 해당 강의를 모두 수강완료했기 때문에 전부 체크표시가 되어 있다. 혹시라도 Upstage AI Ambassador2기 모집에 관심이 있는 사람들이라면, 아래에 4. Claim Certification에서 강의에 대한 수료증을 받고 이를 따로 첨부해서 AI Ambassador 모집 프로그램에 제출해야 한다.

오른쪽을 화면은 해당 강의에 대한 상세한 설명이 나와있는 모습이다. text로만 되어있는 글을 읽다보면 집중력이 떨어지거나 조금 이해하기 쉽지 않은 부분들이 존재할 수 있는데, 굉장히 쉬운 예시 그림을 통해서 설명하고 있는 내용을 더욱 쉽게 이해할 수 있는 장점이 있다. 상세 API 발급과정과 절차, 사용법 모두 이 강의에 설명되어 있다. 아래 그림처럼 Upstage Console창에 개인 API key를 발급받을 수 있는데, 이것을 활용해 Upstage의 대표적인 LLM 모델 Solar Pro 2, Solar mini model들을 활용해 볼 수 있다.

위에 "Dashboard"를 클릭하면, 아래 그림처럼 Solar API를 활용해 내가 무엇을 하고자 하는지에 따라 example code를 제공하기 때문에 이를 참고하면 보다 더 쉽게 기능을 사용해볼 수 있다. 나는 Upstage의 Information extract API와 Document parsing 기능을 사용해서 Document Q&A keyword 추출 서비스 prototype을 제작하였다.

chat chat with Resoning Document parsing Document OCR Universal extraction Prebuilt extraction Document classification Structured outputs

Document Intelligence 기술과 Solar Pro 2 model 그리고 이들이 금융, 법률, 제조, 헬스케어 등 다양한 도메인과 어떻게 융합되어 활용될 수 있는지, 여러 비즈니스 환경에서는 어떻게 다르게 사용되는지 궁금하고 알고자 하는 사람이라면 Upstage AI education program을 적극적으로 활용해보길 권한다.

Reference

Upstage.ai - Upstage 공식 homepage edu.upstage.ai - Upstage AI education homepage credential.net

현재 Transformer는 OpenAI의 GPT, Meta의 Llama, Google의 Gemini와 같은 텍스트 생성 모델에 활용되고 있으며, 텍스트를 넘어 오디오 생성, 이미지 인식, 단백질 구조 예측, 게임 플레이 등 다양한 분야에서 활용되며 versatility(범용성)을 입증하고 있다. 텍스트 생성형 트랜스포머 모델은 다음 단어 예측(next-word prediction) 원리에 기반한다:

사용자로부터 입력된 텍스트 프롬프트를 바탕으로, 그 다음에 올 가장 가능성 높은 단어는 무엇인가?

트랜스포머의 핵심적인 기여는 self-attention mechanism에 있으며, 이를 통해 입력 시퀸스 전체를 동시에 처리하고, 장거리 의존 관계(long range dependency)를 이전 아키텍처보다 훨씬 효과적으로 포착할 수 있다. GPT-2 모델 계열이 대표적인 텍스트 생성형 트랜스포머라고 할 수 있다. 그 중에서 GPT-2 모델은 1억 2400만개의 파라미터를 가지고 있으며 가장 최신이거나 강력한 모델은 아니지만 현재 최첨단 모델들과 핵심 구조와 원리를 공유하고 있기 때문에 기본적인 개념을 이해하기 위해 좋은 예시라고 볼 수 있다.

모든 텍스트 생성형 트랜스포머는 3가지 핵심적인 구성요소로 이루어져 있다.

1. Embedding

• 텍스트 입력은 단어 or sub word 단위의 작은 token들로 나뉘고, 이 token들은 단어의 의미를 수치적으로 표현한 vector인 embedding으로 변환된다.

2. Transformer block

입력 데이터를 처리하고 변형하는 모델의 핵심 연산 단위이다. 각 트랜스포머 블록은 다음의 두가지 구성요소로 이루어져 있다.

• Attention mechanism: 트랜스포머 블록의 핵심 구성요소로, 토큰 간 상호작용을 통해 문맥 정보 및 단어 간 관게를 학습
• MLP (다층 퍼셉트론, Multilayer Perceptron): 각 토큰을 독립적으로 정제하는 feedforward network이다. 어텐션이 토큰간 정보 전달을 담당한다면, MLP는 각 토큰의 표현을 정교화하게 된다.

3. Output probabilities

트랜스포머 블록을 통과한 임베딩은 linear + softmax layer를 통해 다음에 올 토큰에 대한 확률분포로 변환되고, 이를 통해 모델은 다음 단어를 예측하게 된다.

Embedding

예를들어, 트랜스포머 모델에 "Data visualization empowers users to"라는 문장을 입력하면, 이 text는 모델이 이해할 수 있는 형식으로 변환되어야 하고, 바로 이 과정에서 임베딩이 필요하다.

Transformer는 텍스트를 임베딩으로 변환하기 위해 4단계를 거치게된다.

1. Tokenization --> 입력 문장을 단어 or subword token으로 분해 입력 텍스트를 더 작고 관리하기 쉬운 단위인 토큰으로 나누는 과정으로, 이 토큰은 단어일 수 있고, subword 일 수 있다. 모델이 학습되기 전, 전체 토큰 사전 (vocabulary)이 정의되고 GPT-2의 경우 50,257개의 고유토큰을 사전에 포함하고 있다. 입력 텍스트를 토큰으로 분할하고, 각 토큰에 고유한 ID를 부여했다면, 이 ID들을 기반으로 vecter representation(embedding)을 얻을 수 있다.

2. Token embedding 추출 --> 각 토큰을 고차원 수치 벡터로 매핑 GPT-2 (small) 모델에서는 각 토큰을 768차원의 벡터로 표현한다. 여기서 이 차원의 수는 모델의 크기에 따라 달라지는데, 이 임베딩 벡터는 (50.257 x 768) 크기의 행렬에 저장되어 있고, 총 약 3900만개의 파라미터를 포함하고 있다. 이 거대한 임베딩 행렬덕분에 모델은 각 토큰에 semantic meaning을 부여할 수 있게 된다.

3. positional encoding 추가 --> 순서 정보를 나타내기 위해 각 position에 고유한 encoding 추가 Embedding 층에서는 각 토큰의 의미뿐 아니라 입력 문장에서의 위치 정보도 함께 인코딩하게 된다. 모델마다 위치 인코딩 방식은 다르나, GPT-2는 자체적으로 학습된 위치 인코딩 행렬을 사용하며, 이를 훈련과정에서 직접 통합하여 학습한다.

4. token embedding + positional encoding --> 최종 embedding vector 생성 마지막으로 토큰 임베딩과 위치 인코딩을 더해 최종 임베딩 표현을 생성하는데, 이 결합된 벡터는 각 토큰의 semantic와 position정보를 동시에 담고 있어 트랜스포머 모델이 문맥을 더욱 잘 이해하고 예측할 수 있게 한다.

이렇게 트랜스포머는 문자열 형태의 텍스트를 수학적으로 연산가능한 벡터형태로 변환하여 본격적인 처리를 시작한다.

Transformer block

트랜스포머 모델의 핵심은 트랜스포머 블록에 있는데, 이 블록은 다음 두가지 주요 구성요소로 이루어져 있다. Multi head self attention과 MLP (Multi layer perceptron)이다. 대부분의 트랜스포머 기반의 모델은 이 트랜스포머 블록을 여러개 쌓아서 구성한다. 입력 token은 첫번째 block부터 마지막 block까지 순차적으로 처리되며, 각 layer를 거치면서 표현이 점차 정교해지고 의미가 풍부해진다. 이러한 계층적 구조 덕분에 모델은 token의 고차원적 의미와 맥락을 효과적으로 파악할 수 있다. 계속 살펴본 예로 GPT-2 (small) 모델은 총 12개의 트랜스포머 블록으로 구성되어 있다.

1. Multi head self attention

self attention mechanism은 모델이 입력 문장에서 어떤 단어가 중요한지 스스로 판단하여 집중할 수 있도록 한다. 이를 통해 문장 안에서의 의미적 관계나 문법적 의존성을 잘 포착할 수 있게 된다. 멀티헤드 어텐션은 이 메커니즘을 여러개의 주의 집중 head로 동시해 수행하여 여러시점에서 다양한 의미관계를 동시에 파악가능하고, 각 head가 서로 다른 정보를 포착하여 더 풍부한 표현을 생성할 수 있게 된다.

1. Query, Key, and Value Matrices

각 토큰의 임베딩 벡터는 3개의 벡터로 변환된다. Q(Query), K(Key), V(Value) 이들은 학습된 Q, K, V 가중치 행렬과 입력 임베딩을 곱하고 편향을 더해 얻는다.

Web search에 쉽게 비유해보자면, Query는 검색창에 입력하는 검색어 (지금 알고싶은 단어)가 되고, Key는 검색 결과의 제목 (어떤 단어들이 참고가능한지 나타냄)이 되고, Value는 검색결과의 실제 컨텐츠로 (관련있는 페이지에서 보고싶은 정보)가 된다. 모델은 이 Q, K ,V 값을 통해 attention score를 계산하고 예측할때 어떤 token에 '집중'할지를 결정하게 된다.

Scaled Dot-Product Attention

스케일 조정 내적 어텐션의 계산 방식은 아래와 같다. 퀴리와 모든 key간의 dot product(내적)을 계산하고 그 값을 나누어 스케일링한 뒤, softmax 함수를 적용해 각 값에 대한 가중치를 얻는다. 실제로, 여러개의 쿼리를 한번에 처리하기 위해 쿼리를 행렬 Q, 키를 K, 값을 V로 행렬로 묶어서 처리한다. 이렇게 하면 출력행렬이 위 공식과 같게 된다.

2. Multi head splitting Query, Key, Value 벡터는 각가 여러개의 head로 분할되는데, GPT-2 (small)의 경우 12개로 나뉜다. 각 head는 입력의 다른 부분을 독립적으로 처리하여, 다양한 의미/문법적 관계를 포착한다. 이러한 구조 덕분에 모델은 병렬적으로 다양한 언어적 특성을 학습할 수 있고, 표현력도 더 강력해진다.

3. Masked self-attention 각 head에서 masked self-attention을 수행하게 되는데, 이 과정은 모델이 미래 토큰을 보지 않고 앞부분 정보만을 참고해 다음 토큰을 예측할 수 있도록 돕는다.

• attention 점수 계산: query와 key의 내적(dot product)를 계산해 각 토큰이 다른 토큰과 얼마나 관련이 있는지 수치화한 정사각 행렬을 만든다.
• masking: 이 행렬의 오른쪽 위 삼각형 부분(future token)은 -∞ 로 설정하여 미래 정보 접근을 차단한다.
• Softmax: masking된 attention score는 softmax 함수를 통해 확률분포로 변환되며 각 행의 합은 1이 된다.

이렇게 계산된 attention 가중치는 각 토큰이 왼쪽에 있는 다른 토큰에 얼마나 집중해야할지를 나타내게 된다.

4. Output & Concatenation 각 헤드에서 나온 attention결과를 value 행렬과 곱해 최종 출력을 계산하는데 앞에서 예를 든, GPT-2의 경우 12개의 헤드를 사용하며, 각 헤드는 다른 의미/구조적 관계를 포착하게 된다. 마지막으로 모든 헤드의 출력을 연결(concatenate)한뒤 linear projection을 적용하여 다음 layer로 전달한다.

2. MLP: Multi-Layer Perceptron

multi layer self attention이 입력 토큰들 간의 다양한 관계를 포착한 후, 이 연결된 출력은 MLP층으로 전달되어 모델의 표현 능력(representational capacity)를 강화하게 된다.

MLP block은 두개의 linear transformation과 그 사이에 위치한 GELU 활성화 함수로 구성되는데, 첫번째 선형 변환은 입력의 차원을 768 --> 3072로 (4배 증가)시킨다. 두번째 선형 변형은 차원을 다시 3072 --> 768 (원래 크기로 복원)하여, 다음 층에서도 일관된 차원의 입력을 받을 수 있도록 한다.

self-attention과는 달리, MLP는 각 토큰을 독립적으로 처리하며, 단순히 토큰 표현을 하나의 벡터 공간에서 다른 벡터공간으로 변환한다.

Output Probabilities

입력이 모든 트랜스포머 블록을 거쳐 처리된 후, 최종 출력은 마지막 linear layer를 통해 token 예측을 위한 형태로 변환된다. 이 계층은 최종 표현을 50,257차원의 공간으로 사상하는데, 이 숫자는 GPT-2의 전체 어휘 집합(vocabulary) 크기이며, 각 토큰마다 logit이라는 값이 할당되게 된다. 모든 토큰은 다음 단어가 될 수 있기 때문에, 이 과정은 각 토큰이 다음에 등장할 가능성에 따라 순위를 매길 수 있는 기반을 제공한다. 그 다음 이 logit 값에 softmax함수를 적용하여 총합이 1이되는 확률분포로 변환한다. 이렇게 변환된 확률 분포를 바탕으로, 우리는 각 토큰이 다음에 등장할 확률에 따라 샘플링하여 실제 다음 단어를 생성할 수 있다. 2024년 존스홉킨스 연구팀이 개발한 'Transformer Explainer'를 활용하면 구조를 굉장히 쉽게 파악할 수 있다.

모델의 출력 확률 분포로부터 다음 토큰을 sampling 하여 생성하는 것이 마지막 단계이다. 이때, temperature 하이퍼파라미터가 중요한 역할을 한다. 수학적으로는 아주 간단한 연산인데, 모델의 출력 logits 값을 temperature 값으로 나눈 후 softmax를 적용하는 방식이다.

• temperature = 1: logit을 1로 나누게 되면 softmax 결과에 영향을 주지 않는다
• temperature < 1: 값이 작을수록, 확률분포가 날카로워지고 모델은 더 결정론적이되며 예측 가능한 출력을 생성한다.
• temperature > 1: 값이 클수록, 확률분포가 평탄해지고 무작위성이 커지며 창의적인 출력이 나타날 수 있다.

sampling 기법으로는 top-k와 top-p가 있는데

• top-k samlpling은 확률이 가장 높은 상위 k개의 토큰만 후보로 제한하고 그 외는 제거하는 방식이다. 낮은 확률의 토큰 제거로 안정성을 향상할 수 있다.
• top-p nucleus sampling은 누적 확률이 p 이상되는 최소 토큰 집합만을 고려하는데, 확률이 너무 낮은 토큰은 제외하면서도 다양성을 유지할 수 있게 된다.

Adavanced Architectural Features

Transformer model의 성능을 향상시키는 다양한 고급 구조적 기능들이 있다. 아래 내용들은 모델의 학습과 일반화에는 매우 중요하지만, 아케텍처의 핵심 개념을 이해하는데 필수는 아니다. 대표적인 구성요소로, layer normaliazation, dropout, residual conntections(잔차 연결)이 있다.

1. Layer Normalization

각 층의 출력값을 평균과 분산기준으로 정규화하여, 값의 sclae 차이를 줄이고 학습이 더 잘 되도록 돕는다. 내부의 공변량 변화 문제(internal covariate shift)를 완화하여, 초기 가중치에 대한 민감도를 줄인다. Transformer block 안에서 두번 적용되는데, self-attention 앞과 MLP layer 앞에서 적용된다. 이를 통해 모델의 학습과정을 안정화하고 수렴 속도를 높일 수 있게 된다.

2. Dropout

학습 중 일부 뉴련의 출력을 무작위로 0으로 설정해, 특정 뉴런에 대한 의존을 줄이는 방법이다. overfitting을 방지하는 정규화 기법으로, 더 강건하거 일반화된 특성을 학습하도록 돕는다. 하지만 추론 시에는 적용되지 않아, 여러 sub model의 ensemble처럼 동작하여 성능이 향상된다.

3. Residual Conntections

2015년 ResNet에서 처음 제안된 혁신적인 구조로, 입력을 출력에 직접 더해주는 우회경로를 생성하여 vanishing gradient(기울기 소실 문제)를 완화하게 된다. 더 깊은 네트워크로도 학습이 가능해지고, 이전 층까지 gradient가 원활히 흐른다. 마찬가지로 GPT-2를 포함한 Transformer block에서 2번 적용되는데, self attention 이후, MLP이후가 된다.

이 3가지 구성요소들은 Transformer의 성능 향상에 핵심적이 기초 기술로 작용하고, 특히 학습과정에서 큰 차이를 만들어내게 된다.

마지막으로 첨부하는 이 그림은 트랜스포머 구조의 세부적인 부분까지 한 그림에 모두 담고있어 전체적인 숲과 나무를 동시에 보고 이해하는데 매우 도움이 된다.

Reference

Transformer Explainer github.io Transformer Explainer: Interactive Learning of Text-Generative Models (2024) https://arxiv.org/abs/2408.04619 https://cme295.stanford.edu/ - Stanford online lectures VIP Cheatsheet: Transformers & Large Language Models - AfshineAmidi, ShervineAmidi (2025) GENAI starter pack -RESHMAWITHAII (linkedin) Natural language processing with python cheat Sheet (nltk) Vaswani et al, (2017) Attention Is All You Need. http://arxiv.org/abs/1706.03762 Doshi (2021a) Transformers Explained Visually — Not Just How, but Why They Work So Well. Towards Data Science. Jay Alammar (2018) The Illustrated Transformer. https://jalammar.github.io/illustrated-transformer/ https://superstudy.guide. The Transformer Architecture: Institute for Analytical Sociology (IAS) at Linköping University (LiU), Sweden. 2023 Hendrik Erz

LLM (대규모 언어모델)이 단순한 명령 수행 시스템에서 복잡하고 다면적인 애플리케이션의 핵심 추론 엔진으로 진화함에 다라, 이들과 상호작용하는 방식또한 발전하고 있다. Prompt engineering이라는 용어는 기본 개념으로 중요하지만 현대 AI system이 요구하는 정보 payload의 설계, 관리, 최적화를 포괄하기에는 부족하다. 그 이유는, 이러한 시스템이 하나의 고정된 문자열 텍스트만을 처리하지 않으며, 동적이고 구조화된, 다면적인 정보흐름을 활용하기 때문이다. 이에 대응하기 위해서 'Context Engineering' 이라는 새로운 개념이 생겨나게 되었다.

What is Context engineering?

Context Engineering을 공식적으로 정의하기 위해서 먼저 autoregressive LLM의 표준 확률모델을 알 필요가 있다. 파라미터 세타로 정의된 이 모델은 입력 컨텍스트 C가 주어졌을때, 출력 sequence Y를 다음의 조건부 확률을 최대화하도록 생성한다. 기존의 프롬프트 엔지니어링 패러다임에서는 컨텍스트 C를 단일하고 정적인 텍스트 문자열로 취급하였다. 즉, C = prompt라는 단일 개체로 보았다. 그러나 이러한 관점이 현대의 complex한 system에서는 더 이상 맞지 않았다. Context engineering은 C를 동적으로 구조화된 정보 component 집합으로 재 개념화 한다. 이러한 component들을 일련의 함수들에 의해 획득, 필터링, 포매팅되며 최종적으로 고수준의 조립함수 A에 의해 조율(orchestration)되게 된다.

여기서 각 component ci는 임의로 정해지는 것이 아니고 참고한 survey 논문에서 다루는 핵심적인 기술영역들과 직접적으로 연결된다. 예를들어, 시스템 명령어 및 규칙, 외부지식(Rag, knowledge graph), 사용 가능한 외부 도구들의 정의 및 시그니처, 이전 상호작용으로부터 축적된 영속적 정보, 사용자, 세계, 또는 멀티에이전트 시스템의 동적 상태, 사용자의 현재 요청이 있다.

Context engineering은 전통적인 prompt engineering과의 근본적이 차별점을 두고 있다. Context engineering은 정교하고 문맥인식이 가능한 AI system을 설계, 이해, 최적화 하기 위해서 필요한 형식적이고 체계적인 framework를 제공한다. prompt design에서 art --> 정보 물류와 시스템 최적화의 science 로의 관점으로 전환한다고 볼 수 있다.

Context scaling

컨텍스트 스케일링은 문맥 정보처리의 범위와 정교함을 결정짓는 두가지 근본적인 dimension으로 구성된다.

1. Length scaling

ultra-long sequence 처리를 위한 연산적, 구조겆인 과제이다. 이는 수천~수백만의 token 까지 context window를 확장하면서도 긴 이야기, 문서, 상호작용 전반에 걸쳐 coherent understanding을 유지하는것을 목표로 한다. 이를 위해서는 sophisticated attention mechanisom, 메모리 관리 기술, 구조적인 혁신이 필요하다. 이들은 모델이 광범위한 input sequence에서도 문맥적인 일관성을 유지할 수 있게 한다.

2. Multimodal and structural scaling

두번째로는 단순한 text를 넘어서는 context 확장을 의미한다. 이는 다차원적이고 동적인 cross-modal 정보구조를 포함한다. 시간 순서에 따른 관계와 시퀸스의 이해인 시간적 컨텍스트, 위치기반 및 기하학적 관계해석의 공간적 컨텍스트, 여러 개체의 변화 상태를 추적하는 참여자 상태, 목표, 동기, 암묵적 목적을 이해하는 의도기반 컨텍스트, 특정 사회적,문화적 맥락에서의 의미를 해석하는 문화적 컨텍스트가 있다.

현대의 Context engineering은 이 두가지 fundamental dimentions들을 동시에 해결할 수 있어야 한다. 실제 애플리케이션에서는 단지 긴 텍스트 뿐만이 아니라 다음과 같은 다양한 데이터 유형을 동시에 처리해야 하기 때문이다.

• 구조화된 지식 그래프
• 다중모달 입력 (텍스트, 이미지, 오디오, 비디오)
• 시간적 시퀸스
• 인간이 자연스럽게 이해하는 암묵적 문맥 신호 등

이라한 다차원적 접근 방식은 단순히 모델 파라미터수를 늘리는 scaling을 넘어 인간 지능이 복잡한 현실세계를 이해하는 방식에 가까운 시스템을 구축하려는 근복적인 방향 전환을 의미하게 된다.

Why Context engineering?

현재 대규모 언어모델(LLMs)은 고도화된 컨텍스트 엔지니어링 접근법이 반드시 필요한 기술적 한계에 직면해 있다. 예를들어, self-attention mechanism은 sequence 길이가 늘어날수록 계산량과 메모리 사용량이 제곱 비율로 증가하기 때문에, 긴 context를 처리하는데에 있어서 심각한 장벽이 되고 있다. 이에 따라 chatbot이나 여러 모델의 실제 응용에 부정적인 영향을 미치고 있다. 특히 상용 서비스에서는 동일한 context를 반복적으로 처리해야하기 때문에 추가 latency와 토큰 기반의 과금 비용이 더해져 이러한 문제를 악화시킨다. 계산 자원 문제이외에도 여러 단점들이 존재하고 있다. 빈번한 hallucination(환각), 입력 문맥에 대한 불성실한 응답, 입력 변화에 대한 민감한 반응, 구문적으로는 맞지만 의미적으로 일관성이 없는 응답이 이 있다. 또한 기존의 prompt engineering은 근사기반(approximation-driven)이거나 주관적인 방식에 의존하고 있어서 모델의 개별적인 행동차이를 충분히 고려하지 못하는 경향이 있다. 하지만, 정확하고 풍부한 문맥이 담긴 프롬프트 작성은 모호성을 줄이고 응답의 일관성을 높이기 때문에 프롬프트 엔지니어링은 여전히 중요하다.

고급 context engineering 기법들 (e.g, In-Context Learning, Chain-of-Thought, Tree-of-Thought, Planning)은 정교한 언어 이해 및 생성 능력의 기반이 되며 검색 및 생성 최적화를 통해 강력한 문맥인식 AI응용을 가능하게 한다. 향후 logit Contrast를 활용한 chain-of-thought 보강, 다양한 문맥 유형의 효과적 활용, 특히 코드 인텔리전스 분야에서의 문법, 의미, 실행 흐름, 문서화를 통합, 고도화된 필터링 및 선택 메커니즘을 통해 Transformer 구조의 스케일링 한계 극복 등 성능의 품질을 유지하면서도 확장 가능한 LLM 시스템 개발의 핵심 경로가 된다.

Foundational Components

Context Engineering은 대규모 언어 모델에서 정보관리를 위한 핵심적 과제를 해결하기 위해 설계된 세가지 기본 구성 요소를 기반으로 구축된다.

1. Context Retrieval and Generation (문맥 검색 및 생성) 프롬프트 설계, 외부지식 검색, 동적 문맥 조립 등을 통해 적절한 문맥 정보를 수집
2. Context Processing (문맥 처리) 획득된 정보를 최적화하고, 긴 시퀸스를 처리하며, 구조화된 데이터를 통합
3. Context Management (문맥 관리) 메모리 계층 설계, 압축 기술 개발등을 통해 문맥 정보의 효율적인 조직과 활용을 담당

아래는 Artificial Analysis에서 발표한 공식 자료이다. 빅테크 기업들의 LLM을 비교분석하였다.

2025년 보고서에 의하면, 대부분의 AI 모델들의 경우, 현재 미국과 중국이 압도적인 점유율을 차지하고 있는것을 볼 수 있다. 미국은 추론 기반의 모델에서 선두자리를 지키고 있다. Aritificial Analysis의 intelligence index 기준, 상위 4개의 모델은 모두 미국연구소의 추론 모델이다. 중국의 경우, 비 추론 모델 부문에서 1위를 하였는데, DeepSeek V3 0325가 현재 non-reasoning 부문에서 최고 성능의 모델로 미국 및 타국 모델들을 앞서고 있다. 하지만 그 외 국가들에서는 점진적인 발전이 이루어지고 있지만, 아직 최첨단의 frontier 지능 모델 경쟁에서는 주요한 위치를 차지하지 못하고 있다.

현재는 위그림처럼, 사용자의 프롬프트를 해석하고, 사용 가능한 도구들과 상호작용하여 주어진 작업을 수행하는 LLM 기반의 agent system으로 변화하였다.

Open AI는 여전히 선두를 지키고 있고, o3와 o4-mini-high 모델은 최첨단 지능 모델로 평가되고 있다. 구글의 Gemini 2.5 pro도 매우 근접한 수준이다. 높은 intelligence index를 기록한 모델은 공통적으로 thinking을 거쳐 답변하는 추론 기반의 모델이기 때문에 '추론 능력'이 핵심적인 경쟁력이라고 볼 수 있다. 2025년 초 기준 미국의 주요 5대 연구소 (Open AI, Google, Anthropic, sAI, Meta)에 대해 NVIDIA, DeepSeek, Alibaba, Mistral, Amazon도 frontier 모델 대열에 합류하였다. 여기서 핵심 경쟁력이라고 볼수 있는 Reasoning에 대해 부연설명을하기 위해 아래의 그림을 첨부하겠다.

해당그림에서는 뚜렷하게 두 그룹으로 Reasoning model vs non-reasoning model로 나뉘게 된다. Reasoning model은 평균적으로 Non-reasoning model보다 최대 10배 더 많은 토큰을 사용하여 intelligence index를 수행하기 때문에 모델간의 성능 비교분석에서 'token efficeincy'도 매우 중요한 기준이 될 수 있음을 보여준다.

단순히 토큰 단가만으로는 reasoning 모델의 실제 비용을 제대로 파악할 수 없다. 이제는 총 토큰 사용량과 조합하여 총 추론비용을 계산해야 합리적인 의사결정이 가능할 수 있다.

AI 모델의 성능은 하드웨어에도 크게 좌우된다. 여전히 NVIDIA가 독보적인 점유율을 자랑하고 있다.

Reference

A Survey of context Engineering for Large Language Models Artificial Analysis AI Adoption Survey Report H1 2025 Artificial-Analysis-State-of-AI-Q1-2025-Highlights-Report The architecture of today's LLM applications

Agenti AI는 본질적으로 자율성에 중점을 둔 인공지능이다. 특정 목표를 달성하기 위해 스스로 판단하고, 행동하며 학습할 수 있는 AI를 말한다. 지시 없이 상황을 파악하고, 생각하고, 적응하면서 일을 수행할 수 있는 지능형 가상 비서이다.

4단계 과정을 통해 작동한다.

1. Perception: 주변 환경으로부터 데이터를 수집
2. Reasoning: 수집한 데이터를 분석하여 현재 상황을 이해
3. Action: 파악한 내용을 바탕으로 적절한 행동을 결정하고 실행
4. Learning: 피드백과 경험을 통해 점차 더 나아지고 스스로를 개선

--> 이런 과정을 통해 Agentic AI는 매우 높은 자율성을 가지며, 추론, 문제 해결, 새로운 상황에서의 적응이 필요한 복잡한 작업도 스스로 처리할 수 있는 능력을 갖추게 됨

What is an AI Agent?

AI Agent는 특정 작업을 수행하도록 설계된 인공지능이다.

예를 들어,

1. 답변에 답변하기
2. 일정 정리하기
3. 이메일 관리하기

이러한 정해진 업무를 돕기 위해 만들어졌다.

즉, AI Agent는 단순하고 반복적인 작업을 자동화하는 데 매우 뛰어나지만, Agentic AI처럼 자율적으로 판단하거나 결정을 내리는 능력이 없다.

What is MCP?

LLM(Large language model)은 뛰어나 지식과 추론 능력을 가지고 있어 다양한 복잡한 작업을 수행할 수 있지만, 이들이 가진 지식은 초기 학습 데이터에 한정되어 있다. 따라서 실시간 정보를 얻기 위해서는 외부 도구나 리소스를 직접 활용해야 한다.

이를 가능하게 해주는 것이 바로 Multi Context Protocol (MCP) 이다. MCP 는 다양한 AI system이 외부기능 (도구, API etc..)과 연결될 수 있게 해주는 범용 커넥터 역할을 하며, 쉽게 말하면 USB-C 가 전자기기간의 연결을 도와주는 것과 같은 역할을 한다고 볼 수 있다.

Engineering Use Cases

1. LLM과 내부 API integration

• LLM이 내부 API에 안전하게 접근할 수 있도록 하되, read-only or interactive 형태로만 접근을 허용 --> 민감한 비즈니스 데이터를 노출하지 않고도 구조화된 데이터에 접근 가능 ex) 재고 확인 API, 사내 보고서 요약, 고객 이력 조회(단 수정 불가)

2. Enterprise agents

• AI agent에 다음과 같은 runtime context 제공, Salesforce CRM, SAP ERP, knowledge base
• -> agent가 비즈니스 환경을 이해하고 실시간 상황에 맞춰 의사결정을 할 수 있도록 지원, ex) 고객 요청에 따른 견적 자동 작성, 사내 정책에 따른 보고서 생성

3. Dynamic prompt construction

• 사용자 세션, 시스템 상태, 작업 파이프라인의 맥락에 따라 프롬프트를 동적으로 생성하여 더 정확하고 상황에 맞는 응답 유도 ex) 사용자 과거 질문 기반의 맞춤 응답, 현재 업무 단계에 맞춘 안내 프롬프트 자동 조정

Why was MCP created?

MCP가 없다면, 새로운 도구를 추가하거나 다름 모델을 통합하는 것이 매우 어렵게 된다. 예를들어, 공통 표준이 없기 때문에, 만약 AI Application이 3개이고 외부 도구가 3개 있다면, 각, AI와 각 도구를 연결하기 위해 최대 9개 통합 모듈(3X3)을 따로 만들어야 했다. 이는 확장성 면에서 매우 부족하다는 단점이 존재한다.

결국, AI 애플리케이션 개발자들은 매번 새롭게 무언가를 발명하는 것처럼 동일한 문제를 반복해서 해결해야 하는 어려움이 존재했다. 도구들은 제공하는 provider들도 서로 화환되지 않는 여러개의 API를 지원해야만 더 다양한 AI platform에 접근할 수 있었다.

MCP가 등장하기 전에는, AI를 외부데이터나 기능과 연결하는 방식이 one-off 해결책들의 집합이라고도 볼 수 있었다. 각 도구마다 hardcoding된 로직을 작성하거나 불안정한 prompt chain을 관리하거나, vendor 고유의 플로그인 framework를 써야 했다. 이로 인해서 발생한 한계와 문제점이 위에서 언급한 M X N integration problem이다. M 개의 서로다른 AI application과 N개의 외부 도구(data source)가 있다면, M x N개의 개별 통합 작업을 따로 만들어야 했다.

각 AI model은 database, file system, calculator 등 외부 서비스와 연결되기 위해 고유한 코드나 인터페이스가 필요했고, 그 결과는 아래와 같이 복잡한 연결 구조를 만들게 되었다.

Problem Solving

MCP는 이러한 문제를 해결하기 위해 중앙에 표준 인터페이스를 도입한다. 이를 통해 기존처럼 M X N개의 직접 통합이 필요한 구조 대신 M + N 개의 구현만으로 충분하게 된다. 즉, M 개의 AI application은 각각 MCP client를 한번만 구현하면 되고, N 개의 외부 도구나 서비스는 각각 MCP 서버를 한번만 구현하면 된다. 이렇게 되면 모두 같은 language를 활용해 소통하기 때문에, 새로운 조합이 생겨도 별도의 custom code를 작성할 필요가 없게된다. 이미 MCP라는 공통 프로토콜을 통해 서로 이해할 수 있기 때문이다.

위 그림을 통해 이 과정을 설명해 보자면, 전통적인 접근 방식에서는 각 모델이 모든 도구와 직접 연결되어야 했다. 모델 수가 늘어나거나 도구가 추가될수록 복잡도는 기하급수적으로 증가하였다. 반면, MCP를 적용함에 따라, 각 모델과 도구가 MCP layer에만 연결되기 때문에, 연결구조가 획기적으로 단순화 되었다.

쉽게 표현하자면, MCP는 '통역사'라고도 이해할 수 있다. 이전까지는 의사소통을 하기위해 모든 사람이 서로의 언어를 배워야 했다면, 이제는 MCP를 통해 서로 하나의 '공통된 언어'를 활용해 소통할 수 있게 된 것이다.

MCP Architecture

MCP의 핵심은 web이나 다른 network protocol처럼 client - server architecture를 따른다는 것이다. 다만, MCP는 AI 환경에 맞게 용어가 약간 다르게 정의되어 있다.

MCP에서 3가지 주요 역할을 확인해야 한다.

1. Host
2. Client
3. Server

이 세가지 주요 역할들이 함께 작동하면, AI 모델과 외부 도구간의 효율적인 상호작용이 가능해진다.

1. Host

Host는 사용자와 직접 사용하는 AI 애플리케이션이다. 즉, AI 모델이 탑재되어 있고 사용자와 소통하는 환경을 의미한다.

예를들어, Open AI의 Chatgpt interface, Anthropic의 Claude desktop app, AI 기능이 내장된 IDE Cursor or Chainlit처럼 AI assistant를 포함한 custom ap 등이 이에 해당한다고 볼 수 있다.

Host는 시스템이 외부기능을 필요로 할때, MCP 서버들과의 연결을 시작한다. 또한 사용자의 입력을 수집하고, 대화 기록을 유지하며, 모델의 응답을 사용자에게 보여주는 역할을 한다.

2. Client

MCP Client는 Host 내부에 포함된 구성요소로, MCP Server와의 저수준 통신을 담당한다. Client는 adapter 나 메신저 역할을 수행한다고 볼 수있다. Host가 무엇을 할지를 결정한다면, Client는 그것을 실제로 실행하기 위해 MCP 방식으로 Server와 대화하는 역할을 맡는다. 즉, Host는 지시를 내리고, Client는 그 지시를 MCP 언어로 해석해 외부 서버에 전달하고 결과를 받아오는 결과를 받아오는 중간다리역할을 한다고 보면 된다.

3. Server

MCP 서버는 application에 실제 기능(도구, 데이터 etc..)을 제공하는 외부 프로그램 또는 서비스이다. 즉, 특정 기능을 감싸고 있는 wrapper로 볼 수 있으며, 해당 기능을 표준화된 방식으로 외부에 공개하여, 어떤 MCP Client든 호출 할 수 있도록 만들어져 있다. 서버는 Host와 동일한 local machine에서 실행될 수 있고, 또는 클라우드 상의 원격 서버에서 실행될수 있다. MCP는 이 두개의 시나리오 모두를 문제없이 지원하도록 설계되어 있다.

가장 핵심적인 부분은, MCP Server가 자신이 무엇을 할 수 있는지 ex) 사용할 수 있는 도구 목록, 기능 들을 표준 포맷으로 광고하고, Client로부터의 요청을 실행한 후 그 결과를 반환한다는 것이다.

What is ACP (Agent Communication Protocol)?

ACP는 BeeAI와 IBM이 제안한 open standard로 동일한 local 혹은 edge 환경에서 작동하는 AI agent간의 구조화된 통신, 검색, 협업을 가능하기 위해 설계되었다. MCP와 A2A가 주로 클라우드 기반의 도구 연결 or 에이전트간의 통신에 초점을 두어 네트워크의 비용이 크고 느릴 수 있는 단점이 있다면, ACP는 local-first 전략을 활용하여 환경에 배포된 에이전트간에 빠르고 실시간으로 통신이가능해 네트워크 overhead를 최소화하고 밀접한 통합을 지향하게 된다.

What is A2A (Agent-to-Agent Protocol)?

A2A는 Google이 제안한 agent 간 통신을 위한 cross platform specification으로, heterogeneous systems 상에 배포된 AI agent들이 서로 통신하고, 협업하며 작업을 delegate(위임) 할 수 있도록 설계 되었다.

A2A는 HTTP 기반의 통신 모델을 사용하여 각 agent를 상호운용 가능한 web service처럼 다룬다. ACP나 MCP와는 다른 방향으로, horizontal interoperability에 초점을 맞추는데 ,ACP가 로컬 환경 중심의 실시간 협업에 초점을 둔다면, MCP는 AI 모델과 외부도구 간의 통합 계층을 제공한다. A2A는 서로 다른 vendor나 runtime에서 실행 중인 Agent들이 web상에서 능력을 교환하고 workflow를 조율할 수 있도록 표준화 한다.

A2A + MCP

A2A와 MCP 는 상호보완적이지, 경쟁하는 프로토콜이 절대로 아니다.

• MCP는 AI가 file, API, DB등 외부 도구나 구조화된 데이터에 접근할 수 있도록 해준다. 예를들어, 실시간 매출 데이터 가져오기, 사용자 맞춤형 리포트 생성, DB조회 및 분석 자동화, 비유하자면 세상의 도구들과 연결되는 'plug' 역할을 한다.
• A2A는 AI를 AI와 연결한다. 서로 다른 vendor나 platform에서 작동하는 agent들이 서로를 발견하고, 작업을 위임하고, 협력하는 공통의 언어와 규칙을 제공한다. 예를들어, 한 에이전트가 다른 에이전트에게 특정 작업 요청, 다양한 AI들이 함께 복잡한 workflow 수행, 비유하자면 AI들 사이의 '협업 언어' or '공통의 protocol'을 의미한다.
• ACP는 클라우드 없이도 하나의 공유된 runtime안에서 agent들이 즉시 서로를 발견하고 통신할 수 있도록 설계되었다. HTTP나 web 기반의 탐색이 아닌 경량 messaging과 실시간 orchestration에 최적화 되어 있다. 비유하자면, 하나의 device안에서 여러 agent가 동작하는 '내부 통신망'으로 robot, IOT device, smart factory 등 edge computing environment에 적합하다.

--> 역시 가장 좋은 건 Convergence 방향으로 가야한다는 것이다.

Local MCP Client

MCP client는 Cursor와 같은 AI application 내에서 외부 도구와의 연결을 담당하는 component이다. 해당 worflow는 다음과 같다.

사용자가 query를 보내면, Agent가 MCP 서버에 연결하여 사용가능한 도구를 탐색한다. 쿼리의 목적에 따라 적절한 도구를 선택하고 실행하여 관련 정보를 얻고 얻은 context를 바탕으로 응답을 생성하고 user에게 반환한다.

MCP-pwered Agentic RAG workflow

MCP 기반의 Agentic RAG는 외부 도구와의 표준화된 연결(MCP)를 활용하여 우선적으로 ,vector database에서 정보를 검색하고 필요시 web search로 fallback(자동전환)하여 정보를 보완한다. 또한 단순한 검색 도우미가 아니라 Agentic AI 특성에 따라 스스로 판단하여 검색 전략을 조정할 수 잇다.

이 work flow는 다음과 같은 순서로 진행된다.

사용자가 MCP client(cursor)를 통해 query를 입력하면 이 MCP client는 Host 내부에서 작동하고 사용자와 상호작용하게 된다.

Client는 query에 적합한 도구 (vector DB 검색기, web 검색기 등)을 선택하기 위해 하나이상의 MCP 서버에 접속하게 되는데, 각 서버는 자신이 제공하는 기능을 표준화된 방식으로 광고하고 있고, client는 이를 보고 도구를 선택하게 된다.

선택된 도구가 실행되고 관련 결과가 client로 다시 반환된다. 받은 도구 결과를 바탕으로 AI model이 최종 응답을 생성하게 된다. 이 생성된 response가 Host를 통해 user에게 출력되게 된다.

Reference

Model Context Protocol.io/introduction 2025 will be the year of AI agents - Bindu Reddy AI Agent vs. Agentic AI - 모두의 연구소 AI Agents vs Agentic AI: What's the Difference and why does it matter? - Medium https://github.com/google 2025 MCP The illustrated Guidebook - Daily Dose of Data Science brightdata github What every AI engineer should know about A2A, MCP & ACP -Medium A2A project.github.io

본 문서에서는 총 30개의 가장 영향력 있는 신흥 기술과 기술 trend를 분석하였다. 올해 Impact Radar 연구에서 도출된 기술과 트렌드를 요약하였다. Reference에 해당 자료의 출처를 첨부해 두었으나, Gartner 기술 문서들은 별도로 개인정보를 입력한 뒤에 다운받아야 내용을 확인할 수 있다. 본 문서가 2024년 1월에 게시된 자료임을 참고하길 바란다.

위 그림과 표는 최근들어 상승하고 있는 기술들과 세계에 영향을 미치는 트렌드들을 시각화하였다. 이 내용들을 참고하면 business에 어떤 제품들과 서비스의 기능들에 해당 기술들을 접목시킬 수 있을지 더 넓은 시야와 식견을 겸비할 수 있다.

아래와 같이 4개의 핵심 키 테마별로 설명하겠다.

1. The Smart World Transforms Interactions

온라인과 오프라인 Experience가 융합되면서 spatial computing, 인간이 사람, 장소, 컨텐츠, 사물과 상호작용하는 방식 또한 변화하게 되고 있다. 멀티모달 인터페이스의 경우 사용 사례에 따라 다양한 입력 방식 (음성, 문자 언저, 뇌, 근육 신호 제어, 동작과 gesteure, 얼굴 표정이나 시선 움직임, touch 등)을 포함한다.

예를들면, customer service를 위한 인간과 유사한 AI 아바타를 컴퓨터 생성 이미지로 만들어 사용할 수 있고, 브랜드 대표로도 활용될 수 있다. 이러한 상호작용은 digital twin을 통해 더욱 개인화 될 수 있는데, 특정 개인을 반영하는 디지털 복제체로 환자의료, 금융 및 상업 서비스, 정부 및 사회 서비스와 같은 사용사례에서 행동을 예측하는데에 활용될 수 있다.

2. AI-Enabled Applications Will Spur a Productivity Revolution, Largely Driven by Generative AI

지난 1년간 AI 기술, 특히 GenAI의 발전은 AI 기반의 애플리케이션 생산성 잠재력을 크게 상승시켰다. 2023년에는 생성형 AI가 가상비서, 기업용 애플리케이션, search engine, computer vision solution등에 널리 통합되면서 인기있는 기술로 자리잡게 되었다. 이에 따라 기존의 기능 개선뿐만 아니라 새로운 function과 자동화 가능성을 내비치고 있다. 특히 AI는 기존 end-point에 점차 확산되고 있고, camera, UAV(무인 항공기), IOT device, satellite 등 새로운 end point들에도 적용되고 있다. self-supervised learning, synthetic data, model compression 등 AI 기법의 발전은 여러 enterprise들이 데이터 접근성과 hardware limitations들을 극복하는데에 도움을 주고 있다.

3. Privacy and Transparency Will Be the Gating Factors for Technology Adoption

자산, 정보, 경험이 더욱 디지털화됨에따라 악의적인 행위자가 이를 해킹하거나 가로챌 수 있는 위협도 증가하고 있다. 이러한 보안 및 privacy issue를 완화하기 위해서는 데이터를 전통적인 중앙 집중형 저장소에 보관하는 대신 Decentralized Identity 시스템으로 적용하는 것이 더 안전하다. 그 이유는 해당 시스템이 재사용 가능하고 이동성있는 신원을 제공하면서 사용자에게 자신의 신원 및 관련 데이터에 대한 더 많은 제어권을 부여할 수 있기 때문이다. Behavioral Anaytics를 통해서 신뢰가능한 사용자를 식별할 수 있다. 이는 단말기 기반의 인증이 아닌 사용자와의 과거 상호작용에서 파생된 메타 데이터 (시간대, 위치, 접근방식, 이동 속도)를 바탕으로 행동 프로파일을 개발하는 방식이다. AI 도구와 기술이 다양한 제품과 사용사례에 적용되면서 규제 및 법적 조치의 위험성도 증가하고 있는데, leader들은 responsible AI 나 privacy enhancing technologies를 통해 올바른 비즈니스 및 윤리적인 선택을 해야할 것이다. 더 나아가 Human-Centered AI 설계 원칙을 통해 사람과 사회에 도움이 되는 방향으로 AI를 활용해야 한다.

4. Unlock Full Potential of Tech Solutions With Advancements in Critical Enabling Technologies

blockchainrhk tokenization을 포함한 Web3기술은 현재 겨울기로 접어들고 있고, 투자와 도입이 둔화되고 있다. 이는 비즈니스 및 기술 성숙도 면에서 여러 과제를 안고 있기 때문이며, Web3기술이 실질적인 비즈니스 가치를 제공하는 데에 어려움을 격고 있기 때문이다. Knowledge graph와 확장가능한 Vector Databases는 핵심 software 기술로, 조직 내에서 대형 언어 모델(LLM)의 설명력과 활용성을 높여 생성형 AI 도입을 지원하고 있다. 따라서 이러한 기술투자는 Gen AI도입에 있어 매우 중요하다고 할 수 있다.

AI hardware (e.g, AI chips, neuromorphic computing, quantum processing) 의 발전은 더 많은 edge device에 AI solution을 배포할 수 있게 하고 있으며, 더 복잡한 AI application을 cloud 외부 환경에서도 실행 가능하게 만들고 있다. private 5G나 LEO satellite constellations (저궤도 위성) 과 같은 통신 기술의 혁신은 소비자와 기업 모두에게 보다 광범위하고 안정적인 연결성을 제공하며 원격 작업을 지원하고 있다.

한편으로 computer vision과 edge AI는 이미 impact radar의 간극을 넘어서 16% 이상의 시장 도입률을 기로했기 때문에 해당 문서에서는 이 이상 다루지 않는다. 그러나 두 기술 모두에서의 혁신은 계속되고 있다는 점은 분명하다.

Database

• A databse is an organized collection of data that enables simple and efficient storage, retrieval, and modification of data

1.Centralized Database

• Collection of information at a single location accessible from numerous points, the basic function of a centralized database management system is to provide facilities and give access to all the connected computers which ful fill all requirements requested by any single node

2.Cloud Database

• Database that is built, deployed and accessed in a cloud environment, private, public or hybrid cloud

3. Commercial Database

• A commercial database is developed and maintained by a commercial organization that is generally made available to customers and potential customers

4. Distributed Database

• Data is stored across different physical locations. It maybe stored in multiple computers located in the same physical location or maybe dispersed over a network of interconnected computers

5. End User Database

• end-user database enables storing data created by an end-user. Any database which allows the end-user to create and manage data comes under this category. This means that the user is able to directly interact with and control the database and the data that is stored in it

6. Graph Database

• purpose-built to store and navigate relationships among objects. Relationships are first-class citizens in graph databases, and most of the value of graph databases is derived from these relationships. Graph databases use nodes to store data entities, and edges to store relationhips between entities

7. Object Oriented Database

• The data base combines object-oriented programming concepts with relational database principles. Think of a class a s a model, and objects as various constructs and instances of it. These instances share the properties they derive from the class

Cloud Databse Management systems

Gartner는 cloud database management systems 시장을 데이터를 저장하고 조작하는 software 제폼들을 대상으로 하고, 이러한 제품들은 주로 클라우드에서 SaaS 형태로 제공된다. Cloud DBMS는 선택적으로 on-premise 환경, 하이브리드, 멀티클라우드, 인터클라우드 구성에서도 실행될 수 있다.

이런한 시스템은 OLTP( 트랜잭션 처리) 또는 OLAP (분석 처리) 를 위한 용도로 모두 사용될 수 있고, 더 넓은 데이터 생태계에 참여할 수 있도록 하는 기능을 갖추고 있다. Cloud DBMS는 일반적으로 내구성이 뛰어난 방식으로 데이터를 영구 저장하고 Create, Read, Update, Delete와 같은 CRUD 작업 전체를 지원하는 독자적인 구성요소를 통해 데이터를 관리하게 된다.

클라우드 DBMS는 조직이 business process를 실행하고 그 프로세스에 대한 분석을 수행하는데 도움을 준다.

나는 해당 포스팅에서는 AWS(Amazon Web Services)에 관한 내용만 정리하도록하겠다. 파란색 점으로 표시된 더 많은 클라우드 DB 제품군에 대한 설명을 아래 Reference에 기술문서를 확인해보면 모든 것이 정리되어 있다.

AWS는 세계에서 가장 널리 채택된 CSP (클라우드 서비스 제공업체)이고, 폭넓은 Cloud DBMS service를 제공한다. AWS 데이터베이스 서비스는 트랜젝션, 운영, 분석, 스트리밍 애플리케이션 등 다양한 워크로드를 지원한다. 다음과 같은 목적 기반 데이터베이스 제품군을 제공한다.

Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon Neptune Amazon ElastiCache Amazon Timestream Amazon Keyspaces Amazon MemoryDB Amazon Redshift

해당 서비스들은 전 세계적으로 AWS 자체 직원, 산업별 전담팀, 서비스 제공 파트너를 통해 제공된다.

Strengths

• Market leadership: 광범위한 데이터베이스 제품군, 다양한 공급업체와의 전략적 파트너쉽, 전세계적인 입지, 파트너 커뮤니티 그리고 third party 도구 및 서비스와의 통합 솔루션을 보유하고 있다
• Extensive Choice: 관계형, key-value 값, 문서형, 인메모리, 그래프, 시계열, 광역 컬럼 등 다양한 목적 기반의 DB서비스를 제공하며, 생성형 AI 기반의 지원도구로 현대적인 데이터베이스 중심의 애플리케이션 개발과 배포를 지원한다.
• Enhanced integration across database services: 외부 데이터 소스와의 연결, 다양한 DB 간 Zero-ETL 서비스, 그리고 다양한 네이티브 데이터 통합 서비스를 통해 데이터 이동을 간소화하고, 데이터 생태계 전반에 걸친 end-to-end governance를 제공한다.

Limitations

• Limited hybrid and multicloud offerings: AWS는 클라우드 서비스 혁신과 생태계 확장에 집중한 결과, 하이브리드 및 멀티 클라우드 전략에는 상대적으로 소극적이다. Apache Spark와 Apache Iceberg와 같은 opensource engine 및 format을 지원하고 있지만, 여전히 일부 고개들은 하이브리드/멀티클라우드 환경에서의 데이터 오케스트레이션을 위해 제 3자의 솔루션에 의존하고 있다.

• Integration complexity: 워낙 많은 서비스들이 존재하다보니 고객이 적절한 제품을 선택하는것이 어렵다. 이를 해결하기 위해 Zero-ETL 통합 제품군과 차세대 Amazon Sagemaker 통합 플랫폼등을 통해 플랫폼 복잡성을 줄이기 위한 노력을 진행중이다.

• Enhanced data ecosystem support: AWS service를 선택하면 필연적으로 일정 수준의 종속성이 발생한다. 따라서 고객의 입장에서는 이를 전체 데이터 생태계 관점에서 평가해야한다. AWS는 개방성, 모듈성, 통합성을 강화하기 위한 지속적인 개선을 하고 있으나, 완전히 통합된 데이터 생태계 제공을 위해서는 아직 보완이 필요하다.

Reference

gartner.com/emerging-tech-trends Database Types_Datamavericks gartner Magic Quadrant/ Cloud Database Management systems

많은 Software Company 들은 점점 더 ML을 자사 item에 통합하고 있고, 이에 따라 새로운 데이터 관리 도구의 필요성이 증가하고 있다. 현재 많은 도구들이 ML application의 초기 개발과 배포를 지원하지만, ML 생명주기의 서로 다른 단계나 구성 요소를 목표로 하는 분절된 솔루션들로 이루어진 복잡한 생태계를 구성하고 있다. 이러한 분절성 문제로 인해 production 과 더불어 system 배포 후 발생하는 문제(예기치 못한 출력 값이나 낮은 예측 품질)을 해결하는것이 매우 어렵게 되었다.

내가 리뷰하는 이 논문에서는 기존의 ML 개발도구의 stack을 보완한 end-to-end observability를 제공하는 시스템을 제안하고 있다. prototype과 더불어 MLTRACE라는 독립적인 플랫폼 시스템으로 다음과 같은 기능을 제공한다.

1. 구성 요소 실행 시 사전 정의된 테스트 실행 및 ML 특화 메트릭 모니터링
2. 전체 파이프라인의 데이터 흐름 추적
3. 파이프라인 상태에 대한 post-hoc queries들의 수행

스타트업에서부터 대기업까지 다양한 조직들이 machine learning 기반의 application을 개발하고 배포하는 데 점점 더 많은 자원을 투입하고 있다. 이러한 ML application들은 ETL, 모델학습 등 여러 이질적인 구성 요소들로 이루어진 복잡한 파이프라인을 형성하고 있고, 각 구성요소들 마다 고유한 문제점이 존재한다. 예를들어, 데이터 전처리 문제, covariate shift(공변량 이동), 예측 제공의 어려움, Retraining (주기적 재학습) 등의 문제점이 있다.

현업에서 실무를 뛰는 실무자들의 경우 이러한 문제를 해결하기 위해 여러 도구들을 조합해 사용하는데, 예를들어 Hive Metastore로 자주 변경되는 원시 데이터를 관리하고, Deequ로 데이터 유효성을 검사하며, Weights & Biases로 실험 추적을 수행한다. 하지만 이처럼 분절된 도구들의 조합은 ML 애플리케이션의 sustainability를 위협하고 전체 pipeline 관찰에 어려움을 줄 수 밖에 없다.

특히 ML bug는 pipeline의 어느 구성요소에서든 발생할 수 있고, 그 상호작용에서도 발생할 수 있다. 또, ML pipeline은 단일 모델만 있는 단순한 예측과제라고 해도 매우 복잡할 수 있는데, 배포 이후에도 파이프라인이 지속적으로 변화하며, 같은 작업을 위해 모델이 반복적으로 재학습 및 재배포가 되기 때문이다.

한가지 approach로는 TFX나 overton과 같은 전체 pipeline을 통합하는 framework를 사용하는 것이지만, 전체 애플리케이션을 새로 작성해야 하기때문에 user의 진입 장벽이 높고, 기존 코드와 도구들을 유지하고 싶은 user들에겐 부담스러울 수 밖에 없다.

해당 논문에서는 platform-agnostic하고 기존 도구와 호환되며 전체 ML 애플리케이션의 지속 가능성을 지원하는 시스템인 MLTACE를 제안하는데 이는 기존의 software observability 개념을 ML에 알맞게 확장한 것이라고 말할 수 있다.

Difference between Software observability & ML observability

먼저, software observability란, 제어 이론에서 비롯된 개념이다. runtime에 수집된 telemetry를 활용하여 complex한 software의 동작을 파악하는 것을 의미한다. 하지마, 기존의 software 관측성 도구들은 ML 파이프라인을 제대로 지원 할 수 없는데, 이유는 빈번한 상태의 snapshotting이 필요하고, 이에 따른 새로운 데이터 관리 과제들이 존재하기 때문이다.

일반적인 software 관측성은 log, metric, trace를 통해 metadata를 제공하고 이를통해 시스템 상태를 분석하지만 ML 시스템의 경우, 시스템의 uptime뿐만 아니라 예측 결과의 quality또한 중요한 성능 지표가 된다.

논문에서는 세가지 핵심 요소 (logs, Metrics, traces)를 기반으로 ML 관측성을 확장한다.

1. Logging

전통적 소프트웨어는 오류코드나 stack trace 등 이벤트 기반의 로그를 수집한다. 하지만 ML system은 silent failures covariate shift(공변량 이동), concept drift(개념 드리프트) 등이 발생하며 일반적인 log에 나타나지 않을 수 있다. 따라서 입출력 데이터를 구성 요소별로 기록하고 component간 데이터 흐름을 추적할 수 있어야 한다.

논문에서 제안하는 접근법은 pipeline 내 중간 고성요소들의 입력 및 출력 정보를 모두 포착할 수 있어야 되고, 계산적으로 부담이 크고 대형 DNN model의경우 저장공간도 많이 소모된다. 또한 구성요소들이 서로다른 주기로 실행되므로, 입출력간의 연결관계를 식별하는 기능도 갖추어야 한다. 사용자들의 개입을 최소화한 lightweight manner 방식으로 수행되어야 한다.

예를들어, ETL 단계는 몇 주 전에 실행되고 inference는 실시간으로 실행되어야 한다. 이처럼 각 구성요소의 입력과 출력이 파이프라인 전반에서 어떻게 연결되는지 파악하는 것이 중요하다. 또한 이러한 로그 수집은 사용자 개입을 최소화하면서 경량화된 방식으로 지원되어야 한다.

2. Monitoring

traditional software application에서는 평균 응답 시간과 같은 수치 기반의 metric을 통해 application의 성능을 모니터링하고, 이 값이 미리정한 임계값을 초과할 경우 경고를 발생한다. 이러한 metric은 application 내부에서 쉽게 측정가능하고 집계도 간단하다.

하지만 --> ML application의 성공여부는 model의 performance에 달려있는데, 이는 간단히 측정할 수 없다. 그 이유는, label(정답값)이 production 환경에서는실시간으로 제공되지 않는 경우가 많기 때문이다.

설령, user의 feedback (Ad click 여부)가 있다고 해도 F1score나 t test score과 같은 ML metric은 대규모 환경에서 계산 비용이 매우 높다. 따라서 접근방식은 아래를 만족해야 한다.

1. 다양한 ML 중심 metric을 효율적으로 지원
2. 사용자 코드 작성을 최소화한 plug-and-play 방식
3. pipeline 구성 요소가 반복적으로 실행 될 때, 현장에서 metric 추적
4. 사용자가 임계값 alert, trigger, constraint 등을 설정하여 전체 ML pipeline 상태를 보장 가능하도록 지원

3. Querying

ML system을 전체적인 end-to-end perspective에서 debugging하려면, 관측 도구가 수집한 로그와 metric을 query 할 수 있는 기능이 필요하다.

traditional한 system에서는 engineer가 먼저 trace (data point가 system을 거치는 전체 경로)를 추적하여 데이터의 lineage를 이해하고 bug가 어디에서 발생했는지 판단한다. 이러한 trace 추적은 단일 framwork(REST API)에서 변환이 이뤄질 경우 단순할 수 있는데, ML application은 다양한 tool로 구성되어 있는 heterogeous한 stack으로 구축되어 있어, 데이터의 흐름과 출처 정보 접근에 단절되기 쉽다.

해당 논문이 제안하는 시스템의 경우,

1. 이절적인 여러 도구들과 통합되면서도 데이터의 계보 추적 가능
2. ML bug는 단일 출력이 아니라 특정 집단(slice)에서 발생하므로, 선택된 sub group에 대한 계보 질의(slice-based lineage querying)을 효율적으로 수행
3. 금융,법률 등 규제가 엄격한 산업에서는 수개월~수년전의 data에 대한 query가 필요할 수 있기 때문에 이를 위해서는 오랜 기간동안의 meta data 보존이 필요

해당 system의 경우 general software system 처럼 며칠 or 몇 주 단위로 meta data를 유지하는 것과는 차별화된다.

ML Pipeline NEEDS

실제 운영 환경에서 사용되는 ML pipeline의 일반적인 특성과, 아직 해결되지 않은 과측성 관련 요구사항에 대해서 설명해 보겠다.

End-to-End ML pipeline의 시작은 가능한 가장 상류(upstream)의 datasource부터 수집되는 data를 의미하는데, 끝은 가장 하류(downstream)의 출력이 된다.

예를들면, 어떤 Ridesharing 회사가 사용자로부터 tip을 받을 가능성을 운전자에게 알려주는 ML Application을 운영한다고 가정해보자,

이경우 pipline의 한쪽 끝은 모바일 앱에서 수집한 telemetry data이고, 다른 한쪽 끝은 운전자에게 보여지는 예측된 팁 확률이다. 작업이 단순해 보일 수 있지만, 이 파이프라인은 여러 구성 요소들로 이루어진 매우 복잡한 구조이다. 여기서의 component라는 개념이 유연하게 적용될 수 있는데, 위 figure 1에 나온 파이프라인의 각 박스는 하나의 구성 요소가 될 수 있다.

Properties of Pipelines

1. Pipeline architecture는 dynamic하다. ML pipeline의 전체 구조는 처음부터 완전히 정의 되어 있지 않다. 실제 운영되는 동안 새로운 구성 요소가 추가되거나 기존 요소가 제거되는 식으로 pipeline이 진화한다. 예를들어, data scientist가 앙상블을 통해 성능을 향상시키기 위해 새로운 model을 pipeline에 추가하는 경우 새로운 전처리, 학습, 추론 구성 요스의 추가로 이어진다. 따라서 logging이 entire pipeline이 아니라 component 단위로 이루어져야 한다.

2. component 자체도 dynamic 하다. pipeline이 변할 수 있을 뿐 아니라 하나의 component 자체도 쉽게 변경 될 수 있는데 World of software에서는 code 변경이 component element 변경을 유발한다.

production code base에 pull request를 보낼 경우 보통 test directory에 별도로 작성된 CI(continuous integration) test가 실행되서 기능을 검증하는데 ML의 경우 code가 아닌 data나 artifect (저장된 함수나 model)의 변화만으로도 component 요소가 변경 될 수 있기 때문에 기존의 software 방식의 CItest는 충분하지 않다. Deequ나 TFX같은 도구는 component 실행 시점에 데이터 품질 테스트를 작성할 수 있게 해주지만, 이 테스트는 application code 안에 직접 작성되기 때문에 재사용성이 낮다.

User Needs

pipeline을 debugging하기 위해서, 실무자는 component의 다양한 상태에 걸쳐 query를 수행해야 한다. component 요소의 component state를 다음과 같이 정의하 수 있는데, 입력, 출력, 코드 스니펫, 시작 시간, git hash, 기타 metadata 등 구성 요소 실행 시점에 기로되거나 갱신되는 정보를 의미한다.

일반적인 ML 관측성 관련 query는 complexity 순으로 4가지 유형으로 분류할 수 있다.

1. 구성 요소 실행 수준의 질의: 특정 구성 요소 실행에 대한 질의로 입력 값이나 세부적인 실행 실패 원인에 대한 질문이 포함
2. 구성요소 history query: 구성 요소의 과거 동작에 대한 질문으로 data drift 가 있었는가? 등
3. 교차 구성 요소의 질의: 구성 요소간 상호작용에 대한 질문으로, online or offline pipeline이 일치하지 않는가와 같은 질문이 포함됨
4. 교차 구성 요소 history 질의: 과거 파이프라인의 스냅샷, 예를들어 특정 출력 그룹(slice)에 대한 trace를 복원하는질문

이러한 query를 해결하려먼, ML system은 다음을 수행할 수 있어야 한다.

1. 구성 component의 history
2. 구성 요소간의 상호작용을 계산하고 저장

따라서 이 시스템의 경우 component 실행 시점에 state를 기록하고 사용자 정의 trigger를 실행하는 방식을 설계에 채택하였는데 이 후 pipeline 계산 그래프(DAG)를 재구성하여 실무자가 문제를 식별하는데 도움을 준다.

Service Level Agreements, SLAs

software engineering team은 일반적으로 서비스 수준의 계약을 통해 application이 business가치를 제공하도로 보장한다.

예를들면, client가 접근하는 API endpoint에 대해 가동률 99.9%를 보장하는것이 하나의 software SLA가 될 수 있다. 이

System에 대한 자세한 설명을 확인하고 싶다면, 아래 Rerence에 readdocs를 첨부해놓았으니 그걸 확인해보길 바란다. 이 개념을 확장하면, ML SLA의 예시는, 운전자가 팀을 받을 확률을 예측하는 ML Pipeline에서 Recall 90%를 달성하는 것일 수 도 있다. 이러한 비즈니스 핵심 metric(최소 정확도, 클릭률)을 모니터링하는 것은 매우 중요하다고 볼 수 있다.

그러나 실제 산업 현장의 여러 ML 모니터링 솔루션들은 pipeline 중간단계의 분포(feature, 출력)을 지나치게 강조하기 때문에 단편적으로 유의미한 정보가 될수는없다. dubugging에는 도움이 될 수 있다. 예를들어, 사용자가 100개의 feature 중 하나의 평균값이 50% 감소했다는 경고를 받는다고 해도, 그정보만으로 무엇을 해야 되는지 판단하기 어렵다. pipeline 구성요소가 오래되었는지 판단시에는 다라서 중간값보다 오히려 비즈니스 핵심 metric의 하락 여부를 확인하는 것이 훨씬 더 유용하다. 게다가 모든 중간 결과에 대해 경고를 발생시키는 것이 alert fatigue를 유발해 결과적으로 메트릭의 실용성을 떨어뜨릴 수 있다.

이를 해결하기 위해 MLTRACE는 중간집계를 componentrun로그안에 저장하고 경고발생 메트릭은 SLA 또는 기타 비즈니스 핵심 요구사항에 집중한다.

사용자는 구성 요소 정의 시점에서 ML 관련 metric을 미리선언하며 이 metric은 구성 요소가 실행될 때마다 계산되어 SLA가 충족되지 않을 경우에도 경고를 발생한다.

위 그림은 Web UI가 되겠다.

Reference

Towards observability for production machine learning piplines - UC Berkeley (2021) KGC 2022 기조연설 - Jure lescovec https://github.com/loglabs/mltrace https://mltrace.readthedocs.io/en/latest/

RAG?

RAG (Retrieval-Augmented Generation): NLP에서 사용되는 기법으로 Retrieval과 generative model을 결합하여 더 정확하고, 관련성이 높으며, 문맥을 이해한 응답을 생성하는 방법

기존의 언어 생성 작업에서는 Meta의 LLaMMA model이나, IBM의 Granite model과 같은 LLM이 입력된 프롬프트를 기반으로 응답을 생성 이러한 대형 LLM 모델은 주로 chatbot등에 사용

하지만, Knowlege base에 최신정보가 없는 경우에 RAG 가 매우 유용한 도구가 될 수 있다.

AI Agent?

Agentic RAG system의 핵심은 AI agent로 사용자를 대신하거나 다른 시스템을 대신에 스스로 작업을 수행하고, 작업흐름(workflow)를 설계하며, 도구를 활용할 수 있는 자율적인 시스템을 의미한다.

Agentic 기술은 다양한 데이터 소스에서 최신 정보를 수집하고 작업흐름을 최적화하며 복잡한 문제해결을 위한 하위 작업(subtask)를 스스로 생성하는 방식으로 작동 Agent가 사용하는 외부 도구 list

• 외부 데이터셋
• 검색 엔진
• API
• 다른 AI agent 등

Traditional RAG의 경우 vector database에서 문서를 검색해 LLM에 제공하는데 문서검색을 전담하며 제한적이고 단일 에이전트이지만, Agentic RAG의 경우 다양한 도구 사용이 가능하다.

(검색, 계산, 분석, 이메일 작성 등) 다양한 데이터에 접근이 가능하고 검색과 분석 의사결정 보조 등 여러 역할들과 작업들을 수행할 수 있다. 자율적인 계획과 툴 선택이 가능하며 다중 에이전트와의 협업이 가능하여 성능향상이 가능하다.

Agent의 경우 multi-step reasoning을 통해 상황에 따라 적절한 도구를 스스로 선택하기 때문에 다중 에이전트 시스템에서는 에이전트들이 협업하여 단일 에이전트보다 뛰어난 성능을 보일 수 있다. --> 이러한 scalability(확장성)과 adaptability(적응성)이 traditional RAG에 비해 Agentic RAG의 장점이라고 말할 수 있다.

What is Graph RAG?

• RAG의 고급 버전으로 KG와 같은 graph 구조의 데이터를 통합하여 사용하는 기술

기존의 RAG system은 vector search를 통해 의미적으로 유사한 텍스트를 검색하는 반면, GraphRAG는 도메인 특화 쿼리에 따라 그래프의 관계 구조를 활용하여 정보를 검색하고 처리함.

GraphRAG는 2024년 Microsoft Research에 의해 도입되었으며, LLM의 한계를 극복하기 위해 탄생하였다,. 기존 LLM은 특히 비공개 데이터나 구조화된 데이터에 대한 복잡한 추론 작업에서 어려움을 겪는데, 이러한 이유가 생기는 것은 LLM이 entity간의 관계를 이해할 수 있는 능력이 부족하기 때문이다.

GraphRAG의 경우 graph database를 활용하여 이러한 관계를 modeling함으로써, 복잡한 질의 처리, 문맥적 정보 검색, 생성형 AI의 정확도 향상이 가능해진다.

RAG 작동방식

1. vector database, 외부 지식 소스, 내부 지식 베이스로부터 유사도 기반의 관련 정보를 검색한다.
2. 이후, 해당 정보를 LLM과 결합하여 문맥을 고려한 응답을 생성한다.

하지만 기존 RAG의 limitations는 아래와 같다.

1. 데이터간의 복잡한 관계를 이해하지 못함
2. 멀티홉 추론(multi-hop reasoning)이 어려움 --> 여러 소스의 정보를 논리적으로 연결하거나 간접 추론이 어려움
3. 계층적 정보나 관계 기반의 문맥 처리 부족

예를 들어, "누가 상대성 이론을 발명 하였는가?" 에대한 질문은 Entity 간의 관계에 대한 이해와 추론이 필요하기 때문에 기존의 RAG로는 어려울 수 있다.

Graph RAG는 어떻게 이를 개선하는가?

Graph RAG는 말그대로 graph structured dat를 도입함으로써 이러한 한계를 극복한다. graph는 다음과 같은 구성으로 정보를 표현한다.

1. nodes: 사람, 장소, 개념, 엔티티 등
2. edges: node 간의 관계
3. labels: node나 edge를 정의하는 attribute

예를들어, "알버트 아이슈타인 - 발명 - 상대성 이론" 이 정보를 graph structure로 표현하면, node: 알버트 아인슈타인, 상대성 이론 edge: 발명

이처럼 graphRAG는 정보를 network 형태로 구성하고 관계를 기반으로 정보를 검색하고 처리함으로써 보다 정확하고 복잡한 질의에 대한 응답 생성이 가능하다.

--> Transforming data into knowledge graph creates a network of connected and linked entities, and the linked multilayed knowledge graph then supports a wide range of applications and generating targeted questions to craftin rich and contextually relevant summairies ultimately providing a depth of insights that traditional RAG cannot achieve alone

Benefit of using graph RAG

Develop: maintainance Production: Higeher accuracy / complete Governance: Explainability

Components of GraphRAG

graphRAG는 4지의 주요 구성 요소로 되어 있다.

1. Query Processor
2. Retriever
3. Organizer
4. Generator

1. 쿼리 프로세서 사용자의 질문을 전처리하여, 그래프 구조에서 관련 있는 주요 엔티티(개체)와 관계를 식별 NER( Named-Entity Recognition) 개체명 인식 Relational Extraction (관계추출) Cypher 같은 그래프 질의 언어를 통해 지식 그래프에서 도메일 특화 데이터를 조회

2. 검색기 전처리된 질의를 바탕으로 외부 그래프 데이터 소스에서 관련 정보를 탐색하고 추출

• 기존 RAG는 텍스트나 이미지의 vector embedding기반 검색에 의존하지만, GraphRAG는 그래프 구조를 활용하여 의미적 + 구조적 신호를 함께 사용 (leveraging both semantic and structural signals)

사용 기술: 그래프 탐색 알고리즘: BFS(너비 우선 탐색), DFS(깊이 우선 탐색) GNN(그래프 신경망): 그래프 구조를 학습하여 정보검색 Adaptive Retrieval: 탐색 범위를동적으로 조절해 불필요한 정보 제거 그래프 임베딩 모델 사용

3. 조직자 검색된 그래프 데이터를 정제하고 불필요한 node나 edge를 제거하여 더 간결하고 문맥적으로 의미 있는 정보를 유지

사용기술 Graph pruning (그래프 가지치기) Reranking(재정렬) Augmentation(보강)

4. 생성기 정제된 그래프 데이터를 바탕으로 최종 응답을 생성

사용방식 텍스트 기반 응답 생성(LLM을 활용한 자연어 응답) 과학적 응용에서는 새로운 그래프 구조 생성(ex: 분자설계, 지식그래프 확장)

Applications

1. QFS(Query-focused Text summarization)

• 사용자의 질문에 직접적으로 답하기 위해, 텍스트를 그래프 구조로 표현하여 관련 정보를 추출하고 요약

2. Personalized Recommendations

• 전자상거래, 엔터테인먼트 등에서 사용자의 과거 상호작용을 그래프로 모델링하여 맞춤형 경험 제공 핵심 기술: 사용자 행동을 반영한 subgraph 추출, multi retriever를 활용해 추천 품질향상, 고객 서비스 QA시스템 개선

3. Decision Support

• 의료 분야에서 복잡한 증상을 분석하고 질병-증상-치료간의 관계를 그래프로 모델링 사용사례: 관련 논문, 증례보고, 약물정보 검색, 진단제안, 치료 옵션 추천, 약물 상호작용 경고 제공 --> 출처가 있는 신뢰도 높은 응답 생성

4. Fraud Detection and Prevention

• 금융 서비스 등에서 비정상 패턴을 식별하고, 분산된 거래를 연결해 대규모 사기 행위 탐지 ex) 여러 계좌에 걸친 소액 거래를 분석해 사기 연결고리 발견으로 리스크 관리 향상과 개인화된 서비스 제공

5. Knowledge Management and Retrieval 문서간의 관계를 분석하여 문맥 기반 검색 및 정리를 가능하게 함 ex) 법률 사무소에서 수천건의 문서 간 관계를 분석하여 관련 판례, 법적 참고자료를 빠르고 정확하게 검색, 법률 리서치 자동화 및 정확도 향상

Challenges of GraphRAG

1. Scalability: 대용량 데이터를 처리할 때, 그래프 저장, 쿼리 최적화, 하드웨어(GPU 가속)등의 문제 발생
2. Streamlining: 쿼리 처리기, 검색기, 조직자, 생성기 간 원활한 연결이 복잡
3. Reliability: 다단계 추론에서의 누적 오류 발성 가능성 존재
4. Privacy & Safety: 그래프 구조 특성상 민감한 정보 노출의 위험있고, 공격 가능성 존재
5. Explainability: 노드간 관계는 명시적이지만, 추론 경로를 명확히 설명하는 것은 여전히 어려움

Frameworks for building a GraphRAG system

• Llamaindex: 문서 인덱싱, 엔티티/관계 추출, 벡터 임베딩 생성, GPT등과 연동
• Neo4j: 그래프 저장/관리, 그래프 탐색 및 의미 기반 검색 지원
• LangChain, OpenAI: LLM 연동 및 생성형 응답 생성 지원
• Github: 다양한 오픈소스 예제와 튜토리얼 제공

--> 의미기반 검색, 메타 데이터 처리 및 투명성 확보 문맥 인식 응답 생성을 가능하게 함

Conclusion

Traditional RAG가 직선적인 검색 방식에 한정되었다면, GraphRAG는 지식그래프, 의미검색, LLM을 결합하여, 더 풍부한 관계성 기반의 응답을 제공 --> 미래에는 더 똑똑하고 동적으로 적응 가능한 정보시스템을 위한 핵심 기술이 될것으로 기대됨

Reference

IBM agentic-rag github IBM Developer https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/ MIT Technology Review Insights sruvey. 2025

이 논문의 Citation 의 history에 대한 역사적인 관점에서 해석하는 동시에 인용지표에 대해 survey 느낌으로 정리한 논문이다.

인용분석은 발표된 과학 논문, 저자, 출판 매체(학술지/학회)를 평가하는 것이 목표이다.

학술지의 영향력을 측정하기 위해서 알려진 지표들은 여러가지가 있지만, 그중에서도 Impact Factor (IF) 가 가장 널리 사용된다.

H-index는 학회를 평가하고 순위를 매기는데에 널리 사용하는 지표로 적용 대상에 따라 분류하였다. 학술지나 학회에 실린 논문의 immediate relevance를 측정하기 위해서 Normalised immediacy index라는 새로운 지표를 제안하였는데 새롭게 제안한 지표와 기존 피료 (h-index는 학회에 대해, IF는 학술지에 대해) 관계를 파악하기 위해 Spearman 상관분석을 수행하였다.

Citation Metrics

인용지표는 연구비 지원 결정, 도서관 구독 저널 선정, 종신 재직 심사, 학회 발표자 선정 등 중요한 학술적 의사결정에 사용되어 왔다.

1960년 Eugen Garfield가 설립한 ISI(Institute for Scientific information)은 과학 논문을 위한 최초의 인용 색인인 Science Citation Index(SCI)를 도입하였다. 1997년에는 최초의 자동 인용 색인 도구인 CiteSeerX가 등장하였다.

학술지가 특정 indexing service에 포함되면 가시성, 독자층, 신뢰도 향상에 기여할 수 있다.

Evaluation of Journals

전통적으로 학술지는 연구자가 권위를 인정받기 위한 주요 출판 수단으로, 연구자에게 얼마나 명성있는 학술지에 얼마나 많은 논문을 게재했는가는 커리어 향상에 있어 굉장히 중요한 요소이다. 또한 연구성과 평가 차원에서 학술지의 품질 평가는 여전히 필수적이며 많은 연구자들은 논문을 게재할 때, 색인된 학술지를 찾으려고하는 경향이 있다.

1960년대에 Impact Factor가 도입된 이래,

• cited half-life, citing half-life
• Immediacy Index
• Eigenfactor (EF)
• SCImago Journal Rank (SJR)
• SNIP, H-index, CORE ranking, ABDC ranking

Evaluation of Conferences

학회 논문집은 수십년동안 주기적으로 개최되어 왔고, 가장 오래된 학회들은 1960년대 후반에 설립되었다. ACM, IEEE, AAAI등과 같은 저명한 국제학회들의 후원을 받았다.

컴퓨터과학 및 정보기술 분야는 혁신 속도가 빠르기 때문에 연구자들은 자신의 연구 결과를 빠르게 발표하기 위해 학술지보다 학회를 선호하는 경향이 있다.

학회의 품질을 평가할때도 다양한 기준들이 존재하는데,

• 논문의 인용 수
• 투고 수와 수락률
• 논문의 품질
• 많이 인용된 논문의 수
• 후원 여부
• 학회 설립 연도
• 프로그램 위원 구성 등

최근 10년 사이에는 Eigenfactor(EF), SCImago Journal Rank (SJR)와 같은 위상(prestige)기반 지표들이 학술지 평가에 점점 더 많이 활용되고 있다.

컴퓨터공학과 같이 빠르게 성장하는 분야에서는 논문 출판 절차가 일반 학술지보다 짧기 때문에 peer review를 거친 학회가 연구결과를 빠르게 확산하는 데 핵심적인 채널로 간주된다. 학회의 영향력 평가를 위한 다양한 지표들도 개발되었다. acceptance rate,H-index, CORE ranking, Aminer ranking, Microsoft Academic ranking등은 학회의 인기도를 평가하는 데 사용된다.

최근에 학회 평가에서도 위상 기반의 지표의 활용가능성이 연구자들 사이에서 주목받고 있는데, pagerank 기반의 인용 지표를 학회 평가에 사용하는 것이 타당하다고 판단하며, 데이터 마이닝 부냥 학회에 대해 SJR, EF 등의 지표가 기존의 인용 기반 지표들과 긍정적인 상관관계를 가진다는 것이 확인 되었다.

해당 논문에서는 기존의 Immediacy Index의 표준화된 변형으로 학술지학회에 실린 논문들이 immediacy relevance를 평가하기 위한 지표로 최신 연구분야를 다루는 출판 매체간의 비교에서 유용한 시각을 제공할 수 있다.

이로써 논문의 실제 인용 속도를 더 공정하게 반영할 수 있다.

Reference

Citation metrics and evaluation of journals and conferences