goodbye-2022-welcome-2023

언제나 그렇겠지만 2022년도 많은 일들이 있었다. 2021년과 같이 이직에 대한 이벤트는 없었지만 개인적으로도 직장생활에서도 많은것들을 이루고 경험한 한해였다. 그래서 그런지 2022년이 어떻게 지나간지 모르게 순식간에 지나갔다라는 느낌이 드는 한해였다. 나이가 들면 들수록 더욱 그럴려나 싶다.

아무튼 지난 2022년 한해를 돌아보고 2023년에 어떤것들을 계획하고 있는지 적어본다.

22년 돌아보기

사무실 이전

new-office

아무래도 나는 역마살이 낀게 확실하다. 한 회사에서 하나의 사무실에서 1년이상 있었던적이 없었던거 같다. 첫번째 회사에서도 3년이 넘는 근무기간동안 2번의 사무실 이사를 했었고, 두번째 회사에서도 2년이 넘는 기간동안 회사 구성원이 많아지면서 문정에서 잠실로 이사를 했었다. 세번째 회사에서는 1년의 근무기간을 채우지 못하고 이직을 하게되었고 이번회사에서 2021년 입사후 2022년에 사무실을 이사하게 되면서 따지고보면 1년에 한번꼴로 사무실을 옮겨다닌 꼴이 된다.

이전 사무실은 아무래도 오랜기간 사용하다보니 시설도 낙후되었고 인원 대비 좁은 느낌이 들었는데 새로운 사무실은 좀더 스타트업(?) 스러운 느낌으로 바뀌게 되었다. 이번 사무실에서는 1년이상 다녀서 이 징크스(?)를 깨길 바래야지.

도도포인트 양도

yanolja-dodo-point

현재 재직중인 회사를 있게 해준 도도포인트를 야놀자에 양도하기로 결정나면서 해당 서비스에 필요한 전반적인 리소스 및 인프라, 소스코드 등을 야놀자 측으로 이관하는 작업을 진행하게 되었다. 언어전환 프로젝트를 진행하는 와중에 결정난 사항이라 부랴부랴 현재 내가 맡고있는 서비스에 영향범위는 없는지 등을 파악하고 필요한 조치들을 수행했다.

다행히도 메시지 서비스를 제외하면 의존성이 있는 서비스는 없었고 해당 메시지 서비스는 네이버 클라우드에서 제공하는 서비스로 빠르게 이관한 후 의존성을 제거하였다. 나머지는 채용과 봇 메시지와 같은 사내 편리기능을 위한 기능들이었고 우선순위가 높지 않았으므로 언어전환이 끝난 후 천천히 옮기기로 하였다.

이 글을 쓰고 있는 현재 시점에는 모든 양도 작업이 끝났고 다수 이슈가 있었지만 큰 탈없이 마무리되었다. 이제 현재 내가 개발하고 있는 키친보드 서비스에 좀더 집중할 수 있게 되었다.

언어전환

언어전환

작년 11월 말부터 시작했던 언어전환 프로젝트를 잘 마무리 지었다. 4.5개월 정도 소요되었고 예상했던 3개월보다 다소 지체되었지만 앞에서 말한 도도포인트 양도 작업과 명절 등 휴일로 인한 이슈들로 인해 지체된 것이라 회사에서도 지체된 일정에 대해서는 어느정도 받아들였던것 같다.

사실 2021년에 처음 입사했을 때 언어전환을 생각하고 있진 않았지만 좋은 기회가 생겨서 언어전환을 계획할 수 있게 되었고, 언어전환 프로젝트를 잘 마무리 짓기 위해 작업들을 목록화 하고 챕터원들에게 작업을 분배하고 일정을 관리하고 코드작업도 함께 하는 등 쉽게 경험할 수 없는 프로젝트 경험을 가질 수 있게 되었다.

도도포인트 양도를 위해서 회사에서도 키친보드(당시 도도카트)에 신규 기능을 기획할 만한 여력이 되지 않았고 한동안 열심히 제품을 개발해오면서 기술부채가 쌓이고 새로운 개발인력들이 유입되고 하면서 어느정도 정비기간을 가질 필요가 있다는 기류가 흐르고 있던 시점이라 타이밍도 참 좋았다. 거기다 다음 제품의 방향성을 바꾸기 전, 그러니까 제품의 크기가 폭발적으로 더 커지기 전에 전환을 시도한다면 성공가능성도 높이고 앞으로 작업에 대한 생산성도 올릴 수 있을 것이라는게 나의 생각이었다.

