Python · FastAPI · RAG

박시찬

문서처리형·자동화형 AI 서비스를 설계하고 구현하는 주니어 AI 엔지니어

복잡한 현장 문제를 기능이 아니라 흐름과 병목 기준으로 구조화해왔습니다. 지금은 그 시선을 FastAPI, RAG, 생성형 AI 파이프라인에 연결해 문서처리형 AI와 운영 가능한 자동화 워크플로를 만들고 있습니다.

Python FastAPI RAG Systems Generative AI Workflow Design
01

What I Can Do

이런 일을 할 수 있습니다

문서처리형 RAG

검색과 응답 품질을 분리해 조정할 수 있는 문서처리형 RAG 구조를 설계합니다.

  • Summary + Raw 이중 저장소
  • BM25 + Vector + RRF 하이브리드 검색
  • 질의 재작성과 품질 게이트 흐름

생성형 AI 워크플로

한 번의 생성보다 수정, 재실행, 예외 대응이 가능한 생성 흐름을 만듭니다.

  • 단계 분리형 생성 파이프라인
  • 상태 기반 재생성 및 편집 흐름
  • LLM failover와 후처리 구조

운영형 API 설계

기능 구현 이후의 상태 추적, 로그, 운영 API까지 이어지는 구조를 함께 설계합니다.

  • FastAPI 기반 API 계층 분리
  • 실행 상태와 결과 추적 구조화
  • 재실행, 수정, 장애 대응을 고려한 설계
03

Why This Background Matters

현장 경험이 지금의 설계 방식으로 이어집니다

현장 경험

건축·시공 관리

도면, 일정, 커뮤니케이션, 변경 대응처럼 한 요소만 잘한다고 끝나지 않는 문제를 다뤘습니다.

운영 경험

개인 화물 운영

예외 상황, 시간 관리, 우선순위 조정 같은 운영 감각을 익히며 실제 흐름 중심으로 문제를 봤습니다.

AI 프로젝트에서의 적용

문제를 빠르게 구조화합니다

  • 모델 성능보다 전체 흐름을 먼저 봅니다.
  • 문서처리, 자동화, 생성 흐름을 단계별로 나눕니다.
  • 수정 경로와 운영 설명 가능성을 함께 설계합니다.
04

Research-Based Analysis

Research에 쌓아둔 기준으로 데이터를 분석합니다

Research Foundation

이 설명은 research 섹션에 쌓인 노트를 바탕으로 다시 묶은 분석 흐름입니다

여기서 말하는 데이터 분석 방식은 새로 덧붙인 소개 문장이 아니라, 네가 이미 정리해 둔 research 아카이브에서 반복적으로 드러난 기준을 다시 꺼내어 보이게 한 것입니다. 문제를 정의하고, 데이터 표현을 정하고, 지표를 고르고, 실패 케이스를 기록한 뒤, 그 결과를 다시 읽히는 자료로 정리하는 흐름이 portfolio 프로젝트에도 그대로 이어집니다.

Research Note -> Project Metric -> Error Pattern Archive -> Design Decision
ML Sprint Archive에서 지표 중심 분석 기준을 만들었습니다

Machine Learning Sprint Archive에 쌓인 회귀, 분류 실험은 어떤 모델을 썼는지보다 어떤 지표를 먼저 볼지 정하는 기준을 남깁니다. RMSLE, Recall, F1, ROC-AUC처럼 문제마다 실패를 읽는 기준이 다르다는 점이 이후 프로젝트의 baseline 판단 방식으로 이어졌습니다.

ML Sprint Research Map
문서형 데이터는 research note 기준으로 표현을 다시 설계합니다

Korean Document Table RAG와 Beyond RAG 노트에서는 raw text를 그대로 넣기보다 table, summary, metadata를 나눠 retrieval-friendly representation으로 바꾸는 관점이 반복됩니다. 그래서 문서형 프로젝트도 수집보다 표현 재구성과 근거 보존을 먼저 생각하는 구조로 연결됩니다.

Document RAG Beyond RAG
Research Map과 Track Archive가 정리 방식의 기준이 됩니다

실험 로그를 단순히 쌓지 않고 Research Map, Deep Learning Vision Track처럼 주제, 실패 포인트, 다음 실험으로 다시 묶는 방식이 분석 정리의 뼈대가 됩니다. 그래서 research는 기록 보관함이 아니라 다음 프로젝트 설계 자료로 바로 이어지는 기반이 됩니다.

Research Map DL Track
04

How I Analyze Data

데이터를 이렇게 분석하고 정리합니다

ML Workflow

모델보다 먼저 데이터 단위, 지표, 실패 케이스를 정리합니다

회귀, 분류, 문서형 RAG를 같은 방식으로 다루지 않습니다. 먼저 예측 대상과 입력 표현을 정의하고, EDA로 변수와 구조를 확인한 뒤, 문제에 맞는 지표와 오류 패턴을 기준으로 다음 실험을 설계합니다. 그 과정은 노트와 포트폴리오에 다시 정리해 다음 프로젝트의 판단 근거로 이어갑니다.

EDA -> Feature -> Metric Raw + Summary + Metadata Error Note -> Next Experiment
질문과 지표를 먼저 정의합니다

문제 유형에 맞는 기준이 먼저 정해져야 실험이 흔들리지 않습니다. 회귀에서는 RMSLE 같은 오차 기준을, 불균형 분류에서는 Recall, F1, ROC-AUC처럼 놓치면 안 되는 실패 패턴을 먼저 보고 baseline과 feature를 조정합니다.

ML Sprint CFD Case
데이터 표현을 다시 설계합니다

문서형 데이터는 수집보다 표현 방식이 더 중요합니다. 원문, 요약, 표, 메타데이터를 분리하고 retrieval-friendly representation으로 재구성해 검색 품질과 응답 근거를 함께 잡습니다.

Document RAG Obsidian RAG
실험 로그를 다시 읽히는 자료로 정리합니다

결과만 남기지 않고, 어떤 데이터와 지표를 썼는지, 무엇이 실패했고 왜 다음 실험으로 넘어갔는지를 research map과 track archive로 다시 묶습니다. 그래서 학습 기록이 바로 다음 프로젝트의 설계 자료가 됩니다.

Research Map DL Track
05

Links

바로 확인할 수 있는 링크

Profile & Contact

바로 확인하는 링크

프로젝트, 저장소, 연락처처럼 바로 열어보게 될 링크를 먼저 모아두었습니다.

대표 링크 4개 빠른 확인용
Archive Home 기존 작업 허브와 최근 아카이브를 그대로 볼 수 있습니다. Projects Portfolio 대표 프로젝트를 조금 더 자세하게 확인할 수 있습니다. Code GitHub 코드, 저장소, 커밋 흐름을 직접 확인할 수 있습니다. Contact Email bhs3518@naver.com
06

Research Sources

계속 추적하는 자료

Sources Overview

에이전트 구조와 연구 업데이트를 따로 모아 보고 있습니다

공식 문서, 업데이트 채널, 커뮤니티 흐름 중 실제로 자주 다시 보는 자료만 따로 추려 두었습니다.

3개 카테고리 12개 자료