Coding Style Guide 를 작성하려는 지금, 우리가 해야 하는 건 무엇일까?

나, dell.mond 는 카카오 엔터프라이즈에 프론트엔드 개발자로 합류한 지 얼마 지나지 않아 조직 개편을 맞이했다. 랜선 회식을 통해 겨우 얼굴을 익히고 친분을 쌓기 시작한 팀원을 뒤로 한 채 파도처럼 밀려오는 낯선 팀원과 마주해야 했지만 당황하진 않았다. 오히려 나에겐 상황이 좋게 흘러갔다.

개편 전에 속해있던 조직은 백엔드 개발자의 비중이 프론트엔드 개발자의 비중보다 컸다. 물론 비교적 최근에는 프론트엔드 개발자를 많이 영입하려는 모습을 보이긴 했으나-나 역시 그 흐름을 타고 카카오 엔터프라이즈에 합류했다.- 조직 내 백엔드 개발자의 수를 넘지는 못했다. 당연히 프론트엔드 관련 지식 아카이빙 및 정책 설립은 부진한 상태였다. 나는 입사 후 그러한 상황을 곧장 목격하게 되었고, 본격적으로 프론트엔드 개발 인력이 이보다 더 늘어나기 전에 각종 정책을 세워야 한다고 주장했다. 같은 조직 내의 다른 프론트엔드 개발자들 역시 그 부분에 있어서 동의 의사를 밝혔다.

우리는 부지런히 미팅을 통해 프론트엔드 개발 정책을 정했고, 문서를 정리했으며, 실무에 곧장 써먹으려고 했지만, 조직 개편이 이루어지고 말았다. 당황감만 가득한 상황일 수도 있으나 나는 그렇게 느끼지 않았다. 위에서 말했지 않은가? 상황은 꽤 좋게 흘러갔다.

내가 새롭게 만난 조직은 이전과 달리 프론트엔드 개발자만 모여있었다. 파도처럼 밀려오는 낯선 동료 무리와 파악해주기를 기다리고 있는 산더미처럼 쌓인 낯선 프로젝트 속 코드가 나를 반겼다. 그러나 나는 그것들에서 시선을 떼고-물론 새롭게 만난 동료와는 즐겁게 인사를 나눴다. 오해 금지.- 당황하지 않은 모습으로 그들에게 물었다. "개편되기 전, 이 팀에서 따르던 코딩 스타일 가이드가 있습니까?" 돌아온 답은 NO였다.

아, 나는 속으로 탄성을 내질렀다. 이전 조직에서 나와 동료가 나눈 정책 논의는 쓸모없지 않았다. 나는 그래서 살짝 제안했다. "개편을 맞이해서 우리 조직의 프론트엔드 개발자가 따를 코딩 스타일 가이드를 정하는 건 어떨까요?" 새롭게 마주한 동료들은 이 제안을 반기고, 기꺼이 받아들였다.

코딩 스타일 가이드, 이름만 들어도 멋진 이 녀석. 하나 있으면 참으로 든든하리라. 그냥 든든하기만 할까? 코딩 스타일 가이드가 생기면 나와 협업자가 작성하는 코드의 구조가 어느 정도 비슷한 모양을 띠게 된다. 그렇게 되면 서로가 작성한 결과물을 이해하는 데에도 이전보다 힘이 덜 들어간다.

조직에 새로운 구성원이 들어오게 되었을 때도 마찬가지다. 새로운 구성원이 보게 될 그 어떤 프로젝트 역시 통일된 코딩 스타일을 가지고 있을 것이다. 프로젝트 속 코드 분석은 더욱더 쉽게 이루어질 것이고, 그들은 이후에 자신이 작성해야 할 코드의 방향성을 더욱 명확하게 파악할 수 있을 것이다.

이처럼 코딩 스타일 가이드, 표준이라고 불리는 체계는 조직 구성원이 결과물을 표현하는 문법을 일관되게 만들고 그들에게 안정감을 가져다준다.

조직 개편을 통해 새로운 모습을 맞이한, 내가 속해있는 카카오 엔터프라이즈 Cloud FE 파트 역시 이러한 코딩 스타일 가이드가 있었다면 낯선 동료와 협업할 일이 생기더라도, 다른 동료가 개발하던 작업물을 갑자기 넘겨받더라도 당황하지 않을 수 있을 것이다. 또한 이후의 결과물에 대해서도 일관성과 안정감을 금방 얻을 수 있을 것이다.

