포지셔닝·타깃
득팩(DeukPack)의 제품 포지션과 타깃을 요약합니다.
포지션
- IDL·스키마 정의, 코드 생성, 직렬화·프로토콜, 메타·테이블, 스프레드시트·에디터 연동을 한 스택으로 제공합니다.
- Thrift·Protobuf·OpenAPI·CSV·JSON·DB 등 기존 정의를 그대로 가져와 점진적 통합이 가능합니다.
- 게임·서비스·REST·메신저에서 패킷·메타·기획 테이블·에디터·Unity까지 한 툴체인으로 다룰 수 있습니다.
타깃
| 대상 | 설명 |
|---|---|
| 자체 서버·전용 프로토콜을 쓰는 팀 | 기존 IDL·OpenAPI·DB와 메타·테이블·스프레드시트를 한 툴체인으로 쓰고 싶은 경우. |
| Unity·클라이언트에 메타·테이블을 적용하는 팀 | 정의·메타 → 코드·스키마 → Unity 검증·로드 파이프라인이 필요한 경우. |
| 기존 레거시 형태를 유지하면서 최적화를 하고 싶은 팀 | 한 빌드에서 .proto·.thrift·.deuk·OpenAPI·CSV·JSON·DB 혼합 사용으로 점진적 전환. |
| 손쉽게 데이터 구성을 하지만 미래적으로 확장성을 열어두고 싶은 팀 | IDL·스키마·메타를 한 곳에서 정의하고, 필요 시 프로토콜·DB·툴을 단계적으로 확장. |
| 작게 시작하지만 미래가능성도 같이 확보하고 싶은 팀 | CSV·JSON·스프레드시트로 시작해 IDL·OpenAPI·DB까지 점진적으로 확장 가능. |
| (소규모) 인원·리소스가 적어 단일 툴체인으로 패킷·메타를 통일하고 싶은 팀 | IDL·스키마·메타를 한 스택에서 관리해 빌드·배포 부담을 줄이고 싶은 경우. |
| (소규모) 프로토타입·MVP 단계에서 CSV·스프레드시트만으로 메타를 빠르게 쓰고 싶은 팀 | 스키마 추론·헤더 생성으로 곧바로 코드·검증과 연결하고, 나중에 IDL로 승격 가능. |
| (중규모) 서버·클라이언트·기획이 나뉘어 있어 스키마·IDL을 한 곳에서 공유하고 싶은 팀 | 한 번 정의한 스키마로 C#/C++/TS/JS 코드·메타·Unity·서버가 동기화되도록 하고 싶은 경우. |
| (중규모) 기존 IDL을 유지한 채 메타·에디터·Unity 연동을 추가하려는 팀 | 레거시 정의는 그대로 두고, 메타 테이블·에디터 파이프라인만 득팩으로 통합. |
| (대규모) 멀티 프로젝트·멀티 스택에서 레거시와 신규를 하나의 정의 소스로 통합하려는 팀 | .proto·.thrift·OpenAPI·CSV·DB를 한 빌드에서 혼합하고, 점진적 마이그레이션·표준화. |
| (대규모) OpenAPI·DB·여러 런타임까지 표준화된 프로토콜·메타 파이프라인이 필요한 팀 | 코드 생성·직렬화·메타·검증을 하나의 툴체인으로 두고, 팀·프로젝트 간 재사용. |
| (게임 규모) 하이퍼캐주얼·캐주얼·미드코어·코어·MMORPG 등 5가지 규모의 게임 팀 | 기존 시스템·테이블·스키마를 손쉽게 구조화하고, 데이터 관리·코드 추가 구현 및 리스크를 최소화할 수 있음. |
| (REST API) REST API·웹 서비스를 쓰는 팀 | OpenAPI·JSON Schema로 API 스펙을 정의하고, 코드 생성·직렬화·메타와 한 파이프라인으로 연동하고 싶은 경우. |
| (REST API) 기존 REST API의 DTO 구조를 최소 변경으로 최적화·유연성 확장하고 싶은 팀 | OpenAPI·JSON Schema 임포트 또는 IDL로 핵심만 재정의 후, 기존 계약(JSON·경로)은 유지한 채 점진 전환·REST 전용 DTO 생성으로 리스크 최소화. (검토: 가능) |
| (메신저) 채팅·메신저·실시간 메시징 서비스를 다루는 팀 | 패킷·메시지 스키마를 IDL로 정의하고, Binary/Compact/JSON 직렬화·msgId·ProtocolRegistry로 구현·리스크를 줄이고 싶은 경우. |
상세 타깃·시장 구분은 제품군 개요를 참고하세요.