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