4. Stream Analytics에서 Power BI를 출력으로 추가할 때, '그룹 작업 영역'에 아까 저장해둔 작업 영역 ID를 입력.
5. '권한 부여'를 누르고, 로그인 화면이 뜨면 작업영역이랑 동일한 powerBI 계정으로 로그인
6. powerBI로 돌아와서 '데이터 가져오기' > 'powerBI 의미 체계 모델' > '연결' > 내가 사용하려는 데이터셋 선택하면 완료!

피드백 정리

✅ 잘 된 부분

발표 앞부분의 논리 흐름이 좋았어. 문제 제기와 Why Now까지의 흐름이 설득력 있었고 첫인상이 좋았다는 평가를 받았어. 특히 규제가 존재해서 우리 서비스가 필요하다는 부분이 가장 좋게 평가됐어.

**문제의 원인**
1. 점역이 비싸고 수작업이라 오래 걸린다
2. 접근성 표준은 있지만 그걸 준수할 기술이 없다
3. 결과적으로 7.6%의 자료만 접근성이 보장된다

**지금 해결해야 하는 이유**
1. **규제가 존재**해서 우리 서비스가 법적 필수재가 된다
2. 예산은 이미 배정되어 있다

**기존 솔루션의 문제**
1. 충분한 자동화가 없다
2. 서비스들이 분산되어 있다

**우리 솔루션**
1. 충분한 자동화
2. 분산된 서비스를 통합한 플랫폼

다른 팀 적용: 발표 초반 문제 정의와 감정적 훅은 심사위원의 첫인상을 결정해. 앞부분에 가장 많은 공을 들여.

❌ 부족했던 부분

1. 솔루션 설명이 불명확했어

심사위원이 "뭘 하려는 건지", "결과물이 뭔지"를 계속 물었어. 흩어진 기술들을 모아서 빈 공간을 채운다는 핵심 개념이 발표에서 전달되지 않았어. 특히 Pedagogical Masking 같은 독자적 기술이 충분히 설명되지 않고 슬라이드에만 적혀서 넘어갔어.

다른 팀 적용: 솔루션의 핵심을 한 문장으로 말할 수 없다면 청중도 이해하지 못해. "우리는 X를 Y방식으로 해결한다"를 한 문장으로 압축해서 반드시 발표에 포함시켜.

2. 교과서인지 학습지인지 명확하지 않았어

타깃 제품이 무엇인지 흐지부지 넘어갔어. 심사위원 입장에서는 범위가 불명확하면 신뢰도가 떨어져.

다른 팀 적용: 타깃을 좁게 정의할수록 설득력이 높아져. "우리는 모든 것을 한다"보다 "우리는 이것부터 한다"가 더 강해.

3. 비즈니스 모델 설명이 작동 방식 없이 숫자만 있었어

돈 버는 구조는 설명됐지만 실제로 어떻게 운영되는지가 빠졌어. 심사위원은 비즈니스 모델에서 두 가지를 봐. 어떻게 작동하는지, 그리고 어떻게 돈을 버는지. 둘 다 한눈에 보여야 해.

다른 팀 적용: 비즈니스 모델 슬라이드는 화려하게 만들 필요 없어. "A가 B를 하면 C가 발생하고 우리는 D를 가져간다"는 흐름이 한눈에 보이면 충분해.

X	?

4. Callback 답변이 너무 길었어

질문의 의도를 파악하고 요점만 말하는 게 필요했어. 심사위원이 원한 건 "있는 걸 모아서 빈 공간을 채운다" 한 문장이었는데 너무 길게 답했어.

다른 팀 적용: Q&A에서 답변은 두 문장 이내로 시작해. 핵심을 먼저 말하고, 필요하면 한 문장을 덧붙여. 길게 말할수록 핵심이 묻혀.

💡 핵심 인사이트 — 심사위원이 가장 강조한 것

"결과물은 똑같아. How to가 다른 거야. 오퍼레이션이 다른 거야."

기존 점자 교재와 Aequalis의 결과물은 같아. 차이는 만드는 방식이야. 이걸 한 문장으로 압축해서 발표에 넣었어야 했어.

심사위원이 제안한 한 줄:

"흩어져 있는 점역 기술들을 모아서 큐레이션하고, 빈 공간은 우리만의 기술로 채운다. 결과물은 같지만 훨씬 빠르고 정확하게."

다른 팀 적용: 발표에서 "우리만의 한 줄"이 없으면 심사위원은 발표가 끝난 후 아무것도 기억하지 못해. 발표 준비의 마지막 단계는 항상 "이 발표를 한 문장으로 요약하면?"에 답하는 거야.

