AI·에이전트 파이프라인 연동
AI·에이전트가 코드·스펙을 생성하는 흐름에서, 득팩이 어디에 끼워질 수 있는지 정리한 문서입니다.
에이전트와 역할을 나누고, 스키마·계약은 득팩이 담당하게 할 때의 연동 포인트를 소개합니다.
1. 에이전트가 할 수 없는 일(또는 잘 못하는 일)
에이전트는 스펙 초안·비즈니스 로직·코드 초안을 만드는 데는 강하지만, 아래는 보장하기 어렵거나 한 번에 맞추기 어렵습니다. 그래서 이 부분은 전문 도구(득팩) 가 담당하는 편이 안전합니다.
| 에이전트가 하기 어려운 것 |
이유 |
| 결정론적 출력 |
같은 스키마에 대해 실행마다 동일한 코드·바이트 레이아웃을 보장하기 어렵다. 생성할 때마다 필드 순서·이름·스타일이 달라질 수 있음. |
| 와이어·프로토콜 호환 |
Protobuf·Binary/Compact 등 표준에 맞는 바이트 호환을 유지하려면 스펙대로의 직렬화가 필요하다. 에이전트가 생성한 직렬화만으로는 필드 ID·인코딩이 어긋날 수 있음. |
| 다언어·다플랫폼 동시 정합성 |
C#·C++·TypeScript·Unity·서버가 같은 스키마에서 나온 타입을 쓰려면, 한 번의 정의에서 다언어를 내는 파이프라인이 낫다. 에이전트가 언어별로 따로 생성하면 필드 누락·타입 불일치 위험이 큼. |
| 빌드·CI 재현성 |
동일 IDL → 동일 산출물이어야 빌드 캐시·CI가 안정적이다. 에이전트 출력은 재현이 보장되지 않아 “같은 스키마인데 빌드 결과가 달라짐” 문제가 생길 수 있음. |
| 런타임 스키마·검증 |
GetSchema() 처럼 런타임에 스키마 메타를 내놓고 검증·문서화·에이전트 컨텍스트로 쓰는 것은 코드젠·런타임 라이브러리가 한 세트로 담당하는 편이 안정적. 에이전트가 만든 코드만으로는 메타·버전이 흩어지기 쉬움. |
| 레거시·기존 스펙과의 정합성 |
이미 돌아가는 Protobuf·OpenAPI·레거시 스펙과 필드 ID·바이트를 맞추는 건 코드젠 도구(득팩) 로 검증하는 편이 낫다. 에이전트는 바이트 호환까지 보장하기 어렵다. |
→ 정리: 에이전트는 “무엇을 전송할지(스펙 초안)”를 만드는 데 유리하고, “그걸 어떤 바이트로·어떤 타입으로·어떤 언어에 맞춰 낼지”는 결정론적 도구가 하는 편이 안전합니다. 그래서 득팩이 필요한 이유가 분명해집니다.
2. 그래서 필요한 이유(보강)
- 계약·스키마를 “한 번 정의 → 결정론적 다출력”으로 고정해 주는 레이어가 있으면, 에이전트는 그 결과물(타입·스키마)을 전제로 로직만 생성하면 되어 할루시네이션·불일치가 줄어듭니다.
- 에이전트가 스키마를 생성·수정해도, “실행 가능한 타입·직렬화·다언어 코드”로 바꿔 주는 건 전문 도구(득팩)가 하는 편이 안전합니다. 에이전트는 그 도구를 도구로 호출하면 됩니다.
- 기존 시스템(Protobuf·서버·Unity 클라이언트·메타 테이블)과 바이트·타입 수준으로 맞추려면 “동일 스키마 → 동일 생성 규칙”이 필수입니다. IDL → 코드젠 파이프라인(득팩) 이 담당하는 편이 안전합니다.
3. 역할 분리 — 에이전트 vs 득팩
| 주체 |
담당 |
| 에이전트(AI) |
자연어·요구사항 → 스펙·스키마 초안·비즈니스 로직·코드 생성. 출력이 실행마다 달라질 수 있음. |
| 득팩(DeukPack) |
스키마·IDL → 결정론적 코드·직렬화·검증. 동일 입력이면 동일 출력. |
→ 에이전트가 스키마/IDL을 생성·수정해도, “그걸 실행 가능한 타입·직렬화·다언어 코드로 바꿔 주는” 건 득팩이 하면, 에이전트 할루시네이션·불일치를 줄일 수 있습니다. 위 §1을 득팩이 담당하고, 에이전트는 스펙 초안·로직에만 집중하게 하는 구조입니다.
4. AI 파이프라인에서 엮을 수 있는 부분
4.1 입력 — 에이전트 출력을 득팩 입력으로
| 연동 포인트 |
설명 |
| .deuk / .proto / .thrift 파일 |
에이전트가 생성·수정한 IDL을 득팩에 넘긴다. 파싱·AST·코드젠은 득팩이 수행. |
| OpenAPI / JSON Schema |
에이전트가 만든 OpenAPI 스펙·JSON Schema를 득팩 임포트로 AST에 넣고, 동일 파이프라인에서 C#/C++/TS 등 생성. |
| 스키마 JSON |
(구현 여부에 따라) 스키마 객체·JSON을 직접 넣어서 코드·직렬화 생성. |
4.2 호출 방식 — 에이전트가 득팩을 “도구”로 쓸 때
| 방식 |
설명 |
| Node/TypeScript API |
import { DeukPack } from 'deukpack' 후 parseFiles(), generateCode() 등 호출. 에이전트가 제어하는 스크립트에서 사용. |
| CLI·빌드 스크립트 |
프로젝트에 연동된 빌드 스크립트를 에이전트가 실행만 하도록 지시. (에이전트 = 오케스트레이션, 득팩 = 실행.) |
| 향후 HTTP/API |
IDL·코드젠 SaaS/에디션에서 REST API로 “파일 업로드 → 코드 생성”을 제공하면, 에이전트가 HTTP 호출로 연동. |
4.3 출력 — 득팩이 내놓는 것
| 출력 |
에이전트 파이프라인에서 쓰는 법 |
| 생성 코드(C#/C++/TS/JS) |
에이전트가 이 타입을 사용하는 로직만 생성. 직렬화·타입 정의는 득팩이 고정. |
| GetSchema() / 스키마 메타 |
런타임에서 스키마를 읽어 검증·문서화·에이전트에게 컨텍스트로 넘길 수 있음. |
| 직렬화/역직렬화 |
바이너리·JSON 등 일관된 포맷으로 메시지 주고받기. 에이전트가 생성한 “로직”은 이 포맷을 사용하기만 하면 됨. |
5. 정리 — 한눈에
| 구분 |
내용 |
| 입력 |
에이전트가 만든 .deuk / .proto / .thrift / OpenAPI / JSON Schema → 득팩 parse·import → AST. |
| 호출 |
Node API(DeukPack 인스턴스) 또는 CLI·빌드 스크립트 실행. (향후 REST API 가능.) |
| 출력 |
결정론적 코드·직렬화·GetSchema() → 에이전트는 “이 타입/스키마를 쓰는 로직”만 생성. |
| 가치 |
계약·타입·직렬화를 한 곳(득팩)에서 고정 → 에이전트는 비즈니스 로직·스펙 초안에만 집중. |
6. 관련 안내