이 글에서는 제시하는 엔지니어링 팀의 "기여 모델"은 엔지니어가 내 업무 도메인보다 더 낮은 공통 엔지니어링 영역에 활발하게 기여가 이루어지기를 기대하고 이를 독려하는 팀 운영 정책이다.

기여가 잘 동작하는게 무조건 팀에 더 이득이다. 기여는 팀의 엔지니어링 역량 성장에 멀티플을 만든다. 좋은 기술 사례의 공유는 개별 엔지니어뿐 아니라 팀 모두의 엔지니어링 수준을 올린다. 공통 모듈이나 자동화에 대한 기여는 나 뿐 아니라 팀 전체의 속도를 높이고 성과를 공유한다.

나는 개발 플랫폼 엔지니어로 일하며 기여가 잘 작동하는 엔지니어링 팀을 만들기 위해 노력해야 한다. 그러나 동시에 커리어에서 기여 모델이 제대로 동작하는걸 본 적이 없다고 말한 적 있다.

돌아보면 아래 이어질 이유들 때문인데, 이것에 대해 생각해보면서 기여 모델이 잘 돌아가는 엔지니어링 팀을 만들기 위한 조건에는 무엇이 있을지 생각해봤다.

엔지니어링 플랫폼이 별로라서

유사한 코드베이스를 공유하는 엔지니어링 팀에 사람이 10명 정도가 되면, 기여 모델은 자유로운 상태로 알아서 잘 돌아가리라 믿기 힘들다. 코드 품질 유지에 있어 오너십은 매우 중요하다. 공용 영역에 있는 오너십 불분명한 코드는 엔지니어링의 안정성을 몹시 떨어트린다. 책임감있게 코드를 수정하고 그 품질을 보장해도 부족할 판에 기여란, (참 부정적인 관점이지만) 어떤 조직에서는 "내가 끝까지 책임지지 않겠다." 라는 의미일 수도 있다고 생각한다.

기여를 안전하게 실행에 옮길 수 있는 엔지니어링 플랫폼이 뒷받침되어야 한다. 이를 위해서는 사고가 발생하더라도 문제가 빠르게 격리되고, 공통 모듈에 대한 기여가 안정적으로 이루어질 수 있도록 하는 장치와 프로세스가 반드시 마련되어야 한다.

문서화, 테스트, 내보내는 인터페이스의 추적과 관리 이 3가지는 양보할 수 없는 최소다. 패키지가 내보내는(자바스크립트 모듈 세상에서는 export 되는) 모든 구현체들은 버전 관리되고 사용처가 없을 경우 폐기되어야 할 수 있어야 한다. 뭘 내보냈는지도 모르고 그저 공유만을 위해 별걸 다 내보내고 있을 경우 추후에 관리의 난이도가 지수적으로 상승한다.

내보내는 구현체들이 모두 추적되어 문서화되어 각 패키지 README에 박혀야하고 문서 쓰는걸 깜빡했으면 CI에서 터트려야한다. docusaurus같은 것으로 호스팅되어도 좋지만 문서와 코드는 가까이 있어야 한다. 그리고 모든 패키지의 테스트 커버리지는 0이 아니어야 한다.

프로세스에서 이 정도 수준을 보장해주지 못한다면 기여가 진행된 코드베이스가 문제를 빈번히 일으킬 수 있고, 엔지니어는 안전한 기여를 못 함을 알게 되므로 기여를 기대하기가 힘들어지는 악순환에 빠진다. 3년 전쯤에 오래되고 큰 코드베이스의 공용 레이어를 계속 유지하고 발전시키셨던 분이 "공용 모듈에 유닛 테스트는 꼭 많이 붙여놓으시라"는 조언을 하셨던 적이 있는데, 왜 그렇게 중요하다고 말씀하셨는지 지금 아주 잘 안다.

기여의 난이도가 높아서

기여에 따르는 책임에 과도하게 높은 경우 기여는 지극히 어려워진다. 그러면 아무도 기여를 안 한다. 어떤 공용 구현체에 기능을 붙였는데 사용처가 1000곳이 넘어서 붙어있는 모든 앱을 리그레션해야 한다면? 아무도 그 정도의 리스크를 안고 내 몫의 일과 크게 상관없는 일을 하고 싶지 않다.

