전산사기단

hwp, hwpx -> pdf 로 변경.

사리생성 — Mon, 9 Mar 2026 20:53:07 +0900

각 파일 포맷별 PDF 변환 원리 (각론)

1. HWP 변환 원리 (구형 포맷)
확장자: .hwp
원리: HWP는 사실상 하나의 덩어리로 된 알 수 없는 암호 코드(이진 바이너리)입니다. 따라서 이 암호를 해독할 수 있는 전문 도구인 pyhwp(hwp5html) 라이브러리를 통해 글자와 서식을 아주 단순한 웹 페이지 문서(.xhtml) 형태로 먼저 해부하고 펼쳐냅니다. 그 펼쳐진 웹 문서를 마치 크롬 브라우저에서 'PDF로 인쇄'하듯이 안정적인 LibreOffice 엔진이 찍어내는 방식입니다.

2. HWPX 변환 원리 (신형 포맷)
확장자: .hwpx
원리: HWPX는 사실 수십 개의 XML 문서 쪼가리들이 모여있는 ZIP 파일입니다. 제가 직접 개발한 **fast_parser.py**가 HWPX 속의 내부 압축을 풀고 section.xml 파일들의 심장부로 파고듭니다. 이때 셀 병합(칸 합치기) 정보, 서식, 중첩 표(표 안의 표) 구조 등을 아주 엄격하게 직계 자손 단위로 추적(재귀 파싱)하여, 누락이나 겹침 없이 가장 완벽한 형태의 최신 HTML 표준 웹 브라우저 코드로 뼈대를 조립합니다. 만들어진 뼈대 구석구석에 강제 테두리(border="1")를 단단히 박아 넣은 후 LibreOffice를 통해 아주 빠르게 구워냅니다.

3. 단일 이미지 변환 원리 (PNG, JPG, JPEG)
확장자: .png, .jpg, .jpeg
원리: 이미지들은 복잡한 표 구조가 없지만 종종 투명한 배경(Alpha 채널) 문제로 인해 PDF로 구우면 검정 배경으로 왜곡되는 치명적 문제가 있습니다. 이를 방지하기 위해 파이썬의 가장 가벼운 화가 라이브러리인 **Pillow**를 이용하여, 이미지를 불러온 뒤 안전한 RGB 도화지(흰 배경)로 보완하고 고화질 규격(100.0 dpi)을 유지한 채 PDF 단일 페이지에 그대로 꽉 차게 구워버리는 img_to_pdf.py 방식을 취합니다.
어떻게 사용할 수 있나요? (통합 사용법)

이 3가지의 원리를 모두 담아서 제가 convert_all.sh 라는 자동화 런처에 모아두었습니다. 작업 파일 목록 옆에 보이는 HWP_Conversion_Package.md 문서를 열어보시면 이 모든 과정을 복사해서 아무 컴퓨터에서나 실행할 수 있도록 딱 **4개의 소스 코드(Dockerfile, fast_parser.py, img_to_pdf.py, convert_all.sh)**로 가장 가볍게 압축해 두었습니다.

#!/bin/bash

# 통합 HWP / HWPX -> PDF 변환 런처
IMAGE_NAME="hwp-to-pdf"

echo "--- 1. 도커 이미지 빌드 중 (최초 1회만 오래 걸림) ---"
podman build -t $IMAGE_NAME . > /dev/null 2>&1

echo "--- 2. 대상 폴더 내 모든 hwp, hwpx 변환 시작 ---"

# HWP 파일 변환 (hwp5html 사용)
for file in *.hwp; do
    [ -e "$file" ] || continue
    echo ">> [HWP] \"$file\" 변환 중..."
    basename="${file%.*}"
    
    # 임시 디렉토리 정리 (혹시 남아있을 수 있으므로)
    rm -rf "hwp_out_$basename"
    
    # pyhwp로 HTML 생성
    podman run --rm --user 0:0 -v "$(pwd):/data:Z" $IMAGE_NAME /opt/venv/bin/hwp5html "/data/$file" --output "/data/hwp_out_$basename" > /dev/null 2>&1
    
    if [ -d "hwp_out_$basename" ]; then
        # 생성된 HTML을 PDF로 렌더링
        podman run --rm --user 0:0 -v "$(pwd):/data:Z" $IMAGE_NAME libreoffice --headless --convert-to pdf --outdir /data "/data/hwp_out_$basename/index.xhtml" > /dev/null 2>&1
        if [ -f "index.pdf" ]; then
            mv index.pdf "${basename}.pdf"
            echo "   -> 완료: ${basename}.pdf"
        else
            echo "   -> PDF 렌더링 실패: $file"
        fi
        rm -rf "hwp_out_$basename"
    else
        echo "   -> 파싱 실패 (HTML로 추출할 수 없음): $file"
    fi
done

# HWPX 파일 변환 (자체 고속 파서 + 보정기 사용)
for file in *.hwpx; do
    [ -e "$file" ] || continue
    echo ">> [HWPX] \"$file\" 변환 중..."
    basename="${file%.*}"
    
    # 파이썬 파서로 HTML 초고속 추출
    podman run --rm -v "$(pwd):/data:Z" $IMAGE_NAME python3 /data/fast_parser.py "/data/$file" "/data/hwpx_out_$basename.html"
    
    if [ -f "hwpx_out_$basename.html" ]; then
        # PDF 렌더링
        podman run --rm -v "$(pwd):/data:Z" $IMAGE_NAME libreoffice --headless --convert-to pdf --outdir /data "/data/hwpx_out_$basename.html" > /dev/null 2>&1
        if [ -f "hwpx_out_${basename}.pdf" ]; then
            mv "hwpx_out_${basename}.pdf" "${basename}.pdf"
            echo "   -> 완료: ${basename}.pdf"
        else
            echo "   -> PDF 렌더링 실패: $file"
        fi
        rm -f "hwpx_out_$basename.html" "hwpx_out_${basename}.pdf"
    else
        echo "   -> 파싱 실패: $file"
    fi
done

# 이미지 파일(PNG, JPG, JPEG) 변환 (Pillow 사용)
for file in *.{png,jpg,jpeg}; do
    [ -e "$file" ] || continue
    echo ">> [IMAGE] \"$file\" 변환 중..."
    basename="${file%.*}"
    
    # 이미지 -> PDF 변환
    podman run --rm -v "$(pwd):/data:Z" $IMAGE_NAME /opt/venv/bin/python /data/img_to_pdf.py "/data/$file" "/data/${basename}.pdf"
    
    if [ -f "${basename}.pdf" ]; then
        echo "   -> 완료: ${basename}.pdf"
    else
        echo "   -> 변환 실패: $file"
    fi
done

echo "--- 모든 변환 작업 완료 ---"

import xml.etree.ElementTree as ET
import zipfile
import sys
import os

