사람들은 흔히 시스템 설계 품질은 설계자의 기술적인 역량에 의해 결정된다고 믿습니다. 세상의 많은 책과 교육들이 그것을 다루고 있으며 실제로 사실이기도 합니다. 그러나 현실에서 프로젝트가 진행되는 것을 진지하게 관찰해보면 설계자의 기술 역량은 조직 내에 숨겨져 있는 다른 무언가에 의해 제한되는 것을 관찰할 수 있습니다.

1. 소통이 시스템을 망친다

해외 기업과 협력해 제품 개발을 한 적이 있습니다. 그런데 프로젝트 초기 단계부터 그들과 소통이 삐걱되기 시작했습니다. 우리의 중요한 설계 결정 사항들이 그들에게 의존하고 있었는데 메일로 질문을 하면 답이 잘 오지 않았고, 기술적으로 애매한 영역에 대해 질문하면 합리적인 이유 없이 안된다는 답변이 돌아왔습니다. 그로 인해 우리는 몇 가지 중요한 주제에서 제품 설계를 결정하기 어려운 상황에 놓였고, 어쩔 수 없이 시스템을 매우 보수적으로 설계하기 시작했습니다. 중요한 설계 결정에서 그들이 기능을 제공하지 않을 수 있다는 가정을 가지고 설계를 했고, 그들이 제공하기로 한 중요한 기능의 스펙은 제안 단계에 가볍게 정의했던 최소한의 수준으로 제약했습니다. 이후에 기적 같이 제품이 완성되었고 실제 운영도 하게 되었는데, 후에 본 그들의 시스템은 훨씬 많은 일을 하고 있었고 제품 스펙도 기대 이상으로 좋았습니다. 하지만 그런 정보를 설계 단계에 제공 받지 못한 우리는 그들이 이미 하고 있는 일을 이중으로 구현했고, 실제로 훨씬 오랜 시간 운영 가능했지만 거의 1/6 수준의 스펙으로 운영할 수 있게 모든 관련 설계가 제한되어 버렸습니다.

2. 사회적 역량

시스템 설계자는 하얀 도화지 위에 시스템을 그린다고 믿지만, 사실은 조직 내 구성원들 간에 소통 경로라는 좁은 길을 따라 펜을 움직일 수밖에 없습니다. 우리는 시스템을 설계할 때 한 개인이 모든 것을 통제할 수 없는 시스템의 경계를 마주하게 되는데, 이 경계에서는 혼자서 무엇이든 결정할 수 없고 반드시 인접한 구성원과의 소통을 통해 의사결정을 내려야 합니다. 조직 내 수 많은 경계에서 원활한 소통이 일어나고 이를 통해 제품 개발에 필요한 정보 교환과 결정들이 원활히 이루어질 때 우리는 그 조직의 사회적 역량이 높다고 말합니다. 사람들은 흔히 이 사회적 역량이 좋은 설계에 영향을 미치는 중요한 요소임을 간과합니다. 하지만 조직의 사회적 역량은 조용하지만 강력하게 시스템 설계에 영향을 미칩니다. 조직 내 수 많은 소통 채널에서 이루어지는 모든 기술적 의사결정들의 합이 곧 시스템의 설계 품질로 이어지기 때문입니다.

3. 조직의 특징들

사회적 역량이 낮은 조직에서는 몇 가지 공통된 특징들이 나타납니다. 이런 특징들은 사람들 사이에 대화의 장벽을 만들고, 사람들이 불편한 대화보다는 “그냥 내 선에서 적당하게 처리하자”는 선택을 하게 만듭니다. 결국 시스템은 파편화되고 기형적인 해결책들로 서서히 망가져 가게 됩니다. 제가 지난 커리어 기간 동안 관찰한 몇 가지 특징들을 정리해 봅니다. 혹 우리 조직에 이런 모습이 만연해 있지 않은지 돌아볼 수 있으면 좋겠습니다.

나만 좋으면 돼

