2023-12-11(BA클럽 KPT 회고)

이승준

 

중요한 SA 작업을 확실히 하고 넘어가지 않음

⬇️

각자 맡은 부분 구현하면서 API 작성

⬇️

기능 구현 후 합치는 작업

 ⬇️

많은 충돌 발생

 

Keep	구현할 수 있는 기능을 최소 목표로 잡고 진행해서 좋았던 거 같습니다. 그리고 역할 분담도 잘해서 각자 맡은 부분이 있어서 좋았습니다.
Problem	초반 SA작업을 하기는 했지만 꼼꼼히 진행하지 못해서 아쉬웠습니다. 그리고 필수 구현 기능을 빠르게 하고 추가기능을 시도했으면 좋았을 거 같습니다. 다양한 API 구현을 하지 못한게 아쉬웠습니다. github에 각자 구현한 기능을 모으는 과정에서 시행착오가 있었습니다.
Try	git에 대한 이해도를 높이고 모두모여서 pr날린것을 확인하고 머지를 진행하였습니다. 추가 API 구현을 하기 위한 초석은 만들어 놓았기 때문에 개인적으로 시도해 보면 좋을 거 같습니다. 초반 SA작업에 맞게 진행하지 못해 충돌이 났지만 겹치는 부분을 진행한 팀원끼리 모여서 해결을 할 수 있었습니다. 이러한 과정을 통해 초반 SA작업의 중요성을 확실히 알 수 있었습니다.

 

 

장하람

1. 처음에 이전 팀에서 배운 Mapper 기능을 사용해서 게시글에 관한 매핑을 하려고 했으나, 머지할 때 충돌이 많이 발생했고, 다른 팀원과의 컨벤션이 일치하지 않는 것이 그 원인 중에 하나라는 것을 발견함. 처음부터 다시 코드를 짜서 머지에 성공함. 익숙지 않은 기능은 팀프로젝트에서는 자제해야 되는 것과 컨벤션의 중요성을 새삼 느낌.
2. 게시판 기능 중 카테고리 항목을 추가했는데, 구현하는 걸 너무 어렵게 생각해서 팀장님의 도움을 받음. 의외로 entity등에 한두 줄 추가하면 되는 간단한 문제였음.
3. 자바파일들을 세세하게 나눠 코드를 작성해서 중복되거나 불필요한 부분이 많았는데, 삭제하거나 덜어내는 과정을 통해서 가독성 좋고 간결한 코드의 중요성을 새삼 느낌.

Keep	강의에서 배운 방식 외에 새롭게 배운 방식으로 코딩을 하는 도전정신과 끈기를 가지고 수정하는 노력은 유지할 부분이라 생각합니다. merge할 때 오류가 나지 않도록 각자 local에서 branch를 만들어 코딩을 하고 최종적으로 개발 브랜치에 합치는 방식이 바람직했다고 봅니다. 특히 git에서 충돌이 나지 않도록 단계적으로 merge하고, 큰 충돌이 발생한 경우는 다시 백업자료로 돌아가 처음부터 시작하는 등 오류를 수정하는 전반적인 피드백 과정에서 배울 점이 많았습니다.
Problem	처음 SA에서 정한 부분들을 제대로 숙지하고 코딩했어야 했는데, 막상 제가 코딩할 때는 놓친 부분이 많아 미흡했습니다. 또한 호기롭게 이전 팀에서 배웠던 Mapper를 쓰다가 연쇄적으로 충돌이 발생해 수정에 이틀 가까이 소요됐으나, 결국 해결하지 못하고 전체적으로 재코딩을 하게 됐습니다. 결과적으로 프로젝트를 지연시키게 되어 죄송한 마음이 컸습니다. 연쇄적으로 컨벤션 문제와도 이어졌는데, 제 방식에만 익숙해있다 보니 어려워서 방식을 통일하는데 많은 도움이 필요했습니다.
Try	SA를 짤 때 팀의 컨벤션 및 제가 맡은 부분을 확실하게 구체화하고, 아예 개인코딩 시작시 SA를 옆에 띄워놓고 제 코딩이 컨벤션과 목적에 부합하는지 실시간 체크를 해야겠습니다. 익숙하지 않은 기능을 사용할 시에는 반드시 팀원들이 그 기능에 대해 알고 있는지 확인한 후 팀원의 동의를 미리 구하고, 혹 전체 프로젝트에 지장이 갈 것 같으면 과감히 빼야겠습니다. 새 기능에 능숙해지기 전까지는 기존의 방식을 고수해야겠습니다. 제 부족함으로 인해 프로젝트가 지연되지 않도록, 부족한 결과가 나오더라도 먼저 시간을 맞추고 팀원들의 도움을 얻는 식의 프로젝트 진행이 되도록 노력해야겠습니다.

 

 

