최종 회고

회고 방식

• 4Ls 회고

Front-End

Liked

이번 프로젝트에서 좋았던 점

Jini

• 프로젝트에 Next.js, recoil, 타입스크립트를 사용했는데 도입한 기술을 실제로 사용해보며 왜 사용을 하는지에 대해 이전보다 더 이해를 할 수 있어서 좋았습니다.

• 인원이 적어 완성하기까지에 시간이 빠듯했지만 팀원들끼리 함께 완성을 하게 되었고, 의미있는 시간이었던 것 같습니다.

• 구현을 하고 사용을 해보며 부족한 부분을 많이 알게 되었고 어떤게 더 서비스 측면에서 더 나을 지 많은 생각해볼 수 있었습니다. 리팩토링을 하며 개선을 시켜볼 수 있을 것 같습니다.

• 기능 구현을 하며 발생한 문제들에 대해서 공유를 하고 서로 생각해보는 과정에서 담당 작업이 아님에도 해당 기능에 대한 간접적인 경험을 할 수 있어서 좋았습니다.

Grew

• 프론트 팀원이 3명으로 다른 팀에 비해 적은 편이었습니다. 힘들었지만 오히려 그만큼 많은 부분을 경험할 수 있었다는 것.

• 이전에 사용해보지 않았던 타입스크립트나 NextJS, 또 vercel을 이용한 배포까지 해볼 수 있었다는 것.

• 좋은 팀원들을 만나서 협업할 수 있었다는 것.

Joe

• 팀원들 모두 경험이 없던 업무를 자처해서 맡아 서로 공부하면서 성장할 수 있는 시간을 많이 가졌다고 생각합니다.

• 지도 API를 연동하면서 생각했던 것 이상으로 많이 제공되는 API의 기능들을 알 수 있었고 추후 지도 API에 관련된 프로젝트를 또 하게 된다면 좋은 퍼포먼스를 낼 수 있을거 같습니다.

• 팀원이 적은만큼 밤낮없이 모두들 열정을 가지고 개발해주셔서 지치지 않고 달려올 수 있었습니다.

Learned

이번 프로젝트에서 배웠던 점

Jini

• 기능작업을 완료하고 테스트를 좀 더 꼼꼼하게 해야한다는 것을 배웠습니다.

• typescript, next, recoil을 프로젝트에 처음 적용하다보니 새로 만나는 에러를 만나며 해결하는 과정에서 많이 배웠던 것 같습니다.

Grew

• 일정계획은 최대한 보수적으로 짜고, 꼼꼼하고 치밀하게 준비를 해야했다는 것.. 나의 능력은 생각하는 것보다 뛰어나지 않다, 언제나 예상치 못한 이슈는 발생한다.

• 이슈나 혼자 해결하기 힘든 문제사항이 발생한다면 너무 오래 붙잡지 말고 다른 팀원들과 공유해야한다. 처음 혼자 해결하려는 자세는 좋지만 너무 오래걸리면 일정에 차질이 생겨버림… 또 팀원들의 능력은 나보다 뛰어나다.

• 새로운 기술을 적용한다는 것은 무조건 러닝커브가 발생한다. 그것이 작던 크던 프로젝트에 영향을 미칠 수 있다..

Joe

• 간단하다고 생각했던 기능 구현이 생각보다 지체될때 팀원들과의 공유를 통해 쉽게 해결할 수 있는 경험을 했습니다. 개발이 막힐 경우 어떤식으로 막히는지 서로 공유하는 시간이 중요하다는 점을 배웠습니다.

Lacked

이번 프로젝트에서 아쉬웠던 점

Jini

• 제출 마지막에 이슈가 발견되어서 이전에 미리 꼼꼼하게 체크하지 못했던 것이 아쉬웠습니다.

• 작업을 하면서 사용자에게 불편할것 같다고 느꼈던 기능이 있었는데 일정이 급하다보니 수정할 시간이 없어서 그대로 진행하게 되었습니다. 리팩토링 때 개선해 볼 예정입니다.

• 경험이 부족한지라 문제 해결을 위해 시도한 방법이 괜찮은 방법인지 확신이 없는것 같아 고민을 많이 했었고 부족함을 많이 느꼈습니다.

Grew

• 타입스크립트나 NextJS 등 새로운 기술을 적용한 것은 좋았지만 높은 이해도로 사용하지 못했다.

• 이전보다 리액트의 이해도는 높아진 것 같지만 아직도 부족하다는 것을 많이 느꼈다.

Joe

• 배웠던 점에도 적었지만 개발이 막힐때 혼자서 고민하는 시간을 너무 많이 가졌습니다. 이로 인해 개발 일정이 지체되었고 늦게나마 이슈를 공유하고 해결하였는데 추후에는 어느 시점에 지연되는 부분을 공유해야되는지 잘 판단하자는 교훈을 얻었습니다.

