260508 개발질문세션노트

260508 개발질문세션노트

문서 목적

이 문서는 HhdStock 개발 관련 대화에서 나온 질문과 답변을 한 곳에 누적 정리하기 위한 세션 노트입니다.

단순 대화 로그가 아니라, 이후 다시 읽기 쉬운 개발 지식 문서로 재구성합니다.

001. RTMP, RTSP, RTP 차이점

질문

rtmp, rtsp, rtp 의 차이점?

핵심 결론

세 가지는 모두 실시간 미디어와 관련 있지만, 담당하는 층위가 다릅니다.

• RTP: 실제 오디오/비디오 패킷을 실시간으로 운반하는 전송 포맷/프로토콜입니다.
• RTSP: 재생, 일시정지, 세션 설정 같은 스트리밍 제어용 프로토콜입니다. 보통 미디어 본문은 RTP 같은 별도 프로토콜로 흐릅니다.
• RTMP: 오디오/비디오/데이터를 하나의 연결 위에서 메시지로 묶어 보내는 애플리케이션 레벨 스트리밍 프로토콜입니다. 실무에서는 방송 송출 인입, 즉 encoder -> streaming server 구간에서 자주 쓰였습니다.

한눈에 비교

관계도

flowchart LR
    A["카메라/인코더"] -->|RTMP: 송출 인입| B["스트리밍 서버"]
    C["RTSP 클라이언트"] -->|RTSP: SETUP/PLAY/PAUSE| D["RTSP 서버/IP 카메라"]
    D -->|RTP/RTCP: 실제 미디어 패킷| C
    E["WebRTC/VoIP 앱"] -->|RTP/RTCP: 실시간 미디어| F["상대방/미디어 서버"]

조금 더 정확히

RTP는 실시간 데이터의 end-to-end 전달을 위한 프로토콜입니다. 오디오/비디오 payload 타입, sequence number, timestamp, 전송 모니터링 같은 정보를 제공하지만, 자체적으로 지연 보장이나 QoS 보장을 하지는 않습니다. 그래서 손실이 일부 발생해도 실시간성을 우선하는 음성/영상 흐름에 잘 맞습니다.

RTSP는 미디어 스트림을 제어하는 프로토콜입니다. 클라이언트가 DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN 같은 방식으로 서버에게 “어떤 스트림을 어떤 방식으로 재생할지” 요청합니다. 실제 연속 미디어 데이터는 대개 RTSP 밖에서 RTP/RTCP로 전달됩니다.

RTMP는 오디오, 비디오, 데이터 메시지를 TCP 같은 신뢰성 있는 스트림 위에서 multiplexing하고 packetizing하는 프로토콜입니다. 과거 Flash 생태계에서 강했고, 지금도 라이브 플랫폼의 encoder ingest 구간에서 많이 남아 있습니다.

실무 선택 기준

근거 URL

• RFC 3550, RTP: A Transport Protocol for Real-Time Applications: https://www.rfc-editor.org/rfc/rfc3550
• RFC 7826, Real-Time Streaming Protocol Version 2.0: https://www.rfc-editor.org/rfc/rfc7826.html
• Adobe RTMP Specification HTML mirror: https://rtmp.veriskope.com/docs/spec/

사실 / 추정 / 검증필요

002. 240p~4K 해상도와 적정 비트레이트 계산

질문

240p 360p 480p 720p 1080p 4k 영상의 각각 해상도는?
각 영상별 1초 분량의 적절한 비트레이트는?
비트레이트가 산출되는 상세한 계산?

전제

아래 값은 16:9, SDR, H.264, 8-bit, YUV 4:2:0, 30fps, 일반적인 움직임의 영상 기준입니다.

YouTube 공식 업로드 권장값은 360p 이상에 대해 H.264, 4:2:0, VBR, SDR 기준 비트레이트를 제시합니다. 240p는 공식 업로드 표에 직접 값이 없어서, 360p의 bits-per-pixel 수준을 426x240에 맞춰 역산했습니다.

해상도와 권장 비트레이트

MB/s = Mbps / 8 입니다. 예를 들어 1080p 8 Mbps는 8 / 8 = 1 MB/s 입니다.

비트레이트 산출 구조

무압축 영상 기준으로 먼저 계산한 다음, 코덱 압축률을 반영합니다.

1단계: 프레임당 픽셀 수

예: 1080p

2단계: 색상 채널/샘플링 고려

RGB 8-bit 무압축이면 픽셀당 24bit입니다.

하지만 H.264 같은 일반 동영상은 보통 YUV 4:2:0 8-bit를 사용합니다. 이 경우 픽셀당 평균 12bit입니다.

예: 1080p 30fps YUV 4:2:0

3단계: 압축률 반영

H.264 1080p 30fps의 권장 영상 비트레이트를 8 Mbps로 잡으면:

즉, 무압축 YUV 4:2:0 기준 약 746.5 Mbps짜리 데이터를 H.264로 약 8 Mbps 수준까지 줄이는 셈입니다.

다른 표현으로는 encoded bits per pixel per frame을 사용합니다.

예: 1080p 30fps, 8 Mbps

계산 결과 표

오디오까지 포함한 총 비트레이트

영상 파일/스트림의 전체 비트레이트는 보통 아래처럼 계산합니다.

YouTube 업로드 권장값 기준 오디오는 stereo 384 kbps, 5.1ch 512 kbps입니다. 라이브 인코더에서는 stereo 128 kbps도 흔히 씁니다.

예: 1080p 30fps 업로드용

주의할 점

비트레이트는 해상도만으로 결정되지 않습니다. 실제 적정값은 아래 요소에 따라 크게 달라집니다.

근거 URL

• YouTube recommended upload encoding settings: https://support.google.com/youtube/answer/1722171
• YouTube live encoder settings, bitrates, and resolutions: https://support.google.com/youtube/answer/2853702

사실 / 추정 / 검증필요

003. TCP의 문제점과 QUIC의 해결 방식

질문

tcp 의 문제점 소개
quic 으로 해결한 방식 소개

핵심 결론

TCP 자체가 나쁜 프로토콜이라는 뜻은 아닙니다. TCP는 신뢰성 있는 순서 보장 byte stream이라는 강력한 추상화를 제공합니다. 문제는 현대 웹처럼 한 연결 안에 많은 독립 요청을 동시에 싣는 환경에서 이 추상화가 지연을 키울 수 있다는 점입니다.

QUIC은 UDP 위에 새 전송 계층을 만들고, 그 안에 TLS, multiplexed stream, packet-level loss recovery, connection ID 기반 migration을 넣어 TCP+TLS 조합의 병목을 줄였습니다.

TCP의 대표 문제

QUIC의 해결 방식

구조 비교

flowchart TB
    A["HTTP/2"] --> B["TLS"]
    B --> C["TCP: single ordered byte stream"]
    C --> D["IP"]

    E["HTTP/3"] --> F["QUIC: TLS + streams + loss recovery + migration"]
    F --> G["UDP"]
    G --> H["IP"]

Head-of-Line blocking 예시

TCP에서는 한 연결에 A, B, C 요청의 데이터가 섞여 있어도 TCP 계층은 이를 하나의 byte stream으로 봅니다. 앞쪽 packet 하나가 유실되면 뒤쪽 byte를 애플리케이션에 순서대로 넘기지 못합니다.

TCP byte stream:
[A1][B1][C1][A2-loss][B2][C2]
                 ^
                 A2 재전송 전까지 뒤쪽 전달이 막힐 수 있음

QUIC streams:
Stream A: [A1][A2-loss] -> A만 대기
Stream B: [B1][B2]      -> 진행 가능
Stream C: [C1][C2]      -> 진행 가능

QUIC도 만능은 아님

근거 URL

• RFC 9293, Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293
• RFC 9000, QUIC Transport Protocol: https://www.rfc-editor.org/rfc/rfc9000
• RFC 9001, Using TLS to Secure QUIC: https://www.rfc-editor.org/rfc/rfc9001
• RFC 9002, QUIC Loss Detection and Congestion Control: https://www.rfc-editor.org/rfc/rfc9002
• RFC 9114, HTTP/3: https://www.rfc-editor.org/rfc/rfc9114

사실 / 추정 / 검증필요

004. SQL/RDBMS, NoSQL, Redis, Search, pgvector 선택 기준

질문

sql rdbms 와 nosql 의 차이점 장단점
firestore, dynamodb, postgressql, mysql, sqlite 장단점 특징 소개
orm사용시 장단점
redis 소개 장단점
firestore의 약점을 보완하기 위해 redis나 elastic search 를 사용한다면?
pgvector 의 소개 장단점

핵심 결론

DB 선택은 “어떤 데이터 모델이 더 멋진가”보다 질문 패턴과 정합성 요구가 먼저입니다.

SQL RDBMS vs NoSQL

제품별 특징과 장단점

Firestore 세부 메모

Firestore는 “앱 개발 속도”가 매우 빠른 DB입니다. 문서/컬렉션 모델이 직관적이고, 클라이언트 SDK에서 실시간 listener와 offline persistence를 바로 쓸 수 있습니다.

하지만 Standard/Core query 기준으로는 다음 제약이 중요합니다.

2026년 현재는 Firestore Enterprise edition의 Pipeline operations가 강화되었습니다. 공식 Firebase 블로그는 2026-04-27에 Pipeline operations GA와 함께 full-text search, geospatial query, subquery 기반 JOIN, DML이 추가되었다고 설명합니다. 다만 full-text search/geospatial query는 새 기능이라 preview로 안내되어 있고, Enterprise 문서도 “Native mode with Core and Pipeline operations”를 preview로 설명합니다. 따라서 일반 Standard Firestore 설계에서는 여전히 외부 검색/캐시 보완 패턴을 고려하는 것이 안전합니다.

ORM 사용 장단점

ORM은 객체와 관계형 DB 사이의 반복 코드를 줄여주는 도구입니다. SQLAlchemy는 Python 객체의 persistence를 자동화하는 ORM을 제공하고, Prisma는 type-safe client와 migration을 핵심 장점으로 내세웁니다.

실무 추천은 ORM + query log + raw SQL escape hatch입니다. 단순 CRUD는 ORM, 성능 민감/복잡 조회는 SQL 또는 query builder로 명시적으로 작성하는 방식이 가장 덜 위험합니다.

Redis 소개와 장단점

Redis는 단순 key-value cache를 넘어 in-memory data structure server에 가깝습니다. 문자열, hash, list, set, sorted set, stream 같은 자료구조를 제공하고, 캐시/세션/메시지 브로커/streaming/rate limit/랭킹에 자주 쓰입니다.

Firestore 약점을 Redis/Elasticsearch로 보완하는 구조

Redis로 보완하기 좋은 것

Redis는 정답 원장(source of truth) 보다는 속도 계층(speed layer) 으로 두는 것이 안전합니다. 영구 데이터는 Firestore/PostgreSQL에 두고, Redis는 TTL과 재계산 가능성을 전제로 운영합니다.

Elasticsearch로 보완하기 좋은 것

권장 구조는 다음과 같습니다.

flowchart LR
    A["Client/App"] --> B["API / Cloud Functions"]
    B --> C["Firestore: source of truth"]
    B --> D["Redis: cache, counter, rank, rate limit"]
    C --> E["Change event / worker"]
    E --> F["Elasticsearch: search index"]
    A -->|search request| B
    B -->|search ids| F
    B -->|hydrate documents| C

주의할 점은 동기화 지연과 이중 저장소 운영입니다. Firestore -> Elasticsearch sync가 늦으면 검색 결과가 stale해질 수 있고, 삭제/권한 변경도 search index에 반영해야 합니다. 검색 결과에는 Firestore document id를 저장하고, 최종 권한 검사는 Firestore/API 계층에서 다시 수행하는 편이 안전합니다.

pgvector 소개와 장단점

pgvector는 PostgreSQL 안에서 embedding vector를 저장하고 similarity search를 수행하게 해주는 확장입니다. vector, halfvec, bit, sparsevec 타입을 제공하고, L2 distance, inner product, cosine distance 등을 지원합니다.

예시:

CREATE TABLE items (
  id bigserial PRIMARY KEY,
  title text,
  embedding vector(1536)
);

SELECT *
FROM items
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

선택 가이드

근거 URL

• Cloud Firestore data model: https://firebase.google.com/docs/firestore/data-model
• Cloud Firestore query limitations: https://cloud.google.com/firestore/docs/query-data/queries
• Cloud Firestore index overview: https://firebase.google.com/docs/firestore/query-data/index-overview
• Firestore full-text search solution note: https://firebase.google.com/docs/firestore/solutions/search
• Firestore Pipeline operations GA blog, 2026-04-27: https://firebase.blog/posts/2026/04/firestore-pipelines-ga
• Firestore Enterprise edition modes: https://firebase.google.com/docs/firestore/enterprise/overview-enterprise-edition-modes
• Amazon DynamoDB introduction: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html
• PostgreSQL about: https://www.postgresql.org/about/
• MySQL 8.4 Reference Manual: https://dev.mysql.com/doc/mysql/en/
• SQLite appropriate uses: https://www.sqlite.org/whentouse.html
• SQLite serverless: https://www.sqlite.org/serverless.html
• Redis data types: https://redis.io/docs/latest/develop/data-types/
• Redis persistence: https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
• Elasticsearch reference: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
• Elasticsearch full-text search: https://www.elastic.co/guide/en/elasticsearch/reference/current/full-text-search.html
• pgvector README: https://github.com/pgvector/pgvector
• SQLAlchemy ORM: https://docs.sqlalchemy.org/20/orm/
• Prisma ORM: https://docs.prisma.io/docs/orm

