오늘 또 전과 비슷한 일이 발생했다. 이걸로 두 번째다. 사건의 발단은 이러하다.

어제 하루 짧게 작업한 코드를 마무리하여 리뷰를 요청했다. 키보드 입력을 다루는 몇 가지 케이스를 추가한 것이다. 코드에 대한 몇 가지 리뷰코멘트와 함께 전체적인 구조를 한번 잡고 가자는 이야기가 나왔다.

금요일 오후 2시에 있는 위클리 미팅에서 그 얘기가 시작됐는데, 논쟁이 됐던 요지는 아직 좀 애매하다. 이 친구와 논쟁이 시작되면 정확히 뭐가 논점인지 모르고 목소리만 커지게 된다. 그것은 논점이 계속 빙글빙글 돌기 때문이다.

처음 최초의 시작은 Controller 라는 클래스가 이름이 정의한 것보다 너무 많은 일을 하고 있다는 지적이었다. 사실 지금은 프로젝트 초반이라 아직 클래스들이 분화하거나 자라나기 전이라서 그런 것이지. 우리가 테스트할 수 있는 경우의 수가 늘어나고, 기능이 추가될 수록 해당 클래스들이 적절히 리팩토링 되지 않겠느냐는 것이 나의 의견이었다.

그러나, 동료는 그 점에 동의하지 않았고, 지금 전체적인 설계를 한번 잡아야 한다고 했다. 나는 그렇다면 본인이 제안하는 청사진을 제공해주어야 우리가 뭔가 이야기를 할 수 있지 않겠느냐는 요지의 얘기를 했다. 허나 그런 식의 고양이 목에 방울 달기 분위기가 되면, 아무도 좋은 제안을 할 수 없지 않겠느냐는 의견을 내놓았다.

그렇다면, 당신의 제안이 왜 좋은지 나를 설득해 보라고 했다. 결국 그 사람의 마음 속에 있는 설계를 내가 구현해 주길 바라는 것인데, 그렇다면 거기에 대한 명백한 장점을 알아야 되지 않을까 싶었기 때문이었다. 경험에 의한 직관으로 설계를 그렇게 바꾸는 것이 좋을 것이라는 대답이 왔고. 나는 그런 선택은 어떠한 문제도 해결하지 못하기 때문에, 그 설계가 더 낫다는 것을 증명할 방법이 없다고 했다.

이번에는 그럼 설계가 더 낫다는 것을 증명하려면 어떻게 해야 되는가로 발전해 갔는데. 나는 더 많은 문제를 해결할 수 있다면, 예를 들어 readibility, code duplication, testability 등이 좋아지면 더 나은 설계가 아니겠냐고 했다.

그럼 누군가의 코드와 비슷한 중복 작업이 있다면 어떻게 될 것인가로 다시 논제가 옮겨졌고, 나는 그렇다면 둘 다 이미 코딩이 되었다면, 보다 나은 디자인을 고르기는 쉬울 것이고, 안되어 있다면 먼저 한 것을 기반으로 본인의 문제를 해결하면 되지 않냐고 대답했다.

이 이후는 잘 기억나지 않는다. 했던 말을 또 하고, 또 하며 뱅뱅 돈 것 같다. 마침 회사에 외부 손님이 오셔서 회의를 급하게 끝낼 수 밖에 없었다. 커피나 한 잔 하자고 해서, 회사 앞 커피 가게에 가서 이런 저런 얘기를 나눴다. 왜 이런 소모적인 논쟁이 자주 일어날까 라는 주제부터 회사에 대한 이야기까지.

그렇게 얘기하다 보니 왜 논쟁에 대한 대강의 해법을 제시할 수 있게 되었다. 결론부터 말하면, 디자인 리뷰다. 버그 픽스를 쓰기 전에 디자인 리뷰를 함으로써 디자인에 대한 밑그림을 같이 가져갈 수 있지 않겠냐는 제안이었고, 동의했다.

모두가 동의할 수 있는 당연한 결과를 내기 위해 왜 이리도 힘든 논쟁이 필요했는가는 아직도 잘 모르겠다. 나는 그래서 동료가 본인의 욕구를 한번 되돌아 보고 뭔가를 해줬으면 하고 바랬는데, 그걸 표현한 적이 없으니 전달이 안 됐을 터이다.

이런 소모적인 논쟁을 줄이려면 어떻게 해야 되는지 고심해 볼 여지가 있다. 보다 효과적으로 동일한 결론에 안전하게 도달할 방법은 없는가?

나는 그가 어떻게 해주면 대응하기가 편해질 것인가? 내가 바라는 것은 무엇이고, 그가 바라는 것은 무엇인가?

사람을 대하는 법에 관한 책을 한 권 구매했다. 주말 동안 열심히 읽으면서 힌트를 좀 얻어봐야겠다.