[ysw789]

요약

QA B-08(업장 등록 승인 실패)의 원인을 수정했습니다. 신청 연락처 컬럼은 13자, 업장 연락처 컬럼은 11자인데, 승인할 때 하이픈이 들어간 신청 연락처(예: 010-1234-5678)를 업장에 그대로 복사해서 SQLState 22001로 실패했습니다.

이제 신청할 때 연락처 형식을 검증하고 하이픈을 뺀 숫자로 저장합니다. 이미 하이픈으로 저장된 승인 대기 신청도 승인할 때 같은 규칙으로 검증한 뒤 숫자로 바꿔 업장에 저장합니다. DB 스키마 변경과 Flyway 마이그레이션은 없고, 신규 ErrorCode도 없습니다.

변경 내용

POST /api/app/workspace-requests, POST /api/manager/workspace-requests (CreateWorkspaceRequest)

• CreateWorkspaceRequestDto.contact에 기존 NotBlank와 함께 Size(max = 13)과 공용 Pattern을 적용했습니다. 형식이 틀리면 유스케이스를 타기 전에 HTTP 400 B001로 끝나고 신청은 저장되지 않습니다.
• 검증을 통과한 원문에서 ASCII 하이픈(-)만 제거해 숫자로 저장합니다(PhoneNumberUtil.normalizeLocalNumber).
• 유스케이스 입력을 adapter DTO 대신 도메인 CreateWorkspaceRequestCommand(record)로 바꿨습니다. 앱·사장님 컨트롤러는 request.toCommand(user)로 넘깁니다. 내부 경계 변경이라 요청·응답 JSON은 그대로입니다.

PATCH /api/admin/workspace-requests/{workspaceRequestId}/status (UpdateWorkspaceRequestStatus)

• 승인(ACTIVATED)할 때 신청 연락처를 같은 규칙으로 검증·정규화한 뒤 매니저·업장을 저장합니다. 그래서 하이픈으로 저장된 기존 신청도 승인되고, 업장에는 숫자가 저장됩니다.
• 기존 신청의 연락처가 규칙 밖이면 HTTP 400 B001(ILLEGAL_ARGUMENT)로 승인을 거부합니다. 매니저·업장 저장, 채팅 이벤트 발행, 신분증 파일 삭제는 일어나지 않습니다. 승인 상태 변경은 유스케이스의 Transactional 경계 안에서 함께 롤백됩니다.
• 이미 승인된 신청을 다시 승인하거나 반려하면 기존대로 HTTP 409 B020("이미 승인된 요청입니다.")입니다. 상태 검사가 연락처 검사보다 먼저라서, 이미 승인된 신청은 연락처가 틀려도 409를 받습니다.
• 반려(REVOKED)는 연락처를 보지 않습니다. 연락처가 잘못된 기존 신청도 반려할 수 있습니다.
• 기존 매니저 재사용 정책은 그대로입니다.

연락처 형식

PhoneNumberUtil.LOCAL_PHONE_NUMBER_PATTERN이 문자열 전체와 일치해야 합니다. 특정 접두번호 목록으로 제한하지 않아서 02, 031, 070, 099 등도 형식만 맞으면 받습니다.

(?:0[0-9]{8,10}|0[0-9]{1,2}-[0-9]{3,4}-[0-9]{4})

구분	형식
숫자형	0으로 시작하는 ASCII 숫자 9~11자리
하이픈형	0으로 시작하는 2~3자리-3~4자리-4자리

입력 예	저장값 / 결과
010-1234-5678	01012345678
02-1234-5678	0212345678
02-123-4567	021234567 (9자리)
09912345678	그대로 (11자리)
010--1234-5678, 010-12345678, +821012345678	HTTP 400
null, 빈 문자열, 앞뒤·중간 공백, 문자, 전각 숫자, . 등 다른 구분자, 길이 초과, 줄바꿈	HTTP 400

공백을 trim하거나 이상한 문자를 지워서 받아 주지 않습니다. 하이픈 외에는 값을 고치지 않습니다.

오류 응답

• 신규 신청의 DTO 검증 실패: HTTP 400, B001, message "잘못된 요청입니다.", data에 { "field": "contact", "message": "..." } 목록이 들어갑니다. 제약을 여러 개 어기면 항목도 여러 개일 수 있습니다. 형식 오류 항목의 message는 "연락처는 0으로 시작하는 911자리 숫자 또는 23자리-3~4자리-4자리 형식이어야 합니다."입니다.
• 기존 신청 승인 중 연락처 오류: HTTP 400, B001, data: null, message는 위와 같은 문장입니다. 연락처 값은 메시지에 넣지 않습니다.

Swagger

