여러 건을 한꺼번에 저장할 때 반만 들어가는 사고를 막는 법: 모두 저장하거나 하나도 저장하지 않기

2026년 8월, 보드게임 기록 앱 RankBoard에 같은 게임 기록이 두 벌로 쌓였습니다. 여러 판을 한꺼번에 저장하다 통신이 끊겨 앞부분만 들어갔고, 사용자가 저장 버튼을 다시 누르면서 그 앞부분이 한 번 더 들어간 것입니다. 여러 건을 한꺼번에 저장하는 기능은 "전부 저장되거나, 하나도 저장되지 않거나" 둘 중 하나로만 끝나야 안전합니다. 아래에는 그때 바꾼 구조를 적고, 같은 원칙을 발주서 전표 입력과 주문 일괄 처리에 옮기는 방법을 이어서 다뤘습니다.

RankBoard에서 생긴 중복 기록 사고

RankBoard는 보드게임 결과를 기록하면 상대 전적과 랭킹이 쌓이는 iOS·Android 앱입니다. 모임에서 여러 판을 한 뒤 기록을 한꺼번에 저장하는 기능이 있습니다. 예를 들어 4명이 3판을 했다면 3판의 결과를 모아 한 번에 올립니다.

처음 구조는 게임마다 요청을 따로 보내는 방식이었습니다. 1판 저장, 2판 저장, 3판 저장을 차례로 보내는 식입니다. 평소에는 문제가 없지만, 2판을 보내는 중에 통신이 끊기면 1판만 저장되고 나머지는 빠집니다. 화면에는 "실패"만 보이니 사용자는 저장 버튼을 다시 누릅니다. 그러면 이미 들어간 1판이 한 번 더 들어가 같은 기록이 두 벌이 됩니다.

원인을 따라가 보니 누가 버튼을 잘못 누른 게 문제가 아니었고, 중간에 끊길 수 있는 저장 구조 자체가 원인이었습니다. 그런 구조라면 언젠가는 끊깁니다.

구조를 어떻게 바꿨나요?

바꾼 원칙은 "한 요청, 한 번에 저장"입니다.

• 여러 판의 기록을 한 요청으로 받아 서버가 한 번에 저장합니다.
• 그중 하나라도 문제가 있으면 그 요청 전체를 취소합니다. 앞부분만 남는 일이 생기지 않습니다.
• 실패하면 "몇 번째 항목이 왜 안 됐는지"를 함께 돌려줍니다.
• 배지 계산 같은 부가 작업은 기록 저장이 끝난 뒤 따로 돌립니다. 부가 작업이 실패해도 이미 저장된 기록은 안전합니다.

데이터베이스에는 여러 작업을 한 묶음으로 처리해서, 모두 성공하면 확정하고 하나라도 실패하면 처음 상태로 되돌리는 기능이 있습니다. 개발자들은 이것을 트랜잭션이라고 부릅니다. 은행 이체에서 내 계좌에서는 빠졌는데 상대 계좌에는 안 들어가는 일이 없도록 하는 장치와 같은 생각입니다.

서버와 주고받는 횟수가 10분의 1로 줄어서 저장도 빨라졌습니다. 컬렉션을 50건까지 한꺼번에 고치는 기능에도 같은 원칙을 적용했습니다. 이때 목록에 없는 항목은 새로 만들지 않고 "없는 항목"이라고 알려 줍니다. 없는 항목을 조용히 만들어 버리면 담당자는 무엇이 잘못됐는지 알기 어렵기 때문입니다.

TIP자동화 업체에 "일괄 처리 중간에 끊기면 어떻게 되나요?"라고 물어보세요. "전부 취소되고 몇 번째 줄이 문제인지 알려 드립니다"처럼 끊긴 뒤의 상태를 구체적으로 답하는지 보면 됩니다. "다시 돌리면 됩니다"로 끝나는 답이라면 한 번 더 물어보세요.

회사 업무에서 이 원칙이 필요한 곳

