운영자가 미션을 세트로 묶고 사용자가 그중 하나를 선택하는 새 상품을 만들었습니다. 빈 세트를 만드는 경우는 동작했지만, 기존 캠페인·미션·세트를 차례로 복제하는 운영 순서에서는 이전 미션 ID가 새 입력에 남았습니다. 화면에는 ‘새 세트’가 보이는데 서버로 보내는 값은 이전 대상을 가리킬 수 있었습니다.

저는 운영 화면의 검증·복제 입력과 Gateway의 조회·쓰기 연결을 수정하고 참여 FE 통합에 협업했습니다. 서버의 저장·참여 정책은 기존 담당 영역이었습니다. 이 글의 핵심은 사용자에게 보이는 새 구성과 서버가 저장할 새 대상을 일치시킨 과정입니다.

실제 복제 순서에서 이전 대상을 찾았다

새 세트 하나를 만드는 테스트에서는 이 문제가 보이지 않았습니다. 동료가 알려준 운영 순서대로 캠페인·미션·세트를 차례로 복제해 재현했습니다. 복사된 미션의 내용과 함께 기존 미션 ID까지 새 입력에 남는 것이 문제였습니다.

저는 새 세트의 틀과 복사할 미션 내용을 따로 구성하고, 새 입력에서는 이전 미션 식별자를 제거했습니다. 내용은 복사하되 대상과의 관계는 복사하지 않는 선택입니다. 운영 화면에서 만든 ‘새 세트’가 서버에서도 새 대상을 가리켜야 했습니다.

새 상품의 규칙만 바꾸고 기존 참여는 유지했다

복제 입력을 고쳐도 운영자가 저장할 수 없는 세트라면 상품은 이어지지 않습니다. 새 상품에서는 기여 확인(eligibility) 미션을 세트마다 최대 하나로 제한했고, 기존 상품의 목록 단위 검증은 유지했습니다. 전체 목록에 새 검증기를 한 번 적용하면 다른 세트와 기존 상품의 규칙까지 바뀔 수 있었기 때문입니다.

사용자 참여에서는 세트 목록과 기존 제출 여부를 조회했습니다. 이미 선택했다면 기존 참여로 보내고, 처음이라면 선택을 서버에 제출한 성공 응답 뒤 기존 query를 보존해 참여 화면으로 이동했습니다. 제출 실패 때는 안내하고 제출 중 상태를 풀었습니다. 화면의 선택 상태를 서버에 확정된 선택으로 취급하지 않았습니다.

실제 전달 경로로 다시 확인했다

서버 반영 뒤 FE를 전달했지만 Gateway 연결이 빠진 조건이 발견됐습니다. 화면과 서버 코드가 맞아도 Gateway를 통과하는 운영 경로가 빠지면 저장·참여는 이어지지 않습니다. 이 연결을 수정해 배포하고 동료의 동작 확인을 받았습니다.

QA에서는 새 세트 저장, 기존 상품 입력, 운영자의 반복 복제 순서를 확인했습니다. 이미 잘못 저장된 데이터는 자동 복구되지 않아 재사용하지 않도록 안내했습니다. 과거 데이터의 규모와 사후 복구 결과는 확인하지 못했습니다.

확인된 결과는 새 구성의 식별자를 바로잡고, 운영 화면의 저장부터 사용자 선택·기존 참여까지 새 상품 경로를 연결한 것입니다. 과거 데이터 복구나 운영 영향 감소량까지 확인한 결과는 아닙니다.