이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 릴리즈를 앞두고 버그가 어디서 들어왔는지 추적이 안 돼서 같은 이슈를 두 번 수정하는 일이 발생했습니다.
GitHub 이슈에 릴리즈 버전 레이블을 붙이고, 관련 PR에 이슈 번호를 연결하는 방식으로 변경했습니다. 이슈를 열면 어느 릴리즈에서 발견되었고, 어느 PR에서 수정되었는지를 한 번에 볼 수 있게 되었습니다. 처음에는 팀원들이 레이블 붙이는 것을 귀찮아했으나, 두 번째 릴리즈부터는 이슈 히스토리가 깔끔해지면서 모두 납득하였습니다.
이슈 관리가 번거로운 것처럼 보일 수 있으나, 나중에 '이 버그 언제 들어왔지?'를 추적하는 시간이 훨씬 줄어든다는 것을 직접 비교해보았습니다. 릴리즈 후에 같은 이슈가 재발했을 때 히스토리가 있으므로 원인을 빠르게 찾을 수 있었습니다. 그 경험이 이슈 관리를 형식이 아니라 실제 도구로 활용하는 계기가 되었습니다.
팀 프로젝트에서 릴리즈 직전에 '이 이슈 해결됐어?'를 각자 물어보느라 혼란이 생기는 일이 반복됐어요. 모두 바쁜 상황에서 입으로만 확인하다 보니 빠지는 케이스가 생겼습니다.
릴리즈 전날 30분짜리 리뷰 미팅을 만들었어요. 이슈 보드를 화면에 띄우고 각 이슈 상태를 소리 내어 확인하는 방식이었는데, 처음엔 짧은 미팅이 필요하냐는 의견도 있었어요. 그런데 첫 번째 미팅에서 '해결된 줄 알았는데 아직 남은' 이슈가 두 개나 나와서 팀원들이 인정했어요.
미팅을 통해 상태 공유가 개인 작업과는 별개의 활동이라는 걸 팀이 이해하게 됐어요. 이슈를 닫는 것과 팀이 그걸 아는 것은 다른 문제라는 걸 배웠습니다. 그 경험이 릴리즈 관리에 대한 생각을 바꿔줬어요.
처음 QA를 진행했을 때 이슈가 한 번에 12개가 쏟아졌는데 어디서부터 봐야 할지 몰랐어요. 다 급하게 느껴져서 오히려 아무것도 제대로 못 하는 상황이 됐습니다.
이슈를 '릴리즈 블로커 / 기능 저하 / 미관 문제' 세 단계로 분류하는 기준을 만들었어요. 사용자가 핵심 기능을 사용 못 하면 블로커, 사용은 가능하지만 불편하면 기능 저하, 나머지는 미관 문제로 나눴습니다. 분류하고 나니 블로커 2개만 먼저 잡으면 된다는 게 보였어요.
나머지는 다음 릴리즈로 넘길 수 있어서 팀 스트레스도 줄었습니다.
이슈 관리에서 '얼마나 많은가'보다 '어떤 게 먼저인가'가 더 중요하다는 걸 그 경험에서 배웠어요. 우선순위가 없으면 모든 게 급하게 느껴지고, 있으면 집중이 됩니다. 그 경험이 이슈를 대하는 방식을 바꿔줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.