11월 8일 학습일지
총학습시간 : 6시간
Q1. 왜 백엔드 라는 이름이 붙었을까?
백엔드, 프론트엔드는 기술이름이 아니라 사용자에게서 얼마나 떨어져 있느냐로 붙은 이름이다.
사람이 직접 보고 만지는 앞쪽이 프론트엔드 (front: 앞)
사람 눈에 안보이는 뒤쪽에서 일하는 부분이 백엔드 (back :뒤)
Q2.누가,언제,왜 만들었을까?
누가? : 벨 연구소
언제? : 1974년 10월
왜?: 데이터베이스 일을 본 컴퓨터에서 떼어 뒤에 둔 전용기계를 백엔드 컴퓨터 라고 부르기 시작함.
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까?
앞,뒤를 나누니 전에는 크게 3가지 불편함이 있었다.
1. 비싼 컴퓨터 한대가 모든 일을 해서 느렸다.
2.화면 프로그램과 데이터가 한 몸이라 하나를 바꾸면 전체가 고장나기도 했다.
3.데이터 앞에 규칙을 지키는 문지기가 없어 누구나 허가없이 장부를 직접 만졌다.
Q4. 이게 나와서 뭐가 편해졌을까?
1. 앞과 뒤를 따로 고칠수 있게됐다.
2.뒤 하나에 앞을 여러개 붙일 수 있게됐다. (ex. 폰화면, pc화면)
3.규칙과 보안을 한곳에서 지킬수 있게 됐다.
대표적인 예로 RLS : 입구가 몇개로 늘어나도 문지기는 하나면 된다.
4.바쁜 쪽만 골라서 키울 수 있게 됐다.
사용자가 늘어 데이터 처리가 밀리면 백엔드 쪽 컴퓨트만 올리면 된다.
프론트쪽은 그대로 둬도 된다.
직군도 똑같이 나뉘 었다.
화면 전문인 프론트엔드 개발자 and 서버와 DB전문인 백엔드 개발자
Q5.기존의 불편함을 어떻게 해결했을까?
"앞은 무엇을 원하는지만 말하고, 어떻게 하는지는 뒤가 혼자 안다."
일을 이렇게 둘로 자르, 그 사이에 정해진 주문양식(요청과 응답) 만 오게가 했다.
1.한대가 다 해서 느리다 -> 일을 기계별로 떼고. 주문서만 오가게했다.
앞(단말기,브라우저,폰)은 요청만 보낸다.
그러면 뒤(서버,DB)는 그 요청을 처리해서 결과만 돌려준다.
서로 상대방 안에서 무슨 이링 일어나는지 몰라도 된다.
그래서 각자 다른 기계에 앞과 뒤를 따로 올려 돌릴수 있게 됐다.
2. 프로그램과 데이터가 한몸 -> 대이터를 이름으로 부르게 했다.
1970년 IBM의 에드거커드가 관계형 모델을 발표
-> 데이터를 표(행과 열) 로 정리하고, 프로그램은 데이터가 디스크 어디에 어떤 순서로 있는지 몰라도
해당 표에서 조건에 맞는 줄을 이름으로만 요청하게 하자는 아이디어.
->이들이 내세운 목표는 사용자가 기계 안의 데이터 배치를 몰라도 되게 하는것
-> 이 요청 언어가 IBM에서 1970년대에 만든 SQL이다.
3. 문지기가 없다 -> 데이터로 가는 길을 하나로 막았다.
앞은 데이터 파일을 직접 열수 없고, 반드시 뒤에 요청해야한다.
길이 하나뿐이니 그 길묵에서 권한( RLS),형식 동시 처리를 한번에 검사할 수 있었다.
(동시처리란? : 두 직원이 같은 거래를 동시에 저장해도 장부가 꼬이지 않게 하는것)
4.키우기 어렵다 -> 뒤가 숨겨져 있으니 뒤만 바꾸기
앞은 뒤 내부내용을 모르기 때문에 , 뒤를 더 큰 기계로 바꾸거나 여러 대로 늘려도 앞은 알 필요가 없어졌다.
-------------------------------------------여기까지 백엔드-------------------------------------------
<DNS>
Q1. 왜 DNS 라는 이름이 붙었을까?
Domain :영어로 영주가 다스리는 땅을 뜻한다. = 관할구역
Name : 사람이 기억하기 쉬운 주소. 인터넷은 원래 IP주소로 서로를 찾는다.
사람은 이를 외우기 힘드니 www.naver.com 같은 이름을 붙이고 ,
이름을 숫자로 바꿔주는 일을 DNS가 한다.
Q2.누가,언제,왜 만들었을까?
누가: 미국캘리포니아대학교 정보과학연구소의 폴모카페트리스
언제: 1983년
왜?: 인터넷 전체의 이름 장부를 파일 한개로 관리하던 방식이 인터넷이 커지면서
버티지 못했다. 그래서 장부를 한권으로 두지 말고, 관할 구역별로 쪼개서 각 구역 주인이
자기 장부만 들고있게 하고, 필요할 때마다 그 구역 주인에게 직접 물어보는 방식.
(.com .org .edu .kr)
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까?
1. 한 줄만 바뀌어도 전세계가 파일을 통째로 다시 받아야 했다.
2.이름이 전 세계에서 하나뿐이라 겹치면 쓸 수 없었다. -> 먼저 차지한 사람이 임자.
3.컴퓨터마다 들고있는 사본이 서로 달랐다.
4.자기 컴퓨터 이름 하나 바꾸는데도 남의손 (SRI)의 손을 거쳐야했다. -> 내 이름인대 남이 관리하는꼴
Q4. 이게 나와서 뭐가 편해졌을까?
1.가장 큰건 이름은 그대로 두고 뒤의 실제 서버는 마음대로 바꿀 수 있게 된것.
2.이름 하나로 웹,메일 같은 여러일을 나눠 맡길수 있게됨.
3.누구나, 바로, 직접
SRI 담당자 승인을 기다리지 않고, 도메인 판매 사이트에서 결제하면
몇분안에 내 구역이 생기고, 그 안의 이름은 내가 직접 고칠수 있다.
1990년대 인터넷 사업이 폭발한 기저에는 "누구나 자기 간판을 걸 수 있다"는 바탕이 있었다.
4.한 이름 뒤에 여러 서버
한 이름에 숫자 주소를 여러 개 적어 두면 손님이 여러 서버로 나눠 들어간다.
한대가 죽어도 나머지가 받아 줄 수 있다.
큰 서비스들은 여기서 더 나아가 , 묻는 사람의 위치를 보고 가장 가까운 서버 주소를 알려주는
데도DNS를 쓴다.
Q5.기존의 불편함을 어떻게 해결했을까?
DNS는 세가지 장치로 불편을 풀었다.
1.이름을 나무 모양 구역으로 쪼갰다.
2.위 구역은 아래 구역의 내용을 몰라도 되게 = 누구한테 물어볼지만 적어두게 했다.
3.한번 얻은 답은 유효기간을 붙여 잠깐 기억하게 했다. 장부를 통째로 봉사하던 방식이 필요한
한줄만 그떄그떄 물어보는 방식으로 바뀐것이다.
내 PC
│ "wonjangbu.vercel.app 어디야?"
▼
공유기 (192.168.219.1) → 통신사 안내원(리졸버)에게 넘김
│
├─① 루트 서버에게: ".app 담당 누구야?"
│ → "구글 등록소 서버들(ns-tld1~5.charlestonroadregistry.com)한테 물어봐" [유효기간 6시간]
│
├─② .app 담당에게: "vercel.app 담당 누구야?"
│ → "Vercel 서버들(ns1~4.vercel-dns-3.com)한테 물어봐"
│
└─③ Vercel 서버에게: "wonjangbu.vercel.app 주소는?"
→ "216.198.79.195 또는 64.29.17.195" [유효기간 5분]
-------------------------------------여기까지 DNS--------------------------------------------
<DB>
Q1. 왜 DB 라는 이름이 붙었을까?
Data(자료) +Base(기재,토대) 의 약자. 직영하면 자료를 모아두는 기지, 풀어말하면 여러 프로그램이 함께 꺼내 쓰도록
한곳에 모아둔 자료의 토대
Q2.누가,언제,왜 만들었을까?
누가: IBM과 GE의 찰스버크만
언제: 1960년대
왜 : 여러 사람과 여러 프로그램이 같은 자료를 동시에, 함께 써야 하는일이 생겼기 때문에.
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까?
1.자료를 처음부터 순서대로 다 읽어야했다.
2.프로그램이 자료가 놓인 자리를 글자 위치까지 외우고 있어야 했다.
3.같은 자료가 여기저기 흩어져 서로 달랐다.
4.두사람이 동시에 고치면 한사람 작업은 사라졌다.
5.새로운 질문 하나에 프로그램 하나를 새로 짜야했다.
Q4. 이게 나와서 뭐가 편해졌을까?
1.수십만건중에서도 원하는걸 바로 찾을수 있게됐다.
2.자료가 놓인 자리를 몰라도 이름으로 부르면 찾을 수 있었다.
3.자료를 한벌만 두고 서로 번호로 연결하게 됐다.
4.여러 사람이 동시에 고쳐도 장부가 지켜졌다.
5 누구나 직접 질문할수 있게 됐다. ->
Q5.기존의 불편함을 어떻게 해결했을까?
1.디스크 + 나무모양 찾기 = B-tree, 몇단계 만에 원하는 줄에 도착하는 인덱스 구조
2.DB가 설계도(스키마)를 직접 보관, 이름으로 부르는 요청을 실제 위치로 번역
3.표+번호로 연결. 한 사실은 한 곳에만 저장하는 원칙
4.장부를 고치기 전에 일지에 먼저 적어두고, 사고가 나면 일지를 보고 복구
5. SQL
-------------------------------------여기까지 DB--------------------------------------------
<MVC>
Q1. 왜 MVC 라는 이름이 붙었을까?
M: Model (모형) : 업무 자료와 규칙을 담당하는 쪽
V: Vie(보기) : 그걸 보여주는 쪽
C: Controller (조종기) : 사용자의 지시를받아 조종하는 쪽
-> 화면이 있는 프로그램을 세가지 역할로 나눠 부르려고 붙인 이름이다.
백엔드,DNS,DB와 달리 이건 기계나 장소의 이름이 아니라 역할 분담표의 이름.
Q2.누가,언제,왜 만들었을까?
누가: 레인스카우
언제: 1979년
왜?: 사람이 머리속에 그리는 업무의 모습과 컴퓨터 안의 자료를 이어 주는 화면을 만들고 싶었기 떄문
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까?
화면그리기, 입력받기, 업무규칙이 한덩어리 코드에 뒤엉켜 있었다.
그래서 다섯가지 문제가 따라왔다.
1.화면을 고치다 계산 규칙이 깨졌다.
2.같은 자료를 두번째 화면에 보이려면 규칙까지 복사해야했다.
3.한 화면에서 고치면 다른화면은 직접 찾아가 고쳐야 했다.
4.화면 없이는 업무 규칙만 따로 시험할 수 없었다.
5.화면 담당과 규칙 담당이 같은 코드를 만지며 부딪쳤다.
Q4. 이게 나와서 뭐가 편해졌을까?
역할을 나눴기에 다섯가지가 편해졌다.
1.새 화면을 붙이기가 쉬워졌다.
2.화면을 통째로 갈아엎어도 규칙이 안전해졌다.
3.어느 화면에서 보든 숫자가 같아졌다.
4.사람과 AI가 일을 나눠 맡고 넘겨받기 쉬워졌다.
5.파일을 약속된 자리에 두기만 하면 나머지는 알아서 연결해준다.
Q5.기존의 불편함을 어떻게 해결했을까?
1. 누가 누구를 아는지 방향을 한쪽으로 고정 : 모델은 아무도 모르고, 뷰와 컨트롤러만 모델을 안다.
2.모델이 바뀌면 나 바뀌었어! 라고 방송하고 뷰들은 알아서 다시 그린다.
3.사용자의 입력은 컨트롤러라는 문 하나로만 들어온다.
-------------------------------------여기까지 MVC--------------------------------------------
<API>
Q1. 왜 API라는 이름이 붙었을까?
Application Programming Interface
프로그램이 다른 프로그램의 기능을 쓸때의 접점
Q2.누가,언제,왜 만들었을까?
누가: 코튼,그레이토렉스
언제: 1968년
왜: 화면 장비가 바뀌어도 프로그램이 쓰는 접점은 일관되게 유지하려고
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까? (쉽게 요리로 비유)
API가 없던 시절에는 남의 기능을 빌려 쓰려면 그 사람 주방에 직접 들어가야 했다.
1.매번 처음부터 요리
공용 냄비가 없어서 요리사마다 육수부터 직접 끓였다.
=프로그램마다 같은 계산 코드를 처음부터 다시짰다.
2.주방 기구를 바꾸면 레시피도 전부 다시
-> 컴퓨터 장비가 바뀌면 그 위의 프로그램을 다시 고쳐야했다.
3.남의 냉장고를 직접 뒤져야함.
옆 가게 재료를 쓰려면 그 가게 냉장고 칸 배치 까지 알아야했다.
그 가게가 냉장고 정리를 바꾸면 내 요리는 망가졌다.
=다른 프로그램의 자료를 쓰려면 그 속 구조를 알아야했도, 상대가 구조를 바꾸면 내 프로그램이 깨졌다.
4.가게끼리는 전화,팩스로
다른가게와 일하려면 사람이 전화하고 종이를 주고받았다.
=회사끼리는 사람이 파이리을 보내고 다시 입력했다.
Q4. 이게 나와서 뭐가 편해졌을까?
1.뷰를 붙이는게 쉬워졌다.
2.화면을 갈아엎어도 규칙은 안전했다
3. 어디서 보든 같은 숫자
4. 정해진 자리 = 누구나 찾는다.
Q5.기존의 불편함을 어떻게 해결했을까?
1.자주 쓰는 기능을 모아두고 이름으로 불렀다. = 공용 냄비에 "육수"라고 이름표 붙여 두기
2'.주문서 양식과 속을 분리했다. = 주방 기구를 바꿔도 메뉴판은 그대로
3.창구만 열고 주방은 숨겼다. = 손님은 주방에 못 들어오고 창구에서 주문만
4.웹주소로 요청, 주문서양식, API 키 =배달 앱 주문서 양식 통일, 가게마다 회원번호
-------------------------------------여기까지 API--------------------------------------------
<WAS>
Q1. 왜 WAS라는 이름이 붙었을까?
WAS는 Web Application Server, 곧 "웹에서 프로그램(application)을 돌려 주는 서버"라서 붙은 이름
WS Web Server는 만들어진 파일을 그대로 꺼내주는대, WAS는 요청마다 프로그램을 돌려 그때그때 만들어준다.
Q2.누가,언제,왜 만들었을까?
한사람이 만든게 아니다.
1990년대 중반 복잡한 웹서비스가 생기면서 주문마다 요리해주는 주방이 대량으로 필요해지자
여러회사가 거의 동시에 만들었다.
사용자가 100명이면 100개의 페이지를 미리 만들어 둘 수는 없다.
그래서 WAS가 요청마다 프로그램을 돌린다. 사용자마다, 같은 사용자라도 요청마다 다른 화면을 볼 수 있다.
Q3. 이게 나오기 전엔 어떤 불편함이 있었을까?
1.요청마다 프로그램을 새로 띄워서 느렸다.
사용자가 한꺼번에 몰리면 프로그램을 켜고 끄는데만 서버 힘을 다 써서 멈춰버렸다.
2.요청마다 DB에 새로 연결해서 시간이 오래걸렸다.
3.요청이 끝나면 다 잊었다. ->로그인 유지가 어려웠다.
프로그램이 매번 꺼지니 정보를 보관할 곳이 없었다.
4.기본 기능을 서비스마다 직접 만들었다.
로그인확인, 저장이 중간에 실패하면 전부 취소하기(트랜잭션), 보안처리를 서비스마다 처음부터
새로 짰다.
5.화면과 코드가 한 덩어리였다.
프로그램 안에서 HTML을 한줄씩 직접 출력했다.
화면을 조그만 바꾸려해도 프로그램 코드를 고쳐야했다.
Q4. 이게 나와서 뭐가 편해졌을까?
WAS가 나오면서 서버가 계속 켜져있고, DB연결을 재사용하고, 로그인 상태를 기억하게됐다.
그래서 더욱 빨라졌고 개발자는 업무 기능을 만드는데만 집중 할수 있게 됐다.
Q5.기존의 불편함을 어떻게 해결했을까?
1.요청마다 새로띄움 -> 한번 켜 두고 작업만 나눠줌
2.DB에 매번 새로 연결 -> 미리 열어두고 빌려줌
3.요청이 끝나면 다 잊음 -> 번호표로 기억(세션번호)
4.기본기능을 매번 직접 만듦 -> 모든 기능에 똑같이 필요한 일은 WAS가 맡고, 개발자는 그 기능만의 일만 쓴다.
5.화면과 코드가 한덩어리 -> 화면 틀을 따로 뒀다 : HTML은 별도 파일로 만들고, 그 안에
"여기에 견적금액" 같은 빈자리만 표시해둔다. 코드는 그 빈자리에 들어갈 값만 넘긴다.
-------------------------------------여기까지 WAS--------------------------------------------
꼬리질문
https://share.aside.com/s/BEyDj997gS7YNfQE
꼬리질문1. 푸시는 깃헙까지만 올리는 거고 배포는 아닌 거지?
꼬리질문2. 커밋은 그럼 내 컴퓨터의 Git에만 저장하는 거야?
꼬리질문3. 저장을 어떤 식으로 하며 어느 폴더에 저장하는지도 궁금해.
오늘 잘한점.
마인드맵과 노트, AI에게 5가지 방식으로 질문을하며
같은 주제를 다방면으로 공부했다.
오늘 못한점
AI가 주는 5가지 질문에 대한 답들이
내가 영상을보며 노트에 정리한 내용보다 어려운 용어와 함꼐 설명하니까
잘 못알아 듣겠는 경우가많았다.
집중력 저하떄문인지, 용어가 어려워서인지 처음 노트공부하고 마인드맵에다가
정리할때보다 내용이 머리에 잘 들어오지않았다.
이번주의 경험으로 전날 봤던내용이 이해안갔다면 다음날 다시보면
이해가 갔던 경우가 많으니 내일 이후 다시 봐야겠다.
오늘 총평
확실히 공부 후반쯤 되니 집중력이 많이 떨어진다.
집중력 좋을때 다른 짓 안하고 최대한 많은 양을 제대로 이해하고
머리에 넣도록 해봐야겠다.
여기에 파일을 드롭하세요
