2019 하반기 회고

(소라의 날개 33권 130p)

현재 속한 회사에서 가장 많은 변화가 있었던 2019년 하반기이다.
회사 자체의 변화가 아니다.
내 주변의 변화가 지난 3년중 가장 컸다.
그래서 평소 회고 보다 훨씬 스크롤 압박이 있다.

1. 회사

상반기 회고에도 작성했지만, 7월 1일부터 팀이 분리되어 내 역할이 변경 되었다.
크게 2가지 역할인데, 개발 파트 리드와 온프레미스 인프라 관리였다.

1-1. 팀 분리와 역활변경

개발 파트 리드를 하면서 그간 팀장님들이 이런 저런 결정들을 왜 하게 되었는지 조금이나마 이해할 수 있었다.
(속썩여서 정말 죄송한 마음도..)

계속 매니저 역할을 하다보니, 직접적으로 프로젝트에 관련된 개발은 좀 등한시 하고 코드 리뷰만 진행했었다.
그러다보니 코드 리뷰에선 보이지 않는 개발 환경 / QA 환경의 노후화가 진행되고 있다는 것을 모르고 있었다.

이를테면 이런건데,

• 어드민에 메뉴 하나를 넣기 위해선 코드 작업 외에도 부차적인 작업이 계속 해서 추가되고 있다는 것
• 기획자분들이 QA 해주실때 수동으로 엑셀에서 한땀한땀 풀어서 보고 있는 항목들이 계속 늘어나고 있다는 것
• 전체 테스트 코드의 시간이 계속해서 늘어나고 있다는 것
• 클래스, 객체간의 의존성이 자연스럽지 않고 완전히 꼬여있어 코드가 점점 복잡해지고 있는 것

등등 팀의 생산성이 계속 떨어지고 있었다.
이건 아주 천천히, 조금씩 떨어지다보니 계속해서 개발하던 사람들은 느끼지 못했다.
간만에 개발을 한 나는 아주 크게 실감할 수 있었다.
아주 작은 기능을 시간날때 진행하다가 이걸 발견하고선 진짜 위기감을 느꼈다.
팀이 망가지는 신호였다.

그래서 팀 주간 보고때 현재 위기 상황을 이야기 했다.
그리고 정해진 일정 사이에 어떻게든 이런 건들을 추가로 끼워넣어서 개선을 할당했다.

아직도 많이 남았다.
그래도 하반기에 진행된 개선건들로 인해서 전반적인 QA 환경이나 개발 환경이 조금 개선이 된건 확실하다.
사용하시는 분들이 확실하게 긍정적인 피드백을 줬고, 시간도 그만큼 단축 되었으니 말이다.

이걸 계기로 아무리 매니저 역할을 하고 있어도 급하지 않은 개발 건은 직접 해봐야 한다는 생각도 하게 되었다.
그래야 진짜 팀이 잘 관리되고 있다는 것을 알 수 있다.

직접 해보지 않으면 모른다.
보고만 받고 있으면 잘 돌고 있는 것처럼 보인다.
왜냐면 일정은 잘 지켜지고 있었고, 기능도 큰 문제 없이 계속 추가되고 있었으니 말이다.
하지만 점점 신규 입사자들은 개발하기가 어렵고, 뭔가 작은 기능이 나갈때도 많은 시간과 인력이 필요한 형태로 가고 있었던 것이다.

그럼 또 개편해야 한다.
개편하는 것 외에는 방법을 모르는 개발자, 개발팀이 될 수 밖에 없다.
오래동안 사용되는 소프트웨어를 만들고 관리하고 운영하는 방법을 평생 모를수도 있다.

어떤 기능을, 어떤 환경에서 진행할때 "어 이거 불편하다" 느낄 수 있어야 하는게 중요하다.
그걸 느끼냐 못느끼냐가 되게 중요한것 같다.
불편을 감수하는 부지런한 개발자는 팀에 필요 없다.

지금 본인이 선택한 그 방식을 신규 합류한 개발자분께 설명할때 부끄럽지 않는지 꼭 물어보게 되었다.

코드 레벨만 보는게 아니라, 전반적인 팀의 생산성 / 업무 프로세스 등 개선해야될게 너무 많이 쌓여있다.
내년엔 이 부분을 좀 많이 고쳐야할 것 같다.

1-2. 온프레미스 인프라 관리

