Kelly Dev

StackDay. 0. Concept

Sat, 08 Aug 2026 15:36:21 +0900

시작하기

애플 리마인더나 마이크로소프트 To do를 쓰면 매일 해야하는 일들을 관리할 수 있다.

나도 매일 LeetCode Daily를 풀고, Bing 출석체크를 하고, 매일 TIL 을 적으려고 한다.

하지만 기본적으로 Reminder, Todo 앱과 습관 형성 앱은 차이가 있다.

첫 번째로 기능 요구사항이 다르다. 애플 리마인더는 매일 반복해야 하는 태스크를 하지 않았을 경우에, 날짜가 새로 갱신되지 않고, 그 날짜에 계속 남아있는다. 마이크로소프트 To do는 하루를 빠뜨리면 그 태스크가 사라지지 않고 누적된다.

내가 원하는 습관 형성 앱은 리마인더의 방식, 마이크로소프트 투 두의 방식 등등을 포괄할 수 있는 앱이었다.

dev-data-server-light. 0. Concept

Wed, 24 Jun 2026 00:00:00 +0000

시작하기

iOS 프로젝트를 진행하다 보면 생각보다 자주 간단한 API 서버가 필요해진다. 회원가입 화면을 만들거나, 목록 조회 기능을 붙이거나, 이미지 업로드를 테스트할 때도 서버가 필요하다. 물론 실제 백엔드를 구축할 수도 있고, Supabase나 Firebase 같은 BaaS를 사용할 수도 있다. 하지만 작은 개인 프로젝트나 프로토타입 단계에서는 좋은 설계는 아니라고 생각한다.

특히 처음부터 특정 서비스에 의존하기 시작하면, 정작 내가 만들고 싶은 앱의 기능보다 인프라 설정과 서비스 사용법을 익히는 데 더 많은 시간을 쓰게 된다. 앱 개발을 위한 도구가 필요했는데, 어느 순간 도구를 사용하기 위한 공부를 하고 있는 상황이 되는 것이다.

JavaScript Basics. 01. 자바스크립트 기본 환경 설치 및 기본 문법

Sat, 31 May 2025 00:00:00 +0000

환경 설치

자바스크립트란?

HTML과 CSS와 함께 클라이언트 측 웹 프로그래밍을 할 수 있도록 돕는 프로그래밍 언어
C, C++, 자바와 같은 언어에 비해 문법이 쉽고 브라우저에서 바로 실행됨
조금만 배워도 HTML, CSS와 함께 바로 사용 가능

컴파일러 언어와 인터프리터 언어

자바스크립트는 인터프리터 언어로 작성과 동시에 바로 실행할 수 있는 언어이다.

프로그래밍은 일반적으로 컴파일러와 인터프리터라는 과정을 통하여 프로그래밍 진행
바로 작성한 프로그램을 확인할 수 있는 언어를 인터프리터 언어, 컴파일러 언어는 소스 코드를 기계어로 번역하는 과정이 필요함.

기반 환경 구축하기

ES6부터 CLI를 활용해야한다. node.js, npm, react, git등을 활용하려면 터미널을 활용해야 한다.

The Swift Programming Language. Functions (1)

Thu, 25 May 2023 00:00:00 +0000

Functions

함수는 특정 작업을 수행하는 독립적인 코드 덩어리이다. 함수에 이름을 지어서 그 함수가 무엇을 하는지를 나타내고, 필요할때 “호출(call)“할 수 있다.

스위프트의 함수는 파라미터의 이름이 없는 C-스타일 함수와 파라미터의 이름과 아규먼트 레이블이 모두 있는 Objective-C 스타일 함수를 동시에 표현할 수 있다. 파라미터는 디폴트 값을 가질 수 있고, 파라미터로 받아 값을 변경 시킬 수 있는 in-out 파라미터로도 전달 될 수 있다.

모든 함수는 파라미터들의 타입과 리턴 타입으로 이루어진 타입을 가지고 있다. 스위프트의 다른 타입들과 마찬가지로 다른 함수에 대한 파라미터로 이 타입을 전달 할 수 있고, 리턴 값으로 사용할 수도 있다. 또한 함수는 중첩할 수 있어 함수 내부에서 함수를 작성 하여 특정 기능에 대한 캡슐화를 할 수 있다.

StackDay. 엔티티와 계산 책임 분리하기

Wed, 12 Aug 2026 16:51:04 +0900

앞서 도메인, 데이터 모델링한 내용을 실제 코드로 옮기기 시작했다.

모델 자체의 구조는 이미 정해져 있었지만 코드로 구현하니 Habit Entry같은 파생 값들은 어디서 생성해야 하는지 책임이 정해지지 않았다.

Completion

먼저 습관을 수행했다는 사실을 기록하는 Completion을 구현했다.

struct Completion: Equatable {
 let id: UUID
 let habitID: UUID
 let completedOn: Date
 let recordedAt: Date
}

Completion은 저장되는 원본 데이터이므로 완료 사실을 표현하는 데 필요한 값만 가진다.

미래의 날짜인지, Habit의 시작일 이전인지, 같은 날짜의 Completion이 이미 존재하는지와 같은 검증은 Completion 하나만으로 판단할 수 없기 때문에 넣지 않았다.

StackDay. 데이터 모델링, Entry가 아닌 Completion을 관리해야 하는 이유

Tue, 11 Aug 2026 16:48:37 +0900

StackDay의 MVP 범위와 정책을 가지고 앱의 도메인과 데이터를 모델링한다.

도메인 모델링 -> 데이터 모델링 -> 유즈케이스 검증 순서로 진행하고, 각각의 단계가 이전 단계를 검증하는 방향이다.

앱의 핵심 동작

이전 포스트에서 정한 앱의 컨셉과 정책에서부터, 이 앱이 어떤 동작을 해야 할지 먼저 정리했다.

사용자가 습관을 만들면 그날부터 습관의 추적이 시작된다. 사용자는 매일 습관을 수행했는지 기록하고, 앱은 누적된 기록을 바탕으로 현재 스트릭과 통계를 보여준다. 더 이상 이어가지 않을 습관은 추적을 종료할 수 있다.

dev-data-server-light. 1. System

Thu, 25 Jun 2026 00:00:00 +0000

프로젝트에서 제일 간단한 기능과 구조를 가지기 때문에 가장 먼저 System 모듈을 만들었다.

System 모듈의 기능

System 모듈이 제공하는 기능은 단 두 가지뿐이다.

GET /system/status
GET /system/uptime

status는 서버가 정상적으로 동작하는지 알려주고, uptime은 서버가 실행된 이후 얼마나 시간이 지났는지를 반환한다.

비즈니스 로직도 없고, 데이터베이스도 필요하지 않으며, 파일 시스템도 다루지 않기 때문에 구조를 검증하는데 가장 좋다고 판단했다.

구조 검증

System 모듈을 만들면서 확인하고 싶었던 것은 기능이 아니라 구조였다. 당시에 생각했던 구조는 다음과 같았다.

JavaScript Basics. 02. 연산자와 명령문

Sun, 01 Jun 2025 00:00:00 +0000

기본 명령어

표현식

문장 표현식이 하나 이상 모일 경우, 마지막에 종결 의미로 세미콜론(;)

프로그램

문장이 모이면 프로그램이 됨
문장을 작성하고, 다음 줄에 문장을 작성하면 앞 문장 끝에 세미콜론이 없어도 자바스크립트 엔진이 자동으로 세미콜론 추가
- 자바스크립트 엔진이 세미콜론을 생략한 줄이 다음 줄과 이어지고 있다고 판단하면?
```
// 세미콜론을 안붙이면
c = a + b
(x + y).toString()
// 이렇게 해석될 수 있다
c = a + b(x + y).toString()
```

예악어

자바스크립트 문법을 규정짓기 위해 자바스크립트 언어 사양에서 사용하는 특수한 키워드는 식별자로 사용하지 않는 편이 좋다.

The Swift Programming Language. Functions (2)

Fri, 26 May 2023 00:00:00 +0000

Function Argument Labels and Parameter Names

함수의 파라미터들은 각각 아규먼트 레이블(Argument Labels)과 파라미터 이름(Parameter Names)을 가지고 있다. 아규먼트 레이블은 함수를 호출할 때 인자와 함께 사용되며, 파라미터 이름은 함수를 구현할 때 사용한다. 기본적으로, 파라미터 이름이 인자 레이블이 된다.

func someFunction(firstParameterName: Int, secondParameterName: Int) {
 // In the function body, firstParameterName and secondParameterName
 // refer to the argument values for the first and second parameters.
}
someFunction(firstParameterName: 1, secondParameterName: 2)

모든 파라미터들은 고유한 이름을 가져야 한다. 여러 개의 파라미터들이 같은 아규먼트 레이블을 가질 수도 있지만, 고유한 아규먼트 레이블을 사용하면 코드의 가독성이 증가한다.

dev-data-server-light. 2. Database CRUD

Tue, 30 Jun 2026 00:00:00 +0000

시스템 모듈을 만든 이후에, 아마도 가장 많이 쓰게 될 DB 모듈을 만들었다.

당시에는 구조도 시스템 모듈과 동일하다고 생각했다. Router가 DB 인터페이스에 의존하고, 이를 구현한 구현체를 주입받는 방식으로 DIP와 DI를 동시에 적용했다.

이 과정 중에서

naming bias 해결하기
id 생성 책임 위치
기존 아키텍처의 문제점 -> 서비스 레이어 도입해서 해결하기

에 대한 고민을 했다. 아래는 고민과 해결 과정이다.

CRUD부터 만들기

Mock Server라도 최소한 CRUD는 제공해야 한다. 처음부터 구현체를 만들 필요는 없으므로, 라우터와 인터페이스까지만 만들도록 프롬프트를 작성했다.

JavaScript Basics. 03. 자바스크립트 사용자 정의 자료형 활용

Sun, 01 Jun 2025 00:00:00 +0000

조건문

if 조건문

bool 표현식이 true이면 문장을 실행, false이면 문장을 무시

let input = 32;
if (input % 2 == 0) {
 console.log("짝수입니다!");
}
if (input % 2 == 1) {
 console.log("홀수입니다!");
}

let date = new Date();
if (date.getHours() < 12) {
 console.log("오전입니다.");
}
if (12 <= date.getHours()) {
 console.log("오후입니다.");
}

if else 조건문

조건이 합당하지 않은 경우의 표현식도 포함하는 조건문

let input = 32;
if (input % 2 == 0) {
 console.log("짝수입니다!");
} else {
 console.log("홀수입니다!");
}

let date = new Date();
if (date.getHours() < 12) {
 console.log("오전입니다.");
} else {
 console.log("오후입니다.");
}

중첩 조건문

조건문이 중첩된 형태

let date = new Date();
let hours = date.getHours();
if (hours < 11) {
 console.log("아침 먹을 시간입니다.");
} else {
 if (hours < 15) {
 console.log("점심 먹을 시간입니다.");
 } else {
 console.log("저녁 먹을 시간입니다.");
 }
}

if else if 조건문

중복되지 않는 세 가지 이상의 조건을 구분할 때 사용

The Swift Programming Language. Functions (3)

Sat, 27 May 2023 00:00:00 +0000

Function Types

모든 함수는 파라미터들의 타입들과 리턴 값의 타입으로 이루어진 특정한 함수 타입 을 가지고 있다.

func addTwoInts(_ a: Int, _ b: Int) -> Int {
 return a + b
}
func multiplyTwoInts(_ a: Int, _ b: Int) -> Int {
 return a * b
}

위의 예시에서 두 함수는 두 개의 정수 값을 받아 정수 값을 리턴한다. 두 함수 모두 (Int, Int) -> Int 타입이며, 이는 “두 개의 Int 타입 파라미터를 받아 Int 타입을 리턴하는 함수” 라는 의미이다.

파라미터와 리턴 값이 없는 함수의 예시이다.

func printHelloWorld() {
 print("hello, world")
}

이 함수의 타입은 () -> Void 이고 “파라미터가 없고 리턴값이 Void인 함수” 라는 의미를 가진다.

dev-data-server-light. 3. Database Implementation

Thu, 02 Jul 2026 00:00:00 +0000

DB 모듈의 인터페이스와 서비스 레이어를 만들었으므로, 실제 구현체를 만들어야 한다. 우선 인 메모리(In-Memory)로 가볍게 구현체를 만들었다.

인 메모리 데이터 저장소

인 메모리 방식을 선택한 이유는 첫째로 처음부터 SQL이나 JSON 파일 기반 저장소를 이용해서 구현체를 만드는 것 보다는, 가장 단순한 구현체를 만들어서 DB 기능을 검증하고 빠르게 다음 기능을 만들기 위해서이다. 외부 의존성도 없고, 설정도 필요 없고, 테스트도 쉽다.

구현하기

RecordStore 인터페이스를 다시 보면 다음과 같다.

export interface RecordStore {
 list(collection: string): Promise<StoredRecord[]>;
 get(collection: string, id: string): Promise<StoredRecord | undefined>;
 create(collection: string, data: RecordData): Promise<StoredRecord>;
 replace(collection: string, id: string, data: RecordData): Promise<void>;
 delete(collection: string, id: string): Promise<boolean>;
}

구현체는 이 계약을 그대로 만족하면 된다. 중요한 것은 구현체는 Express를 몰라야하고 순수하게 TypeScript 코드로 짜여야 한다. HTTP 요청이나 라우팅 같은 것은 Router가 책임져야 한다.

JavaScript Basics. 04. 자바스크립트 함수

Mon, 02 Jun 2025 00:00:00 +0000

함수 생성 방법

익명 함수

이름을 붙이지 않고 함수 생성

함수를 호출하면 함수 내부의 코드 덩어리가 모두 실행

let helloWorld = function() {
 console.log("Hello, World!");
;

helloWorld(); // 함수 호출
console.log(helloWorld); // 함수 자체를 호출

// Hello, World!
// f () {
// console.log("Hello, World!");
// }

선언적 함수

이름을 붙여 함수를 생성

function helloWorld() {
 console.log("Hello, World!");
}

helloWorld(); // 함수 호출
console.log(helloWorld); // 함수 자체를 호출

// Hello, World!
// f () {
// console.log("Hello, World!");
// }

화살표 함수

하나의 표현식을 리턴하는 함수를 만들 때는 중괄호 생략 가능

The Swift Programming Language. Closures (1)

Sun, 28 May 2023 00:00:00 +0000

Closures

클로저는 코드 내부에서 전달되고 사용할 수 있는 독립적인 코드 블록이다. 클로저는 C, Objective-C의 블록이나 다른 언어들의 lambda와 유사하다.

클로저는 자신이 정의된 컨텍스트에 있는 상수나 변수의 참조를 캡처하고 저장할 수 있다. 이를 캡쳐한 상수나 변수에 대한 클로징 오버(closing over)라고 한다. 이 경우에 스위프트가 모든 메모리 관리를 해준다.

함수(Function)는 클로저의 특수한 케이스이며, 클로저는 다음과 같은 세가지 형태가 있다.

어떠한 값도 캡처하지 않고, 이름이 있는 전역 함수
자신을 둘러 싼 함수 내부의 값을 캡처하고, 이름이 있는 중첩 함수
자신을 둘러싼 컨텍스트의 값을 캡처하고, 이름이 없는 클로저 표현식

일반적인 상황에서 다음과 같은 최적화를 통해서 클로저를 짧고 난잡하지 않게 만들 수 있다.

dev-data-server-light. 4. File Storage

Thu, 02 Jul 2026 00:00:00 +0000

DB 모듈을 마무리하고, 다음으로 구현한 것은 File Storage 모듈이다. DB 모듈과 크게 다르지 않을 것이라고 생각했다. 우선 CRUD 비슷한 메소드를 처리하고, 구조는 DB 모듈에서 충분히 다듬었기 때문이다. 하지만 실제로는 DB보다 인터페이스를 어떻게 정의할 것인지에 대한 고민이 더 많았다.

인터페이스 만들기

처음 작성한 프롬프트는 다음과 같다.

Create the initial FileStorage contract in src/storage.

Requirements:

- Define a FileStorage interface.
- The interface is responsible only for storing and retrieving binary file contents.
- It should not manage file metadata, ids, ownership, permissions, or database records.
- Use Buffer for file contents.
- Include only the minimal operations required for file storage:
 - save(path: string, content: Buffer): Promise<void>
 - read(path: string): Promise<Buffer>
 - delete(path: string): Promise<void>
 - exists(path: string): Promise<boolean>
- Add minimal domain errors if necessary.

For this step, create only the contract and related types.
Do not implement any storage implementation yet.

로컬 파일 시스템을 의식하고 있어서 의심 없이 path라는 이름을 사용했는데, 이 때문에 인터페이스가 구현체를 닮아버리게 되었다. path는 과연 인터페이스를 대표할 수 있는 네이밍인가?

JavaScript Basics. 05. 자바스크립트 내장 객체

Tue, 03 Jun 2025 00:00:00 +0000

객체

배열

기본 형태

let array = ['사과', '바나나', '망고', '딸기'];
array[0] // '사과'
array[1] // '바나나'

배열은 요소에 접근할 때 인덱스를 사용한다.

객체 기본

배열과 다르게 키를 통해서 접근하게 된다.

객체 선언

let product = {
 제품명: '7D 건조 망고',
 유형: '당절임',
 원산지: '필리핀'
};

console.log(product); // {제품명: '7D 건조 망고', 유형: '당절임', 원산지: '필리핀'}

객체 접근

product['제품명'] // '7D 건조 망고'
product['유형'] // 당절임
product['원산지'] // 필리핀
product.제품명 // '7D 건조 망고'
product.유형 // '당절임'
product.원산지 // '필리핀'

객체와 반복문

for in 반복문을 사용해 객체에 반복문을 적용

let object = {
 name: '바나나',
 price: 1200
};

for (let key in object) {
 console.log(`${key}: ${object[key]}`);
}

메소드

객체의 속성 중 자료형이 함수인 속성

The Swift Programming Language. Closures (2)

Mon, 29 May 2023 00:00:00 +0000

Capturing Values

클로저는 자신이 정의된 컨텍스트에서 상수나 변수를 캡처할 수 있다. 캡처한 상수나 변수가 정의되어있는 범위가 더 이상 존재하지 않아도 클로저의 본문에서 그 변수나 상수를 참조하고 수정할 수 있다.

스위프트에서 값을 캡쳐하는 가장 간단한 형태의 클로저는 중첩 함수이다. 중첩 함수는 외부 함수(둘러싸고 있는 함수)내부에 선언된 변수나 상수, 그리고 아규먼트를 캡처할 수 있다.

다음 예시는 incrementer라는 중첩 함수를 가지고 있는 makeIncrementer 함수의 예시이다. incrementer() 함수는 runningTotal과 amount 두개의 변수를 캡처한다. 이 값을 캡처한 다음에 incrementer는 호출될 때마다 amount만큼 runningTotal을 증가시키는 클로저가 되고, makeIncrementer에 의해 리턴 된다.

devbox-light-server (5). Auth

Sat, 08 Aug 2026 16:27:42 +0900

Auth 설계하기

개발용 목서버에서 실제 서비스 수준의 인증 시스템을 구현하지 않고도, 클라이언트에서 사용하는 로그인과 인증 흐름을 테스트할 수 있도록 Auth 기능을 추가했다.

로그인 요청을 보낸다.
access token을 발급받는다.
Authorization 헤더에 token을 실어 요청한다.
현재 로그인된 유저를 확인한다.
로그아웃으로 token을 무효화한다.

JWT, 비밀번호, OAuth, Refresh Token, 보안 같은 기능은 의도적으로 제외했다. 프로덕션 인증 로직을 구현하려는 글이 아니라, 개발용 Mock 서버에서 클라이언트의 로그인, 인증, 로그아웃 흐름을 확인하는 것이 목적이기 때문이다.

최소한의 Auth 구조

첫 단계에서는 DatabaseService를 그대로 사용했다. users 컬렉션을 만들어서 그 레코드 ID를 유저 ID로 사용해 로그인할 수 있도록 했다.

JavaScript Basics. 06. 브라우저 및 문서 객체

Fri, 06 Jun 2025 00:00:00 +0000

브라우저 객체 모델

웹 브라우저와 관련된 객체의 집합
대표적인 브라우저 객체 모델
- window, location, navigator, history, screen, document…

`window` 객체

브라우저 기반 자바스크립트의 최상위 객체

alert(), prompt()함수 모두 window 객체의 메소드
open(URL, name, features, replace)메소드를 통해서 window 객체 생성 가능
- URL: 열고자 하는 HTML 페이지의 URL
- name: 윈도우 간 통신하는 데 사용하는 윈도우 이름
- features: 윈도우 출력 모양을 지정하는 옵션
  - height: 새 윈도우의 높이
  - width: 새 윈도우의 너비
- replace: URL이 새로운 것인가, 기존의 문서를 대체할 것인가를 나타내는 부울리언 값
window 객체는 자신의 형태와 위치를 변경할 수 있도록 메소드 제공
- moveBy(x, y): 윈도우의 위치를 상대적으로 이동합니다.
- moveTo(x, y): 윈도우의 위치를 절대적으로 이동합니다.
- resizeBy(x, y): 윈도우의 크기를 상대적으로 지정합니다.
- resizeTo(x, y): 윈도우의 크기를 절대적으로 지정합니다.
- close(): 윈도우를 닫습니다.

`screen` 객체

웹 브라우저의 화면이 아닌 운영체제 화면의 속성을 가치는 객체

The Swift Programming Language. Closures (3)

Mon, 29 May 2023 00:00:00 +0000

Escaping Closures

클로저가 함수의 아규먼트로 전달이 됐는데, 함수가 리턴된 이후에 클로저가 호출되면 이를 함수를 탈출(escape)했다고 한다. 클로저를 파라미터로 받는 함수를 작성할 때, 파라미터의 타입 뒤에 @escaping을 작성해서 그 클로저가 탈출 가능하다는 것을 나타낼 수 있다.

클로저가 함수를 탈출하는 한가지 방법은 외부 변수에 저장되는 것이다. 예를 들어 많은 비동기 작업을 시작 하는 함수들은 클로저 아규먼트를 컴플리션 핸들러(completion handler)로 사용한다. 함수는 비동기 작업을 시작하고 리턴되지만, 클로저는 비동기 작업이 끝날때까지 호출되지 않는다. 따라서 나중에 호출되기 위해 탈출이 필요하다. 예를 들면:

devbox-light-server (6). Json 영속성

Mon, 10 Aug 2026 14:14:08 +0900

MVP의 마지막 기능으로 서버를 재시작해도 데이터가 사라지지 않도록 영속성을 추가했다.

이번 포스트에서는 devbox-light-server에 DB, Storage, Token Storage에서 영속성을 가진 저장 방식을 구현해서 in-memory 대신 사용할 수 있도록 만든다.

프로토타입이었던 dev-data-server에서는 시작부터 SQL 의존성을 가지고 시작했지만, devbox-light-server는 아주 얇은 in-memory 구현만 가지고 있다.

MVP 마지막에 영속성을 넣는 이유는 서버를 구현할 때, 특정 구현에 휘둘리지 않기 위해서다. dev-data-server에서 SQL을 빠르게 들여와서, 결국 프로젝트가 SQL 래퍼가 된 느낌이 있다.

당연히 Service 레이어는 Repository의 인터페이스에만 의존하므로 어떤 방법을 쓰든 단순히 구현체만 갈아 끼우고, 의존성 생성, 연결 부분을 제외하고는 어떠한 코드에도 변화가 없어야 한다.

JavaScript Basics. 07. 자바스크립트 예외처리 및 이벤트 처리

Mon, 09 Jun 2025 00:00:00 +0000

예외 처리

예외 → 실행에 문제가 발생하면 자동 중단됨
예외 처리 → 오류에 대처할 수 있게 하는 것

예외와 기본 예외 처리

TypeError 기본 예외 처리
- 사전에 해당 데이터가 undefined인지 조건문으로 확인

고급 예외 처리

try, catch, finally 구문

try {
 // 예외 발생
} catch (exception) {
 // 예외 처리
} finally {
 // 무조건 실행
}

catch구문, finally구문 생략 가능

예외 객체

예외가 발생하면 어떤 예외가 발생했는지 정보를 전달함, catch 구문의 괄호 안의 변수

The Swift Programming Language. Enumerations (1)

Tue, 30 May 2023 00:00:00 +0000

Enumerations

열거형은 연관된 값들을 공통된 타입으로 묶은 그룹이며, 타입 안전(type-safe)하게 사용하게 해준다.

스위프트의 열거형은 유연하다. 각 케이스에 값을 할당하지 않아도 되며, 스트링, 캐릭터, 정수, 실수등을 각 열거형 케이스에 제공할 수 있다.

스위프트에서 열거형은 그 자체로 일급 객체다. 컴퓨티드 프로퍼티(computed properties)나 인스턴스 메소드(instance method)와 같은, 기존에는 클래스에서만 사용할 수 있었던 많은 기능들을 가져왔고, 초기 케이스 값을 설정하는 이니셜라이저도 정의할 수 있으며, 프로토콜을 상속 받을 수도 있다.

Enumeration Syntax

열거형을 작성할 때는 enum 키워드를 사용하여 한 쌍의 중괄호 안에 작성한다.

devbox-light-server (7). Dockerizing, MVP 마무리

Mon, 10 Aug 2026 17:42:56 +0900

도커라이징

영속성까지 추가했으므로 이제 서버를 하나의 실행 단위로 묶을 차례다.

지금까지는 로컬에서 Node.js를 설치하고, 의존성을 설치하고, TypeScript를 빌드한 다음 서버를 실행했다. 혼자 개발할 때는 큰 문제가 없지만, 이 서버를 다른 환경에서 실행하려면 매번 같은 준비 과정을 반복해야 한다.

도커라이징은 이 과정을 이미지 안에 고정하는 작업이다. 이 프로젝트에서는 Express 서버를 빌드하고, 실행에 필요한 파일만 담은 뒤, .data 디렉터리를 기준으로 데이터를 유지할 수 있도록 구성했다.

Dockerfile 작성하기

Dockerfile은 두 단계로 나눴다.

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY tsconfig.json tsconfig.build.json ./
COPY src ./src
RUN npm run build

첫 번째 build 단계에서는 개발 의존성을 포함해서 설치하고 TypeScript를 빌드한다. npm run build를 실행하면 dist 디렉터리가 만들어진다.

JavaScript Basics. 08. 자바스크립트 API 활용 및 그림판 프로그램 만들기

Mon, 09 Jun 2025 00:00:00 +0000

API 활용

클라이언트 측 고유 기술 요소

웹브라우저에서 동작하는 자바스크립트를 클라이언트 측 자바스크립트라 함

클라이언트 측 자바스크립트 구성
- ECMAScript가 규정한 코어 언어와 웹 브라우저의 API(Application Program Interface)
웹 브라우저의 주요 API
- window 인터페이스
  - 자바스크립트로 브라우저 및 창을 제어하는 기능 제공
- DOM
  - 자바스크립트 HTML 문서의 요소를 제어하는 기능 제공
- XMLHttpRequest
  - 서버와 비동기로 통신하는 기능 제공

서버 측 자바스크립트의 고유 기술 요소

웹 서버에서 동작하는 자바스크립트

웹 서버를 구현하는데 Perl, PHP, Python, Ruby 등의 프로그래밍 언어를 이용

The Swift Programming Language. Enumerations (2)

Wed, 31 May 2023 00:00:00 +0000

Raw Values

Associated Values 섹션에서는 열거형의 케이스가 다른 타입의 연관값을 저장하는 방법을 보여줬다. 연관 값 대신, 열거형 케이스들은 같은 타입의 디폴트 값-원시 값(raw values)-을 미리 가지고 있을 수도 있다.

다음은 ASCII값을 원시값으로 사용하는 예시이다.

enum ASCIIControlCharacter: Character {
    case tab = "\t"
    case lineFeed = "\n"
    case carriageReturn = "\r"
}

열거형 ASCIIControlCharacter의 원시 값은 Character 타입으로 정의되어 있고, ASCII 제어 문자로 설정되어 있다.

원시 값은 어떠한 자료형이든 될 수 있으며, 각 원시 값은 열거형을 선언할 때 고유해야 한다.

The Swift Programming Language. Structures And Classes (1)

Thu, 01 Jun 2023 00:00:00 +0000

Structures and Classes

스트럭처와 클래스는 범용성 있는 유연한 구조이다. 상수, 변수, 함수를 작성하는 것 처럼 프로퍼티와 메소드를 작성하여 스트럭처와 클래스에 기능을 부여할 수 있다.

Comparing Structures and Classes

스트럭처와 클래스는 많은 공통점을 가지고 있다. 둘 다 다음과 행동을 할 수 있다.

값을 저장하기 위한 프로퍼티 정의
기능(functionality)을 위한 메소드 정의
서브스크립트 구문을 통하여 값에 접근할 수 있게 하는 서브스크립트 정의
초기 값을 설정하기 위한 이니셜라이저 정의
기본 구현보다 확장된 기능을 위한 확장성
특정 종류에 대한 표준 기능을 제공하는 프로토콜 준수

클래스는 스트럭처가 없는 추가 기능들이 있다.

The Swift Programming Language. Structures And Classes (2)

Thu, 01 Jun 2023 00:00:00 +0000

Structures and Enumerations Are Value Types

값 타입은 변수나 상수에 할당되거나 함수에 전달될 때, 값이 복사되는 타입이다. 스위프트의 정수, 실수, 부울, 문자열, 배열, 딕셔너리와 같은 기본 타입들은 모두 값 타입이고 실제로 스트럭처로 구현되어있다.

스위프트에서 모든 스트럭처와 열거형과 그 값 타입 프로퍼티들은 코드 안에서 복사되어 전달된다.

Note
배열, 딕셔너리, 문자열과 같은 콜렉션은 전달(혹은 할당)될 때, 즉시 복사되지 않고 수정 작업이 이루어졌을때 복사를 하는 최적화가 되어있다.

let hd = Resolution(width: 1920, height: 1080)
var cinema = hd

이 예시는 앞선 예시에 나온 스트럭처 Resolution의 상수 인스턴스 hd를 선언하고 프로퍼티를 초기화한다.

The Swift Programming Language. Properties (1)

Fri, 02 Jun 2023 00:00:00 +0000

Properties

프로퍼티는 특정 클래스, 스트럭처, 열거형에 값을 연관시킨다. 저장 프로퍼티는 변수나 상수의 값을 인스턴스의 일부로 저장하고, 컴퓨티드 프로퍼티는 값을 저장하기보다는 계산한다. 컴퓨티드 프로퍼티와 다르게, 저장 프로퍼티는 열거형에서 쓸 수 없다.

저장 프로퍼티와 컴퓨티드 프로퍼티는 인스턴스와 연결되는 반면, 다르게 타입 프로퍼티는 타입 그 자체에 연결된다.

추가로 프로퍼티 값의 변화를 모니터링 하고, 커스텀 액션으로 반응할 수 있는 프로퍼티 옵저버를 사용할 수도 있다. 프로퍼티 옵저버는 저장 프로퍼티에서 직접 정의하여 추가할 수 있으며, 서브클래스한태 상속된다.

The Swift Programming Language. Properties (2)

Fri, 02 Jun 2023 00:00:00 +0000

Property Observers

프로퍼티 옵저버(Property Observer)는 프로퍼티 값의 변화를 관측하고 반응한다. 프로퍼티 옵저버는 새로 설정된 값이 이전의 값과 같더라도, 프로퍼티의 값이 설정 될 때 마다 반응한다.

프로퍼티 옵저버는 다음의 위치들에 추가할 수 있다.

직접 정의한 저장 프로퍼티
상속받은 저장 프로퍼티
상속받은 컴퓨티드 프로퍼티

서브클래스에서 상속받은 프로퍼티를 오버라이드 하여 프로퍼티 옵저버를 추가할 수 있다. 직접 정의한 컴퓨티드 프로퍼티의 경우에는 setter를 사용하면 프로퍼티 옵저버를 사용하지 않고도 값의 변화를 관측하고 응답할 수 있다.

The Swift Programming Language. Properties (3)

Mon, 05 Jun 2023 00:00:00 +0000

Type Properties

인스턴스 프로퍼티는 특정 타입의 인스턴스에 속하는 프로퍼티이다. 새로운 인스턴스를 만들때 마다, 인스턴스는 다른 인스턴스와 구분되는 프로퍼티 집합이 생긴다.

인스턴스가 아닌 타입 자체에 속하는 프로퍼티도 있다. 이러한 프로퍼티를 타입 프로퍼티라고 하며, 얼마나 많은 그 타입의 인스턴스를 생성했느냐에 관련없이 단 하나만 존재한다.

타입 프로퍼티는 특정 타입의 모든 인스턴스들이 보편적으로 사용할 값을 정의할 때 유용하다. (C의 static이랑 유사하다)

Note
타입 그 자체는 이니셜라이저가 없기 때문에, 인스턴스 프로퍼티와 다르게 타입 프로퍼티는 저장 프로퍼티일 때 반드시 디폴트 값을 줘야한다.

The Swift Programming Language. Methods (1)

Tue, 06 Jun 2023 00:00:00 +0000

Methods

메소드는 특정 타입에 연관된 함수이다. 클래스, 스트럭처, 열거형은 인스턴스로 작업하기 위한 기능이나 작업은 캡슐화 하기 위해 인스턴스 메소드를 선언할 수 있고, 타입 그 자체에 연관된 타입 메소드도 선언할 수 있다.

Instance Methods

인스턴스 메소드는 특정 클래스, 스트럭처, 열거형에 속하는 함수이다. 인스턴스 프로퍼티에 접근, 수정하는 방법을 제공하거나 인스턴스의 목적에 맞는 기능을 제공하여 인스턴스가 기능을 가지게 한다. 인스턴스 메소드는 함수와 똑같은 구문을 사용한다.

인스턴스 메소드는 자신이 선언되어 있는 타입의 인스턴스 메소드나 타입에 암시적으로 접근 권한을 가지고 있다. 인스턴스 메소드는 자신이 선언되어 있는 타입의 인스턴스에서만 호출할 수 있으며, 밖에서 독립적으로 사용할 수 없다.

The Swift Programming Language. Methods (2)

Tue, 06 Jun 2023 00:00:00 +0000

Type Methods

이전에 설명했던 인스턴스 메소드는 특정 타입의 인스턴스가 호출한다. 타입 그 자체에 연관된 메소드는 타입 메소드라고하며, func 키워드 앞에 static 키워드를 작성하여 타입 메소드임을 나타낸다. 클래스는 서브클래스가 타입 메소드를 오버라이드 할 수 있도록 class 키워드를 대신 사용할 수 있다.

타입 메소드는 인스턴스 메소드처럼 닷 구문을 통해서 호출되지만, 인스턴스가 아닌 타입을 통해서 호출해야 한다. 다음은 클래스 SomeClass가 타입 메소드를 호출하는 예시이다.

class SomeClass {
 class func someTypeMethod() {
 // type method implementation goes here
 }
}
SomeClass.someTypeMethod()

타입 메소드의 본문에서 self 프로퍼티는 타입의 인스턴스가 아닌 타입 자체를 뜻한다. 따라서 인스턴스 메소드처럼 이를 통해 타입 프로퍼티와 타입 메소드 프로퍼티를 구분할 수 있다.

The Swift Programming Language. Subscripts (1)

Wed, 07 Jun 2023 00:00:00 +0000

Subscripts

클래스, 스트럭처, 열거형은 컬렉션, 리스트, 시퀀스에서 요소에 접근할 때 사용하는 서브스크립트를 정의할 수 있다. 서브스크립트는 별도의 메소드 없이 인덱스로 값을 설정하거나 검색할 수 있다. 예를 들면, 배열 인스턴스에서 요소에 접근할 때, someArray[index]와 같이 사용하고, 딕셔너리에서 someDictionary[key]처럼 사용하는 것이 서브스크립트다.

하나의 타입에 여러 개의 서브스크립트를 정의할 수 있다. 이러한 경우에는 서브스크립트에 전달되는 인덱스의 타입에 따라 적절한 서브스크립트가 선택된다. 또한 서브스크립트는 단일 차원으로 한정되지 않고, 다수의 파라미터를 받는 서브스크립트를 정의할 수 있다.

The Swift Programming Language. Subscripts (2)

Wed, 07 Jun 2023 00:00:00 +0000

Subscript Options

서브스크립트는 파라미터의 수와 타입에 제한없이 받을 수 있으며, 리턴 값도 타입에 제한이 없다.

함수처럼 서브스크립트는 가변 파라미터를 받고, 디폴트 값을 설정해줄 수 있다. 그러나 함수와 다르게 in-out 파라미터는 사용할 수 없다.

클래스나 스트럭처는 필요한 수만큼 서브스크립트를 제공할 수 있고, 대괄호 안에 전달된 값의 타입에 따라서 적합한 서브스크립트를 추론한다. 서브스크립트를 여러개 정의하는 것을 서브스크립트 오버로딩 이라고도 한다.

서브스크립트는 하나의 파라미터를 받는 것이 일반적이지만, 필요한 경우 여러개의 파라미터를 받도록 정의할 수도 있다. 아래의 예시는 Double 타입 2차원 행렬을 나타내는 Matrix 스트럭처를 정의한다. Matrix 스트럭처의 서브스크립트는 두 개의 정수 파라미터를 받는다.

The Swift Programming Language. Inheritance (1)

Thu, 08 Jun 2023 00:00:00 +0000

Inheritance

클래스는 메소드, 프로퍼티등 클래스의 특성들을 다른 클래스에서 상속 받을 수 있다. 한 클래스가 다른 클래스로부터 상속을 받았을 상속 받은 클래스를 서브클래스 라고 하고, 상속 해준 클래스를 슈퍼클래스 라고 한다. 상속은 클래스가 다른 타입들과 구별되는 중요한 특성이다.

스위프트에서 서브클래스는 슈퍼클래스의 메소드, 프로퍼티, 서브스크립트를 접근하고, 호출할 수 있다. 그리고 이러한 메소드, 프로퍼티, 서브스크립트를 오버라이딩 하여 자신에 적합하게 동작을 수정할 수도 있다. 스위프트는 오버라이드한 정의가 슈퍼 클래스의 정의에 매치되는지 확인함으로써 오버라이드가 정확하게 되도록 도와준다.

The Swift Programming Language. Inheritance (2)

Thu, 08 Jun 2023 00:00:00 +0000

Overriding

서브클래스는 상속 받을 수 있는 인스턴스 메소드, 타입 메소드, 인스턴스 프로퍼티, 타입 프로퍼티, 서브스크립트에 자신만의 커스텀 구현을 할 수 있다. 이것을 오버라이딩 이라고 한다.

상속될 수 있는 특성을 오버라이드 하려면, 오버라이드를 하고 있는 정의 앞에 override 키워드를 붙인다. 이렇게 하면 실수로 중복 정의를 한 것이 아닌 오버라이드 했다는 것을 명확하게 보여줄 수 있다. 실수로 오버라이드 하는 것은 예측하지 못한 결과를 가져온다. 따라서 override 키워드 없이 오버라이드를 하면 컴파일할 때 에러로 검출된다.

The Swift Programming Language. Initialization (1)

Tue, 13 Jun 2023 00:00:00 +0000

Initialization

이니셜라이제이션(Initialization) 은 클래스, 스트럭처, 열거형의 인스턴스를 사용하기 위해 준비하는 프로세스다. 이 프로세스는 인스턴스의 각 저장 프로퍼티에 초기 값을 설정하고, 인스턴스가 사용될 준비가 되기 전에 필요한 초기 설정을 하는 작업이 포함된다.

이니셜라이제이션은 특정 타입의 새로운 인스턴스를 만들기 위해 호출하는 특별한 메소드인 이니셜라이저를 정의함으로써 구현할 수 있다. Objective-C의 이니셜라이저와 다르게 스위프트의 이니셜라이저는 값을 리턴하지 않는다. 이니셜라이저의 가장 중요한 역할은 새 인스턴스가 처음으로 사용되기 전에 정확하게 초기화 되는 것을 보장하는 것이다.

The Swift Programming Language. Initialization (2)

Wed, 14 Jun 2023 00:00:00 +0000

Default Initializers

스위프트는 모든 프로퍼티에 디폴트 값을 제공하며, 이니셜라이저를 하나도 가지고 있지 않은 클래스나 스트럭처에게 디폴트 이니셜라이저 를 제공한다. 디폴트 이니셜라이저는 모든 프로퍼티가 디폴트 값으로 설정된 새로운 인스턴스를 만든다.

이 예시는 쇼핑 리스트에 있는 품목의 이름, 수량, 구매 여부를 캡슐화한 ShoppingListItem 클래스를 정의한다.

class ShoppingListItem {
 var name: String?
 var quantity = 1
 var purchased = false
}
var item = ShoppingListItem()

ShoppingListItem 클래스의 모든 프로퍼티가 디폴트 값을 가지고 있고, 슈퍼클래스가 없는 베이스 클래스이기 때문에, ShoppingListItem 클래스는 자동적으로 디폴트 이니셜라이저를 가지게 된다.(name 프로퍼티는 옵셔널 프로퍼티이기 때문에 디폴트 값을 주지 않아도 자동적으로 nil이 자동적으로 디폴트 값이 된다) 위의 예시에서 디폴트 이니셜라이저를 이용해 ShoppingListItem의 새 인스턴스를 만든다.

The Swift Programming Language. Initialization (3)

Fri, 16 Jun 2023 00:00:00 +0000

Initializer Inheritance and Overriding

Objective-C의 서브클래스와 다르게 스위프트의 서브클래스는 기본적으로 슈퍼클래스의 이니셜라이저를 상속받지 않는다. 이러한 스위프트의 접근방식은 슈퍼클래스에서 상속받은 간단한 이니셜라이저가 서브클래스의 완전히 초기화 되지 않은 새 인스턴스를 만드는 것을 방지한다.

Note
슈퍼클래스의 이니셜라이저는 특정 상황에서는 상속되지만, 안전하고 적합할 때만 상속된다. 자세한 내용은 아래의 Automatic Initializer Inheritance에 나온다.

서브클래스가 하나 이상의 슈퍼클래스와 동일한 이니셜라이저를 가지고 있으려면, 서브클래스 내부에 직접 구현하여 제공할 수 있다.

슈퍼클래스의 데지그네이티드 이니셜라이저와 일치하는 이니셜라이저를 서브클래스에 작성할 때, 그 데지그네이티드 이니셜라이저의 오버라이드를 효과적으로 제공할 수 있다. 그러므로 반드시 서브클래스의 이니셜라이저의 정의 앞에 override를 작성해야 한다. 자동적으로 제공된 디폴트 이니셜라이저라도 마찬가지다.

The Swift Programming Language. Initialization (4)

Sat, 17 Jun 2023 00:00:00 +0000

Failable Initializers

이니셜라이제이션이 실패할 수 있는 클래스, 스트럭처, 열거형을 정의하는 것이 유용하게 쓰일 때가 있다. 유효하지 않은 파라미터 값, 필요한 외부 리소스의 부재, 이니셜라이제이션이 실패해야하는 조건 등으로 이러한 실패를 트리거할 수 있다.

실패할 수 있는 이니셜라이제이션 조건을 다루기 위해서는, 하나 이상의 실패 가능한(failable) 이니셜라이저를 클래스, 스트럭처, 열거형의 정의의 한 파트로 정의한다. 실패 가능한 이니셜라이저는 init 키워드 뒤에 ?를 붙여서 표시할 수 있다.(init?)

Note
동일한 타입과 이름을 가진 파라미터들로 실패 가능한 이니셜라이저와 실패 불가능한 이니셜라이저를 동시에 정의할 수 없다.

The Swift Programming Language. Deinitialization

Sun, 18 Jun 2023 00:00:00 +0000

Deinitialization

디이니셜라이저는 클래스의 인스턴스가 할당 해제되기 전에 직전에 호출된다. 이니셜라이저가 init 키워드를 사용하여 작성하는 것 처럼, deinit 키워드를 사용하여 디이니셜라이저를 작성할 수 있다. 디이니셜라이저는 클래스 타입에만 사용 가능하다.

How Deinitialization Works

스위프트는 인스턴스가 더 이상 필요하지 않을때, 자동적으로 할당을 해제해여 리소스를 확보한다. 스위프트는 automatic reference counting (ARC)를 통해 메모리를 관리한다. 일반적으로 인스턴스가 할당 해제될때 수동적으로 처리를 해줄 필요가 없다. 하지만 자체적인 리소스로 작업을 할 경우에는, 수동으로 추가적인 처리를 해줘야 하는 경우가 있다. 예를 들면, 파일을 열고 거기에 데이터를 작성하는 커스텀 클래스가 있을 때, 그 클래스의 인스턴스가 할당 해제되기 전에 파일을 먼저 닫아줘야 한다.

The Swift Programming Language. Optional Chaining (1)

Mon, 19 Jun 2023 00:00:00 +0000

Optional Chaining

옵셔널 체이닝은 nil일 수도 있는 프로퍼티, 메소드, 서브스크립트를 호출하고 쿼리하는 프로세스이다. 만약 옵셔널에 값이 있다면, 프로퍼티, 메소드, 서브스크립트 호출은 성공하고, nil이라면 프로퍼티, 메소드, 서브스크립트 호출은 nil을 리턴한다. 다수의 쿼리를 하나의 체인으로 엮을 수 있으며, 그중 하나라도 nil값을 가진다면 전체적인 체인은 안전하게 실패한다.

Optional Chaining as an Alternative to Forced Unwrapping

호출하고자 하는 프로퍼티, 메소드, 서브스크립트가 nil이 아니라면, 옵셔널 값 뒤에 물음표(?)를 붙여 옵셔널 체이닝을 특정할 수 있다. 이것은 옵셔널 값 뒤에 느낌표(!)를 붙여 강제 언래핑을 하는 것과 매우 비슷하다. 가장 큰 차이점은, 옵셔널 체이닝은 만약 옵셔널이 nil이라면 안전하게 실패하고, 강제 언래핑은 옵셔널이 nil이면 런타임 에러를 발생시킨다.

The Swift Programming Language. Optional Chaining (2)

Tue, 20 Jun 2023 00:00:00 +0000

Linking Multiple Levels of Chaining

다중 레벨의 옵셔널 체이닝을 서로 연결하여 모델 내부의 프로퍼티, 메소드, 서브스크립트로 깊게 내려갈 수 있다. 하지만 다중 레벨 옵셔널 체이닝은 리턴된 값에 옵셔널 단계를 증가시키지 않는다.(주: 옵셔널 체이닝을 하면 항상 옵셔널 값이 리턴되는데, 옵셔널 체이닝 여러개를 합친다 해서 이중 옵셔널, 삼중 옵셔널이 되지 않는다는 뜻)

다른말로 설명하자면:

옵셔널이 아닌 값을 검색하려고 시도하면, 옵셔널 체이닝 때문에 옵셔널 값이 된다.
옵셔널 값을 검색하려고 시도하면, 체이닝 때문에 옵셔널이 추가되지 않는다.

그러므로:

The Swift Programming Language. Error Handling (1)

Wed, 21 Jun 2023 00:00:00 +0000

Error Handling

에러 핸들링은 프로그램이 에러 상황에서 응답하고 회복하는 프로세스이다. 스위프트는 런타임에 복구 가능한 에러를 던지고(throwing), 포착하고(catching), 전파하고(propagating), 조정하는(manipulating)데 최적화된 지원을 해준다.

일부 연산들은 항상 실행을 마치거나 의미있는 결과를 생성하는 것을 보장하지 않는다. 옵셔널은 값의 부재를 나타내는 사용되자만, 연산이 실패한 경우에는 코드가 그에 응답할 수 있도록 실패한 이유를 아는 것이 유용하다.

예를 들면, 디스크에 저장되어있는 파일을 읽고 처리하는 작업을 생각해보자. 이 작업에는 특정 경로에 없는 파일을 포함하거나, 파일에 대한 읽기 권한이 없거나, 파일을 호환 가능한 포맷으로 인코딩 하지 못하는 등의 수많은 실패 요소들이 있다. 이러한 상황들을 구분하면, 프로그램이 해결할 수 있는 에러는 해결하고, 해결 불가능한 에러는 사용자들에게 알릴 수 있다.

The Swift Programming Language. Error Handling (2)

Thu, 22 Jun 2023 00:00:00 +0000

Handling Errors Using Do-Catch

do-catch 문을 사용하면 코드 블록을 실행해서 에러를 처리할 수 있다. 에러가 do절에서 발생하면, 그 에러를 처리할 수 있는 catch절과 매치된다.

다음은 do-catch문의 일반적인 형태이다.

do {
 try expression
 statements
} catch pattern {
 statements
} catch pattern where condition {
 statements
} catch pattern, pattern where condition {
 statements
} catch {
 statements
}

catch절 뒤에 (에러의) 패턴을 작성하여, 그 catch절이 처리할 수 있는 에러를 나타낸다. catch절이 패턴을 가지고 있지 않다면, 이 catch절은 모든 에러와 매치될 수 있으며, error라는 이름을 가진 로컬 상수에 바인딩 된다.

The Swift Programming Language. Concurrency (1)

Fri, 23 Jun 2023 00:00:00 +0000

Concurrency

스위프트는 구조화된 방식의 비동기적이고 병렬 수행되는 코드 작성에 대한 지원이 내장되어있다. 비동기(Asynchronuous) 코드는 일시중단 되었다가 나중에 재개할 수 있지만, 한번에 프로그램의 한 부분만 실행된다. 프로그램에서 코드를 중단하고 재개하면 네트워크에서 데이터를 불러오거나, 파일 파싱과 같은 긴 시간이 걸리는 작업을 계속 진행하면서 UI 업데이트와 같은 짧은 시간이 걸리는 작업을 계속할 수 있다. 병렬 코드(Parallel code) 는 동시에 실행되는 코드들을 의미한다 — 예를 들어 4코어 프로세서를 가진 컴퓨터는 각각의 코어가 코드 하나씩을 실행하게 하여, 네 개의 코드를 동시에 실행할 수 있다. 병렬과 비동기 코드를 사용하는 프로그램은 한번에 여러 작업을 수행하고, 외부 시스템을 기다리는 작업을 일시 중단한다. 이 챕터의 나머지 부분에서 용어 동시성(concurrency) 는 비동기 및 병렬 코드를 지칭한다.

The Swift Programming Language. Concurrency (2)

Mon, 26 Jun 2023 00:00:00 +0000

Asynchronous Sequences

이전 섹션의 listPhotos(inGallery:) 함수는 모든 배열의 원소들이 준비된 후, 비동기적으로 전체 배열을 리턴한다. 다른 접근 방법으로는 비동기 시퀀스(asynchronous Sequence) 를 사용하여 컬렉션의 요소 하나를 한 번에 하나씩 기다리는 것이다. 다음은 비동기 시퀀스를 반복하는 모습이다.

import Foundation

let handle = FileHandle.standardInput
for try await line in handle.bytes.lines {
 print(line)
}

일반적인 for-in 루프를 사용하는 대신에, 위의 예시는 for 다음에 await를 작성한다. 비동기 함수나 메소드를 호출할 때 처럼 await를 쓰는 것은 정지 가능한 지점을 나타낸다. for-await-in 루프는 각 반복이 시작될 때, 다음 원소가 준비될 때 까지 기다리는 동안 실행을 정지한다.

The Swift Programming Language. Concurrency (3)

Mon, 26 Jun 2023 00:00:00 +0000

Actors

태스크를 이용하여 프로그램을 분리된 동시성 조각으로 나눌 수 있다. 태스크는 서로 독립적이기 때문에 동시에 실행되어도 안전하다. 하지만 가끔씩 태스크들 사이에 정보를 공유해야 하는 경우가 있다. 액터는 동시성 코드 사이에 정보를 안전하게 공유하도록 해준다.

클래스처럼 액터는 레퍼런스 타입이다. 따라서 Classes Are Reference Types에서 값 타입과 레퍼런스 타입을 비교한 것이 액터에도 적용된다. 클래스와 다르게, 액터는 한번에 하나의 작업만 변경 가능한 상태(mutable state)에 접근하도록 허용하기 때문에, 여러 태스크가 액터의 한 인스턴스에 상호작용하는 것을 안전하게 해준다. 예를 들어 다음은 온도를 기록하는 액터이다.

The Swift Programming Language. Macro (1)

Thu, 14 Aug 2025 00:00:00 +0000

매크로는 컴파일할 때 소스 코드를 변환하여, 반복적인 코드를 직접 작성하지 않게 해준다. 컴파일하는 동안, Swift는 평상시처럼 코드를 빌드하기 전에 매크로들을 확장한다.

매크로를 확장하는 것은 항상 추가하는(additive) 작업이다: 매크로는 새로운 코드를 더하지만, 기존에 존재하는 코드를 삭제하거나 수정하지 않는다.

매크로 입력과, 매크로 확장의 출력 둘 다 구문적으로 유효한 Swift 코드인지 체크된다. 마찬가지로, 매크로에 전달되는 값과 매크로로 생성된 코드 안의 값이 정확한 타입인지 검사된다. 추가적으로, 매크로를 확장할 때 구현부에서 에러를 마주치면, 컴파일러는 이를 컴파일 에러로 처리한다. 이러한 보장은 매크로를 사용하는 코드를 더 쉽게 이해하게 해주고, 매크로를 잘못 사용하거나 매크로의 구현에 버그가 있는 이슈들을 더 쉽게 알아차리게 해준다.

The Swift Programming Language. Macro (2)

Fri, 15 Aug 2025 00:00:00 +0000

Macro Expansion

매크로를 사용한 Swift 코드를 빌드 할 때, 코드를 확장하기 위해 매크로의 구현을 불러오게 된다.

구체적으로 Swift는 다음과 같은 방법으로 매크로를 확장한다:

컴파일러가 코드를 읽어, 구문의 in-memory 표현을 만든다.
컴파일러가 이 in-memory 표현의 일부를 매크로를 확장시키는 매크로 구현부에 보낸다.
컴파일러가 매크로 호출을 확장된 형태로 대체한다.
컴파일러가 확장된 소스 코드를 사용하여 컴파일을 계속 진행한다.

구체적인 단계들을 살펴보기 위해, 다음을 생각해보자:

let magicNumber = #fourCharacterCode("ABCD")

#fourCharacterCode 매크로는 4개의 캐릭터로 구성된 문자열을 받아, 그 문자열의 ASCII 값들을 이어 붙인 32비트 언사인드 인티저를 리턴한다. 일부 파일 포맷은 데이터를 식별하기 위해 이런 형태의 인티저를 사용하는데, 컴팩트 하면서도 디버거에서 읽을 수 있기 때문이다. 아래의 Implementing a Macro 섹션에서 이 매크로를 구현하는 방법을 보여준다.

The Swift Programming Language. Type Casting

Tue, 27 Jun 2023 00:00:00 +0000

Type Casting

타입 캐스팅(Type casting)은 인스턴스의 타입을 체크하거나, 해당 클래스가 소속된 계층의 다른 슈퍼클래스나 서브클래스로 취급하는 방법이다.

스위프트의 타입 캐스팅은 is 혹은 as 연산자로 구현된다. 이 두 연산자는 값의 타입을 체크하거나, 다른 타입으로 값을 캐스트하는 간단하고 표현적인 방법을 제공한다.

타입이 프로토콜을 준수하고 있는지 여부를 확인하기 위해 타입 캐스팅을 사용할 수도 있다.

Defining a Class Hierarchy for Type Casting

클래스와 서브클래스들의 계층에서 특정 클래스의 타입을 체크하거나 그 클래스의 인스턴스를 같은 계층의 다른 클래스로 캐스트할 때 사용할 수 있다. 아래의 코드 세 개는 앞으로 나올 예시들에서 쓰일 클래스의 계층과, 이 클래스들의 인스턴스를 담고 있는 배열을 정의한다.

The Swift Programming Language. Nested Types

Wed, 28 Jun 2023 00:00:00 +0000

Nested Types

열거형은 특정 클래스나 스트럭처의 기능을 지원하도록 자주 생성된다. 비슷한 이유로, 클래스나 스트럭처를 복잡한 컨텍스트 내부에서 순수하게 유틸 용도로 사용하기 위해 정의할 수도 있다. 이를 위해 스위프트에서는 중첩 타입(nested types) 을 정의할 수 있다. 중첩 타입을 지원하는 타입의 정의 내부에서 중첩 열거형, 클래스, 스트럭처를 중첩시킬 수 있다.

Nested Types in Action

아래의 예시는 블랙잭 카드 게임에서 사용하는 플레잉 카드를 모델링하는 BlackjackCard라는 스트럭처를 정의한다. BlackjackCard 스트럭처는 두 개의 중첩 열거형 타입 Suit와 Rank를 가지고 있다.

The Swift Programming Language. Extensions (1)

Thu, 29 Jun 2023 00:00:00 +0000

Extensions

익스텐션(Extensions)은 이미 존재하는 클래스, 스트럭처, 열거형, 프로토콜에 새로운 기능을 추가한다. 이는 원본 코드에 접근할 수 없는 타입(retroactive modeling 라고도 함)에 대한 확장도 가능하다.

스위프트의 익스텐션은 다음과 같은 행동을 할 수 있다.

컴퓨티드 인스턴스 프로퍼티 혹은 컴퓨티드 타입 프로퍼티 추가
인스턴스 메소드 혹은 타입 메소드 정의
새로운 이니셜라이저 제공
서브스크립트 정의
새로운 중첩 타입 정의 및 사용
이미 존재하는 타입이 프로토콜 준수하도록 함

스위프트에서는 프로토콜도 확장(extend)하여 요구사항 구현을 제공하거나, 그 프로토콜을 준수하고 있는 타입들이 사용할 수 있는 추가 기능을 제공할 수도 있다.

The Swift Programming Language. Extensions (2)

Thu, 29 Jun 2023 00:00:00 +0000

Methods

익스텐션은 이미 존재하는 타입에 새 인스턴스 메소드와 타입 메소드를 추가할 수 있다. 다음의 예시는 새 인스턴스 메소드 repetitions을 Int 타입에 추가한다.

extension Int {
 func repetitions(task: () -> Void) {
 for _ in 0..<self {
 task()
 }
 }
}

repetitions(task:) 메소드는 하나의 () -> Void 타입 아규먼트를 받는다.

이 익스텐션을 정의한 후에는 repetitions(task:)메소드를 어떠한 정수에서도 호출할 수 있다.

3.repetitions {
 print("Hello!")
}
// Hello!
// Hello!
// Hello!

Mutating Instance Methods

익스텐션에서 추가된 인스턴스 메소드는 인스턴스 자체를 수정(mutate)할 수도 있다. self나 self의 프로퍼티를 수정하는 스트럭처나 열거형은 메소드도 기존 구현의 뮤테이팅 메소드처럼 반드시 mutating으로 지정되어야 한다.

The Swift Programming Language. Protocols (1)

Fri, 30 Jun 2023 00:00:00 +0000

Protocols

프로토콜(protocol) 은 특정 작업이나 기능에 적합한 메소드, 프로퍼티, 기타 요구사항에 대한 청사진을 정의한다. 프로토콜은 해당 요구사항들을 실제로 구현하기 위해 클래스, 스트럭처, 열거형에서 도입할 수 있다. 프로토콜의 요구사항들을 만족하는 타입을 프로토콜을 준수한다고(conform) 말한다.

프로토콜을 준수하고 있는 타입이 반드시 구현해야하는 요구사항을 지정하는 것 외에도, 프로토콜을 확장하여 이러한 요구사항들의 일부를 구현하거나, 그 프로토콜을 준수하고 있는 타입이 사용할 수 있는 기능을 추가할 수 있다.

Protocol Syntax

프로토콜은 클래스, 스트럭처, 열거형과 매우 비슷한 방법으로 정의한다:

The Swift Programming Language. Protocols (2)

Sat, 01 Jul 2023 00:00:00 +0000

Protocols as Types

프로토콜은 어떠한 기능도 실제로 구현하지는 않는다. 하지만 코드에서 프로토콜을 타입으로 사용할 수 있다.

프로토콜을 타입으로 사용하는 가장 일반적인 방법은 프로토콜을 제네릭 제약조건(generic constraint)로 사용하는 것이다. 제네릭 제약조건이 있는 코드는 프로토콜을 준수하는 모든 타입에서 사용할 수 있으며, 특정 타입은 API를 사용되는 코드에서 선택된다. 예를 들어 제네릭 아규먼트를 받는 함수를 호출하면, 호출자가 타입을 선택한다.

불투명한 타입(opaque type)의 코드는 프로토콜을 준수하는 일부 타입에서 동작한다. 실제 타입은 컴파일 타임에 알수 있고, API 구현은 그 타입을 선택하지만 그 타입의 식별자는 클라이언트에게 숨겨져 있다. 불투명한 타입을 사용하는 것은 추상화 레이어를 통해 API의 디테일한 구현이 유출되는 것을 방지하게 해준다. — 예를 들어, 함수의 지정된 리턴 타입을 숨기고, 리턴 값의 타입이 주어진 프로토콜을 준수한다는 것만을 보장하게 한다.

The Swift Programming Language. Protocols (3)

Sun, 02 Jul 2023 00:00:00 +0000

Adding Protocol Conformance with and Extension

새로운 프로토콜을 도입하고 준수하기 위해 이미 존재하는 타입을 확장할 수 있다. 그 타입의 원본 소스코드에 접근하지 못하더라도 가능하다. 익스텐션은 이미 존재하는 타입에 새로운 프로퍼티, 메소드, 서브스크립트를 추가할 수 있으므로, 프로토콜에서 요구하는 모든 요구사항들을 추가할 수 있다.

Note
타입의 이미 존재하는 인스턴스는 인스턴스의 타입의 익스텐션에 프로토콜 준수가 추가되었을 때, 자동적으로 프로토콜을 준수하게 된다.

예를 들어, TextRespresentable 프로토콜은 텍스트로 표현할 수 있는 방법이 있는 모든 타입에서 구현 가능하다:

The Swift Programming Language. Protocols (4)

Mon, 03 Jul 2023 00:00:00 +0000

Protocol Composition

하나의 타입이 여러개의 프로토콜을 동시에 준수하도록 하는 것이 유용할 때가 있다. 프로토콜 구성(protocol composition) 을 통해 여러 개의 프로토콜을 하나의 프로토콜로 결합할 수 있다. 프로토콜 구성은 내부에 있는 모든 프로토콜의 요구사항을 결합한 임시 로컬 프로토콜을 정의한 것처럼 동작한다. 하지만 프로토콜 구성은 어떠한 새로운 프로토콜 타입도 정의하지 않는다.

프로토콜 구성은 SomeProtocol & AnotherProtocol의 형태를 가진다. 앰퍼샌드로 구분하여 필요한 수 만큼 프로토콜을 나열할 수 있다. 프로토콜 리스트에 추가로 프로토콜 구성은 필요로 하는 슈퍼클래스로 지정하기 위해 하나의 클래스 타입을 포함할 수도 있다.(주: 프로토콜 구성을 준수하려면 특정 클래스의 서브클래스이어야 할 때, 슈퍼클래스도 그 프로토콜 구성 내부에 포함시킨다.)

The Swift Programming Language. Protocols (5)

Tue, 04 Jul 2023 00:00:00 +0000

Protocol Extensions

프로토콜은 메소드, 이니셜라이저, 서브스크립트, 컴퓨티드 프로퍼티를 해당 프로퍼티를 준수하는 타입들에게 제공하도록 확장될 수 있다. 이는 각 타입의 개별 준수나 전역 함수가 아니라 프로토콜 스스로 동작을 정의할 수 있게 해준다.

예를 들어, RandomNumberGenerator 프로토콜은 random() 메소드 요구사항의 결과값을 사용하여 랜덤 Bool 값을 리턴하는 randomBool() 메소드를 제공하도록 확장될 수 있다.

extension RandomNumberGenerator {
 func randomBool() -> Bool {
 return random() > 0.5
 }
}

프로토콜의 익스텐션을 만들면, 해당 프로토콜을 준수하는 모든 타입은 추가적인 수정 없이 모든 이러한 메소드 구현을 자동적으로 얻게 된다.

The Swift Programming Language. Generics (1)

Tue, 01 Aug 2023 00:00:00 +0000

Generics

제네릭 코드(Generic code) 는 정의한 요구사항을 만족하는 모든 타입과 함께 작업할 수 있는 유연하고 재사용성 높은 함수나 타입을 작성하게 해준다. 코드의 중복을 피하고, 의도를 추상적이고 명확한 방법으로 표현할 수 있다.

제네릭은 스위프트의 강력한 특징 중 하나이며, 많은 스위프트의 표준 라이브러리는 제네릭 코드로 빌드 되어있다. 사실 인지하지 못했어도 Language Guide 내내 제네릭 코드를 사용했다. 예를 들어, 스위프트의 Array와 Dictionary 타입은 둘 다 제네릭 컬렉션이다. Int 값을 저장하는 배열, String 값을 저장하는 배열, 혹은 스위프트에서 만들 수 있는 어떠한 다른 타입이라도 저장하는 배열 등을 생성할 수 있다. 비슷하게, 어떤 타입이든지 간에 특정한 타입을 저장하는 딕셔너리를 만들 수 있다.

The Swift Programming Language. Generics (2)

Wed, 02 Aug 2023 00:00:00 +0000

Generic Types

제네릭 함수와 다르게, 스위프트는 제네릭 타입도 정의할 수 있게 해준다. 이는 Array나 Dictionary처럼 모든 타입과 함께 작업할 수 있는 커스텀 클래스, 스트럭처, 열거형이다.

이 섹션은 스택이라는 제네릭 컬렉션 타입을 작성하는 방법을 보여준다. 스택은 배열과 비슷하게 순서가 있는 값들의 집합이다, 하지만 스위프트의 Array 타입보다 더 제한된 작업을 한다. 배열은 배열의 어느 위치에서나 값을 삽입하거나 제거할 수 있지만, 스택은 컬렉션의 끝 부분에서만 삽입(pushing)이나 삭제(popping)을 할 수 있다.

The Swift Programming Language. Generics (3)

Fri, 04 Aug 2023 00:00:00 +0000

Type Constraints

swapTwoValues(_:_:) 함수와 Stack 타입은 어떠한 타입으로도 작업할 수 있다. 하지만 특정한 타입 제약조건(type constraints) 을 강제하여 제네릭 함수나 제네릭 타입이 사용할 수 있는 타입을 지정하는 것이 유용할 때가 있다. 타입 제약조건은 타입 파라미터가 특정한 클래스를 상속 받거나, 특정 프로토콜을 준수해야 하도록 지정한다.

예를 들어, 스위프트의 Dictionary 타입은 딕셔너리의 키로 사용할 수 있는 타입에 제한을 둔다. 딕셔너리의 키로 사용될 타입은 반드시 hashable 해야한다. 즉, 스스로를 유니크하게 구분할 수 있어야 한다.

The Swift Programming Language. Generics (4)

Mon, 07 Aug 2023 00:00:00 +0000

Associated Types

프로토콜을 정의할때, 프로토콜의 정의의 일부로 하나 혹은 그 이상의 연관 타입(associated type) 을 선언하는 것이 유용할 때가 있다. 연관 타입은 프로토콜의 일부로 사용되는 타입에게 플레이스홀더 이름을 부여한다. 해당 연관 타입이 될 실제 타입은 프로토콜이 적용될 때 까지 지정되지 않는다. 연관 타입은 associatedtype 키워드로 특정할 수 있다.

Associated types in Action

다음은 연관 타입으로 Item을 선언하는 프로토콜 Container의 예시이다:

protocol Container {
 associatedtype Item
 mutating func append(_ item: Item)
 var count: Int { get }
 subscript(i: Int) -> Item { get }
}

Container 프로토콜은 모든 컨테이너가 반드시 제공해야할 세 개의 필수 요구사항을 정의한다.

The Swift Programming Language. Generics (5)

Tue, 08 Aug 2023 00:00:00 +0000

Generic Where Clauses

타입 제약조건을 사용하면 제너럴 함수, 서브스크립트, 타입에 관련된 타입 파라미터의 요구사항을 정의할 수 있다.

이는 연관 타입의 제약 조건을 정의하는데에도 유용하며, 제네릭 where 절을 정의하여 할 수 있다. 제네릭 where절은 연관 타입이 반드시 특정 프로토콜을 준수하게 하거나, 특정한 타입 파라미터와 연관 타입이 반드시 같아야 함을 요구할 수 있다. 제네릭 where절은 where 키워드로 시작하고, 뒤에 연관 타입의 제약조건이나 타입 파라미터와 연관 타입의 동등 관계를 작성한다. 제네릭 where절은 타입이나 함수의 본문의 여는 중괄호 바로 앞에 작성한다.

The Swift Programming Language. Opaque Types (1)

Sat, 12 Aug 2023 00:00:00 +0000

Opaque and Boxed Types

스위프트는 값의 타입에 대한 상세한 정보를 숨기는 두가지 방법을 제공한다: 불투명한 타입과 박스형 프로토콜 타입이다. 타입의 정보를 숨기는 것은 모듈과 모듈을 호출하는 코드의 경계에서 유용하다, 리턴 값의 타입이 공개되지 않은 채로 유지될 수 있기 때문이다.

함수나 메소드는 리턴 값의 타입 정보를 숨기기 위해 불투명한 타입을 리턴하다. 함수의 리턴 타입을 구체적으로 제공하는 대신에, 리턴 값은 값이 지원하는 프로토콜로 묘사된다. 불투명한 타입은 타입의 정체를 보존한다 — 컴파일러는 타입 정보에 대해 접근이 가능하지만, 모듈의 클라이언트들은 불가능하다.

The Swift Programming Language. Opaque Types (2)

Sun, 13 Aug 2023 00:00:00 +0000

Boxed Protocol Types

박스드 프로토콜 타입은 “there exists a type T such that T conforms to the protocol” 라는 구절에서 따와 실존적 타입 (existential type) 이라고도 한다. 박스드 프로토콜 타입을 만들기 위해, 프로토콜 이름 앞에 any를 작성한다. 다음은 예시이다:

struct VerticalShapes: Shape {
 var shapes: [any Shape]
 func draw() -> String {
 return shapes.map { $0.draw() }.joined(separator: "\n\n")
 }
}

let largeTriangle = Triangle(size: 5)
let largeSquare = Square(size: 5)
let vertical = VerticalShapes(shapes: [largeTriangle, largeSquare])
print(vertical.draw())

위의 예시에서, VerticalShapes는 도형들의 타입을 박스드 Shape 원소들의 배열인 [any Shape]로 선언한다. 배열의 각 원소들은 서로 다른 타입일 수 있지만, 반드시 Shape 프로토콜을 준수해야 한다. 런타임에 유연성을 지원하기 위해, 스위프트는 필요할 때 박스(box)라는 간접적인 단계를 추가한다. 박스는 성능 코스트가 있다.

The Swift Programming Language. Automatic Reference Counting (1)

Tue, 15 Aug 2023 00:00:00 +0000

Automatic Reference Counting

스위프트는 자동 참조 카운팅(ARC)을 사용하여 앱의 메모리 사용량을 추적하고 관리한다. 대부분의 경우에, 스위프트에서 메모리 관리는 “그냥 작동"하고, 메모리 관리를 직접 할 생각을 하지 않아도 된다. ARC는 클래스 인스턴스가 더 이상 필요하지 않게 되었을 때, 자동적으로 해당 메모리를 비우게 된다.

하지만, 경우에 따라 ARC는 메모리 관리를 위해 코드 내부에서의 관계**(주: 원문은 relationships between parts of your code, 코드 부분들 간의 관계)** 에 대한 정보를 요구할 때가 있다. 이 챕터는 이러한 상황들을 설명하고, 어떻게 ARC가 앱의 메모리를 관리하는지를 보여준다.

The Swift Programming Language. Automatic Reference Counting (2)

Wed, 16 Aug 2023 00:00:00 +0000

Resolving Strong Reference Cycles Between Class Instances

스위프트는 클래스 타입 프로퍼티로 작업할 때 강한 참조 사이클을 해결하는 두 가지 방법으로 약한 참조와 미소유 참조를 제공한다.

약한 참조와 미소유 참조는 참조 사이클 내부의 한 인스턴스가 다른 인스턴스를 강하게 붙잡지 않고 참조할 수 있게 해준다. 그리고는 그 인스턴스들은 서로를 강한 참조 사이클 없이 참조할 수 있게 된다.

다른 인스턴스의 수명이 더 짧을 때 약한 참조를 사용한다. — 즉 다른 인스턴스가 먼저 할당 해제되는 경우이다. 이전의 Apartment 예시에서, 아파트의 라이프 사이클 중간에 거주자가 없는 것은 충분히 가능한 일이므로 약한 참조는 이러한 경우의 참조 사이클을 깨뜨리는데 적합하다. 반대로, 미소유 참조를 사용하는 것은 다른 인스턴스가 같거나 더 긴 수명을 가지고 있을때 사용한다.

The Swift Programming Language. Automatic Reference Counting (3)

Mon, 21 Aug 2023 00:00:00 +0000

Strong Reference Cycles for Closures

두 클래스 인스턴스의 프로퍼티들이 서로를 강한 참조하면서 강한 참조 사이클이 만들어지는지를 이전에 보았고, 약한 참조와 미소유 참조가 이러한 강한 참조 사이클을 깨뜨리는 것도 보았다.

강한 참조 사이클은 클래스의 인스턴스에 클로저를 할당하고, 해당 클로저의 본문에서 그 인스턴스를 캡처할때도 발생한다. 이러한 캡처는 self.someProperty처럼 그 클로저가 해당 인스턴스의 프로퍼티에 접근하거나, self.someMethod()처럼 해당 인스턴스의 메소드에 접근할 때 발생한다. 두 경우 모두, 이러한 접근으로 그 클로저가 self를 “캡처"할때, 강한 참조 사이클을 생성하게 된다.

The Swift Programming Language. Memory Safety (1)

Sat, 26 Aug 2023 00:00:00 +0000

Memory Safety

스위프트는 기본적으로 코드에서 일어나는 안전하지 않은 행동들을 방지한다. 예를 들어, 스위프트는 변수를 사용하기 전에 초기화가 되어있는지 확인하고, 할당 해제된 메모리에는 접근하지 않으며, 배열의 인덱스 값들이 범위 안에 있는지 확인한다.

또한 스위프트는 메모리를 수정하는 코드가 해당 메모리에 독점적으로 접근하도록 요구하여 같은 위치에 있는 메모리에 대한 동시 접근이 충돌하지 않게 한다. 스위프트가 메모리를 자동적으로 수정하기 때문에, 대부분의 경우에는 메모리 접근에 대해 생각하지 않아도 된다. 하지만, 충돌이 발생할 수 있는 잠재적인 위치를 이해하여, 메모리에 접근할 때 충돌하는 코드 작성을 회피하는 것도 중요하다. 만약 충돌을 일으키는 코드라면, 컴파일 에러 혹은 런타임 에러를 발생시키게 된다.

The Swift Programming Language. Memory Safety (2)

Mon, 27 Jan 2025 00:00:00 +0000

Conflicting Access to In-Out Parameters

함수는 모든 in-out 파라미터에 대한 장기 쓰기 접근 권한을 가지고 있다. in-out 파라미터에 대한 쓰기 권한은 모든 non-in-out 파라미터가 evaluate된 후에 시작되어 함수가 호출되는 전체 기간동안 유지된다. 여러개의 in-out 파라미터가 존재할 경우, 쓰기 접근 파라미터들이 보이는 순서대로 시작된다.

이 장기 쓰기 접근 권한의 결과중 하나는 스코프 규칙(scoping rule)과 액세스 컨트롤이 허락하더라도, in-out으로 전달된 원본 변수에 접근할 수 없다는 것이다—원본에 접근하는 것은 충돌을 발생시킨다:

The Swift Programming Language. Access Control (1)

Tue, 28 Jan 2025 00:00:00 +0000

Access Control

액세스 컨트롤은 다른 소스 파일이나 모듈에서 코드의 일부분에 접근하는 것을 제한한다. 이 기능은 코드의 구체적인 구현 사항을 숨기면서 해당 코드에 접근하고 사용할 선호하는 인터페이스를 지정할 수 있게 해준다.

개별 타입들 (클래스, 스트럭처, 이뉴머레이션) 뿐만 아니라 해당 타입에 포함된 프로퍼티, 메소드, 이니셜라이저, 서브스크립트에도 접근 레벨을 지정할 수 있다. 프로토콜도 특정 컨텍스트로 제한할 수 있으며, 글로벌 상수, 변수, 함수도 가능하다.

다양한 레벨의 액세스 컨트롤을 제공하는 것에 더해서, Swift는 일반적인 시나리오에 대해서 기본 액세스 레벨을 제공해서 명시적으로 액세스 컨트롤 레벨을 지정할 필요를 줄였다. 만약 싱글 타겟 앱을 작성하고 있다면, 아마도 명시적인 액세스 컨트롤을 지정할 필요가 없을 것이다.

The Swift Programming Language. Access Control (2)

Wed, 29 Jan 2025 00:00:00 +0000

Custom Types

커스텀 타입에 대한 명시적인 액세스 레벨을 지정하고 싶으면, 타입을 정의할 때 하면 된다. 새로운 타입은 액세스 레벨이 허용하는 곳이라면 어디에서든 사용할 수 있다. 예를 들어, file-private한 클래스를 정의하면, 그 클래스가 정의된 소스 파일 내부에서 프로퍼티나, 함수의 파라미터 혹은 리턴 타입으로만 사용할 수 있다.

또한 타입의 액세스 컨트롤 레벨은 타입의 멤버(프로퍼티, 메소드, 이니셜라이저, 서브스크립트)의 기본 액세스 레벨에도 영향을 끼친다. 만약 타입의 액세스 레벨을 private이나 file private으로 정의했다면, 멤버들의 기본 액세스 레벨도 private이나 file private이 된다. 만약 타입의 액세스 레벨을 internal 이나 public으로 정의했다면(혹은 액세스 레벨을 명시적으로 지정하지 않아 기본 액세스 레벨 internal을 사용한다면), 타입의 멤버의 기본 액세스 레벨은 internal이 된다.

TIL. Aug 18, 2026

Tue, 18 Aug 2026 23:30:00 +0900

오늘 한 내용

Stack Day
- LocalDay 날짜 모델 도입
- Clock과 FixedClock 추가
- 완료 기록·취소·보관·삭제 UseCase를 날짜 모델에 맞게 수정
- InMemoryHabitRepository, InMemoryCompletionRepository 구현 및 테스트 추가
- StackDay. Date로 하루를 표현하면 생기는 문제

배운 내용

LocalDay 도입하기

Stack Day에서는 Date 하나로 특정 시점과 특정 날짜를 모두 표현하고 있었다. 그래서 달력상의 날짜만 필요한 값을 LocalDay로 분리했다.

LocalDay: startedOn, archivedOn, completedOn
Date: createdAt, updatedAt, recordedAt

현재 시각은 Clock이 제공하고, 그 시각을 어느 날짜로 해석할지는 TimeZone이 결정하도록 분리했다. 전체 설계와 구현 코드는 개발일지에 정리했다.

StackDay. Date는 날짜가 아니다

Tue, 18 Aug 2026 17:52:46 +0900

StackDay는 일정 주기의 습관 수행 여부를 기록하는 앱이고, MVP에서는 그 주기를 매일로 고정했다.

지금까지 구현할 때, “어느 날에 수행했는가"와 “정확히 언제 기록했는가"를 모두 Foundation의 Date로 표현했다.

두 정보는 비슷해 보이지만 다르다. 이 차이를 타입으로 구분하지 않으면 날짜 검증, 중복 기록 검사, 통계 계산마다 같은 해석을 반복하게 된다.

이번 글에서는 그 문제가 실제 코드에서 어떻게 드러났고, LocalDay·Clock·TimeZone을 어떤 경계로 나눴는지 정리한다.

Date타입이 저장하는 것은 순간

Date는 연, 월, 일이나 자정 같은 달력 개념을 저장하지 않는다.

TIL. Aug 17, 2026

Mon, 17 Aug 2026 23:30:00 +0900

오늘 한 내용

PS
- LeetCode 1563. Stone Game V
WWDC
- Swift Concurrency. Explore Structured Concurrency in Swift (2) - WWDC21
마이그레이션
- Algorithm. Kadane’s Algorithm 마이그레이션
- 미방문록. 대표 색상 추출 Picker 만들기 마이그레이션

배운 내용

Unstructured Task

WWDC21 Explore Structured Concurrency in Swift 세션을 정리를 마무리했다.

1편과 다르게 구조화된 task tree에 속하지 않는 unstructured task와 detached task를 정리했다.

Task { ... }로 만든 unstructured task는 생성한 scope가 끝나도 계속 실행될 수 있다. 생성 지점의 actor, priority, task-local value를 상속한다.

Swift Concurrency. Explore Structured Concurrency in Swift (2) - WWDC21

Mon, 17 Aug 2026 19:50:17 +0900

앞선 포스팅에서는 구조화된 동시성이 task 계층 구조를 활용해 제어 흐름을 일반 동기 코드처럼 만들고, 에러 전파와 cancellation을 단순하게 만드는 방식을 정리했다.

이 포스팅에서는 계층 구조가 없는 task, 즉 unstructured task(구조화되지 않은 동시성)에 대해 정리한다.

Not all tasks fit a structured pattern

동기 코드에서 처음으로 비동기 연산을 시작하는 경우처럼 parent task가 존재하지 않거나, task의 생명주기가 하나의 스코프에 들어맞지 않는 경우가 있을 수 있다.

이런 경우는 특히 UIKit에서 delegate를 구현할 때 자주 발생한다.

LeetCode 1563. Stone Game V

Mon, 17 Aug 2026 11:30:13 +0900

문제

https://leetcode.com/problems/stone-game-v

풀이

돌이 일렬로 놓여 있고, 매 턴마다 현재 구간을 둘로 나눈 뒤 더 작은 합을 가진 쪽을 가져간다. Alice가 얻을 수 있는 최대 점수를 리턴하는 문제이다.

매 턴마다 현재 구간을 둘로 나눈 뒤 더 작은 합을 가진 쪽을 가져가므로, 구간 DP로 보는 게 자연스럽다.

dp[left][right]를 stoneValue[left...right] 구간에서 Alice가 얻을 수 있는 최대 점수라고 하자. 구간을 split으로 나눠서 왼쪽 합과 오른쪽 합을 비교하면 된다.

왼쪽 합이 더 작으면 왼쪽을 가져간다.
오른쪽 합이 더 작으면 오른쪽을 가져간다.
두 합이 같으면 둘 중 더 좋은 쪽을 선택한다.

구간 합은 Prefix Sum으로 미리 구해두면 되고, dp는 짧은 구간부터 채우면 된다. 각 구간마다 모든 분할을 확인하므로 전체 시간 복잡도는 $O(n^3)$이다.

TIL. Aug 16, 2026

Sun, 16 Aug 2026 23:30:00 +0900

오늘 한 내용

PS
- Codeforces 1360D. Buying Shovels
Stack Day
- CancelCompletionUseCase, ArchiveHabitUseCase, DeleteHabitUseCase 구현
- 완료 기록 삭제 테스트와 공통 테스트 Repository 정리
- StackDay. 완료 기록을 취소할 때 무엇을 삭제해야 할까

배운 내용

in-memory Repository와 테스트 용도 Repository

프로덕션의 In-Memory Repository는 실제 저장 상태를 다루고, 테스트용 Repository는 호출과 오류를 관찰하는 Test Double이다. 같은 형태로 보이더라도 목적이 달라 분리했다.

ID와 Business Key

Completion.ID는 기록 자체를 식별하고, (habitID, completedOn)은 현재 정책에서 해당 날짜의 기록을 찾는 조건으로 분리했다. 없는 기록 취소를 성공으로 넘기지 않은 이유까지 개발일지에 정리했다.

StackDay. 비즈니스 규칙과 Entity Identity 분리하기

Sun, 16 Aug 2026 15:23:36 +0900

현재 StackDay MVP에서는 하나의 Habit에 대해 하루 한 번만 Completion을 기록할 수 있다.

그래서 처음에는 (habitID, completedOn) 조합을 Completion의 identity처럼 사용해도 될 것 같았고, 실제로 그런 코드도 있었다.

하지만 Completion 삭제를 구현하면서 이 둘을 분리해야 한다는 점을 알게 되었다.

struct Completion: Equatable, Identifiable {
 let id: UUID
 let habitID: UUID
 let completedOn: Date
 let recordedAt: Date
}

같은 날의 기록을 찾는 조건

같은 Habit의 같은 날 Completion을 찾는 데에는 habitID와 completedOn이 필요하다. 현재 정책에서는 이 조건으로 중복 기록도 막을 수 있다.

하지만 이것은 현재 정책에서 필요한 조회 조건이다. 이후 시간 단위로 습관을 기록하거나, 하루에 여러 번 수행하는 Habit이 생기면 같은 조합으로 여러 Completion이 존재할 수 있다.

Codeforces 1360D. Buying Shovels

Sun, 16 Aug 2026 10:53:55 +0900

문제

https://codeforces.com/problemset/problem/1360/D

풀이

정확히 n개의 삽을 사야 하고, 한 번에 살 수 있는 패키지 크기는 1부터 k까지이다. 또한 한 번 고른 패키지 크기만 계속 사야 하므로, 결국 n을 나누는 어떤 수 x를 골라 n / x개의 패키지를 사는 문제로 바뀐다.

패키지 개수를 최소화하려면 패키지 크기 x를 최대한 크게 잡아야 한다. 따라서 n의 약수 중에서 k 이하인 가장 큰 값을 찾으면 된다.

예를 들어 n = 8, k = 7이면 8의 약수는 1, 2, 4, 8인데, 이 중 k 이하인 가장 큰 약수는 4이다. 그래서 답은 8 / 4 = 2가 된다.

LeetCode 2029. Stone Game IX

Sun, 16 Aug 2026 10:22:55 +0900

문제

https://leetcode.com/problems/stone-game-ix

풀이

돌을 순서대로 가져가면서, 합이 3의 배수가 되지 않게 해야 하는 게임이다. Alice가 이길 수 있는지 리턴하는 문제이다.

각 돌의 값은 3으로 나눈 나머지만 보면 된다. 합이 3의 배수인지 아닌지만 중요하기 때문이다. 그래서 0, 1, 2의 개수만 세면 충분하다.

0은 합의 나머지를 바꾸지 않으므로, 실제 승부는 1과 2를 어떻게 번갈아 쓰느냐에 달려 있다. count[0]이 짝수인지 홀수인지에 따라 가능한 진행이 달라진다.

count[0]이 짝수면 1과 2가 둘 다 있어야 한다.
count[0]이 홀수면 1과 2의 개수 차이가 너무 크면 안 된다.

코드

class Solution {
 func stoneGameIX(_ stones: [Int]) -> Bool {
 var count = [Int](repeating: 0, count: 3)
 for stone in stones {
 count[stone % 3] += 1
 }
 let count0 = count[0]
 let count1 = count[1]
 let count2 = count[2]
 if count0 % 2 == 0 {
 return count1 > 0 && count2 > 0
 }
 return abs(count1 - count2) > 2
 }
}

TIL. Aug 15, 2026

Sat, 15 Aug 2026 23:30:00 +0900

오늘 한 내용

배운 내용

Structured Concurrency

Explore Structured Concurrency in Swift WWDC 세션을 봤다.

Meet async/await in Swift 세션도 마찬가지고, 이번 세션을 보면서 느낀 것은 Swift Concurrency의 중요한 컨셉은 비동기 코드를 일반적인 동기 코드와 비슷한 흐름으로 작성할 수 있게 하는 것이라고 생각했다.

async/await가 에러 핸들링과 같은 부분을 비동기 코드도 동기 코드와 비슷하게 사용할 수 있게 해줬다면, Structured Concurrency는 조건문이나 루프같은 제어 흐름도 동기 코드와 비슷하게 사용하게 해준다.

Swift Concurrency. Explore Structured Concurrency in Swift (1) - WWDC21

Sat, 15 Aug 2026 15:54:01 +0900

앞서 정리한 세션에서는 completion handler 기반의 비동기 코드를 async/await로 작성하면서, 비동기 코드에서도 return, throw, try-catch와 같은 일반적인 제어 흐름을 사용할 수 있게 되었다.

이번 포스팅에서는 WWDC21의 Explore Structured Concurrency in Swift 세션을 정리한다. async/await가 비동기 코드의 제어 흐름을 구조화했다면, structured concurrency는 여기서 더 나아가 동시에 실행되는 여러 task의 관계와 수명을 구조화한다.

Explore Structed Concurrency in Swift

Swift Concurrency는 구조화된 프로그래밍(structured programming)의 아이디어에 기반한 structured concurrency라는 개념을 활용한다.

옛날에는 프로그램에서 명령어를 나열하고, 컨트롤 플로우가 여기저기로 자유롭게 점프해서 코드를 읽기가 매우 어려웠다. (C의 goto를 생각해보자)

Codeforces 276C. Little Girl and Maximum Sum

Sat, 15 Aug 2026 12:48:53 +0900

문제

https://codeforces.com/problemset/problem/276/C

풀이

크기 n인 수열 a와 쿼리 q개가 주어진다. 각 쿼리는 인덱스 $[l, r]$ 범위를 지정하며, 해당 범위의 원소 합을 구한다. 수열 a를 적절히 재배열하여 모든 쿼리의 합의 총합을 최대화 한 수를 출력하면 된다.

쿼리가 여러번 나오고 어떤 원소들은 쿼리 안에 중복되어서 포함되어 있을 수 있다. 쿼리의 범위 안에 가장 많이 포함된 원소의 순서대로, 높은 값을 배치하는 정렬 문제로 환원된다.

어떤 원소 $a_i$가 쿼리 내부에 포함되어 있는지를 일반적으로 판단하게 되면 $O(q \times n)$이 되는데, q, n의 범위가 $1 \leq q 2 \times 10^5$ 이므로, 시간 안에 문제를 해결하기 어려워진다.

Leetcode 3702. Longest Subsequence With Non-Zero Bitwise XOR

Sat, 15 Aug 2026 12:38:30 +0900

문제

https://leetcode.com/problems/longest-subsequence-with-non-zero-bitwise-xor

풀이

수열 nums가 주어지고, 이 nums의 서브시퀀스 중, 모든 원소를 XOR해서 0이 아니게 되는 서브시퀀스의 최대 길이를 리턴하면 된다.

이 문제는 XOR 연산의 특성을 잘 알아야 한다. 만약 XOR이 아니라 $+$이었다면, 모든 $\text{nums}$의 원소들을 더해보고, 0이 아니라면 $\text{nums}$ 전체를, 0이라면 원소 중 0이 아닌 것 하나를 제외하면 된다. $+$의 역연산은 $-$이므로, 어떤 원소 $x$를 제외했을 때 다음과 같이 된다.

$$\sum \text{nums} - x \neq 0$$

만약 모든 원소가 0이라면 답은 0이 된다.

TIL. Aug 14, 2026

Fri, 14 Aug 2026 23:30:00 +0900

오늘 한 내용

PS
- Codeforces 550A. Two Substrings
- LeetCode 3090. Maximum Length Substring With Two Occurrences
Stack Day
- HabitRepository, CompletionRepository 인터페이스 추가
- CreateHabitUseCase와 RecordCompletionUseCase 구현
- StackDay. UseCase와 Entity는 각각 어디까지 책임져야 할까
- StackDay. Repository의 save를 insert와 update로 나눈 이유

배운 내용

UseCase와 Entity의 책임

CreateHabitUseCase와 RecordCompletionUseCase를 구현하면서, Entity가 스스로 유효한 상태를 보장하고 UseCase는 객체를 조합해 작업 흐름을 만드는 쪽으로 책임을 나눴다.

이름 정규화와 유효성 검증은 Habit에, 저장 순서와 중복 확인은 UseCase에 뒀다. 자세한 고민은 개발일지에 정리했다.

StackDay. UseCase와 Entity는 각각 어디까지 책임져야 할까

Fri, 14 Aug 2026 16:31:52 +0900

CreateHabitUseCase를 시작으로 여러 유즈케이스를 구현하면서, 도메인 규칙을 어디에 두어야 할지 계속 고민하게 됐다.

Habit을 생성할 때 이름의 유효성을 누가 검증해야 하는지, Completion을 남길 때 해당 날짜에 기록할 수 있는지는 누가 판단해야 하는지처럼 비슷한 문제가 반복해서 나타났다.

처음에는 유즈케이스가 사용자의 작업을 처리하니 이런 검증도 함께 담당하면 된다고 생각할 수 있었다. 하지만 구현을 진행할수록 엔티티가 스스로 보장해야 하는 규칙과 유즈케이스 작업의 흐름을 위해 판단해야 하는 규칙을 구분할 필요가 있었다.

이 포스트에서는 Habit의 생성과 Completion 기록을 중심으로 어떤 고민을 했는지와 어떻게 해결했는지를 정리한다.

StackDay. Repository의 save를 insert와 update로 나누기

Fri, 14 Aug 2026 14:15:52 +0900

유즈케이스를 구현하면서 Habit과 Completion을 저장할 Repository 계약을 좀 정리했다.

처음에는 create와 update 둘 다 save 하나로 저장하면 간단해 보였지만, 두 기능이 기대하는 실패 조건이 서로 다르다는 점에서 계약을 나눌 필요가 있었다.

save는 어떤 동작인가

save를 upsert로 구현하면 호출하는 쪽은 편하다. ID가 없으면 삽입하고, 이미 있으면 갱신하면 된다.

protocol HabitRepository {
 func save(_ habit: Habit) async throws
}

문제는 이 동작이 실패해야 하는 상황까지 조용히 성공으로 바꾼다는 점이다.

(물론 UUID라 현실적으로 겹칠 일은 없지만) Habit을 생성하는 작업은 같은 ID가 이미 있으면 실패해야 하고, 보관처럼 기존 Habit을 바꾸는 작업은 대상이 없으면 실패해야 한다.

Codeforces 550A. Two Substrings

Fri, 14 Aug 2026 12:17:14 +0900

문제

https://codeforces.com/problemset/problem/550/A

풀이

스트링 s가 주어지고, 이 s 안에서 서브스트링 "AB"와 "BA"가 겹쳐지지 않은 상태로 존재하면 "YES" 아니라면 "NO" 출력하면 된다.

문제에서 주어진 예시인 "ABA" 같은 경우는 "NO"가 된다. "AB"와 "BA"가 서로 따로 존재하지 않기 때문이다. 하지만 "ABCABA" 같은 경우에는 "AB"와 "BA"가 "BA"는 겹쳐져 있지만 이미 앞에서 "AB"가 존재하기 때문에, "YES"가 된다.

이런 예외들을 알아내면, 문제를 푸는 방식은 단순하다. "AB"를 찾은 후, 그 이후("B" 이후)에 있는 인덱스부터 "BA"를 찾고, 만약 존재한다면 "YES", 존재하지 않는다면 다시 "BA"를 먼저 찾은 후, "A"의 인덱스 이후에 있는 인덱스부터 "AB"를 찾으면 된다. 둘 다 불가능하다면 "NO"가 된다.

Leetcode 3090. Maximum Length Substring With Two Occurrences

Fri, 14 Aug 2026 11:53:07 +0900

문제

https://leetcode.com/problems/maximum-length-substring-with-two-occurrences

풀이

스트링 s가 주어지고, 스트링 s의 서브스트링 중에서 같은 문자가 최대 2번 까지만 등장하는 서브스트링의 최대 길이를 리턴하는 문제이다.

투 포인터를 이용해서, 서브스트링 내부의 각 문자의 개수는 frequencies 딕셔너리로 추적하고, 같은 문자가 2개를 초과하면 start, 그렇지 않다면 end를 증가시키는 방향으로 s를 탐색하면 된다.

문제의 제약조건이 널널해서 $O(n^2)$ 방식의 브루트 포스로도 풀 수 있지만 투 포인터를 이용하면 $O(n)$으로 쉽게 풀 수 있다.

코드

class Solution:
 def maximumLengthSubstring(self, s: str) -> int:
 frequencies = {}
 answer = 0
 start = 0
 for end in range(len(s)):
 frequencies[s[end]] = frequencies.get(s[end], 0) + 1
 while frequencies[s[end]] > 2:
 frequencies[s[start]] -= 1
 start += 1
 answer = max(answer, end - start + 1)
 return answer

TIL. Aug 13, 2026

Thu, 13 Aug 2026 21:30:00 +0900

오늘 한 내용

배운 내용

StackDay 통계 계산

HabitStatistics를 구현하면서 계산 결과를 표현하는 타입과 계산 로직을 분리했다. 다만 HabitStatisticsCalculator가 HabitStreakCalculator에 의존하게 되면서, 여러 Calculator가 같은 날짜 정규화와 완료 기록 필터링을 반복하는 문제가 보였다.

타입을 나누는 것만으로 항상 구조가 좋아지는 것은 아니고, 공유하는 계산 맥락까지 함께 살펴봐야 한다는 점을 배웠다. 자세한 고민은 StackDay 개발일지에 정리했다.

Leetcode 2213. Longest Substring of One Repeating Character

Thu, 13 Aug 2026 20:45:10 +0900

문제

https://leetcode.com/problems/longest-substring-of-one-repeating-character

풀이

스트링 s에 대해 여러 번의 문자 변경 쿼리가 주어진다. 각 쿼리마다 특정 인덱스의 문자를 변경하고, 같은 문자가 연속되는 가장 긴 부분 스트링의 길이를 리턴하면 된다.

스트링의 길이와 쿼리의 개수가 최대 $10^5$이므로, 문자를 변경할 때마다 스트링 전체를 탐색하는 방식으로는 해결할 수 없다.

문자 하나를 변경하는 업데이트가 반복되고, 변경 이후 스트링 전체에서 가장 긴 연속 스트링의 길이를 구해야 한다. 따라서 변경된 구간만 갱신할 수 있는 Segment Tree를 사용했다.

다만, 단순히 concat을 하면 안되고, 두 접합부의 경계를 확인한 다음 처리를 해줘야 한다.

StackDay. 책임 분리와 타입 분리

Thu, 13 Aug 2026 18:32:51 +0900

이전 작업에서 HabitStreak을 구현하면서 계산 결과와 계산 로직을 분리했다.

HabitStreak은 현재 스트릭과 최장 스트릭이라는 값만 표현하고, 계산은 HabitStreakCalculator가 담당한다.

struct HabitStreak: Equatable {
 let current: Int
 let longest: Int
}

struct HabitStreakCalculator {
 func calculate(
 habit: Habit,
 completions: [Completion],
 referenceDate: Date,
 calendar: Calendar = .current
 ) -> HabitStreak {
 // ...
 }
}

같은 원리로 HabitStatistics도 파생 값과 계산 책임을 분리해서 구현했다.

HabitStatistics

HabitStatistics는 Habit의 수행 기록을 요약한 파생 값이다.

MVP에서는 다음 값을 제공한다.

struct HabitStatistics: Equatable {
 let totalCompletedDays: Int
 let eligibleTrackingDays: Int
 let completionRate: Double
 let streak: HabitStreak
}

totalCompletedDays는 추적 기간 안에서 완료한 날짜의 수이고, eligibleTrackingDays는 시작일부터 기준일까지 추적 대상이 된 날짜의 수다. 아카이브된 Habit은 archivedOn을 마지막 추적일로 사용한다.

Data Structure. Segment Tree

Thu, 13 Aug 2026 14:18:26 +0900

Segment Tree

배열의 특정 구간에 대한 연산을 빠르게 처리하기 위한 이진 트리 형태의 자료구조.

구간 합, 최솟값, 최댓값처럼 배열의 일정 범위를 대상으로 반복해서 연산해야 하는 경우에 사용할 수 있다.

일반적인 배열에서 특정 구간의 합을 구하려면 해당 구간의 원소를 직접 순회해야 하므로 $O(n)$의 시간이 필요하다. 세그먼트 트리는 배열의 여러 구간에 대한 연산 결과를 트리 형태로 저장하여 구간 조회를 $O(\log n)$에 처리할 수 있도록 한다.

특히 배열의 값이 변경되는 상황에서도 구간에 대한 연산을 반복해서 수행해야 할 때 사용할 수 있다.

TIL. Aug 12, 2026

Wed, 12 Aug 2026 23:30:00 +0900

오늘 한 내용

배운 내용

파생 값을 구현할 때의 책임 분리

StackDay의 HabitEntry와 HabitStreak을 구현했다. 모델링 단계에서 정의한 파생 값을 실제 코드로 옮기면서, 값을 표현하는 타입과 값을 계산하는 로직을 분리했다.

AI 에이전트가 작성한 내용중에 별로인 것들을 몇개 직접 수정했는데 리스트로 정리하면 다음과 같다.

HabitEntry의 이니셜라이저 전체 Completion 목록을 직접 탐색하고, 생성 실패/성공을 판정했다.
HabitStreak의 이니셜라이저 내부에 Streak 계산 로직이 들어있었다.

둘 다 경계가 제대로 구분되지 않았다. HabitEntry 내부에서 전체 Completion을 탐색하면서 조건에 맞는 Completion을 찾아내는건 비효율적이기도 하고, 이건 유즈케이스에서 해야 될 일이다.

LeetCode 2996. Smallest Missing Integer Greater Than Sequential Prefix Sum

Wed, 12 Aug 2026 22:47:12 +0900

문제

https://leetcode.com/problems/smallest-missing-integer-greater-than-sequential-prefix-sum

풀이

정수 배열 nums가 주어진다. 배열의 첫 원소부터 연속해서 증가하는 부분의 합을 구한 뒤, 그 합보다 크거나 같으면서 배열에 존재하지 않는 가장 작은 정수를 찾으면 된다.

먼저 첫 번째 원소를 합에 더해두고, 현재 원소가 다음 조건을 만족하는지 확인한다.

$$ nums[i] = nums[i - 1] + 1 $$

조건을 만족하는 동안에는 현재 원소를 합에 더하고, 연속 조건이 깨지면 순회를 종료한다.

이제 구한 합을 후보값으로 두고, 후보값이 배열 안에 있으면 1씩 증가시킨다. 배열에 없는 첫 번째 값이 정답이다. 이 부분은 코드처럼 배열에 후보값이 존재하는 동안 반복하면 된다.

LeetCode 2958. Length of Longest Subarray With at Most K Frequency

Wed, 12 Aug 2026 21:14:37 +0900

문제

https://leetcode.com/problems/length-of-longest-subarray-with-at-most-k-frequency

풀이

정수 배열 nums와 정수 k가 주어질 때, 어떤 숫자도 k번보다 많이 등장하지 않는 가장 긴 연속 부분 배열의 길이를 구하면 된다.

연속 부분 배열이므로 슬라이딩 윈도우를 사용했다. start부터 end까지를 현재 윈도우로 두고, end를 오른쪽으로 이동하면서 숫자별 등장 횟수를 갱신한다.

새로 추가한 숫자의 등장 횟수가 k를 초과하면 조건을 만족할 때까지 start를 오른쪽으로 이동한다. 이때 윈도우의 가장 왼쪽 숫자부터 하나씩 제거하면 된다. 윈도우가 조건을 만족하는 상태가 되면 현재 길이로 정답을 갱신한다.

TIL. Aug 10, 2026

Mon, 10 Aug 2026 23:42:07 +0900

오늘 한 내용

devbox-light-server
- Docker 이미지 작성 및 컨테이너 실행
- .data 볼륨 연결과 healthcheck 추가
- GitHub Actions에서 테스트 이후 이미지를 빌드하도록 구성
- main 브랜치에 push하면 GHCR에 Docker 이미지를 자동으로 배포하도록 연결
PS
- LeetCode 1510
- LeetCode 1140

배운 내용

Stone Game의 승패 DP

LeetCode 1510

Stone Game 시리즈는 현재 플레이어가 이길 수 있는지를 상태로 두고 풀면 된다. Alice가 먼저 시작하는 것은 고정되어 있으므로, Alice와 Bob을 따로 나누기보다 현재 차례의 플레이어 기준으로 생각하는 편이 자연스럽다.

LeetCode 1140. Stone Game II

Mon, 10 Aug 2026 22:18:06 +0900

문제

https://leetcode.com/problems/stone-game-ii

풀이

돌이 일렬로 놓여 있고, 현재 M일 때 1개부터 2M개까지 가져갈 수 있다. 돌을 가져간 뒤에는 M이 max(M, 가져간 개수)로 바뀐다. Alice가 항상 먼저 시작하고, Alice가 얻을 수 있는 돌의 최대 개수를 구하면 된다.

현재 차례인 사람이 상대보다 얼마나 더 많이 가져갈 수 있는지로 DP를 정의할 수도 있지만, 이 문제에서는 현재 상태에서 현재 플레이어가 최대로 가져갈 수 있는 돌의 수를 저장하는 방식이 더 직관적이다.

dp[i][m]을 i번째 돌부터 시작하고 현재 M이 m일 때, 현재 플레이어가 얻을 수 있는 최대 돌의 수라고 하자. suffix[i]는 i번째 돌부터 끝까지 남은 돌의 합이다.

LeetCode 1510. Stone Game IV

Mon, 10 Aug 2026 20:32:58 +0900

문제

https://leetcode.com/problems/stone-game-iv

풀이

돌이 n개 있고, 매 턴마다 제곱수만큼의 돌을 가져간다. 마지막 돌을 가져가는 사람이 이긴다고 할 때, Alice가 이길 수 있는지 구하면 된다.

dp[i]를 돌이 i개 남았을 때 현재 차례인 사람이 이길 수 있는지로 정의한다. 어떤 제곱수 $r^2$을 가져간 뒤 상대 차례의 상태가 패배라면, 현재 플레이어는 그 선택으로 이길 수 있다.

따라서 점화식은 다음과 같다.

$$ dp[i] = \text{true} \quad \text{if there exists } r \text{ such that } dp[i - r^2] = \text{false} $$

DevOps. AI 코딩 에이전트 구조적으로 설계하기

Mon, 10 Aug 2026 13:15:39 +0900

AI 에이전트에게 프로젝트를 설명하기

예전에는 LLM을 이용해 코드를 작성하려면 필요한 기능을 설명하고, 프로젝트의 구조나 현재 상황을 프롬프트로 설명해야 했다. 즉, 프로젝트와 LLM의 API가 사람이었다…

반면 Codex나 Claude Code 같은 코딩 에이전트는 프로젝트의 파일을 직접 탐색하고 기존 코드를 분석하면서 작업에 필요한 컨텍스트를 스스로 수집한다.

하지만 코드만으로 프로젝트의 모든 것을 알 수 있는 것은 아니다. 프로젝트의 규모가 작거나 코드에 충분한 단서가 없다면 의도를 추론하기 어렵고, 반대로 규모가 커질수록 필요한 정보를 찾기 위해 더 많은 코드를 탐색하고 컨텍스트로 사용해야 한다.

TIL. Aug 9, 2026

Sun, 09 Aug 2026 22:16:51 +0900

오늘 한 내용

dev-data-server-light
- DB, Auth Token, Storage에 JSON 기반 영속성 추가
- JSON 파일 읽기·쓰기 로직 공통화
- 실행 환경에 따라 JSON과 in-memory 저장소를 선택하도록 구성
Stack Day
- Habit, Habit Entry, Completion의 역할을 나눠 데이터 모델링

배운 내용

저장 방식은 애플리케이션의 관심사가 아니다

dev-data-server-light를 처음 만들 때는 in-memory 저장소만 사용했다. 개발 중에는 빠르고 편하지만 서버를 재시작하면 유저, 토큰, 파일 데이터가 모두 사라진다. MVP를 마무리하려면 실제로 재시작해도 데이터가 남는 저장 방식이 필요했다.

DevOps. 로컬 LLM을 VSCode와 Xcode에서 코딩 에이전트로 사용하기

Sun, 09 Aug 2026 11:08:32 +0900

로컬 LLM 모델을 설치하고 이어서 로컬 LLM 모델을 Xcode와 VSCode에 연동해보자.

우선 VSCode에 연결해보고 다음엔 Xcode의 ‘Chat’ 기능, 최종적으론 OpenCode와 Xcode를 ACP로 연동해서 로컬 LLM을 코딩 에이전트로 이용하려 한다.

VSCode 연결

Ollama 익스텐션 설치 및 모델 연동

Ollama에서 공식적으로 VSCode 익스텐션을 제공한다. 단순히 설치만 하면된다.

로컬 LLM을 VS Code에서 사용하려면, 빌트인 되어있는 Copilot Chat 기능을 이용해야 한다. Copilot Chat의 UI와 코드 컨텍스트 수집 기능을 사용하고, 실제 응답을 생성하는 언어 모델은 Ollama에서 실행 중인 로컬 모델을 사용할 것이다.

Codeforces 1294C. Product of Three Numbers

Sat, 08 Aug 2026 22:41:23 +0900

문제

https://codeforces.com/problemset/problem/1294/C

풀이

테스트 케이스가 t개 존재한다. 먼저, 정수 n이 주어진다. 각 n에 대해 $n = a \times b \times c, \ a, b, c > 1, \ a \neq b, b \neq c, a \neq c$를 만족하는 세 정수 a, b, c가 존재하면 "YES"와 세 수를 출력하고, 그렇지 않으면 "NO"를 출력하면 된다.

인수 분해 문제이다. n이 3개의 정수의 곱으로 표현되어야 하는데, 3개의 정수가 서로소라는 제약조건은 없다. 64처럼 지수가 6이면 $64 = 2^1 \times 2^2 \times 2^3$ 처럼 표현할 수 있기 때문에 인수와 지수 둘 다 중요하다.

TIL. Aug 8, 2026

Sat, 08 Aug 2026 21:38:24 +0900

오늘 한 내용

PS
- LeetCode 3302
- Codeforces 1294C
Stack Day의 컨셉과 MVP 범위 다시 정리
기존에 작성하던 Stack Day 코드를 정리하고, 다음 구현을 위한 기준 작성

배운 내용

LeetCode 3302와 CPU 스케줄링

문제를 보면서 예전에 풀었던 CPU 스케줄링 문제가 연상됐다. CPU 스케줄링은 현재 들어온 작업만 보고 결정하면 최적의 결과를 만들기 어렵고, 앞으로 어떤 작업이 들어올지까지 알아야 한다.

LeetCode 3302도 현재 인덱스에서 문자를 고를 때 뒤에 어떤 문자들이 남아 있는지를 알아야 했다. 실제 배열은 한 번에 주어지므로 미래를 기다릴 필요는 없지만, 인덱스 포인터의 시점에서는 뒤쪽 정보를 미리 알고 있어야 한다.

LeetCode 3302. Find the Lexicographically Smallest Valid Sequence

Sat, 08 Aug 2026 21:06:44 +0900

문제

https://leetcode.com/problems/find-the-lexicographically-smallest-valid-sequence

풀이

word1에서 인덱스를 고르고, 그 문자들로 word2를 만들면 된다. 선택한 문자는 순서를 유지해야 하고, word1의 문자 중 최대 하나는 다른 문자로 바꿔서 사용할 수 있다. 가능한 수열 중 인덱스가 사전순으로 가장 작은 것을 구하면 된다.

앞에서부터 무조건 현재 문자가 같은지 확인하면서 고르면 되지만, 문자가 다른 위치에서 변경 기회를 바로 사용해도 뒤쪽에 남은 문자를 모두 맞출 수 있는지 확인해야 한다. 즉, 현재 위치를 선택했을 때 남은 문자의 개수가 충분해야 한다.

TIL. Aug 7, 2026

Fri, 07 Aug 2026 22:07:31 +0900

오늘 한 내용

PS
- Codeforces 459B
dev-data-server-light
- Auth 기능 추가
- 에이전트 설정 정리
블로그 클론 이후 Mermaid 재설치와 npm audit 확인

배운 내용

AI 에이전트 설정 문서의 역할

AGENTS.md, Rule, Workflow, Skill의 역할을 다시 정리했다.

AGENTS.md: 프로젝트 구조, 아키텍처, 사용 기술처럼 항상 필요한 정보
Rule: 프로젝트 전반에서 지켜야 하는 규칙
Workflow: 반복 작업의 절차
Skill: 특정 분야의 지식과 작업 방법

모든 내용을 하나의 AGENTS.md에 넣기보다, 에이전트가 현재 작업에 필요한 컨텍스트만 읽을 수 있도록 성격과 범위에 따라 나누는 편이 낫다.

Codeforces 459B. Pashmak and Flowers

Fri, 07 Aug 2026 20:55:17 +0900

문제

https://codeforces.com/problemset/problem/459/B

풀이

n의 원소가 있는 수열 b가 주어진다. b의 원소 두 개를 짝지었을 때, 두 원소의 차이가 가장 클때의 그 차이와, 그 경우의 원소짝의 개수 출력하면 된다.

경우의 수를 구하기 위해 ‘가장 큰 값’을 가진 원소의 개수와 ‘가장 작은 값’을 가진 원소의 개수를 구해야 한다. 가장 큰 값을 가진 원소의 개수를 $maxCount$, 가장 작은 값을 가진 원소의 개수를 $minCount$ 라고 했을 때, 경우의 수는 $maxCount \times minCount$로 어렵지 않게 구할 수 있다.

TIL. Aug 6, 2026

Thu, 06 Aug 2026 22:58:30 +0900

오늘 한 내용

LeetCode 3345
Codeforces 489C
블로그 스크립트 구조화, npm run 스크립트 정리
StackDay 프로젝트 도메인, 데이터 모델, 유즈케이스, MVP 범위 정리
Codex SKILL 공부

배운 내용

그리디 의심하기

Codeforces 489C를 DP로 한참 구현하다가, 뒤늦게 그리디로 해결되는 문제라는 걸 알게 되었다.

PS에서는 완전탐색 → 그리디 → DP 순서로 가능성을 검토하는 습관이 중요한 것 같다. 그리디가 최적인 것을 증명하는 연습이 더 필요하다는 것을 느꼈다. 경험을 통한 직관으로…

정책 -> 도메인 -> 데이터 모델 -> 유즈케이스 순서로 사고하기

Day Stack을 한번 뒤엎어야 했던 어제의 실패를 반면교사 삼아서, 이번엔 실제 구현에 들어가기 전에 도메인과 정책부터 제대로 잡으려 했다.

Codeforces 489C. Given Length and Sum of Digits

Thu, 06 Aug 2026 13:40:23 +0900

문제

https://codeforces.com/problemset/problem/489/C

풀이

자리수가 m이고 각 자리수의 합이 s인 정수 중 가장 큰 수와 가장 작은 수를 찾는 문제이다.

처음에는 DP로 접근했는데, DP로는 수의 개수 정도만 구할 수 있고, 최대값과 최소값을 찾기는 힘들 것 같았다. 그래서 다시 그리디로 접근했다.

자리수가 m인데 $1 <= m <= 100$ 이기 때문에, int 타입으로 수를 다루는건 쉽지 않고, 배열이나 벡터로 다루는게 더 쉽다.

최대값은 계수가 높은 쪽에 큰 숫자를 배치하고, 최소값은 계수가 낮은 쪽에 큰 숫자를 배치하는 방법을 사용하자.

Leetcode 3345. Smallest Divisible Digit Product I

Thu, 06 Aug 2026 13:32:20 +0900

문제

https://leetcode.com/problems/smallest-divisible-digit-product-i

풀이

n보다 큰 수 중에서 각 자리수의 곱이 t로 나눌 수 있는(나머지가 0인 ) 가장 작은 수를 리턴해야 한다.

문제의 제약조건이 $1 <= n <= 100$, $1 <= t <= 10$ 이라서 모든 수를 찾아봐도 된다.

정수의 각 자리수를 모두 곱한 수를 구하는 로직만 구현한 후에, n 부터 시작해서 숫자를 1씩 증가시키면서 t로 나눈 나머지를 구해서 찾으면 된다.

코드

class Solution:
 def smallestNumber(self, n: int, t: int) -> int:
 def productDigits(x: int) -> int:
 product = 1
 while x > 0:
 product *= x % 10
 x //= 10
 return product
 answer = n
 while productDigits(answer) % t != 0:
 answer += 1
 return answer

TIL. Aug 5, 2026

Wed, 05 Aug 2026 21:30:22 +0900

오늘 한 내용

LeetCode 3310
Codeforces 451B
Stack day 코드 뒤엎기

배운 내용

Swift BFS에서 조금 더 쉽게 큐 사용하기

Swift에서 BFS 문제를 풀 때, 대부분 함수로 분리하고, struct Queue { ... } 처럼 헤더 포인터 변수를 사용하는 유사 큐를 만들어서 썼다.

struct Queue {
 //... 
}
func bfs(start: Int) {
 //... 
}

오늘 LeetCode 3310번 문제를 풀면서, 방문 체크 배열을 외부에서도 확인해야 하는 문제여서 inout으로 넘기기 보다는, BFS 로직을 인라인으로 쓰는 방법을 했는데, 생각해보니 큐도 그냥 BFS 로직 안에 인라인으로 쓰면 되지 않나 라는 생각이 들었다.

LeetCode 3310. Remove Methods From Project

Wed, 05 Aug 2026 21:10:33 +0900

문제

https://leetcode.com/problems/remove-methods-from-project

풀이

메소드 k에서 시작해서 도달할 수 있는 노드들을 ‘suspicious’ 하다고 했을 때, 이 ‘suspicious’한 메소드들을 k가 직, 간접적으로 호출하는 것을 제외하고도 호출되는 경우가 있는지 확인하고 있다면 전체 메소드를, 없다면 ‘suspicious’한 메소드를 제외하고 리턴하면 된다.

메소드들의 호출 관계가 단방향 엣지 그래프를 이루기 때문에, BFS나 DFS 무엇을 써도 쉽게 k가 직, 간접적으로 호출하는 함수들을 알 수 있다. k에서 시작해서 도달하는 모든 메소드들은 ‘suspicious’ 하기 때문에 방문 여부를 확인하는 배열을 그대로 사용하면 된다.

Codeforces 451B. Sort the Array

Wed, 05 Aug 2026 21:03:54 +0900

문제

https://codeforces.com/problemset/problem/451/B

풀이

n 크기 수열 a가 주어진다. 이 수열의 특정 구간을 선택해서 뒤집는 것을 1번 했을 때, 이 수열이 오름차순으로 정렬되어 있다면 "yes"와 그 구간을, 불가능하면 "no"를 출력하면 된다.

n의 제약 조건이 $1 <= n <= 10^5$ 이기 때문에, 브루트 포스로는 시간 내에 풀기 힘들다.

특정 구간을 선택해서 뒤집는 행동을 1번만 한다는 것이 힌트인데, 구간 하나를 1번 뒤집어서 수열 전체가 오름차순이 된다는 것은, 수열의 일부 구간만 내림차순 이라는 것이다.

TIL. Aug 4, 2026

Tue, 04 Aug 2026 23:50:02 +0900

오늘 한 내용

LeetCode 3731
Codeforces 580c
블로그 레이아웃, 숏코드, 콘텐츠, 스크립트, 기능 정리

ps

Codeforces 580c가 그래프(트리)를 순회하는 문제였는데, 각 노드의 값이 0 혹은 1이라서 bool 타입 벡터를 사용하고 입력을 받으려 했다.

vector<bool> a(n);

for (bool& ai: a) {
 std::cin >> ai;
}

아무런 이상이 없는 코드라고 생각했지만, 컴파일 에러가 생겼다. 이유를 조금 찾아보고 정리를 했는데 다음과 같다.

bool 타입을 원소로 가지는 벡터는 다른 벡터들과 다르게 각 원소를 1비트 단위로 압축해서 저장한다. (ex: 1010101...)
압축되어 저장되었기 때문에(그냥 비트에 녹아버렸으니까) 다른 타입의 벡터와 서브스크립트 접근 방식이 달라야 한다.
이를 해결하기 위해서 프록시 객체가 존재한다. a[3] = true; -> a.operator[](3).operator=(true);
만약 bool&을 통해 레퍼런스를 뽑아내려 하면, 프록시 객체 자체가 리턴된다.
결론적으로 vector<bool>에선 위의 코드같은 문법을 못 쓴다…

위와 같은 경우가 아니더라도, 굳이 bool 타입 벡터를 쓸 필요도 없는게, 프록시 객체가 원소를 뽑아오는 것도 다른 벡터보다 더 많은 계산 시간이 필요하다. 그래서 그냥 int 벡터로 문제를 풀었다.

Codeforces 580C. Kefa and Park

Tue, 04 Aug 2026 11:34:01 +0900

문제

https://codeforces.com/problemset/problem/580/C

풀이

노드의 값이 1 혹은 0인 트리 그래프와 그 크기인 정수 n이 주어진다. 루트 노드인 1번 노드에서 시작했을 때, 중간에 값이 1인 노드를 연속으로 m번을 초과해서 만날 수 없다. 이 때, 도달할 수 있는 리프 노드의 개수를 출력하면 된다.

트리 전체를 탐색하면서 연속으로 조우한 값이 1인 노드 개수를 관리하면 된다. 그리고 현재 방문한 노드가 리프 노드인지 판정하고, 만약 리프 노드면 1을 더하면 된다. 트리도 그래프이기 때문에, BFS, DFS 어느 쪽이든 가능하지만, 풀이를 할 때 DFS를 사용했다.

LeetCode 3731. Find Missing Elements

Tue, 04 Aug 2026 09:33:33 +0900

문제

https://leetcode.com/problems/find-missing-elements

풀이

연속된 정수 구간에 속한 모든 정수가 들어 있’던’ 수열 nums가 주어진다. 일부 원소가 사라진 상태인 상태인데, 이 사라진 원소들을 배열에 오름차순으로 담아 리턴하면 된다.

최대값과 최소값은 사라지지 않았다고 하니까, 정수 구간의 크기를 구할 수 있다. 그 정수 구간을 순회하면서 빠진 원소들을 찾으면 된다.

정렬을 이용해서 풀 수도 있는데, 이러면 시간 복잡도가 평균 $O(n \times \log n)$이 된다. 큰 차이는 안나지만 Hast Set을 이용하면 평균 $O(n)$에 풀 수 있다.

TIL. Aug 3, 2026

Mon, 03 Aug 2026 23:31:07 +0900

오늘 한 내용

LeetCode 1406 Stone Game III
Codeforces 520B Two Buttons
WWDC Meet async/await in Swift 세션 시청 및 정리.

배운 내용

PS

LeetCode 1406은 현재 차례인 플레이어가 상대보다 확보할 수 있는 최대 점수 차이를 DP로 정의해 풀었다. 누가 Alice인지 Bob인지에 따라 상태를 나누지 않아도, 현재 상태를 점수 차이로 표현하면 같은 점화식으로 문제를 풀 수 있다.

점화식이 안떠올라서 힌트를 보고 풀었다.

Codeforces 520B는 두 연산을 그래프의 간선으로 보고 BFS로 최단 거리를 구했다. 다만 목표값이 시작값보다 작을 때는 2배 연산이 도움이 되지 않으므로, 단순히 1씩 감소시키는 경우를 분리해 처리했다.

Swift Concurrency. Meet async/await in Swift (2) - WWDC21

Mon, 03 Aug 2026 23:01:47 +0900

1편에서는 async await를 어떻게 사용했는지 알아봤다면, 여기서는 테스트와 실제 앱 코드에서 async/await를 사용하는 법을 알아본다. 또한 기존에 존재하는 completion handler 기반 API를 continuation을 사용하여, async/await를 사용하는 async alternative로 변환하는 방법을 알아본다.

비동기 코드 테스트하기

async/await를 쓰면 비동기 코드도 동기 코드만큼 쉽게 테스트할 수 있다. XCTest는 async 테스트를 지원한다.

아래는 completion handler 방식의 비동기 코드를 테스트하는 코드이다.

class MockViewModelSpec: XCTestCase {
 func testFetchThumbnails() throws {
 let expectation = XCTestExpectation(description: "mock thumbnails completion")
 self.mockViewModel.fetchThumbnail(for: mockID) { result, error in
 XCTAssertNil(error)
 expectation.fulfill()
 }
 wait(for: [expectation], timeout: 5.0)
 }
}

기존에는 XCTestExpectation을 만들고, API를 호출한 뒤 expectation을 fulfill 하고, 지정한 시간 동안 기다리도록 작성해야 했다.

Swift Concurrency. Meet async/await in Swift (1) - WWDC21

Mon, 03 Aug 2026 20:03:38 +0900

completion handler로 작성한 비동기 코드는 쉽게 장황해지고, 복잡해지고, 부정확해진다.

Swift의 async/await는 비동기 코드를 일반 코드를 작성하는 것처럼 만들어 주고, 아이디어를 더 쉽게 반영하며, 더 안전하게 만든다.

async/await는 단순한 비동기 표현 방식이 아니다. 이 세션에서는 async/await가 왜 기존 completion handler 방식보다 좋은지, 그리고 Swift의 컨셉에 왜 잘 맞는지를 계속해서 설명한다.

Meet async/await in Swift

Foundation 같은 Apple SDK에는 await할 수 있는 수백 개의 메소드가 존재한다. UIKit의 UIImage는 섬네일을 만드는 API를 동기 방식과 비동기 방식으로 모두 제공한다.

Codeforces 520B. Two Buttons

Mon, 03 Aug 2026 13:30:19 +0900

문제

https://codeforces.com/problemset/problem/520/B

풀이

정수 n, m이 주어지고, 연산 2개 (* 2, - 1)을 이용해서 n을 m으로 만드는데 필요한 연산의 최소 개수를 출력하면 된다.

$1 <= n, m <= 10^4$ 제약조건과 2배로 만드는 연산을 생각해보면 만들 수 있는 숫자의 개수는 최대 2만개 정도이다. 이 숫자들을 각각을 노드라 생각하면, 연산으로 정의되는 노드간 연결도 명확한 그래프로 생각할 수 있다.

그러면 이 문제는 최단 거리 문제가 되므로 BFS를 사용해서 쉽게 풀 수 있다. 2배 연산이 있으므로 방문 확인 배열의 크기를 m * 2로 잡고 BFS를 하면된다. (방문 확인 배열도 할 겸 거리를 세는 기능도 넣으면 좋다.)

Leetcode 1406. Stone Game III

Mon, 03 Aug 2026 12:31:05 +0900

문제

https://leetcode.com/problems/stone-game-iii

풀이

번호가 적힌 돌이 있고, 두 명(Alice, Bob)이 번갈아 가면서 그 돌을 1개에서 3개까지 가져갈 수 있다. 2명 다 이상적으로 플레이 했을 때, 돌에 적힌 번호를 더한 합이 더 많이 가져간 사람의 이름을 리턴하면 된다. 항상 Alice가 먼저 시작한다.

약간 특이한 DP 문제이다. 점화식을 ‘Alice’ ‘Bob’을 특정하지 않고 ‘현재 차례인 사람이 상대보다 돌을 가질 수 있는 최대 개수’로 정의해야한다.

점화식은 다음과 같다.

$$ dp[i] = \max \begin{cases} stoneValue[i] - dp[i+1] \\ stoneValue[i] + stoneValue[i+1] - dp[i+2] \\ stoneValue[i] + stoneValue[i+1] + stoneValue[i+2] - dp[i+3] \end{cases} $$

TIL. Jul 31, 2026

Fri, 31 Jul 2026 21:00:57 +0900

오늘 한 내용

LeetCode 3016, LeetCode 1979 풀이
Codeforces 455A 풀이
AGENTS.md, SKILL.md 관련 자료 학습

배운 내용

PS

LeetCode 3016은 3014와 풀이가 동일했다. 문제의 제약 조건은 달랐지만, 3014를 풀 당시 더 큰 제약까지 고려해서 구현해 두었던 덕분에 그대로 통과할 수 있었다. 왜인지 3014가 Easy 문제치고는 생각보다 까다로운 편이었다.

Codeforces 455A는 전형적인 DP 문제였다. 다만 C++에서는 정수 범위를 고려해 long long을 사용해야 하는데, Swift와 Python만 주로 사용하다 보니 이 부분을 자주 놓치는 것 같다.

Leetcode 1979. Find Greatest Common Divisor of Array

Fri, 31 Jul 2026 20:36:12 +0900

문제

https://leetcode.com/problems/find-greatest-common-divisor-of-array

풀이

수열 nums의 원소 중 가장 큰 원소의 가장 작은 원소의 GCD를 리턴하면 된다.

처음에 max()와 min()을 썼는데, 제출 시간이 거의 최하위권이길래 for loop로 다시 작성했다.

GCD 자체는 유클리드 호제법을 이용해서 구한다.

코드

class Solution {
 func findGCD(_ nums: [Int]) -> Int {
 func gcd(_ a: Int, _ b: Int) -> Int {
 b == 0 ? a : gcd(b, a % b)
 }
 var min = Int.max
 var max = 0
 for num in nums {
 min = min > num ? num : min
 max = max < num ? num : max
 }
 return gcd(min, max)
 }
}

Codeforces 455A. Boredom

Fri, 31 Jul 2026 20:22:51 +0900

문제

https://codeforces.com/problemset/problem/455/A

풀이

배열a에서 얻을 수 있는 최대 점수를 구하는 DP 문제이다. 어떤 값 x를 선택하면 x만큼의 점수를 얻고, 배열에 있는 x - 1과 x + 1은 모두 제거된다.

여기서 중요한 점은 같은 값을 여러 개 가지고 있다면 하나씩 선택할 이유가 없다는 것이다. x를 선택하는 순간 x - 1과 x + 1은 모두 사용할 수 없으므로, 선택한다면 값이 x인 원소는 모두 선택하는 것이 항상 이득이다.

따라서 입력 배열의 순서는 의미가 없어지고, 각 숫자가 몇 번 등장하는지만 알면 된다. 값 x가 frequencies[x]번 등장한다면, x를 선택했을 때 얻는 점수는 x * frequencies[x]이다.

TIL. Jul 30, 2026

Thu, 30 Jul 2026 23:19:17 +0900

오늘 한 내용

Codeforces 279B
LeetCode 3014
과거 Bicubic, Smart CCTV 프로젝트 정리
미방문록 회의, AGENTS 수정.

배운 내용

SKILL 사용하기

프로젝트를 진행하면서 기본적인 개발 원칙은 AGENTS.md에 정리했다. 하지만 View, ViewModel, Test처럼 반복해서 만드는 코드까지 모두 AGENTS.md에 작성하는 것은 적절하지 않았다.

이런 작업은 프로젝트의 규칙이라기보다 반복 작업의 절차에 가깝기 때문이다.

예를 들어 View를 생성할 때는 ViewModel을 어떻게 주입할지, Preview를 어떻게 작성할지 등 항상 비슷한 패턴을 따른다. ViewModel이나 테스트 코드도 마찬가지다.

Codeforces 279B. Books

Thu, 30 Jul 2026 23:08:53 +0900

문제

https://codeforces.com/problemset/problem/279/B

풀이

책을 읽는데 걸리는 시간이 담긴 크기 n 배열 a가 주어지고, 책을 읽을 수 있는 시간 t가 주어진다. 특정 인덱스를 정해서 그 인덱스부터 책을 순서대로 읽었을때, 최대로 읽을 수 있는 책의 개수를 출력하면된다.

모든 경우의 수를 탐색하려면 $O(n^2)$의 시간 복잡도를 가지는데 책의 개수가 10만개 이므로, 시간 내로 해결하기는 힘들다.

‘순서대로’라는 조건이 있으므로, 투 포인터를 이용하면 쉽게 풀 수 있다.

단 배열 a의 원소의 크기가 t보다 클 수 있으므로, 단 한권의 책도 읽지 못하는 경우가 있다. 그래서 책을 0권 읽는 경우의 수도 생각해서 코드를 짜야 한다.

Leetcode 3014. Minimum Numbers of Pushes to Type Word I

Thu, 30 Jul 2026 22:58:21 +0900

문제

https://leetcode.com/problems/minimum-number-of-pushes-to-type-word-i

풀이

휴대전화의 2에서 8까지의 숫자에 문자를 배치할 수 있고, 2개 이상의 수가 배치되었을 땐 여러번 눌러야 뒤에 있는 숫자를 타이핑 할 수 있다. 스트링 word가 주어졌을 때, 버튼을 가장 적게 눌러 word를 타이핑 했을 때의 타이핑 수를 리턴하면 된다.

각 키의 첫 번째 문자는 1번, 두 번째는 2번… 눌러야 하므로 많이 등장하는 문자일수록 누름 횟수가 적은 앞자리에 배치해야 한다.

빈도수 내림차순 정렬 후, 인덱스를 8로 나눈 몫 + 1이 해당 문자의 누름 횟수가 된다.

TIL. Jul 29, 2026

Wed, 29 Jul 2026 20:53:29 +0900

오늘 한 내용

LeetCode 3518: Smallest Palindromic Rearrangement II
Codeforces 189A: Cut Ribbon
블로그 깃 훅 제거
블로그 스크립트 구조화
블로그 커밋 목록 정리

해결 내용

PS 두 문제를 푼 이후에, 블로그에서 스크립트와 깃 훅을 교체하고, 하루종일 깃과 씨름했다. Hugo 프로젝트의 커밋 로그가 너무 더러웠고, Squash, Rebase로 한 번 정리하려는데, 중간에 워킹 트리가 한번 꼬여버렸다.

블로그 깃 훅 일시 제거.

블로그 깃 훅에는 두 가지 문제가 있다. 첫 번째는 타이밍 문제다. pre-commit에 뭔가 내용을 수정하는 훅을 넣으면, 커밋이 멈추지 않고. 변경사항을 유지한채로 커밋되어버린다.

Codeforces 189A. Cut Ribbon

Wed, 29 Jul 2026 10:55:29 +0900

문제

https://codeforces.com/problemset/problem/189/A

풀이

길이가 n인 리본이 하나 주어지고, 이를 a, b, c 의 크기로만 조각낼 수 있을 때, 최대로 만들 수 있는 조각의 개수를 출력하는 문제이다.

잘린 리본 조각의 크기가 정해져 있으므로, 그리디가 아니라 DP로 접근해야 한다. 그리디로 접근하면 마지막에 남은 리본 조각의 크기를 확정할 수 없기 때문이다. dp[i]를 길이 i인 리본을 조각냈을 때의 최대 조각 수로 정의하면, 점화식은 다음과 같다.

$$dp[i] = \max_{x \in {a, b, c}}(dp[i - x] + 1) \quad \text{if } i \geq x \text{ and } dp[i-x] \neq -1$$

LeetCode 3518. Smallest Palindromic Rearrangement II

Wed, 29 Jul 2026 10:36:59 +0900

문제

https://leetcode.com/problems/smallest-palindromic-rearrangement-ii

풀이

1번 문제와 마찬가지로 팰린드롬의 성질상 절반만 결정하면 전체가 결정된다. 따라서 이 문제는 절반 문자열의 k번째 사전순 순열을 구하는 문제로 단순화된다.

각 문자의 등장 횟수를 세고, 홀수 번 등장하는 문자는 팰린드롬의 가운데에 배치한다. 나머지는 2로 나눠 halfTable을 만든다. 절반 문자열에는 중복 문자가 있을 수 있으므로, 전체 순열 수는 단순히 $n!$이 아니라 중복 순열 공식으로 구해야 한다.

$$\frac{n!}{\prod_{i} n_i!}$$

여기서 n은 절반 문자열의 길이, n_i는 각 문자의 개수이다. 이 값이 k보다 작으면 k번째 순열이 존재하지 않으므로 빈 문자열을 반환한다.

TIL. Jul 28, 2026

Tue, 28 Jul 2026 21:09:14 +0900

오늘 한 내용

배운 내용

C++ 배열 vs 벡터

Codeforces에서는 C++로만 코드를 작성하는데, 최근에는 벡터보다 C 스타일 배열을 선호했다. 그런데 오늘 T-Primes 문제를 풀면서 다시 벡터를 쓸까 고민했다.

가장 큰 이유는 보일러플레이트 때문이다. push_back 같은 벡터에서 편리한, 다른 언어에서는 당연히 있는 메소드가 배열에 없다. 결국 추가 코드를 작성하고 어느정도의 비효율이 생긴다. 그 외에도 배열은 함수에 넘길 때 크기를 같이 넘겨줘야 하는 번거로움이 있다. 글로벌 변수를 선호하지 않아서 레퍼런스를 파라미터로 와르르 넘기는 스타일을 쓰는데, 배열이면 크기도 같이 들고 다녀야 한다.

Codeforces 230B. T-Primes

Tue, 28 Jul 2026 10:39:27 +0900

문제

https://codeforces.com/problemset/problem/230/B

풀이

T-Prime을 약수가 3개인 수라고 정의하고, $n$개의 크기의 수열 $x$의 원소 각각에 대해서 그 수가 T-Prime인지 확인하는 문제이다.

약수가 3개라는 뜻은, $1$과 자기 자신 그리고 $\sqrt{x_i}$만을 약수로 가진다는 뜻이다. 즉, T-Prime은 어떤 수의 제곱이어야 한다.

그 ‘어떤 수’의 조건은 무엇일까? 약수의 약수는 결국 약수이다. T-Prime은 $1$, ‘어떤 수’, 자기 자신만을 약수로 가지므로, ‘어떤 수’는 소수여야 한다. 결국 이 문제는 소수 판별 문제로 단순화된다.

$x_i$의 최댓값이 $10^{12}$이지만, T-Prime 여부를 판별하려면 $\sqrt{x_i}$가 소수인지만 확인하면 되므로 체는 $\sqrt{10^{12}} = 10^6$까지만 구성하면 충분하다. 에라토스테네스의 체의 시간복잡도는 (거의) $O(N)$이고, 이후 각 쿼리는 $O(1)$에 처리되므로, $n \leq 10^5$인 입력 전체에 대해 전처리 $O(10^6)$ + 쿼리 $O(n)$으로 풀 수 있다.

Leetcode 3517. Smallest Palindromic Rearrangement I

Tue, 28 Jul 2026 09:12:06 +0900

문제

https://leetcode.com/problems/smallest-palindromic-rearrangement-i

풀이

팰린드롬 스트링 s가 주어지고, 이 s의 원소들을 재배열 하여 만들 수 있는 팰린드롬중 가장 사전순으로 빠른 문자열을 리턴하는 문제이다.

s가 팰린드롬 스트링인것이 보장되니, 팰린드롬의 성질인 대칭을 이용하면 정렬 문제로 바꿀 수 있다. s의 원소 개수가 홀수인지 짝수인지만 주의하면 된다. 만약 홀수면 대칭의 중심이 존재하니, 원소 중 등장 횟수가 홀수인 원소가 존재한다.

s에서 등장하는 모든 원소의 등장 횟수를 센다.
s의 원소 개수가 홀수라면, 원소들 중 홀수번 등장하는 원소를 center를 찾는다. 이 원소가 팰린드롬의 중간에 들어가는 문자이다.
원소들의 등장 횟수를 절반으로 줄인 다음, 사전 오름차순으로 정렬한 스트링 half를 만든다.
half와 center 그리고 half를 뒤집은 스트링을 합쳐서 결과를 만든다.

코드

class Solution {
 func smallestPalindrome(_ s: String) -> String {
 var countTable = [Character: Int]()
 var half = ""
 var center = ""
 for element in s {
 countTable[element, default: 0] += 1
 }
 for (element, count) in countTable.sorted(by: { $0.key < $1.key }) {
 if count % 2 == 1 {
 center = String(element)
 }
 half += String(repeating: element, count: count / 2)
 }
 return half + center + String(half.reversed())
 }
}

SwiftUI. Essentials - WWDC24

Mon, 27 Jul 2026 22:18:58 +0900

SwiftUI는 선언형 UI 프레임워크다.

Rich Feature Set, 다양한 기능과 기기 고유의 이점을 활용할 수 있는 풍부한 기능 집합
Less Code, 더 적은 코드
Incremental adoption, 필요한 순간에 적절하게 사용 가능. 전체 앱이 반드시 SwiftUI일 필요는 없다.

SwiftUI Essentials

SwiftUI는 선언형 UI 프레임워크이기 때문에 UIKit 처럼 UIView 객체가 계속 메모리에 상주해있고, 그 객체를 직접 변화시키는게 아니라, View를 보고 SwiftUI가 그리는 방식이다. 즉, View는 그냥 UI 요소를 정의하는 설계도이다. (Demistify SwiftUI 세션에서도 한 말이다!)

TIL. Jul 27, 2026

Mon, 27 Jul 2026 21:32:08 +0900

오늘 한 내용

각각 Hash Table과 구현 능력을 요구하는 PS 문제였다. IQ Test 부분이 구현이 살짝 번거로운 부분이 있었다.

SwiftUI. SwiftUI Essentials

WWDC 24에서 나온 SwiftUI Essentials 세션을 봤다. 24분 영상인데 정보 밀도가 엄청 높고 예제에서 보여준 것들도 많아서, 직접 예제를 돌리고 캡처하고, 동영상 녹화하고 하는데 꽤 시간이 들었다.

덕분에 블로그에 이미지 수평 배열, 이미지 캡션과 같은 숏 코드들도 추가했다.

배운 내용

SwiftUI Essentials

WWDC 세션을 하나 봤다. 이번에는 SwiftUI의 기본 구조를 다시 정리하는 내용이었는데, 핵심은 View가 실제 UI 객체를 직접 만지는 대상이 아니라 선언형으로 UI를 설명하는 값이라는 점 이었다(Demystify SwiftUI도 마찬가지고 엄청나게 반복되는 내용이다.)

Codeforces 25A. IQ Test

Mon, 27 Jul 2026 16:26:14 +0900

문제

https://codeforces.com/problemset/problem/25/A

풀이

n 개의 원소를 가진 수열이 입력으로 들어오고 입력으로 들어온 숫자 중 홀/짝이 다른 하나의 숫자의 인덱스(1-base 인덱스)를 출력하면 된다.

수열이 들어올 때마다 홀/짝 각각의 마지막 인덱스를 저장하고, 홀수의 개수, 짝수의 개수를 세면된다.

마지막 이렇게 얻어진 개수로 홀/짝인지 판별을 한 뒤에, 홀수면 짝수의, 짝수면 홀수의 마지막 인덱스를 출력하면 된다.

코드

#include <iostream>

int main() {
 int n;
 std::cin >> n;
 int oddCount = 0;
 int evenCount = 0;
 int oddIndex = 0;
 int evenIndex = 0;
 for (int i = 1; i <= n; ++i) {
 int number;
 std::cin >> number;
 if (number % 2 == 0) {
 evenCount++;
 evenIndex = i;
 } else {
 oddCount++;
 oddIndex = i;
 }
 }
 std::cout << (oddCount == 1 ? oddIndex : evenIndex) << std::endl;
}

Codeforces 4C. Registration System

Mon, 27 Jul 2026 11:07:19 +0900

문제

https://codeforces.com/problemset/problem/4/C

풀이

데이터베이스를 흉내내는 문제이다. n 개의 스트링이 입력으로 주어지고(각각의 스트링을 name 이라고 한다), 그 스트링이 만약 등록된 이름이면 이름 + 번호를 붙여서 출력하고 등록되지 않은 이름이면 'OK'를 출력하면 된다.

딕셔너리를 쓰면 가장 쉽게 해결 가능하다. 딕셔너리에 name을 키로, 그리고 등장한 횟수를 값으로 저장하면 쉽게 존재 판별과 번호 붙이기 둘 다 가능하다.

코드

#include <iostream>
#include <map>

int main() {
 int n;
 std::cin >> n;
 std::map<std::string, int> db;
 while (n--) {
 std::string name;
 std::cin >> name;
 if (db.find(name) != db.end()) {
 db[name]++;
 std::cout << name << db[name] << std::endl;
 } else {
 db[name] = 0;
 std::cout << "OK" << std::endl;
 }
 }
 return 0;
}

Leetcode 1464. Maximum Product of Two Element in an Array

Sun, 26 Jul 2026 10:34:58 +0900

문제

https://leetcode.com/problems/maximum-product-of-three-numbers

풀이

정수형 배열 nums 안에서 세 개의 수를 뽑아 곱한 값 중 최대값을 리턴하면 된다.

LeetCode 3536 3536번 문제처럼 nums 배열을 정렬하면 된다. 다만 이번에는 3개의 수를 뽑아야 하기에, 음수, 음수, 양수도 정답의 후보가 될 수 있다.

따라서 정답의 후보는 다음과 같다.

가장 작은 값 2개와 가장 큰 값 1개를 곱한 값
가장 큰 값 3개를 곱한 값

이 두 수를 계산한 다음, 대소를 비교해서 리턴하면 된다.

코드

class Solution:
 def maximumProduct(self, nums: List[int]) -> int:
 nums.sort()
 return max(nums[-1] * nums[-2] * nums[-3],nums[0] * nums[1] * nums[-1])

Leetcode 3536. Maximum Product of Two Digits

Sat, 25 Jul 2026 21:13:47 +0900

문제

https://leetcode.com/problems/maximum-product-of-two-digits

풀이

10 이상 10억 이하의 정수 n이 주어지고, 각 자리수 중 두 개를 골라서 곱한 값중 가장 큰 수를 리턴하면 되는 문제이다.

문제의 힌트에선 브루트 포스를 사용하라 했는데, 정렬하면 더 쉽게 풀 수 있다.

코드

class Solution:
 def maxProduct(self, n: int) -> int:
 digits = sorted(str(n), reverse=True)
 return int(digits[0]) * int(digits[1])

TIL. Jul 24, 2026

Fri, 24 Jul 2026 21:23:17 +0900

키워드

XOR 비트연산
Observation
블로그 스크립트 정리, git hook

내용

XOR 연산

LeetCode에 어제에 이어서 XOR 연산 문제가 나왔다. 일반적인 사칙연산과 다른 특징들을 사용해야하는 문제들이었다. 가장 큰 특징은 비트 연산은 비트 수가 고정되어 있어서 연산의 결과가 엄청나게 많은 경우의 수를 만들지 않는다.

예를 들어서, 곱셉의 경우에는 $10^3$ 미만의 두 수를 곱하면 최대 999 * 999 = 약 100만이 되어서 거의 7자리수의 경우의 수가 되는데, 비트연산은 더 이상 자리수의 확장이 일어나지 않는다.

SwiftUI. Discover Observation in SwiftUI - WWDC23

Fri, 24 Jul 2026 17:41:15 +0900

SwiftUI의 Observation은 모델의 프로퍼티 변화를 추적하고, 그 변화에 맞춰 UI를 업데이트하는 기능이다. @Observable 매크로를 사용하면 별도의 ObservableObject, @Published, @ObservedObject 없이도 일반 Swift 타입에 가까운 형태로 관찰 가능한 모델을 만들 수 있다.

핵심은 간단하다.

View가 읽은 프로퍼티가 바뀌면, 그 View가 다시 계산된다.

이 글에서는 Observation의 동작 방식, @State, @Environment, @Bindable을 언제 써야 하는지, 그리고 기존 ObservableObject 기반 코드를 @Observable로 옮기는 방법을 정리한다.

Observation

@Observable은 Swift 매크로다. 타입에 이 매크로를 붙이면 컴파일러가 해당 타입을 관찰할 수 있도록 코드를 확장한다.

Leetcode 3514. Number of Unique XOR Triplets II

Fri, 24 Jul 2026 11:34:15 +0900

문제

https://leetcode.com/problems/number-of-unique-xor-triplets-ii

풀이

n 길이의 배열 nums가 주어지고, 여기에서 3개의 인덱스 i, j, k를 (i <= j <= k) 뽑아서 XOR 했을 때, 얻을 수 있는 모든 결과의 수를 리턴하는 문제이다.

Leetcode 3513 문제와 다른 점은, nums가 순열이 아니다. 따라서, 자연스럽게 모든 경우의 수를 커버하지 못한다. 다만, 인덱스 제약조건이 저번과 같으므로 ‘값 3개를 무작위’로 뽑는다는 점은 같다. 여전히 n이 최대 1500이기 때문에, $O(n^3)$ 으로 풀기에는 무리가 있다.

우선, 값의 중복을 가리지 않고, 인덱스도 가리지 않으므로 배열의 순서가 중요하지 않다. 따라서 배열에 있는 모든 중복을 제거하는 전처리를 한다.

Codeforces 492B. Vanya and Lanterns

Fri, 24 Jul 2026 02:34:52 +0900

문제

https://codeforces.com/contest/492/problem/B

풀이

길의 길이 l과 가로등의 위치 배열 a가 주어지고, 모든 가로등이 길 전체를 비춰야 할때, 가로등 하나가 비추는 거리 d를 출력하는 문제이다.

문제 풀이는 단순하다. 가로등 사이의 간격을 계산하고, 그 간격을 모두 채울수만 있으면 된다.

가로등이 길을 비추는 건 3가지 케이스로 생각해볼수 있다.

시작 가로등
(양 옆에 가로등이 있는) 중간 가로등
끝 가로동

1번 3번 케이스가 엣지 케이스인데, 중간 가로등은 가로등 사이의 거리의 절반 만큼만 비추면 되지만, 시작 가로등과 끝 가로등은 시작점과 자신의 위치까지를 모두 스스로 비춰야 해서, 따로 처리해줘야 한다.

SwiftUI. The Swiftui Cookbook for Navigation - WWDC22

Thu, 23 Jul 2026 22:36:54 +0900

SwiftUI의 새로운 내비게이션 API를 발표한 WWDC 세션을 정리했다. 이 내비게이션 API는 각각의 NavigationLink가 관리하는 대신, 스택 전체의 상태를 데이터로 표현하고 직접 조작할 수 있게 만든다.

이 구조를 사용하면 버튼을 눌러 이동하는 기본적인 내비게이션뿐만 아니라, 딥 링크나 특정 화면으로 바로 이동하기, 루트 화면으로 돌아가기, 현재 내비게이션 상태 저장까지 같은 모델로 처리할 수 있다.

New naviation API: 새로운 Data-driven 내비게이션 API
Recipes for navigation: 탐색을 프로그래밍 방식으로 완전히 제어하기
Persistent state: 새로운 API를 이용하여 앱의 내비게이션 상태를 유지하기

Leetcode 3513. Number of Unique XOR Triplets I

Thu, 23 Jul 2026 10:33:25 +0900

문제

https://leetcode.com/problems/number-of-unique-xor-triplets-i

풀이

1에서 n까지의 모든 값이 들어있는 n 크기 배열 nums 배열이 주어지고, 그 배열에서 인덱스 3개 i, j, k (i <= j <= k)를 골라서 XOR 했을 때, 나올 수 있는 모든 값을 리턴하면 되는 문제이다.

nums 배열의 크기가 10만이고, 브루트 포스를하면 시간 복잡도가 $O(n^3)$ 이기 때문에 시간 내에 해결할 수 없다.

nums가 순열이라는 것과 XOR의 연산 특징을 알면 생각보다 간단한 공식으로 해결할 수 있다. 우선 인덱스 제약조건은 없는 것과 마찬가지인데, 등호를 포함한 대소관계이기 때문에, 인덱스를 중복해서 골라도 된다.

iOS. Demystify SwiftUI (3) - WWDC21

Wed, 22 Jul 2026 23:13:56 +0900

Dependencies: SwiftUI는 무엇이 바뀌었는지 어떻게 알까?

앞선 글에서는 SwiftUI가 View를 구분하는 방식인 Identity와, Identity가 유지되는 기간인 Lifetime을 정리했다. 이번에는 SwiftUI가 View를 업데이트하는 기준인 Dependencies를 살펴본다.

먼저 결론부터 말하면 SwiftUI의 업데이트 과정은 다음과 같다.

Dependency 변경
 ↓
관련된 View 무효화
 ↓
body 재평가
 ↓
새로운 View Value와 이전 Value 비교
 ↓
실제로 변경된 화면만 업데이트

Identity는 같은 View인지 판단하고, Lifetime은 상태를 유지하며, Dependency는 어떤 View를 다시 계산해야 하는지 결정한다. 이 세 가지를 함께 이해하면 단순히 API 사용법을 외우는 것보다 SwiftUI의 동작을 더 잘 예측할 수 있다.

TIL. Jul 21, 2026

Tue, 21 Jul 2026 23:59:22 +0900

키워드

Codeforces 가입
로컬 LLM opencode에 연결하고 ACP로 Xcode에 연동하기
SwiftUI WWDC 세션, 특히 View Value와 View Identity

내용

PS 풀기, Codeforces 가입

LeetCode에서만 문제를 푸는게 조금 시야가 좁아지나 싶어서, Codeforces에 가입했다. Swift 지원이 없지만, PS 문제를 풀 때 특정 언어에 종속되지 않으려고 꾸준히 Swift, Python, C++를 돌아가면서 풀고 있으니 큰 문제는 없다.

가장 풀이 수가 많은 문제 하나를 풀었다. 매일 LeetCode 오늘의 문제를 푸는 것이 루틴 중 하나인데, Codeforces, 삼성 SW Expert Academy 등 온라인 저지 사이트 여럿 돌아다니면서 풀어보려 한다. BOJ가 사라진 이후로 LeetCode 의존이 꽤 심해졌는데, 다양하게 풀어봐야겠다.

SwiftUI. Demystify SwiftUI (2) - WWDC21

Tue, 21 Jul 2026 21:42:49 +0900

Lifetime

1편에서는 SwiftUI가 View를 구분하는 방식인 Identity를 정리했다. 이번에는 Identity가 유지되는 시간인 Lifetime과, 그 안에서 State가 어떻게 보존되는지 살펴본다.

View Value는 계속 새로 만들어질 수 있지만, Identity가 유지되는 동안에는 같은 View의 Lifetime 안에 있다고 볼 수 있다. 그리고 State와 StateObject는 이 Lifetime에 연결되어 있기 때문에 Identity가 바뀌면 함께 교체된다.

고양이가 하루 동안 이곳저곳 움직이더라도 우리는 계속 같은 고양이라고 생각한다. 이처럼 Identity는 시간에 따라 달라지는 여러 값을 하나의 안정적인 존재로 연결한다. 시간의 흐름 속에서 연속성을 만들어 주는 셈이다.

DevOps. 로컬 LLM 모델 설치하고 UI 붙여보기

Tue, 21 Jul 2026 10:34:39 +0900

Codex는 iOS 개발할 때만 사용하고, 다른 작업은 주로 무료 모델로 처리했다.

dev-data-server-light를 개발할 때는 Cursor를 사용했는데, 개발 도중 사용량이 모두 소진돼 Antigravity로 옮겨야 했다.

그래서 로컬에서 직접 실행하는 LLM 환경을 찾았고, 생각보다는 쉽게 환경을 구축할 수 있었다., 맥미니에서 만족스럽게 사용하고 있다. 이번 글에서는 맥북 에어에도 같은 환경을 설치한 과정을 정리한다.

맥북 에어 사양

설치

ollama 설치하고 서버 켜기

맥에서는 Homebrew로 쉽게 설치할 수 있다.

brew install ollama

설치가 끝났으면 Ollama 서버를 켜야 한다. Ollama는 단순히 실행하는 앱이 아니라, 서버 형태로 동작한다.

LeetCode 3499. Maximize Active Section With Trade I

Tue, 21 Jul 2026 10:29:30 +0900

문제

https://leetcode.com/problems/maximize-active-section-with-trade-i

풀이

'0'와 '1'로만 이루어진 문자열 s가 존재하고, 문제에서 주어진 연산을 최대 1번 적용하여 문자열에 있는 '1'의 개수를 최대로 만든 뒤 그 개수를 리턴하면 된다.

주어진 연산은 다음과 같다. (순서대로 둘 다 적용해야 한다.)

양 옆이 '0'로 둘러싸인 연속된 '1' 블록 하나를 선택해서 모두 '0'로 바꾼다.
양 옆이 '1'으로 둘러싸인 연속된 '0' 블록 하나를 선택해서 모두 '1'으로 바꾼다.

문제에서 s의 양 옆에 '1'을 붙이라 했는데, 이때 추가된 '1'은 최종 반환값에 포함되지 않는다.

Codeforces 1A. Theatre Square

Tue, 21 Jul 2026 10:28:57 +0900

문제

https://codeforces.com/problemset/problem/1/A

풀이

Codeforces에서 푼 첫 문제.

$n \times m$ 크기의 직사각형 도시가 있고, 그 도시를 $a \times a$ 크기의 타일로 뒤덮는 문제이다. 타일은 도시 경계를 넘어가도 되지만, 잘라선 안되고 겹쳐도 안된다. 즉, 필요한 타일의 개수는 가로/세로 각각을 $a$로 나눈 값을 올림하여 곱하면 된다.

문제에 간단한 함정이 하나 있는데, n, m, a의 범위가 최대 $10^9$이라 곱셈 결과가 int 범위를 넘어갈 수 있으므로 long long을 사용을 사용해야 한다.

코드

#include <iostream>
#include <cmath>

int main() {
 long long n, m, a;
 std::cin >> n >> m >> a;
 std::cout << ((n + a - 1) / a) * ((m + a - 1) / a) << std::endl;
 return 0;
}

TIL. Jul 20, 2026

Mon, 20 Jul 2026 22:18:49 +0900

키워드

단조 스택
Hugo Flat Post -> Page Bundle
블로그 스크립트는 어떤 언어로?
Xcode 프로젝트명 바꾸기
SwiftUI Identity

내용

LeetCode 1081, Substring, Subsequence, Monotonic Stack

LeetCode 1081

PS 문제를 풀면서, 처음에 Medium 문제인데 좀 해맸다, LCS 두 개를 하면서 Substring이랑 Subsequence 차이를 분명히 알았는데, Substring으로 생각하고 풀어서 스택을 써야 할 곳에 투 포인터를 썼다.

단조 스택(Monotonic Stack) 문제인데, 사실 이런 스택이 있는지 오늘 처음 알았다. 그냥 스택은 스택으로 생각했으니까, 마치 Binary Search와 Parametric Search같은 느낌인가.

SwiftUI. Demystify SwiftUI (1) - WWDC21

Mon, 20 Jul 2026 21:51:21 +0900

Identity는 화면에 띄워지는 UI 요소들이 같은 요소인지, 다른 요소인지 구분하는 방식이다.

이 WWDC 세션에서 가장 중요한건, View 프로토콜을 채택하여 작성하는 View Structure가 실제 화면에 보이는 요소가 아니라 그냥 그 요소의 설계도일 뿐이라는 것이다. (UIKit과 많이 다르다)

Swift에서 ‘Value Type은 Immutablity를 가진다.’ 이라는 말이 가장 크게 체감되는 부분이기도 한데, SwiftUI에서 코드로 작성한 View도 Value Type이고 당연히 Immutable하다. 따라서 한 번 생성된 값은 변하지 않아야 한다. 만약 내부의 값이 변해야 하면 UIKit의 View Controller 처럼 은근슬쩍 내부 프로퍼티만 바꾸지 않고, Value 전체를 새로 만든다.

LeetCode 1081. Smallest Subsequence of Distinct Characters

Mon, 20 Jul 2026 00:00:00 +0000

문제

https://leetcode.com/problems/smallest-subsequence-of-distinct-characters

풀이

문자열 s에 있는 모든 개별 문자를 정확히 한 번씩 포함하는 부분수열 중, 사전순으로 가장 작은 것을 리턴하면 된다.

처음에 투 포인터를 생각했는데, 원소가 굳이 쭉 이어질 필요가 없으니 스택을 활용했다. 처음에 전처리로 각 문자의 마지막 등장 인덱스를 구해둔다.

스택 top의 마지막 인덱스가 현재 인덱스보다 크면 뒤에 또 나온다는 뜻이므로 제거할 수 있다. 스택에 문자를 추가하기 전, 아래 세 조건을 모두 만족할 때 top을 pop하면 된다.

스택이 비어있지 않다
스택 top이 현재 문자보다 크다 (사전순으로 뒤에 있다)
스택 top 문자가 뒤에 또 등장한다 (lastIndice[stack[-1]] > idx)

코드

class Solution:
 def smallestSubsequence(self, s: str) -> str:
 stack = []
 lastIndice = {}
 for idx, c in enumerate(s):
 lastIndice[c] = idx
 for idx, c in enumerate(s):
 if c in stack:
 continue
 while stack and c < stack[-1] and lastIndice[stack[-1]] > idx:
 stack.pop()
 stack.append(c)
 return "".join(stack)

LeetCode 1260. Shift 2D Grid

Mon, 20 Jul 2026 00:00:00 +0000

문제

https://leetcode.com/problems/shift-2d-grid

풀이

$m \times n$ 2d 그리드에 있는 원소들을 오른쪽으로 k번 민 결과를 리턴하면 된다.

grid[row][n - 1] → grid[row + 1][0] : 마지막 열의 원소는 다음 행의 첫 번째 열로 이동
grid[m - 1][n - 1] → grid[0][0] : 마지막 행의 마지막 열 원소는 첫 번째 행의 첫 번째 열로 이동

k번 직접 반복하는 대신, 그리드를 1차원으로 평탄화하면 shift 연산이 단순한 배열 회전으로 바뀐다.

평탄화한 배열을 오른쪽으로 k칸 회전시킨 뒤, 다시 $m \times n$ 2차원 배열로 복원하면 된다. 단, k가 배열 길이 $m \times n$ 보다 클 수 있으므로 모듈러 연산으로 정규화한다.

Leetcode 3867. Sum of GCD of Formed Pairs

Thu, 16 Jul 2026 10:29:15 +0900

문제

https://leetcode.com/problems/sum-of-gcd-of-formed-pairs

풀이

문제에서 지시한 내용을 그대로 구현하면 되는 문제다. 문제의 지시사항은 다음과 같다:

인티저 배열 nums의 누적 최대값 배열 mx를 만든다.
prefixGcd[i] = gcd(nums[i], mx[i]) 으로 이루어진 배열을 만든다.
prefixGcd를 오름차순 정렬한다.
prefixGcd의 제일 큰 값과 제일 작은 값의 쌍을 만들어, GCD를 구하는 것을 더 이상 만들지 못할 때 까지 반복한다. 만약 prefixGcd의 원소의 개수가 홀수라서 페어을 만들지 못한 하나가 남는다면 무시한다.
‘4’에서 구한 모든 GCD 값의 합을 리턴한다.

페어을 만드는건 간단한 형태의 투 포인터로 해결했다. 정렬과 유클리드 호제법을 제외하곤 모두 $O(n)$에 해결되기 때문에, 시간복잡도는 $O(n \log n + n \log V) = O(n \log (nV))$이다.

Leetcode 3658. GCD of Odd and Even Sums

Wed, 15 Jul 2026 10:32:37 +0900

문제

https://leetcode.com/problems/gcd-of-odd-and-even-sums

풀이

인티저 n이 하나 주어지고 작은 짝수 n개, 가장 홀수 n개를 각각 모두 더한 합 간의 GCD를 구하는 문제이다.

문제에서 요구하는 내용이 너무 간단해서, gcd()를 쓰지 않고, 유클리드 호제법을 직접 작성해서 GCD를 구했다.

코드

class Solution {
public:
 int gcdOfOddEvenSums(int n) {
 int sumOdd = 0;
 int sumEven = 0;
 for (int num = 1; num <= n * 2; num++) {
 if (num % 2 == 0) sumEven += num;
 else if (num % 2 != 0) sumOdd += num;
 }
 while(sumEven) {
 sumOdd %= sumEven;
 swap(sumOdd, sumEven);
 }
 return sumOdd;
 }
};

Leetcode 3336. Find the Number of Subsequences With Equal GCD

Tue, 14 Jul 2026 09:28:12 +0900

문제

https://leetcode.com/problems/find-the-number-of-subsequences-with-equal-gcd

풀이

수열 nums이 주어지고, nums에서 서로 원소가 겹치지 않게 부분 수열을 두 개 만든 뒤, 각 부분 수열(이하 A, B라 함)의 GCD가 같은 경우의 수를 찾는 문제이다.

만약 브루트 포스를 시도한다면, 원소의 개수 n, 각 원소가 가질 수 있는 상태가 3개(부분 수열 A, 부분 수열 B, 아예 미포함)이므로, 시간 복잡도가 $O(n \times 3^n)$ 이 되는데, nums의 최대 크기가 200이므로 유효한 시간 내에 해결할 수 없다.

하지만 부분 수열을 점점 채워나가면서 두 부분 수열을 비교할 수 있으므로, DP를 사용하면 O(n * 부분 수열A의 최대 gcd * 부분 수열B의 gcd 최대값)이 된다. 문제의 제약조건에서 원소의 최대 크기는 200이고, GCD는 원소보다 클 수 없으므로, $O(n \times 200 \times 200)$으로 줄일 수 있다.

Leetcode 1331. Rank Transform of an Array

Mon, 13 Jul 2026 11:09:28 +0900

문제

https://leetcode.com/problems/rank-transform-of-an-array

풀이

배열의 각 원소를 크기 기준으로 순위로 변환해 리턴하는 문제이다. 배열을 정렬한 뒤 각 원소에 순위를 매핑하고, 원본 배열 순서대로 순위를 꺼내 리턴한다.

문제에서 주의점이 하나 있는데, 같은 숫자는 같은 순위를 가진다는 것이다. 따라서 매핑할 때, 중복처리를 해줘야 한다.

코드

class Solution:
 def arrayRankTransform(self, arr: List[int]) -> List[int]:
 sortedArr = sorted(arr)
 rankDict = {}
 rank = 1
 for element in sortedArr:
 if not element in rankDict:
 rankDict[element] = rank
 rank += 1
 return list(map(lambda x: rankDict[x], arr))

Leetcode 1291. Sequential Digits

Mon, 13 Jul 2026 10:59:57 +0900

문제

https://leetcode.com/problems/sequential-digits

풀이

low와 high 사이의 수 중, 각 자릿수가 123, 3456 처럼 연속으로 이어지는 수를 모두 리턴하는 문제이다

문제와 제약조건을 보고 바로 DFS 백트래킹로 풀어야겠다는 생각을 했다. 구간의 크기가 최대 1억이기 때문에, 하나하나 확인하는 것은 무리가 있다. 따라서 수를 하나씩 붙여나가면서 확인하고, 조건에 벗어나면 프룬닝 하면 되는 전형적인 문제로 생각했다.

백트래킹으로도 충분히 빠른 속도로 문제를 풀 수 있지만, 문제를 제출하고 난 뒤 효율성을 검증해보니. high 크기가 최대 1억이기 때문에, 후보들의 수가 몇개 되지 않기 때문에, 실제로 자리수가 연속되는 모든 숫자들을 만들고 확인하는 방식이 더 빠를수도 있다고 한다.

TIL. Jul 13, 2026

Mon, 13 Jul 2026 00:00:00 +0000

키워드

Python 로컬 변수 스코프.
Python에서 람다식 정리, Swift 인라인 클로저와 다른점.
블로그 마이그레이션 하면서 이전에 썼던 iOS 관련 글 복습
블로그에서 카테고리를 몇개를 해야하는가?

내용

Python 로컬 변수 스코프 문제

Leetcode 1291번 문제를 푸는 도중에 다음과 같이 코드를 작성했다. 로직에 오류가 있어서 통과는 못하는 코드다.

class Solution:
 def sequentialDigits(self, low: int, high: int) -> List[int]:
 answer = []
 seq = []
 def dfs(n: int):
 if n > 9:
 return
 if seq:
 intSeq = int("".join(seq))
 if high < intSeq:
 seq = [] # 이부분
 return
 ...

seq 변수가 sequentialDigits 함수의 로컬 변수인데, if 문 안의 seq = [] 부분 때문에 에러가 났다.

TIL. Jul 12, 2026

Sun, 12 Jul 2026 21:21:18 +0900

오늘 한 내용

Hugo 블로그에서 Mermaid를 외부 CDN 없이 렌더링하도록 변경
Mermaid가 필요한 페이지에서만 스크립트를 로드하도록 최적화
hugo --minify로 빌드 검증

풀이

1번 문제와 로직은 동일하다. 차이점은 스트링 s의 서브스트링에 같은 작업을 queries마다 반복해야 한다는 점이다. queries의 원소가 최대 10만 개이므로, 매 쿼리마다 부분 문자열을 슬라이싱해서 처리하면 시간 초과가 난다. 따라서 전처리를 통해 각 쿼리를 $O(1)$ 혹은 $O(n \log n)$에 처리할 수 있도록 해야 한다.

전처리 단계에서 네 가지 누적 배열을 만든다.

pow10: $\text{pow10}[i] = 10^i \mod (10^9 + 7)$
preSum: 각 인덱스까지 자릿수의 합
preConcat: 각 인덱스까지 0이 아닌 숫자들을 이어붙인 값
nonZeroCount: 각 인덱스까지 0이 아닌 숫자의 개수

쿼리 [l, r]이 들어오면 네 배열로 x와 sum을 $O(1)$에 구해 $x \times \text{sum} \mod (10^9 + 7)$를 리턴한다. 0이 아닌 숫자가 없는 경우는 수식이 자연스럽게 $0$을 리턴하게 된다.

LeetCode 3754. Concatenate Non-Zero Digits and Multiply by Sum I

Tue, 07 Jul 2026 14:30:01 +0900

문제

https://leetcode.com/problems/concatenate-non-zero-digits-and-multiply-by-sum-i

풀이

문제에서 주어진 조건에 따라서 스트링을 조작하면 되는 간단한 문제이다. 인티저에서 스트링으로, 스트링에서 인티저로 타입 컨버전만 조심하면된다.

주어진 정수 n을 스트링으로 변환한 다음, 앞에서부터 순회하여 "0"을 제거한 스트링 filtered를 만든다.
filered를 인티저로 타입 컨버전 해서 x를 구한다.
filered의 각 원소를 인티저로 컨버전 한 다음, 합을 구해서 sum을 구한다.
x * sum을 리턴한다.

코드

class Solution:
 def sumAndMultiply(self, n: int) -> int:
 filtered = "".join(char for char in str(n) if char != "0")
 if not filtered:
 return 0
 return int(filtered) * sum(map(int, filtered))

LeetCode 1288. Remove Covered Intervals

Mon, 06 Jul 2026 12:33:49 +0900

문제

https://leetcode.com/problems/remove-covered-intervals

풀이

여러 개의 구간이 주어지고, 다른 구간에 완전히 포함되는 구간을 제거한 이후, 남은 구간의 개수를 리턴하면 되는 문제이다.

가장 쉬운 방법은 브루트 포스이다. 구간의 개수가 최대 1000개이기 때문에, O(n^2) 방식을 사용해도 충분히 통과 가능하다.

하지만 정렬을 이용하면 쉽게 O(n * log(n)) 으로 풀 수 있다.

구간 시작 부분을 기준으로 오름차순 정렬한다. 시작 부분이 같은 경우엔 끝 부분을 기준으로 내림차순 정렬한다.
정렬된 배열을 앞에서부터 순회하며, 지금까지 등장한 끝 부분의 최대값(maxEnd)을 추적한다.
현재 구간의 끝이 maxEnd보다 크면, 이전 어떤 구간에도 포함되지 않는 새로운 구간이므로 카운트하고 maxEnd를 갱신한다.
현재 구간의 끝이 maxEnd보다 작거나 같으면, 이전 구간에 완전히 포함되는 구간이므로 제거한다.

1번에서 시작 부분 기준으로 정렬했기 때문에, 시작 조건은 자동으로 만족되어 끝 부분만 비교하면 충분하다.

LeetCode 1301. Number of Paths with Max Score

Sun, 05 Jul 2026 14:30:01 +0900

문제

https://leetcode.com/problems/number-of-paths-with-max-score

풀이

2차원 그리드의 우하단에서 시작해 좌상단까지 이동하면서, 경로에 있는 숫자들의 합의 최대값과 그 최대값이 나오는 경로의 개수를 구하는 문제이다.

최단 거리를 찾는 문제가 아니므로 BFS나 Dijkstra는 필요 없고, 어떻게 경로의 수를 구할지가 핵심이다. 이동 방향은 문제에서 주어져 있으므로, 각 노드에서 인접한 노드들의 값을 활용해 특정 합(v)에 도달하는 경로의 개수를 구할 수 있다.

이런 문제를 효율적으로 푸는 방법은 결국 DP이다. 처음에 점화식을 이렇게 만들었다.

dp[r][c][v]: row = r, column = c인 노드에서 지나온 경로에 있는 칸들의 합이 v가 되는 경로의 개수.

테스트 케이스는 통과할 수 있었지만, 실제 제출했을 때는 시간 초과가 되어서 통과하지 못했다. v 차원 때문에 dp공간이 너무 커지는 것이 문제였다.

TIL. Jul 2, 2026

Thu, 02 Jul 2026 00:00:00 +0000

요약

오늘은 0-1 BFS를 문제에 적용해 보면서 알고리즘 선택의 중요성을 느꼈다. 또한 티스토리 블로그를 Hugo로 이전하기 위한 마이그레이션 스크립트를 작성하며 HTML을 Markdown으로 변환했다.

배운 것

0-1 BFS

LeetCode 3286. Find a Safe Walk Through a Grid
사용 언어: Python, Swift
사용 알고리즘: Dijkstra, 0-1 BFS

그동안은 거리 개념이 나오면 무조건 다익스트라를 사용했는데, 처음으로 0-1 BFS를 이용해서 문제를 풀었다. 같은 문제를 Python에서는 다익스트라로 풀었고. 0-1 BFS는 Swift로 풀었다.
기존에 Swift에서 BFS를 사용할 때는 배열과 인덱스 포인터를 이용한 유사 Queue를 사용했는데, 이 방식으로는 큐의 헤드에 원소를 push하는 메소드를 구현하기 어려워서 배열을 사용했다. 문제의 제약조건이 널널해서 배열로 충분히 통과했는데, 어떻게 해야할지는 고민해봐야 할 것 같다. Linked List를 이용해서 큐를 만들면 되지만, 이게 힙와 다익스트라를 쓰는 것보다 코드를 작성하는 입장에서 효율적일지는 잘 모르겠다.

Archive. System Programming 정리 노트

Mon, 29 Jun 2026 16:38:00 +0900

학부연구원 시절 FPGA랑 임베디드 살짝 하면서 적어놨던 노트를 최근 클라우드 정리할 때 발견해서, 간단하게 블로그에 포스팅함.

RTOS

RTOS(Real-Time Operating System)는 정해진 시간 안에 작업을 수행하는 것을 보장하도록 설계된 운영체제이다.

일반적인 운영체제와 다르게 RTOS는 작업이 정해진 시간 내에 반드시 수행되는 예측 가능성을 가장 중요하게 생각한다. 산업용 장비, 자동차, 드론, 의료기기와 같은 임베디드 시스템에서 주로 사용된다.

UART

UART(Universal Asynchronous Receiver/Transmitter)는 가장 널리 사용되는 직렬 통신 방식 중 하나이다.

구조가 단순하고 구현이 쉬워 디버깅 콘솔, 센서, 마이크로컨트롤러 간 통신 등에 자주 사용된다. 다만 송신과 수신 장치가 동일한 통신 속도(Baud Rate)를 사용해야 한다.

TIL. Jun 19, 2026

Fri, 19 Jun 2026 20:06:46 +0900

오늘 한 내용

AGENTS.md, AGENTS.override.md의 적용 순서 정리
전역 규칙과 프로젝트 규칙이 어떻게 병합되는지 확인

배운 내용

규칙 파일은 전역에서 프로젝트 하위 디렉토리로 내려오면서 적용된다. 같은 디렉토리에서는 AGENTS.override.md가 AGENTS.md보다 우선하고, 하위 디렉토리의 규칙이 더 구체적인 지침으로 해석된다.

결국 규칙은 전역에서 프로젝트 루트, 현재 작업 디렉토리 순서로 합쳐진다. 공통 원칙은 위쪽에 두고, 특정 모듈의 세부 규칙은 아래쪽에 두는 이유가 여기에 있다.

해결 내용

전역 원칙은 전역 규칙에, 프로젝트 공통 원칙은 루트에, 모듈별 세부 지침은 하위 디렉토리에 두는 계층을 정리했다. 더 가까운 디렉토리의 규칙이 구체적인 지침으로 적용된다는 점도 확인했다.

TIL. Jun 17, 2026

Wed, 17 Jun 2026 21:52:31 +0900

오늘 한 내용

Antigravity의 Rules, Skills, Workflows 구조 정리
dev-data-server-light의 AGENTS 규칙을 새 구조에 맞춰 마이그레이션

배운 내용

Antigravity의 핵심 구조는 다음처럼 정리할 수 있다.

Rules = 행동 규칙
Skills = 특정 분야의 지식과 노하우
Workflows = 작업 절차

Rules는 항상 지켜야 할 원칙을 정의하고, Skills는 Storage 설계나 코드 리뷰처럼 특정 작업에 필요한 전문 지식을 담는다. Workflows는 계획, 구현, 테스트처럼 작업을 어떤 순서로 진행할지 정의한다.

기존 AGENTS.md를 그대로 옮기는 것이 아니라, 공통 원칙과 모듈별 규칙을 분리해야 했다. 규칙을 작게 나누면 모든 작업에 불필요한 문맥을 주입하지 않으면서도 필요한 순간에 더 구체적인 지침을 적용할 수 있다.

TIL. Jun 16, 2026

Tue, 16 Jun 2026 20:29:07 +0900

오늘 한 내용

Antigravity IDE의 에이전트, 에디터, 터미널, 브라우저 구조 살펴보기
File Storage 구현 순서와 StorageService 설계

배운 내용

Antigravity는 에디터 안에서 에이전트가 작업을 수행하고, 브라우저와 터미널을 사용해 결과를 검증하는 개발 환경이다. Agent는 기능 개발이나 버그 수정처럼 실제 작업을 담당하고, Tab은 자동완성에 가깝다.

File Storage는 먼저 계약을 만들고, 그 다음 fs/promises 기반 구현체와 테스트를 추가한 뒤, Express와 분리된 Service를 얹는 순서로 진행하기로 했다. 처음부터 multipart 업로드까지 확장하지 않고, JSON과 단순한 파일 콘텐츠로 흐름을 검증하는 것도 중요한 범위 조절이었다.

TIL. Jun 11, 2026

Thu, 11 Jun 2026 21:36:55 +0900

오늘 한 내용

배운 내용

기존에는 Route가 Database 인터페이스를 직접 사용했다. 리팩터링 후에는 Route -> DatabaseService -> RecordStore -> InMemoryRecordStore 흐름으로 바꾸었다.

RecordStore는 레코드를 저장하고 꺼내는 교체 가능한 capability이고, DatabaseService는 여러 저장소 동작을 조합하는 use case다. 예를 들어 replace 이후 갱신된 레코드를 반환하거나, 삭제 결과에 따라 오류를 판단하는 흐름은 Service가 맡는다.

File Storage도 같은 기준을 적용했다. 계약은 key와 Uint8Array만 사용해 작고 명시적으로 만들고, 로컬 파일 시스템이나 경로 검증은 구현체 안에 가둔다.

TIL. Jun 9, 2026

Tue, 09 Jun 2026 20:48:13 +0900

오늘 한 내용

LeetCode 3689, 2574 풀이
dev-data-server-light의 AGENTS.md 구조 정리
루트와 모듈별 개발 규칙의 중복 검토

배운 내용

새 디렉토리 구조에서는 공통 원칙을 루트 AGENTS.md에 모으고, 모듈에만 해당하는 규칙은 해당 모듈의 문서에 두는 방향이 적절하다.

루트에는 TypeScript, Express, Vitest 같은 기술과 전체 아키텍처, 테스트 원칙을 둔다. 반면 DB 모듈의 레코드 모델이나 저장소 구현 규칙처럼 다른 모듈이 알 필요 없는 내용은 DB 문서에 남긴다.

중복된 규칙은 단순히 길이의 문제가 아니다. 같은 내용이 여러 파일에 있으면 나중에 한쪽만 수정될 수 있고, AI가 서로 다른 지침으로 해석할 가능성도 생긴다.

TIL. Jun 8, 2026

Mon, 08 Jun 2026 21:04:28 +0900

오늘 한 내용

dev-data-server-light의 계층형 구조를 모듈형 구조로 바꾸는 작업 검토
AGENTS.md가 새 디렉토리 구조와 충돌하지 않도록 정리
Database, Route, Service의 책임 재검토

배운 내용

기존 구조는 routes, services, db처럼 계층별로 나뉘어 있었다. 새 구조에서는 모듈이 자신의 계약, 구현체, 서비스, 라우트를 함께 소유하도록 바꾸려 했다.

계층형 구조에서는 AGENTS.md에 각 계층의 역할을 적기 쉬웠지만, 모듈형 구조에서는 모듈의 책임과 공개 API를 기준으로 규칙을 작성해야 한다. 구조가 바뀌면 문서도 함께 바뀌어야 하며, 기존 규칙을 억지로 유지하면 오히려 AI가 잘못된 경계를 학습하게 된다.

TIL. Jun 4, 2026

Thu, 04 Jun 2026 20:17:42 +0900

오늘 한 내용

dev-data-server-light의 DB 모듈 설계 정리
System 모듈과 DB 인터페이스 구현 방향 검토
저장소와 애플리케이션 로직의 경계 정리

배운 내용

이름도 설계의 일부

처음에는 DocumentStore, StoredDocument, DocumentBody라는 이름을 사용했다. 하지만 DB CRUD 인터페이스를 설계하는 과정에서 이 이름들이 프로젝트가 특정 Document Database를 전제로 한다는 인상을 준다는 것을 발견했다.

In-Memory, SQL, JSON File 등 여러 구현을 염두에 둔다면 인터페이스도 구현 방식에서 자유로워야 한다. 그래서 RecordStore, StoredRecord, RecordData처럼 더 중립적인 이름으로 바꿨다.

TIL. May 21, 2026

Fri, 22 May 2026 00:00:00 +0000

요약

LeetCode 문제를 풀면서 자료의 표현 방식이 성능에 큰 영향을 준다는 점을 다시 확인했다. 또한 Express의 req, res, next()가 어떻게 협력하여 요청을 처리하는지 파이프라인 관점에서 정리했다.

배운 것

LeetCode 3043 최적화

LeetCode 3043번 문제를 풀었다. 두 정수형 배열에 있는 원소들 중 임의의 두 수를 선택했을 때, 공통의 일치하는 prefix의 최대 길이를 구하는 문제였다.

우선, 각 배열의 길이가 최대 50000이기 때문에, 가능한 모든 쌍을 만들어서 크기를 구하는 방식으로 하면 시간복잡도가 O(n²)이 되어서 문제를 제 시간 안에 해결하기 힘들다. (n은 둘 중 긴 배열의 원소의 개수)

TIL. May 19, 2026

Tue, 19 May 2026 00:00:00 +0000

요약

Express의 핵심 구성 요소와 요청 처리 흐름을 정리했다. 특히 Middleware가 특정 객체가 아니라 요청 처리 과정에서 동작하는 함수들의 역할이라는 점과, Express가 함수형 체인이 아닌 공유 객체(req, res)를 사용하는 파이프라인 구조라는 점을 이해하게 되었다.

배운 것

오늘 공부한 내용

Express의 App, Router, Middleware
Express의 동작
Express의 간단한 내부 구조

Express의 핵심 구성 요소

처음에는 Express를 iOS의 MVC에서 View를 제거한 형태 정도로 생각했다. Route Handler가 Controller 역할을 하는 것이라고 생각했다. Express를 구성하는 핵심 요소는 크게 다음과 같다.

미방문록. PoC 대표 색상 추출 Picker 만들기

Mon, 09 Feb 2026 17:36:10 +0900

음식 사진에서 색상을 뽑아서 카드의 배경색에 적용하는 기능을 구현해야 했다.

처음 생각한 방향

원본 이미지를 그대로 다루면 비용이 크다.
색이 너무 많으면 후보가 지저분해진다.
원하는 색이 반드시 많이 나오는 색은 아니다.
결과를 화면에 어떻게 보여줄지도 같이 고민해야 한다.

직접 구현해보자.

외부 라이브러리를 쓰기보다는, 가능한 경우에는 항상 먼저 구현해보고 그 이후에 외부 라이브러리를 쓰는 방향을 선호하기 때문에, 직접 구현해보기로 했다.

학부 시절에 이미지 프로세싱을 하기도 했고 나름대로 흥미롭게 접근했다.

CoreGraphics에서 픽셀 읽기

색상을 추출하려면 결국 이미지의 픽셀 값에 접근해야 했다.

Archive. NVIDIA Physical AI 생태계 정리 노트

Fri, 06 Feb 2026 01:39:00 +0900

최근 NVIDIA의 피지컬 AI 생태계를 접할 기회가 있었는데, Omniverse, Isaac Sim, Cosmos, GR00T처럼 처음 보는 용어가 한꺼번에 등장해서 각각이 어떤 역할을 하는지 궁금해졌다.

조금 찾아보니 개별 기술을 각각 봐서 이해하긴 어렵고, 전체 구조를 보면서 어떤 역할을 하는지 이해하는 것이 중요하다는 생각이 들었다.

그래서 나중에 다시 봐도 흐름을 빠르게 떠올릴 수 있도록 핵심 개념을 간단히 정리했다.

피지컬 AI

현실 세계를 인식 → 판단 → 물리적으로 행동하는 AI 시스템 전체를 의미한다. 디지털 AI와 달리 센서 불확실성, 실시간 제어, 물리 상호작용이 핵심 난이도다. (현직자도 단순히 소프트웨어로 처리하는 것 만으로는 충분하지 않다고 했다.)

Algorithm. Kadane's Algorithm

Tue, 25 Nov 2025 00:00:00 +0000

소개

1차원 배열이 주어졌을 때, 연속된 구간의 최대 합을 구하는 알고리즘을 카데인 알고리즘이라고 한다.

예를 들어 다음 배열이 있다면,

[-2, 1, -3, 4, -1, 2, 1, -5, 4]

연속된 구간 [4, -1, 2, 1]의 합인 6이 가장 크다.

카데인 알고리즘은 앞에서 계산한 결과를 재활용하여 배열을 한 번만 순회한다. 따라서 시간 복잡도 O(n), 공간 복잡도 O(1)로 문제를 해결할 수 있다.

아이디어

현재 원소에서 끝나는 연속 구간의 최대 합을 유지하고 다음 원소를 만났을 때 기존 구간을 이어가는 것과 현재 원소부터 새로운 구간을 시작하는 것 중 더 큰 값을 선택한다.

Docker. Dockerfile 작성하기

Thu, 09 Oct 2025 00:00:00 +0000

컨테이너를 실행하려면 먼저 이미지가 필요하고, 이미지는 Dockerfile이라는 파일을 통해 생성한다.

예제 Dockerfile을 기준으로 각 명령어가 어떤 역할을 하는지 살펴본다.

Dockerfile 구조 살펴보기

먼저 예제 Dockerfile을 보자.

FROM python:3.13
WORKDIR /usr/local/app

# Install the application dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# Copy in the source code
COPY src ./src
EXPOSE 8080

# Setup an app user so the container doesn't run as the root user
RUN useradd app
USER app

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]

이제 위 Dockerfile을 한 줄씩 살펴보자.

Docker. 내 애플리케이션 Dockerizing 하기

Thu, 09 Oct 2025 00:00:00 +0000

0. 기반 파일

https://github.com/nice-card/express-example

1. 프로젝트 위치 확인

현재 경로를 프로젝트 경로로 설정하고 확인하기

2. Dockerfile, .dockerignore 추가

프로젝트 루트에 Dockerfile을 새로 만들기.

Dockerfile

프로젝트 루트에 만들기.

# === build stage ===
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci # dev 포함 (tsc 사용)
COPY . .
RUN npm run build # dist/ 생성

# === runtime stage ===
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev # 런타임에 필요한 것만

# 빌드 결과만 가져오기
COPY --from=build /app/dist ./dist

EXPOSE 3000
CMD ["npm", "start"] # package.json의 "start": "node dist/index.js"

.dockerignore

불필요한 파일이 이미지에 안 들어가게 막는 용도

Docker. 이미지 Build하고 Push하기

Thu, 09 Oct 2025 00:00:00 +0000

사전준비하기 & Docker Hub

Docker Hub

Docker 이미지를 공유하기 위해서는 이미지를 저장할 공간이 필요하고, 이 때 Docker Hub가 이미지 저장소로 사용된다. 다른 사람들이 올린 이미지를 검색하여 실행하거나 자신의 이미지를 기반으로 사용할 수 있는 공간을 제공한다.

컨테이너 이미지

컨테이너 이미지는 애플리케이션을 실행하기 위한 파일, config, 종속성을 모두 포함한 표준화된 패키지이다. 이미지를 배포하면 다른 사람과 공유할 수 있다.

Docker Hub에 이미지 푸시하기

GitHub가 소스 코드를 저장하는 것처럼 Docker Hub는 컨테이너 이미지를 저장한다.

Docker. Docker Desktop 실습해보기

Wed, 08 Oct 2025 00:00:00 +0000

설치하기

공식 문서에 설치 가이드 설명 잘 되어있으니 알아서…

첫 번째 컨테이너 실행하기

docker run -d -p 8080:80 docker/welcome-to-docker

http://localhost:8080 에서 이 컨테이너의 프론트엔드 방문 가능.

Docker Desktop 사용해보기

컨테이너 탭

Logs — docker logs <container-name>
- 컨테이너 내부에서 실행 중인 프로세스의 표준 출력을 그대로 보여줌.
- 디버깅할 때 많이 사용하는 부분
Inspect — docker inspect <container-name>
- 컨테이너의 환경 변수, 포트 바인딩, 실행 명령, 마운트 경로, 네트워크, 상태 등 메타데이터를 JSON으로 보여줌
Bind mounts
- 로컬 호스트와 컨테이너 사이의 폴더 연결 정보를 보여줌
  - ex) -v ~/project:/app → 내 컴퓨터의 ~/project 폴더가 컨테이너 내부 /app에 연결됨.
- 로컬 파일 수정 시 컨테이너에 즉시 반영되기 때문에 개발할 때 자주 사용
Exec — docker exec -it <container-name>
- 실행 중인 컨테이너 내부에 직접 명령어를 입력할 수 있는 쉘 세션을 엶.
- 컨테이너 내부 구조 탐색, 빠른 테스트, 수동 디버깅에 사용
Files — docker cp, docker exec ls
- 컨테이너 내부의 파일 시스템 탐색
- 호스트 ↔ 컨테이너 간 파일을 복사할 수 있음
Stats: docker stats <container-name>
- 컨테이너의 실시간 리소스 사용량(CPU, 메모리, 네트워크, I/O) 등을 모니터링
- 성능 문제나 리소스 병목을 추적할 때 사용
- 여러 컨테이너 동시 모니터링 가능

직접 컨테이너를 사용해서 개발해보기

0. 프로젝트 클론

우선 Docker에서 제공하는 예제 앱 가져오기

Docker. Docker 시작하기

Wed, 08 Oct 2025 00:00:00 +0000

Docker

애플리케이션 개발, 배포 및 실행을 위한 개방형 플랫폼

특징

Note.

컨테이너는 개발 환경 자체가 아니라 애플리케이션를 실행하는 격리된 프로세스다. 일반적으로 개발은 호스트 환경에서 이루어지고, 컨테이너는 실행 및 테스트 환경으로 사용된다.

-> 그런데 vscode에서 쓰는 dev container는…?

컨테이너를 사용한 앱 개발

Docker 컨테이너 안에서 앱을 띄우기 때문에 “환경이 달라서 동작하지 않는다”와 같은 문제 해결
ex. Node, Python, MySQL같은 것을 도커로 묶어서 개발

컨테이너는 완전한 실행 단위

컨테이너 하나는 완전한 실행 단위이기 때문에 QA, 테스트, CI/CD 환경에서 그대로 사용
같은 이미지 → 같은 코드, 같은 환경 → 어디서든 일관된 실행이 가능하다.

애플리케이션을 컨테이너 형태로 배포

클라우드나 로컬 서버로 그대로 옮겨서 실행하면 된다.
수명 주기 관리
- build, run, stop, rm, push 모든 것을 Docker가 명령어 단위로 관리해준다.

반응형 배포 및 확장

Docker는 어디서나 똑같이 돌고, 원하면 즉시 늘리거나 줄일 수 있다.

Docker. 컨테이너와 이미지

Wed, 08 Oct 2025 00:00:00 +0000

컨테이너

애플리케이션의 구성 요소(프론트엔드, API, DB 등)을 각각 격리된 프로세스로 실행하는 환경.

특징

호스트의 어떤 환경에도 의존하지 않고, 필요한 라이브러리와 설정을 모두 포함한 독립된 환경으로 존재한다.
서로 다른 컨테이너는 격리되어 있어서 하나가 망가져도 다른 컨테이너에 영향을 주지 않는다.

컨테이너 vs. VM

VM은 자체 커널, 드라이버, 프로그램을 갖춘 완전한 운영체제이기 때문에, 단일 애플리케이션을 분리하기 위해 VM을 사용하는 것은 오버헤드가 크다.

컨테이너는 실행에 필요한 모든 파일을 갖춘 고립된 프로세스이다. 여러 컨테이너를 실행하더라도 모두 동일한 커널을 공유하므로, 더 적은 인프라에서 많은 애플리케이션을 실행할 수 있다.

Node. TypeScript 프로젝트 초기화하기

Wed, 08 Oct 2025 00:00:00 +0000

새로운 노드 프로젝트 생성하기

npm 초기화부터

npm init -y

Node 프로젝트를 초기화한다. 이 명령을 실행하면 현재 디렉터리에 package.json 파일이 생성되고, Node와 npm은 이를 기준으로 프로젝트를 관리한다.

npm install

npm install -D typescript tsx @types/node @types/express

npm install: 필요한 패키지를 설치하는 명령이다. 뒤에 패키지 이름을 지정하면 해당 패키지를 설치하고, package.json에도 자동으로 기록한다.
-D: --save-dev의 약자이다. 개발 과정에서만 사용하는 패키지를 devDependencies에 추가한다. TypeScript처럼 빌드 과정에서만 필요한 도구들이 여기에 해당한다.
패키지
- typescript: TS 컴파일러 (tsc 명령어 제공)
- tsx: TS 파일을 빌드 없이 바로 실행하게 해주는 도구 (dev 서버용)
- @types/node: Node.js의 타입 정의
- @types/express: Express 라이브러리의 타입 정의

Note.

JavaScript. 모듈 시스템

Tue, 07 Oct 2025 00:00:00 +0000

프로젝트가 커질수록 모든 코드를 하나의 파일에 작성하기는 어렵다. 그래서 JavaScript는 기능별로 코드를 여러 파일로 나누어 관리하며, 각각의 파일을 모듈(Module)이라고 한다.

모듈 시스템은 이러한 모듈을 다른 파일에서 가져오고 내보내는 방법을 정의한다.

주요 모듈 시스템

CommonJS (CJS)

CommonJS는 Node.js 초창기부터 사용된 모듈 시스템이다. require로 다른 모듈을 가져오고, module.exports로 외부에 공개할 값을 내보낸다.

// math.js
function add(a, b) {
 return a + b;
}
module.exports = { add };

// main.js
const math = require('./math');
console.log(math.add(2, 3));

위 예시에서 module.exports는 add 함수를 다른 파일에서도 사용할 수 있도록 내보낸다. main.js에서는 require를 통해 해당 모듈을 가져와 math.add()를 호출한다.

Node. Node.js 소개

Sun, 05 Oct 2025 00:00:00 +0000

Node.js는 브라우저 밖에서도 JavaScript를 실행할 수 있게 해주는 런타임이다.

구조

Node.js를 설치하면 JavaScript 런타임 하나만 설치되는 것이 아닌, 프로젝트 관리, 외부 라이브러리, 개발 도구를 실행하기 위한 여러 구성 요소가 함께 설치된다.

Node

JavaScript 실행 환경이다. 브라우저 외부에서 JS를 실행할 수 있게 해준다.

간단한 파일은 다음처럼 직접 실행할 수도 있다. (다른 언어들과 비슷하다.)

node <FILE-NAME>.js

npm(Node Package Manager)

Node 프로젝트의 패키지 관리자이다. 외부 라이브러리를 설치하고, 제거하고, 프로젝트의 의존성을 관리한다.

외부 라이브러리를 설치할 때는 다음 명령을 사용한다.

SwiftUI 상태 관리

Thu, 25 Sep 2025 00:00:00 +0000

상태를 누가 소유하고 어떻게 전달해야 하는가

SwiftUI에서는 상태를 저장하거나 다른 뷰에 전달할 때 프로퍼티 래퍼를 사용한다.

이 상태를 현재 뷰가 직접 가지고 있는지, 부모 뷰에서 전달받는지, 아니면 별도의 객체가 관리하는지에 따라 사용하는 래퍼가 달라진다.

상위 뷰 → 하위 뷰

@State → @Binding

상위 뷰가 상태를 소유하고, 하위 뷰는 해당 상태를 수정할 수 있도록 @Binding으로 전달받는다.

뷰 모델 → 뷰 → 하위 뷰

ObservableObject 프로토콜을 채택한 뷰 모델에서는, 변경을 알려야 하는 값을 @Published 프로퍼티로 선언한다.(이 뷰 모델을 뷰에서 주입받아 사용할 때는 보통 @ObservedObject로 관찰함)

Swift Concurrency. Behind the Scenes - WWDC21

Mon, 25 Aug 2025 00:00:00 +0000

Threading model

뉴스 피드 리더 앱을 예로 들어보자. 앱의 상위 컴포넌트는 다음과 같이 나눌 수 있다.

사용자 인터페이스를 담당하는 메인 스레드
사용자가 구독한 뉴스 피드를 추적하는 데이터베이스
최신 콘텐츠를 가져오는 네트워킹 서브시스템

사용자가 최신 뉴스를 요청하면 다음과 같은 흐름으로 처리할 수 있다.

메인 스레드에서 이벤트 제스처 처리
데이터베이스 작업을 처리하는 직렬 큐로 요청을 비동기적으로 디스패치
- 작업을 다른 큐로 보내면 메인 스레드는 데이터베이스 작업을 기다리지 않고 사용자 입력에 계속 반응할 수 있다.
- 직렬 큐가 상호 배제를 보장하므로 데이터베이스 접근을 순서대로 처리할 수 있다.
데이터베이스 큐에선 사용자가 구독한 피드에 URLSession을 통해 콘텐츠를 다운로드하는 네트워크 요청을 스케줄링
결과가 도착하면 URLSession의 콜백이 Delegate Queue 위에서 호출되어서 각 결과의 Completion Handler가 동기적으로 데이터베이스를 업데이트한다.
MainThread를 깨워서 UI를 리프레시한다.

보기에는 합리적인 방법이다. 메인 스레드를 블록하지 않으면서 네트워크 요청을 동시에 처리할 수 있기 때문이다.

Programmers. 미로 탈출 명령어

Sat, 23 Aug 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/150365

풀이

분명히 배열(문자열)의 원소를 하나씩 채워나가야 하는 DFS 완전 탐색 스타일의 문제인데 k의 최대값이 2,500으로 너무 크다. 하지만 문제에서 주어진 조건들을 읽어보면 프루닝을 통해 백트래킹 문제로 만들 수 있다.

현재 위치와 종료 위치 사이의 맨하탄 거리가 남은 이동 횟수보다 적으면, 더 이상 탐색할 필요가 없다.
- 목표에 도달하지 못하는 분기이기 때문에, 분기를 버려야 한다.
남은 이동 횟수와 현재 위치와 종료 위치 사이의 맨하탄 거리의 차가 홀수인 경우에도 더 이상 탐색할 필요가 없다.
- 이동 횟수는 고정이고, 두 위치의 거리보다 크다면 이동 횟수를 어딘가에서 소모해야한다. 그런데 다른 위치로 갔다가, 다시 현재 위치로 돌아올때 소모하는 값은 2이므로, 홀수인 경우에는 목적지에 절대 도달할 수 없게 된다.
마지막으로, 탐색 순서를 잘 정했다면 처음으로 성공한 케이스가 곧 사전순에서 가장 앞선 순서가 된다. 한 번만 성공하게 되면 그 뒤의 모든 분기는 의미가 없어진다.

풀이

단순 구현으로 풀 수 있는 문제다. 문제를 단순화하면 조건에 맞는 최대 값을 구하는 문제이므로 바이너리 서치도 쓸 수 있겠다.

우선 시간을 다루는 문제에서는 시간, 분을 분으로 통일하는 경우가 더 시간을 다루기 쉬워지는 경우가 많다. 예를 들어서 셔틀의 첫 도착 시간인 9:00을 540으로 바꾸는 것이다.

그리고 timetable 배열의 길이가 최대 2000이므로 모든 배열을 순회해도, 심지어 $O(n^2)$시간으로 순회해도 아무런 걱정이 없다. 따라서 앞 번호부터 순서대로 버스에 태우면 된다. 이제 마지막 버스인 경우에 콘이 탈 수 있는 여유가 있다면, 마지막 버스의 도착 시간을 리턴하면 되고, 만약 여유가 없다면, 마지막 버스에 마지막으로 타는 사람보다 ‘1분’ 일찍 나오면 된다.

Swift Concurrency. 01. 도입 배경

Sun, 03 Aug 2025 00:00:00 +0000

Swift Concurrency는 Swift 5.5에서 도입된 기능이다. Foundation을 import 해야 쓸 수 있는 GCD와 다르게, Swift 언어 자체에 내장된 동시성 모델이다.

Swift Concurrency는 크게 두 가지 부분으로 나뉘어진다.

async, await 로 작성하는 새로운 동시성 모델
애플리케이션을 여러 동시성 태스크로 분할하는 Actor

이 포스트에서는 Swift Concurrency의 도입 배경을 알아본다.

GCD의 한계

GCD는 Objective-C에서부터 사용해온 애플이 만든 비동기 API다. Queue 기반으로 작업을 스케줄링 하고, 스레드 위에서 추상화 되어있기 때문에 스레드를 직접 생성하거나 관리할 필요가 없다.

Programmers. 디스크 컨트롤러

Sat, 02 Aug 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/42627

풀이

우선 순위대로 문제를 처리하므로 힙을 써야하는 것은 명확하다. 하지만, 이 힙을 어떻게 다루느냐가 더 중요한 문제이기 때문에 사실상 힙보다는 단순 구현 문제에 가깝다.

코드

import heapq

def solution(jobs):
 jobs.sort(key = lambda x: x[0])
 waitQueue = []
 finished = 0
 currentTime = 0
 jobIdx = 0
 totalReturnTime = 0
 while finished < len(jobs):
 while jobIdx < len(jobs) and jobs[jobIdx][0] <= currentTime:
 requestTime, duration = jobs[jobIdx]
 heapq.heappush(waitQueue, (duration, requestTime))
 jobIdx += 1
 if waitQueue:
 duration, requestTime = heapq.heappop(waitQueue)
 currentTime += duration
 returnTime = currentTime - requestTime
 totalReturnTime += returnTime
 finished += 1
 else:
 currentTime = jobs[jobIdx][0]
 return totalReturnTime // len(jobs)

Programmers. 징검다리 건너기

Tue, 22 Jul 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/64062

풀이

처음 문제를 읽어보고 바이너리 서치를 이용해야겠다고 생각했다. 결정해야 할 값을 건널 수 있는 최대 인원수로 맞춰놓고 바이너리 서치를 이용하여 찾으면 되기 때문이다.

바이너리 서치를 이용한 알고리즘은 다음과 같다.

바이너리 서치를 통해 찾고 싶은 값은 징검다리를 건널 수 있는 최대 인원 수이다.
징검다리 하나의 내구도가 최대 2억이므로 1에서 2억까지의 범위 내에서 인원 수의 최대값을 찾는다
1. 값이 유효한지 체크하는 방법은 징검다리에서 현재 인원 수가 밟은 수를 뺀 다음 0 이하의 징검다리 돌들이 연속되는 경우가 k개 이하면 통과, 초과면 통과시키지 않는다.
바이너리 서치 결과를 리턴한다.

이 코드의 시간 복잡도는 $N$이 stones 배열의 크기, $M$이 돌 내구도의 최대값이라 했을 때 $O(N \log M)$이다. 돌 내구도의 최대값은 2억이고, 2의 30제곱이 약 10억이므로 30번 이내에 찾을 수 있다. 최대 20만 크기의 배열을 30번 정도 반복한다고 생각하면 충분히 시간 복잡도가 나온다.

iOS. 파일 시스템과 샌드박스

Mon, 21 Jul 2025 00:00:00 +0000

앱은 종료된 뒤에도 데이터를 유지하기 위해 파일 시스템을 사용한다. iOS, macOS 같은 애플 플랫폼에서는 APFS(Apple File System)라는 파일 시스템을 쓴다. 애플은 사용자 파일과 앱 내부 파일을 분리해서 관리하는 것을 목표로 한다.

개발자 문서에서는 파일 시스템의 목표를 다음과 같이 제시한다.

사용자 파일은 쉽게 찾을 수 있도록 한다.
앱 내부적으로 사용하는 파일은 사용자 눈에 띄지 않도록 한다.

많은 파일 시스템처럼 APFS도 디렉토리 구조를 통해 계층적으로 파일을 관리한다. 모든 디스크가 ‘단일 파일 컬렉션’을 구성한다는 점이 특징이다. 즉, 여러 디스크를 연결해도 사용자에게는 하나의 계층에 있는 것처럼 보인다.

Programmers. 단속 카메라

Mon, 21 Jul 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/42884

풀이

그리디 문제다. 그리디는 따로 정석 구현이 있는 알고리즘이 아니라 일종의 컨셉이지만, 배열 + 그리디면 잘 알다시피 정렬이 중요한 경우가 많다.

단순하게 생각해보자, 문제에서 주어지는 것은 시작 위치와 종료 위치다. 그냥 종료하는 위치를 기준으로 오름차순 정렬한 후에 앞에서부터 탐색을 한다.

현재 자동차의 종료 위치에 카메라를 설치하고, 다음 자동차를 살펴본다. 다음 자동차의 시작 위치가 이전 자동차의 종료 위치(즉 카메라가 설치된 위치)보다 앞에 있으면 다음 자동차도 설치된 카메라를 만나게 된다. 그렇지 않다면 또 그 자동차의 종료 위치에 카메라를 설치하면 된다.

Programmers. 불량 사용자

Mon, 21 Jul 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/64064

풀이

일정 크기의 배열(혹은 컬렉션)을 만들어서 매칭되는지 확인해야 하는 문제다.

DFS를 사용해서 모든 경우의 수를 만들기는 쉽지만, 그 경우의 수가 문제에서 제시하는 조건에 맞는지 확인하는 것은 어렵다. 따라서 알고리즘을 약간 수정해서 좀 더 효율적이고 만들기 쉬운 알고리즘을 만들어야 한다.

알고리즘은 다음과 같다:

주어진 banned_id 배열 원소 하나하나에 대응가능한 id를 user_id에서 뽑아서 후보 set에 넣는다.
1번을 재귀적으로 진행한다. set에 담는 이유는 id가 중복되면 안되기 때문이다.
후보 set이 완성되면, 정답 set에 저장한다. set은 set에 담을 수 없으므로 frozenset을 이용한다.
정답 set의 개수를 리턴한다.

코드

def compare(strA, strB):
 if len(strA) != len(strB):
 return False
 for char in zip(strA, strB):
 if char[0] != char[1] and char[1] != '*':
 return False
 return True

def dfs(user_id, banned_id, index, candidateSet, idSet):
 if index == len(banned_id):
 idSet.add(frozenset(candidateSet))
 return
 for id in user_id:
 if id in candidateSet:
 continue
 if compare(id, banned_id[index]):
 dfs(user_id, banned_id, index + 1, candidateSet + [id], idSet)

def solution(user_id, banned_id):
 idSet = set()
 dfs(user_id, banned_id, 0, [], idSet)
 return len(idSet)

Programmers. 최고의 집합

Sun, 20 Jul 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/12987

풀이

n의 값이 최대 10000, s의 값이 최대 1000000의 값을 가질 수 있으므로 모든 경우의 수를 DFS로 탐색하는 것은 매우 비효율적이다.

하지만 수학적 직관을 이용해 생각해보자. 예시로 주어진 s = 9, n = 2인 경우에서도 {4, 5}가 최고의 집합이다. 만약 s = 5, n = 2인 경우에는? {2, 3}이다. s = 10, n = 2인 경우는 {5, 5} 이다. 집합 원소들이 최대한 고르게 되어있을 때 원소들의 곱이 최대가 된다는 것(= 최고의 집합이라는 것)을 알 수 있다. 그러면 이 직관을 증명해보자.

Algorithm. Bit masking

Thu, 12 Jun 2025 00:00:00 +0000

기본 소개

비트 마스킹은 비트 연산을 활용해서 집합을 구현하는 방법이다. 각 자리수의 비트는 하나의 원소를 나타내며, 이 원소들이 모여서 집합을 구성하게 된다.

예를 들어, 원소 A, B, C, D를 각각 다음과 같이 표현할 수 있다:

let A = 0b0001 // 1
let B = 0b0010 // 2
let C = 0b0100 // 4
let D = 0b1000 // 8

혹은 쉬프트 연산을 활용해서 표현할 수도 있다. 이 방법이 조금 더 직관적이고 단순하다:

let A = 1 << 0
let B = 1 << 1
let C = 1 << 2
let D = 1 << 3

이렇게 원소들을 정의하게 되면, 각 원소들이 각각의 자릿수를 점유하고 있기 때문에 겹칠 일이 없다. 따라서 2진수로 쉽게 집합을 표현할 수 있다.

Call by reference와 Call by pointer의 차이

Sat, 07 Jun 2025 00:00:00 +0000

Call by reference와 call by pointer는 모두 호출자가 가진 객체를 함수 안에서 변경할 수 있어 비슷해 보인다. 하지만 C++ 언어에서 파라미터가 가지는 의미와 사용할 수 있는 연산은 다르다.

Pointer를 값으로 전달하기

포인터 파라미터는 주소를 저장한 포인터 객체를 값으로 전달받는다. 함수는 복사된 포인터를 역참조해 호출자의 객체를 변경할 수 있다.

void updateByPointer(int* value) {
 if (value != nullptr) {
 *value = 10;
 }
}

int number = 0;
updateByPointer(&number);

포인터 자체는 복사본이므로 함수 안에서 다른 주소를 대입해도 호출자가 가진 포인터 변수는 바뀌지 않는다.

SniffMEET. Xcode 프로젝트 파일 정리하기

Thu, 05 Jun 2025 00:00:00 +0000

작업 내역

Xcode에서 프로젝트 파일 관련 경고가 많이 떠서 정리했다.

작업 내역

null 파일 제거

320043702CDC9A0D00D08B6D /* (null) in Sources */ = {isa = PBXBuildFile; };
320043722CDC9E5F00D08B6D /* (null) in Sources */ = {isa = PBXBuildFile; };
320043762CDCA18E00D08B6D /* (null) in Sources */ = {isa = PBXBuildFile; };
320043782CDCA49100D08B6D /* (null) in Sources */ = {isa = PBXBuildFile; };
3200437C2CDCA6F300D08B6D /* (null) in Sources */ = {isa = PBXBuildFile; };

이전에 있었던 구조 변경이나, git 충돌/머지 등 다양한 이유로 프로젝트 파일 안에 (null) 파일을 참조하는 라인이 많이 있었다.

Swift. C부터 시작하는 메소드 디스패치

Sat, 31 May 2025 00:00:00 +0000

Introduction

메소드 호출이란 과연 무엇일까? 우리가 평소에 사용하는 메소드 호출은 내부적으로 어떻게 동작하는지 궁금해진 적이 있다. C++로 PS를 풀 때 가끔 함수 포인터를 써야 하는 경우가 생기는데, Swift에서 클로저를 이용하는 것과 비슷하지만 주변 값을 캡처할 수 없다는 특징이 있다. 함수 포인터는 C에도 존재하는 개념이므로, 다음과 같이 생각이 뻗어나갔다.

함수 포인터와 C 스타일 스트럭처를 사용하면 C언어에서도 OOP 스타일의 메소드가 구현 가능할 것 같다.

생각이 계속 확장되다 보니 실제 OOP 언어의 클래스 구현도 이런 방식으로 되어있지 않을까? 라는 생각에 도달했고, 메소드 디스패치를 포함해서 여러 개념들을 이어서 생각해볼 수 있었다.

OS. Operating System 오버뷰

Sat, 17 May 2025 00:00:00 +0000

운영체제(OS)

컴퓨터 하드웨어와 사용자 사이에서 중간 역할을 수행하며, 하드웨어 자원을 효율적이고 안전하게 관리하고, 사용자 프로그램이 원활하게 실행되도록 지원하는 시스템 소프트웨어

커널

운영체제의 핵심 부분, 하드웨어와 직접 상호작용 하여, 자원 관리와 시스템 콜 처리를 담당하는 코드 영역, 일반적으로 운영체제는 커널을 지칭한다.

역할

운영체제는 CPU, 메모리 등의 하드웨어를 효율적으로 사용할 수 있도록 관리하고, 애플리케이션이 자원을 효율적으로 할당받아 문제 없이 실행될 수 있도록 한다.

CPU 관리(CPU 스케줄링)

CPU가 실행 중인 프로그램을 모두 동시에 실행할 수 있는 것은 아니므로, 프로그램들이 효율적으로 CPU를 할당받도록 할당 순서와 사용 시간을 결정하는 역할

DB. Database 오버뷰.

Sat, 03 May 2025 00:00:00 +0000

데이터베이스(Database, DB)

여러 사람이 공동으로 사용하기 위해 통합, 저장하여 운영하는 데이터들의 집합

특정 조직(서비스)의 업무를 수행하는데 필요한 상호 관련된 데이터들의 모임이다.

DBMS(Database Management System)

데이터베이스를 관리하기 위한 프로그램, 대표적으로 SQL을 사용하는 관계형 데이터베이스(RDBMS)가 있고, SQL을 사용하지 않는 NoSQL DBMS도 있다.

관계형 데이터베이스(Relational DB, RDB)

2차원 표를 이용해서 데이터간의 상호 관계를 정의하는 데이터베이스

스키마(Schema)

데이터베이스의 구조와 제약 조건에 대한 전반적인 명세. 엔티티, 어트리뷰트, 릴레이션, 제약 조건 등을 전반적으로 정의한 DB의 구조적 정의

BOJ 12852. 1로 만들기 2

Wed, 30 Apr 2025 00:00:00 +0000

문제

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

풀이

DP를 사용해서 해결했다.

문제를 거꾸로 뒤집어보자. n에서 1을 가는 최단거리가 아니라, 1에서 n으로 가는 최단거리로 바꾸는 편이 편하다.

이렇게 뒤집으면 개별 숫자에서 다른 숫자로 갈 수 있는 방법은 3가지가 주어진다.

1 더하기
2 곱하기
3 곱하기

쉽게 점화식을 만들 수 있다.

dp[i] = max(dp[i - 1], dp[i / 2], dp[i / 3]) + 1

하지만 경로도 트래킹 해야 하는데, 이건 각 개별 숫자에 도달하기 전에 어떤 수에서 왔는지를 저장하는 배열 하나를 만들고, 최종적으로 이 배열을 루프로 순회하거나, 재귀를 통해서 경로를 얻어낼 수 있다.

BOJ 2193. 이친수

Wed, 30 Apr 2025 00:00:00 +0000

문제

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

풀이

문제에서 명시적으로 두 가지 조건을 제공해준다.

0으로 시작하지 않는다.
1이 연속되지 않는다.

이진수라는 조건도 있으므로, 3가지 조건이 있다고 볼 수 있다.

케이스를 몇개 써보면 쉽게 DP로 풀 수 있는걸 알 수 있다.

dp[1] = 1 // 1
dp[2] = 1 // 10
dp[3] = 2 // 100, 101
dp[4] = 3 // 1000, 1001, 1010

2번째 조건 때문에, 0으로 끝나는 경우에는 1을 붙일 수 있지만, 1로 끝나는 경우에는 0으로 붙일 수 없는 것을 알 수 있다.

DP 테이블을 다음과 같이 정의하자.

Algorithm. LIS(Subsequence)

Thu, 03 Apr 2025 00:00:00 +0000

소개

수열의 원소를 골라내서 만든 부분 수열 중, 각 원소가 이전 원소보다 크면서, 가장 긴 길이를 가지는 부분 수열을 찾는 알고리즘

DP 방식과 Binary Search를 쓰는 Greedy 방식 두 가지가 있으며, 별개의 방식이 아닌 두 방식이 밀접하게 연관되어 있다.

아이디어

LIS는 현재까지 구한 부분 수열의 결과를 이용해 더 긴 부분 수열을 만들어 나가는 문제이다.

DP는 이전 계산 결과를 이용해 현재 상태를 구하며, Binary Search를 이용한 방식은 같은 아이디어를 유지하면서 탐색 과정을 최적화한 것이다.

Software Engineering. DI와 DIP

Thu, 27 Mar 2025 00:00:00 +0000

의존성 주입(Dependency Injection)

의존성 주입은 객체가 필요한 의존성을 내부에서 직접 생성하지 않고 외부에서 전달받는 방식이다. 별도의 DI 프레임워크나 주입 전용 객체가 반드시 필요한 것은 아니다. 생성자를 통해 객체를 전달하는 것만으로도 의존성 주입이 된다.

의존의 의미

A → B: A가 B에 의존한다.

A가 동작하기 위해 B의 타입이나 기능을 사용한다면 A는 B에 의존한다. B의 공개 인터페이스가 바뀌면 A도 영향을 받을 수 있다.

다음 코드에서 Greeter는 구체 타입인 EnglishGreetingProvider를 직접 생성한다.

final class EnglishGreetingProvider {
 func greeting() -> String {
 "Hello, World!"
 }
}

final class Greeter {
 private let provider = EnglishGreetingProvider()

 func greet() {
 print(provider.greeting())
 }
}

이 구조에서는 구현을 교체하거나 테스트 대역을 사용하려면 Greeter를 직접 수정해야 한다.

Network. VPN(Virtual Private Network)

Tue, 04 Mar 2025 00:00:00 +0000

소개

VPN은 공용 네트워크를 이용하여 사설 네트워크처럼 안전하게 통신할 수 있도록 하는 기술이다.

공용 네트워크를 통해 사설 네트워크처럼 안전하게 데이터를 주고받는 기술, 데이터를 암호화하여 외부로부터의 도청, 해킹, 감시로부터 보호하고, 원격으로 사설 네트워크에 안전하게 접속할 수 있도록 한다.

동작 원리

암호화

사용자의 데이터를 암호화 하여 전송하므로, ISP나 외부에서 데이터를 읽을 수 없도록 한다.

터널링

VPN 터널이라는 보안 통로를 통해 전송됨, 데이터 패킷을 감싸 보호하는 역할을 한다

대표적인 VPN 프로토콜: OpenVPN, IPsec, WireGuard

IP 주소 변경

VPN 서버를 통해 인터넷에 접속하면 목적지 서버에는 사용자의 공인 IP 대신 VPN 서버의 IP가 보인다. 하지만 VPN 사업자는 사용자의 원래 IP와 트래픽 정보를 볼 수 있고, 쿠키나 계정 같은 다른 식별 수단도 남으므로 VPN이 익명성을 보장하는 것은 아니다.

SniffMEET. 닉네임 검증 개선 고민

Thu, 13 Feb 2025 00:00:00 +0000

작업 내역

닉네임 TextField의 검증 방식을 다시 정리했다. 현재는 UITextFieldDelegate로 길이 검증과 버튼 활성화를 처리하고 있었는데, 중복 체크까지 같은 흐름에 넣을 경우 네트워크 요청이 너무 자주 발생할 수 있어 보였다.

현재 구현

현재는 Delegate 기반으로 다음 두 가지를 처리하고 있었다.

extension ProfileCreateViewController: UITextFieldDelegate {
 func textFieldDidChangeSelection(_ textField: UITextField) {
 guard let textCount = textField.text?.count else { return }
 submitButton.isEnabled = (textCount > 1 && textCount < 9 )
 }
 func textField(
 _ textField: UITextField,
 shouldChangeCharactersIn range: NSRange,
 replacementString string: String
 ) -> Bool {
 guard let text = textField.text else { return false }
 let newLength = text.count + string.count - range.length
 let inputTextValid = newLength <= 15
 return inputTextValid
 }
}

길이 검증 자체는 단순했고, 현재 사용성도 나쁘지 않았다.

문제는 중복 체크처럼 네트워크 요청이 들어가는 검증까지 같은 방식으로 처리하기에는 부담이 커진다는 점이었다.

SniffMEET. AuthManager와 SessionManager의 책임 분리하기

Mon, 10 Feb 2025 00:00:00 +0000

작업 배경

AuthManager와 SessionManager는 서로 매우 밀접하게 연관된 작업을 한다. AuthManager는 사용자의 계정 인증을 담당하고 세션을 받아오며, SessionManager는 그 세션을 관리한다.

하지만 기존 코드에서는 세션 관리를 포함한 대부분의 작업을 AuthManager가 처리하고, SessionManager는 세션을 소유하는 역할만 하고 있었다.

역할 분리

기존에는 AuthManager에서 세션 갱신, 복원, 저장, 로드 작업을 처리하고 있었고, SessionManager는 세션의 만료 여부 확인과 세션 객체를 소유하는 역할만 맡고 있었다.

// AuthManager 인터페이스 프로토콜
protocol AuthManager {
 static var shared: AuthManager { get }
 var authStateSubject: PassthroughSubject<AuthState, Never> { get set }
 func signInAnonymously() async throws
 func restoreSession() async throws
 func refreshSession() async throws
 func loadTokens() throws
}

// SessionManager 클래스
final class SessionManager {
 static let shared = SessionManager()
 var session: SupabaseSession?
 var isExpired: Bool {
 guard let session else { return true }
 // 세션 만료를 파악할 때는 30초의 여유시간을 줍니다.
 return Date(timeIntervalSince1970: TimeInterval(session.expiresAt + 30)) < Date()
 }
 private init() {}
}

그래서 세션 관리는 SessionManager, 인증은 AuthManager가 맡도록 기능을 다시 정의했다.

SniffMEET. Interactor가 인프라를 직접 알아도 될까

Mon, 10 Feb 2025 00:00:00 +0000

Interactor에서 직접 매니저 호출하지 않기

매니저가 변하면 인터랙터를 직접 변경해야한다. 매니저와 인터랙터 간의 의존성을 줄이고, 인터랙터는 “비즈니스 로직”만, 그리고 비즈니스 로직의 구현체인 유즈케이스에서 네트워크 요청이나 데이터 관리와 같은 인프라 로직을 담당하는 것이 좋다고 생각한다.

또한 싱글톤 객체여도 현재 주입하는 방식으로 사용중인데, 인터랙터에서 사용하면 직접 매니저의 싱글톤 객체를 호출해서 사용해야 한다:

func sendWalkRequest(message: String, latitude: Double, longtitude: Double, location: String) {
 Task {
 do {
 let myInfo = try loadUserInfoUseCase.execute()
 let id = try SessionManager.shared.userID.get()
 ...
 try await requestWalkUseCase.execute(walkNoti: walkNoti)
 } catch {
 ...
 }
 }
 presenter?.didSendWalkRequest()
}

위 코드에서 id를 얻기 위해 SessionManager의 싱글톤 객체를 호출해야 한다. 싱글톤 객체 호출 자체는 크게 문제가 되지 않을 수 있지만, 다음과 같이 생각해볼 주제가 있다.

SniffMEET. 세션 갱신과 정보 접근을 SessionManager에 캡슐화하기

Mon, 10 Feb 2025 00:00:00 +0000

SessionManager 사용성 개선

세션을 갱신하는 방법

Supabase 서버와의 통신이 필요할 때, 우선 세션의 유효성을 검증해야 한다.

기존 방식에선 직접 AuthManager의 싱글톤 객체에서 세션을 갱신하는 작업을 했지만

AuthManager와 SessionManager의 역할 명확하게 분리
AuthManager의 싱글톤 해제

와 같은 변화점이 있었고, 기존 AuthManager가 담당하던 세션 갱신, 복원 작업이 SessionManager로 옮겨졌다. SessionManager의 싱글톤 객체에서 세션의 유효성을 체크하는 컴퓨티드 프로퍼티의 부울리언 값을 체크하여 세션을 갱신하는 메소드를 호출하는 방식을 사용했다:

if try SessionManager.shared.isExpired {
 try await SessionManager.shared.refreshSession()
}

이 방식은 SessionManager의 싱글톤 객체 호출이 두 번 일어나고, refreshSession이라는 메소드를 직접 노출해서, SessionManager가 세션을 갱신하는 방법을 직접 노출하는 문제가 있다.

SniffMEET. 세션 저장 메소드를 공개해도 괜찮을까?

Mon, 10 Feb 2025 00:00:00 +0000

세션 저장하기

AuthManager와 SessionManager의 역할을 분리하고 나니, 세션을 받아오는 쪽과 저장하는 쪽이 서로 달라지는 문제가 발생했다.

(AuthManager가 세션도 관리하던)기존 구조에서는 saveSession(for:)가 외부에 노출되어 있지 않았는데, 역할이 옮겨진 뒤에는 AuthManager에서 받아온 세션을 SessionManager로 전달해야 했다.

고민한 점

saveSession(for:)는 사실상 AuthManager가 세션을 받아온 상황에서만 필요한 메소드다.

그런데 이 메소드를 공개하면 캡슐화가 약해진다는 생각을 했고, 다시 AuthManager로 돌리면 SessionManager가 맡아야 할 책임을 되돌리는 것이 되었다.

따라서 몇 가지 방법을 떠올려 봤다.

(최종 선택) saveSession(for:)를 공개한다
saveSession(for:)를 AuthManager로 다시 옮긴다
같은 로직을 AuthManager와 SessionManager에 각각 작성한다
세션이 갱신됐다는 이벤트를 따로 전달할 수 있는 통신 레이어를 만든다

처음에 가장 괜찮아 보였던 건 세션 갱신 이벤트를 따로 전달하는 방식이었다.

Swift. 프로토콜 요구사항과 메소드 어트리뷰트

Mon, 10 Feb 2025 00:00:00 +0000

RemoteDBRequestBuildable 프로토콜을 추가한 뒤, 이전에는 나타나지 않던 unused-result 경고가 발생했다.

구체 타입에서는 사라졌던 경고

기존 구현의 request()에는 @discardableResult가 붙어 있었다. 반환값을 사용하지 않아도 경고가 발생하지 않았다.

final class SupabaseDBRequestBuilder {
 @discardableResult
 func request() async throws -> Data {
 Data()
 }
}

let concrete = SupabaseDBRequestBuilder()
try await concrete.request()

이후 Builder를 프로토콜로 추상화했지만 프로토콜 요구사항에는 해당 어트리뷰트를 붙이지 않았다.

protocol RemoteDBRequestBuildable {
 func request() async throws -> Data
}

extension SupabaseDBRequestBuilder: RemoteDBRequestBuildable {}

let abstract: any RemoteDBRequestBuildable = SupabaseDBRequestBuilder()
try await abstract.request()

구체 구현에는 여전히 @discardableResult가 있는데도, 프로토콜 타입으로 호출하면 경고가 다시 나타났다.

호출을 검사하는 선언과 실행할 구현

컴파일러는 호출 지점의 정적 타입을 기준으로 사용할 메서드 선언을 해석한다.

SniffMEET. ISP로 Supabase 요청 빌더 역할 나누기

Thu, 06 Feb 2025 00:00:00 +0000

들어가며

Supabase REST API를 직접 감싸서 사용하다 보니, 유즈케이스 레이어에서 eq., in., gte. 같은 쿼리 문자열을 직접 조립하는 코드가 늘어났다.

처음에는 단순했지만, 요청이 많아질수록 오타 가능성이 커지고 Supabase의 세부 문법이 상위 레이어로 새어 나오는 문제가 있었다. 이번 글은 이 쿼리 구성 책임을 Supabase DB Layer 안으로 옮기기 위해 요청 빌더와 쿼리 파라미터 래퍼를 도입한 과정을 정리한다.

기본 구조

SNMNetwork의 동작을 간단하게 설명하면, SNMRequestConvertible을 채택하는 객체의 정보로 네트워크 요청을 생성하고, 통신한 다음, 응답을 반환하는 방식으로 동작한다.

Network. NAT(Network Address Translation)

Wed, 05 Feb 2025 00:00:00 +0000

NAT

NAT: Network Address Translation

패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 주소 정보를 수정하여 IP 주소를 다른 주소로 매핑하는 방법, 공인 IP와 사설 IP로 나눠서 처리한다.

동작 원리

NAT는 라우터에서 동작하며, 내부 네트워크의 사설 IP 주소를 외부에서 사용할 수 있는 공인 IP 주소로 변환한다. 이를 통해 여러 장치가 하나의 공인 IP 주소를 공유하면서 인터넷에 접속할 수 있다.

동작 방식

출발지 주소 변환 (SNAT: Source NAT)

내부 네트워크의 컴퓨터가 외부에 패킷을 전송할 때 사설 IP주소를 공인 IP주소로 변환

목적지 주소 변환 (DNAT: Destination NAT)

외부에서 내부로 네트워크로 들어오는 패킷의 목적지 IP를 공인 IP에서 내부 네트워크의 사설 IP로 변환

포트 주소 변환 (PAT: Port Address Translation)

여러 내부 IP들이 하나의 공인 IP를 공유하기 때문에, 포트 번호로 이들을 구별한다.
하나의 공인 IP 주소를 여러 장치가 함께 사용할 수 있도록 포트 번호를 함께 변환하여 구분한다.

예를 들어 다음과 같이 서로 다른 내부 장치가 하나의 공인 IP를 사용할 수 있다.

Network. 쿠키, 세션

Sun, 02 Feb 2025 00:00:00 +0000

개요

웹 애플리케이션에서 사용자 정보를 저장하고 관리하는 방식, HTTP는 statelessness이기 때문에, 이전 요청에 대한 정보를 기억하지 않는다. 따라서 이 문제를 해결하기 위해 쿠키와 세션이 필요하다.

쿠키

클라이언트에 저장되는 작은 데이터 파일, 서버가 클라이언트에게 데이터를 저장하도록 지시하면, 해당 데이터를 전송하게 됨

용도

사용자 인증 정보 저장 (로그인 상태 유지)
웹사이트 설정 저장
사용자 행동 추적

특징

주기적 전송: 사용자가 특정 사이트에 다시 방문하면 브라우저가 자동으로 쿠키를 서버로 전송함
수명: 유효 기간을 설정할 수 있고, 만료되면 삭제됨, 유효기간이 없으면 브라우저 세션이 종료될 때 삭제
용량: 한 도메인당 쿠키는 4KB 정도로 제한

보안

사용자의 브라우저에 저장되기 때문에 클라이언트에서 조작할 수 있다. 따라서 민감한 데이터는 쿠키에 저장하면 안됨

OS. Stack, Heap 메모리 관리

Sun, 02 Feb 2025 00:00:00 +0000

Date: February 2, 2025 Multi-select: Memory

스택 메모리

LIFO 구조로, 함수 호출 시 생성되는 스택 프레임(로컬 변수, 파라미터, 반환 주소 등)을 저장한다. 함수가 호출 될 때 마다 새로운 스택 프레임이 쌓이고, 함수가 종료되면 스택 프레임 제거된다.

특징

빠른 메모리 할당/해제: 스택은 메모리가 자동으로 관리되어서 함수가 끝나면 알아서 메모리가 반환됨
고정 크기: 스택 메모리는 크기가 제한적이라서 너무 많은 데이터를 저장하면 스택 오버플로우 위험이 있음
호출 상태 저장: 함수의 매개변수와 지역 값 일부가 스택 프레임에 저장될 수 있음. 실제 저장 위치는 ABI와 컴파일러 최적화에 따라 레지스터나 다른 영역이 될 수도 있음
스레드별 스택: 각 스레드는 별도의 호출 스택을 가지지만, 이것만으로 함수나 데이터 전체가 thread-safe해지는 것은 아님. 스택에 있는 참조가 공유 객체를 가리킬 수도 있음

스택 오버플로우

프로그램이 스택 메모리를 초과할 때 발생하는 오류, 함수 호출 시마다 생성되는 스택 프레임이 쌓이면서 스택 공간을 사용하게 되고, 이 제한된 스택 공간을 초과해서 스택 프레임이 쌓일 경우 발생한다.

Network. ARP(Address Resolution Protocol)

Sat, 01 Feb 2025 00:00:00 +0000

ARP

ARP: Address Resolution Protocol

네트워크에서 IP 주소와 MAC 주소를 변환하는 프로토콜

동작 방식

데이터 전송 시, 송신자는 목적지의 MAC 주소를 알아야 한다.

송신 장치가 ARP Request를 브로드캐스트한다.
- 여기서 네트워크의 범위는 LAN, 즉 서브넷 내부
- 서브넷 마스크를 이용해서 공유기를 거쳐야 하는지 판단함.
- 이때 기본 게이트웨이는 이미 알고 있음
해당 IP 주소를 가진 장치가 ARP Reply를 유니캐스트로 응답한다.
이 정보를 ARP 캐시에 저장하여 다음 통신에서 요청하지 않는다

Note.

ARP 캐시: IP 주소와 MAC 주소의 대응 관계를 임시로 저장한 캐시 메모리

Network. DHCP(Dynamic Host Configuration Protocol)

Sat, 01 Feb 2025 00:00:00 +0000

개요

DHCP: Dynamic Host Configuration Protocol

디바이스가 네트워크에 접속하려면 고유한 IP주소가 필요하지만, 수동으로 설정하면 불편하고 충돌이 발생할 가능성이 있음, DHCP 서버는 자동으로 IP 주소와 서브넷 마스크, 게이트웨이와 같은 파라미터를 배정한다.

동작 방식

DORA

Discovery
- 클라이언트가 네트워크에 연결되면, IP 주소가 필요하다고 브로드 캐스트 요청을 보냄
Offer
- DHCP 서버가 사용 가능한 IP 주소를 찾아서 클라이언트에게 제안
Request
- 클라이언트가 서버에게 응답함
Acknowledge
- DHCP 서버가 설정을 최종적으로 승인

임대

DHCP는 IP 주소를 영구적으로 할당하지 않고 일정 시간 동안 임대(Lease)하는 방식으로 관리한다.

Network. DNS(Domain Name System)

Sat, 01 Feb 2025 00:00:00 +0000

DNS

DNS: Domain Name System

도메인 이름을 IP 주소로 변환하는 시스템, 웹 사이트 주소를 IP주소로 변환해주는 역할

동작 방식

DNS는 계층 구조를 가지며, 요청을 처리하는 과정에서 필요한 DNS 서버를 순차적으로 탐색한다. 한 번 조회한 결과는 캐시에 저장되어 이후에는 같은 과정을 반복하지 않을 수 있다.

사용자가 google.com을 입력했다고 하면, 맥이 자동으로 로컬 DNS 서버에 요청을 보냄 → 만약 로컬 DNS 서버가 정보를 가지고 있지 않다면, 상위 DNS 서버로 요청을 보냄

1. 맥 → 로컬 캐시 확인
2. 로컬 DNS 서버(ISP DNS 서버) → 로컬 캐시 확인
3. 로컬 DNS 서버 → 재귀 DNS 서버에 요청
4. 재귀 DNS 서버 → 루트 DNS 서버 → TLD DNS 서버 → 권한 있는 네임서버
5. 권한 있는 네임서버 → IP 주소 반환
6. 재귀 DNS 서버 → 로컬 DNS 서버 → IP 주소 전달
7. 로컬 DNS 서버 → 맥에 최종 IP 주소 전달
8. 맥 → 구글 접속

재귀 DNS 서버(Recursive DNS Server)는 클라이언트를 대신하여 필요한 DNS 서버를 차례대로 조회하고 최종 결과를 반환하는 역할을 한다.

Network. Load Balancing

Sat, 01 Feb 2025 00:00:00 +0000

로드 밸런싱

가용성, 성능, 확장성을 높이기 위해 여러 서버에 네트워크 트래픽을 분산하는 방법이다.

특징

서버와 클라이언트 간의 트래픽을 지시하고 제어하여 가용성, 확장성, 보안 및 성능이 향상됨

가용성

여러 서버에 트래픽을 분배하여 한 서버가 다운되었을 때, 사용 가능한 서버로 트래픽을 리다이렉션한다.
애플리케이션 가동 중지 없이 서버 유지 관리 및 업그레이드 가능

성능

여러 서버에 요청을 분배하여, 네트워크 지연 시간을 줄임
물리적으로 더 가까운 서버로 리다이렉션 하여 지연 시간 단축

보안

트래픽 모니터링
공격 트래픽을 여러 서버로 리다이렉션 하여 영향 최소화

확장성

서버 수를 동적으로 추가하거나 제거하여 트래픽 변화에 유연하게 대응 가능
수평 확장(서버 추가), 수직 확장(성능 향상) 둘 다 가능

동작 원리

L4 로드 밸런싱

전송 계층에서 수행하는 로드 밸런싱, 패킷 헤더에 포함된 정보를 기반으로 TCP나 UDP 패킷을 기준으로 트래픽을 분배한다.

Network. REST(Representational State Transfer)

Sat, 01 Feb 2025 00:00:00 +0000

REST

REST: Representational State Transfer
RESTful API: REST를 기반으로 한 API
REST 아키텍처 스타일의 설계 원칙을 준수하는 API

Note.

REST는 HTTP와 동일한 개념이 아니다. REST는 웹 API를 설계하기 위한 아키텍처 스타일이며, HTTP는 REST를 구현할 때 가장 많이 사용하는 프로토콜이다.

설계 원칙

Uniform interface

동일한 리소스에 대한 모든 API 요청은 동일하게 표시되어야 한다(리소스는 단일 URL을 통해 식별할 수 있도록 고유해야 한다). 서버는 표준 형식으로 정보를 전송하고, 형식이 지정된 리소스를 REST에서는 표현(Represent)라고 한다.

Network. 프록시

Sat, 01 Feb 2025 00:00:00 +0000

프록시

클라이언트와 서버 사이에 중간 역할을 하는 시스템, 클라이언트의 요청을 대신 처리하고 서버로부터 받은 응답을 클라이언트에 전달하는 방식으로 작동

프록시는 클라이언트와 서버 사이에서 요청과 응답을 대신 전달하는 중개 서버이다.

특징

익명성 제공

클라이언트의 실제 IP 주소를 숨기고, 프록시 서버의 IP 주소 사용

캐싱

자주 요청되는 데이터를 미리 저장해두고, 클라이언트의 요청이 있을 떄 빠르게 응답

보안

프록시 서버는 클라이언트와 서버 사이에 존재, 보안 및 필터링 기능 제공

트래픽 제어

리소스 보호를 위해 트래픽 필터링

종류

포워드 프록시

클라이언트가 외부 서버에 접근할 때 중개 역할을 하는 프록시

Network. TCP Flow & Congestion Control

Fri, 31 Jan 2025 00:00:00 +0000

개요

TCP는 신뢰성 있는 데이터 전송을 위해 흐름 제어(Flow Control) 와 혼잡 제어(Congestion Control) 기능을 제공함.

흐름 제어는 송신자와 수신자 사이의 데이터 전송량을 조절하고, 혼잡 제어는 네트워크 전체의 혼잡을 방지하기 위한 메커니즘이다.

흐름 제어 (Flow Control)

송신자와 수신자의 처리 속도 차이로 인해 데이터가 손실되지 않도록 전송량을 조절하는 기능이다.

정지-대기 (Stop-and-Wait)

수신 측의 ACK를 받은 후에 다음 패킷을 전송하는 방식, 한 번에 하나의 패킷만을 전송할 수 있음

슬라이딩 윈도우 (Sliding Window)

ACK를 이용해서 송신 데이터의 양을 조절하는 방식, ACK를 받지 않더라도 미리 정해진 패킷의 수 만큼 연속적으로 전송하는 방식

Network. TCP vs. UDP

Fri, 31 Jan 2025 00:00:00 +0000

TCP vs. UDP

TCP와 UDP는 모두 전송 계층에서 동작하는 프로토콜이지만, 연결 방식과 데이터 전송 방식이 다르다.

TCP는 신뢰성을 우선으로 하고, UDP는 속도와 실시간성을 우선으로 설계되었다.

비교

구분	TCP	UDP
연결 방식	연결 지향 (Connection-oriented)	비연결형 (Connectionless)
신뢰성	O	X
순서 보장	O	X
데이터 전송 방식	스트림(Stream)	데이터그램(Datagram)
흐름 제어	O	X
혼잡 제어	O	X
헤더 크기	20~60 Byte	8 Byte
속도	상대적으로 느림	상대적으로 빠름

언제 사용할까?

TCP

웹 서비스 (HTTP, HTTPS)
이메일 (SMTP)
파일 전송 (FTP)
데이터의 정확성이 중요한 서비스

UDP

DNS
DHCP
실시간 스트리밍
VoIP
온라인 게임
빠른 응답이 중요한 서비스

선택 기준

데이터의 정확성과 순서가 중요하다면 TCP를 사용한다.
일부 패킷 손실이 발생하더라도 실시간성이 더 중요하다면 UDP를 사용한다.

Network. TCP(Transmission Control Protocol)

Fri, 31 Jan 2025 00:00:00 +0000

소개

TCP(Transmission Control Protocol)는 전송 계층(L4)에서 동작하는 연결 지향(Connection-oriented) 프로토콜이다.

신뢰성 있는 데이터 전송을 위해 연결 설정, 순서 제어, 오류 제어, 흐름 제어, 혼잡 제어 등의 기능을 제공한다.

특징

신뢰성 있는 연결형 서비스 제공
포트 번호를 이용한 다중화, 순서 제어, 오류 제어, 흐름 제어, 혼잡 제어 기능 제공
애플리케이션에는 메시지 경계를 보존하지 않는 연속된 바이트 스트림을 제공

TCP 헤더

TCP 세그먼트 앞부분에 위치한 데이터 전송을 위한 제어 정보를 포함하는 구조, 20바이트로 구성되며 최대 60바이트로 확장 가능

Network. UDP(User Datagram Protocol)

Fri, 31 Jan 2025 00:00:00 +0000

소개

UDP(User Datagram Protocol)는 전송 계층(L4)에서 동작하는 비연결형(Connectionless) 프로토콜이다.

연결 설정 없이 데이터를 빠르게 전송하며, 신뢰성보다 실시간성이 중요한 환경에서 주로 사용된다.

UDP: User Datagram Protocol

OSI 7계층에서 전송 계층(L4)에 해당

특징

장점

데이터 전송 전에 연결을 설정하지 않는 비연결형 서비스
- 지연 시간이 낮음
단순한 프로토콜 구조
- 헤더 크기가 작고, 오버헤드가 적음
IP 계층의 유니캐스트, 브로드캐스트, 멀티캐스트 전송에 사용할 수 있음

단점

신뢰성 부족
- 패킷 손실, 순서 오류, 중복이 발생해도 복구할 수 없음
애플리케이션 수준의 보완 필요

데이터그램 패킷 통신

각 데이터그램은 다른 데이터그램과 독립적으로 전달된다. UDP 자체에는 순서 번호, 재전송, 중복 제거 기능이 없으므로 도착 순서나 전달 성공을 보장하지 않는다.

Algorithm. Counter Clock Wise

Thu, 30 Jan 2025 00:00:00 +0000

소개

2차원 평면 위에서 두 선분이 주어졌을 때 두 선분의 교차 여부를 판단하는 알고리즘

아이디어

2차원 평면 상에 3개의 점이 있을 때, 이들을 이루는 방향을 계산해서 두 선분의 교차 여부를 판단한다.

여기서 말하는 3개의 점은 기준이 되는 선분의 양 끝점($P_1$, $P_2$라 하면)과, 나머지 선분의 한 끝점($Q_1$ 또는 $Q_2$)을 말한다.

총 4개의 점인데 왜 3개의 점이냐고 하냐면, 기준이 되는 선분의 양 끝점과 나머지 선분의 한 끝점을 이용해 각각 CCW를 계산하기 때문이다.

Swift. Associated Type

Sun, 26 Jan 2025 00:00:00 +0000

소개

Swift의 프로토콜은 구현이 아니라 요구사항만 정의한다. 그런데 어떤 프로토콜은 사용할 타입을 미리 알 수 없는 경우가 있다.

예를 들어, 아래와 같은 Container 프로토콜을 만든다고 생각해 보자.

protocol Container {
 func append(_ item: ???)
}

append가 받을 타입은 무엇이어야 할까?

Int일 수도 있고, String일 수도 있으며, 사용자가 직접 만든 타입일 수도 있다. 하지만 프로토콜이 특정 타입에 종속되면 재사용성이 크게 떨어진다.

이럴 때 사용하는 것이 Associated Type이다. 처음에는 Generic으로도 해결할 수 있을 것 같다는 생각이 들었는데, 프로토콜은 Generic을 사용할 수 없다.

SniffMEET. Diffable Data Source에서 이미지가 갱신되지 않은 이유

Mon, 20 Jan 2025 00:00:00 +0000

들어가며

SniffMeet의 메이트 리스트 화면은 UITableViewDataSource를 직접 구현해서 셀을 구성하고 있었다. 이후 테이블 뷰와 컬렉션 뷰에서 Diffable DataSource를 사용해보기로 했고, 먼저 메이트 리스트 화면에 적용해보려고 했다.

처음에는 어렵지 않을 거라고 생각했다. 섹션과 아이템 타입을 만들고, snapshot을 적용하면 기존 reloadData()보다 깔끔하게 업데이트할 수 있을 것 같았다. 하지만 실제로는 이미지 갱신이 제대로 동작하지 않았다. 더 정확히는 프로필 이미지 데이터는 받아오는데, Diffable DataSource가 셀을 다시 구성할 때는 이미지가 계속 nil로 남아 있었다.

결국 이 작업은 성공적으로 마무리하지 못했다. 그래도 실패한 이유를 다시 정리해보니, 문제는 Diffable DataSource API 자체가 아니라 item의 identity와 표시 상태를 제대로 구분하지 못한 데 있었다.

OS. IPC(Inter-Process Communication)

Sun, 19 Jan 2025 00:00:00 +0000

Date: January 19, 2025 Multi-select: Process

IPC

여러 개의 독립적인 프로세스들이 서로 데이터를 주고받을 때 사용하는 메커니즘을 IPC(Inter Process Communication)라고 한다.

각각의 프로세스는 별개의 메모리 공간을 가지기 때문에, 서로 직접 메모리에 접근할 수 없기 때문에 IPC는 프로세스 간에 데이터를 교환하는 방법을 제공한다.

메세지 패싱

직접 메모리를 공유하지 않고 메세지를 통해 데이터를 주고받는 방식, 격리성을 보장할 수 있는 장점이 있지만 속도가 느리고 메모리 소비가 증가한다는 단점이 있음

주요방식

Simple

간단히 메세지를 보내고 받는 방식

SniffMEET. 프로필 이미지 다운샘플링과 썸네일 분리하기

Fri, 17 Jan 2025 00:00:00 +0000

개요

사용자가 고해상도 사진을 그대로 업로드하면, 앱에서는 훨씬 작은 크기로만 이미지를 표시하는데도 원본 이미지를 계속 전송하고 저장하게 된다.

SniffMeet에서도 프로필 이미지는 홈 화면의 프로필 카드나 메이트 리스트의 작은 썸네일로 표시되는 경우가 대부분이었다. 그런데 원본 이미지를 그대로 업로드하고, 목록에서도 같은 이미지를 다시 내려받고 있었다.

불필요한 네트워크 사용량과 메모리 사용을 줄이기 위해 두 가지를 적용했다.

업로드 전에 프로필 이미지를 앱에서 필요한 크기로 다운샘플링한다.
메이트 리스트에서는 원본 프로필 이미지가 아니라 별도의 썸네일 이미지를 내려받는다.

다운샘플링 기준 정하기

이미지를 어느 크기까지 줄일지 먼저 정해야 했다. 기준은 앱에서 프로필 이미지가 가장 크게 표시되는 홈 화면의 프로필 카드로 잡았다.

SniffMEET. NI·MPC 프로필 드랍 흐름 소유권 고민하기

Tue, 14 Jan 2025 00:00:00 +0000

들어가며

SniffMeet의 프로필 드랍 기능은 주변 사용자를 찾고, 기기 간 연결을 만들고, 거리와 방향 조건을 만족했을 때 프로필을 전달하는 흐름이다.

겉으로 보면 “주변 사람 찾기"와 “프로필 보내기"를 나누면 될 것 같았다. 하지만 실제 흐름을 펼쳐보니 MPC, NI, 유즈케이스, 인터랙터가 서로 맞물려 있었고, 단순히 기능 이름으로 유즈케이스를 나누기 어려웠다.

이 글은 프로필 드랍 흐름을 유즈케이스로 나누면서 고민했던 지점을 정리한 기록이다.

기존에 생각한 흐름

당시 프로필 드랍은 대략 다음 순서로 동작한다고 봤다.

SniffMEET. OSSignposter로 앱 내부 작업 구간 측정하기

Tue, 14 Jan 2025 00:00:00 +0000

들어가며

성능 개선을 하려면 먼저 어떤 작업이 얼마나 걸리는지 볼 수 있어야 한다. CPU 사용량만 보면 어느 시점에 부하가 생겼는지는 알 수 있지만, 앱 내부의 어떤 작업이 그 구간에 실행됐는지는 바로 드러나지 않는다.

그래서 Instruments에서 앱 내부 작업 구간을 이름으로 확인할 수 있도록 OSSignposter를 래핑해보기로 했다.

어디에 붙일까?

처음에는 측정용 타입을 따로 만들지, 기존 SNMLogger에 붙일지 고민했다.

private static let logger: Logger = Logger(
 subsystem: "SniffMeet",
 category: "SNMLogger"
)

별도의 SNMBenchMarker 같은 타입을 만들 수도 있었지만, 이미 프로젝트에 로그 시스템이 있었기 때문에 기존 SNMLogger에 통합하는 쪽을 선택했다.

Network. URI(Uniform Resource Identifier)

Sun, 12 Jan 2025 00:00:00 +0000

URI (Uniform Resource Identifier)

자원(파일, 웹 페이지, 이메일 주소)등을 식별하는 문자열

URI는 URL과 URN을 포함하는 상위 개념이다.

URL (Uniform Resource Locator)

자원의 위치(Location)와 접근 방법을 나타내는 URI

HTTP, HTTPS, FTP 등의 프로토콜을 포함할 수 있다.
프로토콜, 호스트, 경로, 쿼리 등을 통해 자원에 접근하는 방법을 나타낸다.

URN (Uniform Resource Name)

자원의 이름(Name)으로 식별하는 URI

자원의 위치와 관계없이 고유한 이름으로 식별한다.
대표적으로 ISBN, ISSN 등이 사용된다.

관계

URI
├── URL
└── URN

OS. Context Switching

Sun, 12 Jan 2025 00:00:00 +0000

컨텍스트 스위칭

CPU가 현재 실행 중인 프로세스나 스레드를 중단하고, 다른 프로세스나 스레드를 실행하는 과정. 멀티 태스킹 환경에서 하나의 CPU가 여러 작업을 번갈아 가며 처리할 수 있게 만들어 준다.

언제 발생하나?

CPU 스케줄러가 다른 작업을 선택했을 때(그러면 다른 프로세스를 써야하니까)
실행 중인 작업이 블로킹 되었을때 (I/ O같은게 들어왔다거나 할 때)

과정

현재 작업(프로세스, 스레드)의 컨텍스트를 저장한다.
다음에 실행할 작업의 컨텍스트를 복원한다.
CPU가 새로운 작업을 실행한다.

코스트

컨텍스트 스위칭을 할 때, 상태를 저장하고 로드하는 과정에서 메모리 접근, 레지스터 저장, 복원과 같은 작업 때문에 시간과 자원을 사용하게 된다.

OS. Deadlock

Sun, 12 Jan 2025 00:00:00 +0000

데드락

두 개 이상의 프로세스나 스레드가 서로 상대방이 점유하고 있는 자원을 기다리며, 서로 무한히 기다리는 상태에 빠지는 현상

데드락의 발생 조건

다음 네 가지 Coffman 조건이 동시에 성립할 때 데드락이 발생할 수 있다. 각 조건은 데드락의 필요 조건이지만, 네 조건이 성립한다고 해서 모든 실행에서 반드시 데드락이 발생하는 것은 아니다.

상호 배제(Mutual Exclusion)

한 번에 하나의 작업만 사용할 수 있는 자원이 존재하는 상태다.

점유 대기(Hold and Wait)

작업이 하나 이상의 자원을 이미 보유한 상태에서 다른 작업이 가진 추가 자원을 기다리는 상태다.

프로세스와 스레드

Sun, 12 Jan 2025 00:00:00 +0000

프로세스

컴퓨터에서 실행 중인 프로그램의 인스턴스, 프로그램이 메모리에 올라가면 프로세스가 된다.

프로세스의 상태

운영체제마다 세부 상태는 다르지만, 기본적인 5상태 모델은 다음과 같다.

생성(New): 프로세스가 만들어지는 중인 상태
준비(Ready): 실행에 필요한 자원을 갖추고 CPU 할당을 기다리는 상태
실행(Running): CPU에서 명령을 실행하고 있는 상태
대기(Waiting, Blocked): I/O 완료나 이벤트 발생을 기다리는 상태
종료(Terminated): 실행이 끝난 상태

CPU 스케줄러가 준비 상태의 프로세스를 선택하면 실행 상태로 이동한다. 할당 시간이 끝나거나 선점되면 다시 준비 상태가 되고, I/O를 요청하면 대기 상태로 이동한다. 기다리던 작업이 완료되면 다시 준비 상태로 돌아간다.

Data Structure. Hash Table

Sat, 11 Jan 2025 00:00:00 +0000

소개

키, 값 쌍으로 데이터를 저장하는 자료구조. 데이터 삽입, 검색, 삭제가 빠르다. (스위프트에서 사용하는 딕셔너리도 해시 테이블이다.)

해시 테이블은 키를 배열의 인덱스로 직접 사용하는 대신, 해시 함수를 통해 키를 일정한 범위의 해시 값으로 변환한다. 이 덕분에 배열 전체를 순회하지 않고도 데이터가 저장된 위치에 빠르게 접근할 수 있다.

구조

해시 테이블은 배열과 해시 함수로 구성된다.

배열: 데이터를 저장할 배열, 배열의 인덱스는 해시 값을 뜻함
해시 함수: 키를 해시 값으로 변환하는 함수

키를 해시 함수에 넣어서 계산된 해시 값을 기반으로, 배열의 인덱스에 값을 저장한다.

SniffMEET. DTO와 Entity의 경계 점검하기

Sat, 11 Jan 2025 00:00:00 +0000

들어가며

SniffMeet에 기능이 붙으면서 DTO와 Entity가 빠르게 늘어났다. 처음에는 필요한 타입을 그때그때 만들면 됐지만, 어느 순간부터 어떤 타입이 어느 레이어에서 쓰이는지 헷갈리기 시작했다.

특히 UserInfoDTO, UserInfo, DogInfo, Mate처럼 비슷한 정보를 담는 타입들이 여러 곳에서 서로 다른 이름으로 사용되고 있었다. 그래서 바로 코드를 고치기보다, 먼저 현재 타입들이 어디에서 쓰이고 있는지 정리해보기로 했다.

먼저 한 일: 사용처 조사

가장 먼저 DTO, Entity, Supabase 관련 Request/Response 타입을 나눠서 사용처를 훑어봤다.

전체 목록을 보면 타입 수가 많은 것도 문제였지만, 더 큰 문제는 몇몇 타입의 사용처가 너무 넓다는 점이었다.

SniffMEET. 비동기 태스크와 액터 점검하기 (1)

Wed, 08 Jan 2025 00:00:00 +0000

작업 내역

이번 작업에서는 Task, async/await, @MainActor가 섞여 있던 부분을 화면별로 점검했다.

앱 시작 흐름부터 프로필 등록, 메이트 목록, 산책 응답까지 비동기 경계를 다시 살펴보고, 각 화면에서 책임이 어디에 있어야 하는지 정리했다.

앱 시작 플로우

UIWindow의 루트 뷰 컨트롤러를 결정하는 흐름은 @MainActor로 두고, 그 안에서 세션 복원이 끝나기를 기다렸다. await로 대기하는 동안에는 메인 액터를 점유하지 않는다.

displayInitialScreen이 MainActor 안에서 실행되는지 breakpoint로 확인했고, displayOnBoardingView는 그대로 MainActor에 남겨 두었다.

// AppRouter.swift

func displayInitialScreen() {
 Task { @MainActor in
 do {
 try await SupabaseAuthManager.shared.restoreSession()
 displayTabBar()
 } catch {
 displayOnBoardingView()
 }
 }
}

프로필 입력 및 등록

프로필 입력 부분은 전달만 하는 역할이라 비동기 처리가 필요하지 않았다.

SniffMEET. 비동기 태스크와 액터 점검하기 (2)

Wed, 08 Jan 2025 00:00:00 +0000

메이트 요청

didTabAcceptButton과 saveMateInfo를 따라가 보니 유스케이스 실행을 위해 Task가 존재했고, Combine의 sink 클로저 안에서도 Task를 생성하고 있었다. Interactor에서 태스크를 묶으면 저장 완료를 알리는 메서드가 따로 필요해 보였다.

Presenter 메서드는 async로 바꾸고, View의 sink에서는 Task를 통해 호출하도록 두었다.

acceptButton.publisher(event: .touchUpInside)
 .sink { [weak self] in
 Task {
 await self?.presenter?.didTapAcceptButton(id: self?.profile.id ?? DogProfileDTO.example.id)
 self?.presenter?.closeTheView()
 }
 }
 .store(in: &cancellables)

// RequestMatePresenter
func closeTheView() {
 if let view {
 router?.dismissView(view: view)
 }
}
func didTapAcceptButton(id: UUID) async {
 SNMLogger.info("id: \(id)")
 await interactor?.saveMateInfo(id: id)
}

산책 요청 및 응답

`RespondWalkPresenter`

산책 요청은 Task로 Interactor에 존재했고, 위치 변환은 Presenter에서 await로 처리했다.

Programmers. 순위 검색

Tue, 07 Jan 2025 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/72412

풀이

많이 해맨 문제다. 처음에는 다음과 같이 알고리즘을 생각했다.

일단 쿼리의 개수와 info 배열의 크기를 생각해보면 filter를 사용하는 문제는 아님
바이너리 서치, Upper bound와 Lower bound의 차이가 해당하는 원소의 개수가 같음
info 배열을 잘 정렬해서 바이너리 서치만 하면 쉽게 해결될 문제

하지만 조금만 생각해보면 이러한 방식의 알고리즘은 문제를 절대로 해결할 수 없다.

우선 쿼리의 조건들이 독립적이다. 정렬 기준에 따라서 포함되어야 할 값이 포함되지 않게 된다.
그렇다고 바이너리 서치 -> 다시 정렬을 반복하기엔 차라리 filter를 쓰는게 더 시간 복잡도가 더 좋다.

다음에 생각한 방식은 트리를 이용하는 방식이었다.

SniffMEET. Instruments로 성능 개선 후보 찾기

Tue, 07 Jan 2025 00:00:00 +0000

들어가며

성능 개선이 필요해 보이는 지점을 감으로 고르지 않기 위해, 먼저 SniffMeet의 주요 흐름에서 CPU와 네트워크 사용량을 훑어봤다.

이 측정만으로 병목 원인을 확정할 수는 없다. 다만 어떤 화면과 기능을 먼저 의심해야 하는지, 이후 리팩토링 후보를 정하는 기준으로는 충분했다.

CPU 사용량 측정

Instruments의 Time Profiler로 주요 사용자 흐름을 따라가며 CPU 사용량이 튀는 구간을 확인했다.

측정 중 비교적 사용량이 높았던 지점은 다음과 같았다.

시점	동작	관찰
0:26	프로필 입력 뷰 로드	CPU 70%
0:53	텍스트 필드 입력	CPU 70%
1:44	사진, 닉네임 입력 뷰 로드	CPU 70%
2:08	포토피커	CPU 90%
3:00	등록 완료 버튼 터치	CPU 100%, 약 0.7초 유지
3:28	메이트 리스트 뷰 로드	CPU 50%
3:41	산책 요청 보내기 터치	CPU 80%
4:10	지도 로드	CPU 95%
5:05	요청 보내기	CPU 100%, 약 0.2초
6:36	MPC 연결	CPU 100%, 약 1.2초

특히 회원가입 완료 버튼을 눌렀을 때와 MPC 연결 시점이 눈에 띄었다. 회원가입 완료 시점에는 메인 스레드에서만 작업이 몰리는 것처럼 보였고, MPC 연결 시점에는 MultipeerConnectivity 관련 스레드가 지속적으로 동작했다.

Algorithm. LCS(Subsequence)

Thu, 02 Jan 2025 00:00:00 +0000

소개

두 문자열이 있을 때, 가장 긴 공통 부분 문자열을 찾아내는 알고리즘, 부분 문자열이란 원소들이 원래 순서를 유지하면서 일부 원소를 생략할 수 있는 형태를 말함

예시:

문자열 A: A**B**CB**DAB**
문자열 B: **BD**C**AB**B

A와 B의 LCS는 BDAB라고 할 수 있다.

아이디어

2차원 배열을 통해 중간 결과를 메모이제이션 한다. 이 배열은 두 문자열의 길이에 따라 결정된다.

알고리즘

편의상 첫 번째 열과 행은 0으로 초기화 한다. 빈 문자열과 비교했을 때의 경우를 처리할 수 있다.

	-	A	B	C	B	D	A	B
-	0	0	0	0	0	0	0	0

두 번째 문자열의 문자를 차례대로 가져와 비교한다.

	-	A	B	C	B	D	A	B
-	0	0	0	0	0	0	0	0
B	0	0	1

테이블의 각 원소는 그 시점의 substring간의 LCS를 의미한다. 즉 위 표에서 1인 원소는 substring “AB”와 “B”의 LCS의 길이가 1임을 의미한다.

앞선 결과를 기반으로 LCS의 크기를 계산한다.

	-	A	B	C	B	D	A	B
-	0	0	0	0	0	0	0	0
B	0	0	1	1

B와 C는 같지 않더라도, “ABC”와 “B”를 비교하는 것과 같으므로, 이전에 “AB”와 “B”를 비교한 값인 1이 유지된다.

만약 두 문자가 다른 경우

	B	C	B	D	A	B
-	0	0	0	0	0	0
B	1	1	1	1	1	1
D	1

B와 D는 다르지만, “AB”와 “BD”의 LCS의 길이는 1이다. 3번의 경우와 합쳐서 두 원소가 다르지 않을 때, DP 테이블을 채우는 점화식을 세울 수 있다.
dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])

두 문자가 같은 경우

	B	C	B	D	A	B
-	0	0	0	0	0	0
B	1	1	1	1	1	1
D	1	1	1	2

두 문자가 같은 경우, 즉 위 표의 상황에서는 “ABCBD”와 “BD”의 LCS의 크기를 구하는 경우가 된다. 이 경우는 “ABCB”와 “B”의 LCS의 크기에서 원소 “D”가 더해진 것과 같으므로, 대각선 위에 있는 값에서 1을 더한 값이 된다.
dp[i][j] = dp[i - 1][j - 1] + 1

동작 원리

DP 테이블을 채우면서 두 문자가 다른 경우
- 이전에 계산한 결과를 그대로 유지한다.
두 문자가 같은 경우
- 그 문자가 없는 경우의 LCS의 크기에서 1을 더한다.
점화식

if (A[i - 1] == B[j - 1]) {
 dp[i][j] = dp[i - 1][j - 1] + 1
} else {
 dp[i][j] = (dp[i - 1][j] > dp[i][j - 1]) ? dp[i - 1][j] : dp[i][j - 1];
}

기타

길이와 실제 문자열

DP 테이블의 마지막 값인 dp[m][n]은 LCS의 길이만 나타낸다.

Algorithm. Binary Search off-by-one 에러 없이 구현하기

Tue, 31 Dec 2024 00:00:00 +0000

off by one error

바이너리 서치를 할 때, 경계나 중간 값을 처리하면서 인덱스가 하나 어긋나는 에러

주요 원인은 바이너리 서치에 대한 이해 부족
인덱스 레인지, high / low 갱신 방식, 중간값 계산 방식, 값 리턴 방식을 다양하게 생각해야 함

Binary Search 테크닉

else보다는 else if를 사용하여 조건을 명확하게 표현하기
오버플로우 방지를 위해서는 mid를 계산할 때, (low + high) / 2보다 low + (high - low) / 2를 사용하기

바이너리 서치는 단순히 정렬된 배열에서 값을 찾는 알고리즘이 아니다. 바이너리 서치를 이용하여, 정확한 값을 찾는 경우보다 조건을 만족하는 첫 번째 또는 마지막 위치를 찾는 경우가 더 많다.

SniffMEET. anon-key와 익명 사용자의 접근 권한 구분

Thu, 28 Nov 2024 00:00:00 +0000

anon-role과 anon-user의 접근 권한 차이

Public Scheme에 있는 테이블을 anon-key로는 접근할 수 있었지만, anon-user의 JWT 토큰으로는 접근하지 못하는 문제가 있었다.
처음에는 둘이 비슷한 범주라고 생각했지만, 실제로는 권한 체계와 접근 방식이 달라서 같은 문제로 볼 수 없었다.

문제를 확인하기 전 생각한 내용

anon-key, anon-role, anon-user의 차이부터 다시 정리했다.
anon-key를 이용한 접근은 anon-role로 보고, anon-user는 이메일 주소나 전화번호를 등록하지 않은 유저를 의미한다. 이 경우 role 자체는 authenticated-role이었다.

익명 유저가 접근했을 때 200 OK가 뜨지만 실제 값을 가져오지 못하는 경우도 있었다.
그래서 접근 자체는 허용되지만 RLS에서 막히고 있다고 추정할 수 있었다.

SniffMEET. Storage 버킷과 접근 제어

Sun, 24 Nov 2024 00:00:00 +0000

SniffMEET의 프로필 이미지는 사용자 정보와 성격이 다르다. 사용자 이름이나 소개처럼 구조화된 데이터는 Database에 저장하고, 이미지 파일은 Storage에 저장하는 편이 적합하다.

Storage의 Postgres 테이블에는 파일 자체가 아니라 버킷과 객체의 메타데이터가 기록된다.

버킷과 객체 경로

버킷은 파일을 묶는 최상위 컨테이너다. 사용자마다 버킷을 만드는 것보다 용도별 버킷을 만들고 객체 경로로 사용자를 구분하는 편이 관리하기 쉽다.

profile-images/
├── {user-id}/profile.jpg
└── {user-id}/thumbnail.jpg

이 구조에서는 profile-images 버킷이 공통된 공개 범위와 파일 제한을 담당하고, 사용자 ID가 포함된 경로를 RLS 정책에서 검사할 수 있다.

SniffMEET. Supabase 세션 갱신 요청이 실패한 이유

Thu, 21 Nov 2024 00:00:00 +0000

문제

Supabase 세션 갱신 요청이 제대로 동작하지 않았다. 세션 로직이나 네트워크 레이어 문제처럼 보였지만, 실제 원인은 요청 형식이었다. 당시 메모는 이랬다.

수정

"grant_type": "refreshToken"

grant_type 값을 Swift식 camelCase로 보내고 있었다. Supabase가 기대하는 값은 refresh_token이었다.

"grant_type": "refresh_token"

body도 마찬가지였다. Supabase가 기대하는 key는 refreshToken이 아니라 refresh_token이었다. refresh 요청에서는 기존 access token의 Authorization 헤더도 제거했다. (토큰을 갱신받기 위한 요청인데, 만료된 토큰을 보내는거니까 아무 의미 없다!)

body: Data("{ \"refresh_token\": \"\(refreshToken)\" }".utf8)
header["Authorization"] = nil

refresh 요청은 기존 access token으로 리소스에 접근하는 요청이 아니라, refresh token으로 새 세션을 발급받는 요청이기 때문이다.

SniffMEET. JWT와 Supabase RLS 정책에 연결하기

Wed, 20 Nov 2024 00:00:00 +0000

Supabase Auth로 로그인하면 클라이언트는 Access Token으로 JWT를 받는다. Supabase는 요청에 포함된 JWT를 검증하고, 그 안의 사용자 정보와 역할을 RLS 정책에 전달한다.

JWT의 클레임

JWT는 헤더, 페이로드, 서명으로 구성된다. 각 부분은 Base64URL로 인코딩되지만 암호화되지는 않으므로 페이로드에 비밀 정보를 넣으면 안 된다. 서명은 헤더와 페이로드가 변조되지 않았는지 검증하는 데 사용한다.

Supabase의 JWT에는 다음과 같은 클레임이 포함된다.

sub: 사용자의 고유 ID
role: RLS를 적용할 PostgreSQL 역할
iat: 토큰이 발급된 시각
exp: 토큰이 만료되는 시각

Supabase에서 JWT 사용하기

RLS는 PostgreSQL이 행 단위로 접근을 제한하는 기능이다. Supabase에서는 auth.uid()로 현재 JWT의 sub 값을 가져와 행의 사용자 ID와 비교할 수 있다.

SniffMEET. RLS와 테이블 권한

Wed, 20 Nov 2024 00:00:00 +0000

문제

Supabase에서 anon key로 Public 테이블에 접근하면 데이터가 보이는데, 익명 로그인 후 받은 JWT access token으로 접근하면 200 OK만 오고 데이터가 비어 있었다.

처음에는 authenticated role이 anon role보다 상위 권한이라고 생각해서 더 헷갈렸다. 하지만 Supabase에서는 role의 상하관계보다 RLS 정책을 어떻게 작성했는지가 더 중요했다.

확인

JWT가 만료된 경우에는 401 Unauthorized가 발생했다. 반면 RLS 조건에 맞지 않는 경우에는 요청 자체는 성공해서 200 OK가 오지만, row가 필터링되어 데이터가 내려오지 않았다.

authenticated 유저가 읽을 수 있도록 다음 policy를 추가하자 데이터를 읽을 수 있었다.

Swift. Xcode 디버깅과 LLDB 기본 명령어

Wed, 20 Nov 2024 00:00:00 +0000

LLDB가 뭔가요

LLVM + Debugger

LLVM 위에서 동작하는 디버거

LLVM(Low Level Virtual Machine)

프로그래밍 언어를 CPU 아키텍처가 이해할 수 있도록 컴파일 하는 과정을 생각해보면 (프로그래밍 언어의 종류 * CPU 아키텍처의 종류) 만큼의 경우의 수가 생긴다.

LLVM은 LLVM-IR이라는 중간 언어를 만들어서 프로그래밍 언어를 LLVM-IR로 변역하고 이 LLVM-IR을 CPU 아키텍처에 맞는 기계어로 번역하게 해주는 역할을 함 어려운건 여기까지!

XCode Debugging

BreakPoint

브레이크 포인트가 걸린 라인 직전 까지 실행 됨
활성화/비활성화 할 수 있음
다양한 옵션 지정 가능 (이름, LLDB 커맨드, 로그 작성 등등)…

Debugging Bar

Disable/enable breakpoints: 브레이크 포인트들을 활성화/비활성화
Pause/continue execution: 다음 브레이크 포인트가 나올 때 까지 진행
Step over: 다음 라인으로 넘어가기
Step into: 현재 브레이크 포인트가 걸려있는 메소드로 들어가기
Step out: 현재 메소드에서 벗어나기

LLDB 직접 사용해보기

Print: `p`

현재 메모리 상태에 있는 것을 출력한다.

SniffMEET. 익명 로그인 세션의 생성·복원·갱신 흐름

Thu, 14 Nov 2024 00:00:00 +0000

익명 로그인 생성, 복원, 갱신 로직 구현

JWT, Refresh Token, 세션의 개념이 아직 명확하게 정리되지 않은 상태에서 익명 계정을 먼저 만들게 됐다. 개념이 명확하지 않아서, 세션 관리에 꽤 애를 먹었는데, 앱 재실행 이후에도 익명 계정을 어떻게 이어서 사용할지부터 정리할 필요가 있었다.

생성, 복원, 갱신 로직은 서로 밀접하게 연결되어 있어서, 처음 앱을 실행했을 때와 다시 실행했을 때의 흐름을 먼저 구분해야 했다.

실제 문제 해결 과정

먼저 시점별로 세션 상태를 표로 정리했다.

SniffMEET. 여러 VIPER 구현에서 Router 구조 비교하기

Tue, 12 Nov 2024 00:00:00 +0000

VIPER에서 Router가 화면 전환을 담당한다는 원칙은 분명하다. 하지만 현재 화면을 어떻게 참조하는지, 다음 모듈은 누가 만드는지, AppRouter가 반드시 필요한지는 구현마다 달랐다.

SniffMEET의 화면 구조를 정하기 전에 여러 VIPER 프로젝트를 비교하며 Router의 책임 범위를 확인했다.

무엇을 확인했나

분석 기준은 다음 세 가지였다.

Router가 현재 ViewController를 어떻게 참조하는가
화면 전환 시 다음 VIPER 모듈을 누가 조립하는가
여러 모듈에 걸친 전환을 AppRouter가 담당하는가

구현 비교

구현	모듈 조립	화면 전환	AppRouter
iOS-Viper-Architecture	WireFrame의 정적 메서드	출발 View를 인자로 전달	없음
ios-architecture	정적 팩토리 메서드	전환 사례가 적음	없음
Viperit	프레임워크가 모듈을 관리	모듈이 직접 자신을 표시	`AppModules`로 모듈 관리
iOS-Architecture-Sample	모듈별 생성	앱 단위 Router가 화면 계층 관리	싱글톤 AppRouter

구현은 달랐지만 공통점도 있었다. View나 Presenter가 직접 다음 화면을 생성하지 않았고, 화면 조립과 전환을 UI 바깥의 객체로 분리하고 있었다.

SniffMEET. UITabBarController VIPER 컨테이너로 다루기

Mon, 11 Nov 2024 00:00:00 +0000

VIPER 모듈을 사용하더라도, 직접 탭 바를 구현하지 않는 이상 UITabBarController는 사용해야 한다. 일반적인 VIPER 화면처럼 View, Presenter, Interactor, Router를 모두 갖춘 독립 모듈로 보기엔 애매한 것 같다.

특히 Interactor는 여기서 아무 의미가 없어보이고, Router는 UITabBarController에 내장되어 있으니까…

모듈 빌더

router, interactor를 생성하고 이를 가지고 있는 presenter를 생성해서 뷰에 집어넣는 방식

HomeModuleBuilder는 Home 화면에 필요한 VIPER 구성 요소를 한 곳에서 조립한다. ViewController를 만들고, Router와 Interactor를 생성한 뒤 Presenter에 주입한다. 마지막으로 NavigationFactory를 통해 화면을 UINavigationController로 감싸서 반환한다.

Software Engineering. VIPER 아키텍처

Mon, 11 Nov 2024 00:00:00 +0000

VIPER란

VIPER는 화면을 View, Interactor, Presenter, Entity, Router로 나누는 아키텍처 패턴이다. 각 객체의 역할과 의존 방향을 제한해 UI, 비즈니스 로직, 화면 전환을 분리한다.

구성 요소

View

화면을 그리고 사용자 입력을 Presenter에 전달한다. Presenter가 전달한 값을 UI에 반영하며, 비즈니스 로직은 직접 처리하지 않는다.

protocol ExampleViewProtocol: AnyObject {
 func displayMessage(_ message: String)
 func displayError(_ message: String)
}

final class ExampleViewController: UIViewController {
 var presenter: (any ExamplePresenterProtocol)?

 override func viewDidLoad() {
 super.viewDidLoad()
 presenter?.viewDidLoad()
 }
 @IBAction private func buttonTapped(_ sender: UIButton) {
 presenter?.handleButtonTapped()
 }
}

extension ExampleViewController: ExampleViewProtocol {
 func displayMessage(_ message: String) {
 label.text = message
 }
 func displayError(_ message: String) {
 errorLabel.text = message
 }
}

Presenter

View의 입력을 해석해 Interactor나 Router에 작업을 요청한다. Interactor가 반환한 Entity는 화면에 표시할 값으로 가공해 View에 전달한다.

DevOps. GitHub Actions 워크플로우

Tue, 05 Nov 2024 00:00:00 +0000

들어가며

GitHub Actions는 저장소에서 발생한 이벤트를 기준으로 빌드, 테스트, 배포 같은 작업을 자동화한다. 자동화 과정은 .github/workflows 디렉토리의 YAML 파일로 정의한다.

처음 workflow를 작성할 때는 name, on, jobs, steps가 각각 무엇을 나타내는지부터 이해할 필요가 있다.

전체 구조

GitHub Actions의 실행 흐름은 다음과 같다.

Event -> Workflow -> Job -> Runner -> Step

이 흐름을 YAML로 표현하면 다음과 같다.

name: Build and Test
run-name: Build triggered by @${{ github.actor }}

on:
 push:
 branches:
 - main
 pull_request:
 branches:
 - main
 workflow_dispatch:

jobs:
 build:
 runs-on: macos-latest
 steps:
 - uses: actions/checkout@v4
 - name: Build
 run: echo "Build"

 test:
 needs: build
 runs-on: macos-latest
 steps:
 - uses: actions/checkout@v4
 - name: Test
 run: echo "Test"

`name`과 `run-name`

name은 workflow 자체의 이름이다. GitHub 저장소의 Actions 탭에서 workflow를 구분할 때 사용한다.

UIKit. TableViewCell 스와이프 동작 넣기

Fri, 20 Sep 2024 00:00:00 +0000

기본 메소드들

// 오른쪽에서 왼쪽으로 스와이프
tableView(_:trailingSwipeActionsConfigurationForRowAt:)

// 왼쪽에서 오른쪽으로 스와이프
tableView(_:leadingSwipeActionsConfigurationForRowAt:)

구현 순서

1. `UIContextualAction`을 사용해서 액션 구현

let deleteAction = UIContextualAction(style: .destructive, title: "삭제") { (action, view, completionHandler) in
 // 삭제 로직
 completionHandler(true)
}

2. `UISwipeActionsConfiguration`에 액션 등록

// 액션 여러개 등록 가능
let configuration = UISwipeActionsConfiguration(actions: [deleteAction])

3. 전체 코드

func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
 let deleteAction = UIContextualAction(style: .destructive, title: "삭제") { (action, view, completionHandler) in
 // 삭제 로직
 completionHandler(true)
 }

 let configuration = UISwipeActionsConfiguration(actions: [deleteAction])
 configuration.performsFirstActionWithFullSwipe = false

 return configuration
}

기타

색깔, 이미지 지정 가능

deleteAction.backgroundColor = .systemRed
deleteAction.image = UIImage(systemName: "trash")

performsFirstActionWithFullSwipe

true: 스와이프 하면 첫 번째 액션이 즉시 실행
false: 스와이프 된 상태에서 나타는 버튼을 눌러서 액션 실행

실제 적용 코드 (이슈 트래킹 앱)

func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
 let deleteAction = makeDeleteAction()
 let closeAction = makeCloseAction()

 let configuration = UISwipeActionsConfiguration(actions: [deleteAction, closeAction])
 configuration.performsFirstActionWithFullSwipe = false

 return configuration
}

private func makeDeleteAction() -> UIContextualAction {
 let deleteAction = UIContextualAction(style: .destructive, title: nil) { (action, view, completionHandler) in
 // TODO: 얼럿 띄우고 삭제 로직
 completionHandler(true)
 }
 deleteAction.image = UIImage(systemName: "trash")
 return deleteAction
}

private func makeCloseAction() -> UIContextualAction {
 let closeAction = UIContextualAction(style: .normal, title: nil) { (action, view, completionHandler) in
 // TODO: 이슈 닫기 로직
 completionHandler(true)
 }
 closeAction.image = UIImage(systemName: "archivebox.fill")
 closeAction.backgroundColor = .systemIndigo
 return closeAction
}

UIKit. UIView와 CALayer

Tue, 17 Sep 2024 00:00:00 +0000

UIView는 화면의 직사각형 영역을 나타내고, 그 안에 콘텐츠를 관리하는 객체이다. 대부분의 UI 요소가 UIView를 상속받으며, 화면에 콘텐츠를 보여주고 터치나 제스처를 감지하는 역할을 한다.

UIView로 콘텐츠 표시하기

UIView는 UIKit에서 제공하는 메소드나 Core Graphics를 이용해 직사각형 영역에 콘텐츠를 그릴 수 있다. 배경색만 있는 간단한 UIView를 만들어보자.

var magentaRectView: UIView = {
 let magentaRectView = UIView()
 magentaRectView.backgroundColor = .magenta
 return magentaRectView
}()

오토레이아웃 제약은 임의로 정했다.

UIView는 내부에 다른 UIView를 포함할 수 있다. 상위 뷰에 포함된 뷰를 서브 뷰라고 한다. UIViewController의 view 프로퍼티도 UIView 인스턴스이기 때문에, 위 마젠타 사각형도 UIView 내부의 UIView이다. 좀 더 직관적으로 확인하려면, 마젠타 사각형 안에 검은색 사각형을 추가해보자.

UIKit. TableViewCell에 UITextView 넣고 동적으로 높이 변경하기

Sun, 15 Sep 2024 00:00:00 +0000

UITableViewCell 안에 UITextView를 넣고, 입력되는 텍스트 길이에 따라 셀의 높이가 자동으로 늘어나도록 처리했다.

처음에는 그냥 UITextView를 셀에 넣으면 알아서 늘어날 줄 알았는데, UITextView 자체의 스크롤과 UITableView의 셀 높이 계산이 같이 걸려 있어서 생각보다 손이 조금 간다ㅏ.

핵심은 UITextView의 스크롤을 끄고, 텍스트가 변경될 때 UITableView에 높이를 다시 계산하라고 알려주는 것이다.

구현 순서

1. `UITextView`에서 다음 속성들 체크 해제

Show Horizontal Indicator: 텍스트가 가로 크기를 초과한 경우, 가로 스크롤 바 표시
Show Vertical Indicator: 텍스트가 세로 크기를 초과한 경우, 세로 스크롤 바 표시
Scrolling Enabled: 스크롤 가능 여부 설정
Bounce on Scroll: 스크롤이 끝에 도달했을 때, 가볍게 튕기는 애니메이션 설정

2. `Nib` 등록

tableView.register(
 UINib(nibName: "GrowingCell", bundle: nil),
 forCellReuseIdentifier: "GrowingCell"
)

3. 데이터 소스 추가

extension ViewController: UITableViewDataSource {
 func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
 return items.count
 }
 func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
 guard let cell = tableView.dequeueReusableCell(
 withIdentifier: "GrowingCell",
 for: indexPath
 ) as? GrowingCell else {
 return UITableViewCell()
 }
 cell.textView.text = items[indexPath.row]
 cell.delegate = self
 return cell
 }
}

4. 델리게이트 작성

protocol GrowingCellProtocol: class {
 func updateHeightOfRow(_ cell: GrowingCell, _ textView: UITextView)
}

5. 뷰 컨트롤러가 델리게이트 채택하고 구현

extension ViewController: GrowingCellProtocol {
 func updateHeightOfRow(_ cell: GrowingCell, _ textView: UITextView) {
 let size = textView.bounds.size
 let newSize = tableView.sizeThatFits(
 CGSize(
 width: size.width,
 height: CGFloat.greatestFiniteMagnitude
 )
 )
 if size.height != newSize.height {
 UIView.setAnimationsEnabled(false)
 tableView?.beginUpdates()
 tableView?.endUpdates()
 UIView.setAnimationsEnabled(true)
 if let thisIndexPath = tableView.indexPath(for: cell) {
 tableView.scrollToRow(at: thisIndexPath, at: .bottom, animated: false)
 }
 }
 }
}

추가. 공식 문서에서는 beginUpdates() 보다 performBatchUpdates(_:completion:) 의 사용을 권장하고 있음.

UIKit. Responder Chain

Wed, 04 Sep 2024 00:00:00 +0000

앱에서 터치 입력과 같은 유저 인터랙션을 처리할 때, UIKit은 UIResponder 객체를 통해 이벤트를 감지하고 적절히 처리한다. 그렇다면 이벤트가 발생했을 때, 어떻게 적절한 UIResponder 객체를 찾아서 처리할까?

UIKit에서 이벤트가 어떻게 전달되고 처리되는지, 특히 UIResponder와 Responder chain의 흐름을 정리했다.

UIResponder와 UIEvent

개발자 문서에서 UIResponder는 ‘이벤트에 응답하고 처리하기 위한 추상 인터페이스’로 소개한다. 여기서 이벤트란, UIKit에서 UIEvent라는 클래스로 표현되는 단일 유저 인터랙션(예: 터치)을 의미한다. UIEvent 역시 개발자 문서에서 ‘앱에서 단일 유저 인터랙션을 설명하기 위한 객체’라고 정의되어 있다.

UIKit. UIStackView 레이아웃

Tue, 27 Aug 2024 00:00:00 +0000

UIStackView는 여러 뷰를 한 방향으로 묶어 배치할 수 있는 컨테이너 뷰다. 직접 서브뷰마다 제약 조건을 하나씩 걸지 않아도, 스택 뷰에 arranged subview로 추가하면 스택 뷰가 내부 뷰들의 배치를 관리한다.

스택 뷰는 기기의 방향, 화면 크기, 그리고 axis, alignment, distribution, spacing 같은 프로퍼티를 바탕으로 내부 뷰의 레이아웃을 결정한다.

이 글에서는 스택 뷰의 주요 프로퍼티가 레이아웃에 어떤 영향을 주는지 정리한다.

intrinsicContentSize

스택 뷰의 레이아웃을 이해하려면 먼저 intrinsicContentSize를 알아야 한다.

intrinsicContentSize는 뷰가 자신의 내용만을 기준으로 자연스럽게 가지는 크기다. 대표적인 예시는 UILabel이다.

UIKit. 화면 전환 방식

Wed, 21 Aug 2024 00:00:00 +0000

UIKit에서는 화면을 전환하는 방법이 여러 가지 있지만, 실제로는 상황에 따라 적절한 방식을 선택하면 된다.

화면을 계층적으로 이동한다 → Show
Split View의 Detail 화면을 변경한다 → Show Detail
현재 화면 위에 독립적인 화면을 띄운다 → Present Modally
큰 화면에서는 팝오버, 작은 화면에서는 모달로 표시한다 → Present as Popover

이번 글에서는 각각의 방식이 어떤 상황에서 사용되는지 간단히 정리해 보려고 한다.

화면 전환 방식

Show

show(_:sender:)

내비게이션 컨트롤러를 사용하는 경우 새로운 뷰 컨트롤러를 Push하여 화면을 전환한다. 사용자가 계층 구조를 따라 이동하는 대부분의 화면 전환이 여기에 해당한다.

DevOps. Git 기초

Tue, 20 Aug 2024 00:00:00 +0000

깃 파일 라이프 사이클

Tracked: 관리 대상 파일, 이미 스냅샷에 포함되어 있는 파일 - 깃이 이미 알고 있는 파일들…
1. Unmodified: 수정하지 않은 파일
2. Modified: 수정한 파일
3. Staged: 커밋으로 저장소에 기록할 파일
Untracked: 관리 대상이 아닌 파일, 스냅샷 Staging Area에도 포함되지 않은 파일

위 캡처에서

test2: (Staged) 현재 Staging Area에 포함된 파일, 커밋하면 저장소에 기록된다.
test: (Untracked) 트래킹 되지 않은 파일, 스냅샷에도 Staging Area에도 존재하지 않고 워킹 디렉토리에만 존재한다.
README: (Modified) 수정된 파일, 커밋을 하기 위해서는 Staged 상태로 만들어야 함.

파일 새로 추적하기 (git add)

git add 명령은 파일을 새로 추적할 때도 사용하고, 수정한 파일을 Staged 상태로 만들 때도 사용한다.

UIView와 UIViewController의 차이 + 뷰 생명주기 메소드

Tue, 20 Aug 2024 00:00:00 +0000

공식문서 먼저

UIView

An object that manages the content for a rectangular area on the screen.

화면의 사각형 영역을 나타내며, 내부에 다른 뷰를 포함할 수 있다. 대부분의 UI 요소가 UIView를 상속받는다.
콘텐츠를 화면에 나타내고, 사용자의 터치나 제스처를 감지한다.

UIViewController

An object that manages a view hierarchy for your UIKit app.

하나 이상의 뷰를 관리하고, 이 뷰들이 사용자와 상호작용하는 방법을 제어한다.
뷰를 생성하고, 화면에 표시하며, 뷰의 생명 주기를 관리한다.

두 줄 요약

UIView는 화면의 직사각형 영역에 표시되는 콘텐츠를 관리하고, 사용자의 동작을 감지하는 역할을 한다.
UIViewController는 이 UIView를 관리하는 역할을 한다. (사용자의 동작을 감지하면 이 뷰가 어떻게 상호 작용을 해야 할지, UIView 라이프 사이클 관리 등…)

뷰 라이프 사이클 + 뷰 컨트롤러 관련 메소드

순서대로 작성하면

SwiftUI Tutorials. Building Lists and Navigation

Tue, 25 Jun 2024 00:00:00 +0000

사용자가 전체 랜드마크 목록을 보고 각 위치에 대한 세부 정보를 볼 수 있는 방법을 제공해야 한다.

모든 랜드마크에 대한 정보를 표시할 수 있는 뷰를 생성하고 사용자가 탭하여 랜드마크에 대한 디테일 뷰를 볼 수 있는 스크롤 목록을 동적으로 생성한다. UI를 미세 조정하고 싶으면 Xcode를 사용하여 다양한 장치 크기에서 미리보기를 렌더링 하면 된다.

Section 1. Create a landmark model

첫 번째 튜토리얼에선, 모든 정보들을 커스텀 뷰에 하드코딩했다. 이제는 뷰로 전달할 수 있는 데이터를 저장하는 모델을 만들 것이다.

SwiftUI Tutorials. Creating and Combining Views

Tue, 25 Jun 2024 00:00:00 +0000

Section 1. Create a new project and explore the canvas

SwiftUI를 사용하는 새로운 Xcode 프로젝트를 만든다. 캔버스, 미리보기 및 SwiftUI 템플릿 코드를 탐색한다.

Step 1-3

프로젝트 생성 부분

Step 4

SwiftUI 앱 라이프 사이클을 사용하는 앱은 App 프로토콜을 컨펌하는 스트럭처를 가지고 있다. 스트럭처의 body 프로퍼티는 디스플레이에 보여줄 컨텐츠를 제공하는 하나 이상의 씬이 있다. @main 어트리뷰트는 앱의 엔트리 포인트를 지정한다.

//
// LandmarksApp.swift
// Landmarks
//
// Created by Kelly Chui on 6/25/25.
//

import SwiftUI

@main
struct LandmarksApp: App {
 var body: some Scene {
 WindowGroup {
 ContentView()
 }
 }
}

Step 5-7

기본적으로, SwiftUI 뷰 파일은 스트럭처와 프리뷰를 선언한다. 구조체는 View 프로토콜을 컨펌하며, 뷰의 내용과 레이아웃을 정의한다. preview 선언은 해당 뷰의 미리보기를 생성한다.

SwiftUI Tutorials. Handling User Input

Tue, 25 Jun 2024 00:00:00 +0000

랜드마크 앱에서 사용자는 좋아하는 장소를 플래그하고, 그들이 좋아하는 장소만 필터해서 볼 수 있다. 이런 기능을 만들기 위해서, 리스트에 스위치를 추가하여 유저들이 그들이 좋아하는 장소에만 포커스를 맞출 수 있도록 해야한다. 그리고 별 모양 버튼을 추가하고, 탭하면 유저들이 랜드마크에 favorite 플래그를 할 수 있도록 한다.

Section 1. Mark favorite landmarks

리스트를 개선해서 사람들이 한 눈에 favorite를 찾을 수 있도록 시작한다. Landmark 스트럭처에 프로퍼티를 하나 추가해서, 이 랜드마크가 favorite인지 초기 상태를 읽을 수 있도록 한다. 그리고 favorite 표시된 랜드마크에는 별 아이콘을 보여준다.

BOJ 13144. list of unique numbers

Wed, 12 Jun 2024 00:00:00 +0000

문제

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

풀이

매우 특이한 유형의 투 포인터 문제다. start, end가 증가만 해서는 모든 경우의 수를 나타낼 수 없으며, 모든 경우의 수를 탐색하려면 O(n^2)이 된다.

1 2 3 1 2 라는 수열이 있을 때를 생각해보자

겹치는 원소가 나오지 않도록 작성한 일반적인 투 포인터는 1, 12, 123, 231, 312 이렇게 5번 탐색을 하고 종료한다. 하지만 1 2 3 1 2의 정답은 5가 아니라 15이다. 하지만 이 5번의 탐색만으로도 15라는 결과를 얻을 수 있는데, 우리는 정확한 부분 수열의 형태보다 경우의 수만 알면 되기 때문이다.

BOJ 4179. 불

Mon, 10 Jun 2024 00:00:00 +0000

문제

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

풀이

지훈이가 움직이고, 불을 퍼뜨리면 된다. 순서대로 진행하면 되는데 주의해야 할 점이 두 가지 있다.

1분마다 기준으로 번갈아서 움직여야 한다.
지훈이가 움직이기 전에 불에 타면 안된다.

코드

from collections import deque

def bfs(jihun, fires):
 is_jihun_Visited = [[-1] * c for _ in range(r)]
 fire_queue = deque()
 jihun_queue = deque()
 fire_queue.append(fires)
 jihun_queue.append([jihun])

 is_jihun_Visited[jihun[0]][jihun[1]] = 0

 while jihun_queue or fire_queue:
 if jihun_queue:
 jihun_temp_queue = []
 jihun_nodes = jihun_queue.popleft()
 for cur in jihun_nodes:
 if graph[cur[0]][cur[1]] == "F":
 continue
 for move in [(-1, 0), (0, 1), (1, 0), (0, -1)]:
 next = (cur[0] + move[0], cur[1] + move[1])
 if next[0] == -1 or next[1] == -1 or next[0] == r or next[1] == c:
 return is_jihun_Visited[cur[0]][cur[1]] + 1
 if next[0] < 0 or next[0] >= r or next[1] < 0 or next[1] >= c:
 continue
 if is_jihun_Visited[next[0]][next[1]] != -1:
 continue
 if graph[next[0]][next[1]] == ".":
 jihun_temp_queue.append(next)
 is_jihun_Visited[next[0]][next[1]] = is_jihun_Visited[cur[0]][cur[1]] + 1
 if jihun_temp_queue:
 jihun_queue.append(jihun_temp_queue)

 if fire_queue:
 fire_temp_queue = []
 fire_nodes = fire_queue.popleft()
 for cur in fire_nodes:
 for move in [(-1, 0), (0, 1), (1, 0), (0, -1)]:
 next = (cur[0] + move[0], cur[1] + move[1])
 if next[0] < 0 or next[0] >= r or next[1] < 0 or next[1] >= c:
 continue
 if graph[next[0]][next[1]] == ".":
 fire_temp_queue.append(next)
 graph[next[0]][next[1]] = "F"
 if fire_temp_queue:
 fire_queue.append(fire_temp_queue)
 return "IMPOSSIBLE"

r, c = map(int, input().split())
graph = []
for _ in range(r):
 graph.append(list(input()))

jihun = (0, 0)
fires = []

for row in range(r):
 for column in range(c):
 if graph[row][column] == "J":
 jihun = (row, column)
 elif graph[row][column] == "F":
 fires.append((row, column))

print(bfs(jihun, fires))

BOJ 7490. 0 만들기

Mon, 10 Jun 2024 00:00:00 +0000

문제

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

풀이

DFS 문제이다. 3가지 연산자 (" ", "+", "-")를 배치하는 모든 경우의 수를 수식으로 만든 후 계산하면 된다.

코드

import Foundation

func calcuate() {
 var rawExpression = ""
 for idx in 0..<n - 1 {
 rawExpression += String(seq[idx])
 rawExpression += cal[idx]
 }
 rawExpression += String(seq[n - 1])

 let expression = rawExpression.replacingOccurrences(of: " ", with: "")
 var numbers = [Int]()
 var operators = [Character]()
 var numBuffer = ""
 for element in expression {
 if element.isNumber {
 numBuffer.append(element)
 } else {
 numbers.append(Int(numBuffer)!)
 operators.append(element)
 numBuffer = ""
 }
 }
 if let lastNumber = Int(numBuffer) {
 numbers.append(lastNumber)
 }

 var result = numbers[0]
 for idx in 0..<operators.count {
 if operators[idx] == "-" {
 result -= numbers[idx + 1]
 } else {
 result += numbers[idx + 1]
 }
 }
 if result == 0 {
 print(rawExpression)
 }
}

func dfs() {
 if cal.count == n - 1 {
 calcuate()
 return
 }
 for op in [" ", "+", "-"] {
 cal.append(op)
 dfs()
 cal.removeLast()
 }
}

let t = Int(readLine()!)!

var n = Int()
var seq = [Int]()
var cal = [String]()

for _ in 0..<t {
 n = Int(readLine()!)!
 seq = Array(1...n)
 cal = []
 dfs()
 print()
}

가로등 간의 최대 간격을 찾으면 되는 문제이다. 일반적인 가로등 간의 간격과, 시작점과 첫 가로등의 간격, 도착점과 마지막 가로등의 간격을 알아내면 된다.

가로등 사이의 간격은 양 사이드 모두가 가로등이기 때문에 간격에서 2를 나눠줄 필요가 있다.

이 문제에는 작은 함정이 하나 있는데, 가로등 사이의 간격이 만약 홀수인 경우에는 2로 나눴을 때 0.5가 내림 되기 때문에 주의해야 한다.

코드

import Foundation

let n = Int(readLine()!)!
let m = Int(readLine()!)!
let x = readLine()!.split(separator: " ").map { Int($0)! }

var answer = max(x.first!, n - x.last!)
for idx in 1..<m {
 let interval = Int(ceil(Double(x[idx] - x[idx - 1]) / 2.0))
 if interval > answer {
 answer = interval
 }
}
print(answer)

Network. Network 오버뷰

Tue, 30 Apr 2024 00:00:00 +0000

네트워크

노드와 링크(엣지)들이 서로 연결되어 리소스를 공유하는 구조이며, 그래프 형태로 표현할 수 있다.

노드: 서버, 라우터, 스위치
링크: 유선 or 무선

키워드

네트워크 토폴로지
클라이언트와 서버
패킷
주소와 전송 방식
프로토콜

네트워크 참조 모델

통신이 이루어지는 단계를 계층적으로 표현한 모델

OSI Model

계층	대표 역할
Application	HTTP, DNS 등 네트워크 서비스
Presentation	인코딩, 압축, 암호화
Session	세션 관리
Transport	TCP, UDP
Network	라우팅, IP
Data Link	같은 LAN에서의 통신
Physical	비트 전송

TCP/IP Model

응용 계층(Application Layer): OSI 모델에서 세션, 표현, 응용 계층
전송 계층(Transport Layer): OSI 모델에서 전송 계층
인터넷 계층(Internet Layer): OSI 모델에서 네트워크 계층
네트워크 액세스 계층(Network Access Layer): OSI 모델에서 데이터 링크 계층 (+ 물리 계층)

캡슐화와 역캡슐화(Encapsulation, Decapsulation)

캡슐화
- 데이터가 계층를 거치면서 헤더가 추가되는 과정, 상위 계층로부터 내려받은 패킷을 페이로드로 하고, 각 계층에 포함된 프로토콜의 헤더나 트레일러를 덧붙이는 과정
역캡슐화
- 캡슐화 과정에서 덧붙인 헤더들을 각 계층에서 확인한 뒤, 제거하는 과정

각 계층마다 패킷을 부르는 명칭이 다르다.

Network. Physical & Data Link Layer

Tue, 30 Apr 2024 00:00:00 +0000

Physical & Data Link Layer

Physical Layer: 전기, 광, 무선 등의 신호를 통해 데이터를 전송하는 계층
Data Link Layer: 같은 LAN에서 데이터를 올바르게 전달하기 위한 계층

주요 기술

Ethernet

같은 LAN 안에서 데이터를 주고받는 대표적인 기술이다.

Ethernet Frame

이더넷 기반의 네트워크에서 주고받는 프레임, 프리앰블, 송 · 수신 MAC 주소, 타입/길이, 데이터, FCS로 구성

프리앰블(preamble)
- 8 Bytes
- 이더넷 프레임을 수신하고 있다는 것을 알려주는 부분
MAC 주소(MAC address)
- 12(6 + 6) Bytes
- 이더넷 프레임을 송 · 수신할 장치의 MAC 주소를 가지고 있음
타입/길이(type/length)
- 2 Bytes
- 1500 이상의 값일 경우에는 프로토콜의 타입을 뜻함
- 1500 이하의 경우엔 LLC라는 값으로 타입 판별한다. 하지만 요즘은 거의 대부분 Ethernet II를 사용하기 때문에 명확하게 타입으로 사용함.
데이터(data)
- 최대 1500Bytes
- 실제로 송수신할 데이터
FCS
- 프레임의 오류가 있는지 여부를 확인하기 위한 트레일러
- CRC(Cyclic redundancy check)라는 오류 검출용 값이 명시됨.

Wireless

유선이 아닌 전파로 통신하는 방법이다. 대표적으로 와이파이가 있다. 주파수 간섭 문제를 최소화 하기 위해 채널이라는 하위 주파수 대역으로 세분화한다.

BOJ 14890. 경사로

Fri, 19 Apr 2024 00:00:00 +0000

문제

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

풀이

경사로의 방향을 생각해보면 왼쪽에서 오른쪽으로 올라가는 방향이 있을 것이고, 그 반대인 오른쪽에서 왼쪽으로 올라가는 방향도 있을 것이다. 이러한 경우에는 한 번에 해결하기 보다는 배열을 정방향, 역방향으로 각각 순회하여 경사로를 만들어주는 것이 좋다.

따라서 알고리즘은 다음과 같다.

주어진 2차원 배열을 Transpose한 배열을 하나 더 만든다. 세로 모양의 길을 찾기 위해서이다.
정방향으로 우선 순회한다. 다음에 있는 칸의 높이가 현재 칸보다 같으면 count를 하나 늘리고(count는 경사로를 지을 수 있는지 판단할 때 사용한다.) 1 낮으면 일단은 패스(역방향에서 확인한다), 1 높으면 경사로를 설치할 수 있는지 판단한다.
경사로를 설치할 수 있는지 판단하는 기준은 두 가지이다. 일단 경사로를 설치하기 충분한 공간이 확보되었는가 (count로 충분한 공간이 얼마나 있는지를 알 수 있다.), 만약 가능하다면 이미 그곳에 경사로가 설치되어 있지는 않는가(이는 is_built 배열로 추적한다. 하지만 정방향을 먼저 하므로 지금 상황에선 필요 없다.)
역방향으로 순회한다. 정방향과 같지만 정방향을 순회하면서 경사로를 지은 곳을 유의할 필요가 있다.

코드

def check(line):
 is_built = [False] * n
 current_height = line[0]
 count = 1
 for idx in range(1, n):
 if current_height == line[idx]:
 count += 1
 elif current_height - line[idx] == 1:
 current_height = line[idx]
 continue
 elif current_height - line[idx] == -1:
 if count >= l:
 for back in range(1, l + 1):
 is_built[idx - back] = True
 count = 1
 else:
 return False
 current_height = line[idx]
 else:
 return False

 current_height = line[n - 1]
 count = 1
 for idx in range(n - 2, -1, -1):
 if current_height == line[idx]:
 count += 1
 elif current_height - line[idx] == 1:
 current_height = line[idx]
 continue
 elif current_height - line[idx] == -1:
 if count >= l:
 for back in range(1, l + 1):
 if is_built[idx + back]:
 return False
 is_built[idx + back] = True
 count = 1
 else:
 return False
 current_height = line[idx]
 else:
 return False
 return True

n, l = map(int, input().split())
graph = []
graph_tranposed = [[0] * n for _ in range(n)]
answer = 0

for _ in range(n):
 graph.append(list(map(int, input().split())))

for row in range(n):
 for column in range(n):
 graph_tranposed[row][column] = graph[column][row]

for idx in range(n):
 answer += 1 if check(graph[idx]) else 0
 answer += 1 if check(graph_tranposed[idx]) else 0

print(answer)

BOJ 14891. 톱니바퀴

Fri, 19 Apr 2024 00:00:00 +0000

문제

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

풀이

상황 설명이 굉장히 난해하고 비직관적이므로 글을 잘 읽어야 한다. 문제를 겨우 이해하고 나면 알고리즘이나 구현 능력 자체는 크게 요구하지 않는다. 글을 이해하는것 자체가 이 문제의 가장 큰 난관이다.

이 문제에서 톱니바퀴는 현실의 톱니바퀴처럼 움직이지 않는다. 이전 톱니바퀴가 회전하면 다음 톱니바퀴도 회전해야할지 말아야 할지를 이미 돌아간 상태의 이전 톱니바퀴가 아닌 돌기 전의 이전 톱니바퀴의 상태로 판단해야 한다.

코드

class Gear():
 def __init__(self, stat):
 self.__stat = stat
 self.__top = 0
 self.__left = 6
 self.__right = 2

 def rotate(self, drct):
 self.__top = (self.__top - drct) % 8
 self.__left = (self.__left - drct) % 8
 self.__right = (self.__right - drct) % 8

 @property
 def top(self):
 return self.__stat[self.__top]
 @property
 def left(self):
 return self.__stat[self.__left]
 @property
 def right(self):
 return self.__stat[self.__right]

def left_shift(gear_num, drct):
 new_drct = drct * -1
 cur_gear = gear_num
 for next_gear in range(gear_num - 1, 0, -1):
 if gears[next_gear].right != gears[cur_gear].left:
 rotate_queue.append((next_gear, new_drct))
 cur_gear = next_gear
 new_drct *= -1
 else:
 break

def right_shift(gear_num, drct):
 new_drct = drct * -1
 cur_gear = gear_num
 for next_gear in range(gear_num + 1, 5):
 if gears[next_gear].left != gears[cur_gear].right:
 rotate_queue.append((next_gear, new_drct))
 cur_gear = next_gear
 new_drct *= -1
 else:
 break

gear1 = Gear(list(map(int, input())))
gear2 = Gear(list(map(int, input())))
gear3 = Gear(list(map(int, input())))
gear4 = Gear(list(map(int, input())))
gears = [None, gear1, gear2, gear3, gear4]

k = int(input())
answer = 0

rotate_queue = []

for _ in range(k):
 num, drct = map(int, input().split())
 rotate_queue.append((num, drct))
 left_shift(num, drct)
 right_shift(num, drct)
 for g, d in rotate_queue:
 gears[g].rotate(d)
 rotate_queue = []

rank = 1
for idx in range(1, 5):
 answer += gears[idx].top * rank
 rank *= 2

print(answer)

BOJ 14499. 주사위 굴리기

Mon, 15 Apr 2024 00:00:00 +0000

문제

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

풀이

특별한 알고리즘이나 문제 해결 기법을 사용할 필요 없이, 순수하게 딕셔너리 자료구조만을 사용해서 풀 수 있는 문제이다.

주어진 주사위의 전개도를 이용하여 각 면에 숫자를 붙이고(면에 써져있는 숫자가 아닌 각 면을 인식하게 해주는 숫자, 이하 ID숫자라고 하겠다.) 이를 방향: ID 숫자의 꼴로 딕셔너리를 생성한다.

또 ID숫자: 면에 적힌 숫자 꼴로 딕셔너리를 하나 더 생성하여 두개의 딕셔너리로 주사위의 방향과 각 면에 적혀있는 숫자를 추적할 수 있다.

코드

import copy

def north():
 global dice_drct
 original_drct = copy.deepcopy(dice_drct)
 for new, ori in zip(["u", "l", "n", "e", "w", "s"], ["s", "n", "u", "e", "w", "l"]):
 dice_drct[new] = original_drct[ori]

def south():
 global dice_drct
 original_drct = copy.deepcopy(dice_drct)
 for new, ori in zip(["u", "l", "n", "e", "w", "s"], ["n", "s", "l", "e", "w", "u"]):
 dice_drct[new] = original_drct[ori]

def east():
 global dice_drct
 original_drct = copy.deepcopy(dice_drct)
 for new, ori in zip(["u", "l", "n", "e", "w", "s"], ["w", "e", "n", "u", "l", "s"]):
 dice_drct[new] = original_drct[ori]

def west():
 global dice_drct
 original_drct = copy.deepcopy(dice_drct)
 for new, ori in zip(["u", "l", "n", "e", "w", "s"], ["e", "w", "n", "l", "u", "s"]):
 dice_drct[new] = original_drct[ori]

def change():
 if graph[x][y] == 0:
 graph[x][y] = dice_num[dice_drct["l"]]
 else:
 dice_num[dice_drct["l"]] = graph[x][y]
 graph[x][y] = 0

def check(x, y):
 if x < 0 or x >= n or y < 0 or y >=m:
 return False
 return True

n, m, x, y, k = map(int, input().split())
graph = []
for _ in range(n):
 graph.append(list(map(int, input().split())))
orders = list(input().split())

dice_num = {1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0}
dice_drct = {"u": 1, "l": 6, "n": 2, "e": 3, "w": 4, "s": 5}

for order in orders:
 isTrue = False
 if order == "1":
 if check(x, y + 1):
 y += 1
 east()
 change()
 isTrue = True
 if order == "2":
 if check(x, y - 1):
 y -= 1
 west()
 change()
 isTrue = True
 if order == "3":
 if check(x - 1, y):
 x -= 1
 north()
 change()
 isTrue = True
 if order == "4":
 if check(x + 1, y):
 x += 1
 south()
 change()
 isTrue = True
 if isTrue:
 print(dice_num[dice_drct["u"]])

BOJ 12100. 2048(Easy)

Sun, 14 Apr 2024 00:00:00 +0000

문제

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

풀이

최대 20 * 20 크기의 보드에서 2048 게임을 하는 것이다. 최대 5번의 이동만 한다고 문제에 주어져 있으므로, 모든 경우를 탐색하여 문제를 풀 수 있다.

이 문제에서 주의해야할 점은 다음과 같다.

이동하는 방향에서 가까운 숫자부터 이동해야한다.
한 번의 이동동안 이미 합쳐진 숫자는 다시 합쳐지지 않는다.

이 두가지 조건만 잘 생각하면서 작성하면 된다.

코드

import Foundation

func dfs(_ size: Int) {
 if size == 5 {
 for row in 0..<n {
 for column in 0..<n {
 answer = max(answer, graph[row][column])
 }
 }
 return
 }
 for i in 0..<4 {
 let currentGraph = graph
 shift(i)
 dfs(size + 1)
 graph = currentGraph
 }
}

func shift(_ order: Int) {
 var isMerged = [[Bool]](repeating: [Bool](repeating: false, count: n), count: n)
 if order == 0 {
 for row in 0..<n {
 for column in 0..<n {
 if graph[row][column] != 0 {
 var newRow = row
 while newRow > 0 {
 if graph[newRow - 1][column] == 0 {
 let temp = graph[newRow][column]
 graph[newRow][column] = graph[newRow - 1][column]
 graph[newRow - 1][column] = temp
 newRow -= 1
 } else if graph[newRow][column] == graph[newRow - 1][column] {
 if isMerged[newRow - 1][column] {
 break
 }
 let temp = graph[newRow][column]
 graph[newRow][column] = graph[newRow - 1][column]
 graph[newRow - 1][column] = temp * 2
 graph[newRow][column] = 0
 isMerged[newRow - 1][column] = true
 break
 } else {
 break
 }
 }
 }
 }
 }
 }
 if order == 1 {
 for column in 0..<n {
 for row in (0..<n).reversed() {
 if graph[row][column] != 0 {
 var newRow = row
 while newRow < n - 1 {
 if graph[newRow + 1][column] == 0 {
 let temp = graph[newRow][column]
 graph[newRow][column] = graph[newRow + 1][column]
 graph[newRow + 1][column] = temp
 newRow += 1
 } else if graph[newRow][column] == graph[newRow + 1][column] {
 if isMerged[newRow + 1][column] {
 break
 }
 let temp = graph[newRow][column]
 graph[newRow][column] = graph[newRow + 1][column]
 graph[newRow + 1][column] = temp * 2
 graph[newRow][column] = 0
 isMerged[newRow + 1][column] = true
 break
 } else {
 break
 }
 }
 }
 }
 }
 }
 if order == 2 {
 for row in 0..<n {
 for column in 0..<n {
 if graph[row][column] != 0 {
 var newColumn = column
 while newColumn > 0 {
 if graph[row][newColumn - 1] == 0 {
 let temp = graph[row][newColumn]
 graph[row][newColumn] = graph[row][newColumn - 1]
 graph[row][newColumn - 1] = temp
 newColumn -= 1
 } else if graph[row][newColumn] == graph[row][newColumn - 1] {
 if isMerged[row][newColumn - 1] {
 break
 }
 let temp = graph[row][newColumn]
 graph[row][newColumn] = graph[row][newColumn - 1]
 graph[row][newColumn - 1] = temp * 2
 graph[row][newColumn] = 0
 isMerged[row][newColumn - 1] = true
 break
 } else {
 break
 }
 }
 }
 }
 }
 }
 if order == 3 {
 for row in 0..<n {
 for column in (0..<n).reversed() {
 if graph[row][column] != 0 {
 var newColumn = column
 while newColumn < n - 1 {
 if graph[row][newColumn + 1] == 0 {
 let temp = graph[row][newColumn]
 graph[row][newColumn] = graph[row][newColumn + 1]
 graph[row][newColumn + 1] = temp
 newColumn += 1
 } else if graph[row][newColumn] == graph[row][newColumn + 1] {
 if isMerged[row][newColumn + 1] {
 break
 }
 let temp = graph[row][newColumn]
 graph[row][newColumn] = graph[row][newColumn + 1]
 graph[row][newColumn + 1] = temp * 2
 graph[row][newColumn] = 0
 isMerged[row][newColumn + 1] = true
 break
 } else {
 break
 }
 }
 }
 }
 }
 }
}

var n = Int(readLine()!)!
var graph = [[Int]]()
for _ in 0..<n {
 graph.append(readLine()!.split(separator: " ").map { Int(String($0))! })
}
var answer = 0

dfs(0)
print(answer)

BOJ 13460. 구슬 탈출 2

Sat, 13 Apr 2024 00:00:00 +0000

문제

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

풀이

기울이는 방향에 따라서 구슬이 이동하므로, 구슬이 이동할 수 있는 방향은 상하좌우임을 알 수 있다. 이 때, 한 번 기울일 때 마다 구슬의 최종 위치는 하나가 나오므로, BFS를 이용해서 문제를 해결할 수 있다.

문제의 조건을 정리하면 다음과 같다.

한 칸에는 구슬 한 개만 들어갈 수 있다.
한 번 기울이면 구슬이 더 이상 움직이지 못할 때 까지 움직인다.
10번 이하의 횟수로만 기울인다.

1, 2 조건을 조합하면 구슬이 다른 구슬을 만나도 벽을 만난것과 같음을 알 수 있고, 따라서 구슬이 겹친 경우에는 처리를 해줘야 한다.

BOJ 10021. watering the fields

Fri, 12 Apr 2024 00:00:00 +0000

문제

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

풀이

“모든 필드를 파이프 네트워크로 연결하는 데 필요한 최소 금액"에서 MST 문제임을 알았다. 크루스칼 알고리즘을 쓰면 쉽게 풀릴 문제다.

우선 각 노드간의 거리를 알 수 없으므로 모든 경우의 수를 계산해야 한다. 필드의 개수가 2000개 이하이므로 O(n^2)의 연산을 해도 충분하다.

그 이후에는 크루스칼 알고리즘을 적용하면 되는데, 제약조건 중 하나가 비용이 C 미만인 파이프는 만들지 않는다는 것이다. 따라서 두 노드간 거리가 C 미만인 엣지는 존재하지 않는 것으로 해야한다.

코드

def find(field):
 if parent[field] == field:
 return field
 else:
 parent[field] = find(parent[field])
 return parent[field]

def union(a, b):
 pa = find(a)
 pb = find(b)
 if pa != pb:
 parent[pa] = pb

def squared_euclidean_length(a, b):
 return (a[0] - b[0]) ** 2 + (a[1] - b[1]) ** 2

n, c = map(int, input().split())
fields = []
mapping = {}

for idx in range(n):
 xi, yi = map(int, input().split())
 fields.append((xi, yi))
 mapping[(xi, yi)] = idx
edges = []
parent = list(range(n))

for i in range(0, len(fields) - 1):
 for j in range(i + 1, len(fields)):
 distance = squared_euclidean_length(fields[i], fields[j])
 if distance >= c:
 edges.append((mapping[fields[i]], mapping[fields[j]], distance))

edges.sort(key = lambda x: x[2])

answer = 0
count = 0
for edge in edges:
 if find(edge[0]) != find(edge[1]):
 union(edge[0], edge[1])
 answer += edge[2]
 count += 1

print(answer if count == n - 1 else -1)

BOJ 15591. mootubesliver

Fri, 12 Apr 2024 00:00:00 +0000

문제

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

풀이

문제가 복잡하게 설명되어 있다. 중요한 것은 모든 노드가 연결되어 있고 웨이트를 가진 엣지가 존재하지만, 두 노드간의 거리는 경로상의 가장 작은 웨이트를 가진 엣지가 된다.

따라서 웨이트가 있다 해서 다익스트라를 쓸 필요가 없다. 들어오는 쿼리마다 BFS를 이용하여 그래프를 탐색하고 두 노드간의 거리는 실시간으로 업데이트 해주면 된다.

코드

from collections import deque

def bfs(k, v):
 queue = deque()
 queue.append((v, 987_654_321))
 isVisited = [False] * (n + 1)
 isVisited[v] = True
 answer = 0

 while queue:
 cur_node, cur_usado = queue.popleft()
 for next_node, next_usado in graph[cur_node]:
 if isVisited[next_node]:
 continue
 if cur_usado < next_usado:
 next_usado = cur_usado
 if next_usado >= k:
 queue.append((next_node, next_usado))
 isVisited[next_node] = True
 answer += 1
 print(answer)

n, q = map(int, input().split())
graph = {}
for _ in range(n - 1):
 pi, qi, ri = map(int, input().split())
 if pi in graph:
 graph[pi].append((qi, ri))
 else:
 graph[pi] = [(qi, ri)]
 if qi in graph:
 graph[qi].append((pi, ri))
 else:
 graph[qi] = [(pi, ri)]

for _ in range(q):
 k, v = map(int, input().split())
 bfs(k, v)

BOJ 5558. チズ cheese

Fri, 12 Apr 2024 00:00:00 +0000

문제

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

파파고 번역

올해도 JOI 마을의 치즈 공장이 치즈 생산을 시작하여, 쥐들이 둥지에서 얼굴을 내밀었다. JOI 마을은 동서남북으로 구획 정리되어 있고, 각 구획은 둥지, 치즈 공장, 장애물, 공터 중 하나이다. 쥐들은 둥지에서 출발하여 모든 치즈 공장을 방문 하여 치즈를 한 개씩 먹는다.
이 마을에는 N개의 치즈 공장이 있는데, 모든 공장이 한 종류의 치즈만을 생산한다. 치즈의 단단함은 공장마다 다르고 단단함도 다르다 1부터 N까지의 치즈를 생 산하는 치즈공장이 마침 하나씩 있다.
증가
쥐들의 첫 번째 체력은 1이고, 치즈를 한 개 먹을 때마다 그들의 체력은 1증가 하지만, 쥐들은 자신의 체력보다 더 단단한 치즈를 먹을 수는 없다.
쥐는 동서남북으로 이웃한 구역으로 1분이면 이동할 수 있지만, 장애물 구역에는 들어갈 수 없다. 치즈 공장을 치즈를 먹지 않고 지나갈 수도 있다. 치즈를 다 먹을 때까지 걸리는 가장 짧은 시간을 요구하는 프로그램을 작성하라. 쥐가 치즈를 먹 는 데 걸리는 시간은 무시할 수 없다.

우선 최악의 경우를 생각해보자. N, M이 각각 500,000 이고, L은 1, K가 100일 때가 최악인 경우가 된다. 이 상태에서 모든 경우의 수를 확인하려면 별의 위치를 250,000,000,000,000번 확인해야 한다. 따라서 모든 경우의 수를 판단하는건 불가능 하다.

따라서 트램펄린을 설치할 위치를 합리적으로 정해야 한다. 주어진 조건을 보면 별이 최대 100개 까지밖에 없으므로 이를 활용하여 생각해본다.

우선 별 하나를 기준으로 보면 L * L 크기의 트램펄린이고, 별이 최대 100개 있으므로 확인해야 할 위치는 최악의 경우에 100,000,000,000,000개 이다. 사실상 위의 경우와 다를바가 없으므로 불가능하다.

Combine. Combine in Practice - WWDC19

Mon, 18 Mar 2024 00:00:00 +0000

A unified, declarative API for processing values over time

Combine에서는 값이 시간의 흐름에 따라 전달되는 과정을 Publisher로 표현하고, 여러 연산자를 연결해 데이터가 변환되는 흐름을 선언적으로 작성한다. 아래 예제에서는 Notification으로 전달된 Data를 MagicTrick으로 디코딩한다.

let trickNamePublisher = NotificationCenter.default.publisher(for: .newTrickDownloaded)
 .map { notification in
 return notification.userInfo?["data"] as! Data
 } // Output: Data, Failure: Never
 .tryMap { data in
 let decoder = JSONDecoder()
 try decoder.decode(MagicTrick.self, from: data)
 } // Output: MagicTrick, Failure: Error

decode 연산자를 사용하면 위 변환을 다음과 같이 줄여서 작성할 수 있다.

let trickNamePublisher = NotificationCenter.default.publisher(for: .newTrickDownloaded)
 .map { notification in
 return notification.userInfo?["data"] as! Data
 } // Output: Data, Failure: Never
 .decode(MagicTrick.self, JSONDecoder()) // Output: MagicTrick, Failure: Error

Error Handling

모든 Publisher는 자신이 발생시킬 수 있는 실패의 종류를 명확하게 정의한다.
실패가 발생하지 않거나 이미 처리된 경우에는 Never를 Failure 타입으로 사용한다.
Combine은 실패를 감지하고 복구할 수 있는 다양한 연산자를 제공한다.

Combine의 Publisher는 전달하는 값의 타입인 Output과 실패할 때 전달하는 오류의 타입인 Failure를 함께 가진다. 두 타입이 연산자를 거치며 어떻게 바뀌는지 확인하면 데이터 흐름과 오류 흐름을 함께 추적할 수 있다.

Combine. Introducing Combine - WWDC19

Sun, 17 Mar 2024 00:00:00 +0000

Combine

Customize handling of asynchronous events by combining event-processing operators.

결합된 이벤트 처리 연산자를 이용하여 비동기 이벤트 처리를 커스터마이즈 하는 방법

Combine은 데이터 흐름을 간편하게 처리하고 비동기 이벤트를 관리하기 위한 프레임워크다. 다양한 소스에서 발생하는 이벤트를 같은 방식으로 다루고, 이벤트 사이의 상호작용을 연산자로 조합할 수 있다.

특징

Generic: 제네릭을 사용해 다양한 타입의 데이터 흐름을 표현한다.
Type safe: Publisher의 출력 타입과 실패 타입을 컴파일 타임에 확인한다.
Composition first: 작은 Publisher와 연산자를 조합해 더 큰 흐름을 만든다.
Request driven: Subscriber가 필요한 만큼의 값을 요청하는 방식으로 흐름을 제어한다.

핵심 개념

Publisher

값과 에러가 어떻게 생성되는지를 정의한다.

Network. HTTP(HyperText Transfer Protocol)

Thu, 14 Mar 2024 00:00:00 +0000

HTTP

HTTP: HyperText Transfer Protocol

HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 애플리케이션 계층 프로토콜이다.

클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환하는 Request-Response 방식으로 동작한다.

동작 방식

Client
↓ HTTP Request
Server
↓ HTTP Response
Client

특징

Request-Response 방식으로 동작한다.
Stateless를 기본으로 한다.
HTTP/1.x와 HTTP/2는 TCP를 기반으로 동작한다.

버전별 변화

HTTP/1.0

기본적으로 요청마다 연결을 새로 만드는 방식이 널리 사용됐다. 서버에서 여러 파일을 가져올 때 TCP 연결을 반복해서 설정하면 지연이 커질 수 있다. 다만 HTTP/1.0에서도 Connection: keep-alive를 확장 기능으로 사용할 수 있었다.

Network. 네트워크 기기

Thu, 14 Mar 2024 00:00:00 +0000

네트워크 기기의 처리 범위

네트워크 장비는 주로 어떤 계층의 정보를 보고 전달 여부를 결정하는지에 따라 구분한다. 실제 장비는 여러 계층의 기능을 함께 제공할 수 있으므로 아래 구분은 대표적인 처리 기준이다.

애플리케이션 계층: L7 스위치
인터넷 계층: 라우터, L3 스위치
데이터 링크 계층: L2 스위치, 브리지
데이터 링크·물리 계층: NIC, 무선 AP
물리 계층: 리피터

애플리케이션 계층을 처리하는 기기

애플리케이션 계층의 정보를 기반으로 트래픽을 처리하는 장비

L7스위치(로드 밸런서)

HTTP 헤더, URL 경로, 쿠키처럼 애플리케이션 계층의 정보를 읽어 요청을 적절한 백엔드 서버로 분산하는 장비 또는 소프트웨어

TCP/IP 4계층

Wed, 13 Mar 2024 00:00:00 +0000

소개

TCP/IP 4계층은 OSI 7계층과 더불어 인터넷에서 데이터를 주고받기 위해 사용하는 대표적인 네트워크 참조 모델이다.

네트워크 통신 과정을 역할에 따라 계층으로 분리하여 관리하며, 각 계층은 독립적인 역할을 수행한다.

덕분에 특정 계층의 구현이 변경되더라도 다른 계층에 미치는 영향을 최소화할 수 있다.

계층 구성

애플리케이션(Application)

대표 프로토콜: HTTP, HTTPS, DNS, FTP, SMTP

응용 프로그램이 사용되는 프로토콜 계층 이메일, 웹 서비스 등 서비스를 실질적으로 제공

전송(Transport)

대표 프로토콜: TCP, UDP

송신자와 수신자 간의 데이터 전송을 담당하는 계층

Swift. Meta Type

Fri, 26 Jan 2024 00:00:00 +0000

소개

메타 타입은 이러한 타입 자체를 값으로 다루기 위한 타입이다.

즉, 인스턴스가 아니라 타입 그 자체를 표현하는 타입이라고 생각하면 된다.

종류

`.Type`

구조체, 클래스, 열거형 등 구체적인 타입의 메타 타입이다.

let type: Int.Type = Int.self

`.Protocol`

프로토콜 자체의 메타 타입이다.

let type: AnyObject.Protocol = AnyObject.self

언제 사용할까?

메타 타입은 생각보다 자주 등장한다.

타입 자체를 함수의 인자로 전달할 때
런타임에 타입을 비교하거나 확인할 때
타입 정보를 저장해야 할 때
type(of:)를 사용할 때

필요한 이유

메타 타입이 필요한 가장 큰 이유는 타입 자체를 값처럼 다루기 위해서이다.

BOJ 17298. 오큰수

Mon, 10 Jul 2023 00:00:00 +0000

문제

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

풀이

스택을 이용하는 문제이다. 2493번 문제와 사실상 같은 문제인데, 배열이 뒤집혀 있다는 것과 인덱스가 아닌 해당 인덱스에 대응하는 값을 사용하는 것이 다르다.

코드

Swift

import Foundation

let n = Int(readLine()!)!
let a = Array(readLine()!.split(separator: " ").map { Int(String($0))! }.reversed())
var stack: [Int] = []
var answer: [Int] = []

for element in a {
 while !stack.isEmpty && stack.last! <= element {
 stack.removeLast()
 }
 if let last = stack.last {
 answer.append(last)
 } else {
 answer.append(-1)
 }
 stack.append(element)
}

print(answer.map { String($0) }.reversed().joined(separator: " "))

C++

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int main() {
 int n;
 cin >> n;
 vector<int> a;
 for(int i = 0; i < n; i++) {
 int temp;
 cin >> temp;
 a.push_back(temp);
 }
 vector<int> stack;
 vector<int> answer;
 reverse(a.begin(), a.end());
 for(int element: a) {
 while(!stack.empty() && stack.back() <= element) {
 stack.pop_back();
 }
 if(stack.empty()) {
 answer.push_back(-1);
 } else {
 answer.push_back(stack.back());
 }
 stack.push_back(element);
 }
 for(int answerIndex = (int)answer.size() - 1; answerIndex >= 0; answerIndex--) {
 cout << answer[answerIndex] << " ";
 }
}

BOJ 2293. 동전 1

Mon, 10 Jul 2023 00:00:00 +0000

문제

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

풀이

DP를 사용하는 문제이다. dp 테이블의 각 인덱스가 해당 인덱스 만큼의 가치를 만들 수 있는 경우의 수 라고 하면 쉽게 풀 수 있다.

동전의 가치를 value라고 하면 그 동전을 하나 추가해서 i만큼의 가치를 만들 수 있는 경우의 수는 dp[i] += dp[i - value] 라고 할 수 있다. 따라서 하나의 가치에 대해서 동전의 종류의 수 만큼 반복문을 돌려야 한다.

문제에서 주어진 또 다른 조건은 경우의 수가 2의 31제곱이 넘지 않는다는 것이다. 또한 스위프트에서는 오버플로우를 방지하기 위해 2의 31제곱이 넘어가는 수를 다 제거해줘야 한다. (최종적으로 출력할 결과가 2의 31제곱이 넘어가지 않으므로 중간에 2의 31제곱이 넘는 값은 자연스럽게 쓸모가 없는 값이 된다.)

BOJ 2493. 탑

Mon, 10 Jul 2023 00:00:00 +0000

문제

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

풀이

스택을 사용하면 쉽게 풀 수 있는 문제이다. 각 탑에서 왼쪽에 신호를 발사하므로, 현재 인덱스보다 앞에 있는 인덱스중 가장 먼저 나오는 값이 더 큰 인덱스를 찾으면 된다.

현재 인덱스의 탑과 스택의 top에 있는 인덱스의 탑을 비교한다. top 인덱스의 탑이 더 크면 이 인덱스에 있는 탑은 처음으로 신호를 받는 탑이므로, answer 배열에 추가한다. 그렇지 않다면, 해당 인덱스에 있는 탑은 신호를 받지 못하는 탑 이므로 스택에서 제거한다. 현재 인덱스가 다음 인덱스들의 신호를 받을 수 있으므로 스택에 현재 인덱스를 추가한다.

BOJ 1939. 중량 제한

Fri, 07 Jul 2023 00:00:00 +0000

문제

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

풀이

섬(노드)들과 다리(엣지)로 이루어진 그래프가 주어지고, 그 다리들 사이를 지나 목표 노드에 도착해야 한다.

다리에 웨이트가 존재하지 않고 (중량 제한은 엣지가 유효한지 판단하는 기준일 뿐 엣지의 웨이트랑 관련 없다) 최단 거리를 구하는 문제도 아니므로, 다익스트라 알고리즘이 아닌 BFS를 이용해 탐색할 수 있다.

중량이 늘어날수록 건널 수 있는 다리가 적어진다(엣지가 비활성화 된다). 우리는 이 때 주어진 두 섬 중 하나의 섬에서 다른 하나의 섬으로 갈 수 있는 최대의 중량을 구하면 된다. 리니어 서치로도 결과를 구할 수야 있겠지만 현실적으로 1 - 1,000,000,000 값을 다 탐색하는건 너무 비효율적이기 때문에 바이너리 서치를 하면 된다.

BOJ 1520. 내리막 길

Thu, 06 Jul 2023 00:00:00 +0000

문제

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

풀이

dfs를 이용하면 쉽게 풀 수 있는 문제일 것 같지만, 주어지는 그래프의 크기가 커서 시간초과가 나오는 문제이다. 하지만 이러한 문제들은 중첩되는 연산이 많으므로 DP를 이용하면 시간초과 없이 해결할 수 있는 경우가 흔하다.

DP의 컨셉은 다음과 같다.

그래프의 특정 칸에서 목적지로 도착하는 경우의 수는 앞선 경로에 상관없이 항상 같다.
따라서 각 칸에서 목적지로 가는 경로의 수를 dp테이블에 메모이제이션 한다면 불필요한 연산을 하지 않아도 된다.

따라서 점화식을 dp[x][y] = dp[x - 1][y] + dp[x + 1][y] + dp[x][y - 1] + dp[x][y + 1]로 일반화 할 수 있다. 각 항에서 탐색이 불가능한 칸((x, y)보다 높은 칸, 존재하지 않는 칸) 에 대응되는 항은 제외해야하기 때문에 엄밀히 말해서는 틀리지만, 이해하는데는 충분하다.

BOJ 16234. 인구 이동

Thu, 06 Jul 2023 00:00:00 +0000

문제

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

풀이

그래프 각 원소를 전체 탐색하며, BFS를 수행하는 문제이다. 탐색할 수 있는 칸에 대한 제약조건이 문제에 제시되므로, 이에 따라 BFS를 수행하면 된다.

알고리즘은 다음과 같다.

그래프 전체를 순서대로 순회한다. 이 때 칸이 isVisited가 false인 칸에서 bfs를 수행한다. 따라서 isVisited는 전역 변수(혹은 call by reference)가 되어야 한다.
bfs로 탐색한 칸은 서로 연합이 가능한 칸이다. bfs 탐색의 조건은 문제에 상세히 적혀있다. 그래프 전체를 순회하며 bfs 탐색을 실시하고 각 칸의 값을 조정하면, 이게 문제에서 말하는 ‘하루’가 지난 것이다. isVisited가 false인 칸만 연합을 수행하므로, 앞선 칸에서 수행한 bfs 탐색이 뒤에 있는 칸에 영향을 끼칠 일은 없다.
1회의 인구 이동이 끝났어도 또 인구 이동이 가능할 수 있다. 따라서 1.을 더 이상 인구이동이 불가능해 질 때까지 수행한다.

코드

import Foundation

func bfs(root: (Int, Int)) -> Bool {
 struct Queue {
 private var queue = [(Int, Int)]()
 private var ptr = 0
 var isEmpty: Bool {
 ptr >= queue.count
 }
 mutating func insert(v: (Int, Int)) {
 queue.append(v)
 }
 mutating func delete() -> (Int, Int) {
 let popped = queue[ptr]
 ptr += 1
 return popped
 }
 }
 let moves = [(-1, 0), (1, 0), (0, -1), (0, 1)]
 var queue = Queue()
 var union: [(Int, Int)] = [root]
 var unionPop = graph[root.0][root.1]
 queue.insert(v: root)
 isVisited[root.0][root.1] = true
 while !queue.isEmpty {
 let node = queue.delete()
 for move in moves {
 let newNode = (node.0 + move.0, node.1 + move.1)
 if newNode.0 < 0 || newNode.0 >= n || newNode.1 < 0 || newNode.1 >= n { continue }
 if isVisited[newNode.0][newNode.1] { continue }
 let differ = abs(graph[node.0][node.1] - graph[newNode.0][newNode.1])
 if differ >= l && differ <= r {
 isVisited[newNode.0][newNode.1] = true
 queue.insert(v: newNode)
 union.append(newNode)
 unionPop += graph[newNode.0][newNode.1]
 }
 }
 }
 let dividedPop = unionPop / union.count
 for element in union {
 graph[element.0][element.1] = dividedPop
 }
 if union.count > 1 {
 return true
 } else {
 return false
 }
}

let nlr = readLine()!.split(separator: " ").map { Int(String($0))! }
let (n, l, r) = (nlr[0], nlr[1], nlr[2])
var graph = [[Int]]()
for _ in 0..<n {
 graph.append(readLine()!.split(separator: " ").map { Int(String($0))! })
}
var isVisited = [[Bool]](repeating: [Bool](repeating: false, count: n), count: n)
var answer = 0

while true {
 var isEnd = true
 for row in 0..<n {
 for column in 0..<n {
 if !isVisited[row][column] && bfs(root: (row, column)){
 isEnd = false
 }
 }
 }
 if isEnd {
 break
 }
 isVisited = [[Bool]](repeating: [Bool](repeating: false, count: n), count: n)
 answer += 1
}
print(answer)

BOJ 14502. 연구소

Wed, 05 Jul 2023 00:00:00 +0000

문제

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

풀이

dfs와 bfs가 합쳐진 문제이다. 벽을 꼭 3개를 세워야 하므로 dfs를 이용하여 벽을 세울 위치를 전체 탐색할 수 있다. 연구소의 크기가 최대 8 * 8 이므로 전체 탐색하는데 큰 문제가 발생하지 않는다.

벽을 세웠으면 bfs를 이용하여 바이러스가 퍼졌을 때의 연구소의 모습을 그린다. 이 때 바이러스가 지나간 자리는 2로 마킹되고, 벽은 바이러스가 지나가지 못하므로 isVisited와 같은 배열이 없어도 이미 지나간 곳임을 알 수 있다.

알고리즘을 순서대로 나타내면 다음과 같다.

BOJ 6087. 레이저 통신

Wed, 05 Jul 2023 00:00:00 +0000

문제

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

풀이

다익스트라 알고리즘을 사용하여 해결하는 문제이다. 각 인접한 노드가 연결되어있다고 생각하고, 전의 노드에서 현재 노드로 온 방향과 수직인 노드만 거리를 1로 설정해주면 된다.

일반적인 다익스트라 알고리즘 문제에서는 연결된 노드간의 거리가 주어지는데, 이 문제에서는 연결된 노드의 거리를 0으로 할지, 1로 할지 선택해야한다. 하지만 다익스트라 알고리즘과 BFS의 관계를 잘 생각해보면, 어렵지 않게 풀 수 있다(개인적으로 BFS는 일종의 다익스트라 특이 케이스라고 생각한다.)

알고리즘은 다음과 같다.

그래프에서 인접한 칸끼리는 서로 연결된 노드라고 가정함 (노드간 거리는 기본적으로 0으로 생각)
현재 있는 칸에서 내가 바라보고 있는 방향을 기준으로 수직인 노드는 거리가 1, 아닌 노드는 0으로 설정
2.를 반복하면서 다익스트라 수행

vertical은 가로 이동 horizontal은 세로 이동 neutral은 중립 방향인데, 시작 지점이나 아래에서 설명할 다른 Direction이지만 같은 거리에 있는 노드가 가지는 방향이다. none은 아직 탐색하지 않은 노드가 가지는 방향이다.

BOJ 1049. 기타줄

Fri, 16 Jun 2023 00:00:00 +0000

문제

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

풀이

6개 묶음 패키지의 가격과 낱개의 가격이 각각 여러 개가 주어졌을 때, 가장 적은 비용으로 n개 이상의 수를 채워야 하는 문제이다.

문제의 알고리즘은 다음과 같다.

패키지의 가격과 낱개의 가격이 같이 들어오므로 현재 가장 싼 패키지와 낱개의 가격과, 입력으로 들어온 가격을 각각 비교해서 갱신한다.
패키지만 샀을때, 낱개만 샀을때, 패키지와 낱개를 동시에 샀을때 세가지 경우를 비교해서 가장 비용이 낮은 값을 출력한다.

이 문제에서 구매 수량에 제한을 두지 않았으므로, 굳이 배열을 만들고 정렬을 할 필요가 없다. 패키지든 낱개든 무조건 가장 싼 가격만 알고 있으면 된다.

BOJ 11000. 강의실 배정

Fri, 16 Jun 2023 00:00:00 +0000

문제

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

풀이

정렬 후 그리디를 수행하는 전형적인 그리디 알고리즘 문제이다.

강의가 시작하는 시간과 끝나는 시간이 주어져 있으므로 배열에 입력으로 주어진 시간들을 저장한 다음에 정렬해서, 강의가 가장 많은 시간의 강의 수를 출력하면 된다.

알고리즘을 글로 표현하면 다음과 같다.

수업이 시작하는 시간과 끝나는 시간을 배열 lecture에 저장한다. 이때 배열은 [(Int, Bool)] 타입이며, Int에는 시간, Bool에는 강의가 시작하는 시간일 경우 true, 끝나는 시간일 경우 false를 저장한다.
배열 lecture를 정렬한다.
lecture를 for 반복문으로 전체 순회한다. 튜플의 두 번째 원소가 true인 경우 현재 진행 중인 강의 수를 저장하는 변수 current의 값을 1 더한다. false인 경우 강의가 끝난 것 이므로 변수 current의 값을 1 뺀다.

이때, 배열 lecture를 시간순으로만 정렬하게 되면 문제에서 다음과 같은 부분 때문에 문제가 생긴다.

Programmers. 하노이의 탑

Wed, 03 May 2023 00:00:00 +0000

문제

https://school.programmers.co.kr/learn/courses/30/lessons/12946

풀이

이런 문제는 문제를 읽었을 때 어떻게 풀어야 할지 감이 잘 잡히지 않는다. 이러한 상황에서는 우선 문제를 시각화 해보자.

좌측은 n = 1일때, 우측은 n = 2일때의 이동을 시각화 한 것이다. 빨간색 숫자는 원판을 뜻하고 파란색 선은 이동루트를 뜻한다. n = 1 일 때는 당연한 이동 경로지만 n = 2일 때는 중간에 있는 기둥을 사용해야한다. 하지만 아직까진 규칙이 뚜렷하게 드러나지 않는다.

n = 3 일때의 이동경로를 시각적으로 나타냈다. 사실 직접 손으로 그리지 않고 다른 사람이 그린 그림으로 봤을 땐 아직도 규칙이 아리송 할 수 있지만 손으로 직접 그렸을 땐 규칙을 바로 알아 챌 수 있다.

BOJ 1753. 최단경로

Sun, 05 Mar 2023 00:00:00 +0000

문제

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

풀이

다익스트라 입문 문제이다. 단, 스위프트로 풀려면 힙을 직접 구현해야 한다.

입력으로 주어지는 엣지의 웨이트가 모두 같다는 조건이 없으므로, BFS가 아닌 다익스트라로 탐색해야 한다.

코드

import Foundation

struct Heap {
 var heap: [(Int, Int)] = []

 func isEmpty() -> Bool {
 return heap.isEmpty ? true : false
 }

 mutating func insert(_ value: (Int, Int)) {
 heap.append(value)
 var currentIndex = heap.count - 1
 while currentIndex > 0 {
 let parentIndex = (currentIndex - 1) / 2
 if heap[currentIndex].1 < heap[parentIndex].1 {
 heap.swapAt(currentIndex, parentIndex)
 currentIndex = parentIndex
 } else {
 break
 }
 }
 }

 mutating func deleteMin() -> (Int, Int) {
 if heap.isEmpty{
 return (0, 0)
 }
 let min = heap[0]
 heap[0] = heap[heap.count - 1]
 heap.removeLast()

 var currentIndex = 0
 while true {
 let leftChildIndex = 2 * currentIndex + 1
 let rightChildIndex = 2 * currentIndex + 2

 if leftChildIndex >= heap.count {
 break
 }
 var minChildIndex = leftChildIndex
 if rightChildIndex < heap.count && heap[rightChildIndex].1 < heap[leftChildIndex].1 {
 minChildIndex = rightChildIndex
 }
 if heap[minChildIndex].1 < heap[currentIndex].1 {
 heap.swapAt(currentIndex, minChildIndex)
 currentIndex = minChildIndex
 } else {
 break
 }
 }
 return min
 }
}

func dijkstra(k: Int) {
 var heap = Heap()
 heap.insert((k, 0))
 distanceTable[k] = 0
 while !heap.isEmpty() {
 let edge = heap.deleteMin()
 if distanceTable[edge.0] < edge.1 {
 continue
 }
 for node in graph[edge.0] {
 let cost = edge.1 + node.1
 if cost < distanceTable[node.0] {
 distanceTable[node.0] = cost
 heap.insert((node.0, cost))
 }
 }
 }
}

let ve = readLine()!.split(separator: " ").map { Int(String($0))! }
let k = Int(readLine()!)!
var graph = [[(Int, Int)]](repeating: [], count: ve[0] + 1)
for _ in 0..<ve[1] {
 let uvw = readLine()!.split(separator: " ").map { Int(String($0))! }
 graph[uvw[0]].append((uvw[1], uvw[2]))
}
var distanceTable = [Int](repeating: 300_001, count: ve[0] + 1)

dijkstra(k: k)

for i in 1...ve[0] {
 if distanceTable[i] == 300_001 {
 print("INF")
 } else {
 print(distanceTable[i])
 }
}

BOJ 14003. 가장 긴 증가하는 부분 수열 5

Wed, 01 Mar 2023 00:00:00 +0000

문제

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

풀이

LIS(Longest Increasing Subsequence)라고 하는 유명한 DP 문제이다. 이 문제 외에도 연계된 문제들이 많으니 1번(BOJ 11053)부터 차례대로 풀면 어느새 여기까지 풀게 된다.

이 문제들은 총 2가지 기준으로 분류된다. 첫 번째 기준은 O(n²), O(nlogn) 두 번째는 LIS 출력 여부이다. 이 중에 O(nlogn) 알고리즘을 사용하고 LIS를 직접 출력해야 하는 문제가 이 문제이다. 원래는 Swift로 작성하려 했지만, 백준의 입력시간 문제 때문에 Swift론 입력 횟수가 적은 O(n²)문제를 풀고 O(nlogn) 문제는 C++로 작성하였다.

기본적인 알고리즘 콘셉트는 다음과 같다.

BOJ 16398. 행성 연결

Sat, 25 Feb 2023 00:00:00 +0000

문제

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

풀이

모든 행성을 연결해야 하고, 그 비용을 최소로 하려면 최소 스패닝 트리(MST)를 찾아야 한다.

따라서 알고리즘의 흐름은 다음과 같아진다.

2차원 배열로 입력받은 플로우 관리비용을 정렬한다.
Kruskal 알고리즘을 이용해 최소 스패닝 트리를 구한다.

여기서 에지(플로우 관리비용)의 정보가 2차원 배열로 입력되므로 배열을 순회하여 (노드, 노드, 비용)꼴의 튜플 배열로 만들어 정렬했다.

2차원 배열의 각 인덱스가 노드를 특정하므로 이렇게 하는 것이 최선이라 생각했다.

코드

func find(_ a: Int) -> Int {
 if parent[a] != a {
 parent[a] = find(parent[a])
 }
 return parent[a]
}

func union(_ a: Int, _ b: Int) {
 let pa = find(a)
 let pb = find(b)
 if pa < pb {
 parent[pb] = pa
 } else {
 parent[pa] = pb
 }
}

import Foundation

let n = Int(readLine()!)!
var graph: [[Int]] = []
var edges: [(Int, Int, Int)] = []
var parent = Array(0..<n)
var answer: Int = 0
for _ in 0..<n {
 graph.append(readLine()!.split(separator: " ").map { Int(String($0))! })
}

for row in 0..<n {
 for column in 0..<row {
 edges.append((row, column, graph[row][column]))
 }
}

edges.sort(by: { $0.2 < $1.2 } )

for edge in edges {
 if find(edge.0) != find(edge.1) {
 union(edge.0, edge.1)
 answer += edge.2
 }
}

print(answer)

BOJ 4195. 친구 네트워크

Thu, 23 Feb 2023 00:00:00 +0000

문제

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

풀이

전형적인 Union-Find 문제이지만, 각 원소들이 정수가 아닌 문자열로 구성되어 있는 특징이 있다. 정수를 문자열로 대응시키는 것은 Dictionary를 쓰면 쉽게 할 수 있으므로 다음과 같은 방식으로 알고리즘이 진행된다

입력값(문자열 2개)에 대해 각 문자열이 Dictionary에 대응되는 Value가 있는지 판단한다.
1에서 없다면 Dictionary에 [String:Integer] 꼴로 매핑한다. 있다면 그냥 넘어간다.
매핑이 끝났다면, 들어온 두 문자열로 union(a, b) 연산을 하고 그 집합 내부의 원소의 개수를 카운트한다.

여기서 문제는 3번이다. 어떻게 해야 효율적으로 집합 내부의 원소를 카운트 할 수 있을까?

BOJ 1726. 로봇

Fri, 18 Nov 2022 00:00:00 +0000

문제

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

풀이

로봇이 바라보는 방향에 따라서 갈 수 있는 노드가 달라진다 -> 3차원 그래프다 (세로 m, 가로 n, 높이가 4인)

이 발상만 빠르게 해낸다면 평범한 BFS 문제가 된다.

하나의 노드에서 최대 5개의 노드와 연결이 가능하다(회전 2방향, 전진 3방향) 하지만 2칸 이상 전진했을때, 앞선 칸이 1이면 넘어가지 못한다. (점프를 할 수 없다)

이것만 주의하고 BFS 탐색을 하면 쉽게 결과를 낼 수 있다.

코드

# east 0 west 1 south 2 north 3
from collections import deque

def bfs(start):
 bfsQ = deque()
 bfsQ.append(start)
 isVisited[start[0]][start[1]][start[2]] = True
 count[start[0]][start[1]][start[2]] = 0

 while(bfsQ):
 node = bfsQ.popleft()
 currentDir = node[2]
 currentCount = count[node[0]][node[1]][node[2]]
 if node == end:
 return currentCount

 for dir in rotate[currentDir]:
 if end == [node[0], node[1], dir]:
 return currentCount + 1
 if isVisited[node[0]][node[1]][dir]:
 continue
 isVisited[node[0]][node[1]][dir] = True
 count[node[0]][node[1]][dir] = currentCount + 1
 bfsQ.append((node[0], node[1], dir))

 if currentDir == 0:
 moves = [(0, 1), (0, 2), (0, 3)]
 elif currentDir == 1:
 moves = [(0, -1), (0, -2), (0, -3)]
 elif currentDir == 2:
 moves = [(1, 0), (2, 0), (3, 0)]
 else:
 moves = [(-1, 0), (-2, 0), (-3, 0)]

 for move in moves:
 row = node[0] + move[0]
 column = node[1] + move[1]
 if end == [row, column, currentDir]:
 return currentCount + 1
 if row < 0 or row >= m or column < 0 or column >= n:
 continue
 if isVisited[row][column][currentDir]:
 continue
 if graph[row][column] == 1:
 break
 isVisited[row][column][currentDir] = True
 count[row][column][currentDir] = currentCount + 1
 bfsQ.append((row, column, currentDir))

graph = []
rotate = {0: [2, 3],
 1: [2, 3],
 2: [0, 1],
 3: [0, 1]}
m, n = map(int, input().split())
for _ in range(m):
 graph.append(list(map(int, input().split())))
start = list(map(int, input().split()))
end = list(map(int, input().split()))

for i in range(3):
 start[i] -= 1
 end[i] -= 1

isVisited = [[[False] * 4 for i in range(n)] for j in range(m)]
count = [[[0] * 4 for i in range(n)] for j in range(m)]
print(bfs(start))

BOJ 3055. 탈출

Thu, 17 Nov 2022 00:00:00 +0000

문제

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

풀이

입력으로 그래프가 주어지고, 어느 칸에서 BFS를 시작해야하는지 알려준다. 문제를 읽어보면 고슴도치와 물 둘 다 BFS 탐색을 해야 하는 것을 알 수 있다.

주의할 점은 예제에는 초기에 물인 칸이 1개밖에 없지만 문제를 읽어보면 1칸이라는 제약조건이 없다. 따라서 물이 여러칸일 때도 생각하고 프로그래밍을 해야 한다.

처음에 두 가지 생각을 했다.

BFS탐색을 각각 따로 하는 방법
- 고슴도치를 먼저 BFS 탐색시켜서 그래프에 각 칸마다 몇번째 이동에 도달하는지 검사한다.
- 다음에 물을 BFS 탐색해서 1의 결과가 가능한지를 판단한다.
고슴도치와 물을 단계별로 번갈아가면서 BFS 탐색 하는 방법

BOJ 7576. 토마토

Thu, 10 Nov 2022 00:00:00 +0000

문제

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

풀이

처음엔 무난한 BFS 문제라고 생각했다. 처음부터 익어있는 토마토(루트 토마토라고 하겠다.)가 들어있는 칸을 알아낸 다음에 반복문으로 BFS를 적용하고, 루트 토마토를 할 때마다 만약 칸에 더 적은 숫자가 들어 갈 수 있다면 숫자를 업데이트 하는 식으로 문제를 풀었다.

그랬더니 시간초과가 나온다. 쓸데없는 연산이 너무 많아서 그렇다.

정확한 풀이는 BFS 큐를 처음 만들때부터 모든 루트 토마토를 넣어서 초기화 하는 것이었다. 그러면 모든 루트 토마토를 기준으로 동시에 탐색할 수 있으니까.

칸을 탐색할때도 더 높은 숫자가 나오면 그 칸은 큐에 넣을 필요가 없다. 이미 전에 했던 탐색이 더 좋은 결과를 가져다 주었을태니

BOJ 1697. 숨바꼭질

Mon, 07 Nov 2022 00:00:00 +0000

문제

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

풀이

입력으로 수빈이와 동생의 위치, 그리고 수빈이가 이동할 수 있는 제약조건을 알려준다.

수빈이의 위치보다 동생의 위치가 더 앞에 있거나 같을때는 (n >= k) 뒤로 가는 방법이 한칸 이동하는 것 밖에 없으므로 n - k 로 쉽게 결과를 도출 할 수 있다.

그 외의 경우에는 각각의 좌표를 노드라고 생각했을 때, 이 그래프는 각 노드가 노드값이 1만큼 크거나 작은 노드와 2배인 노드와 연결되어 있다.

따라서 BFS를 이용하면 쉽게 해결 할 수 있다.

BOJ 2331. 반복 수열

Mon, 07 Nov 2022 00:00:00 +0000

문제

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

풀이

수열을 만드는 반복문을 만든다.
도중에 기존에 있는 원소와 같은 원소가 나오면 반복문을 종료한다.
처음으로 나온 같은 원소의 인덱스를 출력한다. (인덱스는 0부터 시작이기에 더하고 뺄 필요가 없다.)

너무 간단하게 풀렸는데 시간복잡도가 별로 좋아보이진 않는다. 더 좋은 방법이 있을듯 싶다.

코드

a, p = map(int, input().split())
seq = [a]

while True:
 element = 0
 for i in str(seq[-1]):
 element += (int(i) ** p)
 if element in seq:
 break
 seq.append(element)

print(seq.index(element))

BOJ 2667. 단지 번호 붙이기

Mon, 07 Nov 2022 00:00:00 +0000

문제

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

풀이

그래프가 입력으로 주어지고, 각 노드마다 탐색의 범위가 상하좌우로 제한된다. 앞서 해결했던 미로 탐색과 순열 사이클을 섞어놓은 듯 한 문제이다.

따라서 다음과 같은 과정으로 출력값을 얻었다.

전체 그래프를 탐색하는 2중 반복문을 작성한다.
방문하지 않은 노드가 나올 때마다 그래프 탐색(DFS, BFS)를 실시한다.
각 그래프를 탐색했을때 노드의 개수를 저장하고 정렬한 다음에 출력한다.

코드

from collections import deque

def bfs(v):
 bfsQ = deque()
 bfsQ.append(v)
 isVisited[v[0]][v[1]] = True
 moves = [(1, 0), (-1, 0), (0, 1), (0, -1)]
 count = 1
 while bfsQ:
 node = bfsQ.popleft()
 for move in moves:
 row = node[0] + move[0]
 column = node[1] + move[1]
 if row < 0 or row >= n or column < 0 or column >= n:
 continue
 if graph[row][column] != 0 and not isVisited[row][column]:
 isVisited[row][column] = True
 bfsQ.append((row, column))
 count += 1
 return count

n = int(input())
graph = []
for _ in range(n):
 temp = input()
 graph.append(list(map(int, temp)))

isVisited = [[False] * n for i in range(n)]
area = []
for row in range(n):
 for column in range(n):
 if graph[row][column] == 1 and not isVisited[row][column]:
 area.append(bfs((row, column)))
area.sort()
print(len(area))
for i in range(len(area)):
 print(area[i])

BOJ 10451. 순열 사이클

Sun, 06 Nov 2022 00:00:00 +0000

문제

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

풀이

순열이 각각의 (1부터 시작하는)인덱스와 매칭되어있는 그래프를 만들면 쉽게 해결된다. (친절하게 문제에 그림도 있다.)

순열과 인덱스는 내부 원소들이 순서를 제외하고 같으므로 무조건 내부에 사이클을 형성하게 된다.

따라서 문제에서 주어진 그대로 우리는 서로 가르키는 방향을 재귀로 따라가고, 이미 방문한 숫자가 나온다면 재귀를 종료시키기를 반복해서 생기는 사이클의 총 개수를 카운트 하기만 하면 된다.

코드

def dfs(v, start):
 isVisited[v] = True
 if not isVisited[permutation[v - 1]]:
 dfs(permutation[v - 1], start)

n = []
per = []
t = int(input())
for _ in range(t):
 n_temp = int(input())
 per_temp = list(map(int, input().split()))
 n.append(n_temp)
 per.append(per_temp)

for case in range(t):
 count = 0
 isVisited = [False] * (n[case] + 1)
 permutation = per[case]
 for i in range(1, n[case] + 1):
 if not isVisited[i]:
 dfs(i, i)
 count += 1
 print(count)

굳이 재귀를 쓰지 않더라도 반복문만으로도 깔끔한 코드가 나올것 같다.

BOJ 1260. dfs와 bfs

Sun, 06 Nov 2022 00:00:00 +0000

문제

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

풀이

심플하다. 입력값으로 그래프가 주어지고, DFS와 BFS를 이용해 탐색한 결과를 각각 출력하면 된다.

코드

from collections import deque

def dfs(v, dfsArray):
 isVisitedDFS[v] = True
 dfsArray.append(v)
 for i in range(len(graph[v])):
 if graph[v][i] != 0 and isVisitedDFS[i] == False:
 dfs(i, dfsArray)

def bfs(v, bfsArray):
 QueueBFS = deque()
 isVisitedBFS[v] = True
 QueueBFS.append(v)
 while len(QueueBFS) != 0:
 node = QueueBFS.popleft()
 bfsArray.append(node)
 for i in range(len(graph[node])):
 if graph[node][i] != 0 and not isVisitedBFS[i]
 QueueBFS.append(i)
 isVisitedBFS[i] = True

n, m, v = map(int, input().split())
graph = [[0] * (n + 1) for i in range(n + 1)]
isVisitedDFS = [False for i in range(n + 1)]
isVisitedBFS = [False for i in range(n + 1)]
dfsArray = []
bfsArray = []

for i in range(m):
 a, b = map(int, input().split())
 graph[a][b] = graph[b][a] = 1

dfs(v, dfsArray)
bfs(v, bfsArray)

for node in dfsArray:
 print(node, end=" ")
print()
for node in bfsArray:
 print(node, end=" ")
print()

BOJ 2178. 미로 탐색

Sun, 06 Nov 2022 00:00:00 +0000

문제

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

풀이

입력값으로 미로의 크기와 구성이 주어진다.

미로 안에서는 값이 1인 칸으로만 이동 할 수 있고, 또 각 칸에서는 상하좌우의 칸으로밖에 이동하지 못한다.

-> 현재 칸에서 상하좌우의 칸을 탐색해서 1인 경우에만 Queue에 넣는다.

이 문제에서는 각 노드를 방문했는지의 여부보다 몇번째에 방문했는지의 여부가 더 중요하다.

-> 이전 노드의 방문 순서에 1을 더한 값을 현재 노드의 방문 순서로 한다. (isVisited가 Bool이 아닌 Integer로 구현된다)

이렇게 얻어낸 두가지 인사이트로 BFS를 구현한다.

코드

from collections import deque

def bfs(location):
 visit = [[0] * m for _ in range(n)]
 bfsQ = deque()
 bfsQ.append(location)
 visit[0][0] = 1
 while bfsQ:
 node = bfsQ.popleft()
 up = [node[0] - 1, node[1]]
 down = [node[0] + 1, node[1]]
 left = [node[0], node[1] - 1]
 right = [node[0], node[1] + 1]
 moves = [up, down, left, right]
 for i in range(len(moves)):
 x = moves[i][0]
 y = moves[i][1]
 if x < 0 or y < 0 or x >= n or y >= m:
 continue
 if maze[x][y] == "0":
 continue
 if visit[x][y] == 0:
 visit[x][y] = visit[node[0]][node[1]] + 1
 bfsQ.append([x, y])
 return visit[n - 1][m - 1]

maze = []
n, m = map(int, input().split())
for i in range(n):
 temp = list(input())
 maze.append(temp)
print(bfs([0, 0]))

시작 노드와 종료 노드가 명확하게 정해져 있으므로 DFS로도 풀릴것이라는 생각이 든다.

About

Mon, 01 Jan 0001 00:00:00 +0000

Personal development blog.

Kelly Dev

StackDay. 0. Concept

시작하기

dev-data-server-light. 0. Concept

시작하기

JavaScript Basics. 01. 자바스크립트 기본 환경 설치 및 기본 문법

환경 설치

자바스크립트란?

컴파일러 언어와 인터프리터 언어

기반 환경 구축하기

The Swift Programming Language. Functions (1)

Functions

StackDay. 엔티티와 계산 책임 분리하기

Completion

StackDay. 데이터 모델링, Entry가 아닌 Completion을 관리해야 하는 이유

앱의 핵심 동작

dev-data-server-light. 1. System

System 모듈의 기능

구조 검증

JavaScript Basics. 02. 연산자와 명령문

기본 명령어

표현식

프로그램

예악어

The Swift Programming Language. Functions (2)

Function Argument Labels and Parameter Names

dev-data-server-light. 2. Database CRUD

CRUD부터 만들기

JavaScript Basics. 03. 자바스크립트 사용자 정의 자료형 활용

조건문

if 조건문

if else 조건문

중첩 조건문

if else if 조건문

The Swift Programming Language. Functions (3)

Function Types

dev-data-server-light. 3. Database Implementation

인 메모리 데이터 저장소

구현하기

JavaScript Basics. 04. 자바스크립트 함수

함수 생성 방법

익명 함수

선언적 함수

화살표 함수

The Swift Programming Language. Closures (1)

Closures

dev-data-server-light. 4. File Storage

인터페이스 만들기

JavaScript Basics. 05. 자바스크립트 내장 객체

객체

배열

객체 기본

객체와 반복문

메소드

The Swift Programming Language. Closures (2)

Capturing Values

devbox-light-server (5). Auth

Auth 설계하기

최소한의 Auth 구조

JavaScript Basics. 06. 브라우저 및 문서 객체

브라우저 객체 모델

window 객체

screen 객체

The Swift Programming Language. Closures (3)

Escaping Closures

devbox-light-server (6). Json 영속성

JavaScript Basics. 07. 자바스크립트 예외처리 및 이벤트 처리

예외 처리

예외와 기본 예외 처리

고급 예외 처리

예외 객체

The Swift Programming Language. Enumerations (1)

Enumerations

Enumeration Syntax

devbox-light-server (7). Dockerizing, MVP 마무리

도커라이징

Dockerfile 작성하기

JavaScript Basics. 08. 자바스크립트 API 활용 및 그림판 프로그램 만들기

API 활용

클라이언트 측 고유 기술 요소

`window` 객체

`screen` 객체