SSUPPORT

Overview

SSUPPORT는 장학금 신청부터 서류 관리, 평가자 배정과 심사까지의 과정을 디지털화한 플랫폼입니다. 수백 건의 지원서를 접수하고 심사위원에게 분배하던 기존 수작업에서 발생하는 휴먼 에러와 반복 업무를 줄이는 것을 목표로 개발했습니다.

지원자가 사용하는 메인 서비스와 운영진을 위한 백오피스를 분리했습니다. 운영진은 기수와 심사 회차에 따라 평가자를 배정하고, 전체 심사 진행 상황을 일관된 화면에서 관리할 수 있습니다.

Architecture

Applicant Client ─→ REST API (Spring Boot) ─┐
                                             ├─→ MySQL
Admin Browser ────→ Thymeleaf Back Office ──┘
 
Route53 / CloudFront / S3 / AWS Infrastructure
                    ↑
              Terraform (IaC)

지원자용 서비스는 향후 다양한 클라이언트와 연동할 수 있도록 REST API 기반으로 설계했습니다. 내부 운영진이 사용하는 백오피스는 빠른 화면 개발과 서버 측 권한 제어에 적합한 Thymeleaf SSR 방식을 선택했습니다. 인프라는 AWS 위에 구성하고 Terraform으로 형상과 변경 이력을 관리합니다.

Tech Stack

My Role

• AWS와 Terraform 기반 서비스 인프라 아키텍처 설계 및 구축
• Thymeleaf 기반 장학금 심사 평가자 배정 백오피스의 UI와 백엔드 전체 설계 및 구현
• 기수·회차별 자동 배정과 지정 배정 비즈니스 로직 개발
• 백오피스 요청의 권한 및 cycleId 정합성 검증 로직 구현

Problem

장학금 심사는 단계마다 평가 방식과 담당자가 달랐습니다. 초반에는 여러 평가자가 많은 지원서를 빠르게 나눠 심사해야 했고, 후반에는 정책국장이나 총장 등 특정 권한자가 전체 서류를 최종 검토해야 했습니다. 하나의 고정된 배정 방식만으로는 실제 운영 절차를 표현하기 어려웠습니다.

또한 운영자가 백오피스에서 기수나 회차를 잘못 선택하면 다른 기수의 배정 데이터가 수정될 수 있어, 화면 편의성뿐 아니라 서버 측 데이터 정합성 검증도 필요했습니다.

Troubleshooting

심사 단계별 이원화된 배정 모델

• 초반 심사 — 자동 균등 배정: 다수의 평가위원에게 지원서를 가능한 한 고르게 분배해 심사 처리 속도를 높였습니다.
• 후반 심사 — 지정 배정: 마스터 권한자가 특정 회차의 전체 서류를 일괄 할당받아 최종 검토할 수 있도록 수동 지정 기능을 구현했습니다.

배정 현황 가시성과 데이터 무결성

서버에서 회차별 담당자 현황을 Map으로 구성하고 Thymeleaf 화면에 즉시 렌더링해, 운영자가 현재 배정 상태를 한눈에 확인할 수 있도록 했습니다. 폼 요청에 포함된 cycleId는 화면 값만 신뢰하지 않고 컨트롤러에서 다시 검증해 다른 기수의 데이터가 변경되는 것을 방지했습니다.

Terraform 기반 인프라 코드화

Route53, CloudFront, S3 등 AWS 리소스를 Terraform으로 관리했습니다. 수동 설정에 의존하지 않고 인프라 구성을 코드와 상태 파일로 추적해, 동일한 배포 환경을 재현할 수 있도록 했습니다.

운영 데이터 분석

서비스 배포 이후 신청자와 채점자의 실제 이용 흐름을 GA4 이벤트와 페이지 데이터를 바탕으로 분석했습니다. 사용자 수는 기기, 브라우저, 로그인 상태와 쿠키 환경에 따라 달라질 수 있으므로 정확한 실인원보다는 서비스 접속 규모로 해석했습니다.

신청자 운영

2026년 4월 30일부터 5월 14일까지 15일간 사용자 플로우, 신청 퍼널, 유입 채널과 인증·온보딩 과정을 분석했습니다.

온보딩 이후 신청 진입까지는 원활했지만, 신청 시작 대비 최종 제출 비율은 15.0%였습니다. 다만 이 값만으로 85%가 서비스 오류 때문에 이탈했다고 단정할 수는 없습니다. 자격 확인, 임시 저장, 중복 이벤트, 신청 의사 변경과 측정 설계의 영향이 함께 포함될 수 있으므로 단계별 이벤트를 더 세분화해 실제 이탈 구간을 확인해야 합니다.

일별 트래픽은 오픈일인 4월 30일 293명에서 감소한 뒤, 마감일인 5월 14일 255명으로 다시 증가했습니다. 마감 직전 파일 업로드, 문의와 제출 요청이 동시에 몰릴 수 있음을 확인해 다음 운영에서는 리마인드 알림과 업로드 구간 모니터링을 강화할 근거로 활용했습니다.

유입은 Direct가 1,406세션으로 전체의 58.8%를 차지했습니다. 공지, 카카오톡이나 문자처럼 직접 공유된 링크의 영향을 추정할 수 있지만, 정확한 채널별 성과를 확인하려면 이후 공지 링크에 UTM 파라미터를 일관되게 적용할 필요가 있습니다.

채점자 운영

2026년 5월 10일부터 6월 10일까지 한 달간 12명의 채점자가 207건의 신청서를 4회차에 걸쳐 평가하는 흐름을 분석했습니다. 총 828건의 배정이 모두 처리되었습니다.

채점 플로우는 로그인 → 지원자 목록 → 개별 채점 화면 → 지원자 목록의 반복 패턴으로 나타났습니다. 채점자가 화면과 평가 기준에 익숙해지면서 후반부 처리 시간이 뚜렷하게 감소했습니다.

이 감소는 사용자의 학습 효과와 후반 심사의 업무 특성이 함께 반영된 결과일 수 있습니다. 따라서 UI 개선만의 효과로 단정하지 않고, 다음 운영에서는 회차와 평가 유형을 별도 이벤트 속성으로 수집해 원인을 구분할 계획입니다.

Result

수작업에 의존하던 평가자 배정 과정을 시스템화해 반복 업무와 배정 실수 가능성을 줄였습니다. 심사 단계에 따라 자동 배정과 지정 배정을 선택할 수 있어, 실제 장학금 심사 프로세스의 서로 다른 운영 요구사항을 하나의 백오피스에서 처리할 수 있게 되었습니다.

실제 운영에서는 신청서 207건에 대한 4회차 배정, 총 828건이 모두 처리되었습니다. GA4 분석을 통해 온보딩 완료율 99.5%, 신청 완료율 15.0%, 채점 시간 중앙값 28초를 확인했고, 다음 운영에서 우선 개선해야 할 신청 퍼널과 측정 항목을 구체화했습니다.

Retrospective

서비스의 사용 목적에 따라 REST API와 서버 사이드 렌더링을 함께 사용하는 선택이 개발 효율과 운영 안정성을 높일 수 있음을 배웠습니다. 특히 관리자 화면에서는 화면 구현 속도뿐 아니라 권한 검증과 데이터 정합성을 서버에서 보장하는 것이 중요했습니다.

향후 지원서와 배정 이력이 더 많이 쌓이는 상황에 대비해 실제 쿼리 수와 실행 계획을 측정하고, 필요한 구간에 Fetch Join이나 조회 전용 쿼리를 적용할 계획입니다.

Links

• 서비스 방문하기