백엔드 개발자

정창화

문제 해결에 몰입하고 꾸준히 발전하는 백엔드 개발자

정보처리산업기사

<h3>프로젝트 개요</h3><ul><li>기존 ‘열린데이터 광장’ 기반 공공데이터 활용 및 접근성 향상을 위한 통합 플랫폼 서비스(<a target="_blank" rel="noopener noreferrer nofollow" href="https://data.seoul.go.kr/bsp/wgs/index.do">서울데이터 허브</a>)</li><li>지방자치단체 최초로 RAG 기반 AI 챗봇 서비스를 도입하여 공공데이터의 최신 질의응답 기능 제공</li></ul><h4>주요 기능 및 개발 내용</h4><ol><li>지식 베이스 구축을 위한 스케줄러 개발<ul><li>RAG 과정에 필요한 지식베이스 구조 설계 및 스크랩, 전처리, 저장 프로세스 과정을 설계 및 구현<ul><li>웹 스크랩 중 정적페이지 처리가 대부분인 상황을 고려하여, 성능에 유리한 <code>Jsoup</code>을 도입(비교 도구: <code>Selenium</code>, <code>HtmlUnit</code>)하여 지식베이스 구축</li></ul></li><li>스케줄러의 정기적인 데이터 수집을 통해 최신 공공데이터를 반영</li></ul></li><li>지식베이스 벡터화 및 검색 모듈 개발<ul><li>LLM 모델(HyperCLOVA X)을 응용한 환각 축소 RAG 질의응답 서비스 제공<ul><li>지식베이스의 데이터셋을 벡터화하여 의미 기반 검색 기능을 구현</li></ul></li></ul></li><li>프롬프트 테스트 자동화<ul><li>동료들의 프롬프트 작업 과정에서 반복된 테스트와 테스트 결과 관리 부실을 해소하기 위해, 프롬프트 엔지니어링의 반복 작업을 자동화하여 운영 효율성을 향상 및 비용 절감</li><li>답변 정확도 및 응답 생성시간 측정을 개선하여 프롬프트를 최적화할 수 있도록 지원</li></ul></li></ol>

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

<h3>프로젝트 개요</h3><ul><li>챗봇 솔루션의 시나리오 배포 기능에서 발생하는 오류를 해결하는 프로젝트</li><li>서버 모듈(API와 시나리오 모듈)간 연계처리 및 다중서버 환경에서 발생하는 동시성 문제를 분석 및 해결</li></ul><h4>기술적 도전과 해결</h4><ol><li>배포 처리 상태 갱신 누락 문제<ul><li>문제: 모든 시나리오 서버가 배포 처리를 완료했음에도 불구하고 배포 상태가 여전히 '배포 처리중'으로 남는 문제 발생</li><li>원인: 여러 시나리오 서버에서 발행된 배포 완료 메시지를 동시에 다른 트랙잭션에서 처리하는 과정에서 JPA 쓰기 지연 및 트랜잭션의 격리 수준(<code>READ_COMMITED</code>)으로 인해 다른 서버의 최신 배포 상태를 확인하지 못하게 됨</li><li>해결:<ul><li>데이터 동시성 이슈를 해결하기 위해 기능의 특성상 사용량이 적으며 성능의 측면보다 정확도 측면을 고려하여 락을 도입하기로 결정 (JPA flush 호출, 트랜잭션의 격리 수준 변경, 낙관적 락은 다른 트랜잭션의 조회 시점 전 데이터의 읽기 최신성을 보장할 수 없을 것으로 보고 배제)</li><li>RDB의 비관적 락과 <code>Redisson</code> 분산 락 도입을 검토하였으며, IO가 많은 RDB의 부담을 덜고 다중 서버 구성에서의 데드락을 방지하기 위해 <code>Redisson</code> 분산 락 적용을 결정</li><li>유사한 동시성 문제의 예방을 위해 <code>Spring AOP</code>를 활용한 관점 지향 프로그래밍을 도입하여 관련 로직을 일관되게 관리하도록 구현</li></ul></li></ul></li><li>비동기 메시지 처리 실패 문제<ul><li>문제: 시나리오 서버에서 비동기 요청 메시지(MQ)를 제대로 소비하지 못하는 경우, 보상 트랜잭션이 실행되지 않아 배포 상태가 '배포 처리중'으로 남는 문제가 발생</li><li>원인:<ul><li>Redis의 Keyspace Notifications 기능을 활용해 key 만료 이벤트를 처리하려 했으나, Redis Cluster 환경에서 등록된 키가 만료된 후에도 이벤트가 제대로 구독되지 않는 현상이 발생<ul><li>소규모의 메세징이 요구되는 점과 재처리 보다는 배포 실패로 기록해야하는 기능 특성상 mq 의 TTL/Dead Letter Exchange 보다는 Redis의 Keyspace Notifications가 적합하다고 판단</li></ul></li><li>트러블 슈팅 결과, Redis 서버 설정(<code>slave-read-only</code>)으로 인해 Master 노드에 기록된 키 만료 알람이 읽기 전용인 Slave 노드에서 <code>Redisson</code>이 구독을 시도하면서 Redis Cluster 에서는 일반적인 Pub/Sub 통신 방식과 달리 이벤트 알림은 모든 노드에 브로드캐스트되지 않는 특성이 작용한 것으로 분석(출처: <a target="_blank" rel="noopener noreferrer nofollow" class="_1yt4x7n9 _2rkoiti9 _v56415x0 _1e0c1nu9 _16d9qvcn _syaz1y58 _1rkwglyw _4cvxmr28 _19ith6cr _bfhkhp5a _1a3b18uv _4fprglyw _5goinqa1 _9oik18uv _1bnxglyw _jf4cnqa1 _1nrm18uv _c2waglyw _1iohnqa1 _uizt1kdv _nt751r31 _49pcglyw _1hvw1o36 _1372tlke _7ehicw00 _1j5pglyw _1di629zg" href="https://redis.io/docs/latest/develop/use/keyspace-notifications/">Redis keyspace notifications</a>)<ul><li>트러블슈팅 및 분석 도구: <code>redis-cli</code> 와 <code>Redisson</code> 활용</li></ul></li></ul></li><li>해결:<ul><li>이미 운영 중인 고객사 환경에서 Redis 서버 설정을 개별적으로 수정하는 것은 리스크와 작업 비용이 크다고 판단하여, 가능한 클라이언트 측 설정 변경을 통해 문제를 해결하는 방향으로 결정</li><li><code>Redisson</code>의 <code>subscriptionMode</code> 설정 값을 변경하여, 이벤트를 Master 노드에서 구독하도록 정상 동작하도록 문제를 해결</li></ul></li></ul></li></ol>

