개인 공부용.

MDM + CA 인증서를 활용한 기기 인증 구조

전체 구조 설명

핵심 개념

MDM(Jamf/Intune)은 기기 관리 플랫폼이고, CA 인증서는 그 기기가 "조직이 관리하는 진짜 기기"임을 증명하는 디지털 신분증입니다. 이 둘의 조합으로 "관리된 기기만 SaaS 접근 가능" 이라는 정책이 구현됩니다.

① 인증서 발급 흐름 (MDM → CA → 기기)

MDM이 기기에 인증서를 밀어 넣는 과정입니다.

Jamf (macOS/iOS): Configuration Profile에 SCEP Payload를 포함시켜 배포. 기기가 프로파일을 받으면 자동으로 Issuing CA에 인증서 요청(CSR) 전송 → 서명된 인증서를 키체인에 저장.

Intune (Windows/Android): SCEP Certificate Profile 또는 PKCS Certificate Profile 방식. Windows는 NDES(Network Device Enrollment Service)를 통해 Microsoft CA와 연동. Android는 Android Enterprise로 Work Profile에 인증서 격리.

인증서에는 CN=기기ID (또는 UPN), SAN, Issuing CA 서명, 만료일 등이 포함됩니다.

② CA 인증서 신뢰 체인 (Root → Issuing)

Root CA (오프라인, 최상위)
  └─ Issuing CA (온라인, 기기 인증서 서명)
       └─ 기기 인증서 (각 엔드포인트 1개씩)

IdP와 SaaS는 Root CA의 공개키만 신뢰 목록에 등록해두면, 그 하위에서 발급된 모든 기기 인증서를 자동으로 신뢰합니다.

③ SaaS 접근 시 인증서 검증 (mTLS / Certificate-Based Auth)

기기가 SaaS에 접근할 때 IdP(Entra ID, Okta 등)의 Conditional Access 정책이 개입합니다.

기기 → IdP: 클라이언트 인증서(TLS handshake)를 제시
IdP 검증 항목:
- 인증서 발급자가 신뢰하는 CA인가? (신뢰체인 확인)
- 인증서가 유효기간 내인가?
- CRL/OCSP에서 폐기되지 않았는가?
- 인증서의 CN/SAN이 해당 사용자/기기와 일치하는가?
검증 통과 → 액세스 토큰 발급 → SaaS 접근 허용

④ 미관리 기기 차단

인증서가 없는 개인 기기나 외부 기기는 클라이언트 인증서를 제시할 수 없으므로, Conditional Access 정책에서 TLS handshake 단계에서 차단됩니다. 아이디/패스워드를 알고 있어도 접근 불가.

Jamf vs Intune 비교

항목JamfMicrosoft Intune

주요 플랫폼	macOS, iOS	Windows, Android, iOS
인증서 프로토콜	SCEP	SCEP / PKCS#12
CA 연동	ADCS, 3rd-party CA	NDES + ADCS, PKCS
IdP 연동	Jamf Connect (Okta/Entra ID)	Entra ID 네이티브 통합
정책 엔진	Smart Groups + Config Profiles	Conditional Access 정책

Intune + Entra ID 조합은 M365 환경에서 가장 타이트하게 통합되고, Jamf는 macOS 관리 깊이가 더 뛰어나서 보통 혼용(Jamf for Mac, Intune for Windows)하는 구조가 많습니다.

'C.S. > Security' 카테고리의 다른 글

SECON 2026 의 SASE 및 유사기술 업체 목록 (0)	2026.03.12
AI 가 추천하는 SECON 2026 전시부스 15곳 (0)	2026.03.12
SECON 2026 양자보안 관련 업체 목록 (0)	2026.03.12
CA 서버, RA 서버 차이 (0)	2026.02.24
LDAP (Lightweight Directory Access Protocol) (0)	2026.01.13

LLM 통하여 검색한 내용 입니다.

원본 : https://developer.okta.com/docs/guides/terraform-landing-page/main/

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

Okta를 Terraform으로 관리하기

Okta 공식 개발자 문서(Automate org management with Terraform) 기반 정리

1. 왜 Terraform인가?

Admin Console에서 마우스로 클릭하던 모든 설정을 .tf 파일로 선언하는 방식으로 바꿉니다.

구분 기존 방식 (Admin Console) Terraform 방식

작업 방법	클릭 → 저장	코드 작성 → 검토 → 적용
변경 이력	추적 어려움	Git으로 관리
사전 확인	불가	terraform plan으로 미리 보기
반복 배포	수작업 반복	동일 코드 재사용
CI/CD 통합	불가	파이프라인 연동 가능

