텍스트 기반 검색을 공부하다 보면 유독 Trie라는 자료구조를 자주 만나게 된다. 특히 문자열 검색, 자동완성, 사전 검색 같은 기능에서 Trie는 빠지지 않는다.RedisSearch나 ElasticSearch 같은 대형 검색 엔진에서도 term lookup, prefix matching 최적화에 Trie를 활용하고 있다고 한다.서비스/엔진Trie 활용 방식Redis Stack / RediSearchautocomplete suggestion을 trie 기반 자료구조에 저장. prefix 입력에 대한 추천어 검색에 사용Elasticsearch / Apache Lucene전문 검색은 기본적으로 inverted index 기반이지만, term dictionary나 prefix 탐색에 FST 같은 Trie 계열..

개발을 하다 보면 반복해서 수행하는 작업이 생깁니다. 변경 사항을 확인하고, 브랜치를 만들고, 커밋 메시지를 정리한 뒤, 원격 저장소에 푸시하고 PR까지 생성하는 흐름도 그중 하나입니다. 이런 반복 작업을 매번 자연어로 길게 설명하는 대신, Codex가 일정한 규칙에 따라 수행하도록 만들 수 있는 방법이 Skill입니다.이 글에서는 제가 실제로 등록한 bcpprm Skill을 사례로 삼아, Codex에 새로운 Skill을 등록하는 전체 과정을 정리합니다. 이후 다른 자동화 Skill을 만들 때에도 그대로 참고할 수 있도록 기록합니다.예시로 사용하는 bcpprm는 Branch → Commit → Push → Pull Request 흐름을 지원하도록 만든 Skill입니다.먼저 결정할 것: Skill인가, P..

알림 시스템에서 가장 먼저 마주하는 문제는 “알림이라는 작업을 어떻게 생성하고 누구에게 전달할 것인가”이다. 특히 하나의 이벤트가 수백만 명에게 전달되어야 하는 상황에서는 단순한 구현으로는 감당할 수 없는 부하가 발생한다. 이에 각 도메인 서비스에서 직접 알림 메시지를 생성하여 처리하기보다 알림 담당 도메인을 두고 event-driven 모델로 통신하는 구조가 적합하다. 이처럼 생성과 전달 책임을 분리하기 위해서 알림은 독립적인 이벤트 형태로 정의할 필요가 있다. 다음으로 고민해야 할 것은 이 이벤트를 어떻게 사용자에게 안정적으로 분배할 지이다. 알림 기능은 대부분 유저 인터렉션을 위한 후속 작업의 성격으로 이용가능한 자원이 제한적이고 알림 이벤트 각각은 서로 독립적이다. 따라서 작업을 최대한 균등하게 ..

대규모 서비스 아키텍처의 주된 관심사는 확장성과 병목 관리라 해도 과언이 아니다. 이와 관련된 트레이드오프나 문제 상황을 경험해보고 핸들할 수 있는 판단력을 갖추는 것이 요즘 시대에 가장 필요한 개발 역량이 아닌가 싶다. 규모가 크지 않은 서비스라도 이와 비슷한 문제 상황을 자연스럽게 고민하게 되는 도메인이 있는데 개인적으로 알림 도메인이라고 생각한다. 어느정도 반복되는 구조를 답습하는 대부분의 도메인과 다르게 각자 서비스 성격에 따라 효율적인 시스템 디자인을 간접적으로 고민해 볼 수 있는 가장 현실적이고 자유도 높은 도메인이 아닐까한다. 기본적으로 알림은 서비스가 유저에게 먼저 request를 보내는 거의 유일한 상호작용이다. 개발자이기 이전에 사용자로서 그동안 수많은 애플리케이션의 알림을 경험하며 귀..

상태 관리 라이브러리앱에는 고정된 데이터와 변경되는 데이터가 존재한다. 앱의 주된 사용 목적 중 대부분은 변경되는 데이터의 조회로 이 데이터를 어떻게 관리하고 표현하는지가 앱의 성능, 사용성에 큰 영향을 미친다. 상태 관리 라이브러리는 변경되는 데이터를 클래스 내부에서 관리하고 위젯에 담아 화면에 출력하는 클래스간 데이터 흐름을 총괄한다. 상태 관리 라이브러리로는 대표적으로 Provider, Bloc, Riverpod, GetX가 존재한다. GetX는 이제 거의 안 쓰이고, Provider는 일전에 설명한 관계로 Bloc, Riverpod 두 라이브러리를 중심으로 설명한다.BlocBusiness Logic Componentimperative (명령형) : 외부 자극을 단일 경로를 따라 내부 상태 변화로 ..