사실 / 추정 / 검증필요

005. 간단한 CNN/Transformer 모델 파라미터 수 계산

질문

간단한 cnn, transformer 모델을 상정하고 이의 파라미터 갯수를 계산하는 과정을 보이시오

핵심 공식

Conv/Linear의 + out_channels, + out_features는 bias를 쓰는 경우입니다. bias=False라면 빼면 됩니다.

Conv2D, BatchNorm2D, LayerNorm, Attention, FFN 상세

Conv2D 파라미터 계산 상세

Conv2D의 입력이 PyTorch 관례로 N x C_in x H x W라고 하겠습니다.

Conv2D는 출력 채널 하나를 만들기 위해 C_in개의 입력 채널을 모두 보는 filter bank를 하나 가집니다.

출력 채널 1개를 위한 weight 수
= kernel_h * kernel_w * in_channels

출력 채널이 C_out개면 이런 filter bank가 C_out개 필요합니다.

전체 weight 수
= kernel_h * kernel_w * in_channels * out_channels

여기에 bias를 쓰면, bias는 출력 픽셀마다 따로 있는 것이 아니라 출력 채널마다 1개입니다. 같은 output channel의 모든 위치에 같은 bias가 더해집니다.

전체 bias 수
= out_channels

따라서 일반 Conv2D 파라미터 수는:

예: Conv2d(in_channels=3, out_channels=16, kernel_size=3, bias=True)

중요한 점은 Conv2D 파라미터 수가 H, W에 직접 비례하지 않는다는 것입니다. 같은 kernel을 이미지 전체 위치에 공유하기 때문입니다. 그래서 32x32 이미지든 224x224 이미지든, 같은 3x3, 3->16 conv라면 학습 파라미터 수는 448개입니다. 다만 연산량은 위치 수가 많아질수록 증가합니다.

groups가 있는 grouped convolution은 입력 채널을 그룹으로 나누므로 공식이 바뀝니다.

Depthwise convolution은 보통 groups = C_in, C_out = C_in * multiplier 형태라 파라미터가 크게 줄어듭니다.

BatchNorm2D 자체 설명과 파라미터 계산

BatchNorm2D는 Conv2D 뒤에서 자주 쓰는 정규화 레이어입니다. 입력 shape가 N x C x H x W일 때, 채널별로 평균과 분산을 계산합니다.

Training 중에는 각 채널 c에 대해 batch와 공간 위치 전체에서 평균/분산을 계산합니다.

그 다음 각 값을 정규화합니다.

정규화만 하면 출력의 평균이 0, 분산이 1에 묶입니다. 그런데 모델이 필요하면 원래 scale/shift를 다시 배울 수 있어야 하므로 learnable affine parameter를 둡니다.

여기서:

따라서 affine=True인 일반 BatchNorm2D의 학습 파라미터 수는:

예: BatchNorm2d(num_features=16)

running_mean, running_var도 저장은 되지만 optimizer가 gradient로 학습하는 값이 아닙니다. 이 값들은 학습 중 batch 통계를 이동평균으로 누적해두었다가 inference/eval 모드에서 사용합니다.

training mode:
현재 mini-batch의 mean/var로 정규화
running_mean/running_var 업데이트

eval mode:
저장된 running_mean/running_var로 정규화
gamma/beta는 그대로 사용

Conv 뒤에 BatchNorm이 바로 오면 Conv의 bias를 False로 두는 경우가 많습니다. Conv bias가 더해져도 BatchNorm의 평균 빼기 단계에서 상당 부분 상쇄되고, BatchNorm의 beta가 shift 역할을 다시 할 수 있기 때문입니다.

LayerNorm 자체 설명과 파라미터 계산

LayerNorm은 Transformer에서 매우 자주 쓰는 정규화입니다. BatchNorm과 가장 큰 차이는 batch 방향으로 통계를 내지 않는다는 점입니다.

Transformer에서 입력 shape를 B x L x D라고 하겠습니다.

LayerNorm(normalized_shape=D)는 각 sample의 각 token마다 마지막 차원 D개 feature를 기준으로 평균/분산을 계산합니다.

정규화 후 gamma/beta를 적용합니다.

hidden_dim = D이면:

예: LayerNorm(512)

LayerNorm은 BatchNorm과 달리 running mean/variance를 보통 두지 않습니다. training/eval 모두 현재 입력의 마지막 차원 통계로 정규화합니다. 그래서 batch size가 작거나 sequence length가 가변적인 Transformer 계열에서 쓰기 좋습니다.

주의: LayerNorm(normalized_shape=(C,H,W))처럼 여러 차원을 정규화 대상으로 잡으면 gamma/beta도 그 shape 전체만큼 생깁니다.

Self-Attention의 Q, K, V, O projection 파라미터 계산

Transformer 입력을 X, shape를 B x L x D라고 하겠습니다.

Self-Attention은 같은 입력 X로부터 Query, Key, Value를 만듭니다.

가장 흔한 구현에서 각 projection은 D -> D 선형변환입니다.

Q/K/V 합계:

Attention score와 weighted sum 자체는 학습 파라미터가 아닙니다.

Multi-head에서는 D 차원을 H개 head로 쪼갭니다.

head 수가 늘어도 보통 총 projection 크기는 D -> D로 유지됩니다. 즉, head마다 D -> d_head projection을 갖는다고 생각하면:

그래서 head 수가 직접 파라미터를 H배로 만들지는 않습니다.

각 head 결과를 concat하면 다시 D차원이 되고, 마지막에 output projection을 한 번 더 거칩니다.

따라서 Q,K,V,O projection 전체는:

예: D = 512, num_heads = 8

여기서 sequence length L은 파라미터 수에는 영향을 주지 않습니다. 대신 attention score matrix가 대략 L x L이라 연산량과 메모리 사용량에 큰 영향을 줍니다.

Transformer FFN 파라미터 계산

Transformer FFN은 position-wise feed-forward network입니다. 각 token 위치에 같은 MLP를 독립적으로 적용합니다.

입력 shape가 B x L x D이면:

FFN:
Linear1: D -> D_ff
Activation: ReLU/GELU/SwiGLU 등
Linear2: D_ff -> D

기본 FFN 공식은 다음과 같습니다.

첫 번째 Linear:

두 번째 Linear:

전체:

정리하면:

예: D = 512, D_ff = 2048

FFN도 sequence length L에 따라 파라미터가 늘지는 않습니다. 같은 Linear weight를 모든 token 위치에 공유하기 때문입니다. 하지만 연산량은 token 수 L에 비례해서 증가합니다.

요즘 LLM에서 쓰는 SwiGLU/GEGLU 같은 gated FFN은 첫 projection이 두 갈래가 되는 경우가 많아 vanilla FFN보다 파라미터 수가 달라집니다. 예를 들어 D -> D_ff 두 개와 D_ff -> D 하나를 쓰면 대략 3DD_ff 규모가 됩니다.

예제 1: 작은 CNN

전제:

• 입력 이미지: 32 x 32 x 3
• 분류 클래스: 10
• Conv는 3x3, padding으로 공간 크기 유지
• MaxPool은 2x2, 파라미터 없음
• bias 사용

모델:

Input: 32x32x3
Conv1: 3x3, in=3, out=16
MaxPool: 2x2
Conv2: 3x3, in=16, out=32
MaxPool: 2x2
Flatten
FC1: 2048 -> 128
FC2: 128 -> 10

출력 크기 흐름

총 파라미터:

만약 Conv 뒤에 BatchNorm을 붙이면:

그러면 trainable parameter는:

예제 2: 작은 Transformer Encoder

전제:

• Encoder-only Transformer
• vocab_size = 30,000
• max_position = 512
• hidden_dim = d_model = 512
• num_heads = 8
• ffn_dim = 2048
• num_layers = 6
• 분류 클래스 10
• token embedding과 output LM head는 연결하지 않고, 여기서는 classification head만 사용

중요한 점:

Multi-head attention에서 head 수가 8개여도 파라미터 수는 보통 hidden_dim 기준으로 계산합니다. 각 head의 차원이 d_head = d_model / num_heads로 쪼개질 뿐, Q/K/V 전체 projection의 총 크기는 여전히 d_model x d_model입니다.

Embedding

Token embedding:

Position embedding:

Embedding 합계:

Encoder layer 1개

Self-Attention의 Q, K, V, O projection:

Q/K/V/O가 4개 있으므로:

FFN:

LayerNorm 2개:

Encoder layer 1개 합계:

Encoder 6층:

Classification head:

전체 합계:

Transformer 계산 요약표

자주 헷갈리는 점

근거

이 항목은 표준 딥러닝 레이어의 파라미터 계산식과 PyTorch 공식 문서의 parameter shape 설명을 기준으로 정리했습니다.

• PyTorch Conv2d: https://docs.pytorch.org/docs/stable/generated/torch.nn.Conv2d.html
• PyTorch BatchNorm2d: https://docs.pytorch.org/docs/stable/generated/torch.nn.BatchNorm2d.html
• PyTorch LayerNorm: https://docs.pytorch.org/docs/stable/generated/torch.nn.LayerNorm.html
• PyTorch MultiheadAttention: https://docs.pytorch.org/docs/stable/generated/torch.nn.MultiheadAttention.html
• PyTorch TransformerEncoderLayer: https://docs.pytorch.org/docs/stable/generated/torch.nn.TransformerEncoderLayer.html
• Attention Is All You Need: https://arxiv.org/abs/1706.03762

006. ARM과 Intel 명령어 차이, ARM 버전별 차이

질문

arm, intel 명령어 차이점 장단덤
arm 의 버전별 명령어 차이점 장단점

먼저 구분할 것

ARM vs Intel이라고 말할 때 보통은 아래 두 층위가 섞입니다.

성능/전력은 ISA만으로 결정되지 않습니다. 같은 Arm ISA라도 Apple M-series와 저전력 Cortex-A 코어는 전혀 다르고, 같은 x86-64라도 Intel Atom 계열과 고성능 Core/Xeon 계열은 다릅니다.

ARM vs Intel/x86 명령어 차이

장단점

ARM 명령어 집합 이름 정리

ARM 버전별 큰 흐름

아래 표는 앱/서버 개발에서 자주 만나는 A-profile 중심 요약입니다.

Arm 공식 문서는 현재 A-profile 최신 버전을 Armv9.4-A와 Armv8.9-A로 안내합니다. Armv9-A는 Armv8-A의 단절이 아니라 “Armv8-A에 대한 확장 세트”로 설명됩니다.

실무에서 확인해야 할 것

컴파일/배포에서는 “CPU가 Arm이냐 Intel이냐”보다 아래를 확인해야 합니다.

근거 URL

• Arm A-profile architecture: https://www.arm.com/architecture/cpu/a-profile
• Arm A64 Instruction Set Architecture guide: https://documentation-service.arm.com/static/68cd1a81cccf2a5517018d62
• Introducing the Arm architecture: https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Introducing%20the%20Arm%20architecture.pdf
• Understanding the Armv8.x extensions: https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Understanding%20the%20Armv8.x%20extensions.pdf
• Intel 64 and IA-32 Architectures Software Developer Manuals: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
• Arm Memory Tagging Extension article: https://newsroom.arm.com/memory-safety-arm-memory-tagging-extension
• Arm PAC/BTI article: https://newsroom.arm.com/blog/pac-bti

사실 / 추정 / 검증필요

007. Google Meet/WebRTC 멀티 참가자 대역폭 관리

질문

구글밋 같은 WebRTC 제품에서 멀티세션간 대역폭은 어떻게 관리되는가?
발화자에게 대역폭을 더 할당하는가?
내 목소리는 왜 나에게 다시 들리지는 않는것인가?
서울과 뉴욕 2개의 사무실에 5명씩 총 10명이 구글밋을 진행하는 상황이라면 대역폭 배분을 어떻게 하는 것인가?

핵심 결론

Google Meet 같은 대규모 WebRTC 회의 제품은 보통 브라우저끼리 10명이 전부 직접 연결되는 mesh가 아니라, 각 참가자가 Google의 media server/SFU 계층에 연결하고 서버가 필요한 미디어만 선택적으로 전달하는 구조로 보는 것이 맞습니다.

공식 문서가 Google Meet 내부 알고리즘을 세부 공개하지는 않지만, 공개 표준과 Google Meet 운영 문서로 확인 가능한 큰 원리는 다음과 같습니다.

