SK텔레콤 고객센터 운영사인 서비스에이스 AI 전략팀에서 Java·Spring Boot 기반 사내 업무 시스템과 AI 공통 플랫폼을 개발·운영하고 있습니다. 요구사항 정리부터 데이터·API 설계, TypeScript 화면 개발, 배포·운영까지 담당하는 백엔드 엔지니어입니다.
사내 AX 활용 과제의 접수·진행 상황을 관리하는 플랫폼과 전사 IT 자산관리 시스템을 단독으로 구축했습니다. 부서별로 관리하던 약 9,200건의 자산을 하나의 시스템으로 통합하고, 자산의 사용자와 변경 이력을 추적해 분실 처리된 약 1,000만 원 상당의 자산을 회수했습니다.
또한 3인 협업으로 21개 사내 서비스가 이용하는 AI 공통 플랫폼을 구축·운영했습니다. 서비스별 인증·사용량·오류 기록을 한곳에서 관리하고, 요청 처리 과정을 로그로 연결해 오류가 발생한 지점을 추적할 수 있도록 구성했습니다.
기능 정의, API와 데이터 처리, 트랜잭션, 화면 연동, 운영 개선을 실제 구현 과정에 따라 정리했습니다.
메일·구두로 들어오는 AX 과제의 접수 항목과 처리 기준이 담당자마다 달라 진행 상황을 추적하기 어려웠습니다. 과제 정보와 처리 상태를 공통 데이터로 관리하고, 운영 중 확인한 요구를 단계적으로 반영할 수 있는 시스템을 구축했습니다.
과제 정보, 사용자·관리자 권한, 처리 상태를 먼저 정리했습니다. 접수·조회·상태 변경에 필요한 데이터와 API를 정의하고, 처리 상태를 기준으로 진행 상황을 확인할 수 있게 설계했습니다.
과제 접수·조회·상태 변경 기능을 REST API로 구현했습니다. 화면에서 받은 과제 정보를 MySQL에 저장·조회하고, 처리 상태를 갱신하는 업무 로직을 Java·Spring Boot 백엔드에서 처리했습니다.
과제 작성·목록 조회·진행 상태 확인 화면을 개발하고 백엔드 API와 연결했습니다. 사용자와 관리자가 동일한 과제 데이터를 기준으로 접수와 후속 처리를 진행하도록 구성했습니다.
기존 SSO 사용자 정보를 재사용하고 로그인 사용자의 권한 범위에서 기능을 제공했습니다. AI 사례 게시판에서는 사내 AI 서비스를 iframe으로 실행하되 접근 가능한 서비스만 노출했습니다.
사용자가 1~2줄을 입력하면 Local LLM이 항목별 초안을 생성하도록 연동했습니다. 생성 결과는 사용자가 검토·수정한 뒤 확정하도록 구성했습니다.
접수·조회·상태 관리 기능을 먼저 배포하고, 본부별 설명회 4회에서 수집한 불편 사항을 후속 배포에 반영했습니다. SSO·LLM 입력 지원·권한 기반 AI 서비스 연동을 순차적으로 확장했습니다.
부서별 엑셀에서 자산을 관리해 반납·재배정 때 이전 값이 덮어써졌고, 마지막 사용자와 이동 경로를 확인하기 어려웠습니다. 자산의 현재 상태와 변경 이력이 함께 남도록 등록·조회·반납·재배정 업무를 통합했습니다.
자산 등록·조회·반납·재배정 기능을 REST API로 구현했습니다. JPA·MySQL 기반으로 자산 정보를 조회·저장하고, 현재 상태와 변경 이력을 구분해 관리할 수 있도록 데이터 구조를 설계했습니다.
수정 요청을 받으면 기존 데이터를 조회해 새 값과 필드별로 비교했습니다. 실제 변경된 항목만 전·후 값, 로그인 사용자, 변경 시점과 함께 이력으로 만들어 누가 어떤 값을 바꿨는지 추적할 수 있게 했습니다.
자산 정보 UPDATE와 Audit Trail INSERT를 하나의 업무 단위 트랜잭션으로 묶었습니다. 처리 중 예외가 발생하면 전체를
롤백해 자산 값만 변경되거나 이력만 남는 부분 반영을 방지했습니다.
자산번호·사용자·상태·변경 시점 등 화면에서 반복되는 조회 조건과 정렬 기준을 중심으로 인덱스를 구성했습니다. 조회 빈도와 등록·수정 시 인덱스 유지 비용을 함께 고려해 적용 범위를 정했습니다.
등록·조회·반납·재배정 화면을 백엔드 API와 연결하고, 자산 정보와 변경 이력을 확인할 수 있게 구성했습니다. 자산 현황 통계는 Chart.js로 시각화했습니다.
누락된 관리 항목을 ‘미입력’ 상태로 구분해 가시화하고 후속 확인 대상으로 관리했습니다. 원본 데이터의 불확실성을 보존해 이후 통계와 변경 이력을 검증할 수 있도록 했습니다.
서비스마다 LLM을 직접 호출하면서 인증·사용량·오류 로그가 분산됐고, 요청이 몰리면 제한된 추론 자원의 처리량을 초과했습니다. 공통 호출 계층을 두고 요청량을 제어하며, 모델 요청과 업무 실행을 하나의 경로로 추적하도록 구성했습니다.
모델 요청이 공통 Gateway를 거치도록 구성해 API Key 인증·호출 로그·토큰 집계를 일원화했습니다. OpenAI 호환 인터페이스를 유지하고 챗봇 1개에서 검증한 뒤 21개 서비스로 적용 범위를 넓혔습니다.
추론 서버의 처리 가능량을 초과하는 요청은 대기열에 보관하고 처리 가능한 범위만 전달했습니다. PostgreSQL 로그의 요청량과 지연을 대조해 요청 대기와 모델 추론의 병목을 구분했습니다.
자산관리·AXis·RAG 연동에 필요한 요청·응답·인증·오류 규격을 3인이 합의했습니다. MCP를 공통 Tool 어댑터로 두고 OpenWebUI와 AXis Assistant에서 동일한 Tool 계약과 권한 정책을 재사용했습니다.
SSO 권한 검증 후 Prepare → Commit 순서로 작업하도록 구성했습니다. operation_id와 멱등성 키를 적용하고
사용자·도구·처리 상태를 Audit Trail에 남겨 중복·오실행을 방지했습니다.
토큰·응답 시간·Key·팀 정보를 PostgreSQL에 저장하고, 모델 호출과 MCP Tool 실행을 동일한 trace_id로 연결했습니다.
서비스·Key·Tool별 호출량·지연·오류를 조회해 실패 구간을 추적했습니다.
유사 Tool 오선택과 필수 인자 누락이 발생했을 때 Client·MCP Server 로그를 같은 Trace로 대조했습니다. Tool 이름·사용 조건을 명확히 하고
required·enum·additionalProperties: false를 적용해 호출 검증을 강화했습니다.
여러 MySQL 인스턴스의 상태 확인과 계정·권한 작업을 개별 CLI로 수행하면 결과가 흩어지고 실패한 요청을 추적하기 어려웠습니다. 인스턴스 등록부터 작업 실행·상태 점검·이력 조회까지 관리하고, 작업 실패 후에도 요청 기록이 남는 구조를 구현했습니다.
인스턴스 등록·상태 점검·계정 및 권한 작업·실행 이력 조회 기능을 구현했습니다. JPA·MySQL 기반 관리 데이터와 실제 작업 대상 DB를 분리하고, 실행 중 등록한 인스턴스에도 연결할 수 있도록 구성했습니다.
요청을 먼저 PENDING으로 기록한 뒤 대상 DB 작업을 실행했습니다. 실행 트랜잭션과 이력 저장 경계를 분리해 작업이 실패해도 요청 정보와 실패 원인을
확인할 수 있게 했습니다.
정규식과 권한 enum 화이트리스트로 허용된 작업만 실행하도록 제한했습니다. 인스턴스마다 예외를 처리하고 성공·실패 상태를 별도로 기록해 한 DB의 접속 실패가
전체 점검을 중단하지 않도록 했습니다.
30초 주기 Health Check 결과를 상태 이력으로 남겨 장애·복구 시점을 확인했습니다. 인스턴스·상태·실행 시점을 기준으로 이력을 조회하도록 구성하고, Go CLI에서는 goroutine으로 여러 인스턴스를 병렬 점검했습니다.
SaltStack 이미지 태그 중단 시 python:3.10-slim 기반 실행 환경을 구성했습니다. docker logs로 누락
의존성을 찾아 Dockerfile에 반영하고, SaltStack 멱등 배포와 Kubernetes Pod 재기동 흐름을 검증했습니다.