Search

All Posts (45)

Search

 문제 요약

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

Subjects

Subjects는 Observable이자 Observer 역할을 한다. 따라서 Subject는 데이터를 방출(emit)하고 다른 Observable에서 데이터 이벤트를 받아들일 수 있다. RxSwift에서 제공하는 주요 Subject는 다음과 같다.
1.
Publish Subject
2.
Behavior Subject
3.
Replay Subject
4.
Async Subject

Relays

Relays는 RxCocoa에 포함되어 있으며 기본적으로 Subjects와 비슷하게 동작하지만 onCompleted나 onError 이벤트를 방출하지 않는다.

Publish Subject

Publish Subject는 새로운 구독자가 기존에 발행된 이벤트를 받을 수 없고 구독한 시점 이후의 이벤트만 받을 수 있다.
출력 결과
Publish Subject는 구독 시점 이후의 이벤트만 구독자에게 전달한다. 따라서 “Hello” 이벤트는 구독자가 없어서 아무도 받지 못했다. “World” 이벤트는 첫 번째 구독자가 수신했고 두 번째 구독자는 “World” 이벤트 이후에 구독했기 때문에 “RxSwift” 이벤트만 수신했으며 “RxSwift” 이벤트는 모든 구독자가 수신했다.
장점
Subject와 Relay
TIL
RxSwift

Decodable과 Encodable

Swift에서 데이터를 쉽게 처리할 수 있도록 Decodable과 Encodable 프로토콜이 제공됩니다. 이 두 프로토콜은 외부 데이터 형식과 Swift 데이터 타입 간의 변환을 단순화하며 Codable은 이 두 프로토콜을 모두 포함하는 타입 별칭입니다. 이번 글에서는 Decodable과 Encodable의 개념을 설명하고 왜 Codable을 사용하지 않고 Decodable을 사용했는지에 대해 예제 코드와 함께 살펴보겠습니다.

Decodable

JSON, XML 또는 다른 데이터 형식에서 Swift 타입으로 데이터를 변환하는 데 사용됩니다. 데이터를 받아와서 내부 모델로 변환하는 작업에서 활용됩니다.
예를 들어, 유튜브를 사용할 때 수많은 비디오 데이터를 서버로부터 불러와야 합니다. 유튜브 서버는 비디오 제목, 설명, 조회수 등의 정보를 JSON 형식으로 앱에 보냅니다. 이때, 앱은 이 JSON 데이터를 받아 내부에서 사용할 수 있는 데이터 모델로 변환해야 합니다. 이 과정에서 Decodable 프로토콜이 사용됩니다.

Encodable

Swift 타입을 JSON이나 XML 등의 외부 데이터 형식으로 변환하는 데 사용됩니다. 데이터를 외부에 전송하기 전에 필요한 형식으로 만드는 작업에서 활용됩니다.
예를 들어, 메모 앱에서 사용자가 메모를 작성하면 이 메모 데이터를 JSON 형식으로 인코딩하여 서버에 전송해야 합니다. 이 과정에서 Encodable 프로토콜이 사용됩니다.

Codable은 언제 사용하나요?

Codable은 Decodable과 Encodable을 모두 합친 타입 별칭으로, 한 데이터 모델에 대해 동시에 디코딩과 인코딩을 모두 수행해야 할 때 사용됩니다. 그래서 디코딩만 필요하거나 인코딩만 필요한 경우에는 굳이 사용할 필요가 없습니다. 만약 디코딩 또는 인코딩만 필요한데 Codable을 사용한다면 코드의 목적을 저해시키고 코드의 가독성이 떨어지게 됩니다. 예를 들어, 설정 앱에서 설정을 변경하고 이를 서버에서 저장해야 할 때 사용됩니다.
따라서 이번 프로젝트에서 GitHub Api로부터 저장소를 불러오는 기능만 들어갔기 때문에 Decodable을 사용하였고 MVVM 패턴을 적용하였습니다. 모델 코드부터 보도록 하겠습니다.

Model

깃허브 앱 만들기(with. RxSwift)
RxSwift
CodingKey
MVVM
Swift에서 API로부터 JSON 데이터를 받아와 앱 내에서 사용하기 위해 우리는 종종 Decodable 프로토콜을 구현하는 모델을 정의한다. 오늘은 Decodable 구현 시에 매우 유용한 CodingKeys 열거형에 대해 자세히 알아보고자 한다.

CodingKey란?

CodingKey는 Decodable 또는 Encodable 프로토콜을 사용할 때 JSON 키와 Swift 모델의 프로퍼티가 서로 일치하지 않을 경우 이를 연결하기 위해 사용하는 열거형이다. 예를 들어, 서버로부터 받은 JSON 데이터 내에는 stargazers_count라는 키가 있지만 Swift 코드 내에서는 stargazersCount라는 프로퍼티로 사용하고 싶은 경우가 이에 해당한다.

사용 예시

Repository라는 구조체를 정의하고 이를 Decodable 프로토콜에 따라 구현해보자. 이 구조체는 GitHub의 리포지토리 정보를 담고 있으며 다음과 같이 구성된다.
여기서 CodingKeys 열거형은 JSON 키 값인 stargazers_count를 Swift 모델의 stargazersCount 프로퍼티에 할당하도록 명시한다. 이런 방식은 데이터의 키와 프로퍼티 이름이 다를 때 유용하게 사용된다.

CodingKey 사용의 이점

