파이널 프로젝트 회고록

1. 프로젝트 개요

프로젝트 달성 목표

 

• 프로젝트 이름: clear - bunyang
• 프로젝트 기간: 2024.07.18 ~ 2024.09.20
  • 개발 기간: 2024.08.09 ~ 2024.9.20
  • 기획 기간: 2024.07.18 ~ 2024.8.09
• 팀원 구성: PM-4명, UXUI-5명, FE-3명, BE- 5명
• 주요 목표: 아파트, 오피스텔, 상가의 미분양 문제를 해결하기 위해, 검증된 정보를 신속하게 제공하는 플랫폼. 고객이 쉽게 접근하여 상담, 계약으로 이어질 수 있도록 지원함으로써 미분양 문제를 효과적으로 해소하는 것을 목표로 했다. 

2. 진행 과정

• 주요 작업 및 일정:
  • 기획 기간: 2024.07.18 ~ 2024.8.09
  • 개발 기간: 2024.08.09 ~ 2024.9.20
    • PM, UXUI 가 먼저 기획을 시작했다. PM분 들이 우선순위 설정 후 개발단에게 기능 구현 여부를 확인하며 기획을 구체적으로 설정해나가셨고 이를 토대로 FE와 API 스펙을 맞춰가며 개발을 진행했다. 
• 사용한 기술 스택:
  • • Java 17
    • Springboot 3.2.3
    • JPA
    • MySQL
    • Docker
    • GitHub Registry
    • aws
    • grafana
    • redis

3. 성과 및 성공 요소

• 달성한 목표:
  • 맡은 기능 구현을 완료하였다. 
  • 분산락과 캐시 기능을 적용해보았다. 
• 팀워크 및 협업:
  • PM/ UXUI 분들과는 slack 을 통해 소통하였고, 개발단끼리는 디스코드를 사용해 소통했다.
  • 매 주 월요일 출석체크 후, 모든 팀원들이 줌에 모여 각 파트의 상황을 보고했다.
  • 개발단은 평일 10:00 ~ 19:00 사이라면 자유롭게 질문을 주고 받았다.
    
    • BE끼리는 19시 이후에도, 주말에도 소통을 했다. 약속한 건 아니었지만 언제 질문하든 2시간 내로 답변이 왔었다...

4. 어려움 및 문제점

• 주요 이슈 및 해결 방법:
  • 분산락: 
    • 처음에는 트랜잭션을 분리하지 않고 사용 illegalMonitorStateException이 발생, 첫 실행에 update가 되지 않음 -> @trasaction(propagation = Propagation.REQUIRES_NEW, timeout = 10) 사용 트랜잭션을 분리하고, aop 서 catch (illegalMonitorException e) 적용해 해결
    • ClassCastException -> 커스텀 에러 설정해 해결
    • k6서 400코드가 200으로 넘어가는 문제 -> ErrorCode 400 을 HttpStatus.BAD_REQUEST.value() 로 변경해 해결
    • 위 방법을 적용해서 에러를 잡고, 작동하는 것 까지는 확인 했으나 락 획득을 하지 못하는 문제가 있었다. 멘토링 진행 후, wait time, leas time 을 수정했고, 분리된 트랜잭션을 삭제하니 정상적인 락 작동이 되었다. 
    • 지난 프로젝트서 분산락을 적용한 팀의 프로젝트와 테크 블로그의 분산락을  이 프로젝트에선 작동되지 않거나, 에러가 나는 경우가 빈번했다. k6가 ErrorCode status 400을 Error로 인식하지 못하는 것도 처음 알았다. 시간이 많이 걸리고 시행착오가 많았던 만큼 많은걸 배웠다. 
• 예상하지 못한 어려움:
  • 소통의 어려움:담당 FE분과 api 스펙을 함께 맞춰봤고, 어느 정도 작업이 완성되었다고 생각했었는데 제출 며칠 전 담당자분이 바뀌고 수정 해야하는 부분과 추가되는 api가 생겨 시간이 촉박했다. 이 기간 동안 내 작업물의 문제점도 많이 발견 하였고, FE단의 작업 방식을 조금이라도 이해할 수 있었다. 

5. 배운 점

