정다솔Dasol Jung

주요 문제 해결

1. 문제주니어 개발자들이 복잡한 레거시 코드를 충분히 분석하지 않고 그대로 복사해 재사용하면서 비효율적인 구조가 계속 재생산되었고, 코드 검측률 저하와 일정 지연으로 이어졌습니다.

   해결정형화된 아키텍처와 코드 구조를 설계해 팀 내 개발 기준을 세우고, 레거시를 컴포넌트·인터페이스 단위로 모듈화해 공통으로 제공했습니다. 팀원 모두가 같은 규칙과 흐름 안에서 개발하도록 만들었습니다.

2. 문제반대로 일부 구성원은 기존 레이어를 무시하고 개인 스타일로 개발해, 복잡한 건설 도메인이 표준 없이 구현되면서 인수인계와 유지보수 부담이 급격히 커졌습니다.

   해결개발자마다 따로 만들던 로직을 하나의 공통 모듈로 통합하고, 응답 처리·에러 핸들링 같은 관심사를 분리해 일관된 방식으로 수행하도록 했습니다. 퍼사드, 아토믹, 팩토리, 싱글톤 패턴을 상황에 맞게 적용해 모듈 간 의존성을 낮췄습니다.

3. 문제착공계 문서 관리는 문서 승인 흐름, 상태 관리, 리포팅 등 세부 요구사항이 많은 플랫폼의 핵심 기능이었고, 다른 모듈과 데이터를 주고받아야 했습니다.

   해결건설 도메인을 빠르게 학습해 승인 흐름과 상태 관리를 서비스 로직에 반영하고, Server-to-Server 통신과 RESTful API를 직접 설계해 모듈 간 데이터를 교환했습니다. Ubi-Report로 리포팅을 자동화했습니다.

주요 문제 해결

1. 문제상담원은 제품을 고른 뒤 긴 CallCode 목록에서 해당 상담에 맞는 코드를 직접 찾아야 했고, 고객이 말한 증상과 CallCode 사이의 연결이 화면에 드러나지 않았습니다.

   해결증상(3뎁스)을 먼저 고르면 CallCode를 불러오도록 입력 흐름을 바꾸고, 증상-CallCode 매핑으로 연관 코드 상위 3개를 자동 추천했습니다. 추천 밖의 코드는 [ALL] 버튼으로 전체를 볼 수 있게 했습니다.

2. 문제10월 전환은 법인군마다 셧다운 시작 시각이 달라, 7월처럼 셧다운 상수를 직접 바꿔 재배포하는 방식으로는 대응할 수 없었습니다. 기존 구조도 '전환 대상은 모두 아시아 리전'이라는 전제라 유럽 리전을 표현하지 못했습니다.

   해결리전·대상 국가·셧다운 시작·오픈 시각을 담은 일정표와 현재 단계를 계산하는 함수로 바꿔, 일정만 미리 등록해 배포하면 재배포 없이 자동 전환되게 했습니다. 전환 국가 목록도 리전별 구조로 개편했습니다.

3. 문제10월 작업 중 7월 전환에서 '법인 1개 = 국가 1개'로 등록해 10개국이 빠져 있던 것을 발견했고, 앱에 들어 있는 국가코드 파일도 운영 데이터와 달랐습니다.

   해결운영 Zendesk의 Custom Object를 기준 데이터로 정하고 대상 국가 조회·누락 점검 스크립트를 만들어 누락된 10개국을 바로잡았습니다. 국가코드 선조회를 RUNBOOK과 CLAUDE.md의 필수 규칙으로 남겼습니다.

주요 문제 해결

1. 문제기간계 API를 설정 파일에 들어 있는 고정 인증키로 호출하고 있어, 정보보안 취약점 점검에서 외부 호출 보호가 부족하다는 지적을 받았습니다.

   해결고정 인증키를 제거하고 기간계 토큰 발급 API로 받은 토큰을 Authorization: Bearer 헤더로 보내도록 바꿨습니다. 요청자 IP를 X-Forwarded-For로 함께 전달해 기간계가 실제 요청자를 식별할 수 있게 했습니다.

2. 문제매 요청마다 토큰을 새로 발급받으면 기간계 부하가 커지고, 처음 설계한 'DB 만료 시각 기준' 판단은 실제 서버의 토큰 만료와 어긋났습니다. 재발급 흐름에도 불필요한 DB 왕복이 3번 있었습니다.

   해결토큰을 IP + API 코드 단위로 DB에 캐싱하고, 만료 여부는 기간계 응답 코드로 판단하도록 바꿨습니다. 토큰 인증 오류 코드일 때만 재발급하고, 무효화-재조회-저장으로 나뉘어 있던 흐름을 refreshToken 하나로 합쳐 DB 왕복 3회를 없앴습니다.

3. 문제작업 중 휴면·탈퇴 회원 처리 스케줄러가 2026.03.26부터 38일째 Zendesk API 응답을 기다리며 멈춰 있는 것을 발견했습니다.

   해결jstack으로 스레드 상태를 확인해 HTTP 클라이언트에 타임아웃이 없던 것이 원인임을 찾았습니다. 전 프로젝트에 연결 10초 · 읽기 30초 타임아웃과 JDBC 쿼리 타임아웃 5초를 적용하고, 작업 완료를 기다리는 무한 루프에 최대 횟수를 두고, 재처리 시 중복 INSERT를 막았습니다.

주요 문제 해결

1. 문제local, dev, preview, prod 네 환경이 필요했지만 Supabase 무료 플랜은 프로젝트가 2개로 제한되었고, 어느 브랜치에 push하든 Vercel이 빌드를 돌려 빌드 자원이 낭비되었습니다.

   해결local/dev/preview는 개발 DB를 공유하고 운영 DB만 분리하는 2-프로젝트 전략을 세우고, 파일 스토리지(Cloudflare R2)도 staging/prod 버킷으로 나눴습니다. Vercel ignoreCommand로 preview와 main만 빌드되게 했고, bash 전용 문법 때문에 조건이 무시되던 문제를 POSIX 호환 문법으로 고쳐 의도대로 동작하게 만들었습니다.

2. 문제외부에서 API를 마음대로 호출할 수 있었고, 버튼을 연달아 누르거나 네트워크가 재시도하면 같은 요청이 중복으로 처리될 수 있었습니다.

   해결모든 Route Handler가 거쳐 가는 공통 래퍼(withHandler)에 IP·Origin에 묶인 JWT 검증을 넣고, 공통 apiClient가 토큰을 자동으로 붙이고 만료되면 재발급 후 재시도하게 했습니다. 클라이언트는 진행 중인 같은 요청을 재사용하고, 서버는 Idempotency-Key 캐시로 중복 처리를 막아 이중 방어했습니다.

3. 문제로그인한 사용자의 거의 모든 요청마다 인증 확인 뒤 users 테이블을 한 번 더 조회해, 요청당 DB 왕복이 불필요하게 하나씩 더 붙어 있었습니다.

   해결계정 상태, 정지 기간, 가입 완료 시각을 인증 토큰의 app_metadata에 동기화해 두고 미들웨어가 그 값을 바로 읽게 바꿔 요청당 DB 왕복을 절반으로 줄였습니다. 값을 바꾸는 세 곳(제재 처리, 소셜/이메일 가입 확정)에 동기화를 넣고, 기존 계정 데이터 누락으로 생긴 소셜 로그인 리다이렉트 루프도 함께 해결했습니다.