구리스

indirect Enum, 근데 이제 약간의 CS 지식을 곁들인 .. - 1일1챌린지

Guryss — Wed, 1 Apr 2026 15:57:42 +0900

https://guryss.tistory.com/21

해당 챌린지에서 연결된 심화 개념..? 이라고 하자

Enum 열거형 기초 개념을 다시 새겨보자 - 1일1챌린지

Enumeration Model custom types that define a list of possible values. 관련 값들을 정의하는 커스텀 타입관련된 값들의 그룹에 대한 공통 타입을 정의한다.코드 내에서 type-safe한 방식으로 값들을 사용할 수 있다

guryss.tistory.com

열거형은 값 타입이다 (like Struct)

값 타입은 메모리에 저장될 때 크기가 컴파일 시점에 반드시 고정되어야 한다.

⭐️ 왜 컴파일 시점에 고정되어야 할까?

컴파일러는 코드를 기계어로 변환할 때, 각 변수가 메모리의 어느 위치에 저장될지 미리 계산해야 한다. 크기를 알아야 "이 변수는 100번지, 다음 변수는 108번지..." 처럼 주소를 순서대로 배정할 수 있기 때문이다.

문제 발생: 열거형이 자기 자신을 포함한다면?

enum ArithmeticExpression {
    case number(Int)
    case addition(ArithmeticExpression, ArithmeticExpression)
}

크기 계산이 불가능하다!

ArithmeticExpression의 크기를 알고 싶다 → addition 안에 ArithmeticExpression이 2개 있다 → 그 안에 또 ArithmeticExpression이 있다 → 또 그 안에... 안에 .. 안에 .. 안에 .. 무한반복 발생

Swift는 데이터 크기를 알 수 없기 때문에 컴파일 에러가 발생한다.

해결책: indirect 키워드

indirect를 붙이면 해당 케이스를 직접 저장하지 않고, 힙(Heap) 메모리에 저장한 뒤 그 주소(포인터)만 갖는다.

⭐️ 틈새 CS 지식
여기선, 스택 메모리와 힙 메모리의 개념에 대해 알아야 한다.

Stack
크기가 컴파일 시점에 고정된 데이터를 저장한다.
함수가 실행될 때 생성되고, 끝나면 자동으로 사라진다.
매우 빠르다!

Heap
크기가 런타임에 동적으로 결정되는 데이터를 저장한다.
직접 할당/해제를 관리한다. → Swift는 ARC가 자동으로 관리한다.
스택보단 느리다.

→ 핵심 기준: 데이터의 크기를 미리 알 수 있는지 없는지!

⭐️ 틈새 CS 지식 - Pointer란?
포인터: 메모리 주소를 저장하는 변수

현대 64비트 컴퓨터에서 메모리 주소를 표현하고 싶다.
→ 64bits = 8bytes 이므로 딱 8바이트가 필요하다.

즉, 포인터가 가르키는 대상이 Int, String, Enum이든 주소 값 자체의 크기는 항상 8 바이트로 동일하다.

결론!

따라서 indirect 키워드가 존재하면, 포인터만 저장

→ Heap 메모리에 실제 데이터(ArithmeticExpression)를 저장

→ 각 메모리에 적절한 데이터가 들어갔기 때문에, 컴파일 성공!

의미없는 자료까지 첨부..

(indirect enum을 언젠간 실무에 사용할 수 있겠지?)

Enum 열거형 기초 개념을 다시 새겨보자 - 1일1챌린지

Guryss — Wed, 1 Apr 2026 15:31:36 +0900

Enumeration
Model custom types that define a list of possible values.
관련 값들을 정의하는 커스텀 타입

관련된 값들의 그룹에 대한 공통 타입을 정의한다.
코드 내에서 type-safe한 방식으로 값들을 사용할 수 있다.

Enumeration Syntax (열거형 문법)

enum 키워드로 시작한다. ← 당연한 말 ; 이지만 그래도 !
전체 정의를 중괄호 쌍 안에 배치한다. ← 당연한 말 ; 이지만 그래도 !

enum CompassPoint {
	case north
	case south
	case east
	case west
}

열거형 내 정의된 값들 → enumeration case
case 키워드를 통해 값을 추가할 수 있다.
case 순서에 따라 기본적으로 정수가 설정되지 않는다.
- north: 0, south: 1, east: 2, west: 3 ← X

enum AttractivePoint {
	case worldView, character, releationship, vibe, material, writingSkill
}

여러 케이스를 쉼표로 구분하여 한 줄로 표현할 수도 있다.

Enum 변수명에 대해 ..

대문자로 시작한다. (CompassPoint, AttractivePoint, ..)
단수형으로 지정한다.
자명하게 이해할 수 있도록 한다.

타입 추론 방식

처음 선언할 때에는 타입을 명시해야 한다.

var myAttractivePoint = AttractivePoint.character

한번 선언되고 난 후에는 이미 Swift가 해당 변수의 타입을 알고 있으므로,
AttractivePoint를 생략하고 .케이스명 으로만 나타내도 된다.

myAttractivePoint = .writingSkill // dot syntax!

Switch문 + Enum cases

Switch문을 활용하여 열거형의 각 케이스를 매칭할 수 있다.

myAttractivePoint = .writingSkill

switch myAttractivePoint {
	case .worldview:     print("세계관")
	case .material:      print("소재")
  case .writingSkill:  print("필력")
  case .character:     print("캐릭터")
  case .relationship:  print("관계")
  case .vibe:          print("분위기")
  }
}

모든 케이스를 처리해야 한다.
- 모든 케이스를 처리하기 어려울 때 → default를 사용한다.
- 명시적으로 처리하지 않은 나머지 모든 케이스를 default가 포함한다.

myAttractivePoint = .writingSkill

switch myAttractivePoint {
	case .worldview: print("세계관")
	case .material:  print("소재")
	default:         print("해당하지 않음")

Enum을 배열처럼 다루기

열거형 내 케이스를 모두 꺼내서 사용하고 싶을 때 → CaseIterable 을 붙여준다.

해당 프로토콜 사용 시, Swift에서 자동으로 allCases 라는 프로퍼티를 제공한다.

protoocl CaseIterable 

enum AttractivePoint: CaseIterable {
	case worldView, character, releationship, vibe, material, writingSkill
}

let totalCount = AttractivePoint.allCases.count
print(totalCount) // 6

for point in AttractivePoint.allCases {
	print(point)
}

for-in 루프를 활용해 모든 케이스를 순회할 수 있다.

연관 값 - Associated Values

열거형의 케이스에 추가 정보를 함께 저장할 수 있는 기능

ex) 바코드 시스템을 만들어보자.

UPC: 숫자 4개로 구성 (8, 342, 123412, 54)
QR코드: 문자열로 구성 (”dfjkdlfskadfjslf”)

enum Barcode {
	case upc(Int, Int, Int, Int)
	case qrcode(String)
}

연관값 저장하기

var productBarcode = Barcode.upc(8, 342, 123412, 54)

// 나중에 값을 변경할 수도 있다.
productBarcode = .qrcode("dfjkdlfskadfjslf")

Switch문으로 연관값 꺼내기

switch productBarcode {
case .upc(let numberSystem, let manufacturer, let product, let check):
    print("UPC: \\(numberSystem), \\(manufacturer), \\(product), \\(check).")
case .qrCode(let productCode):
    print("QR code: \\(productCode).")
}

// 앞에 case 뒤에 let을 붙여 한번만 써도 됨.
switch productBarcode {
case let .upc(numberSystem, manufacturer, product, check):
    print("UPC: \\(numberSystem), \\(manufacturer), \\(product), \\(check).")
case let .qrCode(productCode):
    print("QR code: \\(productCode).")
}

특정 케이스 하나만 확인하고 싶을 때: if case

if case .qrCode(let productCode) = productBarcode {
    print("QR code: \\(productCode).")
}

// productBarcode가 qrCode 케이스이면, 연관값을 productCode로 꺼내서 담고 블록을 실행해줘.

// 일반 if문: 조건이 true/false
if productBarcode == .qrCode { }

// if case: 패턴이 일치하는지 + 연관 값까지 동시에 꺼냄
if case .qrCode(let productCode) = productBarcode { }

원시 값 - Raw Value

연관 값과 달리, 열거형 케이스에 따라 미리 기본값을 설정하는 것

enum ReadStatus: String {
  case watching = "WATCHING"
  case watched = "WATCHED"
  case quit = "QUIT"
}

let status = ReadStatus.watching.rawValue
// WATCHING

rawValue를 사용하여 원시값을 꺼낼 수 있다.

암묵적 원시값 할당

일일히 값을 할당하지 않아도, Swift가 자동으로 할당해줄 수도 있다.

Int: 이전 케이스에 +1씩 자동 증가

enum Planet: Int {
    case mercury = 1, venus, earth, mars ...
    // mercury=1, venus=2, earth=3 ...
}

String: 케이스 이름 자체가 원시 값이 된다.

enum CompassPoint: String {
    case north, south, east, west
    // north="north", south="south" ...
}

원시값으로 케이스 찾기

원시값이 있는 열거형은 자동으로 rawValue를 받아서 케이스를 반환하는 이니셜라이저를 제공한다.
옵셔널을 반환한다. → 해당하는 케이스가 없을 수도 있으므로
- 존재하지 않는 원시 값을 넣으면 nil을 반환하기 때문에, if let으로 안전하게 처리하는 것이 중요하다.

