코딩은 마라톤

중간지점 찾기 서비스인 모이삼에서는 중간지점 산출 및 출발지에서 중간지점까지의 상세 경로를 알려준다.https://www.moisam.kr/ 모이삼최적의 중간장소 찾기, 약속장소 추천www.moisam.kr 중간지점은 최대 3개까지 산출되며, 출발지마다 경로를 보여주는 만큼, 응답 데이터의 크기는 중간지점 수와 출발지 수에 비례한다.그래서 모이삼은 응답 시간을 줄이기 위해 응답 데이터 캐싱과 멀티 스레드를 사용해 외부 API에서 경로를 가져오는 등 여러 처리를 진행했다. 위 과정을 통해 비약적으로 속도 개선을 이뤘지만, 응답 데이터의 크기는 줄이지 못했다. 줄일 수 있는 방법을 찾아보던 와중, 응답 데이터를 압축할 수 있는 포맷인 gzip을 알게 되었다. 🏠 gzip이란?gzip은 파일 압축 및 압축 ..

중간 지점 추천 서비스인 SPOT(스팟)은 에러 발생 시, 팀에서 어떤 에러인지 문의가 들어오고 이때 터미널에 들어가 로그를 확인했다.다만, 아직 미흡한 로깅 처리와 에러 추적에 대한 시스템을 마련해두지 않아서 매번 예외 로그만 확인하는데 시간이 꽤 걸렸다. 팀 SPOT은 디스코드를 협업 툴로 사용하고 있고, 디스코드 웹훅을 이용해 에러 발생 시 신속하게 대응할 수 있을 것으로 판단하여 스팟-에러 알림 채널을 만들었다. 웹훅을 어떻게 연동하고 처리하는지 알아보자! 1. 디스코드 웹훅 생성하기 디스코드 알림 채널을 만들고, 서버 설정 -> 연동을 통해 웹훅을 만들 수 있다.웹훅을 만들고 연결할 알림 채널과 이름을 설정하고 웹후크 URL을 복사한다. 웹훅 URL에 요청을 보내 디스코드에 알림을 보내는 방식..

시작에 앞서,애플리케이션 코드를 개발할 때는 명령형(imperative)과 리액티브(reactive, 반응형)의 두 가지 형태로 코드를 작성할 수 있다.명령형 코드순차적으로 연속되는 작업, 각 작업은 한 번에 하나씩 그리고 이전 작업 다음에 실행된다.데이터는 모아서 처리되고 이전 작업이 데이터 처리를 끝낸 후에 다음 작업으로 넘어간다.리액티브 코드데이터 처리를 위해 일련의 작업들이 정의되지만, 이 작업들은 병렬로 실행될 수 있다.각 작업은 부분 집합의 데이터를 처리할 수 있으며, 처리가 끝난 데이터를 다음 작업에 넘겨주고 다른 부분 집합의 데이터로 계속 작업할 수 있다.리액티브 프로그래밍 이해하기리액티브 프로그래밍은 명령형 프로그래밍의 대안이 되는 패러다임이다.명령형 프로그래밍의 문제작업이 수행되는 동안..

진행 중인 프로젝트에서 최근 ChatGPT를 연동해서 응답을 받아와야할 상황이 생겼습니다.OpenAI Java SpringBoot 라이브러리도 있기는 하지만 (https://github.com/TheoKanning/openai-java?tab=readme-ov-file)라이브러리보다 직접 구현하는게 나중에 API 명세가 바뀌더라도 변경하는데 용이하지 않을까 해서 구현해보았습니다! RestClient와 WebClient를 사용하여 구현할 수 있는데 저는 WebClient를 사용하였습니다!* 추후 RestClient와 WebClient에 관한 블로그도 올릴게요! 1. OpenAI API 요청과 응답 확인하기Create Chat Completion API를 사용하였습니다! (참고: https://platfor..

요새 인프런에서 토비의 스프링부트 이해와 원리를 듣고 있는데 내가 스프링부트로 개발을 하고 있지만 서블릿, 디스패처 서블릿, 스프링 컨테이너, 빈 등에 대해 잘 모른다는 것을 알게 되었다.그중 서블릿과 서블릿 컨테이너는 거의 아는게 없었기 때문에 이번 기회에 정리하고자 한다. 서블릿 (Servlet)서블릿이란 무엇일까?서블릿에 대해 알아보기 전에 웹 서버, 웹 애플리케이션 서버(WAS)를 알아봅시다.  웹 서버 (Web Server)웹사이트를 제공할 수 있게 서버로 만들어주는 서비스클라이언트가 특정 주소를 입력 시 특정 화면을 브라우저에서 출력해주는 역할정적인 웹 사이트를 제공웹 애플리케이션 서버 (Web Application Server)자바, JSP 등으로 만든 웹 또는 API 애플리케이션을 실행할 ..

학습하게 된 계기지금 하고 있는 프로젝트가 기능 구현은 다 끝났지만, 인증과 관련해서 액세스 토큰만 사용하기 때문에 짧은 유효시간으로 잦은 로그인이 발생했다. 그래서 리프레시 토큰을 추가해서 안정성을 높이고자 했는데,,  모든 에러를 처리해줬음에도,,  500 에러만 계속 떠서 무슨 이유에서 에러가 발생하는지 알 수 없었다.. 그 이유를 최근에서야 알게 됐는데 바로 Filter 때문이었다. 필터에서 내가 커스텀한 ServiceException이 발생 시 에러 메시지를 보내고, 그 외에 모든 에러는 500 서버 에러를 보낸다. 하지만 ServiceException은 거진 Service 레이어에서 발생하기 때문에 필터에서 디스패처 서블릿으로 넘어간 후 에러가 발생하여 필터에서 catch하지 못하는 상황이었다..

이전 게시물에서도 작성했지만 나는 4월 5일 회사 면접을 보았다.면접 중에 면접관님께서 물으셨다.면접관님 : request dto에서 @Getter를 쓴 이유가 뭐예요? 프론트에서 request 요청을 서버에서 어떻게 받는지 과정을 알아요?나 : 음.. Entity 클래스에서 request를 가지고 Entity 객체를 생성하는데 이때 request dto의 필드는 private로 되어있기 때문에 @Getter를 통해 가져오려고 하였습니다 !면접관님 :  프론트에서 request 요청을 서버에서 어떻게 받는지, @Getter는 왜 사용하는지 공부해보면 좋을 거 같아요.이렇게 면접관님께서 학습할 부분을 알려주셔서 dto에서 왜 @Getter를 사용하는지, 프론트에서 주는 요청을 어떻게 서버에서 받는지 찾아 ..