2021 회고

목표

• 다이어트
• 영어공부

• 명상

  • 하루 2번
• 마음일기 쓰기
• 경제/재테크 공부
• 등산
• 토이프로젝트
• TDD/Rust/Vim/Kotlin 학습하기

이 중에서 성공 했던 것들은 거의 경제/재테크 공부 밖에 없는 것 같다. 그 중에서 명상은 그래도 지키려고 나름 노력 많이 했었다.

Vim은 확실히 쓰려다가 Emacs로 넘어갔다가 다시 Vim으로 돌아가려고 셋팅을 했다. Kotlin을 실무에 계속 쓰려고 Java를 빼고 Kotlin으로 주로 작업을 하고 있는데, 관성이 있는 건지, Kotlin 언어스럽게 코드를 구성하기가 굉장히 어려웠다.

자주 쓰여 있는 return null에서 벗어나고 싶은데, 어떻게 하면 저 문장을 안 쓸 수 있을지? 고민 중인데, 쉽지 않다. 저걸 안쓰려면, 해당 코드를 만지는 모두가 협의가 되어야 한다는게 아직까지 내 생각이다.

올해부터 내가 맡은 영역이 있는데 차근 차근 하나씩 없애보려고 노력 중이다.

강의

• 프론트엔드 Back to the Basics : 지속 가능한 코드작성과 성능 향상법

친구가 결제 해줘서 보게 되었는데, 태곤님은 워낙 프론트계의 구루셔서 열심히 보긴 했는데, 애매하게 팀원이 많아져서 팀이 FE/BE로 나뉘게 되었다.

그런데, BE쪽으로 가다보니 FE쪽의 마크업 개발 영역과는 더 멀어졌다. (애초에 프론트 서비스 개발이지만, 회사 자체가 마크업 개발은 따로 커뮤니케이션 해서 개발을 진행 하기 때문에, FE긴 하지만 HTML/CSS를 못하니 늘 불안 했다) 그래도, 태곤님 강의 들으면서 눈이 넓어지긴 했다.

• 스프링 프레임워크 입문

사실 3년전에 만 얼마주고 샀는데, 안보고 있다가 보게 되었다. 한 시간 좀 더 되는 시간에 스프링을 얼마나 알겠냐마는 그냥 유명한 분이시고 해서 샀었는데, 생각보다 내용이 알차진 않았다.

영화

• 마진콜
• 클로젯
• 프리즌
• 백두산
• 폴라
• 소울
• PMC 더 벙커
• 미나리
• 고질라 vs 콩
• 낙원의 밤
• 서복
• 내일의 기억
• 더 스파이
• 비와 당신 이야기
• 잭스나이더의 저스티스 리그
• 분노의 질주 더 얼티메이트
• 담보
• 다만 악에서 구하옵소서
• 귀멸의 칼날 무한열차
• 제 8일의 밤
• 미드나이트
• 호텔 뭄바이
• 크롤
• 베놈2
• 보이스
• 이터널스
• 광해
• 발신제한
• 인질
• 국제수사
• 골든 슬럼버
• 모가디슈

드라마

• 사이코지만 괜찮아 (보다 말았다.)
• 경이로운 소문
• 도망치는건 부끄럽지만 도움이 된다.
• 도쿄구울
• 귀멸의 칼날
• 체르노빌
• 보좌관
• 시지프스 (보다 말았음)
• DP
• 유레이즈미업
• 오징어게임
• 좋아하면 울리는 시즌2
• 도시남녀의 사랑법
• 마이네임
• 지옥
• 해피니스
• 고요의 바다

독서

• 뉴욕주민의 진짜 미국식 주식투자
• 규칙없음
• 시간여행TV의 주식투자 전략
• IT좀 아는 사람
• 부의 골든타임
• 파이낸셜 프리덤
• 어느 날의 우리가 여느 날의 우리에게
• 한 컷의 인문학
• 부의 인문학
• 제시 리버 모어의 회상
• 디 앤서
• 초격차
• 강방천의 관점
• 내가 춤추면, 코끼리도 춤을 춘다.
• 생각이 너무 많은 서른 살에게
• 사랑의 기술
• 일주일은 금요일부터 시작하라
• 정서적 협박에서 벗어나라
• 나는 나로 살기로했다
• 사피엔스
• 초보자를 위한 투자의 정석
• 프로젝트 오너
• 부의 대이동
• 서울 자가에 대기업 다니는 김 부장이야기 1
• 서울 자가에 대기업 다니는 김 부장이야기 2
• 서울 자가에 대기업 다니는 김 부장이야기 3
• 월급쟁이 부자로 은퇴하라

