임준열

AXis — Node.js 기반 전사 AX 과제 운영 플랫폼

배경 · 문제

AX 관련 요청이 이메일과 구두로 접수되어 과제별 담당자·필수 정보·처리 상태가 서로 달랐습니다. 접수 이후 진행 상황을 일관되게 확인하기 어려워, 업무 흐름을 시스템에서 관리할 수 있는 구조가 필요했습니다.

설계 · 구현

• 과제·사용자 권한·처리 상태를 핵심 도메인으로 정의하고, 접수·조회·상태 변경을 위한 데이터 구조와 REST API 설계
• 접수·조회·상태 관리를 MVP로 먼저 출시하고, 운영 중 접수된 사용자 요구를 바탕으로 기능을 순차 확장
• 사용자가 짧은 설명을 입력하면 LLM이 항목별 초안을 제안하고, 사용자가 수정·확정하도록 해 자동 생성 결과가 검토 없이 업무 데이터가 되지 않도록 구성
• 사내 SSO 정보와 서비스별 접근 권한을 활용해, 사례 게시판에서 접근 가능한 AI 서비스를 iframe 방식으로 연계

운영 · 성과

• 본부별 설명회 4회 진행 및 피드백을 반영해 SSO·입력 지원·AI 사례 연결 기능 고도화
• AX 과제 접수를 월평균 약 50건 규모의 전사 운영 창구로 정착
• 요구 분석부터 현장 확산까지 책임진 성과로 분기 우수 사원 수상

↑ 프로젝트 목록으로

통합 자산관리 — 9,200건 자산의 변경 이력과 정합성 확보

배경 · 문제

기존 자산 목록은 부서별 엑셀로 관리되어 반납·재배정 과정에서 이전 정보가 덮어써졌습니다. 자산을 누가 사용했는지, 어디로 이동했는지 추적하기 어려워 분실·미확인 자산을 확인하는 데 한계가 있었습니다.

설계 · 구현

• 자산 위치 조회부터 시작해 등록·재배정·반납·변경 이력 및 통계 기능으로 단계 확장
• 변경 요청의 전·후 값을 비교하는 필드 단위 diff를 계산하고 실제 변경된 필드와 사용자·시각을 이력 테이블에 기록
• 본 데이터 UPDATE와 Audit INSERT를 하나의 트랜잭션으로 묶어 변경 내용과 이력의 불일치를 방지
• 이관 데이터 중 원본 값이 비어 있는 항목은 임의로 채우지 않고 ‘미입력’ 상태로 보존해 후속 확인 대상으로 관리

운영 · 성과

• 4개 본부의 IT 자산 약 9,200건을 단일 시스템에서 관리
• 변경 사용자·시점·이동 경로를 역추적해 분실 처리 자산 약 1,000만 원 회수
• 감사 대응 및 데이터 오류의 원인 추적에 활용할 수 있는 변경 이력 기반 확보

↑ 프로젝트 목록으로

공통 LLM Gateway 구축 · Local LLM 전환 및 운영

배경 · 문제

업무 성격에 따라 올거나이즈의 GPT 모델을 선택해 사용하고 있습니다. 복잡한 추론에는 고성능 모델을, 일반적인 작업에는 경량 모델을 적용하지만, 최저 크레딧 요금제의 기본 제공량을 초과하면 추가 사용 비용이 발생합니다. 서비스가 늘어나면서 모델 호출과 사용량·오류를 중앙에서 관리하고, Local LLM으로 대체 가능한 요청을 전환할 필요가 있었습니다.

아키텍처 · 의사결정

• LiteLLM Proxy를 공통 호출 진입점으로 사용하고, 기존 서비스는 서비스별 API Key로 호출하도록 구성해 인증과 모델 접근을 관리
• vLLM으로 SKT A.X·Gemma를 서빙하여 내부에서 추론 가능한 업무를 Local LLM으로 단계적으로 전환
• 외부 고성능·경량 GPT 선택 정책은 업무 난이도에 맞춰 유지하고, 초과 크레딧 비용을 유발하는 요청 중 내부 모델로 처리 가능한 영역을 분리
• OpenAI 호환 API를 활용해 모델 변경에 따른 서비스별 연동 부담을 줄이고, 호출 로그와 토큰 사용량을 PostgreSQL 기반으로 집계·분석
• 챗봇 1개에서 호출·로그·응답 흐름을 검증한 후 연계 서비스를 21개로 확대

운영 · 성과

• 21개 서비스에서 주간 약 2.2만 건·약 3,800만 토큰 처리
• 운영 로그 기준 정상 완료율 99.97% 확인 및 서비스·Key·모델별 요청 현황 모니터링
• 외부 서비스의 기본 크레딧 초과 사용 비용 부담을 줄일 수 있는 Local LLM 전환 기반 확보

운영 설계의 고려사항

모델별 응답 지연, 동시 요청 증가에 따른 처리량, 실패 로그 추적을 공통 운영 관점에서 다룹니다. MCP 기반 사내 도구 연계와 중앙 접근 권한 관리는 현재 구조에서 도입 방식을 검토하는 확장 과제로 구분합니다.

↑ 프로젝트 목록으로

DBOps — DB 운영·장애 추적 도구 GitHub ↗

배경 · 문제

여러 MySQL 인스턴스의 상태 확인과 계정·권한 작업을 개별 CLI로 수행하면 실행 결과와 장애 이력이 흩어집니다. 요청이 실패하더라도 실행 과정과 원인을 확인할 수 있는 운영 구조를 검증하고자 했습니다.

설계 · 구현

• Meta DB와 Target DB를 분리하고 런타임 등록 인스턴스에 동적으로 연결하는 구조 구현
• 관리 작업 요청을 PENDING 상태로 먼저 기록해 실패해도 이력이 남도록 트랜잭션 경계를 분리
• 정규식·권한 enum 화이트리스트로 임의 SQL 실행을 제한하고 대상 인스턴스별 오류 격리
• 30초 주기 헬스체크와 이력 저장, Go CLI의 goroutine 기반 병렬 상태 점검 구현

검증 · 개선

• MySQL 3개 인스턴스를 대상으로 장애·복구 감지 및 지표 수집 흐름 검증
• SaltStack 설정 배포의 멱등성 및 Kubernetes Pod 재기동 흐름 확인
• SaltStack 실행 이미지 문제를 로그로 분석하고 Python 기반 실행 환경 의존성을 명시해 재현 가능하도록 개선