• 02 Dec, 2025
• • 품질

제 PC에선 안 그러는데요? - 개발자와의 영원한 신경전

제 PC에선 안 그러는데요? - 개발자와의 영원한 신경전 이 말을 들으면 심장이 철렁한다. 버그 리포트 올렸다고 개발팀 슬랙 채널에 댓글 달면, 정확히 이 말이 돌아온다. 매번이다. 정말 매번이다. 어제도 마찬가지였다. 로그인 화면에서 비밀번호 입력 후 뒤로가기 버튼 누르면 앱이 크래시 되는 버그를 찾았다. 갤럭시 S21, 안드로이드 12, 특정 네트워크 환경에서만 재현됐다. 재현 스텝 6줄, 스크린샷 3장, 로그 파일까지 첨부했다. 서툴지 않다고 생각했다. 개발자 김인호가 답했다. "어? 제 PC에선 안 그러는데요? 그리고 저 버튼 눌러본 적도 없는데 왜 누르시는 거예요?" 이게 뭐 하는 말이야.재현 못 하는 버그의 무력함 문제는 간단해 보이는데 복잡하다. 나는 진짜 버그를 찾은 거다. 스크린샷도 있고, 재현 스텝도 명확하고, 로그에도 에러 메시지가 떴다. 근데 개발자 PC에선 안 나온다. 이게 뭐 하는 일인가.처음엔 이게 일반적인 일인 줄 몰랐다. 신입 때는 모든 버그가 재현되는 줄 알았다. 테스트 케이스 만들고, 실행하고, 버그 나오고, 개발자가 고치고 끝. 그렇게 단순할 줄 알았다. 하지만 QA 4년차인 지금 안다. 재현 못 하는 버그가 더 많다는 걸. 이게 진짜 일이구나. 이게 진짜 스트레스구나. 재현 못 하면 뭐가 되냐? 버그 등록도 애매해진다. Jira에 어떻게 쓸까. "확인 됨? 미확인? Known Issue? Needs More Information?" 이것도 고민이다. 개발자는 Needs More Information이라고 달면서 나한테 더 자세한 정보를 달라고 한다. 근데 더 뭘 주지. 내가 이미 다 줬는데. 배포 이후 사용자한테서 버그 리포트 들어오면 더 답답하다. "사용자가 보고한 버그를 재현 못 했습니다"라고 개발팀에 보고하면, 그럼 뭐하냐는 눈빛으로 본다. 너희 QA는 뭐 해주는 건데, 재현도 못 했어? 내가 뭐를 해야 하는 거다.환경 변수의 악마 이 모든 게 환경 때문이다. 개발자가 쓰는 PC와 테스트 기기, 사용자 폰이 다르다. 네트워크 상태도 다르고, 안드로이드 버전도 다르고, 제조사별 커스텀도 다르다. 심지어 캐시 상태, 저장소 용량, 백그라운드에 돌고 있는 앱까지도 영향을 준다. 나는 이 모든 걸 고려해서 테스트한다. 갤럭시, LG, 삼성, 소니 폰. 안드로이드 8부터 13까지. Wi-Fi, 4G, 5G, 약한 신호 상태. 특정 앱이 백그라운드에서 돌 때. 저장소 용량이 거의 없을 때. 화면 회전. 다크모드. 폰트 크기 조정. 접근성 옵션 활성화. 개발자는 주로 최신 Mac에서 에뮬레이터로 테스트한다. 깔끔한 환경. 캐시도 없고, 다른 앱도 거의 없고, 저장소는 충분하다. 그 환경에선 안 나온다. 당연하지. "제 PC에선 안 그러는데요"라는 말은 사실 말이다. 진짜 안 나온다. 내가 거짓말하는 게 아니고, 개발자가 거짓말하는 것도 아니다. 그냥 환경이 다르다.근데 이 말을 들으면 진짜 화난다. 왜? 왜냐하면 내가 하는 일을 폄하하는 것처럼 들리기 때문이다. "너네 테스트가 이상한 거 아니야? 내가 개발한 코드는 완벽한데 너네 환경에서만 문제 나는 거지 뭐"라는 뉘앙스다. 아니다. 사용자들이 다양한 환경에서 쓴다. 그게 내가 테스트하는 이유다. 개발자가 완벽하게 만든 코드도, 사용자 환경에서는 문제가 날 수 있다. 그 문제를 먼저 찾아주려고 나는 여기 앉아 있는 거다.버그인지 스펙인지 헷갈릴 때 어제 또 다른 버그가 올라왔다. 이번엔 결제 화면에서 상품 개수를 99개까지 조정할 수 있는데, 100개를 넘어가는 경우를 테스트했다. EditText에 직접 100을 입력할 수 있었다. 이게 버그인가? 스펙인가? 나는 버그라고 생각했다. 일반적으로 상품 개수는 최대 99개까지만 가능하게 UI를 제한한다. 그런데 여기선 뭔가 숨을 쉴 수 있는 구멍이 있었다. 이걸 막아야 한다고 생각했다. 개발자는 달랐다. "아, 그건 스펙이에요. 관리자를 위해서 100개 이상도 가능하도록 열어뒀어요." 처음 들었다. 그런 스펙은 어디에 있나. 요구사항 문서엔 없다. 기획서엔 없다. 슬랙 채널 어딘가에 있나? 아니다. 개발자가 임의로 정한 것 같다.이게 QA의 제일 어려운 부분이다. 버그인지 스펙인지 판단하는 거. 개발자들은 스펙이라고 하면 일단 스펙인 거고, 버그는 버그인 거다. 근데 스펙이 명확하지 않으면 어떻게 하나. 나는 기획팀에 물어본다. 기획팀도 처음 본다고 한다. 그럼 개발자한테 다시 물어본다. "어디서 이 스펙이 나왔어요?" "아, 제가 임의로 추가했어요." 그럼 버그지 뭐. 하지만 이미 개발된 상태다. 다시 고치려면 리뷰도 해야 하고, 테스트도 다시 해야 한다. 번거롭다. 보통 "일단 Known Issue로 두고 다음 버전에서 수정하자"고 된다. 근데 다음 버전에서도 안 고쳐진다.신뢰를 만드는 방법 그런데 정말로 일 잘하는 QA와 개발자의 팀은 다르다. 신뢰가 있는 팀 말이다. 우리 팀에는 테스트리드 박수진이가 있다. 3년 전에 들어온 사람인데, 지금은 거의 QA 리더 역할을 한다. 그 사람이 버그를 올리면 개발자들이 다르다. 바로 확인한다. 재현 못 했어도 "확인해볼게"라고 한다. 왜? 박수진이의 버그 리포트는 정확하기 때문이다. 박수진이의 비결을 봤다. 첫째, 버그 재현 스텝이 정말 명확하다. "1단계: 로그인. 2단계: 비밀번호 입력 창에서 복붙 실행. 3단계: 백스페이스로 모두 삭제. 4단계: 뒤로가기 버튼 클릭." 이런 식이다. 복잡한 말은 없다. 둘째, 스크린샷과 로그를 잘 찍는다. 버그가 나타나는 정확한 순간의 스크린샷. 그리고 logcat에서 관련 에러 메시지만 추출해서 코드 스니펫처럼 첨부한다. 셋째, 개발자를 존중한다. 버그를 올릴 때도 "혹시 제 테스트 환경 문제일 수도 있지만"이라고 시작한다. 그리고 개발자가 "제 PC에선 안 그러는데요"라고 해도, 바로 함께 재현해본다. 개발자 PC에도 설치해보고, 개발자 환경에 맞춰서 테스트한다. 그러다 보니 "아, 이 환경에서만 나오네요"라고 발견하거나, 때론 정말로 내 환경 문제인 걸 알 수도 있다. 그럼 개발자들이 박수진이를 다르게 본다. "수진아, 버그 올려줄래? 너 올린 건 믿고 가"라고 한다. 심지어 개발자들이 자기 코드에 자신 없으면 박수진이에게 먼저 테스트해달라고 부탁한다. [IMAGE_4] 나도 그렇게 하려고 한다. 근데 정말 힘들다. 하루에 테스트할 게 너무 많다. 요구사항 문서를 다시 읽고, 개발자들과 미리 회의하고, 재현 스텝을 정리하고... 시간이 없다. 그래도 최근 3개월간 노력했다. 주 1회 개발팀과 테스트 전략 회의를 했다. "이번 스프린트에선 어떤 부분을 집중해서 테스트할까?"라고. 개발자들과 의논해서 고위험 영역을 미리 파악했다. 그 결과 버그 재현율이 올라갔다. 개발자들도 내 버그 리포트를 더 빨리 처리하기 시작했다. 뭐가 달라졌냐? 신뢰다.버그가 안 나오는 게 가장 무서운 일 역설적이지만, QA로서 가장 무서운 건 테스트할 때 버그가 안 나오는 거다. 배포하고 나서 사용자한테서 버그가 들어오는 게 가장 답답하다. 어제는 새로운 결제 모듈을 배포했다. 3주간 매일 테스트했다. 아침 9시부터 저녁 6시까지. 점심시간만 빼고. 결제 프로세스의 모든 경로를 테스트했다. 정상 결제, 결제 실패, 취소, 환불, 네트워크 끊김. 심지어 결제 중에 앱을 강제 종료하고 다시 켜봤다. 결과? 버그 없음. 배포 완료. 그리고 오늘 아침, 사용자 1명이 "결제 후 영수증이 없어요"라고 신고했다. 영수증? 내가 뭘 놓쳤지. 다시 확인해봤다. 오 맞다. 결제 완료 후 영수증 페이지가 없었다. 근데 내가 왜 테스트 안 했지? 요구사항 문서를 다시 읽어봤다. 있다. "결제 완료 후 영수증 페이지 표시"라고. 내가 빠뜨렸다. 나는 결제 성공까지만 확인했다. 그 다음은 테스트하지 않았다. 체크리스트에 없었다. 아니, 있었나? 다시 봐도 없다. 그럼 내가 만드지 않았나? 3주 전 테스트 플랜을 찾아봤다. 아, 있네. 뭔가 했던 메모가. "영수증 페이지 테스트 완료"라고. 그럼 뭐가 문제야. [IMAGE_5] 개발자한테 물었다. "영수증 페이지, 스펙이 변경되지 않았나요?" 개발자가 답했다. "아, 그건 나중에 추가되는 거 아닌가요?" 그게 뭐 하는 소리야. 너가 구현한 기능인데. "몰라요. 정의 안 됐어요." 결국 나 때문이다. 내가 체크리스트에 넣고도 테스트를 빠뜨렸거나, 개발자가 아직 구현하지 않았는데 내가 완료했다고 체크했거나. 둘 다 내 책임이다. 이게 QA의 일이다. 버그를 찾는 것도 일이지만, 버그를 놓치지 않는 게 더 중요한 일이다.다음 주는 또 다른 싸움 내일 또 새로운 빌드가 나온다. 소셜 로그인 기능. 마찬가지로 3주간 테스트할 거다. 체크리스트를 만들었다. 사실 이미 만들어놨다. 지난주에. 테스트 항목: 50개. 테스트 케이스: 150개. 예상 테스트 시간: 30시간. 실제 주어진 시간: 2주. 다시 말해서, 하루에 8시간을 테스트에만 써야 한다. 버그 리포팅, 개발자와의 미팅, 기타 업무는 따로다. 즉, 야근은 필수다. 개발자가 또 말할 거다. "제 PC에선 안 그러는데요." 나는 또 알 거다. 그건 너의 PC가 아니라는 거. 사용자의 환경이 다르다는 거. 그리고 내 일은 그 환경에서 버그를 찾는 거라는 거. 하지만 여전히 답답할 거다. 왜? 왜냐하면 의사소통이 부족하기 때문이다. 스펙이 명확하지 않기 때문이다. 개발자와 나 사이의 신뢰가 완벽하지 않기 때문이다. 그래도 한 가지는 안다. 내가 놓친 영수증 버그가 100명 사용자한테는 영향을 미치지 않았다는 거. 왜? 왜냐하면 1명만 신고했으니까. 즉, 79명의 사용자는 이미 마주쳤는데 신고하지 않았거나, 아직 그 경로를 지나가지 않았을 수도 있다. 최악의 경우, 조용히 앱을 삭제했을 수도 있다. 내가 할 수 있는 건 다음 번엔 더 꼼꼼히 하는 거다.제 PC에선 안 그러는데요 - 그래, 알겠어요 이 말을 들으면 아직도 짜증난다. 하지만 이제는 안다. 이건 싸움이 아니라는 거. 누가 잘못했는지를 판단하는 자리가 아니라는 거. 개발자는 자기 환경에서 코드가 제대로 작동하는 걸 본 거다. 그게 거짓이 아니다. 나는 사용자 환경에서 코드가 제대로 작동하지 않는 걸 봤다. 이것도 거짓이 아니다. 둘 다 진짜다. 그냥 환경이 다른 거다. 그래서 이제는 이렇게 대답한다. "네, 저도 알고 있어요. 그래서 저는 다양한 환경에서 테스트하는 거고, 개발자님은 PC 환경에서 테스트하시는 거예요. 저희가 함께 이 버그를 재현해볼까요?" 그럼 개발자도 다르게 반응한다. "아, 그럼 같이 해볼까요?" 신뢰는 이렇게 만들어진다. 하지만 여전히 밤샘 배포는 무섭고, 영수증 버그 같은 실수는 반복될 거고, 개발자와의 신경전은 계속될 거다. 그게 QA의 일이니까. 내일도 새벽까지 테스트해야 한다. "제 PC에선 안 그러는데요"라는 말을 준비하면서.아, 커피 더 마셔야겠다. 오늘도 길 거 같다. [IMAGE_6]