정산이라는 도메인은 결제와 더불어 온프레미스 환경에서 사용되야한다.
다른 팀처럼 AWS를 쓸 수 있는게 아니다보니, 불편한게 한 두개가 아니다.
무슨 작업이든 쉽게 되는게 없었다.
특히나 디스크나 장비 쪽 관련된 장애가 발생하면 노답이다.

실제로 7월, 11월에 한번씩 DB 서버의 디스크 장애가 발생 했었고, 예비 DB장비가 없어서 이를 복구 하기 위해 안쓰던 WAS 장비를 DB 환경으로 설정해서 풀 백업받고 HA에 투입하는 작업이 있었다.
7월엔 다른 개발자분 (아래에서 언급할 호돌맨) 의 도움을 받았고, 11월에는 직접 다 진행했다.

2번이나 하고 나니 이젠 이런 작업들이 조금 익숙해져서 이후 12월에 신규 DB 장비 3대를 발주해서 DBA 분들의 도움을 받아 OS 설정부터 HA 투입과 복제를 진행했다.

이후에 취약점 인터뷰도 보고, 기존에 쉘로 되어있던 자동화 작업들을 앤서블로 하나씩 개선도 진행했다.
(전체 서버에 사용자 계정 추가하고 패스워드 만료시 변경하는 등)

그래서 올 하반기 내 블로그 내용들이 Spring 보다는 인프라쪽 주제가 더 많을 수 밖에 없었다.

그렇다고 해서 내가 뭐 이제 인프라 잘합니다 이런게 아니다.
SRE팀과 함께 일을 하면서 뭔가 실력의 밑바닥 다 보여주고 있는 중이라 부끄러운 일만 계속 생긴다.
그럼에도 지금 팀에 필요한 역할이기 때문에 계속 실력을 쌓아가려고 한다.

1-3. 페이스 메이커의 퇴사

이게 이번 하반기 회고의 최고 핵심이다.
3년간 함께 개발을 했던 호돌맨님이 퇴사를 하였다.

상반기 회고에도 언급했던 그 분이다.

어떻게 보면 내가 현재 회사에 대한 애정을 갖고 있는 가장 큰 이유가 사라진 것이다.

(밤새 DB 복구하고 퇴근하던 날)

(주말 개인 프로젝트하러 회사 왔다가 찰칵)

야구 선수 중에 오타니 쇼헤이 라는 선수가 있는데 (만다라트 계획표로 유명한 그 선수) 투수와 타자 모두 에이스 역할을 해서 별명이 이도류 라고 한다.

팀에서 함께 했던 호돌맨의 인상이 딱 이 선수 같은 느낌이였다.
백엔드 애플리케이션도 잘하는데, 인프라도 너무 잘하는 것이였다.

당시에 수십대의 결제/정산 온프레미스 인프라를 모두 호돌맨님이 관리중이였다.
DB 튜닝/장애대응/백업 및 복구/MHA/파티셔닝, IDC 인프라 튜닝/장애 대응, 보안 취약점 감사 대응 등을 혼자 다 했다.
매년 수조원의 거래, 월 4천만건의 결제가 발생하는 그 시스템을 말이다.

그래서 새로 합류하신 분들은 다 호돌맨님이 개발자가 아니신줄 알았다고 하더라.

데이터가 적고, 트레픽이 적을때야 Hello World 수준으로도 해결이 가능한데 이정도 규모에서 이렇게 안정적으로 DB와 인프라 모두를 관리하는 애플리케이션 개발자도 있구나 싶었다.

그래서 한번은 술자리에서 도대체 호돌맨님은 어떻게 인프라도 잘하시냐고 여쭤봤었다.
답변이 놀라웠던게, 전 회사에서는 백엔드 개발자가 개발/인프라 둘다 하는게 당연했다고 답변을 하시더라.
둘을 따로 분리해서 바라보는게 더 신기했다는 말도 덧붙였다.
자기가 인프라 잘한다는 이야기 듣게 될 줄 꿈에도 몰랐다는 말로 마무리하면서.

그래서 실제로 이 회사 출신 개발자분이 사내에 한분 더 계시는데 (호돌맨의 전 직장 사수), 그 분 역시 인프라와 보안에 대해 정말 깊게 알고 계시더라.
집에 몇백만원짜리 서버 (PC아니라 실제 물리 서버)를 두고 직접 렉 꽂아보고 관리하면서 논다고 들었다.
이 회사 분들을 다 알진 못하지만, 어떤 회사인지 정말 궁금했다.

