코딩아재

한백년·2025년 1월 18일
개발자
0

개발자

목록 보기
10/17

○ 웹개발입문 심화편 (2022)

4. COOKIE와 SESSION, DIGEST

  • HTTP는 TCP 기반의 비연결성 프로토콜이다. 서버 입장에서 클라이언트를 식별할 수 없는 무상태를 의미한다. 무상태의 웹 환경에서 브라우저의 진행상태를 지속해서 전달하는 방식이 필요하다.
  • 브라우저에서 Cookie는 내부적으로 키와 값의 인자값을 저장하고 요청 시마다 인자값들의 모든 정보를 대입하여 전달한다. Cookie는 일반 웹 사용자에게 노출되지 않는 브라우저 내부에서 자동 관리한다. 그러나 스니핑으로 전송되는 데이터를 확인할 수 있다.
  • 서버에는 Session이 있어 웹 사용자 별로 데이터를 저장하고 Session Key 값을 브라우저와 공유하여 개인정보기반 연동을 유지한다. 브라우저에서 웹 서버에 최초로 요청하면 웹 서버에서 Session Key를 발급하고 브라우저는 그 값을 쿠키에 저장한다. 브라우저에서 로그인을 하면 웹 서버에서 로그인 정보를 확인하고 그 처리 결과를 Session에 저장하고 브라우저에 응답한다. 브라우저는 그 상태를 쿠키에 저장하여 로그인 상태로 서비스를 운영한다.
  • Digest는 아이디와 패스워드 조합을 난수값을 더해 암호화하여 전달한다. Session과 Cookie를 사용하지 않고 연동한다. 관리자 전용 웹 서비스에 Digest 방식을 채택한다.

3. HTTP 프로토콜 2

  • HTTP/1.1 이후 CGI의 다양항 처리를 할 수 있게 되었다.
    HTTP/1.1 Multipart 규격으로 웹을 통한 파일 업로드가 가능하다. PHP 언어를 이용한 오픈소스 게시판, 웹하드 솔루션, 파일 공유 사이트가 등장하였다.
  • HTTP/1.1 Range Request는 응답 정보의 일부를 받을 수 있는 요청으로 이어받기라 한다. 서버에서 파일의 해당 시점부터 데이터를 전달하고, 요청한 브라우저에서 이전에 저장한 파일에 이어서 다운로드한다.
  • 오랫동안 웹은 브라우저에서 벗어나지 못하였다. HTML 출력에 의존하여 HTTP 프로토콜을 연동하였다.
  • 2007년 스마트폰의 등장으로 HTTP/1.1을 활용하기 시작한다. JSON, RESTful API 개념을 이용한다.

2. HTTP 프로토콜 1

  • HTML 문서와 이를 TCP/IP 규격위에서 송수신하기 위한 HTTP. 브라우저의 요청마다 연결을 맺고 끊어지는 비연결성을 보인다. 실시간 처리가 불가능하다.
  • Get의 인자는 Query이고 Post의 Payload 방식은 From data이다.
  • HTTP의 요청은 요청라인, 헤더정보, Payload 순으로 작성한다. 요청라인은 서버에서 특정동작을 하게 만드는 명령어이다. 헤더는 HTTP 요청과 응답에 대한 부과적인 정보를 전달한다.
  • 웹 서버는 TCP 규격에 따라 브라우저 요청에 대한 응답을 수행한다. 상태라인, 헤더저보, Payload 순으로 작성한다. 상태라인은 브라우저에게 처리결과를 알려주는 정보로, 처리결과의 코드와 명칭, HTTP 버전정보를 표기한다.
  • 브라우저는 웹 서버의 결과코드에 따라 동적응답, 정적응답, 에러응답으로 구분한다. 동적응답은 200 OK 이다. 정적응답은 304 Not Modified으로, 수정이 잘 일어나지 않는 요청에 대한 응답이며, 브라우저에서 해당 데이터를 일정 기간 동안 저장하는 캐싱 기능과 관련있다. 에러코드는 404 Not Found, 500 Interal Server Error로, 요청에 대해 웹 서버의 수행 불가를 전달한다.

