2018년 회고록

안녕하세요. 이제 2018년이 정말 마지막 날이 다가왔네요. 다들 한 해 마무리 잘하시고, 내년에도 더 좋은 일만 가득하기를 기원합니다.

오늘은 저의 2018년을 되돌아보는 회고록을 처음으로 작성해보려 합니다. 회고록이기 때문에 격식체는 거의 사용하지 않을 것이며 처음 쓰는 회고록인 만큼 의미있는 시간을 다져보기 위하여 기록합니다.

회고록의 작성

작년에는 2017년 티스토리 결산 기능을 이용하여 블로그를 결산하고 한 해를 되돌아보며 어떠한 블로그의 글이 더 구독이 많았고 어떠한 점이 부족했는지 등을 알아보는 시간을 가졌다.

하지만 올해는 블로그의 글 수가 많이 줄었고, (확인해보니 정말 많이 줄어있었다.) 방문자 수도 예전만큼 못하였다. 물론 나의 게으름이 가장 큰 원인일 수 있겠다. 그리고 이번 티스토리에서는 블로그 결산을 하지 않는다고하니 마침 회고록을 작성하기 가장 좋은 시기라고 생각되기도 하였다.

2019년에 달라지는 티스토리

안녕하세요. 티스토리팀입니다. 티스토리는 더 쉽게 글을 쓰고, 잘 보여주고, 보다 나은 방법으로 유통하는 방법을 꾸준히 고민하고 있습니다. 이 고민을 2019년 한 해 동안 어떻게 풀어갈 계획인지 알려드리려..

notice.tistory.com

그 와중에도 블로그의 포스트를 게을리 하면서 여태까지 해왔던 일들을 정리하고 이를 토대로 내년에는 어떠한 일들을 해볼지 조금 생각해보는 시간을 가져보기로 했다.

Algorithm Study

지금 내가 가지고 있는 역량 중에 가장 부족하면서도 시급한 것은 바로 알고리즘 공부이다. 사실 알고리즘 공부는 여러모로 나의 취약점 중에 하나라고 생각한다. 수학적인 지식은 물론이옵고 문제 푸는 방식 등이 생각보다 저급(?)하여 많은 공부 시간을 요구하고 있지만 사실상 잘 지켜지지 않고 있다.

Hello Coding 그림으로 개념을 이해하는 알고리즘 - 비전공자도 볼 수 있는 헬로 코딩

프로그래밍 세계로 초대하는 알고리즘 입문서이며 비전공자를 위한 헬로 코딩(Hello Coding) 시리즈 도서다. 중학생 이상의 수학 실력이라면 읽을 수 있는 쉬운 난이도의 알고리듬 도서로 전공자, 비전공자 모두를 위한 파이썬 코드로 적혀 있다.

www.hanbit.co.kr

그래서 내가 선택한 것은 알고리즘을 좀 더 재밌게 공부해보기 위해 이해가 좀 쉽다고 생각해서 꼽은 위의 책을 구입하여 알고리즘 공부를 시작하게 되었다.

DFS, BFS 등부터 시작하여 다이나믹 프로그래밍까지 정말 많은 알고리즘 해결 방법들이 존재하였고 이들을 공부하는 데 있어 어려움은 없었지만 아직도 실전에서는 많은 부족함이 있었다. 한 문제가 주어졌을 때 해결 방법은 여러가지가 있겠지만 이 문제에서 어떤 방법으로 풀이 방식을 접근하는 게 Best solution일지, 아직 감을 잡기가 어렵다. 일단 무엇보다도 실제 코딩테스트에서는 시간 싸움이 치열하게 벌어지기 때문에 더 긴장할 수 밖에 없다.

그리고 나는 이를 바탕으로 실전 코딩테스트에 참여하게 되었다. 쉬운 알고리즘 문제, 혹은 알고리즘 외에 실제 GUI 프로그램을 코딩하는 등 여러 문제가 있었지만 나에게 있어 가장 큰 문제점은 알고리즘을 풀면서 사용하는 주 메소드들의 시간 복잡도 등을 고려하지 않고 푸는 문제점이 존재했으며 더 품질 좋은 프로그램을 내기 위해서는 이러한 메소드들의 특성을 고려하고 설계하며 프로그래밍을 해야만을 알 수 있었다.

Back-end Development

