Neon K.I.D의 2019년

어느 덧 2019년도 마지막 날이 다가왔네요. 뭐 항상 나의 개발일지를 적으면, 올해든 내년이든 비슷할 것 같다. 라는 막연한 생각 많이 하는데, 올해는 유난히 느끼는 점이 많이 있어서 조금 의미 있는 회고록이 되지 않을까 생각합니다.

 

 

의료 데이터와 함께한 프로젝트

2019년 7월, 저는 1년의 계약직 생활을 마무리하고, 퇴사하게 되었습니다. 한 해 동안 많은 일을 했다고 생각합니다. 데이터 엔지니어링부터 머신 러닝까지.. 의료 데이터라는 수준 높은 난이도의 데이터를 다뤄보며 비록 1저자까지는 아니지만 논문에 이름이 올려가기도 하고, 토이 프로젝트를 진행하는 등의 성과가 있었네요.

NEONKID/RCDMViewer

회사에서 R을 다루게 되면서, R이라는 것을 다시금 생각해본 적이 많이 있었습니다. 제가 아는 R은 그저 데이터를 분석하고 결과를 도출하는 단순한 데이터 분석용 언어에 불과하다 생각했지만 실제로 R 언어를 가지고 웹 애플리케이션을 개발할 수 있는 레벨까지 성장해 있었습니다. 

그렇게 시작해서 만든 것이 바로 이 뷰어입니다. 이 뷰어는 병원에서 촬영되는 CT, MRI, X-ray의 데이터를 볼 수 있도록 개발한 웹 뷰어입니다. 사용한 기술 스택은 아래와 같습니다.

• Language: R 3.4.4, Java 1.8
• Framework: Shiny 
• DBMS: MSSQL, PostgreSQL, Oracle
• Lib: OHDSI Circe-be

이 기술을 사용해 본 간단한 후기를 얘기하자면, R 언어 하나 가지고는 이러한 애플리케이션 레벨의 수준을 개발하기는 어렵습니다. 다만 R 언어에 C++나 Python, Java와 같은 프로그래밍 언어를 섞어서 쓸 수 있기 때문에 그 부분에 있어서는 매우 좋았죠.

또 한 가지는 Shiny가 비록 웹 애플리케이션을 만들 수 있는 레벨이라고 하더라도, 그 레벨은 운영으로 봤을 때, 회의에서 공동 작업 정도입니다. 따라서 병원에서 영상의학과와 같이 한 학과에서 공동 작업하는 정도가 가장 적당하다고 보면 되겠죠. 이 외에 대용량 처리 서비스나 이런 부분에서는 오히려 약한 모습을 보여줍니다. 

NEONKID/PLSP

회사에서 난소암 관련 프로젝트를 진행하면서 서드 파티 라이브러리로 개발하게 된 유전체 이미지 처리 라이브러리입니다. 당시 저는 이미지 데이터셋 전처리를 맡았고, 이 라이브러리는 Python에 있는 PIL 라이브러리의 한계점을 극복하여 VIPS 라이브러리를 이용해 개발하게 되었습니다.

• Langauge: Python 3.6
• Lib: libvips, OpenSlide

처음 유전체 이미지를 처리할 때 가장 어려웠던 점은 픽셀 크기가 일반 이미지의 몇 배 이상이고, 메타 데이터 중에 섬네일 이미지가 포함되어 있어, PIL로 처리할 때 픽셀 이미지가 너무 큰 사이즈로 되어 있어, 라이브러리에서 처리할 수 있는 메모리의 한계점이 도달하였을 때, 섬네일 이미지로 처리되는 문제점이 있었습니다. 

당시 이 문제를 해결하기 위해서 지도 이미지 처리 라이브러리를 사용하려 했지만 C++ 기반의 vips 라이브러리가 대용량 이미지 처리에 매우 용이함을 알게 되었고, vips로 이미지를 처리할 수 있도록 라이브러리를 별도로 개발하였습니다.

2019 OHDSI Symposium Collaborator Showcase – OHDSI

이 프로젝트에 있어, 아쉬웠던 점이 있다면, 일단 이 회고록에 많은 내용을 담을 수는 없다는 것...ㅎㅎ 그리고....