주의: Okta는 동일한 객체(그룹, 정책 등)를 Terraform과 Admin Console 양쪽에서 동시에 관리하지 않도록 권장합니다. 혼용 시 설정 충돌이 발생할 수 있습니다.

2. Okta Provider 구조

Terraform은 Provider 플러그인을 통해 Okta API를 호출합니다.

provider "okta" {
  org_name  = "my-company"
  base_url  = "okta.com"
  api_token = var.okta_api_token
}

Provider 안에는 두 종류의 컴포넌트가 있습니다.

Resource — 원하는 상태를 선언 (그룹 생성, 앱 등록, 정책 설정 등)
Data source — 현재 상태를 읽기 (기존 정책 조회, 그룹 ID 참조 등)

# Resource 예시: 그룹 생성
resource "okta_group" "engineers" {
  name        = "Engineers"
  description = "Engineering team"
}

# Data source 예시: 기존 정책 조회
data "okta_policy" "default_mfa" {
  name = "Default Policy"
  type = "MFA_ENROLL"
}

3. State 파일 동작 방식

Terraform은 terraform.tfstate 파일에 현재 Okta 조직 상태를 저장하고, 실행마다 이를 기준으로 변경 차이를 계산합니다.

코드 작성 → API 조회(현재 상태) → 차이 계산 → 변경 적용 → State 업데이트

권장 저장 위치: 로컬이 아닌 원격 저장소 (S3, Terraform Cloud 등)

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "okta/terraform.tfstate"
    region = "ap-northeast-2"
  }
}

원격 저장 시 버전 관리, 암호화, 팀 공유가 가능합니다.

4. 핵심 CLI 명령어 3가지

항상 아래 순서로 실행합니다.

terraform init

Provider 플러그인 다운로드 + 백엔드 초기화. 처음 한 번, 또는 Provider를 변경할 때 실행합니다.

terraform init

terraform plan

적용될 변경 사항 미리 보기. 실제로 아무것도 바꾸지 않으므로 안전하게 확인할 수 있습니다.

terraform plan

terraform apply

실제 변경을 Okta에 적용합니다. plan 결과 확인 후 yes를 입력합니다.

terraform apply

5. 자동화 가능한 영역

Okta 공식 문서 기준 4가지 핵심 영역입니다.

사용자 접근 관리

인증 정책, MFA 설정, 로그인 규칙을 코드로 자동화합니다.

resource "okta_policy_mfa" "default" {
  name   = "Default MFA Policy"
  status = "ACTIVE"
  okta_otp {
    enroll = "REQUIRED"
  }
}

그룹 관리

그룹 생성, 멤버 할당, 앱 접근 제어를 관리합니다.

resource "okta_group" "contractors" {
  name = "Contractors"
}

resource "okta_app_group_assignment" "contractors_app" {
  app_id   = okta_app_saml.my_app.id
  group_id = okta_group.contractors.id
}

외부 IdP 연동

SAML/OIDC 외부 Identity Provider를 등록합니다.

resource "okta_idp_saml" "google_workspace" {
  name                     = "Google Workspace"
  sso_url                  = "https://accounts.google.com/o/saml2/idp"
  sso_binding              = "HTTP-POST"
  audience                 = "https://www.okta.com/saml2/service-provider/..."
  issuer                   = "https://accounts.google.com"
  subject_match_type       = "EMAIL"
}

UX 커스터마이징

이메일 템플릿, 로그인 페이지 브랜딩을 관리합니다.

resource "okta_template_email" "welcome" {
  type = "email.welcome"
  translations {
    language = "ko"
    subject  = "환영합니다!"
    body     = "<html>...</html>"
  }
}

6. Best Practices

접근 권한 최소화

Terraform 전용 Service Account를 사용하고, 필요한 스코프만 부여합니다. API 토큰은 환경변수나 Secrets Manager로 관리합니다.

# 환경변수 방식
export OKTA_ORG_NAME="my-company"
export OKTA_BASE_URL="okta.com"
export OKTA_API_TOKEN="your_token_here"

# Vault 연동 방식 (권장)
data "vault_generic_secret" "okta" {
  path = "secret/okta"
}

provider "okta" {
  api_token = data.vault_generic_secret.okta.data["api_token"]
}

Rate limit 관리

Okta API는 분당 호출 제한이 있습니다. 리소스가 많을수록 한 번에 많은 API 호출이 발생하므로 커스텀 rate limit을 설정합니다.

