프로젝트 자세히보기

SFAM 소개

• 주위 사람들과 편리하고 다양한 스포츠 경기를 매칭 시켜주는 서비스입니다.

• 팀전 매치 및 다양한 종목에 대해 매치가 가능하며 채팅 및 전적관리, 경기 후기 등의 기능을 제공하여 보다 더 운동을 즐겁게 할 수 있도록 도모할 수 있습니다.

1️⃣  배포링크

운동 메이트가 필요할 땐 SFAM

https://www.dongkyurami.link/

2️⃣  프로젝트 관리

🖼️

프로젝트 관리

3️⃣  발표영상

4️⃣  프로젝트 진행 방식

• 3~4일 주기로 스프린트 및 회고를 진행하였습니다.

• 매일 14:00 ~ 19:00 코어타임을 정하여 스크럼 및 프로젝트를 진행하였습니다.

• 협업도구는 Discord, Gather, Slack, Jira, Notion 등을 사용하여 협업을 원할하게 진행하였습니다.

5️⃣  InfraStructure

• 프로젝트를 진행할 때 배포서버와 실제 사용자에게 제공되어야 하는 프로덕션 서버가 따로 분리되어 있어야 한다고 생각했습니다.

• 따라서 서버를 2개를 나누었으며 개발 서버에서 충분히 검증 된 API만 프로덕션 서버에 배포될 수 있도록 프로젝트를 진행하였습니다.

• 가장 먼저 충분한 검증이 이루어 졌기 때문에 사용자 입장에서 믿고 사용할 수 있으므로 신뢰도가 향상되는 이점이 있었습니다.

• 그만큼 개발하는 과정에서 많은 테스트를 진행하기 때문에 혹시나 프로덕션 서버에서 버그가 발생해도 치명적인 버그 발생률을 줄일 수 있었습니다.

6️⃣  Tech Stack

• SpringBoot의 최신 버전을 사용함으로써 Spring Security의 WebSecurityConfig가 Deplicated 된 사실을 알게 된 적이 있었습니다. 이 과정에서 자신이 쓰고 있는 기술이 어떻게 업데이트 되고 있는지에 대한 꾸준한 관심이 필요하다는 것을 느꼈습니다.

• 따라서 개발자는 항상 최신 기술에 관심을 많이 가져야 한다고 생각하였으며 기술스택을 최신버전 위주로 선택하게 되었습니다.

• 가장 먼저 자바17을 사용함으로써 레코드와, 개선된 스위치문을 사용할 수 있었습니다.
• 레코드를 적극적으로 사용하여 코드의 간결함과 불변성의 이점을 얻을 수 있었습니다.
• 개선된 스위치문을 통해 보다 더 간결한 코드를 작성할 수 있었습니다.

• Flyway 도입으로 Database 설계가 변경 될 시 유연하게 대응할 수 있었으며 변경 이력 확인이 가능하여 편리함을 얻을 수 있었습니다.

• QueryDSL의 도입으로 동적 쿼리를 보다 더 편리하게 작성하고 코드 가독성에 대한 이점 도 얻을 수 있었습니다.

• CI/CD의 도입을 통해 자동으로 배포환경을 구축하여 백엔드 개발에 더욱 집중할 수 있게 되었습니다.

7️⃣  ERD

8️⃣  기여한 역할

• 팀장의 역할로써 팀원들이 방향과 의지를 잃지 않도록 주도적으로 프로젝트를 진행할 수 있도록 도모하였습니다.

• 기획 및 스프린트 일정 조율, 팀원 담당 역할 할당
• 기획자로 프로젝트의 전반적인 기획 및 정책을 구성하였습니다.
• 팀장의 역할로 스프린트 일정 조율 및 각 팀원 간 역할을 스프린트 주기에 맞게 할당하였습니다.

• CI/CD 구성
• Github Actions과 AWS CodeDeploy를 사용하여 CICD를 구성하였습니다.

• HTTPS 적용
• AWS의 Route53을 통해 도메인을 등록하고 인증서를 발급받아 로드밸런서를 통해 HTTPS를 적용시켰습니다.

• S3 파일업로드 구현
• AWS S3 버킷에 프로필이미지, 로고이미지를 저장하기 위해 파일업로드 기능을 작성하였습니다.
• 파일확장자 외에 확장자를 강제로 변경할 수 있기 때문에 파일의 시그니처도 검증할 수 있도록 코드를 작성하였으며 아파치티카 라이브러리 사용을 고려하였지만 성능이슈 글을 보고 직접 작성해서 만들어 보았습니다.

