API 키 회전 UX: 스코프, 셀프서비스 키, 그리고 로그

실제 제품에서 API 키가 문제가 되는 이유

API 키는 처음엔 단순합니다: 키 하나, 통합 하나, 끝. 문제는 시간이 지나 같은 키가 공유 스프레드시트, Slack 메시지, 혹은 더 이상 소유자가 없는 스크립트에 하드코딩될 때 생깁니다. 키가 여기저기 복사되면 누가 왜 사용하는지 같은 기본적인 질문에 답할 수 있는 능력을 잃습니다.

절대 바뀌지 않는 키도 흔한 함정입니다. 키가 유출되면 조용히 몇 달간 악용되거나, 예상치 못한 비용, 또는 데이터 유출로 이어질 수 있습니다. 아무런 “나쁜” 일이 없어도 오래된 키는 너무 많은 곳에 남아 있어 자신 있게 제거하기 어렵다는 점에서 위험을 만듭니다.

좋은 키 관리는 단지 보안만의 문제가 아닙니다. 사고를 줄이고 지원 업무도 줄여줍니다. 고객이 자신의 키를 보고, 제한하고, 안전하게 교체할 수 있으면 팀은 수동 재설정과 추측에 의존하지 않아도 됩니다.

"셀프 서비스"는 역할에 따라 달라야 합니다. 관리자들은 보통 워크스페이스 전체를 제어해야 하고, 일반 사용자는 자신이 소유한 항목이나 관리자가 위임한 항목만 관리해야 합니다. 목표는 명확한 소유권과 경계이며 권한의 미로를 만들지 않는 것입니다.

보안과 사용성은 함께 작동해야 합니다. UX가 불편하면 사람들은 우회하여 한 개의 "마스터 키"를 어디에나 재사용할 것입니다. 실용적인 시스템은 가장 안전한 경로를 가장 쉬운 경로로 만듭니다:

• 앱이나 통합별로 키를 생성하세요, 회사 하나당 하나가 아닙니다.
• 각 키가 할 수 있는 일을(그리고 어느 곳에서 사용되는지) 제한하세요.
• 누가 만들었는지와 마지막 사용 시간을 보여주세요.
• 회전을 일상적이고 부담 없는 동작으로 만드세요.

예시: 파트너가 "API 접근"을 요청합니다. 유일한 옵션이 전체 접근 키라면 의도보다 많은 권한을 넘겨주게 됩니다. 셀프 서비스 흐름은 파트너의 작업에 맞는 좁은 키를 발급하도록 해야 합니다.

기본 개념: 키, 스코프, 소유자, 환경

키 관리는 관련 인물을 명확히 하고 책임을 분명히 하면 더 쉬워집니다. 대부분의 제품은 몇 가지 반복되는 역할을 갖습니다: 계정 소유자(규칙 설정 및 결제), 관리자(워크스페이스 전반 접근 관리), 개발자(코드에서 키 사용 및 회전), 지원(“왜 실패했나요?”에 답변), 감사자(접근이 통제되고 추적 가능한지 검증).

키는 단순한 비밀 문자열이 아닙니다. 컨텍스트가 있는 권한 있는 자격 증명입니다. 키를 공유 비밀번호처럼 취급하면 회전, 사고 대응, 기본 디버깅에서 고생하게 됩니다.

초기에 몇 가지 핵심 객체를 정의하세요:

• 키: 비밀 값과 메타데이터(생성 후 원문 비밀은 저장하지 마세요).
• 스코프: 허용된 동작의 명명된 집합(예: 주문 읽기, 송장 쓰기 등).
• 소유자: 키에 책임 있는 특정 사용자나 서비스 계정.
• 환경: 키가 작동하는 곳(개발, 스테이징, 프로덕션).
• 만료: 언제 작동이 중지되는지 또는 언제 회전해야 하는지.

실패 양상은 예측 가능합니다: 키가 저장소나 채팅에 유출되고, 스코프가 "작동하게 하려고" 너무 넓어지며, 어떤 키가 요청을 만들었는지 아무도 모르는 상황입니다. 마지막 문제는 지원 부담을 늘리고 보안 작업을 지연시킵니다.

또한 v1에서 지원하지 않을 항목을 미리 결정하세요. 많은 팀이 조직 전체 공유 키, 만료 없는 "영구" 키, 모든 환경에서 동작하는 키를 피합니다. 그런 옵션을 설계상 불가능하게 만드는 것이 나중에 단속하려고 애쓰는 것보다 쉽습니다.

