본문 바로가기

분류 전체보기

 (94)
11월 26일 회고 Keep - 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점Keep1 - JVM 공부 프리코스에서 자바에 대한 기본기가 많이 부족하다는 것을 느꼈다. List, Collection, equals 등의 개념이 대표적이었는데, 내가 무언가를 잘 알지 않는 상태에서 사용하는 것은 프로그램에 좋지 않은 영향을 미칠 것이라 생각했다.  자바에 대해 깊게 알아야 Spring 을 더 잘 할 수 있다고 생각해 JVM 에 대해 공부했다. JVM 을 공부하며 자바 프로그램의 실행 과정, 실행 중 동작, GC 의 수행 과정을 알 수 있었다. 아직 JVM 을 전부 공부한 것은 아니다. JVM 은 생각보다 복잡하고 어려운 개념이었다.  JVM 을 계속해서 공부하며 순수 자바에 대한 이해도를 쌓아가고자 마음먹었다.  Keep2 -..
7기 프리코스 4주차 회고 (KPT 회고) Keep - 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점Keep1 - VO 사용 VO 를 사용하며 원시값을 포장함과 동시에 해당 값만의 역할을 분리할 수 있었다. 처음 VO 를 접했을 때에는 원시값을 클래스로 한번 더 포장하는 것을 잘 이해할 수 없었지만, 직접 사용해보고 장점과 단점을 분석해보니 VO 를 사용하는 것이 더 좋은 방법이라는 결론을 내릴 수 있었다. VO 의 장점1. 자료형에 의미를 부여할 수 있다. - 자료형이 의미 있는 이름을 가지게 되기 때문이다.2. 타입 안정성을 높일 수 있다. - 같은 int 자료형이더라도, 각각의 VO 로 다루게 되면 검증이 적절히 수행되기 때문이다.3. 최소한의 데이터 검증의 책임을 분리할 수 있다. - VO 내부에서 검증을 수행하기 때문이다. VO 의 단점..
7기 프리코스 3주차 회고 (KPT 회고) 3주차 프리코스를 진행하는 과정에서 내가 올바른 방식으로 회고를 하고 있는지에 대한 의문이 들었다.  지금까지 나는 회고를 위해 메타인지를 하는 과정에서 내가 안다고 생각했던 것과 고민했던 점들, 의사결정 이유만을 정리하고 있었다.  이것들을 정리하는 과정에서 앞으로의 계획이나 내가 부족했던 점을 잘 정리하고 있지 않은 것 같다는 생각이 들어 우선 "회고" 란 무엇인지 찾아보기로 마음먹었다.  회고란?지난 일을 순서대로 정리하고, 방식을 복기하면서 아쉬운 점과 앞으로 적용할 수 있는 점들을 기록하는 것.  제대로 된 회고를 하기 위해 나는 KPT 회고 템플릿을 사용해 회고록을 작성하기로 마음먹었다.KPT 회고 템플릿이란?Keep : 잘하고 있는 점. 계속 했으면 좋겠다 싶은 점.Problem : 뭔가 문..
7기 프리코스 2주차 회고 평소 제대로 알고 사용하고 있는 개념이 많지 않다는 사실에 놀랐다. 그동안 프로젝트를 완성하는 것에만 집중하고, 기본기에는 소홀했다는 점을 깨닫고 반성하는 시간을 가질 수 있었다.  안다고 생각했던 것과 몰랐던 것1.  방어적 복사 - List.copyOf() 와 Collections.unmodifiableList() 이 부분은 글을 하나 새로 써야 할 정도로 양이 많다. 알고 있던 개념1. 방어적 복사는 복사본을 만들어 반환하는 것이다.2. List.copyOf() , Collections.unmodifiableList() 를 사용하면, 방어적 복사가 수행되면서, 복사본 List 를 수정할 수 없게 만든다.    몰랐던 개념 지금까지 List.copyOf() 와 Collections.unmodifiab..
7기 프리코스 1주차 회고(알고 있다고 생각했던 것들) 1주차 프리코스를 진행하며 아는 것과 모르는 것을 구분하는 법을 배울 수 있었다.평소 알고 있다고 생각하고 사용했던 개념들에 대해 꼬리질문을 하니 대답할 수 없던 경우가 많았다. 과제를 진행함에 있어 내가 알고 있다고 생각했지만, 몰랐던 것들에 대해 정리를 해 보고자 한다.    1. 자바의 record 클래스알고 있던 개념1. record 는 단순히 값을 저장하는 용도의 클래스가 필요할 때 사용하는 클래스 타입이라는 점.2. 내부 변수를 얻기 위해선(get), 변수명과 동일한 메서드로 접근하면 된다는 것(ex. record.value()).  더 조사하게 된 계기1. 불변 객체를 만들기 위해 record 클래스를 만들고, 변수에 private final 을 붙였다. 하지만, 문법 오류가 발생했다. 2...
Redis 캐싱만 적용하면 끝일까? - Resilience4j 를 통한 Circuit Breaker 적용 Redis를 사용해 응답 데이터를 캐싱했다고 가정해 보자. Redis의 TTL  동안 오는 모든 요청은 Redis와 통신해야 한다.  Look - Aside 패턴을 사용해 캐싱했다고 가정해 보자. 요청을 받은 애플리케이션은 우선 Redis에 해당 데이터가 존재하는지 확인해야 한다. 존재한다면 Redis의 데이터를 반환할 것이고, 존재하지 않는다면 DB에서 직접 값을 읽은 후, Redis에 삽입한 후, 반환할 것이다.  그렇다면.. 만약 Redis에서 장애가 발생해 Redis와 연결이 끊기면 어떻게 될까? Redis에 연결할 수 없으므로, 별다른 처리가 없다면 500 Internal Server Error 가 발생할 것이다.이는 모놀리식 아키텍처에서도 문제이지만, MSA에서는 더 큰 문제이다. 더보기왜 M..
Spring Boot에서 Redis를 활용해 데이터 캐싱하기(feat. Look Aside) 캐시는 자주 사용되는 데이터를 미리 복사해 저장하는 임시 저장소이다. 다음과 같은 상황에서 캐시를 사용할 수 있다. 같은 데이터에 반복적으로 접근하는 상황동시에, 해당 데이터의 변경이 적은 상황캐시를 구현하기 위해 Redis가 많이 사용된다. 그 이유는 다음과 같다.Redis는 In memory 데이터베이스로, Key, Value 쌍을 저장하는 일종의 NoSQL DB이다. In memory 데이터베이스이므로, 하드 디스트에 데이터를 저장하는 일반적인 데이터베이스보다 속도가 월등히 빠르다. 물론, 단점도 있다. 접근 속도에 대한 Trade Off로 비싸다. 비싸다는 것은, 용량이 적다는 것을 나타낸다. 따라서, 많은 데이터를 Redis에 저장하기엔 한계가 있다. 캐싱을 잘 사용하면 특정 상황에서 애플리케이..
캐싱, 개념과 읽기 전략들 다음과 같은 상황을 가정해보자. 상품 판매 서비스를 개발하고 있다.상품 조회 API를 개발하고 있는데, 상품의 정보는 거의 바뀌지 않지만, 매 요청마다 DBMS에 쿼리를 날려 다시 조회하고 있다. 이 상황의 문제점은 다음과 같다. 변경 빈도가 매우 낮은 데이터를 얻기 위해 매번 DB에 쿼리를 보내 애플리케이션의 성능이 떨어지고 있다! 이것이 왜 문제일까? 1. DBMS는 기본적으로 Disk에 데이터를 저장한다. Disk는 용량은 크지만, 접근 시간이 느리다는 단점이 있다.2. 상품 데이터가 100만개라고 가정하면, 매 조회마다 Disk에 접근해야 한다.3. 매번 DBMS에 쿼리를 날리지만, 응답 데이터는 거의 항상 똑같다.  이 비효율성을 해결하기 위해 똑똑한 사람들이 한 가지 방법을 생각해냈다. 변경이..
조금 많이 늦은 11기 마무리와 12기 운영진 시작 11기에서 활동하며 "개발"이라는 것을 처음 접했다. 쉬운 알고리즘 문제나, 심심풀이로 구현을 해 보는 게 전부였던 나에게 11기 활동은 정말 큰 행운이었다. 웹 개발을 처음 접하고, 백엔드 개발도 처음 접했다. 아무것도 모르는 상태에서 시작했기에 세션을 따라가기 힘들었지만, 개발이 즐거웠기에 버틸 수 있었다. 해커톤을 하며 나보다 뛰어난 팀원과의 소통도 경험해 볼 수 있었고, 스스로에 대한 부족함도 많이 느꼈다.해커톤 당시에는 자괴감이 많이 들었다. 지금도 마찬가지지만, 세상은 매우 넓고 나보다 뛰어난 사람은 널렸다...이 자괴감은 곧 지식에 대한 갈증으로 변화되었다. 해커톤이 끝나고, 진정한 방학이 시작되었지만, 해커톤 코드를 리팩터링하고 부가적인 기능을 계속해서 추가하며 스스로 공부하기 시작했다...
Interceptor를 활용한 JWT 토큰 검증 인증, 인가를 위해 매 요청마다 JWT를 검사해야 한다.하지만, 이 과정을 비즈니스 로직 내부로 가져오기엔 무리가 있다. 인증, 인가는 비즈니스 로직의 책임이 아니다. 비즈니스 로직을 구현하는 객체는 자신의 책임에만 집중해야 한다.유지보수성이 좋지 않다. Util Class로 분리해도, 결국 Service들은 해당 Util Class에 의존해야 하기 때문이다. 즉, Class 간 결합도가 높아진다. 인증, 인가를 비즈니스 로직에서 빼내보자.Controller에 요청이 도착하기 전에 인증, 인가가 수행할 것이다.Controller 앞에서 구현하면 다음과 같은 이점을 가질 수 있다. 모든 요청이 Controller에 도달하기 전에 인증과 인가가 처리되므로, 인증되지 않은 접근이나 권한이 없는 요청을 사전에 ..

티스토리툴바