이번에는 Software를 개발하는 분야에서 일하고 싶은 학생들이 알아야 할 열가지를 이야기 해보겠다. 물론 여기서 이야기하는 내용은 전적으로 본인의 생각이며 경험에서 나온 것이다. 하지만, 경험이 체계화되면 지식이 되듯 그냥 흘려서 듣기보다는 한번쯤 고민해볼 가치는 있다고 생각한다.
"You start coding. I will ask what they want."
00. 코딩
Software 개발관련해서 일하고자 하는 학생들은 기본적으로 coding을 할 수 있어야 한다. 어떤 언어(Language)를 사용하는가는 시대의 흐름과 개인적인 성향에 따른 차이가 있겠지만, 최소한 자신이 목적한 바를 실제 프로그램으로 구현할 수 있는 능력은 있어야 한다. 중요한 것은 우리가 일하는 분야에서는 coding이 가장 기본적인 바탕이라는 것이다. 간혹 coding은 언제든 배울 수 있다고 생각해서 다른 곳에 신경을 더 많이 썼다는 학생들을 만나는데, 이건 정말 그른 생각이다. Coding이 바탕이 되지 않는다면 배운 지식은 무의미하기 때문이다. 마치 실제가 없는 지식은 모래성을 쌓은 듯이 언제고 파도가 밀려오면 그냥 허물어져 버리기때문이다. 어떤 언어를 잘 써야할 것인가를 두고 질문을 하는 사람들이 있다. 실제로는 한가지 언어에 능통한 사람은 다른 언어도 빨리 배운다는 점이다. 따라서, 어떤 언어라도 정말 잘 사용할 수 있는 수준까지 도달했다면 이미 기본적인 코딩 능력은 있다고 판단할 수 있다. 하지만, 잘 짠 code와 못 짠 code가 있듯이 coding은 쉽게 배울 수 있는 것이 아니다. 어쩌면 가장 오래동안 배워야 할 것인지도 모른다. 잘 짠 것과 그렇지 못한 것을 나누는 기준은 생각보다 간단하다. 즉, "남이 보기에 쉽게 짠 code"가 잘 짠 것이다. 남이 짠 code를 읽었을때의 거부감이 적을 수록 그 code는 잘 짰다는 것이다. 인터넷 상에서는 무수히 많은 남이 짜놓은 코드를 볼 수 있을 것이다. 자기가 보기에 쉽다고 생각되는 코드들의 공통점을 찾고, 열심히 연습하는 것 이외에는 사실상 coding능력을 키울 수 있는 방법은 없다. 직접해보지 않고서는 알 수 없는 것이 이론과 실제의 차이다.
01. 읽기
쓰기 위해서는 읽어야 한다. Input이 없이는 output이 없다는 것은 진리다. 물론 쓰레기 input은 쓰레기 output을 만들 확률이 높다(간혹 쓰레기 input을 주더라도 정말 멋진 output을 만들어내는 경우도 있지만). 읽기도 그냥 읽는 것이 아니라 바르게 읽는 것이 중요하다. 또한 좋은 것을 읽는 것이 중요하다. 바르게 읽는다는 것은 무슨 뜻인가? 바르다는 것은 글을 읽을때 정확히 저자가 하고자하는 이야기를 잘 이해하는 것을 말한다. 정작 중요한 내용은 다 놓치고, 중요하지 않은 내용만 머리속에 담아두는 경우가 있는데 이는 시간낭비일 뿐이다. 읽기를 하되 내용을 잘 이해하는 것이 중요하다. 실제로 어떤 책의 글귀를 잘 못 이해하게 되면 큰 낭패를 보는 경우가 종종있다. 이는 번역의 오류든 혹은 읽는 사람의 지식수준이 낮아서 그렇든, 다양한 해석을 불러올 수 있는 글들은 널려있다. 정말 하고자 하는 이야기는 사실 한번 읽어서는 잘 이해가 안되는 경우도 많다. 지적 수준이 높아질수록 기본적인 것들에 대한 개념이 중요함을 많이 깨닫는데, 이럴때 일수록 느끼는 것이 "그땐 왜 그렇게 못했지"하는 후회다. 이런 후회를 조금이라도 줄이고자 한다면 내용을 충분히 이해할 수 있는 만큼 읽어보다는 것이다. 좋은 것을 읽는 것이 중요하다고 했는데, 그럼 어떤 것이 좋은 것일까? 시중에는 다양한 책들이 있지만, 이미 검증을 통해서 반드시 읽어야 할 도서정보는 이미 다 정리되어 있다. 특정 분야의 책에서 고전이라고 불리는 책들은 어느 분야던 있기 마련이다. 최신기술을 다루는 책들도 많지만, 고전이라고 여겨지는 그 분야의 대표적인 책들은 절대적으로 사서봐야 할 것들이다. 될 수 있으면 원서로 볼 것을 권장한다. 혹자는 원서는 보는데 시간이 너무 많이 걸려서 보기 힘들다는 사람들도 있지만, 문제는 우리가 다루는 분야가 Software라는 것이다. 사실상 모든 용어가 영어다. 번역서로 보면 어색한 부분이 많이 있을 수 밖에 없는 분야다. 다른 사람들과 이야기를 나눌때 번역된 용어를 사용하면 오해가 발생할 소지가 있다는 것이다. 영어가 안되는 사람은 최소한 전문용어는 반드시 영어로 기억하기 바란다. 훈민정음이 만들어질때는 컴퓨터가 없었으니, 세종대왕께서도 그 정도는 충분히 이해해 주실 것이다.
02. 쓰기
쓰는 것은 가장 기본적인 의사소통 수단이다. 물론 coding도 의사소통 수단이기는 하다. 예전에 이런 이야기를 들은 적이 있다. "Code에 녹아 있으니 열심히 공부하세요". 솔직히 처음 이 말을 처음 들었을때, 머리통을 갈겨주고 싶었지만 참았었다. Code에 있는 것은 분석과 이해를 위해서 필연적으로 상당한 시간을 요한다. 처음 프로젝트에 투입된 사람이 가장 힘들어하는 부분이 바로 읽어야 할 문서는 없고, source code만 잔뜩있는 상황이다. 아마도 그런 경험이 없는 개발자는 없을 것이다. 쓰기는 많이 써야지 잘 쓴다. 모든 것이 그렇듯 연습을 많이한 사람이 당연히 잘하기 마련이다. 문제는 쓰기를 두려워하는 태도에 달린 것이지, 시간이 부족한 것이 아니라는 점이다. 개발자가 항상 핑게로 이야기하는 것이 바로 글 쓸 시간이 없다는 말이다. 가슴에 손을 엊고 한번 진지하게 고민해보라. 정말 시간이 부족해서 못쓴 것인지 아니면 글쓰기가 두려워서 못쓴 것인지. 개발자는 글쓰기를 두려워해서는 안된다. 글은 항상 써야 하는 일종의 일기와 같은 것이다. 물론 기술에 대한 글은 좀더 체계적으로 익혀야 하겠지만, 그런 것은 다 제외하고 일단은 많이 쓰기부터 해야 한다. 그래야지만 두려움이 사라지게 되는 것이다. 대부분의 개발자는 과제에 대한 설계서와 같은 것을 프로젝트의 마무리와 같이 쓰려는 경향이 있다. 이것은 잘 알겠지만, 일의 순서가 바뀐 것이다. 설계서는 일을 시작하기 전에 작성하는 것이고, 프로젝트의 마무리에서는 그렇게 정리된 문서들을 추려서 보고서를 만드는 것이다. 설계서는 변경될 수 있다. 그리고, 일을 해 나가면서 생겼던 문제점이나 해결방안들은 지속적으로 문서화 되어야 한다. 따라서, 개발자가 쓰는 글은 항상 일과 함께 진행되어 나가야 한다. 지속적으로 수정해야 하며 여러사람과 공유되어야 한다. 오랜 시간동안 인간이 인간다울 수 있었던 것은 말이 아닌 문서로서 만들어진 것들이 있었기 때문이다. 물론 당사자의 말보다 더 값진 것은 없을지라도, 문서는 그 문서를 만든 사람보다 더 오래 살아남는다.
03. 발표
자신이 한 일을 돋보이게 하는 것은 발표를 통해서 이루어진다. 공식적으로 어떤 일의 Milestone이 되는 것도 이러한 발표를 통해서 이루어진다. 발표는 일종의 자기 PR이다. 동일한 일을 했더라도 누가 더 발표를 잘 하는가에 따라 일을 잘했는지 못했는지가 판가름되기도 한다. 설령 누군가가 더 일을 잘한다고 개발자들 사이에 인식이 되어 있더라도, 높으신 분들이 보기에는 발표를 효과적으로 멋지게 하는 사람에게 후한 점수를 주기 마련이다. 발표는 대상을 잘 파악하는데서부터 시작한다. 대상이라함은 참석하는 사람중에 가장 높은 직위를 가진 사람이 누군가에 영향을 많이 받는다. 그 사람이 이해하는 수준으로 발표를 해야하는 것이다. Presentation Skil이라고해서 다양한 방법으로 어떻게 발표하는지를 가르칠 정도이니, 발표가 얼마나 중요한지는 새롭게 강조를 안해도 충분히 잘 이해할 것이다. 여기서 중요한 점은 발표하는 사람들과 발표를 듣는 사람이 경쟁관계가 아니라 협동관계라는 사실을 파악하는 것이다. 관심이 있어서 발표에 참석하고, 무언가 얻어갈 것이나 동의를 구할 것이 있어서 발표를 한다는 것이다. 이러한 협동관계에서의 일방적인 전달은 쓸데없이 힘만 소비하는 효과적인 방법이 아니다. 차라리 편안한 자세로 이야기하는 것이 가장 좋다. 하지만, 실제로 이러한 발표자리를 즐길 수 있는 사람은 그렇게 많지 않으며 항상 긴장하기 마련이다. 자신감이 자신이 가진 가장 큰 무기라면, 남의 공격에 견딜 수 있는 솔직함은 가장 큰 방어 수단이라고 할 수 있다. 어떻게 남을 설득할 것인지를 생각하지 말고, 어떻게 남의 이야기를 더 잘 들을 것인가에 신경쓰기 바란다. 발표시에는 많은 말들이 오갈 수 있다. 어떤 사람은 공격적이기도 하고, 어떤 사람은 나를 대변해서 요약해 주기도 한다. 중요한 것은 그들 모두가 함께 한다는 생각이다. 소중한 자신의 시간을 내서 나의 말을 듣기 위해서 참석했다는 것이다. 따라서, 최소한 발표를 위해서는 자신이 발표하는 내용에 대해서 만큼은 숙지하고 있어야 한다. 모르는 용어를 주저리 주저리 이야기 한다고 해서 좋은 발표는 아니다. 전문적인 용어가 난무한다고 해서 유식해 보이지도 않으며, 제스처를 멋지게 취한다고 누가 촬영해서 동영상을 youtube같은데 올려놓지도 않는다(물론, 아주 근사한 자리에서 멋지게 해야할 필요가 있는 발표는 제외하고.). 학술 발표에서 제품 설명회와 같은 발표를 해서도 안되며, 제품 설명회 자리에서 이론적인 공식들을 토론해서도 안될 것이다. 듣는 사람들이 어떤 것을 알기를 원하는지를 제목으로 정했으면 그것에 충실한 발표를 하기 바란다(간혹 제목과는 전혀 상관없는 발표를 보게되는 경우가 많은데...). 발표는 내가 하지만, 내용은 남들이 가져간다.
04. 대화
Software는 혼자서 개발하는 것이 아니다. 항상 끊임없이 누군가와 대화를 하고, 이를 통해서 원하는 목적을 달성하게 만드는 것이 개발자의 할 일이다. 누군가 개발에서 가장 필요한 것이 무엇이냐고 묻는다면, 난 "대화(Communication)"라고 이야기 할 것이다. 그 만큼 프로젝트를 성공으로 이끄는 가장 큰 부분이 대화이다. 고객과의 대화, 팀장과 팀원의 대화, 마케팅과 개발자간의 대화, 사장과 직원등등 대화는 개발의 전 과정에서 일어나는 일상적인 이야기다. 속담에 "말 한마디로 천냥 빚을 갚는다"고 한다. 실제로 가장 힘들었을때 솔직한 말 한마디는 대부분의 갈등을 해소할 수 있는 지름길이다. 대화에도 역시 기술이 필요하다. 다양한 기술들이 있어서 여기서 말하기는 어렵지만, 단순히 대화의 기술에서 그친다면 말을 잘하는 사람이 되지만, 대화에 진정성이 들어가면 그 사람은 존경의 대상이나 혹은 친구가 될 수 있다. 혼자서 골방에 틀어박혀 열심히 프로그램을 짠다고해서 개발이 끝나는 것이 아니다. 특히나 PL(Project Leader)이 되고자 한다면, 다양한 사람들과 대화할 필요가 있다. 그렇다고 아주 대단한 웅변가가 되라는 말은 아니다. 어떤 목적만을 가지고 이야기하기 보다는 지나가는 말 한마디라도 그 사람에게 항상 관심을 가지고 있다는 표시를 하는 것으로 충분하다. 그러한 관심만큼 상대에게 만족감을 주는 것은 없다고 본다.
05. 도구
사람은 도구를 사용할 수 있는 동물이다(물론 동물중에도 도구룰 사용하는 것들이 많지만^^). Software개발에도 다양한 도구가 사용된다. 자신이 사용하는 도구를 얼마나 잘 사용하냐에 따라 생산성은 극적으로 달라질 수 있다. Software개발에서 필요한 도구들은 편집기(Editor), 통합개발환경(IDE: Visual Studio), source code navigator, SVN(Subversion), Trac(Issue관리), Mantis(Issue관리), Eclipse등등 많은 것들이 있다. 이러한 다양한 것들에 대해서 도구라는 관점에서 manual을 보지 않고도 세세한 기능을 잘 활용할 수 있다면, 그 자체로도 훌륭한 경쟁력이 될 수 있다. 설치 및 운영까지도 할 수 있다면 더 좋겠지만, 그렇게 하지 못할 정도로 비싼 도구들도 많기에 일단은 잘 사용하는데 초점을 맞추는 것이 좋다. 잘 쓸려면 어떻게 해야할까? 쉽게보면 일단 자기가 하는 모든 숙제나 프로젝트에 적용해보는 것이다. 새로운 것에 대한 거부감은 누구가 가지고 있다. 마치 새 신발을 샀들때 생기는 발의 굳은 살처럼 처음에는 사용하는 것이 낯설기만 하다. 하지만, 이것도 적응되기 마련이다. 만약 자신의 목적에 정확히 들어맞는 도구가 없다면 어떻게 할 것인가? 장기적인 관점에서 볼 때는 새롭게 만드는 것이 좋다. 단기적으로는 일단 여러가지 관련된 이미 개발된 도구들을 가지고 조합해서 원하는 결과를 만들어 내는 것이 좋다. 사람은 도구를 써서 손발이 해야할 일을 최소화 하고, 자신이 목적한 것에 더 집중할 수 있기에, 과감히 다양한 것들을 배우도록 노력하자. 최소한 자신있게 사용할 수 있는 도구들을 옆에 항상두고 익숙하게 사용할 수 있어야 진정한 개발자라고 할만하다.
06. 그림
여기서 말하는 그림이란 Software의 구조를 보여주는 것을 말한다. 무턱대고 아무런 그림을 그릴 수 있는 것은 아니다. 그림을 그리기 위해서는 머리속에 있는 생각을 끊임없이 현실 세상에 투영할 수 있도록 사고를 해야 한다. 교과서에서 보는 내용들을 계통도를 그려보는 연습도 좋다. 전체적으로 사물을 이해하는 능력은 언제나 중요하다. 전체적인 이해가 없이 좋은 시스템을 만드는 것은 어려우며, 항상 개발자로서 뭔가 부족하다고 깨닫는 이유도 이러한 전체적인 시각의 부재에서 비롯된다. 그림을 그리기 위해서는 형상화 능력을 갖춰야 한다. 어떤 사물이나 개념을 형상화 시켜서 모델을 만들고, 그 모델의 장단점을 파악하는 것은 구현(Implementation)을 위해서 반드시 필요한 과정이다. 모델링을 하지 않고 구현부터 시작하게 될 경우에는, 나중에 지불해야할 비용이 커지기 때문이다. Software를 건물짓기에 많이들 비교하는데, 건물과 마찬가지로 한번 지어지고나면 고치는데는 상당한 비용이 든다. 모델링에 필요한 툴들은 무엇이 있을까? 아무래도 가장 많이 사용하는 UML(Unified Modeling Language)을 사용하는 것이 가장 일반적일 것이다. 하지만, 표현방법에 너무 집착하지는 말자. 표현방법에 치중하다보면 정작 중요한 내용은 간과하기 쉽기 때문이다. 그림은 분석을 통해서 만들어진다. 기존에 혹은 주어진 문제에 대한 분석없이는 더 좋은 것을 만들어낼 수 없다. 프로젝트는 항상 기존에 주어진 문제에 대한 답을 찾거나, 누군가의 요구를 만족시키는 것이기에. 처음에 그리는 그림은 전체적인 숲을 대상으로 하는 것이 좋다. 지속적인 개선을 통해서 점차 나무의 형태를 갖춰가고, 결국에는 줄기와 나뭇잎 하나하나까지도 세밀하게 신경써서 그리도록 노력하는 것이 설계다. 어느정도의 시간이 흘러서 숲과 나무가 갖춰지면, 이제는 그것을 실제로 가꾸는 것이 남은 할 일이다. 자신이 하는 일을 추상화 시켜서 개념적으로 표현하는 것은 어느분야에서건 필요하며 개발자로서의 기본자질에 녹아들어 있어야 할 것이다.
07. 실무
기업이 사람을 채용할 때 가장 중요하게 보는 것이 바로 어떤 일을 해 봤는가이다. 그 사람의 능력을 짧은 인터뷰시간에 판단하기는 힘들다. 하지만, 그 사람이 무슨일을 해봤으며, 그것을 통해서 어떤 일을 할 수 있을 것인가를 판단하는 것은 그렇게 어렵지 않다. 전공분야에 대한 용어의 이해를 몇단계 질문하다보면 대략적으로 어떤 능력이 좋은가를 판가름 할 수 있다(물론 면접관의 능력에 따라 차이는 나겠지만). 따라서, 가능하면 실무를 많이 해볼 것을 권장한다. 어떤 회사에 소속되어 일하든, 아니면 경진대회 같은것에 참여를 하든 자신의 실무 능력을 키워나가야 한다. 주의할 점은 팀으로 일할때 자신이 맡은 분야는 "팀원들이 일을 잘 할 수 있는 분위기를 만들었어요."와 같이 대답해서는 안된다는 것이다. 차라리 "제가 맡은 분야는 이러이러한 분야이며, 전 어떤 문제를 어떤 식으로 해결했어요"라고 말하는 것이 좋다. 신입사원을 채용하려는 회사는 PL급을 뽑지를 않는다. 실제로 일할 사람을 뽑는다. 손을 더럽힐 사람이 필요한 것이며, 백조의 발이 필요한 것이다. PL급은 실무와 이론을 겸비한 사람을 뽑기에 주로 경력을 가진 사람들이 채용대상이다. 삼성전자와 같은 회사에서 시행하고 있는 Software Membership같은 것도 좋은 기회다. 그런 곳에 가기위해서는 남들이 다하는 것보다는 자신만의 독창성을 가지는 작품을 준비하는 것이 중요하다. 단순히 Micro Mouse와 같이 남들이 많이하는 작품을 만드는 것은 면접관들에게 그렇게 좋은 인상을 주지는 못한다. 면접은 가능성만 보는 것이 아니라 그 사람의 능력도 본다. 문제를 해결하는 능력과 자신의 주장을 논리적으로 이야기하는 사람을 주의깊게 본다. 정확히 듣고 의도를 파악해서 논리적으로 대답하는 것이 중요하다. 공대에 있으면서 어학연수로 외국에 한동안 나가서 말그대로 어학만 배우고 오는 것은 어찌보면 낭비다. 공대생에게 필요한 것은 실무능력이며, 어학은 전공영어에 대한 이해정도면 충분하다. 기술자끼리의 대화에 화려한 수식어구를 사용하지는 않으며, 전공에서 배운 용어들이 난무하기 때문이다. 정확히 용어를 이해하고 이를 실무에 적용한 경험이 있다면 어렵지 않게 외국 기술자들과 대화를 나눌 수 있을 것이다. 실무를 절대 가볍게 생각하지말고, 진지하게 사소한 것일지라도 나뭇가지부터 차근차근 보기 바란다.
08. 이론
대체로 실무를 잘하는 사람일수록 이론에 약하다. 실무를 많이해서 프로그래밍 숙제가 주어지면 잘 만들어서 가져오지만 나중에 구현한 내용에 대해서 이론적으로 설명해 보라고하면 대체로 조용한 사람들이 그런 부류다. 주로 이런 사람들은 3에서 5년이 고비다. 직장에 들어오면 실무를 잘 하기 때문에 여러가지 일을 남들보다 더 많이 맡는 경향이 있다. 그리고, 계속 열심히 자신에게 주어진 일을 해 나간다. 진급도 대체로 빠른 편이다. 능력을 인정받기에 다른 사람들의 평가도 후한 편이다. 하지만, 3년에서 5년이 지나면 회의감이 든다. 다양한 일을 하지만 대체로 반복적인 업무를 하게 되며, 차츰 다른 사람과의 차이도 줄어드는 것을 느끼게 된다. 결국은 자신이 부족한 것이 무엇인지를 깨닫게 되고, 다시 학교로 돌아가게 되는 것이다. 기왕에 학교에 다닌다면 이론적인 깊이를 더하도록 노력하자. 학교 공부랑은 별로 상관없이 자신이 하고자 하는 것만 하면 된다는 생각은 그른 것이다. 그렇게 생각하면 학교보다는 학원에 가는 것이 더 좋다. 배우는 것도 실무 위주의 프로젝트이니 금방 금방 따라가는 것 처럼 보일 것이다. 하지만, 수영에서 기초를 잘 배운 사람이 먼 거리를 갈 수 있듯이, 학교에서 기본을 잘 다진 사람이 오래동안 업계에서 살아남을 수 있다. 극과 극을 달리는 학교 성적표(교양과목과 전공과목에서 보이는 현격한 차이)는 좋지 않다. 항상 꾸준한 사람이 어디서든 빛을 보기 마련이다. 이론은 남들이 이미 실제로 경험한 것들을 잘 정리해놓은 시험공부를 하기위한 노트와도 같다. 물론 스스로가 이론을 정립할 수준이 된다면 더 할 나위가 없겠지만, 최소한 남이 정리해 놓은것이라도 잘 알아야 하지 않을까? 교양과목을 열심히 듣고 학점을 잘 받는 것도 중요하지만, 정말 중요한 전공은 다 놓치고 지나간다면 의미없는 학교 생활이다. 언제든 만회할 수 있을 것처럼 보이던 것들이 어느날 갑자기 절대 따라잡지 못할 벽과 같이 느껴지는 것은 과거의 나태함에 대한 복수이다. 비록 지금 당장은 모든 것을 다 이해하지는 못할지라도, 노력만큼은 언제든 보답을 받기 마련이다.
09. 열정
예전에 누군가가 이런 이야기를 했다. A부터 Z까지 철자마다 1에서 26까지의 숫자를 주고, 합쳐서 100점이되는 단어는 "ATTITUDE"라고. 즉, "마음가짐"만 잘되어 있으면 안될 것이 없다는 것이다. 열정을 가지고 하는 사람에게는 아무도 이길 수 없다. 즐긴다는 것도 그러한 열정이 바탕이 되지 않는다면 불가능한 일이다. 가능성이란 단어도 열정이 없는 사람에게는 사전에서 찾을 수 없는 단어이며, 발전하기 위해서는 그만큼의 노력이 필요하다. 열정을 가지고 하지 않고 단순히 주어지는 것들만을 받아들이다보면, 인생은 기다림의 연속일 뿐이다. 찾아나서지 않는다면 발견할 수 없는 것이 당연하지 않을까? 공대생이라면 집요하리만큼 파고드는 자세가 필요하다. 어떤 주제가 주어졌을때 쉽게 만족하기 보다는 항상 이유를 찾는 것이 기본이다. 열정만을 가져서도 안되겠지만, 열정이 없어서도 안된다. 몸은 움직이는데 마음이 가지 않는다면 그 만큼 힘든 일이 기다릴 것은 자명하다. 강사로 교단에 서있는 사람들의 눈에는 수업을 경청하는 사람과 그렇지 않은 사람은 한눈에 알아볼 수 있다. 관심이 없는 수업에 참여한 학생들을 억지로 끌고다니면서 물을 먹이고 싶어할 양치기는 없다. 그냥 목말라서 죽더라도 목마름의 근거를 알아야하지 않겠는가? 오래전에 한 교수님이 계셨다. 그 교수님은 수업의 첫시간에 들어와서 이런 말을 했다. "여러분 무엇을 알고 싶어하나요?" 거기 모인 학생들은 난감해 하면서 아무런 대답도 못했다. 교수님은 그냥 "그럼, 이만"하고선 수업을 끝내버렸다. 다음시간도 마찬가지로 시작했고, 학생들도 마찬가지로 아무런 대답을 하지 않았다. 당연히 교수님도 수업을 거기서 마치고 그냥 나가버렸다. 결국 무엇을 알고 싶어하는지도 모르는 사람에게는 아무것도 가르칠 것이 없다는 뜻이다. 내가 무엇을 갈증하고 무엇을 하고 싶어하는지도 모른체 학교를 다니고 있는 것은 아닌지 자신에게 질문해보라. 그리고, 이길이 아니라고 생각될때는 다시 왔던 길을 돌아가기를 권한다. 더 많이가면 돌아가는 길도 더 길어진다.
이곳에 적은 이야기는 익히지 않은 내 생각들을 정리해본 것이다. 어쩌면 위에서 나열한 여러가지들은 나 자신에 대한 반성일 수도 있을 것이다. 여기서 나열한 순서는 특정한 의미를 가진것은 아니다. 그냥 머리속에서 맴돌던 것들을 그런 순서대로 꺼냈을 뿐이다. 인간은 자신이 못했던 것을 남들에게 강요하는 나쁜 습성이 있는지는 모르지만, 어쨌든 학교다닐때는 잘 모르고 그냥 지나쳤던 것들을 한번쯤은 정리해두어야 겠다는 생각으로 쓴 것이니 너무 부담을 가지고 읽지 않았으면 한다. 이런 모든 것들을 다 제대로 했다면 아마도 글쓰는 본인도 지금쯤은 다른 사람이 되어있을지도 모를 일이다. 결국 중요한 것은 어린 시절에 듣던 나이드신 분들의 충고가 아닐런지. 같은 software 분야의 개발자로서 선배의 말을 잘 들으면 자다가도 떡이 생길지 모르니 한번 고민해 보기 바란다.
- 비가 조금씩 내리네요... -
출처 - http://blog.naver.com/knix008?Redirect=Log&logNo=40130520539
[출처] [ Software 개발과 관련해서 학생들이 알아야 할 열가지 ]|작성자 닉스