거버넌스(Governance)란 원문 그대로 해석하면 통치, 관리; 통치 방식 이라는 뜻이다.
IT용어로 해석하자면 시스템을 개발하는 조직의 구조나 프로세스를 의미한다.
표준 프로세스와 가이드를 기반으로 전체 팀을 운용하는 모델을
중앙 집중형 거버넌스 모델 이라고 하는데
일반적으로 표준개발팀과 서비스개발팀이 나뉘어져 있는 형태이다.
이 경우 전체 시스템이 같은 프로세스와 기술을 가지고 개발되기 때문에
소프트웨어 관리가 쉽고 각 서비스 개발팀은 사용자 중심 로직 개발에만 집중하면 되기 때문에
신규 서비스 구현도 비교적 빠르게 수행할 수 있다.
하지만 오픈소스의 발달로 선택 가능한 기술들이 많고
각 요구사항에 따라 최적화된 기술을 사용하는 것이 좋은 경우가 더 많다.
중앙 집중형 거버넌스 모델에서 이를 적용하려면 새로운 표준을 추가하고
이에 따라 모든 개발팀을 교육시켜야 하기 때문에 기술적용의 민첩성이 떨어지게 된다.
무엇보다 큰 문제는 제공되는 표준 프레임워크만으로 로직 개발에만 집중하는
서비스 개발팀의 경우 매너리즘에 빠지기 쉽다는 것인데
항상 자기 발전에 목메어 있는 개발자들의 특성상 이는 곧 인력이탈로 이어질 수 있다.
실제로 연구소가 있고 이를 통해 중앙 집중형 거버넌스 모델을 사용하는
B2B 솔루션 기업에 재직했던 적이 있었다.
연구소는 자사 근무인 반면 서비스 개발팀은 연구소에서 제공하는 프레임워크를 기반으로
고객사에 파견되어 솔루션을 커스터마이징 구축하는 업무가 대부분 이었는데
해당 기업에서는 이러한 자체프레임워크를 통한 솔루션 제공을 장점으로 내세우는 기업이었다.
하지만 이런 환경 때문에 연구소 인력들은 만족도가 굉장히 높았던 반면
서비스 개발팀 인력들의 경우 불만이 많았는데
실제로 성과 측면에서도 코어기능을 제공하는 연구소가 더 많은 인정을 받기도 했고
이에 따라 더 좋은 기업으로 이직할 기회도 더 많이 주어졌다.
이렇다보니 서비스 개발팀에서는 실무자로서 가장 많은 역할을 수행해야 할 대리급 들의
재직기간이 길어야 2년 이었고 내가 퇴사한 뒤에 이전 후배한테 들은 이야기로는
신입과 차장급 이상 인력만 많아서 관리자 한명을 끼고 신입들끼리 프로젝트하는 경우가
더 경우가 많고 이는 곧 프로젝트 일정 지연과 장애접수로 이어진다고 했다.
이러한 문제점을 해결하는 거버넌스 모델이 분산형 거버넌스 모델이다.
이는 각 팀에 독립적인 프로세스와 기술 선택 권한을 주는 모델로
각 서비스가 표준 API로 기능을 바깥으로 노출할 뿐 내부적인 구현은 추상화 되어 가능한 사상이다.
하지만 분산형 거버넌스 모델을 적용할때에도 간과하지 말아야 할
중요한 개념이 있는데 Alignment 라는 개념이다.
개개인도 그렇듯 팀끼리도 중요하게 생각하는 관심사는 각각 다를 수 있고
이에 특정 팀에서는 상식이라고 여겨지는 것들이 다른 팀에서는 그렇지 않은 경우가 있다.
이에 팀마다 개발속도가 다르고 품질에도 심각한 문제가 생길 수 있는데
이를 위해 전체 팀의 능력을 일정 수준 이상으로 끌어올리고 최소한의 공통 프로세스에 대해서는
서로 맞춰놓을 필요가 있다. 이게 바로 Alignment 의 개념이다.
전체 팀의 능력을 일정 수준으로 끌어올리기 위한 방법 중에
프레임워크를 만들어서 제공하고 싶은 유혹은 잘 뿌리쳐야 한다.
완성된 프레임워크는 또 다른 강결합을 만들어내므로
차라리 프레임워크를 만들 수 있는 방법이나 지식을 공유하는 편이 더 낫다.
그리고 최소한의 공통 프로세스에 대해서도 생각보다 상세하게 안내되고 관리되어야 한다.
그것을 활용하는 것이 어렵거나 제대로 동작하지 않는다면 곧 활용되지 못할 것이고
사용되지 않는 표준은 없느니만 못하다.
끝으로 분산형 거버넌스 모델 을 잘못 해석하면 팀에게 무조건적인 자유만 부여되는 것으로 착각해서
담당하는 서비스를 독자적으로만 이끌어가려는 형태가 될 수 있는데 이렇게 되면
전체 시스템의 아키텍처를 망쳐 버릴 수 있다.
제대로된 해석은 아래와 같다.
우리는 전체 팀이 나가야할 방향과 비즈니스 벨류
그리고 팀 간의 커뮤니케이션이나 전체 시스템 구조에 대해 이해하고 있다.
이를 바탕으로 조금 더 빠른 개발과 효율성을 위한 모든 역할을 가진 팀을 운영하고자 한다.
분산형 거버넌스 모델 을 위해서 몇가지 고려해야 할 부분들이 있는데
여기에서는 개발팀만 기준으로 살펴보도록 한다.
1. DevOps
기술에 대한 독립성을 가지려면 구현뿐만 아니라
운영 또한 직접 할 수 있는 능력을 갖춰야 하기 때문에
개발과 운영을 함께 진행하는 DevOps 모델도 함께 적용되어야 한다.
다만 이는 충분한 준비가 되어 있지 않은 상태에서 도입하게 되면
운영상 많은 장애를 유발하기 때문에 팀의 성숙도에 따라 심각하게 고민하고
만약 성숙도가 부족하다면 팀의 성숙도를 높히는 것이 우선이다.
2. 상품(Product ) 중심 개발
분산형 거버넌스 모델에서는 팀별로 다른 형태의 표준과 프로세스가 존재하기 때문에
가능하면 팀원들은 계속해서 해당 서비스 개발에 집중할 수 있게 해줘야 한다.
팀은 서비스에 대한 책임을 지고 요구사항 정의 발굴부터 개발 및 운영을 책임져야 하고
해당 서비스를 개선해 나가는 활동까지 지속해야 한다.
3. MSA 적용
각 팀이 개발부터 운영 그리고 서비스 개선까지 진행해야 하기 때문에
각 팀은 제한된 책임만 담당해야 하고 이때 고려할 수 있는 것이 MSA이다.
마이크로서비스는 느슨히 결합된 작은 분산서비스로 MSA에서는 어플리케이션의 기능을 분리하고
완전히 상호 독립적인 상태가 되어야 한다.
이는 간단하게 말하면 기존의 의존성 라이브러리 위주의 개발을 지양해야 함을 뜻한다.
MSA는 몇가지 기본원칙에 기반을 두며 서비스 소비자와 제공자 사이의 데이터 교환을 위해
소스상 결합이 없는 HTTP와 JSON 같은 경량 통신 프로토콜을 사용한다.
참고서적
대용량 아키텍처와 성능 튜닝 - 조대협
스프링 마이크로서비스 코딩 공작소 - 존 카넬 지음 | 정성권 옮김