HTTP의 특성 HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜이다HTTP의 가장 큰 특징은 비연결성으로 요청에 대한 응답이 완료되면 서버와 클라이언트 간 연결이 완전히 끊어지며서버는 클라이언트에 대한 정보를 완전 잃게 된다이러한 특징 때문에 서버 단에서는 클라이언트를 알아볼 수 없게 되는데여기서 문제가 발생하게 된다매 요청마다 클라이언트에 대한 정보를 받아야 하게 되는 것이다예를 들어, 네이버 메일을 보낼 때 메일 접속 > 메일 작성 > 메일 전송 의 모든 단계에서 로그인을 새로 해야 할 수도 있는 것이다 이러한 문제를 해결하기 위해 쿠키 라는 개념이 등장하게 된다서버가 클라이언트를 알아볼 수 있도록 요청을 보낼 때마다 클라이언트에 대한 정보가 담긴 데이터 조각을 함께 보내는 것인데이..

난이도별/알고리즘별 문제 조회 기능에 페이지네이션을 추가하면 더 좋을 것 같아서 개발해보도록 하겠당Pagination하면 뭐가 더 좋아?1. 성능 향상: 한 번에 너무 많은 데이터를 로드하지 않으므로 서버나 클라이언트의 메모리 사용을 줄여 성능을 최적화할 수 있음2. 사용자 경험 개선: 페이지를 나누어 보여주면 사용자가 데이터를 더 쉽게 탐색하고, 원하는 정보를 빠르게 찾을 수 있음  그동안은 페이지네이션 구현할 때 JPA의 Pageable을 사용했었는뎅(Pageable 객체가 페이지네이션에 필요한 여러 정보들이 가장 잘 정제되어 있기 때문에 프론트한테 전달해줄 때 가장 적합해서)MyBatis로는 어떤 식으로 구현하면 좋을지 검색을 해봐야겠답  Spring Data - Pageable우어어어억 검색하다보..

하하 이것이(PlanWith) 뭐냐면데브코스 최종 플젝이다...!뒤늦은 회고 시작 😉  PlanWith 간단 소개 및 기능 정리💡 PlanWith : 나의 일정 및 할 일을 나 대신 관리해줄 AI 비서 서비스기능 목록[ 일정과 할 일을 캘린더에서 통합 관리 ]캘린더를 통한 일정과 할 일 관리월별, 주별, 일별 조회 가능[ AI를 활용한 스케줄 기입 자동화 ]AI 챗봇과 대화를 통해 스케줄 자동 분배( ex. 클린코드 20페이지부터 100페이지 까지 이번 주에 읽고 싶은데, 하루 분량 계산해줘 )AI 자연어 처리를 이용해 캘린더에 스케줄 자동 등록( ex. 이번주 일요일 7시에 저녁약속 일정 잡아줘 → 이번주 / 일요일 / 7시 / 저녁 약속 / 일정 )[ 그룹 단위 투두, 일정 관리 ]스터디나 프로젝..

저번 회의 내용 요약로그인 + 문제 리프레시 기능을 위해 쿠키 사용하기로 결정리프레시 버튼 클릭 > 쿠키 확인>> 쿠키 있으면 : GET /problems/refresh로 요청>> 쿠키 없으면 : POST /members/login?handle={백준핸들}로 요청 보내서 사용자로부터 핸들 입력 받은 뒤 쿠키에다가 저장 > GET /problems/refresh로 요청이때 우리 서비스는 프론트엔드와 백엔드가 서로 다른 서버에 배포되어 있고서로 다른 서버끼리 통신하기 위해서는 CORS 설정을 해줘야 함이때 Chrome 브라우저에서쿠키 설정을 SameSite=None, Secure=true로 하면서로 다른 서버에서 쿠키를 주고받을 수 있다다만, Secure=true로 하게 되면 https 통신만을 허가하기 때..

오늘 뀨업 팀원들랑 만나서 로그인 및 문제 리프레시 로직 확인했는데CORS 에러가 났다... 그래숴 WebConfig 클래스를 만들어서 CORS 설정을 했는데@Configurationpublic class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("http://localhost:3000") // 테스트 후 프론트 URL로 변경 예정 .allowedMethods("GET", "POST", "PUT"..

기존 뀨업 서비스의 코드는 JDBC 기반이었다...게다가 서비스 인터페이스 정의 안 하고 냅다 서비스 구현체로 코딩했다...그래서 기능에 대한 수정 회의가 있을 때마다 거의 모든 클래스들 들락날락하면서 코드를 수정했다... 이대론 안 되겠다 싶어서전체적으로 코드 리팩토링을 진행했다!  🔧 리팩토링 방안과 이유 1.  MyBatis로 마이그레이션SQL 쿼리들이 이리저리 흩어져 있고, 커넥션 관리 때문에 코드가 잔뜩 길어져서 수정하기가 빡세다->  도메인별 XML 파일에 SQL문 한꺼번에 관리 가능->  MyBatis의 SQLSession이 커넥션 관리를 대신 해줌 2.  Service Interface 작성기능 구현 방법이 조금씩 계속 수정되고 있기 때문에필요한 역할들을 Service Interface에..