오래된 SW 엔지니어의 평생 공부

다시 공부를 시작하고 나서 부터, 다른 사람들은 어떻게 하는지 살펴 보게 되었다. 몇 가지 "사례"들을 찾았는데, 여기에 정리해 본다. 읽어 보고 공감이 가는 부분에 대해서 고민해 보라는 것이지, 이 것이 옳다고 주장하는 것은 아니다. 나도 공감이 가는 부분이 있고, 이 부분은 아니지 않나 하는 회의가 드는 부분도 있다.

소프트웨어 엔지니어의 역량 수준

회사의 어느 강의를 듣고 알게된 Programmer Competency Matrix[1]이다. 여기에는 Computer Science, Software Engineering, Programming, Experience, Knowledge의 큰 주제별로 나누고, 그 아래 상세 항목을 나누고 있다. 그리고, 상세 항목별로 개발자의 Level의 0에서 3까지 4단계로 설명하고 있다. 이 분야에 대해서 모두 동의 하지는 않지만, 특정 항목별 Level의 차이점이 있고 그 깊이가 다를 수 있다는 부분에 대해서는 공감이 간다. Computer Science 분야는 data structures, algorithms, System Programming으로 나누고 있고 입사 시험에 해당되는 코딩 시험들이 이 부분에 대해서 다루고 있으니 참고할만 하다. 

더 이상 초보 개발자가 아니라는 사실을 언제 알게 되나요? [2]

이 글도 Quora에서 발견한 글을 한글로 번역한 내용이지만, 공감이 가는 짧은 내용들이 있어서 몇가지 인용하고 짧은 생각을 추가해 본다.

"..다른 사람에게 코드 동작 방법을 설명하면서 다른 사람을 이해 시킨다."  이 문장은 여러 공부 방법 중에 통용 되는 것이다. 즉, 자기가 이해한 것을 다른 사람에게 가르치다 보면 더 배운다는 내용이다. "다른 사람의 도움 요청에 올바른 길로 이끌고 있음을 확신한다." 이부분도 유사한 내용이다. 

"필요한 정보를 찾는 장소를 안다." 요즘은 정보가 넘쳐 나서 Googling을 하거나 Stackoverflow를 뒤지거나 API 설명하는 Site를 읽거나 신기술을 소개하는 YouTube등을 보는 것이 일상 다반사가 되었다.  어디서 어떤 키워드로 검색을 해볼지, 키워드를 알게 되면 검색을 하고 책을 좀 더 읽다가 추가로 알게되는 키워드를 더 깊게 파보거나 하는 일은 너무 자연스러운 일이 되었다.

"프로그래밍 언어가 세부사항을 감추더라도 CPU 동작 방식을 이해한다." 이 부분은 내가 Computer Architecture 혹은 C 언어를 배우면서 Linux와 같은 OS의 메모리 운영 방식, 특히 Process/Thread의 개념을 이해하는 부분 또한 Programming Language에서 Stack 및 Heap을 어떻게 활용하는지, Object들이 Attribute와 Method를 어떻게 관리하는지, Garbage Collection은 어떻게 처리하는지 등을 이해하게 되는 부분을 간단히 설명하는 부분이다.

"자료구조아 알고리즘을 직면한 문제 풀기 위해 올바르게 선택할 수 있다." 이 부분도 책에 나와 있다고 그 내용을 액면 그대로 받아 들이기 보다는 "왜"를 생각하여 "어떻게" 활용하는지를 고민하는 것이 중요하다 생각한다. "바퀴를 다시 발명하지 않는다. 이미 알려진 프레임워크를 잘 사용한다." 이 부분도 모든 것을 새롭게 만들기 보다는 존재하는 Open Source를 최대한 잘 활용하고 거꾸로 이 부분의 발전을 Contribution하는 것도 고민하게 된다.

"가독성, 유지보수성, 이식성이 왜 중요한지 이해한다." 이 부분에 대해서는 예전에 대비해서는 성능, 최적화 부분에 대해서 대치되는면도 적지 않다. 하지만, 코드의 유지 보수 및 확장성은 점점 더 중요시 되어 가고 있다. 