🔍 추가 피드백 인사이트

플랫폼 비즈니스는 차별화가 핵심이야

플랫폼 비즈니스는 비슷한 게 너무 많아. "찾으면 나온다"는 말이 나올 수 있어. 그래서 왜 우리가, 왜 지금, 왜 이 시장에서 이 생각을 하게 됐는지를 보여줘야 해. 차별점은 기능이 아니라 문제 정의에서 나와. 문제 정의가 정확할수록 "이 팀이 들어가면 해결된다"는 확신을 줄 수 있어.

다른 팀 적용: 제일 좋은 비즈니스는 벤치마킹이라고 했어. 이미 검증된 모델을 가져오되, 우리가 이 문제를 발견한 맥락과 이유를 보여주는 게 차별점이야. "왜 우리가 이걸 만들게 됐는가"가 설득력의 핵심이야.

4단계 구조를 지켜

심사위원이 직접 제시한 발표 구조야.

1. 현상 — 이런 일이 일어나고 있다
2. 문제 정의 — 이게 왜 문제인가
3. 솔루션 — 우리는 이렇게 해결한다
4. 임팩트 — 그 결과 이렇게 달라진다

다른 팀 적용: 4분 발표든 10분 발표든 이 구조를 벗어나지 마. 솔루션을 먼저 말하고 싶은 충동을 참아. 문제가 먼저 공감돼야 솔루션이 설득돼.

Azure 콘솔에서 리소스를 하나씩 클릭해서 만들어본 적 있으신가요?

개발 환경 하나 세팅하는 데 30분씩 클릭하고, 팀원한테 "나랑 똑같이 만들어줘" 하면 어딘가 하나씩 빠져있고, 운영 환경에 같은 구성을 다시 만들려니 뭘 먼저 만들었는지도 기억이 안 납니다.

ARM 템플릿은 이 문제를 해결하기 위해 존재합니다.

한 마디로 정의하면, "Azure 인프라의 설계도를 JSON 파일로 저장해두는 것" 입니다. 이 파일 하나면 누구든, 어디서든, 동일한 Azure 환경을 빠르게 재현할 수 있습니다.

2. ARM 템플릿이 뭔가요?

선언형 vs 명령형

인프라를 만드는 방식에는 두 가지가 있습니다.

명령형 — "어떻게 만들지"를 순서대로 직접 지시하는 방식

az group create --name myRG --location koreacentral
az storage account create --name myStorage ...
az functionapp create --name myFunctionApp ...

선언형 — "무엇을 만들지"를 기술하면 Azure가 알아서 처리하는 방식

{
  "resources": [
    { "type": "Microsoft.Storage/storageAccounts", ... },
    { "type": "Microsoft.Web/sites", ... }
  ]
}

ARM 템플릿은 선언형입니다. 순서를 직접 신경 쓰지 않아도 되고, Azure가 의존 관계를 파악해서 알아서 순서대로 만들어줍니다.

ARM 템플릿의 기본 JSON 구조

ARM 템플릿은 아래와 같은 구조로 이루어져 있습니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "variables": {},
  "resources": [],
  "outputs": {}
}

각 섹션이 어떤 역할을 하는지는 아래 표를 참고하세요.

3. 왜 써야 하나요?

반복 배포 → 동일한 결과 보장

같은 ARM 템플릿으로 배포하면 개발, 스테이징, 운영 환경이 항상 동일하게 만들어집니다. 사람이 클릭하다 실수로 설정이 달라지는 문제가 없어집니다.

또한 ARM 템플릿은 멱등성(Idempotency) 을 보장합니다. 같은 템플릿을 여러 번 실행해도 결과가 동일하고, 이미 있는 리소스는 건드리지 않고 없는 것만 만듭니다.

인프라를 Git으로 관리할 수 있음

ARM 템플릿은 JSON 파일이기 때문에 코드처럼 Git으로 버전 관리할 수 있습니다.

• 누가 언제 어떤 인프라를 바꿨는지 추적 가능
• PR 리뷰로 인프라 변경 사항을 팀이 함께 검토
• 잘못 배포했을 때 이전 버전으로 롤백 가능

팀 협업 시 환경 통일

신규 팀원이 합류했을 때 "이 파일로 배포하면 돼"라고 하면 끝입니다. 구두로 세팅 방법을 설명하거나 문서를 따로 관리할 필요가 없습니다.

4. 어떻게 만드나요?

ARM 템플릿을 만드는 방법은 크게 두 가지입니다.

방법 1: 기존 리소스 그룹에서 템플릿 내보내기