서버언어전환과 같은 제품의 기술부채를 청산하는 프로젝트는 아무래도 개발자들은 환영하지만 나머지 팀원들에게는 환영받지 못하는 프로젝트다. 실패할 가능성도 높으며 제품을 유지보수하면서 언어를 전환하는 작업들은 아무래도 어려움이 많이 따르는 프로젝트이다. 하지만 운좋게도 언어전환 프로젝트를 큰 이슈없이 마무리 지을 수 있었고, 현재는 주문서비스를 성공적으로 런칭하며 제품을 잘 개발하고 있기에 지난 서버언어전환 프로젝트는 개인적으로 성공적인 프로젝트로 기억될 것이다.

자세한 내용은 서버 언어 전환 이야기에 적혀있으니 참고하자.

주문서비스

키친보드-주문서비스

언어전환 프로젝트가 끝나자마자 주문서비스 개발 프로젝트가 우리를 기다리고 있었다. 언어전환 프로젝트를 진행하면서 조금 쉬는 시간이 있었으면 하는 바램도 있었지만 다른 부서에서 언어전환 프로젝트가 끝나기만을 기다려왔다는 것을 알기에 이해할 수 있는 부분이었다.

주문서비스는 이전에 제공하던 정리서비스와는 성격이 완전 다른 기능으로 제품의 향후 방향성을 결정할 수 있는 중요한 프로젝트였다. 제공하는 기능을 간략하게 설명하자면, 기존에 매장이 유통사에게 식자재 발주를 할 때 카카오톡을 이용하여 비정형적인 양식으로 주문을 하는 형태였는데 이를 키친보드 서비스를 통해서 정형화해서 주문할 수 있도록 하는 것이다. 특히 카카오톡으로 주문하는 경험을 그대로 가져오기 위해서 채팅기능을 함께 제공해서 주문시 채팅방에서 주문내역을 함께 확인할 수 있도록 하는 기능이 핵심이었다.

이전부터 커머스 도메인에 대한 욕심이 있었는데 드디어 커머스적인 요소가 있는 도메인을 하게되어서 개인적으로 기대가 되었던 프로젝트였다. 그래서 평소에 생각해두었던 여러 기술적 요소들을 적용시켜보며 재밌게 프로젝트를 진행했던 것 같다. 추가로 우리는 채팅 기능을 위해 샌드버드를 이용하였는데 샌드버드를 처음 연동하다보니 채팅 메시지 제약조건 및 SDK 이슈등 생각치 못했던 여러 이슈들을 겪게되어서 값진 경험이었다고 생각된다.

자세한 내용은 우당탕탕 주문서 개발기에 적혀있으니 참고하자.

백오피스 서비스 이관

backoffice

주문서비스 프로젝트를 진행하면서 백엔드챕터에서 여유시간이 있어 웹프론드엔드챕터에서 관리해오던 백오피스 서비스를 백엔드챕터에서 관리하도록 이관작업을 진행하였다(역시 언어전환을 하길 잘한거 같다).

이관하는 이유는 웹프론트엔드챕터 구성원 수가 적어 우선순위가 높은 업무가 많아 운영부서에서 원하는 백오피스 기능을 구현해주지 못하는 상황이 지속되고 있었고 아무래도 서버의 세세한 기능을 노출할 일이 많은 백오피스 서비스 특성상 백엔드 개발자가 백오피스를 만드는게 커뮤니케이션 비용을 줄이는 등 효율적인 면이 더 많을 것이라 생각했기 때문이다.

기술스텍

백오피스의 기술스텍에 대해서는 아래와 같이 여러가지 안이 제시되었다.

Spring Boot + thymeleaf/freemarker

Spring 진영에서 가장 많이 사용하는 기술스텍으로 많은 레퍼런스와 쉬운 구현이 장점이다. 하지만 서버 사이드 랜더링을 기반으로하기 때문에 화면전환시 깜빡이는등에 대한 사용자 경험에 부족함이 있었고 요구사항이 조금만 복잡해진다면 화면구성을 위한 코드가 복잡해져 유지보수에 어려움이 있다는 단점이 있었다.

Spring Boot + vuejs

해당 스텍은 기본적인 템플릿을 제공해주는 서버는 익숙한 Spring Boot로 하고 thymeleaf/freemarker 템플릿 위에 좀더 화려하고 유연하게 개발할 수 있도록 vuejs를 import해서 사용하는 방법이다. 해당 방법은 내가 이전 회사에서 도입해서 사용한 방법으로 양방향 바인딩의 장점을 적극 활용할 수 있어서 백엔드 개발자도 금방 배워서 사용할 수 있다는 장점이 있다. 하지만 버전2에서 3으로 올라가면서 문법이 많이 바뀌었다는 점과 컴포넌트를 나눠서 활용하기에 불편하다는 점, 그리고 CSS 프레임워크의 지원이 약하다는 점이 단점으로 다가왔다.

