개발 기초 개념 다시보기(1) (Node.js, 정적/동적 언어, 프레임워크와 라이브러리, REST API)

1. Node.js 란 무엇인가

Node.js 는 언어인가 프레임워크인가? 아니면 뭐지?

당신은 자바스크립트 개발자인가?
아니면 노드 개발자인가?

이런 질문이 보이면 많이들 헷갈리고는 한다.

왜냐하면 가끔 백엔드 기술 스택들을 확인해보면 이렇게 나와있기도 하기 때문인데,

Javascript - Node.js
Java - Spring
Python - Django

 

다른 언어들은 뒤가 프레임워크니 Node.js도 프레임워크가 아닐까 생각하고는 한다.

처음 접하는 사람들이 참 헷갈릴만도 하다.

결론적으로 말하자면,
Node.js는 실행 플랫폼이다. 

다른 언어에는 이런 개념이 많이 없을 것이다.
(비슷한 개념을 굳이 따지자면 Java에서는 JVM이 있다.)

 

왜냐하면 애초부터 언어의 태생이 다르기 때문이다.

C, Java 등의 언어들은 애초부터 프로그래밍을 위한 용도로 만들어진 언어지만,
Javascript는 브라우저에서만 사용되던 언어가 프로그래밍을 위한 용도로 바뀐 것이다.

원래 Javascript은 특별한 목적이 있는 스크립트 언어였다.
오직 웹 브라우저 위에서만 명령을 수행하고 로직을 처리할 수 있는 언어였다.

그러다보니 각 웹 브라우저 자체에 언어를 해석하고 실행하는 엔진들이 있을 수 밖에 없었다.

그러나 이것을 프로그래밍의 세계로 내보낸 것이 바로 구글이다.
구글의 크롬 V8 엔진에 libuv라는 라이브러리가 합쳐서 Node.js라는 것이 탄생했다.

 

Node.js를 통해서 javascript를 다른 코딩 언어들처럼 하나의 구조를 가진 프로그램을 만들 수 있게 됐다.
폴더도 가지고, 아키텍쳐도 설계할 수 있고 그런 것들이 다 Node.js 덕에 가능해졌다.

이후로 Node.js의 인기가 계속해서 커지면서
빠른 시간 동안 각종 라이브러리/프레임워크들이 쏟아져 나왔다.

우리가 들어본 기술들
Express.js
Vue.js
React.js
이외에도 다양한 기술들이 BE, FE 상관 없이 Node.js 와 함께 개발에 사용된다.

 

하지만 ,

 

누군가가 Node.js 개발자냐고 물어보면, 보통은 백엔드 개발자를 물어보는 것이다.
백엔드면 그냥 그렇다고 대답하면 된다.

하지만 정확하게 짚고 넘어가고 싶은 것을 좋아하는 사람이라면,

'Node.js는 실행 플랫폼이기 때문에 그 범위가 넓습니다.
BE든 FE든 Node.js는 둘 다 사용하기 때문에,
정확하게 어떤 업무를 하는지를 물어봐주세요.'

 

라고 대답하면 될 듯 하다.

 

---

Node.js의 특징

솔직히 Node에 대부분의 언어와 크게 다른 특징은 없다.
다른 언어에 있는 기능들도 대부분 있고, 이 언어에만 특별하게 있는 그런 것도 엄청 있지는 않다.

사실 Node.js 자체는 별로 이야기할 게 없는 것이,

Javascript에 대한 특징이 곧 Node.js 의 특징이기 때문이다.

 

그래서 다음의 내용도 다 Javascript와 관련된 내용들이다.

- 자유로운 문법

코딩을 함에 있어서 자유를 경험할 수가 있다. 

문법이 자유분방하고 다양한 형식을 지원한다.
함수 표현 방식도 여러 가지인 데다가,
클래스나 객체를 만드는 것도 다른 언어와 다르게 간결하다.

- 동적 언어

