서로 코드도 못 읽는데 같은 팀일 필요가 있나요?
콘웨이 법칙으로 보는 우리 개발팀의 현주소는
"서로 사용하는 프로그래밍 언어도 다른데 같은 팀일 필요가 있나요?"
예전에 몸담았던 회사에서 들었던 이야기다. 그 회사는 프론트 팀과 서버 팀이 정확히 구분되어 있었다. 두 팀은 회의도 따로 하고 계획도 각각 짰다. 대신에 목적 중심 팀이 구성되어 있어 목적 중심 팀에서 주로 기능 개발을 담당했다. 다만 서버팀과 프론트팀이 각각 따로 놀다 보니, 여러 가지 소통의 문제가 생겨났다. 대표적인 예는 테스트였다. 프론트엔드 개발자가 최종 QA 및 기능 테스트를 맡게 되었는데, 백엔드의 협조를 얻기가 어려웠다. 그래서 복잡한 회원가입 테스트를 수행하기 위해 일일이 새로운 계정을 발급받아 써야 했다.(인증 제한 횟수가 초과하면 수십분을 기다려야 하는 것은 덤이다) 또한 푸시 알림 테스트도 어려워서, 실제 푸시 알림이 도착할 때까지 기다렸다 테스트를 진행하곤 했다. 그러다 결국에는 프론트 팀에서 백엔드에서 보내는 푸시 알림을 모사하여 푸시 알림을 보내는 스크립트를 짜기도 했다. 하지만 어디까지나 모방한 것이다 보니 실제 환경과는 어림도 없이 달라, 운영환경에서 오류보고시스템을 통해 에러를 보고받곤 했다.
아마 팀의 리더는 콘웨이의 법칙을 알고 있었을 것이다. 콘웨이의 법칙이란 "시스템의 구조는 해당 시스템을 설계하는 조직의 커뮤니케이션 구조를 닮는다"는 법칙이다. 그래서 프론트와 서버를 정확히 분리하는 아키텍처 구조 상, 프론트팀과 서버팀이 각각 독립적으로 존재해야 한다는 생각이었을 것이다. 그러나 문제는 두 팀을 조율해줄 사람이 한 명도 없다는 것에 있었다. 각각의 팀은 서로의 기술 스택에 대한 이해가 없었고, 운영 및 개발 이슈를 쳐내느라 급급한 서버팀은 커뮤니케이션에 대한 의지가 없었다. 실무에서 개발을 해보면 알겠지만, 프론트와 서버가 독립적으로 존재하기는 하나 서로 설계에 대한 정보를 공유해야 한다. 예를 들어, 특정 목록의 정렬을 서버에서 처리할 건지 프론트에서 처리할 건지 의사결정을 해야 하며, 특정 정보를 DB에 담을지 클라이언트의 캐시에 담을지 정해야 한다. 서버와 프론트가 통신할 수 있는 통신의 명세(API 스펙)을 함께 설계해야 하는 것도 물론이다.
그래도 각 팀이 굉장히 독립적으로 존재하면서도 대체적으로 프로젝트가 아주 크게 잘못되는 일은 없었다. 기본적으로 서버팀과 프론트팀 개발자들이 긴밀히 협력했기 때문이다. 다만 커뮤니케이션 비용이 높았다. 클라이언트-서버 개발자로 파트너를 이루어 결정한 내용이 정작 다른 프론트 개발자 및 서버 개발자에게는 전파되지 않는 일이 빈번했다. 팀 내 꼭 공유되어야 할 중요한 지식이 전파되지 못하는 것은 덤이다. 커뮤니케이션 비용은 나날이 높아져갔다. 급기야 두 팀 간의 사일로 현상이 나타나기 시작했다. 사일로 현상이란 조직의 각 부서가 서로 중요한 정보를 공유하지 않는 현상이다. 사실 우리나라 말로 이야기하면 부서 이기주의라고 하는데 나는 이 번역에 반대한다. 이기주의가 아니다. 왜냐하면 나만, 우리 부서의 이익만 생각해서 정보를 공유하지 않는 것이 아니라, 애초에 커뮤니케이션 코스트가 너무 높은 조직 분위기 및 구조 때문에 정보를 공유하려야 할 수가 없는 거다. 서로 신뢰가 형성되어 있지 않은데 어떻게 긴밀한 정보 공유가 가능할까.
다시 콘웨이 법칙으로 돌아가 보자. "서로 다른 프로그래밍 언어를 쓰니 서로 다른 팀이 되는 것이 맞지 않나요?"라는 말은 개발자가 프로그래밍 언어로 코딩만 하는 사람일 때 성립하는 말이다. 개발자는 훨씬 더 복잡하고 다양한 일을 한다. 이해관계자의 의견을 취합하여 어떤 프로그램 로직이 적절할지 선택하는 업무, 각 이해관계자를 설득하고 이해시키는 업무, 자신이 수행하고 있는 기술 프로젝트를 전체 팀원에게 설명하는 업무, 클라이언트-서버 시스템을 효율적으로 설계하는 업무, 시스템의 히스토리를 유지하는 업무 등등 개발자의 업무는 결코 로직을 프로그래밍 언어로 옮기는 작업인 "코딩"에만 국한되지 않는다. 그래서 유연한 조직구조가 필요하다. 프론트팀과 서버팀이 서로 긴밀하게 협의해야 할 기간에는 회의를 합쳐서 같이 할 수도 있는거다. 그런데 융통성 없이 조직 구조가 이렇게 짜여 있느니 항상 따로 회의를 한다고 딱딱하게 생각해버린다면 먼 길을 돌아가게 될 것이다.
당신이 개발자 또는 PM이라면 기억하자. 시스템의 구조는 해당 시스템을 설계하는 조직의 커뮤니케이션 구조를 닮는다. 최초 시스템 설계가 완벽하지 않다는 것은 누구나 안다. 설계는 반복적으로 조정된다. 따라서 조직의 커뮤니케이션 구조도 유연하게 반복적으로 조정되어야 한다.
