기술 여행~ 창작 여행~

Spec-kit 시작하기 #1

개발짜맠 — Thu, 9 Apr 2026 23:40:08 +0900

요즘 나같이 늙은 개발자들은 좀 무서울것이다. AI 발전속도 때문에 배워야 하는데, 업무는 바쁘고

신경써서 책임져야 하는 일은 많고..

AI 좀 볼라 치면 이해는 가는데 잘 안들어오기도 하고..

나랑같이 한번 시작해보자. 나도 잘 모르니까 혹시 엇나가는 부분이 있으면 댓글로 혼내주면 반영하겠다.

Spec-Kit 은 SDD(Spec Driven Develop) 를 위한 프레임워크(Tool-Kit) 으로 Github 이 공개했다.

AI 기반으로 개발을 하는데, 바이브코딩은 맥락 유지의 한계가 있으니 스펙을 정의하고, 그 스펙을 기반으로 LLM 에게

일을 시켜보자.

1. Intelij 에서 Cladue Plugin 을 설치한다.

- 파일 > 설정 > 플러그인 > Claude code[beta] 설치

2. Intelij 에서 Claude 를 실행한다.

- 우측상단의 Claude 아이콘을 누르면 터미널 옆에 새 탭으로 Claude 가 뜬다.

3. Claude 터미널에서 아래를 입력한다.

> uv tool install specify-cli --from git+https://github.com/github/spec-kit.git


# 당신의 IDE 에 따라 골라주세용~
> specify init . --ai claude --force

> specify init . --ai claude  --force     # Claude Code
> specify init . --ai copilot --force     # GitHub Copilot
> specify init . --ai cursor  --force     # Cursor
> specify init . --ai windsurf --force    # Windsurf
> specify init . --ai gemini  --force     # Gemini CLI

우리는 지금 Intellij 를 쓰고 있다. 그리고 claude 를 쓰고있다.

그러니까

> uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

> specify init . --ai claude --force # Claude Code

이걸 입력하자

빈프로젝트는 빠르지만 , 뭔가 구성이 많은 프로젝트는 프로젝트를 스캔후에 내용을 포함하여 생성되니 유의하자.

만약 uvx 가 없다면 아래를 진행하자.

macOS / Linux

bash

curl -LsSf https://astral.sh/uv/install.sh | sh

Windows

powershell

powershell
Set-ExecutionPolicy RemoteSigned -scope CurrentUser
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.sh | iex"

그리고 다시 명령어를 실행하면,

CLAUDE.md
.claude/skills/speckit-analyze
.claude/skills/speckit-어쩌구..
...
...
.specify/extensions
.specify/intergrations
....

같은 디렉토리와 파일이 생겼을 것이다.

이전 버전의 spec-kit 의 경우

./claude/command/speckit-clearfy.md 등의

디렉토리에 명령어별 md 파일이 생성되어 , 자신이 직접

> /speckit-clearfy "유저정보 crud api 개발"

같이 커맨드 중심으로 해줘야 했다.

그러나 최신버전의 speckit 은 이걸 AI 사용 룰 답지 못하다고 생각했는지,

커맨드는 그냥 사용자가 치는 맥락을 LLM 이 알아서 이해하고 커맨드 역할을 실행하도록 대체하고, skills 중심으로 업데이트 되었다.

이거야 말로 희소식이고, 정말 내블로그 라서 하는 소리가 아니고 진짜 예상했던 바다.

많이 어렵진 않지만 구성이 조금 복잡하여 sdd 장벽이 높은감이 있었기도 했다.

다음글에서 계속..

Kinesis 사용기

개발짜맠 — Thu, 9 Apr 2026 21:33:51 +0900

Kinesis 는 Kafka랑 뭐 비슷하겠지

처음에 Amazon Kinesis 를 붙일 때는 되게 가벼운 마음이었다.
AWS 안에서 해결되고, 따로 브로커 신경 안 써도 되고, 그냥 넣으면 흘러가는 구조니까.

비슷한 계열인 Apache Kafka 는 직접 설치 구성해서 오래동안 컨피그 하나하나 설정해가며

주키퍼랑 같이 디테일하게 운영해 봤던 관계로, Kinesis 정도야 금방 익숙해지겠지 하고 접근했다.

문제는 실제로 데이터 저장하고 Consumer 를 붙히기 시작하면서 부터 였다.

On-Demand mode 에서 Kinesis 는 초당 처리량에 따라 자동으로 Shard 를 증가시킨다. 그래서 ingest 규모가 커지면 순식간에 Shard 가 50개~ 100 개~ 200개~ 막 늘어난다.

이 Shard 수는 개발자가 제어할 수 가없다. 이게 데이터 소비할때 Kafka 와 큰 차이를 만들어 낸다.

Provisoned Mode 는 샤드고정이라 좋기는한데 많이 쓰지 않아도 Shard 수만큼 고정비용을 무조건 내야한다.

