개요

취업을 목표로 하는 기업은 [카카오, 네이버, 라인]과 같은 IT 기업이다.

많은 분야를 두고 고민했으나, 결국 Web 계열 Front-end & Back-end로 결정했다.


SSD 관련해서도 연구실에서 발 담궜으니, 삼성전자 DS에 원서를 쓸 예정이다.

(반도체냐, 웹이냐.............. 서로 이직이 안되므로 고민......)


한달도 안 남은 기간동안 웹 포트폴리오를 만들기 위한 과정을 기록하려고 한다.



웹기술 관련 업계 동향

웹만큼 빠르게 변화하는 업계는 없는 것 같다. 개인적으로 생각하는 업계 동향을 적어본다.



Front-end 초장기에는 순수 JavaScript만이 존재했다. 근데 브라우저끼리 호환도 안되고 해서 소소하게 입력값 검사 정도의 역할만 했다.

이후 AJAX와 jQuery가 등장하였고, 난이도가 낮아지고 기능이 늘어나기 시작한다.


Back-end로는 PHP/ASP/JSP 세 개가 쌈싸먹게 된다.

소규모 사이트는 PHP로, 좀 규모가 있다면 JSP/ASP로 백엔드를 선택하면 되는 편한 상황.


이후 Python(Django), Ruby(Rails) 등등의 Back-end도 나오게 된다.


그런데 Google V8 Engine이 공개되면서 Node.js가 등장했다. JavaScript를 Back-end로 쓰기 시작했다.

단순히 언어만 JavaScript였다면 Django, Rails랑 같은 취급이었을거다. 그런데 장점이 많았다.

Back-end 대세는 Node.js로 흐르기 시작했다. 더불어 JavaScript 언어의 위상도 올라갔다.


Front-end도 장족의 발전을 했다. 프론트는 선택의 여지 없이 JavaScript 언어이다.

jQuery를 밀어내며 Angular(구글), React(페이스북) 등의 프레임워크가 나오기 시작했다.


근데 Angular가 너무 무겁고 규칙이 빡셌나보다. 가벼움을 추구하는 Vue.js, Backbone.js 등이 나오기 시작했다.


그리고 완전 최근 동향은 뭐... GitHub에서 JavaScript언어에 스타 순으로 정렬하면 대충 각 나온다.



정리하자면...


[Front-end] Vanilla JS --> AJAX/jQuery --> Angular/React --> Vue.js

[Back-end] PHP/ASP/JSP --> Django, Rails --> Node.js


너무 빨리 변해서 대체 뭘 공부해야 할 지 초심자 입장에서는 진입장벽이다.

줏어들은 바로는 이미 배운 사람도 문제다. 버전업이 너무 빠르기 때문...



포트폴리오 준비 계획

Kakao, Naver, LINE 채용 페이지에서 과연 어떤 경력직을 모집중인지 조사했다.

그리고 Web 기술이 아닌 것들은 배제했다. (FinTech, Video Streaming, Machine Learning 등)


대체로 요구하는 기술은 아래와 같다.


[공통]

RESTful API 개념, MSA 개념, MVC 패턴

형상관리 (Git)

Single Page Application (SPA) 개념

Linux, Shell Script, MySQL, NoSQL


[JavaScript]

ECMAScript5 (2015), TypeScript

Node.js, MongoDB, Express

jQuery, Backbone.js, React(+Redux), Angular, Vue.js

webpack, Electron

Bootstrap


[PHP]

Laravel


[Java]

Spring, Playframework(Scala)


기간이 한달 남짓이기에 이걸 전부 공부하기에는 시간이 모자라다는 판단이 든다. 선택과 집중을 하자.

우선 PHP는 이미 할 줄 알고, Java는 손절한다. 걍 JavaScript에 집중하기로 했다. 이것도 넘 많아서 일부만 해야한다.


한 달간 공부하고 포트폴리오에 사용할 내용은 다음과 같다:

백엔드는 Node.js(Express, MongoDB, webpack, babel), 프론트는 Vue.js, 디자인은 Bootstrap



웹 관련 개념

RESTful API

HTTP Request의 GET/POST/PUT/DELETE를 이용해서 CRUD(Create, Read, Update, Delete) 기능을 구현하는 것이다.

기능적인 측면만 봤을 때는 위와 같고, 사실 그 뒷면에 이념이나 규칙 등은 조금 더 자세하다. 그 내용은 아래 소스들 참고.