nodejs + ejs

스프링보다 가벼운 경량서버인 nodejs를 이용해서 빠르게 서버사이드를 개발할 수 있다는 점에서 장점을 가진다. 그리고 thymeleaf/freemarker와 유사한 템플릿 엔진이라는 점도 장점으로 들 수 있을것 같다. 하지만 역시나 서버 사이드 랜더링을 기반으로 했을 때 나타나는 화면전환시 깜빡임이라던지 화려한 화면구성이 어렵다는 점을 똑같이 있고 더욱이 node 서버에 대한 이해도가 부족해 이슈관리가 어렵다는 단점을 가졌다.

S3 Website Hosting + React

S3의 Website Hosting은 정적 웹 페이지를 이용하여 SPA를 구현할 수 있도록 해준다. React는 SPA를 구성하기 위해 웹 프론드엔드 진영에서 가장 많이 사용되는 라이브러리이다. 이 두개의 조합은 서버관리 없이 웹페이지를 서빙할 수 있기 때문에 서버관리의 용이성과 수많은 프론트엔드 개발자가 사용하고 있고 SPA의 장점을 누릴 수 있는 react를 이용하여 페이지를 개발한다는 점에서 장점을 가진다. 다만 백엔드 개발자가 React를 배우는데 러닝커브가 있다는 단점이 있었다.

백엔드 개발자들과 여러가지 고민들을 하였는데 결국 유지보수성과 적당한 러닝커브 그리고 무엇보다 회사내 프론트엔드 개발자의 도움을 받을 수 있는 S3 Website Hosting + React 조합으로 기술스텍을 결정하기로 하였다.

테스팅

백오피스를 개발하면서 시도해본것 중 하나가 바로 테스트 코드였다. React Testing Library를 이용하여 UI를 테스트하는 것은 가뜩이나 React에 익숙하지 않은 백엔드 개발자들에게 무리가 있어보여 jest를 이용하여 간단한 비지니스 로직만을 테스트 해보고자 하였다.

하지만 기술에 대한 이해도가 부족한 상황에서 외부코드를 참고해서 작업하다보니 UI와 비지니스로직을 명확하게 구분지어서 코드를 작성하기가 여간 쉽지 않았다(MVVM은 아직 나에게 너무 생소하다). 테스트를 작성해도 대부분 by pass 코드에 대한 테스트 케이스가 만들어지다보니 오히려 개발에 방해요소만 된다고 생각이 들었다. 그래서 과감하게 테스트 코드를 제거하기로 결정하였다. React Testing Library를 좀더 공부해보고 실무에 도입해봐야겠다.

React Hook

다음으로 고민했던것은 API Fetching에 있어서 React Hook의 사용이었다. 현재 서버는 Graphql API를 사용하고 있기때문에 Apollo client를 이용하여 API 통신을 하고 있다. 이때 주로 useQuery, useMutation과 같은 React Hook을 이용하여 API를 사용하는데 나는 이 React Hook를 사용하지 않기로 결정을 하였다.

이유는 Caching 메커니즘 때문인데 이전 회사에서도 프론트엔드 개발자들 조차 이 캐시로 인해 고생하는 모습을 보면서 사용자가 많지 않은 관리자에서는 굳이 성능이나 효율을 위한 캐시가 중요하지는 않겠다는 생각이 들어서 과감하게 Reac Hook를 사용하지 않고 ApolloClient 자체를 사용하기로 결정하였다.

다소 코드가 장황해지기는 하지만 추상화만 잘해둔다면 UI를 그리는 Component 코드에서는 그렇게 코드가 더러워지지 않기 때문에 지금까지 나름 잘 사용하고 있다.

내용을 적다보니 다소 길어졌는데 좀 더 자세한 내용은 추후에 블로그로 적어봐야겠다.

KPI 달성

kpi-graph

12월 개발일지에서도 말했듯이 회사에서 올해 설정한 KPI를 달성했다. 달성불가능할 것이라 생각했던 목표를 달성하니 뿌듯함과 다음에도 목표를 달성해봐야지 하는 동기부여가 생긴것 같다. KPI 달성에 대한 상여는 덤이다^^

