- Published on
10월 4주 있었던 일 정리
- Authors
- Name
- 이건창
Introduction
이번 주도 이슈 대응이 많았지만, 적절한 기한 내에 전부 해결하고
앞으로의 방향
3주 목표
3주 동안 어떤 성과를 낼 수 있을까?
신입사원 면담을 통해 들었던 피드백이야. 나는 어떤 성과를 낼 수 있을까? 나는 이곳에서 어떤 걸 하고 싶을까?
네트워킹에서 뵙던 분 중 데이터 기반 의사 결정을 통해 전략을 세운다는 이야기를 들었어. 왜 그런 과정을 거칠지 찾아보니 다음과 같은 장점이 있었지.
- 객관적인 의사 결정 가능
- 효율적인 커뮤니케이션
- 가치 생산 속도 향상
입사했을 떄 나는 조직이 가진 대량의 데이터를 매우 가치있게 느꼈어. 만약 원하는 지표를 필요할 때 얻게 된다면 이해관계자들이 데이터를 얻기 위한 커뮤니케이션 줄여 해야할 일에 집중 할 수 있어보였어.
그래서 3주 목표로 (1) 서비스 지표 수집 과정을 학습하고 (2) 당장 필요한 서비스 지표를 분석한 후 (3) 시각화를 적용 해보려 해.
그럼에도 이게 회사에 이익이 되는 선택인지는 약간 고민하고 있어. 지금도 충분하게 비즈니스 메트릭을 수집하고 있는 듯 했거든. 그래서 현재 운영되는 비용보다 줄일 수 있는지 분석하고 필요한 서비스 지표가 무엇인지를 분석하는 일이 우선될 듯 해.
잘하기 위해서? 잘 하기 위해서!
내가 하고 싶은게 아니라 해야할 일을 어떻게 찾을 수 있을까.
목표하는 일을 잘하기 위해서는 상황을 분석하고 의도를 이해한 다음 효율적으로 작업할 필요성이 보여.
현재 프로젝트 회고
편리성과 개발 그리고 성능 사이 트레이드 오프
서비스 오픈까지 얼마남지 않은 상황에서 최신 정보가 포함되는 기준으로 그룹을 정렬하고 싶다는 정책 변경 요청이 들어왔어. 조금 풀어서 이야기 하자면 그룹 리스트를 반환하고 있는데, 그룹에 포함되는 정보를 가지고 정렬을 하는 일이었어.
사용자 편의성이 높아지는 일에 동의를 했지만 지금 작업한 배치 시스템에서 내부 데이터를 활용한 넘버링은 추가 작업이 들어가야 하는 상황이었지. 서비스 오픈이 삼 일 정도 남았는데 추가로 요구되는 정책 이해와 코드 관리가 꽤나 버거웠어.
그나마 코드 관리 비용을 줄이기 위해 쿼리를 수정 했지만 조회되는 양에 따라 슬로우 쿼리로 변해서 실행 시간이 터무니 없이 늘어났지. 사용했던 함수는 다음과 같아.
ROW_NUMBER() OVER (
[PARTITION BY partition_expression, ... ]
ORDER BY sort_expression [ASC | DESC], ...
) ...
그래서 관리 비용이 늘어나도 애플리케이션 서비스에서 비즈니스 로직으로 변경된 정책을 구현했어. 덕분에 이전 버전의 성능을 유지할 수 있었지.
원래 나는 사용자의 편의성을 중요하게 생각했고 어떤 일이 있어서라도 변경이 필요함을 어필했었어. 취업하기 전까지만 해도 작성했던 코드들이 사용되지 않아서 너무 아쉬웠거든. 그런데 사용자에게 안정적이고 빠르게 서비스를 전달해야 하는 입장에서 정책 변경 요청은 망설이게 되더라.
편리성을 높이기 위해 안정성이 떨어지는게 맞는 일일까?
서비스를 안정적으로 전달하는 책임을 가지는 나에게는 이런 부분들을 고민할 필요가 있음을 알게 됐어. 만약 부족하다면 다음 기능 추가에서 넣도록 진행했어도 충분했을텐데 말이지.
앞으로는 개발자 포지션으로서 서비스에 기여하는 방법을 배워야 할 듯 해. 그러기 위해서는 회고록을 신중하게 써서 리마인드 하고 개선점을 찾는 일이 가장 효과적으로 보여. 앞으로도 열심히 작성하자구!
QA 진행 중 아쉬웠던 일
정책에 대한 이해가 부족해서 결과 수정 요청을 꽤나 받았어. 이런 요청들을 계속해서 수정하고 서비스 배포까지 얼마 남지 않을 떄 정책을 전부 이해할 수 있었던 게 정말 아이러니했지.
이왕이면 시작 할 때 수행했으면 얼마나 좋았을까. 아마 어떻게 하면 요구사항 분석을 잘 할 수 있을지 고민해봐야겠어.
어떤 책을 읽으면 좋을까?