Search

All Posts (49)

Search

What I Learned

왜 DM 대화방에 상태 머신 패턴을 적용했는가?

DM은 단순히 “있다/없다”가 아니라 여러 상태를 거친다.
상태를 enum으로 정의하면 불가능한 상태 전이를 컴파일 타임에 방지할 수 있다.
만약 상태를 Bool 여러 개로 관리했다면?

왜 DirectMessage에 불변 객체 + 복사 패턴을 적용했는가?

iOS DM 기능 구현 - 상태 머신과 불변 객체 패턴
TIL

What I Learned

1. 왜 Message 모델에 isFromCurrentUser를 계산 프로퍼티로 만들었는가?

메시지를 생성할 때 isFromCurrentUser: true를 직접 넣으면 두 가지 문제가 생긴다.
1.
데이터 불일치: P2P로 받은 메시지를 변환할 때 실수로 true를 넣으면 남의 메시지가 내 메시지로 보임
2.
중복 로직: 메시지 생성하는 모든 곳에서 senderNumber == myNumber 비교를 해야 함
계산 프로퍼티로 만들면 senderNumber만 정확하면 항상 올바른 값이 나온다. 단일 진실 공급원(Single Source of Truth) 원칙

2. 왜 P2PPayload에서 Message로 변환하는 생성자를 만들었는가?

P2P로 데이터를 주고받을 때는 P2PPayload를 사용하고 UI에서는 Message를 사용한다. 두 모델의 역할이 다르기 때문
•
P2PPayload: 네트워크 전송용 (type, targetNumber 등 포함)
•
Message: UI 표시용 (displayName, isFromCurrentUser 등 포함)
변환 로직을 Message 내부에 두면 변환이 필요한 곳에서 Message(from: payload) 한 줄로 끝난다.

3. 왜 메시지 라우터를 별도로 분리했는가?

iOS 퍼블릭 채팅 기능 구현
TIL

What I Learned

왜 Singleton 패턴을 사용했는가?

UserSession은 앱 전체에서 단 하나의 사용자 정보만 관리해야 한다. 여러 인스턴스가 생기면 사용자 번호, 닉네임, 연결 상태가 서로 다른 값을 가질 수 있어 데이터 불일치가 발생한다.
왜 final class인가? 상속을 허용하면 자식 클래스에서 또 다른 인스턴스를 만들 수 있다. final로 막아야 진정한 Singleton이 보장된다.
왜 private init()인가? 외부에서 UserSession()을 호출하면 새 인스턴스가 생긴다. 이를 막아야 shared만 사용하게 강제할 수 있다.
왜 private(set)인가? userNumber는 외부에서 읽을 수는 있어야 하지만, 변경은 UserSession 내부에서만 해야 한다. 외부에서 마음대로 바꾸면 P2P 통신에서 다른 기기와 번호가 맞지 않게 된다.

왜 didSet으로 자동 저장을 구현했는가?

설정 값을 변경할 때마다 save() 함수를 수동으로 호출하면 개발자가 실수로 빼먹을 수 있다. 앱을 재시작했을 때 설정이 저장되지 않은 버그가 발생한다.
왜 Key를 enum으로 관리하는가? 문자열 키를 직접 사용하면 오타가 나도 컴파일러가 잡지 못한다. “user_nicknam” 같은 오타는 런타임에 데이터가 안 불러와지는 버그로 이어진다. enum을 사용하면 컴파일 타임에 오타를 잡을 수 있다.
iOS 사용자 세션 관리 구현
TIL

What I Learned

1. MultipeerConnectivity 프레임워크 이해

iOS에서 Wi-Fi, Bluetooth를 통한 근거리 P2P 통신을 구현할 때 MultipeerConnectivity 프레임워크를 사용한다.

핵심 컴포넌트

연결 흐름

2. iOS 17+ @Observable 매크로

기존 ObservableObject + @Published 대신 @Observable 매크로를 사용하면 보일러플레이트가 크게 줄어든다.
장점:
•
@Published 키워드 불필요
•
View에서 @ObservedObject 대신 일반 변수로 사용 가능
•
성능 향상 (필요한 프로퍼티만 추적)

3. Thread Safety in MultipeerConnectivity

iOS P2P 연결 서비스 구현 (MultipeerConnectivity)
TIL

 문제 요약

1. API 요청에서 자동 토큰 갱신이 동작하지 않음

•
모든 네트워크 요청에 provider.request(...)만 사용
•
401 (EXPIRED_TOKEN) 응답이 와도 토큰 자동 갱신 및 재요청이 발생하지 않음

