즐거운 개발자가 되자

랜덤 매칭 대기열 로직 작성 시 처음에는 Spring In-Memory Collection에 저장해두고 테스트를 진행했다. 완성 이후 서버 이중화 등을 고려했을 때 다른 저장소에 저장해두고 사용해야 할 필요성을 느꼈다. 성능 비교를 위해, RDB에 저장해두고 쓴 것과 Redis에 저장해두는 방식을 각각 제작해서 비교해보았다. RDB에는 단순히 관련 정보를 저장했다가 삭제하는 식으로 작성했고, Redis에서는 Redis 자료구조 중 Sorted Set을 이용하여 대기열을 구현하였다. Redis의 일반 List로 할 경우, 순서는 보장될 수 있지만 Redis의 List는 양쪽에서 LPOP,RPOP이 가능한 Deque 구조이기 때문에 일부 유저가 차단된 상황 등 대기열의 중간에서 특정 값을 빼야 하는 상황이 ..

Fact 실제 서비스를 런칭해서, 유저 피드백을 받고 수정 사항을 반영했다. 알고리즘 문제를 다시 시작했다. Feeling 하나의 서비스를 런칭하는 과정에서 협업의 중요성을 실감하게 되었다. Finding 나는 백엔드로서 프로젝트에 참여했는데, 유저 피드백에서 제시된 수정사항은 대부분 페이지 이동시의 불편함이나 음소거 버튼 기능이 활성화 상태인지가 명확하게 구분되지 않는 등 주로 UX와 관련해서 프론트엔드에서 수정할 수 있을 법한 내용이었다. 때문에 코드 작성보다는 피드백 받은 내용 중 당장 개선이 가능한 부분과, 기간을 잡고 천천히 수정해나갈 부분을 나눠서 언제, 어떻게 개선할지 결정하기 위한 회의가 주된 활동이었던 것 같다. 물론 백엔드에서도 목표한 기능을 더 구체화시키거나 더 발전시킬 여지는 많았을..

Fact MVP 배포 후 발견된 오류 수정 및 개선을 진행했다. Feeling 설계 당시에도 회의를 거쳐 많은 걸 고려하고 코드를 작성하지만, 클라이언트와 연결되고 실제로 작동해봐야 발견할 수 있는 문제들이 많다는 걸 느꼈다. Finding 이전 포스팅에서도 살짝 언급됐지만 역할 분담 시에 나는 웹 소켓과 매칭 대기열 시스템을 위주로 구현했었다. https://hae3043.tistory.com/50 2023. 08. 14~19 시그널링 socket.io로 변경 WIL에서도 작성했었지만, 시그널링을 위한 소켓 통신 시스템을 socket.io로 변경하는 작업을 진행하게 됐다. 진행 과정에서 생각나는 부분들을 간단하게 정리해볼까 한다. 우선 spring에서 제공하는 hae3043.tistory.com 초기에..

WIL에서도 작성했었지만, 시그널링을 위한 소켓 통신 시스템을 socket.io로 변경하는 작업을 진행하게 됐다. 진행 과정에서 생각나는 부분들을 간단하게 정리해볼까 한다. 우선 spring에서 제공하는 starter-websocket의 경우 일반적으로 기존 http요청들을 처리하는 포트와 동일한 포트를 사용해서 핸드셰이크 및 ws요청들을 처리하지만, 스프링에서 socket.io를 사용하기 위한 라이브러리는 자체적인 서버를 열기 때문에 기존 서버와 포트를 나눠서 열어주어야 한다. 그리고 기본적으로 이벤트 기반으로 작동하기 때문에, 각각의 이벤트에 이벤트 리스너를 등록해서 이벤트를 처리하게 된다. Node.js에서는 서버와 클라이언트 측 모두가 socket.emit , socket.on 형식으로 서로 이벤..

Fact 프로젝트 1차 배포를 위한 MVP 구현 작업을 했다. Feeling 어느 정도 클라이언트와 연결이 조금씩 진행돼가면서, 결과물이 눈에 보이기 시작해서 좋았다. Finding 이번 실전 프로젝트에서 가장 잘했다고 생각했던 점은, 나름대로 협업같은 협업을 진행했다는 것이다. 깃허브의 이슈, 프로젝트 탭을 적극 활용해서 이슈와 커밋을 연동하고 각자 맡을 부분을 공유하면서 작업을 진행하고, 마일스톤을 통해 프로젝트의 진척도를 파악했다. 고쳐야 할 부분이나 새롭게 만들어가야 할 목표 기능들을 새로운 이슈로 꾸준히 등록하고 관리하면서, 앞으로 어떤걸 새롭게 해야 할지 한눈에 볼 수 있었다. 아쉬웠던 부분은 공부의 깊이에 대한 이야기가 될 것 같다. 이번 회고를 쓰면서, 여태까지 적었던 개발일지 블로그 글들..