1. TCP와 UDP

  • 인터넷은 자신의 식별변호가 공유되는 네트워크 환경에서 정보교환이 이루어지는 공간이다. 정보교환 방식은 TCP와 UDP이다. TCP 방식이 가장 많이 활용되고 UDP는 네트워크 노드정보 교환이나 미디어처리에 활용된다.
  • TCP는 컴퓨터 간 접속과 송수신이 보장되는 환경에서 진행되는 방식이다. 서버와 클라이언트 관계에서 세션 접속, 데이터 송수신, 세션 해제 순으로 진행된다.
  • 세션 접속은 클라이언트에서 SYN, SYN+ACK, ACK의 3 Way Handshake를 통해 정보교환이 가능한 상태가 된다. 양측에서 Data/ACK 순으로 송수신이 가능하다. 서버에서 클라이언트로 보내는 Data는 Push이다. 전송되는 데이터는 반드시 반대쪽에서 ACK 응답을 전송한다. ACK 응답이 없을 경우 대기시간이 누적되어 접속이 끊어진다.
  • 세션 해제는 FIN/ACK의 4 Way Handshake를 통해 양쪽에서 서로 교환하여 처리한다.
  • TCP에서 세션 해제 관리는 매우 중요하다. 클라이언트는 여러가지 이유로 비정상적인 세션 종료 현상이 자주 발생하는데 서버에서 그 종료를 인지하지 못해 원활한 TCP 진행이 불가능한 문제가 발생한다.
  • 클라이언트는 세션 접속 이후 일정 시간 주기의 더미 데이터를 전송하여 서버에 접속 유지 여부를 확인시킨다.
  • HTTP(HyperText Transfer Protocol)는 TCP 기반의 췝 처리 프로토콜이다. TCP 세션 접속을 하여 브라우저 요청을 하고 서버의 응답을 받으면 세션을 해제한다.
  • UDP(User Datagram Protocol)는 수신여부와 관계 없이 데이터를 전송한다. 정확한 송수신을 보장하지 않는다. 대용량의 데이터 전송이 가능하여 스트리밍, 인터넷 전화 등의 미디어 처리에 사용된다. 접속과 해제과정이 없는 비연결 방식으로 불특정 다수를 향해 데이터 전송이 가능하다. DNS(Domain Name Server)와 SNMP(Simple Network Management Protocol).
  • UDP 데이터 전송방식은 2가지로 특정 IP를 지정하여 데이터를 전송하는 Unicasting과 특정 그룹의 다수를 향해 데이터를 전송하는 Broadcasting이다.
  • UDP는 송수신측 모두 데이터를 읽어들이는 Receiver를 만들어야 한다.
  • UDP에는 SIP(Session Initiation Protocol) 규격이 있다. 컴퓨터 간의 실시간 음성/영상을 교환하기 위한 환경을 구축한다.

○ 개발묵상 (2024)

4. 개발자의 본질

  • 주변 의견. 코딩에 집착하는 개발자는 망한다. Java는 망하고 Python이 대세다.
  • 단기적인 결과물에 초점이 맞춰지는 사회 분위기가 있다. 개발자보다 주어진 환경과 시간 내에서 결과를 내는 코더를 요구한다. 회의감을 느낀 적이 있다.
  • 코딩 공부만 하고 문제를 직시하지 못하였다. 드러나는 문제를 인식하지 못하니 주어진 시간에도 문제를 해결하지 못한 것이다. 스스로 해결하지 못하였으므로 코더 취급 받는다는 회의감을 느꼈다.
  • 코딩으로 실력을 증명한다. 직접 코드를 작성하는 것만이 실력이 아니라 코딩 없이 설계 등으로 증명하는 개발자가 있다. 코딩은 사고와 설계의 도구이다.
  • 충분한 숙려기간이 필요하다. 최소 1년 코딩학습과 3년의 실무경험.
  • 상상력, 통찰력, 창의력
  • 기존 학습 방식은 언어기초를 배우고 프로젝트를 진행한다. 이제는 인공지능을 활용한다. 막연함을 확신으로 바꾸는 질문을 통한 코딩학습이 필요하다.
  • 학습안: 게시판 예제 - 언어학습 - 개인 프로젝트
  • 게시판은 결과를 알기 때문에 예제실행이 가능하다. 인터넷 환경의 개발흐름을 이해할 수 있다. 서버에서 HTML을 내려주는 방법과 데이터를 내려주는 방법을 모두 학습한다.
  • 질문예시: 만들어보고 싶어. 어떻게 추가해야 해? 예제를 알려줘.
  • 그 예시의 구조와 기술을 파악하기 위한 영속적 질문이 중요하다.
  • 언어문법은 ANSI-C에 기반한다. 파이썬 - 자바 - C 순서로 학습한다. 파이썬에서 입출력, 제어문, 반복문을 학습한다. 자바에서 구조화를 학습한다. C에서 메모리 제어를 학습한다.
  • 쇼핑몰과 같은 무거운 개인 프로젝트를 진행한다. 웹 기반 서비스에서 안드로이드, 플러터까지 구현한다.

1. 콘텐츠소개

  • 코딩, 수학, 전자에 대한 컨텐츠를 제공한다.
  • 입문 시리즈는 개발원리를 설명하여 코딩학습과 실무향상을 지원하는 역할을 한다.
  • 코딩강의는 데이터 제어에 중점을 둔다.

