기본 콘텐츠로 건너뛰기

좋은 기술적 결론에 대한 판단 방법

최근 글

창의적 기술 조직의 구성 원리에 대한 몇 가지 생각 정리

기술 아이디어에 기반한 엔지니어 중심의 혁신을 이루려면 조직을 어떻게 구성해야 할까?
그 기반이 되는 생각들을 몇 가지 정리해본다.
블로그에서 여러 번 반복되었던 내용을 매우 간단히 요약해본 것이다.

1. 지식 <<< 아이디어

2. 개발 <<< 혁신
3. 개인 아이디어 <<< 팀 아이디어
4. 탈권위를 통해 지속적 혁신을 추구
일상적으로 귀를 기울여 아이디어를 발전코칭을 통해 개인들을 성장시켜 더 큰 아이디어를 가능하게지시 중심의 체계를 무너뜨리고 자율 중심의 체계를 구축혁신은 크고 작은 아이디어의 총합에서 이루어짐 5. 리더가 추구할 문제는 Bigger but Solvable Question더 큰 문제를 찾아야더 근원적 사고를 활용충분한enough 시점에서 결정 6. 21세기 인재의 조건에 맞게 사고

엄밀한 사고critical thinking소통communication협업collaboration창의creativity시스템 사고system thinking혁신적 문제 해결disruptive problem solving포용적 리더쉽inclusive leadership







그룹 창의(Group Creativity)는 그룹의 지적 능력을 최대한 발휘할 수 있는 방법

사람의 연결을 통한 더 나은 아이디어 그룹 창의는 개인의 창의가 아닌 여러 사람이 함께 하는 창의를 뜻한다.
사람의 뇌는 개인별로 서로 다른 세계를 가지도록 동작하고 직접적으로 다른 사람과 연결할 수 있는 방법은 알려지지 않았다. 혹시 텔레파시(정신 감응) 같은 게 가능하면 조금 달라질지 모르겠지만.
창의나 뇌에 대해 공부를 하다 보면 늘 아인슈타인과 같은 전문 분야의 뛰어난 천재 이야기가 나온다. 혹은 스티브 잡스와 같은 일반인들에게 가까운 천재 이야기도 나온다.
물론 엄청나게 뛰어난 사람들의 기여를 적극적으로 인정한다. 세상은 천재들에 의해 좀더 빠르게 변화해왔다.
하지만 개인의 천재성 역시 아이디어를 만들 때에는 다른 사람들의 기여가 필요한 경우가 많았음은 잘 알려져 있다.
여러 사람의 뇌가 연결될 수 없으므로 개인의 천재성 없이 순수한 그룹의 천재성이 있다고 생각하지 않는다.
다만, 더 나은 천재성을 위한 여러 사람들, 즉 그룹의 연결이 필요하다.
그룹 창의는 전문 기술 영역에서 함께 최고의 아이디어를 만들어가는 방법을 이야기한다.
팀웍과 소통 얼마 전에 접한 글 중에 다음과 같은 Martine Rothblatt의 명언이 있었다.
Anything worthwhile in life requires teamwork, 인생에서 가치 있는 모든 것은 팀웍을 필요로 하고 and you cannot manage what you don’t understand. 이해하지 못하는 것은 관리할 수 없다
첫번째 문장은 팀웍의 중요성을 뜻하고 두번째 문장은 말 그대로 이해의 중요성을 뜻한다. 혼자서 하는 것보다 함께 하는 것이 더 가치 있는 일을 해낼 가능성을 높여주는데 이를 위해서는 더 많은 이해를 필요로 한다는 뜻이다.
여러 사람을 이해하는 것은 소통을 통해서만 이루어진다. 격이 없이 사람을 이해하고 하나하나 코칭할 수 있고 그룹을 통해 최선의 의사 결정을 할 수 있는 팀을 구축할 필요가 있다.
지적 능력의 단계 왜 이렇게 많은 소통이 필요할까? 더 많은 문제를 풀기 위해…

[Java] Java 9의 모듈 시스템에 대한 단상

우여곡절 끝에 자바 9에 jigsaw 즉, Java Platform Module System이 포함되어 출시되었다.

오래동안 사용되던 ClassLoader 기반의 OSGi와 다르게 Java Platform Module System은 JDK 내부적으로 module을 지원한다.

이를 위해 java.lang.ClassLoader 등의 클래스가 module 관련 선언에 있는 내용대로 접근성이 허용되는지를 내부적으로 체크하도록 JDK 코드가 수정되었다.

그 외에도 모듈에 선언된 것 외에는 타 모듈의 클래스를 액세스할 수가 없는데 Class.forName(...)을 통해 Class 객체는 구할 수 있지만 newInstance 등을 통해 인스턴스 객체를 만들려고 시도하는 순간 에러가 나게 된다.

