윤경구의 Log on Java

창의성은 특이성이 아니다

2024-10-28T20:36:00.005+09:00

지적 노동을 하면서 오래도록 창의성에 민감하게 고민한 편인데

최근엔 창의성이 인공 지능과 생체 지능의 차이로 간주되어 인공 지능을 공격하는 데 사용되기도 해서 새롭게 해석을 해보게 된다.

조금 시간을 뒤돌아보면 스티브 잡스 시대의 창의성에 대한 강조가 있고 창조성을 기계적인 프로세스로 만들어내려는 시도들이 전 세계적으로 이루어지기도 했다.

지금도 특이한 생각에 대한 태도는 사람들마다 사뭇 다른데 가끔은 천재성에 대한 판단과 혼용되기도 한다.

서로 다른 생각, 특이한 생각, 천재적 생각, 창의적 생각 이런 것들이 좀 경계가 애매하게 사용된다고 할까?

가끔씩은 무엇이 생각이고 무엇이 발상인가 하는 것도 혼동될 때가 있다.

질문을 통해 의견을 개진해보자면 …

1. 색다른 의견을 많이 내는 사람의 의견들은 창의적인가?

의견이라 할 수 있는 생각의 수준은 어느 정도엘까 하는 건 해결하고자 하는 문제의 수준에 따라 다르다.

브레인스토밍 수준의 생각들이 필요한 시점이 있을 것이다. 여러 가지 떠올리는 것이 필요할 때 색다른 의견들은 어떤 제약 없이 화두를 다양하게 끄집어내는 데 유용할 수 있다.

다른 측면에서 본다면 생각을 모두 많이 한다면 의견이 모두 많이 나와야 하는 게 아닐까 의문해볼 수 있다.

전문성을 가진 사람들은 생각을 의견으로 출력하기 전에 검증과 심화의 필터링 과정을 거친다.

특이한 생각이 많으나 필터링 없이 주장하는 경우는 창의적일까?

창의성이란 실질적인 창조(개작 포함)를 위한 유용성을 포함하는 개념이므로 개인이 아닌 집단을 위한 생각이라면 집단의 능력과 상관이 있다.

매우 불완전하더라도 그것을 보완해갈 능력을 집단이 갖추고 있느냐는 측면.

또하나는 수많은 아이디어들이 매우 약한 필터링을 거쳐 나올 때 실제 유용할 확률 측면이 있다. 어느 정도 유용할 확률까지 감당할 수 있을까?

흔히 말하는 촉이 좋은 사람들이 있다.
어떤 전문성에 속하여 일을 하다 보면 톡톡 튀는 아이디어를 많이 내고 그 아이디어들이 사후적으로 좋은 방향의 창의로 많이 발전하는 경우. (좋은 직관을 갖고 있다고 얘기할 수 있을 것 같다)

아마도 경험들이 논리적 필터는 아니지만 사고의 방향을 확도 높은 축으로 움직이게 해주는 것처럼 보여지는 …

나는 생각이란 개인별로 모두 다른 기저로 구성된 공간 속에서 생성된다는 가설을 갖고 있다.

좋은 경험은 그 기저들을 움직여 더 나은 생각을 쉽게 떠올리게 한다고 생각한다. 하지만 그 아이디어에 대한 논리적 해석의 능력이 떨어진다면 이것을 뒷받침해줄 Spock 같은 동료가 필요한 경우가 많을 것.

그러면 그냥 똑똑하고 의견 많은 사람은 그러한 기저를 갖춘 사고 공간을 갖고 있을까?

똑똑하다는 것은 사고의 속도와 공간 부피 두 가지 측면의 장점에 가깝다는 또다른 가설을 갖고 있다.

전문성의 경계를 넓힐 가능성이 있지만 전문성은 획득하는 데 많은 노력이 전제되어야 기저 공간을 변화시킬 수 있다.

따라서 전혀 아니라고 생각한다.

색다르지만 좋은 확률의 아이디어를 내는 사람이 창의적이다.

2. 특이하게 생각하는 것이 창의적일까?

평범하지 않은 생각은 창의적일까?

앞의 기저 공간 가설을 특이성에 적용해보면 모든 사람들은 서로 다른 기저 공간을 가지고 있다는 가설이므로 그 공간과 많이 다른 공간을 가진 사람일수록 특이한, 엉뚱해보이는 생각을 할 가능성이 높다.

하지만 그 특이함은 창의적 유용함의 확률을 높여줄까 하는 관점에서는 사실 독립적 요소이다.

많은 조직은 더 나은 생각을 만들고 싶어한다. 어떤 사람들은 특이함을 과도하게 중시한다.
아마도 창의성과 특이성을 동일하게 보거나 특이성을 창의성의 필요조건으로 보는 것 같다.

정말 특이한 것만으로 유의미한 가치를 유용성 관점에서 가질 수 있을까?
먼저 나는 creativity를 inventive idea 혹은 ideas toward invention이란 관점을 갖고 있다. 너무 추상화해서 용어만 남은 창의를 상정하지 않는다.

좋은 기저로부터 나온 특이한 아이디어도 한번에 유용성의 크기가 큰 아이디어일 가능성은 높지 않다. 인류는 수많은 아이디어를 지식화하고 적용하고 개선하는 중이다.
관련한 아이디어의 영역에 매우 많은 사람들이, 그것도 생각의 속도와 공간 부피가 매우 좋은 똑똑한 사람들이 집중하고 있다면 더욱 유용성까지 갈 길이 멀 가능성이 높다.

또하나의 가설은 특이해보이는 아이디어를 많은 사람들이 생각을 거듭하여 만들 수 있다는 가설이다.
생각을 집중해서 많이 할수 있는 사람들이라면 누구나 아이디어를 만들 수 있다.
속도와 공간 부피는 타고나는 측면이 강하다고 해도 전문성을 가진 사람이라면 평범에서 벗어난 착상을 만들 가능성이 있다.

유전적 한계를 벗어날 수는 없다고 해도 생각의 반복을 통해 아이디어를 착상하고 개선할 수 있다.

게다가 축적된 전문성이 있다면 기저 공간이 좀더 효율적인 생각을 만드는 방향에 있을 것이다. 이 얘기는 역설적으로 전문성이란 특정 영역에서 생각의 경험이 집적된 정도라고 정의할 수 있게 한다.

단순한 시간이 아니라 해결의 생각과 경험이 진정한 전문성을 축적시켜준다고 볼수 있고, 분야의 전문성이 가지는 지적 유연성을 획득하게 해준다고 볼 수 있다.

지적 유연성이란 축적된 전문성에 기반한 이해력과 발상력의 제고를 뜻한다고 볼 수 있다.

다시 질문으로 돌아가서 특이한 것과 창의적인 것은 어떤 관계가 있을까?
기본적으로는 독립적이다. “Orthogonal”하다.
하지만 보편적 아이디어는 일반적으로 사회에 이미 구현된 아이디어일 가능성이 높으므로 경계성이라는 측면에서 무의미하지는 않다.

하지만 일반적인 경계성 아이디어가 어떤 창의로 이를 가능성은 높지 않다.
개인적으로 전문성과 결합하지 않은 경계성 아이디어, 즉 무작위하게 특이힌 생각에 투자할 가치는 매우 낮다고 생각한다.

3. 그럼 창의성은 어떻게 구현하는 것이 좋을까?

마냥 특이한 생각을 쫓는 방식은 브레인스토밍 시점을 제외하면 유용성이 크게 떨어진다.

두 가지 방향으로 창의성을 추구하는 것이 좋다고 생각한다.

전제 조건으로 아이디어를 만들 수 있는 환경이 되어야 한다.
여러 사람들이 생각을 거듭할 수 있는 환경이 되지 않으면 출발점도 만들 수 없다.

첫번째는 기저 공간 가설을 한번 더 적용한 가설이다.
모든 사람들은 서로 다른 기저 공간을 가진다면 여러 사람들의 생각을 깊이 있게 병합한다면 더 큰 차원의 생각 공간을 근사할 가능성이 존재한다.
서로 다른 2차원 평면들로 3차원 공간을 구성할 수 있는 것처럼.

한 명의 천재성보다 여러 명의 범재성이 더 나을수도 있고 이왕이면 한 명의 천재성과 여러 명의 범재성을 병합한 공간의 아이디어를 만들면 더 좋을 것이다.

두번째는 생각의 깊이와 폭을 넓히는 방향성을 부여하는 방법이다.
특이한 생각은 방향성이 아니라 경계성을 표현한다.
방향성을 만드는 방법은 조금 tactic에 가깝다고 생각한다.

인공 지능에서도 추론은 1차적 사고가 아닌 2차적 사고 프로세스를 필요로 한다는 것이 일부 증명되고 있는데 현재까지 가장 유용한 생각하는 방법은 근원적 사고(first principle)가 아닐까 생각한다.

좀더 근원적인 범주로 문제를 재정의하고 이를 통해 더 근원적인 문제를 해결해나가는 방법으로 일론 머스크와 같은 이들이 이 방법을 여러 명의 천재성과 결합시켜 문제를 풀고 있다.

전문성에 기반하여 창의의 방향과 규모를 재정의하는 방법에 가깝다.

약한 전문성과 약한 범재성으로도 효과를 낼 수 있을까?
이것은 속도와 공간 부피의 문제여서 아이디어의 수준은 다르겠지만 충분한 보편성을 가지고 있는 방법이라고 생각한다.

여러 가설에 기반한 생각들이긴 하지만 경험적으로 수준에 맞는 창의로운 조직을 구성하려 할때 유의미한 가설이라고 생각한다.

애초 질문에 다시 답한다면 "창의적인 생각을 모으면 특이성이 강하겠지만, 특이한 생각을 모으면 창의적일 가능성이 매우 낮다."

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

2023-07-09T22:52:00.000+09:00

약 20년 전에 BPM 솔루션을 만들기 시작했었는데 그때에는 어떻게 하면 사용자(기업 고객)가 개발을 할 필요없이 (혹은 최소화하도록) 솔루션에서 자동으로 코드를 생성하거나 간단한 룰로 처리하려고 많은 노력을 했다.

몇일 전에 30년만에 만난 대학 후배의 회사에서 후배가 10년에 걸쳐 만든 회사 솔루션을 봤는데 같은 문제를 핵심 메타 정보 중심으로 쉽게 관리해주고 탑레벨의 일들을 굳이 실제 업무랑 연동시키지 않는 방식으로 문제를 풀었다.

그런데 그 후배의 솔루션이 내겐 약 15년 가까이 이전 직장에서 고민했던 합리적인 풀이로 느껴졌다.

탑레벨에서 실제 구현까지 모든 걸 연결하면 오히려 다양한 변화를 쫓아가기 어렵다.

사람의 아이디어와 의사결정 변화를 바로 반영하려면 시스템적으로 실행을 엮으면 오히려 어려워질 수 있다.

자동화가 사실 인간의 의사결정 능력을 대체힐 수 없다는 점에서 잘못된 목표를 가졌던 것이다.

BPM은 이걸 adhoc process나 performance monitoring으로 대체하려고 했었지만 결국 사라졌다.

much ado for nothing인 셈이었다.

