1. [1번 vs 2번] 비교: "SELECT 다이어트의 중요성"

• 차이점: 1번은 SELECT * (모든 컬럼)을 가져오고, 2번은 인덱스에 있는 name 컬럼만 가져옵니다.
• Plan 변화: Bitmap Heap Scan (1번) → Index Only Scan (2번)
• 결과 해석: 1번은 인덱스(name)에 없는 id, email, signup_date를 찾으러 실제 데이터 테이블(Heap)로 가야만 했습니다. 반면, 2번은 Planner(플래너)가 "인덱스만 봐도 답이 다 있네?"라고 판단해 테이블 근처에도 가지 않았습니다.
• 학습 한 줄 정리: 불필요한 컬럼을 버리는 'SELECT 다이어트'만으로도 디스크 방문(Heap Scan)을 막을 수 있습니다.

2. [2번 vs 3번] 비교: "인덱스 범위를 벗어난 필터"

• 차이점: 3번은 WHERE 절에 인덱스에 없는 signup_date 조건을 추가하고, SELECT 결과에도 포함했습니다.
• Plan 변화: Index Only Scan (2번) → Bitmap Heap Scan (3번)
• [cite_start]결과 해석: 3번은 인덱스에 없는 signup_date를 확인하고 출력해야 하므로, Executor(실행기)가 실제 데이터 파일 영역을 뒤져야 하는 비싼 비용(Cost)을 지불하게 된 것입니다[cite: 324, 331].
• 학습 한 줄 정리: 인덱스에 없는 컬럼을 조건이나 결과에 넣는 순간, '인덱스 전용 스캔'의 마법은 풀립니다.

3. [3번 vs 4번] 비교: "단일 인덱스 vs 복합 인덱스"

• 차이점: 3번은 name만 있는 인덱스고, 4번은 (name, signup_date)가 묶인 복합 인덱스입니다.
• Plan 변화: Bitmap Heap Scan (3번) → Index Only Scan (4번)
• 결과 해석: 4번은 자주 같이 쓰이는 두 컬럼을 하나로 묶어버렸습니다. [cite_start]플래너는 이제 signup_date 정보까지 인덱스 안에서 모두 찾을 수 있게 되어 다시 가장 빠른 경로를 선택했습니다[cite: 322, 324].
• 학습 한 줄 정리: 자주 함께 쓰이는 필터 조건들은 '복합 인덱스'로 묶어야 플래너가 가장 '싼 비용'의 계획을 세웁니다.

4. [1번 vs 5번] 비교: "인덱스 전용 스캔의 마법, Covering Index"

• 차이점 (Condition): * 1번: SELECT로 테이블의 모든 컬럼(id, name, email, signup_date)을 요구하지만, 인덱스는 name 하나만 가지고 있습니다.

  • 5번: SELECT id, name, email을 요구하며, 인덱스 생성 시 INCLUDE (id, email)를 사용하여 결과에 필요한 데이터를 인덱스 안에 미리 복사해 두었습니다.

• Plan 변화 (Query Plan): Bitmap Heap Scan → Index Only Scan

• 결과 해석 (Interpretation): * 1번은 인덱스에 없는 나머지 정보를 찾기 위해 Planner(플래너)가 실제 Data Files(Heap) 영역을 뒤져야 한다고 판단했습니다. 이 과정에서 디스크 읽기(read)가 발생하며 비용이 급증합니다.

  • 5번은 여러 컬럼을 요구함에도 불구하고, 필요한 모든 데이터가 인덱스라는 '보조 주머니'안에 다 들어있습니다. Executor(실행기)는 무거운 테이블 파일(base/ 디렉토리) 근처에도 가지 않고 인덱스만으로 모든 응답을 끝냈습니다.

• 학습 한 줄 정리: 검색 조건은 아니지만 결과로 자주 쓰이는 데이터는 INCLUDE로 인덱스에 태워두면, '테이블 방문' 없는 초고속 조회가 가능합니다.

데이터를 분석하다 보면, 아래로 길게 나열된 행(Row) 데이터를 엑셀 피벗 테이블처럼 옆으로(Column) 펼쳐야 할 때가 많습니다. SQL에서 이를 구현하는 두 가지 정석 방법을 정리합니다.

1. 가장 클래식한 방법: CASE WHEN + SUM

별도의 설치 없이 모든 SQL 엔진에서 사용할 수 있는 가장 범용적인 방식입니다.

✅ 작동 원리

특정 조건일 때만 값을 남기고, 아니면 0을 주어 합산하는 방식입니다.

SELECT 
    prod_month,
    SUM(CASE WHEN breeds_nm = 'Cornish' THEN total_sum ELSE 0 END) AS "Cornish_Total",
    SUM(CASE WHEN breeds_nm = 'Cochin' THEN total_sum ELSE 0 END) AS "Cochin_Total",
    SUM(total_sum) AS monthly_total
FROM breeds_prod
GROUP BY prod_month;

⚠️ 주의할 점 (삽질 포인트)

• 별칭 사용 주의: SELECT 절에서 만든 별칭(예: prod_month)은 엔진에 따라 GROUP BY에서 바로 쓸 수 있지만, SUM으로 만든 결과물 별칭은 GROUP BY에서 쓸 수 없습니다. (닭이 먼저냐 달걀이 먼저냐의 싸움 방지!)
• 0 또는 NULL: 합계 시 ELSE 0을 써야 NULL 때문에 전체 합계가 NULL이 되는 대참사를 막을 수 있습니다.

2. 전문가의 도구: tablefunc와 crosstab

PostgreSQL을 사용한다면 tablefunc 확장 기능을 사용하여 더 세련되게 피벗할 수 있습니다.

🛠 준비 단계 (Import와 동일)

CREATE EXTENSION IF NOT EXISTS tablefunc;

• 의미: DB에 '피벗 전용 도구 상자'를 들여놓는 것. 한 번만 실행하면 됩니다.

🍱 crosstab의 '3단 도시락' 규칙

crosstab 함수는 반드시 딱 3개의 컬럼으로 구성된 쿼리를 입력받아야 합니다.

1. 첫 번째 컬럼: 행의 기준 (예: 부화일자)
2. 두 번째 컬럼: 열(컬럼명)이 될 카테고리 (예: 성별)
3. 세 번째 컬럼: 실제 칸을 채울 값 (예: 마릿수)

✅ 실행 코드 예시

SELECT * FROM crosstab(
    --count는 bigint를 내뱉으므로 int로 형변환
    'SELECT hatchday, gender, count(chick_no)::int 
     FROM chick_info 
     GROUP BY hatchday, gender 
     ORDER BY hatchday, gender' -- 반드시 정렬(ORDER BY) 필요!
) AS 별칭(
    hatchday date,  -- 첫 번째 컬럼 (기준)
    male int,       -- 두 번째 컬럼 (값)
   female int       -- 세 번째 컬럼 (값)
); --열 이름의 타입이 아니라 내부 값의 타입을 적어야한단다

⚠️ 주의할 점 (삽질 포인트)

