refactor: 기능 관련한 features 폴더 정리 완료

[MintPansy]

📝 개요

features/profile, features/review, features/reputation에 도메인 단위 초기 구조(types/, services/, index.ts)를 구성했습니다.
또한 공통 API 호출 레이어를 shared/lib/api로 정리해 apiRequest, ApiResponse, ApiError 기반으로 처리 흐름을 통일했고, 관련 서비스 API(profile-api, review-api)를 해당 패턴으로 마이그레이션했습니다.

🔗 관련 이슈

• Closes [refactor] features 기준으로 기능 단위 폴더 구조 정리 #71

🛠️ 변경 사항 (Checklist)

• ✨ Feature: 새로운 기능 추가
• 🚀 Enhancement: 기존 기능 개선/성능 향상
• 🐞 Bug: 버그 수정
• ♻️ Refactor: 코드 구조 개선 (기능 변화 없음)
• 🏗️ Chore: 빌드/패키지 설정/단순 잡일
• 🎨 Design: UI/UX 스타일 수정
• 📚 Documentation: 문서 수정

✅ 아래 내용을 한 번 더 점검해 주세요

1. 의도와 가독성 (Naming & Readability)

• 의도 중심 네이밍: 변수명에서 '역할'이, 함수명에서 '행위+대상'이 명확히 드러나나요?
• 선언적 코드: '어떻게'가 아닌 '무엇을' 하는지 코드만 보고도 알 수 있나요? (복잡한 로직은 내부 메서드로 숨겼나요?)
• 주석: 코드만으로 설명이 어려운 '특정 로직'에만 주석을 달았나요?

2. 타입과 논리 (Type Safety & Logic)

• 타입 안전성: any 사용을 지양하고, 모든 함수의 반환 타입을 명시했나요?
• 엣지 케이스: 데이터가 없거나(null/undefined), 에러가 발생할 경우를 처리했나요?
• 하드코딩 방지: API 주소나 설정값들이 환경 변수나 상수로 분리되었나요?

3. 코드 다이어트 (Clean-up)

• 찌꺼기 제거: 디버깅용 console.log나 사용하지 않는 import를 모두 지웠나요?
• 불필요한 코드: "나중에 쓰겠지" 하고 남겨둔 죽은 코드(Dead Code)는 없나요?
• Linter: 린트 에러나 워닝이 남아있지 않나요?

4. 지속 가능성 (Sustainability)

• 테스트: 수동으로든 코드로든 정상 작동을 확인했나요? (특히 기존 기능이 망가지지 않았나요?)
• 문서화: 새로운 환경 변수나 라이브러리가 추가되어 README 업데이트가 필요한가요?

---

💭 회고 (Optional)

app/에 남아있는 도메인 로직은 기존 70번 브랜치 병합 후 순차적으로 features/*로 이동 예정입니다.
서비스 레이어 타입 정교화 및 일부 네이밍(SpectrumWithValue)은 API 스펙 확정 후 정리 예정입니다.

[D5ng]

features 폴더에는 보통 기능 단위로 들어가는데요, 예시로 src/features/review 폴더에는 아래와 같은 항목들을 넣는게 좋을것 같아요.

• api
• components
• types
• hooks
• constants

파일이 얼마 없다면, 그냥 flat하게 사용하고, 파일의 개수(내부적으로 논의 해야함) 10개 정도가 넘어간다면 그때 다시 계층적으로 분리하는게 나아보입니다 (제 개인적인 생각이에요)

저는 Co-location에 관련하여 찾아보고 말씀드린거라, 다른 folder structure가 있다면 제안주세요!

+추가) 파일같은 경우 suffix를 활용해서, create-review.api.ts, create-review.mutation.ts와 같이 작성하는것도 이름과 유형을 알 수 있어 보기 편할것 같아요!

하나의 기능 또는 api를 각 파일로 둘지, 하나의 파일에서 관리할지도 논의해야할것 같네요!

@she0108 @MintPansy

[MintPansy]

features 폴더에는 보통 기능 단위로 들어가는데요, 예시로 src/features/review 폴더에는 아래와 같은 항목들을 넣는게 좋을것 같아요.

• api
• components
• types
• hooks
• constants

파일이 얼마 없다면, 그냥 flat하게 사용하고, 파일의 개수(내부적으로 논의 해야함) 10개 정도가 넘어간다면 그때 다시 계층적으로 분리하는게 나아보입니다 (제 개인적인 생각이에요)

저는 Co-location에 관련하여 찾아보고 말씀드린거라, 다른 folder structure가 있다면 제안주세요!

+추가) 파일같은 경우 suffix를 활용해서, create-review.api.ts, create-review.mutation.ts와 같이 작성하는것도 이름과 유형을 알 수 있어 보기 편할것 같아요!

하나의 기능 또는 api를 각 파일로 둘지, 하나의 파일에서 관리할지도 논의해야할것 같네요!

@she0108 @MintPansy

현재 구조 확인했는데, feature당 파일이 5개 내외라서 지금처럼 services/와 types/로만 관리하는 게 좋을 것 같아요. 제안해주신 components/, hooks/, constants/는 각 폴더가 실제로 필요해질 때 (예: review 전용 컴포넌트 3개 이상 생길 때) 그때 추가하는 걸로 하면 어떨까요? suffix 네이밍 규칙(review-api.ts)도 현재 방식 그대로 유지하구요! (제 의견만 간단히 남긴거라 다른 의견 있으시면 알려주세요!)

[she0108]

저는 api, components, types, hooks, constants 구조 좋은 것 같습니다. 현재는 개발 진행이 많이 안 된 상태라 파일이 별로 없지만, 저희 서비스가 비슷한 기능과 ui를 여러 페이지에서 쓰는 경우가 많아보여서 api, types 외의 폴더들도 결국 쓰게 될 것 같다는 생각이에요!
파일들은 지금처럼 api/query/mutation으로 구분하되, 코드가 길어지면 추후 create-review처럼 액션 단위로 나눠도 좋을 것 같아요.
그런데 feature 단위라 폴더 경로(/features/review)에 기능이 들어가는데 파일명은 fetchers.ts, queries.ts, mutations.ts 정도로만 해도 충분하지 않을까요?

[D5ng]

저는 api, components, types, hooks, constants 구조 좋은 것 같습니다. 현재는 개발 진행이 많이 안 된 상태라 파일이 별로 없지만, 저희 서비스가 비슷한 기능과 ui를 여러 페이지에서 쓰는 경우가 많아보여서 api, types 외의 폴더들도 결국 쓰게 될 것 같다는 생각이에요! 파일들은 지금처럼 api/query/mutation으로 구분하되, 코드가 길어지면 추후 create-review처럼 액션 단위로 나눠도 좋을 것 같아요. 그런데 feature 단위라 폴더 경로(/features/review)에 기능이 들어가는데 파일명은 fetchers.ts, queries.ts, mutations.ts 정도로만 해도 충분하지 않을까요?

이렇게하면 파일이 많지 않아서 좋기는해요, 대신에 하나의 파일에 여러 함수들이 들어간다는 장점 또는 단점이 있긴합니다!

저는 이 방법도 괜찮아보여요

[MintPansy]

효은님이 말씀하신대로 features 구조를 api / components / hooks / constants / types로 정리하고, API 레이어는 fetchers.ts, queries.ts, mutations.ts 네이밍으로 통일했습니다. 현재 비어있는 영역도 이후 확장을 고려해 폴더와 index.ts를 미리 세팅해, 기능 추가 시 같은 규칙으로 바로 작업할 수 있게 맞춰두었습니다!