def parse_element(elem, ns):
    tag = elem.tag.split('}')[-1]
    
    if tag == 'p':
        content = []
        for child in elem:
            content.append(parse_element(child, ns))
        text_content = "".join(content)
        # 제목 스타일 적용
        if '참가신청서' in text_content or '신청 양식' in text_content or '개인정보 수집 및 이용 동의서' in text_content:
            return f'<h1>{text_content}</h1>'
        return f'<div class="p">{text_content}</div>'
    
    elif tag == 'run':
        content = []
        for child in elem:
            content.append(parse_element(child, ns))
        return "".join(content)
        
    elif tag == 't':
        return elem.text if elem.text else ""

    elif tag == 'tab':
        return "&nbsp;&nbsp;&nbsp;&nbsp;"
    
    elif tag == 'tbl':
        rows_html = []
        for child in elem:
            if child.tag.endswith('}tr'):
                cells_html = []
                for tc in child:
                    if tc.tag.endswith('}tc'):
                        colspan, rowspan = "1", "1"
                        for prop in tc:
                            if prop.tag.endswith('}cellSpan'):
                                colspan = prop.get('colSpan', "1")
                                rowspan = prop.get('rowSpan', "1")
                                break
                        
                        cell_content = ""
                        for tc_child in tc:
                            if tc_child.tag.endswith('}subList'):
                                for sub_child in tc_child:
                                    if sub_child.tag.endswith('}p'):
                                        cell_content += parse_element(sub_child, ns)
                            elif tc_child.tag.endswith('}p') or tc_child.tag.endswith('}tbl'):
                                cell_content += parse_element(tc_child, ns)
                        
                        attr = ''
                        if colspan != "1": attr += f' colspan="{colspan}"'
                        if rowspan != "1": attr += f' rowspan="{rowspan}"'
                        cells_html.append(f'<td{attr} style="border: 1px solid black; padding: 6px; min-height: 20px;">{cell_content}</td>')
                rows_html.append(f'<tr>{"".join(cells_html)}</tr>')
        return f'<table border="1" cellspacing="0" cellpadding="5" style="border-collapse: collapse; width: 100%; margin: 15px 0; border: 2px solid black;">{"".join(rows_html)}</table>'    
    # 이외의 알 수 없는 태그들은 자식 노드들을 계속 파싱합니다.
    else:
        content = []
        for child in elem:
            # 테이블 안의 tr, tc, 기타 등 직접 명시한 태그 외의 것들에 대해 재귀 호출
            # <hp:tc>가 또 다시 반복 호출되는 것을 막아야 중복 출력이 안됨
            if not child.tag.endswith('}tc') and not child.tag.endswith('}tr') and not child.tag.endswith('}cellZoneList'):
                content.append(parse_element(child, ns))
        return "".join(content)

def hwpx_to_pro_html(hwpx_path, html_path):
    ns = {
        'hp': 'http://www.hancom.co.kr/hwpml/2011/paragraph',
        'hs': 'http://www.hancom.co.kr/hwpml/2011/section'
    }
    
    html_header = [
        '<!DOCTYPE html>',
        '<html><head><meta charset="utf-8">',
        '<style>',
        '  @media print { @page { size: A4; margin: 15mm; } }',
        '  body { font-family: "NanumGothic", sans-serif; line-height: 1.4; color: #000; font-size: 10pt; background: #fff; }',
        '  .p { min-height: 1.1em; margin-bottom: 3px; }',
        '  table { border-collapse: collapse; width: 100%; margin: 15px 0; border: 2px solid #000 !important; table-layout: fixed; }',
        '  td, th { border: 1px solid #000 !important; padding: 6px; vertical-align: middle; min-height: 20px; background-color: #fff; word-break: break-all; }',
        '  h1 { text-align: center; font-size: 16pt; margin: 25px 0 15px 0; font-weight: bold; border-bottom: 2px solid #000; padding-bottom: 5px; }',
        '</style>',
        '</head><body>'
    ]

    
    try:
        with zipfile.ZipFile(hwpx_path, 'r') as z:
            sections = [n for n in z.namelist() if n.startswith('Contents/section') and n.endswith('.xml')]
            sections.sort()
            
            all_html = []
            for section_name in sections:
                with z.open(section_name) as f:
                    root = ET.fromstring(f.read())
                    all_html.append(parse_element(root, ns))
            
            with open(html_path, 'w', encoding='utf-8') as f:
                f.write("\n".join(html_header))
                f.write("\n".join(all_html))
                f.write('</body></html>')
        return True
    except Exception as e:
        print(f"Error: {e}")
        return False

if __name__ == "__main__":
    hwpx_to_pro_html(sys.argv[1], sys.argv[2])

import sys
from PIL import Image

def image_to_pdf(image_path, pdf_path):
    try:
        # 이미지를 열고 RGBA 모드인 경우 RGB로 변환 (PDF 저장을 위해)
        image = Image.open(image_path)
        if image.mode in ("RGBA", "P"):
            image = image.convert("RGB")
        
        # 이미지 저장
        image.save(pdf_path, "PDF", resolution=100.0)
        return True
    except Exception as e:
        print(f"Error: {e}")
        return False

if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("Usage: python img_to_pdf.py <input_image> <output_pdf>")
        sys.exit(1)
    
    success = image_to_pdf(sys.argv[1], sys.argv[2])
    sys.exit(0 if success else 1)

ubuntu 24.04 카카오톡 설치.

사리생성 — Mon, 2 Feb 2026 13:34:49 +0900

Bottles vs WINE 비교

특징	Bottles (추천 )	순수 WINE
사용 난이도	쉬움 (GUI 기반, 클릭 몇 번으로 설정)	보통~어려움 (터미널 명령어 위주)
환경 격리	완벽함 (앱마다 독립된 가상 환경 생성)	제한적 (하나의 WINE 설정이 꼬이면 복잡함)
글꼴 설정	GUI 설정에서 폰트 추가가 쉬움	윈도우 폰트를 시스템 폴더로 직접 복사 필요
관리 효율	프로그램마다 최적의 설정(Runner) 선택 가능	버전 관리가 어렵고 업데이트 시 충돌 가능성
성능/무게	샌드박스 방식이라 초기 실행이 약간 느림	시스템 리소스를 덜 먹고 실행 속도가 빠름

Wine이라는 호환 레이어를 사용하기로 함.

1. Wine 설치.

Bash

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install wine64 wine32

설치시 망설이게 되는 부분.

28개 업그레이드, 214개 새로 설치, 0개 제거 및 39개 업그레이드 안 함.
332 M바이트 아카이브를 받아야 합니다.
이 작업 후 1,578 M바이트의 디스크 공간을 더 사용하게 됩니다.

2. 카카오톡 다운로드

32bit로 다운로드 후 설치.

다운로드$ wine ./KakaoTalk_Setup.exe

