지표 버전 관리 및 결재 승인 프로세스의 일관성을 보장하기 위한 멱등적 구조 설계

요약

1. 문제 정의

지표관리 화면은 한 지표에 대해 “등록 → 수정 → 결재요청 → 승인(새 버전 생성)”이라는 전체 수명주기를 담당해요.
그러나 다음과 같은 문제로 인해 버전 일관성·결재 상태 일관성·동시성 안전성이 깨질 위험이 있었어요.

기존 문제 상황

1. 여러 사용자가 같은 지표를 동시에 수정할 수 있음

2. 한 사용자가 결재요청을 한 뒤에도,
   다른 사용자가 기존 화면 그대로 결재요청을 다시 시도하는 것이 가능함

3. 이때 TASK 테이블에서

   • 동일 지표(ANMLY_INDIC_ID)에 대해
     ANMLY_INDIC_STAT_CD = '02'(결재중) 상태의 작업본이 여러 건 생성되는 문제 발생

4. 결재버전기준 테이블(VER_DTL / THLD_DTL / MNG_DEPT_DTL)은
   버전별 1개(또는 3개, N개) 행만 존재해야 하는 강한 일관성 규칙을 가짐
   그러나 결재중 TASK가 여러 건 존재하면

   • 어떤 TASK가 실제 승인되어야 하는지 불명확해지고
   • 승인 후 버전 증가(batch) 시
     중복된 버전 생성, 부서 매핑 꼬임, 임계치 정보 충돌 등 심각한 데이터 불일치 위험 발생

즉,

2. 원인 분석

(1) 화면 상태 기반 처리의 한계

지표관리 화면은 사용자가 지표를 선택하거나 버튼을 클릭할 경우, 다음과 같이 상태를 분기 별로 처리했어요.

• 내 작업본 존재 → 수정 모드
• 내 작업본 없음 → 최신 승인본 view 모드
• 등록 버튼 클릭 → 등록 모드 → 저장 후 작업본 생성
• 수정 버튼 클릭 → 수정 모드 → 수정 및 결재요청 가능

하지만 화면 상태(ScreenState.mode, ScreenState.isDirty)만으로
지표가 현재 결재 가능한지 여부를 판단했어요.

실제 DB 상태(누가 어떤 지표를 결재중인지)는 전혀 확인하지 않았어요.

(2) 결재요청 API가 상태만 바꿈 (검증 없음)

기존 결재요청 API는:

shell
작성중(01) → 결재중(02)

으로 변경하는 것만 수행하고,
이미 다른 사람이 결재 요청했는지에 대해서는 검증하지 않았어요.

중복 결재중 TASK 생성 가능

(3) 사전 체크 API 부재

프론트에서는 결재요청 시 다음과 같은 정보가 필요하지만,
어디에서도 조회하고 있지 않았어요.

• 현재 지표에 작업본이 있는가?
• 그 작업본의 상태는 무엇인가? (작성중인지, 결재중인지)
• 누가 작업한 것인가?

결과적으로,

• A가 결재요청했어도
• B 화면에서는 여전히 “작성중”으로 보이고
• “결재요청” 버튼이 활성화된 상태 유지

3. 해결 전략 (멱등 + 일관성 보장 구조 설계)

전체 해결책은 **UX 레벨 사전 방어 + 서버 레벨 최종 방어(멱등성)**의 이중 구조로 설계했어요.

1) 사전 체크 API 신설 — /retrieve-appv-task

결재요청 버튼 클릭 시 항상 서버에 실제 상태를 확인하도록 새로운 API를 만들었다.

쿼리에서 다음 조건을 만족하는 작업본 최신 1건만 조회:

• ANMLY_INDIC_ID 동일
• 상태가 작성중(01)이 아닌 모든 작업본 (02:결재중, 03:승인완료 등)
• RN(ROW_NUMBER) = 1 (가장 최신)

이를 통해 프론트는 결재 요청 전에 사용자에게 다음과 같이 안내할 수 있게 되었어요.

사용자는 현재 상태를 정확히 인지한 뒤 다음 행동을 할 수 있게 되었고,
잘못된 결재 요청 시도를 UI 단계에서 먼저 걸러낼 수 있게 되었어요.

2) 실제 결재요청 API에서 DB 조건부 UPDATE로 멱등성 보장

사전 체크는 어디까지나 UX용이고,
동시 클릭·여러 탭 등은 항상 존재하는 리스크이기 때문에,
핵심은 결재요청 API에 한 번 더 강력한 DB 제약을 넣는 것이에요.

조건부 UPDATE (핵심)

sqlCopy
UPDATE TB_EWS_ANMLY_INDIC_VER_TASK_DTL T
SET ANMLY_INDIC_STAT_CD = '02'
WHERE T.ANMLY_INDIC_CHG_TASK_ID = #{taskId}
  AND T.ANMLY_INDIC_STAT_CD = '01'
  AND NOT EXISTS (
      SELECT 1
      FROM TB_EWS_ANMLY_INDIC_VER_TASK_DTL X
      WHERE X.ANMLY_INDIC_ID = T.ANMLY_INDIC_ID
        AND X.ANMLY_INDIC_CHG_TASK_ID != T.ANMLY_INDIC_CHG_TASK_ID
        AND X.ANMLY_INDIC_STAT_CD IN ('02','03')
  )

• 먼저 들어온 결재요청만 작성중 → 결재중으로 변경
• 조건을 만족하지 않으면 updated=0 → 즉시 실패
• 즉, 두 요청이 동시에 들어와도 단 한 요청만 성공

이 패턴을 통해 지표결재 프로세스의 핵심 비즈니스 제약이 보장돼요.

이 구조 자체가 멱등성(Idempotent)을 만족하며,
동일 요청이 여러 번 반복되어도 DB 상태는 변하지 않아요.

3) 전체 화면 흐름도 비즈니스 규칙과 동기화

• 등록모드 → 최초 저장 → 사용여부는 ‘미사용’ 고정
• 사용하려면 → 수정모드 → 저장 → 결재요청
• 결재승인 시 → VER 테이블에 새 버전 Insert
• THLD_DTL, MNG_DEPT_DTL 등도 단일 버전 기준으로 정확히 1:N 구조 보장
• 승인 완료 시 → 마스터 테이블의 “적용중 버전”이 새 버전으로 업데이트

즉,
등록 ⇒ 수정 ⇒ 결재요청 ⇒ 승인 ⇒ 새 버전 반영
전 과정이 데이터 규칙 기반으로 자동 정렬되었어요.

4. 결과

1) 지표당 결재중 상태가 1건만 존재하는 구조 확립

중복 결재중 TASK 생성 문제 완전 해소.

2) 화면-DB 간 상태 불일치 해소

• 결재중/승인/작성중 여부가 항상 실제 DB 기준으로 판단됨
• 여러 사용자가 한 지표를 작업해도 프론트 상태만 믿는 문제 사라짐

3) 결재 프로세스의 UX 대폭 향상

사용자에게:

• “누가 결재 올렸는지”
• “현재 어떤 상태인지”

명확히 안내하므로 불필요한 혼란 제거.

✔ 데이터 무결성 보장

• THLD_DTL, MNG_DEPT_DTL, VER_DTL 등
  버전 기준 테이블과 TASK 테이블 간의 일관성 유지
• 승인 시 버전 증가 및 마스터 버전 업데이트도 깨짐 없이 작동

✔ 멱등적 결재요청 API 완성

요청이 여러 번 발생해도 DB 상태는 정확히 한 번만 변경됨.