1. 알고리즘리트 코드 [https://leetcode.com/problems/knight-probability-in-chessboard/description/] 리트 코드 [https://leetcode.com/problems/find-in-mountain-array/description/2. 백엔드 팀원 모집 글 전송[https://github.com/huhdy32/solved-rank]3. 단일 문제 저장 기능 구현[https://github.com/huhdy32/solved-rank]4. 이력서 작성 ( 표준화된 방식 )

꾸준해야한다는 강박에서 벗어나 순간순간에 집중하도록 한다. 꾸준해야한다는 말에 매몰되어 하루를 놓쳤을때 이 실패감이 다음날, 다다음날에까지 영향을 미친다.이 대신, 매일매일 계획을 세우고 순간순간에 집중하도록 한다. 시작은 지금 당장. 이제부터의 계획은 다음과 같다. 1. 매일 아침 8시, 하루의 계획을 블로그에 작성한다. 2. 매일 저녁 9시, 하루동안 학습한 내용을 블로그에 작성한다.3. 매일 저녁 10시, 해당 진행정도를 블로그에 작성 한다. 4. 안산학생 데일리 인증에 내 블로그 링크를 작성한다. 하루 실패해도 괜찮다. 하루의 시작을 전날의 실패감으로 시작하는 대신, 매일 아침 위 목록을 지키는데서 하루의 의미를 찾자.

캐시란?캐시란, 데이터 접근속도를 높이기 위해 원본 데이터를 복사하여 미리 저장해두는것을 의미한다.메모리 Hireachy에 따라, 상단으로 올라갈수록 접근 속도가 높은 대신 저장공간이 작으며, 하단으로 내려갈수록 속도가 낮은 대신 저장공간이 크다. 원본 데이터는 일반적으로 보조 기억 장치 레벨에 저장되며, 이에따라 접근 속도는 현저히 떨어진다. 캐시는 보조 기억 장치에 저장되는 데이터들을 메모리 레벨에 미리 저장해둠으로써 응답속도를 비약적으로 개선한다.하지만, 다음과 같은 세가지 쟁점이 뒤따른다.캐시 저장 데이터캐싱을 사용함으로써 빠른 접근속도를 가지는 대신, 작은 저장공간을 가진다.따라서, 어떤 데이터를, 얼마나, 어떻게 저장할지 고민해야한다.데이터 불일치원본 데이터를 복사하여 저장됨에 따라, 캐시에..

이번 포스팅에선, 한편의 수학 질문 게시판 성능 최적화 과정을 어떻게 이뤄냈는지 설명한다.1. 문제점 파악질문 게시판 기능뿐만 아니라 어플리케이션의 모든 기능들은 모놀리식 아키텍쳐로 구성됐다.200명 정도의 사용자임에 따라 문제가 없을거라 예상했지만, 게시판 동시 조회 시 응답속도가 현저히 낮아지는 문제가 발생했다.파악된 문제점들은 다음과 같았다.1. 조회수 락으로 인한 응답속도 저하조회수는 실시간성이 중요한 데이터 도메인이다.사용자는 자신의 조회수가 실시간으로 반영되어 있지 않다면, 사용감에 부정적인 영향을 줄 수 있다.또한 동시접근이 빈번함에 따라, race Condition이 빈번히 발생할 가능성이 존재한다.기존 모놀리식 어플리케이션에선 Row Level Lock ( X-LOCK )을 통해 race..

🙈 1. 문제 파악API 구성에는 인증과 인가가 항상 뒷따르게 됩니다.이와 관련된 보안 로직은 필수적이지만, API 응답을 직접적으로 테스트하려면, 인증과 인가 로직을 테스트 시 불필요하게 포함하지 않고, 원하는 로직만 검증하는 것이 중요합니다.기존에는 보안 관련 로직이 중복되면서, 입력 형식을 테스트하는 과정에서도 인증 정보가 반드시 필요하게 되어 다음과 같은 문제가 발생했습니다.입력 형식을 위한 테스트에 불필요한 인증 로직을 포함해야 하는 문제예: JsonBody가 매핑되는지 확인하기 위해 인증을 포함해야 했음.인가 테스트를 위해 현재 사용하고 있는 로그인 구현체에 의존해야 하는 문제예: Authorization 헤더를 통해 직접 토큰을 생성하는 방식에 의존하게 됨.💡 2. 해결 방안테스트 각각에..

🙈 1. 문제 파악현재 진행 중인 프로젝트에서는 이미지 업로드 API의 응답 시간을 단축하고, 처리량(Throughput)을 향상시키기 위해 비동기 처리를 도입하고자 했습니다.스프링에서는 AOP(Aspect-Oriented Programming)로 @Async 어노테이션을 통해 비동기 처리를 지원하고 있습니다. 그러나 기존의 MediaStorage 구현체에 @Async를 직접 적용하는 상황에서, 몇 가지 문제가 발생했습니다.문제점1. UploadFile 구현에 따른 의존성 문제@Async를 MediaStorage의 구현체에 직접 추가하면, 기존 MediaStorage를 의존하는 모든 서비스들에 대해 비동기 처리가 적용됩니다. 하지만 UploadFile 자체가 비동기를 지원하지 않으면 (예: Multip..

☁️ 이미지 업로드 API에서의 트랜잭션 병목과 비동기 처리 전략1. 문제 파악 – 응답시간이 8초?최근 진행 중인 프로젝트에서 이미지 업로드 기능을 독립적인 API로 설계하고 있었습니다.사용자는 이미지와 함께 간단한 정보를 전송하며, 서버는 이를 데이터베이스에 기록한 뒤 이미지 파일을 저장합니다.단순한 API라 여겼지만, 부하 테스트 결과는 충격적이었습니다.200 Threads x 10 Loop = 총 2000회 요청평균 응답 시간: 약 8초Throughput: 33 requests/sec단순 이미지 업로드임에도, 트래픽이 몰리자 응답 시간이 기하급수적으로 증가했습니다.원인을 찾기 위해 서버의 흐름을 다시 점검했습니다.2. 근본 원인 – 트랜잭션과 I/O의 결합애플리케이션 구조는 아래와 같았습니다:문제..

어플리케이션의 규모가 커지고, API의 종류가 다양해지면서 입력값 검증 로직이 여러 레이어에 흩어져 관리되는 문제가 발생했습니다.특히 같은 도메인 필드에 대한 검증 코드가 각기 다른 DTO에 중복 작성되면서, 유지보수성과 일관성에 어려움이 뒤따랐습니다.이러한 문제를 해결하기 위해, 검증 책임의 위치를 조정하고 통합해가는 과정을 다음과 같이 정리해보았습니다검증 방식 발전 과정1. Request에 대해서만 검증하자.1-1. 구현 방식 : DTO에 대한 검증일반적인 스프링 MVC 어플리케이션에서 입력값 검증을 위해 Jakarta Validation API를 제공합니다.입력값에 대한 검증을 위해 아래와 같이 해당 API를 사용했습니다.public class MemberRegisterRequest { @Le..