2007. 1. 16. 10:49

소프트웨어의 역량을 나타내는 말

[CTO 칼럼] 소프트웨어의 역량을 나타내는 말  
김익환 안철수연구소 부사장

전 세계적으로 소프트웨어 산업은 점점 더 하드웨어의 영역까지 흡수하면서 성장하고 있다. 그 중요성에도 불구하고 현재의 한국소프트웨어 업계는 어려운 시기를 지나가고 있지만 곧 핵심산업으로 떠오르는 것은 시간 문제이다. 그런 미래에 대비하기 위해 소프트웨어 산업에 필요한 핵심 역량이 무엇일까? 소프트웨어에 대한 해박한 지식이라고 말해버리기에는 뭔가 허전한 감이 든다. 지식은 풍부한 데 소프트웨어가 잘 안 된다는 경험은 소프트웨어에 종사하는 사람이면 누구나 경험해 보았을 것이다. 소프트웨어에 관련된 필요한 지식은 수 많은 책과 기사와 잡지와 인터넷에서 찾아 볼 수 있다. 새로 쏟아져 나오는 수 많은 기술과 마케팅의 귀재들이 계속해서 만들어 내는 Marketing Buzz Word 라고 하는 새로운 용어들도 소화하기도 힘들게 많이 생겨나고 있다. 서점에 가보면 너무 다양한 분야에 너무 많은 책이 있어서 그 모든 책에 있는 지식을 소화할 수 있는 사람은 아무도 없다. 필요할 때 필요한 지식을 습득할 수 밖에 없다. 하지만 지식은 어느 정도 시간 들여 노력하면 습득할 수는 있다는 예측 가능성이 있다.

그런 지식들보다 더 중요하고 배우기 어려운 것은 바로 필자가 항상 주장하는 소프트웨어 문화이다. 문화에는 사람의 사고방식이 큰 비중을 차지한다. 그리고 사람들의 사고방식은 그 사람이 하는 말로서 나타나게 된다. 소프트웨어업계에 종사하는 사람들의 말을 관찰해 봄으로서 소프트웨어에 관한 문화역량을 판단할 수 있다. 지식의 문제가 아니고 문화적인 역량을 말하는 것이기 때문에 학문적인 지식에 집중하고 있는 학계의 지식전문가가 지식역량은 높지만 실제 경험자보다 문화역량은 낮을 수도 있다. 학교나 연구소에서는 지식역량이 가장 중요한 요소이고 회사에서는 문화역량이 더 핵심요소이기 때문에 당연한 결과라고 할 수 있다.

필자가 현장에서 일하면서 경험한 여러 가지 말을 통해서 어떤 문화수준에 있으며 어떤 배경에 의해서 그런 상황이 벌어지는 지를 분석해 보았다. 실전의 대가로 유명한 Joel의 “The Joel Test” 에서는 12 가지 테스트를 소개함으로써 좋은 코드를 쓸 수 있는 능력을 측정한다. 이 12개 항목을 잘 살펴보면 소프트웨어문화가 어떤 의미를 가지는 지를 가르쳐 준다. 물론 다양한 환경의 차이에 따라 Joel Test의 모든 항목에 동의하는 것은 아니지만 소프트웨어에 종사하는 사람이면 언제든지 참고해야 할 훌륭한 자료이다. 요즈음은 실용적인 개발문화에 대해 많은 책이 소개되는 것을 보면 이제 한국의 소프트웨어의 문화도 한 수준 제고 되었다는 것을 느낄 수 있다. 이런 책들이 중요하다는 것을 느끼는 것 자체가 웬만한 역량이 있기 전에는 어렵기 때문이다. 그러면서도 간과하면 안될 점은 그런 책들도 역시 현실에서 부딪쳐서 깨닫기 전까지는 아직도 머리 속에 들어 있는 공허한 지식이라는 점이다. 최종 목표는 그런 실용주의적인 방법들이 몸에 배어 우리의 문화로 성숙되는 것이다. 그래야만 진정한 소프트웨어 전문가가 되고 소프트웨어산업의 밝은 미래를 기대할 수 있다.

