발견 사항 · 기술 진단 보고서 샘플

F-03 치명 코드 조치 · 오픈 전 예시

결제 승인과 주문 저장 사이 트랜잭션 경계 누락

근거: 결제 승인 콜백 처리에서 PG 승인 결과 기록과 주문 상태 변경이 서로 다른 커밋으로 저장되는 구조.
영향: 두 번째 저장이 실패하면 결제는 승인됐는데 주문은 '결제 대기'로 남는다. 고객 문의와 수기 정정이 생긴다.
발생 조건: DB 일시 장애, 커넥션 고갈, 배포 중 서버 재시작이 승인 처리와 겹칠 때.
권고: 두 저장을 한 트랜잭션으로 묶고, 실패하면 승인 취소 또는 재처리 대기열로 보낸다. 결제·주문 일 단위 대사 작업을 추가한다.

무슨 일이 생길 수 있나요?

돈은 빠져나갔는데 주문서에는 아직 '결제 전'으로 보이는 일이 생길 수 있습니다.

무엇을 하면 되나요?

두 기록을 한 번에 저장하도록 묶고, 어긋난 건을 매일 찾아내는 점검을 붙입니다. (오픈 전)

F-07 치명 연동 조치 · 오픈 전 예시

결제 완료 통지를 두 번 받으면 주문이 두 번 처리될 수 있음

근거: PG 완료 통지(웹훅) 처리에 거래 번호 기준 중복 확인이 없다.
영향: 같은 주문의 출고 지시가 WMS로 두 번 전달되어 중복 출고가 생길 수 있다.
발생 조건: PG가 응답 지연을 이유로 같은 통지를 다시 보낼 때.
권고: 거래 번호 기준 중복 방지 키와 처리 이력 테이블을 두고, WMS 출고 지시에도 같은 키를 넘긴다.

무슨 일이 생길 수 있나요?

결제 회사가 '결제 끝났어요' 알림을 두 번 보내면 상품이 두 번 나갈 수 있습니다.

무엇을 하면 되나요?

같은 알림은 한 번만 처리하도록 처리 기록을 남기고, 창고에도 같은 표시를 넘깁니다. (오픈 전)

F-05 높음 연동 조치 · 오픈 전 예시

WMS 호출에 대기 시간 제한이 없어 API 서버가 함께 멈출 수 있음

근거: WMS 출고 지시 호출이 HTTP 클라이언트 기본값(대기 시간 제한 없음)으로 동기 실행된다.
영향: WMS가 느려지면 API 서버 작업자가 모두 대기에 묶여 주문 화면까지 응답하지 않는다(연쇄 장애).
발생 조건: WMS 점검·지연으로 응답이 수십 초 걸릴 때.
권고: 호출 대기 시간을 짧게 제한하고, 출고 지시는 대기열로 분리해 비동기로 재시도한다.

무슨 일이 생길 수 있나요?

창고 시스템이 느려지면 쇼핑몰 주문 화면까지 같이 멈출 수 있습니다.

무엇을 하면 되나요?

창고에 보내는 요청은 줄을 세워 따로 보내고, 오래 기다리지 않게 제한을 둡니다. (오픈 전)

F-02 높음 인프라 조치 · 오픈 후 2주 예시

운영 DB가 단일 가용 영역에서만 동작

근거: 운영 DB 인스턴스의 다중 가용 영역 설정이 꺼져 있고, 대체 인스턴스가 없다.
영향: 해당 영역 장애 시 수동 복구가 끝날 때까지 주문을 받을 수 없다.
발생 조건: 클라우드 가용 영역 장애, DB 인스턴스 장애.
권고: 다중 가용 영역 구성 또는 복제본 승격 절차를 마련하고 전환 시험을 1회 진행한다.

무슨 일이 생길 수 있나요?

DB가 한 곳에만 있어서, 그곳에 문제가 생기면 복구될 때까지 주문이 멈춥니다.

무엇을 하면 되나요?

다른 위치에 대기 DB를 두고 넘겨받는 연습을 한 번 해 둡니다. (오픈 후 2주)