비록 회사에서 마지막 프로젝트로 이름을 남겼지만 이 프로젝트는 그만큼 값어치가 있었던 프로젝트로 기억하고 있습니다. 어느샌가 이런 멋진 이름을 남겼는데, 이 프로젝트에 대한 목적 중 하나는 사망률이 급격히 증가하는 난소암 판별을 머신 러닝을 이용해서 난소암의 조기 발병률을 높이고 사망률으 낮추는 데 이바지한 프로젝트입니다.

 

 

마지막 의료 프로젝트 Contribution

회사에서 오픈 소스 라이브러리를 많이 이용하다보니, 작년에도 이와 비슷한 기여 활동을 한 적이 있었습니다. 작년에는 데이터베이스 부문을 기여했다면, 올해는 웹 애플리케이션쪽으로 기여하게 되었네요.

https://github.com/OHDSI/WebAPI/releases/tag/v2.7.0

OHDSI/WebAPI

사실 저는 뭔가 기여를 한다거나 참여를 할 때, 사람들이 보통 잘 안하는 것을 참여하고, 기여를 하는 편입니다. 이 프로젝트 또한 관련 된 사람들이 많았지만, 사용 대상이 소프트웨어 기술쪽보다는 의료 기술쪽에 포함된 사람들이 많았기 때문에 소프트웨어로 기여하는 사람들은 많이 없었고, 그래서 참여하게 되었습니다.

이 프로젝트는 다수의 병원 데이터를 한 곳에 모아 특정 집단을 정의하고, 다양한 Estimation, Prediction을 연구할 수 있도록 도와주는 서포트 웹 애플리케이션이며, 다수의 병원 데이터를 처리하는 빅 데이터 처리 솔루션 중 하나입니다. 기술 스택은 아래와 같습니다.

• Language: Java 1.8
• Framework: Spring Boot 2.0, Spring Batch, Apache Shiro
• DBMS: MSSQL, PostgreSQL, Oracle

나중에 기여를 하고나서 알게 된 것이지만, 유난히 저 버전 릴리즈 했을 때는 많은 사람들이 기여 활동에 참여하였습니다. 역대로 해당 프로젝트의 커밋 수가 가장 많았고, 그 커밋으로 인하여 많은 버그들이 수정되었고, 환경이 개선되었습니다.

제가 주로 기여했던 것은 이미 변경사항으로 처리되어야 할 데이터 모델들의 A.I 정책이 아직도 IDENTITY를 사용하고 있어, 이 부분을 일부 수정하였고, XSS 취약점을 수정한 부분이 기억에 가장 많이 남네요.

한 가지 아쉬웠던 점은 대용량 데이터 처리를 위해 Spring Batch를 사용했다는 점은 굉장히 인상적이었습니다. 그런데, 약물, 병명 등의 검색 기능이 SQL 쿼리로 동작함으로 인하여, 그 검색 속도가 굉장히 느린데, ElasticSearch나 Solr와 같은 솔루션을 탑재한다면, 검색 속도를 충분히 개선시킬 수 있을 것이라고 생각하네요. 

(나중에 들어가서 확인해보니, 차후 버전에 도입 계획이라고 하네요 ^^;)

 

 

퇴사 후, 또 다시 참여하게 된 해커톤

퇴사한지, 1주일도 채 안되서 해커톤에 참여하게 되었습니다. 작년에 해커톤을 했을 때, 아쉬웠던 점이 많이 남았어서 올해도 해커톤을 참여하게 되었는데요.

올해는 AWS를 이용한 해커톤인 Amathon 2019에 참여하게 되었습니다.

https://github.com/amathon-2019

Amathon 2019

(홈페이지가 분명 있었던 것 같은데, 어느샌가 폐쇄 되어있네요. -_-;)

Amathon 2019에 참여하기 전에, 기억났던 문구가 있다.

"해커톤이란 (...) 하지만 한국에서는 공모전의 일종으로 수상을 하기 위한 하나의 이벤트로서 많이 변질하여 왔습니다. AUSG는 해커톤이 프로페셔널한 사람들이 모여서 수상을 하기 위한 경쟁의 도구가 아니라 (...) 현업에서 사용하는 도구와 기술들을 만나보며 학업과 현업의 거리를 줄이려는 행사를 위하여 Amathon을 기획하게 되었습니다."

당시, 이 문구를 봤을 때 크게 부정적인 이미지도, 긍정적인 이미지도 있지 않았습니다. 사실상 해커톤이 공모전의 일종으로 수상하기 위한 수단, 그렇게 받아 들이는 사람 당연히 존재할 것이라 생각했고, 학업과 현업의 거리를 줄이는 용도 또한 틀린 이야기는 아닌 듯하였습니다.

