출력 포맷팅

LLM의 답이 JSON, 마크다운, 정해진 템플릿처럼 원하는 형식으로 나오게 하는 기법이다. 사람이 읽을 글은 프롬프트에 형식을 적어 주면 충분하다. 프로그램이 받아 처리할 데이터는 형식이 한 번만 어긋나도 파싱이 깨지므로 구조화 출력처럼 형식을 강제하는 방법을 쓴다.

누가 읽느냐로 방법을 고른다

블로그 초안이나 회의록 요약처럼 사람이 읽는 결과는 프롬프트에 "제목은 ##, 핵심은 표로"처럼 형식을 적고 예시를 하나 보여 주면 된다. 형식이 조금 흔들려도 읽는 데는 문제가 없다.

상품 정보 추출이나 문의 분류처럼 코드가 결과를 받아 DB에 넣거나 다음 단계로 넘긴다면 API의 구조화 출력 기능을 쓴다. 가능하면 JSON 스키마로 필드 이름과 타입까지 고정한다.

스키마 정하기 → 넘기기 → 검증하기

먼저 받을 데이터의 모양을 정한다. {"name": "", "price": 0, "category": ""}처럼 필드와 타입을 정하고, category처럼 값이 정해진 필드는 허용 값을 목록으로 적는다.

다음으로 그 스키마를 API에 넘긴다. OpenAI API는 response_format 옵션으로 JSON 모드나 스키마를 지정한다. Claude는 구조화 출력이나 도구 정의에 스키마를 넣어 같은 결과를 얻는다. 파이썬에서는 Pydantic 모델을 정의하고 instructor 같은 라이브러리를 쓰면 스키마 변환과 검증, 실패했을 때 재시도까지 맡길 수 있다.

마지막으로 받은 결과를 코드에서 한 번 더 검증한다. 형식을 강제하는 기능이 없는 모델이라면, 검증에 실패했을 때 오류 내용을 붙여 다시 요청하는 흐름을 만들어 둔다.

형식이 맞아도 내용은 틀릴 수 있다

스키마가 보장하는 건 모양뿐이다. price 칸에 숫자가 들어왔다고 해서 그 숫자가 맞다는 뜻은 아니므로, 중요한 값은 원문과 대조해 확인해야 한다.

형식을 너무 빡빡하게 걸면 답의 질이 떨어질 수 있다. 깊게 생각해야 하는 문제라면 근거를 담는 필드를 앞에, 결론 필드를 뒤에 두는 편이 낫다. 마크다운은 채팅 화면에서는 보기 좋지만 문자 메시지처럼 렌더링되지 않는 곳에서는 기호가 그대로 보인다. 그러니 출력이 어디에 표시될지 보고 형식을 정한다.

데이터 추출과 에이전트에서 가장 많이 쓴다

가장 흔한 쓰임은 LLM의 답을 코드가 바로 받아 쓰게 하는 것이다. 사람이 읽는 화면에서는 가볍게 프롬프트로 형식만 정리하고, 프로그램이 받는 단계에서는 스키마로 모양을 고정한다.