Longed for

다음 프로젝트에서 바라는 점

Jini

• 계획한 일정이 미루어진다면 미리 피드백을 하거나 공유를 해서 마감 일정에 차질이 없으면 좋을 것 같습니다.

• 급하게 마지막에 마무리 하지않고 계획을 잘 세워서 완성시키고 이슈가 생길 것을 대비하여 더 꼼꼼하게 체크 해야할 것 같습니다.

Grew

• 다음 프로젝트에서는 지금까지 사용한 기술을 더 잘 이해하고, 고도화 시켜서 사용할 수 있도록 할 것임.

• 계획을 더 보수적이고, 꼼꼼하게 짜야겠다.

Joe

• 언제나 프로젝트 막바지에는 일정이 촉박했는데 다음 프로젝트를 할때 막바지에는 여유를 가질 수 있었으면 좋겠습니다.

Back-End

Liked

이번 프로젝트에서 좋았던 점

Charlie

• 프론트팀과 함께해서 내가 짠 코드를 가시적으로 볼 수 있었다는 점이 가장 좋았습니다.

Frank

• 프론트엔드와의 작업이 생소했지만 즐거웠습니다. 결과물도 멋있게 나온거 같아 좋았습니다.

Kate

• 항상 프로젝트를 진행할 때 퍼블리싱을 도맡아서 하느라 정작 하고 싶은 백엔드 쪽을 많이 못했었다. 이번에 프론트 팀과 함께 하게 되어 내가 하고 싶은 부분에 몰입 할 수 있는 것이 좋았다.

• 백엔드 팀의 인원이 많아서 개발 부분에서는 일정적으로 부족하지 않았다. (여유는 아니고 적당?)

Kevin

• 프론트팀과 함께 프로젝트를 할 수 있었던 좋은 경험을 해서 좋았습니다. 또, 결과물도 완성되어서 더욱 기분이 좋습니다.

• 어려운일이 생기면 서로 도움을 주면서 함께 해결했던 점이 좋았습니다.

Kid

• 프론트 팀원들과 함께 작업할 수 있는 기회여서 감사했고 우리 백엔드 팀원들도 다 좋은 사람들을 만나서 프로젝트 기간 내내 즐거웠고 좋았습니다.

Learned

이번 프로젝트에서 배웠던 점

Charlie

• JPA fetch join.. 보니까 주 TABLE에서는 where을 써도 상관없지만 fetch join 시킨 TABLE에 where을 써서 필터링을 사용하면 객체의 상태와 DB의 상태 일관성이 깨진다고 하네요? 이번에 제대로 깨트려서 배운 것 같습니다.

fetch join 시 별칭관련 질문입니다 - 인프런 | 질문 & 답변

안녕하세요 영한님 기다리던 2편도 어제부터 너무 즐겁게 보고 있습니다 항상 좋은 강의 감사드립니다 테스트 코드 작성 중 2가지 질문이 있어 질문 드립니다 기본편 패치조인 한계편 초반에 보면 fetch join 시 별칭을 줄 수 없다고 되어 있습니다 그 이유는 별칭을 준 이...

https://www.inflearn.com/questions/15876

• Comparable 인터페이스를 사용해서 sort시킬 수 있다는 것.

• 연관관계가 없는 테이블끼리 Join시키기는 매우 어렵다는 점(Cross Join이 되서…). 나중에라도 Join될 가능성이 보이는 것은 테이블 설계 단계에서 잘해야겠다는 생각이 들었음.

• JPA에 의존하지 않고 Slice를 만들어 봤던 것. 만들면서 관련된 공부를 할 수 있어서 좋았습니다.

• QueryDsl 관련 - QClass를 새로 생성해서 JPAExpressions 안에서 사용하면, 2중 select가 가능해져서 여러가지 데이터를 뽑아올 수 있다는 점. 특히 Count 조회 관련해서 fetchCount가 deprecated되어서 Wildcard.count를 썻어야했는데 이 경우는 그렇지 않아서 좋았습니다.

Frank

• Fetch Join한 테이블은 on, where을 쓰면 안된다는 점 배웠습니다.

• 정렬 조건을 커스텀해볼 수 있었습니다.

Kate

• SSL 인증서 발급 받는 방법 까마득히 잊고 있었는데 기억이 났다.

• 예전에는 돈 아끼려고 Nginx 썼는데 AWS 의 로드 밸런서를 사용하고 SSL 인증서 적용까지 해볼 수 있었다. 역시 돈이 최고라는 것을 깨달았다.