나는 이전부터 리눅스 서버에 대해 관심이 많았었고 이를 발판삼아 군생활 동안 전산실에서 근무했던 경험을 가지고 실제 서버 운영에 이바지를 한 적도 있었다.

이를 바탕으로 직접 서버를 개발해보자라는 마음을 가지게 되었고, 수많은 프레임워크 중 Spring boot와 Flask를 공부하게 되었다. 물론 이들 프레임워크에 대해 전체적으로 공부한 것이 아닌 백엔드 서버 기능 중에서도 가장 기본 골격인 Restful API에 대해서만 끄적여 봤다.

REST API를 처음 접했을 때 이 인터페이스로 할 수 있는 것이 정말 많다는 것을 알았다. 기본적인 쇼핑몰부터 하여 나의 홈페이지 관리, 로그 등 주요 시스템의 기능들을 이로 구현할 수 있다는 것에 굉장히 놀라웠고 나는 이를 바탕으로 무언가를 만들어보기로 했다.

학교는 졸업했지만 이전에 다니고 있었던 동아리의 이름으로 챗봇을 하나 개발하였다. 동아리를 홍보하는 겸 회원들의 편의사항으로 식단과 버스 정보를 확인할 수 있는 간단한 챗봇이었다.

Restful API를 사용하여 개발하였고 Python의 Flask를 사용하였다. 무엇보다도 단순 챗봇이기 때문에 가볍고 라이트한 Flask 프레임워크가 제격이라고 판단하였다. 현재 이 서비스는 Amazon Web Services에서 MSA(Micro-Service Architecture) 형태로 운영 중에 있다.

하지만 공교롭게도 기존 API를 사용한 챗봇 서비스가 2019년 12월 31일을 마지막으로 서비스가 종료된다고 한다. 시간이 된다면 다른 챗봇을 개발하여 서비스해볼 생각도 했었지만 아쉽게도 이는 실행되지 못할 것 같다.

Source Code

Challenge Hackathon

해커톤을 한 번 도전 해보자라는 생각은 꽤 많이 있었었다. 하지만 졸업하기 전 시즌에는 취업 준비도 있었고 나는 그래서 자유로운 해커톤인 GCPUG Hackathon 2018에 참여해보기로 했었다. 무엇보다도 경쟁이 아닌 자유롭게 무언가에 도전해보자 라는 부담감이 덜한 해커톤이라는 점과 서버에 관심이 있는 한 엔지니어로써 클라우드와 직접 서버를 운영하는 것에는 어떠한 방식의 차이가 있는지도 경험해보고 싶었기 때문이다.

하지만 시간은 나를 허락해주지 않았다. 마침 당일에 급히 면접 일정이 잡히게 되었고, 나는 부득이하게 이 일정을 취소할 수 밖에 없어, 해커톤의 참여기회는 그렇게 무산되고 말았다. 취업의 길에 놓여있는 사람으로써 면접보다 해커톤을 더 중요시할 수는 없었기 때문이다.

몇 주 뒤, 나는 모 회사에서 주최하는 해커톤 공고문을 보게 되었다.

MIDAS Challenge 2018

MIDAS Challenge 2018은 우수한 개발자를 발굴하는 소프트웨어 개발 경진대회입니다.

challenge.midasit.com

지금도 이 페이지가 아직 살아있는데, 아마 차후년도에 변경될 듯하다. 어쨌든 나는 이 해커톤에 참여하기 위해 페이지를 방문했었다.

그런데 이 해커톤은 다른 해커톤과 다르게 참가 자격에 제한이 있었다. 자세히 보니 이 해커톤은 채용과 관련된 해커톤이었고 그렇기 때문에 일종의 서류전형과 코딩테스트가 존재했다. 해커톤에 도전해보겠다는 생각은 변함이 없었기 때문에 과감히 나는 이 과정에 모두 참여해보기로 했다.

그리고 당당히 해커톤 예선에 합격하였고, 오리엔테이션에 참가하고자 하였다. 그런데 해커톤에 예선 합격하고나서 생각난게 있었다. '내가 어느 포지션에 지원했더라?'

어쨌든 첫 해커톤이었고 참여하기 전부터 설레임과 긴장감이 가득했었다. 모르는 사람들과 같이 개발한다는 것 과연 어떤 즐거움이 있고 단점이 있을까 라는 생각이 가득했었다. 어쩌면 이 개발 경험이 앞으로 차후의 나의 회사 생활과도 연관이 있을 것이고 이에 대한 사전 연습이라 생각하고 긍정적인 마음으로 참여하였다.