2. TokenRefreshPlugin() 인스턴스를 계속 새로 생성

•
이로 인해 동시다발적으로 토큰 갱신 요청이 중복 발생 → Race Condition 유발

3. 앱을 3~5회 재실행 시, 로그아웃 상태가 되어 로그인 화면으로 이동

•
앱을 3~5회 재실행 시, 로그아웃 상태가 되어 초기 화면으로 이동
•
콘솔에 에러 로그는 출력되지 않음
•
AppState 인스턴스를 뷰 내에서 매번 새로 생성했기 때문
•
이로 인해 @Published var isLoggedIn 값이 초기화되며 상태가 불일치하게 됨

4. JWT 토큰 만료 여부를 정확하게 판단하지 못함

•
기존에는 만료 여부를 확인하지 않거나 단순 문자열 조건으로 검사 (토큰이 “있기만 하면” 유효하다고 판단)
•
만료된 토큰으로 API 요청이 시도되며 불필요한 401 오류 발생
토큰 갱신 버그
Troubleshooting

문제 상황

컬렉션 뷰에서 가로 스크롤하면 컬렉션 뷰가 최상단으로 강제 이동하는 문제가 발생했다.
이 문제는 adjustContentInset() 메서드의 호출 타이밍과 UICollectionView의 동작 방식이 충돌하면서 발생한 것으로 분석되었다.
adjustContentInset()의 역할

원인 분석

이전 코드에서는 viewDidLayoutSubviews()에서 adjustContentInset()을 호출했다. 하지만 viewDidLayoutSubviews()는 뷰의 레이아웃이 변경될 때마다 반복적으로 호출되므로 불필요한 스크롤 이동이 발생하는 문제가 있었다.

 해결 방법

viewWillAppear(_:)에서 adjustContentInset() 메서드를 호출하니 해결되었다.

결론

가로 스크롤 시 최상단으로 이동하는 문제 해결
Troubleshooting

목차

의존성 주입이란?

클래스나 구조체가 필요로 하는 외부 객체(의존성)를 직접 생성하지 않고 외부에서 전달받는 방식을 말합니다. 쉽게 말해서, 내가 필요한 것을 직접 만들지 않고 누군가에게 받아서 사용한다는 개념입니다. 간단한 예시로 커피 주문 시스템을 통해 알아보겠습니다. 의존성 주입이 없다면 다음과 같이 코드를 작성하게 됩니다.
이렇게 작성하면 CafeCounter와 Americano가 강하게 결합되어 다른 음료로 변경하기 어렵고 테스트하기도 어려워집니다.

Property Injection

Dependency Injection
TIL

목차

세션과 토큰이란 무엇인가?

세션은 사용자가 서버에 로그인할 때, 서버 측에 저장되는 사용자 정보의 임시 저장소이다. 세션을 통해 사용자가 로그인된 상태를 유지할 수 있다. 예를 들어, 사용자가 로그인을 하면 서버는 세션 ID를 생성하고 이를 통해 해당 사용자가 로그인한 상태를 인식하게 된다.
세션과 토큰
TIL
Network
Swift에서 Equatable, Hashable, Comparable은 자주 사용하는 기본 프로토콜입니다. 이 프로토콜들은 객체 간의 비교 및 고유 식별이 필요할 때 활용되며 컬렉션 타입에서 객체의 정렬, 검색, 중복 확인 등을 쉽게 할 수 있게 합니다.

목차

Equatable

Equatable 프로토콜은 두 객체의 동일성을 확인하기 위한 프로토콜입니다. Equatable을 준수하는 타입은 == 연산자를 통해 두 인스턴스가 같은지 비교할 수 있습니다. 주로 객체의 속성 값이 같은지 확인하여 동일성을 판단합니다.

특징

장단점

Equatable, Hashable, Comparable
TIL
protocol

목차

Override란?

Override는 클래스의 메서드, 프로퍼티 또는 서브스크립트를 하위 클래스에서 재정의하는 개념입니다. Override는 주로 상속받은 기능을 커스터마이징하거나 확장할 때 사용되며 다형성(polymorphism)을 구현하는 중요한 수단 중 하나입니다. 메서드나 프로퍼티를 재정의할 때는 override 키워드를 사용하여 명시적으로 나타내야 합니다.

Override의 특징

Override
TIL
override
Swift를 배우면서 프로퍼티(Property)에 대해 접하게 될 텐데, 프로퍼티는 클래스, 구조체, 열거형 등에 속하는 값들을 의미합니다. 크게 Stored Property(저장 프로퍼티), Computed Property(연산 프로퍼티), Type Property(타입 프로퍼티)로 나뉩니다. 이 글에서는 이 세 가지 프로퍼티의 차이점을 설명하고 메모리 상에서 어떤 차이가 있는지 알아보고자 합니다.

