새 버전 배포 뒤 주문 조회가 이상해져 프로그램을 이전 버전으로 돌렸다고 가정해 보겠습니다. 서버는 다시 켜졌는데, 이전 프로그램이 읽던 DB 컬럼은 이미 삭제돼 있습니다. 또는 컬럼은 남아 있어도 새 버전이 기록한 상태 값을 구버전이 해석하지 못합니다. 이때 “배포 취소” 버튼은 눌렀지만 서비스는 복구되지 않은 셈입니다.
해외선물솔루션 업데이트에서 되돌릴 수 있어야 하는 것은 실행 파일만이 아닙니다. 이전 버전이 현재 데이터를 읽고, 이후 들어오는 주문 이벤트를 계속 처리할 수 있는지까지 확인해야 합니다. 이 글은 주문 상태 컬럼을 바꾸는 가상 사례로 그 검수 기준을 설명합니다. 가격·임대·분양 비교가 아니라, 개발사와 운영자가 배포 승인 전에 함께 확인할 기술 범위에 초점을 맞췄습니다.
이번 변경의 범위부터 고정합니다
예시는 주문 테이블의 legacy_status를 새 컬럼 status_code로 옮기는 작업입니다. 상태의 뜻과 주문 처리 규칙은 바꾸지 않습니다. 아래 코드명·버전·주문 식별자는 설명용이며 실제 고객 시스템이나 FIX 표준 필드가 아닙니다.
실제 체결 원장, 포지션 계산, RMS 규칙까지 함께 바뀐다면 별도 변경으로 나누어 검수해야 합니다. 컬럼 이름을 바꾸는 작업에 업무 규칙 변경까지 섞으면 어느 단계에서 의미가 달라졌는지 추적하기 어렵습니다.
1. 어떤 버전이 무엇을 읽고 쓰는지 먼저 적습니다
배포 중에는 구버전 서버가 모두 동시에 사라지지 않습니다. 주문 API는 교체됐어도 체결 수신 워커, 예약 작업, 관리자 수정 도구가 남아 있을 수 있습니다. DB에 값을 쓰는 프로그램을 빠짐없이 찾는 일이 출발점입니다. 사용자 화면만 확인해서는 이 경로가 보이지 않습니다.
기존 표현을 바로 지우지 않고 새 구조를 추가한 뒤 사용처를 옮기고 마지막에 정리하는 방식은 Expand–Migrate–Contract로 설명할 수 있습니다. Danilo Sato의 Parallel Change 설명이 이 단계 구분의 참고 자료입니다. 아래 표는 그 원칙을 주문 상태 컬럼 변경에 적용한 설계 예시이며, 모든 서비스에 그대로 적용하는 배포 절차는 아닙니다.
모바일에서는 표를 좌우로 밀어 전체 내용을 확인하세요.
| 단계 | 읽기 기준 | 쓰기와 다음 단계 조건 |
|---|---|---|
| 새 컬럼 추가 | 기존 컬럼 | 기존 프로그램의 조회·입력이 그대로 동작하는지 검증. 새 컬럼을 즉시 필수 입력으로 만들지 않음. |
| 호환 버전 배포 | 기존 컬럼 | 호환 버전은 두 컬럼을 같은 트랜잭션에서 갱신. 기존 컬럼만 쓰는 모든 프로세스의 종료·접근 차단을 확인. |
| 과거 행 채우기 | 기존 컬럼 | 현재 변경과 충돌하지 않게 백필. 미변환·불일치·미지원 값과 작업 재개 결과를 확인. |
| 새 읽기 전환 | 새 컬럼 | 검증이 끝난 뒤 전환. 롤백을 허용하는 기간에는 기존 컬럼도 계속 일치하게 기록. |
| 기존 컬럼 정리 | 새 컬럼 | 구버전 의존성과 롤백 기간이 끝났다는 증거를 확인한 뒤 별도 승인. |
두 컬럼이 같은 DB 행에 있다는 예시이므로 단일 트랜잭션을 가정했습니다. 서로 다른 DB나 메시지 시스템에 각각 기록한다면 이 가정은 성립하지 않습니다. 실패 중간 상태, 재처리와 정합성 확인을 별도로 설계해야 합니다. DB 트리거로 동기화하는 대안도 가능하지만, 중복 갱신·순환 호출·권한·제거 절차를 검토하지 않은 채 임시 해결책으로 넣어서는 안 됩니다.
상태를 바깥 시스템에 전달하는 코드표까지 달라진다면 주문 상태·오류 코드 매핑 기준도 함께 확인하세요. 이 글의 예시는 의미가 같은 표현의 이전으로 제한하며, 새 상태 종류를 추가하는 변경은 뒤로 미룹니다.
2. “NULL이 없으니 완료”가 틀리는 한 가지 경우
백필은 기존 행에 새 형식의 값을 채우는 작업입니다. 다음은 백필 자체는 성공했지만, 구버전 쓰기가 남아 있어 상태가 어긋나는 가상 재현 시나리오입니다. 실제 장애 기록이나 시험 완료 결과가 아닙니다.
| 순서 | 발생한 작업 | 기존 값 / 새 값 |
|---|---|---|
| A | 부분 체결 상태의 주문이 존재 | PARTIAL / NULL |
| B | 백필이 현재 상태를 새 표현으로 변환 | PARTIAL / PARTIALLY_FILLED |
| C | 남아 있던 구버전 워커가 전량 체결 이벤트 처리. 기존 컬럼만 갱신 | FILLED / PARTIALLY_FILLED |
| D | 신버전이 새 컬럼에 값이 있다는 이유로 그대로 표시 | 기존 값은 전량 체결인데 화면은 부분 체결로 표시 |
새 컬럼이 비었을 때만 기존 값을 대신 읽는 방식으로는 C의 불일치를 찾지 못합니다. 새 값이 존재한다는 사실과 그 값이 최신이라는 사실은 다릅니다. SQL의 COALESCE처럼 비어 있지 않은 값을 우선하는 처리만으로 동기화가 보장되지는 않습니다.
그래서 호환 기간에는 어느 표현이 기준인지 하나로 정해야 합니다. 위 예시에서는 기존 컬럼을 기준으로 유지하고, 기존 컬럼만 갱신하는 프로세스를 모두 전환하거나 차단한 다음 새 컬럼을 검증합니다. 구버전 작업자가 다시 실행될 수 있다면 서버 대수만 세지 말고 예약 실행, 재시도 큐, 수동 운영 도구까지 포함해 차단 조건을 확인해야 합니다.
검수의 끝도 화면 문구가 아닙니다. 같은 주문에 대해 상태, 누적 체결 수량, 미체결 수량과 해당 상태를 사용하는 RMS 계산이 일치하는지 봐야 합니다. 이 연결 관계는 RMS 상태·예약 한도 검수와 함께 검토할 수 있습니다.
3. 백필 완료와 DB 변경 완료는 다른 판정입니다
최신 값을 과거 값으로 덮어쓰지 않는지 확인합니다
구버전 쓰기를 없애도, 백필이 행을 읽은 직후 정상 주문 처리가 그 행을 바꾸는 경쟁 상황은 남습니다. 읽어 둔 옛 상태를 나중에 무조건 기록하면 호환 버전의 최신 쓰기를 덮을 수 있습니다. 행 버전 비교나 적절한 잠금 등, 사용하는 DB와 트랜잭션 정책에 맞는 동시 변경 보호가 필요합니다.
행 버전을 비교하는 설계라면 “모든 상태 변경 경로가 같은 버전을 갱신한다”는 전제도 검수 대상입니다. 이름만 버전인 컬럼을 추가해 두고 일부 워커가 갱신하지 않으면 보호 장치로 쓸 수 없습니다. 충돌한 행은 성공 건수에 넣지 말고 현재 값을 다시 읽어 처리하거나 예외 목록으로 남겨야 합니다.
백필은 작은 범위로 나누어 중단·재개와 재실행을 시험합니다. 재개 위치, 처리한 범위, 충돌·실패 건수, 변환 규칙의 버전을 기록하고 작업이 끝난 뒤에도 데이터 대조를 수행합니다. GitLab의 배치 백그라운드 마이그레이션 문서도 작업 완료 확인 전에는 새 데이터에 의존하지 않도록 구분합니다. 이는 참고 사례이지 해당 프레임워크의 기능을 이 솔루션이 제공한다는 뜻은 아닙니다.
짧은 DB 구조 변경(DDL)도 대기 시간이 길 수 있습니다
과거 행을 나누어 옮겼다고 해서 컬럼 추가·자료형 변경·제약조건 적용까지 자동으로 안전해지지는 않습니다. 예를 들어 PostgreSQL 18의 ALTER TABLE 문서는 세부 명령별 잠금 차이를 설명하고, 별도 명시가 없으면 강한 잠금을 요구한다고 안내합니다. 다른 DB 제품·버전의 동작을 이 설명으로 대신 판단하면 안 됩니다.
실행 자체가 짧더라도 기존 장기 트랜잭션 때문에 잠금을 기다릴 수 있습니다. 운영과 유사한 데이터 양·인덱스·동시 쓰기 조건에서 잠금 대기, 오류, 복제 지연을 관찰하세요. 대기 제한 시간과 중단 조건, 중단 뒤 남은 작업의 확인 방법을 정하고, 근거 없이 “이 명령은 무중단”이라고 승인하지 않는 것이 좋습니다.
4. 새 컬럼으로 읽기를 바꾸는 승인 조건
로그인과 상태 조회가 HTTP 200으로 응답하는 것만으로는 충분하지 않습니다. 다음 조건을 만족한다는 자료를 확인한 뒤 읽기 기준을 전환합니다. 측정 기준 시각이 다른 두 결과를 비교해 불일치로 오판하지 않도록, 같은 행 버전이나 동일한 관측 기준에서 대조하는 방법도 정해야 합니다.
- 쓰기 경로: 기존 컬럼만 갱신하는 API·워커·작업·관리 도구가 남아 있지 않고 다시 실행되는 경로도 통제됩니다.
- 데이터 의미: 전환 대상의 누락, 코드표에 없는 값과 설명되지 않은 구·신 표현 불일치가 해소됐습니다. 행 개수만 같다는 결과는 대체 증거가 아닙니다.
- 업무 흐름: 부분 체결, 취소 요청과 체결의 교차, 주문 거절 후에도 업무 규칙과 수량의 의미가 유지됩니다. 상태 변환 작업이 새 주문을 발행하지 않는지도 확인합니다.
- 단말: 구·신 서버를 오가는 HTS·MTS와 재접속한 단말이 같은 기준 시점의 상태를 표시합니다.
- 운영 상태: 주문 처리 지연·오류, 잠금 대기·복제 지연을 배포 전 기준과 비교하고, 합의한 중단 기준을 넘지 않았습니다.
누락을 임의의 기본값으로 채워 “정상”으로 만드는 것은 승인 기준을 통과시키는 방법이 아닙니다. 뜻을 알 수 없는 값은 별도 목록과 확인 책임자를 남겨야 합니다. 단말 쪽 확인 범위는 MTS 재접속과 주문 상태 표시에 정리돼 있습니다.
5. 어느 버전까지 되돌릴 수 있는지 이름을 적습니다
“문제 발생 시 롤백”이라는 한 줄 대신, 되돌릴 프로그램 버전과 그 버전이 읽을 데이터 구조를 적어야 합니다. 호환 버전을 이미 만들어 놓았다면 원래 구버전이 아니라 그 호환 버전이 복귀 대상일 수 있습니다.
기존 컬럼만 쓰는 원래 구버전으로 복귀했다면, 그 이후 새 컬럼이 다시 오래된 값이 될 수 있다는 점도 기록하세요. 다음 배포에서는 동기화와 대조를 다시 마치기 전까지 새 컬럼 읽기를 재개하지 않아야 합니다. “한 번 백필했다”는 이력이 이후의 호환성까지 보장하지는 않습니다.
| 상황 | 판단할 내용 |
|---|---|
| 새 읽기만 문제 | 기존 컬럼이 계속 최신으로 유지된다면 검증된 이전 읽기 경로로 전환할 수 있는지 확인. |
| 새 코드값·업무 의미 도입 | 복귀 버전이 그 값을 이해하는지 확인. 그렇지 않으면 프로그램만 되돌리는 방식은 부적절. |
| 기존 컬럼 삭제 | 그 컬럼에 의존하는 버전으로의 복귀 경로는 닫혔음. 구조·데이터 복구 또는 호환 수정 배포를 별도로 판단. |
| 백업 시점 이후 주문·체결 존재 | DB 복원은 외부 시스템에서 일어난 사실을 취소하지 않음. 복원 이후 누락 데이터와 외부 기록의 대조·복구가 필요. |
호환성 유지와 빠른 복귀의 중요성은 AWS의 롤백 안전성 설명에서도 다룹니다. 위의 주문 데이터 복구 질문은 그 일반 원칙을 바탕으로 정리한 검토 항목이며 특정 거래소의 복구 절차를 뜻하지 않습니다.
백업 파일이 있다는 사실과 복원 후 정상 운영할 수 있다는 사실을 분리해서 보세요. DB를 이전 시점으로 복원하는 동안 외부에서 확정된 체결까지 되돌아가는 것은 아닙니다. 임의로 운영 DB를 덮어쓰지 말고, 복구 범위·대조 기준·중단 및 재개 권한을 정한 절차로 검토해야 합니다. 백업 복원과 운영 변경 기록도 함께 확인할 항목입니다.
6. “지원합니다” 대신 이 시험을 요청하세요
아래는 개발사와 시험 환경에서 합의해 쓸 수 있는 검수안입니다. 실제 주문·고객 데이터로 실행하는 절차도, 당사가 통과했다고 주장하는 시험 결과도 아닙니다. 대상 버전·DB 제품·쓰기 경로·합격 조건을 먼저 적은 뒤 결과와 증빙을 채워 넣는 용도입니다.
| 시험 | 재현 조건 | 확인할 결과 |
|---|---|---|
| T01 · 구버전 잔존 | 기존 컬럼만 쓰는 시험 워커를 남김 | 읽기 전환 승인이 차단되고 잔존 경로가 식별됨 |
| T02 · 동시 변경 | 백필이 읽은 뒤 같은 주문의 상태를 변경 | 옛 값으로 덮어쓰지 않음. 충돌의 재처리·예외 기록 확인 |
| T03 · 작업 재개 | 배치 중단 뒤 같은 범위를 다시 처리 | 중복 업무 이벤트 없이 재개하고 최종 의미 대조가 일치 |
| T04 · 미지원 값 | 코드표에 없는 시험 값을 주입 | 임의의 정상 상태로 치환하지 않고 예외와 승인 차단 확인 |
| T05 · 실패와 복귀 | 두 컬럼 쓰기 중 오류 유발, 이후 호환 버전으로 복귀 | 예시의 단일 트랜잭션이 부분 기록을 남기지 않음. 복귀 후에도 신규 변경 처리 가능 |
| T06 · 단말 재접속 | 배포 전 단말을 유지한 채 재연결 | 주문 수량·상태·RMS 연계와 화면 해석이 같은 기준에서 일치 |
| T07 · 잠금 대기 | 장기 트랜잭션과 DB 구조 변경을 겹침 | 합의한 대기 제한·중단 기준이 작동하고 잔여 작업을 식별 |
| T08 · 정리 단계 | 구버전 의존성이 남은 상태에서 기존 컬럼 삭제 승인 시도 | 배포 승인 절차가 차단. 호환성 종료 조건을 충족하기 전 삭제하지 않음 |
검수 기록용 CSV 내려받기 — UTF-8, 위 8개 시험과 결과·증빙·담당자 기록 칸을 포함합니다. 시험 환경에서 확인한 뒤 내부 기준에 맞게 수정하세요.
인수할 자료도 실행 파일에 그치지 않습니다. 전후 스키마, 코드 매핑표, 마이그레이션·백필 버전, 모든 쓰기 경로 목록, 단계별 승인 기록, 복귀 가능한 버전과 복귀 불가 조건을 받아야 합니다. 배포 후 일정 시간 오류가 없었다는 화면 캡처만으로 이 자료를 대신하지 않는 것이 좋습니다.
해외선물솔루션 분양이나 맞춤 개발 계약을 검토한다면 DB 스키마·마이그레이션 인수 범위와 공급사 검수 증빙 질문에 이 항목을 연결해 보세요. 임대형이라도 변경 공지, 시험 결과와 장애 시 책임 범위는 공급사에 확인할 수 있습니다.
배포 승인 전에 물을 마지막 질문은 간단합니다. “지금 문제가 나면 어느 버전으로 돌아가며, 그 버전은 방금 기록된 주문 상태를 읽을 수 있습니까?” 답이 실행 파일 이름에 그친다면 데이터 호환성과 복구 절차를 더 확인해야 합니다.
자료와 적용 범위
확인일: 2026년 9월 23일. 공개 기술 문서의 일반 원칙을 참고해 가상 주문 상태 변경 사례와 검수안을 구성했습니다. 글에 등장하는 버전·코드·시험은 특정 고객의 운영 사례나 실측 성능이 아닙니다. 현재 사용 중인 DB와 연동 제품의 정확한 버전 문서를 우선 확인하세요.
- Parallel Change — Danilo Sato, martinfowler.com: 확장·이전·정리의 단계 구분.
- GitLab — Batched background migrations: 긴 데이터 변경 작업의 배치 처리와 완료 확인.
- PostgreSQL 18 — ALTER TABLE: DB 구조 변경의 잠금과 세부 명령별 동작.
- AWS — Ensuring rollback safety during deployments: 버전 간 호환성과 복귀 가능성을 고려한 배포.
적용 전 확인
이 자료는 B2B 소프트웨어 도입을 위한 일반 정보입니다. 금융투자업 인가, 고객 자금 취급, 주문 중개와 데이터 라이선스 요건은 사업 구조와 관할 지역에 따라 달라질 수 있으므로 실제 운영 전 별도 검토가 필요합니다.