구글시트도 Jira도 써봤습니다 — 그래도 직접 만든 이유

버그 트래커는 이미 세상에 많습니다. 그런데도 저희는 하나를 더 만들었습니다. 그럴 만한 이유가 있었는지, 아니면 그냥 만들고 싶었던 건지 — 이 글은 그 과정을 순서대로 적은 것입니다.

어디를 가도 흐름은 같았습니다

저희는 여러 SaaS 서비스를 운영하는 조직에서 일했습니다. 업종도 규모도 달랐는데, 일하는 순서는 신기할 만큼 비슷했습니다.

기획하고 → 개발하고 → 테스트하고 → 수정하고 → 운영에 배포하고.

그리고 이 흐름의 한가운데에는 항상 같은 장면이 있었습니다. 테스트하다 문제를 발견하고, 그걸 개발자에게 전달하고, 고쳐졌다는 말을 듣고, 다시 확인하는 것. 조직이 바뀌어도 이 왕복은 그대로였고, 그 사이에서 다뤄본 이슈가 수천 건입니다.

문제는 이 왕복을 담을 그릇이 매번 마땅치 않았다는 것입니다.

1. 시트로 해봤습니다

가장 먼저 잡은 건 공유 시트였습니다. 누구나 열 수 있고, 컬럼도 마음대로 만들고, 무료입니다. 시작하기에 이보다 나은 게 없습니다.

그런데 오래 쓰면 세 군데서 무너집니다.

매번 새 파일부터 만들어야 합니다. 프로젝트가 시작되면 지난 양식을 복사해 오고, 컬럼을 조금 고치고, 공유 설정을 다시 잡습니다. 그렇게 만든 파일이 늘어날수록 "그건 어느 파일에 있었지"가 같이 늘어납니다.

캡처가 자리를 못 지킵니다. 저희는 스크린샷을 셀에 붙여서 관리해 봤습니다. 그런데 행을 하나 추가하거나 정렬을 바꾸는 순간 이미지가 원래 자리에서 어긋났습니다. 몇 번 반복되면 어느 이미지가 어느 행의 것인지 알 수 없게 되고, 결국 다시 붙이는 일이 생깁니다. 버그 관리에서 이미지가 빠지면 남는 건 문장 한 줄뿐입니다.

히스토리를 담을 자리가 없습니다. 시트는 지금 상태만 보여줍니다. 어제 무슨 일이 있었는지는 안 남습니다. 그래서 한동안은 한 셀 안에 날짜와 상황을 계속 밑으로 이어 적었습니다. 그게 저희가 만들 수 있는 유일한 히스토리였습니다. 셀 하나가 열 줄이 되고, 나중엔 그 셀을 열어보는 것 자체가 일이 됐습니다.

2. 메신저로 해봤습니다

급한 건 결국 메신저로 갑니다. 이건 정말 빠릅니다. 캡처 붙여넣고 한 줄 쓰면 끝입니다.

대신 지나고 나면 아무것도 남지 않습니다. 어제 나눈 이야기가 오늘 스크롤 위로 올라가고, 다음 주엔 검색해도 안 나옵니다. 담당자가 바뀌면 그 대화는 통째로 사라진 것과 같습니다.

그래서 실제로는 "메신저로 말하고 시트에도 적는" 이중 작업이 됩니다. 그러다 한쪽을 빠뜨리면 그게 사라집니다.

3. Jira로 해봤습니다

앞의 문제들은 Jira를 쓰면 확실히 해결됩니다. 이력이 남고, 상태가 관리되고, 검색이 됩니다. 괜히 표준이 된 게 아닙니다.

저희가 부딪힌 건 다른 종류였습니다.

시작하기까지가 깁니다. 워크플로와 필드를 팀에 맞게 맞추는 데만 한참이 걸렸고, 그 설정을 이해하는 사람이 팀에 한두 명뿐이면 결국 그 사람에게 계속 물어보게 됩니다.

비용이 인원에 비례합니다. 검수에 잠깐 참여할 사람까지 좌석을 사야 하나 고민하게 됩니다.

이슈 하나를 처리하는 화면이 무겁습니다. 하루에 수십 건을 넘기는 작업에서는 클릭 한 번의 차이가 크게 느껴집니다.

결국 개발팀만 Jira를 쓰고 나머지는 슬랙에 씁니다. 그리고 누군가 그걸 다시 Jira로 옮깁니다. 옮기는 사람이 병목이 되고, 옮기다 빠뜨린 건 사라집니다.

그래도 남던 것들

도구를 세 번 갈아탔는데도 없어지지 않은 문제가 있었습니다. 이게 buggle을 만든 진짜 이유입니다.

① 고친 것과 반영된 것이 구분되지 않았습니다

저희가 가장 많이 겪은 대화입니다.

"수정했습니다." → 확인해 보면 그대로 → "아, 아직 배포를 안 했어요."

