솔루션은 무엇을 자동화하고 무엇을 기록해야 하나? 기업 업무 프로세스 관리에 대한 생각

약 20년 전에 BPM 솔루션을 만들기 시작했었는데 그때에는 어떻게 하면 사용자(기업 고객)가 개발을 할 필요없이 (혹은 최소화하도록) 솔루션에서 자동으로 코드를 생성하거나 간단한 룰로 처리하려고 많은 노력을 했다. 몇일 전에 30년만에 만난 대학 후배의 회사에서 후배가 10년에 걸쳐 만든 회사 솔루션을 봤는데 같은 문제를 핵심 메타 정보 중심으로 쉽게 관리해주고 탑레벨의 일들을 굳이 실제 업무랑 연동시키지 않는 방식으로 문제를 풀었다. 그런데 그 후배의 솔루션이 내겐 약 15년 가까이 이전 직장에서 고민했던 합리적인 풀이로 느껴졌다. 탑레벨에서 실제 구현까지 모든 걸 연결하면 오히려 다양한 변화를 쫓아가기 어렵다. 사람의 아이디어와 의사결정 변화를 바로 반영하려면 시스템적으로 실행을 엮으면 오히려 어려워질 수 있다. 자동화가 사실 인간의 의사결정 능력을 대체힐 수 없다는 점에서 잘못된 목표를 가졌던 것이다. BPM은 이걸 adhoc process나 performance monitoring으로 대체하려고 했었지만 결국 사라졌다. much ado for nothing인 셈이었다.  Hype은 5년을 넘기지 못하고 시들게 마련이고 실질적인 가치를 찾을 때 10년을 넘어갈 수 있다는 생각은 내겐 신념처럼 굳어진 기준이다. (기술을 활용한 가치를 추구하는 사람으로써 더욱더 중요하게 생각하는 신조) AI의 시대에도 무엇을 자동화하고 무엇을 사람에 종속시켜 뒤따르도록 해야 할지는 매우 중요한 의사결정 요소이다. 자동화하는 것이 무조건 가치를 추가하지 않는다. 인간의 판단 능력, 임기응변 적응성 등을 잘 반영하는 것들은 대체할 필요가 없고 한시적으로 집중적인 일들은 파트타임 잡을 통해 사람이 해도 된다. (이 부분의 일부는 거대 언어모델 기반 AI가 인간 고유의 영역이 아님을 선언하고 대체해줄 것이다) 코드 생성, reflection, injection 등의 기술과 데이터베이스 설계, 룰 엔진 등으로 소프트웨어가 할 수 있는 갖은 방법으로 모두 직접 연결하기 위해 엄청난

macOS Catalina 버전부터 JDK의 System.loadLibrary 가 에러가 날 때

정말 오래간만에 자바 관련한 블로깅입니다. 불편한 사람들이 있을 것 같아서 정보 공유 차원에서 현재까지 파악한 이슈를 남깁니다. 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에 대한 관점은 내려놓고 의사 결정 후에 별도 주제로 다루는 게 일반적으로 가능하다 그런데 한 가지 요소를 더 생각해보자면, 풀고자 하는 문제가 무엇인가에 따라 좀더 많은 전문 정보를 공유하고 의사결정의 원칙을 잘 찾는 것이 좋은 의사 결정의 핵심 요소일 텐데 과연 개발자가 문제를 해결하는 전문 정보를 충분히 갖고 있는가, 의사결정의 원칙을 학습을

일론 머스크의 First Principle Thinking (제1원리 기반 사고)

이미지
제1원리 기반 사고, First principle thinking. 첫번째 원리로부터 생각하기 혹은 제일원리 기반 사고 정도로 해석할 수 있겠다.  아리스토텔레스가 형이상학이란 책에서 언급한 것으로 더 이상 추론될 수 없는 원칙에서부터 추론되어야 한다는 원칙이다. 예를 들어 Unmoved mover 즉 우주에 최초의 움직임을 만든 무언가는 움직임이 없었어야 한다는 추론이 이러한 원칙 하에서 추론된 것이다. 수학에서 공리에서 출발하는 것과 같은 논리인데 일론 머스크가 SpaceX를 만들면서 제일원칙에 기반한 사고 실험을 사용하였다고 언급하면서 의사결정의 원칙 혹은 문제해결의 방법론으로서도 많이 언급된다. 일론 머스크의 First Principle Thinking 머스크 이야기는 이렇게 시작된다. 화성에 가야겠다고 목표를 세운 머스크가 첫번째 마주한 문제는 천문학적인 로켓 가격이었다. 머스크는 물리학에서 배운 제1법칙 기반의 사고를 이 문제 해결에 적용하기로 했다. “물리학은 유추가 아닌 제1원리로부터 추론하는 것을 가르쳐준다. 좋다, 제1원리들을 한번 들여다보자. 로켓은 무엇으로 만들지?  우주항공산업 등급의 알루미늄 합금들과 약간의 티타늄, 구리, 탄소 섬유이다. 다시 생각해봤다. 일반 상품 시장에서 이 물질들 가격은 얼마쯤 하나? 로켓에 사용되는 재료들 가격은 로켓 일반 가격의 약 2%에 불과했다.” 머스크는 원 재료를 사서 직접 로켓을 만들기로 했고 SpaceX를 세웠다. SpaceX는 1/10 가격으로 로켓을 만들면서도 수익을 내고 있다. 제1원리 기반의 사고를 머스크는 진실이라고 생각되는 좀더 근원적인 부분으로 내려가서 거기에서부터 다시 의사결정에 이르는 논리를 쌓아올리는 문제 해결 과정으로 적용한 것이다. 진리와 근원적 사고 사람은 수많은 참으로 믿은 불확실한 가설들이나 관성으로부터 판단하는 경향이 강하므로 중요한 의사결정을 좀더 근원적인 진위로부터 추론하는 것은 더 나은 해결 방법, 더 높은 진위 추정의 확률을 위해 매우 유용한 방법이라 할 수 있다

