임준열

Backend Engineer
010-3309-2284 ojo228412@gmail.com
임준열 프로필 사진

Introduce

SKT 고객센터 운영사 서비스에이스에서 백엔드를 단독으로 맡아 전사 운영 업무 도메인을 0부터 설계하고 운영했습니다. 상담 현장은 데이터가 어긋나면 곧바로 잘못된 안내와 금전 손실로 이어지는 환경이라, 정합성과 추적 가능성을 지키는 데 집중했습니다.

전사 운영 플랫폼을 단독으로 운영하며 데이터 변경을 필드 단위 Audit Trail로 남겼고, 이력 추적을 통해 분실 처리 자산 약 1,000만 원을 회수했습니다. Local LLM 공통 호출 계층에서 모델 요청을 추적하고, MCP 환경에서는 Tool 실행까지 동일 Trace로 연결했습니다. 7개 사내 서비스의 주간 약 1.6만 건 요청을 안정적으로 운영하며, 외부 LLM API 비용을 월 약 100만 원 절감하고 있습니다.

Skills

Backend
JavaSpring BootJPAREST API
Database
MySQLPostgreSQL
Infra / Ops
LinuxDockerKubernetesSaltStackPythonGo
AI Platform
LiteLLMOpenWebUILocal LLMMCPTool Calling
Web / Tools
VueJavaScriptGitGitHub

Career

정규직 · 2024.07 ~ 재직 중
SKT 고객센터 운영 계열사 · AI 전략팀 매니저 — 전사 운영 플랫폼 및 AI 인프라 구축·운영
  • LiteLLM Proxy와 PostgreSQL을 기반으로 사내 Local LLM 공통 호출·사용량 추적 구조 구축, 7개 서비스에서 주간 약 1.6만 건·약 1,450만 토큰 처리 및 외부 LLM API 비용 월 약 100만 원 절감
  • 3인 협업으로 진행한 Local LLM 프로젝트에서 자산관리·AXis·RAG API를 MCP Tool로 연동하고, SSO 권한·Audit Trail·호출 관측을 적용한 업무 실행 계층 구현
  • 통합 자산관리와 AXis를 요구사항 정의부터 단독으로 개발·배포·운영해 전사 실사용 서비스로 정착
  • IT 자산 6,200건을 필드 단위 변경 이력(Audit Trail) 구조로 통합하고, 이력 추적으로 분실 처리 자산 약 1,000만 원 회수
  • AXis 월평균 약 50건 접수 체계를 정착시키고 Local LLM 초안 생성을 적용해 등록 부담 완화 · 분기 우수 사원 수상

Projects 대표 2건 · 그 외 프로젝트는 경력기술서에 기재

Local LLM·MCP 기반 사내 AI 에이전트 플랫폼 전환상세 ↗

3인 협업 · 2026.05 ~ 진행 중
LiteLLM · OpenWebUI · PostgreSQL · MCP · Tool Calling · DGX Spark 기반 Local LLM
  • 외부 LLM API 의존 구조를 사내 장비 기반으로 전환하고 LiteLLM Proxy에서 인증·로그·토큰 집계를 일원화
  • OpenWebUI에 MCP 서버를 연결하고 자산관리·AXis·RAG API의 요청·응답·오류 규격을 통일해 Tool Calling 흐름 적용
  • 쓰기 작업에 SSO 권한 검증, Prepare → Commit, 멱등성 제어와 Audit Trail을 적용
  • 모델 호출과 Tool 호출을 동일 Trace로 연결해 도구별 호출량·성공률·지연·오류를 PostgreSQL에서 통합 관측하는 구조 구축
  • 사내 서비스 7개 연동 — 주간 약 1.6만 건 · 약 1,450만 토큰 · 운영 로그 기준 정상 완료율 99.97%, 외부 LLM API 비용 월 약 100만 원 절감

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

단독 개발 · 2026.01 ~ 운영 중
메일·구두로 흩어진 전사 AX 과제 접수를 상태 기반 프로세스와 구조화된 데이터로 전환
Java · Spring Boot · MySQL · Vue · Docker · Linux · Local LLM
  • 제안 → 접수 → 검토 → 상태 관리 흐름과 사용자·관리자 권한을 설계하고 개발·배포·운영까지 단독 수행
  • 1~2줄 입력을 Local LLM이 항목별 초안으로 확장하고 사용자가 검토·확정하는 흐름 구현
  • SSO 권한에 따라 연동 서비스를 노출해 AXis를 사내 AI 활용 허브로 확장
  • 월평균 약 50건 접수 체계 정착 · 본부별 설명회 4회 진행 — 분기 우수 사원 수상

Education

2024.05 ~ 2026.02
학점은행제 컴퓨터공학과 학사
2017.03 ~ 2021.02
인덕대학교 기계설계학과 전문학사
2023.03 ~ 2023.08
쌍용강북교육센터 Java·Spring 기반 AWS 클라우드 융합 개발 과정 수료 · 896시간

