포지셔닝·타깃¶
득팩(DeukPack)의 제품 포지션과 타깃을 요약합니다. 이 사이트(deukpack.app)는 브랜드 컨셉 목적으로 제품을 소개하며, 무료·바로 적용 가능한 코어 라이브러리를 npm·GitHub에서 제공합니다.
포지션¶
IDL·스키마 정의, 코드 생성, 직렬화·프로토콜, 메타·테이블, 스프레드시트·에디터 연동을한 스택으로 제공합니다.- Protobuf·OpenAPI·CSV·JSON·DB·레거시 .thrift 등
기존 정의를 그대로가져와점진적 통합이 가능합니다. 게임·서비스·REST·메신저에서 패킷·메타·기획 테이블·에디터·Unity까지한 툴체인으로 다룰 수 있습니다.서버 연동·실시간 게임 연동에서 동일 스키마·프로토콜로 클라이언트-서버를 연결할 수 있습니다.
대체 불가능한 아키텍처 (Why DeukPack?)¶
시장의 기존 직렬화 솔루션들과 비교했을 때, 득팩은 AI 파이프라인과 비대칭적 유연성(서버 유연성 + 클라이언트 엄격성) 관점에서 독보적인 구조를 가집니다.
| 대체제 (통신 포맷) | 장점 | 득팩(DeukPack) 대비 한계점 (AI 자동화 관점) |
|---|---|---|
| Google Protobuf | 메이저 표준, 다양한 언어 지원 | 코딩(생성)이 경직되어 있습니다. 서버/JS 환경에서 필드를 동적으로 빼거나 조작하려면 보일러플레이트가 너무 많습니다. AI 에이전트가 단일 IDL로 다양한 Subset 문서를 동적 생성하기 어렵습니다. |
FlatBuffers (Google)** | C# 관점에서 Zero-Alloc의 끝판왕 |최악의 Builder 패턴.** JS/TS 환경에서 FlatBuffer를 조립하려면 트리의 리프(Leaf) 노드부터 역순으로 오프셋을 계산하며 조립해야 합니다. AI 에이전트는 이 오프셋 조립 로직을 스스로 작성하지 못합니다. |
||
| MessagePack / JSON | 극강의 유연함, 스키마 프리 | 클라이언트에서 타입(Type)을 보장할 수 없습니다. AI가 { "id": 1 } 대신 { "Id": "1" } 로 응답하는 순간, Unity C# Update() 루틴이 치명적인 런타임 에러를 뿜어냅니다. |
💡 요약: 득팩은 이 세 가지 한계를 돌파했습니다. "JSON/MessagePack처럼 JS나 AI 환경에서 유연하고 편안하게 던지면, FlatBuffers처럼 강력하게 읽어내되(Zero-Alloc 최적화), Protobuf처럼 단일 명세서(IDL)로 전사를 통제합니다." 이것이 AI 시대에 득팩이 대체 불가능한 이유입니다.
🎯 득팩(DeukPack)만의 독보적 3대 무기 (제품 스펙)¶
이론적 개념이 아닌, 실제 소스코드(Runtime) 레벨에 내장되어 있는 대체 불가 스펙은 다음과 같습니다.
- 객체 재사용과 '복사 없는 오버라이드' (
Write(oprot, fieldIds, overrides)) - Protobuf/Thrift의 한계: 특정 필드를 제외하거나 덮어씌워야 할 때(Subset/Override), 무조건 새로운 DTO 인스턴스를 메모리에 할당(
new)하고 일일이 필드를 복사해야 합니다. DeukPack의 필살기:득팩이 생성한 C# 객체는할당 없이 단일 인스턴스로 수백 가지의 변형 직렬화를 수행할 수 있습니다.Write()함수 호출 시점의 변형만 감안하므로, 게임 서버가 100명의 유저에게 시야 밖의 정보를 마스킹(Masking)해서 보낼 때 가비지가 전혀 발생하지 않습니다.- 클래스가 필요 없는 순수 JSON(POJO) 직접 처리 (JS/TS 엔진)
- Protobuf의 한계: JS 환경에서도
new Root.Message()와 같이 지루한 클래스 인스턴스화 또는 느린 리플렉션 무버블(FromObject)이 강제됩니다. - DeukPack의 필살기: 득팩 TS/JS 엔진은 단순한 스크립트 객체(
{ id: 1 })를 곧바로 삼킵니다. AI가 생성한 동적 JSON 응답을 즉시 바이트스트림으로 찍어누르는 데 그 어떤 Builder 패턴의 한계나 무거운 래퍼(Wrapper) 오버헤드가 없습니다. - 단순 명세를 넘어선 'AI 지식 그래프 레포지토리' (
.deuk파일) - Protobuf의 한계: 네트워크를 건너기 위한 1차원적 바이트 규약에 불과합니다. 컨텍스트가 결여되어 있습니다.
- DeukPack의 필살기: 득팩의
.deuk파일은extends(다단 상속),tablelink(DB 테이블 참조 메타데이터), 강력한 제약 조건을 한 몸에 품고 있습니다. 즉, 단순 프로토콜이 아닌 AI(LLM)가 우리 프로젝트 전체의 '데이터 관계성(ERD)'을 완벽하게 이해하게 만드는 RAG용 시맨틱 베이스 역할을 동시에 수행합니다.
타깃¶
| 대상 | 설명 |
|---|---|
| 자체 서버·전용 프로토콜을 쓰는 팀 | 기존 IDL·OpenAPI·DB와 메타·테이블·스프레드시트를 한 툴체인으로 쓰고 싶은 경우. |
| Unity·클라이언트에 메타·테이블을 적용하는 팀 | 정의·메타 → 코드·스키마 → Unity 검증·로드 파이프라인이 필요한 경우. |
| 기존 레거시 형태를 유지하면서 최적화를 하고 싶은 팀 | 한 빌드에서 .deuk·.proto·.thrift·OpenAPI·CSV·JSON·DB 혼합 사용으로 점진적 전환. |
| 손쉽게 데이터 구성을 하지만 미래적으로 확장성을 열어두고 싶은 팀 | IDL·스키마·메타를 한 곳에서 정의하고, 필요 시 프로토콜·DB·툴을 단계적으로 확장. |
| 작게 시작하지만 미래가능성도 같이 확보하고 싶은 팀 | CSV·JSON·스프레드시트로 시작해 IDL·OpenAPI·DB까지 점진적으로 확장 가능. |
| (소규모) 인원·리소스가 적어 단일 툴체인으로 패킷·메타를 통일하고 싶은 팀 | IDL·스키마·메타를 한 스택에서 관리해 빌드·배포 부담을 줄이고 싶은 경우. |
| (소규모) 프로토타입·MVP 단계에서 CSV·스프레드시트만으로 메타를 빠르게 쓰고 싶은 팀 | 스키마 추론·헤더 생성으로 곧바로 코드·검증과 연결하고, 나중에 IDL로 승격 가능. |
| (중규모) 서버·클라이언트·기획이 나뉘어 있어 스키마·IDL을 한 곳에서 공유하고 싶은 팀 | 한 번 정의한 스키마로 C#/C++/TS/JS 코드·메타·Unity·서버가 동기화되도록 하고 싶은 경우. |
| (중규모) 기존 IDL을 유지한 채 메타·에디터·Unity 연동을 추가하려는 팀 | 레거시 정의는 그대로 두고, 메타 테이블·에디터 파이프라인만 득팩으로 통합. |
| (대규모) 멀티 프로젝트·멀티 스택에서 레거시와 신규를 하나의 정의 소스로 통합하려는 팀 | .deuk·.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로 구현·리스크를 줄이고 싶은 경우. |
상세 타깃·시장 구분은 제품군 개요를 참고하세요.