BACKEND
ENGINEER.

가드레일 탐지 메시지를 Oracle DB에 CLOB 청킹·Base64 인코딩으로 분할 저장하고, 관리자 화면에서 페이징+필터링 조회 시 10만 건 기준 응답 시간 약 2분 30초 소요

• XMLAGG가 OFFSET/FETCH 이전 전체 데이터에 먼저 실행 → 페이지와 무관하게 전체 CLOB 합산 후 잘라내는 비효율
• ROW_NUMBER() OVER의 ORDER BY와 최종 SELECT ORDER BY 기준 불일치 → 동일 정렬 키를 가진 행의 순서가 페이지마다 달라지는 문제

• CTE(WITH절)로 쿼리를 분리하고, XMLAGG를 페이징 확정 N건에 대해서만 스칼라 서브쿼리로 실행하여 CLOB 생성 연산 범위를 페이지 단위로 제한
• ORDER BY 기준 통일 및 스칼라 서브쿼리 접근 컬럼에 복합 인덱스 추가로 Sort 연산·Full Table Scan 최소화

10만 건 기준 약 2분 30초 → 약 700ms

30만 건 이상 가드레일 탐지 메시지 엑셀 다운로드 요청 시 OOM(OutOfMemoryError) 발생, 처리 시간 약 18분 소요

• XSSFWorkbook이 전체 엑셀 데이터를 메모리에 적재하는 구조로 건수 증가 시 힙 사용량 선형 이상 증가
• MyBatis 쿼리 결과를 List<T> 전량 JVM 힙에 올려 조회 단계에서도 대규모 메모리 점유
• CLOB 재조합·Base64 디코딩 시 String 객체의 JVM 최대 허용 크기 초과 및 과도한 로그 I/O 비용

• XSSFWorkbook → SXSSFWorkbook 교체, windowSize 초과 행을 디스크에 flush하는 스트리밍 쓰기 방식 적용
• MyBatis ResultHandler로 DB 결과를 건별로 읽어 즉시 엑셀 행에 write하는 구조로 전환
• 다운로드 요청을 비동기로 분리하고 프론트엔드에 진행률 UI를 추가하여 UX 개선

30만 건 기준 약 18분 → 약 1분 40초, OOM 재발 없음

상면 이전 및 정책 변경으로 CAS → Kakao SSO → Keycloak 순차 전환이 필요했으나, 인증 로직이 AuthenticationController에 하드코딩되어 매번 전면 수정이 필요한 구조

• Spring Security 표준 구조로 인증 레이어 분리: AbstractAuthenticationProcessingFilter → AuthenticationToken → AuthenticationProvider → Handler
• 인증 제공자별 AbstractAuthenticationToken 구현체를 분리하고, Provider의 supports()에서 Token 타입 기준으로 분기하도록 설계

CAS → Kakao SSO → Keycloak 순차 전환 완료. 이후 Provider·Token 구현체만 교체하면 인증 제공자 변경 가능한 구조 확립

Kakao SSO 전환 후 동시 로그인 시 먼저 로그인한 사용자의 세션으로 이후 사용자가 접속되는 인증 혼용 현상 발생

OAuth2RestTemplate이 싱글톤 Bean으로 등록되어 내부 OAuth2ClientContext가 모든 요청 스레드에서 공유 → 사용자 A의 AccessToken이 사용자 B 요청에 재사용

매 인증 요청마다 DefaultAccessTokenRequest / DefaultOAuth2ClientContext를 새로 생성하여 OAuth2RestTemplate 인스턴스를 요청 단위로 격리

사용자별 인증 컨텍스트 격리로 토큰 혼용 현상 해소

• 기존 Vault 기반 시크릿 관리는 공유 인프라 의존 구조로, 분리 후 독립적인 시크릿 관리 체계 필요
• Kubernetes Secret은 base64 인코딩에 불과하여 Git에 평문 커밋 불가 → GitOps 방식 유지를 위해 암호화 관리 방법 필요

