2020.09.23~2020.12.22
3개월간의 인턴은 생각의 전환점과 실력으로 느꼈을 때, part1과 part2로 볼 수 있다.
Part1. CSS 친구랑 친해져요.
9월.
3학년 2학기 수업을 듣고 있던 도중 우연히 인턴 합격 소식이 들려왔다.
급하게 휴학을 하고 다음날 바로 출근을 했다.
버스로 편도 2시간 20분 거리였던 회사였지만 3일동안 출퇴근을 하다보니 '내 시간'없이 하루를 보내고 있다는 걸 느꼈다. 새벽 5시에 일어나 6시 30분에 출발했고, 6시에 퇴근하면 8시 30분에 도착했던 3일간의 삶 속에는 오로지 일과 잠 뿐이었다.
그래서, 회사 근처로 거주지를 옮겼다. 나에게는 좋은 휴식공간보다 일과 내 시간이 더 필요했다는 판단이었다.
회사에서 제공해준 맥북으로 slack, notion등으로 소통하는걸 익혀가고 있었고, 프로젝트의 코드를 보면서 시간을 보냈다.
더불어 css로 싸우면서 배워갔다. 토이 프로젝트의 경우, '이 정도면 되겠지'가 있었지만, 회사에서는, 완벽해야만 했다.
landing page
퍼블리싱 된 랜딩 페이지를 React로 옮기는 수정하는 것 이었다.
제플린을 보고 퍼블리싱 된 페이지에서 다르게 된 부분을 찾고, 후에 작업을 했다.
간단한 작업도 SRS를 작성하면서 SRS에 대해서 익숙해졌다. CTO가 원하는 SRS는 2가지였다.
- 개발하는 사람이 알아볼 수 있어 개발할때 막히지 않을 것
- 어떤 사람이 봐도 이해할 수 있도록 작성할 것
그러나 나에게는 처음 작성해보니, 뎁스가 깊어져서 두어번 정도 수정한 후에야 1번 조건을 만족할 수 있었다.
첫번째 미션: 동영상 자체를 클릭하면 닫히는게 불편해요. 수정해주세요.
10월.
추석 연휴를 보내고 다른 일을 주시기까지 시간이 남았다.
그래서, React책을 보면서 redux와 saga에 대한 이론 공부를 했다.
어드민 페이지를 만드는 프로젝트에 들어가면서 CSS로 고군분투 하면서 보냈다.
인턴도 워크숍을 가나요?
10월 27일부터 30일까지 제주도로 워크숍을 갔다.
대표님의 생각과 이사님의 노하우를 알 수 있었던 뜻깊은 시간이었다.
사전에 서비스에 대해서 불편한 점을 작성해보라고 하셨다. 다른 팀원들의 경우, 팀원들이 맡은 업무의 연장선에서 생각해보면서 '이것이 불편할 것이다'에 초점을 맞추었다. 그러나 아직 서비스의 개발에 참여하지 않았던 나는, '고객'의 관점에서 깊이 생각해봤던 과제였다.
워크숍에서 팀원들과 토의하면서, 내가 제안했던 것이 가장 먼저 수정되어야 할 부분이라고 결론이 났다. 바로 개발에 들어갈 수 있는 부분 중 하나였기 때문이었다.
이 부분에서 가장 먼저 든 생각은 "내가 생각하지 않은 서비스에 대해서도 깊히 생각 할 수 있다" 였다. 토이 프로젝트에서도 내가 낸 아이디어에 살을 붙여서 생각했던 것이었는데, 회사의 서비스에서도 깊이 생각해 보면서 다른 사람의 아이디어에도 살을 붙이면서 엣지있게 생각할 수 있다는 자신감이 붙었다.
11월.
gitkraken을 알게되었다. 그동안 CLI(Command-line interface)만 사용했었는데, 가시적으로 볼 수 있는 GUI(graphical user interface)도 사용해보았다. 덕분에 CLI를 사용하면서도 feature 브랜치를 이용할 때 정확히 생각해 볼 수 있었다.
Part2. React의 Redux와 Saga를 사용하라구요?
이 말을 듣자마자 인턴의 Part2의 서막이 시작되었다.
10월달 부터 리덕스를 공부해봤지만 실제로 접해보는 건 어려웠다.
React미션: action을 dispatch해주세요.
React미션: Saga를 사용해주세요.
12월.
Javascript미션: linkedlist를 작성해보세요.
노션 : 링크는 링크
게시글 : 링크는 링크
GitHub : 링크는 링크
서비스 미션: SRS를 작성해주세요.
이번 미션은 열흘 정도의 기간동안 주어졌다.
그동안은 일정이 정해지지 않거나 내가 정했던 미션들이었다. 이번에는 마감이 정해져 있어서 색다르게 다가왔다.
모두가 이번 미션을 끝나지 못한채 열흘이 지날거라고 했다.
수정 개발의 도입부라구? 안녕 난 해피한 워커홀릭!
SRS를 작성하면서 내가 알아볼 수 있도록 만든 SRS-1을 작성하고 나니, CTO께서 향후 개발 수정에 들어갈 부분이라 모두가 볼 수 있도록 작성하라고 하셨다.
- 어떤 사람이 봐도 이해할 수 있도록 작성할 것
드디어 다른 팀원들도 내가 만든 SRS를 보게 되는 것이다.
어찌보면 회사에 직접적으로 기여하는 일을 맡게되었다는 생각이 들었다. 그래서 행복한 워커홀릭에 빠져서 재미있게 했었다.
백엔드 개발자분이 남기신 기존의 문서들을 참고하고 주말, 새벽과 밤 시간에 상관없이 전문서적까지 찾아보면서 만들었다. 나는 프론트엔드 개발자 인턴으로 있어서 백엔드 개발자와 직접적인 이야기를 할 기회가 없을 것 같았는데, 이번 미션 덕분에 API에 대한 많은 이야기를 할 수 있었다.
화면에 어떻게 그려나가야 할지 정리해보면서 서비스를 고객 관점에서 완벽하게 이해할 수 있었다. 그러다보니 백엔드 개발자분이 생각하지도 못한 케이스를 제안해보고, 직접 테스트도 해보면서 기존시스템에서 수정되어야 하는 API를 토의해보았다.
개발자가 아닌 팀원들(고객들과 직접 소통하는 팀원들과 디자이너 및 기획을 담당하는 팀원)과 토의를 하면서 분석가의 역량을 키울 수 있었다.
난해한 명명이 있으면 다른 명명으로 추천해주세요.
수정되는 시스템에서 백엔드 개발자분이 명명법에 대한 문서를 남기시길 원하셨다.
백에서 API Response를 보내면 프론트에서 정재 후 쓰고 있었는데, 이때 백과 프론트에서 사용하는 명명법을 정리해보면서 Django와 React에서의 명명법의 차이가 있어서 서로 다르게 변수명을 사용하고 있다는 걸 알게되었다.
다음과 같은 기준으로 변수명을 정해보면서, 그 전에는 깊게 변수명에 대해 생각해 본적이 없었다는걸 깨달았다.
1. 이 변수가 무슨역할을 하는지 한눈에 알아볼 수 있을지
2. 내가 왜 이 변수명을 추천했는지
Notion으로 수정할 변수 명들을 생각해보면서, 다른 사람에게 내 아이디어를 문서로 어필해 볼 수 있는 기회였다.
