일요일, 4월 07, 2019

소프트웨어 엔지니어가 critical thinking을 학습하려면

젋은 친구들이 소프트웨어를 업으로 하고 기업에 입사하거나 창업에 도전하는 모습이 이제는 사회적으로도 상당히 기대를 받는 장면이 되었다.

그런데 지식 산업인 소프트웨어를 연구 개발하는 역할을 하기 위해 어떤 성장이 필요할까?

개인적으로 최근 몇년간 딥러닝 쪽 공부를 하면서 미국 대학 강의를 들을 기회가 많은데 대학 시절에 공부를 제대로 하지 않아서인지 상당히 인상적인 부분이 있었다.

아마 명강의란 그런 것이 아닌가 싶은데 지식의 전달 방식의 차이였다.
대부분의 책에서 찾아보기 힘든 교수님의 지식에 대한 직관(intuition) 혹은 관점에 대한 전달이었다.

수학적 증명을 하고 난 다음에 이것을 수식이 아니라 직관적으로는 어떻게 이해를 할 수 있느냐 하는 부분이 매우 중요한데 지식을 이해한다는 것이 어떤 솔루션이나 아이디어의 기반이 되는 지식으로 발전하기 위해서는 직관이 가능한 멘탈 이미지로 머리 속에 재정립시킬 필요가 있다.

  • 지식이 머리 속에서 살아 있는 직관 가능한 모델이 되어서 여러 가지 개념들과 느낌들이 무수히 연결되어야 한다.
  • 즉, 평소에도 친숙하게 느낄 정도로 쉬운 개념이거나 숙련으로 쉽게 연상할 수 있는 개념이 되어야 한다. 예를 들어 친숙한 ‘코끼리’라는 개념은 여러 가지 코와 귀, 몸무게, 여러 가지 코끼리의 특성에 대한 것들을 연결시켜준다.
  • 쉽게 직관할 수 있는 모델로서 이해하는 과정이 intuition 관점의 추가 이해라고 볼 수 있다.
  • 이 멘탈 이미지 혹은 개념적 요소로 인지하면 비로소 지식은 유연성을 얻어 이를 기반으로 다양한 유추가 가능해진다. 
소프트웨어를 기업 환경에서 다루는 사람이라면 소프트웨어에 맞는 생각하는 방법을 배워야 더 큰 소프트웨어를 다룰 수 있고, 또 깊이를 가질 수 있다.
창의적 사고의 중요한 요소라고 하는 critical thinking(임계적 사고)이나 system thinking(체계의 사고)은 특정 지식 혹은 영역에서 임계적 요소를 식별하고 이를 좀더 깊이있게 사고할 수 있는 능력이라고 할 수 있다.

그런데 critical thinking, system thinking의 방법은 지식 분야별로 도메인별로 크게 형태가 다를 수 있다.
여기에서 정말 중요한 학습이 필요하다.

앞에서 대학 강의를 얘기했었는데 이러한 임계적 사고가 대학 교수님들의 명강의를 통해서도 어느 정도 체득이 가능하다고 본다.
하지만, 기업에는 같이 문제를 해결하고자 하는 여러 뛰어난 동료들이 있을 수 있다.
이들이 문제를 바라보는 시각, critical path에 대한 판단법, 시스템을 바라보는 사고 체계 등을 옆에서 지켜볼 수 있다면 금방 자기의 것으로 소화할 수 있다.
개별 지식 자체가 아니라 사고의 방식, 도메인을 접하는 시스템에 대한 개념 모델을 엿볼 수 있다.
이러한 시스템적 사고의 방법을 배울 수 있는 동료나 선배가 있는 곳이 좋은 성장의 장소가 된다.
물론 이들과 오픈으로 토론하고 문제를 함께 찾아갈 수 있는 문화가 뒷받침되어야 한다.

개별 지식에 대한 학습은 혼자서 꾸준히 하면 되는 것이지만, 판단의 수준을 높이는 것은 혼자 학습만 해서 이루긴 어렵다.
생각하는 방법의 차이를 주의깊게 보고 이를 자기의 것으로 소화하려는 노력이 진정한 큰 성장을 가져온다.