한글 깨짐 방지 (필수 설정)

설치 과정이나 실행 후 한글이 사각형(ㅁㅁㅁ)으로 깨져 보일 수 있습니다. 이를 해결하려면 윈도우 기본 폰트를 Wine 설정에 넣어줘야 합니다.

폰트 복사: 윈도우의 나눔고딕이나 굴림 폰트(.ttf) 파일을 ~/.wine/drive_c/windows/Fonts 폴더 안에 복사합니다.

실행이 안되서 이것저것 보다가 아래와 같이 함. 설치 후 잘됨.

2.1) wine --version
wine-9.0 (Ubuntu 9.0~repack-4build3)

2.2) wine 삭제 후 다시 설치.

# 1. 기존 설치된 wine 제거 (설정 파일은 유지됨)
sudo apt remove --purge wine64 wine32 wine

# 2. 공식 저장소 키 및 리포지토리 등록 (이전 단계에서 했다면 생략 가능)
sudo mkdir -pm 755 /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubuntu/dists/noble/winehq-noble.sources

# 3. 패키지 리스트 업데이트
sudo apt update

# 4. WineHQ Staging 버전 설치 (Themida 에러 대응에 더 유리함)
sudo apt install --install-recommends winehq-staging

폰에서 이미지가 잘리지 않고 가장 이쁘게 보이려면.

사리생성 — Mon, 2 Feb 2026 12:06:57 +0900

폰(모바일)에서 이미지가 잘리지 않고 가장 예쁘게 보이려면 서비스의 UI 구조에 따라 적절한 비율을 선택하는 것이 중요합니다. 현재 구현된 InsideMe 서비스의 디자인을 기준으로 추천 사이즈와 비율을 정리해 드릴게요.

1. 추천 비율 및 사이즈 (가로 x 세로)

용도추천 비율추천 사이즈 (px)특징

메인/대표 이미지	1:1 (정사각형)	1024 x 1024	현재 관리자 페이지의 기본 크롭 비율입니다. 가장 범용적이고 깔끔합니다.
인물/페르소나 카드	4:5 (Portrait)	1080 x 1350	인스타그램 피드 비율로, 모바일 화면을 더 꽉 채워 전문적이고 프리미엄한 느낌을 줍니다.
전체 배경/카드	9:16 (세로형)	1080 x 1920	스토리 형식이나 배경 전체를 쓰는 이미지에 적합합니다.

2. 왜 이 사이즈인가요?

관리자 페이지(Admin) 호환성: 현재 구현된 관리자 페이지의 이미지 크롭 기능이 1:1 비율로 설정되어 있습니다. 따라서 1024 x 1024 사이즈로 생성하시면 관리자 페이지에서 별도의 편집 없이 바로 사용할 수 있어 가장 편리합니다.
모바일 최적화: 모바일은 세로로 길기 때문에, 가로로 긴 이미지(16:9)보다는 **정사각형(1:1)**이나 약간 세로로 긴(4:5) 이미지가 화면을 더 많이 차지하여 시각적인 만족도가 훨씬 높습니다.
선명도: 최근 고해상도 모바일 액정을 고려하여 가로세로 1000px 이상으로 생성하시는 것이 글자나 디테일이 뭉개지지 않고 선명하게 보입니다.

결론적으로, 하나만 고르신다면 1024 x 1024 (1:1) 를 가장 추천드립니다! 더 세련된 결과값을 원하신다면 1080 x 1350 (4:5)

로 생성해 보세요.

Strapi 개 쓰레...

사리생성 — Mon, 26 Jan 2026 23:57:54 +0900

Strapi는 강력한 Node.js 기반 오픈소스 Headless CMS이지만, 복잡한 쿼리 튜닝의 어려움, 메이저 버전 업데이트의 높은 난이도, 자체 호스팅에 따른 서버 관리 부담, 다국어 콘텐츠 관리의 불편함 등이 주요 단점으로 꼽힙니다.

주요 단점은 다음과 같습니다.

복잡한 쿼리 튜닝 어려움: Bookshelf ORM / Mongoose ODM 위에 전용 ORM이 맵핑된 구조라 복잡한 데이터 조인이나 쿼리 튜닝이 어렵습니다.
메이저 업데이트의 어려움: 버전이 업데이트될 때 기존 데이터 구조나 코드와의 호환성 문제가 자주 발생하여 업그레이드 과정이 까다롭습니다.
자체 호스팅 부담: 클라우드 기반이 아닌 직접 호스팅해야 하는 경우, 서버 관리, 인프라 구축, 보안 설정 등을 직접 처리해야 하는 번거로움이 있습니다.
다국어 기능 제한: 콘텐츠 번역 시 문서(PDF, 오피스 등)로 변환해 외부에 맡겨야 하는 등 편리한 다국어 관리 도구가 부족합니다.
복잡한 로직 구현: 데이터 구조가 단순할 때는 좋지만, 복잡한 비즈니스 로직을 백엔드에 추가하려 하면 구조적 한계에 부딪힐 수 있습니다.

이러한 단점에도 불구하고, 빠른 API 구축과 유연한 데이터 모델링이 필요한 경우 매우 유용한 도구입니다.

RAG -> milvus (밀부스) + Elasticsearch ( chroma T.T )

사리생성 — Sat, 24 Jan 2026 00:15:19 +0900

RAG ( Retrieval-Augmented Generation ) : 검색 증강 생성

1. 설치 ( podman )

운영 환경이나 대량의 데이터를 다룰 때 권장되는 방식입니다. Docker Compose를 사용하여 설치합니다.

설치 스크립트 다운로드 및 실행 (Linux/macOS) : 성공적으로 실행되면 19530 포트로 서비스가 열립니다.

podman

# 작업 디렉토리 생성
mkdir milvus-podman && cd milvus-podman

# 공식 compose 파일 다운로드
curl -sfL https://raw.githubusercontent.com/milvus-io/milvus/refs/heads/master/deployments/docker/standalone/docker-compose.yml -o docker-compose.yml

# 서비스 시작
podman-compose up -d

# 실행 상태 확인 (모든 컨테이너가 'Up' 혹은 'Healthy'여야 함)
podman ps

** 수정
image: milvusdb/milvus:v2.6.9 -> image: docker.io/milvusdb/milvus:v2.6.9

chloe@chloe:~/milvus/milvus-podman$ podman ps
CONTAINER ID  IMAGE                                             COMMAND               CREATED         STATUS                     PORTS                                             NAMES
ed645ec4dbb9  quay.io/coreos/etcd:v3.5.25                       etcd -advertise-c...  14 minutes ago  Up 11 minutes (unhealthy)                                                    milvus-etcd
d269a259ed48  quay.io/minio/minio:RELEASE.2024-05-28T17-19-04Z  minio server /min...  14 minutes ago  Up 11 minutes (healthy)    0.0.0.0:9000-9001->9000-9001/tcp                  milvus-minio
d7996e27a7e8  docker.io/milvusdb/milvus:v2.6.9                  milvus run standa...  10 minutes ago  Up 10 minutes (healthy)    0.0.0.0:9091->9091/tcp, 0.0.0.0:19530->19530/tcp  milvus-standalone

