2017년 회고
가장 많은 성장을 한 해
내년 2월이면 만4년, 즉 5년차 개발자가 된다.
국비교육센터에서 처음 Java를 배울때만 하더라도 5년차가 되면 세상 모든걸 다 알것 같았지만, 막상 그때가 오니 다 알기는 커녕 내가 이런것도 몰랐구나 라는 것만 매번 깨닫게 된다.
SI에서 1년, 줌인터넷에서 2년, 그리고 현 회사인 우아한형제들에서 1년을 근무하면서 올해가 가장 많은 성장을 한것 같다.
그래서 2016년 회고때보다 쓰는게 더 어려웠다.
하나하나 정리하면서 "엇 이것도 올해했던 거구나" 했던 내용들이 많았다.
매년 회고를 남기다보면, 나중에 돌아봤을때 당시 했던 일들이 어떤 영향을 끼쳤는지 알수있지 않을까란 생각에 작성하게 되었다.
회사
2016년 12월 26일부터 우아한형제들에서 개발을 하게 되었다.
이전 회사에서 하던것과 전혀 다른 도메인 (포털의 메인페이지 -> 푸드 커머스의 결제/정산) 으로 전환하다보니 정신없이 시간이 흘러갔다.
기술도 기술인데, 도메인이 완전 달라서 용어/정책 등을 이해하는데 너무 힘들었다.
회의 내용이나, 선임님께 여쭤볼때마다 에버노트에 기록 하는수밖에 없었다.
에버노트 기록들그 얘기가 다 그 얘기 같았는데, 그래도 계속 기록하고 자주보니 조금씩 이해가 되기 시작했다.
가끔 "이정도 내용은 머릿속에 넣으면 되지" 라고 방심했다가 나중에 생각안날때가 몇번생기고 나서는 무조건 기록하는 중이다.
이젠 홀로서기를 해야되서 부담되긴 하지만, 열심히 기록하고 복기하는 수밖에 없을것 같다.
1. 신규 정산 플랫폼
기존에 PHP & 쿼리 중심의 정산 플랫폼을 Java & ORM 위주로 새롭게 구축하는 프로젝트에 참여했다.
이 프로젝트 덕분에 ORM/객체지향/테스트코드 등 겉핥기 식으로 알고 있던 지식들을 제대로 정리할 수 있었다.
정말 좋았던 점은 실제 돈이 오고가는 프로젝트다보니
덤벙대는 성격과 습관을 고칠 수 있는 좋은 기회가 되었다.
1원이라도 차이나면 큰일이기 때문에 데이터 검증시에는 샘플링 하지 않고 스크립트를 작성해 전체 데이터로 검증했다.
테스트 코드도 훨씬더 많이 작성하게 되었다.
특히 Spock덕에 다양한 케이스를 하나의 테스트 코드로 해결할수 있어 부담이 덜했다.
이렇게 하고, 마지막 날까지 데이터가 다 맞았을때는 쾌감이 어마어마했다.
8월에 오픈하고 여태 시스템상 문제로 장애가 없었던걸 생각하면 프로젝트 기간동안의 검증이 잘됐던것 같다.
(장애는 역시 사람이 내는 것임을 다시 한번 깨달으며..)
2. 신규 SAP 연동 시스템
정산 플랫폼이 끝나고, 사내 전체적으로 SAP 시스템 개편이 진행되었다.
기존 업무가 계속 있어서 11월부터 회의에 참석했는데, 12월 중순에 1차 시연을 한다고해서 살짝 당황했다.
(기존 업무도 하면서) 대략 16개 정도의 배치를 만들었어야 했는데
서로 다른 테이블에서,
서로 다른 주기와 조건으로,
서로 다른 전달 방식으로 구현해야 했다.
처음에 문서를 보고 16개를 다 따로 만들어야하나 생각하다가, 모듈을 어떻게 잘 발라내면 앞으로 SAP 관련 배치가 추가되도 쉽게 추가할 수 있는 플랫폼처럼 될수 있지 않을까 싶었다.
개발자로서의 욕심과 한정된 기간이 부딪치다보니 중간에 스트레스도 엄청 받았다.
(우리팀이 선봉격으로 진행하다보니 스펙논의 & 변경/API 삽질의 여파를 그대로 맞았던것도 한몫했다.)
그래도 이 프로젝트가 좋았던 건
SpringBatch와 테스트 코드에 대해 정말 많은 연습이 되었다.
최선의 코드는 아니겠지만, 나름 한정된 자원내에서 좋은 코드로 만들기 위해 고민하고 노력했었던거라 내년에 꼭 이 내용을 정리할 계획이다.
정리하고 공유하면 좀 더 좋은 방법이 떠오르지 않을까 내심 기대된다.
3. 배운점
좋은 팀원들을 만나 제대로된 백엔드 개발환경을 경험할수 있었다
Gralde 멀티 모듈, JPA , SpringBatch, 테스트코드 등 배운게 너무 많았다.
특히 기억나는 에피소드가 있다.
팀내에서 IntelliJ 디버깅에 관해 발표를 한 뒤, 팀장님이 이런 이야기를 해주셨다.
테스트 코드를 많이 짤수록 디버깅 기능을 안쓰게 되요
당시엔 잘 이해를 못했었는데, 시간이 지나 계속 테스트 코드를 짜다보니 진짜 디버깅 기능 쓸일이 거의 없어졌다.
그래서 최근엔 의도적으로 디버깅 기능을 안쓰려고 한다.
오작동 하는 코드가 있으면 습관적으로 Break Point를 걸지 않고, 해당 코드외 다른 코드를 Mock으로 다 발라내서 검증한다.
올 한해 얻은 가장 좋은 습관이라고 생각한다.
정말 이팀에 오길 잘했다고 생각한 한해였다.
오픈소스
2개의 오픈소스를 만들고 1개의 공용 저장소를 생성했다.
https://github.com/jojoldu
http://rankedin.kr/user/jojoldu작년부터 내 이름으로 된 오픈소스 하나를 출시하고 싶다는 갈망이 있었다.
오픈소스를 만들자! 라고 할때는 주제 잡기가 어려웠는데,
내가 필요한걸 만들자! 라고 하니 만들게 많았다.
다행스럽게도 만들고나서 6개월이 넘어서도 여전히 잘쓰고 있어서 앞으로도 시간될때마다 계속 업데이트할수 있을것 같다.
1. markdown-tistory
nodejs 패키지로 markdown-tistory를 출시했다.
티스토리가 마크다운을 지원하지 않아 마크다운으로 글을 작성하고 git push -> Github에서 랜더링된 HTML 코드 복사 -> 티스토리 붙여넣기 과정이 필요했다.
이 과정도 짜증났는데, 추가로 몇가지 문제가 발생한것이
티스토리 커스텀 스킨과 랜더링된 Github HTML의 inline style이 css 충돌이나서 화면이 다 깨져버린다.
이미지 도메인이 Github이라 티스토리에서 이미지를 제대로 사용하지 못했다.
특히 2번 문제가 심해서 HTML 코드를 복사후, 이미지만 별도로 다시 올리다보니 생산성이 너무 떨어졌었다.
그래서 더이상은 안되겠다 싶어 nodejs로 이 과정을 자동화하는 스크립트를 만들었다.
Java와는 다른 재미가 있어 nodejs 테스트 코드도 추가하고, 구글광고 코드를 원하는 위치에 넣을 수 있는 기능도 추가했다.
electron 등으로 전용 에디터도 만들까 하다가, IntelliJ, VS Code 등의 에디터로 마크다운을 작성하는 것보다 기능이 좋을것 같지 않아서 그건 포기.
대신 IntelliJ, VS Code의 플러그인 정도로 개발해서 편집기 내에서 바로 포스팅 하는 정도로 (마치 Git Push 하듯이?) 진행할 계획이다.
2. Intellij 번역 플러그인
IntelliJ 계열의 IDE에서 모두 사용할 수 있는 번역 플러그인을 만들었다.
변수명, 메소드명, 주석해석등이 필요할때마다 번역 웹페이지로 화면전환 하는게 굉장히 흐름을 끊는 행위라 이를 지원하는 플러그인 개발을 진행하게 되었다.
한글 자료가 많이 없어서 삽질도 정말 많았고, 업무에도 별로 도움 되는 일이 아니라서 중간에 포기할뻔도 했었다.
그래도 웹 개발만 계속하다가 PC 어플리케이션 개발을 하니 생각보다 재미있어 끝까지 할 수 있었다.
특히 비동기 코드를 작성할 수 있는 좋은 기회였다.
PC 어플리케이션에선 동기 코드로 작성하면, 외부 API와 통신 하는 동안 IDE가 멈춰버리니 외부 자원을 이용하는 모든 코드가 비동기로 되어야만 했다.
단순히 기술을 위한 기술이 아니라, 제품을 위해 기술을 사용하게 되서 기쁘고, 실제로 출시까지 할 수 있어서 너무 행복했다.
최근엔 다른 개인 프로젝트로 업데이트가 안되고 있었는데, 곧 다시 시작할 예정이다.
추가로 Jetbrains 플러그인 개발 하는 방법도 포스팅해야겠다.
3. 주니어 개발자 취업 정보
주니어 개발자를 위한 취업정보를 모은 Github 저장소를 개설했다.
개인적으로 취업이란 컨텐츠에 굉장히 관심이 많다.
대기업이 아닌 실력 쌓기 좋은 회사,
개인의 경험이 담긴 취업 후기와 노하우,
실제 현업 선배님들의 현실적인 팁 등등
이런 정보들이
아는 사람들 사이에서만 오고가는게 굉장히 불편했다.
많은 주니어 개발자들이 좋은 회사를 선택할 수 있고, 안좋은 회사는 그걸 보고 개발환경을 개선하길 바라는 마음에 몇가지 기준을 두고 양질의 취업정보를 저장소에 모으기 시작했다.
복지가 좋은게 아니라, 실력을 쌓기 좋은 회사에 갈 수 있는 팁들특히 이 저장소는 나혼자만 진행한게 아니라 여러 사람의 Contribution으로 운영되어서 좋았다.
저장소의 Special Thanks31명의 기여자 분들로 인해서 좀 더 양질의 정보가 빠르게 모아졌다.
내년엔 저장소 형태를 개선해서 더 좋은 서비스로 확장할 계획이다.
(챗봇, 뉴스레터 등등)
구직자분들이라면 꼭꼭 주니어개발자 채용정보 저장소를 잊지마시고 방문해보시길 추천드린다.
사이트
개인적으로 운영하는 플랫폼 3곳과 최근에 출시한 서비스가 있다.
블로그
올 한해는 세미나 후기 보다, 기술적인 내용들에 중점을 맞춰서 정리했다.
특히 생뚱맞은 기술, 겉핥기식 튜토리얼, 트렌드에 쫓긴 지식등은 의도적으로 피했다.
대부분의 기술 포스팅이 업무에서 쓴/쓸 기술이 중심이였다.
http://jojoldu.tistory.com/회사의 기술 스택을 공부하고, 이를 직접 제품에 반영하고, 운영하는 경험이 쌓이니 내껄로 만들수 있었다.
(100%는 아니지만...)
업무와 관련된 기술 외에 다른걸 학습하면 결국
제품에 써볼 기회가 없어 내껄로 만들수 없었다.
그래서 더더욱 업무에 관련된 것만 공부하려고 노력했다.
올 한해에만 14만명이 방문해주셨다.
작년엔 200~500였던 하루 PV가 올해는 500~900 사이로 증가했다.
특히 기존에 세미나 위주로 발생한 PV가 구글 기술 검색으로 PV가 증가해서 더 좋았다.
내년엔 좀 더 기술 블로그로서의 위치를 잡고 싶다.
브런치
티스토리와 Github에서 기술적인 내용만 다루고, 개인적으로 쓰고 싶은 비 개발 이야기는 브런치를 통해서 쓰기 시작했다.
지금 쓰고 있는 이 글까지 포함하면 올 한해 8개의 글을 썼다.
확실히 비 개발자분들이 글을 쓰기에 더할나위 없는 플랫폼인것 같다.
앱의 사용성이나 모바일 UI, 에디터 기능등 기존 블로그 플랫폼에 비해 우위에 있다고 생각한다.
매월 1개의 글은 쓸수있지 않을까 했는데, 생각보다 월 1회도 쉽지 않았다.
브런치는 특별히 내년에 목표를 잡진 않았다.
"올해 월 1회를 달성하지 못했으니 내년에는 월 1회를 하자" 이런게 없다.
퇴근하는 지하철에서,
샤워하다가,
침대에 누워 잠들기전에
갑자기 쓰고싶은 이야기가 생길때 쓰다보니 그런 수치에 얽매이지 않기로 했다.
티스토리와 Github에는 포스팅에 강제성을 부여하고 있지만,
브런치에서만큼은 내가 쓰고 싶은 때에, 쓰고 싶은 이야기를 남기려 한다.
페이스북
운영하는 초보개발자모임 페이스북 페이지가 급성장했다.
작년에 1800분이 좋아요를 해주셨는데, 현재 약 3500분이 좋아요를, 3700분이 팔로우를 해주고 계신다.
다른 페이스북 그룹에 페이지를 홍보한것도 아닌데 2배나 성장해서 정말 감사할 따름이다.
페이지 규모가 3천명이 넘으니 몇번의 광고 요청도 왔었다.
다만, 양질의 정보만 전달드리는 페이지이니 내가 모르는 회사, 제품에 대해선 전혀 홍보할수가 없었다.
내년에 5천명 정도가 되면 단일 개발 관련 페이지로는 꽤 규모가 커서 이런저런 이벤트를 할 수 있을것 같다.
페이지 방문해주신 분들 덕분에 계속 열정을 유지할 수 있었다.
꼭 감사한 마음을 돌려드릴만한 이벤트를 유치할 예정이다.
블로그 & Github & 브런치 & 페이스북 & 웹페이지가 동반성장하다보면 나중엔 뭔가 재밌는 일이 생기지 않을까? 기대중이다.
초보개발자모임 뉴스레터
샤워하던 도중 문득 이런 생각이 들었다.
회사가 아닌 나는 얼마나 대규모 트래픽을 처리할 수 있을까?
이걸 확인하기 위해선 나만의 커뮤니티 혹은 웹서비스가 있어야 겠다고 생각했다.
(요 과정은 별도로 정리할 예정)
어찌됐든 이런 이유로 초보개발자모임을 주제로 한 웹 서비스를 출시해야겠다고 생각했다.
헌데 커뮤니티 서비스를 바로 만들자니 부담이 되었다.
예전에도 몇번 커뮤니티를 만들려고 하다가 실패한 경험때문이다.
이기능/저기능을 다 구현해야할것 같고,
이왕할거 최신의 기술 스택으로 구현하고,
여러 정책을 다 고려하는 등등
출시는 커녕 제품완성 조차 못하고 중간에 좌초되었었다.
그래서 좀 더 기능이 단순하지만 제품으로서의 기능을 할만한 주제가 없을까 계속 고민했다.
출처: https://dribbble.com/shots/1753131-MVP그러다가 생각노트의 뉴스레터 글을 보게 되었다.
"이거다!" 라는 생각이 들어 11월 말부터 바로 작업에 들어갔다.
11월 말에 시작하다보니 내년 초에 출시하는걸 목표로 할까 하다가,
그렇게 어영부영하다가 또 한해가 지나갈것 같아 무조건 12월안에 출시하는걸 목표로 했다.
기간이 짧으니, 집중해야할 기능에만 집중하게 되었다.
백엔드 기술 스택은 견고하게 가되, 프론트엔드 기술 스택은 jquery로 다 처리했다.
(웹팩, ES6, Mocha, JS 프레임워크 등 다 구축하고 시작하면 시간 다간다.)
기능도 뉴스레터 등록/발송 외 관리자페이지는 최대한 심플하게 구현했다.
배포자동화는 TravisCI, AWS CodeDeploy로 처리했다. (젠킨스 구축할 시간 따위...)
단, AWS 와 연동해야할 API들은 전부 Gradle Sub Module로 분리해서 구현했다.
(EMail, S3 업로더 등)
그리고 12월 22일에 서비스를 출시하게 되었다.
(코드는 Github에 공개된 상태이다.)
25일에 첫 뉴스레터를 발송하게 되었다.
현재는 116분께서 구독중이시다.
매주 월요일 초보개발자모임의 한주간 소식을 뉴스레터로 전달드린다.
페이스북에서 너무 빨리 소식이 지나가 놓치신 분들에게 적합한 서비스라 신청해놓으셔도 좋을것 같다.
내년엔 이 뉴스레터 서비스를 기준으로 계속해서 기능을 확장해나갈것같다.
언젠간 커뮤니티 혹은 웹서비스처럼 되지 않을까 기대된다.
일일커밋
드디어 일일커밋을 1년이상 유지할 수 있게 되었다.
365일을 달성한건 11월이였는데 Github에서 365+7 일까지의 데이터만 제공해서 계속해서 365~372 사이만 데이터가 출력되서 아쉽다.
업무시작전에 1시간 코딩한걸 커밋하고, 퇴근후에 2~3시간 하던걸 커밋했다.
그러다보니 커밋 단위가 좀 엉망이다.
(커밋 단위가 이러면 안됩니다.. ㅠ)
그래도 어뷰징 하지 않았던 것만으로도 만족한다.
커밋한 일수에 비해 횟수는 적어서 생각보다 커밋은 많이 안했구나 라고 반성하게 되었다.
일일커밋 하는 이유에 대해선 이전에 쓴 글이 있어서 한번 보시면 좋을것 같다.
많은 분들이 일일커밋에 대해서 회의적이시겠지만, 나에겐 최고의 게임이다.
예전에 온라인 게임에 중독되었을때는 마음속 죄책감이 있었지만,
이건 전혀 죄책감이 없는 중독이라 아낌없이 빠질 계획이다.
개인학습
8월에 CTO님의 요청으로 사내 개발자들이 이력서를 작성하게 되었다.
당시에 이력서를 작성하면서 2017년 하반기 목표로 잡았던것이 2개가 있었다.
DB와 인프라를 의도적으로 공부하는 것이다.
쿼리튜닝
전 직장인 줌인터넷에서 근무할때는 메인페이지를 담당하다보니 캐시 전략/장애 전파 최소화/페이지 로딩속도 개선 등에 관심을 많이 가졌었다. (데이터 조회는 이미 API 레벨에서 다 처리되니..)
그러다 현 회사로 오면서 정산 플랫폼을 담당하다보니 관심사가 완전히 바뀌었다.
Table당 1억건이 넘는 상황에서 어떻게 Index를 태우고, 어떻게 조회쿼리를 작성할지가 굉장히 중요해졌다.
그동안 쿼리에 관해서 전혀 신경안쓰고 개발하다보니 여기와서 DB 조회 코드를 작성하는데 완전 고역이였다.
아무리 ORM을 사용하고 Querydsl을 사용하더라도
결국 결과물은 쿼리이다보니 쿼리 튜닝은 피할수 없는 문제였다.
막연한 두려움이라는게 결국 잘모르니깐 생기는 것이라고 생각했다.
마침 패스트캠퍼스에서 SQL 튜닝 캠프 과정을 개설해서 바로 신청했다.
과정에서의 좋았던 점은
RDBMS의 조인/인덱스 처리과정, 트랜잭션 롤백 과정, 전체 구조 등등에 대해 기초를 잡을 수 있었다는 점이다.
안좋았던 점은
Oracle DB를 기준으로해서 실행계획 관해선 전혀 참고할수가 없었고,
모든걸 다 쿼리로 해결하는 내용이라, Java, PHP 등 어플리케이션 코드는 그냥 데이터 통로 역할만 하는 이야기를 해주신 점이다.
개인마다 기준이 다를수 있지만, 위 장점만으로 130만원의 수강료가 아깝진 않았다.
(수강 내용 정리도 할겸 MySQL에선 어떻게 되는지 궁금하기도 해서 포스팅을 쭉 했었다.)
의도적으로 팀내에 쿼리튜닝 캠프를 다니고 있음을 알렸다.
그래야 관련해서 일이 주어지지 않을까 싶었기 때문이다.
팀장님이 관련해서 기회를 정말 많이 주셔서 아직까지 감사한 마음이다.
아무래도 팀이 갖고 있는 데이터가 많아서 이것저것 실험도 많이 해볼 수 있었다.
운영 환경에 있던 1억건 이상의 테이블들을 dump 해서 직접 인덱스를 수정해가며 테스트 해보고,
조회쿼리도 바꿔보며 재밌게 실험했다. (관련된 포스팅)
그리고 실험 결과를 기준으로 팀장님께 보고 하고 실제 운영환경에 반영했다.
내가 변경한 인덱스가 실제 DB에 반영될때 정말 두근두근했다.
이 과정때문에 확신하게 된것은
공부한 것을 제품에 녹여야만 내것이 된다.
이거였다.
아무리 개인공부를 하더라도
실제 운영환경에서,
많은 데이터 속에서,
많은 사용자 속에서
써봐야 내것이 된다는 것이다.
내년에 신규 구축될 시스템이 AWS에서 진행될수도 있다고 해서 내년엔 개인학습으로 AWS를 진행할것 같다.
돈을 내서 빠르게 배우고, 실험하고, 회사에 적용하고, 운영하는 이 방식으로 내껄로 만들예정이다.
2018년도는?
위 회고글을 다시 보니 왜이렇게 길게 썼나 싶다.
간추린다고 간추렸는데 뭔가 주절주절 하게 된것 같다.
남들이 봤을때 가독성이 정말 떨어질것 같긴한데...
나중에 내가 다시 보기 위함이니 최소한의 내용은 남기는게 맞는것 같다.
확실히 CTO님이 말씀하신대로 6개월에 1번씩 이력서를 갱신하니 다음에 할게 선명하게 보였다.
하지만 반기가 너무 긴것 같다는 생각에 내년엔 분기마다 이력서를 갱신할 예정이다.
1분기
1분기는 할 일이 이미 거의 정해져있다.
초보개발자모임 뉴스레터 서비스 강화
2월 말에 용근님 우성님과 함께 재밌는(!?) 행사 개최 + XXX 가이드북 진행
3월엔 개인적인 사정으로 잠깐 쉬는 타임
2분기
2분기는 개인적인 기술 도전을 진행할 예정이다.
초보개발자모임 웹페이지로 큰 이벤트 주최하기
하는 이유는 간단하다.
현재 내 실력으로
서버자원 대비 트래픽을 얼만큼 감당할 수 있는지 확인해보고 싶어서다.
EC2 인스턴스 성능을 높이고, 서버수를 늘리는 걸로 해결하는 방법은 쓰지 않을거다.
그건 돈 있으면 다 하는거니깐.
내가 갖고 있는 꼼수나 아이디어, 경험으로 이정도 규모의 트래픽을 처리하기 위해 얼마만큼 서버의 성능을 써야할까 라고 궁금했던걸 실험해보고 싶다.
(개인 사비 많이가 들것 같아 꽁돈을 차곡차곡 모아야 한다.)
하고나면 할 이야기가 많아질것 같아 두근두근하다.
내년에도 하루하루 기대되는 날들이 될것 같다.
이제는 은퇴한 언니네 이발관이 5집 앨범을 내면서 했던 인터뷰가 생각난다.
(언니네 이발관 5집 앨범은 2000년대 100대 명반에서 2위로 선정되었다.)
보컬이자 리더인 이석원씨가 이번 5집 앨범을 소개하는데 이렇게 얘기했었다.
만약 어떤 커다란 정육면체의 원석이 있고 이걸 깍아야 한다고 할게요.
한번 깎으면 이쪽이, 또 깎으면 다른 쪽이 깎이다 보면 정육면체, 팔면체에서 정이백면체, 삼백면체가 되겠죠.
그렇게 깎고 또 깎으면 원형체가 되겠죠.
보통 대부분의 아티스트들이 원형체가 되기 전에 앨범을 발표해요.
그런데 저희는 이렇게 울퉁불퉁한 덩어리들을 완벽한 하나의 원형체로 만들기 위해, 조금이라도 아주 사소한 것이 보이면 끝없이 깎았어요.
집에 누워있다가도 이 얘기가 떠오르면 노트북들고 밖으로 나가게 된다.
나도 적당선에서 만족하는게 아닌가 싶었다.
시간이 아무리 많이 지나도 될 수 있을지 모르지만,
내년엔 좀 더 원형체에 가까워지길 바라며.
