??? ?? ? ???, ? ??? ??? ?? ?? ???, ??? ??? ?????? ?? ??? ??? ?? ? ??. ?? ?? ?? ??? ?? ?? ???? ???? ??. Credit: Roman Samborskyi / Shutterstock 버그 수정은 모든 개발자의 업무 중 하나다. 새로운 애플리케이션을 처음부터 개발하든, 30년 된 복잡한 레거시 시스템을 유지보수하든, 결국 버그는 고쳐야 한다. 하지만 버그를 수정하는 일은 쉽지 않다. 대부분의 개발자는 ‘하루는 재현하는 데 쓰고, 이틀은 원인을 찾느라 쓰다가, 결국 고치는 건 한 줄’이라는 경험을 한 번쯤 해봤을 것이다. 버그 수정의 난이도를 결정하는 요소는 다양하며, 그중 상당수는 팀이 통제할 수 없는 영역에 있다. 하지만 개발자가 얼마나 효율적으로 버그를 해결할 수 있는지를 결정짓는 핵심 요소가 하나 있다. 바로 버그 리포트의 품질이다. ‘이 기능이 하나도 작동하지 않습니다!’라는 말만 적힌 버그 리포트를 본 적이 있을 것이다. “무엇이, 어떻게 작동하지 않나요?”라고 물으면 돌아오는 대답은 “아무것도 안 돼요!”뿐이다. 이런 커뮤니케이션은 문제 해결에 도움이 되지 않는다. 도움이 되는 것은 ‘잘 작성된 버그 리포트’다. 하지만 이런 리포트는 찾아보기 힘들다. 좋은 버그 리포트를 작성할 수 있느냐가 훌륭한 개발자나 QA 테스터와 평범한 팀 구성원을 가르는 기준이 된다. 잘 작성된 리포트는 문제를 쉽게 재현할 수 있게 해준다. 결국, 재현할 수 있어야만 버그를 고칠 수 있다. 좋은 버그 리포트에는 다음 다섯 가지 요소가 반드시 포함돼야 한다고 생각한다. 구체적으로 살펴보자. 좋은 버그 리포트를 위한 다섯 가지 요소 명확하고 간결한 제목 문제를 재현하는 구체적인 단계 실제 동작과 기대 동작의 비교 관련 맥락과 시스템 정보 그 외 유용한 추가 정보 1. 명확하고 간결한 제목 버그 리포트에서 가장 과소평가되는 요소 중 하나가 제목이다. 대부분의 이슈 트래커는 제목을 검색 결과나 목록에서 가장 눈에 띄는 위치에 배치한다. 따라서 제목만 보고도 어떤 문제인지, 어떤 버그인지 명확히 알 수 있어야 한다. 시간을 들여 제목을 신중하게 작성하자. 기본적인 문제가 무엇인지 모든 사람이 쉽게 이해할 수 있는 제목이라면, 해당 이슈에 대한 대응도 수월해진다. 많은 사람들이 그 제목을 읽게 되므로, 간결하면서도 명확하게 표현하는 것이 중요하다. 2. 문제를 재현하는 구체적이고 간단한 단계 버그 리포트의 핵심이자 가장 중요한 부분이다. 재현할 수 없는 버그는 고치기 어렵다. 개발자가 실제로 버그가 발생하는 장면을 확인할 수 없다면, 수정도 기대하기 어렵다. 따라서 오류를 유발하는 과정을 상세히 설명하는 것이 문제 해결의 출발점이다. 단순히 “POS를 열고, 상품을 판매하고, 카드로 결제하면 에러 발생”이라고 적는 것은 충분하지 않다. 클릭한 위치, 입력한 키 등 모든 행동을 단계별로 구체적으로 기록해야 한다. 세부 단계가 많다고 불평하는 개발자가 있다면, QA 담당자는 오히려 자신의 역할을 제대로 해냈다고 생각해도 된다. 그만큼 리포트를 잘 작성한 것이다. 3. 실제 동작과 기대 동작의 비교 모든 버그는 ‘원래 이렇게 되어야 하는데, 실제로는 다르게 동작했다’는 상황에서 발생한다. 출력값이 잘못되었거나, 애플리케이션이 갑자기 종료됐거나, 다양한 형태일 수 있다. 따라서 좋은 버그 리포트는 특정 단계를 따랐을 때 어떤 결과가 나와야 했는지, 그리고 실제로는 어떤 결과가 나왔는지를 명확히 구분해 서술해야 한다. 올바른 동작이 무엇인지 모르면, 잘못된 동작도 고칠 수 없다. 이 부분은 모든 리포트에 반드시 포함돼야 한다. 4. 관련 맥락과 시스템 정보 버그는 독립적으로 발생하지 않는다. 발생한 환경과 배경 정보를 함께 제공해야 한다. 예를 들어 고객에게 어떤 영향을 주고 있는지, 사용된 운영체제와 브라우저는 무엇인지, 데이터를 통해 문제를 확인할 수 있는 쿼리 정보 등도 포함하면 좋다. 문제가 발생한 원인과 그 영향 범위를 이해하는 데 필요한 정보를 빠짐없이 담아야 한다. 특히 사용자 인터페이스(UI) 관련 문제라면 스크린샷을 포함하는 것이 필수다. 화면에 어떤 일이 벌어졌는지를 시각적으로 보여주는 것이 큰 도움이 된다. 5. 그 외 유용한 추가 정보 정확히 정의하긴 어렵지만, 가장 유용한 추가 정보는 문제 발생 과정을 녹화한 영상이다. 실제로 오류가 발생하는 장면을 보면 상황을 빠르게 파악할 수 있다. 또 다른 유용한 자료는 오류를 재현할 수 있는 데이터베이스다. 많은 애플리케이션이 설정 정보를 데이터베이스에 저장하므로, 이 정보가 재현에 필요한 경우가 많다. UI 문제라면 스크린샷은 말할 것도 없이 필수다. 추가로 고려할 사항 ‘심각도’, ‘우선순위’, ‘고객 영향도’ 같은 속성은 리포트의 품질 요소로 보지 않는다. 이는 프로젝트 관리자에게는 유용하지만, 개발자가 버그를 고치는 데는 필수 정보가 아니다. 다만, 잘 정리된 리포트는 어떤 문제를 먼저 처리할지 결정하는 데 도움이 될 수 있다. 버그 리포팅 도구가 에러에 대한 스택 트레이스를 포함할 수 있다면, 그 정보도 함께 제공하는 것이 좋다. 해당 버그가 처음 등장한 빌드나 버전을 명시하는 것도 유용하다. 좋은 버그 리포트를 작성하는 일은 화려하지 않다. 때로는 다소 지루하게 느껴질 수도 있다. 하지만 팀의 성공에 중요한 기여를 하는 작업이다. 잘 작성된 리포트는 시간을 절약하고, 불필요한 좌절과 반복 작업을 줄이며, 개발 과정을 더욱 매끄럽게 만든다. 그러니 시간을 들여 제대로 작성하자. 버그는 피할 수 없지만, 그로 인해 발생하는 혼란은 충분히 줄일 수 있다.dl-ciokorea@foundryco.com ???? ???? ??? ??? IT ??? ???? ??? ????! ??? ??? ??? ?????. ????