버그

소프트웨어가 잘못 도는 일 자체는 만들기 시작한 날부터 있었습니다. 없던 것은 그 일을 가리키는 공통의 이름과, 그것을 한 건씩 세는 방식이었습니다.

이름이 없을 때 대화는 이렇게 흘렀습니다. 고객이 "결제가 안 돼요" 라고 씁니다. 상담 담당이 그 말을 그대로 개발팀 채널에 옮깁니다. 개발자가 자기 브라우저에서 결제를 해 보니 잘 됩니다. 여기서 대화가 멈춥니다. 어떤 카드였는지, 어느 화면에서였는지, 오류 문구가 떴는지가 아무 데도 적혀 있지 않기 때문입니다. 같은 제보가 그 주에 세 번 더 들어와도 세 번 다 같은 자리에서 멈춥니다.

섞이는 것도 문제였습니다. "이 버튼이 안 눌려요" 와 "이 버튼이 오른쪽에 있으면 좋겠어요" 와 "이 기능이 아예 없어요" 가 한 채널에 한 줄씩 나란히 들어옵니다. 앞의 것은 약속이 깨진 일이고 뒤의 둘은 새로 만들어 달라는 요청입니다. 성질이 다른데 같은 줄에 있으면 무엇을 먼저 할지 정할 수가 없습니다.

버그라는 이름은 이 둘을 갈라 주려고 자리를 잡았습니다. 의도한 동작이 무엇인지 먼저 적고, 실제 동작이 그것과 다를 때만 버그로 부릅니다. 그래서 이 말에는 늘 기준이 따라붙습니다. 기준이 없으면 같은 현상을 두고 한쪽은 고장이라고 하고 다른 쪽은 원래 그렇다고 합니다.

발견된 순간 하나의 기록으로 바뀌는 데서 시작합니다. 머릿속이나 채팅창에만 있는 것은 아직 다룰 수 있는 상태가 아닙니다. 기록 하나에는 다섯 가지가 들어갑니다.

1. 한 줄짜리 제목. "결제 실패" 가 아니라 "해외 발행 카드로 결제하면 승인 단계에서 멈춤" 처럼 어디서 무엇이 어긋나는지가 드러나야 합니다.
2. 재현 절차. 같은 현상을 다시 일으키는 순서를 번호로 적은 것입니다. 이것이 없으면 고치는 사람이 먼저 한 시간을 들여 상황을 되살려야 합니다.
3. 기대 동작과 실제 동작. 두 줄을 나란히 적습니다. 이 두 줄이 있어야 버그인지 아니면 처음부터 그렇게 만든 것인지가 판정됩니다.
4. 환경. 브라우저와 운영체제와 계정 종류와 시각입니다. 특정 조건에서만 나는 결함이 전체의 상당수라 이 줄이 범위를 좁혀 줍니다.
5. 심각도. 그 결함이 서비스에 끼치는 영향의 크기입니다. 결제가 막히는 것과 글자가 한 칸 어긋나는 것을 같은 줄에 두지 않으려고 붙입니다.

기록이 생기면 정해진 길을 따라갑니다. 접수한 사람이 재현을 확인하고, 심각도와 우선순위를 정하고, 담당자가 원인을 찾고, 고치고, 회귀 테스트로 다른 데가 깨지지 않았는지 보고 닫습니다. 마지막 단계를 건너뛰면 한 곳을 고치다 옆을 깨뜨린 채 닫는 일이 생깁니다.

모든 기록이 고쳐지는 것으로 끝나지는 않습니다. 재현이 안 돼 보류로 닫히거나, 고칠 값이 없다고 판단해 닫히거나, 원래 그렇게 만든 것으로 확인돼 닫히기도 합니다. 셋 다 정상적인 결말이고, 무엇으로 닫았는지를 적어 두는 것이 다음에 같은 제보가 왔을 때의 시간을 아껴 줍니다. 닫은 뒤에 같은 현상이 다시 올라오면 새 기록을 만드는 대신 그 기록을 다시 엽니다.