https://meetup.toast.com/posts/92 (REST API 제대로 알고 사용하기)

CRUD를 테스트하는 툴로 Postman을 많이 사용한다. (https://www.getpostman.com)

MSA (Microservice Architecture)

서비스를 작은 단위로 쪼개서 운영하는 구조. 반대말은 Monolithic Architecture이다. (앞으로 Mono와 Micro라고 하겠다.)


Monolithic 아키텍처는 쉽게 말하면 한 웹서버 안에 모든 기능을 다 때려박은 구조이다. 단순하므로 개발이 빠르고 쉽다. 장점들은 많다.


그런데 몇 가지 문제가 있다. (쿠팡 블로그에서 참조함)

1) 일부가 전체에 영향을 미친다. 코드에 메모리 누수가 발생하면 그 서버 전체가 다운되는 수가 있다.

2) 부분적인 Scale-out이 안된다. 일부 서비스에만 오버로드가 발생한다 해도 전체의 스케일을 키워야 한다.

3) 여러 컴포넌트가 강하게 연결되어 있어, 변경이 어렵다. 강결합의 단점은 코드 수정 시 다른 코드에도 영향이 갈 수 있고, 그 정도를 모른다는 점이다.

4) 일부 수정에도 높은 테스트 비용이 든다. 특정 부분만 수정해도 테스트는 전체 서비스에 대해 이뤄지므로 비용이 비싸다.

5) 서비스 규모가 커질 수록 배포 시간이 오래 걸린다.


따라서 서비스를 작은 단위로 쪼개고, 물리적인 서버도 분리하고, 각 서비스끼리는 Message Queue를 두어 통신하게 한다.


이외에 자세한 내용은 아래 소스들 참고.


https://alwayspr.tistory.com/20 (Microservice Architecture 란?)

https://jason-lim.tistory.com/1 (Microservice Architecture에 대한 이야기 - Integration)

https://medium.com/coupang-tech/행복을-찾기-위한-우리의-여정-94678fe9eb61 (쿠팡의 MSA — Part 1)


MVC 패턴

개발할 때 Model-View-Controller 3가지 형태로 역할을 분리하여 개발하는 방법론.


처음에는 '왜 굳이 번거롭게?' 라는 생각이 들 수 있으나, 나중에는 합리적이라는 생각이 든다.

물론 개발 과정이 기존처럼 파일 하나에 다 때려박던 것보다 번거로운건 사실인데, 이렇게 분리함으로써 나중에 관리하기가 편해진다.


[Model] 내부 비즈니스 로직을 맡는 역할. 알고리즘, DB, 데이터 관리 등

[Controller] Model과 View를 연결, 또는 유저와 연결되는 역할. 유저의 명령을 받아 Model에게 일을 넘겨주고 그 결과를 View를 통해 보여줌.

[View] 화면에 무언가 보여주기 위한 역할.


각자 하는 역할이 분리된다. 좀 더 자세히 설명하자면

Model은 데이터 혹은 작업 요청서(?)만 받아서 자기 일을 하고 Controller에게 주면 된다. 사용자랑 무슨 일이 벌어지는지는 관심 없다.

View는 Controller가 요청하면 자신의 모양대로 데이터를 그려내면 된다.

Controller는 Model-View를 중간에서 관리하면서, 유저와 연결되어 있기도 하다.


예)

사용자는 Controller에게 요청을 한다.

Controller는 필요에 따라 Model 에게 작업 혹은 데이터를 주어 처리한다.

그리고 그 결과를 View에게 전달하여 사용자에게 화면을 보여준다.


더 자세한 내용은 아래 소스들 참고.


https://medium.com/@jang.wangsu/디자인패턴-mvc-패턴이란-1d74fac6e256 ([디자인패턴] MVC 패턴이란?)

https://jayzzz.tistory.com/40 (MVC패턴 모델, 뷰, 컨트롤러)


Single Page Application (SPA)

이름 그대로 페이지 하나에 모든 기능을 때려박는(?) 접근 방법이다. 모던 웹의 패러다임이라고 할 수 있다. 페이스북이 이런 식이다.


장점은 페이지 로드 처음에 일단 모든 리소스를 다운받고, 이후에는 변하는 부분만 서버에서 내용을 받아와 표시한다.

따라서 새로고침이 발생하지 않으므로 Native App과 같은 사용자 경험을 줄 수 있다. 트래픽이 줄어들어 모바일 환경에서 좋다.


단점은 최초 1회 로딩에 대하여 많은 양의 리소스를 받아야 하므로 초기로딩속도가 느려지게 된다.

