윤경구의 Log on Java

정말 오래간만에 자바 관련한 블로깅입니다. 불편한 사람들이 있을 것 같아서 정보 공유 차원에서 현재까지 파악한 이슈를 남깁니다. macOS Catalina(10.15.3) 버전부터 JDK의 System.loadLibrary를 통한 dylib 파일 로드가 실패합니다. 이와 관련해서는 크게 두 가지 문제가 관련되어 있습니다. 1. System.loadLibrary 버그 공식 JDK 관련 이슈는 다음 이슈에서 볼 수 있습니다. Java Bug System :  System.loadLibrary fails on Big Sur for libraries hidden from filesystem GitHub :  System.loadLibrary fails on Big Sur for libraries hidden from filesystem System.loadLibrary()를 통한 경로 찾기가 실패하는가 하고 여러 시도를 해보면 곧 System.load()를 통해 dylib 파일을 직접 읽어도 제대로 동작하지 않는다는 것을 알게 될 것입니다. JDK 라이브러리 로딩 버그의 원인(아직 미해결)을 옮겨봅니다. System.loadLibrary 실패 원인 문제 설명:  OSX Big Sur no longer ships with copies of the libraries on the filesystem and therefore attempts to load a native library via System.loadLibrary no longer works. 애플 페이지 내용: New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attem

이 글은 2021년 3월 13일에 페이스북에 올렸던 글이다. 창업은 소프트웨어 기술을 활용하여 산업을 재정의한 것 얼마전 창업은 소프트웨어 기술을 활용하여 기존 산업을 재정의하는 것이고 기존 산업을 유지하는 법규와의 충돌은 필연적이라는 이야기를 들었다. 소프트웨어나 인공지능 등 기술의 발전을 활용하여 기존의 산업 전반을 완전히 바꾸는 것이 현 시대의 창업 개념이고 이를 가속화하기 위해 법규의 재해석과 개정은 불가피하다는 것. 물론 기존 법규가 무조건적으로 배척될 이유는 없을 것이다. 사회적 가치, 인간애적 가치를 전제한 가치의 관점을 가질 필요가 있고, 자동화, 가속, 정보 집중에 의한 더 지능적인 의사결정에 기반하여 새로운 산업을 만드는 것이 누구에게 가치를 줄 수 있을까 혹은 정말 가치로운 일인가를 스스로와 대중에게 설득해야 하는 건 역사적으로도 늘 새로움을 추구하는 이들이 감당해야 할 의무처럼 주어진 것 같다.  협업과 문제 해결을 확장하는 창업 어제 신입 사원들이 부서로 배치되었다. 늘 개발자는 가치를 만드는 게 직업인 사람이며 이 부서(기업 R&D 조직)의 미션은 개발이 아니라 소프트웨어 전문 지식을 기반으로 한 문제해결이란 점을 강조하는 편이다. 나혼자 개발만 잘하면 된다는 생각이 강하면, 문제를 풀기 위해 학습하고 협업하는 과정을 학습하지 못한다. 새로운 문제를 찾으려 하지 않고 더 나은 아이디어를 찾는 노력을 하지 않는다. 이미 잘 알고있는 문제를 잘 알고 있는 기술로 빠르게 찍어내는 게 목적인 시스템 통합 프로젝트처럼 개발을 이해한다면 소프트웨어적 혁신은 애시당초 불가능하다. 물론 벨 연구소에서 유닉스가 탄생한 과정에서 보듯이 정말 똑똑한 사람들은 부서의 목적이 분명하지 않아도 목적에 구애받지 않는 혁신들을 만들어낸다. 우스개로 똑똑한 해커들을 한동안 컴퓨터만 주고 가둬두면 유닉스 비슷한 운영체제를 만들거라는 이야기가 한동안 떠돌기도 했었다. 하지만 그렇게 창업은 할수 없을 것이다. 스티브 잡스가 얘기한 것처럼 해커와 기업가 정신의 결합

개발자들은 '일단 안돼'라고 말한다 보통 이런 얘기를 들을 일이 없는데 개발자가 아닌 분들과 얘기하면 이런 얘기를 듣는다. '무조건 안돼' 족이 있고 '무조건 돼' 족이 있다고... (둘 다 말이 안되는 건데 ^^) 실제 개발자들은 자신이 개발하고 있는 모듈의 변화를 좋아하지 않는다. 부담스러워 한다. 해야 할 일이 갑자기 생기는 것에 대해 부담스러워 하는 것도 있고 업무 자체가 좀더 깊은 집중을 요구하는 성향이 있어 일련의 인터럽트에 즉자적으로 반응하는 성향도 학습된다. 그럼에도 함께 제기된 문제에 대해 문제 해결을 위해 토론하고 분석하는 시간을 들이는 것은 마다하지 않는다. 두 가지 허들을 풀어야 한다. 하나는 갑자기 던지면 숙고를 거친 반응이 나올 수 없다는 것 또 하나는 중요한 자신의 업무인 이해 당사자이기 때문에 이해 관계를 내려놓고 판단하기 쉽지 않다는 것 첫번째는 좀더 시간을 주고 문제를 여러번 remind하여 enough thinking 후에 답을 구하는 게 방법이라고 볼 수 있는데 두번째는 좀더 까다롭다. (그런데 이 이해 관계란 이 개발자의 업무 로드가 증가하는 부분이므로 이 의사결정의 주제 관점에서만 보면 크게 중요하지 않은 요소일 수 있다.) 많은 한국의 소프트웨어 개발 회사는 개발 조직이 계층 구조를 이루고 있다. 가장 잘 아는 사람이 개발자인 매니저이고 심지어 핵심 모듈을 개발하기도 한다. 의사 결정에 주요한 권한을 행사하는 사람이 직접적인 이해당사자인 개발자인 경우가 많다는 것이다. 물론 훈련을 통해 개선된다. 업무 로드에 대한 관점, R&R에 대한 관점은 내려놓고 의사 결정 후에 별도 주제로 다루는 게 일반적으로 가능하다 그런데 한 가지 요소를 더 생각해보자면, 풀고자 하는 문제가 무엇인가에 따라 좀더 많은 전문 정보를 공유하고 의사결정의 원칙을 잘 찾는 것이 좋은 의사 결정의 핵심 요소일 텐데 과연 개발자가 문제를 해결하는 전문 정보를 충분히 갖고 있는가, 의사결정의 원칙을 학습을