에이전시가 필요로 하는 것을 알았기에, 이틀째에 멀티테넌시를 구축했습니다

2025년 8월 21일. STRAŦUM 구축 2일째.

책상 앞에 앉아 하나의 작동하는 AI 에이전트(비즈니스 전략), 기본 인증, 그리고 매우 간단한 데이터 모델을 가지고 있었습니다. 커피가 식어가고 있었습니다. 누구를 위해 만들 것인지 정확히 알고 있었습니다: AI 마케팅 도움이 필요한 중소기업과, 여러 클라이언트에 걸쳐 활용할 수 있는 에이전시.

두 대상 모두. 첫째 날부터.

에이전시 측에서 20년을 일한 후, 에이전시가 실제로 무엇을 필요로 하는지 이해하고 있었습니다—화려한 마케팅 버전이 아닌, 각각 다른 전략, 다른 브랜드 가이드라인, 모든 것이 다른 10-15개 클라이언트를 관리하는 복잡한 현실 말입니다. 또한 중소기업들이 절실히 합리적인 전략적 도움을 필요로 한다는 것도 알고 있었습니다.

하지만 이틀째, 간단한 데이터 모델을 바라보며 불편한 사실을 깨달았습니다: 두 대상 모두를 위해 구축한다는 것은 멀티테넌트 아키텍처를 지금 당장 구축해야 한다는 것을 의미했습니다. 나중이 아니라.

하루가 끝날 무렵, 개발 복잡성을 3배로 늘리고 일정을 몇 주 연장하는 결정에 전념했습니다.

이틀째부터 멀티테넌트 아키텍처를 구축했습니다.

야심적이었을까요, 무모했을까요? 솔직히 확신이 없었습니다. 지금도 100% 확신하지는 못합니다. 하지만 거의 작동하는 제품이 없는 상태에서 내린 이 결정이 제가 내린 가장 중요한 기술적 선택 중 하나가 된 이야기를 들려드리겠습니다.

왜 두 대상 모두인가? 20년의 에이전시 경험

비전은 처음부터 중소기업만을 위한 것이 아니었습니다. 처음부터 두 가지 뚜렷한 대상을 위해 만들고 싶었습니다:

중소기업(직원 1-30명) — 감당할 수 있는 전략적 공동 창업자:

- 마케팅 에이전시나 컨설턴트를 고용할 여유가 없습니다

- 전략적 마케팅 전문성이 없습니다

- 학습 곡선 없이 빠른 성과가 필요합니다

에이전시(5-15개 이상의 클라이언트 관리) — 인력이 아닌 전략적 역량을 확장하십시오:

- 여러 클라이언트에 걸친 전략 업무에 파묻혀 있습니다

- 확장 가능한 일관된 프레임워크가 필요합니다

- 클라이언트 간 완전한 데이터 격리가 필요합니다

왜 에이전시인가? 20년을 에이전시 측에서 보냈기 때문입니다. 그 고통을 직접 알고 있습니다.

전략가들이 12개의 클라이언트를 각각 다른 12개의 브랜드 가이드라인으로 저글링하면서, 도구 간에 컨텍스트를 복사 붙여넣기하고, 실수로 잘못된 클라이언트에게 잘못된 전략을 보내지 않기를 기도하는 모습을 보아왔습니다. 인력을 늘리지 않고는 전략적 사고를 확장할 방법이 없어서 좋은 인재들이 번아웃으로 떠나는 것을 지켜보았습니다.

그리고 솔직히? 스스로에게 도전하고 싶었습니다. 중소기업만을 위해 구축하는 것이 더 간단했을 것입니다—한 명의 사용자, 하나의 조직, 간단한 라우팅. 에이전시를 위해 구축한다는 것은 다중 클라이언트 대시보드, 데이터 격리, 역할 기반 권한, 클라이언트 범위의 모든 것을 의미했습니다.

복잡한 것을 만들고 싶었습니다. 20년 동안 보아온 어려운 문제를 실제로 해결하는 것을 말입니다.

이틀째의 깨달음: 멀티테넌시는 나중에 추가할 수 없습니다

이틀째, 간단한 데이터 모델을 바라보며 이해한 것은 이것입니다:

중소기업 아키텍처 (제가 가지고 있던 것):