이미 Azure Portal에서 만들어둔 리소스가 있다면, 그걸 그대로 템플릿으로 추출할 수 있습니다.

Azure Portal 접속
→ 리소스 그룹 선택
→ 왼쪽 메뉴에서 [자동화] > [템플릿 내보내기] 클릭
→ [다운로드] 버튼 클릭

⚠️ 내보낸 템플릿 사용 시 주의사항:

• 일부 속성이 누락되거나 하드코딩된 값이 들어있을 수 있습니다
• 비밀번호, 연결 문자열 같은 민감한 정보는 보안상 의도적으로 빠져있습니다
• 바로 재배포하면 오류가 날 수 있으니 내용을 먼저 검토하는 것이 좋습니다

방법 2: VS Code에서 직접 작성

VS Code ARM 템플릿 확장 설치

VS Code 확장 마켓플레이스에서 Azure Resource Manager (ARM) Tools를 설치합니다.

템플릿 직접 작성 예시

아래는 Storage Account 하나를 만드는 간단한 ARM 템플릿 예시입니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "type": "string",
      "metadata": {
        "description": "Storage Account 이름"
      }
    },
    "location": {
      "type": "string",
      "defaultValue": "koreacentral",
      "metadata": {
        "description": "리소스를 배포할 Azure 지역"
      }
    }
  },
  "variables": {
    "storageSku": "Standard_LRS"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2021-09-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "[variables('storageSku')]"
      },
      "kind": "StorageV2"
    }
  ],
  "outputs": {
    "storageAccountId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    }
  }
}

코드 포인트 설명:

• parameters('storageAccountName') : 배포할 때 입력받는 Storage Account 이름
• variables('storageSku') : 내부에서 재사용하는 SKU 값
• outputs : 배포 후 만들어진 Storage Account의 ID를 반환

5. 어떻게 배포하나요?

방법 1: Azure Portal에서 배포

Azure Portal 접속
→ 검색창에 "사용자 지정 템플릿 배포" 입력
→ [편집기에서 사용자 고유의 템플릿 빌드합니다.] 클릭
→ JSON 파일 붙여넣기 또는 파일 업로드
→ [저장] 클릭
→ 구독, 리소스 그룹, 파라미터 값 입력
→ [검토 + 만들기] 클릭 후 배포

방법 2: Azure CLI로 배포

Azure CLI가 설치되어 있다면 터미널에서 바로 배포할 수 있습니다.

# 1. Azure 로그인
az login

# 2. 리소스 그룹 생성 (없는 경우)
az group create --name myResourceGroup --location koreacentral

# 3. ARM 템플릿 배포
az deployment group create \
  --resource-group myResourceGroup \
  --template-file ./azuredeploy.json \
  --parameters storageAccountName=mystorageaccount123

배포 후 확인 방법

배포가 완료되면 아래 방법으로 결과를 확인할 수 있습니다.

Azure Portal에서 확인:

리소스 그룹 → [배포] 메뉴 클릭
→ 배포 이력 및 각 리소스 생성 결과 확인 가능

CLI에서 확인:

# 배포 상태 확인
az deployment group show \
  --resource-group myResourceGroup \
  --name azuredeploy

# 실제 리소스 생성 확인
az storage account show --name mystorageaccount123

6. 주의할 점

민감한 정보는 템플릿에 직접 넣지 마세요

비밀번호, 연결 문자열, API 키 같은 값을 JSON에 하드코딩하면 Git에 올라갔을 때 그대로 노출됩니다. 대신 Azure Key Vault 를 연동하거나 배포 시점에 파라미터로 주입하는 방식을 사용하세요.

// ❌ 절대 이렇게 하지 마세요
"adminPassword": {
  "value": "mypassword123!"
}

// ✅ 파라미터로 분리하고 Key Vault 참조
"adminPassword": {
  "reference": {
    "keyVault": {
      "id": "/subscriptions/.../vaults/myKeyVault"
    },
    "secretName": "adminPassword"
  }
}

내보낸 템플릿은 100% 완벽하지 않습니다

Portal에서 내보낸 템플릿은 바로 재배포하면 오류가 날 수 있습니다. 특히 아래 항목들은 반드시 검토하세요.

• 하드코딩된 리소스 이름이나 ID 값
• 누락된 필수 속성
• 민감 정보가 비어있는 필드

참고할 공식 문서

• 템플릿 개요
• 템플릿에서 리소스 선언

local.settings.json은 별도로 관리해야 합니다

