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

UML의  유용한 Diagram들

전통적인 Software Engineering입장에서 Software를 구현하는 절차는 사용자의 요구 사항을 분석 요구 사항을 분석(Analysis)하고 이를 설계 (Design)를하고 구현(Implementation)을 한다. 요즘은 대부분 객체 지향을 기반으로 Software를 구현하므로, 이를 객체 지양 분석 설계(Object Oriented Analysis and Design)라고 한다. 절차(Process)상으로는 여러가지 방법이 분분하게 많지만, Software의 구조의 설계를 위한 도구로서 UML을 많이 사용하고, 이 중에서 특히 Class Diagram과 Interaction Diagram으로는 Sequence Diagram을 활용하여 설계를 하는데 사용한다. State Diagram도 제공되는 경우도 있다.

Open Source로 제공되는 많은 Software 혹은 Module들도 복잡한 경우에는 Class Diagram을 제공하기도 한다.  Android의 Multimedia Framework에 해당하는 Stagefright의 경우도, Googling해 보면 사람들이 작성해 놓은 Class Diagram[1]이 있다. Sequence Chart는 찾기 어렵다. Android Multimedia Framework와 관련된 State Diagram은 초기 부터 제공이 되었다. 이는 Media Player라 불리는 Application Interface를 이해를 돕기 위해서 지속적으로 제공 되고 있다 [2].

실무로 업무를 하게 되면 요구 사항을 바탕으로 개발을 하는 경우도 있지만, 기존 코드(Legacy Code)를 유지 보수 하거나 확장하는 작업을 하는 경우도 많다. 이렇게 되면, 자료가 잘 제공되는 경우도 있지만, 없는 경우도 많다. 내가 생각하기에 가장 기본적인 자료는 Class Diagram이다. 이는 Software의 기존 구조를 파악할 수 있는 조감도에 해당한다. 하지만, 동작의 상세를 제공하지는 못한다. State Diagram 혹은 Sequence Diagram이 있다면 동작에 관해서도 빠르게 이해할 수 있다. 이 자료들이 없다면, Class Diagram은 만들고 Sequence Diagram도 기본적인 정상 동작에 대해서 작성한다면, 빠른 이해에 도움이 된다.

여기서는 Class Diagram 에 대해서 여러 책에 있는 좋은 내용들을 정리해 보기로 하자. 우선은 Object Oriented Paradigm에 대해서는 이해를 한다고 생각한다. 적어도, Java 언어에 대해서는 공부하였다면, 어느 정도 이해할 수 있는 수준이라고 생각한다.

Object, Class 그리고 Syntax

UML@Classroom[3]에서는 내용이 쉽게 설명되어 있으며, Class의 Attribute와 Operation의 Syntax에 대해서 아주 자세히 그리고 도식화가 잘 되어 있다. Chapter 4가 Class Diagram을 다루고 있는데, 다음은 그 요약 내용이다. 

아래 그림은 Object와 Class를 이용한 표기 방법의 예이다. 아래 가장 왼쪽은  :Person은 Class를 Instantiate하면 maxMiller가 된 것을 보여준다. 위의 상자에서는 maxMiller라는 Instance만 보여 주고, 내부 상세 Attribute는 숨기고 있다. 아래 그림의 가운데는 왼쪽 그림에서 Class 종류까지 기술하여 표현하고 있다. 가장 오른쪽은 무명(anonymous) 객체로 Instance의 이름은 없으 Class가 생성된 것을 표현하고 있다.

우리가 잘 알고 있는 Java 언어와 UML의 Class를 표현하는 방식을 병행해서 비교하면 아래와 같다. Course가 Class의 이름이 되고, name, semester, hours가 Attribute그리고, getCredits(), getLecturer(), getGPA()가 operation이 되는 것이다.