필자는 소프트웨어 전문가들이 가져야 하는 기술이나 문화를 일방적으로 나열하는 노력은 하지 않으려고 한다. 이미 실용주의 적인 책들이 많이 소개하고 있으니 그런 정보는 중복된 정보일 뿐이다. 다른 각도에서 보려고 한다. 사람들이 사용하는 말에 따라 역량을 판단하며 그 배경을 말해주는 것이 자기가 어떤 상황에 있는 지를 정확히 인지할 수 있으며 그에 대한 적절한 대응을 하는데 이해가 쉬울 것 같은 생각이 들었다. 이러한 One-Point Lesson 식의 방법이 더 가치가 있을 것이라고 생각한다.

사람의 역량을 판단하는 데는 많은 대화가 필요하지 않다. 선문답(禪問答)이라는 것이 있다. 애들 장난같이 수수께끼 같은 문제를 내고 수수께끼 같은 답을 하는 것인데 잘 모르는 상태에서 보면 그 심오함을 깨닫기는 어렵다. 주로 불교의 수행에서 스승이 제자의 수준을 테스트하기 위하여 사용한다. 이 한 두 마디의 문답으로서 어느 정도 수준인지를 판단한다. 선수만이 선수를 알아 보는 것이다. 낮은 수준에 있는 사람들이 들으면 실 없는 소리로 들리고 스승이나 제자나 별 차이가 보이지 않을 것이다. 소프트웨어 분야에서도 무심코 얘기하는 말이 그 사람의 수준을 반영하게 된다. 필자가 실제로 많은 경우에 경험한 공통으로 사용되는 말들을 몇 가지 예를 들어 분석해 보았다.

“개발하는 데 얼마나 걸립니까? “
“해 봐야 알 수 있습니다.”


이런 답을 하는 사람은 좋게 말하면 솔직한 사람이고 사실대로 말하면 고지식하거나 초보개발자다. 회사에서 제품개발, 유지보수 등 회의를 하다 보면 아마 가장 자주 나오는 질문이 “이거 개발하려면 어느 정도 걸릴까요?” 이다. 정확한 답이 없고 대답도 난감할 것이다. 이럴 때 가장 흔한 답이 “그걸 어떻게 압니까? 해 봐야 알겠는데요.” 이다. 다 맞는 말이다. 해보기 전에 어떻게 정확한 일정을 알 수 있는가? 하지만 해 봐서 알 것 같으면 물어볼 필요도 없었다. 윤리적으로 보면 거짓말을 하는 것 보다는 정확한 일정은 모른다고 하는 것이 좋다고 가르칠 것이다. 회사의 환경은 미안하게도 이러한 고지식한 윤리가 통할 수 없다는 데 딜레마가 있다. 역량에 따라서 며칠 걸리는 작은 프로젝트에서도 일정을 추정할 수 없는 사람이 있고 10년이 걸릴 프로젝트에서도 일정을 추정할 수 있는 사람이 있다. 물론 오류는 항상 있을 수 있고 있는 것이 통상적이다. 일정의 정확도의 문제는 또 다른 하나의 풀어야 할 이슈다. 그럼에도 불구하고 일정이 있어야 한다는 것을 얼마나 중요시하는 것 자체가 역량의 차이다. 필자가 생각한 가장 좋은 답을 다음과 같다. “지금 현재 상황에서 최선의 판단을 하면 … 정도 걸릴 것으로 추측하는데 … 정도의 시간이 있으면 좀 더 정확한 답을 드릴 수 있습니다.”