Javascript가 동적 언어라는 것 때문에, 기존 정적 타입의 언어를 배웠던 사람들에겐 조금 난관이 될 수 있다.
정말이지 Node.js를 쓰다보면 '무슨 이런 언어가 다 있어'라는 말이 한두 번 나오는게 아니다.

 

동적 언어의 장점은 분명히 있다. 굉장히 자유롭고 빠르게 코딩할 수 있다는 것이 장점이다.

 

하지만,

'아니 이게 된다고?' 라는 생각이 자주 들어서 그런지 
불안감이 자주 엄습해오는데, 참 그 스트레스가 적지 않다.

분명히 이전에 쓰던 언어에서는 분명히 에러가 나야 하는데, 여기에선 넘어가고 그런 것도 많다.

 

그래서 그 결과 Typescript가 나왔는데,
이런 걸 보면 자바스크립트 진영이 크다는 것이 느껴진다.

사용하는 사람들이 하도 많다보니 문제가 빠르게 해결되어 가는 느낌이 있다.

그래서 이젠 Typescript를 도입하면 정적 타입을 사용하던 사람들도 사용하기에 좋은 언어라고 생각한다. 

- 비동기

비동기 처리가 언어 수준에서 지원이 되기 때문에, 

다른 옛날 언어에 비해서 관련된 개념을 익히는 것이 쉽다.

이전에는 비동기처리에 항상 존재하는 Callback 지옥이라는 문제가 있었지만, 

이미 그 문제도 Async/Await 로 해결된지 오래다.
Node.js를 사용하다보면 다른 언어에 비해서 비동기처리가 빠르게 익숙해질 것이다. 

 

---

2. 정적, 동적 타입 언어의 차이

두 언어의 구분은 타입이 언제 정해지느냐의 문제이다.

 

정적 언어는 타입을 코딩할 때 반드시 써서 결정해 줘야하지만,

동적 언어는 타입에 상관없이 코딩을 하면, 이후에 실행하면서 변수를 확인하여 타입을 결정한다.

프로그래밍 초보자의 입장에서는 동적 타입을 보고 굉장히 좋은 기술이라고 느낄 가능성이 크다.
(나도 그랬다.)

파이썬에서는 아래처럼 하면 변수 선언이 된다.

num = 1

그러나 자바에서는 

int num = 1;

이런식으로 num의 타입을 붙여야 한다.

난 처음에 이렇게 생각했다.
'아니 알아서 1이 숫자인 걸 알아서 변수에 대입해주는데 완전 좋은 기술 아닌가?
역시 동적 언어는 정적 언어의 진화 버전이구만. 파이썬 좋은데?'

실제로 코딩테스트 공부할 땐 정말 좋다.
타이핑을 조금이라도 아끼고 실제 로직을 짜는데 집중할 수 있어서 참 좋은 언어다.

하지만 실제로 실무에 들어가면 좀 달라진다.

백엔드에서 가장 많이 하는 것이 데이터를 다루는 것인데,
데이터를 다루다보면 변수를 여러번 수정하고, 읽고, 쓰곤 한다.

난 분명히 num 변수에 숫자만 담으려고 했는데,

num = 1
num = "hello"
num = [1, 2, 3]

위처럼 어떤 것을 담더라도 파이썬은 문제가 발생하지 않는다.

그러다가 나중에 실제로 데이터를 사용할 때 문제가 발생하면 그때서야 깨닫게 되는데,
이게 실제로 이런 경우가 적지 않다.

데이터가 틀리게 들어갔을 때, 에러가 나면 그건 그나마 다행이다.
만약 에러가 발생하지 않고 넘어가면 더 문제다.

만약 이게 실제 돈과 관련된 문제라면...

그래서 에러를 미리 방지할 수 있는 정적 타입 언어가 여전히 많은 호응을 받고 있는 것이다.

게다가 자유분방한 언어의 대표격인 Javascript 진영에서조차 이런 문제를 해결하기 위해서
Typescript를 개발한 것을 보면, 
역시나 정적 언어가 아직은 엔터프라이즈에서는 대세인가 하는 생각도 든다.

 

