스프린트를 한 후 느낀점, 배운점을 자유롭게 서술해보자
1차 스프린트에는 백엔드 개발 위주로 하였다. 에자일 방법론을 이용해서 개발하는것 자체로도 경험적인 측면에서 매우 좋다고 생각해서 해당 방법론으로 개발을 진행하고 있으나, 1인 개발에서 스프린트를 할때는 단위를 스토리단위로 짜면 안될것같다는 생각이 제일 먼저 들었다. 나만 그런지는 모르겠는데 개인 프로젝트를 진행할때는 디자인 → 백엔드작업 → 프론트작업 순으로 진행하는데 스토리는 도메인별로 디자인, 백엔드, 프론트 3분야가 하나로 뭉쳐져있기때문에 적합하지 않았다.그래서 스프린트용 스토리를 새로 만들까 했지만 그건 그거대로 보기 힘들것같아서 일단은 이대로 진행하기로 했다. 이번 스프린트에서는 Nest JS에 관해서 많이 알아갔던거 같다. 기술적인 부분에서는 Nest JS의 공식문서가 매우 잘되어있어 도움이 많이 되었고 DB개념이나 서버의 전반적인 도메인지식들은 주변친구들에게 많이 물어보면서 공부했다. 항상 서버공부를 해야지 해야지 하다가 결국 안하고 3학년이 되었는데 안한것이 조금은 후회되었던 스프린트였다 ㅜㅜ 대부분의 서버 API개발은 마쳤으나 AWS 관련 API를 개발하는 도중 내 실수로 깃허브에 AWS ACCESS KEY를 올려버려서 해커들에게 내 AWS 계정이 해킹당했다 ㅜㅜ 비록 5만원정도 밖에 과금되지 않았지만 다시 환불받기 위해서 AWS 고객센터에 계속 상담해야하니 매우 귀찮아졌다(3주 걸려서 환불받음). 이번 사건으로 다시금 보안의 중요성을 깨닭았던것같다. 다음번에는 절대 실수하지 말아야지.. 끝 🙌
2차 스프린트에는 프론트엔드 전반적인 베이스 코드들을 짰다. 처음에는 CI/CD 및 테스팅을 생각하지 않고 개발하려 했으나 생각해보니 도메인에 배포도 해야하고 이것저것 넣다보니까 욕심도 나서 E2E 테스팅 및 Jenkins CI/CD도 넣어보기로 했다. E2E 테스팅은 Cypress를 이용해서 유저 시나리오?대로 테스팅 해보기로 했고 CI/CD는 AWS EC2와 Github Actions, Jenkins를 이용하여 설계했다. 백엔드 API 및 AWS작업은 끝나서 AWS에 배포하는 단계만 남았고 프론트는 전반적인 베이스 컴포넌트 작업 및 기초 설계가 끝났다. 이번 프로젝트에서는 Custom Hook을 사용하는 느낌이나 기존의 내 코드스타일, 폴더구조를 조금씩 바꿔보고 있다. 이때까지 나는 비슷비슷한 폴더구조, 코드스타일을 고수했는데 동계 인턴쉽이후로 조금 생각이 바꼈다. 구글링을 해서 나오는 코드들이나 유명한 개발자 분들의 코드를 접하다보니 클래스형을 쓰는경우, hook에서 비즈니스로직을 많이 처리하지만 한 파일에 다 몰아 넣지않고 분산하는 경우 등등 이유를 알것같기도하고 모를것같기도한 점들이 있었다. 비슷한 폴더구조와 코드스타일에서 더이상 발전할 수 없을것같다고 느낀 나는 이런 부분들을 고치며 더 발전하고 싶어서 이유를 알아가면서 코드스타일을 바꿔보고있다.
2차 스프린트에서는 몸상태가 계속 안좋았다. 아파서 집도 몇번 갔다가 왔고 허리디스크 초기증상도 생겨서 몸이 안좋아진게 느껴진다 ㅜㅜ 더 안좋아지기전에 열심히 노력해서 치료해야겠다 👊
3차 스프린트에는 클라이언트의 전반적인 디자인 퍼블리싱을 완료하였고, 인프라 구축에 많이 힘썼다. Jenkins를 사용하여 CD(Continuous Delivery)를 구현하였는데 AWS 프리티어의 EC2 성능으로는 Jenkins를 정상적으로 받쳐주지 못하는지 초반에는 점유율 100%가 넘어가면서 EC2가 뻗기 일수였는데 Linux의 Swap Memory를 이용해서 하드용량을 메모리로 쓰는 대책을 써봤는데 이 방법을 적용하고 나니 느리긴하나 굴러가긴 한다! 정말 다행이다.
그리고 Nginx를 사용해서 배포하려고 했는데 Nginx를 사용하는 대중적인 이유(리버스/포워드 프록시)가 나에게는 해당되지 않고 굳이 Nginx를 사용해서 배포하지 않아도 다른 수단이 있어서 사용해보지 않았던 Docker를 사용해서 배포했다. Docker에 올리는 커맨드(dockerfile)파일을 CD할때마다 계속 실행해서 기존것을 삭제하고 새로 도커 이미지를 말아서 컨테이너에 올리면 배포가 완료 되는 흐름이다. 이렇게해서 최종적으로 CI/CD를 구축했다.
클라이언트쪽도 말하자면 퍼블리싱은 다 끝낸상태이고, 남은거는 스켈레톤 UI, 에러페이지, 모바일 반응형정도가 남았는데 요부분은 API연동하면서 추가해야 깔끔하게 나올것같다. 사실 모바일 반응형은 처음부터 기획해서 모바일 화면부터 만들고 점차 PC화면으로 늘려나가는 방식이 개발하기 편하다고 생각하는데 그러지 못해서 아쉽다. 그리고 정말 절망적인 문제가 하나있다. 노션페이지를 띄우려고 했으나 기술적한계로 못하게 생겼다... 현재 문제점은 2가지, 노션 PageID랑 라우팅 문제이다.
먼저 1번 문제점을 말하자면, 노션에서 URL로 export하는 기능이 있는데 기본적으로는 url뒤에 pageid를 붙여주어서 정규식으로 내가 가져올 수 있는데 URL에 도메인을 먹여버리면 PageID가 숨어버려서 가져오지 못한다. 그래서 이력서를 등록할 때 문제가 생기고,
문제 2번은 라우팅 문제다. 처음 PageID를 받고 유저ID와 물려서 DB에 저장해놓아도 해당 PageID기반으로 가져온 노션페이지에서 이어지는 다른 노션페이지(ex) 프로젝트페이지)로 넘어가게 되면 PageID가 바뀌어서 자칫잘못하면 url을 수정해서 사용자와 이력서가 다르게 보일 수있는 문제가 있다. 이는 UX적으로 매우 안좋다고 생각한다.
하루동안 솔루션을 계속 강구해보면서 해결책을 찾아봤지만 도저히 나오지 않아 노션 라이브러리로 보여주는것은 포기하고 노션을 PDF로 export해서 해당 파일을 받게 기획을 수정하였다. 너무 아쉽다… 개발하면서 계속 솔루션을 강구해봐야겠다. 이런게 기술부채인가 싶기도 하다.
3차 스프린트에는 고민을 많이했다. 반응형, 코드퀄리티, CI/CD오류 등등 골머리를 앓았던것이 많았다. 끝 😎
4차 스프린트에서는 프로젝트 배포 및 최종적으로 완성을 하였다. 각 페이지 API연동이나 구현은 별로 어려웠던게 없었는데 CI/CD나 테스팅, 각종 버그때문에 문제가 좀 생겼었다.
먼저 가장 큰 이슈는 AWS EC2에 클라이언트를 배포할려고 SSH접속 및 배포를 했는데 정상적으로 배포하고 나서 다시 접속하려고하니 내 터미널 과 AWS 웹에서 접속이 막혀버렸다. Jenkins 설정을 하다가 권한을 잘못준것인지 아니면 pem키 문제인지는 잘 모르겠으나 해당 이슈로 2번정도를 EC2를 지웠다가 다시 만들어서 배포하였다. 친구가 도와줘서 그런지 EC2문제는 잘 해결한거 같다.