lgvv98

Express req.query와 query parser

lgvv — Tue, 7 Jul 2026 00:58:37 +0900

Express req.query와 query parser

Express에서 query string이 req.query로 어떻게 들어오는지 정리.

특히 같은 query key를 여러 번 보냈을 때 왜 배열로 바뀌는지 헷갈려서 정리.

이 글은 Express 5의 기본 query parser인 simple 기준으로 하며, Express 4는 기본값이 extended였으므로 버전에 따라 parser가 다를 수 있음.

예제 요청

아래처럼 같은 key인 tags를 여러 번 보낸다고 가정.

GET /example/info/b?tags=node&tags=express&tags=javascript

Express에서 req.query를 찍으면 아래처럼 보임.

[Object: null prototype] {
  tags: ["node", "express", "javascript"]
}

tags가 하나의 문자열이 아니라 배열로 들어옴.

app.get("/example/info/b", (req, res) => {
  console.log(req.query);

  const tags = req.query.tags;

  res.send({
    tags,
    message: `선택한 태그: ${Array.isArray(tags) ? tags.join(", ") : tags}`,
  });
});

왜 배열이 되는지

Express가 URL의 query string을 읽고 req.query 객체를 만드는 과정에서 생김.

다만 Express가 직접 같은 key를 하나씩 검사해서 배열로 만드는 구조는 아니며, Express는 설정된 query parser를 호출하고, 실제 변환은 parser가 담당.

query parser 설정

Express에는 query parser 설정이 있음.

Express 5 기준 기본값은 simple.

app.set("query parser", "simple");

이 설정은 아래 의미.

query string을 파싱할 때 simple parser 사용

처음에는 app.set이 배열 변환을 직접 하는 줄 알았는데, 그건 아니었음.

app.set은 Express 앱의 설정값을 저장하는 메서드로 아래처럼 나눌 수 있음.

app.set("query parser", "simple")
-> 어떤 query parser를 쓸지 설정

parser
-> query string을 실제 객체로 변환

simple query parser

Express에서 query parser 설정이 simple이면 Node 내장 모듈인 querystring.parse를 사용.

case "simple":
  fn = querystring.parse;
  break;

즉 simple은 query string 파싱에 querystring.parse에 사용.

실제 배열 변환

실제 query string을 객체로 바꾸는 동작은 querystring.parse에서 일어남.

const querystring = require("querystring");

querystring.parse("tags=node&tags=express&tags=javascript");

결과:

[Object: null prototype] {
  tags: ["node", "express", "javascript"]
}

같은 key인 tags가 여러 번 나오므로 값들을 배열로 묶음.

Node 문서 예제도 같은 흐름.

querystring.parse("foo=bar&abc=xyz&abc=123");

결과는 아래처럼 abc가 배열이 됨.

{
  foo: "bar",
  abc: ["xyz", "123"]
}

전체 흐름

정리하면 아래 흐름.

URL 요청
/example/info/b?tags=node&tags=express&tags=javascript

-> Express가 ? 뒤의 query string 확인
tags=node&tags=express&tags=javascript

-> app 설정에서 query parser 확인
query parser = "simple"

-> simple 설정이므로 querystring.parse 사용

-> 같은 key가 여러 번 있으므로 배열로 변환
{
  tags: ["node", "express", "javascript"]
}

-> req.query에 들어감

역할만 다시 보면 아래처럼 정리해볼 수 있음.

app.set(...)
-> 어떤 parser를 쓸지 설정

querystring.parse(...)
-> query string을 실제 객체로 변환
-> 같은 key가 여러 번 있으면 배열로 만듦

[Object: null prototype] 정리

로그에 아래처럼 찍히는 경우가 있음.

[Object: null prototype] { tags: ["node", "express"] }

Node의 querystring.parse가 일반 객체 {}와 조금 다른 객체를 만들어서 그렇게 보이는 것.

Node 문서 기준으로도 querystring.parse가 반환하는 객체는 Object.prototype을 상속하지 않음.

지금 단계에서는 크게 신경쓰지 않아도 괜찮아 보임.

중요한 건 req.query.tags가 배열로 들어올 수 있다는 점.

const tags = req.query.tags;

console.log(Array.isArray(tags)); // true
console.log(tags[0]); // "node"
console.log(tags[1]); // "express"

하나만 보내면 문자열

같은 key가 여러 번 들어오면 배열.

하나만 들어오면 문자열.

GET /example/info/b?tags=node

결과:

{
  tags: "node"
}

그래서 tags를 무조건 배열이라고 생각하면 헷갈릴 수 있음.

실제로는 문자열일 수도 있고 배열일 수도 있음.

그래서 사용할 때 한 번 정규화해두는 편이 안전해 보임.

const tags = req.query.tags;

const tagList = Array.isArray(tags)
  ? tags
  : tags
  ? [tags]
  : [];

이렇게 하면 이후 로직에서는 tagList를 배열로만 다룰 수 있음.

extended parser를 쓰면?

query parser를 extended로 바꾸면 qs 모듈 기반으로 파싱.

app.set("query parser", "extended");

simple보다 복잡한 query string을 다룰 수 있음.

예를 들면 아래처럼 중첩된 형태.

GET /users?filter[name]=kim

다만 지금 글에서 헷갈린 포인트는 같은 key가 여러 번 들어왔을 때 배열이 되는 이유.

이 케이스는 simple 기준으로는 querystring.parse가 처리한다고 이해할 수 있음.

정리

req.query는 Express가 query string을 파싱해서 만들어주는 객체로 Express 5 기준 기본 query parser는 simple.

simple은 Node 내장 querystring.parse를 사용하며, 같은 key가 여러 번 오면 querystring.parse가 값을 배열로 묶음.

tags=node&tags=express&tags=javascript

결과:

{
  tags: ["node", "express", "javascript"]
}

반대로 하나만 오면 문자열.

{
  tags: "node"
}

따라서 req.query.tags를 사용할 때는 문자열과 배열 가능성을 같이 고려하는 편이 안전해 보임.

(참고)
https://expressjs.com/en/5x/api/application/
https://expressjs.com/en/5x/api/request/
https://nodejs.org/api/querystring.html

Express app.param vs app.get

lgvv — Tue, 7 Jul 2026 00:56:27 +0900

Express app.param vs app.get

Express에서 app.get과 app.param에 대해서 간단하게 정리

둘 다 라우팅 과정에서 나오고, 둘 다 userId 같은 값을 다룰 수 있어서 처음에는 비슷해 보임.

간단히 보면 아래처럼 구분.

app.get(path, handler)
-> GET 요청을 실제로 처리하는 라우트 핸들러

app.param(name, handler)
-> 특정 path parameter가 있는 라우트 앞에서 먼저 실행되는 전처리 함수

여기서 말하는 app.get은 app.get("port")처럼 앱 설정값을 읽는 메서드가 아님.

HTTP GET 라우트를 등록하는 app.get(path, handler) 기준으로 정리.

기준

구분	역할
app.get	요청을 받아 응답을 보냄
app.param	라우트 핸들러 전에 path parameter를 미리 처리
req.params	/users/:userId처럼 경로에 들어간 값을 읽음
req.query	/users?role=admin처럼 ? 뒤에 붙은 값을 읽음

app.get은 실제 요청을 처리하는 곳.

app.param은 그 전에 공통 검증이나 조회를 끼워 넣는 방법.

app.get

app.get은 특정 경로로 GET 요청이 들어왔을 때 실행.

app.get("/users/:userId", (req, res) => {
  res.send(`userId: ${req.params.userId}`);
});

위 코드는 아래 요청을 처리.

GET /users/1

/users/:userId 라우트에 GET 요청이 들어오면 콜백 함수가 실행됨.

여기서 :userId 자리에 들어온 값은 req.params.userId로 꺼냄.

app.get("/users/:userId", (req, res) => {
  console.log(req.params.userId); // "1"
  res.send("OK");
});

라우트 핸들러 안에서는 query string도 읽을 수 있음.

GET /users/1?tab=posts

app.get("/users/:userId", (req, res) => {
  console.log(req.params.userId); // "1"
  console.log(req.query.tab); // "posts"

  res.send("OK");
});

따라서 app.get은 요청을 받고, 필요한 값을 읽고, 응답을 보내는 곳이라고 보면 됨.

app.param

app.param은 라우트 경로에 특정 path parameter가 있을 때 먼저 실행.

app.param("userId", (req, res, next, id) => {
  console.log("userId:", id);
  next();
});

Express는 param callback에 (req, res, next, value, name) 순서로 값을 넘김.

보통은 네 번째 값만 id처럼 이름 붙여 받아도 충분.

여기서 "userId"는 라우트의 :userId와 이름이 같아야 함.

app.get("/users/:userId", (req, res) => {
  res.send("User page");
});

요청이 이렇게 들어오면:

GET /users/1

실행 순서는 아래처럼 됨.

app.param("userId", ...)
-> app.get("/users/:userId", ...)

즉 app.get으로 바로 가는 게 아니라 app.param("userId")를 먼저 거침.

Express가 라우트를 매칭하는 과정에서 :userId를 발견하고, 그 이름에 등록된 param callback을 먼저 실행하는 흐름.

왜 app.param을 쓰는지

사용자 정보를 가져오는 라우트가 여러 개 있다고 가정.

app.get("/users/:userId", (req, res) => {
  const user = getUserById(req.params.userId);

  if (!user) {
    return res.status(404).send("User not found");
  }

  res.json(user);
});

app.get("/blogs/:userId", (req, res) => {
  const user = getUserById(req.params.userId);

  if (!user) {
    return res.status(404).send("User not found");
  }

  res.json({
    message: `${user.name}님의 블로그입니다.`,
    user,
  });
});

위 코드에서는 사용자 조회와 404 처리가 반복됨.

const user = getUserById(req.params.userId);

if (!user) {
  return res.status(404).send("User not found");
}

이런 코드를 app.param으로 분리 가능.

app.param("userId", (req, res, next, id) => {
  const user = getUserById(id);

  if (!user) {
    return res.status(404).send("User not found");
  }

  req.user = user;
  next();
});

이후 라우트 핸들러에서는 이미 조회된 req.user만 사용.

app.get("/users/:userId", (req, res) => {
  res.json(req.user);
});

app.get("/blogs/:userId", (req, res) => {
  res.json({
    message: `${req.user.name}님의 블로그입니다.`,
    user: req.user,
  });
});

이렇게 하면 사용자 조회와 검증을 한 곳에서 관리.

다만 모든 로직을 app.param으로 빼는 게 항상 좋은 건 아님.

한 라우트에서만 쓰는 코드라면 그냥 app.get 안에 두는 편이 더 읽기 쉬움.

여러 라우트에서 같은 path parameter를 기준으로 같은 검증이나 조회를 반복할 때 app.param을 사용하면 좋음.

전체 예제

const express = require("express");
const app = express();

app.param("userId", (req, res, next, id) => {
  const user = getUserById(id);

  if (!user) {
    return res.status(404).send("User not found");
  }

  req.user = user;
  next();
});

app.get("/users/:userId", (req, res) => {
  res.json(req.user);
});

app.get("/blogs/:userId", (req, res) => {
  res.json({
    message: `${req.user.name}님의 블로그입니다.`,
    user: req.user,
  });
});

function getUserById(id) {
  const users = {
    "1": { id: 1, name: "Alice", role: "Admin" },
    "2": { id: 2, name: "Bob", role: "User" },
  };

  return users[id];
}

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

요청예제

GET http://localhost:3000/users/1

응답:

{
  "id": 1,
  "name": "Alice",
  "role": "Admin"
}

GET http://localhost:3000/blogs/1

응답:

{
  "message": "Alice님의 블로그입니다.",
  "user": {
    "id": 1,
    "name": "Alice",
    "role": "Admin"
  }
}

없는 사용자를 요청하면:

GET http://localhost:3000/users/999

응답:

User not found

실행 순서

GET /users/1 요청이 들어오면 흐름은 대략 아래와 같음.

1. Express가 /users/:userId 라우트 확인
2. :userId가 있으므로 app.param("userId") 실행
3. getUserById("1") 실행
4. req.user에 사용자 정보 저장
5. next() 호출
6. app.get("/users/:userId") 실행
7. res.json(req.user) 응답

GET /blogs/1도 동일.

라우트는 다르지만 둘 다 :userId를 가지고 있으므로 같은 app.param("userId")를 먼저 거침.

그래서 app.param은 라우트마다 반복되는 parameter 기반 전처리에 잘 맞음.

예를 들면 아래와 같은 작업이 잘 어울림.

id 형식 검증
사용자 조회
권한 확인
없는 리소스에 대한 404 처리

path params와 query params 차이

app.param을 이해하려면 path params와 query params를 먼저 구분해야 함.

path params

GET /users/1

app.get("/users/:userId", (req, res) => {
  console.log(req.params.userId); // "1"
});

/users/:userId에서 :userId 자리에 들어간 값이 req.params.userId에 들어감.

보통 특정 리소스를 식별할 때 사용.

/users/1
-> 1번 사용자

query params

GET /users?userId=1

app.get("/users", (req, res) => {
  console.log(req.query.userId); // "1"
});

? 뒤에 붙은 값들은 req.query에 들어감.

검색, 필터, 정렬, 페이지네이션 같은 조건에 자주 사용.

/users?role=admin
-> 사용자 목록 중 role이 admin인 것만 조회

그러면 query도 app.get에서 가져올 수 있을까? (O)

app.get 안에서는 req.params도 읽을 수 있고 req.query도 읽을 수 있음.

app.get("/users/:userId", (req, res) => {
  console.log(req.params.userId);
  console.log(req.query.tab);
});

다만 app.param은 query parameter에는 반응하지 않음.

app.param("userId", (req, res, next, id) => {
  console.log(id);
  next();
});

app.get("/users", (req, res) => {
  res.send(req.query.userId);
});

이 상태에서 아래 요청을 보내도:

GET /users?userId=1

app.param("userId")는 실행되지 않음.

라우트 경로에 :userId가 없기 때문.

app.param("userId")가 실행되려면 라우트에 아래처럼 :userId가 있어야 함.

app.get("/users/:userId", (req, res) => {
  res.send(req.params.userId);
});

아래 두 요청은 비슷해 보여도 Express 입장에서는 완전히 다르게 처리됨.

/users/1
-> req.params.userId
-> app.param("userId") 실행 가능

/users?userId=1
-> req.query.userId
-> app.param("userId") 실행 안 됨

userId라는 이름이 같아도 하나는 path parameter이고, 하나는 query parameter.

app.param은 이름만 보는 게 아니라 라우트 경로에 선언된 :paramName을 봄.

비교

구분 app.get app.param

역할	GET 요청 처리	path parameter 전처리
실행 시점	라우트가 매칭될 때	라우트 핸들러 실행 전
응답	보통 여기서 응답을 보냄	보통 검증 후 next() 호출
다루는 값	req.params, req.query 등	특정 :paramName
예시	/users/:userId 처리	:userId 값으로 사용자 미리 조회

헷갈리기 쉬운 부분

app.param은 라우트를 만드는 게 아님

app.param("userId", callback);

이 코드만 있다고 해서 /users/1 주소가 생기는 건 아님.

실제 라우트는 따로 있어야 함.

app.get("/users/:userId", callback);

이름이 같아야 함

app.param("userId", callback);
app.get("/users/:id", callback);

위 코드는 "userId"와 :id 이름이 달라서 app.param("userId")가 실행되지 않음.

아래처럼 이름을 맞춰야 함.

app.param("userId", callback);
app.get("/users/:userId", callback);

또 app.param(":userId", callback)처럼 콜론을 붙이지 않음.

라우트에는 :userId라고 쓰지만 app.param에 넘기는 이름은 "userId".

next를 호출해야 넘어감

app.param("userId", (req, res, next, id) => {
  req.userId = id;
  next();
});

next()를 호출해야 뒤의 app.get으로 넘어감.

사용자를 찾지 못해서 여기서 응답을 끝낼 때는 return res.status(...).send(...)처럼 처리.

