집짓기 대신 개발

최신버전의 Spring Boot와 Hibernate버전을 사용하여 Native 컴포넌트를 빌드하면서 알 수 없는 버그를 만났습니다.. Hibernate의 Lazy 로딩에 대한 스펙이 변경 되면서 발생한 이슈인데요 현재기준 (6.4.4.Final) 버전에서 발생하고 있습니다. Hibernate가 6.2버전으로 올라가면서 enhancement 설정을 deprecated시키고 항상 byte Laze 코드를 생성하도록 만드는 설정인데요, 해당 설정이 정상적으로 적용이 안되었는지 적용이 충돌이 발생하는 이슈가 있습니다. 이때 겪었던 트러블 슈팅을 했던 과정을 간단하게 공유하고자 합니다. (무한 반복의 굴레...) 이 사건의 발단은 Spring Boot 버전을 최신버전으로 업데이트하면서 발생했습니다.. Spring..

API는 서버 - 서버 또는 서버 - 클라이언트, 클라이언트 - 클라이언트 간 정보를 요청하고 전달하는데 목적을 가지고 있는데 목적을 가지고 있습니다. 풀어서 Application Programming Interface 이라고 합니다. 소프트웨어에서는 다양한 곳에서 다양한 뜻으로 사용되지만 해당 글에서는 Backend에서 제공하는 인터페이스에 대해서 이야기하려고 합니다. 해당 글에서는 Rest와 GraphQL의 깊은 이야기는 배제하고 각각의 장단점과 언제 쓰이면 좋을지에 대해 기술합니다. 주관적인 요소가 많이 들어가 있어 상황에 따라 유연하게 사용하시기를 권장드립니다! Rest API 장점 리소스를 중심으로 설계되어 있어 계층구조를 파악하고 연관관계를 알기 쉽습니다. 정해진 규칙에 대한 Response만..

DB의 테이블을 설계하면서 ID를 생성할때 일반적으로 두 가지 선택권이 존재합니다. UUID를 이용하는 방법과 DB의 Increase Number를 활용하는 방법입니다. 우선 두 가지 방법에 대해 간단하게 소개해 드리겠습니다! UUID (= Universally Unique Identifier)는 여러 버전이 존재하는데요, 일반적으로 V4를 많이 사용합니다. 이유는 Random을 이용해 생성되기 때문입니다. 총 128bit로 구성되며 Dash를 포함하여 36자의 string으로 표현됩니다. V1과 V2는 Mac Address가 포함되어 있는데 이는 서버 자체 보안이 중요할 경우 서버의 Mac Address가 탈취될 위험이 있다고 합니다. 또한 Timestamp도 포함되어 있지만 비트단위로 쪼개져 정렬은 ..

SNS 로그인을 백엔드에서 검증하는 방법은 2가지가 존재합니다. 오늘은 그 중 하나인 OpenID Connect 규격의 Id Token을 활용하는 방법을 간단하게 정리해보려고 합니다. 먼저 OpenId에 대해 이해하고 넘어갈 필요가 있습니다. 외부 서비스의 계정을 이용한 통합 인증 시스템인 OAuth 제정되고 현재까지 다양한 표준들이 제정되었습니다. 그중 OAuth2.0의 확장 표준?에는 OpenID Connect라는 표준이 존재합니다. 간략하게 소개하면 JWT를 기반으로 하며 JWT내에는 사용자의 여러 정보를 담아서 공개하게 됩니다. 이런 Token은 우리에게 IdToken이라는 이름으로 제공되게 됩니다. SNS 로그인을 연동하면 제공되는 Jwt 형식의 IdToken이 바로 이 OpenID Connec..

Unit Test를 진행하다 보면 다양한 문제에 봉착하게 되는데 가장 해결하기 힘든 문제 중 하나가 외부 DB와의 연결이 아닌가 싶습니다. 우리는 CI를 통해 배포를 수행하며 자동 테스트를 하는데 외부 DB와 연결하는데 애로사항이 생기기 마련이기 때문입니다. 개발 DB나 운영 DB나 마찬가지로 우리는 보안상 문제로 외부에서 접속을 못하도록 내부망에서만 접속이 가능하게 설정합니다. 이때 문제는 빌드를 수행할 환경이 내부망에 없다면 우리는 자동 테스트 과정에서 DB접속 문제를 해결해야 합니다. 이때 우리는 Mocking을 이용해 Repository를 새로 주입하는 등 여러 대안을 사용하지만 Entity가 많아 지고 데이터가 쌓이다 보면 극악의 생산성을 보여주기 시작합니다. 그래서 이런 문제를 해결하기 위해 ..