"학습과 기량 연마가 끝나지 않는다는 것을 인정한다." 이 부분도 끝이 없다는 점을 더욱 더욱 느끼고, 내가 알고 있던 것이 틀리게 바뀌고 틀리다 생각했던 것이 지금은 맞는 경험을 점점 더 하게 된다.

마흔살 기획자 프로그래머 되다.[3]

이 글은 나보다도 나이가 많은 분이 기획자를 하다가 개발자로 커리어를 바꾼 분의 경험담이다. 글의 중요한 포인트는 2가지라고 이야기 하고 싶다.  첫번째는 "마음가짐"이다. 짧게 말하면, 바로 절실함이다. 자기가 하는 일에 꼭 필요한 것이 프로그래머여서, 결국은 자기가 프로그래머가 되겠다고 생각하고 덤볐다는 것이다. 여기에는 마음을 먹는 것도 중요하지만, 실행하는 것도 매우 중요하다는 생각이 든다.

그리고, 두 번째는 "효과적인 방법"이라고 하고 있는데, 이 부분은 여러가지가 있지만, 우선 몇가지 포인트만 들어서 이야기 하고자 한다.

무엇 보다도 정말 내가 현재로 필요하는 내용을 공부하는 것이라는 중요한 포인트를 지적하고 있다. 다른 사람들이 Java를 한다고, C++을 한다고 해서 그것을 하는 것이 아니고, 게임을 만들기 위해서 그 분야에서 유용한, ActionScript라는 언어를 배웠다는 것이다. 

"... 책을 3번 읽는다... ", 그것도 지하철에서 틈날 때 컴퓨터를 활용하지 않고 말이다. 나는 컴퓨터 언어는 백문이 불여일타라고 생각하는 사람이다. 하지만, 이 부분에 대해서는 일부분 공감이 가는 부분이 있다. 내가 박사 과정일 때, 이와 유사한 방법을 실재로 사용했다. 여러 논문을 읽었지만, 내가 참고해서 활용해야 모델을 도입하는 논문이 있었다. 완전히 수학이어서 전혀 이해가 가지 않았다. Journal 논문이었는데, 나는 3번 읽는 것을 넘어서 결국 필사까지 하였다. 어떤 이는 말한다. 모르면 외워라. 그리고 나면, 이해되는 순간이 온다.

"목표를 가지고 프로그래밍을 한다"라는 부분도 실용적인 접근 방법이고 기본이 쌓인 다음에는 Problem Based Learning이 동작한 것으로 보인다. 나는 이 부분은 앞에서 쌓은 기본 지식이 있기 때문에 가능하다고 생각한다.

"고수의 코드를 들여다 보다"에서는 여러 사람들을 통해서 배우는 것과 같다고 생각한다. 다른 공부 방법에서도 이야기 하지만, 서로 주고 받는 피드백, 좋은 코드 살펴 보는 것들이 매우 좋은 내용들이라 생각한다. 

남규진님의 학습에 실패한 이야기 [4]

이 글은 실패담이라고 되어 있다. 타산지석이라고도 할 수 있겠다. 하지만, 읽다 보면 꼭 실패담이라고 할 내용은 아니다. 우선 접근하는 방법이 Retrospective와 같이 좋았던 공부를 계속하는 것은 유지하되 좋지 않았던 부분들을 개선해 나가는 접근 방법이 좋았다.

우선 고치려고 하는 부분은 "막연한 목표 설정", "편안한 학습법" 이었다. 공부를 하면서 그 결과를 평가할 방법이 없는 접근 방법으로 진행했다고 한다. 단순히 책을 읽기만 하는 접근 방법이었다.

다시 결심하고 접근한 방법은 구체적인 계획과 목표를 세우고 접근하기로 하였다. 그래서, Toy Project를 위해 주제를 정하고, 이를 수행한다. 또한 배운 내용을 회사 업무(객체지향 규칙 적용)에 활용한다. 이전에 작성한 내용을 리팩토링하는 것까지가 새로운 계획이었다. 그리고, 법법도 단순 타이핑이 아니고, 일정 주기로 반복하며, 부숴도 좋은 장난감을 만들고, 다양한 방법을 통해 Feedback,을 받는 것이었다.

그러면서도, 좀 더 구체화가 필요해 보이기는 하지만, "왜" 하는가 하는 근원적인 목표도 찾아가는을 살펴 볼 수가 있었다.

