엔터프라이즈 다단계 승인 웹앱 구축

다단계 승인 체인이란(그리고 왜 중요한가)\n\n다단계 승인 체인은 요청이 다음 단계로 진행되기 전에 거쳐야 하는 일련의 결정(스텝)을 구조화한 것입니다. 임시 이메일이나 "괜찮아 보인다"라는 메시지에 의존하는 대신, 승인 체인은 결정을 반복 가능한 워크플로로 바꾸어 책임자, 타임스탬프, 결과를 명확히 기록합니다.\n\n기본적으로, 앱은 각 요청에 대해 세 가지 질문에 답합니다:\n\n- 누가 승인해야 하는가?\n- 어떤 순서(또는 어떤 단계)로 진행되는가?\n- 각 결정 이후에 무슨 일이 발생하는가?\n\n### 순차적 vs 병렬 스텝\n\n승인 체인은 보통 두 가지 패턴을 결합합니다:\n\n- 순차적 승인: B 단계는 A가 승인될 때까지 시작할 수 없습니다. 예: 구매 요청은 팀 리드 → 재무 → 조달 순으로 필요할 수 있습니다.\n- 병렬 승인: 여러 승인자가 동시에 검토할 수 있습니다. 예: 정책 변경은 Legal과 Security의 병렬 승인 후에 진행될 수 있습니다.\n\n좋은 시스템은 두 가지를 모두 지원하고, "이 승인자 중 누군가 하나면 됨" vs. "모두 승인해야 함" 같은 변형도 제공합니다.\n\n### 전형적인 엔터프라이즈 사용 사례(일반적 예시)\n\n다음과 같은 곳에서 다단계 승인 요구가 나타납니다:\n\n- 구매(구매/조달): 벤더 선정, 예산 확인, 조달 서명\n- 경비: 매니저 승인, 재무 검증, 고액의 예외 처리\n- 접근 요청: 매니저 승인, 시스템 소유자 승인, 보안 검토\n- 정책 변경: 초안, 이해관계자 승인, 컴플라이언스 검토, 게시\n\n요청 유형이 다르더라도 요구는 동일합니다: 누가 온라인인지에 의존하지 않는 일관된 의사결정.\n\n### 엔터프라이즈가 승인 체인에 바라는 것\n\n잘 설계된 승인 워크플로는 단순한 "더 많은 통제"가 아닙니다. 네 가지 실무 목표의 균형을 이루어야 합니다:\n\n- 속도: 불필요한 왕복을 줄이고 대기 시간을 제거\n- 통제: 적절한 사람이 적절한 것을 승인하도록 보장\n- 가시성: 누구나 상태, 다음 단계, 장애 요소를 확인할 수 있음\n- 감사 준비 기록: 누가, 무엇을, 언제, 결정과 그 근거까지의 완전한 감사 로그\n\n### 피해야 할 일반적인 함정\n\n승인 체인이 실패하는 이유는 기술적 문제보다는 프로세스의 불명확성에서 오는 경우가 많습니다. 다음 문제를 주의하세요:\n\n- 소유권 불명확: 누가 승인자인지 몰라 요청이 멈춤\n- 감사 이력 누락: 결정이 채팅이나 이메일에서 일어나 추후 증명 불가\n- 너무 많은 수동 단계: "참고" 검토가 필수 승인으로 바뀌어 속도가 느려짐\n\n이 가이드의 나머지 부분은 승인들이 비즈니스에 대해 유연하고, 시스템에 대해 예측 가능하며, 필요 시 감사 가능하도록 앱을 구축하는 방법에 초점을 맞춥니다.\n\n## 엔터프라이즈 승인 요구사항 체크리스트\n\n화면을 설계하거나 워크플로 엔진을 선택하기 전에 요구사항을 명확한 언어로 정리하세요. 엔터프라이즈 승인 체인은 여러 팀에 걸쳐 영향을 미치므로 작은 누락(예: 위임 누락)이 곧 운영상의 우회로로 이어집니다.\n\n### 초기에 참여시켜야 할 이해관계자\n\n시스템을 사용할 또는 검사할 사람들을 먼저 지명하세요:\n\n- 요청자 (직원, 계약자, 벤더)\n- 승인자 (매니저, 재무, 법무, IT, 보안)\n- 관리자 (템플릿, 라우팅 규칙, 접근을 관리하는 운영/지원)\n- 감사/컴플라이언스 (내부 감사, 외부 규제기관)\n\n실무 팁: 각 그룹에서 최소 한 명씩 참여시켜 "일반적인 요청"과 "최악의 요청"(에스컬레이션, 재할당, 정책 예외)에 대해 45분 워크스루를 진행하세요.\n\n### 필수 워크플로 기능\n\n각 항목을 테스트 가능한 문장으로 작성하세요(각 항목이 작동함을 증명할 수 있어야 함):\n\n- 첨부 파일과 구조화된 필드로 요청 제출\n- 단계별로 승인/거부, 댓글, 결정 기록\n- 임시 위임(휴가) 및 영구 재할당(조직 변경) 지원\n- 병렬 승인(예: Finance와 Legal) 및 순차적 단계 지원\n- 누가 무엇을 볼 수 있는지 강제(요청자 가시성 vs 승인자 전용 메모)\n\n좋은 UX 예시는 나중에 /blog/approver-inbox-patterns에서 요구사항을 매핑하면서 참조할 수 있습니다.\n\n### 비기능적 요구사항(엔터프라이즈급 요건)\n\n요구는 목표로 정의하세요, 소망이 아니라:\n\n- 가동시간 및 RTO/RPO (얼마나 오래 중단이 허용되는가, 데이터 손실 허용 범위)\n- 성능 (예: 1만 개의 보류 항목에 대해 인박스 로딩 2초 이내)\n- 데이터 보존 (요청, 코멘트, 첨부파일을 얼마나 보관할지)\n- 지원 모델 (누가 온콜인지, 근무 시간, 사고에 대한 SLA)\n\n### 제약 및 성공 지표\n\n규제 데이터 종류, 지역별 저장 규칙, 원격 근무(모바일 승인, 시간대)를 제약사항으로 캡처하세요.\n\n마지막으로 성공 지표에 합의하세요: 승인 소요 시간, 연체 비율(%), 재작업률(정보 누락으로 인해 요청이 되돌려지는 빈도). 이 지표들이 우선순위를 정하고 롤아웃을 정당화하는 데 도움을 줍니다.\n\n## 데이터 모델: 요청, 단계, 결정, 템플릿\n\n명확한 데이터 모델은 "미스터리 승인"을 방지합니다—누가 무엇을 언제 어떤 규칙 하에 승인했는지를 설명할 수 있어야 합니다. 비즈니스 오브젝트(요청)와 프로세스 정의(템플릿)를 분리하는 것부터 시작하세요.\n\n### 핵심 엔티티\n\nRequest는 요청자가 생성하는 레코드입니다. 요청자 신원, 비즈니스 필드(금액, 부서, 벤더, 날짜)와 보조 자료 링크를 포함합니다.\n\nStep은 체인의 한 단계를 나타냅니다. 스텝은 제출 시 템플릿에서 생성되어 각 Request가 변경 불가능한(immutable) 시퀀스를 갖도록 합니다.\n\nApprover는 일반적으로 Step에 연결된 사용자 참조(또는 그룹 참조)입니다. 동적 라우팅을 지원하면, 해석된 승인자와 그들을 산출한 규칙을 모두 저장하여 추적 가능성을 유지하세요.\n\nDecision은 이벤트 로그입니다: 승인/거부/반환, 행위자, 타임스탬프, 선택적 메타데이터(예: delegated-by). 변경을 감사할 수 있도록 append-only으로 모델링하세요.\n\nAttachment는 오브젝트 스토리지의 파일과 메타데이터(파일명, 크기, 컨텐츠 타입, 체크섬, 업로더)를 저장합니다.\n\n### 리포팅을 쉽게 하는 상태들\n\n보고를 간단하게 하기 위해 일관된 소수의 Request 상태를 사용하세요:\n\n- Draft: 편집 가능, 라우팅되지 않음\n- Submitted: 라우팅 규칙에 고정, 스텝 생성됨\n- In Review: 적어도 하나의 보류 스텝 존재\n- Approved: 모든 필요 스텝 만족\n- Rejected: 거부로 요청 종료\n- Canceled: 요청자/관리자가 철회함\n\n### 초기에 필요한 스텝 유형\n\n일반적인 스텝 의미론을 지원하세요:\n\n- 단일 승인자: 한 사람이 결정해야 함\n- 그룹: 회원 중 누구나 결정 가능\n- 정족수(Quorum): M명 중 N명 승인 필요\n- 조건부: 조건이 참일 때만 포함(예: 금액 > $10k)\n\n### 놀람 없는 템플릿 버전 관리\n\n워크플로 템플릿은 버전 관리 대상입니다. 템플릿이 변경되면 새로운 요청은 최신 버전을 사용하되, 진행 중인 요청은 생성 당시의 버전을 유지합니다.\n\n각 Request에 template_id와 template_version을 저장하고, 제출 시 코스트센터 등 중요한 라우팅 입력을 스냅샷으로 남기세요.\n\n### 코멘트와 파일\n\n코멘트는 Request(선택적으로 Step/Decision)에 연결된 별도 테이블로 모델링하여 가시성(요청자 전용, 승인자 전용, 관리자 등)을 제어할 수 있게 하세요.\n\n파일의 경우: 크기 제한(예: 25–100MB) 적용, 업로드 스캔(비동기 격리 + 해제), DB에는 참조만 저장하여 워크플로 핵심 데이터는 빠르게 유지하고 스토리지를 확장 가능하게 만드세요.\n\n## 유연한 승인 라우팅 규칙 설계\n\n승인 라우팅 규칙은 "누가 어떤 것을 승인해야 하고 어떤 순서인지"를 결정합니다. 엔터프라이즈 승인 워크플로의 핵심은 엄격한 정책과 현실 세계의 예외를 균형 있게 처리하는 것입니다—모든 요청이 맞춤형 워크플로가 되지 않도록 하는 것이 목표입니다.\n\n### 명확한 "신호"부터 시작하세요\n\n대부분의 라우팅은 요청의 몇 가지 필드에서 도출될 수 있습니다. 일반적 예시는:\n\n- 금액 임계치(예: $10k 초과면 Finance 추가)\n- 부서 또는 코스트센터(코스트센터 소유자로 라우팅)\n- 위치(현지 법인 또는 지역 컴플라이언스)\n- 위험 수준(고위험 벤더는 InfoSec/Legal 추가)\n\n이것들을 하드코딩 논리가 아닌 구성 가능한 규칙으로 취급하면 관리자가 배포 없이 정책을 업데이트할 수 있습니다.\n\n### 동적 승인자 지원\n\n정적 목록은 빠르게 무너집니다. 대신 디렉터리와 조직 데이터로 런타임에 승인자를 해석하세요:\n\n- 매니저 체인(직속 매니저, 임계치 이상 시 스킵 레벨)\n- 재무/ERP의 코스트센터 소유자\n- 프로젝트 시스템의 프로젝트 리드\n\n해결 과정을 명시적으로 저장하세요: 최종 이름만 저장하지 말고 "manager_of: user_123" 같은 방식으로 누가 어떻게 선택되었는지도 함께 보존하세요.\n\n### 병렬 스텝과 병합 로직\n\n여러 승인이 동시에 필요할 수 있습니다. 병렬 스텝을 다음과 같이 모델링하고 병합 동작을 명확히 하세요:\n\n- 모두 승인 필요(예: Finance and Legal)\n- 누구든 1명만 승인(예: 여러 예산 담당자 중 1명)