이 점은 기존 코드와 심각하게 비호환되게 하는데 이를 완화하기 위해 java.util.ServiceLoader를 통해서 객체를 만들 수 있도록 하고 있다. (이게 가능하려면 해당 제공 모듈에서 provides를 선언해야만 한다.)

기존의 자바는 클래스로더의 자유도를 기반으로 모듈화를 저해하는 일들을 많이 하는 일들을 많이 해왔다. 특히 프레임웍들은 그러한 형태를 권장해왔다.
모듈에 대한 제어가 없고 이를 통해 더 많은 기능을 제공할 수 있으니까.
자바 9 이후부터는 이러한 모듈화를 저해하는 것들이 많이 줄어들 것 같다.

아니, 새로 작성되는 프로그램들은 자바 9과 쉽게 호환할 수 있도록 자바 코드를 모듈화하여 분리시키는 설계를 항상 선행하여야 할 것 같다.

OSGi는 표준 Java API를 기반으로 사용하므로 특별히 JPMS 기준의 타 모듈에 액세스하지 않는 한 잘 동작할 것이다.
현재로서는 JPMS는 같은 모듈의 멀티 버전을 지원하지 않는다. 그리고 동적 업데이트나 동적 unload도 지원하지 않는다.
엔터프라이즈 환경에서 동적 업데이트/unload는 여러 가지 상황에서 필요하다. 이 글에서 언급한 것처럼 IoT만 필요한 것은 아니다.
물론 클라우드 환경의 blue-green …

집단 창의의 기반을 만드는 포용적 리더쉽

창의성과 포용적 태도
창의성, 무언가 없던 걸 새로 만드는 것과 포용적인 태도가 어떤 관계가 있을까?

창의성의 핵심은 창의적인 문제 해결로 그 과정의 가장 어려운 부분은 엄밀한 사고critical thinking에 있다고 언급한 바 있다.

실제 문제를 해결하는 아이디어를 어떻게 구할 것인가에 대해서는 여러 가지 방법이 제시되고 있지만 개인별로 아하 현상을 어떻게 체험할 것인지는 개인별 발견이 중요할 수 있다고 생각한다. 여기에는 집요한 반복된 생각이 중요할 수 있고, 엄밀한 사고가 중요할 수도 있고, 몰입이 중요할 수도 있고, 혼자가 아닌 토론과 대화가 중요할 수도 있고, 또 깊은 사고 후의 뇌가 회복하는 멍한 순간이 중요할 수도 있다. 아마도 이 모든 것이 다 문제를 창의적으로 푸는 과정에 관여할 것이다.
일례를 들어 끙끙 앓던 문제를 대화를 통해 공유하면서 스스로 문제를 해결하는 경우도 종종 발생한다. 대화 자체를 통해 답을 얻었다기보다는 대화를 하면서 자신의 머리 속에 있던 생각을 외부로 전달하는 과정에서 답을 얻는 경험이다.
일화를 들자면 다음은 아인슈타인이 특수 상대성 이론의 아이디어를 얻은 계기이다. 친구인 미셸 베소에게 안 풀리는 문제를 토론하러 갔다가 갑자기 통찰을 얻었다.
"이렇게 대화를 시작했다. '요즘 어려운 문제를 풀고 있는데, 오늘 자네와 이 문제를 두고 전투를 벌리려고 왔네. '  우리는 이 문제의 모든 측면들을 토론했다. 그런데 갑자기 이 문제의 해법이 어디에 있는지 이해하게 되었다. 다음 날 다시 친구에게 와서 인사도 하지 않고 말했다. '고맙네. 문제를 완전히 풀어버렸어.'"  그렇다면 왜 포용적인 태도를 얘기하려는 걸까.
포용적인 태도는 문제 해결에 있어서 다양한 문제를 인지하고 또 다양한 측면들을 받아들일 수 있는 입력의 문제를 다룬다. 문제 해결 과정을 입력과 출력을 가진 블랙박스로 본다면 포용적 태도는 입력을 충분히 주기 위한 선결 조건이라고 볼 수 있다. 다양한 문제를 인지…

엄밀한 사고(Critical Thinking)란 무엇일까

미국에서는 21세기 교육에 가장 중요한 4가지 역량이 4C라고 한다.

Four Cs of 21st century learning
네 가지 C는 각각 엄밀한 사고(Critical thinking), 소통(Communication), 협업(Collaboration), 창의(Creativity)를 뜻한다.
(critical thinking을 비판적 사고로 번역하는 경우가 많지만, 실제 문맥에서 보면 문제 해결을 위한 매우 중요한 영역의 사고를 뜻하는 엄밀한 사고가 좀더 적합한 표현이라고 판단된다.)

