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

Source: https://help.didit.me/ko/account-organization/organizations-and-applications
Updated: 2026-10-12

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

**Organization** = 팀, 결제 잔액, 감사 로그.
**Application** = 워크플로우, API 키, webhook 엔드포인트, 보존 정책, 제품이며, **라이브**와 **샌드박스**의 두 환경으로 나뉩니다. "변경했는데 아무 일도 안 일어났다"는 문제 대부분은 잘못된 애플리케이션이나 잘못된 환경을 보고 있기 때문입니다.

## 두 개의 계층

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

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

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

- 자체 워크플로우
- 자체 API 키
- 자체 webhook 엔드포인트
- 자체 데이터 보존 정책
- 애플리케이션별 제품 켜기 기능이 적용된 경우, 자체 제품. [제품과 포함 항목](https://help.didit.me/ko/account-organization/products)을 참고하세요
- 두 개의 환경: **라이브**와 **샌드박스**

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

## 겉보기보다 중요한 이유

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

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

다른 것을 디버깅하기 전에 애플리케이션부터 확인하세요. [API 오류와 그 의미](https://help.didit.me/ko/integration/api-errors)를 참고하세요.

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

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

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

> **Tip:** 애플리케이션 이름은 한눈에 절대 헷갈리지 않도록 지으세요. "Application"과 "Application (2)"보다 `acme-onboarding`과 `acme-payments`가 낫습니다. 시크릿 관리 도구에서는 환경이 포함된 이름으로 키를 저장하고, "지금 유효한 쪽 키"를 하나의 환경 변수에 담아 두는 방식은 절대 쓰지 마세요.

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

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

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

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

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

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

## 여러 조직

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

## Didit 재판매

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

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

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

## 애플리케이션 삭제하기

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

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

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

모든 변경 사항은 어떤 애플리케이션에 속하는지가 감사 로그에 기록됩니다. 이 덕분에 다중 애플리케이션 구조가 단순히 정돈된 것을 넘어 감사 가능한 상태가 됩니다. [감사 로그 사용하기](https://help.didit.me/ko/account-organization/audit-logs)를 참고하세요.