운영 중인 일부 서비스에서 웹훅을 통해 애플리케이션 이벤트 알림을 실시간으로 받고 있습니다. 현재는 Slack(이하 슬랙)을 통해 알림을 전송하고 있으나, 이를 Discord(이하 디스코드)로 이전하자는 의견이 제기되었습니다. 대부분의 온라인 활동(회의, 스터디 등)이 디스코드에서 이루어지고 있는 반면, 슬랙은 개발 팀에서만 사용되고 있었기 때문입니다. 또한, 슬랙의 무료 요금제는 메시지를 최대 90일까지만 보관할 수 있어 과거 기록을 확인하기 어려운 점도 중요한 이유 중 하나였습니다. 디스코드로의 이전은 기록 관리와 편의성 측면에서 장기적으로 더 나은 선택이라 판단하여 웹훅 시스템의 마이그레이션을 결정하게 되었습니다. 마이그레이션 과정에서는 애플리케이션의 비즈니스 로직과의 결합을 최소화하면서도 확장성..

CI/CD 파이프라인은 코드베이스 전반의 품질 관리, 안정성 확보 및 오류 최소화를 위해 빌드, 테스트, 배포 과정을 자동화하는 중요한 과정입니다. 프로젝트나 조직의 규모가 커질수록 이러한 자동화된 과정은 안정적인 운영을 위해 필수적입니다. 소프트웨어 개발 주기를 효율적으로 관리함으로써 비용을 크게 절감할 수 있습니다. 특히, 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Deployment)를 통해 개발 속도를 유지하면서도 높은 품질의 소프트웨어를 제공할 수 있습니다. 이번 글에서는 CI/CD의 기본 개념부터 시작하여, Spring Boot 프로젝트에서 SonarCloud, JaCoCo, Checkstyle, Codecov와 같은 도구들을 활용해 안정적이고..

개인적으로 테스트나 서비스 운영 목적으로 라즈베리파이를 활용해 소규모 서버를 운영하고 있습니다. 리소스가 매우 제한적인 화경에서 운영하다 보니, 자원을 조금이라도 효율적으로 활용하기 위해 다양한 시도를 해왔습니다. 이 과정에서 CDS(Class Date Sharing)와 AOT(Ahead-of-Time Compilation)라는 기술을 알게 되었고, 실제로 적용한 결과 애플리케이션의 시작 시간과 메모리 사용량에서 유의미한 개선을 확인할 수 있었습니다. Spring 공식 블로그에서 언급된 것처럼 극적인 개선은 이루어지지 않았지만, 리소스가 제한된 환경에서도 충분히 의미 있는 성과를 얻을 수 있었습니다. 특히, 이번에 적용한 프로젝트는 규모가 작은 편이었지만, 프로젝트 규모가 클수록 이러한 기술의 효과는 더..

현재 동아리에서 Docker 컨테이너를 활용하여 여러 서비스를 운영하고 있으며, 모든 서비스는 Dockerfile을 통해 빌드 및 배포되고 있습니다. 그러나 Gradle 빌드와 Docker 이미지 빌드를 포함한 전체 소요 시간이 평균 5분에 달해, 라즈베리 파이 4 환경을 고려할 때에도 비효율적이라는 판단에 이르게 되었습니다. 이를 해결하기 위해 Docker Multi-stage Builds와 Layered JAR를 도입했습니다. Dockerfile 내에서 빌드 단계와 런타임 단계를 분리하고, JAR 파일을 계층화함으로써 빌드 속도를 최적화하는 동시에 최종 이미지 크기도 효율적으로 줄일 수 있었습니다. 본 글에서는 이러한 멀티 스테이지 빌드와 레이어드 JAR의 적용 과정을 공유하며, 동일한 문제를 겪고 ..

인턴십 과제를 진행하며 프로덕트의 기능을 분석하던 중, 검색어에 띄어쓰기나 오타가 있을 경우 원하는 결과를 찾지 못하는 문제를 발견했습니다. 이는 서비스의 사용자 경험을 저해하고 이용률을 감소시킬 수 있는 중요한 이슈였습니다. 이 문제를 해결하기 위해 다양한 방법을 모색한 끝에, N-gram과 유사도 측정 기법을 활용하면 사용자가 원하는 데이터를 더 효과적으로 검색할 수 있을 것이라 판단했습니다. 이에 직접 이 기법들을 적용하여 검색 기능을 개선하였고, 그 과정에서 얻은 경험을 공유함으로써 비슷한 문제를 겪고 있는 분들에게 도움이 되고자 합니다. 0. 프로덕트 환경Spring Boot 3.xMongoDB Community 7.0.x 1. 기존 검색 시스템의 한계기존의 검색 시스템에서는 사용자가 입력한 검..