if (!user) {
  return res.status(404).send("User not found");
}

같은 요청에서는 한 번만 실행됨

Express 공식 문서 기준으로 param callback은 같은 request-response cycle에서 한 번만 호출.

예를 들어 같은 요청에서 같은 :id가 여러 라우트 핸들러를 거치더라도 app.param("id", ...)는 매번 반복 실행되지 않음.

중복 조회를 줄여준다는 장점이 있음.

반대로 app.param 안에 라우트별로 달라져야 하는 로직을 넣으면 흐름이 꼬일 수 있음.

router.param과 범위가 다름

라우터를 분리해서 쓰기 시작하면 app.param과 router.param의 범위도 신경 써야 함.

const router = require("express").Router();

router.param("userId", (req, res, next, id) => {
  // 이 router 안의 :userId 라우트에 적용
  next();
});

router.get("/users/:userId", (req, res) => {
  res.send("OK");
});

처음 Express를 배울 때는 app.param만 알아도 충분하지만, 나중에 라우터를 파일별로 나누면 param callback도 그 라우터에 맞게 가까운 곳에 두는 편이 읽기 쉬움.

언제 app.param을 쓰면 좋을까

아직까지는 아래와 같은 기준을 가지고 사용

여러 라우트에서 같은 :userId를 사용
각 라우트마다 같은 사용자 조회 코드가 반복
없는 사용자를 같은 방식으로 404 처리
조회된 user 객체를 뒤 라우트에서 공통으로 사용

반대로 아래라면 굳이 쓰지 않아도 됨.

한 라우트에서만 쓰는 로직
parameter 검증보다 라우트 본문 로직이 중심
query string 조건을 처리하려는 목적

이 경우에는 app.get 안에서 직접 처리하는 편이 더 단순함.

정리

app.get
-> GET 요청의 본문 처리
-> 보통 여기서 응답을 보냄

app.param
-> path parameter 기반 전처리
-> 보통 검증하거나 미리 조회한 뒤 next()로 넘김

app.get 안에서는 req.params와 req.query를 모두 읽을 수 있음.

하지만 app.param은 req.query가 아니라 라우트 경로에 선언된 :paramName에만 반응.

그래서 /users/:userId처럼 특정 사용자를 가져오는 라우트에서는 app.param으로 사용자 조회나 검증을 먼저 처리.

반대로 /users?role=admin&page=2처럼 검색 조건이나 페이지 조건을 다룰 때는 app.get 안에서 req.query로 처리하는 편이 자연스러움.

(참고)
https://expressjs.com/en/5x/api/application/
https://expressjs.com/en/5x/guide/routing/

Rust의 Copy와 Clone 차이점 정리

lgvv — Sat, 4 Jul 2026 20:04:33 +0900

Rust의 Copy와 Clone 차이점 정리

Rust의 소유권과 관련하여 Copy와 Clone의 차이점 정리

// 컴파일 O
let x = 5;
let y = x;

println!("{x}, {y}");

// 컴파일 X

let s1 = String::from("hello");
let s2 = s1;

println!("{s1}");

둘 다 값을 다른 변수에 대입했을 뿐인데, 왜 하나는 되고 하나는 안 되는지 이 차이를 설명하는 개념이 Copy와 Clone

구분	Copy	Clone
호출 방식	암묵적	명시적
사용 형태	let y = x;	let y = x.clone();
복제 비용	일반적으로 매우 작음	타입에 따라 다름
동작 방식	단순한 bit-wise copy	타입이 정의한 clone() 실행
Drop 타입	구현 불가	구현 가능
대표 타입	i32, bool, char, &T	String, Vec<T>, Rc<T>, Arc<T>

핵심은 명시성으로 Rust에서 비용이 크거나 의미가 타입마다 달라질 수 있는 복사를 자동으로 숨기지 않음.

그래서 String, Vec<T> 같은 타입은 대입할 때 자동 복사되지 않고 move됨. 따라서 완전한 복제가 필요하다면 clone()을 명시적으로 직접 호출해야 함.

i32는 왜 대입 후에도 사용할 수 있을까?

먼저 i32 예제를 보면 이해가 쉬움.

let x = 5;
let y = x;

println!("{x}, {y}");

x를 y에 대입했는데도 x를 계속 사용할 수 있음. (이유는 i32가 Copy 타입이기 때문)

Copy 타입은 대입하거나 함수에 넘길 때 소유권이 이동(move)하지 않고 값이 복사됨.

정수처럼 크기가 고정되어 있고, 별도의 Heap 리소스를 관리하지 않는 값은 복사 비용이 작음.

이런 값은 Rust가 조용히 복사해도 큰 문제가 없음.

Rust에서 기본타입은 대표적인 Copy 타입은 아래와 같음.

정수 타입
부동소수점 타입
bool
char
함수 포인터
공유 참조 &T
모든 요소가 Copy인 tuple

예를 들어 (i32, i32)는 Copy 가능.

let a = (1, 2);
let b = a;

println!("{a:?}, {b:?}");

하지만 (i32, String)은 Copy가 아님.

let a = (1, String::from("hello"));
let b = a;

println!("{a:?}");

tuple 안에 String이 들어있기 때문.

Copy는 타입의 모든 구성 요소가 Copy일 때만 가능함.

String은 왜 move될까?

아래 코드에서는 소유권이 이동되어서 s1을 더이상 사용할 수 없는 예제

let s1 = String::from("hello");
let s2 = s1; // move 

println!("{s2}"); // ok
println!("{s1}"); // error

위 동작은 String의 메모리 구조를 같이 봐야 하는데, String은 Stack에 포인터, 길이, 용량을 저장하고 실제 문자열 데이터는 Heap에 저장.

만약 s1의 소유권이 이동하지 않은 경우에는 같은 Heap을 바라보기 때문에 s1, s2 중 누군가 메모리를 정리할 경우 문제가 발생할 수 있음.

겉으로는 대입처럼 보이지만, Rust 입장에서는 소유권이 이동한 것(move)

Copy란?

공식 문서에서 Copy는 아래처럼 정의.

pub trait Copy: Clone { }

Rust의 대부분의 원시타입은 Copy trait을 구현하고 있어서 `=` 연산자를 사용하면 Copy가 자동으로 됨.

fn print_number(value: i32) {
    println!("{value}");
}

fn main() {
    let x = 10;

    print_number(x);
    println!("{x}");
}

i32는 Copy이므로 print_number(x) 이후에도 x를 계속 사용할 수 있음.

여기서 중요한 점은 Copy의 동작을 타입이 마음대로 바꿀 수 없음.

공식 문서 기준으로 Copy는 단순한 bit-wise copy임.

그래서 Copy를 구현하려면 조건이 있음.

타입의 모든 필드가 Copy여야 함
Drop을 구현한 타입은 Copy가 될 수 없음
리소스를 직접 관리하는 타입은 보통 Copy가 될 수 없음

Drop 타입이 Copy가 될 수 없는 이유는 명확함.

값이 암묵적으로 복사되면 어떤 값이 리소스를 정리해야 하는지 애매해짐.

Rust는 리소스 정리 책임이 흐려지는 상황을 막음.

Clone이란?

Clone은 값을 명시적으로 복제하기 위한 trait.

공식 문서에서 Clone은 아래처럼 정의됨.

pub trait Clone: Sized {
    fn clone(&self) -> Self;
}

Clone에는 clone() 메서드가 있음.

그래서 복제가 필요할 때 직접 호출해야 함.

let s1 = String::from("hello");
let s2 = s1.clone();

println!("{s1}, {s2}");

String의 clone()은 Heap에 있는 문자열 데이터까지 새로 복사함.

먼저 s1이 가진 메모리 구조를 단순화하면 아래처럼 볼 수 있음.

s1은 스택에 있고, 실제 문자열 hello는 힙에 존재.

clone()을 호출하면 이 구조와 같은 새 String이 s2에도 만들어져서 s1과 s2는 서로 다른 Heap 데이터를 가리킴
이 경우 각자 자기 데이터를 정리하면 되므로 double free 문제가 생기지 않음.

Rust에서는 메모리 문제가 발생할 수 있는 영역에 대해서 개발자가 clone()을 직접 호출하게 만들어서 복제가 일어난다는 것을 명확하게 표현.

Copy와 Clone의 헷갈리는 부분 정리

Rust의 Copy와 Clone에서 헷갈리는 부분 정리

1) Copy는 Stack 타입만 가능할까? -> (X)

대체로 단순한 Stack 값이 Copy인 경우가 많음.

하지만 "Stack이면 Copy, Heap이면 non-Copy"는 아님

예를 들어 공유 참조 &T는 Copy임.

let s = String::from("hello");

let r1 = &s;
let r2 = r1;

println!("{r1}");
println!("{r2}");

참조 자체는 포인터처럼 복사될 수 있으며 이 경우에는 소유권이 이동하는 것은 아님.

반대로 String은 Heap 데이터를 소유하고 정리할 책임이 있으므로 Copy가 아님.

2) Clone은 항상 깊은 복사일까? -> (X)

String의 clone()은 Heap 문자열 데이터를 새로 복사하므로 깊은 복사처럼 보임.

하지만 Clone 자체가 항상 깊은 복사를 의미하지는 않음.

예를 들어 Rc<T>의 clone()은 내부 데이터를 새로 복사하지 않으며, 참조 카운트를 증가시키고 같은 값을 공유.

use std::rc::Rc;

let a = Rc::new(String::from("hello"));
let b = Rc::clone(&a);

println!("{a}");
println!("{b}");

이 코드에서 a와 b는 같은 내부 데이터를 공유하기 때문에 `Clone = 깊은 복사`가 아닐수 있음.

즉, `Clone = 명시적 복제`가 더 가까움

3) Copy면 Clone도 되는 걸까? -> (O)

Copy의 trait 정의 자체가 Copy: Clone이기 때문에, Copy 타입은 Clone도 구현해야 함.

let x = 10;
let y = x.clone();

println!("{x}, {y}");

i32는 Copy이면서 Clone도 가능한데, Copy 타입에서는 보통 clone()을 직접 호출할 필요가 없음. (그냥 대입하면 끝)

구조체에서 Copy와 Clone 사용하기

구조체도 모든 필드가 Copy라면 Copy를 구현할 수 있음. (보통은 derive를 사용)

#[derive(Copy, Clone, Debug)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let p1 = Point { x: 10, y: 20 };
    let p2 = p1;

    println!("{p1:?}");
    println!("{p2:?}");
}

Point의 필드는 모두 i32. (i32는 Copy.)

모든 Point의 모든 필드가 Copy가 될 수 있음.

반대로 구조체 안에 String이 있으면 Copy를 구현할 수 없음.

#[derive(Copy, Clone, Debug)]
struct User {
    name: String,
}

이 코드는 컴파일되지 않는데, String이 Copy가 아니기 때문에 이 경우에는 Clone만 사용할 수 있음.

#[derive(Clone, Debug)]
struct User {
    name: String,
}

fn main() {
    let user1 = User {
        name: String::from("lgvv"),
    };

    let user2 = user1.clone();

    println!("{user1:?}");
    println!("{user2:?}");
}

이렇게 하면 user1과 user2를 둘 다 사용할 수 있음.

다만 String 필드도 함께 clone되므로 비용이 발생할 수 있음.

Copy를 붙일지 판단하는 기준

어떤 타입이 Copy가 될 수 있다고 해서 항상 붙이는 게 좋은 것은 아님.

공식 문서에서도 Copy 구현은 public API의 일부라고 나와 있는데, 한번 Copy를 제공하면 그 타입을 대입해도 원래 값이 계속 유효하다고 개발자기 기대함.

한 번 Copy를 제공하면 사용자는 그 타입을 대입해도 원래 값이 계속 유효하다고 기대하게 됨.

나중에 구조체에 String, Vec<T>, 파일 핸들 같은 non-Copy 필드가 추가되면 Copy를 유지할 수 없음.

그때 Copy를 제거하면 기존 코드가 깨질 수 있음.

따라서 Copy는 현재 컴파일을 위해 붙이기 보다는 해당 타입이 앞으로 값 타입처럼 쓰일지 생각하고 붙이는 편이 좋음.

Copy를 쓰는게 자연스러운 경우

좌표, 크기, 색상, 플래그처럼 작은 값
숫자 기반 ID처럼 복사 의미가 단순한 값
리소스 정리 책임이 없는 값
대입 후에도 기존 값을 계속 쓰는 것이 자연스러운 값

#[derive(Copy, Clone, Debug)]
struct UserId(u64);

Clone만 두는 편이 자연스러운 경우.

String, Vec<T>처럼 Heap 데이터를 소유하는 값
파일, 소켓, 락처럼 외부 리소스와 연결된 값
복제 비용이 클 수 있는 값
복제 의미를 코드에서 명시적으로 보여주는 편이 좋은 값

#[derive(Clone, Debug)]
struct Profile {
    name: String,
    tags: Vec<String>,
}

Profile은 name과 tags가 Heap 데이터를 소유함.

따라서 대입할 때 자동으로 복사되면 비용도 숨겨지고 의미도 애매해짐.

이런 경우에는 clone()을 명시적으로 호출하는 편이 Rust답다.

정리

Copy	Clone
Copy의 경우에는 암묵적으로 일어남 (`=` 연산자)	`clone`을 통해 명시적으로 발생
Copy의 경우에는 스택에 있는 데이터 복사, 힙 데이터를 복사하는 경우는 발생하지 않음.	clone()을 통해 힙 영역까지 명시적 복사
따라서 String에 대해서 스택 정보만 복사되어 소유권 이동만 발생함. 즉, 스택 영역만 새롭게 생성되고, Heap 데이터가 연결됨. (move)	스택과 힙에 대한 정보가 모두 복사

참고

Rust 소유권 (Ownership) 이해하기

lgvv — Sat, 4 Jul 2026 13:49:03 +0900

Rust 소유권 (Ownership) 이해하기

Rust에서 소유권은 단순한 문법이 아니라 메모리를 관리하는 기본 규칙.

Rust는 GC가 메모리를 정리하는 방식도 아니고, 개발자가 직접 free를 호출하는 방식도 아님. 대신 컴파일 시점에 값의 owner, scope, 참조 관계를 검사해서 메모리 안전성을 보장.

Rust가 소유권을 사용하는 이유

프로그램은 실행 중에 메모리를 사용함.

문제는 사용이 끝난 메모리를 언제 정리할지임. 언어마다 이 문제를 푸는 방식이 다름.

GC가 있는 언어는 런타임이 더 이상 쓰지 않는 메모리를 찾아서 정리
C/C++ 같은 언어는 개발자가 직접 메모리 할당과 해제를 관리
Rust는 컴파일러가 소유권 규칙을 검사해서 메모리 안전성을 보장

Rust의 특징은 런타임이 아니라 컴파일 타임에 최대한 많이 확인해 소유권 규칙을 어기면 프로그램이 실행 중에 터지는 게 아니라 컴파일 자체가 되지 않음.

즉, 소유권은 Rust가 GC 없이 메모리 안전성을 얻기 위한 규칙.

Stack과 Heap

소유권을 이해하려면 Stack과 Heap의 차이를 먼저 알아야 함.

Stack은 크기를 컴파일 타임에 알 수 있는 값을 빠르게 넣고 빼는 공간. 함수 호출, 지역 변수, 정수처럼 크기가 고정된 값이 주로 Stack에 올라감.

Heap은 실행 중에 크기가 달라질 수 있는 데이터를 저장하는 공간. 예를 들어 String은 문자열 길이가 실행 중에 바뀔 수 있으므로 실제 문자열 데이터는 Heap에 저장됨.

대신 Stack에는 Heap 데이터를 가리키는 포인터, 길이, 용량 같은 메타데이터가 들어감.

소유권 규칙

Rust Book에서는 소유권 규칙을 세 가지로 정리함.

Rust의 각 값은 owner라고 부르는 변수를 가진다.
한 번에 owner는 하나만 존재할 수 있다.
owner가 scope 밖으로 벗어나면 값은 버려진다.