또 Provisioned Mode 라 해도 어차피 처리 한계량 ( 1 MB/s 또는 1,000 records/s) 이 있어 트래픽이 많다면 위험할 수 있다.

이 글에서는 On-Demand 를 사용했을때에 대해 이야기한다.

Kinesis 즉시 소비를 요하는 스트리밍 Queue

Kafka 시나리오를 보자.

클러스터 노드수, 디스크량, 컨슈머 수 등을 고려하여 Queue 의 파티션을 생성한다.

데이터를 저장하면 고정된 파티션에 저장되고, Consumer 는 파티션 개수만큼 붙어 순차적으로 데이터를 가져온다.

만약 컨슈머 하나가 파티션 2개를 담당하게 되더라도, 파티션 2개만큼 스레드가 생성되 동시에 fetch 하는게 아니라,

하나의 스레드가 2개 파티션에서 한번의 fetch 개수 만큼 나눠서 가져와 제어가 가능했다 ( 물론 옵션을 통해 동시 처리 스레드를 늘릴수 있었다. )

그런데 Kinesis 는 Shard 가 자동으로 늘어나는 구조라고 했다.

(게다가, 트래픽 확장을 고려하면 고정모드로 쓰는것도 무서우니)

그러니까 Consumer 를 전략적으로 운영할 수 가없는것이다.

Shard 개수만큼 Consumer 의 워커 스레드를 강제로 생성하고 동시에 fetch 한다.

AWS SDK Kinesis 옵션을 살펴보면, 이걸 제한할 옵션도 지원하지 않는다.

(최근 버전이었는데 아마 지금도 그럴것이다 )

보통 AWS Kinesis SDK 를 사용하니, Shard 수가 250 개라면, 컨슈머가 붙는 순간 컨슈머의 워커 스레드가 250개가 생성되어

동시에 fetch 한다...

정말 난감한 순간이었다.

보통은 fetch 문제가 아니라, 그걸 가공하여 다음 스텝으로 던져줘야 하므로,

다음 스텝의 인프라가 소형이거나 받아줄수 없다면 문제가 될수 밖에 없다.

Message Push, Event 알림, 채팅에 적합

만약 이러한 유형의 비즈니스라면 참 괜찮았을 것이다.

Consume 받은 메시지를 Virtual Thread 로 I/O 를 동시 다발적으로 처리해버리면 아름답게

대량의 데이터를 처리할 수 있엇을 것이다.

( 아 물론 개념적으로 말이 그렇다는거다. )

그러나 사정상 처리 결과를 받는 최종 목적지가 소형이었고 Queue 를 바꿀수도 없는 상황이라

Semapore Global Lock 으로 어쩔수 없이 울며겨자 먹기로 제어를 했다.

컨슈머 스레드의 시작 지점에 Global Lock 개수를 제한하여 대기후, 정해진 스레드만 동작하도록 한것이다.

만약 Kinesis Consumer 를 구현하게 된다면 이게 무슨말이고 어디에 구현해야 되는지 알게 될것이다.

난 분명 이러한 이유로 Kafka 를 사용하려고 했지만 여러 사정상 어쩔수 없이 Kinesis 를 써야만 했다...

하지만 이러한 제약사항에도 불구하고 코드 자체는 아름답게 짰으니 다행이라면 다행일까?

이러한 문제로 Shutdown 시 이벤트를 받아 Lock 으로 인한 대기열 스레드가 모두 소진되면 그때서야 종료되도록 처리 했다.

물론 갑자기 서버가 죽으면 날라간다.. ( 뭐 그건 다른 Queue 도... 하지만 좀더 손실 범위가 적으니.. )

다들 알겠지만 혹시나 Kinesis 를 선택할때 이러한 특성을 한번쯤 확인해 도움이 되었으면 좋겠다.

ClickHouse 장점

개발짜맠 — Thu, 9 Apr 2026 20:55:24 +0900

최근 나는 ClickHouse 를 쓰고 있다.

거의 빠돌이 수준이다.
이걸 왜 이제야 썼나 싶을 정도로 만족도가 높다.

물론 단점도 있다.
Self-Host 기준으로는 동적 노드 추가가 꽤 불편하다.

그래서 지금은 SaaS로 쓰고 있다.

그럼에도 불구하고 계속 쓰는 이유?
실제로 써보면 답 나온다.

내가 느낀 ClickHouse 장점

1. Object Storage 기반 구조 (진짜 큼)

기존 OpenSearch 나 Apache Solr 는

“노드 = 데이터 책임” 구조다

그래서:

노드 늘리면 → 데이터 리밸런싱
노드 줄이면 → 위험

근데 ClickHouse는 (특히 S3 기반 구조에서는)

- 노드가 데이터를 들고 있지 않는다
- 필요할 때만 붙였다 떼는 구조가 가능하다

그래서:

트래픽 많을 때만 노드 늘리고
평소엔 줄여도 문제 없음

비용 효율이 확실히 다르다

