안녕하세요! 인터널 팀 서버 엔지니어 인턴 월터(Walter. Lee)예요. 인터널 팀에서 당근마켓 구성원들이 더 재미있고 능률적으로 일할 수 있도록, 사내에서 사용하는 도구를 기획하고 만드는 일을 하고 있답니다.
당근마켓에서 여러 팀과 협업하다 보면 신경 써야 할 부분들이 매우 많아요. 단순히 소스 코드로 구현해야 하는 기능을 만들어내는 것 이상으로, 어떻게 하면 지속적으로 성장하는 소프트웨어를 만들어 낼 수 있는지 함께 고민해야 하는 순간들이 많거든요.
당근마켓에서는 보통 코드 리뷰를 통해 서로 작성한 소스 코드에 대해 피드백을 주고받으며 개선하는데요. 그렇다면 어떻게 해야 서로 피드백을 잘 주고받을 수 있을까요?
오늘은 여러 언어와 기술을 사용하는 당근마켓에서 코드 리뷰를 진행하기 전에 어떤 고민을 했고 또 어떻게 해결했는지 얘기해보려 해요.
여러분은 어느 출판사의 편집자이고 두 명의 작가가 함께 한 편의 에세이를 연재하는 상황을 가정해볼까요? A라는 작가는 짧은 호흡의 글을 쓰고 종결어미를 현재 읽고 계신 글처럼 해요체로 끝내기를 좋아해요. 다른 B라는 작가는 반대로 긴 호흡의 글을 쓰며 친근한 느낌을 주고 싶어 평어체를 쓰는 걸 좋아해요. 둘의 글을 인터넷에 발행하기 위해 받아 본 결과 아래와 같았어요.
파이썬은 지구의 온 개발자가 좋아하는 언어예요.
파이썬만의 특징을 일컫는 파이써닉함에 매료된 개발자들이 무척 많죠.그러나 단점도 존재하기 마련이다. 대표적으로 GIL(Global Interpreter Lock)로 인하여 멀티 스레딩 환경에서 만족스러운 성능을 내지 못해 아쉬운 평가를 받고 있다.
A가 작성한 첫 두 줄을 읽다가 B가 작성한 한 문단을 읽으니 어떠신가요? 비록 짧은 글이지만 갑작스러운 표현 방식의 차이로 인해 잘 읽히지 않아요. 이제 서로 합의한 규칙을 바탕으로 쓰인 글을 한번 살펴볼까요?
파이썬은 지구의 온 개발자가 좋아하는 언어예요. 파이썬만의 특징을 일컫는 파이써닉함에 매료된 개발자들이 무척 많죠.그러나 단점도 존재하기 마련이에요. 대표적으로 GIL(Global Interpreter Lock)로 인하여 멀티 스레딩 환경에서 만족스러운 성능을 내지 못해 아쉬운 평가를 받고 있어요.
통일성 덕분에 아까 글보다 훨씬 잘 읽혀요. 하지만 작가만의 고유한 색채가 사라졌고 글을 제출할 때마다 정해진 규칙을 잘 따랐는지 한 번 더 점검해야 하는 번거로움이 생겼어요.
이처럼 규칙은 다수의 사람이 함께 일할 때 큰 힘을 발휘하지만, 한편으로는 업무를 위한 업무를 하게 만들어요. 그렇다면 개발 영역에서 어떤 규칙을 어떻게 적용해야 서로 번거롭지 않게 일의 능률을 높일까요?
대표적으로 서식(Formatting)이 존재해요. 아까 우리는 글의 어미와 줄 바꿈처럼 보이는 형식을 바꾸어 가독성을 높였어요. 프로그래밍에서도 이처럼 보이는 형식, 다시 말해 정해진 서식을 통해 개발자끼리 통일된 모양의 소스 코드를 공유할 수 있어요.
파이썬에서는 대표적으로 파이썬 코드를 위한 스타일 가이드 — PEP8과 구글 파이썬 스타일 가이드가 있어요. 이 두 문서에는 한 줄에 최대 몇 글자의 소스 코드를 작성할 것인지부터 언제 한 줄 공백을 넣을 것인지까지 다양한 부분의 규칙이 적혀 있죠.
이미 눈치채신 분들도 계시겠지만 정해진 하나의 규칙이 있는 게 아닌 이미 유명한 두 문서가 존재하는 것부터 규칙에는 정답이 없음을 시사해요. 특히 PEP8 문서에는 도입(Introduction) 다음에 아래와 같은 문장이 작성돼있어요.
어리석은 일관성을 고집하는 건 허깨비의 좁은 마음과도 같다. A Foolish Consistency is the Hobgoblin of Little Minds
다시 말해 프로젝트 전체를 봤을 때 팀원끼리 통용할 만한 일관성을 만들고 따르는 것이 중요하지 무의미한 규칙에 시간 낭비하는 건 어리석다는 의미에요. 그래서 PEP8과 구글 문서를 참고하지만, 그보다 함께 일하는 사람과 맞춰나가는 게 훨씬 중요해요.