믿고 쓰는 정보가 만들어지는
과정을 설계하고 싶습니다

Righthouse — 형식이 다른 데이터를 하나의 기준으로

회사의 자금이 장부에 기록된 대로 움직였는지 확인하는 프로젝트입니다. 은행이 실제로 처리한 거래와 회계원장에 기록된 거래를 맞춰보고 어긋나는 건을 찾아냅니다. 그런데 가장 먼저 부딪힌 문제는 분석이 아니라 형식이었습니다. 거래내역이 은행마다 다른 구조로 들어왔기 때문입니다.

수만 건 규모를 수작업으로 대사하던 방식은 시간이 오래 걸리고 누락 위험이 있었습니다. 그래서 자동 매칭 로직을 구현했는데, 여기서 진짜 문제는 코드가 아니었습니다. 기계적으로는 불일치지만 실제로는 정상인 건이 상당수였기 때문입니다. 어디까지를 정상으로 볼 것인지, 그 기준을 근거를 갖고 정하는 것이 이 프로젝트의 핵심이었습니다.

DART Converter — 재현해야 원인이 보입니다

사용자 PC 환경이 제각각이고 원천 공시 데이터의 구조도 기업마다 달라, 같은 기능에서도 서로 다른 원인의 오류가 반복 발생하는 솔루션입니다. 문의 접수부터 이슈 종결까지를 담당했습니다.

셀러 신용 리스크 평가 — 평가할 근거가 없는 대상을 어떻게 평가할 것인가

선정산은 온라인 셀러의 정산 예정 대금을 미리 지급하는 구조라, 셀러가 정상적으로 판매를 이어갈 수 있는지 판단하는 것이 곧 리스크 관리였습니다. 그러나 대상 셀러 상당수가 개인사업자이거나 사업 기간이 짧아, 정형 금융데이터로는 평가할 근거 자체가 없었습니다.

저는 셀러가 이미 만들어내고 있는 다른 데이터에 주목했습니다. 구매자가 남긴 리뷰와 문의 내역입니다. 배송이 지연된다는 불만, 응답이 없다는 문의, 상품이 설명과 다르다는 지적은 단순 불만이 아니라 운영이 흔들리고 있다는 신호일 수 있다고 판단했습니다.

고교학점제 RAG 챗봇 — 한 문장의 요구를 명세로 바꾸기

처음 받은 요구는 "고교학점제 정보를 쉽게 찾게 해달라"는 한 문장이었습니다. 이 상태로는 무엇을 만들어야 할지 정할 수 없었습니다. 베어러블이 운영하는 오픈채팅방 데이터를 분석해보니 학생과 교사의 관심사가 다르고, 단순 용어 확인부터 본인 상황에 맞는 이수 경로 판단까지 요구 수준의 폭이 넓었습니다. 질문을 유형별로 나누고 유형마다 어느 수준까지 답할지를 기능 명세로 구체화한 뒤 개발 범위를 확정했습니다.

• 표·각주가 복잡하게 얽힌 정책 PDF를 Docling 기반 PDF→Markdown 변환 파이프라인으로 구조화
• 변환 결과를 원문과 대조해 표의 셀 밀림·항목 누락을 검수하며 전처리 기준 수립
• Pinecone 벡터 검색 기반 Adaptive RAG 구성, 질의 유형에 따라 검색 경로 분기
• LangGraph로 질의 처리 흐름 설계, 프롬프트 엔지니어링으로 답변 일관성 확보

안전 위해도 예측 모형 — 놓치면 안 되는 것을 놓치지 않기

Python 전처리와 피처 엔지니어링으로 위해 발생 가능성을 설명하는 예측 변수(항목)를 설계하고, 다중 모델 비교와 앙상블 기법으로 성능을 최적화했습니다. 이 데이터의 가장 큰 특징은 위해 사례가 극소수인 클래스 불균형이었습니다. 정확도만 보면 모든 건을 정상으로 예측해도 높은 수치가 나왔습니다.

SMOTE로 학습 데이터를 보정하고, 평가지표를 정확도가 아닌 Recall 중심으로 설정했습니다. 위험한 사례를 놓쳤을 때의 비용이 잘못 지목했을 때의 비용보다 크다고 판단했기 때문입니다.

그 외 — 데이터 표준화와 지표 설계

• 고객사 재무·회계데이터 표준화 — 구조가 다른 원장 데이터를 Python ETL로 정제·표준화(수십만 행 규모)하고, 시산표(TB)·계정과목표(COA)와 대조해 원천 데이터의 오류를 사전 식별
• 교육기관 KPI 대시보드 개발·배포 — 흩어진 공공데이터를 수집·병합하고 현업 요구를 지표 정의서로 구체화해 KPI 산출 로직을 설계, 인터랙티브 대시보드로 배포