자체 서비스를 운영하는 팀의 버그 제보가 자꾸 새는 이유

외주와 달리 자체 서비스를 운영하는 팀에는 "납품"이 없습니다. 대신 릴리즈가 계속 돌아가고, 고객 문의가 매일 들어오고, 어제 고친 것이 오늘 또 터집니다. 전담 QA 조직이 있는 회사도 있지만 대부분은 기획자·개발자·CS 담당이 QA를 나눠 맡습니다.

이 구조에서 제보는 "안 들어와서" 새는 게 아니라 들어온 뒤에 샙니다. 어디서 새는지 다섯 구간으로 나눠 보고, 마지막에 한 사이클을 그대로 따라가 봅니다.

제보가 새는 다섯 구간

1. 창구가 너무 많습니다

같은 버그가 이렇게 들어옵니다.

• 고객센터로 들어온 문의
• 슬랙에 누가 올린 스크린샷
• 대표님이 카톡으로 보낸 한 줄
• 기획자가 노션에 적어둔 메모

창구가 넷이면 같은 버그가 네 번 등록되거나, 아무 데도 등록되지 않습니다. 중복은 그나마 낫습니다. 문제는 "누군가 봤겠지" 하고 아무도 안 보는 쪽입니다.

2. CS와 개발 사이가 끊깁니다

CS 담당자는 고객의 말을 그대로 옮깁니다. "결제가 안 돼요." 개발자는 그 문장으로 아무것도 할 수 없습니다. 어떤 결제 수단인지, 어떤 화면에서인지, 재현이 되는지가 없으니까요.

그래서 되묻습니다. CS는 고객에게 다시 묻습니다. 고객은 이미 이탈했습니다.

반대 방향도 막힙니다. 개발자가 고쳤는데 CS는 그걸 모릅니다. 고객에게 "확인 후 안내드리겠습니다"라고 한 채로 며칠이 지나갑니다.

3. 비개발자가 못 쓰는 도구를 씁니다

Jira를 도입한 팀에서 흔히 벌어지는 일입니다. 개발팀은 Jira를 쓰고, 나머지는 안 씁니다. 스프린트·에픽·워크플로 설정을 이해해야 티켓 하나를 제대로 만들 수 있으니까요.

결국 기획·CS·마케팅은 슬랙에 쓰고, 개발자가 그걸 다시 Jira에 옮깁니다. 옮기는 사람이 병목이 되고, 옮기다 빠뜨린 건 사라집니다.

4. 릴리즈마다 같은 걸 다시 확인합니다

회귀 검수는 원래 반복 작업입니다. 문제는 "지난번에 이 화면에서 뭐가 터졌는지"가 기록으로 안 남아 있다는 겁니다. 매번 기억에 의존하고, 기억하는 사람이 휴가면 그냥 넘어갑니다.

5. "그거 고쳐졌나요?"가 계속 반복됩니다

상태를 물어보는 커뮤니케이션이 실제 작업만큼 시간을 먹습니다. 대표가 묻고, 기획자가 개발자에게 묻고, 개발자가 "아까 배포했어요"라고 답하고, 다시 CS가 확인합니다.

한 사이클을 그대로 따라가 보면

도구를 하나 더 늘리는 게 아니라, 모든 제보가 한 곳으로 들어오고 상태가 저절로 드러나게 만드는 쪽입니다. buggle에서 제보 하나가 종결까지 가는 경로를 순서대로 보면 이렇습니다.

① CS가 받은 자리에서 바로 남깁니다

buggle에는 기획·개발·디자인·QA와 함께 CS 역할이 기본으로 있습니다. 그리고 이슈 등록은 직무와 상관없이 프로젝트 멤버면 누구나(읽기 전용 뷰어는 제외), 코멘트는 프로젝트를 볼 수 있는 사람이면 누구나 할 수 있습니다. 스프린트나 에픽 같은 개념을 이해할 필요 없이, CS 담당자가 고객 문의를 받은 그 자리에서 바로 이슈로 남길 수 있습니다.

옮겨 적는 사람이 없으면 병목도 없습니다. (1·3번 구간)

② 이슈에 화면과 재현 정보를 붙입니다

이슈를 프로젝트의 화면 카탈로그에 연결하고, 기대결과·재현경로를 적고, 스크린샷을 첨부합니다. "결제가 안 돼요"가 "결제 화면(어느 단계에서, 어떤 환경에서)"으로 바뀌면 개발자가 되물을 일이 줄어듭니다. (2번 구간)

③ 파트가 각자 진행하고, 상태는 계산됩니다

이슈는 파트(기획·디자인·프론트·백엔드 등)로 나뉘고, 각 파트가 미수정 → 진행중 → 작업완료 → 배포/반영으로 진행합니다. 작업이 필요 없는 파트는 사유를 남기고 작업없음으로 종료할 수 있습니다.

필수 파트가 모두 끝나면 이슈가 검수요청으로 넘어가고, 확인한 사람이 확인완료로 종결하거나 재수정요청으로 되돌립니다. 이슈 상태를 누가 따로 갱신하지 않아도 파트 진행 상황에서 자동으로 계산됩니다. (5번 구간)

프로젝트 대시보드. 상태별 건수와 수정 완료율, 이번 주 활동이 이미 계산되어 있습니다. "그거 고쳐졌나요?" 대신 이 화면을 봅니다.

조직이 텔레그램 봇을 연결하고 담당자가 계정을 연동해 두면 자기 차례일 때 알림도 받습니다.

④ 다음 릴리즈에서 그 기록을 다시 씁니다

화면에 연결해 둔 이슈는 화면 기준으로 쌓입니다. 릴리즈 전에 "이번에 건드린 화면에서 예전에 뭐가 터졌었는지"를 기억이 아니라 목록으로 확인할 수 있습니다. (4번 구간)

화면별 수정이력. 화면을 고르면 그 화면에 연결된 이슈와 각 이슈의 상태 변경 이력이 펼쳐집니다.

보고서에는 화면별 수정이력 외에 처리 추이 · 재확인·반려 · 노후·지연 · 담당자·파트별 리포트가 있습니다. 오래 방치된 이슈가 무엇인지, 반려가 반복되는 지점이 어디인지를 감이 아니라 숫자로 봅니다.

사내 QA라는 말이 어색하다면

자체 서비스를 운영하는 팀에서는 "QA"라는 이름의 조직이 없는 경우가 더 많습니다. 그래도 하는 일은 같습니다. 제보를 받고, 재현하고, 고치고, 확인하고, 다음 릴리즈에 같은 게 또 나오는지 봅니다. 이름이 QA든 운영이든 CS든, 그 흐름이 한 곳에 기록되면 사람이 바뀌어도 이어집니다.

도구가 무거우면 아무도 안 쓰고, 안 쓰면 결국 슬랙으로 돌아갑니다. 엑셀보다는 강력하게, Jira보다는 가볍게 — buggle이 잡고 있는 지점입니다.

외주·수탁 쪽 흐름이 궁금하시다면 외주 프로젝트에서 엑셀·카톡으로 버그를 관리할 때 생기는 문제에 같은 이야기를 프로젝트 단위로 정리해 두었습니다.