뭔가 그간 갖고 있었던 백엔드 애플리케이션 개발자의 모델이 완전히 깨지게 된 계기가 되었다.

그래서 진짜 빨대 꽂아서 엄청 빨아먹어야겠다고 생각했었고, 실행에 옮겼다.
이분이 설명해줬던 내용들이나, 사용했던 명령어들은 다 에버노트에 기록했다.
사용했던 인프라 설정들이나 운영 작업들은 깡통 EC2에 직접 다 설치하고 테스트 해보면서 남기고 있었다.

근데 퇴사한다니.
이미 8월부터 주말에 커피마시면 자주 했던 얘기라 어느정도 마음의 준비는 하고 있었지만 그래도 충격은 충격이였다.

3년간 개발에 대해 같이 이야기를 나누던 분이 떠나니 어찌해야하나 싶었다.

나와 비슷한 연차, 비슷한 나이에 뛰어난 사람이 바로 옆에 있다는건 그 어느 것보다 강력한 자극제이다.
내가 굳이 마음먹지 않아도, 더 잘하고 싶은 생각을 매일 매일 하게 된다.

이런 큰 자극제가 사라진다는게 내년 최고의 고민이다.

이것 때문에 고민할때 주변에서 여러 조언을 해주셨는데, 그 중 하나가 혼자서 공부하면 되지 않냐라는 말이 제일 많았다.
그렇지만 이 말은 크게 도움이 되지 않았다.

혼자서 공부하면 되는데도 더 좋은 환경, 학군으로 이사가고자 하는 마음과 같다.

주변에 좋은 자극제들이 얼마나 많이 있냐가 그 사람의 발전에 큰 영향을 끼친다는 걸 계속 경험해왔다.
전 회사도 그랬고, 현 회사에서도 그런 경험을 계속 해왔다.

그래서 새 자극제를 만들거나, 자가 발전하거나 뭐 어떻게든 수를 만들어내야하는 과제가 생겼다.

후일담이지만, 호돌맨님 퇴사하실때 서비스 개발이 아닌 팀에서도 팀 이동 제안을 했었다. (서비스 개발팀에서도 당연 제시했고)
리얼 이도류….

2. 블로그

7월은 이미 상반기에 언급했으니 8월 ~ 12월까지의 지표만 뽑아보았다.

12월 기준으로

• MAU: 55,000
  • 7월 (45,000)과 비교해서 10,000 증가
• 월 PV: 219,000
  • 7월 (140,000)과 비교해서 79,000 증가
• 평균 세션시간: 2분 4초
  • 7월 (2분 20초) 와 비교해서 16초 감소
  • 체류시간이 계속 감소 중이라, 그만큼 글의 호흡이 짧아지고 있다는 신호라고 생각 된다.

아래에서 자세히 이야기하겠지만, 태용님 영상 덕분에 12월 지표가 말도 안되게 높게 나왔다.

그래서 이걸 기준으로 뽑으면 안되겠지만, 이때 방문 해주신 분들이 계속 재방문을 한다는 지표가 보여서 남기게 되었다.

왜냐면 일일 PV가 평균 1천명 이상 증가했기 때문이다.

일일 PV가 상반기에는 평균 5000정도였다면, 하반기에는 6000이상 나오고 있다.

영상이 나온지 3주가 지난 시점이라 더이상 유튜브의 효과는 없다시피한데, 그럼에도 이 수치가 계속 유지되면 고정된 수치로 봐도 되지 않을까?

실제 방문자수의 77%가 구글 검색을 통해 방문 하고 있다.
(Direct 수치가 10%인건 좀 놀랍다.)

페이스북 등을 통한 거의 어뷰징에 가까운 블로그 글 홍보를 하지 않는다는 점은 칭찬해주고 싶다.

나쁘다는게 아니라, 결국 특정 SNS 그룹에 홍보 하지 않으면 방문자 수를 유지할 수 없기 때문이다.

자생할 수 있는 기술 블로그이고 싶다.
그래서 최대한 구글 검색 방문수에 집중하고 싶다.

일단 내년 상반기에도 계속해서 수치를 지켜봐야 할것 같다.

2-1. 43개의 글

하반기 (7~12월까지)엔 총 43개의 글을 발행했다.

상반기 회고엔 6월까지만 측정했길래 여기서 7월 포함

• 7월: 7
• 8월: 11
• 9월: 7
• 10월: 5
• 11월: 6
• 12월: 7