반복 업무 자동화는 대부분 여러 건을 한꺼번에 처리합니다. 하루치 발주서를 판매 전표로 넣거나, 여러 쇼핑몰 주문을 모아 택배 접수 파일을 만들고 송장번호를 되돌려 올리는 일이 그렇습니다. 사람이 손으로 할 때는 한 건씩 입력하니 어디까지 했는지 눈으로 압니다. 자동화로 수십 건을 한 번에 보내면 그 감각이 사라집니다.

특히 전표는 한 번 이중으로 들어가면 월말 마감 때 찾아내기 어렵습니다. 그래서 자동화를 만들 때 처음부터 이 원칙을 넣습니다.

발주서 전표 일괄 입력에는 어떻게 적용하나요?

루코 웍스의 발주서 → ERP 전표 데모처럼 담당자가 승인한 전표를 ERP로 보내는 구조라면, 실제 구축에서 다음 순서로 만듭니다.

보내기 전에 전부 검사합니다. 거래처코드, 품목코드, 수량, 단가가 모두 채워졌는지, 마스터에 있는 코드인지 먼저 확인합니다. 한 줄이라도 문제가 있으면 아무것도 보내지 않고 "3번째 전표 2번째 줄: 품목코드 없음"처럼 위치와 이유를 보여 줍니다. ERP 같은 외부 시스템은 여러 건을 한꺼번에 되돌리는 기능을 주는지 시스템마다 다르기 때문에, 보내기 전 검사로 실패할 일을 미리 걸러 둡니다.

보낸 건마다 기록을 남깁니다. 어떤 발주서가 어떤 전표로 들어갔는지 남겨 두면, 중간에 끊겨 다시 보낼 때 이미 들어간 전표는 건너뜁니다. 담당자가 버튼을 두 번 눌러도 같은 전표가 두 번 들어가지 않습니다.

실패한 줄만 따로 보여 줍니다. 담당자는 전체를 다시 확인할 필요 없이 표시된 줄만 고치면 됩니다.

부가 작업은 뒤로 뺍니다. 처리 결과 알림이나 집계표 갱신 같은 일은 전표 입력이 끝난 뒤 따로 돌립니다. 알림이 실패해도 전표는 이미 맞게 들어가 있습니다.

TIP자동화를 시험할 때 일부러 틀린 줄을 하나 섞어 보세요. 나머지 줄이 몰래 들어갔는지, 아니면 전부 멈추고 틀린 줄을 짚어 주는지 보면 일괄 처리 구조가 바로 드러납니다.

주문 일괄 처리에서는 무엇을 확인하나요?

주문 처리는 대부분 엑셀 파일을 만들어 담당자가 올리는 방식이라 전표보다 구조가 단순합니다. 그래도 같은 원칙이 들어갑니다. 합친 주문 파일을 만들 때 필수 열이 빠진 주문이 하나라도 있으면 그 주문을 따로 모아 보여 주고, 담당자가 확인하기 전에는 접수 파일에 넣지 않습니다. 판매처 API로 송장을 직접 등록하는 구조라면 전표와 마찬가지로 보낸 주문을 기록해 두고 다시 보내지 않게 만듭니다.

어떤 업무를 먼저 자동화할지 고를 때 "틀렸을 때 비용"을 함께 적어 보라고 첫 자동화 업무 고르는 글에서 권했습니다. 전표처럼 틀렸을 때 비용이 큰 업무일수록 이 원칙이 들어가 있는지 먼저 확인하는 편이 좋습니다.

업체에 물어볼 질문

자동화 업체와 이야기할 때 아래 질문에 구체적으로 답하는지 보면 됩니다.

• 일괄 처리 중간에 실패하면 이미 처리된 건은 어떻게 되나요?
• 같은 버튼을 두 번 누르면 같은 전표나 주문이 두 번 처리되나요?
• 실패했을 때 몇 번째 줄이 왜 안 됐는지 화면에서 볼 수 있나요?
• 알림이나 집계 같은 부가 작업이 실패하면 이미 들어간 전표는 어떻게 되나요?

RankBoard의 사고는 기록 몇 줄이 겹친 일이었지만, 같은 구조가 회사 장부에 들어가면 매출과 재고가 틀어집니다.