2023 개발 회고록

안녕하세요 😀
유익한 일상 정보를 전달하는 유로띠 입니다 😉
 

 

시작하며

---

 
개발자의 좋은 습관은 바로 회고!

기록되지 않는 것은 기억되지 않는다.

 
 
2024년의 새로운 준비를 위해 2023년을 회고해 보려고 한다.
 
이번 회고는 KPT 방법을 토대로 작성하였다.
 
참고로 KPT란 Keep, Problem, Try의 약자로, 가장 대중적으로 사용하는 회고 방식이다.

Keep: 프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분
Problem: 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점
Try: Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해 볼 점
 
 
 

Keep : 계속할 것

---

 

영향력 있는 사람이 되자. 🙋‍♂️

✅ 업무에 있어서 더 좋은, 더 나은 방식으로 개선하고 공유하자.
우리 팀에서 반드시 지키고자 했던 건 바로 테스트 코드의 작성이었다. 꾸준히 한 결과 코드 개선 및 버그 수정에 있어서 굉장히 큰 도움이 되었다고 생각한다. 우리의 방식이 좋게 평가되어 사내에서도 발표를 할 수 있었고 이러한 방식은 사내 전체에서도 선한 영향력을 행사하게 되었다고 생각한다.
블로그 글로 작성할 만큼 테스트 코드 작성은 중요하다 생각하고 앞으로도 꾸준히 유지할 예정이다.
이렇게 하나씩 팀 문화를 만들어 나아갈 예정이고 올해도 좋은 문화를 하나 만들고 싶다.

[Growth Hacking] - 테스트 가능성을 높이자 (TDD, 테스트 코드)

테스트 가능성을 높이자 (TDD, 테스트 코드)

 
✅ 팀에서 먼저 프로젝트를 진행하고 poc를 거쳐 정식 서비스로 출시되도록 하자.
기존에 es를 이용하여 비교적 단순하게 강의 검색이 존재하였다. 하지만 이번 프로젝트에서는 단순히 강의의 이름뿐만 아니라 목차, 강의 내용 등 복합적인 검색이 필요하였고 요구조건에 맞도록 새로운 전문 검색(fts) 서비스를 만들어 poc를 진행하여 팀 내에서 사용하였다.
전사적으로 사용하면 좋겠다 생각되어 매주 개발실에서 발표하는 시간에 해당 서비스를 소개하여 나름의 홍보도 진행했다.
다행히도, 이후 고도화를 거쳐 우리 팀뿐만 아니라 사내에서도 사용할 수 있게 확장시켰다. 새롭게 만든 전문 검색 서비스는 mongoDB의 nGram을 이용하여 전문 검색이 되도록 구성하였다.
나름 MSA구조를 가지다 보니 이렇게 검색의 한 부분을 비교적 쉽게 교체할 수 있어서 좋았고 해당 서비스의 활용도를 인정받아 전사적으로 사용하니 뿌듯함과 좋은 영향력 +1 이 된 느낌이다.

[Growth Hacking] - MongoDB를 이용하여 검색 시스템을 만들어보자(: full text search)

MongoDB를 이용하여 검색 시스템을 만들어보자(: full text search)

 

커뮤니케이션을 잘하자. 

올해 1년은 개발자가 아닌 매니저의 해였다. 올해 초부터 해당 그룹에서 백엔드 팀의 팀장을 맡게 되었다. 첫 팀장으로 많은 부담이 있지만 그중에서도 가장 큰 부담은 팀원들은 저보다 오래 현재 회사의 경험이 더 많았다. 저는 팀원들의 훌륭한 매니저가 되기 위한 고민이 시작되었다. 가장 중요하게 생각한 것은 바로 커뮤니케이션이었다. 사람들은 저마다 다양한 방법으로 예를 들면 카리스마나 만능 해결사 등등으로 팀을 장악한다. 저는 그중에서 커뮤니케이션(소통)의 방식으로 팀을 이끌어 나갈 수 있도록 생각했다.
그래서 매주 3회 이상 팀원과 커피챗을 진행했다. 자주 그리고 가볍게 커피챗을 진행함으로써 현재의 진행 상황과 진척도를 파악할 수 있고 일의 우선순위를 알 수 있어서 좋았다고 생각한다. 또한, 자주 소통하다 보니 다양한 아이디어나 개발 방향, 아키텍처 설계등 고민이 있는 부분에 대해서도 다 같이 시간을 갖고 이야기를 하는 방향으로 나아갔고 더 좋은 방향으로 이끌 수 있었다.
 
