기업-평가위원 자동 배정 API 개발(기존 웹사이트 연동) 전문가

[프로젝트 개요]
운영 중인 웹사이트에 기업 신청 건을 평가위원에게 자동 배정하는 로직을 API로 개발해 연동하는 프로젝트입니다. 화면 개발 없이 배정 엔진과 기존 데이터베이스 연동 백엔드 API 한 벌을 구축합니다. 하루 60~80건 신청, 평가위원 40명 규모를 대상으로 합니다.

[추진 배경과 시점]
현재 운영 중인 웹사이트에는 배정을 수동으로 처리하는 화면과 평가위원이 본인에게 배정된 건을 조회하는 화면이 이미 마련되어 있으나, 어느 위원에게 배정할지를 정하는 로직은 시스템화되어 있지 않습니다. 하루 60~80건의 신청을 평가위원 40명에게 지역과 일일 한도를 고려해 배정해야 하는 규모여서, 이 판단 부분을 API로 자동화하는 것이 이번 프로젝트의 목적입니다. 배정 규칙과 기존 화면은 그대로 두고, 그 사이에서 동작하는 배정 로직만 새로 만듭니다.

[난점과 경위]
이 프로젝트의 핵심 난점은 하루 60~80건의 신청이 특정 시간대에 몰릴 때, 같은 평가위원에게 일일 한도를 초과하는 배정이 동시에 여러 건 나갈 수 있다는 점입니다. 배정 규칙 자체는 명확합니다(동일 지역 우선 배정 → 한도 초과 시 인접 지역 우회 → 전원 소진 시 대기 전환). 다만 다수 신청이 같은 순간에 처리될 때 배정 수를 정확히 세고 한도를 넘기지 않도록 데이터베이스 수준에서 막는 부분이 기술적으로 까다롭습니다. 규칙을 코드로 옮기는 것보다 이 정합성 처리가 이번 개발의 실질 난이도이며, 제안 시 이 부분을 어떻게 다룰지 밝혀 주시기 바랍니다.

[요구사항]
이번 범위는 화면 개발 없이 API 백엔드 한 벌이며, 다루는 데이터는 기존 웹사이트의 신청·기업·평가위원 데이터입니다.

배정 엔진
- 1차: 신청 기업과 동일 지역의 평가위원에게 배정합니다.
- 동일 지역에 복수 후보가 있을 때의 선택 기준은 당일 배정 수가 적은 위원 우선을 기본안으로 하며, 착수 전 협의로 확정합니다.
- 2차: 동일 지역 위원의 일일 한도가 다 차면 인접 지역 위원에게 우회 배정합니다.
- 3차: 인접 지역까지 모두 한도가 차면 수동 배정 대기로 전환합니다.

동시 신청 처리 (이번 개발의 핵심 난이도)
- 하루 60~80건 신청이 피크 시간대에 겹칠 때, 같은 위원에게 한도를 넘는 배정이 동시에 나가지 않도록 데이터베이스 수준에서 차단하는 로직을 구축합니다. 트랜잭션·잠금 등 구체 처리 방식은 제안사가 정합니다.

한도·일자 관리
- 위원별 일일 배정 한도를 카운터로 관리하고, 일자 경계 기준으로 초기화합니다.

연동 API
- 기존 웹사이트가 신청 접수 시 호출하는 배정 요청 API와 인증을 제공합니다.
- 위원별 당일 배정 수를 실시간으로 조회하는 API를 제공합니다.

데이터·연동 계층
- 기존 데이터베이스의 신청·기업·위원 테이블 구조를 파악하고 매핑합니다.
- 위원·인접지역·배정·카운터 테이블 및 컬럼을 추가하는 마이그레이션을 수행합니다.
- 시·도 단위 지역 인접 관계표를 구축해 적재합니다.

배포·검증
- 기존 서비스 환경에 배포하고 실제 연동 상태를 검증합니다.
- 하루 60~80건 피크 상황을 재현하는 시나리오·동시성 테스트를 수행합니다.

[사용자 스토리와 수용 기준]
- 기업이 신청을 접수하면 배정 API가 자동으로 담당 위원을 지정한다. 신청 완료 시 API가 호출되면 규칙에 따라 위원이 배정되고 결과가 반환되면 성공으로 처리된다.
- 동일 지역 위원의 한도가 다 차면 인접 지역 위원에게 배정된다. 동일 지역 위원 전원이 한도 초과 상태이면 인접 지역 위원 중 여유가 있는 위원에게 자동 배정된다.
- 인접 지역까지 모두 차면 수동 배정 대기로 넘어간다. 배정 가능한 위원이 없으면 해당 신청 건은 대기 상태로 전환되어 기존 화면에서 조회된다.
- 신청이 몰려도 한 위원에게 한도 초과 배정이 나가지 않는다. 피크 시간대 동시 신청에도 위원별 배정 수는 일일 한도를 넘지 않는다.

