본문 바로가기

전체 글34

[분산 시스템] Dual Write와 데이터 정합성 (1편): 전파 지연과 장애 복구 전략 목차문제 정의: 분산 시스템과 Dual Write문제 유형 1: 상태 전파 지연 (일시적 불일치)문제 유형 2: 시스템 장애 (정합성 붕괴) Case A: 이벤트 유실 (Outbox, CDC) Case B: 유령 데이터 (이중 방어 전략: 선제적 검증, 상태 머신 & 자가 치유)결론: 대응 전략 요약1. 문제 정의: 분산 시스템과 Dual Write1.1 분산 시스템과 상태 관리분산 시스템은 하나의 목표를 위해 여러 노드가 네트워크로 협력하는 구조다.각 노드는 메모리를 공유하지 않으며, 상태 전달은 오직 네트워크 메시지 통신에 의존한다. 많은 서비스는 다음과 같이 여러 이종(Heterogeneous) 시스템에 상태를 분산 저장한다.RDBMS: 원본 데이터 영속화 (= Source of Truth)Cach.. 2026. 1. 1.
2025년 회고 – 커리어 신년 계획이 자주 실패하는 이유는 대부분 목표가 모호하기 때문이다.2026년 목표를 선명하게 만들기 위해, 2025년 커리어 관련 회고를 다음 순서로 정리했다.1) 업무 경험2) 면접 경험3) 2025년 회사 선택 기준과 정체성 정립4) 정리 1) 업무 경험1-1. 입사 후 3개월: 도메인/엔진 학습과 멘토링입사 후 첫 1개월은 신입 교육이었고, 이후 2개월은 GIS 도메인 개념을 사내 위키와 자료를 통해 정리하면서, 3D GIS 엔진 개발에 필요한 설계와 렌더링 알고리즘을 별도로 공부했다.특히 3D Engine Design for Virtual Globes 같은 자료를 보며 핵심 개념을 정리했고, 그 내용을 수석님께 설명하면 수석님이 실제 엔진 구현 관점에서 더 구체적으로 보완해 주셨다. (회고를 하며.. 2025. 12. 27.
분산 시스템 시간 정합성: UTC, NTP, 그리고 관용 Kafka 기반 분산 시스템에서 transactional outbox 테이블에 메시지가 분명 존재하는데도 발행되지 않는 문제를 겪었습니다. 원인은 Producer와 Poller(Message Relay: Polling)가 서로 다른 시간을 기준으로 이벤트를 판단하고 있었던 것이었습니다. 이 글은 이 경험을 바탕으로, 왜 분산 환경에서는 UTC를 공통 시간 기준으로 삼아야 하고, 그것만으로는 왜 충분하지 않은지를 정리한 글입니다. 목차문제 정의원인: “모든 서버의 시계는 같을 것이다”라는 착각해결책요약1. 문제 정의 이벤트 기반 아키텍처의 분산 시스템(Producer–Consumer)에서는물리적 시간 불일치(Clock Skew / Drift)와타임존 해석 차이로 인해 다음과 같은 문제가 발생할 수 있습니다.. 2025. 12. 23.
3D 모델 요청/응답 API 설계 3D 애플리케이션에서 지도 위 한 점을 클릭했을 때, 우리는 보통 하나의 객체가 로딩되기를 기대합니다.예를 들어, 지도에서 스타벅스를 찾을 때 그곳에 스타벅스 건물 하나가 로딩되는 장면을 떠올립니다.하지만 실제 그 지점에는 스타벅스만 있는 것이 아닙니다.스타벅스 건물주변 나무가로등신호등땅(토지)즉, 하나의 좌표(타일) 위에는 여러 개의 3D 객체가 동시에 존재합니다. “이것들은 꼭 하나의 모델일 필요는 없다”이 객체들이하나의 3D 모델로 미리 합쳐져(Merge) 있을 수도 있고여러 개의 3D 모델로 분리되어 있을 수도 있습니다이건 개발자의 설계 영역입니다.“이 타일을 클릭했을 때 클라이언트와 서버는 어떻게 요청/응답 하는가?” 개발자가 고려해야하는 3가지 요소요청 모델: 단일 요청 vs 멀티 요청응답 모.. 2025. 12. 22.
현실판 자비스, 팔란티어 들어가며 단순한 대시보드나 리포팅 툴을 넘어, 데이터가 기업의 의사결정 구조를 어떻게 혁신할 수 있는지 예측하기 위해 이 시장의 선두주자인 '팔란티어(Palantir)'가 어떤 문제를 정의했고, 기술적으로 어떻게 해결했는지 간단하게 정리했습니다. 질문: 지식이 많아지면 우리는 더 똑똑해질까요, 아니면 더 혼란스러워질까요? 흔히 지식의 90%는 쓸모없는 파편이며, 이를 그룹핑하고 요약해낸 10%만이 비로소 가치 있는 정보가 된다고 합니다. 즉, 아무리 데이터가 많더라도 그 안의 관계(Relationship)가 정리되지 않으면 그건 지식이 아니고 '혼잡(Chaos)' 입니다. 1. 팔란티어가 정의한 문제: 데이터 사일로(Data Silo)영화 에서 토니 스타크가 "적의 위치는?", "플랜 B 가동해"라고 .. 2025. 12. 20.
[마이그레이션] Spring 4 → Boot 3.4: Java 17, Gradle, JAR, 그리고 제어권의 변화 최근 Spring 4 + Java 8 기반의 레거시 시스템을 Spring Boot 3.4 + Java 17로 마이그레이션 했습니다. 초기에는 단순한 라이브러리 버전 업그레이드로 접근했습니다. 하지만 마이그레이션을 진행할수록, 단순한 프레임워크 교체가 아닌 애플리케이션 아키텍처의 재설계였으며, 인프라에 종속되었던 시스템 제어권을 애플리케이션으로 가져오는 전환점이었습니다. 이번 글에서는 마이그레이션 과정에서 경험한 기술적 변화 5가지를 정리했습니다.서블릿 제어권: WAS(Tomcat) 중심에서 Application 중심으로배포 방식: 환경 종속적인 WAR에서 독립적인 JAR로빌드 도구: 정적인 Maven에서 유연한 Gradle로설정 관리: 파편화된 XML에서 중앙 집중형 YAML로런타임: Java 8(T.. 2025. 12. 12.
1시간 만에 ‘환승연애4 이상형 월드컵’ 배포하기 최종 결과물 링크: https://e-xchange-4-ideal-type-world-cup.vercel.app/GitHub 링크: https://github.com/minseojo/EXchange-4-Ideal-Type-World-Cup '환승연애 4 이상형 월드컵' 웹을 1시간 만에 만들기 위해Gemini Canvas로 디자인과 기능을 구현하고,완성된 프로젝트를 Vercel로 배포한 뒤,배포된 웹의 방문 통계를 Google Analytics로 확인하는 전체 과정을 정리했습니다.코드 작성 방법 (Gemini Canvas)만들고 싶은 앱은 다음과 같은 흐름을 가진 React 웹페이지입니다.이름/닉네임 + 성별 입력성별에 따라 환승연애 4 출연진 필터링토너먼트 형식으로 이상형 월드컵 진행최종 우승자를 공유.. 2025. 12. 8.
신뢰성을 위한 Timeout 처리와 멱등성 설계 전략 네트워크 통신에서 Timeout은 단순히 '실패'를 의미하지 않습니다.클라이언트와 서버 사이의 요청-응답 처리 과정에서 Timeout이 발생했을 때 생길 수 있는 3가지 시나리오를 살펴보고, 단순히 '재시도'를 선택했을 때 발생하는 정합성 문제와 이를 해결하기 위한 멱등성(Idempotency) 전략에 대해 정리했습니다. 목차네트워크 통신 흐름 네트워크 통신 개념 TCP 3-way Handshake 과정 Timeout 개념네트워크 Timeout 종류 Connection TimeoutRead TimeoutTimeout 발생 후 요청의 실제 상태 (3가지 경우)요청이 서버에 도달하지 못한 경우요청이 서버까지 도달했고 실패한 경우요청이 서버까지 도달했고 성공했지만 응답이 유실된 경우 (*가장 위험한 케이.. 2025. 12. 2.
대용량 파일 업로드의 정합성 보장 전략: Atomic Rename과 SeaweedFS 활용 올해 3D 타일 배포 파이프라인을 새롭게 구축했습니다. 빌드 시 최대 5,000개의 파일이 생성되며, 이러한 빌드 결과물이 수십 번 이상 누적되어 하나의 배포 버전을 구성하는 구조입니다. 가장 큰 기술적 난제는 물리적으로 분리된 DB(상태)와 오브젝트 스토리지(파일) 간의 정합성 유지였습니다. 업로드 중 장애나 재시도가 발생할 경우, 스토리지에는 파일이 적재되었으나 DB는 실패로 기록되는 등 두 시스템 간 상태 불일치(Inconsistency)가 발생할 수 있기 때문입니다. 복잡하고 성능에 불리한 2PC(Two-Phase Commit) 대신 Atomic Rename 패턴을 적용해 이 문제를 해결했습니다. 전략은 완성된 데이터를 스테이징 경로에 먼저 격리한 뒤, 배포 시점에 공개 경로로 원자적으로 전환(A.. 2025. 11. 27.
SRP를 만족하는 모듈화 리팩토링 과정 기존 GIS 엔진은 모놀리식 시스템입니다.전국 단위 데이터를 한 번에 처리하는 파이프라인은 수십 시간에서 많게는 수백 시간이 걸렸습니다. 이를 개선하기 위해 멀티노드 기반의 병렬 빌드 시스템으로 전환했습니다. 그 과정에서 모듈화 리팩토링을 진행했습니다.하지만 초기에 하나의 모듈에 많은 책임을 주어 확장성과 유지보수성을 떨어트렸습니다. 이 글에서는 SRP(Single Responsibility Principle)를 만족하지 않는 모듈이 어떤 문제를 일으키는지,그리고 이 문제를 해결하기 위해 SRP를 만족하는 모듈로 어떻게 구현 했는지 정리했습니다.모듈화 전/후 구조 차이 모듈화 전: 프로세스가 1개의 모듈을 실행하고, 해당 모듈에서 여러 내부 메서드(기능)를 실행하는 구조모듈화 후: 프로세스가 1개의 모듈.. 2025. 11. 16.
[I/O 멀티플렉싱] select · poll · epoll 참고레디스가 빠른 이유: https://velog.io/@redjen/%EB%A0%88%EB%94%94%EC%8A%A4%EB%8A%94-%EC%99%9C-%EB%B9%A0%EB%A5%BC%EA%B9%8Cselect 와 epoll: https://ozt88.tistory.com/21https://velog.io/@im2sh/%EC%86%8C%EC%BC%93-17-select%EB%B3%B4%EB%8B%A4-%EB%82%98%EC%9D%80-poll selectFD 한도: 기본 FD_SETSIZE=1024 (빌드 시 키우면 늘릴 수 있지만 보통 1024로 가정)FD 관심목록: 사용자 공간이 비트셋을 매 호출마다 재구성해 커널로 전달복잡도: 커널이 maxfd까지 선형 스캔 O(n), 사용자도 FD_ISSET로.. 2025. 10. 10.
Gzip, Zstandard, Brotli 압축 비교 - 3D 모델 파일 3D 모델 파일을 두 가지 목적을 가지고 압축을 고려했습니다.아카이빙(보관용)대용량 파일의 전송 효율화gizp, zstd, brotli 압축 코덱의 성능을 단순히 수치로만 비교했습니다.별도의 해석을 덧붙이지 않은 이유는, “어떤 코덱이 가장 좋다”는 절대적인 기준이 없기 때문입니다.압축의 목적과 사용 환경에 따라 최적의 선택은 달라집니다.압축 목적에 따른 고려 사항 (예시)압축목적이 아카이빙이라면 며칠? 몇개월? 몇년?압축파일을 조회하는가? 압축파일을 조회하면 조회 주기가 어느정도?압축목적이 전송용이라면 어떻게? 브라우저라면 브라우저는 압축 포맷을 지원하는가? (gzip, br 등)압축하려는 파일은 text? binary?압축률은 어느정도여야 하는가? 50%? 20%? 10%?압축속도는 얼마나 빨라야하는.. 2025. 10. 7.
CAP, PACELC 개념·트레이드오프 정리 목차1. 분산 시스템이 필요한 이유 (확장성, 장애 허용, 지연 문제 해결)2. CAP(Consistency, Availability, Partition Tolerance) 개념3. CA / CP / AP 시스템 실제 사례 (RDBMS, HBase, Cassandra 등)4. PACELC 개념5. 분산 시스템 설계 Trade-off6. 요약7. 참고1. 분산 시스템이 필요한 이유 (확장성, 장애 허용, 지연 문제 해결)분산 시스템은 단일 서버로 해결할 수 없는 문제를 풀기 위해 필요합니다. 주요 이유는 다음과 같습니다. 확장성 (Scalability)데이터와 트래픽이 기하급수적으로 증가할 때, 하나의 서버만으로는 처리 한계가 있습니다.여러 대의 서버를 수평적으로 확장(horizontal scaling)하.. 2025. 8. 21.
지도·비지도·강화 학습 개념 정리 참고지도·비지도·강화학습은 학습 방법(패러다임)의 구분머신러닝·딥러닝은 알고리즘/모델의 구분 즉, 모든 학습 방법은 머신러닝과 딥러닝 방식 모두로 구현될 수 있습니다.1. 지도학습 (Supervised Learning)정의: 입력과 정답(label)이 있는 데이터를 학습아이디어: 정답이 있어 입력 → 출력 관계를 배움문제 유형- 회귀(Regression): 연속값 예측 → 예: 집값 예측, 온도 예측- 분류(Classification): 범주 예측 → 예: 스팸 메일 판별, 고양이/강아지 이미지 분류대표 알고리즘: 선형/로지스틱 회귀, 결정트리/랜덤포레스트, SVM, KNN, 신경망2. 비지도학습 (Unsupervised Learning)정의: 정답(label) 없이 데이터의 구조나 패턴을 학습아이디.. 2025. 8. 20.
B-트리와 B+트리 선택 기준 목차1. B-트리 특징/장단점 2. B+트리 특징/장단점 3. 언제 B-트리가 유리할까? 4. 왜 데이터베이스는 B+트리를 쓸까? 5. 실제 사례 비교 (MySQL ↔ Redis) 6. 요약1. B-트리 특징/장단점 특징- 모든 노드(내부 + 리프)에 데이터 저장장점- 중간 노드에서 바로 데이터를 찾을 수 있어 단일 검색 속도 빠름- 메모리 사용 효율 높음 (리프만 따로 두지 않음)- 작은 데이터셋이나 메모리 기반 구조에 적합단점- 리프 노드들이 연결되어 있지 않아 범위 검색 비효율적2. B+트리 특징/장단점특징- 내부 노드는 인덱스만, 데이터는 리프 노드에만 저장- 리프 노드들이 연결 리스트로 연결됨장점- 범위 검색 / 순차 탐색 최적화- 내부 노드에 더 많은 키 저장 가능 → 트리 높이가 낮아짐- 대.. 2025. 8. 19.
선형 회귀 개념 정리 이 글은 선형 회귀로 풀고자 하는 문제를 간단히 이해하기 위해 작성했습니다.※ 참고: 1차원 선형 회귀내용만 있습니다. 이 외에도 다양한 형태의 회귀 모델이 존재합니다. - 입력 변수가 여러 개인 다변수 회귀- 곡선 형태를 학습하는 다항 회귀 등 목차1. 선형 회귀란 무엇인가?2. 선형 회귀 한계3. 선형 회귀 수식4. 선형 회귀가 왜 필요한가?5. 선형 회귀의 핵심: 오차 최소화6. 오차를 줄이는 대표적인 방법: 경사 하강법 (Gradient Descent)7. 요약1. 선형 회귀란 무엇인가?선형 회귀(Linear Regression)는 주어진 데이터를 가장 잘 설명하는 직선 형태의 함수를 찾아, 새로운 값을 예측하는 기계학습 알고리즘입니다. 즉, 독립 변수(x)와 종속 변수(y) 사이의 선형적 관계를.. 2025. 8. 4.
전 세계 공간정보를 관리하는 자료구조 구현기 - Implicit Tiling 이 글은 3D Tiles Specification – Implicit Tiling (Cesium)을 3D GIS 엔진에 직접 적용하는 과정에서 마주친 문제들을 어떻게 해결했는지에 대한 경험을 정리한 글입니다. 깃허브 시각화 링크들어가기에 앞서안녕하세요. 이번 글에서는 전 세계 수조 개에 달하는 3D 공간 정보를 어떻게 효율적으로 관리하고 스트리밍할 수 있을까?라는 문제의식에서 출발하여, Implicit Tiling 기반의 공간 데이터 구조에 대해 소개하고자 합니다. 기존 3D GIS 엔진은 보통 모델을 '그리는 것'에는 특화되어 있었지만,정작 그 모델들을 데이터베이스처럼 체계적으로 관리하거나, 위치 기반으로 탐색하는 데에는 한계가 있었습니다. 예를 들어, "서울대입구역 8번 출구 스타벅스"의 정확한 경위.. 2025. 7. 20.
[Copy-on-Write] Redis BGSAVE OOM 원인 목차1. 문제 배경: Redis가 죽은 이유2. 배경 지식: Redis의 BGSAVE와 Copy-on-Write3. 실험 목적: Copy-on-Write가 실제로 OOM을 유발하는가?4. 실험 환경: Docker 기반 Redis 컨테이너 구성5. 실험 과정: Copy-on-Write 상황 유발 및 메모리 관측6. 실험 결과: Copy-on-Write로 인한 OOM은 실제로 발생한다7. 실험을 통해 알게 된 것8. 결론9. Github 링크1. 문제 배경: Redis가 죽은 이유Redis가 예고 없이 종료될 수 있습니다.Redis의 maxmemory는 6GB로 설정되어 있었고,컨테이너의 메모리 제한은 7GB였으며,메모리 사용량이 한계에 가까운 시점에서 BGSAVE가 실행되었고,그 결과 Redis가 Out .. 2025. 6. 15.
[Z-order Indexing] 다차원 공간 데이터 최적화 들어가기에 앞서 좌측 그림은 데이터를 메모리에 선형적(Row-Major)으로 저장, 탐색하는 방식,우측 그림은 Z-order 기반으로 정사각형 블록 단위로 저장, 탐색하는 방식입니다.이 두 가지 방식의 차이가 공간 데이터 처리 성능에 어떤 영향을 미치는지 살펴보겠습니다. 현대의 지도 서비스, 자율주행 시뮬레이션, 지리 정보 시스템(GIS) 등은 방대한 공간 데이터를 실시간으로 탐색하고 처리해야 합니다.하지만 이러한 데이터를 단순히 행렬 순서(예: Row-Major)로 저장하면, 지리적으로 가까운 두 점이 메모리 상에서는 멀리 떨어져 저장될 수 있습니다. 이는 CPU 캐시 효율을 낮추고 데이터 접근 성능을 저하시키는 주된 원인이 됩니다. 이러한 문제를 해결하는 대표적인 방식이 Z-order Indexing.. 2025. 6. 14.
[Zero-Copy] 파일 전송 최적화와 Kafka 코드 분석 들어가기에 앞서 일반적인 서버의 목적은 클라이언트 요청에 대해 적절한 응답을 빠르고 효율적으로 반환하는 것입니다.즉, 대부분의 서버는 다음과 같은 단순한 I/O 루틴을 반복합니다."입력(요청)을 받고 → 출력(응답)을 보낸다." 예를 들어, 웹 서버는 클라이언트의 요청에 따라 정적 파일(HTML, 이미지 등)을 전송하고,WAS(Web Application Server)는 DB에서 읽어온 사용자 데이터를 API 응답으로 보내며,FTP 서버는 파일을 반환합니다. 이러한 동작들은 모두 단순한 코드로 표현할 수 있습니다.read(fd, buffer, size);send(socket, buffer, size);하지만 이 단순한 동작 이면에서는 여러 번의 데이터 복사와 사용자 공간(user space)과 커널 공간.. 2025. 5. 31.
[Log-based System] RDBMS와 Kafka 구조 분석 로그는 왜 중요할까요?단순한 기록처럼 보이던 로그가, 어떻게 시스템 간 데이터 흐름, 복구, 재처리, 확장을 가능하게 만드는 걸까요?이 글에서는 로그 기반 아키텍처의 핵심 철학을 정리했습니다. 들어가기에 앞서 우리는 서비스를 만들 때 다양한 시스템을 함께 사용합니다.데이터베이스(DB): 사용자 정보, 거래 내역 등 구조화된 데이터를 저장캐시(Redis 등): 빠른 응답을 위해 임시로 데이터를 저장검색엔진(Elasticsearch): 텍스트 기반 검색과 분석을 지원분석 시스템(Hadoop, Spark): 데이터를 수집하고 집계하여 비즈니스 인사이트를 도출이 각각의 시스템은 서로 다른 목적과 다른 형식의 데이터 처리 방식을 갖고 있습니다. 문제는 여기서 시작됩니다.이 시스템들이 하나의 흐름 속에서 유기적으로.. 2025. 5. 25.

티스토리툴바