예를 들어 아래 코드에서 s는 String 값의 owner.

{
    let s = String::from("hello");
}

s가 scope를 벗어나는 순간 Rust는 drop을 호출해서 String이 사용하던 Heap 메모리를 정리함.

핵심은 메모리를 정리하는 시점이 명확하다는 점. owner가 사라지면 값도 함께 정리됨.

Move

Rust에서는 값을 다른 변수에 대입할 때 소유권이 이동할 수 있음.

let s1 = String::from("hello");
let s2 = s1;

println!("{s2}");

이 경우 s1이 가지고 있던 String의 소유권이 s2로 이동함. 이후에는 s1을 사용할 수 없음.

String의 Stack 데이터에는 Heap을 가리키는 정보가 들어있음. 이 값이 단순히 복사되어 두 변수가 같은 Heap 데이터를 정리하려고 하면 double free 문제가 생길 수 있음.

Rust는 이런 상황을 막기 위해 s1을 더 이상 유효하지 않은 값으로 봄.

그래서 아래 코드는 컴파일되지 않음.

let s1 = String::from("hello");
let s2 = s1;

println!("{s1}");

s1의 값은 이미 s2로 move 되었기 때문.

Clone

Heap 데이터까지 실제로 복사하고 싶다면 clone을 사용.

let s1 = String::from("hello");
let s2 = s1.clone();

println!("{s1}, {s2}");

clone은 명시적인 깊은 복사임. 그래서 비용이 발생할 수 있음.

Rust는 비용이 있는 복사를 조용히 처리하지 않음. 복사가 필요하다면 개발자가 직접 clone을 호출해서 의도를 드러내야 함.

Copy

정수처럼 Stack에만 저장되는 단순한 값은 대입 후에도 기존 변수를 계속 사용할 수 있음.

let x = 5;
let y = x;

println!("{x}, {y}");

이 경우 x와 y 모두 사용 가능.

이런 타입은 Copy trait을 구현함. Copy가 가능한 값은 move가 아니라 복사가 일어남.

대표적으로 아래 타입들이 Copy 가능.

정수 타입
부동소수점 타입
bool
char
Copy 가능한 타입만 담은 tuple

반대로 String처럼 Heap 리소스를 관리하는 타입은 기본적으로 Copy가 아님.

함수와 소유권

함수에 값을 넘길 때도 대입과 비슷하게 move 또는 copy가 일어남.

fn main() {
    let s = String::from("hello");
    takes_ownership(s);
}

fn takes_ownership(value: String) {
    println!("{value}");
}

s의 소유권은 takes_ownership 함수의 매개변수 value로 이동함. 함수가 끝나면 value가 scope를 벗어나고 String도 정리됨.

반면 i32 같은 Copy 타입은 함수에 넘겨도 기존 변수를 계속 사용할 수 있음.

fn main() {
    let x = 5;
    makes_copy(x);

    println!("{x}");
}

fn makes_copy(value: i32) {
    println!("{value}");
}

함수에서 값을 반환하면 소유권이 다시 호출한 쪽으로 이동함.

fn main() {
    let s1 = gives_ownership();
    let s2 = String::from("hello");
    let s3 = takes_and_gives_back(s2);
}

fn gives_ownership() -> String {
    String::from("hello")
}

fn takes_and_gives_back(value: String) -> String {
    value
}

이 방식만 쓰면 매번 소유권을 넘기고 다시 돌려받아야 해서 코드가 번거로워짐.

그래서 Rust에는 참조와 빌림이 있음.

참조와 빌림

참조는 값을 소유하지 않고 접근하는 방법.

fn main() {
    let s = String::from("hello");
    let len = calculate_length(&s);

    println!("{s}의 길이는 {len}");
}

fn calculate_length(value: &String) -> usize {
    value.len()
}

&s는 s의 소유권을 넘기지 않음. s를 잠깐 참조할 뿐.

이처럼 소유권을 가져오지 않고 참조로 사용하는 것을 borrowing이라고 함. 한국어로는 보통 빌림이라고 표현.

다만 빌린 값은 기본적으로 수정할 수 없음.

fn change(value: &String) {
    value.push_str(", world");
}

위 코드는 컴파일되지 않음. immutable reference로는 값을 수정할 수 없기 때문.

Mutable Reference

빌린 값을 수정하려면 mutable reference를 사용해야 함.

fn main() {
    let mut s = String::from("hello");

    change(&mut s);

    println!("{s}");
}

fn change(value: &mut String) {
    value.push_str(", world");
}

mutable reference에는 제한이 있음.

같은 값에 대한 mutable reference는 동시에 하나만 만들 수 있음.

let mut s = String::from("hello");

let r1 = &mut s;
let r2 = &mut s;

println!("{r1}, {r2}");

이 코드는 컴파일되지 않음.

Rust는 한 시점에 하나의 mutable reference만 허용해서 같은 데이터를 동시에 수정하는 상황을 막음.

immutable reference와 mutable reference를 동시에 사용할 수도 없음.

let mut s = String::from("hello");

let r1 = &s;
let r2 = &s;
let r3 = &mut s;

println!("{r1}, {r2}, {r3}");

읽는 참조가 사용되는 동안에는 쓰는 참조를 만들 수 없기 때문.

다만 참조의 scope는 마지막으로 사용되는 지점까지로 판단됨.

let mut s = String::from("hello");

let r1 = &s;
let r2 = &s;

println!("{r1}, {r2}");

let r3 = &mut s;
println!("{r3}");

r1, r2는 println! 이후 더 이상 사용되지 않음. 그래서 그 뒤에는 mutable reference를 만들 수 있음.

Dangling Reference

Dangling reference는 이미 사라진 값을 가리키는 참조.

C/C++에서는 잘못된 포인터 사용으로 이런 문제가 생길 수 있음. Rust는 컴파일 단계에서 dangling reference를 막음.

fn dangle() -> &String {
    let s = String::from("hello");

    &s
}

이 코드는 컴파일되지 않음.
s는 함수가 끝나면 사라짐. 그런데 &s를 반환하면 호출한 쪽은 이미 사라진 값을 참조하게 됨.

Rust는 이런 코드를 허용하지 않음.

해결하려면 참조가 아니라 값을 직접 반환.

fn no_dangle() -> String {
    let s = String::from("hello");

    s
}

값을 반환하면 소유권이 호출한 쪽으로 이동하므로 문제가 없음.

참조 규칙

참조 규칙은 이렇게 정리할 수 있음.

한 시점에 여러 immutable reference를 만들 수 있음.
한 시점에 하나의 mutable reference를 만들 수 있음.
immutable reference와 mutable reference는 동시에 사용할 수 없음.
참조는 항상 유효해야 함.

이 규칙을 검사하는 것이 Rust의 borrow checker.

Slice 타입

Slice는 컬렉션 전체가 아니라 연속된 일부를 참조하는 타입.

대표적인 예가 string slice인 &str.

let s = String::from("hello world");

let hello = &s[0..5];
let world = &s[6..11];

hello와 world는 문자열 데이터를 소유하지 않음. 기존 String의 일부를 참조할 뿐.

Rust Book에서는 first_word 예제로 slice가 왜 필요한지 설명함.

처음에는 첫 번째 단어의 끝 위치를 usize로 반환할 수 있음.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

하지만 이 방식은 문제가 있음.

반환된 숫자는 원래 문자열과 분리되어 있음. 문자열이 바뀌면 이전에 구한 index는 더 이상 의미가 없을 수 있음.

slice를 반환하면 문자열의 일부를 참조하는 값이 됨. 원본 문자열과 관계가 유지되는 셈.

fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

여기서 매개변수를 &String이 아니라 &str로 받으면 String과 string literal을 모두 받을 수 있음.

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

&str은 문자열 데이터를 소유하지 않는 참조. 문자열 전체나 일부를 가리킬 때 자연스럽게 사용됨.

String Literal과 Slice

문자열 리터럴의 타입은 &str.

let s = "hello";

s는 프로그램 바이너리에 저장된 문자열 데이터를 참조함.

그래서 문자열 리터럴은 기본적으로 immutable.

다른 Slice

Slice는 문자열에만 있는 개념이 아님. 배열에서도 slice를 만들 수 있음.

let a = [1, 2, 3, 4, 5];
let slice = &a[1..3];

이때 slice의 타입은 &[i32].

즉 slice는 어떤 컬렉션의 일부를 소유하지 않고 참조하는 방식.

정리

Rust의 소유권은 값을 누가 책임지는지 정하는 규칙.

소유권 덕분에 Rust는 값이 언제 정리되어야 하는지 알 수 있음. move는 하나의 Heap 데이터를 여러 owner가 동시에 정리하는 문제를 막고, borrowing은 소유권을 넘기지 않고도 값을 읽거나 수정할 수 있게 해줌.

용어 정리

ownership: 값을 정리할 책임을 가진 상태
owner: 값을 소유한 변수
move: 소유권이 다른 변수나 함수로 이동하는 것
borrow: 소유권을 가져오지 않고 참조로 빌려 쓰는 것
immutable reference: 읽기 전용 참조
mutable reference: 수정 가능한 참조
dangling reference: 이미 사라진 값을 가리키는 참조
slice: 컬렉션의 일부를 소유하지 않고 참조하는 값

참고

What's new in SwiftUI (WWDC26)

lgvv — Thu, 2 Jul 2026 00:14:23 +0900

What's new in SwiftUI (WWDC26)

Refreshed look and feel

새롭게 앱을 빌드하고 실행하면 Liquid Glass 디자인이 업데이트 된 모습으로 자동 적용

appearsActive를 사용해서 조건부로 버튼의 불투명도를 조절할 수 있음.

Xcode 27부터는 Preview에 리사이징이 가능하도록 변경

SwiftUI로 만든 앱은 이런 기능을 자동으로 지원하지만 UIKit과 SwiftUI를 모두 사용하고 있다면 고려해야할 사항 존재.

Screen Geometry 확인, 디바이스 대신에 size class 사용, 화면 회전 대응 등이 추가되는데 WWDC26의 Modernize your UIKit app 확인

우측 하단에 새로운 탭 형태가 생겼고, 띄워서 배치하려면 role을 prominent로 지정.

앱의 윈도우 크기를 조정하면 Toolbar 아이템이 시스템에 의해서 자동으로 조정되며, 공간이 부족할 때 어떤 버튼을 계속 표시할 지 여부도 지정할 수 있음.

visibilityPriority를 높이므로써 공간이 좁아져도 가시성 있게 유지할 수 있음.

반대로 숨기고 싶다면 ToolbarOverflowMenu를 사용하면 됨.

절대로 숨기고 싶지 않은 버튼의 경우에는 placement에 topBarPinned를 지정하면 됨.

toolbarMinimizeBehavior를 사용하면 스크롤 시 네비게이션 바를 시스템이 자동으로 숨길 수 있음.

SwiftUI는 Document 기반 앱을 지원했으나 이번 iOS27부터 더 확장된 API를 제공. DocumentGroupLaunchScene에 source를 통해 버튼을 지정하고 DocumemtGroup의 context를 클로저를 통해 받아서 해당 source에 따라서 초기표현할 UI를 결정할 수 있음.

문서 기반앱은 특히 Performance 중 데이터를 읽고 쓰는 작업이 많음.

Document 앱은 우선 View 영역에서 @Observable 매크로를 이용해 의존하는 프로퍼티가 변경될 때만 View를 업데이트 해서 이것 만으로도 View 성능을 향상.

그러나 문서 기반 앱은 읽기와 쓰기 성능을 개선하는게 가장 중요함.

성능 향상을 위해 WritableDocument를 채택

writableContentTypes 변수를 정의해야 하는데 커스텀 한 타입으로 지정 가능.
쓰기용으로 현재 문서 콘텐츠를 반환하는 snapshot 메서드로 콘텐츠를 나타내기 위해 PageSnapshot 구조체를 사용.
writer를 작성하는데, 지정된 형식으로 디스크에 쓰는 방법에 대한 정의

DocumentWriter 프로토콜에는 Snapshot이라는 개념이 존재하는데, 유일한 요구사항은 write 메서드를 작성하여 성능을 최적화 할 수 있는 여러 기회를 제공함.

nonisolated asnyc로 비동기 메서드로 백그라운드에서 실행
실제로 업데이트 필요한 부분만 작성하는데 previous와 snapshot을 비교하여 결정

그러나 이런 모든 최적화에도 불구하고 시간이 오래 걸릴수도 있어서 process 를 통해 SwiftUI가 현재 쓰기 작업에 대해 진행경과를 확인할 수 있음.

ReadableDocuments를 통해서 DocumentWriter의 쌍둥이 프로토콜로 읽기를 지원

각 프로토콜은 지원퇴는 콘텐츠 유형에 대한 타입이 필요하며, Writer는 Snapshot을 제공하고 Readble은 apply를 통해 대칭됨. 또한, Writer 프로토콜은 write 메서드를 통해 Readable 프로토콜은 read를 통해 대칭됨.

또한 앱이 없는 사람들과도 공유할 수 있도록 페이지를 이미지로 저장하는 기능도 제공 CoreGraphics를 활용해 PNG로 변환하는 것처럼 페이지를 다른 타입으로 저장할 수 있음.

추가적인 형식을 지원하기 위해 ContentType을 추가하고, 앱이 지원하는 형식에 대해서 확인하고 PNG 형식으로 만들기 위해서 CoreGraphics를 활용해 스티커랑 배경 사진을 하나의 이미지로 만들고 최종적으로 결과물을 만들어 냄.

프레젠테이션과 인터랙션에 대해서도 개선사항들이 존재.

reorderable modifier를 추가하고 reorderContainer에 apply를 적용하여 손쉽게 순서 변경을 지원할 수 있음.

apply 메서드는 내부적으로 오픈소스은 swift-collection 패키지를 사용

Reorderable API는 List 뿐만 아니라 LazyVGrid 등 모든 컨테이너에서 동작함.

SwiftUI는 이제 List 뿐만 아니라 모든 View에서 Swipe 동작을 지원하며, swipeActionContiner를 modifier로 추가하면 됨.

만약 특정 항목만 제거하고 싶은 경우에는 contextMenu를 통해 삭제 아이템에 배치한 후 confirmationDialog를 통해서 삭제 동작을 정의할 수 있고, 이는 .alert 대체 가능

휼룡한 성능은 앱이 반응적이고 세련되게 느껴지도록 하는 데 중요. 따라서 데이터가 흐르는 방식에 신중하게 접근하는 것이 가장 좋은 방법.

AsyncImage가 표준 HTTP 캐싱을 지원(서버의 캐시 헤더)하며 기본적으로 이미지가 캐싱됨.

이미지 다운로드 방식을 더 세밀하게 제어하려면 URLRequest를 직접 만들어서 더 세밀하게 제어할 수 있음. 이를 통해서 요청별로 다양한 커스터마이즈가 가능함.

아예 URLSeesion을 직접 만들어서 필요한 용량으로 URLCache를 설정할 수도 있음. 이 경우 .asyncImageURLSession modifer를 통해서 전달

SwiftUI는 앱이 데이터를 모델링하고 저장하는 다양한 방법을 제공하는데 앱 데이터를 저장하는 가장 좋은 방법은 Observable 클래스를 사용하는 것

iOS 26까지는 View가 초기화 되면 store가 새로운 인스턴스를 생성. 기존 인스턴스가 여전히 @State를 통해 저장되고 있음에도 불구하고 버려지기 때문에 성능이 좋지 않음.

하지만, iOS 27 부터는 State 프로퍼티를 사용하여 초기화되고, 저장되는 클래스가 lazy하게 동작함. (이제 한번만 초기화 됨)

이는 @State가 Dynamic Property에서 Macro로 전환되었기 때문

이제부터 초기화 이후에는 새 클래스 인스턴스가 생성되지 않으며, 해당 동작은 하위 호환되어 iOS 17부터 지원하는 것으로 백포팅되었음.

하지만 이로 인해서 init에서 동일한 @State 변수에 값을 할당할 경우 Xcode가 초기화 전 사용할 수 없다는 오류를 발생.