• 쿼리는 문자열이다: crosstab은 함수이므로 내부 쿼리를 통째로 작은따옴표(')로 감싸서 문자열 데이터로 넘겨야 합니다.
• 설계도(AS) 필수: crosstab은 결과 모양을 스스로 알지 못하므로, AS 별칭(컬럼명 타입, ...)으로 결과표의 구조를 명시해줘야 합니다.
• 따옴표 규칙: 설계도 안에서 컬럼 이름에 작은따옴표를 쓰면 에러가 납니다. ('male' ❌ → male ⭕)

SQL을 배울 때 우리는 분명 실행 순서를 다음과 같이 배웁니다.

1. FROM / JOIN
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT (이때 별칭 AS가 생성됨)
6. ORDER BY

그런데 아래 쿼리는 에러 없이 아주 잘 작동합니다.

SELECT to_char(prod_date, 'YYYYMM') AS prod_month, -- 5번: 별칭 생성
       SUM(total_sum) AS monthly_total
FROM breeds_prod
GROUP BY prod_month; -- 3번: 그런데 어떻게 5번에서 만든 별칭을 미리 쓰지?

논리적으로는 3번(GROUP BY) 단계에서 아직 존재하지도 않는 5번(SELECT)의 별명을 부르는 '타임 패러독스'가 발생합니다. 왜 그런 걸까요?

2. 범인은 똑똑한 'SQL 엔진'

우리가 코드를 던지면 데이터베이스 엔진(PostgreSQL, MySQL 등)은 실행 전 코드를 전체적으로 훑어보는 파싱(Parsing) 단계를 거칩니다.

• 엔진의 판단: "GROUP BY에 쓰인 prod_month가 뭐지? 아, SELECT 절을 보니 단순 날짜 변환식이네? 내가 미리 계산해서 그룹을 묶어줄게!"
• 실제 실행: 논리적 순서는 지키되, 엔진이 개발자의 편의를 위해 SELECT 절의 단순 별칭을 미리 참조할 수 있게 설계되어 있기 때문입니다.

3. "무조건" 다 되는 건 아니다! (중요한 차이)

여기서 가장 중요한 포인트는 '어떤' 별칭이냐는 것입니다.

✅ 가능한 경우: 단순 변환 별칭

• to_char, SUBSTRING, REPLACE 등 행 하나하나에 바로 적용되는 식의 별칭은 GROUP BY에서 쓸 수 있습니다. 엔진이 미리 계산하기 쉽기 때문이죠.

❌ 불가능한 경우: 집계 함수의 별칭

• SUM, AVG, COUNT 등으로 만든 별칭은 절대로 GROUP BY에서 쓸 수 없습니다.
• 이유: 집계 함수는 '그룹화가 완료된 후'에야 값이 결정됩니다. 그룹을 묶기 위해 그룹이 묶여야 나오는 값을 가져다 쓰는 것은 불가능하기 때문입니다. (순환 참조 오류)

4. 정리하며

• SQL의 논리적 순서와 엔진의 실제 최적화 순서는 다를 수 있다.
• PostgreSQL 같은 현대적인 DB는 SELECT의 별칭을 GROUP BY에서 쓸 수 있게 지원한다. (단순 식에 한함)
• 이 원리를 이해하면 쿼리 가독성을 높이면서도 성능 최적화를 고려하는 데이터 엔지니어로 성장할 수 있다!

구조가 깨졌지만 메타데이터로 page 확인이 가능하다면 그냥 문서에서 다시 해당 page를 가져와서 분할을 시도하는게 더 낫지 않아? 그렇게 안하는 이유가 뭐야?

실무적인 데이터 엔지니어링 환경에서 '원천 페이지 재호출'을 하지 않고 '강제 분할'을 선택하는 데에는 몇 가지 현실적인 이유가 있습니다.

1. "같은 기계(Parser)는 같은 불량을 냅니다"

가장 결정적인 이유입니다. utils.py에서 8,000자가 넘는 노드가 발생했다는 건, 그 페이지를 읽어낸 PDF 파서(Parser)가 이미 해당 페이지의 구조를 해석하는 데 실패했다는 뜻입니다.

2. 비용과 속도: "공정의 병목 현상"

데이터 파이프라인은 보통 [원천 파일 → 전체 텍스트 추출 → 노드 분할 → 필터링]의 단방향 흐름으로 설계됩니다.

• IO 부하: 필터링 단계에서 갑자기 "이 페이지 다시 읽어와!"라고 역행하면, 닫혀 있던 PDF 파일을 다시 열고, 해당 페이지를 찾고, 다시 파싱하는 무거운 작업이 추가됩니다.
• 비효율: 만약 1,000페이지 중 100페이지에서 이런 문제가 생기면, 전체 처리 속도가 기하급수적으로 느려지는 병목(Bottleneck) 현상이 발생합니다.

3. "데이터 심폐소생술"의 관점

우리가 하려는 강제 분할(Force-chopping)은 '완벽한 복구'라기보다는 '최소한의 검색 가능성 확보'에 가깝습니다.

• 구조는 포기, 키워드는 보존: 비록 문단은 깨졌어도 8,000자 안의 단어들은 살아있습니다. 1,000자씩 잘라두면, 나중에 사용자가 그 안의 키워드로 질문했을 때 검색 결과에는 걸리게 됩니다.
• LLM의 추론 능력: 요즘 LLM은 앞뒤가 조금 잘린 문맥이라도 검색된 조각들을 합쳐서 주면, 그 안에서 의미를 찾아내 답변을 생성합니다.

정말로 "원천 페이지에서 다시 제대로 가져오고 싶다"면, 단순 재시도가 아니라 '다른 공정(다른 파서)'을 써야 합니다.

[개선된 공정 제안]

1. 기본 파서로 전체 파싱 진행.
2. 8,000자 초과 노드 발생 시 '비상 공정' 가동.
3. 해당 페이지를 텍스트가 아닌 이미지(OCR)로 읽거나, 훨씬 정교한(하지만 느린) AI 기반 파서로 해당 페이지만 다시 읽기.

1. 중괄호 {}의 공통분모: 해시 테이블(Hash Table)

두 자료형이 같은 괄호를 공유하는 가장 큰 이유는 내부적으로 데이터를 저장하는 메커니즘이 똑같기 때문입니다.

1. 해시 테이블 기반: 처음부터 끝까지 뒤지는 게 아니라, 주소를 계산해서 한 번에 찾아가는 방식을 사용 (Random Access)
2. 중복 불허: 해시 테이블 특성상 set은 값의 중복을 허용하지 않고, dict는 키(key)의 중복을 허용하지 않습니다. 데이터가 저장될 위치가 데이터 그 자체(값 또는 키)에 의해 이미 결정되어 있기 때문입니다. (Hash Function)*

• 해시 함수(Hash Function): 어떤 데이터를 넣든 고유한 주소값(인덱스)으로 변환해주는 계산기입니다.

💡 여기서 잠깐! "중복 불허"와 "해시"의 상관관계

해시 테이블은 데이터의 값 자체가 저장 위치를 결정합니다.

1. hash("apple")이 5번 방이라면, 사과는 무조건 5번에 들어갑니다.
2. 또 다른 사과를 넣으려 해도 다시 5번 방을 가리킵니다.
3. 가서 보니 이미 "사과"가 있네? 그럼 새로 저장하지 않습니다. 이것이 바로 set과 dict(key)에서 중복이 불가능한 기술적 이유입니다.

2. Set vs Dictionary: 어떻게 구분할까?

파이썬은 중괄호 안의 콜론(:) 유무로 둘을 구분합니다.

⚠️ 주의: 빈 괄호 {}는 파이썬에서 Dictionary로 인식됩니다. 빈 집합을 만들고 싶다면 반드시 set()을 사용하세요!

3. 왜 List의 pop()은 인덱스고, remove()는 값일까?

이 질문의 답은 영어 단어의 본래 의미와 자료구조의 역사에 있습니다.

① pop(): 튀어'나오다' (값을 나에게 쥐어줌)

• 유래: 데이터가 쌓여 있는 스택(Stack)에서 맨 위의 것을 꺼내는 동작입니다.
• 특징: "어디에 있는 것을 꺼낼까?"가 중요합니다. 그래서 인덱스를 받으며, 삭제한 값을 우리에게 다시 반환(return)해줍니다.

② remove(): '무엇을' 제거하다

• 유래: 방에 있는 쓰레기를 치우듯, 특정 대상을 지목해서 없애는 동작입니다.
• 특징: "어디에 있든 상관없으니 '이 값'을 지워줘!"라는 의미입니다. 그래서 값(Value)을 인덱스 대신 받으며, 별도의 값을 반환하지 않습니다.

마치며 언어의 문법과 메서드 이름에는 개발자들의 의도가 담겨 있습니다. 단어의 뜻과 내부 구조를 연결해서 이해해야 덜 헷갈리고 기억에 남습니다.

파이썬은 동적 타이핑 언어라 자료형이 자유롭다는 장점이 있지만, 데이터가 복잡해지면 사고가 나기 쉽습니다.

• 기존 방식: 데이터가 들어올 때마다 if isinstance(age, int)나 try-except를 수십 개씩 써서 검증해야 했습니다.
• Pydantic 방식: "데이터는 이런 모양이어야 해!"라고 모델(Model)을 딱 한 번 정의해두면, Pydantic이 알아서 검증하고 변환까지 해줍니다.

2. 코드 비교: 일반 클래스 vs Pydantic

일반적인 방식

class User:
    def __init__(self, id: int, name: str):
        self.id = id
        self.name = name

# 문자열 "123"을 넣으면? 그냥 문자열로 저장됨 (나중에 계산할 때 에러 날 수 있음)
user = User(id="123", name="가영") 

Pydantic 방식

from pydantic import BaseModel

class User(BaseModel):
    id: int
    name: str

# 문자열 "123"을 넣어도? 자동으로 정수 123으로 변환!
user = User(id="123", name="가영")
print(user.id) # 결과: 123 (int 타입)

# 만약 "abc"처럼 숫자로 못 바꾸는 걸 넣으면? 바로 에러(ValidationError) 발생!

3. Pydantic의 3가지 핵심 기능

① 데이터 검증 (Validation)

정해진 타입이 아니거나 값이 범위를 벗어나면 즉시 에러를 발생시킵니다. 예를 들어 나이는 int여야 하고 0보다 커야 한다는 규칙을 아주 쉽게 정할 수 있습니다.

② 데이터 변환 (Parsing/Coercion)

이게 정말 편리한 기능입니다! "100"이라는 문자열이 들어와도, 모델이 int를 원한다면 Pydantic이 알아서 숫자로 바꿔줍니다. (아까 우리가 int(input())으로 수동 변환했던 과정을 자동으로 해주는 거죠.)

③ 압도적인 성능

Pydantic V2부터는 핵심 로직이 Rust(러스트)라는 매우 빠른 언어로 작성되어, 파이썬에서 가장 빠른 데이터 검증 라이브러리로 평가받고 있습니다.

타입 시스템을 비교 분석하고, 특히 파이썬(Python) 환경에서 변수가 메모리를 관리하는 내부 동작 원리를 살펴보는 글.

1. 타입 시스템: 전용 상자 vs 포스트잇

변수의 자료형(Type)을 결정하는 방식에 따라 언어의 특성이 결정된다. 이를 비유를 통해 명확히 구분할 수 있다.

1.1 정적 타이핑(Static Typing): 전용 상자 모델

• 비유: 변수는 특정 크기와 용도가 정해진 '전용 상자'와 같다.
• 특징: 정수형(int) 상자를 만들면 오직 정수만 담을 수 있으며, 실행 전(Compile 타임)에 상자의 규격을 결정한다.
• 언어: C, C++, Java 등.
• 장점: 안정성이 높고 실행 속도가 빠르나, 유연성이 부족하다.

1.2 동적 타이핑(Dynamic Typing): 포스트잇 모델

• 비유: 변수는 데이터에 붙이는 '포스트잇(이름표)'과 같다.
• 특징: 데이터가 먼저 존재하고, 변수는 그 데이터가 무엇이든 상관없이 이름표만 붙인다. 자료형은 실행 시점(Runtime)에 결정된다.
• 언어: Python, JavaScript 등.
• 장점: 개발 속도가 빠르고 유연하지만, 실행 전까지 타입 에러를 발견하기 어렵다.

-> 아래는 파이썬(동적 타이핑)에 대한 내용

2. 파이썬의 변수 할당과 재할당 메커니즘

동적 타이핑 언어인 파이썬에서 a = 5 이후 a = "Hello"와 같이 자료형을 변경하며 재할당할 때의 내부 동작은 다음과 같다.

1. 객체 생성: 메모리 공간에 5라는 정수 객체가 생성된다.
2. 참조(Binding): 변수 a라는 포스트잇이 5 객체에 부착된다.
3. 재할당: 새로운 "Hello" 문자열 객체가 생성되고, 포스트잇 a를 기존의 5에서 떼어내어 "Hello"에 다시 부착한다.
4. 가비지 컬렉션(GC): 어떠한 이름표도 붙어있지 않은(참조 카운트가 0인) 기존의 5 객체는 파이썬의 청소부인 가비지 컬렉터에 의해 메모리에서 삭제된다.

3. 별칭(Aliasing) 현상과 Mutable 객체의 주의점

하나의 객체에 여러 개의 이름표(변수)를 붙일 때 발생하는 현상을 Aliasing이라고 하며, 이는 데이터 무결성에 큰 영향을 미친다.

3.1 수박(Watermelon) 예시를 통한 고찰

두 명의 팀원이 하나의 수박을 공유하는 상황을 코드로 재현하면 다음과 같다.

# 1. 하나의 리스트 객체 생성 후 my_watermelon 이름표 부착
my_watermelon = ["수박"]

# 2. 새로운 이름표 our_food를 같은 객체에 부착 (Aliasing)
our_food = my_watermelon

# 3. id() 함수로 메모리 주소 확인 시 동일함 (id(my_watermelon) == id(our_food))
print(my_watermelon is our_food) # True

3.2 Side Effect의 발생

리스트와 같이 내부 수정이 가능한 Mutable(가변) 객체는 Aliasing 상태에서 의도치 않은 변경을 초래할 수 있다.

• 상황: 한 명이 my_watermelon.append("꿀맛")을 수행하면, 실제 데이터 자체가 수정된다.
• 결과: 아무 작업도 하지 않은 다른 팀원의 our_food를 확인했을 때도 ["수박", "꿀맛"]으로 변경되어 나타난다.

이는 대규모 데이터 파이프라인 설계 시 원본 데이터를 보호하기 위해 반드시 깊은 복사(Deep Copy)와 같은 기법이 필요한 이유가 된다.

4. 함수 인자 전달 메커니즘: 키워드 인자(Keyword Argument)

함수 호출 시 매개변수(Parameter)에 값을 직접 지정하여 전달하는 방식은 새로운 변수를 생성하는 것과는 구분되는 '설정(Configuration)'의 개념으로 이해해야 한다.

• 키워드 인자: 함수 정의 시 미리 지정된 매개변수 이름을 명시하여 인자(Argument)를 전달하는 방식이다. 인자의 순서와 상관없이 특정 매개변수에 값을 할당할 수 있다.

• 주요 매개변수 분석 (print 함수 예시):

  • end (종료 문자): * print 함수 호출 종료 시 출력할 문자를 결정한다.
    • 기본값은 줄바꿈 문자(\n)이나, end=''와 같이 명시함으로써 다음 출력문과의 연결 방식을 제어할 수 있다.
  • sep (구분자, Separator): * 쉼표(,)로 나열된 여러 개의 출력 인자들 사이를 채울 문자를 결정한다.
    • 기본값은 공백(' ')이며, 이를 변경하여 간격을 없애거나 특정 기호(예: -, /)로 대체할 수 있다.

      # sep 매개변수 활용 예시
      print("010", "1234", "5678", sep="-") # 출력: 010-1234-5678

• 작동 원리: 위 매개변수들은 새로운 메모리 공간에 영구적인 변수를 생성하는 행위가 아니다. 함수 내부에 정의된 설정값(Default Value)을 사용자 정의 값으로 일시적으로 치환하는 행위이며, 해당 함수의 실행이 종료됨과 동시에 해당 설정은 소멸한다.

5. 결론 및 요약: Mutable vs Immutable 구별법

효율적인 디버깅을 위해 자료형의 가변성을 파악하는 것이 필수적이다.

1. 가변성 테스트: x[0] = 1과 같이 인덱스를 통한 직접 수정을 시도했을 때 에러가 나면 Immutable(str, tuple 등), 성공하면 Mutable(list, dict 등)이다.
2. ID 추적: 값을 변경했을 때 id() 값이 바뀌면 Immutable(새 집으로 이사), 그대로이면 Mutable(현 거주지에서 수리)이다.

# webui.sh 파일이 있는 메인 폴더로 이동
cd ~/stable-diffusion-webui-forge

#가상 환경 입장
. ./venv/bin/activate

#서버 실행(엔진 켜기)
./webui.sh --share --enable-insecure-extension-access --gradio-auth 아이디:비번

<주의> Gradio 주소는 매번 바뀝니다: --share 옵션을 쓰면 실행할 때마다 https://xxxx.gradio.live 주소가 새로 생성됨. 이전에 썼던 주소로 접속하면 안열림.

Storage 만들기

Azure에서 '리소스 만들기' > '스토리지 계정'> '만들기'> 기본 옵션으로 생성

생성한 스토리지 계정으로 들어가서 왼쪽에 있는 바에서 '데이터 스토리지'> '컨테이너'> '컨테이너 추가'> 기본 옵션으로 생성

Blob Storage와 동기화하기

<주의> 이미지를 하나라도 생성하고 동기화 진행해야 함.

파일을 동기화 시키기 위해서는 인증 관련 정보가 필요합니다. 액세스 키를 이용해 접근하는 방법, Entra ID 를 통해 진행하는 방법 등 여러가지 방법이 있지만, 보안이 강화되어 있는 SAS 토큰을 통해 파일을 동기화 시킵니다. -> 3개 다 선택해야 함. 아래로 스크롤하여 'SAS 및 연결 문자열 생성' 버튼 누르고 아래에 있는 SAS 토큰을 복사!

SAS란? Shared Access Signature 임시 출입증, 호텔 카드키처럼 일시적으로 권한을 줄때 사용

cmd로 돌아와서 아래 위치로 이동

cd ~/stable-diffusion-webui-forge

해당 위치에서 upload라는 이름의 sh파일 생성

vi upload 

그리고 sh파일 내부에 다음 내용을 넣기

#!/bin/bash
# Azure Storage 계정 이름
STORAGE_ACCOUNT_NAME="fimtrusstorage4" --> 아까 생성한 storage 이름
# Azure Blob 컨테이너 이름
CONTAINER_NAME="stable-diffusion-images" --> storage 내부에 생성한 컨테이너 이름

# 동기화할 로컬 디렉토리 (현재 위치)
LOCAL_PATH="/home/azureuser/stable-diffusion-webui-forge/outputs/"

# SAS TOKEN 정보 입력
SAS_TOKEN="<SAS_TOKEN>" --> 발급한 SAS 토큰 넣기
# Azure Blob Storage URL

# Azure Blob Storage URL
BLOB_URL="https://${STORAGE_ACCOUNT_NAME}.blob.core.windows.net/${CONTAINER_NAME}?${SAS_TOKEN}"

# azcopy 명령어 실행 (동기화)
echo "현재 위치의 모든 파일을 Azure Blob Storage '${CONTAINER_NAME}' 컨테이너와 동기화 시작..."
azcopy sync "$LOCAL_PATH" "$BLOB_URL" --delete-destination=false --recursive --include-pattern="*.png"
#azcopy sync "$LOCAL_PATH" "$BLOB_URL" --delete-destination=false --recursive --include-pattern="*.png;*.jpg;*.jpeg;*.webp;*.bmp;*.tiff;*.gif;*.mp4;*.mov;*.avi;*.mkv"

if [ $? -eq 0 ]; then
  echo "동기화 완료."
else
  echo "동기화 실패."
fi

마지막으로 sh uplaod를 입력하면 동기화 완료.

Storage에서 사진 확인

여러 모델 사용하기

https://stable-diffusion-art.com/models/

📋 문서 요약 방식별 선택 가이드

1. Stuff (몽땅 집어넣기)

원리: 모든 문서를 하나의 프롬프트에 통째로 넣고 "요약해줘"라고 시키는 가장 단순한 방식입니다.

장점: 가장 빠르고 비용이 저렴하며, 문맥을 한 번에 파악하기 좋습니다.

단점: 문서가 너무 길면 AI가 읽을 수 있는 한계를 초과하여 에러가 발생합니다.

stuff_chain = create_stuff_documents_chain(llm, prompt)

2. Map-Reduce (분할 요약 후 병합)

원리: 문서를 여러 조각으로 나눠서 각각 요약한 뒤(Map), 그 요약본들을 다시 모아서 최종 요약을 만듭니다(Reduce).

장점: 아주 방대한 양의 문서도 처리할 수 있고, 각 조각을 동시에 요약하므로 속도가 빠릅니다.

단점: 전체를 관통하는 미묘한 맥락이 요약 과정에서 사라질 수 있습니다.

from langchain_core.runnables import chain


@chain
def map_reduce_chain(docs):
    map_llm = ChatOpenAI(
        temperature=0,
        #단순 반복 작업이 많으므로, 속도가 빠르고 가격이 *저렴한 가성비 모델*
        model_name="gpt-4o-mini",
    )

    # map prompt 다운로드
    map_prompt = hub.pull("teddynote/map-prompt")

    # map chain 생성
    map_chain = map_prompt | map_llm | StrOutputParser()

    # *병렬 처리 (batch)*
    doc_summaries = map_chain.batch(docs)

    # reduce prompt 다운로드
    reduce_prompt = hub.pull("teddynote/reduce-prompt")
    reduce_llm = ChatOpenAI(
        #문맥 파악 능력 위해 성능이 더 좋은 *고성능 모델*
        model_name="gpt-4o",
        temperature=0,
        callbacks=[StreamingCallback()],
        streaming=True,
    )

    reduce_chain = reduce_prompt | reduce_llm | StrOutputParser()

    return reduce_chain.invoke({"doc_summaries": doc_summaries, "language": "Korean"})

Map-Reduce에서 체인을 분리하는 이유는 각 단계의 특성에 맞는 AI 모델을 선택하여 비용을 절감하고, 병렬 처리를 통해 대량의 문서를 빠르게 요약하기 위함입니다.

3. Map-Refine (점진적 보완 요약)

원리: 첫 번째 조각을 요약한 뒤, 그 요약본을 다음 조각과 함께 넘겨서 내용을 업데이트합니다. 이 과정을 마지막 조각까지 반복하며 요약을 완성해 나갑니다.

장점: 앞뒤 맥락이 잘 이어지며, 요약의 디테일이 살아있습니다.

단점: 순차적으로 작업해야 해서 속도가 느리고, 뒤로 갈수록 초기 내용이 희미해질 수 있습니다.

ed!from langchain_core.runnables import chain


@chain
def map_refine_chain(docs):

    # map chain 생성
    map_summary = hub.pull("teddynote/map-summary-prompt")

    map_chain = (
        map_summary
        | ChatOpenAI(
            model_name="gpt-4o-mini",
            temperature=0,
        )
        | StrOutputParser()
    )

    input_doc = [{"documents": doc.page_content, "language": "Korean"} for doc in docs]

    # 첫 번째 프롬프트, ChatOpenAI, 문자열 출력 파서를 연결하여 체인을 생성합니다.
    doc_summaries = map_chain.batch(input_doc)

    refine_prompt = hub.pull("teddynote/refine-prompt")

    refine_llm = ChatOpenAI(
        model_name="gpt-4o-mini",
        temperature=0,
        callbacks=[StreamingCallback()],
        streaming=True,
    )

    refine_chain = refine_prompt | refine_llm | StrOutputParser()

    previous_summary = doc_summaries[0]

    for current_summary in doc_summaries[1:]:

        previous_summary = refine_chain.invoke(
            {
                "previous_summary": previous_summary,
                "current_summary": current_summary,
                "language": "Korean",
            }
        )
        print("\n\n-----------------\n\n")

    return previous_summary

-> 원래 Refine 방식은 이전 요약 + 다음 원문을 결합하는 것이 정석입니다. 하지만 본 실습 코드에서는 토큰(입력량) 제한을 고려하여, 각 페이지를 먼저 요약(batch)한 뒤 요약본끼리 Refine 하는 구조를 취하고 있습니다. 요약본 + 요약본

4. Chain of Density (밀도 보완 반복 요약)

"Chain of Density" (CoD) 프롬프트는 GPT-4를 사용한 요약 생성을 개선하기 위해 개발된 기법입니다.

원리: 요약을 한 번으로 끝내지 않고 여러 번 반복 실행합니다. 이때 핵심 정보(Entity)가 누락되지 않았는지 체크하며 요약문의 밀도를 점점 높여갑니다.

장점: 인간이 작성한 요약과 비슷한 밀도를 가진 고품질 요약본이 나옵니다. 원문의 앞부분에 치우치는 경향(lead bias)이 덜합니다.

단점: 여러 번 반복 실행하므로 비용과 시간이 많이 듭니다.

5. Clustering-Map-Refine (군집화 기반 정예 요약)

원리: 문서 조각(Chunk)들을 비슷한 내용끼리 그룹(클러스터)으로 묶습니다. 각 그룹에서 가장 대표적인 중심 문서들만 골라 Refine 방식으로 요약합니다.

장점: 중복된 내용은 과감히 생략하고 방대한 양의 핵심 주제를 효율적으로 요약할 수 있습니다.

단점: 그룹을 나누는 '클러스터링' 과정이 추가되어 기술적으로 더 복잡합니다.

SQL쿼리 만드는 체인: create_sql_query_chain

사용자의 질문(자연어)을 LLM이 분석하여, 데이터를 추출하기 위한 최적의 SQL 쿼리를 스스로 생성합니다. 이렇게 생성된 쿼리를 통해 데이터베이스를 실시간으로 조회하여 정확한 정보를 찾아냅니다.

from langchain_community.tools.sql_database.tool import QuerySQLDataBaseTool

# SQLite 데이터베이스에 연결
db = SQLDatabase.from_uri("sqlite:///data/finance.db")
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# 생성한 쿼리를 실행하는 도구
execute_query = QuerySQLDataBaseTool(db=db)

# SQL 쿼리 생성
# 기본 프롬프트가 내장되어 있지만 매개변수로 Prompt를 추가해서 엉뚱한 쿼리 생성방지에 도움을 줄 수 있음 (아래에 서술)
write_query = create_sql_query_chain(llm, db)

# 생성한 쿼리를 실행하기 위한 체인을 생성합니다.
chain = write_query | execute_query

Prompt를 직접 작성해서 넣는 법 prompt = PromptTemplate.from_template("프롬프트 작성").partial(dialect=db.dialect) chain = create_sql_query_chain(llm, db, prompt)

chain.invoke({"question": "테디의 이메일을 조회하세요"})

위 방법으로는 답변이 단답형 형식으로 출력되므로 더 친절한 답변을 받기 위해서는 답변을 LLM으로 증강생성 하면 된다.

-965.7 -> '테디의 transaction의 합계는 -965.7 입니다.'

#LCEL 문법의 체인 사용
#친절한 답변 생성
from operator import itemgetter
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import PromptTemplate
from langchain_core.runnables import RunnablePassthrough

answer_prompt = PromptTemplate.from_template(
    """Given the following user question, corresponding SQL query, and SQL result, answer the user question.

Question: {question}
SQL Query: {query}
SQL Result: {result}
Answer: """
)

# 지시서(prompt)를 읽고, 모델(llm)이 생각해서, 문자열(Parser)로 답해라
answer = answer_prompt | llm | StrOutputParser()

# 생성한 쿼리를 실행하고 결과를 출력하기 위한 체인을 생성합니다.
chain = (
  RunnablePassthrough
  .assign(query=write_query)
  .assign(result=itemgetter("query") | execute_query)
  | answer
)

RunnablePassthrough.assign(...): 기존에 있던 데이터는 그대로 두고, 옆에 새로운 정보를 '추가'해서 다음 단계로 넘김

assign(query=write_query) 실행 결과: {"question": "...", "query": "SELECT..."}

result=itemgetter("query") | execute_query
#itemgetter로 query를 가져와서 execute_query로 전달 후 result를 가져옴
실행결과: {"question": "...", "query": "...", "result": "[('...')]"} 
-> answer에 저장

SQL Agent

Agent를 활용하여 Sql 쿼리를 생성하고 실행 결과를 답변으로 출력이 가능합니다.

'A와 B를 비교해줘' 같이 질문이 복잡해서 한 번의 쿼리로 안 끝날 때, 에이전트는 스스로 계획을 세워 여러 번 DB를 뒤져보고 최종 답을 냅니다.

[생각 → 행동 → 관찰]의 과정을 반복합니다.

from langchain_openai import ChatOpenAI
from langchain_community.utilities import SQLDatabase
from langchain_community.agent_toolkits import create_sql_agent

llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
db = SQLDatabase.from_uri("sqlite:///data/finance.db")

# Agent 생성
agent_executor = create_sql_agent(llm, db=db, agent_type="openai-tools", verbose=True)
agent_executor.invoke(
    {"input": "테디와 셜리의 transaction 의 합계를 구하고 비교하세요"}
)

실행 과정

Entering new SQL Agent Executor chain...
---1 어떤 테이블 있나 확인
Invoking: `sql_db_list_tables` with `{}`
accounts, customers, transactions

---2 'transactions' 태이블 구조 파악
Invoking: `sql_db_schema` with `{'table_names': 'transactions'}`

CREATE TABLE transactions (
    transaction_id INTEGER, 
    account_id INTEGER, 
    amount REAL, 
    transaction_date TEXT, 
    PRIMARY KEY (transaction_id), 
    FOREIGN KEY(account_id) REFERENCES accounts (account_id)
)

/* 예시 데이터 3줄
3 rows from transactions table:
transaction_id  account_id  amount  transaction_date
1   1   74.79   2024-07-13
2   1   -224.1  2024-05-13
3   1   -128.9  2024-01-25
*/

---3 정확한 쿼리 생성 및 조회
Invoking: `sql_db_query` with `{'query': 'SELECT account_id, SUM(amount) AS total_amount FROM transactions WHERE account_id IN (1, 2) GROUP BY account_id'}`

[(1, -965.7), (2, 743.13)] 
테디의 거래 합계는 -965.7이고, 셜리의 거래 합계는 743.13입니다.

Finished chain.

🛠️ 실무 적용 시 반드시 고려할 점

LLM 기반의 SQL 에이전트는 편리하지만, 실제 서비스에 적용하려면 안정성과 효율성을 꼭 따져봐야 합니다.

1. 보안: "읽기 전용"은 필수 AI가 실수로 데이터를 지우거나 수정하지 않도록, DB 접속 시 읽기 전용(Read-Only) 계정을 연결해야 합니다. 또한, 위험한 명령어(DROP, DELETE 등)가 포함되었는지 검사하는 Query Validator 단계를 추가하는 것이 일반적입니다.

2. 비용과 속도: 하이브리드 전략 에이전트는 스스로 판단하는 과정에서 AI 모델을 다회 호출(Multi-turn)하므로 API 비용 상승과 응답 지연이 발생합니다. 단순한 질문은 Chain(고정)으로, 복잡한 분석은 Agent(자율 판단)로 처리하는 설계가 효율적입니다.

3. 컨텍스트 최적화 (Context Management) DB의 모든 구조를 AI에게 넘기면 오히려 헷갈려 할 수 있습니다. 꼭 필요한 테이블 정보와 컬럼 설명만 골라 전달하여 AI가 엉뚱한 답변(환각)을 하지 않도록 관리해야 합니다.

🧰 함께 살펴보면 좋은 도구들

랭체인 외에도 현업에서 자주 언급되는 대안들입니다.

LlamaIndex: 랭체인과 양대 산맥입니다. 특히 데이터를 찾고 연결하는 기능(RAG)에 특화되어 있어 SQL 관련 작업에서도 많이 쓰입니다.

Vanna.ai: 'Text-to-SQL'에만 집중한 특화 툴로, 회사의 과거 쿼리 데이터를 학습시켜 정확도를 높이기 좋습니다.

LangGraph: 랭체인의 확장판입니다. 에이전트의 사고 과정을 더 세밀하게 제어하고 싶을 때(예: "먼저 승인을 받고 쿼리를 실행해") 사용합니다.

구조화된 출력 만드는 체인: with_structured_output

AI 답변을 파싱(글자 쪼개기)하느라 고생할 필요 없이, 처음부터 API처럼 규격에 맞는 데이터를 받는 기술.

사람이 아닌 '프로그램'이 AI의 답변을 소비할 때 사용!

예시) 4지선다형 퀴즈를 생성

