윤경구의 Log on Java

신입 코칭을 굉장히 중요하게 생각하고 장시간 직접 챙기는 편이지만 생각해보면 매니지먼트에 대한 코칭이 훨씬 더 중요할 수 있다. 경험적으로 매니저들에 대해서는 코칭보다는 기대치만 부여해서 전체 조직이 비효율적이 되거나 중요한 문화적 자산을 단절시키거나 하는 경우가 많았다. 기술 조직에서 코칭은 기술에 대한 측면이 강하고 기술에 관한 협업적 의사결정의 사례 경험의 성격도 강하다. 곰곰 생각해보면 기술 축면의 코칭이란 전공 요소들을 반영하는 것이라 개인의 상당한 학습 노력과 결합하거나 기반 지식을 갖추고 있을 것을 요구한다. 매니지먼트에 대한 코칭은 그런 전제 조건이 약하기 때문에 훨씬 쉽고 효과도 클 가능성이 있다. 매니지먼트는 의사결정의 원칙에 대한 것이고 이 원칙이 무엇이어야 할지를 세워보도록 경험을 쌓는 게 코칭의 핵심일 수 있다. 의사결정이 계속 관행이나 주어와 목적 없는 프로세스에 의한 것이라면 누구도 새로운 상황에서 혹은 새로운 인적, 환경적 조건에서 의사결정 기준을 정리하고 이에 따라 판단하려고 하지 않을 것이다. 기준을 명시적으로 세워보지 않으면 친소 관계나 관행이 중요한 기준이 될수밖에 없다. 의사결정을 원칙을 세우고 판단하는 과정은 대부분 2,3회면 충분히 학습할 수 있다. 사람을 특별히 싫어해서 독단적 의사결정에 의존하는 경우나 의사결정 자체를 못하는 특수하게 적성에 맞지 않는 경우가 있긴 하지만 수년에 걸친 노력을 축적해야 하는 기술 관련 학습에 비해 정말 효율이 높다고 볼 수 있다. 물론 좋은 의사결정은 각 문맥별로 요구하는 사항이 다르고 그 적응력은 개인차가 있겠지만 많은 경우 충분히 가치있는 의사결정을 할수 있을 것이다.

빅파일 전송 프로그램 빅파일 전송 프로그램을 급 제작해서 작년부터 고객사에서 쓰고 있는데 신규 고객사가 생기거나 고객사의 고객이 파일 전송하다 오류가 생기면 연락이 온다. ㅠㅠ (연락이 뜸해지면 고객사 사업이 잘안되나 걱정부터 듬 ㅠㅠ 모니터링하는 방법과 로그를 개선하였지만 업데이트를 꺼리는 고객이라 ㅋㅋ) 원인의 추정 클라이언트쪽 PC 방화벽부터 기업 방화벽, 그리고 서버쪽 타임아웃 설정 등 이슈가 엔드투엔드로 발생하는데 이게 100GB~1TB 가량 되는 파일 전송이다보니 별별 상황이 다 생긴다. “Network is unreliable”이기 때문에 혹시 모를 경우의 수를 생각해서 신중하긴 하지만 최근에는 금요일 밤 늦게 온 전화 때문에 화를 낸 적이 있다. 한참 오류 상황을 듣고 있었는데 파일 내용이 우리가 준 툴로 자동 생성한 파일이면 전송이 실패한다는 것 ㅠㅠ 100GB 파일 전송하면서 내용을 체크해서 뭘 할수도 없고 버퍼별로 암복호화 압축 체크섬 계산(이건 필요없다고 생각하지만 테스트 용도로 넣어둔 전체 파일 체크섬의 map-reduce 버전. 고객들은 매우 중요하게 생각 ㅠㅠ) 등을 하기 때문에 파일 내용이란 건 암호화하는 순간 아무 의미도 없는 얘기. 신뢰할 수 없는 상황에서 문제를 해결할 때에는 확실한 증거 기반으로 가설을 재수립해가야 하는데 지나치게 많은 중첩된 가설로 이상한 이야기를 주말 밤에 전화로 한 거. 프로젝트 오픈하느라 바쁠텐데 이런 걸 상의 없이 테스트 하느라 하루를 통째로 날린 게 답답하고 안쓰러운 게 컸다. 이 분에게 네트웍 환경 체크를 하랬더니 집에 가서 또 해보겠다고 셀룰러에 테더링으로 전송하고 또 자신의 주장이 맞다고 연락 ㅠㅠ 다행히 http tunneling 방식으로 구현해서 앞쪽 아파치 서버에 액세스 로그가 남아있어서 408 에러코드 확인하고 고객분이 테스트하신 환경인 코워킹스페이스 FAQ 사이트 가서 대역폭 제약 관련 조항을 캡쳐해서 보내줌. 셀룰러로 100GB 보내도 대역폭 제약이 안걸릴 거라는 생각을 하면 안된다

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