답변이 달렸다고 해결된 건 아니잖아

답변이 왔다는 것과 문제가 풀렸다는 건 달라

가상 질문 게시판에 “답변이 달리면 해결로 바꾸고 닫아 달라”는 요청이 들어왔다고 해보자. 질문은 “내보내기 파일의 글자가 깨져”야. 누군가 인코딩을 바꿔 보라고 답했어. 아직 질문자가 파일을 다시 열어 보지도 않았는데 해결로 바꾸면, 답변 도착을 문제 해결로 기록하게 돼.

여기서 먼저 확인할 자료는 질문·답변·댓글의 현재 상태, 해결 표시를 바꾸는 주체, 잠금 권한, 수정 이력이야. 기존 서비스에 이런 기록이 없다면 확인되지 않았다고 적어. 답변율이나 해결률이 높다는 가정으로 요청을 정당화하면 안 돼. 이번 예제는 기존 회원을 식별할 수 있고 질문 하나에 답변 하나만 확인하는 범위로 잡을게.

요청은 “답변이 있는 질문을 닫는다”에서 “질문자가 어떤 답변으로 해결했는지 확인하고, 대화 제한은 별도로 관리한다”로 바꿔 적어. 이 한 줄이 정해져야 버튼 이름과 집계 기준도 맞출 수 있어.

처음에는 답변이 없고, 인코딩을 바꿔 보라는 첫 답변 1개가 도착해. 아래의 “답변 도착” 시연은 이 시점이야. 그 뒤 가져오기 메뉴에서 UTF-8을 고르라는 두 번째 답변이 추가돼. 답변 2개를 두 탭에서 동시에 선택하는 검수는 이 다음 상태에서 시작해.

자동으로 닫는 게 편해도 확인 주체는 남겨야 해

대안은 첫 답변이 오면 자동 해결, 일정 기간 반응이 없으면 자동 해결, 질문자가 직접 확인하는 방식이 있어. 앞의 두 방식은 운영 목록을 줄이기는 쉬워. 그런데 질문자가 바빠서 못 봤거나 답변으로 해결하지 못했을 때도 해결로 넘어가. 이 예제에서는 미확인 질문이 남더라도 질문자의 확인을 받는 쪽을 고를게.

GitHub의 공개 토론 문서도 답변 선택·해제와 대화 잠금을 별도 조작으로 설명해. 여기서 참고할 건 두 동작을 구분한다는 점이야. 질문자만 확인하게 하거나 본문 수정 때 해제하는 조건은 이 글에서 새로 정한 정책이고, GitHub가 같은 방식으로 처리한다는 뜻은 아니야.

운영자가 할 수 있는 일도 나눠야 해. 문제가 있는 확인은 이유를 남기고 해제할 수 있고 댓글도 잠글 수 있어. 다만 질문자 대신 “해결됐어”라고 확인하지는 않아. 상담원이 종결하는 서비스라면 확인 주체부터 다시 정해야 하니 이 표를 그대로 가져가면 안 돼.

무엇을 확인했는지까지 저장해야 해

해결 여부만 저장하면 선택된 답변이 바뀌었을 때 근거가 사라져. 질문, 선택 답변, 확인 당시 두 본문의 버전, 해결 상태의 변경 버전을 함께 연결해. 버전은 내부 구현 값이고 독자에게는 “답변 내용이 바뀌어서 다시 확인이 필요해”라고 풀어 보여 주면 돼.

질문이나 선택 답변의 본문 수정·숨김·삭제는 해결 표시를 해제할게. 오탈자만 고친 경우도 포함해. 의미가 바뀐 수정인지 자동으로 판정하는 별도 규칙을 만들지 않기 위해서야. 그만큼 재확인이 늘 수 있다는 불편도 기획서에 남겨. 다른 답변이나 댓글이 바뀐 건 선택한 답의 근거를 바꾸지 않으니 유지해.

본문을 복원하거나 다시 공개했다고 옛 확인을 되살리지는 않아. 질문자가 다시 읽고 확인해야 해. 해제 이유는 질문자에게 알려 주되 숨겨진 내용을 알림에 넣지는 마. 이력에는 대상 연결, 상태 전후, 처리자·시각·이유와 알림 결과를 남기고 보관 기간은 기존 정책과 맞춰 확인해.

