미리보기

• 사내 쇼핑몰 구축 솔루션 주문, 결제 도메인 업무 수행

  • KIS, 이니시스 등 PG사 연동 개발

• 만 2년간 총 6번의 이커머스 계열 SI 프로젝트 경험, 상품, 주문 등 이커머스의 코어한 도메인 업무 경험

• 상품 조회 쿼리 성능 개선(60s -> 3ms)

• 온프레미스 환경-> KTCloud로 시스템 아키텍처 전환

• 기존 모놀리식 구조에서 주문, 회원 등 도메인별 API 서버를 분리하여 독립적으로 구성

• JSP, Tiles -> Nexacro 어드민 프로젝트 프론트엔드 기술 전환

• 신규 어드민 기능 및 API 개발

주요 업무

• 소스 코드와 Tomcat, IDE를 통합 패키징하여 폐쇄망 환경에서도 고객사에서 로컬 개발 환경을 간편하게 설정할 수 있도록 제공

• 노후된 가이드 문서를 대체하기 위해 로컬 환경 설치 및 이용 가이드 문서를 제작해 제공

• NCP / Rocky Linux8 환경에서 SVN, Jenkins, Apache, WAS 등 인프라 구축

• Jenkins의 MavenProject 플러그인을 활용한 CI/CD 파이프라인 구축

문제 해결

1대의 서버에 구축된 Jenkins와 Tomcat에서 각각 다른 Java 버전 사용

문제 상황

• WAS 서버에 Jenkins도 함께 구축해야하는 상황에서

  프로젝트 구동을 위해 시스템 기본으로 설정한 Java 버전과 Jenkins 실행에 필요한 Java 버전이 달라 Jenkins가 실행되지 않는 문제.

원인 분석

• 설치한 Jenkins 버전은 2.479 LTS 버전으로 Java 17이상에서 실행되나, 프로젝트 구동을 위해 설정한 서버의 시스템 기본 Java 버전은 8로 설정되어 Jenkins 실행시 오류 발생.

실행

• 해당 서버에는 2개의 프로젝트를 실행하고 있기 때문에 시스템 기본으로 설정한 Java의 버전은 변경하지 않고, Jenkins 실행에 필요한 JVM 버전만 변경하기로 결정.