2. 백엔드

  • 주변에서 웹을 기준으로 백엔드를 인식한다. API로 프론트엔드와 연동하는 단순작업. 프레임워크 학습은 의미없다. 인공지능에 의해 대체된다.
  • 복잡한 구조가 아닌 아파치, PHP를 활용해 JSON, 웹 규격으로 충분히 앱을 지원할 수 있다는 이야기를 듣고 충격을 받는다. PHP는 2000년대 초부터 게시판만 개발하면 되는 쉬운 언어로 인식하였다. PHP로 앱서비스를 개발할 수 있다는 소식에 개발자의 가치가 이제 떨어졌다고 생각하였다.
  • 3계층 아키텍처에는 브라우저, 웹서버, 데이터베이스가 있다.
  • 웹개발에서 디자이너, 퍼블리셔, 시스템 엔지니어, 프런트 개발자가 빠져나가면 데이터 제어와 API 지원 기능을 담당하는 백엔드 개발자가 남는다.
  • 신규 개발된 서비스는 단순하고 분석없는 DB로 개발이 가능하다. 서비스가 성장하면 가입자수 증가, 동시접속자수 증가, 요구사항 증가로 DB의 개선을 고려해야 한다. Join 필요성 증가, 다양한 항목에 대한 검색, 사용자 분석과 추천 등이 요구된다. 장애, 간과했던 오류, 기능보완 등을 위해 백엔드 개발자가 필요하다. 인공지능만으로는 한계가 있다. 영업기밀에 관해 비개발자가 인공지능에게 질문을 통해 해결하는 것은 어려움이 있다.
  • 백엔드 개발자는 필요한 데이터를 관리하고 지원한다.
  • 웹의 한계에서 백엔드를 생각하면 곤란하다. CRUD 뿐만 아니라 크롤링 데이터 수집, 분석, 통계, 재가공, 검색 최적화 등 백엔드의 영역은 넓다.
  • 인공지능으로 업무 형태가 변할 뿐 오히려 백엔드 업무는 진화한다. 챗봇연동, 파인튜닝, 운영체제 커스터마이징이 등장할 것이다. 특정 도메인에 특화될 수도 있지만 백엔드 그 자체만으로 가치가 있다. 문제를 분석하고 해결하는 사람이 개발자이다.

3. 개발자의 권위

  • 코딩을 개발업무 그 자체로 오해하는 사람이 있다.
  • 특정 기술을 습득했다는 이유로 기술적 권력을 행사하는 사람이 있다. 자신이 최고이고 다른 기술을 천시한다. 개발경험을 갖고 타인에게 간섭하며 자신에게 유리하게 끌어간다. 대세를 따르며 유언비어를 퍼뜨린다. 연봉을 올리려는 시도로 이어진다.
  • 백엔드와 안드로이드 개발을 먼저하고 시장반응을 보고 iOS와 윈도우 개발을 시도한다.
  • 인공지능 뿐만 아니라 다른 기술에 의해 기존 시장의 변화는 불가피하다. 네이티브 앱 대신 하이브리드 앱을 개발하거나, 쉬운 언어로 쉽게 개발하려는 시도가 있다.
  • 인공지능으로 이해 개발자의 사회적 지위는 상승할 것이다. 사회적 문제를 해결하는 기회가 많아진다.
  • 개발자의 본래가치는 존재한다. 문제해결력, 설계 능력, 책임감이다.
  • 사회에서 AI 답변을 이용해 상대를 제압하려는 시도가 있다. AI 권위의 절대화로 사람들이 무지성으로 살게될 수 있다.

○ 웹개발입문 기초편 (2022)

1. 웹의 탄생과 원리

  • 웹은 인터넷의 일부이다. 인터넷은 IP 위에 TCP 프로토콜 스택을 쌓아 데이터를 전송한다. 네트워크 상 식별번호를 공유하고 정확한 데이터 송수신을 보장한다.
  • HTML 문서를 TCP/IP 규격 위에 송수신하기 위해 HTTP가 발표되고 World Wide Web(WWW)이 탄생한다.
  • 초기 프로토콜은 HTML 문서를 불러와 출력하는 정적인 기능만 하였다. URL은 도메인과 서버 내 문서경로로 구성된다.
  • CGI(Common Gateway Interface)는 웹서버와 외부 애플리케이션 사이를 연결하기 위한 규격이다. 1996년 HTTP/1.0가 발표되고 GET, POST 명령으로 인자값을 전달할 수 있는 규격이다. 데이터를 입력하고 검색할 수 있는 대화형 웹의 시대가 열렸다. 1995년 PHP 발표로 CGI가 대중화된다.
  • 1996년 MySQL 1.0이 발표되고 PHP 사용이 증가한다. PHP를 조립하는 과정에서 MySQL 데이터를 조회하여 HTML에 대입한다. 브라우저 - 웹서버 - 데이터베이스 연동을 3계층이라 한다.
  • 이후 다양한 언어가 등장하고 웹 애플리케이션 개념이 등장한다.
  • CGI가 발전하면서 HTML 조립을 넘어 여러 디바이스에 데이터를 공급하는 역할을 하게된다.
  • 2007년 스마트폰 시대가 열리며 모바일 애플리케이션 개념이 등장한다. 앱스토어를 통해 누구나 배포할 수 있어 앱개발은 대중화된다. 웹에 브라우저가 없는 웹 서비스를 요구하기 시작했고 RESTful API가 도입된다.
  • 1996년 CSS Level 1은 정적 디자인을 지원한다. 1997년 Level 2는 동적인 디자인을 지원하여 Dynamic HTML(DHTML)을 만들 수 있다. 2011년 Level 3는 반응형 웹을 지원한다.