두 화면에서 다른 답을 눌렀을 때도 하나만 남아야 해

서버는 현재 질문자, 답변이 같은 질문에 속하는지, 두 본문의 공개 여부, 화면에서 본 버전과 현재 버전이 같은지, 아직 미해결인지를 한 번의 원자 처리에서 확인해. 원자 처리란 조건 확인과 결과 저장 사이에 다른 요청이 끼어들어 조건이 바뀌지 않게 묶는 거야.

같은 질문을 두 탭에서 열고 다른 답변을 동시에 확인하면 하나만 성공해야 해. 나머지 요청에는 현재 선택을 보여 주고 덮어쓰지 않아. 다른 답변으로 바꾸고 싶다면 먼저 기존 확인을 해제하고 새 답을 확인해. 확인 취소도 현재 선택과 상태 버전이 같을 때만 처리해서 오래된 화면이 새 선택을 지우지 않게 해.

성공 응답이 끊겨 같은 요청을 다시 보냈을 때는 처음 처리한 결과와 지금 상태를 구분해 돌려줘. 처음에는 성공했어도 그 뒤 답변이 수정됐다면 현재는 미확인이야. 화면은 현재 상태를 따라야 하고, 재전송 때문에 이력·알림을 다시 만들거나 해결 표시를 되살리면 안 돼.

잠갔는데 미해결인 화면도 정상적으로 보여야 해

“닫힘” 하나로 표시하면 해결돼서 닫힌 건지 운영상 댓글을 막은 건지 알 수 없어. 해결 확인과 댓글 잠금을 화면에서도 따로 보여 줘. 잠긴 질문이라도 내용이 공개돼 있다면 질문자는 답변을 확인하거나 확인을 취소할 수 있어. 본문 숨김은 접근을 바꾸는 별도 조건이야.

버튼을 누른 직후에는 처리 중이고 서버가 확정한 뒤에만 해결 표시를 바꿔. 조건이 바뀌어서 실패한 경우에는 “다시 시도해”만 쓰지 말고 현재 답변을 다시 읽어야 하는 이유를 알려 줘. 아래 시연은 네 상황의 문구를 비교하는 고정 예제야. 실제 게시판에 해결 확인을 저장하지는 않아.

AI에는 예쁜 흐름보다 틀어지는 조건을 먼저 찾아 달라고 해

“해결 처리 기획서 써줘”라고만 주면 자동 종결이나 운영자 대리 확인을 자연스럽게 추가할 수 있어. 먼저 누가 확인하는지, 어떤 수정이 확인을 깨는지, 잠금은 무엇을 막는지 적어 줘. 그 안에서 누락된 조건과 상태 전후를 찾게 맡기는 거야.

예를 들어 AI가 “같은 요청은 최초 성공 결과 반환”이라고 쓰면 응답이 유실된 뒤 답변이 수정된 경우를 다시 물어봐. 과거 성공과 현재 미확인을 같이 표현하지 못하면 그 답은 그대로 채택할 수 없어. 수정된 조건을 화면 문구·서버 처리·QA에 모두 반영했는지 대조해야 해.

아래는 실행하지 않은 질문 예시야. 실제로 받은 답이나 대화 원문처럼 읽히지 않게 구분했어. 답을 받게 되면 권한, 버전, 재전송, 잠금의 네 조건을 행별로 대조하고, 새 정책을 제안한 부분은 기존 선택과 충돌하는지 별도로 판단해.

예시 질문: 기존 회원의 공개 질문 게시판이야. 질문자만 답변 1개로 해결을 확인해. 질문·선택 답변 본문 수정이나 숨김·삭제는 확인을 해제하고, 댓글 잠금은 별도로 유지해. 자동 해결과 운영자 대리 확인은 없어. 두 탭의 동시 선택, 확인과 본문 수정의 경쟁, 성공 응답 유실 후 본문 수정과 재전송을 검토해 줘. 각각 시작 상태·요청 순서·최종 상태·화면 문구·QA 조건을 써 줘. 새로운 정책이 필요하면 확정한 것처럼 섞지 말고 따로 표시해.

기획서와 설계서에 같은 설명만 복사하면 빠져