• CreateWorkspaceRequestDto.contact의 Schema 설명에 허용 형식과 숫자 저장 정책을 적었습니다.
• UserWorkspaceRequestControllerSpec, ManagerWorkspaceRequestControllerSpec: 신청 operation 설명과 400 설명(연락처 형식 오류 ILLEGAL_ARGUMENT 또는 INVALID_FILE)을 갱신했습니다.
• AdminWorkspaceRequestControllerSpec: 승인 시 기존 연락처도 검증·정규화한다는 설명과 400 설명을 추가했습니다.

프론트 영향

• URL, 메서드, 요청·응답 JSON 필드 이름과 타입은 바뀌지 않습니다. 성공 응답도 기존대로 HTTP 200과 { "timestamp": "...", "data": null }입니다.
• 검증이 엄격해졌습니다. 이전에는 통과하던 공백 섞인 번호, 국제번호(+82...), 하이픈 외 구분자가 이제 400으로 거부됩니다. 앱에서 보내는 연락처 값을 위 형식에 맞춰 주세요.
• 연락처는 문자열로 다뤄 맨 앞 0이 빠지지 않게 해 주세요.
• 새로 만든 신청과 승인으로 생성된 업장의 조회 응답 contact는 하이픈 없는 숫자입니다. 화면에 하이픈을 보여야 하면 앱에서 포맷팅해야 합니다.
• 과거 신청은 일괄 변경하지 않았기 때문에, 기존 신청 상세에는 하이픈 값이 남아 있을 수 있습니다. 이 신청을 승인해서 생기는 업장에는 숫자로 저장됩니다.

테스트

리뷰를 반영해 단위 테스트만 남겼습니다. 처음에 올렸던 MockMvc 컨트롤러 테스트(WorkspaceRequestContactTests)와 H2 통합 테스트(WorkspaceRequestApprovalIntegrationTests)는 단위 테스트만 둔다는 프로젝트 규칙에 맞지 않아 삭제했고, 같은 검증을 유스케이스 단위 테스트로 옮겼습니다. 그래서 실제 DB에서 롤백을 확인하는 테스트는 이 PR에 없습니다. 롤백은 UpdateWorkspaceRequestStatus의 Transactional 경계가 맡고, 단위 테스트에서는 연락처가 틀리면 매니저·업장 저장이 아예 호출되지 않는지 확인합니다.

• PhoneNumberUtilTests: 허용 형식 12가지가 하이픈만 빠진 숫자로 바뀌는지, null·빈 값·공백·문자·국제번호·하이픈 위치 오류·다른 구분자·전각 숫자·길이 초과·줄바꿈이 ILLEGAL_ARGUMENT와 정해진 메시지로 거부되는지 확인합니다.
• CreateWorkspaceRequestTests: 하이픈형·숫자형 연락처가 숫자로 저장되는지, 잘못된 연락처는 신청 저장과 파일 연결 전에 거부되는지 확인합니다. 기존 테스트는 toCommand(user) 호출로 바꿨습니다.
• UpdateWorkspaceRequestStatusTests (ExecuteTests 안)
  • 하이픈이 들어간 기존 신청을 승인하면 업장에 숫자로 저장되는지
  • 연락처가 잘못된 기존 신청은 ILLEGAL_ARGUMENT로 승인이 거부되고, 메시지에 연락처 값이 없고, 매니저·업장 저장·이벤트 발행·파일 삭제가 일어나지 않는지
  • 연락처가 잘못된 기존 신청도 반려는 연락처를 보지 않고 처리되는지
  • 이미 승인된 신청을 다시 승인하면 CONFLICT로 거부되고 매니저·업장을 만들지 않는지
• 전체 ./gradlew test (head 5975457a): 661건 통과, 실패·오류·스킵 0건. 이 중 관련 테스트는 PhoneNumberUtilTests 39건, CreateWorkspaceRequestTests 18건, UpdateWorkspaceRequestStatusTests 20건입니다.

리뷰 반영 전 기준 검증 기록

아래는 테스트 구성을 바꾸기 전, 로컬에서 확인한 내용입니다. 지금 PR의 테스트 결과가 아닙니다.

• 수정 전에 실제 H2 저장소에서 13자 하이픈 신청을 승인하면 varchar(11) INSERT에서 SQLState 22001이 나는 것을 재현했습니다.
• 로컬 PostgreSQL·API에서 정상 업종 ID로 아래 항목을 확인했습니다.

항목	결과
B-04	신청자·관리자 상세 200. 정규화된 연락처와 첨부 URL 메타데이터 확인. 실제 첨부 열림은 미확인
B-05	첨부 댓글 등록·조회 200, 다른 사용자 403, 255자 200, 256자·공백 400
B-07	반려 후 같은 사업자번호로 재신청 200
B-08	휴대전화·일반전화 신규 신청·승인 200 및 숫자 저장, 기존 하이픈 신청 승인 200, 잘못된 기존 번호 400(B001)·PENDING 유지
B-09	이미 승인한 신청의 재승인·반려 409
B-10	같은 신청자의 두 번째 업장 승인 200, 매니저 1건 재사용
B-11	대표이미지 5개 순서대로 업장 이관, 6개 요청 400

