Study Note

코인 세금, 결론부터 말씀드리면 이래요.​법으로는 2027년 1월 1일부터 과세가 맞아요.그런데 정부가 다시 미루는 걸 검토 중이고, 11월 말~12월 초에 결정돼요.​지난 글에서 리플이랑 비트코인 이번 주 흐름을 정리했는데요.댓글이나 주변에서 제일 많이 들은 질문이 "그래서 세금은 내년부터 내는 거야?"였어요.​저도 리플이랑 비트코인을 계속 지켜보는 입장이라 이번에 제대로 찾아봤어요.유예가 되든 안 되든, 12월 31일 전에 알아두면 좋은 것들 위주로 정리했어요.​이 글에서 볼 수 있는 것​- 지금 법에 정해진 코인 세금 구조- 유예 논의, 누가 왜 미루자고 하는지- 내 수익이면 세금이 얼마인지 계산 예시- 2026년 12월 31일이 왜 중요한지- 지금 해둘 준비 4가지​​1. 지금 법으로 정해진 코인..

"이 스파게티 코드가 되어버린 10년 된 쇼핑몰을 MSA로 전환합시다!"이 결심을 한 순간, 경영진과 개발팀은 두 가지 갈림길에 섭니다. **"새 시스템을 완벽하게 다 만들 때까지 기다렸다가 한방에 오픈하자"**는 유혹과, **"일단 회원 기능만 떼어내서 먼저 오픈하자"**는 신중함 사이의 선택입니다.1. 방식 1: 빅뱅 (Big Bang Rewrite) - "모 아니면 도"기존 시스템(Legacy)은 그대로 운영하면서, 옆에서 새로운 시스템(New System)을 처음부터 끝까지 다 개발한 뒤, 특정 날짜(D-Day)에 스위치를 내리고 교체하는 방식입니다.특징이중 개발: 운영팀은 레거시를 유지보수하고, 개발팀은 차세대를 개발합니다. (기능 변경이 있으면 양쪽에 다 적용해야 함)한방 배포: D-Day 새..

"새로운 결제 기능을 배포했는데 치명적인 버그가 발견되었습니다. 서버를 내리고, 코드를 수정하고, 다시 빌드해서 배포하려면 최소 30분이 걸립니다. 그동안 결제는 멈춰있습니다."만약 코드 안에 **"이 기능을 켤까요?"**를 확인하는 if 문이 하나 있고, 그 값을 외부에서 즉시 바꿀 수 있다면 어떨까요? 서버 재배포 없이 스위치만 내리면(Off) 구버전으로 돌아갈 수 있습니다.이 스위치를 "설정 파일에 박아둘 것인가" 아니면 **"실시간으로 제어할 것인가"**에 따라 활용도가 달라집니다.1. 방식 1: 정적 토글 (Static Toggle / Config-based) - "단순한 스위치"애플리케이션의 설정 파일(application.yml, .env)에 기능의 ON/OFF 여부를 적어두는 방식입니다. ..

"사용자가 회원 가입을 했습니다. 가입 환영 메일도 보내야 하고, 쿠폰도 지급해야 하고, 통계 로그도 남겨야 합니다."이때 메시지 큐에 메시지를 하나 던졌을 때, "컨슈머 A가 가져가면 컨슈머 B는 못 가져가게 할지", 아니면 **"A도 받고 B도 받게 할지"**가 아키텍처의 핵심입니다.1. 방식 1: 포인트 투 포인트 (Point-to-Point / Queue) - "선착순 1명"가장 전통적인 작업 큐(Worker Queue) 방식입니다. 생산자(Producer)가 큐에 메시지를 넣으면, 여러 소비자(Consumer) 중 오직 하나만 메시지를 가져가서 처리합니다.특징경쟁적 소비자(Competing Consumers): 소비자들은 메시지를 먼저 가져가기 위해 경쟁합니다. 한 번 소비된 메시지는 큐에서 사..

