혜진의 개발자 성장블로그

프론트엔드 서비스 기획과 애자일 방법론(w.홍석희강사님)

dev.hyejin — Fri, 4 Oct 2024 00:53:40 +0900

PMF와 애자일

• PMF(Product Market Fit): 제품이 시장 요구를 충족시키는 정도
• 애자일 방법론: 유연하고 반복적인 개발 프로세스
• 워터폴 vs 애자일: 전통적 방식과 현대적 방식의 비교

UX 설계와 문제 해결

• UX(User Experience) 중요성: 사용자 맥락, 행동, 요구, 태도, 동기 이해
• 문제 해결 과정으로서의 UX
• '5 Whys' 기법: 근본 원인 파악 방법

MVP(Minimum Viable Product)

• 정의: 최소한의 기능으로 제품의 핵심 가치 검증
• 린(Lean) 스타트업 방법론의 핵심 요소

페르소나와 사용자 스토리

• 페르소나: 대표적 사용자 프로필 작성
• 사용자 스토리: 기능 개발 우선순위 설정 및 팀 소통 도구
• 사용자 스토리 작성법: "As a [user], I want to [action], so that [benefit]"

제품 개발 프로세스

• WBS(Work Breakdown Structure): 프로젝트 작업 분류
• PRD(Product Requirement Document): 제품 요구사항 문서화

팀 구성과 역할

• 주요 역할: PM/PO, UX/UI 디자이너, 프론트엔드/백엔드 개발자, QA
• 효과적인 팀워크의 중요성

소프트웨어 테스트 특강

dev.hyejin — Fri, 27 Sep 2024 03:52:17 +0900

소프트웨어 테스트란?

개발자 입장에서 바라본 테스트
의도한 대로 정상동작하는지 검사하는 것

프론트엔드 테스트 수행하기: 테스트 케이스기반 테스트

QA(Quality Assurance, 품질보증):
제품 품질을 보증하기 위한 전반적인 프로세스와 활동. 테스팅은 QA의 중요한 부분이지만 QA는 이보다 더 광범위한 개념

만약 시나리오 테스트를 마치면 끝이날까? No

기능이 잘 되지 않는지 세부적으로 문제가 되는 지점을 찾기 어려움
테스트 시간적 비용 고려, 리소스 소비가 크다

그럼, 조금더 작은 단위의 기능을 테스트 해보자

조금 더 세부적인 테스트 작성하기 : 로직 하나 하나의 정삭적인 동작 테스트

예) 회원등록 페이지의 이메일 입력 관련

아주 세부적인 테스트로 갈 수록 문제가 생겼을 때, 어떤 문제인지 발견/추적하기 쉬움

그럼 작은 테스트가 장땡? ..... 아니다. 테스트를 작성할게 많다!

[테스트 종류]

1. 가장 유저사이드에 가까운 테스트: E2E테스트(엔드투엔드, 시스템테스트, 전체서비스 테스트)

테스트 케이스가 몇개 없어도 여러가지 기능들을 커버할 수 있다
실제 유저의 동작에 기반해서 모든 인프라까지도 테스트 할 수 있다

프론트엔드 쪽에서,

화면에서 시작해서 서버에 가서 백엔드 디비도 찌르고 여러 동작을 하는 인프라 아키텍처로부터 오는 기능들을 테스트

E2E자동화 툴 : cypress / puppeteer / playwright
테스트 할라면 브라우저에서 실행을 해야하는데 굳이 디스플레이가 필요하진 않기때문에,
헤드리스 브라우저(실제 디스플레이 안하고 코드레벨(노드js)에서만 돌아가는 브라우저)의 백그라운드에서 자동으로 테스트가 진행

2. 통합테스트: 여러 모듈이 엮인 테스트

작은 컴포넌트 레벨의 테스트지만 최소 단위는 아닌 것들에 대한 테스트
브라우저를 실행해서 렌더링 하기도 하고, (더 많이 사용하는 방법) node.js 인스턴스 상에서 react.render()해서 정상동작하는지 확인하기도 하다.
노드JS 상에서 리액트.렌더 -> 어떤 요소를 찾아서 -> 그것을 클릭했을 때 원하는 정상동작이 이루어졌는가.
=> 컴포넌트 하나하나의 동작을 테스트한다

디자인시스템이란:

제품이나 서비스의 디자인과 개발을 일관되고 효율적으로 만들기 위한 표준화된 시각적 요소, 컴포넌트, 패턴의 집합
색상, 타이포그래피, 아이콘, 버튼, 폼 등의 UI 요소와 이들의 사용 지침, 그리고 이를 구현한 재사용 가능한 코드 컴포넌트가 포함
디자인 시스템은 일관된 사용자 경험을 제공하고, 개발 효율성을 높이며, 팀원 간의 협업을 개선하는 데 도움을 준다