품질 보증 절차의 한가운데에 있습니다. 릴리스 전에 확인하는 사람은 발견한 것을 전부 기록으로 남기고, 내보낼지 말지는 그 목록을 보고 정합니다. 이때 기준선을 미리 정해 두는 것이 보통입니다. 심각도가 높은 것만 고치고 나머지는 다음 주기로 넘긴다는 식입니다.

고객 지원 쪽에서는 문의가 버그로 바뀌는 지점이 중요합니다. 들어온 문의 대부분은 사용 방법을 몰라서 생긴 것이고, 그중 일부만 실제 결함입니다. 상담 담당이 재현 절차를 받아 적어 넘기면 개발팀에서 판정하는 시간이 크게 줄어듭니다.

계획을 짤 때도 자리를 잡아 둡니다. 한 주기의 작업 가운데 일정 비율을 버그 수정에 미리 배정하는 방식이 흔합니다. 새 기능만 담아 두면 목록이 쌓이다가 어느 시점에 한 번에 터지고, 그때는 몇 주를 고치는 데만 쓰게 됩니다. 비율은 팀마다 다르고, 오래 굴린 제품일수록 높게 잡습니다. 쌓인 코드가 많을수록 손볼 곳도 함께 늘기 때문입니다.

"이거 버그인가요, 원래 그렇게 만든 건가요?"

기대 동작이 무엇으로 정해져 있는지를 묻는 말입니다.

"재현이 안 돼서 일단 닫았는데 같은 제보가 또 왔어요."

특정 조건에서만 나는 결함일 가능성이 높으니 환경 정보를 더 받아야 한다는 뜻입니다.

"이번 릴리스는 높은 것만 고치고 나머지는 다음으로 넘길게요."

목록 전체를 비우지 않고 기준선 위만 처리한 뒤 내보내겠다는 결정입니다.

페이지덱에서는 수아가 고객에게서 받은 제보를 그대로 넘기지 않습니다. 어느 화면에서 무엇을 눌렀을 때였는지, 오류 문구가 떴는지, 다른 브라우저에서도 같은지를 되물어 적은 뒤에 넘깁니다. 이 한 번의 되묻기가 개발팀의 판정 시간을 반나절씩 줄입니다.

넘어온 기록은 태오가 재현부터 확인합니다. 재현되면 심각도를 붙이고, 높은 것은 그 주에 처리하고 나머지는 목록에 쌓아 둡니다. 지현은 주기를 시작할 때 그 목록에서 일정 몫을 덜어 계획에 넣습니다.

버그는 모두 고쳐야 한다고 보는 경우가 가장 많습니다. 결함을 남겨 두는 것이 품질을 포기하는 일처럼 보이기 때문입니다. 하지만 고치는 데에도 비용이 들고, 고치는 과정에서 새 결함이 생기기도 합니다. 1년에 두 번 특정 조건에서만 나는 화면 어긋남을 고치려고 결제 흐름을 건드리는 것은 남는 거래가 아닙니다. 이 판단을 하지 않으면 목록이 수백 건으로 불어나고, 정작 급한 것이 그 안에 묻혀 보이지 않게 됩니다.

버그 개수를 품질 점수로 읽는 것도 흔합니다. 적게 보고될수록 좋은 제품이라는 계산은 자연스럽습니다. 하지만 보고 건수는 제품의 상태만큼이나 얼마나 많이 쓰이는지와 제보 경로가 얼마나 편한지에 좌우됩니다. 사용자가 두 배로 늘면 보고도 두 배로 늘고, 제보 버튼을 화면에 붙이면 또 늘어납니다. 이 숫자를 평가에 쓰기 시작하면 팀은 제품을 고치는 대신 기록을 적게 남기는 쪽으로 움직이고, 그러면 무엇이 얼마나 깨져 있는지를 아무도 알 수 없게 됩니다.