주변에 배울 사람이 없는 환경이라면 끊임없이 생각을 정리하고 체계화하여 intuition으로 발전시키는 노력을 기울일 필요가 있다. 물론 주변에 배울 사람이 있을 경우에도 먼저 개인의 intuition을 정리하고 이를 오픈하여 개인의 편향이나 오류를 검증할 필요가 있다.

추천한다면 주변의 개념을 넓혀 도움을 주거나 나눌 사람을 기업내외를 막론하고 주기적으로 함께 지식 이해의 수준을 높여갈 수 있도록 찾을 필요가 있다.
배울만한 멤버와 오픈된 토론 문화를 가진 스터디 그룹을 찾아 참석하는 것도 좋은 방법이다. (그런 스터디 그룹이 많지는 않을 것이다.)

지식 기업들에게는 개개인의 학습 능력과 성장이 무엇보다 기업의 잠재력이 되기 때문에 이러한 성장을 매우 중시한다.
유감스럽게도 우리나라 IT 기업들의 수준은 개인의 역량 측면에서나 개인의 역량을 결과물로 총합해내는 측면에서나 그렇게 뛰어난 편이 못된다.

그렇기 때문에 기업의 성장은 외부로부터 우수한 인재를 영입을 하는 것으로 해결하기가 어렵다. 기업 구성원의 성장과 기술적으로 더 나은 솔루션을 의사결정할 수 있는 문화를 만들어가야 한다.

개인의 Career path도 자신의 기술적 성장에 베팅하는 것이 미래에 가장 효과적인 자산이 될 수 있을 것이다.

월요일, 3월 25, 2019

아이디어는 가장자리에서 발생한다



그림의 중심과 에지 사이의 거리는 복잡성의 정도를 표현한 것이다.
아이디어는 항상 복잡한 영역에서 발생하지 않지만, 현재 지식 수준의 경계에서 발생한다.
따라서, 거듭된 사고를 끝까지 한다면 누구나 새로운 아이디어를 만들 수 있다.

토요일, 3월 09, 2019

기술 조직의 매니저는 얼마나 많이 필요할까

기술 조직에서 매니저는 얼마나 많이 필요할까.
관리 편의를 위해 일찍 매니저가 된 친구들은 스스로 기술 개발을 하지 못하고 관리와 다른 팀원들의 연구 결과를 간접적으로 이해하고 판단하는 업무를 할수밖에 없는데 지식 체계의 기반이 부족해지고 스스로 연구할 수 있는 능력을 잃게 마련이다.
물론 관리도 재능이 필요한 영역이긴 하지만 상대적으로 단기간에 학습할 수 있는 영역이다.
연구 전문성에 대한 코칭이나 리딩은 금새 학습할 수 있는 게 아니어서 결국 다른 상위 관리자의 의사결정에 기대게 되기도 한다. 
너무 이른 매니저 역할은 전문가로 성장할 기회를 잃기 쉽다는 뜻이다.
기술직을 시작한지 1,2년만에 팀장이 되면 준비없이 관리와 기술 의사결정에 관여하게 된다. 결국 형식적인 패턴에만 익숙해질 가능성이 높다.
이십년 가까이 IT 업종에서 일을 하고 매니저 역할만 했던 이가 얘기를 해보면 전혀 생각의 깊이가 없는 경우를 볼 때가 가끔 있다. 외부에서 보기엔 훌륭하고 성실한 매니저로 비춰지기도 하지만 실제로는 전혀 무언가를 스스로 이해하고 판단하는 환경에 있지 못했던 것이다.
그냥 패턴적으로 조건반사하듯 의사결정을 반복하고 기술적 피드백을 이해하지도 못하는 모습은 웃프다. 
한국은 위계적 문화 때문에 위계 상의 윗 사람이 진정으로 뭘 학습하기가 쉽지 않다. 개인적 성실성으로 한다고 해도 비평해줄 사람이 거의 없다.
깊이있는 의사결정을 할수 있는 오픈된 토론 회의 문화도 큰 역할을 하겠지만 너무 일찍 매니저들을 만들기보다는 관리를 자율 책임에 많은 영역을 넘기고 매니저를 줄이는 방식이 유의미하다고 생각한다.
이런 경우 의사결정자의 윗쪽으로 갈수록 조금 더 큰 인내심을 필요로 할수 있다.
Bottom-up이 활성화되면 top-down은 이해시키는 비용을 포함해야 한다.
위계의 계층을 줄일 수 있는 자율 단위 규모가 최대 100명 남짓이라면 그 정도 안에서 대부분의 크리티컬한 의사결정이 이루어질 필요가 있는 셈이다.
(젊은 친구들이 어쩔수없이 매니저를 맡아야 한다면 너무 오래지 않은 시점에 다른 친구에게 넘기고 기반을 다시 다지는 기간을 갖는 것도 방법일 것 같다.
경력자를 수혈해서 바로 매니저 역할을 맡기는 것은 문화 융합 문제와 자질 등이 우려되므로 일정 기간 유보하는 룰을 만드는 것도 좋을 듯하다.)
물론 기술 조직의 경계와 의사결정 구조에 대한 얘기이다. 성격이 많이 다른 프로젝트성이나 경영 의사결정은 조직의 대표성을 가진 이들과 프로젝트에 직접 관여하는 핵심 당사자들로 구성하는 게 맞겠지만..