Hype은 5년을 넘기지 못하고 시들게 마련이고 실질적인 가치를 찾을 때 10년을 넘어갈 수 있다는 생각은 내겐 신념처럼 굳어진 기준이다. (기술을 활용한 가치를 추구하는 사람으로써 더욱더 중요하게 생각하는 신조)

AI의 시대에도 무엇을 자동화하고 무엇을 사람에 종속시켜 뒤따르도록 해야 할지는 매우 중요한 의사결정 요소이다.

자동화하는 것이 무조건 가치를 추가하지 않는다. 인간의 판단 능력, 임기응변 적응성 등을 잘 반영하는 것들은 대체할 필요가 없고 한시적으로 집중적인 일들은 파트타임 잡을 통해 사람이 해도 된다. (이 부분의 일부는 거대 언어모델 기반 AI가 인간 고유의 영역이 아님을 선언하고 대체해줄 것이다)

코드 생성, reflection, injection 등의 기술과 데이터베이스 설계, 룰 엔진 등으로 소프트웨어가 할 수 있는 갖은 방법으로 모두 직접 연결하기 위해 엄청난 시간과 사람들이 머리를 쥐어짰었다.

결국 조금 끊고 사람들이 연결하게 하고 탑레벨 정보 관리를 가시적이면서 유연한 구조로 유지하는 게 정답이었던 셈이다.

추상적 정보는 트리 형태의 계층 구조로 관리 가능하지만 실제 프로세스는 너무 다양한 계층에서 연결되거나 애매하게 분류되는 것들이 워낙 많고 사람에 따라 다른체계로 해석하는 일들이 잦은 것이다.

탑레벨의 트리 구조를 실제의 상세 업무 구현 레벨까지 확장하는 것은 가능하다 하더라도 그 가치보다 부작용이 더 클 수밖에 없었던 셈이다.

의사결정의 하부 요소로 들어올 능력이 있는 인공지능의 시대가 5년 후에라도 온다면 이 결론은 다시 생각해볼 수 있을 것이다.

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

2022-04-04T16:43:00.006+09:00

정말 오래간만에 자바 관련한 블로깅입니다.

불편한 사람들이 있을 것 같아서 정보 공유 차원에서 현재까지 파악한 이슈를 남깁니다.

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 attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)
Big Sur부터는 동적 라이브러리의 사본들을 파일 시스템을 통해 찾을 수 없다. 따라서 해당 경로에 파일이 있는지를 체크하거나 해당 디렉토리에 있는 파일들을 찾아보도록 구현된 코드들은 실패하게 된다. macOS에서는 그냥 dlopen을 해당 경로로 주면 알아서 캐시에 있는 라이브러리를 체크할 수 있다. 즉, JDK에서 불필요하게 파일의 존재 유무를 체크하지 않고 바로 dlopen만으로 체크해야 한다.

상세 설명:

- The new dynamic linker cache introduced by OSX Big Sur creates problems with previous code which checks for the existence of a library file in the filesystem before attempting to load it with dlopen(...). According to the Big Sur release notes in [1],
"Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache."

Tracing the execution of System.loadLibrary shows that the offending check happens at [2] (tested on OpenJDK 11 and 17, Oracle JDK 17 and 18-ea) where File.exists(...) is used to check whether the library file is present on the filesystem before attempting to load it. As a result, valid dynamic libraries that otherwise open fine via dlopen(...) fail with UnsatisfiedLinkError in current versions of the JDK.
현재 JDK 구현체들은 로드하기 위하여 파일 시스템의 파일 존재 유무를 File.exists(...) 코드를 사용하여 체크하도록 되어 있다. 그래서 그냥 dlopen(...)으로 바로 열면 제대로 열리는 유효한 동적 라이브러리들이 현재 JDK 버전들에서는 UnsatisfiedLinkError를 던진다.

즉, DYLD_LIBRARY_PATH를 지정하여 해당 디렉토리를 뒤져 경로 방식으로 로드하는 건 무조건 실패하게 됩니다.

2. macOS의 라이브러리 공증 notarization 요구 사항

System.loadLibrary 뿐만 아니라 macOS의 라이브러리 관련 보안 공증 요건 강화도 영향을 주고 있습니다.

이런 에러가 특정 macOS 버전부터 발생하는 이유는 macOS의 라이브러리 보안 관련 규정들이 바뀌었기 때문인데...

이에 대한 내용은 다음에서 잘 정리해두었습니다.

On MacOS 10.15.3 and later, Azul Zulu Builds of OpenJDK Java doesn't load the JNI Libraries my Application needs

내용을 간단히 살펴보면 이와 같은 오류가 발생하는 원인은 다음과 같습니다.

에러의 원인

Apple now requires Application executables like Java to be Notarized. As part of this process, with MacOS 10.15.3, the executables must be Hardened Runtime. In order to be Notarized, and once the Hardened Runtime executables and libraries are installed in the /System and /Library hierarchies, they cannot load libraries which have not been Notarized. Note that Apple has been tightening this up progressively.
애플은 macOS 특정 버전부터 응용 프로그램 바이너리들에 대해 공증을 요구하고 있는데, macOS 10.15.3부터는 이 공증 바이너리의 절차로 실행 바이너리에 보안 강화(hardening) 과정을 거치도록 하고 있다. 공증되기 위해서는 일단 /System 과 /Library 폴더 아래에 한번 설치되는 강화 런타임 실행 파일과 라이브러리들은 공증되지 않는 라이브러리를 적재할 수가 없다. 애플은 이 요구를 점차 더 강화하고 있다.

해결방안

In the short term, the resolution is to download the zip image of the version of Azul Zulu Builds of OpenJDK that you need, and extract the bundle to a folder outside /Library and /System. When you want to run your application, first set DYLD_LIBRARY_PATH=/usr/local/lib, and then use the java executable from the unzipped install. In time, as Apple extends its security model, this option may go away.
In order to ensure that your application is able to continue to load any third-party libraries in the future, contact the library authors and let them know that you need them to submit their libraries for Notarization.
단기적인 해결책으로는 필요한 JDK를 /System이나 /Library 폴더의 자식 경로가 아닌 경로에 설치하면 이 강화 과정을 회피할 수 있다. 그리고 원하는 dylib 라이브러리도 다른 경로에 두고 환경변수 DYLD_LIBRARY_PATH로 경로를 설정해주면 해당하는 문제를 피할 수 있다. 하지만 애플이 보안 모델을 더 강화하면 앞으로는 안될 수도 있다.
가장 확실한 방법은 dylib 라이브러리들을 공증받도록 유도하는 게 최선이다.

일단 JDK 설치를 기본 경로인 /Library 아래에 해서는 답이 없다는 것을 알 수 있습니다.

3. 당장의 Workaround 방법

실제 테스트를 zulu openjdk 8과 11 버전을 통해서 해본 바는 다음과 같습니다.

먼저 JDK 설치 경로는 기본이 /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home 과 같은 곳에 설치되는데 앞에서 언급한 /Library 서브폴더의 요건을 회피하기 위해 사용자 디렉토리로 통째로 옮깁니다.

~/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home

일단 이렇게 하고 난 다음에도 DYLD_LIBRARY_PATH로 설정된 경로에 있는 dylib 동적 라이브러리들을 찾지 못하는 문제가 있습니다. 이 이유는 앞에서 언급한 JDK 라이브러리 로딩 버그와 상관이 있을 것입니다.

JDK가 별도의 loadLibrary 호출 없이 기본으로 찾을 수 있는 다른 가능한 경로에 dylib을 복사하여 실행가능하면 개인적으로는 문제가 해결되기 때문에 (개발과 테스트 목적이므로) 다음과 같이 해결하였습니다.

JDK 8의 경우에는 아래 위치에 원하는 dylib 파일을 복사

~/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre/lib/server

JDK 11의 경우에는 아래 위치에

~/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/lib/server

#또하나의삽질

소프트웨어 창업에 대한 생각

2022-03-13T15:51:00.000+09:00

이 글은 2021년 3월 13일에 페이스북에 올렸던 글이다.

창업은 소프트웨어 기술을 활용하여 산업을 재정의한 것

얼마전 창업은 소프트웨어 기술을 활용하여 기존 산업을 재정의하는 것이고 기존 산업을 유지하는 법규와의 충돌은 필연적이라는 이야기를 들었다.

소프트웨어나 인공지능 등 기술의 발전을 활용하여 기존의 산업 전반을 완전히 바꾸는 것이 현 시대의 창업 개념이고 이를 가속화하기 위해 법규의 재해석과 개정은 불가피하다는 것.

물론 기존 법규가 무조건적으로 배척될 이유는 없을 것이다. 사회적 가치, 인간애적 가치를 전제한 가치의 관점을 가질 필요가 있고, 자동화, 가속, 정보 집중에 의한 더 지능적인 의사결정에 기반하여 새로운 산업을 만드는 것이 누구에게 가치를 줄 수 있을까 혹은 정말 가치로운 일인가를 스스로와 대중에게 설득해야 하는 건 역사적으로도 늘 새로움을 추구하는 이들이 감당해야 할 의무처럼 주어진 것 같다.

협업과 문제 해결을 확장하는 창업

어제 신입 사원들이 부서로 배치되었다.

늘 개발자는 가치를 만드는 게 직업인 사람이며 이 부서(기업 R&D 조직)의 미션은 개발이 아니라 소프트웨어 전문 지식을 기반으로 한 문제해결이란 점을 강조하는 편이다.

나혼자 개발만 잘하면 된다는 생각이 강하면, 문제를 풀기 위해 학습하고 협업하는 과정을 학습하지 못한다.

새로운 문제를 찾으려 하지 않고 더 나은 아이디어를 찾는 노력을 하지 않는다.

이미 잘 알고있는 문제를 잘 알고 있는 기술로 빠르게 찍어내는 게 목적인 시스템 통합 프로젝트처럼 개발을 이해한다면 소프트웨어적 혁신은 애시당초 불가능하다.

물론 벨 연구소에서 유닉스가 탄생한 과정에서 보듯이 정말 똑똑한 사람들은 부서의 목적이 분명하지 않아도 목적에 구애받지 않는 혁신들을 만들어낸다. 우스개로 똑똑한 해커들을 한동안 컴퓨터만 주고 가둬두면 유닉스 비슷한 운영체제를 만들거라는 이야기가 한동안 떠돌기도 했었다.

하지만 그렇게 창업은 할수 없을 것이다. 스티브 잡스가 얘기한 것처럼 해커와 기업가 정신의 결합이 필요하고 그것은 엄청나게 자유롭고 똑똑한 친구들의 생각에 방향을 정하자는 약속 같은 것일테다.

게다가 점점 혼자만의 뛰어난 생각에 여러 사람의 아이디어가 합쳐지는 것이 더 뾰족한 아이디어는 아니지만 더 해결력이 크고 오류 수정도 빠르다는 것이 실리콘밸리에서도 학습했기 때문에 아마도 과거의 벨 연구소나 제록스 팔로알토 연구소로 돌아가려고 하진 않을 것이다.

한국의 소프트웨어 수준은 사실 그닥이지만 최근 AI에 대한 관심도 높고 유니콘 기업들도 본격적으로 나오기 시작하면서 분위기는 많이 좋아지고 있다고 생각된다. 최근 개발자 연봉 인상 움직임도 불가피한 흐름이라고 생각하고...

