저번 글 이후 복습 겸 한번 돌아보는 시간을 가졌다.
그리고 이번에는 내가 무엇을 했고, 무얼 해야 하는지 정리해 보겠다.
우선 이 글을 쓰는 이유는 다음과 같다.
1. 2주간의 일정 이후 번아웃
Java/Spring 언어/프레임워크 공부를 할때 상당히 힘들었던거 같다.
적힌 글도 별로 없고, 인터넷에 돌아다니는 글만 잘 읽어도 얻을 수 있는 정보였지만,
그 정보가 정확한 것인지 계속 점검하고, 확인하는데 진이 빠져버렸다.
거기에 누가 알려주는것도 아니고 개인적으로 공부하다 보니
어떻게 공부해야하는지, 어떤것을 알아야 하는지도 계속 고민을 했었다.
뿐만 아니라 목표가 사라진거 같은 느낌도 들어서
나 자신이 개을러지는 느낌도 많이 받았다.(이게 제일 크다.)
사람이란게 어쩔수 없이 일정에 쫒겨야 열심히 일을 하는거 같다.
2. 무엇을 해야하는지 정리
무작정 코드를 써도 프로그램은 만들어질 것이고, 서버는 돌아갈 것이다.
하지만 내가 이번 프로젝트에서 원하는 것은 다음과 같다.
프로그램 계획 , 언어/프레임워크에 대한 이해는 앞에서 알아 보았다.
그리고 방법론/개발프로세스/프레임워크 경험을 앞으로 해나갈 예정이다.
하지만 처음 해보는것이다 보니 주먹구구식으로 하는것 보다는,
어떤걸 써야하고, 어떤것을 해야 하는지 정하는게 좋다고 생각했다.
3. 내가 했던것을 까먹지 않기 위해
그냥 앞의 내용을 읽어보면 되지 않느냐? 라고도 할 수 있지만
내 경험상으로는 무언가를 읽고 직접 정리하고 쓰지 않으면 쉽게 잊혀진다.
특히나 공부할때, 공략집을 쓸때 느끼는 것이지만
자신의 생각을 남에게 보여주기 위해 설명하는 과정에서 상당한 고민이 필요한데,
이때 머리에 더 잘남는 경험을 많이 했었다.
그럼 여기까지 쓰고 본론으로 넘어가자.
Spring/React , TS , PostgreSQL , AWS , Locust를 사용
각각에 대한 사용경험, 선택 이유를 정리하였음.
CI/CD에 대한 설명이 부족한데, 이부분에 대해서는 전혀 듣지 못했다.
들어본건 젠킨스 하나밖에 없는데, 추후 배포를 할때 추가적으로 알아볼 예정.
개발 방법 또한 직접적으로 경험해 본것은 아니나
TDD만큼은 직접 해보고 싶다고 생각하고 있었다.
이전 프로젝트에서 개발을 할때 서버 자체 테스트를 전혀 돌리지 못했다.
그래서 백엔드 서버 담당팀원과 계속해서 코드 충돌이 있었고, 이를 확인하는데 많은 시간을 소비했다.
따라서 이번에는 데이터의 요청/출력값에 따른 정확한 동작이 되는지 테스트를 통해서 확인할 예정이다.
가장 깊게 생각한 부분은
내가 이걸 지루하지 않게 개발할수 있는가? 였다.
사람이 많이 사용해야하는거? 다양한 경험을 할 수 있는거? 취업에 유리한 프레임워크를 사용하는거?
다 좋다. 하지만 개인 프로젝트에서 가장 중요한 것은 끝까지 완성시키고 유지보수를 하는것 이라 생각하고,
개발을 하다 도중에 포기하는 일이 없었으면 했다.
그래서 외부의 API를 받아오고, 그것을 토대로 내 개인경험과 연결하여
실제로 사용하는사람이 편리하게 사용할 수 있는 사이트를 만들고 싶었다.
때마침 주제를 정할때 전기요금이 얼마나 나오나 몰라서 불편한 상황이었고(전기 계량기가 집에 없다...!)
한번 주제를 잡으니 관련된 아이디어도 잘 나왔다.
많은 사람들과 하는 프로젝트라면, 협업을 하고 어려운 개발을 같이 수행해 나간다는 것에서 성취감을 느꼈지만
혼자서 해야 하는 프로젝트상 스트레스가 장난아니게 쌓일 것인데, 어떻게라도 애정을 가질 수 있는 프로젝트를 하기를 원했다.
역시 프로그램을 코딩할때 가장 힘든것은 환경설정이라고 생각한다.
각 버전별로 무엇이 있고, 어떤것을 사용해야 하는지 많이 알아봐야 하는데,
언어/프레임워크를 사용해본 적이 없으니 알아봐도 적을 내용이 없다.
무엇보다도 써본적도 없는 언어/프레임워크의 장단점을 줄줄 읊어도 전혀 신뢰가 가지 않을 것이다.
그래서 배포 단계에 가면 한번더 복습하는 시간을 가질 것인데, 그때 가서 자세하게 알아볼 예정이다.
그리고 지금 백/프론트 연결을 할때 경로가 짤리는 버그(?) 같은것이 있는데, 이를 유의하면서 코딩해야 한다.
이 문제를 해결하려고 하루를 날렸었던 기억이 난다.
이때도 공공 API 사이트에서 사용할 수 있는 API가 뭐가 있었는지 엄청 찾았었다.
결국은 한전/기상청/소비자원 등등의 다양한 경로로 데이터를 얻는 방법을 찾았고, 이를 POSTman으로 확인했다.
단순히 API 종류와 제공하는 데이터의 종류만 정리했었지만, 검색을 계속 하느라 정신적으로 정말 피곤했다...
아직까지 문제가 남아있는 부분이다.
팀 프로젝트를 할때는 Figma를 통해 웹사이트를 직접 디자인하고, 프론트팀/백엔드 팀으로 나눠져 작업했지만,
혼자서 작업을 하는 만큼 앞에서 보여주는 프론트 작업은 좀 줄여야하나? 라는 생각도 했었다.
무엇보다도 그림은 초등학교 저학년때 잠깐 학원다닌것 말고는 그림을 그려본적도 없는 문외한이라..
절망적인 디자인을 할것이라 생각이 든다.
그래서 대략적인 구성은 다음과 같다.
1. 로그인
2. 메인 페이지 - 날씨가 먼저 나옴.
3. 메인 페이지에서 추가적인 버튼을 눌러서 전기요금 평균을 알수있게.
4. 서브 페이지 2개 - 생필품 가격 정보 검색/집 주변 병원 위치 확인
하지만 이것을 퍼블리싱 할때 재대로 할 수 있을지 정말 고민이다.

