신강희

Case 1. 수기 메타데이터 관리 규칙의 시스템화

1) 문제 맥락

• 회사·부서·사용자·채널 정보를 운영자가 SQL로 직접 관리하고 있어, 변경 누락과 잘못된 상태 입력이 발생할 수 있었고 변경 이력을 추적하기도 어려웠습니다.
• 상위 조직은 비활성화됐지만 하위 조직은 활성 상태로 남는 등 상·하위 데이터의 상태 불일치가 누적됐습니다.

2) 선택 기준과 구현

• 회사·부서·사용자·채널 정보를 관리하는 웹 기반 CRUD를 구축했습니다.
• 상위 데이터 비활성화 시 하위 데이터도 함께 비활성화하는계단식 soft-delete 를 적용했습니다.
• 생성자·수정자·변경 일시를 기록해 변경 이력을 추적하도록 구성했습니다.

3) 결과

• SQL을 직접 실행하지 않고 관리 화면에서 메타데이터를 등록·수정할 수 있도록 운영 절차를 시스템화했습니다.
• 부서 245건 중 확인된 상·하위 상태 불일치 87건과 잘못된 상위 데이터 참조 2건을 정비했습니다.

Case 2. 쓰기 정합성을 우선한 메타데이터 일원화

1) 문제 맥락

• 회사·사용자 메타데이터가 Oracle과 MariaDB에 중복 저장되어 변경 시 두 DB의 정합성을 함께 관리해야 하는 부담이 있었습니다.

2) 선택 기준과 구현

• 중복 관리하던 메타데이터를 MariaDB로 일원화했습니다.
• MariaDB 후보 ID 조회 → Oracle 발송 이력 페이징 → 메타데이터 Map 구성 → 서비스 계층 결합순서로 조회 구조를 구현했습니다.
• 회사당 최대 300건 내외, 전체 1,000건 미만의 후보 규모를 기준으로 IN절과 애플리케이션 매핑의 적용 범위를 제한했습니다.

3) 결과

• 메타데이터의 저장 경로를 MariaDB로 일원화해 두 DB를 함께 갱신할 때 발생할 수 있는 부분 실패와 정합성 관리 부담을 줄였습니다.
• 분리된 두 DB에서도 회사·사용자 기준 발송 이력 조회를 구현했습니다.

Case 3. 변화하는 데이터셋의 조회 시점 고정

1) 문제 맥락

• 신규 데이터가 추가되면 기존 데이터의 위치가 밀려, 페이지 이동 과정에서 중복 조회나 누락이 발생할 수 있었습니다.
• 조회 중 새로 들어온 데이터와 기존 조회 범위를 구분하기 어려웠습니다.

2) 선택 기준과 구현

• 최초 조회 결과의 정렬 기준값을 앵커로 반환하고, 이후 페이지 요청에서도 같은 앵커를 조회 조건으로 사용했습니다.
• 앵커 이후 유입된 데이터는 목록에 즉시 섞지 않고 신규 건수로 별도 표시했습니다.
• 사용자가 갱신할 때 새 앵커를 적용해 최신 조회 범위로 전환했습니다.

3) 결과

• 페이지 이동 중 중복·누락 가능성을 줄이고 조회 흐름을 일관되게 유지했습니다.
• 조회 이후 유입된 신규 데이터의 존재를 별도로 알리면서, 사용자의 현재 페이지와 조회 기준을 유지했습니다.

Case 1. 외부 I/O 분리를 통한 이메일 인증 요청 경로 개선

1) 문제 맥락

• 이메일 인증 과정에서 SMTP 통신이 사용자 요청 처리 경로를 점유하고 있었습니다.
• 이 때문에 인증 요청 API가 메일 발송 완료까지 기다려야 했고, 외부 I/O 지연이 사용자 응답에 그대로 전파됐습니다.

2) 선택 기준과 구현

• 인증 요청 처리와 메일 발송의 실행 경로를 분리했습니다.
• Spring Event와 @Async를 활용해 메일 발송을 비동기 후처리로 구성하고, SMTP 통신은 별도 Executor에서 처리했습니다.

3) 검증 결과

• 로컬 테스트 환경에서 요청 접수까지의 평균 API 응답 시간은 약 2.5초에서 0.2초로 감소했습니다.
• 회원가입 과정의 이메일 인증 UX를 개선했습니다.

4) 설계 회고

• 회원가입 요청 흐름과 SMTP 메일 발송 책임을 분리해, 외부 I/O 지연과 사용자 응답을 분리
• TransactionPhase.AFTER_COMMIT 기반 데이터 정합성 처리 학습

Case 2. Gateway와 Auth Service의 인증 책임 분리

1) 문제 맥락

• 마이크로서비스마다 JWT 검증을 구현하면 인증 코드와 보안 정책이 중복되고, 정책 변경 시 여러 서비스를 함께 수정해야 했습니다.
• 반대로 Gateway가 로그인과 토큰 발급까지 담당하면 사용자 도메인과 라우팅 계층의 책임이 섞이는 문제가 발생할 수 있습니다.

2) 선택 기준과 구현

• Gateway는 JWT 검증과 사용자 식별자 전달만 담당하도록 공통 필터를 구성했습니다.
• 로그인, 토큰 발급·재발급과 사용자 상태 확인은Auth Service가책임지도록 했습니다.
• 인증이 필요 없는 경로를 명시적으로 관리하고, 내부 서비스에는 검증된 사용자 정보를 헤더로 전달했습니다.

3) 검증 결과

• 인증 검증 지점을 Gateway로 일원화해 각 서비스의 중복 JWT 파싱·검증 부담과 인증 정책의 변경 지점을 줄였습니다.
• 라우팅 계층과 사용자 도메인의 경계를 유지해 신규 서비스 추가 시 인증 적용을 단순화

4) 설계 회고

• Gateway가 전달하는 헤더를 외부 요청이 위조하지 못하도록 내부 네트워크 경계와 헤더 제거 정책이 함께 필요하다는 점을 설계 조건으로 정리했습니다.

Case 1. 조회 특성에 맞춘 JPA·MyBatis 하이브리드 전략

1) 문제 맥락

• 복합 조건 검색에 JPA Specification을 사용하면서 가독성이 낮아지고, 복잡한 쿼리를 작성하거나 튜닝하기 어려워졌습니다.

2) 선택 기준과 구현

• 복합 조회에만 MyBatis를 부분적으로 도입했습니다.
• 추가 1) choose 중첩 → OR 조건을 통합해 쿼리 재사용성을 높였습니다.
• 추가 2) JOIN → EXISTS 서브쿼리 기반 카운팅을 통해 쿼리를 최적화했습니다.

3) 검증 결과

로컬 환경에서 동시 사용자 10명, 각 50회 요청으로 측정했으며, 동일한 데이터와 인덱스 조건을 유지했습니다.

• 평균 응답시간:24.45ms → 16.85ms (31.1% 개선)으로 단축했습니다.

4) 설계 회고

• 복합 조회를 MyBatis로 분리하고 COUNT 쿼리의 불필요한 JOIN을 EXISTS로 재구성한 결과, 동일한 로컬 테스트 조건에서 응답 시간을 줄였습니다.