React, Next.js, typescript, springboot, JPA, MYSQL 로 한달간 프로젝트 진행 한 뒤 쓰는 회고

React, Next.js, typescript, springboot, JPA, MYSQL 로 한달간 프로젝트 진행 한 뒤 쓰는 회고

1. 어떻게 시작했는지
2. 진행과정
3. 무엇을 배웠는가
4. 어떻게 달라질 것인가

1. 어떻게 시작했는지

팀원이 제시한 아이디어로 “우리가 써보자 + 유용하겠다. “ 라는 마음으로 출발점을 끊었다.42seoul c++ 과제를 빠르게 진행한뒤 바로 프로젝트 진행을했다. 책과 구글에 다 있었고 하다보면 실력도 늘것이고 혼자하는것도 아닌 팀프로젝트니까 무조건 할 수 있다고 생각하며 자신만만하게 시작했다.

2. 진행과정 (1달)

프로젝트 이름 정하기 , 꼭 있어야하는 핵심기술, 피그마로 화면 정의 , 요구사항 정의서, 사용될 기술 정리 등을 하며 개발전 기획을 진행하였다.이 과정에서는 팀원과 직접적으로 화면이나 기능에 대해 얘기하지 않고 막연하게 “00페이지는 00기술이면 되겠지?” 하며 합의를 본후 진행했었는데, 이과정에서 오류가 있었다. 00기술에 대한 기본정의가 서로 다르기 때문에 사소한 화면 정의 하나에도 차이가 생겼다. 그 차이에 대해서 서로 이야기하고 생각한 차이점에 대해 맞춰가는 과정이 은근 시간소모가 있었다. 또한 사용기술에 대해서도 워낙 다양한 기술이 있다보니 무엇을 사용하는게 좋을지에 대한 논의가 많았다.
 
DB설계에서는 걸리는 부분이 있었지만 구현하면서 조절하면 되겠지 하고 넘어갔었는데 좋지 않은 선택이었다. 구현단계에서 헤매는 중 select를 해오려고 할때면 정규화가 잘 되어있지 않은 DB가 거슬렸고 결국엔 없는시간안에서 그걸 뜯어고치는 시간이 들어갔다. 전체적으로 진행이 더딘중에 뜯어고치며 앞선 과정을 다시하는 시간은 사기를 낮추게 만들었고 팀원과 트러블이 생기게 만들었다. 틀린걸 아니까 정규화하고 진행하자 Vs 틀렸지만 일단 진행하자 , 나는 앞선 주장을 펼치는 입장이었다.시간이 없지만 DB 설계 단계에서 일단 넘기자 하고 넘긴것이 오늘 지금의 화를 만들었다. 따라서 틀린걸 안다면 지금 아는 최대로 DB정규화를 한뒤넘어가야 뒤탈이 없다는 주장이었다. 뒤의 주장을 하는 팀원도 어느정도 이해는 됐다. 시간이 없는데 DB를 바꾸면 이제야 리액트 들어갔지만 다시 백엔드 쪽을 만지니까 바꿔야할게 많다는 것이었다. 그래도 틀린걸 알면 바로 잡고 가야하고 언제든 바로잡아야한다면 지금이 최선일수도 있다는 설득을 통해 바로잡게되었다.
 
구현할때 목표는 “일단하고 , 모르면 공부하자” 였지만 이건 정말 생각보다 어려운 일이라는걸 배웠다. 공부를 한다음에 만들었을때는 목차를 알고있어서 난제를 만났을때 아 거기 보면 되는데! 하고 찾아갔지만 이번에는 달랐다말그대로 맨땅에 헤딩이었다. 시작부터 기술 키워드를 모르니 내가 하고자 하는 기능을 검색한다 ex 버튼 여러개 만들기, 여러개 클릭하기 , 컴포넌트 간 정보 교환 등등. 이렇게 검색했을때의 단점은 낮은 확률로 키워드에 걸리다보니 원하는 결과를 보기까지의 시간이 이미 많이 걸린다. 그렇게 검색해본뒤 복붙을 하면 되거나 안되거나 한다. 될때는 왜 되는지 모르지만 구현 할게 정말많으니까 다음에 하자 하고 넘기게 되고, 안될때는 더 답이 없이 모른다. 에러하나보면 그거하나 잡는데 2시간은 걸렸었다. 하지만 최소한의 기능을 하나 구현할때 초보자 로써 정말 수많은 에러를 만났기 때문에 기간대비 기능구현 갯수가 터무니 없이적었고 투자대비 효율을 보며 자존감은 하락했다. 절대적인 시간투자가 부족했으며, 시간대비 효율도 나빴다.
 
하루는 꼭 구현하고싶은 기능(리액트: 컴포넌트 부모클릭시 api호출해서 데이터 받아온뒤 자식화면에 딱한번 렌더링해서 보여주기)이 있어서 밤을 새어봤지만 데이터 받아오기까지만 됐다. 화면에 보여주기가 돼야할 때에는 오류도 없는데 1)한번 클릭해야 데이터 가져오거나 2) 아무 변화도 없거나 였다. 새벽에 너무 허망해서 거울보며 스스로를 다독이기도 했다.

3. 무엇을 배웠는가