하반기엔 Java / Spring 주제의 글이 부족했다.
아무래도 팀내 역할 변경 때문이라서 점점 공부해야할 기술들이 인프라/DB쪽이 더 많을 수 밖에 없었다.

미뤄둔 MariaDB 운영 시리즈들이 마무리가 안되고 있어 내년엔 빨리 마무리 짓고 올려야겠다.

그리고 사이드로 Jenkins에서 Teamcity로 이전하기 위한 작업을 진행중이다.

확정적으로 하는건 아니다.
개인적으로 생각하는 Jenkins 들의 단점들이 계속 보여서 다른 도구를 찾아보는 중이다.

팀에서 사용 중인 미들웨어들은 쉽게 변경해선 안된다고 생각한다.
그래서 사전에 개인 프로젝트와 블로그로 계속해서 따로 해보고 실제로 이전하는게 더 이득이라는 확신이 있을때 팀에 이야기해 볼 예정이다.

팀에서 반대하면 강요할 생각 전혀 없다.
회사와 팀은 나를 위해 존재하는게 아니다.

2-2. 200만 달성

2019년 11월 5일, 블로그 총 PV가 200만을 돌파했다.

GA 기준으로는 그 전에 돌파를 했는데, 그래도 블로그 공식 지표도 200만을 넘기는게 중요할것 같아서 11월 5일을 기준으로 하게 되었다.

• 2019년 3월에 100만 돌파
• 2019년 11월에 200만 돌파

4월 ~ 11월 동안 월 PV가 12~14만정도라서 얼추 8개월이면 100만씩 증가했다.

내년 1월 지표를 봐야겠지만, 월 PV가 16만정도만 되어도 6개월에 100만씩 증가한다.
그럼 1년에 약 200만씩 증가하는데, 총 PV가 1천만이 되면 정말 기분이 이상할것 같다.
그땐 뭔가 블로그에서 이벤트라도 해볼까 싶다.

작성된 글의 수는 계속해서 늘어나고 있지만 (한달에 6~8개정도?) 방문자 수가 그에 비례해 늘진 않았다.

Java/Spring 이라는 한정된 주제와 기본 문법에 가까운 기초적인 내용들은 없기 때문이지 않을까 싶다.

그래도 어뷰징에 가까운 포스팅은 하고 싶지 않으니 계속 이 기조를 유지 하고 싶다.

3. 오픈소스

3-1. 일일커밋 3주년

일일커밋이 3년 연속 진행되었다.
자세한 후기는 별도로 포스팅했다.

크리스마스, 신년에도 커밋을 했다.
언제까지 이 커밋이 끊기지 않을지 나도 궁금하다.

3-2. 함흥차사 Spring Batch 팀

Spring Batch팀이 얼마나 바쁜지 느낄수 있는 시간이였다.

Spring Batch 4가 나오기도 했으니 버그 수정이나 개선건이 많겠지만…
4월에 올린 PR과 10월에 올린 PR이 11월이 되어서야 확인 되고 라벨이 붙는건 조금 답답하긴 했다.

특히 4월에 올린 건은 JpaPagingItemReader 사용시 hibernate.default_batch_fetch_size 가 안되는 큰 버그(!?) 의 수정건이라 좀 빨리 봐주면 좋을텐데 싶었다.

개선건은 Batch 테스트 코드 작성하면서 매번 느끼는 불편함을 넣은거라 사실 개인적인 바램이긴 하다.

2020년엔 제발 반영되길!!

3-3. 수익 알람 Bot

인프런, 출판 등으로 인해서 매일 여러 사이트를 돌아다니며 수치를 확인하는 습관이 생겼다.
그러다보니 이걸 매번 웹 사이트에서 새로고침하면서 확인하는게 너무 불편하여 Teamcity & Spring Batch & Telegram 으로 알람 Bot을 만들었다.

일단은 RDS에 쌓고 알람만 보내고 있는데, 현재 Vuejs로 어드민도 만들고 있다.
어드민의 기능이 어느정도 완성되면 저자 혹은 인프런 강사님들이 사용하실 수 있게 Open할 예정이다.

4. 외부 활동

올해 하반기는 평소보다 많은 외부 활동이 있었다.
내년엔 좀 자제해야지 싶다.

4-1. 출간

2019.11 프리렉과 함께한 스프링 부트와 AWS 책이 출간되었다.
자세한 출간 회고는 이미 블로그에 썼으니 출간 회고 이후 ~ 2019 하반기 회고 사이에 있었던 일만 쓰면 될 것 같다.

