전체 글(10)
-
프로젝트에서 채팅을 구현한 방법 - 채팅 기능 문서화
💬 FriendShip의 채팅, 어떻게 설계했을까?채팅 서비스를 개발하면서 문서화의 중요성을 새삼 느꼈다. 특히 복잡한 시스템을 명확하게 표현하기 위해 시퀀스 다이어그램을 사용했던 경험을 공유하고자 한다.📌 개요FriendShip의 채팅 시스템은 STOMP 프로토콜을 기반으로 한 웹소켓을 사용하며, Pub/Sub (Publish-Subscribe) 모델을 따른다. 사용자는 특정 채팅방(chatRoom)의 메시지를 구독하고, 메시지를 발행하여 실시간으로 소통한다.🍊 Pub/Sub 구조란?Pub/Sub 구조를 간략하게 뉴스레터 시스템으로 비유하면 이해하기 쉽다:발행자(Publisher): 뉴스레터를 작성하여 보내는 사람구독자(Subscriber): 뉴스레터를 받아보는 사람토픽(Topic): 뉴스레터의 ..
2025.03.25 -
[트러블 슈팅] 테스트 실행 시간이 너무 길어요!
🚩 문제 상황프로젝트에서 하나, 둘 씩 테스트가 늘어가며 문제가 발생했다!1분 이하였던 테스트들이 4분을 넘어가기 시작했다.(실제로는 실행시간에 포함되지 않는 과정까지 영상으로 확인했을 때 5분 정도 되었다)테스트는 기능을 추가하고 수정하며 빠른 피드백을 얻기 위함이었는데, 깃허브 액션 환경에서는 20분이 걸리기도 하여 협업 효율을 낮춘다고 생각이 들었다.개선하고자 로그를 살펴봤다.크게 보이는 문제는 두 가지였는데각 테스트마다 컨텍스트 빌드 시간이 길다는 점데이터베이스의 쿼리문이 테스트 시간의 대부분을 차지한다는 점🛠️ 1. 컨텍스트 환경 통합시키기이전에 MockBean을 사용하며, 테스트 환경 캐싱으로 인한 충돌로 골머리를 앓았지만, 그때 어플리케이션 컨텍스트가 캐싱으로 재사용 가능하다는 것을 알게..
2025.03.25 -
배포 오류 : Asciidoctor 빌드 오류(asGemPath())
서비스 품질을 높이기 위해선 안정적인 테스트와 빌드 과정이 필수적이다. 하지만 자동화된 배포 환경을 구축하다 보면 예기치 못한 오류를 만나기도 한다. 이번에 Gradle과 Spring REST Docs를 활용해 CI/CD를 구성하면서 발생했던 오류와 해결 방법을 기록해본다.🚩 오류 상황배포 자동화를 구현하는 과정에서 갑자기 빌드 오류가 발생했다. 에러 메시지를 확인해 보니 다음과 같은 문제가 있었다. 검색 결과 Gradle의 버전과 관련된 이슈라는 정보를 찾았고, 버전을 6.5로 낮춰도 여전히 문제가 해결되지 않았다. 🛠️ 문제 해결 방법결국 플러그인과 build.gradle 파일을 수정하여 문제를 해결할 수 있었다.1️⃣ 플러그인 수정plugins { id 'java' id 'org.sp..
2025.03.09 -
CI/CD : 테스트 실패시, Push 안되게 하기
서비스 품질을 높이기 위해선 안정적인 테스트 과정이 필수적이다. 그러나 개발 과정에서 테스트가 실패했음을 인지하지 못하고 코드를 병합(Merge)하거나 배포하면 심각한 문제로 이어질 수 있다. 이번에 프로젝트에서 경험한, Gradle과 GitHub Actions를 활용한 CI 환경 구축을 통해 안정성을 높인 경험을 정리해본다.🚩 테스트 실패, 간과하면 큰일난다테스트 실패를 놓친 채로 코드가 병합되면 서비스가 정상적으로 동작하지 않을 수 있고, 이를 되돌리는 과정은 추가적인 시간과 노력이 필요하다. 이를 예방하기 위해 프로젝트에서는 다음과 같은 문제를 해결하고자 했다.개발자가 로컬 환경에서 테스트를 수행하지 않고 push하는 경우Pull Request(PR) 과정에서 테스트 실패 여부가 확인되지 않아 코..
2025.03.09 -
CI/CD : Github Actions를 이용한 배포 자동화
서비스를 개발하고 배포하는 과정에서 반복적인 수동 작업은 늘 귀찮고 번거롭다. 특히 프로젝트 규모가 커지고 배포 주기가 잦아질수록 이런 작업은 생산성 저하를 불러온다. 최근 팀 프로젝트에서 GitHub Actions를 이용한 CI/CD 자동화를 경험하며 느낀 점들과 그 과정에서 사용했던 설정 코드 일부를 정리해보려 한다. ⚙️ CI/CD 자동화, 왜 필요했을까? 개발 초기에는 배포가 큰 부담이 아니었지만, 서비스 규모가 점점 커지면서 배포 과정에서 실수가 생기기도 하고 시간이 너무 많이 소요되었다. 이를 개선하기 위해 배포 과정을 자동화할 필요성이 커졌다. ❗ 겪었던 문제들 수동 배포의 번거로움: 한 번의 배포에도 여러 작업이 필요했기 때문에 실수할 가능성이 높았다. 빠른 피드백 부족: 배포가 늦어지..
2025.03.09 -
Mock : 모의(대역) 객체로 테스트하기
🧪 테스트 중 외부 요인이 필요했던 나의 경험테스트를 작성하다 보면 가끔 외부 요인이 필요한 시점이 있다.예를 들면, 회원 가입 기능을 테스트하려고 하는데 DB가 필요할 때처럼 말이다.아래는 내가 직접 겪었던, 테스트 도중 외부 요인이 필요한 상황들이었다.DB에서 데이터를 조회하거나 추가해야 할 때외부 HTTP 서버와 통신이 필요한 로직일 때이런 외부 요인에 테스트가 의존하게 되면, 테스트 코드 작성이 진짜 귀찮아지고 실행도 어렵다.나 같은 경우엔 결제 서비스에서 결제 기능을 테스트해야 했는데, 외부 결제 대행사에게 요청을 보내고, 결제 성공 여부를 받는 로직이 있었다.💭 그래서 어떻게 테스트를 해야 했을까?결제 요청을 보냈는데, 대행사 서버에 문제가 생겨 timeout이 나는 경우는?이미 결제된 건..
2025.03.08