Fact 프로젝트 1차 목표 기능 구현 작업을 했다. Feeling 매번 1주 단위의 소규모 프로젝트를 진행하다가 6주짜리 프로젝트를 진행하다 보니, 생각할 게 더 많아지는 것 같다. Finding 백엔드와 프론트엔드의 개발 환경에 따라 특정 기능을 구현하는 라이브러리 편의성이 다를 수 있다는 걸 체감하게 됐다. 프로젝트의 모든 인원이 소켓에서부터 시그널링 서버 구현을 비롯한 WebRTC 기술 자체를 처음 접하다 보니 각자가 자료를 찾아보게 됐다. 그렇게 찾아본 결과, SpringBoot에서 웹 소켓을 다루려고 하면 보통 org.springframework.boot:spring-boot-starter-websocket 의존성을 추가한 후 사용하는 게 일반적인 듯했다. 이 라이브러리를 사용하면 기본 웹 소..

WIL에서 얘기했던 대로 주제가 어그러진 후, 새롭게 탄생한 주제에서 1:1 화상 통화 기능이 필요했다. 그냥 단순히 방을 직접 찾아가서 1:1로 대화를 시작하는 게 아니라, 매칭을 시도하면 조건에 맞는 사람이 이미 대기중인지 조회해보고, 있으면 바로 매칭, 없으면 대기하다가 조건에 맞는 사람이 나타나면 연결돼야 했다. 실제로 구현하는 방법이야 다양하겠지만, 나는 웹 소켓 요청을 이용해 실시간으로 매칭이 연결됐는지를 알려주는 방법으로 구현해보고 싶었다. 매칭 시스템을 구현하기까지의 과정을 간략하게 기록으로 남겨보려고 한다. 이번 프로젝트를 통해 웹 소켓을 처음 접해봤고, 웹 소켓에 대한 공부와 동시에 기능 구현이 진행된 터라 부족한 부분이 많을 것임을 감안해 주었으면 한다. 구현 시 고려했던 점. 1. ..

Fact 본 프로젝트 뼈대를 잡았다. Feeling 캠프 생활에서 가장 중요하다고 볼 수도 있는 본 프로젝트가 시작되었다. 결과물이 어떻게 나오냐가 포트폴리오에도 상당한 영향이 있을 수 있다 보니, 다들 조금은 예민하지 않을까 걱정했는데 그래도 나름대로 팀 분위기가 좋은 것 같아서 다행이다. Finding - 특정 주제로 기획을 할 때, 고려해야 될 부분이 생각보다도 훨씬 많다. 프로젝트가 시작되고, 첫 회의 결과로 각 OTT사이트의 영화 정보를 모아서 보기 편하게 검색해주는 사이트를 만들기로 결정했다. 캠프에서 제공해주는 스프링 강의 중 다음 영화 랭킹 페이지를 크롤링해보는 과정도 있었고, 레퍼런스로 삼을 만한 실제 서비스 중인 사이트도 있었기 때문에 당연히 별 문제 없을 거라 생각하고 각자 자료들을 ..

현재는 op.gg를 클로닝하는 프로젝트 진행중이다. 앞에서의 WIL에서도 살짝 언급했지만, riot API를 사용해서 op.gg처럼 정보를 뿌려주는 것이 생각보다 험난했다. .https://news.op.gg/news/5565978/%27%EB%A6%AC%EA%B7%B8-%EC%98%A4%EB%B8%8C-%EB%A0%88%EC%A0%84%EB%93%9C%27-%EA%B2%8C%EC%9E%84-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%B3%B4%EB%8A%94 '리그 오브 레전드' 게임 데이터는 어떻게 보는 걸까? 롤 전적, 모든 게임의 전적, 챔프 평점, KDA, 승률을 볼 수 있고 리플을 보거나 자신의 게임을 녹화를 할 ..

Fact 미니 프로젝트를 무사히 마쳤다. 클론 프로젝트의 틀을 잡아보았다. Feeling 아직은 많은 경험을 하지 못한 상태기 때문에 확신은 할 수 없겠지만, 내가 어떤 걸 좋아하는 지 조금 더 알게 된 것 같아서 기분이 좋으면서도 좀 아리송하다. Finding 팀 프로젝트에 정답이라는 건 없다는 걸 다시금 깨닫게 된 것 같다. 주 초반에 작업했던 미니 프로젝트의 경우에는, 새로운 라이브러리나 로직들을 많이 학습하게 된 프로젝트여서 매우 만족스러웠다. 기존의 CRUD작업 방식을 조금 더 업그레이드 시키는 느낌이었고, 비즈니스 로직이 돌아가는 흐름을 조금 더 상세하게 파악할 수 있었다. 프론트 부분 작업량의 한계로 클라이언트와의 연결이 원활하지는 않았지만, 결과물과는 상관없이 매우 행복하고 재미있었던 미니..