을사년 새해가 되어 2025년이 된지 오래되었으나 더 늦기 전에 2024년 회고 시작!
electron-builder를 통해 MacOS 빌드 환경 구성
Mac OS에서 pkg 파일을 배포하려고 했으나 Mac OS의 보안으로 Code Sign 및 Notarizing이 되지 않으면 다른 Mac OS 컴퓨터에서 사용이 불가하여 많은 고민을 했었다.
이 때 Application ID Developer 키체인과 Application ID Installer 키체인에 대한 차이에 대해 알았고 electron-builder, electron-notarize, electron-osx-sign 라이브러리를 사용하여 어떻게 electron을 빌드해야하는지 알게 되었다.
Tanstack React Query에 대한 고민
처음 프로젝트 시작 시 axios만 사용하다가 낙관적 업데이트에 대한 고민을 하다보니 RTK Query를 사용하여 낙관적 업데이트에 대한 고민을 해결했었다. 그러나 사용을 해보니 보일러플레이트가 너무 많다는 생각이 들었고 좀 더 처리가 간단한 방법이 없을까 하고 사용한 React Query를 사용하게 되었다. 고민이 해결되니 왜 많은 사람들이 이 라이브러리를 사용하게 되었는지 알게 되었다.
그 이후로 React Query를 사용했는데 뭔가 이상하다는 느낌이 들었다.
useQuery로 값을 불러 올 때 여러 페이지에 동시에 사용을 하는데 계속 useQuery로 axios 를 import하고 query key를 지정하는 것이 굉장히 불편하다는 생각이 들었다. 그래서 하나의 함수를 만들어서 import 하면 여러 페이지에서 통일성있게 사용할 수 있고 api 주소 또는 스키마가 변경 되었을 때 한꺼번에 관리할 수 있으니 굉장히 편할 것이라는 생각이 들어 중앙집중화 작업을 하니 개발하는게 세상 편해졌다.
작업 완료 후 useQuery로 불러온 data에 대한 타입이 지정되지 않아 어떻게 해결해야하나 고민을 했는데 함수 만들 때 타입을 지정하니 타입 추론도 가능해져 너무 좋았다.
Sentry 도입 경험
프로그램을 빌드하고 배포 했을 때 어떤 부분에서 어떤 에러가 발생했는지 알 수가 없었다. 백엔드 개발자 분들은 로그가 있어 확인이 쉬운거 같은데 프론트엔드는 로그 확인이 어렵다보니 에러 확인이 더 까다로운 것 같다. 그러다보니 팀장님께서 미니 PC를 주시면서 온프레미스로 Sentry 설치하라고 하셨고 전달 받은 미니PC에 linux 및 Sentry를 설치했다. 설치는 공식문서대 보면서 하니 어렵진 않았으나 react나 electron에서 어떤 에러를 전달할지와 Sentry 내부에 프로젝트를 생성하여 배포된 상황에 맞는 프로젝트에 에러를 전달할지에 대한 고민을 해봤는데 우선 데이터를 쌓는게 중요하니 대부분의 에러는 전달하게끔 했다. Sentry가 에러를 추적하여 동영상도 볼 수 있고 로그도 볼 수 있으니 에러를 로깅할 때 정말 편하고 재밌었다.
github action, AWS Code Deploy CI/CD 도입 경험
배포를 할 때 매번 수동으로 업로드하는 것이 점점 불편하다는 생각이 들 때쯤 팀장님께서 CI/CD 구축을 말씀하셨다. 기본적인 틀은 ./github/workflows/deploy.yml 에 스크립트 작성 → 빌드 파일 S3 전송 → scripts/deploy.sh linux 명령어로 압축 해제 및 파일 이동(S3 → EC2) 스크립트 저장 → appspec.yml 에 AWS Code Deploy 환경 설정 스크립트 작성.
이렇게 진행하니 develop 브랜치에 merge 되면 개발서버에 배포되고 main 브랜치에 merge 되면 상용서버에 배포되었다. 깃허브에서 merge 버튼 딸깍하니 자동으로 배포되는게 너무 편했다. 그리고 CI/CD 실패했을 때 문제도 바로 확인 할 수 있는 점이 좋았다.
테스트 코드 작성
그동안 테스트 코드 작성을 해야한다는 것은 알았지만 어떻게 해야할지 막막하고 기능 구현이 먼저다보니 우선 순위에서 밀렸었다. 하려고 마음 먹은 순간 환경구성부터 진행하기 위해 단위테스트랑 통합테스트를 하기 위해 vitest, React Testing Library를 설치하고 Storybook도 설치했다. e2e 테스트를 위해 playwright를 설치하고 mocking을 하기 위해 MSW 라이브러리를 설치했다. (왜 이리 설치 할게 많은지…) 테스트 코드에 대해 개념이 없었으나 GPT의 도움을 받아 작성을 하니 코드 도움 받을 때 보다 더 도움 받는 느낌…?
그동안 작성 못했던 테스트 코드를 점차 프로젝트 전체적으로 작성해야겠다고 느꼈는데 언제하지...
합성 컴포넌트 적용
Modal 창에서 그동안 공통 UI를 사용하여 큰 문제 없이 사용했으나 기획에서 많은 요구가 추가되다보니 재사용성이 낮아졌다. 카카오에서 작성한 글을 읽고 합성컴포넌트 도입이 필요하다는 생각이 들었다.
회사에서 headless UI를 사용하고 있었는데 headless UI의 사용 방식과 비슷하다는 느낌이 들었고 합성 컴포넌트를 적용하니 불편한 부분이 많이 줄었다.
사람들이 많이 사용하는데는 다 이유가 있다…
신입 채용
예전에 팀장님께 “언젠간 신입 채용하면 저도 면접관으로 참여하나요?” 라고 문의 드렸었는데 진짜 참여 시켜주셨다.
한 명 채용인데 거의 200명이 지원… 요즘 프론트엔드 신입 채용 경쟁률 장난 아니구나 싶었다.
서류 지원서의 검토는 팀장님께서 모두 진행해주셨고 서류 합격하신분들만 이력서를 전달 받아 면접 준비를 했다.
전달 받은 이력서를 검토하고 그분들의 이력서, 깃허브, 블로그를 운영한다면 블로그도 거의 다 봤었던 것 같다.
면접 질문 준비하면서 팀장님께서는 나에게 기술 질문 위주로 하라고 하셨다. 그리고 팀장님께서는 답이 있는 질문을 하는 것을 좋아하지 않는다고 말씀하셨다. 그 말을 들었을 때는 무슨 말인지 이해를 못했지만 실제 지원자 분들에게 질문을 하니 알게 되었다. 질문에 대한 답변을 들었을 때 단순히 외웠는지 이해를 하고 답한건지 판단하기 어려웠다. 그래서 채용을 할 때는 경험, 개발을 어떻게 하는지에 대한 질문을 하는게 더 나을 것 같고 개념에 대한 질문은 직접적인 질문 보다는 이론과 실전을 조합하여 질문을 하려고 노력했던 것 같다.
코드 리뷰 문화 도입
채용 후 동료분이 업무에 적응 될 때 쯤 코드 리뷰 해보자고 의견을 제시했다. 처음에는 어색하고 남의 코드를 보는 것이 익숙하지 않아 어지러웠던 것 같은데 점차 적응이 되니 서로 실수한 부분과 질문을 받았을 때 어떤 생각을 갖고 어떤 정보를 통해 코드를 작성 했는지 공유하다보니 배울점이 많았다. 혼자서 코드를 작성할 때 갖고 있던 습관이 있었으나 같이 일하시는 동료분의 코드를 보고 “저 코드는 나도 사용하면 좋겠다.” 라는 생각도 들고 유익하다는 생각이 들었다.
리뷰해주는 동료가 있다보니 코드 품질도 좋아지는 느낌이 들었다.
스프린트 회고 도입
작년에는 회사에서는 2주 단위로 스프린트를 진행했다. 스프린트가 끝나고 다음 업무를 진행하느라 정신이 없지만 스프린트 회고를 도입해보니 업무하는 동안 어떤 업무를 했는지 어떤 것을 공유하고 싶은지 정리하는 시간을 갖게 되니 좋았다. 동료분이 회고하시는 내용은 업무 중간에 나한테 질문했던 부분이라 대부분은 알지만 내가 동료분께 공유할 때는 동료분이 알았으면 하는 내용, 내가 업무를 진행하면서 새로 알게 된 내용을 공유했다.
그냥 흘러갈 수 있는 개발인데 한 번 정리를 하는 시간을 갖게 되니 머리속으로도 정리되서 좋았고 회사 내부적으로도 공유 했지만 비즈니스 로직을 제외하고 블로그에 꾸준히 작성할 걸… 이라는 생각이 들었다…
정보처리기사 취득
올해 정보처리기사를 취득했다. 개발 시작할 때 자격증 하나 있으면 좋겠다 생각은 했는데 막상 취득하다보니 신기하다. 필기는 책보고 기출문제 푸니 어렵진 않았는데 실기가 생각보다 진짜 어려웠다. 예전에 교통기사 공부할 때도 실기 시험을 무시했다가 낭패 본적이 있어 꽤 열심히 준비했던 것 같다. 특히 용어가 익숙하지 않은데 머리속으로 외워야하니 어지러운 느낌…
오랜만에 도서관가서 공부하니 어릴 때 도서관에서 공부 했던 기억이 떠올라서 좋았다.
낙오 없이 한 번의 도전으로 자격증 취득하니 성취감을 얻게 된 것이 제일 만족스러웠다.
마무리
2024년에는 회사 내부적으로 많은 변화가 일어나다보니 2023년에 이어서 더 많은 경험을 한 것 같다.
2023년에는 팀장님, 나(프론트엔드 개발자), 백엔드 개발자분 총 3명이서 개발을 진행하다보니 개발에 대해서만 거의 집중했었던 것 같다.
하지만 2024년에는 기획자 1명, 프론트 개발자 2명, 백엔드 개발자 4명, QA 개발자 1명으로 구성되니 개발뿐 아니라 협업에 대해서도 신경을 많이 썼다.
특히 신경쓴 부분은 프론트 개발 지식이 없을 때 어떻게 해야 더 쉽게 설명할 수 있을지에 대한 고민을 했다. 기획자 분이랑 많은 얘기를 했던 것 같은데 기획자 분이 이해될 때 까지 말씀을 드렸는데 이 부분은 예전에 CS 업무를 했던 게 도움이 되지 않았나 싶다.
2025년에는 개발 공부하려고 사놓은 책을 슬슬 보려하고 머리속으로 생각해놓은 아이디어가 있어 가볍게 혼자 할 수 있는 프로젝트를 하려고 한다. 아니면 다른 사람들과 사이드 프로젝트 하는 것도 괜찮을 것 같다.
끝.
