프롬프트에 검증 가능한 출력 형식 정의하기

작성자: AILesson6 분 소요테스트::ChatGPT검토일: 2026-08-28

빠른 답변

모호한 출력 요구를 필드, 유형, 상태, 제약 조건과 검증 규칙으로 전환합니다. 제공할 내용: 프롬프트 과제와 후속 용도, 현재 출력 요구 사항과 예시, 형식과 검증 제약 조건. 예상 결과: 스키마, 사람이 읽을 수 있는 예시, 빈 상태와 검증 점검을 갖춘 출력 계약.

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

프롬프트 과제와 후속 용도현재 출력 요구 사항과 예시형식과 검증 제약 조건

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

프롬프트 과제를 위한 검증 가능한 출력 계약을 설계하세요.

입력, 변환, 독자·시스템, 의사결정과 실패 시 결과:
[task]

현재 형식 문구, 원하는 예시, 거부된 출력과 실제 사용 필드:
[output]

직렬화, 파서 제한, 길이, 로캘, 순서, 필수·선택 필드와 검토:
[constraints]

후속 용도를 지원하는 가장 작은 출력 구조를 정의하세요. 모든 필드에 이름, 목적, 유형, 필수 여부, 허용 값 또는 패턴, 단위, 증거 연결, 알 수 없음·빈 값 표현과 필드 간 규칙을 지정하세요. 데이터와 설명을 분리하고 기계 처리용 필드와 검토자 메모를 구분하세요. 서로 호환되지 않는 형식, 장식용 섹션 또는 파싱할 필드 안의 산문을 요구하지 마세요. 필요한 경우 결정론적 순서를 포함하세요. null, 빈 문자열, 0, false와 ‘unknown’을 같은 뜻으로 혼용하지 마세요. 출력 설계 근거, 정식 또는 표 형식 스키마, 정확한 프롬프트 조항, 유효한 완전 예시, 유효한 빈 값·알 수 없음 예시, 이유를 포함한 잘못된 예시, 검증 체크리스트 또는 의사 코드, 기계적으로 검증할 수 없어 사람의 검토가 필요한 필드를 반환하세요.

Playground에서 사용해 보기

기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

프롬프트 과제와 후속 용도: 회의 기록에서 명시적인 약속을 추출합니다. 워크플로가 결과를 작업 검토 화면으로 가져오지만 작업을 자동으로 만들지는 않습니다. 검토자에게는 행동, 담당자, 기한, 상태와 증거 위치가 필요합니다. 담당자나 날짜가 없다는 사실이 드러나야 합니다. 제안은 약속으로 취급하지 않습니다. 담당자를 잘못 지정하거나 기한을 지어내면 책임 소재에 위험이 생깁니다.
현재 출력 요구 사항과 예시: 현재 지침에는 ‘깔끔한 구조화 목록을 주세요’라고만 되어 있습니다. 좋은 출력은 약속마다 한 행을 사용하고 타임스탬프를 포함했습니다. 거부된 출력은 요약과 글머리 기호를 섞고, 기한에 ‘soon’을 사용했으며, 담당자를 알 수 없을 때 owner를 생략했습니다. 검토자는 priority나 sentiment를 사용하지 않습니다.
형식과 검증 제약 조건: 엄격한 JSON이며 Markdown 코드 펜스나 추가 산문은 허용하지 않습니다. 파서는 UTF-8 JSON 배열을 받습니다. 정확한 달력 날짜가 명시된 경우에만 ISO 8601 날짜를 사용합니다. 스냅샷을 위해 필수 키 순서를 고정합니다. status 값은 proposed, confirmed, completed, cancelled입니다. evidence에는 speaker와 timestamp가 포함됩니다. 약속 분류와 인물의 동일성은 사람이 검토합니다.

예시 출력

설계: 명시적인 약속 하나당 배열 항목 하나를 사용하며 요약, priority와 sentiment는 제외합니다. 담당자나 날짜를 알 수 없으면 누락 자체에 의미가 있으므로 null을 사용하고, 빈 문자열은 유효하지 않습니다. ‘Soon’은 evidence에 남기되 due_date에는 입력할 수 없습니다.

