회고록

😔 아쉬웠던 점

먼저 중급 프로젝트를 하면서 아쉬운점이 제일 많았던 것 같다.

🙇‍♂️ 원하는 기능을 맡지 못한 경험

이번 프로젝트에서 개인적으로 가장 해보고 싶었던 기능은 로그인 및 회원가입 기능이었다.
하지만 예기치 않게 예비군 동원훈련이 중간에 잡히면서 약 3일간 프로젝트를 이탈하게 되었고, 그 기간 동안 핵심 기능을 맡기에는 리스크가 크다는 판단이 들었다.
결국 프로젝트에 차질이 생기지 않도록 팀의 요청에 따라 세팅 작업과 공통 컴포넌트 작업에 집중하게 되었다.
물론 세팅 작업과 공통 UI 구축도 중요한 역할이지만, 기획 단계에서 희망했던 기능을 구현해보지 못한 점은 개인적으로 매우 아쉬웠다.
다음 프로젝트에서는 꼭 원하는 기능을 책임지고 끝까지 구현해보는 경험을 하고 싶다.

🚀 배포 이슈 – 8시간의 고군분투

이번 프로젝트에서 배포 작업을 직접 맡게 되면서 예상보다 많은 시간(약 8시간)을 소모하게 되었다.
배포 과정에서 발생한 주요 문제는

• React Hook 규칙 위반
• 잘못된 파일 라우팅 구조
• TypeScript 타입 오류
  이 있었다.
  이러한 문제는 대부분 제가 프로젝트 세팅을 맡을 때, 컨벤션을 명확하게 정의하지 않았던 점, 그리고 Next.js 및 TypeScript에 대한 부족한 이해에서 비롯된 것으로 보인다.

이 경험을 통해 느낀 점은, 초기 세팅과 컨벤션 정의가 얼마나 중요한지, 그리고 기술 스택에 대한 탄탄한 이해가 협업과 배포 단계에서 문제를 줄일 수 있다는 점이다.
다소 힘든 시간이었지만, 배포에 대한 실전 경험과 다양한 문제 해결 능력을 기를 수 있었던 뜻깊은 기회였다.

🛠 Jira 사용 미숙 – Task 관리의 아쉬움

이번 프로젝트에서 Jira 사용법에 대한 이해가 부족해 제대로 활용하지 못한 점이 아쉽다.
Task 관리와 이슈 트래킹이 중요한데도 불구하고, 초반에는 거의 사용하지 않다가 막판에 정리하는 용도로만 활용하게 되었다.

앞으로는 Jira의 기능과 흐름을 사전에 익혀두고, 초기부터 적극적으로 이슈와 Task를 관리하는 습관을 들여야겠다고 느꼈다.
툴은 도구일 뿐이지만, 올바르게 사용하는 것이 협업 효율에 큰 영향을 준다는 사실을 다시금 깨달았다.

🔍 코드리뷰 – 기본기 부족의 체감

아직 언어에 대한 기본기가 부족하다 보니, 다른 사람의 코드를 보더라도 무엇이 잘못됐는지, 어떤 점을 짚어야 할지 명확하게 판단하기 어려웠다.
결국 리뷰를 하더라도 실질적인 피드백은 못 하고, 형식적으로 Approve만 누르게 되는 상황이 반복되었다.

이번 경험을 통해, 기본 문법뿐 아니라 실무에서 자주 마주치는 코드 패턴과 코드 스멜에 대한 학습이 더 필요하다고 느꼈다.
다음 프로젝트에서는 좀 더 적극적으로 코드리뷰에 참여하고, 스스로도 리뷰받을 수 있는 코드를 작성하는 것을 목표로 삼고 싶다.

🧩 공동 컴포넌트 – 정의되지 않은 디자인의 한계

공동 컴포넌트 작업을 하면서 가장 어려웠던 점은, Figma 상에서 컴포넌트의 공통 규격이 명확히 정의되어 있지 않았다는 점입니다.
디자인 상으로는 공통 컴포넌트처럼 보였지만, 실제 페이지에 적용해보면 버튼 크기와 스타일이 페이지마다 제각각이라, 공통으로 묶는 데 어려움이 있었다.

결국 일관된 컴포넌트를 만들기보다는 페이지별로 별도 버튼을 생성하는 방식이 더 나아 보이는 상황도 많았다.

이런 경우에는 디자이너와의 소통도 중요하지만, 직접 Figma에서 컴포넌트를 통일하여 정의해놓는 것이 더 실용적일 수도 있다는 생각이 들었다.

다음에는 디자인 초기 단계부터 재사용 가능한 UI 컴포넌트를 먼저 정의하고 작업을 시작하는 접근 방식을 시도해보고 싶다.

☺️ 얻어갔던 점

얻어갔던 점은 별로 없지만 그래도 있으니 써보자!

✅ 코드 개선 – 하드코딩에서 구조화된 코드로

이번 프로젝트를 통해 파일 및 폴더 구조를 체계적으로 관리하는 습관을 익히게 되었다.
또한, 예전에는 값을 직접 하드코딩하는 방식으로 코딩을 했다면, 이제는 변수화된 값들을 별도로 관리하여 더 유연하고 유지보수에 용이한 코드를 작성할 수 있게 되었다.

특히 반응형 처리 측면에서도 변화가 있었다.
기존에는 @media 쿼리를 직접 하드코딩해서 썼지만, 이번에는 mixin 문법과 전역 breakpoints 변수를 활용하여 반응형 코드를 더 깔끔하고 일관성 있게 작성할 수 있었다.
이러한 접근은 재사용성과 확장성 측면에서 큰 발전이었다고 생각한다.

🧵 SCSS & Mixin – 스타일링 효율의 새로운 발견

기존에는 styled-components를 주로 사용했지만, 최근에는 다소 뒤처진다는 느낌을 받게 되었고, 대체 도구를 찾던 중 SCSS를 접하게 되었다.
CSS와 문법이 유사하여 빠르게 적응할 수 있었고, 특히 @mixin 문법을 활용해 공통 스타일을 효율적으로 재사용할 수 있다는 점에서 큰 만족감을 느꼈다.

타이포그래피, 컬러, 반응형 스타일 등을 각각 mixin으로 정의해두고, 필요한 곳에서 불러와 사용하는 방식은 작업 속도와 코드 일관성 모두를 높이는 효과가 있었다.
이번 프로젝트를 계기로 SCSS와 mixin 사용에 익숙해졌고, 앞으로도 적극적으로 활용할 계획이다.