매니지먼트 코칭

신입 코칭을 굉장히 중요하게 생각하고 장시간 직접 챙기는 편이지만 생각해보면 매니지먼트에 대한 코칭이 훨씬 더 중요할 수 있다. 경험적으로 매니저들에 대해서는 코칭보다는 기대치만 부여해서 전체 조직이 비효율적이 되거나 중요한 문화적 자산을 단절시키거나 하는 경우가 많았다. 기술 조직에서 코칭은 기술에 대한 측면이 강하고 기술에 관한 협업적 의사결정의 사례 경험의 성격도 강하다. 곰곰 생각해보면 기술 축면의 코칭이란 전공 요소들을 반영하는 것이라 개인의 상당한 학습 노력과 결합하거나 기반 지식을 갖추고 있을 것을 요구한다. 매니지먼트에 대한 코칭은 그런 전제 조건이 약하기 때문에 훨씬 쉽고 효과도 클 가능성이 있다. 매니지먼트는 의사결정의 원칙에 대한 것이고 이 원칙이 무엇이어야 할지를 세워보도록 경험을 쌓는 게 코칭의 핵심일 수 있다. 의사결정이 계속 관행이나 주어와 목적 없는 프로세스에 의한 것이라면 누구도 새로운 상황에서 혹은 새로운 인적, 환경적 조건에서 의사결정 기준을 정리하고 이에 따라 판단하려고 하지 않을 것이다. 기준을 명시적으로 세워보지 않으면 친소 관계나 관행이 중요한 기준이 될수밖에 없다. 의사결정을 원칙을 세우고 판단하는 과정은 대부분 2,3회면 충분히 학습할 수 있다. 사람을 특별히 싫어해서 독단적 의사결정에 의존하는 경우나 의사결정 자체를 못하는 특수하게 적성에 맞지 않는 경우가 있긴 하지만 수년에 걸친 노력을 축적해야 하는 기술 관련 학습에 비해 정말 효율이 높다고 볼 수 있다. 물론 좋은 의사결정은 각 문맥별로 요구하는 사항이 다르고 그 적응력은 개인차가 있겠지만 많은 경우 충분히 가치있는 의사결정을 할수 있을 것이다.

네트웍, 불확실성, 가설과 검증, 비전

빅파일 전송 프로그램 빅파일 전송 프로그램을 급 제작해서 작년부터 고객사에서 쓰고 있는데 신규 고객사가 생기거나 고객사의 고객이 파일 전송하다 오류가 생기면 연락이 온다. ㅠㅠ (연락이 뜸해지면 고객사 사업이 잘안되나 걱정부터 듬 ㅠㅠ 모니터링하는 방법과 로그를 개선하였지만 업데이트를 꺼리는 고객이라 ㅋㅋ) 원인의 추정 클라이언트쪽 PC 방화벽부터 기업 방화벽, 그리고 서버쪽 타임아웃 설정 등 이슈가 엔드투엔드로 발생하는데 이게 100GB~1TB 가량 되는 파일 전송이다보니 별별 상황이 다 생긴다. “Network is unreliable”이기 때문에 혹시 모를 경우의 수를 생각해서 신중하긴 하지만 최근에는 금요일 밤 늦게 온 전화 때문에 화를 낸 적이 있다. 한참 오류 상황을 듣고 있었는데 파일 내용이 우리가 준 툴로 자동 생성한 파일이면 전송이 실패한다는 것 ㅠㅠ 100GB 파일 전송하면서 내용을 체크해서 뭘 할수도 없고 버퍼별로 암복호화 압축 체크섬 계산(이건 필요없다고 생각하지만 테스트 용도로 넣어둔 전체 파일 체크섬의 map-reduce 버전. 고객들은 매우 중요하게 생각 ㅠㅠ) 등을 하기 때문에 파일 내용이란 건 암호화하는 순간 아무 의미도 없는 얘기. 신뢰할 수 없는 상황에서 문제를 해결할 때에는 확실한 증거 기반으로 가설을 재수립해가야 하는데 지나치게 많은 중첩된 가설로 이상한 이야기를 주말 밤에 전화로 한 거. 프로젝트 오픈하느라 바쁠텐데 이런 걸 상의 없이 테스트 하느라 하루를 통째로 날린 게 답답하고 안쓰러운 게 컸다. 이 분에게 네트웍 환경 체크를 하랬더니 집에 가서 또 해보겠다고 셀룰러에 테더링으로 전송하고 또 자신의 주장이 맞다고 연락 ㅠㅠ 다행히 http tunneling 방식으로 구현해서 앞쪽 아파치 서버에 액세스 로그가 남아있어서 408 에러코드 확인하고 고객분이 테스트하신 환경인 코워킹스페이스 FAQ 사이트 가서 대역폭 제약 관련 조항을 캡쳐해서 보내줌. 셀룰러로 100GB 보내도 대역폭 제약이 안걸릴 거라는 생각을 하면 안된다