2019년 12월 9일 교보문고 1위 달성!

하루 천하였지만 ㅠ
그래도 2019년 12월 9일, 딱 하루 교보문고 1위를 달성했다.
(Yes24는 2위까지밖에 못해봤다 ㅠ)

지금은 10등 밖에서 왔다갔다 한다.
엑셀,파이썬,정보처리기사는 너무나 강력하다.

수많은 오타 제보와 질문

1쇄가 빠르게 나간만큼 많은 오타 제보와 질문이 왔다.

130개에 가까운 issue가 올라왔는데, 이 중 책 오류나 오타에 대한 제보도 많았지만 실습이 안되어서 질문을 올리신 것들이 많았다.

실습형 책들의 어려움을 절실히 느낄 수 있는 시간이다.

특히나 로컬에서 애플리케이션만 실행하는 것과 다르게 직접 리눅스 서버에서 명령어를 날리고, AWS agent 로그를 보는 등등은 처음 하는 분들에겐 큰 허들이였던 것 같다.

그래도 다행히 Github issue를 이용하다보니 많은 분들이 기존에 올라온 질문을 검색해서 자체적으로 해결하신다는 건 좋았다.

결국 이 책의 목적은 처음 시작하는 분들이 백엔드 개발에 대한 전반적인 감을 익히는것이기 때문이다.
기본적인 틀을 제공해드리고 Github issue를 검색하고, 구글링하는게 자연스레 되시기를 바래본다.

4-2. 태용님 채널 인터뷰

태용님이 운영하시는 유튜브 채널에 인터뷰를 진행 했다.

(하루키의 법칙은 민망했지만 ㅠ)

미용실에서 이발을 하던 중에 태용님의 페이스북 메세지를 받았다.

이미 스타트업씬에선 너무 유명하신 분이기도 하고, 계속 태용님 영상 보면서 자극을 받던 입장에선 메세지 주신것만으로도 놀라운 일이였다.

예전에 태용님이 사내 개발자이신 민태님을 인터뷰 하셨는데 이때의 인연으로 이번 인터뷰의 추천을 해주시게 되었다고 하셨다.

이 자리를 빌어 민태님께 다시 한번 감사의 말씀을 드리고 싶다.

뭔가 흑역사 박제될 것 같아서 걱정도 있었는데, 그래도 기존에 한번도 안해봤던 일이라서 두근되어 진행하게 되었다.
(회사 채용 홍보에도 도움이 될 것 같았고)

영상에선 나혼자 이야기하는 것처럼 나오지만, 사실은 태용님이 카메라가 보이지 않는 장소에서 질문을 주셨다.
나는 그 질문에 답변만 하면 되었다.

대본 외우고 진행한게 아니라서 혹시나 말이 조리있게 들렸다면 그건 온전히 태용님이 인터뷰 흐름을 잘 잡아주셨기 때문이라고 생각하시면 될 것 같다.
특히나 내가 말 실수를 하면 교정해서 다시 답변할 수 있게 해주셔서 무탈하게 인터뷰를 마무리 할 수 있었던것 같다.

10분의 짧은 영상이지만 사실은 5시간 촬영해서 나온 결과물이다.
(오후 6시 ~ 11시까지 촬영했음)

영상은 개인적으로는 잘되었다고 생각한다.
영상이 오픈되고 블로그 하루 방문자수가19,000명이 될 정도로 많은 분들이 방문해주셨기 때문이다.

특히 개발과 전혀 다른 분야에서 일하는 후배도 영상을 봤다고 연락올 정도였다.

새삼 유튜브의 힘을 느낄 수 있었다.

여행을 가는 것보다 이런 새로운 경험을 선호하는 편인데, 이번 경험은 특히나 오래 기억에 남을것 같다.

2019.12.31일 기준으로 영상 조회수가 29만이 되었다.
태용님의 유튜브 영상 중 4번째로 높은 조회수의 영상이 되었다.

4-3. 발표

가장 기억에 남는 발표는 99콘과 우아한테크의 밤이였다.

99콘

99콘 이력서 세미나 후기

99콘은 같은 회사 소속인 미경님의 권유로 발표를 하게 되었다.

주제는 주니어 개발자의 이력서로 정했다.
개발자의 이력서로 하기에는 연차에 따라 내용이 다를 수 있다고 생각되었기 때문이다.
대략 취준생 ~ 3년차 이하의 개발자분들을 대상으로 했다.