이러한 이유를 바탕으로 나는 총대를 메고 일을 벌였다. 그러나, 본격적으로 코딩 스타일 가이드를 정할 논의의 장을 열기 전 몇 가지의 고민이 나의 머릿속을 채우기 시작했다.

그렇다면 코딩 스타일 가이드는 어떻게 만들어야 하는가? 누가, 아니지. 도대체 무엇부터 시작해야 하는가?

이러한 생각을 우리만 한 게 아닐 텐데, 다른 사람들은 어떻게 이 큰 산을 넘을 생각을 했을까? 그리고 뭘 했길래 결국 그 큰 산을 넘어서 나아갈 수 있었을까?

그래서 나는 이 글에 코딩 스타일 가이드 작성이라는 큰 산을 넘어간 다른 이들의 경험을 조사한 내용을 담기로 했다.

주의
스타일 가이드 라인 : 소스코드의 레이아웃에 초점을 맞춘 코딩 규칙
코딩 규칙 : 프로그래밍 관례와 디렉토리 구조, 주석에 대한 구조까지 포함되어 스타일 가이드 라인보다 더 큰 범위의 규칙

🤷🏻‍♀️ 아니, 왜 이리 종류가 많은 거야?

카카오 엔터프라이즈 Cloud FE 파트는 javascript와 그의 슈퍼셋인 typescript 언어를 주로 사용한다. 사용자 인터페이스를 만들기 위한 라이브러리는 React를 사용한다. 그래서 나는 javascript, typescript, 그리고 React 이 세 가지로 범위를 한정지어서 코딩 스타일 가이드에 관련한 사항을 조사했다.

(이미지 설명 : 우리는 싸울 것이다. 늘 그랬듯이.)

javascript style guide

Google Javascript Style Guide

• Google이 정의한 Javascript Coding Style Guide
• hard-and-fast rules 을 따른다.
• 명확하지 않고 시행 불가능한 조언은 피한다.
• 13 Noteworthy Points from Google’s JavaScript Style Guide
• 13 Noteworthy Points from Google’s JavaScript Style Guide ver.KOR

Airbnb Javascript Style Guide

• Global Standard
  • Why?
  • Airbnb가 최고는 아니다. 그러나 그들은 그 당시에 ES2015를 적용한 javascript style guide를 문서화해서 대중에게 최초로 공개했다.
  • 추가로, eslint plugin도 공개해서 자기네들의 style guide를 편하게 도입할 수 있었다.
  • 그 결과 많은 개발자들이 Airbnb Style Guide에 익숙해졌다.
• Airbnb는 자신들의 Guide를 fork 뜬 후, 각 팀의 Style Guide에 맞게 변경해서 사용하기를 권장한다.

W3S Javascript Style Guide

MDN Javascript Style Guide

• MDN 왈, 매우 간단한 수준으로 작성한 Style Guide
• Airbnb Style Guide와 호환되는 내용이 많으니, 더 자세한 설명이 필요하다면 Airbnb Javascript Style Guide 참고를 권장한다.

jQuery Javascript Style Guide

typescript style guide

Google Typescript Style Guide

• 이 Typescript Style Guide는 Google 내부에서 사용하는 버전을 기반으로 작성되었으나, 더 광범위한 개발자를 위해 일부 조정된 외부용 스타일 가이드에 가깝다.
• Google에 속해있지 않은 다른 개발자가 Style Guide 작성에 기여할 수 있다.

Typescript Style Guide (An unofficial Typescript Style Guide)

• 공식적인 Typescript Style Guide는 아니다.
• 그러나 표준 Javascript Style Guide를 참고하여 작성했다.
• 이외에도 Typescript 개발에 유용한 Tip을 많이 정리해두었다.

react style guide

Airbnb React/JSX Style Guide

• Javascript에서 널리 사용되는 표준을 기반으로 작성한 Style Guide
• 그러나 각 사례 별로 몇몇 Style Guide가 사용될 수도 있고 사용이 금지될 수도 있음을 유념해야 한다. (즉, 케이스 바이 케이스)

그 외

뱅크샐러드 Coding Style Guide

🤔 근데, 다른 사람들은 저런 걸 어떤 과정 끝에 만들었대?

여기 아주 훌륭한 글이 있다.

코딩 스타일에 대해 논쟁하는 이유
원글 : Why We Argue: Style

위 글에서 말하고 있는 내용을 간단하게 정리하면 (적고 보니 간단하지 않았다...) 다음과 같다.