누군가는 KPI는 중요하지 않다라고 하기도 하였다. 어느정도 동의하는바이다. KPI달성에 초점을 맞추기보다 장기적인 관점에서 제품을 만들어가야 하는게 이상적이라 생각한다. 하지만 당장 앞으로 1년의 생존도 걱정해야하는 스타트업에서 KPI가 중요하지 않다고는 생각하지 않는다. 큰 목표를 세워두고 그 목표를 달성할 수 있는 작고 빠르게 피드백 받을 수 있는 세부 계획을 세우고 달성해가는게 좋지 않을까. 우리가 흔히 말하는 애자일처럼 말이다.

협업에 대한 고민

cowork

꼭 개발자가 아니더라도 회사생활을 하는 직장인이라면 협업에 대한 고민은 언제나 있다고 생각한다. 나도 지금까지 일하면서 협업에 대한 고민들을 많이 했었지만 올해는 유독 더 많이 했던 것 같다.

2021년 말부터 시작한 언어전환 프로젝트는 철저하게 챕터위주로 프로젝트가 진행되었다. 그러다보니 나도 챕터내부의 이슈관리 및 프로젝트관리에만 신경쓰면되어서 협업에 대한 큰 이슈는 없었다. 문제는 언어전환 이후에 주문/채팅 프로젝트를 진행하면서 이슈가 생기기 시작했다.

2021년 하반기에 기존 인원은 퇴사하고 새로운 인원이 입사하는일이 많았는데 그로인해서 주문/채팅 프로젝트가 실질적으로 팀에서 진행하는 처음 프로젝트이신분들이 많았다. 그러다보니 각자가 생각하는 협업방식에 차이가 있었고 이것을 조율하는 과정이 필요했으나 정비기간 이후 새로운 기능을 빠르게 출시해야한다는 압박감 때문이었을까, 팀에서 개발 외적인 프로젝트 관리 및 협업관리에 대한 노력이 부족했던 것 같다.

Graphql의 사용에서부터(이미 쓰고 있었지만) API 사양 공유, 설계, 요구사항 구체화, 기획, 프로젝트 관리 등등 여러 사항에 대한 논의 및 협의가 이루어 졌고 아직 완벽하다고 할순 없지만 서로가 어느정도 협의점을 찾아가고 있는 것 같다.

챕터장

leader

올해는 챕터장의 역할 및 나의 역량에 대한 고민을 한층 더 깊이 했던 한해였던 것 같다. 일년동안 여러가지 프로젝트를 진행하면서 팀 운영방식도 많이 변경되었고 이에 맞게 챕터운영 방식도 바뀜에 따라 나의 역할도 그에 맞게 계속해서 변하게 되면서 챕터장의 역할이 과연 어떤것인지에 대한 고민들을 하게 되었다. 아래에서 좀더 자세히 이야기 해본다.

프로젝트 관리

언어전환 프로젝트는 백엔드만이 진행하는 프로젝트였고 챕터장으로써 프로젝트를 관리하고 주도하는 것은 나의 책임이었다. 대부분의 의사결정은 챕터원간에 합의에 의해서 결정이 되었지만 내가 항상 의사결정에 참가했기에 내가 관리할 수 있는 범위 내에서 모든 개발이 진행되었다.

주문/채팅 서비스도 팀에서 하나의 프로젝트만 진행하였기에 백엔드 챕터에서는 비슷한 상황이 펼쳐졌다. 의사소통 및 의사결정은 백엔드 챕터내부에서 합의에 의해 진행되었지만 항상 내가 관리할 수 있는 범위 내에서 진행되었다.

하지만 주문/채팅 서비스를 개발하는 프로젝트가 끝난고 작고 산발적인 프로젝트가 병렬로 실행되면서 내가 관리할 수 있는 범위를 벗어나기 시작했고 당시에는 각 담당자에게 설계 및 개발을 일임하고 리뷰 및 일정관리에만 신경을 썼던 것 같다. 그러다보니 개개인의 역량에 따라 특정 프로젝트에서는 이슈가 다수 발생하기도 하고 이를 대응하면서 다른 프로젝트를 챙기랴 정신이 없었던 것 같다.

이렇게 프로젝트들을 진행하면서 모든것을 다 관리하려고 하는 것이 내 욕심인가 싶기도 했다. 그래도 챕터장으로써 서버에서 제공하는 기능에 대한 이해 및 챕터원의 프로젝트 진행 관리는 반드시 챙기고 싶다는게 아직까지 내 바램이다.

적극성