F-09 높음 복구 조치 · 오픈 후 2주 예시

백업은 매일 되지만 복원 시험 기록이 없음

근거: 자동 스냅샷 설정은 있으나 복원 절차 문서와 시험 이력이 없다.
영향: 장애가 나면 얼마 만에, 어느 시점으로 돌아갈 수 있는지 알 수 없다.
발생 조건: 데이터 오삭제, DB 장애, 잘못된 배포로 데이터가 손상될 때.
권고: 검증 환경에서 복원 시험을 1회 진행해 걸린 시간을 기록하고, 목표 복구 시점·시간을 PM과 합의한다.

무슨 일이 생길 수 있나요?

백업은 하고 있지만, 실제로 되살려 본 적이 없어 복구에 얼마나 걸릴지 모릅니다.

무엇을 하면 되나요?

시험 환경에서 한 번 되살려 보고 걸린 시간을 기록합니다. (오픈 후 2주)

F-10 높음 성능 조치 · 오픈 후 2주 예시

주문 목록 조회가 주문 테이블 전체를 읽음

근거: 회원 ID·주문일 조건 조회의 실행 계획이 전체 스캔이다(해당 조건 인덱스 없음).
영향: 주문이 쌓일수록 마이페이지·관리자 주문 목록이 느려지고 DB 부하가 함께 오른다.
발생 조건: 오픈 후 주문 데이터가 늘고, 이벤트로 조회가 몰릴 때.
권고: 조회 조건에 맞는 복합 인덱스를 추가하고 관리자 목록에 페이지 나누기를 적용한다.

무슨 일이 생길 수 있나요?

주문이 많아질수록 '내 주문 내역' 화면이 점점 느려집니다.

무엇을 하면 되나요?

자주 찾는 조건으로 바로 찾아가는 색인을 만들어 둡니다. (오픈 후 2주)

F-04 보통 코드 조치 · 오픈 후 2주 예시

앱 주문 버튼을 빠르게 두 번 누르면 주문이 두 개 생길 수 있음

근거: 앱 주문 버튼에 중복 탭 방지가 없고, 서버 주문 생성에도 요청 단위 중복 확인이 없다.
영향: 같은 내용의 주문이 두 건 생성되고, 결제 단계에서 고객 혼란이 생긴다.
발생 조건: 네트워크가 느려 버튼 반응이 늦을 때.
권고: 버튼을 누르면 처리 중 상태로 막고, 서버는 요청 키로 같은 요청을 한 번만 받는다.

무슨 일이 생길 수 있나요?

인터넷이 느릴 때 주문 버튼을 두 번 누르면 주문이 두 개 생길 수 있습니다.

무엇을 하면 되나요?

버튼은 한 번만 눌리게 막고, 서버도 같은 요청을 한 번만 받게 합니다. (오픈 후 2주)

F-06 보통 연동 조치 · 오픈 후 2주 예시

ERP 매출 전송 실패가 로그에만 남고 다시 보내지 않음

근거: 출고 확정 후 ERP 전송이 실패하면 오류 로그만 기록하고 재전송 경로가 없다.
영향: ERP 매출이 빠져 월말 정산에서 차이가 생긴다.
발생 조건: ERP 점검 시간이나 네트워크 오류와 출고 확정이 겹칠 때.
권고: 실패 건을 대기열에 남겨 재전송하고, 커머스·ERP 매출을 매일 대사한다.

무슨 일이 생길 수 있나요?

회계 프로그램으로 매출을 넘기다 실패하면 그 매출이 빠진 채로 남습니다.

무엇을 하면 되나요?

실패한 건은 다시 보내고, 두 프로그램의 매출 합계를 매일 맞춰 봅니다. (오픈 후 2주)

F-08 보통 성능 조치 · 오픈 후 2주 예시

상품 상세 API가 옵션마다 재고·가격을 따로 조회