• 스타일 가이드는 있어야 한다.
  • 코드는 쓰는 횟수보다 읽는 횟수가 훨씬 많다.
  • 자연스럽게 개발자는 한정된 리소스를 코드를 읽은 데에 더 많이 소모하게 된다.
  • 그러므로 응용 프로그램의 코드는 가독성이 중요하다.
  • 가독성을 위해 최적화하는 방법은 코드를 같은 스타일로 통일하는 것, 일반적인 스타일에 코드 작성을 맞추는 것이다.
• 최고의 스타일 가이드는?
  • 이 논의가 바로 분열의 시작이다.
  • "내 스타일이 최고다"라고 다들 알게 모르게 생각하고 있다.
  • 개발자 그룹에 특정 Coding Style Guide를 따를 수 있도록 동의를 구하기는 쉽다.
  • 그러나 어떤 Coding Style Guide가 우리 모두 따를 만한, '최고' 의 스타일인지 정하는 건 굉장히 어렵다.
• 왜 항상 의견이 갈라질까?
  • 스타일 전쟁은 표면적으로는 코드 형식의 문제처럼 보인다.
  • 그러나 실제로는 권력 다툼과 다를 바가 없다.
  • 스타일 전쟁은 팀의 긴장감을 부추기고 그들의 생각 비용을 증가시킨다.
  • 솔직하게 말하자면 스타일 전쟁은 팀 사기에 독이 될 뿐이다.
• 자기만의 방식으로 하려고 시도하지 말라.
  • 여기 개노답 삼 형제가 있다.
  • 자신들의 방식만이 옳다고만 믿는 고참 개발자 그룹
    • 지시로 모든 것을 해결한다.
    • 지시가 실패해도 자신들이 원하는 스타일로 그냥 진행한다.
    • 그룹의 합의는 무시해버린다. (혹은 무시해도 된다고 생각한다.)
  • 다른 언어의 경험을 현재 사용 중인 언어에 도입하려는 개발자 그룹
    • 자신이 선택한 스타일(다른 언어의 스타일)이 코드를 알기 쉽게 한다고 생각한다.
    • 그러나 그들의 선택은 다른 개발자에게 혼란만 가져다준다.
    • 그리고 그들은 그 사실을 애써 무시해 버린다.
  • 스타일에 대한 지론이 확실하지 않은 신인 개발자 그룹
    • 모든 스타일을 이것저것 실험하려고 한다.
    • 그래서 코드에 일관성이 없다.
    • 다른 개발자들은 그들의 실험적인 코드를 뒤처리하기 바쁘다.
  • 이렇게 되면 조직 내의 개발자 수만큼 스타일이 만들어진다.
  • "코드 일부분만 보여주고 누가 쓴 건지 알아 맞히기 게임 해볼까요? 우리 할 수 있겠죠?"
  • "당연하죠, 어떻게 그걸 모르겠어요?"
• 어떻게 해야 팀이 합의에 도달할 수 있을까?
  • 조직 내에서 스타일 가이드 협의 과정 중 오랜 시간 충돌만 이어지고 있으면, 스타일 가이드를 외부조달하자.
    • 잘 만들어진 스타일 가이드를 쓰지 않을 이유가 뭔가?
    • 내부에서의 불필요한 분쟁을 피하고 집단지성을 빌릴 수 있다.
    • 이렇게 되면 만족 정도와 아쉬운 정도가 서로 비슷해서 논의하기도 훨씬 더 편하다.
  • 스타일 가이드를 무사히 결정했다면, 모두가 그것을 따르게 만들자.
    • 정적 분석을 통해 코드가 스타일 가이드를 위반했다면 경고하는 절차를 자동화하자.
    • 개발자는 설명서를 하나하나 따져가듯 협업자의 코드 스타일을 검토하지 말자. 이건 잔소리다.
    • 대신 코드의 문제를 해결하기 위해 실질적으로 필요한 정보만을 제공하자.
    • PR의 내용은 코드의 외형보다 코드의 내용, 동작에 관한 것이어야 한다.
    • PR 올리기 전 스타일 위반은 모두 바로 잡자.
• 기존 코드는?
  • 기존 코드의 스타일까지 수정할 필요는 없다.
  • 앞으로 작성할 코드나 잘해라.
  • 오래된 코드는 다른 이유로 건드리게 될 때까지 내버려 둬라.
  • 만질 필요가 없는 코드의 스타일을 일부러 수정하는 것 = 백로그에 쌓여있는 다음 작업을 하는 것보다 오래된 코드의 스타일을 수정하는 것이 비즈니스 가치가 높다고 선언하는 것
  • 이미 안정화가 되어있고 스타일 수정에 비용이 크게 든다면 기존 코드에 손을 대지 않는다.