1. AI에게 줄 '데이터의 틀'를 만드는 작업

Quiz 클래스는 퀴즈의 질문, 난이도, 그리고 네 개의 선택지를 정의

class Quiz(BaseModel):
    question: str = Field(..., description="퀴즈의 질문")
    level: str = Field(...)
    options: List[str] = Field(...)

llm = ChatOpenAI(model="gpt-4o", temperature=0.1)
prompt = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            "You're a world-famous quizzer and generates quizzes in structured formats.",
        ),
        (
            "human",
            "TOPIC 에 제시된 내용과 관련한 4지선다형 퀴즈를 출제해 주세요. 만약, 실제 출제된 기출문제가 있다면 비슷한 문제를 만들어 출제하세요."
            "단, 문제에 TOPIC 에 대한 내용이나 정보는 포함하지 마세요. \nTOPIC:\n{topic}",
        ),
        ("human", "Tip: Make sure to answer in the correct format"),
    ]
)

2. with_structured_output(Quiz) (AI에게 틀 전달)

   # 구조화된 출력을 위한 모델 생성
   llm_with_structured_output = llm.with_structured_output(Quiz)
   

퀴즈 생성 체인 생성

chain = prompt | llm_with_structured_output

퀴즈 생성을 요청합니다.

generated_quiz = chain.invoke({"topic": "ADSP(데이터 분석 준전문가) 자격 시험"})

