GO SIWOO!

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (9) - 조회 쿼리 성능 개선 [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (8) - JDBC Batch INSERT [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (7) - Ehcache 3 사용 [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (6) - Redis를 통 gosiwoo.tistory.com 📌들어가며 이전 포스팅에서 Members 테이블에 유니크 인덱스, 읽기전용 트랜잭션을 사용하며 조회 쿼리 성능을 향상한 과정에 대해서 설명했습니다. 이번 포스팅에서 OSIV와 DTO를 프로젝트에 적용해본 과정을 간단하게 포스팅 하겠습니다. 📌OSIV 란? OSIV는 Open Session In View의 약자로 영속성 컨텍스트를 뷰 랜더링이 끝날..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (8) - JDBC Batch INSERT [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (7) - Ehcache 3 사용 [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (6) - Redis를 통한 Open API 결과 캐싱(Caching) [리팩토링 일지] 팀 프로젝트, 나홀로 리 gosiwoo.tistory.com 📌들어가며 이전 포스팅에서 대량의 데이터를 JDBC Batch Insert를 통해 프로젝트 실행과 동시에 삽입했습니다. 이번 포스팅에서 300만건의 데이터에서 조회 성능을 개선하는 과정에 대해서 포스팅 하겠습니다. Index 설정, 프로젝션, Native Query, 검색 조건 최적화, 읽기 전용 트랜잭션, 캐싱, 지연 로딩 등등 많은 쿼..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (7) - Ehcache 3 사용 [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (6) - Redis를 통한 Open API 결과 캐싱(Caching) [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (5) - 응답 form & Global Exception [리팩토링 일지] 팀 프로젝트, gosiwoo.tistory.com 📌대량의 데이터를 필요로 한 이유 요즈음 Real MySQL 8.0을 공부하며 Index 설정을 통한 쿼리 최적화를 이루고자 대량의 데이터가 필요했습니다. 우선 Index를 설정할 테이블은 Member, 회원 테이블로 다량의 데이터를 CommanLineRunner를 사용해 프로젝트 시작과 동시에 데이터를 집어넣기로 하였습니다. 📌JD..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (6) - Redis를 통한 Open API 결과 캐싱(Caching) [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (5) - 응답 form & Global Exception [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (4) - 회원기능 구현을 위한 스프링 Security와 JWT발 📌 기존의 회원기능 gosiwoo.tistory.com 📌Redis에서 Ehcache로 이전 포스팅에서 Redis를 사용해 Open API의 부담을 줄이고 응답 속도를 향상했습니다. 하지만 이전에 사용한 방법은 Redis 저장소를 통해 API의 결괏값을 저장해 조회를 하는 방식으로 Redis의 In-memory 구조를 사용한 것일 뿐 캐싱을 사용했다고 확실히 말할 수 ..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (5) - 응답 form & Global Exception [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (4) - 회원기능 구현을 위한 스프링 Security와 JWT발 📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 gosiwoo.tistory.com 📌그래서 Redis를 사용할 것인가? 결론부터 말하자면 해당 프로젝트에서 Redis를 통한 캐싱은 사용하지 않을 예정이다. 많은 고민을 해본 결과 단일 서버에서의 캐싱을 고려했을때 Global cache인 해당 방법을 사용하는 것은 다음과 같은 단점이 있었다. 배포를 했을 때 Redis 서버도 띄워줘야 한다는 비용적인 문제 단일 서버이기에 Cache..

📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 된 API 호출을 보고 적용하지 않고 프론트 팀에서 전달받은 인증 코드를 바탕으로 회원 정보를 HashMap 형태로 (설정파일도 사용하지 않았다) 이를 Controller 단에서 Session으로 저장해 두는 방식을 사용하였는데... @Service public class KakaoAPI { public String getAccessToken(String authorize_code) { String access_Token = ""; String refresh_Token = ""; String reqURL = "https://kauth.kakao.com/oauth/token"; try { URL url ..

📌 기존의 프로젝트는? 팀 프로젝트를 처음부터 뜯어고쳐 리팩토링을 진행하기 위해서는 기존의 프로젝트의 DB 스키마와 작성한 API 명세를 파악해야만 했다. 캡스톤 디자인 과목을 통해 진행했던 만큼 프로젝트 보고서가 있어 DB 스키마와 구현 기능들의 파악은 어렵지 않았지만 API의 명세는 없어 하나하나 코드를 볼 수밖에 없었다. 📌 DB 스키마와 Entity 아래는 기존 팀프로젝트의 DB 스키마이다, 빨간색은 PK, 파란색은 FK로 표현되어 있다. 아래의 DB 스키마의 표현법도 다소 이상하다... 1 : N의 관계를 올바르게 표시하지 못했고 user 테이블, openDic 테이블, vocabularyNote 테이블 3개의 연관관계를 지니는 1 : N : M의 복잡한 구조도 띄고 있다. (이는 리팩토링을 통..

📌 리팩토링 이유 약 1년간 대학 동기들과 한국어 학습 웹 어플리케이션 웹 서비스 프로젝트를 진행한 적이 있다. 해당 프로젝트는 표준 국어 대사전 API와 Kakao 로그인 API, OpenAPI를 사용해 단어, 문장, 음성 한국어 검색, 사용자만의 단어장, 단어 퀴즈, 랭킹, 오픈사전등의 기능을 제공하는 프로젝트였다. 해당 프로젝트를 통해 공모전에서 은상 교내 대회에서 은상을 타기도 하는 등 많은 성과를 이루었지만 다음과 같은 곳에서 부족함을 느끼고 이 프로젝트를 내 힘으로 완벽히 리팩토링을 하고 싶었다. 1. Git/Github등 협업툴의 사용법과 관리 미숙 버전/이슈의 관리가 메신저로 이루어져 매우 힘들었다. 프로젝트의 결과물을 명확히 확인을 할 수 없었다. 2. 프로젝트 진행 중 mapper 사용..