11월 6일 학습 일지

11월 6일

오늘 공부에 투자한 순수한 시간: 5시간 30분

학습한 개념 : 프론트엔드

<프론트엔드>

1. 포론트엔드는 Front-end로 영어로는 앞쪽 끝이라는 뜻이다. 즉 사용자가 눈으로 보고 직접 만지는 부분을 프론트엔드라고 이야기 하는데 대표적으로는 웹 브라우저 안에서 사용되고 있다.

프론트엔드를 알기 위한 핵심은 4가지가 있는데

① 웹 프론트엔드의 3가지 기술

- HTML: 화면의 구조와 내용

- CSS(Cascading Style Sheets): 색상이나 크기, 배치 같이 화면을 꾸미는 언어이며 이는 화면의 디자인을 구상한다.

- JavaScript(자바스크립트): 화면이 클릭에 반응해서 움직이게 하는 프로그래밍 언어이며 이는 화면의 동작을 이르킨다

② 프론트 엔드가 맡는 일에는

1. UI(User Interface)을 만든다. (사용자가 화면에서 마주하는 버튼이나 입력창등의 모양을 만든다)

2. UX(User Experience)을 사용자에 맞춰서 개선한다. (사용자가 사용하면서 쓰기 편하게 만들고 개선해준다.)

3. 서버에 요청을 하고 서버에서 받은 데이터를 화면에서 보일 수 있도록 한다.

4. 입력값이 올바른지 1차로 확인해줘야한다. (예를들어서 이메일칸에 @가 온전히 잘 들어갔는지 확인하는 과정)

③ 프론트엔드는 코드가 사용자의 브라우저로 내려와서 사용자의 컴퓨터에서 돌아갈 수 있도록 하는데 그래서 반응은 빠르지만 사용자가 읽거나 확인하면 안되는 중요한 비밀이나 최종 검증은 백엔드가 맡아서 해야한다.

④ 화면 크기를 많은 기기에 맞춰서 구상해야 하는데 어느 기기를 사용하여도 잘 보이도록 해주는 '반응형 디자인'이 중요하다.

프론트엔드의 배경으로는 웹이 커지면서 화면을 담당하는 부분과 처리를 담당하는 부분으로 나누어 쓰이고 있다.

ㄴ백엔드를 서버라고 이야기 했는데 그럼 프론트엔드는 클라이언트라고 생각해도 돼?

거의 맞지만 바라보는 관점은 명확하게 갈린다.

클라이언트와 서버 - 요청과 응답을 하는 통신의 역할을 함

프론트엔드와 백엔드 - 개발에 사용되는 역할을 함

2. 프론트엔드는 누군가 발명한 기술이 아닌 웹이 커지며서 화면을 만드는 일이 따로 분리되면서 자리 잡은 기술이다.

1990~1993년도 - 팀 버너스리가 HTML과 첫 브라우저를 만들고 1993년 모자이크(이미지와 글을 한번에 보여주는 대중적인 최초의 브라우저)의 등장. 이 당시에는 문서를 보여주는 것이 전부였고, 화면을 담당하는 작업은 없었음

1995년도 - 브레덴 아이크가 넷스케이프(초기 대표 브라우저 회사)에서 10일만에 JavaScript를 만듦. 처음에는 Mocha였고, 클릭에 반응 하는것이 목적으로 만들게 되었음

1994~1996년도 - 하콘 비움 리가 1994년 CSS를 제안했으며 1996년에는 W3C라는 웹 표준을 관리하는 단체에서 CSS1이 공식 표준 추천 문서로 나오게 됨. CSS의 핵심은 내용(HTML)과 모양(CSS)를 분리하는 것이 초점으로 시작되게 됨

2000년대 - Ajax 즉 페이지를 새로고침하지 않아도 필요한 데이터만 받아서 화면에 바로 적용 시키는 기술로 gmail과 구글 지도로 알려지게 됨 2005년에 용어가 확산되게 됨

