윤경구의 Log on Java

 매니저는 목표와 방향을 다루는 역할이다. 매니저가 아니라도 목표가 중요하지만 개별 목표와 그룹이나 조직의 목표는 다를수밖에 없고 어떻게 방향을 집합적으로 정렬해갈 것인가가 매니저의 핵심 미션이다. 좀더 개인들의 역할이 목표에 기반해있고 조직의 방향과 스스로 연결지어 간다면 관리 계층 구조를 좀더 줄여갈 수 있을 것이다. 관리 구조가 여러 층으로 수직화되면 매니저의 커뮤니케이션 역할이 더욱 중요해지는 반면 그럼에도 불구하고 전반적인 수동성이 높아지고 의사결정들이 복잡해지고 추상적이 될 우려가 있다.  목표의 공유는 사람들이 어떤 방향으로 생각을 한번 더 하게 할것인가의 문제이고 매니저의 의사결정은 그 사람들의 생각을 수집하고 수렴하고 체계화하는 것이라고 볼 수 있다. 지적인 문제 해결이 핵심인 조직에서 매니저의 의사결정이 방향에 대한 것을 빼고 나면 대부분 멤버들의 생각에 기반할수밖에 없다. 물론 충분히 좋은 생각을 만나지 못하고 시간만 흐를 경우에는 매니저 스스로 생각을 만들고 잠정적인 결정을 하는 역할도 있겠지만 대부분 보조적 역할이어야 잘 활성화된 조직일 것이다. (좋은 아이디어에 대한 판단 능력과 수렴 능력은 필수) 매니저의 보조적 역할은 멤버들의 질문을 도와주는 것이 멤버들의 솔루션을 도와주는 것보다 중요한 역할이라 할 수 있다   하지만 매니저가 항상 숟가락 얹기(?)만 하면 단순 논리의 중재, 정리 역할을 할 우려가 있는데 집단의 수준에 따라서 큰 문제가 안될수도 있겠지만 결과적으로는 대부분 단순한 추인의 의사결정이 된다고 하더라도 (그렇게 된다면 매우 좋겠지만) 결정의 방향성에 좀더 장기적인 관점을 부여하기 위해 훨씬 많은 노력을 기울여야 한다. 우수한 인재들이 많다면 장기적인 관점과 방향성에 대해서도 좀더 오픈하고 자주 논의하면 좀더 나은 숟가락을 만들 수 있을 것이다. 내가 하고 있는 일에 대해 스스로 어떤 목표를 부여하고 일정 간격으로 리마인드하게 하는 것, 너무 자주일 필요는 없지만 가끔씩 목표를 다시 생각하게 해...

목표가 여러 개가 되면 기억하기도 힘들고 생각이 분산되어 추진하기도 힘들다. 메트릭이라고 하긴 어렵지만 제대로 된 방향성을 가지고 관리 체계가 돌아가는지 돌아볼 때 혹은 중간 관리자들에게 얘기할 수 있는 쉬운 관리 목표로 나는 병렬성을 얘기한다. 10명이 일을 하면 관리자를 제외한 9명의 병렬성을 보장해줘야 하는 것이 아닐까 하는 단순한 문제 제기. 이렇듯 R&D 조직 관리 시 가장 중시하는 게 parallelism을 높이는 것이다. concurrency라고 해도 좋겠다. management에 대한 wait을 최소화하도록 개인적으로 목표를 협의하여 설정하고 스스로 생각을 하게 하는 것이다. management의 코칭과 의사결정, 지원이 잘못되어 지연되거나 시간을 낭비하는 것을 줄이고, 더 나은 결정을 위해 단선, 다선 간 생각을 모아가는 게 쉬운 일은 아니지만, 기본적으로는 management 를 쳐다보지 않고 각 개인들이 자기 일을 하는 것이 첫 출발점이다. management는 그 기반 위에서 조율을 할 수 있다. 어찌 보면 학습의 목적 함수에 goal에 해당하는 classification이나 regression loss를 최소화하는 항 외에 entropy를 최대화하도록 하는 항을 포함시키는 것과 비슷하다. 사실, management가 병목 역할을 하게 되는 경우가 종종 있는데 어쩔 수 없는 병목이 있는 것은 당연하지만, 너무 과도하게 친절한 코칭 혹은 자신에 대한 과도한 신뢰(?), 생각할 필요가 없을 정도로 단순화된 지시 등을 해서 개개인을 수동화하는 경우가 가장 실패한 managing이라고 본다. 생각을 하는 학습이 되지 않은 사람들을 모으는 회의에서 어떤 의견이 나올 수 있을까. 목표가 분명하면 생각을 하지 않을 수가 없고, 또 주변의 환경이 갖춰지면 쉽게 목표 중심의 사고를 배울 수 있다. 좋은 의견이란 deterministic하지 않고 stochastic하다. 그런 경우라야 collective decision이 더 나을 수 있다. 물론 c...

