버그 티켓 접수선 제작 로그

많이 잡는 게임이 아니어야 했다

버그 티켓 접수선은 처음부터 "많이 처리하기" 게임으로 만들면 방향이 틀어진다고 봤다. 화면 위에서 티켓이 내려오고, 하단 접수선에서 받아낸다는 구조만 보면 슈팅이나 캐치 게임처럼 보일 수 있다. 하지만 이 Play에서 남기고 싶은 판단은 처리량이 아니다. 재현 단계, 로그, 환경, 심각도처럼 접수할 근거가 있는 티켓과 느낌, 소문, 가끔, 추측처럼 아직 반려해야 할 티켓을 나누는 감각이다.

실제 작업에서도 비슷하다. 눈에 띄는 증상은 많지만, 바로 고칠 수 있는 단서가 있는 증상은 따로 있다. "가끔 이상해요"는 무시할 말이 아니라 더 물어봐야 할 말이고, "이 환경에서 이 로그와 함께 500이 난다"는 바로 접수선에 올릴 수 있는 말이다. 이 차이를 긴 설명으로만 쓰면 건조하다. 그래서 초록 접수 도장과 붉은 반려 X가 떨어지는 작은 게임으로 바꿨다.

티켓을 나누는 기준

이 표가 이 Play의 핵심이다. 좋은 티켓과 나쁜 티켓을 사람 탓으로 나누는 것이 아니다. 지금 접수선에 올릴 만큼 정보가 있는지 보는 것이다. 붉은 반려 티켓을 흘리는 것도 버리는 행동이 아니라, 다시 물어볼 질문이 남았다는 뜻에 가깝다.

보관 메모를 하나로 묶으면

`bug-clicker` 주변에는 서로 다른 방향의 짧은 메모가 붙어 있었다. Codex로 작업할 때 빨라지는 부분과 피곤한 부분을 적은 메모, 버튼 하나짜리 웹이 왜 기억에 남는지 적은 메모, AI 도구로 웹서비스를 만들 때 실제로 막히는 경계를 적은 글이 있었다. 따로 보면 각각 맞는 말이지만, 버그 티켓 접수선의 제작 판단으로는 한 흐름으로 묶어야 했다.

이렇게 묶으면 글의 중심이 "AI 도구를 써보니 좋고 피곤했다"에서 "실제 작업에서 접수할 신호와 흘릴 소음을 어떻게 가를 것인가"로 바뀐다. 버그 티켓 접수선은 AI 작업 회고의 장식이 아니라, 운영자가 계속 해야 하는 분류 판단을 손으로 줄인 Play다.

`codex-work-note`를 단독 제출 글로 두면 "AI를 쓰면 빠르지만 사람이 봐야 한다"는 짧은 회고에서 멈춘다. 이 제작 로그 안으로 넣으면 그 말이 버그 접수선의 규칙이 된다. 빠른 손은 모든 티켓을 받아내는 힘이 아니라, 재현 단계와 로그가 있는 티켓을 먼저 알아보는 힘이어야 한다. 방향을 자주 확인해야 한다는 메모도 그래서 접수선 기준으로 바뀐다. 지금 작업이 Blog + Play 품질을 올리는 일인지, 단순히 도구를 더 늘리는 일인지, 실제 증거가 있는 티켓인지, 느낌만 큰 티켓인지 계속 나눠야 한다.

화면에서 중요하게 본 것

가장 중요한 것은 첫 5초다. 사용자가 긴 설명을 읽기 전에 초록 접수 도장과 붉은 반려 X를 구분해야 한다. 초록 티켓에는 재현, 로그, 환경, 심각도 같은 단어가 있어야 하고, 붉은 티켓에는 느낌, 소문, 가끔, 추측 같은 단어가 있어야 한다. 색만으로 나누면 약하다. 도장, X 표시, 종이 티켓 모양, 접수선까지 같이 보여야 한다.

접수선도 점수판처럼 보이면 안 된다. 이 화면은 많은 티켓을 처리하는 콜센터가 아니라, 접수할 근거가 있는 티켓만 하단에서 받아내는 작은 선별판이다. 붉은 티켓을 일부러 피하는 행동도 플레이의 일부다. 모든 것을 잡으면 잘한 것이 아니라, 접수선이 소음으로 막힌 것이다.

첫 5초에서 버린 선택

처음에는 더 게임처럼 보이게 만들 수 있는 선택지가 많았다. 콤보, 연속 처리, 보너스 티켓, 급한 경보음, 큰 점수 팝업은 만들기 쉽다. 하지만 그런 장치가 들어가면 사용자는 "무엇을 받아야 하는가"보다 "얼마나 빨리 많이 받았는가"를 먼저 보게 된다. 이 Play는 손이 빠른지보다 기준이 분명한지가 먼저여야 했다.

그래서 첫 화면에서는 아래 선택을 일부러 줄였다.

이 표는 단순히 기능을 덜 만들었다는 말이 아니다. 작은 Play에서 무엇을 빼야 주제가 남는지 적은 것이다. 버그 티켓 접수선은 실제 운영에서 자주 생기는 "눈에 띄는 말은 많지만 바로 접수할 증거는 적은" 상황을 줄인 화면이다. 콤보가 커지면 그 상황이 사라진다. 반대로 접수선 가까이 온 `로그`, `재현`, `환경` 티켓을 놓쳤을 때 아쉬움이 남으면 주제가 살아 있다.

