- 목차 -

회사에서는 혼자 일하는 게 아니다.

프로그래밍을 혼자 할 일은 거의 없습니다. 심지어 개발팀 안에서도 프론트엔드, 백엔드, 데브옵스 등 여러 분야로 나뉘어져 서로 협업을 하는 관계죠. 회사에 처음 들어왔을 때에는 코드 규칙이라든가 누가 어떤 방식을 사용하는지 별로 중요하게 느끼지 못했어요. 그저 화면설계서대로 기능이 구현되고, 디자인이 제대로 적용되어있으면 된다고 생각했습니다.

신규 프로젝트를 시작하고 운영/유지보수가 필요없다면 명세서 대로 구현만 되면 그게 끝인데, 그런 프로젝트는 거의 없습니다. 코드를 분석하고 왜 이런 일이 발생했는지 알아내야하는 일이 많습니다. 여기서 코드 스타일, 변수 등이 다 다르게 되어있다면 어떨까요? 본인이 맡았던 부분은 며칠, 몇주동안 봐왔던 것들이니 정말 눈에 익고 어느 부분에서 문제가 발생했는지 대충 감을 잡을 수 있습니다. 다른 동료가 작업한 곳에서 발생한 이슈는 코드 분석부터 시작해야해서 최악의 경우에는 어떤 파일에 들어있는지, 어디서 발생하고 있는지도 찾는데 한참 걸리겠죠. 하지만 코드 컨벤션이 정해져있고, 규칙이 있다면 분석하고 수정하는 데 걸리는 시간은 엄청나게 단축이 될 겁니다.

바로 어제 회사 코드 규칙과 관련한 사소한 문제가 있었습니다. 약어때문에 생긴 문제였습니다. 회사에서는 aws S3 서비스를 사용 중인데, 컨텐츠 경로에 맞게 들어가 썸네일을 등록을 하고 프론트에 해당 이미지 url을 통채로 전달해줍니다. 그런데 아무리 봐도 해당 폴더 안에 이미지도 있고 파일명도 같은데 404 not found 라고 응답이 왔습니다. 문제는 폴더 (경로)명이었습니다. 백엔드팀에서 사용하는 약어가 정말 많았는데 예를들면 category를 catgry로 같은 것들이 있습니다.이전 프로젝트 코드를 계속 클론하여 시작돼 레거시 코드들 때문에 회사 코드 규칙으로 자리 잡혔던 약어들입니다. 신규로 만든 폴더명은 category로 되어있어서 catgry/파일명 으로 찾으려해서 계속 찾지 못했던 것이었습니다. 만약 제대로 정해진 규칙이나 코드 사전 같은 것들이 정의되어있었다면 확인도 안 하고 작업할 수 있던 문제였겠죠? 앞으로 차차 완성해나갈 시간들이 정말 기대됩니다.

프로젝트가 끝나고 공백 기간에는 동료들과 함께 이런저런 코드 규칙을 정리하고 회사의 코드 컨벤션을 만들어 나가며 토론하는 시간도 정말 재미있는 것 같습니다. 🌟