안녕하세요 국민대학교 하계현장실습 프로그램으로 이노베이션 아카데미에서 8주간 프로젝트를 진행하게 된 박종민입니다. 참 느낀게 많았던 이번 이노베이션 아카데미에서의 현장실습입니다. 그동안 생각해보지 않았던 부분에 대해서 생각을 많이 하게되고 띵~하는 깨달음이 오는 경험이 많았습니다. 한번 그러한 느낌들에 대해서 적어보겠습니다.
1주차 – 첫출근 ~
첫 출근한날 간단한 규칙설명 듣고 맥북 지급받고 환경설정 이것저것 하고 우리가 할 프로젝트는 이노베이션 아카데미 본과정 학생들을 위한 멘토링시스템을 만들어보는 것이라고 얘기를 하고 각자 자리에 앉았습니다. 그런데 그다음 단계가 없었던 것이 기억이 납니다.
모두 ‘멘토링시스템을 만들것이다’에 대해서는 알고 있었지만 다음 행동은 아무도 하지 않았습니다. 저 또한 우리가 이노베이션아카데미의 시스템에 대해서도 잘 모르고 이 프로젝트는 이노베이션 아카데미에서 쓰는 것이기 때문에 멘토님이 좀 더 상세하게 이부분에 대해서는 이렇게 진행하고 다음 어떤 행동을 해라라고 지시를 하실 줄 알고 자리에서 지루하게 기다리던 기억이납니다.
그렇게 월요일 오후와 화요일…까지 구글드라이브를 파고 협업 툴로는 슬랙과 트렐로를 사용하기로 정하고 초대 정도만 하고 별다른 프로젝트 진행이 되지는 않고 있었습니다. 그러다 수요일 퇴근하기 전에 멘토님이 먼저 칼을 뽑으셨고, 저희를 불러모아서 42서울 라피신 과정의 학생들의 얘기를 해주셨습니다.
라피신 과정 학생들(이하 피시너)은 첫주차에 들어오면 아무도 뭘 해야하는지 알려주지도 않고 뭘 질문해도 대답해주지도 않고 혼자 문제를 해결하게 한다고합니다. 그런 과정에서 특출난 누군가는 무언가를 뚝딱뚝딱 하고 있고 공부를 하고있습니다. 아무것도 하고 있지 않은 피시너는 두가지 선택지가 있습니다. 아무것도 하지 않거나 다른 피시너에게 물어보는 것입니다. 후자를 선택한 피시너들은 그 순간 다음 단계로 넘어갈 수 있습니다. 그 사람을 따라해보면서 무언가를 배울 수 있을 것입니다. 하지만 아무것도 하지 않고 남들이 뭘하고있어도 질문하지 않는 피시너들은 첫주차 시험에서 엄청난 좌절감을 느낀다고 합니다. 심지어 시험 시작 10분뒤 아무것도 하지 않고 할 수 없는 피시너들은 일어나서 나가라고 한다고합니다..(실제로 저도 감독하면서 봤습니다.) 첫주차 시험 역시 들어가서 화면만 덩그러니 주고 아무것도 알려주지 않기 때문입니다. 이런 때 터미널을 켜서 ls만 눌러봐도 다음 단계로 진행할 실마리를 얻는다고 합니다.
한 이쯤까지 들었는데 한대 얻어맞는 기분이 들었습니다. 월요일 화요일 수요일 별다른 행동을 하지 않은 내 모습이완전 아무행동도 하지않는 피시너들 같이 느껴졌습니다. 멘토님은 이걸 누가 시키기 전에는 하지 않는 학생관성이라고 표현하셨고 나름 저에게 각인되는 단어가 되었습니다. 다른 인턴분들도 느낌이왔는지 의기투합 할 수 있었고 바로 다음날 7월2일부터 제대로 저희의 프로젝트는 시작됬습니다.
먼저 각자가 생각하는 멘토링 시스템을 구상하고 어떤 멘토링 시스템을 만들 것인지를 논의하자.
서비스 타겟은 누구인지, 멘토링은 어떻게 제공할 것인지 등등 멘토링 시스템에 관한 것들을 구상하고 논의하는 것을 남은 1주차 내내 했습니다.
첫주차 월화수 시간을 알차게 사용하지 못한만큼 1주차는 시간이부족했고 더욱이 금요일에는 피시너들 시험감독이 있는 관계로 다같이 같이 회의하지 못해서 서비스에 대한 구상을 구체화 시키는건 2주차까지 넘어갔습니다.
2주차 – 우린 분명 같은 주제에 대해서 같은 얘기를 했었는데? 왜 다르게 받아 들인거지?
– 각자 상정하고 있는 전제조건이 다 다르다.
구체적으로 서비스에 대해서 토의를 하면서 아주 신기하고 재밌는 경험을 했습니다. “사람들과 분명 같은 내용을 얘기를 했다.” “하지만 생각하고 있는 내용은 다르다.” “그래서 결국 같은 내용을 얘기한 것이 아니다.” 예를 들어보면 ‘A와 B가 멘토링을 한다.’ , ‘멘토링과정에 질문을 주고받는다.’ 라는 행동에대해서 저는 A와 B가 1:1의 관계는 없이 질문만 주고받는 정도의 관계라고 생각을 했습니다다. 그래서 특정 멘토에게 질문을 하면 그 관계가 끝난다고 생각을 했는데 어떤 사람들은 A와 B는 1:1의 관계가 있다고 생각을 하고 있는 것입니다. 학생과 지도교수처럼 관계가 있어서 일정 시간동안 그 둘만 멘토링을 주고받는다고 생각을 하는 것이죠. 아예 생각이 다릅니다. 이런식으로 토의를 하는동안 각자의 생각이 다름을 몸소 체득하는 것이 굉장히 재밌었고 신기하고 흥미로웠습니다(시간이 갈수록 힘들었다..)
서로의 생각이 다름을 격하게(?) 인정하면서 나온 결정사항들
-이렇게 나온 결정사항들을 가지고 요구사항 분석을 하자
토의를 거쳐서 나온 멘토링시스템의 use-case들을 가지고 시퀀스를 짜고 어떤 시퀀스에 어떤 데이터가 나올지 시나리오를 자세하게 명세하기로 했습니다. 이 과정에서 우리는 화이트보드앞에 모여서 다같이 시퀀스 다이어그램을 그렸는데 이게 맞는 방법인지에 대해서는 의문점이 생겼습니다. 왜냐면 혼자서 하면 금방 끝낼 수 있는 작업을 같이 진행하다보니 또다시 생각하는 점이 다른게 곳곳에서 나와서 곳곳에서 막히는 것입니다. 사실 저는 이 때가 가장 힘들었습니다.. 하지만 미리 이런부분을 다맞추고 나면 실제 개발이 들어가면 막힘없이 진행될것이라는 멘토님의 말씀을 믿고 진행했습니다.
아래는 위 작업의 결과물 입니다.
3주차 – 개발 들어가기 쉽지않네…
사실 인턴으로 왔는데 꽤 긴 시간동안 개발을 하지않고 토의와 문서작업만 하고있는게 굉장히 마음이 불안하고 이래도 되나 싶었습니다. 3주차 쯤 되면 개발에 들어갈 수 있을지 알았지만 큰 오산이었습니다 ㅋㅋ.
– 일단 팀빌딩!
저는 사실 백엔드를 맡고 싶었습니다. 왜냐하면 그동안 해왔던 토이프로젝트에서는 거의 프론트 위주로 해왔기 때문에 백엔드 DB연동이나 API를 만들고 싶었는데 결국 인원분배의 문제로 다시 프론트를 맡게 됐습니다..
– 어떤 언어와 어떤 프레임워크를 사용할 것인가?
멘토링 서비스의 어떤 점 때문에 어떤 언어를 사용하면 좋을 것인가? 어떤 프레임워크가 유리할 것인가? 왜 이 언어와 이 프레임워크를 썼는가? 에 대해서 조사를 했습니다.
누군가가 와서 너 왜 리액트 썼어? 하면 당당하게 대답할 수 있게..
– 우리 서비스의 와이어프레임!
와이어프레임 툴을 사용하는데의 비용문제 등 여러 핑계로 인해 손으로 그리고 올렸더니 너무 허접해 보여서 나름 괜찮은 무료툴인 오븐을 이용해서 로그인하고 개인정보 수정하는 단계까지 와이어프레임을 만들었습니다. (근데 오븐 생각보다 진짜 구렸다…)
아래는 저희가 만든 와이어프레임 링크입니다. 들어가서 동작 플로우를 확인해보실 수 있습니다!
https://ovenapp.io/view/xUJzYGV5rmFzgAHN5pBE2Vw1A2M1sfHz
4주차 – 코딩컨벤션….?
– 코딩컨벤션
부끄럽지만 코딩컨벤션에 대해선 그동안 들어 봤지만 한번도 코딩컨벤션을 정의해서 팀원들과 맞춰서 프로젝트를 진행해본적이 없었습니다. 그래서 처음엔 이게뭐지..? 했지만 본인들이 어떤 스타일로 코딩해왔는지 논의하고 javascript, html , css 로 나눠서 공통의 코딩컨벤션을 정의했습니다.
그리고 위에서 정의한 언어의 코딩컨벤션 외에 react에서 주로 쓰는 삼항연산자나 arrow function 같은 경우 특별히 예외로 정의해야할 것 같아서 따로 react코딩컨벤션도 만들었습니다. 후에 느낀 거지만 확실히 세세한 것 까지 코딩컨벤션을 정의해 놓으니까 개발 작업들어가고 깃에서 머지하는 과정에서도 쓸데없는 오류도 많이 사라지고 예상외의 부분에서 작업의 능률이 올랐던 것 같습니다.
코딩컨벤션은 보기 좋으라고 하는 것도 있지만 작업의 능률을 올릴 수 있는 방법으로도 사용된다.
라는 느낌으로 이호준 멘토님이 말씀하셨던게 확 와 닿았다.
– 리액트 hook
저는 앞서 리액트랑 장고로 동아리 운영페이지를 자체 제작해본 경험이 있었습니다. 그때는 컴포넌트를 class로 만들었었는데 이번에는 hook을 이용하기로 했기 때문에 hook에서의 리액트 LIFE CYCLE에 대해서 공부를 해야될 필요성을 느꼈습니다. 그래서 5주차 집중 개발 들어가기 전에 미리 공부를 싹 하고 리액트에서 제공하는 use-로 시작하는 hook에서 쓰이는 api의 쓰임새들에 대해서 미리 공부를 하는 시간을 가졌습니다.
5주차 6주차 7주차 – 개발시작!
고려사항
시작하자마자 여러가지 고려사항에 직면했습다.
- 프로젝트 빌드는 어떤 방식으로? (CRA? || bable 등 라이브러리 직접설정?)
- 리액트 라우터는 무엇을 쓸까?
- 폴더구조는 어떻게 잡을까?
- 상태관리 라이브러리는 어떤것을 사용할까?
프로젝트 빌드
프로젝트 빌드는 그냥 리액트에서 제공하는 기본 CRA를 사용했습니다. 아직 내 입맛에 맞는 라이브러리가 뭔지에 대해서 취향이 잡히지도 않았고 기본 CRA에서 불편함을 느낀적이 없었기 때문에 일단 CRA로 했는데 한번 CRA빌드 과정들과 다른 라이브러리들에 대해 공부를 해야될 필요성도 많이 느꼈습니다. 뭐가 좋은지도 모르고 기본 제공 설정값을 쓰는게 좀 찝찝했습니다.
리액트 라우터
써드파티 라우팅 라이브러리도 이것저것 많지만 거의 공식 라우터처럼 쓰이는 react-router-dom을 썼습니다.ㅋㅋㅋ
폴더구조
CRA에서 만들어주는 파일들을 제외하고 왜 이렇게 폴더를 짰는지 설명해보겠습니다.
– api
서버와 통신하는 api들을 명세해놓는 파일들이 위치하는 폴더입니다. 프로젝트가 좀더 크면 내부적으로 파일을 쓰이는 기능따라 더 분리를 했겠지만 프로젝트 규모상 한개의 api.js 파일로 모든 api를 관리했습니다.
– components
서비스가 커질수록 컴포넌트는 잘게잘게 계속 생길텐데 그러한 컴포넌트들을 관리하는 폴더입니다.
내부적으로 기능별로 폴더를 한번 더 나눠주고 관리했습니다.
– context
리액트 상태관리를 어떻게 할까에 대해서도 많은 고민이 있었습니다. 몇개 추려본 방법으론 Redux, mobX, context API 등 여러 후보가 나왔습니다. 결론부터 얘기하자면
context API 를 사용하기로 결정했습니다.
왜냐하면 Redux나 mobX는 상태관리 이외에도 매력적인 많은 기능을 제공하는 라이브러리입니다. 반대로 얘기하면 그만큼 프로젝트가 무거워질 수 있다는 얘기입니다.
그리고 Redux 나 mobX는 러닝커브가 높습니다. 그래서 상태관리만 고려하던 저희에게는 알맞지 않다고 생각하여 가볍고 상태관리에 있어서 우수한 성능을 내는 context API로 최종 선택했습니다.
– providers
context API와 같이 프로바이더로 모든 컴포넌트에 상태를 뿌려줄 수 있었습니다. 관련 파일을 관리하는 폴더입니다.
– pages
모든 컴포넌트들을 담아주는 가장 상위컴포넌트 즉, url을 갖고 라우팅되는 페이지들은 pages에 따로 관리했습니다. component 폴더와 따로 관리했을 때의 이점은 특정지점을 찾아 내려갈 때 계층적으로 찾아 내려갈 수 있어서 훨씬 수월했습니다.
디자인 1도 신경 안쓰고 이벤트 핸들링만 전부 마쳐놓은 우리의 멘토링 서비스화면들
이렇게 개발은 마무리되었습니다.
8주차 – 마무리 문서작업
현재 8주차.. 이렇게하고 모든 작업을 따로 정식 문서화 하고 느낀점등을 블로그에 글도 작성하면서 저희의 일정은 마무리가 되어가고 있습니다. 8주동안 정말 알차게 멘토님들한테 배워가는 것도 많고 프로젝트도 진행하는데 있어서 좀 더 체계적으로 진행하는 경험을 가질 수 있어서 정말 좋습니다.
그동안 정말 감사했습니다!