• 공부를 어느정도 한다는 것 에대해 멘토님이 하신말씀이 절박하게 와닿았고 책을 보며 순서대로 따라가고있는데 정말 재밌다. 버전이 다른것들 오류 잡아가며 배운것 정리해가며 공부하는 재미를 알게되었다.
• 서버나 api 개념이 조금더 명확해졌다. 프론트와 백엔드 서버를 만들어 api로 호출하며 만들다 보니 도움이 됐다.
• 단순히 공부를 하는게 아니라 프로젝트를 만들기 위해 부딪힌 문제들이 많았다. 신선한 충격을 안게 되었다.
• 바른생활에 집착하기도 했지만 어느정도의 성과가 있어야 스스로 만족한다는걸 깨달았다.
• 책을통해 공부를 하고 나니 “일단 하는 프로젝트” 에서는 3일정도 걸린 기술구현이 20분 정도면 해결됐고, 그때 헤맸던 부분에 대해 ‘아 이거구나’ 하고 알게 되었다.
• 에러메세지를 대충읽고 구글링으로 넘어갔지만 추후 조급한 마음을 버리고 다시 할때보니 에러에 키워드가 있었다. 에러를 읽는 마음에 대해 배웠다.
• 구현에 급급한 나머지 복붙을 하기도 했는데 나중에 오류를 만났을때 이해를 못하고 썼으니 어디서부터 바로잡아야 할지도 몰랐다. 앞으로 하는 공부에 무조건적인 복붙은 없어지게 되었다.

4. 어떻게 달라질 것인가

1. 나중으로 미루지 말자.
   1. 일단 하자는 마음으로 하다보면 ‘이거하고 좀있따가 수정하자’ 가 되기 마련이었다. 좀있다는 오지 않았다 계속 지금이거 해결하고 좀있다가 보자. 좀있다보자 하다가 프로젝트가 끝났다.
   2. 나중에 해야지 하고 넘기면 그 일들이 너무 많이 쌓여서 나를 짓누른다. 할일을 쌓아두지 말자.
2. 정확하게 얘기하자.
   1. 이거 이렇게 하면 될까? ‘아마도 될걸?’ 이라고 대답했었는데 멘토님이 모르는건 모른다고 말하는게 좋다고 말해주셨다. 맞다. 왜 되는지도 모르면서 팀원이 새로운 경우의 수를 물어본다고 ‘맞아 그거 될거야’ 라고 말할 수 있을리 만무하다.
   2. UX/UI 구현에 있어서도 ‘이건 원래 있는 기능이야’ 같이 근거없는 주장을 펼치지 말고 , 찾아본 결과 이러이러해서 여기에 이 위치에 이 기능이 필요해. 라고 주장하자.
3. 회의 시간은 금이다.
   1. 가뜩이나 부족한 시간속에서 제대로 준비하지 않고 모이면 그날 하루를 다써버리곤했다. 논의할 주제에대해 명확히 한뒤 자료를 구해서 모이고, 합의점이 없다면 조금 미룬뒤 다시 회의 하는 방식으로 하자.
4. 공부하고, 구현하며 공부하자
   1. 일단하고, 모르면 공부하자 보다는 공부한뒤 구현하며 만난 문제점을 공부하는 방식이 지금의 내게는 효율적이다. 그 이유는 일단하자가 통하려면 최소한 키워드를 알거나 흐름을 아는 사람이어야 할텐데 나는 두가지 다 해당되지 않았다. 따라서 키워드도 모르고 흐름도 몰라서 허우적 거리기만 했던거 같다.공부를 통해 키워드나 흐름 목차를 만들고 진행하며 만난 문제들을 내 목차안에서 끄집어내는 식으로 공부해야겠다.
5. 에러 만났을때 에러메세지를 잘 읽어보는 습관
   1. 에러메세지 나오면 냅다 긁어서 구글링했지만 멘토님이 조언해주신대로 해야겠다.
      1. 에러메세지 분석
      2. 나온 키워드들을 공식문서에서 본다.
      3. 구글링해본다.
6. 왜? 가 중요하다.
   1. 복붙해서 될때도 왜 되는거지? 좋다! 하고 넘어가고 안될땐 왜 안되는 거니? 구글링해서 복붙했다. 트러블 슈팅을 한다고 했지만 연속으로 에러를 다여섯번 만날때는 정리하기보단 해결만 하고 넘어갔다. 구현에 집착했다.
   2. 될때, 이런 과정으로 되는구나 하고 이해하도록 하자.
7. 클론코딩으로 기초를 다잡자.
   1. 처음부터 아이디어를 구현하기에는 기본 토대가 없었다. 클론코딩을 통해 토대를 만든뒤 가공하는 방향으로 가자.
   2. 또한 주단위 스프린트 할때 이번주 금요일에 여기까지 구현하자 가 목표였지만 그 목표는 현실성이 없었다. 이유는 그 기술을 구현할때 필요한 배경지식이 전혀없기에 어려운지 쉬운지도 모르기 때문이다. 클론코딩을 하다보면 적어도 감은 생길것이다.
8. 절대적인 시간부족
   1. 자나깨나 코딩에 대해 어떻게 해결하면 좋을지 생각해야 될까말까한 수준에서 너무 여유부렸다.
   2. 프로젝트에 시간을 쏟느라 알고리즘이나 42과제를 뒷전에 뒀다. 시간 조절 능력을 키워야한다.
   3. 천재가 아니니 천재들 1시간 효율만큼 나오게 나는 두세시간 투자하자.
9. 코드리뷰 부재
   1. 서로 구현에만 급급하니 충돌만 해결하며 머지하고 푸시했다. 서로 어떻게 했는지 왜 됐는지 이해도가 없었다.

 
 

💡 개선점들을 적고나니 다시 하면 더 잘할거 같은 같은실수를 하지 않을거같은 자신감이 생겼다.