저희 회사에 프로그래머가 입사하게 되면 몇 가지 교육을 실시하게 되는데, 그 중 하나가 VS notation 교육입니다.
VS notation은 코드 작성 시 네이밍 규칙과 코드 스타일 등등 코드 작성에 대한 규약입니다. 구글에서도 VS notation과 같이 코드 스타일에 대한 가이드라인을 google styleguide 라는 이름으로 공개하고 있습니다.
VS notation은 2007년에 최초로 작성이 되어 지금까지 그 내용이 누적되어 왔습니다. 그것이 가장 잘 드러나는 것은 개발 기간이 가장 오래된 엔진입니다. 그 외 프로젝트들의 코드 스타일을 살펴보면, 개발년도에 따라 혹은 메인 프로그래머에 따라 약간씩의 차이는 있지만 대체로 일관된 스타일을 유지하고 있습니다.
일관된 코드 스타일을 유지하는 것은 생각보다 굉장히 중요한데, 누구도 아닌 코드를 읽는 프로그래머가 바로 그 수혜자가 됩니다. 단순히 indentation을 일관되게 유지하는 것에서부터 단어의 의미를 일관되게 사용하는 것, 복잡하게는 상속이나 함수 객체 등의 사용에 이르기까지 스타일을 유지하는 것은 코드를 읽는 프로그래머가 구현 내용을 이해하는 데 큰 도움이 됩니다. 회사 내부에서 프로그래머 간 협업에 큰 도움이 된다는 것입니다.
만약 SDK나 API를 다른 회사에 판매하는 회사라면 단순히 내부에서만 그치는 것이 아니라 외부에 전달되는 제품의 품질에도 영향을 미칩니다. 모바일 쪽에서 보자면 iOS가 그 예가 될 수 있겠습니다. iOS 개발을 하다보면 언제부턴가 iOS만의 일관된 코드 스타일이 보이기 시작합니다. 이것은 개발자들이 일관된 코드 스타일을 유지하게 노력하였기에 그것이 iOS를 사용하는 프로그래머에게 느껴질 만큼의 품질로 이어졌다는 것을 의미합니다. 이렇게 되면 SDK를 가져다 쓰는 사람이 보다 쉽게 API를 이해하고 가져다 쓸 수 있게 되겠지요.
그런데 생각보다 많은 프로그래머들이 이를 무시하는 경우를 종종 보게 됩니다. 그 이유를 보면 이 코드 스타일은 별로 적합하지 않다고 느끼거나, 혹은 개인의 스타일이 있기 때문이라던가 하는 이유입니다.
코드 스타일이 적합하지 않다고 느낀다는 것은 충분히 이유가 될 수 있습니다. 코드 스타일마다 장단이 있을 수 있고, 항상 정답이 되는 코드 스타일은 있을 수 없기 때문에 문제가 된다고 느끼는 부분이 있다면 프로그래머들의 회의를 거쳐 수정할 수 있습니다. 다만 먼저 논의를 거쳐야 한다는 것을 유념해야겠습니다. 이미 합의되어 유지되고 있는 코드 스타일이 있다면, 그것은 이미 회사의 개발 문화로 사람들에게 공유되어 있는 것이기 때문에 갑작스럽게 이와 다른 코드를 작성하여버린다면 졸지에 팀웍 브레이커라는 눈총을 받을 수도 있습니다.
두번째 이유인 개인의 스타일 문제는 다른 차원의 문제입니다. 회사의 코드 스타일에 대해 특별히 이견이 없음에도 개인의 코드 스타일을 유지하겠다고 하는 것은, 마치 그래픽 디자이너가 게임의 화풍과는 상관없이 자신의 화풍으로 그림을 그리겠다거나 혹은 시나리오 작가가 게임 시나리오와는 무관하게 자신만의 문체를 고집하는 것과 비슷한 맥락이라고 할 수 있지요. 프로그래머가 가장 가까이 하고 있는 클라이언트는 바로 옆에서 함께 일하는 팀원들과 회사입니다. 개발은 협업이라는 사실을 잊지 말아야 합니다.
회사의 코드 스타일, notation은 아주 기본적인 내용인만큼 무심코 간과하고 넘어가게 되는 것도 사실입니다. 하지만 무심코 넘어간 그 작은 차이가 누적되어서 나중에 코드를 읽을 누군가에게 고통을 안겨주거나 혹은 제품의 품질 차이로도 이어질 수 있습니다.
오늘은 코드 commit 시에 한 번 notation을 꼼꼼히 살펴보는 시간을 가져보시는 것은 어떨까요?
by Jake Noah