기획서에는 왜 미확인 질문을 남기기로 했는지, 오탈자 수정까지 해제하는 이유와 재확인 부담을 적어. 설계서에는 상태별 문구와 동작, 권한, 본문 변경과 확인이 겹칠 때의 결과를 연결해. 같은 요구사항을 가리키더라도 각 문서를 보는 사람이 결정할 수 있어야 해.

W3C의 상태 메시지 설명은 초점을 받지 않는 결과도 보조기술이 인지할 수 있게 제공하는 원칙을 다뤄. 이 예제에서는 처리 중·확인 완료·조건 변경을 글자로 구분하고 적절한 상태 알림으로 전달할게. 검은 배지로 색만 바꾸거나 매번 초점을 강제로 옮기는 방식은 피해야 해.

운영 화면은 해결 확인을 늘리는 버튼보다 왜 해제됐는지 확인할 기록이 필요해. 알림 발송이 실패해도 해결 상태를 되돌리지는 않아. 이미 처리한 변경의 알림만 다시 시도하게 연결하고, 전달 여부와 질문자의 재확인을 따로 기록해.

버튼이 눌리는지보다 어떤 상태가 남는지 봐

QA는 빈 게시판에서 확인 버튼 한 번 누르는 걸로 끝내면 안 돼. 미해결 질문에 공개 답변 두 개가 있는 상태, 이미 확인됐지만 댓글은 잠긴 상태처럼 출발점을 써 둬. 기대 결과에는 화면뿐 아니라 선택된 답변, 확인 버전, 이력과 알림의 중복 여부를 넣어.

특히 확인과 수정이 경합하는 경우를 두 순서로 시험해. 확인이 먼저 끝나면 뒤의 수정이 해제해야 하고, 수정이 먼저 끝나면 옛 버전의 확인이 거절돼야 해. 아래 표는 구현 후 실행할 검수 조건이야. 글의 화면 시연을 눌러 본 것과 실제 게시판 연동 시험 통과는 구분해서 기록해.

내 서비스에 가져갈 땐 확인 주체부터 바꿔 봐

아래 전달안은 질문자 한 명의 확인을 기준으로 만들어 둔 거야. 여러 담당자가 공동으로 해결해야 하거나 직원이 대신 종결하는 업무라면 확인 주체·필요한 동의·해제 범위를 다시 정해야 해. 문구만 바꾸면 다른 업무에도 맞는 규칙이 되는 건 아니야.

적용 후에는 답변이 달린 질문 수와 질문자가 확인한 질문 수를 따로 봐. 확인이 해제된 이유와 미확인 상태도 남겨야 숫자의 뜻을 설명할 수 있어. 다만 질문자 확인이 다른 독자의 문제 해결까지 증명하는 건 아니야. 어떤 사건을 집계했는지부터 맞추고 실제 이용 결과는 그 다음에 해석해.

출시 전에는 권한 없는 확인, 다른 질문의 답변 선택, 수정된 본문에 옛 확인 유지, 재전송으로 상태 부활을 막아야 할 결함으로 잡을게. 기획·디자인·개발·QA가 아래 전달안과 자기 문서를 대조한 뒤, 바뀐 조건을 같은 버전으로 전달하면 돼.

