멘토링 시스템
42서울에는 멘토링 시스템이 존재한다.
멘토링 시스템은 슬랙으로 카뎃-멘토 사이 예약이 이루어지고, 진행된 멘토링의 보고서는 멘토가 개별적으로 작성 후 스태프에게 제출하는 방식이다.
설문조사 결과, 현재 방식에는 몇가지 불편한 점이 존재한다.
- 멘토링 채널에 공개적으로 글을 올리거나, 멘토에게 개인적으로 메세지를 보내는 방식에 거부감(?)을 느낌
- 멘토의 보고서 제출 방식이 번거로움
- 스태프는 보고서 확인 방식이 번거로움(메일로 받은 보고서들을 일일이 취합하여 관리)
- 멘토에 대한 정보가 없음
- 어떤 멘토들이 존재하는지 알기 어렵다.
- 멘토들에 대한 후기가 있었으면 좋겠다.
- 현재 멘토링이 가능한지 모르겠다.
- 각 멘토들이 최근에 진행한 멘토링 이력을 알고싶다.
개발 기능
따라서 우리는 다음과 같은 기능을 가진 웹서비스를 제작하기로 결정했다.
- 키워드(협업, 창업 등)에 맞는 멘토 리스트 출력
- 각 멘토는 본인의 상세 페이지를 가짐
- 상세 페이지에는 슬랙아이디, 멘토링 가능 상태, 가능 시간, 자기소개, 키워드, 댓글 등
- 카뎃
- 키워드를 이용하여 본인에게 맞는 멘토 검색 후, 각 멘토가 가진 가능 시간에 맞게 예약이 가능
- 마이페이지에서 멘토링 내역 확인 가능, 대기중 상태일 경우 취소 가능
- 멘토에게 댓글 작성 가능
- 멘토링 예약 현황은 카뎃/멘토에게 이메일로 알림
- 멘토
- 마이페이지에서 멘토링 내역 확인, 멘토링 수락/거절 가능
- 멘토링이 완료된 경우 보고서 작성 가능
- 스태프
- 제출된 보고서 확인 가능
- 보고서는 날짜, 멘토 이름 등으로 검색/정렬 가능
- 보고서 PDF 출력, 엑셀 저장 가능
- 48시간 이내에 멘토링 신청에 대한 응답이 없을 경우 자동 취소
- 멘토링 신청의 상태 변화에 따라 카뎃/멘토에게 이메일 알림
진행 상태
8월 2주간 NestJS 학습 스프린트를 시작으로 8월말 기획 시작, 9월 개발 시작, 현재 멘토님들께 배포를 완료했고 카뎃 배포 날짜를 앞두고 있다.
폴라는 내가 42에 들어오고 나서 처음으로 진행한 팀프로젝트이고(42과제 제외), NestJS도 처음 사용해본 스택이라 아쉬운 점이 많지만.. 그만큼 배운 점도 많았다.
사실 개발을 진행하면서 해당 내용에 대한 글을 작성하려고 했는데, 체력의 문제로 그러지 못하고 배포가 끝난 지금 생각해둔 주제로 하나씩 글을 작성하려고 한다.
문서화에 대하여
처음으로 다른 사람들과 함께 개발을 진행하면서 느낀점은 "생각을 똑같이 공유할 수 없으니 문서화가 굉장히 중요하다"는 것이다.
하나의 이슈에 대해 합의를 보고 시간이 흐르면 결정 사항에 대해 다르게 기억하는 경우가 발생했다.
초반에 서로 가장 많이 했던 말이
- 그래서 이거 어떻게 하기로 결정했었죠?
- 이 기능은 왜 이렇게 변경되었나요?
이런 것들이었다.
다같이 의사결정을 진행했으니 모두가 모든 결정을 기억할 거라는 착각을 하고 있었고, 일부만 합의 후 변경한 코드를 알리는 것을 잊어버리기도 했다.
문제를 인식한 후, 회의 끝에 다음과 같은 해결방안을 생각해냈다.
- 의사결정이나 변경점에 대해 노션에 기록하자
- 유사PM을 선정해서 흩날리던 여러 이슈들을 한곳으로 모으자
효과는 굉장했다? 특히 유사PM의 역할이 '사공이 많아 배가 산으로 가는 상황'을 막아주는 것 같았다.
또다른 문제는 API가 늘어나면서 발생했다.
각자 api 한두개씩 작성하던 시절에는 입출력 값의 포맷에 대해 기억하고 알려줄 수 있었다.
하지만 시간이 흐르고, 그 수가 증가하고, 입출력에 대한 잦은 변경으로 인해 매번 코드를 뜯어보고 사용하는 경우가 늘어났다. 결국 우리는 스웨거를 도입하기로 한다.
스웨거의 효과도 굉장했다.
이번에 처음 사용해봤는데, 왜 이걸 진작 사용하지 않았지? 하는 생각이 들었다.
매번 해당 api를 작성한 사람에게 뭍거나, 코드를 뜯어보던 원시인 방식에서 문서 한번 읽으면 끝나는 문명인 방식으로 진화한 것이다.
점점 늘어나는 스웨거 데코레이터에 코드가 더러워졌지만 유지보수 기간에 커스텀 데코레이터를 도입해볼 생각이다.
협업에 대하여
사실 팀원간 합이 좋아서 그런지.. 특별한 문제나 충돌이 발생하지 않았다.
팀 분위기 자체가 누군가 한 주제로 질문을 하면 다들 각자의 아이디어로 토론을 벌이다가, 납득시키는 쪽의 의견을 따르는 방식이었다. 다들 42 생활 덕분인지 이런 의사소통에 익숙해서 그런 것 같기도..
시작에 대하여?
프로젝트 진행하면서 아쉬웠던 점은
- 기획을 좀 더 길게 잡고 갔으면 좋지 않았을까?
- 시작부터 스웨거 틀을 딱 잡고 갔으면 좋지 않았을까? (개발 중간에 추가되어서, 모든 api에 붙이고 수정하고 하는 과정이 괴로웠음)
결국, 초반에 확실히 결정하고 시작했으면 좋았을텐데..하는 후회였다.
그런데 이 생각에 대해 멘토님이 "모든 걸 다 갖추고 시작하려면 시작도 못하는 때가 많다"라고 적절히 해야 한다고 말씀해주셔서 고개를 끄덕인 경험이 있다.
사이드 프로젝트도 참여할 수 있는 기회는 많았지만, 내가 준비되지 않은 것 같다는 이유로 미루고 있었다.
나름 준비가 된 것 같다고 생각해서 시작한 프로젝트였음에도 여러 문제들을 그때그때 배워서 해결한 걸 보면 완벽히 준비된 때는 오지 않는 것 같다.
이런 마인드가 내 성장을 막고 있었다고 생각한다.
도전을 미루는 건 그만두고 일단 해보는 것이 중요한듯..
소감?
어떤 개발자가 되고 싶냐는 물음은 항상 어려웠다.
개발자의 한줄 소개를 보면 '세상을 더 나은 곳으로 만드는', '문제를 해결하는 사람' 이런 문구를 흔히 찾을 수 있고 그런 말들이 멋있기도 했지만 나에게 와닿는 문구는 아니라고 생각했다.
그런데 폴라를 진행하면서 '실존하는 문제를 기술로써 해결하는 직업'이라는 걸 체감하게 되었고, 그런 개발자가 되고 싶어졌다. 오글죄송~
또한 프로젝트를 진행할 수 있는 공간을 제공해주고, 함께할 사람을 만날 수 있게 해준 42에 감사합니다..^^
