<div id="readability-page-1" class="page"><div><article>
최근에 범준님을 만나서 들었던 조언 중에 가장 크게 와닿았던 것이 있다.
"구성원들의 기대 수준을 관리하셔야 해요"
여러 사람들과 함께 이야기를 나누던 자리였지만, 나에게는 너무 와닿는 조언이였다. 아차 싶은 것도 있었다. 나는 그동안 "욕망" 이라고 표현하면서 "내 욕망"을 채우기 위해 최선을 다했기 때문이다.
그러다 범준님의 조언으로 구성원들의 욕망도 관리해야한다는 것을 알게 됐다.
생각해보면 그간 본인의 욕망을 회사에서 더이상 채울 수 없다는 것을 느끼면 그때부터 보상에만 관심을 가지는 경우를 많이 봤다.
보상에 관심을 가지는게 나쁜 것은 아니지만, 회사에서 관심있는 것이 오로지 보상이기만 해서는 건강하지는 못하다고 생각한다. 회사에 더이상 바라는 것이 없다는 것을 의미하기 때문이다.
모든 팀원은 각자 조직내에서 달성하고 싶은 욕망들이 있다.
<ul data-ke-list-type="disc">
<li>AA 기술 써보고 싶어요.</li>
<li>BB 아키텍처 써보고 싶어요.</li>
<li>CC 방식 혹은 프로세스를 도입해보고 싶어요.</li>
<li>DD 경험을 쌓아보고 싶어요.</li>
</ul>
나는 그간 이런 욕망들을 최대한 자제를 시켰다.
아마 이 부분에서 의아하게 느낄 수 있다. 개발팀에 왜 기술적 자유도를 주지 않냐는 것 말이다.
전 직장 배민에서도 느낀건데, 구성원들의 기술 수준이 충분히 되기 전까지는 기술 자율권을 줘서는 안된다고 생각했기 때문이다.
일관되고 통일된 기술 스택으로 모두의 역량이 함께 성장할 수 있도록 환경을 구성하고, 그렇게 모두가 일정 수준에 도달하게 되면 그때서야 기술적 자유도를 주는게 팀 전체의 성장을 위해 훨씬 더 좋다는 것이다.
물론 내 생각이 틀렸을 수도 있다. 하지만, 여태껏 4개의 회사, 10개가 넘는 팀에 속해있으면서 이 생각은 더욱 확고해졌다.
<ul data-ke-list-type="disc">
<li>조직의 성숙도, 기술 수준이 낮을때는 답답할 정도로 강제성이 강한 언어와 프레임워크를 통해 잘못된 방향으로 쉽게 가지 못하도록 만들고, 단일화된 기술 스택으로 모두의 역량을 하나로 집중 시킨다.</li>
<li>이렇게 해서 조직의 기술 수준이 높아지면 그 이후부터는 자유도와 선택지를 넓혀나간다.</li>
</ul>
이 방식이 성숙도가 낮은 조직의 기술 부채를 관리 (Management) 하는 가장 효과적이라는 것을 경험했기 때문이다.
그럼 지금은 생각이 변한걸까? 그렇지는 않다. 여전히 개발 조직의 성숙도가 낮을때는 자율성이 독약이라는 생각에 변함은 없다.
다만, "지금의 우리팀 수준이라면 그래도 어느정도는 자유도를 줘도 되지 않을까" 하는 생각과 "개발자로서 가지고 있는 모든 욕망을 거세당하면 과연 우리 회사를 다닐 이유가 있을까" 하는 생각이 들었다.
그래서 관리 가능한 범위 내에서는 자유도를 주고 있다.
<blockquote data-ke-style="style1">
물론 우리 팀원들이야 "뭐? 이정도가 자유도가 있는거 였어..?" 라고 할 수도 있지만..
</blockquote>
나한테는 엄청 큰 결정들이였다. (아마 전 팀원들이 봤으면 억울하다고 할 것 같다.)
<ul data-ke-list-type="disc">
<li>팀에서 잘 사용하지 않는 디렉토리 구조를 써보도록 하고</li>
<li>과하지 않는 선에서 새 아키텍처를 적용하게 하고</li>
<li>라이브러리는 나도 같이 확인해보고 교체하기 쉬운 형태로 추상화 계층을 만든 뒤에 적용시킬 수 있도록 하고</li>
</ul>
특히, 잘못된 방법을 제안하면 실행에 옮기게 하고, 그 방법이 왜 문제인지를 직접 경험할 수 있도록 기회를 주고 있다. 잘못된 방법이 분명하지만 그게 결국 내 조언으로만 알게 되면 경험 기반의 성장이 될 수 없다. 그래서 문제가 될 수 있는 부분을 충분히 설명하고나서, 그래도 한번 꼭 써보라고 제안한다. 한번 써보고 어떤 것 때문에 문제인지 경험해보면 확실하게 문제점을 알기 되기 때문이다.
물론 모든 기술적 결정에 이 방식을 택하진 않는다. 조직의 기술 부채가 너무 심해지면 안되기 때문이다. 그래서 기술적 결정을 내릴때 이 결정으로 조직이 감당해야할 부채가 얼마나 큰지 먼저 판단하고 진행한다.
아직까지는 허락 보다는 반대가 더 많다. 이 부분은 계속 훈련을 해야할 것 같다.
100% 다 자유도를 주는 것은 아마 앞으로도 힘들것 같다. 그래도 최대한 우리 팀원들의 욕망을 잘 관리해보고 싶다. 그래서 모든 팀원들이 계속 나, 우리 조직과 계속 함께 하고 싶게 만들고 싶다.
</article></div></div>

