전체 글17 테스트 코드 작성을 통한 리팩토링과 코드 품질 개선기 채팅 시스템의 핵심 로직인 ChatConsumer에 대한 테스트 코드를 작성하면서 겪었던 시행착오와 그 과정에서 얻은 인사이트들을 공유해보려고 한다. 관련 PR : https://github.com/100-hours-a-week/19-Respec-BE-Chatconsumer/pull/17테스트 코드 작성이 어려웠던 이유처음에는 단순히 "테스트 코드만 작성하면 되겠지"라고 생각했는데, 막상 시작해보니 생각보다 복잡했다. WebClient는 mocking하기 어렵고, 여러 외부 의존성들(Kafka, Redis, MySQL)이 얽혀있어서 테스트하기 까다로운 상황이었다.WebClient Mocking의 어려움과 해결문제 상황WebClient의 경우 response가 체인으로 얽혀 있어 일반적인 mocking 방.. 2025. 6. 25. Kafka Consumer를 활용한 채팅 릴레이 시스템 구현기 앞서 WebSocket을 통해 채팅 메시지를 Kafka로 전송하는 부분을 구현했다면, 이번에는 그 메시지를 consume해서 실제 사용자에게 전달하는 채팅 릴레이 시스템을 구현했다. 관련 PR: https://github.com/100-hours-a-week/19-Respec-BE-Chatconsumer/pull/4채팅 릴레이 시스템이 필요한 이유분산 서버 환경에서는 사용자 A가 접속한 서버와 사용자 B가 접속한 서버가 다를 수 있다. A가 B에게 채팅을 보낸다면, A의 서버에서 Kafka로 메시지를 보내고, 챗 릴레이 서버가 B가 접속한 서버를 판별하고 해당 메시지를 relay해서 전달해야 한다. 이런 서버 간 채팅 전달 역할을 하는 것이 채팅 릴레이 시스템이다.채팅 릴레이 시스템 구현 과정Kafka .. 2025. 6. 24. WebSocket + Kafka를 활용한 실시간 채팅 시스템 구현기 카카오테크 부트캠프에서 실시간 채팅 시스템을 구현하면서 겪었던 시행착오와 개선 과정을 공유해보려고 한다. 관련 PR:https://github.com/100-hours-a-week/19-Respec-BE/pull/76왜 순수 WebSocket을 선택했을까?처음에는 STOMP를 사용할지 순수 WebSocket을 사용할지 고민이 많았다. 1:1 채팅만 구현하면 되는 상황이어서 STOMP의 복잡함보다는 순수 WebSocket의 단순함이 더 매력적으로 보였다. 하지만 이 선택이 나중에 여러 문제를 가져다 줄 줄은 몰랐다.실시간 채팅 시스템 구현 과정WebSocket 연결 및 세션 관리사용자가 WebSocket에 연결되면 afterConnectionEstablished 메서드에서 이를 포착한다. 그리고 EC2 p.. 2025. 6. 23. 테크 스펙 작성 - 문서로 하는 코딩 카카오테크 부트캠프에서 프로젝트를 진행하면서 뱅크샐러드 류성두님의 "테크 스펙으로 모두가 함께 성장하는 내용" 발표를 보게 되었다. '문서로 하는 코딩'이라는 개념이 정말 신선했고, 실제로 우리 프로젝트에 적용해보고 싶었다. 참고한 유튜브 : https://www.youtube.com/watch?v=QHaVLYGqjvs 테크 스펙이란 무엇인가?스펙 vs 테크 스펙일반적인 스펙은 이런 거다:"자산 화면에서 편집 버튼을 누르면 편집 화면이 나와야 된다" 테크 스펙은 같은 내용을 이렇게 쓴다:"UIButton에다가 touchUpInside 입력을 받으면 EditViewController의 push라는 이벤트를 방출해야 됩니다" 즉, 스펙을 테크니컬하게 작성하는 것이 테크 스펙이다. 왜 테크 스펙이 필요한가?모.. 2025. 6. 11. 분산 환경에서 1:1 채팅 서버 구축하기 - 이벤트 기반 아키텍처 도입기 카카오테크 부트캠프에서 프로젝트를 진행하면서 분산 서버 환경에서 채팅 기능을 구현해야 하는 상황이 생겼다. 처음에는 단순하게 생각했는데, 막상 해보니 생각보다 복잡한 문제들이 많았다.문제 상황서버가 여러 대로 분산되어 있을 때, 사용자 A가 Server1에 접속해 있고 사용자 B가 Server2에 접속해 있다면 어떻게 메시지를 전달할 것인가?처음에는 각 서버끼리 직접 통신하는 방식을 생각했다. 하지만 서버가 늘어날수록 복잡도가 기하급수적으로 증가하는 문제가 발생했다. Server1이 Server2, Server3, Server4... 모든 서버의 위치를 알아야 하고, 상대방이 어느 서버에 있는지 매번 확인해야 했다.이런 상황에서 중간 계층으로 브로커를 두면 문제가 해결된다는 것을 깨달았다. 서버는 단순히.. 2025. 5. 30. JPA 양방향 매핑과 CASCADE.ALL 도입 결정 과정 Spec 엔티티와 관련된 여러 하위 엔티티들을 관리하면서 겪었던 문제점과 이를 해결하기 위한 양방향 매핑 및 CASCADE.ALL 도입 과정을 공유해보려고 한다.문제 상황: 같은 생명주기를 가진 여러 엔티티들우리 서비스의 Spec 엔티티는 다음 6개의 하위 엔티티들과 밀접한 관계를 가지고 있었다:Education (학력)WorkExperience (경력)Portfolio (포트폴리오)ActivityNetworking (활동/네트워킹)Certification (자격증)LanguageSkill (언어 능력)문제는 이들이 모두 같은 생명주기를 가진다는 점이었다. Spec 엔티티에 관련된 GET, POST, PUT, DELETE API를 정의할 때마다 해당 6개의 엔티티들과 필연적으로 함께 사용되었다.해결 방안.. 2025. 5. 19. 이전 1 2 3 다음