통합테스트는:

여러개 컴포넌트가 있어서 컴포넌트에 대한 동작이 테스트 되어야 할 때,

예) 서비스에서 굉장히 중요한 영역, 장애가 나면안되는 영역에서 ( => 결제, 장바구니) 부가적인 장치로 통합테스트가 사용된다.

cf. E2E테스트에는 디자인시스템이 없다. E2E 테스트는 전체 시스템의 동작을 테스트하며, 이는 디자인 시스템을 포함한 모든 컴포넌트의 통합된 동작을 검증한다.

3. 유닛테스트: 가장 작은 단위에 대한 테스트

가장 브로드하다
각 기능하나하나에 대한 테스트다
코어컴포넌트를 개발할 때(예를들어, 같은 팀원 혹은 팀원으로부터 인수인계를 받아서 추가적으로 유틸리티 기능을 개발하거나 기능을 확장할 때 등), 기존에 지원되었던 다른 컴포넌트의 기능을 망가트릴 수 있다.
이런 상황에서 유닛테스트를 통해서, 어떤 코드를 어떻게 건드렸을 때 발생할 수 있는 문제를 추적하기 용이하다. 즉, 코드를 변경하면서 예상하지 못했던 사이드이펙트를 발견하기 쉽다.
유닛테스트 툴: jest

여기에서 E2E테스트와 다른점은?

E2E테스트는, 개발이 끝나야 할 수 있다.
구현을 다 하고 테스트를 돌려봐야 잘 동작하는지 알 수 있다. 즉, 전체적인 서비스의 테스트를 하기 전에 각 유닛들이 정상동작하는지 검사하는 테스트이다.

[Network] HTTP의 병목현상과 WebSocket

dev.hyejin — Fri, 16 Aug 2024 00:38:40 +0900

HTTP를 기본으로 하는 프로토콜

HTTP의 병목현상을 해소하는 SPDY(스피디) - 사실상 사장된 기술

SPDY의 발전과 HTTP/2로의 전환:

SPDY는 2010년 구글이 발표한 이후 웹 성능 향상에 큰 영향을 미쳤음
그러나 SPDY 자체는 더 이상 활발히 사용되지 않음
SPDY의 핵심 개념과 기술은 HTTP/2의 기반이 됨

HTTP/2의 도입:

2015년 HTTP/2가 공식적으로 표준화 됨
HTTP/2는 SPDY의 많은 특징을 계승하여 개발 됨
대부분의 주요 웹 브라우저와 서버는 HTTP/2를 지원

1. HTTP의 병목현상

병목현상: 시스템의 전체 처리 능력이 가장 성능이 낮은 부분에 의해 제한되는 현상

연결 제한 (Connection Limit):

HTTP/1.1은 일반적으로 브라우저당 도메인별로 동시 연결 수를 6-8개로 제한
많은 리소스가 필요한 웹페이지의 경우, 이 제한으로 인해 로딩 시간이 길어질 수 있음

Head-of-Line Blocking:

HTTP/1.1에서는 하나의 연결에서 요청과 응답이 순차적으로 처리
큰 요청이 앞에 있으면, 그 뒤의 작은 요청들이 지연될 수 있음

반복적인 헤더 정보:

각 HTTP 요청마다 중복된 헤더 정보를 전송해야 함
이는 불필요한 대역폭 사용을 초래하고, 특히 모바일 환경에서 성능 저하의 원인이 됨

단방향 통신:

클라이언트의 요청이 있어야만 서버가 응답할 수 있음
서버가 클라이언트에게 능동적으로 데이터를 푸시할 수 없어, 실시간 업데이트가 필요한 경우 비효율적

압축의 제한:

HTTP/1.1에서는 body 내용은 압축할 수 있지만, 헤더는 압축할 수 없음
헤더가 큰 경우 불필요한 대역폭을 사용

도메인 샤딩의 필요성:

연결 제한을 우회하기 위해 여러 서브도메인을 사용하는 도메인 샤딩 기법이 사용
이는 DNS 조회 시간을 증가시키고 추가적인 TCP 연결을 필요로 하여 새로운 오버헤드를 만듬

지연 시간에 민감:

각 요청-응답 사이클이 완료되어야 다음 요청을 할 수 있어, 네트워크 지연 시간에 매우 민감

상태 비저장 프로토콜:

