우성민, 서익희, 강충원, 김승환, 정회성

AI 트렌드 모아

AI 산업 뉴스 큐레이션 서비스

Contents

01 프로젝트 개요

1.1 팀원 및 역할 분담

1.2 개발환경

1.3 프로젝트 일정

​

​

02 서비스 기획

2.1 메뉴 구조도 (사이트맵)

2.2 기능 정의서

2.3 정책 정의서

​

​

03 서비스 구조

3.1 통합 업무 흐름도

3.2 서비스 아키텍처

​

​

04 데이터베이스 설계

3.1 SQL 설계

3.2 NoSQL 설계

​

Contents

05 주요 화면

​

​

06 주요 기능

6.1 ETL 파이프라인

6.2 추천 시스템

6.3 RAG 시스템

​

​

07 테스트

7.1 단위 테스트

7.2 통합 시스템

​

​

08 별첨

1. 프로젝트 개요

서비스 과제: AI 관련 기사 큐레이션 & 트렌드 인사이트 제공 시스템

1. 프로젝트 개요

A. “Project Redfin”

Q. “급변 AI 산업 동향을 한 눈에 볼 수 없을까?”

추진배경 및 목적

IT 업계는 빠르게 회전하는 업계 동향과 급속한 기술 발전으로 악명이 높습니다. 업계는 AI의 출현으로 한 번 더 변화에 가속 페달을 밟았습니다. 하루에도 수십 편의 주요 논문이 쏟아지며, 주마다 각종 유수 연구실과 회사에서 앞다투어 새로운 모델을 발표합니다. 업데이트 속도는 이제 성실한 개인, 혹은 조직이 따라잡을 수 없는 영역이 되었습니다. 저희 팀은 ”급변하는 AI 산업 동향을 최소한의 노력으로 한 눈에 볼 수 없을까?”라는 질문을 던졌고, 답변으로 프로젝트 Redfin을 소개드립니다.

추진 배경

• 서비스 사용자가 효율적으로 AI 산업 동향을 파악할 수 있도록 지원
• 서비스 사용자가 효율적으로 관심 분야의 최신 기사를 접하고, 더 나아가 전문성을 기를 수 있도록 지원

목적

1

1. 프로젝트 개요

서비스 과제: AI 관련 기사 큐레이션 & 트렌드 인사이트 제공 시스템

주요 기능

A. “Project Redfin”

Q. “급변 AI 산업 동향을 한 눈에 볼 수 없을까?”

1. 맞춤형 뉴스 추천

​

• RSS 기반 글로벌 IT·AI 뉴스 피드에서 핵심 기사만 선별

​

• 사용자 관심사와 선호도에 맞게 자동 필터링 및 전달

​

• 방대한 정보 속에서 필요한 기사만 빠르게 확인 가능

​

​

2. 챗봇 기반 맞춤형 트렌드 인사이트

​

• 관심 이슈나 키워드를 입력하면 챗봇 대화형 인터페이스로 관련 트렌드 제공

​

• 매일 수많은 뉴스를 직접 탐색할 필요 없이,대화만으로 트렌드 파악 가능

​

• 페르소나를 활용한 프롬프트 엔지니어링으로 정책·산업·기술 등 다양한 분야의 종사자들이 자신이 속한 도메인의 언어로 설명된 트렌드를 제공 받음

3. RAG 기반 단위 기간별

트렌드 인사이트

​

• RAG를 활용하여 기간별/도메인별 트렌드 요약 제공

​

• 정부·기업·산업별 주요 이슈를 맥락 기반으로 분석해 깊이 있는 인사이트 확보

​

• 단순 기사 모음이 아닌, 의사결정 지원용 트렌드 리포트로 활용 가능

2

1. 프로젝트 개요

1-1. 팀원 및 역할 분담

2. 팀원 역할 분담

R&R 테이블

3

1.1. 팀원 및 역할 분담

1-2. 개발 환경

3. 개발 환경

기술 스택

4

1.2. 개발 환경

3. 개발 환경

기술 스택

5

1.2. 개발 환경

3. 개발 환경

기술 스택

6

1.2. 개발 환경

1-3. 프로젝트 일정

4. 프로젝트 일정

프로젝트 일정계획

Work Breakdown Structure

7

1.3. 프로젝트 일정

2. 서비스 기획

2-1. 메뉴 구조도

5. 서비스 기획

메뉴 구조도 (사이트맵)

8

2.1 서비스 기획

2-2. 기능 정의서

5. 서비스 기획

기능 정의서 (1/2)

9

2. 서비스 기획

5. 서비스 기획

기능 정의서 (2/2)

10

5. 서비스 기획

2-3. 정책 정의서

5. 서비스 기획

정책 정의서 (1/2)

11

5. 서비스 기획

5. 서비스 기획

정책 정의서 (2/2)

12

5. 서비스 기획

3. 업무 흐름도

Service Workflow

통합 업무 흐름도 (사용자)

13

3.1. 통합 흐름 업무도 (사용자)

통합 업무 흐름도 (관리자)

14

3.1. 통합 흐름 업무도 (관리자)

8. 업무 흐름도

애플리케이션 아키텍처 개요

데이터 흐름 요약

1. 외부 데이터 > Scrap API > MongoDB 적재
2. Label API로 컨텐츠 분석 및 태그 생성
3. Contents API > Next.js UI로 데이터 전달
4. RAG API를 토애 고급 검색/요약 기능 제공
5. Core(Spring Boot)는 MariaDB와 연계해 계정·관리 기능 담당

​

1. API 계층 (FastAPI 기반)

Redfin Scrap API: 외부 RSS/웹 데이터를 수집하여 MongoDB에 적재

3. 비즈니스 로직 계층

Refin Core (Sping Boot): 사용자 관리, 인증/인가,

서비스 코어 로직 수행

4. 프리젠테이션 계층

Redfin UI (Next.js) 웹 프론트엔드, API로부터 콘텐츠를 받아 �사용자에게 제공

2. 데이터 계층

요약문, 키워드, 태그, 카테고리 분류 등 ETL 중 Transformation 담당

15

3.2 서비스 아키텍처

4. 데이터베이스 설계

SQL & NoSQL DB 설계 및 구현

4-1. SQL 데이터베이스 설계

MariaDB 논리적 & 물리적 ERD

• Entity - Table Mapping

논리적 ERD 테이블 (2/3)

16

4.1. SQL 데이터베이스 설계

물리적 ERD 테이블

17

4.1. SQL 데이터베이스 설계

39

4-2. NoSQL 데이터베이스 설계

MongoDB 컬렉션 & 스키마

데이터베이스

몽고DB 도입 이유

문제 상황

• RSS 소스별 스키마가 가변/불완전�(필드 누락·중첩·배열·도메인별 불일치)
• 단기간 PoC/파일럿 필요, 초기 스키마 고정은 리스크
• 원본(raw) 보존 요구: 수집 시점의 JSON을 변경 없이 저장

​

선정 기준

