이제 막 개발을 한 달 정도 진행했다. 점점 요구사항도 정확해져 가고 있다. 그러나 SDK 문서를 보던 중, 우리가 라이브러리를 조금 오해했던 부분이 있었고, 이로 인한 잘못된 가정이 코드 곳곳에 숨겨져 있었다. 새로운 기능 구현을 위해서는 리팩토링이 필요하다고 판단되었다.

며칠 간 SDK 문서를 다시 읽어 본 뒤, 코딩 작업에 얼추 열흘 약간 넘게 걸렸다. 리팩토링 의 과정을 기록으로 남기기 위해 따로 개인 작업 브랜치를 만들어 진행하고 메인 브랜치로 merge 하는 식으로 진행하였다.

어제 코드 리뷰를 보내고, 코드 읽기에 도움을 주기 위한 code walkthrough 회의를 오늘 마련하였다.

원래는 코드 변경을 하나하나 쭉 설명하려고 했었으나, 동료가 불만을 제기하여 논의는 조금 다른 방향으로 흘러가게 되었다. 불만의 내용은 굳이 저렇게 전부 다 바꿀 필요가 있는가 하는 것이었다.

그 체인지의 내용은 static global 배열 변수들을, 클래스 안으로 옮기는 것이었다. encapsulation 과 동시에 굳이 그 변수들이 배열일 필요가 없다고 판단하여, 일반적인 멤버 변수로 바꿨었고, 그 이유에 대한 설명을 했다. 그러나 여전히 강한 불만이 동료에게 있었다.

사실 이런 세부사항은 논의의 대상 자체가 아니었고, 단지 말을 꺼내기 위한 것에 불과했다. 동료가 애기한 것은 자신이 주로 작업했던 코드가 내 작업으로 인해 많이 바뀌는데, 그 결과를 보면 자신에 대한 배려가 많이 부족하다고 느껴진다고 했다.

코드에서 배려심을 느끼고자 하는 걸 보니, 여전히 코드와 본인의 자아를 분리하지 못하고 있다는 느낌이 들었다. 이 요구가 정당치 않다는 것은 알기 쉬운데, 그 반대를 물어보면 된다. 그럼 배려심이 가득한 코드는 어떤 모습이어야 하는가? 나로서는 도무지 이해할 수 없었다. 본인이 ego 를 너무 투영한 것 아니냐고 물어봤으나 그렇지 않다는 것 외에 별 대답을 듣진 못했다.

비슷한 논쟁이 벌써 몇 번째 반복되기도 하고, 무엇보다 이성적으로 이해할 수 있는 근거가 부족한 얘기에 지친 나는 결국 인터페이스를 나눠 서로의 영역 안에서 각자 코딩하자는 의견에 동의했다. 그리고 당분간 코드리뷰도 마찬가지로 일단 중지하기로 했다.

이런 사태를 겪으면서 상당히 의기소침해 질 수 밖에 없었다. 소프트웨어 개발에 대한 나의 믿음이 많이 흔들리게 된 것이 그 이유이다. 인터페이스도 일종의 디자인인데, 누군가의 심리적 문제를 해결하기 위해 만드는 인터페이스가 과연 제품의 품질 향상에 부합하는가? 라는 질문에 부정적일 수 밖에 없기 때문이다.

어쨋든 사람이 있어야 소프트웨어도 있는 것이니까 라고 스스로 설명하고 넘어가려고 한다. 그리하여 내가 작업한 리팩토링 체인지는 보류되었고, 일단 인터페이싱을 통해 각자의 영역을 나누는 회의를 진행해야 할 것 같다.

능력이 맞는 사람이 아니라 생각이 맞는 사람과 함께 일하는 것이 얼마나 소중한 것인지 다시 깨닫는 하루였던 것 같다. 비록 일이 이지경이지만, 계획했던 코드 리뷰에 대한 practice 등은 꾸준히 쓰려고 한다. 아마 맨 처음 쓰게 되는 글은 '코드 리뷰, 이렇게 도입하면 실패한다' 가 될 것 같긴하지만...