※ 정확히 말하면 “완전한 stateless는 아니지만”
실무에서는 거의 그렇게 느껴진다

2. 데이터 ingest 속도

이건 진짜 써보면 놀란다

로그 밀어 넣는 속도
batch insert
스트리밍 ingest

다 빠르다

Kafka 붙여서 써보면
“이게 DB 맞나?” 싶을 정도로 잘 받아먹는다

3. 컬럼 기반 = 초대용량 쿼리 성능

이건 설명보다 체감이다

수억 / 수십억 건
group by
aggregation

그냥 빠르다 (그렇다고 수십억건의 Range 쿼리를 0.0... 초내를 기대하진 말자...)

기존 RDB에서 튜닝하던 감각으로 보면
거의 다른 세계다

4. 엔진 구조 하나로 대부분 커버

ClickHouse는 단순 DB가 아니라
“엔진 선택형 시스템”에 가깝다

MergeTree → 기본
Replacing / Aggregating / Summing
로그성 데이터
시계열 집계

이거 하나로

로그 분석
통계 시스템
간단한 데이터 웨어하우스

대부분 커버 가능하다

매뉴얼이 잘되있어 필요한 비즈니스별 엔진 선택을 하면 된다.

5. Materialized View = 진짜 사기급

이건 핵심이다

Materialized View
Refreshable View (최근 기능)
다양한 집계 구조

실제로:

수백만 ~ 수천만 건 집계
지속적으로 돌아가는 MV

CPU / Memory 크게 안 튄다

이게 왜 가능하냐면
insert 시점에 미리 계산해버리기 때문이다.

무슨 말이냐면... 예를들어 1,000 건의 Row 가 새로 저장되면, 그 데이터를 기준으로 MV 가 수행된다.

단, 하나 짚고 가야 한다

조회 쿼리는 결국 리소스를 쓴다

복잡한 쿼리
대용량 scan

이건 사양 따라 그대로 비용 나간다

6. Full Text Search (최근 추가)

최근 버전에서
Tokenizer 기반 Full Text Search가 들어왔다

아직 SaaS에서는 버전업이 안되었다.

이게 의미하는 건 크다

이제는

로그 검색
간단한 검색 시스템

정도는 굳이 외부 검색엔진 안 써도 될 가능성

물론 아직은 전문 검색엔진 완전 대체하지 못한다. Inverted Index 만 지원할 뿐이다.

Phase Index ( 주어진 문자열의 순서까지 지켜가며 검색 ) 등은 아직 지원되지 않는다.

그래도 방향성은 명확하다

“ClickHouse 하나로 끝내려는 움직임”

결론

ClickHouse는

완벽한 시스템은 아니다
운영도 쉽다고 말하긴 어렵다

근데

성능 + 유연성 + 확장성

이 3개를 같이 가져가는 순간
다른 선택지가 잘 안 보인다.

최근에 Linkedin 댓글에서 QuickWit 엔진에 대한 찬양글을 봐서 관심이 깊었으나.. 일단 먼저 친해진

ClickHouse 랑 좀 더 놀면서 바람을 좀 피워봐야 겠다.

QuickWit 찬양글의 핵심중에 하나는 Full Text Search 를 지원한다 였는데, 이제 뭐 Clickhouse 도 지원하니까..

모듈러 모노리스(Modular Monolith) 아키텍처와 도메인 간의 통신, 그리고 헥사고날 아키텍처

개발짜맠 — Thu, 9 Apr 2026 17:34:35 +0900

모듈러 모노리스에서 도메인 간 통신을 어떻게 할까?

모놀리식은 처음엔 정말 편하다.
빠르게 만들 수 있고, 한 번에 다 돌아간다.

그러나 규모가 점점커지면 도메인간 의존성이 얽히기 시작한다.

이문제를 해결하고 나온 마이크로 서비스 아키텍처.

2010년 후반부터 광풍이 일기 시작했고, 대표적으로 Netflix 가 자신들의 아키텍처를 공개하면서 많은 기업들이 따라하기 시작했다.

Netflix OSS 기반 MSA 는 구조적으로는 아름다웠다.

도메인 간 경계를 세부적으로 쪼개고, 도메인간 통신은 Client Side Loadbalancing 을 통해 제어했다. (꼭 Netflix OSS 기반, Client Side LB 가 아니라도 대게 마찬가지다.)

또 동적 노드 추가로 언제든 트래픽이 몰리는 도메인을 쉽게 증설할수 있었다.

그러나...

그 철학으로 따라가다 보면, 서비스를 운영하기 위해 너무나 많은 도메인, 노드를 운영해야 했다.

트래픽이 거의 없는 도메인 및 노드도 최소한의 자원은 할당해야 했으며, 당연히 git 으로 관리해야할 프로젝트도 그만큼 늘어났다.

아름다웠지만, 너무 비싼 녀석이었다... Netflix 만큼 모든 도메인이 많은 트래픽이 많지도 않았다.