해커톤애 참여한 짤막한 후기는 서로 모르는 사람끼리 개발하면서 나타나는 즐거움과 서로가 가지고 있는 문제점과 고민 등을 자유롭게 이야기할 수 있는 시간 등을 가질 수 있었다는 것에 굉장히 많은 보람을 느꼈다. 그리고 먹을 거 걱정안하고 개발할 수 있다는 것. (이거 정말 좋은 것 같다. 그런데 진짜 시간 생각 없이 개발하고 있는데, 먹을 게 계속 나온다. ) 그런데 이게 또 안좋은 점이 있다. 개발 진척이 잘 안되고 있는데, 벌써 밥시간. 음 이거는 정말 당황스럽지 않을 수 없었다. 더욱이 이 해커톤은 취업과 연계되어 있는 해커톤이기도해서 내가 혹시 잘 하지 못해 이 분들의 취업의 걸림돌이 되지 않을까 라는 우려도 조금은 있었다. 그런 부담감이 있어서 그랬는지는 몰라도 생각보다 백엔드 포지션에서 나의 역할은 새벽 2시에 무사히 마칠 수 있었다.

해커톤 이후, 좀 무리가 있었던 것은 잠을 못잔 탓에 몸에 피로가 많이 쌓인다는 점이다. 만약 회사 생활을 하면서 해커톤을 하는 것이라면? 그 전 날에 휴가 쓰는 것을 매우 심각하게 고려하는 것을 추천.

Source Code

Open Source Contribution

해커톤이 마무리되고 난 후, 나는 취직을 하게 되었다. 그곳에서 데이터 엔지니어 업무를 맡게 되었고 여기서 맡은 첫 프로젝트는 영상의학 이미지의 공통 데이터 모델을 개발하는 것이었다. 공통 데이터 모델이란, 흩어진 데이터를 일정한 분석 용도를 사용하기 위해 모인 공통 데이터 형태로써 CDM(Common Data Model)이라고도 한다. 실제로 의학 데이터에서 많이 쓰는 용어인 듯했다.

여기에서 일하면서 이 곳이 오픈 소스 라이브러리, 모듈, 프로그램을 사용하고 있었다. 특히 한 그룹의 오픈 소스 소프트웨어를 많이 사용해서 여기서 서버 관리 업무도 동시에 맡다보니 그에 관한 문제에 대해 고민을 많이 하게 되었다.

소프트웨어에 대한 문제를 해결한다는 것은 개발자로써의 기본 역량이기도 했다. 하지만 내가 만든 소프트웨어가 아닌 다른 3자의 소프트웨어에 문제가 있어 코드를 수정해야 한다면 어떻게 해야 할까? 그냥 내가 수정하고 나만 사용하는 것이 맞는 걸까? 아니면 버전 관리나 유지를 위해서 이를 issue에 등록하고 코드를 기여하는 것이 맞는 걸까?

사실 취직하기 전에도 많이 생각했던 부분 중에 하나였다. 코드를 기여한다는 것. 그것은 무슨 의미가 있는 것일까? 이 생각을 할 때마다 가끔은 내가 개발 역량이 아직도 멀었구나 라는 엉뚱한 생각을 한 적도 있었고 어쩌면 처음으로 이러한 활동을 하기 전에 이러한 생각을 한다는 것은 당연한 것이다. 라는 생각을 가지기도 했었다. 하지만 내 답은 이거였다. 내가 이 소프트웨어를 계속 쓰는 이상 이것이 문제인 것을 알았고 이것이 차기 버전에도 영향을 미치는 것이라면 공식적으로 issue를 제기하고 명확하게 문제 해결을 제시하거나 서로 풀어나가는 것이 맞다고 봤다.

처음으로 발견한 이슈에 대해서는 큰 이슈까지는 아니었다. 애플리케이션configuration 중 Microsoft SQL Server와 연동했을 때 발견한 문제였는데, 단순 코드 오타로 생긴 오류여서 issue에 올려 해결할 문제까지라고는 아니라 생각했다. 하지만 지금에와서 생각해보면 이러한 문제 해결 방법이 별로 좋다고 느끼지 못할 때가 많이 있었다.

