기능조직에서 목적 조직으로 변경 시 생각해볼 것들

나는 목적 조직으로 구성된 회사는 현 회사가 처음이었다. 현 회사에서의 경험을 바탕으로 기능 조직에서 목적 조직으로 변경 시 협업 관점에서 일하는 방식이 어떻게 달라지는 지, 기존과 다름을 느끼는 포인트들을 공유해보려고 한다. 어느 조직에서나 발생 가능한 상황이라서 ‘미리 이런 부분들에 대해 조직 내 문제 인식이나 합의가 있었다면 좋지 않았을까?’ 라는 생각이 들어서 글을 써본다.

내 배경에 대해 간단히 설명하자면, 나는 백엔드 개발자로 그 동안 기능 조직으로 구성된 회사에서 일하거나 프로젝트 단위로 임시로 팀을 꾸려서 함께 일하는 형태로만 근무를 해왔다. 지금 속해있는 팀은 해결하고자 하는 비즈니스 목표/문제를 달성/해결하고자 구성된 팀이고, 팀 내에 PO/PM, 개발자, 디자이너, BA 직군이 존재한다. 별다른 일이 없다면 이 구성으로 같이 팀을 꾸려나가게 된다. 현재 재직중인 회사는 기능 조직에서 목적 조직으로 변한지는 1년이 넘었는데, 나는 목적 조직으로의 조직 개편이 되고 얼마 되지 않아 입사했기 때문에 조직 구성이 달라짐에 따라 업무 책임과 협업 방식이 조정되는 과정을 경험했다.

기능 조직과 목적 조직

말하기 앞서 기능 조직과 목적 조직에 대해 간단히 알아본다.

기능 조직 : IT 조직 뿐만이 아니라 많은 회사에서 일반적으로 사용되는 구조로 전문 분야나 직무 기능에 따라 직원을 그룹화하여 팀을 구성한다. IT 조직의 경우 개발팀, 인프라팀, 디자인팀, QA팀 등으로 나눌 수 있다.

목적 조직 : 특정 목적을 수행 혹은 해결하기 위해 관련 직군들을 한 팀으로 구성된 형태로, 다기능 조직 또는 매트릭스 조직이라고도 부른다. 기능이나 전문 지식을 기준으로 직원을 그룹화하지 않고 특정 프로젝트나 비즈니스 목표를 기반으로 팀을 구성하는 데 중점을 둔다. 이 팀은 특정 목표나 프로젝트를 위해 함께 모인 다양한 기능 영역의 직원으로 구성된다.

목적 조직에서 생각해볼 것들

목적 조직 형태에서는 일하는 방식이 어떻게 달라졌는 지, 내가 백엔드 개발자로서 일하며 기존과 다름을 느끼는 지점들에 대해서 이야기하고자 한다. 현 회사에서의 경험 위주로 생각들을 정리해봤다.

말하기에 앞서 언급하고 싶은 것은 하나의 거대한 서비스를 여러 서비스(예를 들면 도메인 단위)로 작게 나누는 것은 유연성과 확장성을 얻고자하는 엔지니어링 측면의 결정이다. 조직의 형태와 별개로 트래픽 분산, 도메인 지식 응집화, 배포, 서비스별 적절한 아키텍쳐 구성 등을 위해 서비스를 분산하여 관리한다. 현 회사도 조직의 형태와 별개로 이미 서비스를 작게 나누었고, 그런 움직임은 현재도 진행중이다. 일부는 서비스가 분리되어 있고, 일부는 강하게 결합되어 운영되고 있다. 그러니까 조직의 구성 형태에 따라 반드시 시스템 아키텍처가 바뀌어야 하는 것은 아니라는 점을 짚고 넘어가고 싶다.

• 책임이 모호한 업무들
  • 기존 업무라도 어떤 팀이 책임을 갖는 게 더 적절한 지 논의 후 업무 이관한다(신규 업무도 마찬가지). 누구의 일도 아닐 때는 팀별 리소스에 따라 결정되기도 하는듯(근데 기능 구현을 담당하면 자연스럽게 유지보수도 맡게 된다). 모호한 영역이나 리소스 문제가 있지만 도메인별, 팀별로 적절한 업무를 분배하기 위해 각 팀에서 노력중이다.
  • 업무 단위로 책임팀 설정은 반드시 필요하다. 업무에 대한 책임팀을 지정하지 않는 경우, 각 협업팀은 기능 구현을 위한 최소한의 도메인 영역에 대한 책임을 질 뿐, 업무 기능 단위로 책임지는 팀은 존재하지 않게 된다. 이런 경우 자연스럽게 Aggregation 영역을 담당하는 곳이 책임팀이 되기 쉬운데, 업무의 책임팀 설정은 기술적 구현에 의한 게 아니라 일이 잘 되려면 어떻게 해야할 지 고려하여 설정해야한다.
  • 꼭 필요한 일이지만 리소스가 많이 들고 어느 팀의 일도 아닌 경우가 굉장히 애매하다. 전사 차원에서 반드시 필요한데 담당할 팀이 없거나 유관부서의 책임 영역이 작게 쪼개져있어서 전체를 아우르지 못하는 경우를 봤다. 어떤 결정을 내릴 때 팀 뿐만 아니라 전체 조직 혹은 일이 되게 하는 방향인지를 생각해야한다. 그리고 이것은 팀의 자율성이나 책임감에 맡기지 않고 조직 차원에서 고려해야한다.