현재 백엔드 챕터에서는 개발을 시작하기전에 초기 설계에 힘을 많이 쓰고 있다. 충분히 영향범위를 고민하고 어떤 기능들을 만들지, API 명세는 어떻게 만들지들을 미리 정해두고 진행해야 나중에 코드를 작성할 때 변경사항을 최소화할 수 있기 때문이다. 그래서 프로젝트 초기에는 설계회의를 주로 진행하는데 아무래도 백엔드 챕터 모두가 참가해서 진행하다보니 나와 특정 인원만 의견을 많이 제시하는 상황이 펼쳐지곤 한다.

물론 그 분들도 제시된 의견에 동의하기 때문에 특별한 의견을 제시하지 않을 수도 있지만 혹여나 개인적인 성향으로 인해 생각하고 있는 의견을 제시하지 못하는 상황이 지속되고 있진 않는가 우려가 되는부분이긴 하다. 그렇다고 마냥 그 분들에게 의견을 제시하라고 독촉할 수도 없는게 이 또한 부담이 될 수 있기 때문이다. 어떻게하면 좀더 적극적인 의견제시를 할 수 있도록 환경을 만들 수 있는지는 계속해서 고민하고 있는 부분이다.

역량강화

지난 기간동안 다른회사에서 처럼 스터디나 개발세션을 따로 진행하지 않았다. 개인적으로는 회사의 제품 개발을 진행하면서 개발적인 역량이 가장 많이 강화된다고 생각하고 있는데 그 예 중 하나가 바로 테스트 코드 작성이다.

내가 가장 챕터원들에게 주입하고 싶었던 역량은 테스트 코드 작성에 대한 역량이었다. 대부분 여기에 입사할 당시 테스트 코드 작성에 대한 경험이 풍부하지 않았고 테스트 주도로 개발해온 경험도 적었다. 그래서 현재 백엔드 챕터는 테스트 코드가 존재하니 테스트 코드 작성능력을 키울 수 있는 좋은 상황이라 생각되어 업무를 하면서 테스트 코드를 반드시 작성하도록 하였다. 개인적인 욕심으로는 테스트 주도 개발 프로세스를 지키면서 하면 좋겠다고 생각하지만 처음 테스트 코드를 작성해보는 인원에게는 조금 버거운듯 하였다. 올해는 테스트 주도 개발 프로세스를 연습해볼 수 있도록 해봐야겠다.

스터디나 개발세션을 정기적으로 하지 않는 이유는 지난 스터디나 개발세션 진행 시 적극적인 특정 인원에게만 도움이 되거나 억지로 참가하는 모양새가 되는 등 경험이 만족스럽지 않았기 때문이다. 대신 비정기적 회의에서 챕터원들이 공유하였으면 하는 기술적인 내용들을 공유할 수 있는 장은 마련하고 있다. 다만 조금 아쉬운 부분은 회사에서 사용하지 않는 기술에 대한 관심도 및 지식 공유는 조금 떨어진다는 것이다. 두마리 토끼를 잡을 수 있는 방법은 없을까.

미래

가끔 이런생각을 한다. 내가 다른 회사에서도 챕터장을 이렇게 할 수 있을까? 지금은 이전 회사에서 함께 일했던 인원들이 있어서 심리적인 안정감이 있는것은 사실이다. 의사결정시에도 가끔은 독단적으로 결정해도 이해해주겠지라는 믿음이 있기 때문이다. 하지만 다른회사에서 만약 챕터장을 하게되었다고 가정해봤을 때 지금과 동일한 상황이 아닐 가능성이 높다. 그렇다면 지금처럼 챕터장을 해낼 수 있을까? 라는 생각이 든다. 결국 내가 과연 좋은 리더가 될 수 있을까에 대한 고민인데, 책이나 블로그 등 다른 사람들의 경험을 많이 엿보면서 많이 배워나가야겠다.

책 쓰기

writing

언어전환을 마치고 전환에 대한 내용을 서버 언어 전환 이야기라는 제목으로 블로그로 작성했었다. 시간이 어느정도 흐른 후 감사하게도 IT전문 출판사인 로드북에서 ‘서버 언어 전환’과 관련한 내용으로 글을 써보지 않겠냐고 집필제안을 주셨다.

블로그를 쓰고는 있지만 전문적으로 글을 쓰는 사람이 아니기에 책을 집필한다는 것이 부담이 되기도 하고 ‘서버 언어 전환’이라는 주제 자체가 자칫 논란이 생길까봐 겁이나기도 하였다. 그래서 아내에게 고민을 이야기하였더니 글을 쓰지도 않고 걱정부터 하느냐고 당연히 도전을 해야한다는 조언을 해주었다^^;;

