조직, 애플리케이션, 환경
조직은 팀과 결제를 담당하고, 애플리케이션은 워크플로우와 API 키를 담당하며 각각 live 또는 sandbox 중 하나입니다. 이 구조를 제대로 이해하면 대부분의 혼란스러운 동작을 예방할 수 있습니다.
Organization = 팀, 결제 잔액, 감사 로그.
Application = 워크플로우, API 키, webhook 대상 주소, 보존 정책, 그리고 live 또는 sandbox 모드. "변경했는데 아무 일도 안 일어났다"는 문제 대부분은 잘못된 애플리케이션을 보고 있기 때문입니다.
#두 개의 계층
Organization은 여러분의 계정입니다. 다음을 소유합니다.
- 팀과 그들의 역할
- 결제 잔액과 인보이스
- 감사 로그
- 모든 애플리케이션
Application은 조직 내부의 작업 공간입니다. 다음을 소유합니다.
- 자체 워크플로우
- 자체 API 키
- 자체 webhook 대상 주소
- 자체 데이터 보존 정책
live또는sandbox중 하나인 모드
콘솔 상단의 드롭다운에서 애플리케이션을 전환할 수 있습니다.
#겉보기보다 중요한 이유
"변경했는데 아무 일도 안 일어났다"는 보고는 거의 항상 이 구조로 귀결됩니다.
- 세션은 애플리케이션 B에서 실행되는데 애플리케이션 A에서 워크플로우를 수정했습니다.
- 한 애플리케이션에 webhook 대상 주소를 추가했는데 다른 애플리케이션의 이벤트를 기대했습니다.
- 지금 처리하려는 리소스와 다른 애플리케이션의 키로 호출하면서, 분명히 존재하는 대상에 대해 404나 403을 받고 있습니다.
다른 것을 디버깅하기 전에 애플리케이션부터 확인하세요. API 오류와 그 의미를 참고하세요.
#Live와 sandbox는 별개의 애플리케이션입니다
라이브 애플리케이션 안에는 테스트 모드 전환 스위치가 없습니다. 모드는 애플리케이션 단위로 선택되므로, 테스트한다는 것은 sandbox 모드로 두 번째 애플리케이션을 만들고 그 키를 사용한다는 뜻입니다.
이 분리가 핵심입니다. 테스트 트래픽과 프로덕션 데이터는 절대 섞이지 않으며, sandbox 키가 실수로 실제 크레딧을 소모할 수도 없습니다. sandbox에서 테스트하기를 참고하세요.
애플리케이션 이름은 한눈에 절대 헷갈리지 않도록 지으세요. "Application"과 "Application (2)"보다 acme-live와 acme-sandbox가 낫습니다. 시크릿 관리 도구에서도 같은 이름 규칙으로 키를 저장하고, "지금 유효한 쪽 키"를 하나의 환경 변수에 담아 두는 방식은 절대 쓰지 마세요.
#애플리케이션은 몇 개나 있어야 할까요?
최소한 라이브 하나, sandbox 하나입니다. 그 이상은 독자적인 설정이나 독자적인 격리가 필요한 것 기준으로 나누세요.
- 제품별, 제품마다 다른 워크플로우와 다른 webhook 엔드포인트가 필요할 때.
- 환경별, 프리 프로덕션 환경을 여러 개 운영할 때.
- 브랜드별, 여러 브랜드로 서로 다른 스타일의 인증을 제공할 때.
- 보존 정책별, 보존 정책은 애플리케이션 단위로 설정되므로.
애플리케이션별로 나뉘지 않는 것은 잔액입니다. 이는 조직 단위이며, 모든 애플리케이션이 같은 크레딧을 사용합니다.
#추가 애플리케이션 만들기
추가 애플리케이션은 콘솔에서 만듭니다. 옵션이 보이지 않거나, 콘솔이 아니라 API를 통해 만들어야 한다면, 이는 계정 단위 권한 문제이므로 우회하려 하지 말고 지원팀에 문의하세요. 특히 두 번째 라이브 애플리케이션의 경우 요금제와 관련될 수 있습니다.
#여러 조직
한 사람의 이메일은 한 번에 하나의 조직에만 속하며, 조직 아래에 하위 조직이나 하위 계정을 만들 방법은 없습니다. 자체 고객 여러 곳에 서비스를 제공한다면 지원되는 구조는 하나의 조직 안에 고객별로 하나의 애플리케이션입니다. 각 애플리케이션은 자체 워크플로, 브랜딩, API 키, 결과, 사용량 보고서를 가지며 서로 완전히 분리되고, 청구는 조직 수준에 남습니다.
#Didit 재판매
Didit을 자체 제품에 번들로 넣고 고객에게 요금을 받고 싶다면, 그것이 리셀러 모델입니다. 지원팀이 문의하는 모든 분께 안내하는 조건은 다음과 같습니다.
- 선불 크레딧. 최소 초기 구매액 5,000 USD, 선불, 1년 계약입니다. 크레딧은 만료되지 않고 조직 수준에 있으며 귀하가 온보딩한 모든 최종 고객에 걸쳐 차감되고, 금액이 클수록 커지는 볼륨 할인이 적용됩니다.
- 대시보드는 귀하가 만듭니다. Didit API를 자체 프런트엔드에 통합하고, 고객은 그곳에서 워크플로, 브랜딩, 역할을 관리합니다. Didit은 Business Console의 화이트라벨 사본을 제공하지 않습니다. 최종 사용자가 보는 검증 화면에는 귀하의 브랜드를 입힐 수 있지만(화이트라벨 참고) 콘솔은 그렇지 않습니다.
- 마진은 귀하의 것입니다. 고객이 지불하는 가격은 귀하가 정합니다. Didit은 계약 기간 동안 고정된 단가로 완료된 기능별로 귀하에게 청구합니다.
- 현지 파트너 프로그램이 아닙니다. Didit은 데모, 온보딩, 지원을 고객과 직접 진행하며 유통이나 구현 파트너를 찾고 있지 않습니다.
재판매를 직접 하고 싶지 않다면 추천 옵션을 사용하세요. Business Console 사이드바에서 추천을 열고 프로그램 약관에 동의한 뒤 링크를 공유합니다. 추천한 조직의 첫 입금부터 36개월 동안 모든 현금 입금의 10% 수수료를 받으며, Didit 크레딧으로 쓰거나 성숙 기간 후 은행 송금으로 지급받을 수 있고, 납품이나 지원 의무는 없습니다. 어느 쪽이든 결정하기 전에 무료 티어에서 연동을 구축하고 테스트할 수 있습니다.
#애플리케이션 삭제하기
애플리케이션을 삭제하면 그 워크플로우와 설정이 제거됩니다. 인증 데이터는 애플리케이션의 수명 주기가 아니라 해당 데이터의 보존 정책과 삭제 규칙을 따릅니다. 따라서 목표가 고객 데이터를 지우는 것이라면 애플리케이션을 제거하는 것으로 충분하다고 가정하지 말고 데이터를 명시적으로 삭제하세요. 세션과 개인정보 삭제하기를 참고하세요.
#모든 것이 추적 가능합니다
모든 API 호출은 어떤 애플리케이션에 속하는지가 감사 로그에 365일 동안 기록됩니다. 이 덕분에 다중 애플리케이션 구조가 단순히 정돈된 것을 넘어 감사 가능한 상태가 됩니다. 감사 로그 사용하기를 참고하세요.