---

3. 라이브러리와 프레임워크

내가 느낀 둘의 차이점은 다음과 같다.

라이브러리

- 내가 필요할 때 갖다 쓰는 코드 뭉치
- 프레임워크에 비해서 규모가 작은 편이다.
- 보통 라이브러리를 쓸 땐 내가 필요한 일부 기능만 콕 찝어서 사용하게 된다.
- 라이브러리는 나의 코드 안으로 들어온다.
- 프레임워크에 비해서 비교적 코드가 적고 간단한 편이다.

예시)

- 날짜 관련 필요한 기능이 많아서 day.js 라이브러리를 사용했다.
- 환경변수 관리가 필요해 dotenv 라이브러리를 설치했다.

프레임워크

- 프레임워크는 기본적으로 내가 작성할 프로젝트의 메인 역할을 담당한다.
- 라이브러리에 비해서 코드의 규모가 큰 편이다.
- 프레임워크가 나의 코드를 갖다 쓴다.
- 나의 코드를 프레임워크가 원하는 대로 작성해줘야 한다.
- 실제 코드를 분석할 때 라이브러리와 다르게 분석해야할 코드가 복잡하다.

예시)

- 우리팀은 엔터프라이즈 규모의 서비스를 안정적으로 운영하기 위해서 Nest.js 프레임워크를 도입했다.
- 간단한 API 서버를 구축하기 위해서 Express.js 프레임워크를 기반으로 각종 라이브러리들을 추가해 활용할 예정이다.

어떤 기술이 라이브러리인지 프레임워크인지 헷갈린다면,

보통 기술의 메인 페이지(github 또는 공식 문서)를 확인하면 확실하게 알 수 있다.
대부분의 기술들은 본인들이 어떤 것인지에 대해서 명확한 단어로 설명을 해 놓는다.

 

---

5. REST API

REST API는 Representational State Transfer의 줄임말이다.

 

이름 자체에 큰 의미가 있는 건 아니고,
보통은 REST라고 하면 '웹 서비스끼리의 소통을 담당하는 가장 대표적인 문법' 정도로 이해하면 된다.

만약에 이런 상황이라고 가정해 보자.
'나의 앱에서 서버에서 유저 'chong'의 데이터가 필요해!'

그렇다고 위처럼 말로 달라고 할 수도 없는 노릇이고...

영어로 간단하게 하더라도 아래와 같이 할 수 있지 않을까?

'give me data of chong'

 

데이터를 어떤 식으로 달라고 요청해야 가장 효과적으로 전달할 수 있을까 고민을 참 많이 했을 것이다.

 

그래서 REST에서 선택한 방식이 바로 URI 이다.
이미 인터넷 주소 때문에 굉장히 익숙한 그 방식이다.

uri 방식을 사용하면 위의 요청을 다음처럼 하면 된다.
'GET http://dev-server.com/users/chong'

이런 식으로 URI를 이용해서 제공하는 것이 REST API다 라고 간단하게 이해해도 좋다.

 

서버 개발을 배우다보니, 
REST API의 규칙을 잘 알고 설계하는 것이 참 중요하다는 것을 알게 되었다.

아무렇게나 내가 원하는대로 만들어도 동작은 하지만,
대부분의 사람들이 이해할 수 있고, 일반적인 경우에 문제가 없는 
좋은 API를 작성하는 것은 필수다.

 

실제로 API Convention과 관련해서 인턴이나 면접 때 지적을 받기도 했다.

그래서 다음의 RESTful API 설계 규칙에 대해서도 공부하는 것을 추천한다.

https://one-it.tistory.com/entry/RESTful-API-%EC%84%A4%EA%B3%84-%EA%B7%9C%EC%B9%99

이건 추가로 REST API의 심화라고 할 수 있는 HATEOAS에 대한 내용인데,
REST API 관련해서 굉장히 유명한 영상이다.
https://www.youtube.com/watch?v=RP_f5dMoHFc