• 각 참가자는 자기 uplink 상태에 맞춰 카메라 화질/프레임/비트레이트를 조절합니다.
• 각 참가자의 downlink는 보고 있는 레이아웃, active speaker, 화면공유, 네트워크 상태, 기기 성능에 따라 다르게 받습니다.
• 발화자/큰 타일/spotlight/화면공유는 더 높은 해상도 또는 우선순위를 받기 쉽습니다.
• 내 목소리는 보통 나에게 다시 전달하지 않습니다. 그리고 스피커 소리가 마이크로 다시 들어가는 것은 echo cancellation으로 줄입니다.

P2P mesh와 SFU의 차이

10명이 모두 P2P mesh로 연결되면 각 참가자는 나머지 9명에게 자기 영상을 따로 보내야 합니다.

P2P mesh:
각 참가자 uplink ~= 내 영상 9개 복제
각 참가자 downlink ~= 다른 사람 9명 수신

이 방식은 3~4명까지는 가능해도 10명 이상에서는 uplink, CPU, 배터리, NAT traversal이 부담됩니다.

Meet류 서비스는 일반적으로 아래처럼 동작한다고 이해하면 됩니다.

flowchart LR
    S1["Seoul user 1"] --> G["Google Meet media server / SFU"]
    S2["Seoul user 2"] --> G
    S3["Seoul user 3"] --> G
    N1["New York user 1"] --> G
    N2["New York user 2"] --> G
    G --> S1
    G --> S2
    G --> S3
    G --> N1
    G --> N2

각 사용자는 서버로 1회 송신하고, 서버가 각 수신자에게 필요한 stream/layer만 골라 보냅니다.

대역폭은 누가 어떻게 조절하나

WebRTC에서는 RTP/RTCP feedback, packet loss, RTT, jitter, congestion feedback, available bitrate 추정 등을 보고 bitrate를 조절합니다. Google Meet의 Meet Quality Tool도 packet loss, jitter, RTT, actual bitrate, available bitrate, network congestion 같은 값을 추적합니다.

발화자에게 대역폭을 더 할당하는가

대체로 그렇다고 보면 됩니다. 다만 “대역폭을 발화자 계정에 고정 배정한다”기보다, 수신자별 레이아웃에서 중요한 사람의 video layer를 더 높은 품질로 선택한다에 가깝습니다.

RFC 8853의 simulcast 설명도 multiparty session에서 central node가 참가자별 view를 조절하고, 현재/이전 발화자를 forwarding 대상으로 고르는 active speaker selection이 흔하다고 설명합니다.

예:

즉, 발화자에게 uplink를 더 준다기보다는 다른 사람들이 발화자의 고품질 stream을 더 자주 받는다가 정확합니다. 발화자의 uplink 자체도 카메라 품질, network estimate, server 요청에 따라 올라갈 수 있습니다.

내 목소리는 왜 나에게 다시 들리지 않나

이유는 두 층입니다.

1. 애플리케이션 레벨에서 내 microphone track을 내 speaker에 재생하지 않습니다.
2. 서버/SFU도 보통 내 audio packet을 다시 나에게 forward하지 않습니다.

그래서 내 목소리는 원격 참가자에게만 갑니다. 다만 상대방 목소리가 내 스피커로 나오고 그 소리가 내 마이크로 다시 들어가면, 그건 상대방에게 echo로 들릴 수 있습니다. 이를 줄이려고 브라우저/OS/WebRTC stack은 echo cancellation, noise suppression, auto gain control을 사용합니다.

W3C Media Capture 문서의 echoCancellation 설명은 마이크 입력에서 재생 중인 소리를 제거하려는 처리를 echo cancellation이라고 설명합니다. remote-only 모드는 WebRTC RTCPeerConnection에서 온 원격 오디오를 제거하는 용도를 갖습니다.

서울 5명 + 뉴욕 5명 회의의 대역폭 계산

전제:

• 서울 사무실 5명, 뉴욕 사무실 5명
• 각자 노트북으로 같은 Google Meet에 참가
• 각 사용자는 Google media server에 직접 연결
• P2P mesh가 아니라 SFU 기반으로 추정

Google 공식 문서의 대규모 조직 평균값:

대규모 조직 평균값으로 사무실별 계산:

개인/소규모 기준 Google 공식값:

최대치에 가깝게 잡은 보수적 계산:

하지만 실제로 항상 이 최대치를 쓰지는 않습니다. 이유는 다음과 같습니다.

• 모든 참가자의 영상을 720p로 동시에 받지 않음
• 작은 타일은 낮은 layer로 충분함
• 말하지 않는 참가자의 영상은 낮은 fps/bitrate가 될 수 있음
• 화면공유가 있으면 카메라보다 화면공유를 우선할 수 있음
• 네트워크가 나쁘면 Meet가 자동으로 video definition을 낮춤

같은 사무실 5명이 각자 노트북으로 들어갈 때 주의점

같은 회의실에 있는 5명이 각자 노트북으로 마이크/스피커를 켜면 음향 문제가 생기기 쉽습니다.

서울 사무실 5명과 뉴욕 사무실 5명이 각각 한 회의실에 모여 있다면, 가장 효율적인 구성은 보통 서울 회의실 장비 1대 + 뉴욕 회의실 장비 1대입니다. 그러면 네트워크 관점에서는 10 endpoint가 아니라 2 endpoint 회의에 가까워져 대역폭과 음향 문제가 크게 줄어듭니다.

정리

근거 URL

• Google Meet network preparation and bandwidth requirements: https://support.google.com/a/answer/1279090
• Google Meet requirements and automatic quality adjustment: https://support.google.com/meet/answer/7317473
• Google Meet quality statistics: https://support.google.com/a/answer/9204857
• Google Meet Media API client metrics and WebRTC getStats: https://developers.google.com/workspace/meet/media-api/guides/metrics
• RFC 8853, Using Simulcast in SDP and RTP Sessions: https://www.rfc-editor.org/rfc/rfc8853
• RFC 8834, Media Transport and Use of RTP in WebRTC: https://www.rfc-editor.org/rfc/rfc8834
• RFC 8888, RTCP Feedback for Congestion Control: https://www.rfc-editor.org/rfc/rfc8888.html
• W3C Media Capture and Streams, echoCancellation: https://www.w3.org/TR/mediacapture-streams/

사실 / 추정 / 검증필요

008. Unity, Unreal Engine, NVIDIA Omniverse 비교

질문

유니티, 언리얼, nvidia 옴니버스의 소개, 차이점
그래픽스, 게임엔진, 물리환경, 렌더링, 성능, 품질, 개발생태계 면에 대한 비교

핵심 결론

Unity와 Unreal Engine은 게임/인터랙티브 앱을 빌드해서 배포하는 런타임 엔진입니다. NVIDIA Omniverse는 그 둘과 같은 의미의 게임엔진이라기보다 OpenUSD, RTX, PhysX 기반의 산업용 3D/디지털 트윈/물리 AI 시뮬레이션 플랫폼 및 SDK/API 묶음에 가깝습니다.

제품 소개

큰 관계도

flowchart LR
    A["DCC/CAD tools<br/>Maya, Blender, Revit, CAD"] --> D["OpenUSD scene/data"]
    D --> O["NVIDIA Omniverse<br/>USD + RTX + PhysX + APIs"]
    D --> U["Unity<br/>game/app runtime"]
    D --> E["Unreal Engine<br/>game/film/runtime"]
    U --> P["Mobile, PC, Console, XR apps"]
    E --> Q["AAA games, film, simulation apps"]
    O --> R["Digital twins, robotics, synthetic data"]

그래픽스 관점

Unity 공식 문서는 URP를 광범위한 플랫폼용 scalable graphics, HDRP를 high-end platform용 cutting-edge/high-fidelity graphics로 설명합니다. Unreal은 Nanite로 pixel-scale detail과 높은 object count를, Lumen으로 dynamic global illumination/reflection을 제공합니다. Omniverse RTX Renderer는 RTX GPU, USD, MDL 기반의 photoreal renderer이며 real-time 2.0과 interactive path tracing 모드를 제공합니다.

게임엔진 관점

물리환경 관점

렌더링 품질과 성능

개발 생태계

장단점 요약

Unity

Unreal Engine

NVIDIA Omniverse

선택 시나리오

실무 판단 기준

근거 URL

• Unity Engine official: https://unity.com/products/unity-engine
• Unity render pipelines: https://docs.unity.cn/6000.1/Documentation/Manual/render-pipelines.html
• Unity built-in 3D physics: https://docs.unity.cn/Manual/PhysicsOverview.html
• Unity ECS/DOTS: https://unity.com/ecs
• Unreal Engine official: https://www.unrealengine.com/
• Unreal Engine Nanite: https://dev.epicgames.com/documentation/unreal-engine/nanite-virtualized-geometry-in-unreal-engine
• Unreal Engine Lumen: https://dev.epicgames.com/documentation/en-us/unreal-engine/lumen-global-illumination-and-reflections-in-unreal-engine
• Unreal Engine Physics/Chaos: https://dev.epicgames.com/documentation/en-us/unreal-engine/physics-in-unreal-engine
• NVIDIA Omniverse official: https://www.nvidia.com/en-us/omniverse/
• NVIDIA Omniverse docs: https://docs.nvidia.com/omniverse/index.html
• Omniverse RTX Renderer: https://docs.omniverse.nvidia.com/materials-and-rendering/latest/rtx-renderer.html
• Omniverse Kit manual: https://docs.omniverse.nvidia.com/kit/docs/kit-manual/108.0.0/

사실 / 추정 / 검증필요

009. ACID 트랜잭션과 SOLID 디자인 원칙

질문

acid 트랜젝션 설명
solid 디자인 원칙 설명

핵심 결론

ACID는 데이터베이스 트랜잭션이 실패, 동시성, 장애 상황에서도 데이터를 안전하게 다루기 위한 4가지 보장입니다.

SOLID는 객체지향 설계에서 변경에 강하고 테스트하기 쉬운 코드를 만들기 위한 5가지 설계 원칙입니다.

ACID 트랜잭션

트랜잭션은 여러 DB 연산을 하나의 논리적 작업 단위로 묶는 것입니다. 예를 들어 계좌 이체는 A 계좌 차감과 B 계좌 증가가 모두 성공해야 의미가 있습니다.

BEGIN;

UPDATE accounts SET balance = balance - 10000 WHERE id = 'A';
UPDATE accounts SET balance = balance + 10000 WHERE id = 'B';

COMMIT;

중간에 실패하면:

ROLLBACK;

A: Atomicity, 원자성

원자성은 전부 성공하거나 전부 실패해야 한다는 뜻입니다.

원자성이 없으면 돈은 빠졌는데 상대 계좌에는 입금되지 않는 상태가 생길 수 있습니다.

C: Consistency, 일관성

일관성은 트랜잭션 전후에 DB가 정의된 규칙을 만족해야 한다는 뜻입니다.

예:

• 잔액은 음수가 될 수 없음
• 외래키가 깨지면 안 됨
• 주문 총액은 주문 항목 합계와 맞아야 함
• 계좌 이체 전후 전체 잔액 합은 같아야 함

주의할 점은, DB가 모든 비즈니스 일관성을 자동으로 보장하지는 않는다는 것입니다. 제약조건, 트리거, 애플리케이션 로직이 함께 맞아야 합니다.

I: Isolation, 격리성

격리성은 동시에 실행되는 트랜잭션들이 서로의 중간 상태를 함부로 보지 않도록 하는 성질입니다.

예:

T1: A 계좌에서 10000원 차감
T2: A 계좌 잔액 조회
T1: B 계좌에 10000원 증가

격리 수준이 낮으면 T2가 T1의 중간 상태를 볼 수 있습니다. 그래서 DB는 보통 여러 isolation level을 제공합니다.

D: Durability, 지속성

지속성은 트랜잭션이 COMMIT된 뒤에는 시스템 장애가 나도 결과가 보존되어야 한다는 뜻입니다.

DB는 보통 WAL, redo log, fsync, replication 같은 메커니즘으로 지속성을 구현합니다. 다만 실제 보장 수준은 DB 설정, 디스크, 클라우드 스토리지, replication 정책에 영향을 받습니다.

ACID 예시: 주문 생성

flowchart TD
    A["BEGIN"] --> B["재고 차감"]
    B --> C["주문 row 생성"]
    C --> D["결제 승인 기록"]
    D --> E{"모두 성공?"}
    E -->|Yes| F["COMMIT"]
    E -->|No| G["ROLLBACK"]

SOLID 디자인 원칙

SOLID는 객체지향 설계에서 많이 쓰이는 5가지 원칙입니다. 무조건 클래스를 많이 쪼개라는 뜻이 아니라, 변경 이유와 의존 방향을 잘 관리하라는 쪽에 가깝습니다.

S: Single Responsibility Principle

하나의 클래스/모듈이 너무 많은 책임을 가지면 변경 이유가 많아집니다.