let status = ReadStatus(rawValue: "WATCHING")
// ReadStatus.watching 옵셔널 타입

let find = "INTEREST"
if let someStatus = ReadStatus(rawValue: find) {
	// 해당하는 케이스가 존재할 때
	switch someStatus {
		case .watching: print("watching")
		default: print("not watching")
	}
else {
	// 존재하지 않을 때
	print("case not found")
}

재귀 열거형 - Recursive Enumeration

케이스의 연관 값으로 자기 자신을 다시 사용하는 열거형

indirect 키워드를 붙여준다.
- 컴파일러에게 필요한 간접 레이어를 추가하도록 지시한다.

enum ArithmeticExpression {
    case number(Int)
    indirect case addition(ArithmeticExpression, ArithmeticExpression)
    indirect case multiplication(ArithmeticExpression, ArithmeticExpression)
}

// 연관값을 가지는 모든 열거형 케이스에 대해 간접 참조를 활성화 하고 싶을 때
// enum 앞에 indirect 키워드를 붙인다. 
indirect enum ArithmeticExpression {
    case number(Int)
    case addition(ArithmeticExpression, ArithmeticExpression)
    case multiplication(ArithmeticExpression, ArithmeticExpression)
}

func evaluate(_ expression: ArithmeticExpression) -> Int {
    switch expression {
    case let .number(value):
        return value
    case let .addition(left, right):
        return evaluate(left) + evaluate(right)
    case let .multiplication(left, right):
        return evaluate(left) * evaluate(right)
    }
}

print(evaluate(product))
// "18" 출력

재귀열거형은 처음 알게 된 개념이었다..!
이 개념을 공부하면서 CS 지식도 다시금 복습하게 되었다..

다음 장에 계속 ..

Struct vs Class 를 완벽하게 새겨보기 - 1일1챌린지

Guryss — Mon, 30 Mar 2026 15:26:09 +0900

공부 계기

이번 웹소소 iOS 오프라인 회의에서, 윤학 오빠가 기존의 Service, Repository 타입을 class에서 struct로 변경하자는 의견을 제시했다. 그 이유를 물어보니, Swift 공식 문서에서는 class를 반드시 사용해야 할 명확한 이유가 없다면 struct 사용을 권장한다고 한다.

이 계기로 자연스럽게 class와 struct의 차이에 대해 이야기를 나누게 되었는데, 정작 나는 그 내용이 거의 기억나지 않는다는 사실을 깨달았다… 최근에는 AI 에이전트, 면접 준비, 자소서 작성 등에 집중하면서 정작 중요한 개발 기초 개념 학습을 소홀히 하고 있었다는 것을 느꼈다.

그래서 지금부터는 다시 마음을 다잡고, 하루에 하나씩 개념을 차근차근 정리하며 쌓아가려고 한다.

왜 Swift는 struct를 기본으로 권장할까?

레퍼런스1: Swift.org

Structures and classes are general-purpose, flexible constructs that become the building blocks of your program’s code.

데이터와 기능을 묶어서 하나의 틀로 만들 수 있다.
같은 문법을 활용하여 properties와 methods를 정의할 수 있다.

An instance of a class is traditionally known as an object. However, Swift structures and classes are much closer in functionality than in other languages, and much of this chapter describes functionality that applies to instances of either a class or a structure type. Because of this, the more general term instance is used.

전통적으로 class를 객체(object)라고 부른다. 즉, Java나 Python과 같은 다른 언어에선 class로 찍어낸 것만을 객체라고 부른다.
하지만, Swift에서는 class와 struct의 기능이 상당히 유사한 점이 많다. 위처럼, struct도 프로퍼티와 메소드를 가질 수 있기도 하기 때문이다.
따라서, Swift에서는 object라는 용어 대신에 instance라는 단어를 사용한다. 즉, struct든 class든 모두 instance 로 활용하여 동등하게 취급한다는 것이다.

Struct와 Class의 공통점

프로퍼티: 값을 저장한다.
메서드: 기능을 제공한다.
subscripts:
이니셜라이저: 초기값을 설정할 수 있다.
익스텐션으로 확장할 수 있다.
프로토콜을 채택할 수 있다.

Class만 가능한 것

Inheritance(상속): 다른 클래스를 특성을 상속받을 수 있다.
Type Casting(타입캐스팅): 실행 중 인스턴스의 타입을 확인/변환할 수 있다.
Deinitializers: 이니셜라이저가 사라질 때 free up할 수 있다. → 자원을 해제할 수 있다.
Reference Counting(참조카운팅): 하나의 인스턴스를 여러 곳에서 참조할 수 있다.

The additional capabilities that classes support come at the cost of increased complexity. As a general guideline, prefer structures because they’re easier to reason about, and use classes when they’re appropriate or necessary. In practice, this means most of the custom types you define will be structures and enumerations. For a more detailed comparison, see Choosing Between Structures and Classes.

class: 기능이 많은 대신에 복잡도가 올라간다.
따라서, 기본적으로는 struct을 사용하자. → struct이 더 이해하기 쉽기 때문.
class는 적절하거나 필요할 때 사용하자.

→ 즉, 너가 정의할 커스텀 타입들의 대부분은 struct or enumerations(열거형)이 될 것이다.

Identity Operators (식별 연산자)

클래스는 참조 타입이기 때문에, 여러 변수가 같은 하나의 인스턴스를 가르킬 수 있다. 따라서, 이 둘이 진짜 같은건지 확인하는 연산자가 필요하다.

=== : 같은 인스턴스를 공유하는가 → 주소가 같은가
== : 값이 동일한가

class Person {
    var name: String
    init(_ name: String) { self.name = name }
}

let a = Person("철수")
let b = a              // 같은 인스턴스를 참조
let c = Person("철수") // 값은 같지만 다른 인스턴스

a === b  // true  (같은 인스턴스)
a === c  // false (다른 인스턴스, 값만 같음)

구조체, 열거형 등은 항상 값이 복사되기 때문에, === 연산자를 사용할 수 없다.

레퍼런스2: Apple developer 공식 문서

Choosing Between Structures and Classes | Apple Developer Documentation

Choose Structures by Default

Swift의 Struct: 다른 언어에서 클래스만 할 수 있었던 것을 대부분 할 수 있다.
- stored properties
- computed properties
- method 정의
- extension을 통한 확장 기능
- protocol 채택

구조체를 사용하면 애플리케이션 전체 상태를 고려하지 않고도 코드의 일부를 더 쉽게 이해할 수 있다. 구조체는 값 타입(value type)이기 때문에, 구조체 내부에서 발생한 변경은 의도적으로 전달하지 않는 한 앱의 다른 부분에 영향을 주지 않는다. 그 결과, 특정 코드를 볼 때 해당 영역의 변경이 관련 없는 다른 함수에 의해 암묵적으로 발생하는 것이 아닌, 명시적으로 이루어진 것임을 더 확신할 수 있다.

Swift의 Int, String, Array, Dictionary 모두 Struct이다.

struct Feed {
    let id: Int
    var content: String
}

var a = Feed(id: 1, content: "面白いですね")
var b = a
b.content = "まずいです"

print(a.content) //面白いですね
print(b.content) //まずいです

Use Classes When You Need Objective-C Interoperability

Objective-C 프레임워크를 써야 할 때는 어쩔 수 없이 class를 써야한다. Objective-C는 struct를 모르기 때문이다.
(옵젝C를 쓸 일은 거의 없으므로 패스)

Use Classes When You Need to Control Identity(동일성)

Class: 참조 타입!

class Animal {
    var eatBreakfast: Bool = true
}

var cat = Animal()
var dog = cat

dog.eatBreakfast = false

print(cat.eatBreakfast) //false
print(dog.eatBreakfast) //false

즉, cat과 dog는 같은 객체를 가르키고 있다.
따라서, 앱 어디에서 프로퍼티 값을 변경하면 동일하게 반영된다.

앱 어디에서 바꾸든 전부 반영된다.
- ex) 네트워크 연결, 파일 핸들링, 블루투스 연결 등 .. → 앱 전체가 하나의 상태를 공유할 때 사용
- 여러 곳에서 마구 공유하면 버그가 쉽게 발생할 수 있으니 주의하자.

Use Structures When You Don’t Control Identity

제어할 수 없는 고유한 identity를 가진 엔티티를 모델링할 때에는 struct을 사용하자.

public struct UserRegisteredNovelStatesResponse: Decodable {
    public let interestNovelCount: Int
    public let watchingNovelCount: Int
    public let watchedNovelCount: Int
    public let quitNovelCount: Int
}

let response = try await service.getUserRegisteredNovelStats(userID: myID)
return NovelMapper.decodeUserRegisteredNovelStats(from: response)

로컬에서 해당 struct값을 아무리 변경해도 서버 DB값에는 전혀 영향을 주지 않는다. → struct은 복사본이기 때문이다!

Use Structures and Protocols to Model Inheritance and Share Behavior

⭐️ “상속 구조를 만들고 싶으면 class 말고 protocol부터 고민해라” ⭐️

Struct, Class 모두 상속의 개념을 지원한다. 다만 방식에 차이가 있다.

Class
- Class 상속 가능
Struct
- Class 상속 불가능 -> 대신 protocol을 활용해 상속을 지원할 수 있다.