소통이 안되는 조직에는 자신의 편의만을 우선시하는 문화가 만연해 있습니다. 이런 조직에서 소통은 '나의 일을 남에게 떠넘기기 위한 논쟁'으로 변질되곤 합니다. 내가 구현하기 힘든 기능을 인접한 다른 파트로 미루거나, 타 파트에 미칠 영향을 고려하지 않고 자기 파트에 유리한 쪽으로 설계 변경을 단행합니다. 이러한 자기중심적 소통은 인터페이스의 일관성을 해치고 전체 시스템의 안정성을 위협합니다. 한때 배달의 민족이라는 회사에 걸려있는 문구로 유명했는데, 조직을 구성하는 우리는 타인의 입장을 생각하는 마음의 중심을 가질 수 있어야 합니다. (우아안 기술블로그 참고)

근거 없는 대화

조직이 함께 문제를 해결하기 위해서는 필연적으로 서로에게 문제를 설명하고 해결책을 설득하는 과정을 거쳐야 합니다. 이때 설명하는 측은 상대방이 이해할 수 있는 합리적인 근거를 가지고 설명할 수 있어야 합니다. 이것은 말하는 사람의 기술적 역량과 말하는 커뮤니케이션 역량 모두를 요구합니다. 듣는 사람 역시 상대의 설명을 이해할 수 있는 기술적 배경과 듣는 커뮤니케이션 역량을 함께 가지고 있어야 합니다. 말하는 사람과 듣는 사람 모두 기술과 커뮤니케이션 역량 어느것 하나 빠지면 소통이 어려워집니다. 소통이 잘되는 조직의 구성원들은 기술적인 성숙도와 커뮤니케이션 능력을 두루 가지고 합리적인 대화를 이끌어 갑니다.

배타적 태도

어떤 문제에 대해 함께 문제를 해결하려는 태도는 소통의 기본이 됩니다. 네 쪽에서 드러난 문제는 너 혼자 해결하고 내 쪽에서 드러난 문제는 나 혼자 해결한다는 식의 배타적인 태도는 균형잡힌 최선의 해결책을 찾는데 걸림돌이 됩니다. 시스템은 유기적으로 동작하기에 함께 대안을 생각할 때 최적의 해답이 나올 수 있습니다.

지나친 의존관계

반대로 소통이 필요 이상으로 일어나는 경우에도 조직의 사회적 역량을 떨어뜨리는 이유가 됩니다. 앞서 소개한 배타적인 태도와는 반대되는 상황인데, 문제 해결 과정에서 문제 원인이나 해결책이 어느 정도 식별되고 나면 그 다음부터는 문제가 드러난 파트에서 문제 해결을 전담하면 됩니다. 그런데 아직 성숙되지 못한 초기 조직은 시스템이 잘 나누어져 있지 않아 파트 간에 강한 의존관계를 가지고 있는 경우가 많습니다. 그래서 특정 파트의 개발과 시험을 위해서 다른 파트 엔지니어가 계속 지원을 해주어야 하는 경우가 생기고, 지원하는 쪽에서는 자신의 파트를 설계하고 개발하는데 써야할 시간을 상당 부분 빼앗기게 됩니다. 이런 현상이 지나치게 자주 나타나면 이제 시스템의 각 파트가 독립적으로 개발하고 시험할 수 있게 시스템을 고도화 해야할 때라는 신호입니다. 조직과 설계자가 이 신호를 무시한다면 지원하는 파트에서 개발에 필요한 충분한 시간을 사용하지 못하게 되고 궁극적으로 시스템에 좋지 않은 영향을 미치게 됩니다.

문맥에서 벗어난 의견