• 난 새로 정해진 스타일 가이드가 싫어.
  • 꾹 참고 가이드를 따라서 개발해보자.
    • 따르다 보면 생각이 바뀌기도 한다.
    • 낯설어서 그렇지 적응 후엔 새로운 스타일을 좋아하게 된다.
  • 새로운 스타일 가이드를 따르지 않겠다고 아주 단호한 결심을 해라.
    • 현 조직을 떠나 자신과 맞는 스타일을 사용하는 곳을 찾아가라.
    • 새 조직, 새 직장의 스타일 가이드를 따라라.
  • 결국 당신은 어딜 가게 되더라도 특정 스타일 가이드를 따르게 되어있다. 스타일 가이드를 따르지 않는다는 선택지는 없다.
• 교훈은?
  • 코드는 자신들의 방식대로 작성된 것보다 모든 코드가 비슷한 스타일로 되어 있는 것이 훨씬 중요하다.

촌철살인 그 자체다.

사실 카카오 엔터프라이즈 Cloud FE 파트는 Google이나 Airbnb 처럼 본격적인 Coding Style Guide를 작성할 수 없다. Google과 Airbnb는 우리보다 개발 인력도 많다. 또한 그들의 서비스는 어느 정도 완성되어 이미 시장에 선보여지고 있다. 그래서 실 서비스 개발을 하지 않고, 각종 업무 프로세스를 효율적으로 개선하기 위해 연구하는 개발자의 리소스를 아깝지 않게 생각한다. 나는 이것이 바로, 두 회사가 Coding Style Guide를 밑바닥부터 작성해서 세상에 공표할 수 있었던 큰 이유 중 하나라고 생각한다.

카카오 엔터프라이즈는 다르다. 우리는 아직 실 서비스 개발에 초점을 두고 나아갈 때다. 프로세스 개선도 물론 중요하지만 개발보다는 '덜' 중요하다. 그렇지만 아무것도 개선하지 않고, 정립하지 않고, 해당 논의의 필요성을 무시하고 그냥 지나칠 순 없는 상황이다. (당연하다. 개편된 조직 내의 체계와 문화를 잡지 않고 구성원에게 무조건 앞으로 달리라고만 말하면 그들이 제대로 목적지에 도착할 수 있을까? 준비 운동은 어느 과정에서나 꼭 필요하다.)

코딩 스타일에 대해 논쟁하는 이유는 그러한 우리의 상황에 딱 들어 맞는 시의적절한 내용을 담고 있다. 정말 글쓴이에게 찬사를 보내고 싶을 정도로.

📢 결론

굳이 서로 털어놓지 않아도 알 수 있다. 나를 포함한 카카오 엔터프라이즈 Cloud FE 파트원 모두가 Coding Style Guide 논의를 앞둔 상황에서 공감하는 바는 아래와 같을 것이다.

1. Coding Style Guide는 필요하다.
2. 스타일 가이드를 밑바닥부터 하나씩 다 정할 시간은 없다. (우리에겐 사치다.)
3. "최고의" Coding Style Guide를 정하겠다고 논쟁만 길어지는 건 가치 없는 소모전일 뿐이다.
4. 이미 잘 만들어진 걸 가져다 쓰지 않을 이유는 없다.
5. 팀의 확장이 일시적으로 멈춘 지금, 시간을 내서 스타일 가이드 논의를 성공적으로 빠르게 마쳐야 한다.
6. 이후 작성될 코드는 일관된 스타일을 갖추고 있어야 하며, 해당 작업은 빠르게 이루어질수록 좋다.
7. 급작스럽게 조직 개편을 겪은 구성원들의 혼란을 덜어내고 확실한 체계로 안정감을 부여해야 하며, 해당 작업은 빠르게 이루어질수록 좋다.

다행히 리서치는 만족스러운 수준이다. 이번 리서치를 통하여 이미 잘 만들어진 훌륭한 Coding Style Guide를 찾을 수 있었고, 우리와 매우 유사한 상황에 부닥쳤던 이들이 스타일 가이드 논쟁을 이끌어 나가는 과정 또한 찾을 수 있었다. 준비는 끝났고 실천만이 남아있다. 그렇다면 우리가 여기서 더 머뭇거릴 필요가 있을까?