사람들이 실제로 사용할 최소 권한 스코프 설계

최소 권한은 사용자가 몇 초 안에 올바른 스코프를 선택할 수 있어야만 작동합니다. 보안 전문가가 이해해야 할 수준이라면 사용자들은 "전체 접근"을 선택하고 넘어갑니다.

사람이 설명할 법한 동작 목록으로 시작하세요. "송장 보기"는 명확합니다. billing.read도 괜찮지만 UI가 평이한 언어로 설명해줘야 합니다. 이 점은 회전 시 더 중요합니다. 고객이 대체 키가 이전 키와 일치하는지 확신해야 하니까요.

스코프 집합은 작고 안정적이며 실제 업무 중심으로 그룹화하세요. 예:

• 보고(송장, 고객, 정산 보기)
• 고객 지원(고객 조회, 환불 처리)
• 주문 관리(주문 생성, 상태 업데이트, 취소)
• 웹후크(엔드포인트 생성, 비밀 회전)
• 관리자(사용자 관리, API 키 관리)

작은 토글이 50개나 되지 않게 하세요. 긴 목록이 있다면 보통 스코프가 코드 구조를 그대로 반영하고 있음을 의미합니다. 사람들의 실제 작업 방식에 맞게 만들지 못한 것입니다.

안전한 기본값을 제공하세요. 일반적인 사용 사례에 대해 "권장 번들"을 제안하고 각 번들이 무엇을 하는지 명확히 하세요. 예를 들어 "회계 통합" 번들은 기본적으로 송장과 정산 읽기 전용으로 하고 환불은 끄는 식입니다. 고급 사용자는 여전히 커스터마이즈할 수 있게 합니다.

위험도가 높은 스코프에는 일부러 마찰을 추가하세요. 추가 확인 단계, 관리자 전용 권한, 시간 제한된 권한 상승, 감사 로그에 저장되는 필수 사유 같은 방식이 있습니다.

예시: 파트너가 송장을 자사 시스템과 동기화해야 합니다. 이 경우에는 orders:read와 customers:read 같은 읽기 권한만 주고 "청구 관리" 같은 권한은 주지 마세요. 나중에 환불이 필요하면 그 단일 권한만 요청하도록 하고 승인하면 됩니다.

키 관리 UX: 실수를 막는 화면과 문구

기본 페이지는 한 가지 질문에 빠르게 답해야 합니다: "지금 어떤 키가 존재하며 안전한가?" 간단한 테이블이 보통 가장 잘 작동합니다: 키 이름, 환경, 상태(활성, 만료, 폐기), 마지막 사용 시간, 짧은 스코프 요약. 빈 상태는 가르치되 비난하지 마세요: "아직 키가 없습니다. 특정 앱이나 파트너용으로 필요한 스코프만 가진 키를 생성하세요."처럼요.

키 생성은 무작위 비밀을 생성하는 행위가 아니라 권한을 설정하는 느낌이어야 합니다. 흐름을 짧게 유지하고 평이한 레이블을 쓰며 사람들이 자주 막히는 곳에 작은 도움말을 추가하세요.

견고한 생성 폼에는 보통 다음이 필요합니다:

• 이름(필수): "Payroll dashboard (prod)"처럼 "Key 1"보다 구체적인 이름.
• 환경(필수): 테스트 vs 프로덕션이 명확히 구분되어야 합니다.
• 스코프(필수): 안전한 기본값으로 시작하고 사용자가 추가하도록 합니다.
• 만료(선택이지만 권장): "90일" 같은 쉬운 프리셋.
• 생성자/소유자(자동): 나중에 연락할 사람을 표시.

비밀을 생성할 때는 한 번만 보여주고 이유를 간단히 설명하세요: "보안을 위해 생성 후 원본은 저장하지 않습니다. 지금 복사하세요. 다시 볼 수 없습니다." 복사 한 번을 위한 명확한 동작과 가벼운 확인(예: "이 비밀을 안전한 장소에 저장했습니다")을 제공하세요.

폐기와 회전은 찾기 쉬우면서도 실수로 실행되기 어렵게 만드세요. "관리" 메뉴 뒤에 두고 영향이 명확하게 드러나는 문구를 사용하세요:

• 폐기(Revoked): "즉시 작동을 멈춥니다. 이를 사용하는 앱은 실패합니다."\n- 회전(Rotate): "새 키를 생성하여 안전하게 전환한 다음 이전 키를 폐기합니다."

회전을 지원한다면 안내 다이얼로그가 도움이 됩니다: 이전 키 라벨, 새 키 라벨, 컷오프 시간 전에 호출 시스템을 업데이트하라는 알림을 보여주세요.

지원팀이 항상 묻는 질문에 답하는 사용 로그

문제가 발생하면 지원팀은 보통 같은 질문을 합니다: 어떤 키가 사용되었나, 무엇을 시도했나, 무엇이 변경되었나. 좋은 API 사용 로그는 서버 로그를 뒤적이지 않아도 그 답을 명확히 해줍니다.

유용한 로그 항목은 작지만 구체적이며 사람들이 빠르게 스캔하고 필터링할 수 있는 일관된 필드를 갖습니다:

• 타임스탬프(시간대 포함)
• 키 ID(원문 비밀이 아님)와 키 소유자
• 엔드포인트 또는 액션 이름(가능하면 사람이 이해하기 쉬운 형식)
• 소스 IP와 유저 에이전트(가능한 경우)
• 결과(성공, 스코프에 의해 차단, 인증 실패, 속도 제한, 서버 오류)와 응답 코드

로그를 키 상세 페이지와 연결하세요. 두 가지 작은 지표가 많은 티켓을 예방합니다: **최초 관찰 시각(First seen)**과 마지막 사용(Last used). "한 번도 사용된 적 없음"으로 표시되면 삭제 후보이고, "마지막 사용"이 2년 전이면 다음 회전에서 남기기 어렵습니다.

v1에서는 내보내기(export)보다 필터링이 더 중요합니다. 필터는 간단하고 예측 가능하게 하세요: 시간 범위, 상태(성공 vs 차단 vs 실패), 액션/스코프, 환경.

보존 기간(retention)은 단순한 저장 문제가 아니라 제품 결정입니다. 많은 팀이 UI에선 30~90일을 시작점으로 하고 더 긴 기록은 관리자만 보게 합니다. UI에 이를 명확히 표시해 사용자가 로그가 "없어진" 것으로 오해하지 않도록 하세요.

고객을 끊지 않는 안전한 회전 모델

회전은 예측 가능할 때만 작동합니다. 간단한 정책을 게시해 두 가지 질문에 답하세요: 키를 얼마나 자주 회전해야 하는가(예약 기반)와 어떤 이벤트가 즉시 회전을 강제하는가(이벤트 기반). 예약 회전은 예를 들어 90일마다일 수 있습니다. 이벤트 기반 회전은 "직원이 퇴사함", "키가 티켓에 붙여넣어짐", "비정상적 사용 급증" 등이 될 수 있습니다.

가장 안전한 모델은 겹침(overlap)입니다. 고객이 한 순간에 키를 교체하도록 강요하지 마세요. 새 키를 만들고 이전 키가 여전히 작동하도록 한 뒤 명확한 시간 창 후에 이전 키를 내리세요.

실용적인 흐름:

• 새 키를 생성하고 "활성(Active)"으로 표시합니다.
• 이전 키도 활성 상태로 유지하되 "곧 회전"으로 라벨을 붙입니다.
• 고객이 클라이언트를 업데이트하고 호출이 성공하는지 검증합니다.
• 고객이 "회전 완료"를 클릭하거나 이전 키가 자동으로 만료됩니다.
• 이전 키는 "폐기(Revoked)"되어 다시 활성화할 수 없습니다.

유예 기간은 중요하지만 명확해야 합니다. 리스트 뷰에 만료 날짜를 표시하고(예: 14일, 3일, 24시간 전) 사전에 경고를 보여주세요. "곧 만료" 같은 모호한 문구를 피하고 "이 키는 1월 30일 10:00 UTC에 작동을 멈춥니다."처럼 구체적으로 쓰세요.

속도 제한(rate limits)과 잠금은 정상 동작을 처벌하지 않으면서 계정을 보호해야 합니다. 많은 클라이언트가 네트워크 타임아웃 이후 재시도하므로 실패 몇 번으로 잠그면 오경보가 발생합니다. 규칙은 이해하기 쉽게 유지하세요:

• 키별 및 IP별 속도 제한(계정별만이 아님).
• 401 오류는 타임아웃과 다르게 처리.
• 먼저 경고하고, 일시적으로 트래픽을 제한한 뒤, 필요하면 새 키를 요구.
• UI에 항상 이유를 표시: "120요청/분으로 인해 제한됨."

예시: 파트너가 두 지역에서 API를 사용합니다. 회전 동안 두 키가 7일간 모두 작동하면 배포가 한밤중 컷오버나 지원 티켓 없이 안전하게 진행됩니다.

모니터링과 알림: 무엇을 보여주고, 무엇을 알릴지

좋은 모니터링은 "보안 쇼윈도"가 아니라 한 가지 질문에 빠르게 답하는 것입니다: 이 키가 소유자가 기대한 방식으로 사용되고 있나?

키 목록에는 사람들이 빠르게 훑어볼 수 있는 상태 칩을 보여주세요. "활성(Active)"과 "폐기(Revoked)"는 명확하지만 "곧 만료(Expiring soon)"는 예기치 않은 중단을 막습니다. 간단한 "마지막 사용(Last used)" 타임스탬프와 "한 번도 사용 안 함(Never used)" 표시도 추가하세요.

로그 뷰는 단순한 원시 요청보다 패턴을 강조해야 합니다. 화려한 그래프가 없어도 유용할 수 있습니다. 몇 가지 잘 고른 신호가 대부분의 문제를 잡습니다:

• 요청이나 실패의 갑작스러운 급증(특히 많은 401)
• 새로운 IP 범위나 새로운 국가에서 처음 관찰
• 수주간 조용하던 키가 다시 호출을 시작함

알림은 드물고 실행 가능해야 합니다. 모든 것을 알리면 사용자는 무음 처리하고 정말 중요한 알림을 놓칩니다. 실용적인 v1 알림 세트:

• 키 곧 만료(예: 7일, 1일)
• 오랜 비활성 후 첫 사용
• 짧은 기간 내 많은 401

민감한 스코프의 경우 생성, 회전, 확장 전에 MFA나 승인 단계 같은 더 강한 게이트를 추가할 가치가 있습니다. 영향이 큰 곳에만 쓰세요.

백엔드와 데이터 모델: 저장해야 할 것(그리고 저장하지 말아야 할 것)

좋은 UI도 백엔드가 잘못 저장하면 실패합니다. 목표는 단순합니다: 기본적으로 안전하고, 감사하기 쉽고, 오용하기 어렵게 키를 만드는 것.

작고 명확한 데이터 모델로 시작하세요. "누가 무엇을 언제 왜 했는가"에 답할 수 있을 만큼의 필드가 필요합니다.

포함할 핵심 테이블

실용적인 최소 구성은:

• api_keys: id, owner_id, environment, status(활성/폐기), created_at, last_used_at, expires_at(선택), key_prefix, secret_hash, rotated_from_key_id(선택)
• scopes: id, name, description, risk_level(선택)
• api_key_scopes: api_key_id, scope_id
• audit_events: actor_id, action, target_type, target_id, metadata, created_at

스코프 모델은 안정적으로 유지하세요. 스코프를 나중에 이름 변경하거나 삭제하면 통합이 깨지고 로그가 혼란스러워질 수 있습니다.

원문 비밀은 절대 저장하지 마세요

API 키는 비밀번호처럼 취급하세요. 생성 시 한 번만 보여주고 이후에는 일방향 해시(및 키별 솔트)만 저장하세요. 지원과 UX 용도로 키를 구분하기 위한 짧고 비밀이 아닌 식별자(예: "live_2F9K…")를 저장하세요.

회전의 경우 새 키와 이전 키의 관계(rotated_from_key_id)를 저장하세요. 이렇게 하면 오래된 비밀을 보관하지 않고도 깔끔한 기록을 유지할 수 있습니다.

감사 추적과 접근 제어

모든 민감한 변경은 감사 이벤트를 생성해야 합니다: 생성, 스코프 변경, 회전, 폐기, 로그 조회 등. 누가 무엇을 할 수 있는지 미리 결정하세요. 일반적인 설정은 관리자가 모든 키를 관리하고 모든 로그를 볼 수 있고, 개발자는 자신의 키를 관리하고 자신의 로그만 볼 수 있으며, 지원/읽기 전용 역할은 비밀을 보거나 스코프를 변경할 수 없고 로그만 볼 수 있게 하는 것입니다.

