728x90
반응형

 

 

"Ollama with granite3.2-vision is excellent for OCR and for processing text afterwards"

"Granite3.2-vision이 포함된 Ollama는 OCR 및 이후 텍스트 처리에 매우 적합합니다."

 

최근 Reddit에 올라온 Ollama granite3.2-vision 모델에 대한 글을 보고 granite 모델로 신분증에 대해서 OCR을 하면 얼마나 성능이나 정확성이 나올지 궁금해서 테스트를 해봤습니다.

 

결과를 말씀드리면 속도, 성능, 정확성이 매우 뛰어납니다. 몇가지 신분증을 샘플로 해보도록 하겠습니다.

 

granite3.2-vision
A compact and efficient vision-language model, specifically designed for visual document understanding, 

enabling automated content extraction from tables, charts, infographics, plots, diagrams, and more.

 

A compact and efficient vision-language model, specifically designed for visual document understanding, enabling automated content extraction from tables, charts, infographics, plots, diagrams, and more. The model was trained on a meticulously curated instruction-following dataset, comprising diverse public datasets and synthetic datasets tailored to support a wide range of document understanding and general image tasks. It was trained by fine-tuning a Granite large language model with both image and text modalities.

 

컴팩트하고 효율적인 vision-language 모델로, 특히 시각적 문서 이해를 위해 설계되었습니다. 이 모델은 표, 차트, 인포그래픽, 그래프, 다이어그램 등에서 자동으로 콘텐츠를 추출할 수 있도록 최적화되었습니다. 다양한 공개 데이터셋과 문서 이해 및 일반 이미지 작업을 지원하는 합성 데이터셋으로 구성된 세밀하게 선별된 instruction-following 데이터셋을 활용해 학습되었습니다. 이미지와 텍스트 모달리티를 모두 포함하여 Granite 대형 언어 모델을 미세 조정(fine-tuning)하는 방식으로 훈련되었습니다.

 

참고

Hugging Face

 

모델사이즈는 2B로 다운로드 받으면 2.4GB로 llama3.2-vision의 7.9GB에 비해서도 작은 사이즈입니다.

% ollama list
NAME                        ID              SIZE      MODIFIED
granite3.2-vision:latest    3be41a661804    2.4 GB    About a minute ago
llama3.2-vision:latest      085a1fdae525    7.9 GB    5 days ago

 

Jupyter 노트북으로 샘플을 만들어보겠습니다.

 

사용한 샘플 사진은 구글에서 검색한 필리핀 Driver license 샘플이미지입니다.

테스트 이미지

 

 

import ollama
import time
from IPython.display import Image, Markdown, display

def Talk_with_granite_3_2_vision(user_query, input_image):
    start_time = time.time()  # Start timer
    response = ollama.chat(
    model='granite3.2-vision:latest',
    messages=[{
        'role': 'user',
        'content': user_query,
        'images': [input_image]
        }]
    )
    end_time = time.time()  # End timer
    # Calculate elapsed time
    execution_time = end_time - start_time
    #print(f"Response: {response['message']['content']}")
    print(f"Response: {response}")
    print(f"Execution time: {execution_time:.2f} seconds")
    
    return response

 

display(Image(filename="driver_license.jpeg"))

image display

 

Talk_with_granite_3_2_vision('Describe the content of the given image','driver_license.jpeg')

 

문서 안에 Text를 비롯해서 문의의 설명까지 상세하게 가져온걸 확인할수있습니다.

 

Response: model='granite3.2-vision:latest' created_at='2025-03-15T01:30:57.858356Z' done=True done_reason='stop' total_duration=80162497333 load_duration=46421333 prompt_eval_count=5157 prompt_eval_duration=972000000 eval_count=808 eval_duration=79134000000 message=Message(role='assistant', content='\nThe image depicts a Philippine driver\'s license issued by the Department of Transportation Land Transportation Office (DOTLTO). This document is specifically labeled as a "Non-Professional Driver’s License." The front cover of the license features several key elements:\n\n1. **Country and Issuing Authority**: At the top, there is a flag of the Philippines, indicating that this is an official government document from the Philippines. Below the flag, it reads "REPUBLIC OF THE PHILIPPINES" followed by "DEPARTMENT OF TRANSPORTATION LAND TRANSPORTATION OFFICE."\n\n2. **License Type**: The title of the document is prominently displayed as "NON-PROFESSIONAL DRIVER’S LICENSE," which specifies that this license is intended for individuals who are not professionally licensed to drive but rather hold a provisional or temporary driver\'s license.\n\n3. **Personal Information**:\n   - **Last Name**: DELA CRUZ\n   - **First Name**: JUAN PEDRO GARCIA\n   - **Nationality**: PHIL\n   - **Sex**: M (Male)\n   - **Date of Birth**: 1987/10/04\n   - **Height (in meters)**: 1.55\n   - **Weight (in kilograms)**: 70\n\n4. **Identification Number**: The license number is "N03-12-123456."\n\n5. **Address**: The address listed on the license is "AUTODEAL UNIT/HOUSE NO. BUILDING, STREET NAME: BARANGAY, CITY/MUNICIPALITY," which indicates that the holder of this license resides in Barangay, City/Municipality.\n\n6. **License Expiration Date**: The expiration date is "2022/10/04."\n\n7. **Restrictions and Conditions**: There are two restrictions listed:\n   - Restrictions 1.2\n   - Conditions NONE\n\n8. **Signature of Licensee**: At the bottom, there is a signature of the licensee, which reads "EDGAR C. SALVANTE," followed by his designation as "Assistant Secretary."\n\n9. **Seal and Logo**: The top right corner features a seal with the text "DOTLTO" inside it, indicating that this document is an official government-issued license.\n\n### Analysis:\nThis non-professional driver\'s license serves as proof of identity for individuals who are not professionally licensed to drive but hold a provisional or temporary license. The details provided on the license include personal information such as name, date of birth, height, weight, and address, which are essential for identification purposes. The expiration date ensures that the license remains valid for a specified period, after which it must be renewed or replaced.\n\nThe restrictions listed (Restrictions 1.2) and conditions (NONE) indicate specific rules or regulations that the holder of this license must adhere to. These could include age limits, vehicle type restrictions, or other legal requirements pertinent to driving in the Philippines. The signature of the Assistant Secretary verifies the authenticity of the document and confirms that it was issued by a legitimate authority within the Department of Transportation Land Transportation Office.\n\n### Conclusion:\nThis non-professional driver\'s license is an essential document for individuals in the Philippines who are not professionally licensed to drive but hold a provisional or temporary license. It contains all necessary personal and identification details, as well as restrictions and conditions that must be followed by the holder. The signature of the Assistant Secretary adds an additional layer of authenticity to the document.', images=None, tool_calls=None)
Execution time: 80.19 seconds

 

asitop 실행모니터링

 

그럼 사용자 쿼리를 조정해서 OCR로 추출한 text들을 필요한 항목들만 가져도록 조정해보겠습니다.

 

신분증 이미지를 보면 아래 항목들이 포함되어 있습니다. 제가 필요한것은 각 항목에 맞는 데이터를 추출하는것입니다

- License Type

- Last Name, First Name, Middle Name
- Nationality
- Sex
- Date of Birth
- Weight (in kg)
- Height (in m)
- Address
- License Number
- Expiration Date
- Agency Code
- Blood Type
- Eyes Color
- Restrictions
- Conditions

 

먼저  user_query 를 다음과 같이 지정해서 실행해보게습니다. 'OCR the text of the image. What is license type?'

user_query = 'OCR the text of the image. What is license type?'

response = Talk_with_granite_3_2_vision(user_query,'driver_license.jpeg')

 

Response: model='granite3.2-vision:latest' created_at='2025-03-15T01:51:00.248422Z' done=True done_reason='stop' total_duration=72551407958 load_duration=1374949917 prompt_eval_count=5162 prompt_eval_duration=66223000000 eval_count=54 eval_duration=4948000000 message=Message(role='assistant', content='\nThe license type indicated on the driver\'s license in the image is a "NON-PROFESSIONAL DRIVER\'S LICENSE." This is clearly stated at the top of the document, just below the Philippine flag and above the personal details section.', images=None, tool_calls=None)
Execution time: 72.57 seconds

 

응답으로 "NON-PROFESSIONAL DRIVER\'S LICENSE." 라고 알려줍니다.  

 

출력결과를 아래 원본이미지와 비교해보면서 필요한 필요한 항목들을 OCR한 결과와 매핑해보면 다음과 같습니다.

"License": "NON-PROFESSIONAL DRIVER'S LICENSE",
"name": "DELA CRUZ, JUAN PEDRO GARCIA",
"sex": "M",
"dateOfBirth": "1987/10/04",
"weight": "70",
"height": "1.55",
"address": "AUTODEAL UNIT/HOUSE NO. BUILDING, STREET NAME, BARANGAY, CITY/MUNICIPALITY",
"nationality": "PHL",
"licenseNumber": "N03-12-123456",
"expirationDate": "2022/10/04",
"agencyCode": "N32",
"bloodType": "O+",
"eyesColor": "BLACK",
"Restrictions": "1,2",
"conditions": "NONE"

 

 

와우 역시 좋네요.!!

 

728x90
반응형
728x90
반응형

https://www.ibm.com/kr-ko/new/announcements/ibm-granite-3-2-open-source-reasoning-and-vision

 

IBM Granite 3.2: 오픈 소스 추론 및 비전

추론 기능이 강화된 Granite 3.2 Instruct 모델과 멀티모달 Granite Vision 3.2를 중심으로 한 IBM Granite 3.2는 몇 가지 새로운 엔터프라이즈 기능을 도입했습니다.

www.ibm.com

 

Granite Vision 3.2 2B는 일상적인 기업 사용 사례를 대상으로 하는 컴퓨팅 비전 기능을 갖춘 경량형 대규모 언어 모델로, 특히 시각적 문서 이해에 중점을 두고 학습되었습니다. 이미지 및 텍스트 입력을 모두 처리하는 Granite Vision 3.2의 성능은 DocVQA, ChartQA와 같은 필수 엔터프라이즈 벤치마크에서 훨씬 더 큰 개방형 모델의 성능과 비슷합니다.

