오류 발생최근에 멀티모듈로 이루어진 프로젝트를 혼자서 연습하면서 특정 모듈을 추가했다가 삭제하였다.근데 계속 build.gradle 파일을 수정해도 Gradle 빌드가 실패하는 것이다..🥺그래서 Gradle 빌드를 새로고침 하려고 하면..이렇게 삭제한 모듈에 대한 빌드가 실패하는 모습을 볼 수 있다. Could not set process working directory to '프로젝트 위치': could not setcwd() (errno 2: No such file or directory) 원인 및 해결방법삭제된 모듈에 대한 캐싱 값들이 아직 프로젝트 구성 경로에 남아 있기 때문에 발생하는 것으로 추측된다. 따라서 .gradle, .idea 두 개의 폴더를 지워준 다음, IDE를 재시작하면 해결된다..

최근에 학교 축제의 주점 입장에 활용되는 원격 웨이팅 서비스를 개발하던 중, 사용자 입장에서 무척 아쉬운 문제를 발견했다. 바로 웨이팅을 신청하는 데 걸리는 시간이 평균적으로 2~3초 정도 걸린다는 것이 그 원인이었다.이를 스프링 이벤트와 비동기 처리를 통해 관심사를 분리시킴으로써 평균적으로 10~30ms 정도 소요되도록 개선하였다. 대략적으로 소요 시간을 약 100배 정도 개선한 것이다! 어떤 부분에서 해당 문제가 대두되었고, 이를 어떻게 해결하였는지 적어보려고 한다. 기존 로직의 문제점기존 로직은 웨이팅 신청, 그리고 알림톡 전송 로직이 강하게(분산 락을 통해) 결합되어 있는 상황이었다. 강하게 결합된 로직들은 단 하나의 로직이 실패하면 트랜잭션 자체가 롤백되어 정합성을 보장한다는 특징을 지닌다. 하..

서버 로직을 개발하다 보면, 분명히 예외 처리를 해야 하는 순간이 다가오고는 한다.이때 우리는 대부분 커스텀 예외처리를 사용하고는 하는데, 필자가 작성한 코드를 참고하자면 다음과 같다.ServiceException.javaExtendedServiceException.java 근데 왜 굳이 이렇게 귀찮게 별도로 커스텀 예외처리를 우리가 따로 명시해주어야 하는 걸까? 커스텀 예외 처리를 사용하는 이유당연하게도, 스프링 부트는 기본적으로 예외가 발생하는 모든 부분에 대해 기본적인 예외 처리를 지원해 준다.그리고 이런 예외가 발생하면 대부분의 백엔드 개발자들은 디버깅과 구글링을 통해 문제의 원인을 파악하고, 예외 발생 지점을 특정 짔고, 고친다. 우리가 백엔드 개발을 희망하여 혼자 프로젝트를 공부하는 거라면, ..