어떻게 보면 이제 1차, 2차, 3차 산업의 성격과 개별 사업 특성에 따라 속도의 차이는 있지만 전반적인 산업 재정의라는 과정은 이미 시작되었고 돌이킬 수 없다고 봐야하지 않을까?

코로나19는 전환을 더 가속시키고 있고...

개발자들은 '일단 안돼'라고 말하고 본다는 전형성에 대한 생각

2022-01-15T14:15:00.010+09:00

개발자들은 '일단 안돼'라고 말한다

보통 이런 얘기를 들을 일이 없는데 개발자가 아닌 분들과 얘기하면 이런 얘기를 듣는다. '무조건 안돼' 족이 있고 '무조건 돼' 족이 있다고...

(둘 다 말이 안되는 건데 ^^)

실제 개발자들은 자신이 개발하고 있는 모듈의 변화를 좋아하지 않는다. 부담스러워 한다. 해야 할 일이 갑자기 생기는 것에 대해 부담스러워 하는 것도 있고 업무 자체가 좀더 깊은 집중을 요구하는 성향이 있어 일련의 인터럽트에 즉자적으로 반응하는 성향도 학습된다.

그럼에도 함께 제기된 문제에 대해 문제 해결을 위해 토론하고 분석하는 시간을 들이는 것은 마다하지 않는다.

두 가지 허들을 풀어야 한다.

하나는 갑자기 던지면 숙고를 거친 반응이 나올 수 없다는 것

또 하나는 중요한 자신의 업무인 이해 당사자이기 때문에 이해 관계를 내려놓고 판단하기 쉽지 않다는 것

첫번째는 좀더 시간을 주고 문제를 여러번 remind하여 enough thinking 후에 답을 구하는 게 방법이라고 볼 수 있는데

두번째는 좀더 까다롭다.

(그런데 이 이해 관계란 이 개발자의 업무 로드가 증가하는 부분이므로 이 의사결정의 주제 관점에서만 보면 크게 중요하지 않은 요소일 수 있다.)

많은 한국의 소프트웨어 개발 회사는 개발 조직이 계층 구조를 이루고 있다. 가장 잘 아는 사람이 개발자인 매니저이고 심지어 핵심 모듈을 개발하기도 한다.

의사 결정에 주요한 권한을 행사하는 사람이 직접적인 이해당사자인 개발자인 경우가 많다는 것이다.

물론 훈련을 통해 개선된다. 업무 로드에 대한 관점, R&R에 대한 관점은 내려놓고 의사 결정 후에 별도 주제로 다루는 게 일반적으로 가능하다

그런데 한 가지 요소를 더 생각해보자면, 풀고자 하는 문제가 무엇인가에 따라 좀더 많은 전문 정보를 공유하고 의사결정의 원칙을 잘 찾는 것이 좋은 의사 결정의 핵심 요소일 텐데 과연 개발자가 문제를 해결하는 전문 정보를 충분히 갖고 있는가, 의사결정의 원칙을 학습을 통해 개선하고 있는가 하는 생각을 해볼 수 있다.

풀고자 하는 문제가 기술적인 전문 분야인 경우는 많은 경우 회의를 통해 좋은 답을 구할 수가 있다.

그런데 순수하게 기술적이지 않은 요소가 많은 경우 포함되고 이러한 전문 지식은 많은 개발자들은 사고의 체계에 포함하는 것을 꺼려 하는 경향이 있다.

R&D 조직이 고립되어 있는 경우는 직접적인 사용자에 대한 추체험이 원활하지 않아 더 제대로 되지 않는 경우가 많다.

사용성의 문제를 푸는 경우에도 이런 현상이 있지만 기술적인 문제에도 실제 서비스가 실현되어 실행되는 환경에 대한 이해가 부족한 경우도 많다.

원래 개발을 할 때 가정했던 환경과 실제 실행되는 환경은 다를 수밖에 없고 또 다양한 시간적, 공간적 변화가 존재하게 마련이다.

이러한 구현체들에 대한 실질적인 검증을 하지 않고 즉자적인 반응을 보이는 것은 추체험 부족과 open-ended mind의 중요성을 깨우치지 못했기 때문으로 볼 수 있다.

개발 조직이 단순 계층으로 편의적인 인원 기준으로 관리되는 경우는 개발자들을 더욱 의사결정의 원칙을 학습하고 실질적인 검증에 대한 추체험을 갖는 기회로부터 배제한다고 볼 수 있는데, 개발자란 설계와 구현, 그리고 개선 과정에서 수많은 의사결정을 할 수밖에 없는 직업이다.

개인적으로는 의사 결정의 원칙이 단순하고 명확한 경우가 아니면 개발자들과 회의를 통해 의사 결정에 참여시키고 의사 결정의 원칙을 정확하게 하는 데 좀더 중점을 둔다.

의사 결정을 내리는 것 자체는 어려운 일이 아니지만 더 많은 숙고와 더 많은 아이디어가 그 의사 결정을 더 빠르게 번복하거나 조정하고 더 풍부하게 해준다.

의사 결정의 원칙을 어떻게 세울지 매번 생각하는 것, 그리고 실질적인 환경에 대해 좀더 정확하게 설명해줄 수 있는 사람을 포함시키는 것 등이 매우 기본적인 전제 조건이라고 볼 수 있다.

과도하게 계층 구조를 세운 조직은 top-down 조직에서는 빠르게 기여할 수 있는 부분이 있겠지만 창의성을 중시하는 조직에서는 간접성만 강화되는 단점이 더 커질 수 있다.

경험적으로 많은 개발자들을 보게 되지만 한국에서는 두 가지 성향이 너무 많아 왔다.

"일단 안돼" -> meta thinking (의사 결정의 원칙에 대한 판단 훈련과 다양한 검증을 위한 추체험) 학습이 부족한 경우

"시키면 하겠습니다" -> intelligence를 제거하는 훈련

어떻게 보면 개발 조직의 의사결정자에게 필요한 게 다양한 의사 결정과 추체험 훈련이라 볼 수 있지만

사실은 개발 조직 의사 결정에 여러 아이디어가 포함되어야 하므로 모든 개발자들에게 필요한 훈련이라 볼 수 있다.

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

2021-12-01T11:23:00.002+09:00

제1원리 기반 사고, First principle thinking.

첫번째 원리로부터 생각하기 혹은 제일원리 기반 사고 정도로 해석할 수 있겠다.

아리스토텔레스가 형이상학이란 책에서 언급한 것으로 더 이상 추론될 수 없는 원칙에서부터 추론되어야 한다는 원칙이다.

예를 들어 Unmoved mover 즉 우주에 최초의 움직임을 만든 무언가는 움직임이 없었어야 한다는 추론이 이러한 원칙 하에서 추론된 것이다.

수학에서 공리에서 출발하는 것과 같은 논리인데 일론 머스크가 SpaceX를 만들면서 제일원칙에 기반한 사고 실험을 사용하였다고 언급하면서 의사결정의 원칙 혹은 문제해결의 방법론으로서도 많이 언급된다.

일론 머스크의 First Principle Thinking

머스크 이야기는 이렇게 시작된다.

화성에 가야겠다고 목표를 세운 머스크가 첫번째 마주한 문제는 천문학적인 로켓 가격이었다.

머스크는 물리학에서 배운 제1법칙 기반의 사고를 이 문제 해결에 적용하기로 했다.

“물리학은 유추가 아닌 제1원리로부터 추론하는 것을 가르쳐준다. 좋다, 제1원리들을 한번 들여다보자. 로켓은 무엇으로 만들지? 우주항공산업 등급의 알루미늄 합금들과 약간의 티타늄, 구리, 탄소 섬유이다.

다시 생각해봤다. 일반 상품 시장에서 이 물질들 가격은 얼마쯤 하나? 로켓에 사용되는 재료들 가격은 로켓 일반 가격의 약 2%에 불과했다.”

머스크는 원 재료를 사서 직접 로켓을 만들기로 했고 SpaceX를 세웠다. SpaceX는 1/10 가격으로 로켓을 만들면서도 수익을 내고 있다.

제1원리 기반의 사고를 머스크는 진실이라고 생각되는 좀더 근원적인 부분으로 내려가서 거기에서부터 다시 의사결정에 이르는 논리를 쌓아올리는 문제 해결 과정으로 적용한 것이다.

진리와 근원적 사고

사람은 수많은 참으로 믿은 불확실한 가설들이나 관성으로부터 판단하는 경향이 강하므로 중요한 의사결정을 좀더 근원적인 진위로부터 추론하는 것은 더 나은 해결 방법, 더 높은 진위 추정의 확률을 위해 매우 유용한 방법이라 할 수 있다.

물론 더 근원적 진위나 명제에 접근하기 위해서는 훨씬 더 깊이 있는 지식과 통찰이 필요할 가능성이 높다.

근원적 진위란 무엇일까 혹은 근원적 진위는 어느만큼 참인가 하는 질문을 할 수 있다.

우리가 바라보는 근원적 진위 혹은 공리는 사실은 탄탄한 반석과 같은 것이 아닐 수 있다.

튼튼한 계단을 밟으며 추론의 과정을 밟고 있다고 생각하지만 튼튼한 계단의 가장 아래는 안개 속에 가려져있는 경우가 대부분일 수 있다.

아리스토텔레스가 얘기한 Unmoved mover는 존재하는가? 우주의 본질이 운동(에너지?)인 것은 아닌가? 등등

사회 현상으로 가서는 세계관과 가치관의 문제에서 가장 궁극적인 가치 기준은 무엇일까? 아무런 이해관계 없이 공정한 가치 판단이 있을 수 있는가? 왜 사는가? 등등

그럼에도 불구하고 제1원리 혹은 좀더 명백한 진위로 돌아가서 판단하는 과학적 태도는 많은 부분에서 현상을 잘 해석하고 따라서 매우 유용하다.

제1원리 기반 사고와 의사결정

본업인 IT나 SW로 돌아와보면 문제 해결을 위해 좀더 근원적인 방식의 해결들이 유용한 경우가 매우 많다.

IT 기술을 포함한 수많은 의사결정은 이러한 근원적 사고를 통해 큰 도움을 받기도 하고 큰 혁신을 만들어내기도 한다.

머스크는 테슬라의 자율 주행과 인공 지능에 대한 의사결정들에도 제1원리에 기반한 사고를 사용한다고 잘 알려져 있다.

자율주행의 인공지능 파트를 책임지고 있는 안드레이 커패시는 머스크와의 이런 회의가 종종 몇 일에 걸쳐 진행되며 실리콘밸리에서 텍사스까지 가서 체육관의 요가 매트에서 쪽잠 자며 하는 토론을 매우 즐기고 있다고 말하기도 했다.

물론 이러한 근원적인 문제 해결 혹은 의사결정을 위해서는 지식 체계의 깊이와 유연성, 본질에 대한 직관 등이 체화되어 있어야 한다.

흔히 바쁘기 때문에 근원적인 사고를 할수 없다고 한다. 하지만 근원적인 해결책이 항상 더많은 시간을 요구하는 것도 아니며 그 결과물의 가치는 엄청난 차이를 만들 가능성이 높다.

지속적 개선과 근원적 해결

지속적 개선 모델은 근원적 해결이 불가능한가 혹은 필요없는가?

