[백엔드] BE 개발자 없이 시작 느슨한 JSONB 계약 컨텍스트

부제: AI↔백엔드 계약을 맺을 사람이 없어서 어떤 구조든 받게 만든 이야기

시스템은 백엔드(BE)가 채워 보내는 사용자 정보를 받아 대화 컨텍스트에 넣는다.
그 정보를 어떤 형태로 주고받을지가 문제였다.
그리고 이 결정은 기술이 아니라 조직 현실이 정했다.

계약할 상대가 없었다

프로젝트를 시작할 때 CTO도, 백엔드 개발자도 없었다.
AI 서버와 백엔드 사이에 "무슨 필드를 어떤 스키마로 주고받자"는 계약을 맺을 상대가 없었다는 뜻이다.

엄격한 스키마를 정하려면 양쪽이 합의하고, 백엔드가 그에 맞춰 개발해야 한다.
그럴 사람이 없으니 그 길은 애초에 막혀 있었다.

어떤 구조든 받는다

그래서 방향을 뒤집었다.
"스키마를 맞춘다"가 아니라 "어떤 구조가 와도 추가 개발 없이 받는다"로.

최소한의 뼈대만 정했다.
사용자 정보를 세 섹션으로 나눴다 — 기본 정보, 디바이스, 커스텀.
각 섹션 안은 JSONB로 자유 입력이다. 백엔드가 무엇을 어떻게 채워 넣든 AI가 받는다.

덕분에 백엔드가 채운 걸 그대로 컨텍스트에 주입할 수 있게 됐다.
새 필드가 생겼다고 스키마를 맞추는 개발을 매번 하지 않아도 된다.
사람이 없어서 택한 길인데, 결과적으로 유연함을 얻었다.

넣을 것과 넣으면 안 될 것을 가른다

다만 전부 컨텍스트에 넣으면 안 됐다.
계산에만 쓰거나 모델에 보이면 안 되는 값이 있다. 타임존이나 민감한 설정 같은 것이다.

그래서 이런 건 컨텍스트에 안 들어가는 별도 settings 필드로 분리했다.
"모델에게 보여줄 자유 정보(세 섹션)"와 "시스템이 쓸 설정(settings)"을 나눈 것이다.
느슨하게 다 받되, 모델에 노출할 것과 아닌 것의 경계만은 분명히 했다.

정리

• 프로젝트 초기에 CTO·백엔드 개발자가 없어 AI↔BE 데이터 계약을 협상할 수 없었다
• 엄격한 스키마 대신 "어떤 구조든 추가 개발 없이 받는다"로 방향 전환 — JSONB 세 섹션(기본·디바이스·커스텀) 자유 입력
• 덕분에 백엔드가 채운 걸 스키마 조율 없이 그대로 컨텍스트에 주입
• 단, 모델에 넣으면 안 되는 값(타임존·설정)은 별도 settings 필드로 분리

계약을 협상할 상대가 없는 초기엔, 엄격한 스키마 대신 "어떤 구조든 받는" 느슨한 계약이 오히려 굴러간다.
유연함을 얻는 대신, 모델에 보여줄 것과 시스템 설정의 경계만은 필드로 분명히 가른다.