윤경구의 Log on Java

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

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

최근 릴리스된 Java 15 버전의 new feature를 보다가 깜짝 놀람. JEP 374: Disable and Deprecate Biased Locking Biased locking은 실제로는 synchronized를 통해 lock을 쓰고 있으나 single thread에서 실행되는 경우가 더 많다고 가정하여 이 경우는 lock 오버헤드 없이 실행되도록 자바의 내부 스택에 상태 필드를 유지하는 방식의 최적화이다. 기존 JDK의 util 클래스들이 기본적으로 synchronized를 하도록 구현되어 있었기 때문인데 그후 sync 없는 클래스들이 API에 대부분 추가되었다. 하지만 여전히 java.io 패키지의 스트림 클래스들은 그대로이긴 한데 실제로는 IO를 하지 않는 ByteArray...Stream 같은 류는 biased locking의 여전한 수혜자이고 예전 API 기반으로 설계되어 Hashtable, Vector, Properties 같은 클래스를 인자로 받는 경우도 마찬가지이다. 물론 biased locking은 contentio n이 발생할 때에는 오버헤드가 있다. 이런 낙관적 최적화는 어느쪽이 더 전형적이냐가 분명할 때 효과가 있다. Java 15에서 biased locking을 제거하면 기존 코드들 중 이건 biased locking 덕분에 큰 차이가 없어 하고 넘어갔던 코드들이 모두 영향을 받을 것이다.  15년 가까이 biased locking을 전제로 decision을 했던 터라  약간 난감하다. 물론 가능하면 StringBuilder,ArrayList 등을 쓰는 건 당연했지만 약간 API적으로 선택이 모호한 경우에는 biased locking을 고려하여 lock free 모듈을 만들지 않고 넘어갔던 경우가 계속 떠오른다. (ByteArray stream 같은 경우는 별도로 Lite 클래스를 만들어 쓰긴 했지만 항상 그럴 수 있었던 건 아니다) 제거를 결정한 근거는 대부분 코드들이 lockfree new API로 옮겨갔다는점과 conte

GraalVM의 Native Image가 리눅스 컨테이너에서 Spring Boot 기반 서비스들을 실행하는 데 점점 더 많이 사용되는 이유 중 하나가 메모리 footprint가 기존 서버 JVM처럼 미리 Heap을 전체 할당하는 방식이 아니라는 것일듯. 참고 : Quarkus - SUPERSONIC SUBATOMIC JAVA A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.  GraalVM의 Native Image는 SubstrateVM이라는 유사 JVM(?)을 사용하는데 그야말로 기판에 사용되는 자바 모듈들을 AOT 방식으로 컴파일해서 붙여가는 방식이라서 이렇게 이름을 붙인듯. -Xmx 기본값이 unlimited 이다. 와우! SubstrateVM은 closed world라는 전제로 만들어졌는데 런타임에 사용되는 모듈들은 빌드 타임에도 알 수 있다는 전제이다. 그래서 동적으로 로드되는 자바 코드나 JNI 코드나 다 찾아서 빌드 타임에 미리 함께 빌드되도록 옵션 처리해줘야 한다. 한마디로 상당량의 삽질이 기본 전제된다. ㅠㅠ 그런데 점점 더 활용도가 높아져서 많이 쓰는 모듈들은 (JVM 런타임을 포함해서) 분명 누군가가 이 삽질들을 해놓았을 거라고 기대할 수 있다. 내가 짠 모듈들만 잘 챙기면 많은 경우 해결이 될 것이란 기대... 게다가 graalvm native image는 polyglot이다. 아직 실험적이지만 R과 python 코드를 컴파일할 수 있다. numpy와 pandas 패키지를 포함해서... 서버뿐 아니라 클라이언트 프로그램으로도 java를 좀더 잘 활용할 수 있게 되었다. 대부분 관심이 없겠지만(!) 이제 JavaFX로 작성한 프로그램을 GraalVM Native Image로 쉽게 컴파일할 수 있게 되었다. 윈도우에서 하나의 exe 바이너리로 쉽게 빌드할

  마틴 파울러가 짧은 강의를 통해 소프트웨어 아키텍처란 the important stuff 라고 정의한다. 아키텍처는 두 가지 측면을 가지고 있다고 하는데 "이해를 함께 해야 할 부분"이자 "변경이 어려운 부분"이라고. 이 두가지가 합쳐져서 "중요한 무언가"를 이루는데 이것을 아키텍처라고. 공감하는 부분도 있지만  소프트웨어 아키텍처를 너무 컴포넌트 중심으로 바라보는 것 같다. 시스템 구조적 측면을 단순히 컴포넌트로 보기는 어렵다. 구조의 측면을 고려하면 무조건 변경이 어려운 것은 아니다. 사실 시간의 기준으로 보면 그렇게 어려운 게 아니고 어렵다는 것을 마틴의 얘기 중 하나인 "지식의 깊이"로 보면 맞다고 볼 수 있다. "지식의 깊이"를 가진 사람들이라면 아키텍처는 하나의 aspect처럼 간주될 수 있다. 물론 비즈니스 로직은 잘 동작하고 최소한의 가독성을 가진 코드들로 구성되어 있다는 가정 하에서. 아키텍처는 리팩토링처럼 일상적일 순 없지만 계단식 개선이 간헐적으로 발생해야 하는데, 시간적 관점에서도 hard to change이면 그 소프트웨어의 품질은 나오자마자 이미 한계에 달한 것이 된다. 소프트웨어나 서비스의 아키텍처 측면 품질은 매우 중요한 결정적 요소가 되기 쉬운데 이를 개선하기 위해서는 개발 조직은 아키텍처를 이해할 수 있는 지식의 깊이를 갖춰야 한다고 단순 결론을 내릴 수 있다.

