노성웅

Key Responsibilities

• 운영자가 대신 처리하던 매니지드 방식을 고객 셀프서비스 API로 전환 · 반복적인 수동 처리 업무 해소

  문제고객이 자원을 직접 제어할 수 없고 운영자가 대신 생성해주는 매니지드 방식이라, 로드밸런서에 VM 하나 연결하는 것도 요청·대기가 반복(체감상 월 50건 안팎)되는 제한적인 CSP 구조

  분석네트워크 장비가 이미 제공하는 멀티테넌트 기능을 외부에 안전하게 노출하는 별도 API 서버를 신규 개발 → 고객이 자기 테넌트 범위에서 직접 자원을 신청·즉시 처리

• 다단계 벤더 프로비저닝을 Saga 패턴(11개 예외 타입 기반 차등 롤백)으로 설계 · 자원 누수 구조적 방지, 벤더 추가 시 예외 타입·핸들러만 추가하는 확장 구조

  문제방화벽·VS·라우트·ACI·OpenStack 등 서로 다른 벤더 API의 순차 호출이 외부 시스템이라 DB 트랜잭션·@Transactional로 묶을 수 없어, 중간 실패 시 자원 누수가 발생하고 재시도조차 막힘

  분석벤더 호출을 조율하는 Integration 계층 분리(도메인 서비스 / 벤더 어댑터 / Builder) + 프로비저닝 7단계마다 실패 지점별 롤백 범위가 다른 11개 예외 타입 체계 설계(공통 예외 상속, 하위 예외는 컨텍스트만 추가) · 도메인별 구체 롤백은 각 도메인 담당자가 이 구조 위에서 처리

• 로드밸런서 공유 자원(Citrix Service)에 참조 카운팅을 설계 · 애플리케이션 레벨에서 참조 상태를 직접 관리해 여러 가상서버의 백엔드 공유를 안전하게 보장, 중복 생성·조기 삭제 방지

  문제Citrix 장비에서 백엔드는 {IP}_{PORT}로 식별되는 하나의 Service 객체인데 여러 가상서버가 같은 Service를 공유 바인딩 가능. 여러 가상서버가 안전하게 공유하려면 애플리케이션이 직접 참조 상태를 추적해야 해 중복 생성·사용 중인 자원의 조기 삭제 위험

  분석연결 시 장비에 Service 존재 여부를 조회해 재사용/신규 생성 분기, 해제 시 DB에서 동일 IP·Port를 참조하는 다른 활성 바인딩 존재 여부를 쿼리로 확인 후 삭제하는 방식으로 참조 카운팅 구현

• 상품 도메인별 특성에 맞춘 멀티테넌트 데이터 모델(방화벽 정규화 FK 그래프 / LB 비정규화) + DB 논리 격리·장비 물리 격리 2단 구조 설계

  문제고객(테넌트)마다 독립 네트워크 환경을 보장해야 하는데 상품(방화벽·LB)마다 격리 특성이 달라 단일 방식으로 모델링 불가

  분석장비가 상태 조회 API를 제공해 DB는 얇은 매핑 레이어로 충분 → 단일 스키마 논리 격리. 방화벽은 Zone 루트 FK 그래프로 정규화, LB는 DB·장비 식별자를 함께 저장하는 비정규화로 조인 없이 각자 필요한 키 사용

• 장비 API를 실제 호출하는 통합 테스트로 스펙 불일치를 배포 전 검증 · 최전방 네트워크 설정 실패로 인한 테넌트 전체 연결 장애 사전 차단

  문제네트워크 상품이 테넌트의 최전방 장비를 전부 다루는 구조라 설정 실패 시 테넌트 전체가 연결 불가. 벤더 장비마다 스펙 문서와 실제 동작이 달라(안랩 방화벽 필드명 오타, Citrix 독자 쿼리 파라미터 인코딩 등) 연동 개발 중 반복적으로 고치고 재배포

  분석벤더 장비 연동을 검증하는 테스트 문화가 없던 조직에서, Mock 없이 실제 스테이징 장비를 직접 호출하는 통합 테스트를 도입 — 비즈니스 로직보다 요청 포맷이 실제 장비 스펙과 어긋나지 않는지를 배포 전 검증하는 데 초점

Key Responsibilities

• 배치 처리 2시간 → 10초 (약 700배) — HashMap 캐싱 + JDBC Bulk Insert 전환

  문제연 2회 스케줄러 배치였으나 버튼 즉시 실행으로 기획 변경 후, 14만 건 처리에 2시간이 걸려 사용자가 결과를 볼 때까지 대기해야 하는 사실상 못 쓰는 구조

  분석건별 비교 조회를 전체 조회 + HashMap 인메모리 비교로 개선. INSERT 병목은 JPA IDENTITY 전략이 단건 INSERT를 강제하는 구조적 한계를 확인해 JDBC Template Bulk Insert로 전환

• 값 변경이 있을 때만 이력을 남겨 심사자가 봐야 할 내역만 남도록 설계 · 사업유형별로 검증 규칙을 분리해 실무자 입력 부담 축소

  문제감사 대응상 변경 이력 추적이 필요하나 단순 적재 시 값 변경 없는 저장도 이력이 과다 적재돼 감사 추적성을 저해. 또 사업유형마다 심사 규정(요구 항목)이 다른데 동일 검증을 걸면 폐기 자산에도 불필요한 스펙을 요구

  분석7종 자원을 필드 단위로 비교해 실제 변경 시에만 이력 적재(타입 차이 오탐 처리) + Bean Validation Group을 사업유형별로 분리해 런타임에 검증 규칙 분기

• 사내 최초 QueryDSL 도입으로 혼재된 쿼리 방식 통일 · 컴파일 단계 쿼리 오류 사전 감지

  문제Data JPA·Criteria API·Native Query 세 방식이 혼재해 유지보수 시 구현 방식 파악이 부담이고, Native Query는 오타가 런타임에야 발견됨

  분석팀의 초기 회의론을 자산 현황 모듈 파일럿으로 설득 → 타입 안정성·가독성 개선을 직접 시연 후 지사 내 3개 프로젝트로 확산