• 가변 스키마 수용(Schema-flexible)
• JSON 네이티브 저장(Document/BSON)
• 빠른 적재와 업서트(idempotent)
• 간단한 인덱스 전략
• 수집 후 처리 파이프라인 친화성(ETL 상에선 전처리)�원본 → 정규화 → 색인

도입 효과

• 스키마 변화에 유연하게 대응
• 데이터 구조 변경에 따른 리팩토링 최소화
• 원본 보존성 극대화

트레이드오프 & 보완

• 회원가입, 회원별 컨텐츠 관리 등 예측 가능성이 높은 데이터는 RDB로 스키마 설계
• 데이터 중복성: 파이프라인 기준의 소스 오브 트루스(SOT)=raw 명확화

​

18

4.2. NoSQL 데이터베이스 설계

데이터베이스

몽고DB 관련 개념 (1/2)

MongoDB

• Document-oriented NoSQL
• 저장 포맷: BSON(JSON superset)
• 기본 키 _id(ObjectId), Collection 단위 관리
• 기능:
• 집계 파이프라인
• 인덱스(단일·복합·부분(Partial)·와일드카드(Wildcard)·�TTL·텍스트(Text)·지리공간(2dsphere))
• 트랜잭션(다문서 가능)
• ReplicaSet/Sharding

​

Document (문서)

JSON 유사 키-값 + 중첩/배열 구조. 한 기사 = 한 문서

​

​

용어

19

4.2. NoSQL 데이터베이스 설계

데이터베이스

몽고DB 관련 개념 (2/2)

MongoDB vs SQL

​

20

4.2. NoSQL 데이터베이스 설계

데이터베이스

몽고DB 컬렉션 설계

1. feeds : RSS 소스 메타데이터(1) 추가본

​

2. entries : RSS 기사 메타데이터 리스트(N) 추가본

​

3. entries_with_body (+extract): RSS 기사 원문 바디 텍스트(N) 추가본

​

4. summary_completion: 요약문(N) 추가본

​

5. keywords_completion: 키워드 리스트(N) 추가본

​

6. articles: 카테고리(1), 태그 리스트(N) 추가본

​

7. news_logs: RAG 생성 뉴스 추가본

21

4.2. NoSQL 데이터베이스 설계

데이터베이스

몽고DB 컬렉션 스키마

feeds

• site_url: RSS Feed 소스 링크
• title: title이 없을 경우, site_url로 대체
• _id : MongoDB 상 개별 피드 고유 식별자
• created_at: 생성 일자

22

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

entries

• entry_key
• authors
• domain
• feed_url
• summary
• title
• updated
• created_at
• mirrored_at
• published

​

feeds > entries > summary > keywords > tags > category > articles

23

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

entries_with_body: 2차 크롤링 이후 기사원문 추가 컬렉션

• guid
• source
• title
• link
• pub_date
• author
• category
• scraped_at
• body_text
• body_text_length
• summary
• _id
• tags

feeds > entries > summary > keywords > tags > category > articles

24

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

extract

• guid
• source
• title
• link
• article_text
• summary
• content_type
• language
• readability_score
• processed_at
• text_lenth
• _id
• tags
• key_entitites

​

feeds > entries > summary > keywords > tags > category > articles

25

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

summary_completion

• guid
• source
• title
• link
• pub_date
• description
• author
• category
• group
• scraped_at
• description_word_count
• body_text
• body_text_length
• _id
• tags

​

feeds > entries > summary > keywords > tags > category > articles

26

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

keywords_completion

• guid
• source
• title
• link
• pub_date
• description
• author
• group
• scraped_at
• description_length
• body_text
• body_text_length
• _id
• tags
• keywords

​

feeds > entries > summary > keywords > tags > category > articles

27

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

articles

• Title
• Summary
• keywords
• category
• URL
• body
• published_at
• updated_at
• created_at
• _id
• tags

feeds > entries > summary > keywords > tags > category > articles

28

4.2. NoSQL 데이터베이스 설계

feeds > entries > summary > keywords > tags > category > articles

데이터베이스

몽고DB 컬렉션 스키마

new_logs

• post_id
• article_id
• article_code
• url
• title
• dek
• body_md
• hero_image
• author_name
• category
• status
• _id
• tldr
• categories
• tags
• sources
• model_data
• created_at
• published_at

29

4.2. NoSQL 데이터베이스 설계

데이터베이스

몽고DB 컬렉션 스키마

rag_logs

• endpoint
• status
• error
• _id
• created_at
• envelope
• extra

30

4.2. NoSQL 데이터베이스 설계

5. 주요 화면

Primary Screen

Action

Validation

Description

7. 주요 화면 명세서 (로그인)

A3

V1

A1

A2

A5

A4

V2

A6

31

5. 주요 화면 (로그인)

Action

Validation

Description

7. 주요 화면 명세서 (로그인)

A1

A2

A3

A4

A5

V1

V2

V3

32

5. 주요 화면 (로그인)

7. 주요 화면 명세서 (트렌드 챗봇)

Action

Validation

Description

A1

V1

33

5. 주요 화면 (로그인)

7. 주요 화면 명세서 (트렌드 챗봇)

Action

Validation

Description

A1

V1

34

5. 주요 화면 (트렌드 챗봇)

7. 주요 화면 명세서 (트렌드 챗봇)

Action

Validation

Description

V1

A1

A2

A3

A4

A5

A6

A7

35

5. 주요 화면 (트렌드 챗봇)

7. 주요 화면 명세서 (하이라이트)

Action

Validation

Description

A1

A1

V1

36

5. 주요 화면 (하이라이트)

7. 주요 화면 명세서 (카테고리별 조회)

Action

Validation

Description

C1

V1

A1

A2

A3

A4

V2

Code

37

5. 주요 화면 (하이라이트)

7. 주요 화면 명세서 (소스별 커버리지)

Validation

Description

C1

Code

V1

38

5. 주요 화면 (소스별 커버리지)

7. 주요 화면 명세서 (메인 페이지)

Action

Code

Description

A2

A1

A3

A4 ~ A7

A8 ~ A11

A12 ~ A15

C1

39

5. 주요 화면 (메인 페이지 메뉴)

7. 주요 화면 명세서 (단일 기사 상세)

Code

Validation

Description

V1

V2

C1

40

5. 주요 화면 (단일 기사 상세)

7. 주요 화면 명세서 (단일 기사 상세)

Action

Validation

Description

C1

A1

A2

A3

A4

A5

A6

A7

V1

V1

41

5. 주요 화면 (단일 기사 상세)

7. 주요 화면 명세서 (회원가입)

Action

Validation

Description

A3

A1

A2

A2

A4

A5

A6

A7

A8

42

5. 주요 화면 (회원가입)

39

6. 주요 기능

Extract, Transform, Load

39

6-1. ETL 파이프라인

Extract

ETL 파이프라인 / 데이터

RSS 데이터 구조

RSS 문서 전체를 흔히 지칭하는 일반 표현

RSS 용어에서는 Feed = RSS 문서 전체를 흔히 지칭하는 일반 표현