어떤 경우도 근원적인 의사결정으로 나아가는 것이 필요없을 수는 없다. 그 의사결정의 수준을 결정하기 때문이다.

지속적 혹은 점진적 개선과 근원적 해결은 분명 다르다. 다만 단기적 해법의 축적이 근원적 해결을 대신하는 것도 일반적으로 불가능한 것도 분명하다.

점진성만으로 엄청난 도약을 가져올 수는 없다. 필요하고 가용하다면 둘 다를 실행하기 위해 노력하는 것이 맞을 것이다.

#firstprinciple #elonmusk #problemsolving #decisionmaking

매니지먼트 코칭

2021-10-28T12:52:00.004+09:00

신입 코칭을 굉장히 중요하게 생각하고 장시간 직접 챙기는 편이지만 생각해보면 매니지먼트에 대한 코칭이 훨씬 더 중요할 수 있다.

경험적으로 매니저들에 대해서는 코칭보다는 기대치만 부여해서 전체 조직이 비효율적이 되거나 중요한 문화적 자산을 단절시키거나 하는 경우가 많았다.

기술 조직에서 코칭은 기술에 대한 측면이 강하고 기술에 관한 협업적 의사결정의 사례 경험의 성격도 강하다.
곰곰 생각해보면 기술 축면의 코칭이란 전공 요소들을 반영하는 것이라 개인의 상당한 학습 노력과 결합하거나 기반 지식을 갖추고 있을 것을 요구한다.

매니지먼트에 대한 코칭은 그런 전제 조건이 약하기 때문에 훨씬 쉽고 효과도 클 가능성이 있다.

매니지먼트는 의사결정의 원칙에 대한 것이고 이 원칙이 무엇이어야 할지를 세워보도록 경험을 쌓는 게 코칭의 핵심일 수 있다.

의사결정이 계속 관행이나 주어와 목적 없는 프로세스에 의한 것이라면 누구도 새로운 상황에서 혹은 새로운 인적, 환경적 조건에서 의사결정 기준을 정리하고 이에 따라 판단하려고 하지 않을 것이다.

기준을 명시적으로 세워보지 않으면 친소 관계나 관행이 중요한 기준이 될수밖에 없다.

의사결정을 원칙을 세우고 판단하는 과정은 대부분 2,3회면 충분히 학습할 수 있다.

사람을 특별히 싫어해서 독단적 의사결정에 의존하는 경우나 의사결정 자체를 못하는 특수하게 적성에 맞지 않는 경우가 있긴 하지만 수년에 걸친 노력을 축적해야 하는 기술 관련 학습에 비해 정말 효율이 높다고 볼 수 있다.

물론 좋은 의사결정은 각 문맥별로 요구하는 사항이 다르고 그 적응력은 개인차가 있겠지만 많은 경우 충분히 가치있는 의사결정을 할수 있을 것이다.

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

2021-10-10T21:07:00.006+09:00

빅파일 전송 프로그램

빅파일 전송 프로그램을 급 제작해서 작년부터 고객사에서 쓰고 있는데 신규 고객사가 생기거나 고객사의 고객이 파일 전송하다 오류가 생기면 연락이 온다. ㅠㅠ

(연락이 뜸해지면 고객사 사업이 잘안되나 걱정부터 듬 ㅠㅠ 모니터링하는 방법과 로그를 개선하였지만 업데이트를 꺼리는 고객이라 ㅋㅋ)

원인의 추정

클라이언트쪽 PC 방화벽부터 기업 방화벽, 그리고 서버쪽 타임아웃 설정 등 이슈가 엔드투엔드로 발생하는데 이게 100GB~1TB 가량 되는 파일 전송이다보니 별별 상황이 다 생긴다.

“Network is unreliable”이기 때문에 혹시 모를 경우의 수를 생각해서 신중하긴 하지만 최근에는 금요일 밤 늦게 온 전화 때문에 화를 낸 적이 있다.

한참 오류 상황을 듣고 있었는데 파일 내용이 우리가 준 툴로 자동 생성한 파일이면 전송이 실패한다는 것 ㅠㅠ

100GB 파일 전송하면서 내용을 체크해서 뭘 할수도 없고 버퍼별로 암복호화 압축 체크섬 계산(이건 필요없다고 생각하지만 테스트 용도로 넣어둔 전체 파일 체크섬의 map-reduce 버전. 고객들은 매우 중요하게 생각 ㅠㅠ) 등을 하기 때문에 파일 내용이란 건 암호화하는 순간 아무 의미도 없는 얘기.

신뢰할 수 없는 상황에서 문제를 해결할 때에는 확실한 증거 기반으로 가설을 재수립해가야 하는데 지나치게 많은 중첩된 가설로 이상한 이야기를 주말 밤에 전화로 한 거.

프로젝트 오픈하느라 바쁠텐데 이런 걸 상의 없이 테스트 하느라 하루를 통째로 날린 게 답답하고 안쓰러운 게 컸다.

이 분에게 네트웍 환경 체크를 하랬더니 집에 가서 또 해보겠다고 셀룰러에 테더링으로 전송하고 또 자신의 주장이 맞다고 연락 ㅠㅠ

다행히 http tunneling 방식으로 구현해서 앞쪽 아파치 서버에 액세스 로그가 남아있어서 408 에러코드 확인하고 고객분이 테스트하신 환경인 코워킹스페이스 FAQ 사이트 가서 대역폭 제약 관련 조항을 캡쳐해서 보내줌.

셀룰러로 100GB 보내도 대역폭 제약이 안걸릴 거라는 생각을 하면 안된다고도 첨언.

하드웨어에 얽매이지 않는 소프트웨어는 없다

이 프로젝트는 이번주까지도 계속 파일 전송이 느리다는 이슈가 계속되었는데 가능한 대역폭은 거의 다 쓰는 편이라 네트웍 담당자가 확인해야 한다고 하니까 이 분이 고객은 그냥 파일 전송이 빨라야 한다고 하신다고. (고객의 고객은 네트웍 담당자라 잘 아실 거임 제발 ㅠㅠ)

결국 네트웍 스위치에 본딩 설정이 잘못된 걸로 네트웍 담당자가 확인해서 해결 ㅋ

경우의 수, 불확실성과 가설

경우의 수가 많은 불확실한 상황에서 개연적 추론은 일반적으로 득보단 실이 많고 절대 중첩하면 안됨. 가장 빠르게 확인할 수 있는 직간접 증거를 확인한 후 다음 가설을 세워야 함.

네트웍만 경우의 수가 많고 불확실한 건 아니다. 사회적, 사업적 관점은 얼마나 더 경우의 수가 많고 불확실하며 검증안된 위태로운 가설 위로 가는 것인가.

중첩된 개연적 가설들로 허비하지 말고 빠르게 확인할 수 있는 증거들을 잘 활용해야 한다.

본질적인 가설, 비전

물론 인간의 본성과 같은 좀더 본질적인 가설은 더 긴 판단과 연결되고 이에 대한 검증은 매우 간접적일 수 있다.

개인적으로 스티브 잡스를 포함한 visionary들은 이러한 본질적 가설과 10년 이상의 방향에 대한 비전을 잘 연결했다고 생각한다.

머스크도 가설은 다르지만 그런 성향이 강하다고 생각.

개발 조직을 관리할 때 목적 지표, parallelism과 aggregate intelligence

2021-10-04T22:39:00.001+09:00

개발 조직을 관리하면서 가장 중시하는 목적 지표 중 하나는 parallelism 수준, 또하나는 더 나은 의사결정을 하는 aggregate intelligence 수준으로 생각하는 편이다.

1. parallelism 혹은 vectorization

병렬화 수준 혹은 동시성 수준은 각자 자신의 일을 진행하는 데 병목이 되는 기다림이나 동기화를 최소화하는 것이고, 그 이전에 자신의 일이 가지는 목표가 분명하고 또 스스로 업무를 잘 큐잉해서 언제든지 자신의 큐에서 넣고 뺄 수 있어야 한다.

물론 목표가 자신의 수준에서 조직의 수준에서 다를 수 있기 때문에 기다림을 최소화하면서 동기화하는 리뷰나 이슈 토론 같은 것들이 오히려 중요할 수 있다.

업무를 나눌 때에도 다른 사람이 의존하는 일들은 우선 순위를 좀더 높인다거나 협업에 대한 부분을 미리 스케줄링하는 것들이 중요하게 된다.

여러 사람의 업무와 관련한 의사결정이 필요한 시점에는 어쩔 수 없이 waiting이 있을 수 있다. 이를 최소화하고 잘못된 의사결정으로 인한 폐기 업무, 반복 업무를 최소화하는 것은 의사결정에 책임이 있는 사람들에게 매우 높은 우선 순위가 된다.

2. aggregate intelligence or collaborative decision making

여러 사람의 아이디어가 한 사람의 아이디어보다 더 나을 가능성이 크다는 것은 인간의 불완전함이나 생각의 바이어스 등을 고려할 때 단순한 산수 이상이라고 할 수 있다.

더 나은 의사 결정을 하는 것은 단순히 개인이 돌아가면서 의사결정을 하거나 한 사람의 의사결정을 투표하는 것이 될 수 없다. 여러 의견들 중 최선의 의견에 기반하면서도 공유 과정에서 더 나은 의사 결정으로 발전시키는 과정은 수많은 의사결정을 여러 조직 단위에서 이루어내는 문화 구축과 상관 있다.

기술적 의사 결정은 보다 더 깊은 기술적 이해와 여러 가지 가설에 대한 분석, 연구 등의 반복적인 과정을 필수적으로 요구한다.

물론 이 과정에서 여러 사람의 아이디어를 수집하고 이해하고 논의할 필요가 있고, 충분히 괜찮은 아이디어라고 판단되는 수준에서 의사결정을 할 필요가 있다.

의사결정에서 필요했던 여러 가지 가정들, 가설들은 추후 오류로 판명되면 의사결정이 빠르게 번복될 필요가 있으므로 이에 대해 잘 정리를 해두는 것은 충분히 좋은 의사결정을 내리는 조직이 반드시 갖춰야 할 절차적 방법론이다.

스스로 생각하게 하는 노력이 중요

앞의 두 가지 기준에서 봐도 구성원들이 스스로 생각하게 하는 게 가장 중요한 전제 조건이다. 어떤 수단과 절차가 절대적인 요건일 수는 없다.

구성원들이 가진 목표를 공유하고 remind하거나 벽에 부닥친 구성원을 주변에서 빠르게 도와서 벗어나게 해주는 등 여러 가지 병렬성, 동시성을 높이는 방법들은 문화적으로도 보완할 수 있다.

하지만, 중요한 것은 구성원들이 사람이기 때문에 사람이 무언가를 학습하고 집중하고 아이디어를 내고, 스스로의 에너지를 재충전하는 등의 메커니즘은 사람에 대한 이해에서 출발한다.

중요하고 어려운 문제일수록 여러 번 생각하게 하고 같이 얘기하는 것은 매우 중요한 수단 중의 하나이다.

어떤 절차가 필요할지 혹은 문화적으로 항상 서로에게 도움을 요청하고 도움을 주고 또 이슈를 에스컬레이션하는 문화를 만들어 자율적으로 할지는 구성원들의 특성과 수준 등을 고려하여 판단할 수 있다.

하지만, 생각을 하는 주체가 많을수록 좋다는 것은 변하지 않는다.

