화면에서 숨긴 문의를 서버에서도 막기까지
문의 분류를 화면에서 숨기는 것만으로는 직접 생성 요청을 막을 수 없었습니다. 프론트엔드 밖의 Python 서버에서도 저장·외부 처리 전에 검증하고, DB가 준비된 뒤 코드를 병합했습니다.
새 보너스 화면에서는 앱마다 허용하는 문의 분류가 달랐습니다. 화면에서 미지원 항목을 숨겨도 직접 보낸 생성 요청은 서버에 도착합니다. 저는 프론트엔드 밖의 Python 서버 변경까지 맡아 허용하지 않은 문의가 저장되기 전에 멈추도록 검증 위치를 정했습니다.
저는 허용할 앱·분류 조합과 저장 전에 거절해야 할 조건을 정했습니다. 낯선 Python 코드를 조사하고 초안을 만드는 데 AI를 썼지만, 검사 위치와 테스트 조건은 직접 확인했습니다.
오류를 반환하기 전에 멈춰야 했다
문의 생성 경로에는 DB 저장, 외부 문의 생성, 자동 처리가 이어졌습니다. 미지원 요청에 오류를 반환하더라도 이미 저장한 뒤라면 늦습니다. 그래서 앱과 분류의 지원 여부를 저장·외부 처리 전에 검사하도록 수정했습니다. 조회에서 보여주는 항목과 생성에서 허용하는 입력도 같은 지원 범위를 따르는지 살폈습니다.
테스트에는 미지원 요청 시 DB에 문의가 남지 않고 외부 문의 생성·자동 처리가 호출되지 않는 조건을 넣었습니다. 지원 요청은 앱과 분류가 저장되고 외부 생성으로 이어지는 경로를 확인했습니다. 오류 문구보다 먼저, 잘못된 요청이 실행 단계로 들어가지 않는지를 검증한 셈입니다.
새 분류가 DB에 먼저 있어야 했다
새 문의 분류를 저장하려면 DB ENUM에 값이 추가돼야 했습니다. 화면의 표시 순서에 맞춰 기존 DB 값의 순서를 바꾸면 안 된다는 DBA의 의견을 확인했습니다. 새 값은 DB의 마지막에 추가하고, 화면에 제공하는 순서는 Python 정의에서 따로 다루기로 맞췄습니다.
서버 코드가 새 ENUM 값을 쓰는데 DB가 아직 받지 못하면 다른 동료의 메인 브랜치 배포로 기능이 먼저 열릴 수 있었습니다. 저는 코드·테스트·DDL 초안을 준비해 DBA에게 전달하고 DB 반영 완료 뒤 코드 병합을 적용 순서로 맞췄습니다. DBA는 공유 DB의 현행 스키마와 실행 방식을 검토하고 운영·검증 환경에 반영했습니다.
미지원 요청의 DB·외부 부수효과가 없다는 테스트와 DBA의 반영 완료 보고까지 확인했습니다. 배포 뒤 실제 차단 건수는 확인되지 않았습니다. 이 작업은 프론트엔드 화면을 넘어 요청이 실행되는 경계와 팀의 배포 순서를 함께 책임진 경험입니다.