Side Match

개요작년 SW마에스트로를 통해 개발자 사이드 프로젝트 팀 매칭 플랫폼을 만들었는데, 유저가 모이지 않고 클라우드 비용이 만만치 않아 운영을 중지 했었다. 그런데 최근에 프로젝트 기획을 조금 바꾸어 다른 방향으로 서비스를 하자는 좋은 제안이 들어왔고 SW마에스트로의 지원이 중지 된 지금 클라우드 비용 최적화를 하고자 한다. + 현재 AWS에서 스타트업 창업 패키지로 1000$을 2년동안 지원 받은 상태이고, 한정된 비용으로 최대한 오래 서비스를 유지하기 위해 작년에 비용이 저렴할 것이라고 예상했지만 통수를 씨게 맞았던 DynamoDB 부터 마이그레이션 하기로 결정 하였다. 아래 링크는 내가 작년에 했던 고민이다.2023.10.21 - [SW마에스트로] - [SW마에스트로] 채팅 기능을 만들면서 하는 고민(..

개요현재 개발자 사이드 프로젝트 팀 매칭 플랫폼을 리뉴얼 하고 있으며 SW 마에스트로의 금전 지원이 끊긴 지금 AWS 비용 을 최적화 해야 했다.  Github Action 선정 이유작년 SW 마에스트로의 지원이 빵빵 할때는 Jenkins를 이용하여 팀원분께서 CI/CD를 구축 하셨었다.하지만 지원이 없는 지금 Jenkins는 EC2 한대를 더 올려야 사용이 가능했기 때문에 이 가격을 줄이고자 나는 다른 CI/CD 툴을 찾아 나섰다.CI/CD 툴에는 여러가지가 있었다.Github ActionsJenkinsCircle CITravis CI등등난 이중에서도 현업에서 많이 사용하고, 무료로 사용할 수 있고, 빌드용 서버가 따로 필요없는 Github Actions를 활용하기로 결정하였다. 프로젝트 파일의 최상..

현재 개발자 사이드 프로젝트 팀 매칭을 하고 매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 개요 1차 배포때 모니터링 시스템이 없어서 EC2 콘솔로 로그를 확인하였었는데 너무 불편하였다. 똑같은 실수를 방지하고자 최종 배포 때는 모니터링 시스템을 부착하고자 한다. 모니터링 서비스 종류 모니터링 서비스에는 엄청 여러가지가 있었다. ELK (ElasticSearch + LogStash + Kibana) Sentry DataDog Prometheus + grafana cloudwatch 등등.. 엄청 많았다. 이중에서 현 상황에 적합한 기술을 찾고자 한다. 모니터링 서비스 비교 우선 모니터링 서비스는 크게 로그 모니터링과 서버 모니터링 으로 나뉘는것 같았다 로그 모니터링은 에러나 사용자가 남기..

- 문제 상황 - 원래는 MySQL을 사용하고 있었는데 채팅 메세지를 적재하기 위해서 NoSQL인 DynamoDB를 연결했다. 그런데 연결만 했을 뿐인데 에러가 빵빵 터졌다. 에러 메세지를 보니 약간 Bean이 중복(?)되는 느낌인거 같았다. - 해결 - 구글링 결과 JPA의 경우 default로 SpringBoot가 실행되면 컴포넌트 스캔으로 전체 패키지를 돌아 Entity와 Jpa를 사용하는 DAO단을 빈에 올린다. 그런데 DynamoDB랑 충돌이 일어난 것이었다. 그래서 우선 JPA를 사용하는 패키지와 DynamoDB를 사용하는 패키지를 분리하였다. @RequiredArgsConstructor @Configuration @EnableJpaRepositories(basePackages = {"com...

현재 개발자 사이드 프로젝트 팀 매칭을 하고매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다  - 개발 배경 -1차 배포를 하고 지인들에게 내가 만든 서비스를 피드백 받았다. 피드백 결과 기존 방식인 카카오톡 오픈채팅방으로는 팀 매칭이 힘들다는 평가를 받았다.  우리끼리도 어느정도 예상하고 있었던 문제점이기에 채팅 기능을 구현하기로 결정하였다.   - 채팅의 특성 -1. 채팅은 일반 게시물 보다 쌓이는 데이터 양(Insert)이 많다.2. 채팅은 Update, Delete 연산을 할 일이 없다.3. 채팅은 프라이버시와 보안이 중요하다.4. 채팅은 새로고침(요청)을 하지 않아도 실시간으로 주고 받을수 있어야 한다.  - DB 선정 - 개요채팅 메세지는 기존의 데이터보다 데이터 양이 많았고, 이..

현재 개발자 사이드 프로젝트 팀 매칭을 하고 매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 문제 상황 유저 프로필 사진, 팀의 썸네일 사진을 업로드 하기 위해서 사진 업로드, 삭제 기능을 만들어야 했다. 그래서 정석대로 MultipartFile로 사진 파일을 받아서 S3에 업로드를 하려고 했다, 하지만 MultipartFile은 프론트에서 Form 형식으로 보낼때만 받을수 있고 Json에 담아서 보낼순 없었다. 그렇다고 이미 Json으로 통신하도록 만들어진 프론트 코드를 변경하기엔 무리였다. + Json하고 MultipartFile를 같이 보낼수 있긴 하지만 결국 form으로 한번 감싸서 그 안에 Json과 MultipartFile을 넣어야 하는것이라서 프론트에서 번거롭기는 똑같았다. h..

현재 개발자 사이드 프로젝트 팀 매칭을 하고 매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 고민의 발단 우리 서비스에선 사용자끼리 팀 매칭을 하고 프로젝트/스터디 중간 중간에 팀원에 대한 피드백을 남긴다. 이 피드백 방식을 어떻게 가져가야 할지 고민을 정리해 봄으로써 의사 결정하고자 한다. 아이디어 먼저 피드백의 2가지 방식이 떠올랐다. 1. 별점 방식(코멘트 중심) 2. 당근의 온도 방식(키워드 중심) 장단점 비교 * 별점 방식 장점 : 이 사람이 팀원으로써 괜찮은 사람인지 명확하게 알 수 있다. 단점 : 처음 한번만 별점을 못받아도 별점이 매우 낮아져 그 후 유저가 활동을 안할수 있다. * 당근의 온도 방식 장점 : 초반에 온도가 깎여도 별점만큼 극단적으로 티가 나지 않는다. 단점 :..

현재 개발자 사이드 프로젝트 팀 매칭을 하고 매칭한 팀끼리 멘토링 받을 수 있는 플랫폼을 제작하고 있습니다 개요 나는 중간 발표때 시연을 해야해서 급하게 결과 화면을 뽑아내기 위해 "예외처리, 테스트 코드"를 작성하지 않고 API만 주구장창 개발하였다. 나와 팀원분 둘다 첫 프로젝트라 예외 처리를 하는 방법을 잘 몰랐었는데 시간이 많이 들 것 같아 중간 발표 이후에 만들기로 했던것이다. 이제 중간 발표(8/26)가 끝났으니 1차 배포 전까지 안정적인 서비스를 만들기 위해 예외처리를 적용하고자 한다. 예외 처리 설계 1. 먼저 예외를 공통으로 처리 할 advice 클래스 GlobalAdvice를 만들 예정이다. 그리고 GlobalAdvice 클래스 안에서 @ExceptionHandler를 이용하여 발생한 ..