문서 이해 작업의 성능을 측정하는 벤치마크에서 Granite Vision 3.2는 훨씬 더 큰 개방형 모델과 어깨를 나란히 합니다.

Granite Vision 3.2 2B는 언어 작업에서 비슷한 크기의 텍스트 전용 Granite 모델을 즉시 대체하기 위한 것은 아니지만, 텍스트 입력, 텍스트 출력 시나리오를 유능하게 처리할 수 있습니다.

엔터프라이즈 이미지의 시각을 위한 비전

Granite Vision 3.2 2B는 다양한 시각적 이해 작업을 처리할 수 있지만, 문서 이해 및 멀티모달 검색 증강 생성(RAG)과 가장 관련성이 높은 작업에 특화되어 있습니다.

Granite 3.2 2B Vision Demo (1:20 min)

멀티모달 대규모 언어 모델(MLLM)이라고도 부르는 대부분의 VLM은 주로 자연 이미지에 대한 비전 작업을 위해 학습됩니다. 레이아웃, 글꼴, 차트, 인포그래픽 등 고유한 시각적 특성이 자연 이미지와 크게 다른 문서 이미지에서는 최적의 성능을 발휘하지 못합니다. 대부분의 일반화된 이미지인, 텍스트아웃 사용 사례와 비교하여, 문서 이해에는 시각적 맥락에 대한 보다 구체적이고 세분화된 이해를 필요로 합니다.

MLLM이 문서 및 관련 시각 자료를 효과적으로 처리할 수 있도록 하는 데 있어 두 가지 주요 과제는 고해상도 이미지를 적절하게 인코딩하고 해당 문서 내에서 시각적으로 배치된 텍스트를 정확하게 해석하는 것입니다. 전문화된 접근 방식은 일반적으로 외부 광학 문자 인식(OCR) 시스템에 의존하여 '인식 후 이해' 프레임워크에서 이미지 내의 텍스트를 처리하거나, 문서 이해만을 위해 설계된 맞춤형 모델 아키텍처를 사용합니다.

두 가지 접근 방식 모두 단점이 있습니다. 외부 OCR 기반 문서 이해에 의존하면 필수 정보가 언어에 도달하기 전에 오류가 누적될 수 있으며, 많은 전용 'OCR 프리' 방식은 고해상도 입력을 처리하는 데 어려움을 겪거나 경쟁 LLM에 비해 전반적인 지식 부족으로 어려움을 겪습니다.2

최근에는 문서 중심 데이터 세트에서 일반화된 비전 언어 모델을 명령 조정하여 문서 이해에서 강력한 성능을 달성했습니다. 안타깝게도, 이 접근 방식의 진전은 적절한 오픈 소스 데이터 세트의 부족으로 인해 다소 제한되었습니다. 이 접근 방식을 더욱 발전시키기 위해 IBM의 Granite Vision 3.2 개발에는 시각적 문서 이해를 위한 포괄적인 명령 준수 데이터 세트에 대한 광범위한 작업이 포함되었습니다.

DocFM: 엔터프라이즈 비전 작업을 위한 명령 조정 데이터 세트

DocFM 데이터 세트는 신중하게 선별된 엔터프라이즈 데이터를 기반으로 구축된 비전 작업을 위한 대규모 명령 조정 데이터 세트입니다. 문서 이해 데이터 세트 수집에 사용된 데이터 소스, 초기 수집을 처리하는 데 사용된 필터링 및 정리 방법, 이후 Granite Vision에 대한 학습 작업을 합성적으로 생성하는 데 사용되는 방법론에 대한 광범위한 세부 정보가 함께 제공되는 기술 백서에 나와 있습니다.

Granite Vision을 학습시키는 데 사용되는 문서 이해 데이터는 일반 문서 이미지, 차트, 순서도 및 다이어그램의 범주와 함께 다양한 문서 클래스를 다룹니다. 명령 준수 데이터 세트는 문서 질문 답변, 장면 텍스트 이해, 키-값 추출, 텍스트 그라운딩, 레이아웃 구문 분석, 캡션, UI 이해 및 코드를 포함한 다양한 작업에 걸쳐 있습니다.

왼쪽: 문서 이해 학습 데이터 소스, 오른쪽: 일반 이미지 데이터에 사용되는 데이터 세트

DocFM은 IBM이 향후 다양한 다운스트림 시각 학습 활동에 사용되는 매우 큰 데이터 세트입니다. Granite Vision의 학습은 DocFM의 하위 집합을 사용하여 일련의 합성 시각적 질문-답변 데이터 세트를 생성했습니다. 기술 문서 부록의 표 5에는 Granite Vision에 사용된 문서 이해 데이터 세트에 대한 포괄적인 개요가 나와 있습니다.

내재적 안전 모니터링을 위한 희소 어텐션 벡터

Granite 3.2 Vision의 설계 및 학습에서 IBM은 유해한 활동을 모니터링하기 위해 외부 가드레일 모델에 의존하는 대신 Granite 모델 자체에 직접 통합하는 새로운 테스트 시간 기술도 도입했습니다.

핵심 인사이트는 Granite Vision의 많은 어텐션 헤드와 트랜스포머 계층 내에 안전 모니터링 작업이 분류 문제로 공식화될 때 안전 문제를 식별하는 데 유용할 수 있는 이미지 기능의 희소한 하위 집합이 있다는 것입니다.

Granite Vision 기술 문서에 자세히 설명되어 있는 프로세스에서 IBM Research는 Granite Vision의 어텐션 메커니즘 내에서 생성된 어텐션 벡터를 분리하고 검사하여 평균적으로 특정 부류의 유해 입력과 안정적으로 상관관계가 있는 어텐션 벡터를 평가하는 프로세스를 설계했습니다. 일단 식별되면, 이러한 '안전 벡터'를 생성하는 어텐션 헤드를 사용하여 주어진 입력이 안전한지 여부를 판단할 수 있습니다.

 

 

https://github.com/ibm-granite/granite-vision-models

 

GitHub - ibm-granite/granite-vision-models

Contribute to ibm-granite/granite-vision-models development by creating an account on GitHub.

github.com

 

https://arxiv.org/html/2502.09927v1

 

Granite Vision: a lightweight, open-source multimodal model for enterprise Intelligence

Authors (alphabetical order): Granite Vision Technical Leadership: Assaf Arbelle, Leonid Karlinsky, Peter Staar, Rogerio Feris, Tal Drory Project Management: Abraham Daniels Core Contributors: Ahmed Nassar, Amit Alfassi, Bo Wu, Eli Schwartz, Dhiraj Joshi,

arxiv.org

그림 1: Granite Vision이 생성한 정성적 사례

 

(a) 영수증 계산과 같은 문서 이해

(b) 사람이 직접 쓴 텍스트를 통한 양식 이해

(c) 지식 기반 이미지 설명

(d) 표 이해

 

등 다양한 기능이 포함됩니다.

 

참고 샘플

https://er-vishalanand.medium.com/ibms-granite-3-2-vision-model-a9f701bde847

 

IBM’s Granite 3.2 Vision Model

on NVIDIA with open-source UI for AI.

er-vishalanand.medium.com

 

기사

https://www.datanet.co.kr/news/articleView.html?idxno=200088

 

IBM, 기업 전용 LLM 모델 ‘그래니트 3.2’ 출시 - 데이터넷

[데이터넷] IBM은 거대언어모델(LLM) 제품군의 차세대 버전인 그래니트(Granite) 3.2를 출시했다고 27일 밝혔다.그래니트 3.2 모델은 허깅 페이스(Hugging Face)에서 허용되는 아파치 2.0 라이선스에 따라

www.datanet.co.kr

 

728x90
반응형
728x90
반응형

DeepFace

 

DeepFace는 파이썬을 위한 가벼운 얼굴 인식 및 얼굴 속성 분석( 나이 , 성별 , 감정  인종 ) 프레임워크입니다. 최첨단 모델을 래핑하는 하이브리드 얼굴 인식 프레임워크입니다 : 

VGG-Face, FaceNet, OpenFace, DeepFace, DeepID, ArcFace, Dlib, SFace, GhostFaceNet, Buffalo_L.

Experiments 인간의 얼굴 인식 작업 정확도는 97.53%인 반면, 해당 모델은 이미 이 정확도 수준에 도달하여 이를 넘어섰습니다 .

설치

deepface를 설치하는 가장 쉬운 방법은 PyPI에서 다운로드하는 것입니다 . 라이브러리 자체와 필수 구성 요소도 설치됩니다.

$ pip install deepface

 

또는 소스 코드에서 deepface를 설치할 수도 있습니다. 소스 코드에는 아직 pip 릴리스에 공개되지 않은 새로운 기능이 있을 수 있습니다.

$ git clone https://github.com/serengil/deepface.git
$ cd deepface
$ pip install -e .

 

라이브러리를 설치한 후에는 라이브러리를 가져와서 해당 기능을 사용할 수 있습니다.

from deepface import DeepFace

 

현대 얼굴 인식 파이프라인 - Demo

최신 얼굴 인식 파이프라인은 detect , align , normalize , representation , verify 라는 5가지 일반적인 단계로 구성됩니다. 

DeepFace는 이러한 모든 일반적인 단계를 백그라운드에서 처리하지만, 그 뒤에 있는 모든 프로세스에 대한 심층적인 지식을 습득할 필요는 없습니다. 한 줄의 코드로 verification, find 또는 analysis 함수를 호출하기만 하면 됩니다.

 

얼굴 확인 - Demo

이 함수는 얼굴 쌍을 같은 사람인지 다른 사람인지 확인합니다. 정확한 이미지 경로를 입력으로 기대합니다. numpy 또는 base64로 인코딩된 이미지를 전달하는 것도 환영합니다. 그런 다음 사전을 반환하고 검증된 키만 확인해야 합니다.

result = DeepFace.verify(img1_path = "img1.jpg", img2_path = "img2.jpg")

얼굴 인식 - Demo

