OpenClaw: 로컬 중심의 차세대 AI 에이전트

![ComfyUI_00009_](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/03730cee-62ed-4987-a389-c1ec555e695f_ComfyUI_00009_.png)

현재 여러 프로젝트를 진행중에 있는데

프로젝트를 진행하다가 맘에 드는 lofi 채널을 찾지못해서

그냥 채널을 하나 만들어서 운영하고있습니다.

영상의 캐릭터는 제가 만든 세계관의 캐릭터인 이오(IO) 입니다.

한번씩 작업하다가 들으러 와주세요.

잔잔하면서 좋은 음악들로 최대한 만드는 중입니다~~ㅎㅎㅎ


[https://www.youtube.com/@IO-0047](https://www.youtube.com/@IO-0047)


유튜브에서 lofi 채널을 만들었습니다.

![event](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/3e447b01-be59-4aae-9a98-9a3265f94886_event.webp)

> 스프링에서 Event랑 `@Async`를 쓰다 보면 처음엔 편한데, 프로젝트가 조금만 커져도 “이게 언제 실행되는거지?”, “트랜잭션 커밋 전에 나가버린거 아냐?” 같은 이슈가 바로 나옵니다. 그래서 이번에는 제가 정리했던 내용을 기준으로, Event / `@Async`가 정확히 어떻게 동작하는지랑 운영에서 자주 터지는 포인트를 같이 정리해보겠습니다.

# Spring Event는 기본적으로 “동기”로 동작합니다

처음에 제가 착각했던 부분이 이거였습니다.  
Event라고 해서 자동으로 비동기로 도는게 아닙니다.

- 기본 설정에서는 이벤트를 publish한 **그 스레드에서 리스너가 그대로 실행**됩니다.
- 그래서 리스너에서 시간이 오래 걸리는 작업을 하면, publish한 쪽도 같이 느려집니다.

즉, Event는 “관심사 분리”에는 좋지만, “응답속도”가 자동으로 빨라지는 기능은 아닙니다.

# 이벤트를 쓰면 좋은 상황이 있습니다

이벤트는 보통 “핵심 로직”이랑 “부가 로직”을 분리할 때 가장 효과가 좋습니다.

예를 들면:

- 주문 생성(핵심) 이후에  
  - 슬랙 알림 보내기  
  - 포인트 적립하기  
  - 통계 적재하기  
  - 감사 로그 남기기  
같은 것들이 계속 붙는 상황입니다.

이걸 다 `OrderService.createOrder()` 안에 넣기 시작하면, 결국 서비스 메서드가 너무 길어지고 결합이 커집니다.  
이럴 때 이벤트로 분리해두면 “리스너 추가”만으로 기능을 붙일 수 있습니다.

다만 이 방식도 단점이 있는데, 흐름이 코드에서 한 눈에 안보이는 문제가 있습니다.  
그래서 결제 승인처럼 **즉시 실패 전파가 중요한 핵심 플로우**는 이벤트로 대충 넘기면 위험합니다.

# 이벤트 구현은 이렇게 합니다 (POJO 이벤트)

요즘은 `ApplicationEvent` 상속 없이 POJO(또는 record)로 많이 합니다.

```java
public record OrderCreatedEvent(
    Long orderId,
    Long userId,
    int totalAmount
) {}
```

이벤트 발행은 `ApplicationEventPublisher`로 합니다.

```java
@Service
@RequiredArgsConstructor
public class OrderService {
  private final ApplicationEventPublisher publisher;

  @Transactional
  public Long createOrder(CreateOrderCommand cmd) {
    Long orderId = /* 주문 저장 */;
    publisher.publishEvent(new OrderCreatedEvent(orderId, cmd.userId(), cmd.totalAmount()));
    return orderId;
  }
}
```

여기서 바로 의문이 생깁니다.

- “트랜잭션 커밋 전에 이벤트가 처리되면 어떡하지?”
- “리스너에서 DB 조회하면 아직 커밋 전이면 못 읽는거 아닌가?”

이 문제 때문에 실무에서는 `@TransactionalEventListener`를 같이 쓰는 경우가 많습니다.

# @TransactionalEventListener는 “언제 실행할지”를 정할 수 있습니다

예를 들어 커밋 이후에만 실행되게 하려면 이렇게 합니다.

```java
@Component
public class OrderEventListener {

  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void afterCommit(OrderCreatedEvent event) {
    // 커밋 성공 이후에만 실행됩니다.
  }
}
```

`phase` 옵션은 대충 이렇게 이해하면 됩니다.

- `BEFORE_COMMIT`: 커밋 직전
- `AFTER_COMMIT`: 커밋 성공 이후 (제일 많이 씁니다)
- `AFTER_ROLLBACK`: 롤백 이후
- `AFTER_COMPLETION`: 커밋/롤백 상관 없이 트랜잭션 종료 이후

제가 보통 추천하는 조합은:

- 외부 알림/외부 API 호출(메일, 슬랙, 외부 결제 후속 처리 등) → `AFTER_COMMIT`  
  (커밋이 실패했는데 알림부터 나가면 더 큰 문제가 생깁니다)
- 실패 케이스 후처리(보상 로그, 실패 알림 등) → `AFTER_ROLLBACK`

## 트랜잭션이 없으면 실행이 안될 수 있습니다

`@TransactionalEventListener`는 트랜잭션이 없으면 phase 의미가 없어서, 실행이 안되는 케이스가 있습니다.  
그럴 때는 아래 옵션을 씁니다.

```java
@TransactionalEventListener(
  phase = TransactionPhase.AFTER_COMMIT,
  fallbackExecution = true
)
public void on(OrderCreatedEvent event) { }
```

`fallbackExecution=true`면 트랜잭션이 없어도 실행되긴 합니다.  
다만 이 경우에는 “AFTER_COMMIT” 의미는 사실상 사라지고 그냥 실행된다고 보면 됩니다.

# @Async는 “별도 스레드”에서 실행됩니다

`@Async`는 별도 스레드에서 메서드를 실행하는 기능이고, 내부적으로 `TaskExecutor`(스레드풀)를 씁니다.

사용하려면 보통 아래를 추가합니다.

```java
@EnableAsync
@Configuration
public class AsyncConfig { }
```

그리고 메서드에 `@Async`를 붙입니다.

```java
@Component
public class NotificationService {

  @Async
  public void sendOrderCreatedMessage(Long orderId) {
    // 별도 스레드에서 실행됩니다.
  }
}
```

여기서도 “처음엔 되는데 운영에서 터지는 지점”이 몇 개 있습니다.

# @Async에서 자주 터지는 포인트들

## 1) 프록시 기반이라서 “자기 자신 호출”은 안됩니다

`@Async`는 AOP 프록시 기반이라서, 같은 클래스 안에서 `this.asyncMethod()`로 호출하면 비동기로 안도는 경우가 있습니다.  
그래서 보통은 `@Async` 메서드를 다른 Bean으로 분리합니다.

## 2) `void` 리턴이면 예외가 호출자에게 전달되지 않습니다

`@Async void` 메서드는 예외가 호출한 쪽으로 전달되지 않습니다.  
그래서 운영에서 조용히 실패하는 경우가 생깁니다.

필요하면 `AsyncUncaughtExceptionHandler`를 설정해두는게 안전합니다.

## 3) 트랜잭션/영속성 컨텍스트는 공유되지 않습니다

비동기 스레드에서는 기존 요청 스레드의 트랜잭션/영속성 컨텍스트가 그대로 이어지지 않습니다.  
그래서 이벤트/비동기에서 엔티티를 그대로 들고가면 lazy 로딩 같은게 터질 수 있습니다.

그래서 저는 보통 이렇게 잡습니다.

- 이벤트에는 엔티티를 넘기지 않습니다.
- ID나 스냅샷 DTO만 넘깁니다.
- 리스너에서 필요하면 새 트랜잭션으로 다시 조회합니다.

# Event + @Async 조합은 이런 식으로 씁니다

실무에서 제일 흔한 패턴은:

- 이벤트는 `AFTER_COMMIT`에 받습니다.
- 리스너는 `@Async`로 돌립니다.

```java
@Component
@RequiredArgsConstructor
public class OrderAsyncEventListener {

  private final SlackClient slackClient;

  @Async
  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void on(OrderCreatedEvent event) {
    slackClient.send("#orders", "주문 생성: " + event.orderId());
  }
}
```

이렇게 하면 커밋 성공 이후에, 별도 스레드에서 외부 알림을 보내게 할 수 있습니다.

# 근데 이 방식은 “내구성”을 보장하지 않습니다

여기서 또 중요한 포인트가 있습니다.

Spring Event는 기본적으로 **프로세스 내부 이벤트**라서,

- 서버가 내려가면 유실될 수 있고
- 재시도/중복 처리/내구성이 기본 제공되지 않고
- 멀티 인스턴스 환경에서는 브로드캐스트가 아닙니다

즉, “절대 유실되면 안되는 작업”이면 Event/Async로 끝내면 안됩니다.

이런 경우에는 보통:

- Outbox 패턴 + 메시지 브로커(Kafka/RabbitMQ/SQS)
- DB 작업 큐 테이블 + 워커
- 배치 재처리

같은 구조로 넘어가야 합니다.

# 결론

Event는 결합도를 줄이는 데 좋고, `@Async`는 느린 후처리를 분리하는 데 좋습니다.  
근데 둘 다 “편해보여서 막 쓰면” 운영에서 바로 터질 수 있습니다.

제가 기준으로 잡는건 이렇습니다.

1. 외부 호출은 가능하면 `AFTER_COMMIT` 이후에 합니다.
2. 이벤트 페이로드는 ID/스냅샷 DTO로 최소화합니다.
3. `@Async`는 예외가 조용히 묻히지 않게 로그/메트릭을 잡습니다.
4. 스레드풀(TaskExecutor) 튜닝을 운영 기준에 맞게 합니다.
5. 유실이 허용되지 않으면 Outbox/Queue로 넘어갑니다.


Spring Event와 @Async 정리 (동작 방식, 트랜잭션, 운영 포인트)

> OpenClaw를 한 문장으로 요약하면 **“LLM이 도구(tool)를 통해 실제 세계(브라우저·DB·파일·메신저·스케줄러)를 다루게 해주는 로컬 에이전트 런타임”** 입니다. 
> 이 글에서는 제가 실제로 OpenClaw를 운영하면서 쌓은 경험을 바탕으로, **현업에서 바로 써먹을 수 있는 활용사례(Use case)** 와 **운영 팁(실패/차단/중복/품질 이슈를 줄이는 방법)** 을 정리합니다.

# OpenClaw 활용사례: “대화형 자동화”를 운영 가능한 워크플로우로 만드는 법

# 1. OpenClaw는 뭐가 다른가: 챗봇이 아니라 ‘런타임’이다
대부분의 LLM 도구는 “좋은 답변을 생성”하는 데 초점이 맞춰져 있습니다. 반면 OpenClaw는 구조적으로 다음을 제공합니다.

- **Gateway(로컬 데몬)**: 툴 호출(파일/쉘/브라우저/메시지/스케줄링)을 실제로 수행하는 실행기
- **Cron(내장 스케줄러)**: 일정 기반 실행을 Gateway 내부에서 영속적으로 관리
- **Browser 제어**: 격리된 브라우저 프로필 또는 크롬 확장 릴레이로 “탭을 잡고” 자동화
- **Messaging 채널**: Slack 같은 협업 채널에 결과를 전달하고, 멘션 기반으로 트리거

즉 OpenClaw는 “잘 말하는 AI”가 아니라, **반복 작업을 안정적으로 돌리는 운영형 에이전트**에 가깝습니다.

# 2. 큰 그림 아키텍처(현업 관점)
OpenClaw 활용 시 가장 많이 쓰는 구성은 아래 패턴으로 귀결됩니다.

- **입력(Trigger)**
 - Slack 멘션/DM
 - Cron 스케줄(정확한 시각/주기)
 - 수동 실행(필요할 때만)
- **처리(Agent + Tools)**
 - 웹 탐색(검색/페이지 읽기)
 - 데이터 정제(중복 제거/품질 필터/카테고리 분류)
 - 번역/요약/스코어링
 - DB 저장(예: PostgreSQL)
- **출력(Deliver)**
 - Slack 채널 리포트
 - DB 적재(대시보드/분석용)
 - 블로그 포스팅(콘텐츠 발행)

여기서 중요한 포인트는 **“처리 단계를 분리해서 실패를 국소화”**하는 겁니다. 
예를 들어 “수집(가볍게)”과 “번역/요약(무겁게)”을 같은 턴에서 한꺼번에 처리하면, 한번에 터졌을 때 복구도 어렵고 모델/계정 차단 리스크도 커집니다.

# 3. 활용사례 #1 — Slack 채널에서 운영되는 팀 유틸리티 봇
## 3.1 어떤 문제를 해결하나?
팀 채널에는 반복적인 질문이 항상 있습니다.

- “지금 데이터 얼마나 쌓였지?”
- “오늘 트렌드 뭐 올라왔어?”
- “테이블 스키마 바뀐 거 맞아?”
- “이거 DB로 적재됐어?”

이걸 사람이 계속 확인해 주면 업무가 끊기고, 확인하는 사람만 피곤해집니다.

## 3.2 OpenClaw 방식
OpenClaw는 Slack에서 멘션을 트리거로, **DB 조회 → 요약 → 채널 보고** 같은 운영 업무를 자동화할 수 있습니다.

- 장점: “답변 생성”이 아니라 **조회/검증/보고**까지 자동으로 이어짐
- 팁: 채널에선 과도한 스팸을 피하기 위해 결과는 “요약 + 링크/쿼리” 중심이 좋습니다.

# 4. 활용사례 #2 — 테크 트렌드 수집 → 번역 → DB 적재 (tech_trends)
이 활용사례는 제가 실제로 가장 많이 돌린 형태입니다.

## 4.1 목표
- 기술 트렌드를 ‘읽고 끝’이 아니라 **DB에 누적**해서 검색/분석/대시보드로 연결
- 중복 제거/번역/스코어링을 포함해 “쓸만한 데이터”를 만드는 것

## 4.2 추천 파이프라인(운영형)
저는 아래처럼 **2단계 파이프라인**을 추천합니다.

### (1) 수집 단계(가볍게, 자주)
- 주기: 10분~1시간
- 하는 일: 링크/제목/소스/발행시각 같은 **메타만** 수집
- 목적: 후보를 끊임없이 확보하되, 비용/차단 리스크를 최소화

### (2) 가공 단계(무겁게, 덜 자주)
- 주기: 1-6시간(또는 하루 1-2회)
- 하는 일: 본문 핵심 문단 확보 → 요약/번역/카테고리/스코어링
- 목적: **품질을 보장**하고, “대량 번역 폭주”를 방지

이렇게 분리하면 “수집이 잠깐 실패”해도 가공 단계가 멈추지 않고, 반대로 “가공이 막혀도” 수집 후보가 계속 쌓여서 나중에 배치로 처리할 수 있습니다.

## 4.3 ‘차단/제한’을 피하는 운영 규칙
실제로 운영하면 가장 많이 터지는 문제가 "대량 호출"입니다. 
주기(5분/1시간)보다 **1회 실행에서 몇 개를 처리하는지(상한)** 가 더 중요합니다.

제가 권하는 기본 안전장치:

- **1회 실행 상한(하드 리밋)**: 예) 후보 링크 최대 10개, 번역/요약 최대 5~20개
- **도메인별 쿼터**: 예) 1회 실행에 같은 소스는 최대 1~2개
- **403/429 백오프**: 에러가 뜨면 즉시 6~24시간 쿨다운
- **중복 체크는 URL 우선**: 번역된 제목으로 중복 판정하면 “새 글도 중복”이 되기 쉬움

> 운영 현실에서 “데이터가 안 쌓인다”는 문제는, 대부분 ‘중복 판정이 공격적’이거나 ‘실패를 조용히 삼키는 로직’ 때문입니다.

## 4.4 품질을 올리는 규칙(unknown source, 빈 컨텐츠 방지)
DB에 들어가는 값이 아래처럼 되면 쓸모가 급격히 떨어집니다.

- `source = unknown`
- 본문 내용 없이 제목만 존재
- 번역이 빈 칸이거나, 너무 짧은 요약

권장 규칙:

- **source는 무조건 채운다**
 - 매핑 룰(예: `github.com/trending` → `github trending`)
 - 또는 최소한 도메인명이라도 넣기(unknown 금지)
- **본문/요약 최소 길이 조건**
 - 예: `description_ko` 200자 미만이면 insert 금지(스킵)

# 5. 활용사례 #3 — Cron으로 '정확히 그 시간'에 돌리는 자동화
OpenClaw Cron은 Gateway 내부에 있고, 잡이 영속 저장됩니다. 
그래서 "서버 재시작하면 스케줄 날아가요?" 같은 운영 악몽이 줄어듭니다.

## 5.1 Main vs Isolated
- **Main(sessionTarget=main)**: 시스템 이벤트를 넣고, 다음 heartbeat에서 메인 컨텍스트로 처리
- **Isolated(sessionTarget=isolated)**: `cron:<jobId>`에서 완전 독립 실행(모델/옵션 분리 가능)

잡이 시끄럽거나 자주 돈다면 보통 **isolated**가 운영에 더 편합니다.

# 6. 활용사례 #4 — 브라우저 자동화(검증/어드민 작업)
브라우저 자동화는 ‘가능하면 API로’, ‘불가하면 브라우저로’가 좋습니다.

- 로그인은 자동화보다 **수동 로그인**이 안전(봇탐지/계정락 방지)
- OpenClaw는 격리된 `openclaw` 프로필로 브라우저를 띄워서(또는 확장 릴레이로 탭에 붙어서) 클릭/타이핑/스냅샷을 수행할 수 있습니다.

# 7. 활용사례 #5 — 블로그 운영 자동화(콘텐츠 생성 → 검수 → 발행)
OpenClaw를 블로그 운영에 쓰면 다음이 가능합니다.

- 아이디어 수집(트렌드/이슈)
- 초안 작성(마크다운)
- 검수 체크리스트 적용(섹션 구조/용어 일관성)
- API 기반 발행(GraphQL/REST)

여기서 핵심은 "콘텐츠 생성"보다도, **반복되는 포맷/검수/발행 프로세스를 표준화**한다는 점입니다.

# 8. 실제 운영에서 자주 겪는 문제와 해결책
## 8.1 ‘중복이라서 안 넣었다’가 너무 자주 뜬다
- 중복키가 잘못되었을 가능성이 큽니다.
- URL이 있으면 URL을 1순위로 삼고,
- URL이 없을 때만 `source + title + date` 같은 조합 해시를 씁니다.

## 8.2 특정 매체(DW/Al Jazeera 등)만 과하게 쌓인다
- 검색 상위에 자주 뜨는 매체는 자동으로 편향이 생깁니다.
- 해결: **source별 쿼터**(회차당 1~2개) + **국가/소스 라운드로빈**

## 8.3 계정/모델이 제한(403/429) 걸린다
- 대부분 "대량 fetch + 대량 번역"이 원인입니다.
- 해결: 상한/배치/백오프, 그리고 "본문 전문 저장" 대신 "요약+링크" 중심으로 전환

# 9. 정리: OpenClaw를 '안전하게' 잘 쓰는 5가지 원칙
1) 수집과 가공(번역/요약)을 분리한다
2) 1회 실행 상한을 강제한다
3) URL 기반 중복 제거를 우선한다
4) source unknown/빈 컨텐츠는 저장하지 않는다
5) 에러(403/429) 시 즉시 백오프한다

# 10. 다음 단계(추천)
- 'tech_trends'부터 "안전 모드"로 안정화
- 일정 수준 누적되면(예: 500~1000건) 대시보드/검색 UI로 확장
- 필요하면 글로벌 뉴스/이슈 테이블도 “소량 큐레이션” 방식으로 재도입

# 11. 마무리 
다음에 시간이 된다면 제가 사용하는 실제 예시로,
- `tech_trends` 테이블 스키마(권장 컬럼)
- source 매핑 룰 세트
- relevance_score 계산 규칙(간단한 휴리스틱)
을 더 구체적으로 포스팅해보도록 하겠습니다.

---

현재 OpenClaw를 어떻게 활용해야 잘 사용할지 저도 계속해서 이것저것 시도해 보는 중입니다. 
우선 머릿속에 빠르게 떠올랐던건 정보 수집을 자동화해서 수집한 정보를 토대로 앞으로의 계획이나 세계 트렌드가 어떻게 흘러가는지에 대한 것을 파악 하는 거였습니다. 
이 외에도 여러가지로 많은 시도를 하고있으니 좋은 정보가 있으면 바로바로 포스팅 해보도록 하겠습니다.

OpenClaw 활용사례: '대화형 자동화'를 운영 가능한 워크플로우로 만드는 법

> AI 에이전트 개발 트렌드가 클라우드(SaaS)에서 **로컬(Local-First)** 로 급격히 이동하고 있습니다. 내 데이터를 외부로 보내지 않고, 내 컴퓨터와 서버를 직접 제어하며, 끊김 없이 동작하는 에이전트. 그 중심에 있는 **OpenClaw**의 아키텍처와 기술적 특장점을 낱낱이 파헤쳐 봅니다.

# 1. OpenClaw가 해결하려는 문제

기존의 AI 에이전트(LangChain, AutoGPT 등)들은 대부분 Python 스크립트 형태이거나 일회성 실행에 그쳤습니다.

* **연결성 부재**: 내 맥북의 카메라를 제어하거나, 집에 있는 서버의 로그를 보고 싶을 때 연결이 복잡함.
* **상태 유지 불가**: 프로세스가 죽으면 기억(Context)이 날아감.
* **보안 이슈**: 회사 내부망이나 개인적인 데이터를 클라우드 LLM 서비스에 통째로 넘겨야 함.

OpenClaw는 이 문제를 해결하기 위해 **"Gateway Architecture"** 를 도입한 **상주형 에이전트 런타임(Daemon)** 입니다.

# 2. 핵심 아키텍처: The Gateway

OpenClaw의 심장은 **Gateway**입니다. 하나의 호스트에서 데몬(Daemon) 형태로 실행되며, 모든 연결의 허브 역할을 합니다.

### 🔌 WebSocket 중심의 통신
모든 클라이언트(CLI, 웹 대시보드, 모바일 앱)와 **Node(노드)** 들은 Gateway에 **WebSocket**으로 연결됩니다.

