백엔드와 함께하는 최종 프로젝트의 배포와 발표가 마무리 되었다.
이렇게 달려야 했던 프로젝트가 있었나 싶을정도로 벅찬 일정안에 무사히 모든 기능 구현과 테스트가 완료되어 기쁜 마음이다. 많은 것을 배우고 경험한 프로젝트이니 회고로 기록해보자.

프로젝트 결과물 돕당 (DOPDANG)
🚀 배포 주소 : https://www.dopdang.shop/

---

프로젝트 준비

팀매칭

이전의 두 프로젝트는 운영진이 임의로 결성한 팀원들과 함께 팀프로젝트를 진행했는데, 마지막 최종프로젝트는 프론트엔드 구성원간 자율적으로 팀을 구성한 후 백엔드 팀원을 뽑는 방식이였다. 나는 놀랍게도,, 이걸 몰랐다..! 😅

다행히도 자율 팀결성 공지가 있기전 몇몇 개발자분들이 합류제안을 주셔서 알수있었다. 결론적으로는 같이 스터디을 했던 팀원들과 최종 프로젝트를 하게되었다. 초반에는 감사한 마음에 들떳기도 했지만, 더욱 열심히 참여해서 내 몫을 해내야겠다는 생각에 이내 마음이 바빠졌다.

프로젝트 시작

💡 기획

1️⃣ 문제 파악

이번 프로젝트는 팀원들 모두 기술적으로 성장하고자 하는 의지가 강력했다. 백엔드 분들도 마찬가지셨는데, 백엔드에서 요구하는 기술사항(실시간통신, 동시성 문제 처리, 시간기반 로직 구현)에 맞추느라 아이디어가 한정되어 나오기도했다.

이를 모두 구현할 수 있는 서비스가 실시간 경매 서비스여서 초반에는 이에 맞춰 아이디어가 디벨롭 되었는데, 조사를 할수록 기존 서비스의 문제를 해결하기 보다는 바퀴를 다시 발명하고 있다는 느낌이 강하게 들었다.

그래서 다시 한발 떨어져서 고민해보았다.

"기술스택에 집착하지 말고 내가 진짜 필요했던 게 뭘까? "

펫트너 프로젝트에서 느꼈듯, 기술은 현실의 문제를 해결하기위한 도구이니까 기술에 매몰되지 말고 자유롭게 생각해보기로 했다.

이 당시 나는 코드리뷰에 대한 갈증에 목말라 있었다. 이게 잘짠 코드일까 항상 고민했고 팀원들에게 코드리뷰를 요청하기도했다. 이때 들었던 생각은 좀 더 전문적인 개발자에게 내 고민을 속시원히 털어놓고, 코드리뷰를 받을 수 있었으면 좋겠다는 것이였다.

여기에서 착안하여 전문가 매칭 플랫폼 <돕당>이 탄생했다.

2️⃣ 서비스 구체화

지금까지 만든 서비스 중, 가장 기획단계가 어렵고 복잡하였다고 단언할 수 있다.

먼저 돕당 서비스를 도움이 필요한 사람(의뢰인)과 서비스제공자(전문가)를 쉽게 연결해줄 수 있는 플랫폼으로 골자를 잡고 난뒤 이에 필요한 세부 기능사항과 유저플로우를 구체화했다.
돕당은 서비스 요청부터 전문가 상담 및 견적서 작성 → 계약 → 구매 → 작업 진행 → 서비스완료 및 리뷰 까지의 단계가 아주 촘촘하고 유기적으로 연결되어 있다. 프로젝트 진행과정 내내 여러 서비스 사용 사례를 가정해 보면서 여러번 수정을 거치며 빈 구멍을 촘촘히 메꾸려 노력했다.

서비스는 크게 다음과 같이 구성된다.

• 🏪 스토어 : 유/무형의 서비스와 상품을 사고 팔 수 있다.
• 👨‍💻전문가 : 각 카테고리별 전문적인 능력을 가진 전문가의 프로필을 볼 수 있고 서비스를 요청할 수 있다.
• 📁 프로젝트 : 돕당의 의뢰인들이 만든 요청서를 볼 수 있다.
• 💬 실시간 채팅: 의뢰인과 전문가가 만나 상담할 수 있으며, 대화를 통해 가격을 흥정할 수 있다.
• 💰 결제 : 스토어 상품과 전문가와의 계약금액을 정산할 수 있다.
• 🗝️ 마이페이지 : 유저정보, 전문가 포트폴리오, 현재 프로젝트의 진행도를 확인하고 관리할 수 있다.

위 사진에서도 볼 수 있듯, 의뢰인과 전문가. 두 역할이 있다는 말은 의뢰진행이 시작될 수 있는 갈래가 2가지가 있다는 말이다..!
두가지 시작점을 가지면서도 요청서 - 견적서 - 계약서로 연결되는 플로우를 동일하게 가져가게 할 수 있도록 하느라 고민을 많이 했다.

