RFC 3339 형식이란?
좋은 질문입니다!
RFC 3339 형식은 날짜와 시간을 표준적으로 표현하는 규칙입니다.
아주 많이 쓰이기 때문에 확실히 이해해두면 유용합니다.
🎯 RFC 3339 형식이란?
RFC 3339는 날짜(Date)와 시간(Time)를 표기하는 공식 표준 포맷입니다.
ISO 8601 포맷을 기반으로 하되,
컴퓨터 시스템/네트워크용으로 조금 더 엄격하게 규정된 형태입니다.
주로
- API 통신 (REST API, GraphQL)
- 로그 기록 (Cloud Logging, Databases)
- 타임스탬프 저장 (BigQuery, PostgreSQL)
에서 RFC3339 형식이 기본입니다.
📚 기본 포맷
YYYY-MM-DDTHH:MM:SSZ
또는
YYYY-MM-DDTHH:MM:SS±hh:mm
| 요소 | 의미 |
|---|---|
YYYY |
연도 (Year) |
MM |
월 (Month) |
DD |
일 (Day) |
T |
날짜와 시간 구분자 (고정) |
HH |
시 (Hour, 24시간제) |
MM |
분 (Minute) |
SS |
초 (Second) |
Z |
UTC 기준 시간 (Z는 “Zulu Time” = UTC) |
±hh:mm |
UTC로부터의 오프셋 (Time zone 차이) |
🎯 예시
| 타입 | 예시 | 설명 |
|---|---|---|
| UTC 기준 | 2025-04-29T08:30:00Z |
2025년 4월 29일 08:30 (UTC) |
| 한국시간 (KST, UTC+9) | 2025-04-29T17:30:00+09:00 |
같은 시각, 한국 기준 |
| 다른 타임존 | 2025-04-29T02:30:00-06:00 |
UTC-6 지역 기준 |
📦 주의할 점
-
T는 꼭 있어야 합니다. (날짜와 시간 구분자)
Avro 파일 형식이란?
좋습니다!
Avro 파일 포맷에 대해 정확하고 쉽게 설명드릴게요.
🎯 Avro 파일 형식이란?
Apache Avro는 데이터를 효율적으로 저장하고 전송하기 위한
바이너리 기반의 파일 포맷입니다.
주로 빅데이터 시스템(예: Hadoop, Kafka, BigQuery 등)에서 많이 사용됩니다.
📦 Avro의 주요 특징
| 항목 | 설명 |
|---|---|
| Schema 기반 | 파일 안에 **데이터 구조(Schema)**를 함께 저장 |
| 바이너리 형식 | 사람 눈에는 안 보이는 이진 데이터로 저장 → 빠르고 작음 |
| Self-describing | 파일 안에 Schema가 들어있어서 따로 설명서 없이 읽을 수 있음 |
| 빠른 읽기/쓰기 | 고속 직렬화/역직렬화 (serialization/deserialization) 가능 |
| 언어 독립성 | Java, Python, C++, Go 등 다양한 언어에서 읽고 쓸 수 있음 |
🎯 Avro 파일 구조 (간단)
[ 파일 헤더 (magic bytes + metadata + schema) ]
[ 데이터 블록 1 ]
[ 데이터 블록 2 ]
[ ... ]
- Header: Schema와 metadata가 들어 있음
- Block: 실제 레코드 데이터가 저장되어 있음
🎯 Schema 예시 (JSON 형식)
Avro Schema는 JSON 포맷으로 작성됩니다. 예를 들면:
One-hot Encoding이란?
좋습니다, 간단하고 확실하게 정리해드릴게요!
🎯 One-hot Encoding이란?
One-hot Encoding은
범주형 데이터(categorical data)를 수치형 벡터로 변환하는 기법입니다.
특징:
- 각 범주(category)는 고유한 벡터로 표현됩니다.
- 이 벡터는 대부분 0이고, 해당하는 범주 위치만 1입니다.
예시
예를 들어, “과일” 데이터가 있다고 해볼게요:
| 과일 | |
|---|---|
| 사과 | |
| 바나나 | |
| 포도 |
이를 one-hot encoding하면:
| 과일 | One-hot Encoding |
|---|---|
| 사과 | [1, 0, 0] |
| 바나나 | [0, 1, 0] |
| 포도 | [0, 0, 1] |
- 사과는 첫 번째 칸만 1
- 바나나는 두 번째 칸만 1
- 포도는 세 번째 칸만 1
왜 필요한가요?
- 모델(특히 신경망) 은 수치 입력만 처리할 수 있습니다.
- 범주형 데이터를 고유 숫자로 변환하면 모델이 **“수치 간 크기 비교”**를 할 수 있다고 잘못 해석할 수 있습니다.
- One-hot은 이런 왜곡 없이 범주 간 평등한 거리를 유지시켜줍니다.
PyTorch / TensorFlow 코드 예시
Python 코드 (간단하게)
Adaptive Layers란?
좋은 질문입니다!
“Adaptive Layers” 를 깔끔하게 설명해드릴게요.
Adaptive Layers란?
Adaptive Layers는
학습이나 추론 과정에서, 모델이 자동으로 “특정 층(layer)“을 조정하거나 최적화하는 구조를 뜻합니다.
쉽게 말하면,
모델이 상황에 따라 필요한 층만 사용하거나,
가중치(weight)를 조절하거나,
특정 레이어만 업데이트하는 식으로 유연하게(adaptive) 작동한다는 거예요.
어디에 사용되나요?
- Transfer Learning (전이 학습)
- Fine-Tuning (미세 조정)
- Parameter-Efficient Tuning (예: LoRA, Adapter)
- Large Language Models (LLMs) 의 경량화 튜닝
Adaptive Layers의 주요 개념
| 개념 | 설명 |
|---|---|
| Layer Freezing | 기존 모델의 대부분 레이어는 “고정(freeze)“하고, 일부 레이어만 “학습(adapt)“하게 함. |
| Adapter Layers | 기존 모델 사이사이에 “얇은” 적응 레이어를 끼워서 학습량을 줄이는 방법. |
| LoRA (Low-Rank Adaptation) | 기존 큰 가중치 행렬을 작은 행렬로 근사해서 적응시키는 방법. |
| Routing | 입력에 따라 다른 레이어를 동적으로 선택하는 방법. (예: Mixture of Experts) |
예시 1: Transfer Learning에서의 Adaptive Layers
- 예를 들어, 큰 모델(BERT 등)을 가져와서,
- 초반 레이어는 고정시키고,
- 마지막 몇 개 레이어만 새 데이터에 맞게 조정할 수 있습니다.
- 이때 마지막 몇 개 층이 Adaptive Layers처럼 작동하는 거죠.
예시 2: Adapter Layers (구체적)
- 기존 모델의 모든 가중치를 그대로 둔 채,
- 중간중간에 작은 Adapter Layer를 삽입합니다.
- 학습은 Adapter Layer만 합니다.
- 이렇게 하면 모델을 가볍고 빠르게 튜닝할 수 있습니다.