• 로컬 기존 데이터는 신청 숫자형 1건·하이픈형 1건, 업장 숫자형 12건이었고, 규칙 밖 데이터는 0건이었습니다. 운영 DB 집계는 하지 않았습니다.

남긴 것

• 승인된 신청자의 사장님 API 403(A002)은 이 PR에서 고치지 않았고, 해결 여부도 확인하지 않았습니다. 리뷰 반영 전 로컬 QA에서, 승인된 신청자가 재로그인해도 GET /api/manager/workspaces에서 403을 받았습니다. 승인하면 ManagerUser는 생기지만 User.role은 ROLE_USER 그대로입니다. 그런데 LoginWithPassword는 User.role로 토큰 scope를 정하고, UserRoleUtil.getRoleForScope는 User.role과 scope 역할이 같아야 통과시킵니다. 이 PR은 인증·권한 경로를 바꾸지 않았으므로 B-08의 "승인 후 사장님 전환"은 별도로 추적해야 합니다.
• 과거 신청 원문(하이픈 값)은 일괄 보정하지 않았습니다. 로컬 기준으로 규칙 밖 데이터가 없어 마이그레이션을 만들지 않았고, 운영 DB는 집계하지 않았습니다.
• 화면 표시·전환, 실제 첨부 열림·업로드·S3 삭제, 배포 환경 QA는 하지 않았습니다.
• 업종 요청 불일치(B-01)는 이 PR 범위가 아닙니다.

연관 PR

• fix: [ALT-306] 업장 신청 증빙 역할 중복 방지 및 입력 계약 회귀 검증 #117 (ALT-306 업장 신청 증빙 역할 중복 방지 및 입력 계약 회귀 검증), fix: [ALT-307] 업장 신청 취소·승인 경합 직렬화 #118 (ALT-307 업장 신청 취소·승인 경합 직렬화)은 이 브랜치의 앞 5개 커밋(1c863648~bf154a30)인 fix/alt-297-qa-followup을 base로 쌓여 있습니다. 이 PR을 먼저 머지해 주세요.
• 이 PR과 #118이 모두 UpdateWorkspaceRequestStatusTests를 고칩니다. 이 PR은 테스트를 ExecuteTests 안으로 옮겼고, #118은 같은 파일에 잠금 검증을 넣었습니다. 그래서 이 PR을 머지한 뒤 #118을 dev 위로 올릴 때 이 파일에서 충돌을 정리해야 합니다.

관련 문서

• ALT-297
• B-08 QA 이슈

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 55 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: alter-app/alter-backend
• Branch: fix/alt-297
• File: .coderabbit.yaml
• Commit: 5975457
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 9055e51a-4530-4908-94bc-827b20dd40f3

Commits

Reviewing files that changed from the base of the PR and between 9c23176 and 5975457.

Files selected for processing: 14

• src/main/java/com/dreamteam/alter/adapter/inbound/admin/workspace/controller/AdminWorkspaceRequestControllerSpec.java
• src/main/java/com/dreamteam/alter/adapter/inbound/general/workspace/controller/UserWorkspaceRequestController.java
• src/main/java/com/dreamteam/alter/adapter/inbound/general/workspace/controller/UserWorkspaceRequestControllerSpec.java
• src/main/java/com/dreamteam/alter/adapter/inbound/general/workspace/dto/CreateWorkspaceRequestDto.java
• src/main/java/com/dreamteam/alter/adapter/inbound/manager/workspace/controller/ManagerWorkspaceRequestController.java
• src/main/java/com/dreamteam/alter/adapter/inbound/manager/workspace/controller/ManagerWorkspaceRequestControllerSpec.java
• src/main/java/com/dreamteam/alter/application/workspace/usecase/CreateWorkspaceRequest.java
• src/main/java/com/dreamteam/alter/application/workspace/usecase/UpdateWorkspaceRequestStatus.java
• src/main/java/com/dreamteam/alter/common/util/PhoneNumberUtil.java
• src/main/java/com/dreamteam/alter/domain/workspace/command/CreateWorkspaceRequestCommand.java
• src/main/java/com/dreamteam/alter/domain/workspace/port/inbound/CreateWorkspaceRequestUseCase.java
• src/test/java/com/dreamteam/alter/application/workspace/usecase/CreateWorkspaceRequestTests.java
• src/test/java/com/dreamteam/alter/application/workspace/usecase/UpdateWorkspaceRequestStatusTests.java
• src/test/java/com/dreamteam/alter/common/util/PhoneNumberUtilTests.java

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[hodoon]

리뷰했습니다. 인라인 코멘트 확인 부탁드립니다.