더불어 내용이 상황에 따라 동적으로 변하기 때문에, 검색엔진에서 크롤링이 불가능하다.


이외에 장단점이 더 많이 있다. 역시나 아래 소스들 참고.


https://poiemaweb.com/js-spa (Single Page Application & Routing)

https://medium.com/@bbirec/spa-single-page-application-개발에서-고려할-사항-eedcb7cb618f (SPA 개발에서 고려할 사항)

https://m.mkexdev.net/374?fbclid=IwAR3H9b90QaKAuuNPgJMfoXnWwfsnU4glF4uBp0QSDhAlnBJ8gNb8D5cdeKQ (SPA 단점에 대한 단상)



웹 기술 공부

Node.js (Back-End)

Server-Side에서 동작하며 Network Application을 제작할 수 있는 플랫폼이다. 언어는 JavaScript를 사용한다. (Google V8 엔진 기반)


혼동하지 말 점은, Node.js는 Web Server가 아니라는 점이다. (Apache가 아니다!)

그냥 JavaScript를 실행(Run)할 수 있게 해 주는 런타임(runtime)이다. 마치 Python처럼 말이다.


Node.js가 웹 서버로서 동작하려면 라이브러리(주로 Express)를 이용하여 HTTP 서버 코드를 직접 작성해야 한다.

여기서 직접 작성한다는 말은, Apache가 FTP로 파일을 툭 올렸을 때 폴더 기반으로 파일의 URL을 알아서 처리해 줬던 것과는 달리

Node.js는 URI를 해석하는 것부터, 어떤 파일과 매칭시킬 지 혹은 어떤 코드를 실행시킬 지를 코드로 일일이 라우팅(Routing) 해 주어야 한다.


기존 Apache+PHP 환경에 익숙한 사람은 Node.js가 다소 불편할 수도 있다. 지향하는 바가 조금 다른 것 같다.


Apache는 FTP로 올린 파일의 경로가 URL에도 1:1로 매칭되는 시스템이다. 즉, 파일 위치가 곧 URL이다.

Node.js는 파일의 위치와 URI가 다른 경우가 허다하다. URI와 파일을 직접 매칭 시켜줘야 한다. 그래서 번거로울 수도 있다.


앗, URL과 URI라고 다르게 표기한 것을 눈치챘는가?

URL과 URI의 차이



입문(Tutorial)

Node.js는 공식적인 튜토리얼이 없고, API 문서만 제공한다.

따라서 외부 튜토리얼로 공부해야 한다. 나는 다음 2개의 튜토리얼을 통해 학습하였다.


https://www.w3schools.com/nodejs/ (영문)

https://velopert.com/node-js-tutorials (한글)



설치

학습을 위해 Amazon AWS에 가입하고 프리티어(1년)를 받아 가상서버에서 진행하였다.

Red Hat 리눅스에 설치하였고, 버전은 Node.js 11.10.0 (npm 6.7.0)이다.


엔터프라이즈(RedHat, CentOS, Fedora)는 NodeSource라는 곳에서 바이너리를 배포한다고 한다. (공식 사이트의 안내사항이다.)

아래 링크에서 쉽게 설치하는 쉘스크립트를 제공하고 있다. 명령어 한 줄로 Node.js를 설치할 수 있다.

https://github.com/nodesource/distributions/blob/master/README.md



Hello World 찍어보기

다음 코드를 hello.js에 작성해본다. (vim 이용)


console.log("Hello, World!");


node를 실행하는 명령어는  node 이다. hello.js를 실행하려면  node hello.js 를 입력하면 된다.



아주 간단한 웹서버 만들기

웹서버를 만들기 전에, HTTP 프로토콜에 대한 기반 지식이 필요하다. 특히 헤더의 구조에 대해 알고 있어야 한다.


아래 코드는 http 모듈을 불러오고, 8080 포트에 http 서버를 오픈하는 예제이다.

그 어떤 URI로 접속하던지 동일한 결과를 출력할 것이다. Header에 Response Code: 200(성공)을 보내고, Body는 Hello World.


var http = require("http");


http.createServer(function(request,response) {

    response.writeHead(200, {'Content-Type': 'text/plain'});

    response.end("Hello World\n");

}).listen(8080);


코드를 해석한다. createServer()는 웹서버 객체(Object)를 만든다. 그리고 객체를 만들 때 익명 함수를 작성하여 전달했다.