왜 모든 일의 초기부터 일정 판단이 중요한 가는 회사는 유기적으로 모든 기능이 연관되어 있다는 것이다. 개발자들이 갖는 주된 착각은 개발이 소프트웨어회사의 중심에 있다고 생각하는 것이다. 천만의 말씀이다. 회사의 수 많은 핵심기능 중 하나일 뿐이다. 기획, 마케팅, 개발, 영업, 기술지원 등이 모두 예상되는 일정에 의존해서 활동을 한다. 개발이 언제 시작하고 언제 끝날 것이라는 예정 하에 각 부서는 병행해서 업무를 진행하는 것이다. 이런 유기적인 관계를 유지하기 위해서는 모두의 일정이 꼭 필요하고 서로의 일정에 대한 상호신뢰를 바탕으로 한다. 이런 유기적인 관계 없이 순차적으로 개발하고 있다면 One-Man Company이거나 이제 시작하는 신생업체 일 것이다.

거짓말에는 세가지 거짓말이 있다고 한다. 좋은 거짓말, 나쁜 거짓말, 통계의 거짓말이다. 그 중에 통계의 거짓말이 사실로서 진실을 왜곡시키는데 사용하는 궤변가들의 가장 중요한 무기이다. 예를 들어보자. 미국에서의 프로젝트가 제 일정에 끝나는 통계를 내 보았더니 2003년도에 30%도 안 되는 것으로 나온다. 그러면 그 만큼 엉터리 일정으로 잘 못했다는 것인가? 통계의 허구성을 예를 들어 분석해 보기로 한다. 두 사람이 일정 30일 짜리 프로젝트를 했는데 한 사람은 30일 안에 끝낼 수 있을 것 같아서 일하다가 마지막에는 밤을 세워 가며 했는데 결국은 35일 만에 끝냈다. 예정되었던 30일 째 날에는 다른 부서 사람들이 기다리고 있었는데 최선을 다했지만 미안하다는 소리밖에는 들을 수 없었다. 다른 부서 사람들에게는 청천벽력 같은 소리다. 다 준비해 놓고 기다리고 있는데 모든 일정이 망가진다.

두 번째 사람은 개발을 시작해서 1주일쯤 설계도 하며 일정을 다시 측정해 보니 30일은 무리이고 40일 정도면 가능할 것 이라고 나왔다. 그래서 1주일 지난 시점에 다른 부서 사람들에게 “미안하지만 측정이 잘못되었습니다. 이 프로젝트는 40일로 일정 변경하겠습니다.” 라고 하고 40일에 무사히 프로젝트를 종료했다. 다른 부서들은 이미 한달 전에 합의된 변경된 일정에 따라 적절한 대응책을 마련했으니 큰 타격은 없다.
결론적으로는 첫째 사람은 35일 걸렸고 둘째 사람은 40일 걸렸지만 겉으로 나타나는 통계와는 달리 둘째의 경우가 더 바람직하다. 물론 처음 일정대로 책임감 있게 열심히 일해 끝내는 것이 가장 좋을 것이다.

신 기술을 사용해야 하겠습니다

제품을 개발할 때 호기심으로 연구해 보고 싶은 기술이 있을 때 이런 말을 듣는다. 이렇게 말하는 사람들은 대부분 기술자들이다. 혁신적인 것을 선호하는 기술자들의 성향 때문에 자주 벌어지는 현상이다. 역설적으로 그렇지 않으면 사실 기술자도 아니다. 하지만 이 말이 대부분의 경우 남용되고 있다는 데 문제가 있다. 나중에 기회가 있으면 말하겠지만 영업이나 마케팅하는 사람들은 전혀 다른 말을 할 수 있다. 관점이 다르기 때문이다. 하여튼 이렇게 말하는 사람은 기술력은 있을 지 모르나 비즈니스 개념이 약하다. 불행히도 비즈니스 개념이 없이 성공적인 경력을 이끌 수 있는 곳은 학교나 연구소 밖에 없다. 회사에서는 모든 하나하나의 결정이 누군가 실제 사용해야 하는 고객을 위한다는 점으로 인해서 비즈니스적인 결정과 연관되어 있다. 취미로 연구생활을 하지 않는 이상은 순수한 기술적인 결정은 회사에는 없다. 모든 기술의 목표는 상용제품이든 자체사용하든 누군가가 실제로 사용하는 무엇을 만드는 데 있다. 신기술 사용 못해서 실패한 회사 없다는 말도 있다. 반면에 학교나 연구소에서는 어떤 기술이 가능한 지 가능하지 않은 지를 알아내는 데에 있다.