한국 사회는 교육에서부터 기업까지 창의성이 떨어진다는 말을 많이 해왔다.

굳이 군대와 같은 극단적인 사회 환경을 얘기하지 않더라도, 가족 같은 분위기라는 표현이 가부장적 위계를 인정한다는 뜻으로 통용되는 사회에서 중요한 의사결정 과정에 충분한 소통과 피드백이 주어지지 못하기 때문에 결과적으로는 창의적 아이디어가 부족하게 되고, 엄밀한 사고를 훈련하지 못하여 21세기에 적합한 인재로서 가치가 떨어진다는 표현이라고 볼 수 있다.

창의적 사고는 결과적인 부분에 가까우므로 과정에서 필요한 엄밀한 사고가 한국의 교육이나 혁신을 지향하는 기업 환경에 가장 중요할 것이다.
미국교육협회(NEA)에서는 엄밀한 사고를 어떻게 바라보고 있는지 옮겨본다.
개인적으로는 혁신을 지향하는 SW 기업에서, 또 창의적으로 미래를 열어갈 자녀들을 위해서 코칭이나 교육의 방법을 고민하기 전에 꼭 읽어봐야 할 내용이라고 생각한다.

다음 내용은 NEA에서 발간한 '글로벌 사회의 21세기 학생들을 준비하기 위한 네 가지 C 교육자 지침'에서 발췌 번역하였다.

An Educator’s Guide to the “Four Cs” - Preparing 21st Century Students for a Global Society 엄밀한 사고는 오랫동안 가치있는 기술로 사회적으로 인정받아왔다. 오늘날은 모든 학생들에게 필요하다. 기존에는 엄밀한 사고를 통한 문제 해결 능력이 주로 재능있는 학생들을 위해 필요…

소프트웨어 팀을 코칭한다는 것

연구소장으로 몸담아왔던 직장을 갑작스레 퇴직하게 되었다.

이 사실을 알게 된 몇몇 연구원들이 찾아온다.
왠지 뭉클하면서도 최악의 관리자였던 내가 조금은 나아졌나보다 하는 위안도 든다.

개인적으로 10여년 간 소프트웨어 연구개발 관리자로서 몇 가지 시기를 거쳤다.
제 1기는 관리자를 맡은 개발자. 이때는 관리자라기보다는 개발자였다.
정체성이 개발자인데 수십명을 관리해야 하는 관리자 역할이 주어진 것이다.
당시에는 팀원들을 코칭한다거나 친밀감을 개선한다거나 하는 데 전혀 신경을 쓰지 않았다.
조직 관리는 스스로의 목표에 들지도 못했던 것이다.
늘 조직의 소프트웨어 미션에만 신경을 쓰고 팀원들의 성장이나 상태에는 전혀 신경을 쓸 줄 몰랐다. 팀원들의 코드에 문제가 있으면 내가 다시 짜버리지 하는 생각이 컸었고, 스스로가 메인 코더였고 실제 백만 LoC에 달하는 코드를 작성했던 시기였다.
아마도 당시 팀원들은 황무지에 버려진 처지로 생각하면서 매니저가 너무 열심히 일을 하기 때문에 완전히 서로 다른 세계의 사람인 취급을 했을 것이다.
나중에 얘기를 들어보니, 조금 걱정을 하기도 했다고... ㅠ_ㅠ

제 2기는 코칭을 처음 해보는 난폭한 관리자 이때는 관리가 필요하다는 점을 처음으로 인지했다. 가능하면 스스로 하는 코딩을 줄이려고 노력했고, 팀원들을 코칭하기 위해 노력했다.
하지만, 수적으로나 경험적으로 절대적으로 부족한 팀원들을 데리고 소프트웨어 개발을 하는 매우 힘든 미션이기도 했지만, 더 중요하게는 아무런 경험없는 신입 팀원들을 하나씩 코칭하면서 가장 비효율적인 접근을 했다.
신입 팀원들의 결과물들은 소프트웨어 경험이 이미 십년이 넘은 사람이 보기엔 너무 기본조차 되어 있지 않았고, 이를 극복하고 결과를 만들려는 당위성에 짓눌려 몹시 공격적으로 팀원들을 다그쳤다. 팀이 전체적으로 회사의 주목을 받지 못하는 상황이었기 때문에 팀원들의 상실감이 매우 컸다.
결국 신입 팀원들은 한참의 시간이 지나서야 조금씩 나아졌고(원래 걸리는 시간만큼 지나서.. 결국 강압은 성장에 아무…