• Jenkins 실행에 필요한 Java 버전만 변경할 방법을 찾기 위해 Jenkins 공식 문서(https://www.jenkins.io/doc/book/system-administration/systemd-services/)를 참고하여 jenkins systemd 구성을 재정의 하는 것으로 해결방법 확인.

• jenkins.service에서 JAVA_HOME, JENKINS_JAVA_CMD 환경 변수를 추가하고 해당 환경 변수에 Java17 경로를 지정해 Jenkins 실행시에만 Java17로 사용되도록 설정 변경.

주요 업무

• PMO 업무를 지원하며, 기술에 한정적이지 않고, 사업적 관점으로 시야 확장.

  • 사내 협업툴 관리, 신규 입/퇴사자 자원 관리, 보안 문서 관리 진행

  • TA와 협업해 내부망 환경 구축에 필요한 UTM 장비 보안 정책 수립

  • 고객사와의 주기적인 커뮤니케이션에 주도적으로 참여해, 요구사항을 취합하고, 각 담당자에게 전달하는 게이트웨이 역할 수행

• 문서화가 전무한 상황에서 온보딩 프로세스, 개발 환경 설정, 커밋 메세지 컨벤션, 약어 사전 등 10개+의 문서를 작성해 신규 근무자들이 빠르게 업무에 투입 가능하도록 개선하고, 문서화의 중요성을 강조

• 배포 단계에 SonarCube 정적 분석을 도입해 취약점 보완 및 보안 수준 향상

• 가동성이 떨어지는 기존 API 요청, 응답 로그를 개선

• python, FastAPI와 학습된 deeplab 모델을 활용해 이미지 배경제거 API 개발

  • 등록 규격에 어긋나는 이미지를 매번 직접 수정하는 서비스데스크 업무의 비효율성을 개선

문제 해결

외부 연계 상품 조회 API Timeout 문제 식별 및 해결

문제 상황

• 외부 사이트의 연계 상품 조회 API 요청시 Connection Timeout 에러가 발생하여 화면에 노출되지 않음.

• 디버깅 해본 결과 API 응답이 503 Service Unavailable로 반환된 것을 확인.

원인 분석

• 현재 서비스는 Samsung Cloud Platform에서 서비스 되고 있음.

• 브라우저에서 직접 URL로 API 요청을 보낼 경우 결과가 정상적으로 리턴됨 → 대상 서버의 오류는 아닌 것으로 확인.

• 외부 연계 상품 조회 API는 따로 구성한 Proxy 서버를 통해서 연결을 하고, 아래와 같은 네트워크 흐름을 가짐.

  WAS -> Proxy 서버 -> NAT GW -> Samsung Cloud 보안 관제센터 -> 대상 서버

• 보안그룹과 방화벽 정책을 확인한 결과, 대상서버에 대한 차단 정책은 적용되어있지 않음.

• Proxy 서버의 Squid 프록시 설정은 2024년 2월 4일 이후로 변경되지 않음.

해결

• 분석한 내용을 근거로 클라우드 보안관제센터에서 차단되었을 가능성을 확인하기 위해 문의한 결과, File Inclustion 공격 의심으로 차단된 이력 확인.

• PM께 보고 및 보안 관제센터에 차단 해제 요청 후 테스트 결과 정상적으로 결과를 받아오는 것을 확인함.

개발 환경

• FrontEnd : JSP / JavaScript / jQuery / Nexacro

• BackEnd : Java11 / 전자정부프레임워크 4.1 / MyBatis

• DB : MariaDB

• Infra : SCP / JBoss / nginx / Jenkins

• VersionControl : git, gitLab

주요 업무

• JSP와 Tiles3로 구성된 어드민 화면을 Nexacro N24로 기술 전환을 진행.

  • 직관성이 중요한 어드민 화면에서 디자인에 소모되는 리소스를 감소하고 생산성 증가.

• 공통코드로 관리하던 상품 카테고리를 별도의 관리 API를 개발해 어드민 사용자가 상품 카테고리를 편하게 관리할 수 있도록 업무 효율 개선.

• 커스텀한 Nexacro 주소검색 컴포넌트 개발

  • 지번 주소, 도로명 주소 중 하나의 값만 저장할 수 있던 Nexacro 기본 제공 컴포넌트의 한계 극복.

  • 기존 시스템의 요구사항에 따라 유연하게 대처할 수 있도록 개선.

문제 해결

@Transacational(propagation= REQUIRES_NEW)가 적용되지 않는 문제 식별 및 개선

문제 상황

기존 레거시 시스템에서 별도의 트랜잭션을 생성해 Key값을 생성하는 로직에서 중복 Key가 생성되는 문제 확인.

원인 분석

• 해당 로직에는 @Transactional 어노테이션과 함께 전파속성이 REQUIRES_NEW로 설정되어 있음.

• 트랜잭션 관련 Log Level을 DEBUG로 설정하고 트랜잭션의 생성부터 close될 때까지 로그를 분석한 결과, 현재 생성되어있는 트랜잭션에 참여해 로직을 수행하는 것으로 확인.

• 이를 통해 Nexacro를 적용하기 위해 설정한 샘플 프로젝트와 레거시 시스템 프로젝트를 병합하는 과정에서 트랜잭션 설정이 누락되어있거나, xml방식의 트랜잭션 설정시 해당 메서드에 대한 PointCut이 누락되었을 가능성을 유추.

• 트랜잭션 설정을 확인한 결과, 어노테이션 기반 트랜잭션 설정이 누락되어 있었고, xml 방식의 설정에서도 해당 메섣즈에 대한 PointCut이 누락된 것을 확인.

해결

• 기존 시스템은 어노테이션 기반의 트랜잭션 설정을 사용했기 때문에 xml 방식의 설정을 제거하고, 어노테이션 기반의 트랜잭션 설정을 추가하여 해결.

개발 환경

• FrontEnd : JSP / JavaScript / jQuery / Nexacro

• BackEnd : Java8 / SpringFramework / SpringMVC / MyBatis

• DB : MariaDB / postgreSQL

• VersionControl : SVN

주요 업무

• 결제 연동 모듈 변경 및 최적화.

  • 기존 이니시스 결제 모듈을 KIS 결제 모듈로 변경하여 연동 로직 설계 및 구현

  • 기존 코드의 변경을 최소화하기 위해 PG 연계 기능 모듈화하여 유지보수성 향상.

  • 결제 수단 관리 방식을 DB 기반 공통코드 -> Enum 객체로 전환해 불필요한 DB 조회를 줄이고 성능을 최적화.

• 위치기반 제휴 병원 찾기 서비스 개발 및

  UX 개선

  • 하버사인 공식을 활용한 사용자와 병원간 거리 계산 알고리즘을 도입해, 위치기반 제휴 병원 검색 기능 개발.

  • Geolocation API를 사용해 정확한 위치기반 병원 검색 서비스 제공.

  • 병원데이터가 늘어남에 따라 하버사인 공식을 사용한 조회 성능이 저하되고 있어, 공간 데이터타입 및 공간 인덱스 적용으로 쿼리 성능 개선(3s -> 0.8s)

• 대량 메일 및 알림 서비스 개발

  • 드림라인 UMS 솔루션 연동을 통해 알림톡, SMS, 이메일 발송 기능 구현

  • 예약, 결제 상태, 검진 결과 등 사용자 상태에 따른 맞춤형 알림 발송 시스템 구축

• 관리자 페이지 기능 개선

  • 카카오 알림톡 템플릿 관리 기능을 개발해 문자형, 버튼형 등 다양한 템플릿을 쉽게 등록, 수정, 삭제할 수 있도록 기능 제공

문제 해결

병원 검색 기능의 느린 응답 속도 개선

문제 상황

• 병원 데이터가 많아질수록 검색 속도가 느려지고 사용자로부터 병원 목록이 늦게 뜬다는 피드백이 발생.

• 확인 결과 평균 응답 시간이 3초 이상으로 증가해 사용자 경험 저해되고 있음.

원인 분석

• 거리 계산 쿼리의 비효율성 확인

  • 병원과 사용자간 거리를 계산하는 하버사인 공식이 DB 내에서 수행되고 있어, 숫자 기반 비교 및 거리 계산을 해야함.

  • 병원 테이블에 적절한 인덱스가 없어 전체 테이블 스캔이 발생해 성능이 저하됨.

• 불필요한 병원 데이터 반환

  • 사용자와 과도하게 멀리 떨어진 병원의 데이터도 반환되면서 처리량이 증가.

해결

• 데이터 타입 변경 및 공간인덱스 생성

  • 위도와 경도를 개별 컬럼으로 저장하던 기존 방식을 Oracle의 공간 데이터 타입의 컬럼을 추가.

  • 기존 위도, 경도 값을 이용해 공간데이터 컬럼을 UPDATE.

  • 공간 데이터 정보를 Oracle 메타 데이터 테이블에 등록.

  • MDSYS.SPATIAL_INDEX 타입의 공간 인덱스 추가.

• 쿼리 조건 추가

  • 사용자와 과도하게 멀리 떨어진 병원의 데이터가 조회되는 것을 제한하기 위해, 사용자가 10km, 20km, 30km 중 선택한 값을 조건으로 제한하도록 변경.

• 위와 같은 해결방법으로 평균 응답시간이 3s -> 0.8s로 감소

개발 환경

• FrontEnd : JSP / JavaScript

• BackEnd : Java8 / SpringFramework5 / SpringMVC

• DB : Oracle 19c

• Infra : AWS EC2 / AWS S3 / Jenkins

• VersionControl : SVN

주요 업무

• Maven 멀티 모듈 기반 Spring 레거시 프로젝트에서 Gradle 멀티모듈 기반 SpringBoot로 전환

• 온프레미스 환경에서 운영 중이던 프로젝트를 KTCloud 환경으로 이전

• 모놀리식 구조에서 주문, 회원 등 도메인별 API 서버를 분리해 독립적으로 구성

• Redis, Spring Data Redis를 사용해 도메인 API 서버간 Session이 공유될 수 있도록 클러스터링

• API 문서화를 통한 API 명세, 히스토리 관리

문제 해결

Redis와 Spring Data Redis를 사용한 세션 클러스터링 및 캐싱 전환

문제 상황

• 세션 데이터 관리 문제

  • 회원이 로그인한 후 주문 API를 호출했을 때, 세션이 풀려버리는 문제가 발생.

  • 로드밸런서가 다른 서버로 요청을 분산할 경우 세션 데이터가 부재해 로그인 상태를 유지할 수 없음.

원인 분석

• 세션 데이터 관리

  • JWT 토큰을 사용하는 것은 현재 개발 공수 등의 영향으로 세션 방식을 유지하는 제약 조건.

  • 도메인별 API 서버가 분리됨에 따라 각 서버별로 별도로 세션을 관리하게 되어, 다른 서버에 요청시 세션 데이터가 유실됨.

  • 각 서비스 Pod가 스케일 아웃될 경우에도 동일한 현상이 발생할 것으로 예상.

해결

분산 환경에서 세션 데이터를 관리하기 위한 방법으로 대표적으로 Sticky Session과 별도 저장소를 사용한 세션 클러스터링이 있지만, 아래와 같은 이유로 Redis를 도입해 세션 클러스터링을 구현하는 것으로 결정함.

• Sticky Session 사용시 사용자의 요청이 특정 서버에 의존하게됨. -> 서버에 장애가 발생하면 해당 서버에 저장된 세션이 소실되어 더 큰 문제가 발생할 우려가 있음.

• 특정 서버에 트래픽이 집중될 경우 로드밸런싱 효율이 떨어지고 성능이 저하됨.

• 개발 공수의 문제로 JWT 토큰 방식으로의 변경은 고려하지 않음.

• KTCloud에서 Redis 서버 서비스를 제공하고 있어, 빠른 구성이 가능

  함.

• 로컬캐시를 사용해 캐싱하던 공통코드 또한 분산환경으로 변경됨에 따라 캐시 데이터 동기화시 전체 서버를 재배포 해야하는 문제가 발생해 중앙집중식 관리가 필요함.

결과

• 서버 장애 및 스케일 아웃 시에도 세션 데이터의 유실 없이 관리가 가능해짐.

• 사용자의 요청이 어느 서버로 라우팅 되더라도 동일한 세션을 참조 가능함.

• 캐시 데이터 변경시 서버 재배포 없이 Redis에 직접 업데이트해 운영 부담을 최소화하고, 평균 응답 시간을 유지함.

• 변경 빈도가 높은 데이터를 캐싱할 때에도 실시간 반영이 가능해 서비스 가용성이 확보됨.

개발 환경

• FrontEnd : JSP / JavaScript

• BackEnd : Java11 / SpringBoot 2.7 / Spring Data Redis

• DB : MySQL, Redis

• Infra : KT Cloud / Docker / Kubernetes / ArgoCD

• Monitoring : Grafana

• VersionControl : Git, GitLab

주요 업무

• 신규 어드민 페이지 개발

• 여행 상품 등록 기능을 개선하여, 입점 업체들이 상품을 더 간단하게 등록하고 더 빠르게 쇼핑몰에 노출되어 매출로 이어질 수 있는 시간을 단축(일 평균 상품 등록 건수 4배 증가)

• 상품 조회 쿼리 성능을 기존 60초 -> 2초로 개선하여 업무 효율을 증가

• 상용 B2C 커머스 서비스를 분석하고 개발하면서 이커머스 도메인에 대한 업무 지식 습득

문제 해결

상품 조회 쿼리 성능 최적화

문제 상황

• 상품 데이터가 증가함에 따라 어드민 페이지에서 상품 목록 조회에 60초 이상 소모되어 Timeout이 발생하는 문제 발생.

원인 분석

• 목록 조회 요청시 페이징 처리에 필요한 COUNT 쿼리가 목록조회 쿼리와 분리되지 않고, 인터셉터에서 목록 조회 쿼리를 감싸 COUNT를 실행하고 있음.

• 서로 반대되는 조건으로 조회한 내용을 합치기 위해 UNION ALL을 사용했으나, 두 조건의 결과의 50%가 중복 row로 조회됨.

• 실행계획을 분석한 결과, 상품 목록 조회시 필수적으로 필요한 필터 조건에 대해 인덱스가 없어 테이블 FullScan이 발생함.

• 실제 상품목록 페이지에 사용하지 않는 불필요한 컬럼까지 조회하고 있어 효율이 떨어짐.

해결

• 목록 조회 쿼리를 감싸 카운트 쿼리를 실행하던 것을 별도의 카운트 쿼리를 작성해 실행하는 것으로 변경.

• 상품 목록 조회에 필수적으로 사용하는 필터 조건 컬럼들에 복합 인덱스를 추가하고, 실행 계획을 확인해 인덱스가 제대로 활용되는지 검증.

• 모수를 줄이기 위해 필요한 컬럼만 SELECT 하도록 수정.

• UNION ALL을 통해 합치던 두 조건을 분석해 하나의 WHERE 조건으로 정리하고, UNION ALL을 제거해 중복 row 제거하고 쿼리 구조를 단순화.

결과

• 조회 성능 60s -> 2s로 단축.

• 타임아웃 발생률이 0%로 감소해 사용자 경험이 크게 향상됨.

개발 환경

• FrontEnd : ExtJS / JavaScript

• BackEnd : Java8 / 전자정부프레임워크 / MyBatis

• DB : Oracle 19c

• VersionControl : SVN