ARM 템플릿은 클라우드 인프라를 만들어주는 파일입니다. 로컬 개발 환경에서 사용하는 local.settings.json은 자동으로 채워지지 않습니다.

ARM 템플릿으로 Storage Account나 Function App을 만들고 나면, 그 연결 문자열을 직접 복사해서 local.settings.json에 붙여넣어야 합니다.

// local.settings.json - ARM 배포 후 직접 채워야 함
{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "여기에 배포된 Storage Account 연결 문자열 복사",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet"
  }
}

7. 마무리

ARM 템플릿의 핵심 개념은 "인프라도 코드다 (Infrastructure as Code)" 입니다.

서버, 스토리지, 네트워크 같은 인프라를 사람이 손으로 클릭하는 대신, 코드로 정의하고 버전 관리하고 자동화하는 것입니다.

처음에는 JSON 구조가 낯설게 느껴질 수 있지만, 한 번 익숙해지면 환경을 새로 세팅하거나 팀원과 동일한 환경을 공유하는 게 훨씬 쉬워집니다.

다음 단계로 추천하는 것들:

• Bicep — ARM 템플릿을 더 간결한 문법으로 작성할 수 있는 Azure 전용 언어
• Azure DevOps 또는 GitHub Actions와 연동해서 배포 자동화 파이프라인 구성
• Azure Key Vault 연동으로 민감 정보 안전하게 관리

이 글이 도움이 됐다면 좋아요와 댓글로 알려주세요! 잘못된 내용이나 추가했으면 하는 내용도 편하게 남겨주시면 반영하겠습니다.

읽은 날짜: 2026-05-01

[Day 1] 전체 구조

• 문제:
• 데이터:
• 결론:

[Day 2] 배경

• 기존 방법의 문제:
• 이 논문이 새롭게 하는 것:

[Day 3] 데이터/방법

• 데이터 출처:
• 주요 변수:
• 전처리:

[Day 4] 결과/논의

• 주요 결과:
• 한계:
• 앞으로 필요한 연구:

[Day 5] 내 생각

• 한 문단 요약:
• 내 관심사와의 연결:
• 궁금증:

Numpy, Pandas

Numpy: 고성능 수치 계산용. (Pandas의 뿌리!) Pandas: 표(DataFrame) 형태로 데이터를 자유자재로 요리하는 도구.

Matplotlib, Seaborn

Matplotlib: 파이썬 시각화의 기본. (커스터마이징 자유도가 높음) Seaborn: Matplotlib을 기반으로 더 예쁘고 복잡한 통계 차트를 쉽게 그려줌.

Folium

'지리 데이터(Geo)' 특화 도구

웹크롤링

requests, BeautifulSoup

정적 크롤링 (가볍고 빠름) requests: 웹 서버에 데이터를 달라고 요청하는 배달원. BeautifulSoup: 받아온 HTML 뭉치에서 원하는 정보만 쏙쏙 뽑아주는 집게.

selenium

동적 크롤링 (느리지만 강력함) Selenium: 브라우저를 직접 조종하는 아바타. (로그인, 클릭, 무한 스크롤 등 사람의 행동이 필요할 때 사용)

[Microsoft] Power Automate

PostgreSQL

DBeaver

[Azure] Machine Learning

[데이터 주고 받는 기술]

• Webhook 특정 이벤트가 발생했을 때 자동으로 지정된 URL로 데이터를 전송하는 프로세스 ex) power automate에서 팀즈 웹후크를 이용해 함수 실행마다 팀즈 채널에 메세지 보내기 우리가 팀즈의 http post url에 전송하는 거임.

• REST API 인터넷 주소(URL)를 통해 서버에 데이터를 요청하거나 수정하는 가장 대중적인 방식

[Azure] Function App

서버리스 환경에서 API 호출 로직을 구현

• 로그 확인법

1. remote: azure portal > azure function app > 모니터링 > 로그 > traces 테이블 실행
2. local: 커멘드창에서 azurite start > 터미널에 'func start' 실행 > 터미널에서 로그 출력 ※ remote <-> local로 환경설정을 바꿨을 때, 주피터 노트북 사용 시에는 restart를 해야 환경설정의 변경사항이 적용이 됨.

[Azure] Event Hubs

실시간으로 쏟아지는 방대한 데이터를 유실 없이 받아내고 순서대로 보관하는 '대용량 데이터 입구'.

뒷단(Stream Analytics 등)에서 데이터를 처리하기 전까지 안전하게 지켜주는 완충 작용(Buffer)을 함. Event Hubs가 없다면? 센서에서 데이터가 빗발칠 때 뒷단이 조금이라도 느려지면 데이터가 그대로 사라져 버림.

