joopark 회고록 - innovationacademy-kr/slabs-munetic GitHub Wiki

기술 관련

42 과정을 진행하며 얻은 서버 관련 지식이 아주 큰 도움이 되었습니다. (정확히는 nginx의 리버스 프록시 사용과 전체 서버가 어떤 식으로 구동되는지에 대해서입니다.) 그리고 docker-compose에 대해서도 다뤄 본 경험이 있었기 때문에 이 분야 관련으로는 별 어려움 없이 진행했던 것 같았습니다.

Node 기반의 서버도 과거에 개인 프로젝트로 HTTP API 서버를 만들어 본 경험이 있어 단순 기능 구현 자체는 어렵지 않았지만 서버 내부의 아키텍쳐를 파악하고 설계하는 것 (특히 비즈니스 레이어와 데이터 접근 레이어 간 데이터 흐름)이 어렵다고 느꼈습니다.

DB는 요구사항이 변경되고 기능 미구현 사항에 따라 DB에 컬럼을 추가하거나 삭제했어야 했는데 이 부분에서 테이블의 정규화와 역정규화에 대해서 처음으로 고민해보았던 것 같습니다. 특정 테이블에 컬럼이 많을 경우 중복되는 데이터가 존재해 이를 정규화하여 테이블을 쪼개야 할지, 외래 키를 사용할 때 데이터 무결성 문제가 발생할 수 있는데 이런 경우 역정규화를 해야 할지에 대해 고민을 많이 했던 것 같습니다.

ORM은 sequelize를 사용했는데 ORM은 사용할 때엔 편하지만 사용하려면 해당 ORM에 대해서 깊이 공부해야 함을 느꼈습니다. ORM에서 데이터베이스를 어떻게 접근할 때에 대해 쿼리문이 어떻게 생성되는지, 이에 대해 효율성 문제 등은 깊이 생각하지 못했던 것 같습니다.

프론트엔드는 react 기반으로 개발했습니다. react를 처음 학습할 때 리액트 공식 홈페이지 (https://ko.reactjs.org) 의 문서와 자습서가 아주 큰 도움이 되었습니다. 평소에 프론트엔드의 개발의 난해함과 모듈화의 어려움 때문에 프론트앤드 쪽이 싫었지만 react는 화면 구성요소들을 컴포넌트라는 캡슐화된 자바스크립트 함수(또는 클래스)로 다룰 수 있게 해줘 프론트앤드 개발에 재미를 느꼇던 것 같았습니다.

프론트앤드는 SPA 방식의 어플리케이션이지만 react-router-dom 을 사용하여 브라우저에서 URI의 경로에 따라 다른 페이지를 보여주게 하는 방식으로 동작됩니다. 이러한 방식으로 개발하는 것을 해당 프로젝트를 진행하여 처음 알게 되었습니다. 제가 평소에 생각한 SPA의 단점(URI가 동일해 항상 같은 페이지로 초기에 접근하게 됨.)을 이런 방식으로 해결할 수도 있다는 것이 인상깊었습니다. 그리고 저처럼 UI 구현에 어려움을 느끼는 사람에게 mui 라이브러리는 한줄기 빛과도 같았습니다.

react도 난이도가 상당한 라이브러리라는 점을 리액트 훅을 사용해 보며 느끼게 되었습니다. 잘못 사용하면 페이지 성능이 급격히 하락함을 느껴보기도 하였습니다.

CI/CD를 경험해 본 것도 매우 값진 경험이었습니다. 비록 CI는 테스트 단위로 개발을 진행하지 않았기 때문에 깊이 경험하진 못했지만 소스코드 통합 시에 즉시 서버에 배포가 되는 경험과 그것을 다루는 DevOps 분야의 경험은 저에게 아주 좋은 경험이었습니다.

기술 외 관련

동료들과 github를 통해 이슈 별로 브랜치를 나누어 공통 브랜치에 merge하는 방식으로 개발하는 것은 처음이었습니다. 코드 상 우려되는 사항도 사전에 체크가 가능하며 동료들과 코드에 대해 깊이 있는 이야기를 나눌 수 있는 좋은 경험이었습니다.

동료들과 동료 학습을 하는 것도 좋은 경험이었습니다. 제가 알고 있는 것을 동료들에게 다시 설명할 때 제가 정말로 알고 있는 지식인지, 겉햟기만 하고 있는 지식이 아닌지 생각이 들어 다시 공부하는 계기가 되었고 다른 분들께 설명할 때에는 제가 알고 있는 내용을 정제해서 알려주는 것이기 때문에 개발자들간 소통을 하는 데에 중요한 밑거름이 된다고 느꼈습니다.

멘토님께 기술적인 문의를 별로 드리지 못한 것이 아쉬웠습니다. 초반에 프로젝트를 맡을 때에는 프로젝트에 대해 알고 있는 내용이 없었고 좀 지나서는 단순 기능 구현에 매몰되어 기술적인 조언을 별로 얻지 못한 것이 너무 아쉬웠습니다.