소프트웨어 조직의 관리에 대한 단상

관리라는 말은 정말 싫어하던 말이다.
스스로 자기 일을 잘 하면 되지, 왜 관리가 필요할까?
그런 생각이 강했다.

나이가 들어 관리자의 역할을 맡게 되어서도 관리에 대해 충분히 고민하지 못했다.
관리가 얼마나 중요한가에 대해 깨닫지 못했다.
아마도 내가 속한 팀의 팀원들은 무관리(?)한 관리자에 어이없어했을 것이다.

지금은 생각이 많이 바뀌었다.

"혼자서도 잘해야 하겠지만 함께 해야 무엇이든 이룰 수 있다"

혼자서도 잘해야 하는 게 바뀌는 건 아니겠지만, 혼자만의 힘으로 이룰 수 있는 건 거의 없다.
함께 해야 하는 것이라면 모두 관리의 영역에 포함된다.

뒤늦게 관리에 대해 생각을 하게 되었다.
수많은 시행착오를 뒤늦게 하게 된 것이다.

관리라는 말을 싫어하는 이유는 관리라는 말 자체가 정태적인 관료 조직을 떠올리기 때문이다. 특히 한국의 대기업 문화에서 보이는 관리자들은 전문성 없는 단순 관리자들이다.
자신의 역할이 기업 내 정치랄까 줄서기가 핵심인 가부장적인 존재들이다.

목적이 분명한 조직은 목적에 맞는 관리 체계를 가져야 한다.

관리자로서 가장 큰 실패는 관리자가 없어도 된다는 생각이다.
예를 들어, 구글과 같은 인재들이 모인 조직은 당연히 관리를 싫어한다.
스스로 일을 잘하는 사람들이 굳이 관리를 받으면서 일하려고 하지 않기 때문이다.

하지만, 구글도 목적을 가진 기업이고 이에 따라 사람들을 조직화해야 하기 때문에 관리가 없을 수가 없다.
불필요한 형식에 얽매이지 않고 좀더 목적에 필요한 부분으로 관리를 최소화하려고 노력을 할 뿐이다.

관리의 출발점은 목표 설정(goal setting)이라고 생각한다.
목적 조직에서 관리자들은 틀에 박힌 형식을 중시해서는 안된다.
항상 뚜렷한 목적을 가져야 한다.
목적에 따라 여러 가지 시도를 하면 된다.
물론 경험과 조언 등이 있으면 더 나은 시도를 할 수 있고 시행착오를 줄일 수 있겠지만.

목적 조직은 결과만으로 평가해서는 안된다.
시행 착오로 결과가 나쁘게 나오더라도 목적이 뚜렷한 행위는 개선 가능하고, 많은 것을 학습하기 때문이다.

두번째는 관리에 정답이 있지 않다는 것이다.
목표에 따라 수많은 길들이 있을 수 있다.
흔히 소프트웨어를 문제 해결에 비유한다.
목표 설정은 관리와 관련된 문제 인지 과정이며, 관리 행위들은 문제 해결 과정이라고 볼 수 있다.
소프트웨어와 같은 복잡한 문제를 다룰 때는 항상 고정된 정답이 있지 않다.
이런 문제를 흔히 악제(wicked problem)이라고 부른다.
모든 악제에는 생각하지 못한 더 현명한 길이 있다고 생각해야 하며, 관리의 문제도 다른 악제들과 마찬가지로 항상 더 현명한 길이 있다.

따라서, 더 많은 생각과 토론들이 더 나은 길을 찾는 데 도움이 된다.

세번째는 소프트웨어 개발 조직에서 관리자는 스스로 전문성을 가져야 한다.
항상 행위의 목적을 생각해야 하고 그에 따라 판단을 내리고 행동해야 한다.

가끔 관리자의 겉멋을 (품격?) 찾는 사람들을 볼 때가 있다.

뭐.. 그 시간이 어떤 문제를 풀 시간이 아니라 여유를 즐기는 시간이었다면 충분히 의미 있겠지만...

어쨌거나, 관리의 문제는 매우 어려운 문제이다.
스스로도 익숙하지 않고 끊임없이 도전 받는 주제이다. (관리자로서의 평가는 낙제에 가까울듯)

소프트웨어에서 관리는 사람들을 다루면서도 기술적인 해결을 찾는 과정이기 때문에 더욱 어려움이 많은 것 같다.

사람들과 좀더 많은 아이디어를 주고 받으면서도 동기 부여를 하고, 더 많은 생각을 하게 하고, 더 깊은 토론을 더 끈기있게 해야 하고, 더 나은 결정을 내려야 한다.

목표를 뚜렷이 하고 단순화하여 공유하되, 끊임없이 방법을 개선해나갈 수밖에 없는 것 같다.
아이디어를 함께할 사람들과 좀더 편해져야 하는 문제이기도 하고.

댓글

이 블로그의 인기 게시물

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

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

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