들어가며...

이걸 제가... 할 수 있을까요...?

돌아온 ptn 회고 시간이다.
10월달에 나는 어떤 일들을 겪었을까?

P

저번달에 한다고 했던것들

• 갠플
• 네트워크
• 리액트&TS
• Next.js
• 함수형프로그래밍

그중에 진짜로 했던 것들

- 함수형 프로그래밍

함수형 프로그래밍을 선택강의로 들을 기회가 생겨서 들어보게 되었다.
강의를 전부 수강한 것은 아니지만, 강사님에 대해 흥미가 생겨서 유튜브로 강연 영상도 찾아보았었다.
영상들을 시청하면서, 여태까지 개발을 하면서 생각하지 못했던 부분들에 대해 고민해보게 되었다.

처음에 이터레이터와 이터러블에 관한 강의를 들을때는 뭔가 대학교 시절로 돌아가서 이게 무슨 말일까... 하고 들었다. 그리고 나중에 그 개념들이 코드를 작성할 때 사용되는 부분이 인상깊게 다가왔다. 메모리를 훨씬 효율적으로 관리할 수 있겠구나... 라고 생각이 들었다.

하지만 실전에서 사용하려면 얼마나 내공이 필요할까 라는 생각이 들정도로 어려웠던 것 같다.

ES6+ 비동기 프로그래밍과 실전 에러 핸들링
에러를 터트리는게 중요하다는 생각을 해본적이 없는데, 이 동영상을 보고 생각이 바뀌었다.

에러가 어디에서 발생했는지, 명확하게 표시하는것이 에러를 숨기는 것보다 훨씬 나은 방법이라고 동영상에서는 말하고 있다.
나중에 에러가 어디서 발생했는지 표시조차 나지 않으면 아무도 모른체 큰 사고로 번질 수가 있기 때문이다.

전반적으로 유인동 강사님이 말씀하시는 내용들은 아직 내 수준에서는 적용하기는 어려운 부분들이 많지만 시야를 넓히는데 큰 도움이 되었다.

그리고 문제의 책 쏙쏙 들어오는 함수형 코딩(줄여서 쏙들함코라고 부르는중)

그저 goat...

내 개발적 성장은 이 책을 읽은 후와 읽기 전으로 나눌 수 있을 정도로 나에게 의미가 크다.

코드를 바라보는 관점, 액션과 계산의 분리, 일급추상 등등
뭔가 이 책을 읽으면서 지난 4개월 동안 멘토님들이나 동료들이 얘기했던 내용들이 촤르르 이해가 갔다.

예를들면 코드를 작성하는 원칙중에 응집도는 높게, 결합도는 낮게라는 격언이 있는데 처음에는 도대체가 무슨 말일까 생각이 들었었다.
책을 읽다보면 '함수를 최대한 잘게 나누고 각각의 기능들을 관심사에 맞게 분리해 놓는다면 유지보수가 잘 되겠구나!' 라는 생각이 들게 되는데 이때 위의 격언이 머리속을 츠팟! 하고 지나갔다.

예를 하나밖에 들지 않았지만, 이런 식으로 자바스크립트를 개발언어로 삼는 개발자라면 얻어가는 것이 많은 책이라고 생각을 한다.
코드를 작성할 때 이유와 근거를 들 수 있게 되었다고 생각이 들고(물론 책만 읽는다고 저절로 생기는 것은 아닐테지만) 앞으로도 꾸준히 곁에두고 읽고 싶은 책이다.

T

그리고 위의 저번달에 한다고 해본다고 했던 목록들이 줄줄이 나열되어있는데, 대부분은 달성되지 못했다. 그 이유는...

최종 팀프로젝트

최종플젝이 시작이 되었기 때문이다.

처음에는 2차팀 플젝을 생각하고, 그래도 짬을 내면 개인적으로 공부할 시간이 생기지 않을까? 라고 생각을 했었다.

그리고 그것은 나의 큰 착각이었다.

저번 팀 프로젝트보다 훨씬 바빠진 이유를 적어보자면 아래와 같다.

백엔드와의 협업

백엔드 분들과의 협업을 진행하게 되었다. 지금까지는 미리 api가 존재했고, 거기에 맞춰서 개발을 하는 연습을 했다. 하지만 이제는 처음부터 api를 작성해야했고, 그 과정에서 프론트엔드의 의견이 중요해졌다.