학교나 연구소에게는 개발문화니 방법론이니 등에 관해서 필자가 별로 할 말이 없다. 그런 경우야 말로 구속적인 방법론이나 규칙보다는 각자 자유롭게 연구하는 것이 가장 좋은 방법일 것이다. 학교에서 제품 개발하는 회사 하듯이 가르치고 연구하면 이론적으로 배워야 하는 지식의 십분의 일도 배우기가 힘들 것이다. 회사에서는 당연히 되기 위한 목적으로 개발해야 하며 되더라도 훨씬 더 많은 경우인 예외상황까지 다 고려해야 하기 때문이다. 학교는 되는 것을 빨리 보여주는 데에 핵심역량이 있는 것이므로 학교에서 회사와 같은 문화를 적용한다면 그것은 학교로서의 본분을 망각하고 있는 것이다.

학교에서 배운 것은 못 써 먹는다

업계에서는 고급 소프트웨어 인력의 부재로 인해서인지 학교에서 할 역할에 대해 다음과 같이 말하는 사람들이 있다. 학교에서 이론만이 아니고 사회에 나가서 사용할 수 있는 지식을 가르쳐야 한다고 한다. 잘못된 것은 아니지만 잘못 이해하면 착각을 하게 된다. 이론적으로 훌륭한 구조적 언어인 PASCAL을 가르치는 것이 좋을까? Java를 가르치는 것이 좋을까? 지식도 가르치고 현실에 적용 가능한 Java를 가르치는 것이 좋을 것이다. 이 경우에는 전적으로 공감한다. 어차피 언어를 가르치려면 언어도 가르치고 현실에도 적용 가능한 언어를 가르치는 것이 금상첨화일 것이다. 하지만 학교에서 Software Requirement Specification (SRS, 요구사항 분석서)를 작성하는 방법을 가르친다면 어떨까? 그것을 학교에서 배우는 것이 얼마나 효과가 있을지도 생각해 보아야 하고 그 시간에 다른 과목을 배우는 것이 더 효과적이지 않을 까 하는 생각이 든다. 학교에서 얼마나 배울 것이 많은가? 기본적으로 갖추어야 할 지식만 나열해도 Operating System, Network Architecture, Computer Architecture, Graphics, Database, Algorithm, Artificial Intelligence, Programming Language, Compiler Theory 등 언제 어디서 사용될 지 모르는 지식들이다. 이런 것들은 나중에 시간 내서 회사에서 필요하다고 배우기는 어렵다. 배우려면 혼자서 공부해서 배우거나 아니면 결국은 학교에 가야 하기 때문이다.

SRS작성은 현실이다. SRS에 대한 표면적인 이론은 지식으로 가르칠 수 있지만 진정으로 SRS를 작성하는 기술은 현실에서만 배울 수 있다. 그것도 SRS를 작성할 당시에는 잘 모른다. 나중에 개발이 끝나고 다시 생각해 보면 더 좋은 SRS를 작성할 수 있었는데 하는 생각이 저절로 나면서 배우게 된다. 그것이 경험이다. SRS를 작성하는 능력 중에서 10%가 지식, 90%가 경험에서 정립된 문화라고 생각한다.

