CASE STUDY
한눈에 보는 변화
기존 기능을 법인에 복제하는 프로젝트가 아니었습니다. 본사에도 동일한 운영 사례가 없는 신규 서비스였기 때문에, Whole Plasmid·16S의 차이와 샘플 조건·부가서비스·재처리 규칙을 먼저 업무 모델로 바꿔야 했습니다. Fragment Analysis의 골격은 참고하되 타 법인 영향은 최소화하는 전용 경계를 설계하고 주문부터 결과 제공까지 LIMS 전 과정을 구현했습니다.
본사에 동일한 업무 모델이 없는 상태에서 유럽법인이 최초로 신규 시퀀싱 서비스를 운영해야 했습니다. 향후 서비스 확장과 다양한 샘플 조건을 고려하면서도 재시도와 추가 주문까지 실제 현업 흐름으로 정의해야 했습니다.
직접 담당한 범위
- 현지 요구사항 분석과 LIMS 데이터·화면 설계
- LIMS 주문·생산·실험·결과 처리 전반 개발
- LIMS·COMS 데이터 구조와 주문 흐름 연계, 통합테스트·배포·오픈 지원
| 구분 | 변경 전 | 변경 후 | 확인된 변화 |
|---|---|---|---|
| 업무 모델 | 본사·기존 법인에 그대로 적용할 Nanopore 운영 기준 부재 | 서비스 유형·샘플 조건·부가서비스·재처리 규칙을 현업 질의로 구조화 | 유럽법인 신규 서비스의 처리 기준 확립 |
| 기능 구조 | Fragment Analysis를 참고할 수 있으나 업무 규칙과 실험 흐름은 상이 | 공통 골격은 재사용하고 Nanopore 전용 메뉴·서비스 로직 분리 | 기존 법인 영향도를 줄인 확장 구조 |
| 데이터 경계 | 신규 서비스의 샘플·반응·Plate·실험 상태와 이력 구조 미정 | 8개 전용 테이블과 기존 주문·이력 테이블 확장 | 실험 진행과 변경 이력의 추적 기준 확보 |
| 업무 흐름 | 현지 요구사항이 개별 화면과 기능 단위로 존재 | 주문·접수·Plating·실험·결과·완료를 하나의 처리 흐름으로 연결 | 2024.07.09 유럽법인 운영 오픈 |
EVIDENCE CHAIN
문제를 좁힌 과정
- 01 · 요구사항 분해
화면 목록보다 서비스 규칙과 예외 조건부터 분리했습니다
Whole Plasmid와 16S 서비스의 차이, Sample Condition, 부가서비스, 재시도와 추가 주문 조건을 현지 담당자 질의로 구체화했습니다. 같은 주문이라도 샘플과 반응이 어떤 조건에서 분기되는지 업무 단위로 정리했습니다.
판단신규 서비스는 기존 화면을 먼저 복제하기보다 서비스 유형·샘플·반응의 규칙을 데이터와 상태로 번역해야 했습니다.
- 02 · 기준 구조 비교
Fragment Analysis를 복사 대상이 아니라 비교 기준으로 사용했습니다
주문·접수·실험·결과라는 큰 흐름은 Fragment Analysis에서 참고할 수 있었지만, 서비스 유형과 실험 배열·재처리 규칙은 달랐습니다. 공통으로 유지할 계약과 Nanopore가 독립적으로 가져야 할 영역을 나눴습니다.
판단기존 구조를 그대로 복제하면 다른 법인과 서비스에 불필요한 분기가 전파되므로 전용 메뉴·서비스 경계가 필요했습니다.
- 03 · 데이터 모델링
화면이 아니라 실험 생명주기를 기준으로 8개 전용 테이블을 설계했습니다
샘플, 반응, 임시 데이터, Plate, 실험 배열, 반응 상태, 샘플 변경 이력이 각각 어떤 시점에 생성·변경되는지 분리했습니다. 공통 주문·이력과 연결하되 신규 실험 데이터가 기존 서비스 구조를 흔들지 않도록 경계를 잡았습니다.
판단상태 변화와 재처리를 추적하려면 주문 한 건에 모든 정보를 넣기보다 샘플·반응·실험·이력을 분리해야 했습니다.
- 04 · 책임 연결
COMS와 LIMS의 담당 범위를 분리하고 데이터 계약으로 연결했습니다
사용자는 LIMS 주문·생산·실험·결과 처리를 직접 개발했고, COMS 주문등록 화면은 타 개발자가 담당했습니다. 두 영역 사이에서는 주문 데이터 구조, 등록 이후 상태 전이, 결과 제공 시점을 함께 맞춰 통합테스트했습니다.
판단전체 기능을 단독 개발한 것으로 확장하지 않고, 직접 구현 범위와 연계 검증 책임을 분명히 해야 했습니다.
- 05 · 오픈 검증
기본 정상 흐름뿐 아니라 서비스 분기와 재처리 조건을 포함했습니다
주문등록부터 접수·Plating·Rxn Sheet·Worksheet·결과 URL·메일·주문완료까지 연결해 검증했습니다. 유럽법인 QA 피드백과 추가 개선을 반영한 뒤 2024년 7월 9일 운영 오픈을 확인했습니다.
판단신규 업무 시스템의 완료 기준은 화면 구현이 아니라 주문부터 결과 제공까지 실제 운영 흐름이 닫히는 것입니다.
DECISION LOG
검토한 대안과 선택 근거
Fragment Analysis 구조 그대로 복제
주문·실험의 큰 흐름은 비슷해도 서비스 유형·샘플 조건·재처리 규칙이 달라 법인별 분기가 누적될 수 있기 때문입니다.
기존 공통 테이블에 모든 항목 추가
Nanopore 전용 실험 상태와 배열·변경 이력이 다른 서비스의 데이터 구조와 변경 범위까지 넓히기 때문입니다.
완전한 별도 시스템으로 구축
독립성은 높지만 기존 주문·사용자·이력 계약을 다시 만들어야 하므로 공통 기반은 재사용했습니다.
공통 골격 + Nanopore 전용 경계
기존 주문 흐름과 운영 기반은 활용하면서 신규 서비스의 데이터·화면·로직을 분리해 영향도를 통제할 수 있었습니다.
IMPLEMENTATION
설계와 구현
주문·접수
- LIMS 주문등록과 Excel 일괄 업로드
- 주문조회와 접수, 보류·해제·취소 흐름
- 서비스 유형·Sample Condition·부가서비스 조건 반영
생산·실험
- 샘플과 반응 생성·상태 관리
- Plating, Rxn Sheet와 Worksheet 처리
- Plate·실험 배열·반응 상태를 전용 데이터 구조로 관리
결과·이력
- 결과 URL 등록과 메일 발송
- 주문완료와 재시도·추가 주문 조건 처리
- 샘플 변경과 업무 상태 변화를 이력으로 추적
법인 연계·다국어
- COMS 주문등록 데이터 구조와 LIMS 처리 계약 연계
- 영어·프랑스어·이탈리아어 메시지 적용
- 유럽법인 QA 피드백 반영과 배포·오픈 지원
VERIFICATION
테스트 매트릭스
| 검증 영역 | 검증 방법 | 완료 기준 |
|---|---|---|
| 서비스 유형 | Whole Plasmid·16S와 Sample Condition·부가서비스 조합 실행 | 유형별 주문·샘플·반응 규칙이 정의한 조건대로 분기 |
| 전체 생명주기 | 주문등록→접수→Plating→실험→결과→완료 시나리오 수행 | 단계별 상태와 관련 데이터가 다음 업무 화면에 일관되게 연결 |
| 예외·재처리 | 보류·해제·취소·재시도·추가 주문 조건 점검 | 기존 결과와 이력을 보존하며 허용된 상태 전이만 수행 |
| COMS 연계 | 타 개발자가 담당한 주문등록과 LIMS 데이터·상태 흐름 통합테스트 | 시스템 책임 경계에서 필수 데이터 누락 없이 주문과 결과 연결 |
| 법인 운영 | 다국어 메시지와 유럽법인 QA 피드백·추가 개선 재검증 | 현지 사용 흐름 확인 후 2024.07.09 운영 오픈 |
OPERATION
운영 반영과 후속 안정화
- 신규 해외 서비스의 LIMS 업무 흐름과 데이터 구조 설계
- LIMS 주문·생산·실험·결과 처리 범위를 직접 구현
- 유럽법인 QA와 추가 개선을 거쳐 2024.07.09 운영 오픈
TAKEAWAYS
이 사례에서 드러난 역량
- 본사 기준이 없는 신규 서비스에서는 기능 목록보다 서비스 유형·상태·예외·재처리 규칙을 먼저 모델링해야 합니다.
- 유사 시스템은 복사 대상이 아니라 공통으로 재사용할 계약과 분리할 업무 경계를 찾는 비교 기준으로 활용해야 합니다.
- 샘플·반응·Plate·실험·이력을 분리하면 재처리와 상태 변화를 운영 데이터로 추적할 수 있습니다.
- 협업 프로젝트에서는 직접 개발한 LIMS 범위와 타 개발자가 담당한 COMS 범위를 구분하면서 통합 책임은 구체적으로 설명해야 합니다.