Spring boot를 쓰면서 API Document를 팀내에 전파할 방법을 고민중에 Asciidoctor를 이용한 방법이 있어 도입하게 됐습니다. 간단한 도입 방법과 사용법을 정리해보려 합니다. 스웨거를 사용할 수 도 있지만 스웨거의 경우 어노테이션으로 코드 전체를 오염시켜야하는 치명적인 단점이 존재하여 선택하지 않았습니다. Rest API Doc은 MvcTest를 이용하여 작성하기 때문에 기존 코드를 오염시키지도 않고 테스트를 강제하여 정확한 결과를 표현할 수 있다는 장점도 있습니다. 하지만 기본적인 문서작업과 정리해줄 문서 포맷을 작성해야하는 점이 있어 완벽한 자동화라고 말하기에는 부족하지 않나라는 생각도 들었습니다. (아직 사용이 미숙하여 그렇게 느낄 수도 있습니다!) apply plugin: "..

팀을 초기에 세팅할때 유닛 테스트 관련 컨벤션을 꾸리는데 여러 고민에 빠지게 됩니다.. 유닛테스트의 범위와 규모 TDD를 중심으로 할 것인가? 일반 유닛테스트와 통합테스트만을 중심으로 개발할 것인가? 여러 고민을 하게 됩니다. 해당 글은 이런 고민 속에서 테스트 커버리지를 어떤 방식으로 확인 하는지에 대한 글입니다. JaCoco를 활용하여 간단하게 테스트 커버리지를 확인하는 방법을 알아보고 이를 통해 팀의 컨벤션을 확보하는데 도움이 되길 빕니다! 우선 JaCoco에 대해 간략히 소개드리면 Java기반 언어를 분석하여 테스트 코드가 커버하는 코드 블락을 확인 후 커버리지 퍼센트를 도출해 주는 도구입니다. 물론 그외에 다양한 기능을 제공하기 때문에 해당 글을 보고 찾아보시면 많은 도움을 받을 수 있습니다. ..

Spring 프로젝트를 진행하면서 Query DSL을 언제 도입할지에 대해 고민하던 중 좋은 타이밍이라 생각하여 도입했습니다. 내가 QueryDSL을 도입한 이유와 타이밍에 대해서 간략하게 정리하여 경험을 공유하고 합니다. QueryDSL은 프로젝트 초기에 바로 도입하여 사용하는걸 권장하지만 현재 회사의 프로젝트를 시작하면서 최소한의 툴을 사용하면서 정말 필요할때 도입하고자 목표를 잡았었습니다. 본론으로 들어가기 전에 QueryDSL에 대해 간략하게 소개하고자 합니다. QueryDSL이란? QueryDSL은 Query 빌더로 조금 더 정확하게는 Jpa의 JPQL을 만들어주는 빌더입니다. 보통 Jpa Repository에서 자동으로 만들어주는 매핑 메소드를 생성하기 어렵거나 복잡한 상황에서 쿼리를 작성하고..

Spring Boot 프로젝트에서 JPA를 사용하면 Repository를 통해 DB의 데이터를 꺼내오게 된다. JPA가 지원하는 기본적인 Repository는 다양한 기능을 함께 지원하지만 규모가 커지고 복잡한 쿼리가 필요할때는 한계에 부딪히게 된다. 이럴때 개발자가 자체적으로 Repository를 만들어서 커스텀해 사용해야 하는데 이를 위한 두 가지 방법을 소개하려 한다. 1. 기본 Repository에 Interface를 추가하여 확장하는 방법 2. 기본 Repository와 별개의 Repository생성하는 방법 1. 추가 Interface를 통해 Repository 확장 - 기존 JpaRepostory에 CustomRepo를 추가해준다. public interface ConsultationRepo..

JPA를 이용해 구현을 하다보면 그래프 탐색을 통해 다양한 테이블을 탐색하게 된다. 하지만 객체를 기반으로 구현돼있는 JPA는 자칫 잘못하면 불필요한 집단 쿼리(n + 1)가 발생해 성능에 악영향을 줄 가능성이 매우 높다. 나 또한 이런 문제를 격었기 때문에 그 경험을 공유하려한다. 해당 포스트가 N+1문제 해결을 설명하려는 글은 아니며, 연관된 문제에서 조금 더 유연한 대처를 하는 방법을 소개하려한다. 내가 만난 문제는 고객, 판매자(Account) 테이블과 결제(Payment) 테이블 2가지가 존재했다. 이런 환경에서 판매자가 가지고있는 결제들을 불러오고 결제한 구매자(고객)의 데이터를 함께 List로 return해주는 문제를 해결해야 했다. 처음 작성한 코드는 다음과 같다. //@Query("sel..