99mini · 99mini · Jul 18, 2025 · Jul 12, 2025 · Jul 12, 2025 · Jul 12, 2025
diff --git a/README.MD b/README.MD
@@ -1,3 +1,9 @@
+<div align="center">
+
+[![wakatime](https://wakatime.com/badge/user/32601717-9798-42b7-a297-7ec7581ff7c8/project/f40aa11e-85ba-42e4-9403-01cd240890ab.svg)](https://wakatime.com/badge/user/32601717-9798-42b7-a297-7ec7581ff7c8/project/f40aa11e-85ba-42e4-9403-01cd240890ab)
+
+</div>
+
 # Zero Voyage
 
 - @since 2025-02-03

diff --git a/apps/frontend/tech/blog/2025-02-24-http-get-post.md b/apps/frontend/tech/blog/2025-02-24-http-get-post.md
@@ -24,7 +24,7 @@ HTTP([HyperText Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc7231
 
 ### HTTP/1.1
 
-HTTP/1.1은 1997년에 도입된 HTTP의 첫 번째 표준 버전입니다. 주요 특징은 다음과 같습니다:
+HTTP/1.1은 1997년에 도입된 HTTP의 첫 번째 표준 버전입니다. 주요 특징은 다음과 같습니다
 
 - **지속적 연결(Persistent Connection)**: 한 번의 TCP 연결로 여러 요청과 응답을 처리할 수 있습니다.
 - **파이프라이닝(Pipelining)**: 응답을 기다리지 않고 여러 요청을 연속적으로 보낼 수 있습니다.
@@ -37,7 +37,7 @@ HTTP/1.1은 1997년에 도입된 HTTP의 첫 번째 표준 버전입니다. 주
 
 ### HTTP/2.0
 
-HTTP/2.0은 2015년에 표준화된 버전으로, HTTP/1.1의 성능 제한을 해결하기 위해 설계되었습니다:
+HTTP/2.0은 2015년에 표준화된 버전으로, HTTP/1.1의 성능 제한을 해결하기 위해 설계되었습니다
 
 - **멀티플렉싱(Multiplexing)**: 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리
 - **서버 푸시(Server Push)**: 클라이언트의 요청 없이도 서버가 리소스를 보낼 수 있음

diff --git a/apps/frontend/tech/blog/tags.yml b/apps/frontend/tech/blog/tags.yml
@@ -33,6 +33,11 @@ sqld:
   permalink: /운영체제
   description: 운영체제
 
+웹:
+  label: 웹
+  permalink: /웹
+  description: 웹
+
 알고리즘:
   label: 알고리즘
   permalink: /알고리즘

diff --git a/apps/frontend/tech/docs/intro.md b/apps/frontend/tech/docs/intro.md
@@ -20,6 +20,7 @@ sidebar_position: 0
 1. [독서: code complete2](/docs/category/code-complete2)
 2. [네트워크](/docs/category/네트워크)
 3. [운영체제](/docs/category/운영체제)
+4. [웹](/docs/category/웹)
 
 ## 프론트엔드
 

diff --git a/apps/frontend/tech/docs/reactjs/state-vs-props.md b/apps/frontend/tech/docs/reactjs/state-vs-props.md
@@ -0,0 +1,91 @@
+---
+sidebar_position: 1
+slug: state-vs-props
+title: 'React에서 State와 Props의 차이'
+authors: [99mini]
+tags: [javascript, react]
+date: 2025-07-12
+---
+
+React에서 State와 Props의 차이
+
+<!-- truncate -->
+
+## 요약
+
+|            | Props                                 | State                        |
+| ---------- | ------------------------------------- | ---------------------------- |
+| 소유권     | 부모 컴포넌트 소유                    | 컴포넌트 소유                |
+| 목적       | Data communication between components | Internal data management     |
+| Mutability | 불변 (Read Only)                      | 변경 가능 (Mutable)          |
+| Data Flow  | Passed down from parent to child      | Managed within the component |
+
+## Props
+
+Props는 부모 컴포넌트가 자식 컴포넌트에게 전달하는 데이터
+
+```jsx
+function Parent() {
+  return <Child name="John" />;
+}
+
+function Child({ name }) {
+  return <div>{name}</div>;
+}
+```
+
+### 자식 컴포넌트에서 Props를 변경하기
+
+자식 컴포넌트에서 Props를 변경하기 위해서는 부모 컴포넌트에서 State를 사용.
+자식이 부모의 데이터를 직접 바꾸지 못하고, 콜백 함수로 부모에게 요청만 할 수 있다.
+
+```jsx
+function Parent() {
+  const [name, setName] = useState('John');
+
+  return (
+    <div>
+      <Child name={name} onNameChange={setName} />
+    </div>
+  );
+}
+
+function Child({ name, onNameChange }) {
+  return (
+    <div>
+      <p>Name: {name}</p>
+      <button onClick={() => onNameChange('Jane')}>Change Name</button>
+    </div>
+  );
+}
+```
+
+## State
+
+State는 컴포넌트 내부에서 관리하는 데이터
+
+```jsx
+function Counter() {
+  const [count, setCount] = useState(0);
+
+  return (
+    <div>
+      <p>Count: {count}</p>
+      <button onClick={() => setCount(count + 1)}>Increment</button>
+    </div>
+  );
+}
+```
+
+### State가 아닌 경우
+
+1. Props로 전달된 값
+2. 상수
+3. 지역 변수
+4. DOM 요소
+
+### State 반별하기
+
+1. 변경 가능성: state는 동적으로 변경된다. state가 아닌 것들은 일반적으로 변경되지 않거나 변경되더라도 컴포넌트의 렌더링에 영향을 미치지 않는다.
+2. 저장 위치: state는 컴포넌트 내부에서 관리된다. state가 아닌 것들은 컴포넌트 외부, props, 상수, 지역 분수 등에 저장
+3. 렌더링 트리거: state의 변경은 컴포넌트의 리렌더링을 트리거한다. 단, state가 변경된다고 해서 반드시 렌더링이 트리거되는 것은 아니다.
diff --git a/apps/frontend/tech/docs/네트워크/HTTP-1.1-RFC-7321.md b/apps/frontend/tech/docs/네트워크/HTTP-1.1-RFC-7321.md
@@ -0,0 +1,192 @@
+---
+sidebar_position: 2
+slug: http1.1-rfc7321
+title: 'HTTP/1.1: RFC 7321'
+authors: [99mini]
+tags: [네트워크, http]
+date: 2025-07-12
+---
+
+HTTP/1.1 프로토콜. rfc7321 번역하며 정리한 내용입니다.
+
+:::warning 작성중
+
+2025-07-12 작성 시작
+
+:::
+
+<!-- truncate -->
+
+## HTTP란?
+
+HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버 간의 통신을 위한 프로토콜.
+이는 웹 브라우저(클라이언트)가 웹 서버와 통신할 때 사용하는 주요 방법으로, 요청(Request)과 응답(Response) 방식으로 동작
+
+## HTTP/0.9
+
+- 1989년 팀 버너 리(Tim Berners-LEE)에 의해 제안된 인터넷의 하이퍼 텍스트 시스템
+- `GET` 메서드만 지원
+- `HTTP 헤더`, `상태 코드` 미지원
+- 응답: HTML 파일 자체만 보내줌
+- 특정 HTML 파일을 오류에 대한 설명과 함께 반환
+- 서버와 클라이언트 간의 연결은 모든 요청 후에 닫힘(closed)
+
+## HTTP/1.0
+
+- 1996년에 발표된 HTTP의 첫 버전으로, 기본적인 HTTP 기능을 제공 (RFC 1945)
+- `GET`, `POST` 메서드만 지원
+- 상태 코드(status code)가 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작을 할 수 있음
+- 응답 헤더의 Content-Type 덕분에 HTML 파일 형식 외에 다른 문서들을 전송하는 기능이 추가
+- 단기커넥션: 커넥션 하나당 1 request & 1 response 처리
+
+### HTTP/1.0 문제점
+
+- 비연결성으로 인한 딘기 커넥션
+- html, css, javascript, 미디어 등 많은 자원을 다운로드할 때 매번 새로운 TCP 연결을 맺어야 함
+- `연결 -> 응답 -> 종료`를 반복함으로 속도가 느림
+
+## HTTP/1.1
+
+- 1997년에 발표된 HTTP의 두 번째 버전으로, HTTP/1.0의 단점을 개선
+
+### HTTP/1.1 특징
+
+- **지속 연결(Persistent Connection)**: 지정한 timeout 동안 연속적인 요청 사이에 연결을 유지. 기존 연결에 대하여 핸드쉐이크 생략 가능
+- **파이프 라이닝(Pipelining)**: 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능하게 함. 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간 줄임
+- 도메인 공유(Domain Sharding): 동일 IP 주소에 다른 도메인을 호스트하는 기능
+- Chunk Encoding 전송
+- 바이트 범위 변경
+- 캐시 제어 메커니즘 도입
+
+#### 지속 연결(Persistent Connection: keep-alive)
+
+- HTTP는 TCP 연결 기반으로 동작하여 프로토콜의 신뢰성을 확보
+- 3-ways hand shake를 통해 연결을 유지
+- HTTP/1.0은 비연결성 프로토콜이기 때문에 자원을 요청할 때마다 연결을 맺고 종료하는 과정에서 오버헤드 발생
+
+##### Persistent Connection
+
+- 연결을 유지하여 핸드쉐이크 과정을 생략해 빠르게 자원을 요청 및 응답 가능
+- 불필요한 연결의 맺고 끊음을 최소화하여 네트워크 부하 감소
+- 클라이언츠 측에서 요청에 `keep-alive` 헤더를 추가하여 지속 연결을 요청
+- 정확한 `Content-Length` 헤더를 포함하여 응답의 크기를 명시적으로 지정
+- `Connection` 헤더를 지원하지 않는 프록시에서 사용 불가
+
+```bash title="request"
+GET / HTTP/1.1
+Host: example.com
+Connection: keep-alive
+```
+
+```bash title="response"
+HTTP/1.1 200 OK
+Content-Length: 1234
+Connection: Keep-Alive
+Keep-Alive: timeout=5, max=100
+```
+
+max: keep-alive를 통해서 주고 받을 수 있는 request의 최대 갯수. max 초과 요청 시 connection은 closed
+timeout: keep-alive connection 유지 시간. timeout 초 이후 connection은 closed
+
+```bash title="request with connection close"
+GET / HTTP/1.1
+Host: example.com
+Connection: close
+```
+
+```bash title="response"
+HTTP/1.1 200 OK
+Content-Length: 1234
+Connection: close
+```
+
+#### 파이프 라이닝(Pipelining)
+
+여러개의 요청을 보낼 때 처음 요청의 응답을 기다리지 않고 바로 요청을 한번에 보내는 것.
+
+- keep-alive connection이 필요
+- 서버는 요청이 들어온 순서로 응답 (FIFO)
+- 응답 순서를 지키기 위해 응답 처리를 미루기 때문에 _Head of Line Blocking_ 현상 발생. 모던 브라우저들은 대부분 파이프라이닝을 막음
+- HTTP/2에서 멀티플렉싱 알고리즘으로 대체
+
+#### 도메인 공유(Domain Sharding)
+
+파이프 라이닝을 대체하기 위한 차선책으로 나온 기술. 브라우저들은 하나의 도메인에 대해 여러 개의 Connection을 생성해서 병렬로 요청 주고 받음
+
+- 도메인 주소를 찾기 위한 DNS Lookup 과정에서 오버헤드 발생 가능
+- 브라우저별 도메인당 커넥션 수 제한이 존재
+
+---
+
+아래 내용부터는 **_rfc7231_** 문서의 목차와 동일하게 구성. 번역을 인용할 때는 [RFC 7231 - pdf](https://www.rfc-editor.org/rfc/pdfrfc/rfc7231.txt.pdf) 파일 기준 페이지를 함께 작성합니다.
+
+## 1. Introduction
+
+## 2. Resources
+
+## 3. Representations
+
+## 4. Request Methods
+
+### Common Method Properties
+
+#### Safe Methods
+
+#### Idempotent Methods
+
+#### Cacheable Methods
+
+### Method Definitions
+
+| Method  | 설명                                             |
+| ------- | ------------------------------------------------ |
+| GET     | 서버에서 데이터를 가져오는 요청                  |
+| HEAD    | 서버에서 데이터를 가져오는 요청                  |
+| POST    | 서버에 데이터를 보내는 요청                      |
+| PUT     | 서버에 데이터를 업데이트하는 요청                |
+| PATCH   | 서버에 데이터를 **부분적**으로 업데이트하는 요청 |
+| DELETE  | 서버에서 데이터를 삭제하는 요청                  |
+| CONNECT | 서버와의 연결을 유지하는 요청                    |
+| OPTIONS | 서버가 지원하는 HTTP 메서드를 조회하는 요청      |
+| TRACE   | 서버가 받은 요청을 그대로 응답하는 요청          |
+
+> [HTTP - GET vs POST](/blog/http-get-post)에 대한 개시글
+
+#### GET
+
+#### HEAD
+
+#### POST
+
+#### PUT
+
+#### DELETE
+
+#### CONNECT
+
+#### OPTIONS
+
+#### TRACE
+
+## 5. Request Header Fields
+
+## 6. Response Status Codes
+
+## 7. Response Header Fields
+
+## 8. IANA Considerations
+
+## 9. Security Considerations
+
+---
+
+## 참고문헌
+
+### 내부 링크
+
+- [HTTP - GET vs POST](/blog/http-get-post)
+
+### 외부 링크
+
+- [rfc7231](https://datatracker.ietf.org/doc/html/rfc7231)
+- [HTTP-09-HTTP-30-까지-알아보는-통신-기술#http\_/_0.9](https://inpa.tistory.com/entry/WEB-🌐-HTTP-09-HTTP-30-까지-알아보는-통신-기술#http_/_0.9)
diff --git a/apps/frontend/tech/docs/운영체제/프로세스-쓰레드.md b/apps/frontend/tech/docs/운영체제/프로세스-쓰레드.md
@@ -187,25 +187,32 @@ Context Switching이란, 운영체제가 CPU에서 현재 실행 중인 프로
 - 문맥 교환 빈도 낮음 (완료 후에만 전환)
 - Overhead 낮음, 응답 시간은 비효율적일 수 있음
 
-2. SJF (Shortest Job First)
+2. SJF(Shortest Job First)
 
 - 비선점 또는 선점형(Priority + Preemption) 가능
 - 평균 대기 시간 최소화
 - 선점형일 경우 문맥 교환 발생 가능성 ↑
 
-3.  Round Robin (RR)
+3. SRT(Short Remaing Time)
+
+- 선점형(Priority + Preemption) 가능
+- 남은 실행 시간이 가장 짧은 프로세스를 선점
+- 평균 대기 시간 최소화
+- 문맥 교환 발생으로 인한 오버헤드 ↑
+
+4. Round Robin (RR)
 
 - 선점형(Preemptive) 알고리즘의 대표
 - 타임 슬라이스(quantum)마다 강제 문맥 교환
 - 문맥 교환 횟수 많음 → 오버헤드 증가
 
-4. Priority Scheduling
+5. Priority Scheduling
 
 - 선점형 가능
 - 더 높은 우선순위 프로세스 등장 시 즉시 전환 → 문맥 교환 발생
 - 우선순위 역전(Priority Inversion) 문제 발생 가능
 
-5. Multilevel Queue / Feedback Queue
+6. Multilevel Queue / Feedback Queue
 
 - 여러 큐 레벨에 따라 다른 정책 적용
 - 문맥 교환이 빈번히 발생하며, CPU 사용 패턴에 따라 큐 이동 시 전환

diff --git a/apps/frontend/tech/docs/웹/_category_.json b/apps/frontend/tech/docs/웹/_category_.json
@@ -0,0 +1,8 @@
+{
+  "label": "웹",
+  "position": 104,
+  "link": {
+    "type": "generated-index",
+    "description": "웹 기술 (브라우저, 인터넷, 웹 표준...)"
+  }
+}