주문에서 결과까지 이어져야 했습니다
일본법인에 PCR & Sequencing 서비스를 도입할 때 주문 화면만 추가해서는 업무가 끝나지 않았습니다. 고객이 COMS에서 주문한 뒤 LIMS가 접수하고, 실험 결과와 재반응 정보가 다시 COMS 결과와 메일로 이어져야 했습니다. 화면·기준정보·권한 가운데 하나라도 빠지면 앞 단계가 정상이어도 실제 업무는 다음 단계로 넘어가지 못합니다.
주문에서 결과까지 오가는 데이터와 담당 화면을 먼저 펼쳐 봤습니다.
주문 템플릿
↓
COMS 주문 등록 ─▶ LIMS 접수 ─▶ 결과 처리 ─▶ COMS 결과 조회·메일
└────▶ 재반응 ──────┘
일본어 기준정보·화면 문구·권한은 각 단계에 함께 적용제가 맡은 범위는 이 과정의 Gap Analysis와 주요 기능 개발, QA 피드백 반영, 권한 설정과 오픈 지원이었습니다. 일본법인 시스템 전체를 새로 구축한 것은 아닙니다.
주문·접수·결과·재반응의 연결을 확인했습니다
각 화면이 열리는지만 확인하면 단계 사이의 데이터 연결을 놓칠 수 있습니다. 주문에서 만들어진 값이 접수와 결과 화면에서 같은 업무 건으로 이어지는지, 재반응이 발생했을 때 기존 주문과의 관계가 끊기지 않는지를 함께 확인했습니다.
| 단계 | 입력 | 다음 단계에 넘겨야 하는 결과 |
|---|---|---|
| 주문 | 주문 템플릿과 화면 입력 | 접수할 수 있는 주문 정보 |
| 접수 | COMS 주문 | LIMS 생산 흐름에 들어갈 접수 정보 |
| 결과 | 접수·반응 정보 | COMS에서 조회하고 안내할 결과 |
| 재반응 | 다시 처리할 반응 | 기존 주문과 연결된 후속 결과 |
이 표는 내부 테이블이나 상태코드 대신 실제 변경과 QA에서 확인한 입출력을 공개 가능한 수준으로 정리한 것입니다. 특정 화면만 열리는 상태를 전체 업무 완료로 오해하지 않기 위한 기준이기도 했습니다.
주문 템플릿을 첫 입력으로 맞췄습니다
일본법인이 사용할 PCR & Sequencing 주문 템플릿을 주문 화면에 연결했습니다. 템플릿에 입력한 값은 주문과 접수 단계까지 이어지므로, 파일 제공과 입력 처리 결과를 같은 변경 범위에서 확인했습니다.
확인 기준은 다음처럼 입력과 결과를 짝지었습니다.
| 입력 조건 | 확인한 결과 |
|---|---|
| 대상 서비스의 주문 템플릿 선택 | 일본법인용 템플릿이 제공됨 |
| 템플릿을 이용한 주문 등록 | 접수 단계에서 주문을 식별할 수 있음 |
| 결과가 생성된 주문 | COMS 결과 화면과 안내 흐름으로 이어짐 |
| 재반응이 필요한 주문 | 기존 주문과 연결된 후속 처리로 이어짐 |
보존된 변경 이력은 템플릿 적용 사실과 영향 화면을 확인해 줍니다. 다만 템플릿 파서의 세부 구현이나 공개할 수 없는 열 이름까지 재현할 근거는 없으므로, 이 글에서는 확인된 입출력과 QA 범위까지만 설명합니다.
primer merge에서는 값보다 순서가 중요했습니다
후속 보완에서 가장 작아 보이지만 중요한 변경은 primer merge의 입력 순서를 지키는 일이었습니다. 여러 primer를 하나로 묶을 때 같은 값이 모두 포함됐더라도 사용자가 입력한 순서가 바뀌면 의도한 주문 정보와 달라질 수 있습니다. 집합이 같은지보다 순서 있는 목록이 그대로 유지되는지가 불변조건이었습니다.
설명용 이름으로 검증 기준을 표현하면 다음과 같습니다.
| 입력 순서 | 허용되는 merge 결과 | 허용하지 않는 결과 |
|---|---|---|
| Primer B → Primer A | Primer B → Primer A | 이름순으로 A → B 재정렬 |
| Primer C → Primer A → Primer B | C → A → B | 중간 항목 누락 또는 순서 변경 |
변경 이력에는 primer merge 시 입력 순서를 보장하도록 로직을 보완한 사실이 남아 있습니다. 공개 가능한 소스 본문은 없어서 특정 컬렉션이나 SQL 정렬식을 실제 구현처럼 만들지 않았습니다. 대신 주문 입력과 merge 결과의 순서가 같은지를 검증 조건으로 고정했습니다.
일본어 기준정보와 메일도 별도 산출물이었습니다
화면 문구만 번역하면 서비스가 현지화됐다고 보기 어렵습니다. 주문과 결과 화면이 참조하는 기준정보, 사용자가 받는 메일 템플릿까지 같은 서비스 용어를 사용해야 합니다. 이번 작업에서는 일본어 기준정보와 메일 템플릿을 적용하고, 주문·결과 화면의 번역 항목도 함께 반영했습니다.
번역의 자연스러움만 본 것이 아니라 값이 노출되는 시점도 확인했습니다.
- 주문 단계에서 대상 서비스와 입력 항목을 일본어로 식별할 수 있는지
- 접수·결과 화면에서 같은 업무 용어가 이어지는지
- 결과 안내 메일에 일본어 템플릿이 적용되는지
- 권한이 없는 사용자에게 업무 기능이 노출되지 않는지
일본어 문구 원문과 내부 코드값은 공개하지 않습니다. 기준정보·화면·메일에서 같은 서비스 용어가 쓰이는지 주문부터 결과 안내까지 확인했습니다.
권한과 QA도 오픈 조건에 포함했습니다
변경과 QA 범위를 하나의 성공 표시로 묶지 않고, 남아 있는 근거 유형에 따라 나눠 확인했습니다.
| 검증 영역 | 확인한 범위 | 확인 근거 |
|---|---|---|
| 일본어 적용 | 기준정보, 화면 문구와 결과 메일 | QA 기록 |
| 주문·접수 | 템플릿 입력부터 LIMS 접수까지의 연결 | QA 기록 |
| 결과·재반응 | 결과 조회와 재반응 후속 흐름 | QA 기록 |
| primer merge | 입력 순서 보존 | 후속 변경 이력과 입출력 불변조건 |
| 권한 | 역할에 따른 기능 접근 범위 | QA 기록 |
QA 피드백과 권한 설정을 반영한 뒤 2024년 4월 23일 운영에 열었고, 오픈 후 정상 사용을 확인했습니다. 자동화 테스트 코드를 확인할 수 있는 범위는 아니므로 단위 테스트를 수행했다고 바꾸어 쓰지 않고, 실제로 남아 있는 QA 대상과 오픈 확인을 검증 결과로 기록합니다.
이 사례에서 남은 설계 기준
해외 서비스를 도입할 때는 주문부터 결과까지 어떤 값과 책임이 이어지는지 확인해야 합니다. 특히 사용자가 입력한 순서처럼 다음 단계의 의미를 바꾸는 규칙은 명시적인 불변조건으로 다뤄야 합니다.
20개 Gap을 유지·변경·제외로 나눈 사례는 법인별 차이를 이관 범위로 바꾸는 판단을 설명합니다. Nanopore LIMS 데이터 모델 사례는 주문 이후 샘플·반응·플레이트 상태를 어떻게 분리했는지 보여 줍니다. 이 글은 그 사이에서 주문 템플릿, 순서 규칙, 현지화와 권한을 하나의 운영 흐름으로 연결한 사례입니다.