실패 원인을 따로 남기는 이유

결과 문장도 점수 하나로 끝내지 않으려고 했다. 낮은 점수라고 해서 모두 같은 실패는 아니다. 좋은 티켓을 놓친 것, 소문 티켓을 받은 것, 너무 멀리 있는 티켓을 쫓다가 접수선 가까운 티켓을 놓친 것은 서로 다른 문제다. 다음 판에서 고칠 행동도 다르다.

이 실패 원인을 구분하면 작은 게임이 단순한 점수표에서 운영 메모로 바뀐다. 실제 버그 triage에서도 "많이 봤다"보다 "어떤 신호를 먼저 봤고 어떤 소음을 걸렀는가"가 더 중요하다. 그래서 결과 화면은 최고점 자랑보다 다음 판에서 볼 기준을 남기는 쪽이 낫다.

제작 판단 체크리스트

• - 초록/붉은 구분은 색만이 아니라 도장, X, 라벨로도 읽힌다.
• - 접수할 티켓은 실제 확인 단서가 있는 단어로만 구성한다.
• - 반려 티켓은 사람을 비난하는 말이 아니라 정보가 부족한 상태로 쓴다.
• - 결과는 처리량보다 어떤 소음에 흔들렸는지를 남긴다.
• - 관련 글은 AI 도구 자랑이 아니라 경계 확인과 접수 기준으로 이어진다.
• - 서버 저장, 계정, 랭킹 없이 한 판 안에서 판단이 끝난다.

이 기준을 두지 않으면 화면이 쉽게 "보이는 것 전부 맞히기"가 된다. 그러면 버그 티켓 접수선이라는 이름은 남아도, 실제로는 아무 표적이나 누르는 게임이 된다. 이 Play에서 중요한 것은 손이 빠른가가 아니라, 접수해야 할 티켓을 먼저 보고 소음 티켓을 지나칠 수 있는가다.

검증 기준

이 Play는 단순히 시작하고 끝나는지만 보면 부족하다. 데스크톱에서는 마우스와 키보드가 모두 접수선 이동과 접수 동작을 해야 하고, 모바일에서는 터치로 접수 방패가 움직여야 한다. 결과 화면에서는 공유 버튼, 관련 Blog, 관련 Play가 보이는지도 같이 봐야 한다. 작은 Play라도 결과 이후 경로가 끊기면 Blog + Play 구조가 약해진다.

• - `/play/bug-clicker` 첫 화면에서 초록 접수 도장과 붉은 반려 X가 바로 보이는지 본다.
• - `data-play-action`으로 실제 한 판이 시작되고, 데스크톱/모바일 모두 결과 상태까지 도달하는지 확인한다.
• - 좋은 티켓을 받았을 때와 소문 티켓을 받은 상태가 결과 문장에서 다르게 남는지 본다.
• - 관련 글 목록에 제작 로그와 운영 경계 글이 자연스럽게 이어지는지 확인한다.
• - 하네스가 `data-play-result`, `data-play-share`, `data-play-result-links`, 관련 Blog/Play hook을 놓치지 않는지 본다.

이 로그를 대표 글로 남기는 이유

이 글을 대표 글로 남기는 이유는 `bug-clicker` 자체가 필수 Play 목록에 있기 때문만은 아니다. 이 Play는 bobob.app이 왜 단순한 도구 모음이 아니라 Blog + Play 작업장이어야 하는지를 잘 보여준다. 같은 내용을 글로만 쓰면 "버그 리포트는 재현 단계와 로그가 중요하다"는 일반론이 된다. 게임으로 만들면 사용자가 직접 소문 티켓을 피하고, 재현 티켓을 놓치면 아쉬워한다. 그 손동작이 글의 판단을 보강한다.

짧은 `codex-work-note`를 그대로 제출 표면에 두면 AI 도구 사용 회고 하나가 더 생길 뿐이다. 이 제작 로그 안에 흡수하면 의미가 달라진다. 빠른 도구를 쓸수록 접수 기준이 필요하고, 모든 티켓을 받아내는 것이 능력이 아니라는 점이 Play 규칙으로 남는다. 그래서 이 글은 한 Play의 제작 로그이면서, AI로 사이트를 고칠 때 사람이 계속 해야 하는 분류 작업의 기록이기도 하다.

이 대표 글을 고친 뒤에도 확인은 글자 수에서 끝내지 않는다. `/blog` 목록에서 다른 짧은 메모보다 먼저 보일 이유가 있는지, `/play/bug-clicker` 결과 링크에서 자연스럽게 이어지는지, 검색에서 `bug-clicker`가 단순 도구 회고가 아니라 제작 판단으로 읽히는지 다시 본다. 대표 글은 길기만 하면 되는 글이 아니라, 연결된 Play를 설명할 책임이 있는 글이다.

앞으로 더 본다면 티켓별 실패 원인을 더 짧게 남기고 싶다. "소문 티켓에 밀림"만으로도 방향은 보이지만, 어떤 단어 때문에 흔들렸는지 한 줄 더 남기면 다음 판에서 더 나은 기준을 세울 수 있다. 버그 티켓 접수선은 많이 맞히는 게임이 아니라, 접수할 수 있는 단서를 더 빨리 알아보는 연습으로 남아야 한다.