아래 그램에서 볼 수 있듯이, 3가지 방식으로 Class를 표현할 수 있다. (a)는 가장 단순히 표현하는 방식이다. 하지만, attribute와 operation의 상세 내용은 알 수 없다. 좀 더 정보를 포함한 것이 (b)이다. attribute와 operation의 내용을 볼 수 있지만, 각 속성들은 보여 지지 않는다. (c)가 가장 상세한 기술 방법이다. Java와 같은 언어로 Class의 뼈대(Skeleton)은 구현할 수 있다. Star UML[4]과 같은 UML Tool들은 이러한 Skeleton Code를 자동으로 생성해 주는 기능도 제공한다.

Attribute의 상세 Syntax는 아래와 같다. Visibility는 아래 테이블까지 추가해 두었으니 참고 하면 된다. Multiplicity는 Array를 표시하는 것으로 [min..max]형식으로 표시한다. 상위 제약이 없는 경우, *를 사용한다. [*]의 경우는 [0..*]와 같은 의미이다. 

Property의 경우는 {readOnly, unique, non-unique, ordered, unordered}가 가능하다. 이 특징들을 조합하면 Attribute의 속성을 조정할 수 있다. 이를 표로 나타내면, 아래와 같다. 예를 들자면, Set의 경우는 일반적으로 정렬이 되지 않은 중복되지 않은 숫자의 모임이다. 

Opeattion에 대한 기술 방법은 아래와 같이 요약될 수 있다.

Class 간의 Relationship

이 부분은 Class를 연결 시키는 선들로 기술된다. 이 부분은 Learning UML[5]에서 아주 요약하고 있는 그림이 있다. Local Value 혹은 Parameter로 사용되는 경우는 Dependency 혹은 Association으로 표현이 된다. Aggregation과 Composition은 시나리오에 따라 달라지기는 하지만, 모두 Member로 활용되는 경우이다. Inheritance는 상속으로 구현된다. 좀더 명확한 구분을 하고자 한다면, 책을 더 보도록 한다.

Class Diagram Syntax를 포함한 Diagram 예

Applying UML and Pattern[6]에는 위에서 설명한 Syntax와 Relationship를 예로서 잘 표현하는 그림을 포함하고 있다. 이 그림을 이해한다면, 위에서 정리한 내용도 모두 이해한다고 볼 수 있다. 이 그림을 손으로 그려보거나, UML 툴을 이용해서 그려 보는 것도 Class Diagram의 Syntax와 Relationship 표기 방법을 이해하는데 도움이 된다. 여기서는 <<interface>>를 표시하여 함수만을 Abstract하는 Interface도 표시하고 있다는 것을 참고하자.

Reference

[1] Stagefright player and its class diagram: http://infectiousansh.blogspot.com/2010/09/stagefright-player-and-its-class.html

[2] Developers Documentation Media Player: https://developer.android.com/reference/android/media/MediaPlayer

[3] UML@Classroon: An Introduction to Oject-Oriented Modeling 2015 Springer

[4] Star UML: http://staruml.io/

[5] Kim Hamilton and Russel Miles, Learning UML 2.0, O'Reaily Apr. 2006

[6] Craig Larman, Applying UML and Patterns 3rd Ed, Addison Wesley Perofessional Oct, 2004

Python을 배우면서 2.x대와 3.x의 버전이 있다는 것을 들었고 더 이상 .2.x대의 업그레이드는 없다고하여 많은 고민 없이 3.x대를 쓰기 시작했다. 하지만, 실재로는 여러 이슈가 있다. Android는 여전히 2.x대를 쓰고 있다. 그래서 상황에 따라서는, 2.x 과 3.x를 병행해서 쓰게 한다거나 개발 환경을 Windows와 Linux로 나누어 PC를 2대로 운용한다던지 해야 하는 상황이 있다. 그럼에도 지금까지는 2.x는 그래도 강건너 불구경이었다.

도움 요청