2. 브라우저와 Javascript

  • 2014년 HTML5 등장으로 웹표준화 문제는 사라진다. 플래시 등 플러그인 기반 프로그램의 필요성을 없애고 최신기술을 도입하였다.
  • 자바스크립트는 브라우저의 화면을 제어하기 위해 고안되었다. ANSI C의 기본 문법을 바탕으로 한다. 1997년 ECMA-262 기술규격이 발표되고 여러 브라우저에서 자바스크립트를 사용하게 된다.
  • 오래전 웹은 브라우저에서 새로고침을 하여야 새로운 데이터를 가져올 수 있었다. 이를 해결하기 위해 화면에 IFRAME을 숨겨두는 방식을 활용하였다. 입력값을 자바스크립트가 인지하여 IFRAME에 관련 페이지 출력을 요청한다. 응답 받을 HTML 대신 자바스크립트 출력을 유도하여 해당 페이지에 실행 값을 전달한다. 마치 동적인 이벤트가 발생하는 효과를 가졌다.
  • Asynchronous Javascript and XML(AJAX)는 브라우저의 모듈 XMLHttpRequest 객체를 이용하여, 전체가 아닌 일부 페이지만을 위한 데이터를 불러온다. 자바스크립트 기술만으로 실시간 데이터를 가져온다. Web 2.0와 함께 대중화된다. 검색어 자동완성, 태그 클라우드, UCC가 대표적이다. 브라우저의 HTML 문서 출력 후 자바스크립트의 실행으로 화면의 흐름이 끊어지는 문제가 해결된다.

3. Javascript Framework

  • 2006년 JQuery 라이브러리가 등장한다. 이때까지 여러 브라우저에 대한 자바스크립트의 표준화가 없었다. 시장을 독점하고 있는 인터넷 익스플로러는 JScript를 고집하고 있었다. JQuery는 여러 브라우저의 비표준적 문제에도 작동하여 DHTML과 Ajax를 쉽게 구현할 수 있었다. JQuery Plugin은 특정 태그에 대한 기능과 효과를 빠르게 추가할 수 있다.
  • 브라우저는 웹서버를 통해 HTML 문서를 불러와 출력하고 문서 내 정의된 자바스크립트를 불러온다. 브라우저마다 각자의 엔진 모듈로 자바스크립트를 해석하고 실행하는데 차이가 있었다.
  • 2008년 구글 크롬의 시장 점유율이 높아지고 2009년 ECMAScript5가 발표되면서 표준화가 되었다. 각 브라우저는 ECMAScript5 권고안에 따라 자바스크립트 엔진을 개발한다. 크롬의 V8 엔진은 Node.js 탄생의 기반이 된다. 이후 Node.js 기반 자바스크립트 프레임워크 기능이 등장하고, 자바스크립트만으로 데스크탑 애플리케이션 개발이 가능해진다.
  • Single Page Application(SPA)은 웹페이지 간의 연속적인 간섭을 막는다. 사용자의 동작에 반응하여 적절한 자원을 서버에서 가져와 웹페이지에 동적으로 추가한다. 이때부터 자바스크립트 프레임워크 개념이 등장하고 이후 Angular, React, Vue가 만들어진다. 프레임워크는 구현체가 직접 제어하는 방식이 아닌, MVC 패턴 구조에 의해 구현체가 작동되는 방식이다.
  • MVC는 Server-Side Rendering(SSR)에서 사용하던 방법이었다. 한 개의 페이지에서 다양한 기능을 처리하는 SPA 개발 요구가 늘어남에 따라 MVC 패턴에 의한 자바스크립트 프레임워크 개념이 등장한다. 웹 애플리케이션이 데스크탑 애플리케이션과 같이 작동하도록 한 노력의 결과이다.
  • Angular는 Model-View-Controller(MVC)를 기반으로 별도의 자바스크립트 구현없이 화면이나 관리 데이터가 실시간으로 일치하도록 지원한다. Controller에서 데이터를 준비하고 HTML 문서를 제어한다. 이후 React와 Vue가 등장한다. 자바스크립트가 HTML 태그를 지명하고 제어하는 방식에서 HTML 태그가 자바스크립트의 특정기능을 지명하여 이벤트를 결정하는 방식으로 발상을 전환하였다.
  • 자바스크립트는 브라우저에서 기능을 실행시킬 수 있는 유일한 언어이다. ActiveX가 퇴출되면서 제약이 많은 브라우저의 환경개선을 자바스크립트가 맡고 있다. 이때부터 자바스크립트 언어로 컴파일하는 개념과 함께 TypeScript와 WebAssembly이 등장한다.
  • 자바스크립트는 불확실한 인자타입으로 인해 런타임 오류로 발생하여 개발 공수가 늘어나는 문제가 있는데, TypeScript는 타입을 정의하고 컴파일을 통해 문제를 미리 예방한다.
  • WebAssembly는 일반 애플리케이션의 바이너리를 텍스트 어셈블리어로 변환시켜 해당 프로그램과 브라우저간 인터페이스를 지원하여 실행시킬 수 있는 이진 코드 포맷을 정의하는 개방형 표준이다. 일반 애플리케이션이 브라우저 상에서 작동하도록 돕는다.
  • 프런트엔드 변천사의 방향은 서버로부터의 독립과 브라우저 제약사항의 극복이다.

