말해줄 때까지 기다리지 않는 AIDRA 피드백 트리아지 루프

문제 정의

물어봐야 조금씩 말해주는 관계였다

AIDRA는 협업 파트너팀이 쓰는 사내 기획 에이전트다. 계정은 13개가 있지만 실제로 콘텐츠를 만드는 사람은 두 명이고, 팀 확산은 명시적인 비목표로 확정했고 성공 기준도 그 두 사람의 리텐션으로 좁혔다. 유저가 둘이면 신고 한 건의 정보 가치가 극단적으로 커진다. 그런데 그 신고를 받을 경로가 제품 안에 없었다.

피드백은 슬랙과 메신저, 그리고 회의 자리의 구두로 들어왔다. 문제는 채널의 부재가 아니라 능동성의 부재였다. 사용자들은 먼저 말하지 않았고, 내가 물어봐야 조금씩 말해줬다. 그렇게 들은 내용은 대화 흐름에 섞여 흘러갔고, 누가 어떤 화면에서 무엇을 겪었는지가 남지 않았다. 재현에 필요한 정보를 되묻는 것 자체가 또 한 번의 부담이 됐다.

기록으로 남은 초기 피드백은 대부분 내가 직접 제품을 쓰다가 발견해 스크린샷으로 제보한 것들이다. 도그푸드는 유용했지만 만드는 사람의 눈에는 한계가 있다. 실제로 회차를 20편씩 만드는 사람이 겪는 마찰은 내가 다섯 번 눌러보는 것으로는 드러나지 않는다. 사용자가 스스로 말하게 만들지 못하면, 유저가 둘뿐인 제품에서 결함의 절반 이상을 영영 모르고 지나가게 된다.

가설 수립

채널을 여는 것과 답이 돌아가게 만드는 것은 다른 일이다

사내에는 이미 팀 보드가 있었다. 거기로 신고를 받게 하면 새로 만들 것이 없다. 그 길을 택하지 않은 이유는 세 가지였다. 보드에 사람이 옮겨 적으면 발급 화면과 모드, 세션 식별자, 브라우저 환경이 소실되고, 그게 없으면 근본 원인 조사가 추측으로 시작된다. 그리고 사내 보드는 파트너팀 사용자에게 답을 돌려줄 수 없다.

세 번째 이유가 가설의 핵심이었다. 사용자가 능동적으로 말하지 않는 이유는 말해도 어떻게 됐는지 모르기 때문이라고 봤다. 그렇다면 필요한 것은 신고를 받는 창구가 아니라 신고가 처리되어 본인에게 돌아오는 왕복이다. 제출과 조사와 회신이 한 루프 안에서 닫혀야 다음 신고가 나온다. 유저가 둘이면 회신 한 건의 리텐션 효과도 그만큼 커진다.

그래서 제품 안에 티켓 시스템을 직접 만들고, 팀 가시성을 위한 사내 보드 연동은 나중에 얹기로 했다. 순서를 그렇게 잡은 이유는 제출 경로에 외부 API 의존이 들어가면 그 API의 장애가 곧 피드백 유실이 되기 때문이다. 먼저 유실 없는 정본을 세우고, 닷새 뒤에 보드 미러링을 붙였다. 미러가 실패해도 제출은 성공하도록 설계했다.

배포 당일 라이브에서 직접 써보다가 가장 중요한 결함을 발견했다. 답변이 유저에게 돌아가는 화면을 여는 함수가 어디에서도 호출되지 않고 있었다. 왕복 루프를 만들겠다고 해놓고 정작 돌아오는 쪽이 첫날에 끊겨 있었던 것이다. 그날 안에 모달을 보내기와 내 피드백 두 탭으로 재구성했고, 로그인할 때 모달이 자동으로 열리던 동작도 반복 노출이 거슬려 배지로 되돌렸다. 설계상 좋아 보이던 것이 실제로 쓰면 마찰이 된다는 걸 같은 세션에 두 번 확인했다.

솔루션 도출

조사는 자동화하고, 무엇을 고칠지는 사람이 정한다

