
안녕하세요! 카카오페이 QA팀 찬스입니다.
익숙한 것이 하나도 없는 상황에서 정신없이 몇 번의 QA 기간을 보내고 나서 눈에 들어온 것이 있었습니다. 유독 높았던 버그의 리오픈(다시 열림) 수치였습니다. 등록한 전체 버그 티켓 중 15~25%라는 한번도 본 적 없는 높은 수치의 리오픈 티켓들을 보면서 새로운 곳에서 적응하지 못하고 있는 것은 아닌지, 난 여기까지인건지 혼자 고민도 많이 했었습니다. 그렇다고 좌절을 했던건 아니고, '카카오페이에서의 첫번째 업무 개선은 리오픈 티켓을 줄이는 것이다!' 라는 생각을 했었어요.
입사 10개월차를 정신없이 보내고있는 지금 어떻게 되었는지 한번 점검해 보았습니다.

내가 원래 닫힌 티켓을 다시 여는 사람이 아닌데..
이미 한 번 수정을 거친 버그가 QA에게 전달되었는데, 그것이 닫히거나 닫히지 않은 채로 다시 개발자에게 돌아간다면 그 작업에 연관된 모든 사람들이 두 번이나 같은 작업을 하게 됩니다. 디버그하는 개발자, 검증하는 QA, 그 외에도 버그 수정에 필요한 다양한 관계자들과의 소통.. 이런 행위들은 한 번으로 마치는 것이 발견한 버그를 최소한의 리소스로 수정하는 방법중 하나일거에요.
라는 생각으로 버그 티켓을 관리해온터라 저에게 버그 티켓 리오픈은 자주 있는 일이 아니었는데, 왜 이렇게 된건지 먼저 파악해봤습니다. 그리고 정신없이 테스트하고 버그를 쳐내느라 외면하고 있던 찜찜함을 발견했습니다.

같이 일하는건 처음이라 어려움
카카오페이에 와서 TE(Test Engineer)분들과 처음 손발을 맞춰보게 되었습니다. TE분들과는 어떻게 일해야 하는지 알지 못한 상태에서 QA를 진행하는 것은 저 혼자 하는 것보다 훨씬 신경쓸게 많았죠. 안그래도 새로 익혀야 할 것이 산더미인 상태에서 저와 같이 신규 투입되신 TE분들과 같이 서비스를 파악하고 손발을 맞춰가는 과정은. '다 집어던지고 나 혼자 하고싶다!' 라는 생각을 할 정도로 체력을 쓰는 일이었습니다. (저도 처음 온 곳이고, 아는게 없는데 TE분들한테도 알려드릴 것들을 준비하고 파악하느라 진짜 정신도 자신도 없어지던 시절이었네요..)
그렇게 주니어 TE 두분과 QA를 시작하게 되었지만, 철저히 파악된 상태가 아니라 QA를 진행하며 동시에 익히고 맞춰가는 '꾸역꾸역' 상태에 빠져버렸습니다.

그거 그렇게 하는거 아닌데
이런 상황에서 제가 잘못 판단한 것이 있었습니다. 아직 TE분들이 서비스 파악이 제대로 되지 않았다는 생각에, 버그를 발견하면 우선 TE분들께 버그를 설명한 뒤 티켓 등록을 요청 드리고 저는 관련 영향 범위나 원인을 파악하는데 열중했었죠.
사람의 말을 통해 작성되다 보니 버그의 핵심이 누락되거나 의사소통 과정에서 오해가 생겼고, 결국 제가 버그를 발견했을 때 개발자 분들께 전달하고 싶은 내용이 잘 전달되지 않았어요. 제가 확인한 버그를 대신 등록해주시느라 머리 싸매셨을 TE분들께 지금이라도 죄송..
제가 발견했고 TE분들께 설명 드릴 정도로 잘 파악하고 있는 버그였지만 그 티켓만 보면 저도 이게 무슨내용인지 알아보기 어려웠어요. 저도 그런데 버그를 수정해야하는 개발자 분들은 더더욱 이해하기 힘드셨었을거라 생각합니다.

