개발자 안티패턴3 - 정답을 단정 짓지 말라

요즘 협업을 하면서, 팀을 리드하면서 디자인 리뷰를 하면서 많이 생각하게 되곤 합니다. 내가 생각하고 있는 것이 맞는 정답일까, 이 사람이 만들어놓은 디자인은 맞는 정답일까? 그런데 프로젝트를 여러 번 하다 보니 내리게 된 결론은 다음과 같습니다.

시스템 디자인에 정답은 없습니다.

 

요즘 다시 고용 시장이 조금 회복되면서 다시 인터뷰도 많이 하고 있습니다. 저는 자주 시스템 디자인 세션을 맡곤 하는데, 한 시간의 인터뷰 세션 안에서 자기소개하고 인터뷰이 소개하고 기본적인 질문들을 하다 보면 15분 정도 쉽게 지나가고 마지막 5분은 질답 시간으로 남겨두려면 결국 남는 건 40분 밖에 되지 않습니다. 40분 안에 물어보는 시스템 요구사항에 대한 최적의 디자인을 만들기란 당연히 턱 없이 부족합니다. 인터뷰어로서 살펴보는 건 "장단점을 알고 있느냐" 다른 말로, "Trade off"를 이해하고 있느냐를 위주로 봅니다.

모든 디자인이나 접근 방법에는 Trade off가 있습니다.

 

이것은 디자인 리뷰를 할 때나 디자인을 공유할 때 언제나 강조하는 부분입니다. 심지어 두 변수를 더하는 간단한 연산 구문조차도 trade off와 장단점이 있습니다.

 

int add(int x, int y) {
  return x + y;
}

 

이러한 단순히 두 수를 더하는데 코드에 대해서도 다른 대안을 여러 가지로 제시할 수도 있고, 그 여러 대안들에 대해서도 여러 장단점들을 나열할 수도 있습니다. 연산에 사용되는 메모리를 고려해 int를 그대로 쓰느냐, 범위를 고려해서 int를 long으로 바꿀 거냐, 소수점이 혹시 필요할지 모르니 float / double로 바꿀 거냐, 화폐 단위 계산을 고려해 BigDecimal을 쓸 거냐, 여러 값들을 한 번에 더할 수 있게 별도의 클래스로 Wrap 해서 더하기 연산자를 객체에 넣느냐 등등, 각 접근 방법은 장점이 있고 단점이 있습니다. 명확한 것은 "장점만 있는 방법은 없다"입니다. 이것을 이해하고 다른 개발자들과 소통하는 것은 중요합니다.

장점만 있는 접근 방법은 없습니다.

 

이제 개발자 안티패턴이라는 주제로 돌아와서 하지 말아야 할 행동은 무엇이 있을까요? 제가 가장 많이 접하는 문제 되는 개발자 유형은 "정답을 정해놓고 닫힌 귀로 소통하는 개발자"입니다. 앞선 글에서도 썼었던, 고집을 버려야 하고 겸손해야 한다는 것과 유사합니다만, 제가 이것을 본 개발자들을 주로 리뷰를 해주는 고급 개발자들에게서 입니다. 디자인 리뷰를 하면 끝까지 자기의 디자인을 고집하는 것을 보고 있으면 소통이 안 되는 개발자라는 것이 느껴지고, 그 개발자와 같이 협업하는 것을 꺼리게 됩니다. 

 

물론 리뷰를 받는 입장에서도 비슷하게 적용됩니다. 고급 개발자들이 그렇게 말하는 데에는 이유가 있을 것입니다. 이것을 이해하고 왜 그렇게 이야기하는지 판단하는 것이 중요합니다. 저는 리뷰하는 입장이 많이 되다 보니 조금만 구조를 개선하면 더 오랫동안 시스템의 확장성 이슈가 없어질 수 있는 제안을 많이 하곤 합니다. 그런데 항상 정답이 없다는 것을 명심하고 리뷰받는 개발자의 의견을 존중하려고 노력합니다. 보통은 제가 제안하는 방법은 확장성은 좋아지지만 복잡도가 올라가는 경우가 많거나, 유지보수가 편해지지만 코드의 커플링이 강해지는 방법들을 던져주곤 합니다. 결과적으로 결정을 각 개발자들에게 맡기지만 고급 개발자로서의 역할은 언제나 조금은 다른 관점에서 새로운 접근 방법을 제시해 보는 것이라 생각합니다. 저희 팀 개발자들을 때로는 수용하고 때로는 자기 주관대로 가는데 어느 방향을 선택하든 단기적으로 프로젝트에 영향이 없다면 그대로 진행합니다. 보통은 장점만 있는 접근 방법이 없기 때문에 중요한 것은 개발자들이 그 장단점을 이해하고 있다면 그것으로 된 것입니다.

 

처음부터 확장성이 있는 방법을 선택하느냐 복잡도가 적은 선택을 하느냐는 항상 고민되는 부분입니다. 저는 개발일정을 조금은 미루더라도 확장성이 있는 방법을 우선으로 고려합니다. 하지만 상황에 따라서 유연하게 처리를 할 수 있는 것이 중요합니다. 이러한 유연함은 개발자에게 아주 중요하다고 생각합니다. 특히 프로젝트 오너나 비즈니스와 이야기할 때 무조건 반대 또는 무조건 요구사항 수락을 하는 것이 아니라 한 가지 정답만을 향해 가는 것이 아니라 여러 방법들을 고민하고 먼저 제시하는 것이 중요하다고 생각합니다. 따라서 개발자로서 가장 중요한 것은 어떠한 접근 방법에 대한 결정을 내렸을 때 항상 생각해야 하는 것은 아래와 같습니다.

 

1. 어떠한 접근 방법들과 대안들이 있는가?
2. 각 접근 방법들의 장단점이 무엇인가?
3. 현재 상황에 가장 적합한 접근 방법은 무엇인지 또는 선호되는가?

 

특정한 문제에 대하여 한 가지 정답만을 바라고 생각하지 말고 이러한 식으로 고민을 한번 더 하면 좋고, 고급 개발자라면 다른 개발자들이 어떠한 문제를 해결할 때 이렇게 생각할 수 있도록 도와주는 것이 중요합니다.

개발에 있어서 정답은 없습니다. 왜냐하면 요구사항은 항상 언젠가는 바뀌기 때문입니다.

 

다음 편: "개발자 안티패턴4 - 남의 문제를 지적하지 말라"