이 오류를 해결하기 위해서는 불필요한 기본 값 할당을 제거할 것.

좋은 런타임 성능을 유지하는 것은 앱이 원활하게 작동하는데 중요하고, 또 다른 종류로는 앱 개발 경험에 영향을 줄 수 있는 성능임.

View가 깊게 중첩되어 있다면 컴파일러가 오류를 발생 시키는 오류를 만날 수 있음.

원인은 컴파일러가 해당 컴포넌트를 그릴 때 어떤 조건을 그릴지 모르니 모두 다 시 도해야하는 문제에서 기인함. 따라서, 중첩이 깊어질수록 더 복잡해지고 오래 걸릴 수 밖에 없음.

복잡한 빌더들이 생성 타입에 제약받지 않고, 콘텐츠를 조합하는 형태로 이번 릴리즈에서 개선함.

가장 일반적인 Builder 집합이 이제 단일 initializer를 공유하여 단 하나의 명확한 경로만 남김.

@ContentBuilder를 통해 단일 빌더를 위해 여러 다른 빌더의 유형을 하나로 통합. SwiftUI API 전반에 걸쳐 통합된 Builder를 지향하는 첫 걸음으로 기존 ViewBuilder를 내부적인 개선으로 모든 SwiftUI 버전에서 사용할 수 있음!

@ContentBuilder는 SwiftUI로 된 앱을 빌드할 때 빌드 성능을 크게 향상시킴.

(참고)

https://www.youtube.com/watch?v=s8BB8q2MyXc

UIKit 앱 현대화하기 (Modernize your UIKit app) - WWDC26

lgvv — Wed, 1 Jul 2026 22:29:22 +0900

UIKit 앱 현대화하기 (Modernize your UIKit app) - WWDC26

Adaptivity
- 아이폰 앱에서 새롭게 적용되는 적응형 레이아웃 방식
Bar and menus
- 탭 바, 네비게이션 바, 메뉴 등 새로운 API 소개
Apple Intelligence
- 새로운 기능과 몇가지 변경사항 소개
Agentic coding
- 에이전트가 도와주는 새로운 스킬 소개

Adaptivity

미러링을 통해서 아이폰도 런타임에 사용 가능한 씬 크기에 맞게 조정할 수 있음.

즉, 이제는 아이폰 하나의 사이즈만 지원하는 것이 아니라 여러 사이즈를 지원해야 함.

런타임에 더 잘 동작하기 위해서는 환경에 맞게 대응이 필요

App lifecycle
- 적응형 앱의 기반을 위해서는 App LifeCycle에서 Scene 라이프사이클이 필요
Main Screen
- UIScreen.main 교체
User interface idiom
- pad 혹은 phone 형태의 레이아웃 선택 x
interface orientation
- 인터페이스 방향 확인을 처리하는 방법도 다룸

UIScene 라이프사이클은 최신 SDK로 빌드시 필수로 해당 작업 없이는 이제 더이상 앱이 실행되지 않음.

iPhone이 Mac에서 미러링되거나 혹은 iPad의 앱을 다른 외부 디스플레이로 이동하는 등

즉, 리사이징이 가능한 환경에서는 UIScreen.main에 대한 사용은 앱이 실행되는 환경에 대해 잘못된 정보를 제공.

UIScreen.main을 참조하는 대신 window의 scene으로 접근

Screen을 전역으로 참조하는 유틸리티 함수가 존재한다면 UIScreen을 파라미터로 받는 형태로 변경

다만, 가장 좋은 방법은 UIScreen에 대한 참조를 완전히 제거하고 적응형(반응형) 앱에 더 적합한 다른 API를 사용할 것.

화면 배율에 접근하는 코드를 예로 들자면 trait collection의 displayScale으로 대체

View와 ViewController는 자동으로 trait collection을 업데이트하고 Visible한 계층이 아닌 경우에도 자동으로 fallback을 제공.

즉, override되는 모든 지점들도 추적하고 있어서 변경사항을 명시적으로 업데이트할 필요가 없음.

layoutSubviews, updateProperties와 같은 레이아웃 및 draw 메서드 등 자동으로 추적됨.

자동으로 관찰할 수 없는 곳에서는 수동으로 관찰하는 것 또한 가능함.

해당 메서드를 통해 특정 trait이 변경될 때 실행한 내용을 클로저에 정의할 수 있음,

Scene이 항상 전체 화면이 아니기 때문에 view의 bounds나 scene의 geometry를 통해서 코드를 변경해야 함.

`UIWindowScene.effectiveGeometry`는 앱이 사용할 수 있는 공간에 대한 정보를 제공하며 geometry에 대한 변경 감지는 UIWindowSCeneDelegate의 didUpdateEffectiveGeometry을 구현함으로써 확인할 수 있음

SplitView를 사용할 때 내부에서 화면이 나타나는 경우가 있어서 view.bounds로 변경하면 레이아웃을 더 동적으로 안전하게 사용할 수 있음

user interface idiom은 더이상 레이아웃을 결정하는데 의미가 없음.

미러링이 가능한 환경에서는 리사이징이 가능하기 때문에 `size class`를 활용하고 idiom에 관계 없이 공간을 활용해야 함.

interface orientation도 더이상 레이아웃을 결정하는데 의미가 없음.

Mac에서 iPhone Mirroring에서 앱은 가로 및 세로 비울과 무관하게 항상 세로 인터페이스 방향(portrait)으로만 실행.

앱의 방향 확인도 size class를 사용하도록 업데이트 해야함.

CoreMotion/CoreLocation 등 데이터에는 view를 연결하여 뷰의 좌표 기준으로 계산된 데이터를 얻을 수 있음.

아이패드에서 탭바는 현재 환경이 사이드바를 지원할 때 전환될 수 있음.

아이폰에서는 기본적으로 탭바를 모두 지원하지만 iOS27의 새 기능으로 iPhone 앱도 사이드 바를 선택할 수 있음.

사이드바를 현재 사용할 수 있는지 확인하며 사용할 수 없다면 UI를 앱의 다른 부분에 표시해야 함.

탭바에서 prominent 탭을 지정되면 강조되고 스크롤 중 탭 바가 축소되어도 항상 표시됨.

네비게이션에서 최소화에 대한 부분도 달라지는데 필요한 경우 설정할 것.

Scroll Edge effect에서 .automatic은 더이상 soft와 hard 스타일 간에 전환하지 않음.

메뉴에 설정한 이미지는 기본적으로 표시되지 않을수도 있음.

이미지를 계속 표시해야 하는 경우 preferredImageVisibility 속성을 설정

앱 내에서 바로 Siri를 사용할 수 있는데 앱에 더 특화된 정보를 제공하려며 AppEntity를 주석으로 추가할 수 있음.

또한, 앱에 Drag and Drop을 지원한다면 Siri가 리소스를 로드할 수 있음.

컨텍스트 메뉴에서 Apple Intelligence가 호출되면 시스템이 사용 가능한 Drag and Drop Delegate 메서드를 호출하여 콘텐츠를 로드함. (UIDragInteractionDelegate)

드래그 세션은 사용자 제스처 없이 시작될 수 있으므로 세션이 시작되기 전 애니메이션이나 모달 UI를 표시하지 말 것.

사용자가 드래그를 시작할 때 표시되는 상태 있는 UI가 앱에 있다면 sessionDidMove에 넣기.

마지막으로 Agentic Coding을 지원하며 Xcode가 아닌 다른 도구에서 사용하려면 위의 명령어를 입력하면 마크다운 파일이 생성되어 워크플로에서 가져올 수 있음.

(참고)

https://www.youtube.com/watch?v=rAvlt9Dvgbo

SwiftUI의 Observation 알아보기 (Discover Observation in SwiftUI) - WWDC23

lgvv — Sat, 16 May 2026 01:17:35 +0900

SwiftUI의 Observation 알아보기

SwiftUI에서 마법적인 기능에 대해서 소개할 것.

Observation은 SwiftUI의 뷰가 반응형으로 동작할 수 있도록 도와줌.

SwiftUI 핵심 기능 (SwiftUI essential) - WWDC24

lgvv — Sat, 16 May 2026 00:31:23 +0900

SwiftUI 핵심 기능 (SwiftUI essential) - WWDC24

다양한 기능이 있으며 Apple 플랫폼에서 자연스럽게 통합되고 더 적은 코드로도 프로덕션을 더 빠르게 만들 수 있음.

또한, 기존 코드 베이스에 한번에 적용하는게 아닌 점진적으로 적용할 수 있도록 호환성도 갖춤.

머신 러닝 기반 비디오 효과로 앱 향상하기 (Enhance your app with machine-learning based video effects) - WWDC25

lgvv — Thu, 7 May 2026 00:37:06 +0900

머신 러닝 기반 비디오 효과로 앱 향상하기

Video Toolbox는 비디오 앱에서 많이 사용되는 프레임워크로 여러 비디오 관련 요구사항을 충족하는 기능을 제공

macOS 15.4부터 Video Toolbox는 VTFrameProcessor API로 개선

해당 API는 Apple Silicon에 최적화된 새로운 ML 기반 비디오 처리 알고리즘을 포함

해당 API를 이제 iOS 26에서도 사용할 수 있음.

다양한 효과를 생성할 때도 사용할 수 있음. 이 예시에서 오른쪽 비디오에 모션 블러 효과가 적용되었고, 이에 따라서 더 빠르게 이동하는 효과처럼 느껴지게 함. 도한 갑작스러운 움직임을 연속적으로 느끼게 해서 더 부드럽게 느끼도록 함.

Temoporal noise filter도 매우 좋은 기능으로 이는 과거와 미래의 참조 프레임을 활용한 모션 추정을 기반으로 함.

이 효과는 시간에 따라 화면이 바뀔 때 생기는 지저분한 노이즈를 줄이고, 이상한 깨짐이나 잔상 같은 artifact를 없애며, 영상 압축이 더 잘 되게 만들고, 결과적으로 화질도 좋아 보이게 함.

temporal noise: 한 프레임만 보면 잘 안 보이는데, 영상으로 보면 화면이 자글자글 깜빡이는 노이즈예요. 예를 들어 어두운 장면에서 배경이 계속 미세하게 반짝이는 것.
부드럽게 처리: 프레임과 프레임 사이의 변화가 너무 튀지 않게 평균화하거나 안정화
artifact 영상 처리나 압축 때문에 생긴 부자연스러운 흔적. (블록 깨짐, 링잉, 번짐, 계단 현상, 잔상 같은 것들.)
압축이 용이: 노이즈가 많으면 매 프레임이 조금씩 달라 보여서 압축기가 “노이즈도 정보”라고 판단해 데이터를 많이 사용. 노이즈를 줄이면 프레임 간 차이가 줄어들어서 더 적은 용량으로 압축하기 쉬워짐.
품질 개선: 자글거림과 깨짐이 줄어드니 사람이 보기에는 더 깔끔하고 안정적인 영상처럼 느껴짐.

4분 11초

Low latency frame interpolation은 실시간으로 프레임 속도를 업샘플링 하며, 옵션으로 해상도도 업샘플링할 수 있음.

차이는 영상이 움직일 때 왼쪽은 끊김이 심한데, 오른쪽은 부드럽게 진행됨.

Frame Interpolation (프레임 보간)은 원본 프레임들 사이에 새로운 프레임을 인공적으로 만들어 끼워 넣는 기술

프레임 보간

Low Latency Super Resolution은 가벼우면서도 강력한 성능을 갖춘 실시간 업스케일링 기술

이 스케일러는 네트워크 상태가 좋지 않은 환경에서도 화상 회의 품질을 개선하도록 최적화되어 있음.

낮은 해상도의 비디오 프레임을 더 높은 해상도로 복원하고, 압축 과정에서 생기는 코딩 아티팩트를 줄이며, 흐릿해진 가장자리를 선명하게 보정함.

해당 효과가 적용되면 영상의 해상도가 높아지고 압축 artifact 줄어듦.

또한 가장자리가 또렷해지면서 얼굴 윤곽, 표정, 글자, 물체의 경계처럼 중요한 특징의 디테일이 더 잘 드러나게 됨.

앱에 해당 효과를 통합하는 방법을 코드로 함께 보자

앱이 이러한 효과를 통합하고 프레임워크 간에 데이터가 교환되는 방법을 설명하고 클립을 처리하는 주요 단계도 설명

VTFrameProcessor API에 접근하려면 앱이 Video Toolbox 프레임워크를 우선 가져와야 함.

이 단계에서는 앱은 전체 세션 동안 효과를 사용하는 방법을 설명하는 Configuration을 제공하여 처리하는 세션을 시작
세션이 생성되면 앱은 프레임을 처리할 준비가 된 VTFrameProcessor 객체를 얻음
VTFrameProcessor은 프레임 기반 API로 앱은 입력 비디오 프레임과 관련 매개변수를 하나씩 전송해야 함.
처리 완료 후 프레임워크는 출력 프레임을 반환

예제, 비디오 편집에 적합한 기능, 실시간 영상에 적합한 기능

비디오 편집과 실시간 비디오 향상 등 두가지 사례에 초점을 맞춰 예제를 알아볼 것.

비디오 편집에 적한한 기능은 특히 비디오이 중요할 때 유용함

Frame rate conversion은 비디오 클립의 프레임 수를 늘리는 과정으로 새로운 프레임을 합성하여 기존 프레임 사이에 삽입하는 방식으로 진행.
- 주로 비디오 재생의 부드러움을 개선하기 위해 사용되며 특히 source 및 대상 디스플레이 간의 프레임 속도 불일치로 인한 judder(저더) 현상을 완화하는데 사용됨.
- 누락된 프레임으로 인해 발생한 간격을 채우는 데도 도움이 됨
슬로우 모션 효과를 만들 때 사용될 수 있음
- 영화에서는 느린 재생을 통해 시각적으로 더 인상적인 액션 장면을 만들기 위해 이 효과를 자주 활용
- 스포츠에서는 중요한 영역은 강조하고 분석하기 위해 슬로우 모션을 사용

VTFrameProcessor API 사용하여 프레임 전환율을 구현하는 방법을 시연

Processor 객체 생성
Configuration 객체 생성

다음으로는

VTFrameProcessorParameters

타입의 객체를 사용해서 프레임을 처리하는 것

이를 사용하기 전에 매개변수 객체에 필요한 모든 버퍼를 먼저 할당해야 함.

일반적으로 모든 입력 및 풀력 프레임 버퍼는 호출자가 할당함.

Configuration 소스 및 픽셀 버퍼 속성을 사용하여 CVPixelBuffer 풀을 설정할 수 있음.

먼저 현재 소스 및 다음 프레임 객체를 생성
interpolationPhase 배열을 통해 보간된 프레임을 삽입할 위치를 지정
- 배열의 크기는 보간할 프레임 수를 나타냄
마지막으로 출력을 받을 버퍼로 구성된 destinationFrames 배열을 생성
- 이 배열의 크기는 interpolationPhase 배열과 동일

버퍼가 준비되었다면 나머지 Parameters를 설정할 수 있음.

optioncalFlow를 nil로 설정할 경우 프로세서가 흐름을 계산하도록 함.
submissionMode를 설정하여 프레임이 순서에 따라 전송되는지 혹은 무작위로 전송되는지 지정

정리하자면

VTFrameProcessorConfiguration 클래스는 효과의 처리 세션을 설정하는 방법을 설명
VTFrameProcessorParameters 클래스는 입력 및 출력 프레임과 관련된 모든 매개변수를 설명

앱을 개발할 때 결정해야 할 중요한 요소 중 하나로 광학 흐름을 사전에 계산할 것인지의 여부임.

광학 흐름 계산에는 비용이 많이 들 수 있으며, 일부 앱은 렌더링 단계의 성능을 개선하기 위해 이를 사전에 처리해야 함.

Optical flow는 광학 흐름을 사전에 계산하기 위해서 VTOpticalFlowConfiguration과 VTOpticalFlowParameters를 사용할 수 있음.

