시퀀싱 분석 처리 모듈(CIWER·WaveChecker) 연계 구조 검증 및 LIMS REST API 개발

CASE STUDY

한눈에 보는 변화

처음에는 어떤 Connection Pool이 더 적합한지를 고르는 문제처럼 보였습니다. 하지만 Spring Boot·MyBatis Pool·직접 JDBC 비교 구현과 구간별 측정 코드, 호출 생명주기를 함께 분석하자 핵심은 라이브러리가 아니라 반응마다 시작하고 종료되는 JVM 구조에 있었습니다. 이 근거를 바탕으로 연계 구조 자체를 상시 기동 REST API로 전환했습니다.

초기안은 분석 반응마다 Java 모듈을 새로 실행해 LIMS와 연계하는 방식이었습니다. 기존 분석시간에 JVM 기동과 DB 연결 비용이 반복해서 더해지고, 프로세스가 종료될 때마다 Connection Pool 재사용 효과도 사라지는 구조였습니다.

EVIDENCE CHAIN

문제를 좁힌 과정

1. 01 · 초기안 분석

   Query가 아니라 프로세스 시작부터 종료까지를 한 건의 비용으로 봤습니다

   초기 연계안은 반응마다 Java 모듈을 실행해 설정 로드, DB 연결, 데이터 처리 후 종료하는 구조였습니다. 요청마다 반복되는 애플리케이션 초기화와 DB 연결 비용이 전체 처리량을 좌우할 수 있어 Query 외의 구간도 분석 대상으로 잡았습니다.

   판단Query 실행시간만 비교하면 JVM 기동과 DB 연결이라는 반복 비용을 놓치므로 측정 범위를 프로세스 전체로 넓혀야 했습니다.

2. 02 · 비교 구현

   세 가지 DB 접근 방식을 같은 조건에서 직접 구현했습니다

   Spring Boot·HikariCP, Non-Spring MyBatis Connection Pool, 직접 JDBC 방식을 구현하고 초기화·Connection·Query·Mapping 구간을 나누는 측정 코드를 구성했습니다. 특정 프레임워크에 대한 선호가 아니라 반복 비용의 위치를 비교할 수 있게 조건을 나눴습니다.

   판단라이브러리 선택 전에 각 방식이 같은 생명주기에서 어떤 비용을 반복하는지 증거를 확보했습니다.

3. 03 · 구간 분석

   초기화·Connection·Query·Mapping을 분리해 병목의 위치를 확인했습니다

   애플리케이션 초기화, Connection 획득, Query 실행, Result Mapping을 분리해 측정하는 소스 코드를 확인했습니다. 실행 결과 로그는 보존되지 않아 구체 시간값을 성과로 채택하지 않았지만, 반응이 끝나면 JVM과 Pool도 함께 종료되는 구조는 확인할 수 있었습니다.

   판단Pool을 적용해도 재사용할 다음 요청이 없으므로 초기화 비용만 더하고 재사용 이점은 얻기 어려운 구조였습니다.

4. 04 · 문제 재정의

   Connection Pool 비교를 프로세스 생명주기 설계 문제로 바꿨습니다

   HikariCP·MyBatis Pool·직접 JDBC 사이의 차이를 줄이는 것으로는 반응마다 반복되는 상위 비용을 제거할 수 없었습니다. JVM과 Pool을 여러 요청 동안 유지하는 구조가 필요하다는 근거로 연계안 변경을 제안했습니다.

   판단객체 생명주기보다 상위인 프로세스 생명주기가 병목이면 라이브러리 최적화가 아니라 실행 구조를 바꿔야 했습니다.

5. 05 · 운영 보완

   API 전환 뒤에는 계약과 데이터 일관성 문제를 별도로 안정화했습니다

   3개 API를 본사·유럽·일본 환경에 적용한 뒤 파라미터 누락, Key 채번, Run 시간, 부분완료 주문 처리 조건을 점검하고 보완했습니다. 성능 구조 전환과 업무 데이터 정합성을 별도 검증 항목으로 관리했습니다.

   판단상시 기동 구조가 성능 문제를 해결해도 요청 계약과 트랜잭션 경계는 운영 시나리오로 다시 검증해야 했습니다.

6. 06 · 2026년 후속 안정화

   빈 성공 응답으로 보이던 Well 좌표 충돌을 명시적 실패 계약으로 바꿨습니다

   Well 좌표 충돌 경로가 HTTP 200과 빈 응답을 반환해 호출 측에서 정상과 실패를 구분하기 어려웠습니다. Service·Mapper 흐름을 추적해 HTTP 500과 표준 errorCode·errorMessage를 반환하도록 수정했습니다.

   판단연계 API는 저장 성공뿐 아니라 업무 조건 불일치를 호출 측이 일관되게 판별할 수 있어야 했습니다.

DECISION LOG

검토한 대안과 선택 근거

IMPLEMENTATION

설계와 구현

VERIFICATION

테스트 매트릭스

OPERATION

운영 반영과 후속 안정화

TAKEAWAYS

이 사례에서 드러난 역량

• Connection Pool의 효과는 구현체보다 Pool을 재사용할 수 있는 프로세스 생명주기에 먼저 좌우됩니다.
• 성능 검증은 Query 한 구간이 아니라 실제 호출 한 건이 부담하는 초기화부터 결과 반환까지 포함해야 합니다.
• 구조 변경을 제안할 때는 프레임워크 선호보다 비교 구현·측정 코드와 생명주기 분석이 설득 근거가 됩니다.
• 팀 프로젝트에서는 전체 제품 성과와 직접 담당한 연계 분석·LIMS API 범위를 명확히 구분해야 합니다.

사용 기술