질문 게시판 — 해결 확인 설계·개발·QA 전달안
예제: 기존 회원이 질문과 공개 답변을 쓰는 가상 게시판. 질문당 선택 답변은 1개. 점수·보상·익명 질문·운영자의 대리 해결 확정은 제외한다.
목적: 답변이 왔는지와 질문자가 해결을 확인했는지를 구분한다. 첫 답변, 무응답, 댓글 잠금만으로 해결 처리하지 않는다.
표시: 답변 없음 / 답변 있음·확인 전 / 질문자 해결 확인. 댓글 허용·잠금은 별도 축이며 어느 해결 상태와도 조합될 수 있다.
확인 주체: 질문자만 본인 질문의 현재 공개 답변을 선택한다. 현재 접근 권한과 질문·답변의 소속을 서버에서 확인한다. 운영자는 이유를 남겨 해제하거나 댓글을 잠글 수 있지만 해결 확인을 대신하지 않는다.
확인 조건: 현재 미해결이며 질문 본문 버전·선택 답변 본문 버전·해결 상태 버전이 화면에서 본 값과 같아야 한다. 공개 여부·권한·소속과 함께 한 원자 처리에서 검사하고 선택 답변과 확인 버전을 저장한다.
바뀐 내용: 질문 또는 선택 답변 본문 수정·숨김·삭제는 해결 표시를 해제한다. 오탈자 수정도 포함한다. 다른 답변·댓글 수정은 영향을 주지 않는다. 본문 복원·다시 공개는 자동 재확인이 아니다.
취소·교체: 질문자의 확인 취소와 운영자의 사유 있는 해제 모두 현재 선택과 상태 버전을 확인한다. 답변은 삭제하지 않고 댓글 잠금도 유지한다. 다른 답변으로 바꾸려면 기존 확인 해제 후 새 내용을 확인한다.
잠금: 댓글 잠금은 새 댓글 작성을 막는다. 공개된 내용의 질문자 확인·해제는 허용한다. 질문이나 답변 숨김과 댓글 잠금을 같은 상태로 저장하지 않는다.
동시 요청: 같은 시작 상태에서 서로 다른 답변을 선택하면 한 건만 성공한다. 다른 요청에는 바뀐 현재 결과를 보여 주며 자동 덮어쓰지 않는다. 확인과 본문 수정이 겹쳐도 수정된 본문에 옛 확인이 남으면 안 된다.
재전송: 같은 회원의 같은 작업 요청은 변경·이력·알림을 반복 생성하지 않는다. 최초 처리 결과와 지금 상태를 분리해 반환한다. 그 뒤 본문이 바뀌었다면 최초 성공을 보여 주며 해결 표시를 되살리지 않는다. 재조회 때도 현재 접근 권한을 적용한다.
화면: 처리 중에는 성공 표시를 앞당기지 않는다. 성공, 조건 변경, 접근 불가를 구분한다. 결과 글자를 보조기술로 인지할 수 있게 알리고 불필요하게 초점을 옮기지 않는다. 확인된 답변으로 가는 링크와 확인 취소 동작을 둔다.
기록: 질문·선택 답변 연결, 확인한 본문 버전, 상태 전후, 처리자, 시각, 해제 이유, 요청 중복 여부, 알림 결과를 남긴다. 비공개 본문을 알림이나 오류에 노출하지 않는다. 보관 기간은 기존 정책과 맞춰 확인한다.
역할: 기획은 대안·권한·해제 조건, 디자인은 상태와 피드백, 개발은 버전 검사·원자 전이·재전송, QA는 초기 상태와 요청 순서, 운영은 해제 사유와 알림 실패를 대조한다.
검수: 첫 답변, 무응답, 작성자 외 확인, 다른 질문의 답변, 정상 확인, 본문 변경·숨김·삭제·복원, 무관한 댓글 변경, 동시 선택, 수정 경쟁, 응답 유실 재전송, 확인 취소·잠금 유지, 잠금 중 확인을 시험한다. 실제 결과와 이력을 함께 기록한다.
적용 전: 해결 주체가 여러 명이거나 상담원이 대신 종결하는 서비스는 그대로 쓰지 않는다. 이 자료는 고정 화면 예제와 설계 조건이며 실제 게시판 구현·연동 시험 완료 기록이 아니다.
예제 순서: 답변 없음 → 첫 답변 1개의 도착 화면 → 두 번째 답변 추가 후 동시 선택 검수. 추가 QA: 선택이 바뀐 뒤 옛 확인 취소·운영 해제 거절, 재전송 전 숨김·접근 상실의 내용 비노출, 알림 실패 재시도의 상태 유지·중복 작업 방지를 확인해. 총 15가지 검수 행을 본문과 대조해.

출처와 예제 조건

공개 GitHub 문서의 답변 선택과 잠금 구분, W3C의 상태 피드백 원칙을 참고한 가상 설계야. 권한·수정·재전송 정책은 이 예제의 선택이고 실제 서비스 성과가 아니야. AI 질문은 미실행 예시이며 영어·중국어판은 같은 한국어 안건의 현지화야.

GitHub Docs — Moderating discussions

W3C — Understanding SC 4.1.3: Status Messages