내 발표 전에 최지호님의 "7개의 타이틀,7번의 기회" 발표가 먼저였는데, 이때 장표나 구성, 내용이 다 좋아서 내꺼 준비안하고 발표보느라 정신 없었다.
다음에도 지호님의 발표가 있으면 찾아 들어야겠다는 생각을 했다.

99콘에서 나온 패널 토크 내용은 블로그에 정리했다.
근데 발표 내용보다 이 패널 토크 내용이 더 많이 공유되어서 기분이 묘했다.

이때 발표했던 내용으로 99콘 연말정산 때 한번 더 발표를 진행했다.

우아한테크의 밤

우아한 테크의 밤은 회사에서 본격적으로 진행한 채용을 목적으로 둔 행사였다.

우아한테크의 밤 세미나 후기

여기서는 발표를 하기 보다는 용근님과 함께 패널 토크에 참여했다.
패널 토크가 두 파트로 나눠져 첫번째는 민태님 영호님의 시니어 개발자들의 토크, 두번째는 나와 용근님의 주니어 개발자들의 토크로 이루어졌다.

용근님은 김창준님의 함께자라기에서 언급하는 야생형 개발자였고, 나는 반대 성향이다.

그래서 학습 방법, 패턴, 성장 과정도 조금씩 달라 패널토크 사전 준비나 토크 당일이 다 즐거웠다.

전 직장 동료들끼리 세미나 한번 열어보는게 어떨까요? 라고 했던일이 생각 났다.
(용근님도 전 직장 동료)

비록 세미나를 하진 못했지만, 이번처럼 패널토크 혹은 같은 세미나에서 발표를 하는 등은 해볼 수 있지 않을까 싶다.

5. 기타

5-1. 작업실

개인적으로 사용할 작업실을 구했다.

월 38만원이며 6개월 선납할 경우엔 10% 할인해준다고해서 아마도 다음 결제시에는 6개월 선납할 것 같다.

거리도 집에서 도보로 7분 거리에 있어서 이동하기에 참 편하다.

구하고 나서 제일 많이 받았던 질문이 "왜 구했어요? 카페에서 하면 되지 않아요?" 였다.

일단 내가 회사 외에 개발하는 시간은 다음과 같다.

• 월요일 오전
  • 회사가 월요일 오후 출근 정책이라서
• 평일 퇴근 후
• 주말 데이트 전 / 후

평일 출근 전 시간은 그냥 회사에서 한다.
카페 갔다가 다시 회사로 가기엔 시간이 아깝다.

"아니 저 시간도 회사에서 하면 되지 않아요?" 라고 할 수도 있는데,
평일에 업무 시간외에 회사에서 개인적인 공부와 작업을 처리하는건 참 어려운 일이다.

지나가다 누가 말을 걸수도 있는 거고,
어떤 내용에 대한 질문에 답변을 해야될 수 도 있다.
그럴때마다 계속 대응을 해야 되니 평일 저녁은 바로 퇴근하고 카페에서 하는게 더 좋다.
뻔히 자리에 남아있는데, "이제 퇴근 시간이니 저한테 말걸지 말아주세요" 라고 할 수는 없으니 말이다.
(물론 장애 대응하는건 예외다.)

그렇다고 카페에서 매일 하자니 회사에서 작업할때에 비해 단점이 너무 심했다.
대표적으로 다음과 같은데,

	회사	카페
개발 환경	Sidiz의자 넓은 책상 듀얼모니터 (Dell) Realforce 키보드 Logitech 마우스	불편하고 높이가 맞지 않는 책상과 의자 단일 모니터 맥북의 키감
장소와 이동	고정된 장소 언제 어느때 가도 항상 자리가 존재 슬리퍼/가방걸이/옷걸이	소음 매번 빈 자리 찾으러 다녀야 함 자리 부재시 분실 위험

의자나 책상의 높이, 모니터 높이, 키보드의 키감, 듀얼모니터 등등이 개발/공부할때 얼마나 영향을 끼치는지 알기 때문에 나에겐 되게 중요한 요소였다.

난 디지털 노마드 못할수도 있겠다는 생각을 했다.

더군다나 매일 자리를 구하는 것도 고역이였다.

회사와 자취방이 모두 잠실이다보니 잠실 내의 카페를 가게되는데, 사람이 너무 많다.
특히나 콘센트와 와이파이가 빵빵한 스타벅스는 퇴근 시간엔 이미 꽉차있고, 그 외 카페는 매번 돌아다니면서 자리를 찾아다녀야해서 고역이였다.

