엔터프라이즈 다단계 승인 웹앱 구축
라우팅 규칙, 역할, 알림, 감사 로그를 갖춘 엔터프라이즈용 다단계 승인 웹앱을 설계하고 구축하며 롤아웃하는 방법을 배우세요.
다단계 승인 체인이란(그리고 왜 중요한가)
다단계 승인 체인은 요청이 다음 단계로 진행되기 전에 거쳐야 하는 일련의 결정(스텝)을 구조화한 것입니다. 임시 이메일이나 "괜찮아 보인다"라는 메시지에 의존하는 대신, 승인 체인은 결정을 반복 가능한 워크플로로 바꾸어 책임자, 타임스탬프, 결과를 명확히 기록합니다.
기본적으로, 앱은 각 요청에 대해 세 가지 질문에 답합니다:
- 누가 승인해야 하는가?
- 어떤 순서(또는 어떤 단계)로 진행되는가?
- 각 결정 이후에 무슨 일이 발생하는가?
순차적 vs 병렬 스텝
승인 체인은 보통 두 가지 패턴을 결합합니다:
- 순차적 승인: B 단계는 A가 승인될 때까지 시작할 수 없습니다. 예: 구매 요청은 팀 리드 → 재무 → 조달 순으로 필요할 수 있습니다.
- 병렬 승인: 여러 승인자가 동시에 검토할 수 있습니다. 예: 정책 변경은 Legal과 Security의 병렬 승인 후에 진행될 수 있습니다.
좋은 시스템은 두 가지를 모두 지원하고, "이 승인자 중 누군가 하나면 됨" vs. "모두 승인해야 함" 같은 변형도 제공합니다.
전형적인 엔터프라이즈 사용 사례(일반적 예시)
다음과 같은 곳에서 다단계 승인 요구가 나타납니다:
- 구매(구매/조달): 벤더 선정, 예산 확인, 조달 서명
- 경비: 매니저 승인, 재무 검증, 고액의 예외 처리
- 접근 요청: 매니저 승인, 시스템 소유자 승인, 보안 검토
- 정책 변경: 초안, 이해관계자 승인, 컴플라이언스 검토, 게시
요청 유형이 다르더라도 요구는 동일합니다: 누가 온라인인지에 의존하지 않는 일관된 의사결정.
엔터프라이즈가 승인 체인에 바라는 것
잘 설계된 승인 워크플로는 단순한 "더 많은 통제"가 아닙니다. 네 가지 실무 목표의 균형을 이루어야 합니다:
- 속도: 불필요한 왕복을 줄이고 대기 시간을 제거
- 통제: 적절한 사람이 적절한 것을 승인하도록 보장
- 가시성: 누구나 상태, 다음 단계, 장애 요소를 확인할 수 있음
- 감사 준비 기록: 누가, 무엇을, 언제, 결정과 그 근거까지의 완전한 감사 로그
피해야 할 일반적인 함정
승인 체인이 실패하는 이유는 기술적 문제보다는 프로세스의 불명확성에서 오는 경우가 많습니다. 다음 문제를 주의하세요:
- 소유권 불명확: 누가 승인자인지 몰라 요청이 멈춤
- 감사 이력 누락: 결정이 채팅이나 이메일에서 일어나 추후 증명 불가
- 너무 많은 수동 단계: "참고" 검토가 필수 승인으로 바뀌어 속도가 느려짐
이 가이드의 나머지 부분은 승인들이 비즈니스에 대해 유연하고, 시스템에 대해 예측 가능하며, 필요 시 감사 가능하도록 앱을 구축하는 방법에 초점을 맞춥니다.
엔터프라이즈 승인 요구사항 체크리스트
화면을 설계하거나 워크플로 엔진을 선택하기 전에 요구사항을 명확한 언어로 정리하세요. 엔터프라이즈 승인 체인은 여러 팀에 걸쳐 영향을 미치므로 작은 누락(예: 위임 누락)이 곧 운영상의 우회로로 이어집니다.
초기에 참여시켜야 할 이해관계자
시스템을 사용할 또는 검사할 사람들을 먼저 지명하세요:
- 요청자 (직원, 계약자, 벤더)
- 승인자 (매니저, 재무, 법무, IT, 보안)
- 관리자 (템플릿, 라우팅 규칙, 접근을 관리하는 운영/지원)
- 감사/컴플라이언스 (내부 감사, 외부 규제기관)
실무 팁: 각 그룹에서 최소 한 명씩 참여시켜 "일반적인 요청"과 "최악의 요청"(에스컬레이션, 재할당, 정책 예외)에 대해 45분 워크스루를 진행하세요.
필수 워크플로 기능
각 항목을 테스트 가능한 문장으로 작성하세요(각 항목이 작동함을 증명할 수 있어야 함):
- 첨부 파일과 구조화된 필드로 요청 제출
- 단계별로 승인/거부, 댓글, 결정 기록
- 임시 위임(휴가) 및 영구 재할당(조직 변경) 지원
- 병렬 승인(예: Finance와 Legal) 및 순차적 단계 지원
- 누가 무엇을 볼 수 있는지 강제(요청자 가시성 vs 승인자 전용 메모)
좋은 UX 예시는 나중에 /blog/approver-inbox-patterns에서 요구사항을 매핑하면서 참조할 수 있습니다.
비기능적 요구사항(엔터프라이즈급 요건)
요구는 목표로 정의하세요, 소망이 아니라:
- 가동시간 및 RTO/RPO (얼마나 오래 중단이 허용되는가, 데이터 손실 허용 범위)
- 성능 (예: 1만 개의 보류 항목에 대해 인박스 로딩 2초 이내)
- 데이터 보존 (요청, 코멘트, 첨부파일을 얼마나 보관할지)
- 지원 모델 (누가 온콜인지, 근무 시간, 사고에 대한 SLA)
제약 및 성공 지표
규제 데이터 종류, 지역별 저장 규칙, 원격 근무(모바일 승인, 시간대)를 제약사항으로 캡처하세요.
마지막으로 성공 지표에 합의하세요: 승인 소요 시간, 연체 비율(%), 재작업률(정보 누락으로 인해 요청이 되돌려지는 빈도). 이 지표들이 우선순위를 정하고 롤아웃을 정당화하는 데 도움을 줍니다.
데이터 모델: 요청, 단계, 결정, 템플릿
명확한 데이터 모델은 "미스터리 승인"을 방지합니다—누가 무엇을 언제 어떤 규칙 하에 승인했는지를 설명할 수 있어야 합니다. 비즈니스 오브젝트(요청)와 프로세스 정의(템플릿)를 분리하는 것부터 시작하세요.
핵심 엔티티
Request는 요청자가 생성하는 레코드입니다. 요청자 신원, 비즈니스 필드(금액, 부서, 벤더, 날짜)와 보조 자료 링크를 포함합니다.
Step은 체인의 한 단계를 나타냅니다. 스텝은 제출 시 템플릿에서 생성되어 각 Request가 변경 불가능한(immutable) 시퀀스를 갖도록 합니다.
Approver는 일반적으로 Step에 연결된 사용자 참조(또는 그룹 참조)입니다. 동적 라우팅을 지원하면, 해석된 승인자와 그들을 산출한 규칙을 모두 저장하여 추적 가능성을 유지하세요.
Decision은 이벤트 로그입니다: 승인/거부/반환, 행위자, 타임스탬프, 선택적 메타데이터(예: delegated-by). 변경을 감사할 수 있도록 append-only으로 모델링하세요.
Attachment는 오브젝트 스토리지의 파일과 메타데이터(파일명, 크기, 컨텐츠 타입, 체크섬, 업로더)를 저장합니다.
리포팅을 쉽게 하는 상태들
보고를 간단하게 하기 위해 일관된 소수의 Request 상태를 사용하세요:
- Draft: 편집 가능, 라우팅되지 않음
- Submitted: 라우팅 규칙에 고정, 스텝 생성됨
- In Review: 적어도 하나의 보류 스텝 존재
- Approved: 모든 필요 스텝 만족
- Rejected: 거부로 요청 종료
- Canceled: 요청자/관리자가 철회함
초기에 필요한 스텝 유형
일반적인 스텝 의미론을 지원하세요:
- 단일 승인자: 한 사람이 결정해야 함
- 그룹: 회원 중 누구나 결정 가능
- 정족수(Quorum): M명 중 N명 승인 필요
- 조건부: 조건이 참일 때만 포함(예: 금액 > $10k)
놀람 없는 템플릿 버전 관리
워크플로 템플릿은 버전 관리 대상입니다. 템플릿이 변경되면 새로운 요청은 최신 버전을 사용하되, 진행 중인 요청은 생성 당시의 버전을 유지합니다.
각 Request에 template_id와 template_version을 저장하고, 제출 시 코스트센터 등 중요한 라우팅 입력을 스냅샷으로 남기세요.
코멘트와 파일
코멘트는 Request(선택적으로 Step/Decision)에 연결된 별도 테이블로 모델링하여 가시성(요청자 전용, 승인자 전용, 관리자 등)을 제어할 수 있게 하세요.
파일의 경우: 크기 제한(예: 25–100MB) 적용, 업로드 스캔(비동기 격리 + 해제), DB에는 참조만 저장하여 워크플로 핵심 데이터는 빠르게 유지하고 스토리지를 확장 가능하게 만드세요.
유연한 승인 라우팅 규칙 설계
승인 라우팅 규칙은 "누가 어떤 것을 승인해야 하고 어떤 순서인지"를 결정합니다. 엔터프라이즈 승인 워크플로의 핵심은 엄격한 정책과 현실 세계의 예외를 균형 있게 처리하는 것입니다—모든 요청이 맞춤형 워크플로가 되지 않도록 하는 것이 목표입니다.
명확한 "신호"부터 시작하세요
대부분의 라우팅은 요청의 몇 가지 필드에서 도출될 수 있습니다. 일반적 예시는:
- 금액 임계치(예: $10k 초과면 Finance 추가)
- 부서 또는 코스트센터(코스트센터 소유자로 라우팅)
- 위치(현지 법인 또는 지역 컴플라이언스)
- 위험 수준(고위험 벤더는 InfoSec/Legal 추가)
이것들을 하드코딩 논리가 아닌 구성 가능한 규칙으로 취급하면 관리자가 배포 없이 정책을 업데이트할 수 있습니다.
동적 승인자 지원
정적 목록은 빠르게 무너집니다. 대신 디렉터리와 조직 데이터로 런타임에 승인자를 해석하세요:
- 매니저 체인(직속 매니저, 임계치 이상 시 스킵 레벨)
- 재무/ERP의 코스트센터 소유자
- 프로젝트 시스템의 프로젝트 리드
해결 과정을 명시적으로 저장하세요: 최종 이름만 저장하지 말고 "manager_of: user_123" 같은 방식으로 누가 어떻게 선택되었는지도 함께 보존하세요.
병렬 스텝과 병합 로직
여러 승인이 동시에 필요할 수 있습니다. 병렬 스텝을 다음과 같이 모델링하고 병합 동작을 명확히 하세요:
- 모두 승인 필요(예: Finance and Legal)
- 누구든 1명만 승인(예: 여러 예산 담당자 중 1명)
거부가 발생하면 즉시 중단할지, "수정 후 재제출"을 허용할지 결정하세요.
에스컬레이션과 예외 처리
에스컬레이션 규칙을 1급 정책으로 정의하세요:
- X시간/일 후 리마인더
- 연체 처리(매니저로 에스컬레이션, 큐 재할당)
- SLA 미준수 시 자동 에스컬레이션
예외는 미리 계획하세요: 부재(OOO), 위임, 대체 승인자, 그리고 모든 재라우팅에 대해 감사 가능한 이유를 기록하세요.
워크플로 엔진: 스텝을 신뢰성 있게 오케스트레이션하기
다단계 승인 앱의 성공 여부는 한 가지에 달려 있습니다: 사용자들이 버튼을 두 번 클릭하거나 통합이 지연되거나 승인자가 부재 중일 때도 워크플로 엔진이 요청을 예측 가능하게 진행시킬 수 있느냐.
직접 구축 vs 라이브러리 채택
승인 체인이 대부분 선형(스텝1 → 스텝2 → 스텝3)이고 조건 분기만 일부라면 자체 엔진이 빠른 경로일 수 있습니다. 데이터 모델을 제어하고 감사 이벤트를 맞춤화하며 불필요한 개념을 도입하지 않을 수 있습니다.
반면 병렬 승인, 동적 스텝 삽입, 보상 행동, 장기 타이머, 버전 정의 등 복잡한 라우팅이 예상된다면 워크플로 라이브러리나 서비스를 채택하는 것이 위험을 줄여줄 수 있습니다. 단점은 운영 복잡성과 당신의 개념을 라이브러리의 프리미티브에 매핑해야 한다는 점입니다.
"빠르게 내부 도구를 출시해야 한다" 단계라면, Koder.ai 같은 바이브-코딩(vibe-coding) 플랫폼이 엔드투엔드 흐름(요청 폼 → 승인자 인박스 → 감사 타임라인)을 프로토타이핑하고 라우팅 규칙을 기획 모드에서 반복하는 데 유용할 수 있습니다. 또한 실제로 내보낼 수 있는 React + Go + PostgreSQL 코드베이스를 생성할 수 있습니다.
자주 묻는 질문
다단계 승인 체인이란 무엇이며 왜 기업에서 사용하는가?
다단계 승인 체인은 요청이 완료되기 전에 하나 이상의 승인 단계를 거쳐야 하는 정의된 워크플로입니다.
중요한 이유는 반복 가능성(매번 동일한 규칙 적용), 명확한 책임(누가 무엇을 승인했는지), 그리고 감사를 위한 추적성(누가, 언제, 왜 결정했는지)을 제공하기 때문입니다.
승인은 언제 순차적으로 해야 하고 언제 병렬로 해야 하나?
순서가 중요한 경우에는 순차적 승인을 사용하세요(예: 매니저 승인이 있어야 Finance가 검토할 수 있음).
여러 팀이 동시에 검토할 수 있는 경우에는 병렬 승인을 사용하세요(예: Legal과 Security가 동시에 검토). 병합 규칙은 다음과 같이 정의하세요:
- 모두 승인 필요
- 누구든 1명만 승인
- N-of-M(정족수)
승인 워크플로를 만들기 전에 어떤 요구사항을 수집해야 하나?
최소한 다음 항목에 대해 합의하세요:
- 이해관계자(요청자, 승인자, 관리자, 감사자)가 누구인지
- 각 단계에서 가능한 행동(승인/거부/수정요청, 코멘트)
- 위임 및 재할당 동작
- 가시성 규칙(누가 어떤 필드와 메모를 볼 수 있는지)
- 비기능적 목표(가용성, 성능, 보존 기간)
빠르게 검증하는 방법은 각 그룹 대표자들과 함께 "일반적인" 요청과 "최악의" 요청을 워크스루하는 것입니다.
기업 승인에서 핵심 데이터 모델 엔티티는 무엇인가?
실무적 핵심 모델은 다음을 포함합니다:
- Request (비즈니스 오브젝트)
- Template (버전 관리되는 프로세스 정의)
- Step (요청 생성 시 만들어지는 단계)
- Approver (사용자/그룹 + 어떻게 결정되었는지)
- Decision (증분 추가형 이벤트 로그)
- Attachment 및 Comment (제어와 성능을 위해 별도 엔티티)
감사를 위해 결정은 append-only 방식으로 보관하는 것이 중요합니다.
놀라움을 피하기 위해 워크플로 템플릿 버전 관리는 어떻게 해야 하나?
템플릿은 정책 변경으로 역사가 바뀌지 않도록 버전 관리해야 합니다:
- 각 요청에
template_id와template_version을 저장하세요 - 제출 시 단계 리스트를 생성(실질적으로 고정)하세요
- 템플릿 편집은 새로운 요청에만 적용하세요
- 관리자 콘솔에서 버전 이력과 롤백 경로를 제공하세요
이렇게 하면 진행 중인 요청이 갑자기 다른 경로로 흐르는 일을 방지할 수 있습니다.
승인자를 하드코딩하지 않고 유연한 승인 라우팅 규칙을 어떻게 설계하나?
라우팅 규칙을 기반 규칙으로 만들고, 신호(신호값) 몇 가지로 결정하세요. 예:
- 금액 임계치
- 부서/코스트센터
- 지역/법인
- 위험 수준
결정된 승인자를 시스템(디렉토리, HRIS, ERP)에서 동적으로 해석하고, 다음 두 가지를 모두 저장하세요:
- 해석된 승인자들
- 그들을 산출한 규칙(추적용)
하드코딩된 목록은 쉽게 오래되므로 피하세요.
승인에 적합한 워크플로 엔진을 어떻게 신뢰성 있게 설계하나?
요청 수명 주기를 명시적 상태 머신으로 다루세요(예: DRAFT → SUBMITTED → IN_REVIEW → APPROVED/REJECTED/CANCELED).
실환경에서 신뢰성을 확보하려면:
- 전환을 서버사이드에서 검증(권한 + 유효성)
- 결정 액션을 멱등(idempotent) 하게 처리(더블클릭 안전)
- 알림/에스컬레이션은 백그라운드 잡으로 실행
- 워크플로 로직을 UI와 통합 코드에서 분리
기업 승인에서 필수적인 보안 및 감사 기능은 무엇인가?
레이어드 통제를 사용하세요:
- 인증: 기업 SSO(SAML/OIDC), 필요 시 MFA
- 권한: RBAC와 요청별 권한 검사(팀/코스트센터/지역 기준 범위)
- 데이터 보호: TLS, 저장 시 암호화, 시크릿 매니저
- 감사 추적: 제출/조회/결정/위임 등 append-only 이벤트, 타임스탬프와 행위자 식별 포함
또한 승인 액션 엔드포인트 보호(레이트 제한, CSRF 방어, 이메일 링크용 일회성 토큰)를 구현하세요.
요청자 플로우와 승인자 인박스는 어떻게 설계해야 하나?
결정 시간 단축과 맥락 유지에 집중하세요:
- 스마트 기본값과 인라인 검증이 있는 요청 폼
- 우선순위/SLA를 강조하고 안전한 필터링을 제공하는 승인자 인박스(자세한 패턴은 /blog/approver-inbox-patterns 참고)
- 요약, 첨부파일, 활동 타임라인을 갖춘 요청 상세 페이지
- 거부 시 이유를 요구하고 이전 단계 이후 변경된 것을 보여주세요
모바일은 접을 수 있는 섹션, 고정 요약 등으로 빠른 승인에 필요한 맥락을 유지하세요. 접근성도 반드시 만족시켜야 합니다.
스팸을 피하면서 알림, 리마인더, 에스컬레이션을 어떻게 구현하나?
알림을 단순 메시지가 아닌 작업 전달 시스템으로 구축하세요:
- 이메일 + 인앱을 기본으로, 선택적으로 채팅 툴에 미러링
- 배칭/다이제스트로 소음 줄이기
- 여전히 보류 중인 항목에만 리마인드; 시간대와 조용한 시간 존중
- 에스컬레이션은 명확한 소유자로(매니저, 백업 승인자, 운영 큐)
모든 알림은 실행 가능해야 합니다: 무엇이 변경되었는지, 어떤 조치가 필요한지(언제까지), 그리고 /requests/123?tab=decision 같은 딥링크 포함.
기업 시스템 통합과 API는 어떻게 설계해야 하나?
핵심 시스템 연결을 우선으로 계획하세요:
- HR 디렉터리/아이덴티티 프로바이더
- ERP/재무 시스템
- 티켓팅 시스템
- 문서 저장소
API 및 웹후크 설계:
- 안정적인 REST API(또는 GraphQL)로 핵심 동작 제공
- 아웃바운드용 웹후크(예:
request.submitted,request.step_approved,request.completed)에 이벤트 ID, 타임스탬프, 재시도와 서명 검증 포함
들어오는 통합은 서비스 간 인증을 지원하고 템플릿으로 요청을 생성할 수 있어야 합니다. 식별자는 통상 직원 ID를 기준으로 삼고 이메일은 별칭으로 매핑하세요.
운영을 위한 관리자 콘솔과 리포팅은 어떻게 구성해야 하나?
운영 관점에서 템플릿, 그룹, 정책, SLA를 관리하세요:
- 워크플로 템플릿은 소유자와 설명 포함
- 승인자 그룹은 개인이 아닌 역할/지역 기준으로 관리
- 정책과 SLA(예: "$50k 이상이면 CFO 승인 필요")를 설정
안전한 편집 워크플로(초안/게시, 버전 히스토리, 롤백)와 권한 분리(관리자, 슈퍼 관리자, 감사자)를 제공하세요. 대시보드는 병목, 연체 큐, 상위 요청 유형과 거부 사유를 보여주고, CSV 및 감사 패키지 내보내기를 지원해야 합니다.
관리 링크 예: /admin/templates, /admin/audit-log
테스트, 모니터링, 장애 처리는 어떻게 해야 하나?
신뢰성을 제품 기능으로 다루세요:
테스트 전략:
- 라우팅 규칙에 대한 빠른 단위 테스트(테이블 기반)
- 전체 워크플로 엔진을 검증하는 통합 테스트
- 권한 검사 테스트 포함
시뮬레이션해야 할 엣지 케이스:
- 승인자가 요청 중간에 퇴사(단계 재할당)
- 충돌하는 결정(더블클릭, 병렬 단계, 에스컬레이션 이후의 늦은 응답)
- 템플릿 변경 시 진행 중인 요청이 원래 버전을 계속 사용함
운영 가시성: 전환 로그에 상관관계 ID, 스택 트레이스, 스테퍼 지연 메트릭 등을 포함하고, 재시도 증가나 dead-letter 큐 성장 시 경고하세요.
배포, 롤아웃, 변경 관리는 어떻게 진행해야 하나?
점진적이고 측정 가능한 출시를 계획하세요:
- 파일럿 팀으로 시작(매니저, 재무, 법무, 임원 포함)
- 템플릿 수를 제한하고 복잡도도 단계적으로 확장
- 각 단계의 성공 기준(완료 비율, 중앙값 의사결정 시간, 에스컬레이션 수 등)을 정의
데이터 마이그레이션:
- 이메일/스프레드시트 기반이면 진행 중인 항목을 가능한 한 가져오거나 이전 시스템을 읽기 전용으로 유지
- 템플릿과 그룹, 정책부터 마이그레이션
변경관리:
- 역할별 짧은 교육과 가이드 제공
- 초기 몇 주간 오피스 아워와 전용 지원 채널 운영
- 템플릿 변경에 대한 거버넌스(누가 생성/수정/승인하는지) 수립
지속적 개선 루프를 만들어 정기적으로 템플릿과 리마인더, 에스컬레이션을 튜닝하세요.