나쁜 예:

InvoiceService
- 주문 금액 계산
- PDF 생성
- 이메일 발송
- DB 저장

개선:

InvoiceCalculator
InvoiceRepository
InvoicePdfRenderer
InvoiceMailer

핵심은 “기능 하나”가 아니라 변경 이유 하나입니다. 세금 정책 변경, PDF 양식 변경, 메일 발송 정책 변경은 서로 다른 변경 이유입니다.

O: Open/Closed Principle

새 기능을 추가할 때 기존 코드를 계속 고치는 구조는 회귀 버그가 늘어납니다.

나쁜 예:

def pay(method, amount):
    if method == "card":
        ...
    elif method == "bank":
        ...
    elif method == "paypal":
        ...

개선 방향:

class PaymentProvider:
    def pay(self, amount):
        raise NotImplementedError

class CardPayment(PaymentProvider):
    def pay(self, amount):
        ...

class BankPayment(PaymentProvider):
    def pay(self, amount):
        ...

새 결제 수단은 새 클래스로 추가하고, 기존 안정 코드는 덜 건드리는 식입니다.

L: Liskov Substitution Principle

상위 타입을 기대하는 코드에 하위 타입을 넣어도 정상 동작해야 합니다.

나쁜 예:

Bird.fly()
Penguin extends Bird
Penguin.fly() -> 예외 발생

Bird를 받는 코드가 fly()를 믿고 호출하는데 Penguin이 들어오면 깨집니다.

개선:

Bird
FlyingBird.fly()
Penguin extends Bird
Eagle extends FlyingBird

상속은 “비슷해 보임”이 아니라 “행동 계약을 지킬 수 있음”이 기준입니다.

I: Interface Segregation Principle

큰 인터페이스 하나에 모든 기능을 몰아넣으면 구현체가 쓰지도 않는 메서드를 억지로 구현해야 합니다.

나쁜 예:

Machine
- print()
- scan()
- fax()

단순 프린터는 scan, fax를 지원하지 않는데 인터페이스 때문에 예외를 던지게 됩니다.

개선:

Printer.print()
Scanner.scan()
Fax.fax()

클라이언트가 실제로 필요한 작은 인터페이스에만 의존하게 만드는 것이 목적입니다.

D: Dependency Inversion Principle

상위 정책 코드가 하위 구현 세부사항에 직접 의존하면 교체와 테스트가 어려워집니다.

나쁜 예:

class OrderService:
    def __init__(self):
        self.sender = SmtpEmailSender()

개선:

class OrderService:
    def __init__(self, sender):
        self.sender = sender

OrderService는 SmtpEmailSender라는 구체 구현이 아니라 EmailSender 역할/인터페이스에 의존합니다. 테스트에서는 fake sender를 넣고, 운영에서는 SMTP/SES/SendGrid 구현을 넣을 수 있습니다.

ACID와 SOLID의 공통점과 차이

실무 팁

근거 URL

• IBM, ACID properties of transactions: https://www.ibm.com/docs/en/cics-tx/11.1?topic=processing-acid-properties-transactions
• IBM, Properties of transactions: https://www.ibm.com/docs/en/SSNAQ8_11.1.0/concepts/c_trans.html
• PostgreSQL Transaction Processing: https://www.postgresql.org/docs/current/transactions.html
• PostgreSQL START TRANSACTION: https://www.postgresql.org/docs/current/sql-start-transaction.html
• SOLID Principles Wiki: https://principles-wiki.net/collections%3Asolid
• Robert C. Martin, Design Principles and Design Patterns mirror: https://blog.thedojo.mx/assets/pdfs/DesignPrinciplesAndPatterns.pdf

사실 / 추정 / 검증필요

010. ABI와 ISA 차이점

질문

abi 와 isa 차이점

핵심 결론

ISA는 CPU가 어떤 명령어를 이해하고 실행하는지에 대한 계약입니다.

ABI는 이미 컴파일된 바이너리들이 OS, 라이브러리, 다른 object file과 어떻게 맞물리는지에 대한 계약입니다.

레이어로 보면

flowchart TB
    A["Source code<br/>C/C++/Rust/Go"] --> B["Compiler"]
    B --> C["ABI 규칙<br/>calling convention, stack, object format"]
    C --> D["Machine code<br/>ISA instructions"]
    D --> E["CPU microarchitecture"]
    C --> F["OS / Loader / Dynamic Linker / libc"]

ISA는 Machine code -> CPU 쪽 계약이고, ABI는 컴파일 산출물 -> OS/라이브러리/다른 바이너리 쪽 계약입니다.

ISA가 정하는 것

ISA는 CPU가 실행할 수 있는 명령어와 그 의미를 정의합니다.

예를 들어 AArch64, x86-64, RISC-V RV64GC는 ISA 계층의 이름입니다.

ABI가 정하는 것

ABI는 같은 ISA 위에서 돌아가는 바이너리들이 서로 깨지지 않게 맞추는 규칙입니다.

예를 들어 같은 x86-64 ISA라도 OS마다 ABI가 다릅니다.

같은 ISA, 다른 ABI 예시

x86-64 CPU는 같아도 Linux와 Windows의 함수 호출 규칙은 다릅니다.

그래서 동일한 x86-64 기계어 명령어를 쓰더라도, 어떤 ABI를 가정하고 컴파일했는지에 따라 함수 호출이 맞거나 깨질 수 있습니다.

같은 ABI 계열, 다른 ISA 예시

반대로 “Linux ELF executable”이라는 큰 실행 환경은 비슷해도 ISA가 다르면 바이너리는 직접 실행되지 않습니다.

ELF라는 object/executable 형식은 공유할 수 있지만, 내부 machine instruction이 다르기 때문에 ISA가 다르면 native 실행은 불가능합니다. 에뮬레이터나 translation layer가 필요합니다.

API, ABI, ISA 비교

예:

int add(int a, int b);

API 관점:

• 함수 이름이 add
• 인자 타입이 int, int
• 반환 타입이 int

ABI 관점:

• a, b를 어떤 레지스터에 넣는가
• 반환값을 어떤 레지스터에 넣는가
• stack은 몇 byte 정렬해야 하는가
• symbol 이름은 어떻게 저장되는가

ISA 관점:

• 실제로 ADD, MOV, RET 같은 어떤 machine instruction으로 표현되는가

왜 중요한가

실무 감각

근거 URL

• Arm CPU architecture overview: https://www.arm.com/architecture/cpu
• Arm A-profile architecture guide: https://www.arm.com/architecture/learn-the-architecture/a-profile
• Arm Application Binary Interface official docs: https://developer.arm.com/Architectures/ABI
• Arm ABI GitHub repository: https://github.com/ARM-software/abi-aa
• Apple Application Binary Interfaces: https://developer.apple.com/documentation/xcode/application-binary-interfaces
• RISC-V psABI: https://riscv-non-isa.github.io/riscv-elf-psabi-doc/
• System V ABI overview: https://wiki.osdev.org/System_V_ABI

사실 / 추정 / 검증필요

011. 네트워크 진단 툴 사용법

질문

네트워크 툴 사용법
netstat, ping, ifconfig, dip, traceroute, dig …

핵심 결론

네트워크 문제는 OSI 계층을 따라 아래 순서로 보는 편이 좋습니다.

1. 내 장비 IP/라우팅 확인: ip, ifconfig
2. 목적지까지 도달성 확인: ping
3. 경로 중 어디서 느린지/끊기는지 확인: traceroute, tracert, mtr
4. DNS 확인: dig, nslookup
5. 포트/소켓 확인: ss, netstat
6. 실제 TCP/HTTP 확인: nc, curl
7. 패킷 레벨 확인: tcpdump, Wireshark

dip는 일반적인 현대 네트워크 진단 명령으로는 잘 쓰이지 않습니다. 질문 맥락상 Linux의 ip를 의미한 것으로 보고 정리합니다.

주요 명령어 표

자주 쓰는 진단 흐름

1. 내 IP와 라우팅 확인

ip addr
ip route
ip route get 8.8.8.8

ip route get은 특정 목적지로 갈 때 어떤 interface/source IP/gateway를 쓸지 확인할 때 유용합니다.

2. 목적지 도달성 확인

ping -c 4 8.8.8.8
ping -c 4 google.com

IP로 ping은 되는데 domain으로 ping이 안 되면 DNS 문제일 가능성이 큽니다. 단, ICMP가 차단된 서버도 많아서 ping 실패가 곧 서비스 장애를 의미하지는 않습니다.

3. DNS 확인

dig example.com A
dig example.com AAAA
dig example.com MX
dig +short example.com
dig @8.8.8.8 example.com
dig +trace example.com

dig @resolver는 특정 DNS resolver를 지정해 질의할 때 좋습니다. +trace는 root부터 authoritative DNS까지 추적합니다.

4. 경로 확인

traceroute example.com
traceroute -T -p 443 example.com

중간 hop이 * * *로 나와도 반드시 장애는 아닙니다. 라우터가 TTL exceeded 응답을 제한하거나 ICMP를 막을 수 있습니다.

5. 포트와 소켓 확인

Linux:

ss -tulpn
ss -tan state established

Windows:

netstat -ano
netstat -ab

LISTEN은 프로세스가 해당 포트를 열었다는 뜻이지, 방화벽이 외부 접근을 허용한다는 뜻은 아닙니다.

근거 URL

• Microsoft netstat: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat
• Linux ip man page: https://man7.org/linux/man-pages/man8/ip.8.html
• Linux ping man page: https://man7.org/linux/man-pages/man8/ping.8.html
• Linux traceroute man page: https://man7.org/linux/man-pages/man8/traceroute.8.html
• ISC BIND/dig documentation: https://downloads.isc.org/isc/bind9/9.20.11/doc/arm/html/manpages.html#dig-dns-lookup-utility

012. Android, iOS, Windows, Linux 특징과 장단점

질문

android, ios, window, ios, linux의 특징, 장단점, 설계상 특징
특히 android 의 특징을 길게 설명

한눈에 비교

Android를 길게 설명

Android는 단순히 “Linux 폰”이 아닙니다. Linux kernel 위에 Android 전용 runtime, framework, security model, app component model을 올린 플랫폼입니다.

Android 아키텍처

flowchart TB
    A["Apps<br/>APK/AAB"] --> B["Java/Kotlin API Framework"]
    B --> C["Android Runtime<br/>ART, core libraries"]
    B --> D["Native C/C++ Libraries"]
    D --> E["HAL<br/>Hardware Abstraction Layer"]
    C --> F["Linux Kernel<br/>process, memory, drivers, SELinux"]
    E --> F

Android 앱 모델

Android 앱은 하나의 main()에서 시작하는 전통 데스크톱 앱과 다릅니다. 시스템이 app component를 필요에 따라 생성/중단/재개합니다.

이 구조 덕분에 앱 간 연동이 유연하지만, lifecycle을 잘못 다루면 memory leak, background kill, state loss가 생깁니다.

Android 보안 모델

Android는 기본적으로 앱마다 별도 Linux UID를 주고 sandbox를 만듭니다.

Android의 보안은 강하지만, 사용자가 권한을 과도하게 허용하거나 OEM 업데이트가 늦으면 위험이 커집니다.

Android의 장점

Android의 단점

iOS 특징

iOS는 Apple이 하드웨어, OS, SDK, App Store를 통합 관리합니다. Swift/SwiftUI/UIKit/Metal 생태계가 중심입니다.

Windows 특징

Windows는 데스크톱, 기업, 게임, 레거시 호환성 중심 OS입니다. user mode/kernel mode 분리, Win32, COM, .NET, UWP/WinUI 등 여러 세대의 API가 공존합니다.

Linux 특징

Linux는 kernel이고, 실제 OS 경험은 배포판과 userland 조합으로 결정됩니다. 서버, 클라우드, 컨테이너, 임베디드에서 강합니다.

근거 URL

• Android platform architecture: https://developer.android.com/guide/platform
• Android security checklist: https://developer.android.com/guide/topics/security/security
• Android Binder IPC: https://source.android.com/docs/core/architecture/hidl/binder-ipc
• Apple iOS developer: https://developer.apple.com/ios/
• Apple UIKit overview: https://developer.apple.com/documentation/UIKit
• Microsoft Windows user mode/kernel mode: https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode
• Linux Kernel documentation: https://docs.kernel.org/

013. OpenGL, EGL, WGL 설명

질문

openGL, EGL, WGL 설명

핵심 결론

OpenGL은 렌더링 API입니다. 하지만 OpenGL 자체는 “윈도우를 만들고, OS 화면에 붙이고, context를 생성하는 방법”까지 모두 정하지 않습니다. 그래서 플랫폼별 glue layer가 필요합니다.

관계도

flowchart TB
    A["App"] --> B["OpenGL / OpenGL ES API"]
    A --> C["Context/Surface API"]
    C --> D["WGL on Windows"]
    C --> E["EGL on Android/Linux/Wayland/GBM"]
    B --> F["GPU Driver"]
    D --> F
    E --> F

