Q. 문제 이번주부터 성능 개선에 대한 진행 방법과 진지하게 고민해보고 있습니다. 문제 해결하는 과정을 아래와 같은 방식으로 스토리를 정리해나가면 될까요? 문제상황 → 해결방안 → 의견조율 → 의견결정 → 비교 결과들 수집과 정리.. 문제상황) 기획 당시 검색 기능과 페이지 기능 개선이 가장 중요한 토픽이 될 것으로 예측했었습니다. 현재 MVP 구현 단계에서는 실제 운영되고 있는 서비스들과 비교했을때 사용자가 불편함을 느낄 수 있을 수준으로 성능에 이상이 있음을 느끼고 있습니다. (좀 더 구체적이여야 하는지?) 해결방안) 기본적으로 저희가 할 수 있는 방안 탐색은 구글링, 타 프로젝트 레퍼런스 체크 정도가 맞는지. 저희가 하고있는 수준은 구글링, ChatGPT를 통한 키워드를 최대한 탐색하고 적용할 수 있는 기술스택이나 라이브러리가 어떤것이 있는지 찾고 있습니다. 의견조율) 팀적으로 회의를 통해서 위 내용에 대해서 공유하면서 적절한 기술스택인지를 판단해봅니다. 기본적으로 경험자가 없기때문에 사실 이 부분의 신뢰도가 부족합니다. 더 많은 자료를 탐색해보는 것이 해답인지 궁금합니다. 의견결정) 어떠한 개선사항 토픽 하나에 대해 몇가지 기술 스택을 사용해보자는 의견이 모였다면, 예로 검색기능 개선에서는 아래와 같은 의견들을 모을 수 있었습니다. [Spring][258] 검색관련 문제해결 및 성능 개선 방안 수집 업무 분담은 어떤식으로 하는 것이 효율적이고 팀전체가 성능개선에 참여한 느낌을 줄지 궁금합니다. 팀원이 모두 각자 적용해보고 비교해보는 것은 뭔가 팀적인 움직임이 아닌것 같은 느낌입니다. 모두가 동일한것을 해보니 실력적인 향상은 가장 좋을 것 같지만 마치 그냥 동일한 프로젝트를 개인프로젝트처럼 진행하는 느낌일 것 같습니다.. 아니면 일관성을 유지하기 위해서 전체 토픽을 맡아서 진행해보는게 맞는지 아니면 제가 구분해 둔 중간 토픽 정도로 분담하는것이 좋을지

A. 멘토님답변정리! 팀적으로 회의를 통해서 위 내용에 대해서 공유하면서 적절한 기술스택인지를 판단해봅니다. 기본적으로 경험자가 없기때문에 사실 이 부분의 신뢰도가 부족합니다. 더 많은 자료를 탐색해보는 것이 해답인지 궁금합니다.

현재상황에서는 교차체크가 현실적이고 그중에 정확한 방법일 것이므로 좋다.

현재 상황에서는 위 방법을 선택해야 하고, 추후에 CS, OS, Network, Data Structure, Algorithm 등 심화 공부를 통해서 아이디어를 획득 할 수 있다. → 어려운 문제, 상황을 해결할 키가 다르기 때문에, 계속해서 꾸준히 공부해야 한다. 그 중에 우선순위는 Data Structure , Algorithm 을 공부해보면 이런 문제 해결의 아이디어를 제공 할 수 있는 기본기를 쌓아 나갈 수 있다. https://www.yes24.com/Product/Goods/122445610 이것 같은 책들을 찾아보자.

A. 멘토님답변정리! 업무 분담은 어떤식으로 하는 것이 효율적이고 팀전체가 성능개선에 참여한 느낌을 줄지 궁금합니다. 현재는 분담하더라도 모든것을 혼자 할 수도 없으며, 모든것을 같이 하는것도 문제가 있다. 결국 팀프로젝트기 때문에 분담해야 하며, 프로젝트가 종료되더라도 다른 팀원의 코드, 기능을 내가 직접 다뤄보고 차이점을 느끼고, 그 선택과정을 살펴볼 필요가 있다. 이러한 프로젝트 복기를 해보면서 장기적으로 나만의 정리를 해보면서 공부해야 한다.

Q. 문제 해결을 위한 많은 기술적 해결 방안들이 있었는데, 블로그든 공식 문서든 각 기술들의 장 단점들을 설명해도 와닿지 않는 부분들이 많아 여러 기술들을 프로젝트에 적용해 보는 것이 좋을 것 같다는 생각이 들었습니다. 프로젝트를 할 때, 각 기술 간의 장 단점을 기준으로 가장 필요한 것을 선택한 후 하나만 적용해 프로젝트 코드를 작성하는 것이 좋을지, 아니면 각 기술별 메소드를 생성해서 일단 코드를 작성해 보는 것이 좋을지 궁금합니다. 또한 프로젝트에서 해당 기술들에 대한 분석을 프로젝트 내에서 끝낸 후에, 분석 과정들을 코드로 남겨두는 것이 좋은지, 그 중 가장 좋다고 판단한 버전을 제외하면 모두 삭제하는 것이 옳은 것인지 궁금합니다.

A. 멘토님답변정리! 기술스택을 써봐야 아는것이기 때문에, 학습과정에서 현재 사용하는것을 우선하는것은 어쩔수없는 선택이고, 틀린 선택이 아니다. 직접 해보는 것이 맞다. 만약 효과가 없더라도, 그것 자체도 경험으로 쌓아두는게 좋다. 실무에서는 데드라인이있기 때문에, 그 실패 경험도 추후 기술 선택에서의 실수를 줄일 수 있는 경험이기 때문에 쌓아두는게 좋다. 과거 코드 및 주석도 우선 모두 남겨놓는게 좋다. 스터디 과정의 프로젝트기 때문에, 브랜치도 삭제할 필요는 없다. 배포 최종본만 가장 깔끔하게 release 태그화 시켜놓을 필요는 있다.