* **실시간성**: HTTP 폴링 없이 에이전트의 생각(Thinking)과 행동(Action)이 실시간으로 스트리밍됩니다.
* **단일 진입점**: Telegram, Slack, WhatsApp 등 다양한 메신저 채널을 Gateway가 통합 관리합니다. 사용자는 채널 상관없이 하나의 세션처럼 대화할 수 있습니다.

### 📱 Node Pairing (기기 확장)
OpenClaw의 가장 강력한 기능입니다. 단순히 Gateway가 설치된 컴퓨터만 제어하는 것이 아닙니다.

* **Nodes**: 안드로이드 폰, 아이패드, 라즈베리 파이, 헤드리스 서버 등에 OpenClaw Node를 설치하고 Gateway에 연결(`pair`)합니다.
* **원격 제어**: 에이전트는 연결된 모든 Node의 하드웨어(카메라, 위치 정보, 화면 녹화, 터미널)를 자신의 손발처럼 사용합니다.
 * *"거실 아이패드(Node) 카메라로 현재 상황 찍어서 보내줘."*
 * *"서버(Node) 터미널에서 로그 파일 모니터링해줘."*

# 3. Local-First & Security

### 🔒 내 데이터는 내 컴퓨터에
OpenClaw는 **Local-First** 철학을 따릅니다.

* **로컬 저장소**: 대화 기록(Transcript), 기억(Memory), 설정 파일 등 모든 데이터는 사용자의 로컬 파일 시스템에 저장됩니다.
* **Tailscale 통합**: 외부에서 접속할 때도 복잡한 포트 포워딩 없이 Tailscale VPN을 통해 안전하게 P2P로 연결됩니다.
* **샌드박스(Sandbox)**: 에이전트가 위험한 명령어(`rm -rf /`)를 실행하지 못하도록 Docker나 격리된 환경에서 도구를 실행할 수 있습니다.

# 4. 강력한 도구 생태계 (Skills)

OpenClaw는 **"Skill"** 이라는 단위로 능력을 확장합니다.

* **Browser Control**: Chrome 확장 프로그램을 통해 브라우저를 직접 제어하고 웹을 서핑합니다.
* **Canvas**: 에이전트가 실시간으로 HTML/JS UI를 그려서 사용자에게 보여줍니다. (단순 텍스트 응답을 넘어선 GUI 상호작용)
* **Cron & Hooks**: "매일 아침 9시에 뉴스 요약해줘" 같은 반복 작업을 스케줄링하거나, 특정 이벤트 발생 시 스크립트를 실행합니다.

# 5. 활용 사례 (Use Cases)

### 🏠 홈 오토메이션의 두뇌
IoT 기기들과 연결하여 진정한 스마트 홈 비서로 활용합니다. (Home Assistant 연동)

### 💻 데브옵스(DevOps) 파트너
서버 장애 발생 시 알림을 받고, 로그를 분석하여 1차 조치를 취한 뒤 개발자에게 보고서를 올립니다.

### 👨‍💻 개인 비서 (Second Brain)
옵시디언(Obsidian)과 연동하여 노트를 정리하고, 캘린더를 관리하며, 흩어진 정보를 모아 인사이트를 제공합니다.

# 마치며: AI 에이전트의 미래는 'OS'다

OpenClaw는 단순한 챗봇이 아닙니다. **"AI를 위한 운영체제(OS)"** 에 가깝습니다.
여러분의 모든 기기와 데이터를 연결하고, AI가 그 위에서 자유롭게 뛰어놀 수 있는 운동장을 만들어줍니다.

지금 바로 터미널을 열고 `npm install -g openclaw`를 입력해 보세요. 나만의 자비스(Jarvis)를 만드는 첫걸음입니다. 🚀

OpenClaw: AI 에이전트의 '로컬 런타임' 혁명 (Architecture Deep Dive)

# OpenClaw란 무엇인가?

**OpenClaw**는 개발자의 로컬 환경에서 직접 실행되는 **차세대 AI 에이전트 런타임**입니다. 단순히 클라우드에 있는 챗봇과 대화하는 것을 넘어, 사용자의 터미널, 브라우저, 파일 시스템과 직접 상호작용하며 실질적인 작업을 수행합니다.

# 핵심 특징

- **Local-First & Privacy**: 모든 런타임이 사용자의 로컬 머신(또는 사설 서버)에서 구동됩니다
- **Node Pairing**: 여러 기기(노트북, 데스크탑, 서버)를 연결하여 하나의 거대한 신경망처럼 활용할 수 있습니다.
- **Powerful Tooling**: 터미널 명령어 실행(Exec), 브라우저 제어(Browser Control), 파일 조작 등을 자유자재로 수행합니다.

# 어떻게 쓰이고 있는가?

현재 OpenClaw는 다음과 같은 분야에서 활약하고 있습니다:

1. **Coding Assistant**: VSCode 등의 에디터와 연동하거나 직접 파일 시스템을 수정하며 코드를 작성하고 디버깅합니다.
2. **Infrastructure Automation**: Docker, Kubernetes, AWS CLI 등을 직접 제어하여 배포 및 운영 자동화를 수행합니다.
3. **Personal Secretary**: 이메일 확인, 일정 관리, 웹 정보 수집 등을 대신 처리해줍니다.

# 앞으로의 발전 방향

OpenClaw는 단순한 도구를 넘어 **자율성(Autonomy)** 을 갖춘 에이전트로 진화하고 있습니다.

- **Multi-Agent Swarm**: 여러 에이전트가 협업하여 복잡한 프로젝트를 분담 처리
- **Voice & Vision Integration**: 보고 듣고 말하는 멀티모달 인터페이스 강화
- **Self-Improvement**: 스스로 새로운 기술(Skill)을 학습하고 플러그인을 설치하는 능력

OpenClaw는 AI가 단순한 '말동무'에서 '진정한 동료'로 거듭나는 시작점입니다.

> 지난 글에서는 터미널 기반 AI 에이전트 **OpenCode**에 대해 알아보았습니다. 하지만 OpenCode 그 자체는 훌륭한 '실행 환경(Runtime)'일 뿐입니다. 실제로 코드를 작성하고, 파일을 찾고, 아키텍처를 고민하는 지능적인 작업은 그 위에서 돌아가는 **'에이전트 프로그램'**이 담당합니다. 오늘은 OpenCode 생태계에서 가장 강력하고 널리 쓰이는 메인 에이전트, **Sisyphus(시지푸스)**에 대해 알아봅니다.

# 1. Sisyphus란 무엇인가?

**Sisyphus**는 **Oh My OpenCode**라는 오케스트레이션 레이어(Orchestration Layer)에 포함된 핵심 에이전트입니다. 그리스 신화에서 바위를 끝없이 밀어 올리는 시지푸스처럼, 개발자의 **무한한 코딩 루프(작성-테스트-수정)** 를 대신 수행해 준다는 의미를 담고 있습니다.

단순히 "코드 짜줘"라고 하면 코드를 뱉는 챗봇이 아닙니다. Sisyphus는 **개발자처럼 생각하고 행동하도록 설계된 시스템**입니다.

# 2. 핵심 철학: "Sisyphus는 혼자 일하지 않는다"

Sisyphus의 가장 큰 특징은 **전문가 에이전트들과 협업**한다는 점입니다. 마치 팀장(Lead Dev)처럼 행동합니다.

### 🧩 The Agent Squad (에이전트 스쿼드)

1. **Sisyphus (Main Agent)**: 사용자의 명령을 듣고 전체 작업을 조율하는 리더.
2. **Librarian**: "이 프로젝트에서 인증 관련 로직이 어디 있지?"라고 물으면 문서를 뒤지고 코드를 검색해서 위치를 찾아줍니다.
3. **Oracle**: 복잡한 아키텍처 설계나 디버깅이 필요할 때, 코드 전체를 깊이 분석하여 조언을 줍니다.
4. **Explore**: `grep`보다 똑똑하게 코드베이스를 탐색하여 관련된 파일들을 수집합니다.

Sisyphus는 이들을 적재적소에 호출하여, 혼자서는 해결할 수 없는 복잡한 문제도 척척 해결합니다.

# 3. 주요 기능: 개발자의 멘탈 모델을 그대로

### 🧠 Artifact Management (기억 관리)
개발자가 코드를 짤 때 머릿속에 담아두는 '맥락(Context)'을 Sisyphus는 **Artifact**라는 형태로 관리합니다.
- "아까 수정한 `User.ts` 파일 내용 기억해줘."
- "방금 실행한 테스트 로그 저장해놔."
이 정보들은 세션이 길어져도 잊혀지지 않고 유지됩니다.

### 📍 Checkpoint System (체크포인트)
"아, 방금 수정한 거 취소하고 다시 할래."
Sisyphus는 작업을 수행하기 전에 자동으로 파일 시스템의 스냅샷(Checkpoint)을 뜹니다. AI가 코드를 망쳐놔도 언제든 **Undo** 명령어로 안전하게 되돌릴 수 있습니다.

### 🔄 Self-Correction Loop (자가 수정)
코드를 수정하고 나서 `npm test`를 돌렸는데 실패했다면? Sisyphus는 에러 로그를 읽고 **스스로 원인을 분석하여 재수정**합니다. 이 과정을 테스트가 통과할 때까지 반복합니다. (물론 무한 루프를 막기 위한 제한도 있습니다.)

# 4. 왜 Sisyphus를 써야 하는가?

OpenCode만 설치해서 쓰는 것(Vanilla)과 Oh My OpenCode(Sisyphus)를 깔아서 쓰는 것은 **"메모장"과 "IntelliJ"의 차이**와 같습니다.

* **더 똑똑한 문맥 파악**: LSP(Language Server Protocol)를 적극 활용하여 함수 정의를 찾아다닙니다.
* **도구 사용 능력**: 브라우저를 띄워 문서를 검색하거나, 이미지를 보고 UI를 수정하는 멀티모달 능력도 갖추고 있습니다.

# 마치며

OpenCode가 하드웨어라면, Sisyphus는 그 위에서 돌아가는 **운영체제(OS)** 입니다.
단순한 코딩 보조를 넘어, 나만의 'AI 부사수'를 원하신다면 지금 당장 Sisyphus를 설치해보세요!!

```bash
# Sisyphus 설치 (Oh My OpenCode)
bunx oh-my-opencode install
```

이제 무겁고 무거운 바위는 Sisyphus에게 맡기고, 여러분은 창의적인 설계에 집중해보시죠!!!

Sisyphus(시지푸스): OpenCode를 진정한 코딩 파트너로 만드는 두뇌

> 2025년 하반기, 개발자 커뮤니티를 가장 뜨겁게 달군 프로젝트가 있습니다. 출시 직후 폭발적인 반응을 얻으며 **GitHub Star 70K**를 돌파한 오픈소스 AI 코딩 에이전트, **OpenCode**입니다. "Cursor의 오픈소스 대항마", "터미널 기반의 혁명"이라는 수식어가 붙는 이 도구가 왜 이렇게 인기인지, 그리고 우리가 왜 주목해야 하는지 알아봅니다.


# 1. OpenCode란 무엇인가?

**OpenCode**는 터미널(CLI)에서 실행되는 **AI 코딩 에이전트**입니다. 단순히 코드를 추천해주는 Copilot과는 다릅니다. 개발자의 지시를 받고 **직접 파일을 수정하고, 터미널 명령어를 실행하고, 에러를 고칩니다.**

* **완전한 오픈소스**: 코드가 투명하게 공개되어 있으며, 무료로 사용 가능합니다. (물론 LLM API 비용은 별도)
* **로컬 우선 (Local-First)**: 모든 컨텍스트 분석이 로컬 머신에서 이루어집니다. 프라이버시를 중시하는 기업 환경에서도 안전하게 사용할 수 있습니다.

# 2. 왜 7만 명의 개발자가 열광했는가?

### 🚀 터미널 중심의 워크플로우 (TUI)
많은 AI 도구들이 IDE(VS Code 등)에 기생하는 플러그인 형태인 반면, OpenCode는 **터미널 그 자체**가 됩니다. Vim/Neovim 사용자나 CLI를 선호하는 서버 개발자들에게 열광적인 지지를 받고 있습니다.

### 🧠 놀라운 문맥 이해 (Context Awareness)
단순히 현재 열려있는 파일만 보는 게 아닙니다. 프로젝트 전체 구조, `git diff`, 심지어 **LSP(Language Server Protocol)**와 연동하여 함수 정의나 참조 관계까지 파악합니다. 덕분에 "이 함수 바꿔줘"라고 하면, 그 함수를 호출하는 다른 파일들까지 알아서 찾아 수정합니다.

### 🛠 강력한 도구 사용 능력 (Tool Use)
OpenCode는 단순히 코드를 짜는 것을 넘어, 다음과 같은 도구들을 자유자재로 씁니다.
* **Shell Execution**: 테스트를 돌리고(`npm test`), 실패하면 로그를 읽고 스스로 고칩니다.
* **Browser Control**: (옵션) 웹 브라우저를 띄워 문서를 찾아보거나 로컬호스트를 테스트합니다.
* **File Manipulation**: 파일을 생성, 삭제, 이동, 수정합니다.

# 3. 주요 기능 (Features)

1. **Zen Mode**: 코딩에 최적화된 LLM 모델(Claude 3.5 Sonnet, GPT-4o 등)을 자동으로 벤치마킹하여 골라주는 모드입니다.
2. **Privacy Focus**: 코드를 외부 서버에 저장하지 않습니다. 오직 LLM 추론을 위해서만 데이터를 보냅니다.
3. **Self-Correction**: 코드를 작성한 후 자동으로 린트(Lint)를 돌리거나 컴파일을 시도하고, 에러가 나면 즉시 수정하는 루프를 돕니다.

# 4. 설치 및 사용법

설치는 매우 간단합니다. 터미널 한 줄이면 끝납니다.

```bash
curl -fsSL https://raw.githubusercontent.com/opencode-ai/opencode/refs/heads/main/install | bash
```

설치 후 프로젝트 폴더에서 `opencode`라고 치면, 에이전트와의 대화가 시작됩니다.

```bash
$ opencode
> "현재 프로젝트의 테스트 코드를 전부 실행해보고, 실패하는 부분을 고쳐줘."
```

# 마치며: AI와 페어 프로그래밍하는 시대

OpenCode는 AI가 단순히 '보조 도구'가 아니라 **'동료(Agent)'**가 될 수 있음을 증명하고 있습니다. 특히 오픈소스 생태계의 힘을 빌려 상용 도구(Cursor, Windsurf) 못지않은 퀄리티를 보여준다는 점이 고무적입니다.

아직 사용해보지 않으셨다면, 오늘 퇴근 전에 터미널을 열고 OpenCode를 설치해 보세요. 여러분의 생산성이 10배는 뛸지도 모릅니다. 🚀

[화제] OpenCode: GitHub Star 7만 개를 돌파한 오픈소스 AI 에이전트의 정체

> 2025년 백엔드 개발의 화두는 단연 **"모듈러 모놀리스(Modular Monolith)"** 였습니다. 무조건적인 마이크로서비스(MSA) 도입으로 인한 운영 피로도에 지친 개발자들이, 다시금 "잘 짜여진 모놀리스"로 눈을 돌리고 있기 때문입니다. 오늘은 이 트렌드의 중심에 있는 **Spring Modulith**에 대해 알아보겠습니다.

# 1. 왜 다시 모놀리스인가?

마이크로서비스는 확장성과 배포 독립성이라는 강력한 장점을 주지만, 그만큼 **복잡성 비용(Complexity Tax)** 을 요구합니다. 분산 트랜잭션, 네트워크 레이턴시, 로깅 통합 등 해결해야 할 과제가 산더미죠.

**"굳이 처음부터 네트워크로 찢어놓을 필요가 있을까? 논리적으로만 잘 분리하면 되지 않을까?"**

이 질문에서 시작된 것이 바로 **모듈러 모놀리스**입니다. 그리고 Spring 팀은 이를 공식적으로 지원하기 위해 **Spring Modulith** 프로젝트를 런칭했습니다.

# 2. Spring Modulith의 핵심 기능

Spring Modulith는 패키지 구조를 기반으로 애플리케이션의 모듈을 정의하고, 모듈 간의 의존성을 관리해줍니다.

### ✅ 아키텍처 검증 (Verification)

가장 강력한 기능입니다. 코드가 컴파일될 때, 모듈 간의 참조 규칙을 위반했는지 검사합니다.

```java
@Test
void verifyModularity() {
 ApplicationModules.of(Application.class).verify();
}
```

예를 들어, `Order` 모듈이 `Inventory` 모듈의 내부(Internal) 클래스를 몰래 가져다 쓰면, 테스트가 실패합니다. 개발자의 실수로 스파게티 코드가 되는 것을 원천 차단하죠.

### ✅ 문서 자동화 (Documentation)

코드를 분석해서 모듈 간의 관계를 보여주는 **C4 다이어그램(UML)** 을 자동으로 생성해줍니다. "문서와 코드가 따로 노는" 문제를 해결할 수 있습니다.

### ✅ 이벤트 기반 통신 (Event Externalization)

모듈 간의 결합도를 낮추기 위해 **Spring ApplicationEvent**를 주로 사용하는데, Spring Modulith는 이를 더욱 강화하여 트랜잭션이 성공했을 때만 이벤트를 발행하거나, 카프카(Kafka) 같은 외부 브로커로 이벤트를 자동으로 연동해주는 기능을 제공합니다.

# 3. 마이그레이션 전략: 언제 써야 할까?

- **스타트업 / 신규 프로젝트**: 처음엔 Monolith로 시작하되, Spring Modulith로 구조를 잡아두세요. 나중에 트래픽이 터져서 MSA로 전환해야 할 때, 모듈 단위로 뚝 떼어내기만 하면 됩니다.
- **레거시 청산**: 스파게티가 된 기존 Spring Boot 프로젝트에 도입하여 의존성 사이클을 끊어내는 용도로도 훌륭합니다.

# 마치며

**Architecture is about boundaries.** (아키텍처는 경계에 관한 것이다)

Spring Modulith는 우리가 잊고 지냈던 이 격언을 코드 레벨에서 강제해주는 훌륭한 도구입니다. 복잡한 인프라 없이도 깔끔한 아키텍처를 유지하고 싶다면, 지금 바로 도입해 보세요!

복잡한 MSA는 이제 그만! Spring Modulith로 시작하는 모듈러 모놀리스

> "그냥 익숙한 거 쓰면 되는 거 아냐?" 물론 토이 프로젝트라면 그렇습니다. 하지만 엔터프라이즈 레벨로 넘어가면 **DB 엔진의 아키텍처 차이**가 서비스의 운명을 가르기도 합니다. 오늘은 관계형 데이터베이스(RDBMS)의 3대장, **PostgreSQL, MySQL, Oracle**을 기술적인 관점(Process, MVCC, Join, SQL)에서 적나라하게 비교해 봅니다.

# 1. 프로세스 vs 스레드 (Concurrency Model)

가장 근본적인 아키텍처 차이입니다.

### 🐘 PostgreSQL: Process 기반
* **구조**: 클라이언트 연결 하나당 OS 프로세스(`postgres`) 하나를 띄웁니다.
* **장점**: 프로세스 간 메모리가 완벽히 격리되어 있어, 하나가 죽어도 전체 DB는 끄떡없습니다 (안정성 甲).
* **단점**: 프로세스 생성 비용이 비쌉니다. (Connection Pool 필수)

### 🐬 MySQL (InnoDB): Thread 기반
* **구조**: 하나의 프로세스(`mysqld`) 안에서 여러 스레드가 동작합니다.
* **장점**: 스레드 생성 비용이 매우 저렴합니다. 연결이 많아도 가볍게 처리합니다.
* **단점**: 스레드 하나가 메모리를 잘못 건드리면 프로세스 전체가 죽을 수 있습니다 (이론상).

### 🏛 Oracle: Process 기반 (Linux 기준)
* PostgreSQL과 유사하게 프로세스 기반이지만, **SGA(System Global Area)**라는 거대한 공유 메모리 영역을 매우 정교하게 관리합니다.

# 2. MVCC 구현 방식 (UPDATE의 비밀)

동시성 제어를 위해 **Multi-Version Concurrency Control**을 어떻게 구현했는가?

### 🐘 PostgreSQL: Append Only
* **방식**: `UPDATE`를 하면 기존 데이터를 지우지 않고 **새 데이터를 추가**합니다. (구버전은 `xmax` 마킹)
* **특징**: 롤백이 엄청나게 빠릅니다. 하지만 쓰레기(Dead Tuple)가 쌓여서 **VACUUM**이 필수입니다.

### 🐬 MySQL (InnoDB): Undo Log
* **방식**: 새 데이터로 덮어쓰고, **옛날 데이터는 Undo Log라는 별도 공간**으로 옮깁니다.
* **특징**: 데이터 페이지가 깨끗하게 유지됩니다(VACUUM 불필요). 하지만 트랜잭션이 길어지면 Undo Log가 넘쳐서 성능이 급락할 수 있습니다.

### 🏛 Oracle: Undo Segment
* MySQL과 비슷하게 Undo 데이터를 별도 저장하지만, 이를 **Circular Buffer** 형태로 관리하여 매우 효율적입니다. (역시 돈값 합니다)

# 3. Join 알고리즘과 Optimizer

복잡한 쿼리를 얼마나 똑똑하게 처리하는가?

### 🐘 PostgreSQL
* **알고리즘**: `Nested Loop`, `Hash Join`, `Merge Join` 모두 지원.
* **Optimizer**: **학계 정석**에 가깝습니다. 통계 정보를 기반으로 매우 정확한 실행 계획을 짭니다. 복잡한 쿼리(Subquery, CTE, Window Function) 처리에 있어서는 오픈소스 중 최강입니다.

### 🐬 MySQL
* **알고리즘**: 오랫동안 `Nested Loop Join`만 지원하다가, 8.0부터 `Hash Join`이 추가되었습니다.
* **Optimizer**: 단순한 OLTP 쿼리에 최적화되어 있습니다. 복잡한 분석용 쿼리(OLAP)는 PostgreSQL보다 느린 경우가 많습니다.

# 4. 확장성 (Extensibility)