필자가 중국 무술의 근원이라고 하는 태극권을 초보자로서 배울 때의 일이다. 필자도 항상 모든 것을 지식적인 측면에서 접근하는 면이 강해 책도 사고 비디오도 사고 해서 상급자가 수련하는 것까지 미리 다 한발 앞서서 공부하고 외울 것 외우고 머리 속의 이론으로 정립하고 갔다. 사실은 스승이 내가 궁금해서 물어보는 것을 잘 가르쳐 주지 않는 데에 궁금증이 도져서 내가 혼자서 공부하겠다는 일종의 오기로 한 것이었다. 스승은 이미 내가 쓸데 없는 것을 공부했다는 것을 알고 있었다. 모르고 하는 것이 알고 하는 것보다 더 도움이 되기 때문에 필자의 편견이 생길 수 있는 지식은 일부러 가르쳐 주지 않는다고 했다. 시간이 없어서 안 가르쳐 주는 핑계거니 생각하며 그 당시에는 이해가 안되었지만 나중에 모든 것을 이해 할 수 있게 되었다. 그래서 선각자들이 “잔소리 말고 하라는 대로 해” 가 옳은 경우가 더 많다는 것도 점점 경험이 쌓이면서 알게 되었다. “방편” 이라는 말이 있다. 지금까지 가장 많은 강연을 한 사람이 부처라고 하는데 부처도 수 많은 설법을 하면서 청중수준에 맞추어서 “방편”을 사용했지만 한 번은 청중들이 도저히 받아들일 수 없는 수준인데 제자가 간곡히 부탁해서 거북한 설법을 시작했는데 다행히도 시작하자 마자 거의 모든 청중이 떠나가고 이해할 수 있는 소수만 남자 다행으로 생각했다는 일화가 있다.

학교에서 현실에 필요한 것을 가르치려고 한다면 그 학교는 직업전문 학교와 같다. 회사에서 주장하기를 “학교에서 나온 졸업생을 즉시 현업에 투입하기가 힘들어서 학교에서 잘못 가르치는 것이 아니냐?” 고 하는 데 그건 당연한 일이다. 회사에서 사용할 수 있게 훈련을 시켜야 하는 것은 회사가 할 일이다. 당장 회사에서 써 먹을 수 있는 학생들을 배출한다면 단기 목표로 기능공을 양성하는 직업 전문 학교에 불과하다.

그거 별 기술 없습니다. 우리도 개발할 수 있습니다.

엔지니어들에게 다른 회사 제품 검토하게 하면 자주 나오는 소리다. NIH (Not Invented Here)라는 용어로 알려져 있는 자기가 만든 것이 아니면 믿지도 않고 가치를 잘 인정하지 않는 것이다. 자기존중과 착각으로 자기가 개발하지 않았으면 다 별거 아니라고 한다. Yahoo의 핵심기술은 무엇인가? Microsoft의 핵심기술은 무엇인가? 특별히 꼬집어 말하기는 쉽지 않다. 솔직히 시간과 돈만 있으면 다 따라 할 수 있는 것 아닌가? 이렇게 생각할 수도 있다. 그런데 바로 “시간과 돈”이 핵심이다. Rocket Science라고 말하는 혁신적인 기술보다는 주어진 시간 안에 제품화하는 기술이 더 중요할 수도 있다는 것을 알아야 한다. 또 제품화과정 중에 시행착오에 드는 비용이 항상 생각보다 크게 마련이다.

상용제품을 만드는 보람이 사용되지도 않을 신기술을 연구하는 보람보다 못하지 않다. 실제로 현실에서 요구되는 많은 전문개발자들은 제품 만드는 사람들이다. 그렇다고 신기술의 중요성을 간과하는 것은 아니다. 구글을 보아도 초기에는 소수의 사람들이 신기술을 적용하면서 커가지만 그 후에는 상용 제품화하는 능력이 더 큰 비중을 차지한다. 제품화를 못하면 회사는 계속 성장하기 어렵다. 그러한 점이 마이크로소프트가 지금까지는 성공한 이유고 구글이 미래에 직면하는 도전중의 하나일 것이다. iPod와 같이 기술이 있어서가 아니라 디자인으로 승부하는 제품도 있고 기능은 별거 없으나 빨리 저가로 만들어서 박리다매로 승부할 수도 있다.

