[코드 스테이츠 / Epilogue] "Final-Project 회고 - 교훈"

  이번에는 프로젝트를 통해서 얻어낸 것들을 쓰고자 한다. 쓰려고 마음은 많이 먹었는데, 새해 되면서 조금은 쉬고 싶다는 생각에 미루게 되었지만, 이제 다시 월요일 시작하는 날인 만큼 공부 자세를 다시 갖추고자 한다.

---

[ 오늘의 TODO ]

1. Vue.js 추가 학습
2. 기술 면접 대비

---

[ 프로젝트하며 얻은 교훈 ]

1. 에러가 나의 선생님

   에러는 하나하나가 소중하다. 코드 스테이츠 모든 기간 통틀어서 가장 공부를 많이 한 때가 언제인지를 생각해보면 프로젝트할 때라고 단언할 수 있다. Section 1, 2, 3 을 거치면서 남에게 가르침을 받았을 때보다 프로젝트가 더 공부가 많이 된 이유는 바로 내가 직접 코드를 작성하고 그에 따라 발생하는 에러들 때문이다. 에러가 발생하면서 내가 계속해서 실수하고 있는 것이 무엇인지를 깨닫게 된다.

 

  예를 들어 보자면, 이번 프로젝트에서 가장 에러를 많이 낸 카테고리가 바로 리액트 Hooks 에 대한 잘못된 이해였다. Hooks 라고 해봤자 useState, useEffect, useRef 이 세 개뿐인데, 이 세 개에 대한 이해를 제대로 하고 있지 않다 보니 발생하는 에러들이 많았다. useState 의 경우, 물론 리덕스를 사용하면서 에러를 많이 접하진 않았지만 저번 블로깅에서도 언급했듯이 socket.io 를 사용하면서 상태에 변화를 줄 때 setState( 인자 => 인자에 대한 변화 로직 ) 로 인자 값을 명확히 줘야지만이 원하는 대로 결과가 나오는 경우가 몇 번 있었다. useEffect, useRef 에서 에러 나는 건 대부분 다 cleanup 함수로 관계를 끊지 않아서 발생하는 문제였다. useEffect 가 리액트 라이프 사이클에서 차지하고 있는 부분, componentDidMount - componentDidUpdate - componentWillUnmount 이 세 부분에 대한 이해를 제대로 하고 있지 않다 보니 작성해야 할 로직을 제대로 작성하지 않아서, 좀 더 구체적으로 말한다면 unmount 해줄 때 관계를 끊어줘야 하는데 끊지를 않아서 발생하는 문제들이 종종 있었다. 이런 에러들을 자주 마주하다 보니 자연스럽게 그 Hooks 에 대한 올바른 이해가 이뤄지고, 리액트 라이프 사이클에 대해서 더욱 깊이 있게 이해할 수 있는 시간이 되었다.

 

  에러가 나를 더 공부하게 만든다. 기존에 코드 스테이츠에서 공부할 때는 남이 만들어 놓은 로직 안에서 내가 조금 로직을 구현하는 것이었는데 이제는 내가 무에서 유를 만들어 내며 그 과정에서 제대로 된 학습을 하지 않았기에 발생하는 문제들을 에러로 마주하고 수정할 수 있어서 더 깊이 있게 공부하고 더욱 성장할 수 있는 기회가 된 것 같다.

 

앞으로 에러를 마주할 때는 무서워하지 말고 지금 내가 더 공부하고 성장할 수 있는 기회라고 받아들이며 기록해야겠다. 에러들을 기록하고 다시 한 번 보니 내가 이런 문제들을 마주했었구나 상기하면서 다시 공부가 되는 느낌이 들었다. 그리고 에러를 작성하면서도 내가 무엇이 문제였는지를 추상적으로 알고 있는 게 아니라 구체화할 수 있어서 좋았던 것 같다. 

 

