신세계인터내셔날 연동 API 보안 인증
Zendesk · ECP · MBS 3중 연동 게이트웨이에서, 정보보안 취약점 대응으로 기간계(MBS) 호출을 고정 인증키에서 토큰 발급·캐싱·자동 재발급 방식으로 바꾸고 38일간 멈춰 있던 스케줄러 장애도 찾아 해결했습니다.
- 기간
- 2026.02 - 2026.05
- 소속
- 지에스네오텍(주)
- 역할
- 백엔드 개발
- 기여도
- 100%
Background
신세계인터내셔날은 상담 플랫폼 Zendesk와 사내 시스템을 여러 Spring Boot 게이트웨이 모듈로 연결합니다. 홈페이지·SSG 문의는 상담 플랫폼 Zendesk, 고객이 VOC 문의 게시글을 작성하는 ECP, 문의·답변 이력과 회원 정보를 관리하는 기간계 MBS 세 시스템을 오가는 3중 연동입니다. 게이트웨이가 ECP에서 문의를 가져와 MBS에 기록한 뒤 Zendesk 티켓으로 만들고, 상담원 답변은 MBS 확인을 거쳐 ECP에 등록한 다음 MBS에 다시 남깁니다. 정보보안 취약점 점검에서 MBS 호출이 설정 파일의 고정 인증키에 의존한다는 지적을 받아, MBS가 발급하는 토큰으로 인증하는 방식으로 전환하는 작업을 맡았습니다(ECP 쪽 인증은 전환 대상이 아니었습니다). 토큰을 쓰는 3개 모듈(legacyGw, suspendedUser, outCome)에 같은 패턴으로 적용하면서 환경 설정과 공통 통신 코드도 함께 정비했습니다.
Key Work
- 01Zendesk · ECP · MBS 3중 연동 흐름(문의 수집 Pull / 답변 전송 Channelback)의 MBS 호출 단계마다 토큰 인증 적용
- 02토큰 인증 시스템: IP + API 코드 단위로 토큰을 DB(T_TOKEN)에 캐싱해 재사용하고, 인증 오류 코드를 받으면 재발급 후 1회 재시도
- 03legacyGw · suspendedUser · outCome 3개 모듈에 같은 인터페이스(getCachedOrNewToken / refreshToken)와 설정 키로 통일 적용
- 04실제 기간계 없이 토큰 흐름을 시험하는 로컬 Mock 토큰 서버 모듈 추가
- 0512개 모듈의 HTTP 통신 유틸(CommonUtil) 시그니처 정리와 공통 에러 핸들러 도입
- 06전 모듈 local / dev / prod 환경별 설정 정비, Tomcat 환경별 설정·setenv 스크립트와 설정 가이드 페이지
- 07전 모듈 외부 API 호출 전후 DEBUG 로그(dev/local 전용 로그 파일로 분리)
- 08개발명세서 · DB설계서 · 기술 참조 문서 작성, CLAUDE.md 팀 컨벤션과 작업 로그 슬래시 커맨드
Problem & Solution
Problem 01
기간계 API를 설정 파일에 들어 있는 고정 인증키로 호출하고 있어, 정보보안 취약점 점검에서 외부 호출 보호가 부족하다는 지적을 받았습니다.
Solution
고정 인증키를 제거하고 기간계 토큰 발급 API로 받은 토큰을 Authorization: Bearer 헤더로 보내도록 바꿨습니다. 요청자 IP를 X-Forwarded-For로 함께 전달해 기간계가 실제 요청자를 식별할 수 있게 했습니다.
Problem 02
매 요청마다 토큰을 새로 발급받으면 기간계 부하가 커지고, 처음 설계한 'DB 만료 시각 기준' 판단은 실제 서버의 토큰 만료와 어긋났습니다. 재발급 흐름에도 불필요한 DB 왕복이 3번 있었습니다.
Solution
토큰을 IP + API 코드 단위로 DB에 캐싱하고, 만료 여부는 기간계 응답 코드로 판단하도록 바꿨습니다. 토큰 인증 오류 코드일 때만 재발급하고, 무효화-재조회-저장으로 나뉘어 있던 흐름을 refreshToken 하나로 합쳐 DB 왕복 3회를 없앴습니다.
Problem 03
같은 토큰 기능이 3개 모듈에 서로 다른 설정 키, 메서드 이름, 클래스 구조로 들어가 있어 한 곳을 고치면 나머지를 따로 찾아 고쳐야 했습니다.
Solution
세 모듈의 토큰 서비스를 같은 인터페이스와 구현체 구조로 맞추고 설정 키를 하나로 통일했습니다. 호스트 설정에서 경로를 분리해 환경별 설정값은 순수 호스트만 갖도록 표준화했습니다.
Problem 04
작업 중 휴면·탈퇴 회원 처리 스케줄러가 2026.03.26부터 38일째 Zendesk API 응답을 기다리며 멈춰 있는 것을 발견했습니다.
Solution
jstack으로 스레드 상태를 확인해 HTTP 클라이언트에 타임아웃이 없던 것이 원인임을 찾았습니다. 전 프로젝트에 연결 10초 · 읽기 30초 타임아웃과 JDBC 쿼리 타임아웃 5초를 적용하고, 작업 완료를 기다리는 무한 루프에 최대 횟수를 두고, 재처리 시 중복 INSERT를 막았습니다.
Problem 05
세 시스템을 오가는 흐름이라 어느 구간에서 실패했는지 드러나지 않았고, 실제 MBS와 붙여 보니 응답 키 이름이 문서와 달라 토큰이 null로 저장되고, Bearer 접두어 누락, Oracle 예약어 컬럼, 파라미터 타입 오류가 연달아 나왔습니다.
Solution
ECP 요청 · MBS 토큰 조회와 재발급 · MBS 요청과 응답 · DB 조작 전후에 시각과 소요 시간을 담은 로그를 남겨 실패 구간을 하나씩 좁혀 고쳤습니다. 로컬 Mock 토큰 서버도 실제 서버와 같은 형식으로 응답하게 맞춰 같은 문제가 테스트에서 먼저 드러나게 했습니다.
Problem 06
환경 설정이 모듈마다 제각각이었고, 프로파일 설정이 OS 환경변수를 읽도록 되어 있어 변수가 없으면 개발 서버도 항상 운영(prod) 설정으로 떴습니다. 개발 환경에서는 문의 수집이 같은 문의번호를 반복하는 무한 루프도 있었습니다.
Solution
전 모듈의 local / dev / prod 설정과 Tomcat 설정 파일, setenv 스크립트를 정비하고 탭형 설정 가이드로 정리했습니다. 프로파일 폴백 문제를 고치고, 개발 환경 분기와 마지막 문의번호 갱신으로 무한 루프를 막았습니다.
Results
- ✓3중 연동을 포함한 3개 게이트웨이 모듈의 MBS 호출을 토큰 기반 인증으로 전환해 정보보안 취약점 대응 완료
- ✓토큰 연동이 안정된 뒤 전환 기간용 임시 fallback 코드를 계획대로 제거
- ✓38일간 멈춰 있던 스케줄러 장애 원인을 찾아 전 모듈에 타임아웃 적용
- ✓개발명세서 · DB설계서 · 환경 설정 가이드로 다음 담당자가 바로 이어받을 수 있게 문서화
Learnings
- →외부 시스템 연동은 문서가 아니라 실제 응답을 기준으로 확인해야 한다는 점
- →타임아웃 없는 네트워크 호출은 언젠가 멈추며, 장애는 jstack 같은 근거로 좁혀야 한다는 점
- →같은 기능을 여러 모듈에 넣을 때는 인터페이스와 설정 키부터 통일해야 유지보수가 쉬워진다는 점
- →임시 방어 코드는 넣을 때부터 제거 시점을 함께 계획해야 한다는 점