데이터베이스를 연결하기 전에 책임부터 나눴습니다
유럽법인 LIMS 3.0으로 전환하면서 법인에서 받은 CES 주문을 본사 생산·분석 시스템으로 보내고, 진행 상태와 결과를 다시 법인에 전달해야 했습니다. 두 시스템이 같은 주문을 다루지만 맡는 일은 같지 않았습니다.
- 유럽 LIMS는 법인에서 접수한 주문과 현지 사용자가 보는 진행 상태를 관리합니다.
- 본사 CES는 아웃소싱으로 전달된 주문의 생산·분석과 결과 생성을 맡습니다.
- 연계 계층은 양쪽의 식별자와 상태, 결과 데이터를 서로 이해할 수 있는 값으로 바꿉니다.
DB Link로 상대 테이블을 직접 읽고 쓰면 구현은 짧아 보일 수 있습니다. 그러나 한 시스템의 스키마 변경이 다른 시스템 SQL에 바로 영향을 주고, 어느 시스템이 값을 바꿀 권한을 갖는지도 흐려집니다. 이번 전환에서는 상대 데이터베이스에 직접 접속하지 않고 주문·상태·결과 교환을 API로 분리했습니다.
주문 전송·상태 회신·결과 전달로 나눴습니다
전체 흐름을 공개 가능한 수준으로 줄이면 다음과 같습니다.
유럽 LIMS 3.0 ── 주문 데이터 ──▶ 본사 CES
유럽 LIMS 3.0 ◀─ 진행 상태 ─── 본사 CES
유럽 LIMS 3.0 ◀─ 결과 데이터 ── 본사 CES주문을 보낼 때는 법인 주문을 본사 생산에 필요한 형태로 매핑하고, 이후 상태와 결과를 돌려줄 때는 처음 연결한 식별 관계를 사용했습니다. 양쪽 테이블 이름이나 코드값을 그대로 외부 규격으로 노출하지 않고, 연계에 필요한 의미만 API 데이터로 만들었습니다.
| API 데이터 | 법인 시스템의 책임 | 본사 시스템의 책임 |
|---|---|---|
| 주문 식별 관계 | 법인 주문 식별자 제공 | 본사 처리 식별자 연결 |
| 주문 입력값 | 법인에서 확정한 요청 전달 | 생산 가능한 값으로 검증·수신 |
| 진행 상태 | 사용자가 볼 상태로 반영 | 생산·분석 변화 전달 |
| 결과 | 결과 수신·노출 | 분석 결과 생성·전달 |
이 표는 실제 매핑 문서의 내부 필드명을 공개하지 않고 데이터 책임만 다시 정리한 것입니다. 상대 시스템의 모든 컬럼을 복제하지 않고 연계 시점에 필요한 값만 주고받았습니다.
API DTO에는 연계에 필요한 값만 담았습니다
실제 요청을 공개용 형태로 줄이면 다음과 같습니다. 아래 JSON의 이름과 값은 설명용이며 운영 요청 전문은 아닙니다.
{
"sourceOrderKey": "OVERSEAS-ORDER-KEY",
"service": "SEQUENCING",
"samples": [
{
"sourceSampleKey": "SAMPLE-KEY",
"requestedAnalysis": "ANALYSIS-TYPE"
}
]
}요청에는 본사에서 주문을 생성하고 분석을 시작하는 데 필요한 값만 들어갑니다. 상태·결과 응답에도 법인 주문과 연결할 식별자와 전달할 결과만 포함합니다.
DTO를 내부 테이블과 일대일로 맞추지 않은 덕분에 스키마를 바꾸더라도 API 매핑 계층에서 차이를 흡수할 수 있었습니다. 다만 이 글에서는 확인된 데이터 매핑 구조까지만 설명합니다. 재시도 저장소나 멱등성 키처럼 보존된 근거로 확인하지 못한 구현을 덧붙이지 않았습니다.
DB Link를 없애면 실패도 명시적으로 다뤄야 합니다
API 경계에서는 두 시스템의 데이터베이스 트랜잭션을 하나로 묶을 수 없습니다. 요청을 보낸 쪽이 성공했다고 생각해도 받는 쪽의 검증에서 실패할 수 있고, 상태 전달이 늦으면 잠시 서로 다른 값을 보여 줄 수 있습니다.
그래서 테스트도 HTTP 호출이 성공하는가에서 끝내지 않았습니다. 법인 주문이 본사 처리 대상으로 들어오는지, 본사 분석 뒤 결과가 올바른 법인 주문으로 돌아오는지, 취소나 Hold처럼 정상 진행에서 벗어난 상태가 같은 경로로 잘못 흘러가지 않는지를 확인했습니다.
특히 Outsourcing Hold는 별도 예외 시나리오로 뒀습니다. Hold 상태의 주문이 다음 생산 단계에 들어가지 않는지, 상태가 법인 화면에 맞게 전달되는지를 함께 확인했습니다. 이 조건을 빼면 운영에서 처음 문제가 드러날 가능성이 컸습니다.
통합 테스트는 양쪽 화면의 결과까지 따라갔습니다
유럽법인 QA 환경에서 다음 순서를 연결해 확인했습니다.
- 법인 주문이 API를 거쳐 본사 아웃소싱 주문으로 연결되는지 확인합니다.
- 본사에서 분석을 진행한 뒤 상태가 법인 주문에 반영되는지 확인합니다.
- 생성된 결과가 원래 주문으로 돌아와 조회되는지 확인합니다.
- 주문 취소와 Outsourcing Hold가 정상 진행과 분리되는지 확인합니다.
테스트 결과는 법인 현업과 관련 개발자에게 공유하고 운영 전환에 맞춰 조율했습니다. 팀 단위 Roll-Out은 2022년 7월 4일 유럽법인 LIMS 3.0 공식 전환으로 이어졌습니다.
공식 전환과 개인 기여를 구분합니다
전체 LIMS 3.0 전환은 여러 담당자가 함께한 팀 결과입니다. 제가 직접 맡은 범위는 담당 영역의 현행 흐름 분석, 주문·상태·결과 API와 데이터 매핑 설계·개발, QA 통합 테스트와 운영 배포 지원이었습니다.
DB Link 없이 연결한 담당 API가 전체 전환에서 맡은 책임과 이를 검증한 시나리오가 이 글의 범위입니다. 유럽 LIMS 3.0 전체를 단독으로 구축한 사례는 아닙니다.