→ Class 상속보다는 Protocol 상속을 우선적으로 설계하는 것이 좋다.

class Vehicle {
    func start() {}
}

class Car: Vehicle {
    func addOil() {}
}

Struct, Enum에 해당 클래스를 상속시킬 시, 에러가 발생한다.
즉, Class 상속은 Class끼리만 가능하다.
구조가 점점 복잡해질 수록 상속 트리가 꼬일 가능성이 크다.

protocol Vehicle {
    func start()
}

class Car: Vehicle {
    func start() {}
    func addOil() {}
}

struct Bicycle: Vehicle {
    func start() {}
}

enum SportsCar: Vehicle {
    func start() {}
}

protocol로 상속을 할 경우
- class, struct, enum 모두 상속할 수 있다.
- 더 유연하고 가볍다
- 테스트 및 유지보수가 쉬워진다.

[BOJ/C++] 백준 32762. 더치페이

Guryss — Wed, 1 Oct 2025 11:39:09 +0900

1. 문제 이해

https://www.acmicpc.net/problem/32762

N명의 입장 및 퇴장 시간이 주어진다.

M개의 음식 정보가 주어지는데, 음식의 주문 시각과 가격을 알 수 있다.

결과값은 1인당 평균 지불 금액 이다.

2. 풀이 방법

처음에는 모든 사람들의 입장 및 퇴장 시간을 저장해야 한다고 생각했다.

이후에 음식 주문 시간에 있는 사람들의 수를 가져와서, (전체 가격) % (주문 시간의 사람 수의 합) 으로 결과를 내면 된다고 생각했다.

하지만,, 해당 방식은 브루트포스 이고, 입장 및 퇴장 시간의 범위는 1 ~ 2^31-1 이다.

이거 다 계산하다가는 CPU가 나에게 욕을 해버릴지도 모른다. -> 즉, 이 방식은 패스!

다음으로 생각해본 것은 제시된 음식의 주문 시간의 경우만 생각하는 것이었다.

예를 들어, 1 시간에 1000원 / 2시간에 4000원 음식이 나왔으면 1,2시간의 사람 수만 고려하는 것이다.

근데 이렇게 하면 입력값을 t, p가 먼저 입력되어야 하는데 그렇지 않았으므로 .. 이것또한 완벽한 해결책이 될 수 없다고 판단.

하지만 이 문제는 브론즈다. 문제 이해만 하면 코드는 엄청 간단할 것 같다..

(1인당 평균 지불 금액) = (각 시간 당 평균 지불 금액의 합) / N(전체 인원 수)

= { (음식 가격) * (해당 시간의 인원 수) / (해당 시간의 인원 수) } 의 합 / N

= (음식 가격의 합) / N

이라는 풀이를 할 수 있었다...

결국, 최종 도출해야하는 답안의 의미를 생각하는!!

(vector 쓸 필요도 없었던 .. ㅠㅠ)

3. 코드

#include <stdio.h>

using namespace std;

int main() {
    int N, M;
    scanf("%d %d", &N, &M);

    for (int i = 0; i < N; i ++) {
        int start, end;
        scanf("%d %d", &start, &end);
    }

    double result = 0;
    int total = 0;

    for(int i = 0; i < M; i ++) {
        int t, p;
        scanf("%d %d", &t, &p);
        result += p;
    }

    printf("%0.5f", result / N);

    return 0;
}

4. 느낀 점

문제를 풀기 전에 먼저 답안의 의미를 생각해보자!

의미를 생각하면 생각보다 쉽게 답이 찾아질지도?

난이도가 낮았던 문제를 꽤 오래 헤매서... 기억하고자 글을 남겨본다.

[UIKit] jpegData(compressionQuality: )에 대한 고찰과 트러블슈팅 ☄️

Guryss — Thu, 10 Jul 2025 17:24:01 +0900

웹소소 사진소소 1차 QA에서 발견했던 버그가 있었다.

(참고로 사진소소는 웹소소 사일로 중 하나로 난 피드 내 이미지 첨부 기능을 구현해야했다.... 흑흑 어려워 )

피드를 수정할 때마다 이미지를 수정하지 않았는데도 이미지의 화질이 계속 저하되는 상황이 발생했다.

해당 버그를 수정하기 위해 UIKit에서의 이미지 압축 방식에 대해 처음부터 공부해보기로 결정했다!

우선, 버그부터 해결해보자

서버에 보내야 하는 이미지의 최대 사이즈는 0.25MB였다.

근데 원본 이미지 사이즈가 이미 0.25MB보다 작으면 압축 과정은 필요없이 서버에 전송하면 되는데 ..

내가 이 로직을 생각 못했다 흑흑

if let originalData = image.jpegData(compressionQuality: 1.0) {
    let originalSize = originalData.count
    print("이미지 \(index) 원본 사이즈: \(formatBytesToMB(originalSize))")
    
    // 원본 사이즈가 최대 사이즈보다 작을 때 -> 압축 생략
    if originalSize <= maxImageSize {
        return originalData
    }
}

따라서 해당 로직을 추가해서 원본 사이즈가 maxImageSize 보다 작거나 같다면 바로 원본 이미지를 뱉고 함수를 끝낼 수 있도록 수정했다! 따라서 난 이걸로 끝나는 간단한 버그일 줄 알았으나 ..

왜 압축했는데 사이즈가 더 커지지?

이미지 1 원본 사이즈: 0.71MB
이미지 2 원본 사이즈: 0.77MB
이미지 4 원본 사이즈: 0.76MB
이미지 3 원본 사이즈: 0.80MB
이미지 0 원본 사이즈: 0.73MB
 ️ 이미지 1 초기 해상도 0.90 적용 → 크기: 1.21MB
 ️ 이미지 2 초기 해상도 0.90 적용 → 크기: 1.21MB
 ️ 이미지 4 초기 해상도 0.90 적용 → 크기: 1.27MB
 ️ 이미지 0 초기 해상도 0.90 적용 → 크기: 1.38MB
 ️ 이미지 3 초기 해상도 0.90 적용 → 크기: 1.34MB

위 코드를 추가하고 테스트를 돌려봤다.

완전 당황스러웠다. 원본 사이즈는 저렇게 나오는데, 해상도 즉 scale = 0.9로 적용했는데 오히려 사이즈가 커져있었다.

나는 이 상황에 대한 원인을 알기 위해 지피티에게 물어봤다.

1.0은 거의 무손실 저장, 즉 최소한의 압축만 적용한 것.
JPEG의 강점은 0.6 ~ 0.9 사이에서 효율적인 압축인데, 1.0은 내부적으로 많은 디테일을 보존하려고 해서 오히려 용량이 커질 수 있습니다.
특히 리사이징으로 해상도는 줄었지만 픽셀 하나하나의 품질은 높게 유지됨 → 압축 효율 낮아짐

image.jpegData(compressionQuality: 1.0)으로 만든 데이터보다 실제 원본은 이미 0.7이나 0.8 정도의 압축 상태였을 수도 있음. 따라서 1.0으로 다시 저장하면 → 압축률이 떨어지고 용량이 증가하는 것.

다양한 원인이 있다고 했다.

1. 초기 해상도를 0.9, compressionQuality: 1.0으로 했을 때 용량이 약 1.5배 정도 늘어났음을 알 수 있다.

해상도를 낮춤으로서, 픽셀 수가 줄어들고, 그에 따른 엣지, 패턴, 잡음이 생겨나면서 JPEG가 저장해야 하는 새로운 값들이 늘어나게 되었다. 근데 품질은 1.0으로 거의 손실 없이 이미지를 압축하기 떄문에 용량이 그만큼 늘어날 수 밖에 없던 것이다.

2. 우리가 사용하는 UIImage 객체는 이미지의 픽셀만 담고 있는 메모리 객체이다. 예를 들어 해당 객체가 압축률 0.7로 저장된 JPEG라고 한다면, 해당 객체를 다시 compressionQuality: 1.0 로 압축해 저장하게 된다면? 이에 따라 용량은 다시 커질 수 있다.

어느정도 이해가 되긴 했는데 각 용어에 대한 정의가 명확하지 않았던 상태였다.

해상도? 품질?

이미지 압축에서 자주 등장하는 해상도와 품질에 대해 다시 짚어보고 가고자 한다.

해상도(scale)는 이미지의 전체 세로 * 가로 크기를 얼만큼 할지를 정하는 요소이다.
즉 해상도를 줄인다는 것은 이미지를 구성하는 전체 픽셀 수를 감소한다는 의미인 것!

픽셀 수라는 물리적 값을 줄여버리기 때문에 그만큼 용량도 확 줄어들 수 있다.

그러나 너무 많이 줄여버리면 이미지가 뿌옇게 보이고 선명하지 않게 보여서 .. 사용자 경험을 매우 해칠 수 있다.

품질(quality)은 이미지의 픽셀 정보를 얼마나 유지할지에 대한 요소이다.

품질을 줄인다는 것은 이미지 내 디테일이 손실될 수 있다는 것. 이때 당연하게도 픽셀 수는 유지된다.

품질 또한 많이 줄여버리면 눈에 띄는 디테일한 시각적 표현이 저하될 수 있다.

위 개념에 대해 확실히 이해하게 되고 나서 ..

서버에서 정해둔 maxImageSize = 0.25MB보다 조금만 큰 이미지의 경우, 해상도를 낮추는 방식이 오히려 비효율적일 수 있다는 생각이 들었다. 원본 크기가 5MB 이상인 이미지라면 해상도를 조금만 줄여도 용량 감소 효과가 크기 때문에 효과적이지만,

