네트웍, 불확실성, 가설과 검증, 비전

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

개발 조직을 관리할 때 목적 지표, parallelism과 aggregate intelligence

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

솔루션 기능 만들 때 우선순위 판단 기준

 제품 기능 만들 때 우선 순위 판단.  1. 꼭 필요한 기능, 이 중에도 복잡도가 높은 기능과 핵심 경쟁력이 될 차별성을 줄 수 있는 기능은 더 가중.  2. 당락을 결정하는 기능 항목은 명목만. 3. 그냥 필요할 것 같은 기능, 좋아보이는 기능은 끝까지 미루다가 실 요구사항이 생기면 … Straightforward 기능들은 언제든지 만들 수 있지만 복잡도가 높은 경우는 시행착오와 아이디어가 더 많이 필요하기 때문에 개발 시간의 변동성이 커서 좀더 일찍 파일럿 개발을 해가면서 검증이 필요합니다. 사실 복잡도가 있는 기능은 시간을 미리 계획해서 하는 건 무의미하기도 해서 조직적으로도 우선순위를 높이고 계속 아이디어를 공유해서 핵심 문제의 해결책을 검증하고 나야 유의미한 시간 계획을 세울 수 있죠. 복잡도 = 미검증된 주요 이슈가 있는 경우. 즉자적인 단순 아이디어로 개발할 경우 quality가 떨어져 솔루션으로서 가치를 이야기할 수 없는 경우라고 생각할 수 있습니다. 어떤 경우에도 솔루션 성격을 띄는 제품이나 서비스는 핵심 문제를 해결하려면 중요한 요소는 있게 마련이고 그중 아이디어가 필요한 복잡한 요소를 찾는 것은 가장 중요한 과정 중 하나라고 볼수 있어요. 문제를 인지하면 생각을 거듭하고 또 모을 수 있기 때문에 해가 되는 아이디어가 나오기 마련이니까요. 

O&KR 가설과 검증, 그리고 실제 적용

O&KR, 가설과 검증 구글이 전통적인 관리 기법은 모두 거부했지만 O&KR(목표와 핵심결과) 방식은 채택했다는 것은 잘 알려져 있는데 엄청난 인재들을 모아두고 불필요한 간섭을 하기보다는 스스로 목표를 설정하는 최소한의 관리 원칙만 두겠다는 것이었다고 생각한다. 목표 설정은 생각의 방향에 관한 것이니까 전반적으로 어떤 방향으로 갈 것인지가 어느 정도 연결되도록 하는 것이 핵심이고 그외에는 자율적으로 판단할 수 있게 했다고 생각할 수 있다. 목표 설정 외에 핵심 결과를 지표로 두는 것은 과학적 사고의 핵심과 연결된다고 생각하는데 구글에서는 핵심 결과 즉, Key Results를 평가 지표로 생각하지 않았고 스스로 목표를 구체화하는 검증 방법으로 바라보았다. 검증할 수 없는 추상적 목표를 검증 가능한 구체적 결과물로 리타겟팅하여 사고할 수 있게 해주는 것으로 가설과 검증에 관련된 과학적 사고 기법과 연결된 관리 방식인 셈이다. 물론 O&KR의 핵심 결과는 엄밀한 검증을 위한 것은 아니다. 목표를 직간접적으로 측정할 수 있는 방법을 설정하는 것이며 목표를 정량화한다기보다는 목표의 수준 혹은 개인적 방향을 간접적으로라도 계량할 수 있는 숫자이면 충분하다고 본다. 구글의 가이드라인을 보면 너무 쉬운 목표가 되거나 너무 어려운 목표가 되지 않도록 개인이 판단하기에 60~70% 달성을 목표로 할 수 있는 수치를 잡으라고 권고한다.  분기별로 알아서 업데이트하는 방식으로 최소한 분기별로는 한번 더 목표를 구체적으로 생각할 수 있게 해서 중점적으로 생각하는 방향을 스스로 관리하는 관리 방법이라고 할까. (O&KR을 평가 지표로 사용하는 경우도 있는데 그런 경우에는 좀더 KPI에 가까워지리라고 생각한다.) 우리는 과학이란 용어를 쉽게 사용하면서 검증을 게을리하는 것을 종종 본다.  과학이 절대적인 답을 주는 경우는 그렇게 많지 않다. (어쩌면 그것이 과학과 수학의 차이점일지 모르겠다.) 요즘은 데이터가 모든 것이라는 슬로건과 함께 데이터 중심이란 말

매니저의 역할

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

지능

이미지
 지능을 이루는 건 크게 두 가지밖에 없는 것 같아. 하나는 집중의 수준과 지속력. 하나는 끝까지 목표를 향해 물고늘어지는 추진력. 첫번째는 타고 나는 것도 상당한 것 같고 학습을 통해 강화하는 것도 맞고... 두번째는 인생이 길기 때문에 더 중요한 ...  

백발이 성성한 코더는 아름다운 꿈일까

이미지
image from  xkcd.com 나이가 들어도 코딩을 할수 있는 건 맞지만 단순히 코딩 능력의 관점에서만 본다면 능력이 감소하는 것도 맞다. 미국에서 볼수 있던 백발을 휘날리는 코더는 대부분 COBOL 개발자들이었겠지만 실리콘밸리의 미래에 중장년의 코더가 어떤 역할을 할지는 모르겠다. 내 생각에 코더로서의 전성기는 사람마다 다르겠지만 40대 후반(45~48 무렵)이 아닌가 싶다. 코딩에 필요한 여러 경험의 축적에 따른 판단 능력을 충분히 고려해서 꾸준히 자기 관리를 학습과 체력면에서 가꾸어왔을 경우를 가정했을 때. 코딩이란 게 단순 개발을 뜻하는 건 아니므로 아키텍처나 질적 관점, 소통 능력, 협업 능력 등등을 고려했을 때 관리 측면과 개발 측면을 분리해서 개발 측면만으로 볼 때 이런 판단을 할수 있다. 성과 위주 관점에서는 순수 개발 역할만 하는 이의 나이는 관리를 잘하더라도 한계가 온다는 뜻이다. 직업적 운동 선수가 나이 한계가 있듯이. 한계는 경험적으로 보면 아무래도 집중하여 판단할 수 있는 시간이 줄어드는 데 있다. 장시간 집중해서 상세 판단을 하는 능력은 떨어질 수밖에 없다. 흔히 말하듯 추상 능력의 향상이 보완할 수 있을텐데 그 추상 능력이란 젊은 친구들보다 훨씬 더 오랫동안 판단을 거듭한 이들이 당연히 가지는 결과물인 거라고 생각된다. 그렇게 관리하지 못한 경우는 오히려 사고의 가소성 부족으로 학습 능력이 떨어지고 소통 능력도 떨어져서 급격하게 코더로서 부적격해질 우려도 있다. 꾸준히 학습하고 자기 관리를 한 경우 코딩 속도나 판단 능력에서 급격한 저하는 없다. 다만 더 좋아지기 어렵다. 나이가 든다고 개발 일을 못할 건 아니다. 하지만 굳이 개발 일을 시니어에게 맡기는 시장은 훨씬 좁기 마련이다. 경험과 협업적 코칭 등 단순 개발 관점 이외의 요소들이 필요한 시장인데 젊은 친구들과 소통하는 건 매우 도전적인 일이기도 하다. 세대간 문화의 차이를 무시할 수 없는데 개발 조직은 젊은 친구들의 문화를 기준 규범으로 상당 부분 기초해야 하고 어떤