윤경구의 Log on Java

개발 조직을 관리하면서 가장 중시하는 목적 지표 중 하나는 parallelism 수준, 또하나는 더 나은 의사결정을 하는 aggregate intelligence 수준으로 생각하는 편이다. 1. parallelism 혹은 vectorization 병렬화 수준 혹은 동시성 수준은 각자 자신의 일을 진행하는 데 병목이 되는 기다림이나 동기화를 최소화하는 것이고, 그 이전에 자신의 일이 가지는 목표가 분명하고 또 스스로 업무를 잘 큐잉해서 언제든지 자신의 큐에서 넣고 뺄 수 있어야 한다. 물론 목표가 자신의 수준에서 조직의 수준에서 다를 수 있기 때문에 기다림을 최소화하면서 동기화하는 리뷰나 이슈 토론 같은 것들이 오히려 중요할 수 있다. 업무를 나눌 때에도 다른 사람이 의존하는 일들은 우선 순위를 좀더 높인다거나 협업에 대한 부분을 미리 스케줄링하는 것들이 중요하게 된다. 여러 사람의 업무와 관련한 의사결정이 필요한 시점에는 어쩔 수 없이 waiting이 있을 수 있다. 이를 최소화하고 잘못된 의사결정으로 인한 폐기 업무, 반복 업무를 최소화하는 것은 의사결정에 책임이 있는 사람들에게 매우 높은 우선 순위가 된다. 2. aggregate intelligence or collaborative decision making 여러 사람의 아이디어가 한 사람의 아이디어보다 더 나을 가능성이 크다는 것은 인간의 불완전함이나 생각의 바이어스 등을 고려할 때 단순한 산수 이상이라고 할 수 있다. 더 나은 의사 결정을 하는 것은 단순히 개인이 돌아가면서 의사결정을 하거나 한 사람의 의사결정을 투표하는 것이 될 수 없다. 여러 의견들 중 최선의 의견에 기반하면서도 공유 과정에서 더 나은 의사 결정으로 발전시키는 과정은 수많은 의사결정을 여러 조직 단위에서 이루어내는 문화 구축과 상관 있다. 기술적 의사 결정은 보다 더 깊은 기술적 이해와 여러 가지 가설에 대한 분석, 연구 등의 반복적인 과정을 필수적으로 요구한다. 물론 이 과정에서 여러 사람의 아이디어를 수집하고 이해하고 논의할 ...

관리라는 말은 정말 싫어하던 말이다. 스스로 자기 일을 잘 하면 되지, 왜 관리가 필요할까? 그런 생각이 강했다. 나이가 들어 관리자의 역할을 맡게 되어서도 관리에 대해 충분히 고민하지 못했다. 관리가 얼마나 중요한가에 대해 깨닫지 못했다. 아마도 내가 속한 팀의 팀원들은 무관리(?)한 관리자에 어이없어했을 것이다. 지금은 생각이 많이 바뀌었다. "혼자서도 잘해야 하겠지만 함께 해야 무엇이든 이룰 수 있다" 혼자서도 잘해야 하는 게 바뀌는 건 아니겠지만, 혼자만의 힘으로 이룰 수 있는 건 거의 없다. 함께 해야 하는 것이라면 모두 관리의 영역에 포함된다. 뒤늦게 관리에 대해 생각을 하게 되었다. 수많은 시행착오를 뒤늦게 하게 된 것이다. 관리라는 말을 싫어하는 이유는 관리라는 말 자체가 정태적인 관료 조직을 떠올리기 때문이다. 특히 한국의 대기업 문화에서 보이는 관리자들은 전문성 없는 단순 관리자들이다. 자신의 역할이 기업 내 정치랄까 줄서기가 핵심인 가부장적인 존재들이다. 목적이 분명한 조직은 목적에 맞는 관리 체계를 가져야 한다. 관리자로서 가장 큰 실패는 관리자가 없어도 된다는 생각이다. 예를 들어, 구글과 같은 인재들이 모인 조직은 당연히 관리를 싫어한다. 스스로 일을 잘하는 사람들이 굳이 관리를 받으면서 일하려고 하지 않기 때문이다. 하지만, 구글도 목적을 가진 기업이고 이에 따라 사람들을 조직화해야 하기 때문에 관리가 없을 수가 없다. 불필요한 형식에 얽매이지 않고 좀더 목적에 필요한 부분으로 관리를 최소화하려고 노력을 할 뿐이다. 관리의 출발점은 목표 설정(goal setting) 이라고 생각한다. 목적 조직에서 관리자들은 틀에 박힌 형식을 중시해서는 안된다. 항상 뚜렷한 목적을 가져야 한다. 목적에 따라 여러 가지 시도를 하면 된다. 물론 경험과 조언 등이 있으면 더 나은 시도를 할 수 있고 시행착오를 줄일 수 있겠지만. 목적 조직은 결과만으로 평가해서는 안된다. ...