개발환경 세팅과 플러터 핵심 개념 학습을 어느정도 완료했으니 이를 토대로 플러터 프로젝트를 생성해보자. AI와의 채팅을 통해 갈등 관리 기능을 제공하는 간단한 채팅 앱 conflicAI을 만들기로 했다. VScode를 사용한다.플러터 프로젝트 생성모바일 앱이므로 웹이나 데스크톱 전용 패키지를 따로 세팅하지 않도록 --platforms로 iOS와 Android를 설정하고 --org로 프로젝트 담당 조직(추후 앱의 식별자에 포함)을 명시해서 프로젝트를 생성한다. 이때 프로젝트 이름은 snake_case로 설정해야 한다.flutter create --platforms ios,android --org com.cusum26 conflic_ai create 명령어로 프로젝트를 생성하면 다음과 같은 파일 구조가 만들..

본격적인 프로젝트 개발에 앞서 플러터의 필수 개념에 대해 알아보자. 플러터 아키텍쳐 플러터 프로젝트의 구조를 나름 비유하자면 다음과 같다. 무한하게 상상할 수 있는 Framework가 특정 규칙에 따라 상상력을 전기적 신호로 표현할 수 있는 Engine이라는 뇌로 실체화되고, Embedder를 통해 Native까지 전달된 뇌의 전기적 신호가 실제 물리적 움직임으로 구체화된다... 추상화된 하나의 뇌로 네이티브라는 서로 천차만별인 신체를 적절하게 제어하기 위해서는 뇌의 신경이 각 신체 전용 제어 구조로 연결돼야 한다. 이때 Embedder가 각 몸뚱아리 전용 제어 틀을 이 추상화된 뇌에게 제공하는 역할을 한다. Embedder 플러터로 만든 앱이 기기에서 실행되려면 각 네이티브 환경의 인터페이스 규칙을 ..

개발 환경 세팅플러터 설치 (macOS 기준)(1) 터미널로 설치하는 방법1. 터미널 앱에서 다음 명령어로 플러터 sdk 설치 (brew는 이미 설치 완료 가정)brew install --cask flutter 2. flutter 명령어 사용을 위한 PATH 추가 (.zshrc 파일에 sdk가 설치된 경로를 등록)수동으로 설정한 디렉토리에 다운로드 했다면 "which flutter" 명령어로 sdk 설치된 경로 확인 가능echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrcsource ~/.zshrc 3. 설치 확인flutter --version 4. 적용 확인flutter doctorDoctor summary (to see all details, run f..

도커 환경에서의 Kafka UI 설정알림 기능이 제대로 동작하는 지 검증하기 앞서 Kafka 브로커가 설계한 대로 작동하는 지 Kafka UI를 통해 확인해보자. Kafka UI는 Kafka 브로커에 저장된 메시지와 메타데이터를 조회해 시각적으로 표현하는 HTTP 기반의 외부 웹 UI 도구이다. 일반적으로 Docker 컨테이너로 배포되며 브라우저를 통해 Kafka 브로커의 운영 및 모니터링 환경을 제공한다. 다음의 Docker 설정을 통해 브라우저 접속 환경을 구성할 수 있다.kafka-ui: image: provectuslabs/kafka-ui:latest container_name: kafka-ui ports: - "8085:8080" # 호스트의 브라우저는 8085로 접속 가능 env..

도커 환경에서의 Kafka 설정Kafka의 로그 서버는 스프링 애플리케이션과 분리된 외부 브로커로 동작하며, 프로듀서와 컨슈머 클라이언트를 통해 애플리케이션과 통신한다. 따라서 일반적으로 도커 컨테이너나 별도의 서버 환경에서 운영된다. 여기서는 Kafka를 도커 컨테이너 안에서 실행하는 방식으로 설계했다. 스프링 애플리케이션은 로컬 환경에서는 IDE에서, 배포 환경에서는 도커 컨테이너 안에서 실행되므로 어느 환경에서 접속하더라도 도커 내부의 Kafka 브로커를 정확히 식별해 연결해야 한다. 이를 위해 Kafka는 도커 환경에서 포트를 2개 열어 두고, 각각에 리스너를 설정하여 두 가지 방식으로 접근하는 클라이언트와 모두 통신할 수 있도록 구성한다. 도커 내부에서는 클라이언트끼리 직접 연결 가능하므로 외부..