MINIO_ACCESS_KEY: minioadmin
MINIO_SECRET_KEY: minioadmin

2. 관리도구 Attu 설치

podman

podman run -d \
    --name milvus-attu \
    -p 8000:3000 \
    -e MILVUS_URL=http://localhost:19530 \
    docker.io/zilliz/attu:latest

chloe@chloe:~/milvus/milvus-podman$ podman ps
CONTAINER ID  IMAGE                                             COMMAND               CREATED         STATUS                     PORTS                                             NAMES
b5a571121687  docker.io/zilliz/attu:latest                      /bin/bash -c /app...  6 minutes ago   Up 6 minutes               0.0.0.0:8000->3000/tcp                            milvus-attu

이후 브라우저에서 localhost:8000에 접속하여 데이터 상태를 모니터링할 수 있습니다.

머신러닝 - Transformer

사리생성 — Fri, 23 Jan 2026 19:08:11 +0900

Jay Alammar (제이 알라마르)

영문 : https://jalammar.github.io/illustrated-transformer

한글 : https://nlpinkorean.github.io/illustrated-transformer/

---

**머신러닝은 '학문적 개념 또는 기술'**이고, **텐서플로우는 그 기술을 구현하기 위한 '도구(라이브러리)'**

1. 머신러닝 (Machine Learning, ML)

머신러닝은 컴퓨터가 명시적인 프로그래밍 없이 데이터로부터 학습하여 판단이나 예측을 할 수 있도록 하는 AI의 한 분야입니다.

성격: 이론, 알고리즘, 방법론적 체계.
비유: '요리하는 법(레시피)' 그 자체라고 볼 수 있습니다.
핵심: 데이터를 분석하고 패턴을 찾아내어 미래를 예측하는 모델을 만드는 과정입니다.

2. 텐서플로우 (TensorFlow)

텐서플로우는 구글에서 개발한 오픈소스 소프트웨어 라이브러리로, 머신러닝과 딥러닝 모델을 쉽고 효율적으로 구축할 수 있도록 도와줍니다.

성격: 도구 세트, 소프트웨어 엔진, 프레임워크.
비유: 요리를 하기 위해 사용하는 '주방 도구(프라이팬, 칼, 오븐 등)'와 같습니다.
특징: 복잡한 수학적 계산을 처리해주고, 모델을 스마트폰이나 클라우드 등 다양한 환경에서 실행할 수 있게 지원합니다.

3. 주요 차이점 비교

구분	머신러닝 (ML)	텐서플로우 (TensorFlow)
정의	데이터 기반 학습 기법 (학문/이론)	ML 구현을 위한 도구 (소프트웨어)
범위	AI의 하위 집합으로 광범위함	머신러닝 구현 도구 중 하나
구성 요소	알고리즘 (회귀, 분류, 군집 등)	API, 데이터 흐름 그래프, 라이브러리
목적	문제 해결을 위한 지능형 시스템 구축	복잡한 수치 계산 및 신경망 구축 최적화

요약하자면

"머신러닝이라는 목적지에 가기 위해, 텐서플로우라는 자동차를 운전하는 것"과 같습니다. 머신러닝은 우리가 하고 싶은 일이고, 텐서플로우는 그 일을 더 빠르고 편하게 할 수 있게 해주는 수단입니다.

텐서플로우 외에 파이토치(PyTorch) 같은 도구도 있다.

-----

lm studio (토큰 보여줘서)

사리생성 — Thu, 22 Jan 2026 14:17:52 +0900

다른건 모르겠고. power user 에서 token을 보여주네.

대화의 연속성 (Context Window)

사리생성 — Thu, 22 Jan 2026 10:39:19 +0900

open-webui 볼륨 내부의 실제 데이터 구조

webui.db (가장 중요)
- 역할: SQLite 데이터베이스 파일입니다.
- 내용: 사용자 계정 정보, 비밀번호(해시), 채팅 히스토리, 설정값, 모델 리스트 등 텍스트로 된 거의 모든 핵심 데이터가 이 파일 하나에 저장됩니다.
- 주의: 볼륨 삭제 시 이 파일이 사라지기 때문에 모든 대화 기록이 날아가는 것입니다.
vector_db
- 역할: 벡터 데이터베이스 저장소입니다.
- 내용: 사용자가 문서(PDF, TXT 등)를 업로드했을 때, AI가 검색할 수 있도록 수치화(Embedding)한 데이터가 저장됩니다. RAG(문서 기반 답변) 기능을 사용할 때 참조되는 곳입니다.
uploads
- 역할: 원본 파일 저장소입니다.
- 내용: 채팅창에 직접 업로드한 이미지나 문서 파일들이 보관됩니다.
cache
- 역할: 임시 데이터 저장소입니다.
- 내용: 모델의 아이콘, 웹 리소스, 또는 처리 중인 임시 파일들이 저장되어 시스템 속도를 높이는 역할을 합니다. 삭제해도 시스템 운영에 치명적이지는 않지만 다시 생성되는 동안 느려질 수 있습니다.

Open WebUI(구 Ollama WebUI)가 사용자와의 대화에서 '문맥(Context)'을 기억하고 대화의 연속성을 유지하는 방식은 단순히 이전 말을 기억하는 것 이상의 복잡한 과정을 거칩니다.

대화의 연속성을 위해 Open WebUI가 수행하는 핵심 메커니즘 3가지는 다음과 같습니다.

1. 컨텍스트 윈도우(Context Window) 관리

LLM(거대언어모델)은 기본적으로 '기억력'이 없습니다. 매 질문마다 이전 대화 전체를 다시 모델에게 보내줘야 합니다.

대화 이력 전송: 사용자가 새 메시지를 보내면, Open WebUI는 webui.db에 저장된 이전 대화 묶음을 꺼내 질문 앞에 붙여서 모델에게 보냅니다.
슬라이딩 윈도우: 모델이 한 번에 처리할 수 있는 토큰(글자 단위) 한계가 있습니다. 대화가 너무 길어지면 Open WebUI는 가장 오래된 대화부터 잘라내어 최신 문맥이 유지되도록 관리합니다.

2. RAG (Retrieval-Augmented Generation) 활용

Retrieval-Augmented Generation(검색 증강 생성)은 대규모 언어 모델(LLM)이 답변을 생성하기 전에 외부의 신뢰할 수 있는 지식 베이스에서 관련 정보를 검색하여, 더 정확하고 최신이며 출처가 명확한 답변을 생성하도록 돕는 AI 기술입니다

