조직, 애플리케이션, 환경

조직은 팀과 결제를, 애플리케이션은 워크플로우와 API 키를 담당하며 각각 라이브와 샌드박스 환경으로 나뉩니다.

#두 개의 계층

Organization은 여러분의 계정입니다. 다음을 소유합니다.

• 팀과 그들의 역할
• 결제 잔액과 인보이스
• 감사 로그
• 모든 애플리케이션

Application은 조직 내부의 작업 공간입니다. 다음을 소유합니다.

• 자체 워크플로우
• 자체 API 키
• 자체 webhook 엔드포인트
• 자체 데이터 보존 정책
• 애플리케이션별 제품 켜기 기능이 적용된 경우, 자체 제품. 제품과 포함 항목을 참고하세요
• 두 개의 환경: 라이브와 샌드박스

사이드바 상단의 애플리케이션 카드에서 애플리케이션을 전환하세요. 전환은 즉시 적용됩니다. 같은 메뉴에서 애플리케이션 설정과 애플리케이션 만들기도 열 수 있습니다.

#겉보기보다 중요한 이유

"변경했는데 아무 일도 안 일어났다"는 보고는 거의 항상 이 구조로 귀결됩니다.

• 세션은 애플리케이션 B에서 실행되는데 애플리케이션 A에서 워크플로우를 수정했습니다.
• 한 애플리케이션에 webhook 엔드포인트를 추가했는데 다른 애플리케이션의 이벤트를 기대했습니다.
• 트래픽은 라이브에서 실행되는데 샌드박스를 보고 있거나, 그 반대입니다.
• 지금 처리하려는 리소스와 다른 애플리케이션의 키로 호출하면서, 분명히 존재하는 대상에 대해 404나 403을 받고 있습니다.

다른 것을 디버깅하기 전에 애플리케이션부터 확인하세요. API 오류와 그 의미를 참고하세요.

#라이브와 샌드박스는 별개의 환경입니다

새 애플리케이션은 라이브입니다. 테스트는 샌드박스에서 이루어집니다. 샌드박스는 조직이 공유하는 테스트 애플리케이션으로, 자체 데이터와 자체 키를 가집니다. 사이드바의 애플리케이션 이름 아래에 있는 라이브와 샌드박스 알약 버튼으로 둘 사이를 전환하세요.

인증, API 키, 웹훅, 목록은 환경마다 별도로 관리됩니다. 브랜딩은 공유되며, 워크플로우는 한 번 만들어 환경 간에 복사할 수 있습니다. 이 분리가 핵심입니다. 테스트 트래픽과 프로덕션 데이터는 절대 섞이지 않으며, 샌드박스 키가 실수로 실제 크레딧을 소모할 수도 없습니다. sandbox에서 테스트하기를 참고하세요.

#애플리케이션은 몇 개나 있어야 할까요?

대부분의 팀은 하나로 시작하며, 이것만으로도 라이브와 샌드박스가 갖춰집니다. 그 이상은 독자적인 설정이나 독자적인 격리가 필요한 것 기준으로 나누세요.

• 제품별, 제품마다 다른 워크플로우와 다른 webhook 엔드포인트가 필요할 때.
• 프리 프로덕션 환경별, 샌드박스 하나로는 부족할 때.
• 브랜드별, 여러 브랜드로 서로 다른 스타일의 인증을 제공할 때.
• 보존 정책별, 보존 정책은 애플리케이션 단위로 설정되므로.

애플리케이션별로 나뉘지 않는 것은 잔액입니다. 이는 조직 단위이며, 모든 애플리케이션이 같은 크레딧을 사용합니다.

#추가 애플리케이션 만들기

사이드바 상단의 애플리케이션 카드를 열고 애플리케이션 만들기를 선택한 다음 애플리케이션 이름을 입력하세요(애플리케이션별 제품 기능이 적용된 경우 용도도 선택합니다). 옵션이 보이지 않거나, 콘솔이 아니라 API를 통해 만들어야 한다면, 이는 계정 단위 권한 문제이므로 우회하려 하지 말고 지원팀에 문의하세요.

#여러 조직

