🎆 4L: Liked / Learned / Lacked / Longed for💕 Liked: 좋았던 점민성훈기현정한빈민재📘 Learned: 배웠던 점민성훈기현정한빈민재⚠️ Lacked: 부족했던 점민성훈기현정한빈민재🔎 Longed for: 바라는 점민성훈기현정한빈민재📋 주제 별 회고 정리🗣️ 업무 분배 및 책임🗒️ 코드 리뷰📜 문서화⏩ 업무 프로세스와 협업 툴☠️ 트러블 슈팅 & 테스트🏭 Github🔯 육각형 아키텍쳐(Hexagonal Architecture)🚅 프론트엔드의 부재🏠 프로젝트 주제💊 개인 컨디션 관리
🎆 4L: Liked / Learned / Lacked / Longed for
Liked: 이번 프로젝트(스프린트)에서 팀원들과 함께 작업하며 좋았던 점
Learned: 이번 프로젝트(스프린트)에서 팀원들과 함께 작업하며 배운 점
Lacked: 이번 프로젝트(스프린트)에서 팀원들과 함께 작업하며 아쉬웠던 점
Longed for: 이번 프로젝트(스프린트)에서 팀원들과 함께 작업할 때 “이랬으면 참 좋았겠다.” 싶은 점
💕 Liked: 좋았던 점
민성
- 중간에 작업 진행이 뜻대로 되지 않을 때, 팀원들이 꾸준하게 프로젝트에 기여하는 모습을 보면서 힘을 얻어 할당된 일들을 수행할 수 있었습니다.
- 제가 마친 작업들을 협업 툴을 통해 가시화할 수 있어서, 작업 진행에 동기 부여가 됐습니다. 특히 작업들을 짧은 단위로 나눌 수록 효과가 크게 나타났습니다.
훈기
- 다양한 기술과 툴을 시도하려고 했던 점
- 시간 제약에 맞춰 제출 하려 했던점
- 서로의 코드에 대해 자세한 피드백을 해준 점
- 서로 버그를 발견하면 최선을 다해 찾아주려 한 점
- 충돌을 잘 해결한 점
- 문서정리가 잘 되어 있던점(기록이 정말 잘 되어 있다. 정리와)
- 팀원들과 협업하며 모르는 부분을 많이 배운 점
현정
깃헙 플로우를 사용하여 협업하는 것을 처음 경험해 보았는데, 컨플릭트도 많이 겪고 오류도 겪었지만 그걸 직접 해결해보는 경험도 할 수 있어서 좋았고 뿌듯했다.
그리고 이번 프로젝트에서는 다른 과제들에서보다 pr을 많이 날리고, 리뷰도 많이 받게 되었었는데, 그러다 보니 나의 부족한 꼼꼼함을 채울 수 있었고, 다른 관점에서의 생각들도 여러 번 들을 수 있어서 좋았다.
또 마지막으로, 여러 명이서 같이 프로젝트를 진행하다 보니 개인으로 프로젝트를 진행할 때보다도 동기부여가 되었고, 다른 사람들에게 피해를 끼치지 않고 싶어 더 열심히 공부할 수 있었다.
한빈
- 함께 작업하면서 발생하는 Github 문제들에 대한 연습이 많이 되었음
- PR → 코드리뷰 → 머지로 이어지는 과정에서 배울 수 있는 것들이 많았음
- 공통 모듈 프로그래밍에 대한 경험
- 다른 팀원들로부터 배울 기회가 많았음
- 트러블 슈팅, 코드 리뷰, 기술적인 도움
- 다른 팀원들의 관점에서 인사이트를 얻기도 하며
- 내가 막혔던 부분들에 대해서 도움을 받기도 함
민재
- 같은 목표를 정하고 목표를 이루기 위해 다 같이 노력하는 부분이 좋았습니다.
- 다들 코딩에 대한 열정이 대단하여 같이 작업하며 학습에 대한 동기부여가 되었습니다.
- 특히 혼자서는 겪을 수 없는 다양한 문제들을 미리 겪고 해결책을 찾는 과정을 경험해볼 수 있어서 좋았습니다.
📘 Learned: 배웠던 점
민성
- 비록 직접 환경을 구성하지는 않았으나, 협업 환경에서 어떤 흐름으로 작업이 진행되는 지 (플래닝 포커, 태스크 할당 등) 경험해서 좋았습니다. 나중에 직접 협업 환경을 준비할 때 시행착오를 줄일 수 있을 것 같습니다.
- 육각형 아키텍처를 고민하고 적용해보는 경험을 할 수 있었습니다.
- JpaRepository 상속 인터페이스를 어댑터로 판단해서 인프라 계층에 두었습니다. 비즈니스 계층에서는 인프라에 접근할 수 있는 repository 포트만 따로 두어서 비즈니스 계층에서 repository가 어떤 기술로 구현되었는지 알 필요가 없도록 구현했습니다.
- 서비스 계층에 스프링 프레임워크에 종속된 코드를 어느 정도까지 허용해야 하는지 팀원들과 고민해보는 시간을 가졌습니다.
- 예를 들어, 비즈니스 계층에서 SecurityContext(Spring Security), MultipartFile(Spring Web MVC)와 같은 클래스를 직접적으로 의존하는 것이 맞는지 이야기하고, 해결책을 탐색하는 시간을 가졌습니다.
- 클래스를 작성할 때 마다 해당 클래스가 어떤 계층에 속하는지 검토해보는 습관이 생겼습니다.
- Git 활용 능력을 키울 수 있었습니다.
- PR 올리기 전, merge 전 main 브랜치를 pull 해서 코드 작동 유무 확인
- 다른 브랜치로 체크아웃 해서 다른 팀원 작업 내용 검토 정상 작동 확인
훈기
- QueryDsl과 페이징, 슬라이스를 배운점
- git, jira 등 다양한 협업툴을 경험하고 익힌점
- 애자일을 경험한 점
- 기존의 Layered Architecture가 아닌 헥사고날 아키텍쳐를 적용해 DIP에 대해 좀 더 자세히 배운점
- 처음으로 코드를 깃으로 협업해 충돌 해결하는 방법 등을 배운점
- 빌더패턴을 어노테이션 없이 구현해본점
- 연관관계에 대해 좀 더 자세하게 생각하고 적용해본 점
- Spring Rest Docs와 Mock에 대해 알아간 점
현정
이번 프로젝트에서 나에게 생소했던 헥사고날 아키텍처를 적용하였는데,
처음에는 솔직히 걱정이 많았지만, 팀원끼리 아키텍처에 대하여 이야기를 나누고, 조언도 주고받고 도움을 받으면서 많이 배우게 된 것 같다. (pageable)
또 이번에 사용자 인증 관련 구현을 담당하게 되었는데, 덕분에 부족했지만 공부를 미뤄놓았던 시큐리티에 대한 지식을 채워볼 수 있었고, 구현하기까지의 공부를 통하여 이전에는 대강 넘어갔었던 부분들도 제대로 이해하고 배울 수 있는 기회가 되어서 좋았다.
한빈
- 헥사고날 아키텍처
- JPA EntityListener
- 기획 / 협업 툴 이용한 전체적인 프로세스 학습
- 제네릭을 이용한 공통 부분 프로그래밍
- 코드 리뷰를 통해 얻은 다른 사람 코드에 대한 독해력
민재
⚠️ Lacked: 부족했던 점
민성
업무를 구체적으로 계획하고 진행하지 않았습니다.
- 제가 맡은 스토리에 대한 업무를 엔티티 설계 → 서비스 작성 → 컨트롤러 작성 → API 명세 작성으로 나누었습니다.
- 엔티티 검증 방식 구현, 하위 엔티티 구현, 서비스에서 발생할 수 있는 예상 예외 작성하기 등 각 단계 내부에 많은 일들이 존재하지만 추상적으로 설계를 해버렸기 때문에 다른 업무를 하다 돌아왔을 때 내가 어떤 작업을 하고 있는지 쉽게 파악하지 못할 때가 많았습니다.
- 다른 팀원들이 보드를 통해 나의 업무 현황을 보더라도 내가 어떤 작업을 어려움을 겪고 있는지 쉽게 파악할 수 없었습니다.
- 작업 시간 예측 / 활용 실패
주어진 작업들이 예상보다 어려웠습니다.
- QueryDSL, JPA 연관 관계, Multipart 활용하기, 사용자 정보 가져오기…
- 하루에 온전히 과제에 집중할 수 있는 시간이 적었습니다. 더운 날씨, 작업을 강제하기 어려운 비대면 환경, 예상치 못한 사적인 일 등 여러 원인이 있었습니다. 설상가상으로 스토리들을 일 단위로 계획했기 때문에 괴리감이 더 커졌습니다.
- 주변 환경이 업무에 방해가 된다고 인식했음에도, 이를 적극적으로 해결하러 나서지 않았던 것도 치명적이었습니다. 운이 좋게도 오프라인 교육장에서 팀원들과 작업해서 최악의 상황은 피했으나, 스스로의 의지력을 과대평가해서 무의미하게 보낸 시간이 많았습니다.
이미 검증이 끝난 컴포넌트들을 컨트롤러 테스트에서 대역 없이 사용했습니다.
- 컨트롤러 기능 검증과 거리가 먼 코드를 작성(컴포넌트 실행에 필요한 테스트 픽스처 설정 등 )해서 테스트 코드의 가독성을 해쳤습니다.
- 컴포넌트 관련 작업(준비 - 실행 - 정리) 때문에 테스트 실행 시간이 늘어났습니다. 특히 이미지 등록 관련 API를 테스트에서 서비스를 대역으로 처리한 팀원과 평균적으로
100ms정도 시간 차이가 났습니다.
문서화 기피
- 논의 사항, 새로운 기술, 멘토님 질문 사항 등 팀 페이지에서 정리한 후에 전달할 내용들을 스크럼에서 머리에서 떠오르는 대로 이야기하고 넘어 가버렸습니다.
- 제가 문서화를 하지 않았기 때문에 팀원들은
- 제가 구두로 전달한 정보를 다시 확인해야 했습니다.
- 노트북 내장 마이크 + 게더 타운
- 스크럼의 핵심 주제와 관련 없는 이야기로 시간을 버렸습니다.
- 최우선으로 해결해야 할 문제 같습니다.
- 의지력만으로 해결될 문제는 아닌 것 같습니다.
팀원 코드 리뷰
- 저에게 할당된 일들을 하지 못했기 때문에 코드 리뷰에 집중을 못했습니다.
- 저의 리뷰가 잘못 되었을 경우 팀의 시간을 낭비하는 것이라 생각해서 의문 사항을 리뷰에 다 반영하지 못했습니다.
- PR 단위가 클 경우 읽어야 할 코드가 너무 길어서 집중력이 떨어집니다.
- 저만 그럴 경우에는 내가 따로 코드 읽는 훈련을 해야 할 것 같습니다.
훈기
- 계층에 결국 의존성이 생긴점(어쩔수 없긴 했다.)
- 초반에 설계와 컨벤션에 많은 시간을 썻지만 그만큼 많이 진척하지 못한점
- 프론트엔드가 없어 많은 기능에 제약이 생긴 점
- 너무 범위를 넓게 잡아 테스트코드나 좀 더 디테일하게 구현하지 못한 점
- 처음 작업 분량을 잘못잡은점
- 커밋 단위가 너무 크고 데이터에 관해 신경쓰지 못해 테스트가 잔여 데이터쪽으로 자주 망가졌던점
- 실제로 테스트해볼 프론트화면이 없었던 점
- 스크럼 시간이 하루하루 생각보다 길었던점, 나중엔 짧아져서 괜찮았다.
- 오프라인에서 자주 하지 못한점
- 실제 배포까지 해보지 못한 점 (자동화 포함)
- 컨트롤러 목처리
현정
여러 테스트가 쌓이고 쌓이다 보니 이 테스트들을 관리하는 게 힘들었던 것 같다..
테스트 데이터에 대한 관리가 제대로 안되어서(내가 트랜잭션 롤백을 시키지 않아서..) 테스트 충돌이 일어났던 이슈가 있었는데, 좀 더 꼼꼼하게 작성했었으면 시간을 아낄 수 있었을 텐데!!! 하는 생각을 했다.
이번에 querydsl을 처음 사용하게 되었는데,(팔로잉 피드) 자세히 공부하지 못한 상태에서 쿼리를 작성해서인지 아쉬웠다.. 좀더 공부해보고 싶다
또 다섯 명이서 프로젝트를 진행하는 것은 처음이다보니, 의견을 모으는 데도 시간이 많이 소요되는 것 같아 아쉬웠다. 결론을 모으고 결정하는 더 호율적인 방식이 있었으면 시간을 보다 단축할 수 있지 않았을까? 하는 생각이 들었다.
코드 리뷰를 많이 못한 것. 코드를 읽는 속도가 빠르지 않는데 이번 프로젝트에서 각잡고 다른 사람 부분을 읽은 게 몇 되지 않은것 같아 아쉬웠음..
한빈
- 프로젝트 진행에서 특정 안건 등에 대한 맺고 끊는 부분에 대해서 부족했음
- 이슈 해결 과정에서 지지부진해지고, 작업 시간 분배 실패가 좀 있었음
- 테스트 방식에 대해 고민이 많이 생겼음
- 실행 속도를 떨어뜨리는
@SpringBootTest - 어디까지 통합 테스트의 영역으로 볼 것인지?
@BeforeEach등이 테스트에서 미치는 영향 등
민재
유독 이번 프로젝트 기간에 개인 사정이 너무 많이 생겨 프로젝트에 시간 투자를 많이 못하여 너무 죄송하고 아쉬웠습니다. 다음 프로젝트에는 더 많은 시간을 부어 팀 활동에 기여하겠습니다.
다음은 프로젝트를 진행하며 개인적으로 아쉬움이 남았던 부분입니다.
1. 도메인 크기를 더 작게했다면 어땠을까
처음 주제를 정할때 다들 협업 경험이 그리 많지 않았기에 다양한 기능을 가진 도메인 구현보다는 협업에 익숙해지는것을 프로젝트 목표로 정했습니다. 이러한 이유로 오늘의 집 서비스 클론 범위를 나름 작게 설정했다 생각했는데 이것도 생각보다 구현에 많은 시간이 들었습니다. 시간이 부족하다 결국 단순히 각 도메인들의 CRUD를 구현하고 끝났는데, 차라리 범위를 더 작게 구현하고 디테일쪽에 신경을 썼으면 어땟을까라는 생각이 들었습니다.
2. 너무 큰 PR 단위
기능을 개발하고 PR을 날리면서 겪었던 문제는 다음과 같습니다.
- 담당한 기능 완성
- PR 요청 전 main 브랜치 pull
- conflict 발생, 혹은 test 실패
- 문제 해결 후 커밋
- main에 새로운 pr merge 확인, 2번부터 반복
위의 절차를 반복하다 보니 하나의 PR의 크기가 점점 커지게되고 문제가 발생할 경우 어디서 문제가 발생했는지 추적이 힘들었던거 같습니다. 아마 이 부분도 CI 환경을 구축하면 어느정도 해결될 것이라 생각합니다.
3. 이슈 공유
이번에 프로젝트를 진행하면서 공통적으로 발생한 이슈들이 있었습니다. 다른분들은 해당 이슈에 대해 해결책을 잘 문서화 하여 공유하였지만 저는 그러지 못했던거같습니다. slack에서 다른분이 해당 이슈에 대하여 물어보셨을때야 부랴부랴 답변을 드렸는데, 진작에 제가 이슈 문서란에 정리를 해뒀으면 팀원분들이 시간을 아끼셨을텐데 참 후회되었습니다.
🔎 Longed for: 바라는 점
민성
훈기
- 처음에 너무 쉽게 생각해서 분량을 크게 잡았는데 좀 더 줄여서 테스트코드나 구현 코드에 좀 더 디테일하게 했으면 좋았을 것 같다.
- 위에서 말한대로 좀 더 완성도 있는 코드를 만들었으면 좋았을 것 같다.
- 지금도 컨벤션을 잘 맞췄지만 이번에 하면서 좀 더 디테일하게 맞춰야 겠다는 생각이 들었다.
- 버퍼를 넉넉하게 했었으면 좋았겠다.
현정
개인적으로 온라인을 기반으로 한 협업을 진행하다 보니 답답한 점이 조금 있었다.. 오프라인으로 볼 수 있었다면 더 좋았을 것 같다.
글로는 모든 걸 설명하기 어렵고, 문제가 생긴 부분을 직접 보여주면서 이야기하는게 아직은 내게 더 편하다고 생각하는데, 온라인에선 이 작업이 쉽지 않았다.
한빈
- 리뷰 / 컨벤션 준수에 있어서 조금 더 힘을 기울였으면 코드 일관성이 지켜졌을 것 같음
- 주제
- 인원 수만큼의 파트 분배가 가능해서 머지 충돌을 줄일 수 있었음
- 하지만 동일한 CRUD 작업의 반복이라는 점이 한계였다고 느낌
- 오히려 컨벤션이 안 지켜졌다는 점이 더 드러난 포인트였음
- 좀 더 기술적 도전이 있었다면 괜찮지 않았을까 싶기도
- 온라인 비동기 협업으로 인한 한계가 아쉬웠음
- 기록과 정리에 있어서 더 많은 집중이 필요하지 않았나 싶음
민재
1. CI 도구 도입
아무래도 다들 팀 프로젝트의 경험이 적다 보니 코드를 합칠때 발생한 문제를 해결하는데 시간이 많이 들었던거 같습니다. 특히 각자 맡은 기능에 대해 테스트 코드를 작성했지만, 로컬 환경에서 테스트를 실행하다보니 팀원들의 로컬 환경에 따라 테스트 결과가 달라지는 현상이 생각보다 빈번하게 일어났습니다. 다음 프로젝트에는 CI 환경을 구축하여 이러한 문제를 예방하면 좋을것같습니다!
2. 외부 라이브러리 의존도 결정
이번 저희 프로젝트의 가장 큰 특징은 헥사고날 아키텍쳐를 적용해 외부 기술과 도메인 영역을 분리하는것이었습니다. 처음에는 패기롭게 모든 외부 의존성을 포트로 분리해 도메인 영역을 순수하게 유지시키려했지만, 그러다 보니 결국 Jpa나 스프링 프레임워크에서 지원해주는 기능들을 직접 구현해줘야하는 상황이 되었습니다(사실 기술적인 능력이 부족하여 생긴 일이라 생각합니다). 도메인 영역과 외부 기술을 분리하는건 분명 객체지향적으로 좋지만 효율성을 위해 프레임워크에 대한 어느정도의 의존성은 가지고 가는게 오히려 더 좋을것 같다는 생각이 들었습니다. 다음 프로젝트에는 사용될 기술들에 대해 미리 팀원들과 상의하여 어디까지 의존할지 결정하면 좋을것 같다는 생각이 들었습니다.
3. 테스트 데이터 관리
이번 프로젝트에서는 테스트 데이터를 각 테스트에서 java 코드를 이용해 관리했었습니다. 하지만 이런식으로 데이터를 관리하다 보니, 각 테스트가 서로에게 영향을 끼칠 수 있는 위험이 항상 내제되어있었고 실제로도 관련 이슈가 발생했었습니다. 다음 프로젝트에 대비해 테스트 데이터 관리 방법을 조사하면 좋을것같습니다
📋 주제 별 회고 정리
🗣️ 업무 분배 및 책임
관리자 역할혹은 거기에 상응하는 프로세스가 필요했음- 부재로 인해,
- 논의가 지지부진해지거나, 회의 시간이 지나치게 길어지기도 하고
- 프로젝트에 필요한 과제나 팀 내 컨벤션 준수에 대한 강제성이 약함
- 특히 책임 할당의 경우
- 누군가에게 강하게
“~하세요”형태의 책임을 부여하는 역할이 없었기에 - 강한 책임을 부여하지 못하고 지나쳐 버리는 일들이 많았음
🗒️ 코드 리뷰
- 코드 리뷰 자체에 대해서는
긍정적인 의견이 많았음 - 팀원들의 리뷰로부터 새로운 관점, 스스로 챙기지 못했던 부분을 살필 수 있었으며
- 다른 팀원들의 코드를 살펴보면서 배우는 것들이 많았음
- 코드 리뷰를 지속하기 위해서
개선할 사항들도 많았는데, - 다른 사람이 읽기 좋은 코드를 짜려고 노력해야 함
- 다른 사람의 코드를 읽는 능력을 길러야 함
PR 단위를 작게만들 필요가 있음!- PR 단위가 커지면서 코드리뷰 자체가 부담이 됨
- 리뷰를 읽으면서 여러 번의 맥락(context) 전환이 강제되었음
- PR을 쪼개는 단위에 대해 고민이 필요함!
- 리뷰에 있어서 조금
더 과감해질 필요가 있음! - 듣는 사람을 배려하는 자세는 중요하지만,
- 그것 때문에 피드백 자체에 소극적으로 된다면 문제임
📜 문서화
문서화의 중요성을 느낀 분들이 많았음
- 동시에 문서화를
더 철저히 해야 한다는 필요성도 제기됨 - 어떤 문제건 간에, 문서화를 미루지 말고 제 때 해야겠음
- 팀 내 공유된 문서를 확인하는 버릇도 중요
⏩ 업무 프로세스와 협업 툴
- 함께 하는 작업이기에
서로 자극 받을 수 있었다는 의견이 많았음 - 특히 칸반 보드 / Github 알림 등으로 인해 팀원들의 작업을 체감하면서 자극받을 수 있었음
협업 툴(Jira 등) 활용이 미비한 부분이 있었음- 다음 프로젝트에서는 협업 툴과 프로젝트의 연동을 어떻게 높일 수 있을지 고민해봐야겠음
- 업무 단위 / 업무 예상 시간 계획의 중요성
- 잘 쪼갠 업무 단위는 도움이 되었지만, 많은 부분에서 시간 예측이 실패했고, 업무 단위를 잘 쪼개지 못함
- 중요성은 알게 되었지만, 잘 다루진 못한 부분이기에
개선이 필요
지나치게 큰 계획 기간이 독이 되었음- 너무 큰 계획이 실제 작업 진행하면서 생긴 변동사항, 계획 수정 사항이 반영될 기회를 차단하는 결과를 낳음
- 열심히 컨벤션이나 주제에 대해 계획한 것에 비해 도움이 되지 않았음
- 초기 프로젝트 기획을 좀 더 빠르게 마무리 짓고, 유동적으로 계획을 수정할 필요가 있겠음
- 특히
유저 스토리를 분석하는 초기 과정이 노력에 비해 도움이 되지 않았다고 느낀 사람이 많았음
☠️ 트러블 슈팅 & 테스트
- 테스트가 깨지는 문제가 상당히 많이 발생:
CI & CD필요! - 트러블 슈팅, 코드 리뷰만 하다가 개인 작업을 수행하지 못하게 되는 문제도 발생
- 적절한 Mocking의 필요성
- 모든 테스트를 통합 테스트처럼 구성하다보니 테스트 실행 시간이 지나치게 길어짐
검증이 끝난 컴포넌트들은 적절히 테스트 대역으로 대체할 필요가 있음- 통합 테스트도 필요하지만 거의 모든 테스트를 통합 테스트로 처리한 것은
의존성 처리가 귀찮아서가 아닐 지 고민해봐야겠음
- Spring Security의 경우
@WithMock...방식 테스트 적용에 어려움을 겪었음- 대안으로 사용한 만능 토큰 방식은 기간 제한이 있기에 근본적으로 좀 아쉬움
- Spring Security 테스트 방법에 대해 학습이 필요
테스트 픽스쳐문제- 모조리 자바 코드로 처리하다 보니 문제가 발생
- 공통 테스트 처리를 위해 사용한
TestDataProvider가 편리하기는 했지만 시간이 지날수록 관리가 어려워짐 - SQL문을 이용해서 직접 DB에 테스트 데이터를 넣어주는 방식을 사용할 필요가 있음
🏭 Github
- 모든 팀원들이 이번 프로젝트를 통해 Github에 대해 많이 학습할 수 있었음
Github flow방식에 대한 이해 증가stash,checkout기능을 잘 활용할 수 있게 됨- PR 전에 꼭
main과 충돌이 발생하는 지 체크하는 프로세스 도입이 상당히 도움이 되었음 - 단순 파일 상의 conflict뿐만 아니라
- 합친 이후의 프로젝트가 정상 작동하는가 까지 포함한 개념!
- 종속성 이슈
- MultipartFile, Security Context, Pageable
- DIP에 대한 학습
육각형 아키텍처(Hexagonal Architecture)
🔯 육각형 아키텍쳐(Hexagonal Architecture)
- 해당 아키텍쳐 자체에 대한 학습이 많이 되었다고 공통적으로 응답
MultipartFile,Security Context,Pagable등 여러 기술들과 관련하여 의존성에 대해 생각해 볼 수 있었음
- 어디까지 의존성을 제거할 것인지에 대한 고민이 필요
🚅 프론트엔드의 부재
- 프론트엔드가 없이 진행된 프로젝트라서 기능적 제약이 많았음
- 실제 사용자 환경처럼 통합된 상태에서 테스트해볼 수 없었음
- 프론트 쪽에서 어떻게 통신을 할 것인가에 대한 고민이 적었음
🏠 프로젝트 주제
- 협업하기 편한 주제를 선정해서, 머지 등에서 충돌은 확실히 감소
- 하지만
CRUD 반복 작업 위주였다는 점이 아쉬웠다는 의견이 많음 - 도메인에 대한 애정이 적어서 오히려 테스트 상의 edge case 등, 도메인에 대한 이해를 필요로 하는 부분에서 소홀했던 측면이 있었음
- 다음 프로젝트 때는
CRUD 작업이 좀 더 적고, 기술적 도전을 요하는 주제를 선정하면 좋겠음
💊 개인 컨디션 관리
- 개인적인 사정이 많이 있어서 고생하신 팀원들이 상당히 많으셨음
- 스스로의 작업시간을 너무 크게 평가해서 계획이 어그러지기도 함
- 일이 잘 안 될 때 어떻게 해결할 것인지를 고민할 필요가 있음
- 오프라인으로 모여서 작업한 것(교육장)이 상당히 도움이 되었던 사람들도 많음
- 공통적으로 모든 팀원들이, 여러 악재가 겹쳤음에도 묵묵히 잘 해주시고, 도와주신 다른 팀원들에게 감사한 마음을 가짐