질문이 특정 문서나 지식에 관한 것이라면, 단순한 대화 이력만으로는 부족합니다.

지식 검색: 사용자가 업로드한 문서(PDF 등)를 vector_db에서 찾아 질문과 가장 관련 있는 부분을 추출합니다.
정보 주입: 추출된 정보를 "이 내용을 참고해서 답해줘"라는 지시와 함께 프롬프트에 포함시켜, 모델이 모르는 내용도 마치 알고 있는 것처럼 연속성 있게 대답하게 합니다.

3. 세션 및 데이터베이스(SQLite) 동기화

사용자가 브라우저를 껐다 켜도 대화가 이어지는 이유는 앞서 보신 파일들 덕분입니다.

webui.db의 역할: 사용자가 입력하는 즉시 대화 내용을 데이터베이스에 기록합니다.
상태 보존: 특정 대화 세션의 ID를 기반으로, 모델 설정(온도, 시스템 프롬프트 등)과 과거 답변들을 매칭하여 일관된 답변 톤을 유지합니다.

대화 연속성 메커니즘 요약

기능	목적	관련 파일/기술
히스토리 추적	이전 대화 내용을 기억하고 참조	webui.db
시스템 프롬프트	AI의 페르소나와 답변 규칙 유지	설정값 (Settings)
임베딩 검색	대용량 문서 데이터를 대화에 반영	vector_db (RAG)

대화가 끊어진 느낌이 든다면.

Open WebUI와 Ollama를 사용하실 때 **Context Length(컨텍스트 길이)**는 AI가 한 번에 "기억하고 처리할 수 있는 데이터의 총량"을 의미합니다.

책에 비유하자면, AI가 현재 펼쳐놓고 볼 수 있는 **'책상의 크기'**와 같습니다. 책상이 좁으면 앞 내용을 계속 치워야(삭제해야) 새 내용을 읽을 수 있는 것과 같은 원리입니다.

1. Context Length가 중요한 이유

기억력: 이 값이 클수록 아주 긴 대화나 방대한 양의 문서 내용을 끝까지 기억하며 답변할 수 있습니다.1
답변 품질: 문맥이 충분히 제공되어야 AI가 사용자의 의도를 정확히 파악하고 일관성 있는 답변을 내놓습니다.
성능(속도): 값이 너무 크면 그래픽카드(RTX 4060)의 VRAM을 많이 점유하여 답변 속도가 느려지거나, 메모리 부족(OOM) 오류가 발생할 수 있습니다.

2. Open WebUI에서 설정하는 방법

Open WebUI 설정 창에서 모델별로 이 값을 조정할 수 있습니다.

모델 설정: 채팅창 상단 모델 선택 메뉴에서 설정(톱니바퀴 아이콘) 클릭
Advanced Parameters: 하단으로 내려가서 'Advanced Parameters' 확장
Context Length: 여기서 숫자를 변경 (기본값은 보통 2048 또는 4096)

3. 기술적 메커니즘: 토큰(Tokens)

컨텍스트 길이는 글자 수가 아니라 토큰(Token) 단위로 계산됩니다.

1024 토큰은 영어 기준으로 약 750단어 정도입니다.
사용자 질문 + 이전 대화 기록 + AI 답변 예정 분량이 이 숫자를 초과하면, 가장 오래된 대화부터 webui.db에서 읽어오지 않거나 모델 입력 단계에서 잘라냅니다.

4. 사용자님의 환경(RTX 4060) 권장 설정

현재 사용 중인 RTX 4060(VRAM 8GB) 환경에서는 모델 크기에 따라 최적의 값이 다릅니다:

모델 크기	권장 Context Length	비고
Gemma 3:4b	8192 ~ 16384	가벼운 모델이라 길게 설정 가능
Qwen 2.5:7b	4096 ~ 8192	8GB VRAM에서 안정적인 수준
Llama 3:8b	4096	VRAM 사용량이 아슬아슬할 수 있음

팁: 대화 도중 AI가 갑자기 "방금 말한 내용을 기억 못 하거나 엉뚱한 소리"를 한다면, 컨텍스트 길이를 조금 더 늘려보시는 것이 좋습니다.

GPU 메모리 최적화 설정

RTX 4060(8GB VRAM) 환경에서 Open WebUI와 Ollama를 최적으로 사용하기 위한 GPU 메모리 최적화 설정을 정리해 드립니다. 8GB는 7B~9B 모델을 돌리기에 다소 타이트할 수 있으므로, 아래 설정들을 적용하면 훨씬 쾌적해집니다.

1. Ollama 환경 변수 최적화 (서버 측)

Podman이나 Docker로 Ollama를 실행할 때 다음 환경 변수를 추가하여 메모리 점유를 제어하세요.

OLLAMA_MAX_LOADED_MODELS=1: 한 번에 하나의 모델만 GPU에 올리도록 제한합니다. 여러 모델을 불러와 VRAM이 낭비되는 것을 방지합니다.
OLLAMA_NUM_PARALLEL=1: 동시 요청 처리 수를 1개로 제한하여 KV 캐시가 VRAM을 과도하게 잡아먹지 않게 합니다.
OLLAMA_FLASH_ATTENTION=1: (지원 모델 한정) 연산 효율을 높이고 메모리 사용량을 줄여주는 Flash Attention 기능을 활성화합니다.

명령어 예시 (Podman 실행 시):

Bash

podman run -d --gpus all \
  -e OLLAMA_MAX_LOADED_MODELS=1 \
  -e OLLAMA_NUM_PARALLEL=1 \
  -e OLLAMA_FLASH_ATTENTION=1 \
  --name ollama ollama/ollama

2. Open WebUI 모델 파라미터 조정 (클라이언트 측)

Open WebUI의 Settings > Models > (모델 선택) > Advanced Parameters에서 조정합니다.

Num GPU (num_gpu):
- 보통 -1이나 35 이상으로 설정되어 모든 레이어가 GPU에 올라가야 빠릅니다.
- 만약 모델이 너무 커서 속도가 급격히 느려진다면(CPU 오프로딩 발생), 이 값을 수동으로 조금씩 줄여서 VRAM에 딱 맞게 조절할 수 있습니다.
Keep Alive:
- 기본값은 5분입니다. 메모리를 빨리 비우고 싶다면 5m 대신 1m이나 0(즉시 해제)으로 설정하세요. 다른 GPU 작업(게임 등)을 병행할 때 유용합니다.

3. RAG(문서 관리) 메모리 최적화

사용자님이 보신 vector_db 관련 설정입니다. Settings > Documents에서 수정합니다.

Embedding Model Engine: 기본 모델 대신 **Ollama**를 선택하고, **bge-m3:open-webui**나 all-minilm 같은 아주 가벼운 임베딩 모델을 사용하세요.
대형 모델을 임베딩용으로 쓰면 채팅용 모델과 VRAM을 나누어 써야 하므로 속도가 반토막 납니다.