얼굴 인식은 얼굴 검증을 여러 번 적용해야 합니다. 여기서 deepface는 이 작업을 처리하기 위한 기본 find 함수를 가지고 있습니다. 데이터베이스 경로에서 입력 이미지의 신원을 찾고 출력으로 pandas 데이터 프레임 목록을 반환합니다. 한편, 얼굴 데이터베이스의 얼굴 임베딩은 다음에 더 빠르게 검색할 수 있도록 pickle 파일에 저장됩니다. 결과는 소스 이미지에 나타나는 얼굴의 크기가 됩니다. 게다가, 데이터베이스의 대상 이미지에도 여러 얼굴이 있을 수 있습니다.

dfs = DeepFace.find(img_path = "img1.jpg", db_path = "C:/my_db")
 

임베딩 - Demo

 

얼굴 인식 모델은 기본적으로 얼굴 이미지를 다차원 벡터로 표현합니다. 때로는 이러한 임베딩 벡터가 직접 필요합니다. DeepFace에는 전용 표현 함수가 제공됩니다. Represent 함수는 임베딩 목록을 반환합니다. 결과는 이미지 경로에 나타나는 얼굴의 크기가 됩니다.

embedding_objs = DeepFace.represent(img_path = "img.jpg")

 

 

임베딩은 아래와 같이 플로팅 할 수 있습니다 . 각 슬롯은 차원 값에 해당하며 차원 값은 색상으로 강조됩니다. 2D 바코드와 유사하게 수직 차원은 일러스트레이션에 정보를 저장하지 않습니다.

얼굴 인식 모델 - Demo

 

DeepFace는 하이브리드 얼굴 인식 패키지입니다. 현재 최첨단(state-of-the-art) 얼굴 인식 모델인 : VGG-Face, FaceNet,  OpenFace, DeepFace, DeepID, ArcFace, Dlib, SFace,  GhostFaceNet, Buffalo_L을 많이 래핑합니다 . 기본 구성은 VGG-Face 모델을 사용합니다.

models = [
    "VGG-Face", "Facenet", "Facenet512", "OpenFace", "DeepFace",
    "DeepID", "ArcFace", "Dlib", "SFace", "GhostFaceNet",
    "Buffalo_L",
]

result = DeepFace.verify(
  img1_path = "img1.jpg", img2_path = "img2.jpg", model_name = models[0]
)

dfs = DeepFace.find(
  img_path = "img1.jpg", db_path = "C:/my_db", model_name = models[1]
)

embeddings = DeepFace.represent(
  img_path = "img.jpg", model_name = models[2]
)

 

FaceNet, VGG-Face, ArcFace 및 Dlib는 실험에 근거하여 성능이 뛰어난 모델입니다. BENCHMARKS자세한 내용은 를 참조하십시오. DeepFace의 다양한 모델에 대한 측정 점수와 원래 연구에서 보고된 점수는 다음 표에서 찾을 수 있습니다.

모델측정된 점수선언된 점수

Model Measured Score Declared Score
Facenet512 98.4% 99.6%
Human-beings 97.5% 97.5%
Facenet 97.4% 99.2%
Dlib 96.8% 99.3 %
VGG-Face 96.7% 98.9%
ArcFace 96.7% 99.5%
GhostFaceNet 93.3% 99.7%
SFace 93.0% 99.5%
OpenFace 78.7% 92.9%
DeepFace 69.0% 97.3%
DeepID 66.5% 97.4%

 

DeepFace 내에서 이러한 모델로 실험을 수행하면 고유한 탐지 또는 정규화 기술을 채택했기 때문에 원래 연구와 비교하여 차이가 드러날 수 있습니다. 게다가 일부 모델은 사전 훈련된 가중치가 없는 백본만 가지고 출시되었습니다. 따라서 우리는 원래 사전 훈련된 가중치 대신 재구현을 활용하고 있습니다.

 

유사성 - Demo

 

얼굴 인식 모델은 일반적인 합성 신경망 이며 얼굴을 벡터로 표현하는 역할을 합니다. 우리는 같은 사람의 얼굴 쌍이 다른 사람의 얼굴 쌍보다 더 유사 할 것으로 예상합니다.

유사도는 코사인 유사도 , 유클리드 거리 또는 L2 정규화된 유클리드 와 같은 다양한 지표로 계산할 수 있습니다 . 기본 구성은 코사인 유사도를 사용합니다. 실험 에 따르면 , 어떤 거리 지표도 다른 것보다 성능이 뛰어나지 않습니다.

metrics = ["cosine", "euclidean", "euclidean_l2"]

result = DeepFace.verify(
  img1_path = "img1.jpg", img2_path = "img2.jpg", distance_metric = metrics[1]
)

dfs = DeepFace.find(
  img_path = "img1.jpg", db_path = "C:/my_db", distance_metric = metrics[2]
)

 

 

얼굴 속성 분석 - Demo

 

DeepFace에는 또한 age, gender, facial expression(화남, 두려움, 중립, 슬픔, 혐오, 행복, 놀람 포함) 및 race(아시아인, 백인, 중동인, 인도인, 라틴계, 흑인 포함) 예측을 포함한 강력한 얼굴 속성 분석 모듈이 함께 제공됩니다. 결과는 소스 이미지에 나타나는 얼굴의 크기가 됩니다.

objs = DeepFace.analyze(
  img_path = "img4.jpg", actions = ['age', 'gender', 'race', 'emotion']
)

튜토리얼 에 언급된 대로 연령 모델은 ± 4.65 MAE를 얻었고, 성별 모델은 97.44%의 정확도, 96.29%의 정밀도, 95.05%의 재현율을 얻었습니다 .

 

얼굴 감지 및 정렬 - Demo

 

얼굴 감지 및 정렬은 현대 얼굴 인식 파이프라인의 중요한 초기 단계입니다. 실험에 따르면 감지는 얼굴 인식 정확도를 최대 42%까지 높이고 정렬은 최대 6%까지 높입니다. OpenCV, Ssd, Dlib, MtCnn, Faster MtCnn, RetinaFace, MediaPipe, Yolo, 감지기 YuNet는 CenterFacedeepface에 래핑됩니다.

모든 deepface 함수는 선택적 감지기 백엔드와 정렬 입력 인수를 허용합니다. 이러한 인수를 사용하여 감지기와 정렬 모드 사이를 전환할 수 있습니다. OpenCV가 기본 감지기이고 정렬은 기본적으로 켜져 있습니다.

backends = [
    'opencv', 'ssd', 'dlib', 'mtcnn', 'fastmtcnn',
    'retinaface', 'mediapipe', 'yolov8', 'yolov11s',
    'yolov11n', 'yolov11m', 'yunet', 'centerface',
]
detector = backends[3]
align = True

obj = DeepFace.verify(
  img1_path = "img1.jpg", img2_path = "img2.jpg", detector_backend = detector, align = align
)

dfs = DeepFace.find(
  img_path = "img.jpg", db_path = "my_db", detector_backend = detector, align = align
)

embedding_objs = DeepFace.represent(
  img_path = "img.jpg", detector_backend = detector, align = align
)

demographies = DeepFace.analyze(
  img_path = "img4.jpg", detector_backend = detector, align = align
)

face_objs = DeepFace.extract_faces(
  img_path = "img.jpg", detector_backend = detector, align = align
)

 

 

얼굴 인식 모델은 실제로 CNN 모델이며 표준 크기의 입력을 기대합니다. 따라서 표현하기 전에 크기 조정이 필요합니다. 변형을 피하기 위해 deepface는 감지 및 정렬 후 대상 크기 인수에 따라 검은색 패딩 픽셀을 추가합니다.

RetinaFace  MtCnn은 감지 및 정렬 단계에서 성능이 뛰어난 것으로 보이지만 훨씬 느립니다. 파이프라인 속도가 더 중요하다면 opencv나 ssd를 사용해야 합니다. 반면 정확도를 고려한다면 retinaface나 mtcnn을 사용해야 합니다.

다음 그림에서 볼 수 있듯이 RetinaFace의 성능은 군중 속에서도 매우 만족스럽습니다. 게다가 놀라운 얼굴 랜드마크 감지 성능이 함께 제공됩니다. 강조된 빨간색 점은 눈, 코, 입과 같은 얼굴 랜드마크를 보여줍니다. 그래서 RetinaFace의 정렬 점수도 높습니다.

옐로우 엔젤스 - 페네르바흐체 여자 배구 팀

 

RetinaFace에 대해 더 자세히 알아보려면 이 저장소를 방문하세요 .

 

실시간 분석 - Demo,  React Demo part-i, React Demo part-ii

 

실시간 비디오에도 deepface를 실행할 수 있습니다. 스트림 기능은 웹캠에 액세스하여 얼굴 인식과 얼굴 속성 분석을 모두 적용합니다. 이 기능은 얼굴에 5프레임 연속으로 초점을 맞출 수 있는 경우 프레임을 분석하기 시작합니다. 그런 다음 5초 동안 결과를 보여줍니다.

DeepFace.stream(db_path = "C:/database")

얼굴 인식은 원샷 학습에 기반을 두고 있지만, 한 사람의 얼굴 사진을 여러 장 사용할 수도 있습니다. 아래 그림과 같이 디렉토리 구조를 재정렬해야 합니다.

user
├── database
│   ├── Alice
│   │   ├── Alice1.jpg
│   │   ├── Alice2.jpg
│   ├── Bob
│   │   ├── Bob.jpg

 

 

브라우저에서 직접 얼굴 확인이나 분석 작업을 수행하려는 경우, deepface-react-ui deepface api에 따라 ReactJS를 사용하여 구축된 별도의 저장소가 있습니다.

 

얼굴 안티 스푸핑 - Demo

 

DeepFace에는 또한 주어진 이미지가 진짜인지 가짜인지 이해하기 위한 안티 스푸핑 분석 모듈이 포함되어 있습니다. 이 기능을 활성화하려면 anti_spoofingDeepFace 작업에서 인수를 True로 설정합니다.

 

# anti spoofing test in face detection
face_objs = DeepFace.extract_faces(img_path="dataset/img1.jpg", anti_spoofing = True)
assert all(face_obj["is_real"] is True for face_obj in face_objs)

# anti spoofing test in real time analysis
DeepFace.stream(db_path = "C:/database", anti_spoofing = True)

 

 

API - Demo,Docker Demo

 

