HexSchool Node.js 기업 전문반
HexSchool Node.js 기업 전문반을 수료한 후, 몇 가지 소소한 생각과 반성을 정리해봤다.
왜 이 과정을 선택했나? 어떤 문제를 해결하고 싶었나?
꽤 비싼 과정이었다. 게다가 HexSchool(대만의 코딩 부트캠프)의 특성상 상업적인 이유로 수강생을 거절할 수 없기 때문에, 커리큘럼 난이도가 비교적 쉽게 설계될 수밖에 없다.
이런 조건들을 보면 수강 신청이 별로 이득이 아닌 것처럼 보이지만, 실제로는 다음과 같은 측면에서 고려해볼 만하다.
팀 협업
과정 시작부터 조를 나눠서 함께 개발해야 했다. 수강생 대부분이 프론트엔드 출신이라 백엔드 실무 경험이 거의 없었기 때문에, 우리에게는 백엔드 개발 간의 커뮤니케이션과 협업을 연습할 좋은 기회였다.
다른 측면에서 보면, 함께 협업한 동료들이 앞으로 서로 도울 수 있는 관계가 된다는 점에서 일종의 인맥 형성 방식이기도 하다.
매몰 비용
앞서 말했듯이 꽤 비싼 과정이다. 나처럼 게으른 사람이라도 이 돈을 날리고 싶지 않다면, 퇴근 후에 시간과 에너지를 들여서 프로젝트 진도를 따라잡아야 하고, 마감 전에 프로젝트를 완성해야 손해를 보지 않는다. 어떤 면에서는 자기 관리 목표를 달성하는 데 도움이 되기도 한다.
새로운 시각
전체 프로젝트가 기획 구상부터 개발까지 한 번에 이루어진다. 객관적으로 보면 전체 내용이 꽤 기초적이지만, 모든 팀원이 PM, UI/UX, 프론트엔드, 백엔드의 전 과정을 직접 경험해볼 수 있어서 앞으로의 업무에도 새로운 시각을 얻을 수 있다.
과정 내용
과정 내용 중에서 기본적인 MongoDB 명령어 조작과 Node.js API 구현을 제외하면, 개인적으로 가장 가치 있었던 부분은 서드파티 서비스 연동이다. 소셜 로그인이나 결제 시스템 같은 것들인데, 이 부분은 꽤 정형화된 작업이라 상대방의 문서를 시간 들여 확인해야 연동을 완성할 수 있다. 강의가 있으면 문서를 찾아보는 시간을 절약할 수 있는 셈이다.
또한, 과정 내 일부 설계는 여전히 MVC 패턴을 예시로 사용하고 있어서, 팀원들이 프로젝트 구현 시 직접 프론트엔드와 백엔드를 분리해야 했다. 이 부분도 시간을 들여 고민해야 하는 부분이었다.
일부 과정 내용은 외부 강사를 초빙해서 라이브 강의 형식으로 진행되다 보니 약간의 괴리가 있을 수 있었다. 예를 들어 이번 단위 테스트 강의 예제는 프론트엔드용으로 제공되었기 때문에, 백엔드 단위 테스트를 연습하려면 결국 팀 자체적으로 해결해야 했다.
프로젝트 실습 (매우 주관적인 후기)
프로젝트 실습이 이 과정에서 가장 가치 있는 부분이라고 생각하고, 그중에서도 가장 중요한 건 팀 내부의 협업과 기획이다.
조 편성 전에 솔직하게
팀 편성 전에 개인 역량 평가가 있는데, 익숙하지 않은 영역이라면 솔직하게 말해야 한다. 팀원 간 실력 차이 가 너무 크면 심각한 의견 충돌이 생기기 쉽고, 프로젝트 진행이 어려워진다.
개발 시 여유 시간 확보
대부분이 프론트엔드로서 백엔드 개발에 들어오기 때문에, 이전에 프론트엔드에서는 마주하지 않았던 세부 사항들이 개발 속도를 늦출 수 있다. 예를 들어 결제 시스템 연동 후에는 반드시 주문 처리를 해야 하고, 주문 자체가 거래 시간 등의 문제와 연관된다.
프론트엔드 입장에서는 이전에 이런 부분을 고려할 일이 거의 없었다. API 연동하고 리스트 표시하고 조작하는 게 전부였으니까. 하지만 백엔드에서는 이런 문제들을 반드시 고려해야 한다.
프로젝트 배포를 목표로
반드시 다음 사항들을 진지하게 고려해야 한다.
- 팀원 대부분이 직장인이라 투입할 수 있는 시간이 제한적이다 (팀원의 업무에 갑자기 긴급 건이 생기거나 야근이 있을 수 있다)
- 마감 기한이 매우 촉박하고, 실제 개발 시간이 한정적이다
- 대부분의 팀원이 백엔드 경험이 없어서 시행착오에 시간이 걸린다
그래서 1단계 목표는 쓸 만한 결과물을 만드는 것이지, 완벽한 작품이 아니다. 이 단계에서 아키텍처, 최적화, 테스트 같은 것들은 너무 많이 고민하지 않는 게 좋다. 그건 나중 일이다.
완벽함을 지나치게 추구하면 개발 일정이 막히는 것은 물론, 더 무서운 건 팀이 분열될 수 있다는 것이다 (잠재적인 갈등, 특히 팀원이 낮에 업무 스트레스를 받고 있는지 알 수 없다). 팀이 한번 분열되면 프로젝트는 94.87% 실패한다고 보면 된다. 못생겼지만 돌아가는 기능을 먼저 만들면, 서로에게 큰 자신감을 줄 수 있다.
특히 팀에서 사용하는 기술 스택을 무한 확장하는 것을 피해야 한다. 프론트엔드 기준으로 React와 Vue를 동시에 쓰는 상황은 있어서는 안 된다. 팀 내 누군가가 특정 프레임워크에 매우 능숙하더라도, 다른 사람들이 빠르게 배워서 개발에 활용할 수 있다는 의미는 아니다.
확장과 최적화
프로젝트에서 첫 번째 역할의 기능이 완성되면, 보통 1단계가 끝났다고 볼 수 있다. 잠시 숨을 돌릴 수 있을 뿐만 아니라, 다른 기능 개발도 고려할 수 있다. 구현해보고 싶었던 기술이나 UX 개선 같은 것들도 포함해서.
우리 프로젝트를 예로 들면, websocket 메시지 스트리밍, PWA, 애니메이션, 출석 체크 시스템 등을 단계적으로 추가해서 전체 웹사이트의 콘텐츠를 더 풍부하게 만들었다.
마치며
마지막으로 이번 프로젝트의 프론트 오피스와 백오피스 배포 주소 및 Repo를 첨부한다. 참고하시길.
프론트 오피스 (Client)
백오피스 (Admin)
<!-- test account & password -->
account : admin
password : 12345678