백엔드 시스템의 안정성과 AI 기반 업무 전환을 함께 설계합니다.
포트폴리오 한눈에 보기
| 프로젝트 | 해결한 문제 | 주요 역할 | 핵심 기술 |
|---|
| AI 개발 생산성 전환 | 에이전트의 도메인 이해 부족과 반복 업무 | 컨텍스트 설계, CLI 개발, 검토 워크플로 | Cursor Rules, TypeScript CLI, LLM review |
| 다중 소스 RAG 색인 | 느린 I/O와 중간 실패, 원천별 확장 | 파이프라인 설계·구현 | Java 21, Spring Batch, OpenSearch |
| 문서 파싱 품질 플랫폼 | 변환 품질 회귀와 워커 운영 불안정 | 품질 검증·병렬화·운영 개선 | Python, FastAPI, OCR, golden set |
| AI 웹툰 제작 도구 | 혼자 짧은 기간에 End-to-End AI 제품 완성 | 제품·아키텍처·AI 파이프라인 | Next.js, TypeScript, Gemini, PostgreSQL |
| 슬롯 백엔드 현대화 | 중복 구조, 캐시 동시성, 성능 병목 | 점진 리팩터링과 성능 개선 | Java 17, Spring Boot, Redis, MySQL |
프로젝트 1. AI를 개발 생산성과 실행 도구로 전환
문제
복잡한 슬롯 도메인에서 AI 에이전트는 코드 위치와 게임 규칙을 몰라 존재하지 않는 클래스를 사용하거나 잘못된 로직을 만들었습니다.
협업 도구와 클라우드 운영 업무는 사람이 화면과 여러 CLI를 오가며 반복해서 처리해야 했습니다.
목표
AI가 단순한 코드 생성 도구가 아니라 도메인 맥락을 이해하고, 검증 가능한 방식으로 개발과 운영 업무를 수행하도록 만드는 것이 목표였습니다.
역할
- 도메인 컨텍스트와 검토 기준 설계
- 에이전트가 호출할 CLI 인터페이스 설계·구현
- AI 구현 결과의 추적과 검토 흐름 설계
- LLM 코드리뷰와 자동 테스트 연결
설계와 구현
도메인 컨텍스트
- 공통 객체의 정확한 패키지, 슬롯 아키텍처와 테스트 규칙을 Cursor Rules로 작성했습니다.
- 게임별 심볼, 보너스 규칙과 캐시 대응 방법을 별도 규칙으로 분리했습니다.
- 규칙이 코드와 어긋나면 없는 것보다 위험하다고 보고 유지보수 대상을 명시했습니다.
사람 검토 중심 워크플로
- 에이전트 구현은
by agent 커밋으로 구분했습니다.
- RTP 계산과 특수 심볼 같은 도메인 규칙은 사람이 반드시 검토했습니다.
- 테스트와 검토를 통과한 결과만 실제 코드에 반영했습니다.
에이전트 친화 CLI
- 협업 시스템의 업무, 위키, 메일과 첨부 기능을 하나의 CLI로 통합했습니다.
- 모든 명령에 구조화 JSON 출력과 표준 종료 코드를 적용했습니다.
- 대화형 확인이 필요 없는 실행 경로와 파일 입력을 제공했습니다.
- 클라우드 리소스 98개 명령을 같은 계약으로 통합했습니다.
commands --json을 통해 에이전트가 런타임에 명령 카탈로그를 발견하도록 만들었습니다.
결과
- 20개 이상의 도메인 규칙을 구축했습니다.
- AI 에이전트를 통해 신규 슬롯 3종을 구현했습니다.
- 에이전트용 문서가 팀원의 도메인 온보딩에도 재사용됐습니다.
- 반복되는 협업과 클라우드 운영 업무를 사람과 에이전트가 공유하는 실행 도구로 전환했습니다.
배운 점
- AI 생산성은 모델 성능만으로 결정되지 않고 컨텍스트, 실행 계약과 검토 비용까지 포함해 설계해야 합니다.
- 자동화의 완료 기준은 명령이 실행되는 것이 아니라 사람이 실패 원인을 판단하고 안전하게 복구할 수 있는 것입니다.
- 다음 단계에서는 도입률, 반복 작업 시간, 자동화 성공률과 수동 개입률을 기준선과 함께 측정해야 합니다.
링크
프로젝트 2. 다중 소스 RAG 벡터 색인 파이프라인
문제
사내 지식 검색을 위해 여러 문서 원천을 임베딩하고 OpenSearch에 색인해야 했습니다.
동기 처리에서는 임베딩과 문서 파싱 I/O가 병목이 됐습니다.
중간 실패 시 처음부터 재처리하면 비용이 커지고 삭제된 원문이 검색 결과에 남는 문제도 있었습니다.
목표
- 실패 지점부터 재시작할 수 있어야 합니다.
- 페이지, 댓글, 첨부와 삭제 동기화의 실패 범위를 분리해야 합니다.
- 문서 원천이 늘어도 기존 파이프라인의 핵심 구조를 바꾸지 않아야 합니다.
- 변경되지 않은 문서의 임베딩 비용을 반복해서 지불하지 않아야 합니다.
역할
Spring Batch 구조 설계부터 Reader, Processor, Writer와 OpenSearch 색인까지 전체 파이프라인을 구현했습니다.
설계와 구현
11개 Step 분리
- 초기화
- 원천 수집
- 페이지 색인
- 댓글 색인
- 페이지·댓글·첨부 삭제 동기화
- 색인 갱신
- 실행 완료 처리
각 Step은 독립된 실행 결과를 남깁니다.
댓글 처리에서 실패해도 이미 완료된 페이지 색인 결과는 유지됩니다.
I/O 병렬화
AsyncItemProcessor로 임베딩과 문서 파싱 호출을 병렬 처리했습니다.AsyncItemWriter가 완료 결과를 모아 OpenSearch에 벌크로 색인합니다.- 동시 실행 수를 제한해 외부 API와 내부 자원을 과도하게 사용하지 않도록 했습니다.
변경 감지와 확장
- OpenSearch 문서 version과 원문의 version을 비교했습니다.
- 변경 없는 문서는 Processor에서 제외해 임베딩 호출을 줄였습니다.
- 원천별 메타데이터 차이는 Provider 전략으로 분리했습니다.
- 단일 스페이스에서 여러 스페이스로, 페이지에서 댓글·첨부파일까지 색인 범위를 확장했습니다.
검증
- Testcontainers로 OpenSearch와 MySQL을 포함한 통합 테스트를 구성했습니다.
- JaCoCo 커버리지 게이트와 SonarQube를 CI에 연결했습니다.
결과
- 사내 AI 서비스의 RAG 색인 기반을 처음부터 구축했습니다.
- 중간 실패 후 전체를 다시 실행하지 않고 필요한 Step부터 이어갈 수 있게 했습니다.
- 원천 추가와 삭제 동기화를 기존 핵심 흐름을 유지한 채 확장할 수 있게 했습니다.
배운 점
Spring Batch의 Step 분리는 코드 정리 수단이 아니라 운영 장애의 범위를 제한하는 장치였습니다.
재시작 상태와 실행 중 공유 데이터는 수명과 복구 목적이 다르므로 같은 저장소에 무조건 넣으면 안 됩니다.
링크
프로젝트 3. 문서 파싱 품질 검증과 워커 운영
문제
다양한 문서를 Markdown으로 변환하는 서비스는 설정과 라이브러리를 조금만 바꿔도 결과가 달라집니다.
기존 출력과 달라졌다는 사실만으로는 품질이 좋아졌는지 나빠졌는지 판단하기 어려웠습니다.
OCR 워커는 병렬 처리, GPU 상태와 메모리 단편화 때문에 운영 안정성 문제도 있었습니다.
목표
- 의도하지 않은 출력 회귀를 자동으로 차단합니다.
- 실제 정답에 가까워진 개선은 통과시킵니다.
- 표 구조의 손실을 일반 텍스트 점수와 별도로 검증합니다.
- 운영 서버에 영향을 주지 않고 실제 이미지로 검증합니다.
역할
- 워커 병렬 구조 개선
- 파서 모듈 분해
- 품질 검증 체계 설계
- 관측 정보 정리
- 메모리 증가 원인 분석과 개선
설계와 구현
두 층의 품질 검증
- 1차 회귀 검증은 이전 출력과 새 출력의 NED를 비교했습니다.
- 2차 절대 평가는 LLM 초안을 사람이 확정한 golden 출력과 비교했습니다.
- 표는 셀 누락과 위치 변경이 전체 문자 점수에 묻히지 않도록 셀 단위 F1으로 분리했습니다.
격리된 검증 환경
- 운영 인스턴스를 트래픽에서 빼 검증하던 방식을 폐기했습니다.
- 직접 만든 클라우드 CLI로 운영과 격리된 전용 GPU 인스턴스를 확보하고, 검증 대상 이미지만 바꿔 띄웠습니다.
- 평소에는 인스턴스를 정지해 두고 검증할 때만 시작하는 방식으로 재사용해 운영 영향과 비용을 줄였습니다.
워커 메모리 문제
- 워커 RSS가 시간당 약 1.4GB씩 증가하는 현상을 확인했습니다.
gc.collect() 이후에도 RSS가 줄지 않는 원인을 glibc allocator와 메모리 단편화 관점에서 분석했습니다.- OS 반환을 유도하는
malloc_trim을 적용하고 환경변수로 즉시 끌 수 있게 했습니다.
- 인스턴스 한 대에 먼저 배포해 검증한 결과 RSS가 일정 범위에서 유지되고 회귀가 없음을 확인했습니다. 다만 워커 재활용과 malloc_trim 단독 효과를 분리 측정하는 것은 다음 과제로 남겼습니다.
결과
- 품질 저하를 막으면서 개선 실험을 안전하게 반복할 수 있게 했습니다.
- 운영 자원을 점유하지 않는 검증 환경을 만들었습니다.
- 워커 강제 종료와 재예열 의존도를 낮췄습니다.
배운 점
- 관측 지표가 있다고 해서 올바른 의사결정이 가능한 것은 아닙니다.
- pending과 call queue처럼 의미가 다른 수치를 구분해야 확장 판단을 잘못하지 않습니다.
- AI 결과 품질은 하나의 종합 점수보다 실패 형태에 맞는 여러 지표로 평가해야 합니다.
링크
프로젝트 4. AI 웹툰 제작 도구
문제
한 명이 짧은 기간에 웹소설 분석부터 60컷 이미지 생성까지 이어지는 풀스택 AI 제품을 완성해야 했습니다.
긴 입력의 비용, 모델 rate limit, 부분 실패, 프롬프트 환각과 캐릭터 외형 일관성이 핵심 문제였습니다.
목표
- 운영자가 단계별 결과를 확인하고 수정할 수 있어야 합니다.
- 일부 이미지 생성이 실패해도 성공한 결과는 유지해야 합니다.
- 모델 장애나 제한 상황에서도 작업을 계속할 수 있어야 합니다.
- 원작 범위를 벗어난 서사 환각과 캐릭터 외형 변화를 줄여야 합니다.
역할
제품 요구사항, 프론트엔드, 백엔드, 데이터베이스, AI 호출 구조와 에이전트 개발 하네스를 단독으로 설계했습니다.
설계와 구현
모델·비용 전략
- 결과 품질이 낮아 재생성이 반복되면 저가 모델도 총비용이 커진다고 판단했습니다.
- pro를 우선 사용하고 429가 발생하면 flash와 lite로 넘어가는 fallback을 적용했습니다.
- 모델별 rate limit 상태를 전역으로 공유해 같은 실패 요청이 반복되지 않게 했습니다.
- 동일 소설은 Gemini Context Caching으로 여러 단계에서 재사용했습니다.
부분 실패 격리
- 60컷 이미지를 하나의 긴 SSE 작업으로 처리하지 않았습니다.
- 독립 작업의 성격에 맞게 브라우저에서
Promise.allSettled로 요청했습니다.
- 실패한 컷만 다시 실행할 수 있도록 상태와 오류를 컷별로 저장했습니다.
환각과 이미지 일관성
- continuation 호출마다 원작과 treatment grounding을 다시 전달했습니다.
- 허용되는 창의는 연출이고 서사는 원작 범위라는 경계를 명시했습니다.
- 캐릭터 외형은 텍스트 지시가 아니라 기준 이미지를 자동으로 첨부해 유지했습니다.
AI 개발 하네스
- 구현 전에 계획과 성공 기준을 파일로 고정했습니다.
- 실행, 비판적 검토와 문서 정합성 확인을 서로 다른 에이전트 역할로 분리했습니다.
- 본인은 요구사항과 기술 결정을 맡고 반복 구현을 에이전트가 수행하게 했습니다.
결과
- 12일 동안 199개 계획과 760개 커밋으로 MVP 범위를 완성했습니다.
- 운영자가 소설 분석부터 이미지 결과까지 단계별로 검토하는 제품 흐름을 구현했습니다.
- 디자이너와 파일 소유권을 분리해 로직과 시각 변경의 충돌을 줄였습니다.
배운 점
- AI 제품의 품질 문제는 프롬프트 문구보다 호출 경계와 컨텍스트 전달 구조에서 발생하는 경우가 많습니다.
- 자동화 생산성을 높이려면 에이전트 수보다 입력 요구사항과 검증 게이트의 정확도가 중요합니다.
- 비용 최적화는 모델 단가가 아니라 재생성까지 포함한 전체 작업 비용으로 판단해야 합니다.
링크
프로젝트 5. 슬롯 백엔드의 점진적 현대화
문제
슬롯마다 플레이 흐름과 당첨 규칙이 중복됐고 정적 데이터 갱신 중 조회 요청이 부분 상태를 읽어 NPE가 발생했습니다.
대규모 시뮬레이션은 난수 생성과 메모리 누적으로 성능과 안정성 문제가 있었습니다.
목표
- 검증되지 않은 추상화를 먼저 만들지 않습니다.
- 신규 슬롯을 추가할 때 기존 서비스 코드의 변경 범위를 줄입니다.
- 다중 서버 환경에서 캐시 갱신 중에도 조회 안정성을 유지합니다.
- 알고리즘과 벤치마크를 근거로 성능 병목을 해결합니다.
역할
- 신규 슬롯 5종 개발 (Slot 36·38·41·44·47)
- 슬롯 엔진 구조 개선
- 캐시 동시성 문제 해결
- 시뮬레이터 성능과 메모리 개선
- 테스트 구조와 AI 개발 컨텍스트 표준화
설계와 구현
점진적 추상화
- 슬롯 5종 이상을 직접 구현하며 실제로 반복되는 경계를 먼저 확인했습니다.
- 공통 플레이 흐름은 템플릿으로, 모드별 차이는 Handler로 분리했습니다.
- 당첨 계산의 부가 규칙은 Decorator와 Strategy로 조합했습니다.
- 신규 타입은 기존 코드를 수정하기보다 구현체 추가로 확장하도록 만들었습니다.
캐시 정합성
- 정적 데이터 갱신 시 기존 값을 비우고 다시 적재하는 구간에서 NPE가 발생했습니다.
- 갱신은
StampedLock write lock으로 보호했습니다.
- 조회는 제한 시간 안에 read lock을 얻지 못하면 실패를 명확하게 처리하도록 했습니다.
성능과 메모리
- 가중치 랜덤 선택의 병목을 분석하고 Alias Method 적용으로 시간 복잡도를 O(n)에서 O(1)로 낮출 수 있음을 정리했습니다.
- 1억 건 당첨금을 모두 저장하던 구조를 Welford Online Algorithm으로 변경했습니다.
- 평균과 분산 계산에 필요한 상태만 유지해 공간 복잡도를 O(N)에서 O(1)로 줄였습니다.
결과
- 슬롯별 중복 흐름을 공통 구조로 모으고 신규 규칙의 변경 범위를 줄였습니다.
- 정적 데이터 갱신 중 발생하던 NPE를 해소했습니다.
- 시뮬레이터의 OOM을 제거하고 성능 결정의 근거를 남겼습니다.
- 긴 수명의 레거시를 한 번에 교체하지 않고 테스트 가능한 구조로 발전시켰습니다.
배운 점
- 추상화의 시점은 재사용 가능성을 상상했을 때가 아니라 실제 중복의 경계를 확인했을 때입니다.
- 동시성 도구는 성능뿐 아니라 실패 시 동작과 운영자가 진단할 수 있는 상태까지 함께 설계해야 합니다.
- 작은 PR과 테스트 안전망은 장기 리팩터링을 실제로 끝내게 하는 실행 전략입니다.
링크
일하는 방식
현업 문제를 기술 언어로 바꿉니다
사용자가 말하는 증상을 바로 기능 요구사항으로 받아들이지 않습니다.
반복, 실패, 대기와 검토 비용을 구분하고 기술로 바꿀 수 있는 경계를 찾습니다.
AI 결과도 검증 가능한 소프트웨어로 다룹니다
LLM 출력은 정답으로 간주하지 않습니다.
스키마 검증, golden set, 회귀 테스트와 사람 검토를 조합합니다.
도구와 지식을 팀의 자산으로 남깁니다
일회성 스크립트보다 반복 실행 가능한 CLI와 skill을 선호합니다.
의사결정과 도메인 규칙을 문서로 남겨 사람과 에이전트가 함께 사용하도록 만듭니다.
다음 성장 목표
현업 조직과 직접 맞닿아 업무 병목을 발견하고 필요한 커넥터, 도구와 지식 기반을 빠르게 배포하는 AI 챔피언을 지향합니다.
도입 이후에는 다음 지표를 이용해 효과를 검증하고 지속적으로 개선하고자 합니다.
- 사용자 도입률과 활성 사용률
- 반복 업무의 처리 시간
- 자동화 성공률과 수동 개입률
- 지식의 최신성
- 지식의 참조 빈도와 재사용 범위