[node] common.js로 견고한 node 프로젝트 설계하기

k·2024년 6월 29일
0

node

목록 보기
1/1

서론

"common.js로 견고한 node 프로젝트 설계하기"라는 주제로 github 를 작성하였다.

https://github.com/KNU-K/bulletproof-node-common-js-project-architecture

node진형에서 살아남기위해서, 필수적인 기술이 무엇이 있을까? 라는 생각에서 찾아보던중 santiago라는 개발자가 작성한 "bulletproof architecture" 라는 구조를 알게되었다.

이를 보면서 느낀 첫 감정은 이런식으로도 코딩을 할 수 있구나.. 라는 생각을 많이 느꼈던 것 같다.

단순히 common.js를 통한 개발은 타입이 없기에 안정성이 없고 그렇기 때문에 사람들이 좋게 보지않는 언어이다. 그렇기에 보통은 typescript로 넘어가는 추세이다.

하지만, 나는 common.js 만큼 초기에 시작하기 좋은 js 문법이 또 어디있을까 라는 생각이 들었다. 이를 통해서 백엔드를 공부하는 개발자가 단시간에 여러 시너지를 만들어낼 수 있다고 확신할 수 있다.

하지만 여기에 추가로 좋은 습관을 만들어내면 훨씬 더 추후에 좋은 개발자로써 성장할 수 있다.

이는 아래와 같다.

  • js도 DI를 사용한다. 모듈화로 테스트가 용이하기 때문에, DI를 적용해서 프로젝트를 진행하면 좋다.

  • JS DOC과 같은 형태를 활용하여 타입을 지속적으로 명시하는 습관을 만들어라. 이는 추후 강타입 언어로 넘어가기 위한 준비이라고 생각하면 좋다.

    단순히 js를 타입이 없기 때문에 복잡한 타입의 도피처로 생각하면 안된다는 말이다.

  • e2e 테스트보다는 unit test를 통해서 해당 코드가 테스트에 용이한 코드인지를 항상 생각하며 리팩토링

    unit test를 통해서 green이 뜨는 경우를 만들고, 코드를 유지보수를 하게 되면 코드가 좀 더 빠르게 리팩토링 될 수 있게 도움을 줄 수 있다.

단순히 이정도의 습관만 가지고 개발을 한다면, 분명 좋은 node 개발자가 될 수 있다고 생각한다.

bulletproof 아키텍처에 대해서 알아보고 싶으면, 위의 링크를 타고 문서를 확인하길 바란다. 해당 포스트에서는 node를 선택하는 많은 사람들에게 이는 결코 잘못되지 않았다고 말해주고 싶어서 글을 작성하려고 한다.

node.js의 오해

사람들은 node.js기반 프레임워크가 단순히 Single-Thread 기반이라서 spring과 같은 프레임워크에 비해 많이 부족하다고 말을 많이한다.

이는 잘못된 생각이다. 현 시대에서 Single-Thread를 극복할 수 있는 여러 설계 기법들이 등장했고, 이는 더 이상 큰 단점으로 작용하지 않는다. 대표적인 설계 기법이 MSA 방식이다.

오히려 어떤 일부 기능에서는 spring에 비해서 node.js가 초기 메모리를 작게 차지해서 성능 향상에 도움을 줄 수도 있다.

명확하게는 내부적으로 Batch 작업이 어렵고, 대규모/대용량을 처리하는 것에 적합하지 않아서 그렇지 이외의 작업에는 node.js기반 프레임워크는 상당히 경량화된 좋은 프레임워크라고 할 수 있다.

국내에서 Spring 과 같은 프레임워크가 주력을 이루는 이유는 초기 국내 생태계를 Spring으로 구성하였고, 현재 국내 시니어 개발자들이 가장 많이 분포해있는 것도 한 몫하고 있다고 생각한다.

하지만, 실력과 차별성이 있는 개발자라면 어떠한 언어를 하던지 크게 상관을 없을 것이라고 생각한다.

아키텍처를 중요하게 생각해야하는 이유

나 또한 아키텍처보다는 서비스를 구현하는 것에 급급하던 한 백엔드 개발자였다. express로 프로젝트를 진행하게 되면, nest.js나 spring에 비해서 정해진 부분이 없다보니 사람들마다 개발을 진행하는 방식이 천차만별이다.

하지만, 해당 개발이 시니어 라인으로 올라갈 수록, 테스트를 통한 안정성, 의존성에 대한 문제를 해결하기 위해서 통일화된 구조를 사용하게 된다. 나는 해당 구조를 무조건적으로 익히기보다는 해당 문서를 읽음으로써, 왜 이런 구조를 사용해야하는지에 대한 고민을 했으면 좋겠다.

좋은 아키텍처는 좋은 코드를 만드는 것은 아니다. 내가 생각하는 좋은 아키텍처는 좋은 코드로 가기 위한 좋은 길을 만들어 준다고 생각한다. 그렇기 때문에 해당 부분을 중요하게 생각하고 개발을 하면 좋을 것 같다.

해당 문서화 작업을 하면서 느낀점

부족한게 많은 한 대학생 개발자이지만, 원래는 부족한게 무엇인지 어떻게 성장해야하는지에 대한 생각을 전혀 못했었다. 단순히 문제을 해결할 수 있는 개발자라는 막연한 자신감에 가득차 있었던 것같다.

하지만, 시니어 개발자와 메일을 통해서 연락을 하면서 느낀 것은 단순히 개발을 하는 것이 아닌 어떻게 개발해야하고 왜 이렇게 개발되어야하는지를 알아야한다고 느꼈다.

또한, Santiago의 자료는 5년전의 자료였던터라, 조금 더 수정을 하면 좋은 포인트 들을 살리려고 노력을 했고, 나는 ts가 아닌 js 문법을 통해서 이를 사람들에게 제공하고자 많은 노력을 했다.

그러면서, Open Source 시장에서 다른 사람들이 쓴 코드들도 많이 참조를 했고, 그러다보니 우연치않은 계기로 기여를 할 수 있는 기회도 생겼었다. 그러다보니 나의 답이 100% 정답은 아니더라도, 적어도 확실한 오답에 대해서 알 수 있는 능력이 생겼다.

마무리(feat. 자기 성찰)

나는 신입 개발자이다. 아는 것이 많다 느꼈던 만큼 모르는 것은 훨씬 더 많다고 느낄 수 있었던 기회였던 것 같다. 이 기회를 통해서 나는 우매함의 봉우리에서 떨어져 앞으로 나아갈 힘을 얻었다.

가장 성장해있다고 믿는 그 시점이 어쩌면, 자만으로 가득 차있는 시기일 수도 있다. 그렇기 때문에 항상 자신을 의심하고 그에 따른 근거를 찾으려는 노력을 하면 좋을 것 같다는 생각을 했다.

profile
You must do the things you think you cannot do

0개의 댓글