### 🐘 PostgreSQL: "DB를 만드는 프레임워크"
* **PostGIS**: 지리 정보 시스템(GIS)의 사실상 표준.
* **pgvector**: 벡터 DB 기능 추가.
* **Custom Type**: 사용자가 직접 데이터 타입을 만들 수 있습니다.
* 이 놀라운 확장성 덕분에 "개발자가 사랑하는 DB 1위"를 놓치지 않습니다.

### 🐬 MySQL: "웹 서비스의 표준"
* 확장성보다는 **복제(Replication)**와 **HA(고가용성)** 구축이 쉽고 레퍼런스가 압도적으로 많습니다. 웹 서비스 백엔드로서는 가장 무난한 선택입니다.

# 5. 요약: 뭘 써야 할까?

| 특징 | PostgreSQL | MySQL | Oracle |
| :--- | :--- | :--- | :--- |
| **적합한 용도** | 복잡한 쿼리, 데이터 분석, 지리 정보, R&D | 단순/대량 트랜잭션, 웹 서비스, 스타트업 | 금융권, 대규모 엔터프라이즈, 미션 크리티컬 |
| **SQL 표준** | 매우 준수함 (Standard-Compliant) | 다소 독자적임 (유연함) | 표준 + 강력한 PL/SQL |
| **비용** | 무료 (BSD) | 무료 (GPL) / 유료 (Enterprise) | **매우 비쌈** |

**결론**: 
돈이 넘쳐난다면 **Oracle**,
복잡한 데이터 모델과 분석이 필요하다면 **PostgreSQL**,
빠르게 치고 나가는 웹 서비스라면 **MySQL**을 추천합니다.

(하지만 최근 트렌드는 PostgreSQL이 MySQL의 파이를 꽤 많이 가져오는 추세입니다. 😉)

PostgreSQL vs MySQL vs Oracle: 아키텍처 관점에서 본 승자는?

> 회고록(回顧錄) 지나간 일을 돌이켜 생각하며 적은 기록.

# ⏳ Intro: 폭풍 같았던 2025년
2025년은 제가 살아온 그 어떤 해보다 강렬한 기억으로 남을 것 같습니다. 소수 정예로 시작했던 프로젝트의 난항, 중간 PM의 퇴사와 갑작스러운 PL 역할 수행, 그리고 번아웃 끝에 결정한 퇴사와 유럽 여행까지... 정말 롤러코스터 같은 1년을 보냈습니다. 다사다난했던 그 행적들을 되짚어보며, 개발자로서 그리고 한 사람으로서 무엇을 느끼고 배웠는지 정리해 보고자 합니다.

--- 

# 🏢 Chapter 1. 회사 생활: 시련과 성취 사이
## 1. 순조로웠던 시작, 그리고 균열
2025년의 시작은 긍정적이었습니다. 작년 말 진행했던 프로젝트 중간보고에서 고객사 사장님의 흡족한 반응을 이끌어내며 순조로운 출발을 알렸습니다. 하지만 3월, 프로젝트 종료를 불과 3개월 남겨두고 예기치 못한 변수가 발생했습니다. 기존 PM이 윗선과의 마찰로 갑작스럽게 퇴사하게 된 것입니다. 제대로 된 인수인계조차 없이 공백이 생겨버렸고, 그 자리는 PM 경험이 전무했던 제 사수가 맡게 되었습니다.

## 2. 개발자에서 '떠밀린' PL로
사수가 PM 역할을 맡게 되면서, 공석이 된 PL(Project Leader) 자리는 자연스럽게 제가 맡게 되었습니다. 문제는 인원 충원 없이 직책만 변경되었다는 점입니다.

이중고: PM이 된 사수는 개발에서 완전히 손을 뗐고, 저는 PL 업무와 기존 개발 업무를 혼자 온전히 감당해야 했습니다.

문서의 늪: 엎친 데 덮친 격으로 기존 PM이 작성한 WBS와 실제 진행률 간의 괴리가 심각했습니다. 이를 정상화하기 위해 개발은 손도 못 댄 채 한 달간 새로운 PM, 컨소시엄 PL들과 머리를 맞대고 문서 작업에만 매달려야 했습니다.

## 3. 새벽 3시의 사투, 그리고 종료 감리
어떻게든 프로젝트를 끌고 가 종료 감리 단계에 도달했습니다. 여기서 가장 큰 문제가 터졌습니다. 바로 DB 설계였습니다. 기존 PM이 DA 역할까지 겸하며 작성했던 DB 설계가, PM 변경과 고객사의 요구사항 변화로 인해 완전히 틀어져 버린 것입니다.

DB 재설계: 결국 후임도 없는 상황에서 제가 총대를 메야 했습니다. 용어 표준화부터 테이블, 컬럼 설계까지 모든 것을 다시 잡아야 했습니다.

극한의 일정: 두 달 동안 매일 새벽 2~3시에 퇴근했습니다. 신혼임에도 불구하고 집은 잠만 자는 곳이 되어버렸습니다. 묵묵히 저를 응원해 준 아내에게 미안함과 고마움이 교차하는 시간이었습니다.

## 4. 준공의 희열, 그러나...
6월 중순, 전주 고객사 본사에서 드디어 준공 도장을 받아냈습니다. 관계자들이 시스템을 테스트하고 이상 없음을 확인했을 때 느꼈던 그 희열감은 평생 잊지 못할 것입니다. 하지만 기쁨도 잠시, 유지보수 기간 동안 설계서에 없던 기능 추가 요구가 빗발쳤습니다. PM 경험이 부족했던 사수는 이를 방어하지 못하고 저에게 업무를 몰아주었고, 야근의 굴레는 계속되었습니다.

## 5. 가장 잘한 선택, 다짐 (퇴사)
결국 몸과 마음이 한계에 다다랐습니다. 더 이상 지체하면 저 자신을 잃을 것 같아 7월 초 사표를 던졌고, 7월 31일부로 퇴사를 확정 지었습니다.

퇴사를 결심한 데에는 제 건강뿐만 아니라 가족의 이유도 컸습니다. 한창 행복해야 할 신혼임에도 불구하고, 3월부터 이어진 프로젝트 위기와 잦은 주말 출근으로 인해 아내의 곁을 온전히 지켜주지 못했습니다. 텅 빈 집에서 홀로 기다렸을 아내에게 늘 미안한 마음뿐이었습니다. 그렇기에 퇴사는 저를 위한 선택이자, 우리 가정을 위한 결단이었습니다. 퇴사 후에는 그동안 뺏겼던 시간을 보상하며 아내에게 더 충실해야겠다고 굳게 다짐했습니다. 지금 돌이켜봐도 그때의 퇴사는 제 인생에서 가장 잘한 선택이었습니다.

--- 

# ✈️ Chapter 2. 쉼표: 유럽에서의 3주
![IMG_3928](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/c794763d-3943-4d93-b99b-c2f07a938b6a_IMG_3928.jpeg)
> 스위스 슈피츠 갔을때의 한컷입니다. 날이 엄청 좋았는데 이 이후 두시간 정도 뒤에 비가와서 얼른 들어가야했습니다 ㅠㅠ

퇴사 후 8월, 아내와 함께 3주간 유럽 여행(스위스, 스페인, 포르투갈)을 떠났습니다. 치열했던 전투 현장을 떠나 이국적인 풍경 속에 있으니, 그간의 힘들었던 기억들이 조금씩 정리되는 기분이었습니다. (여행에 대한 자세한 썰과 스위스의 절경을 담은 사진은 추후 별도 포스팅으로 다뤄보겠습니다. 기대해 주세요!)

이 여행은 단순한 휴식이 아니었습니다. 마음의 여유를 찾으며 지난 프로젝트의 경험을 객관적으로 회고하고, 앞으로의 방향성을 정립하는 귀중한 시간이 되었습니다.

--- 

# 💡 Chapter 3. 인사이트: SI를 넘어 다시 스타트업으로
여행 중 곰곰이 생각해보며, 제가 나아갈 다음 커리어에 대한 확신을 얻었습니다. 저는 다시 스타트업으로 돌아가려 합니다.

SI의 한계: 정해진 틀에 맞춰 납품만을 목적으로 하는 정적이고 수동적인 환경이 저와 맞지 않음을 절실히 느꼈습니다.

스타트업의 매력: 고객과 직접 소통하고, 피드백을 즉각적으로 서비스에 반영하는 동적인 환경이 그립습니다. 내 기술이 사용자에게 닿아 가치를 창출하는 과정을 주도적으로 이끌어갈 때, 개발자로서 가장 큰 역량을 발휘할 수 있다고 확신했습니다.

--- 

# 🚀 Chapter 4. 새로운 도전: Project 'GrowDo'
퇴사 후 10월, 우연한 기회로 초등학생 대상 코딩/AI 강의를 진행하며 알게 된 지인과 의기투합하여 새로운 프로젝트를 시작했습니다.

Project Name: GrowDo

Concept: 게이미피케이션(Gamification) 기반 목표 달성 플랫폼

Key Feature:
해외의 '캐릭터 육성' 방식 Todo-list와 달리, '실질적인 보상'에 초점을 맞췄습니다.

사용자가 Todo-list를 달성하고 도전과제를 깨면 포인트를 획득하고, 이를 실제 금전적 가치(상품권 등)로 교환할 수 있는 구조입니다.

단순한 사이드 프로젝트가 아닌, 저의 기술적 역량을 증명할 포트폴리오이자 실제 런칭을 목표로 달리고 있습니다. 취업 전까지 완성도 있게 마무리를 지어 곧 선보이겠습니다.

--- 

# 🏁 Outro: 2026년을 맞이하며
2025년은 퇴사, 유럽 여행, 그리고 새로운 프로젝트까지 쉴 새 없이 달려온 한 해였습니다. 현재는 다시 취준생(이자 1인 개발자) 신분이 되었지만, 단순히 쉬는 시간이 아닙니다. 지난 프로젝트로 인해 놓쳤던 최신 기술 트렌드를 따라잡고, 부족했던 부분을 채우며 'GrowDo'를 통해 다시 한번 도약할 준비를 하고 있습니다.

2026년에는 더 성장한 모습으로, 새로운 곳에서 제 역량을 마음껏 펼칠 수 있기를 기대합니다. 이 글을 읽으시는 모든 분들도 새해 복 많이 받으시길 바랍니다. 감사합니다.

[회고록] 가장 뜨거웠던 한 해, 2025년을 보내며

