공개 실험을 위해 코딩하는 상인이 만든 가상 회의록이다. 실제 고객, 실제 사업의 의사결정이나 개인정보는 포함하지 않는다.

회의 주제: 소규모 상점용 문의 분류 기능의 시험 운영
회의일: 2026년 9월 24일

기획 담당: 초안에는 9월 30일 공개와 상점 50곳 모집으로 적혀 있습니다. 개발·운영 검토를 듣고 오늘 최종안을 정하겠습니다.
개발 담당: 아직 검증이 남았습니다. 시험 보고서와 되돌리기 코드를 10월 2일 오후 6시까지 제가 제출하겠습니다. 공개는 10월 6일로 미루되 품질 검증을 통과한 경우에만 진행할 수 있습니다.
운영 담당: 인원이 부족하므로 50곳은 받기 어렵습니다. 기존 상점 20곳만 초대하는 방식으로 시작합시다. 공개 모집은 하지 않겠습니다.
기획 담당: 일정은 10월 6일, 품질 검증 통과를 조건으로 확정합니다. 참여 대상도 기존 상점 20곳 초대로 고치겠습니다. 초안의 날짜와 인원은 폐기합니다.

회계 담당: 처음에는 예산 120만 원을 제안했지만 승인액은 부가세 포함 90만 원입니다. 모니터링 도구 6만 원도 그 90만 원 안에 포함돼 있습니다. 도구값을 따로 더하지 마세요.
운영 담당: 시험에 쓸 문의는 담당자가 작성한 가상 자료만 쓰겠습니다. 실고객 문의나 이름, 전화번호를 가져오지 않습니다.
개발 담당: 시험 운영에서 최근 100건 중 잘못 분류된 문의가 3건을 초과하면 자동 분류를 끄고 수동 처리로 되돌립니다. 정확히 3건일 때는 이 중단 조건에 해당하지 않습니다. 이미 저장된 처리 기록은 유지합니다.
기획 담당: 자동 결제와 자동 환불은 이번 범위에서 제외합니다. 문의 분류만 시험하겠습니다.

운영 담당: 주말 지원을 할지는 아직 정하지 못했습니다. 운영 책임자가 9월 28일까지 결정해 알려주기로 했습니다.
기획 담당: 주말 지원은 미확정으로 기록합니다. 평일만 지원한다고 확정해서도 안 됩니다. 방금 합의한 변경 사항을 반영해 담당자에게 공유해 주세요.


부록: 문의 분류 화면의 설계 검토 메모
이 부록은 읽을 분량을 늘리는 공개용 합성 자료다. 회의에서 확정한 일정, 예산, 참여 대상, 중단 조건을 변경하지 않는다.

목록 화면에서는 문의 내용의 시작 부분과 현재 처리 상태를 함께 보여준다. 담당자가 원문을 열기 전에 어느 분류로 들어갔는지 확인할 수 있어야 한다. 분류 이름만 읽어도 작업을 짐작할 수 있도록 추상적인 표현을 피한다. 화면 구성은 검토 단계이며 배포 승인으로 해석하지 않는다.

상세 화면은 원문과 분류 이유를 구분해서 배치한다. 모델이 만든 설명을 고객의 발언처럼 보이게 표시하지 않는다. 사용자가 직접 수정한 분류와 자동으로 제안된 분류도 식별할 수 있어야 한다. 사람이 결과를 확인하는 과정에서 원문의 의미를 바꾸어 기록하지 않도록 편집 경계를 설명한다.

검색 기능은 담당자가 문의의 표현 일부를 기억할 때 다시 찾는 데 쓰인다. 검색 결과가 없으면 조건을 지우거나 다른 표현을 시도할 수 있게 안내한다. 검색창의 예시는 실제 고객 문장에서 가져오지 않고 작성자가 만든 문장을 사용한다. 목록의 정렬 순서가 바뀌더라도 선택한 항목의 상태는 분명히 보여준다.

분류를 수정하는 화면에는 현재 값과 선택 가능한 값을 제공한다. 저장 버튼을 누른 뒤에는 저장 성공 여부를 확인할 수 있어야 한다. 오류가 났을 때 입력 내용이 사라지면 같은 설명을 다시 써야 하므로 입력 상태를 유지한다. 완료 여부를 색상만으로 표시하면 구분하기 어려울 수 있어 글자로도 설명한다.

긴 문의는 줄임 표시와 본문 펼치기를 제공하는 방안을 검토한다. 축약된 문장 때문에 반대 의미로 읽히지 않도록 원문을 열기 쉽게 만든다. 사용자가 확대해 읽을 때도 버튼과 본문이 겹치지 않아야 한다. 표가 넓으면 그 표 안에서만 좌우로 이동하게 하며 페이지 전체를 밀어야 하는 구성은 피한다.

키보드만으로 주요 동작을 수행할 수 있는지 확인한다. 현재 초점이 어디 있는지 보이고, 대화상자를 닫았을 때 원래 버튼으로 돌아갈 수 있어야 한다. 단축키는 이미 브라우저에서 쓰는 동작을 가로채지 않는지 검토한다. 장식용 아이콘의 이름이 반복되어 본문 읽기를 방해하지 않도록 한다.

가상 문의 예시에는 배송 일정 질문, 상품 설명 질문, 안내문 확인 요청처럼 일상적인 범주를 넣는다. 샘플은 모델의 일반 능력을 대표하는 데이터셋이 아니며 화면 작동을 확인하기 위한 자료다. 특정 업체가 실제로 이런 문의를 받았다고 표현하지 않는다. 평가에 쓰는 원문과 화면 시연용 원문은 용도를 구분해 보관한다.

오류 안내는 사용자가 다음에 할 수 있는 행동과 연결한다. 작업이 실패했다는 사실, 다시 시도할 수 있는지, 입력을 고쳐야 하는지를 알려준다. 내부 구현 이름이나 원인을 확인하지 못한 추측을 보여주지 않는다. 담당자에게 전달할 오류 기록에서는 비밀 키와 실제 고객의 원문이 섞이지 않는지 살핀다.

진행 상태가 오래 바뀌지 않으면 사용자는 완료 여부를 알기 어렵다. 요청 중이라는 표시와 취소가 가능한 범위를 명확하게 한다. 이미 저장이 끝난 작업을 취소할 수 있는 것처럼 보이게 하지 않는다. 화면의 상태와 서버에 저장된 상태가 다르면 다시 불러와 확인할 수 있는 경로를 제공한다.

문구 검토에서는 같은 기능에 서로 다른 이름을 쓰는지 확인한다. 목록, 상세, 수정 화면의 용어가 일치해야 이동할 때 혼란이 줄어든다. 설명이 필요한 항목은 입력 가까이에 짧게 두고 긴 운영 문서는 별도 링크로 연결한다. 독자가 먼저 알아야 할 내용을 하단 주의사항에만 숨기지 않는다.

검토 기록에는 확인한 화면과 발견한 문제, 수정 후 다시 확인한 결과를 적는다. 확인하지 않은 장치까지 문제가 없다고 적지 않는다. 보고서에는 관측한 범위와 재현 절차를 남겨 다른 담당자가 같은 화면에서 확인할 수 있게 한다. 이 부록의 권고는 회의 본문의 결정 사항을 추가하거나 변경하는 승인이 아니다.
