강파의 기술블로그

YAML

정보인식을 위해 들여쓰기와 줄바꿈이 필수 문법 요소이다.

프로그램 간 정보 전달이 목적이 아니라 

주로 프로그램 설정 파일과 같이 개발자 입장에서 읽고 작성하기 위한 용도로 사용된다.

Ex 1>

name: 프로테크

location: 프로테크시 코딩구 열공길

owner: 

    name: 김강파

    id: protech

    phone: 010-1234-56788

menus:

    - name: 컴퓨터

        price: 10000

        source:

          - 전기

          - 키보드

          - 본체

      2:

    - name: PC방

        price: 1000

        source:

          - 담배

          - 요리

대강 이런 식으로 작성된다.

※Ain't Markup Language 가 YAML의 약자이다.

하이픈(-) 을 사용하여 배열을 표시하며 이 것은 마크업 언어가 아니다. XML이나 JSON보다 가독성은 좋다.

AJAX

이 것은 정확한 형식은 아니다.

JS를 활용하여 서버와 브라우저가 통신할 수 있게끔하는 통신기능을 구현해놓은 것이다.

요즘은 웹 페이지에서 필요한 부분만 부분적으로 Update 할 수 있는데 이 것이 가능한 이유가 AJAX 때문이다.

Asynchronous Javascript And Xml 의 약자로 JS를 활용하여 서버에 비동기 방식으로 요청하는 것이다.

바로 이 비동기 방식이 웹 페이지를 구현하는 주축이 AJAX이다.

비동기란 서버에 데이터를 요청한 상태와 별개로 프로그램이 계속 돌아가는 것을 뜻한다.

이 전에는 모든 클릭은 요청으로 새로운 접속을 의미하였다.

기존의 방식에서는 어떤 버튼을 눌러도 접속으로 판단하여 웹 페이지 전체 파일을 반환하여 주는 식으로 응답했다.

이 AJAX로 인해 웹 개발은 웹 서버프로그래밍에서 프론트엔드와 백엔드로 나눠지는 계기가 되었다.

이로 인해 브라우저에서 프로그래밍할 수 있는 범위가 비약적으로 늘어났다고 보면 된다.

XML

프론트엔드와 백엔드 사이엔 "한 줄로 된 텍스트" 로 작성되어 Data를 주고 받는다.

Ex 1> 프로테크시, 코딩구, 열공길

ㄴ 이런 식의 한줄 Source라면 큰 무리가 없다.

그러나 아래와 같이 분량이 많은 표 형식으로 데이터를 꾸밀 경우 컴퓨터는 이런 데이터를 구분할 수 없다.

Ex 2>

ㄴ 이런 건 컴퓨터가 알 수 없어...

위 표와 같이 복잡하고 다층적인 구조로 이뤄진 데이터는 컴퓨터가 이해할 수 없다.

따라서 계층과 구조를 가진 정보를 텍스트로 표현해줄 수 있는 일종의 형식이 필요하다.

그래서 나온게 XML과 JSON 이다.

XML source는 아래와 같다.

Ex 3> XML 코드

<?xml version="1.0" encoding="UTF-8"?>

<shop>

    <name>프로테크</name>

    <location>프로테크시 코딩구 열공길

    <owner>

        <name>김강파</name>

        <id>protech</id>

        <phone>010-1234-56788</phone>

    </owner>

</shop>

HTML 작성 방식과 비슷하지 않는가?

그렇다 이 놈 XML도 HTML과 마찬가지로 마크업 언어이다.

고로 같은 원리이며, 동일한 태그가 사용된다.(Ex 3> <shop> 같은 게 태그다.)

태그 사이에 정보가 들어가 있는 형태로 구성되며

태그 안에 또 다른 태그를 넣음으로서 다층 구조를 표현할 수 있다.

즉, 태그를 사용하여 컴퓨터에 다소 복잡한 정보를 정확하게 전달 가능한 구조라 보면 이해가 빠를 것이다.