Certificate

2025.12
정보처리기사
2024.11
컴퓨터활용능력 1급
2023.07
SQLD SQL 개발자

Military

2017.10 ~ 2019.06
육군 8사단 기갑수색대대 대형운전병 · 병장 만기제대

경력기술서

문제 정의, 설계 판단, 운영 결과를 중심으로 작성했습니다.

서비스에이스

2024.07 ~ 재직 중 · AI 전략팀 (매니저)

Local LLM·MCP 기반 사내 AI 에이전트 플랫폼 전환

기간 · 2026.05 ~ 진행 중 · 3인 협업 담당 범위 · LiteLLM–PostgreSQL 운영 구조, Local LLM 호출 연동, 자산관리·AXis 및 팀원 담당 RAG API의 MCP Tool 연계 LiteLLM · OpenWebUI · PostgreSQL · MCP · Tool Calling · DGX Spark 기반 Local LLM(SKT A.X 4.0)
배경 · 문제

외부 LLM 비용과 내부 정보 전송 문제를 줄이고 서비스별 사용량을 추적하기 위해 사내 Local LLM 공통 운영 계층을 구축했습니다.
이후 자산관리·AXis·RAG를 MCP Tool로 연결해 실데이터 조회와 승인된 업무 실행까지 확장했습니다.

접근 · 의사결정
  • 서비스가 모델을 직접 호출하지 않고 LiteLLM Proxy를 거치도록 구성해 API Key 인증·호출 로그·토큰 집계를 한 지점에 일원화
  • OpenAI 호환 인터페이스로 모델 교체 영향을 줄이고, SpendLogs의 토큰·응답 시간·Key·팀 정보를 PostgreSQL에 저장
  • 챗봇 1개로 호출 흐름을 검증한 뒤 AXis·RPA 포털·VOC 대시보드 등 7개 사내 서비스로 단계 확산
  • 전용 플러그인 대신 MCP를 표준 어댑터 계층으로 채택 — OpenWebUI를 MCP Client로 구성하고 기존 API를 표준 Tool로 노출해 tools/list 탐색과 tools/call 실행 흐름 검증
  • 3인 협업으로 담당 영역을 나누고 요청·응답·인증·오류 규격을 합의해 독립 개발 결과를 통합
MCP 기반 업무 실행 계층
  • Read Tool — 자산·AXis·RAG 조회 API를 업무 단위 Tool로 노출하고 입력·오류 규격과 접근 범위를 서버에서 통제
  • Safe Write — SSO 권한 검증과 Prepare → Commit, operation_id·멱등성 키로 중복·오실행 방지
  • Audit & Observability — 사용자·도구·상태·오류·지연을 기록하고 SpendLogs와 trace_id로 연결
  • Multi-client — 동일 MCP Server를 OpenWebUI와 AXis Assistant에 연결해 스키마·권한 정책 재사용
결과 · 성과
  • 7개 서비스 실트래픽 처리 — 주간 약 1.6만 건 / 약 1,450만 토큰, 운영 로그 기준 정상 완료율 99.97% 및 Key·팀별 모니터링 확보
  • 3인 협업 결과를 MCP 계층에 통합해 자산관리·AXis 조회, RAG 검색, 승인 기반 쓰기를 수행하는 업무 에이전트 진입점 구축
  • 사내 Local LLM으로 전환해 내부 데이터의 외부 노출 가능성을 축소하고 외부 LLM API 비용 월 약 100만 원 절감
트러블슈팅 · 배운 점

MCP 연결은 정상이지만 유사 Tool 오선택과 필수 인자 누락으로 tools/call 검증이 실패했습니다.
OpenWebUI와 MCP Server 로그를 trace_id로 대조해 겹치는 Tool 설명과 느슨한 inputSchema를 원인으로 확인했습니다.
Tool 이름·사용 조건을 구체화하고 required·enum·additionalProperties: false를 적용했으며, 권한별로 필요한 Tool만 노출하고 검증 오류는 수정 항목이 드러나는 구조화된 응답으로 반환해 잘못된 호출과 재시도를 줄였습니다.
MCP 안정성은 서버 연결이 아니라 모델이 이해할 수 있는 Tool 계약과 노출 정책이 좌우한다는 점을 확인했습니다.

↑ 목록으로

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

기간 · 2026.01 ~ 2026.05 구축 · 이후 운영·고도화 지속 담당 범위 · 요구사항 정의, 설계, 백엔드·프론트엔드 개발, 배포, 운영, 사용자 확산 전반(단독) Java · Spring Boot · MySQL · Vue · Docker · Linux · Local LLM
배경 · 문제

메일·구두로 흩어진 AI 전환 수요를 일관되게 분류하고 처리 상태까지 관리하기 위해 구조화된 접수 플랫폼을 구축했습니다.