역할: 구독자가 RSS 리더를 통해 해당 Feed를 불러와 최신 컨텐츠 확인 가능

주요 요소:

- channel (피드의 전체적인 정보: 제목, 설명 링크 등)

- link (원본 웹사이트 주소)

- title (피드 이름

description (피드 설명)

Feed

eed ≒ RSS 문서 ≒ Channel + Items�웹사이트의 최신 콘텐츠(뉴스, 블로그 글 등)를 구독 가능한 XML 문서 형태로 배포하는 기술.

​

​

• 정의: RSS 문서의 최상위 블록으로 RSS 문서의 헤더 역할
• 피드(=RSS 문서) 자체의 메타데이터를 담음.
• 이 RSS 문서는 어떤 사이트의 어떤 주제에 대한 것인지” 설명.
• 예시 요소:

`<title>`, `<link>`, `<description>`, `<language>`, `<lastBuildDate>`

Channel

Entries(=items)

43

6. ETL 파이프라인 / 데이터

​

• 정의: “기사 하나, 글 하나”를 의미. �Feed 안에 포함된 개별 컨텐츠�(뉴스 기사, 블로그 글, 팟캐스트 등)
• 역할: 사용자가 실제 개별 포스트를 표현
• 주요 요소:

title(글제목), � link(원본 글 링크), � description(요약이나 본문 일부), � pubDate(발행일), � author(작성자), � guid(고유ID)

​

ETL 파이프라인 / 데이터

RSS 데이터 구조 - Feed Source 관리

OPML (Outline Processor Markup Language)

​

RSS 피드 목록을 구조화해 저장하는 XML 기반 포맷

​

여러 개의 RSS 피드를 그룹별로 정리하여 관리 가능

(예: AI / Tech, Korea Frontier 등)

​

각 outline 요소는 하나의 RSS 피드를 나타냄

- text: 피드 이름

- xmlUrl: 실제 RSS URL

- title: 표시될 제목 (선택적)

RSS.opml

44

6. ETL 파이프라인 / 데이터

ETL 파이프라인 / 수집기

RSS 리더

여러 사이트의 RSS 피드를 모아 한 곳에서 기사/컨텐츠 구독할 수 있는 도구

​

사용 목적:

다양한 출처의 뉴스를 실시간으로 수집

사용자가 직접 방문하지 않아도 최신 정보 자동 확인 가능

뉴스 분석, 추천 시스템, 데이터 수집 자동화에 활용

다수의 뉴스 사이트 RSS 피드를 자동으로 크롤링

수집한 기사 데이터를 JSON 형식으로 저장 및 제공

AI 분석 및 기사 추천에 활용하기 위한 전처리 기반 구축

Lemon24◉RSS Reader

45

6. ETL 파이프라인 / 수집기

ETL 파이프라인 / 스케줄러

Airflow

1. Airflow의 개요

• Airflow는 ETL 파이프라인 및 스케줄러로, 여러 사이트의 RSS 피드를 한 곳에 모아 뉴스/컨텐츠를 자동으로 수집·관리하는 역할
• 단순 크롤링을 넘어서, 주기적인 실행 관리, 실패 재시도, 워크플로우 의존성 관리를 체계적으로 할 수 있음

​

2. 주요 사용 목적

• 다양한 뉴스 출처에서 데이터를 실시간 자동 수집
• 사용자가 직접 방문하지 않아도 최신 정보 동기화 가능
• 수집된 데이터는 뉴스 분석, 추천 시스템, 데이터 자동화 파이프라인에 곧바로 활용 가능

​

3. 구성요소

• Scheduler & Executor: DAG(작업 흐름)를 주기적으로 실행
• Metadata DB: 워크플로우 실행 상태, 로그, 히스토리를 관리
• Workers & Trigger: 실제 작업(크롤링, 데이터 처리)을 실행하는 엔진
• API Server: 외부에서 Airflow를 제어하거나 모니터링할 수 있는 인터페이스

​

46

6. ETL 파이프라인 / 스케줄러

39

6-1. ETL 파이프라인

Transform

ETL 파이프라인 / 전처리 / 요약

요약 생성 (1/2)

요약 모델: facebook/bart-large-cnn, Sentence Transformer (DL)

Bidirectional and Auto-Regressive Transformers의 대규모 버전.

CNN/Daily Mail 데이터셋에 특화된 텍스트 요약 생성 모델

양방향 인코더와 자동 회귀 디코더를 결합한 트랜스포머 구조

​

​

전통 요약: 문서 → 키워드 추출 → 중요 문장 선별 → 요약 생성

BART 요약:

텍스트를 의도적으로 손상(마스킹, 삭제, 순서 변경)

손상된 텍스트에서 원본 복원 학습

질의 시 전체 문맥을 이해하여 추상적 요약 생성

​

핵심 개념

​

​

긴 문서도 핵심 내용을 압축하여 요약

원문에 없는 표현으로도 요약 가능

CNN/Dail Mail 뉴스 도메인에서 높은 ROGUE 점수

장점

​

1024 토큰 길이 제한, 영어 텍스트 최적화, 높은 계산 비용(406M)

단점

47

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인 / 전처리 / 요약

요약 생성 (2/2)

토크나이저 모델 구현: facebook/bart-large-cnn, Sentence Transformer

​

48

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인 / 전처리 / 키워드

키워드 추출 (1/2)

키워드 알고리즘: YAKE

Yet Another Keyword Extractor로, 외부 코퍼스나 사전 훈련 없이 통계적 특성만으로 키워드를 추출하는 비지도 학습 알고리즘

​

핵심 개념

• 전통 키워드 추출: TF-IDF → 빈도 기반 → 상위 N개 키워드 선별
• YAKE 키워드 추출
1. 5가지 통계 특성 계산(빈도, 위치, 문맥, 분산성, 상대빈도)
2. 각 특성을 조합하여 키워드 스코어 산출
3. N-gram 단위로 중요도 순위화하여 키워드 추출
• 장점
• 실시간 처리 가능 (사전 훈련 불필요)
• 다국어 및 도메인 독립적 작동
• 파라미터 조정으로 유연한 최적화
• 단점
• 문맥적 의미 이해 한계
• 복합어나 전문용어 처리 제약
• 짧은 문서에서 성능 저하 가능

49

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

키워드 추출 (2/2)

YAKE 구현

50

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

태깅 - 태그 체계

기사의 메타데이터 (제목, 요약, 키워드)를 기반으로,� 맞춤형 인스트럭션 규칙을 적용하여 태깅 생성

​

태그 체계 (제어 사전 + 자유 태그 혼합)

제어 사전 예시:

확장된 제어 사전을 활용하여 우선적으로 태그를 생성하고,� 태깅이 부재할 경우 기사 메타데이터와 Ollama를� 기반으로 태그를 보완 생성

51

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

태깅 - 태그 체계

• 제어사전(Controlled Vocabulary): 품질 보장을 위한 핵심 축

​

​

​

​

​

​

​

​

​

​

​

​

• 자유 태그(Free tags):
• 트렌드/신조어 반영. 큐레이터 검수로 제어 사전 편입 여부 판단
• 확장된 제어 사전을 활용하여 우선적으로 태그를 생성하고,
• 태깅이 부재할 경우 기사 메타데이터와 Ollama로 기반으로 태그를 보완 생성

52

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

태깅 - 태그 모델

Ollama Fine-tuning

​

- LLM(대형 언어모델)을 특정 도메인에 맞게 미세 조정

- 태그/요약/분류/ 등 ETL 태스크에 특화된 지식 반영

- 기존 Pretrained 모델 위에 추가 학습 → 빠른 수렴, 적은 데이터로도 성능 향상

SimCLR(Self-Supervised Contrastive Learning)

​

- 레이블 없는 데이터를 활용한 학습 기법

- 데이터 증강 → 같은 입력의 다른 표현(Positive pair) / 무관한 입력(Negative pair)

- 임베딩 공간에서 유사도 학습 → 태그·요약·검색 정확도 향상

Ollama Fine-tuning / SimCLR 모델 학습 과정 (LLM)

53

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

태깅 - 태그 로직

규칙 우선 (Rule-first)

• fast_match_tags(title, content, vocab)
• 제목+본문을 소문자화 → 정규식(\b ... \b)로 완전 단어 일치 탐지
• 제어 사전 vocab의 cat → [terms]를 순회, 히트 시 “cat/term” 추가
• dict.fromkeys()로 중복 제거 → O(|V|) 선형 탐색, 빠르고 결정적

​

LLM 보완 (Generation)

• user_prompt
• 입력:
• existing(규칙으로 이미 찾은 태그),
• vocab_text(제어 사전 슬라이스),
• yake_text(YAKE 키워드)
• 요구사항:
• 남은(remaining) 새로운 태그만,
• 정확한 문자열(카테고리/키워드 형식),
• 중복 없음, 영문만, 없으면 []

​

• ollama_chat_safe(model_name, ..., )
• 시스템+유저 메시지로 JSON-only 가드레일
• 파서 실패 대비 예외 처리(빈 배열 반환)

54

6.1. ETL 파이프라인 / 전처리

ETL 파이프라인

카테고리 분류 - 체계

MECE(Mutual Exclusive Collectively Exhaustive)

데이터를 중복 없이(배타적, ME), 누락 없이(포괄적, CE) 분류하기 위한�사고 프레임워크

​

적용 이유:

• 데이터 중복/누락 없이 구조화 가능
• 카테고리 정의가 명확해져 ETL 파이프라인에서 일관성 유지
• 분석·검색·추천 시스템의 정확도와 해석력 향상

​

최상위 6대 카테고리:

​

1. Research (학술)

논문, 프리프린트, 학회 성과, 벤치마크/데이터셋

핵심 메시지가 연구 성과일 때

​

2. Technology & Product (기술/제품)

모델 제품 릴리스, 성능 업데이트, 기능 변경

제품/기능 전달이 핵심일 때

​

3. Market & Corporate (시장/기업)

투자, M&A, IPO, 실적, 조직 개편, 제휴·상용화

금액 거래 지배구조가 중심일 때

​

4. Policy & Regulation (정책/규제)

법·규제·가이드라인, 보조금, 수출·통제, 표준화

공공 주체의 규제/지원이 핵심일 때

​

5. Technology & Product (기술/제품)

대중 활용, 창작/교육, 밈, 사회적 논의(정책 전 단계)

사회적 파급 수용이 중심일 때

​

6. Incidents & Safety (사건/안전/운영)

서비스 장애, 보안 사고, 오남용, 리콜/중단

55

6.1. ETL 파이프라인 / 전처리

39

6-2. 추천 시스템

Recommendation System

추천 시스템

개요

​

​

rec/research

추천 기사 검색 시 코사인 유사도를 활용하여 쿼리 (단어 및 문장)과 가장 높은 유사도를 지닌 �상위 k개의 기사 인덱스

• Input: (query) 검색 단어, (k) 상위 k개의 추천 기사
• Output: 추천 기사 메타데이터 (title, keywords, summary, body_text) + 코사인 유사도 점수

​

rec/index

새로운 기사의 임베딩 생성 후 article_recommender 인덱스에 저장 혹은 원래 있는 기사의 임베딩 업데이트

• Input:
• redindex: 임베딩 재생성 여부
• filepath: article_recommender 인덱스에 임베딩 후 추가하고 싶은 뉴스 기사 경로
• Output:
• 인덱스 생성 개수

추천 시스템 소개

1. all-MiniLM-L6-v2 모델을 이용하여 기사들의 메타데이터를 semantic embedding

2. 처리된 임베딩 벡터들을 Elasticsearch 인덱스인 article_recommender에 저장

​

기술 스택 요약

임베딩: all-MiniLM-L6-v2 (SentenceTransformer)

인덱싱/검색: Elasticsearch

​

목표

쿼리 기반 의미적 유사 기사 추천

​

56

6.2. 추천 시스템

추천 시스템

흐름 순서

​

​

전체 흐름

데이터 로드

JSON/JSONL 파일에서 기사 메타데이터 읽기

임베딩

메타데이터와 기사 요약문

임베딩

인덱싱

메타데이터와 임베딩을 Elasticsearch에 저장

검색

사용자 쿼리로 유사한 기사 검색

57

6.2. 추천 시스템

추천 시스템

데이터 준비

​

​

데이터 소스

• JSON/JSONL 파일 RSS 메타 데이터

​

처리 과정

• load_jsonl_data: 파싱 및 오류 처리
• generate_embedding: all-MiniLM-L6-v2로 384차원 임베딩 생성

​

출력

• 메타데이터

58

6.2. 추천 시스템

추천 시스템

임베딩

​

​

색인화를 통한 검색 최적화

• 기사의 메타데이터 (제목, 요약, 키워드)를 기반으로,
• 맞춤형 인스트럭션 규칙을 적용하여 카테고리 생성

​

프로세스

• generate_embedding: all-MiniLM-L6-v2로 384차원 임베딩 생성

​

​

결과

• 임베딩 데이터

59

6.2. 추천 시스템

추천 시스템

인덱싱

​

​

색인화를 통한 검색 최적화

• 기사의 메타데이터 (제목, 요약, 키워드)를 기반으로,
• 맞춤형 인스트럭션 규칙을 적용하여 카테고리 생성

​

프로세스

• create_index: 인덱스 생성 및 매핑 정의(dense_vector: text)
• index_articles: 메타데이터 + 임베딩 청크 단위 저장

​

적용 기술

• Elasticsearch ‘bulk’ API

​

결과

• 구조화된 기사 데이터 인덱스

60

6.2. 추천 시스템

추천 시스템

검색

​

​

추천 기사 반환

• 검색어를 이용하여 Elasticsearch 인덱스에서 코사인 유사도 사용
• 상위 k개의 기사의 title, keywords, summary 반환

​

프로세스

• search_recommendation: 쿼리 임베딩 생성
• 코사인 유사도 기반 script_score 쿼리

​

처리 과정

• Elasticsearch 검색

​

출력

• top_k 유사 기사 (guid, title, score)

61

6.2. 추천 시스템

추천 시스템

기술 스택

​

​

임베딩

• all-MiniLM-L6-v2 (SentenceTransformer) 384차원 벡터 변환

​

​

​

​

​

​

​

인덱싱/검색

• Elasticsearch: 데이터 저장 및 코사인 유사도 검색

​

62

6.2. 추천 시스템

추천 시스템

결과 요약

​

​

데이터 소스

• RSS 메타데이터 기반 의미적 추천 구현
• top_k 유사 기사 성공적 반환

​

한계

기사 원문 미포함으로 정밀도 제한

​

추후 방향성

원문 통합, 카테고리 기반 필터링 추가

63

6.2. 추천 시스템

추천 시스템 / 정보 검색 알고리즘 선정

정보 검색 / 유사도 모델 - TF-IDF

TF (Term Frequency)

문서 내 특정 단어가 얼마나 자주 등장하는지를 나타내는 수치

높을수록 해당 문서가 쿼리와 더 연관성이 있을 수 있음

​

IDF (Inverse Document Frequency)

코퍼스 전체에서 얼마나 희귀한 단어인가를 측정

흔하게 나타나는 단어일수록 중요도가 낮다고 간주하고 가중치를 낮게 부여

​

전체 가중치 계산 방식

기본적인 TF-IDF는 TF x IDF로 계산됨

Elasitcsearch(이하 ES)에서는 이 값을 통해 relevancy score를 계산하고, 문서 간 순위를 매깁니다.

​

ES 알고리즘 변경

ES 5.0 버전부터는 기본 유사도 모델이 BM25로 변경됨

​

검색

검색이란 사용자가 입력한 검색 쿼리에 대해 관련 있는 문서를 매칭한 후,

관련성에 따라 정렬하는 과정이다.

​

관련성(relevance)

주어진 쿼리와 매핑되는 문서를 관련된 정도에 따라 수치화한 값으로

검색 점수(score)

​

​

64

6.2. 추천 시스템 / 정보 검색 알고리즘

추천 시스템 / 정보 검색 알고리즘 선정

all-MiniLM-L6-v2

개요

• 프레임워크: SentenceTransformer
• 아키텍처: TF 기반 MiniLM, DistilBERT 계열 경량화 모델)
• 용도: 문장 임베딩(sentence embedding) 생성
• 활용: 의미 기반 검색(Semantic search), 클러스터링, 분류 등