HTML은 웹 페이지 구조를 개발한다면

XML은 플랫폼간 데이터를 주고 받을 때 데이터의 구조를 개발한다 보면 된다.

JSON

XML은 시작과 끝이 명확하다.

따라서 데이터의 구조를 확실히 보여주지만 단점이 있다.

일단 텍스트가 많아 코드의 길이가 길어지며, 중복되는 구분 덕분에 가독성이 떨어진다.,

또한 이로 인해 컴퓨터의 Load가 생각보다 많이 걸린다.

이런 단점을 보완한 형식이 JSON이다.

Ex 1> JSON 코드

{

    "name" : "프로테크",

    "location" : "프로테크시 코딩구 열공길",

    "owner" : {

        "name" : "김강파",

        "id" : "protech",

        "phone" : "010-1234-56788"

}

이처럼 JSON 형식은 XML 보다 더 간단하고 높은 가독성을 가지고 있다.

각 항목마다

"" 따옴표 로 구분하고

[] 대괄호 로 배열과

{} 중괄호 로 또 다른 객체가 오는 식으로

정보가 작성된다.

JSON의 단점으론

문법 오류에 취약해서 "" 따옴표나 [] 혹은 {} 같은 괄호가 하나만 빠져도 문서 전체를 읽을 수 없다.

반면 XML은 오탈자 포함시 해당 구분만 넘긴 채 읽는 게 가능하다.

또한 주석을 달 수 없다.

※ XML과 JSON 코드는 가독성을 위해 들여쓰기와 줄바꿈을 쓴 것이다.

실제 컴퓨터는 그저 한줄을 길게 나열한 형식으로 이해하고 자료를 표현한다.

프레임워크

마트에서 구매할 수 있는 식재료는 라이브러리.,

필요한 것들만 담아 놓은 밀키트는 프레임워크라 할 수 있다.

라이브러리가 "특정 기능"을 수행하는 S/w 조각이자 여러 프로그램에 범용적으로 들어갈 수 있는 재료라면

프레임워크는 라이브러리 + 자체 코드 = 소정의 소스코드만으로 Product를 만들 수 있는 제품

이라고 보면 된다.

프로그램 개발 관점에서 나누자면

프로그램을 만들기 위해 가져다 쓰는 개념이면 라이브러리(하나의 재료, Ex> 양파 등)

뭔가 IDE로 개발도구에서 그저 언어로 프로그램을 만들면 프레임워크(밀키트)라 생각하면 쉽지 않을까

국내 가장 많이 쓰이는 프레임워크와 언어는 Spring 과 Java 이다.

PHP + 라벨,

파이썬 + 장고 혹은 플라스크,

JS + 익스프레스,

C# + 닷넷

요즘엔 개발이 고도화 되어 프론트엔드 측도 프레임워크를 쓴다.

예로

JS(혹은 TS) + 앵글러,

JS(혹은 TS) + 뷰,

JS(혹은 TS) + 리액트(특성상 라이브러리라고도 불림)

정도가 있다.

API

약속된 규칙이다.

프론트엔드와 백엔드 사이 A를 주면 1을 준다 등

자신들만의 규칙으로 한 약속이다.

REST API

ㄴ REpresentational State Transfer API 라고 부른다.

ㄴ API를 설계시 어느정도 큰 틀에서 비슷하게 설계하기로 한 일종의 약속이다.

ㄴ 잘 설계된 API를 보통 개발자들은 REST ful 하다 표현하기도 한다.

API의 예로는 구글 지도맵, H/w API가 있다.

구글과 비슷한 API로는 공공 데이터 포털(https://www.data.go.kr)에서 날씨, 행정, 법률 등 다양한 데이터를

데이터 사용법과 함께 API를 제공한다.

이처럼 API는 어떤 제공처에서 자료를 오픈했기 때문에 접근할 수 있는 권한을 가지게 되는 것이다.

H/w API는 컴퓨터 내부의 시스템과 S/w 끼리 호출하기 위해 사용된다.

프론트엔드

예전에는 사용자가 요청시 서버는 HTML의 모든 리소스를 보내주는 형식으로

그 효율성이 매우 좋지 못하였다. 부하↑, 속도↓

따라서 예전의 웹 프로그래머 = 웹 서버 프로그래밍을 의미하는 것이었다면..

최근에는 브라우저를 프로그래밍할 수 있는 자바스크립트 언어의 기능↑ 되면서

웹 브라우저의 세세한 부분으로 나눠서 그 요청을 나눌 수 있고 이로 인해 서버의 부하를 줄일 수 있다.\

ㄴ Ex> 좋아요 시스템의 경우 좋아요를 누를 경우 HTML 페이지 전체를 로딩하는 것이 아닌 자바스크립트로 코딩된 일부 영역만을 서버에 요청하므로 서버에 가해지는 부하 측면에서 매우 효율적이라 할 수 있다.

결론적으로 유저는 빠른 속도와 데이터 낭비를 줄일 수 있는 것이다.

웹 사이트에서 필요한 데이터를 서버에 요청하고 반환된 정보를 활용해 화면을 구성하는 일이

프론트엔드 개발자가 하는 일이다.

※ 브라우저 언어로는 자바스크립트를 여전히 많이 쓰지만 좀 더 효율적으로 관리하고자 하는 개발자들

혹은 프로그램은 타입스크립트를 쓴다.

타입스크립트 언어는 자바스크립트에서 파생된 언어로 데이터에 자료형 타입을 부여하여 좀 더 오류 매니지먼트 측면에서

확실히 할 수 있는 언어인 셈이다.

백엔드

서버사이드 측 연산이다.

프론트엔드(클라이언트 측)에서 백엔드(서버)로 요청시 이를 반환하는 코딩을 하는 기술적 부분이다.

쉽게 말해 SNS의 예로 보자.

① SNS 접속시 브라우저는 프론트엔드 프로그램대(클라이언트 측)로 서버에 친구들의 피드를 보여달라 요청한다.

② 서버는 요청을 받아 DB에서 사용자의 친구 목록을 얻고, 친구들이 올린 피드를 최신순으로 뽑아서 클라이언트 측에 전송한다.

이처럼 클라이언트 단의 프로그램이 어떤 요청을 하면 백엔드 측은 그에 대응하여 반환하는 구조인 셈이다.

대게 프론트엔드 개발은 자바스크립트 언어를 쓴다.

백엔드는 서버에 돌아가는 프로그램을 만드는 것이므로 Java, Python, Javascript, C#, PHP, Ruby 등 다양한 언어가 활용될 수 있다.

웹 앱

그냥 웹 사이트라고 보면 된다.

적응형 혹은 반응형 방식으로 사용하여 모바일 기기서 볼 수 있게 만든 것이다.

장점 : 앱 마켓의 심사과정이 없고 웹사이트인만큼 비용이 적게 든다.

단점 : 브라우저로 할 수 있는 기능 외, 내부의 파일, 각종 h/w장치는 제어가 불가능에 가깝다.

          접근성이 매우 불편하다.(직접 URL치고 들어가야 함.)

하이브리드 앱

웹사이트로 제공하면서 네이티브 앱의 기능까지 제공하는 앱을 하이브리드 앱이라 한다.

원리는 네이티브 혹은 크로스플랫폼 방식으로 앱을 제작 후

화면 요소를 직접 만들지 않고 브라우저 역할을 해줄 수 있는 웹 뷰라는 요소를 사용하여

웹 화면에 띄우는 형식이다.

카메라, 푸시알람 같은 기능을 쓸 수 있으면서 웹 브라우저이므로 매우 범용성 있게 쓸 수 있다.

Ex> 다음사이트 앱

앱 기능을 업데이트 할 때를 제외하곤 심사 없이 바로 수정, 사용 가능하다.

(앱 기능 업데이트시엔 마켓에 다시 올려야 하니 이에 따른 마켓의 심사가 필요하다.)

PWA

Progressive Web Apps 이다.

PWA는 기본적으로 앱이 아닌 모바일 웹사이트 이다.

무슨 소리냐면 웹 앱 임에도 불구하고 바탕화면에 아이콘으로 설치가 가능하며,

푸시 알람을 보낼 수 있는 등 이를 사용해 카메라, 블루투스, 진동 등 기능을 사용할 수 있다.

ㄴ 크롬 브라우저의 기능

단점 : 아이폰은 사파리만 PWA가 가능하며, 그 기능도 매우 제한적이다.

따라서 대세 기술이 되기엔 아직 모자른 감이 있다.

네이티브 앱

안드로이드, iOS 등 각 운영체제 별 앱을 제작하는데 이들에게 최적화된

개발언어를 사용하여 개발하는 것을 네이티브 앱이라고 한다.

가령 예를 들면 안드로이드의 경우 Java, iOS 의 경우 swift 등이 있다.

각 운영체제에 맞는 언어로 개발이 이루어지며 

Write -> Test -> Build 가 이뤄진다.

장점 :

① 각 스마트 폰의 모든 기능을 사용할 수 있으며 효율 또한 최고로 뽑을 수 있다.

ㄴ GPS, Bluetooth, Camera, 영상편집 등 최대의 성능을 발휘해야하면 추천한다.

단점 :

① 개발 기간이 길어지고 그에 따른 비용이 증가한다.

② 안드로이드(Playstore), iOS(App store) 등 각각의 심사를 거쳐야 한다.

③ 네이티브 앱으로 개발된 앱은 컴퓨터로는 접속이 불가하다.

ㄴ 가상머신을 이용한 추상화 기술을 사용시엔 가능하긴 하다.

크로스플랫폼

같은 소스코드로 안드로이드, iOS 전부 구동되게끔 고안된 도구이다.

플러터는 다트 언어

리액트 네이티브는 자바스크립트 언어

닷넷 마우이는 C# 언어

등을 언어로 쓴다.

네이티브가 아닌만큼 성능에 제약이 있다.

크로스플랫폼을 일부 차용하는 유명 앱으로는 에어비앤비, 페이스북, 인스타그램 등이 있다.

각 크로스플랫폼의 프레임워크 별 스마트폰의 기능을 얼마나 지원하는지,

또는 자원을 얼마나 활용할 수 있는 지 확인 후 선택하는 것이 좋다.

주로 스마트폰 기본 기능 들을 활용하면서 높은 성능을 요구하지 않는 앱을 개발하기에 적합하다.

토큰

세션 방식은 안전하고 빠르지만 단점이 있다.

바로 메모리에 올려두고 사용하는 방식이라 서버에 부하가 과도하게 몰릴 시 뻗을 수 있다.

ㄴ SSD나 HDD 방식 같은 대용량 방식은 용량은 크지만 느리기 때문에

    속도를 중시하는 시스템들은 메모리에 올여두고 사용하는게 일반적이다.

그래서 서버는 로그인한 사용자에게 "토큰 생성 & 검증 알고리즘"을 사용하여 

토큰을 발급해준다.

이러한 이유로 사용자는 서버에게서 토큰을 쿠키 형식으로 받아서 필요할 때마다 서버에 제시하여

로그인시 인증 절차를 받을 수 있다.

단점 : 여러 기기 연결시 강제로 접속을 종료해야 하는데 토큰 방식의 경우 이런 것을 할 수 없다., 방지 대책으로는 토큰의 만료시간을 짧게 하여 부하를 줄이는 방식으로 설계한다.

토큰은 만료시간(유효기간)이 끝나기 전에는 서버가 통제할 수 없다는 점에서 보안상 취약해질 수 있다.

캐시

Cache Memory 에서 주로 쓰는 단어이다.

컴퓨터의 하드웨어에서도 고속 연산을 담당하는 CPU의 메모리는

CPU 안에 Cache memory 라고 불리우는 곳에서 담당하는데 여기서 착안한 개념이다.

ㄴ 연산속도가 특히 빠르다. 그러나 용량은 역시 적다.

웹 상에서 한번 방문한 웹 사이트를 계속 요청하지 않게끔 개인 컴퓨터의 Cache에 저장시키는 기술이다.

반복적인 요청으로 Server에 Load가 걸리는 일도 없고 유저 입장에선 빠른 로딩으로 스트레스도 없다.

브라우저 캐시라고 표현한다.

쿠키 : text 조각 모음들로 사용자 편의성 위주로 수고를 덜어주는데 목적

캐시 : 데이터 전송량 측면에서 서비스 이용 속도를 높이는데 목적

CDN

콘텐츠 전송 네트워크의 줄임말이다.

사용자의 요청에 가장 가까운 서버에서 대응하는 서비스 개념이다.

즉, 본서버에서 전 세계에 흩어진 캐시 저장 및 전달용 컴퓨터에 데이터를 보내면

CDN은 이를 토대로 사용자의 요청을 토대로 가까운 서버에 작업이 할당되게끔 분산처리한다.

본서버는 1번만 데이터를 보내면 된다.

사용자는 가장 가까운 서버에서 데이터를 받으니 빠르게 데이터를 받을 수 있다.

대량의 데이터를 전송하는 서비스(Ex>넷플릭스, 유튜브 등)는 이런 CDN이 필수인 셈이다.

전세계 : AWS의 Cloudfront, CloudFlare, Akamai 등

한국 : GS 네오텍, SK브로드밴드, KT 등

서비스 특성, 사용자 규모, 대상 지역에 따라 적합한 CDN업체의 상품을 선택하는 게 중요하다.

쿠키

쿠키는 크롬, 사파리 같은 브라우저에 저장되는 작은 텍스트 조각이다.

브라우저 S/w에 개인적으로 저장되는 정보파일이라고 보면 된다.

사용자는 브라우저의 설정화면, 개발자 도구에서 쿠키를 확인하고 수정, 삭제 할 수 있다.

쿠키는 본인을 포함 제 3자도 조회가 가능하기 때문에 보안상 이유로 민감 정보를 담는데는 적합치 않다.

세션

사이트에 로그인 시 세션이 없으면 페이지를 누를 때마다 매번 ID와 Password가 필요하게 된다.

이러한 번거로움을 덜기 위해

서버로부터 인증 받았음을 증명해주는 세션이라는 증서를 활용한다.

서버는 아이디와 비번으로 유저가 로그인시 "세션 아이디"라는 데이터를 만든다.

Ex> 2Gsd98dfwze2 이런 식으로 알파벳 + 숫자가 혼합된 형식을 쓴다.

세션 아이디를 사용자에게 전달하고, 메모리에 아이디 사본을 어떤 사용자의 것인지 적어서 보관한다.

사용자는 서버로부터 받은 세션 아이디를 쿠키로 저장하고 앞으로 모든 요청에

선행하여 이를 보내주어 자신이 로그인한 인증자라는 것을 증명한다.

쉽게 말해 세션이란 것은 일종에 Identifier로서 열쇠라고 보면 된다.

쿠키의 세션 아이디를 서버가 동일한 세션 아이디로 매칭되는 정보를 서로 상호 점검하여

데이터의 무결성을 검증하는 작업이라고 보면 될 것이다.

★세션은 빠르다!

그러나 그 빠른 부분을 담당하는 영역이 CPU의 캐시 영역이므로 용량이 소용량인 측면이 있다.

그러므로 리소스가 다분히 한정적인 자원을 활용한다고 보면 된다.

★서버 뻗을 위험 있음!