챗봇 시나리오 배포 기능 개선

<h3>프로젝트 개요</h3>팀의 브랜치 전략을 재정립하여 안정적이고 효율적인 배포 체계를 개선시키기 위한 프로젝트<h4>문제</h4><ul><li>브랜치 전략의 비효율성<ul><li>기존의 공통모듈 동기화 문제로 배포도중 누군가 배포하면 재배포가 필요한 비효율 발생</li><li>패치 변경 내역이 체계적으로 정리되지 않아 릴리스 및 롤백 시 혼선 발생</li><li>각 환경(개발/운영)에서 안정적인 배포를 보장하면서도 상시 배포가 가능한 전략 부재</li></ul></li><li>빌드 및 배포 파이프라인의 비효율<ul><li>기존 빌드 과정에서 공통모듈 중복 빌드로 전체 배포 사이클에 지연 발생</li><li>반복적인 작업(수동 Merge 작업 및 버전 태깅 등)이 배포 프로세스의 병목으로 작용</li></ul></li></ul><h4>해결 과정</h4><ul><li>팀내 브랜치 전략 수립<ul><li>GitHub Flow, GitLab Flow, Git Flow 등 다양한 전략의 장단점을 분석하여 팀 환경에 적합한 DAVinCI Flow(=GitLab Flow + Tagging)를 발표 후 동의를 통해 도입</li><li>공통모듈 동기화 문제 해결 방안을 마련하고, 브랜치 구조 및 태깅 정책을 문서화하여 팀원들과 공유<ul><li>태그를 통해 버전을 참조하여 배포시 공통모듈의 특정 버전에 의존하도록 변경</li></ul></li><li>각 환경별(개발, 운영) 브랜치 관리 체계를 확립하여, 안정적인 배포 및 롤백이 가능하도록 전략을 단순화</li></ul></li><li>젠킨스 파이프라인 개선<ul><li>2개 이상의 모듈을 배포하게 될 경우, 공통 모듈의 중복 빌드를 생략(Maven 로컬 캐시 활용)하도록 개선</li><li>태그를 기준으로 병합 및 배포하는 프로세스 자동화</li></ul></li></ul><h4>성과</h4><ul><li>새로운 브랜치 전략 도입으로 공통모듈 동기화 문제 및 변경 내역 관리 체계를 확립, 배포 안정성 향상 (공통모듈 동기화 문제 100% 감소)</li><li>솔루션 배포 시간 약 25%(21min → 16min) 단축(5개 모듈 기준)</li></ul>

