외주 프로젝트에서 엑셀·카톡으로 버그를 관리할 때 생기는 문제

외주 개발에서 QA는 대부분 이렇게 시작합니다. 공유 시트를 하나 만들고, 급한 건 단톡방에 올리고, 스크린샷은 각자 메신저로 보냅니다. 프로젝트 하나일 때는 그럭저럭 굴러갑니다. 문제는 프로젝트가 셋으로 늘고, 고객사가 넷이 되고, 지난달에 고친 버그를 다시 설명해야 할 때 드러납니다.

아래 다섯 가지는 외주·수탁 QA에서 반복해서 나오는 문제입니다. 문제를 하나씩 짚고, 그 문제를 buggle에서 어떻게 다르게 두었는지를 바로 이어서 적었습니다.

1. 이력이 프로젝트마다 흩어집니다

같은 팀이 A사·B사·C사 프로젝트를 동시에 돌리면 시트도 세 개, 단톡방도 세 개가 됩니다. "그 결제 오류 언제 고쳤죠?"라는 질문에 답하려면 어느 시트의 몇 번째 행이었는지부터 찾아야 합니다.

더 곤란한 건 사람이 바뀔 때입니다. 담당자가 교체되면 시트의 행은 남지만 맥락은 남지 않습니다. "왜 이렇게 고쳤는지"는 대부분 단톡방 어딘가에 흘러가 있고, 그건 검색으로 잘 찾아지지 않습니다.

buggle에서는 프로젝트를 조직 안에 나란히 두고, 각 프로젝트의 이슈를 하나의 보드에서 봅니다. 이슈마다 등록·상태 변경·코멘트가 이력으로 남기 때문에, 담당자가 바뀌어도 "이 이슈가 어떤 경로로 여기까지 왔는지"가 그대로 남습니다.

이슈 보드. 왼쪽에 프로젝트가 나란히 있고, 각 이슈의 기획·디자인·퍼블·백엔드·프론트엔드 파트 상태가 열로 보입니다.

2. 재현 스텝이 사라집니다

메신저로 오는 버그 제보는 보통 이렇게 생겼습니다.

결제 화면에서 튕겨요

이 한 줄로는 아무도 고칠 수 없습니다. 어떤 기기인지, 어떤 계정으로 로그인했는지, 어떤 순서로 눌렀는지가 빠져 있으니까요. 결국 개발자가 되묻고, 제보자가 답하고, 그 사이 하루가 지나갑니다.

스크린샷을 붙여도 마찬가지입니다. 이미지가 메신저에 있고 이슈는 시트에 있으면, 나중에 그 둘을 다시 잇는 사람이 고생합니다.

buggle에서는 이슈에 기대결과·재현경로를 따로 적는 칸이 있고, 스크린샷은 이슈에 직접 첨부합니다. 이미지와 설명이 같은 곳에 있으니 나중에 둘을 다시 이을 일이 없습니다. 환경(dev·stg 등)과 중요도도 이슈에 붙어 다닙니다.

3. "누가 할 차례"인지 아무도 모릅니다

이게 가장 비싼 문제입니다. 하나의 버그가 기획·디자인·프론트·백엔드를 거쳐야 하는 경우, 시트의 "담당자" 칸 하나로는 지금 공이 누구에게 있는지 표현할 수 없습니다.

• 프론트는 "API가 아직 안 나왔다"고 하고
• 백엔드는 "기획 확정 기다린다"고 하고
• 기획은 "그건 이미 정리해서 보냈다"고 합니다

상태를 물어보는 회의가 늘어나고, 그 회의는 대부분 "지금 어디까지 됐나요"를 확인하는 데 씁니다.

buggle에서는 하나의 이슈를 파트로 나누고, 각 파트가 자기 몫만 관리합니다. 파트 상태는 미수정 → 진행중 → 작업완료 → 배포/반영으로 진행하고, 작업이 필요 없다고 판단되면 사유를 남기고 작업없음으로 종료할 수 있습니다.

일반적인 흐름에서는 필수 파트가 모두 종료되면 이슈 전체가 검수요청으로 넘어갑니다. 검수 결과에 따라 확인완료로 종결되거나, 재수정요청으로 다시 작업 단계로 돌아옵니다. 이슈 상태를 사람이 따로 갱신하지 않아도, 파트 진행 상황에서 자동으로 계산됩니다.

이슈 상세. 오른쪽에 파트·담당과 상태 버튼이 있고, 그 아래로 검수와 변경 히스토리가 이어집니다. "배포/반영 → 재수정요청"처럼 되돌아간 기록도 그대로 남습니다.

파트에 순서를 지정하면 앞 파트가 끝났을 때 다음 차례 담당자에게 표시가 갑니다. 다만 이건 작업을 막는 잠금장치가 아닙니다. 순서를 지정해도 다른 파트가 먼저 일할 수 있고, 순서는 "지금 누구 차례인지"를 보여주고 알림을 어디로 보낼지 정하는 데만 쓰입니다. 실무에서 순서는 자주 바뀌니까요.

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

4. 같은 화면이 계속 터지는데 그걸 모릅니다

시트 관리의 사각지대입니다. 행 단위로만 보면 "이번 주 12건 처리"는 알 수 있어도, "그중 다섯 건이 전부 같은 화면"이라는 사실은 잘 안 보입니다. 근본 원인을 잡을 기회를 놓치고, 같은 자리에서 계속 두더지잡기를 합니다.

buggle에서는 이슈를 프로젝트의 화면 목록(화면 카탈로그)에 연결하면, "이 화면에서 지금까지 어떤 문제가 있었는지"가 화면 기준으로 모입니다. 보고서에도 화면별 수정이력이 따로 있어서, 유난히 자주 터지는 화면을 감이 아니라 목록으로 확인할 수 있습니다.

5. 고객 보고가 매번 수작업입니다

주간 보고 때마다 시트를 필터링하고, 스크린샷을 붙이고, 진행률을 손으로 계산합니다. 다음 주에 또 같은 일을 합니다. 이 작업은 품질을 높이지 않는데 시간은 확실히 먹습니다.

buggle에서는 프로젝트 대시보드에 상태별 건수와 수정 완료율, 주간 활동이 이미 계산되어 있습니다. 보고서에는 처리 추이·재확인·반려·노후·지연·담당자별 리포트가 있고 CSV로 내려받을 수도 있습니다. 보고서를 "만드는" 일에서 "보여주는" 일로 바뀝니다.

정리하면

시트·메신저에서 생기는 문제	buggle에서 다르게 둔 지점
프로젝트마다 이력이 흩어짐	조직 안에 프로젝트를 모으고, 이슈마다 이력 유지
재현 스텝·스크린샷이 따로 놂	기대결과·재현경로 칸 + 이슈에 직접 첨부
누구 차례인지 모름	파트별 상태 진행 → 검수요청으로 자동 롤업
같은 화면이 반복해서 터짐	화면 카탈로그 연결 + 화면별 수정이력
고객 보고가 수작업	대시보드·보고서에서 바로 확인·내보내기

엑셀과 메신저가 나쁜 도구는 아닙니다. 다만 상태를 사람이 손으로 옮겨 적어야 하는 구조라서, 프로젝트가 늘어날수록 옮겨 적는 비용이 같이 늘어납니다. 이력이 한곳에 쌓이고 상태가 자동으로 계산되면, 회의에서 물어보던 것들이 화면에서 그냥 보이기 시작합니다.

고객사와 검수를 나눠야 하는 상황이라면 고객사와 버그 검수를 안전하게 공유하는 방법도 함께 보시면 좋습니다.