토요일, 3월 02, 2019

왜 ‘최고’ 인재들이 창의력 없는 결과를 내놓을까

원 글 : Why hiring the ‘best’ people produces the least creative results
관련 도서 : The Diversity Bonus How Great Teams Pay Off in the Knowledge Economy

창의적인 팀웍을 만들려면 어떻게 해야 할까
나름 재미있는 관점을 제공해주는 글이 있어 소개한다.
한글로 번역한 글을 읽었는데 원 글에 나오는 통계학적 기법이나 마르코프 프로세스를 이해못해서 핵심을 잘못 전달했기에 원 글을 읽어보길 추천한다.

글은 수학 전공한 교수님이 논리학 수업 시간에 교통 체증을 컴퓨터로 모델링하는 방법에 대해 설명하는 것으로 시작한다.
교통 체증 상태의 차량의 흐름을 추적하는 건 엄청난 메모리와 연산량을 필요로 하게 된다.
교수님은 이런 경우엔 빈 도로를 추적하면 된다고 아이디어를 제시한다. 교통 체증 상황에서 빈 도로의 흐름을 추적하도록 모델을 만드는 아이디어이다.

이러한 아이디어 이야기들은 몇 가지 공통점이 있다.
1.  복잡한 문제이다. 차원이 높은 문맥을 다루기 때문에 설명하기도, 엔지니어링하기도, 개선하거나 예측하기도 까다롭다.

2.  획기적인 아이디어는 마법처럼 떠오르거나 완전히 새롭게 만들어지지 않는다.
기존의 아이디어, 직관, 기교나 룰에서 출발하며 이것들을 참신하게 적용을 한 것이거나 결합한 것이다.
앞의 교통 체증 사례는 정보 이론의 최소 서술 길이minimum description length 즉, 같은 정보를 가장 짧게 기술하는 기법 개념을 참신하게 적용한 사례라고 볼수 있다.
이러한 아이디어들은 조금의 이득을 가져온다. 하지만 이런 아이디어들이 모이게 되면 커다란 반향을 가져올 수가 있다. 진보는 거대한 도약 만큼이나 작은 걸음들의 누적을 통해서도 크게 이루어진다.

3. 이런 아이디어들은 그룹 환경에서 태어난다.
한 사람이 어떤 문제에 대해 자신의 관점을 얘기하고 해결에 대한 접근법을 설명하거나 해결에 집중하고 있는 부분을 명확히 하면 다른 사람이 의견을 주거나 알고 회피법을 알려주는 식이다.
작고한 존 홀랜드는 늘 다음과 같이 물었다. “마르코프 프로세스로 바꿔서 생각해보았나요? 관련된 여러 개의 상태와 그 상태들간의 전이 경로를 식별해서 생각해보았나요? ” 이러한 질문은 발표자가 문제에 관련된 상태를 정의하도록 강제한다. 이 단순한 행위가 곧잘 어떤 직관으로 이어지기도 한다.