기술적인 깊이가 필요한 생각들에 아직 미숙한 사람들을 포함시켜야 하는 것은 결과적으로 더 많은 생각, 아이디어를 가져오게 한다. 이것이 코칭의 핵심 중 하나이다.

관리가 많고 피드백없는 수직적 의사결정이 반복될수록 의사결정 수준도 떨어지고 병렬성도 지시를 기다리기에 급급해 떨어질뿐아니라 실제로는 생각의 병렬성이 아닌 기계적인 업무 병렬성만 진행될 수 있으므로 관리 계층을 최소화하고 아이디어들을 더 많이 구성원들로부터 이끌어내고 반영하려는 노력은 일상적으로 이루어질 필요가 있다.

솔루션 기능 만들 때 우선순위 판단 기준

2021-09-05T15:38:00.003+09:00

제품 기능 만들 때 우선 순위 판단.

1. 꼭 필요한 기능, 이 중에도 복잡도가 높은 기능과 핵심 경쟁력이 될 차별성을 줄 수 있는 기능은 더 가중.

2. 당락을 결정하는 기능 항목은 명목만.

3. 그냥 필요할 것 같은 기능, 좋아보이는 기능은 끝까지 미루다가 실 요구사항이 생기면 …

Straightforward 기능들은 언제든지 만들 수 있지만 복잡도가 높은 경우는 시행착오와 아이디어가 더 많이 필요하기 때문에 개발 시간의 변동성이 커서 좀더 일찍 파일럿 개발을 해가면서 검증이 필요합니다.

사실 복잡도가 있는 기능은 시간을 미리 계획해서 하는 건 무의미하기도 해서 조직적으로도 우선순위를 높이고 계속 아이디어를 공유해서 핵심 문제의 해결책을 검증하고 나야 유의미한 시간 계획을 세울 수 있죠.

복잡도 = 미검증된 주요 이슈가 있는 경우.

즉자적인 단순 아이디어로 개발할 경우 quality가 떨어져 솔루션으로서 가치를 이야기할 수 없는 경우라고 생각할 수 있습니다.

어떤 경우에도 솔루션 성격을 띄는 제품이나 서비스는 핵심 문제를 해결하려면 중요한 요소는 있게 마련이고 그중 아이디어가 필요한 복잡한 요소를 찾는 것은 가장 중요한 과정 중 하나라고 볼수 있어요.

문제를 인지하면 생각을 거듭하고 또 모을 수 있기 때문에 해가 되는 아이디어가 나오기 마련이니까요.

O&KR 가설과 검증, 그리고 실제 적용

2021-08-14T14:30:00.004+09:00

O&KR, 가설과 검증

구글이 전통적인 관리 기법은 모두 거부했지만 O&KR(목표와 핵심결과) 방식은 채택했다는 것은 잘 알려져 있는데

엄청난 인재들을 모아두고 불필요한 간섭을 하기보다는 스스로 목표를 설정하는 최소한의 관리 원칙만 두겠다는 것이었다고 생각한다.

목표 설정은 생각의 방향에 관한 것이니까 전반적으로 어떤 방향으로 갈 것인지가 어느 정도 연결되도록 하는 것이 핵심이고 그외에는 자율적으로 판단할 수 있게 했다고 생각할 수 있다.

목표 설정 외에 핵심 결과를 지표로 두는 것은 과학적 사고의 핵심과 연결된다고 생각하는데 구글에서는 핵심 결과 즉, Key Results를 평가 지표로 생각하지 않았고 스스로 목표를 구체화하는 검증 방법으로 바라보았다.

검증할 수 없는 추상적 목표를 검증 가능한 구체적 결과물로 리타겟팅하여 사고할 수 있게 해주는 것으로 가설과 검증에 관련된 과학적 사고 기법과 연결된 관리 방식인 셈이다.

물론 O&KR의 핵심 결과는 엄밀한 검증을 위한 것은 아니다. 목표를 직간접적으로 측정할 수 있는 방법을 설정하는 것이며 목표를 정량화한다기보다는 목표의 수준 혹은 개인적 방향을 간접적으로라도 계량할 수 있는 숫자이면 충분하다고 본다.

구글의 가이드라인을 보면 너무 쉬운 목표가 되거나 너무 어려운 목표가 되지 않도록 개인이 판단하기에 60~70% 달성을 목표로 할 수 있는 수치를 잡으라고 권고한다.

분기별로 알아서 업데이트하는 방식으로 최소한 분기별로는 한번 더 목표를 구체적으로 생각할 수 있게 해서 중점적으로 생각하는 방향을 스스로 관리하는 관리 방법이라고 할까.

(O&KR을 평가 지표로 사용하는 경우도 있는데 그런 경우에는 좀더 KPI에 가까워지리라고 생각한다.)

우리는 과학이란 용어를 쉽게 사용하면서 검증을 게을리하는 것을 종종 본다.

과학이 절대적인 답을 주는 경우는 그렇게 많지 않다. (어쩌면 그것이 과학과 수학의 차이점일지 모르겠다.)

요즘은 데이터가 모든 것이라는 슬로건과 함께 데이터 중심이란 말을 하면서 인과관계 혹은 메커니즘에 대한 가설을 세우지 않고 데이터만 수집하거나 기계적으로 결론을 도출하는 경우도 종종 본다.

개인적으로는 모든 선험적인 결론은 한계가 있다고 생각한다.

모든 가설은 회의할 필요가 있고, 검증할 필요가 있다.

완벽한 검증이 아니더라도 가설은 좀더 풍부할 필요가 있고 인과성을 분명히 할 필요가 있으며, 그 결과는 잠정적으로 존중되고 또다른 가설과 검증으로 이어질 필요가 있다.

O&KR은 최종적인 과학적 결론을 요구하는 기법은 아니다.

단지 스스로는 목표의 수준과 성취 방향성을 가늠해보는 시도를 하게 만든다.

이 과정이 반복이 되고 계속 방향을 조정하면서 개선하다보면 군집된 결과는 미리 계획된 방향에 비해 다양할지 모르지만 큰 방향은 유지하면서도 개인의 다양성과 편차를 그대로 표현되게 할 수 있다.

O&KR 실제 적용할 수 있을까

O&KR을 연구개발 조직에 적용하려는 노력은 한 10년째 하는 것 같다.

목표 관리를 잘하는 친구들은 사실 아무런 어려움 없이 metric인 key result도 편하게 잡지만 그렇지 못한 친구들도 상당수 있었던 것 같다.

지금 조직에서도 목표 설정과 핵심 지표 설정을 하다보면 일부는 6개월 가까이 수립을 못해서 결국 목표다운 목표를 수립하지 못하기도 한다.

자신이 하는 일에 의미를 부여하는 일이 어떤 이에게는 당연한 일이지만 어떤 이에게는 매우 힘든 일이기도 한 셈이다.

수명 업무에 익숙하거나 작은 미션에만 익숙한 사람들은 스스로 목표를 설정하는 일을 힘들어하는 경향이 있다.

물론 그 얘기는 협업의 수준이 높지 않고 주어진 일만 해왔다거나 스스로 할 일을 정하기 어려운 강한 드라이브가 항상 주어져있었을 가능성이 있다.

그럼에도 불구하고 구글과는 너무나 다른 구성원, 조직이지만 목적 설정과 목표 수준의 수립은 지식 노동을 하고 자율성을 중요한 덕목으로 삼는 조직에게는 매우 중요한 관리 방식이라고 생각한다.

모든 사람에게 이 방법이 최선이긴 어렵다고 생각한다. 이루고자 하는 동기부여가 작을수록 이 방법은 효과를 발휘하기 어렵다.

개인적으로는 KR을 정성적인 요소를 계측할 수 있는 부수적 지표라고 부른다. 사람은 생각하는 방향으로 움직인다. 생각에 방향성을 서로 공유하는 것이 가장 중요하고 나머지는 전문가들인 이들이 알아서 길을 서로 물으며 찾아가면 된다고 본다.

너무 늦지 않게 목표를 다시 조정하거나 다시 수립할 수 있는 기회를 자연스럽게 제공하면 그것으로 가장 중요한 관리의 역할을 하는 것이라고 생각한다.

매니저의 역할

2021-07-18T08:53:00.005+09:00

매니저는 목표와 방향을 다루는 역할이다.

매니저가 아니라도 목표가 중요하지만 개별 목표와 그룹이나 조직의 목표는 다를수밖에 없고 어떻게 방향을 집합적으로 정렬해갈 것인가가 매니저의 핵심 미션이다.

좀더 개인들의 역할이 목표에 기반해있고 조직의 방향과 스스로 연결지어 간다면 관리 계층 구조를 좀더 줄여갈 수 있을 것이다.

관리 구조가 여러 층으로 수직화되면 매니저의 커뮤니케이션 역할이 더욱 중요해지는 반면 그럼에도 불구하고 전반적인 수동성이 높아지고 의사결정들이 복잡해지고 추상적이 될 우려가 있다.

목표의 공유는 사람들이 어떤 방향으로 생각을 한번 더 하게 할것인가의 문제이고 매니저의 의사결정은 그 사람들의 생각을 수집하고 수렴하고 체계화하는 것이라고 볼 수 있다.

지적인 문제 해결이 핵심인 조직에서 매니저의 의사결정이 방향에 대한 것을 빼고 나면 대부분 멤버들의 생각에 기반할수밖에 없다.

물론 충분히 좋은 생각을 만나지 못하고 시간만 흐를 경우에는 매니저 스스로 생각을 만들고 잠정적인 결정을 하는 역할도 있겠지만 대부분 보조적 역할이어야 잘 활성화된 조직일 것이다. (좋은 아이디어에 대한 판단 능력과 수렴 능력은 필수)

매니저의 보조적 역할은 멤버들의 질문을 도와주는 것이 멤버들의 솔루션을 도와주는 것보다 중요한 역할이라 할 수 있다

하지만 매니저가 항상 숟가락 얹기(?)만 하면 단순 논리의 중재, 정리 역할을 할 우려가 있는데 집단의 수준에 따라서 큰 문제가 안될수도 있겠지만 결과적으로는 대부분 단순한 추인의 의사결정이 된다고 하더라도 (그렇게 된다면 매우 좋겠지만) 결정의 방향성에 좀더 장기적인 관점을 부여하기 위해 훨씬 많은 노력을 기울여야 한다.

우수한 인재들이 많다면 장기적인 관점과 방향성에 대해서도 좀더 오픈하고 자주 논의하면 좀더 나은 숟가락을 만들 수 있을 것이다.

내가 하고 있는 일에 대해 스스로 어떤 목표를 부여하고 일정 간격으로 리마인드하게 하는 것, 너무 자주일 필요는 없지만 가끔씩 목표를 다시 생각하게 해주는 게 사실 가장 중요한 관리의 목표일 것이다.

(O&KR이 이런 관점에서 발전한 관리 방식이라고 생각)

지능

2020-11-01T15:29:00.002+09:00

지능을 이루는 건 크게 두 가지밖에 없는 것 같아.

하나는 집중의 수준과 지속력.

하나는 끝까지 목표를 향해 물고늘어지는 추진력.

첫번째는 타고 나는 것도 상당한 것 같고 학습을 통해 강화하는 것도 맞고...

두번째는 인생이 길기 때문에 더 중요한 ...