수정과 배포는 다른 사건인데, 대부분의 도구에서는 같은 칸 하나에 들어갑니다. "완료" 체크 하나로는 이 둘을 구분할 수 없습니다. 그래서 확인하는 사람이 헛걸음하고, 그 헛걸음이 매일 반복됩니다.

② 고쳐진 걸 몰랐습니다

개발자가 고쳐놓고 시트에만 적어두거나, 메신저로 따로 말해주지 않으면 그냥 몰랐습니다. 수정된 줄 모르고 며칠이 지나간 이슈가 여러 건이었습니다.

반대로 알게 되는 경로도 제각각이었습니다. 어떤 건 메신저로 들었고, 어떤 건 시트를 수시로 들여다보다 발견했고, 어떤 건 배포 알림을 보고 알았습니다. 알림이 없는 게 아니라, 알림이 흩어져 있었던 겁니다.

③ 반복되는 장애를 감으로만 알았습니다

"저 화면 또 터졌네"라는 감은 늘 있었습니다. 다만 그건 감일 뿐이어서 회의에서 근거로 쓸 수가 없었습니다. 어느 화면에 몇 건이 몰렸는지 수치로 볼 수 있는 자리가 아예 없었으니까요. 시트에서는 화면명을 매번 손으로 적었기 때문에 표기가 조금씩 달랐고, 그래서 세어보는 것조차 정확하지 않았습니다.

그래서 이렇게 만들었습니다

앞의 네 가지를 그대로 기능으로 옮겼습니다.

수정과 반영을 다른 칸으로 나눴습니다

이슈를 파트(기획·디자인·퍼블·백엔드·프론트엔드)로 나누고, 각 파트가 미수정 → 진행중 → 작업완료 → 배포/반영으로 진행합니다. 작업완료와 배포/반영이 별개 상태입니다. "고쳤다"와 "올라갔다"를 화면에서 구분할 수 있으면, 확인하는 사람이 헛걸음할 일이 줄어듭니다.

작업이 필요 없다고 판단된 파트는 사유를 남기고 작업없음으로 종료할 수 있습니다.

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

상태를 사람이 옮겨 적지 않게 했습니다

일반적인 흐름에서는 필수 파트가 모두 끝나면 이슈가 검수요청으로 넘어갑니다. 확인한 사람이 확인완료로 종결하거나 재수정요청으로 되돌립니다. 이슈 상태를 누가 따로 갱신하지 않아도 파트 진행 상황에서 계산됩니다. (협의필요·보류처럼 사람이 직접 지정한 상태는 이 계산보다 우선합니다.)

옮겨 적는 사람이 없으면 병목도, 누락도 없습니다. 조직이 텔레그램 봇을 연결하고 담당자가 계정을 연동해 두면 자기 차례일 때 알림도 받습니다.

화면을 기준으로 쌓게 했습니다

저희가 내린 결론은 단순했습니다. 서비스는 사람이 눈으로 보는 화면이 먼저입니다. 그렇다면 오류를 적는 것도, 고친 것을 기록하는 것도 화면을 기준으로 두는 편이 가장 자연스럽습니다.

그래서 프로젝트마다 화면 목록(화면 카탈로그)을 두고 이슈를 거기에 연결합니다. 손으로 적지 않으니 표기가 흩어지지 않고, 그러면 비로소 셀 수 있게 됩니다.

화면별 수정이력. 화면을 고르면 그 화면에 연결된 이슈와 각 이슈의 상태 변경 이력이 펼쳐집니다. 감이 아니라 목록으로 봅니다.

④ 캡처를 붙이는 일이 매번 번거로웠습니다

세 가지라고 했지만 사실 하나가 더 있었습니다. 버그 리포트에서 이미지는 문장 열 줄보다 빠른데, 그걸 붙이는 과정이 늘 성가셨습니다.

캡처 도구로 찍고 → 파일로 저장하거나 클립보드에 담고 → 브라우저로 와서 → 첨부 버튼을 누르고 → 파일을 찾아서 → 올립니다. 여러 장이면 이걸 장수만큼 반복합니다. 화살표 하나 그리려면 또 다른 편집기를 열어야 하고요.

한 건이면 아무것도 아닌데 하루에 수십 건이면 이 왕복이 그대로 시간이 됩니다. 그래서 결국 "말로 때우고" 캡처를 생략하게 됩니다. 그리고 그 이슈는 나중에 "이게 무슨 말이지"가 됩니다.

그래서 캡처 도우미를 따로 만들었습니다. 컴퓨터에 설치해 두고 트레이에 상주시키는 작은 프로그램입니다.

찍는 방법을 상황에 맞게 나눴습니다. 단축키 하나로 전체 화면, 다른 하나로 드래그한 영역, 또 하나로 고정해 둔 영역을 찍습니다. 마지막 것이 의외로 요긴합니다. 회귀 검수처럼 같은 자리를 반복해서 찍을 때 매번 드래그할 필요가 없습니다. 움직임으로만 설명되는 버그는 화면 녹화(GIF) 로 남깁니다.

