올해는 회사, 스터디, 사이드 프로젝트, 개발 외 적인 것으로 2022년을 정리해보고자 한다.
회고란
사전적 의미로 '뒤를 돌아봄', '지나간 일을 돌이켜 생각함'.
정해진 기간 동안 해왔던 일들에 대해 돌아보면서 문제점이나 잘한 점을 찾아내어 다음 작업에도 좋은 점은 계승하고, 아쉬웠던 점들은 다른 방식을 시도해 끊임없이 개선을 추구하는 것이다.
from https://bit.ly/3FLRHjY
1. 회사
1) 의지하던 유능한 동료들의 퇴사
올해 초부터 2분기까지 개발팀에서 내가 많이 의지하던 유능한 동료분들의 퇴사가 있었다.
그때의 나는 아직 1년을 조금 넘긴 병아리 삑삑이 주니어 개발자였기 때문에 당시만 생각하면 아직도 막막함, 두려움, 아쉬움,.. 여러 가지 감정으로 힘이 쭉 빠진다.
그 시기 쯤에 마켓컬리에서 진행한 <2022년 2월 마켓컬리 개발자 밋업>을 듣게 되었고, 그 과정에서 용기를 얻어 사내 개발자 세션에서 <우리 회사 개발팀, 오히려 좋아>를 준비하고, 나누면서 다시금 내가 왜 이 회사에 남아있는 가를 상기시켜 보았다.
그리고 지금 1년을 되돌아보니 ‘인생 만사 새옹지마’라는 말이나 ‘나를 죽이지 못하는 고통은 나를 더욱 강하게 만든다’라는 말처럼 어떤 계기더라도 마음가짐이 중요한 것이라는 것을 깨달았다.
좋았던 것들:
출퇴근길에서 ‘사수 없이 성장하기’ 같은 주제를 담은 아티클을 읽으면서 우울해하는 건 그만하고 동료분들께서 평소에 가르쳐주시고 가신 것들을 정리했다.
그리고 백엔드에서 내가 인수인계를 받고 리드를 맡은 부분의 업무 파악을 하기 위해서
- C님의 퇴사부고
- 인수인계 문서들
- 백엔드 아키텍처와 API 등 남겨져있는 문서 파악하기
등을 했다.
그리고 백엔드 팀과 다른 개발팀 분들, 그리고 개발팀 리드분께 피드백을 요청해서 받았다.
아쉬운 것들:
내가 이전에 그 동료분들께 배웠던 것, 그분들이 나보다 입사를 빨리 했고, 경력이 조금 많고,.. 등의 여러 이유로 나의 방패가 되어주고, 내가 좀 더 개발에 집중할 수 있도록 배려해줬던 점들이 분명 있었다. 그런데 나는 다른 동료분들께 이런 존재가 되어주었는가? 에 대해선 확신이 없다. ㅠ
2023년에는 ‘아 이 사람이랑 같이 하면 되지. 할 수 있지’라는 든든함, 따뜻함을 주는 동료이고 싶다.
2) 커리어에 대한 생각
2021년 하반기 동안 복잡했던 생각을 정리하고 2022년 3월, Career 방향성에 대한 생각 이라는 글을 적으면서
- 복잡한 도메인 / 비즈니스를 이해하고, 미팅을 이끌어 갈 수 있는 능력
- 확장성 있는 시스템을 구상하고, sustainable 하고 scalable 한 대규모 시스템 설계 및 개발 능력
- 운영 능력
이 있는 Backend Engineer로서 성장해 나가고 싶다.
라고 생각의 마침표를 찍었다.
그리고 이렇게 커리어에 대한 방향성을 잡고 나니, 회사에서 주도적으로 맡고 싶은 일들도 생겨났고, 기존에 맡고 있던 일들도 다시금 재미가 생겼다.
올해부터 적극적으로 사용하게 된 프로젝트 관리 툴 클릭업(ClickUp)을 보며 크게 어떤 일들이 있었는지 정리해 봤다.
좋았던 것들:
- Issue가 생겼을 때 Post mortem, 문서화 및 fix를 한 경험 (TRY TO solves business problems efficiently and effectively)
- 문서화를 열심히 한 것 (TRY TO writes documentation to help both peer engineers)
- 매주 30분씩 있는 CAO님과 하는 백엔드 팀 미팅 리드 (비록 미팅 리딩이나 회의록 작성 역할이 많긴 했지만) (TRY TO carries out regular maintenance checks and analysis of current procedures and policies and suggests possible ways to optimize product performance.)
- 백엔드의 새로운 architecture, tech stack에 대해서 고민하고 논의할 수 있는 기회가 있었던 것
아쉬운 것들:
- 위 4가지 일들을 경험할 수 있었던 것이 매우 좋았지만, 더 열심히 할걸..이라는 아쉬움이 있다.
- Test code 작성 경험이 여전히 부족하다고 느낀다.
- writes clean and concise code
- .. 그 외 다수 여전히 개발에 있어선 아쉬운 게 너무 많고, 내가 한없이 부족해 보이기만 한다.
3) 팀 문화의 성장
올해는 어느 때보다 팀 내 문화나 함께 일하기에 대해서 팀/회사 차원에서 많은 고민을 하고 action item을 수행했던 해인 것 같다.
아직 이 회사에서 지낸 지 2년이 조금 안되었지만 처음 입사했을 당시와 현재를 생각해보면 정말 많은 것들이 좋은 방향으로 바뀌었다.
좋았던 것들:
1. 컬쳐데이
우리 팀에는 정기적으로 ‘아무 말이나 편하게 얘기 나누고 평소에 하고 싶었던 토의/얘기하기’를 하는 시간이 있다.
여기서 ‘업무 스트레스에서 벗어나 팀원에 대해 알아가는 시간을 통한 팀워크의 향상’의 필요성 대해 얘기가 나왔고 이는 2 달마다 주최되는 컬쳐데이의 탄생으로 이어졌다.
아래는 나와 JH님이 주최한 <제3회 컬쳐데이>의 모습이다.
컬쳐데이를 함께 기획하면서 가장 많이 친해졌고, 또 이 날 만큼은 업무 얘기 외의 개인적인 얘기를 하면서 서로를 더 잘 이해하고 가까워질 수 있었다.
나는 개인적으로 팀 분위기나 스타트업 특유의 자유로움, 재미, 동료애 가 정말 x 100 작년보다 2배는 좋다고 생각한다. 연말 익명 설문조사에서 팀원분들께 사랑한다고 고백할 만큼 ㅎㅎ
2. 개발팀 내 업무 또는 개발팀과 타팀간의 협업 효율성을 높이기
2021년 회고에도 적었던 것처럼, 올해도 우리 팀에서 체계적이면서도 효과적인 업무 처리 방식이나 커뮤니케이션 방법 등에 대해서 고민하는 것이 이어졌다.
2022년에 좀 더 발전된 것이 있다면 문제라고 이야기하는 것들의 배경을 충분히 듣고 이해하고 그 이후 action item으로 우리가 쓰고 있는 협업 툴들인 Clickup, Slack, Google Calendar, Github 등의 사용 규칙을 모든 팀원이 함께 정하고, 문서화하여 따르도록 노력한 것이다. ‘함께’ 논의해서 만들어나간 사내 통일된 tool guildline이기 때문에 확실히 갈수록 업무와 협업 process가 나아지고 있다는 것이 체감이 된다. 스타트업의 매력은 이렇게 우리가 스스로 변화시켜나갈 수 있는 것들이 많고, 그 과정에 주체적일 수 있는 자유로움이 보장된다는 게 아닐까.
내년에는 ‘문화’적인 측면, ‘함께 어느 목표를 가지고 일하는 협업하는 관계에서 가져야 할 마음가짐’에 대해서 좀 더 많은 얘기와 노력이 이루어졌으면 하는 바람이 있다.
3. 칭찬하는 문화 만들기
앞서 말한 ‘아무 말이나 편하게 얘기 나누고 평소에 하고 싶었던 토의/얘기하기’를 하는 시간에 <칭찬하는 문화>에 대해서 얘기가 나왔었다. 그러던 중 리멤버의 타코 문화를 소개합니다 를 보게 되었고,
이와 유사한 서비스인 Hey burrito를 사내 서버에 배포해서 팀 내에서 사용할 수 있도록 하였다.
내년에도 잘 활용되었으면 좋겠다!
아쉬운 것들:
google calendar로 slack profile status 동기화 앱 개발을 해서 우리가 사용하고 있는 연차나 재택근무, 자리비움 등을 google calendar에 표시해두면 해당 시간에 등록된 status에 해당하는 slack profile emoji가 표시될 수 있도록 하고 싶었다. (왼쪽 slack user display name 옆에 status emoji가 표시됨)
이에 대한 배경 설명과 개발 근황을 [Toy Project] 팀원 일정 및 상태 슬랙 프로필 표시 앱 개발 - 1 여기에 정리하였는데, 그 이후 완성을 하지 못했다. 이 점이 아쉽다.
4 ) 2022년의 끝! 그리고 겨울 방학
사려 깊고 팀원을 정말 아끼시는 프런트엔드 엔지니어 SK님께서 프로덕트 팀원 전체에게 칭찬할 점과 그에 대한 트로피를 직접(!!!) 만들어주셨다. (메이커스에서 직접 한 땀 한 땀 만드신 것이다. 진짜 감동)
나에 대해서는 아래의 것들을 칭찬해 주셨다.
최고의 복지는 동료(최복동)라고 하지 않던가. 난 1년 동안 최최최최복동 사이에서 조금 더 성장했다.
2. 스터디
1) Clean Code
github repo: https://github.com/Gracechung-sw/clean-code-practice
blog post:[Clean Code] Chapter 01. 깨끗한 코드
[Clean Code] Chapter 02. 의미 있는 이름
[Clean Code] Chapter 04. 주석, Chapter 05. 포맷팅
[Clean code] Chapter 09. Unit test
Clean code를 1번 완독하고 정리했다. Clean code를 읽게 된 배경이나 느꼈던 점은 우리 회사 블로그 #5. Backend Engineer의 성장스토리. <마틴 파울러의 리팩터링 2판 스터디> 글에 적어두었다.
2) 리팩터링 2판
github repo: https://github.com/Gracechung-sw/refactoring-2nd-edition
refactoring log:
chatper 01 리팩터링: 첫 번째 예시
chapter 06 기본적인 리팩터링
chapter 07 캡슐화
chapter 08 기능 이동
chapter 09 데이터 조직화
chapter 10 조건부 로직 간소화
chapter 11 API 리팩터링
chapter 12 상속 다루기
번외 리팩터링과 테스트
리팩터링 2판을 공부해야겠다는 마음을 먹게 된 배경은
- Clean code를 어찌 됐건 읽고, 정리하는 목표를 달성했다는 것에 대한 자신감이 있었음.
- 더럽고 복잡한 코드, 이해하기 어려운 코드로 인해 유지보수가 오래 걸리는데, 여기에 기능 추가까지 되어야 하는 상황이라 리팩터링의 필요성이 절실함
- 부채 청산에 대한 팀 차원의 공감이 형성되어 있음.
이었다.
리팩터링 2판은 현업에서 적용시켜봐야 하는 것인 만큼
- 회사 동료분들과 함께 공부하고 싶었고,
- 리팩터링 2판은 Javascript로 되어있었기에 Typescript를 사용하는 우리 상황에 맞게 예시 코드를 바꿔보기도 하고, 예제를 따라 해 보며 리팩터링 과정을 커밋 단위로 남겨보고자 했다. 또한 테스트까지 작성해보고 싶었다.
그래서 잠깐의 홍보로 동료 2분과 함께 리팩터링 2판 스터디를 함께 하게 되었다.
그리고 11월 10일, 스터디의 가장 큰 공통 목표였던 <리팩터링 2판 완독>으로 스터디가 마무리되었다.!
한 번 읽었다고 모든 걸 기억하고 적용할 수 있진 않겠지만 일단 책을 다 읽었다는 것, 그리고 각자의 실업무를 생각하며 이런저런 토론을 했다는 것만으로 충분히 만족할만한 아웃풋이라고 생각한다.
해당 스터디에 대한 구체적인 내용은 우리 회사 블로그에 #5. Backend Engineer의 성장스토리. <마틴 파울러의 리팩터링 2판 스터디> 글에 적어두었다.
3) 알고리즘 스터디 5기 Bay Area K Group (BAKG)
알고리즘 스터디 5기 Bay Area K Group (BAKG)을 했다.
이 스터디는 MIT 알고리즘 강의와 실전 문제 풀이로 이루어져 있는데, 첫 오리엔테이션 시간에 <내 인생에 알고리즘 개념 정리는 이게 마지막이다!>라는 마음가짐으로 열심히 하자고 했었다.
특히 리더분께서 말씀해주신 것이 정말 기억에 남았는데, 그때 간단하게 적어놓은 것을 첨부하자면 아래와 같다.
time complexity를 생각할 때
⇒ 실무에서 practical 하게 어떻게 적용되는가?
⇒ 이런 식으로 실무와 개념을 연관시켜서 생각하기! 가 매우 interview에서 중요하다.
ex. O(n^2) 는 O(nlogn)보다 항상 못한 solution이야??라고 interview에서 물어보면..? 현업에서 어느 경우에 더 좋은가라고 다방면으로 생각해봐야 함.
Engineer는 항상 practical 한 접근이 필요함. view point를!
결론적으로
1. MIT 는 면접/실무에 대한 수업은 아니지만 내용은 정말 좋다.. 그렇기 때문에 수업을 들을 때 항상 실무 적용에 대한 view point 어떻게 할 것인지 생각하면서 들어야 한다.
2. 그리고 내 인생애 알고리즘 스터디는 이게 마지막이다.라고 생각하고 깊게/확실하게 공부하기.
개념 강의는 발표도 하면서 참여했다. 하지만 문제풀이 시즌이 되어선 알고리즘 챕터별로 묶어진 문제를 차근차근 풀고 싶다는 내 스터디 방향과 맞지 않는 것 같다. 개인적으로 스터디를 만들어 진행하는 것으로 BAKG 5기 알고리즘 스터디 참여는 그만하는 것으로 했다.
4) 파이썬 알고리즘 인터뷰
BAKG 5기 알고리즘 스터디 참여를 그만두고 리팩터링 스터디를 같이한 팀원분과 함께 <파이썬 알고리즘 인터뷰>로 알고리즘 스터디를 시작했다.
아래는 kickoff 미팅 때 스터디의 참여 목표, deadline, 스터디 방식, 시간 등을 정한 내용이다. 이렇게 남겨놓고 스터디가 마무리되었을 때, 잘 되었는지 확인하는 게 좋은 것 같다.
5) 개인적으로 한 공부들
리팩터링과 파이썬 알고리즘 스터디를 하면서 ‘기본기’를 확실히 잡고 암기하고 싶어서 기본기인 JavaScript, TypeScript, Python와 OOP에 집중해보기로 했다.
chapter 02. 이상한 나라의 객체
chapter 03. 타입과 추상화
chapter 04. 역할, 책임, 협력
chapter 05. 책임과 메시지
chapter 06. 객체 지도
chapter 07. 함께 모으기
TypeScript, Python typing OOP
github code link: https://github.com/Gracechung-sw/typescript-typepython-oop/pull/2/files
아쉽지만 많이 못 한 것들
- Kubernetes
- NestJS
- Envoy
마무리
공부의 output은 결국 무의식 속 확실히 알고 있는 지식의 범위를 넓혀가는 것, 그래서 실무에서 자연스럽게 꺼내 쓸 수 있는 것이지 않을까 라는 생각을 하면서 결국 공부의 마무리는 ‘암기’가 아닐까 한다.
올해는 이 점이 많이 부족했다고 생각한다. 내년에는 ‘이 공부를 해서 실무에서 어떻게 적용시켜 보았고, 그래서 output이 뭔지?’에 대해서 집중하려고 한다.
이 마음가짐을 더 굳건하게 해 준 참고자료를 남긴다.
https://youtu.be/4OWuDjCk16M?t=39
3. 사이드 프로젝트
1) Mash Up 12기
<Mash Up>이라는 IT동아리를 했다. 나는 Node팀 12기였고, 약 6개월 동안 활동을 했다.
프로젝트를 하기 전까지는 Node 팀원들과 NestJS와 Kubernetes에 대해서 스터디를 하는 시간을 가졌고,
정기적으로 Mash Up 전체 사람들과 온/오프라인으로 모여서 다른 팀(IOS, Android, Java, Design.. 등)의 발표를 듣거나 Partnership을 맺은 회사의 홍보/발표를 듣기도 했다.
사이드 프로젝트를 시작하게 된 이유 첫 번째인 프로젝트를 하면서는 Anroid, Node, Product Design, Web으로 구성된 우리 팀원들과 해커톤에서 밤도 함께 새우면서 정말 열심히 했다.
이 때는 힘들어도 개발이 재미있었고,
<맨먼스 미신>에서 설명한 개발이 즐거운 이유 5가지 중 4가지 인
- 무언가를 만드는 데서 오는 순전한 즐거움 (ㅇ)
- 남에게 쓸모 있는 것을 만드는 데서 오는 즐거움 (△)
- 복잡한 문제를 풀어내면서 얻는 즐거움 (ㅇ)
- 지속적인 배움에서 오는 즐거움 (ㅇ)
들이 있었다.
그리고 좋은 팀원들과 서로 아끼고 배려해주면서 각자의 책임감으로 하나의 제품을 만들어 나가는 느낌이 정말 하나의 스포츠를 하는 느낌이었다.
그리고 두 번째 이유인 Node팀 내에서의 NestJS, Kubernetes 스터디에 대해서 적어보자면
- Kubernetes는 실제 현업에서 사용할 수 있는 환경이 아니어서 이 side project에서는 해 볼 수 있지 않을까 해서 신청한 이유도 있었다.
- 하지만 side project 역시 대규모이거나 kubernetes를 사용할 만큼의 규모가 아니라서 사용해보지 못하고 끝났다.
- 다만 현재 회사에서 open source(kafka, envoy, istio… 등), kuberenetes, 등을 사용해서 cloud dependency를 없애고 MSA를 더 효과적으로 운영할 수 있도록 가기 위해서 준비 단계에 있다. 내년에는 잘 사용해 볼 수 있지 않을까 하는 기대가 있다.
좋았던 것들:
1. 팀원들의 피땀눈물 (이 아니고 커피맥북재미) 해커톤
2. 프로젝트로 만든 서비스 완성!
아쉬운 것들:
- kubernetes 스터디나 사용을 못 해본 것
- NestJS를 깊이 이해하지는 못한 것
- TDD 등 실무에서 하고는 싶지만 ‘잘 안 되는 것’을 여기서 해볼 수 있었을 텐데.. 잘 못 해본 것.ㅠ
2) 글또 7기
작년 글또 6기 에 이어서 이번에도 글또 7기에 참여했다. 하지만 올해는 많은 글을 쓰지 못했는데, 이 회고를 하면서 다시 뒤돌아보니 후회가 많이 된다. 좋은 분들과 커피챗도 하면서 개발자 선배님으로서 많은 조언과 위로를 받았었는데 나는 그런 활동원이 되지 못한 것 같아서 죄송하기도 하고 많이 아쉽다.
4. 개발 외
2022년, '나 자신하고 싶은 거 다 해!' 싶었던 소중한 기억들을 여기 박제해 둡니다.
1) 운동
올해는 필라테스를 열심히 했다! 망가지는 몸을 간신히 필라테스로 견뎌내고 있는 중..
2) 운전면허 취득
작년 연말~올해 초에 우리 회사 개발팀에 운전면허 붐이 불어서 나도 28년 인생.. 이제야 운전면허를 따게 됐다.
무려 기능만 3번 만에 합격했지만 도로주행은 한 번에 합격했다.
내년 초에 렌트가 가능해지면 이리저리 많이 돌아다녀보고 싶다!
3) 피어싱
추석에 서버에러를 급히 처리하고 스트레스 풀러 충동적으로 피어싱을 4개나.. 했다.
이 맛에 피어싱 하는구나 ㅎㅎ 예쁘다. (이런 거 보면 내가 정말 IST’J’가 맞는지 의심이 간다.)
2022년은 희노애락이 정말 분명했던 해였던 것 같다.
개발자로서 성장하고 있는가에 대한 불안감과 자신감의 하락이 바닥을 기던 올해 초,
그리고 거기서 메타인지의 연습과 팀원들의 묵묵한 응원 속에 회복해 나간 2분기.
여러 개발의 재미를 찾아 이런 저런 시도를 하고 새로운 사람들, 새로운 기술들로 하나의 서비스를 완성하면서 개발을 처음 배웠을 때 느꼈던 흥분이 있었던 3분기.
회사에서 올해 내내 고민해던 새로운 아키텍쳐와 백엔드 방향성에 대해 이제야 조금씩 형태가 보이기 시작하면서 느낀 뿌듯함과 팀원들의 사랑(사랑? 사랑!) 으로 마무리된 4분기.
2022년도 무사히 보낼 수 있도록 내 곁에 있어주신 온/오프라인 모든 분께 다들 감사하다.
감사합니다.
'Diary > Y2022' 카테고리의 다른 글
| [글또] 글또 6기 KPT로 시작하는 7기 준비 (1) | 2022.05.05 |
|---|---|
| 나의 부족함 마주하기 (0) | 2022.04.19 |
| Career 방향성에 대한 생각 (0) | 2022.03.02 |
| [Dev Culture] 내가 경험하고 배운 Project Post-mortem 문화 (0) | 2022.02.18 |