2. 남이 말하는 걸 정확하게 알아 듣는 스킬의 중요성

  진짜 이 스킬 너무 중요하다. 처음 SR 때 이 스킬은 굉장히 중요했고, 실제 코드를 작성하는 중에도 이 스킬은 계속 필요했다. 내가 팀장의 위치에 있었기에 더 그랬을 수도 있다. 하지만, 전반적으로 남이 말하는 내용을 제대로 캐치하지 못하면 기능 구현이 엉망으로 된다.

 

  이걸 처절하게 느꼈을 때가 SR 기획 단계에서다. SR 기획 때, 서로가 이 페이지에서는 어떤 기능을 구현하자, 어떤 UI 로 디자인을 하자 얘기를 충분히 많이 했다(약 4일 정도) 모두가 합의한 후에 각 페이지의 requirements 까지 정리하고 기능을 구현했는데, 기능 구현하고 보니까 다른 얘기들이 오고 간다. 원래 이런 기능을 구현하려고 했던 거였나요? 이런 기능 말고 다른 기능을 구현해보는 게 더 좋을 것 같은데. 이런 얘기가 너무 오고 가다 보니까 한 팀원 분께서 "SR 기획 때 기능 구현하기로 모두가 합의한 거에서는 더 건들지 말자" 라고 말할 정도였다. 분명히 모두가 합의를 했음에도 불구하고 다르게 이해한 사람들이 있었다. 다행히도 각 기능마다 다르게 이해한 사람이 1명 정도였고, 그게 그 기능을 구현하는 사람이 아니라서 프로젝트 전체 진행에는 크게 영향을 끼치지 않았다. 

 

  팀장으로 있으면서 가장 많이 한 일은 그 사람들의 말을 정리해서 되물어 보는 것이었다. A 라는 사람이 X 를 얘기했는데 B 라는 사람이 Y 로 알아듣는 경우가 많았다. 그래서 내가 중간에서 먼저 B 분에게, Y 가 아니냐고 물어보신 거 맞으시죠? 라고 한 다음, A 분에게 A 분은 X 를 말씀하신 거죠? 라며 중재하는 역할을 가장 많이 했던 것 같고, 그리고 아예 다른 팀원들이 못 알아듣는 경우도 있어서 X 에 대해서 내가 더 자세하게 들어가 말하고 그게 A 분께서 말씀하신 내용이 맞는지 되물어보는 경우가 많았다. 물론, 이렇게 말하더라도 나도 중간에는 내가 잘못 이해한 것들이 있었고, 그 부분은 팀원 분들께서 잘 정정해주셨다.

 

  진짜, 협업할 때는 다른 사람이 무슨 말을 하고 있는지 정확하게 알아듣는 게 너무 중요하다는 걸 깨달았다. 만약에, 조금이라도 우리가 말이 엇나갔다면 우리가 원하는 기능들 하나 두 개 정도는 빼야 했을 수도 있었다. 그래도 지금 원만하게 잘 이뤄진 거 같아서 다행이다. 

 

3. 나는 여전히 부족하다는 것, 그래서 더 공부해야한다는 것.

   "공부 좀 더 해야겠다" 라는 생각을 프로젝트 내내 했다. 코드 스테이츠를 통해서 많은 개념들을 학습했지만 그것을 온전히 모두 사용할 수 있다고 당당하게 말하기는 힘들 것 같다. 프로젝트를 진행하면서 사용하는 스택들은 이제 어느 정도 학습이 됐지만, 그럼에도 React 를 사용한다는 것이 곧 JavaScript 언어를 잘 사용한다는 것을 의미하진 않는다. Express 를 다룰 줄 알게 됐다고 해서 Node.js 환경을 자유자재로 구사할 수 있다는 얘기도 아니고, Sequelize 를 사용할 줄 알게 됐다고 데이터 관리를 효율적으로 할 수 있게 된 것은 아니다. 그리고, React 를 사용할 수 있다고 해서 정말 깔끔하고 효율적으로 코드를 잘 작성할 수 있다는 것도 아니다. Express 를 사용한다고 해서 Express 에 내장된 옵션들과 npm 패키지들을 자유자재로 활용해 더욱 효율적인 코드를 작성할 수 있다는 것을 의미하는 것도 아니다. 

 

  내가 이번 프로젝트를 진행하면서 좀 힘들다고 생각했던 부분은 바로 옆에서 코드 리뷰를 해주는 사수, 선배가 없었다는 점이다. 내가 코드르 작성하고 기능은 구현하고 있으나 이 코드가 정말 효율적인 코드인지, 다른 더 경험이 많은 선배 분들이 본다면 내 코드에서 지적받아야 할 점은 무엇인지를 코칭받고 싶은데 그럴 수 없었던 것이 안타까웠다. 어쨌든, 중요한 것은 내가 아직은 부족하다는 것이다. 기능은 구현할 줄 알지만 그 모든 기능 구현이 완벽하다고는 할 수 없다. 조금이라도 더 효율적인 코드를 작성하는 것, 완벽하게 에러가 날 상황들을 모두 잡아내는 것, 그런 것들을 해내지 못하고 있다. 

 

  내가 생각하는 개발자로서의 성장은 두 가지다.

1. 새로운 기술과 스택을 쌓아 지식의 반경을 넓히는 것
2. 기존에 알고 있던 것들을 개선해 나가는 것

  앞으로도 더욱 공부해서 이 두 가지 의미의 성장을 잘 이뤄나갈 수 있도록 노력해야겠다.