[IoT 센서/웹후크] → (데이터 발송) → [Event Hubs] → (데이터 보관) → [Stream Analytics] → (SQL로 분석) → [Power BI]

Azure Schema Registry

데이터가 어떤 모양이어야 하는지 적힌 '표준 설계도'를 보관하고 관리하는 저장소 별도의 리소스(보통은 Azure Event Hubs namespace 안에 포함됨)로 존재

• 작동 방식:

1. 보내는 쪽이 데이터를 보내기 전에 Schema Registry에서 "나 이 설계도(ID)대로 보낼게"라고 등록합니다.

2. 데이터에는 설계도 자체가 아니라 '설계도 번호(ID)'만 살짝 붙여서 보냅니다. (데이터 크기가 줄어듭니다!)

3. 받는 쪽은 데이터에 붙은 ID를 보고 Schema Registry에서 설계도를 찾아와 데이터를 정확하게 해석합니다.

Azure Event Hubs Capture

Event Hubs로 들어오는 실시간 데이터를 설정된 시간이나 용량 단위로 묶어서 자동으로 Azure Storage(Blob/Data Lake)에 저장해주는 기능 = 코딩 없이 원본 데이터를 즉시 저장소에 백업하는 기능

왜 필요한가? ** Event Hubs는 자체적으로 '데이터를 전송하는 능력'이 거의 없어서** 다른 곳으로 보내려면 이 설정을 켜줘야함.

[Azure] Stream Analytics

하나 또는 여러 개의 input을 받아 실시간 스트림 데이터와 참고용 데이터를 쿼리로 결합하고(SQL 쿼리로 데이터를 가공), 가공된 데이터를 목적에 맞게 여러 곳(Output)으로 분기하여 전송.

✅ 핵심 요약

• 다중 입출력: 입력 소스들을 JOIN(결합)하여 분석하고, 결과물을 실시간 대시보드나 DB 등 여러 저장소로 동시에 보낼 수 있음.

• 시간의 기준: 데이터가 시스템에 도착한 시간이 아닌, 현장에서 실제로 발생한 시간을 기준으로 처리할 것.

  Tip: 쿼리 작성 시 TIMESTAMP BY 문구를 사용하여 발생 시간을 명시해주는 것이 정확한 분석의 핵심!

[Microsoft] PowerBI

Stream Analytics에 output으로 연결하면 별도의 새로고침 없이도 신규 데이터가 즉각 반영되는 실시간 시각화 보드를 구현할 수 있음.

• Stream Analytics에 연결하는 법

[Azure] Cosmos DB

데이터를 임베딩 모델에 통과시켜 벡터로 바꾼 후 (벡터 검색이 필요한 경우에만) cosmos DB에 전달하면

1. 자동으로 인덱싱
2. 나중에 질문이 들어왔을 때 우리가 정한 Distance Function을 써서 관련 데이터를 빠르게 찾아줌.

• 설정> 기능 Vector Search for NoSQL API :벡터 검색이 필요한 경우 '켜기'

• 비용관리 모델 택1 RU/s(요청 단위): 처리량을 미리 예측하고 예약. 지속적이고 예측 가능한 트래픽에 최적. 서버리스: 사용한 만큼만 지출. 간헐적이거나 예측 불가능한 트래픽에 최적.

• 내부 계층 cosmosDB 계정(리소스 그룹 내부)> DB> container

[Microsoft] Foundry

<아직 실습 중>

Gradio

파이썬으로 웹 UI를 만들 수 있음. 제공해주는 컴포넌트 사용법만 알면 됨.

NL2SQL

자연어를 SQL로 바꿔줌.

[Azure] Azure OpenAI

AI 모델을 제공.

대체품

• 사용 한도 내에서 무료인 LLM API 제공 서비스

  Groq	Github	Google AI Studio

• 충분한 GPU가 있다면 로컬 LLM 도구를 설치

  Ollama	LM Studio

Azure 서비스를 대체할 오픈소스

Azure Event Hubs > Apache Kafka

대용량의 실시간 스트리밍 데이터를 안정적으로 수집하고 전달하는 분산 메시징 시스템

Azure Stream Analytics > Apache Flink

실시간으로 스트리밍 데이터를 처리하고 분석하는 분석 스트림 처리 프레임워크

Azure Cosmos DB > Elasticsearch

처리된 데이터를 저장, 검색하고, 머신러닝 모델을 통합하는 검색 엔진

[Azure] Azure Data Factory

Document Intelligence Studio