•
명확성
•
유지보수성
•
타입 안정성
데이터와 모델 간의 연결이 명확해지므로 다른 개발자가 코드를 볼 때 이해하기 쉬우며 모델의 프로퍼티 이름이나 JSON 키가 변경되어도 쉽게 대응할 수 있다. 또, 컴파일 시점에 프로퍼티 매핑 오류를 발견할 수 있어 런타임 에러의 가능성을 줄여준다.

결론

Swift에서 JSON 키와 모델 프로퍼티 매핑하기 - CodingKey
TIL
CodingKey
부산에서 iMac으로 코딩할 수 있는 무료 강좌 이벤트가 개설되어 바로 부울경 iOS 단톡방에 공유했다 ㅋㅋ
그리고 레벨 1과 레벨 2가 있었는데 레벨 1은 기초적인 내용으로 초보자도 쉽게 들을 수 있는 레벨이었고 레벨 2는 배운 내용들을 토대로 나만의 명함을 만들 수 있다. 나는 둘 다 할 수 있다고 해서 모두 참여하기로 했다. 난이도가 굉장히 쉬워보였지만 참가하는 첫 번째 이유는 그곳에서 많은 사람들과 친해지고 싶었고 이야기를 나누고 싶어서이다. 두 번째는 나도 언젠간 부산, 울산, 경남권 지역에서 iOS 개발 커뮤니티를 크게 키우고 싶고 이런 교육이나 컨퍼런스도 주최해보고 싶기 때문이다. 세 번째 이유는 iMac을 사용해보고 싶었다 ^^
도착!! 앨리스랩에서 장소를 후원 받았다고 한다. 내부는 굉장히 깔끔했고 입구 오른쪽이 프로그래밍존이다. 오거나이저분이 왼쪽 광장 같은 곳에서 잠깐 대기하라고 하셨다.
빨리 들어가고 싶어요.. 기다리면서 리이오도 봤다. 인터넷 강의에서만 보던 분을 실제로 보니 신기했다. 10분 정도 기다리니 입장하라는 안내와 함께 짐을 챙겨 입장했고 가장 앞자리에 어떤 분 옆에 바로 착석했다:)
옆에 분과 간단히 인사를 나누고 어디서 왔는지, 대학생인지 등등 이것저것 물어봤다. 이 분은 수원에서 오셨고 입사한지 6개월된 신입이라고 하셨다. 그렇게 레벨 1 섹션이 시작되고 Playground에 있는 바이트라는 캐릭터를 이용해서 간단한 코딩하는 시간을 가졌다. 코드를 짜는데 옆에 분은 너무 쉬웠는지 금방금방 하셨고 조금 더 나아가 더욱 고도화된 코드를 작성하고 계셨다. 이 분도 나와 같이 네트워킹 목적으로 오신 것 같았다. 레벨 1이 끝나고 쉬는 시간을 가진 뒤 레벨 2가 시작되었다. 레벨 2는 레벨 1에 비해 더 난이도가 있었고 여기저기서 질문하는 소리가 들리기 시작했다. 그래도 코딩을 어느정도 한 경험이 있다면 쉽게 풀 수 있는 난이도였다. 모든 강좌가 끝나고 명함 만드는 시간이 찾아왔다. 나는 나의 강아지 사진을 프로필 사진으로 설정하였고 백그라운드 색은 인스타그램 느낌이 나도록 그라데이션 효과를 넣었다. 아래는 결과물이다.
코드를 작성하면서 가장 먼저 느낀 점은 iMac 정말 이쁘고 화질도 좋았다 ㅋㅋㅋ(선 뽑아서 집에 들고 가고 싶었다ㅎ) 그리고 텍스트를 커스텀하면서 중복되는 코드가 많았는데 UIKit처럼 함수로 만들어 코드의 중복을 줄이고 싶었지만 아직 SwiftUI를 잘 알지 못해 에러가 계속 떴다. 옆 분에게 물어보니 리턴 타입으로 some View를 작성하니 문제가 해결되었다. 나는 그 자리에서 바로 박수쳐주니 굉장히 쑥스러워 하셨다 ㅋㅋㅋㅋ 프로그래밍존을 벗어나 입구 왼쪽에 있는 광장? 같은 곳에서 자리를 잡고 네트워킹 시간을 가졌다. 다양한 지역에서도 오셨고 다양한 분야의 개발자들도 모인 자리였다. 시간 가는 줄도 모르고 즐겁게 이야기를 나눴고 서로 명함도 교환했는데 다들 잘 만드셨다. 아쉬운 점은 명함이 3장뿐이어서 모든 분들께 나누지 못해 아쉬웠다. 마지막으로 단체 사진을 찍고 그곳에서 만난 사람들과 함께 지하철역으로 이동했다. 교통카드를 찍으려는 순간 어떤 분께서 시간 괜찮으면 저녁 같이 먹자고 해서 바로 옆에 있는 신세계 백화점으로 향했다.
파스타, 피자, 샐러드, 스테이크를 시켰는데 스테이크가 너무 맛있었다. 밥을 먹으며 개발 이야기를 끊임없이 나눴고 내 옆 자리에 앉았던 분도 오셨는데 자신이 한 프로젝트를 소개해주었다. 대학교 셔틀버스가 언제 오는지 알려주는 프로그램을 만들었는데 엄청 잘 만들었고 지금도 정류장 뒤에 운영 중이다! 보면서 한국은 땅은 좁은데 천재들은 많다는 것을 느낄 수 있었다.
‘iMac으로 코딩 첫 걸음’ 회고
Retrospect
Load more