HTTP는 상태를 저장하지 않아, 매 요청마다 필요한 모든 정보를 포함해야 함
이는 쿠키나 세션 관리를 위한 추가적인 메커니즘 필요

2. 브라우저 양방향통신, WebSocket

WebSocket의 작동방식

초기 연결:

클라이언트가 서버에 HTTP 연결을 요청하면서 WebSocket으로의 업그레이드를 요청(초기 핸드셰이크를 수행)
서버가 이를 승인하고 프로토콜을 WebSocket으로 전환

양방향 통신:

WebSocket 연결이 수립되면, 클라이언트와 서버 간에 자유로운 양방향 통신이 가능
클라이언트는 언제든 서버로 메시지를 보낼 수 있음
서버도 별도의 요청 없이 클라이언트에게 실시간으로 데이터를 푸시할 수 있음

연결 종료:

클라이언트나 서버 중 어느 쪽에서든 연결 종료를 요청 가능
상대방이 이를 확인하면 연결 종료

이 다이어그램의 특징:

초기 연결은 HTTP를 통해 이루어지지만, 그 이후에는 WebSocket 프로토콜을 사용
연결이 수립된 후에는 클라이언트와 서버가 대등한 위치에서 자유롭게 통신 가능
서버가 클라이언트의 요청 없이도 데이터를 전송할 수 있어, 실시간 업데이트에 매우 효과적

사용 사례:

실시간 채팅 애플리케이션
라이브 스코어보드나 주식 시세 같은 실시간 업데이트
온라인 게임
협업 도구 (실시간 문서 편집 등)
IoT 디바이스 모니터링

장점:

실시간 양방향 통신으로 즉각적인 데이터 교환이 가능
HTTP Long Polling에 비해 서버 리소스를 효율적으로 사용
헤더 오버헤드가 적어 네트워크 트래픽을 줄일 수 있음

단점:

일부 오래된 브라우저에서는 지원되지 않을 수 있음
방화벽이나 프록시 서버가 WebSocket 연결을 차단할 수 있음
서버 측에서 연결 상태를 관리해야 하므로 복잡성이 증가할 수 있음

3. HTTP Long Polling은 또 뭔가?

실시간에 가까운 웹 애플리케이션을 구현하기 위한 기술 중 하나. 전통적인 폴링(polling) 방식을 개선한 것으로, 서버와 클라이언트 간의 지속적인 연결을 시뮬레이션

클라이언트가 서버에 요청을 보내고, 서버는 새로운 데이터가 있을 때까지 응답을 보류
데이터가 있거나 타임아웃이 발생하면 서버가 응답을 보냄
클라이언트는 응답을 받는 즉시 새로운 요청을 보냄

작동 방식:

클라이언트가 HTTP 요청을 서버로 보냅니다.
서버는 요청을 받지만, 즉시 응답하지 않고 대기합니다.
새로운 데이터가 생기거나 정해진 시간(타임아웃)이 지나면 서버가 응답합니다.
클라이언트는 응답을 처리하고 즉시 새로운 요청을 보냅니다.

장점:

실시간에 가까운 업데이트를 제공할 수 있습니다.
일반 HTTP를 사용하므로 대부분의 브라우저와 서버에서 지원됩니다.
방화벽이나 프록시 서버와의 호환성이 좋습니다.
WebSocket보다 구현이 간단할 수 있습니다.

단점:

각 클라이언트마다 서버에 연결을 유지해야 해서 서버 리소스 사용량이 높습니다.
실제 실시간 통신에 비해 약간의 지연이 있을 수 있습니다.
많은 수의 동시 접속자가 있을 경우 확장성 문제가 발생할 수 있습니다.
클라이언트와 서버 간의 연결이 자주 끊겼다 다시 맺어지므로 오버헤드가 발생합니다.

[Network] 인증(Authorization)

dev.hyejin — Thu, 15 Aug 2024 23:54:29 +0900

인증을 무엇으로 할까?

등록된 본인만이 알고 있는 정보
등록한 본인만이 가지고 있는 정보 등
패스워드, 원타임토큰, 전자증명서, 바이오매트릭스, IC카드

HTTP에서 사용하는 인증방법

BASIC
DIGEST
SSL Client
Form Base

1. BASIC 인증

HTTP/1.0에 구현된 인증방식

클라이언트: 리퀘스트 송신
서버:상태코드 401로 응답해서 인증이 필요하다는 것을 전달
유저가 ID와 패스워드를 입력하면, 브라우저가 자동적으로 Base64 로 변환
- 클라이언트: 유저ID와 패스워드를 Base64형식으로 인코드 한 것을 송신
서버: 인증 성공 시에는 상태코드 200 응답. 실패했을 경우 다시 상태코드 401로 응답
- 서버는 인증정보가 정확한지 여부를 판단함

