백엔드 엔지니어
박상수

문제와 제약

PC·모바일에 유사 기능과 레거시 규칙이 흩어져 변경 영향과 API 중복이 커지는 구조였습니다.

설계와 구현

• 지원 도메인의 주요 기능을 Java 기반 서비스로 전환
• 유사 기능을 분류해 PC·모바일이 함께 쓰는 API 계약 설계
• 채널 요구는 BFF에서 흡수하고 핵심 지원 규칙은 도메인 경계에 집중

문제와 제약

한 사용자가 여러 공고에 동시에 지원하면 기존 지원 흐름의 서버·DB 부하가 증폭될 수 있었고, 추천 대상 추출에는 20개 이상의 조건이 얽혀 있었습니다.

설계와 구현

• 기존 지원 쿼리 전체를 DBA와 함께 검토
• 지원 소스와 처리 흐름을 리팩터링
• 복잡한 추천 조건을 유지하면서 DB 부하가 커지지 않도록 조회·처리 범위 점검

문제와 제약

지원자 인쇄 정보 불일치와 브라우저 백그라운드 탭의 재귀 호출처럼 간헐적이고 표면 증상만으로 원인을 찾기 어려운 문제가 있었습니다.

설계와 구현

• 요청 경로와 API 사용 맥락을 추적해 목록 API 오사용을 식별
• 프런트 전면 교체의 부작용 대신 인쇄 목적의 전용 API를 설계
• 대량 호출 패턴을 로그·브라우저 동작과 연결해 재귀 실행 원인을 제거

문제와 제약

외부 노출 URL의 파일 접근, 개인정보 열람 이력, 장기간 누적된 탈퇴 데이터처럼 애플리케이션과 데이터 운영을 함께 다뤄야 하는 과제였습니다.

설계와 구현

• 레거시 파일 다운로드 경로에 인증 세션 검증 추가
• 개인정보 조회 로그와 암호화된 관리용 내보내기 구현
• 2012년부터 누적된 1,400만 건 이상의 파기 대상 데이터를 DBA와 다중 검증 후 저부하 시간대에 통제 실행

문제와 제약

광고성 메일·문자 수신 설정이 과거 변경 이력을 복원하기 어려운 구조여서 감사 가능성과 운영 정확성이 부족했습니다.

설계와 구현

• 현재 상태와 변경 이력을 분리해 관리할 수 있도록 저장 구조 개선
• 이력이 없는 기존 회원의 기준 로그 생성
• 관리자 화면과 백엔드를 함께 구현해 조회·수정 흐름을 일관되게 연결

문제와 제약

새 채팅 플랫폼은 알바몬과 독립적으로 유지되어야 했고, 반복 개발 문의와 운영 확인은 담당자 의존을 키우고 있었습니다.

설계와 구현

• 알바몬 측 연동 경계와 API를 분리해 플랫폼 독립성 유지
• 채팅 백엔드 구현·배포·운영을 단독 담당하고 팀 리뷰 수행
• 과거 지원·제안 발신 이력을 운영자가 직접 조회하는 관리 기능의 기획·FE·BE 구현

문제와 제약

기존 발송 프로세스가 없는 상태에서 사용자 행동 시점에 맞는 알림, 앱 딥링크, 발송 결과 집계까지 한 흐름으로 구축해야 했습니다.

설계와 구현

• 발송 시점과 대상 조건을 업무 규칙으로 정리
• 알림톡 메시지와 앱 딥링크를 연결하고 결과 통계 저장 구조 설계
• 대상 추출·발송·결과 반영 배치를 처음부터 구현하고 운영 지표를 점검

문제와 제약

운영성 조회가 주 데이터베이스에 부담을 줄 수 있었고, 백업 데이터를 복원하는 검증 환경에서는 사용자 식별 정보의 불일치가 반복될 수 있었습니다.

설계와 구현

• 부하가 큰 조회의 실행 경로와 쿼리를 검토해 읽기 전용 데이터베이스로 분리
• 백업 복원 뒤 식별 정보를 일관되게 맞추는 동기화 배치 구현
• 적용 전후 실행 흐름과 데이터 정합성을 반복 검증