코딩 컨벤션? 네이밍 컨벤션?

코딩 컨벤션의 한 갈래인 네이밍 컨벤션(Naming Convention)은 코드에서 사용되는 명명(命名) 규칙이에요. 그렇다면 코딩 컨벤션은 뭘까요? 

흔히 ‘개발자는 코드를 쓰는 시간보다 코드를 읽는 시간이 더 길다’고들 하죠. 프로젝트가 진행됨에 따라 이미 작성된 코드를 수정하고 버그를 찾는(Debugging) 일이 늘기 마련입니다. 이미 만들어진 외부 라이브러리 등을 활용할 목적으로 관련 코드를 읽는 경우도 많죠. 더욱이 여럿이 협업하는 프로젝트라면 다른 사람이 작성한 코드를 이해해야 하고요.

이렇듯 코딩 컨벤션(Coding Convention)은 읽고 관리하기 쉬운 코드를 작성하기 위해 코드를 ‘쓰는’ 방식을 정하는 규칙과 관행이에요. 들여쓰기(Space를 쓸 것인지 Tab을 쓸 것인지), 공백, 줄바꿈, 주석 작성 방식, 코드 구조 등 코드 스타일에 대한 여러 규칙을 통일해 소스 코드의 가독성을 높이고 일관성을 유지하게끔 해요. 

_{‘조선 붕당의 이해’ 밈을 패러디한 ‘코딩으로 본 조선 붕당의 이해’. 들여쓰기에 탭과 스페이스 중 어떤 걸 사용해야 하는지는 개발자 사이 오랜 논쟁(?)거리이기도 하죠.}

그중에서도 네이밍 컨벤션은 소스 코드에 쓰이는 식별자(변수, 함수, 클래스, 타입 등)에 이름을 붙이는 방법을 다뤄요. 쉽게 말해 변수나 함수 등의 이름을 어떻게 지으면 좋을지에 대한 약속이라고 할 수 있어요.

뱀부터 케밥까지, 대표적인 네이밍 컨벤션 6가지

보통은 식별자 이름으로 영단어를 조합해 붙이는 경우가 많은데요. 유의할 점 중 하나는 여러 단어를 이어 만들 때 단어와 단어 사이에 공백(띄어쓰기)을 넣지 않아야 한다는 것입니다. 많은 프로그래밍 언어에서 두루 쓰이는 변수(Variable)가 대표적인데요.

일반적으로 프로그래밍 언어에서 변수명은 공백이 없는 낱말로 이루어져야 해요. 만약 공백이 포함되면 컴퓨터는 변수가 들어간 코드를 하나의 변수로 해석하지 못하고 문법 오류(Syntax Error)로 처리하기 때문이죠. 더욱이 데이터를 저장하고 조작하는 데 변수가 폭넓게 쓰이는 만큼, 변수명을 어떻게 짓는지에 따라 코드의 가독성과 유지보수 편의가 크게 좌우될 수 있어요. 

때문에 변수명을 비롯한 여러 식별자 이름을 짓는 데 쓰이는 네이밍 컨벤션은 여러 단어를 이어 쓸 때를 전제로 한 규칙을 세우고 있습니다. 잘 알려진 네이밍 컨벤션으로는 이런 것들이 있어요.

이러한 네이밍 컨벤션은 프로젝트의 상황이나 채택하는 기술의 특성에 따라 다양하게 혼합되어 쓰이고 있어요. 프로그래밍 언어, 프레임워크 등 기술마다 주로 사용되는 네이밍 컨벤션이 있죠. 

공식 문서를 통해 권장하는 컨벤션을 정해 두기도 하고, 해당 기술을 사용하는 커뮤니티에서 여러 개발자들이 특정 컨벤션을 관습처럼 따르기도 합니다. 한편 한 기술 안에서도 식별자 유형마다 추천하는 컨벤션을 구분해 두기도 하는 만큼 수없이 많은 사례가 있다고 볼 수 있어요.

_{팀 여건이나 외부 API 사용 여부 등 여러 이유로 Node.js 프로젝트에 공식 문서에서 권장하는 카멜 케이스가 아닌 다른 네이밍 컨벤션을 함께 사용하기도 해요. DB 컬럼 이름에 여전히 스네이크 케이스가 쓰이기 때문에, JS/TS 애플리케이션과 함께 쓰는 일부 DB 클라이언트(ORM)에서는 테이블 컬럼의 스네이크 케이스를 자동으로 카멜 케이스로 매핑해주는 기능을 지원하죠. 지원하지 않는 클라이언트에서는 별도 패키지를 사용해서 처리해야 하고요. 
(함께 읽으면 좋은 글 : "Snake_case or camelCase in node.js", "TypeORM에서 Camelcase 필드를 Snake 컬럼에 매핑하기")}