OpenGL

OpenGL은 vertex, shader, texture, buffer, framebuffer 등을 통해 그래픽을 그리는 API입니다. Khronos의 OpenGL registry에 공식 specification과 extension이 있습니다.

주의할 점:

• OpenGL은 rendering API이지 windowing API가 아닙니다.
• context가 있어야 OpenGL 함수를 호출할 수 있습니다.
• Windows에서는 보통 WGL, Android에서는 EGL로 context를 만듭니다.

EGL

EGL은 Khronos rendering API와 underlying native platform window system 사이의 interface입니다.

주요 역할:

Android OpenGL ES 개발에서 자주 보는 흐름:

eglGetDisplay
eglInitialize
eglChooseConfig
eglCreateWindowSurface
eglCreateContext
eglMakeCurrent
glDraw...
eglSwapBuffers

WGL

WGL은 Windows 전용 OpenGL windowing/context interface입니다.

주요 역할:

Windows에서 modern OpenGL context를 만들 때는 기본 WGL API만으로 부족해 WGL_ARB_create_context 같은 extension을 함께 사용합니다.

근거 URL

• Khronos OpenGL: https://www.khronos.org/opengl/
• Khronos OpenGL Registry: https://registry.khronos.org/OpenGL/
• Khronos EGL: https://www.khronos.org/egl
• Khronos OpenGL/WGL Registry: https://registry.khronos.org/opengl

014. GPU core와 Tensor Core 설명

질문

gpu core, tensor 설명

핵심 결론

GPU core는 일반적인 병렬 연산을 수행하는 실행 유닛을 넓게 부르는 말이고, Tensor Core는 딥러닝에서 많이 쓰는 matrix multiply-accumulate를 빠르게 처리하는 특수 하드웨어입니다.

GPU core

GPU는 CPU처럼 소수의 강한 core보다, 많은 실행 lane으로 같은 명령을 여러 데이터에 병렬 적용하는 데 강합니다. NVIDIA에서는 SM 안에 CUDA core, Tensor Core, load/store unit, special function unit 등이 들어갑니다.

CUDA core는 단순히 “CPU core”와 1:1 대응되는 개념이 아닙니다. GPU thread가 warp 단위로 묶여 실행되고, CUDA core는 그 warp의 산술 명령을 처리하는 실행 lane에 가깝습니다.

Tensor Core

Tensor Core는 딥러닝의 핵심 연산인 matrix multiply-accumulate를 가속합니다.

일반 CUDA core로도 행렬곱을 할 수 있지만, Tensor Core는 특정 shape/precision의 행렬 블록 연산을 훨씬 높은 throughput으로 처리하도록 설계되어 있습니다.

주의할 점:

• Tensor Core는 “AI tensor 객체를 저장하는 곳”이 아닙니다.
• Tensor Core는 GPU 안의 특수 연산 유닛입니다.
• PyTorch/TensorFlow의 tensor는 데이터 구조이고, NVIDIA Tensor Core는 하드웨어입니다.

근거 URL

• NVIDIA Tensor Cores: https://www.nvidia.com/en-us/data-center/tensor-cores/
• NVIDIA mixed precision training: https://docs.nvidia.com/deeplearning/performance/mixed-precision-training/index.html
• PyTorch tensor docs: https://docs.pytorch.org/docs/stable/tensors.html

015. AI에서 Tensor란 무엇인가

질문

ai 에서 tensor 란?
tensor와 일반 행렬과 일반 숫자와 차이점?

핵심 결론

AI 프레임워크에서 tensor는 보통 동일 dtype을 가진 다차원 배열입니다.

수학적으로 tensor는 더 엄밀한 의미가 있지만, AI/딥러닝 실무에서는 대부분 ndarray + dtype + shape + device + gradient 정도로 이해하면 됩니다.

예시

이미지 한 장:

RGB image = [C, H, W] = [3, 224, 224]

이미지 batch:

batch = [N, C, H, W] = [32, 3, 224, 224]

Transformer 입력:

tokens embedding = [B, L, D]
B = batch size
L = sequence length
D = hidden dimension

Tensor와 행렬/숫자의 차이

행렬은 rank-2 tensor입니다. 숫자는 rank-0 tensor로 볼 수 있습니다. 즉 tensor가 더 일반적인 개념입니다.

근거 URL

• TensorFlow Introduction to Tensors: https://www.tensorflow.org/guide/tensor
• TensorFlow tf.Tensor: https://www.tensorflow.org/api_docs/python/tf/Tensor
• PyTorch Tensor docs: https://docs.pytorch.org/docs/stable/tensors.html

016. Python 같은 인터프리터 언어가 일반적으로 느린 이유

질문

python 같은 인터프리터 언어가 컴파일 언어에 비해서 일반적으로 느린이유?

핵심 결론

CPython은 소스 코드를 bytecode로 컴파일한 뒤, interpreter loop가 bytecode를 하나씩 해석해 실행합니다. C/C++/Rust/Go 같은 언어는 보통 더 많은 정보를 컴파일 시점에 알고 machine code로 최적화합니다.

Python이 느린 주된 이유는 “한 줄씩 읽어서”라기보다, 동적 타입과 객체 모델이 매 연산마다 많은 일을 하게 만들기 때문입니다.

주요 이유

예: x + y

C에서 int x, y라면 컴파일러는 거의 바로 machine add instruction으로 내릴 수 있습니다.

Python에서는:

z = x + y

이 연산에 대해 runtime이 확인해야 하는 것:

• x, y가 어떤 객체인가
• +가 어떤 special method로 연결되는가
• overflow/큰 정수 처리는 어떻게 할 것인가
• 결과 객체를 새로 만들 것인가
• reference count를 어떻게 바꿀 것인가

이 유연성이 Python의 생산성을 만들지만, CPU-bound loop에서는 비용이 됩니다.

그래도 Python이 빠른 경우

근거 URL

• Python executive summary: https://www.python.org/doc/essays/blurb/
• Python C API, GIL: https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock
• Python FAQ: https://docs.python.org/3/faq/general.html
• PyPy CPython differences: https://doc.pypy.org/en/latest/cpython_differences.html

017. WebGL 소개와 OpenGL 대비 한계

질문

WebGL 소개, 특징, 장단점
openGL을 windows나 android 에서 사용할때에 비해 webGL을 사용할때의 한계점

핵심 결론

WebGL은 브라우저의 HTML canvas에서 JavaScript로 GPU 가속 3D 그래픽을 사용할 수 있게 하는 Khronos 표준입니다. WebGL 1.0은 OpenGL ES 2.0, WebGL 2.0은 OpenGL ES 3.0 기반입니다.

WebGL 장점

WebGL 단점

Windows/Android에서 native OpenGL을 쓸 때와 WebGL 한계

Windows native OpenGL 대비

Windows 브라우저의 WebGL은 내부적으로 ANGLE 등을 통해 Direct3D/Vulkan/Metal/OpenGL backend로 변환될 수 있습니다. 앱 개발자는 WebGL API를 쓰지만 실제 GPU backend는 브라우저가 선택합니다.

Android OpenGL ES 대비

언제 WebGL을 쓰나

근거 URL

• Khronos WebGL: https://www.khronos.org/webgl/
• WebGL 1.0 specification: https://registry.khronos.org/webgl/specs/latest/1.0/
• WebGL 2.0 specification: https://registry.khronos.org/webgl/specs/2.0/
• Khronos EGL: https://www.khronos.org/egl
• Khronos OpenGL: https://www.khronos.org/opengl/

018. Unity를 Desktop, Mobile, WebGL에서 사용할 때의 차이

질문

유니티를 windows/macos에서 사용할때, android/ios 에서 사용할때, webGL에서 사용할때
특징, 차이점, 한계 설명
특히 그래픽스, 멀티미디어 측면에서 설명

핵심 결론

Unity는 같은 프로젝트를 여러 플랫폼에 빌드할 수 있지만, 실제 그래픽스/멀티미디어 동작은 타깃 플랫폼의 그래픽 API, 파일/스레드/오디오/비디오 제한, 브라우저 sandbox에 크게 좌우됩니다.

그래픽스 차이

멀티미디어 차이

Unity 공식 문서는 WebGL 빌드가 HTML5와 WebGL rendering API를 사용해 브라우저에서 Unity content를 실행하며, WebGL platform에는 OpenGL ES 기능 기반 제한이 있고 audio는 Web Audio API 기반 custom backend로 기본 기능만 지원한다고 설명합니다.

플랫폼별 선택 감각

근거 URL

• Unity Graphics API support: https://docs.unity.cn/Manual/GraphicsAPIs.html
• Android Unity graphics APIs: https://developer.android.com/games/engines/unity/start-in-unity
• Unity WebGL technical overview: https://docs.unity.cn/Manual/webgl-technical-overview.html
• Unity WebGL Vivox limitations: https://docs.unity.com/en-us/vivox-unity/developer-guide/vivox-webgl
• Unity Metal manual: https://docs.unity3d.com/Manual/Metal.html

019. TFLite, OpenCL, OpenGL, Core ML 설명

질문

tflite, openCL, openGL, coreML 설명

핵심 결론

네 가지는 이름은 비슷해 보여도 역할이 다릅니다.

TFLite

TensorFlow Lite는 모바일, 임베디드, IoT 기기에서 ML 모델을 실행하기 위한 도구 모음입니다.

OpenCL

OpenCL은 CPU, GPU, 기타 compute device를 대상으로 병렬 계산 kernel을 실행하기 위한 Khronos 표준입니다. 그래픽을 그리는 API가 아니라 compute API입니다.

OpenGL

OpenGL은 2D/3D vector graphics 렌더링 API입니다. shader, texture, buffer, framebuffer 등을 이용해 화면을 그립니다.

Core ML

Core ML은 Apple 기기에서 ML 모델을 on-device로 실행하기 위한 프레임워크입니다. Apple silicon, Neural Engine, GPU, CPU를 활용해 모델 실행을 최적화합니다.

근거 URL

• TensorFlow Lite guide: https://www.tensorflow.org/lite/guide
• Khronos OpenCL specification: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html
• Khronos OpenCL: https://www.khronos.org/opencl/
• Khronos OpenGL: https://www.khronos.org/opengl/
• Apple Core ML overview: https://developer.apple.com/machine-learning/core-ml/
• Apple Core ML documentation: https://developer.apple.com/documentation/CoreML

020. MediaPipe 소개, 특징, 장단점, 한계

질문

mediapipe 소개 특징 장단점 한계 설명

핵심 결론

MediaPipe는 Google의 실시간 on-device perception/ML pipeline 프레임워크입니다. 얼굴, 손, 포즈, gesture, object detection 같은 실시간 입력 처리를 graph pipeline으로 구성합니다.

구조

flowchart LR
    A["Camera/Audio/Input"] --> B["Preprocess Calculator"]
    B --> C["ML Inference"]
    C --> D["Postprocess"]
    D --> E["Landmarks/Detections/Results"]

MediaPipe의 기본 단위는 graph, node/calculator, stream, packet입니다.

장점

단점과 한계

언제 쓰면 좋은가

근거 URL

• MediaPipe Tasks: https://ai.google.dev/edge/mediapipe/solutions/tasks
• MediaPipe Framework concepts: https://developers.google.com/mediapipe/framework/framework_concepts/overview
• MediaPipe graphs: https://developers.google.com/mediapipe/framework/framework_concepts/graphs
• MediaPipe calculators: https://developers.google.com/mediapipe/framework/framework_concepts/calculators
• MediaPipe paper: https://arxiv.org/abs/1906.08172

021. NVIDIA Ray Tracing/RTX와 기존 shader 기반 렌더링 차이

질문

nvidia lay tracing, rtx 와 기존의 쉐이더 기반 렌더링의 차이점

용어 정리

여기서 lay tracing은 ray tracing을 의미하는 것으로 보고 정리합니다.

또한 “기존 shader 기반 렌더링”은 보통 rasterization + programmable shader pipeline을 뜻합니다. Ray tracing도 ray generation, closest-hit, miss shader 같은 shader를 쓰므로, 정확히는 rasterization 기반 렌더링과 ray tracing 기반 렌더링의 차이입니다.

Rasterization vs Ray Tracing

RTX란

RTX는 NVIDIA의 real-time ray tracing, AI upscaling/denoising, neural rendering 생태계를 묶어 부르는 브랜드/기술군입니다.

왜 기존 rasterization만으로는 어려운가

Rasterization은 카메라에서 보이는 표면을 빠르게 그리는 데 매우 좋습니다. 하지만 빛이 반사되고, 굴절되고, 다른 물체에 가려지고, 여러 번 튕기는 현상은 직접 계산하기 어렵습니다.

그래서 전통 렌더링은 다음 기법을 많이 씁니다.

Ray tracing은 광선을 직접 scene에 쏘기 때문에 이런 효과를 더 일관되게 다룰 수 있습니다. 대신 비싸서 real-time에서는 적은 sample + denoising + DLSS 같은 기법을 조합합니다.