​

주요 특징

• 속도: 경량화 모델로 GPU/CPU에서 빠른 추론이 가능하여 RAG 시스템에 적합
• 정확도: 작은 모델이지만 Semantic Textual Similarity(STS) 벤치마크에서 높은 성능(≈ 85점대) 달성
• 출력 차원: 384차원 → 저장 공간 및 벡터 검색 효율성이 뛰어남
• 다목적성: “all” 시리즈는 일반적인 문장 표현 학습을 목표로 QA, 검색, 클러스터링 등 범용적 활용이 가능

​

활용 사례

• Semantic Search: 검색 키워드와 문서 간 의미 기반 매칭
• RAG: 임베딩 DB(FAISS, Chroma)에 벡터 저장 후 LLM과 결합
• 문서 군집화: 의미적으로 유사한 문서 자동 그룹핑
• 추천 시스템: 사용자 입력/컨텐츠 임베딩 기반 추천

65

6.2. 추천 시스템 / 임베딩 모델

39

6-3. RAG

Retrieval-Augmented Generation

RAG 시스템

RAG란?

검색 증강 시스템

개념: 외부 지식베이스(문서, DB 등)에서 관련 정보를 검색한 뒤, LLM에 함께 제공하여 답변의 정확성과 신뢰성을 높이는 방식