• API / 테스트코드 작성
• 사용자 조회 API, 팀원 초대 및 거절 API, 팀원 등록 API, 초대목록 조회 API 개발
• 컨트롤러 목 테스트 및 서비스 통합테스트 작성

• 기술문서화
• QueryDSL
• HTTPS

9️⃣  트러블 슈팅

🧐  서비스끼리의 순환참조를 어떻게 해결해야 하는가?

• 관련된 도메인들끼리 서로 참조하여 순환참조가 발생하는 곳이 꽤 있었습니다.

• 이것을 어떻게 매끄럽게 순환참조를 없앨 수 있을지 고민을 많이 했었습니다.

1. Facade Pattern 패턴을 도입하여 한 곳에서 서비스를 관리하도록 만들어 해결하는 방법을 생각했습니다.
• 하지만 Facade Pattern을 도입하여 굳이 중간 Layer를 하나 거치도록 해야하는가? 에 대해 의문이 생겼으며 명확한 방법은 아니라고 생각이 들었습니다.

2. 단순하게 서비스에서 다른 도메인의 Repository를 참조하여 사용하는 것은 안될까?
1. 이 방법은 개인적으로 Repository의 참조를 열어두면 다른 서비스에서 도메인의 값이 의도치 않게 사용될 가능성이 더욱 높아지기 때문에 위험한 방법이라고 생각이 들었습니다.

• Giver 클래스도 더 작게 나눠서 다른 도메인에서만 필요로 하는 메서드만 사용할 수 있도록 제공하면 더 안전한 코드를 만들 수 있지 않을까 생각이 들었으며 반대로 그렇게 된다면 클래스 파일이 너무 많아져 관리가 힘들지 않을까란 생각도 들었습니다.

🧐  파일에 관련된 기능을 처리할 때 고려해야할 사항이 무엇이 있을까?

• 사용자가 확장자를 강제로 변경하여 요청을 보내도 정상적으로 처리되는 문제점이 있었습니다.

1. Apach Tika 라이브러리를 사용하여 요청이 들어온 확장자의 시그니처를 검증하도록 하는건 어떨까?
1. 좋은 대안이 될 수 있겠지만 Apach Tika의 경우 각 확장자 타입에 맞는 Mime Type의 Signature Offset만 검증하면 된다고 생각이 들었고 모든 파일을 읽는 것은 성능에 좋지 않다고 판단되었습니다.

• 따라서 직접 MimeType을 만들고 시그니처까지 함께 검증할 수 있도록 직접 작성하였습니다.

• 마감기한에 따라 기능구현이 우선이기 때문에 검증값을 단순히 문자열로 처리를 하였습니다. 하지만 이 또한 들어온 byte값을 문자열로 한번 더 변환이 일어나기 때문에 리소스 낭비라고 판단이 되었으며 개선되어야 할 점이라고 판단되었습니다.

• 추가적으로 파일 크기에 따라 resizing을 하는 부분도 더욱 고려해야 할 것 같습니다.

🧐  API 오류가 있을 때마다 매번 EC2 에서 로그를 확인하는 불편함을 어떻게 해소할까?

• 개발을 진행하면서 실제 협업이 이루어지는 서버는 EC2에서 실행되고 있기 때문에 로그를 바로바로 확인할 수 없었습니다.

• 또한 오류가 발생할 때마다 직접 EC2에 접속하여 로그를 확인하는 과정이 매우 번거로웠습니다.

• AWS CloudWatch를 통해 로그가 관리될 수 있도록 구성하였습니다.
• 불필요하게 EC2에 접속하지 않고 바로 AWS에서 한눈에 확인할 수 있어서 매우 편리하였습니다.

🔟  프로젝트를 하면서 느낀 점

• 처음으로 프론트 개발자와 팀을 이뤄 프로젝트를 진행한 만큼 협업이 어떻게 이루어지고 개발이 진행되는지 큰 흐름을 느끼며 배울 수 있었습니다.

• 팀원이 많을수록 각각 이해하고 있는 정도가 다르고 리소스 낭비가 심한 만큼 문서화와 비동기적 통신이 중요하다는 것을 다시한번 느낄 수 있었습니다.

• 백엔드가 생각하는 Response 형태와 프론트가 생각하는 Response 형태가 다르다는 것을 새로 알게 되었으며 API 개발 시 프론트의 입장에서 한번 더 생각해보는 계기가 되었습니다.

• 단순한 API 한개라도 실무에서는 다양한 상황이 있을 수 있고 고려해야 할 점이 많다는 것을 느낄 수 있었습니다.