가장 생산성이 좋은 환경에서 언제나 개발할 수 있는 것
이게 필요했다.
그래서 작업실 역시 회사의 개발환경과 동일하게 세팅해서 사용하고 있다.
(Sidiz 의자, Dell 모니터, Realforce 키보드, Logitech 마우스)

집에 이런 환경을 세팅하기는 어렵다.
잠실이라는 동네에서 1~2평 넓은 곳으로 이사가는건 몇천만원이 더 필요하기도 하고, 언제든 출근지가 변경될 수도 있으니 집은 최소한으로 유지하고 싶었다.

"에이 그렇다고 38만원이나 쓴다고?" 할 수도 있지만, 생산성이, 시간이 5% 혹은 10%만 좋아져도 38만원은 전혀 아깝지 않다.

시간이 지나면서 학습 속도나 집중력, 체력이 신입때 보다 못하다는 생각을 계속 한다.
그러니 현질해서 부족한 부분을 채울 수 밖에 없다.

체력이 계속 떨어지니 PT를 받으며 체력을 키우고,
집중력이 떨어지니 최적의 환경을 세팅해서 생산성을 보정하고,
학습 속도가 떨어지니 시간을 돈으로 사서 더 많은 시간을 투자하는 등등.

계속해서 떨어지는 부분을 채우면서 갈 수 밖에 없다.

비슷한 일로 무조건 회사까지 Door To Door 30분 이내로 이사한다.
월세 혹은 전세 보증금이 아무리 차이나도, 방 크기가 아무리 작아도 출근 거리가 가장 우선시 된다.

오바하는 것처럼 보일 수는 있겠지만, 나는 정말 오래 오래 일하고 싶고 잘하고 싶다.
그러니 계속 이렇게 투자할 계획이다.

참고로 NBA 톱스타 르브론 제임스는 자신의 몸 관리를 위해 매년 17억을 쓴다고 한다.
참고 영상
내가 르브론 제임스만큼 연봉을 받진 않지만, 그래도 그냥 이야기 하고 싶었다.

6. 교육

캡틴 판교 (장기효) 님의 Vue.Js 정복 CAMP 수업을 수강했다.

수업 내용은 정말 좋았다.
실습 위주의 구성, 듣고 싶었던 Vuejs에서의 테스트 코드, 웹 개발의 전반적인 디버깅 방법 등 백엔드 개발자면서 어드민 개발이 필요한 분들에겐 특히나 도움이 많이 된다고 생각했다.

다만 평일 수업 시간이 생각보다 조금 허들이였다.
매 주 월/수 저녁 8~11시에 진행되었는데, 이러다보니 일주일의 스케줄이 다음과 같다.

• 월/수는 Vue 수업
• 화/목은 PT
• 금/토/일은 데이트

일정이 많이 빡빡했다.
그래서 수업 기간 동안은 저녁 약속을 일체 잡지 않았다.

근데 이게 문제라기 보다는, 강의장에 도착하면 생각보다 너무 피곤했다.
수업 시작도 전에 졸린다고 해야하나?

이상하다고 느낀게 작업실에서 개인작업할때는 이 시간대가 결코 졸린 시간대는 아니였다.
근데 수업들을땐 너무 졸려서 왜 이러나 싶었다.

곰곰히 생각해보니 지하철 2호선 인구 밀집도 때문이였던것 같다.
지하철에 사람들이 너무 밀집되어있고, 역 도착때마다 밀고 당기고 하는 과정이 계속 되다보니깐 흔히 말하는 기 빨리는 느낌이였다.

팀내 회의가 좀 늦게 끝나서 타다 타고 수업을 들으러 간적이 있다.
이때는 정말 개운하게 수업을 들었다.
그때 사람이 밀집된 2호선 지옥철 타고 강남으로 가는게 얼마나 체력이 소모되는 일인지 알게 되었다.

웬만하면 오픈라인 수업은 주말을 활용해야되겠다고 생각하게 되었다.

7. 내년 1분기 목표

원래 상반기 목표를 쓸랬는데, 이번 하반기 회고를 쓰다 보니 반기마다 쓰는 것도 양이 너무 많다는 느낌을 받았다.

간략하게만 쓰고싶지는 않다.
다음에 이 쌓인 기록들로 또 뭔가 해볼 수 있지 않을까하는 기대감에 최대한 상세하게 남기고 싶다.