WebSocket  프로토콜은   하나의  tcp ( 실제로는  http  확장   형태 )  소켓으로   여러   개의   논리적   연결인   세션  개념을   지원한다 . 그런데  tcp  레벨에서   같은   연결을   사용하기   때문에   논리   세션은   각   특성에   따라   효율적이기   어렵다 .  적당한   크기의   프레임이란   메시지   단위로   잘라서   여러   세션   메시지를   섞어   보내다보니   원래는   하나의   양방향   큐를   구성하는  tcp  연결을   다시   에뮬레이트해야 해서   오버헤드가   있다 . 자바   웹소켓   스펙을   보면   메시지   유형이   스트림이면   큰   메시지라고   간주하여   매   프레임별로   별도의   쓰레드로   보내고   그렇지   않으면   하나의   쓰레드로   보내게   되어있는데   나는   이   스펙은   지나친   쓰레드   모델과   메시지   유형의   커플링이라고   본다 . 오히려   큰   파일일수록   순서대로   하나의   쓰레드에   큐로   보내고   작은   프레임들이면   알아서   처리하라고  worker 로   보내거나   했어야  정상적인  ( 효율적인 )  처리   구조일   것   같고   아니면   그냥   열어뒀어야   할것   같은데  Java EE  스펙에서   과도한   개입을   해서   망친   듯 . 그런데  websocket 과   같이   여러   개의   논리   연결을   위해   하나의   물리   연결을   사용하는   것   자체가   효율적인   발상은   아니다 . tcp 의 내부   최적화를   깨는   형태가   되는   셈이니 ... 그저   브라우저가  http  연결하면서   서버로부터     push  메시지   받는   용도로만   제한적으로   쓸   일이지 ... 생각해보니  일전에 본 용례는  http 로  passive connection 을   못   만들어서  

관리는 정적인 프로세스가 아니다 팀장의 역할은 이러하고 프로세스는 이래야 하고 ... 관리를 정적인 형태로 이해하는 경우 흔히 나오는 이야기이다. 실제로 관리자가 조직 성원들 간에 기술적인 의사 결정을 하는 것을 절차적인 부분만 생각해서 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

신입 사원들이 들어오면 가장 먼저 하는 것 중 하나가 아주 간단한 프로그램을 작성해보도록 숙제를 내주는 것인데 코딩을 해본 경험이 적은 이들에게 목표를 주고 그 목표에 따라 소프트웨어 코드를 작성하는 것은 매우 중요한 일이다. 물론 회사 뿐만아니라 학생의 경우에도 처음은 있다. 경험적으로 첫번째 아주 짧은 코딩 과제는 Tic-tac-toe나 사다리 게임을 주는 편이다. 보통 학생에게 가이드한다면 다음과 같이 접근을 한다.

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

개발자보다 관리자 역할을 더 중시하게 된지도 10년쯤 되었다. (그전 10년도 관리자였지만 미안 ㅠㅠ) 지적 노동의 관리자로서 가장 중시하는 것은 어떤 문제에 부닥치든 "어떤 일이든 더 나은 아이디어가 있다고 생각"하느냐이다. 직접적으로 사람과 조직의 생각들이 열려있냐를 보게 되고 막다른 골목에 다다라서도 더 현명한 접근법이 있을수 있다고 생각하여 사람들을 불러 조언을 구하고 토론을 하게 되고 개인의 아이디어보다 토론과 서칭 등을 통해 더 많은 아이디어를 구하게 되고 의사결정에서도 wicked problem의 룰을 따라 숙려의 시간에 따른 충분한 의사결정을 하고 실행 과정에서 다시 조정하는 것을 기본으로 삼게 된다. 물론 지적 노동이니만큼 아이디어를 낼수 있는 사람들의 성향도 중요하여 조직 운영도 의견을 내는 걸 어려워하지 않게 해야 하고 개인들이 생각을 많이 하도록 goal setting도 해야 하고 코칭도 필요하고 ... 그러다보니 개인들의 소통 능력을 가장 중시하고 ... (물론 지적 노동의 특성 상 개인들의 능력도 중요하게 생각하지만 그것은 아이디어의 깊이와 횟수에 대한 확률이라고 생각하기 때문에 소통 능력이 떨어지면 다른 사람들을 이해시키지 못하고 또 일회성 아이디어를 다중의 조언을 통해 개선할 기회가 적기 때문에 소통 능력 다음으로 생각한다) 조직의 문화적 측면도 매우 중시한다. 목적을 중시하고 누구나 쉽게 의견을 제시하고 빠르게 오류를 인정하고 등등 하나의 의견이 더 나은 의사결정의 seed가 될 수 있도록 하는 데 신경을 많이 쓰는 편이다. 소통 능력이 떨어지는 친구들은 대부분 설득이 가능하다고 생각하는데 (업을 같이 하는 곳에서는 의도부터 나쁜 사람은 없다..) 굳이 안되는 사람들은 과감하게 배제해서 문화적 리스크를 줄인다.