화면별 차이를 Gap으로 정리했습니다
유럽법인에는 본사 화면을 그대로 복제할 수 없었습니다. 본사는 실험을 직접 수행하는 인소싱이 중심이었고, 유럽·일본법인은 본사로 보내는 아웃소싱도 함께 처리해야 했습니다. 같은 메뉴 이름이라도 주문을 누가 수행하고 결과를 어디서 가져오는지에 따라 동작이 달랐습니다.
COMS와 LIMS의 주문, 접수, 생산, 결과 화면을 나란히 놓고 AS-IS와 TO-BE 차이를 20개 Gap으로 정리했습니다. 각 항목에는 시스템, 메뉴, 본사 동작, 법인 동작, 목표 동작, 중요도와 협의 여부를 함께 기록했습니다. 이 자료를 바탕으로 각 기능이 법인 운영에 필요한지 판단했습니다.
네 가지 결정으로 분류했습니다
최종 Gap 목록의 판단을 공개 가능한 수준으로 줄이면 다음과 같습니다.
| 결정 | 판단 기준 | 사례 |
|---|---|---|
| 유지 | 법인 현행이 이미 목표 업무와 같음 | 주문의 Sample Type을 PCR Product로 고정 |
| 변경 | 인소싱·아웃소싱에 따라 데이터나 권한이 달라짐 | 결과 조회 원천 분기, 재반응 주문 제한 |
| 이관 | 본사 생산 흐름이 법인 인소싱에도 필요함 | 보류·취소 관리, Plating, Rxn Sheet |
| 제외 | 전제 서비스가 없어 실행될 수 없는 기능 | Worksheet, DNA Extraction, PCR Amplification |
제외는 일정 때문에 미룬 항목이 아니었습니다. 법인 주문은 Sample Type이 PCR Product로 고정되고 DNA Extraction과 PCR Amplification 부가서비스를 제공하지 않았습니다. 그 전제가 없는데 본사 메뉴만 옮기면 사용되지 않는 화면과 상태만 늘어납니다. 현업과 이 조건을 확인한 뒤 세 기능을 이관 대상에서 뺐습니다.
인소싱과 아웃소싱의 처리 단계를 나눴습니다
가장 큰 변경은 같은 Fragment Analysis 주문을 수행 주체에 따라 다르게 처리하는 것이었습니다.
- 인소싱 주문은 법인 LIMS에서 접수한 뒤 Plating과 Rxn Sheet를 거쳐 결과를 만듭니다.
- 아웃소싱 주문은 본사에서 전달한 결과를 조회하며, 법인 생산 대상에는 들어가지 않습니다.
- COMS 결과 화면은 주문 유형에 따라 법인 결과와 본사 전송 결과를 나눠 읽습니다.
- 아웃소싱 주문에는 수정·수동생산·재반응처럼 법인에서 수행할 수 없는 동작을 제한합니다.
Plating과 Rxn Sheet를 이관할 때도 메뉴를 복사하는 데서 끝내지 않았습니다. 아웃소싱 주문이 실험 대상 쿼리에 포함되지 않도록 조건을 추가했습니다. 실제 조건의 의미를 공개용으로 줄이면 다음과 같습니다.
SELECT reaction_id, order_id, reaction_status
FROM fragment_reaction
WHERE service_type = :fragmentAnalysis
AND outsourcing_order = 'N'
AND reaction_status = :waitingForPlating;테이블과 컬럼명은 바꿨지만 아웃소싱 주문을 생산 대상에서 제외한다는 조회 조건은 실제 변경을 반영합니다. 화면 버튼만 숨기면 다른 진입점이나 조회에서 다시 노출될 수 있어 데이터 조회 단계에서도 제외했습니다.
주문 유형에 따라 결과 조회 대상을 바꿨습니다
결과 조회는 화면 모양이 같아도 데이터의 책임이 달랐습니다. 인소싱 주문은 법인이 만든 결과를 보여 주고, 아웃소싱 주문은 본사가 전송한 데이터를 보여 줘야 했습니다. 그래서 법인 결과 화면과 본사 결과 화면을 따로 복제하기보다 주문 유형을 기준으로 조회 원천과 허용 동작을 분기했습니다.
재반응 주문도 같은 기준을 적용했습니다. 화면에 버튼이 있다는 이유로 허용하지 않고, 해당 법인이 실제로 재생산할 수 있는 주문인지 확인했습니다. 주문 접수, 조회, 수정, 수동생산, 완료와 결과 메일 발송 조건까지 이 판단이 일관되게 이어지는지 확인했습니다.
Gap 목록을 테스트 시나리오로 바꿨습니다
분석 문서의 20개 행과 테스트 케이스를 일대일로 세지는 않았습니다. 한 Gap이 주문등록과 조회, 상태 변경 여러 화면에 영향을 줄 수 있고, 반대로 한 시나리오가 여러 Gap을 함께 검증할 수 있기 때문입니다.
최종 테스트는 LIMS 35개와 COMS 3개, 총 38개 시나리오로 구성했습니다. LIMS 최초 수행에서는 34개가 성공했고, 아웃소싱 주문의 수정 제한과 관련된 1개가 실패했습니다. 이 결함을 수정한 뒤 해당 흐름을 다시 확인했고, COMS 3개와 사용자 테스트까지 마쳤습니다.
| 검증 대상 | 확인한 경계 |
|---|---|
| 주문·접수 | 주문 유형별 접수와 수정 가능 범위 |
| 생산 | 아웃소싱 주문의 실험 대상 제외 |
| 결과 | 인소싱·아웃소싱별 조회 원천과 메일 조건 |
| 예외 | 보류·취소·재반응과 완료 조건 |
38이라는 숫자보다 중요한 것은 실패한 한 건을 대체로 통과로 묶지 않은 점입니다. Gap에서 정한 제한이 실제 화면과 저장 동작에서 지켜지지 않았기 때문에 결함으로 분리하고 수정·재검증했습니다.
제가 맡은 이관 범위
서비스는 2023년 10월 말 운영에 반영했고 다음 날 사용자 확인을 마쳤습니다. 운영 직후 Quick Search에서 나온 이슈는 캐시 데이터 문제로 확인해 배포 코드와 분리해 안내했습니다.
제가 맡은 범위는 20개 Gap 분석과 법인 협의, LIMS 주문·생산·결과 처리, COMS 결과 조회 분기와 재반응 주문 제약, 테스트와 배포였습니다. COMS 전체 기능이나 LIMS·COMS 전체를 단독으로 구축한 것은 아닙니다. 이 글은 서로 다른 운영 방식을 어떤 기준으로 유지·변경·이관·제외했는지 설명합니다.