덕분에(?) 용기를 얻어 집필을 시작하게 되었고 5월에 집필제안이 와서 11월 말에 끝났으니 약 6개월 정도 시간을 들여 원고를 마무리짓게 되었다. 솔직히 막바지에는 분량에 대한 압박과 소재가 바닥이 나서 처음에 비해 부족함이 점점 드러나지 않았나 싶었지만 그래도 약속했던 기한과 분량을 맞춰서 제출할 수 있어서 다행이라 생각한다. 이제 디자인 및 편집과정과 퇴고가 남은 상황이고 올해 초에 출간이 되지 않을까 생각된다.

이번에 책을 쓰면서 다시한번 책을 쓰시는 분들이 존경스럽다는 생각이 들었고 400~500페이지가 넘는 두꺼운 책을 몇권씩 책을 쓰시는 분들은 참 대단하다는 생각도 들었다. 결과가 어떻게 되든 이런 경험을 할 수 있었다는 것만드로도 나에게는 뜻깊은 일이라 생각한다.

야곰캐스트 연사

yagom-tech-cast

어느날 블로그의 개발자의 소통의 중요성이라는 글을 보고 야곰에서 캐스트 연사로 참가해줄 수 있을지 초청 메일이 왔다. 이전에 사내 세미나에서 발표를 해본적은 몇번 있지만 외부에 불특정 다수를 상대로하는 발표를 참가는 해본적이 없어서 두려움반 기대반으로 참가를 결정하게 되었다.

다행히 나를 포함하여 3명의 연사가 참가하게 되어서 조금 묻어갈 수 있겠다(?) 싶어서 조금 안심이 되기도 하였다. 발표는 잘한것 같지는 않지만 나름 질문들도 해주시고 들으시는 분들께 생각할 거리들을 남겼다는 점에서 의미는 있었지 않았을까 생각한한다. 다음에도 이런 좋은 기회가 생기면 좀더 준비를 잘해서 참가해야겠다.

코로나

covid-19

올해도 어김없이 코로나가 계속해서 유행을 하고 있었다. 많은 분들이 감염이되고 치유가되면서 어느정도 면역체계가 생겼다고 생각해서인지 방역수준은 작년과 재작년에 비해서 상당히 완화된 수준으로 이어지고 있었다. 그러던중 나도 처음으로 코로나에 감염이 되었고 일주일간 자가격리를 하게되었다. 내가 확진판정을 받은 다음날 아내도 확진을 받게 되면서 졸지에 부부가 한집에서 격리를 하는 신세가 되었다. 다행인건 두사람다 감염이 되었기에 서로 격리를 위해 양가 부모님 댁에 가야한다던지와 같은 일은 하지 않아도 되었다는 것이다.

코로나에 걸리니 열도 열인데 목이 가장 아팠던 것 같다. 그리고 살면서 가장많이 잠을 잤던것 같다. 약기운인지는 모르겠지만 가장 많이 잔 날은 하루에 18시간 이상을 잠을 잤던것 같다. 그덕인지 그동안 쌓였던 피로가 싹 다 풀렸던 것 같다. 물론 그동안 운동했던 근육도 함께 싹 다 풀렸다 ^^;;

이제는 감염이 되어도 정부지원금을 받을 수는 없어서 아쉬웠지만 성동구에서는 격리자를 위한 생활용품을 여전히 보내주고 있었기에 의외의 선물에 기분이 좋기도 하였다.

이 글을 쓰고 있는 현재는 방역지침도 많이 완화되어 마스크 의무착용까지 해제하는 것을 논의하고 있는 상황이고 많은 회사들이 일부재택 또는 전면출근으로 근무제도를 변경하고 있는 상황이다. 모쪼록 이 긴 유행이 빨리 종식되길 기대해본다.

국토종주

bike-journey

2022년에 세운 계획 중 하나가 바로 4대강 국토종주를 해보는 것이었다. 2021년 11월부터 타이트한 일정으로 언어전환 프로젝트를 진행하고 있었으므로 언어전환 프로젝트가 끝나면 국토종주를 하겠노라 마음먹고 있었다. 하지만 프로젝트가 예상치 못하게 조금씩 딜레이가 되고 QA를 거쳐 배포를 한 이후에 숨돌릴 틈도 없이 주문/채팅 프로젝트가 계획되어 있었다. 그래서 긴 휴가를 내어야하는 4대강 국토종주는 다음으로 미루기로 하고 친구와 함께 주말에 속초 라이딩을 가기로 하였다.

그나마 다행인점은 지인이 무릎 통증으로 인해 속초라이딩 중에 결국 점프를 하게 되었고 미시령고개는 결국 혼자서 건너게 되었다. 4월임에도 불구하고 미시령은 엄청 추웠던 기억이 있다. 아무튼 속초 라이딩에 대한 기억이 너무 좋았던 나머지 주문 채팅 프로젝트가 끝나고나면 꼭 4대강 국토종주를 가겠노라 다짐을 하였다.