VTOpticalFlowConfiguration에서 사전 계산된 flow 매개변수에 false로 설정하면 프레임워크는 흐름을 실시간으로 계산함

1. 사전 계산(Pre-computed) 모드(영상 전체를 미리 분석 -> flow 데이터 저장 -> 필요할 때 꺼내 사용)
- 장점: 재생/처리 시 매우 빠름 (이미 계산되어 있으니까)
- 단점: 초기 분석 시간이 오래 걸림, 메모리/디스크 사용량 큼
- 용도: 영상 편집, 후처리(post-processing), 고품질 슬로우 모션
2. 실시간(Real-time) 모드
- 프레임이 들어올 때마다 즉석에서 flow 계산
- 장점: 초기 지연 없음, 라이브 스트림에 적합
- 단점: 매 프레임마다 계산 비용 발생 (성능 부담)
- 용도: 실시간 카메라 효과, 라이브 비디오 처리

모션 블러는 느린 셔터 속도를 시뮬레이션해서 움직이는 물체가 흐려지는 효과를 생성

API를 통해 블러 강도를 조정해서 화면에서의 흘미 강도를 제어할 수 있음.

블러는 동작이 자연스럽게 보이도록 하거나 빠른 물체에 속도감을 추가하는 것처럼 예술적인 이유로 주로 사용됨

타임랩스에 사용하면 더 자연스러운 느낌을 줄 수도 있음.

모션 블러로 처리 세션을 생성하려면 VTMotionBlurConfiguration 클래스를 사용하고 위에서 처리하는 형태와 동일하니 위의 내용 참고

파라미터는 VTMotionBlurParameters를 사용하며 우선 next와 previous 프레임 등 두 개의 참조 프레임이 필요.

첫 클립에는 previous에서 프레임을 nil로 설정하고 또한 최종 프레임에서 next 프레임을 nil로 설정

프레임 버퍼를 확보했으므로 VTMotionBlurParameters를 만들 수 있음

프로세서가 광학 흐름을 계산하도록 OpticalFlow를 nil로 설정하고 strength는 블러 강도를 설정함.

화상 회의나 실시간 스트리밍과 같은 실시간 영상에 사용하는 예제

우측 3개는 모두 실시간 사용을 위해서 설계되었음.

이러한 기능은 성능을 고려하며 비디오를 개선

Low latency frame interpolation은 일반적으로 수신하는 기기에서 진행.

Low latency super resolution은 아래 2개로 구성되면 실시간 화상 회의를 위해 구성

VTLowLatencySuperResolutionScalerConfiguration
- 프레임 너비, 높이, 스케일링 비율만 필요
VTLowLatencySuperResolutionScalerParameters
- 소스 및 목적지 프레임 버퍼만 필요

Low latency frame interpolation은 아래 2개로 구성되면 실시간 화상 회의를 위해 구성

특히 이 기술은 연결 속도가 느릴 때 영상 통화 앱에 유용.

Judder를 완화하여 편안한 스트리밍 경험을 제공

해당 API에는 프레임 속도 더블링 및 해상도 업스케일링 기능을 하나로 결합한 유틸리티도 존재

VTLowLatencyFrameConfiguration
VTLowLatencyFrameParameters

Video Toolbox 프레임워크는 이미 하드웨어 비디오 인코딩과 디코딩 기능에 대한 직접적인 접근을 비롯해 다양한 기능을 제공

비디오 압축, 압축 해제 픽셀 타입 변환과 같은 서비스를 지원

VTFrameProcessor API를 통해 더 매력적인 애플리케이션을 만들 수 있음.

(참고)

https://www.youtube.com/watch?v=EbRvY6j8d7g&list=PLjODKV8YBFHZ0CMQQU55bE_r6i01KSqCA

SwiftUI의 새로운 기능 (Explore related documentation, sample code, and more) -wwdc25

lgvv — Sat, 2 May 2026 16:21:35 +0900

SwiftUI의 새로운 기능 (Explore related documentation, sample code, and more)

SwiftUI의 저성능 관련 개선사항부터 UI상의 버튼에 이르기까지 시스템 전반에 걸쳐 개선

Make the new design shine
- 새로운 모든 시스템 기능 리뷰
Framework foundations
- 성능과 애니메이션, 레이아웃 관련 개선사항 공유
SwiftUI across the system
- Apple 플랫폼 전반에 걸쳐 SwiftUI를 사용할 수 있는 새로운 환경 소개
Expand SwiftUI views
- 웹 콘텐츠, 리치 텍스트 지원 등 SwiftUI 뷰의 새 기능에 대해 알아볼 것.

Make the new design shine

네비게이션, 버튼, 탭바, macOS, PadOS 등 디자인이 변경되었음

아이템 간 간격은 toolbar의 Spacer API를 사용해 조정.

Liquid Glass는 색조를 지원하기도 하는데 스타일과 색상을 적용하면 됨.

검색 위해 코드를 변경할 필요가 없이 패드, 폰, 맥 등에 한번에 적용됨.

외관을 새롭게 하려면 role에 search를 두어 역할을 갖도록 설정

Liquid Glass는 커스텀하게도 사용할 수 있음.

macOS에서 메뉴 막대 구축시 `.commands` API를 사용했었고, 아이패드에서도 같은 결과를 낼 수 있음.

사용자가 앱 사이즈를 자유롭게 조절할 수 있음.

SplitView를 사용하는 앱은 시스템이 가능한 공간에 따라 자동으로 열을 숨기거나 보임.

앱 크기 조정 기능을 구현하려면 UIRequiresFullScreen과 같이 화면을 전체 크기로 고정하는 API를 외부로 마이그레이션.

UIRequiresFullScreen 이건 PadOS 26에서 더 이상 지원되지 않음.

아이패드 사이즈 조정에 대한 부분을 확인하려면 Elevate the design of your iPad app(WWDC25) 확인

macOS에서도 windowResizeAnchor를 이용해서 사이즈를 동적으로 대응할 수 있음.

Framework foundations

강력한 성능 부터 사용 편의성 개선 및 새로운 콘텐츠 레이아웃에 이르기까지 SwiftUI로 앱을 개발하기 좋은 시점.

프레임워크 성능 개선 또한 여러 앱을 포함해 Apple 플랫폼 전반의 모든 앱에 이점을 가져다 줌.

SwiftUI에서 Lists, Scrolling, Profiling and Debugging이 개선되었음.

macOS에서는 10만개 항목 리스트 로딩이 6배, 업데이트는 최대 16배 더 빠르게 업데이트 됨.

리스트가 클수록 성능이 더 크게 향상되며, 플랫폼 전반에 적용.

SwiftUI가 다음 스크롤링하면 다음 프레임을 렌더링할 수 있도록 함.

하지만 Deadline까지 모든 작업이 완료되지 않으면 프레임이 떨어지게 됨.

iOS 및 macOS는 UI 업데이트를 통해 SwiftUI 스케줄링 경험이 개선

반응성을 향상시키고 SwiftUI가 다음 프레임에 대비해 더 많은 작업을 처리하도록 해줌.

이로 인해서 많은 스크롤을 하는 동안 앱이 중단될 가능성을 줄여줌.

LazyVStack을 ScrollView 안에 넣을 때 SwiftUI가 뷰가 나타나기 직전까지 로딩을 지연시킴

중첩된 ScrollView도 이와 같이 동일하게 동작함.

예를 들어서, 사진 캐러셀과 같은 뷰를 만드는데 좋음.

앱에 어떤 성능 문제가 남아 있는지 이해하려면 Xcode에서 SwiftUI 성능 도구를 사용하면 됨.

긴 body를 업데이트 또는 View 업데이트와 같은 다양한 성능 문제 영역에서 문제를 확인하고 조치할 여러가지 방법을 사용할 수 있음.

Optimize SwiftUI performance with instruments에서 상세한 정보를 확인할 수 있음.

또한 동시성에 부분을 확인하려면 위의 영상 참고할 것

애니메이션에는 AnimatableData이라는 프로토콜을 사용함.

드로잉 방향을 제외한 모든 모앙야 데한 속성을 애니메이션화 함.

전체 애니메이션 데이터 선언을 추가할 때 드로잉 방향을 제외하는 것만 해도 코드가 정말 많은데, 새로운 애니메이션 매크로(@Animatable)를 사용하면, 사용자 지정 애니메이션 데이터 속성을 삭제하고, SwiftUI로 하여금 자동으로 합성하도록 만들 수 있음.

드로잉 방향처럼 애니메이션을 원하지 않는 속성의 경우 @AnimatableIgnored을 사용해서 제외.

레이아웃은 이제 3차원으로 작업하는데 SwiftUI에는 이미 익숙한 수정자에 새로운 깊이 기반 변형이 도입되어, 직접적인 volumetic layout 없이도 더 많은 작업이 가능함.

VisionOS 앱에서 3D가 적합한데, 새로운 Alignment3D를 활용하면 시간에 따른 정렬을 조정할 수 있음.

이건 VisionOS 26의 공간 레이아웃 개선사항으로 Meet SwiftUI spatial layout (WWDC25)를 확인.

SwiftUI across the system

앱은 시스템 전반에 걸쳐 SwiftUI의 이점을 활용할 수 있음.

Scene에 대한 개선사항과 Widget 및 Control과 관련한 새로운 API 덕분에 앱이 플랫폼과 정말 잘 어우러짐.

SwiftUI는 다른 프레임워크와는 훨씬 더 잘 작동함.

Scene은 앱의 뷰에 대한 루트 컨테이너로 인터페이스의 분리된 부분을 나타냄.

앱의 `body` 영역에 선언하여 Scene에 접근할 수 있음.

올해부터는 Scene 브릿징을 통해 UIKit과 AppKit 라이프사이클 앱에서 SwiftUI의 Scene 요청이 가능함.

Scene bridging을 통해서 UIKit과 AppKit에서 라이프사이클 상호운용 가능함.

이를 통해서 SwiftUI에 있는 Scene 타입을 열거나 UIKit 또는 AppKit에서 바로 SwiftUI 기능을 사용할 수 있음.

MenuBarExtra나 ImmersiveSpace 같은 Scene 타입 등을 사용할 수 있음.

WindowStyle 등 다양한 Modifier와도 잘 작동함.

인지 장애가 있는 사용자를 위한 특수 모드인 AssistiveAcess가 존재.

올해 SwiftUI에는 AppKit 작업에 몇가지 큰 개선사항이 있음.

Scene bridging 외에도 SwiftUI 뷰가 있는 시트도 표시할 수 있음.

AppKit 제스처도 SwiftUI로 연결할 수 있음.

interface Builder에서 NSHostingView를 사용할 수 있음.

watchOS 26과 macOS Tahoe는 커스텀 제어 기능을 제공함.

올해부터는 위젯을 VisionOS와 CarPlay에서 사용할 수 있음.

VisionOS는 새로운 레벨 환경 변수를 사용해서 공간을 사용자가 지정할 수 있음.

푸시 기반 업데이트 API 등 올해 여러가지가 새롭게 나옴.

SwiftUI View 기능이 확장되었는데, 리치 텍스트 편집부터 3D 차트에 이르기까지 기존 SwiftUI의 기능과 외관이 새롭게 단장됨.

앱에서 웹 콘텐츠를 곧바로 임베드 할 때 WebKit에서 WebView와 같은 SwiftUI API 전체를 활용할 수 있음.

WebView는 앱에서 웹 콘텐츠를 표시하는 새로운 SwiftUI 뷰로 Safari와 동일하게 WebKit으로 구동.

페이지를 커스텀하고 이와 상호작용하려면 WebView로 새 observable 모델 유형인 WebPage를 표시할 수 있음.

WebPage는 웹과 풍부한 상호작용을 가능하도록 하는데, 프로그래밍을 통해 페이지에서 탐색하고 페이지 속성에 접근함.

WebKit이 SwiftUI를 지원하는 새로운 방법으로 사용자 에이전트 커스텀이나 JavaScript 호출, 커스텀 URL 스킴 등이 생겼고 더 다양해짐.

Chart3D를 통해서 3차원 플롯을 보여줄수도 있음.

올해는 mac에 드래그를 도입해서 여러 항목 주변으로 드래그를 할 수 있음.
새로운 dragContainer도 macOS에서 사용할 수 있음.

이렇게 하면 뷰가 드래그 항목을 담는 컨테이너와 동일해지며, 커스텀 선택 동작과도 함께 작동함.

드래그 앤 드롭이 실행될 때 항목은 지연 드래그하도록 SwiftUI가 자동으로 요청함.

신규 `dragCofiguration` api로 드래그 작업을 사용자화 할 수도 있음.

`onDragSessionUpdated`는 이벤트를 관찰 가능하도록 함.

`dragPreviewsFormation`은 드래그 할 때 미리보기가 어떻게 뜨는지 확인하기 위해서 사용

TextView에 이제 AttributedString이 지원됨.

TextEditor에서 AttributedString에 바인딩을 통해 내장형 텍스트 포맷팅 제어 기능을 사용할 수 있음.

(참고)

https://www.youtube.com/watch?v=cETgTtu6atM

클로저 안에 락을 두어 생기는 데드락 (Apple 시스템 API)

lgvv — Thu, 26 Mar 2026 17:02:00 +0900

클로저 안에 락을 두어 생기는 데드락 (Apple 시스템 API)

클로저 안에 락이 들어 있으면 위험함. 획득이든 해제든 락의 수명이 클로저 실행에 묶이는데, 클로저가 언제 불릴지, 혹은 불리지 않을지 앱이 통제하지 못하기 때문.

애플 시스템 API를 쓰는 영역에서 이 형태로 데드락이 발생. lock을 잡고 시스템 API를 호출한 뒤 완료 클로저 안에서 unlock을 하던 기존 코드였음. 그 클로저가 끝내 호출되지 않으면 lock이 풀리지 않아 무한 대기에 빠짐.

완료 클로저 안의 unlock이 실행되지 않는 경우

락을 잡은 채로 완료 클로저 안에서만 unlock을 하는 형태로 실제 코드를 단순화하면 아래와 같음.

func activateAudioSession() {
    lock.lock()
    // Apple 오디오 세션 관련 시스템 API 호출
    // 완료가 비동기 클로저로 전달됨
    audioSession.requestRecordPermission { [weak self] granted in
        // 응답이 와야 여기서 unlock
        self?.lock.unlock()
    }
    // 함수는 여기서 반환. lock은 아직 잡힌 상태
}

정상 흐름에서는 완료 클로저가 불리면서 unlock까지 이어짐. 문제는 시스템 API가 응답을 주지 않는 경우였음. 콜백이 오지 않으면 클로저 안의 unlock도 실행되지 않고, lock은 잡힌 채로 남음. 이후 같은 lock을 잡으려는 호출은 전부 lock.lock()에서 멈춤.

근본 원인은 unlock을 클로저 안에 둔 것 자체가 아니라, lock을 푸는 시점을 외부 시스템의 응답에 통째로 맡긴 것. 응답이 없으면 해제 시점도 같이 사라짐.

클로저에 콜백이 오지 않을 수 있는 Apple 시스템 API

실제로 발생한 영역에 대한 정리.

모두 클로저나 delegate 콜백이 불릴지 여부가 앱이 아니라 시스템 상태에 달려 있음.

오디오 권한: AVAudioSession의 마이크 권한 요청(requestRecordPermission)
- 콜백이 오지 않아 데드락이 발생했고, 해당 경우에 30초 정도 지나면 콜백이 내려옴.
페이지 전환: UIPageViewController의 setViewControllers(_:direction:animated:completion:)로 앞선 전환 애니메이션이 끝나기 전에 다시 호출하면 completion이 불리지 않고 유실되는 경우가 발생.
- 해결 방법으로는 셋업 단계에서 isEnabledUserInteraction = false로 설정하고 클로저를 받은 후에 다시 활성화
알림 권한: UNUserNotificationCenter의 requestAuthorization(options:completionHandler:)와 getNotificationSettings(completionHandler:). 문서에도 적혀 있듯 메인 스레드를 보장하지 않으면 특정 Xcode 버전에서 배포한 특정 iOS 버전에서만 발생
- 이 케이스에서는 Concurrency API도 동일하게 동작하지 않음
- https://github.com/lgvv/unusernotificationcenter-requestauthorization-blocking-simulation