현대 문제들의 복잡성은 종종 개인이 모든 문제를 충분히 잘 이해할 수가 없도록 한다.
복잡한 문제들의 다차원성과 중층성은 실력주의 즉, 최고의 인재를 채용해야 한다는 생각의 근거를 약화시키는 경향이 있다.
최고의 실력자는 없는 것이다. 여러 면에서 최고의 점수를 받은 사람을 뽑는 게 아니라 다양성을 추구하게 된다. 다양한 지식 기반, 도구, 분석 기술을 가진 일련의 사람들을 팀으로 구축하게 된다.
종종 수학자를 포함할 것이며 그 수학자들은 미분 방정식 뿐만 아니라 동적 시스템을 공부했을 것이다.
이렇게 팀은 ‘최고’의 수학자, ‘최고’의 종양학자, ‘최고’의 통계학자 등을 인재 풀에서 선택한 사람들로 구성될 것이다.

이러한 다양성에 대한 주장의 증거는 다양한 아이디어를 결합하는 것이 더 나은 결과를 만드는 경향이 있다는 여러 논문들과 특허 등에서 확인된다.

랜덤 포레스트에서 활용하고 있는 기법인 boostrap aggregation 즉, bagging 기법에서 다양성의 유용성은 확인될 수 있다.
(Bagging은 분산을 감소시키는 앙상블 기법이며 결과적으로 여러 개로 나뉘어진 트레이닝 셋을 통해서 각각 만들어진 결과들의 평균이나 투표를 통해 최종 결과물을 내는데 일반적으로 분산이 줄어들고 accuracy가 좋아지게 된다. 부트스트랩은 외부에 의존하지 않고 자신의 힘으로 여러 단계를 거쳐 무언가를 이루는 과정을 뜻하는 표현인데 통계적으로는 동일한 데이터 셋을 여러 개의 데이터 셋으로 나눠서 샘플링하는 방법을 뜻한다. 즉, 동일한 데이터 셋 중 일부를 무작위로 샘플링해서 교체하는 방식으로 여러 벌의 데이터 셋을 만드는 기법이다.)
또다른 앙상블 기법인 boost 기법은 가장 어려운 부분에 집중해서 (boost는 여러 학습자들 중 정확도가 가장 낮은 학습자들의 비중을 높여 학습시키는 방법) 학습하여 결과적으로 더 많은 다양성을 거치면서 정확도가 높아지게 한다.

단순히 공통된 기준에 따른 고득점자를 채용하는 방식은 다양성이 아니라 동질성을 높이는 방식이다.
알파벳 자회사인 X의 CEO인 아스트로 텔러는 다음과 같이 말한다.

“중요한 건 서로 다른 지적 관점을 가진 사람들을 보유하는 것입니다. 지금까지 탐험해보지 못한 영역을 탐험하고자 한다면 자신과 닮고 자신과 비슷하게 사고하는 사람을 뽑는 것은 최선의 방법이 아닙니다.”

글쓴이는 다양성이 팀웍의 핵심이라고 생각하고 다양한 전문가를 채용하고 이를 팀웍을 통해 부트스트랩이나 부스팅 등 협업적(앙상블)으로 아이디어를 만들어내는 팀을 구성하는이 최선이라고 얘기하고 있다.

그룹 창의성의 가능성을 보여주는 적절한 비유라고 생각된다.
서로 협업하고 의사 소통할 수 있으며 아이디어를 만들어낼 수 있는 문화, 그 기반은 다양한 아이디어를 만들고 의견을 제시하는 학습하는 개인들이기도 하다.

토요일, 2월 16, 2019

창의성을 발현시키려면

아이디어의 시대이다. 모든 기술은 학습과 아이디어를 통해 유지되고 발전한다.
하지만 특별한 우연이 창의를 만드는 건 아니다.

나는 창의성은 ‘끝까지 생각’하는 여정에서 ‘단속적으로 생각을 많이’ 하는 데서 나온다고 생각한다.
수없이 거듭되는 문제 재인지, 심화 속 어느 순간에 Aha의 찰나가 숨어있다.