모든 사람이 잘 받아들이지 않는 재미있는 현상이 있다. “왜 다른 사람이 내 뜻을 몰라 줄까?” 인데 타인이 자기를 평가하는 것보다 자기가 자기자신에 대해서 거의 예외 없이 높게 평가한다. 소스코드 리뷰를 하면 서로 다른 사람의 코드는 낮게 평가한다. 그만큼 우리 모두 착각 속에 산다. 자기보다 더 높은 지식은 평가할 능력이 없기 때문에 그냥 자기가 조금만 하면 따라 할 수 있다고 생각하며 착각 속에 산다. 그러면서도 남이 가진 떡이 커보인다는 이중성도 가지고 있다.

이 책에서는 다르게 얘기 하던데요.
전문가가 다르게 얘기 하던데요.
다른 회사에서는 이렇게 하던데요.


회사에서 “이렇게 합시다.” 하고 규칙과 방법을 정해서 하자면 이런 소리를 하는 사람이 있다. 그런데 이런 소리를 하는 사람은 대부분 다른 곳에 가도 똑 같은 소리를 한다. 한가지에 불평하는 사람은 원하는 것을 갖다 주어도 또 불평을 한다. 일전에 보잉의 최고기술자이며 카네기멜론 대학의 교수가 와서 강연할 때 같은 얘기를 했다. 자기는 지금까지 쌓아온 경험과 지식으로 최선을 다해서 강연하고 있으면 누군가가 “자기가 본 책에는 그렇게 적혀있지 않은데요.” 라는 말을 한다고 한다. 그러면 대답하기를 “그 책을 믿고 그 책이 시키는 대로 하든지 나를 믿고 내 강연을 듣던지 둘 중에 하나를 택하세요. 둘 다 얻을 수는 없습니다.” 라고 한다고 한다. 책을 분석적으로 읽는 독자라면 대부분의 책들 자체가 일관성이 없다는 것을 눈치챌 수 있다.

같은 주제에 대한 책을 몇 권 사다 놓고 자세히 살펴보면 수 많은 모순이 있음을 발견하게 된다. 개발방법만 해도 폭포수모델을 사용하려고 하면 프로토타입모델이나 Iterative 방법론을 들고 나와서 혼란하게 만들 수 있다. 지식에 더 많은 비중을 두는 필자도 스키 배우려고 책과 비디오를 많이 보았는데 어떤 책에서는 무게 중심을 중간에다 두라고 하고 어떤 책은 앞에다 두라고 한다. 둘 다 옳은 말이다. 무게 중심의 위치는 초보자들에게 스키를 설면에 누르는 방법을 가장 쉽게 가르치기 위한 방편일 뿐이지 진정한 속 뜻은 다른 데에 있기 때문에 책에 따라서는 다른 식으로 얘기 할 수 있다. 그러니 몸무게를 앞으로 두라고 배운 사람이 가운데 두어도 된다는 말을 들으면 틀렸다고 생각할 수 밖에 없다. 나중에 상급자가 되면 두 책 모두 다 옳고 핵심을 알고 보면 모든 것이 다 이해가 되는데 우물 안 개구리식의 단편적인 지식으로는 자기의 지식과 다른 것은 받아 들이기 힘들다. “이것도 옳고 저것도 옳고 다 옳다” 라는 말을 진정으로 알고 하는 사람이면 고수일 확률이 높다.


어떻게 하면 소프트웨어 전문가를 양성하겠습니까?

전문가를 양성한다는 것에 필자가 생각하는 전문가의 정의로서는 동의하기가 어렵다. 전문가는 많은 노력을 들여 자기가 이루는 가는 것이지 어떻게 양성해 낼 수가 있겠는가? 전문가가 되기 위한 요소의 일부분은 충족 시킬 수 있겠지만 많은 부분이 자기자신의 노력이다. 타인이 쉽게 도움을 줄 수 있는 부분은 지식역량 분야이다. 지식이야 가르쳐 주면 되지만 그 나머지는 모두 자신의 몫이다.

