Table of contents
들어가며
안녕하세요~ 
프론트웹개발팀의 주니어 개발자 박수현, 허예은입니다! 프론트웹개발팀에 입사한 지 어느덧 1년이 다 되어가네요! 저희 팀은 구성된 지 얼마 안 되어서, 개발 문화가 정착되어 가고 있는 중인데요. 최근 몇 개월 동안 팀의 개발 문화를 만들어가기 위해 노력한 것과 느낀 점, 앞으로의 방향성 등에 대해 공유해보고자 합니다!
프론트웹개발팀의 주니어 개발자 박수현, 허예은입니다! 프론트웹개발팀에 입사한 지 어느덧 1년이 다 되어가네요! 저희 팀은 구성된 지 얼마 안 되어서, 개발 문화가 정착되어 가고 있는 중인데요. 최근 몇 개월 동안 팀의 개발 문화를 만들어가기 위해 노력한 것과 느낀 점, 앞으로의 방향성 등에 대해 공유해보고자 합니다!1. 코딩 컨벤션
코딩 컨벤션은 읽고, 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약입니다. 여러 명이 작업하는 협업 프로젝트에서 일관된 스타일을 유지하고, 추후 유지보수를 하는 데 있어서도 효율성을 높이기 때문에 중요한 요소라 할 수 있어요.
이 글에선 Prettier, ESLint 등 코드 포맷팅 도구 세팅을 제외하고 커밋 메시지, UI 마크업 컨벤션을 주제로 잡아보았습니다.
(1) 커밋 컨벤션
프론트웹개발팀에 들어와서 처음 하게 된 팀 프로젝트가 넥슨 주소찾기 프로젝트였어요. 당시엔 커밋 메시지의 중요성에 대해서도 무지했고, 어떤 방식으로 작성하는 것이 좋은지 잘 몰랐기에 이런 부분을 정리하지 않은 채로 각자 코드를 작성하고 로그를 남겼습니다. 그 결과는 다음과 같았습니다.
그림 1 : 인턴 생활 첫 프로젝트 '주소찾기'의 커밋 메시지들. 다채로운 커밋 메시지로 인해 보는 사람으로 하여금 혼란을 느끼게 한다.
이런 시행착오를 겪고 나서는 다른 프로젝트를 시작할 때 ‘커밋 컨벤션부터 작성해보자!’ 라는 생각을 갖게 되었어요. 그리고 시간이 흘러 다음 프로젝트를 시작하기 전, 우리 팀은 어떤 방식으로 커밋 메시지를 사용하는지 조사했고, 따로 문서화가 되어있진 않았지만 팀원들의 작성 패턴을 정리하고 (구글링도 해서) 우리 프로젝트에 맞는 컨벤션을 만들어 제안해 보았습니다.
그림 2 : 커밋 컨벤션 제안
팀원분께 말씀드려보니, 최근엔 emoji를 활용한 커밋 메시지도 있다고 하시더라구요!
emoji를 활용한 커밋 메시지도 있다고 하시더라구요! 
그림 3 : emoji를 활용한 커밋도 꽤 흥미롭다!
익숙해지기까지는 좀 오래 걸리겠지만, 커밋 컨벤션에도 정말 다양한 방식이 있다는 것을 알게 되었습니다.
우선 저희는 프로젝트에 가장 많이 쓰였고, 적용하기 쉽고, 가독성이 좋은 3~4 글자의 대문자 제목을 활용해보기로 했습니다.
그림 4 : 대문자 제목을 활용한 커밋 컨벤션
[분류 제목]: [내용] #[이슈 번호]
위와 같은 형태로 커밋 메시지를 통일하니, 제목만 봐도 해당 작업이 기능 추가인지, 버그 수정인지, 코드 리팩토링인지 한 눈에 알 수 있어서 보기에 ‘편ㅡ안’ 해졌습니다.
또한 이슈번호를 뒤에 태깅해주면 gitlab에서 link가 자동으로 걸리기 때문에, 해당 커밋의 이슈를 보고 싶을 때도 매우 편리합니다.
물론 아쉬운 점은 있습니다. 추후 100년 뒤 팀원 한 명이 커밋 한 줄만 봤을 때 어느 파일의 어느 부분을 수정했는지 알 수 있는 수준까지는 아니기 때문입니다. 커밋 내용을 좀 더 자세하게 쓰는 습관을 들이면 더욱 좋을 것 같습니다.
커밋은 프로젝트의 역사를 기록하는 행위라고 생각합니다. 여러 명이 작성하는 글에서 일관성 만큼 중요한 것은 없겠죠. 이러한 작은 변화가 개발 효율은 물론이고, 팀의 협업능력을 키워주는 원동력이 될 것이라고 생각합니다.
(2) UI 마크업 컨벤션
개발자의 능력 필수요소 중 하나가, 네이밍 센스라는 말이 있습니다. 하지만 저는 그렇지 못했죠. 변수명 짓기도 마찬가지였지만, 특히나 스타일 파일 작업 시 class 이름짓기가 정말 어려웠습니다.
그림 5 : 중구난방 클래스 이름 예시
카멜 케이스(showMap), 스네이크 케이스(juso_name)를 혼용하고, 주소를 juso라고 번역해 놓은 처참한 모습입니다. 코딩 컨벤션의 중요성을 절실히 깨닫게 해 주었던 예시죠.
이후 서브 프로젝트로 UI 개발자분들과의 협업이 중요한 넥슨 UI 프로젝트를 진행하면서, 이를 정리해주신 천사같은 팀원 분이 계셨는데요..! 무려 코딩 컨벤션을 정리한 PPT를 (새벽까지) 손수 제작하셔서 발표해 주셨습니다.
그림 6 : 해림님의 PT
해림님의 PT주요 내용을 정리해보자면 다음과 같습니다.
1.
class 이름은 영문 소문자, 언더스코어(_)로만 시작, 작성한다. 주석문은 영문 대문자 사용 가능
2.
id 이름은 camelCase 혹은 대문자 SNAKE_CASE (통일해서 사용)
3.
id는 레이아웃 (#header, #footer, #nav) 외에 스타일 지정을 위해 사용하지 않는다.
4.
CSS 스타일 지정과 자바스크립트 동작 제어는 서로 다른 책임을 갖기 때문에, 각각을 분리해서 관리하는 것이 유지보수 측면에서 유리하다.
JS에서 CamelCase를 사용하고 CSS네이밍은 KEBAB-CASE를 사용하는 식으로 네이밍 방식으로 구분하거나, 좀더 명시적으로 js- 등의 접두어를 붙이는 방법을 사용하기도 한다.
id와 class의 네이밍 방식을 다르게, 또 CSS와 JS의 네이밍 방식을 다르게 한다는 점이 인상깊었습니다.
이 내용들이 가리키는 방향은 결국 하나라는 생각이 들었어요.
같은 역할은 같은 네이밍 방식을, 다른 역할은 다른 네이밍 방식을 사용하자!
PT가 끝나고, 팀원들끼리 이에 대해 논의하는 자리도 가졌는데요. ‘팀 별 컨벤션 규칙을 정하는게 좋다’, ‘주요 컨벤션만 통일하고, 프로젝트별 컨벤션 규칙을 작성해야 한다’ 등 다양한 의견이 오고 갔습니다.
저는 컨벤션에 정답은 없다고 생각합니다. 가장 선행되어야 할 작업은, 우리 팀에 잘 적용할 수 있는 우리만의 컨벤션을 만드는 것이겠죠.
넥슨 UI 프로젝트가 이제 막 본격적으로 시작되려는 시점에, 이런 컨벤션 PT가 프로젝트의 방향성을 잡아주게 된 것 같습니다.
기존 프로젝트에서는 컨벤션 규칙에 대해 이야기 나눌 수 있는 자리가 부족했는데, 앞으로는 프로젝트를 시작하기 전 팀원들과 함께 협업이나 컨벤션에 대해 얘기할 수 있는 자리를 가지면 좋겠다고 생각했습니다. 그러다 보면 ‘넥슨 코딩 컨벤션’ 처럼 우리 팀을 넘어 넥슨에서 공통적으로 사용하는 컨벤션 규칙도 나오게 되지 않을까요?
2. 코드 리뷰
코드 리뷰는 여러 개발자가 코드를 점검하고, 피드백을 주는 과정을 말해요. 이러한 과정에서 코드 퀄리티가 높아지게 되고, 버그를 줄일 수 있게 됩니다.
저희는 ‘넥슨 박물관 리뉴얼’과 ‘사내 좌석배치 Round’ 프로젝트에 참여했는데요, 해당 프로젝트 리드를 맡은 팀원 민구님이 주축이 되어 주니어 개발자들이 코드 리뷰를 경험해볼 수 있도록 해 주셨습니다.
그림 7 : 입사 후 코드 리뷰를 통해 제 코드가 온 천하에 드러나고 여기저기서 호되게 당하는 상상을 했었죠...
(1) 코드 리뷰의 필요성
우리는 다음과 같은 이유로 팀 내 코드 리뷰의 필요성을 느끼게 되었어요.
•
실수로 인한 크로스체크 필요
•
이슈 발생 시 잦아지는 불필요한 커뮤니케이션을 줄이기 위해
•
코드에 대한 의심(ex. 이게 맞나? 이렇게 해도 되나? 등..)을 해소하기 위해
•
컨벤션 등 통일성을 위해
•
서비스 및 프로젝트 코드 전반에 대한 이해도를 높이기 위해
◦
서로 맡은 기능만 개발하다 보니 남의 코드를 볼 일이 별로 없었기 때문
◦
팀원 부재 시 발 빠른 대처가 가능해질 것
(2) 코드 리뷰 방법
우리는 가장 일반적인 방법으로 코드 리뷰를 진행했습니다. 한 단위의 기능/이슈가 메인 브랜치인 develop에 병합(merge)되기 직전에 코드를 검사하는 방법이에요.
1. 리뷰 요청자가 Gitlab MR(Merge Request)을 보낸다.
(이 때 리뷰어를 위해 description 란에 상세한 설명을 쓰면 더 좋은 리뷰를 받을 수 있다!)
2. 리뷰어가 리뷰하고자 하는 코드 line에 코멘트를 작성한다. (귀여운 이모지는 덤)
3. 리뷰 요청자는 코멘트 확인 후, 코드를 수정하고 재확인 요청을 한다.
4. 문제 없을 시, 리뷰어는 Approve한 뒤, merge한다.
(이 때 리뷰어를 위해 description 란에 상세한 설명을 쓰면 더 좋은 리뷰를 받을 수 있다!)
2. 리뷰어가 리뷰하고자 하는 코드 line에 코멘트를 작성한다. (귀여운 이모지는 덤)
3. 리뷰 요청자는 코멘트 확인 후, 코드를 수정하고 재확인 요청을 한다.
4. 문제 없을 시, 리뷰어는 Approve한 뒤, merge한다. 
그림 8 : MR의 changes 탭에서 코드 라인마다 코멘트를 달 수 있다.
그림 9 : 코드리뷰 후 Approve 및 merge가 완료된 모습
우리가 코드 리뷰를 할 때 중점적으로 봤던(보고자 했던) 부분은 다음과 같습니다.
•
코드에 문제가 없는가
•
기능 테스트
◦
해당 브랜치로 이동해 pull을 받은 뒤, 직접 실행시켜 봅니다.
•
우리 시스템과 맞는 코드인가 / 일관적인 아키텍쳐를 가지고 있는가
•
간결하고 이해하기 쉬운가
•
변수/class/methods 네이밍
•
다른 해결방법 제안
•
버그 가능성
•
기술적 지식이나 방법 공유
(3) 코드 리뷰 후기
처음에는 '이제 막 주니어가 된 내가 어떻게 코드 리뷰를 하지?'라는 생각에 걱정되었으나 대단한 리뷰를 하지 않아도 전반적으로 큰 도움이 되었어요. (예를 들어 수정한 기능을 확인하고 질문하는 것 만으로도 불필요한 부분이나 실수를 줄일 수 있었기 때문이죠! 훗 )
)
그림 10 : 꼭 새로운 방법을 제시하지 않아도, 질문하는 것만으로도 큰 도움이 된답니다!
정리하자면, 다음과 같은 효과를 경험했습니다.
1.
'크로스체킹'
자동으로 크로스체킹이 되다보니 전반적으로 실수가 줄었습니다. 혼자 코드를 작성/수정하다 보면, 사이드 이펙트나 엣지 케이스들을 놓칠 때가 있는데요. 최소 두 명이 코드를 검토하다 보니 이런 실수를 줄일 수 있었습니다.
나아가 크로스체킹은 기획이나 QA팀에도 좋은 영향을 주었는데요. 기획의 맹점을 찾아내어 의견을 제시해본 적도 있고, QA도 줄일 수 있었답니다!
그림 11 : 기능 크로스체크 후 기획의 맹점을 찾아낸 모습
2.
프로젝트/코드 이해도 향상
처음 코드 리뷰를 할 때는 다른 사람이 짠 코드를 해석하는 데 시간이 오래 걸렸어요. 뭐라고 코멘트를 달아야 할지 잘 모르겠고 전반적인 코드 이해도 부족했기 때문이었죠.
하지만 내가 맡지 않은 다른 부분의 코드도 보면서 차츰 프로젝트의 전반적인 코드를 파악하게 되었고 자연스레 숙련도가 높아지더라구요. (더불어 코드 리뷰 속도도 빨라졌다는 놀라운 사실..!)
또한, ‘아~ 이런 식으로도 코드를 작성하는구나’, ‘이렇게 쉬운 방법이 있었구나’와 같은 학습 효과도 있었습니다.
처음에는 시간이라는 비용이 들었지만, 그만큼 효과가 좋았다고 생각해요.
3.
코드의 퀄리티 향상
코드를 짤 때, (리뷰 당할 생각에) 내가 짠 코드를 타인의 눈으로 바라보면 어떨지를 생각하며 코드 퀄리티도 좀 더 높아지게 되었답니다. 리뷰를 잘 받고 싶어서가 아니라, 이전에 해 왔던 리뷰 경험으로 인해 좋은 코드에 대한 고민을 하게 되는 거겠죠?
아쉬웠던 점도 물론 있었는데요. 전체적으로 아쉬운 점은 항상 ‘시간’으로 귀결되었습니다.
그림 12 : 코드리뷰? 할 시간이 없어여...
프로젝트 마감 기한이 가까워질수록 코드를 리뷰하기 힘들어졌어요. 막바지에 늘어나는 요구/수정 사항과 함께 코드 리뷰는 저 멀리 가버렸고, 점점 코드 퀄리티가 떨어지는 느낌이 들었달까... 또한, 1:1 코드 리뷰의 경우 상대방의 상황에 따라(ex. 너무 바쁘다던가, 부재 등) 코드리뷰 진행 속도가 더뎌질 때도 있었죠. 이런 상황은 누구에게나 있을 수 있으니, 미리 함께 고민해보고 대안책을 마련해보면 좋을 것 같아요.
(4) 시도해 볼 만한 것
코드 리뷰를 더 효율적으로 하기 위해 시도해 보면 좋을만한 것들을 리스트로 정리해 보았습니다!
•
리뷰 요청자로서 준비 잘 하기
좋은 리뷰를 받으려면, MR의 description을 잘 써야겠다고 생각했습니다. 리뷰 받고 싶은 목록이나 변경점, 체크 리스트를 상세히 적어 리뷰어가 한눈에 볼 수 있도록 해야 하겠습니다.
그림 13 : 작은 단위의 mr이었지만, 연습 삼아 description을 자세하게 작성해 본 화면
(큰 단위일수록 상세한 설명이 필요할 것 같네요.)
•
Rule 정하기
◦
Approval Rule 설정 (승인자 지정 후, 한 명 이상이 Approve해야만 merge되도록 하기)
◦
코멘트 강조 정도를 정해 커뮤니케이션 비용 줄여보기 (코드 반영을 원하는 정도)
◦
수정 사항 중 우선순위 정하기 (어떤 것부터 반영해야 할지 혼란스러울 때 유용할 것 같아요.)
•
MR 템플릿 활용하기
MR 내용을 일관되게, 합의된 룰에 맞게 사용하기 위해 템플릿을 만들고 적용하면 좋을 것 같아요. 이건 제가 한번 시도해 봤는데요, 레포지토리 root 경로에 .gitlab 디렉토리를 만들고, .gitlab/merge_requests_template/템플릿명.md 파일에서 프로젝트나 팀에 맞는 템플릿을 만들면 됩니다!
그림 14 : 위에서 작성한대로 템플릿을 작성해 보았어요!
•
suggest changes를 통해 코드 제안하고 merge하기
suggest changes를 활용하면, 제안한 코드를 바로 merge할 수 있어요!
그림 15 : 예은님의 suggest changes
물론 장단점은 있습니다. 다른 제안을 코드에 바로 적용해 볼 수 있다는 점은 좋았지만, 해당 코드가 테스팅되지 않은 상태로 바로 merge가 될 수 있기 때문에, 무조건적인 suggest apply는 위험하겠다는 생각이 들었어요.
3. 회고 문화
회고(回顧): 지나간 일을 돌이켜 생각함. 여기서는 ‘프로젝트 단위의 회고’로 이해하면 됩니다.
프로젝트 회고란 프로젝트의 특정 생명주기 시점을 정하고, 이전시점~현재시점 사이에 있었던 일들을 리스트업하여, 좋았던 점은 발전시키고 안 좋았던 점은 개선하는 활동입니다. 회고를 통해 프로젝트를 더 잘 이끌어나갈 수 있고 협업자들도 리프레시되어 다음 단계를 준비하기에 좋아요.
사내 좌석배치 시스템인 ‘Round’ 프로젝트의 1차 마무리가 끝나고, 해당 프로젝트 서버 개발자 도윤님의 제안으로 회고를 시작하게 되었는데요, 다행히 팀 내 반응이 좋아 현재는 프로젝트마다 꾸준히 진행하고 있답니다!
그림 16 : 뚝딱뚝딱 우리의 첫 회고 페이지
•
언제 진행하는게 좋을까?
지금까지는 정확한 기준 없이 뭔가 큰 단계가 지났다 싶으면 팀장님이 회고를 제안하셨는데요. 앞으로는 프로젝트 구성원들이 회고 시점을 협의하면 좋을 것 같아요. (보통은 이터레이션 또는 릴리즈 단위로 진행하는 것 같습니다.)
•
어떻게 하면 좋을까?
팀에서 했던 회고 방식은 아래와 같습니다.
◦
회고 전에 미리 ‘좋았던 점 / 안 좋았던 점’을 컨플루언스(협업공간) 페이지에 적어 놓기.
그림 17 : 게임 제작 플랫폼 MOD 프로젝트를 맡은 팀원 기혁님의 회고 中 좋았던 점
◦
프로젝트 구성원들이 차례로 체크인(프로젝트에 대한 나의 감정 혹은 점수 부여)한 뒤 발표
◦
위의 내용을 토대로 Action item 도출
◦
프로젝트에 구성원 외의 팀원도 참석 가능
그 외에 다른 회고 방식들을 찾아보았는데요, 전체적인 틀은 비슷한 것 같습니다.
1.
KPT 방식
•
KEEP(계속 유지되어야할 것) / PROBLEM(문제점) / TRY(해결을 위해 시도할 것)
•
K → P → T 순서로 진행 후, 최종적으로 Action item 도출
2.
타임라인 리뷰
•
프로젝트의 흐름을 따라 회고 진행
•
발생 이슈에 따라 좋았던 점 / 안 좋았던 점 정리
•
최종 Action item 도출
3.
4Ls
•
Liked(좋았던 점) / Learned(배운 점) / Lacked(부족한 점) / Longed for(바라는 점)
•
최종 Action item 도출
•
돌아보기
<집중을 했나? 재미있었던 회고였나?>
처음에는 신선하고 재미있었지만, 매번 같은 방식으로 회고를 진행하다 보니 지루하다는 느낌을 받았어요. 쉬는 시간을 가지거나, 게임으로 분위기를 푼 다음 진행하는 등 다음 번에는 새로운 단계를 추가하거나 아예 다른 방식으로 회고를 진행해 보면 좋을 것 같습니다.
쉬는 시간을 가지거나, 게임으로 분위기를 푼 다음 진행하는 등 다음 번에는 새로운 단계를 추가하거나 아예 다른 방식으로 회고를 진행해 보면 좋을 것 같습니다.그리고 전사 재택근무 시기에는 온라인으로 회고를 진행했는데요. 팀원들의 반응을 보기 어려웠고 조금은 딱딱하다는 느낌을 받았습니다. 오프라인으로 하면 더 좋겠지만, 전사 재택근무와 같은 특수한 상황에서는 좀 더 신경 써서 준비하면 효과가 좋을 것 같아요! 우선 카메라를 꼭 켜서 서로의 반응을 확인할 수 있으면 좋겠고 컨플루언스 페이지가 아닌 Google jamboard와 같은 툴을 사용해보는 것도 좋을 것 같아요.
그림 18 : 예시로 작성해본 Google jamboard (온라인에서도 오프라인 효과를 낼 수 있어요!)
<Action item 도출 과정이 충분했나?>
회고에 익숙하지 않다보니 ‘그러면 Action item은 어떻게 정해야하지?’라는 생각을 했던 것 같아요. 그래서 저는 팀원들의 생각을 그룹핑하고 의사결정하는 과정을 개선해 보면 좋겠다고 생각했어요. 기존에는 팀원 각자가 컨플루언스 페이지에 의견을 작성했기 때문에 한눈에 의견을 그룹핑하기 어려웠는데 다음에는 포스트잇으로 item들을 가시화시키면 좋을 것 같아요. 그런 다음 dot voting(의사결정을 위한 투표)을 하면 Action item을 도출하는 것이 훨씬 수월해질 것 같아요.
<이후 어떤 변화가 있었나?>
회고를 진행하고 개선점을 이야기했지만 회고가 끝난 뒤 우리가 놓친 부분이 있었어요. 바로 이후 문제점들이 개선되었는지 추적하지 않았다는 것이에요. (사실 오래된 회고의 Action item이 뭔지도 기억나지 않아요..) 이 부분은 ‘프로젝트 개선’이라는 회고의 목적을 위해 꼭 지켜졌으면 하는 바람입니다.
이 부분은 ‘프로젝트 개선’이라는 회고의 목적을 위해 꼭 지켜졌으면 하는 바람입니다.트래킹을 잘 하기 위해서는 Action item을 정한 뒤, 세부사항을 작성하는 것이 중요할 것 같아요. (그래야 잘 지켜졌는지 체크하기 수월하겠죠?) 이후 이슈 트래커 등에 이슈를 만들어 꾸준히 체크하면 좋을 것 같아요. 그리고 주간회의 때도 팀에 공유해 주어야 한다는 사실!
<좋은 회고였는가?>
더 나은 회고를 위해서는 회고가 끝난 뒤, ‘회고의 회고’를 하면 좋습니다. 종이에 간단히 좋았던 점, 아쉬웠던 점을 작성하여 공유하면 되니 간단하죠?
나가며
이렇게 글을 쓰고 보니, 지난 9개월 동안 프론트웹개발팀에서 다양한 개발 문화를 겪으며 고민해보았던 시간들이 값지게 느껴집니다. 코딩 컨벤션, 코드 리뷰, 회고 문화와 같은 문화들은 필수적이지는 않지만 협업을 용이하게 해 주는 도구들이에요. 정착되기까지 시행착오와 어려움이 있었지만 이 또한 팀이 성장해 나가는 과정이라고 생각해요. 앞으로도 우리 팀에 도움이 되는 다양한 시도들을 해보고 팀과 잘 맞는 방법을 찾아나갔으면 좋겠습니다!
코딩 컨벤션, 코드 리뷰, 회고 문화와 같은 문화들은 필수적이지는 않지만 협업을 용이하게 해 주는 도구들이에요. 정착되기까지 시행착오와 어려움이 있었지만 이 또한 팀이 성장해 나가는 과정이라고 생각해요. 앞으로도 우리 팀에 도움이 되는 다양한 시도들을 해보고 팀과 잘 맞는 방법을 찾아나갔으면 좋겠습니다! 
테크블로그 문의 devrel@nexon.co.kr