jQuery 즉 자바스크립트를 쉽게 사용할 수 있게 하는 도구가 2006년 생겨나게 되었으며 널리 사용되게 되었고 2008년에는 Chrome이 등장.

2010년~현재 - 화면을 체계적으로 만들게 도와주는 개발 도구인 라이브러리와 프레임워크가 생겨남. 복잡한 앱 수준의 화면을 만드는 프론트엔드 개발자가 독립적인 직군으로 자리 잡았음. 모바일 기기가 확산되면서 반응형 디자인도 많이 중요하게 됨

왜 만들어 졌는가?

1. 정적으로 읽기만 해야만했던 정적이던 문서를 조금 더 생동감 있게 만들기 위해서

2. 내용과 디자인을 구분하기 위해서

3. 화면의 일부를 바꿀때마다 서버를 왔다갔다 해야하여 오래 걸리던 대기 시간을 줄이기 위해서

4. 설치 없이 브라우저만으로도 많은 화면을 제공하기 위해서

5. 화면이 커지면서 코드가 엉키는 문제를 프레임워크를 사용해서 체계적으로 관리하기 위해서

ㄴ프레임워크/라이브러리의 차이가 뭐야?

라이브러리 - 필요한 기능을 모아 둔 도구 상자이며 흐름의 주도권이 나에게 있어 내가 원할때 골라서 사용함

프레임워크 - 앱의 뼈대와 규칙을 미리 갖춰둔 틀이며 내가 정한 규칙대로 내가 코드를 끼워넣으면 틀이 나를 직접 호출하는 것이며, 흐름의 주도권이 틀에게 있음

핵심적인 차이

1. 라이브러리는 내 코드가 라이브러리를 찾고, 프레임워크는 프레임워크가 나를 부름

2. 라이브러리는 자유롭지만 구조 자체를 내가 직접 짜야하고 프레임워크는 구조가 정해져 있어서 팀원들의 코드가 비슷하고 협업이 쉬움