생성된 퀴즈 출력

print(f"{generated_quiz.question} (난이도: {generated_quiz.level})\n") for i, opt in enumerate(generated_quiz.options): print(f"{i+1}) {opt}")

#결과물 다음 중 데이터 분석의 과정에서 가장 먼저 수행해야 하는 단계는 무엇인가요? (난이도: 보통)

1) 데이터 수집 2) 데이터 전처리 3) 문제 정의 4) 모델 평가

``` 3. 데이터의 흐름

① 입력: "ADSP 시험에 대한 퀴즈를 내줘"라고 요청합니다.

② 처리: AI가 내용을 생성한 뒤, Quiz 클래스 양식에 맞게 데이터를 칸칸이 집어넣습니다.

③ 출력: 결과물이 문장이 아니라 generated_quiz.question처럼 변수명으로 바로 접근할 수 있는 형태로 나옵니다.

주요 도구: OpenAIEmbeddings

지원되는 모델 목록

어떤 모델을 사용해서 embedding 할건지 정하고 (여기서는 text-embedding-3-small) 텍스트를 임베딩하면 벡터화(숫자)되어 리스트에 담긴 것을 확인 가능합니다.

embed_query (검색용)

사용자의 질문 단 하나를 벡터로 바꿀 때

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
text = "임베딩 테스트를 하기 위한 샘플 문장입니다."
query_result = embeddings.➡️embed_query(text)

[-0.00776276458054781, 0.03680367395281792, 0.019545823335647583, -0.0196656696498394, 0.017203375697135925]

embed_documents (저장용)

많은 양의 문서를 한꺼번에 벡터로 바꿀 때 -> 항상 문자열의 리스트를 입력받고, 각 문서에 대한 임베딩 벡터를 포함하는 2차원 리스트를 반환함.

차원(Dimension) 지정 기능이 필요한 이유?

임베딩 차원 지정은 검색 속도와 저장 비용을 최적화하면서도, 핵심 의미 정보를 유지하여 시스템 효율과 정확도 사이의 최적의 밸런스를 찾기 위해 필요합니다.

'dimensions=1024' 옵션을 추가하여 차원 지정가능

embeddings_1024 = OpenAIEmbeddings(model="text-embedding-3-small", ➡️dimensions=1024)

• 비용 및 저장소 최적화: 차원을 줄이면 벡터 DB 용량이 감소하여 인프라 유지 비용이 대폭 절감됩니다.

• 검색 속도(Latency) 향상: 저차원 벡터는 유사도 계산 연산량이 적어 대규모 데이터셋에서 훨씬 빠른 응답 속도를 보장합니다.

• 정확도 밸런스: '매트료슈카 임베딩' 기술 덕분에 차원을 줄여도 핵심 의미 정보는 대부분 유지되므로, 성능 손실을 최소화하며 효율을 극대화할 수 있습니다.

• 환경 적응성: 메모리가 제한된 모바일이나 엣지 디바이스 환경에 맞춰 모델 부하를 조절할 수 있습니다.

2. 캐시를 이용한 임베딩 최적화

주요 도구: CacheBackedEmbeddings

이유: 임베딩은 비용(돈/시간)이 듭니다. 똑같은 문장을 매번 새로 계산하는 건 비효율적이죠.

CacheBackedEmbeddings

embeddings를 키-값 저장소에 캐싱하는 embedder 주변에 래퍼입니다.

• 알맹이: 실제 계산을 담당하는 OpenAIEmbeddings.
• 껍데기(Wrapper): 계산된 결과를 저장하고 관리하는 CacheBackedEmbeddings.

🛠️ CacheBackedEmbeddings 초기화 매개변수

캐시 임베더를 설정할 때는 from_bytes_store 메서드를 통해 다음 세 가지 핵심 부품을 연결합니다.

1. underlying_embeddings: 실제 임베딩 계산을 수행할 모델 엔진 (예: OpenAI).
2. document_embedding_cache: 계산된 벡터를 바이트 단위로 보관할 저장소 (ByteStore).
3. namespace: 저장소 내의 독립된 구역 이름.
   • 주의: 서로 다른 모델이 동일한 텍스트에 대해 생성한 벡터가 섞이지 않도록, 모델명을 네임스페이스로 지정하는 것이 권장됩니다.

LocalFileStore 에서 임베딩 사용 (영구 보관)

# 캐시를 지원하는 임베딩 생성
embedding = OpenAIEmbeddings()

cached_embedder = CacheBackedEmbeddings.from_bytes_store(
    underlying_embeddings=embedding,
    document_embedding_cache=➡️LocalFileStore("./cache/"), # 로컬 파일 저장소 설정
    namespace=embedding.model  # 기본 임베딩과 저장소를 사용하여 캐시 지원 임베딩을 생성
)

InmemoryByteStore 사용 (비영구적)

from langchain.embeddings import CacheBackedEmbeddings
from langchain.storage import InMemoryByteStore

store = ➡️InMemoryByteStore()  # 메모리 내 바이트 저장소 생성

# 캐시 지원 임베딩 생성
cached_embedder = CacheBackedEmbeddings.from_bytes_store(
    embedding, store, namespace=embedding.model
)

비용 절감과 데이터 보존이 중요한 실무 환경에는 LocalFile을, 속도가 중요하고 일회성인 작업에는 InMemory를 선택

3. 오픈소스 모델 활용: HuggingFace

주요 도구: HuggingFaceEmbeddings

특징: OpenAI API(유료) 없이 내 로컬(코랩) 환경에서 무료 오픈소스 모델로 갈아타는 방법.

쓸만한 한국어 임베딩 모델

• intfloat/multilingual-e5-large (3~4위): 현재 오픈소스 모델 중 최상위권 성능입니다. instruct 버전은 질문과 답변의 맥락을 더 잘 구분하도록 튜닝되어 있습니다.

• BAAI/bge-m3 (6위): 한국어 임베딩의 교과서 같은 모델입니다. 성능이 안정적이고, 다국어 지원이 강력해서 실무에서 가장 많이 쓰입니다.

• e5-base / e5-small (7~8위): 성능은 상위권 모델보다 조금 낮지만, 가볍고 속도가 매우 빠릅니다. 컴퓨터 자원이 부족하거나 빠른 응답이 필요할 때 선택합니다.

HuggingFace Endpoint Embedding

모델을 내 컴퓨터가 아닌 별도의 전용 서버(Endpoint)에 올려놓고 API 형태로 호출하는 방식

from langchain_huggingface.embeddings import HuggingFaceEndpointEmbeddings

model_name = "intfloat/multilingual-e5-large-instruct"

hf_embeddings = ➡️HuggingFaceEndpointEmbeddings(
    model=model_name,
    task="feature-extraction",
    huggingfacehub_api_token=os.environ["HF_TOKEN"],
)

embedded_documents = hf_embeddings.embed_documents(texts)
embedded_query = hf_embeddings.embed_query("LangChain 에 대해서 알려주세요.")

HuggingFace Embeddings

내 컴퓨터(Local)의 GPU를 사용하여 임베딩을 생성합니다. 비용이 0원이며 보안이 중요한 프로젝트에 필수적

from langchain_huggingface.embeddings import HuggingFaceEmbeddings

model_name = "intfloat/multilingual-e5-large-instruct"

hf_embeddings = HuggingFaceEmbeddings(
    model_name=model_name,
    model_kwargs={"device": "cuda"},  # cuda, cpu-> 내 컴퓨터 가동
    encode_kwargs={"normalize_embeddings": True}, 
    # 추출된 벡터들의 길이를 1로 맞추는 정규화 작업 -> 유사도를 구할 때 복잡한 계산 없이 단순한 '내적'만으로도 정확한 비교가 가능
)

임베딩 방식별 비교표

a. BGE-M3는 세 가지 방식을 모델 하나로 모두 구현하고 있음❕❕❕

a. BGE-M3 임베딩🌟

현재 한국어를 포함한 다국어 검색에서 가장 가성비 좋고 강력한 오픈소스 모델이기 때문에 실무 표준으로 소개됨

from langchain_huggingface import HuggingFaceEmbeddings

model_name = ➡️"BAAI/bge-m3"
model_kwargs = {"device": "cuda"}
encode_kwargs = {"normalize_embeddings": True}

hf_embeddings = HuggingFaceEmbeddings(
    model_name=model_name, model_kwargs=model_kwargs, encode_kwargs=encode_kwargs
)

랭체인(langchain)말고 모델 제조사(BAAI)가 직접 만든 전용 라이브러리(FlagEmbedding)를 사용하는 방법

랭체인의 HuggingFaceEmbeddings는 범용적이지만, BGE-M3 전용 기능(Sparse, Multi-vector 추출 등)을 세밀하게 제어하기에는 한계가 있습니다.

제조사가 제공하는 라이브러리를 쓰면 use_fp16(반정밀도 연산) 같은 속도 최적화 옵션을 더 직접적으로 사용할 수 있습니다.

# FlagEmbedding 설치
!pip install -qU FlagEmbedding

1번 스타일: 일단 계산시키고 dense_vecs만 사용하기

from FlagEmbedding import BGEM3FlagModel

bge_embeddings = BGEM3FlagModel(
    "BAAI/bge-m3", use_fp16=True
)  # use_fp16을 True로 설정하면 약간의 성능 저하와 함께 숫자를 표현하는 비트 수를 줄여 계산량을 줄어 빨라짐.

bge_embedded = bge_embeddings.encode(
    texts,
    batch_size=12,
    max_length=8192,  # 한번에 읽는 토큰수:작은 값을 설정하여 프로세스의 속도를 높일 수 있음.
)➡️["dense_vecs"]

["dense_vecs"] ->BGE-M3는 Dense, Sparse, ColBERT 결과를 동시에 생성하는 멀티태스킹 모델이므로, encode() 결과 중 필요한 데이터 형태(dense_vecs)만 명시적으로 추출하여 사용하려고 넣은 코드.

2번 스타일: 처음부터 dense 결과만 돌려주도록 세팅

from FlagEmbedding import BGEM3FlagModel

bge_flagmodel = BGEM3FlagModel(
    "BAAI/bge-m3", use_fp16=True
)  

bge_encoded = bge_flagmodel.encode(texts, ➡️return_dense=True)

b. Sparse Embedding (Lexical Weight)

기존 밀집(Dense) 임베딩은 문맥은 잘 잡지만 "고유 명사(예: 제품명, 이름)" 검색에 약합니다. 이를 보완하기 위해 키워드 일치 방식(Lexical)의 가중치를 더해 검색 정확도를 높임

bge_flagmodel = BGEM3FlagModel(
    "BAAI/bge-m3", use_fp16=True
)  # use_fp16을 True로 설정하면 약간의 성능 저하와 함께 계산 속도가 빨라집니다.
bge_encoded = bge_flagmodel.encode(texts, ➡️return_sparse=True)

여기서는 BGE-M3 모델 사용함

lexical_scores1 = bge_flagmodel.compute_lexical_matching_score(
    bge_encoded["lexical_weights"][0], bge_encoded["lexical_weights"][0]
)
# 0 <-> 0 자기 자신과의 비교
print(lexical_scores1)

0.30167388916015625 = 0번 문서와 0번 문서가 얼마나 '같은 단어'를 공유하는지 계산한 값입니다. 당연히 똑같은 단어들로 구성되어 있으니 모델이 판단한 최대 일치 점수가 나옵니다.

lexical_scores2 = bge_flagmodel.compute_lexical_matching_score(
    bge_encoded["lexical_weights"][0], bge_encoded["lexical_weights"][1]
)
# 0 <-> 1 다른 문서와의 비교
print(lexical_scores2)

0 =두 문서 사이에 겹치는 단어가 하나도 없다. Dense 방식은 단어가 달라도 '분위기'가 비슷하면 0.8 같은 점수를 주지만, Sparse 방식은 글자 자체가 일치하지 않으면 가차 없이 0점.

c. ColBERT

문장 전체를 하나의 점(Vector)으로 찍는 대신, 단어 하나하나의 벡터를 모두 비교합니다. 계산량은 훨씬 많지만, 문맥적 유사도를 찾는 정밀도가 압도적으로 높아 고성능 검색 엔진 구현 시 사용

작동 방식

1. 문서의 각 토큰에 대해 별도의 벡터를 생성합니다. 즉, 하나의 문서는 여러 개의 벡터로 표현됩니다.
2. 쿼리도 마찬가지로 각 토큰에 대해 별도의 벡터를 생성합니다.
3. 검색 시, 쿼리의 각 토큰 벡터와 문서의 모든 토큰 벡터 사이의 유사도를 계산합니다.
4. 이 유사도들을 종합하여 최종 검색 점수를 계산합니다.

bge_flagmodel = BGEM3FlagModel(
    "BAAI/bge-m3", use_fp16=True
)  # use_fp16을 True로 설정하면 약간의 성능 저하와 함께 계산 속도가 빨라집니다.
bge_encoded = bge_flagmodel.encode(texts, ➡️return_colbert_vecs=True)

colbert_scores1 = bge_flagmodel.colbert_score(
    bge_encoded["colbert_vecs"][0], bge_encoded["colbert_vecs"][0]
)
colbert_scores2 = bge_flagmodel.colbert_score(
    bge_encoded["colbert_vecs"][0], bge_encoded["colbert_vecs"][1]
)
# 0 <-> 0
print(colbert_scores1)
# 0 <-> 1
print(colbert_scores2)

앞서 본 Sparse 방식이 "0점"을 줬던 문장들에 대해, ColBERT는 어떻게 반응하는지 비교하면 , ColBERT는 글자는 다르지만, 단어들의 세부적인 맥락을 보니 의미적 연관성이 있다고 판단해 tensor(0.3748)라고 점수를 부여해줌.

"ColBERT가 좋은 이유" Sparse 방식은 '아이폰'과 '스마트폰'을 완전히 다른 것으로 보지만, ColBERT는 두 단어를 구성하는 토큰(Token) 벡터들이 서로 유사한 영역에 있음을 감지한다.

4. UpstageEmbeddings

국내 AI 기업인 Upstage(업스테이지)의 Solar 모델 실습

업스테이지는 검색의 정확도를 높이기 위해 비대칭 임베딩(Asymmetric Embedding) 전략을 사용하는데 질문과 답변은 문장 구조가 다르기 때문에 각각의 특성에 맞춰 학습시켜, 질문용 모델과 답변용 모델이 분리 되어 있다!

from langchain_upstage import UpstageEmbeddings

# 쿼리 전용 임베딩 모델
query_embeddings = UpstageEmbeddings(model="solar-embedding-1-large-query")

# 문장 전용 임베딩 모델
passage_embeddings = UpstageEmbeddings(model="solar-embedding-1-large-passage")

# 쿼리 임베딩
embedded_query = query_embeddings.embed_query("LangChain 에 대해서 상세히 알려주세요.")
# 임베딩 차원 출력-> 4096
len(embedded_query)
# 문서 임베딩
embedded_documents = passage_embeddings.embed_documents(texts)

앞서 배운 BGE-M3나 E5 모델은 1024차원이었지만 업스테이지 모델은 4096차원으로 정보를 4배나 더 세밀하게 쪼개서 저장합니다. 그만큼 문장의 미묘한 뉘앙스를 잡아내는 능력이 탁월하지만, 저장 공간(Vector DB)을 더 많이 차지한다는 트레이드오프가 있습니다.

유사도 결과에서도 한국어와 영어의 교차 검색에서 언어가 달라도 의미가 통하면 높은 점수를 주는 등 더 정교한 의미 검색이 가능함!

5. OllamaEmbeddings

Ollama는 로컬 환경에서 대규모 언어 모델(LLM)을 쉽게 실행할 수 있게 해주는 오픈소스 프로젝트로 개발자들이 AI 모델을 자신의 컴퓨터에서 직접 실험하고 사용할 수 있도록 지원합니다.

from langchain_community.embeddings import OllamaEmbeddings

ollama_embeddings = ➡️OllamaEmbeddings(
    model="nomic-embed-text", #768차원짜리 가벼운 모델. 로컬에서 돌려야해서 가장 대중적으로 쓰임.
)

쿼리와 문서를 인베딩하는 방식은 위 다른 실습과 동일하고 특이한 점은 유사도에서 점수가 높게 나왔는데 그 이유는 다른 모델과는 달리 정규화를 거치지 않은 순수 벡터 값을 그대로 내적했기 때문에, 벡터의 크기만큼 점수가 뻥튀기된 것입니다. 점수의 절댓값은 의미가 없고 상대적인 순위만 확인하면 됩니다.

[Query] LangChain 에 대해서 알려주세요.
====================================
[0] 유사도: 399.644 | LangChain은 초거대 언어모델로 애플리케이션을 구축하는 과정을 단순화합니다.

[1] 유사도: 356.518 | 랭체인 한국어 튜토리얼은 LangChain의 공식 문서, cookbook 및 다양한 실용 예제를 바탕으로 하여 사용자가 LangChain을 더 쉽고 효과적으로 활용할 수 있도록 구성되어 있습니다. 

[2] 유사도: 322.359 | LangChain simplifies the process of building applications with large language models

[3] 유사도: 321.078 | 안녕, 만나서 반가워.

[4] 유사도: 224.858 | Retrieval-Augmented Generation (RAG) is an effective technique for improving AI responses.

6. GPT4ALL 임베딩

GPT4All은 무료로 사용할 수 있는 로컬 실행 기반의 개인정보 보호를 고려한 챗봇으로 GPU 없이 CPU만으로도 돌아가는 저사양 환경을 위한 가성비 모델입니다. 업스테이지(4096), BGE-M3(1024)에 비해 훨씬 작은 384차원을 사용합니다. (실습에서 확인가능)

• 장점: 숫자가 적으니 계산 속도가 빛의 속도만큼 빠르고, 메모리(RAM)를 거의 차지하지 않습니다.
• 단점: 정보의 '해상도'는 낮습니다. 복잡하고 긴 전문 지식 검색보다는 간단한 일상 대화나 가벼운 문장 검색에 적합합니다.

//implement here...

에 class를 선언하니까 참조를 못한다고 떴습니다. 물론 class가 사용처보다 아래에 작성되긴 했지만 저는 교수님이 적으라고 한 곳에 적은 죄 밖에 없었기에 억울했습니다... 게다가 코틀린은 자바와 같은 컴파일 언어인데 선언 순서에 영향을 받을 거라고 생각치도 못했습니다.

저 같은 오개념을 가진 사람도 있을 것이라 생각해 이번 블로그 주제를 선정하게 되었습니다.

기술적 오해

코틀린은 자바와 마찬가지로 JVM(Java Virtual Machine)을 타겟으로 하는 컴파일 언어입니다. 그러나 코틀린은 사용하고자 하는 요소가 그 사용처보다 코드 상위(먼저)에 정의되어야만 컴파일이 성공하는 경우가 일반적입니다.

이는 흔히 알려진 '컴파일 언어는 선언 순서에 자유롭다'는 인식과는 다릅니다. 그렇다면 선언 순서의 자유도에 영향을 미치는 근본적인 요인은 무엇일까요?

선언 순서의 결정 요인: 컴파일러 처리 방식의 차이

선언 순서의 자유도를 결정하는 핵심 요인은 언어의 종류(컴파일 vs 인터프리트)가 아닌, 컴파일러가 소스 코드를 처리하는 방식, 즉 '통과(Pass)' 횟수에 있습니다.

• $\text{다중 통과(Multi-Pass)}$ 방식: 코드를 여러 번 스캔하여, 첫 번째 통과에서 모든 심볼(클래스, 함수 등)의 존재와 위치를 파악(전방 참조 허용)하고, 이후 통과에서 실제 검증 및 코드를 생성합니다. -> 즉, 선언 순서가 비교적 자유롭습니다.

• $\text{단일 통과(Single-Pass)}$ 방식: 코드를 위에서 아래로 한 번에 처리하며, 요소를 사용할 시점에는 반드시 그 정의가 이미 컴파일러에게 알려져 있어야 합니다. -> 즉, ** 선언이 사용처보다 앞에 되어있어야만 합니다.**

코틀린(Kotlin): 단일 통과 경향과 언어 설계의 합리성

코틀린 컴파일러는 단일 통과에 가까운 효율적인 처리를 지향하며, 이는 언어 설계 철학과 긴밀하게 연결되어 있습니다. 다른 근본 언어를 배우고 코틀린을 배우기 시작하면 코틀린이 얼마나 컴팩트함과 직관적임을 유지하고자 했는지 참... 느껴집니다 (개인적인 의견)

코틀린은 다중 스캔의 복잡성을 줄여 컴파일러 구조를 단순화하고 처리 속도를 높이고자 하였고 (근데 앱 개발할때는 애뮬레이터 때문에 느려터짐) 스크립트와 유사한 순차적 실행 흐름 갖도록 선언도 이 흐름에 맞춰 사용 전 정의를 규칙으로 확립함으로써 코드의 지역성(Locality)과 가독성을 극대화합니다.

코틀린은 JVM 기반 컴파일 언어의 이점을 유지하면서도, 현대적인 언어의 요구사항(간결성, 명확성)을 위해 명시적인 선언 순서를 채택한 것입니다.

결론

결론적으로, 선언 순서의 자유도는 언어의 종류가 아닌 컴파일러의 내부 설계 방식에 의해 결정됩니다. 자바는 다중 통과로 유연성을 확보했고, 코틀린은 단일 통과 경향과 가독성 철학으로 명확성을 선택한 것입니다.

실무에서 코틀린을 사용할 때는 이 원리를 이해하고, 클래스나 함수를 사용하기 전에 정의하는 Top-Down 방식의 코딩 습관을 유지합시다!

요즘 코딩 판에서 React Server Components (RSC) 얘기가 핫하다고 하는데 저도 잘 모르지만 주제가 재밌어서 알아봐 왔습니다~. Next.js가 밀고 있는 이 기술은 단순한 기능 하나 툭 던져준 게 아니라, 우리 웹 개발판 자체를 뒤집어엎고 있다는데요.

RSC가 왜 등장했고, 이게 왜 '풀스택 개발의 역설'이라고 불리는지, 흥미롭게 파헤쳐 볼게요. 😉

1. 배경 지식: CSR과 '그 시절 모놀리스'를 소환합니다

RSC를 이해하려면, 우리가 '왜 이렇게까지 왔는가'를 봐야죠. 지금 우리를 괴롭혔던 두 가지 개념부터 쿨하게 정리해봅시다.

1-1. CSR (Client Side Rendering): "사용자 컴퓨터 뺑이 치는 방식"

CSR은 한때 SPA(Single Page Application)의 혁신이었지만, 요즘 들어 욕을 바가지로 먹는 방식이죠.

• 작동 방식: 서버는 텅 빈 HTML 파일 하나 던져주고, 수많은 JavaScript 파일 뭉치(번들)를 사용자 브라우저에 배달합니다. 브라우저는 이 JS 뭉치를 전부 다운로드해서 실행하고, 그제야 화면을 완성하죠.
• 문제점: JS 번들이 커질수록 초기 로딩이 답답해집니다. 사용자는 화면이 하얗거나 먹통인 상태(TTI 지연)를 하염없이 기다려야 해요. "아니, 왜 로딩만 하고 아무것도 안 돼?" 소리가 절로 나오죠. 🤬

1-2. 모놀리스(Monolith): "옛날 맛집의 만능 간장처럼"

모놀리스는 요즘 마이크로 서비스 아키텍처(MSA)에게 밀렸지만, 한때는 웹 서비스의 국룰이었어요.

• 정의: 서비스의 모든 기능 (프론트엔드, 백엔드 로직, 데이터 처리, 인증 등)이 하나의 거대한 코드베이스와 하나의 애플리케이션에 몽땅 묶여 작동하는 방식입니다. 마치 김치찌개부터 삼겹살까지 다 파는 '옛날 만능 식당' 같아요.
• 유명한 예시: 초창기 버전의 페이스북(Facebook)이나 이베이(eBay) 같은 서비스들이 이 모놀리스 구조에서 시작했어요. 물론 서비스가 커지면서 지금은 쪼개고 쪼개서 MSA로 갔지만, 처음에는 하나의 거대한 몸뚱이였죠.
• 문제점: 코드가 엉키면 머리도 엉킵니다. 작은 기능 하나 수정해도 전체를 다시 배포해야 해서 개발 속도가 '느림보 거북이'가 됩니다. 그리고 한 군데 문제 터지면, 줄줄이 소시지처럼 전체 서비스가 터질 위험이 있죠. 😱

2. RSC의 등장과 기술적 떡상 포인트

RSC는 CSR의 느린 초기 로딩과 모놀리스의 배포/확장성 문제 사이에서 절묘한 균형점을 찾으려고 나타났습니다.

💡 RSC가 서버에서 처리하는 '핵심 미션'

RSC는 "데이터 가져오기(Data Fetching)랑 화면 그리기(Rendering)는 서버에서 해치우자"는 마인드입니다.

1. 데이터 패칭 (Data Fetching) 혁신: Server Components는 DB에 직접 접근해서 데이터를 땡겨옵니다. 클라이언트에서 "야 서버! 데이터 줘!"라고 또 API 호출할 필요가 없어져요.
2. JS 번들 다이어트: 서버에서 렌더링된 컴포넌트는 클라이언트로 JS 코드가 아닌 특수 포맷으로 전송됩니다. 상호작용이 없는 컴포넌트의 JS 코드는 클라이언트 브라우저로 아예 안 넘어가죠. 결과적으로 다운로드할 JS 양이 확 줄어들어 로딩 속도가 🚀 로켓처럼 빨라집니다.

📊 RSC vs. CSR vs. SSR, 뭐가 다른데?

3. RSC가 가져온 '풀스택 개발'의 역설 🤯

RSC의 가장 재밌는 점은 개발자의 역할이 뒤섞인다는 거예요. RSC를 도입하면...

1. 프론트엔드 개발자가 서버의 왕좌에 오르다: 프론트엔드 개발자가 Server Component에서 DB 접근 로직을 직접 짜게 됩니다. 이게 무슨 말이냐? 프론트 개발자가 곧 서버 개발자가 되는 풀스택 경계 붕괴가 일어난 거죠.
2. API 서버의 정체성 혼란: 백엔드 팀이 힘들게 만들어 놓은 API 서버가 꿔다 놓은 보릿자루가 될 위기에 처합니다. 백엔드는 이제 "순수한 비즈니스 로직(핵심 기능)"과 "인프라 관리"라는 찐 업무에만 집중해야 합니다.

🤔 '옛날 모놀리스'로 회귀하는 거 아니야? (No!)

"어? 결국 하나로 합치는 거면 옛날 페이스북 모놀리스처럼 되는 거 아냐?"라고 생각할 수 있지만, 절대 아닙니다.

RSC는 모놀리스의 '하나로 합쳐진 편의성'은 가져오되, 단점인 '유지보수 지옥'은 버린 '신개념 하이브리드'라고 이해하면 됩니다. 즉, 풀스택 코딩의 편리함과 분산 아키텍처의 확장성을 동시에 잡은 치트키인 셈이죠.

4. 이제 우리는 무엇을 준비해야 할까? (찐 개발자의 숙제)

RSC는 우리에게 설렘과 동시에 숙제를 던져줍니다.

1. '나만 아는 코드' 금지! 협업 규칙 재정립

프론트엔드 개발자가 DB 코드를 짜면, 백엔드 개발자와 코드 리뷰 및 보안 기준을 어떻게 맞출지가 핵심이에요. "이건 프론트 영역인데 건들지 마!" 하던 시대는 갔습니다.

2. 보안 지식, 선택이 아닌 필수

Server Component는 서버에서 작동합니다. 즉, 데이터베이스 접근 권한, 민감 정보 노출 방지 등 백엔드 레벨의 보안 지식이 프론트엔드 개발자에게도 필수 소양이 됩니다.

3. 경계 긋는 능력 = 고수

모든 컴포넌트를 RSC로 만들면 오히려 복잡해질 수 있어요. "여기까지는 서버 컴포넌트로 성능 잡고, 여기서부터는 클라이언트 컴포넌트로 사용자 상호작용 넣자!"라고 명확하게 경계를 그릴 줄 아는 능력이 진정한 고수의 덕목이 될 거예요.

RSC는 단순히 React의 유행이 아니라, 웹 개발의 다음 챕터를 열고 있습니다. 이 변화를 놓치지 않고 잘 탑승해서, 우리 모두 '갓생 개발자'로 레벨업 합시다! 🚀

📌 == 와 .equals()의 차이

자바에서 두 값을 비교할 때 사용하는 두 가지 방법입니다. 어떤 자료형을 비교하느냐에 따라 적절한 방법을 사용해야 해요.

📌 length 와 length()의 차이

💡 핵심 원리: '종류'를 구별하기 프로그래밍 문법은 결국 '무엇'의 길이를 재는가에 따라 달라져요. 이때 . 뒤에 ()가 붙는지 여부는 그 '무엇'이 데이터(속성)인지 기능(메서드)인지를 나타내는 중요한 힌트가 됩니다.

length (괄호 없음)

📝 이건 데이터(속성)예요. 배열처럼 고정된 크기를 가진 객체의 고유한 정보를 의미합니다. 배열을 만들 때 그 길이가 정해지기 때문에, 그냥 그 값을 읽어오기만 하면 되죠. 따라서 굳이 어떤 동작을 실행할 필요가 없어 괄호가 붙지 않습니다.

• 예시: String[] arr = {"A", "B", "C"};
  • 👉arr.length의 결과는 3 입니다.

length() (괄호 있음)

💻 이건 기능(메서드)이에요. 문자열처럼 가변적인 데이터를 다룰 때, 길이를 계산하거나 확인하는 '동작'을 수행하는 것이죠. "야, 지금 이 문자열의 길이가 몇이야?"라고 물어보는 명령과 같아서 괄호 ()가 필요합니다.

• 예시: String str = "Hello"; 👉 str.length()의 결과는 *5** 입니다. 문자열의 길이를 세는 '행위'를 수행하는 거죠.

🤔 쉽게 기억하는 방법

이 두 가지를 구별하기 어렵다면, 다음과 같은 간단한 질문을 스스로에게 해보세요.

"이것은 이미 정해진 상수(값)인가?" 👉 그렇다면 length (괄호 없음) "이것은 어떤 동작을 통해 알아내야 하는가?" 👉 그렇다면 length() (괄호 있음)

📌 변수 초기화: 여러 변수 한 줄에 선언하기

자바에서 여러 변수를 한 줄에 선언할 수 있지만, 초기화에는 주의해야 합니다.

• 잘못된 초기화: int a, b, c, d = 0;

  • 이 코드는 d만 0으로 초기화하고, a, b, c는 초기화되지 않은 상태가 됩니다. 이 변수들을 사용하면 컴파일 오류가 발생해요.

• 올바른 초기화: int a = 0, b = 0, c = 0, d = 0;

  • 이렇게 각 변수에 값을 명시적으로 할당해야 모든 변수가 올바르게 초기화됩니다.

코딩 테스트에서 문자열을 효율적으로 다루는 방법은 시간 초과를 피하는 핵심 전략입니다. String, StringBuilder, 그리고 문자열과 배열의 관계를 제대로 이해하면 성능을 크게 향상할 수 있습니다.

1. String과 StringBuilder의 차이점

String: 불변(Immutable) 객체 🧊

String은 한 번 생성되면 그 내용을 변경할 수 없습니다. 문자열을 수정하거나 이어붙일 때마다 새로운 String 객체가 생성됩니다. 이 때문에 반복문에서 + 연산을 사용하면 수많은 객체가 만들어져 메모리 낭비와 함께 성능이 급격히 저하됩니다. 이는 코딩 테스트에서 **시간 초과(Time Limit Exceeded)**의 주요 원인이 됩니다.

StringBuilder: 가변(Mutable) 객체 ✨

StringBuilder는 기존 객체의 메모리 공간을 재활용하며 문자열을 추가, 수정, 삭제할 수 있습니다. 문자열을 자주 조작하는 코딩 테스트 환경에 매우 적합하며, 반복적인 문자열 작업에 필수적입니다.

✅ 비효율적인 String vs 효율적인 StringBuilder

// 비효율적인 String 사용
String str = "";
for (int i = 0; i < 1000; i++) {
    str += "a"; // 매 반복마다 새로운 String 객체 생성
}

// 효율적인 StringBuilder 사용
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append("a"); // 기존 객체에 계속 추가
}

2. StringBuilder 주요 메서드

StringBuilder 객체를 다룰 때 자주 사용하는 메서드들입니다.

3. String.repeat() (Java 11 이상)

vs StringBuilder.append()

자바 11 이상에서 제공되는 메서드로, 특정 문자열을 지정된 횟수만큼 반복할 수 있어 코드를 간결하게 만들어줍니다. repeat()는 내부적으로 StringBuilder를 사용해요. 예를 들어, str.repeat(5)를 호출하면 자바는 내부적으로 StringBuilder를 생성하고, append()를 5번 호출한 뒤, 최종적으로 toString()을 호출해 새로운 문자열을 만듭니다.

// 예시: 5번 반복하여 "abcabcabcabcabc" 생성
String repeatedString = "abc".repeat(5);

repeat()는 내부적으로 StringBuilder를 사용해 문자열을 이어붙이는 것과 비슷하게 동작하므로, 성능 면에서도 효율적입니다.

4. 문자열과 배열의 효율적인 활용

charAt() vs toCharArray(): 성능과 메모리의 차이

문자열의 각 문자에 접근하는 두 가지 방법에는 성능과 메모리 사용량에 큰 차이가 있습니다. 코딩 테스트에서 O(N)과 O(1)의 차이는 결과에 큰 영향을 미칩니다.

✅ toCharArray() 사용 시 주의점 반복문 안에서 toCharArray()를 사용하면 매번 새로운 배열이 생성되어 메모리 낭비를 초래합니다.

// 비효율적인 toCharArray() 사용
for (int i = 0; i < wallpaper.length; i++) {
    char[] wallpaperJ = wallpaper[i].toCharArray(); // ⚠️ 매 반복마다 배열 생성
    for (int j = 0; j < wallpaper[i].length(); j++) {
        if (wallpaperJ[j] == '#') {
            // ...
        }
    }
}

charAt()를 사용하면 새로운 배열을 만들 필요 없이 원래 문자열에서 바로 문자에 접근하므로 메모리 효율성과 시간 효율성 모두 높아집니다.

5. 기타 유용한 문자열 기술

문자 → 정수 변환

문자 '0'~'9'를 실제 정수 0~9로 변환하는 기술입니다. 배열의 인덱스로 활용할 때 매우 유용합니다.

// 예시: 문자 '5'를 정수 5로 변환하여 배열의 5번 인덱스를 증가
int[] count = new int[10];
char num = '5';
count[num - '0']++;

pintos -v -- -q run 'priority-change' test를 하기위해 사용하게 되는 명령어 docker안에서 명령어 입력! 따옴표 안에 실행하고픈 테스트 이름을 넣으면 됨. 여기 있는 pintos라는 명령어를 사용하기 위해서는 아래 세팅을 해야함.

⚙️ 매번 pintos라고만 치고 실행하고 싶다면: 환경 변수 등록 find /pintos -name pintos 이거 하면 pintos 스크립트 위치를 알려주는데 /pintos/utils/pintos 랑 /pintos/src/utils/pintos에 있음

export PATH=$PATH:/pintos/utils

🧠 이걸 영구 적용하려면: echo 'export PATH=$PATH:/pintos/utils' >> ~/.bashrc source ~/.bashrc 당연히 얘네도 docker안에 입력해야함

📌 문제 원인 지금 너가 사용하는 PintOS 구조는 pintos-kaist 버전이 아닌, 공식 PintOS Reference (Stanford/CS140) 기본 버전 또는 Makefile에 테스트 자동화를 포함하지 않은 최소 버전이야.

즉, 이 구조에선 make check도 없고

TESTS=...도 지원되지 않으며

테스트 실행은 직접 명령어로 pintos 명령을 호출해서 수동으로 해야 함

🛠️ make 명령어 비교 (Pintos 기준)

✅ 추천 사용 흐름 (단계별)

1. make clean – 이전 결과 삭제 (에러 방지용)
2. make – 내가 수정한 코드가 잘 컴파일되는지 확인
3. make check – 전체 테스트를 실행해서 결과 확인

좋아, 이 오류 메시지:

make: *** No rule to make target 'tests/threads/priority-change.result'.  Stop.

는 make가 테스트 실행 규칙을 찾지 못했다는 뜻인데,
대부분 다음 중 하나야:

✅ 1. 잘못된 디렉토리에서 테스트 실행 시도

너가 위치한 곳이 pintos/threads인데,
Pintos 공식 구조는 pintos/src/threads 구조여야 해.

🔧 해결:

cd /pintos/src/threads

src 폴더 안에 들어가서 Makefile이 있는지 확인해줘.

✅ 2. 처음 실행 시엔 make로 전체 빌드를 먼저 해줘야 할 수 있어

| 🔁 처음 빌드 했음? | make 또는 make all 했는지 |

cd /pintos/src/threads
make clean
make

이후 다시 아래 명령어 시도:

make tests/threads/priority-change.result

✅ 주석 작성 규칙 요약

• 코드에는 반드시 [기능][출처] 태그를 붙입니다.
• 슬라이드 기반 구현은 [FromSlide], 본인 설계는 [Custom]으로 구분합니다.
• 구조체 확장, 함수 정의, 기존 코드 내부 삽입 등 모든 위치에 주석을 명확히 달아야 합니다.
• "무엇을 하는가"보다, 왜 필요한가를 설명하는 주석이 더 중요합니다.
• 섹션 주석 작성하기

🧱 섹션 주석 작성법

파일 최상단이나 큰 섹션 나눌 땐:

/**************************************/
/*     THREAD UTILITY FUNCTIONS       */
/**************************************/

📌 팁: Ctrl + F로 찾을 때 키워드가 딱 걸리니까 탐색도 쉬워져.

작은 기능 구역(중단, 중첩 내부 등)에선:

// ===== [Priority Scheduling Helpers] =====

✔ 보통 함수들 사이에 넣기 적합함.

🧩 통합 예시 – 이 하나만 보면 모든 규칙이 보입니다

struct thread {
    ...
    /* [AlarmClock] 해당 스레드가 깨어나야 할 시각 (tick 기준) */
    int64_t wake_up_tick;

    /* [Donation][Custom] 이 스레드가 기부받은 priority들을 저장 */
    struct list donations;
};

📝 chatGPT용 주석작성 프롬프트

I’m working on the PintOS project and I want to add helpful comments to my C code.

Please add simple and clear English comments to each function or code block, following these rules:

1. Use only easy English words. Each sentence should be short and direct.
2. Add a feature tag at the start of each comment in this format: [FeatureName]. Example: [AlarmClock], [PriorityScheduling], [Donation].
3. If the code is a new **variable or function** that I created (not originally in PintOS), also add [Custom] after the feature tag. Example: [AlarmClock][Custom].
4. If the code is inside an existing PintOS function or modifies an existing variable, **do not** add the [Custom] tag — just use the feature tag.
5. If the line is for debugging, use [DEBUG] as the tag.
6. Only describe *why* the code exists, not just what it does. Focus on the purpose.
7. Comments should appear above the code they describe.
8. Do not explain basic C syntax. Just explain the logic or purpose.

Example:
```c
/* [AlarmClock] Set the time when this thread should wake up */
t->wake_up_tick = current_time + ticks;