4. 웹개발

  • 웹 서버 시스템은 웹과 웹 애플리케이션을 작동시키기 위한 소프트웨어 구조이다.
  • Web Server는 HTTP 요청에 따라 정적파일을 제공할지, CGI 규격에 따른 웹 애플리케이션 처리가 필요한 것인지 분기처리한다. 대표적으로 Apache HTTP와 Nginx를 사용한다.
  • Web Application Server(WAS)는 HTTP와 CGI 규격에 맞춰 실행되는 서버 프로그램의 개발 개념이다. 웹 서버를 통해 들어오는 데이터를 처리한다. CGI 처리는 서브 프로세스를 실행하는 모듈방식과 WAS에 HTTP 전달로 처리하는 방식이 있다. 모듈방식은 대표적으로 PHP를 사용한다. WAS는 대표적으로 Java의 Servlet, Python의 Django, Node.js, Tomcat를 사용한다.
  • WAS는 웹서버 없이 실행이 가능하지만, 정적파일을 웹서버에서 처리하도록 하거나 다수의 WAS를 분기처리하기 위해 웹서버와 연동한다.
  • Web Application은 요청값 분석과 분기처리를 하여 데이터처리 과정을 거치고, HTML 문서조립 혹은 JSON/XML을 생성하여 응답한다.
  • PHP와 MySQL 조합으로 HTML 문서를 조립하면서 일련의 과정을 수행하는 개발이 진행되는데 문서의 출력 순서에 따라 데이터처리를 한다. Model 1 개발기법으로, PHP, ASP, JSP에서 주로 사용한다.
  • 요청을 분기하고, 데이터를 처리하고, 결과를 생성하는 방식은 Model 2 개발방법 또는 MVC 모델이다. Model은 데이터 처리 및 입력과 출력 값을 규격화 하는 역할이다. View는 Model에서 처리된 결과값으로 화면에 출력한다. Controller는 외부 요청에 따라 Model과 View를 제어한다. 초기 설계나 개발 구축에 많은 시간이 소요되지만 재사용 및 기능수정에 빠른 대응이 가능하다.
  • Server Side Rendering(SSR)은 웹 애플리케이션에서 데이터를 처리하여 화면에 출력하기 위해 HTML 문서를 만든다. SSR을 효율적으로 처리하기 위한 Template, Decorator, Taglibrary이 있다.
  • Model 1는 HTML문서를 조립하는 과정에서 데이터를 조회하거나 처리하는 과정이 섞여 있으므로 최종적으로 프로그램을 실행하여야 결과물을 확인할 수 있다. 그리고 데이터를 처리하고 결과를 반영하여 웹을 구현하는 과정에서 여러 파일을 사용하여 처리하는 비효율적인 문제가 있다. 이를 개선하는 방안으로 데이터 처리를 위한 Model과 요청을 분기하기 위한 Controller가 등장한다.
  • Inversion of Control(IoC)는 제어의 역전으로, 기능 호출을 내부가 아닌 http 요청과 같은 외부요인에 의해 결정하는 방법이다. Controller가 해당된다. Java의 Spring MVC, PHP의 Larabel, Node.js의 Router, Python의 Flask가 있다.
  • Dependency Injection(DI)는 MVC 모델 각각의 요소에서 개발된 모듈의 연계를 위한 조건을 효율적으로 대입하기 위한 방법이다. Java의 SpringBoot가 대표적이다.
  • Persistence는 영속성으로, 데이터베이스와 연동하는 과정에서 발생하는 데이터 구조를 효율적으로 운영하기 위한 개념이다. 쿼리문과 함수를 매핑시키는 방법과 데이터베이스의 데이터 구조와 메모리 구조를 매핑시켜 처리하는 방법이 있다. 대표적으로 MyBatis와 Hibernate가 있다.
  • Model과 Controller 영역에 대한 비중이 높아지고 있고, 프런트엔드 개발 기술이 발전하면서 SSR 처리는 사라지고 있다.
  • HTTP/1.1만으로 파일전송과 채팅은 불가능했다. 각자의 방법으로 메시지 규격을 지정하여 개발해야 했다. 서버를 자체 개발하고 동시접근, 메시지 분석, 업무 수행, 데이터 처리까지 각자의 방식으로 개발하였다.

