엔지니어링 문화를 만들 때 중요한 3가지

오늘은 제가 소프트웨어 엔지니어팀 문화를 만들면서 배웠던, 제가 생각하는 가장 중요한 3가지를 공유하고자 합니다. 이 글이 이제 막 개발팀 시니어나, 팀장이 되는 분들에게 도움이 되면 좋겠습니다.

저는 대략 3번정도 엔지니어링 팀을 이끌면서 다양한 시도를 해왔다고 생각합니다(?)
엄청나게 빡세게 코드리뷰를 하기도하고, 비자아적 프로그래밍을 추구해보자고 하면서 코드 비판을 감정 없이(?) 주고받은 적도 있습니다.(그리고 감정이 상했죠..하하하)

그러한 시행착오 끝에 찾은 저에게 적합한 “엔지니어링 문화를 만들 때 중요한 3가지” 를 이야기해 보고자 합니다.

가독성이 최우선입니다.

전 팀으로 일할 때 소프트웨어 엔지니어로써 다른 소프트웨어 엔지니어와 코드로 커뮤니케이션한다고 생각합니다. 다른 작업자의 코드를 적극적으로 읽고, 이해하고, 내가 쓴 코드를 다른 사람이 이해할 수 있게 해야 한다고 말이죠.

그래서 팀으로 일하는 엔지니어링에선, 코드의 가독성을 제일 중요시 합니다.
가독성이 좋다 라는 것은 간단하게 말하면 “다른 사람이 코드를 읽고 이해하는데 드는 시간을 최소화 하는 것” 이고, 이를 기저로 두면 많은 부분이 해결될 때가 많습니다.

대표적으로 코드 리뷰가 있습니다. 여러 가지 방법의 코드 리뷰를 시도해 보았지만, 저에게 가장 성과가 좋았던 건 코드 리뷰를 가독성을 극대화하기 위한 도구로 사용했을 때입니다.

가독성을 위한 코드 리뷰는 코드로 설명되지 않는 것들이나 한 번에 와닿지 않는 변수명 등에 대한 리뷰를 통해 본인의 가독성을 늘리는 작업입니다. 동시에 리뷰어로써, “이 코드가 이해가 되지 않는데요"라고 조금 더 편하게 이야기할 수 있게 됩니다.

(이 방향으로 가다 보면 더 좋은 코드를 가독성 있게 제안할 수도 있게 됩니다.)

성역은 존재하지 않습니다.

만약에 여러분이 함께 일하고 있다면, 코드에는 성역은 존재하지 않아야 합니다.
코드의 시작부터 코드의 끝까지 수정해도 됩니다.

제가 의미하는 수정은 무분별한 수정을 의미하는건 아닙니다.
이유가 있다면, 누구든 수정할 수 있어야 함을 의미합니다.

간혹, “성역” 이라고 불리는 코드들이 있습니다. 그런 코드를 수정을 하면 원작자가 달려와서 내 의도와 다르게 작성하셨다. 혹은 코드를 왜 수정하셨냐 라는 이야기를 하곤 합니다.

저는 그럴 때, 수정하는 사람의 편을 들어주는 편입니다.
이유를 가지고 코드를 수정하는 사람에게 본인의 의도를 설명하지 말고, 의도를 가독성있게 구성해야 한다고 말합니다. (코드로 본인의 의도를 표현하기 어렵다면, 주석은 좋은 방법 중 하나입니다.)

좋은 의도가 항상 좋은 결과를 내지 않습니다.

어떠한 의도를 가지고 있었건, 결과적으로 좋지 않을 수 있습니다.
‘아 이제 여기서 이렇게 확장하고, 저렇게 확장하고, 리팩토링 조금만 하면 되요’

그런 코드는 성역이 되기 쉽습니다. 그리고 확장되지 않고, 리팩토링 되지 않는 경우가 있습니다. 코드의 성역을 만들어선 안됩니다. 좋은 결과를 내는데 있어 본인의 의도보단 팀의 결과를 더 생각하는게 중요합니다.

그리고 생각보다 리더는 이런 성역 코드를 만들기 쉽습니다. 그래서 일단 팀원들에게 지적을 받는 연습을 해야 합니다. 리더가 짠 코드에 의도를 가장 먼저 설명하고, 코드를 지적할 수 있는 환경을 만드는 게 중요합니다.

퀄리티 = 실력

사실 위에 2개의 중요성은 퀄리티와 실력이 기반이 되지 않으면 쉽게 망가지는 것들입니다.
가독성만을 중요시하니까, 실력적으로 이해가 되지 않는 부분을 지적하는 경우를 본적이 있습니다.

예를 들면, 정수형 n을 4로 나눈다고 하면, n/4, n*0.25, n>>2 와 같은 다양한 구현 방식이 있는데, 마지막 코드인 n>>2는 좋은 코드이면서 가독성도 나쁘지 않은 코드입니다.

실제로 제가 본 예는 이를 지적하는 케이스였습니다.
반대로, 실력이 너무 뛰어나서 그냥 읽어버리는 경우도 있습니다.

예를 들면, 게임 캐릭터가 바닥에 있다라고 할때 불형 OnGround 와 같은 변수를 활용합니다.
그래서 if(OnGround) 라는 표현을 쓰는데 어떤분이 if(!NotOnGround) 라는 코드를 썼고,
이를 리뷰했던 리뷰어는 실력이 너무 뛰어난 나머지(?), 그냥 넘어간적이 있습니다.

그래서, 이런 코드의 퀄리티의 기준을 리더가 잡아야 합니다. 때문에 리더는 최소한 가독성 부분에서 가장 많이 노력해야 합니다.

저는 팀을 이끌때 정말 유능한 개발자도 많이 봤고, 함께 일을 해봤는데 공통적인건 “퀄리티 = 실력” 이라는 점입니다. 비개발직군이 함께 일하고 싶은 엔지니어가 있고, 조금 꺼려지는 엔지니어들이 있습니다. 여기에는 퀄리티가 기반이 되는 경우가 대부분이였습니다.

무언가를 개발을 해줬는데 이것저것 챙겨야 하고, 퀄리티가 나사가 하나씩 빠진듯 2%씩 부족하면 실력이 부족한게 맞습니다. 아무리 알고리즘을 잘하고, 프로그래밍 언어를 많이 알아도, 퀄리티를 꼼꼼하게 채우지 못한다면 그것은 실력이라고 할 수 없습니다.

정말 유능하고 실력 있는 개발자와 함께 한다는건, 퀄리티를 매번 검수받거나 리뷰 받지 않아도 되는 상황을 의미합니다. 본인이 만들어내는 퀄리티(=실력)이며, 본인이 생각하기에 퀄리티가 부족하다고 판단이 들면 동료에게 도움을 청하거나, 함께 작업하는 사람들에게 조언을 받는게 중요합니다.

리더의 역할 또한 그런 퀄리티를 챙기는 역할을 해야합니다. 그런 팀원을 방치하는게 아니라, 반복되는 실수를 피드백하고 퀄리티적으로 부족한 부분을 체크해서 이야기해주어야 합니다.

아마도 이 세가지 이외에도 엔지니어링팀으로써 중요시 해야하는 것들이 수없이 많이 떠오르실 수 있습니다. 동시에 저와 다른 리딩방식을 갖고 계시는 분도 있을 거라 생각합니다.

개인적으로 다른 엔지니어링 리더분들의 생각도 들어보고 싶습니다 :) 편하게 공유해주세요!