기억보단 기록을

이동욱 (향로)

최근에 범준님을 만나서 들었던 조언 중에 가장 크게 와닿았던 것이 있다.
"구성원들의 기대 수준을 관리하셔야 해요"
여러 사람들과 함께 이야기를 나누던 자리였지만, 나에게는 너무 와닿는 조언이였다.
아차 싶은 것도 있었다.
나는 그동안 "욕망" 이라고 표현하면서 "내 욕망"을 채우기 위해 최선을 다했기 때문이다.
그러다 범준님의 조언으로 구성원들의 욕망도 관리해야한다는 것을 알게 됐다.
생각해보면 그간 본인의 욕망을 회사에서 더이상 채울 수 없다는 것을 느끼면 그때부터 보상에만 관심을 가지는 경우를 많이 봤다.
보상에 관심을 가지는게 나쁜 것은 아니지만, 회사에서 관심있는 것이 오로지 보상이기만 해서는 건강하지는 못하다고 생각한다.
회사에 더이상 바라는 것이 없다는 것을 의미하기 때문이다.
모든 팀원은 각자 조직내에서 달성하고 싶은 욕망들이 있다.
AA 기술 써보고 싶어요.
BB 아키텍처 써보고 싶어요.
CC 방식 혹은 프로세스를 도입해보고 싶어요.
DD 경험을 쌓아보고 싶어요.
나는 그간 이런 욕망들을 최대한 자제를 시켰다.
아마 이 부분에서 의아하게 느낄 수 있다. 
개발팀에 왜 기술적 자유도를 주지 않냐는 것 말이다.
전 직장 배민에서도 느낀건데, 구성원들의 기술 수준이 충분히 되기 전까지는 기술 자율권을 줘서는 안된다고 생각했기 때문이다.
일관되고 통일된 기술 스택으로 모두의 역량이 함께 성장할 수 있도록 환경을 구성하고, 그렇게 모두가 일정 수준에 도달하게 되면 그때서야 기술적 자유도를 주는게 팀 전체의 성장을 위해 훨씬 더 좋다는 것이다.
물론 내 생각이 틀렸을 수도 있다. 
하지만, 여태껏 4개의 회사, 10개가 넘는 팀에 속해있으면서 이 생각은 더욱 확고해졌다.
조직의 성숙도, 기술 수준이 낮을때는 답답할 정도로 강제성이 강한 언어와 프레임워크를 통해 잘못된 방향으로 쉽게 가지 못하도록 만들고, 단일화된 기술 스택으로 모두의 역량을 하나로 집중 시킨다.
이렇게 해서 조직의 기술 수준이 높아지면 그 이후부터는 자유도와 선택지를 넓혀나간다.
이 방식이 성숙도가 낮은 조직의 기술 부채를 관리 (Management) 하는 가장 효과적이라는 것을 경험했기 때문이다.
그럼 지금은 생각이 변한걸까? 
그렇지는 않다. 
여전히 개발 조직의 성숙도가 낮을때는 자율성이 독약이라는 생각에 변함은 없다.
다만, "지금의 우리팀 수준이라면 그래도 어느정도는 자유도를 줘도 되지 않을까" 하는 생각과 "개발자로서 가지고 있는 모든 욕망을 거세당하면 과연 우리 회사를 다닐 이유가 있을까" 하는 생각이 들었다.
그래서 관리 가능한 범위 내에서는 자유도를 주고 있다.
물론 우리 팀원들이야 "뭐? 이정도가 자유도가 있는거 였어..?" 라고 할 수도 있지만..
나한테는 엄청 큰 결정들이였다.
(아마 전 팀원들이 봤으면 억울하다고 할 것 같다.)
팀에서 잘 사용하지 않는 디렉토리 구조를 써보도록 하고
과하지 않는 선에서 새 아키텍처를 적용하게 하고
라이브러리는 나도 같이 확인해보고 교체하기 쉬운 형태로 추상화 계층을 만든 뒤에 적용시킬 수 있도록 하고
특히, 잘못된 방법을 제안하면 실행에 옮기게 하고, 그 방법이 왜 문제인지를 직접 경험할 수 있도록 기회를 주고 있다. 
잘못된 방법이 분명하지만 그게 결국 내 조언으로만 알게 되면 경험 기반의 성장이 될 수 없다. 
그래서 문제가 될 수 있는 부분을 충분히 설명하고나서, 그래도 한번 꼭 써보라고 제안한다. 
한번 써보고 어떤 것 때문에 문제인지 경험해보면 확실하게 문제점을 알기 되기 때문이다.
물론 모든 기술적 결정에 이 방식을 택하진 않는다.
조직의 기술 부채가 너무 심해지면 안되기 때문이다. 
그래서 기술적 결정을 내릴때 이 결정으로 조직이 감당해야할 부채가 얼마나 큰지 먼저 판단하고 진행한다.
아직까지는 허락 보다는 반대가 더 많다. 
이 부분은 계속 훈련을 해야할 것 같다.
100% 다 자유도를 주는 것은 아마 앞으로도 힘들것 같다.
그래도 최대한 우리 팀원들의 욕망을 잘 관리해보고 싶다. 
그래서 모든 팀원들이 계속 나, 우리 조직과 계속 함께 하고 싶게 만들고 싶다.

욕망 관리하기

댓글