안녕하세요. 황진성입니다.
최근에 회사에서 기능 하나를 개발하게 되었는데, 그 이야기를 해볼까 합니다.
개요
약 한 달 전, 유저 유입과 인터렉션을 늘리기 위해 특정 조건을 만족하는 유저에게 푸시 알림을 보내주는 기능을 개발하게 됐습니다.
결론적으로 기능 배포 2일 차인데, 관련 지표에서 평균 이상으로 좋은 성과를 보여주고 있습니다. 😮💨
지금은 정상적으로 동작하지만, 여기까지 수많은 핫픽스 배포가 있었습니다. 여러 핫픽스는 코드 리뷰와 배포 승인을 해주는 백엔드 셀에게 피로감을, 제 때 정상적으로 동작하길 기대했던 PO에게 불안감을 줬습니다.
최근에는 잠도 거의 못 잘 만큼, 기능을 개발하는 과정에서 많은 고민과 걱정거리가 있었습니다. 이 기회에 이번 일을 확실히 짚고 넘어가서, 더 성장한 내가 되기 위해 글로 정리해 보겠습니다.
내가 생각한 패착 요인
1. 전반적인 백엔드 시스템에 대한 이해도가 낮았다.
운영하는 서비스가 Microservice로 구성되어 있는데, 각 컴포넌트들의 역할을 모두 이해한 상태는 아니었습니다. 처음 기능 개발을 했을 때는 Happy case만 생각해서, 제가 사용해 본 컴포넌트들만 구성해서 기능이 동작하도록 구현했습니다. 빠르게... 는 구현할 수 있었습니다.
하지만 코드 리뷰에서 성능 이슈가 있을 것 같다며 역할 별로 컴포넌트를 분리하라는 의견이 나왔습니다. 저도 그 의견에 동의했기 때문에 컴포넌트 분리를 시도했습니다. 하지만 컴포넌트 간 Kafka를 사용해 통신하고 있었는데, Kafka에 대한 전반적인 지식이 부족해서 분리하는 데 시간이 오래 걸렸습니다.
2. 어려운 부분에 대해 빠르게 공유하고 질문하지 않았다.
각 역할 별 DB가 분리되어 있는 환경에서 서비스를 운영하고 있습니다. Multi Datasource를 제어하기 위해 여기저기 흩어진 JPA configuration을 하나씩 살펴보기 시작했습니다. 하지만 여태 Single Datasource만 사용했던 저는 너무 복잡해서 이해하기 힘들었습니다. 하나씩 찾아보며 왜 이렇게 설정했을까 고민하며 관련 컨텍스트를 이해하려 노력했습니다. 이제 와서 드는 생각은 팀원분에게 30분만 시간 내서 설명을 부탁드렸으면 시간을 훨씬 아낄 수 있었을 거라는 생각이 들었습니다.
DB 서버가 물리적으로 분리되어 있으니 트랜잭션을 어떻게 처리할지 고민을 많이 했습니다. 여러 방면으로 학습해 본 결과, 2 Phase commit 방식을 사용할 수 있도록 만들어둔 JTA Atomikos 라이브러리를 활용해 보기로 했습니다. 의존성 추가해서 비즈니스 로직에 요리조리 적용하는 것을 시도해 봤습니다. 하지만 마음처럼 쉽게 동작하진 않았습니다. 24시간이 넘게 고민과 삽질을 하고 있었는데, 팀원분이 잘 진행되고 있냐고 물어보셨습니다. 현재 상황을 얘기했더니 비동기 처리하면 신경 쓰지 않아도 될 거 같다고 말씀해 주셨습니다. 제가 적당한 타이밍에 의견을 먼저 여쭤봤으면 이런 일이 없었을 텐데 너무 아쉬웠습니다.
3. 주어진 한정된 시간을 중요한 일에 사용하지 않았다.
기술적인 이슈들은 경험이 많은 시니어 팀원에게 여쭤보며 빠르게 넘어가고, 테스트에 집중했어야 했습니다. 매우 다양한 Input이 들어올 수 있는 기능이었기 때문에 정상적인 동작을 위해 테스트에 가장 많은 시간을 투자했어야 하지만, 그러지 못했습니다.
4. 성능 테스트를 하지 않았다.
기능 개발 전, 테스트 대상이 N만 명이라는 얘기를 들었습니다. 분명 알고 있었음에도 그에 대한 대비를 하지 않았고, 겨우 10명 내외로 테스트 후 개발이 끝났다고 생각했습니다. N만 명이라는 숫자를 너무 낮게 생각했습니다. 실제 동작을 보니 Bulk insert는 생각보다 오래 걸렸고, 메시지 consume 하는데도 시간이 꽤 걸렸습니다.
5. Estimation을 잘못했다.
애자일 스크럼 방식으로 프로덕트를 개발하고 있습니다. 스프린트 플래닝 때, 진행할 스토리에 대해서 스토리 포인트를 책정하고 있습니다. 적절하게 Estimation 하는 것은 중요합니다. 저는 예상보다 낮게 설정해서, 팀원들에게 혼란을 줬을지도 모릅니다.
6. 코드 리뷰에 예의가 없었다.
코드 리뷰는 팀원들이 귀한 업무 시간을 내서 진행해 주는 것임을 잊으면 안 됩니다. 퇴근 후 연락해서 배포 승인해 달라고 요청하는 것은 예의 없는 행동일 수 있습니다.
다른 사람이 작성한 코드를 읽고 이해하는 것은 굉장히 힘든 일이라고 생각합니다. 코드에 대해 충분히 설명하고 주석을 작성해야 합니다. 리뷰 할 충분한 시간도 드렸어야 하지만, 바쁜 배포로 인해 리뷰를 재촉했습니다. 충분한 검토로 이어지지 못했고, 이는 곧 장애로 이어졌습니다.
배운 점
부정적인 말만 한 것 같은데, 배운 점도 당연히 있었습니다.
1. 전반적인 백엔드 시스템에 대해 이해할 수 있었다.
입사한 지 4개월이 다 되어 가는데, 드디어 모든 컴포넌트를 한 번씩 다뤄봤습니다. 우리 팀의 백엔드가 어떻게 동작하는지 조금 더 구체적이고 명확하게 알 수 있는 기회가 되었습니다.
2. "일을 잘하는 것"에 대한 근본적인 의문을 가지게 되었다.
자기 자신에게 문제가 있음을 스스로 인식하는 것이 문제를 해결하는 과정의 절반이라고 생각합니다. "내가 일을 잘하고 있는 것인가?"라는 의문이 들었습니다. 하지만 "No"인 것 같아서 많이 혼란스러웠습니다. 일을 잘하기 위해 어떻게 해야 할까 고민을 해봤습니다. 추상적인 방법 말고 구체적인 방법으로 생각을 해봤습니다.
어떻게 하면 더 잘할 수 있을까?
그래서 어떻게 하면 일 잘하는 신입, 주니어 개발자가 될 수 있는지 고민을 많이 해봤습니다.
(글을 작성하는 현재의 제 생각인데 나중에 추가되거나 삭제될 수 있습니다.)
1. 질문을 잘하자.
질문을 잘하면 대부분의 문제는 해결된다고 생각합니다. 신입이고 주니어이기 때문에 일을 잘하기 위해서는 경험이 많은 팀원들의 이야기를 잘 듣는 것이 중요하다고 생각합니다.
단, 모든 것을 알려달라는 듯 질문하는 것은 좋지 않습니다. 왜 이런 질문을 하게 되었는지 근거가 있어야 하며, 이 질문을 해결하기 위해 어떤 노력을 얼마큼 했는지 충분한 공유도 함께 이뤄져야 합니다. 문제를 해결하고자 하는 의지만 있다면 당연히 함께 이뤄질 것입니다.
스프린트 데일리 스크럼을 진행하고 있지만, 이 자리에서 제가 직면한 문제를 얘기하면 팀 전체에게 제 이슈를 raising 하는 느낌이 들어서 망설여졌습니다. 하지만 앞으로는 쉽게 해결되는 이슈를 제외하곤 모든 방해요소를 공유할 예정입니다.
2. 빠르거나, 완벽하거나.
같이 일을 하는 팀원으로써, 일을 빠르고 완벽하게 하는 사람이 최고라고 생각합니다. 하지만 그게 힘들다면 빠르게 일을 하거나, 완성도가 높게 일하거나 둘 중 하나는 갖춰야 한다고 생각합니다. 하지만 이번 기능 개발 건에서 저는 두 조건 모두 만족하지 못한 것 같아서 역량이 부족하다는 것을 많이 느꼈습니다.
함께 일하는 팀이라면, 서로에게 어떤 일을 줘도 잘 해낼 거라는 신뢰감이 있어야 한다고 생각합니다. 하지만 일을 어떤 방면으로든 잘 해내지 못한다면 신뢰가 깨질 것이고, 최악의 경우에 팀 전체에 좋지 못한 영향을 미칠 수도 있습니다.
3. 내 일은 내가 찾아서 한다.
팀원들 모두가 바쁘다면 각자 어떤 일을 해야 하는지 챙겨주지 못할 때가 있습니다. 이때 내가 해야 할 일을 직접 찾아서 하는 것이 중요하다고 생각합니다. 예를 들면, 다음과 같습니다.
- 업무를 요청한다.
- 이미 등록된 이슈가 있는지 확인한다.
- 팀에서 개발하는 코드에 익숙하지 않다면 코드, 시스템, 아키텍처를 분석한다.
- 팀에서 사용하는 기술에 대해 학습한다.
- 팀에서 운영하는 프로젝트의 개발환경, 빌드, 운영, 배포, 모니터링 등 개선점이 있는지 찾아보고 개선한다.
이러한 과정들이 팀에서 하는 일에 대해 이해도를 높여주고, 기술적 역량을 기르는 데 큰 도움이 될 것이라 생각합니다.
4. 매일 학습한다.
너무 당연한 것이라고 생각합니다. 물론 실무 경험이 일을 잘하는데 더 도움이 되는 것 같지만, 이론 지식 없이는 아무것도 할 수 없습니다. 특히 주니어라면 꾸준한 학습은 매우 중요하다고 생각합니다. 어느 순간부터 관성이 생겼음을 느꼈는데, 습관적으로 퇴근하고 집에 오면 노트북을 펴는 게...
5. 큰 작업을 작고 명확한 하위 작업으로 분리해서 진행한다.
작업이 너무 크면 지금 당장 어떤 일을 해야 할지 명확하게 떠올리기 쉽지 않을 수 있습니다. 아마 이 글을 읽는 대부분의 분들이 고전적인 방법을 알고 있을 겁니다. 큰 작업을 여러 개의 작은 작업으로 쪼개서 하나씩 작업을 진행하면, 하나의 이슈에 할당되는 코드 변경사항도 작아집니다. 이는 곧 코드 리뷰하기 좋은 모습이 되었음을 의미합니다.
6. 일을 하기 전에 일을 왜 하는지 파악한다.
개발 요구사항이 명확하게 나오지 않았는데, 개발에만 집착하다 보면 PO와 소통이 원활하지 않을 수 있습니다. 내가 지금 개발하는 기능이 왜 필요한 건지, 유저에게 어떤 가치를 전달할 수 있는지 알고 있다면, 개발할 때 선명도가 훨씬 높아짐을 느낄 수 있습니다. 덕분에 PO와의 의사소통도 원활해집니다.
7. Estimation 할 때 크게 잡는다.
내 예상 * 1.3으로 추정치를 잡습니다. 작업 중 갑자기 추정치를 늘리면 나비 효과로 일정에 차질이 생기거나, 일을 게을리한다는 의심을 받을 수도 있을 것 같습니다. 하지만 작업 중 추정치를 줄이면 일을 잘하는 것처럼 보일 것입니다. 남는 시간에는 다른 작업을 미리 당겨와서 진행하면 됩니다. (말하고 나니 이상한 사람 같네요..)
일을 즐겁게 하는 것
일이 즐거울 때도 있지만, 즐겁지 않을 때도 있습니다. "일이 꼭 즐거워야 하나?"라는 생각이 들 때가 있는데, 그렇지 않은 것 같습니다. 마냥 즐겁기만 하다면 그건 취미로 남겨두는 게 오래오래 좋을 것 같습니다. 때론 즐겁고 때론 고통스럽지만, 고통을 감내하고서라도 그 분야의 전문가가 되고 싶다는 생각이 들면 비로소 일을 하고 있다고 느낍니다. (라고 겨우 2년 차가...)
맺음말
사실 위 대부분의 내용을 매니저와 1 on 1 시간에 공유를 하고 얘기를 나눴습니다. 평소에는 1 on 1에 가볍게 참석하는데, 오늘은 뭔가 준비하고 싶어서 Google의 1 on 1 아젠다 템플릿을 참고해서 준비를 했습니다. 업무에 관한 생각, 업무에 대한 피드백, 앞으로의 커리어 등 다양한 얘기를 나눌 수 있는 시간이어서 좋았습니다.
유독 힘들고 폭풍 같던 시기가 지나갔는데, 그래도 성과가 잘 나와서 후련하네요.
긴 글 읽어주셔서 감사합니다.
(제 글에 대한 피드백 환영합니다.)
'📝 일상 > 회고' 카테고리의 다른 글
| [회고] 2023 생각 스냅샷 (4) | 2024.01.07 |
|---|
