Posts

대시보드 감사 기록 조회 API의 성능 테스트 중, 1000만 건 데이터 조회 시 응답 시간이 3000ms를 훌쩍 넘는 현상을 발견했다. 당연히 인덱스를 탈 것이라 예상했던 쿼리가 FULL SCAN을 하고 있었다. 이 글은 문제의 원인을 파악하고 응답 시간을 10분의 1로 단축하기까지의 과정과 그 과정에서 배운 점을 담은 기록이다. 1. 문제 상황: 느린 쿼리 그리고 기대와 다른 실행계획 대시보드 화면에서 가장 최근에 기록된 감사기록 5건을 조회하는 API 개발을 맡게 됐다. 기존의 소스코드를 분석해보니 이미 관련 기능을 제공하는 DAO가 있었고, POSTMAN으로 테스트해본 결과 적은 데이터에서는 별 문제없이 잘 동작했다. ...

개발자 업무 숙련도가 높아진 경험

앞으로의 백엔드 개발자로서의 공부 방향을 제시해주는 책

인코딩 개념 이번에 잡아 보자

올해 상반기 회고 실시. 회고를 통해 더 나은 나를 만들어 보자.

DB에서 독립된 URL 단축기

테스트 커버리지 100% 수치에대한 허상. 그럼에도 불구하고…

쉬운코드님의 유튜브 영상 정리

MVCC 공부

Challenge: 메모리 제약과 비정형 데이터 관리 MY CODING TEST 프로젝트에서 소스 코드와 메모 같은 비정형 데이터를 MySQL에 직접 저장하려 했습니다. 그러나 AWS 1GB 메모리 인스턴스에서 스프링 서버를 운영하며 JVM의 기본 최대 힙 크기가 240MB로 제한된다는 점에서 다음과 같은 우려가 생겼습니다: 메모리 부담: 클라이언트 요청이 스프링 서버로 전달되면 데이터 크기만큼 JVM 힙 메모리에 로드됨 비정형 데이터의 불확실성: 문제 번호, 타이틀, 채점 결과 등 정형 데이터는 크기가 작고 예측 가능한 반면에 소스 코드와 메모는 사용자에 따라 크기가 천차만별이며, 복잡한 문제 풀이 시 대용량 데이터 발생 가능 성능 저하 위험: 240MB 힙 크기 제한 하에서 대용량 요청이 동시에 발생하면 GC(가비지 컬렉션)가 빈번해지고, 스프링 앱 성능이 저하될 가능성 1GB 시스템에서의 JVM default Heap Memory 확인 ...

문제 정의 Oauth2.0 로그인 구현 성공 로그인시 서버에서 쿠키를 클라이언트에 전달 이제 브라우저에서 API를 요청시 전달받은 쿠키를 헤더에 넣어서 요청을 함 서버에서 이제 쿠키를 확인하고 처리하는 로직을 구현해야한다 문제 분석 결국 해야하는것은 정상적인 쿠키일때 Security Context에 인증이 되었다고 설정해주는 것 문제 해결 과정 로그인 성공 시, 서버는 사용자 정보를 담은 JWT 토큰을 생성후, 쿠키에 담아 응답 서버는 JwtFilter를 통해 토큰의 유효성을 검증하고, 사용자 정보를 추출하여 인증을 완료 Spring Security Filter에 구현한 JwtFilter를 추가하여 인증 작업을하도록 구현 다음 그림은 JwtFilter 의 흐름을 간단히 다이어그램으로 표현 ...

잘 작동되던 API가 memberId를 바꾸었더니 에러가 발생한다. 그 원인분석과 테스트를 해본다.

인덱스, 복합 인덱스 활용하면 조회가 얼마나 빨라지는가?

문제 정의 팀의 브랜치 전략에 대해 우선 설명하자면 일주일동안 작업한것을 Develop에 머지하고 문제 없으면 Master로 머지하는 방식 작업 브랜치는 각자 생성하고 그 브랜치를 Weekly 브랜치에 PR후, 코드리뷰 후 Approve를 받아 머지시킴 커밋 로그를 깔끔히 관리하기 위해 Squash Merge를 활용하기로 결정 문제 발생 Weekly -> Develop 머지시 All Conflict 가 발생했고 당연히 Develop -> Master 머지도 불가 문제 분석 Squash Merge 시행시 기존 커밋 히스토리가 하나의 커밋으로 합쳐지며 새로운 히스토리 하나로 통합된다 이러면 Weekly 에서 Squash Merge 된 커밋을 Develop 에서는 커밋 히스토리 추적이 불가하다. 커밋 ID로 히스토리가 추적되는데 Develop 입장에서는 Weekly에서 Squash 된 새로운 커밋은 생판 처음보기 때문 아래의 그림은 팀원에게 설명하기 위해 그린 그림. ...

여름에 참여한 아이디어톤 후기

구현 계기 아래 그림과 같은 기능을 구현하고 싶었습니다. 먼저 국내에 이런 서비스가 존재하는지 확인을 해보았는데, 기존 통신사에서 인터넷전화를 제공하고 이와 관련된 API도 제공은 하는거 같은데 약정같은것도 해야되고 명확한 정보들을 찾지 못하였습니다. 대학생 수준의 프로젝트이고 개발과정이라서 통신사 약정같은것은 너무 부담이 되었습니다. 그래서 해외까지 찾아보니 Twilio라는 회사를 발견하게 되었습니다. 이 회사는 메세지, 인증, 보이스등의 서비스를 제공해주는 CPaaS 회사입니다. 찾아보니 Twilio는 webhook을 이용해서 내 Twilio 전화로 온 발신자의 정보를 POST해주는 기능을 지원하는것을 확인하였고, 관련 Twilio설정을 마친후, 직접 제가 Twilio로 부터 받은 전화번호로 전화를하니 성공적으로 서버로 발신자 번호가 넘어가는것을 확인하였습니다. ...

팀원들에게 협업 방법들을 설명하기 위한 자료

협업 준비위한 세팅 방법을 기록

문제 정의 기존의 설정으로 헤더를 이용하는 위시관련기능에서 계속 cors error가 발생하였습니다. 문제 분석 브라우저의 에러로그를 살핌 검색 Access to XMLHttpRequest at 'http://43.201.254.198:8080/api/wishes?page=0&size=10&sort=createdDate,desc' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status. 🤔원인 여기서 생소한 preflight request를 보았고 아래자료와 GPT 등으로 무엇인지 알아보았습니다. CORS관련 문서 문제 해결 과정 위시 관련 api 요청에는 Authourization 헤더를 요구합니다. 이 요청은 단순한(GET, POST 등)요청으로 취급되지 않고 복잡한 요청으로 브라우저에서 취급을 합니다. 그래서 CORS 정책에서 preflight request이 요청은 서버가 실제 데이터 요청을 허용할지 여부를 확인하는 과정입니다.preflight request가 먼저 요청이 왔을때 아래의 응답을 원하고 있었습니다. ...