SKT 고객센터 운영사 서비스에이스에서 전사 운영 플랫폼의 백엔드를 단독으로 맡아 요구사항 정의부터 설계·배포·운영까지 수행했습니다.
상담 현장은 데이터가 어긋나면 곧바로 잘못된 안내와 금전 손실로 이어지는 환경이라, 정합성과 추적 가능성을 지키는 데 집중했습니다.
상담사가 상담 중 요금제·약정 기간을 실시간으로 비교하는 계산기를 만들어 상담 업무를 지원했고,
부서별 엑셀로 흩어져 있던 IT 자산 약 6,200건은 변경을 필드 단위 전·후 값으로 남기고
본 데이터와 이력을 하나의 트랜잭션으로 묶는 Audit Trail 구조로 통합해 분실 처리 자산 약 1,000만 원을 회수했습니다.
사내 AI 인프라에서는 서비스마다 외부 LLM API를 직접 호출하던 구조를 사내 Local LLM과 LiteLLM 공통 호출 계층으로 전환해,
외부 API 사용료 0원으로 7개 사내 서비스의 주간 약 4,200건 요청을 운영 로그 기준 정상 응답률 99.6%로 운영하고 있습니다.
데이터가 늘며 RAG 검색 품질이 떨어졌을 때는 원인을 중복 청크의 순위 잠식으로 좁혀, Recall을 확보하는 검색과 Precision을 높이는 재정렬로 단계를 분리해 해결했습니다.
현재는 자산관리·AXis·RAG를 MCP Tool로 연결해 모델이 사내 실데이터를 조회하고, SSO 권한·사용자 확인·Audit Trail 아래에서 업무까지 실행하는
사내 업무 에이전트 실행 계층을 구축해 운영하고 있습니다.
주력 스택은 Java·Spring Boot이고, 개인 프로젝트에서는 Go·Python·Kubernetes로 DB 운영 플랫폼을 만들며 같은 원칙을 실험했습니다. 특정 기술보다, 작업이 실패하더라도 “누가 · 언제 · 무엇을 · 어디까지” 실행했는지가 남아 추적·복구할 수 있는 상태·이력 구조를 설계하는 일에 가장 관심이 많습니다.
문제 정의, 설계 판단, 운영 결과를 중심으로 작성했습니다.
외부 LLM API 사용 증가로 비용 부담이 커졌고, 사용자·서비스별 사용량을 분리해 추적할 수 없었습니다.
내부 정보가 포함된 질의가 외부 API를 경유하는 문제도 있어, 사내 장비에서 구동되는 Local LLM과 공통 운영 계층을 구축했습니다.
이후 답변 생성에 머물던 챗봇을 자산관리·AXis·RAG와 연결해, 사내 실데이터를 조회하고 승인된 업무를 안전하게 실행할 수 있도록 MCP 기반 표준 Tool 계층으로 확장했습니다.
tools/list로 외부 기능의 이름·설명·입력 스키마를 조회하고, 모델이 선택한 기능을 tools/call로 실행한 뒤 결과를 다시 Local LLM 컨텍스트에 전달하는 흐름 검증tools/list로 자동 발견되는 연결 구조 설계Prepare → Commit)로 구현 — operation_id·멱등성 키·만료시간으로 중복·오실행 방지trace_id로 연결해 모델 호출부터 업무 시스템 실행까지 추적하는 PostgreSQL 관측 구조 구축
크롤링 문서와 청크가 누적되면서 의미가 비슷한 후보가 증가해, 정답 청크가 존재하더라도 최종 Top-K 밖으로 밀리는 검색 품질 저하가 발생했습니다.
실패 질의의 검색 순위를 추적해 정답이 넓은 후보군에는 포함되지만 최종 결과에서 탈락하는 것을 확인하고, 임베딩 누락이 아닌 후보 간 경쟁과 중복 청크의 순위 잠식 문제로 원인을 좁혔습니다.
1차 검색에서 후보를 Top 50까지 확보한 뒤 완전·유사 중복을 제거하고 문서별 청크 수를 제한했으며, bge-reranker-v2-m3로 상위 후보를 재평가해 최종 Top 6만 LLM에 전달하도록 검색 단계를 분리했습니다.
검색 후보를 무작정 프롬프트에 늘리는 대신 Recall을 확보하는 검색 단계와 Precision을 높이는 재정렬 단계를 분리해야 데이터가 증가해도 검색 품질을 안정적으로 유지할 수 있음을 확인했습니다.
전사 AI 전환 수요가 메일·구두 요청·부서별 논의로 흩어져 있었고, 접수 기준이 없어 과제를 일관되게 분류하기 어려웠습니다.
제안자가 배경·개선안·기대 효과를 직접 작성해야 해 자발적인 등록도 저조했습니다.
수요를 구조화된 데이터로 접수하고 처리 상태까지 관리하는 플랫폼을 구축했습니다.
iframe으로 연동해 AXis를 과제 접수뿐 아니라 AI 서비스를 직접 체험하는 진입점으로 확장
IT 자산이 부서별 엑셀로 관리되어 반납·재배정 때 기존 값이 덮어써졌고, 분실·미확인 자산의 마지막 사용자와 변경 경로를 추적할 수 없었습니다.
등록 → 재배정 → 반납 전 과정을 단일 플랫폼으로 통합하고, 모든 변경이 사용자·시점·필드 단위로 남는 구조로 전환했습니다.
기존 데이터를 일괄 이관하는 과정에서 도입연도 등 일부 관리 항목이 비어 있었습니다.
임의 값으로 보정하면 통계와 이력의 신뢰도가 함께 무너지므로, 누락값을 ‘미입력’ 상태로 분리해 가시화하고 운영 과정에서 보완하도록 설계했습니다.
데이터 이관은 값을 옮기는 작업이 아니라 기존 데이터 품질을 드러내고 관리 기준을 다시 세우는 과정이라는 점을 배웠습니다.
여러 MySQL 인스턴스의 상태 확인과 계정·권한 작업을 개별 CLI로 수행하면 결과가 분산되고, 실패 시 어떤 요청이 어디까지 실행됐는지 추적하기 어렵습니다.
인스턴스 등록부터 상태 점검, 권한 작업, 실행 이력 조회까지 하나의 플랫폼에서 관리하고 실패한 요청도 사라지지 않는 운영 구조를 구현했습니다.
PENDING으로 기록하고 결과에 따라 SUCCESS / FAILED로 전이
사용하려던 SaltStack 공개 이미지 태그가 더 이상 제공되지 않아 python:3.10-slim을 기반으로 실행 환경을 직접 구성했습니다.
컨테이너가 기동 직후 종료되는 문제는 docker logs의 Traceback을 기준으로 distro, pycryptodomex, cryptography 등 누락 의존성을 확인해 해결했습니다.
이후 베이스 이미지와 런타임 의존성을 Dockerfile에 직접 명시해 외부 이미지 정책에 덜 의존하는 재현 가능한 환경으로 전환했습니다.