공통 데이터 모델을 개발했을 때 나는 DatabaseConnector라는 R의 패키지를 사용했었다. 여기에서는 Data frame을 insert 해주는 함수도 있었는데, 공교롭게도 이 함수가 DATETIME이나 BIGINT 자료형에 대해서 아무런 지원을 하지 않았다는 것이 아쉬웠다. 그래서 나는 이 라이브러리에서 DATETIME, BIGINT 타입의 삽입을 지원하도록 코드를 기여하였다.

BIGINT 지원이 R 코드에서 잘 수행되지 않은 이유는 R에서는 C++나 Java처럼 기본 자료형으로 INT64를 지원하지 않기 때문이다. 그렇다면 2^32 이상되는 숫자는 어떻게 표현을 하냐? FLOAT로 표현해야한다. 나는 이 부분을 너무 불편히 여겼다. 하지만 이러한 자료형이 없어도 BIGINT를 삽입할 수 있도록 구현하는 것은 큰 문제가 되지 않았음을 알았기에 그리고 나와 같은 생각을 하면서 개선을 바라고 있다는 사람이 있을 수 있다는 생각에 과감히 코어 부문에도 코드를 기여하게 되었다.

물론 오픈 소스의 기여가 항상 Accept 되는 것은 아니었다. 몇 개월 전 회사에서 사용하고 있는 웹 프레임워크 중 하나에 XSS 취약점 문제가 있어 문제점 코드를 수정하고 PR을 올렸지만 해당 애플리케이션의 디자인 패턴과 적합하지 않다는 이유로 Reject 되거나 보류되기도 하였다. 한 때 백엔드 개발을 공부했던 사람으로써 이 부분은 나 자신에게 실망을 감추지 않을 수 없었다.

Github라는 것을 사용한 것은 올해로 3년이 되어간다. 물론 안 것은 2012년 때부터였지만 군 생활 등을 이유로 사용하지 않았다. 여태까지는 소스 코드 보관용이나 아는 사람과 같이 하는 프로젝트를 할 때 사용하는 정도가 전부였고 다른 소프트웨어 코드에 직접적인 코드를 기여하여 참여한 것은 이번이 처음이었다. 두려웠던 것은 영어라는 높은 장벽이 있었기 때문이다. 물론 코드 리딩하는 것도 리뷰하는 것도 많이 부족했던 것이 사실이다. 하지만 기본적인 의사소통이 어렵다면 어떻게 코드를 기여할 수 있겠는가, 하지만 이번 코드 기여를 통해 알게 된 것은 Try하는 것을 두려워하지 말자라는 것이다. 지금도 영어라는 장벽이 너무 높아 소통이 잘 안되지만 이렇게 코드를 기여하는 습관을 들이다보면 언젠간 내 영어 실력도 향상이 되지 않을까? ㅠ...

앞으로의 계획...

2018년에는 정말 많은 일이 있었다. 아마 내가 블로그 활동을 몇 개월 안한 동안 나의 Github Contribution 도트가 쌓여있다. 음 결론적으로 말하자면 여기에 벌써 재미 붙인 것 같다;; 앞으로도 내가 이 활동을 계속하는 동안 지금하고 있는 그룹 뿐만이 아니라 다른 어딘가에서도 코드 기여를 하고 있을 것이다.

2019년에는 Deep Learning을 조금 익혀보고자 한다. 지금 내가 다니고 있는 회사에서는 데이터를 주로 다루고 있고 지금은 ETL 모듈 초기 버전을 완성한 것이 전부다. 물론 그 데이터 모델을 기반으로하여 간단한 애플리케이션을 개발하기도 했지만 사실상 간단하고 단순한 애플리케이션이기 때문에 R 언어를 연습하는 용도에 그치는 정도다. 깊게 공부하지 않아도 되서 누구나 쉽게 개발할 수도 있다.

올해 회사에 입사해서 Deep Learning에 대해 아예 공부를 하지 않았던 것은 아니었다. 하지만 생각보다 이 녀석한테 흥미를 가진다는 것이 쉽지 않았다. 학회도 몇 번 갔었고 그를 통해서 다른 사람들의 프로젝트도 살펴보고 어떻게 사용했는지, 문제점은 무엇이 있었는지 등 다방면으로 보고 나름대로 공부해봤지만 여전히 흥미를 느끼고 있지 못했다. 하지만 수확이 없었던 것은 아니다. 학습이 어떻게 이루어지는지, 어떤 식으로 접근해야하는지 정도는 이해할 수 있었고 실제로 머신러닝 엔지니어들이 하는 일이 어떤 일이고 이것이 나중에 어떻게 사용될지 정도는 대충 감은 잡을 수 있었다.