상대적으로 용량이 작은 이미지에 대해 무리하게 해상도를 낮추면 품질만 떨어지고 용량은 크게 줄지 않는, 오히려 악영향을 줄 수 있다는 점이 알게 되었다. 오호

결론적으로 어떻게 했냐면 ..

이미지 사이즈가 1MB 이하일 때 품질(quality)를 낮춰 픽셀 수 즉, 해상도는 최대한 유지될 수 있도록 했다.
반면에 사이즈가 1MB보다 클 때는 해상도를 먼저 줄인 뒤 품질을 조금씩 줄여나갈 수 있도록 했다.

// 원본이 1MB 이하 → quality만 낮춤
if originalSize <= oneMB {
    while (data == nil || data!.count > maxImageSize) && quality > 0.1 {
        data = image.jpegData(compressionQuality: quality)
        print("이미지 \(index) 크기: \(formatBytesToMB(data?.count ?? 0))")
        quality -= 0.1
    }
} else {
    // 원본이 1MB 초과 → scale 먼저 줄이고 필요 시 quality도 함께 감소
    data = image.resizedImage(to: scale)?.jpegData(compressionQuality: quality)
    print("이미지 \(index)크기: \(formatBytesToMB(data?.count ?? 0))")

    while (data == nil || data!.count > maxImageSize) && quality > 0.01 && scale > 0.1 {
        if quality > 0.2 {
            quality -= 0.1
        } else {
            scale -= 0.1
            if let resized = image.resizedImage(to: scale) {
                data = resized.jpegData(compressionQuality: quality)
            }
            continue
        }
        data = image.resizedImage(to: scale)?.jpegData(compressionQuality: quality)
        print("↘️ 해상도: \(String(format: "%.2f", scale)), 품질: \(String(format: "%.2f", quality)) → 크기: \(formatBytesToMB(data?.count ?? 0))")
    }
}

이렇게 하니 확실히 피드를 반복해서 수정해도 이미지의 화질이 저하되는 현상이 상당히 줄어들었단 걸 알 수 있었다.

사실 위 방법이 좋은 방법인지는 .. 아직 확실하진 않다. ㅠㅠ

그래도 기본적인 이미지 압축 개념들에 대해 다시 공부하고 내가 판단하기에 효율적이라고 생각한 방법으로 리팩토링 했으니 .. 의미있었던 과정이라고 생각한다!

아, 하나 또 알게 된 건 내가 처음 피드를 POST할 때, 0.25MB보다 작게 압축해서 보내도 피드 수정할 때 다시 받는 이미지 사이즈는 0.25MB보다 커진다는 걸 알 수 있었다. 원인은 서버쌤들에게 물어봐야할듯 .. 그래서 피드를 수정하고 이미지를 다시 보낼 때 압축 검증 절차가 필요해짐 ..

이미지를 언어별로 다르게 적용시키고 싶다면? Image Localizing ✨

Guryss — Mon, 7 Jul 2025 16:57:47 +0900

사이드 프로젝트를 진행하다가 이미지를 한국 / 영어 언어에 따라 다르게 적용해야 하는 상황이 발생했다.

(사실은 튜토리얼 뷰를 따로 만들어서 뷰의 크기에 맞게 조정되도록 해야하는데 .. 이건 백로그로!
우선 릴리즈 기한을 맞추기 위해 이미지 통째로 넣어두기로 했다. )

이 상황을 마주하고.. 음 텍스트는 로컬라이징을 할 수 있는데 이미지는 어떻게 하지? 란 생각이 들었다.

해결방법

생각보다 간단했다.

로컬라이징 하고 싶은 이미지를 선택하고 우측 네비게이션의 Image Set을 클릭하면 위 사진처럼 Localization이라는 탭이 보일 것이다.

이를 클릭하면

위 버튼들이 생길 것이고, 로컬라이징 하고 싶은 언어들을 선택해주면 된다.

나는 영어와 한글 버전 두가지의 이미지를 추가할 것이기 때문에 두 버튼 모두 선택했다.

그러면 이미지를 추가할 수 있는 창이 언어별로 구분되어 생성된다.

따라서 Korean 쪽에는 한글로 된 튜토리얼 이미지를 추가하고, English에는 영어로 된 튜토리얼 이미지를 넣어주면 된다.

그렇다면, 앱의 언어 상태에 따라 튜토리얼 이미지가 다르게 보여진다!! 신기하다

참고로, 언어가 설정되어있지 않은 부분(왼쪽 상단)에는 영문 버전의 이미지를 추가해두었다.

결과는 이렇게!

추가적으로 Content.json 파일의 변경점을 살펴보니,

locale이라는 key가 새로 생기면서 파일들을 구분해주고 있었다. 간단하면서 신기하군!

[WWDC25] 스스챌 Distinguished Winner로서 간 WWDC25 현장 후기 (3)

Guryss — Tue, 24 Jun 2025 00:54:44 +0900

WWDC25 3일차 마지막날 (6/ 10)

공식 행사 마지막날이다. 이제 막 시차적응 했다고 생각했는데.. 벌써 가야한다니 너무 아쉬웠지만 그래도 알차게 끝내자는 생각으로! 마지막날을 힘차게 시작해봤다.

오전 9시에 집합해서 인피니트 루프에 가서 어제 발표된 Apple의 Liquid Glass와 관련된 디자인 세션을 들었다.

Apple의 엔지니어, HIG 디자이너들이 나와서 직접 코드로 구현까지 해주며 자세한 방법에 대해 알려주었다.

아쉽게도 해당 디자인 세션에선 사진 촬영이 불가해서 내용에 대한 메모만 남겨두었다.

하나 진짜 인상 깊었던 점은, 행사 시작부터 끝까지 수화통역사분들이 열심히 수화로 행사를 설명해주셨다. 애플의 섬세함을 다시 한번 느낄 수 있었다.

Liquid glass
Specular highlights
Reflection
Lensing

Regular liquid glass
Clear liquid glass

Scroll edge effect: 스크롤될 때 버튼 뒤에 컨텐츠가 비쳐보이게 함

<Components>
툴바
어두움 밝음 컬러에 따라 툴바 내 아이콘 컬러가 자동으로 바뀜 ㄷㄷ
아이폰 하드웨어의 둥근 모서리값에 따라 같은 값의 곡선값으로 가져왔다
하단에 있는 툴바가 상단 툴바보다 조금 더 크다

44pt 48pt
버튼에 컬러가 입혀져도 동일하게 렌징 효과를 준다
툴바 상단의 많은 아이템들을 세컨더리 엑션으로 빼둠

탭바
검색버튼이 탭바로 내려옴
탭바 위에 음악 재생 바가 있게 하는 것 처럼 항상 탭바가 보이게 한다

시트
툴바 버튼과 동일하게 시트 내 컴포넌트 설정
Detent: 시트 사이즈를 조절할 수 있는 컨포넌트
X 버튼도 클릭하면 거기서 팝업이 뜨는 형태로 컨텐츠가 가려지지 않게 함

Icons
앱 아이콘 전면 개편 라이트/다크/틴트/컬러 모드
Icon Composer
아이콘 내 블러 모드나 다양한 모드의 상황을 보여준다
앱 아이콘의 다양한 os에서의 프리뷰를 보여준다
레이어링을 강조함
갤러리 아이콘도 애플 아이콘 규격에 맞춰 디자인 됨 ㄷㄷㄷㄷㄷㄷ 변태같아
아이콘 컴포저 시연도 해줌 어떻게 만드는지 대박이당

탭뷰에서 스크롤할 때 탭바를 미니마이즈 하는 프로퍼티
Tabviewbottomaccessory 라는 프로퍼티 안에 뷰를 넣으면 탭바 위에 컴포넌트가 뜸
탭뷰 최소화됐을 때 inline 시키는 방법도 있음
ToolbarSpacer(.fixed) 툴바간의 간격 유지

searchable 모디파이어 하나로 뷰 안에 서치 컴포넌트 생성할 수 있음
맥은 오른쪽 상단 아이폰은 하단

툴바를 만드는 것에 대한 코드 시연까지 해줌 네비게이션을 통해 뷰를 넘어가명서 툴바가 자얀스럽게 추가되는 애니메이션을 보야주면서 되게 자부심 느꺄보이고 재밌어보인다 변태같음......ㅡㄱ으끙

버튼에 글라스 프로퍼티
슬라이더에 스텝 마크 추가할 수 있다 뉴트럴벨류라고 스타팅포인트를 미리 설정해둘수있다

GlassEffectContainer 이거 개쩐다 ㄷㄷ

애플의 디자인을 매우 좋아하는 나로서는 이 디자인 세션이 너~무 재미있었다.

얼른 XCode 업데이트 해서 반영된 기능들을 얼른 구현해보고 실기기로도 반영해보고 싶었다!!

직접 구현해보고 블로그에도 기록해볼 예정이다 ㅎㅎ

디자인 세션이 끝난 이후, 애플 파크에서 맛있는 점심을 먹었다.

저 라구 파스타 정말 맛있어서 한번 더 리필해서 먹었다 오예

Apple Accessability Session

점심시간 이후엔 애플의 접근성 팀에 계신 Gus와 애플이 제공하는 접근성 기능들에 대해 배우고, 질의응답 시간을 가졌다.