적절한 문제 정의는 솔루션을 유추하게 해주는데 ‘끝까지’는 수많은 단계iteration를 의연하게 거쳐갈 수 있어야 하며 ‘단속적’이라는 뜻은 생각의 속도 조절이 도움이 된다는 뜻이다.
물론 이 속도 조절에는 생각의 방향을 역방향으로 틀어 다시 문제의 재정의로 회귀하는 걸 포함한다.
방향 전환은 속도를 떨어뜨리지만 목표 지점을 다시 찾게 하고 더 나은 길을 찾을 수 있게 해준다.

많은 생각을 끊임없이 완급과 방향을 조절하며 엄밀한 문제 해결의 지점으로 찾아가는 과정은 무작위적인 과정이 아니다.
무작위적인 과정은 평범한 관행적 사고에 머물게 한다.
끝까지 검증하고 경계를 밀어붙이는 엄밀성이 창의를 만든다.
마치 aha 현상이 무작위적 사고인 것처럼 보이지만 뇌의 다양한 사고 패턴들이 무의식적으로 동작하는 것일뿐 그 패턴 관점에서는 개인별 특성을 가질 수 있다.
그 특성은 물론 유전과 학습을 통해 갖춰지며 변화해간다.

즉, 개인별 타고난 특성과 엄밀한 아이디어 경험들이 창의적 사람을 만든다고 봐야 한다.

Nothing mystic.

일요일, 3월 04, 2018

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


기술 회의를 하는 건 일반적인 회의와 약간 다른 특성이 있는데 그건 아마도 상당 부분 물리적으로 혹은 논리적으로 검증 가능하기 때문일 것이다.
주장을 확인할 방법이 항상 있다고 생각할 수 있다.

회의에서 발언하는 사람들은 발언의 범주를 잘 구분할 필요가 있는데 흔히 자기 질문의 성격을 구분하지 않고 얘기하는 경우가 있다.

발언의 유형을 단순하게 나눠보자면
  • 1. ‘질문(몰라서 묻는)’
  • 2. ‘즉흥적 가설(문맥의 상황을 설명하거나 해결하기 위한)’
  • 3. ‘제안(의사결정이나 부분 기술에 대한 의견 제시)’
  • 4. ‘의사결정(잠정적 결론에 대한 기술)’
  • 그외 회의 진행을 돕기 위한 보완 설명
등으로 나눌 수 있겠다.

단순 질문은 명쾌해야 하며 진행을 돕는 보조 설명은 너무 늘어지면 안된다.
흔히 발생하는 문제는 질문과 가설, 제안을 혼돈하는 것과 가설, 제안과 의사결정을 혼돈하는 것이다.

몰라서 질문을 하면서 마치 의견 제안을 하는 듯이 토론을 요구하는 듯한 경우도 있고,
의견을 내면서 무조건 자기 의견을 결정하기 위한 의사결정의 안인 듯이 윽박지르기도 한다.
심지어 회의에 참석하는 것은 자기 의견을 관철하기 위한 수단으로 생각하는 경우도 있다.

토론할 때 잘못된 방식의 의견들로 다음 현상들을 볼 수 있다.

  • 반복된 변명식 주장
  • 단답형 답변
  • 말 끊기
  • 추임새식 내용없는 랩업 반복
  • 타인의 권위를 근거로 한 주장

모두 깊이있는 개념적, 다면적 이해와 아이디어 공유를 방해하는 행위들이다.

많은 오류는 마음 속에 의견이 아니라 의사결정을 들고 있기 때문이다.
시작부터 Open-ended 원칙을 추구하지 않는 셈이다.

의견과 의사결정은 큰 차이가 있다.

권한의 문제이기도 하겠지만 그보다는 의견의 수준에 있다.
의견의 수준이 충분히 의사 결정할 만큼 풍부하고 해결책을 포함해야 의사결정의 단계에 이를 수 있다.

조급함이나 압박감은 더욱 문제를 악화시킨다.

좋은 의사결정 수준에 이른 의견 혹은 안은 몇 가지 특징을 요구한다.

  • 하나는 풍부함이다. 회의를 하는 이유는 다른 생각을 얻기 위함이다.
  • 두번째, 개념의 시스템적 결합 수준이다. 전체와 부분이 잘 조화를 이뤄내는 상태임을 확인할 수 있다.
  • 세번째, 임계점이 파악되고 설명되어야 한다. 장점 외에 중요한 단점들이 파악되어야 한다.  가장 중요한 지점들이 식별되고 공유되어야 하며 그 부분을 잘 설명하거나 해결할 수 있어야 한다.
