리포트를 어디로 보낼까 — 이메일·웹훅·Jira·자체 백엔드

트리거를 정하고 수집 코드를 붙였다면 다음은 전송입니다. 1편에서 짚었듯 이 선택이 QA 팀의 실제 워크플로에 가장 직접 영향을 줍니다. 네 경로 — 이메일, 웹훅, Jira 직접 연동, 자체 백엔드 — 를 순서대로 봅니다.

이메일(SMTP) — 가장 쉽지만 딱 거기까지

SMTP 클라이언트 몇 줄이면 끝입니다. 별도 서버도, 인증 플로도 필요 없습니다. 다만 세 가지 벽에 곧 부딪힙니다. 첨부파일 용량 제한(대부분의 SMTP 서버가 10~25MB 선에서 막습니다), 스팸 필터로 리포트가 조용히 사라지는 문제, 그리고 "이 버그 아직 열려 있나 닫혔나"를 추적할 방법이 없다는 것입니다. 프로토타입이나 극초기 단계에서 "일단 뭐라도 받아보자"에는 맞지만 팀이 커지면 바로 한계가 옵니다. 예를 들어 QA 한두 명이 막 프로토타입을 테스트하기 시작한 단계라면 하루에 리포트 몇 건이 전부라 이 세 가지 벽 중 어느 것도 아직 체감되지 않습니다. 문제는 팀과 리포트 수가 함께 늘어나는 순간 세 벽이 동시에 나타난다는 점입니다.

웹훅(Slack/Discord) — 즉시성은 최고, 이력은 없다

팀이 이미 보고 있는 채널에 리포트가 바로 뜹니다. 도입도 웹훅 URL 하나로 끝나서 인증 난도가 사실상 없는 수준입니다. QA 가 리포트를 올리자마자 개발자가 알아채는 속도는 넷 중 가장 빠릅니다.

문제는 그 다음입니다. 채널 스크롤이 곧 리포트 이력이라서, 지난주에 비슷한 버그가 있었는지 검색하려면 사람이 기억에 의존해야 합니다. 상태(진행 중/해결됨) 관리도 없고, 메시지 하나하나가 독립적이라 같은 버그의 재발을 자동으로 묶어주지도 않습니다. 팀 규모가 작을 때는 이 약점이 잘 안 보이다가, 리포트 수가 늘어나는 순간 갑자기 드러납니다. 예를 들어 개발자 서너 명이 같은 Slack 채널에 상주하는 팀이라면 리포트가 올라오자마자 반응이 오는 속도 자체가 다른 무엇보다 큰 값입니다. 다만 같은 채널에 몇 주 치 리포트가 쌓이고 나면, 특정 버그를 다시 찾으려 스크롤을 몇 백 줄 거슬러 올라가야 하는 상황이 반드시 옵니다.

Jira 직접 연동 — 이슈 트래커에 바로 꽂히지만 그 대가로

리포트가 처음부터 이슈로 존재하므로 검색·상태·담당자 배정이 전부 트래커 기능을 그대로 씁니다. 넷 중 사후 관리 측면에서는 가장 튼튼한 선택지입니다.

대가는 진입 비용입니다. OAuth 인증 플로를 직접 구현해야 하고(토큰 갱신, 만료 처리까지 포함), 게임에서 수집한 필드(디바이스 정보, 게임 상태, 스크린샷)를 Jira 커스텀 필드에 매핑하는 작업이 별도로 필요합니다. Jira 프로젝트 구조가 바뀌면 매핑도 따라 바뀌어야 합니다. 작은 팀에는 이 초기 구축 비용이 부담일 수 있습니다. 이 비용은 한 번 내고 끝나는 것도 아닙니다. 토큰 갱신 로직을 놓치면 어느 날 갑자기 리포트가 안 들어오기 시작하는데, 실패가 조용해서 한동안 아무도 눈치채지 못하는 경우가 흔합니다.

자체 백엔드 — 통제권은 최대, 유지비도 최대

리포트 스키마, 검색 방식, 대시보드 UI 까지 전부 원하는 대로 설계할 수 있습니다. 영상 파일처럼 용량이 큰 첨부물을 다루거나, 여러 이슈 트래커로 동시에 내보내야 하는 요구가 있다면 사실상 이 경로밖에 없습니다.

다만 스토리지, 인증, 대시보드, 백업까지 전부 직접 운영해야 합니다. 처음 붙일 때의 비용보다 몇 달 뒤 유지비가 더 큰 변수입니다. 로그인 한 명 늘어날 때마다, 플랫폼 하나 추가될 때마다 손이 갑니다. 예를 들어 로그인 방식을 하나 더 붙이거나 지원 플랫폼을 하나 늘리는 작업은, 다른 세 경로라면 설정 몇 줄로 끝나지만 여기서는 스토리지·인증·대시보드 세 곳을 동시에 고쳐야 하는 일이 됩니다.

네 경로 비교

실무 결론

대개는 웹훅으로 시작해서 리포트 수가 늘어나면 이슈 트래커로 옮겨갑니다. 처음부터 완벽한 경로를 고르려 하지 말고, 지금 팀 규모에서 알림 속도가 급한지 이력 관리가 급한지를 먼저 물으면 됩니다. 웹훅과 Jira 연동을 동시에 쓰는 것도 흔한 절충안입니다 — 즉시 알림은 웹훅으로, 정식 이슈는 트리아지 후 Jira 로 넘기는 방식입니다.

정리

이메일은 진입장벽이 없는 대신 이력 관리가 없고, 웹훅은 즉시성이 있는 대신 검색이 없고, Jira 연동은 트래커 기능을 그대로 쓰는 대신 인증 비용을 치르고, 자체 백엔드는 통제권을 사는 대신 유지비를 삽니다. 네 경로에 정답은 없고, 지금 팀이 속도와 이력 관리 중 어느 쪽을 더 아쉬워하는지가 선택을 가릅니다. 무엇을 수집해서 보낼지는 게임 상태 스냅샷에서, 트리거·수집까지 포함한 전체 그림은 1편에서 다룹니다.

저희 Rekon은 이 선택 자체를 없애는 쪽입니다 — 웹 대시보드가 검색·이력을 대신 가지고 있고, 거기서 Jira 이슈로 바로 등록할 수 있습니다. 자체 백엔드까지 가지 않고도 검색성과 이력 관리를 얻는 경로가 필요하다면 검토해 보시길 권합니다.