윤경구의 Log on Java

시간 관리는 대부분의 사람들한테 어려운 부분이고 시간 관리 능력에 따라 성과가 크게 다를 수 있다. 여러 가지 역할을 해야 하는 사람들은 성격이 다른 업무들 간의 전환을 할 때 어려움을 많이 겪는다. 어떻게 시간을 서로 다른 업무들 간에 효율적으로 배분할 수 있을까? 몰입(flow)이 필요한 창의적인 지적 노동을 하는 사람들에겐 더욱 시간의 관리가 중요한 요소이다. 하나의 생각에 깊이 몰입할 수 있어야만 성과를 얻을 수 있기 때문에 몰입할 수 있는 시간 여건을 만드는 관리가 필요하다. 개인적으로도 하루 종일 예정되어 있는 회의들 속에서 생각을 정리하고 설계할 수 있는 시간은 점점 더 찾아보기 어렵다. 어떻게 몰입하고 정리하는 시간을 만들어야 할까? 늘 고민이다. 육체의 피로와 뇌의 피로는 보통 직접적인 관련은 없다. 육체가 피로할 때에도 뇌는 활발하게 활동할 수 있으며, 반면 육체는 멀쩡할 때에도 뇌가 피로할 경우가 있다. 물론 육체가 활발하게 맑은 혈액을 공급해줘야 뇌의 활동이 보장되는 것은 장기적 관점에서 사실이다. 다음 프레젠테이션은 캐나다의 제품 마케팅 컨설턴트인 Etienne Garbugli라는 사람이 작성한 시간 관리 기술에 대한 것이다. 나름 공감되는 부분도 많아서 하나씩 음미해본다. SlideShare : 26 Time Management Hacks I Wish I'd Known at 20 1. 하루 시간의 배분  시간에 우선순위를 두자.  무의미한 Boring 시간을 줄이고 우선순위가 있는 일들로 바꾸자. 2. 매일 일할 분량 4~5시간만 계획하자. 나머지 시간은 차게 마련이다. 3. 하루 종일 일이 전혀 진행되지 않거나, 12시간 이어서 일이 잘 진행되는 게 정상이다. 일이 잘 될 때 좀더 일을 하고, 일이 안될 때 좀더 여유를 갖도록 하자. 4. 자신의 시간당 비용을 생각해보고 그에 따라 행동하자. 내 시간을 존중하고, 또 내 시간이 존중받을 만큼 가치가 있도록 만들자. 5....

창의적으로 ( 소프트웨어)  문제를 푸는 경험은 여러 경로로 만날 수 있다. a. 똑똑하고 적극적인 개인들이 문제를 잘 푸는 경우. b. 문제의 범주를 잘 인지하고 똑똑한 그룹을 형성하여 회의 속에서 토론하여 실마리를 풀어가는 경우. 문제를 푸는 과정이 단순히 a-ha 현상 한 스텝만은 아니므로 사실은 a와 b의 반복을 어느 정도의 긴장감 속에서 만들 수 있는 체계가 가장 효율적이라고 생각한다. management는 이러한 문제를 가려내고 가치로운 문제 해결을 할 수 있도록 개인별 mission과 회의를 통한 아이디어 심화 및 공유를 잘 갖추어주고 회의를 잘 이끄는 것이 중요한 역할이다. 그럼에도 문제를 푸는 (답을 선택하는 게 아니라) 과정을 직접 해야 할 시점은 항상 존재하는데 다른 사람과의 토론 속에서 연상을 통해 풀어내는 경우 외에는 결국 스스로 생각을 다시 정리하면서 풀어야 한다. 개인적으로 이러한 풀이 과정은 자리에 앉아 머리를 싸맬 때보단 계속 생각하면서 걸어다닐 때 해답이 잘 발견되었던 것 같다. 복도를 계속 걸으면서 생각한다거나, 탄천을 헤매면서 생각한다거나... 하나. 문제 해답이 떠오르는 건 문제에 대한 깊이 있는 이해 과정이 거듭되어야 한다. (wicked problem적 특성) 둘. 문제의 인지와 해결 모두 우수하고 적극적인 그룹을 형성하여 논리적 토론을 거치는 것이 가장 중요한 단계이다. A-ha의 한 스텝을 제외하고는 이 과정을 통해 문제의 인지와 심화 그리고 해결의 대부분을 매우 좋은 효율로 이룰 수 있다. 셋. A-ha는 보통 정확하게 problem-solving의 mission을 맡은 사람이 만나게 된다. 그만큼 생각을 많이, 깊게 하는 것이 전제되어야 하기 때문이다. 넷. A-ha 자체의 순간은 몰입이나 이완 등의 과정과 무관한 시점에서 아주 비동기적으로 수많은 생각 중 하나의 한 연결에 이어져서 발생한다.

