[HOTSPOT] 2026.05.30 - 주요 작업 요약

1) 오늘의 작업 요약

오늘은 팔로우/팔로잉 목록을 다루면서 생각보다 헷갈리는 지점이 있었다. 내 프로필에서 보는 팔로워 목록과, 다른 사용자의 프로필에서 보는 팔로워 목록은 화면은 비슷하지만 기준이 되는 사용자 ID가 다르다. 처음에는 같은 목록 페이지를 재사용하면 된다고 생각했지만, 실제로는 API 호출 기준과 라우팅 기준을 명확히 분리해야 했다.

• 다른 사용자의 팔로워/팔로잉 목록을 볼 수 있도록 userId 쿼리 파라미터를 지원했다.
• 팔로워/팔로잉 버튼 클릭 시 현재 로그인한 사용자가 아니라, 보고 있는 프로필 사용자의 목록으로 이동하도록 수정했다.
• 프로필 소유자 여부에 따라 팔로워/팔로잉 이동 동작을 제한했다.
• 팔로우 목록 하단의 불필요한 완료 문구를 제거했다.
• 상품 상세 페이지의 실시간 판매 배너를 제거해 화면을 단순화했다.
• 인플루언서 페이지 API 경로에서 잘못된 by-nickname 경로를 제거했다.

2) 주요 변경사항 상세

2-1. 팔로워/팔로잉 목록 조회 기준을 userId로 확장

기존에는 팔로워와 팔로잉 목록을 조회할 때 암묵적으로 현재 로그인한 사용자를 기준으로 동작하는 흐름에 가까웠다. 하지만 다른 사용자의 프로필을 보고 있을 때는 그 사용자의 팔로워와 팔로잉을 조회해야 한다. 그래서 목록 API 호출 함수에서 userId를 받을 수 있도록 확장했다.

// 개념 예시
// 내 목록 조회
GET /api/follows/followers

// 특정 사용자 목록 조회
GET /api/follows/followers?userId=123
GET /api/follows/followings?userId=123

핵심은 목록 페이지가 항상 동일한 사용자 기준으로 동작하지 않는다는 점이다. URL에 userId가 있으면 해당 사용자를 기준으로 조회하고, 없으면 기본적으로 현재 사용자 기준으로 조회하도록 흐름을 나눴다.

2-2. 팔로워/팔로잉 버튼 라우팅 수정

문제는 버튼을 눌렀을 때 잘못된 사용자의 목록으로 이동할 수 있다는 것이었다.

• 문제: 다른 사람의 프로필에서 팔로워 버튼을 눌러도 내 팔로워 목록처럼 동작할 가능성이 있었다.
• 원인: 라우팅할 때 현재 보고 있는 프로필의 사용자 ID를 넘기지 않았거나, 로그인 사용자 기준으로만 처리하고 있었다.
• 해결: 버튼 클릭 시 현재 화면의 프로필 사용자 ID를 쿼리 파라미터로 전달하도록 수정했다.

// 개념 예시
/followers?userId=123
/followings?userId=123

라우팅은 단순히 페이지를 이동시키는 기능이 아니라, 다음 화면이 어떤 데이터를 조회해야 하는지 알려주는 역할도 한다. 그래서 이번 수정에서는 이동 경로와 조회 기준을 함께 맞추는 것이 중요했다.

2-3. 프로필 소유자 여부에 따른 이동 제어

팔로워/팔로잉 이동은 모든 상황에서 동일하게 열리면 안 되는 경우가 있었다. 특히 프로필 소유자 여부에 따라 허용해야 하는 동작이 달라질 수 있기 때문에, 현재 프로필이 내 프로필인지 다른 사용자의 프로필인지 구분하는 로직을 정리했다.

// 개념 예시
boolean isProfileOwner = loginUserId.equals(profileUserId);

if (isProfileOwner) {
    // 내 프로필 기준 목록 이동
} else {
    // 다른 사용자 프로필 기준 목록 이동 또는 제한 처리
}