5. Backend의 역할

  • 웹 애플리케이션과 서버 애플리케이션은 공통적으로 사용할 수 있는 범용 메시지 규격이 필요했다. eXtensible Markup Language(XML)과 JSON이 등장한다.
  • 1998년 W3C는 XML를 발표하는데 데이터를 저장하고 전달한다. 2003년 XML과 RPC 개발패턴을 기반으로 Simple Object Access Protocol(SOAP)이 탄생한다. 웹을 통하여 XML 문서가 오가는 규격에서 서버와 클라이언트 코드에서는 객체의 메소드가 호출되는 것처럼 보이게 한다. 아쉽게도 MS에서만 활용하고 있다. XML은 다양한 데이터 구조를 표현하기 쉬운 구조이지만 XSD 스키마를 사용해야 정확히 사용이 가능하므로 쉬운 접근이 아니다.
  • 2000년 JavaScript Object Notation(JSON)이 등장한다. 키와 값의 쌍으로 이루어진 메모리 상의 데이터 객체를 문자열로 나타낸다. 다양한 자료구조를 가시적으로 표현할 수 있다. 스키마 없이 단순하게 사용이 가능하다. 여러 언어가 JSON과 호환되는 기능과 라이브러리를 지원한다. 단순한 규칙으로 다양한 구조의 데이터를 만들어 낼 수 있다. 문서 기반 데이터베이스 등장에 영향을 주었다.
  • XML과 JSON을 활용하면서 다양한 장치에서 처리할 수 있게 되었고, 화면구성과 관련된 응답 처리에 큰 영향을 주었다. 그러나 요청 규격에는 영향을 주지 못하였다.
  • 다양한 장치가 등장하고 웹에 대한 요구가 늘어나면서 서비스에 대한 규모가 거대해지기 시작한다. 시스템 구성이 분리되고, 요청수가 늘어나면서 장치에서 서비스로 접근하는 난이도가 높아졌다.
  • 2000년 Representational State Transfer(REST)를 발표한다. HTTP 규격이 아니라 분산 처리를 위한 설계 원칙이다. 웹 요청 URI에서 고유한 자원을 식별하고, 자원의 CRUD 과정을 HTTP 메소드를 통해 자원을 처리한다. REST 설계원칙을 준수하여 개발한 웹 애플리케이션은 RESTful API이다. 이것이 웹 서비스에 활용되기 시작한다. 웹 서비스는 네트워크 상에서 서로 다른 시스템이 상호작용하기 위한 방법으로 서비스 지향적 분산 처리 기술이다. RESTful은 웹 서비스 구현에서 XML/JSON 메시지 구조를 활용해 매우 쉽게 접근할 수 있다. 웹 API는 시스템과 여러 장치 연동에 활용된다.
  • OpenAPI는 공개된 웹 서비스이다. 인증키를 부여하여 서비스 개발에 필요한 자료를 웹을 통해 제공받을 수 있다. RESTful 설계방식을 따르므로 연동을 위해 RESTful 설계방식을 이해해야 한다.
  • 스마트폰과 SNS 등장 이후 웹 애플리케이션과 서버 애플리케이션의 장벽이 허물어지고 백엔드의 역할이 부각된다. 웹 브라우저의 응답방식을 벗어나 다양한 응답처리가 필요했고, 많은 양의 데이터 처리가 요구되었다. JSON 규격과 RESTful API 기법을 활용하여 웹 애플리케이션 개발만으로 모바일 애플리케이션을 개발하는 것이 가능해졌다. 모바일을 위한 별도 서버 개발이 불필요해진 것이다. 직관적인 서비스 접근과 쉬운 응답값 분석으로 빠른 개발이 가능해졌다.
  • 한 전자책 업체는 서비스를 PHP와 MySQL을 이용해 빠르게 개발하고 제공하여 시장을 장악하였다.
  • 스마트폰과 SNS 등장 이후 요구되는 적절한 언어의 선택, 동시 접속자 분산, 대용량 데이터처리 등의 문제는 백엔드가 풀어야 할 문제이다.
  • 웹 초기 PHP, ASP, JSP 스크립트 언어가 많이 사용되었다. 성능 개선을 위해 컴파일 언어로 전환되었다. 많은 IT 스타트업은 개발 지식보다 아이디어만으로 시작한 사례가 대부분이었고 스크립트 언어로 개발을 시작해 서비스를 제공하였다. 이후 사용자 증가에 따른 서비스의 가능성을 확인하고 컴파일 언어로 전환하여 안정적인 플랫폼으로 만든다.
  • 사용자의 증가는 분산처리를 필요로 한다. 이중화 기술을 적용하여, 사용자의 요청을 L4 스위치와 같은 특정 장비를 통해 여러 서버에 분산처리하고, 사용자는 한 개의 서버로 처리된 것처럼 보이게 한다.
  • 사용자의 증가로 데이터 양이 기하급수적으로 늘어나 저장 공간의 물리적인 한계와 데이터 조회 성능 저하의 문제가 발생한다. 수직확장은 비용 문제가 따른다. 2010년 이후 NoSQL과 관련된 Memcached, Hadoop, Mongodb 오픈소스 플랫폼을 활용하기 시작하여 관계형 데이터 구조의 제약조건으로 발생되는 문제를 보완하였다. 성능을 높이기 보다 장비를 추가하여 보완하는 수평확장이 가능해졌다.
  • 백엔드는 거대해지더라도 높은 성능과 다양한 기능제공을 하는데 목적을 둔다. 여러 서버를 구축하여 운영하고 데이터베이스 구현을 직접 처리하는 것이 일반적이다.
  • 웹 역사의 흐름에서 파생된 역할은 모두 백엔드로부터 시작되었다.

