보호되어 있는 글입니다.

배포 방식, 그때는 맞고 지금은 틀리다프로젝트 초기에는 AWS에서 제공하는 배포 도구인 CodeDeploy와 S3를 사용하여 배포를 진행했습니다.CodeDeploy는 학습 비용이 낮고, GitHub Actions와 연계하여 자동 배포를 설정할 수 있어 기본적인 배포 흐름을 익히기에 적합하다고 판단했습니다. 하지만 배포를 진행하면서 몇 가지 한계를 경험했습니다. CodeDeploy 방식은 S3에서 파일을 다운로드한 후, EC2에서 압축을 해제하고 애플리케이션을 재시작하는 과정이 필요했습니다.아래는 CodeDeploy를 통한 배포 단계별 시간으로, 이벤트 로그를 통해 각 단계에서 소요된 시간을 확인할 수 있습니다. CodeDeploy 배포 시간은 현재 서비스가 크지 않은 상태에서 배포 시간이 약 5 ~ 6초..

세션 기반 인증의 한계프로젝트 초기에는 스프링 시큐리티를 기본 기능인 세션 기반 인증을 사용했습니다.세션 기반 인증은 사용자의 로그인 상태를 서버 메모리에 저장하는 방식으로 간단하지만, 세션은 서버에 저장되기 때문에 사용자가 증가함에 따라 서버 메모리에 저장되는 세션 데이터도 증가하고 이로 인해 서버의 부하가 커질 것이라고 생각했습니다. 또한, 세션 하이재킹과 같은 보안 위협에 노출될 가능성이 있었습니다. 이러한 문제를 해결하기 위해 JWT를 도입하기로 결정했습니다. JWT는 클라이언트 측에서 토큰을 저장하고, 서버는 상태를 유지하지 않는 방식으로 동작합니다. 때문에 세션 기반을 사용했을 때의 한계를 극복할 수 있었습니다. 하지만 세션 기반을 버리고 토큰 기반으로 사용을 한다고 해서 모든 문제점이 해결되..

시간 복잡도를 구해야 하는 이유시간 복잡도를 구해야 하는 이유는 알고리즘의 성능을 평가하고, 문제 해결에 적절한 방법을 선택하기 위해서이다. 코딩 테스트나 실무에서 알고리즘을 다룰 때, 단순히 코드가 동작하는지만 확인하는 것이 아니라 “이 코드가 얼마나 빠르게 실행될 것인가”를 고려해야 한다. 같은 문제를 해결하는 다양한 접근 방식이 존재하는데, 어떤 방법이 더 효율적인지를 판단하려면 단순 실행 시간이 아닌 입력 크기에 따른 연산 횟수 증가율을 분석해야 한다. 이를 위해 시간 복잡도를 구한다.   시간 복잡도를 구하는 이유는 크게 세 가지로 정리할 수 있다. 1. 알고리즘의 효율성을 비교하기 위해  ﹒ 동일한 문제를 해결하는 여러 알고리즘이 존재할 때, 실행 속도를 객관적으로 비교해야 한다.﹒ 실행 속도..