공감이 되었던 책은 개발 7년차, 매니저 1일차 란 책이고 처음 팀장을 맡은 분들에게 추천한다.

개발 7년차, 매니저 1일차 - 예스24

 

스터디 📚

개발 부서 내부의 북클럽을 만들어 스터디를 진행했다. 분량에 따라 다르지만 한 권 당 대략 2 ~ 3개월 정도 진행해 왔고 무려 3기까지 진행하였다. 물론 제가 다 리드한 건 아니지만 새로운 문화를 만들고 평소 읽고 싶은 책을 완독 할 수 있게 되었다.
북클럽 이외에도 개인적으로나 다른 팀에서 하는 스터디에 참여해서 책을 많이 읽었다. 책을 읽는 것은 좋은 습관인 것 같아 2024년에도 꾸준히 이어 나갔으면 하는 바람이다.
개발자 원칙
이펙티브 타입스크립트
쏙쏙 들어오는 함수형 코딩
 
이외에 독서 정보는 꾸준히 git에 올리고 있다.  

GitHub - alstjs1207/book-club: 책을 읽고 정리합니다.

 

먼저 코딩하기보다 문서를 만들어 공유부터 하자 📃

이슈를 할당받아 기획서를 분석하고 코딩을 하고 pull Request를 거쳐 코드리뷰를 받는다. 하지만 이 기능의 모든 히스토리와 기획은 개발한 당사자만 알고 있기에 코드리뷰를 받기가 쉽지 않다. 또한 개발 방향과 의도가 달라질 수도 있다. 그래서 기획을 읽고 문서로 작성하여 공유하는 시간을 가지도록 하였다.

좋은 점은 모두가 알 수 있다는 것과 내가 미처 생각지 못한 문제나 더 나은 방향성을 찾을 수 있다는 점이다.

물론 매번 기능을 개발할 때마다 하기는 어렵지만 예를 들어 수강신청 기능이나 알림 서비스 등 비교적 큰 기능을 추가할 때, 문서로 작성하여 공유하면 나중에 신규 입사자의 온보딩에도 큰 도움이 되고 이슈 추적에도 도움이 되기에 최대한 문서를 작성하는 습관을 가지려 한다.

 

 

 

Problem : 개선할 것

---

 

매니저가 아닌 반장?

 
지금 생각해 보면 팀장으로서 매니저보다는 반장에 가까웠다. 일감은 매일 팀원에게 아침식사처럼 지라이슈를 할당했고 어려운 일이나 번거로운 일은 내가 맡아서 처리했다. 왜냐면 이런 일 보다 더욱 가치 있는 일을 주고 싶었기 때문이었다. 저만의 생각이었던 걸까?.. 평가에서도 이런 부분이 단점으로 지적되었다. 방향이 잘못되었음을 생각하고 지속적으로 개선해 나아가야 할 부분이다.
올해는 반장이 아닌 진정한 매니저가 되보도록 하자
 

 