더불어 웹서버 객체에 대해 8080 포트로 요청을 받아들이도록 listen() 메소드를 호출했다.


이제 해당 웹서버는 8080 포트로 접속이 들어올 때마다, 등록한 익명 함수를 호출할 것이다.


웹서버 예제는 더 복잡한 거 말고 여기까지만 하는 게 좋다. 어차피 Express 모듈을 써서 웹서버를 만들 것이기 때문.



Node Package Manager (NPM)

NPM은 패키지/모듈을 쉽게 설치하고 관리할 수 있도록 해 주는 명령어이다. (RedHat의 yum, Ubuntu의 apt-get과 같은 역할)


Node.js로 사이트(프로젝트)를 만들 때 수많은 모듈을 짜집기해서 만들게 된다. 따라서 필연적으로 다음과 같은 2개의 문제점이 발생한다.


1) 프로젝트마다 필요한 모듈이 다를 것이다.

2) 프로젝트의 개발 시점에 따라서 사용한 모듈의 버전이 달라질 것이다.


따라서 이 프로젝트에 어떤 모듈이 사용됐는지, 모듈의 버전이 무엇인지를 프로젝트 내 package.json 파일에 기록해야 한다.

물론 package.json은 NPM에 의해 자동으로 관리된다. 그런 역할을 NPM이 해 주고 있다.


만약 다른 사람의 프로젝트 파일을 다운받았다고 가정해보자. NPM에서 제공하는 간단한 명령어 2~3줄로

해당 프로젝트의 의존성(Dependency) 패키지들을 한 번에 설치하고, 프로젝트를 바로 실행할 수 있다. 



# 프로젝트 생성

npm init


리눅스에서 적당히 폴더를 하나 만들고, 위 명령어를 치면 이제부터 해당 폴더가 프로젝트 폴더가 된다.

프로젝트의 이름, 버전, 제작자 등의 정보를 기입할 수 있다. 귀찮으면 전부 엔터를 쳐버려도 된다.



# 특정 모듈 설치

npm install [모듈명]


# 현재 프로젝트의 모든 Dependencies 모듈 설치

npm install


위 명령어는 모듈 파일을 다운받아 프로젝트 폴더에 설치해 주지만, package.json에는 기록하지 않는다.


--save 옵션을 주어야 package.json에 "Dependencies" 항목으로 기록된다.

--save-dev 옵션을 주면 "DevDependencies" 항목으로 기록된다. (음... 쉽게 얘기하면 개발용과 배포용을 따로 사용할 수 있다.)

--dev 옵션을 주면 "DevDependencies" 항목의 패키지를 설치한다. 옵션 안주면 일반 Dependencies만 설치된다.

-g 옵션을 주면 글로벌로 설치한다. 기본값은 로컬 설치(현재 프로젝트 폴더에만 설치)이다. 글로벌 설치는 아예 시스템에 파일이 박힌다. (sudo 필요)



이외에도 NPM의 다양한 기능들이 있다.

예를 들어 npm run-script 명령어는 아주 편하고 많이 사용되는 기능이다. script 관련 내용은 아래 package.json에서 익힐 수 있다.



package.json

다음 블로그에서 잘 설명해 주고 있다: https://programmingsummaries.tistory.com/385 (모두 알지만 모두 모르는 package.json)



Callback Function(콜백 함수) 개념

이 개념을 받아들이기 어려워 하는 사람도 있다. 생소하기 때문이다.

자세한 설명은 다른 블로그가 더 잘 해주고 있고, 여기서는 개요만 설명하겠다.



기존 Blocking 코딩에서, get_number() 함수가 처리에 5초 걸린다고 가정해 보겠다.


var a = get_number(); // 5초 걸리는 놈

console.log(a); // get_number()의 결과를 출력


next_function();


프로그램의 실행 흐름은 다음과 같다:

get_number() 호출 --> 5초 대기(blocking) --> a 출력 --> next_function(); 실행


즉, next_function() 입장에서는 앞 코드 실행이 끝날 때까지 기다려야 자기가 실행될 수 있다.



다음 예제는 Node.js가 익명 함수를 사용하여 Blocking을 없애고 있는 모습이다.


get_number(  function(req,res) { console.log(req); }  );

next_function();


get_number() 호출 --> next_function() 호출 --> 5초 후 --> 익명 함수(function)를 호출해서 결과 출력


next_function()은 아무런 대기 시간 없이 즉시 실행될 수 있다.