여러 엔지니어들이 암묵지와 어른의 사정을 남기고, 생기고 사라지고 방치되는 기능이 가득하며, 나이테처럼 시간에 따라 결합이 선형적으로 증가하는 역동적인 코드베이스는 "소소한 기여"가 거의 불가능하다. 모든 동작이 그대로임을 증명하고 감수해야할 책임이 본인에게 놓이기 때문이다. 이런 코드베이스 위에서 기여는 작거나 크거나 한 것이 아니라 어떤 사람이 큰 맘먹고 해야하는 것이 되어 다양성을 상실한다.

종종 기술 컨퍼런스에 "작지만 소중한 이러한 코드를 공통 모듈로 만들었더니 사람들이 잘 쓰고 좋아한다." 식의 세션이 나온다. 그런 세션을 보고 있으면, 결합과 부채가 가득한 코드베이스에서는 정말 불가능한 기여겠다 - 는 생각이 절로 들 때가 있다. 다시말해 크고 작은 다양한 기여가 힘든 코드베이스에서는 소소하고 다양한 기쁨이나 효용감을 얻을 수 있는 창구도 없어진다.

기여의 난이도를 낮출 수 있어야 한다. 앞 섹션에서 말한 엔지니어링 플랫폼은 기본이고, 기여의 난이도를 더 낮추기 위해서는 적절한 수준으로 격리된 코드베이스도 필요하다. 점진적으로 적용하고 그 효과를 보이는 방식을 더 쉽게 할 수 있게 보장해야 한다. 그럴 수 있다면 작은 기여나 아이디어가 하나의 제품에서, 하나의 팀으로, 여러개의 제품으로, 여러개의 팀으로 안전하게 업그레이드되며 전파될 수 있다. 기여자의 보람도 작게 시작해 점점 커질 수 있다.

조직 문화가 기여에 친화적이지 않아서

기여의 코어는 "뭔가 도움이 되고 싶은 마음"이다. 기여자는 그렇게 생각하니까 맡지도 않은 일을 자발적으로 할 수 있다. 이 마음을 꺾어선 안 된다.

커리어 내내 "대안이 없는데 문제만 제기하는 사람"이 비판을 받는 경우를 자주 봤다. 실행이 중요한 스타트업에서 책임을 지지 않고 문제만 제기하는 것은 공허하다고 생각한다. 하지만 거기에서 그치지 않고, 기여의 의지가 있는 사람이라면 하고자 하는 것을 이루기 시작할 수 있도록 팀이 힘을 실어줄 수 있어야 한다고 생각한다. 문제를 제기하는 사람은 어떻게 해결해야 할지 몰라서 대안을 가져오지 못 했을 수도 있다.

기여가 용이하도록 하는 일에는, 기여를 쉽게 할 수 있도록 안내하고 독려하는 것도 포함이다. 팀은 잠재적 기여자가 답을 쉽게 도출할 수 있도록 좋은 도구들을 만들고 눈에 보이는 곳에 두어야 한다. 역시 기여가 쉬운 엔지니어링 플랫폼이 도움이 된다. 팀 동료들은 좋은 의논 상대가 되어야 한다.

해결은 못하고 말만 한다고 뭐라 그러면, 잠재적 기여자의 기여하고 싶은 마음을 제대로 꺾어놓는다. 그 엔지니어는 다음에 문제를 봐도 아무말도 안 하게 된다. 결국 팀의 손해다.

제품 외적으로도 그런 마음을 잘 조직해줄 수도 있다. 관심있는 주제에 대해 같이 공부를 해보는 스터디를 회사가 독려하고 지원하는 경우도 많다. 그러나 제품이나 코드 공공의 문제를 팀에서 같이 고민하고 풀기 위한 활동이 더 유익하다고 생각하는 편이다. 제품의 문제를 해결하기 위해 같이 공부하고, 작은 기여를 만들고, 더 잘 개선할 수 있게 무엇이 필요한지 사람들과 토론하고, 정보를 얻고 운영해보는 일련의 사이클이 제품 안에서 자연스럽게 만들어지면 좋겠다고 생각한다.

맺으며

섹션마다 약간씩 관점이 다르긴 하지만 플랫폼이 짱짱하면 많은 것들이 해결된다. 더 다양하고 유익한 기여가 가능하게 하기 위해 플랫폼 엔지니어는 열심히 일해야 하고, 동료 엔지니어의 기여하고자 하는 마음을 감사히 여겨 이를 복돋을 수 있는 방법을 연구해야 한다.

지금 회사 다니는 3년동안 기여가 악화되어가는 과정도 봤고, 조금씩 좋아질 기미가 생기는 순간도 있었다. 아직 성과를 보기에는 이르지만 기여에 방해가 되는 블로커들을 꽤 많이 치웠다. 앞으로 더 좋아질 여지는 많다.