DeepFace는 API도 제공합니다 api folder. 자세한 내용은 를 참조하세요. deepface 소스 코드를 복제하고 다음 명령으로 API를 실행할 수 있습니다. 이 명령은 gunicorn 서버를 사용하여 REST 서비스를 시작합니다. 이런 식으로 모바일 앱이나 웹과 같은 외부 시스템에서 deepface를 호출할 수 있습니다.

cd script

# run the service directly
./service.sh

# run the service via docker
./dockerize.sh

API에는 얼굴 인식, 얼굴 속성 분석 및 벡터 표현 기능이 포함되어 있습니다. 이러한 기능은 http post 메서드로 호출해야 합니다. 기본 서비스 엔드포인트는 http://localhost:5005/verify는 얼굴 인식, http://localhost:5005/analyze는 얼굴 속성 분석 및 http://localhost:5005/represent 는 벡터 표현을 위한 것입니다. API는 파일 업로드(양식 데이터를 통해) 또는 정확한 이미지 경로, URL 또는 base64 인코딩된 문자열(JSON 또는 양식 데이터를 통해)로 이미지를 허용하여 다양한 클라이언트 요구 사항에 대한 다양한 옵션을 제공합니다. 여기에서 이러한 메서드를 호출하는 방법을 알아보려면 postman 프로젝트를 찾을 수 있습니다.

 

대규모 얼굴 인식 - Playlist

 

Vector Similarity Search for Machine Learning

Embark on an enlightening journey into the realm of vector search with our meticulously curated YouTube playlist. Delve into the intricacies of approximate n...

www.youtube.com

 

작업에 대규모 데이터 세트에서 얼굴 인식이 필요한 경우 DeepFace를 벡터 인덱스 또는 벡터 데이터베이스와 결합해야 합니다. 이 설정은 정확한 검색 대신 근사적 최근접 이웃 검색을 수행하여 밀리초 내에 수십억 개의 항목이 포함된 데이터베이스에서 얼굴을 식별할 수 있습니다. 일반적인 벡터 인덱스 솔루션에는 Annoy , Faiss , Voyager , NMSLIB , ElasticSearch 가 있습니다 . 벡터 데이터베이스의 경우 인기 있는 옵션은 pgvector 확장 기능이 있는 Postgres  RediSearch 입니다 .

반대로, 작업에 중소 규모 데이터베이스에서의 얼굴 인식이 포함된다면 Postgres , SQLite 와 같은 관계형 데이터베이스 나 Mongo , Redis , Cassandra 와 같은 NoSQL 데이터베이스를 사용하여 정확한 최근접 이웃 검색을 수행할 수 있습니다.

임베딩 암호화 - Demo with PHE, Tutorial for PHE, Demo with FHE,Tutorial for FHE

벡터 임베딩은 원본 이미지로 되돌릴 수 없지만 지문과 같은 민감한 정보가 여전히 포함되어 있어 보안이 중요합니다. 임베딩을 암호화하는 것은 민감한 정보를 조작하거나 추출할 수 있는 적대적 공격을 방지하기 위해 보안 수준이 높은 애플리케이션에 필수적입니다. AES와 같은 기존 암호화 방법은 매우 안전하지만 거리 계산을 위해 클라우드 컴퓨팅 파워를 안전하게 활용하는 데 제한이 있습니다. 여기서 암호화된 데이터에 대한 계산을 허용하는 동형 암호화는 강력한 대안을 제공합니다.

from lightphe import LightPHE

# build an additively homomorphic cryptosystem (e.g. Paillier) on-prem
cs = LightPHE(algorithm_name = "Paillier", precision = 19)

# define plain vectors for source and target
alpha = DeepFace.represent("img1.jpg")[0]["embedding"]
beta = DeepFace.represent("target.jpg")[0]["embedding"]

# encrypt source embedding on-prem - private key not required
encrypted_alpha = cs.encrypt(alpha)

# dot product of encrypted & plain embedding in cloud - private key not required
encrypted_cosine_similarity = encrypted_alpha @ beta

# decrypt similarity on-prem - private key required
calculated_similarity = cs.decrypt(encrypted_cosine_similarity)[0]

# verification
print("same person" if calculated_similarity >= 1 - threshold else "different persons")

# proof of work
assert abs(calculated_similarity - sum(x * y for x, y in zip(alpha, beta))) < 1e-2

 

 

이 방식에서는 클라우드의 계산 능력을 활용하여 암호화된 코사인 유사도를 계산합니다. 그러나 클라우드는 수행하는 실제 계산에 대해 전혀 알지 못합니다. 이것이 바로 동형 암호화의 마법 입니다 ! 온프레미스 측의 비밀 키 보유자만 암호화된 코사인 유사도를 해독하고 쌍이 같은 사람을 나타내는지 다른 개인을 나타내는지 확인할 수 있습니다. LightPHE라이브러리를 확인하여 부분 동형 암호화에 대해 자세히 알아보세요.

Contribution

풀 리퀘스트는 언제나 환영합니다! 대규모 패치를 기여할 계획이라면, 먼저 이슈를 생성하여 사전 질문이나 디자인 결정을 먼저 해결하세요.

PR을 만들기 전에 명령을 실행하여 로컬에서 단위 테스트와 린팅을 실행해야 합니다 make test && make lint. PR이 전송되면 GitHub 테스트 워크플로가 자동으로 실행되고 단위 테스트 및 린팅 작업은 승인 전에 GitHub 작업 에서 사용할 수 있습니다.

Support

프로젝트를 지원하는 방법은 여러 가지가 있습니다. GitHub 저장소를 starring⭐️하는 것은 그 중 하나입니다 🙏

이 작업이 마음에 든다면 Patreon , GitHub Sponsors 또는 Buy Me a Coffee 에서 재정적으로 지원할 수 있습니다 . 또한, 골드, 실버 또는 브론즈 티어의 스폰서가 되면 회사 로고가 GitHub의 README에 표시됩니다.

Citation

연구에 도움이 된다면 출판물에서 deepface를 인용해 주세요.

 

S. Serengil 및 A. Ozpinar, "얼굴 인식 파이프라인의 벤치마크 및 모듈의 공동 사용성 성능" , 정보 기술 저널 , 제17권, 제2호, 95-107쪽, 2024년.

