여러 회사, 하나의 설치, 공유되지 않는 고객

회사를 두 개 이상 운영하신다면 — 자회사를 둔 지주회사, 프랜차이즈, 다른 시장을 겨냥한 두 브랜드, 에이전시와 에이전시에서 분사한 사업 — 문제의 모양은 이미 아실 거예요. 브랜드들은 사람과 도구와 재무 부서를 공유해요. 하지만 고객은 공유하지 않고, 공유하는 것처럼 보여서도 안 돼요.

iKonekt는 하나의 설치로 이 모든 것을 운영하고, 그 사이의 분리는 코드가 아니라 데이터베이스가 지켜요. 이 구분은 아무렇지 않은 학문적 차이처럼 들리다가, 어느 날 갑자기 그렇지 않게 돼요.

그룹이 실제로 공유할 수 있는 것

분리는 그 자체를 위한 고립이 아니에요. 그룹 전체에서 공유할 가치가 있는 것들은 의도적으로 공유되고, 대부분은 지루한 것들인데 — 바로 그게 맞아요. 지루한 것들이 곧 중복 비용이 발생하는 곳이니까요:

• 실행하고 업데이트할 설치 하나. 배포 하나, 관리할 자격 증명 한 세트, 패치를 유지할 대상 하나.
• 서로 다른 모자를 쓰는 한 팀. 한 사람이 여러 회사에서 일할 수는 있어요. 하지만 물어보지 않은 쿼리를 통해 두 회사를 동시에 볼 수는 없어요.
• 한 세트의 습관. 리드를 배정하는 방식, 메모를 작성하는 방식, 작업이 청구서에 이르는 방식 — 한 번 배워서 어디서나 적용하니, 온보딩이 아침 한 번 정도로 짧아져요.
• castomo 패밀리와의 하나의 관계. 그 아래 castomAPI, 같은 계정, 같은 커넥터 — 중요한 곳에서는 회사별로 구성돼요.

그룹이 항상 두 번째로 묻는 질문

"전체에 걸쳐 보고서를 만들 수 있나요?" 네 — 누수 경계의 부작용이 아니라, 그룹 자체의 관점에서 의도적이고 명시적으로 가능해요. 이 구분이 설계의 전부예요: 경계를 넘는 일은 반드시 그 권한을 가진 누군가가 의도적으로 수행한 행위여야 해요. 잘못된 식별자가 우연히 해내는 일이 되어서는 안 돼요.

그리고 세 번째로 묻는 질문: "브랜드 하나를 매각하면 어떻게 되나요?" 데이터베이스가 지키는 경계는 깨끗한 사본을 꺼낼 수 있는 경계이기도 해요. 우연이 아니에요 — 분리와 이식성은 서로 다른 회의에서 본 같은 속성이에요.