```
users → campaigns → agent_outputs
```

멀티테넌트 아키텍처 (에이전시를 위해 필요한 것):

```
organizations (SME or AGENCY)
  ↓
clients (agencies only)
  ↓
campaigns
  ↓
agent_outputs (with org_id AND client_id)
```

차이점은 단순히 "몇 개의 컬럼을 추가하는 것"이 아닙니다. 근본적으로 다른 데이터 모델입니다.

만약 중소기업을 먼저 구축하고 나중에 에이전시 지원을 추가한다면, 다음을 해야 했을 것입니다:

- 모든 기존 테이블에 `org_id`를 추가하기 위한 마이그레이션

- 전체 데이터베이스에 걸친 RLS 정책 소급 적용

- 클라이언트 컨텍스트를 위한 프론트엔드 라우팅 재작성

- 멀티테넌트 시나리오로 모든 것을 다시 테스트

그것은 기능 추가가 아닙니다. 재작성입니다.

더 오래 기다릴수록 소급 적용 비용은 더 높아집니다. 이틀째는 저렴했습니다. 60일째는 고통스러울 것입니다. 200일째는 "에이전시를 위한 별도 제품을 만드는 게 나을지도"가 될 것입니다.

그래서 결정을 내렸습니다: 이틀째부터 멀티테넌트를 구축하거나, 에이전시가 영원히 1등 시민이 되지 못할 것을 받아들이거나.

트레이드오프: 멀티테넌시의 실제 비용

여기서 멈추고 스스로에게 물어봤어야 했습니다: "확실한가? 작동하는 에이전트가 하나뿐인데. 하나."

하지만 멈추지 않았습니다. 대신 미친 듯이 SQL 스키마를 작성하기 시작했습니다. 이틀째의 멀티테넌시는 합리적인 사람이라면 재고할 만한 비용을 감수하는 것을 의미했습니다:

비용 1: 개발 복잡성 (3배)

모든 테이블에 `org_id`가 필요했습니다. 에이전시 테이블에는 `client_id`가 필요했습니다. RLS 정책에는 두 필터가 모두 필요했습니다. 모든 쿼리, 모든 API 엔드포인트, 모든 프론트엔드 라우트—모두 멀티테넌트를 인식해야 했습니다.

예상 복잡성 증가: 동일한 기능에 대해 3배의 개발 시간.

(스포일러: 실제로는 4배에 가까웠습니다. 과소평가했습니다. 전형적인 저답죠. :P)

비용 2: 연장된 개발 일정

첫째 날부터 두 대상을 위해 구축한다는 것은 출시까지의 경로가 더 길다는 것을 의미했습니다. 일정은 다음과 같았습니다:

일정:

- 8월 20일: 구축 시작 (첫째 날부터 멀티테넌트)

- 9월 15일: 4주 후, 3개의 에이전트 작동, 10월 목표

- 10월: 10일간 아파서 코딩 불가

- 11월 5일: 프라이빗 알파 출시 (총 75일)

멀티테넌시가 추가한 것:

- 퍼블릭과 에이전시 테이블 간의 스키마 라우팅

- 모든 테이블에 대한 RLS 정책 (결국 26개 테이블에 83개)

- 모든 에이전트를 통한 클라이언트 컨텍스트 전파

- 이중 라우팅 패턴 (중소기업 vs 에이전시 URL)

중소기업 전용 아키텍처로 더 빨리 출시할 수 있었을까요? 아마 3-4주 더 빨랐을 것입니다. 하지만 그러면 에이전시가 문을 두드릴 때 재작성을 해야 했을 것입니다.

비용 3: 보안 요구사항 (더 높은 리스크)

중소기업 데이터 격리는 기본입니다. 에이전시 데이터 격리는 미션 크리티컬합니다.

추가된 요구사항:

- 26개 테이블에 걸친 83개의 RLS 정책

- 스키마 수준 격리 (퍼블릭 vs 에이전시 스키마)

- 모든 CRUD 작업을 위한 데이터베이스 라우터 함수

- 포괄적인 감사 로깅

- 다중 인증 옵션

보안 복잡성: 중소기업 전용 대비 5배 높음.

어떤 주에는 실제 AI 에이전트 개발보다 Row-Level Security 정책에 더 많은 시간을 쏟았습니다. 잘 생각해 보십시오.

