윤경구의 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, 웹 프로그래밍 중심의 대학 과정이 실용성의 이름으로 이루어진다. 놀랍게도 코딩만 가르쳐서 청년 실업을 해결하겠다는 움직임도 보이는데 인공지능 시대 소...

Open Source Software에 대한 여러 가지 찬반이 있는데 어느 한쪽 방향으로 판단하기는 쉽지가 않다. 공개라는 점은 공유를 전제로 한다. 오픈 소스 운동이 공개를 통해 공유의 범위를 넓힘으로써 소프트웨어 혁신의 출발점 수준을 넓혀온 점은 분명하다. 그런 반면 소프트웨어 저작 활동이 지식 노동이기 때문에 지적 노동의 가치를 어떻게 할 것인가 하는 측면에서는 여러 가지 복잡한 관점이 뒤섞인다. 많은 경우 단순히 기부의 관점으로 바라본다. 지적 노동을 공유 자산화하는 관점이다. GPL, LGPL, Apache/BSD License 등은 분명 그러한 측면이 강하다. 자산을 사적 이익으로 파생화하는 것을 허용하느냐 안하느냐의 관점 차이가 있지만 이렇게 공개된 소스들이 다수의 이익을 위한 기부가 된다는 점은 동일하다. 다만 그 기부가 개인적 기부인지 혹은 상업 회사가 고용한 저작의 기부인지의 차이는 있다. 하지만 이렇게 노동이 보상되지 않는 기부라면 직업적 노동으로는 한계가 있다. 소프트웨어 저작이 직업화되지 않고 기부 활동에 그친다면 그것은 오히려 새로운 소프트웨어 혁신을 저해하는 것 아닌가. 순수한 잉여 시간 노동의 기부를 하는 전문 소프트웨어 엔지니어가 있고, 또 상대적으로 직업적 압박으로부터 자유로운 학생들의 적극적인 기부도 있다. 그외에 상업적 이익을 간접적으로 올릴 수 있는 구글 같은 기업도 적극적으로 공개 소프트웨어 활동을 통한 지적 노동의 기부에 참여한다. 애플, 오라클, IBM과 같은 전통적인 소프트웨어 기업들은 공공재화된 공개 소프트웨어들을 활용하고 또 일부 기부를 통해 공개 소프트웨어의 결과물들을 자신들이 원하는 방향으로 이끌기 위한 활동을 하기도 한다. 기부가 아닌 경우도 존재한다. 일부 제한된 기능에서만 활성화된 커뮤니티를 통해 협업적으로 기부를 하고, 핵심 기능들은 상업용으로 비공개하는 방식을 통해 제한된 커뮤니티 버전만 기부하고 그 커뮤니티를 주도적으로 이끌며 상업용 버전은 판매함으로써 커뮤니티...

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