설득

동료와 리팩터링하다 다음과 같은 코드를 만났다.

private Map<String, Integer> getCountryCodeCountMap(String customerId) {
  List<String> countries = getCountryList(customerId);

  Map<String, Integer> countryCodeMap = new HashMap<>();
  for (String cc : countries) {
    if (StringUtils.isNotBlank(cc)) {
      countryCodeMap.put(cc, countryCodeMap.getOrDefault(cc, 0) + 1);
    }
  }
  return countryCodeMap;
}

나는 이렇게 명령형으로 작성된 코드를 좋아하지 않는다. 코드가 불필요하게 길 뿐 아니라 뭘 하는지 한 눈에 보이지 않기 때문이다. 이 코드가 하는 일이 무엇인가? 국가 코드 목록을 받아 루프를 돌며 null이나 빈 문자열이 아닌 값을 맵에 넣고 있다. 맵에 넣을 때 키는 국가 코드고 값은 숫자로 넣는데 원래 있던 값에 1을 더하고, 원래 값이 없었으면 0으로 친 다음 1을 더한다.

간단히 정리하면 국가 코드가 키고 빈도가 값인 맵을 만드는 것이다. Java 8의 Stream API를 사용하면 훨씬 간단하게 작성할 수 있다. 그래서 다음과 같이 코드를 수정하자고 했다.

private Map<String, Long> getCountryCodeCountMap(String customerId) {
  List<String> countries = getCountryList(customerId);
  return countries.stream()
    .filter(StringUtils::isNotBlank)
    .collect(groupingBy(identity(), counting()));
}

이 코드는 해야 할 작업을 그대로 표현한다. 국가 코드 목록에서 빈 항목을 걸러내고(filter) 코드별 빈도를 세서(groupingBy(...counting())) 맵을 만든다. 얼마나 직관적인가.

그런데 동료의 반응이 놀랍다. 이런 코드는 읽기가 어려워 싫다는 것이다. 그 말을 듣는 순간 할 말을 잃었다. 내게는 너무도 명확하고 당연한 것이 다른 사람에겐 전혀 그렇지 않은 경우도 있는 법인데, 이게 딱 그런 경우였다.

Stream API를 사용해 작성한 코드의 좋은 점이 뭘까 생각해보니 명확하게 내세울 만한게 보이지 않았다. 선언적이라 이해하기 쉽다? 물론 나는 선언적 코딩 스타일을 좋아한다. 하지만 그게 주관적인 취향이 아니라고 어떻게 단정할 수 있을까? 동료는 '자신도 JavaScript를 써봤기 때문에 이런 스타일을 잘 알지만 싫다'고 분명하게 말했다. 따라서 이 논리로는 설득할 수 없다.

코드가 짧다? 짧긴 하다. 나는 짧은 코드를 좋아한다. 긴 코드 보다는 짧은 코드가 이해하기 쉽고 버그도 적을 것이다. 그러나 영리한 기법을 사용해 축약한 코드는 좋아하지 않는다. 작성할 때는 이해할 수 있어도 한참 지난 다음에 다시 보면 이해하기 어렵다. 이 논쟁에서 코드의 길이를 장점으로 내세우기는 어렵다. 그 동료에게 스트림을 사용한 코드는 영리한 기법은 사용해 축약한 코드처럼 보였을 지도 모른다.

성능은 어떨까? 성능을 내세울 수 있다면 설득에 큰 도움이 된다. 목록이 길다면 병렬 처리를 통해 처리 속도를 빠르게 할 수 있다는 점을 내세울 수 있을 것이다. stream()을 parallelStream()으로 바꾸기만 하면 병렬 처리가 가능해진다. 그러나 이건 길이가 짧은 리스트였고 병렬처리는 불필요했다. 스트림을 사용하면 오히려 느려질 수 있다.

그 동료는 스트림을 사용하면 디버깅도 어려워진다는 점을 지적했다. 디버거로 한 줄씩 실행해가며 상태 변화를 추적하기는 불편해진다. 스트림과 람다의 조합으로 코드를 작성한 경우는 디버깅이 필요 없을 정도로 코드를 단순하고 명확하게 작성해야 한다고 생각하지만, 어쨌는 그 동료 관점에서는 디버깅이 어렵다는 말도 사실이다.

이렇게 되고 보니 장점으로 내세울 수 있는게 마땅치 않았다. 흔히 말하는 코드 가독성이라는 게 객관적 사실이 아닌 주관적 감정에서 기인한 것이 아닐까 하는 의문이 들었다. '그런 스타일은 싫다'고 말하는 사람을 어떤 논리로 설득할 수 있을까?

생각해보니 지금까지 논리로 설득에 성공한 적은 별로 없었던 것 같다. 주관적 취향이 개입할 여지가 있다면 논리는 더더욱 먹히지 않는다. 아무리 논리 정연하게 설명해도 상대가 받아들이지 않으면 소용 없다. 이 경우에는 내세울 만한 논리도 없다.

설득하려 했던 시도 자체가 잘못된 것이었는지도 모르겠다. 그 동료가 스스로 새로운 코딩 스타일을 좋아하게 되지 않는 한 내 설명을 받아들이지 않을 것이다. 내 주장이 옳다고 강력하게 주장하며 설명하려 했다면, 설득은 커녕 반감만 사는 역효과만 생길 수 있다. 다행히 그렇게 하지는 않았다.

내가 대단하게 생각하는 사람이 하는 말이라면 귀담아 들으려 하겠지만, 내가 별로라고 생각하는 사람의 말은 중요하게 생각하지 않는다. 자기 생각과 다른 말을 들으면, 우선 비판하고 부정적으로 반응하는 것이 인지상정 아닌가.

어느 정도 상대의 인정을 받아야 비로소 설득이 가능해 진다. 내가 일을 잘 하면 다른 동료가 내 방식을 배우고 싶어 할 지도 모른다. 내가 코드를 어떤 식으로 작성하는지 살펴보고 싶은 마음이 생길 지도 모른다. 코드를 보며 '보기보다 괜찮군' 하고 생각하게 된다면, 그때는 설득을 시도할 수 있을 것 같다. 시간이 많이 걸리겠지만, 이게 유일한 설득 방법일지도 모른다.