네트워크 성능 최적화가 주요 업무인 후배는 network에서 실재로 전송하고 받는 packet을 캡춰해 놓은 pcacp 데이터를 많이 분석한다. 관련해서 이야기도 많이 하고 나에게 조언을 구하기도 한다. 한번은 python 이야기를 하길레 내 경험을 이야기 하고 python 강습을 듣도록 권유했다. 그래서, 나름 작업을 시작했던 것 같다. 관련된 조언을 몇번씩 구해서 같이 고민하고 간단히 답을 구하기도 하고 혹은 못 도와주기도 했다. 하지만, 이번에는 좀 더 심각해 보였다. 우리 집까지 찾아 오겠다는 것이었다.

내용은 python의 pcap 분석 툴인 captcp[1]의 포팅을 도와 달라는 것이었다. 이 툴은 dpkt[2] 모듈을 이용해서 TCP/IP 패킷을 분석하는 툴이었다. 예전에 몇번 질문한 것도 결국은 이 것과 관련 된 것이었다. 추가적인 문제점은 운용 환경이 Windows였다는 것에서 시작해서, 결국은 Python 3로 포팅해야 한다는 것이었다.

간단한 변환

새롭게 알게 된 것은 python 2 스크립트를 3로 변환하는 툴이 있었다. 기본적으로 python 3를 설치하면 [python 3]\Tools\scripts에 설치 되어 있는 툴이다. 이를 이용하여 기본 변환을 하면 된다.

아래와 간단히 명령어를 입력하면 변환이 일어난다.

미궁을 해매기

위와 같이 변환해도 Logical하게 문제가 발생하는 부분을 모두 처리해주지 못하기 때문에 바로 동작하지는 않는다. 결국에는 이 코드를 가지고 작동 시켜보면서 디버깅을 해야 하는 상황이었다. 이미 여러 이슈를 해결했지만, 최종 결과에는 이슈가 있었다. 테스트로 사용했던 동작은 statistic 옵션 이었다.

하지만, 지속적으로 error가 발생하면서 이슈를 파악하기 어려웠다 이 부분을 같이 살펴 보면서 Logical한 이슈가 무엇인지 분석을 하였다. 

결과 부터 이야기 하면, python 3로 오면서 Object의 연산자 overloading에 대한 구현 부분이 바뀐 것이다. Object의 비교 연산자가 Override 구현이 정확하게 동작하지 않고 단순 주소 비교로 되면서 처리가 완료되지 못하고 오류가 발생하는 건이었다.

근본 원인이 밝혀 지니 수정 방향도 수립이 되었다. __cmp__가 적절하지 못하는 것이 예상되었고, googling해 보니 이미 관련된 설명[3]이 있다. 이를 기반으로 __eq__로 대체 구현하였더니 동작함을 확인할 수 있었다.

돌아보며

결국은 Python2의 결과물을 Python 3로 변환하는 것은 쉬운일이 아니다. 또한, Open Source의 특성 상 지원이 있을 수도 있고 없을 수도 있기 때문이다. 하지만 또 하나의 장점은 내가 직접 변환할 수도 있다는 것이다.

최종 결과물은 내 github repsitory[4]에 저장되어 있다. 원본 Project가 2016년 부터 멈추어 있고, python 3과 연계가 어떻게 될지 불분명해 보인다. 그래서, 원본으로 pull request를 보내지는 않을 예정이다. 대신, 내 repository에 유지해 보는 것이 여러 방향으로 괜찮지 않을까 하여 유지해 보려 한다.

사족이지만 방금 찾은 것인데, python 2.7은 2020년에 퇴역(EOL)한다[5].

[1] captcp, https://github.com/hgn/captcp

[2] dpkt, https://github.com/kbandla/dpkt

[3] cmp method in python 3, https://stackoverflow.com/questions/8276983/why-cant-i-use-the-method-cmp-in-python-3-as-for-python-2

[4] captcp for python 3, https://github.com/blcktgr73/captcp