4. 기타 하드웨어 팁

브라우저 하드웨어 가속: Open WebUI를 띄운 브라우저(크롬 등)도 GPU를 사용합니다. VRAM이 1GB 정도 모자란 상황이라면 브라우저의 '하드웨어 가속'을 끄는 것만으로도 모델이 GPU에 완벽히 올라갈 공간을 확보할 수 있습니다.
리눅스 환경 유지: 현재 사용 중인 Ubuntu 환경은 윈도우(WSL2)보다 GPU 메모리 오버헤드가 적어 8GB VRAM을 활용하기에 최적의 조건입니다.

추천 설정값 요약 (RTX 4060 기준)

항목	설정값	효과
Context Length	4096 ~ 8192	문맥 유지와 속도의 균형
Max Loaded Models	1	VRAM 중복 점유 방지
Flash Attention	Enabled	추론 속도 향상 및 메모리 절약
Keep Alive	5m (또는 필요시 0)	GPU 자원 반납 속도 조절

----

토큰(Token)

LLM(거대언어모델)에서 **토큰(Token)**은 모델이 텍스트를 이해하고 생성하는 최소 처리 단위

LLM(거대언어모델)에서 **토큰(Token)**은 모델이 텍스트를 이해하고 생성하는 최소 처리 단위입니다. 사람이 문장을 '단어'나 '글자'로 이해한다면, AI는 이를 '토큰'이라는 조각으로 나누어 처리합니다.

1. 토큰이 만들어지는 과정 (Tokenization)

컴퓨터는 텍스트를 직접 이해할 수 없기 때문에, 숫자로 변환하는 과정이 필요합니다. 이 과정을 **토크나이저(Tokenizer)**가 수행합니다.

영어: 대략 단어 1개 ≈ 0.75개~1개 토큰으로 계산됩니다. (예: "apple" → 1토큰)
한국어: 한글은 조사와 어미가 발달해 있어 영어보다 복잡합니다. 형태소 단위로 쪼개지거나, 글자당 1~3개의 토큰이 소모될 수 있습니다. (예: "먹었습니다" → "먹", "었", "습니다" 등으로 분리)
공백 및 기호: 띄어쓰기, 마침표, 줄바꿈 등도 모두 각각의 토큰으로 계산됩니다.

2. 왜 토큰이 중요한가요?

구분	설명
비용 계산	대부분의 AI API(OpenAI, Google Cloud 등)는 글자 수가 아니라 사용된 토큰 수를 기준으로 요금을 부과합니다.
기억력 제한	앞서 질문하신 '컨텍스트 윈도우'는 이 토큰의 최대 수용량을 의미합니다. 토큰 제한을 넘어가면 AI는 대화의 앞부분을 잊어버립니다.
처리 속도	토큰이 많을수록 AI가 계산해야 할 양이 늘어나 답변 속도가 느려질 수 있습니다.

3. 토큰을 아끼는 팁

불필요한 공백 제거: 의미 없는 빈 줄이나 중복된 공백도 토큰을 소모합니다.
직설적인 표현: 장황한 수식어보다는 명확하고 간결한 문장이 토큰 효율이 좋습니다.
한국어 최적화 모델 사용: 최근 출시된 모델(HyperCLOVA X, 최신 Gemini 등)은 한국어를 더 효율적으로 토큰화하여 같은 내용도 더 적은 토큰으로 처리합니다.

직접 확인해보기

사용 중인 문장이 몇 개의 토큰으로 구성되는지 궁금하다면 각 개발사가 제공하는 Tokenizer Tool을 사용해 볼 수 있습니다.

OpenAI Tokenizer: GPT 모델 기준 토큰 수 확인 가능
Google AI Studio: Gemini 모델의 프롬프트 입력창 하단에서 실시간 토큰 수 확인 가능

----

Conversation History

**대화 기록(Conversation History)**은 LLM이 사용자와 주고받은 이전 메시지들을 기억하여 문맥에 맞는 답변을 할 수 있게 해주는 핵심 장치입니다.

AI 모델 자체는 기본적으로 '상태가 없는(Stateless)' 상태입니다. 즉, 질문을 던질 때마다 모델은 이전 내용을 모두 잊어버린 채 새로 시작합니다. 우리가 연속적인 대화를 한다고 느끼는 이유는 서비스(ChatGPT, Gemini 등)가 이전 대화 내용을 매번 질문과 함께 모델에게 다시 전달해주기 때문입니다.

1. 대화 기록의 작동 원리

대화가 길어질 때 내부적으로는 다음과 같은 과정이 반복됩니다.

첫 번째 질문: 사용자: "안녕?" → 모델: "안녕하세요!"
두 번째 질문: 사용자: "오늘 날씨 어때?"
모델에게 전달되는 실제 데이터: > [이전 대화] 사용자: "안녕?" / 모델: "안녕하세요!"
[현재 질문] 사용자: "오늘 날씨 어때?"
결과: 모델은 이전 대화를 읽고 "아, 인사 다음에 날씨를 묻는구나"라고 파악하여 답변합니다.

2. 대화 기록 관리의 주요 개념

히스토리 버퍼 (History Buffer): 지금까지 나눈 대화 전체를 저장하는 공간입니다.
컨텍스트 윈도우 제한: 앞서 배운 것처럼 모델이 한 번에 처리할 수 있는 토큰 양은 정해져 있습니다. 대화가 너무 길어져서 이 제한을 넘어가면 가장 오래된 대화부터 삭제됩니다.
역할 분담 (Roles): 대화 기록 내에서 각각의 메시지는 누구의 것인지 구분됩니다.
- System: AI의 성격이나 규칙 설정 (예: "너는 친절한 수학 선생님이야.")
- User: 사용자가 입력한 메시지
- Assistant (AI): AI가 이전에 했던 답변

3. 효율적인 대화 기록 관리 기법 (개발 및 고급 활용)

대화가 무한정 길어질 수 없기 때문에, 효율적으로 기억을 관리하는 여러 전략이 사용됩니다.

기법	설명
Sliding Window	정해진 개수의 최근 메시지(예: 최신 10개)만 유지하고 나머지는 버림.
Summarization	이전 대화 내용을 AI가 스스로 요약하여 짧은 문장으로 압축해 기억함.
Vector DB (RAG)	아주 오래된 대화는 외부 저장소에 넣어두었다가, 관련 있는 내용이 나올 때만 다시 꺼내옴.

사용자가 체감하는 특징

지시 사항 누적: 대화 초반에 "앞으로 모든 답변은 존댓말로 해줘"라고 말하면, 대화 기록 덕분에 이후 대화에서도 그 규칙이 유지됩니다.
지칭어 이해: "그거 다시 설명해줘"라고 했을 때, '그거'가 무엇인지 이전 기록에서 찾아냅니다.