파일 구조 분리

하나의 파일에 모든 리소스를 몰아넣지 말고 역할별로 분리합니다.

okta-terraform/
├── main.tf          # Provider 설정
├── variables.tf     # 변수 선언
├── outputs.tf       # 출력 값
├── groups.tf        # 그룹 관련 리소스
├── apps.tf          # 애플리케이션 리소스
├── policies.tf      # 정책 리소스
└── terraform.tfvars # 변수 값 (Git 제외)

Okta는 조직 하나당 configuration 하나를 사용하도록 권장합니다.

7. 시작하기

# 1. Terraform CLI 설치 (macOS)
brew install terraform

# 2. 작업 디렉토리 초기화
mkdir okta-terraform && cd okta-terraform

# 3. main.tf 작성 후 초기화
terraform init

# 4. 변경 사항 미리 확인
terraform plan

# 5. 실제 적용
terraform apply

참고 링크

'C.S.' 카테고리의 다른 글

NeRF (Neural Radiance Fields) (0)	2026.04.29
i18n (Internationalization) (0)	2026.04.29
SKT 6G 전략 및 보안 (ATHENA 백서) (0)	2026.03.05
K8s 의 node 조정 (0)	2026.02.01

개인 학습용. chatgpt 검색 내용.

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

Cloudflare란?

Cloudflare는
전 세계에 분산된 Edge Network를 기반으로

CDN
DNS
WAF
DDoS 방어
Bot 방어
Zero Trust
API 보호
Load Balancing

등을 제공하는 글로벌 보안 + 네트워크 플랫폼입니다.

쉽게 말하면

👉 “인터넷 앞단에서 서비스 보호 + 가속을 해주는 플랫폼”

입니다.

1. 어디에 위치하나

보통 구조는 이렇게 됩니다.

User
→ Cloudflare
→ Route53
→ ALB
→ EC2 / ECS / Origin Server

즉

Cloudflare가

👉 가장 앞단 (Internet Edge)

에 위치합니다.

모든 요청이 먼저 Cloudflare를 통과합니다.

2. 주요 역할

① CDN (Content Delivery Network)

정적 콘텐츠를 사용자 가까운 곳에서 제공

예:

이미지
CSS
JS
동영상 일부
정적 페이지

효과:

속도 향상
Origin 부하 감소
비용 절감

② DNS

빠르고 안정적인 DNS 서비스 제공

특징:

Anycast 기반
매우 빠른 응답
DDoS 강함

많은 회사가

Amazon Route 53 대신
혹은 함께 사용합니다.

③ WAF

웹 공격 방어

막는 것:

SQL Injection
XSS
RCE
Path Traversal
OWASP Top 10 공격

즉

👉 웹 보안 핵심

④ DDoS Protection

대규모 공격 방어

막는 것:

SYN Flood
UDP Flood
HTTP Flood
Layer 7 공격

Cloudflare의 대표 기능 중 하나

⑤ Bot Management

자동화 공격 방어

막는 것:

로그인 무차별 공격
Credential Stuffing
Scraping
Fake Signup
Inventory Abuse

요즘 매우 중요

⑥ Rate Limiting

과도한 요청 차단

예:

로그인 API 초당 100회 초과
→ 차단

⑦ Zero Trust

사내 시스템 보호

예:

VPN 대체
내부 Admin 페이지 보호
SSH / RDP 보호
Identity 기반 접근 제어

⑧ API Security

API 보호

Schema Validation
Token Abuse 방어
API Discovery
Abuse Detection

즉

👉 WAAP 핵심 요소

3. Cloudflare = WAAP 인가?

정답:

경우에 따라 다름

YES

다음 기능 사용 시:

WAF
Bot
DDoS
API Protection
Rate Limiting

→ 사실상 WAAP

NO

다음만 사용 시:

DNS
CDN

→ 그냥 CDN/DNS 서비스

4. AWS와 함께 쓰는 이유

많이 보는 구조:

Client
→ Cloudflare
→ Route53
→ ALB
→ ECS / EC2

이유:

AWS만으로 부족한 부분 보완

특히

Bot 방어
글로벌 Edge 보안
고급 WAF 정책
L7 DDoS

에서 강함

5. Cloudflare vs AWS WAF

항목CloudflareAWS WAF

위치	인터넷 앞단	AWS 내부
Bot 방어	강함	약함
DDoS	매우 강함	보통
글로벌 Edge	강함	제한적
운영 편의성	좋음	AWS 친화적

실무에서는

