MenuMate 레시피 조회 로직 리팩토링 및 문제 해결 과정 정리

1. 문제 상황

프로젝트를 진행하던 중 특정 레시피(자두라떼)의 상세 페이지 접근이 실패하는 문제가 발생했습니다.

검색 결과에서는 해당 레시피가 정상적으로 노출되었지만, 상세 페이지로 이동하면 데이터를 불러오지 못하는 현상이 발생했습니다.

이 문제는 단순한 데이터 오류가 아니라, 사용자가 클릭한 콘텐츠에 접근하지 못하는 UX 문제로 이어질 수 있는 상황이었습니다.

 

2. 원인 분석

기존 MenuMate의 레시피 조회 구조는 다음과 같았습니다.

1. 일정 범위의 레시피 목록 조회 (1 ~ 1000)
2. 해당 목록에서 RCP_SEQ(id)로 특정 레시피를 찾음

 

즉, RCP_SEQ로 직접 조회가 블가능하고 레시피 하나를 찾기 위해서도 넓은 범위의 전체 목록을 조회할 필요가 있는 구조였습니다.

문제는 API가 한 번에 조회할 수 있는 범위가 제한되어 있기 때문에 발생한 것이었습니다. 해당 범위를 넘어서는 레시피는 존재하더라도 접근할 수 없었던 것입니다.

 

3. 해결 전략 설계

문제를 해결하기 위해 식약처 레시피 API 공식 문서를 다시 확인했습니다.

확인 결과,

• RCP_SEQ는 직접 조회용 파라미터로 적합하지 않았고
• 대신 RCP_NM(레시피 이름)을 검색 조건으로 활용할 수 있었습니다

실제로 브라우저에서 다음과 같이 테스트해보았습니다.

.../COOKRCP01/json/1/10/RCP_NM=자두라떼

 

그 결과, 특정 레시피 이름을 기반으로 단건 조회가 가능하다는 것을 확인했습니다.

이를 바탕으로 다음과 같은 전략을 설계했습니다.

1. RCP_NM으로 레시피 조회
2. 결과 리스트에서 RCP_SEQ로 정확한 데이터 매칭 

 

이름 기반 조회 + id 보정 구조로 리팩토링하기로 결정했습니다.
id 로 보정을 하는 이유는 혹시라도 동일한 이름의 레시피가 존재할 경우, id로 구분하기 위함입니다.

 

4. 구현 및 리팩토링 과정

 

4-1. 상세 조회 로직 변경

(기존) 범위 조회 후 id 찾기 -> (변경) name 기반 조회 + id로 보정 

 

4-2. URL 구조 개선

기존에는 id만 전달했지만 이제는 name도 함께 전달하도록 변경했습니다.

/recipes/[id]?name=자두라떼

 

4-3. 검색 결과 카드 링크 수정

상세 페이지에서 name이 필요해졌기 때문에 검색 결과 카드에서 생성하는 링크도 함께 수정했습니다.

 

 

5. 결과 및 개선 효과

 

리팩토링 이후,

• 기존에 조회되지 않던 레시피(자두라떼 등)가 정상적으로 조회되기 시작했습니다.
• 조회 범위에 상관없이 레시피 접근이 가능해졌습니다.

결과적으로 레시피 상세 페이지의 안정성이 크게 향상되었고 UX가 개선되었습니다.

 

 

5. 배운 점

이번 경험을 통해 다음과 같은 점을 배웠습니다.

 

1. 잘못된 가정이 문제를 만든다

처음에는 "이 API는 단건 조회가 불가능하다"고 가정하고 구현을 진행했습니다.

하지만 실제로는 다른 방식(RCP_NM)으로 충분히 해결할 수 있는 문제였습니다.

 

2. 공식 문서를 다시 보는 습관의 중요성

이미 한 번 확인했던 API 문서였지만, 문제가 발생한 이후 다시 확인하면서 해결 방법을 찾을 수 있었습니다.

문서는 한번이 아니라, 문제 상황마다 다시 확인해야 한다는 점을 배웠습니다.

 

3. 조회 방식 설계의 중요성

단순히 데이터를 가져오는 것이 아니라,

• 어떤 기준으로 조회할 것인지
• 어떤 필드를 사용할 것인지

에 따라 기능의 안정성과 UX가 크게 달라질 수 있다는 것을 경험했습니다.