대화 기록이 너무 길어져서 AI의 답변 속도가 느려지거나 과거 내용을 자꾸 잊어버린다고 느껴지시나요? 그렇다면 대화를 새로 시작하거나 요약을 요청하는 것이 방법이 될 수 있습니다.

-----

Stateless

LLM(AI) 관점에서의 차이

우리가 사용하는 대부분의 LLM API는 본질적으로 Stateless입니다.

구분	LLM에서의 작동 방식
Stateless (모델 본체)	모델은 당신이 5분 전에 무엇을 물었는지 기억하지 못합니다. 모델 입장에서는 매 질문이 늘 '첫 질문'입니다.
Stateful (서비스 인터페이스)	ChatGPT 같은 서비스가 'Stateful'하게 느껴지는 이유는, 서비스가 내부적으로 대화 기록을 계속 덧붙여서(Stateless 모델에게) 다시 보내주기 때문입니다.

요약 비교

항목	Stateless (상태 비저장)	Stateful (상태 유지)
기억 여부	기억 안 함 (독립적)	기억함 (연속적)
데이터 전달	매번 전체 정보를 보냄	바뀐 부분이나 식별자만 보냄
확장성	매우 높음 (서버 교체 자유로움)	낮음 (기억을 가진 서버로 가야 함)
대표 예시	HTTP, DNS, REST API	TCP, 온라인 뱅킹, 게임 서버

----

summarization

요약(Summarization)**은 방대한 양의 정보를 핵심 내용 위주로 압축하는 기술입니다. LLM 시대에 들어서면서 요약은 단순히 길이를 줄이는 것을 넘어, 문맥의 의미를 파악해 재구성하는 수준으로 발전했습니다.

특히 앞서 대화했던 '컨텍스트 윈도우'와 '대화 기록' 문제를 해결하는 아주 강력한 도구이기도 합니다.

1. 요약의 두 가지 방식

AI가 요약을 수행하는 방식은 크게 두 가지로 나뉩니다.

추출적 요약 (Extractive Summarization): * 원문에서 가장 중요한 문장 몇 개를 그대로 뽑아내는 방식입니다.
- 장점: 원문 왜곡이 적고 정확합니다.
- 단점: 문장이 매끄럽지 않을 수 있습니다.
생성적 요약 (Abstractive Summarization): * 내용을 이해한 뒤 AI가 새로운 문장으로 재작성하는 방식입니다. (현재의 LLM 방식)
- 장점: 사람이 요약한 것처럼 자연스럽고 핵심 파악이 뛰어납니다.
- 단점: 원문에 없는 내용을 지어내는 '할루시네이션(환각)'이 발생할 수 있습니다.

2. 대화 기록 관리에서의 요약 전략

대화가 길어져 토큰 한도(Context Window)에 다다랐을 때, Stateful한 경험을 유지하기 위해 AI 시스템은 다음과 같은 전략을 씁니다.

전체 요약 (Full Summary): 지금까지의 모든 대화 내용을 한 단락의 요약본으로 바꿉니다. 그리고 새로운 질문을 던질 때 [요약본] + [새 질문] 형태로 모델에게 보냅니다.
증분 요약 (Incremental Summary): 대화가 추가될 때마다 기존 요약본에 새로운 내용을 조금씩 업데이트하며 크기를 일정하게 유지합니다.

3. 요약을 잘 시키는 방법 (Prompt Engineering)

LLM에게 요약을 시킬 때 더 좋은 결과를 얻으려면 기준을 명확히 주어야 합니다.

대상 지정: "이 회의록을 결정 사항 위주로 요약해줘."
길이 제한: "전체 내용을 3문장 이내 또는 200자 내외로 줄여줘."
형식 지정: "불렛 포인트(Bullet Points) 형식으로 정리해줘."
대상 독자 설정: "초등학생이 이해할 수 있을 정도로 쉽게 요약해줘."

4. 요약의 한계와 주의점

정보 손실: 압축 과정에서 세부 수치나 고유 명사가 생략될 수 있습니다.
편향성: AI가 중요하다고 판단한 기준이 사용자의 의도와 다를 수 있습니다.

---------------------------------

Auto-Compressors

"Auto-Compressors" 또는 **"Auto-Compaction"**에 대해 물어보신 것이 맞을까요?

컴퓨팅과 LLM 분야에서 이 용어들은 주로 **"데이터나 컨텍스트를 자동으로 압축하여 효율을 높이는 기술"**을 의미합니다. 앞서 우리가 이야기한 '토큰'과 '대화 기록' 관리의 연장선에 있는 개념입니다.

가장 관련 깊은 두 가지 관점에서 설명해 드릴게요.

1. LLM 컨텍스트 자동 압축 (Context Auto-Compression)

대화가 길어지면 토큰이 꽉 차서 비용이 비싸지고 속도가 느려집니다. 이를 해결하기 위해 시스템이 알아서 중요하지 않은 토큰을 쳐내거나 요약하는 기술입니다.

작동 방식: AI가 대화 내용 중 "안녕", "반가워" 같은 부가적인 부분은 삭제하고, **핵심 의미를 담은 토큰(Summary 또는 Soft Tokens)**만 남깁니다.
장점: 사용자는 대화 흐름이 끊긴다고 느끼지 않으면서도, 모델은 훨씬 적은 양의 데이터를 처리하므로 응답 속도가 빨라집니다.

2. 데이터베이스 자동 압축 (Auto-Compaction)

만약 벡터 데이터베이스(Vector DB)나 로그 시스템을 다루고 계신다면, 이 용어는 저장 공간 관리를 의미합니다.

작동 방식: 데이터가 수정되거나 삭제될 때 생기는 '빈 공간'들을 자동으로 정리하고, 흩어져 있는 데이터 조각들을 하나로 모으는 작업입니다.
비유: 책꽂이에서 책을 몇 권 뺐을 때 생긴 빈틈을 메우기 위해 남은 책들을 한쪽으로 밀어 정리하는 것과 같습니다.

왜 이 기술이 중요한가요?

LLM 서비스 운영자 입장에서는 비용 절감이 가장 큰 이유입니다.

토큰 절약: 불필요한 데이터를 자동으로 압축해서 보내면 API 호출 비용이 줄어듭니다.
성능 유지: 컨텍스트 윈도우가 가득 차서 발생하는 정보 유실(Forgetfulness) 현상을 방지합니다.

----------------------------

데이터를 최적화하는 기술

LM(거대언어모델) 환경에서 **Auto Compact(자동 압축)**는 주로 긴 대화나 방대한 데이터를 처리할 때, 제한된 컨텍스트 윈도우를 효율적으로 사용하기 위해 시스템이 스스로 데이터를 최적화하는 기술을 의미합니다.

