윤경구의 Log on Java

WebSocket  프로토콜은   하나의  tcp ( 실제로는  http  확장   형태 )  소켓으로   여러   개의   논리적   연결인   세션  개념을   지원한다 . 그런데  tcp  레벨에서   같은   연결을   사용하기   때문에   논리   세션은   각   특성에   따라   효율적이기   어렵다 .  적당한   크기의   프레임이란   메시지   단위로   잘라서   여러   세션   메시지를   섞어   보내다보니   원래는   하나의   양방향   큐를   구성하는  tcp  연결을   다시   에뮬레이트해야 해서   오버헤드가   있다 . 자바   웹소켓   스펙을   보면   메시지   유형이   스트림이면   큰   메시지라고   간주하여   매   프레임별로   별도의   쓰레드로   보내고   그렇지   않으면   하나의   쓰레드로   보내게   되어있는데   나는   이   스펙은   지나친   쓰레드   모델과   메시지   유형의   커플링이라고   본다 . 오히려   큰   파일일수록   순서대로   하나의   쓰레드에   큐로   보내고   작은 ...

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

(작은 에피소드였지만 흔히 접하게 되는 일이다.) " 웹크롤러 사용해서 데이터 수집이 일주일 걸리던 것을 멀티 쓰레드로 돌려서 1일 걸립니다. 멀티 쓰레드로 바꿀 때 concurrency 문제를 해결하기 위해 O(1) 복잡도를 가진 CopyOnWriteArraySet을 사용하였습니다." 이런 뿌듯한 발표를 듣고 너무 답답했다. 물론 O(1) 복잡도도 완전히 틀린 얘기이고 (아마도 array list의 배열 색인 접근 시 연산 복잡도를 잘못 본듯) 배열을 중복 허용하지 않은 기반 자료구조로 쓰기 때문에 조금만 커져도 접근이든 삽입이든 엄청 느리겠지만 무엇보다 concurrent 자료구조이다. COW는 빈번하게 변경이 여러 쓰레드들간에 걸쳐 발생하는 상황에서는 전혀 적합하지 않다. Concurrency 문제가 개별 연산 복잡도보다 훨씬 지배적인 상황이다. 하지만 개별적인 오류는 차치하고 성능 최적화를 할 때에는 병목이 무엇이고 시스템 자원이 포화가 되는지를 기준으로 판단해야 하는데 전혀 고려되지 않는다. 네트웍 대역은 아직 널널하고 CPU 자원도 별로 일을 하지 않는데 (물론 자료구조와 concurrency logic을 잘못 선택해서 좀 많이 낭비하긴 한다) 기준 시간이었던 7일(너무 naive한 구현)이나 개선한 1일이나 큰 의미가 있을까. Enough 라는 기준을 만족하면 되 는데 하루라는 시간이 어떤 경우에 만족이 될까. "시스템 자원을 70~80%까지 활용도를 높였는데 더 이상은 기존 로직을 세부 변경해야 해서 성능 때문에 논리 가독성을 포기하는 것은 희생이 커서 이만큼만 튜닝했어요." 이런 결론이 나야 하지 않을까. 학교마다 다르긴 하지만 많은 수도권 대학에서도 이제 운영체제와 같은 시스템 과목은 잘 가르치지도 않고 학생들이 수강하지도 않는다고 한다. 자바와 python, 웹 프로그래밍 중심의 대학 과정이 실용성의 이름으로 이루어진다. 놀랍게도 코딩만 가르쳐서 청년 실업을 해결하겠다는 움직임도 보이는데 인공지능 시대 소...

 2015년 11월 17일에 발표했던 스프링 프레임웍 Spring Framework - Inversion of Control Container from Kyung Koo Yoon

 2019년 7월에 강의했던 쿠버네티스 자료 Kubernetes from Kyung Koo Yoon