놀랍게도 저 조잡하기 짝이없는 ERD를 설계하는데 1주일이 걸렸다.
그리고 저 ERD는 100프로 틀렸다고 장담할 수 있다.
왜 이렇게 효율이 나오지 않았나를 생각해 보면
즉 간단하게 요약하자면, 처음보는 분야에 데이터의 양이 너무많아 얼탔다.

본격적인 서버 코딩에 들어가면 ERD를 갈아엎을 예정이다.
이거때문에 번아웃이 왔다.
무려 7월 9일에 시작해서 7월 25일에 끝난 파트이다.
약 16일동안 온갖 영문 레퍼런스/Java, Spring 공식 문서를 뒤지면서 내가 찾는게 정확한것인가 교차검증을 죽어라 했다.
이전에도 설명했듯이, JavaScript를 코딩할때 비동기 처리때문에 2~3일동안 한 문제를 가지고 머리 터지도록 고민한 적도 있었고, 비동기처리 관련 문제가 터질때마다 8시간 이상씩 왜 이 버그가 발생했나 코드 다 검토하고, 찾았던 기억이 있었다. 진짜 핫식스 킹 하루에 2캔씩 마시면서 심장마비 걸리는줄 알았다.(이때는 하루에 14시간씩 프로젝트만 했었는데, 3주하고나니까 몸 컨디션이 그냥 작살났었다.)
이러한 경험때문에 약간의 PTSD가 걸린게 아닌가 싶은데, 웃긴건 전부다 비동기 처리에 대한 정확한 지식이 있었으면 빠르게 디버깅 할 수 있는 문제들이었다는 것이다.
따라서, 더더욱 확실하게 언어/프레임워크를 공부하려고 했었다.
지금봐도 호들갑떠는게 아닐까 싶을정도로 Java 공부를 시작하기 전 내가 왜 이렇게 공부하는가를 구구절절 설명했었고, Java의 구동부터 멀티스레드/OOP/SOLID/Spring 아키텍처의 다양한 특징까지 알고싶은 부분들은 싹다 공부했었다.
배운것은 정말 많았다고 생각한다.
왜 JDK/JRE/JVM, Spring이 WAS 안에서 돌아가는 어플리케이션이라는것, Servlet Stack과 Reactive Stack의 차이점, Bean이란 무엇인가 등등 관심있게 알아보지 않았다면 절대 알수 없는 것들을 알 수 있게 되었다.
당장 코딩을 한다면 프로그램의 코드는 많아질 것이다. 하지만 이러한 기본적인 것들조차 모른다면 개이적으로 납득이 되지 않았기 때문이다. 나에게 있어서 개발자란 문제를 해결하는 사람이고, 문제를 해결하기 위해 원인을 깊게 탐구하는 사람이기 때문이다.
결국 내가 쓰는 도구들을 이해하지 못하면 프레임워크에 잡아먹힐것이라 생각한다.
위의 내용들은 전부 '추상적인'내용들이었다.
사이트 컨샙, 각종 도구들의 이해 등등을 공부했다고 할 수 있다.
1달동안 실컷 공부했으니, 이제 코딩에 필요한 정보를 모으고, 실제 사이트를 만들 차례이다.
Spring 프레임 워크가 어디에서 시작을 하고, 무엇을 참고하고, 어떻게 흘러가는지에 대해 전반적인 이해를 하고 넘어가려고 한다. Nest.JS를 사용할때 Dependency를 집어넣는거에서 상당히 해맸었다.
Spring도 이와 같은 DI가 필요로 하는 프레임워크이다 보니 앞으로 어덯게 코드를 작성하면 좋은지
다른 레퍼런스를 참고하며 알아볼 예정이다.
ERD/Git/코딩할때 필요한 문법/기법 등등 프로젝트 진행에 필요한 요소들을 점검할 것이다.
앞서 말했다시피 ERD는 뭔가 맘에도 들지 않고 잘못되었다는 느낌을 받고 있다.
다음은 Git인데, 이전 프로젝트에서도 그냥 Git 이 명령어 쓰면되구나~ 하고 이해도 없이 자꾸 쓰다보니
새로운 환경에서 이걸 어떻게 사용해야 되는지 감도 잡히지 않았다.
이 기회에 Git 사용법도 재대로 알아볼 생각이다.
코딩 문법/기법의 경우에는 전체적인 스타일을 보는 것이다.
혼자서 코드를 짜는것 보다는 레퍼런스를 참고하는것이 좋다고 생각한다.
이전 프로잭트 초기에 고봉밥 코드 때문에 팀원들의 피드백이 좀 있었다.
이번 프로젝트에서 가장 중요하게 생각하는 부분이다.
무작정 코드를 짰을때 버그가 발생하는 경우가 많았었는데, 이러한 버그 발생을 줄이고,
내가 짠 코드를 모듈별로 나눠서 확인/검증할수 있는 수단이 필요했다.
주력으로 다룰 예정이다.
젠킨스 하나 말고는 전혀 모른다.
배포 자동화 툴이라고 하는데, 아마 팀원이 배포 자동화를 돌렸어요~ 라고 했던 그것인거 같다.
AWS에서 특강을 해줬었다. 하지만 도저히 뭐가 뭔지 잘 이해가 되지 않아서 손도 못댔었는데
이번에는 재대로 배포를 하며 서버를 돌려볼 생각이다.
이후 도메인 구입까지 하러면 돈이 좀 들어갈것이라 생각한다.