api를 가져다 쓸 뿐이지 고민해본적이 없었던 나로써는 팀원들과 얘기를 많이 해보는 것 말고는 뾰족한 수가 없었다. 이러이런한게 필요할 것 같은데, 아직 ui도 완성이 안되었는데,,, 와 같이 신경써야 할 부분들이 엄청나게 많아졌다.

그리고 프론트엔드에서 뇌빼놓고 api를 만들어 달라고 요청을 했다가 나중에 만약 수정을 해야하는 부분이 생긴다면? 프론트엔드와 달리 백엔드에서는 거의 전체를 갈아엎어야 하는 부분이 생길 수도 있다는 말에 긴장을 엄청나게 했었다.

많아진 커버 범위

위의 내용과 살짝 겹치는 부분인데, 결국 개발을 하려면 api를 고민해야하고, api를 고민하기 위해서는 ui가 나와야하고, ui가 나오기 위해서는 디자인을 해야하고, 디자인을 하기 위해서는 기획을 해야하고,,,

결론은 처음부터 오롯이 백엔드와 프론트엔드가 손잡고 아무것도 없는 상태에서 시작을 해야했기 때문에 눈코뜰새 없이 바빴었다.

우리 팀은 팀원 한명한명의 의견에 귀 기울이는 문화가 있는데, 그 나머지 사람들의 집중력을 낭비시키지 않기 위해서 조사를 열심히 해보고, 조사가 끝나면 또 열심히 의견을 어필하고,,, 하는 과정이 정말 쉽지많은 않았다.

새로운 기술적 도전

그리고 아마 이게 가장 크게 바빠진 원인이지 않을까 싶다.
저번팀에서는 써보지도 못한 기술을 크게 3개정도 쓰게 되었다.
처음에는 호기롭게 할 수 있다! 라고 생각을 하고 덤벼들었는데 막상 개발을 진행하면서 공부를 하려다 보니 하나를 제대로 쓰기도 버거웠다.

멘토님이 피드백 주신 내용중에 기술 하나를 쓰더라도 깊이 공부하고 써보는게 중요하다 라는게 있었다.
뭔가 이 말에 공감을 프론트엔드 전체가 했는지 아닌지 잘 모르겠지만, 적어도 나는 공감을 많이 했다.

여러 기술을 쓰는것 보다, 한가지를 깊이 공부한 경험을 쌓는게, 자신 스스로에게도 좋은 경험이 될 것 같고, 외부에서 보기에도 좋은 인상을 남길 수 있는 방법이라는 생각을 현재 하고 있다.

아직 도입되지 않은 기술 스택에 대해서는 팀원들에게 얘기를 해보고 더 쉽고 간편한 기술로 바꾸자고 해보고, 뭔가 진짜 도전해보고 싶은 한가지를 깊게 파보자고 얘기를 해볼 것 같다.

N

결국에는 물고 늘어져야한다.

솔직하게 이번 팀플을 진행하면서 내가 팀에 기여를 하고있는 부분이 많지 않다고 생각한다.

디자인을 할 때는 피그마를 잘 다룰줄 몰라 버벅였고, 개발을 진행하면서는 다른 팀원은 코드를 뚝딱뚝딱 만들어 내는 코드를 버벅이며 작성했다.

결국 10월 동안 팀프로젝트를 진행하면서 돌이켜 보았을 때 하드스킬이 많이 부족하다고 생각이 들었다.

나는 소프트 스킬이 뛰어나고, 인격적으로 훌륭한 사람이라도, 팀에 어떤 기술적인 기여를 할 수 없는 사람으로 남겨지는 것을 원하지는 않는다.

내가 개발자를 그만 두기 전까지는.

훌륭한 하드스킬이 뒷받침되는 소프트 스킬이 의미가 있다고 생각이 드는 요즘이고, 그렇게 된 이상 남은 프로젝트 기간동안 짜낼 수 있을 만큼 남은 힘을 짜내보고 싶다.

그리고 그런 하드스킬을 갖추기 위해서는 문제를 끝까지 물고 늘어지는 자세가 필요하다고 생각한다.

결국에 문제를 해결해 나가는 과정에서 이 기술 저 기술도 써보고 코드도 만지작 거리는 것 아니겠나.

남은 한달동안 열심히 불태워 봐야겠다.

화이팅!