DevYGwan

프로젝트를 진행하다보니, 사용자 데이터 조회시 최근 사용자의 데이터를 조회할 일이 많다는 것을 알게 되었습니다. 이를 매번 DB를 통해 조회하는 것보다 캐싱해 조회하는 것이 성능상 이점이 있겠다 라는 생각이 들었습니다. 또한 사용자 데이터는 자주 바뀌지 않기 때문에 캐시를 도입하는게 유리하다고 생각했습니다. 정리하자면, 제가 캐시를 도입한 이유는,최근 사용자 데이터를 조회할 일이 많다. (캐시 히트율이 높다.)사용자 데이터는 수정이 빈번하게 일어나지 않는다.데이터가 손실돼도 큰 서비스 장애를 발생시키지 않는다. (다시 DB에서 가져오면 되기 때문에)입니다. 그렇다면 캐시를 도입했을때의 기대 효과는 어떤게 있을까요? 제가 생각하는 캐시를 도입했을 때의 주 효과는 캐시 히트가 됐을 경우 DB에 접근하지 않고..

코드를 짜다보면 항상 이런 생각이 듭니다. 좋은 코드란 무엇일까? 객체 지향적으로 코드를 짜려면 어떻게 짜는 것이 좋을까? 좋은 코드는 코드의 양이 많아질때 위력을 발휘한다고 생각합니다. 코드의 양이 적고 나 혼자 작업한다면, 사실 단순히 잘 동작하는 코드가 중요하지 좋은 코드를 작성하는 것이 많이 중요하지는 않다고 생각합니다. 하지만 코드의 양이 많아지고 남들과 협업하는 환경에서 단순히 기능만을 위한 코드를 작성한다면 이건 이기적인 마음이라고 생각합니다. 다른 사람이 내가 작성한 코드를 보고 이해하고 코드를 추가 및 수정해야되는데, 코드를 봤을때 해당 코드가 너무 지저분하다면, 코드를 이해하는데 너무 많은 시간을 사용해야 하기 때문입니다. 실제로 내가 코드를 작성하는 것보다 남의 코드를 보고 이해하는..

Spring으로 서버를 개발하는 개발자라면, @Transactional 어노테이션은 많이 익숙할 것이라고 생각합니다. 서비스 로직을 작성할때 대부분 한번에 DB접근으로 끝나는 것이 아닌 여러번의 DB접근을 할 상황이 생기고 이를 한 트랜잭션으로 묶기 위해서 주로 사용하는 것이 @Transactional 어노테이션입니다. 여태까지 이렇게 간단히 한 트랜잭션으로 DB접근을 묶고 싶을때 이 어노테이션을 사용했습니다. 그러다보니 생긴 문제가 있어 이를 공유하려고 합니다. 회사에서 카카오 발신 프로필 제거 로직을 구현하던 도중 제가 처한 문제 상황은 다음과 같습니다. 키 값이 여러개 들어왔을때 이를 제거하는 로직을 구현하는 중입니다. 이때 키 값 각각을 하나의 트랜잭션으로 처리해야합니다. 이를 한 클래스 내에서 ..

프로젝트를 진행하는 동안 외부 API를 사용해본적이 있으실겁니다. Spring에서 외부 API를 사용하기 위한 대표적인 방법은 RestTemplate WebClient ForeignClient 가 있습니다. 하지만, 단순히 외부 API만 사용한다면 큰 문제가 발생할 수 있습니다. 외부 API를 제공하는 서버는 저희가 컨트롤 할 수 없기 때문입니다. 즉, 만약 해당 서버가 문제가 생겨 응답을 못받게 되는 상황이 온다면, 저희 서버도 영향을 미치기 때문입니다. 단순히 해당 서버가 터진다면 외부 API로 사용 시 에러를 반환해 큰 문제가 되진 않습니다. 하지만 만약 에러를 반환하는게 아닌 커넥션을 계속해서 가지고 있다면 이를 동기적으로 처리했을때는 서비스 장애로, 비동기적으로 처리했을때는 리소스 낭비의 문제가..

프로젝트 내에서 유저가 대학생인지 확인하기 위해서 유저 대학생 이메일을 인증하는 로직을 적용하려 했습니다. 이 로직을 적용하기 위해서 실제 대학생 이메일에 인증번호를 보내고 이 인증번호를 확인하는 로직을 구현하였습니다. 구현에 사용한 기술을 간단히 설명하면 Spring Mail Google SMTP 인증 코드 생성 & Redis를 통한 인증 비동기 처리 비동기 에러 처리 정책 (retry & 로깅) 이런 기술을 사용하여 구현하였습니다. 이를 간단히 도식화하면 위의 그림과 같습니다. 이제부터 사용된 기술과 이를 어떻게 적용했는지를 설명하도록 하겠습니다. Google SMTP를 위한 계정 설정은 이에 대한 자료가 많으니 따로 설명을 하진 않겠습니다. Google SMTP를 적용하려면 구글 계정 설정을 추가로..

데이터를 암호화하는 것은 필수적입니다. 특히 요즘 같이 데이터가 곧 힘인 시대에서는 더욱 더 암호화를 신경써서 해야됩니다. 개인정보 보호 뿐만아니라 내가 사용자로써 앱을 사용할때 해당 앱이 데이터가 암호화되어있지 않다면 사용하기 꺼려질 것 같습니다. 만약 악의적인 공격자가 저희 서버의 디비를 탈취하여 디비를 조회했을때 사용자 데이터가 바로 노출되면 큰 문제가 될 것이기 때문입니다. 따라서 이번에 프로젝트를 진행하면서 유저들의 데이터를 제대로 암호화하기 위해 노력했습니다. 처음에는 모든 데이터들을 암호화 처리하였습니다. 그러다보니 모니터링 할때 어떤 유저의 데이터인지 확인하기 어려워 불편했습니다. 따라서 모든 데이터를 암호화하는 것이 아닌 기준을 가지고 암호화를 처리했습니다. 데이터 암호화를 처리한 기준은..

2023.07.03~2023.08.11 약 한 달 반 동안의 다우 인턴 생활이 끝났다. 너무 짧아서 아쉬우면서도 많은 것을 배울 수 있었던 1달 반이었던 것 같다. 처음에는 단순문서 작업과 단순 일 처리만 할 줄 알고 걱정을 많이 했는데 그래도 실제 업무를 경험하게 해 주셔서 좋았던 것 같다. 생각해 보면 팀장님하고 사수님들이 배려를 많이 해준 것 같다. 회사 생활하면서 나의 첫 회사이기 때문에 많은 걱정과 두려움도 있었지만 기대감도 있었다. "내가 주어진 일을 잘할 수 있을까?", "내가 회사 생활을 잘 적응할 수 있을까?" 하는 걱정이 컸다. 더군다나 내가 결국 이 회사를 지원하게 된다면 내가 생활한 1달 반이라는 시간 동안 어떻게 했는지가 많은 영향을 미칠 것 같다는 생각도 들어 더 걱정됐던 것 같..