23년 2월 월간 회고
Intro
2월도 순삭이네..
Keep
첫 PR 드디어 Merge!
와..드디어...
아마 블로그를 예전부터 꾸준히 봐왔던 사람이라면 이게 얼마나 감동적인지 알 것이다..때는 바야흐로 작년 8월 23일. 프로덕션 코드베이스에 처음으로 PR을 올렸던 날이다. 그리고 동료 분들의 사랑을 뜨겁게 받기도 한 날이고(리뷰 124개 실환가 진짜).
저때 이후로 리뷰 지옥에 파묻혀 지내다가 더 우선순위가 높은 일들을 받으면서 점차 밀려나갔던 일이었다. 백로그 한 켠에 고이 잠들어 있던 아이였는데..마침 2월에 잠깐 여유가 생긴 틈을 타 후다닥 해치워버렸다.
작년 10월 월간 회고에 보면 <개발자의 오너십>에 대한 이야기가 나온다. 자신이 맡은 일, 작성한 코드는 주인의식을 갖고 끝까지 책임져야 한다는 게 골자인데 저때 이후로도 계속 이 작업을 할 기회가 생기지 않아 마음이 여간 불편했던 게 아니었다. 이제야 진짜 1년차 개발자를 졸업한 느낌이랄까. 고생했다 진짜. 그리고 잘했다. 앞으로도 이렇게 계속 주인의식을 갖고 끝까지 책임지면서 일하자.
독서 스터디: <구글 엔지니어는 이렇게 일한다>
약 2달 남짓 진행했던 독서 스터디가 오늘을 끝으로 마무리됐다. 2달 동안 <구글 엔지니어는 이렇게 일한다>를 읽고 요약하는 스터디였다. 정확히 49회차까지 진행했다. 정리한 내용은 여기 링크에 공유한다.
예전부터 꼭 읽고 싶었던 책이었지만 워낙 두껍다보니 한 번에 읽을 엄두가 나지 않았다. 필요할 때마다 발췌독으로 몇 번 읽기는 했지만 책이 말하고자 하는 바를 큰 뷰에서 알기는 좀처럼 쉽지 않았다. 마침 정글 1기 분께서 매일 읽고 쓰는 독서 스터디를 열어주신 덕분에 끝까지 완수할 수 있었다. 책 후기는 따로 블로그 글에 쓸 예정이다. 앞으로도 두꺼운 책은 이렇게 쪼개서 읽으면 되겠구나 하는 자신감이 생기기도 했다.
사내 도커 스터디 주관 → 계속 Keep going
저번 1월 회고에서 언급했듯, 주도적으로 일을 진행하는 내 장점을 살려 BE 팀 내에서뿐만 아니라 FE, QA 등 다른 팀 엔지니어 분들과도 함께 할 수 있는 사내 스터디를 주관해보는 게 어떻냐는 조언을 해주셨다. 실행력 빼면 시체인지라 곧바로 도커 스터디를 시작…하려 했는데 사실 바로 실행하기가 쉽지 않았다. 그도 그럴 것이, 일하면서 배우는 것들을 소화하기도 벅찬 마당에 새로운 스터디를 벌리는 게 맞을까 싶었기 때문이다. 그렇게 고민하기를 3주, 리드님과 1 on 1을 하며 결국 스터디를 진행하기로 결정했다.
총 10명이 지원해 2달 간의 스터디를 진행하고 있다. 이 글을 쓰는 지금 시점을 기준으로 이미 3회차를 진행했다. 스터디 수업 자료는 공개해두고 있어 여기에도 공유한다(스터디 자료 링크). 책은 <도커, 컨테이너 빌드업>으로 진행하고 있다.
여기서 한 가지 챌린지는 무엇이었냐, 모든 수업 준비는 나 혼자 다 담당하고 있다는 점이다. 이 스터디는 돌아가면서 진행하지 않는다. 스터디 장인 내가 수업 준비부터 진행까지 전부 다 맡고 있다.
애초에 스터디를 진행하려는 건 두 가지 목적이었다. 하나는 팀 전반적으로 컨테이너 환경에 대한 이해도를 높이고 나아가 실전에 원활히 적용하게끔 하는 것이었다. 다음은 가장 중요했던 동기인데, 개인의 실력 향상이다. 스터디에서는 누가 가장 많이 배울까? 바로 스터디를 진행하는 사람이다. 혼자 이해하기 위해 공부하는 것과 남에게 가르쳐주기 위해 공부하는 것. 둘 중 후자에서 이해도가 훨씬 높다. 도커 및 컨테이너 환경에 대해서는 내가 가장 많이 배우고 싶었다. 한 가지 걸리는 게 있다면 '수업 준비 및 진행을 나 혼자 독점해도 되는 건가'였는데, 오히려 다들 좋아해주셨다. 스터디 반응 역시 좋았다.
단순히 개발 실력 뿐만 아니라 스터디를 스스로 이끌어 보는 경험에서 오는 전반적인 진행력 향상 역시 원하던 바였다. 다행히 수업 반응이 늘 좋다. 스터디 끝내는 대로 하반기에는 도커 강의 콘텐츠를 찍어보는 걸 목표로 삼으려 한다.
앞으로 5회 정도 더 하면 수업은 끝날 예정이다. 그때까지 계속 화이팅하자.
대규모 프로젝트 투입 → 떨린다..!
저번 주부터 새 프로젝트에 투입됐다. 이전까지는 작은 단위 기능 추가라던지, 리팩토링이라던지, 버그 수정 등 티켓 하나 단위의 태스크 위주로 일을 수행했다. 그러다 이번에 Payment & Wallet 팀으로 옮기고 처음으로 큰 프로젝트에 투입이 됐다. 프로젝트는 대출 상환 자동 이체 시스템으로, 사용자가 신청하면 상환일에 직접 입금할 필요 없이 계좌에서 자동으로 이체할 수 있게 하는 기능이다. 한국인 입장에서 자동이체는 너무나도 당연하고 익숙한 기능이다보니 이게 왜 아직까지 안 들어갔지? 했는데, 속사정을 살펴보니 여러 이슈가 많았더라. 어쨌거나 덕분에 지금 시점에 내 손에 들어온 게 중요한 것 아니겠나.
심지어 실력 좋은 분들과 함께 투입되었다. 진짜 많이 배울 수 있을 것 같아 설렌다. 심지어 해당 기능이 출시됨으로써 이용자의 연체율 감소 등 꽤나 큰 비즈니스 임팩트를 만들 수 있을 것으로 보인다. 정말 값진 경험을 하겠다 싶다.
요즘 깃헙 잔디가 예전만 못하다..
다시 keep going하자. 사실 이전 같았으면 코딩으로 채울 시간을 독서 스터디로 메우다 보니 독서 스터디 내용을 깃헙 잔디로 심을까 고심도 했다. 그런데 뭔가 이유는 없지만 그렇게 하고 싶지는 않더라. 블로그에 매번 요약본을 올리기도 뭔가 그렇고. 알량한 자존심인가. 무튼 그나마 도커 스터디 준비하면서 커밋 잔디를 많이 심었는데 이따금 스터디 준비를 해놓고도 해당 내용을 깃헙에 업데이트하지 않아 종종 빼먹었다. 3월에는 이런 일 없게 해야지..
Learn
색안경 끼고 함부로 판단하지 말 것
제목이 모호한데, 꽤나 반성할 일이 하나 있었다. 현재 내 매니저는 인도 분이다. 그런데 한국에서 인도를 바라보는 시선 중 하나가 일을 제대로 안한다는 게 있는데, 직접 제대로 겪어보지도 않았으면서 어느샌가 알게 모르게 나 역시 색안경을 끼고 보게 되더라.
하루는 회의를 하다가 금요일에는 배포를 하지 말자는 안건이 나왔다. 순간 ‘일을 하기 싫어서 그런건가…?’라는 생각이 들었다. 차마 입밖에 꺼낼 수 없어 가만히 있었다. 그러고 얼마 뒤, 한국 개발자 분들과 담소를 나누다가 윗 얘기를 꺼냈다. 일을 하기 싫어서 그런 거 아닌가 싶다며 웃었는데, 생각지 못한 대답을 들었다.
우니, 그건 아닌 것 같아요. 금요일에 배포하지 말자는 건 배포했다가 주말에 이슈 터지는 바람에 사람들 제대로 쉬지도 못하고 고생하니까 나온 의견이예요. 애초에 배포 전에 버그는 없는지, 테스트부터 시작해서 배포하는 개발자가 제대로 점검하지 못해서 다같이 고생하는 건데 그렇게 얘기하는 건 아닌 것 같아요.
깊이 반성했다. 저런 이슈가 있었다는 건 몰라서는 둘째 치더라도 애초에 나한테도 알게 모르게 그런 편견이 있었다는 사실에 문제가 있음을 깨달았다. 절대 색안경 끼고 함부로 판단하지 말자.
Github - Jira Integration 진행하자
사실 이건 Problem 자체에 더 가까운 것 같긴 한데, 팀 회고를 하던 중 배포 프로세스 관련해 한 가지 이슈가 나왔다. 이제까지는 커밋이 머지되면 곧바로 태그를 달고 배포 티켓을 열어 배포를 진행한 뒤, 배포가 끝나면 티켓을 닫는 식으로 진행했다. 그런데 몰랐던 사이에 배포가 끝난 뒤 티켓을 닫고 그 뒤에 태그를 다는 식으로 프로세스가 변경되었다고 하더라. 이 이유는 배포 중에 문제가 생겨 롤백해야 할 상황이 발생할 수 있어 그랬다고 했는데, 지금 써보니 잘 납득이 되지 않는다. 다시 물어봐야 할 것 같다. 아무튼 이러면 배포 이후에 까먹고 태그를 달지 않는 이슈가 발생했다(실제로 몇몇 리포지토리에는 해당 배포에 대해 태그가 달려있지 않았다).
그래서 티켓을 닫으면 Github hook을 통해 자동으로 해당 태그를 만들어주는 프로세스를 만들자고 제안했다. 문제는 액션 아이템으로 제안해놓고 바쁘다고 팽개쳐두고 있던 것.. 지금 회고를 빌어 요 작업 꼭 마무리하자. 물론 그전에 이게 진짜 필요한지부터 다시 체크하고.
Try
- 색안경 끼지 말 것(사실 try는 아니지만 다짐 삼아 적어본다.)
- Github - Jira Integration 자동화 진행하기