들어가는 글🙋♀️
약 6개월 간 주로 involved됐던 프로젝트가 마무리 되었다. 이 기간동안에 어떤 일들을 수행했는지를 정리하기 위한 wrap-up을 하고자 한다. 또한 백엔드 엔지니어로서, 한 명의 팀원으로서 성장한 부분이 어떤 것인지 정리하여, 다음 프로젝트에 고려해봐야 할 사항 등을 미리 뽑아내보도록 한다.
Let's wrap up!📑
🔸 개요
해당 프로젝트는 사내에서 진행하던 사이드 프로젝트였다. 말은 '사이드'라고 칭했지만(실제 메인 프로덕트는 따로 있었음) 규모 자체는 아주 작진 않았다. 어느정도 클라이언트의 요구사항을 받아서 프로젝트를 진행하였고, 그 요구사항에 세세한 부분이 많았기 때문이다.
다음의 스펙으로 프로젝트가 진행되었다고 간략하게 소개하겠다.
프로젝트 개요
- 의료 데이터 정제 로직을 통한 결과 값과 이에 대한 예측 결과 값을 보여주는 웹 서비스
서비스 이용자
- 헬스케어 도메인 전문가
투입 인원
- 사업 매니저 1명
- 서비스 기획자 1명
- 디자이너 1명
- 데이터 엔지니어 1명
- 백엔드 개발자 1명(필자)
- 프론트엔드 개발자 1명
- 머신러닝 개발자 1명
- 데이터 분석가 1명
진행 기간 및 스케줄
- 약 6개월의 진행
🔸 목표 및 수행
- 데이터 정제 및 GET API 설계
- 원본 데이터는 유지하며 데이터 변경 로직 추가
- 여기서 원본 데이터라 함은 마스터 테이블의 정보 및 데이터 엔지니어가 1차 처리한 정보를 의미했다. 이는 요구사항에 의해 유지가 되어야 했다.
- 폐쇄망 배포
- 도커 및 쿠버네티스를 이용하여 폐쇄망 배포
- 도커 이미지 태그로 버전 관리
🔸 결과 기여 상세
프로젝트의 서버 로직 개발
전체적인 API 설계, 서비스 DB의 설계를 수행하고 필요에 의해서 데이터 엔지니어나 프론트엔드 개발자와 논의를 하곤 했다. 또한 bulk로 들어온 데이터를 화면에 표현하기 위해 어떤 로직으로 정제할 수 있을지 고민을 했다. 이에 너무 느려질 것 같은 부분은 기획자와 데이터에 대한 논의를 많이 하였다.
외부 업체와의 협업
외부 플랫폼을 사용하며, 여기에서 생겼던 다양한 문제를 최대한 극복하고자 했다. 특히 쿠버네티스 사용하는 데에 있어서 몇 가지 애로사항이 존재 했고, 이 때는 중간 전달자에게 전달하기 보단 직접 담당자와 소통하기도 했다. 특히 전달할 사항이 모호하지 않도록, 시도한 내용/문제된 사항/원하는 사항 등을 글과 사진으로 정리해서 전달했다.
🔸 아쉬운 점
테스트 코드의 부재
테스트 코드를 작성을 해야 유지 보수의 편의성을 높일 수 있었겠으나, 프로덕트 코드 작업하는 것이 바쁜 관계로 이 부분을 많이 놓쳤다. 스스로도 많이 아쉬운 부분이다. 테스트 코드의 부재로 거대한 리팩토링이 필요할 때 조금씩 놓치는 부분이 생기곤 했다.
임시 방편이긴 했지만, 프론트엔드 개발자가 만든 코드를 로컬에 받아 직접 실행하여 화면 상에서 보여지는 데이터들이 리팩토링 전후로 변경이 없는지를 확인하려고 했다. 그렇지만 이는 웹 프로젝트 특성상 유저 테스트를 그렇게 했을 뿐이지, 실제 서버 단에서의 테스트는 부족한 게 사실이어서 더 아쉬움으로 남았다.
코드 리뷰의 부재
아무래도 백엔드 엔지니어로는 혼자 작업했기 때문에 코드 리뷰를 거의 진행할 수 없었다. 틈틈히 동료들에게 코드 리뷰를 요청했지만 각자의 바쁜 이유로 확인이 어려운 경우가 빈번했다. 또한 프로젝트에 참여하지 않는 인원은 비즈니스 로직은 잘 모르니, 만약 리뷰를 해주신다 해도 구조적인 내용 위주로만 리뷰를 해서 한계가 분명 있었던 것 같다.
🔸 배운 점
혼자 개발한다는 것은 오히려 어렵다.
개발 자체를 혼자했다고 볼 순 없지만(데이터 엔지니어나, 프론트엔드 개발자도 있었기 때문에) 그저 백엔드 엔지니어로는 혼자 참여한 프로젝트였다보니 아쉬운 부분이 존재한다. 내가 진짜로 발전하고 있는지 판단 자체가 안되기 때문이다.
그렇다고 매 프로젝트에서 동료와 함께 할 수 있다는 보장은 안된다는 것도 꽤나 현실적인 이유이기 때문에, 이런 경우에는 나의 프로젝트 방향이 잘 진행되고 있는지 체크할 수 있는 방법을 많이 모색해야 할 것 같다.
개발하는 것에서 타협할 수 있는 부분을 고민해본다.
어떨 땐 클라이언트의 요구사항에서 바로 해결하기 어려운 부분이 생기기도 한다. 그게 이유가 어떠했다는 것은 별로 중요하지 않기도 하다. 그럴 땐 최대한 현재의 상황을 판단, 해결 가능한 문제인지 진단을 하고 해결에 걸리는 시간을 가늠하여 전달하는 것이 중요했다.
칸반보드를 잘 활용하여 blocked 된 사항을 잘 정리하고 PM이 이를 인지할 수 있도록 안내를 하는 것은 기본이며, 수행 가능한 사항일 땐 최대한 일정에 맞추도록 노력했다.
🔸 추후 액션 아이템
📌 테스트 코드를 짜자
사실 그냥 말로만 짜자고 하니까 안 짜게 된다. 테스트 코드 짜는 행위 자체가 또다른 품이 든다고 생각하기 때문이다. 따라서 테스트 코드 설계할 때 공통적으로 뺄 수 있는 것들은 차라리 클래스화/모듈화를 잘 해두도록 해야겠다. 이미 있는 패키지를 사용하는 것도 좋고 직접 잘 만들어두는 것도 좋겠다.
📌 비즈니스 로직을 정리하자
'개발자가 비즈니스 로직을 정리해두는 게 옳은가?' 싶을 수도 있다. 그래도 시간이 허용되는 내에서는 간결하게나마 남겨두는 게 중요하다고 생각한다. 해당 프로젝트는 지금 마무리 되지만, 추후의 결정사항에 따라 다시 재개할 수도 있다. 이 때 필자가 이 프로젝트에 다시 투입될 수도 있고 아예 다른 인력이 투입될 수도 있다. 그리고 위에서 아쉬워 했던 것처럼, 코드 리뷰에서 동료가 좀 더 내용을 알 수 있게 도움을 주는 가이드가 필요할 수도 있다. 이 때의 커뮤니케이션 비용을 줄이는 목적을 두면 못 할 것도 아니라 생각한다.
다만 이 비즈니스 로직을 하나의 덩어리로 정리할 순 없으니 어떻게 문서 관리를 하고, 이에 따른 코드는 어떻게 작성이 되었는지를 연결 시킬 수 있게 하는 방법을 찾아야겠다.
마치며🤗
어느 프로젝트를 하든 나는 성장한다고 생각한다. 다만 그 성장한다라는 것의 구체화는 필요하다고 생각한다. 그래야 스스로에 대한 분석이 가능해지고 그 중에 취하고 버릴 것이 어떤 것인지 판단하는 지적 근육을 기를 수 있기 때문이다. 득이 된 것은 내 것으로 잘 정착시키고, 실이 됐다 느껴지는 것은 분석을 통해 다음 액션 아이템을 정하는 것이 가장 중요한 것 같다.
그리고, 여전히 내가 모르는 것들이 많은 것을 깨달았다. 서버 구조적인 것부터 (일부이긴 해도) DevOps의 일, 일을 더 효율적으로 할 수 있는 방안 등 여전히 공부하고 헤쳐 나아가야 하는 것이 많게 느껴진다. 액션 아이템을 생각날 때마다 잘 적어두고 실천 그 자체를 하려고 의식적으로 행동해야겠다.
이번 프로젝트는 그래도 득이 훨씬 많았던 프로젝트였다 생각한다. 배운 것들은 잘 정리하고, 아쉬웠던 것은 개선하여 다음 프로젝트에서는 보다 성장한 상태로 임할 수 있었으면 좋겠다.