한 페친이 프로젝트 정량화에 대한 글을 올려서 몇 가지 의견을 제시한 글들을 옮겨놓습니다. "왜 정량화를 하려는지 목적이 무엇인가요? 또 프로젝트 결과란 무엇인가요? 프로젝트별 목표가 다르기 때문에 각 목표는 있을 수 있겠지만 sw 프로젝트 일반에 대한 정량화란 말 자체가 무엇인지 생각해보기 바랍니다. 가능한 것은 프로젝트별 목표이고 그나마 정성적인 요소들은 일반화된 기준의 수치화는 시도하는 게 무의미합니다." "SW 프로젝트 결과물이란 SI이거나 SW 솔루션이거나 서비스이거나 하겠지요. 그 결과물의 점수를 일반적으로 점수화한다는 시도 자체가 피겨 스케이팅의 점수 채점을 객관화하는 것과 왜 비슷하다고 생각하는지 모르겠구요. 그에 앞서 왜 점수화를 하려고 하는지 편의적인 발상이 아닌가 하는 부분입니다. 일반화한 정량화는 비교가 가능한 정량화인데 그것을 추구하는 의도가 무엇인가요? SW에서 가장 경계하는 것 중 하나가 단지 있으면 좋을 것 같은 것입니다. 왜 하는지 모르고 하는 거죠. SW가 그냥 일반적인 목적을 갖지 않는다면 SW를 일반화한 평가가 의미가 있는 걸까요? 비교 분석하려는 평가 목표 자체가 문제가 있다고 생각합니다. 비교라는 건 엄밀한 제약 조건을 가지고 있어야 하는데 단순 논리에 의한 일반화의 오류가 보이기 때문에 얘기했습니다. SW에 대한 일반화된 정량화보다는 목표의 엄밀한 설정이 중요하다고 생각합니다." "SW가 어떤 목적을 달성하기 위한 해결책인데 목적과 무관한 일반화된 평가 지표.. 그것은 비현실적인 생각인데 그것을 일반화하려는 무리한 시도 자체가 SW의 질적 수준을 저해한다고 생각합니다. 국내 SW 정책이 그런 정량주의에 기반하고 있죠. SW가 아닌 SW공학이 SW 정책을 입안하고... SI 프로젝트와 같이 SW 수준이 중요하지 않은 프로젝트에서나 가능한 걸 일반화하기도 하고.." "프로젝트 결과를 정량화하는 게 도덕적 사회적 기준으로 한다는 걸 ...

lateral thinking을 번역할 때처럼 wicked problem도 우리말로 옮기기가 쉽지 않다. 창의적 사고의 한 방법으로 제안되었던 lateral thinking은 한 우물을 깊게 파는 수직적 사고 대신에 여러 우물을 주변에 파보는 사고를 제안하는 것인데 이를 "수평적 사고"라고 번역한 탓에 창의는 수직적 위계질서나 권위에 반하는 사고에 기반한다는 단순 논리들을 일으키기도 했다. 어색하지만 "곁을 따라 생각하기" 정도가 맞지 않을까 싶다. wicked problem은 "까탈스런 문제" 정도의 어감으로 들으면 좋겠다. wicked problem의 대응되는 개념으로는 tame problem "순한 문제"가 있다. 여기에서는 wicked problem을 악제(惡題), tame problem을 순제(淳題)라는 용어를 만들어 써본다.  악제(惡題, wicked problem)와 순제(淳題, tame problem) 악제(惡題)는 솔루션을 만드는 매 시도가 문제에 대한 이해를 변화시키는 문제이다. 이런 문제들은 문제의 정의가 새로운 가능한 솔루션들이 고안되고 구현될 때마다 문제의 정의가 진화하기 때문에 전통적인 선형적 방법으로 풀 수가 없다. (Rittel & Webber, 1973) "Wicked" problems are ones for which each attempt to create a solution changes the understanding of the problem. They cannot be solved in a traditional linear Fashion, because the problem definition evolves as new possible solutions are considered and/or implemented. Jeff Conklin은 다음 여섯 가지 특성을 악제(惡題)에 고유한 특성으로 보았다. ...