연구소장으로 몸담아왔던 직장을 갑작스레 퇴직하게 되었다. 이 사실을 알게 된 몇몇 연구원들이 찾아온다. 왠지 뭉클하면서도 최악의 관리자였던 내가 조금은 나아졌나보다 하는 위안도 든다. 개인적으로 10여년 간 소프트웨어 연구개발 관리자로서 몇 가지 시기를 거쳤다. 제 1기는 관리자를 맡은 개발자 . 이때는 관리자라기보다는 개발자였다. 정체성이 개발자인데 수십명을 관리해야 하는 관리자 역할이 주어진 것이다. 당시에는 팀원들을 코칭한다거나 친밀감을 개선한다거나 하는 데 전혀 신경을 쓰지 않았다. 조직 관리는 스스로의 목표에 들지도 못했던 것이다. 늘 조직의 소프트웨어 미션에만 신경을 쓰고 팀원들의 성장이나 상태에는 전혀 신경을 쓸 줄 몰랐다. 팀원들의 코드에 문제가 있으면 내가 다시 짜버리지 하는 생각이 컸었고, 스스로가 메인 코더였고 실제 백만 LoC에 달하는 코드를 작성했던 시기였다. 아마도 당시 팀원들은 황무지에 버려진 처지로 생각하면서 매니저가 너무 열심히 일을 하기 때문에 완전히 서로 다른 세계의 사람인 취급을 했을 것이다. 나중에 얘기를 들어보니, 조금 걱정을 하기도 했다고... ㅠ_ㅠ 제 2기는 코칭을 처음 해보는 난폭한 관리자 이때는 관리가 필요하다는 점을 처음으로 인지했다. 가능하면 스스로 하는 코딩을 줄이려고 노력했고, 팀원들을 코칭하기 위해 노력했다. 하지만, 수적으로나 경험적으로 절대적으로 부족한 팀원들을 데리고 소프트웨어 개발을 하는 매우 힘든 미션이기도 했지만, 더 중요하게는 아무런 경험없는 신입 팀원들을 하나씩 코칭하면서 가장 비효율적인 접근을 했다. 신입 팀원들의 결과물들은 소프트웨어 경험이 이미 십년이 넘은 사람이 보기엔 너무 기본조차 되어 있지 않았고, 이를 극복하고 결과를 만들려는 당위성에 짓눌려 몹시 공격적으로 팀원들을 다그쳤다. 팀이 전체적으로 회사의 주목을 받지 못하는 상황이었기 때문에 팀원들의 상실감이 매우 컸다. 결국 신입 팀원들은 한참의 시간이 지나서야 조금씩 나아졌고(원래 걸리는 시...

목표(goal)는 수준과 시간의 의미를 함께 가지고 있다. goal을 설정하는 것과 성취하는 것은 많은 경우 하나의 연속된(반복된) 과정이다. goal 설정 시 수준을 반영하는 간단한 문장을 요구하는 편이지만 시간에 대한 부분은 늘 reasonable한 수준이라고 implicit하게만 요구한다. 스스로는 계속해서 수준과 시간을 수정해가야 하겠지만 manager 혹은 adviser가 판단할 수 있는 건 그 사람의 능력을 고려한 합리적인 노력 여부와 방법적인 부분 정도이다. 시간에 대한 한계를 먼저 설정한다는 건 매우 어려운 일이지만 시간을 무시하는 것은 또한 잘못된 일이다. "내가 마무리할 때가 마무리하는 것이다"라는 사고는 대부분 성과 측면에서 비효율적이며, 목표를 추진하는 사람의 성장에도 도움이 되지 않는다. 수준과 시간, 그리고 성장이란 화두가 적합하지 않은 영역도 있을 것이다. 아마도 그런 영역은 goal이란 표현도 적합하지 않을 것이다. 조금 시각을 다르게 해서 근원적인 문제를 떠올려보자. 왜 우리는 더 나은 성과와 성취, 성장을 얘기하는 걸까. 하고 싶은 만큼 일하고 그 결과를 나눠가지면 안되는 걸까. 엄청난 수준으로 생산력이 향상되면 과연 그게 가능한 것일까? 나는 그렇지 않다고 판단한다. 사람 자체의 생산력이 기술의 발전에도 불구하고 아무런 비용 없이 무한의 잉여를 주지는 못할 것이라고 본다. 물론 불필요한 일들은 크게 줄일 수 있으리라고 본다. 판단에 집중할 수 있고 상대적으로 변화와 개선의 사이클도 짧아질 수 있으리라고 본다. 그럼에도 불구하고 그건 그러한 통찰을 가능하게 하는 고도의 인간 활동의 숙련을 위해 보조하는 역할들을 할 거라고 본다. 적어도 잉여의 생산은 유럽의 복지에 대한 개념이 국내의 복지에 대한 개념과 다른 것처럼 노동 없이도 인간으로서 삶을 기본 보장하는 건 가능할 것이다. 하지만, 진보를 이끄는 힘들은 여전히 goal을 필요로 한다고 본다. 인간다운 삶에 대한 ...