● 개발자 여러분, 혹시 버그를 할당 받은 적이 있나요?
아직 없다고요? 조금만 기다리면 금방 할당 받을 꺼에요. 그런데 버그를 할당 받으면 정말 짜증이 날꺼에요.
그 이유는 여러분의 관리자들이 짜증나거나 상기된 표정으로 나타나 여러분을 괴롭힐 가능성이 높기 때문이에요.
● 버그는 언제 까지 잡을 수 있냐?
● 버그를 잡을 수 있는 대책이 뭐냐?
보통 버그가 나오면 버그와 관련된 기능을 맡고 있는 개발자에게 할당되는 경우가 많습니다.
왜냐면 버그 관련된 코드를 작성한 개발자가 해당 버그를 잘 수정할 확률이 높기 때문이죠.
그래서 여러분이 버그를 할당 받으면 여러분이 짠 코드에 논리적 오류가 있는 지 점검합니다. 코드를 분석하고 디버깅을 하죠. 여기까지 문제가 될 건 없습니다. 너무나 당연한 이야기죠.
그런데 문제는 다른 개발자가 짠 모듈의 버그를 여러분 보고 잡으라는 상황인데, 이런 상황을 겪으면 정말 짜증납니다.
동료가 퇴사를 했거나 휴가를 간 상황이면 짜증이 바다와 같이 밀려 오게 됩니다.
"내가 짠 코드도 아닌데 왜 나보고 문제를 잡으라고 하는 거지?"란 생각이 무의식적으로 들기 때문이죠.
아무튼 버그를 잡는 과정(코드를 분석하고 디버깅을 수행)은 아주 짜증나는 일이에요. 가장 큰 이유는 관리자들이 압박을 하기 때문이죠.
"차를 몰고 있는데 20톤 짜리 덤프 트럭이 요란한 경적을 울리면서 차 바로 뒤 범퍼에 딱 붙어 있는 느낌" 혹은 "스타크래프트에서 테란에게 10만년 조이기를 당하는 느낌"이라고 할까요? 관리자들은 다양한 방식으로 압박을 해오는데, 미소를 지으면서 버그를 언제까지 잡을 수 있는지에 대해 물어보거나 화를 내기도 합니다. 정말 다양한 종류의 관리자를 볼 수 있습니다.
개발자 입장에서는 디버깅을 할 때 뭔가 코드의 흐름이나 자료 구조가 눈에 보이고 버그를 유발하는 코드에서 뭔가 실마리가 보일 때는 그마나 버틸만합니다. 가끔은 이 과정에서 흥미를 느끼고 뭔가 개발자로써 실력이 느는 듯한 느낌도 받을 수 있습니다. 물론 아주 소수의 개발자이지만요.
그런데 버그에 대한 분석을 시작할 수 없는 앞이 캄캄한 상황을 맞이할 수 있습니다. 정말 이때 개발자가 받는 심리적인 압박감은 생각보다 큰데요.
이 때 개발자들은 대응하는지 이야기하겠습니다.
솔직히 털어놓는 개발자
차라리 솔직히 현재 상황을 털어 놓는 게 최선입니다. 욕을 먹더라고 자신이 버그를 잡기 어려운 이유를 차근차근 이야기하는 것이죠. 물론 그 동안 시행착오를 겪으면서 찾아본 코드나 로그에 대해서 설명도 해야 합니다. 현재 상황에 대해 실토를 하면 관리자들은 다른 대안이나 대책을 마련할 수 있습니다. 예를 들면 버그를 잡을 시간을 번다던가, 다른 개발자를 찾아본다던가, 아니면 관련 기능에 대한 스팩을 조정한다던가 등등의 대응을 할 수 있죠.
이 때 정말 용기가 필요합니다. 이런 사실을 실토할 때 관리자들에게 욕을 먹지만 나중에 문제를 잘 해결하고 나서는 잊어 먹을 가능성이 높습니다.
대충 코드를 수정한다
제대로 코드를 이해하지 못한 채 코드를 일단 수정하는 선택을 합니다. 계속 관리자들이 압박을 하니까 말이죠. 물론 코드의 수정 내역은 그럴 싸 하게 포장해 말합니다.
하지만 현재 처한 문제를 모면하기 위해 땜빵으로 가짜 패치를 만들면 나중에 반드시 다른 버그로 부메랑을 맞을 가능성이 높습니다. 왜냐면 소프트웨어는 거짓말을 안하거든요.
대충 코드를 수정하느니 차라리 솔직히 잘 모르겠다고 실토하고 다른 도움을 관리자에게 요청하는 게 좋습니다.
버그를 다른 개발자에게 넘긴다
버그를 잡기 어려운 상황에서 개발자들이 많이 하는 수법이 버그를 다른 개발자에게 넘기는 것입니다. 버그가 할당될 때 보통 로그와 함께 전달되는 경우가 많은데요. 문제가 발생한 재현 경로가 약간 애매한 경우에는 관련 모듈 기능의 어떤 메시지가 보이면 해당 담당자에게 버그를 던집니다. 충분히 로그를 분석하지 않고 문제가 재현된 상황도 체크하지 않고 말이죠.
한 가지 예를 들어볼까요? 오디오 사운드가 끊긴다는 내용과 함께 로그가 전달된 상황입니다.
그 로그는 다음과 같습니다.
[ 7164.614352] rpi sound_card.27: Ply shutdown, devnum 7
[ 7165.077580] ------------[ cut here ]------------
[ 7165.077807] WARNING: at /root/rpi/kernel/workqueue.c:2904 __cancel
_work_timer+0x12c/0x178()
[ 7165.087114] Modules linked in: texfat(PO)
[ 7165.092596] CPU: 3 PID: 1373 Comm: mmcqd/0 Tainted: P W O 3.10.44+ #1
[ 7165.101579] [<c0017344>] (unwind_backtrace+0x0/0x144) from [<c0013874>] (show_stack+0x20/0x24)
[ 7165.111750] [<c0013874>] (show_stack+0x20/0x24) from [<c0936350>] (dump_stack+0x20/0x28)
[ 7165.121489] [<c0936350>] (dump_stack+0x20/0x28) from [<c0028848>] (warn_slowpath_common+0x5c/0x7c)
[ 7165.132133] [<c0028848>] (warn_slowpath_common+0x5c/0x7c) from [<c0028894>] (warn_slowpath_null+0x2c/0x34)
[ 7165.143418] [<c0028894>] (warn_slowpath_null+0x2c/0x34) from [<c0048600>] (__cancel_work_timer+0x12c/0x178)
[ 7165.154654] [<c0048600>] (__cancel_work_timer+0x12c/0x178) from [<c0048668>] (cancel_delayed_work_sync+0x1c/0x20)
[ 7165.168097] [<c0048668>] (cancel_delayed_work_sync+0x1c/0x20) from [<c007b588>] (pm_qos_update_request+0x34/0xac)
[ 7165.178711] [<c007b588>] (pm_qos_update_request+0x34/0xac) from [<c064348c>] (sdhci_disable+0x2c/0x48)
[ 7165.189268] [<c064348c>] (sdhci_disable+0x2c/0x48) from [<c062e68c>] (mmc_release_host+0xa8/0xc0)
[ 7165.199855] [<c062e68c>] (mmc_release_host+0xa8/0xc0) from [<c0640794>] (mmc_blk_issue_rq+0x104/0x664)
[ 7165.210600] [<c0640794>] (mmc_blk_issue_rq+0x104/0x664) from [<c0641514>] (mmc_queue_thread+0xb4/0x14c)
[ 7165.221673] [<c0641514>] (mmc_queue_thread+0xb4/0x14c) from [<c004ef1c>] (kthread+0xc0/0xd0)
[ 7165.231685] [<c004ef1c>] (kthread+0xc0/0xd0) from [<c000f788>] (ret_from_fork+0x14/0x20)
[ 7165.241314] ---[ end trace b64c1dfefe8a5e9e ]---
그런데 위 로그를 보니 파일 시스템 관련 메시지가 보여, 다음과 같은 내용으로 파일 시스템 담당자에게 버그를 이관합니다.
* 파일 시스템 문제로 오디오 사운드가 끊어지는 것 같습니다. 버그 수정 바랍니다.
이런 내용을 받아 본 파일 시스템 개발자는 정말 짜증이 나기 마련이고, 감정적으로 대응할 가능성이 높습니다.
파일 시스템 개발자는 로그에서 오디오와 관련된 메시지를 찾아서 다시 이관을 합니다.
* 아래 로그에 오디오 사운드 카드 관련 에러 메시지가 보입니다. 관련 내용 확인하시고 대응 하시기 바랍니다.
[ 7164.614352] rpi sound_card.27: Ply shutdown, devnum 7
충분히 로그나 재현 상황을 체크하지 않고 바로 다른 담당자에게 버그를 이관하면 문제는 해결되지 않고 계속 분쟁이 생길 가능성이 높습니다.
최근 덧글