단일 서비스 리소스로 독립 생성이 가능. 최근에는 Azure AI Foundry (Foundry Tools) 산하로 편입되는 방향으로 가고 있음.

OCR / 문서처리

• OCR/Read 손글씨도 인식하는데 단어 순서를 반대로 추출하기로 함... 가장 기본적인 text 추출

• Layout 테이블, figure(그래프), 체크박스도 추출해줌.

• General documents 신청서 같은 서류에서 key-value pair와 그냥 문장 덩어리를 추출함.

  prebuilt model

• Invoices Query fields로 field 추가하면 더 잘 인식함.

  +a

Azure AI Language Studio

https://language.cognitive.azure.com/home 지역별로 제공 여부가 다르고 East US의 경우 모든 서비스를 제공

• 정보 추출: 비구조화된 텍스트에서 범주 그룹에 속하는 개체를 추출해줌. NER(Named Entity Recognition)

• 텍스트 분류: 텍스트의 언어를 감지하거나 감정 분류

  • 고객 감정 분석
  • 자동으로 텍스트 분류: 사용자 지정 텍스트 분류, 언어 감지

• 질문과 대화형 언어 이해

  • 고객 쿼리에 응답 QnA: 사용자 지정 질문 답변
    • 대화형 환경 구축: 대화 언어 이해

• 텍스트 요약

• 번역

대상 독자: Azure ML을 처음 접하는 분, 머신러닝 실습 환경 구축이 처음인 분
사전 조건: Azure 계정 또는 실습용 계정 보유

📋 목차

1. Azure Portal 접속 및 로그인
2. 리소스 그룹 선택
3. Azure Machine Learning 리소스 생성
4. ML 스튜디오 시작
5. 데이터셋 등록
6. 컴퓨트 인스턴스 생성

1. Azure Portal 접속 및 로그인

1-1. 포털 접속

1. 구글에서 "Azure Portal" 을 검색하거나, 주소창에 portal.azure.com을 직접 입력합니다.
2. 로그인 버튼을 클릭하여 본인 계정으로 로그인합니다.
   • 수업/실습용으로 배포받은 계정이 있다면 해당 계정을 사용합니다.
   • 계정이 없다면 "무료 체험 시작하기" 를 통해 체험 계정을 만들 수 있습니다.

💡 첫 로그인 시 주의: 실습 계정으로 처음 로그인하는 경우, 모바일 기기에 Microsoft Authenticator 앱을 설치하고 2단계 인증(2-Factor Authentication)을 완료해야 합니다. Google Play 또는 App Store에서 "Microsoft Authenticator"를 검색하여 설치하세요.

2. 리소스 그룹 선택

리소스 그룹은 Azure에서 관련된 리소스들을 하나로 묶어 관리하는 단위입니다. 실습 후 삭제할 때 리소스 그룹만 삭제하면 됨.

2-1. 리소스 그룹으로 이동

1. Azure Portal 메인 화면에서 상단 "Azure 서비스" 영역의 "리소스 그룹" 아이콘을 클릭합니다.

2. 리소스 그룹 만들기 리소스 그룹 이름은 자유롭게 짓고, 지역은 한국 외 다른 지역을 해도 상관없음.

3. 검색 결과에서 본인의 리소스 그룹을 클릭하여 선택합니다.

3. Azure Machine Learning 리소스 생성

이제 본격적으로 머신러닝 작업을 수행할 Azure Machine Learning 워크스페이스를 만듭니다.

3-1. 리소스 만들기 시작

1. 선택한 리소스 그룹의 "+ 만들기" 버튼을 클릭합니다.

2. Marketplace 검색창에 "기계 학습" 또는 "machine learning" 을 입력하고 검색합니다. 검색 결과 중 "Azure Machine Learning" (Microsoft 제공)을 선택합니다.

3-2. 워크스페이스 세부 정보 입력

1. 기본(Basic) 탭에서 아래 항목을 입력합니다.

   💡 이름 규칙: 이름은 A000-xxxxxxx 또는 B000-xxxxxxx 형태로 지정하세요. 스토리지 계정, 키 자격 증명 모음 등 부속 리소스들은 워크스페이스 이름에 따라 자동으로 생성됩니다.

2. 하단의 "검토 + 만들기" 버튼을 클릭합니다.

3-3. 유효성 검사 및 배포

1. 유효성 검사가 통과되면 "✅ 유효성 검사 통과" 메시지를 확인합니다.

2. 화면 하단의 "만들기" 버튼을 클릭합니다.

3. 배포가 시작되며, "배포 진행 중..." 화면이 표시됩니다. 완료까지 수 분 정도 소요됩니다.

