미리보기

기술스택: Java8, SpringBoot 2, MariaDB, JPA, Redis, Elasticsearch, RabbitMQ, Docker, Jenkins CI/CD

다빈치 챗봇 솔루션 개발

• 대시보드 및 챗봇 시나리오 등 관리자 기능 개발

• Junit5 테스트환경 구축 및 테스트코드(약 500개의 테스트케이스) 작성

• 솔루션 배포 프로세스 정립 및 구축

• 솔루션 패키징 및 관리(Docker 기반)

  • MSA 아키텍쳐 & 다중 서버 기반

서울데이터 허브 AI 챗봇 개발

• 기존 '열린데이터 광장'의 공공데이터 활용 및 접근성 향상을 위한 플랫폼 서비스

  • 전국 지방자치단체중 최초의 RAG 기반 AI 챗봇 서비스

• 지식베이스 구축을 위한 스케줄러 개발

• 지식베이스 벡터화 및 검색 모듈 개발

• 프롬프트 테스트 자동화를 통한 프롬프트 엔지니어링 환경 개선

  • 자동화 프로세스 기획 및 구현

기술스택: Java11, SpringBoot 2, MariaDB, JPA, Apache Kafka, Mosquitto, K8S(EKS)

카봄 서비스 개발

• ReactJS TypeScript 기반의 SPA 페이지 개발

• CS 업무를 자동화/효율화하는 백오피스 기능 개발

• IoT 패킷 데이터 분석

프로젝트 개요

• 기존 ‘열린데이터 광장’ 기반 공공데이터 활용 및 접근성 향상을 위한 통합 플랫폼 서비스(서울데이터 허브)

• 지방자치단체 최초로 RAG 기반 AI 챗봇 서비스를 도입하여 공공데이터의 최신 질의응답 기능 제공

주요 기능 및 개발 내용

1. 지식 베이스 구축을 위한 스케줄러 개발

   • RAG 과정에 필요한 지식베이스 구조 설계 및 스크랩, 전처리, 저장 프로세스 과정을 설계 및 구현

     • 웹 스크랩 중 정적페이지 처리가 대부분인 상황을 고려하여, 성능에 유리한 Jsoup을 도입(비교 도구: Selenium, HtmlUnit)하여 지식베이스 구축

   • 스케줄러의 정기적인 데이터 수집을 통해 최신 공공데이터를 반영

2. 지식베이스 벡터화 및 검색 모듈 개발

   • LLM 모델(HyperCLOVA X)을 응용한 환각 축소 RAG 질의응답 서비스 제공

     • 지식베이스의 데이터셋을 벡터화하여 의미 기반 검색 기능을 구현

3. 프롬프트 테스트 자동화

   • 동료들의 프롬프트 작업 과정에서 반복된 테스트와 테스트 결과 관리 부실을 해소하기 위해, 프롬프트 엔지니어링의 반복 작업을 자동화하여 운영 효율성을 향상 및 비용 절감

   • 답변 정확도 및 응답 생성시간 측정을 개선하여 프롬프트를 최적화할 수 있도록 지원

프로젝트 개요

• 챗봇 솔루션의 시나리오 배포 기능에서 발생하는 오류를 해결하는 프로젝트

• 서버 모듈(API와 시나리오 모듈)간 연계처리 및 다중서버 환경에서 발생하는 동시성 문제를 분석 및 해결

기술적 도전과 해결

1. 배포 처리 상태 갱신 누락 문제

   • 문제: 모든 시나리오 서버가 배포 처리를 완료했음에도 불구하고 배포 상태가 여전히 '배포 처리중'으로 남는 문제 발생

   • 원인: 여러 시나리오 서버에서 발행된 배포 완료 메시지를 동시에 다른 트랙잭션에서 처리하는 과정에서 JPA 쓰기 지연 및 트랜잭션의 격리 수준(READ_COMMITED)으로 인해 다른 서버의 최신 배포 상태를 확인하지 못하게 됨

   • 해결:

     • 데이터 동시성 이슈를 해결하기 위해 기능의 특성상 사용량이 적으며 성능의 측면보다 정확도 측면을 고려하여 락을 도입하기로 결정

       
       (JPA flush 호출, 트랜잭션의 격리 수준 변경, 낙관적 락은 다른 트랜잭션의 조회 시점 전 데이터의 읽기 최신성을 보장할 수 없을 것으로 보고 배제)

     • RDB의 비관적 락과 Redisson 분산 락 도입을 검토하였으며, IO가 많은 RDB의 부담을 덜고 다중 서버 구성에서의 데드락을 방지하기 위해 Redisson 분산 락 적용을 결정

     • 유사한 동시성 문제의 예방을 위해 Spring AOP를 활용한 관점 지향 프로그래밍을 도입하여 관련 로직을 일관되게 관리하도록 구현