보안 위험과 지원 부담을 만드는 흔한 실수들

회전을 지원 악몽으로 만드는 가장 빠른 방법은 위험한 선택을 정상처럼 느끼게 하는 UI를 출시하는 것입니다. 대부분의 문제는 예측 가능한 몇 가지 함정에서 옵니다.

지나치게 관대 한 기본값

기본 키가 "모든 것을 할 수 있다"면 대부분 사람은 좁히지 않을 것입니다. 첫 키를 그대로 프로덕션에 복사하고 잊어버립니다.

더 안전한 패턴은 최소 스코프 기본값과 무언가 실패했을 때의 명확한 오류(예: "missing scope: invoices.read"). "전체 접근" 옵션이 필요하다면 명시적인 선택으로 짧은 경고를 붙이세요.

정체불명의 키와 정체불명의 중단

키에는 소유자와 목적이 필요합니다. 이 필드가 없으면 몇 주 후 "어떤 키가 문제인지?" "이걸 삭제할 수 있나?" 같은 티켓이 쌓입니다.

생성 시 두 가지 작은 입력을 요구하세요:

• 소유자(사람 또는 팀)
• 목적(예: "Zapier 통합" 또는 "Partner ABC sandbox")

회전도 흔한 장애 유발자입니다. 이전 키를 즉시 무효화하는 강제 컷오버를 하면 고객은 다운타임을 경험합니다. 겹침을 허용하세요: 새 키 생성 → 이전 키 단기 유효 유지 → 이전 키 비활성화.

기본 질문에 답하지 못하는 로그

로그가 실패하는 이유는 보통 지원에 필요한 한 가지 항목이 빠졌기 때문입니다: 어떤 키가 사용되었는가. 유용한 항목에는 키 id(비밀 아님), 타임스탬프, 엔드포인트/액션, 환경, 결과(성공/실패 및 상태 코드)가 포함되어야 합니다. 결과 코드 없이는 "잘못된 키"인지 "스코프 부족"인지 "서버 오류"인지 알 수 없습니다.

"도움이 되는" UX로 비밀이 유출됨

생성 후 비밀을 다시 보여주지 마세요. 이메일로 보내지 마세요. 스크린샷, 내보내기, "팀원과 공유" 흐름에 포함시키지 마세요. 누군가 분실하면 해결책은 새 키를 만들고 회전하는 것입니다.

출시 전에 확인할 빠른 체크리스트

출시 전에 빠른 지원·보안 점검을 하세요. 좋은 키 화면은 키 생성뿐 아니라 안전한 선택을 쉽게 만드는 것이 핵심입니다.

• 모든 키에 명확한 소유자와 목적이 있음. "누가 소유하고 왜 존재하는가?"에 답할 수 있어야 합니다.
• 한 곳에서 "누가 마지막으로 사용했나"에 답할 수 있음. 각 키에 대해 마지막 사용 시간, 환경, 호출 앱/클라이언트를 보여주세요.
• 바쁜 날에도 회전이 안전함. 전환 중 두 개의 활성 키를 지원하고 간단한 계획을 보여주세요: 새 키 생성 → 클라이언트 업데이트 → 트래픽 확인 → 이전 키 비활성화.
• 민감한 스코프는 명확하고 보호됨. 고영향 스코프를 평이한 단어로 라벨링하고 요청 시 추가 단계를 걸기.
• 폐기는 빠르고 영향이 측정 가능함. 유출된 키는 몇 초 내에 폐기 가능하고 로그가 무슨 일이 일어났는지 확인해야 합니다.

노코드 도구로 만든다면 이러한 포인트를 나중의 "개선"이 아니라 초기 UI 요구사항으로 다루세요. 이들이 키 관리가 사고를 줄이는지 만들지 결정합니다.

예시: 파트너에게 전체 계정을 주지 않고 접근 권한 부여하기

일반적 상황: 물류 파트너가 송장 데이터를 가져가서 배송을 생성해야 합니다. 주문을 변경하거나 환불을 처리하거나 고객 지원 노트를 볼 필요는 없습니다. 전체 접근 키를 건네면 공격 범위가 넓어집니다.