6. Database와 NoSQL

  • 데이터베이스 역사는 인터넷보다 오래되었다. 1996년 MySQL 등장으로 인터넷 환경에서 데이터베이스가 대중화되었다.
  • 2-Tier 연동구조는 데이터베이스가 설치된 대형 컴퓨터에 프로그래밍 설치된 컴퓨터가 접근하여 사용한다. 인터넷의 발달로 서버에 부하가 걸리고 해킹의 취약점이 나타나 3-Tier 구조로 발전한다.
  • 관계형 데이터베이스는 관계형 모델과 트랜잭션 기능으로 구성되어 인터넷 환경에서 필수적인 기능을 제공한다.
  • 데이터 양이 늘어나면서 분류와 검색기능이 요구되었고, 저장정보의 중복을 최소화하고 실시간으로 그 변화를 반영하는 장치가 필요했다. 관계형 모델은 키와 값의 관계를 Column과 Row의 개념으로 테이블화하고, Row 데이터를 다른 테이블과 연관시켜 데이터를 관리한다. 대용량 데이터를 두 개 이상의 테이블로 분리하고 연관시켜 중복된 데이터를 없애고, 최소한의 데이터 수정으로 실시간 정보를 제공할 수 있게 되었다.
  • 인터넷은 수많은 사용자가 조회와 저장을 동시에 처리하는 환경으로, 데이터를 정확하게 유지하고 제공해야 한다. 트랜잭션은 하나 이상의 작업을 수행하기 위해 필요한 데이터베이스 연산을 모아 처리하는 단위이다. 처리 중 문제가 발생하면 복원하는 역할을 한다.
  • 2000년 인터넷 동창회 서비스 다모임. 대기업의 투자나 개입 없이 소규모 자본으로 데이터베이스를 활용한 서비스를 구축하였다.
  • SQL은 1986년 ANSI에 의해 표준화되어 다수 데이터베이스에서 공통으로 사용하는 언어이다. 테이블 구조를 생성하고 편집하는 DDL, 테이블 내 데이터를 조작하는 DML, 데이터의 접근을 제어하는 DCL이 있다.
  • API 설계 시 데이터베이스와 연동하여 개발하므로 데이터베이스 구조에 맞춰 설계하는 것이 일반적이다.
  • 여러 SQL문 실행을 통해 데이터를 조작한 후 Commit 처리되어 영구저장되고, Rollback 처리되어 이전의 Commit 상태로 복원한다. Commit과 Rollback은 접속된 세션 별로 진행된 데이터베이스 명령어를 다른 세션에서도 조회할 수 있는지를 최종적으로 결정해주는 기능이다.
  • 개발단계에서 SQL의 DML을 사용하기 위해 인터넷 상에서 데이터베이스 접속을 유지한 상태에서 진행해야 한다. TCP/IP는 세션에 대한 접속 및 해제의 과정에서 많은 부하가 생겨나 실시간 데이터 처리에 영향을 미치는 문제가 있다. 이를 해결하기 위해 데이터베이스 접속 세션을 여러 개 생성하여 SQL문을 지연 없이 실행시키는 Database Connection Pool(DBCP) 라이브러리를 이용하여 연동한다. 일정개수의 데이터베이스 접속 세션을 미리 생성하여 SQL 요청 시 세션을 주고, 실행 후 완료되면 돌려받는다.
  • 인터넷 서비스는 검색을 넘어 추천하는 기능을 요구하는데 이때 관계형 데이터베이스는 한계를 드러냈다. 추천은 사용자의 패턴을 분석하여 원하는 정보를 자동으로 검색하는 기능이다. 데이터의 연산 결과를 일시적으로 저장하고 제공하는 Memcached와 Redis 캐싱서버가 등장하였지만 실시간으로 데이터가 반영이 되지 않는 문제가 있었다. 추천을 구현하기 위해 관계형 데이터베이스의 연산결과를 캐싱하면서 실시간 반영할 수 있어야 한다.
  • NoSQL은 JSON 형식의 다차원적인 구조로 관리하는 문서 기반 데이터베이스이다. 대용량 문서를 빠르게 저장하는 MongoDB와 별도 제약 없이 대용량 검색이 가능한 ElasticSEarch가 있다. 관계형 데이터베이스의 트랜잭션 기능을 없애 문서를 빠르게 등록하고 제공한다. 분산처리할 수 있는 수평확장을 지원한다. 그러나 트랜잭션 기능이 없어 데이터 정확도에 대한 안정성이 떨어진다. 따라서 웹 개발에서 관계형 데이터베이스를 주로 사용하고, 로그를 수집하여 통계를 추출하거나 검색속도를 높이기 위해 NoSQL을 보조로 사용하는 것이 일반적이다.