보완 방법

lock 해제와 흐름 진행을 완료 클로저 하나에만 의존하지 않도록 변경

lock은 공유 상태를 읽고 쓰는 최소 구간에만 사용함. 외부 응답을 기다리는 작업은 lock 밖으로 빼서, lock을 잡은 채 콜백을 기다리지 않게 함.
애플의 시스템 API도 클로저로 콜백이 오지 않을 수 있어서 타임아웃을 함께 두어 예방할 수 있음. 정해진 시간 안에 콜백이 없으면 실패로 처리하고 상태를 원래대로 되돌림.
완료 처리가 한 번만 실행되도록 보호함. 타임아웃과 실제 콜백이 둘 다 도착해도 unlock이나 상태 변경이 중복되지 않게 함.

샘플 코드

func requestMicPermission() {
    // lock은 상태 변경 구간에만 사용
    lock.lock()
    markRequesting()
    lock.unlock()

    audioSession.requestRecordPermission { [weak self] granted in
        self?.finishPermission(with: granted ? .granted : .denied)
    }

    // 콜백이 오지 않는 경우를 대비한 타임아웃
    scheduleTimeout { [weak self] in
        self?.finishPermission(with: .timedOut)
    }
}

finishPermission(with:)을 한 번만 동작하도록 막아 두면, 콜백과 타임아웃 중 먼저 도착한 쪽만 반영됨. 시스템이 응답을 주지 않아도 앱은 정해진 시간 뒤에 실패로 흐름을 정리하고 멈추지 않음.

(참고)

기기별 RAM 용량에 따른 이미지 동적 캐시 사이즈 설계

lgvv — Wed, 25 Mar 2026 23:02:57 +0900

기기별 RAM 용량에 따른 이미지 동적 캐시 사이즈 설계

글로벌 서비스를 운영하다 보면, 여전히 RAM 2GB~3GB 수준의 구형 기기 사용자를 무시할 수 없음. iPhone 8, iPhone SE 1세대, 일부 보급형 기기처럼 메모리 여유가 크지 않은 환경에서는, 캐시 전략 하나만으로도 앱 안정성이 크게 달라질 수 있음. 이미지 캐시는 사용자 경험을 빠르게 만들기 위한 중요한 장치지만, 동시에 메모리를 많이 사용하는 기능이기도 함. 그래서 캐시 크기를 고정값으로 두면 다음과 같은 문제가 생김

저사양 기기에서는 메모리 압박으로 크래시 위험이 커짐
고사양 기기에서는 더 많은 자원을 활용하지 못해 비효율이 발생함

기기의 물리적 RAM 용량을 기준으로 이미지 캐시 사이즈를 동적으로 결정하는 방식을 적용

왜 동적 설정이 필요할까?

iOS는 앱이 사용할 수 있는 메모리 한도를 초과하면 명시적인 에러 없이 프로세스를 종료할 수 있음. 저사양 기기의 경우

RAM 2GB 기기에서 캐시를 1GB로 고정하는 것은 실제 사용 가능한 메모리 대비 과도한 점유가 될 수 있음.
경우에 따라서는 결과적으로 메모리 부족으로 인한 크래시 확률이 높아짐.

고사양 기기의 경우

이미지 디스크 접근 증가
네트워크 재요청 증가
이미지 디코딩 비용 증가
스크롤 체감 성능 저하

즉, 캐시를 너무 작게 잡아도 손해가 커서 기기별 메모리 특성에 맞게끔 균형을 찾고자 함.

전체 코드

메모리 캐시 사이즈에 기기별 가용 가능한 메모리 크기를 기반으로 상한값을 다르게 설정. physicalMemory는 기기 스펙의 메모리 용량과 일치하지 않음(스펙보다 작게 잡힘).

아래 코드에서 1/8 값을 사용하고 있으나 프로젝트 특성에 맞게 변경해도 됨.
- 안드로이드 공식 문서에서 1/8 사용하고 있는 예제가 있어서 그대로 적용

private func configureImageCacheLimits() {
        // 기기의 물리적 RAM 전체 용량 (단위: bytes)
        // 예) 6GB RAM → 6,442,450,944 bytes
        let physicalMemory = ProcessInfo.processInfo.physicalMemory
        // 이미지 캐시에 허용할 최소 메모리 한도 (단위: MB)
        let minimumLimitMB: UInt64 = 100
        
        // 이미지 캐시에 허용할 최대 메모리 한도 (단위: MB)
        let maximumLimitMB: UInt64 = 512
        
        // physicalMemory(bytes) → MB 변환 과정:
        //   ÷ 8          : 전체 RAM의 1/8만 캐시에 사용 (나머지는 OS or 앱 등이 사용)
        //   ÷ 1024       : bytes → KB
        //   ÷ 1024       : KB → MB
        //
        // 예) 6GB RAM 기기:
        //   6,442,450,944 ÷ 8 = 805,306,368 bytes (약 768MB, RAM의 1/8)
        //   805,306,368 ÷ 1024 = 786,432 KB
        //   786,432 ÷ 1024 = 768 MB
        //   → min(512, 768) = 512 → max(100, 512) = 512MB 적용
        //
        // 예) 2GB RAM 기기:
        //   2,147,483,648 ÷ 8 = 268,435,456 bytes (약 256MB)
        //   → 256MB → max(100, 256) = 256MB 적용
        let computedLimitMB = max(
            minimumLimitMB,
            min(maximumLimitMB, physicalMemory / 8 / 1024 / 1024)
        )
        
        // 최종 캐시 한도를 다시 bytes로 변환 (SDImageCache에 bytes 단위로 전달해야 하므로)
        // 예) 512MB → 512 × 1024 × 1024 = 536,870,912 bytes
        let physicalMemoryMB = physicalMemory / 1024 / 1024
        let physicalMemoryGB = physicalMemoryMB / 1024
        
        var systemInfo = utsname()
        uname(&systemInfo)
        let deviceModel = withUnsafePointer(to: &systemInfo.machine) {
            $0.withMemoryRebound(to: CChar.self, capacity: 1) {
                String(validatingUTF8: $0) ?? "Unknown"
            }
        }
        
        print("기기 모델: \(deviceModel)")
        print("물리 메모리: \(physicalMemoryGB) GB")
        print("캐시 한도: \(computedLimitMB) MB")
}

iPhone 14 Pro (모델 식별자 iPhone15,2, physicalMemory 약 5GB)

이미지 01 - iPhone 14 Pro (iPhone15,2)

iPhone 12 mini (모델 식별자 iPhone13,1, physicalMemory 약 3GB)

이미지 02 - iPhone 12 mini (iPhone13,1)

모델 식별자는 마케팅 이름과 다름. iPhone15,2는 iPhone 14 Pro, iPhone13,1은 iPhone 12 mini임.

기기	RAM	1/8 계산값	최종 적용
iPhone SE (1st)	2GB	256MB	256MB
iPhone 11	4GB	512MB	512MB
iPhone 15 Pro	8GB	1024MB	512MB (상한 제한)

(참고) Android 비트맵 캐싱

Socket과 WebSocket 정리 (RFC 6455)

lgvv — Wed, 11 Feb 2026 03:33:15 +0900

Socket과 WebSocket 정리 (RFC 6455)

실시간 통신을 개발하면서 Socket과 WebSocket 그리고 Polling과 Long Polling에 대해서 정리하고자 함.

이 글은 RFC 6455 (The WebSocket Protocol) 섹션 1을 기반으로 정리.

HTTP 정리
Socket이란?
폴링: 계속 물어보는 방식
롱폴링: 물어보고 기다리는 방식
Socket과 WebSocket의 차이
WebSocket: 하나의 TCP 연결로 양방향
오프닝 핸드셰이크: HTTP로 시작해서 HTTP를 떠남
클로징 핸드셰이크: TCP FIN만으로 부족한 이유
TCP, HTTP와의 관계
서브프로토콜
비교 정리

HTTP 정리

HTTP는 요청-응답(request-response) 모델임.

통신은 언제나 클라이언트의 요청으로 시작하고, 서버는 그 요청에 응답만 할 수 있음.

HTTP 모델의 한계는 서버가 먼저 데이터를 전송할 수 없음.

채팅, 게임, 실시간 시세, 라이브 방송의 시청자 수처럼 서버 쪽에서 이벤트가 발생하는 서비스에서는 이 한계가 그대로 문제가 됨.

RFC 6455의 1.1 Background에서는 WebSocket 이전의 웹이 이 문제를 HTTP 남용(abuse of HTTP)으로 풀어왔다고 지적하며, 그 비용으로 세 가지를 언급함.

서버가 클라이언트마다 여러 개의 TCP 연결을 사용하게 됨. 보내는 용도 하나, 받는 용도 하나씩.
모든 메시지에 HTTP 헤더가 붙음. 메시지 한 줄을 보내는 데 수백 바이트의 헤더 오버헤드가 발생.
클라이언트가 "보내는 연결"과 "받는 연결"의 대응 관계를 직접 추적해야 함.

폴링과 롱폴링은 이 한계 안에서 실시간을 흉내 내는 기법이고, WebSocket은 이 한계 자체를 없애는 프로토콜임.

Socket이란?

WebSocket으로 가기 전에, 이름의 원조인 소켓부터 정리.

소켓(socket)은 운영체제가 제공하는 네트워크 통신 인터페이스임. 프로세스가 네트워크로 데이터를 보내고 받으려면 커널의 네트워크 스택을 거쳐야 하는데, 그 출입구가 소켓.

TCP 연결 하나는 (출발지 IP, 출발지 Port, 목적지 IP, 목적지 Port) 조합으로 식별되고, 소켓은 그 연결의 양 끝단(endpoint)임.

앱 입장에서 소켓은 파일 디스크립터라는 숫자 핸들로 보이며, read, write로 바이트를 흘려보내는 통로.

여기서 중요한 성질이 두 가지 있음.

소켓은 프로토콜이 아니라 인터페이스. TCP 위에서 무엇을 주고받을지(HTTP인지, WebSocket인지, 자체 프로토콜인지)는 소켓이 관여하지 않음.
TCP 소켓은 스트림(stream). 바이트가 순서대로 흐를 뿐, "메시지의 시작과 끝"이라는 경계가 없음. 경계를 나누는 일은 위 계층의 몫.

이 두 성질이 뒤에서 WebSocket과의 차이, 그리고 WebSocket이 프레이밍을 도입한 이유로 이어짐.

폴링: 계속 물어보는 방식

폴링(polling)은 클라이언트가 일정 주기로 서버에 "새로운 것 있어?"라고 묻는 방식.

구현이 가장 단순함. 타이머 하나와 평범한 HTTP 요청이면 충분.

문제는 주기 설정이 딜레마라는 점.

주기를 짧게 잡으면: 실시간성은 올라가지만, 대부분의 요청이 빈 응답으로 끝남. 매 요청마다 HTTP 헤더, 경우에 따라 TCP 핸드셰이크와 TLS 협상 비용까지 반복해서 지불.
주기를 길게 잡으면: 낭비는 줄지만, 이벤트 발생부터 전달까지 최대 한 주기만큼 지연됨.

즉 폴링에서 실시간성과 자원 효율은 교환 관계임. 어느 쪽으로 조정해도 한쪽을 포기하게 됨.

롱폴링: 물어보고 기다리는 방식

롱폴링(long polling)은 폴링의 "빈 응답" 낭비를 줄이려는 개선.

클라이언트는 똑같이 요청을 보내지만, 서버는 줄 데이터가 없으면 응답을 바로 돌려주지 않고 보류함. 데이터가 생기는 순간 응답하고, 클라이언트는 응답을 받자마자 다음 요청을 다시 걸어둠.

폴링 대비 개선점은 분명함. 빈 응답이 사라지고, 보류 중인 요청이 있다면 이벤트가 발생 즉시 전달됨.

하지만 요청-응답 모델을 벗어난 것은 아님.

응답 하나당 전달할 수 있는 이벤트는 한 번. 응답을 받고 다음 요청을 다시 거는 사이에 공백이 생기고, 이벤트가 잦으면 사실상 폴링과 비슷해짐.
서버는 응답을 보류하는 동안 클라이언트 수만큼 연결을 계속 점유함.
매 사이클마다 HTTP 헤더 오버헤드는 여전히 반복됨.
클라이언트에서 서버로 보내는 방향은 여전히 별도의 요청이 필요함. RFC 6455가 지적한 "보내는 연결과 받는 연결의 이중 관리" 문제가 그대로 남음.

정리하면, 롱폴링은 서버에서 클라이언트로 오는 지연을 줄였을 뿐, 양방향 통신 자체를 만든 것은 아님.

Socket과 WebSocket의 차이

소켓은 전송 계층 연결(주로 TCP)의 끝단을 다루는 OS 인터페이스. WebSocket은 그 TCP 소켓 위에서 동작하는 응용 계층 프로토콜. WebSocket 연결도 내부적으로는 결국 TCP 소켓 하나를 사용함.

계층 관계는 아래 이미지와 같음.

구분(TCP) SocketWebSocket

정체	OS가 제공하는 통신 인터페이스 (API)	표준 문서(RFC 6455)로 정의된 프로토콜
계층	전송 계층 연결의 끝단	응용 계층
데이터 단위	바이트 스트림 (경계 없음)	메시지/프레임 (경계 있음)
연결 수립	TCP 3-way handshake	TCP 위에서 HTTP Upgrade 핸드셰이크
사용 주체	임의의 네트워크 프로그램	주로 웹 환경 (브라우저 포함)
보안 모델	없음 (앱이 알아서)	origin 기반 보안 모델 내장

즉 "Socket vs WebSocket"은 대등한 비교가 아니라 층이 다른 개념임.

WebSocket을 이해한다는 것은 "TCP 소켓 위에 어떤 규칙을 얹었는가"를 이해하는 일.

WebSocket: 하나의 TCP 연결로 양방향

RFC 6455가 정의하는 WebSocket은 폴링, 롱폴링이 우회하던 문제를 정면으로 풂.

핵심은 단 하나의 TCP 연결 위에서 클라이언트와 서버가 대등하게, 아무 때나, 양방향으로 메시지를 보내는 것.프로토콜은 크게 두 부분으로 구성됨 (RFC 6455 §1.2).

핸드셰이크: HTTP 형식을 빌린 연결 수립 절차
데이터 전송: 연결 수립 후, 프레임(frame) 단위로 메시지를 주고받는 단계

이 구조 덕분에 폴링의 세 가지 비용이 모두 사라짐. 연결은 하나고, 메시지마다 붙는 것은 HTTP 헤더가 아니라 몇 바이트짜리 프레임 헤더이며, 보내는 연결과 받는 연결을 구분해서 관리할 필요가 없음.

오프닝 핸드셰이크: HTTP로 시작해서 HTTP를 떠남

WebSocket 연결은 평범한 HTTP GET 요청으로 시작함. RFC 6455 §1.2의 예시 그대로.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

서버가 WebSocket을 지원하면 아래처럼 응답함.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

상태 코드 101 Switching Protocols가 교환되는 순간, 이 TCP 연결 위의 대화는 더 이상 HTTP가 아님. 같은 연결이 그대로 WebSocket 프레임을 실어 나르는 통로가 됨.

굳이 HTTP 형식으로 시작하는 이유는 호환성 (§1.3). 80/443 포트, HTTP 서버, 프록시 같은 웹의 기존 인프라를 그대로 통과하기 위해, 이미 웹이 이해하는 문법인 HTTP Upgrade 메커니즘을 입구로 삼음.

각 헤더의 역할:

Upgrade: websocket + Connection: Upgrade: 이 연결을 WebSocket으로 전환하겠다는 선언
Sec-WebSocket-Key: 16바이트 난수를 base64 인코딩한 값 (다음 절에서 정리)
Sec-WebSocket-Version: 13: 프로토콜 버전. RFC 6455가 13
Origin: 브라우저 환경에서 요청 출처를 서버에 알려주는 값. 승인되지 않은 웹 페이지의 크로스 오리진 연결을 서버가 거부할 수 있게 함
Sec-WebSocket-Protocol: 서브프로토콜 협상 (뒤에서 정리)