​

구성 요소

• Retriever(검색기): 사용자의 질문과 관련된 문서를 찾아옴
• Generator(생성기): 검색된 문서를 바탕으로 답변을 생성

​

장점

• 최신 정보 반영 가능
• 환각(Hallucination) 감소
• 특정 도메인에 맞춤형 활용 용이

​

활용 예시

• 고객 상담 챗봇
• 내부 문서 검색/QA
• 뉴스 요약 및 리포트 생성

출처: OpenAI Cookbook

66

6.3. RAG 시스템

RAG 시스템

RAPTOR

Recursive Abstractive Processing for Tree-Organized Retrieval

트리로 구성된 검색을 위한 재귀적 추상 처리

​

핵심 개념

• 전통 RAG: 쿼리 → 리트리버에서 k개 문서 검색 → LLM으로 답변 생성

​

• RAPTOR RAG:

1. 문서를 세밀하게 리프 청킹

2. 상위 레벨 요약 노드 생성(트리 구조)

3. 질의 시 트리를 따라 상·하위 요약을 결합해 응답

​

장점

- 단순 RAG 대비 계층적 요약 구조를 활용하여 더 안정적이고 맥락 충실한 답변을 생성

- 긴 문서에서도 핵심 정보 유지

- 정보 손실 최소화

- 응답 일관성 및 신뢰도 향상

​

단점

- 인덱싱 비용 증가(요약 생성 단계 필요)

- 질의 처리 속도 상대적으로 느림

​

​

출처

[Submitted on 31 Jan 2024]RAPTOR: Recursive Abstractive Processing for Tree-Organized RetrievalParth Sarthi, Salman Abdullah, Aditi Tuli, Shubh Khanna, Anna Goldie, Christopher D. Manning

67

6.3. RAG 시스템

RAG 시스템

RAG 흐름 순서

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

사용자 프롬프트 입력 시점

오프라인 경로

온라인 경로

68

6.3. RAG 시스템

RAG 시스템

Data Load

데이터베이스(database): redfin

컬렉션(collection): extract

“Document 단위로 데이터 저장"

"각 Document는 guid, title, summary 등 다양한 필드로 구성"

article_text = LLM에 입력할 “기사 본문 텍스트”

​

즉, 이 필드는 요약·분석·답변 생성을 위해 LLM 프롬프트에 전달되는

주요 컨텐츠(payload) 역할을 합니다.

69

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chunking

개요: 청킹과 인덱싱은 RAG 성능의 핵심.

RAPTOR 적용 여부에 따라 전략이 달라짐.

indexing.py

70

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Embedding

Embedding Model

왜 영어 전용 임베딩으로 BGE를 선택했는가?

​

1. 검증된 성능 (MTEB 기준)

small/base/large모델 모두 OpenAI ada보다 높은 평균 accuracy (≈62–64%)

→ 효율적인 리소스 사용 대비높은 검색 품질 확보

​

2. 성능과 지연의 균형

BGE-base는 latency(≈79–82 ms)와 accuracy(≈84–85%) 간균형적인 우수 모델

→ 실시간 RAG 서비스에 적합한 “그램당 성능 대비 처리 속도”

​

3. 오픈소스의 장점 + 합리적 성능

BGE large (≈71.5% accuracy)는 상용 OpenAI 대비 약 5–10% 성능 하락,

