AI 답변을 스프레드시트나 업무 도구에 바로 넣고 싶다면, 내용을 잘 써 달라는 요청과 출력 형식을 지키라는 규칙을 분리해 작성해야 합니다. 상담 메모에서 문의 내용·긴급도·누락 정보를 뽑거나 여러 문서를 같은 항목으로 정리할 때 JSON이 유용합니다. 다만 서비스와 모델에 따라 JSON 또는 스키마 기반 출력 지원 범위가 다르므로, 처음에는 프롬프트로 형식을 지정하고 결과를 검증하는 방식으로 시작하는 것이 안전합니다.
목차
먼저 정할 입력과 출력 조건
AI에 원문을 넣기 전에 결과를 어디에 사용할지부터 정하세요. 사람이 읽을 보고서인지, 스프레드시트 행인지, 자동화 도구의 입력값인지에 따라 필요한 구조가 달라집니다. 자동으로 넘길수록 필드명과 자료형을 바꾸지 않는 것이 중요합니다.
- 필드명: 예를 들어 request, urgency, missing_info처럼 고정합니다. 나중에 연동할 예정이라면 한글과 영문 중 하나를 정해 계속 사용하세요.
- 자료형: 제목과 문의 내용은 문자열, 누락 정보는 배열, 완료 여부는 참·거짓처럼 정합니다.
- 허용값: 긴급도는 ‘높음·보통·낮음’처럼 선택지를 제한합니다. 판단할 수 없을 때 사용할 null도 미리 정해야 합니다.
- 정보 부족 처리: 빈 문자열, null, 빈 배열 중 어떤 값을 쓸지 결정합니다. 필드마다 규칙이 달라지면 누락이 늘어날 수 있으므로 단순하게 유지하세요.
원문에 없는 사실을 추정하지 말라는 규칙도 반드시 포함하세요. 형식이 올바른 JSON이어도 이름, 날짜, 긴급도 같은 값이 틀리면 업무 데이터로 사용할 수 없습니다.
프롬프트로 JSON 출력 만들기
- 역할과 작업을 한 문장으로 씁니다. “아래 상담 메모에서 문의 내용을 분류하세요”처럼 처리할 대상을 명확히 합니다.
- 필드별 규칙을 적습니다. 각 키의 자료형과 허용값, 정보가 없을 때의 값을 함께 지정합니다.
- 출력 범위를 제한합니다. “유효한 JSON 객체만 출력하고 설명, 인사말, 마크다운 코드 블록은 넣지 마세요”라고 명시합니다.
- 원문 보존 규칙을 추가합니다. “원문에 없는 사실, 날짜, 연락처를 만들지 마세요”처럼 금지할 추정을 구체적으로 적습니다.
- 가상 예시로 시험합니다. 예시를 넣을 때는 실제 입력이 아닌 가상 데이터라고 표시해 결과값과 혼동하지 않게 합니다.
예를 들어 다음과 같이 요청할 수 있습니다. “상담 메모에서 문의 내용을 추출하세요. 원문에 없는 사실은 만들지 마세요. request는 문자열, urgency는 ‘높음·보통·낮음’ 또는 null, missing_info는 문자열 배열입니다. 판단할 수 없는 값은 null 또는 빈 배열로 처리하세요. 유효한 JSON 객체만 출력하고 설명과 마크다운 코드 블록은 넣지 마세요.”
결과를 저장하기 전 검증하는 순서
AI 응답을 곧바로 업무 도구에 붙여 넣지 말고 다음 순서로 확인하세요. 특히 자동화에 연결할 때는 내용 검토와 형식 검사를 별도로 진행해야 합니다.
- 응답의 첫 글자와 마지막 글자에 설명이나 불필요한 문장이 없는지 확인합니다.
- 중괄호와 대괄호가 올바르게 닫혔는지, 키와 문자열에 큰따옴표가 사용됐는지 살핍니다.
- 필수 키가 모두 있는지 확인하고, 값이 정한 자료형과 일치하는지 검사합니다.
- 긴급도처럼 허용값을 제한한 항목에 다른 표현이 들어오지 않았는지 확인합니다.
- 원문과 대조해 날짜, 이름, 요청 내용이 추가되거나 바뀌지 않았는지 검토합니다.
파싱 오류가 났을 때
쉼표나 따옴표가 빠져 해석되지 않는다면 잘못된 응답을 임의로 고쳐 저장하지 마세요. 오류 메시지와 해당 응답을 함께 보내고 “내용은 바꾸지 말고 JSON 문법만 수정해 다시 출력하세요”라고 요청하는 편이 안전합니다. 같은 문제가 반복되면 필드 수를 줄인 테스트 입력으로 원인을 좁힌 뒤 규칙을 다시 추가하세요.
값이 이상하거나 누락됐을 때
JSON 문법이 맞아도 분류 기준이 모호하면 값이 흔들릴 수 있습니다. ‘높음’의 조건을 업무 규칙에 맞춰 정의하고, 해당하지 않으면 null을 쓰도록 수정하세요. 누락된 정보는 AI가 추측해 채우지 말고 missing_info 같은 별도 필드에 기록하게 하는 것이 좋습니다.
반복 업무와 서비스별 기능 차이
건수가 적고 사람이 결과를 확인한다면 프롬프트 템플릿만으로도 시작할 수 있습니다. 같은 결과를 계속 시스템에 보내거나 형식 오류가 업무를 중단시킨다면, 사용 중인 서비스에 구조화 출력·스키마·JSON 응답 설정이 있는지 공식 도움말과 설정 화면에서 확인하세요. 기능의 이름, 지원 모델, 입력 길이 제한은 서비스와 모델 버전에 따라 달라질 수 있으므로 일반적인 메뉴 위치를 단정해서는 안 됩니다.
웹 브라우저와 모바일 앱은 제공되는 설정 항목이나 표시 방식이 다를 수 있습니다. 찾는 기능이 보이지 않으면 계정 유형, 선택한 모델, 앱 업데이트 여부를 확인하고, 같은 서비스의 웹 설정 화면이나 공식 도움말에서 지원 조건을 확인하세요. 기능이 없는 경우에는 프롬프트 출력 후 별도의 JSON 파서나 업무 도구의 유효성 검사 단계로 보완할 수 있습니다.
- 템플릿에 필드명, 자료형, 허용값, null 처리 규칙을 고정합니다.
- 입력 여러 건에는 번호나 고유 식별자를 붙여 결과가 섞이지 않게 합니다.
- 정보가 충분한 사례와 부족한 사례를 각각 시험합니다.
- 검증을 통과한 결과만 스프레드시트나 자동화 단계로 보냅니다.
개인정보·비용·데이터 손실 주의사항
실명, 연락처, 상담 내용, 계약 정보는 꼭 필요한 부분만 입력하세요. 가능하면 식별자를 가리거나 가명으로 바꾸고, 조직 계정에서는 입력·보관·접근 권한 정책을 확인해야 합니다. 대화 삭제 기능이 있더라도 이미 내려받았거나 다른 도구로 전송한 사본까지 자동으로 삭제된다고 볼 수는 없습니다.
API나 자동화 기능을 사용하면 서비스의 사용량 기준에 따라 비용이나 한도가 적용될 수 있습니다. 가격과 무료 한도는 바뀔 수 있으므로 결제 화면과 공식 요금 안내에서 직접 확인하고, 본격적으로 연결하기 전에 소량으로 시험하세요. 원본 메모는 AI 결과로 덮어쓰지 말고 별도 보관해 잘못 분류했을 때 다시 대조할 수 있게 하세요.
실행 후 최종 점검 목록
- 필수 필드와 필드명이 처음 정한 규칙과 같은가요?
- 각 값의 자료형과 허용 범위가 맞나요?
- 판단할 수 없는 정보가 추정되어 채워지지 않았나요?
- JSON 밖에 설명이나 코드 블록이 붙지 않았나요?
- 원문과 결과를 대조했으며, 중요한 데이터는 사람이 승인했나요?
- 개인정보를 최소화했고 저장·삭제·접근 범위를 확인했나요?
- 자동화 연결 전 비용, 사용량 한도, 원본 복구 방법을 점검했나요?
핵심은 JSON이라는 형식 자체보다 고정된 규칙과 검증 절차입니다. 작은 표본으로 누락·오분류 사례를 먼저 확인한 뒤 템플릿과 자동화를 확대하면, 형식 오류와 잘못된 업무 데이터의 유입을 함께 줄일 수 있습니다.