윤경구의 Log on Java

제1원리 기반 사고, First principle thinking. 첫번째 원리로부터 생각하기 혹은 제일원리 기반 사고 정도로 해석할 수 있겠다.  아리스토텔레스가 형이상학이란 책에서 언급한 것으로 더 이상 추론될 수 없는 원칙에서부터 추론되어야 한다는 원칙이다. 예를 들어 Unmoved mover 즉 우주에 최초의 움직임을 만든 무언가는 움직임이 없었어야 한다는 추론이 이러한 원칙 하에서 추론된 것이다. 수학에서 공리에서 출발하는 것과 같은 논리인데 일론 머스크가 SpaceX를 만들면서 제일원칙에 기반한 사고 실험을 사용하였다고 언급하면서 의사결정의 원칙 혹은 문제해결의 방법론으로서도 많이 언급된다. 일론 머스크의 First Principle Thinking 머스크 이야기는 이렇게 시작된다. 화성에 가야겠다고 목표를 세운 머스크가 첫번째 마주한 문제는 천문학적인 로켓 가격이었다. 머스크는 물리학에서 배운 제1법칙 기반의 사고를 이 문제 해결에 적용하기로 했다. “물리학은 유추가 아닌 제1원리로부터 추론하는 것을 가르쳐준다. 좋다, 제1원리들을 한번 들여다보자. 로켓은 무엇으로 만들지?  우주항공산업 등급의 알루미늄 합금들과 약간의 티타늄, 구리, 탄소 섬유이다. 다시 생각해봤다. 일반 상품 시장에서 이 물질들 가격은 얼마쯤 하나? 로켓에 사용되는 재료들 가격은 로켓 일반 가격의 약 2%에 불과했다.” 머스크는 원 재료를 사서 직접 로켓을 만들기로 했고 SpaceX를 세웠다. SpaceX는 1/10 가격으로 로켓을 만들면서도 수익을 내고 있다. 제1원리 기반의 사고를 머스크는 진실이라고 생각되는 좀더 근원적인 부분으로 내려가서 거기에서부터 다시 의사결정에 이르는 논리를 쌓아올리는 문제 해결 과정으로 적용한 것이다. 진리와 근원적 사고 사람은 수많은 참으로 믿은 불확실한 가설들이나 관성으로부터 판단하는 경향이 강하므로 중요한 의사결정을 좀더 근원적인 진위로부터 추론하는 것은 더 나은 해결 방법, 더 높은 진위 추정의 확률을 위해 매우 유용한 방법...

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

관리는 정적인 프로세스가 아니다 팀장의 역할은 이러하고 프로세스는 이래야 하고 ... 관리를 정적인 형태로 이해하는 경우 흔히 나오는 이야기이다. 실제로 관리자가 조직 성원들 간에 기술적인 의사 결정을 하는 것을 절차적인 부분만 생각해서 round-robin, random, expert 등에게 맡기는 경우도 있고 혹은 위계 조직답게 일방적으로 결정하고 지시만 하는 경우도 많다. R&D 조직은 기술적 검증을 보통 조직 성원이 1차 진행하므로 의사 결정과 검증이 분리되는 현상은 의사 결정의 오류를 키울 가능성이 높다. 하지만 개인이 완벽하게 검증한 내용 기반으로 의사결정 하는 것은 일반적으로 더 나은 결정을 가로막을 가능성이 크다. 특히 각이한 수준, 각이한 경험의 개인들이 항상 조직 관점에서 최선의 선택을 하기는 쉽지 않다. 매니저는 상대적으로 더 많은 정보를 접하는 허브 역할을 하기 때문에 정보 접근성 관점에서 보더라도 앞에 설명한 다양한 의사결정 규칙은 적은 정보로 결정을 요구하게 되므로 큰 오류가 있다. 일방적 의사결정 경험적으로 최악의 매니저는 의견을 청취하지 않고 지위를 사용하여 결정하는 유형이다. 기술 회의의 의견은 기술적 관점이어야 하나 지위를 발언권으로 이해하고 아무 얘기나 마구 해서 실질적인 회의의 집중과 심화를 훼방하는 습성을 가진 경우다. 기술적 의사 결정을 위한 회의가 딱딱할 필요는 없고 다양한 의견을 폭넓게 듣기 위해 범위를 가능하면 제약하지 않는 게 좋지만 습관적으로 생각 없이 말을 하는 습성은 여러 사람의 시간을 낭비하게 하는 큰 장애물이다. 의사 결정에서 지위는 물론 존중되어야 하지만, 청취를 통해 더 나은 지식과 아이디어를 의사 결정의 근거로 만들지 못하는 것은 최악의 권위적 결정이 되고 이 과정에서 배제된 부원들은 점점 더 흥미를 잃고 수동화되고 성취욕이 강한 친구들은 능력을 발휘할 수 있는 곳을 찾아 조직을 떠날 것이다.  의견을 청취하는 것은 어려운 기술은 아니지만 훈련없이 그냥 얻어지진 않는다. 의견을 이해하고...

해커스 - Heroes of the Computer Revolution 해커스는 소프트웨어, 하드웨어 해커의 출현을 추적한 기록이다. 가장 중요한 것은 해커들의 원칙인 "직접 해서 보여라"라는 제일의 원칙이라고 할 수 있다. Access to computers should be unlimited and total. Always yield to the Hands-On Imperative! 컴퓨터가 대중화되기 이전 시기에서 대중화를 이끌었던 여러 뛰어난 해커들의 생각들, 그리고 그들이 추구한 원칙들 중 유의미한 부분이 무엇일까 다시금 생각해볼 필요가 있다. 책에 나오는 대목들 중 인상깊었던 부분들, 그리고 몇 가지 생각들 30시간 단위로 하루를 살아가며 해커로 늙어갈 수 있을까? "저는 정말로 자랑스러웠습니다. 밤낮없이 해킹한다는 사실이 말입니다. 해가 떴는지 달이 떴는지 상관하지 않았죠. 자다 일어나 밖이 어슴푸레해도 새벽인지 초저녁인지 몰랐습니다." 하지만, 이런 생활을 영원히 계속할 수 있을까? 실전 스타일의 해커들이 가장 퍼포먼스가 좋았던 상황은 혼자 있는 방은 아니었던 것 같다. 조금은 웅성대는 까페 같은 분위기랄까? 저는 미적인 목적으로 칩을 줄이려고 애씁니다. 또한 제가 똑똑하다고 생각합니다. 칩 줄이기는 제가 즐기는 퍼즐이며, 제 설계는 지금까지 나온 보드보다 칩을 하나 덜 씁니다. 저는 더 빨리, 더 작게, 혹은 더 영리하게 하는 법을 궁리합니다. 뭔가를 구현할 때 명령 6개가 괜찮다고 여겨지는 수준이라면 저는 5개나 3개에 도전합니다. 정말 잘하고 싶을 때는 2개에 도전합니다. 저는 평범하지 않은 기교를 씁니다. "모든 문제는 평범한 방식 말고 다른 각도에서 생각하면 더 나은 해법이 나옵니다." 그리고 저는 이런 해법을 발견합니다. 매일 여러 문제를 접할 때 우선 하드웨어 문제인지 자문한 후 과거에 썼던 기교를 하나씩 떠올립니다. 카운터와...

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은 다음 여섯 가지 특성을 악제(惡題)에 고유한 특성으로 보았다. ...