get_number() 함수가 끝났을 때 무슨 코드를 실행할 지를, 익명 함수를 통해 작성하면 된다. (Non-blocking 구현)

익명 함수는 본 함수의 처리가 끝났을 때 호출될 것이다.



자, 지금까지는 기존 언어(Java 등)에 익숙했기 때문에 '익명 함수' 라고 불렀지만, 사실은 이게 '콜백 함수'이다.

처리가 끝나면 불려지는 함수를 콜백 함수라고 한다.









(공부하면서 계속 내용 추가 중)

(Last Update: 2019/02/21) 

NC도 1차 면접에서 떨어졌다. 너무 어려웠다.




2:1 면접이었고, 내 지원 직무는 게임개발이다.

서버/클라이언트 구분이 없어서, 나는 양 쪽 다 해본 경험을 어필하고 포트폴리오를 구성했다.


전반적으로 질문이 문제해결능력창의성을 보려고 했던 것 같다.

문제를 몇 개 예로 들면

- 3D 맵디자이너가 맵을 만들어왔는데, 떨어지면 가파라서 다시 올라올 수 없는 지형을 프로그래머 입장에서 어떻게 찾아낼 것인가? (구체적으로)

- 동접자가 100만명이 들어왔을 때, 접속중인 유저의 정보를 담은 클래스를 어떤 자료구조로 관리할 것인가? (DB 문제가 아님)

- 이외에도 문제 다수


다 현업에서 부딪히고 있는 듯한 시나리오였고, 학부생으로서는 당연히 접해보지 못한 문제이기에 그냥 내 생각대로 말했다.

그리고 해시함수나 트리를 이용한 서버 운영 시나리오도 몇 개 질문받았는데, 그 내용은 복잡해서 생략하겠다. 굉장히 어려웠다.


학부 기초 내용에 관한 질문도 있긴 있었는데, 서버와 클라이언트를 구성할 때 TCP/UDP 중 무엇을 쓸 것이고 그 이유를 물어봤다.

그리고 TCP의 특징 3가지와 같은 아느냐/모르느냐의 문제여서 전부 답했다.




결국 떨어졌는데, 여기는 그냥 실력부족으로 떨어졌다. 너무 어려웠다.

공부를 더 해야겠다는 생각이 든다. 포트폴리오도 부실했고.

1차 면접에 떨어진 후기를 써본다. 떨어졌으므로 간단하게 써야지




3:1 면접이고 분위기는 아주 편했다. 좁은 테이블에 4명이 바싹 붙어서 팀플하는 느낌.

들어가면 1분 자기소개 하고, 풀었던 코딩테스트 문제에서 뭐가 인상깊거나 아쉬웠는지 간단히 물어본다.


면접은 100% 자기소개서만 가지고 하는 것 같다. 그러니까 서류 쓸 때 면접까지 생각해서 신경썼어야 했다.

자기소개서에 쓰여진 경험, 팀플, 프로젝트에 대해서 아주 자세하게 물어본다.

어떤 역할을 맡았고, 무슨 기술을 썼으며, 어떤 어려움이 있었고 어떻게 해결했는지


그리고 꼬리물기 질문이 어렵게 들어온다.

예를 들면 내가 홈페이지를 만들었었다 -> 로그인 보안은? -> SSL을 썼다 -> SSL도 뚫리는 거 알고 있느냐? -> 모른다 첨듣는다... -> ㅇㅇ수고

이런 식으로 내가 모르는 내용이 나올 때까지 긁고, 면접관이 실망하는 것이 반복되었다.

근데 억울한게... 나도 꽤나 많이 알고있다고 생각했는데 진짜 듣도보도 못한 걸 갖고와서 물어본다ㅜ...


그래놓고 내가 시무룩하면 아, 어차피 학부생들한테 별로 기대하는 거 없어요 라고 말을 해 준다. (위로인가?)




일단 면접 떨어진 이유는 확실히 짐작이 간다. 내가 서류 쓸 때 생각 없이 썼다.

포트폴리오에 Server 관련 내용을 잔뜩 써놓고, 정작 지원 분야는 Client로 썼다. 그래서 직무가 맞질 않았다. (면접관이 직접 묻기도 했다)


말실수로 대답 잘못한 것도 몇 개 기억나는데, 지금 생각해보면 면접관이 전부 기회를 줬던 것이고 내가 잡지 못했다.

이번 하반기 첫 면접이어서 멋도 모르고 멍청하게 망쳤다. 담엔 잘하지 뭐...

+ Recent posts