접근 · 의사결정
  • 제안 → 접수 → 검토 → 상태 관리 프로세스와 역할·API 권한을 분리하고 과제 정보를 컬럼 단위로 구조화
  • 사용자가 1~2줄을 입력하면 Local LLM이 항목별 초안을 생성하고, 사용자가 검토·수정한 뒤 확정하도록 해 자동화와 책임 있는 입력 사이의 균형 확보
  • AI 사례와 일부 사내 서비스를 연동하고 SSO 권한으로 노출 범위를 통제해 AI 활용 허브로 확장
  • Docker·Linux 운영 환경을 검증하고 본부별 설명회 4회로 사용자 정착 지원
결과 · 성과
  • 월평균 약 50건 접수 체계 정착 및 LLM 초안 생성으로 등록 부담 완화
  • SSO 기반 연동과 설명회 4회를 통해 AXis를 사내 AI 활용 허브로 확장
  • 플랫폼 구축과 운영 확산 기여로 분기 우수 사원 수상
↑ 목록으로

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

담당 범위 · 요구사항 정의, 시스템 설계·개발, 기존 데이터 이관, 배포·운영 Java · Spring · MySQL · JavaScript · Apache POI · Chart.js — 자산 약 6,200건 / 전사 4개 본부
배경 · 문제

IT 자산이 부서별 엑셀로 관리되어 반납·재배정 때 기존 값이 덮어써졌고, 분실·미확인 자산의 마지막 사용자와 변경 경로를 추적할 수 없었습니다.
등록 → 재배정 → 반납 전 과정을 단일 플랫폼으로 통합하고, 모든 변경이 사용자·시점·필드 단위로 남는 구조로 전환했습니다.

접근 · 의사결정
  • 자산 위치 조회를 MVP로 배포하고 반납·재배정·엑셀·통계 기능을 단계적으로 확장
  • 수정 전 데이터를 조회해 새 값과 필드 단위 diff를 계산하고 변경된 항목만 전·후 값과 함께 이력 테이블에 저장
  • 본 데이터 UPDATE와 이력 INSERT를 하나의 트랜잭션으로 처리해 본 데이터만 바뀌고 이력이 빠지는 상황 방지
  • 애플리케이션 레벨 이력화로 로그인 사번을 기록하고 오류 원인 추적·복구가 가능하도록 설계
결과 · 성과
  • 자산 약 6,200건의 등록·조회·반납·재배정·이력 관리를 단일 시스템으로 통합, 전사 4개 본부 실사용 운영
  • 이력 기반 추적으로 분실 처리 자산 약 1,000만 원 회수 및 기한 내 자산 신고 완료
  • 필드 단위 Audit Trail을 기반으로 감사 대응과 데이터 오류 원인 추적 체계 확보
트러블슈팅 · 배운 점

기존 데이터 이관 중 일부 관리 항목 누락을 확인했습니다.
임의 보정 대신 ‘미입력’ 상태로 분리·가시화해 통계와 이력의 신뢰도를 유지했습니다.
데이터 이관은 값을 옮기는 작업이 아니라 관리 기준을 다시 세우는 과정임을 배웠습니다.

↑ 목록으로

개인 프로젝트

DBOps — Mini DBMS 운영 관리 플랫폼 GitHub ↗

개인 프로젝트 · 설계·구현 전반 Java · Spring Boot · JPA · MySQL · Vue · Docker · Python · Go · SaltStack · Kubernetes
배경 · 문제

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

접근 · 의사결정
  • Meta DB와 Target DB를 분리하고 런타임 등록 인스턴스를 위한 동적 연결 구조 구현
  • 요청을 PENDING으로 먼저 기록하고 독립 트랜잭션으로 이력을 남겨 실패 원인 보존
  • 정규식·권한 enum 화이트리스트로 임의 SQL을 제한하고 인스턴스 단위로 예외 격리
  • 30초 주기 헬스체크와 상태 이력으로 장애·복구 시점을 추적하고, Go CLI에서는 goroutine으로 여러 인스턴스를 병렬 점검
결과 · 성과
  • 인스턴스 등록 → 상태 점검 → 계정·권한 작업 → 실행 이력 조회로 이어지는 DB 운영 흐름 구현
  • MySQL 3개 인스턴스를 대상으로 장애·복구 감지와 지표 수집 흐름 검증
  • SaltStack 설정 배포의 멱등성과 Kubernetes Pod 재기동(self-healing) 흐름 검증
트러블슈팅 · 배운 점

SaltStack 이미지 태그 중단으로 python:3.10-slim 기반 실행 환경을 구성했습니다.
docker logs에서 누락 의존성을 찾아 보완하고 Dockerfile에 명시해 재현 가능한 환경으로 전환했습니다.

↑ 목록으로