회고 (回顧)
1. 뒤를 돌아다봄.
2. 지나간 일을 돌이켜 생각함.
회사 컨플루언스 공간에 팀 회고를 기록하였지만 이 공간은 개인적인 공간이기에 좀 더 편하게 '나'라는 관점에 맞춰 회고를 하고자 한다.
작년과 마찬가지로 정신없이 바쁜 한해를 보냈었지만 올해는 작년과는 다르게 운영팀이 아닌 개발팀 팀장으로써 바쁜한해를 보냈었고 운영팀 업무를 진행하면서 개발할 때는 미쳐 인지하지 못했던 다소 소홀했던 부분들에 대해 다시 개발팀을 맡게 되면서 말그대로 쏟아낼 수 있었던 한해 였다. (하지만 아직은 갈 길이 멀다.)
뒤돌아 보면 용감을 넘어 무모함이 있었고 그 과정속에 시행 착오도 다수 존재하였지만 그럭저럭 잘 보낸 듯 하여 한편으로는 안도되는 듯 하다.
인재 영입 (2 to 6)
작년 본부 조직개편이 단행되면서 개발팀으로 다시 복귀를 강행하였다. 당시 운영팀은 최고의 팀웍을 자랑하고 있었고 나와 구성원 모두가 좋았다. 하지만 나는 개발팀으로 가고자 하였다. 운영팀을 맡으면서 상당기간 개발해왔던 서비스를 좀 더 거시적 관점으로 바라보게 되면서 결자해지(結者解之)해야 한다는 생각이 마치 신념처럼 자리 잡고 있었기 때문이다.
나만의 이러한 신념 탓에 함께 일하던 동료들을 두고 나올 수밖에 없었고 junior였던 c만 데려 갈 수 있었다. 이렇게 팀 구성원은 c와 나 고작 둘로 시작하게 되었다. 다행히 TO는 6명 받을 수 있어 4명을 충원할 수 있었고 이 과정에 여러 우여곡절이 있었다.
시작은 2019년 신입공채 2명을 배정 받을 수 있었고 그들은 비록 회사에 채용 되었지만 나는 그들을 영입하고자 하였다.
우선 팀에서 어떤 업무를 담당하는지 기록된 페이지를 영입 대상자들에게 공유하였고 c와 내가 함께한 작은 회의실에서 영입 대상자를 한 명씩 불러 그들의 의사를 물어보며 성향을 파악하여 팀웍을 고려할 수 있었다.
3번째 구성원도 위와 비슷한 방식으로 영입 하였다. 물론 인원이 늘어난 만큼 지난번 보다는 넓은 회의실을 잡았다.
이렇게 영입된 3명의 구성원은 모두 신입이다.
아무래도 팀 밸런스를 맞추기 위해 중간관리자를 영입하기 위하여 무뎐히 노력 하였지만 결국 실패로 돌아갔다. 영입 하고자 하였던 그는 이전, 그리고 그 이전에도 나와 같은 팀에서 일하던 동료였다. 아니 어쩌면 동료 그 이상이었을 지도 모르겠다. (인간적으로) 그와 나는 언제나 발전적으로 나아가기 위해 고민했고 실천하고자 치열하게 발버둥 쳤었다. 하지만 그는 그 스스로가 권한이 없다 생각하고 한편으로는 소극적으로 보여지는 듯 하여 안타까운 생각에 더욱 그를 영입하기를 몹시나 희망하였고 다방면으로 노력하였으나 모두 수포로 돌아갔었다. 결국 그는 그의 그릇을 품어줄 수 있는 회사로 이직하게 되었다. 그가 나가기전 했던 말이 몹시나 속상하게 하는듯 하다. "팀장님과 함께 일했더라면 이직을 결심하지 않았을 거에요.." 어쨌든 나를 대신할 중간 관리자 영입은 이렇게 실패로 돌아갔다.
회사의 제한적인 채용 프로세스를 통하여 몇 번의 거듭된 실패 후 sj대리를 영입할 수 있었다.
이렇게 나와 비록 junior 지만 결코 junior 답지 않은 5명의 동료들을 끝으로 팀이 구성될 수 있었다.
업무 시각화
신임 대표님께서 선임되시고 변화의 바람을 타고 TF가 진행되면서 다수의 업무가 몰려 전화가 쇄도하면서 상당히 난감해 하던 찰나에 업무 시각화라는 책을 읽게 되었다.
목차는 다음과 같다.
• 시간을 훔쳐가는 다섯 도둑들
• 시간 도둑을 드러내는 방법
• 측정 메트릭, 피드백 그리고 주변 환경
이 책에서 소개된 시간을 훔쳐가는 도둑들을 찾아내고 이러한 도둑들을 드러내기 위해 칸반보드를 작성하기에 이르렀다.
말끔한 벽에 커다란 화이트보드를 설치 하여 포스트잇을 덕지덕지 붙여 놓아 보는 이에 따라 다소 의아함을 자아낼 수 있겠지만 팀 구성원들 간엔 나름 만족감을 나타내는 듯하다.
(물론 Jira를 통해 확인할 수 있겠지만 어떠한 action없이 업무 공간 내에서 상시로 확인 할 수 있고 나는 아날로그 갬성을 추구하기에 고집하였다.)
장점으로는,
• 팀 구성원 간 업무를 사전에 인지
• 백로그 대기열에 포함되어 업무를 누락하지 않고 진행이 가능
아무래도 업무를 누락하지 않고 진행이 가능한 점이 가장 큰 듯하다.
그 밖에도 개인마다 차이는 있을 수 있겠지만 "진짜 완료"로 옮길 때 희열이 느껴진다고도 한다. (긍정적)
데일리 스크럼
개인적으로 소모적인 회의를 극도로 싫어하지만 중간 관리자가 부재한 팀에서는 데일리 스크럼이 반드시 필요로 했다.
진행 방법
회의실을 잡지 않고 주변 자리에서 간단히 (가급적 10분을 넘지 않도록!) 자신이 하고있는 업무 진행사항을 보고합니다. (앉아서)
다음과 같은 주제로 진행합니다.
• 어제 내가 달성한 일은 무엇인가?
• 오늘계획한 일은 무엇인가?
• 일하면서 격는 문제나 어려운점은 무엇인가?
목적
• 목표 공유
• 협업
• 문제점을 도출하고 해결 방법 도출
팀 구성원들과 데일리 스크럼 진행 관련하여 논의하였고 오늘 계획한 일에 대해서만 치중되었는데 앞으로는 '어제 내가 달성한 일은 무엇인가?', '어려운 점은 무엇인가?'에 대해서도 이야기하고자 한다.
다만 가끔 주제가 엉뚱한 데로 새지 않도록 보안이 필요하며 이는 다소 수다스러운 나의 문제가 큼으로 가장 마지막에 발언하는 것으로 조율하였다. (시간이 남는다면...)
의사소통은 팀원들을 위한 것이지, 관리자가 팀의 진척 상황을 점검하고 통제하기 위한 것은 아니다.
그룹 스터디
상반기 그룹 스터디를 제안하여 업무 시간의 일부 활용하여 진행되었으나 그 결과는 실패하였다.
실패 사유로는 몇 가지 이유를 들 수 있다.
• 동기 부여 부족
• 바쁜 업무
• 런닝 메이트의 부재
그룹 스터디가 실패하게 된 가장 큰 원인 중 하나는 무엇보다도 동기 부여 부재로 볼 수 있다. 당시 각자 저마다 필요로 한 지식이 조금씩 달랐으며 반드시 학습이 선행되어야만 한다는 이유에 대해 설득력 있게 전해지지 않은 듯하다.
다만 한가지 명심해야 할 것은 기회는 언제든 준비된 자에게만 주어진다. 기회를 잡을 수 있도록 항상 준비가 필요로 하다.
당시 바쁜 업무도 한 몫 하였다. 아무래도 업무 시간을 할애 하다 보니 우선 순위가 뒤로 밀려 지속할 수 없었던 것 같다.
런닝 메이트도 어찌 보면 멘토 역할과 유사하다고 볼 수 있는데 좀 더 주도적으로 진행되길 바랬고 학습에 관련해서는 일방적 우위로 누군가를 가르친다는 생각보다는 공유한다는 관점으로 접근했으면 하는 생각에 런닝 메이트라 정의 하였다.
얼마전 또 다시 그룹이라고 하기엔 거창한 소박한 스터디를 결성하여 진행하고 있다. 과거 실패 사례를 번복하지 않고자 학습에는 뚜렷한 목표를 두고 대표적인 사례를 조사하며 이를 토대로 실제 업무에 접목하고자 한다. 이번엔 내가 함께 참여하고 있으며 "팀장님은 어디까지 보셨어요?" 라고 질의를 하는 걸 보면 러닝 메이트 전략도 적절히 반영되는 듯하다.
코드 리뷰
작년과 비교한다면 담장 밖을 넘어야 하지 않아야 할 코드는 넘어가지 않은 듯하다.
아무래도 팀 내 담당하는 서비스 전반에 대한 이해도가 높고 실제 상당 부분 개발에 참여하였던 나의 역할도 한 몫 한 듯하였고 (만약 그렇지 않다면 장담 할 수 없을 듯) 맡은 업무에 대해 책임감 있게 진행해 주었던 동료들 덕에 가능했으리라 생각된다.
아울러 연초 운영팀에서 코드 리뷰를 망설이던 psy대리를 겨우 설득하고 사정해서 비공식 적으로 나마 코드 리뷰를 받을 수 있어 그의 역할도 한 몫 한 듯하다. 다만 이를 비공식화 한 것은 이러한 역할에 대한 책임을 지워주지 않고 그에 대한 책임은 오롯이 개발팀에서 지기 위함이었다.
팀 구성원 들에게 항상 제품 생애 주기(end to end)를 책임 질 줄 아는 개발자가 되어야 한다고 이야기한다. 내년에는 좀 더 체계적인 코드 리뷰 방안에 대해 고민해 보고자 한다.
학습의 길
나를 제외한 모든 구성원이 junior들로 이뤄져 본인들은 체감하지 못하겠지만 그들은 굉장히 중요한 시기를 보내고 있다. 스폰지와도 같은 시기에 습관을 어떻게 형성하느냐가 가장 중요하다.
제도적 장치를 두어 학습 습관을 심어 주고자 하였고 나 또한 예외일 수 없기에 모범을 보이고자 함께 참여하였다. 내년에는 좀 더 개인의 자율에 맡기고자 한다.
일이 어느정도 익숙해지면 학습에 소홀해 지기 마련이다. 하지만 대부분의 개발자는 무언가를 배우고 잘하고 싶어 하기에 꾸준히 노력하고자 하며 어쩌면 내가 그들에게 좋은 자극제가 되길 바란다.
습관은 관성이 되고
관성은 도전을 싫어하지
우리는 모두 이렇게 꼰대가 된다...
일 만드는 개발자 vs. 일 부풀리는 개발자
회고
작년에 이어 회고는 KPT 방식으로 지속되었다.
올해 한 가지 달라진 점이 있다면 회고 시 사전 신청을 받아 참관하도록 하였고 이는 문화적 확산을 하고자 하는 목적이었으나 아쉽게도 기대와는 달리 확산이 되지 않은 듯 하다.
회고 시 가장 중요시 했던 부분은 성토의 장이 되지 않도록 하는 것이었다. 또한 개선(Try) 방안에 대해서는 조직 내 해결할 수 있는 방안에 대해 초점을 맞춰 진행하였다.
앞으로도 보안해가며 지속하며 문화적 확산을 기대하며 참관 신청도 꾸준히 받을 예정이다.
Beyond 자체 F/W (Feat. Spring Boot)
자체F/W은 다년간 결제 서비스를 제공해왔던 여러 기술 노하우를 축적하여 만든 결제 서비스에 최적화된 F/W이다.
2015년 처음 출시되어 다양한 결제 서비스에 적용되어 충분한 검증이 이뤄졌다고 볼 수 있다.
다만 현재에 이르기까지 소위 바깥 세상에서는 급변하게 기술 발전이 이뤄지는데 반해 큰 변화 없이 제자리에 머무르는 듯 하여 그에 따른 아쉬움이 있었다.
올해 신규 프로젝트를 진행하면서 Spring Boot 를 도입하게되어 나름의 가능성을 타진해 볼 수 있었다. 다만 이 과정에서 공들여 만든 자체F/W를 버린(?)듯 하여 아쉬움을 보이신 분도 물론 있었으나 제공되는 상당한 기능이 이식되어 결코 버렸다고는 할 수 없다.
이 과정에 많은 우려의 시선을 감당해야만 했고 나 역시 상당한 부담을 감수 해야만 했었다.
물론 무조건 적으로 Spring Boot 를 도입했던 것은 아니였다. 구성원 간 충분한 논의가 이뤄 졌었고 결과적으로 좀 더 나은 방향으로 결론이 도출 되었다고 볼 수 있다.
이러한 과정을 이뤄나갈 수 있었던 것은 구성원 모두와 긴급 투입된 na대리의 활약 덕분으로 비교적 괜찮은 사례로 남길 수 있었고 당시 힘들고 괴로웠던 기억마저 이젠 추억으로 남길 수 있어 동료들에게 다시 한번 감사하게 생각하고 있다.
2021년을 맞이하며
오랜 기간 한 곳에 머무르면서 나 스스로가 틀에 박혀 있다 거나 매너리즘에 빠진 건 아닐까 스스로 반문하게 된다. 어쩌면 지독한 패배의식에 빠져든 건 아닐까 반대로 작은 우물안에서 성공의식에 도취되어 버린 것은 아닐까 라는 생각도 든다. 여러모로 어려운 숙제와도 같다. 현재는 스스로가 불행하고 힘든 시기를 보내고 있는 듯 하지만 휴식(refresh)을 통해 훌훌 털고 일어날 참이다.
다행인건 좋은 동료들을 만날 수 있었고 올해도 구성원 모두가 만족감을 느끼며 (아마도?) 좋은 캐미를 자랑할 수 있었고 회사에서도 나름 인정 받는 듯하다. 이점에 대해 항상 감사하게 생각하고 있다.
단정할 수 없겠지만 내년에도 항상 고민하며 치열한 한해를 보내고 있지 않을까 예상한다. 또한 올해 만난 junior들의 성장세가 뚜렸이 나타나 내년의 그들의 모습이 기대된다.
나 역시도..
"더 잘하고 싶은 스스로의 욕구를 바탕으로 최고의 결과물을 내기위해 노력한다." - 도서 Clean Agile