비용 없이 로컬 사용 가능이라는 무시할 수 없는 이점

출처

https://blog.vespa.ai/bge-embedding-models-in-vespa-using-bfloat16/?utm_source=chatgpt.com

https://supermemory.ai/blog/best-open-source-embedding-models-benchmarked-and-ranked/?utm_source=chatgpt.com

https://www.tigerdata.com/blog/open-source-vs-openai-embeddings-for-rag?utm_source=chatgpt.com

출처: supermemory.ai 블로그

71

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Embedding

- 비용 효율: 자체 호스팅 가능(오픈소스) → 대량 임베딩 시 TCO 유리, API 과금 의존↓

​

- 저지연: 로컬 추론이라 p50 수십 ms대로API 대비 크게 빠름(테스트에서도 확인)

​

- 인덱스/메모리 효율: 768d 기준 인덱스가 작고 검색 속도 안정 → 대규모 확장에 유리

​

- 성능 균형: 영어 뉴스 RAG에서 정확도 손실 없이 실용적 성능, 필요 시bge-large로 업스케일 가능

bge-base-en-v1.5

Embedding Model

BGE계열 모델

72

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Indexing

RAG 인덱싱 메타데이터(ChromaDB 저장 스키마)

​

“뉴스 문서를 청킹·요약한 뒤 원문 식별 정보 + 검색 속성 + RAPTOR 계층 정보를 메타데이터로 함께 인덱싱합니다.”

​

​

- 식별/출처: doc_id(guid/_id), source, link, published, authors, tags

​

- 수집 경로: ingest_source(http|mongo), source_collection(extract)

​

- RAPTOR 계층(선택): raptor_level, node_type(summary|leaf), cluster_id

indexing.py

73

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

ChromaDB

ChromaDB 기반 RAPTOR 트리 인덱싱

​

ChromaDB 역할

- 임베딩 벡터 저장소(Vector DB)로서 문서/요약 노드의 임베딩 관리

- collection 단위로 RAPTOR 트리 계층(루트 요약 → 중간 요약 → 원문 청크) 저장

- cosine 유사도 기반 k-NN 검색 지원

로컬 VectorDB

vectorstore.py

74

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > VectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

사용자 입력 프롬프트

Query

사용자 입력 프로프트 단계

​

원하는 주제, 이슈, 트렌드를 질문으로 입력하는 단계

​

75

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Retriever

쿼리에 맞는 관련 문서를 벡터DB에서 찾아주는 검색 단계

Retriver 매개변수

​

- fetch_k: “최초로 불러오는 후보 문서 개수 (검색 풀 크기)”

​

- k: “LLM에 최종 전달할 문서 개수”

​

- λ (lambda_mult): “MMR 재랭킹 시 유사도(정확성) vs 다양성(coverage) 균형 조정 (0=유사도, 1=다양성)”

Golden “Retriever”

76

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chain

LangChain의 Chain

Chain = LLM 호출 절차를 모듈화한 파이프라인

​

LangChain의 체인 → 유닉스 파이프라인(|)처럼 단계 연결

​

각 단계는 독립적·재사용 가능, 필요에 따라 쉽게 교체·조합

“LangChain에서 체인은 LLM 호출을 일관되고 확장성 있게 관리하는 핵심 추상화”

chain.py

77

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chain

Stuff 체인

​

검색된 문서를 한 번에 통째로 LLM에 넣고 답변을 생성하는 방식

​

가장 단순한 RAG 체인

Map-Refine 체인

​

Map 단계: 각 문서별로 부분 답변을 먼저 생성

​

Refine 단계: 초기 답변을 바탕으로 문서를 순차적으로 읽으며 점진적으로 보완·수정

​

CoD 체인 (Chain of Density)

​

답변을 여러 차례 생성하며 밀도를 점점 높여 내용을 압축

​

초안에서 핵심 요약 → 반복적으로 누락된 디테일 추가 → 최종적으로 짧지만 정보가 풍부한 결과물 생성

요약 답변 기능에서 체인 기법

출처

Huang et al.,“Chain-of-Density: Iterative Information Densification for Summarization with LLMs”(2023, arXiv:2309.04269)

78

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chain

Stuff chain

chain.py

Stuff 체인 (한 번에 입력)

​

- 모든 검색 문서를 한꺼번에 프롬프트에 삽입해 LLM 응답 생성

​

- 가장 단순하고 빠른 전략

​

- 소규모 문서 집합, 간단 질의에 적합

​

- 토큰 한계에 쉽게 부딪히며, 대규모 데이터에는 부적합

[문서 A, B, C] → (프롬프트 삽입) → [LLM] → [응답]

​

79

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chain

Map-Refine chain

chain.py

Map-Refine 체인 (순차 요약/정제)

​

- 각 문서를 개별 요약(Map) 후, 순차적으로 결합·정제(Refine)하여 최종 응답 생성

​

- 긴 문서 처리 가능, 품질이 상대적으로 높음

​

- 문서 수만큼 LLM 호출이 늘어나 속도가 느릴 수 있음

문서 A → 요약 ┐

문서 B → 요약 ├─▶ [Refine 단계: 순차 결합/정제] → 최종 응답

문서 C → 요약 ┘

​

80

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Chain

CoD chain

chain.py

CoD 체인 (고밀도 응답)

​

- 초기 요약을 만든 뒤, 불필요·중복 정보를 제거하며 반복적으로 압축

​

- 핵심만 남기는 고밀도 응답 생성

​

- 토큰 효율이 높고 정보 손실 최소화

​

- 구현이 복잡하며 지나친 압축 시 문맥 손실 위험

[초기 요약] → [불필요 요소 제거] → [압축 반복] → [고밀도 응답]

81

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

7가지 사용자 페르소나 정의

PromptEngineering

​

​

​

AI 관심 일반인

기본 지식은 부족하지만 생활 속 AI 활용에 관심. → 쉬운 설명, 실생활 예시, 핵심 요약 필요.

​

​

​

​

AI 산업 종사자

기업 실무/기획/엔지니어링 종사. → 최신 기술, 기업 전략, 사례, 동향 정보 필요.

​

​

​

​

AI 관심 공무원

정책·규제 담당. → 정책/규제 동향, 글로벌 기준 비교, 사회 영향 정보 필요.

​

​

​

AI 스타트업 CEO

사업화·투자 집중. → 시장·투자 트렌드, 경쟁사 분석, 차별화 포인트 필요.

​

​

​

​

AI 정보 크리에이터

유튜브·블로그 등 운영. → 최신 뉴스 요약, 콘텐츠 소재, 재가공하기 쉬운 자료 필요.

​

​

​

대학(원)생/연구자

논문·연구 집중. → 최신 논문 요약, 학계·산업 동향 비교, 학습 참고자료 필요.

​

​

​

투자자/VC

투자 기회 발굴. → 투자 라운드, 시장 전망, 기술 상용화 가능성, 경쟁 구도 정보 필요.

+ .md(마크다운 파일)

+ .md(마크다운 파일)

+ .md(마크다운 파일)

