분류 전체보기

내 생에서 가장 행복하고 울컥했던 순간을 뽑으라면 올해, 4월 11일이 아닐까 싶다. 이전의 글에서도 한번 적었던 적이 있지만, 나는 수 많은 동아리에 지원했었고 그만큼 떨어졌다. 하지만, 이번에는 나의 노력이 빛을 바랬던 것인지 얍 22기 서버파트에 면접을 볼 기회가 주어져 상당히 떨리는 마음으로 면접을 준비하였다. 참고로 자소서에는 최대한 개발자로서 지향하는 방향과 우선시 하는것, 그리고 얍에서 가장 얻어 가고싶은 것들을 위주로 작성하였다. 우선 제일먼저 했던 것은 이전 기수들의 면접 질문들을 찾아보고 예상 면접 질문 리스트를 만들어 연습하는 것이었다. 평소 지식을 남에게 가공하여 설명하는 것에는 자신이 있었으나, 면접이라고 생각하니 떨리지 않을 수 없었다. 그렇게 4월 15일 면접일이 다가오게 되었..

소개 배경 Description: The dependencies of some of the beans in the application context form a cycle: securityConfig defined in file [C:\BE-Mogakco\mogakco\build\classes\java\main\project\mogakco\global\config\SecurityConfig.class] ↓ OAuth2LoginSuccessHandler defined in file [C:\BE-Mogakco\mogakco\build\classes\java\main\project\mogakco\global\handler\oauth\OAuth2LoginSuccessHandler.class] ┌─────┐ |..

소개배경 현재 구상중인 하루하나 알고리즘은 Github API를 이용하여 하루하나 알고리즘 Repository에 Commit 유무를 판단한다. 이때 UserInfo(실제 API Response값과는 다르나 편의상 칭함)와 Commit 날짜를 Entity 형식으로 가져올 수 있다. 이를 RDB에 저장하여 Markdown형식의 파일로 만드는 작업을 하여 "알고리즘을 풀이한 날짜를 손쉽게 확인"하게 하는 것이 프로젝트의 목적이었다. 현재 해당프로젝트는 Oracle 서버에 CI를 구축하여 자동으로 매일밤 11시 55분에 실행시키는 작업을 구현하였는데 현재는 이슈가 발생하여 Server에서 내린상태이다. 여기서 말하는 이슈란 회원 저장 API의 응답속도가 상당히 느리다고 생각되어 이를 개선한 과정을 포스팅해보려고..

해당 내용은 우아한형제들 기술 블로그를 참고하여, 원글인 Robert C.Martin의 블로그의 내용을 추가하여 작성하였습니다. 의존성 규칙 아키텍처는 다양한 구조가 존재하고 그 구조마다 세부사항은 다르지만, 관심의 분리라는 동일한 목표를 가진다. 그리고 해당 아키텍쳐들은 소프트웨어 계층을 나누어 이러한 분리를 달성한다. 이 조건을 달성하기 위해선 Robert C.Martin은 다음과 같은 5가지를 준수해야 한다고 얘기합니다. 프레임워크와 독립적이어야한다. 아키텍처는 일부 기능이 포함된 소프트웨어 라이브러리의 존재에 의존하지 않는다. 이러한 점은 프레임워크를 도구로서 사용할 수 있게 만들어주며, 종속적이지 않게 만들어준다. 외부요소(UI,DB,Server)와는 별개로 테스트환경이 구성되어있어야한다. UI..

소개 배경 최근 DB에 대해 공부하며, 힌트라는 개념이 약하다고 생각하여, 해당 개념을 정리하고자 포스팅하게 되었다. 우선 DB의 힌트 개념을 알기전 쿼리 실행 계획과, 쿼리 옵티마이저에 대한 개념을 익혀야한다. 쿼리 실행 계획(execution plan) 실행 계획은 DB에서 query를 수행할 때, 어떤 방식으로 데이터를 조회 및 처리할지 나타내는 계획하는 것이다. 이때 실행 계획은 DBMS에 의해 쿼리 옵티마이저가 최적의 방법을 선택하여, 생성한다. 쿼리 옵티마이저(query optimizer) 쿼리 옵티마이저란 쿼리를 처리하는데 있어, 가장 효율적인 방법을 선택하기 위해 여러가지 정보를 고려한다. 해당 정보에는 테이블의 크기, 인덱스의 유무, 통계 정보, 서버 자원 상황 등이 포함된다. 쿼리 옵티..

소개배경 나는 원래 Service Layer에서 비즈니스 로직을 작성할 때, @Transactional(readOnly=true) 설정을 거의 의무적으로 해왔었다. 성능이 향상된다는 것은 알고 있었지만, 해당 원리는 파악하지 못하고 관습적으로 사용하는 것을 지양하고자 포스팅하게 되었다. Annotation @Transactional(readOnly=true) 우선 해당 속성값을 사용할 경우 아래와 같은 이점을 얻을 수 있다고 정의되어 있다. 💡 예상치 못한 엔티티의 등록(insert),변경(update),삭제(drop)을 예방할 수 있고, 또한 성능을 최적화 할 수 있다. 하지만, 우리는 아직 풀지 못한 숙제가 있다. "어떻게 성능이 최적화되는가?" 해당 동작원리에 대해 자세히 이해하기 위해선, 우선 J..

소개 배경 현재 개발중인 프로젝트 모각코에서 간단한 매핑 이슈가 발생하여 소개하고자 포스팅하게 되었다. 기본적인 DB 매핑개념인 1:1, 1:N, N:N에 대한 지식이 동반되면 이해가 빠를 것이다. Trouble(문제 원인) 기본적으로 JPA를 사용할 때 Entity Own(사용하고자 하는 엔티티)와 Entity Geu(Mapping을 해야되는 대상)의 Mapping을 맺을 때 해당 관계의 주인을 지정해주어야한다. 현재 문제가 된 부분은 Ranking 시스템을 구축하던 중 Ranking과 MemberSocial Entity간의 이슈였다. 현재 모각코 중 Timer 서비스에서는 공부 시간을 기록하여 해당 시간(이하 Score)을 전부 초(Sec)로 환산하여 DB에 저장시킨다. Ranking 서비스에서는 T..

소개배경 이번에 Refresh Rotation 전략을 구성하며 상당히 바보 같은 에러를 자초하여 이를 기록하고자 간단하고 짧게 포스팅하게 되었다. 가장 크게 문제가 되었던 것은 RefreshToken으로 새로 발급 받은 AccessToken을 통하여 API의 응답이 이루어지지 않는 이슈였다. Refresh Rotation 로직 자체에 문제가 발생한 것은 아니나, 해당 로직에 관련 부분이 문제를 일으키게 되었다. 혹시라도, Refresh Rotation을 알지 못한다면 나의 블로그에서 JWT를 정리하였던 글 또는 타 블로그를 참조하는 것이 좋을 것같다. Trouble(문제원인) 현재 프로젝트에서 RefreshToken의 용도는 토큰을 재발급 받는 용도로만 사용하게 되었다. 현재 프로젝트에선 Custom F..