튜터님 피드백

SA 문서 피드백

튜터님이 제출한 SA 문서를 검토해주시며 주요 피드백을 주셨다.

• 데이터 삭제 방식
  데이터를 완전히 삭제하지 않고 보관 처리해야 한다는 요구사항에 따라, 우리는 @DeleteAt 어노테이션을 사용해 NULL 확인으로 대체하려 했지만, 가게의 메뉴와 같은 경우는 별도의 판매 상태를 다루는 FLAG 역할의 컬럼을 추가해 관리하는 것이 좋다는 피드백을 받았다.

• JSON 예시
  파라미터 입출력과 JSON 예시가 있어야 피드백이 구체적으로 가능하다고 하셔서, 이 부분을 최우선적으로 작업하기로 했다.

---

도메인 분리

로그인과 회원가입이 유저 도메인에 포함되어 있었지만, 외부에 노출되는 기능은 유저 도메인에서 분리하는 것이 좋겠다는 피드백을 반영하여, 모든 권한에게 노출되는 Auth 도메인을 따로 분리했다.

---

인프라 설계서 보완

지금도 잘 구성했지만 몇 가지 보완하면 좋을 점 들을 말씀해주셨다.

• 표준화된 아이콘 사용
  AWS에서 제공하는 아키텍처의 표준화된 아이콘을 사용하여 가급적이면 시각적 일관성을 높이는 것이 좋다는 피드백을 받았다.

• 레이블 추가
  사용자와 개발자를 단순 아이콘으로 표시하기보다는 레이블을 추가해 더욱 명확하게 표현하기로 했다.

• Redis 도입 여부
  Redis를 Docker로 분리해 두었지만 사용처가 명확하지 않아 빼기로 결정했다.

추가로 실제 면접에서도 인프라 설계서를 보고 어떤 의도로 그런 방식으로 붙였는지, AWS RDS는 내부 컨테이너가 아니라 왜 외부 컨테이너로 빼놓았는지, 전체적인 파이프라인을 어떤식으로 이용해서 배포했는지 이런 질문을 많이 하게 된다고도 알려주셨다.

---

메뉴 변경 시 주문 데이터 문제 해결 방안

메뉴 변경 시 주문 정보와 같은 주문 관련 데이터에 영향을 미치기 때문에 튜터님께 조언을 구했고, 3가지 방법을 제안해주셨다.

1. 메뉴가 변경 중일 때 주문을 금지
2. 주문 정보에 메뉴 정보를 포함
3. 변경 시마다 새로운 메뉴 데이터로 추가해 버저닝 관리

이 중 3번 방안을 채택하여, 변경되는 메뉴 정보를 새로 삽입하는 방식으로 문제를 해결하기로 했다.

---

관리자 API 분리 여부

요구사항에 모호하게 적혀 있던 관리자 페이지와 관련해서 API를 기능이 중복되지만, 별도로 나누는 것이 좋은지 문의했다. 실무에서는 권한 관리 차원에서 관리자 API를 별도로 두지만, 현재는 내부적으로 변경된 요구사항이라 없어도 문제없다고 하셨다. JWT 관련 사전 강의 자료를 참고하여 구현할 수 있도록, 통합된 API로 제공하기로 했다.

---

API 명세서 데이터 작성

각자 도메인별로 담당하여 요청 및 응답 JSON 데이터 예시를 작성했다. 예상보다 시간이 많이 걸렸고, 피드백 시간 동안 각 예시의 형식을 통일했다.

• 케이스 통일
  JSON의 key값은 snake_case 대신 camelCase로 설정하여 백엔드에서 더 쉽게 파악할 수 있도록 했다.

• 페이지네이션
  쿼리 스트링을 통해 다루기로 결정했다.

• 가입 및 권한 부여
  가게 주인은 일반 유저로 가입 후, 가게 생성 시 추가 권한을 부여하는 방식으로 변경했다.

---

주소 데이터 관리 방식 고안

ERD 설계 당시에는 가게의 배달 가능 지역을 쉽게 유저의 배송 받을 주소와 연결하기 위해 “서울시 송파구”와 같은 지역 데이터를 자체 고유 코드로 다루기로 했다. 하지만 API를 설계하면서 생각해보니 전국적으로 주소 형식이 다양하여 통일된 파싱 방식을 떠올리기가 어려웠다. 일단 회의가 끝난 후 연결되어있는 도메인의 담당자들끼리 이야기를 해보는 것으로 하고 넘어갔다.

---

주소 파싱

다른 담당자분은 사정이 있으셔서 일단 먼저 방법을 찾아보기 시작했는데 참고할 정보를 찾을 수 없었다. 그래서 전제조건이 필요하지만 가능한 방법을 떠올렸다.

프론트엔드에서 Kakao 지도 API를 활용해 도로명 주소 전체를 받아온 후, 이것을 서버 측 비즈니스 로직에서 파싱하는 방식으로는 정했다. 그리고 형식이 다른 주소 체계를 모두 적용할 수 있도록 절차에 예외 사항을 추가했다.

1. 도로명 주소에서 ‘도’ 단위가 있다면 제거를 한다. (제주특별자치도는 제외한다.)
2. 띄어쓰기를 기준으로 2뎁스까지 나눈다. (세종특별자치시는 1뎁스까지 나눈다.)
3. 이렇게 하면 (대로/로/리)로 끝나는 상세주소를 분리할 수 있다.

걱정거리였던 많은 백데이터도 자동으로 넣을 수 있도록 데이터베이스에 해당 주소 코드 데이터가 없는 경우, 새로운 주소 코드를 자동으로 등록하는 방식으로 고안했다.

파싱 방법을 떠올렸음에도 API에서 전체 주소를 받을 때, 규칙으로 제한하고 싶지만 생각해낼 수 없었다.

---

재검토

이번 회고를 작성하면서 큰 문제를 발견했는데, 도로명 주소의 면적 단위가 어느 정도 일정할 줄 알았던 초기 가정이 틀렸다는 것이다. 원래의 목적은 배달 가능 지역을 설정하고 유저의 위치를 매칭하는 것이었으나, 결과를 도출하고서야 면적의 단위가 일정하지 않다는 것을 알게 되었다. 지역 단위를 세분화할지, 다른 매칭 방법을 고안할지 추가적인 고민이 필요한 상황이다.