클로징 핸드셰이크: TCP FIN만으로 부족한 이유

TCP에도 이미 연결 종료 절차(FIN/ACK)가 있음. 그런데 WebSocket은 그 위에 자체 종료 핸드셰이크를 하나 더 정의함 (§1.4).

절차는 단순함. 한쪽이 Close 프레임을 보내고, 상대가 Close 프레임으로 응답하면, 먼저 보낸 쪽이 TCP 연결을 닫음. 양쪽이 동시에 시작해도 됨.

TCP 종료를 그대로 쓰지 않는 이유를 RFC는 아래처럼 설명함.

TCP의 종료 신호는 프록시 같은 중간 장치를 거치는 환경에서 끝(end-to-end)까지 항상 신뢰성 있게 전달된다고 보장할 수 없음.
응용 계층에서 명시적으로 Close를 주고받으면, 양쪽 모두 "상대가 내 마지막 데이터까지 받았고, 연결이 의도적으로 끝났다"는 사실을 확실히 알 수 있음. 갑작스러운 연결 유실과 정상 종료를 구분할 수 있게 됨.

Close 프레임을 받은 뒤에 도착하는 데이터는 폐기됨.

TCP, HTTP와의 관계

WebSocket은 TCP 위에서 동작하는 독립적인 프로토콜. HTTP와의 관계는 핸드셰이크가 HTTP 서버에게 Upgrade 요청으로 해석.

핸드셰이크가 끝난 뒤의 WebSocket 트래픽은 HTTP가 아님. HTTP의 메서드, 상태 코드, 헤더 같은 개념은 더 이상 등장하지 않음.
기본 포트는 HTTP와 같음. ws://는 80, TLS 위에서 동작하는 wss://는 443. 기존 웹 인프라와 공존하기 위한 선택.
같은 포트를 HTTP 서버와 공유할 수 있음. 이 경우 WebSocket 연결 시도는 서버 입장에서 "Upgrade 헤더가 붙은 평범한 GET 요청"으로 보임 (§1.8).
RFC는 당시 기준으로 443 포트(wss)의 연결 성공률이 80 포트보다 유의미하게 높았다고 언급함. 중간 장치들이 TLS 트래픽에는 개입하지 못하기 때문.

서브프로토콜

WebSocket은 메시지의 경계와 타입(텍스트/바이너리)까지만 정의함. 그 메시지 안에 무엇을 어떤 형식으로 담을지는 프로토콜이 관여하지 않음.

그 "안의 규칙"을 협상하는 장치가 서브프로토콜 (§1.9).

클라이언트는 핸드셰이크에서 사용 가능한 서브프로토콜 목록을 제시하고, 서버는 그중 하나를 선택해서 응답함.

클라이언트: Sec-WebSocket-Protocol: chat, superchat   (이 중에 골라줘)
서버:      Sec-WebSocket-Protocol: chat              (chat으로 하자)

RFC가 권장하는 관례는 두 가지.

이름 충돌을 피하기 위해, 서브프로토콜 이름에 만든 주체의 도메인을 포함. 예: chat.example.com
버전 관리: 기존 클라이언트와 호환되지 않는 변경이라면 새 이름을 사용 (예: v2.chat.example.com). 같은 이름을 유지하며 확장하려면 하위 호환을 신중히 설계해야 함.

STOMP 같은 메시징 프로토콜이 WebSocket 위에서 동작하는 것이 바로 이 서브프로토콜 계층의 활용.

비교 정리

구분	폴링	롱폴링	WebSocket
통신 모델	요청-응답 반복	요청-응답 (응답 보류)	양방향 (full-duplex)
서버 → 클라이언트 지연	최대 폴링 주기만큼	거의 즉시 (요청 보류 중일 때)	즉시
클라이언트 → 서버	별도 요청	별도 요청	같은 연결로 즉시
메시지당 오버헤드	HTTP 헤더 전체	HTTP 헤더 전체	프레임 헤더 몇 바이트
빈 응답 낭비	있음 (주기가 짧을수록 큼)	없음	없음
연결 관리	요청마다 새로 (keep-alive 여부에 따라 다름)	사이클마다 반복	하나의 TCP 연결 유지
서버 부담	잦은 요청 처리	대기 연결 다수 점유	연결당 상태 유지
구현 복잡도	낮음	중간	프로토콜/라이브러리 필요
인프라 호환성	어디서나 동작	어디서나 동작 (타임아웃 주의)	중간 장치에 따라 차단될 수 있음 (wss 권장)

폴링: 갱신 주기가 길고 실시간성이 중요하지 않은 데이터에 적합. 예를 들어 몇 분 단위의 상태 확인. 구현과 운영이 가장 단순하고, 어떤 인프라에서도 동작함.
롱폴링: 실시간성이 필요하지만 WebSocket을 쓸 수 없는 환경의 폴백(fallback). SockJS 같은 라이브러리가 WebSocket 실패 시 롱폴링으로 내려가는 전략을 쓰는 이유.
WebSocket: 양방향 메시지가 잦은 경우. 채팅, 실시간 게임, 협업 편집, 시세 스트리밍처럼 서버 푸시와 클라이언트 전송이 모두 빈번한 서비스.

판단 기준을 하나로 줄이면 이렇게 됨. 서버가 먼저 클라이언트에게 데이터를 주어야 하는 빈도가 높고 양방향인가이라면 WebSocket, 아니라면 더 단순한 쪽이 나음.

소켓은 인터페이스, WebSocket은 프로토콜. WebSocket도 결국 TCP 소켓 하나 위에서 동작함.
HTTP의 근본 한계는 서버가 먼저 말을 걸 수 없다는 것. 폴링과 롱폴링은 그 한계 안의 우회책.
WebSocket 핸드셰이크는 HTTP로 시작하지만, 101 응답 이후 그 연결은 더 이상 HTTP가 아님.
Sec-WebSocket-Key와 Accept는 암호화나 인증이 아니라 "상대가 WebSocket을 이해했는가"의 검증.
WebSocket이 TCP에 얹은 것은 네 가지뿐. origin 보안 모델, 주소 지정, 프레이밍, 클로징 핸드셰이크.
메시지 안의 형식은 서브프로토콜의 몫.

(참고)

RFC 6455 - The WebSocket Protocol

HTTPURLResponse.allHeaderFields 파싱 시 NSNumber 헤더 누락 문제

lgvv — Wed, 4 Feb 2026 02:13:19 +0900

HTTPURLResponse.allHeaderFields 파싱 시 NSNumber 헤더 누락 문제

네트워크 응답 처리 레이어에서 `HTTPURLResponse.allHeaderFields`를 [String: String] 형태로 변환해 상위 모듈에 전달.

기존 변환 사용 로직은 Any를 `as? String`으로 캐스팅하는 방식인데, 이 방식이 Swift 타입 시스템과 Foundation의 NSNumber 브리징 동작이 결합되어 일부 헤더를 조용히 누락시키는 현상

코드 예시

참고로 헤더에는 동일한 key가 중복을 허용하고 있어서 header는 동일 키 값에 대해서도 여러개 받을 수 있도록 해야함.

/// ❌ 기존 코드 
var responseHeader: [String: String] = [:]

for (headerKey, headerValue) in httpResponse.allHeaderFields {
    guard let key = headerKey as? String,
          let value = headerValue as? String   // ← ❌ NSNumber면 nil → continue
    else { continue }

    responseHeader[key] = value
}

/// ✅ 안전한 방식
var responseHeader: [String: String] = [:]

for (key, value) in httpResponse.allHeaderFields {
    guard let keyString = key as? String else { continue }
    responseHeader[keyString] = String(describing: value)
}

///   NSNumber가 데이터로 들어오는 경우 
Content-Length: 123

(참고)

https://developer.apple.com/documentation/foundation/httpurlresponse/allheaderfields

allHeaderFields | Apple Developer Documentation

All HTTP header fields of the response.

developer.apple.com

https://developer.apple.com/documentation/foundation/httpurlresponse/value(forhttpheaderfield:)

HTTPURLResponse | Apple Developer Documentation

The metadata associated with the response to an HTTP protocol URL load request.

developer.apple.com

https://developer.apple.com/documentation/swift/string/init(describing:)-67ncf

init(describing:) | Apple Developer Documentation

Creates a string representing the given value.

developer.apple.com

https://github.com/swiftlang/swift-corelibs-foundation/pull/287

Implement NSHTTPURLResponse by danieleggert · Pull Request #287 · swiftlang/swift-corelibs-foundation

This implements both the trivial attributes (statusCode and allHeaderFields), and also parses the headers in order to set the following attributes: public var mimeType: String? { get } public var e...

github.com

Instrumets로 행 분석하기 (Analyze hangs with Instruments) - WWDC23

lgvv — Sun, 4 Jan 2026 00:47:22 +0900

Instrumets로 행 분석하기 (Analyze hangs with Instruments) - WWDC23

행에 대해서 자세히 알아볼 예정.

행의 기초 지식으로 시작하여 3가지 다른 행과 insturment를 통해 문제를 분석

What is hang?
- 인간의 지각하는 것과 행의 개요
Event handling and rendering loop
- 이벤트 처리와 렌더링 루프라는 행을 일으키는 원인의 기초
Busy main thread hang
- main thread가 busy함으로써 나타나는 행
Asnyc hang
- 비동기 행
Blokced main thread hang
- 메인 스레드가 차단되어 발생하는 행

우선 행을 발견하려면 행을 발견하기 위해서는 위와 같은 범주를 가지는데, 이는 다른 세션에서 확인

해당 세션에서는 이미 찾은 행을 instruments를 사용하여 분석하는 것을 위주로 진행.

상황에 따라 지연이 발생할 수 있는데 어떤 종류의 지연이 용인되는지는 상황에 따라 다름.

거북이와 유니콘이 대화하는 건 Request-Response 형태이 상호작용은 적정한 행이

전선을 꽂는 행위는 실제로 직접적으로 물체를 조작하는 것으로 실제 물체는 바로 반응함.

즉, 실제 시뮬레이션도 즉각 반응해야 하며, 그렇지 않은 경우에 사용자의 illusion이 깨짐.

인간의 지각 능력의 행에도 영향을 줌.

100ms: 즉각적으로 느껴지면 이거보다 짧아야하는 특수한 상황도 있지만 목표로 삼기에 좋음
~250ms: 상황에 따라 달라지면 250ms까지는 괜찮을 수 있음
~500ms: 상황에 따라 다르지만 즉각적인 느낌이 들지 않음.
- 따라서 대부분의 tool이 250ms부터 행을 보고
- 이런건 쉽게 무시할 수 있고, 맥락에 따라 괜찮을 수도 있고 아닐수도 있음.
500ms~: 정식 행으로 간주

Instant 상호작용이면 < 100ms 이어야 하며 Request - Response 상호작용 형태라면 500ms 동안 추가 피드백이 없어도 괜찮음.

하지만 둘 다 허용되는 형태도 존재

(이메일 버튼 클릭 -> 이메일 API Request -> 이메일 API Response -> 이메일 창 닫기)의 흐름이 존재할 때

(이메일 버튼 클릭 -> 이메일 전송 버튼 UI 즉시 변경 ->이메일 API Request -> 이메일 API Response -> 이메일 창 닫기)흐름으로 작업한다면 실제 이메일 UI가 바뀜으로써 사용자는 지연이라고 느끼지 못함.

UI가 빠르게 작동할 수 있도록 메인이 아닌 작업은 UI에서 빼내야 함.

Hardware: 사용자의 클릭을 받고

OS: 운영체제에서 어떤 프로세스가 이벤트를 처리할지 알아내서 해당 프로세스를 앱으로 전달

App: MainThread에서 UI 처리를 수행

Render Server: 각각의 UI Layer를 합성하고 다음 프레임을 렌더링하는 별도의 프로세스

Display: Render Server가 준비한 비트맵을 화면 픽셀에 맞게 업데이트

이 과정에서 다른 이벤트가 들어오면 대다수는 병렬로 처리할 수 있음.

하지만 단일 이벤트가 파이프를 지나가는 과정에서 시퀀스의 모든 단계를 살펴봐야 함.

Main Thread로 가기 전 마지막 프로세싱 단계와 이후의 렌더링과 디스플레이 업데이트 단계는 걸리는 시간을 예측하는게 쉬운편

만약 interaction이 너무 오래 걸린다면 MainThread의 작업이 오래 걸렸거나

MainThread에서 이미 다른 작업을 수행하고 있어서 작업이 끝날 때까지 기다린 뒤 수행되는 경우

메인 스레드의 모든 작업이 100ms를 넘으면 안되며 빠를수록 좋음.

메인 스레드의 긴 작업은 히치도 유발할 수 있음.

Insturment는 반응이 없는 메인 스레드를 잠재적으로 행을 발생시킬 수 있다고 기록.

행이 발생한 경우에는 2가지로 나눌 수 있는데

Busy Main Thread: 메인 스레드가 바쁨
- 메인 스레드에 다양한 CPU 활동이 나타남
Blocked Main Thread: 메인 스레드가 차단됨.
- 다른 곳에서 완료해야 하는 작업을 기다리고 있어서 메인 스레드의 CPU 활동이 없거나 미미

해당 예제에서는 CPU 사용량이 100을 넘지는 않지만 꽤 높은 수준은 60% ~ 90% 사이를 사용

Heaviest Stack Trace에는 소스 코드에서 유래하지 않은 이후의 함수 호출에 관련되지 않는 부분들을 기본적으로 숨겨서

어떤 함수에서 문제가 발생했는지 시작할 수 있음.

Call Tree에서도 동일한 효과를 낼 수 있는데, Hide System Libraries를 체크

Busy Main Thread인 이유에는 2가지가 있는데, 경우에 따라서 메인 스레드 작업을 줄이는 방법이 다름.

메서드가 오랜기간 실행
호출 횟수가 많아서 빈번

위의 사례는 something()에서 호출하는 Turtles 함수가 너무 많이 수행하고 있음.
- 이 경우에는 작업을 줄여야 함.
- 오래 실행되는 함수의 경우에는 함수의 적용과 호출 대상을 살펴봐야 함.

위의 사례는 something()에서 Unicorns을 너무 많이 호출하고 있음.
- 이런 케이스가 발생하는건 Unicorn 함수를 호출하는 호출자가 loop 같은 영역에서 호출하기 때문.
- 이 경우에는 Unicorn 함수의 기능을 최적화하는 대신 더 적게 호출하는 방법을 조사하는게 나을 수도 있음.

Turtle 함수처럼 오래 실행되는 코드의 경우에는 흐름의 더 아래쪽을 살펴봐야 하고,

Unicorn 함수처럼 빈번하게 실행된다면 흐름의 위를 살펴봐야 함.

위의 이미지처럼 샘플별로 어떤 함수가 CPU에서 실행 중인지 확인

하지만 Time Profiler에서는 현재 4가지 시나리오가 존재하여 어떤 경우인지는 알려줄 수 없음.

특정 함수의 실행 시간을 재려면 `os_signposts`를 사용.

2019년 Instrument 시작하기 세션에서 사용 방법을 다룸.

SwiftUI에서 각 구간은 하나의 View Body의 실행.

몇 개의 Body를 실행하는데 얼마나 걸렸는지를 정확하게 알 수 있음.

여기서는 너무 많이 실행되는게 문제이고, BackgroundThumbnailView가 70번이나 실행되었는데 평균 실행시간이 약 50ms이며, 총 소요 시간도 3s가 넘음.

이미지 6개만 보여주면 되는데 70번의 뷰 업데이트는 너무 과하다는 것을 유추할 수 있음.

Grid는 전체를 한번에 처리하지만 LazyVGrid를 통해 보여줄 만큼만 처리하는 형태로 개선