시간이 흘러 주문/채팅 프로젝트가 잘 마무리되고 책 집필로 인해 일상에 지쳐갈때쯤, 결국 참지못하고 연휴와 휴가를 붙여서 일주일정도 일정을 잡고 국토종주를 다녀오기로 결심했다. 나름 긴 여행이라 블로그와 유튜브를 섭렵하며 만반의 준비를 하였다. 아래는 메모장에 적어둔 코스 및 숙소 위치 등등이다.

bike-journey-plan

총 4박 5일을 계획하였는데 중간에 비가온다는 소식이 있어 첫날에 무리를 해서 200km가 넘게 달리고 다른날도 계획보다 더 달리면서 총 3박 4일의 일정으로 국토종주를 마치게 되었다. 가는길 중간에 부모님이 사시는 시골집이어서 비가오는 3일째 되는날은 집에서 하루 더 쉬고 부산으로 출발하였다.

하루에 길어야 3~4시간씩 평지위주로 달릴땐 몰랐는데 높은 산과 긴 코스로 자전거 여행을 하니 지금보다 더 좋은 자전거가 사고 싶다는 생각이 엄청 들었다. 그래서 만약 KPI를 달성하면 자전거를 꼭 사야지 마음먹었었다. (이 글을 쓰고 있는 지금 KPI를 달성해서 마음에 드는 새로운 자전거를 하나 장만했다. 짝짝짝)

종주를 마치고 오랜만에 부산친구들을 만나서 좋은 시간을 보내기도 하는 등 2022년 가장 좋았던 경험을 꼽으라면 이 국토종주를 이야기할 수 있을 것 같다. 왜 사람들이 국토종주를 여러번 하는지도 알것 같은 마음이다.

국토종주 인증서 사진을 자랑하면서 이 챕터는 마무리지어야 겠다^^

bike-journey-certification

운동

bench-press

나이가 들면서(?) 운동을 하지 않으면 체력이 받쳐주질 못한다는것을 느끼게된 후부터 자전거, 스피닝, 수영 등 꾸준히 운동을 하고 있다. 코로나가 시작되면서 다른 사람들과 함께하기 힘든 운동들은 아무래도 하기가 힘들어서 주로 자전거를 탔었는데 계절의 영향을 많이 받는 운동이다보니 이마저도 아쉬운 부분이 있었다. 다행히 방역수준이 완화되면서 헬스장에서 마스크를 착용하고 운동을 할 수 있게되었고, 유산소 위주로 운동을 해왔었는데 코어 근육도 건강에 중요하다고 하여 헬스장에서 근육운동을 시작하게 되었다.

초반에는 PT를 받는것이 좋다고 하였지만 부담이 되는 부분도 있고 다이어트를 빡세게 할게 아니었기에 PT는 하지않고 기본적인 근육운동을 꾸준히하면서 유산소는 자전거로 병행하는 방법으로 운동을 하였다. 드라마틱하게 살이 빠지거나 인바디 수치가 좋게 나오지는 않았지만 눈바디(?)로 보았을 때 나름 근육이 붙고 코어 근육이 생기다 보니 자세도 좋아진 것 같다.

앞으로도 헬스장은 계속 다녀서 기초적인 근육운동은 꾸준히 해야겠다. 자전거도 더 열심히 타고!

투자

investment

2021년부터 2022년 초까지는 호황이었다. 그래서 주식과 함께 코인까지 투자해서 쏠쏠하게 벌어서 아내 결혼기념일 선물도 사주고 했는데 후반기부터 금리가 오르더니 곤두박질 쳤다.

코인쪽은 수익실현하고 반정도 빼서 손실을 좀 줄이긴 했지만 그래도 워낙 하락세가 크다보니 코인으로 벌었던 돈만큼 평가손실을 보고 있는 상태다. 문제는 주식쪽이다. 아무리 주식을 적금처럼 생각하고 넣어놓은거라고 하지만 호황일 때 여윳자금을 많이 넣어둔 상태라 평가손실비율이 큰 상황이다.

한동안 경제항황이 좋아질것 같지는 않다는 평가가 많은 지금, 현재 넣어둔 주식이나 코인쪽 자금을 빼서 적음으로 돌려야하나 말아야하나 고민된다. 아직 평가손실이라 와닿지는 않지만 매번 파란화면을 볼때마다 아쉬운 마음이 들기는 하다. 혹자는 어차피 장기투자라 생각하고 그냥 두고 잊어버리라고도 한다. 그렇다면 적금에다 넣어두고 잊어버리는게 낫지 않나 싶기도하다.

