[TIL] Trollo - 팀 프로젝트 KPT 회고

phdljr·2024년 1월 3일

KPT TIL Trollo

TIL

목록 보기

50/70

서문

스프링으로 팀 프로젝트를 진행하는 시간을 갖게 되었고, 성공적으로 마무리를 지을 수 있었다. 이러한 경험을 토대로 KPT 회고를 작성하려 한다.

KPT 회고란 Keep, Problem, Try의 약자로 회고 방법 중 하나라고 한다.

Keep은 좋았거나 계속 이어갔으면 하는 부분
Problem은 부족했거나 개선이 필요한 부분
Try는 어떻게 개선할 것인지에 대한 부분

KPT를 진행하기 전에 나의 느낀 점

이번에는 Trello의 칸반 서비스를 따라 해보는 Trollo 프로젝트를 진행하게 되었다.

주어진 시간은 주말과 연휴를 포함해서 대략 10일이었다. 필수 요구사항만 먼저 구현하고 나머지 요구사항을 추가하는 방식으로 진행하며 MVP 형식으로 기능을 구현하고 AWS를 통해 클라우드상에서 배포했다.

이미 존재하는 서비스를 따라 만드는 프로젝트 즉, 클론 코딩을 직접 하게 되었는데, 여기서 중요한 점은 원래 서비스를 직접 사용함으로써 직접 로직을 파악해보는 시간을 갖는 것이다.

해당 서비스가 오픈 소스라면, 직접 소스 코드를 뜯어보면서 해석해보는 것도 좋은 방법일 것이다. 하지만, 이번 프로젝트에서는 직접 사용만 해보고 어떻게 동작하는지, 어떤식의 원리를 갖는지를 생각해보며 설계를 진행하게 되었다.

사실, 칸반 보드 서비스의 기능들은 대부분 게시판 프로젝트만 비슷한 기능들이 많았다. 그러나, 카드의 위치를 옮기는 기능이 이렇게 까다로울 줄은 몰랐다. 그 이유는, 복잡성과 효율성을 갖춰야 되기 때문이다.

카드의 수가 많으면 많을수록, 순서에 대한 정보를 업데이트하게 해주면 시간이 오래 걸릴 것이다. 그래서 단순히 순서라는 속성을 테이블에 추가시키기 보단, 이중 연결 리스트를 사용함으로써 생성/수정/삭제에 대해 복잡도를 O(1)을 가지는 효율을 챙겨보려고 노력했다. 칸반 보드의 특성상, 수정이 잦을 거라고 예상하였기 때문이다. 대신, 조회하는 속도는 O(n) 만큼의 복잡도를 가지게 된다.

이 부분을 직접 구현해보니, 자료 구조를 프로젝트에 직접 적용시키는 것이 생각보다 힘든 작업임을 느끼게 되었다. 그래도 그만큼 얻어가는 것이 있기에 좋은 학습이 되었다.

새로운 팀원들과 같이 ERD도 작성하고, 기능에 대한 시나리오를 작성해보면서 서로의 생각을 공유하는 시간을 가져보니 오해하거나 잘못 생각하는 일이 확실히 줄어드는 효과가 있었다.

여태까지 글을 통해 서로의 생각을 공유했다면, 다음 부터는 UML을 통해 다양한 다이어그램으로 서로의 생각을 공유하면 어떨까라는 생각이 들었다. 괜히 소프트웨어공학에서 UML을 배운게 아니라는 느낌이 들었다. 자신의 생각을 팀원들에게 효과적으로 전달시키는 방법을 배우는 것이 UML이 아닐까라는 생각이 든다. 글 보다는 그림이 더 직관적이 때문에, 다양한 다이어그램의 종류가 나왔다고 생각해본다.

이번 프로젝트에선 배포까지는 구현했지만, 기능과 배포에만 몰두하다보니 테스트 코드를 작성하는데 시간을 투자하지 못했다. 테스트 코드가 없으니 매번 수작업으로 테스트를 하게 되는데, 확실히 이 부분에서 시간을 잡아먹게 되는 것 같다. 테스트 코드를 먼저 작성하는 습관을 들이도록 해야겠다.

또한, CI/CD 파이프라인을 구축하지 못하여서, 테스트와 배포 자동화를 도입하지 못하게 되었다. 사실, 테스트 코드가 없어서 CI는 크게 의미가 없다고 보고, CD도 기능을 다 만들고 난 뒤에 배포를 하게 돼서 없어도 큰 문제가 없었다. 다만, 테스트 코드가 많고, 배포가 잦다면 확실히 CI/CD를 구축하는 것이 훨씬 편하고 생산성을 높여줄 것 같다.