목차

Stored Property

저장 프로퍼티는 말 그대로 값을 저장하는 역할을 하는 프로퍼티입니다. 클래스나 구조체의 인스턴스에 해당 값을 저장하고 그 값을 메모리에 유지합니다. 쉽게 말해, 우리가 변수를 선언하고 값을 할당할 때와 같은 역할을 합니다.

예시 코드

Stored, Computed, Type Property
TIL
Property
개발을 하다 보면 특정 객체가 앱 전역에서 하나만 존재해야 하는 경우가 있습니다. 그럴 때 사용하는 디자인 패턴이 바로 '싱글톤(Singleton)'입니다. 싱글톤 패턴은 객체의 인스턴스가 하나만 생성되도록 보장하고 이를 전역적으로 접근할 수 있게 합니다. 이 글에서는 싱글톤 패턴이 무엇인지, 왜 사용하는지, 그리고 실제로 어디에 적용할 수 있는지 알아보도록 하겠습니다.

목차

싱글톤 패턴이란?

싱글톤 패턴은 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴입니다. 이 패턴은 주로 전역 상태를 관리하거나 자원의 중복을 방지하고 싶을 때 사용됩니다. 예를 들어 네트워크 매니저, 데이터베이스 연결 객체 등은 애플리케이션 전체에서 하나의 인스턴스로만 존재해야 합니다. 여러 인스턴스가 생성된다면 리소스를 낭비하거나, 데이터를 일관성 있게 유지하는 것이 어려울 수 있습니다.
싱글톤 패턴의 주요 특징은 다음과 같습니다.
싱글톤 패턴의 이해와 활용
TIL
Singleton
어느새 중간고사가 코앞으로 다가왔는데 나는 여전히 책을 덮고 코드 속에 빠져 있다. 누구는 책을 펼치고 누구는 게임 속에서 시간을 보낼 때 나는 조용히 노트북 앞에 앉아 컴퓨터와 대화를 나눈다. 때론 이런 나 자신이 자랑스럽다가도 문득 불안감이 스며든다. 만약 회사에 들어갔을 때 내가 쏟아부은 시간과 노력에 비해 그 결과가 초라하면? 다른 사람들이 내가 걸어온 길이 거짓이라며 비웃지는 않을까?
하지만 이제 그런 걱정은 내려놓으려 한다. 중요한 건 내가 진심을 다해 달려왔다는 사실 그리고 내 걸음걸이가 남들과 다르다는 게 틀린 것은 아니라는 깨달음이다. 천천히 그러나 확고하게 내 길을 따라 나아가다 보면 결국 나만의 빛을 마주하게 될 것임을 믿는다. 오늘의 발걸음이 내일의 길을 만든다. 주변의 시선에 흔들리지 않고 내 속도로, 내 방식대로 걸어가자. 그리하여 마침내 그 빛나는 순간을 맞이할 때 나는 이 모든 과정이 나를 만든 것이었음을 알게 될 것이다.
그러나 그 여정 속에서도 CS에 대한 기본적인 이해는 꾸준히 챙겨야 한다는 것도 잊지 말자. 코딩의 기초가 되는 원리와 이론은 그 어느 때보다 중요한 자산이 될 것이다.
느려도 꾸준히 그리고 확고하게
Retrospect

목차

클로저란?

클로저는 코드의 일부분을 캡슐화하여 나중에 호출할 수 있는 기능입니다. 흔히 익명 함수나 lamda로 알려져 있으며 함수와 매우 유사하지만 더 간결한 형태로 사용할 수 있습니다. 예를 들어, 배열의 정렬이나 비동기 작업 등에 자주 사용됩니다.

배열 정렬 예시 코드

비동기 작업 예시 코드

Swift의 클로저에 대해 알아보기
TIL
Closure
@escaping
Computer Science
UILabel의 줄바꿈 동작과 관련이 있음.

numberOfLines = 0

•
UILabel은 줄 수에 제한이 없다는 것을 의미함.
•
텍스트가 한 줄에 모두 들어갈 경우에도 UILabel은 줄바꿈을 지원할 수 있도록 약간의 추가 여백을 제공할 수 있음.
•
텍스트가 여러 줄에 걸쳐 있을 때 줄 수 제한 없이 자유롭게 높이가 늘어나므로 레이아웃 시스템이 이를 고려하여 추가 여백을 남길 수 있음.

numberOfLines = 1