"통장에 잔액이 100만 원 있습니다. 그런데 이 돈이 월급이 들어와서 생긴 건지, 적금을 깨서 생긴 건지, 누가 보낸 건지 알 수 있나요?"전통적인 방식은 UPDATE 쿼리로 잔액을 바꿔버리기 때문에 **과거(Context)**가 사라집니다. 반면, 이벤트 소싱은 데이터를 절대 지우거나 수정하지 않고(Append Only), 모든 변경 사항을 '이벤트'로 기록하여 완벽한 감사(Audit) 로그를 남깁니다.1. 방식 1: 상태 저장 방식 (State-Oriented / CRUD) - "전통적인 덮어쓰기"우리가 흔히 사용하는 RDBMS 방식입니다. 현재 시점의 최신 데이터만 테이블에 유지합니다.특징UPDATE 위주: 데이터가 변경되면 기존 값을 덮어씁니다.스냅샷: DB에 있는 데이터는 항상 "지금 이 순간..

"우리 회사는 슬랙(Slack) 같은 서비스를 만듭니다. 삼성전자도 쓰고 LG전자도 씁니다. 두 회사의 데이터는 물리적으로 섞이면 안 될까요, 아니면 논리적으로만 구분하면 될까요?"멀티테넌시란 하나의 애플리케이션 인스턴스가 여러 사용자(Tenant)를 동시에 처리하는 아키텍처를 말합니다. 핵심은 **데이터 격리(Data Isolation)**입니다. 비용을 아끼기 위해 데이터를 합칠수록 개발 난이도와 보안 위험은 올라갑니다. 1. 방식 1: DB 분리 (Database per Tenant) - "최고의 보안, 최고의 비용"고객사마다 **별도의 데이터베이스(또는 스키마)**를 생성해 주는 방식입니다. 물리적으로 데이터가 섞일 일이 없습니다.특징완벽한 격리: A 고객사가 해킹당해도 B 고객사의 DB는 안전합..

API는 한 번 배포되면 **계약(Contract)**이 됩니다. 함부로 수정하면 클라이언트가 오작동합니다. 그래서 우리는 v1, v2를 만듭니다.하지만 이 버전 정보를 어디에 두느냐에 따라 API의 사용성(DX)과 캐싱 전략, 그리고 RESTful 원칙 준수 여부가 완전히 달라집니다.1. 방식 1: URI 버저닝 (URI / Path Versioning) - "가장 실용적인 접근"트위터, 페이스북, 구글 등 대다수의 **공용 API(Public API)**가 사용하는 방식입니다. URL 경로 자체에 버전 숫자를 박아버립니다.특징직관성: URL만 봐도 몇 번째 버전인지 알 수 있습니다.리소스 분리: v1/users와 v2/users는 아예 다른 자원 취급을 받습니다.코드 예시 (Spring Boot)Ja..

"사용자가 아이디/비번을 입력하고 로그인에 성공했습니다. 그런데 페이지를 이동할 때마다 아이디/비번을 계속 물어볼 순 없습니다. 이 사용자가 아까 그 사용자라는 것을 어떻게 기억해야 할까요?"HTTP는 상태가 없는(Stateless) 프로토콜입니다. 따라서 우리는 상태(State)를 유지하기 위한 기술이 필요합니다. 이때 "서버가 기억하느냐(Stateful)", **"클라이언트가 들고 다니느냐(Stateless)"**에 따라 시스템 구조가 완전히 달라집니다.1. 방식 1: 세션 기반 인증 (Session-based Auth) - "서버의 장부"전통적인 방식입니다. 서버가 메모리(또는 DB)에 **"누가 로그인했는지"**를 적어두고, 클라이언트에게는 그 장부의 **식별 번호(Session ID)**만 줍니..