/* [AlarmClock][Custom] New comparison function for sleep_list ordering */
static bool wakeup_less(...) { ... }

/* [DEBUG][Donation] Print the current priority */
printf("[DEBUG][Donation] current priority = %d\n", priority);

📝 PintOS 주석 작성 가이드 (한국어 요약)

1. 쉬운 영어 단어만 사용해 주세요.
   문장은 짧고 직접적이어야 합니다.

2. 각 주석 앞에는 [기능 이름] 태그를 붙여 주세요.
   예: [AlarmClock], [PriorityScheduling], [Donation]

3. 해당 코드가 PintOS 슬라이드에 없는, 내가 직접 추가한(Custom) 코드일 경우
   [Custom] 태그도 함께 붙여 주세요.
   예: [AlarmClock][Custom]

4. 디버깅용 코드에는 [DEBUG] 태그를 사용하세요.

5. 주석은 코드가 무엇을 하는지보다
   왜 필요한지(목적)를 설명하는 데 집중하세요.

6. 주석은 설명하는 코드 바로 위에 작성하세요.

7. 기본적인 C 문법은 설명하지 않아도 됩니다.
   대신 로직의 목적이나 동작 이유를 설명하세요.

--> 주석 작성이 어려우면 이 프롬프트 먹여서 AI가 작성하게 시키면 주석 작성 규칙에 맞춰서 써줄거임. 아래는 이해안되면 읽어보쇼