📌 배포(Deployment)란? 개발 환경에서 설정한 리소스를 실제로 사용할 수 있는 환경(제품 환경)으로 생성해 주는 과정입니다.

4. "배포가 완료됨" 메시지가 나타나면, 화면 하단의 "리소스로 이동" 버튼을 클릭합니다.

4. ML 스튜디오 시작

Azure Machine Learning Studio는 머신러닝 작업을 수행하기 위한 종합 웹 포털입니다.

1. 리소스 개요 화면 중앙 하단의 "Studio 시작하기" 버튼을 클릭합니다.

💡 ML 스튜디오에서 할 수 있는 것들

• Notebooks: Python 코드로 직접 머신러닝 구현
• Automated ML: 머신러닝을 자동으로 구현
• Designer: 드래그-앤-드롭 방식으로 머신러닝 파이프라인 구현 -> 우리가 할 것

5. 데이터셋 등록

머신러닝 작업을 시작하기 전에, 분석할 데이터를 클라우드 환경에 업로드해야 합니다.

5-1. 데이터 메뉴 접근

1. ML 스튜디오 좌측 네비게이션 메뉴에서 "Data" 를 클릭합니다.
2. "+ Create" 버튼을 클릭하여 데이터 자산 생성을 시작합니다.

5-2. 데이터 타입 설정 (Data type)

1. 이름(Name) 을 입력합니다.
   • 예: Automobile_price_data
   • ⚠️ 개인 정보가 유추될 수 있는 이름은 사용하지 마세요.
2. Description에 데이터에 대한 간략한 설명을 입력합니다. (예: 자동차 가격 데이터)
3. Type은 "Tabular" 를 선택합니다. (데이터를 표 형식으로 표현)
4. "Next" 버튼을 클릭합니다.

5-3. 데이터 소스 선택 (Data source)

1. 데이터를 가져올 소스를 선택하는 화면에서 "From local files" 를 선택합니다.
2. "Next" 버튼을 클릭합니다.

5-4. 저장소 타입 선택 (Destination storage type)

1. Datastore type은 "Azure Blob Storage" 로 유지합니다.
2. 목록에서 "workspaceblobstore" 가 선택된 상태를 확인합니다.
   • Blob Storage는 대량의 비정형 데이터를 저장하는 데 특화된 저장소입니다. (Blob = Binary Large OBject)
3. "Next" 버튼을 클릭합니다.

5-5. 파일 업로드 (File or folder selection)

1. "Upload files or folder" 드롭다운을 클릭하고 "Upload files" 를 선택합니다.
2. 로컬 PC에서 업로드할 데이터 파일(imports-85.data.csv)을 찾아 선택합니다.
3. 파일 업로드가 완료되면 "Next" 버튼을 클릭합니다.

5-6. 세팅 확인 (Settings)

업로드된 파일의 파싱 설정을 확인합니다.

화면 하단의 미리보기 표에서 데이터가 올바르게 파싱되는지 확인 후 "Next" 를 클릭합니다.

5-7. 스키마 확인 (Schema)

컬럼별 데이터 타입을 확인합니다. 자동으로 감지된 타입을 검토하고 필요 시 수정합니다.

• String: 문자 데이터
• Integer: 정수 데이터
• Decimal dot: 실수 데이터
• Boolean: 논리(참/거짓) 데이터

"Next" 버튼을 클릭합니다.

5-8. 최종 검토 및 생성 (Review)

지금까지 입력한 모든 설정 정보를 최종 검토합니다.

• 이상이 없으면 "Create" 버튼을 클릭합니다.

6. 컴퓨트 인스턴스 생성

컴퓨트 대상(Compute Target) 은 머신러닝 모델을 학습시킬 때 실제로 연산을 수행하는 컴퓨팅 자원입니다. 실습에서는 가상 머신처럼 사용할 수 있는 컴퓨팅 인스턴스를 생성합니다.

6-1. 컴퓨트 메뉴 접근

1. ML 스튜디오 좌측 네비게이션 메뉴 하단 "Manage" 섹션에서 "Compute" 를 클릭합니다.
2. 상단 탭에서 "Compute instances" 가 선택된 상태를 확인합니다.
3. "+ New" 버튼을 클릭합니다.

6-2. 컴퓨트 인스턴스 세부 설정

1. Compute name 을 입력합니다.

   • 예: A000Compute1
   • Azure 데이터센터 전체에서 고유한 이름이어야 합니다.
   • ⚠️ 이름의 마지막을 - 또는 -숫자 형태로 끝내면 안 됩니다.