첫 신입 개발자, 첫 온보딩

 
이제 막 개발자로 첫걸음을 시작하는 신규 입사자가 등장했다! 그것도 우리 팀에만 2명이나! (회사 전체로는 8명 정도?! 신입이 입사하였다.)
그간 첫 신입은 거의 채용하지 않았기에 온보딩 정책이 뚜렷하게 존재하지 않았다. 우리 회사에 귀하게 오신 신입이기에 우리는 철저히 3개월간의 완벽한 온보딩을 위해 여러 회사의 온보딩 문서를 찾아보고 가이드를 작성하여 진행했다. 하지만 기존 팀원의 매니징부터 개발, 회의에 치이다 보니 첫 1개월간은 좋았으나 후반으로 가면서 부족함을 느껴서 개인적으로는 많이 아쉬운 온보딩이 된 것 같다. 온보딩은 우리 팀의 첫 이미지이자 분위기이기 때문에  이미 신규 입사자분들의 온보딩은 끝났지만 나중을 위해 틈틈이 개선해 보도록 하자

 

커스터마이징

우리는 하나의 서비스를 제공하지만 내가 맡은 B2B 업무의 특성상 다른 업체와의 연동 작업에 있어서 많은 커스터마이징 작업이 발생된다. 그때마다 기간 조정, 업무 순위가 변동되어 개발을 진행하는 문제가 발생되고 더욱이 문제가 되는 건 외부 연동으로 인한 기존코드의 오염이었다. 많은 시간으로 개발한 노력에 비해 일회성코드가 되는 것이 많이 아쉽고 외부 연동에 대한 불안전한 테스트 코드에 대해서 개선할 필요성을 느꼈다. 진행할 때마다 시간이 부족해서 지나치는 경우가 많은데 이러한 부분이 결국 깨진 유리창이 되기 때문에 올해는 개선해 나아가야 할 것이다.

 
 

Try : 시도할 것

---

우리 모두 진급

우리 팀원 모두 부족한 저를 믿고 달려와주었기 때문에 가장 큰 목표는 노력을 인정받아 우리 팀원 모두가 진급할 수 있도록 만들고 싶다. 꼭 진급이 아니더라고 사내에서 영향력 있는 사람으로 만들도록 하고 싶다. (영향력 있는 사람이 되면 진급도 같이 따라올 수 있지 않을까? 😎)

 

마이크로 매니징 

반장이 아닌 팀장이 되기 위해 전략적인 마이크로매니지먼트를 진행하려 한다.

 

작업 성숙도 파악(Gauge Task Maturity):

🔵 업무를 할당할 때 직원의 기술 수준을 평가하기

🔵 초보자는 자연스럽게 더 많은 지원이 필요하며, 기술이 발전함에 따라 점차 지원을 줄임

 

명확한 기준 설정(Set a Clear Baseline):

🔵 직원이 프로세스를 수행할 수 있다고 해서 그것을 설계할 적합한 사람이라는 의미는 아님

🔵 표준을 정의하고 프로세스를 직접 만들어 문서화하며, 추측을 방지하기 위해 화면 녹화나 실제 비디오를 사용

 

이해도 검증(Verify Comprehension):

🔵 직원에게 프로세스를 다시 설명하게 하고, 녹화된 내용을 사용하여 자신의 SOP(표준 운영 절차)를 작성하게 하기

🔵 이해도를 완전히 확인한 후에 업무를 시작하게 하기

 

결과를 면밀히 모니터링(Monitor Results Closely):

🔵 처음에는 자주 확인하고, 빠르고 구체적인 피드백을 제공하기

🔵 성공을 칭찬하고, 개선 사항은 개인의 단점이 아닌 시스템에 초점을 맞춤

 

자율성 증가(Increase Autonomy):

🔵 역량이 성장함에 따라 업무 수행과 원래 프로세스 개선에 대한 자율성을 더 부여하기

🔵 그러나 중요한 업무에 대해서는 일정한 감독을 유지

🔵 목표는 완전한 자급자족이지 감독을 전혀 하지 않는 것이 아님

 

 

해마다 영향력 있는 일을 해보자

전문검색 시스템처럼 올해도 사내에 영향력 있는 서비스를 만들어 보려고 한다.
새로운 기능이나 도구, 기술을 우리 팀에서 먼저 시작하여 사내 전체에서 사용될 수 있는 마루타가 되어보자?!!!
도전에 두려워하지 말자. 새로운 것에 도전해 보자.