한 사람이 여러 조직에 속할 수 있으며, 사이드바 상단의 조직 메뉴에서 조직 사이를 전환합니다. 대기 중인 초대도 이 메뉴에 표시됩니다. 직접 조직을 두 개 이상 만드는 것은 리셀러 계정으로 제한되며(활성화하려면 지원팀에 문의하세요), 조직 아래에 하위 조직이나 하위 계정을 만들 방법은 없습니다. 자체 고객 여러 곳에 서비스를 제공한다면 지원되는 구조는 하나의 조직 안에 고객별로 하나의 애플리케이션입니다. 각 애플리케이션은 자체 워크플로, 브랜딩, API 키, 결과, 사용량 보고서를 가지며 서로 완전히 분리되고, 청구는 조직 수준에 남습니다.

#Didit 재판매

Didit을 자체 제품에 번들로 넣고 고객에게 요금을 받고 싶다면, 그것이 리셀러 모델입니다. 지원팀이 문의하는 모든 분께 안내하는 조건은 다음과 같습니다.

• 선불 크레딧. 최소 초기 구매액 $5,000 USD, 선불, 1년 계약입니다. 크레딧은 만료되지 않고 조직 수준에 있으며 귀하가 온보딩한 모든 최종 고객에 걸쳐 차감되고, 금액이 클수록 커지는 볼륨 할인이 적용됩니다.
• 대시보드는 귀하가 만듭니다. Didit API를 자체 프런트엔드에 통합하고, 고객은 그곳에서 워크플로, 브랜딩, 역할을 관리합니다. Didit은 Business Console의 화이트라벨 사본을 제공하지 않습니다. 최종 사용자가 보는 검증 화면에는 귀하의 브랜드를 입힐 수 있지만(화이트라벨 참고) 콘솔은 그렇지 않습니다.
• 마진은 귀하의 것입니다. 고객이 지불하는 가격은 귀하가 정합니다. Didit은 계약 기간 동안 고정된 단가로 완료된 기능별로 귀하에게 청구합니다.
• 현지 파트너 프로그램이 아닙니다. Didit은 데모, 온보딩, 지원을 고객과 직접 진행하며 유통이나 구현 파트너를 찾고 있지 않습니다.

재판매를 직접 하고 싶지 않다면 추천 옵션을 사용하세요. Business Console에서 설정 → 추천하고 보상받기를 열고 링크를 받아 공유합니다. 추천한 조직의 첫 입금부터 36개월 동안 모든 현금 입금의 10% 수수료를 받으며, Didit 크레딧으로 쓰거나 성숙 기간 후 은행 송금으로 지급받을 수 있고, 납품이나 지원 의무는 없습니다. 어느 쪽이든 결정하기 전에 무료 플랜에서 연동을 구축하고 테스트할 수 있습니다.

#애플리케이션 삭제하기

애플리케이션의 영구 삭제는 아직 사용할 수 없습니다. 애플리케이션 설정에 위험 구역이 있지만, 삭제를 사용할 수 없다고 안내할 뿐 아무것도 삭제하지 않습니다. 그때까지 선택할 수 있는 방법은 다음과 같습니다.

• 사용을 중단하세요. 아무도 실수로 선택하지 않도록 이름을 바꾸고(예: acme-old), 개발자 → API 키에서 API 키를 취소하세요.
• 고객 데이터를 지우세요. 인증 데이터는 애플리케이션의 수명 주기가 아니라 해당 데이터의 보존 정책과 삭제 규칙을 따르므로, 데이터를 명시적으로 삭제하세요. 세션과 개인정보 삭제하기를 참고하세요.
• 처음부터 다시 시작하세요. 지원팀이 조직 전체를 삭제해 새 조직을 만들 수 있게 해 줍니다. 팀, 잔액, 이력이 함께 사라지므로 최후의 수단입니다.

#모든 것이 추적 가능합니다

모든 변경 사항은 어떤 애플리케이션에 속하는지가 감사 로그에 기록됩니다. 이 덕분에 다중 애플리케이션 구조가 단순히 정돈된 것을 넘어 감사 가능한 상태가 됩니다. 감사 로그 사용하기를 참고하세요.