[HOTSPOT] 2026.06.02 - 주요 작업 요약

1) 오늘의 작업 요약

오늘은 회원가입 화면과 팔로우 기능을 정리하면서, “프론트에서 어떤 정보를 반드시 받아야 하는가?”를 다시 고민했다. 처음에는 생년월일이나 계정 유형 같은 값이 있으면 사용자 정보를 더 풍부하게 만들 수 있다고 생각했지만, 실제 가입 흐름에서는 불필요한 입력이 사용자의 진입 장벽이 될 수 있다고 느꼈다. 그래서 나는 회원가입 폼을 더 단순하게 만들고, 팔로우/언팔로우처럼 사용자가 즉시 반응을 기대하는 기능의 상태 처리도 함께 점검했다.

• 이메일 회원가입 폼에서 생년월일 입력을 제거했다.
• 회원가입 폼에서 생년월일과 계정 유형 입력을 제거해 가입 흐름을 단순화했다.
• 팔로우/언팔로우 토글 동작이 꼬이는 문제를 수정했다.
• 팔로우 목록 페이지에서 사용하지 않는 상태를 제거해 TypeScript 빌드 오류를 해결했다.

2) 주요 변경사항 상세

회원가입 폼 입력 항목 정리

회원가입은 사용자가 서비스를 처음 만나는 지점이기 때문에 입력 항목이 많을수록 이탈 가능성이 커진다. 이번에는 가입에 반드시 필요하지 않은 생년월일과 계정 유형을 제거했다. 특히 계정 유형은 이후 온보딩이나 프로필 설정 단계에서 받는 편이 더 자연스럽다고 판단했다.

// 변경 전 개념 예시
const signupForm = {
  email: "",
  password: "",
  nickname: "",
  birthDate: "",
  accountType: "USER"
};

// 변경 후 개념 예시
const signupForm = {
  email: "",
  password: "",
  nickname: ""
};

폼 필드를 제거할 때는 화면에서 input만 지우는 것으로 끝나지 않는다. 초기 상태, 유효성 검사, API 요청 payload, 타입 정의까지 함께 정리해야 한다. 하나라도 남아 있으면 실제로 사용하지 않는 값 때문에 타입 오류가 나거나, 서버로 불필요한 데이터가 전달될 수 있다.

팔로우/언팔로우 토글 버그 수정

팔로우 버튼은 사용자가 누르는 즉시 상태가 바뀌는 것처럼 보여야 한다. 하지만 실제로는 서버 요청이 비동기로 처리되기 때문에, 화면 상태와 서버 상태가 어긋날 수 있다. 이번 작업에서는 팔로우 여부를 토글하는 과정에서 이전 상태를 기준으로 잘못 업데이트되던 흐름을 수정했다.

// 핵심 개념 예시
setIsFollowing((prev) => !prev);

// 비동기 요청 후 서버 응답 기준으로 보정하는 방식이 더 안전하다
const result = await toggleFollow(userId);
setIsFollowing(result.following);

문제는 버튼 클릭 시점의 상태와 요청 완료 시점의 상태가 항상 같지 않다는 점이었다. 특히 빠르게 여러 번 클릭하거나 목록 페이지에서 여러 사용자의 팔로우 상태를 다룰 때는 단순 반전 방식이 버그를 만들 수 있다. 그래서 서버 응답 또는 명확한 대상 id를 기준으로 상태를 갱신하는 방식이 중요하다고 느꼈다.

TypeScript 빌드 오류 수정

팔로우 목록 페이지에서는 사용하지 않는 done 상태가 남아 있어 TypeScript 빌드 오류가 발생했다. React 컴포넌트에서 상태를 선언해놓고 사용하지 않으면, 린트나 빌드 설정에 따라 오류로 처리될 수 있다.

// 문제 예시
const [done, setDone] = useState(false);

// 실제로 사용하지 않는다면 제거
// const [done, setDone] = useState(false);

이 문제는 단순한 unused state였지만, 빌드 단계에서 잡히는 오류는 배포 안정성과 직접 연결된다. 나는 기능 구현 후 남은 상태나 변수까지 정리하는 습관이 중요하다고 다시 느꼈다.

3) 기술 메모/배운 점

Q&A: 폼 필드는 왜 최소화해야 할까?

Q. 사용자 정보를 많이 받으면 더 좋은 것 아닌가?

A. 꼭 그렇지는 않다. 가입 단계에서는 서비스 이용에 필요한 최소 정보만 받는 것이 좋다. 추가 정보는 사용자가 서비스 가치를 경험한 뒤 프로필 설정이나 온보딩에서 받는 편이 부담이 적다.

Q. 프론트에서 필드를 제거하면 끝인가?

A. 아니다. 상태 초기값, validation schema, API 요청 body, 타입 정의, 서버 DTO와의 호환성까지 확인해야 한다. 프론트 화면에서만 제거하면 내부 코드에는 여전히 오래된 데이터 구조가 남을 수 있다.

Q. 팔로우 토글은 왜 단순히 boolean 반전만 하면 위험할까?

A. 비동기 요청에서는 클릭 순서와 응답 순서가 달라질 수 있다. 따라서 prev => !prev만 믿기보다는 서버 응답값이나 사용자 id 기준으로 정확히 상태를 갱신하는 방식이 더 안정적이다.

트러블슈팅 정리

• 문제: 회원가입 폼에 더 이상 필요하지 않은 생년월일, 계정 유형 입력이 남아 있었다.
• 원인: 가입 정책이 단순화되었지만 프론트 폼 구조와 요청 데이터가 함께 정리되지 않았다.
• 해결: 관련 input, 상태, 요청 payload를 제거해 가입 흐름을 최소화했다.

• 문제: 팔로우/언팔로우 버튼 상태가 의도와 다르게 토글될 수 있었다.
• 원인: 비동기 요청과 로컬 상태 반전 로직이 맞물리면서 최신 상태를 보장하지 못했다.
• 해결: 토글 후 상태 갱신 기준을 명확히 하고, 사용자별 상태가 올바르게 반영되도록 수정했다.

• 문제: 팔로우 목록 페이지에서 TypeScript 빌드 오류가 발생했다.
• 원인: 사용하지 않는 done 상태가 남아 있었다.
• 해결: 불필요한 상태 선언을 제거해 빌드 오류를 해결했다.

오늘 작업은 큰 기능 추가보다는 사용자 흐름과 코드 안정성을 다듬는 작업에 가까웠다. 가입 폼을 줄이면서 사용자가 더 쉽게 시작할 수 있게 했고, 팔로우 토글과 TypeScript 오류를 정리하면서 작은 상태 관리 실수도 실제 UX와 빌드 안정성에 영향을 줄 수 있다는 점을 복습했다.