context drift
아주 좋은 질문입니다.
이런 현상은 “drift” 또는 특히 “context drift” 혹은 “attention drift” 라고 부릅니다.
구체적으로 설명하면:
- LLM (대규모 언어 모델) 은 대화가 길어질수록,
- 초기에 설정된 목표나 톤, 문맥을 점점 잃어버리는 경향이 있습니다.
- 처음과 끝은 비교적 집중이 잘 되어 있지만,
중간부에서는 일관성 부족 또는 품질 저하가 발생할 수 있습니다.
이런 문제를 가리켜:
| 용어 | 의미 |
|---|---|
| context drift | 대화 문맥이 점차 흐트러지거나 변질되는 현상 |
| attention drift | 모델이 초반 초점에서 점차 다른 주제나 스타일로 주의가 흐트러지는 현상 |
| generation degradation | 긴 응답/대화 세션에서 점차 품질이 저하되는 일반적인 현상 |
왜 이런 현상이 생기나?
- LLM은 “현재까지의 입력” 만을 보고 매번 다음 토큰을 예측합니다.
- 대화가 길어질수록 초기 정보(시작 컨텍스트) 의 영향력이 줄어들 수 있습니다.
- 또한 메모리 한계(컨텍스트 윈도우 크기) 때문에,
과거 정보가 부분적으로 잘리거나 희석되면서 drift가 심해집니다.
예시
- 초반: 주제를 정확히 따라감
- 중간: 세부 정보가 틀리거나, 약간 다른 방향으로 새어 나감
- 끝: 마무리할 때 다시 처음 목표로 끌어오는 경향이 있음
정리
장시간 LLM 사용 시, 중간에 응답 품질이 떨어지는 현상은
“Context Drift”, “Attention Drift”, 또는 포괄적으로 “Generation Degradation” 이라고 부릅니다.
RMSE
좋아요!
RMSE에 대해 추가로 자세히 설명해드릴게요:
RMSE란?
- RMSE는 Root Mean Squared Error의 약자입니다.
- “평균 제곱 오차의 제곱근” 을 뜻합니다.
- 쉽게 말하면, 모델이 예측한 값과 실제 값 사이의 오차(틀린 정도) 를 숫자 하나로 요약한 지표입니다.
왜 쓰나요?
- RMSE는 오차가 클수록 벌점이 커지게 설계되어 있어서,
예측이 많이 틀린 경우를 민감하게 감지할 수 있습니다. - 그래서 정확한 모델을 만들고 싶을 때 RMSE를 줄이는 걸 목표로 합니다.
수식 (조금 수학적으로 보면)
[ \text{RMSE} = \sqrt{ \frac{1}{n} \sum_{i=1}^{n} (예측값_i - 실제값_i)^2 } ]
서브넷 계산하는 방법
좋은 질문이에요! 서브넷을 계산하는 방법은 네트워크 설계의 핵심이고, 이해해두면 IP 계획할 때 정말 유용합니다.
🧮 서브넷 계산 방법 요약
1️⃣ 기본 개념
- IP 주소는 32비트 (IPv4 기준)
- 서브넷 마스크는 IP 주소 중에서 네트워크/호스트 구분을 위한 비트 수를 나타냄
예:/24→ 상위 24비트는 네트워크, 나머지 8비트는 호스트
2️⃣ 공식
✅ 서브넷당 IP 수 = 2^(32 - 서브넷 비트 수)
- 예:
/24→2^(32-24) = 2^8 = 256개 IP
그중 2개는 항상 예약됨:
GCP + GKE
gcloud config set project
gcloud config set compute/region
gcloud config set compute/zone
export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)
gcloud container clusters create fancy-prod-268 --num-nodes 3
gcloud compute instances list
gcloud services enable cloudbuild.googleapis.com
# build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-220:1.0.0 .
# deploy
kubectl create deployment fancy-monolith-220 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-220:1.0.0
# check
kubectl get all
# Show pods
kubectl get pods
# Show deployments
kubectl get deployments
# Show replica sets
kubectl get rs
#You can also combine them
kubectl get pods,deployments
kubectl get services
# delete
kubectl delete pod/<POD_NAME>
# expose
kubectl expose deployment fancy-monolith-220 --type=LoadBalancer --port 80 --target-port 8080
# Accessing the service
kubectl get service
~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-430:1.0.0 .
kubectl create deployment fancy-orders-430 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-430:1.0.0
kubectl expose deployment fancy-orders-430 --type=LoadBalancer --port 80 --target-port 8081
~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-721:1.0.0 .
kubectl delete deployment fancy-products-721
kubectl create deployment fancy-products-721 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products-721:1.0.0
kubectl expose deployment fancy-products-721 --type=LoadBalancer --port 80 --target-port 8082
~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-189:1.0.0 .
kubectl create deployment fancy-frontend-189 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-189:1.0.0
kubectl expose deployment fancy-frontend-189 --type=LoadBalancer --port 80 --target-port 8080
------------------
# scale
kubectl scale deployment monolith --replicas=3
kubectl get all
# Make changes to the website
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
# Update website with zero downtime
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
kubectl get pods
# delete
# Delete the container image for version 1.0.0 of the monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --quiet
# Delete the container image for version 2.0.0 of the monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --quiet
# The following command will take all source archives from all builds and delete them from cloud storage
# Run this command to print all sources:
# gcloud builds list | awk 'NR > 1 {print $4}'
gcloud builds list | grep 'SOURCE' | cut -d ' ' -f2 | while read line; do gsutil rm $line; done
kubectl delete service monolith
kubectl delete deployment monolith
gcloud container clusters delete fancy-cluster lab region
GCP Website Make
# App Build & Docker Deploy
# artifactregistry Repository
gcloud auth configure-docker us-east1-docker.pkg.dev
gcloud services enable artifactregistry.googleapis.com \
cloudbuild.googleapis.com \
run.googleapis.com
# Submit
gcloud builds submit --tag us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0
# Cloud Build 에서 진행상태 볼 수 있다.
# Deploy Container
gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1
# check
gcloud run services list
# Create new revision with lower concurrency ??
gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1 --concurrency 1
gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1 --concurrency 80
# Cloud Run에서 확인가능
# node module 지우고 올리기
cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/
# 인스턴스 만들기
gcloud compute instances create backend \
--zone=$ZONE \
--machine-type=e2-standard-2 \
--tags=backend \
--metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh
# ip확인
gcloud compute instances list
# Firewall. 적용하고 3분 기다려야 된다.
gcloud compute firewall-rules create fw-fe \
--allow tcp:8080 \
--target-tags=frontend
gcloud compute firewall-rules create fw-be \
--allow tcp:8081-8082 \
--target-tags=backend
# 끄고
gcloud compute instances stop frontend --zone=$ZONE
gcloud compute instances stop backend --zone=$ZONE
# 인스턴스를 템플릿으로 만든다.
gcloud compute instance-templates create fancy-fe \
--source-instance-zone=$ZONE \
--source-instance=frontend
gcloud compute instance-templates create fancy-be \
--source-instance-zone=$ZONE \
--source-instance=backend
gcloud compute instance-templates list
# 기존의 것을 지우고
gcloud compute instances delete backend --zone=$ZONE
# managed 로 다시 만든다
gcloud compute instance-groups managed create fancy-fe-mig \
--zone=$ZONE \
--base-instance-name fancy-fe \
--size 2 \
--template fancy-fe
gcloud compute instance-groups managed create fancy-be-mig \
--zone=$ZONE \
--base-instance-name fancy-be \
--size 2 \
--template fancy-be
# set-named-port라는 명령이 있네
gcloud compute instance-groups set-named-ports fancy-fe-mig \
--zone=$ZONE \
--named-ports frontend:8080
gcloud compute instance-groups set-named-ports fancy-be-mig \
--zone=$ZONE \
--named-ports orders:8081,products:8082
# 핼스체크 추가
gcloud compute health-checks create http fancy-fe-hc \
--port 8080 \
--check-interval 30s \
--healthy-threshold 1 \
--timeout 10s \
--unhealthy-threshold 3
gcloud compute health-checks create http fancy-be-hc \
--port 8081 \
--request-path=/api/orders \
--check-interval 30s \
--healthy-threshold 1 \
--timeout 10s \
--unhealthy-threshold 3
gcloud compute firewall-rules create allow-health-check \
--allow tcp:8080-8081 \
--source-ranges 130.211.0.0/22,35.191.0.0/16 \
--network default
# 헬스체크한 뒤 업데이트 해야 하나 보다
gcloud compute instance-groups managed update fancy-fe-mig \
--zone=$ZONE \
--health-check fancy-fe-hc \
--initial-delay 300
gcloud compute instance-groups managed update fancy-be-mig \
--zone=$ZONE \
--health-check fancy-be-hc \
--initial-delay 300
# Create load balancers
gcloud compute http-health-checks create fancy-fe-frontend-hc \
--request-path / \
--port 8080
gcloud compute http-health-checks create fancy-be-orders-hc \
--request-path /api/orders \
--port 8081
gcloud compute http-health-checks create fancy-be-products-hc \
--request-path /api/products \
--port 8082
# 엥?
# Note: These health checks are for the load balancer, and only handle directing traffic from the load balancer; they do not cause the managed instance groups to recreate instances.
gcloud compute backend-services create fancy-fe-frontend \
--http-health-checks fancy-fe-frontend-hc \
--port-name frontend \
--global
gcloud compute backend-services create fancy-be-orders \
--http-health-checks fancy-be-orders-hc \
--port-name orders \
--global
gcloud compute backend-services create fancy-be-products \
--http-health-checks fancy-be-products-hc \
--port-name products \
--global
# 로드 밸런서도?... 이렇게 복잡하게 해야하는건가? 보다.
gcloud compute backend-services add-backend fancy-fe-frontend \
--instance-group-zone=$ZONE \
--instance-group fancy-fe-mig \
--global
gcloud compute backend-services add-backend fancy-be-orders \
--instance-group-zone=$ZONE \
--instance-group fancy-be-mig \
--global
gcloud compute backend-services add-backend fancy-be-products \
--instance-group-zone=$ZONE \
--instance-group fancy-be-mig \
--global
# Create a URL map. 악!
gcloud compute url-maps create fancy-map \
--default-service fancy-fe-frontend
# 아... 이건 Nginx에서 라우팅 하는 것 처럼 보인다.
#Create a path matcher to allow the /api/orders and /api/products paths to route to their respective services:
gcloud compute url-maps add-path-matcher fancy-map \
--default-service fancy-fe-frontend \
--path-matcher-name orders \
--path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"
# 맵을 만들고... 용어가 달라서 그렇군.
# Create the proxy which ties to the URL map:
gcloud compute target-http-proxies create fancy-proxy \
--url-map fancy-map
# 포워딩
# Create a global forwarding rule that ties a public IP address and port to the proxy:
gcloud compute forwarding-rules create fancy-http-rule \
--global \
--target-http-proxy fancy-proxy \
--ports 80
# Find the IP address for the Load Balancer:
gcloud compute forwarding-rules list --global
# ip가 바뀌었을테네.. .env 파일 바꿔준다. 음.. 이건 좀.
# 다시 빌드하고 다시 배포 한다.... 음.. .env를 안쓰면 되나? 거참.
cd ~/monolith-to-microservices/react-app
npm install && npm run-script build
cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/
gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \
--zone=$ZONE \
--max-unavailable 100%
# 체크
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global
# 스케일 변경
gcloud compute instance-groups managed set-autoscaling \
fancy-fe-mig \
--zone=$ZONE \
--max-num-replicas 2 \
--target-load-balancing-utilization 0.60
gcloud compute instance-groups managed set-autoscaling \
fancy-be-mig \
--zone=$ZONE \
--max-num-replicas 2 \
--target-load-balancing-utilization 0.60
# CDN...은 어떻게 설정되는지?
# Enable content delivery network
gcloud compute backend-services update fancy-fe-frontend \
--enable-cdn --global
# 인스턴스 사이즈 변경
gcloud compute instances set-machine-type frontend \
--zone=$ZONE \
--machine-type e2-small
gcloud compute instance-templates create fancy-fe-new \
--region=$REGION \
--source-instance=frontend \
--source-instance-zone=$ZONE
gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \
--zone=$ZONE \
--version template=fancy-fe-new
# 와치? 3분 정도 걸린다고 함.
watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \
--zone=$ZONE
gcloud compute instances describe [VM_NAME] --zone=$ZONE | grep machineType
# ssh
gcloud compute instance-groups list-instances fancy-fe-mig --zone=$ZONE
gcloud compute ssh [INSTANCE_NAME] --zone=$ZONE
console + data
gcloud config set project qwiklabs-gcp-02-806cc13914e8
gcloud config list project
bq show bigquery-public-data:samples.shakespeare
bq query --use_legacy_sql=false \
'SELECT
word,
SUM(word_count) AS count
FROM
`bigquery-public-data`.samples.shakespeare
WHERE
word LIKE "%raisin%"
GROUP BY
word'
Use the bq ls command to list any existing datasets in your project:
# 현재 내 dataset
bq ls
# 오픈 데이터셋
bq ls bigquery-public-data:
# make dataset
bq mk babynames
curl -LO http://www.ssa.gov/OACT/babynames/names.zip
unzip names.zip
# 스키마 지정해서 업로드
bq load babynames.names2010 yob2010.txt name:string,gender:string,count:integer
# 확인
bq show babynames.names2010
bq query "SELECT name,count FROM babynames.names2010 WHERE gender = 'F' ORDER BY count DESC LIMIT 5"
# 지우는 것도 가능
bq rm -r babynames
CVID-19 오픈 데이터 세트