퇴사를 한 후 내가 경험한 기술들을 정리하면서 확실하게 느끼고 있는 것은 나의 기억력이 아무리 좋다는 가정을 해도 최대 2년까지 밖에 기억을 못한다는 사실이다.
13년 동안 이런저런 언어들을 이용하여 개발을 진행하면서, 언어를 사용하지 않고 스스로 공부를 하지 않으면, 해당 언어 스킬 뿐만 아니라 이론적인 부분까지 잊혀진다는 것이 이렇게 무섭다는 것을 새로운 출발을 준비하는 나에게는 큰 부담으로 다가오고 있다.
시간이 더 지나서 완전히 백지 상태가 되기 전까지 기존의 기술 스킬과 경험을 빠르게 기록해야겠다.
(그래야 훗날 이 언어를 다시보게되면 나의 기억이 돌아올 수 있도록... 기억력아 돌아와라~~~)
오늘은 지금으로부터 3년전인 2019년의 기억을 끄집어 내보겠다. 당시에 따로 정리한 기술 노트가 있긴 했지만, 지금와서 보니 참 이것저것 스크랩만 해서 작성했다는 내용들만 잔뜩있다.ㅠㅠ 오늘 이자리를 빌어 Javascript를 나만의 방식으로 정리해보려한다.
Javascript :
- 웹 브라우저 기반의 인터프린터로 시작
- C++ 기반의 V8 Engine에서 동작하기 때문에 Node.js 를 출시가 된 시점부터 Back-end 기반으로 동작 가능
- 이를 기반으로 nest.js, nuxt.js 등의 framework로 발전하게 됨
- W3G 제단에서 출판하는 Javascript 표준 문서인 ECMA Script 표준을 따름
ECMA script
- W3G 제단에서 출판하는 표준 가이드
- 2015년 이전까지는 prototype 기반의 함수형 프로그램을 지향해오다, ECMA 2015(ECMA 6라고도함) 가 출판된 이후에는 객체 지향 프로그램이 가능하도록 큰 변화을 불러옴. 이 후 ECMA 2016~2019 까지 async/await, 데코레이션 등 기존 framework에서 지원해주는 기능들을 추가하며 framework 개발로 확장할 수 있도록 표준화하였음
Javascript vs Python
- 공통점
- 인터프린터 vs 인터프린터
- scope vs scope
- 스크립트 기반의 기능 동작 가능
- 차이점
- protoype 기반의 상속 모델을 사용 vs class 기반의 상속모델을 사용
- 불변 가능한 개념이 없음(이것도 ECMA6 이후 let, const 등의 반불변(?)적인 개념이 생기긴 했음, 그래도 불변 개념은 아님(scope 허용 범위의 정의 정도…)) vs 불변 가능한 개념이 있음(str, int 등..)
- 버전별 하위호환성을 가짐 vs 버전별 하위 호환성을 가지지 않음(언어적 특성을 가지고 있음)
Scope
- 변수 및 매개변수의 유효 범위
- 참조 대상 식별자를 찾아내기 위한 규칙
- 별다른 정의가 되어 있지 않으면 모든 변수는 하나만 사용 가능함
- 전역 스코프/지역 스코프에 따라서 변수의 사용 범위가 결정됨
- 스코프는 함수 레벨 스코프 단위로 사용되어 지고, 전역 스코프의 경우 최상위 portotype에 정의되어 있는 함수 레벨 스코프에서 동작되어짐
ex) # 스크립트 실행 시 전역 함수인 prototype에 정의됨
# Object.prototype = function () {
var a = 1;
function add(){
let b = 2;
return a + b;
}
console.log(add()) # 3
# }Prototype
- Javascript에서 사용되는 단일 객체 개념(프로토타입 기반 언어라고도 불림)
- 모든 객체 및 함수의 속성은 Prototype 내에 상속되어 지며, 필요에 따라 사용자가 별도의 prototype을 정의하여 사용할 수 있음
- 프로토타입 객체는 상위/하위 프로토타입 객체 모두 상속을 주거나 받을 수 있으며, 스크립트 실행 시 프로토타입 체인에 의거하여 정의되어있는 프로토타입 객체가 실행되는 순서가 정해진다.
NodeJS :
- Javascript 기반의 SSR
- 싱글스레드 기반의 높은 처리 성능을 보여줌
- Event Driven 방식의 비동기 프로그래밍
- 장점 :
- 높은 생산성
- 러닝커브(진입장벽)이 상대적으로 낮음
- 빠른 배포 및 테스트
- 단점 :
- 싱글 스레드 방식이다 보니 대용량 처리 시 성능이 급격하게 떨어짐
- 비동기 방식이다 보니 복잡한 로직 개발 시 코드 가독성이 떨어질 수 있음
(ecma2017부터 async-await 기능을 이용하여 비동기 처리를 동기 처리처럼 사용할 수 있게 제공함으로써 가독성이 향상되었음)
여기까지의 내용을 보면 제목과 매칭이 안되네? 뭐야?? 하실 것이다. 오늘 '희노애락의 Javascript'로 제목을 지은 이유는 내가 Back-end 개발자로 넘어간 이유를 정리해보려한다.
2009년 솔루션 기반의 SI 업체를 다녔을때 까지만해도 나의 포지션은 "웹 개발자"다. 지금은 생소할 수 있겠으나, 당시 시절의 Web 시장은 Web 기반의 디지털 트랜스포메이션 서비스 같은 대전환의 시대가 아닌 단순 홈페이지를 만드는 정도의 시장이었다.
(물론 그때도 Back-end 개발자는 존재했으나, 그때의 기술 스킬은 linux c 또는 c,c++ 같이 시스템 core 개발 및 커널 활용 방법 등의 OS 기초 지식을 가진 개발자를 지칭하는 포지션이었다.)
이 시기에는 Web보다는 CS기반의 솔루션이 대세였기에 처우는 당연하게도 박봉이었고, 당시 국내에서는 Web이 앞으로 어떻게 갈 것이다라는 비전을 가지고 다양한 의견이 분분했던 시기다.
(이 때 미국은 세 가지 시장이 크게 태동하며 시대의 대전환을 진행하기 시작한다. 하나는 SPA 기반의 웹 어플리케이션 시장 형성, 이로 인해 google/twitter 등의 자이언트 회사의 탄생, 그리고 AWS가 주축이 되는 Cloud다.)
당시의 내가 가장 자신있었던 언어는 Javascript 였고, 첫 회사에 입사하면서 Javascript 기반의 웹 언어를 다룬다고 하였을때, Javascript는 언어가 아니다라는 소리를 듣기도 했다. 물론 아무것도 몰랐던 시기였고 웹 개발자가 나 혼자였던 시기다보니 그런가보다 하고 넘어갔지만.. 지금와서 생각해보면, 그때 ECMA Scirpt라는 표준 가이드의 개념을 알았고, 깊이 공부했더라면, "Javascript도 이렇게 Back-end 언어로 사용됩니다."라는 시대가 도래하였을 때, 지금처럼 이리저리 다니지 않고 특정 한 곳에 안정적으로 자리를 잡지 않았을까? 라는 생각이 든다. Javascript 개발의 즐거움을 경험하면서 개발자의 길로 들어셨고, 이를 기반으로 다양한 언어와 개발 경험을 하면서 나름 보람찼지만, 그 때 한가지를 깊이 파보지 않은 것은 개발자로 들어서면서 후회하고 있는 부분 중 하나다.
(오늘 이 글의 주제는 결국 나의 푸념을 정리하는 것이다 생각해주시면 좋을 듯 하다.)
아무튼, 이렇게 기술적인 부분과 나의 경험을 정리하니 씁쓸하지만 나름 정리가 잘 되었다고 생각한다. 이 글을 읽고 있는 개발자 분이 혹시나 계시다면, 나처럼 이런저런 기술 스킬을 따라가지 말고 한 우물을 꼭 파고나서 다양한 경험을 하길 바란다.