티켓이 쌓이자 처리 과정 자체가 반복 작업이 됐다. 미해결 티켓을 전수 조사하고, 근본 원인을 코드에서 확정하고, 무엇을 고칠지 승인받고, 구현하고, 배포하고, 사용자에게 회신하는 순서다. 이 절차를 두 번 손으로 돌려본 뒤 아홉 단계로 문서화해 프로젝트 스킬로 만들었다. 추측으로 쓴 절차가 아니라 이미 검증한 순서를 옮긴 것이다.

스킬을 만들면서 가장 신경 쓴 것은 어디까지 자동화할지의 경계였다. 처음에는 매일 아침 자동으로 처리되게 하고 싶었다. 그런데 조사해보니 세 번째 단계부터는 무인화가 성립하지 않았다. 어떤 대안을 택할지는 코드로 결정할 수 없는 제품 판단이고, 무인으로 돌리면 승인 없이 배포하지 않는다는 저장소 규칙과 충돌한다. 그래서 이번엔 스킬만 만들고 자동 루프는 미뤘다. 이 경계는 처음부터 세운 원칙이 아니라 하고 싶었던 것을 스스로 접으면서 그어진 선이다.

조사 단계에도 규칙을 하나 넣었다. 관련 커밋이 이미 있으니 해결됐겠다는 패턴 매칭을 그대로 승인하지 않는 것이다. 첫 라운드에서 이 함정이 세 번 나왔기 때문이다. 캐릭터 이름 원장이 존재하니 개명 반영도 됐겠다고 넘어갈 뻔했는데 그 원장은 다른 용도였고, 의도 우선 로직이 배포됐으니 장르 불일치도 커버됐겠다고 봤지만 캐릭터 직업 필드는 그 범위 밖이었다. 그래서 항목마다 독립 에이전트를 붙여 지금 코드에서 실제로 재현되는지를 파일과 줄 번호까지 확정시키게 했다.

보내기와 내 피드백 두 탭. 답변에는 근본 원인과 배포 완료 시점이 함께 적힌다

결과 & 배운 점

채널이 아니라 능동성이 만들어졌다

다섯 주 동안 열세 번의 라운드를 돌렸다. 접수된 티켓 42건 중 41건이 종결됐고 남은 한 건도 보류 사유를 명시해 회신했으므로, 답변이 돌아가지 않은 티켓은 한 건도 없다. 개선 항목은 누계 약 53개였고 프로덕션 배포는 열일곱 번 이상이었다. 그 사이 단위 테스트는 634개에서 2,102개로 늘었다.

수치보다 분명한 것은 관계의 변화였다. 물어봐야 조금씩 말해주던 사람들이, 퍼널이 뚫리고 나니 훨씬 편하고 능동적으로 주기 시작했고 피드백의 양 자체가 늘었다. 전체 티켓의 절반이 넘는 22건이 한 사람에게서 나왔는데, 유저가 둘인 조직에서 이건 한 사람의 사용 흔적이 로드맵의 절반을 만들었다는 뜻이다. 두 사람이 각각 독립적으로 같은 요구를 신고한 적도 있었는데, 그때는 처음에 보류했던 판단을 뒤집어 우선순위를 올렸다. 유저가 둘일 때 두 명 독립 신고는 사실상 전수 합의다.

경계를 사람 쪽에 남겨둔 판단이 값을 한 순간도 있었다. 보드 상태를 여섯 건 전부 반영했다는 보고를 받았는데, 화면을 직접 열어보니 컬럼에 카드가 아직 남아 있었다. 조회 API가 기본값으로 최근 50건만 돌려주고 있어서 오래된 카드가 밀려나 있었던 것이다. 자동화가 완료했다고 말한 것을 화면 한 장이 반증한 셈이고, 판정권을 사람에게 남긴 설계가 그 자리에서 값을 했다.

이 일을 통해 배운 것은 피드백 시스템의 성패가 접수가 아니라 왕복에 달려 있다는 사실이다. 배포 첫날 발견한 결함이 정확히 답변이 돌아가는 동선이었다는 게 그 증거다. 사용자가 말하지 않는 이유는 할 말이 없어서가 아니라 말한 뒤에 무슨 일이 일어나는지 모르기 때문이었다. 그리고 이 루프에도 한계가 남았다. 신고가 없으면 결함도 안 보이므로, 이후에는 티켓을 기다리지 않고 실사용 데이터를 직접 전수 분석하는 쪽으로 한 걸음 더 옮겨야 했다.