비용 4: 테스트 복잡성 (2배의 테스트 케이스)

모든 기능에 대해 다음을 테스트해야 했습니다:

- ✅ 중소기업 플로우 (더 간단)

- ✅ 에이전시 플로우 (클라이언트 범위)

- ✅ 데이터 격리 (Nike ≠ Adidas)

- ✅ 권한 경계 (에이전시가 중소기업 데이터를 볼 수 있는가? 아니오.)

테스트 유지보수: 2배로 증가.

같은 테스트를 약간 다른 컨텍스트로 두 번 작성하는 것이 재미있다고 한 사람은 아무도 없습니다.

---

그래도 이 트레이드오프를 선택한 이유

정리하면: 3배의 복잡성, 연장된 일정, 5배의 보안 오버헤드, 2배의 테스트... 그런데도 했다고요?

네. 다음은 그 당시의 생각입니다:

이유 1: 소급 적용은 악몽입니다

이틀째: 코드가 거의 없음. 데이터 모델이 아직 유연함. 마이그레이션할 사용자 없음.

60일째: 45개 테이블, 20만 줄의 코드, 15명의 알파 사용자. 멀티테넌시 추가는 코드베이스의 절반을 재작성해야 함.

교훈: 아키텍처 결정은 시간이 지남에 따라 기하급수적으로 변경하기 어려워집니다.

이틀째의 비용: 데이터 모델 재설계에 약 5시간.

60일째의 비용: 모든 것을 리팩토링하는 데 약 200시간.

멀티테넌시를 소급 적용하려는 회사들을 본 적이 있습니다. 잔인합니다. 승객이 탑승한 비행기를 날리면서 다시 만드는 것과 같습니다. 돈을 지불하는 승객이요.

이유 2: 에이전시를 실제로 이해하고 있습니다

이것은 이론적인 시장 조사가 아니었습니다. 20년 동안 에이전시가 정확히 이 문제로 고군분투하는 것을 지켜보았습니다.

에이전시가 필요로 하는 것을 알고 있습니다:

- 완전한 데이터 격리 (클라이언트 1은 클라이언트 2의 전략을 볼 수 없음)

- 클라이언트 범위의 모든 것 (브랜드 가이드라인, 페르소나, 캠페인)

- 역할 기반 접근 (어카운트 매니저 vs 전략가)

- 클라이언트 프레젠테이션을 위한 화이트 라벨 잠재력

이 고통을 직접 겪었기 때문에 제대로 만들 수 있었습니다. 중소기업 전용으로 출시하고 "나중에 에이전시를 추가"해서 낭비하고 싶지 않은 장점이었습니다.

이유 3: 도전 자체가 목적이었습니다

자주 말하지 않는 것이 있습니다: 복잡성을 원했습니다.

저는 가족이 있는 중년 창업자이지, 에너지 드링크와 수면 없이 버틸 수 있는 22살이 아닙니다. 1년을 들여 무언가를 만들 거라면, 저에게 도전이 되는 것이어야 합니다. 기술적으로 자랑스러운 것이어야 합니다.

적절한 데이터 격리, RLS 정책, 스키마 라우팅을 갖춘 멀티테넌트 아키텍처—그것은 어렵습니다. 흥미롭습니다. 새벽 2시에도 몰두하게 만드는 종류의 엔지니어링 문제입니다.

중소기업 전용을 만드는 것이 더 빨랐을 것입니다. 하지만 어려운 부분을 극복할 동기부여가 되었을까요? 아마 아닐 것입니다.

이유 4: 두 대상이 서로를 더 좋게 만듭니다

중소기업과 에이전시는 경쟁하는 사용 사례가 아닙니다. 보완적입니다:

- 에이전시가 제품을 검증합니다: 에이전시가 클라이언트 데이터를 맡길 정도로 신뢰한다면, 중소기업도 그럴 것입니다

- 중소기업이 볼륨을 제공합니다: 더 많은 사용자는 더 많은 피드백, 더 빠른 반복을 의미합니다

- 아키텍처가 둘 다에게 서비스합니다: 팀 계정, 역할 권한, 화이트 라벨이 두 대상 모두에게 작동합니다

