본문으로 바로가기
TaeyoungKim.dev

프로젝트

검증 가능한 구현과 운영 판단

회사 협업에서 맡은 기능과 판단 근거를 확인 가능한 범위로 정리했습니다.

공공시설 예약·결제 정합성 개선

주차 정기권, 강습, 시설 예약이 함께 운영되는 시스템에서 신청 상태, 환불, 매출 집계와 증빙자료 처리 기능을 개선했습니다.

기여 확인 기간: 2026.07 - 2026.09

역할과 범위

회사 협업 프로젝트의 백엔드·관리자 화면 유지보수. 전체 서비스 구축이 아니라 본인 커밋으로 확인된 기능 변경을 정리했습니다.

환불 검증, 전용 수정 경로, 합산 기준 계산을 서버 처리 경계 안에서 보완한 협업 기여입니다. 회사 시스템의 운영 성과 수치는 공개하지 않습니다.

업무 흐름

  1. 1. 신청·상태 확인
  2. 2. 결제·환불 검증
  3. 3. 집계·자료 정리

주요 판단

환불과 결제취소의 처리 경계

처리 대상 행을 잠근 뒤 기존 환불 내역, 신청 상태, 환불 가능 금액을 다시 확인하도록 보완했습니다. 관련 서비스에 트랜잭션 규칙을 적용하고 중복 요청을 거절하는 경로를 추가했습니다.

수정 범위를 좁혀 데이터 보호

차량 정보 수정은 전용 서비스·SQL 경로로 분리해 결제 관련 필드가 함께 덮어써지지 않게 했습니다. 배정 확정 전 수용 가능 여부를 확인하는 조건도 보완했습니다.

집계와 증빙자료의 생명주기

여러 결제·환불 건을 합산한 금액에 맞춰 세액·공급가액 계산을 정리했습니다. 상태 변경 성공 여부와 첨부 참조 관계를 확인한 뒤 증빙 원본·변환본 정리 경로를 연결했습니다.

확인한 근거
본인 작성 변경의 Java 서비스, MyBatis SQL, 관리자 화면과 기본 브랜치 반영을 확인했습니다. 환불 검증, 차량 전용 수정, 합산 기준 계산이 각각 코드 변경으로 뒷받침됩니다.
확인 범위와 한계
이번 검토에서 회사 환경의 테스트나 운영 배포를 재실행하지 않았습니다. 처리량·장애 감소율은 측정 자료가 없어 성과 수치로 사용하지 않습니다.
남긴 기준
상태 확인과 금액 계산은 화면이 아니라 서버의 일관된 처리 경계 안에 있어야 합니다. 데이터베이스 변경과 파일 삭제는 실패 특성이 달라 후속 확인이 필요합니다.
JavaSpringMyBatisMariaDBJSP

공영주차 신청·추첨·결제 흐름 구현

신청부터 추첨, 수납과 환불까지 이어지는 공영주차 기능을 개발했습니다. 관리자가 다루는 업무 규칙을 서버 검증과 결제 상태 흐름으로 연결했습니다.

기여 확인 기간: 2026.08 - 2026.09

역할과 범위

회사 협업 프로젝트의 신규 주차 기능 개발. 개발 브랜치의 구현과 테스트 코드 추가가 확인되며 운영 배포 완료로 표현하지 않습니다.

신청·추첨·환불의 거절 경로와 모의 결제 테스트를 추가한 개발 브랜치 기여입니다. 운영 배포 완료나 실결제 성과를 주장하지 않습니다.

업무 흐름

  1. 1. 접수·추첨
  2. 2. 결제 원장·검증
  3. 3. 환불·결과 확인

주요 판단

신청·추첨을 검증 가능한 작업으로

신청·취소에 전용 트랜잭션 경계를 적용했습니다. 추첨에서는 설정과 준비 상태를 확인하고 처리 건수·당첨 결과·실행 이력 저장이 맞지 않으면 실패하도록 구성했습니다.