일하는 방식 먼저 맞추기
현상과 원인(으로 의심되는 것)을 파악하고 TE분들과 같이 회고 시간을 가졌습니다. 여러가지 좋았던 점과 아쉬웠던 점, 잘한 것과 잘 못한 것, 해보고 싶은 것들에 대해 이야기를 나눴고 저는 액션 아이템으로 '리오픈 수치 줄이기'를 제안하게 되었습니다.
리오픈 수치를 줄이기 위해 먼저 버그 티켓 작성에 대한 가이드라인이나 기준을 정했습니다.
<요약은 짧은 한 문장으로, 내용은 핵심을 전달하기, 재현 방법은 누구나 그대로 따라만하면 100% 재현이 가능하도록.>
먼저 버그는 현상만을 단순히 설명하기 보다 현상과 더불어 그로 인해 발생하는 핵심 문제를 같이 작성하기로 했고, 재현 스텝은 TC를 쓰듯이 상세하게 단계적으로 작성하기와 같이 별로 대단한 것은 아니었습니다. 사실 누구나 알고 있지만 바쁘다거나 이정도만 해도 괜찮다 라는 이유로 잘 지켜지지 않는 것들을 지키기로 했을 뿐이에요. 요약과 내용은 어떤 내용을 포함해야 하는지, 어떤 포맷으로 작성해야 하는지 이정도요.
기본적으로 저와 TE분들이 작성하는 버그 티켓은 가이드라인을 지키려고 노력했어요. 그리고 혹시나 미비한 점이 있으면 발견하는 사람이 내용을 채워주면서 최소한 저희가 등록한 버그 티켓들의 품질을 올리려고 했습니다.

리오픈이 줄었슴다
지난 시간동안 해왔던 리오픈 줄이기의 결과를 오늘 확인해 보았습니다. 사실 체감상 많이 줄었다는 느낌은 받고 있었지만 실제로 결과를 열어보니 더 놀라운 결과를 확인할 수 있었습니다.

(데이터는 % 기준으로 표시되었습니다.)
최초 두 번의 과제를 진행하고 나서 리오픈 티켓의 비율이 20%가 넘는다는 문제가 있다는 것을 인지했고, 위에서 말한 가이드라인을 지켜서 버그 티켓을 작성하기 시작했어요. 10개월이 지난 후 그 결과는 말도 안될 정도로 놀라웠습니다. 두 번의 적응 기간이 필요했는지 지지부진한 모습이 있었지만, 5번째 과제부터는 리오픈 티켓이 0~2%로 거의 발생하지 않았던 것을 알 수 있었어요!😂
과제 12는 현재 절반정도 진행한 상태라 아직 끝나진 않았지만 앞으로 남은 기간에 엄청 많은 버그가 새로 발견되지는 않을 것으로 생각됩니다. 아마도 리오픈 비율은 5% 미만으로 끝날거라 예상합니다.
이 결과를 열어보고나서 든 생각은 '기본만 지켜도 중간 이상은 간다.' 였어요. 저희는 정말 특별한 일을 한게 아니었거든요. 버그 티켓 잘 쓰는법 이라고 검색만 해도 수두룩하게 나오는 내용들일겁니다. 다만 제가 정신없다는 이유로 기본을 지키지 않았던 것 뿐이죠.

마무리
이 일을 겪고 배운건 두개에요.
1. 아무리 적어도 누군가와 같이 일하는건 어렵다. 그러니까 손발 먼저 맞추자.
2. 잘 하는 사람들이 하라는 것만 지켜라.(정 안되면 반 만이라도..?)
카카오페이에서 새롭게 배우고 있는 '같이' 일하는법. TE분들 뿐만 아니라 AI 과제를 함께하는 QA분들과도 같이 일하는 것은 어떻게 하는건지 천천히 깨지면서 배우고있습니다. 3년, 5년 뒤에는 이런 일에도 능숙해져서 고민하는 밤이 덜 찾아오길 바래봅니다!
'품질 인사이트' 카테고리의 다른 글
| AI가 생성한 결과물을 평가하기 (0) | 2025.11.21 |
|---|---|
| Chrome 개발자도구에서 API 응답 조작하기 (5) | 2025.07.05 |
| 테스트 너머의 QA 엔지니어링 집필 후기 (2) | 2024.12.11 |
| LLM 기반 체크리스트 생성 툴 공유 (3) | 2024.11.04 |
| QA 직무 오프라인 강의 진행 후기 (3) | 2024.06.01 |