• 이미 강하게 결합된 코드와 아키텍처
  • 여러 도메인 로직을 담고 있는 경우, 각 도메인 담당팀에 인터페이스 제작을 요청하여 Aggregation 진행 (이러면서 결합도는 낮아졌지만 내부적으로 API 요청량 증가함)
  • 특정 도메인 기능에 장애가 있을 때 연관된 업무도 정상적으로 진행되지 못하는 경우에 대응하기 위해서, 각 도메인 팀에서 도메인 단위로 별도 서비스로 분리 작업 진행 (결합도를 낮추고 시스템 안정성을 높이기 위함)
• 협업팀에 사전에 협조 요청 (각 팀별로 리소스를 관리하기 때문에 갑작스러운 요청은 협업팀의 리소스 관리를 방해하는 것임)
  • 바쁜 사람은 언제나 바쁘다. 모든 팀과 협업해야하는 특징을 가진 업무를 담당하는 팀이 있다. 현 회사를 예로 들면 인프라 관련 업무를 수행하는 SRE팀과 DBA팀 그리고 QA팀이 그렇다. 이런 팀들은 특히 리소스 관리가 중요한 이슈이므로, 급박하게 요청하지 않고되도록 미리미리 요청하도록 해야한다.
  • 그래도 긴급한 건들은 각 팀에서 빠르게 처리해준다 (서로 상부상조)
  • 하지만 정말 협업팀에서도 리소스가 없는 경우가 있음. 다른 도메인에 대한 인터페이스를 얻지 못할 때에는 일시적으로 다른 도메인 영역을 직접 쿼리하던가(이 경우 도메인 지식이 분산되고 해당 팀의 관리를 받지 못하니 추후 인터페이스 개발을 요청 필요함), 해당 팀의 저장소에 API 구현 PR을 올려서 진행함
  • 요청팀은 협업팀에게 업무 협조를 구할 때 구체적인 요구사항, 희망 일정 등에 대해 명확히 밝혀야함 (그리고 희망 일정은 희망일 뿐, 협업팀의 리소스 관리를 우선해야함)
• 팀 내에서 해결 가능한 일이라도 협업팀의 책임이라면 협조 요청
  • 단, 팀과 팀의 협업이 많은 업무의 경우 협업팀의 리소스도 고려해야하기 때문에 원하는 만큼 속도를 내지 못할 수 있다.
• 해당 팀이 책임을 갖는 영역에 한해, 팀의 기술적 의사결정은 자유로움
  • 언어/프레임워크/아키텍쳐/레파지토리(코드저장소) 별도로 운영 가능 → 이러면서 기술에 대한 자율성은 얻었지만 전체적인 코드 영향도 파악이 다소 어려워졌다고 느낌

그래서 어떻게 해야해?

조직마다 다르다. 하지만 우리는 문제를 해결하기 위해 모였고, 문제 해결을 위한 협력은 팀 내에서 이뤄질 수도 있고, 팀과 팀 간의 협업일 수도 있으며 조직 외부와의 협업일 수도 있다. 이런 이해를 바탕으로 우리 팀이, 우리 조직이, 우리 서비스가, 우리 고객이 이득을 취하려면 어떻게 해야하는 가에 대해서는 조직 내에서 이야기하고 합의를 거쳐야하는 부분이라고 생각한다.

그치만 조직 특성을 떠나서 공감할만한 사례들은 언제나 존재하기 때문에 아래에 몇 가지 경험을 공유한다.

구체적인 업무 사례들

• 인터페이스를 제공하는 팀은 명세(ex: API 문서)를 제공
  • 상황 설명 : 우리팀에서 여러 협업팀으로부터 API를 받아서 proxy처럼 동작하는 서버를 만들고 있었음. 일부 협업 담당자가 API 문서 제공하는 것은 자신의 업무가 아니기 때문에 API 스펙은 직접 코드를 파악하라고 피드백 줌.
  • 문제가 될 수 있는 부분 : 여러 팀이 연관된 프로젝트나 기능의 경우, 한 팀의 병목이 여러 팀으로 전파될 수 있음. 기능 구현을 마무리하지 않더라도, 미리 인터페이스를 약속해둔다면 각 팀은 언젠가 구현될 기능을 기대하며 병목없이 개발이 가능함. 인터페이스 명세(ex: API 문서)는 각 팀의 디펜던시를 끊고 일을 각자 병렬로 진행할 수 있게 해주는 구체적인 방법 중 하나임. 팀끼리 협업 시 어떤 식으로 진행해야 좋을 지 전혀 논의된 바가 없기 때문에 서로 이해하는 협업 방식에 차이가 존재했음.
  • 대처 방안 : 협업팀 담당자와 업무 방식에 대해 씽크를 맞췄음