팀 브랜치 전략 및 배포 체계 개선

<h3>프로젝트 개요</h3>사내 공통모듈 사용 중 발생하는 불편함 해소와 성능 개선 프로젝트<h4>개선 포인트</h4><ol><li>HTTP 클라이언트 모듈 개선 (<code>RestTemplate</code> → <code>WebClient</code> 전환) 및 고도화<ul><li>Http 통신 클라이언트 툴을 WebClient로 교체하여 보다 효율적인 비동기 HTTP 통신 환경을 구축</li><li>WebClient는 Single-Thread, Non-Blocking 기반으로 동작하여, 기존 툴 대비 평균 응답속도가 (각 스레드 10개 기준) 약 40%(tps 0.9/sec -&gt; 1.3/sec) 개선되는 효과를 확인</li><li>여러 Http 요청 정보(Method, header, body content 등 제공)를 캡슐화하여 관리할 수 있는 요청 모델 설계 및 구현(Builder 패턴을 이용)</li><li>간편하게 HTTP 요청을 처리할 수 있도록 구현(동기/비동기 지원, 에러 핸들링 처리)하여 사내 공통 모듈의 일부로 포함되어 다양한 프로젝트에서 사용 중</li></ul></li><li>Flyway 도입 및 프로세스 정립<ul><li>DB 마이그레이션 자동화와 스키마 변경 관리의 일관성을 확보하기 위해 Flyway를 도입<ul><li>Flyway를 선택하게 된 이유(vs Liquibase) SQL을 기본으로 사용하는 Flyway가 적응하기 쉽고 패키징 파일과 함께 관리하기 용이하다고 판단하여 동료들의 동의를 통해 도입</li></ul></li><li>마이그레이션 프로세스를 문서화(마크다운 기반 가이드 작성)하여 Java 기반 모듈을 개발하는 모든 개발자가 쉽게 적응하고 400건 이상의 마이그레이션에 활용</li><li>이를 통해 배포 전 DB 변경 사항의 검증 및 적용 과정이 표준화되어 배포 안정성 향상</li></ul></li><li>MapStruct 인터페이스 리팩토링<ul><li>기존 10,000줄 이상의 대규모 MapStruct 인터페이스를 도메인별로 분리하여 유지보수성 향상</li><li>도메인 단위로 모듈화함으로써 코드 가독성 개선</li><li>도메인별 의존 관계를 설정하여 코드 재사용성 향상</li></ul></li></ol>

사내 공통모듈 개선

기술스택: Java8, SpringBoot 2, MariaDB, JPA, Redis, Elasticsearch, RabbitMQ, Docker, Jenkins CI/CD<h4>다빈치 챗봇 솔루션 개발</h4><ul><li>대시보드 및 챗봇 시나리오 등 관리자 기능 개발</li><li><code>Junit5</code> 테스트환경 구축 및 테스트코드(약 500개의 테스트케이스) 작성</li><li>솔루션 배포 프로세스 정립 및 구축</li><li>솔루션 패키징 및 관리(<code>Docker</code> 기반)<ul><li>MSA 아키텍쳐 &amp; 다중 서버 기반</li></ul></li></ul><h4>서울데이터 허브 AI 챗봇 개발</h4><ul><li>기존 '열린데이터 광장'의 공공데이터 활용 및 접근성 향상을 위한 플랫폼 서비스<ul><li>전국 지방자치단체중 최초의 RAG 기반 AI 챗봇 서비스</li></ul></li><li>지식베이스 구축을 위한 스케줄러 개발</li><li>지식베이스 벡터화 및 검색 모듈 개발</li><li>프롬프트 테스트 자동화를 통한 프롬프트 엔지니어링 환경 개선<ul><li>자동화 프로세스 기획 및 구현</li></ul></li></ul>

기술스택: Java11, SpringBoot 2, MariaDB, JPA, Apache Kafka, Mosquitto, K8S(EKS)<h4>카봄 서비스 개발</h4><ul><li><code>ReactJS</code> <code>TypeScript</code> 기반의 SPA 페이지 개발</li><li>CS 업무를 자동화/효율화하는 백오피스 기능 개발</li><li>IoT 패킷 데이터 분석</li></ul>