찍자마자 그 자리에서 편집합니다. 다른 편집기를 열 필요가 없습니다. 편집 도구는 QA에서 실제로 쓰는 것만 넣었습니다.

• 사각형과 화살표로 어디가 문제인지 표시
• 번호 스탬프로 재현 순서를 1·2·3으로
• 짧은 텍스트 메모
• 필요 없는 부분 잘라내기
• 모자이크·블러로 가리기 — 실계정이나 고객 정보가 찍혔을 때

도형 라이브러리도, 레이어도, 필터도 없습니다. 있으면 오히려 시간을 씁니다.

실제로 이런 모양이 됩니다. 번호로 지점을 가리키고, 문제 영역을 네모로 묶고, 한 줄 적습니다. 여기까지 30초면 됩니다.

무엇보다 붙여넣기라는 단계 자체가 없습니다. 도우미를 켜둔 채 평소처럼 캡처만 하면, buggle의 캡처 버튼을 눌렀을 때 방금 찍은 것들이 이미 목록으로 떠 있습니다. 거기서 여러 장을 골라 한 번에 첨부하면 끝입니다. 클립보드를 거치지도, 파일 탐색기를 열지도, 저장 위치를 기억하지도 않습니다.

이슈의 캡처 버튼을 누른 화면. 조금 전 찍어둔 캡처들이 이미 올라와 있고, 클릭해서 여러 장을 고른 뒤 한 번에 첨부합니다.

캡처는 기본적으로 그 컴퓨터에만 있습니다. buggle에서 직접 첨부하기 전까지는 서버로 올라가지 않고, 로컬 보관분도 기본 7일·최대 100개까지만 두고 오래된 것부터 자동으로 지웁니다. 화면 캡처에는 남에게 보이면 곤란한 것이 섞이기 쉬우니, 기본값을 그렇게 잡았습니다.

Windows와 macOS(Apple Silicon)를 지원합니다. 도우미가 꺼져 있으면 캡처 버튼을 눌렀을 때 자동 실행을 시도하고, 그래도 안 되면 설치 안내를 띄웁니다.

돌아보면 이것도 같은 이야기입니다. 기능을 많이 넣는 게 아니라, 원래 하던 일 사이에 끼어 있던 단계를 없애는 것.

아직 못 한 것

만든 이야기만 적고 끝내면 공평하지 않으니, 지금 안 되는 것도 적습니다.

• 전용 모바일 앱이 없습니다. 모바일 웹은 대응했지만 앱스토어에 올라간 앱은 없습니다.
• 결제 창구를 아직 열지 않았습니다. 기능은 준비돼 있고, 지금은 얼리버드 기간이라 플랜과 관계없이 상위 플랜 한도로 쓰실 수 있습니다. 정식 오픈에 맞춰 열 예정입니다.
• 연동할 수 있는 외부 도구가 아직 적습니다. 텔레그램 알림과 AI 도구 연동(MCP)은 되지만, 협업 도구 연동은 더 늘려야 합니다.

도구를 만드는 일은 끝이 없어서, 이 목록은 계속 바뀔 겁니다. 다만 없는 걸 있다고 말하지는 않으려 합니다.

불편한 점을 알려주세요

이 목록에서 다음에 무엇을 만들지는 쓰시는 분들이 정해 주시는 게 가장 정확합니다.

• 쓰다가 불편했던 것
• "이건 왜 이렇게 되나" 싶었던 것
• 이 도구와 연동됐으면 하는 것
• 있었으면 하는 기능

무엇이든 편하게 보내 주세요. 크기와 상관없이 봅니다. 저희가 겪은 문제로 시작한 도구라, 다른 팀이 겪는 문제도 같은 방식으로 듣고 만들려고 합니다. 필요하다고 판단되면 바로 작업해서 알려드리겠습니다.

앱에 로그인하시면 상단의 개선요청 버튼으로 바로 보내실 수 있습니다.

마지막으로

buggle이 세상에 없던 걸 만들었다고 생각하지는 않습니다. 시트도, 메신저도, Jira도 각자 잘하는 일이 있습니다.

다만 저희가 계속 부딪히던 자리 — 고친 것과 올라간 것 사이, 고쳐졌다는 사실이 전해지는 길목, 같은 화면이 반복해서 터지는 지점 — 거기에 맞춘 도구가 필요했고, 없어서 만들었습니다.

엑셀보다는 강력하게, Jira보다는 가볍게. 그 사이 어딘가입니다.

각 상황을 더 자세히 적은 글도 있습니다. 외주 프로젝트의 버그 관리 · 고객사와 검수 공유하기 · 자체 서비스 운영팀의 제보 누수.