• 협업팀에 협조 요청 시 "사전에, 일괄로, 구체적"으로 요청
  • 상황 설명 : 4개의 협업팀으로부터 몇십개씩의 API 제작 요청을 해두었는데, 영향도 파악에 누락된 API들이 발견되어 인지할때마다 게릴라처럼 제작 요청을 드리고 있었음
  • 문제가 될 수 있는 부분 : 협업팀에서 리소스 관리를 위해 일의 크기에 따라 담당자를 할당할텐데, 뒤늦게 요청하는 건들이 많으니 매니징에 곤란함이 발생함
  • 대처 방안 : 코드 저장소 전체를 기준으로 각잡고 다시 영향도 파악을 진행하여 누락한 API 2~30개를 찾아내어 각 팀에 일괄 요청드림
• API 제거 시 IT 조직 전체 공유
  • 상황 설명 : 기존 API를 제거하고 새로운 스펙의 API를 제공해야하는 상황임. 기존 API 제거 시 영향받는 서비스/팀을 파악해야함.
  • 문제가 될 수 있는 부분 : 특정 기간 동안의 API 액세스 로그를 확인하여 호출 이력이 없음을 확인하였지만, 인지한 기간보다 더 넓은 주기로 API가 호출될 수 있기 때문에 액세스로그 호출 이력만으로는 판단이 어려움. 그리고 각 팀에 기술적 자율성이 허용되는 만큼 언어/프레임워크/코드 저장소 등도 다르게 관리할 수 있음. 그래서 인지하고 있는 코드 저장소에서 영향도 분석을 하더라도 누락이 발생할 수 있음. 영향도 분석하는 담당자의 도메인 지식에 따라서도 누락이 발생할 수 있음.
  • 대처 방안 : IT 조직 전체가 포함된 공개 채널에 내용을 공유하여, 각 팀에서 해당 API 사용여부 검토 요청

나쁜 업무 사례

직접 경험한 것과 건너건너 들은 단편적인 이야기를 조합하여 가상의 사례를 이야기해보려고 한다.
이 가상의 사례를 통해 위에서 말한 "목적 조직에서 생각해볼 것들 - 책임이 모호한 업무들"에서 어떤 말을 하고자 하는 지 이해도가 오를 것이라 생각한다.

• 가상의 배경 설정
  • 글로벌 업무 시스템(ex: SAP, ERP, Salesforce 등)을 도입하여 내부 시스템과의 통합 필요한 상황
  • 사내 시스템과의 통합을 위해 내부에서는 다양한 도메인의 협업팀 참여
  • 글로벌 업무 시스템 구현은 외부 인력(외주사) 참여

• 업무 단위로 Owner(책임팀) 미지정으로 발생한 상황 : 각 도메인 팀은 하나의 기능을 완성하기 위한 인터페이스 제공에 집중하였고, 하나의 기능을 책임지는 Aggregation 영역을 조직 외부 시스템에서 책임지고 구현함
• 발생한 문제
  • 도메인 지식이 낮은 조직 외부 인력이 하나의 기능을 책임지는 Aggregation 영역을 구현하였기 때문에, 조직에서 원하는 요구사항대로 구현이 제대로 되지 않음 (그리고 이를 조직 내부에서 인지하는 시점이 늦음)
  • 장애 발생 시 업무별로 담당팀이 있는 게 아니기 때문에 원인 파악 및 담당자 지정이 느림
    • ex) 하나의 기능에서 장애 발생 시, 그 기능을 구성하는 비즈니스 로직 중 어느 부분에서 장애가 발생했냐에 따라 담당팀이 다르고, 외부 시스템에서는 API만 보고 담당팀이 어디인지 알 수 없음

맺으며…

목적 조직의 장점도 있다.
나같은 경우 목적조직으로 일하면서 비즈니스 이해도도 높아지고, 서비스/비즈니스를 바라보는 각 직군의 시선, 다양한 직군의 동료들이 신뢰를 바탕으로 한 협업하는 것이 즐거웠다.
하지만 대부분 기능 조직에서 근무한 경험이 많기 때문에, 기존에 일했던 것처럼 일한다면 목적 조직의 장점을 전혀 살리지 못하고 불편함만 느낄 수 있다.
조직의 형태가 어떠하든 업무를 이해하고, 어떻게 일해야 할지 생각하고, 그것들을 팀원들과 함께 맞춰나갈 수 있다면 구체적인 액션은 무엇이든 좋을 것이라 생각한다.