단점:

Base64라는 인코딩 형식을 사용하고 있지만, 암호화는 아님

따라서 아무런 부가 정보 없이 복호하 가능

즉 HTTPS 등에서 암호화되지 않은 통신 경로 상 BASIC 인증을 해서 도청된 경우, 복호화 된 유저ID와 패스워드 뺏길 가능성 있음

한번 BASIC 인증을 하면, 일반 브라우저에서는 로그아웃 불가능(사용상 문제가 많고 보안등급이 낮음)

2. DIGEST 인증

BASIC 인증 약점 보완, HTTP/1.1에 소개

챌린지 리스폰스 방식 사용

최초 상대방에게 인증요구 보냄
상대방 측에서 받은 챌린지 코드를 사용해서, 리스폰스 코드 계산함
이 값을 상대에게 송신하여 인증함(패스워드 누출 가능성 낮음)

DIGEST 인증 수순

클라이언트: 리퀘스트 송신
서버: 상태코드 401로 응답해서 인증이 필요하다는 것을 전달하는 동시에 패스워드와 챌린지코드(nonce) 송신함
클라이언트: 패스워드와 챌린지 코드에서 리스폰스 코드(response)를 계산해서 송신
서버: 인증 성공 시 상태코드 200 응답, 실패 시 다시 상태코드 401 응답

3. SSL Client 인증

HTTPS의 클라이언트 인증서를 이용한 인증방식

SSL Client 인증은 2-factor 인증에서 사용
SSL Client 인증은, 폼 베이스 인증과 합쳐서 2-factor인증의 하나로서 이용
- 2-factor 인증: 이용자가 가진 다른 정보를 병용해서 인증하는 방법
- 첫번째 인증 정보로서, SSL 클라이언트 인증을 사용하여 클라이언트 컴퓨터를 인증
- 다른 인증정보로서, 패스워드를 사용하여 유저의 본인 확인을 함(본인이 올바른 컴퓨터에 엑세스하고 있음을 확인)

단점: SSL Client 인증은 이용하는데 비용이 든다

4. 폼 베이스(Form Base) 인증

HTTP 프로토콜로서 사양이 정의되어 있는 인증방식은 아님
클라이언트가 서버상의 웹 애플리케이션에 자격정보(Credential)를 송신하여, 그 자격정보의 검증결과에 따라 인증하는 방식
대부분 사전 등록된 자격정보인 유저ID와 패스워드를 입력해서 웹 애플리케이션에 송신, 검증결과를 토대로 검증 성공여부 결정함

인증의 대부분은 폼 베이스 인증

BASIC/DIGEST 인증의 문제: 사용상 문제, 보안문제
SSL 클라이언트 인증의 문제: 도입비용 및 운용비용의 문제

세션 관리와 쿠키에 의한 구현

HTTP는 스트레이트 프로토콜
방금 전에 인증을 성공했던 유저라는 상태를, 프로토콜 레벨에서는 유지 불가능
즉, 상태관리가 안됨(다음에 유저가 엑세스 하더라도 다른 유저들과 구별 불가)
세션 관리와 쿠키를 사용 => HTTP에 없는 상태관리기능을 보충

[Network] HTTPS 구조

dev.hyejin — Thu, 15 Aug 2024 23:30:24 +0900

HTTP 약점

평문(암호화 하지 않은) 통신이기 때문에 도청 가능
통신 상대를 확인하지 않기 때문에 위장 가능
완전성을 증명할 수 없기 때문에 변조 가능

1. 평문이기 때문에 도청 가능

TCP/IP는 도청 가능한 네트워크
암호화로 도청 피할 수 있다
- 통신을 암호화 : HTTP + SSL/TLS 조합
  - SSL(Secure Socket Layer)
  - TLS(Transport Layer Security)
  - SSL 등을 이용해 안전한 통신로를 확립 후, 그 통신로를 사용해 HTTP 통신
  - SSL을 조합한 HTTP => HTTPS(HTTP Secure) / HTTP over SSL
- 콘텐츠 암호화: 콘텐츠 내용 자체를 암호화(HTTP메시지에 포함되는 콘텐츠만 암호화)
  - 메시지 헤더는 암호화되어 있지 않음
  - 메시지 바디에 들어가는 콘텐츠를 암호화(통신자체는 암호화되어 있지 않음)
  - 주로 웹 서비스에서 이용되는 방법

2. 통신 상대를 확인하지 않기 때문에 위장 가능

HTTP를 사용한 리퀘스트나 리스폰스 에서는 통신 상대를 확인하지 않음