3. 라이브러리는 특정 기능 하나에 집중하는데 프레임워크는 앱 천체(구조, 라우팅(주소에 따라 보여줄 화면을 정하는 것), 상태 관리 (데이터 변화를 화면에 반영하는 관리)등을 활용함

4. 프레임워크는 규칙을 익혀야하며 나중에 다른 것으로 갈아타는 것이 어렵고 라이브러리는 그에 비해서 부분적으로 교체 할 수 있음.

3. 프론트엔드가 나오기 이전에 불편함으로는

1. 웹이 글이 주로 사용된 정적인 문서라서 버튼을 누르거나 입력값을 즉시 확인할 수 있게 하는 기능이 없었음

2. 작은 부분을 수정/변화를 하려고 해도 서버에 요청해서 웹 페이지를 처음부터 다시 받아야 했다.

3. 내용과 디자인이 서로 섞여 꾸미기 어려웠는데 이전에 HTML에는 글자 크기나 색상을 바꾸기 위해서는 <font>같은 태그를 직접 섞어서 수정해야 해서 디자인을 바꾸기 위해서는 모든 페이지를 하나하나 일일이 수정해야 하는 버거움이 있었고, 세밀한 배치는 꼼수를 부려 어렵게 수정해야 했음

4. 입력 양식(폼)에 잘 못 적어도 먼저 제출하고 서버에서 돌려 줬을때 확인 할 수 있었다. 단순한 실수도 지속적으로 왕복 해야 했음

5. 각 브라우저마다 화면이 다르거나 깨져서 나오는 문제가 있어 브라우저별로 각 따로 만들어야 하는 수고가 있었음

4. 프론트엔드가 나오고 난 이후 편리해진 부분으로는

1. 읽기만 가능했던 문서가 이제는 JavaScript를 사용하여 사용자와 상호작용이 가능해짐

2. Ajax와 프레임워크 덕분에 작은 변화에도 서버를 왔다갔다 해야하는 문제점을 바로 잡고, 이젠 웹 안에서 자연스러운 움직임이 가능해졌으며 서버도 부담이 줄었음

3. 이전에는 입력에 오류가 있었으면 서버에서 받아서 확인 할 수 있었는데 프론트엔드가 생기고 서버로 보내기 이전에 문제점을 먼저 확인이 가능해짐

4. 글자 크기나 색상을 태그에 섞어야해서 디자인을 수정하는데 어려움이 있었지만, CSS로 디자인, 모양 부분을 파일 한 곳에서 수정해도 웹 사이트의 전체 디자인이 수정되었고, 반응형 디자인도 가능하게 되었음

5. 이전에는 사용하는 브라우저마다 각각 수정해야 했지만 이제는 웹 표준(브라우저들이 공통으로 따르는 규칙)이 자리를 잡으면서 프레임워크와 라이브러리가 호환 문제를 흡수하게 되었고 복잡한 화면도 컴포넌트 즉 재사용할 수 있는 화면 부품을 단위로 나누게 되면서 팀이 다 같이 만들 수 있게 되었음. 마지막으로 설치 없이 브라우저만으로도 웹 앱을 사용할 수 있어짐

문제점: 프론트엔드의 도구가 빨리 전환되면서 배워야하는 부분도 많아지고, 코드가 사용자 기기에서 돌아가니 초기 로딩이 오래걸리게 되며 보안상 중요한 문제는 백엔드가 맡아서 해야한다.

5. 이 후 기존의 불편함을 어떻게 해결했는가?

1. 정적인 화면에서 상호작용으로 변하게 되면서 더욱 풍부한 활용을 할 수 있게 되었다. 사용자가 클릭하는 행위 자체를 이벤트로 보고 거기에 맞춰서 반응하게 됨

2. 기존에는 작은 화면을 바꾸기 위해서 서버에 요청을 하고 응답을 받아야 했는데 프론트엔드가 생긴 이 후에는 HTTP의 요청을 JavaScript가 먼저 확인하고 받은 JSON으로 화면 일부만 바꾸게 되었는데 이는 Ajax의 원리

3. 또 사용자가 입력한 결과는 JavaScript가 먼저 확인하여 값을 검사하는데 이러하여서 불필요한 서버와의 연결을 줄여줌

4. 내용·동작·모양으로 3가지로 나눠서 처리하는데 HTTP는 구조의 내용, CSS는 사이트 전체의 디자인, JavaScrip는 동작의 역할을 하게 되고 CSS는 반응형 디자인으로 어떤 기기도 옮겨지더라도 올바르게 작용할 수 있도록 처리해줌

5. 표준과 도구로 기존에 있었던 호환성과 복잡성을 해결하게 되었음

- 웹 표준(W3C나 WHATWG가 관리하는 공통 규칙)을 브라우저들도 따르게 하여 같은 코드가 어느 브라우저로 가던지 모두 통일되게 됨

- 프레임워크와 라이브러리가 브라우저에 남은 다른 부분을 대신 처리하여 개발자는 그것을 직접 신경쓰지 않아도 됨

- 빌드 도구(여러 파일을 합치고 최신 문법을 구형 브라우저용으로 변환해 주는 도구)가 개발과 배포를 자동으로 하기 시작함

ㄴ 프레임워크/라이브러리가 남은 차이를 흡수한다는게 무슨 뜻이야?

프레임워크와 라이브러리가 브라우저에 남은 다른 부분을 대신 처리하여 개발자는 그것을 직접 신경쓰지 않아도 된다는 뜻이다.

<백엔드>

1. 백엔드는 Back-end라는 영어로 '뒤쪽 끝'이라는 뜻이다. 프론트엔드의 반대말이기도 하다. 사용자가 직접 확인하고 작업하고 사용하는 쪽이 앞(front), 사용자가 보이지 않는 뒤쪽 공간에서 일하는 쪽이 뒤(back)이기 때문에 서로 반대되는 말이다

백엔드도 알기 위한 핵심은 4가지가 있는데

① 앞에서 설명한 백엔드와 프론트엔드는 물리적인 거리가 아닌 사용자와의 거리이다. 사용자가 직접 보느냐 못 보느냐로 나눈 이름이다.

② 백엔드가 하는 일로는 5가지가 있는데

1. 비지니스 로직(서비스의 규칙과 처리방식) - 예를 들어 주문이 들어왔을때 재고가 있는지 확인을 하고 결제하는 것이라고 생각하면 됨

2. 데이터베이스(정보를 체계적으로 관리하는 저장소)를 관리함

3. 인증과 권한을 하는데 누가 요청하는 것인지 무엇을 할 수 있는지를 확인하는 일을 함

4. API(프로그램끼리 서로 요청하고 응답을 주고받을 수 있도록 하는 창구)를 제공함

5. 최종 검증(프론트엔드의 입력 확인과는 다르게 서버에서 한 번 더 확인함)을 함

③ 백엔드에서는 서버에서 실행되는데 단 서버는 '통신에서의 역할'이고 백엔드는 '개발 영역'이기에 비슷하면서도 다르다

④ 백엔드가 대표적으로 사용하는 기술은 3가지가 있다.

1. 프로그래밍 언어: Java, Python, JavaScript 등

2. 프레임워크: Spring, Django, Express 등

3. 데이터베이스: MySQL, PostgreSQL, MongoDB 등

ㄴ프로그래밍 언어, 프레임워크, 데이터베이스, API, 비지니스 로직에 관련해서 조금 더 구체적으로 알려줘.

비지니스 로직 - 서비스의 규칙과 처리 방식. 백엔드에서 두뇌의 역할을 함. "이 서비스가 어떻게 돌아가야 하는가"를 코드로 적은 부분

사용자가 브라우저 코드를 조작하려고 해도 권한이 바뀌지 않음 (서버에서 관리/판단 하고 있기 때문에)

프로그래밍 언어 - 비지니스 로직을 컴퓨터에게 전달하는 도구. 사람이 쓴 규칙을 컴퓨터가 실행할 수 있도록 명령으로 전환

1. Java - 대규모 서비스와 기업 시스템에 많이 쓰임. 안정적이며 자료가 풍부함

2. Python - 문법이 쉽고 간결해서 배우기 좋음. 데이터나 AI 분야와 잘 어울림

3. JavaScript(Node.js) - 프론트엔드와 동일한 언어로 백엔드까지 작성 가능. Node.js는 브라우저 밖에서 자바스크립트를 실행할 수 있게 해주는 환경 도구.

4. Go - 빠르고 동시에 처리하기에 용이함

프레임워크 - 앱의 뼈대와 규칙을 미리 갖춘 틀. 백엔드에서 이러한 작업을 대신 해줌

1. 요청이 들어오는 URL를 어느 코드에 연결할지 정해줌 (라우팅)

2. 요청 내용을 확인하고 응답을 만들어서 전송해줌

3. 로그인이나 보안, 데이터베이스 연결 처럼 공통 기능을 제공해줌

데이터베이스 - 정보를 체계적으로 저장하고, 빠르게 찾으며, 안전하게 고칠 수 있게 해주는 저장소. 서버를 껐다가 다시 켜도 데이터가 남을 수 있도록 하는 기억장치

API(Application Programming Interface) - Application는 우리가 사용하는 앱이나 소프트웨어를 Programming는 소프트웨어를 개발하는 과정이나 방법을 의미함 마지막으로 Interface는 소통을 가능하게 하는 규칙을 의미하는데 3가지를 묶으면 '프로그램끼리 요청하고 응답을 주고 받는 창구'

2. 백엔드는 웹이 서비스로 커지면서 서버 쪽을 처리하는 담당의 영역이 분리되면서 생겨난 개념이다.

1993년도 - NCSA에서 웹 개발진이 CGI 즉 '웹 서버가 외부 프로그램을 실행해서 그 결과를 응답으로 알려주는 규칙'을 만들게 되었는데 이때부터 요청에 따라서 그때마다 다른 답을 주는 백엔드의 원형이 생겼음

1995~1998년도 - 웹 전용 언어와 도구들이 등장했는데 웹 페이지에서 서버코드를 쉽게 끼워 넣을 수 있도록 해주는 언어인 PHP, 기업용 웹 서비스의 기반이 되는 .Java 서블릿(웹 요청을 처리하는 자바 프로그램)과 JSP(선 마이크로시스템즈), 마지막으로 마이크로소프트인 ASP도 이 당시에 나타남

1990년대 후반 - MySQL과 PostgreSQL과 같은 DB(데이터베이스)가 생겨나면서 데이터를 저장하고 꺼내 쓰는 서비스가 가능해졌음

2000년대 - 이 당시에는 프레임워크 시대가 되었는데 Spring의 자바 백엔드 개발을 체계화와 Django의 파이썬 웹 프레임워크, Ruby on Rails의 적은 코드로 빠르게 서비스를 만드는 방식이 대중화 되었음

2000년대 중반~ - 이 당시에는 API와 확장이 주로 이루어 졌으며

1. 로이 필딩의 박사 논문인 REST가 API 설계 방식으로 자리 잡음

2. Node.js로 자바스크립트가 서버에서도 사용되기 시작함

3. 클라우드(인터넷 밖에 있는 자원을 빌려 쓰는 방식)와 마이크로서비스(서비스를 작은 독립 단위까지 쪼개 따로 운영하는 구조)가 널리 사용됨

왜 만들려고 하였는가?

1. 사용하는 사용자마다 서로 시점이 다른 내용을 보여주고자 정적인 문서에서 동적인 문서로 바꾸기 위해서

2. 회원의 정보등을 안전하게 서버에 모아서 여러 사람이 함께 사용하기 위해서

3. 규칙을 사용자가 함부로 만지면 안되기 때문에 안전한 곳에서 사용하기 위해서

4. 반복적인 작업을 줄이고 개발에 더욱 집중하기 위해서

5. 다양한 화면이 같은 기능을 사용하게 하기 위해서

3. 백엔드가 나오기 이전에 불편함

1. 다양한 기기를 사용하는 사람들에게 통일된 사이트만 보여지게 되어 기기에 맞지않는 화면을 보게될 경우 불편함이 있음

2. 웹은 읽기만 하는 구조였기 때문에 다른 사람들이 회원 가입이나 글쓰기 등 서버에 데이터를 보내서 저장하는 일을 처리할 방법이 없음

3. 내용이 바뀔때마다 항상 담당자가 HTML파일을 직접 수정해야하는 버거로움이 있었음

4. 정보가 HTML 파일 안에 글자와 섞여있어 검색이나 정렬은 불가능하였으며 데이터베이스는 있었으나 웹과 직접적인 연결은 방법이 없었음

5. 안전에 관련된 처리가 불가능하여 웹으로 서비스를 운영하는거 자체가 어려웠음

4. 백엔드가 나온 이후에 편리한 점

1. 사용자나 상황별로 그에 맞는 화면을 보여주게 만들고 개인화된 화면이 가능해졌음

2. 사용자가 서버에 정보를 보내 저장하여 읽기만 하는 웹에서 참여하는 곳으로 바뀌게 되었음

3. 데이터를 데이터베이스에 저장하고 그 안에서 조건에 맞춰서 찾거나 정렬하는 것이 가능해졌음

4. 내용이 변하는 것이 자동화 되었음

5. 누가 접속했거나 확인하거나 결제를 믿고 맡길 수 있는 곳이 없었지만 이 후에 사용자가 사용하거나 사용하지 못하는 부분을 만들어 안전하게 같이 참여할 수 있게 되었음

5. 백엔드가 나오고 기존의 불편함은 크게 5가지가 해결되었는데

1. 똑같은 화면이 나가던 기존에서 사용자가 참여하여 백엔드에서 실행하게 만들어 졌으며 초기에는 CGI에서 이 후에는 프레임워크로 과정이 체계화 됨

2. 요청 본문으로부터 데이터를 서버가 받아서 서버가 이를 읽고 처리 후 저장하게 되는데 프론트엔드에서는 조작 가능성이 있어 백엔드에서 최종적으로 검증하도록 됨

3. 검색이나 정렬이 불가능했던 이전과는 다르게 백엔드 중간에서 SQL(데이터베이스에 요청하는 전문 용어)같은 질문을 보내고 데이터를 받아오게 되어 정렬과 검색도 가능하게 되었음. 또 트랜잭션으로 저장 도중에 틀어지는 문제도 해결함

4. 데이터는 데이터베이스에 화면은 템플렛에 따로 저장하여 데이터를 바꾸기 위해서는 모두 수작업을 해야하는 문제점을 한번에 자동 반영되도록 수정함

5. 과거에는 안전하게 기억하거나 처리하지 못했는데 백엔드가 나오면서 중요한 데이터는 DB에 저장하면서 안전하게 처리가 가능해졌음

ㄴ데이터베이스를 담고 있는 백엔드가 노출이 되면 그 안에서 문제가 생기는 것이고 그때 해킹이나 개인정보 유출 사고가 일어나는거야?

백엔드나 데이터베이스에 허가받지 않은 사람이 접근할 수 있는 틈이 생겼을때 사고가 난다.

1. SQL 인젝션 - 사용자가 입력창에 데이터베이스 명령어를 섞어서 넣은 후 서버가 실행하게 만드는 공격이 대표적이다. 백엔드가 입력값을 검증하지 않고 데이터베이스에게 넘길때 문제가 생긴다.

2. 인증, 권한 검사 헛점 - 로그인 확인이나 권한 검사가 빠진다면 남의 정보를 볼 수 있게 된다. API주소의 번호를 바꾸는 것만으로도 뚫리는 경우가 있다.

3. 데이터베이스나 서버가 그대로 열려있는 경우

4. 비밀 정보의 노출 - API키나 DB의 비밀번호가 있는 코드를 공개된 저장소에 올리거나 누구나 볼 수 있는 프론트엔드에 올리게 될때 문제가 생기게 됨

5. 부안 부실 - 보안 패치(발견된 취약점을 고치는 업데이트)를 미뤄서 생기는 약점 노출

AI 대화 내역 링크: https://claude.ai/share/812f3eb7-d286-42ab-b716-7a88152c9cf0

오늘 잘한 점: 집중이 잘 되어 많은 정보를 공부했으며 확실히 이해가 되고 작성하기 위해서 노력했다.

오늘 부족했던 점: 적극적인 대화를 주도하지 못했다고 생각한다.

오늘 총평: 프론트엔드와 백엔드를 어느 정도 알고 있다고 생각했는데 넓은 범위로 폭 넓게 공부하니까 큰 틀만 대충 아

는것이 아닌 사소한것까지도 알게 되었다. 그리고 프론트엔드의 약점과 백엔드의 약점도 알 수 있는 기회가 되었고 앱을 만들때 각각 어떤 역할을 하는지 이해하여 어떤 방향으로 나아가야 하는지 알 수 있게 된거 같다.

부족한 단어: 하이퍼링크, 링크, HTML, URL, HTTP, ENQUIRE, W3C, FTP, Usenet, Telnet, Archie, Gopher, 하이퍼텍스트, 하이퍼카드, 메멕스(Memex), 모자이크(Mosaic), link rot, 테드 넬슨, HTML Tags, 바이너리 형식, SGML, 검색 엔진, 스크린 리더, 자동 처리 도구, 로이 필딩, 헨릭 프리스틱 닐슨(Henrik Frystyk Nielsen), IETF, 인터넷 통신 방식(TCP/IP), 메서드, 데이터, 도메인, Head-of-Line Blocking, 멀티플렉싱, n-gram 모델, 트랜스포머, 클로드 섀넌, IBM 연구진, 요슈아 벤지오 연구팀, BERT, GPU, API, CGI