<div id="readability-page-1" class="page"><p><span>19 min read</span>|<span>23. 12. 14.</span></p><article><p>어김없이 올해가 다 지나가고 회고 시즌이 왔다. 올해는 분기별로 회고를 진행하고 있었어서 오래 걸리진 않았다. 연말에 다이빙 여행이 있어어 조금 일찍 회고를 정리해보았다. 2023년은 3가지 역할로 구분지어 회고했다.</p>
<p><em>previously on Jbee.log</em></p>
<ul>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2022)">Jbee.log(2022)</a></li>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2021)">Jbee.log(2021)</a></li>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2020)">Jbee.log(2020)</a></li>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2019)">Jbee.log(2019)</a></li>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2018)">Jbee.log(2018)</a></li>
<li><a href="https://www.jbee.io/articles/essay/Jbee.log(2017)">Jbee.log(2017)</a></li>
</ul>
<h2>개발자</h2>
<blockquote>
<p>아직 한 스푼 남은 코딩 경력</p>
</blockquote>
<p>지난 1년, 개발해야 하는 일이 아예 없진 않았다. 상반기에는 팀의 사정에 따라 우선순위에 따라 긴급도가 높은 작업들을 주로 진행했고 하반기에는 하나의 프로젝트를 개선하는 작업에 도전해봤다.</p>
<h3>재구조화 작업</h3>
<p>곧 별도 아티클로도 발행될 예정인데, 제품 하나를 개선하는 작업을 진행했다. 이 아티클에는 팀에 공감대가 형성되는 과정, 제품 '개선'이라는 목표 잡기 어려운 프로젝트를 어떻게 진행하고 신경썼는지 담길 예정이다. 그래서 회고 글에서는 간단히만 언급하려고 한다. (https://toss.tech/article/restructuring-planning)</p>
<p>잘 알려져있듯 이미 달리고 있는 기차의 바퀴를 교체하는 작업은 쉽지 않다. 그래서 많은 리소스를 투입해야 어느 정도 진척이 보인다. 목표를 설정하는데 많은 시간을 투자했는데, 첫번째 목표는 테스트 코드의 신뢰도 회복과 테스트 코드를 작성하기 용이한 설계로 바꾸는 것이었다. 그 외 나머지, 깨진 스타일 수정이라던가 모듈화 작업, 중복 코드 제거 등의 '리팩토링'이라 부르는 작업들은 전부 후순위로 미뤄뒀다. 먼저 안전 장치를 확보해야 나머지 작업들이 수월해질 것이라는 가설이었다. 설계의 방향성만 잡고 대부분의 작업은 팀원분들이 해주셨는데, 참 대단한 것 같다.</p>
<p>잘 마무리하고 양고기 회식까지 했지만 그래도 아쉬웠던 지점이 있었는데, 역시나 리소스 관리였다. 기능 조직이 아닌 제품 중심의 조직 구조에서 어떤 하나의 제품을 개선한다는 것이 참 어려웠다. 아무리 팀에 공감대가 형성됐다 하더라도 우선순위를 논의할 때, 비즈니스 앞에서 기술적인 논리는 힘이 약했다. 중간을 타협하는 과정에서 많은 대화를 나눴고 협의가 이뤄졌으니 이만한 결과가 나왔다고 생각한다. 이번 기회를 통해 새로운 것을 많이 시도해보았고 기술적으로도 팀의 관점에서도 꽤 소중한 경험이었다. 이 제품이 좋은 선례가 되어줄 것이라 생각하고 다음 번에 이런 작업이 필요해진다면(그럴 일이 없으면 더 좋겠지만) 더 잘해볼 수 있을 것 같다.</p>
<h2>리더십</h2>
<blockquote>
<p>작년이 신입 리드로써 적응하고 익숙해지는 시간이었다면 이 기간동안 학습한 것들을 기반으로 더 나은 리드가 되는 해가 될 예정이다. 궁극적으로 내가 추구하는 것이 무엇인지 계속해서 물어보면서 여러 가지를 경험할 생각이다.</p>
</blockquote>
<p>라는 내용이 작년 회고에 있었는데, 나는 과연 더 나은 리드가 되었을까? 여러 가지 경험을 하긴 했는데, 궁극적으로 내가 추구하는 것이 무엇인지 찾았을까.</p>
<h3>코딩, 그립긴 하지만</h3>
<p>코드를 작성하는 것이 그립기는 하나, 이젠 하지 않는 것에 대해 더이상 불안하진 않다. 코딩이 그리운 이유는 시간이 참 잘 가서 였던 것 같다. 한 가지 문제를 만나면 그것을 디버깅하기 위해 몰입하곤 하는데, 시간이 순식간에 증발하곤 한다. 이렇게 몰입하여 문제를 해결하고 나면 대단한 일을 해낸 것처럼 뿌듯함이 밀려온다. 이 도파민에 중독되어 그동안 개발을 좋아했던 것 같다.</p>
<p>개발을 하고 나면 눈 앞에 바로 보이고 내가 없으면 제품을 만들 수 없고 내가 못 하겠다고 하면 일정이 밀리니 효능감 그 자체였다. 이런 면에 있어서 개발은 참 보람차고 재밌는 것 같다.</p>
<h3>남몰래 세운 목표, retention</h3>
<p>내가 기술 조직 리드로써 추구해야 하는 지표가 있을까?라는 고민을 한 적이 있다. 수많은 제품들이 데이터를 기반으로 의사결정을 내리고 OKR을 세우고 달린다. 이런 환경에 있다보니 나도 뭔가 신경써볼만한 데이터가 있을까 싶어 고민을 해봤는데, 그 결과 '리텐션'이라는 결론을 냈다.</p>
<p>말이 리텐션이지 HR 용어로 번역하자면 '근속년수'이다. 다소 올드(old)한 지표라고 생각되지만 이 지표가 중요하다고 생각한데엔 이유가 있는데, 오래 다닐수록 구성원의 생산성이 높아진다는 것이다.</p>
<p>팀에 오래 있을수록 생산성이 높다. 과정 속에서 성장도 하겠지만 팀이 어떻게 일하는지, 누가 무엇을 잘하는지, A가 막히면 누구에게 도움을 청해야 하는지 등 팀을 활용하는 방법을 알게 된다고 생각한다. 일은 혼자하는 것이 아니기 때문에 개인의 퍼포먼스 뿐만 아니라 팀원을 어떻게 활용할 것인지도 생산성에 지대한 영향을 미친다. 그러다보니 오래 다닌 팀원일수록 생산성이 높다고 생각했다.</p>
<p>리텐션을 중요하게 관리하기 위해 여러가지 계획을 세우기도 하고 실행에 옮기기도 했다. 외부 동기부여 요소(연봉, 복지 등)들은 내 제어권 하에 없었기 때문에 다른 영역에 신경을 썼다. 프론트엔드 개발 영역을 전문화해보기도 하고 챕터 내 라포 형성을 위해 여러 가지 장치를 만들어보기도 했다. 그 중에서 가장 중요하게 생각한 것은 챕터 구성원들의 강점을 알아차리고 이 강점을 극대화 하여 구성원들의 효능감을 높이는데 집중했다. 이 강점찾기 프로젝트는 아직 진행중이다.</p>
<p>이러한 관점에서 채용의 기조도 다르게 가져갔다. 채용 시 지원자의 지금 당장의 개발 역량도 중요하지만 얼마나 우리와 오래 함께 재밌게 잘 할 수 있을까?를 중심적으로 보게 되었다.</p>
<p>이 노력의 결과는 시간이 말해주지 않을까.</p>
<h3>애자일 맛보기</h3>
<p><a href="https://www.ac2.kr/">김창준님의 ac2 코스</a>를 수강하신 분께 애자일에 대한 강의를 들었다. 그 중 인상 깊었던 세션은 Essence of agile 이라는 세션이었다. 외부 아티클로도 기고가 됐는데, 내 일을 바라보는 관점을 다르게 만들어 주는 계기가 되었다.</p>
<p>앞서 소개한 제품 재구조화 작업도 불확실성이 많은 프로젝트였지만 Essence of agile 프레임워크를 통해 접근했고 좀 더 체계적으로 준비할 수 있었다.</p>
<p>Learning 12 factor라는 세션을 듣고 나서도 여러 부분에 활용을 해보았는데, 그 중 피드백을 좀 더 잘하기 위해 AAAAA 프레임워크를 만들어봤다. 피드백에 대한 피드백을 듣고 잘하는 사람에게 의견을 물어보기도 하고 직접 프레임워크를 사용해보기도 하면서 피드백을 좀 더 잘하기 위한 연습을 했다.</p>
<p>Read less는 책을 끝까지 다 읽어야 한다는 약간의 미련을 완전히 떨쳐낼 수 있게 된 세션이었다. 최근엔 소프트웨어 테스팅 책, 과학 분야의 책 등을 주로 읽었는데, 책을 정보 습득의 측면에서 읽을 때 더 효율적으로 읽을 수 있게 됐다. 내년에는 이 Read less 원칙을 기반으로 기술 서적 스터디를 만들어보려고 한다.</p>
<h3>의사결정 원칙</h3>
<p>의사결정을 내려하 나는 경우가 많았고 관련해서 나만의 원칙을 정해보았다.</p>
<ol>
<li>롤백할 수 없는 의사결정이 있다면 롤백할 수 있는 의사결정으로 문제를 단순화 하거나 나눌 수 없는지 돌아볼 것</li>
<li>그럼에도 불구하고 롤백할 수 없는 의사결정이라면 그 결정은 최대한 심사숙고 할 것</li>
<li>롤백할 수 있는 의사결정들은 최대한 빨리 결정하고 실행에 옮길 것</li>
<li>단 이 때 결정한 사항에 대해 기간을 정해두고 다시 회고해볼 수 있는 날짜를 정할 것</li>
<li>다시 리비짓 했을 때, 결정에 문제가 있었다면 쿨-하게 롤백할 것</li>
</ol>
<p>모든 의사결정에 적용하진 않지만 사고의 흐름을 정리하는데 있어서 많은 도움이 되었고 나에게 도움됐을 뿐만 아니라 고민이 길어지는 경우 조언을 해줬을 때도 많은 효과를 보았다.</p>
<h2>개인</h2>
<h3>발표</h3>
<p>그래도 올해 4번의 외부 발표, 4번의 내부 발표 그리고 8개의 글을 썼다. 나름 선방했다. Obsidian을 정말 적극적으로 사용했다. 아직 제텔카스텐 방식의 메모엔 아직 익숙하지 않은데 접근성이 좋고 빠르게 글을 작성할 수 있어서 출퇴근 시간에 글을 쓰거나 발표 준비할 때 사용하기 용이했다.</p>
<ul>
<li>4개의 외부 발표
<ul>
<li>유난한 엔데 - 프론트엔드 다이빙 클럽</li>
<li><a href="https://www.jbee.io/articles/presentation/%5B%EB%B0%9C%ED%91%9C%5D%20%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%9D%98%20%ED%95%99%EA%B3%BC%20%EC%8A%B5">개발자의 학과 습</a> - 너디너리</li>
<li>프로그래머스 - 우리의 테스트가 어려운 이유</li>
<li>오늘도 테스트를 쓰려고 마음 먹는다. 그러나, - 프론트엔드 다이빙 클럽</li>
</ul>
</li>
<li>5개의 내부 발표
<ul>
<li>Qwik framework 에 대한 소개</li>
<li>카페24브랜드페이 Greenfield project를 하면서 시도했던 것들과 좋았던 것들</li>
<li>Front End 개발 현황 - 대마고 견학 대상</li>
<li>회고를 통한 결실</li>
<li>일 야무지게 하는 법 (feat. QWER)</li>
</ul>
</li>
<li>8개의 글</li>
</ul>
<p>테스트와 관련된 책도 많이 읽고 관련 컨텐츠를 만드는 데에 집중을 하기도 했다. 테스팅이 중요한 것에 비해 이 생태계에서 비중있게 다뤄지고 있지 않는 것 같다. 특히 프론트엔드 생태계에선 더 심한 것 같다. 이런 생각으로 집필까지 생각하고 출판사와 미팅을 갖기도 했다. 결국 후일을 도모하긴 했지만 작성하고 있는 컨텐츠는 계속 쓰고 있다. 내년이든 내후년이든 출판할 날이 오면 좋겠다.</p>
<h3>블로그 마이그레이션</h3>
<p>블로그는 최근에 부랴 부랴 Obsidian publish 로 마이그레이션 했다. 도메인도 Cloudflare로 마이그레이션 하고 이것 저것 같이 진행했다. <a href="https://www.jbee.io/articles/tool/Obsidian%20publish%20%EC%82%AC%EC%9A%A9%EA%B8%B0">Obsidian publish 사용기</a>를 적어보았다. 만족스럽진 않다.</p>
<h3>스쿠버 다이빙</h3>
<p>1년 뒤 리프레시 계획을 세워봤다. 하고 싶은 것들이 꽤 많더라. 기다리지 않고 하나씩 해보았다. 당장 시작할 수 있는 것들이 꽤 많았다. 그리고 올해 8월, 스쿠버 다이빙에 도전했고 정신차리고 보니 모든 장비를 다 맞췄다.</p>
<p>글의 서두에서 말했다시피 곧 있을 연말 연휴에도 필리핀으로 다이빙 여행을 갈 예정이고 내년 구정, 추석에도 다이빙 여행 일정이 잡혀있다. 혹시 스쿠버 다이빙에 관심이 생겼다면 <a href="https://www.jbee.io/articles/diving/%EC%8A%A4%EC%BF%A0%EB%B2%84%20%EB%8B%A4%EC%9D%B4%EB%B9%99%20%EC%9D%B4%EC%95%BC%EA%B8%B0">스쿠버 다이빙 이야기</a>를 읽어보길 추천한다!</p>
<h4>그린피스</h4>
<p>내친김에 미루고 미루던 <a href="https://supporter.ea.greenpeace.org/kr/s/donate?campaign=ocean">그린피스 해양보호 캠페인에 후원</a>을 시작했다. (~~홈페이지에 개선하고 싶은게 참 많았는데 Frontend Engineer는 채용이 열려있지 않았다.~~) 작고 귀여운 금액이지만 꾸준히 하면 의미있지 않을까 하는 생각에 시작했다.</p>
<p><img src="https://jbee.io/articles/essay/Jbee.log(2023)./images/greenpeace_support.png" alt="그린피스 후원"></p>
<h2>2024 목표</h2>
<p>올해를 마무리하고 나서 목표가 꽤 명확해졌다. 그리고 명확해진 목표와는 별개로 그 목표를 달성했을 때 어떤 성장을 이뤘을지, 어떤 결과물이 나올지는 또 명확하지 않더라. 다만 목표를 위해 더 많은 사람들과 이야기해보고 경험하지 못한 것들을 추구하려고 한다.</p>
<ul>
<li>연 단위 목표
<ul>
<li>팀이 성공하는 것에 집중해보기 (내가 무슨 일을 해야 하는지 무엇이 부족한지 파악해나가기)</li>
</ul>
</li>
<li>상반기 목표
<ul>
<li>챕터 구성원들의 강점을 찾고 강화하기</li>
<li>커뮤니케이션이라는 것을 전문화해보기</li>
</ul>
</li>
<li>하반기 목표
<ul>
<li>리더십에 필요한 능력치를 만들어보기</li>
<li>나만의 직군 만들기 <em>(Job Description까지 작성해보기)</em></li>
</ul>
</li>
<li>사이드 프로젝트 시작하기
<ul>
<li>업무에서 개발의 비중이 적어지다보니 꾸준히 개발을 할 핑계가 필요하다. 반드시 시작한다!</li>
</ul>
</li>
</ul>
<h3>마무리</h3>
<p>정리해보니 컨텐츠로 만들어볼만한 이야기들이 보였다. 이번 회고 글에선 짧게 짧게 다뤘는데, 몇개 잡고 블로그 글로 써봐야겠다. 그러고보니 기술 이야기가 쏙 빠졌다. 다시 개발 이야기로 가득한 회고가 이뤄질 날이 올지는 모르겠지만 계속해서 그 때의 고민과 그 때의 결정을 살펴보기 위해 회고를 작성해야겠다.</p></article></div>

Jbee.log(2023)

댓글