간단하고 안전한 흐름(파트너에겐 빠르게 느껴짐): 개발자 포털에서 계정 소유자가 "Logistics Partner - Orders Read"라는 새 키를 생성합니다. 읽기 전용 스코프인 orders:read만 선택하고 만료일(예: 90일)을 설정하며, 현실적이라면 알려진 IP 범위로만 허용할 수도 있습니다.

복사 단계는 명확하게 표시하세요: 토큰은 한 번만 보여주고 "지금 복사하세요. 이 키는 다시 볼 수 없습니다." 같은 문구를 분명히 적습니다. 이 한 문장이 많은 지원 티켓을 예방합니다.

며칠 후 파트너가 "API가 다운된 것 같다"고 보고하면 사용 로그는 몇 초 만에 실질적 질문에 답해줘야 합니다:

• 어떤 엔드포인트가 호출되었고, 어떤 키가 사용되었는가
• 반환된 상태 코드와 오류 메시지
• IP 주소와 유저 에이전트(해당되는 경우)
• 지원 추적용 타임스탬프와 요청 ID

이 시나리오에서 로그는 종종 간단한 문제를 드러냅니다: 그들이 읽기 전용 키로 /orders/update를 호출하거나 요청이 허용 목록에 없는 새로운 IP에서 오고 있다는 식입니다. 이제 지원은 추측하는 대신 하나의 명확한 수정안을 줄 수 있습니다.

회전은 좋은 UX가 진가를 발휘하는 순간입니다. 파트너의 계약자가 떠나면 동일한 orders:read 스코프로 새 키를 만들고 두 키를 단기간 겹치게 유지한 후 새 키로 통합이 확인되면 이전 키를 폐기합니다.

성공은 이렇습니다: 파트너가 팀을 기다리지 않고 온보딩하고, 기본적으로 접근은 최소화되며, 문제가 생기면 무엇이 일어났는지 정확히 보고 신속히 대응할 수 있습니다.

다음 단계: v1을 출시하고 전체를 다시 쓰지 말고 개선하세요

작게 시작하세요. 깔끔한 v1이 몇 달 걸려도 사람들을 혼란스럽게 하는 화려한 포털보다 낫습니다. 대부분 제품은 짧은 스코프 목록, 기본 사용 로그, 하나의 안전한 회전 흐름으로 대부분의 실제 요구를 처리할 수 있습니다.

세 가지 빌딩 블록으로 시작하세요: 키, 스코프, 로그. 처음엔 스코프를 거칠게(read, write, admin) 유지하고 증거가 있을 때까지 수십 가지의 작은 권한을 추가하지 마세요. 회전은 지루하게 만드세요: 두 번째 키 생성 → 테스트 → 이전 키 폐기.

작동하는 간단한 v1 체크리스트:

• 6~12개 스코프(각 스코프가 허용하는 바에 대한 명확한 예시 포함)
• 키별 환경(prod vs sandbox)과 명확한 소유자
• 시간, 엔드포인트/액션, 상태 코드, 키 라벨이 포함된 사용 로그
• 겹침을 지원하는 회전 흐름(일시적으로 두 개의 활성 키)
• 실수로 클릭하기 어려운 폐기 액션

v1이 라이브된 후에는 지원 티켓을 줄이는 곳에 연마를 추가하세요. 로그 필터(날짜 범위, 상태, 엔드포인트/액션)가 보통 첫 번째 성과입니다. 다음은 경보: 급증, 반복 인증 실패, 오랜 비활성 후 첫 사용 등을 알리세요. 민감한 스코프에는 모든 것을 관리자 전용으로 만들기보다 승인 단계를 추가하세요.

제품 내부에서 UX를 문서화하세요. 액션 옆의 짧은 도움말이 긴 문서보다 효과적입니다: "업무 시간에 키를 회전하세요. 트래픽이 전환될 때까지 두 키를 활성화 상태로 유지하세요." 같은 문구가 좋습니다.

빠르게 셀프 서비스 포털을 구축하고 싶다면 노코드 접근법으로 잘 모델링할 수 있습니다: Keys 테이블, Scopes 테이블, Key-Scope 조인, Logs 테이블, 관리자와 지원 역할. On AppMaster (appmaster.io), you can design the database in the PostgreSQL Data Designer, implement rotation and approvals in the Business Process Editor, and ship an admin panel plus customer portal UI with flexible deployment options, including cloud hosting or source export.