작년보다 책을 너무 덜 읽었다. 그렇지만, 리디페이퍼를 산 이후로 속도가 붙어서 엄청 빠르게 책을 읽을 수 있었다. 재택 근무가 길어지니, 확실히 책보다 유투브를 더 많이 보게 되고, 경제학이나 재테크 관련 서적 보다 유투브를 많이 보게 되니 책을 읽는 시간이 줄게 되었다. 이 부분은 반성해야 된다…

팀의 분리 (FE/BE의 세상)

내가 일 하는 프론트 팀이 팀 안에서 FE/BE 파트가 나뉘게 되었고, 그 안에서 어찌 보면 일을 하게 되었는데, 생소하기도 하고 업무를 또 새로 또 받게 되었다.

한 9개월 정도 그 일을 했는데, 정말 적응이 안되고 오래 된 레거시다보니 일정이 더디게 지연 되었다. (내년에 열심히 하자)

거기다가 돈 관련 업무라 그런지, 수정사항 하나도 굉장히 조심스럽고, 레거시 스펙을 제거 하는 일도 굉장히 많은 사람들을 찾고 또 찾아내서 처리 해야 한다는 부담감이 속도를 저하 시키는 요인이었고, 실제로 잘못 되고 있는 걸 바로 피드백을 받을 수 없는 부분이 눈 가리고 칼질 하는 느낌을 받았다. (실제로 사고를 치기도 했다)

어떤 보완 할 수 있는 시스템의 부재도 크고, 리소스도 없고 그렇다고 내가 야근 하고 주말까지 반납해서 회사 일에 충성을 다 해야 하는건가? 생각도 들었다.

어찌보면 핑계 같기도 변명이기도 하지만, 어느 순간부터인가? 내가 회사 일을 열심히 한다고 술술 풀리는 것은 아니였다.

그래서 할 수 있는 시간에 최선을 다 하기로 생각 했다. 그래도 역부족이었을지도 모르겠다.

연차 대비 실력..? 글쎄

16년도 부터 일을 해왔으니, 그래도 시간이 지나고 일을 곧 잘 했던 것 같은데, 내가 모르는 부분은 왜 이렇게 많고, 내가 쓰는 기술도 모르고 지나친 부분이 어찌나 많은지, 한 해 내내 열심히 따라 가려고 해도 벅찬 느낌이었다.

어찌보면, 내가 지난 2년 동안에는 경제 관련 관심사만 두어서인지도 모르겠다. 그 이유가 아마 프로그래밍에 대한 어떤 번아웃이 오고 나니 퇴근 이후에는 정말 쳐다 보지도 않았다.

오히려 주식 시장이나 경제 관련 공부를 하는게 더 재밌었던?

그런데, 시간이 지나고 보니 내가 과연 연차에 대해 증명할 수 있는 실력을 가지고 있는지? 궁금해졌다.

코드의 퀄리티를 잘 하는 것은 아니라는 생각이 들었고, 인프라적인 지식은 많이 올라갔지만, 늘 코드와 인프라 운용은 대비 되는 부분 같다. 이것 하나만 잘 하는 것도 어려운데, 저것도 놓을 수 없으니, 어려움이 배가 된 느낌..?

그런데, 둘다 재밌으니 둘 다 놓지는 못하겠고, 그러다보니 더 산으로 간 느낌이다. 그래도 인프라와 개발 모두를 엮는 건 재미있는 요소라 생각 한다.

팀의 신입 개발자분이 빨리 성장 하려면 어떻게 해야 하는지 물어 왔을때, 내가 답했던 건 오히려 되물음이었다.

도대체 잘 하는 개발자가 뭘까요? 정량적으로 수치화 할 수 있는 잘함이 있을까요?

나는 아직도 모르겠다.

기술적으로 앎이 많던, 개발을 빠르게 해내던, 코드를 정말 깔끔하고 추상화 잘 하면서 작성 한다던지, 가독성이 좋은 등등,, 수 많은 좋음 사이에서 내가 늘 고민 하는 것은 “수정이 쉬운” 부분이 나는 추상화를 잘 설계 하는 것보다 중요했다. 물론 중복 없고, 추상화가 잘 된…그런걸 잘 지키며 만든 프로그램이 있을 수도 있지만, 적어도 나는 OCP를 잘 지키며 개발하는 게 능사가 아니라고 생각했다.