마이크로 행은 화면이 작은 경우에 문제가 없지만 아이패드를 통해 화면이 큰 경우에 긴 행으로 변함.

개발 때 테스트에서 발견한 마이크로 행이 상황이 다른 사용자에게는 심각한 행일 수 있음.

이 경우에는 LazyVGrid를 통해 화면에 표시되는 뷰만 렌더링할 수 있도록 수정해서 호출 수를 줄여 최적화하는 방법은 사용할 수 없음.

각각의 실행 속도를 더 빠르게 해야함

시간이 오래 걸린 하나의 BackgroundThumbnailView를 설정하고 Main Thread를 분석

Insturments가 View Body의 getter 부분을 Heaviest Back Trace에 보여주고

`BackyardBackground.thumbnail.getter` 호출하는 것을 보여줌

-[UIImage imageByPreparingThumbnailOfSize:]가 `BackyardBackground.thumbnail.getter`를 호출.

즉, 썸네일을 실시간으로 처리하고 해당 작업은 150ms가 걸림.

이런 작업은 백그라운드에서 진행해야 하며, Main Thread를 busy하게 하면 좋지 않음.

변화를 주기 전에 `BackyardBackground.thumbnail.getter` 호출하는 맥락을 먼저 살펴봄.

`BackyardBackground.thumbnail.getter`의 맥락을 살펴보기 위해서 먼저 Open in Source Viewer를 클릭.

오른쪽 이미지처럼 코드가 나타남.

해당 코드는 BackgroundView가 반환한 썸네일을 포함한 Image를 만듦.

여기서 썸네일의 호출이 오래 걸려서 코드를 다르게 작성할 필요가 있고, 인디케이터를 활용하고자 함.

SwiftUI가 나타날 때 task를 시작하여 background.thumbnail을 호출하고 결과값을 image에 할당하여 View를 업데이트할 예정.

하지만, 이렇게 개선했음에도 iPad에서는 아직도 2초에 가까운 행을 가짐.

이번에는 행이 조금 뒤에 나타나는데, 이미지 로딩 중에는 저의 탭이 무시됨.

메인 스레드가 바쁜 상태인 것과 차단된 것의 차이는 위에 서술했고, 이번에는 조금 다른 종류의 행.

행이 일어나는 원인과 행이 발생하는 시점에 대한 부분인데 이를 각각 동기 및 비동기 행이라고 부름.

Synchronous/Direct
- 이벤트가 들어왔을 때 이벤트 처리에 오랜 시간이 걸리면 이것을 행이라고 함.
Asnychronous/Delayed
- 이벤트를 빠르게 처리한다고 가정하면 메인 스레드에서 일부 작업을 연기하거나 메인 스레드에서 다른 작업을 처리중일 때 이벤트가 발생하면 이전 작업이 끝날 때까지 기다렸다가 이벤트를 처리할 수 있음.
- 이 경우에는 이벤트 처리 코드가 각 작업을 빨리 끝내도 여전히 행이 발생함.

Apple 플랫폼에서 행을 감지하는 방식은 메인 스레드의 모든 작업 항목을 살펴보고 너무 길지 않은지 확인.

충분히 길다면 이를 잠재적 행(Potential Hang)으로 표시

이때 사용자의 입력과 관계없이 행을 잠재적 행으로 표시하는데, 사용자 입력이 언제 발생할지 모르기 때문에 실제 행으로 나타날 수도 있음.

따라서 행을 감지할 때 Asnychronous/Delayed 행도 감지함.

잠재적인 delayed를 측정한거고 실제로 나타난 delay는 아님

Asnychronous 행을 이라고 부르는 이유는 Main Queue의 dispatch_async 작업이 원인이거나 Swift Concurrency의 Task가 MainActor에 의해서 실행되기 때문인데 Main Thread에 작업을 발생시키는 모든 게 원인이 될 수 있음.

버튼을 탭 하는 동작 자체로 힘든 작업은 아닌데 MainThread에 여전히 작업이 있어서 탭 동작을 처리할 수 없음.

앱을 사용하는 사람들이 눈치채지 못할 수 있고 이 시점에 앱과 상호작용을 안할 수도 있지만 그럴 가능성에 대비해서 수정해야 함.

총 70회가 실행된 것은 SwiftUI가 Grid를 채우기 위해 40개의 View를 생성했지만

`BackyardBackground.thumbnail.getter`의 부분이 대부분 2회씩 실행되었기 때문에 70번 정도 수행됨.

실제로 화면에 표시된건 35개이며, 35개의 View도 이미지를 로딩하기 시작하며 이미지 로딩 후 View를 업데이트하고 body를 다시 호출하여 body의 실행이 총 75회가 됨.

다시 정리하자면 40개의 View를 생성, 35개만 UI에 표현하지만, 각각 2번씩 실행

40개 중 35개는 View에 2번씩 실행되면서 표시되고, 5개는 표시되지 않아서 1번만 실행

따라서 35 * 2 + 5 * 1 = 75회 실행

75개의 body.getter가 실행되는데 1ms도 걸리지 않음.

즉, body.getter는 Progress를 통해서 수정되었지만, 그럼에도 불구하고 아직도 행이 존재.

`BackyardBackground.thumbnail.getter`의 클로저에서 `Background.thumbnail.gertter`를 호출하고 있으며 `body.getter`가 직접 호출하지 않음.

이때 코드가 실행되어야 하지만 Main Thread에서 실행되면 안됨.

이런 경우 Swift Concurreny의 Task가 기대했던 대로 실행되지 않을 때는 Swift Concurrency를 진단하는 Instruemnts를 활용

커맨드 키를 누른 상태로 클릭하면 여러 정보를 함께 볼 수 있음.

1. SwiftUI View의 body가 `View` 프로토콜에 있는 @MainActor를 암시적으로 상속받음
2. `.task { }`가 주변의 context를 통해 actor isolation을 상속 받음.
- 이에 따라서 `.task`안의 클로저도 @MainActor isolation을 암시적으로 상속받고 여기에서 실행되는 모든 코드는 @MainActor임
3. `background.thumbnail`의 `getter`가 동기적으로 동작하기 때문에 메인 스레드에서 동기적으로 실행됨.

Swift Concurrency Task는 기본적으로 주변 context의 actor isolation을 상속 받음.
- 따라서 SwiftUI의 `.task { }`도 같은 행동을 취함.
main actor에서 분리되는 방법에는 2가지가 있음
- await을 통해 함수를 비동기적으로 호출해서 Task가 main-actor에서 분리되도록 함.
  - 효율적이고 SwiftUI는 자동으로 생성된 `Task`를 취소함.
- 하지만 이게 가능하지 않다면 `Task.detached {}`에서 주변 context에서 Task를 명시적으로 분리함.
  - 단, `Task.detached {}`를 사용하는건 강압적이고 기존 작업을 유보하는 것보다 비용이 더 많이 들어감.
  - `Task.detached {}`는 비구조적 `Task`로 취소가 전파되지 않음.

SwiftUI의 `.task { }` MainActor에 속하기 때문에 thumbnail에서 `getter`를 `async`를 통해 비동기로 전환하고, task에서 `await` 키워드를 추가.

코드를 변경하고 instruments를 보면 행이 사라졌지만 CPU 사용량이 조금 높음.

메인 스레드를 사용하는 부분을 확인하면 썸네일을 로딩하는 부분으로 모든 `task`의 구간이 아주 짧음

메인 스레드를 사용하는 시간이 이전과 비교해서 매우 개선되었다는 의미

메인 스레드를 적게 사용하고 있기에 다른 스레드 트랙으로 가서 확인해보면 다른 스레드에서 serial이 아닌 parallel로 실행하고 있음.

즉, CPU의 멀티 코어를 제대로 활용하고 있기에 이를 통해 모든 썸네일을 매우 빠르게 처리 가능.

따라서 백그라운드에서 실행하는 시간 동안에 메인 스레드는 반응성을 유지할 수 있음.

1. 메인 스레드가 CPU를 많이 사용하여 행이 나타나던 문제. 즉, 메인 스레드가 busy하여 반응성이 없던 문제를 해결.

2. Synchronous으로 발생하는 행은 사용자 인터랙션의 일부로 나타날 수 있음을 알았고

3. Asynchronous적으로 발생하는 건 메인 스레드에 예정되었던 작업이 새로운 이벤트가 처리되는걸 늦춘다는걸 알았음.

이 경우들 모두 Instrument가 감지할 수 있었음.

행을 수정하는 방법은 작업을 적게 하거나 적게 할 수 없는 일은 백그라운드에서 처리한 뒤 UI를 업데이트 할 때만 메인 스레드로 돌아오는 방법.

마지막 사례로 메인 스레드가 block된 경우인데 이 경우에는 메인 스레드가 CPU를 아주 적게 사용.

이런 사례를 분석하려면 다른 instruments가 필요.

긴 행이 발생한 영역의 메인 스레드의 CPU Usage를 확인해보면 초반에는 CPU를 사용하지만 나중에는 사용량이 없음.

메인 스레드가 차단된 경우임.

이걸 더 확대해서 확인하면 CPU Usage 그래프가 개별 샘플까지 보여줌.

각 마커(R 표시)는 Time Profiler가 가져온 샘

샘플이 없는 시간대를 Range를 확대하면 이 시간에는 데이터를 녹화하지 않았기 때문에 Time Profiler가 어떤 일이 일어나는지 알려줄 수 없음.

따라서 다른 도구가 필요한데, `Thread States Trace` instruments임.

Thread 정보를 확인할 수 있는데, 메인 스레드에 오랜 시간 차단된 것을 확인할 수 있음.

이것이 행이 길게 발생하는 원인이 될 수 있음.

좌측

여기 정보를 보면 6.64초 동안 차단되었다는 것을 확인할 수 있음.
시스템 콜인 `mach_msg2_trap`가 6.64초를 차단했다는 것을 확인할 수 있음.

우측

Backtrace로 Heaviest Stack Trace와는 다른 정보가 존재.
시스템 콜인 `mach_msg2_trap`의 정확한 backtrace로 스레드를 차단한 원인.
함수 호출이 리프 형태로 표시되어 있고, 호출 스택은 그 위에 표시.

좌측부터 1,2,3

좌측부터 4,5,6

호출 스택을 분석하자면 `mach_msg2_trap` 시스템 콜이 발생한 이유는 MLModel 할당 때문.

ColorizingService Type의 객체 할당 때문이며, 이는 ColorizingService의 싱글톤 객체인 shared의 일부로 호출되었음.

ColorizingService의 싱글톤 객체는 `BackgroundThumbnailView.body.getter` 클로저에서 호출

ColorizingService.shared에 접근하여 로컬 변수에 저장

여기서 문제는 `shared`에 처음 접근시 ColorizingService 인스턴스를 만들기 때문에 이로 인하여 모델을 로딩하는 전체 과정을 시작
따라서 스레드를 차단.

이 문제를 해결하기 위해서 이전과 같은 방법으로 `.task { }`를 await 을 통해 분리하는 접근법을 시도할 수 있으나 이 예제에서는 문제를 해결하지 못함.

왜냐하면 await 키워드는 이후 코드의 비동기 함수 호출에만 적용되기 때문

여기 예제에서는 `colorize` 메서드가 비동기 메서드이지만 `shared`의 프로퍼티는 그렇지 않음.

`static` 프로퍼티이기 때문에 처음 접근했을 순간(lazy 초기화)되며, 이 시점에는 모두 동기적으로 진행.

즉, await 키워드가 shared를 바꾸지 않아서 여전히 메인 동기적인 호출은 메인 스레드에서 발생

이전 사례 처럼 처리하려면 `shared`도 asnyc로 만들어서 MainActor에서 분리해야 함.

스레드가 아닌 진전이 있는 곳에서 작업을 기다리고 있다면 일반적으로 괜찮을 수 있음.

스레드 차단의 일반적인 이유는 Lock과 Semaphore.

다른 영역에서 메인 스레드가 Blocked로 표시되어 있지만 이 부분에서는 Instruments가 잠재적인 행으로 표시하지 않음.

단지, 사용자 입력이 없어서 메인 스레드가 잠든(aleep) 상태.

운영체제 관점에서는 차단된 것처럼 보이지만 할 일이 없을 때는 실행을 멈추고 자원을 아끼는 것.

이후 입력값이 들어오자마자 깨어나서 처리함.

차단된 스레드가 반응성 문제인지 결정할 때는 Hangs Instruemnts를 먼저 확인

Blocked MainThread가 무조건적으로 Main Thread 반응이 없다는 것을 나타내지(암시하지) 않음.

또한 CPU Usage가 높다는 것이 단순히 Main Thread 반응이 없는걸 나타내지(암시하지) 않음.

왜냐하면 Main Thread가 반응하지 않은 경우에는 OS가 자원을 아끼기 위해 Blocked으로 처리할 수 있으며, 실제로 반응하지 않은 경우에만 Insturments는 잠재적인 행으로 나타냄.

하지만 Unresponsive Main Thread 이라면 blocked 또는 busy하다는 의미

메인 스레드에서 어떤 작업을 하든 100ms 이하로 작업해야 메인 스레드를 이벤트 처리에 쓸 수 있음.

물론 짧을수록 더 좋음

Busy한 상태와 Blocked된 상태의 메인 스레드의 차이점을 명확하게 기억하고 메인 스레드의 비동기 작업으로 발생할 수 있는 행도 기억하기.

행을 수정하려면 작업을 줄이거나 백그라운드로 옮겨야 함. 때로는 둘 다 해야함.

작업을 적게한다는 것은 작업에 맞는 적절한 API를 사용한다는 것.

(링크)
https://www.youtube.com/watch?v=lWVuP3Vts_0

lgvv98

Express req.query와 query parser

Express req.query와 query parser

예제 요청

왜 배열이 되는지

query parser 설정

simple query parser

실제 배열 변환

전체 흐름

[Object: null prototype] 정리

하나만 보내면 문자열

extended parser를 쓰면?

정리

Express app.param vs app.get

Express app.param vs app.get

기준

app.get

app.param

왜 app.param을 쓰는지

전체 예제

요청예제

실행 순서

path params와 query params 차이

그러면 query도 app.get에서 가져올 수 있을까? (O)

비교

헷갈리기 쉬운 부분

언제 app.param을 쓰면 좋을까

정리

Rust의 Copy와 Clone 차이점 정리

Rust의 Copy와 Clone 차이점 정리

목차

요약

i32는 왜 대입 후에도 사용할 수 있을까?

String은 왜 move될까?

Copy란?

Clone이란?

Copy와 Clone의 헷갈리는 부분 정리

구조체에서 Copy와 Clone 사용하기

Copy를 붙일지 판단하는 기준

정리

참고

Rust 소유권 (Ownership) 이해하기

Rust 소유권 (Ownership) 이해하기

목차

Rust가 소유권을 사용하는 이유

Stack과 Heap

소유권 규칙

Move

Clone

Copy

함수와 소유권

참조와 빌림

Mutable Reference

Dangling Reference

참조 규칙

Slice 타입

String Literal과 Slice

다른 Slice

정리

용어 정리

참고

What's new in SwiftUI (WWDC26)

What's new in SwiftUI (WWDC26)

목차

Refreshed look and feel

UIKit 앱 현대화하기 (Modernize your UIKit app) - WWDC26

UIKit 앱 현대화하기 (Modernize your UIKit app) - WWDC26

목차

Adaptivity

SwiftUI의 Observation 알아보기 (Discover Observation in SwiftUI) - WWDC23

SwiftUI의 Observation 알아보기

목차

SwiftUI 핵심 기능 (SwiftUI essential) - WWDC24

SwiftUI 핵심 기능 (SwiftUI essential) - WWDC24

목차

머신 러닝 기반 비디오 효과로 앱 향상하기 (Enhance your app with machine-learning based video effects) - WWDC25

머신 러닝 기반 비디오 효과로 앱 향상하기

목차

SwiftUI의 새로운 기능 (Explore related documentation, sample code, and more) -wwdc25

SwiftUI의 새로운 기능 (Explore related documentation, sample code, and more)