조르바의 2022년 회고
오랜만에 글을 쓴다.
블로그 글을 주기적으로 올려야지 생각하고 있었지만 게을렀다.
2022년 내내 몇 가지 계속 하는 것들이 있었는데 일, 책 집필, 게임 이 3가지 키워드로 정리할 수 있을듯 싶다.
3가지만 해도 벅차서 일하면서 블로그에 쓰고 싶던 주제들을 꽤 놓쳤다. (메모라도 해둘걸..)
게임은 안해도 되는거지만, 게임해 본 사람 중에 의지대로 게임을 끊을 수 있던가?! 난 아님..
작가 희망생
작년에 있었던 사건 중 흔하지 않은 사건은 책을 쓰게된 일이다.
4월쯤 내 블로그를 보시고 출판사에서 책 집필을 권유받았다. '내세울 것 없는 내가 책을 써도 되나'라는 생각에 가까운 개발자분들에게 의견을 구했었다.
그렇게 자신감이 넘치는 스타일이 아니라 책을 쓰더라도 욕 먹으면 어떡하지? 라는 마음도 컸다. 욕 먹는 건 무섭고 싫으니까.
그와 동시에 새로운 도전을 해보고 싶다는 욕심도 있었다. 개발자를 한 것도 20대 때 내게 있어 큰 도전이었다.
의견을 구했던 분들도 죽이되든 밥이되든 해보라는 의견이었고, '나도 안 하고 후회할 바에 욕먹어도 해보고 후회하자' 란 생각으로 편집장님에게 해보겠다고 했다.
상세히 밝히긴 어렵지만 주제는 특정 기술에 대한 지식이 아닌 프로그래밍 관련 교양서 같은 느낌이다. 가볍게 읽었으면 하는 책이다.
업무 시간 외에는 책 집필 60~70%, 게임 40~30%를 투자한 1년이었다.
올해 안에 책을 내는게 목표다.
책, 게임보다 우선 순위는 일이었다.
1. 초반은 적응이다!
상반기에는 수습기간이었기 때문에 날 증명해야했다.
처음 들어가서 카카오 인프라에 익숙해져야했고, 다녔던 회사들은 인프라를 많이 다룰 일이 없었다. devOps에서 배포 파이프라인 구성, 젠킨스 관리 등을 다 해주셔서 내가 개발하는 애플리케이션 서버만 딱 신경쓰면 되는 형식이었다.
첫 업무로 받은게 서비스 메쉬인 Istio를 클러스터에 적용하는 것이었다. 도입의 주된 이유는 Ruby on Rails로 된 기존 서버를 JVM 기반 서버로 마이그레이션할건데, 앞단에서 게이트웨이 역할로 기존 서비스와 신규 서비스를 동시에 운영하기 위함이었다.
재택근무 옹호자지만, 재택근무인채로 입사하니 업무를 파악하는데 어려움이 있었다. 내가 뭘 모르는지 몰라서 어떤걸 찾아야하는지 모르는 상황?
그나마 다행인건 버디를 해주신 분이 궁금할 걸 물어보면 적극적으로 알려주셨다.
우여곡절 끝에 업무나 인프라를 파악하면서 Istio를 적용하는데 한달 정도 걸린 것 같다.
2. 떠나가는 팀원들
6월쯤부터 회사가 매각된다는 얘기가 나오기 시작했다.
구체적으로 얘기하긴 어렵지만 당시 사내 분위기나 업무 분위기가 전체적으로 다운된 느낌이었다.
매각설을 계기로 팀원분들이 많이 나가셨다 ㅜㅜ 외부 환경 요인도 이직에 큰 영향을 끼친다는 것을 보았다.
그 결과, 아마 8월쯤부터 기존 팀원들 대부분은 1인 2서비스를 맡았다.
나도 작은 서비스 1개, 프로젝트 1개를 맡았는데 작은 서비스도 고도화를 계속해야했다.
스스로의 리소스와 우선 순위를 관리하고 컨텍스트 스위칭 하는데 애먹었다. 이때부터 책을 거의 쓰지 못했다.
3. 1년 가까운 시간의 프로젝트
위의 그림처럼 카카오내비에서 목적지 검색을 하면 곧바로 주차권이나 발레예약권을 구매할 수 있도록 해주는 프로젝트이다.
원래 프로젝트는 스펙이 더 크긴 했으나 내부 사정상 현재 범위로 출시했다.
3~4월쯤부터 설계를 하고 11월에 오픈했으니 거진 1년을 투자한 프로젝트였다.
이해관계자가 많은 프로젝트였어서 조율하고 설계하고 다시 엎기도 하다보니 시간이 꽤나 걸렸다.
내가 맡은 서비스는 다른 종류의 상품들을 하나의 서비스에서 묶어주고 상품을 한 단계 더 추상화해서 관리하고 판매할 수 있도록 만들어주는 일종의 플랫폼 역할을 하는 서비스였다.
서비스들은 이미 각자마다의 스타일로 상품을 팔고 있고 각자만의 엣지케이스를 파악하고 조율하는게 쉽지 않았다.
엎친데 덮친격으로 8월부터 같이 개발하시던 분이 다른 서비스를 전담하셔야해서 그쯤부터는 거의 혼자 개발해야했다.
의견은 계속 공유했지만 내가 주도적으로 설계하거나 개발해나가야했다.
내색하진 않았지만, 마음속으로는 잘해내지 못할까봐 전전긍긍했다. 이 시기부터 오픈까지 주말근무는 아니지만 야근은 매일했던 것 같다.
어쩌어찌 정해진 기한에 맞춰 서비스를 오픈했다.
누군가의 리딩을 따라가는게 아니라 주도적으로 참여해서 서비스를 제로부터 만들어본 경험은 실무에 오고나서 이번이 처음이었다.
제로부터 만들어봤다는게 자신감을 꽤 높여주었다. 그렇다고 제로부터 하는 것에 대한 불안감이 사라졌다는건 아니다.
4. 작은 서비스 하나
마이그레이션 하고 있던 서비스는 위에서 말한 큰 프로젝트 투입 때문에 홀딩됐다.
그래서 마이그레이션해서 신규로 올리려고 했던 서비스는 '전기차 보조금'이라는 신규 피처만 제공하는 서비스가 돼버렸다.
의외로 사내에서는 꽤 괜찮은 아이템으로 생각했는지 지속적으로 고도화와 개편 건이 들어왔다.
그것도 그거지만 개발자로서 재밌기도 했고 배운 점도 있다. Spring이 아닌 젯브레인에서 만든 웹 프레임워크인 Ktor를 사용해서 만들었다.
ORM 라이브러리는 JPA가 아닌 똑같이 젯브레인에서 만들고 있는 Exposed를 사용했다.
작게 오픈하고 바로 다른 프로젝트에 투입된터라 Ktor나 Exposed를 깊게 공부하진 않았지만 Ktor가 애플리케이션 서버를 띄우는 속도가 체감상 스프링보다 훠얼씬 빨랐다.(생긴지 얼마안되다보니 가벼워서 빠른건지 아키텍처적으로 뭔가 다른건지는 찾아봐야겠다.)
스프링에서 DI(Dependency Injection)를 굉장히 편하게했는데 Ktor는 Koin이라는 DI 라이브러리를 사용하면서 일일이 코드로 관리해주어야했다.
Exposed는 익숙하게 사용하던 JPA보다 Active Record Pattern에 충실한 편이다. QueryDSL처럼 자유롭게 쿼리를 만들 수 있는 기능도 제공해준다. 개인적으로 Exposed 방식에 더 마음이 간다. 엔티티 내부에서 다른 엔티티도 호출할 수 있어 관련 있는 엔티키간의 로직을 재활용할 수 있어서 그렇달까.
다만, 아직 Exposed는 버전 1.0도 안되다보니 구글링을 해도 자료가 부족하고 공식 문서도 기본적인 내용만 적혀있다보니 라이브러리를 직접 까보거나 이래저래 삽질한게 하루 이틀이 아니다보니 개발하면서 답답해서 짜증내는 날들이 많았다.
Ktor는 SpringFox처럼 스웨거를 자동 생성해주는 라이브러리도 없어서 그나마 쓸만한 라이브러리를 적용했는데 그것도 부족한게 많았다.
그래서 이번에 배운 점은 기술이 성숙하기 전에 도입한다는 건 개발자가 삽질과 고생을 각오해야한다는 것이었다. 아님 멋지게 오픈소스로 기여하거나.
게임게임게임
개발 회고와 상관 없는 이야기지만, 게임을 시작하게 된 건 주변 개발자분들 중 게임을 즐기는 분들이 많았다. 특히 콘솔 게임 이야기를 듣다보니 나도 한 번 해보고 싶었다.
해보고 싶지만 공부해야지란 생각으로 미루다 어차피 계속 공부는 할텐데 언제 게임해보지? 란 생각으로 플스5를 질렀다.(전형적인 공부 안하는 애들 핑계)
'무료 게임 좀 해보고 유료 게임 사야지'란 생각으로 플레이스테이션 스토어를 뒤지다가 '원신'이라는 게임이 무료 게임 1등이라기에 무심코 다운받았다.
맛만 보려했던 게임이었는데 이 게임만 주구장창 하고 있다 ㅋ
원래 넥슨의 마비노기를 학창시절에 했던 나로서는 빠질 수 밖에 없는 게임이긴했다.
한 해 동안 무엇을 배웠나?
▶ 제로부터 서비스를 만들 수 있다는 자신감이 조금 생겼다. 올해의 가장 큰 수확이다.
▶ 인프라 기술의 전문지식은 없지만 서비스에 필요한 인프라를 공식 문서든 구글링을 통해서 어떻게든 구성할 수 있다.(LB 구성, Istio 도입, 젠킨스 관리, 쿠버네티스를 통한 클러스터 관리 등)
▶ 분산 환경과 이중화 구성을 이론이 아닌 실제로 경험했다.
▶ 오픈한 서비스에서 동시성 이슈 발생 빈도가 잦아서 그에 대한 처리를 고민하고 해결했다
▶ 분산 환경에서 쉽게 발생할 수 있는 동시성 이슈를 redis를 통해서 처리해보았다.
▶ 적용해본 후 소감: DB 데이터 같은 경우는 unique key를 거는게 제일 낫지만, unique key가 될만한 컬럼이 없다면 redis를 도입해볼만한 것 같다. 나중에 redis로 줄 세우기 기능도 만들어보고 싶다.
▶ 책을 쓰면서 자료들을 갈무리하다보니 독자에게 전해줄 지식보다 내가 배우는게 더 많았다.
아쉬웠던 점
▶ 회사가 큰 만큼 프로세스가 많아서 그만큼 병목이 생기는 부분이 많았다.(인프라 리소스 확보, 보안 정책 처리 등) 사내 툴도 많아서 업무는 업무대로 하면서 필요한 걸 찾아내고 파악하기에 어려움이 있었다.
▶ 필요한 기술을 공부해서 도입하고 싶었지만 리소스 부족으로 심적으로나 물리적으로 여유가 없어서 그러지 못했다. 카프카를 도입해서 이벤트를 통해 짧은 레이턴시를 제공하면서 트랜잭션을 분리하고 실패한 이벤트에 대한 관리같은 것들을 해보고 싶었다. 나중에라도 메세지 브로커만 끼워넣으면 바로 사용할 수 있도록 코드상으로는 이벤트 방식으로 분리해뒀지만 새로운 프로젝트 투입으로 언제할 수 있을지는 미지수다.
▶ 사이드 프로젝트를 한 게 없다.
▶ 우선순위가 일 > 책 집필 > 블로그 다보니 책 집필, 블로그는 뒷전이었다.
올해 해보고 싶은 것이 있다면?
▶ 우선 순위 1. 올해도 그렇지만 회사 업무가 1순위다. 작게 시작하지만 크게 키울 프로젝트를 맡아서 잘 해내고 싶다.
▶ 우선 순위 2. 집필중인 책은 어떻게든 완성하자
▶ 우선 순위 3. 블로그에 짧게라도 1달에 유의미한 글 1개는 올리자
▶ 우선 순위 4. 틈틈이 개발 책 읽기(1~2달에 한권씩)
▶ 우선 순위 5. Rust로 사이드 프로젝트로 서비스 올려보기(Rust를 알게 됐는데 정말 매력적이어서 꼭 공부해보고 싶다)
한 해를 돌아본 소감
▶ 처음으로 IT 대기업(에 가까운?)에서 근무하는 경험을 해보았다. 이제 카카오 뉴인턴(3개월 수습 후 정규직 전환)에서 탈락했던 기억도 이제는 하나의 추억이 되었다.
▶ 전 회사도 그랬지만, 어느 레벨 이상의 회사로 오게 되면 실력있는 동료들은 항상 있구나.
▶ 일적으로나 사적으로나 코드가 맞다고 여겼던 개발자 두 분이 곧 이직해서 무척이나 아쉽다.
쓰고보니 이번 회고는 죄다 핑계, 변명 같아 보인다. 하지만 업무에 있어 내가 주도적으로 참여할 수 있는 프로젝트라는 마음에 정말 최선을 다했다.
2023년, 더 레벨업하는 개발자가 되길 바라본다(되겠다).
회고 끝.