임준열

Local LLM 기반 사내 AI 운영 인프라 전환

배경 · 문제

외부 LLM API 사용량이 늘며 토큰 비용 부담이 계속 증가했고, 사용자·용도별 사용량 추적이 없어 통제가 어려웠습니다. 질의에 내부 정보가 포함되어 사내 데이터가 외부 API를 경유하는 보안 리스크도 있었습니다. 사내 장비(DGX Spark)에서 구동되는 Local LLM 호출 구조로 전환하고, 모든 호출을 로그·토큰 단위로 기록하는 운영 체계를 구축했습니다. 저는 LiteLLM–PostgreSQL 운영 데이터 저장 구조와 OpenWebUI–LiteLLM–Local LLM 호출 흐름 연동·검증을 담당했습니다.

접근 · 의사결정

• 앱이 LLM을 직접 호출하는 대신 LiteLLM을 중간 Proxy 계층으로 분리 — 호출 주체가 챗봇 하나가 아니라 여러 사내 서비스라, 직접 연결 시 인증·로깅·토큰 집계를 서비스 수만큼 중복 구현해야 했습니다. API Key 인증·호출 로그·토큰 사용량 관리를 한 지점에 일원화했습니다
• OpenAI 호환 인터페이스를 채택해, 기존 외부 API 호출 코드가 엔드포인트 변경만으로 전환되도록 구성 — 모델 교체 시 각 서비스의 변경 범위를 최소화
• 요청 1건 단위로 모델·프롬프트/응답 토큰 수·응답 시간·호출 Key·팀 정보가 기록되는 저장 구조를 PostgreSQL에 구성(LiteLLM SpendLogs 기반)하고, 서비스별 API Key 발급으로 “어느 서비스가 얼마나 쓰는지”를 분리 추적
• OpenWebUI → LiteLLM → Local LLM으로 이어지는 질의응답 흐름을 연동하고, 실제 문답형 챗봇 1개를 전환해 검증한 뒤 AXis 과제 제안 생성 → RPA 포탈 · VOC 대시보드 등 사내 서비스 5개로 단계 확산

결과 · 성과

• 사내 서비스 5개가 API Key 단위로 연동되어 실트래픽 처리 중 — 주간 약 2,200건 요청 / 약 1,000만 토큰, 성공률 99.6%, 외부 API 과금 $0
• 모든 요청이 토큰 수·응답 시간 단위로 기록되어 Key·팀별 사용량 추적과 운영 모니터링 체계 확보
• 질의가 외부망을 경유하지 않는 구조로 데이터 유출 리스크 제거

AXis — 전사 AX 과제 접수·관리 플랫폼

배경 · 문제

전사 AX(AI 전환) 아이디어가 메일·구두 요청·부서별 논의로 분산되어 수요를 한눈에 파악할 수 없었고, 접수 기준이 없어 과제를 일관되게 분류·관리하기 어려웠습니다. 무엇보다 제안 배경·개선 아이디어·기대 효과를 사용자가 직접 정리해야 해 등록 자체가 문턱이었고, 제안이 들어오지 않았습니다. 수요를 구조화된 데이터로 접수·관리하고, 등록 부담을 낮추는 플랫폼을 구축했습니다.

접근 · 의사결정

• 단순 게시판이 아니라 제안 → 접수 → 검토 → 상태 관리로 이어지는 운영 프로세스를 기준으로 기능 범위를 정의하고, 사용자(제안)와 관리자(접수·검토·상태 관리)의 역할·화면·API 접근 흐름을 분리
• 과제명·업무 영역·제안 배경·개선 아이디어·기대 효과·처리 상태 등 핵심 관리 항목을 자유 텍스트가 아닌 컬럼 단위로 구조화 — 자유 게시판이었다면 접수 후 분류 수작업이 다시 발생. 기본 정보와 처리 상태를 분리해 향후 상태 변경 이력 관리로 확장 가능한 구조로 설계
• 등록·조회·수정·삭제 API를 Controller / Service / Repository 계층으로 구현하고, DTO + 서버단 Validation으로 필수값·입력 오류를 방어. 예외 응답 구조를 정리해 오류 상황을 화면에서 안내
• Local LLM 초안 생성 — 사용자가 1~2줄 입력하면 백엔드가 프롬프트 템플릿으로 Local LLM을 호출해 양식 항목(제안 배경·개선 아이디어·기대 효과)별로 채워진 초안을 생성하고, 사용자가 보완 후 최종 등록. LLM은 초안만 만들고 확정은 사용자가 하는 구조로 자동화와 데이터 품질 사이의 균형 확보
• Linux 서버 배포·운영 로그 검증, Docker 실행 환경으로 개발/운영 환경 차이를 최소화하고 본부별 팀장·그룹장 설명회 4회를 지원

결과 · 성과

• 월평균 약 50건의 AX 과제가 접수되는 운영 체계로 정착
• LLM 초안 생성으로 등록 부담과 데이터 품질 문제를 동시에 개선
• 운영 확산 기여로 분기 우수 사원 수상

통합 자산관리 시스템 — 사내 IT 자산 운영 플랫폼

