Teamver 판매전략 및 Customization 전략
대리점(Partner) 주도 · On-Premise 커스터마이징 · ISO/IEC 26550 (SSPL) 기반 제품 구조
1Executive Summary (요약)
Teamver는 대화 + 파일 + AI + 결과물 생성을 하나로 연결하는 AI 기반 팀 협업 워크스페이스이다. 본 문서는 이 제품을 대리점(Partner) 주도의 On-Premise 커스터마이징 판매 모델로 확장하기 위한 전략을 정의한다.
- 벤더는 고객사 커스터마이징을 직접 수행하지 않는다. 벤더는 "커스터마이징이 가능한 제품 구조"를 만든다.
- 대리점이 커스터마이징을 수행한다. 대리점은
Configuration→SDK→API3계층 메커니즘으로 고객 요구를 해결한다. - 부족한 변경점만 벤더에 요청하고, 벤더는 3계층 중 적절한 영역에 기능을 추가 개발한다.
- 이론적 기반은 ISO/IEC 26550 (SSPL)의 Domain Engineering / Application Engineering 분리 및 Variability Management이다.
★핵심 강조 — 공통성·가변성 분리와 "지속적 업그레이드"
이 절은 본 제품 기획의 가장 중요한 원칙이며, 다른 모든 설계 결정이 이 원칙에 종속된다.
★.1 문제 정의 — "고객사마다 형상은 달라진다"
On-premise + 대리점 커스터마이징 모델에서는 고객사별로 제품 형상이 서로 달라진다. 고객 A와 고객 B는 브랜딩, 인증 방식, AI 모델, 연동 시스템, 추가 기능이 모두 다르다. 여기서 흔히 빠지는 함정:
- 고객사마다 소스를 통째로 복제(fork)해서 고치면 → 각 고객 형상이 코어와 고립(divergence)된다.
- 그 결과 벤더가 코어를 업그레이드해도 이미 커스터마이징된 고객사에는 반영 불가(업그레이드 단절).
- 시간이 갈수록 고객사 수 × 버전 조합만큼 유지보수 부담이 폭발한다.
➡ 결론: 커스터마이징과 업그레이드가 양립하려면, 처음부터 "달라지는 부분"과 "달라지지 않는 부분"을 구조적으로 분리해야 한다.
★.2 핵심 원리 — 형상을 두 부분으로 분리한다
ISO/IEC 26550(SSPL)의 근간 개념인 Commonality(공통성) vs Variability(가변성)를 그대로 적용한다.
| 구분 | SSPL 용어 | 소유·관리 주체 | 업그레이드 |
|---|---|---|---|
| 달라지지 않는 부분 | Common Assets (공통 코어/플랫폼) | 벤더 | 벤더가 지속적으로 업그레이드 |
| 달라지는 부분 | Variability (변이점 바인딩 = 고객별 형상) | 대리점 고객 | 코어와 분리되어 보존 |
★.3 지속적 업그레이드가 가능한 이유 (그리고 조건)
공통 코어와 고객별 변이가 분리되어 있고, 명시적 인터페이스(계약)로만 연결되어 있으면, 벤더는 코어만 새 버전으로 교체하고 고객별 변이는 그대로 재결합(re-binding)할 수 있다.
★.4 연동(Re-binding)을 보장하기 위한 제품 기획 요건
| # | 요건 | 내용 |
|---|---|---|
| 1 | 변이점의 명시적 인터페이스화(계약) | 변이는 오직 벤더가 공개한 확장 지점(Extension Point)=계약으로만 코어에 결합. 코어 소스 직접 수정(fork) 원천 차단. |
| 2 | 확장 레이어의 물리적 격리 | 공통 코어와 고객 변이를 분리된 레이어/디렉터리/패키지로 배치. 업그레이드 시 코어만 교체. |
| 3 | 인터페이스 하위 호환(SemVer) | vN+1이 vN 확장 인터페이스를 깨지 않아야 재연동 가능. 불가피 변경은 Deprecation 유예·마이그레이션 가이드. |
| 4 | 형상 명세의 데이터화 | 고객 변이 바인딩을 형상 명세서(설정값·확장 목록·연동 정의)로 데이터화·보존. "새 코어 + 저장 명세 재적용"으로 재현. |
| 5 | 업그레이드 자동 회귀 검증 | 변이점 계약에 대한 호환성 테스트 스위트로 "새 코어 + 고객 변이" 재연동 결과를 자동 검증. |
"공통은 벤더가 계속 업그레이드하고, 가변은 고객별로 보존한다. 둘을 잇는 명시적 인터페이스(계약)만 유지되면, 커스터마이징된 모든 고객사가 코어 업그레이드를 지속적으로 받을 수 있다." — Teamver 제품 구조 설계의 제1원칙
2Teamver 제품 분석
2.1 제품 개요
| 구분 | 내용 |
|---|---|
| 제품 정의 | 팀을 위한 AI 기반 협업 워크스페이스 (Smarter & Faster) |
| 핵심 가치 | 대화·파일·AI·결과물 생성을 하나의 업무 맥락으로 연결 |
| 차별점 | Slack(대화)+Notion(문서)+Drive(파일)+ChatGPT(AI)로 분리된 문제를 단일 워크스페이스로 통합 |
| 배포 형태 | Desktop(macOS/Windows/Linux), Android, iOS + (본 전략) On-Premise 구축 |
| AI 모델 | OpenAI GPT, Anthropic Claude, Google Gemini 등 전환 사용 |
2.2 핵심 기능 구조 — 커스터마이징 변이점 후보
3Customization 3계층 모델 — Configuration / SDK / API
대리점이 커스터마이징을 수행하는 3가지 메커니즘. 요청이 오면 하위 계층(Config)부터 상위 계층(API)으로 순차 검토한다(비용·난이도 오름차순).
| 계층 | 수행 주체 | 방식 | 난이도 | 재배포 | 대표 용도 |
|---|---|---|---|---|---|
| Configuration | 대리점(비개발자 가능) | 관리 메뉴 설정 | 낮음 | 불필요 | 브랜딩·정책·권한 |
| SDK | 대리점 개발자 | 정의된 파일/모듈 수정·추가 | 중간 | 부분 필요 | UI 확장·AI App·에이전트 |
| API | 대리점 SI | 외부 연동 개발 | 높음 | 별도 시스템 | 연동·자동화 |
Configuration 설정형
관리자 콘솔에서 설정만으로 즉시 반영(재빌드 불필요)
- 브랜딩/UI: 로고·테마·앱명·로케일·타임존
- 워크스페이스 정책: 채널·DM·파일 업로드·보존기간
- 권한/RBAC: 역할·권한 매트릭스·부서 상속
- AI 정책: 모델 선택·사용량 한도·프롬프트·가드레일
- 저장소: 용량 쿼터·스토리지 경로·외부 공유
- 보안: SSO·2FA·IP 화이트리스트·감사로그
- 알림/온보딩: 알림 규칙·기본 채널 참여
SDK 코드 확장형
정의된 확장 지점(Extension Point) 구현 — 대리점 개발자
- UI 확장: 메뉴·탭·사이드패널·위젯·슬래시 커맨드
- AI App/Agent: 신규 AI App·에이전트 워크플로우·프롬프트 패키지·RAG 파이프라인
- Connector/Provider: 커스텀 LLM·인증 IdP·드라이브 소스·파일 뷰어
- 이벤트/자동화: 이벤트 훅·커스텀 봇·리포트 확장
원칙: 변이점은 명시적 인터페이스로만 노출, 코어 은닉, 하위호환(SemVer) 보장
API 연동형
외부 시스템 연동 · 대리점 SI 개발
- 인증/계정: OAuth2·API Key·SAML/OIDC·LDAP·SCIM
- Core Resource: User/Workspace/Channel/Message·Drive·Search
- Messaging/Bot: 메시지 송수신·봇
- AI/Inference: AI Chat 호출·AI Apps 생성
- Event/Webhook: 이벤트 구독·스트림
- Admin/Governance: 사용자·사용량·감사로그·쿼터
- Integration: ERP·그룹웨어·전자결재·CRM·BI
4ISO/IEC 26550 (SSPL) 기반 제품 구조 철학
4.1 개요 — 두 개의 생명주기 분리
ISO/IEC 26550은 소프트웨어·시스템 제품라인 공학 및 관리를 위한 참조 모델이다. 개별 제품을 매번 새로 만드는 대신, 공통 플랫폼(재사용 자산)과 변이(Variability)를 체계적으로 관리하여 다수 파생 제품을 효율 생산한다.
4.2 SSPL 시리즈와 Teamver 매핑
| 표준 | 주제 | Teamver 전략에서의 역할 |
|---|---|---|
| ISO/IEC 26550 | 참조 모델 | 벤더-대리점-고객 역할 분리의 근간 |
| ISO/IEC 26551 | 요구공학 | 고객 요구를 공통/변이 요구로 분류 |
| ISO/IEC 26552 | 아키텍처 설계 | Config/SDK/API 변이점 설계 |
| ISO/IEC 26553 | 실현(Realization) | SDK 확장 지점·컴포넌트 구현 |
| ISO/IEC 26554 | 검증·확인(V&V) | 대리점 커스터마이징 결과 검증 |
| ISO/IEC 26555 | 기술 관리 | 변이성·자산·형상 관리(핵심) |
| ISO/IEC 26556 | 조직 관리 | 벤더/대리점 조직·책임 경계 |
| ISO/IEC 26557~9 | 애자일·추출·메트릭 | 점진적 변이점 확대·성과 측정 |
4.3 Variability Management — 3계층과 바인딩 시점
- Variation Point(변이점): 달라질 수 있는 지점 (인증 방식, AI 모델, UI 테마, 연동 대상)
- Variant(변이체): 변이점에 바인딩되는 선택지 (SAML/OIDC, GPT/Claude)
- Binding Time(바인딩 시점): Configuration=설정 시점 / SDK=빌드 시점 / API=통합 시점
4.4 왜 이 구조인가 (전략적 이유)
확장성
벤더 인력이 모든 고객 커스터마이징을 감당 불가 → 대리점 위임으로 병렬 확장
품질/안정성
코어 미변경, 정의된 변이점만 사용 → 업그레이드 호환성 유지
책임 경계
벤더=변이점 제공, 대리점=바인딩 → 장애·유지보수 책임 분리
재사용성 한 대리점이 만든 SDK 확장/연동을 자산화하여 타 고객사에 재사용 가능.
5판매전략 (대리점 중심 On-Premise 모델)
5.1 역할 분담 (RACI)
| 활동 | 벤더 | 대리점 | 고객사 |
|---|---|---|---|
| 코어 제품/변이점 개발 | R/A | C | I |
| 신규 변이점 추가 개발 | R/A | C(요청) | I |
| Configuration 설정 | C | R/A | C |
| SDK 확장 개발 | C(가이드) | R/A | I |
| API 연동/SI 개발 | C | R/A | C |
| 요구사항 정의 | I | C/R | R/A |
| 검수/운영 | I | R | A |
R=수행, A=승인, C=협의, I=통보
5.2 커스터마이징 요청 처리 프로세스
5.3 대리점 파트너십 모델
- 파트너 등급제: Registered → Certified → Premier (기술 인증·매출 기준)
- 기술 인증: Configuration 관리자 / SDK 개발자 / API 연동 엔지니어 트랙별 교육·자격
- 레퍼런스 자산 공유: 대리점 개발 SDK 확장·커넥터를 파트너 마켓플레이스에 등록·재판매
- 수익 모델: 라이선스 마진 + 커스터마이징 SI 수익 + 유지보수(MA) 수익
5.4 On-Premise 구축 전제
- 폐쇄망/사내망 배포(데이터 주권·보안 대응)
- 사내 LLM 또는 프라이빗 API 게이트웨이 연동(SDK Provider 어댑터)
- 워크스페이스·스토리지·AI 사용량을 고객 인프라 내에서 통제
6Customization 전략 상세 (실행 지침)
6.1 계층 선택 원칙
"가능한 한 낮은 계층에서 해결한다."
Configuration으로 되면 SDK를 쓰지 않고, SDK로 되면 API/SI를 쓰지 않는다. (비용·리스크 최소화)
Configuration으로 되면 SDK를 쓰지 않고, SDK로 되면 API/SI를 쓰지 않는다. (비용·리스크 최소화)
6.2 변이점 카탈로그 관리 (벤더 책임)
벤더는 제공 가능한 변이점을 Variation Point Catalog로 문서화하여 대리점에 공개한다.
| 변이점 ID | 도메인 | 계층 | 설명 | 바인딩 시점 |
|---|---|---|---|---|
VP-BRAND-01 | UI | Config | 로고·테마·앱명 | 설정 |
VP-AUTH-01 | 보안 | ConfigSDK | SSO/IdP 방식 | 설정/빌드 |
VP-AI-MODEL-01 | AI | ConfigSDK | LLM Provider 선택·추가 | 설정/빌드 |
VP-AIAPP-01 | AI Apps | SDK | 신규 AI App 추가 | 빌드 |
VP-UI-EXT-01 | UI | SDK | 메뉴·위젯·커맨드 | 빌드 |
VP-CONNECTOR-01 | 연동 | SDKAPI | 외부 데이터 소스 | 빌드/통합 |
VP-INTEG-01 | 연동 | API | ERP/그룹웨어/결재 | 통합 |
VP-EVENT-01 | 자동화 | API | Webhook 이벤트 | 통합 |
6.3 형상·버전 관리 (ISO/IEC 26555 준수)
- 코어 버전과 대리점 확장 버전을 분리 관리(SemVer)
- 변이점 인터페이스 하위 호환 보장, Deprecation 정책 명시
- 대리점 확장은 격리된 확장 레이어에 배치(코어 소스 미변경)
- 업그레이드 회귀 테스트 스위트를 벤더가 제공
6.4 품질·검증 (ISO/IEC 26554 준수)
- 대리점 커스터마이징 산출물 검증 체크리스트 제공
- SDK 확장 샌드박스·테스트 하네스 제공
- API 연동 스테이징 환경 및 계약 테스트(Contract Test)
6.5 단계별 로드맵
7요약 결론
- Teamver를 대리점 주도 On-Premise 커스터마이징 제품으로 전환하는 핵심은, 제품 자체가 Configuration / SDK / API 3계층 변이 메커니즘을 내장하는 것이다.
- 이론적 근거는 ISO/IEC 26550 (SSPL)의 Domain Engineering(벤더) / Application Engineering(대리점·고객) 분리와 Variability Management이다.
- 벤더는 변이점을 만들고, 대리점은 변이점을 바인딩하며, 고객사는 요구를 제기한다. 벤더는 고객 커스터마이징을 직접 수행하지 않고, 부족한 변이점만 추가 개발한다.
- 이를 통해 벤더 인력 병목 없이 확장 가능하고, 업그레이드 호환성과 품질을 유지하며, 대리점 SI 수익과 자산 재사용이 가능한 지속가능한 판매 생태계를 구축한다.
공통은 벤더가 업그레이드하고, 가변은 고객별로 보존하며, 둘을 잇는 계약(인터페이스)이 유지되는 한 — 모든 고객사는 커스터마이징을 유지한 채 지속적으로 진화한다.