[5] Python 2.7 will retire in..., https://pythonclock.org/

나의 기억 속의 Java

Java는 C/C++만 알고 있던 나에게는 새로운 언어라고 보다는 개념을 도입하는 언어였다. 이는 Java의 언어 형태가 C/C++과 매우 흡사하기 때문이다. 코드 일부만 보면, 어떤 언어인지 판단하기가 쉽지 않을 수도 있다. 처음 배울 때가 Java가 Public하게 처음 소개 될 때였다. 그 당시에는 Sun Microsystem에서 릴리즈 하였다. 대학원 당시 랩에서 Sun Spark 워크스테이션을 처음 접해 본 터라 컴퓨터를 만드는 회사에서 도입한 컴퓨터 언어라는 것이 신기하고 Object-Oriented 개념으로 만든 언어라는 것이 신기했다.

그리고는 , Java 1.2가 Java 2로 소개 되고, J2SE, J2ME와 같이 Profile을 가지고 소개되었다. 단말을 하였었기 때문에, 옆 부서에서 J2ME의 여러 모듈들을 포팅하는 것을 기억하고 있다. 이 당시는 J2ME라도 상당히 무겁고 응용도 많지 않은 상태여서 Mobile에는 적용이 어렵다는 생각을 많이 하였고, 심지어는 모바일에는 Java는 절대로 보편화 되지 못할 것이라는 나름대로의 판단이 있었ㄴ다.

다시 안드로이드를 시작하면서, Java로 어플리케이션을 작성하는 부분에 대해서 놀랐다. 그리고, 이야기 듣던 JNI로 C++단이나 커널과 연결되어 Platform을 구성하는 것에 대해서 많은 놀라울 수 밖에 없었다. 그리고도, 시간이 흘러 보니 내가 알고 있던 Java와는 많은 차이가 있었고 처음 부터 다시 다져봐야 할 이유가 충분하였다.

또 다시 시작.

Android를 하기 때문에, Java를 다시 봐야 하는 것은 자연 스러웠다. Python도 강좌를 통해서 익힌 터라 강좌를 찾았다[1]. 2가지 과정으로 되어 있었지만 첫번째 강좌만 들었다. 이후는 응용인데, Android에는 큰 도움이 되어 보이지 않아서였다. 전반적으로 IDE로 Eclipse를 쓰고 있어서 툴을 배우는데는 유용했다. 다른 언어와 유사한 데이터 타입, 연산자, 입출력, 루프 그리고 함수까지는 평이했고 C++을 했기 때무에 객체 지향관련 Class와 다형성까지 크게 문제가 없었다. Interface와 C++과 다른 부분들은도 예전과 크게 다르지 않았다고 느껴서 어렵지않았다. 하지만, 이 것을 마무리 하고나서는 많이 부족한 생각이 들었다.

책으로 보는 Java

결국은 책을 찾게 되었고, C++ 책의 같은 저자가 만든 책이 있는 것을 알고 그 책을 찾아 보았다. 이책은 Java 8기반으로 작성되어 있어서 Android를 기반으로 하고 있는 나도 더 도움이 되겠다 싶어 보게 되었다. 다 보고 난 후 총평은 새로운 개념들을 설명하면서는 정리가 좀 덜 된 듯 한 느낌을 들기는 하였다. 요리를 해야 하는 재로는 다 들어갔는데 잘 어울어지지 않는다는 느낌이었다. 물론, 내가 개념들을 깊이 이해하지 못해서이기도 하지만, 설명을 잘 하는 책이라면 충분히 그 느낌을 덜어주지는 않았을까 한다.

나의 관점에서 새로운 개념들은 Chapter 21부터 설명되는 Generic그리고 이를 활용한 Collection Framework였다. 이 후, Lambda와 Method 참조, 그리고 스트림까지이다. 특히, Android에서도 적용되는 Java 8의 신규 기능이라 할 수 있는 것은 Lambda와 Stream이다. 새로운 Android 코드들에는 이를 활용한 코드가 적용[3]되고 있으니, 반복해서 확인하고 몸에 익혀야 할 내용들이다.

