임준열

AXis — Node.js 기반 전사 AX 과제 운영 백엔드

배경 · 문제

AX 과제가 메일과 구두로 들어오면서 접수 항목과 처리 상태가 담당자마다 달랐고, 진행 상황을 일관되게 추적하기 어려웠습니다.
정형화되지 않은 현업 업무를 시스템이 처리할 수 있는 데이터 구조와 API로 구체화하고, 실제 사용 과정에서 확인되는 요구를 다음 버전에 반영할 수 있는 운영 구조가 필요했습니다.

접근 · 의사결정

• 과제 정보·사용자/관리자 권한·처리 상태를 핵심으로 데이터 구조를 정의하고 접수·조회·상태 변경 REST API를 설계
• 기능을 한 번에 크게 만들기보다 접수·조회·상태 관리를 먼저 출시하고, 실제 사용 과정에서 확인한 요구를 후속 기능으로 반영하는 방식으로 단계 확장
• 사용자가 1~2줄을 입력하면 Local LLM이 항목별 초안을 생성하되, 사용자가 검토·수정한 뒤 확정하도록 해 자동 생성 결과가 그대로 업무 데이터가 되지 않도록 구성
• 기존 SSO 사용자 정보와 권한을 재사용하고, AI 에이전트 사례 게시판에서 사내 AI 서비스를 iframe으로 직접 실행하도록 연동하되 접근 가능한 서비스만 권한 범위 안에서 노출

출시 후 운영 · 개선

• 본부별 설명회 4회에서 불편 사항과 사용 패턴을 수집하고 SSO·LLM 입력 지원·권한 기반 iframe 실행 기능을 순차적으로 반영
• 월평균 약 50건이 접수되는 전사 AX 과제 창구로 정착
• 요구사항 정리부터 출시·운영·확산까지 책임진 성과로 분기 우수 사원 수상

통합 자산관리 — 9,200건 데이터의 정합성과 변경 이력을 관리하는 운영 백엔드

배경 · 문제

IT 자산이 부서별 엑셀로 관리되어 반납·재배정 때 기존 값이 덮어써졌고, 분실·미확인 자산의 마지막 사용자와 변경 경로를 추적할 수 없었습니다.
등록 → 재배정 → 반납 전 과정을 하나의 시스템으로 통합하면서, 현재 데이터와 변경 이력이 서로 어긋나지 않는 구조가 필요했습니다.

접근 · 의사결정

• 자산 위치 조회를 MVP로 먼저 배포하고 반납·재배정·이력·통계 기능을 실제 운영 요구에 맞춰 단계적으로 확장
• 수정 요청마다 변경 전 데이터를 조회해 새 값과 필드 단위 diff를 계산하고 실제로 바뀐 항목만 전·후 값, 사용자, 시점과 함께 이력 테이블에 저장
• 본 데이터 UPDATE와 Audit INSERT를 하나의 트랜잭션으로 처리해 데이터만 바뀌고 변경 이력이 누락되는 상태를 방지
• 애플리케이션 레벨에서 로그인 사용자 정보를 이력과 연결해 운영자가 값뿐 아니라 누가·언제·어떤 필드를 변경했는지 역추적할 수 있도록 설계

결과 · 성과

• 자산 약 9,200건의 등록·조회·반납·재배정·이력 관리를 단일 시스템으로 통합하고 전사 4개 본부 실사용 운영
• 이력 기반으로 마지막 사용자와 변경 경로를 추적해 분실 처리 자산 약 1,000만 원 회수 및 기한 내 자산 신고 완료
• 필드 단위 Audit Trail을 기반으로 감사 대응과 데이터 오류 원인 추적 체계 확보

데이터 이관 · 검증

21개 서비스를 위한 Local LLM Gateway·MCP 업무 실행 플랫폼

배경 · 문제

서비스마다 외부 LLM API를 직접 호출하면 인증·사용량·비용·오류 로그가 분산되고, 모델 변경 시 서비스별 수정 범위도 커집니다.
여러 서비스가 하나의 호출 계층을 공유하면서도 서비스별 사용량과 오류를 분리해 추적할 수 있는 공통 Gateway가 필요했습니다.

접근 · 의사결정

• 서비스가 모델을 직접 호출하지 않고 LiteLLM Proxy를 거치도록 구성해 API Key 인증·호출 로그·토큰 집계를 한 지점에 일원화
• OpenAI 호환 인터페이스를 유지해 모델 교체 시 개별 서비스 코드의 수정 범위를 줄이고, SpendLogs의 토큰·응답 시간·Key·팀 정보를 PostgreSQL에 저장
• 처음부터 전사 적용하지 않고 챗봇 1개에서 호출 흐름을 검증한 뒤 21개 서비스로 단계 확산해 적용 범위를 넓힘
• 서비스별 전용 연동 대신 MCP를 공통 Tool 어댑터 계층으로 두고 자산관리·AXis·RAG API의 요청·응답·오류 규격을 맞춰 여러 Client에서 재사용

정합성 · 관측성

• Safe Write — SSO 권한 검증과 Prepare → Commit, operation_id·멱등성 키로 중복·오실행 방지
• Audit & Observability — 사용자·도구·상태·오류·지연을 기록하고 모델 SpendLogs와 trace_id로 연결
• Multi-client — 동일 MCP Server를 OpenWebUI와 AXis Assistant에 연결해 Tool 스키마와 권한 정책을 재사용

결과 · 성과

• 21개 서비스 실트래픽 처리 — 주간 약 2.2만 건 / 약 3,800만 토큰, 운영 로그 기준 정상 완료율 99.97%
• 서비스·Key·팀별 사용량과 모델 호출부터 Tool 실행까지 이어지는 운영 관측 경로 확보
• 동일 사용량을 외부 LLM API로 처리하는 경우와 비교해 월 약 1,000만 원 비용 절감 및 내부 데이터의 외부 전송 범위 축소

로그 기반 트러블슈팅

DBOps — DB 운영·장애 추적 개인 프로젝트 GitHub ↗

배경 · 문제

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

접근 · 의사결정

• Meta DB와 Target DB를 분리하고 런타임 등록 인스턴스를 위한 동적 연결 구조 구현
• 요청을 PENDING으로 먼저 기록하고 독립 트랜잭션으로 이력을 남겨 실패 원인 보존
• 정규식·권한 enum 화이트리스트로 임의 SQL을 제한하고 인스턴스 단위로 예외 격리
• 30초 주기 헬스체크와 상태 이력으로 장애·복구 시점을 추적하고, Go CLI에서는 goroutine으로 여러 인스턴스를 병렬 점검

결과 · 성과

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

트러블슈팅 · 배운 점