•
UILabel은 텍스트를 한 줄로 제한함.
•
텍스트가 한 줄을 초과할 경우 자르고 여백이 최소화됨.
•
한 줄에 딱 맞게 레이아웃이 잡히며 추가적인 줄바꿈을 고려하지 않기 때문에 여백이 최소화되어 더 컴팩트한 레이아웃을 제공함.
numberOfLines = 0과 numberOfLines = 1의 여백 차이
TIL
UIKit
UILabel
앱의 생명주기
TIL
UIKit
Lifecycle

목차

뷰 컨트롤러의 생명주기
TIL
UIKit
Lifecycle
스레드는 프로그램이 동시에 여러 작업을 처리할 수 있게 해주는 중요한 개념입니다. 스레드를 사용하면 프로그램이 여러 일을 동시에 처리할 수 있으며 성능을 크게 향상시킬 수 있습니다.

목차

스레드란?

운영 체제가 프로세스 내에서 실행되는 가장 작은 단위입니다. 모든 프로그램은 최소 하나의 스레드를 가지고 있으며 이를 메인 스레드라고 부릅니다. 스레드는 프로세스 내에서 동시에 여러 작업을 처리할 수 있으며 프로세스가 자원을 여러 스레드 간에 공유하면서 작업을 수행합니다.
프로레스를 ‘회사’라고 생각하면 스레드는 ‘직원’이라고 볼 수 있습니다. 회사는 여러 직원이 각기 다른 작업을 병렬로 수행하게 하여 더 많은 일을 할 수 있습니다. 마찬가지로 프로세스도 여러 스레드를 생성해 다양한 작업을 동시에 처리할 수 있습니다.
Thread
TIL
Thread
Computer Science
한국 블로그에는 해당 내용에 대한 자세한 정보를 찾기 어려워서 결국 해외 커뮤니티(레딧, 애플 개발자 공식 커뮤니티, 애플 공식 문서, 깃허브 등등)를 많이 참고했다. 솔직히 영어 실력이 부족해 모든 자료를 하나하나 번역하면서 해석하는 것이 꽤 힘들었다(+ 번역 프로그램이 있지만 결국에는 영어와 함께 봐야 한다. PrivacyInfo 추가될 속성들도 한글로 번역되기 때문). 하지만 이런 과정을 반복하다 보면 결국 영어와 기술 문서 해석이 지금보다 훨씬 수월해질 것이라고 믿는다. 확실히 코딩뿐만 아니라 영어 실력도 중요하다는 것을 이번 경험을 통해 다시 한 번 깨달았다. 문제를 해결하긴 했지만 솔직히 제대로 했는지에 대한 확신은 아직 없다. 그래도 여러 문서를 탐구하고 분석하는 과정은 굉장히 재미있었고 새로운 지식을 배우면서 한 단계 성장한 느낌이 들었다. 문제를 해결했을 땐 내가 정말 개발자가 된 것 같았고 뿌듯했다. 앞으로도 더 많은 에러를 만나고 싶다. 내가 아직 모르는 에러들이 많다는 점이 오히려 다행이라고 생각한다. 왜냐하면 앞으로 풀 문제가 아직 많이 남아있고 성장하는 즐거움을 그만큼 더 많이 느낄 수 있기 때문이다. 지금처럼 초심 잃지 말고 꾸준히, 그리고 열심히 최선을 다해보자.
문제 해결과 배움의 즐거움
앱 스토어에 심사를 제출하니 1분 이내에 다음과 같은 메일이 날라왔다.
App Store 검토를 위한 제출이 성공적으로 완료되었더라도 다음 번 App Store 검토 제출 시 다음 문제를 수정하는 것이 좋습니다. 문제를 수정한 후 App Store Connect에 새 바이너리를 업로드하세요.

4. 보안성 강화

ITMS-91061: Missing privacy manifest - Privacy manifest? / 해결 방법
TIL
Xcode
CocoaPods
프로젝트를 진행하면서 WeatherKit을 사용해야될 상황이 와서 Minimum Deployment를 15.0에서 16.0으로 업그레이드 했다. 하지만 iOS Deployment Target도 자동으로 16.0으로 변경될 줄 알았는데 15.0인 것을 발견하였다. 애플은 왜 번거롭게 두 개로 나누어서 버전을 설정하도록 했을까?

iOS Deployment Target과 Minimum Deployment의 차이