외부 결제 결과를 그대로 신뢰하지 않기

환불 요청을 외부 호출 전에 기록하고 거래 식별자·금액·응답 상태를 대조하도록 구현했습니다. 결과가 불확실하면 검토가 필요한 상태로 남겨 무조건적인 재환불을 피하도록 했습니다.

실거래와 테스트의 경계

운영 결제는 명시적 환경 설정과 활성화 조건이 모두 맞아야 허용하도록 했습니다. JUnit·Mockito 테스트에 운영 환경 오인, 금액 불일치, 환불 설정 누락 같은 거절 경로를 포함했습니다.

확인한 근거
본인 커밋의 신청·추첨 서비스, 환불 서비스, 결제 정책과 JUnit·Mockito 테스트 코드를 확인했습니다. 외부 결제 호출을 mock으로 대체하는 테스트 구성이 포함돼 있습니다.
확인 범위와 한계
확인된 기능은 개발 브랜치 기준입니다. 이번 검토에서는 회사 CI·테스트를 실행하거나 운영 배포를 확인하지 않았으며, 실결제 성공률과 부하 성능은 주장하지 않습니다.
남긴 기준
데이터베이스 트랜잭션만으로 외부 결제까지 원자적으로 묶을 수는 없습니다. 요청 기록, 응답 검증, 불확실한 결과의 후속 확인을 별개로 설계해야 합니다.
JavaSpringMyBatisJSPJUnitMockito

시설 계약·관리비 청구 시스템 개선

기존 Classic ASP 기반 계약·청구 시스템에서 사전 확보한 가상계좌 배정과 입금 통보 처리를 개선했습니다. 기존 업무 흐름과의 호환성을 유지하는 변경에 집중했습니다.

기여 확인 기간: 2026.07 - 2026.08

역할과 범위

회사 협업 프로젝트의 레거시 웹 시스템 유지보수. 계좌 배정 처리와 입금일·관리비 부과 관련 본인 변경을 선별했습니다.

기존 계약·수납 기록과의 호환성을 유지하면서 계좌 배정과 거래일 검증을 보완한 레거시 유지보수 기여입니다.

업무 흐름

  1. 1. 계약·계좌 배정
  2. 2. 청구·입금 통보
  3. 3. 입금일·수납 반영

주요 판단

신규 발급과 기존 계좌 사용 분리

자동 신규 발급을 제한하고 사전 확보한 계좌의 예약·확정 흐름을 연결했습니다. 이미 배정된 계좌는 재사용 경로로 처리하고 확정 실패 시 예약 해제 호출을 추가했습니다.

명시적인 데이터베이스 호출

계좌 배정 처리에 ADO 매개변수와 저장 프로시저 호출을 사용했습니다. 대상·용도·등록자 정보를 구분해 전달하고 처리 단계별 실패를 구분했습니다.

통보 시점과 거래일 구분

입금 통보의 거래 날짜를 검증해 유효한 경우 입금일로 사용하도록 수정했습니다. 기존 계좌 방식에는 신규 발급 요청을 반복하지 않도록 관리비 부과 경로를 보완했습니다.

확인한 근거
본인 작성 ASP 변경의 계좌 배정 처리, ADO 호출, 거래일 검증과 기본 브랜치 반영을 확인했습니다. 대규모 파일 이동·병합은 신규 기능 성과로 계산하지 않았습니다.
확인 범위와 한계
이번 검토는 애플리케이션 변경 확인 범위입니다. 회사 데이터베이스의 저장 프로시저 실행, 실입금 시험과 운영 배포는 재검증하지 않았습니다.
남긴 기준
레거시 시스템에서는 전면 교체보다 기존 계약과 수납 기록의 연속성이 우선일 수 있습니다. 처리 시각과 실제 거래일을 구분하는 작은 변경도 정산 기준에 영향을 줍니다.
Classic ASPVBScriptADOSQL ServerPayment Integration