7. 웹 개발 업무

  • 웹 개발은 브라우저 출력을 처리하는 프런트엔드, 데이터를 처리하고 지원하는 백엔드, 데이터를 관리하는 데이터베이스가 인터넷 네트워크 망을 통해 데이터를 주고 받는 관계를 이룬다.
  • HTML/CSS는 현업에서 디자니어가 주가 되어 작업한다. 초창기 웹 개발은 디자이너의 작업 결과물을 개발자가 받아 HTML/CSS로 변환하여 웹에 적용하였다. 디자이너의 의도가 반영되지 않는 문제가 발생하여 디자이너가 직접 개발에 참여하였다. 업무가 분산되어 HTML/CSS를 전문으로 하는 퍼블리셔가 등장하고, 자바스크립트 개발에 개입하기 시작하면서 프런트엔드 개발자가 등장하였다.
  • 프런트엔드 개발이 전문화되면서 웹 디자인에 대한 규격화된 라이브러리가 등장한다. Fontawesome, Bootstrap은 웹 화면에 필요한 디자인을 HTML/CSS로 규격화하여 디자이너 도움 없이 구현할 수 있게 한다.
  • 백엔드 개발자의 전신인 웹 개발자는 CGI 기반 기술을 이용하여 조회된 데이터를 HTML 문서로 조립하는 SSR 처리 방식으로 개발하였다. 웹 개발자가 최종적으로 검토하는 구조이다. 그러나 AJAX와 JSON의 등장으로 개발역역이 분리되기 시작한다. 자바스크립트에 대한 라이브러리, 프레임워크, 브라운저 엔진의 개선으로 브라우저에 대한 표준화가 이루어지고 Node.js가 떠오르면서 본격적으로 프런트엔드 개발자가 등장한다. Electron, Inoic을 이용하여 모바일 앱까지 개발할 수 있게 되었다.
  • 백엔드는 요청을 접수하는 웹 서버와 이를 처리하는 웹 애플리케이션으로 나뉜다. 애플리케이션의 개발 언어에 따라 웹 서버의 구성과 개발 과정이 달라진다.
  • 스크립트 언어는 웹 서버에 의존하여 쉽고 빠른 개발이 가능하다. 복잡하고 거대한 서비스에서 유지보수가 어렵다. 쉬운 배포를 위한 게시판/쇼핑몰 개발에 활용된다.
  • 컴파일러 언어는 복합한 구조와 작업 공정을 거치지만 안정적인 실행이 가능하다. 스크립트 언어는 컴파일러 언어는 WebLogic, Jeus, Tomcat 같은 별도의 Web Application Server(WAS)를 사용한다. WAS는 단독으로 사용할 수 있으나 자원 분산의 효율성을 고려해 웹 서버와 연동하는 것이 일반적이다. 컴파일러 환경에서 유연한 대응을 하기 위한 방안으로 데이터처리와 결과 출력을 분리하는 MVC 개발 패턴을 적용한다. 초기 구축이 어렵지만 유지보수와 재생산 개발이 용이하다. Java의 JSP, C#의 ASPX는 유연한 화면구현이 가능한 템플릿 기능을 제공한다. 이후 Spring, Flask, Express 같은 MVC 웹 프레임워크가 등장한다.
  • 스크립트 언어 Python과 Node.js가 등장하고 자체 WAS를 구축하여 Nginx 웹 서버와 연동한다. Node.js는 파일이나 네트워크 소켓의 지연문제를 쉽게 처리해 채팅과 같은 실시간 공유에 활용된다.
  • 백엔드의 데이터베이스 연동은 데이터 처리에서 가장 큰 비중을 차지한다. 초기 문자열 변수에 SQL 구문을 작성하여 전달하였고 백엔드 구현에 집중하기 어려웠다. SQL 구문을 대문자로 작성해 가독성을 높이거나, 별도 클래스 또는 설정파일로 분리하는 시도를 했지만 근본적인 해결은 되지 않았다. Persistence 라이브러리가 이를 해결한다. MyBatis, Hibernate, Sequelize, SQLAlchemy는 데이터베이스를 연동하는 SQL 언어를 자동으로 생성하거나 별도 설정파일을 통해 관리한다.
  • 모바일 애플리케이션가 증가하면서 백엔드는 RESTful API 지원이 늘어났다. 백엔드의 SSR 처리 기능은 사라질 듯 했으나 서비스의 기능이 많아지고 잦은 업데이트가 발생하면서 앱 사용률이 떨어지는 현상이 나타났다. 업데이트를 줄이기 위해 내부를 웹으로 출력하는 하이브리드 앱이 등장하였다.
  • SQL 공통언어가 있어 데이터베이스 선정은 웹 개발에 큰 영향을 주지 않는다. 데이터를 어떻게 관리하는가, 즉 데이터 튜닝의 문제가 있다. 튜닝은 백엔드의 웹서비스에 영향을 주지 않으면서 테이블의 인덱스 설정 및 물리적 데이터 구조를 수정하고 물리적인 서버자원을 최적화하여 데이터베이스를 구동시킨다. 오라클 데이터베이스가 튜닝에 대한 풍부한 기능을 제공하여 기업에서 선호한다. 튜닝은 고비용 작업이지만 대용량 데이터 처리 장애를 줄인다.
  • 2008년 MySQL 5.1 출시로 관계형 데이터 처리가 가능해지고, MariaDB, PostgreSQL와 함께 오라클의 대안이 되었다.
  • NoSQL은 문서기반 데이터로 저장하여 기존 RDB만으로 불가능한 일을 처리하는 보조수단이 되었다. Redis는 이중화된 서버간 데이터를 공유하고 실시간 메시징 처리를 구현한다. MongoDB는 IoT 기기의 상태 정보를 수집한다. ElasticSearch는 검색 및 추천 서비스에 사용된다. 다만 트랜잭션 기능이 없어 데이터 관리에 대한 보장을 받지 못한다.
  • 백엔드는 RDBMS를 기반으로 데이터구조를 설계하여 구현하고, 구현된 데이터의 흐름을 파악하여 보조적으로 합당한 NoSQL을 선택한다.
profile
한백년
이전 포스트

SCODE 박재성

다음 포스트

양동준 Yang DongJun

0개의 댓글