🧩 1. 기능/출처 태그 붙이기

📌 태그 구조

/* [기능이름][출처] 설명 */

✅ 기능 태그 예시

• [AlarmClock]
• [PriorityScheduling]
• [Donation]
• [MLFQ]
• [DEBUG] ← 디버깅 출력

✅ 출처 구분

| 태그 | 의미 | |------|------|| | [Custom] | 구현상 필요해서 직접 설계한 코드 |

🔍 예시

/* [AlarmClock][Custom] sleep_list 정렬 비교 함수 */
static bool wakeup_less(...) { ... }

printf("[DEBUG][AlarmClock] current_tick=%lld\n", ticks);

🧩 2. 함수 주석 작성법

• 함수 위에는 간단한 기능 설명과 호출 조건을 함께 작성합니다.

  /* [PriorityDonation]
  * 현재 스레드가 lock을 요청할 때, holder가 낮은 priority를 가진 경우 priority 기부
  */
  void donate_priority(void) { ... }

🧩 3. 기존 함수 내부에 코드 추가 시

• 삽입한 코드 앞에 주석을 붙여 기능과 목적을 설명합니다.

  void timer_interrupt(struct intr_frame *args UNUSED) {
    ticks++;
  
    /* [AlarmClock]sleep_list에서 깰 스레드 확인 및 unblock */
    thread_wakeup(ticks);
  
    thread_tick();
  }

