코딩 컨벤션(Coding Convention)

코딩 컨벤션, 네이밍 컨벤션, 팀 내 컨벤션 등등...

개발자들은 일상적으로 많은 상황에서 컨벤션이라는 단어를 쓰고 있다.

 

Convention

우리 말로는 협약, 약속 등으로 번역되는 말로 '함께 와서 모이고 참석하다'는 라틴어가 그 어원이다.

 

그럼 코딩 컨벤션은 무엇일까? 위키피디아에 기재된 코딩 컨벤션에 대한 정의는 다음과 같다.

프로그래밍 스타일 , 관행 및 방법을 권장 하는 특정 프로그래밍 언어에 대한 일련의 지침

일반적으로 파일 구성, 들여쓰기, 주석, 선언, 명령문, 공백, 명명 규칙, 프로그래밍 관행, 프로그래밍 원칙, 프로그래밍 경험 법칙, 아키텍처 모범 사례 등을 다룬다

위키피디아에서의 정의는 언어에 대한 지침으로 국한되어 있으나, 코딩 컨벤션은 언어 전반에 걸쳐 존재할 수도 있고 특정 프레임워크에 대해서도 존재할 수 있다.

 

언어에 대한 지침은 공식적이진 않지만 대부분의 개발자들에게 암묵적인 공감대로 존재하며, 아래와 같은 레포를 통해 좀 더 엄격화된 형태로 공유되기도 한다.

 

GitHub - ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript

 

해당 언어 사용자들에게 암묵적인 공감대로 존재하는 코딩 컨벤션이 아닌, 팀 단위에서 보다 엄격하게 적용되는 코딩 컨벤션들도 존재한다.

 

이러한 코딩 컨벤션은 대게 팀 혹은 회사 차원에서 논의와 정의, 합의를 통해 완성되거나 개선된다. 그리고 그 합의 내용은 문서화가 되어 공식화되거나 암묵적으로 구전(...)된다.

 

코딩컨벤션

 

언어 사용에 대한 컨벤션이 아닌, 라이브러리 혹은 프레임워크 사용 시에 권장되는 컨벤션들도 존재한다. 예컨대 리액트 사용 시의 컴포넌트 이름은 대문자로 시작해야 한다거나,  이벤트 콜백에 대한 props 이름은 on[Event] 형태나 handle[Event] 형태로 작성한다는 등의 암묵적인 합의들이 그러하다.

 

위의 예시 뿐만 아니라, 코딩 컨벤션의 정의에서도 언급했다시피 보다 넓고 추상적인 부분에서의 컨벤션들도 존재할 수 있다. 폴더 구조를 어떻게 설계할 것인가, 컴포넌트의 단위는 어떻게 정의할 것인가, 상태 관리의 책임과 역할을 누구에게 위임/일임하는가 등등... 조직마다의 개발 철학에 따라 전혀 다른 관점에서의 소프트웨어 설계를 할 수 있는 것이다.

 

우리가 온보딩 과정에서 어려움을 겪는 이유 중 가장 큰 부분이 바로 이 점일 것이다. 같은 언어, 같은 프레임워크, 같은 라이브러리를 사용하는 다른 조직으로 이직을 한다고 해도 소프트웨어를 바라보는 관점에 따라 전혀 다른 컨벤션이 존재하기 때문에 체화를 위한 시간과 노력이 필요하다.

 

흔히 말하는 '체계가 잡혀있다' 는 개발 조직은 이러한 컨벤션이 문서화 혹은 어떤 형태로든 새로운 인원이 받아들이기 원활하게끔 프로세스가 구축되어있는 곳이라는 말이다. 이러한 조직은 보통 규모가 클 확률이 높은데, 조직 내 컨벤션을 정리하고 관리하는 비용보다 신규 인원의 온보딩에 드는 비용이 더 커졌을 때 경제성이 있는 의사결정이 되기 때문이다.

 

컨벤션이 없거나, 있지만 문서화가 되지 않은 작은 조직들의 경우엔 어떻게 대처해야 할까?

 

먼저 컨벤션 정리에 대한 효용을 조금 다른 관점으로 바라봐야 한다고 생각한다.

 

컨벤션 정리를 통해 신규 인원의 연착륙을 돕는 부분도 물론 중요하겠지만, 기존 팀원들이 모호하게 서로 다른 개념으로 접근하고 커뮤니케이션하던 부분들을 명확하게 정리할 수 있는 부분에 초점을 맞춰야 한다.

 

위와 같은 관점으로 문서를 작성하게 된다면 A-Z 형태가 아닌, 이슈 위주와 토론이 있었던 항목 등을 중점으로 뼈대를 삼아 점차 늘려나가는 방식으로 작업을 할 수 있을 것이다.

 

'문서화'라고 하면 뭔가 목차부터 다 정리하고 변수명에 대한 컨벤션부터 시작해야 할 것 같은 느낌이 들어 부담스럽고 망설여지는 부분이 있는데 위와 같은 방식을 사용하면 고민했던 굵직한 사건들을 떠올리며 당장 시작해 볼 수 있을 것이다.

 

-

 

내가 이런 이야기를 적는 이유는, 우리 팀에서도 슬슬 문서화된 코딩 컨벤션이 필요하지 않나 하는 생각이 들었기 때문이다.

 

물론 우리 팀에도 기존의 많은 합의와 토론을 통해 암묵적으로 공유되는 컨벤션이 분명히 존재한다. 그러나 코드 리뷰 도중 서로 다른 관점으로 해당 컨벤션을 해석하고 있었다는 것을 깨닫는 경험이 왕왕 있었다. 그리고 그 과정에서 커뮤니케이션 비용이 적지 않게 소요되는 부분도 아쉬웠다.

 

조만간 이 부분에 대해서 건의를 해 볼 생각이지만, 사실 조직 내에서의 컨벤션 수립과는 별개로 내 블로그에 내가 생각하는 몇 가지 코딩 컨벤션을 정리할 계획이다. 앞서 말했듯이 이슈 위주로 정리를 할 계획이며, 부족한 토론과 합의는 집요한 Why를 통해 보충해서 끄적여 보려고 한다.

 

사실 내가 블로그에 이렇게 컨벤션에 대한 글을 쓰려는 가장 중요한 이유는 '치열하게 고민했던 과정과 그 결과물'을 잊어버리고 싶지 않아서가 제일 큰 것 같다는 생각이 든다... 잊어버리면 너무 아깝자너