작업 내용

1) 코드 리팩토링 및 안정성 개선

문제 정의:

• 전임자로부터 인수받은 챗봇 로직의 모듈화와 역할 분리가 부족한 상태
• 기능 추가 및 변경이 반복되면서 코드 복잡도가 증가하였고, 유지보수성과 확장성이 저하됨
• 서비스 오류가 빈번하게 발생해 장애를 최소화하는 것이 해당 분기의 주요 OKR로 설정

해결 방법:

• 전체 챗봇 로직을 리팩토링하고 기능별로 모듈화하여 코드 구조를 재정비
• 처리 단계의 추가·변경이 잦은 챗봇 파이프라인 특성을 고려해 책임 연쇄 패턴을 적용하여 각 처리 단계의 책임을 분리
• 단일 LLM Provider 장애에 대비해 복수의 Provider를 구성하고 Fallback 로직을 구현
• Provider별 구현 차이는 Strategy 패턴으로 분리하고 공통 인터페이스로 통일하여, 상위 레이어에서 필요한 Provider 전략을 교체해 사용할 수 있도록 설계
• 공통 처리 흐름은 Template Method 및 Facade 패턴을 적용하여 중복 코드를 줄이고 호출 구조를 단순화
• 예외 케이스를 재정의하고 기존 예외 처리 과정에서 누락되거나 잘못 검출되던 오류를 수정
• 오류 발생 시 Slack 및 DB에 자동으로 기록되도록 로깅 체계를 추가/정비했으며, Decorator 패턴을 활용해 비즈니스 로직과 관측성 로직을 분리

맡은 역할:

• 모든 업무를 전담함

개선 결과:

• 기존 분기당 서비스 장애 발생: 5건 이상 (오류 로깅 결함으로 정확한 건수 측정 불가)
• 개선 이후 분기 서비스 장애 발생: 0건
• 코드 구조 개선과 장애 대응 체계 강화를 통해 서비스 안정성 및 확장성 확보

2) 성능 및 비용 최적화

문제 정의:

• LLM Provider 및 모델 선정 과정에 정량 평가 기준이 없어 경험적으로 모델을 선택
• 프로젝트 내에서 챗봇 응답 속도가 느리다는 피드백이 지속적으로 발생

해결 방법:

• 이미지 입력 시 유해 콘텐츠 필터링과 응답 생성을 위해 LLM API를 2회 호출하던 구조를 개선하여, 단일 호출에서 두 작업을 함께 처리하도록 변경
• DB에 축적된 실제 사용자 대화 약 400건을 평가 데이터셋으로 활용하여 각 성능 지표를 측정하고 비교함
• 웹서치 기능을 JSON Structured Output 방식과 Function Calling 방식으로 각각 구현하고, 모델·구현 방식별 호출 빈도, 응답 속도, 정확도​를 비교
• 모델별 이모션 검출 결과 분포, Structured Output 성공률, 응답 속도​를 측정하여 비교
• 평가 결과를 기반으로 최적 모델과 호출 우선순위를 재설계

맡은 역할:

• 모든 업무를 전담함

개선 결과:

• 응답 속도 개선: 기존(1.42초), 개선(1.07초)
• 이미지 입력 응답 속도 개선: 기존(4.5초), 개선(2.5초)
• 정량 평가 결과에 근거하여 웹서치, 이모션 검출 성능을 최적화하고 모델 우선순위를 정립함

아키텍쳐

런타임/배포 구조

flowchart TB
    Client["클라이언트"]
    Client -->|"HTTP"| REST["REST 서버<br/>FastAPI"]
    Client <-->|"Socket.IO"| Socket["실시간 서버<br/>Flask + Eventlet"]
    REST --> Pipeline["공통 대화 파이프라인"]
    Socket --> Pipeline
    Pipeline --> LLM["LLM 공급자"]
    Pipeline --> Mongo[("MongoDB")]
    Socket --> Redis[("Redis")]

Socket 메시지 시퀀스

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Socket Server
    participant R as Redis
    participant H as Chat Pipeline

    C->>S: message
    S->>R: 현재 sid 저장
    S->>H: 대화 처리 요청
    H-->>S: response_data
    S->>R: 최신 sid 조회
    R-->>S: socket id
    S-->>C: receiveMessage

sequenceDiagram
    autonumber
    participant H as Chat Pipeline
    participant M as MongoDB
    participant L as LLM

    H->>M: 최근 대화 조회
    M-->>H: 최근 15건
    H->>L: 언어 분류
    L-->>H: 입력 언어
    H->>L: 답변 생성
    alt 성공
        L-->>H: 구조화된 답변
    else 실패
        H->>L: 다음 공급자 호출
        L-->>H: 답변 또는 오류
    end
    H->>M: 처리 결과 저장
    M-->>H: inserted_id

