[회고][데브코스 FE] 3차 프로젝트 회고

 

안녕하세요, 프론트엔드 개발자를 준비중인 dalsu 입니다.!~

제가 참여했던 데브코스 1기가 저번주 금요일 수료식 이후로 끝이 났습니다.

살짝 늦었지만, 지난 10월 말부터 11월 초까지 약 3주간 진행했던 3차 프로젝트에 대한 회고를 공유하고자 합니다.!~

 

이번 프로젝트는 저에게 특별한 의미가 있었습니다.

프론트엔드 개발자로서의 역할을 수행하면서 동시에 처음으로 Node.js를 활용한 백엔드 개발에도 도전해보았기 때문입니다.

기획에 1주일, 실제 개발에 2주일을 투자했던 이 시간 동안, API에 대한 이해도를 높이고 프론트엔드와 백엔드 간의 협업에서 중요한 포인트들을 발견할 수 있었습니다.

 

일단 FE개발자로서 얻은피드백에 대해서 먼저 생각해보고자 합니다.


FE 주요 피드백과 깨달은 점

💭 UX 관점에서의 개선사항

프로젝트를 진행하면서, 프론트엔드 개발자라면 프로젝트 전체적으로 사용자 경험(UX)에 대한 더 깊은 고민이 필요하다는 것을 느꼈습니다.

특히 강사님과 FT님께서 주신 피드백을 정리하면서, UX 개선의 필요성을 깊이 깨닫게 되었습니다.

강사님 피드백 1
강사님 피드백 2
그 외 피드백

 

받은 피드백을 다시 항목별로 정리하자면

  • 사용자 행동 예측성 강화
    • 클릭 시 발생할 동작에 대한 명확한 안내 부족
    • 슬라이드 기능의 존재를 직관적으로 인지하기 어려움. 
      → 슬라이드로 된다는 것을 어떻게 인식시킬 것인가?
    • 페이지 이동에 대한 사전 인지 부족.
      →  클릭하면 페이지가 이동된다는 것을 어떤 방법으로 인식시킬 것인가?
  • 유효성 검사 일관성 확보
    • 실시간 검사와 제출 시 검사가 혼재되어 있었음
    • 필수 입력 항목에 대한 명확한 표시 미흡
      → 필수 데이터가 입력되지 않았다는 것을 어떻게 인식시킬 것인가?
    • 오류 메시지의 통일성 부재

사용자가 어떤 액션을 하면(클릭, slide 넘기기 등), 어떤 일이 일어날 지 예측 가능하도록 혹은 미리 알 수 있는 장치가 필요해 보인다는 피드백이 위주였던 것 같습니다.

 

또한 유효성 검사에서도 적절한 메시지를 상황에 맞게 제공하면 좋겠다는 피드백을 받았습니다. 유효성 검사가 모든 페이지에서 통일성 있이 적용되었으면 좋았을텐데, 페이지를 팀원별로 담당하면서 개발하다보니 유효성 검사에 대해 서로가 관리하고 적용하는 방식이 달랐던 것 같습니다.

 

이러한 경험을 바탕으로, 다음 프로젝트에서는 기회가 된다면 아래와 같은 점들을 중점적으로 개선해보면 좋겠다고 생각했습니다.

  1. 직관적인 UI/UX 설계
    • 호버 효과나 툴팁, 코치마크 등을 활용한 상호작용 가능성 명시
    • consistent한 디자인 시스템 구축
    • 사용자 테스트를 통한 실제 사용성 검증
  2. 체계적인 유효성 검사 시스템
    • 프로젝트 전반에 걸친 통일된 유효성 검사 전략 수립
    • 명확하고 친절한 에러 메시지 제공
    • 필수 입력 항목에 대한 시각적 표시 강화

그리고 이러한 개선점들이 적용될 수 있도록, 개발 들어가기 전에 미리  UI/UX 제공방안에 대해 정도를 협의해두고 개발을 시작해야겠다는 생각이 들었습니다. 각자의 페이지를 개발하면서 서로가 정도를 다르게 제공하는 일이 없도록, 사전 협의가 필요하다는 것을 깨달았습니다.

 

✅ 받은 피드백을 활용하기

위에서 적었던, 3차 프로젝트를 진행하면서 느꼈던 점들과 개선이 필요하다고 생각했던 부분들을,

이후 피드백을 받으면서도 계속 기억하고 있었던 덕분에 저번주에 끝났던 4차(최종) 프로젝트에 적용할 수 있었습니다.

그래서 받은 피드백으로 한 걸음 더 성장할 수 있어서 정말 다행이라고 생각합니다.

4차 프로젝트를 마치고 느꼈던 점들은, 이번 포스팅이 끝나고 조만간 다시 정리해보고자 합니다.

 

이번 3차 프로젝트에서는 각자의 페이지를 개발하다보니 놓친 점들이 있었던 것 같습니다. 어느 부분에서는 실시간 유효성 검사, 어느부분에서는 제출할때 적용되는 유효성 검사 등... 전체적인 UI/UX 일관성이 아무래도 필요하다고 느낀 것 같습니다. 이 부분에서도 4차 프로젝트에 반영해볼 수 있었어서 건강한(?) 개발을 하고 있다는 것이 새삼 다시 느껴지는 것 같습니다.

 


