주문 등록 화면에서 저장 버튼을 눌렀는데 응답이 끊겼다. 다시 누르면 주문이 두 번 들어가는지, 잠시 기다리면 되는지 판단하기 어렵다. 이 상황을 이해하려면 화면의 응답, 서버의 업무 처리, 데이터베이스의 저장 완료를 구분해야 한다.
기업 IT 시스템의 데이터는 대체로 입력, 검증, 업무 처리, 저장, 조회, 후속 처리의 흐름을 거친다. 이 글은 주문 등록을 가상 예시로 사용한다. 특정 회사의 실제 구성이나 수행 경험을 설명하는 사례는 아니며, 파일 저장과 DB 저장의 역할부터 장애 확인 기준까지 살펴본다.
같은 데이터라도 트랜잭션 위치에 따라 용도가 다름
사용자가 입력한 주문 수량은 처음에는 브라우저나 앱의 메모리에 있다. 서버로 전송되면 애플리케이션이 해석하고 계산할 수 있는 값이 된다. 이후 데이터베이스에 주문 행으로 기록되거나, 첨부파일과 함께 별도 저장소에 보관된다. 모든 데이터가 하나의 디스크에 같은 형태로 들어가는 것은 아니다.
| 위치 | 담는 내용의 예 | 구분할 점 |
|---|---|---|
| 브라우저·앱 메모리 | 입력 중인 주문 수량 | 화면에 보인다고 서버 저장이 끝난 것은 아니다 |
| 애플리케이션 메모리 | 계산 중인 금액, 검증 결과 | 프로세스 종료 시 사라질 수 있다 |
| 데이터베이스 | 주문번호, 품목, 수량, 처리 상태 | 조회·변경 규칙과 트랜잭션을 적용한다 |
| 파일·오브젝트 저장소 | 거래명세서 PDF, 첨부 이미지 | DB의 파일 식별자와 실제 파일을 함께 관리한다 |
| 캐시 | 자주 조회하는 상품 정보의 사본 | 원본보다 오래된 값일 수 있다 |
DB와 파일 저장소는 논리적 역할의 구분이다. 실제로는 같은 서버에 함께 설치되거나 각각 관리형 서비스로 제공될 수 있다. 저장 장비의 종류보다 먼저 “업무상 기준이 되는 원본이 어디인가”를 정해야 데이터 불일치를 설명할 수 있다.
입력값이 업무 데이터로 바뀌는 과정
가상으로 직원이 상품 한 종류의 주문 수량을 3개 입력했다고 하자. 애플리케이션은 요청한 사람이 주문을 등록할 권한이 있는지, 상품이 유효한지, 수량이 허용 범위인지 확인한다. 화면에서 숫자만 입력되도록 제한했더라도 서버에서 다시 검증해야 한다. 화면의 제한만으로 서버의 업무 규칙을 보장할 수 없기 때문이다.
금액도 화면에서 넘어온 값을 그대로 확정하기보다 서버가 적용 가능한 단가와 할인 규칙으로 계산하는 편이 안전하다. 반면 이미 합의된 계약 단가를 사용하는 업무라면 그 기준과 유효 기간을 조회해야 한다. 입력값 검증과 업무 규칙 검증은 함께 수행되지만 목적이 다르다.
처리는 항상 내용을 수정하는 작업만 뜻하지 않는다. 주문 합계 계산, 거래처별 조회, 재고 가용 여부 판단, 보고서 집계도 데이터 처리다. 같은 서버라도 요청 종류에 따라 DB 읽기, 메모리 계산, 외부 시스템 호출의 비중이 달라진다.
저장 완료는 트랜잭션의 상태판단
주문 등록과 재고 예약을 같은 관계형 DB에서 처리한다면 두 변경을 하나의 트랜잭션으로 묶는 설계를 검토할 수 있다. 트랜잭션은 묶인 변경을 전부 확정하거나 취소하는 단위다. PostgreSQL의 트랜잭션 설명은 이 원자적 처리의 의미를 설명한다.
다만 트랜잭션을 사용한다는 이유만으로 재고 초과 예약이 자동으로 방지되지는 않는다. 두 요청이 동시에 같은 재고를 읽는 상황까지 고려해 조건부 갱신, 잠금, 격리 수준 등을 설계해야 한다. 또한 외부 배송 시스템 호출은 일반적인 로컬 DB 트랜잭션만으로 함께 취소되지 않는다.
디스크 기록도 모든 변경 데이터 파일을 즉시 덮어쓰는 방식만 있는 것은 아니다. PostgreSQL의 WAL 설명에 따르면 변경 내용을 먼저 영속 로그에 기록하고, 장애 시 그 로그로 데이터 파일의 변경을 재적용할 수 있다. 일반적인 내구성 설정에서는 커밋에 필요한 로그 영속화와 데이터 파일 반영 시점이 다를 수 있다.
따라서 “저장 버튼을 눌렀다”, “서버가 요청을 받았다”, “DB가 커밋했다”, “사용자가 성공 응답을 받았다”는 서로 다른 사건이다. 커밋 후 응답 전달에 실패하면 화면에는 오류가 보여도 주문은 존재할 수 있다. 재요청 시 같은 업무를 중복 실행하지 않도록 요청 식별자와 중복 방지 규칙을 두는 이유다.
조회 화면은 저장된 원본과 다를 수 있음
사용자가 주문 목록을 열면 애플리케이션은 조건에 맞는 데이터를 조회하고 화면에 필요한 형태로 가공한다. 여러 테이블을 결합하거나 권한에 따라 일부 항목을 제외할 수도 있다. 조회 결과는 원본 데이터에 업무 규칙과 표시 규칙을 적용한 결과다.
조회 성능을 높이려고 캐시를 사용하면 갱신 지연이라는 문제가 생긴다. Microsoft의 Cache-Aside 문서는 캐시에 값이 없을 때 원본을 조회해 채우고, 원본 변경 뒤 관련 캐시를 무효화하는 패턴을 설명한다. 이 패턴도 캐시와 원본이 항상 같은 값을 갖는다고 보장하지는 않는다.
실무 설계에서는 조회 목적별로 허용 가능한 지연을 정하는 편이 낫다. 상품 소개 문구와 주문 확정 여부에 동일한 캐시 정책을 적용할 이유는 없다. 저장 직후 결과를 확인하는 화면은 원본 조회를 사용하거나, 갱신된 결과를 응답으로 돌려주는 방식 등을 검토할 수 있다.
요청과 트랜잭션 처리 완료는 다른 상태
주문 저장 뒤 배송 요청이나 알림 발송을 별도 작업자가 처리하도록 구성할 수 있다. 이러한 비동기 처리는 사용자가 모든 후속 작업을 기다리는 부담을 줄이지만, 주문만 저장되고 배송 요청은 대기하는 중간 상태를 만든다. 모든 기업 시스템이 메시지 큐를 사용하는 것은 아니며, 업무 규모와 복구 요구에 따라 선택한다.
메시지 큐를 사용해도 작업 완료가 자동으로 보장되지는 않는다. RabbitMQ의 신뢰성 가이드는 연결 실패와 재전송, 중복 전달에 대비한 처리를 다룬다. 수신 작업자는 같은 주문을 다시 받아도 배송을 중복 생성하지 않도록 처리 이력을 확인하는 등의 방식을 갖춰야 한다.
DB 커밋과 메시지 발행을 별개로 수행하면 그 사이에 실패할 수도 있다. 설계 대안으로 주문과 발행할 이벤트를 같은 DB 트랜잭션에 기록한 뒤 별도 작업이 전송하는 방식이 있다. 이 경우에도 재시도와 중복 처리는 남으므로, 주문 상태와 후속 작업 상태를 따로 기록하고 대조해야 한다.
실무자 관점: 장비보다 먼저 확인할 데이터 경계
다음 표는 특정 제품의 진단 절차가 아니라 이 글의 흐름에서 도출한 운영 점검 기준이다. 서버가 정상 가동 중이어도 특정 주문의 저장이나 연계 처리는 실패할 수 있다. CPU 사용률만으로 업무 성공 여부를 판단하면 중간에 멈춘 데이터를 놓치기 쉽다.
| 사용자에게 보이는 증상 | 먼저 확인할 데이터·기록 | 대응 판단 |
|---|---|---|
| 저장 중 시간 초과 | 요청 식별자, 주문번호, DB 커밋 여부 | 원본 확인 뒤 재시도 여부 결정 |
| 저장했는데 목록에 없음 | 원본 주문, 조회 조건, 캐시 상태 | 저장 실패와 조회 지연 구분 |
| 주문은 있지만 배송이 안 됨 | 후속 작업 상태, 전송 실패, 재시도 이력 | 미처리 작업을 찾아 통제된 재처리 |
| 주문이 두 번 생성됨 | 중복 요청, 업무 식별자, 중복 방지 이력 | 중복 확정 범위와 취소 대상 확인 |
| 첨부 문서가 열리지 않음 | DB의 파일 식별자, 실제 파일, 접근 권한 | 파일 누락과 권한 오류 구분 |
이 점검을 가능하게 하려면 주문번호 등 업무 식별자와 요청 추적 정보를 연결해야 한다. 로그에는 처리 시각, 단계, 결과, 오류 원인을 남기되 개인정보나 인증 정보를 불필요하게 복제하지 않는다. 운영 로그는 원인 분석 자료이며 주문 원장을 무조건 대체하는 자료는 아니다.
백업에서도 경계를 확인해야 한다. 주문 DB만 복구하고 첨부 문서가 누락되거나, 과거 시점 DB로 되돌린 뒤 이미 실행된 배송 요청을 다시 보내면 서비스가 실행되더라도 업무는 맞지 않을 수 있다. 복구 점검에는 DB, 파일, 외부 처리 이력의 대조를 포함하는 편이 타당하다.
시스템 설명의 출발점은 한 건의 트랜잭션 플로우 시작점부터
기업 시스템을 이해할 때에는 실제 업무 한 건을 골라 입력 위치, 검증 규칙, 원본 저장소, 커밋 시점, 조회 경로, 후속 작업 완료 기준을 따라가면 된다. 이 여섯 가지를 설명할 수 있으면 데이터가 어디서 지연되거나 중복될 수 있는지 파악하기 쉬워진다.
신규 구축이나 운영 인수인계에서도 “서버가 몇 대인가”와 함께 “성공 응답은 무엇의 완료를 뜻하는가”를 확인하자. 주문 저장과 배송 완료처럼 서로 다른 상태를 구분해 기록하는 것이 장애 대응과 복구 범위를 구체화하는 출발점이다.