Quick Reference

출력 계약은 글을 예쁘게 보이게 하는 장식이 아니라, 무엇을 반환하고 모르는 정보는 어떻게 표시하며 어떤 증거가 있어야 끝나는지를 정합니다. 사람이 읽을 답변에는 Markdown과 자연어 규칙을, 프로그램이 읽을 값에는 JSON schema와 별도 검증을 사용합니다.

| 결과를 쓸 곳 | 먼저 정할 것 | 적합한 형태 | 완료를 확인할 곳 | | --- | --- | --- | | 빠르게 읽는 답변 | 결론 위치, 길이, 목록 규칙 | 짧은 문단·목록 | 사람이 내용과 원문을 읽기 | | 선택지 비교 | 고정 비교 축과 누락 처리 | 표 | 비교 축과 source 대조 | | 수행 절차 | 순서와 중단 조건 | 번호 목록 | 각 단계의 실행 결과 | | 다른 프로그램 입력 | 필드, 타입, 필수 여부 | JSON schema | schema validator와 도메인 규칙 |

목적: 팀이 1분 안에 선택지를 비교한다.
출력: 결론 2문장 -> 비교표 1개 -> 확인이 필요한 항목
표 열: 선택지 / 비용 / 장점 / 제약 / 적합한 경우
제약: 각 셀은 2문장 이하, 자료에 없는 값은 "미확인"
금지: 표 밖에 새 사실 추가, 항목을 임의로 합치기
완료: 세 후보 모두에 근거 또는 "미확인"이 있고, 추천 이유가 분리돼 있다.
검증: 가격과 정책은 공식 원문에서 다시 확인한다.

사람용 형식과 구조화된 출력

Markdown은 사람이 빠르게 읽을 답변의 표현 계약입니다. 독립적으로 찾아야 할 단위에는 heading, 순서 없는 핵심에는 bullet, 순서가 바뀌면 결과가 달라지는 작업에는 번호 목록, 둘 이상의 대상을 같은 축으로 볼 때만 표, 실행하거나 복사할 값에는 language label이 있는 code fence를 고릅니다. 설명 하나를 표로 강제하거나, 실행 환경 없는 명령을 code fence에 넣으면 오히려 빠른 참조가 깨집니다.

표로 정리해 줘만으로는 열의 의미, 행 수, 셀 길이, 누락값 처리가 열려 있습니다. 자연어 답변에는 무슨 형식으로, 무엇을 빠뜨리지 말고, 모르면 어떻게 표시할지를 함께 적습니다. 형식 이름만 나열하지 말고 표를 생략할 조건도 남기면 불필요한 표가 줄어듭니다.

주제: 배포 후보 세 개
독자: 운영 담당자
출력 계약:
1. 첫 문장에 추천과 이유 두 개
2. 비교 대상이 둘 이상일 때만 "비용 / 위험 / 적합한 경우" 표 사용
3. 실행 명령은 bash code fence와 실행 위치를 함께 표시
4. 근거가 없는 값은 "확인 필요"로 표시
5. JSON은 요구하지 않으며 사람이 읽을 Markdown으로 작성

Markdown 안에 JSON 예시를 넣었다고 machine-readable response가 되지는 않습니다. 프로그램이 값을 읽어 외부 동작을 한다면 API Structured Outputs와 JSON schema를 사용하고, schema를 통과한 뒤에도 값 범위, 권한, 도메인 규칙을 검증합니다. 반대로 사람이 읽을 보고서라면 schema보다 section 순서, 근거, line length가 더 중요한 계약입니다.

누락 처리와 실제 완료 증거

출력 구조에는 필수 항목과 누락 처리를 같이 적습니다. 입력 자료에 없는 사실을 채우지 말고 확인 불가, 가정, 추가로 필요한 자료 중 어느 상태인지 보이게 합니다. 대상 독자나 문체처럼 비용이 낮은 빈칸은 가정을 밝힌 초안을 제시할 수 있지만, 가격·정책·날짜·권한·외부 변경은 추측하지 않고 원문 또는 승인을 요청해야 합니다.

우선순위:
1. 제공한 사실을 바꾸지 않는다.
2. 필수 항목 5개를 모두 포함한다.
3. 비교가 필요한 항목에만 표를 쓴다.
4. 600자 안에 정리한다.

길이를 맞추려면 표현을 줄이되 필수 사실과 "미확인" 표시는 지우지 마.

답변에 section과 표가 모두 있어도 업무가 끝난 것은 아닙니다. 코드 수정은 diff·test log·실행 환경, 자료 조사는 원문과 주장 대응, 외부 작업은 대상 서비스 상태와 승인 기록, 데이터 분석은 source data·filter·계산 단위를 별도로 확인합니다. 이 증거는 응답 형식의 일부가 아니라 실제 상태를 닫는 근거입니다.

형식과 내용을 함께 검증하기

형식이 맞아도 내용이 맞는 것은 아닙니다. 목록 수, heading, 표 열, JSON field처럼 기계적으로 확인할 항목과 사실성·논리·출처처럼 사람이 또는 별도 검사로 확인할 항목을 나눕니다. renderer에서는 heading 계층, 표의 가로 폭, code fence의 복사 가능성, 명령의 escape와 line wrap을 확인합니다. API 결과는 parser·schema validator·invalid response 처리와 server-side authorization까지 확인합니다.

답을 탐색하는 단계에서는 형식을 너무 빨리 고정하지 말고 선택지와 근거를 먼저 받습니다. 운영 보고, 데이터 추출, 반복 문서처럼 다음 사람이 같은 순서로 읽어야 하는 결과는 처음부터 형식을 고정합니다. 어느 경우든 형식은 내용의 성격을 돕는 수단이며, 사실성·권한·외부 실행을 보장하지 않습니다.