BE를 하며 겪은 트러블슈팅, 느낀 점

🤔Why? 백엔드를 맡았는가

프론트엔드 5명으로 모인 팀에서, 자체적인 crud 기능이 포함된 프로젝트를 만드려다 보니 무조건 백엔드를 맡아야하는 개발자가 필요했었습니다.

이 과정에서, '과감하고 무모한 도전일 수 있지만 시간을 더 투자해서라도 배워보지 뭐!' 하는 마인드로 백엔드 개발을 맡겠다고 했던 것 같습니다.

다행히, 같이 백엔드를 맡으시는 나머지 팀원분이 백엔드나 프로젝트에 대한 이해가 뛰어나신 분이어서 많은 도움을 받기도 했고 또 도움을 드릴 수도 있던 것 같습니다.

 

🔎 트러블슈팅 한눈에 보기

프로젝트를 진행할 때 포트폴리오 작성 페이지 api 개발을 담당하면서, 가장 기억에 남는 두 가지 문제 해결 과정을 공유해드리고 싶습니다.

 

1️⃣ CKEditor 이미지 처리와 S3 저장 이슈

포트폴리오 작성 페이지에서 사용자들이 이미지와 텍스트를 자유롭게 작성할 수 있도록 하는 것이 목표였는데요.

여기서 재미있는 도전 과제가 있었습니다!

 

CKEditor에서 이미지를 처리할 때는 이런 과정을 거쳤어요:

  • 먼저 전체 콘텐츠에서 이미지 태그만 쏙쏙 뽑아내는 파싱 작업을 진행
  • base64 형식의 이미지를 파일 객체로 변환
  • 여러 이미지를 한 번에 S3에 올리는 API를 활용
  • 마지막으로 에디터 내 이미지 URL을 S3 링크로 교체

2️⃣ S3 버킷 스토리지 효율적 관리

처음에는 포트폴리오를 수정할 때마다 새로운 이미지가 S3 버킷에 쌓이는 문제가 있었습니다. 근데 이걸 해결하는 과정에서 S3의 재미있는 특성을 발견했어요!

 

해결 방법:

  • S3의 '같은 경로와 파일명으로 저장하면 자동으로 덮어쓰기'되는 특성을 활용
  • 에디터에 있는 이미지 순서를 파일명으로 사용하는 아이디어를 떠올림
  • 덕분에 포트폴리오 수정할 때 이미지가 자연스럽게 교체되면서 storage 관리가 훨씬 효율적으로 진행!

이런 문제들을 해결하면서 백엔드 개발의 묘미를 느낄 수 있었던 것 같습니다. 😊

 

🕯️느낀 점

백엔드 개발의 묘미도 느꼈지만...!

특히, 직접 API를 설계하고 개발하면서 BE와 FE 간 API의 필드명을 일관성 있게 정하는 것의 중요성을 깨달았습니다.

필드명이 일관되지 않으면 협업 시 혼란을 초래할 수 있기 때문에, 초기 설계 단계에서부터 세심하게 조율하는 것이 필요하다는 점을 배웠습니다.

또한, 페이지네이션 처리와 같은 기능은 프론트엔드 개발자 입장에서는 당연하게 여겨질 수 있지만, 실제로는 백엔드와의 협업을 통해 명확한 기준을 정하고 구현해야 한다는 점도 느꼈습니다.

이처럼 백엔드 개발을 경험하며, 단순히 기능을 구현하는 것을 넘어 협업과 소통의 중요성을 다시 한번 깨닫게 되었고, 이러한 과정에서 많은 성장의 기회를 얻을 수 있었습니다.

 


🌱 마치며 - 새로운 도전을 통한 성장

이번 3차 프로젝트는 저에게 특별한 의미가 있었습니다. FE 개발자로서의 역량을 키우는 동시에, BE 개발이라는 새로운 영역에 도전해보면서 많은 것을 배울 수 있었기 때문입니다.

 

글을 마치면서 위에서 느꼈던 주요 포인트들을 다시 정리하며 마치고자 합니다.

주요 성장 포인트

  1. 더 나은 UX를 위한 인사이트
    • 사용자 관점에서의 세세한 고민의 중요성
    • 일관된 사용자 경험을 위한 팀 내 사전 협의의 필요성
    • 실제 피드백을 통한 개선 방향 도출
  2. BE 개발 경험을 통한 시야 확장
    • API 개발과 이미지 처리 등 실제 서버 개발 경험
    • 프론트엔드와 백엔드 간 협업 포인트 이해
    • 문제 해결 과정에서의 기술적 성장

이러한 경험들은 4차 프로젝트에서 더 나은 결과물을 만들어내는 밑거름이 되었고, 앞으로도 개발자로서 성장해나가는 데 큰 자산이 될 것 같습니다. '과감하고 무모한 도전'이라고 생각했던 BE 개발이, 결과적으로는 더 넓은 시야를 갖게 해준 의미 있는 경험이었다고 자신 있게 제 스스로에게도 당당하게(?!) 말할 수 있다고 생각합니다.

3차 이후에 4차(최종)프로젝트도 끝이 나긴 했지만!

앞으로 마주할 프로젝트에서는 이번 3차 프로젝트에서 얻은 인사이트들을 토대로, 더 체계적인 기획과 구현을 해볼 예정입니다.