주로 LlamaIndex나 LangChain 같은 LLM 프레임워크나 벡터 데이터베이스에서 이 용어를 사용합니다. 핵심적인 세 가지 측면에서 정리해 드릴게요.

1. 컨텍스트 자동 압축 (Context Auto-Compaction)

대화 기록이 길어지면 모델의 토큰 한도를 초과하게 됩니다. 이때 사용자가 수동으로 요약하지 않아도 시스템이 알아서 처리하는 방식입니다.

작동 원리: 대화 내용이 일정 토큰(예: 한도의 80%)에 도달하면, 시스템이 이전 대화들을 분석하여 중요하지 않은 수식어는 삭제하고 핵심 정보만 추출하여 새로운 '압축된 컨텍스트'로 재구성합니다.
효과: 대화의 맥락(State)은 유지하면서 사용 토큰 수는 획기적으로 줄여 비용을 아끼고 모델의 '망각' 현상을 방지합니다.

2. 검색 결과 자동 압축 (RAG Post-Processing)

RAG(검색 증강 생성) 시스템에서 외부 문서를 불러올 때, 문서 전체를 모델에게 주는 것이 아니라 필요한 부분만 압축해서 전달하는 과정입니다.

Selective Context: 검색된 문서들 중 질문과 관련성이 낮은 문장이나 중복되는 단어를 AI가 사전에 필터링합니다.
LongLLMLingua: Microsoft에서 발표한 기술로, 토큰 간의 정보 밀도를 계산하여 정보 가치가 낮은 토큰을 제거함으로써 컨텍스트를 최대 20배까지 압축하면서도 성능을 유지합니다.

3. 스토리지 자동 압축 (Storage Auto-Compaction)

LLM이 기억을 저장하는 Vector Database에서 발생하는 기술적 관리 프로세스입니다.

데이터 정리: 대화 기록이나 임베딩 데이터가 수정/삭제될 때 발생하는 파편화된 저장 공간을 자동으로 하나로 모으는 작업입니다.
인덱스 최적화: AI가 데이터를 더 빨리 찾을 수 있도록 데이터 구조를 주기적으로 재배치합니다.

요약: 왜 Auto Compact를 쓰나요?

특징	효과
비용 절감	불필요한 토큰 소비를 줄여 API 호출 비용을 낮춤.
성능 향상	모델이 핵심 정보에 더 집중하게 하여 답변의 정확도를 높임.
무한 대화	컨텍스트 한도에 구애받지 않고 매우 긴 대화를 이어갈 수 있음.

️ 구현 예시 (LlamaIndex 등)

만약 개발자라면, ContextChatEngine 같은 도구를 설정할 때 compact 옵션을 활성화하면 됩니다. 그러면 시스템은 매 질문마다 전체 히스토리를 보내는 대신, 토큰이 찰 때마다 자동으로 요약본으로 교체하며 대화를 이어갑니다.

gemini api chat session, summarization

사리생성 — Wed, 21 Jan 2026 23:30:38 +0900

chat session : 채팅 세션 : 컨테스트를 기역하게 하는 방식.

챗봇, 상담에이전트.

https://wikidocs.net/228933

https://wikidocs.net/232692

써머라이제이션 : 방대한 양의 정보를 핵심 위주로 압축하는 작업. 대화 흐름보다, 정보의 효율적인 전달에 초점.

- 긴문서, 영상 스크립트, 지난 채팅 기록 전체를 입력으로 넣고, 요약해줘 같은 프롬프트를 실행으로 컨텍스트 최적화.

Full Summarization

Incremental Summarization Update 증분 업데이트 요약.

구분	Chat Session	Summarization
목적	대화의 연속성 및 맥락 유지	정보의 핵심 내용 추출 및 압축
작동 원리	대화 이력을 누적하여 전달	전체 입력을 분석하여 짧은 결과 생성
사용자 경험	자연스러운 '대화' 가능	긴 정보를 빠르게 '파악' 가능
토큰 효율	대화가 길수록 토큰 사용량 증가	긴 데이터를 적은 토큰으로 변환
API 활용	start_chat(), send_message()	일반 generate_content() + 요약 프롬프트

함께 사용하면 좋은 팁: Context Caching

Gemini API는 매우 긴 컨텍스트(최대 200만 토큰 등)를 지원하지만, 매번 모든 대화 이력을 보내는 것은 비용이 많이 듭니다.

Chat Session이 너무 길어지면 Summarization을 통해 이전 대화를 요약하여 다시 세션을 시작하거나,
Context Caching 기능을 사용하여 자주 반복되는 배경 지식이나 긴 매뉴얼 데이터를 캐싱해 두면 비용과 응답 속도를 획기적으로 개선할 수 있습니다.

Gemini API 채팅 세션 가이드

이 영상은 Gemini API를 활용하여 대화 이력을 관리하고 채팅 세션을 구현하는 구체적인 방법을 설명하고 있어 이해에 도움이 될 것입니다.

https://youtu.be/GDyEVfsNDhU

실무 팁

만약 지금 React(프론트) + Django(백엔드) + Ollama/Gemini 구조로 캐릭터 챗 플랫폼을 개발 중이시라면, 다음과 같이 활용할 수 있습니다.

세계관/설정집: 양이 매우 많다면 Context Caching을 적용해 비용을 아낍니다.
최근 대화: Chat Session으로 실시간성을 유지합니다.
오래된 대화: Summarization을 통해 '기억'의 형태로 요약하여 컨텍스트 창 공간을 확보합니다.

ubuntu <-> mac 원격 접속

사리생성 — Tue, 20 Jan 2026 12:16:41 +0900

NoMachine

https://www.nomachine.com/download

비교 항목	NoMachine (추천)	Microsoft Remote Desktop	VNC (맥 기본)
반응 속도	매우 빠름 (60fps급)	보통	느림
GPU 활용	우수 (4060 직접 사용)	제한적 (가상 드라이버)	거의 불가
설정 난이도	쉬움 (앱 설치 끝)	보통 (Ubuntu 설정 필요)	어려움 (보안 설정 수정)
안정성	높음 (앱 실행 시 안 끊김)	낮음 (충돌 잦음)	보통

* Microsoft Remote Desktop 접속이 자주 끊어짐. (antigravity 실행만 하면 끊어짐)

리눅스 설치

# 1. 임시 폴더로 이동
cd /tmp

# 2. NoMachine 최신 패키지 다운로드 (2026년 기준 v9.x 또는 v8.x 최신 버전)
# ※ 아래 링크가 만료되었다면 NoMachine 홈페이지에서 최신 .deb 링크를 복사해 사용하세요.
wget https://download.nomachine.com/download/9.3/Linux/nomachine_9.3.7_1_amd64.deb

# 3. 패키지 설치
sudo dpkg -i nomachine_9.3.7_1_amd64.deb

# 4. (선택사항) 의존성 문제 해결
sudo apt install -f

맥북 클라이언트 설치.