안녕하세요, Kernel 360 백엔드 2기 크루 박소은이라고 합니다!
어느덧 12월이 되어 파이널 프로젝트도 슬슬 마무리가 되고 있는데요, 어떻게 만들어지고 있는지 한 번 확인해보도록 하겠습니다!!!!
기획
사실 3팀의 기존 주제는.. "자녀 위치 찾기 서비스"였는데요!
위치 서비스를 제공하기 위해서는, 앱으로 개발하는 것이 훨씬 적합하며, 웹앱으로는 어려움이 있었기 때문에 주제를 변경하게 되었습니다.
저희 팀원은 모두 웹 개발을 생각하고 모였기 때문에, 아이디어를 낼 때 이런 부분을 생각해보면 좋을 것 같아요! (본인이 낸 아이디어였거든요..)
이틀차에 기획이 완전 뒤집어졌지만, 팀원들이 다시 열심히 힘을 모아 새로운 아이디어가 나오게 되었습니다! 아래처럼 농사 정보 플랫폼, 밈 백과사전, . . 등 다양한 아이디어가 나왔는데요!
저희 팀은 최종적으로 "배드민턴 동호회를 위한 커뮤니티 서비스"를 개발하게 되었습니다!
가까운 지역, 비슷한 실력의 사람들과 함께 배드민턴을 칠 수는 없을까?
배드민턴 동호회에서 더 편하게 사용할 수 있는 서비스를 만들어보기로 했습니다!
기능 회의
어떤 기능이 필요할지 팀원들과 꽤 오랜 시간 이야기했던 것 같습니다. 서로가 가지고 있던 생각이 일치하는지, 달랐다면 어느 방향으로 갈 것인지 차근차근 정해나가기 시작했습니다.
경기 대진표를 두 가지 방식으로 생성해주고, 점수를 쉽게 기록하고, 메인 화면에서 여러 경기의 진행 상황을 한 눈에 볼 수 있는 기능이 핵심 기능입니다.
https://vast-volcano-c8c.notion.site/e2e82282eb2a426b9fb33830fc4bd7c3?pvs=4
와이어 프레임
기능 회의 이후, frame0으로 와이어프레임을 그렸습니다. 아래처럼 쉽고 깔끔하게 그릴 수 있어서 추천하는 툴입니다.. !
참고로, Kernel 360 프론트엔드 디렉터님께서 만드셨다고 합니다.. !!!!! 대박
컨벤션, 협업 규칙, 마일스톤, . . .
3달 간의 프로젝트를 아주 잘!! 하기 위해서 위의 사항들을 많은 회의를 거쳐 정했습니다. 하루에 회의를 6~7 시간을 하면서 첫주차를 보냈던 것 같아요! 아무래도 장기전이고, 팀 프로젝트를 하다 보면 갈등 상황도 생기기 때문에 서로 스트레스를 받거나 힘들 때 어떻게 마인드 컨트롤을 할지도 이야기했어요!!ㅎㅎ
Github 컨벤션도 아래와 같이 정리했습니다. 다른 기업들의 개발 문화를 많이 참고하려고 했던 것 같아요!
https://vast-volcano-c8c.notion.site/Github-6c2c1523df8740d3a1e5eeb7f4dd2d54?pvs=4
요구사항명세서, 기능명세서, 에러 명세서, API 명세서, . . .
초반에는 각종 문서화 작업을 하느라 정신없이 바빴던 것 같아요! 문서화가 되어있으니 작업을 하면서 확실하게 더블 체크를 할 수 있었고, 서로 알고 있는 것이 동일한지 확인할 수 있었습니다.
코딩컨벤션
본격적으로 개발에 들어가기 전, 코드 스타일을 정하고, 코딩 컨벤션을 정했습니다. 개발을 시작하고 나서, 코드 리뷰를 통해 정할 수도 있지만, 생각나는 것들은 미리 정하기로 했습니다!
1. 정적 팩토리 메서드 vs 생성자 vs 빌더
2. Entity에 사용할 어노테이션
3. toDto, toEntity 어디에?
4. 에러 코드, 커스텀 예외
5. 검증 validator
.
.
.
장단점을 생각해보고, 많은 회의와 토론 끝에 하나씩 정해나갔습니다. 물론 개발을 하다가 더 나은 방법을 찾아 변경된 부분도 있었지만, 미리 이러한 얘기를 해보고 개발을 시작한 덕분에 토론하는 개발 문화가 정착되었고, 더 나은 고민을 찾을 수 있게 되었습니다!
개발
다양한 의견을 주고 받으며 코드 리뷰를 하고, 하나씩 기능을 구현해나가기 시작했습니다!
함께 고민하고, 토론하기
활발하게 소통하고, 코드 구조를 어떻게 개선할지 끊임없이 고민하는 것이 팀 문화로 정착되었는데요! Github의 Discussion 기능을 사용하기도 하고, 스크럼 시간, 페어 프로그래밍, 코드 리뷰 등 다양한 방법으로 팀원들과 토론을 했습니다.
프로젝트를 진행할 때 아래 두 가지를 끊임없이 생각하고 챙기려고 했습니다!
왜?를 고민하기
왜?를 끊임없이 고민하고 나면, 더 나은 선택을 할 수 있었습니다. 고민을 많이 했던 과정이 성장의 원동력이 되어줬던 것 같아요! 어떤 기술을 선택할 때 장단점을 고민하고, 많은 공부를 한 다음, 팀원들과 논의해 하나씩 결정해나갔습니다. 항상 상황에 더 적합한 판단을 하기 위해 많이 노력했던 것 같아요!
꼼꼼한 코드 리뷰
코드 리뷰에 시간을 조금 더 들이고 있습니다! 내 팀의 코드라면, 모르는 것이 없도록 코드 리뷰를 굉장히 꼼꼼하게 하고 있어요! 실제로 현업에 가면 코드를 작성하는 시간보다 읽는 시간이 더 많다고 종종 듣게 되는데요..! 내가 작성하지 않은 코드를 이해하고, 적절한 피드백을 남기는 능력도 아주 중요하다고 생각해요! 팀의 코드 스타일을 지키고 코드 품질을 올리는데 가장 좋은 수단이기도 한 것 같습니다:)
위와 같은 과정 이후에는 Notion이나 블로그 등에 결정한 사항을 하나씩 정리하고 있습니다:)
아래는 조회수를 비동기로 처리하게 된 과정을 담은 글입니다 :)
https://velog.io/@carol_ly/Event-Publisher-사용해-조회수-로직-개선하기-Async-빠뜨렸을-때-일어나는-일
배포 및 운영 & 성능 개선
EC2로 배포하고, 서비스를 운영함과 동시에 유지 보수를 하고 있습니다!
지속적으로 성능을 개선하며, 추가적인 기능을 구현하고 있습니다. 고객의 피드백을 받아들여 사용자 경험을 개선하는데 집중하고 있습니다.
먼저 팀원들과 QA를 진행해 응답 시간이 500ms 이상 소요되는 API를 찾았습니다. 이를 인덱스, 캐싱(레디스), 비동기 처리, . . 등등 다양한 방법을 적용해 평균 2~3 배 이상 속도를 개선할 수 있었습니다! 그 중에는 1~2s 이상 걸리는 API도 있었는데요..! 문제의 원인을 찾고, 코드를 지속적으로 리팩토링하고, 성능을 개선하다 보니 이제 200ms로 줄어들어 무려 10배의 성능 개선을 체감할 수 있었습니다!
아래 링크를 통해 어떻게 성능을 개선했는지 확인해보실 수 있습니다 :)
https://gabby-hygienic-d26.notion.site/15730c219576803a9858f478ed9d68e0?pvs=4
마치며
지금까지 FINAL 프로젝트가 어떻게 진행되었는지 글에 담아보았는데요, Kernel 360 이 궁금하신 분들께 조금이라도 도움이 되셨길 바랍니다! ㅎㅎ 긴 글 읽어주셔서 감사합니다~!