내가 말하는 쉬움은 누가 봐도 이 코드를 수정 하기 좋은가?

코드에 중복이 있기도하고, 폭포수 모델처럼 코드가 위에서 아래로 읽으면 이해가 되는 수준이고, 패턴도 전무하고 하는 느낌의 코드들이다. 서비스 개발에서는 추상화 시킨다고 공통화 하거나 하는 경우 문제가 연동 된 코드들이 많을 수록 장애 포인트가 커진다. 그러다보니 나는 “중복 러버”가 되었다.

차라리 중복 코드를 넣고, 나중에 서비스의 스펙이 사라지던, 그 서비스가 사라지던 하는게 낫다.

그 중복의 정도를 조절 하는 것이 제일 어렵다.

물론, 이게 정답도 아니고, 너의 한계야 라고 할 수도 있지만, 어쩔 수 없다.

내가 속한 곳에서는 서비스 개발의 목적은 최대한 빠르게 일정안에 기능 구현을 소화 해내고, 적정 트래픽도 받을 준비 (인프라 셋업)까지 다 해야 한다.

나는 내가 잘 하고 있다고 생각 하진 않는다. 나는 코드를 잘 짠다?와는 거리가 먼 개발자다. 사실 비즈니스 로직의 더러움을 코드가 가져다 주진 않는다고 생각 하는 편이다.

개발자는 얼마나 덜 짜는지가 서비스 완성의 척도라고 본다. 정말 필요한 부분만 코드를 작성 해서 서비스를 유지 시키는 게 중요하지.

기획자가 원하는 대로 수용해서 서비스 코드에 넣는게 중요한게 아닌 것 같다.

어쩌면, 개발자는 얼마나 코드를 덜 짜서!? 서비스를 확장 해나가는 건지가 중요한 능력 같기도 하다. 그리고, 그게 가능하면 좋겠지만 불가능한 경우도 있으므로, 결과적으로 실무는 늘 아름답지 않다.

책의 예제는 쉽고 간결하며, 굉장히 단순한 형태의 데이터를 기준으로 삼지만, 실무에서는 스펙도 더럽고, 레거시도 더럽고, 이상은 높다.

그것을 노력으로 서비스가 무너지지 않게 하는 것은 팀의 결합도인 것 같다. 나는 팀의 시너지가 소통에서 온 다고 생각 하는 사람이다.

개발자들끼리 이야기 하다가 어떤 이야기 나와서 내가 말한 건 이렇다.

“잘 한다고 그 사람과 일하고 싶진 않고, 그 사람과 일 하는게 재밌어야 오래 하고 싶어진다.”라고 말 했는데, 이게 나의 정답 같다.

2022년도에는 나도 일 할 때 재밌는 사람이고 싶다.

그래서 회사에 속한 개발자로써의 계획은 ?

• 불평/불만을 내려 놓기
• 인정을 빨리 하는 것

총 2가지를 지키고 싶다. 불평/불만을 말하는 것보다 지금 당장 실행 할 수 있는 것을 하는게 시간을 아끼는 방법이다.

그리고, 스우파를 보면서 느낀 건데, 허니제이의 강함은 “인정”에서 온다고 생각 했다. 밤새도록 했음에도 결과가 나오지 않더라도, 상대방보다 내가 더 잘 한것 같음에도 결과는 내가 패배일 수 있고, 내 의견이 팀의 색깔과 부합 되지 않거나, 방향이 다를 수 있다. 그럴때, 인정 하는 것

나는 늘 내 생각이 옳고, 고집 부렸던 것 같다. 그래서 나와 다르면, 늘 부정적인 시각으로 보거나 말을 했던 것 같다.

그 부분들은 이제는 내려놓고 온전히 할 수 있는 것에 집중 하는 팀원이 되고 싶다.

개인적인 목표

• Kotlin의 세계관을 좀 더 잘 이해하기
• Rust를 이해 해보자.
• 토이 프로젝트

작은 것부터 하나씩 만들어가보자.

어려운 프로그램도 결국, 단순하고 쉬운 함수 하나부터 시작한다. 그런 토이 프로젝트를 진지하게 해보길!