원격 웨이팅 서비스에서 가장 많이 동작하는 API는 무엇일까? 놀랍게도 조회 API이다. 하루에도 수천 명의 사용자는 수십 개의 매장을 살펴보며 메뉴를 구경하고, 마음에 드는 곳을 발견하면 웨이팅을 걸고는 한다. 라인업지도 그랬다. 만약, 서비스를 접속했는데 주점 목록을 가져오는 데 수 초 이상이 걸린다면 어떻게 될까? 물론 서비스 사용자 수가 적을 때에는 문제가 없겠지만, 축제 기간에 수 백~수 천 명의 사용자가 초 단위로 접속하면 당연히 DB에는 부하가 갈 것이고, 부하가 가면 랜딩 페이지를 가져오는 데에는 오랜 시간이 걸릴 것이다. 사람들이 웹사이트를 처음 보고 해당 웹사이트가 어떤지 평가하는 데 걸리는 시간은 50m/s 이내(20분의 1초)라고 한다. 따라서 랜딩 페이지에서 데이터 로딩이 지연되는..

또 라인업지다. 혹시 라인업지가 무엇인지 궁금하신 분들을 위해 간단히 설명하자면, 2024년 가천대학교 가을 축제에 사용된 원격 웨이팅 서비스이다. 그리고 이 서비스를 구현하기 위해 경험했던 기술적 도전들을 차례차례 풀어나가고 있으며, 이번 글은 AuroraDB와 @Transactional 어노테이션을 통한 간단한 CQRS를 구현하는 내용이 될 것이다! CQRSCQRS(Command and Query Responsibility Segregation)는, 데이터 저장소(DB)로부터 발생하는 읽기 작업과 쓰기 작업을 분리하는 것을 뜻한다. 간단히 말해, 조회(R)와 명령(CUD) 작업을 분리한다는 것이다. 대부분의 서비스는 쓰기 작업보다 조회 작업이 압도적으로 많이 발생하기 때문에, 저장소를 분리하여 조금이..

개발 과정에서 기능을 구현한 뒤 로컬 환경에서 테스트하고 최종적으로 푸시하는 방식은 흔히 쓰이는 패턴이다. 하지만 소셜 로그인과 같이 프런트엔드와의 협업을 반드시 거쳐야 하는 기능 테스트에 해당 방식을 그대로 적용하면 여러 가지 불편한 점들이 발생한다.예를 들어, 로컬 환경에서는 문제가 없던 기능을 테스트 서버에 배포한 후에야 프런트와의 연동 과정에서 오류를 발견한다면, 이를 수정하고 다시 배포하는 반복 작업에 많은 시간과 에너지를 소모하게 된다. 결국 이러한 비효율적인 과정들은 의미 없는 병목 현상을 유발하면서 개발 생산성을 크게 저하시킨다. 본인도 실제로 소셜 로그인 기능을 구현하면서 많은 애로사항을 겪으면서, '로컬의 빌드 환경을 외부에서 접속하여 테스트할 수 있다면, 정말 좋을 것 같은데..'라는..

지난 10월, 동아리에서 활동했던 디자이너의 졸업작품을 위해 간단한 서버를 배포해야 했었다. 문제는, 프런트가 Vercel을 통해 배포를 진행했기에, 서버도 마찬가지로 SSL 인증을 통한 HTTPS 연결을 구성해줘야 했었다. 이때 선택지는 2개였는데,가장 싼 도메인을 사서 Nginx를 통해 HTTPS 구성하기Caddy를 통한 리버스 프록시로 HTTPS 구성하기난 후자를 선택했다. 왜냐하면 돈도 없었을뿐더러, Nginx를 설정하는 데에 드는 시간적 리소스 또한 만만치 않다고 판단했기 때문이다. 그리고 Caddy를 선택한 것은 최고의 선택이었다. 쉽고 빨랐기 때문이다. CaddyCaddy는 모든 도메인에 대해 자동으로 SSL 연결을 지원해주는 오픈소스이다. Caddyfile이라는 설정 파일을 통해 편리하게 ..

지난 11월 6일, 현재 리드를 역임하고 있는 가천대학교 IT 학술동아리 Leets와 GDG on Campus Gachon이 연합해서 주최한 컨퍼런스 마일스콘이 성황리에 마무리되었다. 해당 컨퍼런스를 준비하면서 느꼈던 감정과 희로애락을 꼭 작성해야겠다고 다짐했었는데, 해당 마일스콘을 계기로 연달아 추가적인 컨퍼런스를 주최하게 되면서 해당 다짐은 잠시 뒤로 미뤄둔 상태였다. 그래도 짤막하게나 링크드인에 소감 몇 마디를 남겼는데, 궁금하신 분들은 아래 링크를 통해 구경해 주시면 좋을 것 같다..ㅎ  LinkedIn Jeongwan Noh 페이지: 마일스콘: 개발자로서의 첫 걸음부터 지속 가능한 성장을 위한 이정표 |좋은 계기로 이번 행사를 주관하며 사회를 진행하게 되어 뜻깊은 시간이었습니다. MilesCon..