"사용자가 1억 명이 넘었습니다. DB 서버 한 대로는 용량도 부족하고, 쓰기 트래픽을 감당할 수 없습니다."이때 해결책은 데이터를 여러 DB(Shard)에 나누어 담는 것입니다. 이를 **수평 분할(Horizontal Partitioning)**이라고 합니다. 핵심은 **"어떤 규칙으로 데이터를 나눌 것인가(Sharding Key)"**입니다. 이 규칙을 잘못 정하면 샤딩을 안 하느니만 못한 결과가 나옵니다.1. 방식 1: 레인지 샤딩 (Range Sharding) - "순서대로 차곡차곡"데이터를 특정 범위(Range)를 기준으로 나누는 방식입니다. 예를 들어 날짜별로 나누거나, ID(Primary Key) 순서대로 나눕니다.특징규칙: if (id 확장성: 데이터가 늘어나면 그냥 새로운 DB(DB_3)..

"새벽 1시에 정산 배치가 돌아야 하는데, 서버가 5대 떠 있습니다. 별도 처리를 안 하면 5대 모두가 정산을 시작해서 돈이 5배로 빠져나갑니다."분산 시스템에서는 "오직 하나의 인스턴스만 특정 작업을 수행하도록" 보장해야 할 때가 많습니다. 이를 위해 여러 서버 중 하나를 리더로 뽑아야 하는데, 이 투표소를 어디에 차리느냐가 핵심입니다.1. 방식 1: 락 기반 선출 (Lock-based) - "깃발 꽂기"가장 쉽고 흔한 방식입니다. Redis나 RDBMS 같은 외부 저장소를 이용해 **"가장 먼저 깃발을 꽂은(Lock을 획득한) 놈이 리더"**가 되는 방식입니다.특징선착순: SETNX(Redis)나 INSERT(DB)가 성공한 서버가 리더가 됩니다.TTL(Time To Live): 리더가 죽었을 때를 ..

"사용자가 '월간 리포트 생성' 버튼을 눌렀습니다. 이 작업은 3분이 걸립니다. HTTP 연결을 3분 동안 붙들고 있으면 브라우저나 로드 밸런서가 연결을 끊어버립니다(Time-out)."이런 상황에서는 일단 **"알겠어, 접수했어(202 Accepted)"**라고 응답하고 연결을 끊어야 합니다. 문제는 **"그 작업이 다 끝났는지 클라이언트가 어떻게 아는가?"**입니다.1. 방식 1: 폴링 (Polling) - "다 됐어요?"클라이언트가 서버에게 주기적으로 상태를 물어보는 방식입니다. 가장 기본적이고 구현하기 쉽습니다.동작 순서Client: POST /report 요청.Server: 작업을 큐에 넣고, 즉시 202 Accepted와 함께 상태 조회 URL(Location: /report/123/statu..

"우리 회사는 Java, Node.js, Go를 다 씁니다. 그런데 로그 포맷을 변경하려니 3가지 언어의 로깅 라이브러리를 모두 수정하고 배포해야 하네요?"마이크로서비스 환경에서는 모든 서비스가 인증, 로깅, 모니터링, 트레이싱 같은 공통 기능(횡단 관심사)을 가져야 합니다. 이걸 해결하기 위해 **"내 코드 안에 라이브러리를 넣는 방식"**과 **"내 컨테이너 옆에 도우미 프로세스를 띄우는 방식"**이 치열하게 경쟁합니다.1. 방식 1: 라이브러리/SDK 방식 (Fat Client) - "코드 내장형"전통적인 방식입니다. 공통 기능을 .jar나 npm package 형태의 라이브러리로 만들어서 각 마이크로서비스 프로젝트에 의존성으로 추가합니다. 넷플릭스 OSS(Eureka, Ribbon, Hystrix..

"이미지 업로드 기능이 느려져서 스레드가 다 묶였습니다. 그 때문에 텍스트만 조회하는 가벼운 게시판 기능까지 응답 불가(Timeout) 상태가 되었습니다."하나의 톰캣(Tomcat) 스레드 풀을 모든 API가 공유해서 쓰면 발생하는 전형적인 **연쇄 장애(Cascading Failure)**입니다. 이를 막기 위해 자원(스레드, 커넥션)을 구역별로 나누는 것이 벌크헤드 패턴입니다.Hystrix는 스레드 풀 방식을, Resilience4j는 세마포어 방식을 기본으로 채택했는데, 그 이유는 무엇일까요?1. 방식 1: 스레드 풀 격리 (Thread Pool Isolation) - "완벽한 물리적 분리"Netflix Hystrix가 유행시킨 방식입니다. 서비스 A 전용 스레드 풀, 서비스 B 전용 스레드 풀을 ..

과거의 온프레미스 환경에서는 서버 IP가 고정(192.168.0.10)되어 있어 설정 파일에 박아두면 그만이었습니다.하지만 클라우드(AWS, K8s) 환경에서는 컨테이너가 수시로 죽고 살아나며 IP가 **동적(Dynamic)**으로 바뀝니다.그래서 **"현재 살아있는 서버들의 목록(Service Registry)"**을 관리하는 전화번호부가 필요합니다. 중요한 건 이 전화번호부를 누가 보고 전화를 거느냐입니다.1. 방식 1: 클라이언트 사이드 디스커버리 (Client-side Discovery) - "능동적인 손님"Netflix Eureka가 대표적인 예시입니다. API를 호출하는 **클라이언트(요청자)**가 서비스 레지스트리(전화번호부)를 직접 조회해서, 사용 가능한 인스턴스 중 하나를 골라 호출합니다..

"API 호출이 실패했습니다. 0.1초 뒤에 다시 해보고, 또 실패하면 0.1초 뒤에 다시 해봤는데... 결국 서버가 트래픽 폭주로 완전히 뻗어버렸습니다."일시적인 네트워크 오류(Transient Fault)는 클라우드 환경에서 필연적입니다. 그래서 우리는 **재시도(Retry)**를 합니다. 하지만 실패한 요청 수천 개가 **똑같은 시간에 동시에 재시도를 감행(Thundering Herd)**하면, 간신히 살아나려던 서버를 다시 짓밟는 꼴이 됩니다.이를 막기 위한 두 가지 재시도 전략을 비교해 봅니다. 1. 방식 1: 고정 간격 재시도 (Fixed Backoff) - "꾸준함의 미학"가장 단순한 방식입니다. 실패하면 **항상 정해진 시간(예: 1초)**만큼 기다렸다가 다시 시도합니다.특징일정함: 1번째..

"서버 프로세스는 떠 있는데, DB 커넥션이 끊겨서 에러만 뱉고 있습니다. 로드 밸런서는 이걸 아는지 모르는지 계속 요청을 보내네요."운영 중인 서비스의 상태를 모니터링하기 위해 /health 같은 API를 만들어두곤 합니다. 하지만 이 API가 단순히 **"나 살아있어(200 OK)"**만 외쳐야 할까요, 아니면 **"DB도 연결됐고, 캐시도 정상이고, 디스크 공간도 충분해"**라고 보고해야 할까요?이 목적에 따라 헬스 체크는 엄격하게 두 가지로 나뉩니다.1. 방식 1: 라이브니스 체크 (Liveness Probe) - "생존 신고"**"프로세스가 살아있는가?"**를 확인합니다. 이 체크가 실패하면 시스템(K8s)은 애플리케이션을 재시작(Restart) 시킵니다.특징Shallow Check (얕은 검사..

"선착순 이벤트 때 매크로가 1초에 1,000번씩 새로고침을 눌러서 서버가 다운되었습니다.""특정 사용자가 API를 너무 많이 호출해서 다른 사용자가 이용을 못 합니다."이런 상황을 막기 위해 **단위 시간당 요청 횟수를 제한(Throttling)**하는 것이 처리율 제한 패턴입니다. API 게이트웨이나 미들웨어에서 주로 사용되는데, 알고리즘 선택에 따라 **"경계 시간의 트래픽 두 배 문제"**를 해결할 수도, 못 할 수도 있습니다.1. 방식 1: 고정 윈도우 카운터 (Fixed Window Counter) - "단순 무식"시간을 고정된 단위(예: 1분)로 나누고, 각 단위마다 카운터를 둡니다. 구현이 가장 쉽고 메모리를 적게 먹습니다.특징동작 원리: "12:00:00 ~ 12:00:59" 구간에 카운..

"회원 가입(INSERT)은 성공했는데, 가입 축하 메일 이벤트(send) 발송은 네트워크 오류로 실패했습니다. DB는 롤백해야 할까요?"DB 트랜잭션과 외부 메시지 큐(Kafka, RabbitMQ) 발행은 하나의 트랜잭션으로 묶을 수 없습니다(Dual Write Problem).이를 해결하기 위해 **"보내야 할 메시지도 일단 DB에 같이 저장(Commit)하고, 나중에 꺼내서 보내자"**는 것이 아웃박스 패턴입니다.핵심은 "DB에 저장된 메시지를 어떻게 꺼내서 브로커로 보낼 것인가?" 입니다.1. 방식 1: 폴링 퍼블리셔 (Polling Publisher) - "심플한 스케줄러"가장 직관적이고 구현하기 쉬운 방식입니다. 별도의 테이블(outbox)에 이벤트를 저장하고, 스케줄러가 주기적으로 이 테이블..

"글을 쓰는(Write) 횟수보다 글을 읽는(Read) 횟수가 1,000배는 더 많습니다."대부분의 시스템은 읽기 요청 트래픽이 쓰기 요청보다 압도적으로 많습니다. 그런데 우리는 보통 하나의 Member 객체로 회원 가입도 하고(Write), 회원 조회도 합니다(Read).이렇게 되면 조회 성능을 높이려다 데이터 무결성이 깨지거나, 쓰기 모델을 복잡하게 만들다 조회 성능이 떨어지는 딜레마에 빠집니다.이를 해결하기 위해 "명령(Create, Update, Delete)"과 "조회(Read)"를 아예 분리하는 것이 CQRS의 핵심입니다. 1. 방식 1: 논리적 CQRS (Logical Separation) - "코드만 분리"데이터베이스는 하나(Single DB)를 쓰지만, 애플리케이션 내부의 모델(Model..

"모바일 앱에서 메인 화면을 띄우려면 회원 정보, 주문 목록, 추천 상품, 알림 개수 API를 각각 4번 호출해야 합니다. LTE 환경에서는 너무 느려요."클라이언트가 수십 개의 마이크로서비스를 직접 호출하게 두면 보안, 인증, 네트워크 지연 등 헬게이트가 열립니다. 그래서 중간에 **관문(Gateway)**을 두어 요청을 통합하고 라우팅합니다.하지만 이 관문을 "모든 클라이언트가 같이 쓸지", 아니면 **"클라이언트별로 따로 만들지"**가 아키텍처의 유연성을 결정합니다. 1. 방식 1: 단일 중앙 게이트웨이 (Single Central Gateway) - "만능 해결사"Netflix Zuul(과거)이나 Spring Cloud Gateway처럼 하나의 거대한 게이트웨이가 모든 클라이언트(Web, iOS..

"유튜브 조회수나 인스타그램 '좋아요'처럼 1초에 수천 번 클릭이 일어나는 데이터를 매번 DB에 UPDATE 쿼리로 날리면 어떻게 될까요?"DB는 디스크 I/O가 발생하기 때문에 필연적으로 느립니다. 그래서 우리는 메모리 기반의 캐시(Redis, Memcached)를 앞에 둡니다. 하지만 캐시와 DB 사이의 데이터 동기화(Sync) 타이밍을 어떻게 잡느냐가 시스템의 성능을 결정짓습니다.1. 방식 1: 룩 어사이드 (Look Aside / Cache Aside) - "정석이자 표준"**"캐시를 옆(Aside)에 두고 필요할 때만 본다"**는 뜻으로, 엔터프라이즈 환경에서 가장 범용적으로 쓰이는 읽기 중심 전략입니다.동작 순서조회(Read):애플리케이션이 먼저 캐시를 찌릅니다.있으면(Cache Hit) 바로..

"결제 서비스가 응답하지 않아서 주문 서비스 스레드가 다 묶여버렸고, 결국 전체 시스템이 다운되었습니다." (연쇄 장애, Cascading Failure)우리 집 두꺼비집(누전 차단기)은 전력 과부하가 걸리면 딱! 하고 내려가서 가전제품을 보호합니다. 소프트웨어에서도 특정 서비스의 에러율이 치솟으면, 즉시 연결을 차단(Open)하고 '잠시 후에 다시 시도해봐'라고 빠르게 실패(Fail Fast) 처리하는 것이 서킷 브레이커의 핵심입니다.중요한 건 "도대체 언제 차단기를 내릴 것인가?" 입니다.1. 기본 개념: 3가지 상태서킷 브레이커는 신호등처럼 3가지 상태를 오가며 시스템을 보호합니다.Closed (닫힘/정상): 전기가 통하듯 정상적으로 요청을 보냅니다.Open (열림/차단): 에러율이 임계치를 넘으면..

"데이터를 저장할 때, user.save()가 직관적일까요, 아니면 repository.save(user)가 유지보수에 좋을까요?"데이터베이스의 테이블(Table)과 객체지향의 객체(Object)를 연결하는 ORM 기술은 크게 두 가지 철학으로 나뉩니다. "객체가 DB 기능까지 다 하는 만능(Smart)이냐", 아니면 **"객체는 데이터만 담고 DB 로직은 분리(Dumb)하느냐"**의 싸움입니다.1. 방식 1: 액티브 레코드 (Active Record) - "똑똑한 객체"Ruby on Rails, Django, Node.js(Sequelize, TypeORM 일부) 등 스크립트 언어 진영에서 주로 사용하는 방식입니다. 객체(Entity)가 데이터와 함께 CRUD 메서드(save, delete)를 모두 가..

"주문 서비스, 결제 서비스, 배송 서비스가 모두 다른 DB를 씁니다. 결제는 성공했는데 배송 DB 저장에 실패하면 어떡하죠? 결제도 취소해야 하는데..."과거의 모놀리식 시스템에서는 DB가 하나라 Transaction.rollback() 한 방이면 끝났습니다. 하지만 MSA에서는 불가능합니다. 그래서 **"실패하면 되돌리는 로직(보상 트랜잭션)을 순차적으로 실행하자"**는 것이 사가 패턴입니다.이 순서를 누가 관리하느냐에 따라 구현 방식이 완전히 달라집니다.1. 방식 1: 코레오그래피 (Choreography) - "자율적인 댄서들"각 서비스가 **이벤트(Event)**를 주고받으며 스스로 다음에 할 일을 결정하는 방식입니다. 중앙 관리자가 없고, 무용수들이 서로 눈빛을 교환하며 춤을 추듯 동작합니다...

"게시판 1페이지 조회는 0.01초 걸리는데, 10,000페이지 조회는 왜 3초가 걸릴까요?"데이터베이스에서 수백만 건의 데이터를 한 번에 가져오는 것은 자살행위입니다. 그래서 우리는 데이터를 잘라서(Paging) 가져옵니다. 하지만 우리가 흔히 쓰는 오프셋 방식은 데이터가 많아질수록 치명적인 성능 저하를 일으킵니다. 이를 해결하기 위해 등장한 것이 커서(No-Offset) 방식입니다.1. 방식 1: 오프셋 페이지네이션 (Offset Pagination) - "전통의 강자"우리가 게시판 하단에서 흔히 보는 [1] [2] [3] ... [10] 형태의 UI를 구현할 때 사용하는 방식입니다. SQL의 OFFSET과 LIMIT 문법을 사용합니다.특징페이지 번호 이동: 사용자가 5페이지에서 100페이지로 바로 ..