👉 Cloudflare가 더 “WAAP 느낌”

이 강함

6. 실무에서 중요한 포인트

Cloudflare 앞단이면

AWS WAF가 우회될 수 있음

즉

보안 정책 중심이

👉 AWS → Cloudflare

로 이동합니다.

이걸 모르고 운영하면 사고 납니다.

7. 한 줄 정리

👉 Cloudflare = CDN 회사

가 아닙니다

실제로는

👉 보안 + 성능 + 네트워크 플랫폼

입니다.

그리고 요즘은

👉 거의 “WAAP 플랫폼”

으로 보는 경우가 많습니다.

'C.S. > AWS' 카테고리의 다른 글

WAAF (Web Application and API Protection) (0)	2026.04.29
ALB (Application Load Balancer) (0)	2026.04.29
OTel Collector (0)	2026.04.29

개인 학습용 chatgpt 검색 내용.

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

WAAP란?

WAAP = Web Application and API Protection

즉,

👉 웹 서비스와 API를 공격으로부터 보호하는 보안 체계입니다.

예전의 단순한 WAF를 넘어서

웹 애플리케이션 보호
API 보호
Bot 공격 방어
DDoS 방어

까지 포함한 개념입니다.

1. 왜 WAAP가 필요한가

예전에는

방화벽 + WAF

만으로 충분했지만,

지금은

API 공격 증가
Bot 공격 증가
계정 탈취
Credential Stuffing
Layer 7 DDoS
OWASP Top 10 공격

이 훨씬 많아졌습니다.

그래서

👉 “웹 + API 전체를 보호하는 통합 보안”

이 필요해졌고 그게 WAAP입니다.

2. WAAP 구성 요소

① WAF (Web Application Firewall)

가장 기본

막는 것:

SQL Injection
XSS
RCE
Path Traversal
Command Injection
File Inclusion

즉

👉 웹 공격 방어의 핵심

② API Protection

요즘 더 중요

막는 것:

API Abuse
Broken Authentication
Excessive Data Exposure
Schema Violation
Token Abuse

즉

👉 REST / GraphQL / Mobile API 보호

③ Bot Management

자동화 공격 방어

막는 것:

Credential Stuffing
Account Takeover
Scraping
Fake Signup
Inventory Hoarding

예:

로그인 무차별 대입 공격

④ DDoS Protection

대량 공격 방어

막는 것:

L3/L4 공격
L7 HTTP Flood
SYN Flood
UDP Flood

즉

👉 서비스 다운 방지

⑤ Rate Limiting

과도한 요청 제한

예:

1초에 1000번 로그인 시도
→ 차단

⑥ Threat Intelligence

공격자 IP / 악성 봇 차단

Known bad IP
ASN 차단
Geo Blocking
Reputation 기반 차단

3. WAF vs WAAP 차이

구분WAFWAAP

목적	웹 공격 방어	웹 + API 전체 보호
보호 범위	주로 웹	웹 + API + Bot + DDoS
Bot 대응	약함	강함
API 보안	제한적	핵심 기능
현대 서비스 적합성	부족	높음

한 줄:

👉 WAF는 WAAP의 일부

4. 대표적인 WAAP 솔루션

Cloud 기반

Cloudflare
Akamai
Imperva
F5
Amazon Web Services WAF + Shield + API Gateway

On-Premise

F5 BIG-IP
Imperva SecureSphere
Fortinet
Palo Alto

5. AWS에서 WAAP 구성 예시

Client
→ Cloudflare
→ Route53
→ ALB
→ ECS / EC2

여기서

Cloudflare가

WAF
Bot
DDoS
Rate Limit

을 담당하면

👉 이미 WAAP 구조

AWS 내부에서는

ALB
Security Group
Shield
WAF

가 추가 방어

6. 실무에서 자주 보는 오해

오해 ①

“WAF 있으면 WAAP다”

→ 아님

WAF만 있으면 부족

오해 ②

“AWS WAF = 완전한 WAAP”

→ 보통 부족

Bot/API 보호가 약함

오해 ③

“CDN 쓰면 보안도 된다”

→ 아님

CDN ≠ WAAP

7. 보안팀 관점 핵심 질문

실제로는 이렇게 봅니다

질문 1

API까지 보호되는가?

질문 2

Bot 공격 막는가?

질문 3

DDoS 대응 가능한가?

질문 4

자동 정책 업데이트 되는가?

질문 5

False Positive 관리 가능한가?

8. 한 줄 정리

👉 WAF = 웹 공격 차단기