또 나의 경우에는 서비스 규모에 비해 복잡한 비즈니스를 구현했어야 하는데, 그러다 보니 100개가 넘는 도메인을 각각 개발하고 관리해야 했다. 글로벌 기업수준도 아닌데 이건...

이러한 문제점을 보완하기 위해 최근 각광받는 Mono Repo, 그리고 Modular Monolith,

이 글은 모듈러 모노리스에 대한 이야기를 해보고자 한다.

(참고로 나는 Mono Repo 스타일은 별로 좋아하지 않는다. )

도메인이 늘어나기 시작하면
자연스럽게 이런 코드가 생긴다.

Order가 Payment를 직접 호출하고
Payment가 다시 Inventory를 건드리고
어느 순간 서로가 서로를 참조한다

처음엔 단순한 “함수 호출”이었는데,
나중엔 얽히고설킨 의존성 덩어리가 된다.

그리고 이 시점에서 대부분 이렇게 생각한다.

“헥사고날 아키텍처 쓰면 해결되는 거 아니야?”

헥사고날 아키텍처로 도메인을 서로 외부 경계로 바라본다면

Port / Adapter 구조를 도입하면
도메인 간 통신을 마치 외부 시스템처럼 다룰 수 있다.

예를 들면:

Order → PaymentPort (인터페이스)
PaymentAdapter → 실제 구현

이렇게 하면 나중에
HTTP, gRPC, 메시지 기반으로 바꾸기도 쉬워진다.

딱 봐도 “MSA 전환 준비 완료” 느낌이다.

근데 여기서 함정이 있다.

문제는 기술이 아니라 구조다

Port/Adapter를 쓰면 미래 대비가 된다고 생각한다

하지만 좀더 중요한 요소가 있다.

미래에 시스템을 쪼갤 수 있느냐는
Port가 아니라 “도메인 구조”가 결정한다.

진짜 중요한 4가지

1. 의존 방향은 무조건 단방향

Order → Payment (O)
Payment → Order (X)

순환 의존이 생기는 순간
그 도메인은 절대 분리할 수 없다.

2. 상태 공유하지 않기

같은 DB 테이블을 같이 쓰거나
서로 join해서 데이터 가져오기 시작하면

이미 한 몸이다.

나중에 분리? 거의 불가능하다.

3. 느슨한 결합은 이벤트로

OrderCreated → Payment 처리

이벤트 기반으로 바꾸는 순간
도메인 간 결합도가 확 낮아진다.

4. 진짜 분리될 도메인만 Port/Adapter

모든 걸 Port로 감싸는 건 오버엔지니어링이다. 게다가 CRQS 개념 분리까지 생각하면 Port, Adapter 천국이 될 수 있다.

대신 이렇게 생각하자.

“이 도메인은 나중에 진짜 따로 나갈 가능성이 높은가?”

결제
인증
알림

이런 영역만 Port/Adapter로 감싸면 된다.

그래서 결론은

모듈러 모놀리스에서 중요한 건
“지금부터 분산 시스템처럼 만드는 것”이 아니다.

나중에 분리할 수 있는 구조를 만드는 것

정리하면 딱 이거다.

도메인 간 통신은 단순하게 Service 호출
느슨한 결합은 이벤트로 해결
의존성은 단방향 유지
상태는 절대 공유하지 않기
정말 필요한 곳만 Port/Adapter 적용

한 줄 정리

미래를 대비한다는 건 기술을 추가하는 게 아니라,
구조를 망치지 않는 것이다

모놀리식 아키텍처, 모듈러 모노리스, 헥사고날 아키텍처, Port Adapter, 도메인 설계, MSA 전환, 이벤트 기반 아키텍처

AI 시대 경제 시스템 구상

개발짜맠 — Tue, 7 Apr 2026 17:07:53 +0900

0. 목표

다가오는 시대는 AI와 자동화로 인해 인간 노동의 가치가 급격히 낮아질 가능성이 크다.
이 변화 속에서 다음과 같은 문제를 해결해야 한다.

노동 가치 하락 시대에서 시민을 보호할 것
AI 기술을 가진 특정 기업의 권력 독점을 방지할 것
국가가 경제 발전의 동기를 잃지 않도록 할 것
우주를 단순한 탐사가 아닌, 명확한 산업적 목표로 재정의할 것

1. 개요

이 시스템은 정부, 기업, 시민, 그리고 자원(전력/우주)이 연결된 구조를 가진다.

정부

전력 및 자원 인프라 투자 및 확보
토큰 발행 기준 설계
시장 안정화 및 규제

기업

AI / 로봇 / 기술 제공자
토큰을 대가로 생산 활동 수행
생산 결과물을 요청자에게 제공

시민

생산 요청
전력 절약 및 공유
참여 기반 활동

토큰

생산 요청권 + 참여 보상 수단
전력 및 물리적 자원을 기반으로 발행되는 자산

목적