@article{serengil2024lightface,
  title     = {A Benchmark of Facial Recognition Pipelines and Co-Usability Performances of Modules},
  author    = {Serengil, Sefik and Ozpinar, Alper},
  journal   = {Journal of Information Technologies},
  volume    = {17},
  number    = {2},
  pages     = {95-107},
  year      = {2024},
  doi       = {10.17671/gazibtd.1399077},
  url       = {https://dergipark.org.tr/en/pub/gazibtd/issue/84331/1399077},
  publisher = {Gazi University}
}

 

 

SI Serengil 및 A. Ozpinar, "LightFace: 하이브리드 딥 페이스 인식 프레임워크" , 2020년 지능형 시스템 및 애플리케이션 혁신 컨퍼런스(ASYU) , 2020, 23-27쪽.

 

SI Serengil 및 A. Ozpinar, "HyperExtended LightFace: 얼굴 속성 분석 프레임워크" , 2021 국제 엔지니어링 및 신흥 기술 컨퍼런스(ICEET) , 2021, pp. 1-4.

 

또한, GitHub 프로젝트에서 deepface를 사용하는 경우 . deepface을 추가하세요 requirements.txt.

특허

DeepFace는 MIT 라이선스에 따라 라이선스가 부여되었습니다. LICENSE자세한 내용은 여기에서 확인하세요.

DeepFace는 일부 외부 얼굴 인식 모델을 래핑합니다: VGG-Face , Facenet (128d와 512d 모두), OpenFace, DeepFace, DeepID, ArcFace, Dlib, SFace, GhostFaceNet  Buffalo_L . 또한, 연령, 성별 및 인종/민족 모델은 전이 학습을 통해 VGG-Face의 백본에서 학습되었습니다.

마찬가지로, DeepFace는 많은 얼굴 감지기를 래핑합니다: OpenCv , Ssd , Dlib , MtCnn , Fast MtCnn , RetinaFace , MediaPipe , YuNet , Yolo  CenterFace . 마지막으로, DeepFace는 선택적으로 얼굴 스푸핑 방지를 사용하여 제공된 이미지가 진짜인지 가짜인지 판별합니다. 해당 모델을 활용하려는 경우 라이선스 유형이 상속됩니다. 프로덕션 목적으로 해당 모델의 라이선스 유형을 확인하세요.

 

DeepFace 로고는 Adrien Coquet가 제작하였으며 크리에이티브 커먼즈: 저작자표시 3.0 라이선스 에 따라 라이선스가 부여되었습니다 .

728x90
반응형
728x90
반응형

 

tail 명령어를 이용해 Tomcat 로그(catalina.out)를 실시간으로 모니터링하면서 별도 파일로 저장하는 방법입니다.

1. tail -f를 사용하여 로그 저장

가장 간단한 방법은 tail -f를 사용하여 로그를 저장하는 것입니다.

실행 명령어 (기본)

tail -f /path/to/tomcat/logs/catalina.out > /path/to/logs/my_tail.log​
  • tail -f: 로그를 실시간 모니터링
  • >: 출력 내용을 새로운 파일로 저장
  • 단점: 이 방식은 Ctrl + C로 종료하면 로그 저장도 멈춥니다.

2. tee를 사용하여 파일과 화면에 동시에 출력

tee 명령을 사용하면 로그를 파일에 저장하면서 동시에 터미널에 출력할 수 있습니다.

파일과 터미널 동시 출력

tail -f /path/to/tomcat/logs/catalina.out | tee -a /path/to/logs/my_tail.log​
  • tee -a: 파일에 추가(-a: append 모드)

장점

  • 로그를 실시간 확인하면서 저장 가능
  • 중간에 Ctrl + C로 종료해도 파일이 유지됨

3. nohup을 사용하여 백그라운드 실행

터미널을 닫아도 로그 저장이 계속되도록 하려면 nohup을 사용할 수 있습니다.

터미널 종료 후에도 로그 저장 유지

nohup tail -f /path/to/tomcat/logs/catalina.out > /path/to/logs/my_tail.log 2>&1 &​
  • nohup: 터미널 종료 후에도 실행 유지
  • 2>&1: 표준 에러 출력도 포함
  • &: 백그라운드 실행

백그라운드 프로세스 확인 및 종료

ps aux | grep tail
kill -9 <PID>  # 특정 프로세스 종료​

 

 

4. screen 또는 tmux를 사용하여 안정적인 로그 저장

만약 원격 서버에서 로그를 장시간 저장해야 한다면, screen 또는 tmux를 사용하는 것이 좋습니다.

screen을 이용한 로그 저장

screen -S tail_log
tail -f /path/to/tomcat/logs/catalina.out > /path/to/logs/my_tail.log​
  • Ctrl + A, D: 세션을 백그라운드로 보내기
  • 다시 접속: screen -r tail_log

5. cron을 이용한 로그 자동 저장 및 관리

일정 시간마다 로그를 저장하고 싶다면 cron을 사용하면 됩니다.

매일 로그 저장 (예: 00:00마다 실행)

crontab -e​

 

추가할 내용:

0 0 * * * tail -n 1000 /path/to/tomcat/logs/catalina.out > /path/to/logs/catalina_$(date +\%F).log​
  • 매일 자정(0 0 * * *)에 최근 1000줄을 새로운 파일로 저장
  • 날짜별(catalina_YYYY-MM-DD.log)로 저장됨

최종 정리 (추천 방법)

방법설명명령어
기본 로그 저장 로그를 파일로 저장 (터미널 닫으면 중단됨) tail -f catalina.out > my_tail.log
화면 + 파일 저장 실시간 확인하면서 저장 `tail -f catalina.out
터미널 종료 후에도 실행 백그라운드 실행 nohup tail -f catalina.out > my_tail.log 2>&1 &
원격 서버에서 사용 screen을 활용하여 안정적 실행 screen -S tail_log + tail -f catalina.out > my_tail.log
자동 로그 저장 cron으로 일정 시간마다 저장 crontab -e

이제 상황에 맞게 tail 로그를 별도로 저장할 수 있습니다! 🚀

728x90
반응형
728x90
반응형

1. sed 사용 (빠르고 간편)

sed -n '1000,$p' catalina.out > new_output.out
  • 1000,$p: 1000번째 줄부터 끝까지 출력 ($는 마지막 줄 의미)
  • > new_output.out: 결과를 new_output.out 파일에 저장

장점: 빠르고 간단하며 대용량 파일에도 적합
단점: 원본 파일이 너무 크면 속도가 느릴 수도 있음

2. tail 사용 (끝에서 특정 줄을 기준으로 복사)

tail -n +1000 catalina.out > new_output.out
  • -n +1000: 1000번째 줄부터 끝까지 출력
  • > new_output.out: 새로운 파일에 저장

장점: 속도가 빠르며 메모리 사용량이 적음
단점: tail 명령이 특정 시스템에서 동작 방식이 다를 수도 있음

3. awk 사용 (유연한 처리 가능)

awk 'NR>=1000' catalina.out > new_output.out
  • NR>=1000: 1000번째 줄부터 끝까지 출력

장점: 조건을 추가하여 더 세밀한 조정 가능 (예: 특정 패턴 이후부터 복사)
단점: sed보다는 약간 느릴 수 있음

4. Python 스크립트 사용 (복잡한 조건 적용 가능)

with open("catalina.out", "r") as infile, open("new_output.out", "w") as outfile:
    for i, line in enumerate(infile, start=1):
        if i >= 1000:
            outfile.write(line)
  • enumerate()를 사용하여 1000번째 줄부터 출력
  • Python을 사용하면 정규식 필터링도 가능

💡 장점: 복잡한 조건을 적용 가능 (예: 특정 문자열 이후부터 복사)
💡 단점: 스크립트를 실행해야 해서 번거로울 수 있음

추천 방법

  • 빠르게 처리하고 싶다면 → sed 또는 tail
  • 유연한 조건이 필요하다면 → awk
  • 복잡한 패턴 분석이 필요하다면 → Python

어떤 방법이든, 특정 라인부터 원하는 대로 catalina.out을 복사할 수 있습니다! 

728x90
반응형
728x90
반응형

 

Banking에서 DeFi란 무엇인가?

DeFi는 "Decentralized Finance"의 약자로, "탈중앙화 금융"을 의미합니다. Blockchain 기술을 활용하여 중앙 기관의 개입 없이 금융 서비스를 제공하는 것을 말합니다. DeFi는 은행이나 증권사 등 전통 금융기관의 역할을 Blockchain 기술로 대체하여, 중개 기관 없이 누구나 참여할 수 있는 금융 서비스를 제공합니다. 

 

이 글을 읽기 전에, 은행 업무에 대해 알고 있다고 생각했던 모든 것을 잊어보세요. 탈중앙화 금융(DeFi)은 은행이나 투자 회사와 같은 전통적인 중개자를 배제하고 금융 당국의 감독을 없애 돈을 다루는 방식을 바꾸고 있습니다. DeFi는 사용자가 안전하고 투명한 환경에서 직접 거래를 통제할 수 있는 세상을 약속합니다.

 

DeFi의 핵심에는 분산 원장인 Blockchain이 있습니다. 이는 암호화되어 연결된, 거래 기록이 담긴 블록 또는 노드로 구성됩니다. 금융 활동을 수행하기 위해 DeFi는 디지털 자산으로서 token을 활용합니다. 디지털 프로세스 자동화를 위해서는 스마트 계약이 사용됩니다. 이는 Blockchain 네트워크에 작성된 계약으로, 대부분 EVM(이더리움 가상 머신)과 호환되며 미리 정의된 조건이 충족되는 즉시 자동으로 실행됩니다.

 

Banking에서의 DeFi 간략한 역사

DeFi의 역사는 2009년 비트코인이 최초의 암호화폐로 등장하여 탈중앙화된 P2P(개인 간) 거래를 가능하게 하면서 시작됩니다. 그러나 변동성이 큰 가격, 확장성 문제, 높은 거래 비용으로 인해 일상적인 사용에는 너무 신뢰할 수 없었습니다.

 

이 때문에 처음 5년 동안 사용자들은 비트코인을 기본적인 거래에만 의존했고 투자 도구로 사용했습니다. 그리고 DeFi 발전의 다음 두 가지 이정표는 옴니 프로토콜(Omni Protocol)과 최초의 성공적인 스테이블 코인인 테더(Tether)의 개발이었습니다. 테더는 탈중앙화된 디지털 자산의 이점을 유지하면서도, 스테이블 코인이 법정화폐에 고정되어 있기 때문에 안정적인 코인 가격과 결합했습니다. 스테이블 코인 거래는 갑작스러운 가격 하락이나 급등으로 거래 비용이 좌우되지 않기 때문에 훨씬 더 신뢰할 수 있습니다.

 

DeFi의 또 다른 전환점은 2015년 이더리움의 출시와 스마트 계약의 도입이었습니다. 이는 또한 대출 플랫폼, 탈중앙화 거래소(DEX) 등과 같은 복잡한 탈중앙화 애플리케이션(dApp)을 이더리움 Blockchain 위에 만들 수 있게 했습니다.

유니스왑(Uniswap)이나 커브 파이낸스(Curve Finance)와 같은 새로운 DEX 플랫폼들은 DeFi 채택 증가에 더욱 기여했습니다. 이들은 중앙화된 거래소 외부에서 대규모 암호화폐 거래를 가능하게 했습니다.

 

오늘날, 특정한 과제들을 안고 있음에도 불구하고 DeFi는 탈중앙화되고 투명하며 접근성이 높은 특성으로 인해 현재와 미래에 중요한 의미를 지닙니다. 더 빠르고 비용 효율적인 서비스를 통해 DeFi는 개인 자산 및 금융 결정에 대한 더 큰 통제권을 제공하고 중개자를 제거합니다.

 

Banking에서 DeFi의 장점과 단점

기존 금융 솔루션에서 DeFi로의 전환을 고려하는 모든 사람에게 핵심 질문은 DeFi의 장점과 단점이 무엇인지입니다. 아래에는 고려해야 할 중요한 몇 가지 장단점이 있습니다.

 

은행업에서 DeFi의 장점

  • 낮은 거래 비용
  • 더 빠른 거래 처리
  • 탈중앙화 및 투명성
  • 더 큰 접근성

은행업에서 DeFi의 단점

  • 규제 부족
  • 해킹 및 사기 위험 증가
  • 암호화폐의 변동성
  • 기존 금융 기관의 제한적인 수용

DeFi 뱅킹 애플리케이션

DeFi는 전통적인 은행 서비스에 대한 탈중앙화된 대안을 제공하며 금융 환경을 적극적으로 재편하고 있습니다. 이 섹션에서는 광범위한 DeFi 뱅킹 애플리케이션과 이들이 일상적인 금융 요구를 해결하는 방식을 살펴봅니다.

 

탈중앙화 거래소(DEX)

탈중앙화 금융(DEX)의 부상은 탈중앙화 금융 발전의 중요한 단계입니다. 회사를 통해 운영되고 주문서 관리를 위해 시장 조성자에게 의존하는 중앙화된 거래소(CEX)와 달리, DEX는 Blockchain 기술과 스마트 계약을 사용하여 완전히 투명한 거래를 가능하게 합니다.

 

CEX는 익숙하지만 중앙화된 특성 때문에 특정 위험을 안고 있습니다. 해킹에 대한 취약성, 잠재적인 정부 개입, 데이터 유출 및 개인 정보 보호 문제는 지속적인 위협입니다. 반면에 DEX는 사용자에게 통제권을 넘겨줍니다. 금융 회사 대신 스마트 계약이 거래 실행 및 유동성 공급에서부터 출금 및 예금에 이르기까지 모든 거래소 구성 요소를 관리합니다. 이는 중개자의 필요성을 없애고 거래 과정 전반에 걸쳐 사용자에게 투명성을 제공합니다.

 

이러한 보관 방식의 차이는 중요합니다. CEX에서는 사용자가 자금을 예치하면 통제권을 잃는 반면, DEX는 사용자가 개인 지갑에서 직접 거래할 수 있도록 하여 보안을 강화하고 사용자 자율성을 증진합니다.

다양한 DEX가 서로 다른 방식으로 운영될 수 있다는 점은 주목할 가치가 있습니다. dYdX와 같이 일부는 CEX와 유사한 주문서 시스템을 채택했지만, 유니스왑, 뱅코르, 팬케이크스왑, 스시스왑을 포함한 대다수는 자동화된 시장 조성자(AMM)라는 다른 접근 방식을 취합니다.

 

자동화된 시장 조성자(AMM)

자동화된 시장 조성자(AMM)는 중앙화된 거래소의 전통적인 주문서 모델을 온체인 유동성 풀로 대체합니다. 이 풀은 거래 수수료의 일부를 받는 대가로 암호화폐를 빌려주는 유동성 공급자에 의해 채워집니다. 풀은 모든 거래의 상대방이 됩니다. 사용자는 주문 매칭의 필요성을 우회하여 AMM의 스마트 계약과 직접 상호 작용합니다.

 

이 혁신적인 접근 방식에는 몇 가지 장점이 있습니다. 스마트 계약과 거버넌스 모델을 통해 통제권이 중앙 권한에서 사용자로 이동함에 따라 탈중앙화가 가장 중요합니다. 이는 또한 사용자가 거래 과정 전반에 걸쳐 자산에 대한 완전한 통제권을 유지하고 지갑에서 직접 상호 작용하는 비수탁 환경을 보장합니다. 중앙화된 거래소의 우려 사항인 시장 조작은 그러한 관행으로 이익을 얻을 수 있는 중앙 주체가 없기 때문에 완화됩니다. DEX의 탈중앙화되고 분산된 특성으로 인해 해커는 개별 사용자 계정이 아닌 유동성 풀만 공격할 수 있으므로 보안이 강화됩니다. 마지막으로, DEX의 개방적이고 무허가적인 특성으로 인해 중앙 권한의 승인 없이 모든 토큰을 상장할 수 있어 토큰에 대한 접근성이 향상됩니다.

 

그러나 AMM에도 과제가 있다는 점을 인지하는 것이 중요합니다. DEX는 풀에 유동성을 공급하는 사용자에게 크게 의존하며, 유동성이 부족하면 거래 활동을 방해하고 가격 책정에 영향을 미칠 수 있습니다. DEX에서의 주문 실행은 정교한 거래 도구의 부족으로 인해 중앙화된 거래소보다 느릴 수 있습니다. DEX의 거래량은 크게 증가했지만, 주문서가 없으면 특히 대규모 주문의 경우 높은 슬리피지가 발생할 수 있습니다. 마지막으로, DEX에서의 거래는 일반적으로 모든 거래에 대해 고정 수수료가 부과되며, 이더리움과 같은 기본 Blockchain 네트워크에서 부과하는 가스 수수료(거래 비용)도 추가됩니다. 이러한 가스 수수료는 네트워크 혼잡도에 따라 크게 변동될 수 있어 잠재적으로 높은 거래 비용을 초래할 수 있습니다.

 

대출 및 차입 플랫폼

대출 및 차입은 전통적인 대출 모델의 대안으로서 탈중앙화 금융 생태계의 또 다른 핵심 구성 요소입니다.

은행과 같은 중앙화된 기관은 소위 게이트키퍼 역할을 하며 승인 알고리즘을 갖추고 있습니다. 승인 과정에는 양호한 신용 점수, 안정적인 고용, 최소 담보와 같은 엄격한 요건이 포함됩니다. 이 시스템은 자연스럽게 전통적인 은행 서비스에 접근할 수 없거나 접근이 제한된 사람들을 배제합니다.

 

DeFi 대출 프로토콜은 신용에 대한 개방적이고 무허가적인 접근 덕분에 이러한 장벽을 허물고 금융 포용을 촉진합니다. 배경, 위치 또는 신용 기록에 관계없이 필요한 자산을 가진 사람은 누구나 자금을 빌릴 수 있습니다. 또한, 이러한 프로토콜은 전통 금융에서 일반적인 KYC(고객 알기 제도) 정책과 같은 스트레스 받는 신원 확인 절차 없이 운영되는 경우가 많습니다.

 

DeFi는 컴파운드(Compound), 에이브(Aave), 메이커(Maker), bZx와 같은 프로토콜 통합을 통해 탈중앙화 대출의 인기를 더욱 높였습니다. 이러한 플랫폼은 대출자와 차입자를 직접 연결하여 대출자는 암호화 자산에 대해 매력적인 이자율을 얻을 수 있고 차입자는 서류 작업 부담 없이 안전하고 익명적인 환경에서 즉각적인 유동성을 확보할 수 있습니다.

 

DeFi 대출의 특히 혁신적인 기능은 플래시 론(flash loans)이라는 개념입니다. 전통적인 대출과 달리 플래시 론은 담보가 필요 없으며 사용자가 잠재적으로 수백만 달러에 달하는 상당한 금액을 빌릴 수 있도록 합니다. 그러나 이러한 대출에는 매우 짧은 상환 기간이 따릅니다. 즉, 거래 블록이 완료되기 전에 상환해야 합니다. 이 독특한 기능은 플래시 론을 차익 거래 및 부채 재융자와 같은 빠른 수익 창출 작업에 적합하게 만듭니다. 그러나 신중하게 관리하지 않으면 사기 행위에 악용될 수 있는 잠재적인 취약점을 야기할 수 있습니다.

스테이블 코인

암호화폐 가격의 자연스러운 변동은 DeFi 생태계에 상당한 과제를 제기합니다. 스테이블 코인은 가격 안정성을 제공하고 시장 변동성과 관련된 위험을 완화하기 위한 해결책으로 등장했습니다.

 

스테이블 코인은 고정된 가치를 유지하도록 설계된 토큰입니다. 일반적으로 미국 달러나 금과 같은 법정화폐 또는 상품에 연동됩니다. 이는 시장 변동성의 영향을 줄여 사용자가 불확실한 기간 동안 자본을 보호할 수 있도록 하는 것을 목표로 합니다. 또한 스테이블 코인은 변동성이 큰 암호화폐를 보다 안정적인 자산으로 전환하여 수익을 확보하는 편리한 방법을 제공합니다.

미국 달러가 스테이블 코인의 지배적인 페그(고정 가치)로 남아 있지만, 이 페그를 유지하는 데 사용되는 메커니즘은 프로젝트마다 크게 다릅니다. 대체로 스테이블 코인은 법정화폐 담보형, 암호화폐 담보형, 알고리즘형의 세 가지 유형으로 나눌 수 있습니다.

 

이름에서 알 수 있듯이 법정화폐 담보형 스테이블 코인은 발행 기관이 보유한 법정화폐 준비금으로 뒷받침됩니다. 가장 널리 사용되는 스테이블 코인 중 하나인 테더(USDT)가 이 접근 방식의 예입니다. 테더는 발행된 모든 USDT 토큰에 대해 1 미국 달러를 준비금으로 보유한다고 주장합니다. 그러나 이 모델은 사용자가 발행자가 적절한 준비금을 유지하고 투명하게 운영한다는 신뢰를 가져야 하므로 신뢰에 크게 의존합니다. 이러한 준비금을 보유하기 위해 중앙화된 기관에 어느 정도 의존하기 때문에 법정화폐 담보형 스테이블 코인은 어느 정도의 중앙화 요소를 도입합니다.

 

반대로, 암호화폐 담보형 스테이블 코인은 페그를 유지하기 위해 다른 암호화폐를 담보로 사용합니다. 그러나 이는 근본적인 암호화 자산의 고유한 변동성이라는 과제를 제시합니다. 담보 가치 변동으로 인해 스테이블 코인이 페그를 잃을 위험을 완화하기 위해 이러한 방식은 초과 담보되도록 설계됩니다. 이더리움 네트워크에 구축된 대표적인 예인 다이(DAI)는 스마트 계약과 초과 담보된 포지션을 사용하여 미국 달러에 대한 페그를 보장합니다.

 

스마트 계약의 투명성을 통해 사용자는 담보 비율, 잠긴 자산의 가치 및 DAI의 안정성을 관리하는 메커니즘을 독립적으로 확인할 수 있습니다. 이러한 투명성은 DAI의 탈중앙화된 특성을 강화하고 생태계 내 신뢰를 조성합니다.

알고리즘 스테이블 코인은 종종 담보에 의존하지 않고 알고리즘과 스마트 계약을 통해 가격 안정을 유지하는 것을 목표로 합니다. 일반적으로 시장 수요에 따라 스테이블 코인 공급을 확대 및 축소하는 것과 같은 메커니즘을 사용하여 페그를 유지합니다.

 

결제 게이트웨이

DeFi가 전통적인 금융 서비스를 복제하는 데 진전을 이루었지만, 일상적인 비즈니스에서의 채택은 기존 결제 시스템과의 통합이라는 상당한 장애물에 직면해 있습니다. 바로 이 지점에서 DeFi 결제 게이트웨이가 역할을 합니다.

전통적인 결제 게이트웨이는 중개자 역할을 하여 고객, 기업 및 금융 기관 간의 거래를 촉진합니다. 그러나 이러한 중앙화된 모델에는 수수료, 지연 및 잠재적인 장애 지점과 같은 단점이 따릅니다.

 

DeFi 결제 게이트웨이는 Blockchain 기술을 사용하여 기업이 중개자와 관련 비용을 우회하여 직접 암호화폐 결제를 받을 수 있도록 합니다. 스마트 계약은 결제 프로세스를 자동화하고 더 빠른 거래 속도, 절감된 수수료 및 향상된 투명성을 보장합니다.

또한 DeFi 결제 게이트웨이는 서로 다른 Blockchain 네트워크와 통합되어 상호 운용성을 촉진하고 DeFi 애플리케이션의 범위를 확장할 수 있습니다. 이는 국경 간 결제, 소액 결제 및 프로그래밍 가능한 결제에 대한 새로운 기회를 열어 새로운 비즈니스 모델과 수익원을 가능하게 합니다.

 

그러나 DeFi 결제 게이트웨이는 광범위한 채택을 방해하는 몇 가지 장애물에 직면해 있습니다. 명확한 규제의 부재는 사용자와 기업 모두에게 불확실성을 야기할 수 있으며, 암호화폐를 처음 접하는 사람들에게는 복잡한 사용자 인터페이스가 부담스러울 수 있으므로 신중한 고려가 필요합니다.

이러한 장벽에도 불구하고 DeFi 결제 게이트웨이는 보다 효율적이고 접근성 높은 금융 시스템을 구축할 수 있는 엄청난 잠재력을 가지고 있습니다.

 

DeFi가 은행업을 변화시키는 방식

탈중앙화 금융(DeFi)의 급격한 성장은 금융계를 혁신하고 있습니다. DeFi의 채택 증가는 보다 포용적인 서비스와 향상된 보안에 대한 요구에 의해 주도되며, 우리가 돈과 금융 시스템과 상호 작용하는 방식을 재편할 것입니다.

 

탈중앙화 금융 서비스로의 전환

스마트 계약을 통해 DeFi 플랫폼은 은행과 같은 중개자 없이 P2P 거래를 가능하게 합니다. 이러한 전환은 사용자에게 자산 및 금융 결정에 대한 더 큰 통제권을 부여하고, 금융 포용을 촉진하며, 전통적인 중개자에 대한 의존도를 줄입니다.

 

DeFi가 전통 은행 기관에 미치는 영향

DeFi의 부상은 전통 은행 기관에 도전과 기회를 동시에 제시합니다. 한편으로, 대출, 차입, 결제와 같은 핵심 은행 기능에서 중개자를 배제할 수 있는 DeFi의 잠재력은 상당한 경쟁 위협을 제기합니다. DeFi 플랫폼은 종종 예금에 대해 더 높은 이자율을 제공하고 대출에 대해 더 낮은 수수료를 부과하여 더 나은 수익과 낮은 비용을 추구하는 고객을 유치합니다.

 

다른 한편으로, 전략적으로 생각하고 혁신적인 은행들은 기존 인프라에 DeFi 솔루션을 통합할 방법을 모색하고 있습니다. 여기에는 효율성, 투명성 및 거래 보안을 개선하기 위해 Blockchain 기술을 수용하는 것이 포함됩니다. 또한 이러한 은행들은 DeFi 기반 제품 및 서비스를 통해 새로운 수익원을 모색하고 있습니다.

 

금융 산업을 혁신할 DeFi의 잠재력

DeFi는 금융 서비스에 대한 접근을 민주화하고, 수수료 및 거래 비용을 절감하며, 효율성을 높임으로써 금융 산업을 크게 혁신할 실질적인 잠재력을 가지고 있습니다. DeFi 프로토콜의 투명한 특성은 더 넓은 사용자층의 요구에 맞는 금융 상품 및 서비스 개발로 이어지고 있습니다. Blockchain으로 인해 사기 및 사이버 공격에 대한 취약성이 제거되므로 이러한 향상된 보안 요소는 DeFi의 인기 상승에 더욱 기여합니다.

 

은행업 규제 속 DeFi

DeFi의 빠른 발전은 규제 프레임워크보다 앞서 나아가 초기 사용자와 규제 당국 모두에게 복잡한 환경을 만들고 있습니다. 이 섹션에서는 은행업에서의 DeFi에 대한 규제 환경, 내재된 위험 및 잠재적인 완화 전략을 자세히 살펴봅니다.

 

현재 DeFi 규제 현황

현재 은행 산업에서 DeFi를 위해 특별히 설계된 포괄적인 규제 프레임워크는 없습니다. 이 때문에 전 세계 규제 당국은 빠르게 발전하는 이 분야에 기존 금융 규제를 어떻게 적용할지 고심하고 있습니다. 그럼에도 불구하고 더 많은 지역에서 맞춤형 규제의 필요성을 인식하고 DeFi 관련 프레임워크 개발을 향한 선제적인 조치를 취하고 있습니다.

 

예를 들어 유럽 연합은 DeFi에 사용되는 암호화 자산을 포함하여 암호화 자산을 규제하는 것을 목표로 하는 암호화 자산 시장 규정(MiCA)을 마련 중입니다.

 

DeFi 규제의 미래

DeFi의 미래는 균형 잡히고 효과적인 규제 프레임워크 개발에 달려 있습니다. 이러한 프레임워크는 해당 분야의 혁신을 저해하지 않으면서 투자자 보호를 우선시하고 시장의 무결성을 보장해야 합니다. 이러한 균형을 위해서는 탈중앙화 금융의 합법성을 보장하는 동시에 위험을 완화하기 위해 산업 협력, 기술 발전 및 규제 감독을 결합한 포괄적인 접근 방식이 필요합니다. 현재 여러 지역에서 잠재적인 규제 접근 방식에는 DeFi 플랫폼에 대한 라이선스 요구 사항, 소비자 보호 조치 및 시스템적 위험 해결 메커니즘이 포함됩니다.

 

은행업에서 DeFi의 위험과 과제

DeFi가 큰 가능성을 지니고 있지만 단점도 없는 것은 아닙니다. 장기적으로 번창하기 위해서는 몇 가지 위험과 과제를 해결해야 합니다.

주요 우려 사항 중 하나는 사이버 보안입니다. DeFi는 스마트 계약에 크게 의존하기 때문에 코드의 취약점은 해커에게 악용될 수 있으며, 잠재적으로 사용자에게 상당한 금전적 손실을 초래할 수 있습니다.

 

DeFi의 탈중앙화된 특성은 여러 면에서 강점이지만, 거버넌스 및 책임 소재 측면에서는 과제를 제시합니다. 중앙 권한이 없으면 명확한 책임선을 설정하고 분쟁을 해결하는 것이 복잡할 수 있습니다.

 

DeFi 시장은 상대적으로 젊기 때문에 변동성과 조작에 취약합니다. 급격한 가격 변동과 시장 조작 가능성은 투자자에게 위험을 초래합니다.

스마트 계약의 한계도 과제를 제시합니다. 네트워크 혼잡은 높은 거래 수수료와 느린 실행 속도로 이어져 DeFi 애플리케이션의 효율성을 저해할 수 있습니다.

 

마지막으로, DeFi의 중앙화된 감독 부재는 사기 및 스캠의 기회를 만듭니다. 악의적인 행위자는 시스템의 익명성과 탈중앙화된 구조를 악용하여 사용자를 속이고 자금을 훔칠 수 있습니다.

 

은행업에서 DeFi의 위험과 과제를 완화하는 방법

견고하고 지속 가능한 DeFi 생태계를 구축하려면 기본적인 보호를 넘어 정교하고 상호 연결된 솔루션으로 나아가는 다층적인 위험 완화 접근 방식이 필요합니다.

 

  • 스마트 계약의 보안 개선

코드 감사가 필수적이지만 진정한 견고성을 달성하려면 형식 검증 기술로의 전환이 필요합니다. 스마트 계약 로직의 정확성을 증명하는 데 사용되는 수학적 모델은 DeFi를 괴롭혔던 공격의 위험을 사전에 제거하고 취약성을 줄일 수 있습니다.

 

  • DAO를 넘어서는 탈중앙화 거버넌스

DAO는 DeFi 생태계에 탈중앙화 거버넌스를 도입하는 데 중요한 발전이었습니다. 그러나 현재 형태로는 한계와 단점이 있습니다. 사람들은 투표에 대한 관심을 잃거나 소수의 부유층이 통제권을 장악할 수 있습니다. 거버넌스를 더 강력하고 포용적으로 만들기 위해서는 새로운 메커니즘을 개발해야 합니다. 온체인 평판 시스템, 이차 투표(quadratic voting), 푸타키(futarchy)는 더 탄력적이고 대표적인 거버넌스 구조를 만들기 위한 유망한 접근 방식입니다.

 

  • 촉매로서의 규정 준수

KYC(고객 알기 제도) 및 AML(자금 세탁 방지) 절차의 통합은 규제상의 일상적인 절차로 간주되어서는 안 되며, 신뢰를 강화하고 대중적인 채택을 촉진할 기회로 보아야 합니다. 영지식 증명과 같은 개인 정보 보호 기술을 활용하면 DeFi 생태계 내에서 중요한 우려 사항인 사용자 개인 정보를 침해하지 않으면서 규정을 준수할 수 있습니다.

 

  • 시너지

DeFi와 전통 금융 간의 관계는 단순한 파트너십을 넘어 협력적인 생태계로 나아가야 합니다. 실제 자산을 담보로 사용하거나 하이브리드 CeFi-DeFi 상품을 만드는 등 DeFi 프로토콜을 기존 금융 인프라와 통합하면 양쪽과 관련된 위험을 완화하면서 가치 창출을 위한 새로운 길을 열 수 있습니다.

이러한 접근 방식을 수용함으로써 DeFi 생태계는 탄력성, 보안 및 책임 있는 혁신을 향해 나아갈 수 있으며, 글로벌 금융 환경에 대한 변혁적인 잠재력을 발휘할 수 있습니다.

결론

DeFi는 은행 업무 영역을 변화시키고 있으며, 금융 서비스가 더 접근하기 쉽고 효율적이며 사용자 중심적인 미래를 엿볼 수 있게 합니다. 과제가 남아 있지만, 전통 금융을 변화시킬 DeFi의 잠재력은 부인할 수 없습니다. 위험 관리, 혁신 및 협력을 통해 DeFi는 모두를 위한 보다 포용적인 금융 시스템으로 전환될 수 있습니다.

 

https://innowise.com/blog/defi-in-banking/

 

What is DeFi in banking?

Discover how DeFi banking is reshaping traditional banking, challenging old norms, and driving innovation in finance. Read more on the Innowise Blog.

innowise.com

728x90
반응형

'블록체인' 카테고리의 다른 글

DeFi에 대한 6가지 기본 질문  (1) 2025.05.16
728x90
반응형

 

MySQL 백업 파일(.sql.gz)을 복원하려면 먼저 압축을 풀고 mysql 명령어를 사용해야 합니다.

방법 1: 압축을 풀면서 바로 복원

.gz 파일을 압축 해제 없이 직접 MySQL로 복원할 수 있습니다.

gunzip -c backup.sql.gz | mysql -u [username] -p [database_name]

설명

  • gunzip -c backup.sql.gz: 압축 해제된 내용을 표준 출력(stdout)으로 보냄.
  • | mysql -u [username] -p [database_name]: 해제된 SQL을 바로 MySQL로 복원.
  • -p 입력 후 비밀번호를 입력해야 합니다.

예제

gunzip -c mybackup.sql.gz | mysql -u root -p mydatabase
  • mybackup.sql.gz의 내용을 mydatabase에 복원.

 

방법 2: 압축을 먼저 풀고 복원

.gz 압축을 먼저 풀고 .sql 파일을 복원하는 방법입니다.

1. 압축 해제

gunzip backup.sql.gz
  • backup.sql.gz → backup.sql로 압축 해제됨.

2. MySQL로 복원

mysql -u [username] -p [database_name] < backup.sql

💡 예제

mysql -u root -p mydatabase < backup.sql

 

방법 3: zcat을 사용한 직접 복원

Linux에서 zcat을 활용하면 압축을 풀면서 즉시 복원할 수 있습니다.

zcat backup.sql.gz | mysql -u [username] -p [database_name]

💡 예제

zcat mybackup.sql.gz | mysql -u root -p mydatabase

추가 옵션

1. 복원 진행 상태 보기

기본적으로 mysql 명령어로 복원하면 진행 상태가 보이지 않지만, 다음과 같이 하면 진행 상황을 확인할 수 있습니다.

gunzip -c backup.sql.gz | pv | mysql -u [username] -p [database_name]
  • pv 명령어는 데이터 처리 속도 및 진행률을 표시합니다.
  • 설치 필요: sudo apt install pv (Ubuntu) 또는 sudo yum install pv (CentOS)

2. 특정 테이블만 복원

.gz 파일에서 특정 테이블만 복원하려면 압축 해제 후 수동 편집해야 합니다.

gunzip -c backup.sql.gz | grep -i 'INSERT INTO table_name' | mysql -u [username] -p [database_name]
  • grep을 활용하여 특정 테이블만 필터링할 수도 있음.

 

복원 전 확인해야 할 사항

1. 데이터베이스가 존재하는지 확인

mysql -u root -p -e "SHOW DATABASES;"
  • 데이터베이스가 없으면 먼저 생성:
mysql -u root -p -e "CREATE DATABASE mydatabase;"

 

2. 백업 파일 크기 확인

ls -lh backup.sql.gz
  • 너무 큰 경우 screen이나 nohup을 사용하여 백그라운드에서 실행 가능.

3. 기존 데이터 백업 복구 전에 현재 데이터를 백업하는 것이 안전합니다.

mysqldump -u root -p mydatabase > mydatabase_backup.sql

 

 

결론

방법명령어

압축 풀면서 복원 `gunzip -c backup.sql.gz
압축 해제 후 복원 gunzip backup.sql.gz → mysql -u root -p mydatabase < backup.sql
zcat 활용 `zcat backup.sql.gz
진행률 표시 (pv) `gunzip -c backup.sql.gz

가장 빠른 방법은 gunzip -c 또는 zcat을 사용한 실시간 복원입니다.
하지만 데이터 크기에 따라 미리 gunzip으로 압축을 풀고 복원하는 방법이 더 안정적일 수 있습니다. 

728x90
반응형
728x90
반응형

MySQL에서는 일반적인 TRUNCATE TABLE 명령어로 특정 파티션만 비우는 기능이 없습니다. 그러나 ALTER TABLE ... TRUNCATE PARTITION 명령어를 사용하여 특정 파티션을 개별적으로 삭제할 수 있습니다.


특정 파티션의 데이터 삭제

ALTER TABLE table_name TRUNCATE PARTITION partition_name;

예제

ALTER TABLE sales TRUNCATE PARTITION p2023;
  • sales 테이블에서 p2023 파티션의 모든 데이터를 삭제.
  • 테이블의 다른 파티션에는 영향을 주지 않음.

전체 테이블을 비우는 경우

테이블의 모든 데이터를 삭제하려면 일반적인 TRUNCATE TABLE 사용:

TRUNCATE TABLE sales;

주의: 모든 파티션이 삭제되며 자동 재생성됨.

 

특정 파티션만 삭제 후 재사용 가능하게 만들기

MySQL에서 TRUNCATE PARTITION은 단순히 데이터를 비우는 것이지, 파티션 자체를 제거하지 않습니다.
특정 파티션을 삭제하고 다시 추가하려면:

ALTER TABLE sales DROP PARTITION p2023;
ALTER TABLE sales ADD PARTITION (PARTITION p2023 VALUES LESS THAN (2024));

주의: DROP PARTITION을 사용하면 데이터와 함께 파티션 자체가 삭제되므로 신중히 사용해야 합니다.


TRUNCATE PARTITION을 지원하는 MySQL 버전

  • MySQL 5.7 이상에서 지원됨.
  • 일부 스토리지 엔진(InnoDB, NDB)에서만 가능. MyISAM은 지원되지 않음.

결론

  1. 특정 파티션의 데이터를 삭제하려면:
  2. 모든 데이터를 삭제하려면:
  3. 특정 파티션을 삭제 후 다시 생성하려면:

1. 특정 파티션의 데이터를 삭제하려면:

ALTER TABLE table_name TRUNCATE PARTITION partition_name;

 

 

2. 모든 데이터를 삭제하려면:

TRUNCATE TABLE table_name;

 

 

3. 특정 파티션을 삭제 후 다시 생성하려면:

ALTER TABLE table_name DROP PARTITION partition_name;
ALTER TABLE table_name ADD PARTITION (PARTITION partition_name VALUES ...);

 

이 방법을 활용하면 MySQL의 파티션 테이블에서 원하는 데이터만 효율적으로 삭제할 수 있습니다.

728x90
반응형
728x90
반응형

액세스 승인자액세스 구현자는 정보 시스템이나 네트워크에서 접근 제어와 보안 관리를 담당하는 데 있어 각기 다른 역할을 수행합니다. 이 두 역할을 이해하면, 권한 부여 및 실제 접근의 세부 과정에 대한 명확한 이해를 할 수 있습니다.

1. 액세스 승인자 (Access Approver)

  • 주요 역할: 사용자의 접근 요청을 검토하고 승인하거나 거부하는 권한을 가진 사람 또는 시스템입니다.
  • 책임:
    • 액세스 권한을 필요로 하는 사람의 요청을 평가하여 필요성과 적법성을 판단.
    • 조직의 보안 정책에 따라, 각 사용자가 필요한 권한만 가지도록 접근 수준을 조정.
    • 승인된 요청만을 구현자가 처리할 수 있도록 권한 부여를 관리.
  • 예시:
    • 시스템 관리자, 보안 책임자, 혹은 매니저가 해당 역할을 수행할 수 있습니다.
    • 예를 들어, 특정 직원이 특정 데이터베이스에 접근할 필요가 있는 경우, 매니저가 승인을 할 수 있습니다.

2. 액세스 구현자 (Access Implementer)

  • 주요 역할: 승인자가 승인한 접근 권한을 시스템에 실제로 적용하는 사람 또는 시스템입니다.
  • 책임:
    • 승인된 접근 권한을 시스템에 반영하여 사용자가 요청한 리소스에 접근할 수 있도록 설정.
    • 승인이 없는 권한 요청은 무시하며, 승인된 권한만 적용.
    • 역할 기반 접근 제어(RBAC) 등의 보안 정책을 따라 구현.
  • 예시:
    • IT 관리자 또는 시스템 엔지니어가 주로 이 역할을 수행합니다.
    • 승인자가 승인한 후, IT 담당자가 사용자의 계정에 해당 권한을 부여하는 경우입니다.

차이점 요약

구분액세스 승인자액세스 구현자

역할 접근 요청을 검토하고 승인 여부 결정 승인된 접근 권한을 시스템에 반영
책임 접근 필요성 평가, 정책 준수 확인 승인된 권한만 실제로 구현
접근 제어 관점 승인 프로세스의 시작점 승인 후 적용하는 최종 단계
예시 보안 관리자, 매니저 IT 관리자, 시스템 엔지니어

따라서, 승인자는 "접근 권한을 부여할지 결정"하고, 구현자는 "결정된 접근 권한을 시스템에 적용"하는 차이가 있습니다.

728x90
반응형

'보안' 카테고리의 다른 글

SOC 2  (0) 2024.03.15
728x90
반응형

 

MySQL에서 BLOB 타입의 경우, 문자열 길이에 따라 테이블이 차지하는 용량을 계산할 수 있습니다.

4000 Characters를 BLOB로 저장할 때 크기를 계산하는 방법은 다음과 같습니다.

  1. MySQL BLOB 특성:
    • BLOB 타입은 바이너리 데이터(binary data)를 저장합니다.
    • 문자열이 아니라 바이너리 데이터로 저장되므로, 문자 개수가 아니라 바이트 수로 계산합니다.
    • MySQL에서 일반적으로 1 character = 1 byte로 계산되지만, 문자열이 멀티바이트 (UTF-8 등) 문자 집합을 사용한다면 1 character가 1 byte 이상일 수 있습니다.
  2. 4000 Characters가 차지하는 용량:
    • 문자열이 UTF-8로 인코딩된 경우, 문자당 최대 4바이트가 될 수 있습니다.
    • 최악의 경우(모든 문자가 4바이트를 차지하는 경우) 4000 characters × 4 bytes = 16,000 bytes가 됩니다.
    • 따라서 **16,000 bytes (16 KB)**가 됩니다.
  3. 테이블의 크기 계산:
    • MySQL에서 BLOB 칼럼을 갖는 테이블은 칼럼 외에도 인덱스, 테이블 메타데이터 등의 추가 공간을 차지할 수 있습니다.
    • 그러나, 단순히 BLOB 데이터 자체만 계산한다면 위의 16 KB가 해당 데이터의 크기입니다.
  4. MegaBytes로 변환:
    • 16 KB = 0.015625 MB
    • 따라서, 4000 characters의 데이터가 BLOB 컬럼으로 저장된 경우 약 0.016 MB를 차지합니다.

요약하면, BLOB으로 4000 characters를 저장할 때 데이터가 차지하는 대략적인 크기는 약 0.016 MB입니다.

728x90
반응형

+ Recent posts