누구나 리퀘스트 할 수 있음
- 위장한 웹 서버일 우려
- 위장한 클라이언트일 우려
- 통신하고 있는 상대가 접근 허가된 상대인지 아닌지 확인할 수 없음
- 어디의 누가 리퀘스트 했는지 확인할 수 없음
- 의미없는 리퀘스트라도 수신하게 됨(DoS 공격 방지 불가능)
상대를 확인하는 증명서
- SSL로 상대 확인 가능
- SSL은 암호화 뿐 아니라, 상대를 확인하는 수단으로 증명서를 제공함
- 클라이언트는 통신을 개시할 때 서버의 증명서를 확인함
- 증명서를 가짐으로써 본인 확인 및 웹 사이트 인증에 이용 가능

3. 완전성을 증명할 수 없기 떄문에 변조 가능

완전성: 정보의 정확성

완전성을 증명할 수 없다: 정보가 정확한 지 아닌지 확인할 수 없다

수신한 내용이 다를지도 모른다
- 리퀘스트/리스폰스가 발신된 후 상대가 수신할 때까지의 사이에, 변조되었다 하더라도 이 사실을 알 수 없음
- 중간자 공격(Man-in-the-Middle 공격): 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격
변조를 방지하려면?
- MD5/SHA-1 등 해시값 확인
- 파일의 디지털 서명을 확인

HTTP+암호화+인증+완전성 보호 = HTTPS

1. HTTPS(HTTP Secure): HTTP에 암호화나 인증 등의 구조를 더한 것

증명서는 서버 혹은 클라이언트의 신원을 증명
https://

2. HTTPS는 SSL의 껍질을 덮어쓴 HTTP

HTTP 통신을 하는 소켓부분을 SSL이나 TLS라고 하는 프로토콜로 대체할 뿐, HTTPS는 새로운 프로토콜이 아니다

애플리케이션(HTTP)

TCP

HTTP

애플리케이션(HTTP)

SSL

TCP

HTTPS

HTTP는, 직접 TCP와 통신
HTTPS는, SSL을 사용한 경우, HTTP와 SSL이 통신하고, SSL이 TCP와 통신

3. 상호간에 키를 교환하는 공개키 암호화 방식

SSL은 실제 데이터를 암호화 할 때 대칭키 암호화를 사용(암호화 알고리즘 공개하고, 키를 비밀에 부침)

대칭키(공통키) 암호의 딜레마: 키 배송 문제
- 암호화할때도 복호화할 때도 같은 키를 사용
- 키를 손에 넣으면 누구라도 암호를 해독할 수 있음
- 키를 보내면 도청 될 가능성이 있고, 키를 보내지 않으면 복호화 할 수 없음
- 애초에 키를 안전하게 보낼 수 있다면, 틀림없이 데이터도 안전하게 보낼 수 있음
- 어떻게 하면 안전하게 키를 보낼 수 있을까?

4. 두개의 키를 사용하는 공개키(비대칭키) 암호

서로 다른 두 개의 키 쌍을 사용(비밀키-공개키)
암호를 보내는 쪽이 상대의 공개키를 사용해서 암호화 함
암호화된 정보를 받은 상대는 자신의 비밀키를 사용해 복호화 함
공개키는 누구에게나 넘겨줘도 괜찮음
대칭키 암호의 딜레마였던 키 배송 문제 해결

HTTPS는 하이브라드 암호시스템

키를 교환하는 곳에서는 공개키 암호 사용
그 후, 통신에서 메시지를 교환하는 곳에서는 대칭키(공통키)암호 사용

4. 공개키가 정확한지 아닌 지를 증명하는 증명서

인증기관(CA: Certificate Authority)

서버의 운영자가 인증기관에 공개키 제출
인증기관은 제출된 공개키에 디지털 서명을 하고, 서명이 끝난 공개키를 생성 후 공개키 인증서에 서명이 끝난 공개키를 담는다
서버는 이 인증기관에 의해 작성된 공개키 인증서를 클라이언트에 전송하고, 공개키 암호로 통신
증명서를 받은 클라이언트는 증명기관의 공개키를 사용해서 서브의 공개키를 인증한 것이 진짜 인지, 서버의 공개키를 신뢰할 수 있는지 알수 있음

조직의 실제성을 증명하는 EV SSL 증명서
증명서 역할: 서버가 올바른 통신 상대임을 증명하는 것.
EV SSL 증명서: 상대방이 실제 있는 기업인지 확인하는 역할을 가진 증명서. 운영하는 조직의 실재성 확인
클라이언트 증명서

