2019년 회고와 이력서
2020년을 앞두고 이력서를 업데이트했다.
한 해 동안 달라진 이력과 기술을 정리하기 위해 매해 연말에 해오던 일이다. 공개적으로 이력서를 공개적으로 개제한 건 처음이다. '연말 회고록'을 따로 작성한 적은 없었다. 이력서를 업데이트하면서 회고하는 시간을 가져왔다. 이력서를 보면서 카테고리별로 회고를 해보려 한다.
익명의 개발자
대한민국 서울
Telephone: 비공개
E-mail: 비공개
Github: 비공개
Blog: https://brunch.co.kr/@anonymdevoo
요약
A년차 웹 개발자; 주도적인 성향; 우선순위를 정하고 일하기 선호; 자동화 추구; 치열한 토론에 긍정적 성향
이력 & 학력
201D 년 ~ 외국계 게임 회사 - 개발자
201A 년 – 201C 년 지거국 대학원 (컴퓨터 계열 전공)
200D 년 – 201A 년 지거국 학부 (상경 계열 전공)
언어
N개 국어 가능 모국어 수준의 한국어, 유창한 영어, 초보 수준의 스페인어
추구하는 개발자로서의 가치
기술 분야의 폭을 넓힐 수 있는 포지션 추구
테스트, 빌드, 배포, 단순 반복 작업의 '자동화' 추구
긍정적 태도를 가지고 비판적 사고를 가진 동료들과 함께 코드를 작성하고 리뷰하기
기술 요약
개발언어: Java(주요), JavaScript
프레임워크: Spring 5/Junit, ReactJs/Redux/Jest
중요하게 생각하는 개발 가치: 테스트 코드, 읽기 좋은 코드, CI/CD, 자동화
최근 활용 도구: K8S, MongoDB, Apache Kafka, Redis, Jenkins, AWS services
선호하는 IDE: IntelliJ
운영체제: Linux/Unix, Windows
개발 이력
쿠버네티스를 활용한 서비스 환경 셋업 자동화
Oct 2019 – Nov 2019
#자동화 #Kubernetes(+skafffod) #AwsEKS #Docker
AWS EKS 클러스터 셋업과 종료 자동화
스토리지 셋업, 데이터 마이그레이션 자동화
다수의 애플리케이션 빌드와 배포 자동화
반응형 모바일 웹앱
June 2019 – Sept 2019
#Spring #React/Redux #ResponsiveWeb #Figma
HTTP API 서버 구현 (spring-boot 2.X)
React.js를 활용한 반응형 웹페이지 구현
Storybook + Figma를 활용한 프로토타이핑과 디자인 협업
홈페이지
Mar 2019 – May 2019
#React #Storybook
React.js를 활용한 PC버전 홈페이지 구현
Stakeholder 요구사항 정리 + 커뮤니케이션
실시간 사용자 이벤트 처리 시스템
June 2017 – Nov 2018
#SpringReactor #Kafka #Redis #MongoDB #AWS #DataBricks(Spark Scala) #Tableau
Established MicroService Applications in AWS
메시지 큐를 활용한 사용자 이벤트 처리(Apache Kafka) 일일 최대 108,667,050 건
인메모리 캐시(Redis)를 활용한 사용자 세션 관리
Databricks + Tableau를 활용한 이벤트 통계 서비스 구현
레거시 홈페이지 기술 개편
June 2018 – Nov 2018
#ClassicAsp #ReactJs #Spring
Classic Asp 뷰를 React.js로 코드 전환
데이터베이스 CRUD 연산 코드를 백엔드 서버로 분리(Spring)
2019 개인 프로젝트/이력
Git & Github 대학 강의
Mar 2019(봄 학기), July 2019(계절학기)
#VCS #Git #Github
Git과 Github을 활용한 소프트웨어 버전 관리 + 협업 방법 강의/실습 진행(4~8 시간)
강의자료: https://brunch.co.kr/magazine/gitandgithub
주가 예측 모델 개발
Dec 2018 – Feb 2019
#Tensorflow #Python #Jupyter-notebook #RNN
주식 종목의 일별 종가와 거래량 변화 트렌드를 학습
학습된 모델을 가지고 미래의 주가 예측 시도
알카노이드 슈팅 게임 만들기
Mar 2019 – May 2019
#Unreal #C++ #Spring
언리얼 엔진(c++)으로 클라이언트 구현
Spring으로 게임 서버 구현
추구하는 개발자로서의 가치에 대한 회고
2020 이력서를 업데이트하면서 개발자로서 추구하는 가치들을 추가했다. 개발자로서 어떤 부분에 중점을 두고 있는지 고민할 필요가 있다고 생각했다. 그리고 그 가치에 맞는 2019년을 보냈는지 회고해보려고 한다.
기술 분야의 폭을 넓힐 수 있는 포지션 추구
현재 본인의 경력을 고려했을 때 특정 분야에 제한되지 않고 기술 영역을 넓히고 싶다. 현재도 백엔드 서버 개발에 초점을 맞추고 있지만 '웹 개발'이라는 보다 큰 그림에서 프런트엔드 개발에도 관심을 갖고 참여하고 있다. 특히 2019년에는 이 전해에 비해 프런트엔드 개발에 주도적인 역할을 담당해서 참여한 프로젝트가 많았다. 개발/빌드/배포 환경 세팅도 개발의 처음과 끝을 담당하는 중요한 분야라고 생각한다. 중구난방으로 개발하면 '이도 저도' 아니게 된다고? 맞는 말이다. 하지만 웹 개발이라는 관점에서 더 크게는 개발이라는 관점에서 큰 그림을 볼 수 있는 안목을 갖출 때 더 날카로운 디테일을 만들 수 있다고 생각한다. 특히 경력이 짧은 본인에게 꼭 필요한 소양이다. 아! 물론 주력해야 할 전문 분야는 반드시 계발해야 한다.
테스트, 빌드, 배포, 단순 반복 작업의 '자동화' 추구
'자동화'하면 '편함'이라는 단어가 떠오른다. 자동화를 해두면 사람이 하던 작업을 컴퓨터가 해주기 때문에 편하다. 핵심은 "컴퓨터가 한다"이다(물론 편한 건 두말할 필요 없다). 컴퓨터는 오류, 버그를 만들지언정 실수를 하지 않는다. 하지만 사람은 오류나 버그를 범하기도 하지만 실수도 한다. 인간의 실수를 최소화할 수 있는 운영을 위해서 정기적으로 반복되는 작업이라면 자동화는 반드시 필요하다. 그 작업이 아무리 작고 단순한 작업일지라도(단순한 작업이라면 더더욱). 자동화를 하게 되면 자원을 다른 작업에 투입할 수 있기 때문에 시간/비용 관점에서도 생산적이다.
과거에 내가 자동화를 하지 않고 반복되는 작업을 직접 했던 이유는 뭐였을까? 부지런하기 때문에 내가 열심히 하고 싶어서였던 걸까? 아니다. 반대로 나태함 때문이었다. 지금 5분 만에 해서 치울 수 있는 일에 30분 혹은 한 시간을 투자하기 싫었기/귀찮았기 때문이다. 시간이 지날수록 투자하는 시간뿐만 아니라 스트레스와 실수도 누적되어갔다. 수작업 소요 시간이 짧다 해도 집중해서 하던 일 중간에 하게 되면 부담스럽고 스트레스받는 일이 된다. 작업의 능률과 생산성을 떨어뜨린다.
2019년에 자동화를 위해서 나는 어떤 작업을 했을까? 쿠버네티스를 활용해서 수작업으로 하던 개발 환경 세팅을 자동화하는 프로젝트를 진행했다. 현재 팀에서 운영하는 시스템은 N개의 서비스 + N개의 스토리지 + N개의 메시지 큐로 구성이 되어있다. 개발 환경 세팅을 위해서 한 땀 한 땀 N개 서비스를 빌드하고 띄우고 N개의 스토리지와 N개의 메시지 큐를 설치해야 한다.
기존에 시스템을 운영해오던 개발자가 아니라면 파악조차 힘든 작업이다. 정기적으로 라이브 배포 전에 라이브와 동일한 환경을 구성해서 부하 테스트를 해왔었다. 모든 세팅 작업을 수작업으로 했다. 테스트라는 게 그렇다? 불편하면 하고 싶지 않다. 그러면 "에이~ 이거 뭐 별거 아닌 변경인데 그냥 라이브 나가시죠?"하고 검증 없이 나가게 된다. 자동화를 한 후에 라이브 부하 테스트에 대한 거부감도 없어졌다. 편해졌기 때문이고 누구나 할 수 있게 됐기 때문이다. 스크립트만 실행하면 클러스터 세팅부터 빌드, 배포, 스토리지 설치까지 다 되니까.
긍정적 태도를 가지고 비판적 사고를 가진 동료들과 함께 코드를 작성하고 리뷰하기
2019년에 기술적으로 많이 성장했다. '팀 케미'가 좋았던 덕분이라고 생각한다. 본인에게 '팀 케미'가 좋다는 의미는 서로 대화/토론을 많이 한다는 의미다. 혼자 개발을 하게 되면 개인의 역량에 제한된 결과물이 나온다. 동료들과 함께 문제를 해결하는 과정에서 동료의 역량과 지식이 나의 역량이 되는 순간이 많았다. 동료들의 토론 태도가 긍정적이었기 때문에 보다 적극적으로 문제를 공유를 할 수 있었다. 반대로 내가 가진 지식을 공유하는데도 적극적일 수 있었다. 작업한 결과물을 주제로 두 차례 공유하는 시간을 가졌는데 보람도 느꼈지만 그 과정에서 개선점을 찾고 기술적으로 성장할 수 있었다. 앞으로도 팀케미가 좋은 환경에서 일하고 싶은 소망이 있다. 그렇기 위해선 내가 더 좋은 개발자가 돼야 하지 않을까? 하나 짚고 넘어가고 싶은 것은 "긍정적인 태도는 친절함과 무관하다."이다. 긍정적 태도는 '토론과 리뷰에 대한 긍정적인 자세'라고 생각한다.
프런트엔드 기술 회고
React.js를 프레임워크로 프런트엔드 개발에 활용한 지 2년 차가 됐다. React.js를 기준으로 회고를 해봤다.
View를 구성하는 Component 단위에는 기준이 필요하다.
Page 단위로 존재하던 View를 단순하게 작게 나눈다고 생각했다. Component를 구현할 때 고려해야 할 점을 깨달았다. 0) 재사용/복제될 여지가 있는 View인가 1) View에 종속된/책임이 있는 기능(function)을 가졌는가. 2) 독립적으로 유지/보수받는 View 인가 3) 테스트 코드를 작성하기 좋은 Component인가
적합한 보조 개발도구를 활용하면 작업의 생산성과 결과물의 품질이 높아진다.
Component 단위로 개발할 수 있도록 도와주는 Storybook을 활용해봤다. Storybook은 Component를 격리된 공간에 띄워서 개발할 수 있도록 하는 UI 개발 도구이다. 위에서 언급했듯이 Component는 독립적인 View와 기능을 갖는 게 이상적이기 때문에 개발도 격리된 공간에서 독립적인 Component로 했을 때 개발하기 편리하다. 개발을 시작하기에 앞서 좋은 도구가 있는지 찾아보는 게 좋다.
기존에는 Page를 띄워두고 Component를 추가하면서 구현했다. 이 방법의 경우 개발하는 과정에서 0) Component 동일한 페이지에 있는 다른 Component에 의존성이 생긴다. 1) View가 필요한 값을 주입하기 위해 임의로 코드나 값을 수정해야 한다(개발 테스트가 끝나면 다시 돌려놓고). Component를 개발하고 테스트하기 위해 임의로 코드를 수정하고 돌려놓을 필요가 없다. 개발 테스트를 위해 임시 값을 정해서 주입해주면 된다. 순수하게 개발을 위해 Storybook 내에만 존재하는 값이기 때문에 Production 코드에는 영향이 없다.
프런트엔드도 테스트 코드를 작성해야 한다.
"응? 이게 뭔 삽소리지?"라고 생각하고 있다면 좋은 개발자의 조건을 하나 갖추신 거다. 본래 자바/스프링으로 서버를 개발하는 게 본업(?)이었다. 서버를 개발할 때는 꼬박꼬박 유닛 테스트 코드를 작성했었다. React.js 1년 차에는 부끄럽게도 테스트 코드를 작성하지 않았다. 자바의 JUnit 같은 테스트 유틸이 자바스크립트에도 있는지 조차 몰랐다.
프런트엔드 2년 차가 돼서야 정신 차리고 Jest를 활용해서 테스트 코드를 작성하고 있다. 프런트엔드 테스트 코드를 작성하고 나서야 작성하지 않고 개발했던 지난 시간들이 후회가 됐다. "아니? 프런트엔드는 눈에 잘 나오는 거 직접 확인하면 되는데 무슨 테스트 코드 쓰는데 시간을 써? 구현하기도 바쁜데?"라고 생각하실 수도 있다. 따로 공간을 할애해서 프런트엔드도 테스트 코드를 왜 짜야하는지 설명해보겠다. 결론만 말하자면 "테스트 코드를 활용하면 개발단계에서 하는 노가다 테스트보다 시간적으로 유리하다."이다. 테스트의 정확도가 높다는 건 두 말할 필요도 없다.
프런트엔드 기술에서 부족한 점이 너무 많아서 깨달은 점을 위주로 회고를 했다. 아직은 프런트엔드 기술에 대한 깊이도 얕지만 폭도 좁다. 2020년에는 프런드 엔드 기술의 폭을 넓히는 일에 집중하려고 한다. 내년 상반기에는 백엔드보다는 프런트엔드 개발을 위주로 참여할 작업이 많기 때문에 개선할 기회도 자연스럽게 생길 예정이다.
백앤드 기술 회고
2019년에는 백엔드 개발이라고 해봤자 프런트엔드 개발하면서 같이 한 'API 서버 개발' 정도가 다였다. 신규 개발보다는 기존의 백엔드 코드를 유지 보수하는 작업을 주로 했다. Spring Reactive API를 활용해서 구현했던 프로젝트를 개선하는데 중점을 둔 작업들이었다.
잘못된 API의 사용은 성능과 디자인을 망친다.
Spring 5가 정식 출시되기 전에 Reactor 프로젝트를 따로 임포트(Import)하는 방식으로 ReactiveAPI를 활용해서 개발한 프로젝트가 다수 있다(Spring5부터 ReactiveAPI를 지원하기 시작했다). Mono/Flux 클래스를 활용해서 data stream을 처리하는 방식이었다. 자료와 활용 사례가 부족한 시기였다. 실험적으로 적용을 해보다 보니 ReactiveAPI 이해 부족으로 인한 오류(?)가 있었다.
오류
0) Non-blocking API 내부에서 Blocking 함수 호출
1) map과 flatMap 구분 없이 사용 등등.
개선법 -> 결과
0) Blocking 함수 호출을 없애거나 Non Blocking 방식으로 수정했다. ->(결과) 성능이 올라갔다.(코드 깔끔 해진 건 덤)
1) 무분별하게 사용되던 flatMap을 목적에 맞게 map함수로 대치했다. -> 코드가 깔끔해졌다. (불필요하게 Mono/Flux를 생성해서 반환하는 부분이 사라졌다.)
프로그램은 불완전한 것이고 지속적으로 개선해야 하는 건 맞다. 활용하는 기술/API에 대한 이해가 구현하고자 하는 프로그램의 디자인에 끼치는 영향은 크다. 특히 프로그램의 개괄적인 디자인을 잡는 단계에서 끼치는 영향은 더 크다. 디자인을 바탕으로 기술을 선택하기도 하지만 활용 기술에 맞춰 디자인이 바뀌는 케이스도 있기 때문이다. 위에 사례처럼 지속적인 개선이 가능하지만 "개발 초기에 활용할 기술에 대한 정확한 이해가 있었다면 더 좋은 디자인을 설계할 수 있었을 텐데.", "중간에 포기했던 디자인을 적용할 수 있었을 텐데"라는 아쉬움이 있다. 코드를 수정하는 건 간단하지만 프로그램의 디자인을 재설계하는 건 쉽지 않은 작업이다(솔직히 얘기하면 쫄린다). 중간에 수정하는 방법도 좋지만 애초에 정확히 이해를 하고 활용하는 게 가장 이상적이겠다. 문서를 더 똑바로 읽어보자!
JDK13이 뭔지는 알고 있니?
JDK13이 나올 동안 JDK8의 지식에 머물러있었다. "아직도 JDK6로 개발한다고?"라고 얘기했던 적이 있었다. 정작 고여있는 건 다른 사람도 아니고 나였다. 문서조차 본 적이 없다. 왜 관심이 없었을까? "스프링 프레임워크가 곧 자바다."라는 안일한 생각을 가지고 있었던 거 같다. (2019년 기준) 최신 버전인 스프링 5의 JDK 최소 요구 버전은 jdk8이다.
스프링이 곧 자바고 자바가 곧 스프링인 세상?
틀린 말은 아니다. 지금 자바 생태계를 스프링이 독식하고 있는 건 사실이니까. "자바 따로 공부 안 해도 스프링 프레임워크에서 제공하는 API만 잘 따라가면 된다."라는 생각을 가질 수 있다. 스프링이 자바인 건 납득하지만 자바가 스프링인 건 아니다. 기억하자! "나는 스프링 프레임워크를 활용하는 자바 개발자이지. 스프링 개발자는 아니다." 스프링도 결국은 자바로 만들어진 사실을 인지하고 있다면 자바가 버전별로 어떻게 변했는지 훑어보기라도 하자.
2019 개인 프로젝트에 대한 회고
2019년 상반기에 열심히 하다가 하반기에 뜸했다.
쉬는 시간에 게임하는 게 즐거웠다. 게임만큼 코딩하는 시간도 즐거웠다. 다만 개인 프로젝트와 코딩에 강박관념을 가졌던 거 같다. 개인 프로젝트가 주말에 의무적으로 해야 하는 과업이라고 느끼는 순간이 있었다. 즐거워서 시작한 개발이 질리게 되면 어쩌지라는 걱정도 들었다. 개발을 더 즐겁게 하기 위해 2019 하반기에는 잠시 개인 프로젝트를 내려두고 따른 쪽을 쳐다봤다. 글을 쓰는 이유도 비슷한 맥락이다.
쉬는 시간을 가지니 개발하고 싶은 주제와 마무리 안된 프로젝트들이 하고 싶어 졌다. 2020년 개인 프로젝트를 단기간에 불타서 하지 말고 약불에서 1년 동안 조금씩 해봐야겠다.
Git과 Github을 가지고 버전 관리와 협업을 주제로 대학 강의를 했다.
두 개의 대학교에서 했다. 하나는 봄 정규학기에 2주간 8시간. 다른 하나는 이틀간 8시간. 버전 관리에 대해서 새롭게 공부했다. 수업을 준비하고 진행하면서 "할 줄 아는 것과 알고 있는 것에는 차이가 있다."에 대해서 생각을 했다.
'할 줄 아는 것'과 '알고 있는 것'에는 분명한 차이가 있다. 당연히 알고 있다고 생각하고 무의식적으로 해왔던 '할 줄 아는 나의 버전 관리'를 되돌아봤다. 학생들에게 설명하기 위해서 내 지식을 분류해봤다.
0) 명확하게 알고 있는 것
1) 알고 있다고 생각했지만 모르고 있던 것
2) 모르는 걸 알고 있었지만 찾아보지 않은 것
3) 전혀 모르는 것.
정리해놓고 보니 내가 알고 있다고 생각했던 것들 중 반절 이상은 1), 2)에 해당됐다. 부끄럽다. 수업을 준비하면서 1), 2)에 해당하는 지식을 0) 명확하게 알고 있는 것으로 바꿔갔다. 내가 명확하게 알아야 설명이 되니까. 어버버 하면서 "아... 이거 제가 아는데 설명하기가 어렵네요?"라는 한심한 소리를 하고 싶진 않다. 설명이 안되면 그건 모르는 거다. 아는데 설명이 안 되는 건 없다. 앞으로도 어중간하게 알고 있는 지식에 대해서 되짚고 갈 필요가 있을 거 같다. 2020년에도 교육이나 공유 세션에 참여해서 내 지식을 다지는 기회를 의도적으로 만들어야겠다.
주가 예측 모델 개발
2019년 초에 주식 투자에 관심이 생겼다. "주가 변화에도 패턴이 있지 않을까?"는 호기심을 가지고 패턴을 예측할 수 있는 모델 개발을 시도해봤다. 주식 투자도 그냥 하면 재미가 없으니까 개인 프로젝트로 시작을 해봤다. 결과는? 실패. 우선 트레이닝하는데 시간도 오래 걸리고 빡세다. GPU를 빡세게 몇 날 며칠을 돌려보니 어느 순간부터 그래픽카드에서 '끼익 끼익'하는 소리가 들리기 시작했다. 컴퓨터 자원의 한계가 있다 보니 트레이닝한 표본의 숫자도 부족하다 보니 정확도도 낮았다. 그래도 재밌었다. 척척박사님들이 입으로만 털던 머신러닝을 직접 해봤으니까.
가장 뿌듯한 건 '수학1'도 제대로 못한 수 알못 문돌이 주제에 말로만 듣던 미분/적분을 이해해서 수식을 사용했다(물론 수식을 내가 짠 건 아니고. 누가 만든 거). "이 정도면 나도 이과라고 할만하겠는데?"라는 말 같지 않은 생각을 잠시 했다. 잠시 내려놨지만 2020년에는 새로워진 텐서플로우로 새 출발해봐야겠다. 최근에 '쿼터백'이라는 로보 어드바이저 서비스를 이용해서 자산 관리를 시작했다. 겸사겸사 투자하면서 좋은 공부가 될 거 같다.
알카노이드 슈팅 게임 만들기
친구와 같이 한 프로젝트였다. 중간에 중단됐지만 유익한 경험이었다. 나는 C++을 공부하고 싶어 Unreal 엔진으로 클라이언트를 개발했다. 친구에게는 '스프링 프레임워크' 사용법을 가르쳐주기 위해 게임 서버를 개발하도록 했다. C++로 개발해 본 경험이 전무한 나에게 좋은 시작이었다고 생각한다. 다시 한다 해도 나 혼자 할거 같으니까 서버도 C++서버로 바꿔서 해볼까 한다. C++ 매력적인 언어다.
마무리
2020년에는 글 쓰는데 집중을 해서 내가 가진 기술과 지식을 정리하며 시간을 가질 계획이다. 위에서 얘기했듯이 어중간하게 알고 있는 '잡지식'들을 명확히 아는 '지식'으로 만들어야겠다.