둘 다를 위해 구축한다는 것은 곧 성장을 넘어설 단순화된 버전이 아닌 완전한 솔루션을 구축하는 것을 의미했습니다.

이유 5: 미래 대비

에이전시를 넘어서도, 멀티테넌시 아키텍처는 다음을 가능하게 했습니다:

- 팀 계정 (여러 사용자가 있는 중소기업)

- 리셀러 파트너십

- 화이트 라벨 기회

- 엔터프라이즈 영업 (가고자 한다면)

옵션 가치: 멀티테넌시는 이틀째에 상상조차 할 수 없었던 비즈니스 모델을 가능하게 했습니다.

구현: 이틀째 아키텍처 결정의 실제 모습

8월 21일에 실제로 구축한 것은 다음과 같습니다:

데이터베이스 스키마 (핵심 결정)

```sql
-- Organizations table (SME or AGENCY)
CREATE TABLE organizations (
  id UUID PRIMARY KEY,
  name TEXT,
  type TEXT CHECK (type IN ('SME', 'AGENCY')),  -- Critical distinction
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Clients table (agencies only)
CREATE TABLE clients (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Which agency owns this
  company_name TEXT,
  slug TEXT UNIQUE,  -- For URL routing
  created_at TIMESTAMPTZ DEFAULT NOW(),

  -- Constraint: Only agencies can have clients
  CONSTRAINT clients_agency_only CHECK (
    (SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
  )
);

-- Campaigns table (multi-tenant aware)
CREATE TABLE campaigns (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Always required
  client_id UUID REFERENCES clients(id),      -- Required for agencies, null for SMEs
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Agent outputs (multi-tenant + client-scoped)
CREATE TABLE agent_outputs (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),
  client_id UUID REFERENCES clients(id),
  campaign_id UUID REFERENCES campaigns(id),
  agent_type TEXT,
  content JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
```

이틀째의 핵심 결정들:

- 모든 테이블에 `org_id` (RLS 가능하게 함)

- `client_id` nullable (중소기업은 클라이언트가 없음)

- 조직에 `type` 구분자 (SME vs AGENCY)

- 제약조건: 에이전시만 클라이언트를 생성할 수 있음

Row-Level Security (이틀째 계획)

```sql
-- RLS policy for campaigns (multi-tenant isolation)
CREATE POLICY campaigns_org_isolation ON campaigns
  FOR ALL TO authenticated
  USING (
    org_id = get_user_org_id() AND
    (client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
  );
```

이 정책이 보장하는 것:

- ✅ 사용자는 자기 조직의 캠페인만 볼 수 있음

- ✅ 에이전시 사용자는 중소기업 캠페인을 볼 수 없음

- ✅ 에이전시는 서로의 클라이언트를 볼 수 없음

비용: 이틀째에 5개의 초기 RLS 정책 작성. 출시까지 결국 83개로 증가.

URL 라우팅 (첫째 날부터 멀티테넌트)

```typescript
// Frontend routing structure (planned Day 2)

// SME routes (simple)
/campaigns/:campaignId
/agents/strategy/:campaignId

// Agency routes (client-scoped)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```

이 URL 구조가 가능하게 한 것:

- ✅ 모든 URL에 클라이언트 컨텍스트 (에이전시)

- ✅ 중소기업과 에이전시 플로우 간의 명확한 분리

- ✅ 북마크 가능, 공유 가능한 URL

- ✅ 클라이언트별 분석 추적

결과: 성과가 있었나요?

출시일: 2025년 11월 5일 (시작부터 75일)

멀티테넌시로 인한 개발 오버헤드:

- 스키마 설계 및 마이그레이션

- 26개 테이블에 걸친 83개의 RLS 정책

- 데이터베이스 라우터 함수

- 이중 라우팅 패턴 (중소기업 vs 에이전시 URL)

- 클라이언트 컨텍스트 전파

Claude Code와 Gemini 2.5 Pro를 사용하여, 실제 코딩은 혼자 했을 때보다 빨랐습니다. 하지만 작동해야 하는데 작동하지 않는 RLS 정책을 디버깅하는 것은? AI 도움과 관계없이 새벽 2시에도 여전히 고통스럽습니다.

현재 가지고 있는 것:

