코딩 스타일은 개인적으로 따르기는 쉬워도, 스타일이란 의제를 놓고 팀 합의를 이끌어가는 과정은 정말로 어려운 문제다. 왜 스타일이 필요한지, 의견 충돌은 왜 일어나는지, 어떻게 합의에 도달하는지 등에 대해 잘 정리한 글이 있어 원저자 Sandi Metz의 허락하에 번역해 공유한다. 원문은 Why We Argue: Style이다.
나는 수년 동안 코드에 대해 논쟁을 하는 이유가 무엇인지, 그리고 격렬하게 엇갈리는 의견들을 건설적인 방향으로 전환하는 방법은 어떤게 있을까 고민해 왔다.
나의 견해는 매우 특이한 상황에서 발견되었다. 나는 불특정 기업들에 가서 며칠에 걸친(3일, 혹은 그 이상의) 객체 지향 설계 강의를 일년에 10회에서 12회 정도를 진행한다. 나는 외부인이었지만, 그들 기업에서 며칠을 보내는것으로도 그 기업들의 보이지 않은 부분들을 볼 수 있었다.
그 때 깨달았던 부분이 여기에 기술되어 있다. 몇몇 기업들은 모두가 대체로 행복해하며 프로그래머도 잘 지내고 있고, 그들 대부분은 이 일에 함께 한다는 동질감을 가지고 있는것 같다. 이런 기업에서는 내 시간의 대부분을 실제 객체 지향 설계 강의에 집중하게 해 준다.
몇몇 다른 기업들은 놀라울 정도로 비참한 상황에 빠져있는 곳도 있다. 많은 불협화음이 존재하고 프로그래머들도 “파벌” 싸움에 휘말려 있기도 하다. 이런 상황에서의 객체 지향 설계 강의는 뿌리 깊은 충돌을 어떻게 해결할까에 대해 광범위하게 그룹 토론의 장으로 바뀌어 버린다.
톨스토이의 “행복한 가정은 서로 비슷하지만, 불행한 가정은 모두 저마다의 이유로 불행하다”라는 유명한 성구는 안나 카레니나의 원칙(Anna Karenina Principle)로 알려져 있다. 그리고 이 법칙은 성공에는 엄청난 판단 기준을 모두 충족해야함을 보여 준다. 행복해지는 유일한 방법은 그 하나 하나 모두를 충족하는 것이다. 불행히도, 이러한 판단 기준의 단 하나라도 만족하지 못하면 불행은 찾아온다. 즉, 행복한 기업은 대부분 비슷하지만, 불행한 기업은 자신들만의 독특한 이유로 불행을 겪고 있는 것이다.
상당수의 강의를 하면서 나는 다양한 불행의 종류를 기업에서 체험하고 나서 행복을 판단하기 위한 몇 가지 일반적인 기준이라는 것을 이해하기 시작했다. 본 뉴스레터는 그 중에서 하나를 토론해 보고 싶고 나머지에 대해서는 향후 뉴스레터에서 언급할 예정이다.
지금 내가 관심있는 것은 자신의 기업의 스타일 가이드에 동의하고 따르는지에 대한 여부 즉, 구문(syntax)의 선택이다. 내가 이런 평범하게 생각하는 이슈에 대해 쓰기 시작한다는 것을 보고 여러분이 놀란다면 다행히 지금의 당신 직장은 좋은 구문(syntax)을 선택하고 있다고 생각한다. 이 토픽의 중요성에 대해 후회하듯 고 개를 흔들며 이 주제의 중요성에 동의하고 있다면 진심으로 나는 당신의 고통에 공감한다.
왜 스타일 가이드라는 것이 있는가?
나는 개인적으로 검토해야 할 모든 코드는 일관된 형식으로 보여줘야 된다고 굳게 믿고 있다. 코드는 쓰는 횟수보다 읽는 횟수가 훨씬 많다. 그래서 코드의 많은 비용은 읽을 때 발생한다. 그러므로 코드는 가독성을 위해 최적화를 해야 한다는 결론, 즉 응용 프로그램의 코드는 모두 같은 스타일로 통일되어야한다는 결정을 이끌어 낼 수 있다. 일반적인 스타일에 맞춤으로써 여러분은 비용을 절감할 수 있다.
어떤 스타일 가이드가 최고인가?
여기까지의 이야기는 대부분의 프로그래머가 동의하여 준다. 하지만, 여기부터가 분열의 시작이다. 내가 아는 한 개인적인 코딩 스타일 이야말로 분명히 최고라고 생각한다. 그러나, 여러분도 자신의 코딩 스타일이 최고라고 생각하는 것을 나도 안다. 프로그래머 그룹에게 모든 코드 스타일을 공통의 스타일로 따르게 동의시키는 것은 쉽다. 그러나, 어떤 스타일이 공통의 코드 스타일인지를 정하는 것과 이것을 동의시키는 일은 너무 너무 어렵다.
코딩 스타일의 선택의 대부분은 독단적이며, 완전히 개인의 취향의 문제이다. 스타일 가이드를 선택하는 것은 사소한 이슈에서 의견이 갈리는 부분에서 합의를 형성하는 것을 의미한다. 스타일 자체가 중요한 것이 아니라, 스타일의 유사성을 찾아서 채워가는 것이 중요하다.
왜 팀 내에서 의견이 갈라지는 것인가?
앞서 얘기한 바와 같이, 스타일 가이드가 없으면 많은 비용이 발생한다. 그러나, 당신이 코드 스타일에 대해 동의할 수 없다면 비용은 전체가 아닌 당신 자신의 작은 문제로 최소화 할 수 있다.
나는 지금까지 스타일 가이드의 합의 형성에 실패하고 팀이 분열해 버린 기업을 방문한 적도 있다. 거기에 있는 프로그래머들은 구두 협의를 오래전에 중단했고 대신에 변경 요청을 핑계로 변경 요청의 대상이 되는 코드들을 자신의 스타일대로 바꿔 버리고 있었다. 코드는 경쟁하듯 서로의 스타일로 반복 수정되고 있었다. 이는 실제 동작하는 것이 어떻게 변화하는가를 파악하는데 어려워질 뿐만 아니라, 마지막으로 코드에 손댄 사람이 다음에 그 곳을 다시 볼 때 분노하게 된다.
이러한 “스타일 전쟁”은 표면상으로는 코드 형식의 문제 같이 보이지만, 실제로는 파워(권력) 게임이다. 좀 더 부드럽게 말하면, 스타일 전쟁은 팀의 긴장감을 부추기고 비용을 증가시킨다. 더 독한말로 하면, 스타일 전쟁은 팀 사기에 독이 된다.
자기만의 방식으로 해도 되지 않나?
아니다.
이것은 “누가 결정을 내릴지”에 대한 질문이며, 질문의 해결책에 대해 접근하다보면 당신 기업은 균열에 직면하게 된다. 다음의 3가지의 코딩 스타일 형태의 서로 다른 스타일을 고집하고 있는 상황은 자주 접하는 일이다.
자신들의 방식이 옳다고 그럴 만하다고 믿는 고참 프로그래머 그룹들은 종종 있다. 이런 사람들은 지시에 의해 진행하려 하고 그 지시가 실패해도 자신들이 원하는 스타일로 진행하고 그룹의 합의조차도 무시해도 된다는 생각을 가지고 있다. 이러다 보니 누가 그들을 해고시키겠는가?
다른 언어의 경험들을 Ruby에 도입하려는 프로그래머도 자주 볼 수 있다. 그들은 자신들의 선택한 스타일이 코드를 알기 쉽게한다고 생각하고 그 선택이 다른 프로그래머들에겐 혼란을 준다는 사실을 애써 무시해 버린다.
마지막으로, 스타일에 대한 지론이 확실하지 않은 신인 프로그래머들이 있다. 그들은 모든 스타일을 이것 저것 실험하기 때문에 코드에 일관성이 없다는 특징을 가지고 있다. 안타깝게도, 다른 멤버들은 모두 혼란에 휘말려 뒷처리 하기에 바쁘다.
여기서 소개한 형태는 3가지 뿐이지만, 여러분 직장에서 이런 종류의 골치 아픈 문제가 있다면 다양한 스타일의 분쟁이 발발할 수 있다. 스타일 파벌이 일단 형성되면 자신만의 방식으로 개발하게 되고 결국 프로그래머 수만큼의 스타일이 만들어진다. 이런 기업에서 내가 “코드의 일부분만 보여주고 누가 쓴 건지 알 수 있나요?”라고 물으면 모든 사람이 “예” 라고 대답한다.
어떻게 팀의 합의에 도달할 수 있나?
코딩 스타일의 문제는 실제로 두가지 문제를 안고 있다. 첫째 전원의 스타일 가이드에 합의를 해야 한다, 둘째 전원이 스타일에 따라야한다는 것이다.
직장에서 코딩 스타 일에 충돌이 오랫동안 계속되고 있는 것이라면, 스타일 가이드를 외부에서 아웃소싱하는게 좋다. 이미 언어별로 각 커뮤니티가 스타일 가이드에 대한 시행착오를 통해 만들고 있으니 같은 노력을 반복할 이유는 없다. “Ruby Style Guide”(다른 언어도 물론 가능)로 검색해서 그 중 하나를 선택하면 된다. Ruby는 RuboCop 기반의 스타일 가이드를 선택하기 바란다.
외부 스타일 가이드를 사용하면 내부에서의 불필요한 분쟁을 피해 대중의 지혜(집단지성)를 빌릴 수 있다. 대부분의 스타일 가이드는 만족 정도와 아쉬운 정도가 서로 비슷하기에 때문에 스타일을 완성하려면 어딘가는 절충이 필요하다. 외부 스타일 가이드를 선택하면, 개인의 취향에 좌우되는 일도 누군가에게 일방적으로 강요받는 일도 없어진다.
스타일 가이드를 선정하는 것만으로 끝나진 않는다. 스타일 가이드를 결정하면, 모두가 그것에 따라야 한다. 스타일을 시행하는 가장 쉬운 방법은 정적 분석을 통해 자신의 코드에서 위반이 발생되면 경고하는 절차를 자동화하는 것이다. Ruby면 RuboCop을 한번 체크해 보자. RuboCop이 이미 설정되어 있으면, 잘 작동할 것이다.
개발자가 수동으로 스타일을 검토하는 것은 피하자. 이것은 누군가를 잔소리꾼으로 만든다. 대신, 코드의 문제를 해결하는 데 실질적으로 필요한 정보를 프로그래머에게 제공하자. 풀 리퀘스트를 전송하기 전에 스타일 위반을 바로잡아야 한다. 풀 리퀘스트의 내용은 코 드의 외형보다 코드의 내용과 동작에 관한 것이어야 한다.
여기서 조금 개인적인 이야기지만, 최근 Elm 언어를 시험하고 있다. Ruby 스타일의 불편함을 넘어 Elm처럼 보다 의식적인 코드 포맷을 사용하고 싶어서 편집기에 자동 Elm 포매터를 설치했다. 처음에는 자동 수정된 코드의 외형에 혐오감을 느꼈지만 지난 몇 주 동안 그토록 싫어했던 Elm 스타일을 어느새 진심으로 좋아하게 되었다. 표준 Elm 스타일에 반복적으로 접함으로써 서서히 좋아하게 되었고 표준 따위는 자신의 습관(익숙함)에 지나지 않는 것을 스스로 증명하게 되었다. 자신의 기존의 방식을 새로운 사고법에 맞추기가 그 반대보다 훨씬 쉽다.
기존 코드는 어떻게 해야 하나요?
그대로 둬라. 기존 코드의 스타일까지 수정할 필요는 없다. 앞으로 작성 해야 할 코드나 잘해라. 오래된 코드는 다른 이유로 건드리게 될 때까지 내버려 둬라.
이 전략을 따르게 된다면 가장 자주 사용하는 코드에서 점차적으로 공통화된 스타일을 갖추게 된다. 기존의 코드의 일부는 앞으로 다시는 수정을 하지 않을 가능성도 있겠지만 아무도 돌보지 않는 코드는 더이상 신경쓸 필요는 없다.
만질 필요가 없는 코드의 스타일을 일부러 수정한다는 것은 백로그에 쌓여있는 다음 작업을 하는것보다 오래된 코드의 외형을 수정하는 것이 비즈니스 가치가 높다고 선언하는 것과 같다. 순전히 코드의 외형을 바꾸는 즉, 외형의 미적 변화를 위한 기회 비용은 당신이 외형 대신에 할 수 있었던 것에 대한 이익을 잃어버린것도 포함되어 있다. 내가 생각하는 규칙은 다음과 같다. 이미 안정화가 되어있고 수정에 비용이 든다면 기존 코드의 스타일에 손을 대지 않는다 (적은 비용이 든다면 변경할 수는 있겠다).
새로운 스타일 가이드가 싫다면 어떻게 해야 하나요?
팀이 합의한 스타일 가이드를 동의하지 않는다면, 괜찮은 대안은 두가지 밖에 없다.
하나는 꾹 참고 스타일 가이드에 따르는 것이다. 위에서 이야기한 Elm에서 알 수 있듯이, 스타일 가이드를 따르다보면 어느덧 자신의 생각도 바뀌고, 새로운 스타일을 좋아하게 된다. 스타일 가이드에 따라 코드를 작성하다 보면 결국 좋아하게 될 것이다.
또 다른 하나는 그 스타일 가이드에 따르지 않겠다는 단호한 결심을 하는 것이다. 그렇게 되면 지금의 직장을 떠나 자신의 스타일을 사용하는 곳을 찾아야 한다. 새로운 직장에서 거기의 스타일 가이드를 따라라.
어쨌든 두가지 방법 모두 결국엔 어떤 스타일 가이드를 따라야 한다는 것이다. 스타일 가이드를 따르지 않는다는 것에 대한 선택지는 없다.
이 이야기의 교훈은 코드가 자신들의 방식대로 작성되어 있는것보다 모든 코드가 비슷한 스타일로 되어 있는 것이 훨씬 중요하다. 스타일 가이드에 동의하고 그것에 따르라. 팀이 합의에 이르지 못하는 경우라면 그 문제에서 한발 물러나 스타일에 대한 힘의 균형점을 의제로 삼고 논의를 시작하자.