생산 · 기술 · 자원 · 토큰이 순환하는 지속 가능한 경제 구조 구축

2. 토큰 발생 구조

2.1 지구 기반 토큰

정부
- 발전소, 전력망, 저장 시스템 구축
- 전력 생산량 기준으로 토큰 발행 정책 설정
시민
- 전력 절약 및 잉여 전력 공유 → 토큰 획득
기업
- 기술을 통해 전력 효율 향상 → 토큰 보상

2.2 우주 자원 기반 토큰

정부 / 국제기구
- 초기 탐사 투자
- 자원 소유권 및 가치 기준 정의
기업
- 우주 탐사 및 자원 채굴
- 확보한 자원을 기반으로 토큰 발행

즉, 우주 탐사는
“위상 경쟁”이 아니라
명확한 경제 활동 (자원 확보 산업)이 된다.

3. 핵심 구조: 생산의 흐름

이 시스템에서 가장 중요한 것은 기업의 역할 정의다.

생산 흐름

시민 / 정부 / 기업이 생산을 요청한다
요청자는 토큰을 지불한다
기업은 기술(AI, 로봇)을 제공하여 생산을 수행한다
정부로부터 전력을 공급받아 생산 활동을 진행한다
생산된 결과물은 요청자에게 귀속된다
기업은 기술 제공의 대가로 토큰을 획득한다

핵심 포인트

기업은 생산물을 소유하지 않는다
기업은 기술 제공자이자 실행자다
생산 결과는 항상 요청자(시민/정부/기업)에게 돌아간다

즉,

“기업 = 소유자가 아니라 생산을 수행하는 기술 주체”

4. 상호작용 구조

정부

인프라 제공
규칙 설계
시장 안정화

기업

기술 개발
생산 수행
효율 경쟁

시민

전력 절약 및 공유
토큰 확보
생산 수요 창출

자원

전력 및 우주 자원
토큰 가치의 근본 기반

5. 경쟁 및 발전 메커니즘

5.1 기업 경쟁

더 효율적인 기술 개발 → 더 많은 토큰 확보
글로벌 진출 → 다양한 자원 접근
생산 효율을 높이기 위한 지속적 기술 혁신

5.2 시민 경쟁

전력 절약 및 공유 참여
커뮤니티 기반 협력
토큰 확보를 통한 생산 요청 능력 강화

5.3 국가 경쟁

전력 생산 능력
에너지 효율
우주 자원 확보 능력

국가의 인프라 수준이 곧 경제력

5.4 글로벌 구조

기업 간 경쟁은 유지되지만
자원과 토큰은 정부와 시민 기반

기업 단독 독점 불가능

6. 정부의 핵심 역할

6.1 인프라 투자자

전력 생산 및 저장 시스템 구축
우주 탐사 기반 시설 투자

6.2 규칙 설계자

토큰 발행 기준 정의
기업 참여 조건 설정
시민 보상 구조 설계

6.3 시장 안정 장치

토큰 가치 급변 시 개입
전력 수급 조절
시스템 붕괴 방지

7. 장점

기업 권력 독점 구조 방지
시민 참여 기반 경제
국가 경제 주권 유지
기술 발전 동기 유지
환경 절약과 경제적 보상 연결
우주 탐사의 명확한 산업화

8. 고려사항

토큰 발행과 자원 간 균형 유지
정부 개입과 시장 자율성의 균형
국가 간 자원 격차 문제
우주 자원에 대한 국제 규범 필요
시스템 투명성 확보

결론

이 구조는 기존 자본주의를 부정하는 것이 아니다.

오히려
자본주의를 “자원 기반”으로 재구성하는 시도다.

기업은 소유가 아니라 기술로 경쟁하고
시민은 참여를 통해 권한을 얻으며
정부는 시스템을 설계하고 안정화한다

그리고

우주는 더 이상 막연한 미래가 아니라
명확한 경제 활동의 영역이 된다.

이것은 아직 완성된 답이 아니라,
하나의 방향성이다.

하지만 분명한 것은,
AI 시대에는 기존 경제 구조만으로는
지속 가능하지 않다는 점이다.

ClickHouse 로 시계열 통계 구축

개발짜맠 — Thu, 12 Mar 2026 15:20:36 +0900

ClickHouse로 대규모 시계열 집계 파이프라인 설계하기

실시간 통계 API를 위한 멀티 테넌트 분석 아키텍처

왜 ClickHouse인가

MySQL 같은 RDB는 트랜잭션 처리에 최적화되어 있다. 행 단위로 데이터를 읽고 쓰는 구조이기 때문에, 수천만 건의 로그를 집계하는 분석 쿼리에는 태생적으로 불리하다. 테넌트 수가 늘고 데이터 규모가 커질수록 이 한계는 선명하게 드러난다.

ClickHouse는 열 지향(columnar) 스토리지를 기반으로 하며, 집계 연산에 특화된 엔진들을 제공한다. 같은 쿼리를 RDB 대비 수십 배 빠르게 처리하는 것이 가능하다. 분석용 파이프라인의 핵심 저장소로 적합한 이유다.