스키마: action은 필수이며 비어 있지 않은 string, owner는 필수 키이며 string|null, due_date는 필수 키이며 YYYY-MM-DD 형식의 string|null, status는 필수 enum입니다. evidence는 필수 object이며 비어 있지 않은 string인 speaker, HH:MM:SS 형식의 timestamp, 200자 이하의 비어 있지 않은 string인 excerpt를 포함합니다. 키 순서는 action, owner, due_date, status, evidence입니다. 필드 간 규칙: completed 상태에는 완료가 언급되었다는 evidence가 필요하고, evidence에 정확한 날짜가 없으면 due_date는 null이어야 합니다.

정확한 프롬프트 조항: “UTF-8 JSON 배열만 반환하세요. 명시적인 약속 하나를 객체 하나로 만들고 키는 action, owner, due_date, status, evidence 순서로 배치하세요. 담당자나 정확한 기한이 언급되지 않았다면 null을 사용하고, 키를 생략하거나 상대적 표현을 날짜로 변환하지 마세요. status는 proposed, confirmed, completed, cancelled 중 하나여야 합니다. evidence에는 speaker, HH:MM:SS 형식의 timestamp와 200자 이하의 출처 excerpt를 포함하세요. 명시적인 약속이 없으면 []를 반환하세요. 산문이나 Markdown을 추가하지 마세요.”

유효한 예시: [{"action":"수정된 예산 보내기","owner":"Nora","due_date":null,"status":"confirmed","evidence":{"speaker":"Nora","timestamp":"00:14:22","excerpt":"수정된 예산을 곧 보내겠습니다."} }]. 유효한 빈 결과: []. 잘못된 예시: due_date가 "soon"이면 ISO 규칙에 어긋나고, owner를 생략하면 필수 키 규칙에 어긋납니다. 사람이 excerpt가 실제 약속인지, ‘Nora’가 올바른 인물인지 계속 검토해야 합니다.

효과가 있는 이유

1
유형이 지정된 필드와 명시적인 빈 상태는 출력 품질을 관찰 가능한 규칙으로 바꿉니다.
2
필드 간 검증은 형식은 잘 갖춰졌지만 내부적으로 일관되지 않은 출력을 찾아냅니다.

결과 확인

모든 필드가 실제 후속 의사결정, 표시 또는 점검에 쓰이나요?
알 수 없음, 누락, 해당 없음과 0 값이 모호하지 않게 구분되나요?
기계적 점검과 사람의 판단 책임을 구분할 수 있나요?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

“프롬프트에 검증 가능한 출력 형식 정의하기”를 사용하기 전에 무엇을 준비해야 하나요?

“프롬프트에 검증 가능한 출력 형식 정의하기”를 사용하려면 프롬프트 과제와 후속 용도, 현재 출력 요구 사항과 예시, 형식과 검증 제약 조건을 준비하세요. 확인할 수 있는 정보로만 자리표시자를 바꾸세요. 세부 사항을 모른다면 모델에 추론을 맡기지 말고 그 불확실성을 명시적으로 유지하세요.

“프롬프트에 검증 가능한 출력 형식 정의하기”의 결과는 언제 사용할 준비가 되지 않은 것인가요?

제공된 근거를 바탕으로 명시된 결과물인 ‘스키마, 사람이 읽을 수 있는 예시, 빈 상태와 검증 점검을 갖춘 출력 계약’을 아직 제공하지 못했거나, 해결되지 않은 가정, 누락된 승인 또는 지어낸 세부 사항에 의존한다면 사용할 준비가 되지 않은 것입니다. 점검 항목을 공개 기준으로 삼아 근거 없는 결과물을 다듬는 대신 원본 입력을 수정하거나 이름과 권한이 명확한 검토자를 지정하세요.

“프롬프트에 검증 가능한 출력 형식 정의하기”에 대해 테스트 기록이 있는 AI 도구는 무엇인가요?

2026-08-28 기준으로 “프롬프트에 검증 가능한 출력 형식 정의하기”의 공개 테스트 기록에는 ChatGPT가 기재되어 있습니다. 이는 실행 기록이 있다는 뜻일 뿐, 이후 제품 버전에서의 호환성이나 동일한 결과를 보장하지 않습니다. 다른 도구나 버전을 사용할 때는 모든 제약 조건을 명시하고 사용 전에 결과 점검을 다시 수행하세요.

더 많은 탐색 방법