개인적 고뇌
이 글을 쓰는 시점은 사실 프로젝트를 완성하고 쓰는 글이다.
프론트엔드 개발을 진행하며, 다양한 기술적 선택과 과정 속에서 수많은 고민을 했다. 단순히 트렌드를 따르는 것이 아니라, 프로젝트의 특성과 개발 환경을 고려하여 최적의 방안을 모색하려 했던 나의 여정을 정리해 본다.
이 시점은 정확히 개발하고나고 나서 1달정도 가량 됐을때의 내가 내 노션에 스스로의 고뇌를 정리해놨던 글이다.
디자이너는 단독 그러나..
본 프로젝트에서 디자이너는 단독으로 참여하고 있다, 디자인 작업에 AI 도구를 적극 활용하지 않았다.
ex)
디자인과 개발 간의 원활한 협업을 위해 수작업으로 조정하는 과정이 필수적이었다.
→ 인라인 스타일링 조절이 많았음 (아쉬움)
팀원들의 적극적인 도움과 아이디어 피드백
우린 함께야 !
미디어 쿼리를 원할하게 쓰려고 sidebar(navbar)을 context를 팠는데 이 방향성이 맞나? (너무 몰두하는것 같았음)
→ 그래서 아직 안함
백엔드와 프론트엔드 간 진도 차이로 인해 답답할때?
백엔드 개발이 완전히 마무리되기 전에 프론트엔드 작업을 진행해야 하는 경우가 많았다
이로 인해 API 응답을 기다리거나, 예상 데이터를 가정하고 개발해야 하는 어려움이 있었다.
이를 해결하기 위해 JSON Server를 활용하여 Mock 서버를 구축했고, 이를 통해 백엔드 없이도 실제 API와 유사한 환경에서 프론트엔드 개발을 원활하게 진행할 수 있었다.
스타일 컴포넌트 혹은 CSS in JS를 쓰지 않고 SCSS를 쓴 이유?
가독성과 유지보수성: CSS-in-JS 방식은 동적 스타일링에는 유리하지만, 복잡한 스타일 계층 구조에서는 오히려 코드가 난잡해질 수 있다
퍼포먼스 고려: CSS-in-JS 방식은 런타임에서 스타일을 생성하기 때문에, 대규모 프로젝트에서는 성능 저하가 발생할 가능성이 있다.
팀원 및 유지보수 고려: 만약 프로젝트가 장기적으로 유지보수되어야 한다면, 보다 표준적인 스타일 관리 방식인 SCSS가 유리할 수 있다고 판단했다.
그러나…
앞으로는 Emotion을 쓸것 같다.
https://wonbin109.tistory.com/90
스타일 재사용을 적극적으로 하지 않았는가?
코드의 복잡성을 증가시킬 수 있으며, 특정 컴포넌트의 스타일을 변경하는 데 오히려 제약이 될 수 있기 때문이다.
라고 썼지만.
디자이너의 부재였을까, 첫번째 경험이어서 그랬을까
특정 컴포넌트에서만 사용되는 스타일을 굳이 공통 스타일로 만들 필요가 없다고 판단했다.
그러나 후반에 가면 갈수록 아쉽다는 생각이 들었다.
이건 할만할것같은데? 와 드라마틱한 차이가 있을까?
Context를 왜 썼는가? Redux가 더 좋지 않나요?
퍼포먼스: Context API는 깊이 있는 상태 트리에서 불필요한 리렌더링이 발생할 수 있다는 단점이 있지만, 해당 프로젝트에서는 영향이 크지 않다고 판단했다.
무엇보다 매우 간단하고 유지보수가 너무 쉬웠다.
useCallback useMemo를 적극적으로 쓰지 않은 이유
성능 최적화 왜 안함?
useCallback과 useMemo는 성능 최적화를 위해 중요한 훅이지만, 모든 함수와 변수를 무조건적으로 최적화하는 것이 항상 좋은 것은 아니다.
그러나 매우 필요한 작업이라고 생각이 들었고
곧 할거같다. 우선 배포된 FE와 BE의 원할한 통신이 우선이다.
Axios Instance, vite.config.js로 서버연동했는데 이유는? (배포전)
API 호출 패턴을 단순화 → Axios Instance
Local 한정 CORS 이슈 해결 및 API Base URL 확정
proxy는 로컬 한정의 방법이었다는 것을 깨닫고 아래줄을 2.1일에 느꼈다.
배포됐을때는 안되더라.. (vercel)
로컬에서는
해결법 : .env 파일 만들어서 그 안에 백엔드 로직을 넣고 연동
배포후에는
vercel 환경변수 직접 추가하면 됌
오류
Deploy 환경에는 안돼고 로컬은 돼
→ 여기서 3시간 헤멘거같다.
대소문자 인식이 문제였는데.. Renux vs Mac OS 차이
문제가 되는 파일을 삭제하고 commit 다시 넣고 commit + push 하면 해결
https://velog.io/@eunjios/Vercel-배포-오류-Module-not-found-Error-Cant-resolve-/
이러한 선택들은 단순한 기술적 트렌드를 따르는 것이 아니라, 프로젝트의 특성과 팀의 개발 환경을 고려한 결과물이다.
물론, 완벽한 선택은 없으며, 앞으로도 지속적인 개선이 필요할 것이다. 하지만 그 과정에서 했던 고민들이 프로젝트를 더욱 단단하게 만들었다고 믿는다.
'FrontEnd Develop > Project : Wallet Guardians' 카테고리의 다른 글
소극적인 재무관리를 하는 20대를 위한 프로젝트, <Wallet Guardians> 최종 회고록 (9) | 2025.02.24 |
---|---|
소극적인 재무관리를 하는 20대를 위한 프로젝트, <Wallet Guardians> #2. 팀 구축과 기술 스택 소개 (0) | 2025.02.21 |
소극적인 재무관리를 하는 20대를 위한 프로젝트, <Wallet Guardians> #1. 시작했던 계기와 기능소개 (0) | 2025.02.21 |
프로젝트 Wallet Guardians의 프론트 개발자로서 했던 몇가지 고민 Part #1. (0) | 2025.02.17 |
본격연동 #8. 명확한 API 컴포넌트간의 삼권분립 : 간결화와 유지보수성 향상 (0) | 2025.02.14 |