20. Delta의 새로운 규칙

Delta를 운영하고 사람 관리를 하면서 쌓은 경험과

조직관리, 철학, HR 등의 지식들을  6개월 간 차곡차곡 모았다. 

그리고 여느 현인들이 겪었다는 흔히 듣는 경험처럼,

독서 겸 공부 목적으로 근처 카페 가는 길에 불현듯 생각의 바람개비가 돌았고 

꽤나 그럴싸한 구조와 규칙을 세울 수 있었다.  

---

소위 마이크로 조직구조에서 영감을 받아서 큰 틀을 짰다

비록 7명이 남은 상황이었지만, 

저번 프로젝트에서 4명 단위의 팀으로 프로젝트를 진행해본만큼

산술적으로 2개 이상의 프로젝트 팀이 존재할 정도의 규모는 여전히 되었다. 

정말 최악의 경우, 지난 6개월간 스터디할 자료를 잔뜩 쌓아놓은 상황이었기 때문에

전문적 스터디를 목표로 나 주도의 2-3인 팀을 생성한다는 보험도 마련되어 있었다. 

 

두번째, 한 명이 하나의 팀에 귀속되면서

능력치를 제대로 발휘하지 못하는 문제와 팀 간 공유사항이 전혀 없는 문제가 있었다.

이에, 한 명이 오직 하나의 팀에 귀속되는 룰 자체를 부숴야 한다고 생각했다. 

이 또한, 내가 주도적으로 추진할 수 있는 스터디 프로젝트 안건이 여럿이었음로

특정 구성원을 타겟팅해서 복수개의 프로젝트를 참여하도록 윤활작업을 할 수 있었다. 

 

세번째로 프로젝트 명시적 리더가 없다는 지적사항이 있었다.

일정 및 진행에 대한 책임을 모두가 지지 않는 문제를 야기했고

결과적으로 의미있는 진척을 스스로 만들지 못하는 결과를 낳았다. 

한편으로, 지시가 없이 자율과 능력베이스에서 업무 분장이 이뤄지면서

사회적 소요가 매우 적다는 명시적 리더가 없는 장점도 있었다. 

따라서 2가지를 공존시켜야 한다는 생각이 있었다. 

이에, 프로젝트 리더와 조직관리 리더를 분리하고 

소통 파이프라인을 이원화하는 방안을 생각해냈다.

---

지속적 공유에 대한 문제,

일부의 성과를 전체에게 환원시키는 문제가 여전히 남았다. 

따라서, 큰 틀에서 전체 구성원이 공유할 수 있는 룰베이스의 규칙적 일정이 필요했다. 

그렇지 않으면, 각 팀에서 나온 산출물과 경험, 지식은

오직 특정 팀의 팀원들에게만 귀속될 터였다. 

기본적으로 지식 베이스의 성장과 인사이트 공유라는 바이브를 놓치고 싶지 않았다. 

또한, 초기 단계의 Delta 목표는 Common Knoweldge의 확장이었으므로

그 목표를 사수하기 위해서라도 규칙적 일정은 필요했다. 

이런 차원에서 2개월 베이스의 서로 알게된 점을 공유하는 시간을 만들었다.

 

한편으로, 각 팀이 유기적으로 돌아가는 가를 

다시 외부의 시선에서 조망할 수 있는 기회를 각 프로젝트리더에게 필요할 터였다.

나조차도 여전히 부족한 리더인데,

다른 구성원들은 말할 것도 없이 부족할 것이었기 때문이다. 

또한, 세션3에서 외부 관찰자의 역할을 맡아온 경험 상,

한번씩 다른 팀과 외부를 돌아보는 시간이 

프로젝트 리더들 스스로 환기하는 데 분명 도움이 될거라고 보았다. 

따러서 1개월 베이스의 프로젝트리더끼리 토의를 하는 시간을 만들었다 

---

세션6를 일회성의 모험이자 POC로 끝낼 생각은 없었다

무엇보다 구성원들이 직접 요구한 체제 변환이었기 때문에

장기적으로 유지한다는 관점으로 기획을 접근했으며 나 또한 그러고 싶었다 

 

그리고 프로젝트 그 자체는 어떻게 모집할 것이냐였다. 

시작을 어떻게 하느냐에 따라 이후의 지속성에 끼치는 영향도가 달라질 수 있었다. 

애초에 1명 당 1팀 룰을 깰 생각이었고, 

흥미를 기준으로 팀에 합류할 수 있게 할 생각이었으며 

그로부터 나오는 자발적 참여의지를 최대한 자극하고자 했다. 

이에, 다같이 모여서 팀을 구성하는 것이 아니라,

각자가 각자 원하는 프로젝트를 발의하고, 각자 구성원을 리크루팅하는 것으로 기획했다.

 

한편, 이 방식에서 내가 숨긴 의도가 하나 더 있었다. 

각자가 원하는 구성원을 리크루팅하고, 또 리크루팅 당하면서

각 구성원들의 인적 네트워크 형성도를 관찰하는 것이었다.

또한, 구성원들 스스로가 다른 구성원과 어떤 관계인지를

스스로 성찰할 수 있는 계기가 될 수도 있었다. 

---

어떤 생각들이 이런 아이디어를 급하게 만든 것인지는 정확히 알 수 없다.

마치 오늘날 LLM의 아웃풋에 대한 근거를 설명할 수 없듯이.

이 구조와 관련된 당시에 내가 관심있거나 인상깊었던 경험과 지식들을 

지금 시점에서 기억해보며 나열해보면 아래와 같다 

 

- 인터넷에 떠도는 미국 IT 빅테크들의 조직구조 그림이 있다.

  그 중 나는 구글의 그림이 참으로 인상깊었다.

- AWS 온라인 세미나에서 한 미국 금융 그룹이

  마이크로 아키텍쳐로 전사 시스템을 구축했다는 설명을 들은 기억이 있다. 

  당시, AWS SAA를 공부하면서, 서버리스의 관점을 한창 이해할 때 였는데

  마이크로 아키텍쳐에 대해 어렴풋이 알고 있었기에 더욱 인상깊었다. 

 - 조직구조에 대한 책은, 단일 기능 중심의 팀을 컴팩트하게 구성하는 것을 강조했다. 

  그리고 그런 마이크로 팀들이 낼 수 있는 시너지의 가능성

  전사적으로 유기적인 조직구조 형성의 가능성을 언급했는데, 

  마침 내가 늘 아쉬워하던 부분을 긁어주는 내용이라 속이 다 시원했다. 

  - 아주 오래 전, 카카오에 근무하는 한 직원이 2년만에 팀장급 직책을 낸 사연을 

  본적이 있다. 그 분은 한 번에 7개의 팀에서 근무한다고 하였다. 

  마침, 회사 시니어의 아드님이 카카오였기 때문에, 어떤 식으로 근무하는지

  간접적으로 들을 기회가 많았고, 이런 방식의 장점을 한참 전부터 인식하고 있었다

  한편으로 구조화된 팀의 R&R에 갇혀서 일하는 나 자신에 대한 소회이기도 했고.

- 회사 시스템 중, 의미론적으로 같은 시스템이지만, 법규 또는 타 문제로

  이원화되는 시스템들이 꽤 많았다. 이들은 구조적으로도 이분되어 있었는데, 

  이는 동일 작업을 중복해야 함을 의미했다

  따라서, 환경의 요구사항을 맞추면서도

  백단의 의미론적인 부분을 어떻게 분리하여 일원화할 것인가?, 

  실무 프로세스는 과연 일원화될 것인가? 등이 나의 소소하며 불필요한 고민거리였다