프론트엔드에서는 이런 조건이 작아 보여도 사용자 경험에는 바로 드러난다. 내가 보고 있는 대상과 실제 이동 결과가 다르면 사용자는 화면을 신뢰하기 어렵다.

2-4. 불필요한 UI 요소 제거

팔로우 목록 하단의 모두 불러왔습니다. 문구는 기능적으로 큰 의미가 없고, 목록이 끝났다는 사실을 과하게 강조하고 있었다. 무한 스크롤이나 페이지네이션에서는 끝 상태를 알려주는 것이 필요할 때도 있지만, 이번 화면에서는 오히려 시각적 노이즈에 가까웠다. 그래서 해당 문구를 제거했다.

상품 상세 페이지의 실시간 판매 배너도 제거했다. 상세 페이지에서는 사용자가 상품 정보에 집중해야 하므로, 현재 흐름에 맞지 않는 배너는 덜어내는 편이 낫다고 판단했다.

2-5. 인플루언서 페이지 API 경로 수정

인플루언서 페이지에서는 잘못된 API 경로가 사용되고 있었다. 특히 by-nickname이 포함된 경로가 실제 백엔드 API 설계와 맞지 않아 요청이 실패하거나 의도와 다른 엔드포인트를 바라볼 수 있었다.

• 문제: 프론트엔드에서 잘못된 API 경로로 요청했다.
• 원인: 닉네임 기반 조회 경로가 변경되었거나 더 이상 사용되지 않는 형태였다.
• 해결: 불필요한 by-nickname 경로를 제거하고 현재 API 규격에 맞게 호출 경로를 정리했다.

3) 기술 메모/배운 점

Q. route parameter와 query parameter는 언제 구분해서 쓰는가?

A. route parameter는 리소스 자체를 식별할 때 적합하고, query parameter는 조회 조건이나 옵션을 전달할 때 적합하다.

// 특정 사용자의 프로필처럼 리소스가 명확할 때
/users/123

// 같은 목록 화면에서 조회 기준만 바꿀 때
/followers?userId=123

이번 작업에서는 팔로워 목록 페이지 자체는 동일하고, 조회 기준 사용자만 달라지는 구조였기 때문에 userId 쿼리 파라미터가 잘 맞았다.

Q. 왜 현재 로그인 사용자 ID만으로 처리하면 안 될까?

A. 로그인 사용자와 현재 보고 있는 프로필 사용자는 다를 수 있기 때문이다. 팔로우 기능에서는 이 둘을 혼동하기 쉽다.

• loginUserId: 현재 서비스를 사용 중인 나
• profileUserId: 화면에서 보고 있는 프로필의 주인
• targetUserId: 팔로우하거나 목록을 조회하려는 대상

이 값들을 명확히 나누지 않으면, 다른 사용자의 프로필에서 버튼을 눌렀는데 내 목록으로 이동하는 버그가 생긴다.

Q. API 함수에 선택적 userId를 추가할 때 주의할 점은?

A. 기존 호출부가 깨지지 않도록 기본 동작을 유지해야 한다. userId가 있으면 특정 사용자 기준으로 조회하고, 없으면 기존처럼 현재 사용자 기준으로 조회하는 식으로 처리하는 것이 안정적이다.

// 개념 예시
String url = "/api/follows/followers";

if (userId != null) {
    url += "?userId=" + userId;
}

오늘 작업을 하면서 팔로우/팔로잉 기능은 단순한 목록 조회가 아니라 사용자 문맥을 정확히 전달하는 기능이라는 점을 다시 느꼈다. 화면 이동, API 호출, 프로필 소유자 판별이 서로 맞물려야 사용자가 기대한 결과가 나온다. 작은 라우팅 수정처럼 보여도, 실제로는 프론트엔드 상태와 백엔드 조회 기준을 일치시키는 작업이었다.