Android와 Java

그럼, Java는 없어질 언어인가요?

[1] Java 배우기 Part 1(기본), http://www.credu.com/main/credu/user/course/zu_course_detail_R.jsp?p_subj=C69401

[2] 윤성우, "윤성우의 열헐 Java 프로그래밍", 2017년 7월

[3] Android Java 8 Support, https://developer.android.com/studio/write/java8-support

[4] 8년 전장 오크랄 웃고, 구글 울었다. http://www.zdnet.co.kr/news/news_view.asp?artice_id=20180328141031

[5] Android version history, https://en.wikipedia.org/wiki/Android_version_history

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

우선 C++에 대해서 보수 학습을 고민하게 된 것은 처음에도 이야기 했던데로 내가 C를 학습했었고 Object Oriented Paradigm/Programming(OOP)을 접하게 되면서 C++이 C를 기반으로 OOP를 접목한 언어로 소개 받았기 때문이다. 1998년 경으로 기억한다. 이 당시에는 어렴풋한 기억이지만 이 Template 개념이 없었다. 이후 Template이 적용된 C++ 코드를 보았었고, 이 후에 C++에서도 여러 버전이 만들어 지고 있다는 사실을 알게 되었다.

마지막으로 C++에 대한 보수 교육을 하기로 마음 먹게 된 이유는 내 업무에 이 부분이 아직도 많이 활용되기 때문이다. 내 업무는 Android 어플리케이션에서 동영상과 음악 파일을 재생하게 하는 Multimedia Framework이다. Android의 경우, Application이 Java로 이루어 있다. 하지만, Linux Kernel위에 여러 Service와 Framework를 이루는 기본적인 언어는 C++이다. 이 부분이 예전 부터 사용되어 오고 있는 Open Source 레거시 코드(Legacy Code)들이 있기 때문이기도 하다. 또 다른 이유는 하드웨어 (Hardware, HW)와 연동하는 코드들의 경우, 성능을 이유로 C/C++로 작성되는 경우가 많다.

이와 같은 이유로 C++에 대해서 공부하기로 했고, 우선 학습 방법은 기존 부터 가지고 있던 윤성우 저자의 "열혈 C++ 프로그래밍 개정판"이었다. 이 책은 내가 보기에는 C++03 기준으로 설명하고 있는 것으로 보여진다. 책의 서문이나 내용 중에서 이에 대해서 명확하게 하고 있지는 않다. 발행일이 2011년도인 것으로 보아도 C++11의 내용을 담기에는 어려움이 있어 보인다. 그렇더라도, 아직 내가 보는 코드들에서 C++11까지 이해해야 할 정도가 아니기 때문에 이책으로도 충분히 필요한 내용은 포함된다고 생각했다. 이 부분도 일독을 마친 후에 나중에 알고 되고 추가 공부할 내용을 알게 된 점에 대해서도 분명히 한다.

학습 내용

책을 일독하고, 2번 정도 Sample Code를 살펴 보면서 알게 된 것은 사람들이 많이 이야기 하고 있는 Standard Template Library(STL)과 Lambda등에 대한 내용은 책에서 다루고 있지 않다는 부분이었다. 그래서, 인터넷등을 통해 알게 된 다른 자료까지 학습한 내용을 포함하여 정리해 보면 다음과 같다.

1. Procedural Programming Paradigm 

이 부분은 컴퓨터 언어의 개요서를 보게 되면 일반적으로 가장 먼저 다루게 되는 부분이다. 하지만, 이 책[1]에서는 C를 안다는 가정으로 시작한다. 나는 오랫 동안 사용한 언어가 C여서 크게 문제 될 부분은 없었다. 혹시라도 C를 잘 모르는 거나, 컴퓨터 언어를 처음 배우는 사람은 다른 C++책을 보는 것이 좋겠다. 