전성준

1. 테스트 코드를 작성하며 객체의 값을 검증하기 위해 if문을 사용해야 하나 고민하다가 지난 팀의 팀장님이 사용하신 assertThat이 생각나서 assertThat을 사용하였는데 다른 기능들과 달리 자동으로 import가 되지 않아 많이 애먹었다. 수동으로 임포트 작성해 주니 간단하게 해결되었다.
2.  mysql 다운로드를 해결하지 못하고 현재까지 mariaDB를 사용하고 있었는데 이번에 유섭 님이 mariaDB도 삭제 후 진행해 보는 게 어떻냐고 말씀해 주셔서 진행하였더니 해결이 되었다.

Keep	무리하게 많은 기능을 구현하지 않고 복습과 추가적인 기능을 더 구현해보는 방식이 탁월한 선택이었다고 생각됩니다.
Problem	git사용에 큰 문제를 느꼈습니다. commit, push, stash 를 하는 동안 코드를 몇번이나 날려먹었고 클론을 수 없이 많이 해왔습니다. 또한 설계단계에서 개인 사정으로 인해 참여하지 못하여 유섭님과 더 자세한 설계를 해야 함에도 그러지 못한 것에 굉장히 죄송스러운 마음입니다.
Try	개인사정이 생겨 자세한 설계를 하지 못하였을 때 다른 시간이라도 먼저 대화하는 시간을 가져야겠다고 느꼈습니다. git관련 TIL을 작성하여 git 숙련도를 높여야겠습니다.

 

 

신유섭

기존 세션 방식과는 다르게, jwt토큰을 사용하여 로그아웃을 구현할 때 서버가 발급된 토큰을 인위적으로 만료할 수 없어 애로사항이 있었습니다.

제가 택한 방식은 새로운 MySQL DB를 만들어 Refresh 토큰을 서버가 저장하고, Access토큰의 제한시간을 짧게 설계하였습니다.

이렇게 설계하면 jwt토큰의 장점인 무상태성을 어느 정도 포기하게 되지만, Access토큰이 해커에 의해 탈취되더라도 아주 적은 시간밖에 사용할 수 없어 보안이 강화되는 효과를 기대할 수 있습니다.

 

개선점은 DB를 MySQL을 사용하는 것이 아닌 Redis를 사용하는 것입니다.

Redis는 메모리에서 데이터를 처리하기 때문에 속도가 빠르고,

Refresh 토큰만 저장하면 되기 때문에 Key Value형태의 Redis가 관계형 데이터베이스 MySQL보다 효율적일 것으로 예상됩니다.

 

Keep	새롭게 배운내용을 적용하고 익숙치 않은 방법에 대해 두려워하지 않는 마인드는 계속 이어나가야겠습니다. 팀원들과 편안한 분위기를 조성하기위해 지금까지와 같이 앞으로도 따뜻한 말투로 대화를 해나가도록 하겠습니다.
Problem	필수 구현에 맞춰서 배우지 않은 방법을 구현해야할 때 시간이 많이 소요됐습니다. 팀원들에게 먼젖 조언을 구하고 같이 해결하는 방식을 취하는데 어려움을 가졌습니다.
Try	테스트 코드를 작성해서 제가 만든 웹서버의 안정성을 테스트 해보고 싶습니다. 웹서버를 구축하면서 생기는 예외들의 상태코드들에 대한 고찰도 다시한번 생각해봐야겠습니다.