전체 파이프라인 구조

Raw Ingest
    ↓
Materialized Views (실시간 변환)
    ↓
MINUTE 집계 테이블
    ↓
HOUR / DAY / MONTH 집계 테이블 (계층적 롤업)

핵심은 "한 번 적재, 다단계 집계" 다. 원본 데이터를 그대로 쌓아두는 것이 아니라, Materialized View가 ingest 시점에 바로 변환하여 각 시간 단위 집계 테이블로 흘려보낸다. 쿼리 시점의 부하를 적재 시점으로 분산시키는 구조다.

테이블 엔진 선택

SummingMergeTree — 일반 집계용

SummingMergeTree는 동일한 Primary Key를 가진 row를 백그라운드에서 자동으로 합산한다. INSERT가 발생하면 일단 별도 파트로 저장되고, 이후 백그라운드 프로세스가 같은 Key의 파트들을 병합하며 값을 누적한다. 카운트, 합계 같은 단순 집계 지표를 저장하는 테이블에 적합하다.

멀티 테넌트 환경에서는 SharedSummingMergeTree를 사용한다. ClickHouse Cloud나 Shared 클러스터 구성에서 여러 노드가 스토리지를 공유하는 방식이다.

ReplacingMergeTree — Top-N 랭킹용

ReplacingMergeTree는 같은 Key에 대해 가장 최근 row만 남긴다. "최신 값으로 교체"가 필요한 순위 데이터에 적합하다.

Top-N 테이블은 SharedReplacingMergeTree와 Refreshable Materialized View를 조합해 구성한다. Refreshable MV가 주기적으로 집계 결과를 다시 계산하고, 결과를 Top-N 테이블에 덮어쓰는 방식이다.

ORDER BY 설계

ORDER BY (tenantId, code, timestamp, statValue)

시계열 데이터라고 해서 무조건 시간을 앞에 두는 것이 최선은 아니다. ClickHouse의 Primary Key는 ORDER BY와 동일하게 구성되며, 앞에 배치된 컬럼일수록 범위 스캔이 효율적으로 동작한다.

실제 쿼리 패턴을 보면 "어떤 지표를" → "어느 기간에" 순으로 조건이 걸리는 경우가 압도적이다. 지표 코드(code)를 시간(timestamp)보다 앞에 두는 이유다. 시간 필터는 PARTITION BY를 통한 파티션 프루닝으로 처리하면 충분하다.

SummingMergeTree의 단편화 문제

SummingMergeTree를 실제로 운용하면 반드시 마주치는 문제가 있다. 백그라운드 merge가 완료되기 전까지는 같은 Key의 row가 여러 파트에 분산되어 존재한다. 즉, 쿼리 시점에 아직 합산되지 않은 중간 상태 데이터가 함께 읽힐 수 있다.

FINAL 키워드는 왜 쓰면 안 되나

SELECT * FROM stats_table FINAL WHERE ...

FINAL은 쿼리 시점에 강제로 merge를 수행해 정확한 값을 반환한다. 언뜻 깔끔한 해결책처럼 보이지만, 내부적으로 전체 데이터를 재정렬하고 병합하는 작업이 발생한다. 대용량 테이블에서는 쿼리 하나가 시스템 전체에 부하를 줄 수 있다. 특히 여러 테넌트가 동시에 쿼리를 날리는 멀티 테넌트 환경에서는 사용하기 어렵다.

View + GROUP BY로 해결

CREATE VIEW v_stats AS
SELECT
    tenantId,
    code,
    timestamp,
    sum(value) AS value
FROM stats_table
GROUP BY tenantId, code, timestamp;

쿼리 소비자가 항상 View를 통해 조회하도록 하면, View의 GROUP BY가 단편화된 데이터를 투명하게 합산해준다. FINAL보다 훨씬 빠르고, 테이블 구현 세부사항을 API 레이어로부터 완전히 분리할 수 있다.

왜 시간 단위별로 테이블을 분리하는가

가장 먼저 드는 의문은 "그냥 하나의 테이블에 다 넣고 쿼리할 때 GROUP BY로 조절하면 안 되나?" 다.

기술적으로는 가능하다. 하지만 분 단위 원본 데이터를 그대로 보관하면서 월 단위 집계 쿼리를 날리는 상황을 생각해보면 문제가 명확해진다. 하루 1억 건의 분 단위 데이터가 쌓이는 환경에서 "이번 달 집계"를 구하려면 수십억 건을 매번 스캔해야 한다. 멀티 테넌트 환경에서 이런 쿼리가 동시에 수십 개 날아온다면 시스템은 버티기 어렵다.

테이블을 시간 단위별로 분리하는 이유는 세 가지다.