![image](https://memgraph.com/_next/image?url=%2Fimages%2Fblog%2Fgraphql-vs-rest-api%2Fcover.png&w=1920&q=75)

# 개요

> 2025년 현재, 클라이언트-서버 API 설계에는 두 가지 주요 접근 방식이 있습니다. REST API는 20년 넘게 업계 표준이었고, GraphQL은 2015년 오픈소스화 이후 빠르게 성장했습니다. 둘 다 프로덕션에서 충분히 검증되었으며, "최고"의 선택은 프로젝트 요구사항에 따라 달라집니다.

---
# REST API

## 핵심 개념

- HTTP 메서드(GET, POST, PUT, DELETE)를 사용한 리소스 기반 아키텍처
- 각 리소스는 고유한 URL을 가짐 (/users/123, /posts/456)
- JSON 형식의 응답 (사실상 표준)
- Stateless 통신

## 장점
### 1. 낮은 학습 곡선

- 대부분의 개발자가 이미 알고 있음
- HTTP 표준을 그대로 활용
- 새 팀원 온보딩이 빠름

### 2. 강력한 캐싱
```javascript
// HTTP 캐싱을 그대로 활용
GET /api/users/123
Cache-Control: max-age=3600
ETag: "abc123"

// CDN, 브라우저 캐시 모두 자동으로 동작
```
### 3. 성숙한 생태계

- Postman, Insomnia 같은 테스트 도구
- OpenAPI/Swagger로 자동 문서화
- 모든 HTTP 클라이언트 라이브러리 호환
- AWS API Gateway, Nginx 등 인프라 지원 완벽

### 4. 명확한 의미론
```javascript
GET /api/posts // 목록 조회
POST /api/posts // 생성
GET /api/posts/123 // 단건 조회
PUT /api/posts/123 // 전체 수정
PATCH /api/posts/123 // 부분 수정
DELETE /api/posts/123 // 삭제
```
### 5. 디버깅 용이

- 브라우저 Network 탭에서 바로 확인
- curl 한 줄로 테스트 가능
- 로그에서 URL만 봐도 무슨 요청인지 파악

## 단점
### 1. Over-fetching
```javascript
// 사용자 이름만 필요한데 모든 필드를 받음
GET /api/users/123
{
 "id": 123,
 "name": "홍길동", // 필요한 필드
 "email": "hong@example.com", // 불필요
 "phone": "010-1234-5678", // 불필요
 "address": { ... }, // 불필요
 "created_at": "...", // 불필요
 "updated_at": "..." // 불필요
}
```

### 2. Under-fetching (N+1 문제)
```javascript
// 게시글 목록
GET /api/posts
[{ id: 1, title: "...", author_id: 10 }, ...]
`
// 각 게시글의 작성자 정보를 가져오려면 추가 요청 필요
GET /api/users/10
GET /api/users/11
GET /api/users/12
// ...

// 또는 엔드포인트를 추가로 만들어야 함
GET /api/posts?include=author
```

### 3. 버전 관리의 복잡성
```javascript
// API가 변경되면 버전을 올려야 함
/api/v1/users // 구버전 유지
/api/v2/users // 신규 필드 추가
/api/v3/users // 구조 변경

// 여러 버전을 동시에 유지보수해야 함
```

### 4. 엔드포인트 폭발
```javascript
// 다양한 요구사항에 맞춰 엔드포인트가 계속 추가됨
GET /api/posts
GET /api/posts?status=published
GET /api/posts?author=123
GET /api/posts?author=123&status=published
GET /api/posts/trending
GET /api/posts/recommended
GET /api/users/123/posts
// ...
실무 예시
javascript// 사용자 정보와 최근 게시글 5개를 가져오려면
const user = await fetch('/api/users/123').then(r => r.json());
const posts = await fetch(`/api/users/123/posts?limit=5`).then(r => r.json());

// 2번의 네트워크 요청 필요
// 각 게시글의 댓글 수까지 필요하면 3번째 요청 또는 복잡한 엔드포인트 설계 필요
```
---
# GraphQL
## 핵심 개념

> - Facebook(현 Meta)이 2012년 개발, 2015년 오픈소스화
> - 쿼리 언어로 클라이언트가 필요한 데이터 구조를 명시
> - 단일 엔드포인트 (POST /graphql)
> - 강력한 타입 시스템 (Schema Definition Language)
> - 현재는 Linux Foundation 산하 GraphQL Foundation에서 관리

## 장점
### 1. 정확한 데이터 요청

```graphql
query {
 user(id: 123) {
 name # 필요한 필드만 명시
 email
 }
}

# 응답
{
 "data": {
 "user": {
 "name": "홍길동",
 "email": "hong@example.com"
 }
 }
}
```
### 2. 단일 요청으로 복잡한 데이터 구조
```graphql
query {
 user(id: 123) {
 name
 email
 posts(limit: 5) {
 title
 createdAt
 comments(limit: 3) {
 content
 author {
 name
 avatar
 }
 }
 }
 }
}

# 한 번의 요청으로 사용자 → 게시글 → 댓글 → 작성자 모두 가져옴
```
### 3. 강력한 타입 시스템
```graphql
type User {
 id: ID!
 name: String!
 email: String!
 posts: [Post!]!
}

type Post {
 id: ID!
 title: String!
 content: String!
 author: User!
 comments: [Comment!]!
}

# IDE에서 자동완성, 타입 체크 가능
# 컴파일 타임에 오류 발견
```

### 4. 버전 관리 불필요
```graphql
type User {
 id: ID!
 name: String!
 email: String!
 phone: String @deprecated(reason: "Use phoneNumber instead")
 phoneNumber: String
}

# 필드 추가/deprecated만으로 관리
# 클라이언트는 필요한 필드만 요청하므로 호환성 유지
```

### 5. 자가 문서화
```graphql
# 스키마 자체가 문서
# GraphQL Playground에서 모든 타입, 필드, 인자 확인 가능
# 별도 문서 작성 불필요
6. 실시간 기능 (Subscriptions)
graphqlsubscription {
 newMessage(chatId: "123") {
 id
 content
 author {
 name
 }
 }
}

# WebSocket으로 실시간 업데이트
# 채팅, 알림, 실시간 대시보드 구현 용이
```
## 단점
### 1. 학습 곡선

- GraphQL 쿼리 언어 학습 필요
- Schema 설계 패턴 학습 필요
- Resolver 개념 이해 필요
- 팀 전체가 익숙해지기까지 시간 소요

### 2. 캐싱 복잡성
```javascript
// REST는 URL 기반 캐싱
GET /api/users/123 → 캐시 키: /api/users/123

// GraphQL은 쿼리 내용이 캐시 키
// POST 요청이라 HTTP 캐싱 불가
// Apollo Client, urql 같은 전용 캐싱 필요
```
### 3. 쿼리 복잡도 관리
```graphql
# 악의적이거나 비효율적인 쿼리 가능
query {
 users {
 posts {
 comments {
 author {
 posts {
 comments {
 # 무한 중첩...
 }
 }
 }
 }
 }
 }
}

# Depth limiting, Query complexity analysis 필수
```

### 4. N+1 문제
```javascript
// Resolver가 비효율적이면 성능 문제
const resolvers = {
 Post: {
 author: (post) => {
 return db.users.findById(post.authorId); // 각 게시글마다 DB 쿼리!
 }
 }
};

// DataLoader로 해결 필요
const userLoader = new DataLoader(ids => 
 db.users.findByIds(ids) // 배치 처리
);
```

### 5. 파일 업로드
```javascript
// GraphQL 표준이 아님
// multipart/form-data 별도 구현 필요
// 또는 별도 REST 엔드포인트 사용
```
### 6. 에러 처리
```javascript
// HTTP 상태 코드를 활용할 수 없음
// 쿼리 일부만 실패해도 200 OK 반환
{
 "data": {
 "user": null // 실패
 },
 "errors": [{
 "message": "User not found",
 "path": ["user"]
 }]
}

// 클라이언트가 data와 errors를 모두 확인해야 함
```

## 실무 예시
```javascript
// Apollo Client 예시
const { data, loading, error } = useQuery(
gql`
 query GetUserWithPosts($userId: ID!) {
 user(id: $userId) {
 name
 email
 posts(limit: 5) {
 title
 createdAt
 commentCount # 서버에서 계산된 필드
 }
 }
 }
`,{
 variables: { userId: '123' }
});

// 한 번의 요청으로 모든 데이터
// 타입 안정성 보장
// 캐싱 자동 처리
```
---
# 성능 비교 (2025년 기준)
- 페이로드 크기
```javascript
// REST - 불필요한 필드 포함
{
 "id": 123,
 "name": "홍길동",
 "email": "hong@example.com",
 "phone": "010-1234-5678",
 "address": { /* ... */ },
 "preferences": { /* ... */ },
 "created_at": "2024-01-15T10:30:00Z",
 "updated_at": "2025-02-20T14:20:00Z"
}
// ~800 bytes

// GraphQL - 필요한 필드만
{
 "data": {
 "user": {
 "name": "홍길동",
 "email": "hong@example.com"
 }
 }
}
// ~150 bytes
```

**실측 데이터** (복잡한 중첩 쿼리 기준):
- REST: 평균 3-5개 요청, 총 ~2-3MB
- GraphQL: 1개 요청, ~800KB

## 네트워크 레이턴시

### REST: 
1. 요청 1: 사용자 정보 (100ms)
2. 요청 2: 게시글 목록 (120ms) 
3. 요청 3: 댓글 수 (90ms)
4. 총: ~310ms + 네트워크 오버헤드

### GraphQL:
1. 단일 요청: ~180ms

## 개발 속도

1. REST: 프론트엔드가 새 데이터 필요 → 백엔드 엔드포인트 추가 → 배포 → 사용
2. GraphQL: 프론트엔드가 새 데이터 필요 → 스키마에 이미 있으면 바로 쿼리 작성
---

# 2025년 실무 트렌드
## **REST**가 여전히 우세한 영역
### 1. 공개 API
```javascript
// Stripe, GitHub, Twilio 등 대부분의 공개 API는 REST
GET https://api.stripe.com/v1/customers/cus_xxx
Authorization: Bearer sk_xxx
```

외부 개발자가 사용하기 쉬움
문서화가 직관적
curl로 바로 테스트 가능

### 2. 간단한 CRUD 애플리케이션
```javascript
// To-do 앱, 블로그, 간단한 관리 시스템
GET /api/todos
POST /api/todos
PUT /api/todos/123
DELETE /api/todos/123
```
### 3. 레거시 시스템 통합

- 기존 REST API 인프라 활용
- 마이그레이션 비용 없음

## GraphQL이 강세인 영역
### 1. 모바일 앱
```graphql
# 데이터 사용량 최소화
# 배터리 절약
# 3G/4G 환경에서도 빠른 응답
query {
 feed(limit: 10) {
 id
 thumbnail # 작은 이미지만
 title
 }
}
```
### 2. 복잡한 데이터 관계
```graphql
# E-commerce, SNS, 협업 도구
query {
 product(id: "123") {
 name
 price
 reviews(limit: 5) {
 rating
 comment
 author {
 name
 verified
 }
 }
 relatedProducts(limit: 3) {
 name
 price
 thumbnail
 }
 }
}
```

### 3. BFF (Backend For Frontend) 패턴
*BFF패턴에 대해선 나중에 따로 다룰 예정입니다*

### 4. 실시간 대시보드
```graphql
subscription {
 orderUpdates {
 orderId
 status
 timestamp
 }
}
# WebSocket으로 실시간 업데이트
```
---

# 선택 가이드
## REST API가 적합할 경우:
1. 공개 API 또는 파트너 API
2. 간단한 CRUD 위주 애플리케이션
3. 팀이 GraphQL 학습 시간이 없는 경우
4. HTTP 캐싱을 적극 활용하고 싶은 경우
5. 레거시 시스템과 통합해야 하는 경우
6. 파일 업로드/다운로드가 주요 기능인 경우

### 구체적 예시:

1. 블로그 플랫폼 (Medium, WordPress)
2. 결제 서비스 API (Stripe, PayPal)
3. OAuth 인증 서비스
4. 간단한 관리자 대시보드


## GraphQL이 적합할 경우:

1. 모바일 앱 (데이터 효율성 중요)
2. 복잡한 데이터 관계가 많은 경우
3. 프론트엔드 요구사항이 자주 변경되는 경우
4. 실시간 기능이 필요한 경우
5. 여러 데이터 소스를 통합하는 BFF 구축
6. 타입 안정성이 중요한 경우

### 구체적 예시:

1. SNS 플랫폼 (Facebook, Instagram)
2. E-commerce (Shopify)
3. 협업 도구 (Notion, Slack)
4. 복잡한 SaaS 대시보드

---
# 실제 기업 사례 (2025년)

## REST 사용사례

- Stripe: 결제 API (외부 개발자 친화적)
- Twilio: SMS/음성 API
- AWS: 대부분의 AWS 서비스

## GraphQL 사용사례

- GitHub: API v4는 GraphQL
- Shopify: Admin API와 Storefront API
- Netflix: 내부 API (Falcor, GraphQL 유사)

## 둘 다 사용하는 사례

- GitHub: REST (v3) + GraphQL (v4)
- Contentful: REST + GraphQL
- Hasura: 자동으로 DB에서 GraphQL 생성

## 하이브리드 접근
실무에서는 둘을 함께 사용하는 경우가 많습니다:
```javascript
// 공개 API: REST
app.get('/api/v1/products/:id', ...)

// 웹/모바일 앱: GraphQL
app.post('/graphql', graphqlHTTP({ schema }))

// 파일 업로드: REST
app.post('/api/upload', upload.single('file'), ...)

// 실시간 알림: GraphQL Subscription
```
### 장점:
1. 각 기술의 강점을 활용
2. 점진적 마이그레이션 가능
3. 레거시 호환성 유지

## 마이그레이션 전략
REST → GraphQL
```javascript
// 1단계: GraphQL 서버가 REST API를 래핑
const resolvers = {
 Query: {
 user: (_, { id }) => fetch(`/api/users/${id}`).then(r => r.json())
 }
}

// 2단계: 점진적으로 Resolver를 직접 DB 접근으로 변경
const resolvers = {
 Query: {
 user: (_, { id }) => db.users.findById(id)
 }
}

// 3단계: 프론트엔드를 하나씩 GraphQL로 전환
```

### 비용 고려사항

#### **REST 추가 비용** 
- 거의 없음 (표준 HTTP)
#### **GraphQL 추가 비용**
1. 개발: 스키마 설계, Resolver 구현
2. 인프라: Apollo Server, DataLoader 등
3. 모니터링: Query complexity, 성능 추적
4. 학습: 팀 교육 시간

# 결론

**2025년 현재, 둘 다 성숙하고 프로덕션에서 검증된 기술이며 프로젝트에 맞게 사용하는게 중요할 것 같습니다.**

## 실무 추천
### 1. 스타트업/신규 프로젝트:
- 작게 시작: REST로 MVP 개발
- 복잡해지면: GraphQL 고려
- 필요시: 하이브리드 접근

### 2. 대규모 프로젝트:
- 내부용: GraphQL (효율성)
- 외부용: REST (접근성)
- 실시간: GraphQL Subscriptions

# 마지막으로 기술 선택시 가장 중요한 것
1. 팀의 경험
2. 프로젝트 요구사항
3. 장기 유지보수 가능성 고려

# 느낀점
REST API는 워낙 익숙하게 써오다 보니 크게 생각하지 않았지만, 블로그를 만들면서 처음 GraphQL을 제대로 다뤄보니 둘의 장단점이 확실히 비교를 할 수 있었습니다. 
특히 요즘 GraphQL은 Apollo까지 함께 이해해야 해서 초반에는 머리가 지끈거릴 정도로 어렵고, 학습곡선도 짧지 않지만 그래도 시간이 지나 익숙해지니까 확실히 편한 면이 많았습니다. 

개인 프로젝트라도 이렇게 GraphQL을 직접 적용해보고, 그 경험을 바탕으로 글까지 정리해볼 수 있다는 게 참 의미 있고 좋은 기회였던 것 같습니다.

GraphQL vs REST API : 2025년 기준으로 다시 생각해보기

> "MySQL이랑 PostgreSQL이랑 뭐가 달라요?" 면접에서 가장 많이 나오는 질문 중 하나이자, 시스템 아키텍처를 설계할 때 가장 고민되는 지점입니다. 단순히 "Postgres가 기능이 더 많다" 정도가 아니라, **내부적으로 데이터를 어떻게 저장하고 관리하는지**를 이해해야 진짜 성능을 끌어낼 수 있습니다. 이 글에서는 PostgreSQL을 지탱하는 **4가지 핵심 기둥(MVCC, WAL, VACUUM, Buffer)**을 아주 상세하게 파헤쳐 봅니다.

# 1. 아키텍처 개요: 프로세스 기반 모델

MySQL이 스레드(Thread) 기반인 것과 달리, PostgreSQL은 **프로세스(Process) 기반**입니다.
클라이언트 연결이 들어올 때마다 `postgres` 메인 프로세스(Postmaster)가 새로운 자식 프로세스(Backend Process)를 `fork()`합니다.

* **장점**: 프로세스 간 메모리가 격리되어 있어, 하나가 죽어도 전체 DB가 죽지 않습니다. 안정성이 매우 높습니다.
* **단점**: 연결 생성 비용이 비쌉니다. 그래서 **PgBouncer** 같은 Connection Pooler가 사실상 필수입니다.

# 2. MVCC (Multi-Version Concurrency Control)

동시성을 제어하는 PostgreSQL의 심장입니다. **"읽는 자는 쓰는 자를 막지 않고, 쓰는 자는 읽는 자를 막지 않는다"**는 원칙을 지킵니다.

### 🛠 동작 원리: UPDATE는 사실 INSERT다?

MySQL(InnoDB)은 Undo Log를 사용해 이전 버전을 관리하지만, PostgreSQL은 **데이터 페이지(Heap)에 튜플의 예전 버전과 새 버전을 함께 저장**합니다.

1. 데이터를 `UPDATE` 하면, 기존 행을 덮어쓰는 게 아니라 **새로운 행(New Tuple)을 추가**합니다.
2. 기존 행(Old Tuple)은 `xmax` 필드에 "삭제된 트랜잭션 ID"를 마킹하고 투명인간 취급합니다.
3. 각 트랜잭션은 자신의 시작 시점에 따라 어떤 버전을 볼지(`xmin`, `xmax`) 결정합니다.

이 구조 덕분에 롤백(Rollback)이 매우 빠르지만, 치명적인 부작용이 생깁니다. 바로 **Bloat(비만) 현상**입니다. (뒤에서 다룰 VACUUM이 필요한 이유)

# 3. VACUUM: 쓰레기 청소부

앞서 말했듯, `UPDATE`나 `DELETE`가 발생하면 디스크에는 "죽은 튜플(Dead Tuple)"이 계속 쌓입니다. 이걸 방치하면 테이블 크기가 무한히 커지고 조회 속도가 느려집니다.

### 🧹 AutoVacuum
PostgreSQL은 백그라운드에서 주기적으로 `AutoVacuum` 데몬을 실행하여 죽은 튜플을 청소하고, 해당 공간을 **재사용 가능하도록 마킹(FSM: Free Space Map)**합니다.

* **주의할 점**: 일반 `VACUUM`은 OS에게 디스크 공간을 반납하지 않습니다. (파일 크기가 줄어들지 않음)
* **VACUUM FULL**: 디스크 공간을 완전히 회수하지만, 테이블에 **Exclusive Lock**을 걸어버려서 운영 중엔 절대 쓰면 안 됩니다.

# 4. WAL (Write-Ahead Logging): 데이터의 생명줄

데이터베이스의 가장 중요한 미덕은 **"전원이 뽑혀도 데이터는 날아가면 안 된다"**입니다. 이를 보장하는 것이 WAL입니다.

### 📝 동작 방식
1. 데이터를 변경하면, 실제 디스크 파일(Heap)을 고치기 전에 먼저 **WAL 로그 파일**에 변경 내용을 순차적으로(Sequential) 기록합니다.
2. `fsync()`를 통해 WAL이 디스크에 안전하게 저장된 것이 확인되면 클라이언트에게 "성공" 응답을 보냅니다.
3. 실제 데이터 파일(Data File)은 나중에 백그라운드 프로세스(`Checkpointer`)가 천천히 변경합니다.

이 WAL 파일은 **Replication(복제)**의 핵심이기도 합니다. Master DB가 Slave DB에게 이 WAL 스트림을 쏘아주면, Slave가 그걸 받아 똑같이 재현(Replay)하는 방식입니다.

# 5. Shared Buffer: 메모리 관리

PostgreSQL은 자체적인 캐시 영역인 **Shared Buffer**를 관리합니다. 하지만 특이하게도 OS의 파일 시스템 캐시(Page Cache)와 이중으로 캐싱하는 구조(Double Buffering)를 가집니다.

* **튜닝 포인트**: 보통 전체 RAM의 **25~40%** 정도를 `shared_buffers`에 할당하는 것이 권장됩니다. (너무 많이 주면 OS 캐시 효율이 떨어짐)

# 6. TOAST (The Oversized-Attribute Storage Technique)

PostgreSQL의 페이지 크기는 기본 8KB입니다. 만약 8KB보다 큰 데이터(긴 텍스트나 이미지 등)가 들어오면 어떻게 할까요?
PostgreSQL은 이를 자동으로 압축하고 조각내어 별도의 **TOAST 테이블**에 저장합니다. 사용자는 이를 의식하지 않고 그냥 쓰면 됩니다.

# 마치며

PostgreSQL은 "대학원생들이 만든 DB"라는 별명처럼 학구적이고 정교하게 설계되어 있습니다.

1. **MVCC** 덕분에 동시성이 뛰어나지만,
2. **Dead Tuple** 때문에 **AutoVacuum** 튜닝이 필수적이며,
3. **WAL**을 통해 강력한 데이터 무결성과 복제를 지원합니다.

이 원리들을 이해하고 나면, `vacuum_cost_limit` 같은 설정값이 왜 존재하는지, 왜 대량 `UPDATE`를 조심해야 하는지 비로소 보이기 시작할 것입니다. 🐘

PostgreSQL 완벽 가이드: MVCC부터 WAL까지 아키텍처 깊게 파기

> 2013년, Facebook(현 Meta)이 "우리는 DOM을 직접 조작하지 않겠다"며 React를 오픈소스로 공개했을 때, 많은 개발자들은 의아해했습니다. 하지만 선언적 UI와 단방향 데이터 흐름은 곧 프론트엔드 개발의 표준이 되었죠. React가 어떻게 변화해왔는지, 주요 버전별 특징을 통해 그 흐름을 짚어봅니다.

![React Evolution](https://images.unsplash.com/photo-1633356122544-f134324a6cee?q=80&w=2070&auto=format&fit=crop)

# 1. 초기 React: Class Component와 생명주기 (v0.x ~ v15)

초기의 React는 객체 지향적인 접근 방식을 취했습니다. `React.createClass`나 ES6 `class extends React.Component`를 사용하여 컴포넌트를 정의했죠.

- **특징**: `this.state`로 상태를 관리하고, `componentDidMount`, `componentDidUpdate` 같은 생명주기(Lifecycle) 메서드로 시점을 제어했습니다.
- **문제점**: 
 - `this` 바인딩 문제로 인한 혼란.
 - 관심사의 분리 실패: 하나의 생명주기 메서드 안에 API 호출, 이벤트 리스너 등록 등 서로 다른 로직이 뒤섞임.
 - 재사용성 부족: HOC(Higher Order Component)나 Render Props 패턴이 나왔지만 코드가 복잡해짐(Wrapper Hell).

# 2. React 16: Fiber 아키텍처와 혁신의 시작 (2017)

React의 코어를 밑바닥부터 다시 짠 **Fiber 아키텍처**가 도입되었습니다. 겉으로 보이는 API 변화보다는 내부적인 렌더링 엔진의 교체가 핵심이었습니다.

- **주요 기능**:
 - **Error Boundaries**: 컴포넌트 에러를 잡아내는 `componentDidCatch` 도입.
 - **Portals**: 부모 컴포넌트의 DOM 계층 구조 바깥에 렌더링 가능 (모달 구현에 혁명).
 - **Fragments**: 불필요한 `div` 래퍼 없이 여러 엘리먼트 반환 가능.

# 3. React 16.8: Hooks의 등장 (2019) ⚡️

React 역사상 가장 충격적이고 위대한 업데이트입니다. **"함수형 컴포넌트에서도 상태를 가질 수 있다"**는 개념이 도입되었습니다.

- **Hooks (useState, useEffect)**:
 - Class를 작성할 필요가 없어졌습니다.
 - `this`의 고통에서 해방되었습니다.
 - 로직을 커스텀 훅(Custom Hook)으로 분리하여 재사용하기가 너무나 쉬워졌습니다.
- **결과**: Class Component는 레거시가 되었고, React 생태계는 함수형으로 대통합을 이룹니다.

# 4. React 17: 위대한 준비 (2020)

"No New Features"라는 슬로건을 걸고 나온 버전입니다. 기능 추가보다는 **점진적 업그레이드**를 위한 내부 공사에 집중했습니다.

- **이벤트 위임 변경**: `document`가 아닌 `root` 노드에 이벤트를 위임하여, 마이크로 프론트엔드 아키텍처나 다른 버전의 React와 공존하기 쉬워졌습니다.

# 5. React 18: 동시성(Concurrency)의 시대 (2022)

React가 렌더링을 멈추거나, 쪼개서 수행할 수 있게 되었습니다.

- **Concurrent Mode**:
 - **Automatic Batching**: 여러 상태 업데이트를 한 번의 리렌더링으로 묶어줌.
 - **Transitions (useTransition)**: UI 업데이트의 우선순위를 지정하여, 무거운 렌더링 중에도 입력창이 버벅이지 않게 함.
 - **Suspense**: 데이터 로딩 상태를 선언적으로 처리.

# 6. React 19: 서버가 된 컴포넌트 (2024~)

이제 React는 단순한 클라이언트 라이브러리를 넘어 풀스택 프레임워크를 위한 아키텍처로 진화하고 있습니다.

- **RSC (React Server Components)**: 컴포넌트가 서버에서 렌더링되고, 결과 HTML만 클라이언트로 전송됩니다. 번들 사이즈가 0(Zero Bundle Size)이 될 수 있습니다.
- **Actions**: `<form>` 제출 처리를 위한 서버 액션을 기본 지원합니다.
- **React Compiler**: `useMemo`, `useCallback` 같은 수동 최적화를 컴파일러가 알아서 해주는 시대가 오고 있습니다 (React Forget).

# 마치며

React는 멈추지 않습니다. View 라이브러리에서 시작하여 이제는 메타 프레임워크(Next.js, Remix)의 기반 엔진이 되었습니다.
Class 시절부터 해오신 분들에게는 격세지감이, 새로 시작하는 분들에게는 RSC라는 새로운 파도가 느껴지실 겁니다. 앞으로의 10년은 또 어떻게 변할까요? ⚛️

React의 진화: Class Component에서 Server Component까지

> Node.js 생태계는 자유롭습니다. Express.js로 시작하면 폴더 구조부터 에러 처리까지 모든 것을 개발자가 직접 정해야 하죠. 하지만 팀 규모가 커지면 이 "자유"는 곧 "파편화"라는 독이 됩니다. A 개발자와 B 개발자의 코드 스타일이 너무 달라서 협업이 힘들어지는 것이죠. 이 문제를 해결하기 위해 등장한, **"Node.js 진영의 Spring Boot"**라 불리는 **NestJS**에 대해 아주 깊이 있게(Deep Dive) 알아봅니다.

![NestJS Logo](https://nestjs.com/img/nest-og.png)

# 1. NestJS란 무엇인가?

NestJS는 **TypeScript**를 기본으로 지원하는 **서버 사이드 프레임워크**입니다. 내부적으로는 Express(기본값)나 Fastify를 래핑해서 동작하지만, 개발자에게는 완전히 다른 경험을 제공합니다.

### 💡 왜 만들어졌을까?
NestJS의 창시자 **Kamil Myśliwiec**은 Angular(프론트엔드 프레임워크)의 아키텍처에서 큰 영감을 받았습니다. Angular처럼 **모듈화(Modularity)**, **의존성 주입(DI)**, **데코레이터(Decorator)** 패턴을 서버 사이드에 도입하여, 대규모 애플리케이션에서도 유지보수가 쉬운 구조를 만들고자 했습니다.

# 2. 핵심 철학 및 아키텍처 (The Core)

NestJS를 지탱하는 3가지 핵심 기둥이 있습니다. 이 구조를 이해하면 NestJS의 80%를 이해한 것입니다.

### ✅ 모듈 (Modules)
애플리케이션을 기능 단위로 나누는 가장 큰 덩어리입니다. `@Module` 데코레이터를 사용하며, 관련된 컨트롤러와 서비스를 묶어 캡슐화합니다.

```typescript
// user.module.ts
@Module({
 imports: [TypeOrmModule.forFeature([User])], // 다른 모듈 가져오기
 controllers: [UserController], // 이 모듈의 컨트롤러
 providers: [UserService], // 이 모듈의 서비스 (비즈니스 로직)
 exports: [UserService], // 다른 모듈에서 쓸 수 있게 공개
})
export class UserModule {}
```
모든 NestJS 앱은 적어도 하나의 `AppModule`(루트 모듈)을 가집니다. 마치 레고 블록처럼 모듈을 조립해서 서버를 완성합니다.

### ✅ 컨트롤러 (Controllers)
들어오는 요청(Request)을 받고 응답(Response)을 반환하는 역할을 합니다. `@Controller`, `@Get`, `@Post` 같은 데코레이터를 사용하여 라우팅을 정의합니다.

```typescript
// user.controller.ts
@Controller(users)
export class UserController {
 constructor(private readonly userService: UserService) {} // DI (의존성 주입)

 @Get(:id)
 findOne(@Param(id) id: string) {
 return this.userService.findOne(id);
 }
}
```

### ✅ 프로바이더 (Providers) & DI
비즈니스 로직, DB 접근 등 실제 "일"을 하는 친구들입니다. NestJS의 핵심인 **의존성 주입(Dependency Injection)** 시스템을 통해 관리됩니다.

* **IoC (제어의 역전)**: 개발자가 직접 `new UserService()`를 하지 않습니다. NestJS 런타임(IoC 컨테이너)이 알아서 객체를 만들고, 필요한 곳(Controller)에 꽂아줍니다.
* 이 덕분에 테스트 코드 작성 시 Mock 객체로 갈아끼우기가 매우 쉬워집니다.

# 3. NestJS만의 강력한 기능들

Express에서는 직접 구현해야 했던 고급 기능들이 NestJS에는 기본 내장되어 있습니다.

### 🛡 파이프 (Pipes) - 유효성 검사
요청 데이터가 올바른지 검사(Validation)하거나 변환(Transformation)합니다. `class-validator` 라이브러리와 함께 쓰면 DTO(Data Transfer Object)만 정의해도 자동으로 검사가 끝납니다.

```typescript
@Post()
create(@Body(ValidationPipe) createUserDto: CreateUserDto) {
 // createUserDto는 이미 검증이 끝난 안전한 데이터!
 return this.userService.create(createUserDto);
}
```

### 🛡 가드 (Guards) - 인증/인가
요청을 처리하기 전에 "이 사용자가 권한이 있는가?"를 검사합니다. JWT 토큰 검사 등을 여기서 처리하면 비즈니스 로직이 깔끔해집니다.

### 🛡 인터셉터 (Interceptors)
요청 전/후에 로직을 끼워넣습니다. 응답 데이터를 가공하거나(직렬화), 실행 시간을 로깅하는 데 쓰입니다. (AOP와 유사)

# 4. 실무 활용: 현재 어디에 쓰이는가?

2025년 현재, NestJS는 단순한 웹 서버를 넘어 다양한 영역에서 표준처럼 쓰이고 있습니다.

### 🏢 엔터프라이즈 백엔드
대한민국은 아무래도 스프링 공화국이어서 여러 예외들이 있지만 해외의 경우에는 스타트업뿐만 아니라 대기업에서도 Node.js로 마이그레이션할 때 NestJS를 1순위로 고려합니다. 유지보수성과 확장성 때문입니다. Spring을 쓰던 인력들이 Node.js로 넘어올 때 가장 이질감이 적은 선택지이기도 합니다.

### 🔗 마이크로서비스 (MSA)
NestJS는 기본적으로 모놀리스뿐만 아니라 MSA를 강력하게 지원합니다. `@nestjs/microservices` 패키지를 통해 RabbitMQ, Kafka, gRPC, Redis Pub/Sub 등을 손쉽게 연동할 수 있습니다. 코드 몇 줄만 바꾸면 HTTP 서버가 gRPC 서버로 변신합니다.

### 🛠 BFF (Backend For Frontend)
프론트엔드(Next.js, React)와 밀접하게 일하는 팀에서, API를 집계하고 가공하는 중간 계층 서버로 NestJS를 많이 사용합니다. TypeScript를 공유할 수 있다는 장점 덕분에 풀스택 개발 생산성이 매우 높습니다.

# 마치며: NestJS를 배워야 할까요?

**되도록 배우는것을 권장 드립니다.**
백엔드 개발자라면 AI 시대에는 Spring, Spring Boot 만으로는 부족합니다. 채용 공고를 봐도 "NestJS 경험 우대"가 많아지고 있습니다.

Express의 자유로움에 지쳐 "정해진 정답"을 찾고 계셨다면, 혹은 Spring Boot처럼 견고한 아키텍처를 Node.js에서도 누리고 싶다면, NestJS가 최고의 선택이 될 것입니다. 지금 바로 `npm i -g @nestjs/cli`를 입력해 보세요!

Node.js의 Spring Boot? NestJS 완벽 해부 (기본 골자부터 실무 활용까지)

> Java 21 LTS가 출시되면서 **Virtual Threads(가상 스레드, Project Loom)**가 정식 기능이 되었습니다. 많은 개발자들이 "이제 WebFlux(Reactive)의 복잡함 없이도 고성능 비동기 처리가 가능하다!"며 환호했죠. 하지만 실무 도입 1년이 지난 지금, 해외 커뮤니티에서는 **예상치 못한 성능 저하와 OOM(Out of Memory)** 사례들이 보고되고 있습니다. 오늘은 단순한 찬양글이 아닌, **실전에서 Virtual Threads를 도입할 때 마주하게 될 함정들과 그 해결책**을 깊이 있게 다뤄봅니다.

![Virtual Threads Architecture](https://miro.medium.com/v2/resize:fit:1400/1*rQyC5L-g_k-b0iHqD3HqD3.png)

# 1. Virtual Threads의 환상과 실제

기존의 Java 스레드(Platform Thread)는 OS 스레드와 1:1로 매핑되는 비싼 자원이었습니다. 그래서 톰캣(Tomcat) 스레드 풀을 200개 정도로 제한해서 썼죠.
반면, **Virtual Threads는 JVM이 관리하는 경량 스레드**로, OS 스레드 하나 위에서 수천, 수만 개가 번갈아 가며 실행될 수 있습니다 (M:N 모델).

Spring Boot 3.2부터는 설정 한 줄이면 바로 적용할 수 있습니다.

```yaml
spring:
 threads:
 virtual:
 enabled: true
```

이 한 줄로 I/O Blocking이 발생할 때마다 JVM이 알아서 스레드를 스위칭해주니, 이론상 처리량(Throughput)이 폭발적으로 늘어나야 합니다. **하지만 현실은 달랐습니다.**

# 2. 치명적인 함정: Pinning (고정 현상)

Virtual Threads 도입 후 가장 많이 겪는 성능 이슈의 주범입니다.

### 🚨 현상
가상 스레드가 I/O 작업을 만나면 캐리어 스레드(OS 스레드)를 놓아주고 쉬어야 하는데, 특정 상황에서는 **OS 스레드를 붙잡고 놓지 않는 현상**이 발생합니다. 이를 **Pinning**이라고 합니다.

### 🔍 원인
1. **`synchronized` 블록 내부**: Java의 전통적인 동기화 블록 안에 있을 때.
2. **네이티브 메서드(JNI) 호출 시**.

```java
// ❌ Pinning 유발 코드 예시
synchronized (lock) {
 // 여기서 DB 조회 같은 I/O를 하면
 // 캐리어 스레드가 블로킹되어 전체 성능이 급락합니다.
 repository.findById(id);
}
```

많은 JDBC 드라이버나 구형 라이브러리들이 내부적으로 `synchronized`를 사용하고 있습니다. Virtual Threads를 켰는데 갑자기 전체 서버가 멈춘다면 99% 이 문제입니다.

### ✅ 해결책
* `synchronized` 대신 **`ReentrantLock`**을 사용하세요. `ReentrantLock`은 Pinning을 유발하지 않습니다.
* 라이브러리 버전을 최신으로 올리세요. (MySQL Driver, Jackson 등 주요 라이브러리들은 이미 패치되었습니다.)
* JVM 옵션 `-Djdk.tracePinnedThreads=full`을 켜서 Pinning이 발생하는 지점을 로그로 추적하세요.

# 3. 메모리 폭발: ThreadLocal의 배신

기존 스레드 모델에서는 스레드 수가 적었기 때문에 `ThreadLocal`에 무거운 객체(예: DateFormat, UserContext)를 캐싱하는 패턴이 흔했습니다.
하지만 Virtual Threads는 **수백만 개**가 생성될 수 있습니다.

### 🚨 시나리오
* 요청 하나당 Virtual Thread 하나 생성.
* 각 스레드가 1MB짜리 버퍼를 `ThreadLocal`에 할당.
* 동시 접속자 10,000명 → **10GB 메모리 순식간에 점유** → **OOM(Out Of Memory) 발생**.

### ✅ 해결책
* Virtual Threads 환경에서는 `ThreadLocal` 사용을 지양해야 합니다.
* 꼭 필요하다면 Java 21에 새로 도입된 **Scoped Values (JEP 446)**를 사용하세요. 불변성을 보장하며 메모리를 효율적으로 공유합니다.

# 4. 언제 써야 할까? (Blocking vs CPU Bound)

Virtual Threads는 **I/O Bound 작업**(DB 조회, API 호출)에 특화되어 있습니다.
반면, **CPU Bound 작업**(동영상 인코딩, 암호화, 복잡한 계산)에서는 오히려 성능이 떨어집니다.

* **Good**: RestController, DB CRUD, 마이크로서비스 간 통신
* **Bad**: 배치 프로세싱, 이미지 처리, 머신러닝 연산

CPU 작업이 많다면 가상 스레드의 컨텍스트 스위칭 비용이 더 큽니다. 이런 작업은 기존의 Platform Thread 풀을 따로 운영하는 것이 낫습니다.

# 마치며

Spring Boot의 Virtual Threads 지원은 분명 혁신적입니다. WebFlux의 끔찍한 디버깅 난이도에서 우리를 구원해주었으니까요.
하지만 **"켜기만 하면 빨라진다"는 오해**입니다.

1. 사용 중인 라이브러리가 **Pinning**을 유발하지 않는지 확인하세요.
2. **ThreadLocal** 사용량을 점검하세요.
3. CPU 집중 작업은 별도로 분리하세요.

이 3가지만 지킨다면, 여러분의 서버는 적은 리소스로도 엄청난 트래픽을 감당할 수 있게 될 것입니다. 🚀

Java Virtual Threads: 무조건 도입하면 안 되는 이유와 실전 트러블슈팅

> 끝을 맺기를 처음과 같이 하면 실패가 없다. - 노자 

# 프로젝트 개요
- 이 프로젝트는 지인 1명의 아이디어로 출발을 시작했습니다. 언제 완성해서 언제 끝낼지는 모르지만 최대한 열심히 프로젝트를 진행 해 볼 예정입니다

# 참여인원
- 아이디어 제공자 - 1명
- 개발자 - 1명

이 프로젝트는 개발자인 저 포함 아이디어 제공자 총 2명으로 이뤄진 프로젝트입니다 
그래서 모든 인프라, 백엔드, 프론트엔드 등의 모든 개발은 제가 혼자 할 것이고 그 외의 것들은 아이디어 제공자와 같이 진행할 예정입니다


# 계기
처음 논의된 것은 게이미피케이션의 Todo-list에서 출발했습니다. 
아이디어 제공자의 얘기를 시작으로 
외국의 한 Todo-list 앱을 모티브삼아 얘기를 진행하다가 Growdo 프로젝트까지 오게됐습니다

# What is Growdo?
명칭은 Grow + todo-list를 합친것입니다 본인의 todo list를 진행하다보면 성장한다는 뜻으로 Growdo 라고 짓게됐습니다 
전체적인 기능은 todo-list와 포인트를 합친 모습이 될 것 같습니다 
예를들어 todo-list를 진행해서 포인트를 쌓으면 그 포인트로 여러 쿠폰으로 교환 할 수 있는 형태입니다.

# 마무리
이 프로젝트는 계속 논의중이며 현재 설계단계에 있습니다 그래서 갑자기 그만둘수도 있습니다 
그렇지만 끈기를 가지고 정식 출시까지 한번 달려보겠습니다 
프로젝트의 진행상황이나 진행중의 여러 문제점은 블로그를 통해 조금씩 올려볼 예정입니다

Growdo 프로젝트

> React 공식 문서조차 "새로운 React 프로젝트를 시작할 때 Next.js를 사용하라"고 권장하는 시대가 되었습니다. 단순한 SSR 도구로 시작해, 이제는 **웹 개발의 모든 것(The React Framework for the Web)**이 된 Next.js의 A to Z를 아주 깊고 상세하게 파헤쳐 봅니다.

![Next.js Architecture](https://assets.vercel.com/image/upload/v1588805858/front/nextjs/blog/next-9-4/og.png)

# 1. Next.js란 무엇인가?

Next.js는 **Vercel**이 만든 React 기반의 풀스택 웹 프레임워크입니다.

### 🚨 React만으로는 부족했던 것들
React는 "UI를 만드는 라이브러리"입니다. 그 말은 즉, UI 외적인 부분은 개발자가 알아서 채워야 한다는 뜻입니다.
- **라우팅**: `react-router-dom`을 직접 설치하고 설정해야 함.
- **번들링**: Webpack, Babel 설정을 직접 만지거나 CRA의 블랙박스에 의존해야 함.
- **SEO (검색 엔진 최적화)**: SPA(Single Page Application) 특성상 초기 HTML이 비어있어 구글/네이버 봇이 내용을 못 읽음.
- **초기 로딩 속도**: 자바스크립트를 다 다운받기 전까지 화면이 하얗게 뜸.

Next.js는 이 모든 문제를 **"설정 없이(Zero Configuration)"** 해결해 줍니다. 개발자는 오직 비즈니스 로직에만 집중하면 됩니다.

# 2. 렌더링 패턴의 진화 (The Rendering Spectrum)

Next.js가 강력한 이유는 상황에 맞춰 렌더링 방식을 자유자재로 선택할 수 있다는 점입니다.

### 1️⃣ CSR (Client-Side Rendering)
- 기존 React 방식.
- 브라우저가 JS를 실행해야 화면이 보임.
- **용도**: 관리자 페이지, SEO가 필요 없는 비공개 대시보드.

### 2️⃣ SSR (Server-Side Rendering) - `getServerSideProps`
- 요청이 올 때마다 서버에서 HTML을 그려서 내려줌.
- **장점**: 항상 최신 데이터, 완벽한 SEO.
- **단점**: 서버 부하 증가, 응답 속도 느림.
- **용도**: 실시간 주식 차트, 개인화된 피드.

### 3️⃣ SSG (Static Site Generation) - `getStaticProps`
- **Next.js의 필살기 1**. 빌드 타임에 미리 HTML을 다 만들어둠.
- **장점**: 압도적인 속도 (CDN에서 바로 서빙).
- **단점**: 빌드 이후 데이터 변경 반영 불가.
- **용도**: 블로그, 회사 소개 페이지, 마케팅 랜딩 페이지.

### 4️⃣ ISR (Incremental Static Regeneration)
- **Next.js의 필살기 2**. SSG의 빠름 + SSR의 최신성.
- 빌드된 정적 페이지를 특정 주기(예: 60초)마다 백그라운드에서 새로 고침.
- **용도**: 이커머스 상품 상세 페이지 (가격이 가끔 바뀜).

# 3. Game Changer: App Router와 RSC

Next.js 13.4부터 안정화된 **App Router**는 패러다임을 완전히 바꿨습니다.

### ⚛️ RSC (React Server Components)
기존에는 컴포넌트가 클라이언트(브라우저)에서 실행됐지만, 이제는 **서버에서 실행**됩니다.

```tsx
// app/page.tsx (Server Component)
async function Page() {
 // 1. DB 직접 접근 가능 (API 안 만들어도 됨!)
 const data = await db.query('SELECT * FROM posts');

 // 2. 무거운 라이브러리(예: Markdown 파서)를 써도
 // 브라우저로 전송되는 번들 사이즈는 0kb입니다.
 return <div>{data.map(...)}</div>;
}
```

* **Zero Bundle Size**: 서버 컴포넌트 코드는 브라우저로 전송되지 않습니다. 클라이언트가 다운로드해야 할 JS 양이 획기적으로 줄어듭니다.
* **백엔드 로직 통합**: 프론트엔드 코드 안에서 DB 쿼리를 직접 날리는 것이 자연스러워졌습니다.

# 4. Next.js만의 강력한 최적화 도구들

프레임워크답게, 웹 성능을 높이는 도구들이 기본 내장되어 있습니다.

### 🖼️ Image Component (`<Image />`)
- 이미지를 WebP/AVIF로 자동 변환.
- 디바이스 크기에 맞춰 리사이징.
- Lazy Loading 자동 적용.
- **CLS(Cumulative Layout Shift)** 방지 (이미지 로딩되면서 레이아웃 덜컹거리는 현상 해결).

### 🔤 Font Optimization (`next/font`)
- 구글 폰트를 빌드 타임에 다운로드하여 호스팅.
- 브라우저가 구글 서버로 요청을 보내지 않아 프라이버시 이슈 해결 및 속도 향상.

### 📜 Script Optimization (`next/script`)
- 서드파티 스크립트(구글 애널리틱스, 광고 등)가 메인 스레드를 막지 않도록 로딩 우선순위를 제어(`strategy="lazyOnload"` 등).

# 5. 현재와 미래: 웹의 표준이 되다

### 📈 Vercel 생태계
Next.js의 개발사 Vercel은 프레임워크와 배포 플랫폼을 완벽하게 통합했습니다. `git push` 한 번이면 전 세계 Edge Network에 사이트가 배포되고, Serverless Function이 자동으로 생성됩니다. 이는 개발자 경험(DX)을 극대화했습니다.

### 🔮 미래: 풀스택의 대중화
과거에는 프론트엔드와 백엔드가 엄격히 분리되었지만, Next.js의 **Server Actions**와 **RSC**는 그 경계를 허물고 있습니다. 프론트엔드 개발자가 DB를 다루고, 백엔드 로직을 작성하는 것이 자연스러운 워크플로우가 되었습니다.

# 마치며

Next.js는 단순한 도구를 넘어, **"웹을 어떻게 만들어야 하는가"**에 대한 모범 답안을 제시하고 있습니다.

더 빠른 웹, 더 검색 잘 되는 사이트, 더 편한 개발 환경을 원한다면 선택이 아닌 필수입니다. 지금 당장 `npx create-next-app@latest`로 미래를 경험해 보세요. 🚀

Next.js: React의 한계를 넘어 웹의 표준이 되기까지 (CSR부터 RSC까지)

> "ChatGPT API 비용이 부담스러워요."
> "우리 회사 기밀 문서를 외부에 보내기 찝찝해요."
> 이 두 가지 고민을 한 방에 해결하는 방법이 있습니다. 바로 **로컬 LLM**을 돌리는 것입니다. 이제는 노트북 한 대만 있으면 **Llama 3** 같은 고성능 AI를 내 컴퓨터에서 돌리고, **LangChain**을 엮어 내 데이터를 학습시킨 챗봇을 만들 수 있습니다.

# 1. 준비물 (Prerequisites)

* **Ollama**: 로컬에서 LLM을 실행해주는 엔진 (Docker처럼 편합니다).
* **LangChain**: LLM과 데이터를 연결해주는 프레임워크 (Python 사용).
* **ChromaDB**: 텍스트를 벡터로 변환해서 저장할 로컬 Vector DB.
* **Python 3.9+**: 코드를 실행할 환경.

# 2. 1단계: Ollama 설치 및 LLM 실행

가장 먼저 내 컴퓨터에 AI 뇌를 심어야 합니다. [Ollama 공식 홈페이지](https://ollama.com/)에서 다운로드 받으세요.

설치 후 터미널에서 다음 명령어를 입력합니다.

```bash
# Llama 3 모델 다운로드 및 실행
ollama run llama3

>>> 안녕, 넌 누구니?
# 한국어로 대답을 잘 해줄 겁니다!
```
이제 백그라운드에서 `http://localhost:11434` 포트로 API 서버가 돌고 있습니다.

# 3. 2단계: 프로젝트 설정 및 패키지 설치

Python 프로젝트를 만들고 필요한 라이브러리를 설치합니다.

```bash
pip install langchain langchain-community langchain-chroma pypdf
```

# 4. 3단계: RAG 파이프라인 코드 작성 (따라치세요!)

이제 **"PDF 문서를 읽어서 -> 쪼개고 -> 벡터화해서 저장하고 -> 질문하면 검색해서 답변하는"** 전체 코드를 작성해 봅니다. (`app.py`)

```python
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.chat_models import ChatOllama
from langchain.chains import RetrievalQA

# 1. 문서 로드 (내 이력서나 회사 문서를 넣으세요)
loader = PyPDFLoader("my_document.pdf")
docs = loader.load()

# 2. 문서 쪼개기 (Chunking)
# 문맥을 유지하기 위해 1000자씩 자르되, 앞뒤 200자는 겹치게 합니다.
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
splits = text_splitter.split_documents(docs)

# 3. 임베딩 & 벡터 DB 저장
# Ollama가 제공하는 임베딩 모델(nomic-embed-text 등)을 사용합니다.
embedding = OllamaEmbeddings(model="llama3") 
vectorstore = Chroma.from_documents(documents=splits, embedding=embedding)

# 4. LLM 로드 (로컬 Ollama 연결)
llm = ChatOllama(model="llama3")

# 5. 질의응답 체인 생성 (RetrievalQA)
qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=vectorstore.as_retriever()
)

# 6. 질문하기
question = "이 문서의 핵심 내용이 뭐야?"
response = qa_chain.invoke(question)

print(f"Q: {question}")
print(f"A: {response['result']}")
```

> **Tip**: 임베딩 속도를 높이려면 `ollama pull nomic-embed-text`를 받아두고 `model="nomic-embed-text"`를 쓰는 게 훨씬 빠르고 정확합니다.

# 5. 4단계: 실행 및 결과 확인

```bash
python app.py
```

잠시 기다리면(컴퓨터 사양에 따라 다름), AI가 문서를 다 읽고 요약된 답변을 내놓습니다.
와우! 인터넷 연결 없이, 오직 내 컴퓨터 안에서 나만의 데이터를 학습한 AI가 탄생했습니다.

# 6. 심화: Streamlit으로 웹 UI 붙이기

터미널이 밋밋하다면 **Streamlit**을 붙여서 그럴듯한 챗봇 화면을 만들 수 있습니다.

```python
import streamlit as st

st.title("📄 나만의 문서 챗봇")
user_input = st.text_input("질문을 입력하세요:")

if user_input:
 with st.spinner("AI가 생각 중입니다..."):
 response = qa_chain.invoke(user_input)
 st.write(response['result'])
```
`streamlit run app.py`로 실행하면 웹 브라우저에서 챗봇을 만날 수 있습니다.

# 마치며

이제 여러분은 **API 비용 걱정 없이**, **보안 걱정 없이** 마음껏 AI를 실험해볼 수 있는 환경을 갖췄습니다.
이 코드를 기반으로 사내 위키 검색 봇, 개인 일기장 분석기, 법률 문서 검토기 등 무궁무진한 아이디어를 실현해 보세요. 🚀

[실전] LangChain + Ollama: 0원으로 만드는 '나만의 로컬 RAG 챗봇' 구축 가이드

> 지난 포스팅에서는 VectorDB의 종류와 선택 기준을 다뤘습니다. 이제 도구는 준비되었으니, 실제로 **RAG(Retrieval-Augmented Generation)** 시스템을 구축해볼 차례입니다. 하지만 막상 구현해보면 생각보다 정확도가 나오지 않아 당황하게 됩니다. 오늘은 실전에서 자주 겪는 문제점들과 그 품질을 높이는 핵심 팁들을 공유합니다.

![AI Technology](https://images.unsplash.com/photo-1677442136019-21780ecad995?q=80&w=1932&auto=format&fit=crop)
*이미지 출처: Unsplash*

# 1. 문서 청킹(Chunking)의 딜레마

RAG의 첫 단계는 긴 문서를 작은 조각(Chunk)으로 자르는 것입니다. 하지만 이 "자르는 기준"이 매우 까다롭습니다.

- **문제점**: 너무 작게 자르면 문맥(Context)이 잘려서 의미를 잃고, 너무 크게 자르면 불필요한 노이즈 정보까지 포함되어 검색 정확도가 떨어집니다.
- **해결책**:
 - **의미 기반 청킹(Semantic Chunking)**: 단순히 글자 수로 자르지 말고, 문단이나 섹션 단위로 의미가 이어지도록 자릅니다.
 - **Overlap(중첩)**: 자를 때 앞뒤 문장을 10~20% 정도 겹치게 하여 문맥이 끊기는 것을 방지합니다.

# 2. 키워드 검색의 부재 (Hybrid Search)

VectorDB는 "의미"를 잘 찾지만, "정확한 단어"를 찾는 데는 약할 수 있습니다.

- **문제점**: 사용자가 "제품 모델명(ABC-123)"이나 "특정 에러 코드"를 검색했는데, VectorDB는 의미가 비슷한 엉뚱한 문서를 가져올 수 있습니다.
- **해결책**:
 - **하이브리드 검색(Hybrid Search)**: 전통적인 키워드 검색(BM25)과 벡터 검색(Dense Retrieval)을 섞어 사용합니다.
 - **Reciprocal Rank Fusion (RRF)**: 두 검색 결과의 순위를 적절히 섞어 최종 순위를 재조정합니다.

# 3. 검색 결과의 순위 문제 (Reranking)

벡터 검색으로 상위 10개를 가져왔다고 해서, 그 1번이 무조건 정답은 아닙니다.

- **문제점**: 임베딩 모델은 범용적이기 때문에, 우리 도메인의 특수한 뉘앙스를 완벽히 구분하지 못할 수 있습니다.
- **해결책**:
 - **리랭커(Reranker) 도입**: 초벌 검색으로 50~100개를 빠르게 가져온 뒤, 더 정교한(하지만 느린) Cross-Encoder 모델을 사용해 순위를 다시 매깁니다.
 - 이 과정을 거치면 LLM에게 전달되는 문서(Context)의 품질이 비약적으로 상승합니다.

# 마치며: 은탄환은 없다

RAG는 단순히 DB만 붙인다고 완성되는 것이 아닙니다. 데이터의 전처리부터 검색 전략, 그리고 프롬프트 엔지니어링까지 꼼꼼하게 튜닝해야 원하는 성능을 얻을 수 있습니다.

이 시리즈를 통해 VectorDB의 개념부터 도구 선택, 그리고 실전 팁까지 알아보았습니다. 여러분의 AI 서비스 구축에 도움이 되었기를 바랍니다! 🚀

RAG(검색 증강 생성) 시스템 구축 시 마주하는 3가지 난관과 해결책

# 들어가며

지난 포스팅에서 우리는 VectorDB가 무엇이고 왜 AI 시대에 필수적인지 알아보았습니다. 개념을 이해했다면 이제 **"그래서 도대체 무엇을 써야 하는데?"** 라는 질문에 부딪히게 됩니다.

시중에는 수많은 VectorDB가 존재하며, 각각의 장단점이 뚜렷합니다. 이번 글에서는 대표적인 VectorDB들을 유형별로 살펴보고, 여러분의 프로젝트에 딱 맞는 도구를 선택하는 기준을 제시해 드립니다.

---

# 전용 VectorDB (Specialized)

벡터 검색만을 위해 처음부터 설계된 데이터베이스들입니다. 성능과 특화 기능이 뛰어납니다.

## 1. Pinecone
- **특징**: 완전 관리형(SaaS) 서비스입니다. 인프라 관리가 전혀 필요 없습니다.
- **장점**: 구축이 매우 쉽고 빠릅니다. 스케일링이 자동화되어 있어 운영 부담이 적습니다.
- **단점**: 오픈소스가 아니며, 데이터 양이 많아지면 비용이 비싸질 수 있습니다. 데이터를 외부에 저장해야 한다는 보안 우려가 있을 수 있습니다.
- **추천**: 빠르게 프로토타입을 만들어야 하거나, 인프라 운영 인력이 부족한 스타트업.

## 2. Milvus
- **특징**: 대규모 데이터를 처리하기 위해 설계된 고성능 오픈소스 VectorDB입니다.
- **장점**: 수십억 개의 벡터를 처리할 수 있는 확장성(Scalability)을 자랑합니다. 기능이 매우 풍부합니다.
- **단점**: 쿠버네티스(k8s) 기반으로 운영하는 것이 권장될 정도로 배포와 관리가 복잡할 수 있습니다.
- **추천**: 대규모 트래픽과 데이터를 다루는 엔터프라이즈 환경.

## 3. Chroma
- **특징**: 개발자 경험(DX)을 최우선으로 하는 오픈소스 DB입니다.
- **장점**: `pip install chromadb` 하나면 설치 끝. 로컬 파일 기반으로 가볍게 시작할 수 있고 사용이 매우 직관적입니다.
- **단점**: 대규모 분산 처리는 Pinecone이나 Milvus에 비해 아직 성숙도가 낮을 수 있습니다.
- **추천**: 개인 프로젝트, 사이드 프로젝트, 로컬 테스트 환경.

---

# 통합형 VectorDB (Integrated)

기존에 쓰던 데이터베이스에 벡터 검색 기능을 추가한 형태입니다. 새로운 인프라를 도입하지 않아도 된다는 강력한 장점이 있습니다.

## 1. pgvector (PostgreSQL)
- **특징**: 전 세계에서 가장 사랑받는 RDBMS인 PostgreSQL의 확장 플러그인입니다.
- **장점**: 기존의 관계형 데이터와 벡터 데이터를 **하나의 쿼리(SQL)**로 조인해서 가져올 수 있습니다. 트랜잭션, 백업 등 RDBMS의 안정성을 그대로 누립니다.
- **단점**: 전용 DB에 비해 벡터 검색 성능(인덱싱 속도 등)이 약간 떨어질 수 있습니다.
- **추천**: 이미 PostgreSQL을 쓰고 있고, 메타데이터 필터링이 복잡하게 필요한 서비스.

## 2. Elasticsearch / OpenSearch
- **특징**: 검색 엔진의 제왕들답게 강력한 벡터 검색 기능을 탑재했습니다.
- **장점**: 기존의 키워드 검색(BM25)과 벡터 검색(Dense Retrieval)을 결합한 **하이브리드 검색(Hybrid Search)** 구현에 최적화되어 있습니다.
- **단점**: 리소스를 많이 잡아먹고(Memory Heavy), 운영 난이도가 꽤 높습니다.
- **추천**: 기존에 검색 엔진을 이미 운영 중이거나, 키워드 검색과 벡터 검색을 정교하게 섞어야 하는 경우.

---

# 선택 가이드: 요약

결국 정답은 없습니다. 상황에 맞춰 골라보세요.

1. **"나는 인프라 관리 귀찮고, 돈으로 시간을 사겠다."** 👉 **Pinecone**
2. **"나는 PostgreSQL 덕후고, 기존 데이터랑 같이 조회해야 한다."** 👉 **pgvector**
3. **"토이 프로젝트 중인데, 지금 당장 내 노트북에서 돌리고 싶다."** 👉 **Chroma**
4. **"수천만 건 이상의 데이터를 다루는 대형 서비스를 만든다."** 👉 **Milvus**

---

# 마치며

도구를 선택했다면, 이제 데이터를 어떻게 벡터로 변환(Embedding)하고 어떻게 검색 품질을 높일지 고민할 차례입니다.
다음 포스팅에서는 **"RAG(검색 증강 생성) 시스템을 실제로 구현할 때 겪게 되는 문제점과 해결 팁"**에 대해 다뤄보겠습니다.

어떤 VectorDB를 써야 할까? (Pinecone, Milvus, Chroma, pgvector 비교)

> 최근 ChatGPT와 같은 생성형 AI(Generative AI)가 급부상하면서, 함께 주목받고 있는 기술이 있습니다. 바로 VectorDB(벡터 데이터베이스)입니다. 
기존의 관계형 데이터베이스(RDBMS)가 있는데 왜 새로운 형태의 데이터베이스가 필요해진 걸까요? 
오늘은 개발자 관점에서 VectorDB의 핵심 개념과 특징, 그리고 왜 지금 이 기술이 중요한지에 대해 정리해 보겠습니다.

# VectorDB란?

1. **VectorDB**는 텍스트, 이미지, 오디오와 같은 비정형 데이터를 **벡터(Vector)** 형태, 즉 고차원의 숫자 배열로 변환하여 저장하고 검색하는 데 특화된 데이터베이스입니다.

2. 전통적인 데이터베이스가 `WHERE title = '검색어'`와 같이 키워드 일치(Exact Match)를 찾는다면, VectorDB는 데이터의 의미적 유사성(Semantic Similarity)을 기반으로 검색을 수행합니다.
 

# 핵심 원리: 벡터 임베딩 (Vector Embedding)

컴퓨터는 "사과"라는 단어의 맛이나 모양을 이해하지 못합니다. 대신 AI 모델을 통해 이 데이터를 다차원 공간의 좌표(숫자 리스트)로 변환하는데, 이것을 임베딩(Embedding)이라고 합니다.

* **의미 공간(Semantic Space):** 의미가 비슷한 데이터들은 벡터 공간상에서 서로 가까운 거리에 위치하게 됩니다.
* **예시:**
 * '왕(King)' - '남자(Man)' + '여자(Woman)' = '여왕(Queen)'
 * '강아지'는 '고양이'와 가깝게, '자동차'와는 멀리 위치합니다.

> ![maxresdefault](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b1f67aaf-ccd0-457b-85a2-4688859f7f8d_maxresdefault.jpg)

 

# 기존 DB(RDBMS) vs VectorDB

가장 큰 차이점은 데이터를 바라보는 관점과 검색 방식에 있습니다.

| 특징 | 관계형 데이터베이스 (RDBMS) | 벡터 데이터베이스 (VectorDB) |
| :--- | :--- | :--- |
| **저장 단위** | 행(Row)과 열(Column) | 고차원 벡터 (Embeddings) |
| **검색 방식** | 키워드 매칭, 정확한 값 비교 | 유사도 검색 (Similarity Search) |
| **쿼리 예시** | `SELECT * FROM items WHERE name LIKE '%아이폰%'` | "최신 스마트폰 추천해줘" (의미 기반 검색) |
| **결과** | '아이폰' 단어가 포함된 결과만 반환 | 갤럭시, 픽셀 등 문맥상 유사한 결과 포함 |

 

# 왜 지금 VectorDB인가? (feat. RAG)

VectorDB가 필수 인프라로 떠오른 가장 큰 이유는 **LLM(거대언어모델)의 한계**를 보완해주기 때문입니다.

* **RAG (검색 증강 생성):** LLM은 학습하지 않은 최신 정보나 기업 내부의 사내 데이터는 알지 못합니다. 또한 사실이 아닌 정보를 진실인 것처럼 말하는 '환각(Hallucination)' 현상이 발생하기도 합니다.
* **해결책:** VectorDB에 우리만의 지식 데이터를 벡터화하여 저장해 둡니다. 사용자가 질문을 하면 VectorDB에서 가장 유사한 근거 자료를 찾아와 LLM에게 전달하고, LLM은 그 정보를 바탕으로 정확한 답변을 생성합니다.


 

# 마치며

VectorDB는 단순한 저장소를 넘어, AI가 데이터의 맥락(Context)을 이해하도록 돕는 핵심 기술입니다.

다음 포스팅에서는 VectorDB의 종류와 구체적인 내용들을 좀 더 심도있게 다뤄보겠습니다.

AI 시대의 필수 데이터베이스, VectorDB(벡터 DB)란 무엇인가?

> 자료구조(Data Structure)는 데이터를 **어떤 형태로 저장하고, 어떤 방식으로 접근할 것인가**를 다루는 컴퓨터 과학의 핵심 개념입니다. 
프로그램의 성능, 확장성, 유지보수성은 대부분 자료구조 선택에서 큰 영향을 받고있습니다. 
각 자료구조의 특징, 단점, 시간복잡도 등을 최대한 단순하게 적어서 읽는데 많은 시간을 안들이게 구성 했습니다. 
저도 적으면서 가물가물했던 내용들을 다시한번 기억하니 많은 도움이 되었습니다.

# 선형 자료구조

## 1. 배열 (Array)
- **특징**: 고정 크기, 연속된 메모리, O(1) 인덱스 접근
- **단점**: 크기 변경 불가, 삽입/삭제 비효율적
```java
int[] arr = new int[5];
arr[0] = 10; // O(1)
```

## 2. 동적 배열 (ArrayList)
- **특징**: 가변 크기, 내부적으로 배열 복사로 확장
- **시간복잡도**: 조회 O(1), 끝 추가 O(1) amortized, 중간 삽입/삭제 O(n)
```java
ArrayList list = new ArrayList<>();
list.add(10); // O(1) amortized
list.get(0); // O(1)
list.add(0, 5); // O(n) - 요소 이동 필요
list.remove(0); // O(n)
```

## 3. 연결 리스트 (LinkedList)
- **특징**: 노드 기반, 동적 크기, 포인터로 연결
- **시간복잡도**: 조회 O(n), 앞/뒤 삽입/삭제 O(1), 중간 삽입/삭제 O(n)
```java
class Node {
 int data;
 Node next;
 
 Node(int data) {
 this.data = data;
 this.next = null;
 }
}

class LinkedList {
 Node head;
 
 void addFirst(int data) { // O(1)
 Node newNode = new Node(data);
 newNode.next = head;
 head = newNode;
 }
 
 void delete(int data) { // O(n)
 if (head == null) return;
 
 if (head.data == data) {
 head = head.next;
 return;
 }
 
 Node current = head;
 while (current.next != null) {
 if (current.next.data == data) {
 current.next = current.next.next;
 return;
 }
 current = current.next;
 }
 }
}
```

## 4. 스택 (Stack)
- **특징**: LIFO (Last In First Out)
- **용도**: 함수 호출, DFS, 괄호 검증, 되돌리기
```java
Stack stack = new Stack<>();
stack.push(10); // O(1)
stack.push(20);
int top = stack.pop(); // 20, O(1)
int peek = stack.peek(); // 10, O(1)
```

## 5. 큐 (Queue)
- **특징**: FIFO (First In First Out)
- **용도**: BFS, 작업 스케줄링, 버퍼
```java
Queue queue = new LinkedList<>();
queue.offer(10); // O(1)
queue.offer(20);
int front = queue.poll(); // 10, O(1)
int peek = queue.peek(); // 20, O(1)
```

### 6. 덱 (Deque)
- **특징**: 양쪽 끝에서 삽입/삭제 가능
- **용도**: 슬라이딩 윈도우, 양방향 큐
```java
Deque deque = new ArrayDeque<>();
deque.addFirst(10); // O(1)
deque.addLast(20); // O(1)
deque.pollFirst(); // O(1)
deque.pollLast(); // O(1)
```

# 비선형 자료구조

## 1. 해시 테이블 (HashMap)
- **특징**: 키-값 쌍, 해시 함수 사용
- **시간복잡도**: 평균 O(1), 최악 O(n) - 해시 충돌 시
- **용도**: 빠른 검색, 중복 제거, 캐싱
```java
HashMap map = new HashMap<>();
map.put("apple", 100); // O(1) 평균
map.get("apple"); // O(1) 평균
map.containsKey("apple"); // O(1) 평균
map.remove("apple"); // O(1) 평균

// 충돌 처리: Chaining(LinkedList) 또는 Open Addressing
```

## 2. 해시 셋 (HashSet)
- **특징**: 중복 없는 집합, HashMap 기반
- **시간복잡도**: 추가/검색/삭제 O(1) 평균
```java
HashSet set = new HashSet<>();
set.add(10); // O(1)
set.contains(10); // O(1)
set.remove(10); // O(1)
```

## 3. 트리 (Tree)

### 3.1. 이진 트리
```java
class TreeNode {
 int val;
 TreeNode left;
 TreeNode right;
 
 TreeNode(int val) {
 this.val = val;
 }
}
```

### 3.2. 이진 탐색 트리 (BST)
- **특징**: 왼쪽 < 부모 < 오른쪽
- **시간복잡도**: 평균 O(log n), 최악 O(n) - 편향 트리
```java
class BST {
 TreeNode root;
 
 TreeNode insert(TreeNode node, int val) { // O(log n) 평균
 if (node == null) return new TreeNode(val);
 
 if (val < node.val)
 node.left = insert(node.left, val);
 else if (val > node.val)
 node.right = insert(node.right, val);
 
 return node;
 }
 
 boolean search(TreeNode node, int val) { // O(log n) 평균
 if (node == null) return false;
 if (node.val == val) return true;
 
 return val < node.val 
 ? search(node.left, val) 
 : search(node.right, val);
 }
}
```

### 3.3. TreeMap/TreeSet (Red-Black Tree)
- **특징**: 자가 균형 이진 탐색 트리
- **시간복잡도**: 모든 연산 O(log n) 보장
- **용도**: 정렬된 상태 유지 필요 시
```java
TreeMap treeMap = new TreeMap<>();
treeMap.put(3, "three"); // O(log n)
treeMap.put(1, "one");
treeMap.put(2, "two");
// 자동 정렬: {1=one, 2=two, 3=three}

TreeSet treeSet = new TreeSet<>();
treeSet.add(5); // O(log n)
treeSet.first(); // 최소값 O(log n)
treeSet.last(); // 최대값 O(log n)
```

## 4. 힙 (Heap)
- **특징**: 완전 이진 트리, 최대/최소값 빠른 접근
- **시간복잡도**: 삽입/삭제 O(log n), 최대/최소 조회 O(1)
- **용도**: 우선순위 큐, 힙 정렬, Top K 문제
```java
// 최소 힙
PriorityQueue minHeap = new PriorityQueue<>();
minHeap.offer(5); // O(log n)
minHeap.offer(3);
minHeap.offer(7);
minHeap.poll(); // 3, O(log n)

// 최대 힙
PriorityQueue maxHeap = new PriorityQueue<>(Collections.reverseOrder());
maxHeap.offer(5);
maxHeap.offer(3);
maxHeap.poll(); // 5
```

## 5. 그래프 (Graph)

### 5.1. 인접 리스트
```java
// 효율적: 간선이 적을 때 (희소 그래프)
HashMap> graph = new HashMap<>();

void addEdge(int u, int v) {
 graph.putIfAbsent(u, new ArrayList<>());
 graph.get(u).add(v);
 // 무방향 그래프면 양쪽 추가
 graph.putIfAbsent(v, new ArrayList<>());
 graph.get(v).add(u);
}
```

### 5.2. 인접 행렬
```java
// 간선이 많을 때 (밀집 그래프), O(1) 간선 존재 확인
int[][] graph = new int[n][n];
graph[u][v] = 1; // 간선 존재
```

# 시간복잡도 비교

| 자료구조 | 접근 | 검색 | 삽입 | 삭제 |
|---------|------|------|------|------|
| 배열 | O(1) | O(n) | O(n) | O(n) |
| LinkedList | O(n) | O(n) | O(1)* | O(1)* |
| Stack | O(n) | O(n) | O(1) | O(1) |
| Queue | O(n) | O(n) | O(1) | O(1) |
| HashMap | - | O(1) | O(1) | O(1) |
| TreeMap | - | O(log n) | O(log n) | O(log n) |
| Heap | O(n) | O(n) | O(log n) | O(log n) |
| BST | O(log n) | O(log n) | O(log n) | O(log n) |

*위치를 알고 있을 때

# 선택 기준

- **빠른 인덱스 접근**: 배열, ArrayList
- **빈번한 삽입/삭제**: LinkedList
- **LIFO**: Stack
- **FIFO**: Queue
- **빠른 검색**: HashMap, HashSet
- **정렬 + 검색**: TreeMap, TreeSet
- **최대/최소 우선**: PriorityQueue (Heap)
- **관계 표현**: 그래프

# 마무리
실전에선 대부분 ArrayList, HashMap, PriorityQueue로 해결이 가능한 것들이 많습니다. 
혹시 작성한 내용중에 오타나 내용에 이상이 있으면 댓글로 말씀해주시면 감사하겠습니다 .

개발자가 반드시 알아야 할 자료구조 기본 정리

> "React 배우기 어렵나요?" 라고 물으면 항상 나오는 대답이 있습니다. "Hooks의 의존성 배열(Dependency Array) 관리만 익숙해지면 할 만해요." 하지만 이제 이 말도 옛말이 되었습니다. **React 19**와 **React Compiler**의 등장으로, 우리는 더 이상 렌더링 최적화에 골머리를 앓을 필요가 없어졌기 때문입니다. 이번 포스팅에서는 React 생태계를 송두리째 바꾼 이 두 가지 거대한 변화에 대해 아주 상세하게 알아봅니다.

![React Compiler](https://images.unsplash.com/photo-1618477247222-ac591245363d?q=80&w=2070&auto=format&fit=crop)

# 1. The Pain Points: 우리가 겪던 고통

React 개발자라면 누구나 한 번쯤 `useEffect`나 `useMemo`의 의존성 배열(`[]`) 때문에 버그를 만들어본 적이 있을 겁니다.

```javascript
// ❌ 실수하기 딱 좋은 코드
const filteredTodos = useMemo(() => {
 return todos.filter(t => t.status === filter);
}, [todos]); // 실수로 filter를 빼먹음! -> 필터가 안 바뀜
```

이런 실수를 잡기 위해 `eslint-plugin-react-hooks`를 썼지만, 때로는 불필요한 리렌더링을 막기 위해 코드 전체를 `useCallback`으로 감싸야 하는 **"Memoization Hell"**에 빠지기도 했습니다.

# 2. React Compiler: 자동 메모이제이션의 시대

**React Compiler (구 React Forget)**는 이 모든 고통을 없애줍니다. 이 컴파일러는 빌드 타임에 코드를 분석하여, **값이 변경되었을 때만 컴포넌트나 UI 조각이 다시 렌더링되도록 자동으로 코드를 변환**합니다.

### 🛠 어떻게 동작하나요?

개발자가 `useMemo`를 쓰지 않아도, 컴파일러가 알아서 판단합니다.

**[Before: 개발자가 짠 코드]**
```javascript
function TodoList({ todos, filter }) {
 const filtered = todos.filter(t => t.status === filter);
 return <List items={filtered} />;
}
```

**[After: 컴파일러가 변환한 코드 (개념적)]**
```javascript
function TodoList({ todos, filter }) {
 const $ = useMemoCache(2);
 let filtered;
 // todos나 filter가 바뀌었을 때만 계산 수행
 if ($[0] !== todos || $[1] !== filter) {
 filtered = todos.filter(t => t.status === filter);
 $[0] = todos;
 $[1] = filter;
 $[2] = filtered;
 } else {
 filtered = $[2];
 }
 return <List items={filtered} />;
}
```

이제 개발자는 **"무엇(What)"**을 렌더링할지만 고민하면 됩니다. **"어떻게(How)"** 효율적으로 렌더링할지는 컴파일러의 몫입니다.

# 3. React 19의 핵심: Actions & New Hooks

컴파일러가 최적화를 담당한다면, React 19는 **데이터 흐름(Data Flow)**을 혁신했습니다. 핵심 키워드는 **"Actions"**입니다.

### ✅ Actions (`<form action={fn}>`)

더 이상 `onSubmit`, `e.preventDefault()`, 수동 `fetch`, `isLoading` 상태 관리를 할 필요가 없습니다.

```javascript
// 서버 액션 함수
async function updateProfile(formData) {
 'use server';
 await db.user.update(...);
}

// 컴포넌트
function Profile() {
 return (
 <form action={updateProfile}>
 <input name="name" />
 <button type="submit">저장</button>
 </form>
 );
}
```
HTML의 기본 폼 동작을 확장하여, React가 비동기 요청의 생명주기를 자동으로 관리해줍니다.

### ✅ useOptimistic: 낙관적 업데이트가 공짜

"좋아요" 버튼을 눌렀을 때, 서버 응답을 기다리지 않고 즉시 하트가 빨개지게 만드는 것(Optimistic UI)은 꽤 복잡한 구현이 필요했습니다. React 19에서는 훅 하나로 끝납니다.

```javascript
const [optimisticLikes, addOptimisticLike] = useOptimistic(
 likes,
 (state, newLike) => state + 1
);
```

### ✅ useFormStatus: Props Drilling 안녕

폼 내부 깊숙한 곳에 있는 제출 버튼이 "로딩 중" 상태를 알아야 할 때, 예전에는 props로 `isLoading`을 내려줬어야 했습니다. 이제는 훅으로 상태를 구독합니다.

```javascript
function SubmitButton() {
 const { pending } = useFormStatus(); // 부모 폼의 상태를 바로 읽음
 return <button disabled={pending}>{pending ? '저장 중...' : '저장'}</button>;
}
```

# 4. use API: 렌더링 중에 Promise 읽기

`useEffect` 안에서 데이터를 가져오는 패턴도 사라지고 있습니다. 새로운 `use` API는 렌더링 함수 내부에서 Promise(비동기 데이터)나 Context를 바로 읽을 수 있게 해줍니다.

```javascript
function Comments({ commentsPromise }) {
 // Promise가 해결될 때까지 React가 자동으로 Suspense를 보여줌
 const comments = use(commentsPromise);
 return comments.map(c => {c.text});
}
```

# 마치며: DX(개발자 경험)의 승리

React 19와 Compiler의 등장은 단순한 기능 추가가 아닙니다. **"React를 작성하는 멘탈 모델"** 자체가 바뀌었습니다.

1. **메모이제이션 걱정 끝**: 비즈니스 로직에만 집중하세요.
2. **보일러플레이트 감소**: `useEffect`, `useState` 범벅이던 데이터 페칭 코드가 `Action`과 `use`로 깔끔해졌습니다.
3. **서버-클라이언트 융합**: RSC와 Server Actions로 경계가 허물어졌습니다.

이제 React는 단순한 UI 라이브러리가 아니라, **풀스택 애플리케이션을 위한 운영체제**에 가까워지고 있습니다. 2026년, React를 다시 배워야 할 이유입니다. ⚛️

React 19 & Compiler: 수동 최적화의 종말과 DX의 혁명

![](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/d9d6ce2b-f24a-4501-8192-42864d5d1943_how_to_manually_create_an_openstack_image.png)

>이전 포스팅에서는 오픈스택 구축에 관한 경험을 정리 했었는데 이번 포스팅부터는 구축 후 발생했던 겪었던 이슈에 대한 이슈를 정리 해본다

# 🚨 설치 단계 문제

## 1. OS 설치 관련

### 그래픽 모드 문제
**증상**: Rocky Linux 설치 시 그래픽 화면이 뜨지 않음

**원인**: 
- Nvidia 그래픽 카드 드라이버 이슈
- 하드웨어 호환성 문제

**해결방법**:
```bash
# 방법 1: 부팅 옵션 추가
# GRUB 화면에서 'e' 키를 누르고 다음 추가:
splash nomodeset

# 방법 2: Text mode 설치 후 그래픽 드라이버 설치
sudo dnf install nvidia-driver
```

### 설치 중 네트워크 문제
**증상**: 패키지 다운로드 실패

**해결방법**:
```bash
# DNS 설정 확인
cat /etc/resolv.conf

# 임시 DNS 설정
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
```

---

# 🔧 의존성 및 버전 문제

## 1. Python/Pip 버전 불일치

**증상**: 
- Ansible 설치 실패
- "requirement already satisfied" 오류

**해결방법**:
```bash
# Python 및 pip 업그레이드
sudo dnf update python3 python3-pip

# 가상환경 사용 (권장)
python3 -m venv openstack-env
source openstack-env/bin/activate

# pip 업그레이드
pip install --upgrade pip

# 캐시 클리어
pip cache purge
```

## 2. Ansible 버전 호환성

**증상**: 
- Ansible 실행 시 모듈 오류
- "module not found" 에러

**해결방법**:
```bash
# 특정 버전 설치
pip install ansible==6.0.0

# 의존성 재설치
pip install --force-reinstall ansible

# Galaxy 컬렉션 설치
ansible-galaxy collection install ansible.posix
```

---

# 🐳 Docker 관련 문제

## 1. Docker 권한 문제

**증상**: 
- "permission denied" 오류
- Docker 명령어 실행 불가

**해결방법**:
```bash
# 사용자를 docker 그룹에 추가
sudo usermod -aG docker $USER

# 그룹 권한 즉시 적용
newgrp docker

# Docker 소켓 권한 확인
sudo chmod 666 /var/run/docker.sock
```

## 2. Docker 서비스 시작 실패

**증상**: Docker 데몬이 시작되지 않음

**해결방법**:
```bash
# 서비스 상태 확인
sudo systemctl status docker

# 로그 확인
sudo journalctl -u docker.service

# 서비스 재시작
sudo systemctl restart docker

# 자동 시작 설정
sudo systemctl enable docker
```

---

# ⚙️ Kolla-Ansible 배포 문제

## 1. 메모리 부족

**증상**: 
- 컨테이너 생성 실패
- OOM (Out of Memory) 오류

**해결방법**:
```bash
# 스왑 파일 생성
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 영구 설정
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 메모리 사용량 확인
free -h
```

## 2. 네트워크 인터페이스 문제

**증상**: 
- "Network interface not found" 오류
- 외부 연결 불가

**해결방법**:
```bash
# 네트워크 인터페이스 확인
ip addr show

# globals.yml 수정
sudo vim /etc/kolla/globals.yml

# 올바른 인터페이스 설정
network_interface: "enp0s3" # 실제 인터페이스명
neutron_external_interface: "enp0s8"
```

## 3. 포트 충돌

**증상**: 
- "Port already in use" 오류
- 서비스 바인딩 실패

**해결방법**:
```bash
# 포트 사용 현황 확인
sudo netstat -tulpn | grep :80
sudo netstat -tulpn | grep :443

# 기존 서비스 중지
sudo systemctl stop httpd
sudo systemctl stop nginx

# 포트 확인 후 재배포
kolla-ansible -i all-in-one prechecks
```

---

# 🌐 OpenStack 서비스 문제

## 1. Keystone 인증 실패

**증상**: 
- "Authentication failure" 오류
- 대시보드 로그인 불가

**해결방법**:
```bash
# 패스워드 확인
grep keystone_admin_password /etc/kolla/passwords.yml

# 환경 변수 재설정
source /etc/kolla/admin-openrc.sh

# Keystone 컨테이너 재시작
sudo docker restart keystone
```

## 2. Nova 컴퓨트 서비스 문제

**증상**: 
- 인스턴스 생성 실패
- "No valid host found" 오류

**해결방법**:
```bash
# 컴퓨트 서비스 상태 확인
openstack compute service list

# Nova 컨테이너 로그 확인
sudo docker logs nova_compute

# 리소스 사용량 확인
openstack usage show
```

## 3. Neutron 네트워크 문제

**증상**: 
- 네트워크 생성 실패
- 인스턴스 네트워크 연결 안됨

**해결방법**:
```bash
# 네트워크 에이전트 상태 확인
openstack network agent list

# OVS 브리지 확인
sudo ovs-vsctl show

# Neutron 서비스 재시작
sudo docker restart neutron_server
sudo docker restart neutron_openvswitch_agent
```

---

# 💾 스토리지 문제

## 1. Cinder 볼륨 생성 실패

**증상**: 
- 볼륨 생성 시 오류
- "No space left" 메시지

**해결방법**:
```bash
# 디스크 사용량 확인
df -h

# Cinder 설정 확인
sudo docker exec cinder_volume cat /etc/cinder/cinder.conf

# LVM 설정 확인 (LVM 백엔드 사용 시)
sudo vgs
sudo lvs
```

## 2. 스토리지 백엔드 문제

**증상**: 
- 백엔드 초기화 실패
- 스토리지 서비스 다운

**해결방법**:
```bash
# 스토리지 서비스 상태 확인
openstack volume service list

# 로그 확인
sudo docker logs cinder_volume
sudo docker logs cinder_scheduler
```

---

# 🔍 진단 및 모니터링

## 1. 시스템 리소스 모니터링

```bash
# CPU 사용률
top
htop

# 메모리 사용률
free -h
cat /proc/meminfo

# 디스크 I/O
iostat -x 1

# 네트워크 트래픽
iftop
nethogs
```

## 2. 컨테이너 상태 확인

```bash
# 모든 컨테이너 상태
sudo docker ps -a

# 특정 컨테이너 로그
sudo docker logs <container_name>

# 컨테이너 리소스 사용량
sudo docker stats

# 컨테이너 내부 접근
sudo docker exec -it <container_name> bash
```

## 3. OpenStack 서비스 상태

```bash
# 모든 서비스 상태
openstack endpoint list
openstack service list

# 컴퓨트 서비스
openstack compute service list
openstack hypervisor list

# 네트워크 서비스
openstack network agent list

# 볼륨 서비스
openstack volume service list
```

오픈스택 구축 및 운영시 발생할 수 있는 이슈 정리

![how_to_manually_create_an_openstack_image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/d9d6ce2b-f24a-4501-8192-42864d5d1943_how_to_manually_create_an_openstack_image.png)

> 회사에서 진행한 프로젝트를 통해 OpenStack을 직접 구축하며 학습했던 과정을 정리해보려 합니다. 
당시엔 시행착오도 많고 정말 힘들었지만, 프로젝트 중에 남겨둔 문서와 제 기억을 바탕으로 가능한 한 자세하게 기술해보고자 합니다. 
다양한 시도 과정, 맨땅에 헤딩하듯 해왔던 삽질까지 모두 기록하려 합니다. 
훗날 저와 비슷한 상황에 놓인 분들에게 작은 도움이라도 되길 바라는 마음으로 이 글을 작성합니다.

# 📋 프로젝트 개요

## 배경
- **프로젝트**: 재산관리통합 프로젝트
- **메인목표**: 고객사와 유사한 개발 환경 구축
- **서브목표**: 개발자들이 통합 환경에서 배포 및 소스코드를 관리 할 수 있는 환경 구축
- **요구사항**: OpenStack 기반 클라우드 인프라 구성


## 고객사 플랫폼 구성
- **상태**: 개발 중인 플랫폼 (불안정)
- **아키텍처**:
 - OpenStack 기반 클라우드
 - VM 위에 OpenShift 컨테이너 플랫폼
 - 별도 서버의 Git 및 Database

---

# 🛠 프로젝트 개발서버 구축 환경

## 시스템 사양
- **OS**: Rocky Linux 9.4
- **네트워크**: Online망 -> Offline망

## 기술 스택
- **클라우드 플랫폼**: OpenStack
- **자동화 도구**: Ansible
- **컨테이너**: Kubernetes

---

# ⚡ 주요 도전과제 및 해결방법

## 1. OpenStack 설치 도구 선택

### 시도한 방법들
1. **DevStack** ❌
 - Red Hat 지원 중단
 - Rocky Linux 9.4 비호환

2. **PackStack** ❌
 - 동일하게 지원 중단
 - 설치 패키지 부재

3. **Ansible (Kolla-Ansible)** ✅
 - 최종 선택한 방법
 - 안정적인 지원 및 커뮤니티

---


## 2. 버전 호환성 문제

### 문제 상황
- Python과 pip 버전 불일치
- Ansible 요구 버전 미충족
- 의존성 패키지 충돌

### 해결 과정
```bash
# Python 및 pip 업그레이드
sudo dnf update python3 python3-pip

# 가상환경을 통한 Ansible 설치
python3 -m venv ansible-env
source ansible-env/bin/activate
pip install ansible

# 버전 확인
ansible --version
python3 --version
pip --version
```

**소요 시간**: 2-3일 (OS 재설치 반복 포함)

## 3. OpenStack 설정 복잡성

### 주요 난점
1. **아키텍처 선택**
 - All-in-one vs Multi-node 구성
 - 리소스 및 용도에 따른 선택 기준 부족

2. **환경 설정**
 - `globals.yaml` 파일 설정
 - 네트워크, 스토리지 구성
 - 보안 설정

3. **설치 진행 상황 판단**
 - 에러와 정상 진행 구분 어려움
 - 로그 분석 능력 부족

---

# 📚 학습 포인트

## 기술적 측면
- **시스템 관리**: Linux 시스템 관리 능력 필요
- **네트워크**: 가상 네트워크 구성 이해
- **가상화**: OpenStack 아키텍처 및 컴포넌트 이해
- **자동화**: Ansible 플레이북 작성 및 실행

## 프로젝트 관리 측면
- **문서화**: 충분한 레퍼런스 부족 시 대응 방법
- **문제 해결**: 체계적인 디버깅 접근법
- **시간 관리**: 예상보다 긴 구축 시간 고려

---

# ⚠️ 주요 교훈

## 사전 준비의 중요성
1. **환경 조사**: 하드웨어 호환성 사전 확인
2. **도구 선택**: 지원 상태 및 커뮤니티 활성도 검토
3. **백업 계획**: 실패 시 복구 방안 수립

## 학습 접근법
1. **기초 지식**: OpenStack 아키텍처 이해 우선
2. **단계별 접근**: 컴포넌트별 순차 학습
3. **실습 환경**: 테스트 환경에서 충분한 검증

## 커뮤니티 활용
1. **공식 문서**: OpenStack 공식 문서 숙지
2. **커뮤니티**: Stack Overflow, Reddit 등 활용
3. **현업 조언**: 경험자 멘토링의 중요성

---

# ✅ 최종 결과
1. OpenStack 폐쇄망 구성 완료
2. 각 서비스별 VM 발행 후 CI/CD 구축 준비 완료
3. CI/CD 구축 후 개발 환경 구성완료

---

# 💭 회고 및 느낀 점

OpenStack 구축하면서 제일 먼저 느낀 건 이거였습니다. 
"아… 이건 그냥 설치만 한다고 되는 시스템이 아니구나." 
클라우드 인프라 전체를 알아야 하고, 네트워크 구조에 대한 감도 어느 정도 필요했습니다. 

처음엔 오류 로그만 봐도 머리가 아파서 
반나절은 로그 읽고, 반나절은 구글링하고, 또 반나절은 삽질하면서 보냈습니다. 
근데 이 과정을 겪다보니
자동화의 필요성이랑 환경 격리의 중요성은 진짜 몸으로 느낄 수 있었습니다. 

**이번에 얻은 핵심 교훈은 딱 세 가지입니다** 

	1.	문서 없는 환경에서 문제 해결은 결국 ‘시도 → 실패 → 기록’ 반복이 유일한 답이다.
	2.	OpenStack 같은 대형 시스템은 설치보다 유지보수가 난이도 최상이다.
	3.	Ansible은 선택지가 아니라 필수다. 자동화 없으면 재현성도 확장성도 없다.

다음에는 OpenStack을 그냥 구축하는 데서 끝내지 않고, 
각 컴포넌트가 내부에서 어떻게 통신하고 연결되는지 
아키텍처 레벨에서 제대로 뜯어보고 싶습니다. 
실제로 알아가다 보니 더 깊이 파고싶다는 생각이 들었습니다. 
지금은 시간이 없으니 추후 프로젝트 종료 후에 다시한번 깊게 공부하면서 파볼 예정입니다.

오픈스택 구축 경험 정리

> "우리 회사도 프라이빗 클라우드를 구축하고 싶어요."
> "AWS 비용이 너무 비싸서 온프레미스로 내리고 싶어요."
> 이럴 때 가장 먼저 거론되는 이름이 바로 **OpenStack**입니다. 수십 개의 프로젝트가 얽혀 있어 진입 장벽이 높기로 악명 높은 OpenStack. 하지만 핵심만 알면 **"데이터센터를 위한 운영체제"**라는 말이 딱 들어맞는 매력적인 도구입니다. 오늘은 OpenStack의 정체와 핵심 컴포넌트, 그리고 동작 원리를 아주 깊이 있게 파헤쳐 봅니다.

![OpenStack Services](https://superuser.openstack.org/wp-content/uploads/2018/09/Screen-Shot-2018-09-17-at-9.39.54-PM.png)

# 1. OpenStack이란 무엇인가?

쉽게 말해 **"오픈소스 버전의 AWS"**입니다.
여러분의 서버(컴퓨팅), 스토리지, 네트워크 장비들을 하나로 묶어서, 사용자가 웹 대시보드(Horizon)나 API를 통해 클릭 몇 번으로 가상 머신(VM)을 만들고, 네트워크를 구성할 수 있게 해주는 **IaaS(Infrastructure as a Service) 플랫폼**입니다.

### 🌍 누가 만드나요?
NASA와 Rackspace가 시작하여, 현재는 전 세계 수천 명의 개발자와 Red Hat, Canonical, Mirantis 등 거대 기업들이 참여하는 거대한 오픈소스 프로젝트입니다.

# 2. 핵심 아키텍처: 서비스들의 집합

OpenStack은 하나의 프로그램이 아닙니다. 수많은 **"프로젝트(서비스)"**들이 서로 API로 통신하며 유기적으로 동작합니다.
가장 기본이 되는 핵심 6대 서비스(**Keystone, Nova, Glance, Neutron, Cinder, Horizon**)만 알면 80%는 이해한 것입니다.

### 🔑 1. Keystone (Identity Service) - "문지기"
모든 요청은 Keystone을 통과해야 합니다.
* **역할**: 인증(Authentication) 및 인가(Authorization).
* **기능**: 사용자 관리, 서비스 카탈로그(어떤 서비스가 어디에 있는지) 제공.
* **비유**: AWS IAM + Service Discovery.

### 🖥️ 2. Nova (Compute Service) - "두뇌"
OpenStack의 주인공입니다. 가상 머신(VM)의 생명주기를 관리합니다.
* **역할**: Hypervisor(KVM, Xen 등)를 제어하여 VM을 생성(`spawn`), 삭제(`terminate`), 재부팅합니다.
* **비유**: AWS EC2.

### 💿 3. Glance (Image Service) - "설계도 보관소"
VM을 띄우려면 OS 이미지가 필요하겠죠? (Ubuntu, CentOS 등)
* **역할**: VM 이미지를 등록하고 관리합니다.
* **비유**: AWS AMI.

### 🕸️ 4. Neutron (Networking Service) - "혈관"
가장 복잡하고 중요한 부분입니다. 가상 네트워크를 정의합니다.
* **역할**: 가상 라우터, 스위치, 방화벽(Security Group), Floating IP 등을 관리합니다.
* **기술**: OVS(Open vSwitch), Linux Bridge 등을 사용하여 SDN(Software Defined Networking)을 구현합니다.
* **비유**: AWS VPC.

### 💾 5. Cinder (Block Storage) - "하드 디스크"
VM에 붙였다 뗐다 할 수 있는 영구 저장소입니다.
* **역할**: 외장 하드처럼 동작하는 블록 스토리지를 생성하고 VM에 마운트합니다.
* **비유**: AWS EBS.

### 🖥️ 6. Horizon (Dashboard) - "얼굴"
이 모든 것을 웹 브라우저에서 제어할 수 있는 GUI입니다.
* **역할**: 관리자 및 사용자용 웹 인터페이스.
* **비유**: AWS Management Console.

# 3. 어떻게 동작하나요? (VM 생성 흐름)

사용자가 "VM 하나 만들어줘"라고 요청하면 내부적으로 어떤 일이 일어날까요?

1. **사용자 -> Horizon**: 로그인 후 "인스턴스 시작" 버튼 클릭.
2. **Horizon -> Keystone**: 사용자 인증 토큰 발급.
3. **Horizon -> Nova-API**: "이 스펙(Flavor)으로, 이 이미지(Glance) 써서 VM 만들어줘."
4. **Nova -> Glance**: "OS 이미지 위치 좀 알려줘."
5. **Nova -> Neutron**: "이 VM이 쓸 IP랑 네트워크 포트 좀 만들어줘."
6. **Nova -> Cinder**: (필요시) "볼륨 하나 만들어서 붙여줘."
7. **Nova-Compute -> Hypervisor(KVM)**: "준비 다 됐다. 실제 프로세스 띄워!"

이 모든 과정이 API 호출과 Message Queue(RabbitMQ)를 통해 비동기로 척척 진행됩니다.

# 4. OpenStack 설치 및 운영 (현실)

### 🛠 설치 방법
맨땅에 헤딩(소스코드 컴파일)은 추천하지 않습니다. 배포 도구를 쓰세요.
* **DevStack**: 개발/테스트용. 스크립트 하나로 설치 끝. (운영용 절대 아님) - 현재 지원 중단
* **Kolla-Ansible**: 모든 서비스를 **Docker 컨테이너**로 띄워서 관리합니다. (현재 대세)
* **OpenStack-Ansible**: LXC 컨테이너 기반.
* **Red Hat OpenStack Platform (RHOSP)**: 엔터프라이즈 상용 솔루션.

### ⚠️ 운영 시 주의사항
* **네트워크(Neutron)**가 제일 어렵습니다. 패킷 흐름(VLAN, VXLAN)을 이해하지 못하면 트러블슈팅이 불가능합니다.
* **로그 분석**: 각 서비스(`nova-api.log`, `neutron-server.log` 등)가 분산되어 있으므로 ELK 스택 같은 중앙 집중형 로깅이 필수입니다.

# 마치며

OpenStack은 배우기 어렵지만, 한번 익히고 나면 **"클라우드가 밑바닥에서 어떻게 도는가"** 를 완벽하게 이해하게 됩니다. 가상화, 네트워크, 스토리지, 분산 시스템의 종합 선물 세트이기 때문이죠.

나만의 프라이빗 클라우드를 구축해보고 싶다면, 남는 PC 두어 대로 Kolla-Ansible과 All-in-one으로 시작해 보세요. 그곳이 바로 여러분만의 작은 데이터센터가 될 것입니다. ☁️

OpenStack 기초 가이드: 나만의 AWS를 만드는 오픈소스 클라우드 OS

> 회고록(回顧錄) 지나간 일을 돌이켜 생각하며 적은 기록.

# 2024년을 돌아보며

## 1. 퇴사와 새로운 시작 
2024년은 정말 다사다난한 한 해였습니다. 
3월을 끝으로 지난 회사를 떠나 5월에 현재 회사에 합류했는데, 규모도 크고 개발자로서 더 성장할 기회를 제공해준 회사였습니다. 
여러 사람들과 협업하고 제안서도 작성해보며, 평소 개발만 해서는 접하기 어려운 경험들을 하게 되어 감회가 새로웠습니다.

## 2. 올해의 목표와 가장 뿌듯했던 순간 
올해의 목표는 새로운 환경에 잘 적응하고 개발자로서 한 단계 성장하는 것이었습니다.

그중에서도 가장 뿌듯했던 순간은, 제가 참여한 제안서가 실제 프로젝트 수주로 이어지고, 치열한 경쟁 속에서 결국 우리 팀이 프로젝트를 따낸 일이었습니다. 
이런 기회를 만들어준 회사와 팀에 감사했고, 스스로 목표를 잘 수행하고 있다는 확신도 들었습니다.

## 3. 마찰과 기회 
물론 과정이 순탄하기만 했던 것은 아닙니다. 제안서 작업에서는 수많은 마찰과 긴장감이 있었고, 특히 실적 압박을 받는 부장·차장급 선임들의 부담감을 가까이서 지켜보며 개발자로서는 쉽게 경험하기 어려운 순간들을 겪었습니다.

코드·서비스·성장에 대한 고민만 하던 저에게, 프로젝트 수주 과정에서 사람들의 심리와 압박까지 함께 느껴본 것은 값진 경험이었습니다. 
이 경험은 제 성장의 중요한 발판이 되었습니다.

 

# ⏳ 프로젝트 경험 
현재 저는 그 제안서로 시작된 프로젝트에 투입되어 실제 개발까지 맡고 있습니다. 
제안서 작성부터 수주, 초기 문서 작업, 중간보고, 그리고 개발까지 이어지는 A to Z 전체 과정을 직접 경험하는 것은 정말 드문 기회라 더욱 의미가 큽니다.

## 4. DevOps & Infra 경험 
올해는 개발뿐 아니라 DevOps와 인프라 업무까지 맡게 되면서 스스로 한 단계 성장했다고 느낍니다.

사람이 부족해 자연스럽게 담당하게 되었지만, 회사 워크스테이션에 OpenStack을 설치하고 개발자들이 사용할 인프라를 구축한 경험은 그 자체로 소중했습니다. 
네트워크, k8s, 인프라 관리 등 다양한 영역을 공부하고 적용하며, 개발자들이 편하게 코드 관리와 배포를 할 수 있는 환경을 성공적으로 구축했습니다. 
내년에는 이 과정들을 블로그에 조금씩 기록할 예정입니다.

 

# 💻 블로그 개발 
올해 초 제작한 블로그를 꾸준히 업데이트하며, 연말에 이렇게 회고록을 남기니 감회가 더욱 새롭습니다.

"나만의 블로그를 갖고 싶다"는 생각에서 시작했지만, 직접 설계·개발·디자인을 거쳐 완성한 뒤 운영해보니 스스로 만든 공간을 가진다는 것이 큰 기쁨이었습니다. 
블로그 개발 과정은 백엔드, 프론트엔드, 인프라, 디자인 등 모든 영역을 고민하게 했고, 개발의 재미를 다시 느끼게 해준 계기이기도 했습니다.

 

# ✅ 마무리 
올해는 정말 많은 일들이 있었습니다.

- 나만의 블로그 구축 
- 퇴사와 새로운 회사 입사 
- 프로젝트 제안 및 수주 경험 
- DevOps 및 인프라 담당 
- 그리고 현재 진행 중인 프로젝트 개발

개발자로서 다양한 경험을 하게 해준 회사와 팀원들에게 감사하며, 내년에는 프로젝트 완주에 집중하려 합니다. 

올 한 해 모두 고생 많으셨습니다. 
따뜻한 연말 되시길 바랍니다. 

감사합니다.

2024년 회고록

> TypeScript를 쓴다는 것은 단순히 변수 뒤에 `: string`을 붙이는 것이 아닙니다. 진정한 TypeScript의 힘은 **"타입 시스템을 프로그래밍"**할 때 나옵니다. 단순한 인터페이스 선언을 넘어, 조건부 타입, 맵드 타입, 템플릿 리터럴 타입을 활용하여 라이브러리 레벨의 정교한 타이핑을 하는 방법까지. 오늘은 10년 차 개발자도 헷갈려하는 **TypeScript의 심연(Abyss)**을 아주 깊고 길게 들여다보겠습니다.

![TypeScript Advanced](https://images.unsplash.com/photo-1516116216624-53e697fedbea?q=80&w=2128&auto=format&fit=crop)

# 1. 제네릭(Generics): 타입의 함수화

가장 기초적이지만 가장 강력한 도구입니다. 제네릭은 **"타입을 인자로 받는 함수"**라고 생각하면 이해가 빠릅니다.

### 🧬 기본 개념
```typescript
// T라는 타입 변수를 받아서 그대로 반환하는 타입 함수
type Identity<T> = T;

type StringIdentity = Identity<string>; // string
```

### 🧩 실전 응용: API 응답 래퍼
```typescript
interface ApiResponse<Data> {
 status: number;
 message: string;
 data: Data; // Data 타입은 나중에 정해진다
}

interface User { id: number; name: string; }

// 이제 User 타입이 쏙 들어간 응답 타입을 만들 수 있습니다.
function fetchUser(): Promise<ApiResponse<User>> { ... }
```

# 2. keyof & Mapped Types: 객체 타입을 마음대로 조작하기

기존 타입을 재활용해서 새로운 타입을 찍어내는(Map) 기술입니다.

### 🔑 keyof 연산자
객체 타입의 **키(Key)**들만 뽑아서 유니온 타입으로 만듭니다.
```typescript
interface User { id: number; name: string; age: number; }
type UserKeys = keyof User; // "id" | "name" | "age"
```

### 🗺️ Mapped Types (in)
`[K in Keys]` 문법을 사용해 객체의 모든 속성을 순회합니다.

```typescript
// 모든 속성을 Readonly로 만들기 (유틸리티 타입 Readonly<T>의 원리)
type MyReadonly<T> = {
 readonly [K in keyof T]: T[K];
};

// 모든 속성을 Optional로 만들기 (Partial<T>의 원리)
type MyPartial<T> = {
 [K in keyof T]?: T[K];
};
```

# 3. Conditional Types: 타입 세계의 if문

`T extends U ? X : Y` 형태의 삼항 연산자를 사용하여 조건에 따라 타입을 분기합니다. **타입 체조의 시작점**입니다.

### 🚦 기본 문법
```typescript
type IsString<T> = T extends string ? true : false;

type A = IsString<string>; // true
type B = IsString<number>; // false
```

### 🕵️‍♀️ infer: 타입 추론하기
조건부 타입 안에서 `infer` 키워드를 쓰면, TypeScript가 추론한 타입을 변수처럼 가져올 수 있습니다. 주로 **"안에 들어있는 타입 꺼내기"** 용도로 쓰입니다.

```typescript
// Promise<T>에서 T만 쏙 꺼내는 유틸리티 (Awaited<T>의 원리)
type UnwrapPromise<T> = T extends Promise<infer U> ? U : T;

type Result = UnwrapPromise<Promise<string>>; // string
```

# 4. Template Literal Types: 문자열 가지고 놀기

TypeScript 4.1부터 도입된 기능으로, 문자열 리터럴 타입을 템플릿 리터럴 문법으로 조합할 수 있습니다. CSS-in-JS 라이브러리나 이벤트 핸들러 타이핑에 혁명을 가져왔습니다.

### 🎨 색상 코드 조합하기
```typescript
type Color = "red" | "blue";
type Shade = "100" | "200" | "300";

// 자동으로 모든 조합이 생성됩니다!
type Palette = `${Color}-${Shade}`;
// "red-100" | "red-200" | "red-300" | "blue-100" ...
```

### 🛠 이벤트 핸들러 자동 생성
```typescript
type Entity = "User" | "Post";
type EventName = `on${Entity}Change`; // "onUserChange" | "onPostChange"

const handlers: Record<EventName, () => void> = {
 onUserChange: () => {},
 onPostChange: () => {},
 // onCommentChange: () => {} // 에러! 타입에 없음
};
```

# 5. 실전 예제: Type-safe `get` 함수 만들기

`lodash.get` 처럼 중첩된 객체의 값을 점(`.`) 표기법으로 가져오는 함수를 타입 안전하게 만들어 봅시다.

```typescript
// 재귀적 타입 정의 (Recursive Type Definitions)
type Path<T> = T extends object
 ? {
 [K in keyof T]: K extends string
 ? `${K}` | `${K}.${Path<T[K]>}` // 현재 키 | 현재 키.하위 키
 : never;
 }[keyof T]
 : never;

// 사용 예시
interface Config {
 server: {
 port: number;
 database: {
 host: string;
 };
 };
}

// P는 "server" | "server.port" | "server.database" | "server.database.host" 만 허용됨!
function get<T, P extends Path<T>>(obj: T, path: P) { ... }

const config: Config = { ... };
get(config, "server.database.host"); // OK
get(config, "server.db.password"); // Error: 타입에 없는 경로!
```
이 코드가 컴파일 타임에 경로 유효성을 검사해줍니다. 오타가 날 수가 없는 구조죠.

# 6. 공변성(Covariance)과 반공변성(Contravariance)

고급 사용자가 되기 위해 꼭 넘어야 할 산입니다. 타입 호환성에 관한 이야기입니다.

- **공변성**: `Cat`이 `Animal`의 서브타입이면, `List<Cat>`도 `List<Animal>`의 서브타입이다. (리턴 타입에서 적용)
- **반공변성**: 함수의 **매개변수**에서는 반대로 동작합니다. `Animal`을 받는 함수에 `Cat`을 받는 함수를 넣을 수 없습니다. (더 좁은 타입을 받는 함수는 더 넓은 타입을 받는 자리에 못 들어감)

이 원리를 모르면, 함수형 프로그래밍이나 복잡한 콜백 타입을 다룰 때 이해할 수 없는 에러를 마주하게 됩니다.

# 마치며
> 타입은 문서다

TypeScript를 잘 쓴다는 것은 **"런타임 에러를 컴파일 타임 에러로 옮겨오는 능력"**을 기르는 것입니다.

오늘 다룬 내용들이 어렵게 느껴질 수 있습니다. 하지만 이 개념들을 자유자재로 다루게 되면, 여러분의 코드는 그 자체로 **살아있는 문서**가 되고, 동료 개발자들에게 **최고의 생산성 도구**가 되어줄 것입니다.

이제 IDE의 자동완성(IntelliSense)이 여러분의 손끝에서 춤추게 만들어보세요! 💃🕺

TypeScript 마스터하기: 타입 체조(Type Gymnastics)부터 고급 패턴까지

> TypeScript 문법은 알지만 실무 코드에서 어떻게 써야 할지 막막하신가요? "이거 `any` 써도 되나요?"라고 묻기 전에 잠깐만요! 실무에서 버그를 줄이고, 코드의 가독성을 높이며, "이 사람 TS 좀 치네?"라는 소리를 들을 수 있는 **핵심 패턴과 팁 5가지**를 엄선했습니다.

![TypeScript Tips](https://images.unsplash.com/photo-1555066931-4365d14bab8c?q=80&w=2070&auto=format&fit=crop)

# 1. Exhaustiveness Checking (모든 케이스 처리 강제하기)

`switch` 문이나 `if-else` 분기에서 **"빠뜨린 케이스"가 있으면 컴파일 에러를 내는 기법**입니다. 상태 관리가 복잡한 프론트엔드 로직에서 필수입니다.

```typescript
type Shape = { kind: "circle" } | { kind: "square" };

function getArea(shape: Shape) {
 switch (shape.kind) {
 case "circle": return Math.PI * 2;
 case "square": return 100;
 default:
 // 만약 나중에 "triangle"이 추가되면 여기서 에러가 발생합니다!
 const _exhaustiveCheck: never = shape;
 return _exhaustiveCheck;
 }
}
```
나중에 누군가 `Shape` 타입에 `triangle`을 추가하고 `switch` 문을 수정하지 않으면, 컴파일러가 빨간 줄을 긋고 알려줍니다. (유지보수의 신!)

# 2. Branded Types (같은 타입, 다른 의미 구분하기)

`string` 타입이지만 `UserId`와 `PostId`를 섞어 쓰면 안 될 때가 있습니다. 하지만 TypeScript는 구조적 타이핑(Structural Typing)이라 둘 다 그냥 `string`으로 취급하죠.
이때 **Branded Type(Nominal Typing 흉내내기)**을 씁니다.

```typescript
type Brand<K, T> = K & { __brand: T };

type UserId = Brand<string, "UserId">;
type PostId = Brand<string, "PostId">;

const userId = "user_123" as UserId;
const postId = "post_456" as PostId;

function deleteUser(id: UserId) { ... }

// ❌ 컴파일 에러! PostId는 UserId 자리에 들어갈 수 없습니다.
deleteUser(postId);
```
실수로 유저 ID 자리에 게시글 ID를 넣어서 DB를 날려버리는 사고를 원천 차단할 수 있습니다.

# 3. Discriminated Unions (구별된 유니온)

타입 좁히기(Type Narrowing)를 가장 우아하게 하는 방법입니다. 공통된 리터럴 속성(`type`, `kind` 등)을 두어 타입을 구분합니다.

```typescript
// ❌ 안 좋은 예: 모든 게 Optional
interface Response {
 status: "success" | "error";
 data?: User;
 error?: string;
}

// ✅ 좋은 예: 상태에 따라 확정된 타입
type Response = 
 | { status: "success"; data: User } // 성공이면 data는 무조건 있음
 | { status: "error"; error: string }; // 에러면 error 메시지가 무조건 있음

if (res.status === "success") {
 console.log(res.data.name); // ? 없이 접근 가능 (타입 좁혀짐)
}
```

# 4. as const (리터럴 추론)

객체나 배열을 **읽기 전용 리터럴 타입**으로 고정합니다. Redux 액션이나 설정 상수를 정의할 때 유용합니다.

```typescript
const routes = {
 HOME: "/",
 LOGIN: "/login",
} as const;

// type Route = "/" | "/login"
// string이 아니라 정확한 값으로 추론됩니다.
type Route = (typeof routes)[keyof typeof routes];

function navigate(path: Route) { ... }
```
`as const` 하나만 붙이면 `string`으로 퉁쳐지는 것을 막고 강력한 자동완성 효과를 얻을 수 있습니다.

# 5. Type Predicates (`is` 키워드)

`filter` 함수를 쓸 때 `undefined`를 걸러냈는데도 타입이 여전히 `undefined`를 포함하고 있어 답답했던 적 있으신가요?
**사용자 정의 타입 가드**를 쓰면 해결됩니다.

```typescript
const values = ["a", undefined, "b", null];

// ❌ 결과 타입: (string | undefined | null)[]
const badFilter = values.filter(v => v !== undefined && v !== null);

// ✅ Type Predicate 사용
function isString(val: any): val is string {
 return typeof val === "string";
}

// ⭕️ 결과 타입: string[]
const goodFilter = values.filter(isString);
```

# 마치며

TypeScript는 단순히 "에러를 잡아주는 도구"가 아니라, **"우리의 의도를 코드로 명확히 표현하는 언어"** 입니다.
오늘 소개한 패턴들을 코드에 하나씩 적용해 보세요. 코드가 훨씬 더 단단해지고, 동료들이 여러분의 코드를 믿고 사용할 수 있게 될 것입니다. 🚀

사수에게 칭찬받는 TypeScript 핵심 패턴 5가지

> 2002년, 로드 존슨(Rod Johnson)이 쓴 책 한 권에서 시작된 프레임워크가 전 세계 자바 생태계를 지배하게 되었습니다. EJB(Enterprise JavaBeans)의 복잡함에 반기를 들고 일어난 Spring은 어떻게 진화해 왔을까요? Spring 1.0부터 최신 Spring 6.0까지, 각 시대를 관통하는 핵심 변화와 특징을 정리해 봅니다.

![Spring History](https://images.unsplash.com/photo-1461360228754-6e81c478b882?q=80&w=2074&auto=format&fit=crop)

# 1. Spring 1.0 ~ 2.0: XML의 시대 (2004~2006)

**EJB 없는 가벼운 개발(Lightweight)** 을 모토로 등장했습니다. 
핵심은 **DI(Dependency Injection)** 와 **AOP(Aspect Oriented Programming)** 였습니다.

- **특징**: 모든 빈(Bean) 설정을 applicationContext.xml이라는 거대한 XML 파일에 일일이 적어야 했습니다.
- **문제점**: 프로젝트가 커질수록 XML 파일이 수천 줄을 넘어가며 관리가 불가능한 수준(XML Hell)이 되기 시작했습니다.

# 2. Spring 2.5 ~ 3.0: 어노테이션의 혁명 (2007~2009)

개발자들의 XML 피로도가 극에 달했을 때, Spring은 **Java Annotation**을 적극적으로 도입하기 시작합니다.

- **@Component, @Autowired 등장**: XML에 bean 태그를 쓰는 대신, 클래스 위에 @Service, @Controller만 붙이면 되게 바뀌었습니다.
- **Java Config (Spring 3.0)**: XML을 완전히 버리고 Java 코드(@Configuration, @Bean)로 설정을 관리할 수 있게 되었습니다. 이것이 훗날 Spring Boot의 기반이 됩니다.

# 3. Spring 4.0: Spring Boot의 탄생 (2013)

Spring 역사상 가장 큰 분기점입니다. **설정보다 관례(Convention over Configuration)** 를 내세운 **Spring Boot**가 등장했습니다.

- **Java 8 지원**: 람다(Lambda) 식을 사용할 수 있게 되었습니다.
- **Spring Boot 1.0**: 내장 톰캣(Embedded Tomcat)을 탑재하여 main() 메서드 실행만으로 웹 서버를 띄우는 충격적인 경험을 선사했습니다.
- **자동 설정(Auto Configuration)**: spring-boot-starter-web 하나만 추가하면 수십 가지 설정을 알아서 해주는 마법이 시작되었습니다.

# 4. Spring 5.0: 리액티브 프로그래밍 (2017)

Node.js의 비동기 논블로킹 모델이 인기를 끌자, Spring도 이에 대응하기 위해 대대적인 변화를 줍니다.

- **Spring WebFlux**: 기존의 서블릿(Servlet) 기반 블로킹 모델(Spring MVC)과 별도로, 완전한 비동기 논블로킹 웹 프레임워크를 출시했습니다.
- **Project Reactor**: Mono, Flux 같은 리액티브 타입을 표준으로 도입했습니다.
- **JDK 9 모듈 시스템** 대응이 시작되었습니다.

# 5. Spring 6.0 & Boot 3.0: 클라우드 네이티브 (2022~현재)

클라우드와 서버리스(Serverless) 환경에 최적화하기 위해, Spring은 과감하게 **과거와의 단절**을 선언합니다.

- **Java 17 필수**: 최소 요구 사항이 Java 8에서 17로 껑충 뛰었습니다. (Java EE -> Jakarta EE로 패키지명 변경 대혼란)
- **GraalVM Native Image**: JIT 컴파일러 대신 AOT(Ahead-of-Time) 컴파일을 지원하여, JVM 없이 실행되는 **네이티브 바이너리**를 만들 수 있게 되었습니다.
 - 부팅 속도: 수 초 -> 0.1초
 - 메모리 사용량: 수백 MB -> 수십 MB

# 마치며: Spring은 늙지 않는다

20년이 넘은 프레임워크가 여전히 현역 1타 자리를 지키는 이유는 끊임없는 **자기 혁신** 때문입니다.
EJB를 죽이러 왔던 Spring이 이제는 Serverless와 AI 시대(Spring AI)를 준비하고 있습니다.

여러분의 프로젝트는 지금 어떤 Spring 버전에 머물러 있나요? 3.x? 4.x? 이제는 6.0으로 넘어올 때입니다. 🚀

Spring Framework 변천사: XML 지옥에서 Native Image까지

![typescript](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/e8c1cc3c-8aa3-42f8-9382-60df0d5c2cee_typescript.jpeg)

# react-native와 typescript로 공부를 하다 진짜 너무 황당한 에러를 맞딱뜨렸다..
>'string | null' 형식의 인수는 'string' 형식의 매개 변수에 할당될 수 없습니다. 'null' 형식은 'string' 형식에 할당할 수 없습니다.

---

# 무슨 내용의 에러인가
## 1. 우선 코드를 살펴보자
```typescript
const key = 'todos';
const rawTodos = await AsyncStorage.getItem(key);
const savedTodos: ITodos[] = JSON.parse(rawTodos);
```
1. AsyncStorage에 있는 todos라는 key로 Object Value를 가져와서 rawTodos 변수에 저장한다.
2. rawTodos에 저장되어있는 Object를 JSON.parse를 통해 파싱을 해서 savedTodos 변수에 저장한다.
3. 이때 JSON.parse(rawTodos)에서 rawTodos에 빨간색 밑줄이 생기면서 위의 에러를 떨군다

## 2. 무엇이 문제인가
해당 코드의 에러는 typescript에서 발생해서 타입이 맞지않는다는 에러인데 rawTodos에
const rawTodos: string | null
으로 type을 지정해줘도 위의 에러는 사라지지않았다

---

# 해결방법
정말 온갖 생쇼를 하다가 정말 간단하게 해결했다
## 1. 해결방법1
```typescript
const key = 'todos';
const rawTodos = await AsyncStorage.getItem(key);
if (!rawTodos) {
 throw new Error('No saved todos');
}
const savedTodos: ITodos[] = JSON.parse(rawTodos);
```
위의 코드처럼 rawTodos가 없을때 즉 null일 경우 처리해준다

## 2. 해결방법2
tsconfig.json에서 
strictNullChecks: false 
로 설정해준다 
typescript로 개발하다보면 현재의 경우처럼 빡세게 null 체크를 할 때가있는데 이걸 false로 해주면 좀 널널하게 바꿔준다는것 같다

---

# 마무리
typescript를 공부하는 중이라 정말 여러가지 난관에 부딪히는거 같다
특히 저런 에러는 구글링을해도 잘 못찾겠더라
typescript를 잘다루기까지의 난관이 너무 험난하다...

TypeScript 타입 에러

![nestjs](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/709b0388-fd0c-4648-a768-381a590ad90e_nestjs.jpg)

> NestJS 패키지 설치시 ts-jest 때문에 설치가 안되는 현상

# 2023년 1월 중순부터 현재(1월 31일)까지 ts-jest 설치가 안되는 현상이 발견됨

1. 일단 이렇게 패키지 설치가 안될경우에 패키지의 문제인지 아닌지를 확인하기위해서 스택오버플로우에 검색을 해봤지만 외국인들은 설치가 잘만 되는것 같았다
2. 그럼 집에있는 네트워크가 문제인가 싶어 노트북에 핸드폰 테더링을 연결해서 install 해봤지만 실패 (집에있는 인터넷, 핸드폰 모두 KT 사용중)
3. 그렇다면 생각해볼 수 있는건 통신사 문제라는것으로 결론이 났고 그렇게 구글링 시작


# 현재 이 문제는 KT를 사용하고 있는 한국사람들 대상으로 일어나고 있는 문제가 맞았다

1. https://github.com/kulshekhar/ts-jest/issues/3992 확인해보니
2. 한국인들이 이슈를 열어 놓은게 있어 읽어봤다
3. KT망에서만 설치가 안되는것을 확인했다
4. npm support 팀에서 KT망에서만 안되는 원인을 파악중이라고 한다


# 해결책
`npm config set registry https://registry.npmjs.cf/`을 터미널에 입력해 mirror로 바꿔주고 install 하면 제대로 설치된다
나중에 이슈가 해결되면

`npm config set registry https://registry.npmjs.org/`
로 다시 바꿔주는것도 잊지말자..

# 결론
KT나 npm쪽에서 아직 공식적인 발표가 없어 뭐라 하긴 힘들지만... 1월 초까지만 해도 분명 잘됐었다 지금 KT 사용자만 안되는걸로봐선 거의 KT 잘못이 확실한것 같다... 통신사를 바꾸던지 해야지...



ts-jest 설치 안되는 현상


# 새로운 시작 블로그를 열며

저만의 공간을 가지고 싶어 블로그를 하나 만들어 제 생각을 남길 예정입니다

지금 상용하고있는 여러 블로그도 있지만 내 입맛대로 꾸미고싶은 욕심이 항상 있어서

이렇게 만들어서 운영하게 됐습니다

제 블로그에 쓴 글 들이 누군가에겐 도움이 되길 바라며...