현재 리드를 역임하고 있는 가천대학교 IT학술동아리 Leets의 5기 새 단장(?)을 맞아, 랜딩 페이지에 신기능을 도입하는 중이다.신기능이라고 해봤자 거창한 것은 아니고, 모집 알림 신청 기능을 메일링을 통해 구현해주는 것이 목표이다! 이번 글은 해당 기능을 구현하면서 DTO에서 필드 검증 시에 발생하는 예외를 어떻게 처리하여 프런트에게 공통 응답을 보내줄 수 있었는지에 대한 내용이 될 것이다.덕분에 오늘도 프런트랑 행복한 협업을 진행할 수 있게 되었다..>_ DTO에서 필드 검증하기DTO를 통해 필요한 값을 전달 받을 때, 프런트에서도 검증을 해주지만 혹시 모를 경우에 대비해 서버 단에서도 검증을 해주는 것이 좋다.이를 위해서 우리는 @Valid 어노테이션을 사용해야 한다. @Valid@Valid 어..

이번에도 라인업지 서비스를 진행하면서 적용했던 기술적 도전을 간단하게나마 풀어보려 한다.매번 라인업지 서비스를 가져와서 '또 라인업지야?'라고 느끼실 수 있을 것 같다고 생각한다.하지만 그만큼 해당 프로젝트가 필자로 하여금 수많은 기술적 도전을 통해 한층 더 성장하게 만들어 주었기에, 다양한 문제를 해결하며 얻은 교훈과 성장의 흔적들을 여러 글에 걸쳐 정리해보려고 하는 것이니 이해해 주시면 정말 감사하겠다ㅎㅎ 🥹 그럼 각설하고, AOP 로깅을 적용하게 된 계기를 우선 말씀드리면서 시작하겠다. AOP 로깅의 적용 계기와 기존 로깅 로직의 한계점우리가 보통 로깅을 비즈니스 로직에 적용한다고 하면, @slf4j 어노테이션을 통해 비즈니스 로직에 다음과 같은 코드를 끼워 넣어 다음과 같이 구현한다. 해당 코드..

간단한 토이 프로젝트를 진행하는 도중 마주친 오류이다..🥺무척 간단한 프로젝트여서, Express + JavaScript를 활용해 간단한 REST API를 두어 개 정도 구축하려는 찰나, 다음과 같은 오류를 발견했다..Error: ER_NOT_SUPPORTED_AUTH_MODE: Client does not support authentication protocol requested by server; consider upgrading MySQL client 분명 엔드포인트, 사용자명, 암호 등을 알맞게 입력했는데, 계속 다음과 같은 에러 메세지가 나오면서 접속이 거부되는 것이다.. Express 공식 문서에서는 mysql 모듈을 설치하여 연동하라고 하는데, 연결은 계속 되지 않으니 무척 답답했다. 원인..

Spring Security에 Kotlin DSL을 사용했을 때 빌드가 되지 않는다...Kotlin으로 Spring Security 개발을 하던 중, 공식 문서와 동일한 코드인데 IntelliJ에서는 빌드가 되지 않는 오류가 계속 발생했다.. 코틀린 DSL과 자바와의 가장 큰 차이점을 꼽아보자면,자바는 람다 체이닝 메서드(`.`)을 통해 매개변수를 구현해 주지만,코틀린은 DSL을 통해 매개변수를 구현해 준다는 것이었다.근데 DSL이 대체 무엇일까? DSL(Domain Specific Language)DSL은 도메인 특정 언어, 쉽게 풀어 말하자면 특정 도메인에 국한된 문법이라고 생각하면 된다. 이를 통해 우리는 특정 도메인의 내부 로직 및 메서드를 추상화하여 가독성을 높이고 재사용 및 유지보수성을 높일 ..

관습적으로 개발한 결과물무심코 스프링 부트와 JPA를 통해 개발을 하다 보면, 편리함에 녹아들어 테이블 간 연관관계를 막무가내로 설정하고는 한다.당장 본인도 그랬다..주로 양방향 매핑을 통해 개발하는 이유는 다음과 같다.개발의 편의성을 증진시키기 위해비즈니스 로직을 작성할 때, 양쪽 엔티티에서 원하는 객체를 쉽게 가져올 수 있어서물론 양방향 매핑을 통해, 개발하는 데 있어서 정말 많은 이점을 가져갈 수 있다고 생각했다. 특정 객체와 연관된 객체들을 손쉽게 가져온다거나, 단순 조회를 위해 여러 객체들을 가져올 때 덕분에 시간을 정말 아낄 수 있었다. 그러면 왜 그러한 이점을 버리면서까지 양방향 매핑을 지향한 걸까? 양방향 매핑이 가져다주는 문제점순환 참조만약 두 엔티티가 서로를 참조하게 될 경우, JSON..