최소한 글에 신빙성을 부여할 수 있을지 몰라 약간의 제 소개를 합니다.

프로그래밍은 85년 APPLE II부터 시작하였고 베이직을 마스터 하는데 6개월 걸렸으며 (여기서 마스터라 함은 다른 기종의 BASIC으로 되어 있는 프로그램들을 APPLE용으로 수정할 정도의 수준, APPLEII에 없는 기능의 경우 만들어낼 수 있는 정도) 그 이후 대학에 들어가기 전까지 C를 사용하고 싶었으나 APPLE II의 속도상의 문제로 (참고로 APPLE II의 CPU속도는 아시는 분은 아시겠지만 1MHz입니다. 더군다나 8bit이고 레지스터가 3개 밖에 안되며 메모리는 0000~FFFF까지 64KB라 하지만 D000~FFFF까지는 ROM이 사용하고 (물론 그 부분도 확장해서 RAM으로 사용하는 방법이 있죠) C000~CFFF까지는 하드웨어를 다루는 부분으로 예를 들어 C030번지의 경우 한번 접근만 해도 컴퓨터에서 틱소리가 나 애플의 경우 음악을 위해 딜레이를 준 후 C030를 액세스 하는 방식으로 소리를 냈었죠. APPLEII로 프로그래밍 하신분이라면 다들 기억하실 겁니다. 그리고 A000~BFFF까지는 디스크 플레이어가 있는 경우 디스크 플레이어를 다루기 위한 부분이 항상 로딩이 되어 있었죠. 그래픽 메모리 또한 따로 있는게 아니라 램을 사용하여 0400~07FF번지는 TEXT1 및 GR1 플레이용이였고 0800~0BFF번지는 TEXT2 및 GR2 플레이용이였고 2000~3FFF는 HGR1, 4000~5FFF는 HGR2였습니다. 그리고 베이직으로 프로그래밍을 하면 기본주소가 0800번지부터 베이직이 저장이 되었기 때문에 프로그램이 길어질 경우 그래픽과 겹치는 걸 염두에 뒀어야 됐었습니다.

APPLEII에 대한 얘기를 하자면 끝이 없기 때문에 여기서 멈추고 그 후 대학에 들어와 C를 다루다 VB, C++, VC++, ASP, PHP 등을 다루게 되고 Sybase, Oracle, MSSQL Server등의 데이터 베이스 또한 다루어 보게 됩니다.

개인적으로 특기라 생각하는 언어는 C++이지만 프로젝트를 진행할때 언어는 특별히 가리지 않습니다. 예를 들어 간단한 미들웨어를 만들때는 C로 만들었고 속도와 성능 그리고 개발의 편의성을 필요로 할 때는 Delphi, 멀티플랫폼에서 실행되는 프로그램을 개발할 땐 자체 라이브러리를 C++로 만들어 개발했죠.

프로그래머로서 어느 이상의 레벨이 되면 자신만의 철학이 생기기 때문에 프로그래밍 또한 매우 일관성있게 하고 자연적으로 객체지향적으로 개발을 하게 됩니다.

VB사용하는 분들을 보면 VB Class에 대한 기본개념도 없는 분들이 많던데 중요한건 한가지 언어에 완전히 달통하게 되면 다른언어는 그냥 흡수하듯이 익힐 수 있다는 겁니다.

자신이 코더인지 개발자인지를 구별하는 방법으로는 제생각에는 코더가 아닌 개발자 수준이라면 예를 들어 엑셀을 만들라고 하면 엑셀을 혼자 다만들 시간은 없으니 엑셀의 기능중 하나를 선택하면 그 걸 만들 정도가 되어야 한다고 생각합니다. ActiveX 컨트롤 같은 걸 가져다 이리저리 배치한 후 프로그램을 만드는 건 코더입니다. 프로그래머가 ActiveX 컨트롤을 사용하는 건 시간을 줄이기 위해서이거나 리소스 낭비를 막기 위해(한달에 500만원 받는 사람이 증권 차트를 만들기 위해 한달이 걸렸는데 100만원이면 주고 살 수 있는 차트가 있었다면 400만원 날린거나 마찬가지 인거죠. 물론 커스터마이징 가능하다던지 여러가지 변수가 있지만 간단히 따져서 그렇다는 겁니다.) 쓰는 겁니다.

우선 지금 막 생각나는 건 뛰어난 학습능력, 목표의식, 학습의 일상화 등이 필요하다고 생각합니다.

제 생각에 80%이상의 프로그래머가 MSDN또는 자신이 사용하는 언어의 도움말도 정확히 해석을 못하거나 사용하질 못합니다.

프로그래밍 분야는 끝없이 복잡해지는 분야이기 때문에 학습능력이 남들보다 뛰어나다는 생각이 들지 않으면 일지감치 따른 길로 가는게 최상의 선택입니다.

최소한 책이 없어도 처음 보는 언어를 도움말만 이용해서 테트리스 정도는 쉽게 짤 수 있는 수준은 되야 합니다.

처음 보는 언어로 하루안에 테트리스를 짤 수 없다면 뭔가 문제가 있는것입니다.

학습의 일상화를 가장 쉽게 할 수 있는 방법은 일을 하는 것 자체가 학습이 되는 그런 일을 하는 겁니다.

저의 예를 들어보자면 Delphi를 사용한것도 Delphi로 진행되는 프로젝트에서 특별한 기능을 갖어야 하는 서버를 만들 수 있는 사람이 없어 울며겨자먹기로 Delphi처음써보는 제가 만들게 되면서 Delphi를 익히게 되었죠.

그리고 MFC의 경우 처음 다루게 된 것이 증권거래시스템 클라이언트 부분을 만들어야 하는데 회사내에 MFC를 다룰 주 아는 사람이 없는 관계로 제가 MFC를 처음 써보면서 만들게 되었습니다.

그것이 인연이 되어 MFC를 분석해보게 되다 MFC의 둔중한 무게가 싫어 슬림한 멀티플랫폼용(Windows, Linux, Unix에서 똑같이 컴파일됨, 컴파일 옵션만 바꾸면 됨) 라이브러리를 만들게 됩니다. 혹시 분석하고 싶으시거나 원하시는 분이 있으면 제가 직접 만든 멀티플랫폼 라이브러리를 보내드릴 수 있습니다. (혼자만들기에는 너무 방대한 양이였고 현재 직업이 프로그래머가 아니기 때문에 일단 개발 중단 상태이지만 구현된 부분까지는 멀티플랫폼에서 작동하는 소켓예제같은 여러개의 실행되는 샘플들이 있습니다. Sample의 구조를 보면 MFC와 비슷하나 라이브러리의 구조는 MFC와는 매우 틀립니다.)

새로운 언어라든지 새롭게 나온 책이라던지 한번씩은 훑어보기라도 하는 호기심이 있어야 합니다.

자기가 관심있거나 잘 아는 분야의 책중 처음 보는 책표지를 본다면 반드시 어떤 내용이 있는지 봐야 직성이 풀려야 겠죠.

제가 어렸을 때 인천에서 살았는데 책을 많이 살때는 강남컴퓨터 서적에서 상자를 받아서 상자에 책을 담아 어깨에 매고 인천까지 가져온적도 있습니다. (봉지나 가방에 들어갈 양을 초과해서)

사실 프로그래밍에서 언어의 종류나 DB의 종류같은 건 그리 중요하지 않습니다. 언어자체의 원리를 이해하고 Database자체의 원리를 이해하면 나머지는 저절로 익숙해 집니다.

아래의 추천책들은 자신이 주로 사용하는 언어에 상관 없이 봐야될 책들입니다.

참고로 제가 나열한 책은 가지고 있고 본 책들 입니다.

꼭 봐야하는 책이기에 설명은 대충하거나 생략합니다.

• Effective C++ 시리즈 : 프로그래밍 왠만큼 하신 분들은 다 봤을거라 생각하는 필독서죠. 아직 안보신 분들은 무조건 보시기 바랍니다.
  
• Writing Solid Code : 이 책은 안보신 분들이 상당히 많을 것 같은데 책 제목 자체를 보셔도 알겠지만 꼭 봐야될 책입니다.
  
• Code Complete : 말이 필요없습니다. 코더가 아닌 프로그래머가 되고 싶다면 필독해야할 책
  
• Practical Standards for Visual Basic : VB책이란 이유로 안보시려는 분들이 많을 수 있는데, 이 책을 보는 이유는 프로젝트를 진행할 때 Naming 룰이라던지 Commenting이라던지 정확한 함수의 사용법이라던지 언어에 상관없이 타 언어에 응용할 수 있는 부분이 꽤 있으니 안보신 분들은 꼭 보시기 바랍니다.
  
• Debugging Applications : 보시면 디버깅에 대한 모든 걸 알게 될 겁니다. 디버깅에 대한 모든 것을 다룬 책으로 저는 잃어버려 한번 더 샀죠.
  
• Exceptional C++ : Effective C++과 어느 정도 유사한 책으로 위의 책을 다 읽으셨더라도 읽으신다면 꽤나 재미있을 책입니다.
  
• Game Programming Gems 시리즈 : 게임 프로그래머가 아닌 분이라도 한번 보시면 도움이 될 책들입니다.
  
• 대용량 데이터베이스 솔루션 : 말이 필요 없는 DB 책의 최강입니다.
  
  

-- 박기태

공감이 가는 내용도 있고, 도움되는 내용도 많네요 -- 남상협

java.about.com이 꼽은 Top 5 Must-read books

• Refactoring
  
• Design Pattern Explained
  
• UML Distilled
  
• The Pragmatic Programmer
  
• Test Driven Development
  

Concepts, Techniques, and Models of Computer Programming by Peter Van Roy 와 How to Design Programs를 추천합니다.전자는 concurrent programming를 비롯하여 multiparadigms를 보여줍니다.후자는 design recipe등 매우 재밌게 프로그래밍을 배울 수 있습니다. StructureAndInterpretationOfComputerPrograms라는 훌륭한책의 문제점을 해결하기 위해 만들어진 책이라고 합니다.그 외에 Books Kragen Recommends on Programming 도 좋은 참고가 될 거 같네요. -- 아무로

처음보는 언어로 하루만에 테트리스를 못짜면 뭔가 문제가 있다구요 ? ^^; 난 때려치워야 하나? -- 그로밋

기분이 상하셨다면 죄송합니다. 테트리스를 상용화된 테트리스 처럼 짜기보다는 텍스트에서 작동해도 상관없으니 (바를 #### 이렇게 표현해도 되는 식으로) 기본적인 테트리스의 기능만 가지고 실행만 된다면 만들 수 있으실 겁니다. GUI는 상관없이 문법의 차이만 익히면 되니까요. -- 박기태

약간 과장된 수사적 표현 같습니다.

프로그래머로(혹은 어떤 일이건 지식 노동자로) 성공하기 위해 학습능력이 필수적이다라는 주장에는 피터드러커를 포함 아무도 이견을 달지 않을 것입니다. 하지만 과연 학습능력과 지능지수(I.Q.)에 어떤 긴밀한 관계가 있는가 하는 것에는 의문이 남습니다(I.Q.의 신빙성에 대해서는 많은 논쟁이 있었고, 현재 I.Q.는 그 자체로는 학계에서 큰 의미를 갖고 있지 않다고 알고 있습니다). 또, 프로그래머로서의 성공 가능성과 지능지수 간에 또 필연적 관계가 있는가 이것 역시 확실하지 않습니다(별 관계가 없다는 연구 결과가 많이 있습니다).

그리고 마지막으로 테트리스를 처음 접하는 언어로 하루만에 작성하는 것이 그 사람의 학습능력(혹은 지능지수)과 어떤 연관이 있는가 하는 문제가 있습니다.

저는 큰 연관이 없다고 봅니다. 제가 사람(개발자)을 뽑을 때, 어떤 알고리즘 중심의 문제를 내어 주고, 그 문제를 자신이 익숙하게 쓰는 언어와는 가장 이질적인 언어를 하나 골라서 풀어보라고 했습니다. 시간은 특별한 제한을 두지는 않습니다. 일종의 연구과제 같은 것이죠. 그리고 숙제를 제출할 때에는, 완성된 소스코드와 함께, 문제 풀이 과정의 타임 로그(언제 뭐 했는지를 기록한 것), 그리고 이 문제 풀이(새 언어를 학습하는 것 포함)를 통해 자신이 배운 교훈을 보고서 형태로 정리해서 제출토록 했습니다.

이때, 어떤 문제를 주는가가 무척 중요합니다. 가급적 GUI나 시스템 호출이 필요없는 문제를 주는 것이 좋습니다. 그렇지 않으면 어떤 언어를 고르건 해법이 비슷해 지거나, 아니면 쓸데없는 데에 시간을 허비하기 쉽상입니다. 평가시에는, 얼마나 빨리 학습했는가도 중요하지만, 어쩌면 그것보다 더 중요한 것은 어떻게 학습했는가, 그리고 무엇을 학습했는가, 학습한 것을 어떻게, 얼마나 적용했는가, 그리고 학습과 실습 간을 오가며 피드백을 어떻게 받는가, 자신의 실패에서 교훈을 얻어서 자기개선을 하는가, 자신의 기존 지식을 비울 수 있는가(UnlearnTheLearned) 등입니다. 이 모두가 프로그래머로 성공하기 위해 중요한 요소들(동시에 학습 능력에 있어 중요한 요소)이라고 생각합니다.

이런 복잡한 것을 과연 하루만에 테트리스를 짜는가 마는가의 흑백으로 판가름을 할 수 있을런지 의문스러울 뿐 아니라, 제가 알고 있는 이미 성공한 프로그래머들이 이 테스트를 통과할런지도 확신이 서지 않습니다.

--김창준

김창준님의 글을 보니 제가 좀 극단적인 표현을 쓴것 같네요.

테트리스를 처음 접한 언어로 만들 수 있는지 테스트 하는 건 테트리스의 경우 누구나 다 해본 게임이기 때문에 어떤 구조로 작동되고 어떠한 프로세스가 필요하고 어떠한 알고리즘(특히 알고리즘이 필요할 만한것도 없지만)이 필요한지 알 수 있기 때문에 한가지 언어에 완전히 익숙해진 사람의 경우 다른 언어에 대한 접근을 문법의 차이나 사용법의 차이 및 그 언어 만의 프로그래밍의 방식를 알게 되면 만드는 과정은 매우 쉽게 이루어질 수 있기에(이 과정에서 학습능력이 떨어진다면 쉽게 만드는 과정이 이루어질거라 보지 않습니다.) 그런 얘기를 했습니다. 그리고 테트리스를 꼭 GUI로 만들라는 얘기는 아니였습니다. 러시아에서 만들어진 최초의 테트리스는 텍스트에서 실행되는 프로그램이였습니다. #이나 *같은 걸로 박스와 바를 만들어 그걸 떨어뜨리고 쌓아서 작동시켰죠. GUI는 전혀 상관없이 테트리스를 만든 다면 시스템 호출이나 GUI의 사용법의 차이때문에 오는 문제는 피할 수 있습니다. 그리고 테트리스는 제가 생각하는 가장 쉬운 예라 생각했고 위의 표현에 최소한이라고 되어 있죠. 실제로 문제를 낸다면 저렇게 쉬운 문제를 내지는 않을 겁니다.

그리고 제가 생각하는 I.Q.란 얼마나 패턴을 잘 찾느냐로 정의를 합니다. 예를 들어 경제의 다양한 변수들(원유가, 나스닥지수, 환율의 변화 등등)과 한국 시장간의 관계를 규명하기 위해서는 단순 비교로는 되지 않고 다양한 방식으로 관계를 알아내야 하는데 그 때 패턴찾기에 능한 사람과 그렇지 않은 사람간의 차이는 극명하게 들어납니다.

개인적으로 I.Q.란 복잡하게 보이는 현상속에서 규칙을 찾아내고 단순화 시킬 수 있는 능력이라 생각합니다.

실제로 중고등학교에서의 I.Q.문제와 멘사의 I.Q.문제는 매우 다릅니다. 멘사의 I.Q.문제는 말그대로 패턴찾기로 논리회로나 기계어를 약간 공부한 해서 XOR,OR,AND의 비트연산의 응용만 잘하면 95%이상은 맞출 수 있는 문제들 입니다. (제가 멘사의 회원이기 때문에 압니다.) 근데 그 I.Q.란 충분히 신빙성이 있다고 생각합니다. 특히 프로그래머에게 있어서는.

--박기태

다큐먼트 모드의 글이 좀 주관적인 것 같습니다. 쓰레드의 내용을 적절히 반영할 필요가 있는 듯 합니다.

전 프로그래머의 능력을 지식, 학습 능력, 사고 능력 세 가지 정도로 판단할 수 있다고 봅니다. 저보고 프로그래머를 뽑으라면 이 세 가지 영역을 판단할 수 있는 테스트를 할 것입니다. 지식 테스트로는 리팩토링을 할 줄 아는지, 몇몇 널리 쓰이는 디자인 패턴을 알고 있는지, XP에 대해 아는지, 자신 있는 언어의 장단점에 대한 의견을 피력할 수 있는지를 물어볼 것입니다. 학습 능력 테스트로는 새로운 언어, 혹은 새로운 프레임웍을 던져주고 이를 이용해서 간단한 과제를 수행해보게 할 것입니다. 사고 능력을 판단하게 하기 위해서는 이제껏 팀내에서 발생했던 문제들을 던져주고 어떻게 해결하는지를 보겠습니다. 이런 테스트에서 좋은 결과를 보여줄 수 있는 사람이라면 좋은 프로그래머로 판단해도 좋으리라 생각합니다. 비중은 20:30:50 정도로 주면 되지 않을까 합니다.

반대로 이야기한다면 좋은 프로그래머가 되기 위해서는 이런 테스트를 통과할 수 있는 능력을 기르는 게 좋을 것입니다. 기초적인 지식들을 쌓고 학습 능력과 사고 능력을 키우는 것이죠.

-- 박영록

인지심리학 쪽에 이와 관련한 연구가 많이 진행되었습니다(특히 70, 80년대 전문성expertise 연구에서). 체스의 대가들에게 진행 중인 체스 게임의 판 배치를 10초 이하로 보여주고 그걸 똑같이 기억해 내보라는 주문을 하면 별 어려움 없이 쉽게 해냅니다. 하지만 체스판의 말이 무작위로 배치되면 일반인의 기억능력과 통계학적으로 유의미한 차이를 보이지 않습니다. 즉 특출난 기억능력이나 패턴 인식 능력은 해당 도메인 내에서만 유효하다는 것이고, 특정 분야의 전문가가 일반적인 지적 능력에 있어 더 똑똑하다고 말하기는 어렵다는 것이죠. 다른 연구에서는, 뛰어난 체스 플레이어와 대가(전세계에서 손에 꼽는)를 구분하고자 할 때, 통상적인 I.Q.가 유효한 구분자가 되지 못했습니다. --김창준

프로그래밍에는 기술적인 측면 말고도 사회적인 측면이 있기 때문에 그 부분을 고려해야 할 것입니다. 예를 들면 협업이라든가 의사소통능력 같은 것 말이죠. --김창준

제가 만약에 사람을 뽑아야 하는 입장이라면, 그 사람이 리팩토링이던, 알고리즘이던 분명히 남보다는 뛰어나지 않더라도, 협업이 잘되고 의사소통이 잘된다면 반드시 뽑을것 같아요. 협업과 의사 소통이 잘되는 사람은, 금방 배울수도 있지요 ^^(이런글 달아도 되겠죠? ^^;) - 귀천

그렇게 생각해보니 사실 프로그래머는 일반적으로 좋은 지식 노동자의 자격만 있으면 된다고도 말할 수 있겠네요. 학습 능력이나 사고 능력도 따지고보면 지식 노동자에게 필수적인 덕목일테니까요. 지식 노동자에게 일반적으로 적용되는 내용과 프로그래머에게만 적용되는 내용으로 나누어서 생각해보면 어떨까요.

근데 의사소통을 잘하는지는 어떻게 판단할 수 있을까요? 면접자들끼리 토론 시켜보기? HowToBeAProgrammer에서는 최소한 두 시간 이상 구두 시험을 실시해보라고 하는데 이것도 상당히 좋은 방법이라는 생각이 드는군요.

그런데 좋은 의사소통 능력이 어떤 것인지를 구체적으로 말한다면 어떻게 표현할 수 있을까요? 상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것? '일'에서의 토론은 어떻게 해야 잘하는 것일까요? 전 아직 어떤 게 좋은지 잘 모르겠습니다. 예전엔 상대를 설득하거나 혹은 내가 설득당할 때까지 밀어붙이는 게 회사를 위하는 길이라고 생각했는데 회의라는 것이 여러 사람의 시간을 한꺼번에 쓰는 것이다보니 토론이 소모적으로 흐를 때도 많은데 무작정 시간을 갖다 붓는 게 좋은지 회의가 들더군요.

-- 박영록

지식 노동자..^^ 피터드러커님의 서적에서 본 표현 이군요 :-). 두시간 이상 구두 시험이라... 그러고 보니 Daum에서 면접을 볼때에도, 한두시간씩 면접을 보더군요...

상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것. 그게 핵심 아닐까요. 후자는 대부분 갖추 더라도, 전자는 그렇지 못한 경우가 많습니다. 상대방의 의견에 대해 제대로 듣고 이해하고 생각할수 있다함은, 어쩌면 바로 협업과도 연결될수 있는것 같습니다. '일'에서 토론 할때도 마찬가지 겠지요, 심지어, 코딩 스타일에 대해 회의를 하더라도... 상대방의 입장에서 왜 그게 좋은지 한번 심각하게 생각한 뒤에 자기 자신의 생각도 전달하고, 그리고 적당히 수용 할줄도 알아야 겠죠.

중대한 일에 대해서는, 만약 다른 사람의 의견이 선택 되었을때, 그 결정에 대한 영향이 위험할수 있고 막대하다면 논리적으로 설명하고 설득 해야 하겠지만, 그렇지 않을 때에는 큰 문제가 없다면 그냥 받아들일때도 있어야 한다고 봅니다.

어떤 논제에 대해 이야기 하다가 삼천포로 빠져 버리는등의 일을 피하기 위해, 회의를 하다가 계속해서 "지금 우리에게 중요한 것이 무엇이며, 핵심은 무엇이다. 이것을 정확히 결정 해야만 한다"는 생각을 계속 하는게 좋을듯 합니다. 그래야, 회의도 효율적으로 되지 않을까요? 당장 중요한것은 기간내에 훌륭한 프로그램의 개발하는 것이지, 내 코딩스타일이 왜 유용한가가 중요한게 아니거든요.^^(매우 주관적인 생각 이었습니다. ^^;) -- 귀천

저는 사람을 뽑을 때에 그 사람의 협동 능력, 의사 소통 능력을 측정하기 위해 집단 토론과 집단 문제 해결을 하게 했습니다.

집단 토론은 찬반 양론으로 갈릴만한 사안을 주고 한쪽을 택하게 한 뒤 테이블 양단에 서로 마주보고 앉아 토론을 합니다. 대략 30분 정도면 많은 정보를 얻을 수 있습니다.

집단 문제 해결은 답이 딱 정해져 있지 않은 문제(ill-defined problem. 예컨대 새로운 핸드폰을 디자인해 봐라 등)를 내어 주고, 피면접자 4-5명이 한 팀이 되게 해서 팀별로 문제 해결을 하는 것입니다. 시간은 1시간 정도 주면 됩니다. (초반 10분-20분 정도 됐을 때에는 몇몇 분은 자신이 생각하는 "이상적인 팀원의 모습"을 연기하려고 노력합니다. 그러다가 중반이 지나고 다른 의견과 충돌이 있거나 데드라인이 가까워지면서 심리적 압력이 높아지면 원래의 자기 모습이 드러납니다.)

이런 과정을 다 끝낸 뒤에는, 피면접자 모두는 "평가서"를 작성합니다. 평가서에는 다른 사람들의 강점, 약점 등을 분석해서 적도록 합니다. 다른 피면접자를 포함 자기 자신에 대한 분석도 포함됩니다. 그리고 마지막으로 자기가 새롭게 배운 것이나 교훈 등을 적도록 합니다.

면접자(평가자)는 새로 뽑을 사람과 같은 팀에서 일할 사람 모두 입니다. 그들은 이런 면접 시간 중 손에 종이와 펜을 들고 이리저리 자리를 옮기고 사람들의 대화를 관찰하며 평가를 합니다.

see also 면접

--김창준

예전엔 상대를 설득하거나 혹은 내가 설득당할 때까지 밀어붙이는 게 회사를 위하는 길이라고 생각했는데 ... 토론이 소모적으로 흐를 때도 많은데 무작정 시간을 갖다 붓는 게 좋은지 회의가 들더군요.

상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것. 그게 핵심 아닐까요.

이상적으로는 잘 이해하고 잘 전달하는 것이 좋은 의사 소통을 의미하는 것이겠죠. 하지만 현실 상황에서는 무수히 많은 제약이 있고, 그 제약 내에서 최선을 택해야 합니다. 특히나 그 제약에 시간이 걸려 있으면 최선보다는 그럭저럭 좋은 것을 택하는 경우가 현실적으로 더 낫기도 합니다.

모든 선택에는 트레이드오프가 있는 것이고 그 균형을 잘 잡는 것이 뛰어난 퍼포먼스와 직결되는 것 같습니다.

앞서 언급한 제가 시행한 면접 방식을 진행해 보면, 가장 우수한(창의적, 현실적 면에서) 결과를 발표하는 팀의 경우 어떤 특징이 있습니다. 그것은 정해진 시간 내에서 나름대로 괜찮은 안을 결정하고 모두가 즐겁게 동참하는 팀입니다. 그런 팀의 분위기를 만드는데 일조하는 사람의 패턴이 있을까요? 네, 있는 것 같습니다. "유도"(무술)를 잘하는 사람에 비유할 수 있을 것 같습니다.

--김창준

조금 원 주제에서 멀어지는 것 같긴 하지만, 그 패턴에 대해 좀더 자세히 말씀해주실 수 있나요? 어떻게 하면 그런 사람이 될 수 있는지 알고 싶습니다. 전 스스로가 상대방의 말을 잘 이해하고 자신의 의사를 정확히 전달하는 것은 잘한다고 생각하지만 그리 효율적인 토론을 하고 있진 못합니다. 어떤 경우는 어려운 문제를 아주 효율적으로 결론내리기도 하지만 어떨 때는 간단한 문제인데도 질질 끌면서 스트레스만 받는 경우도 많거든요. 그런 경우 속으로 그 책임을 참여자 중 몇몇에 전가시키기도 하는데-_- 그런 경우도 효율적인 토론을 이끌어낼 수 있는 사람이 되고 싶습니다. 그러려면 어떻게 해야할까요?

-- 박영록

간단하게 설명할 수 있는 그런 종류의 것은 아닌 것 같습니다만 위험을 무릅쓰고 몇가지 떠오르는 내용을 끄적거려 보겠습니다. 상대가 가려고 하는 힘의 벡터가 일시적으로 장애가 된다고 할 때 그 힘을 막아선다기보다 흐름의 결을 따라 받아 넘기는 기술이 중요한 것 같습니다. 정면으로 받아내면 나에게도 타격이 있고 상대에게도 타격이 있습니다. 그리고 진지함과 유치함을 자유롭게 오가는 것도 필요한 것 같습니다.

--김창준

테트리스를 예로 드신 것이 적절치 않다 여겨지는 이유는 텍스트로 구현한다해도 스크린 임의의 위치에 문자를 써넣고 키 입력을 처리하는 것은 GUI 못지 않게 특정 OS, 특정 터미널 그리고 (리눅스의 ncurses같은) 특정 라이브러리에 의존적인 (그쪽이 업이 아닌 이상 레퍼런스 찾아보면 되고 기억할 필요는 없는) 지식들을 필요로 하기 때문입니다. 뭐 라이브러리 레퍼런스를 뒤지는 능력도 능력이긴 하겠지만 사실 그 정도는 기본기겠죠. 프로그래머로서의 코어 능력을 테스트하기에 테트리스는 여전히 군더더기가 많고 많은 자질을 증명해주지도 않는다 여겨집니다.
-- 또마 2008-06-12 05:30:03