+ .md(마크다운 파일)

+ .md(마크다운 파일)

+ .md(마크다운 파일)

+ .md(마크다운 파일)

82

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

7가지 사용자 페르소나 정의

PromptEngineering

system_insight.md

+

시스템 프롬프트

페르소나별 템플릿 프롬프트

(마크다운 형식)

7가지 페르소나

83

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

메인 LLM

API 형태로 LLM 호출

처음 시도한 모델

​

Gemini 2.0 Flash (무료 플랜)

​

장점: 최신 모델, 무료 사용 가능

한계:무료 플랜의 RPM(분당 요청 수) 제한→ 서비스 거절 발생

​

​

대체 모델

​

OpenAI GPT-4.1 Mini (유료)

​

장점: 안정적 호출, 저비용, 빠른 응답

결과: 프로젝트에서 안정적 운영 가능

의미

모델 선택은 단순 성능이 아닌비용·제약·지연까지 고려해야 함

실제 서비스에서는성능과 운영 안정성의 균형이 핵심

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

84

6.3. RAG 시스템

DataLoad > Chunking > Embedding > Indexing > vectorDB > Query > Retriever > Chain > Persona > LLM

RAG 시스템

Langsmith

RAG 체인을 모니터링하고 평가하는 도구

📑 redfin_target-insight

사용자 질의 RAG 파이프라인

- 사용자 쿼리 수신 → 쿼리 정규화 및 임베딩

- ChromaDB에서 MMR 기반 검색(fetch_k, k, λ 조정)

- 검색된 컨텍스트를 체인에 결합하여 LLM 응답 생성

- 전략 자동 선택(Stuff / Map-Refine / CoD / Refine 등) 적용

- 응답과 함께 출처·근거(chunk metadata)를 반환

- LangSmith에서 리트리버 성능, 체인 전략, 응답 품질을 실행 로그 단위로 추적

역할: 검색 증강 질의응답 성능 모니터링 및 전략 검증

​

📑 redfin_news-publish

뉴스 출간 자동화 파이프라인

- 외부 뉴스 소스(JSON API, Mongo 등)에서 기사 수집

- 문서 청킹 및 (선택) RAPTOR 요약 적용 후 ChromaDB 인덱싱

- LLM을 활용해 기사 요약·본문(body_md) 자동 생성

- 최종 결과를 MongoDB(news_semantic_v1)에 저장, API(/redfin_news/posts)로 제공

- LangSmith에서 기사 출간 과정(로드 → 요약 → 저장)을 체인 단위로 추적

역할: 자동 요약·출간 파이프라인 모니터링 및 품질 관리

LangSmith는 LangChain 기반 애플리케이션의 실행 추적·모니터링·평가를 제공하는 플랫폼입니다. 체인/에이전트의 입력→중간 단계→출력을 실시간 기록하고, 품질을 정량·정성으로 평가할 수 있습니다.

85

6.3. RAG 시스템

RAG 시스템

Langsmith

• - map_refine 방식에서 너무 느린 응답 시간 최적화(2025-09-02)

원인: map_refine의 Map 단계에서 문서별 LLM 호출을 직렬로 돌기 때문

​

해법: 시간을 줄이는 1순위 해법은

chain.py에서.invoke()반복을 batch/abatch병렬화로 바꾸는 것

기존 50~ 80초대로 나오는 응답 시간이 20~30초대로대폭 줄어든 것을 확인할 수 있음.

RAG 체인을 모니터링하고 평가하는 도구

문제 사진: 응답시간 61.02 sec

86

6.3. RAG 시스템

RAG 시스템

RAG API (FastAPI)

컴포넌트와 계약

엔드포인트:POST /redfin_target-insight

[Client]

→ FastAPI(CORS, Depends, lifespan)

→ Retriever(Chroma: k/fetch_k/λ, 필터)

→ LLM Chain(프롬프트·페르소나·전략 선택)

→ Response(Answer + citations)

​

↘ Mongo Logs, ↘ LangSmith Tracing

요청 계약 (QueryRequest)

​

question: str — 사용자 질문

persona: Optional[str] — 페르소나(없으면 auto)

strategy: "auto"|"stuff"|"map_refine"|"cod" — 체인 전략

top_k: int — 최종 반환 문서 수

fetch_k: int — MMR 후보군 크기

lambda_mult: float — MMR λ(0=다양성↑, 1=유사도↑)

user_id: Optional[str] — 회원ID(없으면 "notuser")

응답 계약 (QueryResponseV1)

​

data.answer.text | bullets? | format="markdown"

data.persona / data.strategy

data.sources[] = {doc_id, title, url?, snippet?, score?}

meta.user / meta.request / meta.pipeline

​

response.py

query.py

87

6.3. RAG 시스템

RAG 시스템

RAG API (FastAPI)

지표, 로그와 운영 포인트

RAGAS는

“추후 도입 예정(Faithfulness/Relevancy 자동평가)”

API가 기록하는 메타(실시간)

​

- trace_id,latency_ms(E2E/단계별), token_usage{prompt, completion, total}

- selected_strategy,top_k/fetch_k/lambda

- candidate_docs[](doc_id, score),used_sources[](doc_id)

- error_code,retry_count

​

⇒역할:“지표 산출의 원본 신호(telemetry)”

- 응답 스키마의 meta블록에 trace_id, latency_ms, token_usage, selected_strategy, top_k/fetch_k/lambda, used_sources등을 채워서 반환 + Mongo에 동일 구조로 로깅

​

- LangSmith 트레이싱(기능별, 랭스미스 프로젝트별 분리)

대시보드/오프라인에서 산출하는 지표

​

품질:Hit@k, Source Coverage, (간이) Answer–Query 유사도, 사용자 👍/👎 비율

성능:P50/P95 지연, 오류/타임아웃률, RPS, 토큰/요금

⇒역할:“운영·개선 판단용 KPI”

FastAPI 레벨 지표

추가로 찍는 로그/메타

RAGAS= RAG 시스템을 자동으로 평가하는 프레임워크.

​

질문–컨텍스트–답변 세트를 입력받아정확성·근거성·검색 품질을 수치(0~1)로 산출.

​

무엇을 재나요? (핵심 지표)

- Faithfulness: 답변이 제공된 컨텍스트에 정합 (환각 여부).

- Answer Relevancy: 질문과 답변의 관련성.

- Context Precision: 가져온 컨텍스트 중 유용한 비율

(노이즈 적을수록 ↑).

- Context Recall: 답변에 필요한 정보가 컨텍스트에 충분히 포함되었는가.

- Context Relevancy(선택): 컨텍스트와 질문의 적합도.

+

88

6.3. RAG 시스템

39

7. 테스트

Test

39

7.1. 단위 테스트

Unit Test

단위 테스트

개요

단위 테스트란

• 소프트웨어 개별 모듈 또는 함수가 올바르게 동작하는지 검증하는 테스트
• 작은 단위(함수, 클래스, 메서드)별 독립적으로 실행

​

자유 양식개별 모듈/기능의 독립적 검증