아무튼 많은 투자 전문가들이 리스크 관리를 위한 분산투자를 이야기하였었는데 실제로 손실을 겪게되니 역시 전문가들의 조언을 새겨서 들어야하지 않나 싶다.

2023년 목표

독서

reading

독서를 많이하겠다는 다짐은 매년 하는것 같다^^;; 하지만 언제나 잘 지켜지지 않았다. 연말에 항상 목표했던 독서량에 현저하게 못미치는 결과를 보곤한다. 2022년에도 이것저것 다른 것을 많이 했기 때문이라는 핑계를 대보지만 결국 여가시간에 독서보다는 휴대폰을 보는 시간이 더욱 길었던 것 같다.

그래서 올해는 조금 독하게 마음먹기로 했다. 바로 유튜브 어플을 지워버렸다. 그리고 SNS어플도 지워버렸다. 나의 의지가 부족함을 알았기 때문에 이렇게 물리적으로 단절시키지 않으면 안되겠다는 생각이 들었다. 때마침 사내 복지제도가 개편되면서 책구매 시 비용지원을 받을 수 있게 되었다. 책을 사는데 좀 더 자유로워졌으니 올해는 꼭 책을 많이 읽어야겠다.

그랜드 슬램 달성

grand-slam-certification

4대강 종주길을 다녀왔으니 이제는 종주수첩에 있는 다른 코스들을 다녀보는 것이 올해의 목표다. 크게는 ‘동해안 자전거길’에서 부터 ‘제주환상자전거길’, ‘금강자전거길’, ‘북한강 자전거길’등 수많은 코스들이 남아있다. 종주수첩에 도장을 찍는 재미도 쏠쏠하고 종주수첩에 모든 도장을 찍게되면 ‘그랜드슬램 인증서’를 받을수 있기 때문에 꼭 달성해 보고 싶다.

날씨가 풀리는 봄부터 한강에서 부지런히 훈련해서 여유될때마다 도장을 잘 찍어놔야겠다.

그 외 업무적인 목표

청구/결제 프로젝트

올해부터는 본격적으로 다음 큰 프로젝트인 ‘청구/결제 프로젝트’를 진행중이다. ‘주문/채팅 프로젝트’가 제품의 방향성을 전환시킬 중요한 프로젝트였다면 ‘청구/결제 프로젝트’는 제품의 BM을 위한 첫 시작점이라 생각한다. 그리고 ‘주문/채팅 프로젝트’에 비해 백엔드 챕터에서 할일이 많고 중요한 요소가 많은 프로젝트이기도 하다. 여튼 잘 마무리 지어서 올해의 스타트를 잘 끊었으면 하는 바램이다.

정리 서비스 종료

KPI를 달성하면서 ‘주문/채팅’ 기능에 대한 시장성을 증명하게 되었다. 그러면서 선택과 집중을 위해 ‘정리’ 서비스를 종료하기로 결정하였는데, 아무래도 이전까지 주요 기능을 제공하던 서비스라 코드의 양도 상당부분 차지하고 있다. 올해는 이 정리서비스를 위한 코드들을 잘 제거하여 서버의 코드가 컴펙트하게 유지될 수 있도록 하는것이 목표다. 잘 제거하고나면 CI속도도 개선되지 않을까라는 기대감을 가지고 있다.

통합테스트에서 기능테스트로 전략 변경

서버 언어 전환 이야기에서도 언급하였지만 현재 서버는 단위 테스팅과 통합 테스팅을 혼합한 형태로 코드 커버리지를 충족하고 있다. 다만, 통합테스트가 기능테스트에 비해서 커버리지가 다소 떨어지다보니 실제로 테스트코드에서 잡아주지 못하는 기능적 오류, 특히 데이터베이스에 영속화를 하는 기능들에 대한 오류가 간헐적으로 발생하고 있다. 그러다보니 JPA와 관련한 리펙터링 시 수동적일 수 밖에 없는 모습들이 보이는데, 테스트 코드 작성에 다소 난이도가 올라가더라도 통합테스트에서 기능테스트로 테스트 전략을 바꾸는 것을 목표로 하고 있다.

이제는 챕터원들이 테스트에 대한 이해도가 높은 상태이고 기능테스트를 수행하더라도 서드파티는 그대로 Mock을 사용하거나 Mock server로 대체하는 등의 전략을 사용할 것이기 때문에 도전해봄직하다고 생각한다.

2022년 회고

댓글