먼저, 간단하게 두 개념을 정리해보자.
•
iOS Deployment Target은 앱을 개발할 때 테스트와 빌드에서 사용할 최소 iOS 버전이다. Xcode에서 프로젝트나 각 타겟별로 이 버전을 설정하게 되며 이 설정에 따라 해당 버전 이상의 iOS에서 앱이 실행될 수 있다. 즉, 개발 과정에서 이 버전을 기준으로 앱이 정상 동작하는지 테스트하게 된다.
•
Minimum Deployment는 앱이 배포될 때 실제로 최소 요구되는 iOS 버전을 정의하는 설정이다. 이 값은 앱이 앱 스토어에 올라가면 그 버전 이상의 iOS 기기에서만 앱을 다운로드하고 실행할 수 있도록 하는 제한을 걸어준다. 보통 이 값은 Info.plist나 프로젝트 설정 파일에 기록된다.

왜 두 개로 나누었을까?

iOS Deployment Target을 따로 설정함으로써 개발자가 더 낮은 iOS 버전을 지원하는 코드 작성과 테스트가 가능하다. 예를 들어, 앱이 새로운 기능을 위해 iOS 16.0을 필요로 하더라도 iOS 15.0에서의 호환성을 유지하고 싶은 상황이 있을 수 있다. 이때, Xcode에서는 iOS 15.0에서도 정상적으로 빌드가 되게끔 처리하면서 실제 배포 시에는 16.0 이상의 버전만 지원하도록 제어할 수 있다.
이렇게 하면 새로운 API나 기능을 도입하면서도 기존의 더 낮은 iOS 버전을 지원하는 코드를 유지하거나 조건부 코드(if #available(iOS 16.0, *))를 추가하여 iOS 버전별로 동작을 다르게 구현할 수 있다.
프로젝트 안에 여러 타겟(Target)이 있을 수 있다. 예를 들어, 동일한 코드베이스에서 일반 사용자용 앱과 테스트용 앱을 따로 빌드할 때 각각의 타겟에 따라 지원하는 최소 iOS 버전이 다를 수 있다.
이때, 각 타겟마다 iOS Deployment Target을 따로 설정하여 타겟별 맞춤 설정이 가능하게 만들 수 있는 것이다. 즉, 타겟마다 테스트 환경이나 지원 버전을 다르게 설정할 수 있어 유연성을 극대화할 수 있다.
iOS Deployment Target vs Minimum Deployment
TIL
Xcode
Git에서 파일 크기 제한으로 인해 fatal: the remote end hung up unexpectedly 오류가 발생한 문제를 해결한 방법을 정리해보았습니다.

문제 상황

git push를 실행했을 때, fatal: the remote end hung up unexpectedly 오류가 발생했습니다. 이는 원격 저장소에서 허용하는 최대 파일 크기 또는 전체 push 크기 제한을 초과했기 때문에 발생한 오류였습니다.

해결 방법

이 문제를 해결하기 위해 Git의 http.postBuffer 설정을 변경하여 push 데이터를 압축하고 크기를 줄였습니다. 이 설정은 Git이 HTTP 프로토콜을 통해 데이터를 push할 때 사용하는 버퍼 크기를 조정해줍니다.
위 명령어를 실행하면 버퍼 크기가 500MB로 설정되어 push할 수 있는 데이터의 크기가 늘어나게 됩니다.
이 설정을 적용한 후, 다시 git push를 시도했을 때 오류 없이 성공적으로 원격 저장소에 데이터를 push할 수 있었습니다.

교훈

Git Push 시 파일 크기 제한 초과 오류 해결하기

Just

just 연산자는 단일 요소를 방출한 다음 완료되는 Observable을 생성한다. 매우 간단하고 직관적인 방식으로 단일 값을 Observable로 변환할 수 있게 해준다.
출력 결과
장점
•
단일 요소를 방출하기에 매우 간단한 연산자임. 이를 통해 특정 값 하나를 방출해야 할 때 직관적으로 사용할 수 있음.
•
단일 값을 방출하고 완료한다는 명확한 목적을 가지고 있기 때문에 코드를 읽기 쉬움.
•
항상 동일한 값과 동일한 순서로 동작하기 때문에 예측 가능성이 높아 테스트와 디버깅에 용이함.
단점
•
단일 값만 방출할 수 있기 때문에 여러 값을 방출해야 하는 경우에는 다른 연산자를 사용해야 함.
•
고정된 값만 방출할 수 있기 때문에 동적 데이터나 조건에 따른 데이터 방출에는 적합하지 않음.

Of

of 연산자는 여러 개의 요소를 순차적으로 방출하는 연산자이다. 주로 짧은 시퀀스를 테스트하거나 특정 값들을 한 번에 방출해야 할 때 유용하다.
RxSwift Operators #1: Creating Operators
TIL
RxSwift
Load more