의사결정은 완벽하긴 어렵다. 늘 시점적으로 enough하면 된다. enough가 판단되지 않으면 의사결정을 미루는 게 가장 좋다.

억지로 판단을 한다면 아마 몇주 후에 완전히 새로운 안이 떠오를 것이다.

각이한 수준의 의견을 청취하는 건 때론 엄청난 인내를 요구하기도 한다.

회의 성원의 수준이나 역할이 다양하다면 더욱 큰 인내를 요구한다.

하지만 사람의 사고는 근본적으로 유사하기 어렵다.
긴장이 있는 Diversity는 늘 유익하다.

Just listen.
Parallelism wins.
Never rush to decide.

p.s. always open and listen to every opinions. just prudent and be critical to make decision

목요일, 1월 18, 2018

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

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

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

'계속 고민하던 기술 문제의 직접적인 연장선에서 내려진 결론이라면 창의적인 결론이거나 멋진 결론이 되기는 어렵다. 계속 고민하던 논리의 옆쪽에서 툭 튀어나와 와르르 내려지는 결론이 언제나 아름다운 결론이다'

왜냐하면 직접적으로 추론되는 논리는 아무리 기술적이라 하더라도 누구나 쉽게 추론할 수 있는 것이며 새로운 혁신이 들어가기 어렵다.
straightforward한 건 어려운 기술이라 하더라도 가치가 크지 않다.
그래서 마치 깊이 반복해서 고민하다 옆의 둑이 작은 바늘구멍에서 물이 새어 터지듯 나오는 아이디어가 훨씬 더 나은 답인 경우가 많다.

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

'새로운 기술은 그 장점의 이유 뿐만아니라 그 단점까지 볼 수 있을 때 비로소 이해했다고 할 수 있다. 장점만 보이면 그것은 이해한 게 아니라 그냥 시키는 대로 공부한 것이다.'

이것은 critical thinking의 문제이다. 엄밀한 사고란 critical point를 인지할 수 있어야 하고 이 문제를 해결할 때 다른 critical point를 생각할 수 있어야 한다.
이때 system thinking이 중요한데 system이란 layer 간의 혹은 전체와 부분 간의 관계를 유기적으로 파악하는 것이다. 예를 들어 소프트웨어를 시스템적으로 이해한다는 것은 하드웨어 - 운영체제 - 애플리케이션 등의 각 파트를 유기적으로 연결하여 머리 속에서 사고할 수 있다는 뜻이다.
장점만 보일 때는 의사 결정을 할만큼 이해가 된 상태가 아니다. 즉, 공부가 제대로 되지 않은 상태이다. 문제점이 보이고 시스템적 상호 작용 관계들이 이해될 때 비로소 의사 결정에 고려해야 한다.
물론 향후 더욱 기술을 구체적으로 이해하게 될 때 또다른 결론으로 변경될 가능성이 많다. 하지만 의사 결정을 위한 주요한 단계에서는 어느 정도의 변경 가능성을 열어놓을 수밖에 없다. 세부 단계에서 주요 결정 사항이 번복되는 건 어떻게 보면 불가피한 사람의 인지 과정 특성을 반영하는 것이다.

워크샵 도중 가장 놀란 솔루션은 사실 가장 단순한 아키텍처를 가진 Kafka라는 솔루션이었다.
너무 단순하고 너무 잘 알고 있는 기술이었는데 그 단순함을 끝까지 밀어부쳐 새로운 패러다임을 만들었다.
알고 있는 기술에서 아주 작은 변화였는데 말이다.
단점들도 많지만 그것은 사용하는 쪽에서 알고 쓰면 된다는 방식으로 풀어버렸다. 그것 또한 멋진 아이디어라고 받아들였다.

어젯밤 멋진 아이디어를 함께 한 친구가 냈다. 그리고 오늘은 약간의 잔 아이디어들을 붙여 큰 그림을 마무리했다.

이렇게 '아름다운 결론'을 팀웍으로 함께 만들 수 있다.