👉 WAAP = 웹 + API + Bot + DDoS 전체 방어 체계

즉

👉 “WAF보다 훨씬 큰 개념”

'C.S. > AWS' 카테고리의 다른 글

Cloudflare (0)	2026.04.29
ALB (Application Load Balancer) (0)	2026.04.29
OTel Collector (0)	2026.04.29

chatgpt 검색한 내용.

다른 부분은 찾아보세요.

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

ALB는
Application Load Balancer 입니다.

쉽게 말하면:

👉 “들어오는 웹 요청(HTTP/HTTPS)을 여러 서버로 똑똑하게 분배해주는 장비”

1. 어디에 위치하나

보통 구조는 이렇게 됩니다.

Client
 → Cloudflare
 → Route53
 → ALB
 → EC2 / ECS / EKS / Lambda

즉,

Cloudflare : 인터넷 앞단 보호 + CDN + WAF
Amazon Route 53 : DNS
AWS Application Load Balancer : 실제 요청 분산
EC2/ECS : 실제 애플리케이션 서버

2. ALB가 하는 일

① 트래픽 분산 (Load Balancing)

예:

사용자 10,000명 접속
→ 서버 1대가 아니라
→ 서버 10대로 나눠서 처리

서버가 죽지 않게 해줌

② URL 기반 라우팅

예:

/api/* → API 서버
/admin/* → 관리자 서버
/video/* → 영상 서버

경로별로 다른 서버로 보냄

③ 도메인 기반 라우팅

예:

api.company.com → API 서버
admin.company.com → Admin 서버

④ HTTPS 인증서 처리

SSL/TLS 종료
인증서 연결

즉 서버는 내부에서 HTTP만 써도 됨

⑤ Health Check

서버가 살아있는지 계속 확인

서버 죽음 → 자동 제외

매우 중요

3. 왜 Nginx 대신 ALB?

둘 다 가능하지만:

ALB → AWS 관리형
Nginx → 직접 운영

즉

👉 운영 부담 줄이려면 ALB

4. ALB vs NLB 차이

구분ALBNLB

Layer	L7	L4
프로토콜	HTTP/HTTPS	TCP/UDP
기능	URL 라우팅 가능	매우 빠름
사용처	웹 서비스	DB / 게임 / MQTT

5. 한 줄 정리

👉 ALB = 웹 서비스용 스마트 분배기
👉 NLB = 초고속 네트워크용 분배기

'C.S. > AWS' 카테고리의 다른 글

Cloudflare (0)	2026.04.29
WAAF (Web Application and API Protection) (0)	2026.04.29
OTel Collector (0)	2026.04.29

개인 학습용 자료로 GPT 찾아본 내용.

부정확하면 다시 찾아보세요.

------

set -o pipefail 는 bash 같은 셸에서 파이프라인(|)의 에러 처리 방식을 바꾸는 옵션이야.

🔧 기본 동작 (pipefail 없이)

일반적으로 쉘에서 파이프라인은 맨 마지막 명령의 종료 코드만 기준으로 성공/실패를 판단해.

false | true
echo $?

👉 결과: 0 (성공)

false는 실패(1)
true는 성공(0)
👉 마지막 명령(true)이 성공이므로 전체가 성공으로 처리됨

➡️ 앞에서 실패해도 무시되는 문제 있음

✅ set -o pipefail 적용 시

set -o pipefail

false | true
echo $?

👉 결과: 1 (실패)

파이프라인 내 하나라도 실패하면 전체 실패로 처리
정확히는: 가장 마지막으로 실패한 명령의 exit code 반환

📌 왜 쓰냐?

실무에서 매우 중요함 (특히 DevOps / 스크립트)

예:

cat file.txt | grep "keyword" | sort

file.txt 없으면 cat 실패
하지만 grep, sort는 정상 실행 → 결과적으로 성공처럼 보임 ❌

👉 pipefail 없으면 오류를 놓침

👉 pipefail 있으면:

cat 실패 → 전체 실패 → 바로 감지 가능 ✅

💡 보통 같이 쓰는 옵션

set -euo pipefail

의미:

-e: 에러 나면 즉시 종료
-u: 정의 안된 변수 사용 시 에러
-o pipefail: 파이프라인 에러 감지

👉 "안전한 bash 스크립트 기본 3종 세트"

🔥 한 줄 요약

👉 set -o pipefail = 파이프라인 중간에서 실패해도 무조건 실패로 처리하게 만드는 옵션

'C.S. > Linux' 카테고리의 다른 글

WSL 사용하기 (0)	2023.02.02
Linux 에서 samba 서버에 접근하기. (0)	2011.09.01
Linux 에서 Java (sun-java6-jdk, jre, sun-java5-jdk, jre) 설치 문제. (0)	2011.09.01
Linux 사용자 추가 (0)	2011.08.26
Ubuntu 에서 sudo 사용하기. (0)	2011.08.24

개인 공부용.

chatgpt 검색 내용.

📌 NeRF (Neural Radiance Fields) 핵심 정리

1️⃣ NeRF란?

NeRF (Neural Radiance Fields)는
👉 2D 이미지 여러 장을 이용해서 고품질 3D 장면을 복원하는 딥러닝 기반 기술이다.

제안: NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis
핵심: “공간 좌표 + 시점 방향 → 색상 + 밀도”를 신경망이 학습

2️⃣ 개념 구조 (한 줄 핵심)

👉 3D 공간을 함수로 표현한다

수식적으로 보면:

입력: (x, y, z, θ, φ)
출력: (RGB 색상, Density)

즉,

"이 위치에서 이 방향으로 보면 어떤 색이 보이는가?"

를 학습하는 모델

3️⃣ 동작 원리

✔️ 전체 흐름

여러 각도에서 찍은 이미지 수집
카메라 위치/방향 추정 (Pose estimation)
MLP(신경망)가 공간 함수 학습
Ray marching으로 이미지 렌더링

✔️ Ray 기반 렌더링 구조

8

픽셀마다 카메라에서 광선(ray)을 쏨
광선 위 여러 포인트 샘플링
각 포인트의 색 + 밀도 계산
누적 → 최종 픽셀 색 생성

👉 이 과정을 Volume Rendering이라고 함

4️⃣ 기존 방식 vs NeRF

구분기존 3D (SfM/MVS)NeRF

표현 방식	점/메쉬	연속 함수
결과	기하 구조 중심	사실적인 렌더링
장점	빠름	고품질
단점	텍스처 약함	학습 느림

👉 핵심 차이
➡️ 기존: “모양 복원”
➡️ NeRF: “빛까지 포함한 장면 복원”

5️⃣ 장점

✔ 매우 사실적인 뷰 합성
✔ 복잡한 반사/투명 효과 표현 가능
✔ 학습 후 임의 시점 생성 가능

👉 특히

AR/VR
디지털 트윈
메타버스
에서 핵심 기술

6️⃣ 단점 (현업에서 중요한 포인트)

❌ 학습 시간 길다 (수 시간 ~ 수십 시간)
❌ 실시간 처리 어려움
❌ 데이터 촬영 품질 의존
❌ 카메라 pose 정확도 중요

👉 그래서 실제 서비스에서는

Instant-NGP
Zip-NeRF
같은 경량화/가속 모델 사용

7️⃣ 확장/응용 기술

🔹 주요 파생 기술

Dynamic NeRF → 움직이는 객체 처리
NeRF in the Wild → 조명 변화 대응
Gaussian Splatting
→ 최근 실시간 대체 기술 (속도 ↑)

🔹 활용 사례

8

게임/메타버스 공간 생성
문화재 3D 복원
부동산/공간 스캔
자율주행 시뮬레이션

8️⃣ 한 줄 요약 (기술 면접용)

NeRF는 3D 공간을 신경망 함수로 표현하고, 광선 기반 렌더링을 통해 새로운 시점의 이미지를 생성하는 기술이다.

'C.S.' 카테고리의 다른 글

Okta Provider 를 통한 Terraform 을 이용한 조직 관리 방법 (0)	2026.04.29
i18n (Internationalization) (0)	2026.04.29
SKT 6G 전략 및 보안 (ATHENA 백서) (0)	2026.03.05
K8s 의 node 조정 (0)	2026.02.01

chatgpt 에서 찾아본 내용 정리.

자기 학습용.

내용이 틀릴 수 있으니 항상 double check 하세요.

----

1. i18n 이란?

i18n은 Internationalization (국제화) 의 약자입니다.

i와 n 사이에 18개의 글자가 있어서
줄여서 i18n이라고 부릅니다.

의미는

하나의 서비스가 여러 나라와 여러 언어를 쉽게 지원할 수 있도록 구조를 만드는 것

입니다.

즉,

번역을 하는 것이 아니라
번역이 쉽게 가능하도록 설계하는 것입니다.

2. 왜 필요한가?

서비스를 운영하다 보면

한국어
영어
일본어
중국어

등 여러 언어를 지원해야 할 수 있습니다.

만약 화면 문구를 코드에 직접 작성하면

로그인 실패
회원가입 완료
비밀번호 오류

언어를 추가할 때마다
코드를 계속 수정해야 합니다.

그래서

문구
날짜 형식
통화 표시
문화권 차이

를 분리해서 관리합니다.

이것이 i18n입니다.

3. i18n 과 l10n 차이

i18n (국제화)

→ 다국어 지원이 가능하도록 구조를 만드는 것

예:

문구를 코드에서 분리
언어 파일 관리
날짜/통화 포맷 분리

즉,

준비하는 작업

입니다.

l10n (Localization, 현지화)

→ 실제 특정 국가에 맞게 적용하는 것

예:

한국어 번역
영어 번역
일본어 번역
국가별 표현 수정

즉,

실제 번역 및 적용 작업

입니다.

4. 무엇을 다루는가?

① 화면 문구

버튼
메뉴
에러 메시지
알림 문구

예:

Save
저장
保存

② 날짜 / 시간 형식

예:

2026-04-29
04/29/2026
2026年4月29日

③ 숫자 / 통화 표시

예:

₩10,000
$10,000
10.000 €

④ 문화적 차이

이름 표기 순서
주소 형식
전화번호 형식
색상 의미
법률 문구

단순 번역보다 더 중요할 수 있습니다.

5. 핵심 원칙

코드와 언어를 분리한다

좋지 않은 방식:

코드 안에 직접 문구 작성

좋은 방식:

문구는 별도 파일에서 관리

이렇게 해야

유지보수 쉬움
언어 추가 쉬움
운영 효율 증가

가 가능합니다.

6. 한 줄 정의

쉽게

여러 나라 사람이 같은 서비스를 사용할 수 있게 만드는 구조

실무적으로

문자열, 포맷, 문화권 요소를 분리한 국제화 설계

7. 핵심 요약

용어의미

i18n	국제화 (구조 설계)
l10n	현지화 (실제 적용)
목적	다국어 서비스 지원
대상	문구, 날짜, 통화, 문화권 요소
핵심	코드와 언어를 분리

최종 한 줄

i18n은
“번역을 잘하는 것”이 아니라
“번역이 쉽게 되는 구조를 만드는 것”이다.

'C.S.' 카테고리의 다른 글

Okta Provider 를 통한 Terraform 을 이용한 조직 관리 방법 (0)	2026.04.29
NeRF (Neural Radiance Fields) (0)	2026.04.29
SKT 6G 전략 및 보안 (ATHENA 백서) (0)	2026.03.05
K8s 의 node 조정 (0)	2026.02.01

개인 학습용. chat gpt 검색 내용.

틀릴 수 있으며 정확한 내용은 한번 더 검색해보세요.

0. 개요

OTel Collector는 OpenTelemetry Collector를 줄여서 부르는 말입니다.
애플리케이션이나 서버에서 발생하는 Telemetry 데이터(Logs / Metrics / Traces)를 수집하고, 가공하고, 원하는 곳으로 전달하는 중간 허브 역할을 합니다.

쉽게 말하면:

애플리케이션 → OTel Collector → 모니터링 시스템

구조입니다.

EKS / ECS / EC2 / Lambda
        ↓
OTel Collector
        ↓
CloudWatch / X-Ray / OpenSearch / AMP / AMG

1. 왜 필요한가?

예를 들어 서비스가 여러 개 있다고 하면

API 서버
DB 서버
Redis
Kubernetes
AWS 서비스

이 모든 곳에서

CPU 사용률
응답 시간
에러 로그
API Trace

같은 데이터를 각각 수집해야 합니다.

직접 각각을

Prometheus
Grafana
Datadog
Jaeger

로 보내면 관리가 복잡해집니다.

그래서 중간에 Collector를 두고

한 번 모아서 → 변환 → 필터링 → 전달합니다.

2. 주요 기능

OTel Collector는 크게 3가지 역할을 합니다.

(1) Receiver

데이터를 받는 역할

예:

OTLP
Prometheus scrape
Jaeger
Zipkin
Fluent Forward
Syslog

즉,

"어디서 데이터를 받을까?"

를 담당합니다.

(2) Processor

데이터를 가공하는 역할

예:

batch 처리
sampling
filtering
memory limit
attribute 추가

즉,

"받은 데이터를 어떻게 다룰까?"

입니다.

(3) Exporter

최종 목적지로 보내는 역할

예:

Prometheus
Grafana Tempo
Jaeger
AWS CloudWatch
Datadog
Elasticsearch

즉,

"어디로 보낼까?"

입니다.

3. 예시 구성

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
  memory_limiter:

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

의미:

애플리케이션에서 metric 수집
→ batch 처리
→ Prometheus로 전달

4. Agent mode vs Gateway mode

Agent mode

각 서버마다 설치

App → Local Collector → Backend

장점:

빠름
로컬 정보 수집 쉬움

Gateway mode

중앙 집중형

App → Central Collector → Backend

장점:

관리 쉬움
정책 통일 가능

실제 운영

보통 둘 다 사용합니다.

Agent + Gateway

형태가 많습니다.

5. Kubernetes에서 자주 사용

특히

Kubernetes
환경에서는 거의 필수급입니다.

이유:

Pod가 계속 생성/삭제됨
서비스가 많음
Trace 중요
중앙 관리 필요

그래서

DaemonSet (Agent)
Deployment (Gateway)

형태로 많이 구성합니다.

6. 한 줄 정의

아주 쉽게

observability 데이터의 프록시 서버

조금 전문적으로

telemetry pipeline engine

7. 핵심 요약

항목의미

OTel	OpenTelemetry
Collector	수집/가공/전달 엔진
데이터 종류	Logs / Metrics / Traces
핵심 구성	Receiver / Processor / Exporter
주 사용처	K8s, MSA, Cloud 환경

한 줄로 끝내면:

“Prometheus 이전 시대의 exporter가 아니라
observability 전체를 통합하는 중간 플랫폼”

'C.S. > AWS' 카테고리의 다른 글

Cloudflare (0)	2026.04.29
WAAF (Web Application and API Protection) (0)	2026.04.29
ALB (Application Load Balancer) (0)	2026.04.29

AI 정리한 문서이니 참고해서 보시고 실제 정보는 실제 참가업체와 대조, 비교해보세요.

SECON 2026 SASE 및 연관 기술 업체 정리

분야(연관 기술)업체명국가부스번호요약

SASE / Zero Trust	에어코드	Korea	T122	망분리·망연계 보안, CDR, DLP 기반 Zero Trust 및 SASE 보안 아키텍처 제공
SASE / CASB / Cloud Security	에스에스앤씨(SSNC)	Korea	Q051	Forcepoint 보안 플랫폼 파트너, CASB·DLP·ZTNA·SASE 기반 클라우드 통합 보안 제공
Data Security / DLP	안랩	Korea	S001	개인정보보호, 접속이력 관리, 데이터 유출 방지(DLP), DDoS 대응 등 데이터 보호 중심 보안 플랫폼
Endpoint Security / EDR	이테크시스템 (시만텍)	Korea	P135	Symantec 보안 솔루션 공급. 엔드포인트 보안, 랜섬웨어 대응, 서버 보안 중심
Endpoint Security	카스퍼스키랩코리아	Korea	R105	랜섬웨어 대응, EDR, 모바일 및 서버 보안 중심 보안 플랫폼
Data Security / DB Security	Shenzhen MAITUO Technology	China	Q045	개인정보 보호, 데이터 유출 방지, DB 보안 중심 데이터 보호 솔루션

기술 영역 기준 분류

기술 영역포함 업체

SASE / Zero Trust	에어코드, 에스에스앤씨
Cloud Security / CASB	에스에스앤씨
DLP / Data Security	안랩, Shenzhen MAITUO
Endpoint Security / EDR	이테크시스템, 카스퍼스키

💡 핵심 포인트 (SECON 기준)

SASE 직접 업체
- 에어코드
- 에스에스앤씨 (Forcepoint)
SASE 연관 기술 업체
- 안랩 (DLP / 데이터 보안)
- Symantec (엔드포인트 보안)
- 카스퍼스키 (EDR / Endpoint)
- MAITUO (DB 보안)

즉 SASE 구조 관점에서는

Endpoint Security
 ↓
Data Security (DLP)
 ↓
Cloud Security / CASB
 ↓
ZTNA
 ↓
SASE

형태로 이어지는 보안 스택을 구성합니다.

'C.S. > Security' 카테고리의 다른 글

MDM + CA 인증서를 활용한 기기 인증 구조 (0)	2026.05.14
AI 가 추천하는 SECON 2026 전시부스 15곳 (0)	2026.03.12
SECON 2026 양자보안 관련 업체 목록 (0)	2026.03.12
CA 서버, RA 서버 차이 (0)	2026.02.24
LDAP (Lightweight Directory Access Protocol) (0)	2026.01.13