_{네이밍 컨벤션은 개발자와 협업하는 프로덕트 디자이너에게도 중요한 영역이에요. (인프런 강의 “피그마 배리어블을 활용한 디자인 시스템 구축하기”)}

URL 슬러그엔 왜 케밥 케이스를 쓸까?^*

케밥 케이스는 대시(-)로 단어와 단어를 명확하게 구분하기 때문에 검색 엔진 최적화(SEO)에 유리한 영향을 미칠 수 있다고 해요. 더욱이 가리키는 단어를 명확하게 알 수 있는 만큼 사용자가 URL을 구분하고 파악하기에도 편하죠. (이 페이지의 슬러그도 케밥 케이스를 따라요!)

네이밍 컨벤션, 왜 지켜야 할까?

네이밍 컨벤션은 소스 코드를 읽고 이해하는 데 드는 노력과 부담을 덜어주는 역할을 하는데요. 잘 따르게 되면 이런 장점이 있어요.

특히 대규모 프로젝트에서는 네이밍 컨벤션을 지킴으로써 코드베이스 전체가 일관된 스타일을 갖추는 것이 작업 능률을 높이는 데 무척 중요해요. 모든 팀원이 비슷한 상황에 공유된 스타일을 지킴으로써 혼란을 줄이고 협업을 원활하게 할 수 있기 때문이죠. 그래서 코드 리뷰 과정에서도 네이밍 컨벤션 검토는 중요한 고려 사항 중 하나로 꼽혀요.

물론 여러 사람과 협업하지 않는 1인 프로젝트라고 해도 네이밍 컨벤션을 준수하는 건 바람직한 습관이에요. 이후에 협업을 하거나 오픈 소스로 프로젝트로 공개할 가능성도 있고, 협업을 제외한 여러 장점들이 결국 코드의 질을 높이고 개발 과정을 보다 효율적으로 만들어주기 때문입니다.

좋은 이름 짓기가 어려운 이유 
스타일을 넘어서, 이름 ‘잘 짓는’ 원칙

_{수박을 ‘몽미’라고 부르면 다른 사람이 무엇을 얘기하는 건지 알아듣지 못하는 것처럼, 식별자 이름은 가리키는 대상을 명확하게 알 수 있어야 해요. ⓒ천재교과서}

여러 네이밍 컨벤션 유형을 따르기에 앞서, 어떤 단어로 이름을 지을 것인지도 무척 중요합니다. 핵심은 ‘정확한 의미를 알기 쉽게’라는 점인데요.

식별자의 이름은 해당 식별자가 담고 있는 기능과 데이터, 역할 등을 명확히 전달해야 해요. 알아보기 어려운 약어나 은어로 지은 이름은 협업하는 다른 개발자는 물론 처음 이름을 지었던 개발자 본인도 뜻을 단번에 알아보거나 기억해내기 어려울 수 있어요. 간결한 이름만으로도 해당 식별자의 역할을 충분히 설명할 수 있다면 짧은 이름이 좋지만, 지나치게 압축적이라서 이해하기 어렵다면 오히려 독이 될 수 있죠.

_{프로그래밍을 하다 보면 변수명을 짧게 할지, 길고 자세하게 지을지 고민하게 될 때가 많아요.}

과거에 인기를 끌던 헝가리안 표기법이 지금은 쇠퇴한 이유도 코드 가독성과 편의에 따른 변화라고 볼 수 있어요. 헝가리안 표기법이 등장했던 시절엔 코드에서 변수명만 보고도 데이터 타입(Data Type: 자료형)을 바로 추정할 수 있다는 점이 유용하게 작용했죠.

하지만 지금은 IDE(통합 개발 환경)에서 코드 완성 기능, 타입 추론 등 여러 기능을 지원하기 때문에 변수나 함수의 타입을 이름에 명시할 필요가 줄었습니다. 오히려 이름마다 불필요한 정보(타입)가 붙어 코드 가독성이 나빠지고, 개발 도중에 데이터 타입이 바뀐다면 모든 이름을 수정해야 한다는 단점이 두드러졌고요.