• JIRA에서 이벤트 설정하는 법을 찾았다. 이제 지라를 관리하는데 익숙해졌다.

Kevin

• Jenkins와 codeDeploy를 이용해 자동 빌드 배포 환경 만들기
Jenkins + CodeDeploy를 사용하여 자동배포 구현하기
기존에 Travis를 사용하여 CI를 구축했었습니다. 하지만 무료 크레딧이 끝나버려서 이번 기회에 구인 공고에서도 많이 보이는 Jenkins와 AWS CodeDeploy를 사용하여 자동배포를 구현해보도록 하겠습니다. 위의 아키텍쳐로 진행하기 위해서 Jenkins를 돌릴 EC2 서버를 하나 더 생성하여 진행하겠습니다. 두개의 EC2 인스턴스를 사용하기 때문에, 구별하기 쉽도록 '젠킨스 서버'와 '스프링 서버'라고 명명하여 구별하겠습니다. 사용자가 GitHub에 Push.

https://velog.io/@bluewind8791/jenkins-with-docker-ci

• JIRA 사용하는 방법 (스프린트, 티켓 , etc,,,)
Products | Atlassian
Software development and collaboration tools for teams, from startup to enterprise. Try Jira Software, Jira Service Management, JWM, and Confluence.

https://www.atlassian.com/software

Kid

• Spring Security에서 로그인 처리 및 JWT 토큰 발급을 이용해 회원 가입을 처리 했던 경험이 좋았습니다.

• 이렇게 규모가 큰 프로젝트를 모두와 함께하면서 코드 스타일, 처리 방식, 이슈 처리 방법 등 여러가지를 보고 배웠습니다.

• Jira 사용 및 스크럼과 회고하는 협업 방식을 배웠습니다.

Lacked

이번 프로젝트에서 아쉬웠던 점

Charlie

• 경험 부족으로 왜 경력있는 개발자를 원하는지, 가치가 높은지 알게되었습니다. 내 역량을 알아야 프로젝트 초기 수립 단계에서 더 효율적으로 계획을 잡았을 텐데 라는 생각이 들었습니다.

• 다른 팀의 코드를 몰래몰래 훔쳐볼껄.. 이라는 생각이 들었습니다. 옆팀꺼는 또 다른 스타일의 코드라 보고 배울 점이 많다는 생각이 들었습니다.

Frank

• 생각했던대로 코드가 동작하지 않아 시간이 오래 걸린 점이 아쉬웠습니다.

• 한 메서드에서 쿼리가 몇 개 나가는지 측정하는 AOP를 만들고 싶었으나 잘 안된게 아쉽습니다.

Kate

• 프로제트 진행에 대해서 계획을 잘 세웠다고 생각했는데, 예기치 않은 문제가 많이 발생하였다. 프로젝트 버퍼 타임을 확보하고 계획을 수립했어야 했다.

• 변수명을 오해의 소지가 있게 지정한 게 나중에 코드 분석을 어렵게 만들었다. 변수명은 짧은 것보다 충분한 설명이 들어가도록 정의하자.

• 많은 로직이 구현되어 있는 핵심 메소드에 대하여 성능 측정 및 개선해보기

Kevin

• 생각보다 새로운 기술을 적용하는데 애를 많이 먹어서 아쉬웠습니다.

• 메인 기능에 대해 직접 코드를 짤 일이 거의 없어서 아쉬웠습니다.

Kid

• 맡겨진 작업을 계획했던 것보다 빠르게 해결하지 못해서 아쉬웠습니다

Longed for

다음 프로젝트에서 바라는 점

Charlie

• Spring Security에 대해 직접 해보기

• JPA 성능 향상

• 더 좋은 코드로 리펙토링

Frank

• DDD 기반의 폴더 구조 적용해보기

• 무중단 배포 공부해보기

• 쿼리 최적화 하기

Kate

• Jenkins를 통한 CI/CD 해보기 (지금까지 Github Actions만 했었다.)

• QueryDSL 공부하기

• 범석님께 네임카드 전달하기

Kevin

• 내가 공부하고 사용해 볼 내용
• SSL 인증서 발급 후 적용해보기
• 로드 밸런싱(Nginx 나 AWS 사용해보기)
• GitHub Actions으로 CI/CD 해보기
• QueryDSL 과 JPA 를 좀 더 공부해보기
• Spring Security… (OAuth2) 제대로 써보기
• + (필터, 인터셉터)
• 성능 측정 해보기(디비 쿼리, 인덱스 처리 등을 통해)

Kid

• AWS EC2와 RDS를 직접 연동해서 개인 프로젝트에서 사용해보기

• github README 정리를 깔끔하게 만들어보기

• QueryDsl 공부 및 사용해보기