- 조직 간 완전한 데이터 격리

- 클라이언트 스코핑이 포함된 에이전시 지원 아키텍처

- 26개 테이블에 걸친 83개의 RLS 정책

- 스키마 수준 라우팅 (퍼블릭 vs 에이전시 스키마)

- 첫째 날부터 내장된 화이트 라벨 잠재력

- 중소기업과 에이전시 모두에게 진정으로 서비스할 수 있는 제품

가치가 있었나요?

실제 고객이 실제 돈을 지불하는 6개월 후에 물어봐 주십시오. 현재는 15명 이상의 사용자와 함께 프라이빗 알파 중이며, 여전히 무엇이 효과적이고 무엇이 아닌지 배우고 있습니다.

하지만 이것만은 알고 있습니다: 두 대상 모두를 제대로 서비스할 수 있는 아키텍처를 가지고 있습니다. 중소기업 전용으로 만들고 나중에 에이전시를 추가하려 했다면, 지금쯤 3개월짜리 재작성을 바라보고 있었을 것입니다. 대신 아키텍처 부채가 아닌 제품-시장 적합성에 집중하고 있습니다.

그것이 올바른 트레이드오프라고 느껴집니다.

프레임워크: 멀티테넌시를 일찍 구축해야 할 때

모든 제품이 이틀째에 멀티테넌시를 필요로 하는 것은 아닙니다. 이 프레임워크를 사용하십시오:

멀티테넌시를 일찍 구축해야 하는 경우:

✅ 대상 시장에 에이전시/리셀러가 포함됨 (고객당 높은 가치)

✅ 데이터 격리가 중요함 (법적/규정 준수 요구사항)

✅ 팀 계정이 있는 B2B가 유력함 (Slack, Figma 모델)

✅ 화이트 라벨 기회가 존재함 (리셀러 GTM 전략)

✅ 엔터프라이즈 영업이 가능함 (첫째 날부터 다중 클라이언트 필요)

멀티테넌시를 건너뛰어야 하는 경우:

❌ B2C 제품 (개인 사용자, 조직 계층 없음)

❌ MVP에 속도가 필요함 (먼저 제품-시장 적합성 테스트)

❌ 팀/에이전시 사용 사례 없음 (싱글 플레이어 도구)

❌ 간단한 데이터 모델 (나중에 org_id 추가가 쉬움)

❌ 학습 중인 솔로 창업자 (복잡성이 너무 클 수 있음)

배운 점: 전문성에 맞게 구축하십시오

1. 대상 지식이 아키텍처를 주도해야 합니다

가상의 사용자가 아닌 실제로 이해하는 사용자를 위해 설계하십시오.

제 장점: 20년의 에이전시 경험으로 에이전시가 필요로 하는 것—데이터 격리, 클라이언트 스코핑, 역할 기반 접근—을 정확히 알고 있었습니다.

잘못된 접근: "먼저 중소기업을 위해 만들고, 에이전시를 이해하면 나중에 추가하자"

올바른 접근: "이미 에이전시를 이해하고 있다. 저렴할 때 지금 만들자."

시장 세그먼트에 대한 깊은 전문성이 있다면 활용하십시오. "더 간단한 것부터"로 미루지 마십시오.

2. 초기 복잡성이 후기 리팩토링보다 낫습니다

이틀째 아키텍처 비용: 데이터 모델 재설계에 5시간.

60일째 아키텍처 비용: 모든 것을 리팩토링하는 데 200시간.

40배 차이.

멀티테넌시가 필요할 것이라고 80% 확신한다면, 일찍 구축하십시오. 오래 기다릴수록 비용이 더 비싸집니다.

3. 기술적 도전이 동기부여가 될 수 있습니다

이것은 개인적인 것입니다: 어려운 것을 만들고 싶었습니다.

RLS 정책, 스키마 라우팅, 적절한 데이터 격리를 갖춘 멀티테넌트 아키텍처—그것은 흥미로운 엔지니어링입니다. 어려운 시기를 극복할 수 있게 해주었습니다.

솔로 창업자라면 동기부여를 과소평가하지 마십시오. 도전적인 것을 만드는 것이 더 빨리 출시하는 것보다 가치 있을 수 있습니다.

4. 아키텍처는 비즈니스 모델을 가능하게 합니다