HTTPS에서는 SSL과 TLS 라는 두 개의 프로토콜 사용

HTTPS 문제점

SSL 사용하면 처리가 늦어짐
HTTPS는 서버, 클라이언트 모두 암호화와 복호화 처리가 필요. CPU나 메모리 등의 하드웨어 리소스를 소비
HTTP통신에 비해 SSL 통신만큼 네트워크 리소스를 더 소비, SSL 통신만큼 통신 처리에 시간이 걸림
HTTPS는 HTTP에 비해서 속도가 2~100배 느리다

[Network] HTTP 헤더

dev.hyejin — Thu, 25 Jul 2024 17:13:32 +0900

리퀘스트 HTTP 메시지

HTTP 메시지 헤더

클라이언트와 서버 처리에 필요한 주요정보 거의 다 여기 있다

개행문자

HTTP 메시지 바디

사용자와 리소스를 필요로 하는 정보가 있다

HTTP 헤더 필드 구조

헤더필드 명: 필드 값

일반 헤더 필드: 리퀘스트 메시지와 리퀘스트 메시지 둘 다 사용 됨
리퀘스트 헤더 필드: 리퀘스트 부가정보와 클라이언트 정보, 리스폰스의 콘텐츠 관련 우선순위 등 포함
리스폰스 헤더 필드: 리스폰스의 정보와 서버경로, 클라이언트 추가 정보요구 등 포함
엔티티 헤더 필드: 콘텐츠 갱신시간 등 엔티티 관련 정보 포함

HTTP/1.1 이외의 헤더 필드(비표준 헤더 필드)

쿠키와 Set-Cookie, Content-Disposition

End- to-end 헤더와 Hop-by-hop 헤더

HTTP 헤더필드는, 캐시와 비캐시 프록시 동작을 정의하기 위해 2가지 카테고리로 분류

End-to-end 헤더
- 리퀘스트나 리스폰스의 최종 수신자에게 전송
- 캐시에서 구축된 리스폰스 중 보존 되어야 하고, 반드시 다시 전송되어야 함
Hop-by-hop 헤더
- 한 번 전송에 대해서만 유효
- 캐시와 프록시에 의해서 전송되지 않는 것도 있음
- Connection 헤더 필드에 열거해야 함
  - Connection
  - Keep-Alive
  - Proxy-Authenticate
  - Proxy-Authorization
  - Trailer
  - TE
  - Transfer-Encoding
  - Upgrade

응용 1 : 강의시간 자료 중에 리스폰스 헤더필드 해석

강의 시간에 api.http로 Send Request를 날렸다. 리스폰스 메시지의 헤더를 해석해보자

HTTP/1.1 200 OK HTTP 프로토콜 버전 1.1을 사용, 요청이 성공적으로 처리되었음(상태 코드 200 OK)

X-Powered-By: Express 서버가 Express.js 프레임워크를 사용하여 응답을 생성했음(선택적인 헤더로, 서버의 내부 구현정보 제공)

Content-Type: application/json; charset=utf-8 응답 본문의 내용이 JSON 형식, UTF-8 문자 인코딩을 사용하고 있음

Content-Length: 140 응답 본문의 길이가 140 바이트임. (클라이언트가 데이터를 얼마나 읽어야 하는지 알 수 있게 해줌)

ETag: W/"8c-yDWLu2PPS162ezmkGNikUkfdzrw"

이태그(ETag). 특정 버전의 리소스를 식별하는 고유한 값.
W/ 접두사는 약한(weak) ETag를 나타내며, 리소스가 근사적으로 동일함을 의미
클라이언트는 ETag를 사용하여 캐시된 리소스가 최신인지 확인 가능

Date: Thu, 25 Jul 2024 06:38:22 GMT 응답이 생성된 날짜와 시간을 GMT 표준시로 나타냄

Connection: close 이 응답 후에 서버가 TCP 연결을 닫을 것임. 클라이언트는 이 정보로 연결 관리 방식을 결정할 수 있음

응용 2: 내 GitHub 사이트로 접속 후 요청/응답 헤더필드 해석

내 GitHub 사이트로 들어가게 되면 어떠한 요청/응답 헤더를 받을까?

:method: GET HTTP 메서드. 클라이언트가 서버에 리소스를 요청하고 있음. (GET 메서드: 주로 데이터를 요청)

:scheme: https 요청이 HTTPS 프로토콜을 사용하여 보내지고 있음. (데이터가 암호화되어 전송됨)

:authority: github.com 요청을 받는 서버의 호스트 이름

:path: /clara-shin 요청하는 리소스의 경로.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