상태 머신

stateDiagram-v2
    state "처리 중" as processing
    state "성공" as success
    state "반복 메시지" as repeated
    state "이미지 오류" as imageError
    state "서버 오류" as serverError
    state "답변 생성 오류" as llmError
    state "JSON 오류" as jsonError
    state "미정의 오류" as unknownError

    [*] --> processing
    processing --> success : 생성 성공
    processing --> repeated : 3회 반복
    processing --> imageError : 이미지 검증 실패
    processing --> serverError : DB 오류
    processing --> llmError : LLM 오류
    processing --> jsonError : 형식 오류
    processing --> unknownError : 기타 예외

    success --> [*]
    repeated --> [*]
    imageError --> [*]
    serverError --> [*]
    llmError --> [*]
    jsonError --> [*]
    unknownError --> [*]

디자인 패턴

Chain of Responsibility

• 대화 처리 단계를 순차 체인으로 연결하여 각 단계의 책임을 분리하고 처리 순서를 쉽게 조합

Strategy

• LLM 공급자와 MongoDB 저장 방식을 전략 클래스로 분리하여 호출부를 변경하지 않고 구현을 선택하거나 교체

Template Method

• `요청·검증·후처리 순서를 고정하여 공급자별 구현이 동일한 처리 절차를 따르도록 함

Failover / Ordered Fallback

• 우선순위에 따라 LLM 전략을 실행하도록 하여 한 공급자가 실패해도 다음 공급자로 작업을 이어가도록 함

State Pattern에 가까운 명시적 상태 머신

• TaskState를 처리 단계와 DB·응답 분기의 기준으로 사용하여 성공 및 오류 흐름을 일관되게 제어

Facade

• LLMModule과 DBModule이 여러 공급자 및 DB 세부 동작을 단일 인터페이스로 감싸 상위 계층의 사용을 단순화

Decorator / Cross-cutting Concern

• Slack, DB, 실행 시간 로깅 데코레이터가 핵심 로직과 관측성 코드를 분리

참고자료

앱

• Android: https://play.google.com/store/apps/details?id=co.hiing.hiing
• Apple: https://apps.apple.com/kr/app/하잉-고민상담-힐링-대화-ai-채팅/id6476132969

딥테크팁스, 고성능컴퓨팅 지원 사업의 지원을 받아 수행함 (H100 GPU 2EA)

작업 내용

1) 데이터 중복 제거

문제 정의:

• 고성능컴퓨팅 지원 기간이 얼마 남지 않았고 진행이 더딘 상태에서 프로젝트를 인수함 (24년 9월)
• 부족한 GPU 자원을 최대한 효율적으로 사용하여 기간 내 모델 개발을 완료해야 하는 상황

해결 방법:

• 학습 데이터 수를 줄여 학습 소요 시간을 단축시키고 더 많은 실험(하이퍼 파라미터 최적화 등)을 진행하기로 결정
• 중복 제거 방법론 조사 및 적용 (SemDeDup: 의미가 유사한 데이터를 제거하여 과적합을 방지하고 성능을 향상, Abbas et al., 2023)

맡은 역할:

• 모든 업무를 전담함

성과:

• 중복 제거를 통해 68.2% 데이터 제거하면서 성능 저하를 막음 (정성적 평가)
• 학습 소요 시간을 2배 이상 단축
• 해당년도 모델 개발 목표 완수하여 Hiing App에 Fine-Tuning 모델 실적용 할 수 있었음

2) 그 외 세부 내용

학습 데이터 수집 및 관리

• Hiing App 대화 데이터 약 2백만 개
• 데이터 버전 관리
• 비식별화 처리

모델 학습

• SFT(LoRA, Instruction Tuning) 캐릭터 역할 학습
• DPO 학습 시 독성 응답, 응답 길이, 반복 응답 문제 추가 조정

성능 평가

• Decontamination: 학습 데이터와 평가 데이터 간 오염 가능성을 탐지
• 5개 벤치마크(Ko-Hellaswag, Ko-TruthfulQA, KMMLU, Toxicity Score, Emotion 검출) 성능 평가 (TTA 시험 인증)
• LLM-as-a-Judge: 특정 사용 사례에 대하여 기존 벤치마크로 측정할 수 없는 정성적인 평가 기준을 정량화

모델 서빙

• 제한된 사내 GPU 자원 (A100 2EA)으로 Hiing App에 Fine-Tuning 모델 서빙해야 하는 상황
• Fits on Chips 서비스 사용하여 vLLM으로 서빙 시의 파라미터 최적화 실험 수행
• GPU 메모리 사용 최소화 (70GB -> 30GB)

참조 문헌

• Super-NaturalInstructions: Generalization via Declarative Instructions on 1600+ NLP Tasks — Wang et al. (2022)
• SemDeDup: Data-efficient learning at web-scale through semantic deduplication — Abbas et al. (2023)
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — Zheng et al. (2023)
• FEEL: A Framework for Evaluating Emotional Support Capability with LLMs — Zhang et al. (2024)
• AugESC: Dialogue Augmentation with Large Language Models for Emotional Support Conversation — Zheng et al. (2023)
• Scaling Laws for Forgetting When Fine-Tuning Large Language Models — Kalajdzievski (2024)

수행 내용

1) CBT 챗봇 설계

문제 정의:

• 딥테크팁스 사업 정량 목표 중 하나로, 2주간 챗봇(실험군)과 독서치료(대조군)를 비교하는 무작위대조시험(RCT)을 통해 우울·불안 지표 개선 효과를 검증하는 과제를 수행
• 모델 파인튜닝만으로는 체계적인 상담 효과를 이끌어내는데 한계가 있음
• 검증된 상담 프로토콜을 기반으로 치료 과정을 수행하는 챗봇 에이전트 구축이 필요

해결 방법:

• 상담 기법 및 디지털 정신건강 챗봇 관련 문헌 조사 후 인지행동치료(CBT)를 적용한 챗봇 에이전트 개발로 방향을 설정함
• 우울·불안 증상, 온라인 챗봇 치료, 범용적 적용 가능성을 고려하여 Unified Protocol 기반의 14일 CBT 프레임워크 선정
• 14일간 매일 정해진 워크시트를 수행하도록 상담 과정을 구성
• 일일 상담 세션을 7단계로 구조화
• Orchestrator Agent가 대화 단계를 판단하고 각 단계별 에이전트가 상담을 진행하는 Multi-Agent 구조 구현
• 우울·불안 및 CBT 상담 자료를 기반으로 Knowledge Base(Vector DB) 구축하고 각 단계에서 이를 참조하는 RAG 기능 구현

맡은 역할:

• RCT 운영(모집/배정/온보딩)을 제외한 모든 업무
• 논문 작성과 통계 분석은 일부(비열등성 검정, 성실도 분석) 수행

성과:

• 개발한 챗봇을 활용한 2주간의 RCT 실험 완료
• ANCOVA 분석 결과, 챗봇 실험군과 독서치료 대조군 간 우울·불안 개선 효과에서 통계적으로 유의한 차이는 얻지 못함
• 당초 설정한 정량 목표치에는 미달하였지만, 독서치료와 유사한 수준의 우울·불안 개선 효과 확인하여 현재 JMIR Medical Informatics 투고를 위한 논문 작성 진행 중

2) 그 외 세부 내용

연구 개요

• 설계: 2군 무작위 대조 시험 (실험군: CBT 챗봇 / 대조군: Mind Over Mood 독서치료)
• 기간: 14일 (중간설문: 7일차, 사후설문: 14일차)
• 모집 규모: 총 90명 (기존 모집 81명 + 추가 모집 9명) — 실험군 49명, 대조군 41명
• 드롭아웃·불성실 참여자 제외한 Completer 74명 (실험군 39, 대조군 35)
• 고위험군 스크리닝 조건(PHQ < 20, GAD < 15) 적용/미적용 두 기준으로 병행 분석
• 측정: PHQ-9(우울), GAD-7(불안)을 사전(pre)–중간(mid)–사후(post) 3회 측정

CBT 챗봇 프레임워크·대화 구조 설계

• opening(시작) → emotion(감정 탐색) → trigger(촉발 요인) → consequence(반응) → evidence(사고 검증) → summary(요약) → worksheet(훈련) → open_ended(공감적 자유 대화)로 이어지는 단계형 CBT 대화 절차 정의 (CCI, Unified Protocol 등 임상 CBT 자료 참고)
• Agent 설계: Orchestrator - 각 단계 Agent - Knowledge Base (Pinecone Vector DB)

모델 선정 및 학습

• Open-Ended 단계: EXAONE-3.5-7.8B-Instruct 기반 파인튜닝 모델
• 그 외 단계: Gemini-2.5-flash

RCT 운영 (모집·배정·온보딩)

• 모집 계획 수립, 실험 진행 프로토콜(모집·배정·연락) 및 대면 온보딩 프로토콜 문서화·운영
• 기존 모집 후 추가 모집(+9명)으로 표본 보강, 드롭아웃·불성실 참여 기준 정의 및 적용

통계 분석

• ITT 분석: Linear Mixed Model(그룹 x 시점) + Multiple Imputation(Rubin's rules, m=50, burn-in 20) — 스크리닝 적용/미적용 두 기준으로 수행
• Completer 분석: 2x3 Repeated-Measures ANOVA(pre-mid-post), 2x2 ANCOVA(post ~ pre + group)
• 비열등성 검정: FDA/EMA 가이드라인과 선행연구 조사 기반으로 비열등성 검정 마진 산출, ANCOVA 조정 평균차와 95% CI로 평가
• 질적 분석(Thematic Analysis): 실험군/대조군 사용자 피드백 1차 코딩 → 2차 코딩으로 상위 테마 도출
• 성실도(참여 성실성) 변화 분석: 일별 채팅 수·총 단어 수·단답 비율·응답 유사도(similarity)에 대한 OLS 회귀 및 PHQ/GAD 변화량과의 상관 분석

주요 결과

• ITT 분석(LMM + MI, 실험군 49/대조군 41): PHQ-9, GAD-7 모두 중간·사후 시점에서 그룹 간 유의한 차이 없음. 시간 효과는 유의 — 두 군 모두 증상 감소
• Completer 분석(RM ANOVA, ANCOVA): 그룹 간 차이 없음
• 비열등성 검정: GAD-7(불안) 비열등성 입증
• 성실도 변화: 사용 일차가 지날수록 참여 지표 감소, 단답 비율이 증가할수록 PHQ-9(우울) 악화

참조 문헌

• The Key Principles of Cognitive Behavioural Therapy — Fenn & Byrne (2013)
• Delivering Cognitive Behavior Therapy to Young Adults With Symptoms of Depression and Anxiety Using a Fully Automated Conversational Agent (Woebot): A Randomized Controlled Trial — Fitzpatrick et al. (2017)
• 21-Day Stress Detox: Open Trial of a Universal Well-Being Chatbot for Young Adults — Williams et al. (2021)

PDF·DOCX·HWP·URL·텍스트로부터 검증 대상 문장을 추출, 웹 검색 결과와 대조하여 진위 여부를 검증하고 분석 결과를 반환하는 Multi-Agent 시스템 개발

설계·구현

문서 파싱 및 전처리

• PDF·DOCX·HWP·URL·텍스트를 공통 구조로 변환하는 Parser API 개발
• 다국어 문장 분리, 파싱 오류 복원 및 Parser Fallback 개발
• 진위 검증 대상이 되는 주장(Claim) 추출

검색·RAG 파이프라인

• 문장별 복수 검색 질의를 생성하는 Multi-query Retrieval 구현
• 비동기 웹 수집, 도메인 필터링 및 중복 문서 제거
• Embedding·Reranking 기반 근거 문서 선별 및 Context 압축

멀티에이전트 워크플로우 설계

• 검색·판별·검토·재검색 역할을 분리한 Multi-Agent Workflow 구축
• 검색·스크래핑·Embedding·Reranking을 수행하는 Research Agent
• 진위 여부를 판단하는 Fact-Check Agent
• 근거 기반 분석 결과와 신뢰도를 검토하는 Review Agent
• 근거 부족 시 질의 재작성 및 추가 검색을 수행하는 Retry 구조 구현

분석 결과 구조화 및 관계 분석

• LLM에 의존하지 않는 일관되고 재현 가능한 총점 계산식 작성
• 문서·Claim 분석 결과 리포트 생성

장애 대응 및 운영 안정성

• LLM·OCR·검색 API 오류에 대한 재시도·지수 백오프·Fallback 구현

성능 평가·최적화

진위 판별 정확도

• 300개 Claim으로 Golden Set 구성 (TRUE / MOSTLY_TRUE/ ... / UNCHECKABLE의 5개 Label)
• Accuracy: 0.83
• Macro F1: 0.55
• 평균 판정 오차(각 label 0~4 수치화 후 거리) 0.264

조작정보 탐지 성능

• 300개 Golden Set 중 TRUE Claim 100건을 선정하여 11개 조작 패턴으로 변형
• GPT-5.1의 탐지 정확도와 비교
• 본 시스템 86%, GPT-5.1 82%로 4%p 우위

RAG 검색 성능

• 약 20종 PDF 대상, 300→1,024 token, 1~3-hop 조건에서 BM25/Semantic/Hybrid Search 비교
• Hybrid MAP 0.780→0.793, MRR 0.837→0.850
• Semantic MAP 0.761→0.716, MRR 0.817→0.776

Embedding 검색 성능

• 한국어 Retrieval Dataset 5종에서 주요 검색 지표 비교
• Gemini Embedding이 Top1·Top10 랭킹 지표 1위
• Cohere는 Recall@10 최고 성능

웹 검색 엔진 성능

• Google/Serper, Brave, Jina, Perplexity의 품질·속도·비용 비교
• Google/Serper 선정
• 평균 응답시간 약 1.3초, 비용 약 $0.00075/회
• Brave는 비용 약 5배, Jina는 응답 지연 약 10~20배

문서 Parser 성능

• HWP/DOCX/PDF의 실패율·응답속도 측정
• 전 형식 실패율 0%
• 평균 응답시간: HWP 32ms, DOCX 614ms, PDF 4.7초
• PDF 최적화: 평균 32초→4.7초, 실패율 7.7%→0%

전체 처리 속도

• 전체 Fact-Check 파이프라인 처리시간 측정
• Overall 29.69초, Retry=True 63.78초, Retry=False 24.33초
• 최종 평균 약 33초/Claim

시스템 부하·보안 검증

• URL/TEXT/FILE 요청 총 90회 부하 테스트 및 포트 스캔
• 서버 장애 없이 처리
• 필요한 서비스 포트만 Open 상태 확인

문서 입력 흐름

sequenceDiagram
    participant 사용자
    participant 문서API
    participant ParserAPI
    participant MongoDB
    participant WebSocket

    사용자->>문서API: 파일 / URL / 텍스트
    문서API->>MongoDB: 초기 메타데이터 저장
    alt 파일 입력
        문서API->>ParserAPI: POST /api/parse
        ParserAPI->>ParserAPI: 형식 판별 및 OCR
        ParserAPI-->>문서API: 파싱 텍스트
    else URL 입력
        문서API->>문서API: 웹 크롤링 및 전처리
    else 텍스트 입력
        문서API->>문서API: 텍스트 정규화
    end
    문서API->>MongoDB: 본문 및 상태 갱신
    문서API-->>WebSocket: 처리 상태 전송

Parser 처리 구조

flowchart LR
    upload["파일 입력"] --> detect["확장자 판별"]
    detect -->|"DOCX"| docx["DOCX Parser"]
    detect -->|"HWP"| hwp["HWP Parser"]
    detect -->|"PDF / 이미지"| ocr["OCR API"]
    docx --> normalize["텍스트 정규화"]
    hwp --> normalize
    ocr --> normalize
    normalize --> cache["메모리 Cache"]
    cache --> response["파싱 결과"]

Scheduler 처리 흐름

flowchart LR
    timer["APScheduler"] --> fetch["대기 데이터 조회"]
    fetch --> refine["문서 문맥 정제"]
    refine --> extract["문맥 단위 추출 Pipeline"]
    extract --> query["검색 Query 생성"]
    query --> persist["MongoDB 상태 갱신"]
    persist --> request["분석 API 호출"]

분석 Graph 흐름

stateDiagram-v2
    [*] --> 요청분기
    요청분기 --> 검색Query생성: 검색 경로
    요청분기 --> LLMFallback: 대체 경로
    검색Query생성 --> 웹검색
    웹검색 --> 문맥검색
    문맥검색 --> 응답생성
    응답생성 --> 응답검토
    응답검토 --> 응답생성: 재생성
    응답검토 --> 재시도Graph: 근거 부족
    응답검토 --> [*]: 완료
    재시도Graph --> 응답생성
    LLMFallback --> [*]

재시도 Graph 흐름

stateDiagram-v2
    [*] --> Query재작성
    Query재작성 --> 웹재검색
    웹재검색 --> 문맥재검색
    문맥재검색 --> 응답재생성
    응답재생성 --> 응답검토
    응답검토 --> 응답재생성: 수정
    응답검토 --> Query재작성: 근거 부족
    응답검토 --> [*]: 완료

작업 내용

1) 소스 코드 통합 및 Monorepo 전환

문제 정의:

• 유사한 비즈니스 로직·모듈·설정을 사용하는 프로젝트가 여러 Repository에 분산되어 있어, 환경변수 관리·유지보수·배포·협업 과정에서 중복 작업이 발생하고 관리 복잡도가 높아지는 문제 발생

해결 방법:

• 개별 Repository는 단기 작업에 빠른 대응이 가능하지만 중복 관리가 증가하고, Monorepo는 초기 표준화 비용과 프로젝트별 요구사항 차이로 공통 모듈의 복잡도가 증가할 수 있음.
• 유사 프로젝트를 지속적으로 확장하는 회사 방침을 고려해 장기적인 재사용성과 유지보수성이 높은 Monorepo로 통합
• 프로젝트별 요구사항 차이를 고려해 전체 코드를 획일적으로 표준화하지 않고, AI Client·DB·Logging·Prompt 등 핵심 공통 모듈만 공유하고 비즈니스 로직과 처리 파이프라인은 독립적으로 설계·구현할 수 있도록 구성
• 팀 내 Git 브랜치 생성·병합 규칙을 표준화하여 협업 방식 정립

맡은 역할:

• 공통 모듈 설계 및 브랜치 생성·병합 규칙 제안

성과:

• 공통 모듈 재사용과 코드 표준화를 통해 개별 작업 요청에 대한 대응 속도 향상
• 유사 프로젝트 간 코드·구현 사례 공유가 쉬워져 협업 효율과 전반적인 코드 품질 향상
• 프로젝트 구조가 표준화되어 담당자 부재 시 대응 및 인수인계가 용이해지고 유지보수성 향상

2) 운영 인프라 및 CI/CD 구축

문제 정의:

• Monorepo 통합 이후 여러 프로젝트를 하나의 운영 체계에서 관리하게 되면서 환경변수·배포 절차의 복잡도가 증가하고, 트래픽이 집중되거나 배포 장애가 발생할 경우 전체 서비스 중단으로 이어질 수 있는 문제 발생

해결 방법:

• 백엔드 개발자와 Monorepo 환경에 적합한 배포·환경변수 관리·트래픽 분산 구조를 논의
• Google Sheets로 환경변수를 중앙 관리하고 배포 시 자동 참조하도록 구성
• Jenkins Pipeline으로 Docker 컨테이너 단위 순차 배포를 자동화하고, 헬스체크 실패 시 이전 이미지로 자동 롤백
• GCP Load Balancer → 운영 서버 2대 → Nginx → Docker 컨테이너 구조를 구성
• Jenkins Credentials로 GitHub Token, SSH Key, GCP 인증키 등 배포 키 관리

맡은 역할:

• 환경변수 및 Credentials 관리 방법 제안, nginx 설정 작성

성과:

• 환경변수 추가·변경이 크게 단순화되었으며, 이후 AI API Key 전수조사 및 변경 과정에서 Monorepo 통합 여부에 따라 관리 난이도와 소요 비용에 뚜렷한 차이가 발생할 정도로 운영 효율이 향상됨
• 프로젝트별로 분산되어 있던 운영 서버를 통합하여 관리 포인트를 축소하고 서버 자원 활용 효율을 향상시켜 비용을 절감함
• 로드밸런싱을 도입해 서버·컨테이너 간 트래픽을 분산하고, 특정 인스턴스의 과부하 및 장애가 전체 서비스에 미치는 영향을 최소화

연구과제

1) 프로젝트명 : 주조(다이캐스팅) 분야 제조 빅데이터 기반 공유 플랫폼 개발

• 연계/소속회사 : 창원대학교, (주)대한오토텍, (주)쿨스
• 참여 기간 : 2019.12 ~ 2021.08 (약 20개월)
• 주요 역할 : 문헌 조사, 데이터 요구사항 정의, 데이터 전처리, 분류 모델 학습
• 업무 성과 : 양품/불량품 예측 모델 분류정확도 1차년도 성능 목표 초과 달성(한국건설생활환경시험연구원 시험 인증)

2) 프로젝트명 : 플라스틱 부품 생산을 위한 사출 금형의 환경관리와 빅데이터의 활용 솔루션

• 연계/소속회사 : 창원대학교, (주)화인
• 참여 기간 : 2020.05 ~ 2021.08 (약 16개월)
• 주요 역할 : 문헌 조사, 데이터 요구사항 정의, 실험계획
• 업무 성과 : 데이터 수집 단계에서 실험 인자/수준 설정 등의 실험계획을 통해 실험 비용을 최소화

3) 프로젝트명 : 빅데이터 기반 STS303 선재 제강공정 최적화

• 연계/소속회사 : 창원대학교, (주)세아창원특수강
• 참여 기간 : 2020.08 ~ 2020.12 (약 5개월)
• 주요 역할 : 문헌 조사, 데이터 전처리, 기계학습 모델링, 비선형 최적화(Particle Swarm 알고리즘)
• 업무 성과 : 최적공정조건 도출, 추가적인 개선을 위해 필요한 시계열 데이터셋 수집을 제안

4) 프로젝트명 : 기계학습 기반 스테인리스강 소재 제품 제조공정 최적화

• 연계/소속회사 : 창원대학교, (주)세아창원특수강
• 참여 기간 : 2020.12 ~ 2021.08 (약 9개월)
• 주요 역할 : 데이터 요구사항 정의, 시계열 데이터 전처리, 탐색적 분석(데이터 시각화)
• 업무 성과 : 3)의 후속 연구로, 추가로 수집한 시계열 데이터를 가공하여 모델링에 필요한 데이터 준비 작업을 완료함

학술대회

1) 항만 컨테이너 터미널 운영 최적화

• 학술대회명 : 한국시뮬레이션학회 (한국대학생컴퓨터시뮬레이션경진대회)
• 발표일 : 2019.04
• 성과/내용 : 매일경제회장상 수상

2) Manufacturing Process Optimiztion for STS303 Wire Rods based on Big Data Analytics

• 학술대회명 : PRESM
• 발표일 : 2020.11.15
• 성과/내용 : 연구과제 3)의 연구 결과

3) Casting Defect Classification Model with GAN-based Image Augmentation

• 학술대회명 : PRESM
• 발표일 : 2021.07.21
• 성과/내용 : 수집가능한 이미지 데이터가 부족한 상황에서 표면 결함 분류 모형을 학습하기 위해 GAN(Generative Adversarial Network) 기반의 이미지 증강 기법을 적용

갤럭시 코퍼레이션 PoC

수행 내용

상용 화상통화 AI 플랫폼 비교 검토

• Tavus(CVI), D-ID(Realtime Agents), HeyGen(LiveAvatar), LemonSlice, BitHuman, MascotBot 대상
• 입력 모달리티(영상/음성/텍스트), 외형·음성 커스터마이즈, 본인인증·동의 절차, 분당 단가, 동시 접속 세션 수, 한국어 품질 기준으로 비교표 작성

오픈소스 기반 화상통화 엔진 구현 (LipSync 모델)

• 화상 통화 프로세스: STT → LLM → TTS → LipSync
• A100 단일 GPU에서 실시간 처리 가능한 SoulX-FlashHead, AVTR-1 모델 선정 후 부하 테스트 수행
• 병목이 VRAM이 아닌 GPU 연산 처리량임을 규명: A100 80GB 1장 기준 AVTR-1 약 2세션, FlashHead 약 4세션이 실시간 동시 처리 상한임을 실측

STT

• FastWhisper, Qwen3-asr 모델 비교 → Qwen3-asr 사용

TTS 오픈소스 파인튜닝 (GPT-SoVITS)

• 오픈소스 TTS 모델 비교 실험: GPT-SoVITS, Zonos, CosyVoice 2.0, Sesame CSM-1B, Dia-1.6B, Resemble AI Chatterbox (소요 시간, 감정 표현, 언어 별 비교)
• 음성 분할 → 잡음 제거 → STT(Faster Whisper large-v3) → 오디오 주석 점검 → 훈련 데이터셋 포맷팅 → SoVITS/GPT 미세 조정 → 추론
• 10초 샘플 복제, 10분/1시간 30분(여성·남성 보컬) 학습 결과 비교 및 하이퍼 파라미터 실험
• GPT-SoVITS 버전 별 파인튜닝 결과 비교 (v4 / v2Pro / v2ProPlus)

TTS (음성 복제)

• 오픈소스(GPT-Sovits)와 ElevenLabs, Minimax 비교 → 최종 Minimax 선정

성능 최적화

• 응답 소요 시간 최소화: LLM → TTS 엔진 간 Stream 연결하여 지연 시간 최소화 (음성 채팅의 경우 첫 음성 발화까지 소요 시간 약 1초)

기술 스택

• 립싱크/아바타 모델: SoulX-FlashHead
• 음성: Qwen ASR(STT), Minimax(TTS)
• 실시간 통신: WebRTC(Daily)
• 개발/배포: Python, Next.js, Node.js, pnpm, Vercel (Python 외 바이브 코딩)
• 인프라: NVIDIA A100 (GPU 부하 테스트)

이야기씨앗: 아이 일기를 동화 영상으로 제작해주는 서비스

동화 생성 API 개발

• OCR → 장면 계획 → 참조 이미지 → 장면 이미지 → 장면 영상/TTS → 편집 단계로 구성된 생성 파이프라인 설계
• LLM, 이미지, 영상 생성 프롬프트 엔지니어링 수행

생성 오류 대응

문제 정의:

• 생성 비용 절감을 위해 저가형 모델을 사용한 탓에 화풍·외형 불일치, 등장인물 수 오류, 인물 관계 오인 등의 오류 잔존
• 외부 생성 API의 rate limit·timeout·safety checker 등의 생성 실패가 빈번하게 발생

해결 방법:

• 입력 / 생성 품질 / 외부 API 등 오류 유형을 정의, 오류별 처리 정책 설계
• 생성 품질 오류 세부 유형 별로 모델·프롬프트·단계 별로 광범위한 비교 실험 수행
• 이미지·영상·TTS 복수 Provider fallback 구성, fallback 모델 간 생성 결과 차이를 고려하여 전체 재시도 로직 설계

성과:

• 비정형적으로 발생하던 생성 오류를 유형별 처리 규칙으로 정리하여 서비스 운영 과정의 장애 대응 범위와 기준 명확화
• 저가형 모델을 유지하면서 생성 오류를 최대한 줄여 이후 사용자 모집 테스트에서 영상 품질에 대하여 일관된 호평을 받음

생성 품질 개선

문제 정의:

• 전문 그림·영상 동화 작품의 컷 구성, 장면 전개, 인물 배치와 구도를 벤치마크하며 기존 결과물 개선이 필요하다고 판단
• 기존 장면 계획 LLM이 장면 분할부터 캐릭터·배경 정의, 장면 연출까지 너무 많은 역할을 한 번에 수행하면서 지시 이행 성능이 저하
• 비용·속도상 고성능 모델로 단순 교체하기 어려워, 경량 모델에서도 안정적으로 동작하도록 작업 단위와 프롬프트 경계를 재설계할 필요가 있었음

해결 방법:

• 동화 작품 분석을 바탕으로 컷 구성·장면 구도를 수정하고, 이에 맞춰 파이프라인 구조를 반복적으로 개선
• 장면 계획 LLM의 역할을 이야기 분석, 장면 분할, 캐릭터·배경 정의, 연출 정보 생성 등으로 세부 단계로 분리
• 단계 분리로 인한 처리 시간 증가를 줄이기 위해 서로 의존하지 않는 작업을 병렬화

성과:

• 단순 프롬프트 튜닝이 아니라 도메인 분석 → 작업 분해 → 프롬프트 경계 설정 → 병렬화 → 파이프라인 재설계까지 수행

생성 비용 절감

문제 정의:

• 초기 구조에서 영상 생성 비용이 전체 생성 비용의 약 80%를 차지
• 높은 콘텐츠 생성 단가가 큰 허들이 됨

해결 방법:

• 단계별 비용을 분리 측정하여 단계/Provider별 비용 구조 가시화
• 비용 비중이 가장 높은 영상 생성 단계를 우선 최적화 대상으로 선정하고 기존 모델과 저비용·오픈소스 대안 모델을 동일 샘플 기준으로 비교
• 단순 최저가 모델을 선택하지 않고 BGM·SFX 및 영상 품질 저하까지 함께 평가하여 품질/비용 trade-off 기준으로 모델 조합 결정
• 생성 품질을 크게 떨어뜨리지 않는 범위에서 모델 선택 및 생성 파라미터를 반복 조정하여 불필요한 생성 비용 축소

성과:

• 초기 동화 1편 생성 비용 약 2,900원 → 913원
• 동화 1편당 약 1,987원 절감, 생성 비용 약 68.5% 감소
• 생성 품질을 유지해야 하는 구간과 비용 최적화가 가능한 구간을 분리하여, 단순 모델 교체가 아닌 품질·비용을 함께 관리하는 생성 파이프라인 운영 구조 확보

데이터 수집 인프라 구축

Upbit·Binance REST API 기반의 스케줄러를 개발하여 100개 이상 종목의 1분봉 캔들 데이터를 수집. 1년 이상의 기간에 해당하는 1억 건 이상의 시계열 데이터를 구축했으며, API Rate Limit 관리와 Thread·Multiprocessing 기반 병렬 처리를 적용해 수집 성능과 안정성을 확보.

뉴스 및 외부 시장 데이터 수집

웹 스크래핑, Selenium, REST API를 활용해 12개 이상의 국내외 뉴스 소스로부터 실시간 뉴스 데이터를 수집. 또한 환율, 나스닥 지수, 주요 경제지표, 경제 이벤트 캘린더 및 거래소 공지사항을 통합 수집하고, 소스 구조 변경에 대응하며 수집 모듈을 지속적으로 유지보수.

실시간 데이터 가공 및 Feature Engineering

수집된 1분봉 데이터를 5분봉·15분봉 등 다양한 주기로 실시간 집계하고, 거래소 간 가격 차이를 기반으로 김치 프리미엄 등의 합성 지표를 계산. 뉴스 데이터에는 Sentiment 분류 모델을 적용해 감성 점수를 산출했으며, 유사 뉴스가 단기간에 반복 생산되는 특성을 활용해 TF-IDF 기반 뉴스 이슈 중요도 점수를 설계.

시장 분석 및 모니터링

가상자산 가격, 뉴스 이슈 점수, 감성 점수, 환율, 나스닥 지수 등 다양한 변수 간 상관관계를 탐색. 인과관계 분석과 통계적 가설 검정을 수행했으며, 실시간 시세 변동을 감지해 설정 범위를 초과할 경우 알림을 전송하는 시장 모니터링 시스템을 구축.

예측 모델 및 자동매매 시스템 개발

XGBoost와 LSTM 기반 시계열 예측 모델을 학습하고, 각종 factor 모형 기반 트레이딩 전략 및 자산 간 가격 관계를 활용한 페어 트레이딩 전략을 개발. 예측 모델과 거래소 API를 연동하여 주문 실행, 포지션 관리 및 매매 전략 수행을 자동화하는 거래소별 자동매매 프로그램을 구현.