하지만 제가 생각하는 해커톤은 기술의 장, 각자의 개발 이야기를 단순히 이야기로 나누는 것이 아닌 직접 같이 해보며, 공유하고, 나누는 시간, 그리고 그 결과를 보는 재미에 있다고 생각합니다. 수상을 받는다면야 더욱 좋겠지만, 제가 해커톤을 나가는 본질적인 목적은 이 점에 있습니다.

본론으로 들어가서, 제가 맡았던 프로젝트는 "머신 러닝 기반의 음성 인식 코드 에디터"였습니다. 

(머신 러닝 기반의 음성 인식? 음, 샘플링 데이터를 다 수집해서 기계 학습 돌리기에는 도저히 1박 2일로 부족했던 시간...)

혹시 몰라, 내 능력이 부족하지 않았나 생각하여 주변 개발자들, 같은 팀원들에게도 조언을 구해봤지만, 아쉽게도 그런 분은 계시지 않았습니다. 가능하면 위의 것을 목표로 한 번 해보자. 라는 마음을 가졌지만, AWS 크레딧 비용 제한도 존재하였고, 자유로운 개발 환경이 아님을 핑계 삼아 아쉽게도 위의 목표는 수행할 수 없었습니다... ㅠㅠ

가능한 AWS를 사용하는 것이 필수 조건이니, AWS에서 제공하는 Transcribe를 이용하였고, 우리팀은 이를 적극 활용하려 하였으나 결과를 받아오는 시간이 1분 이상 소요되는 것은 정말 크나큰 흠이었고, 우리는 결국 Azure를 사용하여 해커톤을 마감짓는 만행을 저지르게 되었습니다...ㅋㅋ

그래서 애초에 수상 같은 건 기대하지도 않았는데, 이런 소소한 재미를 남겨주는 이벤트가 있어서 또 다른 해커톤으로 기억에 남는 자리가 되었었네요. 

 

 

Google Study Jam과 Google Cloud License 

올해 구글 스터디잼을 통해 머신 러닝과 구글 클라우드 플랫폼을 공부하면서 느낀 것이 있었습니다. 블로그에도 관련 글을 적었습니다만 스터디잼에서 단순히 수료 과정을 거친 것은 제 자신이 만족하지 못했죠. 그래서 구글 클라우드 플랫폼의 라이센스를 취득하게 되었습니다.

https://blog.neonkid.xyz/189

GCP 자격증 후기 - Google Certified Professional Cloud Architect

백엔드 개발자를 목표로 하고 있는 저에게 있어서 클라우드 아키텍트는 그야 말로 필수라고 생각했습니다. 제가 원하는 개발자는 단순히 코드를 작성하는 코더 레벨보다는 설계와 배포 등을 전부 고려하는 엔지니어 레벨까지를 목표로 하고 있기 때문이죠. 어쩌면 AWS 라이센스를 취득해야 맞을지 모르겠지만, 스터디잼을 한 것도 있고해서 기왕이면 Google Cloud Platform 라이센스를 취득하게 되었습니다.

 

 

둔화된 알고리즘 실력을 찾아서...

작년에도 알고리즘 스터디를 정말 열심히 해야지.. 했었는데, 입사한 뒤로 한 번도 알고리즘 공부를 열심히 해본 적이 없었습니다. 그걸 알게 된 것은 퇴사를 하고나서, Java와 C++를 다시 잡았을 때 쯤 이었습니다.

사실 데이터 분야에서 일을 하다보면 프로그래밍 언어보다는 SQL이나 R과 같은 데이터 처리 언어 쪽을 더 많이 다루게 되고, 엔지니어링도 같이 하게 됩니다. 그렇다고 아예 프로그래밍 언어를 안쓰는 것은 아니지만 여태까지 했던 프로젝트들 전부 하나부터 열까지 소스 코드를 읽어봐도 프로그래밍 다운 프로그래밍을 했다는 느낌을 받지 못했다는 것은 개발자로써 분명히 반성해야 될 부분이라고 생각했습니다.