때때로 사람들은 자기에게 주어진 역할을 넘어 다른 사람의 일에 지나치게 참여하고자 하는 경우가 있습니다. 다른 사람의 문제 해결을 함께 고민하고 결과에 대한 리뷰 의견을 주는 것은 분명 좋은 것인데, 어떤 경우 이런 행동은 일을 주도하는 조직을 방해합니다. 이것 역시 잘못된 방향의 소통이라 할 수 있습니다. 일이 방해되도록 의견을 주는지, 일의 도움이 되도록 의견을 주는지 판단할 수 있는 좋은 기준이 한 가지가 있습니다. 일에 방해가 되도록 의견을 주는 사람은 일을 주도하는 팀의 문맥을 알지 못하고 단편적인 현상만 보고 자기 의견을 냅니다. 예를들면 엔지니어는 바꿀 수 없는 이런 저런 악조건 속에서 최선의 선택을 한 것인데, 악조건에 대해서는 알지 못하면서 최선의 선택이 왜 최고가 아닌지 피드백을 주는 경우가 있습니다. 엔지니어들끼리 불편한 의견을 나누고 치열하게 토론하는 것은 좋은 일이지만 일을 주도하는 조직의 문맥을 알지 못하고 이런저런 의견을 내는 것은 팀에 도움이 되지 않습니다. 어떤 일에 함께 참여하길 원한다면 나의 의견을 말하기 전에 상대의 문맥을 이해하는데 먼저 시간을 써야합니다. 소통이 잘되는 조직은 활발한 의견이 오가기 전에 상대의 문맥을 이해하는 조용한 시간에 충분한 시간을 할애합니다.

바꿀 수 없어

대화를 통해 좋은 해결책이 도출되더라도 이를 시스템에 적용할 수 없다면 소통은 무의미한 에너지 소모가 됩니다. 수주 사업처럼 계약 범위에 묶여 좋은 아이디어가 있어도 시스템에 적용할 수 없거나, 이미 구축된 부실한 서브 시스템이 '변경 불가'라는 성역이 되어버린 경우가 대표적 경우입니다. 이러한 경직성은 설계자가 더 나은 구조를 제안할 의지를 꺾고, 시스템이 나쁜 구조 위에서 계속 비대해지도록 방치합니다.

느린 응답

소통의 '골든 타임'을 놓치는 것도 큰 장애 요소입니다. 담당자들이 너무 많은 프로젝트에 참여하고 있어 요청에 대해 시기적절하게 응답하지 못하면, 무한정 기다릴 수 없는 상대 팀은 임의의 가정을 가지고 개발을 진행하기도 합니다. 이러한 응답의 지연은 문제가 뒤 늦게 발견되게 하고 이후에 수정 비용을 기하급수적으로 높이는 원인이 됩니다. 조직이 시기적절하게 문제를 함께 논의하고 응답할 수 있도록 일의 양이나 동시성을 제어하는 것도 좋은 소통 채널을 만들기 위한 중요 요소가 됩니다.

휘발되는 소통

소통이 안 되는 조직의 또 다른 특징 중 하나는 "말로만 하고 끝나는 것"입니다. 메신저나 말로 나눈 대화는 시간이 지나면 각자의 기억 속에서 다르게 해석되거나 소멸됩니다. 문서화된 합의점이 없기에 과거의 논의를 반복하거나, 서로 다른 이해를 가진 채 개발을 진행하다가 통합 단계에서 예상치 못한 이해 충돌을 맞닥드리기도 합니다. 정리되어 기록되지 않는 소통은 조직의 지식을 축적하지 못하게 하고 아키텍처의 근거를 모호하게 만듭니다. 좋은 소통 채널에서의 소통은 잘 정리되고 기록됩니다. 경험에 의하면 회의에서 모두가 동의한 것 같아도 문서로 다시 정리한 내용을 읽어보면 몇 가지 사실을 다르게 이해한 경우가 많았던 것 같습니다.

4. 맺으며

시스템 설계는 기술이라는 도구로 조직의 소통을 기록하는 행위로 표현될 수 있습니다. 소통의 실패는 시스템에 지울 수 없는 비효율의 흔적을 남깁니다. 따라서 좋은 시스템 설계를 원하는 조직이라면 이제 기술문서와 코드를 들여다 보는 것을 넘어 조직 내 소통 그래프를 들여다 보아야 합니다. 원하는 시스템의 모습대로 조직의 소통 채널을 건강하게 유지하는 것이 최선의 설계를 완성하는 시작이 될 것입니다.