Git 줄바꿈(LF, CRLF) 정리 및 실무 설정 가이드1. 줄바꿈(Line Ending)의 차이운영체제마다 줄바꿈 문자가 다르다.운영체제줄바꿈 문자표기설명Linux / macOSLF\nLine FeedWindowsCRLF\r\nCarriage Return + Line Feed이 차이 때문에 Windows에서 만든 파일을 Linux 환경으로 올리면 ^M 문자가 생기거나,빌드 스크립트·셸 스크립트가 깨지는 문제가 생긴다.2. Git의 자동 변환 설정: core.autocrlfGit은 운영체제별 줄바꿈 차이를 자동으로 처리하기 위해 core.autocrlf 설정을 제공한다.환경권장 설정설명Windowscore.autocrlf=true커밋 시 CRLF→LF로 변환, 체크아웃 시 LF→CRLF 변환macOS ..

데이터 구축 시 고려사항메시지 처리의 전달 보장(delivery guarantee)보장방식데이터 손실중복 처리사용사례처리속도복잡도At most once✅ 있음❌ 없음로그 수집, 비중요 이벤트빠름낮음At least once❌ 없음✅ 있음결제 처리, Kafka, IoT 이벤트보통중간Exactly once❌ 없음❌ 없음은행 송금, Flink E2E 처리, 재고관리 시스템느림높음 속도 중요 / 유실 감수 가능 → At most once정확한 처리 중요 / 중복 허용 가능 → At least once + 중복 방지 로직 추가정확성 매우 중요 / 복잡도 감수 가능 → Exactly once이미지로 외우기1️⃣ At most once – “난 분명히 보냈어!” 직원특징:메시지를 한 번 보내고 끝중복은 절대 안 함..

분산 시스템의 메시지 로깅 패턴: RBML, SBML, HML 완전 정복스트리밍 데이터 처리 시스템을 운영하다 보면 가장 중요한 문제 중 하나가 바로 메시지 유실 방지입니다. 특히 Flink, Kafka Streams 같은 실시간 처리 엔진에서는 시스템 장애가 발생했을 때 어떻게 데이터를 안전하게 복구할 것인가가 핵심 과제죠.오늘은 분산 시스템에서 사용되는 세 가지 메시지 로깅 패턴인 RBML, SBML, HML에 대해 실무 경험을 바탕으로 자세히 알아보겠습니다.메시지 로깅이 왜 필요한가?먼저 간단한 시나리오를 생각해보겠습니다. 이커머스 회사에서 실시간 주문 처리 시스템을 운영하고 있다고 가정해보죠.주문 이벤트 → Flink 처리 → 재고 업데이트 → 알림 발송만약 Flink 애플리케이션이 재고 업데이트..

데이터 수집 파이프라인에서실시간으로 데이터를 처리하는 스트리밍 패턴에서장애 발생시 어떻게 데이터를 처리할까? 어떻게 처리해야 정합성을 유지할까?이때 두가지 방식이 혼합해서 사용한다.체크포인트, 로깅 (1) 체크포인트와 로깅체크포인트무엇을 저장하나? 특정시점의 전체 상태를 저장(Snapshot) + 그 체크포인트까지 처리된 이벤트 인덱스값(offset) 활용장애 발생 시 가장 최근의 체크포인트로 복구 + 로깅의 이벤트 기록을 순차적으로 재처리함로깅시간순으로 발행된 이벤트를 순차적으로 그대로 저장하는 것활용장애 발생 시 이벤트 기록들을 replay해서 데이터를 복구여기까지만 봐도 뭔말인지 모를 용어들이 난무한다.체크포인트, 로깅뭔지 알려면 좀더 구체적인 예시로 이해하는게 좋다.그전에 이벤트, 상태라는게 뭔..

Error, Fault, Failure — 헷갈리는 개념 정리와 실무 사례개발하다 보면 장애가 터졌을 때 이런 질문을 많이 받습니다.이건 개발자가 실수한 거야?아니면 시스템이 이상한 건가?이건 버그야, 아니면 장애야?이럴 때 필요한 게 바로, 세 가지 개념의 구분입니다:오류(Error), 결함(Fault), 장애(Failure) 용어정의설명🟥 Error (오류)사람이 만든 실수잘못된 코드, 잘못된 입력, 설정 오타 등🟧 Fault (결함)오류로 인해 시스템에 잘못된 설정 또는 값이 적용된 상태오류가 코드나 설정, 인프라에 남아 있는 상태시스템이 실행되면 장애가 발생될 것으로 예상되는 상태🟨 Failure (장애)결함으로 인해 서비스에서 피해가 발생한 상태사용자 또는 모니터링 관점에서 서비스가 망가진..

Falut tolerance 시스템에 일부 장애나 오류가 발생하더라도 전체 서비스가 중단되지 않고 정상동작을 유지할 수 있는 능력 내결함성이 요구되는 대상과 솔루션구분내결함성 요구 대상이유 솔루션1️⃣ 수집기IoT 센서, 로그 수집 에이전트 (Fluentd, Telegraf 등)수집기 장애 시 데이터 손실 우려- 버퍼링 (disk/memory)- Retry/Backoff- MQTT QoS (1,2)2️⃣ 메시지 브로커Kafka, RabbitMQ, MQTT 등메시지 전송 중 장애 대비- Replication (Kafka ISR)- High Availability 클러스터 구성- ACK 기반 전송 보장3️⃣ 수집 서버 / 인제스터Logstash, Fluentd, Kafka Connect 등대량 데이터 실..

✅ 명확한 정의를 내리고 기억하자!Stateful (상태 저장) vs Stateless (상태 비저장) statefulstateless정의이전 요청에서의 상태를 기억하고 다음 요청에 반영함이전 요청과 관계없이 모든 요청을 독립적으로 처리함특징세션/컨텍스트를 유지함요청마다 필요한 모든 정보를 포함해야 함예시로그인 후 세션 유지, DB 연결 세션, TCPREST API, DNS, HTTP, UDP 이전 요청에 대한 정보를 들고있는지 아닌지에 따른 구분.관념적인 개념이고 때문에 여러 상황에서 응용되어 사용됨. -> 반드시 개념적의미를 구분지어 알고 있어야한다. 🛠 실무 적용 예시✅ 1. 웹 애플리케이션Stateful: 로그인 세션을 서버에서 저장하고, 이후 요청마다 사용자 정보 유지 (예: JSP + T..

(1) 홈페이지 접속후 설치 https://brew.sh/ko//bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" (2)환경변수 설정 → 이제 안해도됨, 새터미널 켜고 brew --version 확인1단계: Homebrew 설치 위치 확인 bash# Homebrew가 실제로 설치되어 있는지 확인ls -la /opt/homebrew/bin/brew엔지니어 독백: "Apple Silicon Mac에서는 Homebrew가 /opt/homebrew에 설치돼. 설치는 됐는데 PATH에 추가되지 않아서 터미널이 못 찾고 있는 거야."2단계: 환경변수 설정왜 하는가: 터미널이 brew 명령어를 찾..