프로그래머의 길, 멘토에게 묻다. 리뷰[5]

소프트웨어 크래프트맨쉽에 관한 책의 리뷰 블로그 글이다. 소프트웨어 크래프트맨쉽은 Agile 개발 방법론에서 한걸음 더 나아가 개발자들이 장인(Craftman)과 같이 길러져야 한다는 개념으로 정리된 것으로 알고 있다. 이미 여러 공감가고 눈이 내용들이 많다. 관련 책도 구매해서 일부 읽고 있어서 이 부분은 나중에 따로 정리하거나 여기에 추가해야 할 내용이다.

임백준님의 개발자의 평생 공부[6]

임백준님은 YouTube 영상도 있고 상당히 유명한 분으로 알고 있다. 최근에 발견한 이분의 잠언 형식의 글들에 공감가는 부분이 있어 후배들에게 공유하기 도 하기도 했었다. 몇가지만 추려 보겠다.

"지금 다니고 있는 회사에서 하는 일을 잘하기 위해서 노력하는 것이 가장 좋은 공부다." 이 부분은 방향성에 관한 것이기도 하다. 내가 하고 싶은 것과 해야 하는 것을 가능하면 일치 시키는 것이 나의 성장에 가장 큰 도움이 된다는 내용으로 나는 이해하고 있다.

"... 스스로 문제를 정의한다음, ... 그 문제를 풀어 보는 것이다..." 이 부분은 공부하는 방법으로 치면 최상 레벨의 접근 법이라고 생각한다. 반드시 해봐야 한다. 대학에서는 이러한 것을 박사 과정이라고 한다.

"겉만 핥는 것은 경박하고, 토끼굴에 빠지는 것은 우매하다. ... 균형을 잡는 ..." 늘 그렇듯이 균형은 중요하고 어렵다.

이 분도 이해 안되는 것은 암기하라고 한다. 그리고, 공부는 함께 해서 Feedback을 받으라고 한다.

김창준님의 사례[7, 8]

김창준님을 만난 것은, 회사에서 진행한 Agile 교육이었다. 교육 내용을 거의 모두 잊었지만, 아직 기억하는 부분은 Agile을 생활에 접목하시는 분이었다. 부부의 대화에서 Retrospective를 적용하는 방법에 대한 것이었다.

이 분의 사례는 상급 레벨에 해당하는 사례이다. 적어도, 컴퓨터 언어는 이제 능숙하게 다루고, 위에서 이야기하는 초보 개발자 수준은 벗어나야 한다. 내가 음악은 잘 모르지만, 잘하는 악기 연주자를 보면, 악보가 있으면 왠만하면 치고, 음악만 듣고도 코드를 따는 것도 힘들지만 할 수는 있는 단계가 아닐까하는 생각이다.

공부의 내용은 알고리즘, Design Pattern, Refactoring, XP에 관련된 내용이다.

알고리즘 공부에 대해서는 스스로 푸는 것에 대한 강조하고 있다. 이 부분은 다른 입장도 있을 수 있다. 수학 개념을 모르는데, 스스로 어떻게 풀 수 있는가? 위에 40대 프로그래머 시작하신 분도 처음에 이렇게 접근하지 못했다. 그래서, 고급 공부 방법이라고 한 것이다. 하지만, 이것도 자신의 경지의 문제일 수 있다. 즉, 고급 단게에서 그 단계를 지나 자신을 넘어 서기 위한 필요한 방법일 수 있다.

Design Pattern의 경우도 "왜"를 많이 강조한다. 결국에는 숨어 있는 가치, 의미를 이해하지 못하고 Design Pattern을 과하게 적용하려고 하는 경우를 지양하기 위한 것으로 이해된다.

Quo Vadis?

[2] 더 이상 초보 개발자가 아니라는 사실을 언제 알게 되나요?, http://jhrogue.blogspot.com/2018/03/b.html

[3] 마흔살 기획자 프로그래머 되다. http://www.ibatstudio.com/%EB%A7%88%ED%9D%94%EC%82%B4-%EA%B8%B0%ED%9A%8D%EC%9E%90-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8-%EB%90%98%EB%8B%A4/

[4] 남규진, 학습에 실패한 이야기 (우아한형제들 기술 블로그), http://woowabros.github.io/experience/2017/12/11/how-to-study.html

