집짓기 대신 개발

최신버전의 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도 포함되어 있지만 비트단위로 쪼개져 정렬은 ..

많은 개발자들은 개발을 시작하고 성장하면서 아키텍처에 대해 여러 방면으로 고민하고 나만의 방법을 찾아 나가기 시작합니다. 저는 이런 성장 과정에서 여러 성장통을 겪었는데 그때 느꼈던 점을 정리해보려고 합니다! 아키텍처를 처음 공부하고 배워나갈때 정답은 없지만 최소한 베스트는 있다는 생각으로 접근을 했었습니다. 이런 접근법은 지금 생각해보면 좋은 접근법은 아닌 것 같지만 그래도 저한테는 빠르게 나의 아키텍처를 찾는데는 도움을 주었습니다. 이런 아키텍처의 접근방식을 통해 다른 팀은 어떻게 아키텍처를 쌓아나가는지 그리고 DDD와 같은 설계 철학은 어떤 이야기를 하고 있는지 깊게 고민하고 공부하는 계기가 되게 해주었습니다. 이 과정에서 겪은 성장통은 결국 아키텍처는 정답도 없고 베스트도 없다는 생각이였습니다. ..

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

어플리케이션(서비스)의 본질은 무엇일까? * 서비스: 해당 글에서는 Web / Mobile 등에서 사용하는 Application을 지칭합니다. 사용자는 서비스를 사용할 때 어떤 행위를 할까요? 사용자는 서비스을 사용하면서 다양한 행동을 취합니다. 회원가입을 수행하고 게시글을 등록하기도 하며 다른 사람과 친구를 맺어 채팅을 하기도 합니다. 사용자의 이런 행동들은 어떤 결과를 만들고 우리는 왜 가치있다고 여길까요? 이런 행위를 통해서 사용자들은 자신만의 데이터를 생성해나가기 때문입니다. 이런 정보들이 나만을 위한 편리함을 제공할 때 사용자는 내가 사용하고 있는 서비스가 가치있다고 생각합니다. 결국 서비스는 사용자들의 입맛에 맞게 데이터를 생성하고 이용하는데 본질을 두고 있다고 말할 수 있습니다. 따라서 서비..

많은 개발자들이 성장을 갈구하고 성장하기 위해 공부를 이어나갑니다. 새로 공부한 내용을 써보기도 하고 더 좋은 구조를 만들기 위해 상당기간 고민하기도 합니다. 이런 경험들이 쌓이다 보니 항상 경계하게 되는 점들이 있습니다. 우리는 새로운 기술에 대해 항상 받아들이고 흡수해야한다는 강박이 있는지 생각해봐야합니다. 주변을 관찰하다 보면 주니어에 가까울 수록 이런 생각을 많이 하시는 것 같습니다. 새로운 기술을 배우고 도입해야 성장한다? 새로운 기술을 접하고 공부하다 보면 해당 기술에 대한 장점들에 매력을 느끼고 빠져들게 됩니다. 그러다 보면 시야가 좁아지고 반드시 필요한지에 대한 판단은 나중으로 미뤄버리게 됩니다. 그러면서 아, 나는 한 단계 더 성장했다는 착각에 빠집니다. 새로운 기술을 배웠고 도입도 해봤..

Service를 구현할때 Interface를 써야할까? Spring을 사용하다 보면 많은 서적과 안내서에 Interface를 이용하여 Service를 구현하도록 설명합니다. 하지만 왜 Interface를 활용해야하는지에 대해 자세하게 설명하는 경우는 못 본 것 같습니다. 그래서 생각없이 Interface를 사용하여 Service를 구현하는 케이스를 종종보게 됩니다. 우리는 여기서 고민해야하는 지점은 Service를 구현할 때 Interface를 써야하는가 그리고 왜 사용해야 하는가입니다. 해당 내용은 제 생각으로 정답이 아니며 각자의 철학과 사고를 바탕으로 판단해야합니다. 저는 Service를 구현할때 interface를 써야할까 라는 질문은 No라고 말하고 싶습니다. 먼저 Interface를 사용하는 ..

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

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