2. Virtual machine type 은 "CPU" 를 선택합니다.

3. Virtual machine size 에서 사용할 VM 사양을 선택합니다.

   • 실습 권장 사양: 2 cores짜리 아무거나

4. "Review + Create" 버튼을 클릭합니다.
5. 생성에 몇 분 정도 소요됩니다.

6-3. 생성 완료 확인

Compute 목록 화면에서 Status가 "Creating" → "Running" 으로 변경되면 정상적으로 생성된 것입니다.

💡 비용 절감 팁: 컴퓨팅 인스턴스는 실행 중일 때 비용이 발생합니다. 실습이 끝나면 Stop 버튼을 눌러 인스턴스를 중지하는 습관을 들이세요. 기본 설정으로 60분 비활성 시 자동 종료가 활성화되어 있습니다.

이제 머신러닝 디자이너(Designer) 를 열고 본격적인 실습을 시작할 준비가 완료된 것입니다! 🎉

📝 다음 포스팅 예고: Azure ML 디자이너로 파이프라인 구축 가이드라인

얼리버드로 신청했는데 덕분에 서류는 면제되었고 구글폼으로 이 두 가지만 제출하면 됐다.

17. 근무지/재직기간/업무내용 등 자유롭게 작성하여 주시기 바랍니다.
18. 자기소개 및 지원동기를 자유롭게 작성하여 주시기 바랍니다.

이 내용을 바탕으로 질문 안함. 그냥 참고만 하시는 듯.

기초역량 테스트

면접 대기 중에는 기초역량 테스트 링크를 주는데 파이썬 기본 문법 물어봄 (합격이랑 관계 없음) ex) 수정이 안되는 자료형은? 튜플

면접

면접 난이도는 별로 안높았음. 다른 면접 후기들에서 나와있는 것과 동일한 질문을 함. Teams 온라인 면접이고 면접관님 23명에 질문은 한분만 하시고 동시에 면접을 본 인원은 2명(둘 다 합격). 다른 분들은 34명이서 본 팀도 있다고 했다.

면접 질문

• 지원동기
• 팀플 시 가장 힘든 부분과 해결방법: 제출한 내용보니까 하고 싶은게 좀 뚜렷한 편이신 것 같던데 만약 별로 하고 싶지 않은 주제를 해야하거나 팀플에서 갈등이 생기면 어떻게 할거에요? (팀플 하다가 그만두고 나간 케이스가 있어서 방지하기 위해 팀플에서 갈등이 있어도 해결하려는 의지가 있는 인성의 소유자인지 확인하는 질문) (농업, 해양 생태계, 야생동물 이런거 하고 싶다고 적었더니 하고 싶은게 뚜렷하다고 말씀하신듯)
• 기본적인 IT 관련 질문 1개: 클라우드 컴퓨팅이란 무엇인가요? 클라우드란? (우리팀은 두명이라 같은 질문으로 답했는데 여러명인 팀은 질문을 다르게 준다고) (같이 면접 본 분은 대답 잘 못했는데 합격하심)
• 개발 경험 있는지? (웹 프론트, 안드로이드 앱, 데이터 분석용 파이썬 등과 기본 SC 강의를 수강한 적 있다고 말함)
• 부캠이 끝나고 어떤걸 할건지 미래계획? (4학년이 남아서 학교를 마저 다니고 부캠에서 배운걸 바탕으로 캡스톤을 잘 마무리하고 바로 취업할 수 있도록 하겠다고 답함. 다른 교육을 더 듣는다던지 그런 답변은 안해야 함.)

About me

참고로 나는 반(半)전공자(전공자이긴한데 산업공학 계열이라 애매해서)로 3학년 수료 후 휴학하고 지원했고 20대 중반에 경력도 없었음.

나중에 합격자들과 대화를 나눠보니 비전공자 분들도 있으시고 경력자도 있고 나처럼 휴학생들도 있었다.

얼리버드 기준으로 면접 대기자 방에 100명이 넘었다는데 Data school이 30명 가량 되니까 AI, Data school 다 합쳐서 60명 정도 된다고 가정했을 때 떨어진 사람이 절반은 된다는게 믿기지 않았다. 왜냐면 면접도 쉽고 코테도 안보니까... 그리고 나도 그렇게 면접을 잘봤다고 생각하지는 않는데(누구나 할법한 식상한 말만 했음..) 내가 합격했길래 지원하면 다 붙는줄 알았는데 그게 아닌게 놀라웠다.

더 궁금한 내용은 댓글 남겨주시면 추가해보겠습니다 끝

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 방식의 코딩 습관을 유지합시다!