백발이 성성한 코더는 아름다운 꿈일까

2020-10-04T18:54:00.002+09:00

image from xkcd.com

나이가 들어도 코딩을 할수 있는 건 맞지만 단순히 코딩 능력의 관점에서만 본다면 능력이 감소하는 것도 맞다.

미국에서 볼수 있던 백발을 휘날리는 코더는 대부분 COBOL 개발자들이었겠지만 실리콘밸리의 미래에 중장년의 코더가 어떤 역할을 할지는 모르겠다.

내 생각에 코더로서의 전성기는 사람마다 다르겠지만 40대 후반(45~48 무렵)이 아닌가 싶다.

코딩에 필요한 여러 경험의 축적에 따른 판단 능력을 충분히 고려해서 꾸준히 자기 관리를 학습과 체력면에서 가꾸어왔을 경우를 가정했을 때.

코딩이란 게 단순 개발을 뜻하는 건 아니므로 아키텍처나 질적 관점, 소통 능력, 협업 능력 등등을 고려했을 때 관리 측면과 개발 측면을 분리해서 개발 측면만으로 볼 때 이런 판단을 할수 있다.

성과 위주 관점에서는 순수 개발 역할만 하는 이의 나이는 관리를 잘하더라도 한계가 온다는 뜻이다. 직업적 운동 선수가 나이 한계가 있듯이.

한계는 경험적으로 보면 아무래도 집중하여 판단할 수 있는 시간이 줄어드는 데 있다. 장시간 집중해서 상세 판단을 하는 능력은 떨어질 수밖에 없다.

흔히 말하듯 추상 능력의 향상이 보완할 수 있을텐데 그 추상 능력이란 젊은 친구들보다 훨씬 더 오랫동안 판단을 거듭한 이들이 당연히 가지는 결과물인 거라고 생각된다. 그렇게 관리하지 못한 경우는 오히려 사고의 가소성 부족으로 학습 능력이 떨어지고 소통 능력도 떨어져서 급격하게 코더로서 부적격해질 우려도 있다.

꾸준히 학습하고 자기 관리를 한 경우 코딩 속도나 판단 능력에서 급격한 저하는 없다. 다만 더 좋아지기 어렵다.

나이가 든다고 개발 일을 못할 건 아니다.

하지만 굳이 개발 일을 시니어에게 맡기는 시장은 훨씬 좁기 마련이다. 경험과 협업적 코칭 등 단순 개발 관점 이외의 요소들이 필요한 시장인데 젊은 친구들과 소통하는 건 매우 도전적인 일이기도 하다.

세대간 문화의 차이를 무시할 수 없는데 개발 조직은 젊은 친구들의 문화를 기준 규범으로 상당 부분 기초해야 하고 어떤 방향성을 주는 코칭 역할을 해야 한다.

물론 조직이 아니라 개인으로서 개발하는 건 다른 일이다. 전성기에 비해 90% 정도의 능력을 발휘한다고 큰 문제가 생기진 않는다. 다만 혼자 개발하려면 개발 이외의 부문에서 유의미한 통찰을 갖추어야 한다.

그런 의미에서 보면 나이 들어서도 순수 개발이란 생각은 매우 협소하고 불안한 입지를 갖는 셈이다.

무게를 어느쪽에 두더라도 순수 개발이긴 어렵다. 장기 연구를 목표로 하는 직군은 아니기 때문이다.

개인적으로는 코딩보다는 문제의 설정과 해결이 더 본질적인 목표라고 생각하므로 코딩을 하고 안하고는 중요하게 생각하지 않는 편이다. 다만 팀웍을 통해 문제 해결을 할 때 구체적 판단이 필요할 때 직접적인 코딩이 판단이나 코칭에 도움을 줄 때가 많아서 최소한의 코딩은 꾸준히 하는 편이다.

45세 정도부터는 순수(?) 코더는 가치를 인정받지 못할 가능성이 높다. 물론 동료들이 서로 부족한 부분을 잘 메꿔줄 수 있는 조직에서는 자기 가치만으로도 충분히 역할할 수 있겠지만 그 조직에서만 큰 가치를 낼 가능성이 있다.

참고. 이런 기사도 있었네요.

Top programmers who write code after 40 years

Java 15에 Biased Locking이 deprecate 된다.

2020-09-19T18:25:00.004+09:00

최근 릴리스된 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은 contention이 발생할 때에는 오버헤드가 있다.
이런 낙관적 최적화는 어느쪽이 더 전형적이냐가 분명할 때 효과가 있다.
Java 15에서 biased locking을 제거하면 기존 코드들 중 이건 biased locking 덕분에 큰 차이가 없어 하고 넘어갔던 코드들이 모두 영향을 받을 것이다.
15년 가까이 biased locking을 전제로 decision을 했던 터라
약간 난감하다. 물론 가능하면 StringBuilder,ArrayList 등을 쓰는 건 당연했지만 약간 API적으로 선택이 모호한 경우에는 biased locking을 고려하여 lock free 모듈을 만들지 않고 넘어갔던 경우가 계속 떠오른다. (ByteArray stream 같은 경우는 별도로 Lite 클래스를 만들어 쓰긴 했지만 항상 그럴 수 있었던 건 아니다)
제거를 결정한 근거는 대부분 코드들이 lockfree new API로 옮겨갔다는점과 contention이 많은 ThreadPoolExecutor 같은 코드에서 오버헤드가 꽤 크다는 점을 들고 있다. 공감한다.

다만 약간 뒷골이 당기는 느낌이 있다. ㅠㅠ

수많은 decision들을 되돌릴 수도 없고...

참고자료(PDF) : 2006년 JVM biased locking 설명자료

근래 최고의 Java 혁신은 GraalVM Native Image가 아닐까

2020-09-07T16:18:00.003+09:00

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 바이너리로 쉽게 빌드할 수 있게 된 것이다.

물론 앞에서 설명한 대로 jni list나 reflection list 등을 찾아서 지정해주는 약간의 삽질은 감수해야 한다. ㅠㅠ

참고 : Gluon Substrate and GraalVM Native Image with JavaFX support

최근 자바는 오라클과 구글의 소송을 거치면서 많이 관심이 줄어들었다.

그럼에도 최근 몇 년을 걸쳐 자바의 가장 놀라운 혁신을 들라면 단연 AOT 컴파일 아이디어를 전면 적용한 GraalVM, 그 중에서도 하나의 바이너리를 만들어주는 GraalVM Native Image를 들겠다.

마틴 파울러가 소프트웨어 아키텍처를 the important stuff이라고 했다.

2020-09-05T19:27:00.005+09:00

마틴 파울러가 짧은 강의를 통해 소프트웨어 아키텍처란 the important stuff 라고 정의한다.

아키텍처는 두 가지 측면을 가지고 있다고 하는데 "이해를 함께 해야 할 부분"이자 "변경이 어려운 부분"이라고.
이 두가지가 합쳐져서 "중요한 무언가"를 이루는데 이것을 아키텍처라고.

공감하는 부분도 있지만 소프트웨어 아키텍처를 너무 컴포넌트 중심으로 바라보는 것 같다.
시스템 구조적 측면을 단순히 컴포넌트로 보기는 어렵다.

구조의 측면을 고려하면 무조건 변경이 어려운 것은 아니다.
사실 시간의 기준으로 보면 그렇게 어려운 게 아니고
어렵다는 것을 마틴의 얘기 중 하나인 "지식의 깊이"로 보면 맞다고 볼 수 있다.

"지식의 깊이"를 가진 사람들이라면 아키텍처는 하나의 aspect처럼 간주될 수 있다.
물론 비즈니스 로직은 잘 동작하고 최소한의 가독성을 가진 코드들로 구성되어 있다는 가정 하에서.

아키텍처는 리팩토링처럼 일상적일 순 없지만 계단식 개선이 간헐적으로 발생해야 하는데, 시간적 관점에서도 hard to change이면 그 소프트웨어의 품질은 나오자마자 이미 한계에 달한 것이 된다.

소프트웨어나 서비스의 아키텍처 측면 품질은 매우 중요한 결정적 요소가 되기 쉬운데 이를 개선하기 위해서는 개발 조직은 아키텍처를 이해할 수 있는 지식의 깊이를 갖춰야 한다고 단순 결론을 내릴 수 있다.

Websocket Java spec에 대한 단상

2020-08-25T00:57:00.003+09:00

WebSocket 프로토콜은 하나의 tcp (실제로는 http 확장 형태) 소켓으로 여러 개의 논리적 연결인 세션 개념을 지원한다.

그런데 tcp 레벨에서 같은 연결을 사용하기 때문에 논리 세션은 각 특성에 따라 효율적이기 어렵다. 적당한 크기의 프레임이란 메시지 단위로 잘라서 여러 세션 메시지를 섞어 보내다보니 원래는 하나의 양방향 큐를 구성하는 tcp 연결을 다시 에뮬레이트해야해서 오버헤드가 있다.

자바 웹소켓 스펙을 보면 메시지 유형이 스트림이면 큰 메시지라고 간주하여 매 프레임별로 별도의 쓰레드로 보내고 그렇지 않으면 하나의 쓰레드로 보내게 되어있는데 나는 이 스펙은 지나친 쓰레드 모델과 메시지 유형의 커플링이라고 본다.

오히려 큰 파일일수록 순서대로 하나의 쓰레드에 큐로 보내고 작은 프레임들이면 알아서 처리하라고 worker로 보내거나 했어야 정상적인 (효율적인) 처리 구조일 것 같고 아니면 그냥 열어뒀어야 할것 같은데 Java EE 스펙에서 과도한 개입을 해서 망친 듯.

그런데 websocket과 같이 여러 개의 논리 연결을 위해 하나의 물리 연결을 사용하는 것 자체가 효율적인 발상은 아니다. tcp의내부 최적화를 깨는 형태가 되는 셈이니...

그저 브라우저가 http 연결하면서 서버로부터 push 메시지 받는 용도로만 제한적으로 쓸 일이지...

생각해보니 일전에 본 용례는 http로 passive connection을 못 만들어서 이런 복잡한 websocket을 쓰려고 하고 있었다 ㅠㅠ

tcp로 하는 것과 다른 게 없을텐데 ㅠㅠ

R&D 조직 관리 - 목적 지향성, 협업성, 성장

2020-08-22T16:01:00.003+09:00

관리는 정적인 프로세스가 아니다

팀장의 역할은 이러하고 프로세스는 이래야 하고 ...

관리를 정적인 형태로 이해하는 경우 흔히 나오는 이야기이다.

실제로 관리자가 조직 성원들 간에 기술적인 의사 결정을 하는 것을 절차적인 부분만 생각해서 round-robin, random, expert 등에게 맡기는 경우도 있고 혹은 위계 조직답게 일방적으로 결정하고 지시만 하는 경우도 많다.

R&D 조직은 기술적 검증을 보통 조직 성원이 1차 진행하므로 의사 결정과 검증이 분리되는 현상은 의사 결정의 오류를 키울 가능성이 높다. 하지만 개인이 완벽하게 검증한 내용 기반으로 의사결정 하는 것은 일반적으로 더 나은 결정을 가로막을 가능성이 크다. 특히 각이한 수준, 각이한 경험의 개인들이 항상 조직 관점에서 최선의 선택을 하기는 쉽지 않다.