이해를 돕는 돕당 프로젝트 소개서도 작성했다!

꽤나 복잡한 기능 구조도가 만들어졌다..!

🎨 디자인

프론트에서는 이전 프로젝트의 반복적으로 만들어지는 컴포넌트에 대한 문제점을 해결하고자 했다.팀장님께서 아토믹 디자인 패턴의 사용을 제안했고 팀원 모두가 이를 숙지한 뒤 프로젝트에 적용하였다.이에 관환 경험은 여기에 자세히 남겨두었다..!

디자인은 피그마를 사용하여 진행했는데, 이미 디자인에 익숙한 팀원분이 있어서 이전 프로젝트보다 훨씬 수월하게 할 수 있었다.
디자인 시스템을 구축하고 이를 바탕으로 공통 컴포넌트를 만든뒤 페이지에 적용하는 방식으로 작업햇는데, 페이지 수가 많은 것에 비해 빠르게 작업을 할 수 있었다.

돕당 디자인 시스템	공통 컴포넌트

이번 디자인에서 특히 고려된 점은 명도 웹접근성 가이드를 따랐다는 것이다.

웹 접근성은 장애인이나 고령자는 물론 어떤 사용자들도 웹사이트에서 제공하는 정보를 비장애인과 동등하게 접근하고 활용할 수 있도록 하자는 개념이다.
저시력자, 고령자 등도 인식할 수 있도록 콘텐츠와 배경 간의 명도 대비는 4:5:1 이상이어야 한다.

크롬의 LightHouse에서도 명도대비(Contrast Ratio)에 대한 지표를 제공하고 있고, 이는 WCAG(Web Content Accessibility Guidelines)의 기준에 맞는지 검사하는 지표 중 하나이다. LightHouse의 "Accessibility"카테고리안에 있고 문제가 있다면 아래사진 처럼 "Background and foreground colors do not have a sufficient contrast ratio."란 문구를 띄워준다. (즉, 배경과 텍스트의 글씨의 명도대비가 알아볼 수 있을 정도로 뚜렷해야함!)

이번 경험을 통해 명도대비같은 디자인적인 접근성요소를 신경써야겠다고 마음먹게되었다. 그 이유는 프론트개발자의 일이 단순히 예쁜 UI가 아니라 실제로 사용가능한 웹을 만드는 일에 직결되기 때문이다. 초반에는 이러한 부분이 디자인적인 요소로만 느껴질 수 있지만 조금만 더 익숙해지면 색상선택, 상태변화(hover, focus)등에서도 "접근성을 위한 선택"을 하게된다. 예를들면 hover상에 일때 단순히 배경색 변화만 있다면 색각이상자는 차이를 느끼지 못할 수 있다. border, font-weight 과 같은 보조적 요소를 함께 넣으면 더 나은 웹을 만들 수 있다.

개발

개발 관련하여 구현하면서 느꼈던 점은 아래 글에 싣을 예정이다.

• Next.js 미들웨어 처리하기
• 아토믹 디자인 패턴 적용기
• Axios대신 fetch 사용하기( API Builder 패턴)
• 실시간 채팅, 결제 기능 구현하기

---

Keep, Problem, Try, Emotion 회고로 정리하기

1️⃣ KEEP : 잘했던 점, 앞으로의 프로젝트에도 유지해야할 사항

기술적으로 도전하기

jejumonth프로젝트에서 남긴 과제로 "기술적으로 도전하기"라는 항목이 있었다. 이번 돕당 프로젝트를 통해 기존의 CRUD 말고도 다양한 구현과제가 주어져서 힘들기도 했지만 뿌듯했던 기억이다. 돕당에서는 전문가페이지와 스토어 페이지를 비롯하여 핵심기능이라고 할수있는 실시간 채팅기능과 결제기능을 맡게되었다.

실시간 채팅의 경우 HTTP를 이용한 통신과 달리 웹소켓을 사용하여 이루어지는 양방향 통신이기에 이에 대한 공부를 선행한뒤 구현을 시작했다. 프론트측에서는 socket.io-client 혹은 STOMP를 사용하는 방법 2가지가 있었는데 백엔드와의 호환성을 위해 STOMP와 SockJs를 활용하여 구현했다. 실시간채팅의 경우 클라이언트측의 코드 구현은 복잡한 편이 아니었다고 생각한다. 오히려 백엔드측 redis에서 실시간성 관련 오류가 자주 발생해서 이를 해결하느라 고생했다.
생각보다 어려웠던 점은 채팅방 페이지를 구성하기 위한 정보들이 다양했는데( 요청서 정보, 채팅방 목록 정보, 견적서 정보, 전문가 정보 등) 백엔드 api 를 설계할때 필요한 데이터가 충분히 정리되어있지 않아서 이를 조율하고 커뮤니케이션하느라 일정이 딜레이되었다. 백엔드가 API 설계하기전 팀장님께서 Figma페이지를 확인후 누락되는 정보가 없도록 해달라고 부탁하셨는데 앞으로의 일정에 꼭 필요한 말이었다..! 그럼에도 불구하고 앞으로는 복잡한 페이지 설계시에는 프론트와 백엔드가 의논하는 시간을 충분히 가진 후 구현에 착수해야겠다는 생각이 들었다.

