[강의] 웹 개발 기초

맹돌이·2026년 9월 7일
강의웹개발

강의

목록 보기
1/3
  • 백엔드 프론트엔드를 다 다룰줄 아는 사람이 풀스택 개발자다
  • 프론트엔드를 배우는 이유는 백엔드의 직접적 소비자이기 때문이다
  • 웹의 구성은 url(주소) html(콘텐츠) http(프로토콜/규칙)
  • html -> css -> js (틀을 제공받고 꾸며주고 기능을 제공하는 플로우)
  • 브라우저는 DNS(Domain Name System) 서버에 url의 실제 주소가 뭔지 물어서, 해당 도메인에 연결된 IP주소를 브라우저에게 알려준다

chapter1

  1. HTML
  • 폼(form)을 이해하는 것이 중요하다
  • 서버에 사용자가 입력한 정보를 전달하려면,form은 input, select, textarea에 입력된 값이 필요하며, 해당 태그에 입력된 값을 JS를 통해 Json형태로 변환되어 서버로 전송된다
  • Json은 key value 쌍으로 데이터를 표현한 것
  1. CSS
  • html 내부에서 CSS를 사용하는 방법과 link를 통해서 외부에서 CSS를 연결하는 방법 2가지가 있다
  • 백엔드관점에서 제일 중요하게 이해해야하는것은 박스모델과 레이아웃이다. 크기와 배치에 관련된거라서!

3.JavaScript(중요)

  • 최근에는 js의 사용툴이 넓어져서 서버, 앱 등을 만들어지고도 있다
  • 연결방식도 css와 마찬가지로 내부에서, 외부에서 연결하는 방법이있다
  • 변수 함수 EventListener(행동감지기->함수를 동작시키는 트리거) DOM
  • JS는 이벤트가 발생하면 HTML안에 값을 읽어오거나 새로 써서 화면을 변경할 수 있는데, 여기서 화면은 태그로 구성된 HTML이고 이를 DOM(Document Object Model)이라고 한다. html 안에 값을 읽고 쓰고 수정과 삭제를 할 수 있다
  • 서버와 통신기능 또한 가지고있음
    -> DOM 문서제어를 통해서 사용자가 입력한 데이터를 Json 객체로 만들었다. 이 데이터는 현재 사용자 컴퓨터의 브라우저 안에만 있으니까 이를 영구적으로 저장하고 공유하려면 newItem을 전송해야하는데 전송대상이 백엔드이다
  • fetch()함수가 서버에 데이터를 요청하고 응답을 받아오기 위해 사용하는 JS함수

Chapter2

  1. 서버
  • 하드웨어로서의 서버 : 고성능 컴퓨터 본체, 항시 켜져있어야함, 고정IP주소를 갖고있어야함 DNS가 찾아와야되니까
  • 소프트웨어로서의 서버 : 컴퓨터 안에서 실행되는 프로그램(근데 클라이언트의 요청을 듣고 응답을 하도록 설계되어있는것들)
  • 컴퓨터에는 수많은 포트가 존재함 (은행 창구같은거) 적절한 응답을 다시보내는데 각 포트는 각자가 맡은 업무만 처리한다.
  • 서버의 역할
    1. 웹 파일 제공 - 정적 파일(웹파일) html, css, png등 제공. 과제중에 개발자도구에서값을 변경했더래도 파일 값은 변하지 않앗으니까
    1. API 제공 - 클라이언트가 어딘가에 요청하면 응답 하러 가겠지? 근데 그 어디가 API라는거임.fetch함수도 어디론가 값을 보내주는데 그 어딘가가 API다
  • 정적 처리는 웹 서버에서 이뤄지고, API같은것들은 어플리케이션 서버에서 이뤄진다
  • 개발자도구 Fetch/XHR에서는 JS가 서버에 추가 데이터를 요청하는 통신 내역 API를 보여준다
  • API는 일단 서버에게 내가 이런 방식으로 요청하면, 이런 형식으로 대답해줘 라고 정해놓은 약속같은거임.
  1. HTTP
  • 클라이언트가 먼저 요청한다, 그럼 서버가 그 요청을 처리하고 응답한다(절대 서버가 먼저 클라이언트에게 말을 걸지 않는다) 클라이언트가 요청을 보내면 항상 응답한다
  • 주요특징
    1. 무상태성: 서버가 클라이언트의 이전 상태를 기억하지 않는다.서버는 불특정 다수의 수많은 클라이언트를 상대해야하니까 모든 클라이언트가 누군지 어떤 클라이언트가 보낸건지 다 기억하면 과부하걸리는거지 따라서 각 요청별로 새로운 요청인 것처럼 취급을 한다.
    1. 비연결성: 클라이언트가 요청을 보내고 서버가 응답을 마치면, 연결을 끊는다.
  • HTTP 요청은 Start Line, Headers, Body 3개로 구성된다
    1. Start Line (우편을 보낼때 박스위에 보내는사람,받는사람,주소같은거임)
  • GET(조회) POST(추가) PUT/PATCH(수정) DELETE(취소)
  • URL은 IP 주소(고유주소 DNS가 찾아준거) , 포트, 경로가 존재함
    1. Header (주문의 상세 정보를 의미)
  • Contents Type : 본문에 담긴 콘텐츠(데이터)가 어떤 형식인지 본문 해석전에 알 수 있게 하는 정보임.
  • Accept : 클라이언트가 전달 받을 수 있는 컨텐츠를 서버에게 알려주기 위한 정보임
  • 3.Body(주문할때 함께 보내는 요청서, 저 이런거 못먹어요 이런거지)
  • 응답도 Status Line, Headers, Body로 구분된다
    1. Status Line : HTTP 응답은 status code라는게 있는데 2xx는 성공/4xx는 클라이언트 오류, 5xx는 서버오류다