• 애플리케이션을 구성하는 주요 독립적인 모듈 또는 기능 블록이 개별적으로 예상대로 작동하는지 확인
• (예: 전처리 각 과정의 정확도, RAG 생성 응답 등)

​

빠른 피드백 및 개발 효율성 증대

• 각 모듈 개발 단계에서 오류를 조기에 발견하고 수정하여 전체 개발 흐름에 미치는 영향을 최소화하며, 안정적인 코드 기반을 마련

​

모듈별 책임 명확화

• 각 모듈이 담당하는 기능의 정확성을 보장함으로써, 추후 문제 발생 히 원인 추적을 용이하게 하고 리팩토링 시 안정성을 제공

RAG 시스템 동작

​

응답 결과 품질 검증,

응답 레이턴시 평가

LLM 인터페이스

​

프롬프트 구성

응답 파싱

​

API / 백엔드

​

요청 처리 흐름

데이터 수집

데이터 전처리

프론트엔드 렌더링

​

결과 표시

오류 메시지

​

89

7.1. 단위 테스트

단위 테스트

테스트 계획

UI / 프론트엔드(redfin_ui)

90

7.1. 단위 테스트

단위 테스트

테스트 계획

API / 백엔드 (redfin_scrap_api)

API / 백엔드 (redfin_api)

91

7.1. 단위 테스트

단위 테스트

테스트 계획

API / 백엔드 (redfin_label_api)

92

7.1. 단위 테스트

단위 테스트

테스트 계획

API / 백엔드 (redfin_rag_api)

93

7.1. 단위 테스트

39

7.2. 통합 테스트

Integration Test

통합 테스트

개요

통합 테스트란

• 전체 시트템이 올바르게 동작하는지 확인하는 테스트 단계
• 개별적으로 테스트된 모듈(컴포넌트)들을 결합하여 실

​

종합적인 사용자 시나리오 및 비즈니스 흐름 검증

• 개별적으로 작동을 확인한 여러 모듈 및 컴포넌트들이 실제 시스템 환경에서 함께 연동되어, 사용자가 경험하는 복잡한 기능
• (예: 회원가입, 챗봇 검색 후 결과 확인)이 시작부터 끝까지 오류 없이 정상적으로 작동하는지 확인

​

시스템 계층 간의 상호작용 및 데이터 무결성 확인

• 프론트엔드, 백엔드, 데이터베이스, 외부 API 등 다양한 시스템 계층과 모듈 간의 인터페이스 및 데이터 전달 과정에서 발생할 수 있는 문제를 점검

​

실제 운영 환경에 근접한 환경에서의 검증

• 실제 데이터베이스, 외부 서비스 등 의존성이 있는 환경에서 테스트를 수행하여, 운영 환경에서의 잠재적 문제점을 조기에 발견하고 시스템의 안정성과 신뢰성을 확보

프론트엔드

(입력)

API/백엔드�(요청 처리)

LLM & RAG�(요청 응답 생성)

API/백엔드

(데이터 수집)

API/백엔드

(데이터 전처리)

프론트엔드

(출력)

ALL PASS

사용자 시나리오

*비실시간 선택사항

*비실시간 선택사항

94

7.2. 통합 테스트

통합 테스트

테스트 계획

95

7.2. 통합 테스트

통합 테스트

테스트 시나리오 항목

96

7.2. 통합 테스트

통합 테스트

테스트 상세 진행내역(TC_001)

97

7.2. 통합 테스트

46

소감

프로젝트를 마치며

팀원별 소감

우성민

sungminwoo.devops@gmail.com

​

팀을 리드하며, 구현 외 업무들과 문서화의 중요성을 깨닫게 되었습니다. Airflow와 각종 크롤러를 활용한 데이터 수집부터 RAG 및 LLM 까지 전반적인 흐름을 설계 및 구현하며 프로젝트를 보다 더 넓은 시야로 볼 수 있었습니다. 또한 몽고DB를 포함한 10여개의 컨테이너 서비스를 기동하며, 네트워크 인프라 및 리소스 관리를 경험하며, 제한적인 리소스 상황에 대한 정확한 인지와 타협이 중요함을 배울 수 있었습니다. 앞으로는 과제별로 적합한 알고리즘과 모델을 선택할 수 있도록 각종 엔지니어링, ML/DL 기법, 그리고 LLM 고도화 기법들을 학습하고 싶습니다.

​

​

서익희

sdzknight@gmail.com

​

React/Next.js는 처음 시도하게 되어 시작할때에는 어디서부터 접근해야되며 라우팅 상태관리 개념조차 낯설었지만 SPRING BOOT MARIADB와의 통합 방식을 이해하며 FRONT와 Backend 연동의 본질을 깊이 이해하게 되었습니다

​

강충원

kco19981116@gmail.com

​

RAG를 활용하여 Retriever가 여러 자료를 찾아 LLM이 핵심만 빠르게 요약하도록 LangChain을 통한 다양한 기법을 이용해 전체 흐름을 구성하며 RAG에 대한 전반적인 개념과 흐름을 알 수 있었습니다. 단순 RAG에서 그치지 않고 RAPTOR와 같은 고급 기법을 적용해 토큰 비용 및 시간 최적화 관점에서 유의미한 경험을 했습니다. 페르소나별 템플릿을 추가로 전달해주어, 사용자 특성별로 LLM이 맞춤 답변 또한 만들게 하였습니다. 앞으로 RAGAS와 같은 자동 평가 시스템을 붙여 A/B테스트를 통한 고도화 작업을 진행하며 경험하고 싶습니다.

​

​

마치며

김승환

hwan000303@gmail.com

​

리소스 한계로 인해 Two-tower 모델에서 Elasticsearch 기반으로 아키텍처를 변경한 점은 아쉬웠지만, 의도한 기능을 완성할 수 있었습니다. 웹 사이트별 구조 차이와 텍스트 전처리 로직 구현을 통해 스크래핑의 복잡성을 체감하였고, 백엔드 API가 프론트엔드 추천 결과와 연결되는 전체 개발 과정을 경험하면서 데이터 파이프라인의 중요성을 배웠습니다. 앞으로는 더 다양한 추천 알고리즘과 효율적인 데이터 전처리 기법을 학습하여 모델 성능을 고도화하고 싶습니다.

​

정회성

ghltjd2344@gmail.com

​

프론트엔드 개발을 맡으며 Next.js 14, React 18, TypeScript 기반으로 뉴스/추천 UI 로직과 상태 관리 구현을 담당했습니다. Tailwind CSS, shadcn/ui, lucide-react 아이콘을 활용하여 반응형 대시보드 및 재사용 가능한 컴포넌트 디자인을 구현하면서, 프론트엔드 설계의 체계성과 사용자 경험(UX)의 중요성을 배웠습니다. 앞으로는 사용자 친화적이고 확장성 있는 UI를 설계할 수 있도록 성능 최적화 및 디자인 시스템 구축 경험을 쌓아가고 싶습니다.

98

마치며

46

Q&A

발표를 경청해주셔서 감사합니다.