시작부터 접근성을 고려하라
베타테스트를 할 사람을 찾아라
너의 업데이트들을 기억하라

Voice over, voice control 지원

Human interface guidelines - accessibility
Wwdc25에도 접근성 관련 영상 4개 업로드되어있음

접근성을 고려한 앱을 어떻게 시작할 수 있을까?
일단 작은 것부터 만들어보고 테스트를 통해 계속 발전해나가라

Liquid glass와 접근성
디자인팀과 많은 대화를 나눴다. 개발과정에서도 피드백이 많이 오갔다.

앱이 완성되었는지를 어떻게 파악하여 진행할 수 있을까?
테스트플라이트를 통해 그룹 테스팅 후 피드백을 받는다

이후에는 각자 팀을 이뤄 팀과 관련된 분야에 대해 이야기 나눠보는 시간을 가졌다.

나는 때마침 접근성 분야 팀에 배정 받아 현재 접근성 팀에 계신 애플 엔지니어 두 분과 시간을 가졌다.

아쉬웠던 점은, 내 영어 실력이 부족했어서 그런가..? 질문할 내용이 바로 생각이 나지 않아 질문을 하지 못했다. 행사 내용을 미리 알았더라면 미리 질문거리를 준비해 갔을 것 같은데 이 점이 좀 아쉬웠지만! 그래도 접근성과 관련된 인사이트가 많이 커질 수 있었던 경험이었다.

마지막날이 마무리되어간다

애플 TMI

Apple은 사과나무를 키운다 .. (진심변태같음)

캠퍼스를 걸어다니다보면 상당히 자연친화적인 느낌인데 그 많은 나무들 중 많은 비중을 사과나무가 차지하고 있다.

듣기론 사과가 익으면 사과를 기부한다고도 들었는데 이건 확실치 않다 ㅋㅋㅎㅎ

주어진 행사들이 마무리 되고 3일간의 distinguished winner들 사진을 보여주는 시간이 있었다.

3일 동안 우리를 찍어주신 포토그래퍼분과 많이 대화를 나눠서 그런가? 내 사진이 진짜 많았다.

위너들과 직원분들이 너 사진 진짜 많아~ 이런 말을 엄청 많이 들었을 정도다 ㅋㅋㅋ

작년 아카데미에서 항상 챌린지가 끝나고 하는 회고처럼 우리도 3일간의 회고를 진행했다.

1. 어떤 부분에서 영감을 받았는가?
2. 이번 행사를 통해 가져가고 싶은 부분은 무엇인가?
3.너의 미래 워크에서 가장 적용해보고 싶은 툴, 프레임워크, 아이디어
4.집에 돌아가면 무엇을 하고 싶나?

그리고 3일동안 WWDR 직원분들이 입고 계셨던 Swift 티셔츠와 뱃지를 선물로 받게 되었다.

iOS 개발자라면 환장할 수 밖에 없는 굿즈였어서 받았을 때 너무 좋았다 ✌️

위너들을 위한 공식 이벤트는 이로써 끝이 났고, 마지막엔 Apple 관계자분들과 함께 하는 미팅 시간이 있었다.

가볍게 음식을 먹으며 네트워킹할 수 있는 소중한 시간이었다. 진짜 여기 와서 네트워킹 능력 하나는 야무지게 배우고 간 것 같다. ㅋㅋㅋ

처음에 나는 3월부터 배우고 있던 일본어를 사용해보고 싶어서 위너였던 다이키와 일본어로 대화를 나눴다. 약 4개월 간 한국인들과 일본어로 소통하는 경험만 갖고 있던 나로선, 일본인과 일본어로 대화할 수 있었던 경험은 너무나 소중했었다. 아직 회화는 더 공부해야겠단 생각이 들긴 했지만! 너무 재밌었다. 앞으로도 일본어를 더욱 열심히 공부해야겠다고 다짐함!

그리고 Apple의 인도네시아 멘토였던 현재 WWDR의 딕슨, 조엘 등 여러 사람들과 소통할 수 있었다.

특히 딕슨과 꽤 오랫동안 대화를 나눴는데, 본격적으로 취업을 준비하는 나에게 해주신 조언은 너무 도움이 되었다.

어느 나라든 취준은 힘들고.. 여러 사례를 들려주시며 본인을 PR하는 능력, 진짜 너가 가고 싶은 회사가 있다면 링크드인과 같은 플랫폼을 통하 디엠으로라도 연락을 해봐라 라는 적극적인 자세를 추천해주셨다. 조언 뿐만 아니라 응원까지 해주셔서 너무 도움이 되었던 시간이었다. 특히 영어 실력이 좋다는 말씀을 듣고 ... 자신감이 좀 상승했다 하항

마지막날 밤에는 미국에 오신 한국인분들과 펍에서 가벼운 술자리를 가졌다.

다양한 IT 회사에서 오신 분들에게 실무 이야기를 들으면서, 음 나도 얼른 개발자가 되야겠다! 란 다짐을 하게 되었다.

개발자분들에게 많은 질문을 드려서 정말 감사했다는 말씀을 추후에 아이메시지방에 남겼다.. (그 자리에서 전달을 했어야 했는데!)

떱떱이 아니었다면 가지지 못했을 소중한 자리들이 있었어서 지금 돌이켜 생각해봐도 너무 감사했던 순간들이다.

한국인들 최고! 앞으로도 멋진 커리어를 보여주세요!

WWDC가 끝나고 ..

이 회고를 작성하는 지금, 기말고사도 끝나고 방학이 시작했다.

한국에 돌아오자마자 기말고사 2개 해치우고, 다음날부터 담주까지 쭉 시험들이 있어서 정신없이 하루를 보냈다. 인턴 면접도 있었음 ..

지금 와서야 정신이 차려져서 잊혀지기 전에 얼른 WWDC 정리를 해보았다.

1. 이전까진 실내에서 보던 WWDC를 현장에서 볼 수 있다니!

한국에서 떱떱을 보는 것과 미국 쿠퍼티노에서 떱떱을 보는 건 차원이 달랐다. 미국에 있는 많은 IT 업계 종사자들과 전 세계 기업인 애플의 개발자 컨퍼런스에 참여하여 키노트 발표를 볼 수 있는 이 순간은 처음이자 마지막이 될 수 있는 경험이었다.

Liquid Glass가 발표되었을 때의 환호성, 개발자 생산성을 높여줄 GPT와의 콜라보 등등 이번 업데이트는 이전과 비교될 만큼 많은 변화가 생겨났다. 이 과도기에 내가 함께 실시간으로 참여할 수 있어서 감사했고 영광이었다.

내년에 제발 또 갈 수 있길 .... (참고로 distinguished winner는 1번 밖에 못함. 이후엔 랜덤뽑기 당첨이 되길 바래야함 ㅜㅜ)

2. 다양한 나라의 사람들과의 네트워킹은 차원이 다르구나!

기존엔 대체로 한국인들과 IT 관련 내용에 대해 이야기를 나눴다. 대체로도 아니고 전부인듯?

떱떱에 와선 미국뿐만 아니라, 브라질, 사우디, 인도, 일본, 중국 등등 진짜 많은 나라에서 온 Apple 생태계의 사람들과 만날 수 있었던 점이 인상 깊었다. 각 나라의 언어도 알 수 있었을 뿐만 아니라, 그들의 공부하는 방식, 어떻게 개발해오고 있는지에 대해 자세히 들을 수 있어서 너무 재미있었다.

3. 나의 성장..?

다녀오고 나서 확실히 시야가 넓어진 것 같다. 기존엔 접근성 분야에 대해 관심은 있었지만 실질적으로 행동은 못해본 것 같다. 이번 떱떱 3일동안 접근성에 대한 내용도 듣고 피드백도 받아보면서 아직 이 분야는 더 발전해야하고 발전해 나가고 있다는 걸 알 수 있었다. 나도 같이 이 분야에 뛰어들어 공부해보고 싶단 생각이 들었다.

사실 취준 전부터, 해외 취업에 관심이 있었다. 아카데미에서도 해외 취업을 하신 분들이 꽤 계시기도 했고, 난 개인적으론 태어나서 한번쯤은 해외에서 일해보는 경험도 가져보고 싶었다. 떱떱을 다녀오고 나서 외국에서 취업을 해보고 싶단 열정이 더욱 커졌다. 그러기 위해 내가 지금 공부하고 있는 일본어 뿐만 아니라 영어 실력을 더 키워서 나의 의견이나 주장을 더욱 다채롭게 해보고 싶다는 욕심이 생겼다. 참고로 나는 언어를 배우는 게 재미있다. 언어를 통해 사람과 사람간이 연결될 수 있다는 점이 너무 흥미롭거든 ㅎㅎ

앞으로도 사람들의 삶에 긍정적인 영향을 줄 수 있는 개발자가 되기 위해 끊임없이 배우고 도전하겠다고 다짐하며 이글을 마친다.

ps) 두서없이 막 작성된 이 글이 이 후에 있을 한국의 Swift Student Challenge Distinguished Winner에게 도움이 되었으면 한다!

또는 이 행사를 위해 위너에 도전하는 이들에게도!

궁금한 점이 있다면 언제든 연락주세요!

seochoi1003@gmail.com

https://github.com/Guryss

[WWDC25] 스스챌 Distinguished Winner로서 간 WWDC25 현장 후기 (2)

