돌아보니 저는 백엔드 역량에만 치우진 사이드 프로젝트만 하고 있었던 것 같습니다.
그러다보니 항상 반쪽짜리 프로젝트만 만들게된 것이 아쉬웠고, 이즈음에서 제대로된 한 사이클의 어플리케이션을 만들어봐야겠다는 결심을 했습니다.
이 시리즈는 프로젝트를 진행하면서 겪는 어려움과 회고가 기록할만큼의 쌓이면 작성됩니다.
사이드 프로젝트 선택
먼저 내가 풀스택으로 개발할 것인가? 아니면 팀을 구할 것인가? 를 고민했는데, 실무와 병행하면서 실력을 키우려면
백엔드에 더 집중해야된다는 결론을 냈습니다.
몇 번의 사이드 프로젝트와 실무를 경험하면서 개발자의 관점에서 느낀 점은 3가지 였습니다.
- 내가 안다고 생각하던 기술도 노베이스에서 적용하려고 하면 헤멘다.
- 공부한 기술을 실무에 적용하고 싶지만, 피쳐 개발이 우선인 스타트업의 특성 상 쉽지 않다.
- 사이드 프로젝트 아이템의 참신함은 중요하지 않다. 중요한 것은 기술을 녹이는 것이다.
백엔드의 가장 흔한 프로젝트인 게시판 만들기도 기술과 설계를 적용하기 시작하면 얼마든지 도전적인
프로젝트가 될 수 있다는 것을 알고있기에, 실력 향상에 적합한 팀을 찾기로 했습니다.
제가 잡은 최소 기준은 4가지 였습니다.
- 경력 있는 프론트 개발자가 있는 팀.
- 프로토 타입이 나와있거나, 최소한 기획안이 확정된 팀.
- 주 1.5 ~ 2 영업일을 기술적으로 투자할 분량이 있는 프로젝트.
- 사이드 프로젝트임을 인정하고 비지니스 모델이 없는/서두르지 않는 팀.
다행히 기준에 부합하는 팀에 합류 할 수 있었습니다.
팀 구성
- 기획 1 경력 0년
- 디자인 1 경력 0년
- FE & 앱 1 경력 0년 (C++ 게임 개발 경력 n년)
- BE 1 경력 1년 (인프라 & 기술지원 경력 n년)
- 주 1회 오프라인 모임
개인 목표
- 도전적인 기술 적용
- 흐름도, 객체 관계에 입각한, 변경에 강한 설계
- CI/CD 구성
- 테스트 설계
- 모니터링 설계
- 위 모든 과정을 기록
주요 진행 내용 & 어려움
- 초기 세팅 및 FE 와 API 연동 & Swagger 제공
- spring security 를 활용한 JWT 로그인 & 권한 관리 Link
기획에서 기술 리뷰까지
개발자의 일정 관리를 위해서 가장 중요하다고 생각하는 것은, 기획자의 전체 의도를 파악하고 MVP 에 맞는 (또는 일정에 맞는)
기술 범위를 산정하는 것이라고 생각합니다.
하지만 팀원의 절반이 팀 프로젝트 경험이 없고, 체계가 잡히지 않았기에 커뮤니케이션 낭비는 필연적일 것 같습니다.
회사라면 오프라인 미팅과 잦은 슬랙을 통해 의견을 좁힐 수 있지만, 본업과 병행해야 되는 사이드 프로젝트의
특성상 커뮤니케이션 포인트를 줄이면서 해결할 수 있는 방법을 고민해야만 합니다.
마치며
만료 기한이 짧은 JWT 를 통한 로그인은 구현했지만, 기획에서는 기 로그인자는 로그인 과정을 생략한다 는
요구 사항을 전달해주었습니다. 직관적으로 드는 생각은 refresh token 을 활용하는 것이지만,
이것을 FE 에도 설명하기 위해서는 공부하고 구성도를 그려야 할 것 같습니다.
짧은 2 주의 개발에서도 도전적인 기술을 적용했고, 앞으로도 회사에서는 해보지 못한,
하지만 도움이 될 기술을 연습할 수 있을 것이라는 생각에 즐겁습니다.
'잡담 & ETC' 카테고리의 다른 글
code kata 를 하자! - Codewars (0) | 2023.02.20 |
---|---|
요즘 애들은 문해력이 낮아진걸까? (0) | 2022.09.10 |
어느 새벽에 작성하는 첫 회고록 (3) | 2021.12.10 |
좋은 개발 문화란? - (2) 준비 (0) | 2021.11.15 |
좋은 개발 문화란? - (1) 실패 (0) | 2021.11.15 |