개발자들은 '일단 안돼'라고 말하고 본다는 전형성에 대한 생각

개발자들은 '일단 안돼'라고 말한다

보통 이런 얘기를 들을 일이 없는데 개발자가 아닌 분들과 얘기하면 이런 얘기를 듣는다. '무조건 안돼' 족이 있고 '무조건 돼' 족이 있다고...

(둘 다 말이 안되는 건데 ^^)

실제 개발자들은 자신이 개발하고 있는 모듈의 변화를 좋아하지 않는다. 부담스러워 한다. 해야 할 일이 갑자기 생기는 것에 대해 부담스러워 하는 것도 있고 업무 자체가 좀더 깊은 집중을 요구하는 성향이 있어 일련의 인터럽트에 즉자적으로 반응하는 성향도 학습된다.

그럼에도 함께 제기된 문제에 대해 문제 해결을 위해 토론하고 분석하는 시간을 들이는 것은 마다하지 않는다.

두 가지 허들을 풀어야 한다.

하나는 갑자기 던지면 숙고를 거친 반응이 나올 수 없다는 것

또 하나는 중요한 자신의 업무인 이해 당사자이기 때문에 이해 관계를 내려놓고 판단하기 쉽지 않다는 것

첫번째는 좀더 시간을 주고 문제를 여러번 remind하여 enough thinking 후에 답을 구하는 게 방법이라고 볼 수 있는데

두번째는 좀더 까다롭다.

(그런데 이 이해 관계란 이 개발자의 업무 로드가 증가하는 부분이므로 이 의사결정의 주제 관점에서만 보면 크게 중요하지 않은 요소일 수 있다.)

많은 한국의 소프트웨어 개발 회사는 개발 조직이 계층 구조를 이루고 있다. 가장 잘 아는 사람이 개발자인 매니저이고 심지어 핵심 모듈을 개발하기도 한다.

의사 결정에 주요한 권한을 행사하는 사람이 직접적인 이해당사자인 개발자인 경우가 많다는 것이다.

물론 훈련을 통해 개선된다. 업무 로드에 대한 관점, R&R에 대한 관점은 내려놓고 의사 결정 후에 별도 주제로 다루는 게 일반적으로 가능하다

그런데 한 가지 요소를 더 생각해보자면, 풀고자 하는 문제가 무엇인가에 따라 좀더 많은 전문 정보를 공유하고 의사결정의 원칙을 잘 찾는 것이 좋은 의사 결정의 핵심 요소일 텐데 과연 개발자가 문제를 해결하는 전문 정보를 충분히 갖고 있는가, 의사결정의 원칙을 학습을 통해 개선하고 있는가 하는 생각을 해볼 수 있다.

풀고자 하는 문제가 기술적인 전문 분야인 경우는 많은 경우 회의를 통해 좋은 답을 구할 수가 있다.

그런데 순수하게 기술적이지 않은 요소가 많은 경우 포함되고 이러한 전문 지식은 많은 개발자들은 사고의 체계에 포함하는 것을 꺼려 하는 경향이 있다.

R&D 조직이 고립되어 있는 경우는 직접적인 사용자에 대한 추체험이 원활하지 않아 더 제대로 되지 않는 경우가 많다.

사용성의 문제를 푸는 경우에도 이런 현상이 있지만 기술적인 문제에도 실제 서비스가 실현되어 실행되는 환경에 대한 이해가 부족한 경우도 많다.

원래 개발을 할 때 가정했던 환경과 실제 실행되는 환경은 다를 수밖에 없고 또 다양한 시간적, 공간적 변화가 존재하게 마련이다.

이러한 구현체들에 대한 실질적인 검증을 하지 않고 즉자적인 반응을 보이는 것은 추체험 부족과 open-ended mind의 중요성을 깨우치지 못했기 때문으로 볼 수 있다.

개발 조직이 단순 계층으로 편의적인 인원 기준으로 관리되는 경우는 개발자들을 더욱 의사결정의 원칙을 학습하고 실질적인 검증에 대한 추체험을 갖는 기회로부터 배제한다고 볼 수 있는데, 개발자란 설계와 구현, 그리고 개선 과정에서 수많은 의사결정을 할 수밖에 없는 직업이다.

개인적으로는 의사 결정의 원칙이 단순하고 명확한 경우가 아니면 개발자들과 회의를 통해 의사 결정에 참여시키고 의사 결정의 원칙을 정확하게 하는 데 좀더 중점을 둔다.

의사 결정을 내리는 것 자체는 어려운 일이 아니지만 더 많은 숙고와 더 많은 아이디어가 그 의사 결정을 더 빠르게 번복하거나 조정하고 더 풍부하게 해준다.

의사 결정의 원칙을 어떻게 세울지 매번 생각하는 것, 그리고 실질적인 환경에 대해 좀더 정확하게 설명해줄 수 있는 사람을 포함시키는 것 등이 매우 기본적인 전제 조건이라고 볼 수 있다.

과도하게 계층 구조를 세운 조직은 top-down 조직에서는 빠르게 기여할 수 있는 부분이 있겠지만 창의성을 중시하는 조직에서는 간접성만 강화되는 단점이 더 커질 수 있다.

경험적으로 많은 개발자들을 보게 되지만 한국에서는 두 가지 성향이 너무 많아 왔다.

"일단 안돼" -> meta thinking (의사 결정의 원칙에 대한 판단 훈련과 다양한 검증을 위한 추체험) 학습이 부족한 경우

"시키면 하겠습니다" -> intelligence를 제거하는 훈련

어떻게 보면 개발 조직의 의사결정자에게 필요한 게 다양한 의사 결정과 추체험 훈련이라 볼 수 있지만

사실은 개발 조직 의사 결정에 여러 아이디어가 포함되어야 하므로 모든 개발자들에게 필요한 훈련이라 볼 수 있다.

댓글

이 블로그의 인기 게시물

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

일론 머스크의 First Principle Thinking (제1원리 기반 사고)

엄밀한 사고(Critical Thinking)란 무엇일까