\n거부가 발생하면 즉시 중단할지, "수정 후 재제출"을 허용할지 결정하세요.\n\n### 에스컬레이션과 예외 처리\n\n에스컬레이션 규칙을 1급 정책으로 정의하세요:\n\n- X시간/일 후 리마인더\n- 연체 처리(매니저로 에스컬레이션, 큐 재할당)\n- SLA 미준수 시 자동 에스컬레이션\n\n예외는 미리 계획하세요: 부재(OOO), 위임, 대체 승인자, 그리고 모든 재라우팅에 대해 감사 가능한 이유를 기록하세요.\n\n## 워크플로 엔진: 스텝을 신뢰성 있게 오케스트레이션하기\n\n다단계 승인 앱의 성공 여부는 한 가지에 달려 있습니다: 사용자들이 버튼을 두 번 클릭하거나 통합이 지연되거나 승인자가 부재 중일 때도 워크플로 엔진이 요청을 예측 가능하게 진행시킬 수 있느냐.\n\n### 직접 구축 vs 라이브러리 채택\n\n승인 체인이 대부분 선형(스텝1 → 스텝2 → 스텝3)이고 조건 분기만 일부라면 자체 엔진이 빠른 경로일 수 있습니다. 데이터 모델을 제어하고 감사 이벤트를 맞춤화하며 불필요한 개념을 도입하지 않을 수 있습니다.\n\n반면 병렬 승인, 동적 스텝 삽입, 보상 행동, 장기 타이머, 버전 정의 등 복잡한 라우팅이 예상된다면 워크플로 라이브러리나 서비스를 채택하는 것이 위험을 줄여줄 수 있습니다. 단점은 운영 복잡성과 당신의 개념을 라이브러리의 프리미티브에 매핑해야 한다는 점입니다.\n\n"빠르게 내부 도구를 출시해야 한다" 단계라면, Koder.ai 같은 바이브-코딩(vibe-coding) 플랫폼이 엔드투엔드 흐름(요청 폼 → 승인자 인박스 → 감사 타임라인)을 프로토타이핑하고 라우팅 규칙을 기획 모드에서 반복하는 데 유용할 수 있습니다. 또한 실제로 내보낼 수 있는 React + Go + PostgreSQL 코드베이스를 생성할 수 있습니다.