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

개발

jykim23 2026. 7. 14. 12:07

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

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

계약할 상대가 없었다

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

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

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

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

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

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

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

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