• 개인적인 교훈:
  • 기술적 성장: 여러 프로젝트를 끝내고 나니 기술적으로 성장한 것이 느껴졌다. 미니프로젝트의 미흡한 api 설계를 보완했고(PathVariable 은 하나만 사용해야한다는 것), 어떤 것을 리팩토링 해야할지도 눈에 보였고, 어노테이션도 적절하게 사용했다. DB에 접근을 최소화 하고자 repository 계층에 dto를 처음 사용해봤고, 리팩토링도 여러 차례 공들여했다. 리팩토링이 필요 없이 한 번에 잘 하면 좋았겠지만, 고작 며칠, 몇주전의 내 코드에서 수정할 점을 발견했다는 것이 성장의 증거라고 생각한다.
  • 협업 능력의 성장: 미니프로젝트에서는 실무 경험이 있으신 분이 도맡아 FE와 소통하시고, BE 팀원들에게 문제점을 전해주시는 방식으로 진행했다. 이 방법이 빠르고, 편하긴 했지만 나의 성장엔 도움이 되지 않았다. FE와 1:1 협업을 해보지 않은 상태로 파이널 프로젝트에 들어왔고, 초반엔 긴장도 실수도 많이 했다. 하지만 2달이라는 프로젝트 기간 덕분에 FE 분들과 소통할 기회가 많았고 그 외 PM, UXUI 분들과도 협업해 소통,협업 능력이 성장했다.
• 팀 전체의 교훈:
  • 유능한 팀원들로 구성된 팀: BE 모든 팀원분들이 자기 역할을 똑부러지게 해내셨다. 유능한 팀원 덕분에 그라파나와 프로메테우스로 성능 모니터링도 볼 수 있었다. 팀원들을 보며 많이 배울 수 있는 좋은 프로젝트였다. 좋은 팀원을 만나는게 얼마나 중요한 것인지 다시 한 번 느꼈다.  

6. 향후 개선점

• 프로세스 개선 사항:
  • 코드리뷰: 초반에는 코드리뷰를 진행하였으나 후반에는 시간 부족으로 인해 코드리뷰를 진행하지 못했다. 후반으로 갈수록 바빠져 시간이 없는 건 어쩔 수 없는 건가 생각이 들었다. 
  • 이슈 관리: 문제가 생길 때, 문제를 해결했을 때 마다 디스코드 채팅방에서 소통했다. 편하긴 했지만 시간이 지나 찾아볼 때, 문서 작성 시 불편한 부분이 많다. 
• 기술적 개선 사항:
  • 초반 DB 설계의 아쉬움: 현재는 상담사 데이터를 상수로 하드코딩해 사용하고 있는데 상담사 테이블을 따로 만들거나, 멤버 테이블을 회원 - 상담사로 분리해 설계했으면 어땠을까 생각이 든다. 

7. 기타 의견

• 다음에는 배포를 도전해보고 싶다. 그 전 팀에서 잠시 공부 했었는데(팀이 한 번 깨졌었다.) 너무 어렵다고 느꼈다... 배포 하시는 분을 따라다니며 배우고 싶었는데 질문이 너무 많을까봐 가만히 있었다. 질문이라도 해볼걸 후회된다. 
• 도메인 로직은 미니 프로젝트에 비해 비교적 간단했다. 대신 분산락, 캐시 적용 같은 다른 기술을 사용해봤다. 시행착오를 많이 겪은 만큼 많이 배운 거 같다. 분산락과 캐시 관련해 팀원 분들에게 많은 질문을 했는데 시간 내서 알려주고 설명해준 팀원 분에게 감사하다. 
• 처음으로 실제 기업, PM, UXUI 와 협업한 프로젝트였다. 시작 전엔 많이 떨렸다. 진행하며 보니 우리는 우리의 역할을 열심히 하고, 우리의 의사를 명확히 전달하면 원활한 프로젝트 진행이 가능했다. (다른 파트도 이렇게 해준다는 전제 하에...) 
• 개발적인 요소도 실제 현업에서 진행하는 것과 동일한 형태를 추구하여 놀라운 점이였고, 속도에 대한 고민, 트러블 슈팅에 대한 고민 등이 인상적이였습니다.라는 기업의 피드백도 받았다. pr 을 하나하나 보신 거 같았다. 

pr