그래서 시작한 것은 바로 1일 1 알고리즘 프로젝트였습니다. 알고리즘 문제는 프로그래머스, 백준 등 여러 사이트에서 많이 제공하고 있고, 차후 이직 준비를 위한 코딩 테스트 준비로도 쓰일 수 있기 때문에, 어쩌면 이러한 계획은 저에게 반드시 도움이 될 것이라 생각하여 퇴사 직후 바로 준비하게 되었습니다.

알고리즘 문제를 풀면서, 가장 장점으로 꼽히는 것은 자주 사용하는 언어의 자료 구조, 함수, API 등을 익힐 수 있고, 그만큼 문제의 접근 능력과 풀이 능력을 향상시킬 수 있다는 점은 큰 장점입니다. 만약 내가 프로그래밍을 하면서 대부분 프로그래밍할 때 초반부부터 구글을 킨다거나(?) 가장 기본적인 ArrayList, Vector 등의 자료구조 함수를 다시금 보는 습관이 있다면, 이 과정을 해보는 것을 저는 강력히 추천드리는 바입니다.

 

 

건강 관리

회사 다닐 때는 퇴근하자마자 사내 헬스장을 이용해서 1시간씩 헬스를 하였습니다. 주로 등과 가슴 운동을 중심으로 하였고, 그로 인해서 등 근육이 정말 많이 늘어났습니다.

퇴사하고나서의 운동 계획은 점심 식사 후, 조깅 그리고, 푸쉬업, 플랭크 (최근에 인바디 재보니 복부 지방률이....;;)를 주로 하는데요.

헬스장을 다니는 것만큼은 많이 못하지만 개발자라는 삶 자체가 앉아있는 시간이 많다보니 은근 건강에 좋지 않은 습관들이 많이 있어서 올해는 정말 꾸준히 운동을 하려고 노력하였고, 가급적이면 술을 줄이고, 단백질 위주의 식습관을 가지려했습니다.

내년에도, 최소한 이 정도는 해야하지 않을까...

 

 

새로운 식구를 맞이하기까지...

제가 사용하는 개발 장비는 MSI PE60-2QE Prestige 노트북으로 Ubuntu Linux와 Windows 10을 멀티 부팅하여 사용하고 있습니다. 

그런데, 노트북이 워낙 무거워서 다른 노트북으로 구입해보는 겸, 이번에 새로운 장비를 구입할 계획을 가지고 있었는데요. 아직 노트북이 크게 필요하지는 않기 때문에 먼저 조립 컴퓨터를 구입해보기로 하였습니다.

마침 블랙프라이데이도 겹치고 해서... 이번에는 해외에서 컴퓨터 부품을 구입하여 조금 저렴하게 구입해보자는 욕심을 가지게 되었습니다. 그런데, 특가 세일하는 제품을 일일이 검색하여 찾는 것은 쉽지 않으니 국내에서 특가 사이트가 있다는 게시판을 몇 개 모아서 데이터를 크롤링 한 다음, 알림을 받을 수 있는 서비스를 개발하여 이를 활용하였습니다.

확실히 일일이 찾아다니는 것보다 손을 덜 쓸 수 있어 편리하였고, "이 맛에 개발하는 거지...(?)" 라고 느끼면서 아래의 제품을 아마존에서 구입하였습니다. (여러분, 지름신이 이렇게 무섭습니다..)

• GIGABYTE AORUS ELITE X570
• G. Skill Trident Z 3600 CL16 16GB * 2
• XPG GAMING Gen 4x4 SSD 1TB

CPU나 그래픽 카드, 파워 서플라이 등은 해외 특가를 찾기가 좀처럼 쉽지 않아서, 다른 제품은 국내에서 구매하게 되었고, 본격적인 조립에 들어갔습니다. (특히 XPG GAMING SSD는 정말 100 달러 이상 저렴하게 구입한 것 같네요.)

• AMD Ryzen 7 3700X
• SEASONIC GOLD 750 Full Modular
• GALAXY GeForce RTX 2070 SUPER EX O.C

와 근데, 정말 조립 한지가 10년 가까이 다 되어 갔는데, 요즘 컴퓨터 케이스는 강화 유리로 나온다는 것을 처음 알게 되었네요. 요즘 컴퓨터 조립은 성능 말고도 감성으로도 돈을 쓸 수도 있겠다. 라는 생각을 많이 했습니다. 그렇게 조립이 끝났는데....

(..... 화면에 아무것도 안 나옴...)

(에이.. 설마, 설마 그거 겠어...?)