수영선수를 길러낸다고 생각해 보자. 수영이론을 다 가르쳐주고 땅 위에서 숨 쉬는 법, 물장구치는 법, 팔 사용하는 법 다 외웠다고 가정하고 물에다 빠뜨려 보면 어떻게 되는지 삼척동자도 알 것이다. 학교에서 나와서 실제 소프트웨어를 개발하게 되면 흥분되었던 마음과는 달리 이와 비슷한 상황에 부딪히게 된다. 전문가라고 하기에는 상식적으로 인정하는 기간이 있을 것이다. 몇 달 배웠다고 전문가라고 할 수는 없다. 2-3년 근무한 사람을 전문가라고 한다면 이 세상에는 모두 전문가 투성이 일 것이다. 전문가라고 말하려면 그만큼 어렵고 희귀성이 있어야 전문가지 너도나도 전문가이면 전문가가 아니다. 전문가가 되기 위한 단기간의 비법은 없다.

필자는 전문가라는 단어의 애매모호성 때문에 좀 더 혼동이 적게 가는 “선수”라는 단어가 더 마음에 든다. 진정한 선수가 되고 싶다면 이론을 가르치는 강사도 아니고 훈수 잘 두는 코치나 Consultant가 되어서도 안 된다. 경영학 교수나 경영 Consultant하는 사람을 경영진을 시킨다고 회사의 경영을 할 수 있는 것은 아니다. 경영은 현실이고 Consulting은 Consulting에 불과하다. 코치나 강사는 그들 나름대로의 고유한 역할이 있는 것이다. 하지만 실제 일은 코치도 아니고 강사도 아니고 선수가 하는 것이다. 훈수 두는 사람은 많다. 신도 모른다는 주식 투자하는 법을 가르치는 사람들은 많지만 경제학자 중에서 주식에 투자해서 성공한 사람이 케인즈 밖에 없다는 농담이 있을 정도로 이론과 현실은 다르다. 그렇다고 경제학자가 필요 없거나 거짓말을 하는 것은 아니고 현실과의 괴리를 극복하기 어렵다는 말이다. 강사와 코치가 많은 회사는 잘 될 수 가 없다. 선수가 많아야 한다. 사공이 많으면 배가 산으로 간다고 서로 다른 의견으로 인한 갈등과 분열을 일으키고 혹시라도 결과가 안 좋으면 서로 책임을 미루고 비방하게 된다.

필자가 다양한 환경에서 자주 경험했던 몇 마디 말에 관한 분석을 해 보았다. 지식은 지혜를 깨닫는 데 방해가 된다고 한다. 지식이 많으면 많을수록 지식에 집착하고 모든 것을 지식에 의해서 판단하려고 하기 때문에 조심해야 한다. 가진 지식이 없으면 받아들이기 쉬운데 가진 것에 집착하며 잃지 않으려는 인간의 본능 때문이다. 지식으로 문화를 판단하는 잘못을 저지르지 말아야 하겠다. 문화는 현실에서 느끼기 전에는 배울 수가 없다. 필자가 존경하는 정신적인 스승과 저녁을 같이 먹는데 처음 보는 채소가 있어서 저건 맛이 어떠냐고 물어보니까 아무 말 하지 않고 그냥 집어서 입에다 넣어주었다. 더 이상 할 말이 없었다. 아무리 맛을 설명해 준 들 내가 알겠는가? 그냥 먹어보면 되는 것을 잠깐이긴 하지만 머리로 분석하고 있다는 것을 깨달았다.


[출처] 마이크로소프트웨어 2006년 3월호

'Study Story > References' 카테고리의 다른 글

헝가리안 표기법 (Hungarian Notation)  (6) 2007.01.22