조급하지말고 천천히

15일에 19번 업데이트? Claude Code 1월 업데이트 정리

오산돌구 — Sun, 25 Jan 2026 15:42:42 +0900

업무에서 Claude Code를 설계와 검증에 더 시간을 쏟고 구현은 거의 안 하는 느낌으로 사용하고 있다.

사용하다 보면 Claude Code에 좋다고 하는 추가 skill이나 에이전트 소개가 많이 나오는데 크게 관심이 없다.

왜냐하면 정말 좋다고 하면 엔트로픽에서 Claude Code에 조만간 반영하겠지.. 생각이 크다.

이번에 TODO -> TASK를 바꾼것도 비슷한 맥락이다.

Claude Code에 대한 내 생각을 적어봤는데 이번글에서는 그래서 올해 Claude Code에 어떤 수정이 있었는지 정리해 봤다.

작년 12월에 회사에서 발표한 slash command(skill로 합쳐짐)와 단축키 슬라이드다.

없어진 명령어와 기능도 있으니 참고해서 테스트하고 본인에게 맞는 걸 쓰면 된다.

RELEASE NOTE

정리해 달라고 먼저 요청하고 수정했다.

버전	날짜	핵심변경사항
v2.1.0	1월 9일	메이저 업데이트!! Skill 핫리로드, language 설정
v2.1.2	1월 9일	winget 지원
v2.1.3	1월 9일	slash command와 skill 통합
v2.1.4	1월 10일	백그라운드 작업 비활성화 옵션
v2.1.5	1월 12일	임시 디렉토리 커스터마이징
v2.1.6	1월 13일	/config 검색, /stats 필터링
v2.1.7	1월 14일	커스텀 키바인딩, MCP 자동모드
v2.1.9	1월 16일	plansDirectory, 외부 에디터지원
v2.1.10	1월 17일	Setup 훅 이벤트
v2.1.11	1월 17일	MCP 연결 최적화
v2.1.12	1월 17일	렌더링 버그 수정
v2.1.14	1월 20일	Bash 히스토리 자동완성, 플러그인 검색
v2.1.15	1월 21일	React Compiler 성능 개선
v2.1.16	1월 22일	Task Management 시스템
v2.1.17	1월 22일	AVX 호환성 수정
v2.1.18	1월 23일	고급 키바인딩 시스템
v2.1.19	1월 23일	VSCode 세션 포크, Custom command 인자 문법

핵심기능 Top 7

1. Skill 시스템 기능 강화 (v2.1.0, v2.1.19)

자동 스킬: ~/.claude/skills 폴더 파일 수정 시 세션 재시작 없이 즉시 반영

`context: fork`: 스킬을 fork된 subagent 컨텍스트에서 실행

slash command 통합: `/스킬명` 으로 스킬 직접 호출 가능

Hook 지원: 스킬 frontmatter에서 PreToolUse, PostToolUse, Stop Hook 정의

승인 없이 사용 가능: 추가 권한이나 훅이 없는 스킬은 승인 절차 없이 바로 실행 가능 (v2.1.19)

실전활용 예시 1

```yaml
# ~/.claude/skills/test-runner.md
---
name: test-runner
description: 테스트를 실행하고 결과를 분석합니다
context: fork
allowed-tools:
  - Bash(npm test *)
  - Bash(jest *)
  - Read
hooks:
  PreToolUse:
    - command: echo "  테스트 시작: $(date)"
  PostToolUse:
    - command: |
        if [ $TOOL_EXIT_CODE -ne 0 ]; then
          echo "❌ 테스트 실패 - 로그 확인 필요"
        fi
---


# 테스트 러너

이 스킬은 프로젝트의 테스트를 실행하고 결과를 분석합니다.

## 수행 작업
1. package.json에서 테스트 스크립트 확인
2. 테스트 실행
3. 실패한 테스트 분석 및 해결책 제안
``


# 사용 방법
```bash
# Claude Code에서
/test-runner
```

실전활용 예시 2

포크 한 subagent에서 skill 실행

```yaml
# ~/.claude/skills/code-review.md
---
name: code-review
description: Git 변경사항을 분석하고 코드 리뷰를 수행합니다
context: fork
allowed-tools:
  - Bash(git diff *)
  - Bash(git log *)
  - Read
  - Grep
---

# 코드 리뷰어

현재 브랜치의 변경사항을 분석하여 코드 리뷰를 수행합니다.

## 검토 항목
- 코드 스타일 일관성
- 잠재적 버그
- 성능 이슈
- 보안 취약점
- 테스트 커버리지
```

2. Task Management 시스템 (v2.1.16, v2.1.19)

복잡한 멀티스텝 프로젝트를 관리할 수 있는 작업관리시스템이 도입됐다.

# Claude Code에서

print a list that usable tools.

새로운 Task Management가 맞지 않는다면 환경변수 추가로 비활성화할 수 있다.

```bash

export CLAUDE_CODE_ENABLE_TASKS=false

```

실전활용 예시

"JWT 인증으로 마이그레이션 할 건데, 단계별로 작업 목록을 만들고 의존성을 설정해서 순서대로 진행해 줘"

3. 고급 키바인딩 시스템 (v2.1.18)

https://code.claude.com/docs/en/keybindings

```json
// ~/.claude/settings.json
{
  "keyBindings": {
    // 기본 키바인딩
    "submit": "ctrl+enter",
    "escape": "ctrl+c",

    // 컨텍스트별 설정
    "vim.normal": {
      "gg": "scrollToTop",
      "G": "scrollToBottom"
    },
    "vim.insert": {
      "ctrl+[": "exitInsertMode"
    }
  }
}
```

4. 커스텀 명령어 인자 문법 개선 (v2.1.19)

short hand syntax: `$0`, `$1`, `$2`

```yaml
# ~/.claude/commands/deploy.md
---
name: deploy
description: 특정 환경에 배포합니다
---

# 배포 명령어

환경: $0
브랜치: $1

## 실행
$0 환경으로 $1 브랜치를 배포합니다.
```


**사용 방법:**
```bash
/deploy production main
# → $0 = "production", $1 = "main"
```

5. MCP 자동 모드 (v2.1.7, v2.1.9)

MCP의 도구 설명이 전체 컨텍스트 사용량이 임계값을 초과하면

MCP 연결을 자동으로 지연시켜 컨텍스트를 최적화한다.

```json
// ~/.claude/settings.json
{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["./server.js"],
      "mode": "auto:30"  // 30% 컨텍스트 초과 시 지연
    }
  }
}
```

| 모드 | 설명 |
|------|------|
| `"mode": "auto"` | 기본값 (10% 초과 시 지연) |
| `"mode": "auto:30"` | 30% 초과 시 지연 |
| `"mode": "auto:0"` | 항상 지연 (필요할 때만 연결) |
| `"mode": "enabled"` | 항상 연결 |

실전활용 예시

{
  "mcpServers": {
    // 자주 사용하는 서버: 항상 연결
    "database": {
      "command": "mcp-postgres",
      "mode": "enabled"
    },
    // 가끔 사용하는 서버: 컨텍스트 절약
    "analytics": {
      "command": "mcp-analytics",
      "mode": "auto:50"
    }
  }
}

6. Bash 히스토리 자동완성 (v2.1.14)

1. `!` 모드로 진입

2. 이전에 실행했던 명령어 일부 입력

3. Tab 키를 눌러 히스토리에서 자동완성

```bash

# 예시: 이전에 "npm run build:production" 실행했다면

!npm run bu[Tab]

# -> npm run build:production 자동완성

```

개발자 경험 향상

설정 옵션 완벽 가이드

{
  // 응답 언어 설정 (v2.1.0)
  "language": "korean",

  // 계획 파일 저장 위치 (v2.1.9)
  "plansDirectory": "~/Documents/claude-plans",

  // 턴 시간 표시 숨기기 (v2.1.7)
  "showTurnDuration": false,

  // @-멘션 파일 선택기에서 .gitignore 적용 (v2.1.0)
  "respectGitignore": true,

  // 커스텀 키바인딩 (v2.1.7, v2.1.18 확장)
  "keyBindings": {
    "submit": "ctrl+enter",
    "escape": "ctrl+c"
  }
}

환경변수

```bash
# ~/.zshrc 또는 ~/.bashrc에 추가

# 임시 디렉토리 커스터마이징 (v2.1.5)
export CLAUDE_CODE_TMPDIR="/tmp/claude-workspace"

# 백그라운드 작업 비활성화 (v2.1.4)
export CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=true

# 스트리밍/데모용 이메일/조직 숨기기 (v2.1.0)
export IS_DEMO=true