배경 · 문제

IT 자산이 엑셀로 관리되어 반납·재배정 시 데이터가 덮어쓰기되고 이력이 남지 않았습니다. 분실·미확인 자산이 발생해도 마지막 사용자·관리자·부서를 추적할 방법이 없었고, 실사 때마다 부서별 수작업 취합이 반복됐습니다. 등록 → 재배정 → 반납 전 과정을 단일 플랫폼으로 통합하고, 모든 변경이 “누가 · 언제 · 무엇을 어떻게 바꿨는지” 남는 구조로 전환했습니다.

접근 · 의사결정

• 전 기능을 한 번에 만들기보다, 현업이 가장 급했던 “이 자산이 어디 있는지”부터 해결하기 위해 조회 MVP를 먼저 배포하고 현업 피드백에 따라 반납·삭제·엑셀 연동·통계로 단계 확장
• 필드 단위 변경 이력(Audit Trail) — 수정 API에서 기존 데이터를 먼저 조회해 새 값과 필드 단위로 비교(diff)하고, 변경된 필드만 변경 전·후 값과 함께 이력 테이블에 저장. 본 데이터 UPDATE와 하나의 트랜잭션으로 묶어 이력 누락을 방지
• DB 트리거 대신 애플리케이션 레벨 이력화를 선택 — 트리거로는 알 수 없는 로그인 세션의 사번을 변경자로 기록해야 했기 때문. 데이터 오류 발생 시 이력 기준으로 원인 추적·복구 가능한 구조 확보
• 기존 엑셀 업무와 병행할 수 있도록 Apache POI 기반 대량 업로드/다운로드를 지원하고, 기존 5,900건은 검증 후 일괄 이관
• 부서·팀·사용자·관리자 정보를 분리 관리해 자산의 소유/관리 관계를 명확화하고, Chart.js로 부서별·연도별 현황 대시보드를 구성

결과 · 성과

• 자산 5,900건의 등록·조회·반납·재배정·이력 관리를 단일 시스템으로 통합, 전사 4개 본부 실사용 운영 중
• 이력 기반 추적으로 분실 처리 자산 약 1,000만 원 회수, 기한 내 자산 신고 완료
• 필드 단위 자동 이력으로 감사 추적(Audit Trail) 체계 확보, 헤드셋 관리 등 현업 요청 기반 기능 확장 지속

트러블슈팅 · 배운 점

DBOps — Mini DBMS 운영 관리 플랫폼

배경 · 문제

여러 MySQL 인스턴스의 상태 확인과 계정·권한 작업을 개별 CLI로 수행하면 작업 결과가 분산되고, 실패 시 어떤 명령이 어디까지 실행됐는지 추적하기 어렵습니다. 인스턴스 등록부터 상태 점검, 계정·권한 작업, 실행 이력 조회까지 하나의 플랫폼에서 관리하고, 작업이 실패해도 요청과 결과가 반드시 남는 DB 운영 관리 구조를 구현했습니다.

접근 · 의사결정

• 플랫폼의 인스턴스 정보와 작업 이력은 Meta DB, 실제 계정·권한 명령은 Target DB에서 처리하도록 분리. 런타임에 등록되는 DB에 접속할 수 있도록 동적 연결 구조를 구현하고, 접속 정보는 암호화해 저장
• Meta DB의 이력 저장과 Target DB의 DDL 실행은 하나의 트랜잭션으로 묶을 수 없음 — 분산 트랜잭션을 도입하는 대신 작업을 PENDING으로 먼저 기록하고, 실행 결과에 따라 SUCCESS / FAILED로 갱신하는 상태 기반 추적을 선택. 대상 DB 작업이 실패해도 요청 내용과 오류 원인이 사라지지 않도록 이력 저장은 독립 트랜잭션으로 분리
• CREATE USER, GRANT 같은 DDL은 권한명·계정 정보를 일반적인 파라미터 바인딩으로 처리하기 어려움 — 사용자명·호스트는 정규식으로 검증하고, 실행 가능한 권한은 enum 화이트리스트로 제한해 임의 SQL 실행을 방지
• Python Agent로 각 인스턴스의 커넥션 수·슬로우 쿼리 지표를 수집하고, 한 인스턴스의 접속 실패가 전체 수집을 중단시키지 않도록 인스턴스 단위로 예외를 격리
• 30초 주기 헬스체크와 상태 이력 테이블을 구성해, 현재 상태만 저장하는 대신 장애 발생과 복구 시점을 추적. Go CLI에서는 goroutine으로 여러 인스턴스를 병렬 점검

결과 · 성과

• 인스턴스 등록 → 상태 점검 → 계정·권한 작업 → 실행 이력 조회로 이어지는 DB 운영 흐름 구현
• MySQL 3개 인스턴스를 대상으로 장애·복구 감지와 지표 수집 흐름 검증
• Meta DB와 Target DB에 걸친 작업을 PENDING → SUCCESS / FAILED 상태로 추적
• SaltStack 설정 배포의 멱등성과 Kubernetes Pod 재기동(self-healing) 흐름 검증

트러블슈팅 · 배운 점