3개월 단위로 회고하는게 좀 더 낫겠다는 생각이 들어서 일단은 1분기 목표만 정리 한다.

해보다가 분기 단위로 정리하기에 너무 짧은 시간이라면 그때 다시 기존대로 해도 될것 같다.

7-1. 4월 프로젝트 오픈

회사에서는 이미 2020년 상반기 프로젝트 일정들이 정해져있다.
이 프로젝트들 진행하면서 팀적으로 이것저것 시도하는것들이 있는데 이것 역시 잘 되었으면 한다.

바빠서 다음으로 미루자는 말을 너무 많이 했던것 같아서 이번엔 좀 다르게 하고 싶다.

7-2. 프레임워크 가지수 정리

올해 보았던 SNS 글 중에서 가장 공감가는 글이 있다.

링크

"낮은 수준의 사고에 익숙해야 남는 자원으로 높은 수준의 사고를 할 수 있다".

이 대목이 왜 와닿았었냐면, 사용하는 프레임워크 가지수가 늘어나면서 점점 더 상위 레벨의 고민이 부족한걸 자주 보기 때문이였다.

더 좋은 테스트 구조, 더 좋은 도메인 구조, 더 좋은 패키지와 모듈의 관계, 객체 관계, 비지니스 로직의 추상화 등등을 고민해야할 시간에 문법 공부하는 그런 일 말이다.

도구의 숙련도가 충분해야 더 좋은 애플리케이션에 대한 고민을 하는데 있어서 방해가 되지 않는다고 생각 한다.

그래서 (좀 극단적이긴 하지만) 기존에 다양하게 다 열어두고 사용했던 것들을 모두 다 단일 프레임워크만 사용하도록 할 예정이다.

• Junit : Spock
• MockMvc : RestAssrued
• Gulp : Webpack
• Guava 사용 여부

팀이 전반적으로 흔히 말하는 설계 능력이 다 갖춰지면 그때 가지수를 좀 늘려보는걸 고려해볼것 같다.

다양한 기술 스택이 단점이라는건 아니다.
문제에 맞게 기술을 선택하는건 좋은 일이다.
다만 현재 우리 상황에서 이게 좀 더 좋다고 판단한 것이다.
이미 팀에는 한번 얘기해놓은 상태이다.

7-3. Spring Batch 집필 완료

정상혁님과 함께하는 스프링 배치 책의 1차 원고 완성을 1분기 안에 하고 싶다.

상혁님이 매일 워크로드를 써주시는걸 보고 나도 덩달아 매일 작업을 할 수 있을것 같다.

스프링부트 책을 썼던때를 생각하면서 다시 열심히 달려봐야겠다.

상혁님과의 집필도 마무리 되면 그땐 집필 더 할지말지 고민을 해봐야겠다.
들어가는 공수가 너무 많다.

8. 마무리

최근까지 보고 있던 판타지 웹 소설 중에 전지적 독자 시점이 있다.

이 소설에는 재밌는 설정이 있는데,
그 인물이 어떤 이야기를 쌓아왔는지에 따라 강함이 결정된다는 것이다.

동굴에서 몇년간 폐관 수련한다던가,
은거 기인, 영약, 보물 등을 얻는 기연이라던가,
엄청난 노력을 했다던가 하는 등으로 강해지는게 아니라는 것이다.

더 많은 모험을 즐기고, 더 많은 사건을 거친 인물일수록 더 강하다.

그리고 더 재밌는 설정은, 더이상 이야기를 쌓지 못하는 인물은 소멸한다.
세계관이 그렇다.
즉, 예전에 계속 머물러 있으면 존재가 없어진다는 것이다.

난 이 설정들이 참 좋았다.
지금 하고 있는 회고도 내가 어떤 이야기를 쌓아왔는지를 확인해볼 수 있는 지표라고 생각했기 때문이다.

계속해서 많은 이야기를 쌓고 싶다.
잘나가던 과거를 회상하기만 하는 사람이 되고 싶지는 않다.
(그렇다고 지금 잘나간다는건 아니고…)

회사 안에서, 회사 밖에서 계속해서 더 많고, 다양한 이야기를 쌓을 기회를 찾을거다.

더 찾을 수 없다면, 떠나거나 / 방법을 변경하거나 해야겠지.
2020년에는 또 어떤 이야기들을 쌓을 수 있을까.