이 가이드는 짧은 명령어 하나로 끝나지 않습니다. 필요한 자료를 정리하고, AI가 추측하지 않게 경계를 주고, 출력 내용을 원문과 대조해 실제로 사용할 수 있는 결과로 만드는 전체 과정을 설명합니다.
예시 안내 본문의 입력과 기대 결과는 절차를 설명하기 위해 구성한 예시입니다. 실제 수행 결과나 성과를 주장하지 않으며, 중요한 업무에는 원자료와 담당자의 최종 확인이 필요합니다.
- 열 이름과 허용 범주, 빈값 처리법을 먼저 고정합니다.
- AI 출력은 행 ID·범주·근거·검토 상태가 있는 구조로 제한합니다.
- 정답을 가린 시험표와 사람 검토 대기열을 통과한 뒤에만 일괄 적용합니다.
완성 결과물
누구에게 필요하고, 누구에게는 맞지 않을까
이런 분께 맞습니다
- 문의·설문·콘텐츠 목록을 반복해서 같은 범주로 나누는 운영자
- 스프레드시트 원본을 손대지 않고 분류 결과를 별도 열로 붙이려는 실무자
- 코딩 전에 입력·출력·예외·검수 규칙을 확정하려는 기획자
이 경우에는 멈추세요
- 진단·신용·채용처럼 잘못된 분류가 사람의 권리에 직접 영향을 주는 자동 의사결정
- 개인정보나 영업비밀을 외부 AI에 입력해도 되는지 확인하지 않은 업무
- 범주 정의 없이 AI가 알아서 의미 있는 그룹을 만들기를 기대하는 경우
시작 전에 준비할 것
도구를 열기 전에 입력 자료와 최종 확인자를 정하면, 그럴듯하지만 틀린 결과를 줄일 수 있습니다.
- 식별정보를 제거한 CSV 복사본과 원본 보관 위치
- 행마다 중복되지 않는 record_id 열
- 허용 범주와 범주별 포함·제외 예시
- 사람이 판정한 소규모 기준 정답표
- 최종 검토자와 반려 결과를 처리할 규칙
단계별 과정
CSV 구조와 분류 단위를 먼저 고정합니다
왜 필요한가 — 행의 경계나 열의 뜻이 흔들리면 같은 내용도 다른 입력으로 읽혀 결과를 재현하기 어렵습니다.
원본 파일은 읽기 전용으로 보관하고 분류용 복사본에는 record_id, 분류에 필요한 텍스트 열, 보조 맥락 열만 남깁니다. 쉼표·줄바꿈·따옴표가 포함된 셀은 CSV 파서로 읽고, 화면에서 보이는 줄 수로 행을 세지 않습니다.
각 열에 데이터형, 빈값의 뜻, 최대 길이, 여러 값이 들어올 때의 구분자를 적습니다. 주민번호·연락처처럼 분류에 필요 없는 값은 삭제하거나 내부 시스템에서만 찾을 수 있는 표식으로 바꿉니다.
열: ticket_id, channel, message, customer_email 원본 행: T-1042,웹,"배송 상자는 왔는데 컵 한 개가 없습니다",person@example.com 목적: 문의 유형 분류
분류 입력 열: record_id=T-1042 | channel=웹 | text=배송 상자는 왔는데 컵 한 개가 없습니다 제외 열: customer_email 원본 상태: 변경 없음
범주 사전과 보류 조건을 함께 만듭니다
왜 필요한가 — 범주 이름만 나열하면 서로 겹치는 사례에서 모델과 검토자가 다른 기준을 적용합니다.
범주마다 한 줄 정의, 포함 신호, 제외 신호, 자주 헷갈리는 이웃 범주를 기록합니다. 하나의 행에 여러 요청이 있으면 복수 분류를 허용할지 대표 범주 하나만 고를지도 정합니다.
정보 부족, 범주 충돌, 새 유형 발견, 위험 표현이 있는 행은 억지로 분류하지 않고 검토 필요로 보냅니다. 숫자 확률을 받더라도 보류 기준은 실제 시험 결과를 보고 정하며, 모델이 말한 확률을 정확도의 보증처럼 사용하지 않습니다.
허용 범주 배송: 출고·도착·누락·파손 관련 교환·반품: 수령 후 교환 또는 반품 절차 요청 사용법: 제품 사용 방법 질문 기타: 위 범주에 해당하지 않음 검토 필요: 두 범주가 충돌하거나 정보가 부족함
T-1042 후보=배송 포함 신호=상자는 도착함, 구성품 누락 제외 검토=교환 요청은 아직 없음 보류 조건=누락과 교환 요청이 동시에 있으면 사람 검토
출력 형식을 한 행 단위로 제한합니다
왜 필요한가 — 자유로운 설명문은 CSV에 다시 붙이기 어렵고 원본 행과의 연결도 쉽게 끊깁니다.
출력은 record_id, label, evidence, review_status, reason_for_review 다섯 필드로 고정합니다. evidence에는 입력 문장의 짧은 근거만 담고 새 사실이나 해결책은 쓰지 않게 합니다.
허용 범주 밖의 단어, 누락된 ID, 여러 행을 합친 결과가 나오면 저장하지 않습니다. JSON처럼 구조 검사가 쉬운 중간 형식으로 받은 뒤 유효성 검사를 통과한 값만 결과 CSV로 내보냅니다.
record_id=T-1042 text=배송 상자는 왔는데 컵 한 개가 없습니다 규칙=허용 범주에서만 선택하고 근거는 원문 표현으로 적기
{"record_id":"T-1042","label":"배송","evidence":"상자는 왔는데 컵 한 개가 없습니다","review_status":"자동 후보","reason_for_review":""}정답을 가린 시험표로 실패 유형을 측정합니다
왜 필요한가 — 보기 좋은 몇 건만 확인하면 실제로 자주 틀리는 경계 사례를 찾을 수 없습니다.
정상 사례뿐 아니라 짧은 문장, 오탈자, 두 요청이 섞인 문장, 빈값, 새 유형, 부정 표현을 시험표에 넣습니다. 프롬프트를 다듬을 때 본 개발표와 최종 비교에 쓸 보류표를 분리합니다.
전체 일치율 하나만 보지 말고 범주별 누락, 잘못 붙인 범주, 검토 필요로 안전하게 보낸 비율을 나눠 기록합니다. 틀린 행에는 원인을 범주 정의, 입력 정제, 출력 형식, 모델 판단 중 하나로 표시합니다.
E01 기대=배송 | '택배가 아직 오지 않았어요' E02 기대=검토 필요 | '컵이 깨졌고 환불도 묻고 싶어요' E03 기대=사용법 | '뚜껑 패킹을 어느 방향으로 끼우나요?' E04 기대=검토 필요 | 빈 메시지
시험 결과표: case_id | 기대 범주 | 실제 범주 | 근거 적합 | 검토 상태 | 실패 원인 | 수정 후 재시험 E02 | 검토 필요 | 교환·반품 | 적합 | 실패 | 복수 요청 규칙 미적용 | 필요
자동 반영 대신 검토 대기열로 연결합니다
왜 필요한가 — 분류기가 한 번 틀렸을 때 원본이나 고객 처리 상태까지 바뀌면 복구 비용이 커집니다.
결과 CSV는 원본을 덮지 않고 record_id를 기준으로 옆에 연결합니다. 보류 조건, 구조 오류, 새 범주 후보, 위험 신호가 있는 행은 검토 대기열에 넣고 검토자가 원문과 범주 사전을 함께 보게 합니다.
사람이 고친 결과는 정답표 후보로 저장하되 즉시 학습 데이터로 확정하지 않습니다. 검토일, 검토자, 범주 사전 버전, 프롬프트 버전을 남기고 다음 변경 때 이전 실패 사례가 다시 생기지 않는지 확인합니다.
T-1042 자동 후보=배송 T-1043 자동 후보=검토 필요, 이유=배송 지연과 환불 요청이 함께 있음 범주 사전=v1.2, 프롬프트=v3
검토 대기열 T-1043 | 원문 보기 | 후보 범주 2개 | 보류 이유 | 사람 판정 | 판정 근거 | 검토자 | 검토 시각 적용 규칙: 승인된 행만 결과 테이블에 병합
수정해 쓰는 재사용 입력
중괄호 부분을 자신의 상황으로 바꾸고, 실제 자료를 넣기 전에 개인정보와 공개하면 안 되는 내용을 제거하세요. 결과는 반드시 원문과 대조합니다.
다음 CSV 행을 제공된 범주 사전만 사용해 분류하세요. 입력에 없는 사실을 만들지 말고, 애매하면 반드시 검토 필요로 보내세요.
[범주 사전]
{{범주명 / 정의 / 포함 신호 / 제외 신호}}
[보류 조건]
- 두 범주가 동시에 성립함
- 분류에 필요한 정보가 없음
- 범주 사전에 없는 새 유형임
- 위험 신호가 있음
[입력 행]
record_id: {{ID}}
text: {{비식별 처리한 문장}}
context: {{허용된 보조 맥락}}
[출력 JSON]
{"record_id":"입력 ID","label":"허용 범주 또는 검토 필요","evidence":"원문의 짧은 근거","review_status":"자동 후보 또는 사람 검토","reason_for_review":"보류 이유 또는 빈 문자열"}결과 확인 체크리스트
- 원본 CSV를 읽기 전용으로 보관했다.
- 모든 행에 중복되지 않는 record_id가 있다.
- 셀 안의 쉼표·따옴표·줄바꿈을 파서로 처리한다.
- 분류에 불필요한 개인정보를 제거했다.
- 범주별 포함·제외·충돌 기준을 적었다.
- 검토 필요 상태와 보류 조건을 만들었다.
- 출력 필드와 허용값을 구조 검사한다.
- 근거 문장이 입력 원문에서 확인된다.
- 개발표와 독립된 보류 시험표가 있다.
- 오류를 범주별·원인별로 기록한다.
- 원본을 덮지 않고 승인 결과만 연결한다.
- 범주 사전·프롬프트·검토 이력을 버전으로 남긴다.
자주 막히는 지점과 해결법
RFC 4180 계열 규칙을 지원하는 CSV 파서를 사용하고 행 ID 수를 원본과 대조합니다.
허용 목록 밖의 label은 저장 전에 거부하고 검토 필요로 보냅니다.
사람이 만든 보류 시험표로 오류를 측정하고 업무 위험에 맞는 보류 규칙을 별도로 둡니다.
원본과 분류 결과를 분리하고 record_id로만 연결해 언제든 판정을 되돌릴 수 있게 합니다.
개인정보·저작권·정확성 주의
AI가 자연스럽게 작성했다는 사실은 정확성과 이용 권한을 보장하지 않습니다. 공개하거나 전달하기 전에 아래 항목을 확인하세요.
- 개인정보·고객정보를 외부 AI에 입력하기 전에 조직 정책과 처리 조건을 확인하세요.
- 채용·보험·신용·의료처럼 사람에게 중대한 영향을 주는 분류는 이 절차만으로 자동화하지 마세요.
- CSV 수식으로 해석될 수 있는 값은 스프레드시트에서 열 때 별도의 보안 검토가 필요합니다.
- 범주 비율이 크게 불균형하면 전체 일치율이 높아도 드문 범주를 놓칠 수 있습니다.
- 새 범주와 정책 변경이 생기면 과거 시험표와 범주 사전을 함께 갱신하세요.
- AI 결과는 후보이며 최종 업무 판단과 책임은 승인한 사람이 집니다.
자주 묻는 질문
AI가 표시한 신뢰 점수가 높으면 바로 자동 분류해도 되나요?
권하지 않습니다. 모델이 표시한 점수는 실제 업무 정확도를 보증하지 않습니다. 사람이 만든 보류 시험표에서 범주별 오류와 위험 사례를 측정하고, 허용 가능한 행만 승인 대기열을 거쳐 반영해야 합니다.
시험 행은 몇 개면 충분한가요?
모든 업무에 통하는 고정 숫자는 없습니다. 자주 들어오는 정상 사례뿐 아니라 빈값, 복수 요청, 새 유형, 오탈자와 위험 신호가 포함됐는지 먼저 봐야 합니다. 새 실패 유형이 발견될 때마다 보류 시험표를 늘리는 방식이 안전합니다.
셀에 쉼표나 줄바꿈이 있으면 어떻게 처리하나요?
텍스트를 줄 단위로 자르지 말고 따옴표와 줄바꿈 규칙을 지원하는 CSV 파서로 읽어야 합니다. 불러온 record_id 수와 원본 행 수를 대조해 행이 쪼개지거나 합쳐지지 않았는지도 확인합니다.
운영 중 범주 정의가 바뀌면 기존 결과도 다시 분류해야 하나요?
영향 범위에 따라 다릅니다. 범주 사전 버전을 결과마다 남기고, 바뀐 정의와 관련된 과거 행만 찾아 새 규칙으로 재시험하세요. 원본과 이전 판정은 보존해 변경 전후를 추적할 수 있어야 합니다.
공식 출처와 확인 기준
출처는 각 원자료가 다루는 범위 안에서 참고했습니다. 서비스 화면과 기능은 바뀔 수 있으므로 실제 사용 전 최신 문서를 다시 확인하세요.
수정 이력
2026-08-15 — 작성 및 편집 검수.
이어서 볼 가이드
재생에너지·앱 개발·이커머스를 거치며 배운 AI 활용법
회사 안에서도 저는 계속 ‘새로운 걸 만들어야 하는 역할’에 있었습니다 돌이켜보면 저는 정해진 업무를 오래 반복하기보다, 이미 있는 방식에서 새로운 매출이나 새로운 채널을 만들어야 하는 일을 많이 했습니다. 신세계에서는 MD의 관점에서 상품과 고객을 봤고, SK Networks에서는 온라인 시장이 본격적으로 커지기 시작하던 시기에 새로운 이커머스 사업을 만드는 일을 경험했습니다. 당시에는 지금처럼 브랜드가 온라인 판매를 당연하게 생각하지 […]
프롬프트 버전을 감으로 고르지 않는 평가 도구 설계법
같은 시험 입력과 판정 기준으로 프롬프트 두 버전을 가려 비교하고, 좋아진 사례와 퇴행한 사례를 함께 남기는 평가 도구 명세입니다.