Guryss — Mon, 23 Jun 2025 23:42:22 +0900

WWDC 2일차 (6 / 9)

WWDC25의 가장 큰 행사인 키노트 발표가 있는 날이다보니, 위너들도 오전 7시 10분까지 모여야했다.

그리고 오전 8시쯤 도착해서 아직 아무도 들어오지 않은 애플파크에 먼저 들어갈 수 있는 영광을! 가질 수 있었다.

애플파크를 한바퀴 쭉 돌면서 구경하고 아직 아무도 앉지 않은 애플 파크 키노트 좌석이 있었다.

몇 시간 뒤에는 이 곳에 사람들이 꽉 들어찰 생각을 하니 너무나 설레었다.

키노트 발표 시작 시간인 오전 10시 이전까진 자유롭게 애플 파크를 돌아다니며 아침밥도 먹을 수 있었다.

생각보다 아침밥 퀄리티가 너무나 좋았다. 다양한 종류의 음식들을 준비해줘서 골라 먹을 수 있었다 ㅎㅎ

돌아다니다가 작년에 아카데미 같이 했던 러너들도 만나서 얘기를 나누다가 우연히 유튜버 '방구석리뷰룸'님도 만나서 간단히 인터뷰를 진행했다.

그리고 유튜브에 다음 날 바로 출연했다! 완전 신기방기 (난 36초부터 나옴 ㅋㅎ)

https://youtu.be/Rvugz0O32cU?si=zgRtEt1oMBylwbQK

WWDC25 키노트 발표

드디어 오전 10시! 키노트 발표가 시작되었다.

팀 쿡이 단상 앞에 나오고 엄청난 환호가 쏟아졌다. 역시 그의 첫 마디 "Good Morning!" 을 실시간으로 들었다.

생각보다 팀 쿡의 실물 첫인상은 약간 NPC..? AI..? 가상현실 같으면서도 .. 뭔가 느낌이 신기했다 ㅋㅋㅋ

Apple의 수석 부사장인 크레이그 페더리기를 필두로 컨셉을 가지고 키노트 영상이 나오는데 이것 애플 키노트의 가장 큰 재미요소다.

이번 컨셉은 AppleTV에서 곧 방영 예정인 영화 F1을 컨셉으로 했어서 되게 흥미로웠다.

이후에 알았는데 F1 예고편 중에 햅틱 트레일러가 있어서 예고편을 보는 동안 리얼하게 햅틱이 전달된다!!! 이거 진짜 신기했음

애플이 영화 F1에 투자를 많이 했나부다~ 싶었다.

https://tv.apple.com/kr/clip/%E1%84%92%E1%85%A2%E1%86%B8%E1%84%90%E1%85%B5%E1%86%A8-%E1%84%8B%E1%85%A8%E1%84%80%E1%85%A9%E1%84%91%E1%85%A7%E1%86%AB/umc.cmc.5834l80x7lpxvb1wqiz7uvgj7?targetId=umc.cmc.3t6dvnnr87zwd4wmvpdx5came&targetType=Movie

햅틱 예고편 보기 - Apple TV+

tv.apple.com 웹사이트가 나의 대략적인 위치 정보를 사용하도록 허용하시겠습니까? 위치 정보는 콘텐츠의 이용 가능 여부를 결정하고 라이브 경기, 행사, 뉴스 및 광고 등과 같은 지역 연관 콘텐츠

tv.apple.com

이번 키노트는 너무 인상적이었고 진짜 재미있었다.

많은 변화가 있었던 Apple 생태계를 실시간으로 볼 수 있었음에 너무 감사했다.

실시간으로 보면서 메모 앱에다가 기억하고 싶은 부분들을 적어두었다.

애플 인텔리전스
기본 앱 내 ai 반영

파운데이션 모델 프레임워크
온디바이스 llm 모델

디자인 변경
Liquid glass
투명 감성으로 와우

iOS26 앞으로 연도 이름으로 진행

카플레이 업데이트
디자인 변경
위젯 제공
카플레이 울트라

Unified layout
Call screening
Hold assist

Message background
Group chats - polls, apple cash, typing indicator
Message filtering

Image playground api
Live translation
메세지 페이스타임 전화에서 실시간 번역되어서 보여짐
Call translation api

Visual intelligence
이미지 바로 검색 가능

Apple tv
Automatic sign-in api
Sing with iphone mic with apple music

MacOS
MacOS tahoe
제어센터 편집 가능
폴더컬러, 이모지 변경
라이브 액티비티 - 아이폰, 아이패드, 맥 연결
전화올때 포스터보임
단축어 - intelligent actions
Spotlight - Quick keys
App intents api

VisionOS
WIDGET으로 벽에 붙이기, 커스텀 by widgetKit
나만의 페르소나 생성 내가 말하는대로 페르소나가 말하는 모습을 볼 수 있음
같이 게임도 가능하다

iPadOS
멀티태스킹 한 화면에 여러 뷰 띄워놓기
Background tasks api

Webview api
3D charts

Apple OS 숫자도 올해부터 년도로 작성된다고 한다. <- 루머가 맞았다니!

이번의 가장 화제였던 Liquid Glass.. 보자마자 감탄했다. 너무 예쁘잖아!!

배터리 관리는 어떻게 할 지가 궁금하긴 한데, UI 디테일이 장난 아니라서, 개발할 때 이젠 기본 컴포넌트로 구현하면 더더욱 예뻐질 것 같다.

그리고 온 디바이스 LLM 모델도 개발자들을 위해 API를 제공해준다. Foundation Model이라닛! 이젠 지피티 API를 사용하지 않고 앱 기능을 더 다채롭게 만들 수 있을 생각에 즐거웠다. 이번 스스챌 제출한 앱 디벨롭할 때 꼭 사용해볼 예정이다.

추가적으로, XCode 내에도 커서처럼 에디터 툴 내에 지피티를 바로 활용할 수 있도록 업데이트되었다.

개발자 생산성 미친 상승 .... 너무 기대된다 ㅎㅎ

카플레이도 위젯이 생겼다. 최근에 차 탈 일이 몇 번 있어서 카플레이를 써봤는데 위젯이 있음 참 좋겠단 생각을 했다.

나중에 카플레이쪽도 가볍게 개발해봐도 좋을 것 같다.

올해 애플 생태계의 업데이트를 보면서, 내가 이 생태계를 꾸준히 공부하고 활용할 수 있다는 점이 더욱 흥미롭게 다가왔다.

따라서 이번 방학 동안에는 WWDC 영상을 쭉 보며, 적용해보고 싶은 기능들을 정리해 블로그에 작성할 예정이다!

키노트 발표 이후

이후엔 점심식사를 했다. 진짜 점심이 너무 맛있었다.

일식, 멕시칸, 카레, 비건 등등 각 나라 별 음식이 종류별로 준비되어있었다. 너무 맛있었음 ... 흑흑

그리고 Platform State of Union 이 진행되었다.

이번 Apple에서 주최한 Design Award 수상작들이 발표되었고, 수상자들은 단상에 나와서 인사하는 시간도 가졌다.

또한 Swift Student Challenge Distinguished Winner도 소개되었다.

화면에 내 이름이 떡 하니 !! 너무 신기했다 우하하

작년에 아카데미에서 WWDC를 봤을 때에는 딱 한시간 정도의 키노트 발표만 보고 마무리가 되었다.

하지만 올해에는 현장에서 실시간으로 보게 되니까, 키노트 발표 이외에도 이런 행사들이나 Platform State of Union도 볼 수 있어서 좋았다. 이번에 반영된 Liquid Glass 나 Foundation Model 과 같은 기술들을 코드적으로 구현되는 방식을 자세히 볼 수 있었다.

Apple Design Lab에 참여하다

모든 발표가 끝나고 나서 Apple의 디자인 랩이 오후 3시부터 시작되었다.

이 시간엔 Apple 내 엔지니어 또는 디자이너들을 직접 일대일로 만나서 궁금했던 점이나 피드백을 받을 수 있었다.

나는 이번 스스챌에 제출했던 앱에 대해 직접적인 피드백을 받아보고 싶었다.

특히나 애플은 Accessability 접근성에 관심이 많고 그만큼 이 분야에 대한 발전을 지속적으로 하고 있기 때문에 이 곳에 일하고 있는 분들의 인사이트를 알고 싶었다.

내 앱에 대해 Accessibility design lab에서 질문을 남겼다. 난 내 앱에 대한 전반적인 질문을 했다. 첫번째로는 시니어를 위한 디자인을 위해서는 어떤 것을 고려 해야 될까에 대한 질문을 남겼다.일단 제임스는 높은 대비의 색상을 사용 하는 거 과 매우 큰 글자가 중요하다고 하였다.그리고 나는 앱 아이콘 심불이 시니어 환자들에게 잘 보여 줄 수 있을지에 대해서 질문을 했는데 이정도면 매우 충분하고 마찬가지로 앱 아이콘들의 간격이 꽤 넓어야 한다는 것을 강조 하였다. 나는 이전까지는 내가 만든 앱 디자인에 대한 확신이 없었는데 제임스에게 앱에 대한 조언을 듣고 난 뒤 어느 정도 확신이 생겼다. 내가 서치한 내용이 틀리지 않았다는 것이 매우 유의미하였고 조만간 일단 얼른 출시해 봐야겠다. 아 그리고 폰트를 사용하는 것에도 물어 봤는데 나는 현재 폰트를 두 가지를 사용하고 있어서 앱에서 다른 폰트를 사용해도 괜찮은지에 대해서 물어 봤는데 폰트는 무조건 통일 해주는 게 좋다고 얘길 했다.

