1. 코드스테이츠 교육 과정을 마치고
(22.05.01 ~ 08.18)
22년 8월 18일부로, 코드스테이츠의 교육 과정을 마치게 되었다.
여기서 마쳤다는 교육 과정은 project 과정을 제외한 '백엔드 개발자를 위한' 학습 과정이다.
약 4개월 간, 백엔드 개발자 로드맵을 4개의 Section 별로 나누어 학습을 진행했다.
이 중, Section 4는 [스프링 시큐리티, 클라우드 배포, Spring webflux] 를 다루는 내용으로 가장 기대한 부분이었다.
즉, Section 4 내용을 학습하는 것이 코드스테이츠 교육 과정을 이수하는 이유 중 하나였다.
덕분에 Section1부터 3까지 복습도 했으며, 새로운 기술들을 익힐 수 있었다.
1) 4개월 동안 경험한 학습 내용
사실 4개월 동안, '백엔드 개발자의 로드맵'을 전부 학습했다는 것은 매우 건방진 소리다.😥
정정하자면, '이런게 있구나' 라며 경험했다고 말하는 것이 맞다.
몇 가지는 생략했지만, 참 많기도 하다.
2) 앞으로의 성장 계획
이제까지는 전체적인 과정을 수직 방향으로 학습했다고 생각한다.
이제는 특정 기술과 기본이 되는 개념을 수평으로 확장해야 한다.
특히 JPA, 스프링 시큐리티와 스프링 프레임워크를 다루는 기술을 집중적으로 학습할 것이다.
최근 프로젝트를 진행하면서, JPA와 스프링 시큐리티로 많은 에러를 겪었다.
그러면서 해당 부분은 특히나 얕게 알면 안 된다는 것을 느끼게 되었다.
다시 요약하자면, 앞으로는 실제 서비스를 구현하기 위한 기술을 중점으로 학습을 진행할 것이다.
2. Pre-Project 중간 회고
(22.08.19 ~ 09.06)
역시나 코드스테이츠의 교육 과정으로,
이전에 학습 과정을 마쳤기 때문에 팀 프로젝트를 시작하게 되었다.
22년 9월 6일까지 진행할 프로젝트는 사전 프로젝트다.
다시 말하면, 9월 7일부터 진행할 Main 프로젝트를 위해 사전에 진행하는 프로젝트인 것이다.
사전 프로젝트의 목적은 이제까지 배운 내용을 적용하면서 복습도 하고, 프로젝트의 프로세스를 경험하기 위함이다.
현재 나와 동료들에게 첫 프로젝트인 셈이다.
사실 나는 이전에 개발 협업 프로젝트를 경험한 적이 있다.
단, 이전에 진행했던 프로젝트는 백엔드 개발자가 나뿐인 협업 프로젝트였다.
말 그대로 개발과 관련한 첫 협업 프로젝트일 뿐, 백엔드 개발자와 협업을 진행한 경험은 아니었다.
반대로 이번에 진행하는 프로젝트는 다수의 백엔드 개발자와 협업을 진행한다.
이런 의미에서 이번 프로젝트 첫 개발 협업 프로젝트라고 생각한다.
회고를 작성하는 시점은 사전 프로젝트 기간의 중간 지점인 8월 30일이다.
프로젝트를 시작한 이 후로 약 10일이 지났다.
따라서 10일 동안 겪었던 경험과 고민, 추후 개선방법에 대해서 기록하려고 한다.
1) 팀 소개
먼저 팀을 소개하겠다.
우리 팀은 프론트엔드 3명, 백엔드 4명(나 포함)으로 총 7명으로 이루어진 팀이다.
그중 내 역할은 PM(Project Manager)이다.
아무래도 개발 프로젝트 경험이 있어서인지 PM이 되었다.
자초한 것은 아니었지만,
나 역시도 프로젝트를 직접 관리하면서 동료 개발자들과 함께 성장하고 싶다는 욕구가 있었기 때문에 결과에 만족했다.
2) 프로젝트 진행
- 팀 빌딩
가장 먼저 프로젝트 진행을 원활하게 하기 위해 [팀 빌딩]을 진행했다.
팀 빌딩 내용
1. 팀 규칙 선정
2. 개발 규칙 선정
3. 협업 툴, 프로젝트 관리 툴 선정
4. 프로젝트 전략과 Branch 전략, 커밋 규칙 제시
- 프로젝트 선정
사전 프로젝트는 약 2주 동안 진행되는 짧은 프로젝트이다.
그래서 우리 팀은 Stack overflow 웹 사이트를 Clone 코딩하기로 했다.
팀 공동 목표로는 [웹 사이트 request, response 프로세스를 처음부터 끝까지 완성시키기]라고 정했다.
- 전체 일정
- 요구사항 정의 및 명세서 작성
해당 과정은 프로젝트 덕분에 배움을 얻을 수 있었다.
혼자 프로젝트를 진행할 때는 분석 및 설계 단계를 감으로 진행했다.
그렇다 보니 개발 진행 도중 변경 사항이 많아질 때마다 애를 먹은 적이 한두 번이 아니었다.
이번 프로젝트에서는 문서화 과정을 배울 수 있었다.
그렇게 우리 팀이 진행한 문서화는 아래와 같다.
문서화 내용
1. 요구사항 정의서
2. 화면 정의서
3. 테이블 명세서 및 ERD 스키마
4. API 명세서
3) HOT ISSUE🔥
- GitHub 팀 Repository Delete
22/8/29 ~ 8/30
프로젝트를 진행하던 도중 재밌는 이슈가 발생했다. 팀원 한 명이 팀 repository를 삭제한 것이다. 사실 fork 했던 본인의 repository를 삭제하려고 했으나, 착각하고 실수했다. (Ctrl C, Ctrl V 의 폐해이기도 하다..)
작성했던 프로그램 환경과 코드들은 사라졌고, 갑작스러운 이슈로 인해서 프로젝트 진행이 쉽지 않았다. 그렇게 하루 동안 우리는 대처 방법을 생각했다. 다행히도 삭제했던 레파지토리는 완전히 삭제된 것이 아니어서 복구가 가능했다. 어떻게 보면 간단하면서도, 그 순간에는 하늘이 무너질 듯한 무서운 이슈였다고 생각한다. 이번 문제는 온전히 팀원의 실수라고 보기는 어려웠다. 그 이유는 초기 팀 repository를 설정할 때, 팀원들에게 admin 권한을 부여했기 때문이다. 조금 더 고려했다면 이 문제는 발생하지 않았을 것이다. 덕분에 권한의 중요성을 크게 느낀 경험이 되었다.
추가로 이때 해당 이슈를 팀원들에게 공유를 때, 한 명도 빠짐없이 "다시 하면 되죠!"라는 말을 전했다. 멋진 팀원들의 긍정적인 말 덕분에 PM인 나로서도 걱정보다는 다른 방법으로 대처할 수 있는 여유를 가질 수 있었다.
- 다수의 백엔드 개발자와 첫 협업 진행
ISSUE
다수의 백엔드 개발자들과 진행하는 첫 협업이기 때문에, 개발 진행 방법에 대해서 고민이 많았다. 설상가상으로 팀원들이 아직 개발에 익숙하지 않은 상태여서, 무엇이든 쉽게 결정하기가 어려웠다.
SOLVE
이 고민을 해결하기 위해 이번 프로젝트의 목적을 다시 생각했다. 이번 프로젝트를 통해서 학습했던 내용을 복습하고, 개발 프로세스를 이해하는 게 중요했다. 이를 통해 '동료들을 최우선적으로 성장시키자'라고 결정했다.
이어서 따라온 고민은 '어떻게 성장시키냐'이었다. 그래도 목적을 정하니 방법을 생각하는 것은 어렵지 않았다.
(1) 코드 리뷰 도입 - 팀원들이 본인이 구현한 코드를 말로 설명하게 했고, 나는 부족한 부분을 보완하며, 강의를 진행했다.
(2) 팀원에게 맡는 역할 부여 - 팀원들의 부족한 점을 파악했고, 필요와 상황에 맞게 역할을 부여했다. 여기서 중요한 것은 핵심 관심사 부분에 코드 구현을 팀원들에게 맡겼고, 부가적인 부분을 내가 구현했다.
추후 Main 프로젝트 시에는,,
(1) 프로젝트 환경 구성시 - 패키지 구조 형성 (PM)
(2) 모든 팀원들이 도메인을 맡고 entity 구현 및 연관 매핑 진행
(3) 각자 맡은 도메인 기능 개발, API 명세서 작성, 테스트 코드 구현
- Github 브랜치 전략과 프로젝트 진행 방법 강의 진행
많은 팀원들과 어떻게 일관성 있게 프로젝트를 관리할 수 있을지 고민했다.
확실한 건 규칙을 명확하게 짜야한다는 것이다. 그리고 모두가 이 규칙을 이해해야 한다고 생각했다.
이에 나는 구체적인 예시와 모두가 이해할 수 있는 용어로, 자료를 만들어 공유하고, 강의를 진행했다.
056(Not-Error) 팀 Github repository입니다.
'RECORD > 회고' 카테고리의 다른 글
| [Project] 험난했던 'SPRINT 1'을 마치고 (1) | 2022.09.28 |
|---|---|
| [Project] 백엔드 개발자의 PM 회고록: 사전 프로젝트를 마치고 😆 (5) | 2022.09.09 |
| [회고] 동료와 내일이 있음에 감사하며! (4) | 2022.07.26 |
| [회고] 5월의 회고록 : 어쩌다 또 도전 시작 - 코드스테이츠 (15) | 2022.05.24 |
| [Project] 문화 공유 웹/ 앱 플랫폼 - 헤리티지 (24) | 2022.03.19 |