API/REST API

  1. API
  • Application Programming Interface
  • 프로그램들이 서로 소통하기 위한 접점
  • API는 소비자가 쉽고 편하게 원하는 목적을 얻을 수 있도록 도와주는 소통창구(안에서 무슨 일이어나는지 전혀 관심안가짐)
  1. RESTAPI
  • Representational State Transfer API
  • 표준 설계 원칙이라는 건데 API를 설계하는 원칙이란거임.
  • A는 찜 목록 추가를 POST/createItem B는 POST/item/new 이런식으로 짯다면 혼란이 야기된다.
  • Representation = 표현 , 서버의 자원을 클라이언트가이해할 수 있는 형태로 쉽게 표현하는것
  • State는 현재 서버가 관리하는 자원에 현재 상태를 의미하는거임.
  • Transfer 클라이언트가 서버에게 자원에 상태를 요청하고 서버는 해당 상태를 클라이언트에게 전달한다
  • 즉, RESTAPI는 웹 자원을 URI로 식별하고 그 자원의 표현을 HTTP표준에 맞게 주고 받는 원칙이다
  • REST에는 6원칙이 존재함(1-3은 중요하다)
    1. 균일한 인터페이스 - 모든 자원은 고유한 주소로 식별되어야한다
    1. 클라이언트-서버의 역할 분리 - 클라이언트는 사용자 경험만, 서버는 데이터와 로직만 책임진다 -> 독립적 발전
    1. 무상태성 - 서버는 당신을 기억하지않는다(HTTP 무상태성과 같음)
    1. 주문형 코드 - 필요할 때 기능을 전송한다. 데이터가 다양한걸 포함할 수 있다는건데, JSON같은ㄷ ㅔ이터 뿐 아니라 실행가능한코드를 클라이언트에 올릴 수 있음
  • 5.캐시 가능 - 서버는 응답을 보낼 때 이 데이터 캐시 해도되냐고 묻는다 이를 헤더에 명시해야한다.
    1. 계층형 시스템 클라이언트가 직접 서버와 대화하는지 방화벽과 얘기하는지 알 필요가 없다.
  • 즉 REST API는 API를 만드는 원칙같은거네.
  • API 요청 명세 작성법 - 요청시에는 메서드(GET,POST..등), 엔드포인트(naver.com 뒤에 /items(명사형)), 요청 파라미터(?sort-new 이런거), 요청 헤더(콘텐츠 타입같은거), 요청 본문이 들어가야한다.
  • API 응답 명세 작성법 - 마찬가지로 상태코드가 존재해야하고, 응답 헤더, 응답 본문이 필요
  • 오류에 대한 부분에 대해서도 대비해놔야한다
  1. Postman으로 REST API 확인하기
  • API 명세는 프론트엔드와 백엔드 개발자간의 협업과정을 부드럽게 하기위해서
  • Postman : API를 테스트하고 API를 배달하는 배달부같은거임. 내가만든 API가 잘 작동하는지 검증하고, 백엔드 API가 어떻게 데이터를 주는지
  • Mock Server는 응답만 해주는 가짜 서버임
  • Collection API 요청들을 담아두는 모음임