회사에 들어가기 전 경험한 첫 해커톤 참여 그리고 챗봇의 개발 등 올해는 나에게 있어 프로젝트에 대한 이야기가 많이 존재했다. 물론 코앞의 취업도 있었고 무엇보다 학교를 졸업했기 때문에 그만큼 공백의 시간도 많이 있었기 때문이라고 생각한다.

비록 짧은 6개월 동안의 회사 생활이었고 Deep Learning을 공부하는 것도 남는 시간에 짬짬이 하는 아주 깨알같은 시간이었지만 이 시간동안 오픈 소스 기여, ETL과 데이터 처리의 공부 모듈의 개발 등을 할 수 있어 나름 뜻깊은 시간을 보냈다고 생각한다. 그래서 앞으로 더 오픈 프로젝트 기여에 집중하고 구글에서 제공하는 머신 러닝 단기 집중 과정을 통해서 본격적인 공부를 시작해보고 올해 개발해 본 데이터 모델에 어떻게 사용할 수 있을지 고민을 해 볼 필요가 있겠다.

올해 공부한 알고리즘 공부는 나의 개발 역량을 높이는 데 중추적인 역할을 하였다. 하지만 지금도 가끔 알고리즘 문제를 풀고 있고 풀 때마다 느끼는 것은 "과연 이게 최선인가"이다. 더 좋은 코드, 깔끔한 코드를 만들 수 있을 것 같은데 라는 생각은 가지고 있지만 마지막에 답을 보거나 누군가가 리뷰를 통해서야 알게 된다. 그래서 나는 지금도 코드 리뷰를 굉장히 중요하게 여기고 있고 그것을 누군가가 해준다고 한다면 기꺼이 환영한다. 하지만 지금 내가 가지고 있는 문제는 이러한 문제가 아니다. 아직까지 내가 알고리즘을 작성한다고 한다면 기본적인 자료구조를 사용해서 주먹구구식으로 푸는 방법이다. 이렇게 해결하는 방법이 결코 잘못된 것은 아니다. 그렇다고 잘한 일도 아니다. 적절한 알고리즘 해결 방법을 사용하기 위해 올해 배운 DFS와 BFS에 대해 다시 한 번 되짚어보고 이를 실무에 적용해 내 것으로 만들 필요가 반드시 존재한다. 물론 두 가지 다 하기 힘들다면 하나라도 꼭 시도해보자.

데이터 엔지니어 업무를 하면서 가장 걱정인 것은 바로 여태까지 내가 소프트웨어 엔지니어 공부를 하면서 배운 아키텍처나 디자인 패턴이다. 요즘 점점 데이터 처리에 이목이 집중되면서 프로그램의 디자인 패턴이나 아키텍처 공부에 굉장히 소홀해지고 있다. 이렇게 되면 차후에 큰 애플리케이션을 개발할 때 다시 배워야하는 문제점을 지니고 있다. 현재 다니고 있는 곳에서 사용하고 있는 Back-end의 코드를 리딩해보고 기여해보도록 하자. 이 애플리케이션에서 사용하는 아키텍처와 디자인 패턴은 내가 코드를 리뷰하거나 기여해볼 정도로 견줄만한 스펙을 지니고 있다.

마치며...

여기까지 2018년 저의 회고록을 작성해봤습니다. 정말 1년이라는 시간은 짧으면서도 기네요. 회고록을 쓰면서 이 글을 어떻게 마무리 짓지? 어디까지 쓸까?를 정말 많이 고민했습니다. 그래도 확실한 건 올해 정말 제가 프로젝트에 참여하기 위해 많은 노력을 기울였음과 동시에 뜻깊은 일들이 많았다는 점이었습니다.

내년에도 더 재밌고 뜻깊은 시간과 개발이 많았으면 좋겠네요. ^^;

아 그리고 앞으로의 블로그 활동은 계속 이어갈 것이지만 지금의 글 발행 횟수를 봐서 좀 더 노력해야겠죠...ㅠㅠ 
더 좋고 유익한 글로 만나뵐 수 있도록 하겠습니다. 예년처럼 1개월에 한 개의 포스트는 작성할 수 있도록 하겠습니다.

여기까지 읽어주셔서 감사드립니다.