#   Task Management 비활성화 (v2.1.19)
export CLAUDE_CODE_ENABLE_TASKS=false
```

Hook 시스템 확장

새로운 Hook 이벤트: Setup (v2.1.10)

`--init`, `--init-only`, `--maintenance` 플래그로 실행될 때 트리거된다.

// settings.json
{
  "hooks": {
    "Setup": [
      {
        "command": "echo '초기화 시작: $(date)' >> ~/.claude/init.log"
      },
      {
        "command": "./scripts/check-env.sh",
        "timeout": 5000
      }
    ]
  }
}

일회성 Hook

`once: true`

{
  "hooks": {
    "PreToolUse": [
      {
        "command": "echo '첫 도구 사용!'",
        "once": true  // 세션당 한 번만 실행
      }
    ]
  }
}

PreToolUse의 additionalContext 반환

#!/bin/bash
# ~/.claude/hooks/context-provider.sh

# JSON 형태로 additionalContext 반환
echo '{"additionalContext": "현재 프로젝트는 TypeScript 5.0을 사용합니다."}'

TIP

1. 효율적인 Skill 구조

~/.claude/skills/
├── daily/
│   ├── standup.md       # 일일 스탠드업 정리
│   └── review.md        # 코드 리뷰
├── project/
│   ├── deploy.md        # 배포 자동화
│   └── db-migrate.md    # DB 마이그레이션
└── personal/
    ├── blog-helper.md   # 블로그 작성 도우미
    └── learning.md      # 학습 노트 정리

2. MCP 서버 최적화 설정

{
  "mcpServers": {
    // 핵심 서버: 항상 연결
    "filesystem": {
      "command": "mcp-filesystem",
      "mode": "enabled"
    },
    // 보조 서버: 필요할 때만
    "github": {
      "command": "mcp-github",
      "mode": "auto:20"
    },
    // 무거운 서버: 명시적 요청 시만
    "kubernetes": {
      "command": "mcp-k8s",
      "mode": "auto:0"
    }
  }
}

3. 커스텀 키바인딩 설정

{
  "keyBindings": {
    "submit": "ctrl+enter",      // 전송
    "escape": "ctrl+c",          // 취소
    "interrupt": "ctrl+d"        // 중단
  }
}

마지막으로 프로젝트 경로 설정하는 환경변수도 찾아봤다.

주요 환경변수 목록

변수명	설명	사용 가능 위치
CLAUDE_PROJECT_DIR	프로젝트 루트 절대 경로	Hooks, MCP Server
CLAUDE_ENV_FILE	환경변수 영속화용 파일 경로	SessionStart, Setup Hook만
CLAUDE_PLUGIN_ROOT	플러그인 디렉토리 경로	Plugin hooks
CLAUDE_CODE_REMOTE	원격 실행 여부 ("true" or 빈값)	모든 곳

활용 예시

Hook에서 사용

{

"hooks": {

"PreToolUse": [

{

"matcher": "Bash",

"command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/validate.sh"

}

]

}

plandDirectory 설정에 활용

아쉽게도 settings.json에서는 환경변수 치환이 지원되지 않는다.

// ❌ 이렇게는 안 됨

{

"plansDirectory": "$CLAUDE_PROJECT_DIR/claudeworkspace"

}

// ✅ 상대 경로로 사용

{

"plansDirectory": "./claudeworkspace"

}

SessionStart Hook에서 환경변수 설정

#!/bin/bash
# .claude/hooks/session-start.sh

# 다른 명령어에서 사용할 변수 영속화
echo "export MY_WORKSPACE=$CLAUDE_PROJECT_DIR" >> "$CLAUDE_ENV_FILE"
echo "export MY_PLANS_DIR=$CLAUDE_PROJECT_DIR/claudeworkspace" >> "$CLAUDE_ENV_FILE"

---
Hook 입력으로 받는 정보 (stdin JSON)

{
  "session_id": "abc123",
  "cwd": "/current/working/directory",
  "transcript_path": "/path/to/conversation.json",
  "permission_mode": "default"
}

★ Insight ─────────────────────────────────────

- CLAUDE_PROJECT_DIR vs cwd: CLAUDE_PROJECT_DIR는 Claude Code를 시작한 프로젝트 루트이고, cwd는 현재 작업 디렉토리입니다. cd 명령으로 이동해도 CLAUDE_PROJECT_DIR는 변하지 않습니다.

- settings.json 제한: 설정 파일에서는 환경변수 치환이 안 되므로,./claudeworkspace처럼 상대 경로를 사용하면 프로젝트 루트 기준으로 자동 해석됩니다.

- CLAUDE_ENV_FILE: SessionStart 훅에서만 사용 가능하며, 여기에 export VAR=value를 추가하면 이후 Bash 명령어에서 해당 변수를 사용할 수 있습니다.

─────────────────────────────────────────────────

참고 자료

- Claude Code GitHub Releases

- 공식 CHANGELOG

- 키바인딩 문서

- ClaudeLog Changelog

- Releasebot Updates

오픈소스 만들어 Github에 올릴 때 하면 좋은 체크리스트 .. (2)

오산돌구 — Tue, 10 Jun 2025 21:40:21 +0900

Github 블로그 글을 보며 정리한 글에 이어서 이번에는 README와 릴리즈 노트 관련 글을 읽고 정리했다.

https://dol9.tistory.com/338

오픈소스 만들어 Github에 올릴 때 하면 좋은 체크리스트 .. (1)

아직은 진행중이라 Private으로 진행하고 있지만 간단한 오픈소스를 만들어 공개해보려고 한다. 외부 OpenAPI를 호출하는 아주 단순하고 목적이 명확한 클라이언트다.기능이야 문서 보고 Copilot과

dol9.tistory.com

원래 아는 걸 실행하는 게 어렵다.

그래서 실행 할 때는 아무 생각 없이 할 수 있도록 준비하는 게 좋은데

단순하면서 꽤나 효과적이라고 생각하는게 금방 완료 가능한 할 일들을 체크리스트로 만들어 하나씩 완성해 나가는 것이다.

이 글은 체크리스트를 만들기 위해 정리가 목적이다.

https://www.daytona.io/dotfiles/how-to-write-4000-stars-github-readme-for-your-project

How to Write A 4000 Stars GitHub README for Your Project

Guide on How We Created a GitHub Project README that Propelled Our Open Source Project to 4k Stars

www.daytona.io

프로젝트에서 README는 가장 중요하다.

처음 방문한 사용자가 스타를 누를지, 사용자가 될지, 기여자가 될 지 아니면 브라우저 탭을 닫을지 결정하는데 큰 영향을 끼친다.

HEADING

1. 로고 만들기

간과하기 쉬운데 첫줄에 로고가 있으면 깊은 인상을 준다.

2. 신뢰를 줄 수 있는 배지

프로젝트의 테스트 커버리지나 활성화 등 사용자에게 프로젝트의 건강함을 어필할 수 있다.

3. 프로젝트를 잘 표현하는 캐치프레이즈

프로젝트를 잘 표현하는 한 줄로 시작하고 다음 줄에 추가 설명을 진행하면 좋다.

사람들의 관심을 끄는데 매우 중요하다.

4. 이미지나 애니메이션 같은 시각화

글만 있는것보다 시각화 자료가 함께 있다면 더욱 좋다.

5. 기능 소개

지금까지 사람들의 관심을 끌었으니 프로젝트에서 매력적인 기능을 나열한다.

다른 프로젝트와 차별되는 고유한 가치를 강조해서 사용자가 관심을 넘어 호기심을 갖도록 한다.

6. QuickStart

최소한의 명령어로 프로젝트를 활용할수 있는 방법을 보여준다.

BODY

1. Why

여기까지 읽은 사용자의 관점으로 프로젝트에 참여해야 하는 이유를 명확하게 설명한다.

그들의 필요와 문제를 해결해줌으로써 관계 구축에 도움이 된다.

2. 배경설명

대부분의 프로젝트가 없지만 배경설명 적는 걸 추천한다.

당신이 프로젝트를 시작하게된 동기와 여정들을 공유하면, 독자가 더욱 공감 가고 기억에 남게 해 준다.

3. Getting Started

QuickStart의 확장버전이다.

프로젝트의 기능들을 종합적으로 설명을 해준다.

4. 간결하게 유지

불필요하게 README 파일이 길어지면 사용자는 프로젝트가 복잡하다고 느낄 수 있으므로 간결하게 유지한다.

프로젝트의 건강함(??)

사람들의 관심도 중요하지만 오픈소스가 지속하는 데는 프로젝트의 건강함에 달려있다.

1. Contributing

잘 작성된 기여 가이드는 컨드리뷰터들이 모범사례를 따라 유용한 문제를 작성할 수 있고,

표준화된 P/R을 제출할 수 있어 관리자가 프로젝트 관리를 쉽게 해 준다.

2. 라이선스

프로젝트의 라이선스 명확히 명시하여 지적 재산권과 권리 모두를 보호한다.

3. 행동강령

프로젝트가 커뮤니티와 어떻게 소통하고 사용할 것인지를 정의하고 컨드리뷰터들의 기대치를 설정한다.

4. 소통하는 채널 만들기

사용자가 도움을 요청하거나 문제 리포트, 또는 피드백을 제공할 공간을 명확하게 명시한다.

정리

앞에서 소개한 모든 항목들이 프로젝트에 가치를 더하는지 확인을 한다.

파일이 커지면 세부항목을 별도의 문서 폴더의 README 파일을 만들어 참조하는 것도 방법이다.

링크가 깨지거나 빈 README가 있는지 확인하고 깔끔하게 유지시킨다.

오픈소스 만들어 Github에 올릴 때 하면 좋은 체크리스트 .. (1)

오산돌구 — Fri, 23 May 2025 17:00:40 +0900

아직은 진행중이라 Private으로 진행하고 있지만 간단한 오픈소스를 만들어 공개해보려고 한다.

외부 OpenAPI를 호출하는 아주 단순하고 목적이 명확한 클라이언트다.

기능이야 문서 보고 Copilot과 함께 조금씩 개선하면 되는데

공개하는데 비슷한 생각을 가진 사람과 이런저런 얘기하고 만들어가면

재밌을 것 같아서 오픈소스 관련 내용을 찾아봤다.

여러개 찾았는데 그중 내가 필요한 내용들을 정리했다.

https://github.blog/enterprise-software/collaboration/a-checklist-and-guide-to-get-your-repository-collaboration-ready/

A checklist and guide to get your repository collaboration-ready

In the world of software development, collaboration can make the difference between a brittle last-minute release and a reliable, maintainable, pain-free project. Whether you’ve been coding for a day or a decade, your colleagues are there to help strengt

github.blog

오픈소스 만든 메인테이너의 가장 중요한 책임은 다른 사람들이 본인의 프로젝트를

적절하게 사용하고, 이해하고, 기여할 수 있도록 하는 것이다.

이런 미션을 지원하기 위해 Github이 있다. Github 기능들을 소개한다.

1. Repository settings

Visibility

Repository -> Settings 탭에서 수정할 수 있다.

Public

누구나 접근할 수 있고 코드를 로컬에 다운로드할 수 있고 이슈를 만들고 P/R을 보낼 수 있다.

불특정 다수로부터 기능이 잘 동작하는지 피드백을 받을 수 있고 다양한 개선 방법도 들을 수 있다.

보안 정보가 없는 개인프로젝트에 적합하고 회사 프로젝트에는 적합하지 않다.

Internal

Github Enterprise에서 사용 가능한 Visibility 옵션이다.

조직 내부 누구나 접근 가능하지만 외부에서는 접근할 수 없다.

민감한 정보가 없는 회사 프로젝트에 어울린다.

Private

가장 제한적인 옵션이다. 초대한 사람만 접근 가능하다.

Collaborators

특정 개인이나 조직을 프로젝트에 초대하는 옵션이다.

읽기 전용, P/R과 커밋 또는 Admin 같은 역할을 부여할 수 있다.

Private과 차이점은 초대 이후 역할을 부여할 수 있다는 점이다.

Protect the main branch

Repository rule을 이용하여 main branch에 바로 commit 하는 것을 막을 수 있다. (다양한 기능 존재)

최소 한 명 이상의 승인을 받아야 한다면 `CODEOWNERS` 파일을 이용한다.

추가로 P/R 마다 unit test 같은 자동화된 실행이 필요하다면 status checks를 이용한다.

2. Repository contents

소프트웨어 프로젝트는 코드 작성만 포함된 게 아니다.

이 프로젝트가 왜 만들어졌는지, 잘 사용하는 방법, 기여하는 방법 등
협력자와의 가이드 역할도 해야 한다.

README.md

해당 repository를 방문한 사람이 가장 처음 보는 파일이다.

프로젝트의 기능과 어떻게 설정하고 사용하는지 적혀있어야 한다.

LICENSE.md

해당 repository에 있는 코드와 콘텐츠에 대해 다른 사람들이 할 수 있는 것과 할 수 없는 것이 정의되어 있다.

프로젝트에 가장 적합한 라이선스에 대한 지침은 choosealicense.com에서 확인하고 repository에 라이선스를 추가하자.

CONTRIBUTING.md

해당 파일에 프로젝트에 새로운 코드, 문서 등 기여하는 방법과 이유를 명확하게 적어서

잠재적 기여자가 직면할 혼란과 마찰을 줄인다.

짧은 경우 README에 적어도 상관없지만 두 문단 이상인 경우 파일 분리하는 걸 추천한다.

분리된 파일에는 메인테이너가 원하는 기여 유형, 새로운 기능과 버그 수정 제안 방법,

P/R 제출 과정, 그리고 코딩 표준과 스타일 가이드라인에 대한 정보가 포함되어야 한다.

GitHub docs 프로젝트를 참고 (지금은 지워졌다. 필요 없을지도??)

CODEOWNERS

전체 또는 파일 확장자나 폴더 별로 1명 이상의 코드 책임자를 지정할 수 있다.

P/R이 생성되면 수정된 코드에 대해 자동으로 리뷰어 할당이 된다.

"·. md" 확장자가 있으면 안 된다.

CODE_OF_CONDUCT.md

프로젝트 참여자가 따라야 할 사회적 규범과 규칙, 책임을 설정한다.

이러한 파일은 사람들이 저장소에 훨씬 더 쉽게 접근할 수 있고, 이해가 쉬워지며,

기여하는 게 더 자연스럽게 흐르는 걸 볼 수 있다.

3. Automation and checks

Never send a human to do a machine's job

Linting

Linters는 다양한 에러를 감지하고 일관된 코드 스타일을 유지하기 위해 코드를 분석하는 도구다.

Super-Linter

Building and testing

프로젝트에서 사용하는 언어와 프레임워크에 따라 다르겠지만 대부분의 repository에서 자동으로 실행 가능하다.

Github Workflow 마켓플레이스에서 build, Test App & Actions 검색해서

본인 repository에 맞는 도구를 찾자.

Checks

앞에서 말한 자동화된 도구(Linter, 빌드, 테스트)를 추가하면 실패하는 경우 배포하는 걸 막을 수도 있다.

status checks를 구성해서 앱이 제대로 테스트하는지 확인하는데 도움 된다.

이런 자동화 도구와 status checks를 통해 repository 기여의 품질과 일관성의 신뢰를 높이고

자동 실행되기 때문에 관리하는데 더 적은 시간을 사용한다.

4. Security

Roles

협력자에게 역할과 권한 주는 걸 결정할 때는 신중해야 한다.

Writer는 신뢰하는 개인을 위한 것이다.

Admin은 제품 방향을 관리하고 검토하는 핵심 인물을 위한 것이다.

Secrets management

API keys나 비밀번호, 인증서 같이 비공개로 유지해야 할 예민한 데이터를 Secrets라고 한다.

코드라 로그에 직접 입력하면 안 되고,

third pary keystore나 GitHub의 secret-management 도구를 사용하면 된다.

Security scanners

대부분의 애플리케이션 코드 80~90%는 third pary 소스(프레임워크, 패키지)가 차지한다.

Dependabot은 공개 repository에서 사용할 수 있고, 모든 조직에서 자동으로 활성할 할 수 있다.

불안정한 third pary소스가 발견되면 알림을 주고 수정 방법을 제공한다.

Dependabot이 활성 중인지 확인하려면 repository의 보안탭을 확인한다.

5. Advanced options

Issue templates

버그 수정이나 개선사항에 대한 문의할 때 issue 기능을 사용하는데

기본적으로 구조화되지 않아 필요한 모든 정보를 알기 위해선 여러 번의 핑퐁이 필요하다.

하지만 issue templates를 만들어 가이드를 주면 필수와 옵션 정보를 입력받을 수 있어

이슈 생성부터 대부분의 정보를 알 수 있다.

6. Next steps

Responsiveness

메인테이너로서 당신의 응대는 해당 프로젝트가 건강하고 협력하는 환경을 만드는데 중요한 역할을 한다.

이슈와 P/R에 신속하게 대응하고 피드백을 주며, 새 기여자에게 가이드 주는 것까지 포함한다.

변경사항에 대응하고 문제 해결하는 전념할 별도 시간을 따로 설정하고 측정도 하면 좋다.

Project management

업무를 관리하고 진행상황을 시각화하기 위해 GitHub Project를 설정하면 좋다.

다른 사람들이 프로젝트의 상태를 이해하고 기여할 수 있는 부분을 확인하는데 좋다.

Visibility

앞에 소개한 방법들을 적용해서 잘 관리는 됐지만 아무도 알지 못하면 쓸모가 없다.

블로그 포스트나 데모, 프로젝트 랜딩 페이지 등을 통해 프로젝트를 홍보하자.

많은 사람들이 프로젝트 존재에 대해 알수록 더 많은 잠재적 기여자와 사용자를 유치할 수 있다.

Community engagement

커뮤니티와 소통하는 것은 건강하고 협력하는 환경을 만드는데 중요하다.

체크리스트를 출력하여 GitHub repository를 생성하거나 수정하

Issue Template 활용해서 개선하자!!

Valkey 8에 반영된 개선사항 - multi thread

오산돌구 — Sun, 18 May 2025 17:29:27 +0900

지난 글에서 new hash table을 보면서 많은 수정이 있다고 느꼈는데 이번에 볼 multi thread도 많은 수정이 있다.

https://dol9.tistory.com/336

Valkey 8에 반영된 개선사항 - new hash table

작년 3월, Redis는 기존 BSD 라이선스에서 Redis Source Available License (RSALv2)과Server Side Public License (SSPLv1) 듀얼 라이센스를 적용했다.https://redis.io/blog/redis-adopts-dual-source-available-licensing/ 개인 사용자나 Re

dol9.tistory.com

Redis는 single thread다 -> single thread니까 분산락하면 Redis지!! 라는 생각의 흐름이였는데 multi thread??

성능 개선의 비교군인 Valkey 7.2에서는 어떻게 처리했는지 알아보고 Valkey 8에선 multi thread를 어떻게 적용했는지 알아본다.

7.2 이해하는데 시간이 꽤 오래걸렸지만 나름 파악이 된 상태에서 8을 보니 금방 이해가 됐다.

※ Valkey 7.2에 설명 중 틀리거나 보완이 필요한거 알려주시면 감사하겠습니다.

Valkey 7.2 single thread

rdb, aof 같은 별도의 스레드는 차치하더라도

알아보니 클라이언트의 모든 요청을 정말 single thread로 처리하는 게 아니라

node.js 처럼 IO Multiplexing 기술을 이용해서 여러 IO 연산을 single thread로 동시에 처리하는 거였다.

※ 지금까지 잘못 알고 있었네... (코 쓱..)

Valkey 7.2 코드를 보기 전에 Multiplexing 개념을 알면 좋을 것 같다.. 찍먹 해보자

IO Multiplexing

아래 두 글에서 Multiplexing 개념과 실제 코드까지 설명이 너무 잘 됐는데 내가 부족해서 온전히 이해를 못 하겠다. ㅜ,ㅜ

https://blog.naver.com/n_cloudplatform/222189669084

https://blog.naver.com/n_cloudplatform/222255261317

[네이버클라우드 기술&경험] IO Multiplexing (IO 멀티플렉싱) 기본 개념부터 심화까지 -2부-

I/O Multiplexing (IO 멀티플렉싱) *톺아보기 포스팅! *톺아보다 : 샅샅이 더듬어 뒤지면서 찾아보다....

blog.naver.com

대강 느낌적으로 정리해 보면

Everything is a File

OS 입장에서는 일반 파일뿐 아니라 socket, 터미널, 파이프, 디바이스 모두 File Descriptor(이하 fd) 중 하나로 취급한다.

fd는 표준입력(0), 표준 출력(1), 표준 에러(2) 총 3가지 종류가 있다.

Multiplexing은 여러 fd를 하나의 프로세스가 관리하는 기술이고

이 fd를 어떤 상태로 대기하냐에 따라서
리눅스는 select, poll, epoll. 맥은 kqueue, 윈도우는 iocp 등 다양한 기법이 있다.

Multiplexing은 Asynchronous Blocking I/O라고 한다.

Application에서 Kernel로 System call 하고 제어권은 Application에서 유지한 채 다른 작업을 한다.

이후 Kernel에서 작업이 완료되어 데이터가 준비되면 Kernel에서 Application으로 콜백 신호를 보내고

Application은 Kernel에 있던 데이터를 user 영역의 buffer로 복사하는 흐름이다.

https://developer.ibm.com/articles/l-async/

그래서 Valkey 7.2에서는 어떻게 동작한다고?

Valkey 7.2에서 클라이언트 요청을 어떻게 처리했는지 알아보자.

1. 서버가 시작되면 Server와 Listener가 초기화된다.

Server 초기화할 때는 File Event와 Timer Event를 만든다.
Listner 초기화할 때는 server listner에 accept 했을 때 실행할 AcceptHandler를 등록한다.

int main(int argc, char **argv) {
  ...
  initServer();
  ...
  initListeners();
  ...
  aeMain(server.el);
}

void initServer(void) {
  ...
  // event loop fd 생성
  server.el = aeCreateEventLoop(server.maxclients+CONFIG_FDSET_INCR);
  ...
  // 앞에서 만들어진 event loop fd에 timer event 추가
  if (aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
    serverPanic("Can't create event loop timers.");
    exit(1);
  }
  ...
}

void initListeners(void) {
    /* Setup listeners from server config for TCP/TLS/Unix */
    int conn_index;
    connListener *listener;
    if (server.port != 0) {
        conn_index = connectionIndexByType(CONN_TYPE_SOCKET);
        if (conn_index < 0)
            serverPanic("Failed finding connection listener of %s", CONN_TYPE_SOCKET);
        listener = &server.listeners[conn_index];
        ...
        listener->port = server.port;
    }
    ...
    /* create all the configured listener, and add handler to start to accept */
    int listen_fds = 0;
    for (int j = 0; j < CONN_TYPE_MAX; j++) {
        ...
        if (createSocketAcceptHandler(listener, connAcceptHandler(listener->ct)) != C_OK)
            serverPanic("Unrecoverable error creating %s listener accept handler.", listener->ct->get_type(NULL));

       listen_fds += listener->count;
    }
}

우선 initServer 함수에서 생성되는 이벤트만 알아보자. (File Event, Fired Event, Time Event)

읽기와 쓰기 그리고 BARRIER 중 하나로 마스킹 된 server.maxclients+CONFIG_FDSET_INCR 개의 File Event 풀을 만든다.

epoll 기준, epoll_wait로 처리할 이벤트를 받아 실행할 File Event 정보를 마스킹과 fd를 보관하는 Fired Event 풀을 만든다.

마지막으로 Time Event는 양방향 리스트로 만들어져 있고 id와 시간을 갖고 있고 trigger 될 때 실행할 timeProc가 있다.

2. initListners에서 AcceptHandler는 어떻게 처리될까?

아래 글에서 소켓 리스너부터 EventLoop가 어떻게 처리되는지 잘 설명되어 있다.

Redis가 싱글 스레드 모델임에도 높은 성능을 보장하는 이유

Redis가 싱글 스레드 모델임에도 높은 성능을 보장하는 이유 (I/O Multiplexing)

틀린 내용이 있을 수 있어 피드백 해주시면 감사하겠습니다 Redis는 Remote Dictionary Server이며, Dictionary, Set 등과 같은 메모리 내 자료구조를 제공하는 TCP 서버이다. Redis는 캐싱, 세션 저장소, 실

velog.io

1번에서 봤듯이 initListners 함수 안에서 클라이언트가 접속하면 실행할 acceptHandler 함수를 붙인다.

if (createSocketAcceptHandler(listener, connAcceptHandler(listener->ct)) != C_OK)

createSocketAcceptHandler 함수는 listener fd를 read 형태의 File Event로 Multiplexing에 등록한다.

int createSocketAcceptHandler(connListener *sfd, aeFileProc *accept_handler) {
  int j;

  for (j = 0; j < sfd->count; j++) {
    if (aeCreateFileEvent(server.el, sfd->fd[j], AE_READABLE, accept_handler,sfd) == AE_ERR) {
      /* Rollback */
      ...   
    }
  }
  return C_OK;
}

클라이언트가 접속하면 아래 흐름으로 accept_handler가 실행된다.

1. 서버 main 함수에서 while loop를 돌면서 aeProcessEvents를 실행하는 aeMain을 실행한다.

2. aeProcessEvents함수는 aeApiPoll를 실행해 발생한 이벤트 목록을 받는다.

2-1. aeApiPoll이 하는 일은 epoll, kqueue 등 기술에 맞게(?) waiting 후 이벤트 목록을 받으면

Fired Event에 마스킹 정보와 fd 정보를 저장한다.

3. 마스킹이 read인지 write인지에 따라 분기가 있어 알맞은 함수를 실행한다.

accept_handler을 타고 가다 보면 networking.c -> acceptCommonHandler에서

createClient 함수를 호출해 클라이언트 구조체를 초기화한다.

이때 클라이언트의 요청받는 handler를 설정해 준다.

※ 응답 쓰는 건 writeToClient를 직접 호출한다.

왼쪽 위부터 시계방향으로 진행

1. connection을 맺으면 reader handler를 설정해 주는데 readQueryFromClient 함수다.

2. connection type에 reader_handler 함수를 실행한다.

3. connection fd를 aeCreateFileEvent에 등록하는데 이벤트가 발생하면 ae_handler를 실행하도록 설정했다.

4. ae_handler는 connSocketEventHandler 함수인데 결국 마스킹값에 따라 분기처리된다.
5. readQueryFromClient를 실행하는데 이 함수는 클라이언트로부터 명령어를 읽어 실행하는 역할을 한다.

3. 클라이언트 요청은 이것이 끝이 아니었다.

데이터 구조와 ttl 정도만 살펴봤지 이 정도로 클라이언트 처리 과정을 본 건 처음이었다.

2번 정도 했으면 다 봤겠지 했는데 웬걸... 별도의 pthread가 돌고 있었다. :wow:

앞에서 살펴본 aeProcessEvents에서 aeApiPoll을 실행하기 전에 beforeSleep 함수를 실행하는데
이때 지연된 read, write 요청을 IO 스레드를 이용해서 처리하는 로직이 있다. networking.c -> IOThreadMain

fan-out -> fan-in을 이용해 스레드 세이프하게 처리한다.

Main Thread가 0보다 큰 값으로 setIOPendingCount를 호출하면서 IO Thread fan-out

Main Thread가 getIOPendingCount를 주기적으로 호출하면서 0이 될 때까지 기다리다가 0이 되면 Main Thread fan-in

3. File Event & Filred Event

위에서 클라이언트 흐름을 설명하면서 File Event 처리도 함께 설명했지만 정리하면 다음과 같다.

굉장히 단순화했지만 뭐.. 느낌 있으니까..ㅋㅋㅋ

4. Time Event

initServer 함수에서 Time Event 초기화 부분을 알아보자.

if (aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
  serverPanic("Can't create event loop timers.");
  exit(1);
}

// eventLoop에 Time Event head세팅! 실행하는 함수는 serverCron
long long aeCreateTimeEvent(aeEventLoop *eventLoop, long long milliseconds,
        aeTimeProc *proc, void *clientData,
        aeEventFinalizerProc *finalizerProc)
{
    long long id = eventLoop->timeEventNextId++;
    aeTimeEvent *te;

    te = zmalloc(sizeof(*te));
    if (te == NULL) return AE_ERR;
    te->id = id;
    te->when = getMonotonicUs() + milliseconds * 1000;
    te->timeProc = proc;
    te->finalizerProc = finalizerProc;
    te->clientData = clientData;
    te->prev = NULL;
    te->next = eventLoop->timeEventHead;
    te->refcount = 0;
    if (te->next)
        te->next->prev = te;
    eventLoop->timeEventHead = te;
    return id;
}

aeProcessEvents 마지막 즈음에 Time Event 실행하는 함수가 있다.

Time Event에 설정한 시간보다 현재시간이 과거면 timeProc(serverCron)를 실행한다.

AE_NOMORE은 -1인데 serverCron은 `1000/server.hz;` 를 리턴하기 때문에 -1이 나올 수 없다.

즉 serverCron 실행 후 삭제하지 않고 when 값을 now + retval*1000로 수정한다.

이런 느낌

7.2에서 File Event와 Time Event가 어떻게 실행되는지 알아봤고
File Event를 이용해서 Valkey가 listner와 client event가 어떻게 실행되는지 알아봤다.

pending 요청을 별도의 thread가 처리하긴 하지만 대부분의 일을 Main Thread가 한다.

Redis EventLoop에 디버깅으로 자세하게 소개한 글

Valkey 8에 적용된 multi thread

Valkey 블로그에 소개된 multi thread 그림이다.

7.2에서 pending read/write 요청을 fan-out, fan-in 방식으로 IO Thread로 처리하는 건 알았는데

아래 그림은 뭔가 peding 구분 없이 IO Thread에서 많은것들을 처리하는 걸로 보인다.

먼저 블로그에서 설명한 글을 정리하고 코드를 살펴보자.

https://valkey.io/blog/unlock-one-million-rps/

Valkey 블로그 글 정리

IO Thread가 하는 작업에는

1. 클라이언트의 명령을 읽어 구문 분석하거나

2. 클라이언트에게 응답을 다시 작성하거나

3. TCP 연결에서 I/O 이벤트를 폴링 하거나

4. 메모리 할당을 해제하는 작업이 포함된다.

IO Thread는 I/O 처리하느라 바쁘지만 Main Thread는 실제 명령을 실행하는 데 더 많은 시간을 할애한다.

코드 살펴보기

1. IO Job을 ring buffer 형태로 만들어 data와 함께 job_handler 실행하도록 만들었다.

io_jobs 256개를 만들고

io_jobs 하나당 2048개의 ringbuffer를 만들었다. 와우!!

총 256*2048= 524,288 개

#define IO_THREADS_MAX_NUM 256

static pthread_t io_threads[IO_THREADS_MAX_NUM] = {0};
static pthread_mutex_t io_threads_mutex[IO_THREADS_MAX_NUM];

/* IO jobs queue functions - Used to send jobs from the main-thread to the IO thread. */
typedef void (*job_handler)(void *);
typedef struct iojob {
    job_handler handler;
    void *data;
} iojob;

typedef struct IOJobQueue {
    iojob *ring_buffer;
    size_t size;
    _Atomic size_t head __attribute__((aligned(CACHE_LINE_SIZE))); /* Next write index for producer (main-thread) */
    _Atomic size_t tail __attribute__((aligned(CACHE_LINE_SIZE))); /* Next read index for consumer  (IO-thread) */
} IOJobQueue;
IOJobQueue io_jobs[IO_THREADS_MAX_NUM] = {0};

IOJobQueue에 Job을 추가하는 `IOJobQueue_push` 함수를 어디서 호출하는지 알면 파악이 될 것 같다.

2. `IOJobQueue_push` 함수를 실행하는 곳을 찾아서..

io_threads.c에서 IOJobQueue_push 호출하는 곳을 찾아봤다.

1. client의 요청 읽을 때

2. client에 응답 쓸 때

3. client 해제할 때

4. 이미 존재하는 key의 value를 덮어쓰는 경우 기존 value 해제할 때

5. beforeSleep 할 때 이벤트 목록을 가져오는 aePollApi 호출

6. TLS 한정 Accept도 IO thread로 처리

1. client의 요청 읽을 때

void readQueryFromClient(connection *conn) {
  ...
  if (postponeClientRead(c)) return;
}


// Valkey 7.2
int postponeClientRead(client *c) {
    if (server.io_threads_active &&
        server.io_threads_do_reads &&
        !ProcessingEventsWhileBlocked &&
        !(c->flags & (CLIENT_MASTER|CLIENT_SLAVE|CLIENT_BLOCKED)) &&
        io_threads_op == IO_THREADS_OP_IDLE)
    {
        listAddNodeHead(server.clients_pending_read,c);
        c->pending_read_list_node = listFirst(server.clients_pending_read);
        return 1;
    } else {
        return 0;
    }
}


// Valkey 8.1
int postponeClientRead(client *c) {
  if (ProcessingEventsWhileBlocked) return 0;

  // IOJobQueue에 push	
  return (trySendReadToIOThreads(c) == C_OK);
}

2. client에 응답 쓸 때

// Valkey 7.2
void sendReplyToClient(connection *conn) {
    client *c = connGetPrivateData(conn);
    writeToClient(c,1);
}

// Valkey 8.1
void sendReplyToClient(connection *conn) {
    client *c = connGetPrivateData(conn);
    if (trySendWriteToIOThreads(c) == C_OK) return;
    writeToClient(c);
}

3. client 해제할 때

// Valkey 7.2
void freeClientArgv(client *c) {
    int j;
    for (j = 0; j < c->argc; j++)
        decrRefCount(c->argv[j]);
    c->argc = 0;
    c->cmd = NULL;
    c->argv_len_sum = 0;
    c->argv_len = 0;
    zfree(c->argv);
    c->argv = NULL;
}


// Valkey 8.1
void freeClientArgv(client *c) {
    /* If original_argv exists, 'c->argv' was allocated by the main thread,
     * so it's more efficient to free it directly here rather than offloading to IO threads */
    if (c->original_argv || tryOffloadFreeArgvToIOThreads(c, c->argc, c->argv) == C_ERR) {
        for (int j = 0; j < c->argc; j++) decrRefCount(c->argv[j]);
        zfree(c->argv);
    }
    c->argc = 0;
    c->cmd = NULL;
    c->io_parsed_cmd = NULL;
    c->argv_len_sum = 0;
    c->argv_len = 0;
    c->argv = NULL;
}

4. 이미 존재하는 key의 value를 덮어쓰는 경우 기존 value 해제할 때

// Valkey 7.2
static void dbSetValue(...) {
  if (server.lazyfree_lazy_server_del) {
    freeObjAsync(key,old,db->id);
  } else {
  /* This is just decrRefCount(old); */
    db->dict->type->valDestructor(db->dict, old);
  }
}

// Valkey 8.1
static void dbSetValue(...) {
  /* For efficiency, let the I/O thread that allocated an object also deallocate it. */
  if (tryOffloadFreeObjToIOThreads(old) == C_OK) {
    /* OK */
  } else if (server.lazyfree_lazy_server_del) {
    freeObjAsync(key, old, db->id);
  } else {
    decrRefCount(old);
  }
  *valref = new;
}

5. beforeSleep 할 때 이벤트 목록을 가져오는 aePollApi 호출

// Valkey 8에 추가

void beforeSleep(struct aeEventLoop *eventLoop) {
  /* When I/O threads are enabled and there are pending I/O jobs, the poll is offloaded to one of the I/O threads. */
  trySendPollJobToIOThreads();
  ...
}


void trySendPollJobToIOThreads(void) {
  ...
  IOJobQueue_push(jq, IOThreadPoll, server.el);
}

void IOThreadPoll(void *data) {
  aeEventLoop *el = (aeEventLoop *)data;
  struct timeval tvp = {0, 0};
  int num_events = aePoll(el, &tvp);

  server.io_ae_fired_events = num_events;
  atomic_store_explicit(&server.io_poll_state, AE_IO_STATE_DONE, memory_order_release);
}

int aePoll(aeEventLoop *eventLoop, struct timeval *tvp) {
  AE_LOCK(eventLoop);

  int ret = aeApiPoll(eventLoop, tvp);

  AE_UNLOCK(eventLoop);
  return ret;
}

6. TLS 한정 Accept도 IO thread로 처리

// Valkey 8.1

static int connTLSAccept(connection *_conn, ConnectionCallbackFunc accept_handler) {
  ...
  /* Try to offload accept to IO threads */
  if (trySendAcceptToIOThreads(_conn) == C_OK) return C_OK;
}

int trySendAcceptToIOThreads(connection *conn) {
  ...
  IOJobQueue_push(job_queue, ioThreadAccept, c);
}

static void ioThreadAccept(void *data) {
  client *c = (client *)data;
  connAccept(c->conn, NULL);
  c->io_read_state = CLIENT_COMPLETED_IO;
}

multi thread라고 했지만 실제 명령어 실행은 Main Thread에서 진행하고

IO 작업이나 epoll_wait 같은 대기작업들을 IO Thread가 처리하면서 Transaction 기능은 온전히 유지되는 것 같다.

자료 찾다 보니 Redis 8도 보게 되었는데 뭔가 비슷한 느낌이 물씬 난다.

어라? Redis 8도 비슷하게 적용했나 보네..

https://riferrei.com/the-engineering-wisdom-behind-rediss-single-threaded-design/

The Engineering Wisdom Behind Redis’s Single-Threaded Design – Ricardo Ferreira

In the relentless pursuit of performance, our industry often gravitates toward seemingly obvious solutions: more cores, more threads, more concurrency. Yet Redis—one of the most performant databases in the world—has maintained its commitment to a prima

riferrei.com

앞으로 어떻게 될진 모르겠지만 선의의(?) 경쟁은 좋다.

Valkey 8에 반영된 개선사항 - new hash table

오산돌구 — Sun, 4 May 2025 22:23:27 +0900

작년 3월, Redis는 기존 BSD 라이선스에서 Redis Source Available License (RSALv2)과
Server Side Public License (SSPLv1) 듀얼 라이센스를 적용했다.

https://redis.io/blog/redis-adopts-dual-source-available-licensing/

https://github.com/redis/redis/pull/13157

개인 사용자나 Redis를 이용한 라이브러리들은 영향 없지만

AWS, Azure, GCP 같은 클라우드 업체에서 라이선스 버전 이후의 Redis는 서비스 제공이 어렵게 된 거다.

그러자 라이센스 반발로 만들어진 Redis 포크 프로젝트 Valkey를 많은 대기업들이 지원하기로 했다.

그저 개인의 치기 어린 포크 프로젝트가 아니다.

https://news.hada.io/topic?id=14436

1년이 지난 지금,

antirez가 복귀하고 VectorSet 데이터 타입이 추가되고, Redis에 AGPL 라이선스도 추가했지만 딱히 끌리지 않는다.
※ antirez 옹 미안해요..

올 초부터 Valkey에서 달라진 점들을 알고 싶었는데, 이번 기회에 알아보고자 한다.

https://valkey.io/blog/ 내용 중 Valkey 8 글들을 Google NotebookLM에 던져놓고 알아보기 시작했다.

자료를 요약해 주고 정리도 해줘서 시작하는 허들은 낮출 수 있었지만 결국 내 걸로 만들려면 많은 시간과 노력은 필요했다.

Valkey 8에 적용된 개선 내용

new hash table
dictionary per slot
key embedding
multi-threaded architecture
specific command/data type optimizations

이번글에서는 Valkey 8.1에 반영된 새로운 hash table을 알아본다.

https://valkey.io/blog/new-hash-table/

Valkey · A new hash table

Viktor is an open source developer from Ericsson and one of the maintainers of Valkey.

valkey.io

결론부터 말하면 새로운 hash table 구조는

key-value 하나당 약 20 byte를 아끼고, TTL이 적용된 key-value는 약 30 byte를 아낀다고 한다.

와우!!!!!

새로운 hash table을 알아보기 전에 기존 구조를 알아보자.

Valkey 7.2 Hash Table

오래전에 파악한 내용이 있어 다시 봤는데 음... 다시 정리해 보자.

Dict

Dict는 다양한 자료구조를 담는 기본적인 redis의 자료구조입니다. key, value형식으로 되어있고 value에 사용자가 입력한 자료구조(?)들이 들어가게 되죠출처 : http://en.wikipedia.org/wiki/File:Hash_table_5_0_1_1

dol9.tistory.com

Valkey 7.2에서 dict 구조를 살펴보면 아래와 같다.

특정 조건(해시충돌, 키 사용량 등)을 기준으로 bucket 수를 늘리기 위한 rehash를 목적으로 dictEntry **ht_table[2]가 있다.

rehash가 발생하지 않을 때는 ht_table[0]에서 조회/추가/삭제를 하지만,

rehash 중일 때는 추가는 ht_table[1]만, 조회, 삭제는 ht_table[0]과 ht_table[1] 두 곳에 진행한다.

위 구조에 "FOO" -> "BAR" key-value 쌍으로 저장된 상태에서

조회를 하려고 $ get FOO 를 실행하면 메모리 접근은 4번 일어난다.

1. ht_table[0][hash_function("FOO")%hash_size]

2. ht_table[0][hash_function("FOO")%hash_size] -> key

3. ht_table[0][hash_function("FOO")%hash_size] -> val

4. ht_table[0][hash_function("FOO")%hash_size] -> val -> ptr

그리고 주소 정보를 담고 있는 포인터는 공짜가 아니다. 64bit OS 기준 8 byte다.

Valkey 8.1 Hash Table

아예 새로운 프로젝트다. 새롭게 보이는 kvstore, hashtable 파일에 블로그에 쓰인 디자인들이 구현되어 있다.

코드 주석에 쓰여있는 친절한 설명과 Copilot의 /explain 기능, 그리고 상상력을 더해 알아보자.

새로운 Hash Table의 흐름은 다음과 같다.

1. kvstore와 hashtable 조합으로 기존 dict를 교체했다.

서버가 뜰 때 관리하는 DB 구조체가 있는데(7.2 redisDb, 8.1 serverDb)
가장 중요한 dict와 expires key-value를 dict에서 kvstore + hashtable로 바뀌었다.

※ dict 변수명을 keys로 바꾼 것 나이스!!

kvstore 없이 바로 hashtable만 써도 될 것 같은데 뭔가 이유가 있겠지.. 하며 다음을 기약한다.

// Valkey 7.2
/* Redis database representation. There are multiple databases identified
 * by integers from 0 (the default database) up to the max configured
 * database. The database number is the 'id' field in the structure. */
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP)*/
    dict *blocking_keys_unblock_on_nokey;   /* Keys with clients waiting for
                                             * data, and should be unblocked if key is deleted (XREADEDGROUP).
                                             * This is a subset of blocking_keys*/
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
    unsigned long expires_cursor; /* Cursor of the active expire cycle. */
    list *defrag_later;         /* List of key names to attempt to defrag one by one, gradually. */
    clusterSlotToKeyMapping *slots_to_keys; /* Array of slots to keys. Only used in cluster mode (db 0). */
} redisDb;

struct dict {
    dictType *type;

    dictEntry **ht_table[2];
    unsigned long ht_used[2];

    long rehashidx; /* rehashing not in progress if rehashidx == -1 */

    /* Keep small vars at end for optimal (minimal) struct padding */
    int16_t pauserehash; /* If >0 rehashing is paused (<0 indicates coding error) */
    signed char ht_size_exp[2]; /* exponent of size. (size = 1<<exp) */

    void *metadata[];           /* An arbitrary number of bytes (starting at a
                                 * pointer-aligned address) of size as defined
                                 * by dictType's dictEntryBytes. */
};



// Valkey 8.1
/* Database representation. There are multiple databases identified
 * by integers from 0 (the default database) up to the max configured
 * database. The database number is the 'id' field in the structure. */
typedef struct serverDb {
    kvstore *keys;                        /* The keyspace for this DB */
    kvstore *expires;                     /* Timeout of keys with a timeout set */
    dict *blocking_keys;                  /* Keys with clients waiting for data (BLPOP)*/
    dict *blocking_keys_unblock_on_nokey; /* Keys with clients waiting for
                                           * data, and should be unblocked if key is deleted (XREADEDGROUP).
                                           * This is a subset of blocking_keys*/
    dict *ready_keys;                     /* Blocked keys that received a PUSH */
    dict *watched_keys;                   /* WATCHED keys for MULTI/EXEC CAS */
    int id;                               /* Database ID */
    long long avg_ttl;                    /* Average TTL, just for stats */
    unsigned long expires_cursor;         /* Cursor of the active expire cycle. */
} serverDb;

struct _kvstore {
    int flags;
    hashtableType *dtype;
    hashtable **hashtables;
    int num_hashtables;
    int num_hashtables_bits;
    list *rehashing;                          /* List of hash tables in this kvstore that are currently rehashing. */
    int resize_cursor;                        /* Cron job uses this cursor to gradually resize hash tables (only used if num_hashtables > 1). */
    int allocated_hashtables;                 /* The number of allocated hashtables. */
    int non_empty_hashtables;                 /* The number of non-empty hashtables. */
    unsigned long long key_count;             /* Total number of keys in this kvstore. */
    unsigned long long bucket_count;          /* Total number of buckets in this kvstore across hash tables. */
    unsigned long long *hashtable_size_index; /* Binary indexed tree (BIT) that describes cumulative key frequencies up until
                                               * given hashtable-index. */
    size_t overhead_hashtable_lut;            /* Overhead of all hashtables in bytes. */
    size_t overhead_hashtable_rehashing;      /* Overhead of hash tables rehashing in bytes. */
};

struct hashtable {
    hashtableType *type;
    ssize_t rehash_idx;        /* -1 = rehashing not in progress. */
    bucket *tables[2];         /* 0 = main table, 1 = rehashing target.  */
    size_t used[2];            /* Number of entries in each table. */
    int8_t bucket_exp[2];      /* Exponent for num buckets (num = 1 << exp). */
    int16_t pause_rehash;      /* Non-zero = rehashing is paused */
    int16_t pause_auto_shrink; /* Non-zero = automatic resizing disallowed. */
    size_t child_buckets[2];   /* Number of allocated child buckets. */
    void *metadata[];
};

2. 캐시라인에 맞춘 64 byte에 bucket을 만들었다.

캐시라인 설명을 위해 어렴풋하게 알고 있는 프로그램 실행 흐름을 얘기하면
작성한 파일을 메인 메모리에 올리고 명령어와 데이터를 CPU로 가져와서 실행한다고 알고 있다.

이때 CPU가 데이터를 빨리 가져오기 위해 CPU 캐시가 존재하는데

캐시 라인은 CPU 캐시 메모리의 기본 데이터 전송 단위, 즉 캐시의 최소 단위 크기를 말하고

요즘 하드웨어는 64 바이트라고 한다.

이를 적극 활용하려고 Valkey 8.1에서는 bucket 크기를 64 바이트로 맞췄다.

bucket 크기를 64 byte로 bucket을 맞췄을 때 장점은 hash 충돌이 발생한 경우

CPU에서 추가 메모리 접근 없이 이미 CPU 캐시에 로드한 데이터에 다른 Entry 정보도 있기 때문에 빠른 탐색이 가능하다.

※ 값이 다른 key인데 hash 값이 같다면 동일한 bucket에 담겨 있을 테고 그럼 두 번째 Entry에 저장이 된다.

한 bucket은 8byte의 메타데이터와 8 byte Entry 7개로 구성되어 있다. (8 + 8*7 = 64)

메타 데이터는 1. chain 여부, 2. key 존재 여부, 3. Entry 7개의 key를 1 byte로 표현한 secondary hash로 구성되어 있다.

하나씩 알아보자.

3. bucket이 가득 찼을 땐 자식 bucket을 만들어 처리한다.

위에서 하나의 bucket에는 7개의 Entry가 존재한다고 했다.

그럼 7개 Entry가 있는 bucket에 Entry를 추가하면 어떤 일이 일어날까?

1. 새로운 Bucket을 만들고

2. 기존 Bucket의 일곱 번째 Entry를 새로운 Bucket 첫번째로 옮긴다.

3. 기존 Bucket 메타데이터 수정
bucket_from->chained = 1 그리고 bucket_from->presence &= ~(1 << pos_from)

3. 추가할 Entry는 새로운 bucket 두 번째 Entry에 추가해 준다.

4. 해당 bucket에 Entry 존재 여부는 bit로 먼저 판단한다.

해당 bucket의 데이터가 비었는지, 가득 찼는지, Entry에 데이터가 있는지 없는지를 판단할 때
7개 Entry를 직접 조회하지 않고 presence를 이용한다.

1이면 존재, 0이면 비어있다는 의미다.

앞에서 살펴본 Child bucket이 생성 됐는데 키가 삭제되면서 Child bucket이 비었거나
Entry 중간에 비어있다면 정리해 줄 때도 presence가 잘 쓰인다.

처음 보는 함수가 있어 살펴보니 gcc 빌트인 함수라고 한다. 오.. 득템
__builtin_popcount: parameter 값을 이진수로 나타냈을 때 1이 몇 개인지 카운트해 주는 함수다.

__builtin_ctz(count trailing zeros): parameter 값을 이진수로 나타냈을 때 LSB부터 왼쪽으로 이동하면서
0이 몇개인지 카운트해주는 함수다. 반대는 __builtin_clz(MSB부터 오른쪽으로 이동)

static void compactBucketChain(hashtable *ht, size_t bucket_index, int table_index) {
    bucket *b = &ht->tables[table_index][bucket_index];
    while (b->chained) {
        bucket *next = getChildBucket(b);
        // child bucket도 chained 타입이고 비어있다면 child bucket 삭제(포인트 바꾸고 메모리 해제)
        if (next->chained && next->presence == 0) {
            /* Empty bucket in the middle of the chain. Remove it from the chain. */
            bucket *next_next = getChildBucket(next);
            b->entries[ENTRIES_PER_BUCKET - 1] = next_next;
            zfree(next);
            if (ht->type->trackMemUsage) ht->type->trackMemUsage(ht, -sizeof(bucket));
            ht->child_buckets[table_index]--;
            continue;
        }

        // child bucket이 비어있고 chained 타입이 아니라면 삭제(prune)
        if (!next->chained && (next->presence == 0 || __builtin_popcount(next->presence) == 1)) {
            /* Next is the last bucket and it's empty or has only one entry.
             * Delete it and turn b into an "unchained" bucket. */
            pruneLastBucket(ht, b, next, table_index);
            return;
        }

        // 중간에 비어있는 Entry가 있다면 가장 마지막에 있는 child bucket의 Entry로 채움
        if (__builtin_popcount(b->presence) < ENTRIES_PER_BUCKET - 1) {
            /* Fill the holes in the bucket. */
            for (int pos = 0; pos < ENTRIES_PER_BUCKET - 1; pos++) {
                if (!isPositionFilled(b, pos)) {
                    fillBucketHole(ht, b, pos, table_index);
                    if (!b->chained) return;
                }
            }
        }

        /* Bucket is full. Move forward to next bucket. */
        b = next;
    }
}

5. 입력한 key가 몇 번째 Entry인지 secondary hash로 판단 후 Entry key값을 비교한다.

데이터 저장 할 때 key 값에 hash 함수를 적용해 64 비트로 만든 후
그중 상위 8비트를 highBit 함수로 구해서 hashes에 저장한다.

# <limits.h> 64 bit 8
#define CHAR_BIT  __CHAR_BIT__

/* For the hash bits stored in the bucket, we use the highest bits of the hash
 * value, since these are not used for selecting the bucket. */
static inline uint8_t highBits(uint64_t hash) {
    return hash >> (CHAR_BIT * 7);
}

/* Helper to insert an entry. Doesn't check if an entry with a matching key
 * already exists. This must be ensured by the caller. */
static void insert(hashtable *ht, uint64_t hash, void *entry) {
    ...
    bucket *b = findBucketForInsert(ht, hash, &pos_in_bucket, &table_index);
    b->entries[pos_in_bucket] = entry;
    b->presence |= (1 << pos_in_bucket);
    b->hashes[pos_in_bucket] = highBits(hash);
    ht->used[table_index]++;
}

그럼 나중에 해당 key를 조회하거나 삭제할 때 bucket에 있는 Entry key를 하나씩 꺼내고 비교하는 게 아니라

hash값에 상위 8비트와 hashes에 있는 값을 비교하고(isPositionFilled(b, pos) && b->hashes[pos] == h2)

매칭되면 실제 key를 비교하는 식이다. (compareKeys)

static bucket *findBucket(hashtable *ht, uint64_t hash, const void *key, int *pos_in_bucket, int *table_index) {
    if (hashtableSize(ht) == 0) return 0;
    uint8_t h2 = highBits(hash);
    int table;
    ...
    for (table = 0; table <= 1; table++) {
        ...
        do {
            /* Find candidate entries with presence flag set and matching h2 hash. */
            for (int pos = 0; pos < numBucketPositions(b); pos++) {
                if (isPositionFilled(b, pos) && b->hashes[pos] == h2) {
                    /* It's a candidate. */
                    void *entry = b->entries[pos];
                    const void *elem_key = entryGetKey(ht, entry);
                    if (compareKeys(ht, key, elem_key) == 0) {
                        /* It's a match. */
                        assert(pos_in_bucket != NULL);
                        *pos_in_bucket = pos;
                        if (table_index) *table_index = table;
                        return b;
                    }
                }
            }
            b = getChildBucket(b);
        } while (b != NULL);
    }
    return NULL;
}

진짜 비트 하나하나 알차게 쓰네...

6. 메모리를 아끼기 위해 embed type이 있는데 항상 적용되는 건 아니다.

8.1에서 메모리 접근 횟수 감소와 메모리 사용이 줄어든 이유는 serverObject에 포인터가 아닌 값을 직접 저장하고 있기 때문이다.

그럼 Valkey 8.1은 항상 embed type으로 저장이 될까? 아니다.

저장할 때 value 길이가 44 이하일 때 Embed String 타입으로 저장하고,

44 초과면 7.2에서 본것처럼 포인터로 저장한다.

/* Create a string object with EMBSTR encoding if it is smaller than
 * OBJ_ENCODING_EMBSTR_SIZE_LIMIT, otherwise the RAW encoding is
 * used.
 *
 * The current limit of 44 is chosen so that the biggest string object
 * we allocate as EMBSTR will still fit into the 64 byte arena of jemalloc. */
#define OBJ_ENCODING_EMBSTR_SIZE_LIMIT 44
robj *createStringObject(const char *ptr, size_t len) {
    if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT)
        return createEmbeddedStringObject(ptr, len);
    else
        return createRawStringObject(ptr, len);
}

serverObject에 key, value, expire 데이터가 embed 타입으로 어떻게 저장되는지 알아보자.
※ object.c의 `static robj *createEmbeddedStringObjectWithKeyAndExpire`

serverObject 구조체는 다음과 같다.

type + encoding + lru + hasexpire + hasembkey + refcount = 64 bit

64 bit 다음에 void* ptr이 존재한다.

구조체에 bit 필드 선언하는 방법과 구조체에서 마지막 void 포인터는 구조체 크기에 영향을 안 준다는 구글 AI 검색 내용.

크흐~~ 옛날에 고생하면서 찾았던 기억이 나면서 스샷 한번 ㅋㅋㅋ

static robj *createEmbeddedStringObjectWithKeyAndExpire(const char *val_ptr,
                                                        size_t val_len,
                                                        const sds key,
                                                        long long expire) {
    // 64 bit + value size + expire size(optional) + key size(optional)
    size_t min_size = sizeof(robj) + val_sds_size;
    if (expire != -1) {
        min_size += sizeof(long long);
    }
    if (has_embkey) {
        /* Size of embedded key, incl. 1 byte for prefixed sds hdr size. */
        min_size += 1 + key_sds_size;
    }

    /* 64 bit 알차게 값 할당 */
    size_t bufsize = 0;
    robj *o = zmalloc_usable(min_size, &bufsize);
    o->type = OBJ_STRING;
    o->encoding = OBJ_ENCODING_EMBSTR;
    o->refcount = 1;
    o->lru = 0;
    o->hasexpire = (expire != -1);
    o->hasembkey = has_embkey;


    /* embedded 데이터 설정을 위해 void포인터 크기 만큼(8 byte) 이동 */
    char *data = (void *)(o + 1);

    /* Set the expire field. */
    if (o->hasexpire) {
        *(long long *)data = expire;
        data += sizeof(long long);
    }

    /* Copy embedded key. */
    if (o->hasembkey) {
        *data++ = sdsHdrSize(key_sds_type);
        sdswrite(data, key_sds_size, key_sds_type, key, key_sds_len);
        data += key_sds_size;
    }

    /* Copy embedded value (EMBSTR) always as SDS TYPE 8. Account for unused
     * memory in the SDS alloc field. */
    size_t remaining_size = bufsize - (data - (char *)(void *)o);
    o->ptr = sdswrite(data, remaining_size, SDS_TYPE_8, val_ptr, val_len);

    return o;
}

이런 느낌이다.

새로운 해시 테이블 코드 보면서 앞으로 Redis와 합쳐지기는 어렵다는 생각이 더 굳어졌다.

메모리 아끼고 성능 개선하려고 만들어진 코드를 보며 재미도 느끼고 오... 이렇게 까지 한다고? 신기해하며 코드를 봤는데

한편으론 Redis보다 복잡해진 느낌도 받아서 좀 더 알아봐야겠다.

Spring Framework 6.2 문서 읽고 이해하기 ... IOC Container (4)

오산돌구 — Wed, 5 Mar 2025 08:05:42 +0900

Lazy 빈 인스턴스화

기본적으로 ApplicationContext는 초기화될 때 모든 빌은 eager 하게 생성하고 구성하도록 구현되어 있다.

일반적으로 eager 한 생성은 괜찮은 방법인데 왜냐하면 실행 후 몇 시간 또는 며칠 뒤가 아니라 즉시 발견할 수 있기 때문이다.

eager 한 생성이 필요하지 않은 경우 lazy 하게 만들 수 있는데 ApplicationContext가 초기화될 때가 아니라
요청할 때 빈을 생성한다.

lazy 빈을 설정하는 방법은 @Lazy annotation 또는 XML에 <bean />에 lazy-init 속성으로 제어할 수 있다.

<bean id="lazy" class="com.something.ExpensiveToCreateBean" lazy-init="true"/>

<bean name="notLazy" class="com.something.AnotherBean"/>

하지만 eager 한 빈이 lazy 한 빈의 의존관계가 있다면 ApplicationContext는 빈 생성을 위해 lazy 한 빈을 시작할 때 생성한다.

메서드 주입

컨테이너의 대부분의 빈은 싱글톤이다.

싱글톤인 빈은 다른 싱글톤 빈 또는 non-싱글톤 빈과 협업을 할 수 있는데

싱글톤 빈이 non-싱글톤 빈과 협업하려고 할 때 서로 다른 빈의 생명주기로 문제가 생긴다.

싱글톤 빈 A가 non-싱글톤 Bygw 사용한다고 가정했을 때

컨테이너는 A를 최초 한 번만 생성하므로 속성 설정은 딱 한 번만 할 수 있다.

그리고 A에게 매번 새로운 인스턴스인 B를 제공할 수도 없다.

해결책은 IoC를 포기하는 것이다.

ApplicationContextAware 인터페이스를 구현하고 getBean("B")를 호출하는 방식으로
A가 필요할 때마다 매번 B 인스턴스를 컨테이너에 요청하는 방식이다.

Customizing the Nature of a Bean

Method Injection

메서드 주입 검색

메서드 주입 검색은 컨테이너가 관리하는 빈에서 메서드를 오버라이드하고
다른 이름의 빈을 반환하는 기능이다.

Spring Framework는 CGLIB 라이브러리가 생성한 bytecode를 이용해서
메서도 오버라이드한 하위 클래스를 동적으로 생성하는 방식으로 메서드 주입을 구현했다.

동적 하위 클래스 생성방식을 사용하기 위해서는 class와 오버라이드한 메서드 모두 final이면 안된다.
해당 클래스를 유닛테스트 하려면 abstract를 stub 해줘야 한다. (구현해줘야 한다.)
마지막으로 메서드 주입 검색은 factory 메서드와 같이 동작하지 않으면
특히 configuration 클래스의 @Bean 메서드와 함께 동작하지 않는다.
왜냐하면 컨테이너가 인스턴스 생성을(앞에서 말한 B) 담당하지 않아, 하위 클래스를 만들 수 없기 때문이다.

package fiona.apple;

// no more Spring imports!

public abstract class CommandManager {

	public Object process(Object commandState) {
		// grab a new instance of the appropriate Command interface
		Command command = createCommand();
		// set the state on the (hopefully brand new) Command instance
		command.setState(commandState);
		return command.execute();
	}

	// okay... but where is the implementation of this method?
	protected abstract Command createCommand();
}

<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
	<!-- inject dependencies here as required -->
</bean>

<!-- commandManager uses myCommand prototype bean -->
<bean id="commandManager" class="fiona.apple.CommandManager">
	<lookup-method name="createCommand" bean="myCommand"/>
</bean>

또는 abstract 메서드에 @Lookup annotation을 이용하는 방법도 있다.

빈 Scope

빈 정의를 만들 때 XML이나 Annotation 등의 방법으로 실제 인스턴스를 만드는 레시피를 적는다.

이 레시피라는 개념은 중요한데 Java class처럼 하나의 레시피로 많은 인스턴스를 만든다는 걸 의미하기 때문이다.

다양한 의존성이나 설정값을 제어하는 것 외에도 빈 정의의 Scope(범위)도 제어할 수 있다.

Scope은 굉장히 강력하고 유연한데 Java class에서 Scope을 선택하는 게 아니라 설정으로 선택할 수 있다.

빈은 여러 Scope 중 하나를 선택할 수 있다.

Spring Framework는 총 6개의 Scope을 지원하는데 그중 4개는 web-aware ApplicationContext을 사용할 때만 가능하다.

6개 외에도 사용자가 직접 자신만의 Scope을 만들 수도 있다.

Scope	Description
singleton	(Default) Spring IoC 컨테이너마다 한개의 빈 정의는 한개의 인스턴스로 Scope을 지정한다.
prototype	한개의 빈 정의를 임의 개수의 인스턴스로 Scope을 지정한다.
request	한개의 빈 정의를 한개의 HTTP 요청 라이프 사이클에 적용한다. 각 HTTP 요청은 하나의 빈 정의에서 생성된 인스턴스를 가지고 있다. (web-are ApplicationContext)
session	한개의 빈 정의를 HTTP 세션 라이프사이클에 적용한다. (web-are ApplicationContext)
application	한개의 빈 정의를 ServletContext 라이프사이클에 적용한다. (web-are ApplicationContext)
websocket	한개의 빈 정의를 WebSocket 라이프사이클에 적용한다. (web-are ApplicationContext)

Singleton Scope

singleton 빈의 인스턴스는 단 하나만 관리되며, 빈 정의에 있는 ID와 동일한 모든 요청은 특정 빈의 인스턴스를 반환한다.

해당 인스턴스는 singleton 빈 캐시에 저장되고, 해당 빈 이름의 요청이 있을 때마다 캐시에 있는 객체를 반환한다.

Spring의 singleton 빈 개념은 GoF책에 나온 singleton 패턴과는 다르다.

GoF의 singleton은 Java Class를 하드코딩해서 Scope을 지정하고
ClassLoader당 하나의 인스턴스만 생성되고 관리되도록 한다.

Spring의 singleton은 컨테이너와 빈 단위로 잘 설명이 된다.
하나의 Spring 컨테이너에서 특정 클래스의 하나의 빈을 정의했다면 Spring 컨테이너는 빈 정의에 의해 하나의 인스턴스만 생성한다.

Prototype Scope

non-singleton인 prototype은 해당빈에 요청이 올 때마다 빈 정의에 따라 새로운 인스턴스를 만들어 반환한다.

원칙적으로 stateful 빈은 prototype으로 만들고 stateless 빈은 singleton으로 만든다.

다른 Scope과는 다르게 prototype은 Spring이 온전하게 lifecycle을 관리하지 않는다.

컨테이너는 프로토타입 객체를 인스턴스화하여 클라이언트에 전달까지만 하고 더 이상 관여하지 않는다.

초기화 lifecycle 콜백 메서드는 모든 Scope의 객체들이 호출되지만

해제 lifecyle 콜백 메서드의 경우 prototype Scope의 객체는 호출되지 않아서

클라이언트 코드에서 직접 객체를 정리하고 리소스를 해제해야 한다.

또는 해제가 필요한 bean들을 참조하는 custom 빈을 만드는 방법도 있다.

Customizing the Nature of a Bean

Spring Framework 6.2 문서 읽고 이해하기 ... IOC Container (3)

오산돌구 — Sun, 2 Mar 2025 11:00:47 +0900

엔터프라이즈 급 어플리케이션은 대부분 객체 하나만 갖고 있지 않는다.

심지어 간단한 어플레이션도 사용자에게 일관된 기능을 제공하기 위해 서로 협력하는 객체들로 구성된다.

앞에서는 독립적으로 동작하는 빈을 얘기했는데,
지금부터는 어플리케이션의 목표를 온전히 달성하기 위해 객체끼리 협력하는 방법을 설명한다.

의존성 주입

의존성 주입(Dependency injection, DI)은

생성자 주입, factory 메서드로 인자 또는 setter 메서드로 property 설정 방식으로 의존성을 정의하는 프로세스다.

컨테이너는 빈 생성할 때 정의한 의존관계들을 주입한다.

이 과정들은 기본적으로 생성자나 서비스 로케이터 패턴을 이용해서 의존성의 위치나 인스턴스화를 스스로 제어한다. (IoC)

DI 원칙 덕분에 코드는 좀더 깔끔해지고, 디커플링은 의존관계를 더 효과적으로 제공한다.

빈으로 생성될 객체는 종속성이 무엇인지, 위치나 타입 등을 몰라도 된다.

그 결과, 테스트가 쉬운 클래스가 되는데, 특히 interface나 abstract class로 의존관계를 정의했다면
단위테스트에서 스텁이나 목객체를 이용하기 더욱 쉬워진다.

DI는 크게 두가지 방법이 있다.

생성자 기반 의존정 주입(DI)과 Setter 메서드를 이용한 의존성 주입이 있다.

생성자 기반 의존성 주입

생성자 기반 의존성 주입은 컨테이너가 의존관계인 argument와 함께 생성자를 호출한다.

static factory 메소드 호출하는 방식도 생성자 방식과 거의 비슷하다.

아래는 컨테이너의 인터페이스나 기본 클래스, annotation을 사용하지 않는 POJO의 생성자 기반 의존성 주입 예시다.

public class SimpleMovieLister {

	// the SimpleMovieLister has a dependency on a MovieFinder
	private final MovieFinder movieFinder;

	// a constructor so that the Spring container can inject a MovieFinder
	public SimpleMovieLister(MovieFinder movieFinder) {
		this.movieFinder = movieFinder;
	}

	// business logic that actually uses the injected MovieFinder is omitted...
}

생성자의 argument 매칭은 타입을 이용하여 처리한다.

동일한 타입의 빈이 여러개가 있어 모호한 argument가 정의되어 있지 않다면 정의된 순서대로 빈을 생성한다.

package x.y;

public class ThingOne {

	public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
		// ...
	}
}

ThingTwo, ThingThree가 상속하지 않아 모호하지 않는다고 가정해 보면,

아래 설정만으로 훌륭하게 동작한다!! <constructor-arg /> element에 index나 타입 정의를 신경 쓰지 않아도 된다.

<beans>
	<bean id="beanOne" class="x.y.ThingOne">
		<constructor-arg ref="beanTwo"/>
		<constructor-arg ref="beanThree"/>
	</bean>

	<bean id="beanTwo" class="x.y.ThingTwo"/>

	<bean id="beanThree" class="x.y.ThingThree"/>
</beans>

또 다른 예로 아래와 같이 Bean이 아닌 int, String 같이 자료형을 받을 경우 인덱스 번호나(0부터 시작) type으로 값을 주입할 수 있다.

package examples;

public class ExampleBean {

	// Number of years to calculate the Ultimate Answer
	private final int years;

	// The Answer to Life, the Universe, and Everything
	private final String ultimateAnswer;

	public ExampleBean(int years, String ultimateAnswer) {
		this.years = years;
		this.ultimateAnswer = ultimateAnswer;
	}
}

<bean id="exampleBean" class="examples.ExampleBean">
	<constructor-arg type="int" value="7500000"/>
	<constructor-arg type="java.lang.String" value="42"/>
</bean>

또는

<bean id="exampleBean" class="examples.ExampleBean">
	<constructor-arg index="0" value="7500000"/>
	<constructor-arg index="1" value="42"/>
</bean>

Parameter 이름으로도 값 세팅할 수 있는데 아래처럼 생성자에 @ConstructorProperties를 사용하거나
annotation을 쓰지 않으려면 컴파일할 때 -parameter flag를 추가하면 된다.

XML의 property 값은 String으로 정의하고 conversion service를 이용해서 실제 타입으로 변환 후 값을 할당한다.

Spring Type Conversion

package examples;

public class ExampleBean {

	// Fields omitted

	@ConstructorProperties({"years", "ultimateAnswer"})
	public ExampleBean(int years, String ultimateAnswer) {
		this.years = years;
		this.ultimateAnswer = ultimateAnswer;
	}
}


<bean id="exampleBean" class="examples.ExampleBean">
	<constructor-arg name="years" value="7500000"/>
	<constructor-arg name="ultimateAnswer" value="42"/>
</bean>

Setter 메서드 의존성 주입

Setter 기반 DI는 컨테이너가 기본 생성자 또는 parameter가 없는 factory 메서드를 실행해서 빈을 초기화 후 setter 메소드를 실행한다.

아래는 별도의 인터페이스, 기본 클래스, 어노테이션과 의존성이 없는 POJO를 Setter 메소드 의존성 주입 예시다.

public class SimpleMovieLister {

	// the SimpleMovieLister has a dependency on the MovieFinder
	private MovieFinder movieFinder;

	// a setter method so that the Spring container can inject a MovieFinder
	public void setMovieFinder(MovieFinder movieFinder) {
		this.movieFinder = movieFinder;
	}

	// business logic that actually uses the injected MovieFinder is omitted...
}

PropertyEditor 인스턴스와 함께 BeanDefinition 형식으로 의존성을 정의하는 방법도 있지만 잘 사용하지 않는다.

XML bean 설정 또는 @Component, @Controller 같은 annotation 설정,

또는 @Configuration 클래스의 @Bean 메소드를 이용한다.

앞에 3가지 방법은 내부적으로 BeanDefinition 인스턴스로 변환되고, 전체 IoC 컨테이너 인스턴스 로드하는 데 사용된다.

생성자 기반 vs Setter 메서드 기반
Spring 팀은 생성자 기반 방식을 권장한다.
1. 컴포넌트를 불변 객체로 구현할 수 있고,
2. 생성자 기반 컴포넌트는 항상 완전하게 초기화된 인스턴스를 리턴한다. (new 한 다음에 별도 설정이 필요 없다)
3. 추가로, 생성자 argument 개수가 많다면 책임이 많다고 볼 수도 있어 관심사를 적절하게 분리할 타이밍임을 알아챌 수 있다.

종속성 해결 프로세스

1. ApplicaitonContext가 생성되고 모든 bean 정의가 있는 메타데이터 설정을 초기화한다.

메타데이터 설정은 XML, Java, annotation으로 할 수 있다.

2. 각각의 빈의 의존성은 property, 생성자 파라미터, static-factory 메서드 파라미터에 표현되어 있다.

3. property와 생성자 파라미터는 실제 값이거나 컨테이너에 있는 다른 빈 참조다.

4. property나 생성자 파라미터에 지정한 형식에서 실제 유형으로 변환한다.

기본적으로 Spring은 문자열로 지정된 값을 int, long, String, boolean 등 모든 기본 실제 유형으로 변환한다.

Spring Container는 컨테이너가 생성될 때 모든 빈 설정이 유효한지 검사한다.

하지만 bean의 property는 실제 생성되기 전까지 할당되지 않는다.

컨테이너가 생성될 때 빈은 singleton-scoped(default)으로 설정되고 미리 인스턴스화된다.

다른 경우는, 요청이 있을 때 빈을 생성하는 방법도 있다.

Customizing the Nature of a Bean

depdends-on 사용하기

한 Bean이 다른 Bean에 의존성이 있는 경우 XML의 <ref>나 autowiring을 이용한다.

하지만 데이터베이스 드라이버 초기화처럼 의존관계가 덜한 관계도 있다. ※ 실제 사용하지는 않지만 초기화는 필요

이럴 때는 @DependesOn 어노테이션을 이용해서 강제로 의존관계의 Bean을 초기화할 수 있다.

<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
<bean id="manager" class="ManagerBean" />



<!-- multiple depends-on  -->
<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
	<property name="manager" ref="manager" />
</bean>

<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />

Spring Framework 6.2 문서 읽고 이해하기 ... IOC Container (2)

오산돌구 — Sun, 23 Feb 2025 13:28:20 +0900

https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-properties-detailed.html

IoC Container 찍먹 해본 지난 글에 이어서 이번에는 Bean을 알아보자.

https://dol9.tistory.com/332

Spring Framework 6.2 문서 읽고 이해하기 ... IOC Container (1)

현재 정산 백엔드 직군으로 일하고 있고 사용하는 기술은 Spring Boot와 Kotlin이다. (사람마다 깊이에 대한 기준은 다르지만) Spring을 깊은 이해 없이 활용 가능한 정도로 공부한 후 사용하다가 문제

dol9.tistory.com

IoC Container는 한개 이상의 빈을 관리하는데, 이 빈들은 XML <bean /> 같은 메타데이터 설정을 통해 생성된다.

빈 정의는 아래 정보를 BeanDefinition 객체에 담아놓는다.

패키지 포함 클래스 이름: 빈의 실제 구현 클래스
빈의 행위: 컨테이너에서 빈이 어떻게 동작하는지에 대한 상태 정보 (Scope, 라이프사이클 콜백 등등)
빈이 실행되기 위해 참조하는 다른 빈: 참조하는 다른 빈을 collaborators 또는 depdencies라고 부른다
새롭게 생성되는 객체에 설정 정보: 예를 들어 빈에서 커넥션 풀을 관리하기 위해 사용되는 풀의 크기

이 메타데이터는 각각의 빈 정의를 구성하는 속성으로 변환된다. 속성들은 다음과 같다.

Property	Explained in ...
Class	빈 인스턴스화
Name	빈 이름
Scope	빈 Scope
Constructor arguments	의존성 주입
Properties	의존성 주입
Autowiring mode	Autowiring 협력자
Lazy initialization mode	게으른 빈 인스턴스화
Initialization method	초기화 콜백
Destruction method	소멸자 콜백

ApplicationContext에는 빈 생성에 필요한 빈 정의 말고도, registerSingleton(..), registerBeanDefinition(..)을 이용해서
외부에서 생성한 객체를 빈으로 등록할 수도 있다.

하지만 있다는것만 알아두고 어플리케이션 개발할 때 쓰진 말자.

빈 이름

모든 빈은 한 개 이상의 식별자를 가지고 있다.

대개 한개의 식별자만 사용하고 식별자가 더 필요한 경우 별칭을 이용한다.

XML로 메타데이터를 설정한 경우 id 또는 name 속성을 이용해 식별자를 지정할 수 있다.

관습적으로 알파벳과 숫자를 사용하고 특수문자는 사용 가능하다.

별칭을 만들고 싶다면 name속성에 콤마(,), 세미콜론(;), 공백( )을 구분자로 여러 개를 입력하면 된다.

그리고 id 속성은 xsd:string 타입으로 정의됐지만 고유성은 IoC 컨테이너에서만 강제되고, XML parser에서는 강제되지 않는다.
(XML 쓰는 중에는 중복인지 아닌지 알 수 없다는 뜻)

name이나 id가 필수는 아닌데, 둘다 명시하지 않는 경우 자동으로 고유한 이름을 만든다.

하지만 빈 이름으로 참조하거나 XML에서 ref 속성 또는 서비스 로케이터 패턴을 사용한다면 반드시 이름을 지정해야 한다.

빈 이름 규칙
자바에서 멤버변수의 이름 규칙과 동일하게 소문자로 시작하고 camelCase 형식을 쓴다.
이름이 없는 경우 java.beans.Introspector.decapitalize 를 이용해서 자동으로 생성한다.
https://docs.oracle.com/javase/8/docs/api/java/beans/Introspector.html#decapitalize-java.lang.String-

빈 정의 밖에서 빈 별칭 정의하기

앞에서 id 하나, name 여러개 조합으로 여러 이름을 정의할 수 있다고 했다.

하지만 alias 속성을 이용해서 별칭만 정의할 수 있다.
별칭을 이용하면 어플리케이션의 각 컴포넌트가 컴포넌트에 특화된 이름으로 참조하는 상황에 유용하게 사용할 수 있다.

또한 동일한 빈에 대해서 서로 다른 시스템이 사용한다고 할 때 별칭을 사용하면 네임스페이스 느낌으로 관리가 된다.
※ myApp-dataSource, subsystemA-dataSource, subsystemB-dataSource 모두 같은 빈이다.

<alias name="fromName" alias="toName"/>

<alias name="myApp-dataSource" alias="subsystemA-dataSource"/>
<alias name="myApp-dataSource" alias="subsystemB-dataSource"/>

Java-configuration
XML이 아니라 Java configuration을 사용하고 있다면 @Bean annotation으로 별칭을 설정할 수 있다.
자세한 내용은 Using the @Bean Annotation 을 보자

빈 인스턴스화

빈 정의(Bean definition)는 하나 이상의 객체를 생성하는 레시피다.

컨테이너는 생성 요청을 받으면 빈 정의 레시피를 살펴보고, 빈 정의로 캡슐화된 메타데이터 설정을 사용하여

객체를 생성 또는 가져옵니다.

XML 메타데이터 설정을 사용한다면 <bean />의 class 속성을 사용하여 인스턴스화시킬 클래스를 지정한다.

class 속성은 일반적으로 필수 값인데 예외 상황이 있다. ex: Factory Method 또는 Bean 상속

일반적으로 자바 코드의 new 연산자 호출하듯이 container에서 생성자를 직접 호출해서 빈을 생성한다.
컨테니어가 static 팩토리 메소드를 호출해서 빈 생성하는 방법은 덜 일반적이다.
static 팩토리 메소드 호출 결과가 동일한 클래스일 수도 있고 다른 클래스일 수도 있다.

생성자를 이용한 인스턴스화

Spring IoC 컨테이너는 어떠한 클래스라도 관리할 수 있다. 다수의 Spring 유저는 기본 생성자를 이용해서

Bean을 만들고 setter, getter로 프로퍼티 채우는 방식을 선호한다. (예전에 써서 그런가? 이젠 생성자 주입을 선호)

XML 메타데이터 설정을 쓴다면 아래와 같이 빈을 정의할 수 있다.

<bean id="exampleBean" class="examples.ExampleBean"/>

<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

생성자 주입을 좀 더 알고 싶다면 Dependency Injection을 참고하자

Static Factory 메소드를 이용한 인스턴스화

static factory 메소드로 빈을 정의하기 위해서는 clsss 속성에 정의한 클래스에 static factory method 이름이
factory-method로 추가해주면 된다.

<bean id="clientService" class="examples.ClientService" 
		factory-method="createInstance"/>

앞에서 정의한 Bean Definition을 동작하기 위한 클래스 예시는 다음과 같다.

public class ClientService {
	private static ClientService clientService = new ClientService();
	private ClientService() {}

	public static ClientService createInstance() {
		return clientService;
	}
}

한 클래스가 여러 static factory 메서드를 가지고 여러 타입을 리턴할 수도 있다. (개인적으로 있다 정도만 알아두기로 했다.)

보다 자세한 static factory 메소드를 알고 싶다면 Dependencies and Configuration in Detail을 참고하자

Spring Framework 6.2 문서 읽고 이해하기 ... IOC Container (1)

오산돌구 — Sun, 9 Feb 2025 16:00:12 +0900

현재 정산 백엔드 직군으로 일하고 있고 사용하는 기술은 Spring Boot와 Kotlin이다.

(사람마다 깊이에 대한 기준은 다르지만) Spring을 깊은 이해 없이 활용 가능한 정도로 공부한 후

사용하다가 문제 생기면 그때 필요한 부분만 알아가는 식이였다.

IOC Container라는 게 있어서 POJO + Meta정보를 이용해서 Bean을 생성하고 lifecycle도 관리해 주고,
Reflection을 이용해서 DI 해준다 정도... 아는 것도 모르는 것도 아닌 두리뭉실한 느낌

이를 반대로 말하면 문제없는 영역은 잘 모른다는 게 문제다.

Spring Boot가 알아서 해주는 게 많아 개발자는 비즈니스 로직에만 집중한다는 장점이 있지만
프로젝트가 커지다 보면 비즈니스 로직만 알아서는 부족함을 느낀다. 개발 속도가 느려진다.

지금 상황이 그렇다.

코드를 봐야겠다고 결심하게 된 결정적인 계기는
지금 프로젝트를 리팩토링 하려고 테스트 코드 작성하는데 감으로만 알고 있던 걸로는 진행이 안 됐다.

더 이상 구글 검색결과에 나온 방법들로는 해결되지 않았다.

내가 생각한 개발자의 가장 큰 장점은 공개되어 있는 코드들이 많아

시간과 노력을 투자한다면 내부 동작 원리를 알 수 있다는 점이다.

그래서 당장 업무에 도움 될지를 상상하며 내부 동작을 알아보려고 한다.

첫 시작은

Spring framework 6.2!!

나의 지적호기심 채우려고 너무 깊게 알아가는 모습을 항상 경계하자.

Core Technologies / The IoC Container

IOC는 Inversion of Control의 약자로 제어를 내부가 아닌 외부에서 한다는 개념이고

DI는 생성자, property, factory method, setter method 등을 이용하여 의존 관계에 있는 객체를 주입받는 걸 말한다.

IoC 컨테이너는 두 개 패키지가 기본이고 `org.springframeowrk.beans`, `org.springframeowrk.context`

beans 패키지는 BeanFactory interface를, context 패키지는 ApplicationContext interface를 root로 보면 된다.

BeanFactory는 모든 유형의 객체를 관리할 수 있는 메커니즘을 제공하고,
ApplicationContext는 BeanFactory의 하위 interface로 아래와 같은 추가 기능을 제공한다.

Spring AOP 기능과 쉬운 연동
i18n 관리
이벤트 메시지 관리
웹에서 사용하기 위한 WebApplicationContext 같은 계층별 Context

BeanFactory는 프레임워크 설정과 기본 기능을 제공하고, ApplicationContext는 추가로 엔터프라이즈 기능을 제공한다.

이후 Spring IoC Container 설명 ApplicationContext으로 진행한다.
※ BeanFactory에 대한 자세한 내용은 The BeanFactory API 읽을 때 알아보겠습니다.

Container Overview

Spring IoC Container = ApplicationContext interface 느낌.

bean의 인스턴스화, 설정, 조합등을 책임지는데 메타정보를 읽어 처리한다.

다양한 ApplicationContext interface 구현체가 있는데 그중에

AnnotationConfigApplicationContext, ClassPathXmlApplicationContext 가 단독으로 생성 가능하다.

비즈니스 로직이 있는 객체(POJO)와 메타정보를 가져와서 ApplicationContext에서 즉시 사용가능한 Bean 만들어준다.

Configuration Metadata

메타정보는 다양한 방식으로 정의할 수 있는데 대부분의 개발자들은 주로 Java-based configuration 방식을 사용한다.

Annotation-based configuration: 애플리케이션 컴포넌트 클래스에 annotation을 사용해서 bean을 정의하는 방식
Java-based configuration: 애플리케이션과 별개의 클래스에 bean을 정의하는 방식

XML 방식도 있는데 XML에 <beans/>를 적고 하위에 <bean/>을 적어서 bean을 정의한다.

※ <import /> element를 이용해서 다른 xml파일에 정의한 bean 내용을 가져올 수도 있다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <!-- services -->
    <bean id="petStore" class="com.tistory.dol9.context.support.PetStore"/>
</beans>

ClassPathXmlApplicationContext 생성자 argument로 Java classpath 기준 xml을 넘겨주면 IoC container가 생성된다.

XML 경로는 상대경로 대신 절대경로 사용을 권장한다.

추가로 GenericApplicationContext와 reader delegate를 이용해서 container를 생성할 수도 있다.

// create and configure beans using ClassPathXmlApplicationContext
val context: ApplicationContext = ClassPathXmlApplicationContext(SINGLE_CONTEXT)

val service: PetStore = context.getBean("petStore", PetStore::class.java)

// create and configure beans using GenericApplicationContext
val context = GenericApplicationContext()
val beanDefinition = BeanDefinitionBuilder.genericBeanDefinition(PetStore::class.java).beanDefinition
context.registerBeanDefinition("petStore", beanDefinition)
context.refresh()

val service: PetStore = context.getBean("petStore", PetStore::class.java)
val userList = service.userName


// PetStore
class PetStore {
	val userName: List<String>
		get() = mutableListOf("dol9", "dol10")
}

위에 작성한 XML과 코드

https://github.com/kgcrom/learn-something/commit/e95a391445213127ff9eb6e7017b7c9a833d98bc

Spring Framework 6.2 git clone 한 뒤 코드를 봤지만 이해 안 되는 게 참 많았다.

문서 Resource까지 보면서 대강 분위기 익히고 코드를 봐야겠다.

CSS를 공부하다가 AI활용에 대해 생각해봤다.

오산돌구 — Thu, 14 Nov 2024 23:37:23 +0900

프론트엔드 작업할게 생겨서 Next.js + React 그리고 Ant 디자인 시스템으로 인하우스 화면을 개발하고 있다.

개발한다고는 했지만 사실 뭐.. 이미 있는 코드 보면서 눈치로 그린다는 표현이 더 맞겠다.

ant.design에서 원하는 동작의(?) 컴포넌트를 검색한 후 화면 컴포넌트에 복붙 한다.

내가 원하는 위치에 올 때까지(?) 정렬이랑 마진 주면서 대강 맞춘다.

입력을 받고 API 호출하고 결과 보여주는 팀 내에서 사용하는 인하우스 시스템이어서 크게 문제가 되지 않았다.

원하는 기능 동작과 누락한 컴포넌트 없이 잘 구현했지만

뭐라 표현할 수 없는...뭔가 애매~한 느낌과 화면 크기에 따라 텍스트가 넘어가고 깨지고 난리도 아니었다.

layout 잡는 게 중요하다고 다시 느꼈다.

지금까지 인하우스 화면 개발할 때는 기능 동작을 최우선으로 삼아

화면 개발은 주먹구구 식으로 했는데, 이번에 시간을 들여 공부하기로 했다.

영상과 글로 Flex, Grid를 공부하다가 알게 된 근본 사이트!!

지금 Box model 보고 있는데 이 개념을 모르고 CSS 만졌던 내 모습이 부끄러웠다.

객체에 한가지의 역할과 책임을 주고 격리시킨다는 개념과 Box model이 비슷하다는 느낌도 들었다.

CSS 학습 | web.dev

웹 스타일링 전문 지식을 한 단계 끌어올릴 수 있는 상시 CSS 과정 및 참고 자료.

web.dev

Flex, Grid 그리고 Box model 까지 학습했지만 개발은 해야 했다.

여기서 놀란 점!!

위에 나열한 지식을 모르고 Github Copilot에게 질문했을 때 답변과

지식을 알고 구체적으로 질문했을 때의 답변의 퀄리티가 상당히 차이가 있었다. (후자가 좋다)

그리고 코드 자동완성도 뭔가 착 달라붙는 느낌??

정보는 흘러넘쳐나고 LLM으로 웬만한 정보는 빠르게 찾고 가공할 수 있고 뭐든 만들 것 같지만

가장 중요한 건 본인의 역량이라고 느꼈다.

이제 막 개발을 시작한 사람이 AI와 함께 한다고 해서 20년 이상 개발해 온 개발자만큼 작성하는 모습은 상상하기 어렵다.

결국 기본이 더 중요해진 것 같다.

유튜브에서 'AI를 쓰면 성공(?), 안 쓰면 도태'라는 주장들을 종종 보는데 동의하기 어렵고

본인이 가진 역량에서 AI를 잘 쓴다면 곱하기가 된다고 본다.

그래서 내가 가진 역량이 5라면 AI를 더 잘 쓰려고 노력하기보다는

10의 역량을 가지도록 (AI와 함께)노력하는 게 오히려 더 나은 결과물을 만든다고 생각한다. (성공/실패와는 별개로 꽤 괜찮은 결과물)

ASI 세상이 오면 또 모르겠다..

[IT TREND] AGI를 향한 기대와 우려

시작하며 4월에도 기술 시장 소식은 AI를 중심으로 끊임없이 이어지고 있습니다. 금주의 수 많은 소식들을 살펴보며 특히 눈에 띄었던 것은, 바로 AGI (Artificial General Intelligence)에 대하여 다루는

tech.kakaoenterprise.com

저희는 프로그래머가 오랫동안 '운전석'에 있는 미래를 그리고 있어요
cursor 대표 인터뷰 중

https://maily.so/josh/posts/2nznwx6gzp5

"AI가 개발자를 대체? ‘이 능력’ 키우세요." 커서 창업자 인터뷰

Open AI를 제치고 세계 가장 핫한 툴 1위가 된 커서

maily.so

CSS 러닝코스 마무리하면 프론트 개발 하면서 AI와 긴밀하게 협업하는 모습을 상상하니 벌써 설렌다.