🧩 4. 구조체 필드 확장 시

• 확장한 이유를 필드마다 주석으로 명확히 남깁니다.

  struct thread {
    ...
    /* [AlarmClock] 깨어날 tick 저장 */
    int64_t wake_up_tick;
  
    /* [Donation][Custom] 기부받은 priority 저장용 리스트 */
    struct list donations;
  };

🧩 5. 디버깅 코드 관리

• 디버깅용 출력 또는 코드에는 반드시 [DEBUG] 태그를 붙이고,
• 최종 제출 전에는 삭제하거나 주석 처리하세요.

  printf("[DEBUG][Donation] current priority=%d\n", t->priority);

✅ 마무리 팁

• 태그는 항상 대괄호[], 앞글자 대문자 + CamelCase
• 기능과 출처를 함께 표시하면 가독성 및 추적성 ↑
• 한눈에 보이는 주석이 좋은 주석입니다!

🔐 세마포어(Semaphore)란? 세마포어는 공유 자원에 접근할 수 있는 "허가증" 같은 역할을 하는 변수야. 목적: 여러 스레드가 동시에 하나의 자원을 접근하려고 할 때, 충돌을 막기 위해 사용함.

• sema_down() 허가증을 획득하려는 시도. 허가증이 없으면 waiters 리스트에 들어가서 block 상태로 전환됨

• sema_up() 허가증을 반환. waiters 리스트에서 우선순위 높은 스레드를 깨움 unblock
• waiters 기다리는 스레드 목록 (정렬 기준: priority)

Main goal 현재 PintOS 스케줄러는 FIFO 방식 → 우선순위 기반 스케줄링으로 바꾸는 게 목표

🎯 목표

• ready_list를 priority 기준으로 정렬해서 가장 높은 우선순위 스레드를 먼저 실행
• 세마포어, 락, 조건변수 등 동기화 구조에서도 높은 우선순위 스레드 먼저 깨어나게 하기
• Preemption (선점): 새로 들어온 스레드가 더 높은 우선순위면 CPU 뺏기

📌 구현에서 고려할 핵심 세 가지

1. Priority Scheduling

• ready_list에서 항상 priority 높은 스레드 먼저 실행

• 새 스레드가 들어오면 현재 running 스레드와 우선순위 비교

2. Priority Synchronization

• Lock, Semaphore, Condition Variable 등에서 기다리는 스레드도 priority 순 정렬

3. Priority Donation

• 낮은 우선순위 스레드가 락을 잡고 있어서 높은 우선순위 스레드가 대기하는 문제 해결

CH3

├── Process

│ ├── 📌Process Concept /정의 및 구성 요소 │ ├──🔄 Process State /상태 변화 및 PCB(Process Control Block) │ ├──-🧵Threads(Process 내부)/하나의 프로세스 내부 다중 실행 흐름 │ ├──🐧 Linux에서의 프로세스 표현/ task_struct │ ├──⚙️ Process Scheduling/ scheduling queues, Context switch, │ │     │        Multitasking in Mobile Systems 등 │ │     └── scheduling queues: Ready queue, Wait queues │ │ │ └──📥Operations on Processes/ 생성(fork, exec) / 종료 (exit, wait) ├──💬Interprocess Communication (IPC) │ ├──📦Shared Memory/ 공유 메모리 방식 │ ├──✉️ Message Passing/ 메시지 전송 기반 통신 │ │    └── Direct & Indirect Communication │ │        └──Synchronization, Buffering │ └── 🛠️ IPC 예시 시스템/ POSIX, Pipes 등 └──🌐 Client-Server Communication/ Sockets, RPC, Java 소켓 예제 등

1. TCP Sequence Number

• 정의: TCP 세그먼트의 시퀀스 번호는 해당 세그먼트가 전송하는 데이터 중 첫 번째 바이트의 번호입니다.
• 예시: 바이트 127부터 80바이트 전송 시 → 시퀀스 번호는 127이고, 다음 세그먼트의 시퀀스 번호는 127 + 80 = 207입니다.

📚 참고: {ch3.pdf} 235~236쪽 (Section 3.4 Reliable Data Transfer)

2. TCP Acknowledgment Number

• 정의: 수신 측이 다음으로 기대하는 바이트의 번호를 의미합니다.
• ✅ 누적 ACK(Cumulative Acknowledgment) 사용
  → 중간 일부만 도착하더라도, 가장 처음 누락된 바이트까지만 ACK 합니다.

📚 참고: {ch3.pdf} 235~238쪽 (Section 3.4), 258쪽 부근 (TCP ACK Generation)

3. 세그먼트 도착 순서에 따른 ACK 동작

• ✅ 순서대로 도착한 경우:

  • 첫 번째 세그먼트: ACK = 127 + 80 = 207
  • 두 번째 세그먼트: ACK = 207 + 40 = 247

• ⚠️ 두 번째 세그먼트가 먼저 도착한 경우:

  • 예상 시퀀스가 아닌 세그먼트가 오면 → 중복 ACK 생성: ACK = 127

📚 참고: {ch3.pdf} 258쪽 부근

4. TCP Port Numbers

• TCP 세그먼트는 다음 정보를 포함합니다:
  • Source Port Number
  • Destination Port Number
• 일반적으로 연결 세션 동안 포트 번호는 동일하게 유지됨

📚 참고: {ch3.pdf} 221~224쪽 (Section 3.2 Multiplexing and Demultiplexing)

5. ACK 손실과 Timeout 처리

• ACK가 손실될 경우, 송신 측은 타이머가 만료될 때까지 ACK를 기다립니다.
• ⏰ 타이머가 만료되면 해당 세그먼트를 재전송합니다.

📚 참고: {ch3.pdf} 240쪽 (rdt3.0 개념에서 설명)

✅ P28 문제 해결을 위한 필수 개념 요약

1. TCP Flow Control (흐름 제어)

• 목적: 송신자가 너무 빠르게 데이터를 보내서 수신자의 수신 버퍼를 넘치게 하지 않도록 제어하는 기능.
• 이는 송신자의 속도를 수신자의 읽기 속도에 맞추는 속도 일치 서비스(speed-matching service)입니다.

📄 관련 페이지: {ch3.pdf} 280~282쪽

2. TCP Receive Buffer와 관련 변수

수신자는 TCP 연결마다 receive buffer(RcvBuffer)를 할당하며, 다음 변수가 정의됩니다:

• LastByteRead: 수신 응용 프로그램이 버퍼에서 읽은 마지막 바이트
• LastByteRcvd: 수신 버퍼에 도착한 마지막 바이트
• Receive Window (rwnd): 버퍼의 여유 공간
  계산식:
  [ rwnd = RcvBuffer - (LastByteRcvd - LastByteRead) ]

📄 관련 페이지: {ch3.pdf} 281~282쪽

3. 수신자가 송신자에게 rwnd 전달 방식

• 수신자는 자신의 rwnd 값을 ACK 세그먼트의 "Receive Window" 필드에 담아 송신자에게 전달함.
• 송신자는 다음을 보장해야 함:
  [ LastByteSent - LastByteAcked \leq rwnd ]

즉, 수신자가 허용한 만큼만 데이터를 전송할 수 있습니다.

📄 관련 페이지: {ch3.pdf} 281쪽

4. rwnd가 0이 되었을 때의 처리

• 만약 수신 버퍼가 가득 차서 rwnd = 0이 되면 송신자는 블로킹됨.
• 이 경우 송신자가 아무것도 못 보내는 것을 방지하기 위해 1바이트 세그먼트를 계속 보내어 수신자의 rwnd 변화를 감지하도록 명시되어 있음.