클라이언트가 서버로부터 수신할 수 있는 MIME 타입
우선 순위는 text/html, application/xhtml+xml, application/xml이 높고, 그 외 모든 타입은 우선 순위가 낮음

Accept-Encoding: gzip, deflate, br

클라이언트가 서버로부터 수신할 수 있는 콘텐츠 인코딩 방식
여기서는 gzip, deflate, br(Brotli) 압축 방식을 수용할 수 있음

Accept-Language: ko-KR,ko;q=0.9

클라이언트가 선호하는 언어
여기서는 한국어(ko-KR 및 ko)를 선호

Connection: keep-alive

클라이언트가 서버에 지속적인 연결을 유지하고 싶다는 의사를 나타냄
이를 통해 여러 요청을 하나의 TCP 연결로 처리할 수 있음

Cookie: _gh_sess=3NvvsACwt1dVQD....

클라이언트가 서버에 전송하는 쿠키 데이터
이 예시에서는 _gh_sess 쿠키가 포함(쿠키는 클라이언트와 서버 간의 상태 정보를 유지하는 데 사용)

Host: github.com 요청을 받는 서버의 호스트 이름(어떤 서버로 요청을 보내는지)

Referer:https://github.com/

클라이언트가 현재 요청을 보내기 전에 방문했던 URL
서버는 사용자가 어떤 경로를 통해 현재 페이지에 접근했는지 알 수 있음

Sec-Fetch-Dest: document 클라이언트가 서버에서 어떤 유형의 리소스를 요청하는지. 여기서는 문서(document)를 요청하고 있음

Sec-Fetch-Mode: navigate 클라이언트가 서버와 어떻게 상호 작용하는지. navigate: 클라이언트가 탐색을 위해 리소스를 요청하고 있음

Sec-Fetch-Site: same-origin 요청이 동일 출처(same-origin)에서 발생했음. 즉, 요청의 출처와 목적지가 동일한 도메인임을 의미

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15

클라이언트의 브라우저 및 운영 체제 정보를 포함. 여기서는 Mac OS X 10.15.7을 사용하는 Safari 17.5 브라우저

Cache-Control: max-age=0, private, must-revalidate 캐싱 동작을 제어

max-age=0: 리소스가 즉시 만료됨. 클라이언트는 항상 서버로부터 새로운 복사본을 요청해야 함.
private: 리소스가 특정 사용자에게만 캐시될 수 있음. 공유 캐시(예: 프록시 서버)에서는 캐시할 수 없음.
must-revalidate: 만료된 리소스가 재검증 없이 사용될 수 없음. 캐시된 데이터가 만료되면 반드시 서버로부터 새로운 데이터를 받아야함.

Content-Encoding: gzip

응답 본문이 gzip으로 압축되었음
클라이언트는 응답을 수신한 후 이를 gzip 형식으로 디코딩해야 함

Vary: X-Requested-With, X-PJAX-Container, Turbo-Frame, Turbo-Visit, Accept-Encoding, Accept, X-Requested-With

서버가 클라이언트 요청 헤더의 특정 필드를 기반으로 서로 다른 응답을 제공할 수 있음
즉, 다음과 같은 헤더가 달라질 경우 서버는 다른 응답을 제공할 수 있음
- X-Requested-With
- X-PJAX-Container
- Turbo-Frame
- Turbo-Visit
- Accept-Encoding
- Accept
- X-Requested-With

[React] React Hook: useEffect()

dev.hyejin — Sun, 21 Jul 2024 21:10:07 +0900

React는 Component를 호출하고, Component는 React에게 HTML을 준다.

그럼 React는, 컴포넌트가 리턴한 HTML로 VDOM을 만들고, VDOM은 DOM을 만든다.

React이 Component를 호출했을 때 비동기 작업이 있다면, Component 안에서 비동기(async) 호출을 한다

비동기 호출은 Server에 요청을 하고, Server는 컴포넌트에게 응답(Data)을 준다

응답을 주는데 100ms의 시간이 걸린다면?

React가 Component를 호출했을 때, Component는 함수이기 때문에 호출 후 바로 리턴을 해야 하는데,

Component에서 HTML을 리턴하는데는 5ms가 걸린다면?

React가 Component를 호출하고 Component가 HTML을 React로 리턴하는데 5ms가 걸린다

그 사이 Component는 async 호출을 해서 100ms 뒤에 data를 받고 Component는 HTML을 생성하는데, 이미 리턴했잖아

React component는 함수라서 호출을 해야 리턴할 수 있음

호출을 하는 주체는 리액트임

이미 리액트는 5ms안에 컴포넌트 호출해서 VDOM만들고 DOM 만듬

