전체 글31 취업 기록 부트캠프 기간 9주 + 채용 전환 대비 면접 과정이 벌써 전생같고 엄청난 기억이 휘발되는 듯한 느낌이 든다..그 엄청난 경험을 잊혀지게 만들 수 없기 때문에 남기는 기록이다. 소프티어 부트캠프는 2025년 하반기에 7기로 백엔드 직무에 지원했다.당시 여러 곳 지원서 작성하고, 시험 보고, 면접 보고 등등 그 중 하나인 곳이었는데어쩌다 보니 전형을 다 밟고 최종 선정까지 됐다. 지원서 작성 -> 코딩 테스트 -> CS 테스트 -> 인성 검사 -> 면접을 진행하고 합격했다. 1. 기간이 짧고2. 채용 전환이 가능하고3. 일반 공채와 유사한 선발 과정으로 미루어보면 일반적인 부트캠프보다 공채 과정 중 "두 달 간의 긴 테스트 기간"이라고 볼 수 있을 거 같다. (사바사였지만 면접에서도 배움에 대한 열정을.. 2026. 5. 15. Hibernate IN 절 병목 및 Redis KEYS 차단 현상 분석과 성능 개선 본 문서는 프로젝트 진행 중 관찰된 인프라 지표 스파이크 현상을 분석하고, 이를 해결하기 위해 수립한 가설과 리팩터링 과정을 기록했습니다.1. 현상 관찰 및 지표 분석1.1 메모리 및 인프라 지표 이상 포착 서비스 모니터링 중 특정 시간대에 다음과 같은 비정상 지표가 관찰되었습니다.메모리(Memory Usage) 급증: 추천 로직 실행 시 JVM 힙 메모리 점유율이 가파르게 상승네트워크(Network In): 순간적으로 450MB까지 급증하는 트래픽 스파이크 발생.사용자 체감: 해당 시간대 응답 지연 및 간헐적인 API 타임아웃 발생. 1.2 리포지토리 레이어의 비효율분석 과정에서 Hibernate가 생성하는 SQL 쿼리를 검토한 결과, 메모리 점유율을 폭증시키는 결정적인 패턴을 발견했습니다. 2. 장.. 2026. 3. 2. 매칭 연산 데이터 신뢰성 확보 및 정합성 결함 추적 목차1. 분석 배경 및 목적1.1 서비스 핵심 가치: 행정사 매칭 신뢰도 정의1.2 RDB 중심 설계의 한계: 중간 연산값 혼재와 데이터 오염2. 장애 현상 및 데이터 오염 지표 관찰2.1 더티 데이터 누적 및 원자성 파괴2.1.1 비즈니스 트랜잭션 롤백 시 연산 파편 잔존 현상2.1.2 '리뷰 없는 점수' 발생에 따른 매칭 정밀도 저하 리스크2.2 데이터 상태 불일치 및 동시성 제어 결함2.2.1 고빈도 업데이트 상황에서의 갱신 손실 포착2.2.2 멀티 스레드 시뮬레이션을 통한 점수 회귀 현상 증명2.3 스토리지 효율성 저하 및 관리 가시성 부재2.3.1 고차원 벡터(512차원) 갱신 시 발생하는 물리적 파일 비대화2.3.2 PostgreSQL 통계 수집기의 비동기성에 따른 Silent Failure .. 2026. 3. 2. 리뷰 통계 관리 테이블 분리 및 성능 최적화 과정 1. 배경 및 목적 현재 프로젝트의 홈 화면은 사용자에게 최적의 행정사를 추천하기 위해 [행정사 탐색] 기능을 제공합니다. 이 과정에서 각 행정사가 획득한 '배지 Top 2'와 '리뷰가 많은 특화직무 Top 2'를 실시간으로 보여주어야 합니다.기존 방식의 한계- 성능 저하: 행정사 목록 조회 시마다 수만 건의 Review, Badge 테이블을 JOIN 및 GROUP BY 하면 API 응답 시간이 기하급수적으로 늘어남.- 확장성 부족: 리뷰 작성 시점에 통계 업데이트, 알림 발송, 포인트 지급 등 요구사항이 늘어날수록 ReviewService가 비대해짐 (Fat Service 문제).2. 팀 내부 논의 및 의사결정 과정본 설계안은 프로젝트 팀원들과의 심도 있는 기술 논의를 거쳐 도출되었습니다... 2026. 3. 2. 커스텀 JWT 인증 시스템 및 OAuth 2.0 연동 아키텍처 본 문서는 Spring Security를 사용하지 않는 환경에서 JWT(JSON Web Token)와 Redis를 활용해 구축한 독자적인 인증 시스템과 구글 OAuth 2.0 연동 과정, 그리고 보안 고도화 전략 구현 과정에 대해 기술합니다.(*핵심 비즈니스 로직에 집중하고 시스템 복잡도를 낮추기 위해, 구글 로그인은 프론트엔드 연동 단계에서 최종 제외되었습니다.)1. 설계 배경 및 제약 사항- Spring Security 미사용: 프레임워크의 과도한 추상화 대신 직접 Interceptor를 제어하여 인증 흐름을 투명하게 관리하고자 했습니다.- 보안과 성능의 균형: 매 요청마다 DB를 조회하는 세션 방식 대신, 무상태성(Stateless)을 유지하는 JWT 방식을 채택하고 Redis를 통해 토.. 2026. 3. 2. 통합 테스트 구조 개선: 컨테이너 재사용을 통한 테스트 최적화 본 문서는 스프링부트 프로젝트의 테스트 신뢰성을 확보하기 위해 운영 환경과 동일한 데이터베이스 환경을 구축하고, 테스트 실행 속도를 최적화하기 위해 설계된 "통합 테스트 구조"에 대해 기술합니다.1. 설계 배경 및 목적기존의 `@DataJpaTest`는 기본적으로 인메모리 데이터베이스인 H2를 사용했습니다. 하지만 프로젝트가 고도화됨에 따라 다음과 같은 기술적 한계와 엔지니어링적 고민이 발생했습니다.1. DB 방언(Dialect) 및 기능적 불일치: H2와 실제 운영 환경인 PostgreSQL 사이에는 문법 및 제약 조건 동작의 차이가 존재합니다. "테스트는 성공하지만 운영 환경에서는 실패하는" 시나리오를 방지하고, 쿼리의 정확성을 실제 환경 수준으로 검증하고자 했습니다.2. 환경의 일관성 (In.. 2026. 3. 2. 이전 1 2 3 4 ··· 6 다음