Chapter3

  1. 프론트엔드 코드 맛보기

  • 프레임워크?(React)
    html css js외에도 코드를 관리하기 위한 도구가 있는데 코드 관리 도구의 모음을 프레임워크라고해 그 중 가장 유명한게 React야

  • 프레임워크가 필요한 이유가 뭐지?
    html css js 3가지만 써도 되긴하는데 이거 3개만 쓰면 너무 복잡해져, 프레임워크는 밀키트같은거임. 검증된 레시피가 있고 검증된 재료가 들어있잖아.프레임워크의 핵심역할은 두개야
    - 1. 컴포넌트관리
    - 2. 상태관리
    컴포넌트도 기능단위로 묶인 블럭이니까 재사용이가능해.
    상태관리는 state 웹사이트가 기억해야할 데이터를 프레임워크가 해주는거임 예를들어 좋아요 하나 누르면 +1해주는거라든지, 장바구니에 몇개든지 표시하는거라든지.
    =>일단 지금은 프레임워크가 우리의 일을 대신해주는 친구라고 생각만하자

  • 프레임워크의 종류?
    React Vue.js Svelte 등..

  1. 백엔드 코드 맛보기
    백엔드 프레임워크가 필요한 이유도 똑같다. 밀키트가 있다면 순수 Java를 사용하는 것 보다 편리하게 좋은 결과물을 만들어낼 수 있다
    react는 UI를 컴포넌트로 분리했다면 백엔드 프레임워크의 핵심역할은?
  • 백엔드 프레임워크 핵심역할
  1. Spring은 역할에 따라 코드를 분리한다

  • Controller는 클라이언트가 요청한(POST/items)같은 API 엔드포인트가 도착하는 진입점이자 요리한 음식을 손님에게 응답하기 위한 출발점을 하는 역할
    API를 관리해주는 친구인거지. 얘를 통해서 시작과 끝을 맞이한다

  • Service는 실제 비즈니스 로직을 담당한다

  • Repository는 오직 데이터베이스와 통신하는 역할만 한다

  • Entity는 데이터베이스에 어떤 걸 넣을지 재료 자체를 정의하는거임

=>이러한 구조를 레이어드 아키텍처(계층형 아키텍처)라고 한다
장점으로는 부품 교체이다 Repository를 메모리에서 데이터베이스로 바꿔도, Controller와 Service는 코드를 바꿀 필요가없다!

  1. 데이터베이스 맛보기
    데이터베이스는 초대형 냉장고이자 창고이다.
    영속성 - 데이터가 안전하게 저장된다
    동시성 -여러 사람이 동시에 재료를 읽거나 써도 데이터가 꼬이지 않게 관리한다
    무결성/일관성 - 재고가 0인데 구매를 허용하지않거나 예외를 막는다

데이터베이스도 2개로 나눠진다
1. RDB (Oracle, MySQL등)
엑셀시트 처럼 데이터를 저장하고 구조화된 '관계'바탕으로 데이터를 관리한다
일관성과 명확성이 생명인 분야에서 사용된다
2. NoSQL(Not only SQL, Firebase Firstore,Redis등)
엑셀시트 같은 틀이 없고 데이터를 폴더 안의 문서 처럼 자유롭게 저장한다
빠른 속도와 확장성이 장점이다. 정해진 틀이 없어서 일관성이나 명확성이 떨어진다

전체적으로 처음에는 프론트엔드만 구성해서 목 서버를 이용해서 데이터를 CRUD해봤고,
백엔드를 구성하니까 DB가 없어서 새로고침하면 다 날아갔었다
최종적으로 DB까지 구성하고 나니까 완전히 사용가능한 사이트가 되었다!

==

26/09/08

Chapter4

  1. AI를 학습 코치로 활용하기
  • 명령 - 명확한 질문을 해야한다! (코드를 성능,가독성 관점에서 리뷰해줘)
  • 맥락 - 배경을 설명해서 오해를 줄일 수 있다.(뭘 알고 뭘 모르는지)
  • 페르소나 - 요구사항 정의서를 작성할 때도 페르소나를 두는 것이 좋은 방법이다. 전문가로 만들어줌으로써 ai를 빙의 시키는거지
  • 예시
  • 포맷 - ai가 대답해야할 형식
  • 어조 - 말투를 지정해서 난이도를 낮출 수 있지

위 핵심 요소를 고려해서 질문하는 것이 중요하다!
가령 질문시에 ai에게 페르소나를 부여하고 나는 맥락과 포맷을 알려주면 원하는 답을 얻기 쉬울것

2.v0 서비스 실전 활용해보기

profile
맹돌이
다음 포스트

[강의] 협업을 위한 Git 활용

0개의 댓글