두번째로 (1)의뢰비용과 (2)스토어 상품비용의 청구를 위해 TossPayment를 활용한 결제기능을 구현했다. 담당 백엔드 분이 이미 결제기능을 구현해본 경험이 있으셔서 구현 과정이 생각보다 어렵지는 않았지만, 최종 결제 완료 페이지를 하나의 경로에서 처리하려다 tosspayment-api 구조상 그게 불가능하다는 것을 뒤늦게 알게되어 중간에 삽질하느라 시간을 꽤 썼었다. (리디렉션이 안되는 이슈..)
이와는 별개로 결제창을 띄우기 부터 결제완료까지의 과정은 tosspayment 문서에 친절하게 설명되어 있어 보면서 감탄했던 기억이 있다..! 구현하면서 신경썼던 점은 사용자의 결제관련 정보를 클라이언트 측에 노출하지 않기위해 SSR를 사용해 보안상 안전하게 만드려고 했다. 때문에 데이터 패칭 레이어, 페이지 랜더링 레이어, 결제 로직 레이어로 분리해서 결제페이지를 완성했다.

이외에도 Next.js를 사용하면서 middleware를 사용해 URL 접근 제한을 구현한것, axios를 사용하지 않고 스터디에서 배웠던 API Builder를 활용해서 처리한것, 프로젝트에서 Storybook을 적용한 것 등 배운 점이 많아서 더 뿌듯했다..!

2️⃣ PROBLEM : 아쉬웠던 점, 앞으로 개선해야할 사항

일정 계산 능력 기르기

프로젝트 진행기간 동안 일정을 보수적으로 잡았다고 생각했는데 생각보다 여유가 없어서 당황했다..! 약 3주+a의 기간동안 실질적으로 개발할 수 있는 시간이 15일 내외 정도였다. 이 기간동안 3명이서 1000개 넘는 커밋을 쌓았으니 꽤나 달렸다고 볼 수 있겠다.

개발일정 초반에는 공통 컴포넌트를 만들고 이후 남은 일주일간 나머지 기능을 처리하기로 일정을 잡았다.
먼저 약 3일간비교적 빠르게 구현할 수 있는 스토어와 전문가 페이지를 만들었다. 등록과정을 팀원분께서 맡아주셔서(압도적 감사🙏) 이후 4일간 결제와 채팅 페이지 구현에 집중할 수 있었다. 나머지 2일간의 QA기간동안 잔 버그를 고치고 최종 발표영상녹화까지 마무리했다.

바쁜 일정이였고, 생각보다 시간이 남는 날에는 미리미리 이후 일을 해두었지만 절대 여유있는 일정은 아니였다..!
팀장님이 일정 산출을 꾸준히 해주시고 중간중간 푸쉬해주지 않았다면 자칫 더 늦어졌을 수도 있다고 생각한다.
일정을 산출 할때는 구현할 기능을 더 상세히 쪼개고 이에 복잡도와 버퍼시간을 더해 시간을 잡아야겠다. 그리고 반드시 이 기간안에는 끝낼 수 있다는 마음가짐은 필수다 👨‍💻

3️⃣ TRY : 다음 프로젝트에 적용해볼 Action Item

보다 독립적인 프론트엔드로 도약하기

이번 프로젝트를 하며 더욱 여실히 느꼈던 점은 "프론트엔드 독립성 확보"의 중요성이였다. 보통은 백엔드가 api를 만들고 나서야 프론트작업이 시작할 수 있다. 하지만 독립적으로 API 없이도 개발이 가능한 환경이 구성된다면 프론트는 백엔드 작업이 끝나기 전에 UI구현, 상태관리, 테스트를 마칠 수 있을 것이며 이는 팀 전체 개발 사이클이 빨라지는데 도움을 줄 것이다. 특히 서버 상태 로딩/에러처리같은 경우 테스팅하기가 까다로운데 이를 처리하면서 독립적인 프론트엔드 개발에 대한 니즈가 생기게 되었다. 다음 프로젝트에서는 MSW와 같은 모킹라이브러리를 활용해서 API에 비교적 덜 끌려다니며, 더 안정적이고 주도적으로 개발하고 싶다.