의미적인 일관성을 유지하는 것도 중요합니다. 많은 프로젝트에서 한 개념에 대해 다른 네이밍 컨벤션을 사용하면서 여러 이름이 혼재되는 경우가 심심치 않게 발생하는데요. 때문에 동일한 유형으로 구분되는 변수라면 동일한 패턴이나 접두사 등을 써서 일관되게 이름을 지을 필요가 있죠.

따르고자 하는 네이밍 컨벤션의 대소문자 및 연결부호 사용을 지키면서도 오탈자가 생기지 않도록 주의해야 하고요. 프로그램이 실행될 때 에러나 버그가 발생하지 않도록 여러 기술적인 조건도 꼼꼼하게 고려해야겠죠.

다시 말해 가리키는 대상이 뚜렷하면서도 유일한 표현을 사용하고, 일관적이면서도 시간이 지나도 뜻이 변하지 않는 영속성을 지닌 이름이 ‘좋은 이름’이라고 할 수 있어요.

_{IDE인 Visual Studio Code(비주얼 스튜디오 코드)에서 변수명 오타를 잡아주는 익스텐션도 있어요.}

_{카카오페이에서는 사내 해커톤을 통해 변수명을 추천해 주는 ‘너의 변수명은.’ 슬랙(Slack) 챗봇을 개발한 과정을 기술 블로그에 공개하기도 했어요.}

끝으로, 협업 과정에서 네이밍 컨벤션을 정할 때 무엇보다 중요한 건 바로 합의 자체에 있다는 점을 생각해야 해요. 여러 네이밍 컨벤션 가운데 가장 적절해 보이는 컨벤션을 선택하는 건 물론 중요한 일이지만, 팀을 둘러싼 제약이나 특수성을 충분히 고려하지 않는다면 오히려 효율이 떨어지거나 문제가 발생할 수도 있기 때문입니다. 그래서 컨벤션마다의 우위를 따지기보다는 어떤 컨벤션을 선택할 것인지에 대해 충분히 논의하고, 그렇게 정한 규칙을 팀 안에서 올바르게 따르는 게 더욱 중요해요.

_{X(트위터)에서 누적 19만 조회수를 기록한 토스페이먼츠 ‘세종대왕 프로젝트’.}

작년 7월 X(트위터)에서는 토스페이먼츠의 한글 코딩 컨벤션 ‘세종대왕 프로젝트’가 화제가 되기도 했는데요. 토스페이먼츠에서는 ‘국가지방자치단체 공공단체 금융사 여부’처럼 어려운 도메인 용어를 쉽게 이해할 수 있도록 변수, 상수, 함수, 타입 등을 한글로 표기하고 있다고 합니다. 

이러한 컨벤션에 대해 우려를 보내는 시선도 있는데요. 특히 글로벌 서비스를 제공하거나 한국어를 구사하지 않는 개발자가 소속된 팀 등 외부와의 협업 및 기술 연동에 어려움이 발생할 수 있다는 이유 등을 꼽을 수 있죠. 하지만 외부의 관점으로 판단하기보다는 실제로 컨벤션을 따르는 조직 안에서의 합의가 중요하다는 의견도 존재합니다. 결국 네이밍 컨벤션을 고민하는 것도 여러 다양한 방법 가운데 우리 팀에 가장 어울리는 선택(Best Practice)을 찾는 과정이니까요.

_{인프런과 랠릿을 만드는 인프랩 프론트엔드 파트에서는 코딩 컨벤션에 대해 논의하는 슬랙 채널을 마련해두고 있어요.}

오늘도 많은 개발자들이 좋은 이름을 고민합니다.
이름 하나하나가 코드의 만듦새를 결정하고, 팀의 개발 환경을 일궈 나가죠.
그래서 네이밍 컨벤션을 정하고 따르는 과정은 단순히 이름을 붙이는 일 이상의 의미를 가져요. 개발자의 일하는 방식과 고민이 이름 하나하나에 담겨 있다고 해도 과언이 아니죠.

네이밍 컨벤션에 대한 이야기, 어떠셨나요?
여러분이 선호하거나 주로 쓰는 네이밍 컨벤션은 어떤 게 있나요?
네이밍 컨벤션과 코딩 컨벤션에 대한 여러분의 이야기를 들려주세요. 😊

_{당신의 변수명에 투표하세요! 😉}

함께 보면 좋은 강의