이전의 프로젝트 할때 이게 참 재밌어 보였다.
서버 관리 프로그램을 켜서, 가상의 사용자를 집어넣고 CPU 과부하 테스트를 하는것이다.
이게 백준 문제풀이 할때 메모리/시간이 터지는지 보는거 같아서 참 재밌어 보였다.
뿐만 아니라 나의 목표는 사람들이 쓸 수 있는 사이트를 만드는 것이기 때문에, 부하 테스트를 하며 몇명이 사용하는가에 대해 알아보는 것도 재밌어 보였다.
게임사들이 Ver 1.0.0 이러면서 관리하는게 있는데, 이게 참 재밌어 보인다.
그래서 기능을 추가하면서 버전을 업데이트 하면 게임을 만든다는 느낌도 낼 수 있을것 같다.
위는 개인적인 생각이고, 프로젝트의 버전을 관리하는것 또한 많은 큰 이점이 있다고 한다.
히스토리 추적, 백업관리 같은것에서 도움이 된다고 하지만 아직은 먼 얘기니 차차 알아가도록 하자.
큰 고비를 넘겼다고 생각한다.
처음 하는 개인프로젝트다 보니 어떤것을 하고 어떤건 줄여야 하는가 눈대중이 잘 안되서 규모가 많이 커진거 같지만
이러한 것도 경험으로 남아 다음 프로젝트때 잘 사용될 것이다.
가장 중요한 것은 꾸준히, 생각하면서 코딩하는것이라 생각하고, 조급해서는 안된다.
물론 개을러지는것은 안되지만, 급하게 진행하다 나중에 돌이킬 수 없는 실수를 하고싶지는 않다.