2. Objected Oriented Paradigm/Programming (OOP)

이 책에서는 Encapsulation에서 시작하여 OOP를 설명하면서, 상속(Inheritance), 다형성(Polymorphism)까지 설명하고 있다. C++이 다른 객체 지향 언어와 다르게 혼동을 주고 있는 virtual keyword에 대해서도 Chapter를 하나 할해하여 설명하고 있다. Chapter 11까지의 내용이 여기에 포함된다.

3. Template

구지 분리할 필요는 없지만, OOP와 Template를 분리하는 것은 내가 이 부분에 대한 이해가 낮기 때문이다. 책에서는 2개의 Chapter를 할당하여 개념 설명, Class Template, Class Template Specialization, Template Parameter (템플릿 인자)등을 설명하고 있다. Chapter 13, 14 이다.

4. Standard Template Library (STL)

책에서는 이 부분을 설명하지 않고 있다. 하지만, 알고리즘 등을 설명하는 등의 여러 웹싸이트 등에서 설명할 때, STL을 가정하고 코딩을 하는 경우가 종종 있기 때문에 이 부분에 대해서는 알아 둘 필요가 있다. 좋은 자료로 처음 찾은 것은 Topcoder의 Tutorial이었다. 현재 내가 봤던 Tutorial은 찾기가 어려워 현재 검색되는 Tutorial[2-3] 최신 관련 링크를 추가해 둔다.

5. Lambda와 C++11 관련 내용

특히 여기서는 Lambda에 관한 내용을 [4-6]으로 학습했다. 전반적인 C++11 내용은 [7]에도 잘 요약되어 있다. 이 부분은 특별히 필요한지 공감이 되지는 않아서 우선 다 살펴 보지는 않았다.

기존에 이해한 내용에 대해서 상기하는 부분과 이해가 부족한 부분에 대한 학습 그리고 STL, Lambda에 대한 학습은 쭉 살펴 본 상태이다. 하지만, 계속 쓰지 않으면 잊게 되어 코드를 시간 날 때 타이핑해보거나 다시 살펴 볼 생각이다. 여라가지 항목에 관련해서 하나씩 정리도 가능하다. C의 레거시 항목은 포인터도 다른 언어에서는 c++에서 Reference라는 개념이 도입되면서, 대부분의 언어에서는 사용하지 않지만, Object Pointer만이 아닌 Function의 Pointer등도 Lambda등과 같이 고민해 보면 흥미로울 듯 하다. 다른 항목 중, 추가로 작성 해보고 싶은 내용은 나에게는 신규 항목인 Template 부터 Lambda까지는 따로 글을 써서 정리해 보는 것도 재미 있을 것 같다. 특히, C++, Java, Python에서 공통되는 부분도 있어 글을 써보면 매우 흥미로울 것 같다.

참고자료

[1] 윤성우, "열혈 C++ 프로그래밍", Orange Media 2011

[2] "Power up C++ with the Standard Template Library: Part 1", https://www.topcoder.com/community/data-science/data-science-tutorials/power-up-c-with-the-standard-template-library-part-1/

[3] "Power up C++ with the Standard Template Library: Part 2", https://www.topcoder.com/community/data-science/data-science-tutorials/power-up-c-with-the-standard-template-library-part-2/

[4] "씹어먹는 C++ 토막글 ② - 람다(lambda) 함수", http://itguru.tistory.com/196

[5] http://ciere.com/cppnow12/lambda.pdf (링크 깨진 듯 합니다.)

[6] http://pages.cs.wisc.edu/~gerald/cs368/resources/Lambda.pdf

[7] "C++ 11 특징 및 사용 예제 정리", https://duragon.gitbooks.io/c-11/content/