기억이란 게 얼마나 엉터리일수 있는지 가끔 놀랄 때가 있다. "무의식의 기억 위조" 현상인데 우리가 기억을 저장할 때 어떤 느낌으로 저장하기 때문일 것이다. 오래되었지만 강렬한 기억은 강력한 위조인 경우가 많은데 낡아진 기억을 복원하기 위해 우리의 무의식은 주변의 비슷한 느낌을 키로 저장된 기억들을 사용하여 완벽(?)하게 재구성하기 때문이다. 수십년만에 페북으로 만난 후배를 마치 잘 알고 있었던 것처럼 느낄 때, 사실은 그 후배와 관련된 기억들은 유사한 이미지를 가진 다른 이의 것이었음을 점차 알게 되고 나중엔 그 이미지조차 원래 그 후배의 이미지가 아니었는데 기억 속에서 바꿔치기되어버렸음을 발견한다. 강렬한 위조였음을... SW 기술의 기억도 다르지 않다. 흔히 지식이라고 부르는 것들이라고 뭐 특별히 다른 방식의 기억소에 저장하는 것이 아니니까.. 중요한 지식, 선입견들 중 첫 인상이 강렬했던 것들은 강력한 방식으로 위조되는 경우가 많다. (난 절대 이런 기억의 정확성을 두고 내기를 하면 안된다 ㅠ) 그런데 어떻게 뇌는 이 수많은 기억들을 미묘한 느낌의 코드로 분류하여 저장하는 것일까? 그 메커니즘은 알수 없지만 기억력과 관련해서는 보통 매우 차분하게 몰입되는 경우가 가장 오래 남고 극도의 긴장 상태에서는 매우 짧은 기간 유지되는 기억 효율이 매우 높은 것으로 알려져있다. 이 사실은 차분할 때 작은 느낌의 차이까지 기억할 수 있고 장기 기억화될 여지가 많다는 뜻이 아닐까? 기억 능력과 아하 현상(a-ha effect, eureka effect)은 직접적인 연관이 없어보이지만 기억에서 차지하는 무의식(인지하지 못하는 뇌의 활동)과 느낌으로 표현할 수 있는 기억의 끄집어냄(검색?) 방식을 보면 유사한 메커니즘일 수 있을 것 같다. 다만 기억은 위조하여(!) 끄집어내는 것이고 아하 현상은 비슷한 것들을 무의식이 총합하여 추천한 것들 중에서 솟구쳐올리듯이 처리한다고나 할까! P.S A-ha 현상이 실재하는 ...

글쓰는 법에 대한 가이드는 있어도 코딩하는 법에 대한 가이드는 보지 못한 것 같다. 글을 쓸 때에도 탑다운으로 (워드의 개요 모드outline mode 활용할 때처럼) 쓸 때와 글 가는 데로 붓 가는 데로 쓸 때가 다르듯이 코딩도 유사함을 가지고 있다. 논리적 설계와 아키텍처의 중요성을 강조하다가 막상 아키텍처 설계가 일단락되어 실제 코딩 단계로 넘어가면 어쩔줄 몰라하는 친구들이 있다. 물론 코딩 못하는데 설계만 아주 잘하는 건 일반적으로 가능한 이야기는 아니고 이런 이들의 설계는 구멍들이 있거나 현실성이 부족한 경향이 있다. 코딩을 설계를 기반으로 topdown 방향으로 진행하려면 인터페이스나 메소드 시그너처 혹은 커멘트 등을 통해 계속 논리 진행을 코드화해나가야 한다. 아주 디테일한 구현을 하나씩 해나가면서 그야말로 코드 가는 데로 하는 방식은 코드 몰입이 좋을 때 별다른 문제없이 잘 된다. 하지만 디테일 코딩을 하기에 논리적 분량이 많고 여러 가지 고려할 경우의 수가 많은 경우는 메소드 시그너처를 먼저 작성하고 (여의치 않은 경우 소스코드에 커멘트로 디테일 계획을 적어둔다) 디테일은 하나씩 채워나가는 형태가 더 효율적이다. 한마디로 코딩할 땐 구현해야할 모든 걸 코드에 반영하는데 한꺼번에 다 상세 구현으로 반영할 수없는 부분은 윤곽만 코딩하는 것이다. 이것은 그림을 그리는 과정과도 유사하다. 기본 스케치를 먼저 하는 것은 설계 후 주요 인터페이스 시그너처를 정의하는 것이라 볼 수 있고 실제 상세 터치는 어떤 부분은 아주 세밀하게 한번에 그리고 어떤 부분은 윤곽부터 조금씩 구체화하는 방식을 사용한다. 대부분 두 가지 방식이 모두 사용되어야 효율적인데 한번에 상세로 그리는 집중력이 필요한 부분은 그렇게 하고 생각이 끊어지는 여러 부분들은 그 포인트만 먼저 윤곽을 잡는 식인 것이다. 스스로 코딩도 하지만 멤버들의 교육과 성장을 함께 고민하면서 스스로에게 여러 가지 실험을 하게 된다. 논리적 사고의 방법, 창의 도출의 방법, 설계의...

