2022년의 상반기가 지났다. 항상 그래 왔듯이 회고해보자.
목차
- 좋은 팀장 되기 ⭐
- 팀 공간 만들기
- R & R (Role and Responsibility)
- 리소스 관리
- 좋은 시니어로 나아가기 💻
- 서비스가 잘 되길 고민하는 개발자
- 공유 문화를 만드는 개발자
- 코드 품질을 고민하는 개발자
- 크리티컬 이슈 해결 🔥
- 배치 이슈
- 월요 장애 이슈
- 기술 블로그
- 공부하기
- 성장 욕구 ✍
- 매일매일 조금씩 하자
- 아직은 혼자가 편해
- 사이드는 미완성
- 마무리 ❤
1. 좋은 팀장 되기 ⭐
재직한 3년 동안 10명에서 80여명으로 인원이 늘었다. 그에 따라 자연스럽게 나는 ‘셀 리더’, ‘파트장’을 지나 현재 ‘팀장’이라는 직책을 얻게 되었다. 엄청난 실력 때문이라기보단 보다 더 열심히 하라는 의미로 받아들였다.
이왕이면 팀장이 되었으니 개발자로서 개발도 잘하고 싶지만 팀장으로서도 인정받고 싶었다. 그렇게 좋은 팀장이 되기 위해 고군분투했던 나의 몇가지 일들을 적어보려 한다.
1-1. 팀 공간 만들기
기록하고 공유하는 것을 좋아하는 나는 우리 팀원들 모두가 기록하고 공유하는 것을 좋아하기를 바랐다. 하지만 바람이 지나치면 강요가 될 수 있기에 좋은 방법이 없을까 고민하였다. 그러던 중 ‘인프랩실Log’을 만나게 되었다. 그곳에서는 ‘인프런’을 운영하는 ‘인프랩’의 2015년 2월 첫 시작부터 현재까지의 크고 작은 일들이 모두 기록되어있었다. ‘인프랩’이 정말 좋은 조직이라 느껴졌고 우리도 실천해본다면 기록하고 공유하는 문화를 퍼트릴 수 있을 뿐만 아니라 좋은 조직이 될 거라고 느껴졌다.
‘SaaS Team Dev Log’ 라는 이름으로, ’ 보람과 단결을 위하여 기록합니다!’라는 슬로건으로, 노션 페이지를 활용해 기록하기 시작했다. 인프랩이 ‘원자⇒분자⇒씨앗⇒새싹⇒묘목’이라는 나무의 느낌으로 나아갔다면, 우리는 기술팀이니 시기별 역사라는 ‘구석기⇒신석기⇒청동기’와 ‘주먹도끼⇒빗살무늬토기⇒청동검’이라는 기술의 역사를 구분하여 적어 보기로 했다. 단결력을 위해(?) 서로의 MBTI, 혈액형, 나이, 탕수육 부먹VS찍먹, 주량, N문N답 등을 이곳에 기록했고 이야기를 나눴다.
연초에 비해 지금은 정말로 뿌듯한 공간이 되었다. (능력자 팀원으로 인해 멋진 로고와 캐리커쳐를 얻었다.)
1-2. R & R (Role and Responsibility)
좋은 팀이라는 건 애매모호한 표현이다. 편한 팀, 재밌는 팀 같은 것도 좋은 팀이지만 회사 내 팀은 무엇보다도 생산성이 좋은 팀이 첫 번째가 아닐까 싶다. 생산성을 떨어트리는 무언가가 있다면 제거하는 게 팀장의 역할이라고 생각했다.
생산성이 저하되는 요소를 몇 개 생각해보면 1) 업무 분배의 어렵다는 것, 2) 팀원들에게 광범위한 업무를 주면 지식의 축척이 어렵다는 것, 3) 비개발팀이 업무 진행을 위해 개발팀원 누구와 소통해야 하는지 어렵다는 것이 있다. 이 부분의 답은 R&R이라는 생각이 들었고 팀원들과 회의를 통해 각 팀원들의 대표 R&R을 정해주었다. 하다 보니 어느 정도 R&R이 이미 나눠진 부분도 있지만 이 부분을 더 명확하게 해 주고 공표한다면 이점이 있을 것이라 생각했다. 또, 매주 R&R별 이슈에 대해서 공유하는 시간을 가져 지식을 축적하고자 했다.
R&R 시스템을 잘 이행해보고 싶었으나 몰아치는 과제와 팀원들의 인 앤 아웃으로 쉽지는 않았다. 개발팀 규모가 더욱 커진다고 가정하면 다시금 중요해질 부분이니 계속 관심 가지고 있어야겠다.
1-3. 리소스 관리
용어가 주는 힘이 있다고 생각한다. 일정관리와 리소스 관리라는 말은 한 끗 차이 일수 있다. 하나, 리소스 관리가 일정 관리보다 더 큰 영역이라고 생각했다. 또, 개개인의 일정을 관리하는 게 포커스라기 보단 팀 전체 리소스를 어디에 할당해야 하는가에 초점을 맞춰 관리하는 게 의미 있다고 생각했다.
팀 전체의 리소스를 한눈에 확인할 수 있는 무언가가 필요했다. 우리가 만들고 사용하는 협업 툴 플로우에 간트차트라는 기능이 있어 리소스를 녹일 수도 있었다. 하지만 대중적인 간트차트의 형태보다 좀 더 맞춤 형태가 필요하다는 생각이 들었다. 그래서 구글 스프레드 시트에 우리의 모든 리소스를 요약하며 나아가는 형태로 초안을 짜보았다. 이름은 ‘팀 리소스 차트’라는 네이밍을 가지고서 우리 팀의 리소스를 관리해나갔다.
4월 초부터 시작한 리소스 차트는 디자인은 좀 허접할지라도 매우 유의미하게 팀에 녹아들었다. 뿐만 아니라 다른 팀에게도 전파되어 전체적으로 리소스 관리라는 개념이 잘 퍼트려진 것 같다. 개인적으로 이 리소스 차트는 회의에 없어서는 안 되는 매우 중요한 요소가 되었다. (이 기능이 협업 툴 플로우 내 기능 또는 새로운 서비스로 나와도 쓸만할 것 같다는 생각이 들었다.)
2. 좋은 시니어로 나아가기 💻
개발 4년 차는 아직 시니어라고 하기엔 아직 부족한, 갓 주니어를 벗어난 풋내기일 수 있다. 하지만 결국 시니어 개발자가 될 것이고, 그 시기에 팀 동료들에게 좋은 영향력을 주는 개발자가 되고 싶다. 꼭 개발자로서가 아니더라도 경력 임직원으로서 회사가 더 좋은 길로 나아갈 수 있게 영향력을 주는 팀원이고 싶다. 가만히 바란다고 이뤄지는 것은 아니니까 조금씩 노력해보고자 했다.
2-1. 서비스가 잘 되길 고민하는 개발자 : 워커보드, 사내해커톤, 실험실
회사가 성장하지 않기를 바라는 임직원은 없다. 회사가 성장하길 바란다면 당연지사 회사의 서비스가 잘 되기를 바란다. 그러한 바람으로 서비스에 대해 생각과 고민이 쌓인다. 더군다나 스타트업에 다녀서인지 의견이 충분히 반영될 수 있다는 기대감에 더 많은 생각과 고민에 쌓이는 것 같다.
입사 때부터 지금까지 서비스가 잘 되길 바라며 많은 아이디어를 냈다. 아주 작은 구체적인 아이디어부터 조금 크고 두리뭉실한 아이디어까지. 하지만 아무리 좋은 아이디어가 있어도 말로만 하면 설득하기 어렵다는 것을 잘 알고 있다. 개발자는 아이디어를 구현할 수 있다는 장점이 있기에 가끔은 시간을 내 무언가를 만들어내곤 했다.
이번 상반기에는 그러한 바람을 담아 ‘워커보드’라는 개인별 대시보드 기능을 만들었다. 협업툴 서비스는 업무 데이터가 많이 쌓인다. 이러한 업무 데이터 속에서 다양한 인사이트를 얻을 수 있다고 믿는다. 워커보드는 개개인이 매주 어떤 업무를 진행하는지, 메일 어떤 업무가 지연되었는지, 매년 얼마나 많은 업무를 진행하는지 손쉽게 확인할 수 있다.
경영진에게 새로운 기능을 선보이고 좀 더 다듬으면 충분히 출시할 수 있는 기능이라며 칭찬을 받았다. 현재 시점까지는 오픈되지 않았지만 개인적으로 팀 내 주간보고 용도로 잘 활용하고 있다.
이러한 행동이 좋은 본보기가 되어 사내 해커톤이라는 좋은 흐름으로 나아가게 되었다. 많은 개발자들이 직접 고민하여 만든 기능들이 임직원들에게 공개하여 우리 서비스의 확장 가능성이 무궁무진하다는 것을 깨우치는 시간이 되었다. 이러한 서비스가 단순히 해커톤에 그치지 않게 환경설정의 ‘실험실’이라는 기능을 추가적으로 또 개발했다. 아직 미공개이긴 하지만 ‘워커보드’ ⇒ ‘해커톤’ ⇒ ‘실험실’이라는 흐름으로 우리 서비스의 가능성을 엿보았다.
2-2. 공유 문화를 만드는 개발자 : 플로우테크세미나
협업툴 플로우 내에 글을 작성하고 공유하는 것만으로는 부족하다고 느꼈다. 또, 현재 업무와 직접적으로 관련된 것들만 공유하는 것 또한 부족하다고 느꼈다. 새로운 것들을 지속해서 접하고 새로운 인사이트를 얻을 수 있게 다양한 분야의 테크 스킬을 들여다볼 필요가 있다고 느꼈다. 또, 미쳐 다지지 못한 기본기를 충분히 다지기 위한 정리의 시간도 필요하다고 느꼈다.
그러던 중 매우 유명한 우아한형제들의 테코톡을 보고서 우리도 한 번 해보면 어떻겠냐는 생각이 들었다. 마침 최근에 큰 작업들이 있어서 시간을 잡아 공유해야 될 내용도 있었고 개발 대장님(CTO)이 좋은 개발 문화를 위해 넌지시 세미나 같은 것을 해보면 좋겠다 말씀도 하셨다.
그렇게 제1회 플로우테크세미나를 직접 주최하게 되었다. ‘Vacuum In PostgreSQL’라는 주제로 발표자로도 참여했는데, 2명의 발표자가 더해져 성공적으로 세미나를 마치게 되었다. 세미나 내용은 간단하게 컷 편집해서 플로우 프로젝트 방에 공유했는데 추후 들어올 다른 개발자들을 위해서도 좋은 자료로 남게 될 것 같다. 매달 진행해서 좋은 문화로 자리 잡게 만들어봐야겠다.
2-3. 코드 품질을 고민하는 개발자
서비스가 고도화되고 개발인원이 늘어나면 추가되는 코드량과 수정되는 코드량이 기하급수적으로 늘어난다. 변화무쌍한 코드를 잘 정리해서 품질이 좋게 개발해나가려면 많은 고민이 필요하다. 그 고민을 할 수 있는 개발자가 시니어 개발자라고 생각한다.
작년 리뉴얼 프로젝트를 마친 시점에는 어느 정도 정리가 잘 되어 생산성이 꽤 높아졌다고 생각했다. 하지만 더 공부하고 더 고민하고 다시 보니 많이 부족했음을 느꼈다. 그리고 현재 코드의 상태도 중요하지만, 앞으로 개발자들이 어떻게 코드를 개발 해나 갈 건지를 결정하는 코딩 문화가 더더욱 중요함을 느꼈다.
혼자 연구하기보다는 같이 연구하는 게 낫다. 같이 연구하는게 더 좋은 결과물이 나온다는 측면도 있지만 같이 연구하면 문화가 되고 혼자 연구하면 아집이 된다. (물론 영향력이 엄청난 네임드 개발자는 혼자 연구해도 문화가 된다. ㅎㅎ)
코드 품질을 높이기 위해 다양한 방법을 제시하고 때로는 직접 구현해보며 공유하고 다듬어 나가고 있다. 주어진 업무도 해내면서 이러한 고민도 같이 병행되어야 하기 때문에 시행착오가 많다.
하반기에 더 노력해야 될 것 같다.
3. 크리티컬 이슈 해결 🔥
상반기에는 연초 OKR 기능 개발 빼고는 크리티컬 이슈를 해결하는데 많은 집중을 했던 것 같다. 크리티컬 이슈를 처리하면서 아직도 많이 부족하고 배울게 많다는 것을 느꼈다.
3-1. 배치 이슈
협업툴 플로우는 배치 프로세스를 활용해 FCM(푸시)를 컨트롤하고 있다. 누락되는 메시지가 꽤 있었는데 그 부분을 잡기 위해 다양한 스텝을 밟아가며 개선해나갔다.
- 알림, 채팅 카운트 로직 개선
- 1,000건 넘는 카운트를 가진 유저는 별도로 기록하여 관리한다.
- FCM 멀티 쓰레딩 처리
- 공유자원(PreparedStatement) 이슈 처리 ⇒ 독립적으로 자원 선언
- 보조 스케쥴링 프로세스 생성
- 5분 주기 프로세스 체크
- 30분 주기 통계 로그 인서트
- 매일 01시 리포트 발행
누락률이 10% ~ 20% 수준에서 0% 수준으로 개선되었다.
3-2. 월요 장애 이슈
4월 ~ 6월 동안 매주 월요일 9시 ~10시 사이에 DB 장애가 발생하였다. 공교롭게도 배치 누락률을 0% 만들고 나서 발생했기 때문에 처음에는 배치로 인한 부하가 영향이 있다고 생각했다. 하지만 최종적으로는 테이블의 팽창이 문제였다고 보인다.
중간 과정을 보면, 수많은 개선을 통해 개선되는 부분은 분명 있었지만 원론적인 문제를 해결 못해 계속 월요 장애 이슈를 직면했다. 마지막 즈음에 스케일업과 원론적인 문제도 같이 해결되면서 대폭 개선되었지만 스케일업이 병행된 부분이어서 조금 아쉬운 부분은 있었다. (AWS RDS 스케일업은 진짜 최고인 것 같다.)
구체적으로 적어보면, 중간과정에 푸시 배치 개선, autovacuum 설정값 개선, 슬로 쿼리 개선, 불필요 대량 인서트&업데이트 삭제, statement_timeout 30초 설정 등을 진행했다. 최종적으로는 vacuum full을 통한 테이블 & 인덱스 팽창을 정리했다. 이 과정에 얻은 다양한 내용들을 공유하고 위에 언급한 플로우테크세미나에 ‘Vacuum In PostgreSQL’ 세션 발표로 마무리를 지었다. 많이 배웠다.
3-3. 브랜치 이슈
SVN에서 GIT으로 넘어온 지 2년이 지났다. 깃 명령어를 다루는 데 있어 많이 익숙해졌다. 하지만 개발자들이 늘어나고, 배포 주기가 짧아지고, 엔터프라이즈 업체가 늘어나면서 좀 더 전략적인 접근이 필요했다.
기준 삼을 전략을 찾아보던 중 GIT FLOW 전략과 GITHUB FLOW 전략을 만났다. 그중에 테스트 자동화가 준비되어있진 않아 GIT FLOW 전략을 선택했다. GIT FLOW 브랜치 전략을 기준으로 서비스에 맞게 약간 변형을 했다. 브랜치 그래프를 그려가며 팀원들과 토의했고 최종적인 브랜치 전략을 정했다.
이전 방식 대비 릴리즈, 핫픽스 구간이 확실하게 생겼고 그로 인해 안정성이 굉장히 높아졌다. 이전에 릴리즈 기간 동안 운영과 동일한 상태가 없다는 문제점이 가장 컸는데 그 부분도 해결되었다.
하반기에는 엔터프라이즈별 브랜치 전략도 고도화해서 서비스의 안정성을 더 높여야겠다.
4. 성장 욕구 ✍
성장에 대한 욕구가 강해 작년에는 굉장히 많은 강의 수강으로 승화시켰던 것 같다. 언제까지 강의 수강만 할 수는 없다는 생각이 들었다. 이제는 스택을 정하고 공부와 함께 병행하여 나만의 작은 사이드 프로젝트를 진행해야겠다는 생각이 들었다. 최종적으로 선택한 스택은 프론트는 Vue, 백은 Nest.js, 디비는 PostgreSQL이다.
4-1. 매일매일 조금씩 하자
퇴근 후 미친 듯이 몰입할 수 있었다면 좋았겠지만 연초에는 OKR 프로젝트로 야근할 일도 좀 있었고 아기도 아직 돌이 되지 않았기에 하루에 30분씩 컴퓨터는 붙잡고 공부 의지를 불태웠다. 1분기 끝날 무렵 아가가 밤중 수유를 끊고 분리 수면을 시작한 뒤 어느 정도 규칙적인 생활이 진행되었을 때 저녁 11시 반부터 새벽 2시 정도까지가 나의 주 공부 시간대였다. 깃 잔디가 나의 상반기를 증명하는 듯하다.
- 기술 블로그 꾸준히 기록하기 (12건)
- 강의 수강하기
- 인스타그램을 만들며 배워보는 Vue.js 3 완벽 가이드 - 코딩애플
- 매우 쉽게 이해하는 JavaScript 객체지향 & ES6 신문법 - 코딩애플
- Svelte.js 입문 가이드 - HEROPY (인프런)
- Typescript with Vue 실전 프로젝트 - 성도희 (인프런)
- Node.js로 웹 크롤링하기 - 조현영 (인프런)
- Vue.js 3 완벽 마스터: 기초부터 실전까지 - "기본편” - 짐코딩 (인프런)
4-2. 아직은 혼자가 편해
어떤 주제로 사이드 프로젝트를 진행할까 계속 고민하다 ‘동료들의 다양한 플랫폼 블로그를 보기가 어렵다’는 작은 불편함을 시작으로 무언가를 만들기 시작했다.
과거 친한 형과 간단한 사이드 프로젝트를 통해 재밌는 경험을 해본 적이 있었다. 그 기억을 되살려 형에게도 피드백을 구했다. 간간히 만나서 툭 하고 아이디어를 던질 땐 매번 비판적인 피드백을 주던 형이 이번만큼은 긍정적인 피드백을 주었다. 그러면서 같이 한번 해보자는 이야기를 했다.
일단 가볍게 오케이를 했지만 겨우 두 사람임에도 불구하고 서로 시간 맞추기가 쉽지가 않았고 중간에 1~2번 만나기는 했지만 그때 기획과 디자인 방향성 등을 논하다 보니 진도가 좀처럼 나가지 않았다. 그래서 일단 모든 것은 나의 감(?)에 의해 만들어지고 있다.
4-3. 사이드는 미완성
아직은 말 그대로 미완성이다. 디테일을 조금씩 챙기다 보면 일주일이 금방 지나가버린다. 어느 정도 선에서 맺고 끊어서 하반기는 기필코 사이드 프로젝트 링크를 공개해봐야지!
5. 마무리 ❤
아가는 돌이 지나 엄청난 개구쟁이가 되었다. 요즘은 저녁 7시면 잠들어서 퇴근하고는 보지 못한다. 아침 6시 반이면 아가는 일어나는데 자고 있는 나를 깨워 9시 반에 집을 나설 때까지 괴롭힌다(?) 요즘은 엄마보다 아빠를 더 잘 말한다. 자기주장이 생겼고 그래서 떼를 쓴다. 매번 귀엽고 사랑스러워서 ‘사랑해’라는 말을 안 할 수가 없다.
아내는 나의 일을 존중하고, 나의 공부를 존중하고, 나의 생각을 존중한다. 다만, 나의 무신경한 행동들은 용서하지 않는다. 더욱 정신을 곤두세워 좋은 아빠, 좋은 남편이 되고 싶다.
하반기에도 가족과 함께 행복한 시간 계속 보내고 싶다
끝.
'Retrospective' 카테고리의 다른 글
| [개발자회고] #11. 2023 상반기 회고 (feat. 고민과 증명) (0) | 2023.07.01 |
|---|---|
| [개발자회고] #10. 2022 하반기 회고 (feat. 꾸준하게) (2) | 2023.01.02 |
| [개발자회고] #8. 2021 하반기 회고 ( feat. 문샷싱킹, 언주니어 ) (8) | 2022.01.03 |
| [개발자회고] #7. 2021 상반기 회고 ( feat. 3년 차 개발자 ) (3) | 2021.07.21 |
| [개발자회고] #6. 스타트업 입사 2주년 회고 ( feat. 파트장! ) (0) | 2021.06.04 |
