기본 콘텐츠로 건너뛰기

창의성을 발현시키려면

최근 글

성과 있는 기술 회의를 위해 의견을 제시할 때 유의할 점

기술 회의를 하는 건 일반적인 회의와 약간 다른 특성이 있는데 그건 아마도 상당 부분 물리적으로 혹은 논리적으로 검증 가능하기 때문일 것이다. 주장을 확인할 방법이 항상 있다고 생각할 수 있다.
회의에서 발언하는 사람들은 발언의 범주를 잘 구분할 필요가 있는데 흔히 자기 질문의 성격을 구분하지 않고 얘기하는 경우가 있다.
발언의 유형을 단순하게 나눠보자면 1. ‘질문(몰라서 묻는)’2. ‘즉흥적 가설(문맥의 상황을 설명하거나 해결하기 위한)’3. ‘제안(의사결정이나 부분 기술에 대한 의견 제시)’4. ‘의사결정(잠정적 결론에 대한 기술)’그외 회의 진행을 돕기 위한 보완 설명 등으로 나눌 수 있겠다.
단순 질문은 명쾌해야 하며 진행을 돕는 보조 설명은 너무 늘어지면 안된다. 흔히 발생하는 문제는 질문과 가설, 제안을 혼돈하는 것과 가설, 제안과 의사결정을 혼돈하는 것이다.
몰라서 질문을 하면서 마치 의견 제안을 하는 듯이 토론을 요구하는 듯한 경우도 있고, 의견을 내면서 무조건 자기 의견을 결정하기 위한 의사결정의 안인 듯이 윽박지르기도 한다. 심지어 회의에 참석하는 것은 자기 의견을 관철하기 위한 수단으로 생각하는 경우도 있다.
토론할 때 잘못된 방식의 의견들로 다음 현상들을 볼 수 있다.

반복된 변명식 주장단답형 답변말 끊기추임새식 내용없는 랩업 반복타인의 권위를 근거로 한 주장
모두 깊이있는 개념적, 다면적 이해와 아이디어 공유를 방해하는 행위들이다.

많은 오류는 마음 속에 의견이 아니라 의사결정을 들고 있기 때문이다. 시작부터 Open-ended 원칙을 추구하지 않는 셈이다.
의견과 의사결정은 큰 차이가 있다.
권한의 문제이기도 하겠지만 그보다는 의견의 수준에 있다. 의견의 수준이 충분히 의사 결정할 만큼 풍부하고 해결책을 포함해야 의사결정의 단계에 이를 수 있다.
조급함이나 압박감은 더욱 문제를 악화시킨다.
좋은 의사결정 수준에 이른 의견 혹은 안은 몇 가지 특징을 요구한다.
하나는 풍부함이다. 회의를 하는 이유는 다른 생각을 얻기 위함이다.두번째, 개…

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

오랜 SW 연구개발 경험 상 나름 이런 감(symptom)의 원칙이 있다.

원래 시스템 소프트웨어란 건 wicked problem이어서 완벽한 정답이란 건 없고 enough한 시점에서 결론을 내려야 한다.
하지만, 좋은 답이란 것은 약간의 징후가 있다.

'계속 고민하던 기술 문제의 직접적인 연장선에서 내려진 결론이라면 창의적인 결론이거나 멋진 결론이 되기는 어렵다. 계속 고민하던 논리의 옆쪽에서 툭 튀어나와 와르르 내려지는 결론이 언제나 아름다운 결론이다'
왜냐하면 직접적으로 추론되는 논리는 아무리 기술적이라 하더라도 누구나 쉽게 추론할 수 있는 것이며 새로운 혁신이 들어가기 어렵다.
straightforward한 건 어려운 기술이라 하더라도 가치가 크지 않다.
그래서 마치 깊이 반복해서 고민하다 옆의 둑이 작은 바늘구멍에서 물이 새어 터지듯 나오는 아이디어가 훨씬 더 나은 답인 경우가 많다.

빅데이터 기술을 처음으로 본격적으로 다루다 보니 근 15년 정도 걸쳐 발전한 기술들을 3주만에 압축적으로 이해하려다 보니 어려움이 많았다.
이 기술들을 들여다보면 놀라운 경우가 많은데 상위 계층으로 갈수록 hype이 섞인 경우가 많다.
새로운 기술을 받아들일 때 나름 스스로 이해의 수준을 판단하는 잣대가 있는데 이것도 일종의 enough와 감이라고 할 수 있다.

'새로운 기술은 그 장점의 이유 뿐만아니라 그 단점까지 볼 수 있을 때 비로소 이해했다고 할 수 있다. 장점만 보이면 그것은 이해한 게 아니라 그냥 시키는 대로 공부한 것이다.'
이것은 critical thinking의 문제이다. 엄밀한 사고란 critical point를 인지할 수 있어야 하고 이 문제를 해결할 때 다른 critical point를 생각할 수 있어야 한다.
이때 system thinking이 중요한데 system이란 layer 간의 혹은 전체와 부분 간의 관계를 유기적으로 파악하는 것이다. 예를 들어 소프트웨어를 시스템적으로 이해한다는 것은 하드웨어 - 운영체제 -…

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

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

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에 있다고 언급한 바 있다.

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