Hybrid Rendering

현대 게임은 대부분 완전한 path tracing만 쓰기보다 hybrid 방식입니다.

Rasterization:
기본 geometry, visibility, 대부분의 material shading

Ray tracing:
reflection, shadow, ambient occlusion, global illumination 일부

AI:
denoising, upscaling, frame generation

근거 URL

• NVIDIA RTX technology: https://www.nvidia.com/en-us/technologies/rtx/
• NVIDIA ray tracing docs: https://docs.nvidia.com/ray-tracing/index.html
• NVIDIA RTX and DirectX Raytracing introduction: https://developer.nvidia.com/blog/introduction-nvidia-rtx-directx-raytracing/
• NVIDIA path tracing explanation: https://blogs.nvidia.com/blog/2022/03/23/what-is-path-tracing/
• NVIDIA Turing architecture ray tracing: https://developer.nvidia.com/blog/nvidia-turing-architecture-in-depth/

022. After Effects 2.5D Parallax 소개

질문

after effect 2.5D parallelX 의 소개
종이인형으로 진행하는 인형극과 같은 느낌인데 3차원 무대에서 원근카메라로 촬영하는 기법

용어 정리

parallelX는 문맥상 parallax를 의미하는 것으로 해석했습니다.

After Effects의 2.5D parallax는 2D 이미지, 일러스트, 종이 인형 같은 평면 레이어들을 3D 공간의 서로 다른 깊이/Z축에 배치하고, 카메라를 움직여 원근감과 깊이감을 만드는 기법입니다.

완전한 3D 모델링은 아니지만, 카메라 이동에 따라 앞쪽 레이어는 빠르게 움직이고 뒤쪽 레이어는 천천히 움직이므로 입체적인 무대처럼 보입니다.

한 줄 비유

종이 인형극 무대를 여러 겹으로 세워두고, 실제 카메라가 그 무대 사이를 이동하면서 찍는 느낌입니다.

flowchart LR
    C["Camera"] --> F["Foreground<br/>character/cutout"]
    F --> M["Midground<br/>props"]
    M --> B["Background<br/>sky/building"]

2.5D라고 부르는 이유

즉, “평면들을 3D 무대에 세운 것”이므로 2D와 3D의 중간 같은 느낌이 납니다.

기본 원리

카메라가 옆으로 이동할 때 가까운 물체와 먼 물체의 화면상 이동량이 다르게 보이는 현상을 parallax라고 합니다.

이 차이가 깊이감을 만듭니다.

After Effects에서 만드는 기본 순서

1. Photoshop/Illustrator에서 캐릭터, 팔, 다리, 배경, 소품을 레이어별로 분리합니다.
2. After Effects로 가져온 뒤 각 레이어의 3D Layer 스위치를 켭니다.
3. 레이어를 Z축으로 배치합니다.
4. 가까운 레이어가 너무 커지거나 작아지면 Scale을 보정합니다.
5. Layer > New > Camera로 카메라를 만듭니다.
6. 카메라를 Null Object에 parent해서 dolly, pan, orbit을 제어합니다.
7. 필요하면 Light, Shadow, Depth of Field, Motion Blur를 추가합니다.
8. 캐릭터는 Puppet Pin, Duik, RubberHose, Joysticks ‘n Sliders 같은 리깅 도구로 종이인형처럼 움직입니다.

무대 배치 예시

Z = -1200  먼 배경 산/하늘
Z = -700   건물/숲
Z = -300   무대 소품
Z = 0      캐릭터 몸통
Z = 80     팔/손/전경 장식
Camera     Z = -1800 쪽에서 바라봄

After Effects에서는 카메라/좌표계 설정에 따라 감각이 달라질 수 있으므로, 중요한 것은 숫자 자체보다 레이어 간 상대적 깊이 차이입니다.

원근카메라 느낌을 만드는 요소

종이인형극 느낌을 내는 디자인 포인트

장점

한계

2.5D Parallax와 진짜 3D의 차이

근거 URL

• Adobe, Use 3D layers in After Effects: https://helpx.adobe.com/after-effects/using/3d-layers.html
• Adobe, Cameras, lights, and points of interest: https://helpx.adobe.com/after-effects/using/cameras-lights-points-interest.html
• Adobe Learn, Animate a camera: https://www.adobe.com/learn/after-effects/web/camera-animation
• Adobe Learn, Advanced 3D renderer: https://www.adobe.com/learn/after-effects/web/work-in-3d
• Adobe Blog, 3D and motion design upgrades in After Effects: https://blog.adobe.com/en/publish/2024/09/10/adobe-introduces-3d-motion-design-upgrades-adobe-after-effects

사실 / 추정 / 검증필요

023. Android ART, DEX, JIT, AOT 설명

질문

android 의 ART DEX JIT AOT 설명

핵심 결론

Android 앱의 Kotlin/Java 코드는 최종적으로 DEX bytecode 형태로 APK/AAB 안에 들어가고, 기기에서는 ART(Android Runtime) 가 이 DEX를 실행합니다.

ART는 실행 성능과 설치 시간, 저장공간, 배터리 사이의 균형을 맞추기 위해 interpretation, JIT, AOT를 섞어 사용합니다.

전체 흐름

flowchart TB
    A["Kotlin / Java source"] --> B["javac / kotlinc<br/>.class bytecode"]
    B --> C["D8 / R8"]
    C --> D["classes.dex<br/>DEX bytecode"]
    D --> E["APK / AAB"]
    E --> F["Device install"]
    F --> G["ART"]
    G --> H["Interpreter"]
    G --> I["JIT compiler"]
    G --> J["Profile-guided AOT<br/>dex2oat -> odex/oat"]
    H --> K["Native execution"]
    I --> K
    J --> K

DEX란

DEX는 Android가 실행하는 bytecode 포맷입니다. 일반 JVM의 .class bytecode와 다릅니다.

Android 빌드 도구인 D8/R8은 Java/Kotlin 컴파일 결과를 Android용 DEX bytecode로 바꿉니다.

ART란

ART는 Android Runtime입니다. Android 앱과 일부 system service가 사용하는 managed runtime입니다. ART는 DEX format과 DEX bytecode specification을 실행합니다.

ART는 Dalvik을 대체했습니다. Android 5.0부터 ART가 기본 runtime이 되었고, Android 7부터는 AOT만 고집하지 않고 JIT/AOT/interpretation을 섞는 구조가 중요해졌습니다.

ART가 담당하는 일:

JIT란

JIT는 앱이 실행되는 동안 자주 호출되는 hot code path를 감지하고, 그 부분을 native machine code로 컴파일하는 방식입니다.

앱 첫 실행
-> 우선 interpreter로 DEX 실행
-> ART가 어떤 method가 자주 실행되는지 profile 수집
-> hot method를 JIT로 native code 컴파일
-> 이후 같은 실행 중에는 native code 사용

장점:

단점:

AOT란

AOT는 앱 실행 전에 DEX bytecode를 native machine code로 미리 컴파일하는 방식입니다.

Android에서는 dex2oat가 DEX를 OAT/ODEX artifact로 컴파일하는 핵심 경로입니다. .odex에는 APK method에 대한 AOT compiled code가 들어갈 수 있습니다.

장점:

단점:

Android가 JIT와 AOT를 섞는 이유

Android 5의 ART는 AOT 중심이었습니다. 앱 설치 시점에 많이 컴파일하므로 runtime 성능은 좋아지지만, 설치 시간이 길고 저장공간을 더 씁니다.

Android 7부터는 다음 균형을 위해 hybrid 전략을 사용합니다.

공식 AOSP 문서는 Android 7부터 ART가 AOT compilation, JIT compilation, interpretation을 조합하여 사용하고, AOT compilation은 profile-guided일 수 있다고 설명합니다.

Baseline Profile이 중요한 이유

Baseline Profile은 앱/라이브러리가 “이 코드 경로는 startup과 critical path에 중요하다”는 정보를 미리 제공하는 방식입니다.

Baseline Profile이 없으면 모든 앱 코드가 처음에는 interpreted/JIT 경로를 거치거나, device가 idle일 때 background로 odex에 기록될 수 있습니다. Baseline Profile을 제공하면 새 사용자와 업데이트 직후에도 중요한 코드가 AOT 최적화될 수 있어 startup과 jank 개선에 도움이 됩니다.

실행 시나리오

앱 설치 직후

APK 설치
-> DEX 존재
-> 일부 검증/최소 컴파일
-> baseline profile이 있으면 중요한 코드 AOT 가능

앱 첫 실행

ART가 DEX 실행
-> 미리 컴파일된 코드는 native로 실행
-> 나머지는 interpreter
-> hot code는 JIT 컴파일
-> profile 수집

앱 반복 실행/기기 idle

profile 기반으로 자주 쓰는 코드 파악
-> dex2oat background compilation
-> 다음 실행부터 더 많은 코드가 AOT artifact로 실행

JIT/AOT/Interpreter 비교

Android 개발자가 체감하는 포인트

근거 URL

• Android platform architecture, ART and DEX: https://developer.android.com/guide/platform
• AOSP, Android runtime and Dalvik: https://source.android.google.cn/docs/core/runtime?hl=en
• AOSP, Configure ART: https://source.android.com/docs/core/runtime/configure
• AOSP, Dalvik executable instruction formats: https://source.android.google.cn/docs/core/runtime/instruction-formats?hl=en
• Android Developers, Baseline Profiles overview: https://developer.android.com/topic/performance/baselineprofiles/overview
• AOSP, dex2oat source tree: https://android.googlesource.com/platform/art/+/master/dex2oat/

사실 / 추정 / 검증필요

024. Android APK와 AAB 차이점

질문

안드로이드의 apk aab 의 차이점
aab 의 장단점
aab 에 포함되는것 포함되지 않는것

핵심 결론

APK는 Android 기기에 실제로 설치되는 패키지입니다.

AAB(Android App Bundle)는 Google Play 같은 스토어에 업로드하는 게시 포맷입니다. AAB 자체가 기기에 그대로 설치되는 것이 아니라, Google Play나 bundletool이 AAB를 바탕으로 기기별 APK 또는 split APK set을 만들어 설치합니다.

설치 관점 흐름

flowchart LR
    A["Developer build"] --> B["AAB upload"]
    B --> C["Google Play / bundletool"]
    C --> D["Base APK"]
    C --> E["Config APKs<br/>ABI/density/language"]
    C --> F["Feature APKs"]
    D --> G["User device"]
    E --> G
    F --> G

사용자는 AAB를 받는 것이 아니라, 자기 기기에 필요한 APK 조합을 받습니다.

APK 안에 보통 들어가는 것

Android 공식 문서는 APK가 ZIP archive이며 앱을 구성하는 파일을 포함한다고 설명합니다.

단일 APK라면 여러 ABI, 여러 화면 밀도, 여러 언어 리소스가 한 파일에 다 들어갈 수 있습니다. 그래서 설치/다운로드 크기가 커질 수 있습니다.

AAB에 포함되는 것

AAB는 앱 코드를 모듈별로 구조화합니다.

중요한 점은 AAB가 “기기 하나에 그대로 들어갈 최종 패키지”가 아니라, 여러 기기 구성을 위한 원재료와 메타데이터를 담는다는 것입니다.

AAB에 포함되지 않거나 최종 APK에 들어가지 않는 것

AAB 장점

AAB 단점과 주의점

Split APK 종류

AAB에서 생성되는 APK 조합은 대략 다음과 같습니다.

예시

앱이 다음 리소스를 지원한다고 가정합니다.

ABI: arm64-v8a, armeabi-v7a, x86_64
Density: mdpi, hdpi, xhdpi, xxhdpi
Language: ko, en, ja
Feature: camera feature, editor feature

단일 APK 방식이면 한 파일에 여러 ABI, density, language, feature 코드가 모두 들어갈 수 있습니다.

AAB 방식이면 arm64-v8a, xxhdpi, ko인 기기에는 그 조합에 필요한 APK만 내려갑니다. x86_64 라이브러리나 일본어 리소스, 아직 쓰지 않는 on-demand feature는 초기 설치에서 빠질 수 있습니다.

APK/AAB 실무 명령

Android Studio:

Build > Generate Signed Bundle / APK

bundletool로 AAB에서 APK set 생성:

bundletool build-apks \
  --bundle=app-release.aab \
  --output=app-release.apks

연결된 기기에 맞는 APK set 생성:

bundletool build-apks \
  --connected-device \
  --bundle=app-release.aab \
  --output=app-release.apks

APK set 설치:

bundletool install-apks --apks=app-release.apks

단일 universal APK 생성:

bundletool build-apks \
  --mode=universal \
  --bundle=app-release.aab \
  --output=app-universal.apks

선택 기준

근거 URL

• About Android App Bundles: https://developer.android.com/guide/app-bundle
• Android App Bundle format: https://developer.android.com/guide/app-bundle/app-bundle-format
• Reduce your app size, App Bundle and APK structure: https://developer.android.com/topic/performance/reduce-apk-size
• bundletool documentation: https://developer.android.com/tools/bundletool
• Android App Bundle FAQ: https://developer.android.com/guide/app-bundle/faq

