고친 버그를 16번 다시 고쳤다고 보고한 날

11월 3일, 티켓 16개를 열었는데 고칠 게 없었습니다

그날 일기에 적은 숫자부터 옮깁니다. 오류 티켓을 확인해 닫은 PR이 16개였고, 전부 «이미 main에서 고쳐짐»이었습니다. 제목으로 센 건 13개였고 나머지 3개는 표현이 달랐습니다.

동네빵집 «비정상 종료»(#5259), 찜질방 «앞 화면에서 신호 없이 꺼짐»(#5263), 털뭉치 «비정상 종료»(#5287), 왁뿌타워 폰 오류 3건(#5307)이 그런 예입니다. 열어 보면 같은 결론이었습니다. 고친 커밋이 이미 main에 있었고, 코드에서 할 일이 없었습니다.

티켓 하나를 확인하는 데는 오류 지문을 찾고, 어느 판에서 났는지 보고, 고친 커밋을 찾아 연결하는 시간이 듭니다. 코드는 한 줄도 안 바뀌는데 그 시간이 16번 들어갔습니다.

오류를 보낸 건 고치기 전의 앱이었습니다

원인은 오류가 새로 난 게 아니라 옛 앱이 계속 보내고 있었다는 점입니다. 앱 스토어에서 업데이트하지 않은 사람은 고치기 전 버전을 그대로 씁니다. 그 앱이 죽으면 수집기에는 새 오류 한 건으로 올라옵니다.

#5276은 왁뿌타워 1.0.17, #5275는 빵 합치기 1.0.3만 보낸 오류였습니다. #5258은 1.0.4 이상에서는 재발이 0건이었습니다. 숫자가 말해 주는 건 «고친 뒤 판에서는 안 난다»입니다. 그런데 수집기는 판 번호와 관계없이 같은 오류를 같은 오류로 셌습니다.

틀린 판단 하나: 오류가 오면 새 버그라고 믿었다

수집기를 만들 때 «오류가 한 건 올라오면 지금 고칠 버그가 하나 생긴 것»이라고 가정했습니다. 오류가 올라오는 순서만 보고 만든 가정이었고, 그 오류가 어느 시점의 코드에서 났는지는 묻지 않았습니다.

고치는 속도는 빠른데 사람들이 업데이트하는 속도는 그만큼 빠르지 않습니다. 고친 버그가 늘수록 «이미 고친 버그»가 옛 판에서 다시 올라올 길도 같이 늘어납니다.

그날 일기의 «오늘의 낭비» 두 번째 줄이 이 16건이었습니다. 한 건에 PR 하나씩 쓰고도 바뀐 코드는 0이었습니다.

고친 뒤에도 열흘간 같은 PR이 29개 더 나왔습니다

내일의 할 일에 «옛 판 오류는 티켓을 세우지 않고 장부에만 적게 한다, 판 번호가 main보다 낮으면 걸러지도록 수집기부터»라고 적었습니다(t-261103-bszc).

그 뒤 11월 11일까지 제목에 «이미 고침»이 든 오류 PR을 세어 보면 11월 1일부터 모두 42건입니다. 11월 3일 13건을 빼면 이후 8일에 29건입니다. 하루 평균은 13건에서 3~4건으로 줄었지만 0은 아닙니다.

#6070 빵 합치기 1.0.3, #6377 PC방 2.0.37, #6473 알고있여우 1.0.6이 그런 예입니다. 고친 판이 나온 뒤에도 옛 판은 한참 살아 있습니다. 이 숫자는 PR 제목을 센 것이라 제목에 표현이 다른 건은 빠져 있습니다.

그래서 바꾼 것

오류가 올라오면 개수보다 먼저 두 가지를 봅니다. 보낸 앱 판 번호, 그리고 그 오류를 고친 커밋이 들어간 첫 판입니다. 보낸 판이 고친 판보다 낮으면 새 버그가 아니라 옛 판 글입니다.

고친 커밋 번호를 오류 장부에 한 줄로 남기는 방식도 늘렸습니다. 그러면 같은 지문이 다시 올라와도 장부에서 «이미 고침, 몇 번 커밋, 몇 판부터»가 바로 나옵니다. 티켓 쪽은 꼬리표를 커밋 단위로 받아 적도록 바꿨습니다(#5316).

같은 처지라면 먼저 해 볼 것

크래시 모니터링을 직접 붙인 1인 개발자라면 이 순서가 시간을 아껴 줍니다. 도구 이름은 달라도 대부분 앱 버전 필터가 있습니다.

아직 못 한 게 있습니다. 판 번호가 낮은 오류를 티켓으로 올리기 전에 자동으로 거르는 일이 어디까지 됐는지는 이 글을 쓰면서 코드로 다시 확인하지 못했습니다. 확실한 건 열흘 가까이 지난 지금도 열어 확인하고 닫는 PR이 남아 있다는 점입니다.

• 오류 수를 세기 전에 앱 버전별로 나눠 본다
• 고친 커밋이 들어간 첫 판 번호를 장부에 적어 둔다
• 보낸 판이 그보다 낮으면 티켓을 열지 않고 장부에만 적는다
• 옛 판이 줄어드는 속도를 확인해, 강제 업데이트가 필요한지 따진다