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

Python을 처음 들었을 때에는 Linux Shell Script 혹은 Windows에서 Bat 파일과 함께 Perl을 사용해서 업무 자동화를 주로 할 때였다. 이 때의 자동화는 Software 빌드를 자동으로 하는 업무가 주여서 주어진 내용으로 충분했고, Perl의 경우도 필요한 내용만 찾아서 사용하는 정도의 수준이었다. Python도 이와 유사항 언어였고 필요성을 느끼지 모해서 배우지 않았던 것이 사실이다. 

최근에 컴퓨터 언어의 Ranking들을 살펴 보다 보니, 순위가 엄청나게 높아져 있었다. 용처도 많고, 옆의 동료가 온라인 과정을 통해서 배우고 있고 이를 통해서 자신의 업무 자동화에 활용하고 있는 것을 보고 자극이 되어서 사내 온라인 강좌를 통해서 기본적인 내용을 듣게 되었다. 목표도 어렴풋이 사내 웹싸이트에 있는 정보를 모아서 주기적으로 보고하는 것을 주기적으로 해야 하는데, Web Page의 테이블에 있는 내용들을 지속적으로 손으로 정리해서 보고 하게 되면 과제 진행하는 2~3개월 동안 보고 하게 되면 업무 효율이 나지 않았다. 그래서, 반드시 자동화를 해야하기는 했는데 어떻게 해야할지 막막했다.

온라인 강좌로 시작하다.

내가 들었던 강좌는 멀티캠퍼스의 2개의 강좌[1-2] 였다. 첫번째 수강한 강좌는 활용 보다는 전체 내용을 처음 부터 하나씩 설명하는 구조였기 때문에 지루하였다. 하지만, 책을 보고 공부하는 것도 습관이 붙어 있지 않은 상태여서 매일 조금씩 강좌를 보는 것은 꾸준히 진도를 나가는 도움이 되었다. 컴퓨터 언어를 전혀 하지 않았다면 첫번째 구조와 같은 강좌가 도움이 될 것 같고, 이미 다른 언어를 알고 있다면 [2] 강좌가 응용 예가 더 많이 소개 되기 때문에 도움이 될 것이다. 두 개의 강좌에서 살펴 보면, 크게는 다음 항목들을 다루고 있다.

0. 설치, 환경 설정 및 IDE

어느 언어든 기본적인 환경 설정이 필요하다. Python도 다운로드 받아서 설치를 해야 한다. 또한, 개발을 편리하게 해주는 Integrated Development Environment (IDE)가 있다. 모든 강좌에서는 기본적인 Python 설치를 다룬다. [2] 강좌에서는 Python 개발자들이 상당히 많이 사용하는 PyCharm[3] 을 설정하는 법을 설명한다.

1. Basic Language