📄 관련 페이지: {ch3.pdf} 282쪽

5. TCP 흐름 제어 vs 혼잡 제어

• 흐름 제어는 수신자의 속도에 맞추기 위한 것
• 혼잡 제어는 네트워크 내 혼잡을 방지하기 위한 것
• 둘 다 송신자의 속도를 제한하지만, 이유와 메커니즘이 다름

📄 관련 페이지: {ch3.pdf} 280쪽

✅ P32 문제 해결을 위한 필수 개념 요약

1️⃣ Round-Trip Time (RTT)의 정의

• RTT (Round-Trip Time)는 세그먼트를 전송하고 해당 세그먼트에 대한 ACK(확인 응답)를 수신하는 데 걸리는 시간입니다.
• TCP는 이를 샘플 RTT (SampleRTT)라고 부르며, 재전송된 세그먼트는 RTT 측정 대상에서 제외합니다.

📄 {ch3.pdf} 269쪽 설명 참조

2️⃣ RTT 측정의 어려움과 평균의 필요성

• SampleRTT 값은 혼잡, 라우터 큐 대기, 시스템 부하 등에 따라 변동성이 매우 큽니다.
• 따라서 TCP는 단일 SampleRTT를 그대로 사용하지 않고, 지속적으로 평균을 유지하면서 새로운 값을 반영하는 방식을 사용합니다.

3️⃣ EstimatedRTT의 정의와 업데이트 공식

• TCP는 SampleRTT의 평균값을 EstimatedRTT라는 이름으로 유지합니다.
• 업데이트 공식은 다음과 같습니다:

[ \text{EstimatedRTT} = (1 - \alpha) \cdot \text{EstimatedRTT} + \alpha \cdot \text{SampleRTT} ]

• 여기서 α는 보통 0.125 (1/8)이 추천됩니다. (문제에서는 α = 0.1 사용)

📄 {ch3.pdf} 270쪽 설명 참조

4️⃣ 지수 이동 평균 (Exponential Weighted Moving Average, EWMA)

• 위 공식은 통계적으로 지수 이동 평균 (EWMA)이라고 불립니다.
• 이전 값에 더 많은 가중치를 두되, 새로운 SampleRTT도 점진적으로 반영합니다.
• 왜 “exponential”인가?
  → 예전 SampleRTT는 시간이 지날수록 가중치가 지수적으로 줄어들기 때문입니다.

📄 {ch3.pdf} 270쪽 중간 설명 참조

5️⃣ DevRTT (편차)와 TimeoutInterval

• DevRTT는 SampleRTT가 EstimatedRTT로부터 얼마나 벗어나는지를 측정하는 변동성 지표입니다. [ \text{DevRTT} = (1 - \beta) \cdot \text{DevRTT} + \beta \cdot |\text{SampleRTT} - \text{EstimatedRTT}| ]
• β는 보통 0.25로 추천됨
• 최종적으로, 재전송 타이머(TimeoutInterval)는 다음과 같이 설정됩니다:

[ \text{TimeoutInterval} = \text{EstimatedRTT} + 4 \cdot \text{DevRTT} ]

📄 {ch3.pdf} 270~271쪽 설명 참조

6️⃣ 왜 이 방식이 유용한가?

• 최근의 RTT 변화에 빠르게 적응하면서도, 예외적인 SampleRTT로 인해 예측이 급변하지 않도록 완충 역할을 합니다.
• 따라서 TCP는 네트워크의 불안정한 RTT 상황 속에서도 안정적으로 타이머를 관리할 수 있습니다.

✅ P34를 해결하기 위한 필수 개념 정리

🔹 SendBase (송신 측 변수)

• SendBase는 가장 오래된 미확인 바이트의 시퀀스 번호를 나타냅니다.
• 즉, 아직 ACK를 받지 못한 데이터 중 가장 앞선 바이트 번호입니다.
• SendBase - 1은 수신자가 정상적으로 수신하고 ACK로 확인한 마지막 바이트 번호가 됩니다.

📄 관련 설명: {ch3.pdf} 273~274쪽, Section 3.5.4

🔹 LastByteRcvd (수신 측 변수)

• LastByteRcvd는 수신자가 네트워크로부터 받은 마지막 바이트의 번호입니다.
• 즉, TCP 세그먼트가 도착하여 수신 버퍼에 저장된 마지막 바이트 번호입니다.

📄 관련 설명: {ch3.pdf} 281쪽, Section 3.5.5

✅ 두 변수 간의 관계

• SendBase는 송신자가 수신자로부터 ACK를 받았는지 여부에 따라 추적되는 값입니다.
• 반면 LastByteRcvd는 수신자가 물리적으로 받은 바이트 수를 추적합니다.
• 이 두 변수는 간접적으로 연결됩니다:
  ➤ 송신자가 SendBase를 갱신하는 것은, 수신자가 데이터를 받아 LastByteRcvd를 증가시킨 후 ACK를 보냈기 때문입니다.

🔁 요약하자면:

• LastByteRcvd가 증가하고 → 수신자가 ACK를 보냄 →
• 이 ACK를 받은 송신자가 → SendBase를 증가시킴

따라서 두 변수는 TCP 연결 양쪽에서 서로 상호작용하며 TCP의 신뢰성 보장을 위해 함께 동작하는 핵심 요소라고 볼 수 있습니다.

✅ P35를 해결하기 위한 필수 개념 정리

🔹 y (Section 3.5.4, 송신 측 ACK 필드)

• y는 수신자로부터 도착한 ACK 세그먼트의 ACK 번호 값입니다.
• y는 수신자가 “바이트 y-1까지 수신했음을” 의미합니다.
• 송신 측은 y > SendBase일 경우 SendBase = y로 갱신합니다.

📄 참고: {ch3.pdf} 273~274쪽

🔹 LastByteRcvd (Section 3.5.5, 수신 측 변수)

• LastByteRcvd는 수신자가 네트워크로부터 실제로 받은 가장 마지막 바이트의 번호입니다.
• 즉, TCP 세그먼트가 도착하여 수신 버퍼에 저장된 가장 높은 바이트 번호입니다.

📄 참고: {ch3.pdf} 281쪽

🔁 두 변수 간의 관계

• y는 수신자가 ACK로서 보낸 다음으로 기대하는 바이트 번호입니다.
  즉, y = LastByteRcvd + 1가 되는 경우가 많습니다.
• 이 경우 송신자는 y를 받아 SendBase = y로 설정하고, 이는 수신자의 LastByteRcvd를 기준으로 자신의 송신 상태를 갱신하는 것입니다.

✅ 정리된 설명

• LastByteRcvd는 수신자 측에서 실제 수신된 가장 마지막 바이트의 시퀀스 번호
• y는 ACK 메시지에서 나타나는 수신자의 다음 기대 바이트 번호
• 따라서 y = LastByteRcvd + 1 이고, 이로 인해 송신자는 자신이 보낸 데이터가 수신 측에서 확인되었음을 판단합니다.

이러한 구조를 통해 TCP는 송신 측과 수신 측의 상태 정보를 정확히 동기화하며 신뢰성 있는 데이터 전송을 구현합니다.

✅ 문제 P36을 풀기 위한 개념 정리

1. Duplicate ACK의 의미

• Duplicate ACK는 송신자가 이미 ACK를 받은 세그먼트에 대해 다시 ACK가 도착하는 것.
• 수신자는 예상보다 높은 sequence number를 가진 세그먼트를 받았을 때, 중간에 누락된 세그먼트가 있다는 뜻으로 duplicate ACK를 보냄.
• 이 방식은 TCP가 NAK(Negative ACK) 없이도 세그먼트 손실을 간접적으로 탐지할 수 있게 합니다

2. 왜 1개 duplicate ACK만으로는 빠른 재전송을 하지 않는가?

• 세그먼트 손실이 아닌, 단순히 세그먼트가 재정렬(out-of-order) 되어 도착했을 가능성도 있습니다.
• 네트워크 상황에 따라 임시적인 패킷 순서 뒤바뀜이 있을 수 있으며, 이는 실제 손실과는 무관합니다.
• 이런 상황에서 단 1개의 duplicate ACK만 보고 재전송을 하면 불필요한 재전송이 발생할 수 있습니다.

3. 3개 duplicate ACK의 의미

• TCP는 3개의 duplicate ACK가 도착하면 이를 신뢰할 수 있는 손실 신호로 간주합니다.
• 왜냐하면 송신자는 일반적으로 여러 세그먼트를 백투백으로 전송하고, 수신자도 연속적으로 ACK를 보냅니다.
• 따라서 같은 ACK가 3번 중복되어 도착하면, 중간에 있는 세그먼트가 손실되었고, 그 뒤의 세그먼트들이 도착했다는 것을 유력하게 추론할 수 있습니다

4. Fast Retransmit의 조건 요약

• TCP는 세 번째 duplicate ACK가 도착하면, 그 시점에서 fast retransmit을 수행합니다.
• 이는 타이머 만료를 기다리지 않고 빠르게 손실을 복구함으로써 end-to-end delay를 줄이기 위한 전략입니다

✅ P40을 풀기 위한 필수 개념 정리 (유기적 흐름)

📦 1️⃣ Congestion Window (cwnd)

• 정의: TCP 송신자가 네트워크 혼잡을 고려해 동시에 보낼 수 있는 최대 바이트 양(또는 세그먼트 수)를 의미.
• 역할: cwnd 값은 전송 속도를 제한하는 핵심 변수이며, 시간에 따라 지속적으로 증가/감소함.

📘 관련: 혼잡 제어 알고리즘의 기반이 되는 변수

🚀 2️⃣ TCP Slow Start

• 동작 조건: 연결 시작 시 또는 timeout 발생 후, cwnd는 1로 초기화되고 지수적으로 증가함 (cwnd *= 2).
• 종료 조건: cwnd가 ssthresh(slow start threshold)를 초과하면 slow start 종료 → congestion avoidance 진입

📘 효과: 네트워크 상태를 빠르게 탐색하며 가능한 전송률까지 증가

📈 3️⃣ TCP Congestion Avoidance

• 동작 조건: cwnd >= ssthresh가 된 시점부터, cwnd는 매 RTT마다 선형적으로 증가 (cwnd += 1)
• 목적: 혼잡을 일으키지 않도록 천천히 전송 속도를 조정

📘 특징: 혼잡이 감지되지 않는 한, 네트워크에 부하를 최소화하며 신중하게 윈도우 증가

📬 4️⃣ Loss Detection via Triple Duplicate ACKs (Fast Retransmit + Fast Recovery)

• 조건: 같은 ACK를 3번 이상 받으면, 중간 세그먼트 손실로 간주
• TCP Reno 동작:
  • ssthresh = cwnd / 2
  • cwnd = ssthresh
  • 손실된 세그먼트를 즉시 재전송 (timeout보다 빠름)

📘 장점: timeout을 기다리지 않고 빠르게 복구함 → "fast retransmit"

⏰ 5️⃣ Loss Detection via Timeout

• 조건: ACK를 일정 시간 내에 받지 못하면 타이머 만료
• 모든 TCP 버전 공통 동작:
  • ssthresh = cwnd / 2
• TCP Reno:
  • cwnd = 1 (slow start로 다시 진입)
• TCP Tahoe:
  • 동일하게 cwnd = 1, ssthresh = cwnd / 2 → 반드시 slow start로 재시작

📘 특징: 가장 보수적인 복구 방법, 전송 속도 급감

🎚️ 6️⃣ Slow Start Threshold (ssthresh)

• 역할: slow start와 congestion avoidance를 구분하는 경계값
• 갱신 시점: 손실 발생 시마다 ssthresh = cwnd / 2로 갱신됨
• TCP의 회복 행동은 이 값에 따라 달라짐

📘 연관: ssthresh는 네트워크의 혼잡도를 판단하고 향후 증가 전략을 조정하는 기준선

🔁 7️⃣ TCP Tahoe vs Reno 차이

📘 이 차이는 (j), (k)와 같은 질문에 매우 중요함

⌛ 8️⃣ Transmission Round의 의미

• Transmission round = 한 라운드 내에서 가능한 한도까지 segment를 보낸 후, 해당 ACK가 도착할 때까지 기다리는 시간
• 각 round에서 cwnd 크기만큼 segment 전송 가능

📘 그래프의 x축 단위 해석의 기준이 되는 개념

🧮 9️⃣ Segment 수 계산 방법

• 각 round에서 보낼 수 있는 세그먼트 수는 해당 round의 cwnd 값과 동일
• 누적합을 통해 몇 번째 세그먼트가 어떤 round에서 전송되었는지 추적 가능

📘 (h), (k)와 같은 문항에 필수

이처럼 P40은 단일 개념이 아니라, TCP 혼잡 제어 알고리즘 전반의 흐름과 조건 간 전이 원리를 종합적으로 파악하는 문제입니다.
그래서 각 질문은 단순 수치 이상의 개념 간 상호작용에 기반해 풀어야 해요.