사람들이 많이 쓰는 컴퓨터 언어

소프트웨어 개발자로서, 가장 먼저 배우게 되는 것이 컴퓨터 언어 (Computer Language)이다. 여기서 고민 되는 사항은 두가지 이다. "만일 내가 현재 처음 컴퓨터를 접하게 되었다면 어떤 언어를 배울 것인가?"와 "지금까지 컴퓨터 언어를 배운 것을 돌아 본다면 어떤 언어를 어떻게 공부할 것인가?" 일 것이다. 첫 번째는 내가 생각하는 컴퓨터 언어에 대한 추천이고, 두 번재는 내가 알고 있는 것을 기반으로 어떻게 확장할 것인가 이다.

우선 첫번째 질문에 대해서 고민을 해보자. 2018년 6월 6일 기준으로 구글 검색 결과 제일 처음에 나오는 3가지가 TIOB Index[1], IEEE Top Programming Language[2], 그리고 The RedMonk Programming Language Rankings [3] 이다. TIOBE Index에서는 2위가 C, 3위가 C++로 사실 둘을 합치면 1등인 Java 보다도 높다. IEEE Spectrum은 미국의 전자 공학회가 발행하는 주요 잡지에서 설문 조사한 결과로 공학자들이 많이 쓰는 언어라고 볼 수 있다.  여기에는 C가 2위 C++은 4위에 랭크하고 있다 하지만, C++이 97.1%로 대부분 이 사용하고 있다 이 링크로 알 수 있는 재미있는 사실은 많은 사람들이 한가지 언어만 하고 있지 않고 여러 컴퓨터 언어를 사용하고 97% 이상이 Python, C, Java 그리고 C++까지 사용한다고 하고 있다.

이제 부터는 개인적인 의견이다. 위의 내용의 결론은 여러 언어를 배우는 것이 좋겠다는 것이다. 하지만 한꺼번에 4개를 다 시작하는 것은 좋지 않다. 우선은 목표를 고민해 보는 것이 좋겠다. 컴퓨터 관련 전공자가 될 것인지, 혹은 내 분야는 다르지만, 컴퓨터를 더 잘활용하기 위한 목적인지가 결정 포인트가 될 것이다. 

나의 추천: 비전공자 vs 전공자

만일 비전공자라면 Python으로 시작하는 것이 좋겠다. 가장 큰 이유는 Python은 컴퓨터 언어의 기본 구조는 다기지고 있으면서, 배우기가 상대적으로 쉬운 언어이다. 그럼에도 불구하고 Python은 정말 관련된 라이브러리도 많아 사무 자동화 등 여러 곳에 활용될 수 있다. 여기서 그치지 않고, 요즘 화두가 되고는 Machine Learning관련해서도 사용되고 있기도 해서 여러 활용처를 고민해 볼 수 있다. 아들에게 Python을 방학 동안 가르쳐 본 것도 이러한 판단 때문이다. 

전공자라면 Java를 추천한다. 오래된 언어이지만, 많은 대학에서 Java를 전산전공자의 처음 언어로 가르치고 있는 것으로 알고 있다. 요즘은 Smart Phone이 화두가 되고 있다. PC에서 동작하는 SW 제품을 만들기도 하지만, Web이나 Mobile에서의 SW를 만든다고 하면 Java를 기반으로 좀 더 학습하면 쉽게 접근할 수 있다.  

또한, 처음 컴퓨터 언어를 익히고 여러 프로젝트를 하면서 접하게 되는 설계 관련(Architecturing) 관련한 분야로 Design Pattern, Refactoring, Unit Testing이 Java 기반으로 설명하고 있기 때문에 내가 강하게 추천하는 이유이기도 하다.

나는 어디로?