다음으로, 팀원들과의 KPT 내용을 적어본다.

Keep

데이터베이스에서 자료구조를 적용해 데이터를 관리한다는 점이 신선했다.
팀원들이 적극적으로 의견을 제시해줘서 다양한 경험을 얻을 수 있었다.
Github를 규칙대로 사용해서 충돌이 잘 일어나지 않았다.
시나리오를 미리 분석 작성 해보니 어떤식으로 코드를 짜야할 지가 수월하였다.
도메인 별로 역할을 맡고 패키지 구조 또한 도메인으로 정렬하여 깃 충돌이 상대적으로 적게 발생했다.
풀 리퀘스트를 통해 코드 리뷰를 진행한게 실력적으로도 도움이 되었고 비즈니스 로직간 충돌을 예방할 수 있었다.
기존 방식말고 새로운 방식을 시도하였다.
뭔가 부족한 듯 하지만 고급기능까지 도전 성공
커밋,브랜치 컨벤션이 있고 깃허브에 이슈와 함께 등록하여 깃허브 관리가 깔끔하게 되고 기능들의 구조나 진행상황을 파악하기 좋았다.
ERD나 여러가지를 설계할 때 다 같이 모여서 여러가지 의견을 내면서 생각해보고 정리하는것이 좋았다.
리뷰를 받고 나서 코드에 대해 한번 더 생각해보는 시간을 가지게 되어 좋았다.
여러가지 새로운 것들도 많이 시도해보고 이것저것 알아보고 적용한 점이 좋았다.
프로젝트 설계를 시작할 때 분석 및 시나리오, 규칙등 세세하게 회의하면서 S.A를 작성한 것
이슈, 프로젝트, 풀리퀘스트 등 여러가지 기능들을 사용해봤다.
오류가 발생하면 그 오류를 해결하기 위해서 팀원들과 소통하는 부분이 좋았다
개발 하려고 하는 내용에 대해서 다시 한 번 정리하고 생각할 수 있어서 복습을 할 수 있었다.
코드 리뷰를 통해서 새로운 코드 스타일을 적용해 볼 수있어서 좋았다.

Problem

시나리오를 작성하는 부분에서 미흡한 부분이 존재했다.
테스트 코드가 없어서 해당 기능이 잘 작동되는지를 확인하지 못했다.
연휴기간이라 시간대가 맞지 않아 소통이 약간 아쉬웠다.
사용했던 개발도구들의 버젼에 대한 설명이 부족했다.
테스트코드를 작성하지 못하였다.
CI/CD 파이프라인 구축 해보지 못했다.
프로젝트 기간과 연휴가 겹치고 개인사정 등으로 퀄리티 개선이나 배포에 대한 시간이 조금 부족했던 것 같다.
테스트코드를 작성하지 못했다.
이슈를 깃허브에 push하는 타이밍에 생성하여서 다른 팀원에게 할당된 업무가 뭐기 있는지 뭘 진행하고 있는지 파악할 수 없다.
연휴 기간으로 인해 시간이 부족했다.
프로젝트 기간이 너무 짧은거에 비해서 연휴가 포함되다 보니 시간이 조금 부족했다고 느꼈다.
다양한 문제가 발생하는데 그 오류를 해결하기 위해서 디버깅을 찍고 여러가지 방법을 시도했는데 지우고 다시 생성하면
잘 돌아가는 이유를 아직까지도 알지 못해서 아쉬웠다.
S3를 사용하면서 IAM 계정 AWS 엑세스키가 손상된 이유를 도저히 모르겠다.

Try

테스트 코드 꼭 작성하기
CI/CD 파이프라인 설계하기
기술 구현 자체보다는 기능 및 도구를 사용한 명확한 이유 설명할 수 있게 하기
진짜 간략하게라도 테스트코드 시도해보기
리뷰받은 코드는 수정 전에 따로 작성 해두고 정리해보기
다음에는 기능을 모두 프로젝트의 Todo에 백로그로 작성해두고 구현하는 기능이나 세부 기능만 in progress로 옮기든 issue를 하위에다가 만들어서 하든 하면 전체적인 진행도 추적이 더 쉬울 것 같다.
코드 리뷰를 나를 포함해서 모든 팀원이 더 적극적으로 한다면 로직 상의 문제점등을 더 빨리 찾을 수 있지 않을까 싶다.
pull request 리뷰를 적극적으로 하기
프로젝트 구성을 최대한 빠르고 완벽하게 끝내고, 본인이 잘하는 부분을 개발하면서 협업을 하면 좋을거같다.
어려운 부분은 하나의 공통주제로 두고 다 같이 협력하면서 하면 좋을거 같다