2. 비동기 메시지 처리 실패 문제

   • 문제: 시나리오 서버에서 비동기 요청 메시지(MQ)를 제대로 소비하지 못하는 경우, 보상 트랜잭션이 실행되지 않아 배포 상태가 '배포 처리중'으로 남는 문제가 발생

   • 원인:

     • Redis의 Keyspace Notifications 기능을 활용해 key 만료 이벤트를 처리하려 했으나, Redis Cluster 환경에서 등록된 키가 만료된 후에도 이벤트가 제대로 구독되지 않는 현상이 발생

       • 소규모의 메세징이 요구되는 점과 재처리 보다는 배포 실패로 기록해야하는 기능 특성상 mq 의 TTL/Dead Letter Exchange 보다는 Redis의 Keyspace Notifications가 적합하다고 판단

     • 트러블 슈팅 결과, Redis 서버 설정(slave-read-only)으로 인해 Master 노드에 기록된 키 만료 알람이 읽기 전용인 Slave 노드에서 Redisson이 구독을 시도하면서 Redis Cluster 에서는 일반적인 Pub/Sub 통신 방식과 달리 이벤트 알림은 모든 노드에 브로드캐스트되지 않는 특성이 작용한 것으로 분석(출처: Redis keyspace notifications)

       • 트러블슈팅 및 분석 도구: redis-cli 와 Redisson 활용

   • 해결:

     • 이미 운영 중인 고객사 환경에서 Redis 서버 설정을 개별적으로 수정하는 것은 리스크와 작업 비용이 크다고 판단하여, 가능한 클라이언트 측 설정 변경을 통해 문제를 해결하는 방향으로 결정

     • Redisson의 subscriptionMode 설정 값을 변경하여, 이벤트를 Master 노드에서 구독하도록 정상 동작하도록 문제를 해결

프로젝트 개요

팀의 브랜치 전략을 재정립하여 안정적이고 효율적인 배포 체계를 개선시키기 위한 프로젝트

문제

• 브랜치 전략의 비효율성

  • 기존의 공통모듈 동기화 문제로 배포도중 누군가 배포하면 재배포가 필요한 비효율 발생

  • 패치 변경 내역이 체계적으로 정리되지 않아 릴리스 및 롤백 시 혼선 발생

  • 각 환경(개발/운영)에서 안정적인 배포를 보장하면서도 상시 배포가 가능한 전략 부재

• 빌드 및 배포 파이프라인의 비효율

  • 기존 빌드 과정에서 공통모듈 중복 빌드로 전체 배포 사이클에 지연 발생

  • 반복적인 작업(수동 Merge 작업 및 버전 태깅 등)이 배포 프로세스의 병목으로 작용

해결 과정

• 팀내 브랜치 전략 수립

  • GitHub Flow, GitLab Flow, Git Flow 등 다양한 전략의 장단점을 분석하여 팀 환경에 적합한 DAVinCI Flow(=GitLab Flow + Tagging)를 발표 후 동의를 통해 도입

  • 공통모듈 동기화 문제 해결 방안을 마련하고, 브랜치 구조 및 태깅 정책을 문서화하여 팀원들과 공유

    • 태그를 통해 버전을 참조하여 배포시 공통모듈의 특정 버전에 의존하도록 변경

  • 각 환경별(개발, 운영) 브랜치 관리 체계를 확립하여, 안정적인 배포 및 롤백이 가능하도록 전략을 단순화

• 젠킨스 파이프라인 개선

  • 2개 이상의 모듈을 배포하게 될 경우, 공통 모듈의 중복 빌드를 생략(Maven 로컬 캐시 활용)하도록 개선

  • 태그를 기준으로 병합 및 배포하는 프로세스 자동화

성과

• 새로운 브랜치 전략 도입으로 공통모듈 동기화 문제 및 변경 내역 관리 체계를 확립, 배포 안정성 향상
  (공통모듈 동기화 문제 100% 감소)

• 솔루션 배포 시간 약 25%(21min → 16min) 단축(5개 모듈 기준)

프로젝트 개요

사내 공통모듈 사용 중 발생하는 불편함 해소와 성능 개선 프로젝트

개선 포인트

1. HTTP 클라이언트 모듈 개선 (RestTemplate → WebClient 전환) 및 고도화

   • Http 통신 클라이언트 툴을 WebClient로 교체하여 보다 효율적인 비동기 HTTP 통신 환경을 구축

   • WebClient는 Single-Thread, Non-Blocking 기반으로 동작하여, 기존 툴 대비 평균 응답속도가 (각 스레드 10개 기준) 약 40%(tps 0.9/sec -> 1.3/sec) 개선되는 효과를 확인

   • 여러 Http 요청 정보(Method, header, body content 등 제공)를 캡슐화하여 관리할 수 있는 요청 모델 설계 및 구현(Builder 패턴을 이용)

   • 간편하게 HTTP 요청을 처리할 수 있도록 구현(동기/비동기 지원, 에러 핸들링 처리)하여 사내 공통 모듈의 일부로 포함되어 다양한 프로젝트에서 사용 중

2. Flyway 도입 및 프로세스 정립

   • DB 마이그레이션 자동화와 스키마 변경 관리의 일관성을 확보하기 위해 Flyway를 도입

     • Flyway를 선택하게 된 이유(vs Liquibase)
       SQL을 기본으로 사용하는 Flyway가 적응하기 쉽고 패키징 파일과 함께 관리하기 용이하다고 판단하여 동료들의 동의를 통해 도입

   • 마이그레이션 프로세스를 문서화(마크다운 기반 가이드 작성)하여 Java 기반 모듈을 개발하는 모든 개발자가 쉽게 적응하고 400건 이상의 마이그레이션에 활용

   • 이를 통해 배포 전 DB 변경 사항의 검증 및 적용 과정이 표준화되어 배포 안정성 향상

3. MapStruct 인터페이스 리팩토링

   • 기존 10,000줄 이상의 대규모 MapStruct 인터페이스를 도메인별로 분리하여 유지보수성 향상

   • 도메인 단위로 모듈화함으로써 코드 가독성 개선

   • 도메인별 의존 관계를 설정하여 코드 재사용성 향상