사실 해외 직구하기 전에 정말로 고민했던 것은 이것입니다. 해외에서 부품을 사게 되면 국내 A/S는 포기해야 하는데요. 따라서 무탈하게 잘 쓰거나 "초기 불량"만 나타나지 않으면 정말 성공작이라고 할 수 있습니다.

그런데, 느낌은 왠지 "초기 불량..." 당시 조립했던 촉감을 떠올려보면, 그것이 아닐 수 없었습니다. 

결국 저는 여분의 확인 부품이 없어, 주변 컴퓨터 가게의 일정 비용을 주고, 의뢰를 맡겼습니다. 그러고 며칠 뒤....

(이거 메인 보드 문제 맞는 것 같네요....)

조립하면서 한 번도 메인 보드 불량이라는 걸 받아본 적이 없었는데, 극한의 1/20 확률에 걸리다니... 

결국 실망을 무릅쓰고, 이 녀석은 다시 미국으로 돌려보내졌고.... 저는 하나의 교훈을 얻었습니다.

메인 보드는 아무리 가격을 내려도, 해외 직구하지 말자...

수리 비용도 수리 비용이지만 국내 A/S가 안되기 때문에 해외로 보내야 하는데, 그 비용이 진짜 장난 아닙니다. 게다가 그만큼 시간도 1주~2주 아니고, 1달~2달이기 때문에 정말 해외 직구로 조립 고민하시는 분들 계신다면, 메인 보드는 가급적이면 해외 직구 하지 마시길...

그렇게 새로운 메인 보드를 국내에서 구입하고, 조립을 하여 고군분투 끝에 새로운 식구를 맞이하게 되었습니다.

 

 

내년도 계획과 다짐.

회사를 그만 둔 해인 올해에 그만두고 나서 생각이 들었던 것은 "아 혹시 내가 개발에 소홀해져서 나태해지는 것은 아닐까..", "바이오리듬이 깨지면 어떻게 하지.." 라는 고민을 많이 하게 되었는데요.

그런데 이렇게 글을 적어보니 다행히도 큰 차이는 나지 않았다는 것이 눈에 보여서 "아 내가 그래도 못하고 있진 않구나..." 라는 평타의 느낌을 받을 수 있었습니다.

이 회고록에는 적지 않았지만, 저는 퇴사 후, 제 홈페이지(https://neonkid.xyz)를 다시 리뉴얼하였고, 거기에 진행했던 프로젝트에 대한 상세사항을 기록하는 것을 중심으로 넣었습니다. 이 때 저는 TypeScript를 처음 사용하였고, 앞으로의 개발 계획을 모놀리틱 아키텍처 방식에서 마이크로 서비스 아키텍처 중심으로 나아가겠다고 결정한 바도 있었습니다.

이에 내년에 저는 백엔드 개발의 역량을 더욱 더 쌓아나고자, Spring Batch, Spring Cloud와 같은 마이크로 서비스 아키텍처 중심 개발과 이를 빅데이터 인프라에 활용을 하는 것을 중점적으로 공부해볼 생각입니다. 엔지니어링 쪽으로 나아간다면, 아마 클라우드 쪽을 좀 더 파보지 않을까 라는 생각이 드네요.

한 가지 더, 내년에는 머신 러닝을 좀 더 공부해서 내가 정말로 만들어 보고 싶은 딥러닝 모델을 혼자서 개발해볼 생각입니다. 사실 딥러닝 모델을 개발하는 게 일반 소프트웨어 개발만큼 Cost(비용)이 들지 않습니다. 여러 시도를 해야 하는 만큼 그만큼 비용이 정말 많이 들어가고, 손도 많이 들어가는 녀석입니다. 물론 이를 잘 연습하고 실력을 쌓는다면, 그에 들어가는 비용 또한 줄어들겠죠. 

하지만 비용이 얼마가 들더라도, 내가 만들고 싶은 딥러닝 모델을 만드는 것은 분명히 지금 가지고 있는 개인화 서비스를 좀 더 발전시키고, 포트폴리오화 하는 데 얼마든지 도움이 될 수 있는 요소라고 생각합니다. 따라서 내년에는 TF 2.0을 공부하여 이를 좀 더 많이 활용해보고자 합니다.

쓰다보니 정말 긴 글이 되었습니다. 여기까지 읽어주셔서 감사합니다.

2020년에도 Let's Coding !