매니저는 상대적으로 더 많은 정보를 접하는 허브 역할을 하기 때문에 정보 접근성 관점에서 보더라도 앞에 설명한 다양한 의사결정 규칙은 적은 정보로 결정을 요구하게 되므로 큰 오류가 있다.

일방적 의사결정

경험적으로 최악의 매니저는 의견을 청취하지 않고 지위를 사용하여 결정하는 유형이다.

기술 회의의 의견은 기술적 관점이어야 하나 지위를 발언권으로 이해하고 아무 얘기나 마구 해서 실질적인 회의의 집중과 심화를 훼방하는 습성을 가진 경우다. 기술적 의사 결정을 위한 회의가 딱딱할 필요는 없고 다양한 의견을 폭넓게 듣기 위해 범위를 가능하면 제약하지 않는 게 좋지만 습관적으로 생각 없이 말을 하는 습성은 여러 사람의 시간을 낭비하게 하는 큰 장애물이다.

의사 결정에서 지위는 물론 존중되어야 하지만, 청취를 통해 더 나은 지식과 아이디어를 의사 결정의 근거로 만들지 못하는 것은 최악의 권위적 결정이 되고 이 과정에서 배제된 부원들은 점점 더 흥미를 잃고 수동화되고 성취욕이 강한 친구들은 능력을 발휘할 수 있는 곳을 찾아 조직을 떠날 것이다.

의견을 청취하는 것은 어려운 기술은 아니지만 훈련없이 그냥 얻어지진 않는다. 의견을 이해하고 판단하는 경험이 누적되면 좀더 나은 청취를 할 수 있을 것이다. 청취의 수고와 시간에 대한 긴장감이 있겠지만 청취의 가치를 충분히 이해하려고 한다면 점점 더 의견을 이해하고 반영할 수 있을 것이다.

목적 지향성이 전제

기업은 목적 조직이다. 여러 가지 목적에 따라 조직을 구성하고 각 개인별로도 직간접적으로 업무의 목적을 기업의 목적과 연동하기를 원한다

구글에서 차용해서 화제가 되었던 O&KR(목표와 핵심 결과) 관리는 이러한 관점을 반영하고 있다.

목적 지향성은 조직과 개인의 다양한 활동을 목적에 비추어 방향을 잡도록 하는 것인데 개인들이 현재 주어진 업무를 정태적으로 받아들이지 않고 목적을 고려하여 더 많은 생각을 하게 해준다.

국내에서는 O&KR을 KPI와 같은 평가지표로 이해하는 경우가 있는데 그렇게 하면 목표 설정을 좀더 본질적으로 하기 어렵지 않나 생각된다. 굳이 O&KR이 아니더라도 업무를 목적에 맞게 재해석하거나 재수립하는 게 일상이 될 필요가 있고 이를 통해 개인들이 좀더 목적의 방향으로 생각하고 의견, 아이디어를 만들고 나눌 수 있어야 목적 지향성이 개인에게까지 확산된다고 볼수 있다.

협업과 참여, 성장 등 추가된 가치들은 목적 지향성을 전제하고 논의해보자.

아무도 말을 하지 않는다

집단 지성을 얘기하면 매니저들로부터 흔히 듣는 하소연이 회의에 사람들을 모아도 ‘아무도 의견을 내지 않아요’이다.

우리 직원들은 모두가 수동적이어서 아무런 말도 하지 않는다는 것이다.

회장님, 사장님이 참석한 회의에서 일반 직원이 의견을 쉽게 낼 수 있는가? 왜?

이런 상황에서는 대부분 묵시적으로 의견에 대해 큰 책임을 요구하기 때문에 자유롭게 생각을 얘기할 수 없다.

게다가 회의 도중 한번 큰소리가 나서 의견을 진압하는 일이 생기면 의견은 다시는 나오지 않을 것이다. 관리자급 회의는 책임감 때문에 조금 다르긴 하지만...

대부분의 직원들은 사실 적극적으로 의견을 개진하려고 하지 않는다. 그 이유는 관련하여 많은 생각을 하지 않았기 때문이다. 평소에 잘 알고 있고 생각을 해본 주제는 특별한 장애만 조성하지 않는다면 의견을 제시할 것이다.

그런데 실무 담당자들이 모인 회의에서도 의견이 없다는 것은 어떤 의미일까?

하나. 합리적 의견들이 의사 결정에 제대로 반영된 경험이 없어서 회의를 신뢰하지 않는 경우가 있을 것이다.

관리자는 먼저 의견을 청취하려고 노력해야 한다. 먼저 관리자들이 큰 의견을 내기 시작하면 작은 의견을 내기 머뭇거리게 될 것이다. 위계적 분위기가 직위 뿐만아니라 선임, 후임 간에도 고착된 병영 분위기라면 더 젊은 의견은 나오기 어려울 것이다.

관리자들일수록 좀더 깊이 생각하고 나중에 의견을 내는 게 좋다.

의사 결정은 참여한 사람들을 위해 충분한 설명이 필요하다. 약간 불필요할 정도로 자세하게 판단 이유를 설명할 필요가 있다. 그 과정에 참여한 사람들의 합리적 아이디어가 설명없이 무시되면 참여한 사람들은 모두 다음 회의부터는 의견을 내려 하지 않을 것이다.

둘. 주제가 회의에서 논의되기에 참여자의 준비가 부족한 경우가 있다.

브레인스토밍 수준의 회의에서 모든 걸 결정하려고 하면 안된다. 이런 경우엔 회의에서 주제의 성격과 도움을 얻을 만한 정보를 브레인스토밍하여 공유한 후 좀더 자세하게 준비할 사람을 지정하여 다음 회의를 준비하면 된다.

흔히 말하는 time-to-market이 무리한 의사결정 혹은 무조건 빠른 결정으로 이해되는 경우를 종종 본다.

무조건이 아니라 충분함이 기준이 되어야 한다. 충분함의 기준은 이해와 공유 그리고 아이디어의 충분함일 수 있고 한번 결정은 너무 늦지 않은 시점에 보완 변경되는 것이 일반적으로 좀더 나은 현실적 의사결정이라고 생각한다. 조급함은 비즈니스는 물론 조직도 망가뜨린다. 물론 생각 자체도 막는다.

충분한 의사 결정은 더 많은 사람들이 집중해서 생각하고 분석하는 시간을 거쳐 회의를 통해 아이디어를 공유하는것을 뜻한다. 그럼에도 급한 아이디어는 오류를 내포할 것이므로 보완할 수정안을 1,2주 정도의 기간을 두고 준비하는 게 가장 낫다고 경험적으로 생각한다.

신입이라 할수 있는 게 없어요

업무를 분배함에 있어 어떤 관리자는 매우 마이크로하게 잘게 쪼개서 세세한 지시를 포함해서 업무를 정의하는 경우가 있다.

스마트한 직원이라면 답답해서 일을 못할 것 같은데 뿐만아니라 업무의 성격과 진행방법을 담당자가 재규정하는 과정이 생기기 어려워 담당자는 업무의 소유자가 아니라 수동적 행위자가 되며, 그 결과로 사고의 범위가 좁아지고 업무를 통해 배울 수 있는 게 사라진다.

연구개발에 종사하는 사람들은 주니어든 시니어든 끊임없이 기술의 변화를 학습하고 깊이와 커버리지를 확대할 필요가 있다. 학습과 성장은 업무 자체를 통해 일어나야 한다고 생각한다.

일의 범위를 한 사람이 충분히 설계부터 아이디어까지 생각할 수 있는 분량으로 나누는 것은 업무를 통한 성장이라는 관점에서 매우 중요하다.

‘신입이라 일을 줄 게 없어요’

이런 말을 자주 듣지만 크게 잘못된 생각이다. 일은 혼자 하는 게 아니다. 먼저 혼자 생각을 충분히 해보게 하면 신입도 많은 경우 잘 하기도 하지만 단계별로 협업적 검증과 개선 아이디어를 공유하겠다는 협업적 관점이 없는 게 잘못되었다.

신입이 아니라 주니어든 시니어든 단계를 좀더 좁히거나 늘릴수는 있어도 상호 공유와 리뷰, 주요 이슈 관리는 모든 이에게 필요하다.

연구개발이 점점 더 팀플레이로 바뀌고 있는 것은 일시적 유행이 아니다. 한 사람의 아이디어보다 여러 사람의 더 많은 아이디어가 더 나은 결론을 만들 수 있다는 지극히 당연한 과학을 반영한 방향이다.

항상 성장을 의사결정 기준에 포함하자

지금 당장 급한 일이 급한데 어떻게 신입이 잘하길 기다렸다가 하겠느냐고 반문할 수 있다.

물론 매우 급한 일을 아직 검증되지 않은 이에게 맡기는 것은 리스크를 높이게 된다. 그 의사결정은 그에 맞는 요소를 고려해서 하면 된다.

하지만 지식 노동의 특성 상 좀더 많은 생각을 하게 하고 좀더 많은 아이디어를 반영한 좋은 의사결정을 하는 것은 단순히 시간과 수의 문제로 끝나지 않는다. 사람은 경험을 통해 학습하고 학습을 통해 성장한다.

좀더 학습에 유리한 경험을 만들어주고 이를 통해 성장하면 훨씬 더 나은 지식과 아이디어로 문제해결할 수 있는 역량을 갖추게 된다.

당신의 조직 모델은?

조직이 100명이라면 100명이 아이디어를 내고 문제의 성격에 따라 여러 사람의 아이디어를 이합집산하며 merge하는 모델을 상상해보자.

몇명의 매니저가 그들만의 아이디어로 100명을 끌고가는 모델을 생각해보자.

비교하여 어떤 조직 모델이 더 나은결과를 내며 또 이를 통해 사람들을 성장시켜줄 것인가?

당신의 조직은 어떤 모델이며 어떤 목적을 갖고 있고 어떤 합목적적 결과를 만들며 어떤 성장을 개인과 조직이 이루고 있나?

튜닝을 하려면 무엇을 고려하여 기준점을 잡아야 하나

2020-08-17T18:07:00.006+09:00

(작은 에피소드였지만 흔히 접하게 되는 일이다.)

"웹크롤러 사용해서 데이터 수집이 일주일 걸리던 것을 멀티 쓰레드로 돌려서 1일 걸립니다. 멀티 쓰레드로 바꿀 때 concurrency 문제를 해결하기 위해 O(1) 복잡도를 가진 CopyOnWriteArraySet을 사용하였습니다."

이런 뿌듯한 발표를 듣고 너무 답답했다.

물론 O(1) 복잡도도 완전히 틀린 얘기이고 (아마도 array list의 배열 색인 접근 시 연산 복잡도를 잘못 본듯) 배열을 중복 허용하지 않은 기반 자료구조로 쓰기 때문에 조금만 커져도 접근이든 삽입이든 엄청 느리겠지만 무엇보다 concurrent 자료구조이다. COW는 빈번하게 변경이 여러 쓰레드들간에 걸쳐 발생하는 상황에서는 전혀 적합하지 않다. Concurrency 문제가 개별 연산 복잡도보다 훨씬 지배적인 상황이다.