스토리지 효율. 분 단위 데이터는 빠르게 만료시키고, 시간/일/월 단위로 올라갈수록 오래 보존한다. 하나의 테이블로 관리하면 TTL 정책을 세밀하게 적용하기 어렵다. 테이블을 분리하면 각 단위별로 독립적인 보존 정책을 가질 수 있다.

쿼리 성능. 월간 집계 쿼리는 월 테이블만 읽으면 된다. 분 단위 테이블에는 접근조차 하지 않는다. 테이블 자체의 크기가 작으니 스캔 비용이 줄고, 캐시 효율도 높아진다.

집계 정확성. 분 단위 데이터로부터 시간 단위를 실시간으로 계산하면 SummingMergeTree의 단편화 문제가 중첩된다. 각 단위별로 이미 집계된 테이블을 별도로 유지하면, 상위 단위 쿼리는 항상 이미 정리된 데이터를 읽는다.

결국 "저장은 한 번, 집계는 미리"라는 원칙이 테이블 분리로 이어진다. 적재 시점에 Materialized View가 각 집계 단위 테이블로 동시에 흘려보내기 때문에, 운영 복잡도 증가 없이 각 단위별 최적화된 테이블을 유지할 수 있다.

계층적 롤업

집계 단위마다 별도 테이블을 두고, 데이터 흐름은 아래와 같이 구성한다.

원본 단위반영 대상

MINUTE	MINUTE / HOUR / DAY / MONTH
HOUR	HOUR / DAY / MONTH
DAY	DAY / MONTH
MONTH	MONTH

분 단위 원본 데이터가 있다면 모든 집계 테이블에 반영된다. 시간 단위 데이터만 있다면 HOUR 이상에만 반영된다. 지표마다 어떤 granularity를 지원하는지는 메타데이터로 관리하며, 파이프라인은 이를 참조해 해당 테이블에만 적재한다.

고카디널리티 지표: Dual-Path 설계

고유값이 많은(High-Cardinality) 지표는 단순 SUM으로 처리할 수 없다. 기간을 나눠 집계한 값들을 다시 합산하면 중복이 발생하기 때문이다.

이 경우 파이프라인을 두 갈래로 나눈다.

Raw Ingest
    ├─→ [단기 TTL] Raw 집계 테이블  ──→  Top-N Ranking 테이블 (장기 보존)
    └─→ [일반] 집계 테이블

Raw 집계 테이블은 짧은 TTL로 원본에 가까운 데이터를 유지한다. Refreshable Materialized View가 이 데이터를 주기적으로 읽어 Top-N을 계산하고, 결과를 SharedReplacingMergeTree 기반의 랭킹 테이블에 저장한다. 랭킹 테이블은 긴 보존 기간을 가지며, API가 직접 서빙한다.

TTL 이중 관리

보존 기간이 다른 데이터가 한 파이프라인 안에 공존할 때, TTL 컬럼을 목적에 따라 분리하면 유연하게 관리할 수 있다.

ingestTtlDate Date,  -- 단기 만료 (ingest 원본 데이터 정리용)
ttlDate       Date,  -- 장기 보존 (집계 결과, 랭킹 데이터)

ingestTtlDate는 빠르게 만료시켜 스토리지를 확보하고, ttlDate는 장기 보존이 필요한 집계 결과에 적용한다. 하나의 TTL 정책으로 모든 데이터를 관리하려 하면, 어느 한쪽이 너무 짧거나 너무 길어지는 딜레마가 생긴다.

메타데이터 기반 확장

새 지표를 추가할 때마다 코드를 수정하고 배포하는 구조는 운영 부담이 크다. 지표의 속성(어떤 집계 단위를 지원하는지, 어떤 테이블을 참조하는지 등)을 메타데이터로 정의하고, 파이프라인과 API가 이를 참조해 동적으로 동작하면 코드 변경 없이 지표를 추가할 수 있다.

ClickHouse 테이블 구조 자체는 범용적으로 유지하되, 지표의 의미와 동작 방식은 메타데이터가 결정하는 구조다.

정리

문제접근

RDB 집계 성능 한계	ClickHouse 열 지향 스토리지로 전환
SummingMergeTree 단편화	View + GROUP BY 레이어
FINAL 성능 비용	View로 추상화, FINAL 미사용
고카디널리티 지표	Dual-Path + Refreshable MV
TTL 정책 충돌	컬럼 분리 (ingestTtlDate / ttlDate)
지표 확장성	메타데이터 기반 동적 구성

ClickHouse는 분석 워크로드에서 강력하지만, SummingMergeTree의 단편화나 FINAL의 숨겨진 비용처럼 직접 부딪혀봐야 알 수 있는 특성들이 있다. 설계 단계에서 이 특성들을 이해하고 구조에 반영하는 것이 안정적인 파이프라인의 출발점이다.

React CRA

개발짜맠 — Mon, 27 Nov 2023 22:28:36 +0900

Backend 개발자인 제가 React 를 구성해보고 싶어 열심히 공부하고 테스트해가며 배운것들을 매우 심플하게 정리합니다.

