윤경구의 Log on Java

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

오랜 SW 연구개발 경험 상 나름 이런 감(symptom)의 원칙 이 있다. 원래 시스템 소프트웨어란 건 wicked problem이어서 완벽한 정답이란 건 없고 enough한 시점에서 결론을 내려야 한다. 하지만, 좋은 답이란 것은 약간의 징후가 있다. '계속 고민하던 기술 문제의 직접적인 연장선에서 내려진 결론이라면 창의적인 결론이거나 멋진 결론이 되기는 어렵다. 계속 고민하던 논리의 옆쪽에서 툭 튀어나와 와르르 내려지는 결론이 언제나 아름다운 결론이다' 왜냐하면 직접적으로 추론되는 논리는 아무리 기술적이라 하더라도 누구나 쉽게 추론할 수 있는 것이며 새로운 혁신이 들어가기 어렵다. straightforward한 건 어려운 기술이라 하더라도 가치가 크지 않다. 그래서 마치 깊이 반복해서 고민하다 옆의 둑이 작은 바늘구멍에서 물이 새어 터지듯 나오는 아이디어가 훨씬 더 나은 답인 경우가 많다. 빅데이터 기술을 처음으로 본격적으로 다루다 보니 근 15년 정도 걸쳐 발전한 기술들을 3주만에 압축적으로 이해하려다 보니 어려움이 많았다. 이 기술들을 들여다보면 놀라운 경우가 많은데 상위 계층으로 갈수록 hype이 섞인 경우가 많다. 새로운 기술을 받아들일 때 나름 스스로 이해의 수준을 판단하는 잣대가 있는데 이것도 일종의 enough와 감이라고 할 수 있다. '새로운 기술은 그 장점의 이유 뿐만아니라 그 단점까지 볼 수 있을 때 비로소 이해했다고 할 수 있다. 장점만 보이면 그것은 이해한 게 아니라 그냥 시키는 대로 공부한 것이다.' 이것은 critical thinking의 문제이다. 엄밀한 사고란 critical point를 인지할 수 있어야 하고 이 문제를 해결할 때 다른 critical point를 생각할 수 있어야 한다. 이때 system thinking이 중요한데 system이란 layer 간의 혹은 전체와 부분 간의 관계를 유기적으로 파악하는 것이다. 예를 들어 소프트웨어를 시스템적으로 이해...