KPT 회고
KEEP, 다음 프로젝트로 가져갈
· 추가 구현에서 경험한 동시성 처리, Redis를 이용한 캐시의 이점, 쿼리와 인덱스를 이용한 최적화, 젠킨스와 도커를 이용한 CICD까지 직접 구현하진 않은 부분일지라도 팀 노션에 작성된 부분을 통해 간접 경험을 하거나 동료의 구현 모습을 보면서 좀더 본인의 기술을 디벨롭 할 수 있는 경험.
· 의견 차이를 커뮤니케이션을 통해 극복하는 자세를 유지하면 좋다. 대부분의 개발이 단체로 이뤄지기 때문에 의견을 수용하고, 배우는 자세를 유지하는것은 매우매우 좋음.
· 동시성 처리에서 분산락, 낙관락, 비관락을 활용한 다양한 동시성 처리 방식을 적용해보았고, 각 방법이 특정 메서드에 얼마나 적합한지 확인하는 과정을 거침.
· 외부 API 호출을 통한 알림 기능에서 외부 API를 활용해 알림 기능을 구현한 경험을 바탕으로, 이를 다른 프로젝트에서도 유용하게 활용할 수 있을 것임.
· JMeter를 활용한 서버 부하 테스트에서 JMeter를 사용해 병렬로 서버 부하 테스트를 진행하며, 특정 메서드에 가장 적합한 동시성 처리 방식을 검토할 수 있었음.
· Redis를 이용한 캐시의 이점, 최적화방법들, CI -CD 구현 방법들
· JMeter를 이용한 서버 부하 테스트를 통해우리가 추론하지않고 눈으로 결과가 보여 더 효율적으로 대처하기가 좋았음
· 일단 해보자 라는 마음으로 처음 맡은 부분이더라도 우선 믿고 팀원에게 그 역할을 주고 기다려준 부분
· 팀원들이 맡은 역할을 기대한 그 이상으로 해낼 것이라는 믿음에 각자 본인도 기여하기 위해서 더 노력하고 이루어낸 부분
PROBLEM, 버려야 할
· 문제 발생시 혼자 해결하려는 자세는 지양하는게 좋다. 해결하는 과정부터 디벨롭의 양분이 되기 때문에 어느 문제라도 공유는 하는것이 좋다. 다만 해결방안을 고민한 후 같이 공유하는게 더 좋아보임
· 구현에 우선순위를 두고 문서작업은 뒤로 미루고 구현부터 하는건 좋지 않다. 나의 경우 젠킨스를 세팅하면서 나름 문서작업도 열심히 했다고 생각하는데, 몇몇 누락된 오류가 있고, 이 오류를 해결하기 위해서 다시 구글링을 해야하는 문제가 발생한다. 이런 문제를 다시 마주하지 않기 위해선 문서 작업을 더 열심해 해야한다.
· 테스트 및 성능 모니터링 부족했음. JMeter를 통한 부하 테스트 및 성능 측정을 도입했지만, 테스트 환경 구성과 시나리오 작성에서 어려움을 겪음.
· 비관적 락에 대한 실시간 충돌 처리 문제를 겪음. 비관적 락을 적용할 때는 트랜잭션 대기 시간이 증가하면서 성능 저하가 나타남.
· 시도해보기 전에 내가 할 수 있을지 걱정하는 마음을 버려야함. 이러한 마음을 가짐으로써 내가 가진 역량보다 적은 역량을 발휘하게 될 수 밖에 없음
· 팀원과 소통하지 않고 혼자서 문제를 해결하는 태도
· 더 많은 기능 구현을 위해 앞을 보고 코드를 짰는데, 어느 정도는 뒤를 보고 내가 짠 코드들을 더 점검하고 나은 방법들을 더 많이 생각했다면 몇 가지 기능들을 더 나은 방식으로 구현할 수 있었을 것.
TRY, 새로 시도할
· 지금 조에서 본인의 영향력이 약간 부족하다고 느껴진다면, 다음 조에선 적극적으로 리더롤을 가져가보는것도 좋아보임.
· 현재 로그인 알림에만 국한된 Slack 알림 기능을 확장하여 프로젝트의 다양한 이벤트(카드 수정, 업무 완료 등)에도 알림을 연동하는 시도를 해볼 수 있음. 또한 알림의 커스터마이징 기능을 추가하여 사용자별 알림 설정을 다르게 제공할 수 있도록 기능을 확장.
· Jenkins(githubAction)를 이용해서 좀 더 효율적인 CI - CD 를 구축해 보는걸 새롭게 시도해보기
· 대규모 데이터 처리를 위한 여러 방법들 적용을 해보고 경험해보기
· JMeter 등 여러 툴을 경험해보고 익숙해지기
· 5분 기록을 제대로 작성하지 않아 앞으로 잘 써야겠음
· 팀원들이 구현한 기술에 내가 모르는 부분들은 이후에 추가로 학습이 필요해보임
· 중요한 비즈니스 로직의 테스트를 추가하여 커버리지를 높일 필요가 있어보임
· 파일 업로드를 비동기로 처리해 업로드 성능을 개선시켜도 좋아보임