하지만 개별적인 오류는 차치하고 성능 최적화를 할 때에는 병목이 무엇이고 시스템 자원이 포화가 되는지를 기준으로 판단해야 하는데 전혀 고려되지 않는다.
네트웍 대역은 아직 널널하고 CPU 자원도 별로 일을 하지 않는데 (물론 자료구조와 concurrency logic을 잘못 선택해서 좀 많이 낭비하긴 한다) 기준 시간이었던 7일(너무 naive한 구현)이나 개선한 1일이나 큰 의미가 있을까.

Enough 라는 기준을 만족하면 되는데 하루라는 시간이 어떤 경우에 만족이 될까.

"시스템 자원을 70~80%까지 활용도를 높였는데 더 이상은 기존 로직을 세부 변경해야 해서 성능 때문에 논리 가독성을 포기하는 것은 희생이 커서 이만큼만 튜닝했어요." 이런 결론이 나야 하지 않을까.

학교마다 다르긴 하지만 많은 수도권 대학에서도 이제 운영체제와 같은 시스템 과목은 잘 가르치지도 않고 학생들이 수강하지도 않는다고 한다. 자바와 python, 웹 프로그래밍 중심의 대학 과정이 실용성의 이름으로 이루어진다.
놀랍게도 코딩만 가르쳐서 청년 실업을 해결하겠다는 움직임도 보이는데 인공지능 시대 소프트웨어의 핵심이 코딩일까? 점점 더 코드의 영역은 줄어드는데?

알고리즘 중심의 코딩 테스트가 지나치게 확산되는 것도 사실 우려스럽다. 검증된 우수 인력만 선발하는 기업과 사회 초년생을 선발하는 기업 간에 이해의 차이가 있을 순 있겠지만...
사고력, 문제 해결 능력을 검증하려면 좀더 균형 잡힌 역량을 확인하고 레디메이드가 아닌 포텐셜을 중시해야 하지 않을까.

소프트웨어 관련 학과 정원을 늘려야 한다는 주장을 언론을 통해 보곤 하는데 숫자의 문제가 맞을까.

교육 과정이 어떤 미래를 생각하고 있는지 모르겠다.
소프트웨어 관련해서는 한국이 앞선 부분이 하나도 없다는 걸 현실을 모르는 IT 선진국론에 빠져 있는 건 아닌가.

뭔가 다른 방향의 노력이 필요한 것은 아닐까.

(아래 그림은 리눅스 성능 문제를 분석할 때 사용할 수 있는 할 툴들. 해당 블로그 참조)

Spring Framework - an inversion of control container

2020-08-08T19:18:00.001+09:00

2015년 11월 17일에 발표했던 스프링 프레임웍

Spring Framework - Inversion of Control Container from Kyung Koo Yoon

컨테이너 가상화와 쿠버네티스

2020-08-08T18:51:00.002+09:00

2019년 7월에 강의했던 쿠버네티스 자료

Kubernetes from Kyung Koo Yoon

첫번째 코딩 과제

2020-06-20T17:41:00.007+09:00

신입 사원들이 들어오면 가장 먼저 하는 것 중 하나가 아주 간단한 프로그램을 작성해보도록 숙제를 내주는 것인데 코딩을 해본 경험이 적은 이들에게 목표를 주고 그 목표에 따라 소프트웨어 코드를 작성하는 것은 매우 중요한 일이다.

물론 회사 뿐만아니라 학생의 경우에도 처음은 있다.

경험적으로 첫번째 아주 짧은 코딩 과제는 Tic-tac-toe나 사다리 게임을 주는 편이다.

보통 학생에게 가이드한다면 다음과 같이 접근을 한다.

코딩은 반드시 직접 해봐야 돼.
먼저 생각을 해보고 궁금한 것은 물어보고 해서 한 사이클을 해보자.
틱택토 게임을 콘솔로 만드는 걸 해보면 되는데 먼저 스펙을 정해야 돼. 위키피디아 보고 판단해봐.

https://en.m.wikipedia.org/wiki/Tic-tac-toe

하나씩 단계를 밟아야 하니까.

먼저 언어를 정하고.
C로 하라고 하고 싶지만 먼저 좀더 간단하게 할수 있는 java나 python으로 해도 돼.
Java를 해봐야 하니까 자바로 시작하면 되겠다.

1. 언어 결정 (자바 추천)

2. 게임 구상

2.1 위키피디아 보고 룰 이해

2.2 1인용, 2인용 (2인용이 쉽겠지? 1인용은 컴퓨터 자동 플레이 지능을 구현해야 하니까!)

2.3 콘솔, 그래픽 (콘솔부터 하는 거지. 그래픽은 나중에 붙여도 되니까. 항상 독립적인 요소를 단위를 너무 크지 않게 빌딩해가는 습관이 필요해. Divide and conquer하면 어떤 큰 것도 해결 가능!)

3. 모듈 구상 (어떤 파트들을 개발해야 하지?)

여기서부턴 먼저 생각을 해보길...

첨이니까 예시를 들자면

3.1 main 부분 (프로그램 시작부)

3.2 게임 클래스 (3x3 크기 판을 갖고 있고 처음에는 모두 빈 값. 나중에 1번 사용자가 수를 두면 X로 마킹, 2번 사용자가 수를 두면 O로 마킹할 배열 변수겠지?)

3.3 play함수. 게임 클래스 안에 있을 테고 사용자와 위치를 입력 받겠지? 그리고 룰에 따라 해당 위치에 빈 값이 아닌 다른 값이 이미 있으면 에러 처리. 빈 값이면 해당 위치에 사용자에 따라 O나 X값 저장. 그리고 게임이 끝났는지 체크. 이건 별도 함수로 만들어 호출하는 게 좋겠네.

3.4 decideEndOfGame 함수. 더 둘 데가 없거나 승부가 결정나면 이를 판단해서 게임의 끝을 알려주는 함수. 아마 가장 지능적인 함수가 될듯.

3.5 결과를 알려주는 함수

처음에는 실행하면 한 판만 하게 만들고 그 다음에는 여러 판을 할수 있게 고쳐서 기능 추가를 해보는 것도 좋겠어.

한 사이클을 체험해보자. 이 경험이 굉장히 자신감을 갖는 데 중요해~
먼저 위키피디아 보고 2.3까지 구상해봐.
예시한 것과 다르게 생각해도 돼~

R&D 조직 관리 목표를 하나로 표현하라면

2020-06-20T17:32:00.003+09:00

목표가 여러 개가 되면 기억하기도 힘들고 생각이 분산되어 추진하기도 힘들다.

메트릭이라고 하긴 어렵지만 제대로 된 방향성을 가지고 관리 체계가 돌아가는지 돌아볼 때 혹은 중간 관리자들에게 얘기할 수 있는 쉬운 관리 목표로 나는 병렬성을 얘기한다.

10명이 일을 하면 관리자를 제외한 9명의 병렬성을 보장해줘야 하는 것이 아닐까 하는 단순한 문제 제기.

이렇듯 R&D 조직 관리 시 가장 중시하는 게 parallelism을 높이는 것이다. concurrency라고 해도 좋겠다.

management에 대한 wait을 최소화하도록 개인적으로 목표를 협의하여 설정하고 스스로 생각을 하게 하는 것이다.

management의 코칭과 의사결정, 지원이 잘못되어 지연되거나 시간을 낭비하는 것을 줄이고, 더 나은 결정을 위해 단선, 다선 간 생각을 모아가는 게 쉬운 일은 아니지만, 기본적으로는 management 를 쳐다보지 않고 각 개인들이 자기 일을 하는 것이 첫 출발점이다.
management는 그 기반 위에서 조율을 할 수 있다.

어찌 보면 학습의 목적 함수에 goal에 해당하는 classification이나 regression loss를 최소화하는 항 외에 entropy를 최대화하도록 하는 항을 포함시키는 것과 비슷하다.

사실, management가 병목 역할을 하게 되는 경우가 종종 있는데 어쩔 수 없는 병목이 있는 것은 당연하지만, 너무 과도하게 친절한 코칭 혹은 자신에 대한 과도한 신뢰(?), 생각할 필요가 없을 정도로 단순화된 지시 등을 해서 개개인을 수동화하는 경우가 가장 실패한 managing이라고 본다.

생각을 하는 학습이 되지 않은 사람들을 모으는 회의에서 어떤 의견이 나올 수 있을까.

목표가 분명하면 생각을 하지 않을 수가 없고, 또 주변의 환경이 갖춰지면 쉽게 목표 중심의 사고를 배울 수 있다.

좋은 의견이란 deterministic하지 않고 stochastic하다. 그런 경우라야 collective decision이 더 나을 수 있다.

물론 collective decision의 룰이 science의 룰을 따르느냐, authoritarianism의 룰을 따르느냐, democracy의 룰을 따르느냐 그건 컨텍스트에 따라 다를 수 있다.

알고리즘적으로 best-fit, first-fit, worst-fit, random 등을 따를 수도 있고... ^^

나의 역할은 가능하면 science의 룰을 따르는 decision을 하는 조직을 만드는 것이다.

(현실은 다른 경우가 많이 생긴다. 괴롭...)

어떤 일이든 더 나은 방법이 있다는 믿음

2020-05-20T22:59:00.001+09:00

개발자보다 관리자 역할을 더 중시하게 된지도 10년쯤 되었다. (그전 10년도 관리자였지만 미안 ㅠㅠ)

지적 노동의 관리자로서 가장 중시하는 것은 어떤 문제에 부닥치든 "어떤 일이든 더 나은 아이디어가 있다고 생각"하느냐이다.

직접적으로 사람과 조직의 생각들이 열려있냐를 보게 되고

막다른 골목에 다다라서도 더 현명한 접근법이 있을수 있다고 생각하여 사람들을 불러 조언을 구하고 토론을 하게 되고

개인의 아이디어보다 토론과 서칭 등을 통해 더 많은 아이디어를 구하게 되고

의사결정에서도 wicked problem의 룰을 따라 숙려의 시간에 따른 충분한 의사결정을 하고 실행 과정에서 다시 조정하는 것을 기본으로 삼게 된다.

물론 지적 노동이니만큼 아이디어를 낼수 있는 사람들의 성향도 중요하여 조직 운영도 의견을 내는 걸 어려워하지 않게 해야 하고 개인들이 생각을 많이 하도록 goal setting도 해야 하고 코칭도 필요하고 ...

그러다보니 개인들의 소통 능력을 가장 중시하고 ...

(물론 지적 노동의 특성 상 개인들의 능력도 중요하게 생각하지만 그것은 아이디어의 깊이와 횟수에 대한 확률이라고 생각하기 때문에 소통 능력이 떨어지면 다른 사람들을 이해시키지 못하고 또 일회성 아이디어를 다중의 조언을 통해 개선할 기회가 적기 때문에 소통 능력 다음으로 생각한다)

조직의 문화적 측면도 매우 중시한다. 목적을 중시하고 누구나 쉽게 의견을 제시하고 빠르게 오류를 인정하고 등등 하나의 의견이 더 나은 의사결정의 seed가 될 수 있도록 하는 데 신경을 많이 쓰는 편이다.

소통 능력이 떨어지는 친구들은 대부분 설득이 가능하다고 생각하는데 (업을 같이 하는 곳에서는 의도부터 나쁜 사람은 없다..) 굳이 안되는 사람들은 과감하게 배제해서 문화적 리스크를 줄인다.