[운영 확장 11·부록] 환자 포털과 모바일 채널은 예약을 어떻게 보여 주는가 환자 포털의 예약 현황·알림·내 정보 화면, ETag와 멱등 키를 사용하는 예약 관련 작업, SSE와 polling 대체 경로, 모바일 채널의 열린 로드맵을 한 글에서 구분합니다.
블로그
글 목록
섹션 제목: “글 목록” 117개 글
인기 태그 전체 Kotlin 86 실전 예제 42 Architecture 40 복원력 37 Timefold 31 예약서비스 30 예제 30 Spring 29 Exposed 24 Persistence 21 Performance 17 Event Driven 15
전체 태그
관측성 8 동시성 12 멀티테넌시 5 메시징 7 멱등성 3 보안 3 복원력 37 비교·선택 13 실전 예제 42 예약서비스 30 예제 30 테스트 11 트랜잭션 5 AI 5 Architecture 40 AWS 8 Barcode 1 Billing 4 BOM 5 Cache 9 Coroutines 13 DATA Isolation 1 DDD 1 Dependencies 12 Domain Modeling 12 Ecosystem 11 Event Driven 15 Exposed 24 Fulfillment 1 Golang 1 Graph 7 Image 10 JaVers 7 JDBC 6 Kafka 5 Kotlin 86 Ktor 14 Leader Election 9 Microservices 2 Migration 4 Mobile 1 Moderation 1 Notification 2 OCR 2 Operations 12 Optimization 6 Outbox 4 Patient Portal 1 Performance 17 Persistence 21 PostgreSQL 7 R2DBC 7 Redis 9 Release Train 2 Reliability 2 Reminder 1 Search 7 Spring 29 Statistics 1 Text 9 Timefold 31 Virtual Threads 9
[운영 확장 10] 최신 계산 결과만 예약에 적용한다 계산 시점의 원본 버전과 적용 시점의 원본 버전을 비교해 오래된 결과를 막고, 정책·알림 작업의 재시도와 관측 경계를 STAFF 화면으로 설명합니다.
[운영 확장 9] 재시도와 replay가 있어도 예약은 한 번만 바꾼다 재시도와 replay가 예약을 두 번 변경하지 않도록 HTTP idempotency key, 아웃박스(outbox), inbox, quarantine과 STAFF 조치 큐를 하나의 결과 결정으로 연결합니다.
[운영 확장 8] 여러 병원을 한 예약 서비스로 운영할 때 지켜야 할 데이터 경계 tenant·clinic 범위를 요청 경로에서 조회·캐시·이벤트까지 전달하고, STAFF가 범위 경고와 다음 작업을 판단하는 운영 경계를 설명합니다.
[운영 확장 7] 예약 결과가 외부 시스템과 통계로 전달되는 과정 예약 결과를 외부 시스템과 통계에 전달할 때 아웃박스, consumer inbox, 통계 projection, 현재 예약 집계의 책임 경계를 STAFF 화면과 함께 설명합니다.
[운영 확장 6] 알림과 리마인더는 왜 별도 서비스인가 예약 확정 트랜잭션과 알림 발송을 분리하고, 리마인더 누락을 복구하면서도 STAFF에게 필요한 다음 작업만 보여 주는 경계를 설명합니다.
[운영 확장 5] 내원 확인과 시술 완료는 다른 사실이다 내원 확인과 예약 종료가 실제 시술 완료를 뜻하지 않는 이유를 STAFF 운영 화면과 상태·이벤트 흐름으로 설명합니다.
[운영 확장 4] CRM 프로필이 바뀌어도 확정 예약은 자동으로 변경하지 않는다 CRM 프로필 변경을 예약 재평가의 이유로만 사용하고, PROPOSED·HELD와 CONFIRMED의 상태 변경 경계를 STAFF 운영 화면으로 설명합니다.
[운영 확장 3] 예약 복구는 영향 범위 확인부터 시작한다 병원 사정으로 예약을 바꿔야 할 때 영향을 받은 예약을 찾고, 대체 후보를 계산하고, 현재 버전을 다시 확인한 뒤 STAFF가 변경을 확정하는 과정을 설명합니다.
[구현 9] 패키지 상품의 실행 순서와 선택 조건을 방문 계획에 담는 과정 패키지 선택 결과와 실행 조건을 검증하고, 이벤트 순서가 뒤섞이거나 저장이 중단되어도 실행 계약을 안전하게 보존하는 방법을 설명합니다.
[구현 8] N회 상품 구매로 방문 계획을 만드는 과정 반복 상품의 구매 권리를 회차별 방문 계획으로 전개하고, 완료·환불·간격 제약을 변경 이력으로 관리하는 방법을 살펴봅니다.
[설계 7] 병원마다 예약 규칙이 다른 이유 병원마다 다른 예약 결과를 설명하는 정책 상속, 재정의, 버전, 활성화 경계를 살펴봅니다.
[운영 확장 1.3] 대기 목록 운영 명령은 API 요청과 재조회로 완성된다 운영 화면의 확정·거절 버튼이 범위·버전·멱등성·재조회 계약으로 이어지는 흐름을 설명합니다.
[운영 확장 1.2] 대기 목록 운영 화면은 상태판이 아니라 조치판이다 대기 목록을 상태 목록으로 끝내지 않고, 병원 지표·조치 큐·근거·허용된 명령으로 연결하는 운영 화면을 설명합니다.
[운영 확장 1.1] 대기 목록은 이름표가 아니라 상태 머신이다 대기 후보를 단순한 이름 목록으로 보지 않고, 빈시간 하나를 제안·보류(hold)·수락(claim)·복구하는 상태 머신으로 설계합니다.
[운영 확장 2] 예약 우선순위는 누구의 규칙인가 노쇼 이력과 VIP 우선 신호를 예약 서비스에 반영하되, 정책 소유권과 기존 예약 보호를 분리하는 설계를 설명합니다.
[설계 6] 고객 희망 내원 날짜는 예약 확정이 아니다 희망 일정과 예약 확정을 분리하고, PROPOSED·HELD·CONFIRMED 상태와 변경 동의 경계를 기존 예약을 보호하도록 설계하는 방법을 설명합니다.
[설계 5] 상품 BOM은 어떻게 AppointmentPlan과 방문 계획으로 이어지는가 패키지 구매가 예약 계획과 실제 방문으로 이어지는 두 단계와 상품·예약·임상 서비스의 책임 경계를 설명합니다.
[설계 4] 패키지 상품은 왜 실행 그래프가 되는가 패키지의 구성 상품, 선택 규칙, 선후행 관계가 환자의 여러 방문과 실제 예약 항목으로 이어지는 경계를 설명합니다.
[설계 3] N회 상품은 왜 예약 한 건이 아닌가 여러 회차를 구매한 사실과 한 번씩 확정되는 예약을 분리하고, 실제 완료 뒤 잔여 이행 의무를 계산하는 방법을 설명합니다.
[설계 2] 이벤트 상품은 어떤 예약을 만드는가 이벤트 상품을 산 사실이 어떻게 후보 시간과 고객 동의를 거쳐 확정 예약이 되는지 설명합니다.
[설계 1] 상품이 바뀌어도 고객의 예약은 변경하지 않는다: 상품 버전과 구매 기준 정보 상품 변경이 기존 환자의 예약을 다시 해석하지 않도록 구매 기준 정보와 Plan 리비전의 경계를 환자 A 사례로 설명합니다.
[프롤로그] 상품 정보가 고객의 예약이 되기까지 이벤트·N회·패키지 상품이 고객의 예약이 되고, 내원과 상담의 객관적 사실로 이어지는 전체 흐름을 그립니다.
OCR과 다른 바코드·QR 추출 계약: 값·형식·위치를 보존하는 provider 경계 바코드·QR의 값과 형식, 선택적인 위치 정보를 provider-neutral 계약으로 보존하고 OCR·정책과 분리합니다.
이미지 검출 결과와 처리 정책을 분리하라: 사실·조치·검토의 경계 검출기가 보고한 사실과 방문증 업무 정책을 분리해 오탐·미탐과 수동 검토 경계를 보존합니다.
OCR 결과를 통합 응답에 연결하기: 빈 결과·사용 불가·실패를 구분하는 계약 OCR 공급자의 빈 결과, 사용 불가, 타임아웃과 예외를 구분하고 객체 검출·바코드 결과를 잃지 않는 통합 응답 계약을 살펴봅니다.
사용량 과금 Part 4: 장애 탐지, 격리, 재처리와 정합성 검증 장애 신호 수집, 영향 범위 식별, 실패 분류, 격리, 재처리와 정합성 검증을 하나의 과금 복구 Runbook으로 정리합니다.
사용량 과금 Part 3: 마이크로서비스, Outbox와 Inbox 서비스별 데이터 소유권, 로컬 트랜잭션과 Outbox, Inbox 중복 판정, 순서 역전과 Poison Event 복구를 하나의 과금 흐름으로 살펴봅니다.
사용량 과금 Part 2: Event Sourcing, Replay와 Projection 운영 Event Store를 과금의 기준 데이터로 삼을 때 필요한 재생, 스키마 진화, 프로젝션 세대 전환과 실패 격리를 살펴봅니다.
사용량 과금 Part 1: 중복 수집부터 재시작 가능한 마감과 원장까지 중복 사용량, 가격 변경, 마감 재시작, 늦은 사용량을 하나의 PostgreSQL 기준 데이터 모델에서 다루는 방법을 살펴봅니다.
이미지 분석 전에 입력부터 판정하라: 공통 자격 판정과 단일 디코딩 여러 이미지 분석기가 함께 쓰는 입력 자격 판정, 크기·픽셀 예산, 실제 파일 형식 확인, 단일 디코딩 경계를 구현과 테스트로 살펴봅니다.
이미지 한 장에서 여러 정보를 추출하는 API: OCR·객체 검출·QR 처리의 경계 한 이미지에 포함된 텍스트, 객체 영역, QR 값을 각각 읽고 부분 실패를 보존한 뒤 업무 정책으로 연결하는 API 경계를 살펴봅니다.
Spring WebFlux 멀티테넌시: Reactor Context 전파에서 테넌트 온보딩까지 요청의 테넌트 정보를 코루틴과 DB 선택까지 안전하게 전달하고, 권한 검증·영속 생명주기·신규 테넌트 온보딩을 같은 운영 계약으로 묶습니다.
같은 애플리케이션 안의 이벤트 전달: Spring Modulith 발행 기록과 아웃박스를 나누는 기준 같은 애플리케이션 안의 리스너 복구와 외부 이벤트 전달을 같은 아웃박스 문제로 섞지 않는 기준을 정리합니다.
Bluetape4k JaVers Part 4: 감사 로그는 공짜가 아니다 감사 범위, 스냅숏 저장 비용, 커밋 메타데이터 인덱스를 커밋된 벤치마크 근거로 판단한다.
[구현 7] 완성 뒤가 진짜 시작이다 리뷰 지적과 운영 증거를 다음 요구사항으로 되돌려 보내며 예약 SaaS를 계속 진화시키는 방법을 정리합니다.
Timefold Server 실전 적용: 계획 모델에서 Exposed 영속화 경계까지 병상 배정과 학교 시간표는 같은 Timefold를 쓰지만 계획 변수와 점수 구조가 다릅니다. 빠른 시작 예제의 Solver 실행을 실제 서비스의 저장·승인·업무 반영으로 확장할 때 필요한 경계를 살펴봅니다.
[구현 6] 휴진과 장비 고장은 예약 설계를 어떻게 바꾸는가 휴진과 장비 고장을 상태 전이, 후보 생성, 승인, 감사 이력과 알림으로 이어지는 재배정 업무 흐름으로 설계합니다.
여러 서버가 같은 작업을 실행하지 않게 만드는 방법 테넌트별 집계는 병렬성을 살리고 마이그레이션은 전역으로 막아야 합니다. 실제 예제로 리더 선출의 범위와 실패 경계를 정합니다.
예약 요청이 몰려도 수량 한도를 넘지 않는 방법 동시 요청, 재시도, 임시 예약 만료, 대기 목록, Redis 장애가 겹쳐도 예약 수량 한도를 지키는 경계를 코드와 테스트로 확인합니다.
[구현 5] 병원 업무 규칙을 Timefold 제약으로 모델링하기 병원의 필수 업무 규칙과 운영 선호를 12개 필수 제약과 6개 선호 제약, HardSoftScore로 모델링하는 과정을 살펴봅니다.
[구현 4] 한 건의 예약 가능 시간 조회와 전체 일정 최적화는 다르다 한 건의 예약 가능 시간 조회와 여러 예약의 전체 일정 최적화가 왜 다른 문제인지, Timefold Solver를 어디에 적용할지 살펴봅니다.
[구현 3] 병원마다 다른 업무시간과 자원으로 예약 가능 시간을 계산하기 병원과 의사의 시간표를 겹치고, 운영 중단과 자원 제약을 차례로 적용해 실제 예약 가능 시간을 계산합니다.
[구현 2] 예약 상태는 열거형이 아니다 현재 상태만 저장해서는 알 수 없는 허용된 변화, 변경 사유, 변경 이력을 하나의 계약으로 묶습니다.
[구현 1] 병원 예약은 CRUD로 끝나지 않는다 요구사항부터 모듈 경계까지, 예약 한 건 뒤에 숨어 있는 병원 업무 규칙을 따라갑니다.
Bluetape Skills Part 3: 중단된 작업 흐름을 안전하게 복구하는 방법 1.1.0 런타임이 중단된 실행 단위를 판별하고 작업 원장과 구성 요소별 증거를 바탕으로 작업 흐름을 복구하는 과정을 설명합니다.
Bluetape Skills Part 2: bluetape-workflow로 작업을 시작하는 방법 작업 분류부터 계획 승인, 세부 스킬, 단계별 증거와 최종 완료 조건까지 bluetape-workflow의 실제 실행 절차를 설명합니다.
Bluetape Skills Part 1: 팀과 공유하고 설치하는 방법 정식 스킬과 참조 자료, 설치 검증, 개인 런타임 경계를 갖춘 Bluetape Skills 배포 방식을 정리합니다.
Bluetape4k Exposed Part 6: BigQuery, Trino, CockroachDB, DuckDB 통합 예제 분석 플랫폼과 특수 DB를 Exposed DSL에 붙일 때, 실행보다 먼저 검증해야 할 경계를 예제로 봅니다.
OCR 서비스를 실전에서 운영하기: 큰 이미지 전처리와 실패 응답 계약 OCR 서비스를 글자 인식 엔드포인트가 아니라 큰 이미지 입력, 네이티브 OCR 런타임, 실패 응답의 경계로 나누어 설명합니다.
Bucket4j 요청 제한: 버킷보다 먼저 호출자 식별 기준을 정하라 Bucket4j 요청 제한을 저장소 선택에 앞서 호출자 식별, 프록시 신뢰, 응답 헤더 계약으로 나누어 설명합니다.
bluetape4k Flow 확장 함수: 복잡한 흐름을 명시적인 운영 계약으로 바꾸기 여섯 개 실전 예제로 Kotlin Flow 확장 함수가 취소, 대체 경로, 구독, 집계, 병렬 처리와 샘플링 계약을 어떻게 드러내는지 살펴봅니다.
코루틴 관측성: 추적 문맥과 준비 상태가 지켜야 할 경계 코루틴 서비스에서 추적 문맥을 유지하고, 준비 상태를 실제 운영 계약으로 검증하는 실전 예제를 살펴봅니다.
Transactional Outbox 2부: Kafka 우선 발행으로 주문 트랜잭션 줄이기 주문만 트랜잭션으로 저장하고 Kafka 직접 발행이 실패할 때만 영속 대체 행을 남기는 outbox 변형을 살펴봅니다.
트랜잭셔널 아웃박스와 멱등성: Spring·Ktor 예제로 보는 실패 경계 도메인 행과 아웃박스 행을 함께 저장하고, 재시도와 중복 요청을 DB 경계에서 다루는 방법을 Spring·Ktor 예제로 설명합니다.
Bluetape4k Text Part 4: 사전과 금칙어 변경을 테스트로 다루기 사전 파일 한 줄은 작지만 토크나이저와 금칙어 필터의 동작을 바꿉니다. 사전 변경을 어떻게 정리하고, 어떤 테스트로 검증해야 하는지 살펴봅니다.
Bluetape4k Text Part 3: Aho-Corasick 검색과 워크숍 시나리오 금칙어와 위험 키워드가 늘어나면 반복적인 contains 검사를 관리하기 어려워집니다. Aho-Corasick 자동 장치를 한 번 만들고 입력을 한 번 훑는 구조로 전환합니다.
Bluetape4k Text Part 2: 토크나이저와 언어 감지로 입력 라우팅하기 한국어, 일본어, 그 밖의 입력을 같은 문자열 처리 함수로 다루면 한계가 생깁니다. 토크나이저와 Lingua 언어 감지기의 책임을 서비스 경계에서 구분하는 기준을 살펴봅니다.
Bluetape4k Text Part 1: 텍스트 처리의 시작점과 품질 기준 문자열을 자르고 찾는 일도 서비스 경계로 들어오면 설계 문제가 됩니다. bluetape4k-text의 모듈 지도와 품질 기준을 먼저 봅니다.
Spring Boot 4 워크숍의 Jackson 3 전환 Spring Boot 4 예제의 의존성, 코드 API, 설정과 검증을 Jackson 3 기준에 맞추는 방법을 설명한다.
배치 벤치마크 재설계: measureTimeMillis에서 kotlinx-benchmark로 성능 수치보다 먼저 측정 경계, 비교 변수, 반복 조건과 결과 재현 경로를 고정해야 합니다.
Exposed R2DBC Workshop: Ktor 멀티테넌트 라우팅 패턴 Ktor에서는 테넌트 상태를 ThreadLocal에 숨기지 않고, 호출 속성과 명시적인 라우팅 값으로 전달합니다.
Bluetape4k Graph Part 5: 가상 스레드 벤치마크 해석 가상 스레드는 단일 그래프 호출의 속도가 아니라, 대기 작업의 동시 처리량을 위한 선택지입니다.
bluetape4k-dependencies 제작기 Part 3: Maven Central에는 롤백 버튼이 없다 여러 저장소를 함께 배포하려면 개발용 버전 행렬과 공개 릴리스 계약을 분리하고, 중앙 BOM을 마지막에 게시해야 합니다.
bluetape4k-dependencies 제작기 Part 2: 1.0.0 BOM을 공개 계약으로 만들기 BOM은 버전 표가 아니라 사용자 프로젝트의 의존성 해석 결과를 결정하는 공개 계약이다.
bluetape4k-dependencies 제작기 Part 1: 중앙 BOM이 필요한 이유 여러 저장소가 독립적으로 배포될 때 중앙 BOM은 사용자가 선택할 호환 버전 조합을 공개하는 운영 계약이 된다.
bluetape4k-dependencies 1.3.0 활용기 Part 4: 입력 경계와 자원 안전성 작은 샘플에서는 드러나지 않는 파일 크기, 메모리, 문자열 길이, 실패 응답 문제를 Image와 Text API 경계에서 확인한다.
bluetape4k-dependencies 1.3.0 활용기 Part 3: 운영에서 드러나는 신호 운영 문제를 조기에 발견하려면 캐시, AWS, 리더 선출 경계의 상태와 오류 신호를 관측해야 한다.
bluetape4k-dependencies 1.3.0 활용기 Part 2: 서비스 경계에 맞는 모듈 조합 BOM을 적용한 뒤에는 서비스가 책임지는 경계에 따라 필요한 모듈 조합을 선택한다.
bluetape4k-dependencies 사용 가이드: 여러 라이브러리 함께 사용하기 여러 bluetape4k 라이브러리를 함께 사용할 때는 각 모듈 버전을 개별 관리하지 않고 BOM을 먼저 적용한다.
bluetape4k-dependencies 1.3.0 활용기 Part 1: 기능 보강과 경계 정리 버전 숫자보다 중요한 것은 각 라이브러리에서 무엇이 나아졌고, 같은 실수를 어떻게 줄였는지다.
전역 고유 ID 생성기 성능 개선기: Go와 Kotlin 비교 Go ID 생성기 구현과 엔트로피 개선, Kotlin ULID·KSUID·Snowflake 개선을 세 차례 벤치마크로 비교합니다.
Bluetape4k Graph Part 4: 워크숍 시나리오와 서비스 통합 실행 가능한 워크숍 예제를 통해 그래프가 적합한 문제와 서비스 통합 경계를 살펴봅니다.
Bluetape4k Graph Part 3: 그래프 입출력과 벤치마크 해석 그래프 데이터는 서비스 밖으로 내보내고, 다시 불러오고, 테스트에서 재현할 수 있어야 합니다.
Bluetape4k Graph Part 2: 핵심 API와 실행 모델 그래프 저장소가 바뀌어도 서비스 코드의 변경을 줄일 수 있도록 핵심 API와 실행 모델을 정의합니다.
Bluetape4k Graph Part 1: 그래프 데이터베이스 선택 기준 그래프 데이터베이스를 도입하기로 했다면, 다음에는 워크로드와 운영 환경에 맞는 저장소를 선택해야 한다.
Bluetape4k JaVers Part 3: DDD와 워크숍 감사 예제 수동 감사 테이블에서 출발해 JaVers 스냅숏, DDD 저장소, Kafka/Redis 프로젝션 흐름으로 확장한다.
Bluetape4k JaVers Part 2: Exposed, Redis, Kafka 영속 저장소 선택 Exposed는 영속 이력, Redis는 빠른 스냅숏 조회, Kafka는 쓰기 전용 이벤트 스트림으로 구분한다.
Bluetape4k JaVers Part 1: 감사와 객체 차이 비교의 기본 모델 엔티티마다 감사 테이블을 만들기 전에 JaVers의 커밋, 스냅숏, 객체 차이 비교 모델부터 이해한다.
Bluetape4k AWS Part 5: 실전 예제로 적용하기 examples/와 bluetape4k-workshop/aws를 바탕으로 Spring Boot, Ktor, S3, SQS, DynamoDB 적용 흐름을 살펴봅니다.
Bluetape4k AWS Part 4: Spring Cloud AWS와 비교하기 Spring Cloud AWS와 bluetape4k-aws를 기능 수가 아니라 적용 범위와 운영 책임으로 비교합니다.
Bluetape4k AWS Part 3: Spring Boot와 Ktor 통합 Spring Boot 4 자동 구성과 Ktor 3 플러그인이 같은 AWS 공통 도우미를 각 실행 모델에 맞게 연결하는 방식을 살펴본다.
Bluetape4k AWS Part 2: 핵심 모듈과 AWS 서비스 지원 현황 Java SDK v2와 Kotlin SDK의 사용 방식, CRT 기반 S3 TransferManager, compileOnly 의존성 모델을 비교한다.
Bluetape4k AWS Part 1: Kotlin 서비스의 AWS 작업대 AWS SDK, 코루틴 래퍼, Spring Boot 4, Ktor 3, Floci·LocalStack 테스트 모델을 한눈에 정리합니다.
Bluetape4k Leader Part 5: 백엔드, 운영 기능, 벤치마크 리더 선출 백엔드를 기존 운영 인프라, 리스 저장 방식, 관측성을 기준으로 선택하는 방법.
Bluetape4k Leader Part 4: Spring Boot와 Ktor 통합 직접 호출하던 runIfLeader를 Spring AOP와 Ktor 스케줄러·관리 경계로 옮기는 방법.
Bluetape4k Leader Part 3: 복수 리더와 전략 선출 리더 한 명으로 부족할 때 그룹 슬롯과 후보 선출 전략으로 실행 권한을 제어하는 방법.
Bluetape4k Leader Part 2: 핵심 API와 실행 모델 하나의 작업을 블로킹, CompletableFuture, 코루틴, 가상 스레드 실행 모델에 맞춰 처리하는 방법.
Bluetape4k Leader Part 1: 리더 선출의 기본 모델 스케줄 작업, 마이그레이션, 폴러, 캐시 워머가 모든 레플리카에서 중복 실행되지 않도록 제어하는 방법.
Bluetape4k Exposed Part 5: 실전 예제 - 캐시 전략과 멀티테넌시 Exposed 저장소와 트랜잭션 경계에 캐시, 멀티테넌시, 아웃박스, 멱등성을 결합하는 방법을 살펴봅니다.
Bluetape4k Exposed Part 4: JSON, 암호화, 다이얼렉트 데이터베이스별 세부 사항을 도메인 코드에 분산하지 않고 사용자 정의 컬럼 타입과 다이얼렉트 모듈로 격리한다.
Bluetape4k Exposed Part 3: R2DBC, 코루틴, 가상 스레드 R2DBC는 스트리밍에 강하고, JDBC + 가상 스레드는 익숙한 드라이버 방식을 살린다. 숫자로 고르자.
Bluetape4k Exposed Part 2: JDBC 저장소와 SQL DSL SQL DSL은 숨기지 말고, 반복되는 저장소 경계만 줄인다.
Bluetape4k Exposed Part 1: 왜 Exposed인가 R2DBC, Vert.x, 가상 스레드, Exposed DSL을 지나 운영용 Exposed 확장으로 가는 선택 기준.
Bluetape4k Projects Part 6: Spring Boot 4와 Ktor Spring Boot 4와 Ktor 3에서 코루틴, 데이터, Redis, 관측성, 테스트 경계를 잡는 방법.
Bluetape4k Projects Part 5: 유틸리티와 도입 경로 작은 유틸리티 모듈을 필요한 만큼만 고르고 예제와 벤치마크로 검증하는 채택 순서.
Bluetape4k Projects Part 4: 데이터와 인프라 DB, Redis, 메시징, 관측성, 회복성 경계를 Kotlin 서비스에서 덜 거칠게 쓰는 방법.
Bluetape4k Projects Part 3: 바이트가 지나가는 길 파일, 버퍼, 직렬화기, HTTP/RPC, 암호화가 만나는 I/O 경계 정리.
Bluetape4k Projects Part 2: 공통 기반의 안쪽 서비스 요청과 테스트 픽스처가 함께 기대는 core, coroutines, logging, tests 기반.
Bluetape4k Projects Part 1: 공유 Kotlin/JVM 기반 core, coroutines, I/O, data, infra, Spring Boot, Ktor, 테스트 기반이 한 저장소에 모인 이유.
Bluetape4k Cache Part 4: Workshop 예제로 캐시 전략 감 잡기 Caffeine, Redis, resilience와 Exposed loader/writer 전략을 예제로 살펴본다.
Bluetape4k Cache Part 3: Near Cache와 Exposed로 캐싱 전략 만들기 Read-through, write-through, write-behind. 이름은 비슷하지만 사고 방식은 꽤 다르다.
Bluetape4k Cache Part 2: Near Cache, Redis 왕복을 줄이는 현실적인 방법 Remote cache는 공유되지만 멀다. Near Cache는 뜨거운 읽기를 JVM 가까이 둔다.
Bluetape4k Cache Part 1: 캐시 모듈은 왜 이렇게 생겼나 로컬 캐시, JCache, suspend API, memoizer, NearCache가 한 상자에 들어간 이유.
Virtual Threads 4편: Java 21과 Java 25를 하나의 API로 감추기 Java 21과 25 차이는 내부로 숨기고, 애플리케이션 코드에는 하나의 Virtual Threads API만 보여주는 방법.
Virtual Threads 3편: JDBC가 R2DBC를 생각보다 자주 이긴 이유 R2DBC가 당연히 이길 줄 알았는데, 벤치마크 결과는 꽤 달랐다. JDBC + Virtual Threads의 반격.
Virtual Threads 2편: 실전에서 바로 걸리는 규칙들 Virtual Threads를 켰다고 끝이 아니다. pool, semaphore, context, lock 경계에서 바로 차이가 나는 실전 규칙들.
Virtual Threads 1편: 저비용이지만 마법은 아닌 스레드 블로킹 코드를 다시 활용할 수 있다는 반가운 소식. 단, timeout과 자원 한도를 함께 설계할 때만.
부끄러운 실수가 더 나은 안전장치를 만들 때 null이 0이 되고, 테스트가 낡고, cleanup이 timeout에 막히고, cancellation과 interrupt를 놓친 다섯 가지 실수 회고.
Ktor CIO가 HTTP 벤치마크를 이상하게 만들었을 때 Ktor CIO의 느린 초기 숫자에서 출발해 공정한 벤치마크, Vert.x pool 병목 수정, workload별 HTTP client 선택 기준까지 정리한 글.
CSV Writer가 불필요한 우회 경로를 걷어냈을 때 Okio CSV writer 후속 작업. Flow row 파이프라인, UTF-8 sink, CSV 의미 보존, 그리고 large export 3.25배 개선을 정리합니다.
Okio 세그먼트로 CSV 파서 할당 줄이기 CSV 파서 최적화 작업을 Reader 기반 파싱부터 Okio UnsafeCursor 세그먼트 탐색까지 벤치마크와 함께 정리합니다.
순수 JVM에서 libvips까지: bluetape4k 이미지 처리 벤치마크 scrimage와 libvips 벤치마크, Java 21 JNI의 호스트 제약, Java 25 FFM 실측값, 워크숍 파생 이미지 처리 예제를 정리합니다.
Backend 서비스는 언제 GraphDB를 도입해야 할까? GraphDB 도입 기준, PostgreSQL 순회 기준선, AGE, Neo4j, Memgraph, 그래프 저장소가 잘 맞는 사용 사례를 벤치마크 결과로 정리합니다.
Bluetape4k 생태계 한눈에 보기 Spring Boot 4, Ktor 3, 도메인 기능, 데이터, 인프라, 기반 계층으로 Bluetape4k 전체 구조를 정리합니다.
AI와 일하는 환경을 인프라로 만들기 AGENTS.md, bluetape4k skills, qmd, memory, hooks로 Codex와 Claude가 같은 기준을 읽고 검증하게 만든 방식입니다.
AI와 3개월 동안 키운 대규모 Kotlin 라이브러리 생태계 Claude Code와 Codex로 자동화, 문서화, 테스트, 연구, 예제, 대규모 repo 작업을 안정화한 과정과 배운 점입니다.
선택한 태그의 글이 없습니다.