개발 팀 협업에 중요한 2가지

프로그래밍 공부를 처음 시작 이후로 현재까지 현업에서 많은 시간이 보내오면서 그 동안을 회상해보면 혼자 일하는 경우가 많지 않다는 사실을 깨닫게 된다. 많은 개발 현업자들이 공감할 것이라고 생각한다. 그러다 보니 협업을 잘하는 사람이 어떻게 보면 일을 잘하는 사람이 되기도 한다. 협업 관계에서 "1+1 = 2"가 아니라 2 이상의 역량 및 결과를 도출하게 하는 것이 리더의 역할이지만 한편으로 개개인이 전체적으로 마이너스가 될 요인을 만들지 않는 것도 매우 중요하다. 

무엇보다도 협업 관계에서 제일 중요한 것은 신뢰와 배려라고 생각한다. 상호 간 신뢰가 있다면 오해도 쉽게 풀리고 협업 관계에서 발전적인 방향의 토론이 잘 되겠지만 뭔가 이상하다는 생각이 든다면 신뢰가 없거나 배려가 없는 경우가 대부분이라고 생각한다. 개인적인 경험을 토대로 한 번쯤 고민해보면 좋을만한 상황을 각색해서 적어보려 한다. 

"나는 무진장 코드를 개선하고 싶다" 

일단 소제목을 이렇게 붙여봤는데 개발에 익숙해지고 자신감이 붙으면서 종종 찾아볼 수 있다. 협업보다 자신의 코드 표출이 먼저인 개발자라고 말할 수 있다. 협업이 중요하지 않다고 말하는 사람은 단 한 명도 없다. 하지만 행동이나 결과가 어떠한지를 보면 그 사람의 가치관을 엿볼 수 있다. 서론이 길었는데 예시를 위해 가상의 개발자 A를 소개해보려고 한다.

개발자 A는 리팩토링 책도 보았고 디자인 패턴도 익혔으며 기존에 유지 보수하던 코드가 더 멋져지길 원하는 열망도 가지고 있다. 

어느 날 A는 API 서버 코드 중 객체 매핑을 정말 섹시하게 도와주는 오픈소스를 찾았다. A는 기존 보일러 플레이트 하게 하나하나 객체의 멤버를 값 할당하는 코드는 너무 못생겼고 생산성을 떨어뜨린다고 생각하고 있었다. A는 약 5년간 유지보수 중이던 코드에 기능 개선 건을 작업하면서 핫한 오픈소스를 반영하였다. 아무래도 생각보다 양이 좀 되는 기존 코드를 모두 고치기에는 수정 범위가 너무 커서 변경 없이 그냥 두기로 했다. 하지만 코드 리뷰 과정에서 리뷰어와 오픈소스의 장점에 대해 논의를 하다가 기존 코드를 모두 바꿀 만큼 매력적이지 못하다는 의견을 받게 되었다. 서로 평행선을 달리다가 서로 다름을 인정하고 결국 코드는 기존 방식과 신규 이렇게 2가지 방식으로 구현된 상태로 상당 기간 유지하게 된다. 

실제로 위와 같은 상황은 개발하면서 종종 만나게 된다. 사실 누군가의 생각이 틀리다고 말할 수는 없다. 다만 협업관계에서 생각해볼 것은 해당 코드는 나만의 코드가 아니라 팀이 함께 다루는 코드라는 점이다. 내가 아무리 개선의 명목 하에 멋진 것들을 도입한다 하더라도 같이 코드를 고치는 팀 사람들에게 충분한 설명을 해야 하고 동의하지 않으면 사실 반영하지 않는 게 맞다. 동의 없이 코드를 계속 변화시킨다면 결국 코드 파편화만 만들어내기 때문이다. 심지어 담당자가 바뀌어가면서 이와 같은 패턴을 계속 코드가 접하게 되면 가독성은 매우 떨어질 것이고 고치기 힘든 냄새 나는 코드로 바뀌어갈 가능성이 높다.

기존 코드를 개선할 때 대전제는 요구사항에 유연하게 대응할 수 있어야 하고 코드 가독성이 좋아야 한다고 생각한다. 물론 서비스 안정성면에서 크리티컬 한 오류가 발생하지 않는다라는 바탕 또한 있어야 한다. 한편 미래의 요구사항을 예측하긴 어렵기 때문에 문제를 최소화하는 방법은 요구사항이 들어오기 전에 개선하는 게 아니라 들어올 때 개선하는 것이다. 모든 면에서 확장하기 좋거나 유연한 판타지스러운 상황과 코드는 많지 않기 때문이다. 노련한 시니어 개발자들은 그 동안의 경험으로 적당한 수준의 확장을 고려한다.

개발자 A처럼 보일러 플레이트 코드에 집착하고 이번에 알게 된 핫한 오픈소스나 디자인 패턴을 반영한 결과가 코드 파편화라면 내가 지금 팀과 서비스를 생각하고 있는 것인지 객관적으로 고려할 필요성이 있다. 

반응형

 

"나는 사실 널 신뢰하지 않아"

이번에 가상의 개발자 B라고 가정하고 상황을 적어보면, 개발자 B는 위에서 나온 개발 A의 동료이자 리더이다. 동료 A가 작년에 작성하였고 지금 동작하고 있는 코드에서 문제가 나타났다. 기존에 작성된 기획 문서를 보니 뭔가 구현 내용이랑 달라 보인다. 아! 동료 A는 꼼꼼하지 못하군! 문제 재현이나 A와의 논의 없이 기획 문서대로 코드를 고쳐버리고 이슈를 마무리한다. B는 리더로서 팀의 개발 문화를 생각해서 기획 문서의 의도를 파악하고 그대로 잘 구현해야 한다고 슬랙 메신저로 당부의 말을 전달하였다. 

그리고 일주일 뒤 B가 고친 코드에서 새로운 문제가 나오게 되었다. 알고 보니 기획 문서가 old 버전이었고 마지막에 합의된 내용이 반영되지 않았다.

엔지니어들은 사실 문제를 객관적으로 바라봐야 하고 사람은 언제나 실수할 수 있음을 고려해야 한다. 그래서 위 사례는 그다지 문제가 아닌 것처럼 보이지만 결과적으로 코드를 고친 곳에서 새로운 문제가 또 나왔으니 재검토하고 수정해야 할 것을 생각하면 리소스 낭비를 한 셈이다. 또한 A 개발자의 사기까지 건드렸으니 꽤 안 좋은 결과라고 생각된다.

B가 A를 신뢰하지 않는 상황인지라 재현도 하지 않고 기획문서만 믿고 바로 고친 게 가장 큰 문제이다. 만약에 A를 조금이라도 신뢰했다면 코드를 고치기 전에 상황 설명을 부탁하거나 해당 이슈 검토를 함께 봐달라고 이야기하지 않았을까 싶다. 

마무리하면

나름 열심히 적었지만 상황 각색이 좀 부족했을 수 있을 거 같다. 다만 신뢰와 배려가 중요하다는 것을 이야기하고 싶었다. 뛰어난 동료들과 서로 신뢰하고 배려를 바탕으로 개발하는 팀. 거리낌 없이 개발 문화 및 기술 토론을 할 수 있는 팀. 협업이 잘되는 팀이란 이런 팀이 아닐까.