• CI/CD 파이프라인 구성: GitHub Actions(CI) → Helm Chart(GitOps) → ArgoCD(CD) → GKE 클러스터
• Sealed Secrets 도입: kubeseal CLI로 암호화한 SealedSecret YAML을 저장소에 커밋, GKE 내 Controller가 개인키로 복호화하여 Kubernetes Secret 자동 생성. 일반 환경변수는 ConfigMap, 민감 정보는 Secret으로 분리 관리
• .env.secret 기반 kubeseal 암호화부터 GitOps 저장소 커밋까지 자동화하는 Shell 스크립트 작성하여 반복 작업 간소화 및 휴먼 에러 방지

사내 인하우스 → GKE 인프라 이관 완료. Vault 의존성 제거 및 Sealed Secrets 기반 GitOps 시크릿 관리 체계 확립

ArgoCD sync 후 SealedSecret은 클러스터에 정상 apply 되었으나 Kubernetes Secret이 생성되지 않아 앱 Pod 기동 실패

• Sealed Secrets의 strict scope 기본값은 암호화 시점에 metadata.name/namespace를 암호문에 바인딩하는 구조
• 암호화 시 지정한 name/namespace와 실제 배포 환경의 메타데이터가 달라 Controller가 복호화를 거부하고 Secret 미생성 (Controller 로그에서 거부 메시지 확인)

배포 환경의 실제 metadata.name/namespace에 맞춰 재암호화 후 저장소에 재커밋하여 해결

복호화 실패 원인 파악 및 재암호화로 정상 운영 복구

제공자별로 Controller 엔드포인트와 Service 로직이 각각 분리된 구조로, 구글·페이스북·애플 소셜 로그인 추가 결정 시 매번 Controller 메서드와 Service 로직을 동시에 추가해야 하는 중복 코드 누적

• /api/v1/login/{provider} 단일 엔드포인트로 통합 후, 공통 인터페이스 LoginStrategy를 정의하고 제공자별 로직을 독립 구현체로 분리
• Controller는 전략 조회 및 호출만 담당 → 새로운 제공자 추가 시 Controller·Service 수정 불필요한 구조 확립

LoginStrategy 구현체만 추가하면 되는 구조로 개선 (OCP 준수). 각 전략 클래스 독립 분리로 단위 테스트 용이

담당자 부재 시 기능 스펙·의도 파악 어려움. 비즈니스 로직 변경 시 사이드 이펙트 사전 파악 불가. 문서 갱신 누락 시 코드-명세 불일치 발생

• 계층별 테스트 전략 수립: Service 핵심 비즈니스 로직은 TDD, Controller는 API 설계 확정 후 TLD 방식 제안. Given-When-Then + @DisplayName 컨벤션으로 테스트 케이스 자체가 명세서 역할을 하도록 구성
• Spring REST Docs 병행 도입: Swagger(개발 단계 협업 편의) + REST Docs(신뢰할 수 있는 API 명세) 역할 분리. 테스트 통과 시에만 스니펫 생성되는 구조로 코드-문서 불일치 방지

팀 전체 테스트 작성 기준 제시. @DisplayName/@Nested 기반 구조로 신규 팀원도 테스트코드만으로 도메인 정책 파악 가능

PHP + Laravel 기반 서버를 Java 17 + Spring Boot 3.2 + JPA로 전환 중 중단된 상태에서 재착수. Hibernate SQL 로깅으로 기능 테스트 중 단일 조회 요청에 수십 건의 SELECT가 반복 실행되는 N+1 문제 탐지

• 반복문 내 findById() 개별 호출로 N건 처리 시 최대 2N번 DB 호출
• 단건 상세 조회 시 모든 연관관계가 FetchType.LAZY로 설정되어 접근 시점마다 추가 SELECT 연쇄 발생 (최대 5번)
• 목록 조회 후 서비스 계층에서 각 Member마다 Group 연관관계 접근으로 건수에 비례하는 N+1 구조

• 반복 쿼리 개선: 공통 데이터 선 조회 후 findAllById() 일괄 조회 전환, Map 인덱싱 캐싱 → DB 호출 2N번 → 2번
• 단건 조회: Fetch Join 적용한 상세 조회 전용 메서드 작성 → 쿼리 실행 5번 → 1번
• 목록 조회: QueryDSL DTO Projection으로 필요한 컬럼만 단일 JOIN 쿼리로 직접 조회하여 서비스 계층 연관관계 접근 제거

전체 목록 조회 기준 약 4,680ms → 380ms (약 92% 단축)