제가 주장하는 창의 메커니즘의 핵심은 좀 단순화하여 얘기하면 다음과 같이 요약될 것 같다. "스스로 거듭 논리적으로 생각하면 누구나 해답을 찾을 수 있다" (개인 관점의 창의) 창의도 문제 해결의 관점에서 바라본다는 점에서 해답을 찾는 것이고 (생각한 문제와 다른 문제의 답이 나오는 수도 있지만) 수단은 '스스로'와 '거듭된 논리적 생각' 뿐이라는 거... 누구나 찾을 수 있다고 믿지만 다만 논리적이기 위해서는 생각의 훈련이 필요하고 거듭 생각하는 것도 쉽지 않다는 것을 지적하고 싶다. 또하나는 이 주장을 개인적 관점에서 확대하여 조직의 창의로 발전시키기 위한 부분이다. 조직(팀) 창의는 역시 반복 훈련과 적응 과정이 필요하다. "팀 창의는 개인적 창의의 기반 위에서 이루어지는 것이며 다면적 소통을 통해 더나은 결론을 도출할 수 있다" (조직 관점의 창의)

소프트웨어 스케줄 계획과 기한 소프트웨어를 하다보면 스케줄 계획과 기한이 항상 맞지 않다. 상세한 수준에서 스스로 스케줄링을 하도록 권장하지만 그것을 기한과 맞춰야 하거나 또 큰 기한을 세워야 할 때면 항상 착오가 생긴다. 목표에 기한이 없으면 뒷쪽으로 갈수록 추동력이 떨어지지만, 기한이 합리성을 잃으면 역효과가 나게 마련인데.. 예상과 계획은 늘 어긋나는데 경험과 풀어야 할 문제의 complexity 수준이 제한할 수 있으면(판단되고 제한이 되는 단계가 되면) 예상이 좀더 의미있는 값이 되는 것 같다. 창의적 조직에 대한 고민을 늘 하고 있는데 개인의 성장에 기반한 조직적 지혜의 개선이 가장 중요한 요소라고 생각하지만, 현실에서 마주치는 시간과 기한의 문제는 또다른 어려움이다. 여가와 창의의 관련성에 대한 반론 창의와 시간에 관련된 문제 중 흔히 여가가 창의에 도움을 준다는 주장이 있는데 개인적으로 이러한 주장에 대해서는 사례나 근거를 파악하기가 쉽지 않고 오히려 반례가 많다고 판단하고 있다. 개인적으로는 자발성과 능동성이 그리고 좀더 많은 시간을 몰입하여 생각하는 데에 할애하는 게 창의에 도움을 준다고 생각하는데, 기한이나 문제의 어려움 혹은 현실에서의 댓가와 같은 pressure를 개인이 너무 강하게 의식하게 되면 충분히 생각을 할 수가 없고 생각에 한계를 두게 되기 때문에 창의를 해치는 것은 분명하다. 다만 여가라는 표현은 그야말로 남는 시간을 뜻하는 것인데.. 남는 시간과 휴식이 창의와 연결된다는 근거는 거의 없다. 여러 창의의 발견 형태 중 3M과 같은 사례의 경우 다양한 시도와 조금은 우연성에 기반한 부산물의 재해석을 통한 창의의 형태에서는 주기적인 사고의 전환 즉 몰입하던 문제를 완전히 털어내고 다른 문제로 몰입하는 방식이 중요할 수 있다. 하지만, 그런 경우도 여가가 창의에 기여를 하는 것은 아니라고 생각된다. 여가가 사람에게 필요한가 하는 질문과 여가가 창의에 기여하는가 하는 질문은 전혀 다르기 때문에 사실에 대한 탐구를...

오늘(2013년 5월 14일) 저녁에 있었던 이화여대 컴퓨터공학과 학부 4학년을 위한 특강 자료.. 강의 자료는 예전에 명지대에서 했던 자료를 재작성했는데 아쉬움이 있지만 그래도 발표자료보다 내용 전달은 잘되었을 거라 생각합니다. 아무도 주무시지 않고 경청해주셔서 감사. ^^; Smart software engineer from Kyung Koo Yoon P.S 강의 자료에서 보완할 부분이 세 가지 정도. 강의 자료에는 빠져 있지만 세번째 항목을 제외하면 특강 때에는 언급한 내용입니다. a. 뇌 활동 중 인지하는 부분과 인지 못하는 부분 (의식과 무의식) b. wicked problem의 특성들 c. 소설 읽듯이 코드를 읽는 법 (논리적 사고의 연장선 상에서 코드 구조 가설-내가 구현한다면-을 먼저 세운 후 실제 코드를 보고 그 차이를 비교하면서 다시 읽어가는 방식)