근거: 상품 상세 응답을 만들 때 옵션 수만큼 재고·가격 질의가 반복된다.
영향: 옵션이 많은 상품에 접속이 몰리면 DB 질의 수가 급격히 늘어난다.
발생 조건: 기획전·푸시 발송 직후처럼 같은 상품에 접속이 몰릴 때.
권고: 옵션 정보를 한 번에 묶어 조회하고, 자주 바뀌지 않는 값은 짧게 캐시한다.

무슨 일이 생길 수 있나요?

옵션이 많은 상품은 화면 하나를 열 때 DB에 여러 번 물어봅니다.

무엇을 하면 되나요?

한 번에 모아서 물어보도록 바꿉니다. (오픈 후 2주)

F-11 보통 인프라 조치 · 오픈 후 2주 예시

운영 로그 보관 기간이 7일로 짧음

근거: API 서버·WMS 연동 로그 보관 기간이 7일로 설정되어 있다.
영향: 정산 차이나 고객 문의가 2주 뒤에 들어오면 원인을 추적할 기록이 없다.
발생 조건: 월말 정산, 늦게 들어오는 고객 문의.
권고: 주문·결제·연동 로그는 최소 정산 주기 이상 보관하고, 개인정보는 가린 채 저장한다.

무슨 일이 생길 수 있나요?

기록이 일주일 뒤 지워져서, 늦게 발견한 문제의 원인을 찾기 어렵습니다.

무엇을 하면 되나요?

주문·결제 기록은 정산이 끝날 때까지 보관합니다. (오픈 후 2주)

F-01 낮음 인프라 조치 · 다음 개선 주기 예시

쓰지 않는 개발용 접속 규칙이 운영 계정에 남아 있음

근거: 운영 계정 보안 그룹에 개발 단계에서 쓰던 접속 허용 규칙이 남아 있다(연결된 자원 없음).
영향: 당장 노출은 없지만 다음 설정 변경 때 실수로 열릴 수 있다.
발생 조건: 보안 그룹을 재사용할 때.
권고: 쓰지 않는 규칙을 지우고, 규칙마다 용도를 적는다.

무슨 일이 생길 수 있나요?

지금은 쓰지 않는 출입문 설정이 남아 있습니다.

무엇을 하면 되나요?

쓰지 않는 설정은 지우고, 남는 설정에는 용도를 적어 둡니다. (다음 개선 주기)

F-12 낮음 복구 조치 · 다음 개선 주기 예시

장애 때 누가 무엇을 하는지 정한 문서가 없음

근거: 장애 연락망, 판단 기준, 외부 연동사(PG·WMS) 연락 경로를 정리한 문서가 없다.
영향: 장애 초기에 연락과 판단이 늦어져 복구 시간이 길어진다.
발생 조건: 야간·주말 장애.
권고: 한 장짜리 장애 대응표(연락처, 우선순위, 공지 문구)를 만들고 오픈 전 공유한다.

무슨 일이 생길 수 있나요?

문제가 생겼을 때 누구에게 먼저 연락할지 정해져 있지 않습니다.

무엇을 하면 되나요?

연락 순서와 할 일을 한 장으로 정리해 나눠 둡니다. (다음 개선 주기)

발견 사항 12건

결제 승인과 주문 저장 사이 트랜잭션 경계 누락

결제 완료 통지를 두 번 받으면 주문이 두 번 처리될 수 있음

WMS 호출에 대기 시간 제한이 없어 API 서버가 함께 멈출 수 있음

운영 DB가 단일 가용 영역에서만 동작

백업은 매일 되지만 복원 시험 기록이 없음

주문 목록 조회가 주문 테이블 전체를 읽음

앱 주문 버튼을 빠르게 두 번 누르면 주문이 두 개 생길 수 있음

ERP 매출 전송 실패가 로그에만 남고 다시 보내지 않음

상품 상세 API가 옵션마다 재고·가격을 따로 조회

운영 로그 보관 기간이 7일로 짧음

쓰지 않는 개발용 접속 규칙이 운영 계정에 남아 있음

장애 때 누가 무엇을 하는지 정한 문서가 없음

공고 대응표