[7] 김창준님의 공부하는 법, http://cafe.daum.net/_c21_/bbs_search_read?grpid=LtXl&fldid=AoDe&datanum=6

[8] 김창준, 프로그래밍, 어떻게 공부할 것인가, https://mindscale.kr/course/how-to-learn-prg/lectures

계정이 휴면이 될 정도로 오랫동안 고민만 했다. 어떤 것을 적어야 할지 무엇을 적어야할지 말이다. 다른 사람들이 하는 것 처럼 공부하는 것을 정리하고자 하는 마음에 계정만 열어 놓은 것이다. 하지만, 어떻게 시작해야 할지 망설여 졌던 것이다. 휴일 전날 새벽 2시에 끄적이며 시작한 글이다. 겨우 마음을 다잡고 주절대는 것은 그래도 이게 몇개월이나마 내가 하려고 했던 것들이고 더 나아가 보려하기 때문이다. 이게 20년이라는 아주 오래된 경력 후에 다시 시작한 블로그이기 때문이다.

내가 왔던 길

다른 것을 다 재껴 놓고도, 모든 것을 내려 놓고도 나는 여전히 Software Engineer이고 싶다. 하지만 현실은 그렇지 못하다. 나는 소프트웨어를 개발한다. 전자공 학 전공이어서 학교에서 배운 것은 FORTRAN이었다. 하지만, 독학한 것은 C 언어 그리고 전산(Computer Science)에 대한 관심으로 친구들과 독학하고 수강까지 한 운영체제(Operating System)를 통해서, 소프트웨어 엔지니어의 길로 들어 서게 되었다.

나는 현재 관리자/매니저이다. 회사에서는 파트장 혹은 TL(Technical Leader)라고 불린이다. 40명 가까운 인력들의 개발 내용을 관리하여 제품에 문제 없이 상품화 되게하고, 인력들의 인사적인 부분까지도 관리, 소위 조직 관리도 진행하니 적절한 호칭이다. 하지만, 나의 내면에서는 소프트웨어 엔지니어(Software Engineer)라는 것을 버리지 못하고 있으니, 그것이 여기 정리하려는 공부의 첫 번째 이유이다.

공부하자

다른 회사의 예이지만, Google에서는 Technical Manager라는 직책에서도 여전히 개발 능력을 요구한다. 면접에서도 Coding 시험을 보고 평가하고 있다. 이것은 Manager라고 해서 조직관리 혹은 과제 관리만이 중요한 것이 아닌 실재로 Software 개발 능력 뿐 아니라 팀원의 Software 역량을 이끌어 갈 수 있는 기본적인 소양을 갖추고 있기를 기대하는 것으로 볼 수 있다. 이런 측면에서 나의 경쟁력 강화에도 의미가 있다고 생각된다.

회사에서 실무를 할 때에는 좌충우돌로 익힌 여러 실무들 익힌다. 하지만, 많은 회사들이 그러하지 않을까 싶은데 그 나마 조금 경력이 쌓이면 과제 관리하는 프로젝트 리더 (Project Leader, PL)가 되어 버린다. 나는 그 시점에서 박사 공부한다고 도망나왔다. 이 때, 다시 코딩하게 되면서 얼마나 좋았는지? 회사에 복귀 후에는 개발 업무를 다시 시작하게 되었어도 일정에 쫓기어 공부를 미루고 미루었다. 

많이 돌아왔지만, 이제서야 강의도 듣고 책도 보면서 스스로 공부하게 되는 보수 교육(補修敎育, Continuing Education , Further Education) 이라는 개념으로 공부한 것을 여기에 정리해보고자 한다.

내가 공부하고 여기에 정리해 놓는 것이 다른 이에게도 맞는지 모른다. 하지만, 적어도 나에게 공감이 가는 것들을 공부하면서 정리한 것이니 나에게는 도움이 된다고 생각하고 다른 분들께도 도움이 되길 기대 한다. 주제에 대해서 강의 들으면서, 관련된 책을 정리한 것을 옮겨 놓을 것이라 링크로 확인할수 있는 것들은 링크를 남기고, 나름 내가 정리한 책의 내용과 내가 이해하는 거 새로운 내용들도 정리해 보고자 한다.