멀티테넌시는 단순한 기술적 결정이 아니었습니다. 다음을 가능하게 했습니다:

- 에이전시 가격 등급 (가격 책정을 결정하면)

- 화이트 라벨 기회

- 엔터프라이즈 영업 잠재력

- 중소기업을 위한 팀 계정

아키텍처 = 코드 형태의 비즈니스 옵션성.

5. 솔로 창업자도 멀티테넌트를 구축할 수 있습니다

"멀티테넌시는 한 사람에게 너무 복잡하다" → 거짓.

현대적 도구(Supabase RLS, 데이터베이스 함수, AI 지원 개발)를 사용하면, 솔로 창업자도 엔터프라이즈급 멀티테넌시를 구축할 수 있습니다.

시간 비용: 70일 (파트타임).

얻는 것: 나중에 후회할 해킹이 아닌 실제 데이터 격리.

두 대상 모두에게 진지하게 서비스하려면 가치가 있습니다

마무리 생각

이틀째는 STRAŦUM이 성공할지 알기에 너무 이른 시점이었습니다. 에이전트 하나. 사용자 없음. 검증 없음. 단지 에이전시가 실제로 무엇을 필요로 하는지 알려주는 20년의 에이전시 경험만 있었습니다.

연장된 일정은 때때로 고통스러웠습니다. 다른 출시들을 보면서 저는 여전히 RLS 정책을 디버깅하고 데이터베이스 라우터 함수를 작성하고 있었으니까요. 좌절감은 말로 다 표현할 수 없습니다. 복잡성이 가치가 있는지 의문을 품는 날들도 있었습니다.

하지만 지금 이것만은 알고 있습니다: 첫째 날부터 두 대상을 위해 구축한 것은 올바른 결정이었습니다. 어떤 영리한 단위 경제학 계산 때문이 아닙니다—아직 어떤 가격 책정이 효과적일지 모릅니다. 하지만 두 대상 모두를 제대로 서비스할 수 있는 아키텍처를 가지고 있기 때문입니다.

이틀째의 멀티테넌시는 단순한 기술적 결정이 아니었습니다. 나중에 파악할 가상의 사용자가 아닌, 실제로 이해하는 사용자를 위해 구축한다는 베팅이었습니다.

그 베팅이 성과를 냈나요?

아직 15명 이상의 사용자와 함께 프라이빗 알파 중입니다. 아직 답을 모릅니다. 하지만 이것만은 말씀드릴 수 있습니다: 에이전시가 연락해서 "적절한 데이터 격리로 여러 클라이언트에 사용할 수 있나요?"라고 물으면 "네"라고 답할 수 있습니다. "작업 중입니다"라고 말할 필요가 없습니다.

그것이 올바른 기반이라고 느껴집니다.

야심적이었는지 고집스러웠는지는 시간이 말해줄 것입니다. (솔직히 둘 다 조금씩이었을 겁니다.) :)

너무 야심 차다고 느꼈던 초기 아키텍처 베팅을 한 적이 있으신가요—그리고 성과가 있었나요? 여러분의 이야기를 듣고 싶습니다.

감사합니다,

Chandler

STRAŦUM 아키텍처 시리즈: 이 이틀째 결정은 시작에 불과했습니다. 67일째에는 보안 감사에서 아키텍처 결함이 발견되어 멀티테넌시 레이어 전체를 재구축해야 했습니다. 그 다음에는 내비게이션 컨텍스트 손실로 인한 31개의 빈 화면이 있었고, 데이터베이스가 기술적으로는 정확하지만 296배 느린 것을 발견했습니다.

---

멀티테넌트 SaaS를 구축하고 계신가요? STRAŦUM의 아키텍처는 첫째 날부터 중소기업과 에이전시 고객 모두를 지원합니다. https://stratum.chandlernguyen.com/request-invitation에서 알파 접근을 요청하십시오

---

아키텍처 결정이 위장된 비즈니스 결정이라는 것을 여전히 배우고 있습니다. 여전히 RLS 정책을 디버깅하고 있습니다. 여전히 이틀째의 선택에 의문을 품고 있습니다 (하지만 이제는 덜합니다). 더 많은 구축 모험은 https://www.chandlernguyen.com/에서.

---