두 번째, 지금까지 경력을 쌓았던 나의 경우 어떻게 보수 학습을 할 것인지에 관한 질문이다. 아주 개인적인 질문이다. 하지만, 기본적으로는 내가 어떤 언어들을 주로 사용했고, 현재 시점에서는 어떻게 학습해 나갈 것인지에 관한 것기 때문이다. 방향은 어찌 보면 위와 같다. 즉, Python, Java, C/C++여러 언어를 배울 것이다. 하지만, 어떤 순서로 어떤 것을 살펴 볼 것인지가 더 중요하겠다. 왜냐하면, 처음 시작하는 사람들과 같이 처음 부터 다시 다 봐야할 필요가 있지 않을 수도 있기 때문이다.

내가 가장 먼저 배운 언어는 초등학교 때, 컴퓨터를 처음 접하면서알게된 Basic언어였다. 그리고는, 대학에 입학하고 나서 학교에서는 내가 전공한 전자공학에서는 관련 언어라는 이유로 FORTRAN이 과정에 포함되어 있었다. 또한, 전산과에서는 PASCAL을 가르쳤었다. 하지만, 나는 이때에 이러한 언어들이 유행이 지났다고 생각해서, 따로 독학한 언어는 C 언어였다. 이 때에 보았던 책들을 기억해 보면 정말 함수를 만들고 문제를 해결하는 형식의 Procedural Programming Paradigm을 활용한 접근 방식이었다. 대표적으로 Main Menu가 있고 키를 눌러서 해당 함수로 호출 되게 해서 요구 사항을 만족시키는 방식이다.

회사에 입사하기 시작하면서, C++과 Java가 소개되기 시작했다. 매우 초기 버전이기 때문에 Object Oriented Paradigm이 소개 되고 이를 위한 개념들이 녹아 있는 버전의 언어들었다. 하지만, 아직, 휴대폰에는 이를 활용한 개발들이 더디게 적용 되고 있었다. 그래서, 컴퓨터 언어와 관계해서는 더 배우게 된 것이 Perl이나 Unix Shell Script, Makefile 등이었다. 실재로 프로그램하는 방식도 Procedural에서 Event-Driven으로 바뀌었다. 이는 Event Handler에서 Event의 종료를 구분하여 처리하는 구현 접근 방법이다.

Android를 시작하면서, 실재로는 Java와 C++을 더 봐야하는 입장이었지만 실재로 더 이론들을 탄탄히 하면서 진행하지 못했다. 그러면서, 결국에는 C++을 좀 더 봐야겠구나 하고 정리하게 되었고, 동료가 Python 온라인 강의를 듣는 것을 보고 배우기 시작해서 아들과 아들 친구에게 가르치는 일까지 하게 되면서 Python을 알게 되었다. 이 후, Java에서도 내가 교육을 통해 마지막으로 배웠던 것 이후에 바뀐 부분이 많다는 생각에 다시 학습하게 되었다.

사족이기는 하나, 위와 같이 공부하게 된 것도 고민을 하면서 바뀌게 된 것이다. 사실 지금돌아 보면, 역시 Java를 먼저 보강하고 C++ 그리고 Python을 다시 하는 것이 좋지 않겠나 생각하지만 이렇게 진행한 것도 나쁜 선택이라고 생각되지는 않는다.

[1] TIOBE Programming Community Index, https://www.tiobe.com/tiobe-index/

[2] The 2017 Top Programming Languages - IEEE Spectrum, https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages

[3] The RedMonk Programming Language Rankings, http://redmonk.com/sogrady/2018/03/07/language-rankings-1-18/

계정이 휴면이 될 정도로 오랫동안 고민만 했다. 어떤 것을 적어야 할지 무엇을 적어야할지 말이다. 다른 사람들이 하는 것 처럼 공부하는 것을 정리하고자 하는 마음에 계정만 열어 놓은 것이다. 하지만, 어떻게 시작해야 할지 망설여 졌던 것이다. 휴일 전날 새벽 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) 이라는 개념으로 공부한 것을 여기에 정리해보고자 한다.

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