Q. 현재 구현된 책 대출/예약 프로세스는 아래와 같습니다. 대출 : 로그인한 유저가 직접 버튼을 눌러 책을 대출/반납하는 방식 예약 : 대출된 책이 반납되는 즉시 첫번째 예약자가 자동으로 책을 대출 ebook을 대출하는 것이 아니기 때문에 위 방식은 실물 책을 사용하는 도서관 서비스에는 부적합하다고 생각됩니다. 학습용 프로젝트로서 위의 대출/예약 프로세스를 유지해도 상관없는지, 혹은 실제 서비스에 대입 가능하도록 프로세스를 바꿔야 하는지 문의드립니다.

A. 멘토님답변정리! 현재 상태 서비스 프로세스를 유지해도 좋을 것 같다. 서비스가 잘되는것, 최적화하는것도 중요하지만, 우리에게 중요한것은 문제해결을 위한 기술선택, 트러블 슈팅 등 이런 과정을 더 강조하는것이 우선순위가 높다.

Q. 현재 책 나눔 서비스를 제공하는 시스템에서 특정 기간 동안 신청 순서대로 책을 배부하는 구조를 가지고 있습니다. 이 과정에서 하나의 책에 여러명이 신청이 되는 동시성 문제가 발생하였습니다. 이를 해결하기 위해 데이터베이스 수준에서의 락, 애플리케이션 수준에서의 락(세마포어 및 뮤텍스), 혹은 카프카를 통한 구조적 해결 방법이 있다고 조사하였고 현재는 데이터베이스 수준의 락(비관적인 락, 낙관적인 락) 및 애플리케이션 수준에서 락(세마포어 및 뮤텍스)를 구현했습니다. 애플리케이션

[Spring][258] Spring 뮤텍스를 활용한 동시성 문제 해결

[Spring][258] Spring 세마포어를 통한 동시성 오류 해결

또한 현재 카프카를 통해 동시성 문제를 해결하는 것을 시도 중에 있습니다.

현재 진행 중인 대용량 트래픽을 처리하는 프로젝트에서 Kafka를 도입하여 확장성, 탄력성 및 고가용성을 향상시키고자 합니다. Kafka의 프로듀서와 컨슈머를 분리하여 여러 서버에 배치하는 아키텍처를 고려하고 있습니다. 이와 관련하여, 서버를 세 개로 나누어 프로듀서, Kafka, 컨슈머를 각각 다른 서버에 배치하면 성능 향상 측면에서 이점이 있는지, 아니면 프로듀서와 컨슈머를 같은 서버에 두고 Kafka 서버만 분리하는 것이 더 효율적인지 궁금합니다.

또한, 여러 서버에 걸쳐 비동기적인 작업 처리와 결과 전송을 위해 웹소켓이나 서버 센트 이벤트 등을 사용하는 방법과, 컨슈머가 직접 클라이언트에게 응답을 보내지 않고 프로듀서를 통해 응답을 전달하는 구조 중 어느 쪽이 더 효율적인지, 실무에서는 어떤 방식을 주로 사용하는지에 대한 멘토님의 의견을 듣고 싶습니다.

코드를 재구성하고 새로운 기술을 도입하는 데 있어 난이도와 시간적인 부담이 큰데, 이러한 구조 변경이 성능 향상 측면에서 실질적인 이점을 제공할 수 있는지, 그리고 장기적으로 보았을 때 이러한 아키텍처 변경이 프로젝트에 긍정적인 영향을 미칠 것인지에 대한 멘토님의 경험과 조언을 구하고자 합니다.

A. 멘토님답변정리! 상황에 따른 접근 : 구조변경이나 기술 도입은 서비스에 따라 다를 수 있으므로, 특정 서비스에 맞는 접근 방법을 고려해야 합니다. A, B 사이의 구체적인 상황과 요구사항을 기반으로 결정을 내려야 합니다. 난이도와 시간적인 부담 : 코드를 재구성하고 새로운 기술을 도입하는 과정은 난이도가 높고 시간이 많이 소요될 수 있습니다. 이러한 부담을 감안하여 구조변경이 성능향상 측면에서 실질적인 이점을 제공 하는지 장기적으로 프로젝트에 긍정적인 영향을 미칠지에 대해 충분히 고민해 봐야합니다. 이해도와 오류 해결 : 현재 저희 프로젝트에 대한 구조 이해가 높다면, 구조 변경 과정에서 발생 할 수 있는 중간오류를 우회하거나 해결책을 찾는 데 유리할 것으로 보입니다. 따라서 지금 상황에서는 시도하는 것이 맞다고 조언 하셨습니다. 실패 케이스에 대한 고려 : 구조 변경이 성공 할 수 있지만, 실패할 위험 역시 존재합니다. 실패 케이스에 대한 고민과 준비가 필요하다고 하십니다.

Q. 저희가 챌린지에서 다뤄보고 싶은 성능 개선 토픽은 아래처럼 2개를 목표로 두었습니다. 의견을 여쭤보고 싶습니다. [Spring][258] 검색관련 문제해결 및 성능 개선 방안 수집 [Spring][258] 동시성 문제 해결 및 성능 개선 방안 수집

A. 멘토님답변정리! 챌린지 토픽 선정은 적절하며 둘다 풀이하기 어려운 문제들이 맞다. 이번 프로젝트를 통해 잘 접근해보는 것이 좋다.