일대일로 피드백 받는 시간이 지난 뒤, 나오자마자 받아쓰기로 바로 메모 앱에 작성해두었던 내용이다.

난 디자이너로 갈 생각은 없지만, 오직 1인으로 개발한 나만의 앱에서 개발보단 디자인적인 인사이트가 객관적으로 부족했다고 생각했다.

현재 Apple의 Accessability 팀에서 디자이너로 계신 제임스라는 분을 만나서 앱에 대해 자세히 설명해드리고, 앱을 보여드리면서 다양한 부분에 대해 질문을 드렸다. 시니어 유저를 위한 컬러 선정, 아이콘 이미지, 앱 전환 로직 등을 물어보며 UX를 개선해보고 싶다는 의지를 보였다. 언제 내가 애플 관계자에게 피드백을 받아보겠나~ 싶은 생각도 들면서 .. 이 시간이 정말 의미있었고 짧은 시간이었지만 진짜 유용한 인사이트를 얻을 수 있었다.

이 글을 읽는 분들 중 떱떱에 가게 된다면 완전 강추다!

가기 전에 애플 엔지니어, 디자이너에게 물어볼 내용을 미리 정리해서 가면 더 좋을 것 같다!

WWDC25 2일차 Wrap up

2일차를 마무리하며 .. 떱떱의 가장 핵심이었던 이틀차가 끝났다.

디자인랩이 끝난 이후엔 돌아다니면서 한국인 개발자분들에게 취업이나 실무와 관련된 궁금했던 부분들에 대해 물어봤다.

다들 너무나 친절하게 답변해주셔서 감사했다! 이제부터 슬슬 취업 준비를 하는 단계인데, 취준생인 나에게 너무 좋은 조언을 주셨다.

이 날은 아침 일찍부터 시작해서 피곤해 늦은 오후에 숙소로 복귀하였다.

역시 잘 즐길려면 체력도 중요함 ..

[WWDC25] 스스챌 Distinguished Winner로서 간 WWDC25 현장 후기 (1)

Guryss — Mon, 23 Jun 2025 12:26:39 +0900

지난 3월 말, Apple에서 주최한 Swift Student Challenge에서 Distinguished Winner로 선정되어 Apple의 전세계 개발자 컨퍼런스인 WWDC에 초대받게 되었다.

그리고 난 6월 6일부터 6월 12일, 총 6일동안 미국 캘리포니아 쿠퍼티노에 다녀왔다.

과연 Distinguished Winner로서 초대받게 되면 어떤 행사를 참여하게 되고 어떤 경험을 할 수 있었는지 작성해보고자 한다!

미국 가기 전

떱떱 가기 전엔 크게 준비할 건 없었다. 왜냐하면 애플에서 다 준비해준다... 최고

비행기도 원하는 시간 일정에 맞춰 예약해두면 애플에서 컨펌 후 예약을 확정해줬다. 완전 편했음!

숙소도 애플 파크 바로 앞에 있는 3성급 호텔 코트야드로 예약해줬다.

룸 당 한 사람씩 배정을 해줘서 매우 편하게 다녀왔다

행사는 공식적으론 8일부터 시작이었지만, 저는 미국에 6일에 도착했는데에도 이 일정까지 고려해주어 숙소 체크인을 해줬다.

난 당연히 다른 숙소에서 하루 묵고 넘어가야겠다고 생각했는데 비행기 일정에 맞춰 숙소 일정을 배정해줬다. 히히

그리고 미국 가기 한 달 반 전부터 일주일에 두 번씩 화상 영어 수업을 들었다.

수능 이후로는 영어 공부를 따로 해본 적이 없었기 때문에 특히 스피킹에 자신이 없었다

그래서 학교에서 연결해주는 화상영어 기관을 통해 약 한 달간 원어민 선생님과 수업을 진행했다.

저는 한 달 뒤에 개발자 컨퍼런스에 갈 예정이라고 말씀드리고, 그 곳에서 할 수 있는 대화 주제를 중심으로 프리토킹을 했다.

지금 돌이켜 생각해보니, 이 화상 영어 수업이 정말 큰 도움이 된 것 같다.

선생님이 늘 하시던 말씀이 "영어는 결국 자신감!" 이었는데, 이 마인드가 굉장히 도움이 많이 되었던 것 같다. 하항

미국 도착!

유나이티드 항공을 타고 약 11시간동안 비행을 해서 샌프란시스코 공항에 도착했다.

행사 공식 일정은 6월 8일 ~ 10일, 총 3일이었지만 전 미국시간으로 6일 오전에 도착해서 이틀 간의 자유 시간이 있었다.

첫날에는 시차때문에 정신이 혼미해서 하루종일 잠만 잤다. 지금 생각하면 너무 아쉬운 ㅠㅠ

그리고 둘째날에는 스탠포드 대학교 구경, 산타나 로우, 애플파크 비지터 센터를 쭈욱 구경하고 일찍 숙소로 복귀했다.

WWDC 1일차 (6 / 8)

1일차에는 호텔 로비에서 오전 10시 10분까지 모이라는 일정이 있었고, 이외에는 아무 행사 관련 정보를 알 수 없었다. ㅋㅋㅋㅋ

두근거리는 마음을 갖고 호텔 로비에 가니, 벌써 distinguished winner들이 모여 네트워킹을 하고 있었다.

처음엔 낯을 좀 가려서 어색어색했는데, 같이 간 한국인 위너들도 있어서 가볍게 얘기하고 나니 어느 정도 긴장이 풀렸다.

스스챌 위너 전용 버스

위너들을 픽업해주는 전용 버스가 따로 있었다.

이 버스 덕분에 숙소에서 애플 파크까지, 애플 파크에서 숙소까지 아주 편하게 이동할 수 있었다.

스스챌 위너 전용 뱃지 !

WWDR팀 내 스스챌 위너들을 따로 관리해주는 직원분들이 항상 저 팻말을 들고 다니시면서 우리를 챙겨주셨다.

저 사진은 애플 파크 내에 도착해서 체크인을 할 때였다.

첫 일정은 바로 애플 파크 내 무지개에서 위너들끼리 사진 촬영이었다.

사진 찍을 때 Apple의 CEO인 팀쿡과 Apple WWDR의 수잔이 와서 함께 기념 사진을 찍을 수 있었다.

당시 공원에 있던 사람들 대부분이 우리를 찍고 있어서 마치 연예인(?)이 된 기분이었다.

이후에 무지개 앞에서 자유롭게 사진을 찍는 시간을 줘서, 다른 사람들이 없을 때 찍을 수 있어 '이것 또한 특권이구나' 싶었다.

사진을 찍고 있으면 애플 포토그래퍼 분들이 자연스럽게 저희 모습을 담아주시곤 했는데, 운 좋게도 제가 찍히는 순간이 있었고…

결국 내가 팀쿡의 X 썸네일에 출연하는 영광을 안겨주셨다

https://x.com/tim_cook/status/1931892818404057417?s=46

이후엔 점심식사를 하러 애플 건물 내로 들어갔다.

음료수 무한 제공과 음식도 샌드위치랑 샐러드, 디저트 등등 구성이 다채로웠다. 공짜라니 말도 안되는 ㅠㅠ

한국인 위너들과 함께 얘기를 나누면서 점심을 먹었다.

점심식사 후에는 Apple 내 엔지니어분들과의 미니 토크쇼가 진행되었다.

오직 스스챌 distinguished winner들을 위한!! 엄청 프라이빗하고 오직 우리만을 위해 만들어진 자리였어서 매우 새로웠다.

왠지 토크쇼 진행 중간 사진은 올리면 안될 것 같아.. 진행 전의 사진만 올려본다.

이 자리에는 Apple의 Soft Engineering 수장인 Cheryl이 진행을 맡아주시고, Josh, Leslie, Tim이 참여했다.

이들의 어린 시절 사진과 함께 유년시절을 어떻게 보냈으며, 어떻게 애플에 합류하게 되었는지에 대한 이야기를 들을 수 있었다.

또한 그들이 지금 현재 어떤 팀에 참여해서 어떤 기술들을 담당하고 있는 지도 생각보다 생생하게 들을 수 있었다.

토크쇼가 끝난 후, 위너들끼리 작게 팀을 이뤄 서로를 간단히 소개하는 시간을 가졌다.

어떤 앱을 개발했는지, 어떤 일을 하고 있는지 등 얘기를 나누고 난 뒤, 어디론가 안내 받았다.

그 곳에선 Apple의 Airpods Max를 직접 분해해보며 각 부품들의 역할과 구조를 살펴보는 특별한 시간이 마련되어 있었다.

비록 사진 촬영은 불가능했지만.. 이 기회 또한 오직 위너들에게만 주어진 것이라 더욱 특별하고 흥미로웠다.

직접 드라이버로 나사를 풀며 부품을 하나씩 분해해보고, AirPods Max 담당 애플 엔지니어분들이 각 부품에 대해 자세히 설명해주셨다.

평소 AirPod Max를 사용하고 있는 사람으로서 노이즈 캔슬링, 소리 전달 방식 등을 직접 이해해볼 수 있는 시간이어서 매우 인상적인 경험이었다.