하지만 한참 뒤에(100ms뒤에) 응답이 오면, 이후 HTML만들어서 주고 싶어도 줄 수가 없음.

그렇다면 비동기 작업은 어떡하지?

비동기작업: 순수함수가 아님, 항상 성공하는 작업이 아님. 성공할수도 있고 실패할 수도 있음, 부수효과(side effect) 가능한 코드들(예상할수 없는 코드들)임

순수함수: 항상 성공하는 함수 (예) 10*5 하는 함수,

api 호출은 비동기 함수이므로 순수함수와 분리되어야 하고, 리액트에서는 useEffect()함수를 제공함

useEffect(리액트에서 제공해주는 Hook)

사이드이펙트(Side-Effect)를 관리해주는 함수

useEffect() 안에 비동기 함수를 처리하면, 비동기 처리가 끝난 후 리액트가 한번 더 컴포넌트를 호출해서 받아온 데이터가 적용된 HTML을 재렌더링함

[React] 컴포넌트(Component)란?

dev.hyejin — Sun, 21 Jul 2024 15:13:23 +0900

컴포넌트(Component)

UI를 구성하는 독립적이고 재사용 가능한 코드 단위
버튼, 입력 필드, 네비게이션 바

컴포넌트 특징

재사용성: 동일한 컴포넌트를 여러 곳에서 재사용할 수 있어 코드의 중복을 줄임(DRY)
독립성: 각 컴포넌트를 독립적으로 개발하고 테스트할 수 있음
컴포넌트는 내부 상태와 외부에서 전달받은 데이터를 통해 동작을 제어하고 UI를 렌더링 함
컴포넌트는 생명주기를 가지며, 생성, 업데이트, 제거의 과정을 거친다

리액트 컴포넌트

함수형: React Hooks를 사용하여 생명주기 메서드를 구현
클래스형(ES6 클래스): `componentDidMount`, `componentDidUpdate` 같은 메서드를 사용

[React] JSX의 이스케이프 백(escape back)

dev.hyejin — Sat, 20 Jul 2024 00:43:02 +0900

JSX 코드 내에서 JavaScript 표현식을 사용하는 방법(Escape into JavaScript from JSX attributes)

JSX는 JavaScript 코드 내에 마크업(HTML) 코드를 포함할 수 있게 해줌
이때, 중괄호 { }를 사용하여, JSX 코드 내에서 JavaScript로 "탈출(이스케이프)"하여 변수나 표현식을 사용할 수 있음

return (
  <h1>
    {user.name} // 자바스크립트로 이스케이프 한 부분
  </h1>
);

중괄호{ } 안에 JavaScript 표현식(변수를 속성값으로 전달)을 넣으면, 그 값이 해당 위치에 렌더링 됨

return (
  <img
    className="avatar"
    src={user.imageUrl}
  />
);

src 속성에 user.imageUrl 변수의 값을 전달하여 이미지의 경로를 설정
반면에 className="avatar"는 단순히 문자열을 전달하는 경우로, 이때는 중괄호 대신 큰 따옴표를 사용

JSX에서 "이스케이프 백(escape back)"은, 중괄호를 사용하여 JavaScript 표현식을 사용하거나 변수를 삽입하는 것을 의미한다. 이를 통해, JavaScript와 JSX를 유연하게 결합하여 동적인 UI를 만들 수 있다.

[React] 리액트 컴포넌트의 이벤트 핸들러

dev.hyejin — Sat, 20 Jul 2024 00:26:30 +0900

함수 컴포넌트가 어떤 순서로 업데이트 되는지(재렌더링 되는지) 보면

import { useState } from 'react';

function MyButton() {
  const [count, setCount] = useState(0);
  
  function handleClick() {
    setCount(count + 1);
  }
  
  return (
  	<button onClick={handleClick}>
    	Clicked {count} times
    </button>
   );
}

count = 0 인 상태로 버튼이 보이고,
버튼을 클릭했을 때 handleClick 함수를 호출하면,
setCount함수에 count + 1을 넘겨주며 실행
이때, 리액트는 업데이트 해야 하는 것을 알아차리고 다시 렌더링 한다.
setCount함수에 count + 1을 넘겨주며, 실행되는 과정에서 클로저(외부 스코프의 값을 기억)로 인해 외부 스코프에 있는 count 값인 0을 참조하고 거기에 1을 더한다.
다시 return 코드로 넘어가서 Clicked 1(count값이 업데이트 되어 보여짐) times 버튼이 보이고,
한번 더 클릭하면 다시 handleClick가 호출되고, handleClick의 setCount(count+1)가 실행된다.