사실 / 추정 / 검증필요

025. Android Doze, Foreground Service, Background Service

질문

안드로이드에서
doze 모드 foreground service, background service 설명

핵심 결론

Android는 배터리를 아끼기 위해 앱이 보이지 않는 상태에서 마음대로 계속 실행되는 것을 강하게 제한합니다.

짧게 말하면:

• 즉시 끝나는 화면 내부 작업: coroutine/thread/asynchronous work
• 언젠가 해도 되는 백그라운드 작업: WorkManager/JobScheduler
• 사용자가 지금 진행 중임을 알아야 하는 중단 불가 작업: Foreground Service
• 계속 몰래 도는 background service: 현대 Android에서는 피해야 함

Doze 모드란

Doze는 기기가 전원에 연결되어 있지 않고, 화면이 꺼져 있고, 일정 시간 움직임이 없을 때 배터리 절약을 위해 들어가는 idle 모드입니다.

Doze에서 Android는 다음을 제한합니다.

Doze는 완전 정지가 아니라, 주기적으로 maintenance window를 열어 밀린 작업을 일부 수행하게 합니다. 시간이 길어질수록 maintenance window 간격이 길어질 수 있습니다.

Doze 대응 방식

Android 공식 문서는 setAndAllowWhileIdle()과 setExactAndAllowWhileIdle()도 앱당 9분에 한 번보다 더 자주 발동할 수 없다고 안내합니다.

Background Service란

Background service는 사용자가 앱 화면을 보고 있지 않고, foreground service notification도 없는 상태에서 도는 service입니다.

Android 8.0(API 26)부터 background service는 강하게 제한됩니다. 앱이 idle 상태가 되면 background service 사용에 제한이 생기며, 많은 경우 JobScheduler나 WorkManager로 바꾸는 것이 권장됩니다.

예전 방식:

startService(Intent(this, SyncService::class.java))

현대 Android에서는 주기적/지연 가능한 동기화라면 보통:

WorkManager.getInstance(context).enqueue(workRequest)

쪽을 먼저 검토합니다.

Foreground Service란

Foreground service는 사용자가 앱을 직접 보고 있지 않아도, 사용자가 인지할 수 있는 중요한 작업을 계속 수행하기 위한 service입니다. 반드시 상태바 notification을 표시해야 합니다.

대표 예:

부적합한 사용:

Foreground Service 시작 흐름

Android 8.0+에서 background service를 만든 뒤 나중에 foreground로 올리는 방식은 문제가 됩니다. 새 foreground service는 startForegroundService()로 시작하고, 생성 후 제한 시간 안에 startForeground()를 호출해 notification을 보여야 합니다.

ContextCompat.startForegroundService(
    context,
    Intent(context, UploadService::class.java)
)

Service 내부:

class UploadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        startForeground(NOTIFICATION_ID, buildNotification())
        // 실제 업로드 작업 시작
        return START_NOT_STICKY
    }
}

Android 8.0 문서는 startForegroundService() 후 startForeground()를 5초 안에 호출하지 않으면 시스템이 service를 중지하고 ANR로 처리한다고 설명합니다.

Android 12+ 백그라운드 시작 제한

Android 12(API 31)+를 target하는 앱은 앱이 background 상태일 때 foreground service를 마음대로 시작할 수 없습니다. 예외가 아니면 ForegroundServiceStartNotAllowedException이 발생합니다.

허용 예외의 대표 사례:

Android 14+ foreground service type

Android 14를 target하면 foreground service type을 manifest에 선언해야 합니다.

예:

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />

<service
    android:name=".RunTrackingService"
    android:foregroundServiceType="location"
    android:exported="false" />

대표 type:

Android 14+에서는 type 누락 시 MissingForegroundServiceTypeException, type별 permission 누락 시 SecurityException이 날 수 있습니다.

Android 15+ timeout

Android 15+를 target하면 일부 foreground service type은 background 상태에서 실행 시간 제한을 받습니다.

timeout이 오면 Service.onTimeout(int, int)가 호출되고, service가 곧 stopSelf()하지 않으면 crash로 이어질 수 있습니다.

Background Service vs Foreground Service vs WorkManager

실무 설계 가이드

Doze 테스트 명령

공식 문서는 adb로 Doze와 App Standby를 강제로 테스트하는 방법을 안내합니다.

adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

App Standby 테스트:

adb shell dumpsys battery unplug
adb shell am set-inactive <packageName> true
adb shell am set-inactive <packageName> false
adb shell am get-inactive <packageName>

근거 URL

• Android Doze and App Standby: https://developer.android.com/training/monitoring-device-state/doze-standby
• Android Background execution limits: https://developer.android.com/about/versions/oreo/background.html
• Android Background tasks overview: https://developer.android.com/develop/background-work/background-tasks
• Android Services overview: https://developer.android.com/develop/background-work/services
• Android Foreground services overview: https://developer.android.com/develop/background-work/services/fgs
• Android restrictions on starting foreground services from background: https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start
• Android foreground service types required: https://developer.android.com/about/versions/14/changes/fgs-types-required
• Android foreground service timeout: https://developer.android.com/develop/background-work/services/fgs/timeout

사실 / 추정 / 검증필요

026. Android SurfaceView, GLSurfaceView, TextureView 차이점

질문

안드로이드에서 SurfaceView, GLSurfaceView, TextureView 차이점

핵심 결론

세 클래스는 모두 “동영상, 카메라 preview, OpenGL 렌더링처럼 일반 View drawing과 다른 고성능 화면 출력”에 쓰이지만, 화면에 합성되는 방식이 다릅니다.

짧게 선택하면:

• 동영상/카메라/게임처럼 성능과 배터리가 중요하면 SurfaceView
• OpenGL ES를 빠르게 붙이고 싶고 EGL/thread를 직접 관리하기 싫으면 GLSurfaceView
• 회전, 알파, scale, clip, View animation과 자연스럽게 섞어야 하면 TextureView

구조 차이

flowchart TB
    A["App View Hierarchy"] --> B["Normal Views<br/>TextView/Button/etc."]
    A --> C["SurfaceView<br/>separate Surface layer"]
    A --> D["TextureView<br/>drawn as regular View"]
    C --> E["SurfaceFlinger / Hardware Composer"]
    D --> F["App UI GPU composition"]
    F --> E
    G["GLSurfaceView"] --> C
    G --> H["EGL context + GL render thread"]

SurfaceView

SurfaceView는 View hierarchy 안에 들어가지만, 실제 콘텐츠는 앱 UI buffer와 다른 별도 Surface에 그려집니다. 이 Surface는 SurfaceFlinger/Hardware Composer가 앱 UI layer와 함께 합성합니다.

장점:

단점:

중요한 lifecycle:

Activity: onCreate -> onResume
Surface:  surfaceCreated -> surfaceChanged

Back:
Activity: onPause
Surface:  surfaceDestroyed

하지만 화면 꺼짐 같은 상황에서는 onPause()만 오고 Surface가 유지될 수도 있습니다. 그래서 Surface 상태와 Activity 상태를 분리해서 생각해야 합니다.

GLSurfaceView

GLSurfaceView는 SurfaceView의 subclass입니다. OpenGL ES를 쓰기 위해 필요한 EGL display/context/surface, render thread, Renderer callback, pause/resume 처리를 대신 관리해 줍니다.

공식 문서상 GLSurfaceView가 제공하는 기능:

기본 사용:

class MyGLView(context: Context) : GLSurfaceView(context) {
    init {
        setEGLContextClientVersion(2)
        setRenderer(MyRenderer())
        renderMode = RENDERMODE_CONTINUOUSLY
    }
}

class MyRenderer : GLSurfaceView.Renderer {
    override fun onSurfaceCreated(gl: GL10?, config: EGLConfig?) {
        // shader/program/texture 초기화
    }

    override fun onSurfaceChanged(gl: GL10?, width: Int, height: Int) {
        GLES20.glViewport(0, 0, width, height)
    }

    override fun onDrawFrame(gl: GL10?) {
        // draw
    }
}

장점:

단점:

TextureView

TextureView는 SurfaceTexture를 감싼 View입니다. 카메라 preview, video, OpenGL scene 같은 content stream을 표시할 수 있습니다. SurfaceView와 달리 별도 window/layer를 만들지 않고 일반 View처럼 동작합니다.

장점:

단점:

기본 lifecycle:

textureView.surfaceTextureListener = object : TextureView.SurfaceTextureListener {
    override fun onSurfaceTextureAvailable(st: SurfaceTexture, w: Int, h: Int) {
        val surface = Surface(st)
        // MediaPlayer / Camera / EGL target으로 전달
    }

    override fun onSurfaceTextureDestroyed(st: SurfaceTexture): Boolean {
        // true면 TextureView가 SurfaceTexture release
        // false면 앱이 직접 유지/해제 책임
        return true
    }

    override fun onSurfaceTextureSizeChanged(st: SurfaceTexture, w: Int, h: Int) {}
    override fun onSurfaceTextureUpdated(st: SurfaceTexture) {}
}

비교표

선택 기준

실무에서 자주 겪는 문제

근거 URL

• Android SurfaceView API: https://developer.android.com/reference/android/view/SurfaceView
• Android TextureView API: https://developer.android.com/reference/android/view/TextureView
• Android GLSurfaceView API: https://developer.android.com/reference/android/opengl/GLSurfaceView
• Android GLSurfaceView.Renderer API: https://developer.android.com/reference/android/opengl/GLSurfaceView.Renderer
• AOSP, SurfaceView and GLSurfaceView: https://source.android.com/docs/core/graphics/arch-sv-glsv
• AOSP, TextureView: https://source.android.com/docs/core/graphics/arch-tv
• Android OpenGL ES guide: https://developer.android.com/guide/topics/graphics/opengl.html

사실 / 추정 / 검증필요

027. 카메라/라이브 스트리밍에서 프레임 timestamp가 0이 아닌 값부터 시작하는 경우

질문

멀티미디어에서
카메라 촬영할때 혹은 라이브 스트리밍 rtmp 퍼블리시 할때
각 프레임의 타임스탬프가 0부터 시작하는 것으로 알고 있는데
0이 아닌값부터 시작할때가 있는가?

핵심 결론

있습니다.

다만 “timestamp가 0부터 시작한다”는 말은 보통 파일/스트림 세션 내부의 presentation timeline을 0으로 정규화한다는 뜻입니다. 카메라 센서가 주는 원본 timestamp나 RTP/RTMP/인코더 내부 timestamp는 0이 아닌 큰 값에서 시작할 수 있습니다.

왜 0이 아닌 값이 나오나

1. 카메라 timestamp는 “녹화 시작 후 경과시간”이 아닐 수 있음

Android Camera2의 SENSOR_TIMESTAMP는 nanoseconds 단위의 monotonic timestamp입니다. SENSOR_INFO_TIMESTAMP_SOURCE가 REALTIME이면 elapsedRealtimeNanos()와 같은 timebase로 센서 timestamp를 다룰 수 있습니다. UNKNOWN이면 같은 camera device 안에서 비교 가능한 monotonic timestamp지만 다른 time source와 직접 비교는 보장되지 않습니다.

즉, 첫 프레임 timestamp가 다음처럼 큰 값일 수 있습니다.

cameraFrame.timestamp = 48,382,912,345,678 ns

이 값은 “촬영 시작 후 48,382초”라는 뜻이 아니라, 시스템 부팅 후 경과 시간 같은 monotonic timebase 위의 값일 수 있습니다.

RTMP로 보낼 때는 보통:

val firstNs = firstCameraTimestampNs
val rtmpTimestampMs = (cameraTimestampNs - firstNs) / 1_000_000

처럼 첫 프레임 기준으로 0부터 다시 맞춥니다.

2. 인코더 PTS는 앱이 정한다

Android MediaCodec의 presentationTimeUs는 해당 buffer가 재생/표시되어야 하는 media time입니다. ByteBuffer 입력 방식이라면 앱이 queueInputBuffer(..., presentationTimeUs, ...)에 직접 넣습니다.

따라서 앱이 아래처럼 넣으면 0부터 시작합니다.

0 us
33,333 us
66,666 us
...

하지만 카메라 timestamp를 그대로 microseconds로 바꿔 넣으면 다음처럼 시작할 수 있습니다.

48,382,912,345 us
48,382,945,678 us
48,382,979,011 us
...

즉, 인코더는 “첫 값이 반드시 0이어야 한다”기보다, timeline이 일관되고 증가해야 제대로 동작합니다. 다만 muxer/streaming protocol/플레이어 호환성 때문에 0 기반 정규화를 하는 경우가 많습니다.

3. RTMP spec 자체는 type-0 chunk timestamp를 absolute timestamp라고만 설명한다