어떤 언어를 배워도 다루게 되는 기본 자료형(Default Data Type, 연산자(Operator), 변수(Variable), 표준 입출력, 제어문, 함수가 우선 이 부분에 해당되었다. [1]에서는 2~6장이 여기에 해당되고, [2]에서는 2~8장까지가 여기에 해당된다고 볼 수 있다.

3. OOP, Module 과 예외 처리

Python은 OOP를 지원한다. 하지만, 간략화 된 클래스, 상속과 다형성을 포함한다. [1]에서는 7장, 8장이 여기에 속하고 [2[에서는 16장에서 설명한다. 또한, 기능들을 분리하여 관리하기 위해 모듈 기능을 제공한다. 추가적으로 예외 처리 관련 항목도 설명한다.

기본적인 개념을 바탕으로 파일 처리, XML, 네트워크, 데이터 베이스 뿐 아니라 그래픽 관련 모듈 설명도 한다. 특히, Tkinter는 Python이 설치되면 기본적으로 제공되는 기능으로 UI를 쉽게 구성할 수 있다. Python에서는 Regular Expression, 정규식도 많이 사용된다. 2개의 강의 모두 Regular Expression을 다루지만, [2[에서는 2개의 챕터를 할애해서 설명한다.

5. 응용

[2]의 강좌가 좀 더 응용에 집중하고 있다. 엑셀, JSON을 포함한 Open API 활용, Web Scrapping, 날짜 및 자동화 기능, 메일 발송/수신까지 광범위하게 다룬다. 위에서 설명한 특정 웹 페이지에 접속해서 정보를 받아 정리하는 기능이 Web Scrapping으로 볼 수 있는데, 내가 필요로 했던 자동화 기능도 바로 이를 활용하면 가능하였다.

아들에게 가르치기: Python for Kids

일주일에 한번씩 아이들이게 가르치는 기회가 생겼다. 방학에 중학교 1학년인 아들과 아들 친구과 관심을 보였고, 어떻개 진행할까 고민하다가 책[4]을 발견하였다. 원래는 영문판을 먼저 발견했다가 번역을 하려 하다가 번역본이 있다는 것을 알게 되어 이 책을 선정하였다. 강의 계획은 아래와 같았다.

12/09: Python 소개, 기본 설정. Ch1 책소개 Ch2

12/16: 복습, Ch3, 4: Data types & Turtle graphics

12/23: 복습, Ch5, 6 (if/loop)

12/30: 복습, Ch7, 8 (function, class)

01/06: 복습, Ch9, 10 (Built-ins and useful modules)

01/13: 복습, Ch11, 12 (Graphics), Project 논의

01/20: 복습, Ch13, 14 (Bounse Ball), Project 계획

01/27: 복습, Ch15, 16 (Game2)

02/03: 복습, Ch17, 18 (Game2)

한번에 2시간 혹은 2시간 30분 정도 소요 되었다. 중간에 쉬는 시간을 가지면서 했다. 복습을 시키면서 새로운 단원을 나갔고 실습 위주로 진행하였다. 이해하지 못하는 것은 이론 설명을 충분히 하였지만, 책에 포함된 코드를 이용하여 실습에 더 많은 시간을 할해했다. 그래서 인지, 두 아이는 큰 무리 없이 따라 왔었다. 이책이 좋았던 부분은 설명 자체도 실습이 가능한 구조여서 입력하여 결과를 볼 수 있었고, 마지막에 Game을 다루기 때문에 흥미를 이끌어 내기 쉬웠다.

추가적인 부분으로, PyCharm을 처음 부터 설치하게 해서 인터프리터 기능 보다는 코딩 개념으로 설명하였다. 강의, 실습도 2명이 하기 때문에 더 진도가 잘 나갔던 것 같다. 원래 계획으로는 위의 강습 후에 Project 같은 것을 할 계획이었지만, 시간 부족으로 진행하지는 못했다. 나중에 또 기회가 있다면, 프로젝트를 하면서 여러 명이 함께 기획하고 구현하고 발표하는 시간도 3주 정도 가져보면 더 발전이 있을 것으로 예상한다. 그렇다면, 총 12주 정도의 시간이 필요했다.

업무 자동화에 활용: Web Scrapping

Python은 C++/Java와는 다르게 인터프리터를 사용하는 언어이다. 내가 가장 먼저 사용해본 인터프리터 언어는 Basic이었다. 그 당시는 마치 지금의 Windows 명령어 프람프트(Cmd.exe) 와 유사한 인터페이스였다. 다른 것은 컴퓨터를 켜면 항상 그 화면이 떴고, 수행할 내용을 입력하고 얻는 방식, 즉 인터프리터 방식이 기본이었다. 옛날 방식의 기술이 항상 나쁜 것은 아니고 상황에 따른 선택이라는 생각이 든다. 즉, 이렇게 하게 되면 컴퓨터의 동작 방법을 몇가지는 알지 않더라도 컴퓨터 언어에 접근하게 해주는 것이 장점이 되고, 그래서 Python을 비전공자에게 권하게 된다고 생각된다. 고급 사용자의 경우는, 실행할 내용을 text파일로 저장해 놓는 Script도 사용할 수 있으니 이 또한 유연한 접근 방법이다. Android에서는 2.x를 사용하지만, 나는 우선 자동화와 추후를 위해서 3.x대를 선택하여 사용하였다.

위에서 설명하였듯이 Web 페이지에 접속해서 필요한 내용을 추출해 해는 것이라고 간단히 말할 수 있겠다. 내가 필요했던 업무도 사내 홈페이지들에 흩어 져 있는 우리 부서의 정보를 원하는 형태로 취합 정리하는 것이었다. 인트라넷 홈페이지는 로그인 처리가 필요했고 개별 링크에 관련 정보들이 흩어져 있었고, Java Script를 이용한 Dynamic Web이었다. 강좌에서 소개한 Library는 Beautiful Soup이였다. 이 라이브러리는 디테일한 컨트롤이 어려웠고, 사내 홈페이지에 접속하는 것이 매우 어려웠다. 결국 Googling을 많이 하다 보니, Selenium이라는 모듈을 알게 되었고, [5]에 포함된 내용과 Googling을 통해서 원하는 기능을 구현할 수 있었다.

돌아 보며.

새셈 느낀 것이지만 필요한 목적이 있으면 배움이 더 유용하다. 그래서, 업무와 연계 시키거나 혹은 다른 목적을 찾으면 좋다. 특히, 가르치는 것은 더 많은 배움을 동반한다. 현재는 이러한 목적을 넘어선 다른 것 또한 찾고 있다. 그것이 더 좋은 공부라는 것을 알기 때문이다.

[1] 파이썬으로 배우는 실전 프로그래밍, http://www.credu.com/main/credu/user/course/zu_course_detail_R.jsp?p_subj=C90113

[2] 파이썬을 이용한 자동화 스크립트, http://www.credu.com/main/credu/user/course/zu_course_detail_R.jsp?p_subj=CB6392

[3] JetBrains PyCharm, https://www.jetbrains.com/pycharm/

[4] 제이슨 R. 브리그스 et. al, "누구나 쉽게 배우는 파이썬 프로그래밍 (Python for Kids)", BJPUBLIC. 2013

[5] Ryan Mitchel, "Web Scrapping with Python", O'Reilly 2015

업무를 하다 보면, 시키는 일만 하다가 문제를 해결하는 단계를 거쳐 문제를 만드는 단계를 거쳐 올라가게 되는 것을 경험하게 된다. 나는 이게 리더가 되어 가는 과정이라고 생각한다. 내 경험으로 비추어 보면, 소프트웨어 개발하는 사람들의 중요하게 생각하는 경력 방향이 조금씩 바뀐 것 같다. 어느 것이 더 중요하고 덜 중요하다고 생각하지는 않는다. 하지만, 방향성을 가지고 가는 것이 필요한 역량을 준비하는데 효율적이지 않을까 하는 생각한다.

개발자의 경력 방향

내가 생각하는 경력의 방향은 3가지 이다.

내 경력의 초창기에는 과제의 대한 넓은 이해를 바탕으로 제품 출시에 대해서 Risk가 되는 항목을 관리하는 것이 주요 목표인 Project Leader가 중요했다. 이런 부분에 대해서는 PMPBOK[1]과 같이 일반적인 프로젝트 관리(Project Management) 혹은 SW만을 위한 RUP(Rational Unified Process)와 같은 방법론을 중요하게 여기었다. 지금도 큰 회사들은 범위가 큰 제품을 다루기 때문에 이러한 프로세스를 도입하거나 혹은 자체 운영 프로세스를 운용하고 있다. 여러한 운영하는 역할을 가진 Leader들은 여전히 중요한 역할을 하고 있다.

또한, Agile Software가 소개 되면서, 목표 중심의 접근 방법에서 사람 중심, 소통 중심의 작고 기민한 개발 방법으로의 변화가 이루어지고 있다. RUP에서도 이러한 Agile한 접근 방법은 XP(eXtream Programming), Scrum, Kanban등 다양한 Practice들이 소개 되었고, 계속해서 표면적인 Practice만이 아닌 가치와 원칙들을 기반으로 시도되고 있다.

소프트웨어 개발자도 결국은 제품을 만드는 사람이고, 이 제품은 요구 사항을 구현하여 상품화 하는 것이다. 제품의 요구 사항은 당장 스마트폰만 보더라도 어플리케이션, 미들웨어, 시스템 소프트웨어와 같은 큰 분류가 있고, 좀 더 세밀하게 들어가면 해당 분야가 필요로 하는 지식이 전혀 다르다.

단적인 예로 Video 어플리케이션만 하더라도 비디오를 재생하는 부분, 그리고 압축되어 있는 비디오를 사용자가 볼 수 있도록 압축을 풀어 주는 부분,그리고 이 압축 풀린 비디오를 화면에 뿌려 주는 부분 그리고 이 동작을 통합하여 사용자와 연동하는 부분으로 세세하게 나눌 수 있다. 이러한 기술 분야(Technology Domain)가 엄밀히 말하면 모두 다르다고 할 수 있다. 비디오 압축을 풀어주는 Video CODEC 그리고 압축 풀린 화면을 그려주는 Graphic 부부분으로 Domain이 다르다고 할 수 있다. 이러한 분야별로 전문가인 Domain Expert들이 필요하게 되었고 이러한 인력들이 Technical Leader들이 떠오르기 시작했다.

요즘 소프트웨어 회사에서 인력 채용을 할 때에는 코딩 면접을 본다. 예전의 기술 면접과는 차이가 있다. 관련 분야의 Knowledge를 측정 하기 보다는 자료구조 및 컴퓨터 알고리즘에 대한 기본적인 이해, 그리고 실재로 프로그래밍을 할 수 있는 소양, 센스를 확인하는 듯한 느낌이 강하다. 즉, 회사에서 바라는 Software 개발자의 인재상이 바뀌고 있다는 생각이 든다. 이러한 개발 역량은 과제를 운영하거나 특정 분야의 지식으로 만으로는 부족하다고 보고, 실재로 작동하고 복잡한 소프트웨어를 설계하고 구현할 수 있는 인력들을 원하며, 이러한 소프트웨어 개발 역량을 가진 사람들을 Software Architect라고 부르고 있다. 

후배들에게 하는 조언

나는 위에서 이야기 한 Project Leader, Domain Expert 그리고 Software Architect를 개발자의 Career Path로 보고 후배들에게 조언을 하고는 한다.

사람들과 Interaction을 좋아하면서, 제품을 만들어 가는 관점에서 소프트웨어 개발에 관심이 높은 사람들에게는 Project Leader와 관련 내용을 소개하곤 한다. 특히, Agile Software Development에 대해서 많이 설명한다. 나는 XP의 Pair Programming이나 TDD 등에 대해서 관심을 가지고 있었었고, 지금은 Kanban을 일부 적용하면서 사람들과 소통에 대해서 관심을 가지고 있다. 이러한 부분을 소개하면서, 반응을 살피고, 관련 내용, 교육을 소개한다. 자격증도 있어서, 관심있으면 획득하는 것도 좋다고는 이야기 하지만, 꼭 필요한 것은 아니라는 내 생각도 이야기 해준다.

대학원 석사/박사를 희망하는 사람도 종종 있다. 요즘 유행하는 Machine Learning과 같은 학문적인 관심을 가지고 있는 사람들이다. 석사/박사를 하게 되면 무엇이 다른가에 대한 질문이기도 하다. 나는 학사는 내 전공이 어떤 분야인지 이해하는 과정이고, 석사는 해당 분야의 주어진 문제를 푸는 방법을 배우는 과정이라 설명한다. 박사는 한마디로 인류 지식의 지평을 넓히는 사람이라고이야기 한다. 즉, 특정 분야의 "의미있는 문제"를 찾아 다른 사람이 해보지 않은 "새로운 방법(Novel Way)"으로 해결하는 것이라고 설명한다. 이 방향이 Domain Expert가 되어 가는 과정이다. 

Software 개발 역량은(SW Development Competency)는 개발자로의 기본 능력이라고 생각한다. 그래서, 아직은 많은 고민을 하지 못한 후배들에게는 이 부분을 설명한다. 컴퓨터 언어, 알고리즘, 그리고는 설계 관련 이야기를 한다.  이와 같이 이야기 하는 이유는 두 가지 정도이다.

하나는 이 부분이 Software 개발자로서의 경쟁력이기 때문이다. 이야기 한데로, 여러 회사들이 인력 선발할 때 살피는 기본적인 부분이다. 신입이든 경력이든 개발자로 살아 남으려면 기본적으로 이부분이 준비 되어 있어야 한다.

또 하나는 생산성이 다르기 때문이다. 실재 업무는 새로운 기능을 구현을 하거나 기존 코드 (Legacy Code)의 이슈를 수정하는 것이 시작이다. 이 때, Software 개발 능력은 매일 사용해야 한다. 그렇기 때문에, 이 능력의 높고 낮음에 따라 생산성에서 큰 차이가 발생한다.

그래서 나는?

위의 어느 것을 선택하여 나아가던 선택의 문제이지 어느 것이 더 낮다고 이야기 하지는 않는다. 개인 선호도의 문제이기도 하다. 물론, 무시하기 어려운 것은 인력 시장의 선호도 혹은 관련 분야의 전망 또한 선택하는 사람 입장에서는 고려해야 할 부분일 수도 있다. 

하지만, 정말 훌륭한 Technical Leader로 가는 길은 여러 갈래길 나뉘어 져 있지만, 어느 순간에는 만나고 어느 순간에는 갈라진다고 생각한다. 위에서 이야기 한 3가지 방향 중 어떠한 것을 가더라도 서로를 완전히 때어 놓을 수 없고, 다시 만난다. 소프트웨어 제품을 만들다 보면, 사람들과 소통하고 Risk를 관리하는 방법을 배우게 된다. 특정 제품의 해당 기능을 구현하다 보면, 관련 Domain Knowledge가 쌓인다. 실재 개발을 하다 보면, 관련 컴퓨터 언어, 알고리즘 그리고 설계를 배우게 된다. 즉, 업무를 통해서 학습하게 된다. 

중요한 것은, 이런 부분을 자세히 살피지 않으면 알지 못할 수도 있다. 자신이 있는 단계에서 한단계 더 넘어 서려면 더더욱 그러하다. 그래서, 깨어 있어야 하고 공부해야 한다고 생각한다.

지금의 나는 다행이도 여러 가지 경험을 하고 있고, 오늘도 배우면서 좀 더 성장한 내가 되기 위해 고민하고 있다. 그래야, 후배들에게도 그들이 고민하는 부분에 대해서 나의 생각을 이야기 해주고, 그들이 선택하여 나아갈 수 있도록 해줄 수 있다고 믿고 있다.

[1] PMBOK Guide and Standard, https://www.pmi.org/pmbok-guide-standards

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

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

회사의 어느 강의를 듣고 알게된 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