러버덕: 강제적 객관 주입
개발자로서 제가 가진 가장 큰 장점은 동료 개발자에 비해 좀 더 복잡한 로직이 동원되어야 하는 작업에 특화되어 있다는 겁니다(어디까지나 상대적인 기준이므로 잘난 체 한다고 너무 미워하지 마시죠! 흥). 반면 어떤 난제에 매몰되기 시작하면 다른 개발자보다도 훨씬 더 헤어 나오기 힘든 상태에 빠지는 단점이 있습니다. 이 단점이 진짜 치명적인 이유는 그 순간의 제 모습이 흡사 전형적인 아르센 '월급' 루팡이기 때문입니다.
제가 이런 똥통에 빠져 허우적댈 때마다 마더 메리, 아니 전 직장의 본부장님은 지혜의 말씀을 속삭이셨죠.
'곰돌이 찾아올까?'
러버덕 디버깅이라고도 불리는 이 방법은 간단하지만 매우 강력합니다. 우선 눈에 들어오는 불쌍한 후임을 하나 부릅니다. '뭐 좀 도와줄래? 지금 내가 문제가 있어서...' 그리곤 지금 내가 구현하려는 이상과 초라한 현실, 그리고 그 사이에 가까스로 양다리를 걸치고 가랑이가 찢어지고 있는 내 신세를 격하게 토로하는 겁니다. 그렇게 자학과 분노를 뿜다 보면 갑자기 그 전에는 없었던 오타나 빠진 제어문이 뿅~ 하고 나타나는 거죠. 간절히 원하면 온 우주가 나서서 도와준다더니 그 말이 사실인가 봅니다. 아, 아직 한 가지 일이 남았어요. 혼자서 북 치고 장고 치며 울다가 웃는 미친 선임을 보며 무슨 표정을 지어야 할지 힘들어하는 후임을 자리로 돌려보내면 됩니다. '고마워, 자네 덕에 큰 문제가 해결되었어!'라는 칭찬을 잊지 마세요(그래야 reusable한 자원이 됩니다. 재사용은 개발자의 기본 도리죠)!
이건 얼핏 옵서버-오퍼레이터를 중간에 스위칭하지 않는 짝코딩과 유사합니다. 두 명이 한 개의 이슈에 매달려 있고, 대화를 하죠. 다른 점이라면, 화자가 당신뿐이며 옵서버의 스킬 레벨이 별로 중요하지 않다는 거? 하지만 어떻게 그럴 리가? 증명을 위해, 의문의 고통을 받아야 하는 대상을 후임이 아닌 곰인형으로 바꾸어 봅시다. 이 기법에 '러버덕'이라는 이름이 붙은 건, 아마도 양키놈들은 음란한 테디베어보다 고무 오리 인형을 더 좋아했기 때문이겠죠. 쨌든 놀랍게도 거의 똑같은 효험이 있을 겁니다. 상상력이 풍부한 사람이라면, 탁상용 USB 선풍기나 굴러다니는 마커펜과도 대화할 수 있습니다. 가상의 투명인간과 코드 리뷰를 해도 됩니다.
사실 이 러버덕은 확증 편향이 켜켜이 쌓여 돌아오는 길을 까먹은 개발자의 인격 일부를 분리시켜 악마의 대변인으로 각성시키는 데 그 의의가 있습니다. 우리는 무의식적으로 '내가 오타를 쳐서 코드에 문제를 일으키진 않을 거야', '내가 설마 초딩도 아닌데 그렇게 어처구니없는 데서 조건을 빼먹었겠어?' 등의 말도 안 되는 가정을 거의 매 순간 합니다. 그러니 당연히 디버깅이 성립하기 힘들죠 ^^ 사실 통상의 짝코딩이나 코드 리뷰도 꽤 비슷한 역할을 합니다. 적절한 경험이 있다면, 코드 리뷰 도중 누군가 지적을 하지 않았음에도 자신의 코드에 결점이 있다는 사실을 먼저 깨달은 적이 있을 거예요. 바로 그겁니다!
러버덕 디버깅은 두 가지 단점을 빼면 거의 완벽에 가까운 신약입니다. 첫 번째 단점은 여러분의 조직에서 드디어 실성한 녀석이 탄생한다는 것이죠. 아, 물론 그게 너죠. 하지만 이건 의외로 간편한 해법이 있는데, 다 같이 미친놈이 되면 그만입니다. 러버덕을 영접하고, 그 은혜를 모든 팀원에게 간증하세요!!
또 다른 단점은, 이 노랗고 작은 친구가 진짜 필요한 상황이 되면 이미 높은 확률로 러버덕의 L자도 떠올리지 못할 정도로 깊은 수렁에 빠져 있을 거란 사실입니다. 이건 제가 어떻게 해 드릴 수 없는 문제라 정말 난감하군요. 우선 오리 인형을 항상 잘 보이는 데 두시고, 조금이라도 마음의 여유가 있을 때 자주 러버덕과 교감하는 연습을 하시라고 당부드립니다. 어려울 때 친구가 진정한 친구라지만, 먹고 살만할 때가 아니면 친구를 사귈 수 조차 없는 법이니까요 ;)