RTMP chunk stream에서 type-0 chunk header의 timestamp는 해당 message의 absolute timestamp입니다. RTMP spec은 timestamp field, timestamp delta, extended timestamp를 설명하지만, publish session의 첫 media timestamp가 반드시 0이어야 한다고 강제하는 식으로 쓰지는 않습니다.

그래서 기술적으로는 첫 video message timestamp가 12345 ms일 수도 있습니다. 다만 실제 RTMP ingest server, player, recorder, transmuxer 호환성을 위해 라이브 publish에서는 보통 0 또는 0에 가까운 값부터 시작시키는 것이 안전합니다.

4. RTSP/RTP를 RTMP로 relay하면 원본 timestamp가 0 기반이 아닐 수 있음

RTP timestamp는 media clock 위의 값이며, 보안/동기화 이유로 임의 초기값을 쓰는 경우가 많습니다. RTSP camera에서 받은 RTP timestamp를 그대로 RTMP timestamp로 옮기면 첫 값이 0이 아닐 수 있습니다.

relay/transmuxer는 보통 다음 작업을 합니다.

input RTP timestamp: 3,291,442,120
first RTP timestamp: 3,291,442,120
relative timestamp: input - first
RTMP timestamp ms: relative / media_clock_rate * 1000

이 정규화를 하지 않으면 일부 서버/플레이어가 timestamp gap, 음성/영상 sync 문제, 비정상 duration을 겪을 수 있습니다.

5. B-frame이 있으면 PTS/DTS가 분리된다

H.264/H.265에 B-frame이 있으면 display order와 decode order가 다릅니다.

RTMP/FLV의 H.264 video tag timestamp는 실무적으로 decode timeline에 가깝게 쓰이고, AVC video packet에는 composition time offset이 들어가 PTS를 표현합니다.

간단히:

PTS = DTS + compositionTime

그래서 첫 DTS는 0이어도 첫 PTS가 0보다 크거나, 내부 계산상 음수 PTS 보정을 위해 전체 timeline을 밀어 non-zero로 시작시키는 muxer도 있습니다.

언제 0부터 시작해야 하나

실무 구현 패턴

카메라 프레임 timestamp 정규화

var firstVideoNs: Long? = null

fun toVideoPtsUs(cameraTimestampNs: Long): Long {
    val first = firstVideoNs ?: cameraTimestampNs.also { firstVideoNs = it }
    return (cameraTimestampNs - first) / 1_000
}

RTMP timestamp 변환

val ptsUs = toVideoPtsUs(cameraTimestampNs)
val rtmpTimestampMs = ptsUs / 1000

Audio와 Video를 같은 기준에 맞추기

오디오와 비디오를 따로 0으로 만들면 A/V sync가 깨질 수 있습니다. 공통 시작 기준을 잡는 것이 좋습니다.

sessionStartNs = min(firstVideoNs, firstAudioNs)

videoPtsUs = (videoFrameNs - sessionStartNs) / 1000
audioPtsUs = (audioFrameNs - sessionStartNs) / 1000

다만 오디오 API의 timestamp timebase와 카메라 timestamp timebase가 같은지 확인해야 합니다. 서로 다른 clock이면 직접 빼면 안 되고, 변환/동기화가 필요합니다.

0이 아닌 timestamp가 문제를 만드는 경우

권장 결론

라이브 RTMP publish에서는 아래 원칙이 가장 안전합니다.

1. 카메라/오디오 원본 timestamp는 수집 단계에서 보존합니다.
2. publish session 시작 시 공통 기준 sessionStart를 잡습니다.
3. RTMP로 보낼 때는 timestamp = now - sessionStart 형태로 0 기반 상대 시간으로 보냅니다.
4. timestamp는 audio/video 모두 같은 timeline을 사용합니다.
5. RTMP timestamp는 ms 단위이므로 us/ns에서 변환할 때 rounding 누적 오차를 조심합니다.
6. B-frame을 쓰면 PTS/DTS/composition time 처리를 분리해서 봅니다.
7. reconnect는 새 publish session이면 0부터 다시 시작하는 것이 보통 안전합니다.

근거 URL

• Android CameraCharacteristics SENSOR_INFO_TIMESTAMP_SOURCE: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#SENSOR_INFO_TIMESTAMP_SOURCE
• Android Image timestamp / CameraX ImageInfo: https://developer.android.com/reference/androidx/camera/core/ImageInfo#getTimestamp()
• Android MediaCodec presentationTimeUs: https://developer.android.com/reference/android/media/MediaCodec.QueueRequest#setPresentationTimeUs(long)
• Android MediaMuxer: https://developer.android.com/reference/android/media/MediaMuxer
• Adobe RTMP Specification: https://rtmp.veriskope.com/docs/spec/
• Adobe Flash Video File Format Specification mirror: https://docslib.org/doc/3399949/adobe-flash-video-file-format-specification-10-1-2-01
• RTP specification, RFC 3550: https://www.rfc-editor.org/rfc/rfc3550

사실 / 추정 / 검증필요

028. Android JNI에서 문자열, 숫자형, 구조체, class 객체를 주고받을 때 주의점

질문

안드로이드 jni로 문자열, 숫자형, 구조체, class객체들을 앱과 so 간 통신할때 주의할 점?

핵심 결론

JNI는 Java/Kotlin 세계와 C/C++ .so 세계를 잇는 강력한 통로지만, 타입/메모리/스레드/예외 규칙을 잘못 다루면 크래시가 매우 쉽게 납니다.

가장 중요한 원칙은 다음입니다.

JNI 타입 대응

문자열 주의점

1. GetStringUTFChars는 일반 UTF-8이 아니라 Modified UTF-8

JNI의 GetStringUTFChars는 Modified UTF-8을 반환합니다. 일반 UTF-8 라이브러리에 그대로 넘겨도 대부분 ASCII/한글은 문제가 없어 보일 수 있지만, NUL, surrogate pair 같은 edge case에서 차이가 생길 수 있습니다.

extern "C"
JNIEXPORT void JNICALL
Java_com_example_NativeBridge_sendString(JNIEnv* env, jobject thiz, jstring text) {
    const char* chars = env->GetStringUTFChars(text, nullptr);
    if (chars == nullptr) {
        return; // OutOfMemoryError 등 exception pending 가능
    }

    // chars 사용

    env->ReleaseStringUTFChars(text, chars);
}

주의:

2. UTF-16이 필요하면 GetStringChars

Java/Kotlin String은 개념적으로 UTF-16 code unit 기반입니다. C++에서 UTF-16로 처리하는 것이 맞으면 GetStringChars를 씁니다.

const jchar* utf16 = env->GetStringChars(text, nullptr);
jsize len = env->GetStringLength(text);
// utf16[0..len)
env->ReleaseStringChars(text, utf16);

3. C 문자열을 Java String으로 만들 때

jstring result = env->NewStringUTF("hello");
return result;

NewStringUTF 역시 Modified UTF-8 입력을 기대합니다. 임의 binary data를 String으로 보내지 말고 byte[]나 ByteBuffer를 쓰는 편이 안전합니다.

숫자형 주의점

숫자형은 단순해 보이지만, ABI와 부호/크기 혼동이 자주 납니다.

native pointer handle 패턴:

class NativeSession {
public:
    void start();
    void stop();
};

extern "C"
JNIEXPORT jlong JNICALL
Java_com_example_NativeBridge_nativeCreate(JNIEnv* env, jobject thiz) {
    auto* session = new NativeSession();
    return static_cast<jlong>(reinterpret_cast<intptr_t>(session));
}

extern "C"
JNIEXPORT void JNICALL
Java_com_example_NativeBridge_nativeDestroy(JNIEnv* env, jobject thiz, jlong handle) {
    auto* session = reinterpret_cast<NativeSession*>(static_cast<intptr_t>(handle));
    delete session;
}

Kotlin 쪽:

class NativeBridge {
    private var handle: Long = nativeCreate()

    external fun nativeCreate(): Long
    external fun nativeDestroy(handle: Long)

    fun close() {
        val h = handle
        if (h != 0L) {
            handle = 0
            nativeDestroy(h)
        }
    }
}

주의: handle은 권한 없는 포인터 노출이므로 외부 입력으로 받으면 안 됩니다. 멀티스레드에서 close/use가 동시에 일어나지 않게 소유권을 설계해야 합니다.

배열과 버퍼 주의점

Java primitive array

jbyte* data = env->GetByteArrayElements(array, nullptr);
if (data == nullptr) return;
jsize len = env->GetArrayLength(array);

// data 사용

env->ReleaseByteArrayElements(array, data, JNI_ABORT);

Release mode:

읽기만 했다면 JNI_ABORT가 안전합니다.

Critical array

GetPrimitiveArrayCritical은 GC를 오래 막을 수 있어 매우 짧게 써야 합니다. 이 구간에서는 blocking I/O, JNI 재진입, 긴 계산을 피하는 것이 좋습니다.

DirectByteBuffer

대용량 binary data나 구조체 blob을 자주 주고받는다면 DirectByteBuffer가 좋을 수 있습니다.

Java/Kotlin:

val buffer = ByteBuffer.allocateDirect(size)
nativeFill(buffer)

C++:

void* ptr = env->GetDirectBufferAddress(buffer);
jlong cap = env->GetDirectBufferCapacity(buffer);

주의:

구조체를 주고받을 때

Java/Kotlin에는 C struct와 같은 memory layout 보장이 없습니다. JNI로 구조체를 주고받는 방법은 여러 가지가 있습니다.

struct를 그대로 memcpy하지 말아야 하는 이유

struct Foo {
    int32_t id;
    double value;
    bool enabled;
};

이 struct는 compiler, ABI, packing option에 따라 padding이 달라질 수 있습니다.

안전한 binary format 예:

offset  size  type
0       4     int32 little-endian id
4       8     double little-endian value
12      1     uint8 enabled
13      3     reserved

이렇게 명시적으로 layout을 정하면 Java/Kotlin과 C++ 양쪽에서 같은 의미로 읽을 수 있습니다.

class 객체와 field/method 접근 주의점

Java/Kotlin 객체를 native로 넘기면 jobject입니다. native에서 field/method를 접근하려면 GetObjectClass, GetFieldID, GetMethodID, Get<Type>Field, Call<Type>Method를 씁니다.

jclass cls = env->GetObjectClass(obj);
jfieldID idField = env->GetFieldID(cls, "id", "I");
jint id = env->GetIntField(obj, idField);
env->DeleteLocalRef(cls);

문제는 이 작업을 매 frame/매 sample마다 반복하면 느립니다.

권장:

JNI_OnLoad에서 캐시:

static JavaVM* g_vm = nullptr;
static jclass g_eventClass = nullptr;
static jmethodID g_eventCtor = nullptr;

jint JNI_OnLoad(JavaVM* vm, void*) {
    g_vm = vm;
    JNIEnv* env = nullptr;
    if (vm->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6) != JNI_OK) {
        return JNI_ERR;
    }

    jclass local = env->FindClass("com/example/Event");
    if (local == nullptr) return JNI_ERR;

    g_eventClass = reinterpret_cast<jclass>(env->NewGlobalRef(local));
    env->DeleteLocalRef(local);

    g_eventCtor = env->GetMethodID(g_eventClass, "<init>", "(IJ)V");
    if (g_eventCtor == nullptr) return JNI_ERR;

    return JNI_VERSION_1_6;
}

주의:

LocalRef / GlobalRef / WeakGlobalRef

JNI의 jobject류는 C++ raw pointer처럼 보이지만 실제로는 VM reference입니다.

반복문에서 많은 객체를 만들면 local reference table overflow가 날 수 있습니다.

for (int i = 0; i < count; ++i) {
    jstring s = env->NewStringUTF(items[i].c_str());
    env->CallVoidMethod(list, addMethod, s);
    env->DeleteLocalRef(s);
}

스레드 주의점

JNIEnv*는 thread-local입니다. 한 thread에서 받은 JNIEnv*를 다른 thread에서 쓰면 안 됩니다.

native C++ thread에서 Java를 호출하려면:

JNIEnv* env = nullptr;
bool attached = false;

if (g_vm->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6) != JNI_OK) {
    if (g_vm->AttachCurrentThread(&env, nullptr) != JNI_OK) {
        return;
    }
    attached = true;
}

// env 사용

if (attached) {
    g_vm->DetachCurrentThread();
}

주의:

예외 처리 주의점

JNI에서 Java method/field/class lookup을 호출하면 Java exception이 pending 상태가 될 수 있습니다. pending exception이 있는 상태에서 대부분의 JNI 호출을 계속하면 문제가 생깁니다.

env->CallVoidMethod(obj, method);
if (env->ExceptionCheck()) {
    env->ExceptionDescribe(); // debug only
    env->ExceptionClear();
    // native error path
    return;
}

C++ exception을 Java/Kotlin으로 그대로 던지면 안 됩니다. native 내부에서 잡고 Java exception으로 변환합니다.

jclass ex = env->FindClass("java/lang/IllegalStateException");
env->ThrowNew(ex, "native session is closed");
env->DeleteLocalRef(ex);