Today I Learned on Kelly Dev

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이 결정하도록 분리했다. 전체 설계와 구현 코드는 개발일지에 정리했다.

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를 상속한다.

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)은 현재 정책에서 해당 날짜의 기록을 찾는 조건으로 분리했다. 없는 기록 취소를 성공으로 넘기지 않은 이유까지 개발일지에 정리했다.

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는 조건문이나 루프같은 제어 흐름도 동기 코드와 비슷하게 사용하게 해준다.

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에 뒀다. 자세한 고민은 개발일지에 정리했다.

TIL. Aug 13, 2026

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

오늘 한 내용

배운 내용

StackDay 통계 계산

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

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

TIL. Aug 12, 2026

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

오늘 한 내용

배운 내용

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

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

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

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

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

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을 따로 나누기보다 현재 차례의 플레이어 기준으로 생각하는 편이 자연스럽다.

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를 마무리하려면 실제로 재시작해도 데이터가 남는 저장 방식이 필요했다.

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

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에 넣기보다, 에이전트가 현재 작업에 필요한 컨텍스트만 읽을 수 있도록 성격과 범위에 따라 나누는 편이 낫다.

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

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 로직 안에 인라인으로 쓰면 되지 않나 라는 생각이 들었다.

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 벡터로 문제를 풀었다.

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씩 감소시키는 경우를 분리해 처리했다.

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만 주로 사용하다 보니 이 부분을 자주 놓치는 것 같다.

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이나 테스트 코드도 마찬가지다.

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에 뭔가 내용을 수정하는 훅을 넣으면, 커밋이 멈추지 않고. 변경사항을 유지한채로 커밋되어버린다.

TIL. Jul 28, 2026

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

오늘 한 내용

배운 내용

C++ 배열 vs 벡터

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

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

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도 마찬가지고 엄청나게 반복되는 내용이다.)

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자리수의 경우의 수가 되는데, 비트연산은 더 이상 자리수의 확장이 일어나지 않는다.

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 의존이 꽤 심해졌는데, 다양하게 풀어봐야겠다.

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같은 느낌인가.

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로 빌드 검증

배운 내용

Mermaid 코드 블록은 layouts/_markup/render-codeblock-mermaid.html에서 <pre class="mermaid">로 변환하고, layouts/_partials/extend_footer.html에서 Mermaid가 포함된 페이지에만 스크립트를 삽입하도록 구성했다.

처음에는 ESM 파일 하나만 static/에 복사했지만, 해당 파일이 내부 chunk를 추가로 참조하는 구조라 렌더링이 깨졌다. 브라우저가 다이어그램을 SVG로 바꾸지 못하고 원문 텍스트처럼 보여서, 의존성이 단순한 mermaid.min.js로 교체했다.

외부 CDN을 제거하는 작업도 단순히 파일을 내려받는 것으로 끝나지 않았다. 번들 파일의 의존성과 실행 방식까지 확인해야 실제 정적 사이트에서 안정적으로 동작한다는 것을 배웠다.

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를 이용해서 큐를 만들면 되지만, 이게 힙와 다익스트라를 쓰는 것보다 코드를 작성하는 입장에서 효율적일지는 잘 모르겠다.

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를 구성하는 핵심 요소는 크게 다음과 같다.