[HOTSPOT] 2026.06.06 - 크리에이터 라이브 상태와 channelUrl을 화면까지 연결한 과정

1. 라이브 상태는 왜 단순 Boolean이 아니었나?

이번 작업에서 다시 확인한 문제는 크리에이터의 라이브 상태가 백엔드 값 하나로 끝나지 않는다는 점이었다. 사용자는 홈 화면, 마이페이지, 프로필 화면에서 같은 상태를 기대하고, 실제 방송 흐름에서는 채널 URL까지 함께 필요하다.

기존 구조에서는 라이브 여부를 일부 화면에서만 다루거나, 프로필 응답에 필요한 값이 빠져 있어 프론트엔드가 상태를 일관되게 표현하기 어려웠다. 그래서 이번에는 isLive, userType, channelUrl이 같은 사용자 흐름 안에서 자연스럽게 이어지도록 정리했다.

2. 백엔드 응답에 channelUrl을 포함해야 했던 이유

라이브 버튼을 누르거나 크리에이터 프로필을 열었을 때, 프론트엔드는 단순히 사용자가 라이브 중인지뿐 아니라 어디로 이동해야 하는지도 알아야 한다. 이때 channelUrl이 프로필 응답에 없으면 화면은 추가 API를 호출하거나 임시 상태에 의존하게 된다.

public record ProfileResponse(
    Long userId,
    String nickname,
    String userType,
    Boolean isLive,
    String channelUrl
) {}

응답 DTO에 값을 포함하면 화면은 같은 데이터 모델로 프로필, 마이페이지, 홈 라이브 영역을 처리할 수 있다. 특히 매니저와 크리에이터가 모두 프로필을 가지는 구조에서는 누락된 필드 하나가 역할별 분기 코드를 불필요하게 늘린다.

3. 라이브 API는 공개 조회와 인증 변경을 나눠야 한다

라이브 상태를 보여주는 조회 API는 비로그인 사용자에게도 필요할 수 있다. 반면 라이브 상태를 바꾸는 API는 반드시 본인 또는 권한 있는 사용자만 호출해야 한다. 그래서 조회와 변경의 보안 기준을 분리해서 보는 것이 중요했다.

GET /api/users/live      // 공개 조회
PUT /api/creator/me/live // 인증된 크리에이터 상태 변경

이번 작업에서는 라이브 조회 쪽에 접근 허용을 추가하고, 응답에는 userType을 포함해 프론트엔드가 매니저와 크리에이터를 구분할 수 있게 했다. 화면 입장에서는 같은 라이브 목록이라도 클릭 경로와 노출 문구가 달라질 수 있기 때문이다.

4. 프론트엔드에서 이벤트 누락이 만든 문제

프론트엔드에서는 크리에이터 라이브 상태를 변경한 뒤 화면이 즉시 갱신되지 않는 문제가 있었다. 상태 변경 API가 성공해도 해당 이벤트를 화면 상태에 반영하지 않으면 사용자는 버튼을 눌렀는데 아무 변화가 없는 것처럼 느낀다.

const handleLiveChange = async (nextLive: boolean) => {
  await updateCreatorLiveStatus(nextLive);
  setProfile(prev => prev ? { ...prev, isLive: nextLive } : prev);
};

핵심은 서버 저장과 클라이언트 상태 갱신을 같은 사용자 액션 안에서 묶는 것이다. 여기에 channelUrl까지 같이 보관하면 홈, 마이페이지, 프로필 화면이 서로 다른 값을 보여주는 상황을 줄일 수 있다.

5. /influencer/:id와 /manager/:id 경로를 통일한 이유

이번 프론트엔드 작업에는 /influencer/:id 경로를 /manager/:id 기준으로 통일하는 변경도 포함됐다. 경로가 역할 이름에 너무 강하게 묶여 있으면 크리에이터처럼 새 역할이 들어왔을 때 페이지 재사용이 어려워진다.

프로필 화면의 본질은 특정 공개 프로필을 보여주는 것이다. 그래서 내부 역할명이 바뀌어도 사용자가 보는 경로와 컴포넌트 흐름은 가능한 한 단순하게 유지하는 편이 낫다.

6. SNS URL 저장 누락은 작은 버그처럼 보이지만 흐름을 끊는다

SNS URL 저장 누락도 같이 수정했다. 프로필에서 외부 채널 링크는 크리에이터 기능의 핵심 정보다. 저장은 성공한 것처럼 보이는데 다시 들어가면 값이 사라지는 유형의 버그는 사용자가 기능을 신뢰하지 못하게 만든다.

const payload = {
  nickname,
  introduction,
  channelUrl,
  snsUrl,
};

이런 필드는 백엔드 DTO, 저장 로직, 프론트엔드 폼 상태, 제출 payload 중 한 곳만 빠져도 문제가 생긴다. 그래서 프로필 계열 기능을 수정할 때는 화면 입력값이 최종 응답까지 왕복하는지 확인해야 한다.

7. 정리

이번 작업은 크리에이터 라이브 기능을 화면에 보이게 만드는 것보다, 관련 데이터가 여러 화면에서 같은 기준으로 움직이게 만드는 쪽에 가까웠다. isLive, userType, channelUrl, SNS URL은 각각 작은 필드처럼 보이지만, 프로필과 라이브 진입 흐름에서는 하나라도 빠지면 사용자가 바로 어색함을 느낀다.

앞으로 비슷한 기능을 추가할 때는 API 응답, 프론트엔드 상태 갱신, 라우팅, 저장 payload를 한 묶음으로 확인해야 한다. 그래야 특정 화면에서는 값이 보이고 다른 화면에서는 사라지는 문제를 줄일 수 있다.