검색하면 서로 너무너무 다른 방식으로 예제나 코드들이 설명되고 있어 했갈리더 군요.

그래서 너무 복잡한 바람에 그냥 매우 간단한 요점만 기재합니다.

세부적으로 파고듬은 전반적으로 이해한 후에 진행하는걸로 !

사전 설치 (맥 기준 )

brew install node
brew install npm
brew install yarn
brew install npx (맞나?)

React 로 프로젝트를 구성할 때 전반적인 구성요소

React 를 처음부터 구성하려면 여러가지 세팅을 해야한다.

NPM 및 Yarn
- 그냥 패키지 매니저다. Ruby 나 Python 도 NPM 을 이용해 라이브러리들을 가져온다.
- Spring 의 Maven 혹은 Gradle 이라고 보면 된다.
Babel
- 최신 브라우저의 자바스크립트 기능 및 문법이 과거 브라우저에선 통하지 않기에, 여러분이 작성한 코드를 컴파일시 자동으로 구버전 자바스크립트 ( ES5 등 ) 으로 변환해준다.
WebPack
- 프로젝트를 보기좋고 깔끔하게 관리하려면 디렉토리등 구조적으로 작성해야 하는데, 배포할땐 단하나의 파일로 만들어 로딩 회수도 줄이고 Javascript Minified 도 하는등의 역할을 해준다.
ESLint
- SonaLint 를 아는가? 똑같다. 그냥 문법문제가 있는것들을 콘솔상에서 Warning 으로 알려준다.
TypeScript
- Java 변수에 String, integer 등의 형선을 생각하자. 개념상 똑같다. 타입을 지정해서 프로젝트를 좀더 안전하게 관리하자 이다.
TailWind
- React 의 HTML 객체에 스타일을 적용할때 아래와 같이 작성해야 하는데, 기존문법처럼 작성하면 인식해준다.

- 기본 
<div className="[{"div", "h2", "span"}]"></div>
- TailWind 가 아래 문법도 지원
<div class="div h2 span"></div>

* 좀더 HTML 작성스럽게 지원한다.

React CRA

React CRA 는 뭐냐? React 가 히스토리를 아는 프론트엔드 개발자들은 구성하기 쉽겠지만

나같이 Jquery 이후에 손 안대본 개발자나 처음부터 시작하는 사람은 라이브러리 종류도 많고 세팅법도 어려워서

페이스북이 BolilerPlate 를 만들어 두었다.

난 그것도 모르고 이걸로 시작했다가 웹팩 설정 어딨어. Tsconfig 어딨어 등 한참 해맸다.

Cra 프로젝트는 이렇게 만든다.

npx create-react-app my-app --template typescript

이러면 my-app 폴더가 생기며 프로젝트가 생긴다.

npx command not found 뜨는 친구들은 검색해서 설치하고 오시길

npm 이랑 이런거 정도는 설치 간단하니까 설치하고 오자 .

CRA 는 설정파일을 내부에 숨겨서 관리하고 있다.

현시점에 이르러 딸랑 React 만가지고 프로젝트를 개발하기는 어렵다. 그래서 위에 열거한 것과 같은 라이브러리의 도움을

받아 프로젝트를 세팅하고 개발해야 하는데, 숙련자도 시간이 걸리고, 초보자는 너무 어려워 페이스북 형아들이 다 알아서 세팅해두고

배포한 보일러플레이트 인 것이다.

CRA 는 아래같은 패키지 및 설정들을 내포하고 있다.

Webpack
EsLint
Tailwind
Babel
기타 등등 또 뭐있을것이다 나도 아직 다 몰라서 확인한것은 이것들이다.

TypeScript 는 내포 안하고 있더라. 그래서 위에 첨 만들때 typescript 로 지정한 것이다.

설정 꺼내기

 yarn eject

이러면 숨겨진 설정파일들이 튀어나온다. 다시 되돌리진 못하니까 신중히 하라는 글들 많이 봤을 것이다.

난 너무 궁금해서 해봤지만 별거 없었다. 웹팩, eslint, 뭐 이런 설정들이 튀어 나오더라.

페북 형아들이 이렇게 해둔건 " 야 범용적으로 다 설정 해놨는데 뭐여 걍써 얼마나 대단한 설정 납신다고"

인거 같다.

내 생각도 같다. 뜬금없이 엄청 레거시한 프로젝트랑 지금 우리가 만드는 프로젝트를 병합하는 상황이 아니라면 별로 그럴일은

없을거 같다.

또 설정 override 도 지원하는거 같으니 개발자로서 당연히 찜찜한 걱정이 들겠지만 시원하게 CRA 로 시작해보길 바란다.

나도 프린이라 지금 시작하고있어서 잘 모르는 부분이 많아 잘못된 정보가 있을까 걱정이다.

이글을 보는 프린이 나와 함께 프른이가 되도록 같이 해보도록 하자.