Structured Output
3줄 요약
- Structured Output은 모델 응답을 JSON schema 같은 구조로 제한해 서버가 안전하게 파싱하도록 돕는다.
- 그래도 refusal, partial output, schema validation 실패, provider error는 남으므로 실패 경로가 필요하다.
- 백엔드에서는 모델 응답을 DTO처럼 검증하고, 파싱 실패를 정상적인 오류 유형으로 다뤄야 한다.
핵심 정리
- 자연어 답변은 사람이 읽기 좋지만 서버 후속 로직에는 불안정하다.
- 분류, 추출, 요약 저장, 워크플로우 분기에는 structured output이 적합하다.
- schema는 모델에게 기대 형식을 알려주고, 서버 validation은 실제 결과를 검증한다.
- schema를 강제해도 정책 거절이나 중단 응답은 구조가 다를 수 있다.
- validation failure rate는 운영 지표로 봐야 한다.
헷갈리는 지점
- schema를 지정하면 파싱 실패가 사라진다고 생각하기 쉽다.
- 핵심은 모델 호출 전체에는 refusal, timeout, max token, provider error가 남는다는 점이다.
- 파싱 실패를 예외가 아니라 설계된 실패로 처리한다.
- JSON으로 답하라고 프롬프트에 쓰면 structured output이라고 생각하기 쉽다.
- 핵심은 자연어 지시와 API 수준 schema 제약은 다르다는 점이다.
확인 질문
- structured output이 필요한 대표 상황은 무엇인가?
- 모델 결과를 서버가 후속 로직, DB 저장, 분류, tool 인자로 사용할 때다.
- structured output을 써도 validation이 필요한 이유는 무엇인가?
- 거절, 중단, schema 불일치, provider 오류가 여전히 발생할 수 있기 때문이다.
3줄 요약
- Tool Calling은 모델이 외부 함수나 API를 호출해야 할 상황과 인자를 구조화해 제안하는 기능이다.
- 실제 실행 권한과 side effect 통제는 모델이 아니라 서버가 가져야 한다.
- read-only tool과 write tool은 retry, 권한, audit, idempotency 기준이 완전히 다르다.
핵심 정리
- Tool calling은 모델이 “이 도구를 이 인자로 호출하라”고 구조화해 반환하게 하는 방식이다.
- tool schema는 모델이 사용할 API 문서와 같다.
- 모델이 tool 호출을 제안해도 서버는 권한, 입력 검증, 정책, idempotency를 확인해야 한다.
- write tool은 승인, audit log, idempotency key 없이 연결하면 위험하다.
- tool 결과는 다시 모델 context로 들어가므로 prompt injection 위험이 있다.
헷갈리는 지점
- 모델이 tool을 호출한다고 해서 서버 검증이 필요 없다고 생각하기 쉽다.
- 핵심은 모델은 보안 경계가 아니라는 점이다.
- 실제 실행은 서버 정책을 통과해야 한다.
- tool calling과 MCP를 같은 것으로 보기 쉽다.
- 핵심은 tool calling은 모델 API 기능이고 MCP는 도구와 리소스를 제공하는 프로토콜이라는 점이다.
확인 질문
- tool calling에서 서버가 반드시 해야 하는 검증은 무엇인가?
- 권한, 입력 schema, side effect 위험, idempotency, rate limit, audit log다.
- write tool이 read-only tool보다 위험한 이유는 무엇인가?
- 외부 상태 변경과 중복 실행 사고를 만들 수 있기 때문이다.
DTO 검증과 실패 처리
3줄 요약
- 모델 출력은 외부 입력처럼 취급하고 DTO validation을 반드시 거쳐야 한다.
- validation failure, refusal, no tool call, invalid tool args는 서로 다른 실패 유형이다.
- 실패 유형을 구분해야 retry, fallback, 사용자 메시지, 장애 알림을 올바르게 결정할 수 있다.
핵심 정리
- 모델이 만든 JSON도 신뢰할 수 없는 외부 입력이다.
- DTO validation은 타입, 필수 필드, enum, 길이, 범위를 확인한다.
- invalid JSON과 business invalid는 다르게 처리한다.
- refusal은 파싱 실패가 아니라 정책적 응답일 수 있다.
- validation 실패율은 prompt/schema/model 변경의 회귀 신호다.
헷갈리는 지점
- 모델이 내부 시스템 안에서 호출되므로 신뢰해도 된다고 생각하기 쉽다.
- 핵심은 모델 출력도 외부 provider에서 온 데이터라는 점이다.
- 사용자 입력과 같은 수준의 검증이 필요하다.
- validation 실패는 예외적인 버그라고 생각하기 쉽다.
- 핵심은 AI 시스템에서는 정상적으로 예상해야 하는 실패 경로라는 점이다.
확인 질문
- 모델 출력을 외부 입력처럼 봐야 하는 이유는 무엇인가?
- provider와 모델이 생성한 값이며 형식, 내용, 정책 실패가 항상 안전하다고 보장할 수 없기 때문이다.
- validation failure를 metric으로 봐야 하는 이유는 무엇인가?
- prompt, model, schema 변경으로 품질 회귀가 발생했는지 알 수 있기 때문이다.