그리고 나서 Apple Infinite Loop에 가서 공식적인 WWDC 첫 날 행사에 참여할 수 있었다.

이 또한, 우리는 프리패스로 들어갈 수 있어서 행사 기간동안 편하게 즐길 수 있었다.

자유롭게 돌아다니며 사람들과 네트워킹을 하거나 건물 안에선 Apple Design Award에 선정된 앱들을 구경할 수도 있었다.

특히나 이번엔 우리나라 개발자들이 만든 3D 드로잉 앱인 Feather도 있어서 매우 자부심이 느껴졌다.

https://apps.apple.com/kr/app/feather-3d-%EB%93%9C%EB%A1%9C%EC%9E%89/id6737254232

나도 이리저리 돌아다니면서 사람들도 구경하고 앱들도 구경하면서 시간을 보냈다.

또한 애플에서 제공해주는 스낵, 디저트들도 먹을 수 있었고 원하면 와인도 마실 수 있었다.

한국인분들도 많이 오셨어서 대화를 나누니 시간이 금방 흘렀다.

첫째날의 마무리로는 이탈리아 애플 디벨로퍼 아카데미에서 주최한 special pre-WWDC meetup에 참여했다.

전세계 애플 디벨로퍼 아카데미 러너들과 멘토들을 만나 네트워킹할 수 있는 시간을 가졌다.

이때, Hacking with Swift의 폴쌤도 만났다...

나의 첫 스위프트 선생님이었어서 너무 반가웠는데, 내 앱까지 직접 시연하고 피드백도 받을 수 있어서 너무 뜻깊은 경험이었다

샌프란에서 일하고 있는 아카데미 러너인 슌도 만나고, 작년에 자주 봤던 얼굴들을 많이 만날 수 있어서 또 너무 반가웠다.

기억에 남는 에피소드 중 하나는, 행사가 진행되던 펍에서 우연히 Apple의 관계자분을 만나게 된 일이었다.

내가 위너 목걸이를 차고 있었기 때문인지, 나에게 관심을 보이셨고 내가 만든 앱 서비스에 대한 설명을 너무 흥미롭게 들어주셨다.

알고보니 그 분의 아내분은 Apple의 WWDR팀에서 일하시는 분이셨고, 본인도 메디컬 쪽에 근무하고 계신다고 하셨다.

이야기를 나누던 중, 나중에 앱이 출시되면 꼭 알려달라며 이메일 주소를 주시기도 했다.

이처럼 즉흥적이며 감사한 기회들이 자연스럽게 생겨나는 곳이 바로 이 자리구나, 하는 걸 다시금 느낄 수 있는 순간이었다.

1일차 Wrap up

생각보다 Apple에서 위너들을 세심하게 챙겨주고 따뜻하게 환영해줘서 낯설면서도 정말 신기했고, 그만큼 너무 신났다.

이때 아직 시차 적응을 못해서 체력적으로 많이 지치긴 했었지만, 언제 또 이런 경험을 해보겠어! 란 마인드로 행사에 끝까지 참여하면서 다음날 있을 WWDC 키노트 행사를 기대하면서 마무리했던 것 같다.

전 세계에서 온 위너들과도 영어로 대화를 나누며 느꼈던 건, 아 아직 난 멀었다.. 더 열심히 노력하고 성장해야 한다..고 다짐했다.

지금까지는 주로 한국에서 한국 사람들과의 네트워킹을 해왔다면, 이번 해외에서의 네트워킹은 또 다르게 느껴졌다.

그들의 iOS 개발 동기, 어떤 기술에 관심이 있는지, 각 나라의 iOS 점유율에 이르기까지 정말 다양한 이야기를 깊이 있게 나눠볼 수 있었고, 그 과정이 너무 재미있었고 인상깊었다.

[WWDC25] 애플 본사에 가기 전까지의 좌충우돌 기록 ‍➡️

Guryss — Sun, 13 Apr 2025 15:11:37 +0900

애플에서 초청한 6월 7일부터 11일까지 나는 한국이 아닌 미국의 쿠퍼티노에 있게 되었다.

따라서 나는 4학년 1학기를 다니고 있는 대학생이기 때문에 공결 인정을 위해 교수님들에게 메일을 보내게 되었다.

학교 다니는 약 4년 간 교수님들에게 메일 따위 보내보지 않은 사람.... 저에요

사실 학교에서 공식적으로 인정하는 결석 사유에는 해당되지 않았다.

흑흑. 그렇기 때문에 교수님들에게 직빵으로 연락을 드려 따로 인정을 받는 방법밖엔 없었다.

다행히도! 몇몇 교수님들은 긍정적으로 생각해주셔서 증명서나 참석 인증 사진만 제출하면 공결로 인정해주신다고 하셨다...

흑흑 넘나 감동적

하지만, 마냥 쉽지만은 않았다.

WWDC 같은 개발자 컨퍼런스의 의미를 잘 이해해주시고, 기꺼이 공결을 배려해주신 교수님들도 계셨다.
하지만 특히 컴퓨터공학과와 전혀 관련이 없는 교수님들의 경우, 이 행사가 어떤 행사인지조차 생소했고,
내가 “초청을 받았다”고 말해도 어떻게 선정되고, 어떤 기준으로 뽑히는 건지 구체적인 내용을 알 수 없으셨다.

사실 교수님들께 공결 요청 메일을 보내면서, 그냥
"애플에서 초청받아 WWDC25에 참가하게 되었습니다!"
라고 하면 이 행사의 의미나 중요성이 자연스럽게 전달될 거라고 생각했다.

하지만 전공 교수님 중 한 분께서
WWDC25가 어떤 행사인지, 어떤 앱을 제출해서 선정된 건지, 이게 학교와 어떤 관련이 있는지

구체적인 자료를 부탁한다고 말씀하셨고 그때서야 깨달았다. 아, 내가 너무 선정된 사실에 심취해 중요한 걸 간과했구나

생각해보면 이 분야에 익숙하지 않다면 WWDC가 뭔지, Swift Student Challenge가 어떤 건지 모를 수밖에 없다.
엄마한테 스스챌 distinguished 위너로 선정됐다고 말했을 때도, 과정에 대한 많은 추가적인 설명을 말하고 나서 이해하셨다.

그래서 나는 다시 자료들을 준비하면서 이 행사 자체를 처음 들어보는 사람들도 쉽게 이해할 수 있도록 자료를 만들게 되었다.

이런식으로 워드 문서에 추가자료를 정리했다.. 우핳하

기말고사 이슈

하나 또 문제가 있었는데, 미국시간으로 11일 오후에 한국으로 돌아오면 12일 저녁~밤에 돌아오게 되었다.

근데 12일 오후 7시, 오후 8시에 교양 수업 기말고사가 2개나 있었다........... 시험시간에 난 비행기에 있는 불상사가 발생할 상황이었다.

최대한 교수님께 소명, 재검토, 재고 부탁 등등을 드렸지만 나를 위해 기말고사 기간을 변경하는 건 전혀 불가하였다.

그래서 나는 기말고사 대체과제와 같은 대체방안이 있는지 여쭤봤지만 그에 대한 사례가 전혀 없었기도 하고, 아무리 과제를 잘하더라도 B 이상으론 주기 어렵다고 답변 받았다. 난 이제 4학년이고 학점 관리가 필수적인 상황에서 교양 수업 학점이 B 언더인건 꽤나 크리티컬했다....

나는 애플 트래블 측에 문의를 남겼다.

한국 시간으로 12, 13일에 시험이 총 3개가 예정되어 있어서 13일에 한국으로 돌아가고 싶다고 남겼다.

메일을 보내고 하루 이틀 뒤에 애플 본사측에서 전화가 왔다.

비자 문제가 있기 때문에 행사일 이후에 돌아가는 건 불가하다는 답변이었다.

따라서 10일 저녁 또는 11일 완전 아침에 비행기를 타는 방법, 또는 교수님을 다시 설득해보는 방법 뿐이었다.

결국에는.......... 흑흑 11일 오전에 뱅기를 타는 걸로 결정했고, 비행기가 연착되지 않길 기도하는 수밖에..........

그럼에도 불구하고 난 간다!

처음 경험해보는 준비 과정이었기에 처음에는 스트레스를 꽤나 받았던 것 같다.

내가 왜 이걸 일일히 설명해야하지? 이정도면 충분한 거 아닌가? 공부하기도 바쁜데 내가 이것까지?

하지만 그 사람들 입장에서 이성적으로 생각해보면 나 아니면 그 누구도 설명해줄 사람이 없다는 것이다.

내가 나를 표현해야 하는 자기PR의 시대인 것처럼, 이 또한 PR의 과정이라고도 생각한다.

그리고 지금까지 주입식 강의만 들었던 일개 대학생이었던 나로서는 교수님들과 많은 대화와 이메일을 주고받은 것이 꽤나 유익했던 경험이었다 ^.^

오늘은 애플 아카데미 인터뷰에도 참여하고 이전에는 애플 PR팀과 온라인 인터뷰도 진행했다!

모든 게 다 처음이라 긴장되면서도 설레는 상황들의 연속인데, 이 모든 것들이 나에게 도움이 되고 성장의 밑거름이 될 거라 확신한다!!

다음은 인터뷰 후기를 작성해봐야겠다 ㅎㅎ