[업무 상태 흐름]
신청 건은 배정 완료, 수동 배정 대기, 이후 처리 완료 세 상태로 관리됩니다. 위원별 일일 배정 수는 일자 경계 기준으로 초기화되며, 자정 기준인지 영업일 기준인지는 착수 전 협의로 확정합니다. 화면 전이나 관리 도구의 조작 순서 설계는 제안사가 정합니다.

[비기능 요구]
하루 60~80건, 피크 시간대 동시 신청에서도 한도 초과 배정이 발생하지 않아야 합니다. 배정 API는 기존 사이트의 신청 처리 흐름 안에서 지연 없이 응답해야 합니다.

[외부 연동]
기존 운영 중인 웹사이트의 데이터베이스와 연동합니다. 그 외 외부 시스템 연동은 없습니다.

[스코프 밖]
관리자 화면·위원 조회 화면 등 화면 개발은 포함하지 않습니다(발주처 기존 시스템에 이미 있음). 신청 완료 시 배정 API를 호출하도록 하는 기존 사이트 측 코드 수정도 이번 범위에 포함하지 않습니다(발주처가 진행). 재배정·회수, 배정 이력·감사 조회, 통계 대시보드, 위원 알림 발송도 포함하지 않습니다.

[제약 사항 및 확인 필요]
기존 웹사이트는 JAVA 기반 웹 애플리케이션입니다. 데이터베이스 종류는 발주처가 현재 확인 중이며, 확정되는 대로 계약 전 협의로 전달됩니다. 데이터베이스 종류에 따라 마이그레이션 방식과 동시성 제어 구현 방식이 달라질 수 있습니다. 지역 인접 관계는 시·도 단위로 전제하며, 시·군·구 단위로 세분화될 경우 데이터 구축 범위가 달라질 수 있습니다. 평가위원별 일일 한도가 전원 동일 값인지 위원별로 다르게 설정되는지, 리셋 시 주말·공휴일 처리 방식은 확정 전입니다. 동일 지역 복수 위원 시 선택 기준, 위원 거절·사퇴 시 재배정 필요 여부도 착수 전 협의로 정합니다.

[클라이언트 준비 사항]
필요한 내용들을 알려주시면 기존 외주업체를 통해 받아드릴 예정입니다. 현재 소스 코드는 이관받는 과정중에 있습니다.

[기술 스택]
기존 웹사이트는 JAVA 기반 웹 애플리케이션이며, 이번 배정 API도 동일한 JAVA 환경에서 개발하는 것을 전제로 합니다. 프레임워크·빌드 도구·서버 구성 등 세부 사항은 계약 협의 시 전달됩니다. 데이터베이스 종류는 발주처가 확인 중이며, 확정 전까지 특정 제품을 전제하지 않습니다.

[원하는 파트너]
JAVA 기반으로 운영 중인 웹 애플리케이션에 API를 추가하고, 기존 데이터베이스에 접속해 스키마를 파악하고 안전하게 마이그레이션해 본 경험이 있는 백엔드 개발자를 찾습니다. 동시 요청이 몰리는 상황에서 데이터 정합성을 지키는 로직(트랜잭션·잠금 처리 등)을 다뤄본 경험을 우대합니다. 외부 시스템과의 API 연동 경험과, 짧은 일정 안에서 명확한 산출물을 내는 진행 방식을 중요하게 봅니다.

[제안 요청 사항]
제안서에 다음을 포함해 주십시오. 하루 60~80건 신청이 동시에 몰리는 상황에서 위원별 한도 초과 배정을 막기 위한 동시성 처리 방안(트랜잭션·잠금 등 구체 방식). JAVA 기반 운영 시스템에 API를 추가하고 기존 데이터베이스에 접속해 작업한 경험 사례. 데이터베이스 종류가 확정되지 않은 상태에서 착수 시 대응 방식. 예상 착수·완료 일정.

[예산과 기간]
예산은 150만원부터 협의합니다. 기간은 순수 개발 6~7영업일을 기준으로 하되, 요구사항 확정 협의·데이터베이스 접근 준비·검수 왕복 일정은 협의로 정합니다.

[산출물]
배정 API 백엔드, 데이터베이스 마이그레이션 스크립트, 인접 지역 관계 데이터, API 명세서, 연동 가이드, 시나리오·동시성 테스트 결과를 납품합니다.

[계약 특이사항]
기존 데이터베이스 접근 권한 제공 시점과 지역 인접 관계·일일 한도 확정 시점에 따라 착수일이 조정될 수 있습니다. 세부 사항은 계약 시 협의합니다.