꿈꾸는 사람들

WSL/WSL2 완벽 가이드

환영전사 — Wed, 8 Jul 2026 14:19:07 +0900

WSL/WSL2 완벽 가이드

개념부터 배포판 설치·관리까지

Windows에서 리눅스 환경이 필요할 때 가장 먼저 떠오르는 선택지가 바로 WSL(Windows Subsystem for Linux)입니다. 가상 머신처럼 무겁지도 않고, 듀얼 부팅처럼 번거롭지도 않게 Windows 안에서 진짜 리눅스를 쓸 수 있게 해주는 기능이죠. 이 글에서는 WSL과 WSL2의 개념 차이부터, 설치 방법, 그리고 게스트 OS(배포판)를 설치하고 관리하는 방법까지 한 번에 정리합니다.

1. WSL이란?

WSL은 Windows 위에서 리눅스 바이너리 실행 파일을 네이티브로 실행할 수 있게 해주는 호환 계층입니다. Microsoft가 만든 기능으로, 별도의 가상 머신 설정이나 듀얼 부팅 없이 Windows Terminal이나 명령 프롬프트에서 바로 Ubuntu, Debian, Kali Linux 같은 배포판을 사용할 수 있습니다.

대표적인 활용 사례는 다음과 같습니다.

● 리눅스 전용 CLI 도구, 스크립트 실행

● Docker, Kubernetes 등 컨테이너 기반 개발 환경 구축

● 웹 개발 시 서버 환경(nginx, MySQL, Redis 등)을 로컬에서 재현

● macOS/Linux 기준으로 작성된 오픈소스 프로젝트 빌드

2. WSL 1 vs WSL 2, 무엇이 다른가

WSL은 버전에 따라 내부 동작 방식이 완전히 다릅니다.

WSL 1

● 리눅스 시스템 콜을 Windows 커널이 이해할 수 있는 형태로 변환(translation layer)하는 방식

● 실제 리눅스 커널을 사용하지 않음

● Windows 파일 시스템과의 파일 접근 속도가 빠름

● 일부 시스템 콜 미지원으로 인해 특정 리눅스 프로그램이 동작하지 않을 수 있음

WSL 2

● 경량 가상 머신(Hyper-V 기반) 위에서 실제 리눅스 커널을 구동하는 방식

● 시스템 콜 호환성이 완전해 대부분의 리눅스 프로그램이 문제없이 동작

● 전체 리눅스 커널 기능 지원 (Docker, systemd 계열 도구 등과의 호환성이 크게 향상됨)

● 자체 가상 네트워크 어댑터를 사용하므로 네트워킹 방식이 WSL 1과 다름

● Windows 파일 시스템(/mnt/c 등) 접근 속도는 WSL 1보다 다소 느릴 수 있음

비교표

항목	WSL 1	WSL 2
구조	시스템 콜 변환 계층	경량 VM + 실제 리눅스 커널
커널	없음(에뮬레이션)	실제 Linux 커널 사용
리눅스 호환성	일부 제한	완전한 호환성
파일 접근 속도 (Windows FS)	빠름	상대적으로 느림
파일 접근 속도 (Linux FS)	보통	빠름
메모리 사용	필요한 만큼만	VM 특성상 다소 높음
네트워킹	Windows와 동일 IP 공유	별도 가상 네트워크 어댑터
Docker 지원	제한적	원활

특별한 이유가 없다면 대부분의 최신 환경에서는 WSL 2 사용을 권장합니다. 다만 Windows 파일 시스템(C:\ 등) 안의 파일을 리눅스에서 빈번하게 읽고 쓰는 작업이 많다면 WSL 1이 유리할 수 있습니다.

3. 설치 요구사항

● Windows 11, 또는 Windows 10 버전 1903(빌드 18362) 이상 (x64 기준)

● ARM64 시스템은 Windows 10 버전 2004(빌드 19041) 이상

● WSL 2를 쓰려면 BIOS/UEFI에서 가상화(Virtualization) 기능이 활성화되어 있어야 함

4. WSL 설치 방법

4.1 자동 설치 (권장)

Windows 10(최신 빌드) 또는 Windows 11에서는 관리자 권한 PowerShell(또는 명령 프롬프트)에서 명령어 하나로 설치가 끝납니다.

wsl --install

이 명령어는 다음을 한 번에 처리합니다.

● WSL 관련 Windows 기능 활성화

● WSL 2를 기본 버전으로 설정

● 기본 배포판(Ubuntu)을 Microsoft Store를 통해 설치

설치 후 시스템을 재부팅하면 되고, 이후 Ubuntu가 자동으로 실행되며 최초 1회 사용자 이름과 비밀번호를 설정하게 됩니다.

특정 배포판을 지정해서 설치하고 싶다면 다음과 같이 사용합니다.

wsl --install -d Debian

4.2 수동 설치 (구버전 Windows용)

자동 설치가 지원되지 않는 환경이라면 아래 단계를 따릅니다.

1단계 — WSL 기능 활성화

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

2단계 — 가상 머신 플랫폼 기능 활성화 (WSL 2용)

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

3단계 — 재부팅

4단계 — WSL 2 리눅스 커널 업데이트 패키지 설치

Microsoft에서 배포하는 커널 업데이트 패키지(wsl_update_x64.msi)를 다운로드해 설치합니다.

5단계 — WSL 2를 기본 버전으로 설정

wsl --set-default-version 2

6단계 — Microsoft Store에서 원하는 배포판 설치

Microsoft Store 앱을 실행해 Ubuntu, Debian, Kali Linux 등 원하는 배포판을 검색해 설치합니다.

5. 게스트 OS(배포판) 설치 및 관리

WSL의 큰 장점 중 하나는 여러 리눅스 배포판을 동시에 설치하고 독립적으로 관리할 수 있다는 점입니다. 이 부분을 좀 더 자세히 살펴보겠습니다.

5.1 설치 가능한 배포판 목록 확인

wsl --list --online

Ubuntu, Debian, Kali Linux, openSUSE, Oracle Linux, Fedora 등 Microsoft Store를 통해 제공되는 배포판 목록이 표시됩니다.

5.2 배포판 설치

wsl --install -d <배포판이름>

예시:

wsl --install -d kali-linux

Microsoft Store 앱에서 직접 검색해 "가져오기(설치)" 버튼을 눌러 설치할 수도 있습니다.

5.3 설치된 배포판 목록 확인

wsl --list --verbose

또는 짧게

wsl -l -v

이 명령을 실행하면 아래와 같이 배포판 이름, 실행 상태(Running/Stopped), WSL 버전을 확인할 수 있습니다.

NAME            STATE           VERSION
* Ubuntu          Running         2
Debian          Stopped         2
kali-linux      Stopped         1

* 표시는 현재 기본 배포판을 의미합니다.

5.4 기본 배포판 지정

여러 배포판을 설치했을 때, wsl 명령어만 입력하면 실행될 기본 배포판을 지정할 수 있습니다.

wsl --set-default <배포판이름>

5.5 배포판별 WSL 버전 전환

특정 배포판만 WSL 1 ↔ WSL 2로 전환하고 싶을 때 사용합니다.

wsl --set-version <배포판이름> 2

새로 설치되는 배포판에 적용될 기본 버전을 바꾸고 싶다면:

wsl --set-default-version 2

5.6 배포판 실행

● 시작 메뉴에서 배포판 이름(예: "Ubuntu")을 검색해 실행

● Windows Terminal에서 새 탭 드롭다운으로 배포판 선택

● PowerShell/CMD에서 배포판 이름을 직접 입력해 실행

특정 배포판을 특정 사용자로 실행하고 싶다면:

wsl --distribution <배포판이름> --user <사용자이름>

5.7 배포판 종료 / 전체 종료

특정 배포판만 종료:

wsl --terminate <배포판이름>

WSL 전체(모든 배포판 + 경량 VM)를 종료:

wsl --shutdown

5.8 배포판 삭제(등록 취소)

더 이상 필요 없는 배포판을 제거할 때 사용합니다.

wsl --unregister <배포판이름>

⚠️ 이 명령을 실행하면 해당 배포판 안의 모든 데이터와 설정이 영구적으로 삭제됩니다. 다시 설치하면 초기 상태의 깨끗한 배포판이 새로 설치됩니다.

5.9 배포판 백업 및 이전 (export / import)

다른 PC로 옮기거나 백업해두고 싶을 때 사용합니다.

# 내보내기 (tar 파일로 백업)
wsl --export <배포판이름> D:\backup\ubuntu-backup.tar

# 가져오기 (새 이름/경로로 복원)
wsl --import <새배포판이름> D:\wsl\ubuntu-new C:\backup\ubuntu-backup.tar

이 기능은 배포판을 복제하거나, 같은 배포판을 여러 개 만들어 프로젝트별로 독립된 환경을 구성할 때도 유용합니다.

6. 자주 쓰는 WSL 명령어 정리

명령어	설명
wsl --install	WSL 및 기본 배포판(Ubuntu) 설치
wsl --install -d <이름>	특정 배포판 설치
wsl --list --online	설치 가능한 배포판 목록 조회
wsl --list --verbose (wsl -l -v)	설치된 배포판 및 상태/버전 확인
wsl --set-default <이름>	기본 배포판 지정
wsl --set-version <이름> <1\|2>	특정 배포판의 WSL 버전 변경
wsl --set-default-version <1\|2>	새로 설치되는 배포판의 기본 버전 지정
wsl --terminate <이름>	특정 배포판 종료
wsl --shutdown	모든 배포판 및 WSL 가상 머신 종료
wsl --unregister <이름>	배포판 삭제
wsl --export / --import	배포판 백업 / 복원
wsl --update	WSL 자체 업데이트
wsl --status	현재 WSL 설정 상태 확인
wsl --help	전체 명령어 도움말

7. 파일 시스템 및 상호운용성

WSL의 강점 중 하나는 Windows와 리눅스 간 파일 시스템이 서로 연결되어 있다는 점입니다.

● 리눅스에서 Windows 드라이브 접근: /mnt/c/, /mnt/d/ 등

● Windows 탐색기에서 리눅스 배포판 파일 접근: 주소창에 \\wsl$\<배포판이름>\ 입력

● 리눅스 셸에서 Windows 실행 파일 직접 실행 가능 (예: notepad.exe)

● Windows에서도 리눅스 명령 실행 가능 (예: PowerShell에서 wsl ls -al)

성능 측면에서는, 자주 수정하는 프로젝트 파일은 Windows 파일 시스템(/mnt/c/...)보다 리눅스 파일 시스템 내부(~/project 등)에 두는 것이 WSL 2에서 훨씬 빠릅니다.

8. 리소스 사용량 제한 (.wslconfig)

WSL 2는 경량 VM 방식이라 메모리·CPU를 과도하게 점유하는 경우가 있습니다. 이럴 때는 사용자 홈 디렉터리(C:\Users\<사용자명>\.wslconfig)에 설정 파일을 만들어 리소스를 제한할 수 있습니다.

[wsl2]
memory=4GB
processors=2
swap=2GB

설정을 적용하려면 wsl --shutdown 실행 후 다시 배포판을 실행하면 됩니다.

9. 함께 쓰면 좋은 도구들

Windows Terminal: 여러 배포판/셸을 탭으로 관리하고 커스터마이징까지 가능해 WSL 사용 시 사실상 필수급 도구

VS Code + WSL 확장: 로컬 Windows에서 에디터를 실행하면서 실제 코드 실행/디버깅은 WSL 내부에서 처리

Docker Desktop: WSL 2 통합 기능을 켜면 별도의 VM 없이 WSL 배포판 안에서 바로 Docker 사용 가능

Git: 리눅스 환경에서 네이티브 Git 사용, Windows와 자격 증명(Credential) 공유 설정 가능

10. 마무리

WSL은 "Windows냐 리눅스냐"라는 양자택일에서 벗어나, 하나의 PC에서 두 환경을 자연스럽게 오갈 수 있게 해주는 도구입니다. 특히 WSL 2로 넘어오면서 실제 리눅스 커널을 사용하게 되어 호환성과 성능 면에서 크게 발전했고, 개발 환경 구축의 진입 장벽을 상당히 낮춰주었습니다.

정리하면,

● 개념: WSL 1은 변환 계층, WSL 2는 실제 커널 기반 경량 VM

● 설치: wsl --install 한 줄이면 대부분 해결

● 관리: wsl --list, --set-default, --set-version, --unregister, --export/--import 등으로 배포판을 자유롭게 다룰 수 있음

이 정도만 알아둬도 WSL을 실무 개발 환경으로 충분히 활용할 수 있습니다.

로컬 LLM + Cline 바이브 코딩 가이드 - 6부. 최적화 및 문제 해결, 7부. 마무리

환영전사 — Tue, 7 Jul 2026 17:12:07 +0900

21장. vLLM 성능 튜닝 — 단일 5090 기준

21.1 `gpu-memory-utilization` 튜닝

기본값은 보통 0.9입니다. OOM(Out of Memory)이 발생하면 0.85, 0.8 순으로 낮춰가며 안정적인 값을 찾습니다.

vllm serve Qwen/Qwen2.5-Coder-32B-Instruct-AWQ \
--gpu-memory-utilization 0.85 \
...

21.2 컨텍스트 길이 vs `max-num-seqs` 균형

--max-num-seqs는 동시에 처리할 수 있는 요청(시퀀스) 수를 제한합니다. 바이브 코딩처럼 개인이 순차적으로 사용하는 경우 동시 요청 수는 크지 않아도 되므로, 이 값을 낮추고 대신 --max-model-len을 늘리는 방향이 유리할 수 있습니다.

--max-num-seqs 4 --max-model-len 32768

21.3 AWQ 양자화 적용 시 속도/품질 비교

● AWQ 4bit은 BF16 대비 VRAM 사용량을 크게 줄여주지만, 일부 벤치마크에서는 고대역폭 GPU에서 BF16보다 오히려 느린 경우도 보고된 바 있습니다 (양자화 해제 연산 오버헤드 때문). 실제 환경에서 두 방식을 모두 벤치마크해보고 선택하는 것을 권장합니다.

# BF16 버전과 AWQ 버전을 각각 실행해 처리량 비교
# (동일 프롬프트로 반복 요청 후 평균 응답 시간 측정)

22장. 응답 속도 개선 팁

22.1 Prefix Caching 활용

Cline은 시스템 프롬프트, .clinerules, 파일 내용 등 동일한 접두 부분이 반복되는 요청을 자주 보냅니다. vLLM의 prefix caching을 활성화하면 이 반복되는 부분을 캐싱해 프리필 시간을 크게 줄일 수 있습니다.

vllm serve Qwen/Qwen2.5-Coder-32B-Instruct-AWQ \
--enable-prefix-caching \
...

22.2 지연시간(latency) 최적화 중심 전략

프로덕션 서버와 달리 개인 개발 환경에서는 처리량(throughput)보다 단일 요청의 응답 속도(latency) 가 체감 성능에 더 중요합니다. 동시 요청 수 제한을 낮추고, 컨텍스트 길이를 실사용에 맞게 최소화하는 방향으로 튜닝하세요.

23장. 흔한 문제와 해결법


CUDA error: no kernel image is available / sm_120 is not compatible	구버전 CUDA/PyTorch/vLLM 사용	CUDA 12.8+, PyTorch 2.9.0+cu128, vLLM 0.17.0+ 로 업그레이드 (2부 4.2절, 3부 7.1절)
FlashAttention 관련 오류	Blackwell에서 FlashAttention 3 미지원	환경변수 VLLM_FLASH_ATTN_VERSION=2 설정 후 재시작
Windows에서 GPU 작업 중 시스템 멈춤(hang)	RTX 5090/RTX PRO 계열 WDDM 반가상화 버그	WSL2 또는 네이티브 Linux로 전환 (3부 7.1절)
특정 최신 모델(예: 일부 GLM 계열) 구동 실패	Blackwell 대응이 아직 안 된 모델/커널	해당 모델의 vLLM 이슈 트래커에서 Blackwell 지원 현황 확인 후 대안 모델 사용
CUDA OOM	컨텍스트 길이/동시 요청 수 과다	--max-model-len, --max-num-seqs, --gpu-memory-utilization 하향 조정 (6부 21장)
Cline에서 tool call 파싱 오류	--tool-call-parser 값이 모델과 불일치	모델 카드에서 권장 파서 확인 후 재설정 (3부 7.5절)
IntelliJ 플러그인 인덱싱/버전 호환 이슈	IDE 버전과 플러그인 버전 불일치	Marketplace에서 플러그인 최신 버전 확인, IDE도 최신 버전 유지

# FlashAttention 버전 강제 지정 예시
export VLLM_FLASH_ATTN_VERSION=2
vllm serve ...

24장. 클라우드 모델과 병행 사용 전략

로컬 vLLM 환경은 일상적인 반복 작업(보일러플레이트 생성, 간단한 리팩터링, 테스트 코드 작성)에는 충분히 효과적이지만, 다음과 같은 경우에는 클라우드 모델(Claude 등)과 병행하는 것이 실용적입니다.


반복적인 CRUD 코드, 보일러플레이트	로컬 (vLLM)
간단한 버그 수정, 리팩터링	로컬 (vLLM)
전체 시스템 아키텍처 설계	클라우드 (복잡한 추론 필요)
여러 마이크로서비스에 걸친 대규모 리팩터링	클라우드 (긴 컨텍스트, 강한 추론)
민감한 사내 코드/데이터 처리	로컬 (프라이버시)

Cline은 Provider 설정을 간단히 전환할 수 있으므로, 같은 프로젝트 안에서도 작업 성격에 따라 로컬↔클라우드를 오가며 사용하는 것이 가능합니다. 다만 이 경우 4부에서 강조한 설계 문서(`docs/`, `memory-bank/`)를 잘 유지해두면, 어떤 모델을 쓰든 일관된 맥락으로 작업을 이어갈 수 있습니다.

7부. 마무리

25장. 실전 프로젝트 예제

이 가이드에서 다룬 전체 흐름(분석/설계 → 환경 구축 → 바이브 코딩 → 검증)을 실습해볼 수 있는 간단한 CLI 툴 예제를 제안합니다.

예제: 로컬 파일 정리 CLI 툴

1. 요구사항 정의 (11장): "지정한 폴더 내 파일을 확장자별로 하위 폴더에 자동 분류하는 CLI 툴"

2. 설계 문서화 (12~13장): docs/PRD.md, docs/ARCHITECTURE.md 작성 → memory-bank/ 초기화

3. 환경 준비: vLLM 서버 기동 (3부 7장), Cline 연결 확인 (3부 9장)

4. Task 분해 (14.1절):

● Task 1: CLI 인자 파싱 (argparse)

● Task 2: 폴더 스캔 및 확장자 분류 로직

● Task 3: 파일 이동 로직 (dry-run 옵션 포함)

● Task 4: 테스트 코드 작성

5. Plan → Act 반복 (16장): 각 Task를 Plan 모드로 상의 후 Act 모드로 구현

6. 검증: pytest 실행, 설계 문서와의 일치 여부 확인 (14.2절)

이 예제는 복잡도가 낮아 로컬 32B급 모델로도 충분히 안정적으로 완주할 수 있으며, 가이드 전체 흐름을 손에 익히기에 적합합니다.

26장. 참고 자료 및 커뮤니티 링크

● vLLM 공식 문서 및 릴리즈 노트: https://docs.vllm.ai

● vLLM GitHub 이슈 트래커 (Blackwell/RTX 5090 관련 이슈 검색 시 유용): https://github.com/vllm-project/vllm/issues

● Cline 공식 GitHub: https://github.com/cline/cline

● Hugging Face 모델 허브 (코딩 모델 검색): https://huggingface.co/models

이 가이드에 포함된 버전 정보(vLLM 0.17.0+, CUDA 12.8+, PyTorch 2.9.0 등)와 모델 추천 목록은 작성 시점 기준입니다. RTX 5090/Blackwell 관련 소프트웨어 생태계는 빠르게 개선되고 있으므로, 실제 설치 전에는 위 공식 문서/릴리즈 노트에서 최신 정보를 한 번 더 확인하시길 권장합니다.

*끝.*

로컬 LLM + Cline 바이브 코딩 가이드 - 5부. 실전 바이브 코딩

환영전사 — Tue, 7 Jul 2026 17:09:43 +0900

15장. 첫 프로젝트 시작하기

15.1 VS Code에서 시작하기

- File → Open Folder로 프로젝트 폴더 열기 (빈 폴더도 가능)

- Cline 패널 열기

- 4부에서 준비한 docs/ 폴더와 .clinerules가 있다면 먼저 프로젝트 루트에 배치

- Cline 채팅창에 첫 지시 입력

@docs/ARCHITECTURE.md @docs/API_SPEC.md
이 설계를 기준으로 프로젝트 초기 구조(폴더, 기본 설정 파일)를 만들어줘.
아직 세부 로직은 작성하지 말고 뼈대만 잡아줘.

15.2 IntelliJ에서 시작하기

- File → Open으로 프로젝트 열기

- Cline 툴 윈도우 열기

- 이하 진행 방식은 VS Code와 동일

15.3 프로젝트 폴더 열기 및 작업 지시 팁

● 폴더 전체를 열어야 Cline이 프로젝트 구조를 스스로 탐색할 수 있습니다. 단일 파일만 열어서는 제한적으로 동작합니다.

● 첫 지시는 "전부 다 만들어줘"보다 "뼈대만 잡아줘" 처럼 범위를 좁게 주는 것이 검토하기에도, 로컬 모델의 컨텍스트 관리 측면에서도 유리합니다.

16장. Plan 모드 vs Act 모드 활용법

16.1 Plan 모드

● 파일을 수정하거나 명령을 실행하지 않고, 대화와 계획 수립만 진행하는 모드

● 요구사항을 다듬거나(11.3절), 구현 방향을 상의하거나, 여러 접근 방식의 장단점을 비교할 때 사용

● 로컬 모델의 경우, Plan 모드에서 충분히 계획을 구체화해두면 이후 Act 모드에서의 실패 확률을 크게 줄일 수 있습니다.

[Plan 모드 예시]
사용자 인증 기능을 추가하려고 해. JWT 방식과 세션 방식 중 어떤 게 이 프로젝트에 맞을지
docs/ARCHITECTURE.md를 참고해서 의견을 줘. 아직 코드는 작성하지 마.

16.2 Act 모드

● 실제로 파일을 생성/수정하고 터미널 명령을 실행하는 모드

● Plan 모드에서 방향이 정해진 뒤 전환해서 사용하는 것을 권장

[Act 모드 예시]
방금 상의한 JWT 방식으로 인증 미들웨어를 구현해줘.

16.3 권장 워크플로우

1. Plan 모드: 요구사항/방향 상의
2. (필요시) 설계 문서 업데이트 (4부 14.4절)
3. Act 모드: 작은 Task 단위로 구현 지시
4. 결과 검토 (diff 확인)
5. 다음 Task로 이동, 반복

17장. 파일 생성/수정 워크플로우

17.1 Diff 확인 및 승인 과정

Cline이 파일을 수정할 때는 즉시 반영되지 않고, 변경 사항(diff)을 먼저 보여주고 승인을 요청합니다.

● 초록색(추가)/빨간색(삭제) 라인으로 변경 내용 표시

● "Save" 또는 "Approve" 버튼으로 승인, 거부 시 변경 사항 취소

● 승인 전 반드시 변경 라인 하나하나를 읽고 의도와 일치하는지 확인하는 습관을 들이는 것이 중요합니다. 로컬 모델은 가끔 관련 없는 파일까지 건드리려 하는 경우가 있어, 이 검토 단계를 생략하면 안 됩니다.

17.2 자동 승인 설정 주의사항

Cline은 특정 작업(파일 읽기, 안전한 명령 등)에 대해 자동 승인을 설정할 수 있는 옵션을 제공합니다. 편의를 위해 켜둘 수는 있지만, 파일 삭제, 외부 네트워크 요청, git push 등 되돌리기 어려운 작업은 항상 수동 승인으로 유지하는 것을 권장합니다.

18장. 터미널 명령 실행과 자동화

Cline은 필요시 다음과 같은 명령을 스스로 실행하고 결과를 읽어 다음 행동을 결정합니다.

# Frontend (Vue.js)
npm install
npm run test:unit

# Backend (Spring Boot)
./gradlew build
./gradlew test

git status
git commit -m "..."

● 명령 실행 결과(특히 에러 메시지)는 Cline의 다음 판단에 직접 사용되므로, 실행 로그가 잘리지 않도록 vLLM의 --max-model-len 설정에 여유를 두는 것이 좋습니다 (2부 6.3절).

● 위험한 명령(rm -rf, git push --force 등)은 실행 전 반드시 직접 확인하세요.

19장. 에러 디버깅을 Cline과 함께하기

19.1 기본 흐름

- 테스트 실행 또는 앱 실행 → 에러 발생

- Cline에게 에러 로그를 그대로 전달 (또는 Cline이 직접 명령을 실행해 로그를 읽음)

- Cline이 원인 분석 및 수정 diff 제안

- 검토 후 승인 → 재실행 → 반복

[프롬프트 예시]
./gradlew test 실행했더니 아래 에러가 나. 원인을 분석하고 수정해줘.

TodoServiceTest > completeTodo_shouldSetCompletedTrue() FAILED
    org.opentest4j.AssertionFailedError:
    Expecting: false
    to be equal to: true

19.2 로컬 모델 디버깅 시 유의점

로컬 32B급 모델은 복잡한 스택 트레이스나 여러 파일에 걸친 원인 추적에서 클라우드 최상위 모델보다 실수가 잦을 수 있습니다. 다음을 권장합니다.

● 에러와 직접 관련된 파일만 @ 첨부로 명시적으로 제공 (전체 코드베이스를 다 훑게 하지 않기)

● 한 번에 여러 에러를 몰아서 던지지 말고, 하나씩 순차적으로 해결

● 원인이 명확하지 않을 때는 Plan 모드로 전환해 가설을 먼저 논의한 후 Act 모드로 수정

20장. 컨텍스트 관리하기

20.1 `.clineignore`

프로젝트 내 불필요한 파일(빌드 산출물, 의존성 폴더, 대용량 데이터 등)을 Cline이 읽지 않도록 제외합니다.

# .clineignore
node_modules/
dist/
build/
.gradle/
*.log
.env
application-secret.yml

이는 단순히 성능 문제가 아니라, 로컬 모델의 짧은 컨텍스트를 불필요한 내용으로 낭비하지 않기 위한 필수 설정입니다.

20.2 프로젝트 구조 최적화

● 파일당 코드 길이를 너무 길게 두지 않기 (한 파일이 너무 크면 그 파일 하나만 읽어도 컨텍스트를 크게 소진)

● 관심사별로 파일을 명확히 분리 (12.1절 폴더 구조 참고)

● memory-bank/(13.3절) 를 활용해 "지금 필요한 요약"만 우선 참조하는 습관

20.3 짧은 컨텍스트 한계 다루는 법 정리


Task 잘게 쪼개기	4부 14.1절 참고, 한 번의 요청 범위를 좁게
.clineignore 활용	불필요한 파일 원천 차단
선택적 @ 첨부	관련 파일만 명시적으로 첨부, 전체 스캔 지양
Memory Bank 요약본 우선	전체 문서 대신 activeContext.md 같은 요약 먼저 참조
새 세션으로 리셋	대화가 너무 길어지면 memory-bank를 참조시키며 새 세션 시작

로컬 LLM + Cline 바이브 코딩 가이드 - 4부. 분석/설계와 바이브 코딩 연결하기

환영전사 — Tue, 7 Jul 2026 17:07:07 +0900

10장. 바이브 코딩 전 분석/설계가 필요한 이유

10.1 로컬 LLM의 제한적 추론 능력과 설계 부재 시 발생하는 문제

바이브 코딩에서 가장 흔한 실패 패턴은 "설계 없이 바로 코딩 지시부터 하는 것"입니다. 특히 로컬 환경에서 구동하는 32B급 모델은 클라우드 최상위 모델 대비 다음과 같은 한계가 있을 수 있습니다.

● 여러 파일에 걸친 일관된 아키텍처를 스스로 유지하는 능력이 상대적으로 약함

● 긴 대화가 이어지면 앞서 정한 규칙(네이밍 컨벤션, 폴더 구조 등)을 잊어버리는 경향

● 모호한 지시("로그인 기능 만들어줘")를 받으면 임의로 세부사항을 추측해서 구현 → 나중에 요구사항과 어긋남이 드러남

설계 없이 진행하면 다음과 같은 악순환이 발생하기 쉽습니다.

모호한 지시 → AI가 임의로 추측하여 구현 → 의도와 다른 결과물
→ 수정 지시 → 다른 부분과 충돌 → 재수정 → ... (반복)

이 악순환은 대화가 길어질수록 컨텍스트가 누적되어 로컬 모델의 컨텍스트 한계에도 더 빨리 도달하게 만듭니다.

10.2 "설계는 사람 주도 + 코딩은 AI 위임" 역할 분담 원칙

이 가이드가 권장하는 원칙은 다음과 같습니다.


요구사항 정의	사람	비즈니스 맥락, 사용자 니즈는 AI가 알 수 없음
아키텍처/설계	사람 (AI와 상의)	장기적 유지보수성, 팀 컨벤션 판단은 사람의 몫
설계 문서화	사람 + AI 협업	초안은 AI가, 최종 검토/확정은 사람이
실제 코드 구현	AI 위임	반복적 타이핑, 보일러플레이트는 AI가 빠르고 정확
코드 리뷰/검증	사람	설계 의도와 부합하는지는 결국 사람이 판단

즉, "생각은 내가 하고, 타이핑은 AI가 한다"는 구도를 명확히 하는 것이 중요합니다. 다음 장부터는 이 원칙을 실제로 어떻게 실행하는지 단계별로 다룹니다.

11장. 요구사항 분석하기

이 장부터는 하나의 예제 프로젝트를 끝까지 일관되게 사용해 설명합니다.

예제 프로젝트: "팀 할 일 관리 서비스" — Frontend: Vue.js 3, Backend: Spring Boot 3 (Java/Kotlin), DB: PostgreSQL

요구사항 분석은 "AI에게 무엇을 시킬지"를 정하는 단계가 아니라, "내가 무엇을 원하는지 스스로 명확히 하는" 단계입니다. 로컬 LLM은 클라우드 최상위 모델보다 모호함을 스스로 메우는 능력이 떨어지기 때문에, 이 단계를 충실히 거칠수록 이후 바이브 코딩 단계의 성공률이 크게 올라갑니다.

11.1 요구사항 분석의 전체 절차

1. 배경/목적 정의        → 왜 이 프로젝트를 만드는가
2. 이해관계자와 사용자 정의 → 누가 쓰는가
3. 기능 요구사항 도출     → 무엇을 할 수 있어야 하는가
4. 비기능 요구사항 도출   → 어떤 품질/제약을 만족해야 하는가
5. 사용자 스토리 작성     → 기능을 사용자 관점 문장으로 구체화
6. 유스케이스 상세화      → 각 스토리의 정상/예외 흐름 정의
7. 우선순위 및 범위(MVP) 확정 → 무엇을 먼저 만들 것인가
8. Cline과 Plan 모드로 교차 검증 → 빠진 부분/모순 점검

이 절차는 대규모 프로젝트에서 쓰는 정식 요구공학 프로세스를 개인/소규모 팀 바이브 코딩에 맞게 축약한 것입니다. 프로젝트 규모가 작다고 해서 1~2단계를 건너뛰면, 결국 코딩 단계에서 "이게 아닌데" 하는 재작업으로 시간을 더 많이 쓰게 됩니다.

11.2 배경/목적 정의

가장 먼저, 이 프로젝트가 왜 필요한지 한두 문단으로 정리합니다. 이는 이후 AI에게 프로젝트 맥락을 설명할 때 그대로 재사용됩니다.

## 프로젝트 배경

현재 팀은 할 일 관리를 채팅과 스프레드시트로 병행하고 있어 진행 상황 파악이 어렵다.
팀원 5명 내외의 소규모 조직이 사용할 수 있는, 가볍고 빠른 웹 기반 할 일 관리
서비스를 자체 구축하여 사내 인프라(PostgreSQL)에 직접 데이터를 적재하고자 한다.

11.3 이해관계자와 사용자 정의

## 이해관계자
- 최종 사용자: 팀원 (할 일 등록/조회/완료 처리)
- 관리자: 팀 리더 (팀원 배정, 전체 현황 조회)

## 사용자 유형별 권한
| 역할 | 권한 |
|---|---|
| 팀원 | 본인에게 배정된 할 일 조회/완료 처리, 새 할 일 생성 |
| 팀 리더 | 팀원 권한 + 할 일 배정, 전체 통계 조회, 팀원 관리 |

사용자 유형을 명확히 나누어두면, 이후 Spring Boot의 인증/인가(Spring Security) 설계와 Vue.js의 화면별 접근 제어를 정의할 때 근거가 됩니다.

11.4 기능 요구사항 도출

기능 요구사항은 "시스템이 무엇을 할 수 있어야 하는가" 를 동사 중심으로 나열합니다. 화면 단위가 아니라 행위(액션) 단위로 쪼개는 것이 이후 API 설계와 자연스럽게 연결됩니다.

## 기능 요구사항 (FR)

FR-1. 사용자는 이메일/비밀번호로 로그인할 수 있다.
FR-2. 사용자는 할 일을 생성할 수 있다 (제목, 설명, 마감일, 담당자, 태그).
FR-3. 사용자는 본인에게 배정된 할 일 목록을 조회할 수 있다.
FR-4. 사용자는 할 일을 마감일/생성일/우선순위 기준으로 정렬해서 볼 수 있다.
FR-5. 사용자는 할 일을 완료 처리하거나 완료를 취소할 수 있다.
FR-6. 팀 리더는 할 일을 다른 팀원에게 재배정할 수 있다.
FR-7. 팀 리더는 팀 전체의 완료율 통계를 조회할 수 있다.
FR-8. 사용자는 할 일에 댓글을 남길 수 있다.

각 항목에 ID(FR-1, FR-2...) 를 붙이는 것을 권장합니다. 이후 설계 문서, API 스펙, 커밋 메시지, Cline 지시문에서 "FR-3 구현해줘" 처럼 참조할 수 있어 추적성이 크게 좋아집니다.

11.5 비기능 요구사항 도출

비기능 요구사항은 "얼마나 잘 해야 하는가"를 규정합니다. 아래 카테고리를 체크리스트처럼 훑으며 빠짐없이 정리하는 것을 권장합니다.

## 비기능 요구사항 (NFR)

### 성능
NFR-1. 할 일 목록 조회 API는 평균 응답 200ms 이내 (팀원 수 50명, 할 일 1만 건 기준)

### 보안
NFR-2. 비밀번호는 BCrypt로 해시하여 저장 (평문 저장 금지)
NFR-3. 팀원은 다른 팀원의 할 일을 조회/수정할 수 없다 (본인 배정 건 제외 접근 차단)

### 가용성/운영
NFR-4. 별도 이중화 없이 단일 서버로 운영 (사내 소규모 팀 대상이므로 고가용성 불필요)
NFR-5. DB는 PostgreSQL 15 이상, 매일 새벽 자동 백업

### 유지보수성
NFR-6. Backend는 Spring Boot 레이어드 아키텍처(Controller-Service-Repository)를 따른다
NFR-7. Frontend는 Vue 3 Composition API + TypeScript로 작성한다

### 호환성
NFR-8. 최신 Chrome/Edge 기준으로 동작 (IE 등 구형 브라우저 지원 불필요)

기능 요구사항과 비기능 요구사항을 분리해서 정리하면, "빨리 만드는 것"과 "잘 만드는 것" 사이에서 이번 프로젝트가 어디에 방점을 두는지 팀 내에서도, AI에게 지시할 때도 명확해집니다.

11.6 사용자 스토리 작성법

기능 요구사항을 사용자 관점 문장으로 한 번 더 구체화합니다. 아래 템플릿을 사용합니다.

As a [사용자 유형]
I want to [하고 싶은 행동]
So that [얻고자 하는 가치]

Acceptance Criteria (인수 조건):
- [ ] 조건 1
- [ ] 조건 2

예시:

## US-3 (FR-3 대응)

As a 팀원
I want to 나에게 배정된 할 일 목록을 확인
So that 오늘 무엇을 해야 하는지 파악할 수 있다

### Acceptance Criteria
- [ ] 로그인한 사용자에게 배정된 할 일만 표시된다
- [ ] 완료된 항목과 미완료 항목이 구분되어 표시된다
- [ ] 목록이 비어 있으면 "배정된 할 일이 없습니다" 안내 문구가 표시된다

인수 조건(Acceptance Criteria) 을 함께 적어두는 것이 핵심입니다. 이것이 나중에 14장의 "구현 결과 검증" 단계에서 그대로 체크리스트로 쓰이고, 테스트 코드 작성의 근거가 됩니다.

11.7 유스케이스 상세화 (정상 흐름 + 예외 흐름)

여러 단계를 거치는 복잡한 기능은 유스케이스로 한 단계 더 구체화합니다. 특히 예외 흐름을 명시하는 것이 중요합니다 — 이 부분이 빠지면 AI가 예외 처리를 임의로 (혹은 아예 하지 않고) 구현하게 됩니다.

## UC-6: 할 일 재배정 (FR-6 대응)

**주 액터**: 팀 리더
**사전 조건**: 로그인 상태, 대상 할 일이 존재함

### 정상 흐름
1. 팀 리더가 할 일 목록에서 특정 항목의 "재배정" 버튼 클릭
2. 시스템이 재배정 가능한 팀원 목록을 표시
3. 팀 리더가 새 담당자를 선택하고 확인
4. 시스템이 담당자를 변경하고, 변경 이력을 기록
5. 새 담당자에게 알림 (v1에서는 화면 표시만, 이메일 알림은 범위 제외)

### 예외 흐름
- E1. 팀원 권한으로 재배정 시도 → 403 Forbidden 응답, "권한이 없습니다" 안내
- E2. 존재하지 않는 할 일 ID로 요청 → 404 Not Found 응답
- E3. 이미 완료된 할 일 재배정 시도 → 재배정은 허용하되 경고 메시지 표시 (차단하지 않음)

11.8 우선순위 및 범위(MVP) 확정

모든 기능을 한 번에 구현하려 하지 말고, 최소 기능 제품(MVP) 범위를 먼저 확정합니다. MoSCoW 기법(Must/Should/Could/Won't)을 활용하면 편리합니다.

## 범위 확정 (MoSCoW)

### Must (MVP 필수)
- FR-1 로그인, FR-2 할 일 생성, FR-3 목록 조회, FR-5 완료 처리

### Should (MVP 이후 우선)
- FR-4 정렬, FR-6 재배정

### Could (여유 있으면)
- FR-7 통계, FR-8 댓글

### Won't (이번 범위 제외)
- 이메일/푸시 알림
- 모바일 앱 (반응형 웹으로 대응)

이렇게 범위를 나눠두면, 14장의 Task 분해와 25장의 실전 예제에서 "Must 항목부터 순서대로 구현"하는 흐름이 자연스럽게 이어집니다.

11.9 Cline과 함께 Plan 모드로 요구사항 교차 검증

요구사항 초안(11.4~11.8절 산출물)이 준비되면, Cline의 Plan 모드로 빠진 부분이나 모순을 점검받습니다. Plan 모드는 파일을 수정하지 않으므로 이 단계에 적합합니다.

[Plan 모드 프롬프트 예시]
아래는 "팀 할 일 관리 서비스"의 기능/비기능 요구사항과 유스케이스 초안이야.
Spring Boot + PostgreSQL 백엔드, Vue.js 프론트엔드로 구현할 예정이야.
빠진 요구사항, 서로 모순되는 부분, 애매한 표현이 있으면 질문 형태로 알려줘.
아직 코드나 설계 문서는 작성하지 마.

[요구사항 문서 붙여넣기 또는 @docs/PRD.md 첨부]

이 단계에서 로컬 모델이 "재배정 시 이전 담당자에게도 알림이 필요한가요?", "완료 취소는 몇 번까지 가능한가요?" 같은 질문을 던지면, 사람이 그 자리에서 답을 정해 요구사항 문서에 즉시 반영합니다. 이렇게 하면 실제 구현 단계에서 이런 질문에 AI가 임의로 답을 추측해 엉뚱하게 구현하는 상황을 미리 막을 수 있습니다.

12장. 설계 문서화하기

요구사항이 "무엇을 만들 것인가"라면, 설계는 "어떻게 만들 것인가" 입니다. 이 장에서는 Vue.js / Spring Boot / PostgreSQL 스택을 기준으로 설계 문서를 어떻게 구체적으로 작성하는지 다룹니다.

12.1 아키텍처 개요 작성

전체 시스템 구성도

계층별 책임 정의

## 아키텍처 개요

### Frontend (Vue.js 3)
- Composition API + TypeScript + Pinia(상태 관리) + Vue Router
- Axios로 Backend REST API 호출
- 화면(View) - 컴포넌트(Component) - 스토어(Store) - API 클라이언트 계층 분리

### Backend (Spring Boot 3)
- 레이어드 아키텍처: Controller → Service → Repository → Entity
- 인증: Spring Security + JWT
- ORM: Spring Data JPA (Hibernate)
- 빌드 도구: Gradle

### DB (PostgreSQL 15)
- Backend와 동일 서버 내 Docker Compose로 구성 (로컬/개발 환경 기준)
- 마이그레이션 관리: Flyway

폴더 구조

## 폴더 구조

### Backend (Spring Boot)
backend/
+-- src/main/java/com/example/todoapp/
|   +-- controller/       # REST 컨트롤러 (@RestController)
|   +-- service/          # 비즈니스 로직
|   +-- repository/       # Spring Data JPA 리포지토리
|   +-- entity/           # JPA 엔티티
|   +-- dto/              # 요청/응답 DTO
|   +-- config/           # Security, CORS 등 설정
|   `-- exception/        # 예외 처리 (@ControllerAdvice)
+-- src/main/resources/
|   +-- application.yml
|   `-- db/migration/     # Flyway 마이그레이션 SQL
`-- src/test/java/...     # JUnit 5 테스트

### Frontend (Vue.js)
frontend/
+-- src/
|   +-- views/            # 라우트 단위 화면
|   +-- components/       # 재사용 컴포넌트
|   +-- stores/           # Pinia 스토어
|   +-- api/              # Axios 기반 API 클라이언트
|   +-- router/           # Vue Router 설정
|   `-- types/            # TypeScript 타입 정의
`-- tests/                # Vitest 테스트

### 공통 설계 문서
docs/
+-- PRD.md
+-- ARCHITECTURE.md
+-- API_SPEC.md
`-- DATA_MODEL.md

이 폴더 구조를 docs/ARCHITECTURE.md에 그대로 저장해두면, 이후 Cline에게 "이 구조를 따라 파일을 생성해줘"라고 지시할 수 있어 파일 위치가 임의로 뒤섞이는 것을 방지합니다.

12.2 API/인터페이스 스펙 먼저 정의하기

Frontend(Vue.js)와 Backend(Spring Boot)를 각각 다른 세션에서, 혹은 다른 사람이 작업하더라도 서로 어긋나지 않도록 API 스펙을 코드 작성 전에 먼저 확정합니다.

## API 스펙 (docs/API_SPEC.md)

### 인증
POST /api/auth/login
Request: { "email": string, "password": string }
Response: { "accessToken": string, "expiresIn": number }
Error:    401 { "message": "이메일 또는 비밀번호가 올바르지 않습니다" }

### 할 일 (Todo)
POST /api/todos
Request: { "title": string, "description": string?, "dueDate": string (ISO 8601)?, "assigneeId": number, "tags": string[]? }
Response: 201 { "id": number, "title": string, "dueDate": string, "completed": boolean, "assigneeId": number }
Error:    400 (필수값 누락), 403 (권한 없음)

GET /api/todos?sort=dueDate&order=asc&assigneeId={id}
Response: 200 [{ "id": number, "title": string, "dueDate": string, "completed": boolean, ... }]

PATCH /api/todos/{id}/complete
Response: 200 { "id": number, "completed": true }
Error:    404 (존재하지 않는 ID), 403 (본인 배정 건이 아님)

PATCH /api/todos/{id}/reassign
Request: { "newAssigneeId": number }
Response: 200 { "id": number, "assigneeId": number }
Error:    403 (팀 리더 권한 아님)

### 공통 에러 응답 형식
{
"timestamp": string,
"status": number,
"message": string,
"path": string
}

API 스펙 작성 시 반드시 포함할 항목


요청/응답 필드명과 타입	Frontend TypeScript 타입, Backend DTO가 여기서 파생됨
성공/실패 상태 코드	Spring Boot의 @ExceptionHandler 설계 근거
에러 응답 형식	프론트/백엔드가 공통으로 처리할 수 있도록 통일
페이지네이션/정렬 규칙	목록 API는 항상 이 부분에서 요구사항이 누락되기 쉬움
인증 방식 (헤더, 토큰 형식)	Authorization: Bearer {token} 등 명시

필드명 규칙(camelCase vs snake_case)도 이 시점에 명확히 정해두는 것을 권장합니다. Spring Boot는 관례적으로 JSON 필드에 camelCase(dueDate)를 사용하고, PostgreSQL 컬럼은 snake_case(due_date)를 사용하는 경우가 많은데, 이 매핑 규칙(JPA @Column(name = "due_date") 등)을 ARCHITECTURE.md에 미리 적어두면 AI가 임의로 다른 규칙을 쓰는 것을 방지할 수 있습니다.

12.3 DB 스키마 / 데이터 모델 설계

PostgreSQL 기준으로 테이블 정의와 관계를 먼저 문서화합니다.

## 데이터 모델 (docs/DATA_MODEL.md)

### users 테이블
| 컬럼 | 타입 | 제약 |
|---|---|---|
| id | BIGSERIAL | PRIMARY KEY |
| email | VARCHAR(255) | UNIQUE, NOT NULL |
| password_hash | VARCHAR(255) | NOT NULL |
| name | VARCHAR(100) | NOT NULL |
| role | VARCHAR(20) | NOT NULL, CHECK (role IN ('MEMBER', 'LEADER')) |
| created_at | TIMESTAMP | NOT NULL DEFAULT now() |

### todos 테이블
| 컬럼 | 타입 | 제약 |
|---|---|---|
| id | BIGSERIAL | PRIMARY KEY |
| title | VARCHAR(255) | NOT NULL |
| description | TEXT | NULL 허용 |
| due_date | TIMESTAMP | NULL 허용 |
| completed | BOOLEAN | NOT NULL DEFAULT false |
| assignee_id | BIGINT | FOREIGN KEY → users(id) |
| created_at | TIMESTAMP | NOT NULL DEFAULT now() |

### todo_tags 테이블 (다대다 관계)
| 컬럼 | 타입 | 제약 |
|---|---|---|
| todo_id | BIGINT | FOREIGN KEY → todos(id) |
| tag_name | VARCHAR(50) | NOT NULL |

### ERD (관계 요약)
- users (1) ─── (N) todos [assignee_id]
- todos (1) ─── (N) todo_tags

ERD를 mermaid로도 함께 표현

erDiagram
    USERS ||--o{ TODOS : "assigned"
    TODOS ||--o{ TODO_TAGS : "has"
    USERS {
        bigint id PK
        varchar email
        varchar role
    }
    TODOS {
        bigint id PK
        varchar title
        timestamp due_date
        boolean completed
        bigint assignee_id FK
    }
    TODO_TAGS {
        bigint todo_id FK
        varchar tag_name
    }

이 정의를 그대로 Flyway 마이그레이션 SQL(db/migration/V1__init.sql)로 옮기면, Spring Boot의 JPA 엔티티(@Entity)와 스키마가 어긋나지 않게 관리할 수 있습니다. 이 문서를 Cline에게 첨부하고 "이 스키마 기준으로 Flyway 마이그레이션 파일과 JPA 엔티티를 작성해줘"라고 지시하는 흐름이 13.4절과 14장에서 이어집니다.

12.4 화면/컴포넌트 설계 (Vue.js 기준 추가 항목)

Backend API 스펙만 정의하고 끝내지 않고, Frontend가 있는 프로젝트라면 화면 단위 설계도 함께 정리해두는 것을 권장합니다.

## 화면 설계 (docs/ARCHITECTURE.md 내 섹션)

### 화면 목록 (Vue Router)
| 경로 | 컴포넌트 | 설명 | 접근 권한 |
|---|---|---|---|
| /login | LoginView.vue | 로그인 화면 | 비로그인 |
| /todos | TodoListView.vue | 내 할 일 목록 | 로그인 필요 |
| /todos/:id | TodoDetailView.vue | 할 일 상세/댓글 | 로그인 필요 |
| /admin | AdminDashboardView.vue | 팀 통계 (FR-7) | 팀 리더만 |

### 상태 관리 (Pinia 스토어 구조)
- authStore: 로그인 상태, accessToken, 현재 사용자 정보
- todoStore: 할 일 목록, 필터/정렬 상태, CRUD 액션

### 컴포넌트 재사용 원칙
- TodoItem.vue: 목록/상세 화면에서 공통 사용
- 폼 검증은 각 View에서 처리, 공통 검증 로직은 composables/ 폴더로 분리

이렇게 화면/상태 설계까지 문서화해두면, Cline에게 "TodoListView.vue를 만들어줘"라고 지시했을 때 어떤 스토어를 참조하고 어떤 컴포넌트를 재사용해야 하는지 AI가 임의로 판단하지 않고 문서를 따르게 할 수 있습니다.

12.5 간단한 다이어그램 활용 (시퀀스 다이어그램)

여러 계층에 걸친 흐름(예: 로그인 → JWT 발급 → 이후 요청 인증)은 시퀀스 다이어그램으로 표현해두면 Backend 인증 설계를 구현할 때 참고하기 좋습니다.

sequenceDiagram
    participant V as Vue.js
    participant S as Spring Boot
    participant P as PostgreSQL

    V->>S: POST /api/auth/login (email, password)
    S->>P: SELECT * FROM users WHERE email = ?
    P-->>S: 사용자 정보 반환
    S->>S: BCrypt 비밀번호 검증 + JWT 생성
    S-->>V: accessToken 반환
    V->>S: GET /api/todos (Authorization: Bearer {token})
    S->>S: JWT 검증 (Spring Security Filter)
    S->>P: SELECT * FROM todos WHERE assignee_id = ?
    P-->>S: 할 일 목록 반환
    S-->>V: JSON 응답

다이어그램은 정교할 필요 없이, "이 프로젝트의 각 계층이 어떤 순서로 상호작용하는지"를 AI와 사람이 동시에 빠르게 파악할 수 있는 수준이면 충분합니다.

12.6 설계 문서 작성 시 Cline 활용 팁

설계 문서 초안을 처음부터 사람이 전부 작성할 필요는 없습니다. 요구사항 문서(11장 산출물)를 Cline에게 제공하고 초안 작성을 맡긴 뒤, 사람이 검토/수정하는 방식이 효율적입니다.

[Plan 모드 프롬프트 예시]
@docs/PRD.md
이 요구사항을 기준으로 Spring Boot + PostgreSQL + Vue.js 스택에 맞는
아키텍처 개요, API 스펙, DB 스키마 초안을 각각 작성해줘.
파일은 아직 만들지 말고, 이 대화창에 마크다운으로 먼저 보여줘.

초안을 확인한 뒤 사람이 수정할 부분을 지시하고, 최종 확정된 내용만 13장의 방법으로 docs/ 파일에 저장합니다. 초안은 AI, 확정은 사람이라는 원칙(10.2절)을 이 단계에서도 그대로 지킵니다.

13장. 분석/설계 산출물을 프로젝트에 반영하는 방법

앞서 정리한 요구사항/설계 문서는 파일로 저장하지 않으면 대화가 끝나는 순간 사라집니다. 이를 프로젝트에 지속적으로 반영하는 것이 이 장의 핵심입니다.

13.1 `docs/` 폴더에 설계 문서를 파일로 저장하기

project/
`-- docs/
    +-- PRD.md              # 제품 요구사항 문서 (배경, FR/NFR, 사용자 스토리, MVP 범위)
    +-- ARCHITECTURE.md      # 아키텍처 개요, 폴더 구조, 화면/컴포넌트 설계
    +-- API_SPEC.md          # API 스펙
    `-- DATA_MODEL.md        # DB 스키마, ERD

이렇게 파일로 저장해두면, 이후 어떤 대화 세션에서든 "docs/ARCHITECTURE.md 참고해서 작업해줘"라고 지시할 수 있어 일관성이 유지됩니다.

13.2 `.clinerules`로 프로젝트 규칙/컨벤션 인식시키기

Cline은 프로젝트 루트에 .clinerules 파일(또는 .clinerules/ 폴더)이 있으면 이를 매 요청마다 자동으로 시스템 프롬프트에 포함시킵니다. 코딩 컨벤션, 금지 사항 등을 여기에 명시해두면 매번 반복 설명할 필요가 없습니다.

# .clinerules

## 코딩 컨벤션 (Backend - Spring Boot)
- 컨트롤러는 얇게 유지하고, 비즈니스 로직은 Service 레이어에 작성
- DTO와 Entity를 분리할 것 (Entity를 직접 API 응답으로 반환하지 않기)
- 모든 API 응답은 docs/API_SPEC.md의 형식을 따를 것
- 커밋 전 반드시 `./gradlew test` 실행 결과 확인

## 코딩 컨벤션 (Frontend - Vue.js)
- Composition API + `<script setup lang="ts">` 형식 사용 (Options API 금지)
- API 호출은 반드시 src/api/ 폴더의 클라이언트를 통해서만 수행
- 컴포넌트 props/emit은 TypeScript 타입으로 명시

## DB 관련
- 스키마 변경은 반드시 Flyway 마이그레이션 파일로 작성 (JPA auto-ddl 금지)
- 컬럼명은 snake_case, JSON 필드명은 camelCase (docs/API_SPEC.md 참고)

## 금지 사항
- application.yml의 DB 접속 정보를 임의로 변경하지 말 것
- .env 및 application-secret.yml 내용을 출력하거나 수정하지 말 것

13.3 Memory Bank 패턴

Cline 커뮤니티에서 널리 쓰이는 방식으로, 프로젝트의 맥락을 여러 마크다운 파일로 나누어 유지하며 세션이 바뀌어도 컨텍스트가 이어지도록 하는 패턴입니다. 로컬 모델처럼 컨텍스트 창이 상대적으로 짧은 환경에서는 이 패턴이 특히 유용합니다 (한 번에 모든 내용을 다 넣지 않고, 필요한 파일만 골라 참조시킬 수 있기 때문).

project/
`-- memory-bank/
    +-- productContext.md   # 이 프로젝트가 왜 존재하는지, 무엇을 하는지
    +-- activeContext.md     # 지금 작업 중인 내용, 최근 결정 사항
    `-- progress.md          # 완료된 작업, 남은 작업 목록

activeContext.md 예시:

# Active Context

## 현재 작업
할 일 완료 처리 API(`PATCH /api/todos/{id}/complete`) Backend 구현 중

## 최근 결정 사항
- 완료된 할 일은 삭제하지 않고 completed 플래그만 변경하기로 결정 (2026-07-05)
- 재배정된 할 일도 완료 처리는 차단하지 않고 경고만 표시 (UC-6 E3 참고, 2026-07-06)
- DB 컬럼은 snake_case, API JSON은 camelCase — JPA @Column(name=...)으로 매핑

이 파일들은 작업이 진행되면서 사람 또는 Cline이 계속 업데이트합니다. 새로운 세션을 시작할 때 "memory-bank/ 폴더를 먼저 읽고 시작해줘"라고 지시하면, 로컬 모델이 매번 전체 코드베이스를 처음부터 파악하지 않고도 맥락을 빠르게 회복할 수 있습니다.

13.4 Plan 모드에서 설계 문서 참조시키기

Cline은 @ 기호로 특정 파일을 대화에 직접 첨부할 수 있습니다.

@docs/ARCHITECTURE.md @docs/API_SPEC.md @docs/DATA_MODEL.md
이 설계를 기준으로 Spring Boot의 Todo 엔티티, 리포지토리, 컨트롤러를 작성해줘.

이렇게 명시적으로 문서를 첨부하면, 모델이 임의로 추측하는 대신 문서에 정의된 스펙을 그대로 따르도록 유도할 수 있습니다.

13.5 짧은 컨텍스트 한계 고려한 문서 발췌 전략

로컬 모델(특히 32K 컨텍스트로 운영 중인 30B급 모델)은 모든 설계 문서를 매번 통째로 넣으면 컨텍스트를 금방 소진합니다. 다음 전략을 권장합니다.

● 작업 단위(Task)별로 관련된 문서만 선택적으로 첨부 (Backend API 작업 시 API_SPEC.md+DATA_MODEL.md만, Frontend 화면 작업 시 ARCHITECTURE.md의 화면 설계 섹션만)

● 설계 문서 자체를 too long하게 만들지 않기 — 섹션을 나누어 여러 개의 짧은 파일로 관리 (예: API_SPEC.md가 너무 길어지면 API_SPEC_AUTH.md, API_SPEC_TODO.md로 분리)

● memory-bank/activeContext.md처럼 "지금 당장 필요한 요약"과 "전체 설계 문서"를 분리해서, 평소에는 요약본만 참조하고 필요할 때만 전체 문서를 열어보기

14장. 설계 → 구현 → 검증 루프

14.1 설계 문서 기준 Task 단위 쪼개기

설계 문서가 준비되었다면, 이를 한 번에 다 구현하도록 지시하기보다 작은 Task 단위로 쪼개어 순차적으로 진행하는 것이 안정적입니다. 11.8절에서 정한 MVP(Must) 범위부터 순서대로 진행합니다.

## Task 목록 (예시 - MVP 범위)

### Backend
- [ ] Task 1: Flyway 마이그레이션으로 users/todos/todo_tags 테이블 생성
- [ ] Task 2: User, Todo JPA 엔티티 및 Repository 작성
- [ ] Task 3: Spring Security + JWT 로그인 구현 (FR-1)
- [ ] Task 4: POST /api/todos 엔드포인트 구현 (FR-2)
- [ ] Task 5: GET /api/todos 엔드포인트 구현 (FR-3, FR-4 정렬 포함)
- [ ] Task 6: PATCH /api/todos/{id}/complete 엔드포인트 구현 (FR-5)

### Frontend
- [ ] Task 7: LoginView.vue + authStore 구현
- [ ] Task 8: TodoListView.vue + todoStore 구현
- [ ] Task 9: 할 일 생성 폼 컴포넌트 구현
- [ ] Task 10: 완료 처리 버튼 및 API 연동

Task를 잘게 쪼갤수록 한 번의 요청에 필요한 컨텍스트가 줄어들어, 로컬 모델의 짧은 컨텍스트 한계에도 안정적으로 대응할 수 있습니다.

14.2 구현 결과와 설계 일치 여부 검토

각 Task가 끝날 때마다, 다음을 확인합니다.

● 생성/수정된 코드가 API_SPEC.md에 정의한 요청/응답 형식과 일치하는가 (필드명 camelCase 등)

● .clinerules에 정의한 컨벤션(레이어 분리, DTO/Entity 분리 등)을 지켰는가

● 11.6절에서 작성한 인수 조건(Acceptance Criteria) 을 모두 만족하는가

● 다른 Task에서 만든 코드(Backend API ↔ Frontend 호출부)와 인터페이스가 충돌하지 않는가

[검토 프롬프트 예시]
방금 만든 GET /api/todos 응답을 docs/API_SPEC.md와 비교해서
필드명, 타입, 정렬 파라미터가 스펙과 정확히 일치하는지 확인해줘.

14.3 설계와 어긋난 구현 되돌리기 (문서 우선 원칙)

만약 AI가 설계 문서와 다르게 구현했다면(예: 응답 필드명이 스펙과 다름), 코드를 문서에 맞춰 고치는 것을 기본 원칙으로 삼습니다. 예외적으로 구현 과정에서 설계 자체의 허점이 발견된 경우에만, 문서를 먼저 수정한 뒤 코드를 그에 맞춰 다시 조정합니다. 이 순서(문서 수정 → 코드 반영)를 지켜야 문서와 코드가 서로 어긋나는 것을 방지할 수 있습니다.

[지시 예시]
방금 만든 응답 형식이 docs/API_SPEC.md와 다르네.
스펙에는 "dueDate"인데 코드 DTO에는 "due_date"로 되어 있어.
스펙(camelCase) 기준으로 DTO를 수정해줘.

14.4 구현 중 설계 문서 업데이트 ("살아있는 문서")

설계 문서는 한 번 작성하고 끝나는 것이 아니라, 구현하면서 드러나는 세부사항을 반영해 계속 업데이트하는 "살아있는 문서(living document)"로 관리해야 합니다.

[지시 예시]
방금 재배정 기능을 구현하면서 "완료된 할 일도 재배정은 허용하되 경고 표시"라는
규칙을 코드로 확정했어. 이 내용을 docs/API_SPEC.md와
memory-bank/activeContext.md에 반영해줘.

이렇게 문서를 계속 최신 상태로 유지하면, 다음 세션이나 다른 작업자가 프로젝트에 합류했을 때도(혹은 컨텍스트가 리셋된 새 대화에서도) 프로젝트의 현재 상태를 빠르게 파악할 수 있습니다.

로컬 LLM + Cline 바이브 코딩 가이드 - 3부. 설치 및 설정

환영전사 — Tue, 7 Jul 2026 17:04:38 +0900

7장. vLLM 설치 및 서버 실행 — 5090 환경 기준

7.1 설치 환경 준비

OS 선택

RTX 5090은 Windows 네이티브 환경에서 WDDM(Windows Display Driver Model) 반가상화를 통한 GPU 연산 시 복구 불가능한 행(hang) 현상이 보고된 알려진 이슈가 있습니다. 실제 커뮤니티 벤치마크도 대부분 WSL2 Ubuntu 24.04 환경에서 진행되고 있습니다.

→ WSL2(Ubuntu 24.04) 또는 네이티브 Linux(Ubuntu 22.04/24.04) 사용을 강력히 권장합니다.

WSL2 설치 (Windows 사용자):

# PowerShell (관리자 권한)에서 실행
wsl --install -d Ubuntu-24.04

설치 후 WSL2 내에서 NVIDIA 드라이버는 Windows 호스트의 드라이버를 그대로 사용하므로, WSL2 안에 별도로 그래픽 드라이버를 설치할 필요는 없습니다. 다만 최신 Windows용 NVIDIA 드라이버(Blackwell 지원 버전)가 설치되어 있어야 합니다.

드라이버 및 CUDA 확인

nvidia-smi
nvidia-smi --query-gpu=driver_version,name --format=csv

nvidia-smi 출력 상단에 표시되는 CUDA Version이 12.8 이상인지 확인하세요. 그 이하라면 NVIDIA 드라이버를 최신 버전으로 업데이트해야 합니다.

Python 환경 준비

sudo apt update
sudo apt install -y python3.12 python3.12-venv python3-pip

python3.12 -m venv ~/vllm-env
source ~/vllm-env/bin/activate

vLLM + PyTorch(cu128) 설치

기본 pip install vllm 명령은 환경에 따라 구버전 CUDA(cu126 등)가 딸린 PyTorch를 함께 설치할 수 있어, RTX 5090에서 동작하지 않을 수 있습니다. cu128을 명시적으로 지정합니다.

pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu128
pip install "vllm>=0.17.0"

설치 직후 GPU 인식 여부를 반드시 확인하세요.

python3 -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True와 함께 NVIDIA GeForce RTX 5090이 출력되어야 정상입니다. sm_120 is not compatible 관련 오류가 나온다면 6부 23장의 트러블슈팅을 참고하세요.

7.2 Docker로 vLLM 실행 (권장 방식)

docker run --gpus all \
--ipc=host \
--ulimit memlock=-1 \
--ulimit stack=67108864 \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
vllm/vllm-openai:latest \
--model Qwen/Qwen2.5-Coder-32B-Instruct-AWQ \
--max-model-len 32768 \
--gpu-memory-utilization 0.9 \
--quantization awq \
--enable-auto-tool-choice \
--tool-call-parser hermes

Docker 이미지 태그는 Blackwell 지원이 포함된 최신 버전인지 반드시 확인하세요. 이미지가 오래된 경우 sm_120 미인식 문제가 컨테이너 안에서도 동일하게 발생합니다.

7.3 모델 다운로드 및 서버 기동

pip install huggingface_hub
huggingface-cli download Qwen/Qwen2.5-Coder-32B-Instruct-AWQ

vllm serve Qwen/Qwen2.5-Coder-32B-Instruct-AWQ \
--max-model-len 32768 \
--gpu-memory-utilization 0.9 \
--quantization awq \
--enable-auto-tool-choice \
--tool-call-parser hermes \
--port 8000

2부 6.1절에서 메인으로 추천한 Qwen3-Coder-30B-A3B-Instruct를 사용하려면, 위 명령의 --model 값을 해당 모델의 vLLM 호환 체크포인트(AWQ/FP8 등) 경로로 바꾸면 됩니다. MoE 모델이므로 --quantization 값도 실제 다운로드한 체크포인트의 양자화 방식에 맞춰 조정하세요. 명령어 구조와 나머지 옵션(--enable-auto-tool-choice, --tool-call-parser 등)은 동일하게 적용됩니다.

주요 옵션:


--model	Hugging Face 모델 경로 또는 로컬 경로
--max-model-len	최대 컨텍스트 길이
--gpu-memory-utilization	VRAM 사용 비율 (0~1, 기본 0.9 권장, OOM 시 낮추기)
--quantization	양자화 방식 (awq, gptq, fp8 등)
--enable-auto-tool-choice	tool calling 자동 활성화 (Cline 연동 필수)
--tool-call-parser	모델별 tool call 파싱 형식 (hermes, mistral 등)

서버 정상 기동 시 로그:

INFO: Started server process
INFO: Uvicorn running on http://0.0.0.0:8000

7.4 OpenAI 호환 API 엔드포인트 확인

정상적으로 JSON 응답(코드 포함)이 오면 서버 설정은 완료된 것입니다.

7.5 Tool calling 지원 확인

Cline은 파일 수정, 명령 실행 등을 function calling(tool call) 형식으로 모델에 요청합니다. 이 부분이 맞지 않으면 Cline의 핵심 동작(파일 수정, 명령 실행)이 실패합니다.

curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
    "model": "Qwen/Qwen2.5-Coder-32B-Instruct-AWQ",
    "messages": [{"role": "user", "content": "현재 디렉토리 파일 목록을 보여줘"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "list_files",
        "description": "디렉토리 내 파일 목록 반환",
        "parameters": {"type": "object", "properties": {"path": {"type": "string"}}}
      }
    }]
}'

응답에 tool_calls 필드가 포함되어 있는지 확인하세요. 포함되어 있지 않다면 --tool-call-parser 값이 사용 중인 모델과 맞지 않을 가능성이 큽니다. 모델의 Hugging Face 카드에서 권장 tool-call-parser 값을 확인하세요.

8장. IDE 선택 및 설치

8.1 VS Code + Cline 설치

- VS Code → Extensions(확장) → Cline 검색 후 설치

- 설치 후 사이드바 Cline 아이콘 클릭 → 사이드 패널 오픈

- 최초 실행 시 API Provider 설정 화면 표시 (9장에서 설정)

8.2 IntelliJ + Cline 설치

- IntelliJ IDEA(또는 WebStorm, PyCharm 등) → Settings/Preferences → Plugins

- Marketplace 탭에서 Cline 검색 후 설치

- IDE 재시작 → 툴 윈도우에 Cline 패널 추가됨

JetBrains 계열 IDE는 동일한 플러그인 코어를 공유하므로 설치 방법은 어떤 제품이든 동일합니다.

8.3 두 IDE 중 선택 기준


자바/코틀린/스프링 기반 백엔드	IntelliJ IDEA
웹 프론트엔드(Vue.js), Node.js	VS Code
Python 위주 작업	VS Code 또는 PyCharm
기존 워크플로우 유지	기존 IDE 유지

Cline의 핵심 기능은 두 IDE에서 동일하게 동작하므로, 평소 사용 언어/프레임워크와의 궁합을 기준으로 선택하는 것이 합리적입니다.

9장. Cline과 vLLM 서버 연결하기

9.1 VS Code에서 연결 설정

- Cline 패널 → 설정(톱니바퀴) 클릭

- API Provider: OpenAI Compatible 선택

- Base URL: http://localhost:8000/v1

- API Key: 임의 문자열 입력 (예: not-needed)

- Model ID: vLLM에 로드한 모델명과 정확히 일치 (예: Qwen/Qwen2.5-Coder-32B-Instruct-AWQ)

- 저장 후 간단한 질문으로 연결 테스트

9.2 IntelliJ에서 연결 설정

- Cline 툴 윈도우 → 설정 아이콘 클릭

- 동일하게 OpenAI Compatible Provider 선택

- Base URL, API Key, Model ID는 VS Code와 동일 값 입력

- 설정 UI 레이아웃만 다를 뿐 입력 항목은 동일

9.3 API Key 처리

vLLM은 기본적으로 API 키 검증을 하지 않지만, Cline UI는 빈 값을 허용하지 않는 경우가 있어 sk-dummy 등 임의 문자열을 입력하면 됩니다. 사내에서 인증 프록시를 붙였다면 실제 키를 입력해야 합니다.

9.4 연결 테스트 및 흔한 오류


연결 timeout	Base URL 오타, 서버 미기동	curl http://localhost:8000/v1/models로 직접 확인
"Model not found"	Model ID 불일치	curl .../v1/models로 정확한 이름 확인
파일 수정/명령 실행 멈춤	Tool calling 미지원/파서 불일치	7.5절 curl 테스트 재확인, --tool-call-parser 점검
응답 중간에 끊김	--max-model-len 초과	.clineignore로 불필요한 파일 제외 (5부 20장)

로컬 LLM + Cline 바이브 코딩 가이드 - 3부. 설치 및 설정

환영전사 — Tue, 7 Jul 2026 16:59:42 +0900

7장. vLLM 설치 및 서버 실행 — 5090 환경 기준

7.1 설치 환경 준비

OS 선택

→ WSL2(Ubuntu 24.04) 또는 네이티브 Linux(Ubuntu 22.04/24.04) 사용을 강력히 권장합니다.

WSL2 설치 (Windows 사용자):

# PowerShell (관리자 권한)에서 실행
wsl --install -d Ubuntu-24.04

드라이버 및 CUDA 확인

nvidia-smi
nvidia-smi --query-gpu=driver_version,name --format=csv

nvidia-smi 출력 상단에 표시되는 CUDA Version이 12.8 이상인지 확인하세요. 그 이하라면 NVIDIA 드라이버를 최신 버전으로 업데이트해야 합니다.

Python 환경 준비

sudo apt update
sudo apt install -y python3.12 python3.12-venv python3-pip

python3.12 -m venv ~/vllm-env
source ~/vllm-env/bin/activate

vLLM + PyTorch(cu128) 설치

pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu128
pip install "vllm>=0.17.0"

설치 직후 GPU 인식 여부를 반드시 확인하세요.

python3 -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True와 함께 NVIDIA GeForce RTX 5090이 출력되어야 정상입니다. sm_120 is not compatible 관련 오류가 나온다면 6부 23장의 트러블슈팅을 참고하세요.

7.2 Docker로 vLLM 실행 (권장 방식)

7.3 모델 다운로드 및 서버 기동

주요 옵션:


--model	Hugging Face 모델 경로 또는 로컬 경로
--max-model-len	최대 컨텍스트 길이
--gpu-memory-utilization	VRAM 사용 비율 (0~1, 기본 0.9 권장, OOM 시 낮추기)
--quantization	양자화 방식 (awq, gptq, fp8 등)
--enable-auto-tool-choice	tool calling 자동 활성화 (Cline 연동 필수)
--tool-call-parser	모델별 tool call 파싱 형식 (hermes, mistral 등)

서버 정상 기동 시 로그:

INFO: Started server process
INFO: Uvicorn running on http://0.0.0.0:8000

7.4 OpenAI 호환 API 엔드포인트 확인

정상적으로 JSON 응답(코드 포함)이 오면 서버 설정은 완료된 것입니다.

7.5 Tool calling 지원 확인

8장. IDE 선택 및 설치

8.1 VS Code + Cline 설치

1. VS Code → Extensions(확장) → Cline 검색 후 설치

2. 설치 후 사이드바 Cline 아이콘 클릭 → 사이드 패널 오픈

3. 최초 실행 시 API Provider 설정 화면 표시 (9장에서 설정)

8.2 IntelliJ + Cline 설치

4. IntelliJ IDEA(또는 WebStorm, PyCharm 등) → Settings/Preferences → Plugins

5. Marketplace 탭에서 Cline 검색 후 설치

6. IDE 재시작 → 툴 윈도우에 Cline 패널 추가됨

JetBrains 계열 IDE는 동일한 플러그인 코어를 공유하므로 설치 방법은 어떤 제품이든 동일합니다.

8.3 두 IDE 중 선택 기준


자바/코틀린/스프링 기반 백엔드	IntelliJ IDEA
웹 프론트엔드(Vue.js), Node.js	VS Code
Python 위주 작업	VS Code 또는 PyCharm
기존 워크플로우 유지	기존 IDE 유지

Cline의 핵심 기능은 두 IDE에서 동일하게 동작하므로, 평소 사용 언어/프레임워크와의 궁합을 기준으로 선택하는 것이 합리적입니다.

9장. Cline과 vLLM 서버 연결하기

9.1 VS Code에서 연결 설정

7. Cline 패널 → 설정(톱니바퀴) 클릭

8. API Provider: OpenAI Compatible 선택

9. Base URL: http://localhost:8000/v1

10. API Key: 임의 문자열 입력 (예: not-needed)

11. Model ID: vLLM에 로드한 모델명과 정확히 일치 (예: Qwen/Qwen2.5-Coder-32B-Instruct-AWQ)

12. 저장 후 간단한 질문으로 연결 테스트

9.2 IntelliJ에서 연결 설정

13. Cline 툴 윈도우 → 설정 아이콘 클릭

14. 동일하게 OpenAI Compatible Provider 선택

15. Base URL, API Key, Model ID는 VS Code와 동일 값 입력

16. 설정 UI 레이아웃만 다를 뿐 입력 항목은 동일

9.3 API Key 처리

9.4 연결 테스트 및 흔한 오류


연결 timeout	Base URL 오타, 서버 미기동	curl http://localhost:8000/v1/models로 직접 확인
"Model not found"	Model ID 불일치	curl .../v1/models로 정확한 이름 확인
파일 수정/명령 실행 멈춤	Tool calling 미지원/파서 불일치	7.5절 curl 테스트 재확인, --tool-call-parser 점검
응답 중간에 끊김	--max-model-len 초과	.clineignore로 불필요한 파일 제외 (5부 20장)

로컬 LLM + Cline 바이브 코딩 가이드 - 2부. 환경 준비

환영전사 — Tue, 7 Jul 2026 16:57:23 +0900

4장. 하드웨어 요구사항 — RTX 5090 32GB 기준

4.1 RTX 5090 스펙 요약

RTX 5090은 NVIDIA의 Blackwell 아키텍처 기반 소비자용 최상위 GPU로, 다음과 같은 특징을 갖습니다.

● VRAM: 32GB GDDR7

● 아키텍처: Blackwell (GB202 다이), CUDA Compute Capability sm_120

● FP8 Tensor Core 지원: Blackwell 세대부터 FP8 연산을 하드웨어 레벨에서 가속하는 전용 Tensor Core가 탑재되어 있어, FP8 양자화 모델 구동 시 이점이 있습니다.

4.2 Blackwell 아키텍처 호환성 주의사항 [주의]

RTX 5090은 2025년 출시된 최신 아키텍처이기 때문에, 소프트웨어 생태계가 이를 따라잡는 데 다소 시간이 걸렸습니다. 이 가이드를 따라 하기 전에 반드시 아래 사항을 확인하세요.

● CUDA 버전: 최소 CUDA 12.8 이상 필요. 이보다 낮은 버전에서는 sm_120 커널을 인식하지 못해 CUDA error: no kernel image is available for execution on the device 같은 오류가 발생합니다.

● vLLM 버전: 최소 v0.17.0 이상 사용을 강력히 권장합니다. 이 버전부터 RTX 5090을 포함한 Blackwell 소비자용 GPU에 대한 정식 지원과 전용 FP8 GEMM 최적화가 포함되었습니다. 구버전 vLLM은 5090 자체를 인식하지 못하거나 성능이 크게 떨어질 수 있습니다.

● PyTorch 버전: PyTorch 2.9.0 + CUDA 12.8(cu128) 조합이 커뮤니티에서 안정적으로 검증된 조합입니다. cu126 등 구버전 CUDA가 딸려오는 기본 설치 명령을 그대로 쓰면 5090에서 동작하지 않으니 주의가 필요합니다.

● OS 선택: 뒤에서 다시 설명하지만, RTX 5090/RTX PRO 6000 계열은 Windows 네이티브 환경에서 GPU 연산 중 복구 불가능한 행(hang) 현상이 보고된 바 있습니다(NVIDIA도 인지하고 있는 이슈). WSL2(Ubuntu) 또는 네이티브 Linux 사용을 강력히 권장합니다.

이 영역은 하드웨어가 최신인 만큼 소프트웨어 호환성이 계속 개선되고 있는 영역입니다. 실제로 설치하기 전에 vLLM 공식 릴리즈 노트에서 최신 Blackwell 지원 현황을 한 번 더 확인하는 습관을 들이세요.

4.3 32GB VRAM으로 구동 가능한 모델 크기 가이드


FP16 / BF16 (양자화 없음)	~14B 모델까지 여유롭게	컨텍스트 길이를 넉넉하게 확보 가능
FP8	~14B~20B급	5090의 FP8 Tensor Core 활용, BF16 대비 메모리 절반
AWQ / GPTQ 4bit	~32B~34B급까지	컨텍스트 길이는 다소 제한 (16K~32K 권장)
AWQ 4bit + 짧은 컨텍스트	70B급도 이론상 가능	실사용성은 떨어짐 (컨텍스트 매우 짧아짐), 비권장

바이브 코딩용으로는 코드 컨텍스트(여러 파일, 긴 대화 기록)를 충분히 넣어야 실용적이므로, 단순히 "모델이 로드되는가"보다 "실사용 가능한 컨텍스트 길이가 확보되는가"를 기준으로 판단하는 것이 중요합니다. 이 부분은 6장에서 구체적인 수치와 함께 다룹니다.

4.4 단일 GPU 구성

이 가이드는 RTX 5090 1장 기준이므로, 여러 GPU에 모델을 분산시키는 Tensor Parallelism 설정은 다루지 않습니다. 추후 GPU를 증설한다면 vLLM의 --tensor-parallel-size 옵션을 통해 확장할 수 있다는 점만 참고로 알아두면 됩니다.

5장. 로컬 LLM 서빙 도구로 vLLM 선택하기

5.1 vLLM이란 무엇인가

vLLM은 UC 버클리에서 시작된 오픈소스 LLM 추론 서빙 엔진으로, 다음 두 가지 핵심 기술로 유명합니다.

● PagedAttention: GPU 메모리(특히 KV 캐시)를 운영체제의 가상 메모리 페이징과 유사한 방식으로 관리해, 메모리 낭비를 최소화하고 동시에 더 많은 요청을 처리할 수 있게 합니다.

● 연속 배치(Continuous Batching): 여러 요청이 들어올 때 이를 효율적으로 묶어 처리량(throughput)을 극대화합니다.

또한 vLLM은 OpenAI 호환 API 서버를 기본 제공하기 때문에, OpenAI API 형식을 사용하는 대부분의 클라이언트(Cline 포함)와 별도 어댑터 없이 바로 연결할 수 있습니다.

5.2 Ollama / LM Studio 대비 vLLM의 장단점


목적	개인 데스크톱 사용에 최적화	서버/프로덕션급 추론에 최적화
설치 난이도	매우 쉬움 (원클릭 수준)	상대적으로 복잡 (CUDA/드라이버 버전 관리 필요)
동시 요청 처리	제한적	우수 (연속 배치로 다중 요청 효율적 처리)
응답 지연시간(단일 요청)	준수함	우수함, 특히 첫 토큰 응답 시간(TTFT)에서 강점
Tool calling 안정성	모델/버전에 따라 다름	파서를 명시적으로 지정 가능, 상대적으로 안정적
GPU 활용	자동 오프로딩 등 편의 기능 多	수동 튜닝 필요하나 최대 성능 추출 가능

실측 벤치마크에 따르면, 동일 Blackwell GPU(RTX PRO 6000)에서 vLLM은 Ollama 대비 첫 토큰 응답 시간(TTFT)이 약 3.9배 빠르고, 프리필(prefill) 처리 속도는 3.4배, 동시 처리량은 2.8배 높은 것으로 나타났습니다. 다만 이 비교는 에이전트/다중 요청 워크로드 기준이며, 단순 1:1 채팅 용도라면 Ollama도 충분히 쓸만합니다.

5.3 Cline 워크플로우에서 vLLM이 적합한 이유

Cline은 에이전트 방식으로 동작하면서 다음과 같은 특성을 보입니다.

● 하나의 작업 안에서도 파일 읽기 → 코드 생성 → 명령 실행 결과 확인 → 재생성 등 여러 번의 짧은 요청이 연속으로 발생

● 시스템 프롬프트 + 여러 파일 내용 + 대화 기록이 누적되어 프리필 단계 처리량이 중요

● Tool calling(함수 호출) 형식의 정확도가 떨어지면 Cline이 파일 수정/명령 실행 자체를 실패

이런 특성 때문에 프리필 속도와 tool calling 안정성이 중요한 Cline 환경에서는 vLLM의 구조적 장점이 실질적인 체감 성능 차이로 이어집니다.

5.4 5090에서 vLLM 사용 시 알려진 이슈

● 초기 vLLM 버전에서는 RTX 5090이 sm_120 아키텍처를 인식하지 못해 설치 자체가 실패하는 사례가 많았습니다. 반드시 vLLM 0.17.0 이상을 사용하세요.

● 최신 모델(예: 특정 GLM 계열 모델) 중에는 커스텀 빌드로도 RTX 5090에서 호환이 안 되는 사례가 여전히 보고되고 있습니다. 사용하려는 모델이 있다면 vLLM GitHub 이슈나 포럼에서 5090/Blackwell 관련 이슈를 미리 검색해보는 것을 권장합니다.

● Windows 네이티브 환경에서 RTX 5090/RTX PRO 6000 계열이 GPU 연산 중 멈추는(hang) 현상이 보고되어 있습니다. WSL2 또는 Linux 네이티브 사용을 권장합니다 (7장에서 상세히 다룸).

6장. 모델 선택 가이드 — 32GB VRAM 최적화

6.1 추천 모델 라인업 (최신 업데이트)

바이브 코딩(특히 Cline과 같은 에이전틱 워크플로우)에는 코딩 특화 + tool calling(함수 호출)을 잘 지원하는 모델이 적합합니다. 2026년 상반기 기준 오픈소스 코딩 모델 생태계는 몇 달 사이 매우 빠르게 발전했고, RTX 5090 32GB 단일 GPU 환경에는 다음 라인업을 권장합니다.


Qwen3-Coder-30B-A3B-Instruct	30B (MoE, 활성 3B)	FP8 / AWQ 4bit	메인 추천. MoE 구조로 30B급 품질을 3B급 속도로 제공, 256K(최대 1M) 컨텍스트, Apache 2.0 라이선스. RTX 5090 32GB에 가장 이상적인 조합으로 평가받음
Qwen2.5-Coder-32B-Instruct	32B (Dense)	AWQ 4bit	검증된 안정적 대안. Qwen3-Coder 계열 이슈 발생 시 폴백용으로 적합
GLM-4.7-Flash	경량급	BF16 / AWQ	16~32GB급 GPU에 최적화된 가벼운 대안, 리소스가 더 타이트한 환경에 적합

Qwen3-Coder-30B-A3B를 메인으로 추천하는 이유

● MoE(Mixture of Experts) 구조: 전체 파라미터는 30B이지만 토큰당 실제 활성화되는 파라미터는 약 3B 수준이라, 동급 Dense 모델보다 추론 속도가 훨씬 빠릅니다. RTX 5090 32GB VRAM에서 GPU 호환성 평가 100/100을 받은 조합입니다.

● 긴 컨텍스트: 기본 256K, YaRN 확장으로 최대 1M 토큰까지 지원 — 4부에서 다루는 여러 설계 문서(docs/, memory-bank/)를 한 번에 첨부해도 여유가 있습니다.

● Apache 2.0 라이선스: 상업적 사용 제약이 적습니다.

● Tool calling 안정성: 커뮤니티 차원에서 tool-calling 관련 이슈가 수정된 이력이 있어(예: Unsloth 배포판), Cline과 같은 에이전트 워크플로우에서 안정적으로 동작합니다.

[주의] 주의: Qwen3-Coder-30B-A3B는 MoE 구조라 vLLM에서 서빙 시 AWQ/FP8 등 vLLM 호환 양자화 체크포인트가 Hugging Face에 등록되어 있는지 먼저 확인해야 합니다. 순수 BF16 체크포인트만 있다면 30B 전체 파라미터 기준 VRAM 요구량이 32GB를 초과할 수 있으므로, 이 경우 FP8(온라인 양자화) 또는 커뮤니티 AWQ 빌드를 사용하거나, 대안으로 검증된 Dense 모델인 Qwen2.5-Coder-32B-AWQ를 사용하세요.

오픈소스 코딩 모델 순위는 몇 달 단위로 바뀌는 영역입니다(이 시점 기준 GLM-5 계열, DeepSeek V4, Kimi K2 계열도 최상위권이지만 대부분 100B~1T급으로 단일 RTX 5090에는 맞지 않습니다). 실제 설치 전 Hugging Face 모델 카드와 최신 코딩 리더보드를 한 번 더 확인하는 것을 권장합니다.

6.2 vLLM 지원 양자화 포맷

● AWQ (Activation-aware Weight Quantization): 가중치를 4bit로 양자화하되, 활성화 값에 민감한 가중치는 정밀도를 보존. 코딩 모델에서 품질 손실이 비교적 적어 널리 쓰임.

● GPTQ: AWQ와 유사한 목적의 다른 양자화 기법. 모델별로 AWQ/GPTQ 지원 여부가 다르니 Hugging Face 모델 카드를 확인.

● FP8: RTX 5090의 전용 FP8 Tensor Core를 활용해 BF16 대비 메모리를 절반으로 줄이면서 속도 이점을 얻을 수 있음. vLLM 0.17.0 이상에서 Blackwell 전용 최적화가 적용됨.

● BitsAndBytes: 온더플라이 양자화 지원하나, vLLM에서는 AWQ/GPTQ/FP8 대비 처리량이 낮은 편.

6.3 `--max-model-len` 설정과 VRAM 트레이드오프

vLLM 서버 실행 시 --max-model-len으로 최대 컨텍스트 길이를 지정합니다. 이 값이 클수록 KV 캐시가 차지하는 VRAM이 늘어나므로, 모델 가중치 크기와 컨텍스트 길이 사이에서 트레이드오프가 발생합니다.

예시 (Qwen2.5-Coder-32B-Instruct-AWQ, 32GB VRAM 기준 대략적인 가이드):


16,384	넉넉함	짧은 파일 단위 작업에는 충분
32,768	적당함	바이브 코딩 기본 권장값
65,536	타이트함	동시 요청 수를 줄여야 안정적

정확한 수치는 모델, vLLM 버전, gpu-memory-utilization 설정에 따라 달라지므로 반드시 실제 환경에서 서버를 기동해보고 nvidia-smi로 VRAM 사용량을 확인하며 조정해야 합니다.

6.4 KV Cache 메모리 계산법 간단 소개

KV 캐시 메모리 사용량은 대략 다음 요소에 비례합니다.

KV 캐시 크기 ∝ (레이어 수) × (헤드 수) × (헤드 차원) × (컨텍스트 길이) × (동시 요청 수) × (bytes per value)

직접 계산하기보다는, vLLM이 서버 기동 시 로그에 출력하는 "사용 가능한 KV 캐시 블록 수"와 --gpu-memory-utilization 값을 참고해 실험적으로 조정하는 것이 실용적입니다. 이 내용은 6부 21장(성능 튜닝)에서 다시 다룹니다.

로컬 LLM + Cline 바이브 코딩 - 1부. 개념 이해하기

환영전사 — Tue, 7 Jul 2026 16:55:21 +0900

1장. 바이브 코딩이란 무엇인가

1.1 정의와 배경

"바이브 코딩(Vibe Coding)"은 개발자가 코드를 한 줄 한 줄 직접 타이핑하는 대신, 자신이 원하는 결과물(의도, "vibe")을 자연어로 AI에게 전달하고, AI가 실제 코드 작성·수정·실행을 담당하는 개발 방식을 말합니다.

이 용어는 2025년 초 AI 코딩 어시스턴트가 단순 자동완성 수준을 넘어 파일 시스템을 직접 조작하고, 터미널 명령을 실행하고, 에러를 스스로 읽고 수정하는 "에이전틱(agentic)" 능력을 갖추면서 널리 퍼졌습니다. 개발자는 더 이상 문법이나 API 시그니처를 일일이 기억할 필요 없이, "이런 기능이 필요해", "이 버그를 고쳐줘" 같은 지시만으로 실질적인 결과물을 만들어낼 수 있게 되었습니다.

핵심은 개발자의 역할이 "코드 작성자"에서 "의도 전달자 겸 검토자"로 이동한다는 점입니다. 코드를 직접 치는 시간은 줄지만, 대신 다음과 같은 역량이 더 중요해집니다.

● 무엇을 만들고 싶은지 명확하게 표현하는 능력

● AI가 만든 결과물이 의도와 맞는지 검토하는 능력

● AI가 막히거나 잘못된 방향으로 갈 때 방향을 재설정하는 능력

1.2 기존 코딩 방식과의 차이


코드 작성 주체	개발자 본인	AI (개발자는 지시)
개발자의 주 업무	타이핑, 문법/API 암기	의도 전달, 검토, 방향 설정
속도 결정 요인	타이핑 속도, 숙련도	프롬프트 품질, AI 응답 속도
실수 발견 시점	컴파일/실행 시	AI 응답 검토 시 + 실행 시
요구되는 스킬	문법, 알고리즘, 라이브러리 지식	요구사항 정의력, 설계 감각, 코드 리딩 능력

바이브 코딩이라고 해서 개발 지식이 필요 없어지는 것은 절대 아닙니다. 오히려 AI가 만든 코드를 읽고 판단할 수 있는 능력은 그대로, 혹은 더 중요해집니다. AI에게 맡기는 것은 "타이핑"이지 "판단"이 아니기 때문입니다. 이 가이드의 4부(분석/설계)에서 이 부분을 자세히 다룹니다.

2장. Cline이란 무엇인가

2.1 VS Code/JetBrains 확장으로서의 Cline

Cline은 VS Code와 JetBrains 계열 IDE(IntelliJ IDEA, WebStorm, PyCharm 등)에서 동작하는 오픈소스 AI 코딩 에이전트 확장(플러그인)입니다. 단순히 코드 제안을 보여주는 Copilot류 도구와 달리, Cline은 다음과 같은 실행 권한을 가진 에이전트로 동작합니다.

● 프로젝트 내 파일을 직접 읽고, 생성하고, 수정

● 터미널 명령을 직접 실행 (빌드, 테스트, 패키지 설치 등)

● 브라우저를 열어 웹 페이지 결과를 스크린샷으로 확인

● MCP(Model Context Protocol) 서버를 통한 외부 도구 연동

이 모든 동작은 사람의 승인(approve) 없이는 실행되지 않도록 설계되어 있어(설정에 따라 자동 승인도 가능), AI가 프로젝트를 망가뜨릴 위험을 통제하면서도 실질적인 작업 위임이 가능합니다.

2.2 Cline의 핵심 기능

1. 파일 읽기/쓰기: 프로젝트 구조를 스스로 탐색하고, 필요한 파일을 열어보고, 새 파일을 만들거나 기존 파일을 diff 형태로 수정 제안합니다.

2. 터미널 실행: npm install, pytest, git commit 같은 명령을 직접 실행하고 그 결과(출력, 에러)를 읽어 다음 행동을 결정합니다.

3. 브라우저 제어: 웹 애플리케이션을 개발할 때 실제로 페이지를 열어 렌더링 결과를 확인하고, 콘솔 에러를 읽습니다.

4. Plan/Act 모드: 실행 전에 계획을 세우고 사용자와 상의하는 모드(Plan)와, 실제로 파일을 수정/명령을 실행하는 모드(Act)를 분리해 제공합니다. (5부 16장에서 상세히 다룸)

5. MCP 연동: 외부 API, 데이터베이스, 사내 도구 등을 MCP 서버 형태로 연결해 Cline의 능력을 확장할 수 있습니다.

6. 다양한 모델 프로바이더 지원: Anthropic, OpenAI 같은 클라우드 API뿐 아니라, OpenAI 호환 API를 제공하는 로컬 서버(Ollama, LM Studio, vLLM 등)도 연결 가능합니다. 이 가이드는 이 마지막 지점, 즉 로컬 vLLM 서버와의 연결을 중심으로 다룹니다.

3장. 왜 로컬 LLM인가

3.1 클라우드 API 대비 장단점

장점

● 비용 예측 가능성: 클라우드 API는 토큰 단위 종량 과금이라 대규모/반복 작업 시 비용이 눈덩이처럼 불어날 수 있습니다. 로컬 LLM은 초기 하드웨어 투자 이후 전력비 외 추가 비용이 없습니다.

● 프라이버시/보안: 사내 코드, 고객 데이터, 민감한 비즈니스 로직을 외부 서버로 전송하지 않아도 됩니다. 금융, 의료, 국방 등 규제 산업에서 특히 중요합니다.

● 오프라인/폐쇄망 사용: 인터넷 연결이 없거나 제한된 환경(사내 폐쇄망 등)에서도 동작합니다.

● 커스터마이징: 특정 도메인에 맞게 파인튜닝하거나, 원하는 오픈소스 모델을 자유롭게 선택/교체할 수 있습니다.

● 응답 지연시간(latency) 통제: 네트워크 왕복 시간이 없어 로컬 환경에서는 지연시간을 직접 튜닝할 수 있습니다 (단, 모델 자체의 추론 속도는 하드웨어 성능에 좌우됨).

단점

● 초기 하드웨어 비용: 고성능 GPU(RTX 5090 등) 구매 비용이 상당함

● 모델 성능 한계: 오픈소스 모델은 최상위 클라우드 모델(Claude Opus 등) 대비 복잡한 추론/설계 능력이 떨어질 수 있음

● 운영 부담: 서버 설정, 드라이버/CUDA 버전 관리, 모델 업데이트 등을 직접 관리해야 함

● 컨텍스트 길이 제약: VRAM 한계로 인해 클라우드 모델만큼 긴 컨텍스트를 다루기 어려운 경우가 많음

3.2 이 가이드의 접근 방향

이 가이드는 "모든 작업을 로컬로 대체하자"가 아니라, "일상적인 반복 작업은 로컬로, 정말 어려운 설계/추론은 필요시 클라우드로" 라는 하이브리드 관점을 취합니다. 이 전략은 6부 24장에서 구체적으로 다룹니다. 다만 이 가이드의 대부분은 vLLM + RTX 5090 조합으로 로컬 환경을 온전히 구축하고 활용하는 데 집중합니다.

갈치 선상낚시 초보자 가이드

환영전사 — Tue, 7 Jul 2026 16:52:58 +0900

텐빈 & 루어 채비로 시작하는 갈치 선상낚시텐빈 & 루어 채비로 시작하는 갈치 선상낚시

여름밤 바다 위에 집어등이 환하게 켜지고, 은빛 갈치가 줄줄이 올라오는 손맛. 갈치 선상낚시는 무거운 전동릴 없이도 즐길 수 있는 텐빈(편대) 채비와 루어 채비로 접근하면 훨씬 가볍고 초보자 친화적으로 시작할 수 있습니다. 장비부터 노하우까지 순서대로 정리해봤습니다.

1. 낚시 장비

텐빈·루어 스타일은 심해 전동릴 장비에 비해 훨씬 가볍고 저렴하게 구성할 수 있어 처음 도전하는 분들에게 특히 추천할 만합니다.

텐빈(편대) 채비용 장비

• 낚싯대: 타치우오(갈치) 텐빈 전용대나 6.6~7ft 정도의 라이트~미디엄라이트(ML) 로드가 적당합니다. 텐빈 전용대는 예민한 입질과 어신 전달력에 특화되어 있습니다.

• 릴: 소형~중형 스피닝 릴이나 베이트릴을 사용합니다. 전동릴처럼 무겁지 않아 다루기 편합니다.

• 원줄·목줄: PE 합사 위주로 준비합니다.

루어 채비용 장비

• 낚싯대: 6.6~7ft 길이의 UL(울트라라이트)~ML 강도 로드가 초보자에게 적합합니다. 8ft 전후의 연질 농어·볼락 루어대도 대용 가능합니다. 원투가 필요하다면 7ft 이상의 긴 로드가 유리합니다.

• 릴: 2000~2500번 크기의 스피닝 릴이면 충분합니다.

• 원줄: PE 라인 0.6~0.8호

• 목줄(쇼크리더): 카본 또는 나일론 1~3호. 가는 목줄일수록 가벼운 루어를 멀리 던지기 쉽고 입질 감도도 좋아집니다.

공통 준비물

• 집어등: 채비 위쪽에 달아 갈치를 유인합니다. 배터리형 방수 집어등이 일반적입니다.

• 의류·소품: 미끼 비린내가 배기 쉬우므로 세탁이 편한 간편복을 추천하며, 모자·장갑·여벌 옷·수건은 기본으로 챙깁니다.

• 손질 도구: 회칼 하나 챙기면 선상에서 바로 회를 떠서 맛볼 수 있습니다. 갈치의 날카로운 이빨에 다칠 수 있으니 바늘을 뺄 땐 플라이어를 사용하세요.

• 보관함: 아이스박스는 선상에서 제공되는 경우가 많지만, 신선도를 더 오래 유지하려면 개인용 대형 아이스박스를 준비하는 것이 좋습니다.

TIP 텐빈·루어 장비는 볼락·농어 루어대 등 이미 가지고 있는 라이트 태클로도 대체 가능한 경우가 많아, 심해 전동릴 장비보다 진입 장벽이 훨씬 낮습니다. 처음이라면 배에서 대여 가능한지 미리 확인해보세요.

2. 낚시 채비

텐빈(편대) 채비

편대(텐빈) 채비는 봉돌과 바늘이 아래위로 분리되어 엉킴이 적고 다루기 쉬운 것이 특징입니다.

• 편대(텐빈): 20~30cm 길이의 속공 텐빈이나 오모리리그용 편대를 사용합니다. 스테인리스나 티타늄 소재가 일반적입니다.

• 바늘: 쌍바늘 또는 아가미바늘 형태의 갈치 전용 텐빈 채비가 완제품으로 많이 판매되며, 형상기억합금 소재로 엉킴을 줄인 제품도 있습니다.

• 목줄: 갈치 이빨에 잘리지 않도록 와이어나 튜브로 보강된 목줄을 사용합니다.

• 봉돌: 15~30호 정도로 근해·내만 포인트에 맞춘 가벼운 무게를 사용합니다(심해용보다 훨씬 가볍습니다).

• 집어등·케미컬라이트: 텐빈 위쪽에 달아 갈치를 채비 쪽으로 유인합니다.

• 미끼: 꽁치살을 손질해 바늘에 꿰어 사용합니다.

루어 채비

• 지그헤드 + 웜: 가장 기본적인 조합으로, 지그헤드에 실리콘 웜(2~5인치)이나 볼락웜(1.5인치)을 결합해 사용합니다.

• 바늘 방향: 바늘이 아래로 향하게 세팅하는 것이 기본입니다.

• 웜 색상: 야광·축광 웜이 밤낚시에 효과적입니다.

• 채비 교체: 갈치는 같은 패턴에 금방 적응하므로 웜 종류나 색상을 자주 바꿔주는 것이 좋습니다.

TIP 완제품 텐빈 채비와 루어용 지그헤드·웜은 낚시점이나 온라인에서 저렴하게 구입할 수 있어, 직접 매듭을 묶지 않아도 바로 사용할 수 있습니다.

3. 낚시 시기

갈치는 수온에 따라 이동하는 어종이라 시기별로 포인트와 씨알이 달라집니다.

• 전체 시즌: 대체로 6~7월부터 12월까지가 갈치 선상낚시 시즌입니다. 수온이 급격히 낮아지는 12월 중순 전후로 시즌이 마무리됩니다.

• 초반(6~7월): 제주도 주변 해역에서 먼저 시즌이 열리며, 이 시기엔 손가락 2개 굵기 정도의 작은 '풀치'가 주로 낚입니다. 텐빈·루어 채비로 공략하기 좋은 시기이기도 합니다.

• 성수기(8~11월): 수온이 오르면서 어장이 남해안 가까이(거문도, 백도 등)로 북상해 형성되며 조황이 가장 안정적입니다.

• 후반(11~12월): 씨알이 굵어져 4지급(손가락 네 마디 폭) 이상의 대형 갈치를 만날 확률이 높아집니다.

TIP 시즌이 시작되면 특정 달이 유독 좋다고 단정하기 어려울 만큼 꾸준한 조황을 보이는 편이니, 날씨와 개인 일정에 맞춰 출조 시기를 정하면 됩니다.

4. 주요 출항지

갈치 선상낚시는 남해안과 제주도가 대표적인 출항지입니다.

• 여수: 거문도·백도 해역으로 나가는 먼바다 갈치낚시로 유명하며, 왕갈치급을 노릴 수 있는 대표 포인트입니다.

• 통영·삼천포(사천): 남해안에서 갈치 포인트가 꾸준히 형성되는 지역입니다.

• 완도: 남해 서부권의 주요 갈치 출항지 중 하나입니다.

• 제주도: 시즌 초반 어장이 먼저 형성되는 곳으로, 도두항 등에서 근해·내만식 텐빈·루어 낚시도 활발합니다.

• 서해권: 최근 서해에서도 갈치 어군이 확인되면서 새로운 낚시터로 주목받고 있습니다.

수도권에 거주한다면 시즌 중 남해 출항지까지 왕복하는 출조버스를 운행하는 낚시점들이 많아, 개인 차량 없이도 편하게 다녀올 수 있습니다.

5. 낚시 방법

텐빈·루어 채비는 심해 전동릴 방식보다 캐스팅과 리트리브 위주로 진행되어 훨씬 직관적입니다.

텐빈(편대) 채비 사용법

1. 텐빈 채비에 미끼(꽁치살)를 꿰고 집어등을 위쪽에 답니다.

2. 배 주변으로 채비를 내려 상층부터 탐색을 시작합니다.

3. 입질층을 찾을 때까지 조금씩 수심을 더 내려가며 탐색합니다.

4. 입질이 오면 갈치가 미끼를 완전히 삼킬 때까지 기다린 후 챔질합니다. 갈치는 미끼를 한입에 삼키지 않고 뜯어 먹는 습성이 있어 서두르면 놓치기 쉽습니다.

루어 채비 사용법

1. 지그헤드+웜 채비를 원하는 방향으로 캐스팅합니다.

2. 채비가 가라앉는 동안 라인을 살짝 견제하며 입질층을 확인합니다.

3. 부드러운 리트리브(감아들이기)로 웜의 꼬리가 자연스럽게 떨리는 액션을 만들어줍니다.

4. 가벼운 트위칭(로드를 톡톡 흔들기)을 리트리브 중간에 섞어 불규칙한 액션으로 입질을 유도합니다.

5. 활성이 좋을 때는 갈치가 점점 상층으로 붙으므로 채비 수심을 얕게 조절해 입질을 놓치지 않도록 합니다.

6. 주요 노하우

• 입질층을 빠르게 찾기: 텐빈이든 루어든 상층부터 시작해 점차 깊은 층으로 탐색 범위를 넓혀가며 갈치가 몰려있는 수심대를 찾는 것이 조과의 핵심입니다. 수위가 바뀌면 입질층도 함께 바뀌니 계속 확인해야 합니다.

• 루어는 액션이 생명: 웜 자체는 가만히 있으면 미끼 역할을 하지 못합니다. 리트리브 중 웜 꼬리가 잘 떨리는지 확인하고, 같은 액션에 갈치가 반응하지 않으면 루어 종류나 색상을 바꿔보세요.

• 챔질 타이밍: 갈치는 미끼를 바로 삼키지 않고 뜯어 먹기 때문에, 입질이 왔다고 바로 챔질하면 헛챔질이 되기 쉽습니다. 완전히 삼킬 때까지 기다렸다가 챔질하는 것이 요령입니다.

• 텐빈 채비의 장점: 봉돌과 바늘이 분리된 구조라 루어 채비보다 엉킴이 적고, 생미끼를 쓰기 때문에 갈치의 반응 속도가 빠른 편입니다.

• 루어 채비의 장점: 원투가 가능해 넓은 범위를 빠르게 탐색할 수 있고, 수심 조절도 텐빈보다 훨씬 간편합니다.

• 이빨 손상 방지: 갈치의 날카로운 이빨에 목줄이 잘리지 않도록 와이어나 튜브로 보강된 채비를 사용하고, 바늘을 뺄 때는 플라이어를 사용해 손을 보호하세요.

• 날씨 확인은 필수: 특히 겨울철에는 어장이 육지에서 멀리 떨어져 있어 기상 악화 시 출조 자체가 취소되는 경우가 많으니 사전에 일기예보를 확인하세요.

• 비용 계획: 보통 1인당 20만~30만원 선이며 대개 식사와 기본 채비, 미끼 등이 포함된 경우가 많습니다. 저렴한 가격만 보고 선택하기보다는 선장과 출조점의 신뢰도를 먼저 확인하는 것이 좋습니다.

텐빈과 루어 채비는 전동릴 심해 장비보다 훨씬 가볍고 진입 장벽이 낮아, 라이트 태클을 이미 갖고 있다면 별도 구매 없이도 도전해볼 수 있습니다. 이번 시즌엔 남해나 제주도로 은갈치를 만나러 떠나보는 건 어떨까요?

람다 표현식으로 Map 값 처리 (Handling Map Values with Lambda Expressions)

환영전사 — Fri, 15 Sep 2023 15:38:33 +0900

원문 : https://dev.java/learn/api/collections-framework/maps-and-lambdas/

Handling Map Values with Lambda Expressions - Dev.java

Handling the Values Stored in a Map.

dev.java

Map 콘텐츠 소비

Map 인터페이스에는 Iterable 인터페이스의 forEach() 메서드와 동일한 방식으로 작동하는 forEach() 메서드가 있습니다. 차이점은 이 forEach() 메소드가 단순한 Consumer 대신 BiConsumer를 인수로 취한다는 것입니다.

간단한 Map를 만들고 그 내용을 인쇄해 보겠습니다.

Map<Integer, String> map = new HashMap<>();
map.put(1, "one");
map.put(2, "two");
map.put(3, "three");

map.forEach((key, value) -> System.out.println(key + " :: " + value));

이 코드는 다음과 같은 결과를 생성합니다.

1 :: one
2 :: two
3 :: three

값 바꾸기

Map 인터페이스는 키에 바인딩된 값을 다른 값으로 바꾸는 세 가지 방법을 제공합니다.

첫 번째는 기존 값을 맹목적으로 새 값으로 바꾸는 교체(키, 값)입니다. 이는 put-if-present 연산과 동일합니다. 이 메소드는 지도에서 제거된 값을 반환합니다.

더 세밀한 제어가 필요한 경우 기존 값을 인수로 사용하는 이 메서드의 오버로드(replace(key, existingValue, newValue))를 사용할 수 있습니다. 이 경우 전달받은 기존 값이 일치하는 경우에만 새 값으로 대체됩니다. 대체되는 경우 이 메서드는 true를 반환합니다.

Map 인터페이스에는 BiFunction을 사용하여 Map의 모든 값을 바꾸는 방법도 있습니다. 이 BiFunction은 키와 값을 인수로 사용하고 기존 값을 대체할 새 값을 반환하는 리매핑 함수입니다. 이 메소드에 대한 호출은 맵의 모든 키/값 쌍에서 내부적으로 반복됩니다.

다음 예에서는 이 replacementAll() 메서드를 사용하는 방법을 보여줍니다.

Map<Integer, String> map = new HashMap<>();

map.put(1, "one");
map.put(2, "two");
map.put(3, "three");

map.replaceAll((key, value) -> value.toUpperCase());
map.forEach((key, value) -> System.out.println(key + " :: " + value));

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

1 :: ONE
2 :: TWO
3 :: THREE

값 계산

Map 인터페이스는 키-값 쌍을 맵에 추가하거나 맵의 기존 값을 세 가지 메서드(compute(), ComputeIfPresent() 및 ComputeIfAbsent()) 형식으로 수정하는 세 번째 패턴을 제공합니다.

이 세 가지 메서드는 다음 인수를 사용합니다.

계산이 이루어지는 키
Compute() 및 ComputeIfPresent()의 경우 해당 키에 바인딩된 값
재매핑 함수로 작동하는 BiFunction 또는 ComputeIfAbsent()의 경우 매핑 함수.

Compute()의 경우 리매핑 이중 함수는 두 개의 인수를 사용하여 호출됩니다. 첫 번째는 키이고, 두 번째는 기존 값이 있으면 기존 값이고, 없으면 null입니다. 리매핑 이중 함수는 null 값으로 호출될 수 있습니다.

ComputeIfPresent()의 경우 해당 키에 바인딩된 값이 있고 null이 아닌 경우 다시 매핑 함수가 호출됩니다. 키가 null 값에 바인딩되어 있으면 다시 매핑 함수가 호출되지 않습니다. 재매핑 함수는 null 값으로 호출할 수 없습니다.

ComputeIfAbsent()의 경우 해당 키에 바인딩된 값이 없기 때문에 리매핑 함수는 실제로 키를 인수로 사용하는 간단한 함수입니다. 이 함수는 키가 맵에 없거나 null 값에 바인딩된 경우 호출됩니다.

모든 경우에 이중 함수(또는 함수)가 null 값을 반환하면 키가 맵에서 제거됩니다. 해당 키에 대한 매핑이 생성되지 않습니다. 이 세 가지 방법 중 하나를 사용하면 null 값이 있는 키/값 쌍을 맵에 넣을 수 없습니다.

모든 경우에 반환되는 값은 맵의 해당 키에 바인딩된 새 값이거나, 재매핑 함수가 null을 반환한 경우 null입니다. 이 의미 체계가 put() 메서드와 다르다는 점을 지적할 가치가 있습니다. put() 메서드는 이전 값을 반환하는 반면, Compute() 메서드는 새 값을 반환합니다.

ComputeIfAbsent() 메서드의 매우 흥미로운 사용 사례는 목록을 값으로 사용하여 맵을 생성하는 것입니다. 다음과 같은 문자열 목록이 있다고 가정해 보겠습니다. [1 2 3 4 5 6 7]. 키는 해당 목록에 있는 단어의 길이이고 값은 해당 단어의 목록인 맵을 만들어야 합니다. 생성해야 할 것은 다음 맵입니다.

3 :: [one, two, six]
4 :: [four, five]
5 :: [three, seven]

Compute() 메서드가 없으면 아마도 다음과 같이 작성할 것입니다.

List<String> strings = List.of("one", "two", "three", "four", "five", "six", "seven");
Map<Integer, List<String>> map = new HashMap<>();
for (String word: strings) {
    int length = word.length();
    if (!map.containsKey(length)) {
        map.put(length, new ArrayList<>());
    }
    map.get(length).add(word);
}

map.forEach((key, value) -> System.out.println(key + " :: " + value));

이 코드를 실행하면 예상되는 결과가 생성됩니다.

3 :: [one, two, six]
4 :: [four, five]
5 :: [three, seven]

그런데 putIfAbsent()를 사용하여 이 for 루프를 단순화할 수 있습니다.

for (String word: strings) {
    int length = word.length();
    map.putIfAbsent(length, new ArrayList<>());
    map.get(length).add(word);
}

그러나 ComputeIfAbsent()를 사용하면 이 코드가 더욱 향상될 수 있습니다.

for (String word: strings) {
    int length = word.length();
    map.computeIfAbsent(length, key -> new ArrayList<>())
       .add(word);
}

이 코드는 어떻게 작동하나요?

키가 맵에 없으면 매핑 함수가 호출되어 빈 목록이 생성됩니다. 이 목록은 ComputeIfAbsent() 메서드에 의해 반환됩니다. 이는 코드가 단어를 추가하는 빈 목록입니다.
키가 맵에 있으면 매핑 함수가 호출되지 않고 해당 키에 바인딩된 현재 값이 반환됩니다. 이것은 단어를 추가해야 하는 부분적으로 채워진 목록입니다.
이 코드는 putIfAbsent() 코드보다 훨씬 더 효율적입니다. 그 이유는 대부분 이 경우 필요한 경우에만 빈 목록이 생성되기 때문입니다. putIfAbsent() 호출에는 키가 맵에 없는 경우에만 사용되는 기존 빈 목록이 필요합니다. 맵에 추가하는 객체를 요청 시 생성해야 하는 경우 putIfAbsent()보다 ComputeIfAbsent()를 사용하는 것이 더 좋습니다.

값 병합

ComputeIfAbsent() 패턴은 에 다른 값의 집합인 값이 있는 경우 잘 작동합니다. 하지만 이 집계를 지원하는 구조에는 제한 사항이 있습니다. 즉, 변경이 가능해야 합니다. 이는 ArrayList의 경우이며 여러분이 작성한 코드는 다음과 같습니다. 즉, 값을 ArrayList에 추가합니다.

단어 목록을 만드는 대신 단어 연결을 만들어야 한다고 가정해 보겠습니다. 여기서 String 클래스는 다른 문자열의 집합으로 표시되지만 변경 가능한 컨테이너는 아닙니다. 이를 수행하기 위해 ComputeIfAbsent() 패턴을 사용할 수 없습니다.

이것이 merge() 패턴이 구출되는 곳입니다. merge() 메서드는 세 가지 인수를 사용합니다.

키
해당 키에 바인딩해야 하는 값
리매핑 BiFunction.

키가 맵에 없거나 null 값에 바인딩된 경우 값은 해당 키에 바인딩됩니다. 이 경우에는 재매핑 함수가 호출되지 않습니다.

반대로 키가 이미 null이 아닌 값에 바인딩된 경우 기존 값을 사용하여 다시 매핑 함수가 호출되고 새 값이 인수로 전달됩니다. 이 재매핑 함수가 null을 반환하면 키가 맵에서 제거됩니다. 그렇지 않으면 생성된 값이 해당 키에 바인딩됩니다.

다음 예제에서 이 merge() 패턴이 실제로 작동하는 것을 볼 수 있습니다.

List<String> strings = List.of("one", "two", "three", "four", "five", "six", "seven");
Map<Integer, String> map = new HashMap<>();
for (String word: strings) {
    int length = word.length();
    map.merge(length, word, 
              (existingValue, newWord) -> existingValue + ", " + newWord);
}

map.forEach((key, value) -> System.out.println(key + " :: " + value));

이 경우 길이 키가 맵에 없으면 merge() 호출은 이를 추가하고 단어에 바인딩합니다. 반면, 길이 키가 이미 맵에 있으면 기존 값과 단어를 사용하여 이중 함수가 호출됩니다. 그런 다음 이중 함수의 결과가 현재 값을 대체합니다.

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

3 :: one, two, six
4 :: four, five
5 :: three, seven

두 패턴(computeIfAbsent() 및 merge())에서 생성된 람다가 이 람다의 컨텍스트에서 항상 사용할 수 있고 해당 컨텍스트에서 캡처할 수 있는 인수를 취하는 이유가 궁금할 수 있습니다. 대답은 다음과 같습니다. 성능상의 이유로 캡처하는 람다보다 캡처하지 않는 람다를 선호해야 합니다.

Comparator 작성 및 결합 (Writing and Combining Comparators)

환영전사 — Wed, 13 Sep 2023 18:13:32 +0900

원문 : https://dev.java/learn/lambdas/writing-comparators/

Writing and Combining Comparators - Dev.java

Creating and Combining Comparators Using Lambda Expressions.

dev.java

람다 표현식으로 Comparator 구현

Functional Interface의 정의 덕분에 JDK 2에 도입된 기존의 Comparator<T> 인터페이스가 Functional Interface가 되었습니다. 따라서 Comparator 구현은 람다 식을 사용하여 수행할 수 있습니다.

Comparator<T> 인터페이스의 유일한 추상 메서드는 다음과 같습니다.

@FunctionalInterface
public interface Comparator<T> {

    int compare(T o1, T o2);
}

Comparator의 규칙은 다음과 같습니다.

o1 < o2이면 Compare(o1, o2)는 음수를 반환해야 합니다.
o1 > o2이면 비교(o1, o2)는 양수를 반환해야 합니다.
모든 경우에, Compare(o1, o2)와 Compare(o2, o1)은 반대 부호를 가져야 합니다.

o1.equals(o2)가 true인 경우 o1과 o2의 비교가 0을 반환한다는 것이 엄격히 요구되는 것은 아닙니다.

자연 순서를 구현하는 정수 Comparator를 어떻게 만들 수 있습니까? 이 튜토리얼의 시작 부분에서 본 방법을 사용하면 됩니다.

Comparator<Integer> comparator = (i1, i2) -> Integer.compare(i1, i2);

이 람다 표현식은 다음과 같은 방식으로 아주 좋은 바인딩된 메서드 참조로 작성될 수도 있다는 것을 알아차렸을 것입니다.

Comparator<Integer> comparator = Integer::compare;

(i1 - i2)를 사용하여 이 Comparator를 구현하지 마십시오. 이 패턴이 작동하는 것처럼 보이더라도 올바른 결과가 나오지 않는 경우가 있습니다.

이 패턴은 Comparator의 규칙을 따르는 한 비교해야 하는 모든 항목으로 확장될 수 있습니다.

Comparator API는 훨씬 더 읽기 쉬운 방식으로 Comparator를 생성하는 데 매우 유용한 API를 제공함으로써 한 단계 더 발전했습니다.

Factory Method를 사용하여 Comparator 생성

비자연적인 방식으로 문자열을 비교하기 위해 비교기를 만들어야 한다고 가정해 보겠습니다. 즉, 가장 짧은 문자열이 가장 긴 문자열보다 작습니다.

이러한 비교기는 다음과 같이 작성할 수 있습니다.

Comparator<String> comparator =
        (s1, s2) -> Integer.compare(s1.length(), s2.length());

이전 부분에서 람다 표현식을 연결하고 구성하는 것이 가능하다는 것을 배웠습니다. 이 코드는 그러한 구성의 또 다른 예입니다. 실제로 다음과 같이 다시 작성할 수 있습니다.

Function<String, Integer> toLength = String::length;
Comparator<String> comparator =
        (s1, s2) -> Integer.compare(
                toLength.apply(s1),
                toLength.apply(s2));

이제 이 비교기의 코드는 toLength라는 함수에만 의존한다는 것을 알 수 있습니다. 따라서 이 함수를 인수로 사용하고 해당 Comparator<String>을 반환하는 팩토리 메서드를 만드는 것이 가능해졌습니다.

toLength 함수의 반환 유형에는 여전히 제약이 있습니다. 즉, 비교할 수 있어야 합니다. 여기서는 항상 정수를 자연 순서와 비교할 수 있기 때문에 잘 작동하지만 이를 명심해야 합니다.

이러한 팩토리 메소드는 JDK에 존재하며 Comparator 인터페이스에 직접 추가되었습니다. 따라서 이전 코드를 다음과 같이 작성할 수 있습니다.

Comparator<String> comparator = Comparator.comparing(String::length);

이 comparing() 메서드는 Comparator 인터페이스의 static 메서드입니다. Comparable의 확장인 유형을 반환해야 하는 함수를 인수로 사용합니다.

getName() getter가 있는 User 클래스가 있고 이름에 따라 사용자 목록을 정렬해야 한다고 가정합니다. 작성해야 하는 코드는 다음과 같습니다.

List<User> users = ...; // this is your list
Comparator<User> byName = Comparator.comparing(User::getName);
users.sort(byName);

Comparator 연결

귀하가 근무하고 있는 회사는 현재 귀하가 제공한 Comparable<User>에 매우 만족하고 있습니다. 그러나 버전 2에는 새로운 요구 사항이 있습니다. 이제 User 클래스에는 firstName과 lastName이 있으며 이 변경 사항을 처리하려면 새 Comparator를 생성해야 합니다.

각 Comparator를 작성하는 것은 이전 Comparator와 동일한 패턴을 따릅니다.

Comparator<User> byFirstName = Comparator.comparing(User::getFirstName);
Comparator<User> byLastName = Comparator.comparing(User::getLastName);

이제 필요한 것은 Predicate 또는 Consumer의 인스턴스를 연결한 것처럼 이들을 연결하는 방법입니다. Comparator API는 이를 수행하는 솔루션을 제공합니다.

Comparator<User> byFirstNameThenLastName =
        byFirstName.thenComparing(byLastName);

thenComparing() 메서드는 Comparator 인터페이스의 기본 메서드로, 다른 Comparator를 인수로 사용하고 새 Comparator를 반환합니다. 두 명의 사용자에게 적용될 때 Comparator는 먼저 byFirstName Comparator를 사용하여 이러한 사용자를 비교합니다. 결과가 0이면 byLastName Comparator를 사용하여 비교합니다. 간단히 말해서 예상대로 작동합니다.

Comparator API는 한 단계 더 발전했습니다. byLastName은 User::getLastName 함수에만 의존하기 때문에 thenComparing() 메서드의 오버로드가 이 함수를 인수로 사용하는 API에 추가되었습니다. 따라서 패턴은 다음과 같습니다.

Comparator<User> byFirstNameThenLastName =
        Comparator.comparing(User::getFirstName)
                  .thenComparing(User::getLastName);

람다 식, 메서드 참조, 연결 및 구성을 사용하면 Comparator 를 만드는 것이 그 어느 때보다 쉬워졌습니다!

특수 Comparator

박싱(boxing) 및 언박싱(unboxing) 또는 기본 유형도 Comparator에서 발생할 수 있으며, 이로 인해 java.util.function 패키지의 Functional Interface의 경우와 동일한 성능 저하가 발생합니다. 이 문제를 해결하기 위해 Compare() 팩토리 메서드와 thenComparing() 기본 메서드의 특수 버전이 추가되었습니다.

다음을 사용하여 Comparator<T>의 인스턴스를 만들 수도 있습니다.

기본 유형인 속성을 사용하여 객체를 비교해야 하고 이 기본 유형의 박싱/언박싱을 피해야 하는 경우 이러한 방법을 사용합니다.

Comparator<T>를 연결하는 해당 메서드도 있습니다.

아이디어는 동일합니다. 이러한 메서드를 사용하면 박싱/언박싱으로 인한 성능 저하 없이 기본 유형을 반환하는 특수 함수를 기반으로 구축된 Comparator와 비교를 연결할 수 있습니다.

자연 순서를 사용하여 Comparable Object 비교

이 튜토리얼에는 간단한 Comparator를 만드는 데 도움이 되는 몇 가지 언급할 가치가 있는 팩토리 메서드가 있습니다.

JDK와 아마도 애플리케이션의 많은 클래스도 JDK의 특수 인터페이스인 Comparable<T> 인터페이스를 구현하고 있습니다. 이 인터페이스에는 int를 반환하는 CompareTo(T other) 메서드가 하나 있습니다. 이 메서드는 Comparator<T> 인터페이스의 계약에 따라 T의 이 인스턴스를 다른 인스턴스와 비교하는 데 사용됩니다.

JDK의 많은 클래스가 이미 이 인터페이스를 구현하고 있습니다. 이는 기본 유형(Integer, Long 등)의 모든 래퍼 클래스, String 클래스, Date 및 Time API의 날짜 및 시간 클래스에 해당됩니다.

자연 순서, 즉 이 CompareTo() 메서드를 사용하여 이러한 클래스의 인스턴스를 비교할 수 있습니다. Comparator API는 Comparator.naturalOrder() 팩토리 클래스를 제공합니다. 이것이 구축하는 Comparator는 정확히 그 일을 합니다. 즉, CompareTo() 메서드를 사용하여 모든 Comparable 객체를 비교합니다.

이러한 팩토리 메서드를 사용하면 Comparator를 연결해야 할 때 매우 유용할 수 있습니다. 다음은 문자열을 길이와 자연 순서와 비교하려는 예입니다(이 예에서는 가독성을 더욱 높이기 위해 naturalOrder() 메서드에 대한 정적 가져오기를 사용합니다).

Comparator<String> byLengthThenAlphabetically =
        Comparator.comparing(String::length)
                  .thenComparing(naturalOrder());
List<String> strings = Arrays.asList("one", "two", "three", "four", "five");
strings.sort(byLengthThenAlphabetically);
System.out.println(strings);

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

[one, two, five, four, three]

Comparator 반전

Comparator의 주요 용도 중 하나는 물론 객체 목록을 정렬하는 것입니다. JDK 8에서는 특히 이를 위해 List 인터페이스에 List.sort() 메서드가 추가되었습니다. 이 메서드는 비교기를 인수로 사용합니다.

이전 목록을 역순으로 정렬해야 하는 경우 Comparator 인터페이스의 reversed() 메서드를 사용할 수 있습니다.

List<String> strings =
        Arrays.asList("one", "two", "three", "four", "five");
strings.sort(byLengthThenAlphabetically.reversed());
System.out.println(strings);

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

[three, four, five, two, one]

Null 값 처리

null 개체를 비교하면 코드를 실행하는 동안 NullPointerException이 발생할 수 있습니다. 이는 피하고 싶은 일입니다.

정수 목록을 정렬하기 위해 null-safe 정수 Comparator를 작성해야 한다고 가정해 보겠습니다. 따르기로 결정한 규칙은 모든 null 값을 목록 끝에 푸시하는 것입니다. 즉, null 값은 null이 아닌 다른 값보다 큽니다. 그런 다음 null이 아닌 값을 자연 순서로 정렬하려고 합니다.

이 동작을 구현하기 위해 작성할 수 있는 코드 종류는 다음과 같습니다.

Comparator<Integer> comparator =
        (i1, i2) -> {
            if (i1 == null && i1 != null) {
                return 1;
            } else if (i1 != null && i2 == null) {
                return -1;
            } else {
                return Integer.compare(i1, i2);
            }
        };

이 코드를 이 부분의 시작 부분에서 작성한 첫 번째 비교기와 비교할 수 있으며 가독성이 큰 타격을 입었다는 것을 알 수 있습니다.

다행히도 Comparator 인터페이스의 또 다른 팩토리 메서드를 사용하여 이 비교기를 작성하는 훨씬 쉬운 방법이 있습니다.

Comparator<Integer> naturalOrder = Comparator.naturalOrder();

Comparator<Integer> naturalOrderNullsLast =
        Comparator.nullsLast(naturalOrder());

nullsLast() 및 그 형제 메소드인 nullsFirst()는 Comparator 인터페이스의 팩토리 메소드입니다. 둘 다 비교기를 인수로 사용하여 그 작업을 수행합니다. 즉, null 값을 처리하고, 끝까지 푸시하거나, 정렬된 목록의 첫 번째에 배치합니다.

예는 다음과 같습니다.

List<String> strings =
        Arrays.asList("one", null, "two", "three", null, null, "four", "five");
Comparator<String> naturalNullsLast =
        Comparator.nullsLast(naturalOrder());
strings.sort(naturalNullsLast);
System.out.println(strings);

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

[five, four, one, three, two, null, null, null]

람다 표현식 결합 (Combining Lambda Expressions)

환영전사 — Wed, 13 Sep 2023 15:54:14 +0900

원문 : https://dev.java/learn/lambdas/combining-chaining-composing/

Combining Lambda Expressions - Dev.java

Using Default and Static Methods to Combine and Create Lambdas.

dev.java

java.util.function 패키지의 Functional Interface에 Default Method가 있다는 것을 알아차렸을 것입니다. 이러한 메서드는 람다 식의 조합 및 연결을 허용하기 위해 추가되었습니다.

왜 그런 일을 하겠습니까? 더 간단하고 읽기 쉬운 코드를 작성하는 데 도움이 됩니다.

Default Method를 사용하여 Predicate 연결

null이 아니고, 비어 있지 않고, 5자보다 짧은 문자열만 유지하기 위해 문자열 목록을 처리해야 한다고 가정해 보겠습니다. 이 문제를 기술하는 방식은 다음과 같습니다. 특정 문자열에 대해 세 가지 테스트가 있습니다.

non-null;
non-empty;
shorter than 5 characters.

이러한 각 테스트는 매우 간단한 한 줄의 조건자로 쉽게 작성할 수 있습니다. 이 세 가지 테스트를 하나의 단일 조건자로 결합하는 것도 가능합니다. 다음 코드와 같습니다.

Predicate<String> p = s -> (s != null) && !s.isEmpty() && s.length() < 5;

그러나 JDK에서는 다음과 같은 방식으로 코드를 작성할 수 있습니다.

Predicate<String> nonNull = s -> s != null;
Predicate<String> nonEmpty = s -> s.isEmpty();
Predicate<String> shorterThan5 = s -> s.length() < 5;

Predicate<String> p = nonNull.and(nonEmpty).and(shorterThan5);

기술적인 복잡성을 숨기고 코드의 의도를 드러내는 것이 람다 식을 결합하는 것입니다.

이 코드는 API 수준에서 어떻게 구현됩니까? 세부 사항을 너무 깊이 파고들지 않고도 볼 수 있는 내용은 다음과 같습니다.

and()는 메소드입니다
Predicate<T>의 인스턴스에서 호출됩니다. 따라서 인스턴스 메서드입니다.
또 다른 Predicate<T>를 인수로 사용합니다.
Predicate<T>를 반환합니다.

Functional Interface에는 하나의 추상 메서드만 허용되므로 이 and() 메서드가 기본 메서드여야 합니다. 따라서 API 설계 관점에서 볼 때 이 메서드를 만드는 데 필요한 모든 요소가 있습니다. 좋은 소식은 Predicate<T> 인터페이스에는 and() 기본 메서드가 있으므로 직접 작성할 필요가 없다는 것입니다.

그런데 다른 Predicate를 인수로 취하는 or() 메소드도 있고, 아무것도 취하지 않는 negate() 메소드도 있습니다.

이를 사용하여 이전 예제를 다음과 같이 작성할 수 있습니다.

Predicate<String> isNull = Objects::isNull;
Predicate<String> isEmpty = String::isEmpty;
Predicate<String> isNullOrEmpty = isNull.or(isEmpty);
Predicate<String> isNotNullNorEmpty = isNullOrEmpty.negate();
Predicate<String> shorterThan5 = s -> s.length() < 5;

Predicate<String> p = isNotNullNorEmpty.and(shorterThan5);

이 예제가 한계를 조금 넘어서더라도 메소드 참조와 기본 메소드를 활용하여 코드의 표현력을 극적으로 향상시킬 수 있습니다.

Factory Method를 사용하여 Predicate 생성

Functional Interface에 정의된 팩토리 메서드를 사용하면 표현력을 한 단계 더 높일 수 있습니다. Predicate<T> 인터페이스에는 두 가지가 있습니다.

다음 예에서 isEqualToDuke 조건자는 문자열을 테스트합니다. 테스트된 문자열이 "Duke"와 같을 때 테스트는 참입니다. 이 팩토리 메소드는 모든 유형의 객체에 대한 조건자를 생성할 수 있습니다.

Predicate<String> isEqualToDuke = Predicate.isEqual("Duke");

두 번째 팩토리 메서드는 인수로 제공된 조건자를 부정합니다.

Predicate<Collection<String>> isEmpty = Collection::isEmpty;
Predicate<Collection<String>> isNotEmpty = Predicate.not(isEmpty);

Default Method를 사용하여 Consumer 연결

Consumer<T> 인터페이스에는 Consumer를 연결하는 방법도 있습니다. 다음 패턴을 사용하여 Consumer를 연결할 수 있습니다.

Logger logger = Logger.getLogger("MyApplicationLogger");
Consumer<String> log = message -> logger.info(message);
Consumer<String> print = message -> System.out.println(message);

Consumer<String> printAndLog = log.andThen(print);

이 예에서 printAndLog는 먼저 메시지를 log Consumer에게 전달한 다음 이를 print Consumer에게 전달하는 소비자입니다.

Default Method를 사용하여 Function 연결 및 구성

연결과 구성의 차이는 약간 미묘합니다. 두 작업의 결과는 실제로 동일합니다. 다른 점은 쓰는 방식입니다.

f1과 f2라는 두 가지 함수가 있다고 가정합니다. [f1.andThen(f2)를 호출하여 연결할 수 있습니다. 결과 함수를 객체에 적용하면 먼저 이 객체를 f1에 전달하고 결과를 f2에 전달합니다.

Function 인터페이스에는 f2.compose(f1)라는 두 번째 기본 메서드가 있습니다. 이런 방식으로 작성된 결과 함수는 먼저 객체를 f1 함수에 전달하여 객체를 처리한 다음 결과를 f2에 전달합니다.

깨달아야 할 것은 동일한 결과 함수를 얻으려면 f1에서 andThen()을 호출하거나 f2에서 compose()를 호출해야 한다는 것입니다.

다양한 유형의 기능을 연결하거나 구성할 수 있습니다. 그러나 분명한 제한 사항이 있습니다. f1에서 생성된 결과 유형은 f2에서 사용되는 유형과 호환되어야 합니다.

Identity Function 생성

Function<T, R> 인터페이스에는 ID()라는 ID 함수를 생성하는 팩토리 메서드도 있습니다.

따라서 다음과 같은 간단한 패턴을 사용하여 Identity Function를 생성할 수 있습니다.

Function<String, String> id = Function.identity();

이 패턴은 모든 유효한 유형에 적용 가능합니다.

메서드 참조로 람다 표현식 작성 (Writing Lambda Expressions as Method References)

환영전사 — Wed, 13 Sep 2023 15:06:18 +0900

원문 : https://dev.java/learn/lambdas/method-references/

Writing Lambda Expressions as Method References - Dev.java

Understanding Method References.

dev.java

람다 식이 실제로는 Functional Interface의 유일한 추상 메서드인 메서드의 구현임을 확인했습니다. 때때로 사람들은 이러한 람다 표현식을 "anonymous methods"라고 부는데, 그 이유가 이름이 없고, 필드나 변수에 저장되고, 메서드나 변수에 인수로 전달할 수 있고, 생성자와 메서드에서 반환 될 수 있기 때문입니다.

때로는 다른 곳에 정의된 특정 메서드를 호출하는 람다 식을 작성하는 경우도 있습니다. 그리고 실제로 다음 코드를 작성할 때 이미 해당 작업을 수행했습니다.

Consumer<String> printer = s -> System.out.println(s);

이렇게 작성된 이 람다 식은 System.out 개체에 정의된 println() 메서드에 대한 참조일 뿐입니다.

이것이 메소드 참조 구문이 들어오는 곳입니다.

첫 번째 Method 참조

때때로 람다 표현식은 기존 메서드에 대한 참조일 뿐입니다. 이 경우 메소드 참조로 작성할 수 있습니다. 이전 코드는 다음과 같습니다.

Consumer<String> 프린터 = System.out::println;
메서드 참조에는 네 가지 범주가 있습니다.

Static method references
Bound method references
Unbound method references
Constructor method references

프린터 Consumer는 바인딩되지 않은 메서드 참조 범주에 속합니다.

대부분의 경우 IDE는 특정 람다 표현식이 람다 표현식으로 작성될 수 있는지 알려줄 수 있습니다. 주저하지 말고 물어보세요!

Static Method 참조 작성

다음 코드가 있다고 가정합니다.

DoubleUnaryOperator sqrt = a -> Math.sqrt(a);

이 람다 표현식은 실제로 Static Method인 Math.sqrt()에 대한 참조입니다. 다음과 같은 방법으로 작성할 수 있습니다.

DoubleUnaryOperator sqrt = Math::sqrt;

이 특정 메서드 참조는 정적 메서드를 참조하므로 Static Method 참조라고 합니다. Static Method 참조의 일반 구문은 RefType::staticMethod입니다.

Static Method 참조는 두 개 이상의 인수를 사용할 수 있습니다. 다음 코드를 고려해보세요.

IntBinaryOperator max = (a, b) -> Integer.max(a, b);

메소드 참조를 사용하여 다시 작성할 수 있습니다.

IntBinaryOperator max = Integer::max;

Unbound Method 참조 작성

어떠한 인수도 취하지 않는 Method
다음 코드가 있다고 가정합니다.

Function<String, Integer> toLength = s -> s.length();

이 함수는 ToIntFunction<T>으로 작성할 수 있습니다. 이는 String 클래스의 length() 메소드에 대한 참조일 뿐입니다. 따라서 메소드 참조로 작성할 수 있습니다.

Function<String, Integer> toLength = String::length;

이 구문은 실제로 정적 호출처럼 보이기 때문에 처음에는 혼란스러울 수 있습니다. 그러나 실제로는 그렇지 않습니다. length() 메서드는 String 클래스의 인스턴스 메서드입니다.

이러한 메소드 참조를 사용하여 일반 Java Bean에서 모든 getter를 호출할 수 있습니다. getName()이 정의된 User 클래스가 있다고 가정합니다. 그렇다면, 다음 함수를 작성할 수 있습니다.

Function<User, String> getName = user -> user.getName();

다음 메소드 참조로:

Function<String, Integer> toLength = User::getName;

어떠한 인수도 취하지 않는 Method

이미 본 또 다른 예는 다음과 같습니다.

BiFunction<String, String, Integer> indexOf = (sentence, word) -> sentence.indexOf(word);

이 람다는 실제로 String 클래스의 indexOf() 메서드에 대한 참조이므로 다음 메서드 참조로 작성할 수 있습니다.

BiFunction<String, String, Integer> indexOf = String::indexOf;

이 구문은 꽤 간단한 String::length 또는 User::getName 예제보다 더 혼란스러워 보일 수 있습니다. 고전적인 방식으로 작성된 람다를 정신적으로 재구성하는 좋은 방법은 이 메서드 참조의 유형을 확인하는 것입니다. 그러면 이 람다가 취하는 인수가 제공됩니다.

바인딩되지 않은 메서드 참조의 일반 구문은 다음과 같습니다. RefType:instanceMethod, 여기서 RefType은 유형의 이름이고, instanceMethod는 인스턴스 메서드의 이름입니다.

Bound 메서드 참조 작성

여러분이 본 메서드 참조의 첫 번째 예는 다음과 같습니다.

Consumer<String> printer = System.out::println;

이 메서드 참조를 바인딩된 메서드 참조라고 합니다. 이 메서드 참조를 바인딩이라고 하는 이유는 메서드가 호출되는 개체가 메서드 참조 자체에 정의되어 있기 때문입니다. 따라서 이 호출은 메서드 참조에 지정된 개체에 바인딩됩니다.

바인딩되지 않은 구문인 Person::getName을 고려하면 메서드가 호출되는 개체가 이 구문의 일부가 아니며 람다 식의 인수로 제공된다는 것을 알 수 있습니다. 다음 코드를 고려해보세요.

Function<User, String> getName = User::getName;
User anna = new User("Anna");
String name = getName.apply(anna);

함수에 전달된 User의 특정 인스턴스에 함수가 적용되는 것을 볼 수 있습니다. 그런 다음 이 함수는 해당 인스턴스에서 작동합니다.

이전 Consumer 예제에서는 그렇지 않습니다. println() 메서드는 메서드 참조의 일부인 System.out 개체에서 호출됩니다.

바인딩된 메서드 참조의 일반 구문은 다음과 같습니다: expr:instanceMethod. 여기서 expr은 객체를 반환하는 표현식이고, instanceMethod는 인스턴스 메서드의 이름입니다.

생성자 메서드 참조 작성

알아야 할 마지막 메소드 참조 유형은 생성자 메소드 참조입니다. 다음과 같은 Supply<List<String>>이 있다고 가정합니다.

Supplier<List<String>> newListOfStrings = () -> new ArrayList<>();

나머지 부분과 동일한 방식으로 이를 볼 수 있습니다. 이는 결국 ArrayList의 빈 생성자에 대한 참조로 귀결됩니다. 음, 메서드 참조가 그렇게 할 수 있습니다. 그러나 생성자는 메서드가 아니므로 이는 메서드 참조의 또 다른 범주에 속합니다. 구문은 다음과 같습니다.

Supplier<List<String>> newListOfStrings = ArrayList::new;

여기서는 다이아몬드 연산자가 필요하지 않음을 알 수 있습니다. 이를 넣으려면 유형도 제공해야 합니다.

Supplier<List<String>> newListOfStrings = ArrayList<String>::new;

메소드 참조의 유형을 모르면 그것이 정확히 무엇을 하는지 알 수 없다는 사실을 알아야 합니다. 예는 다음과 같습니다.

Supplier<List<String>> newListOfStrings = () -> new ArrayList<>();
Function<Integer, List<String>> newListOfNStrings = size -> new ArrayList<>(size);

newListOfStrings 및 newListOfNStrings 변수는 모두 동일한 구문 ArrayList::new로 작성할 수 있지만 동일한 생성자를 참조하지는 않습니다. 그것만 조심하면 됩니다.

마무리 메소드 참조
다음은 네 가지 유형의 메소드 참조입니다.

람다 표현식 사용 (Using Lambdas Expressions in Your Application) - part 2/2

환영전사 — Tue, 12 Sep 2023 16:49:03 +0900

원문 : https://dev.java/learn/lambdas/functional-interfaces/

Predicate<T>를 사용하여 개체 테스트

Predicate 구현 및 사용

세 번째 인터페이스는 Predicate<T> 인터페이스입니다. Predicate는 개체를 테스트하는 데 사용됩니다. 나중에 보게 될 주제인 Stream API에서 스트림을 필터링하는 데 사용됩니다.

추상 메서드는 개체를 가져와 부울 값을 반환합니다. 이 인터페이스는 Consumer<T>보다 조금 더 복잡합니다. 여기에는 기본 메서드와 정적 메서드가 정의되어 있으며 이에 대해서는 나중에 살펴보겠습니다. abstract method에 집중해 보겠습니다.

@FunctionalInterface
public interface Predicate<T> {

    boolean test(T t);

    // default and static methods removed
}

이전 부분에서 Predicate<String>의 예를 이미 보았습니다.

Predicate<String> length3 = s -> s.length() == 3;

주어진 문자열을 테스트하려면 Predicate 인터페이스의 test() 메서드를 호출하기만 하면 됩니다.

String word = ...; // any word
boolean isOfLength3 = length3.test(word);
System.out.prinln("Is of length 3? " + isOfLength3);

특화된 Predicate 사용

정수 값을 테스트해야 한다고 가정해 보겠습니다. 다음 조건자를 작성할 수 있습니다.

Predicate<Integer> isGreaterThan10 = i -> i > 10;

Consumer, Supplier 및 이 Predicate도 마찬가지입니다. 이 Predicate가 인수로 취하는 것은 Integer 클래스의 인스턴스에 대한 참조이므로 이 값을 10과 비교하기 전에 이 개체는 자동으로 unboxing됩니다. 매우 편리하지만 오버헤드가 발생합니다.

JDK가 제공하는 솔루션은 Supplier 및 Consumer를 위한 솔루션과 동일합니다: 특수 Predicate. Predicate<String>과 함께 IntPredicate, LongPredicate 및 DoublePredicate라는 세 가지 특수 인터페이스가 있습니다. 추상 메서드는 모두 명명 규칙을 따릅니다. 모두 부울 값을 반환하므로 test()라는 이름을 붙이고 인터페이스에 해당하는 인수를 취합니다.

따라서 이전 예제를 다음과 같이 작성할 수 있습니다.

IntPredicate isGreaterThan10 = i -> i > 10;

람다 자체의 구문은 동일하다는 것을 알 수 있습니다. 유일한 차이점은 i가 이제 Integer가 아닌 int 유형이라는 것입니다.

BiPredicate를 사용하여 두 요소 테스트

Consumer<T>에서 본 규칙에 따라 JDK는 하나가 아닌 두 개의 요소를 테스트하는 BiPredicate<T, U> 인터페이스도 추가합니다. 인터페이스는 다음과 같습니다.

@FunctionalInterface
public interface BiPredicate<T, U> {

    boolean test(T t, U u);

    // default methods removed
}

다음은 이러한 BiPredicate의 예입니다.

BiPredicate<String, Integer> isOfLength = (word, length) -> word.length() == length;

다음 패턴으로 이 BiPredicate를 사용할 수 있습니다.

String word = ...; // really any word will do!
int length = 3;
boolean isWordOfLength3 = isOfLength.test(word, length);

기본 유형을 처리하는 BiPredicate<T, U>의 특수 버전은 없습니다.

Collection에 Predicate 전달

Collection framework에 추가된 메소드(removeIf()) 중 하나는 Predicate를 사용합니다. 이 메서드는 이 Predicate를 사용하여 Collection의 각 요소를 테스트합니다. 테스트 결과가 true이면 이 요소가 Collection에서 제거됩니다.

다음 예에서 이 패턴이 실제로 작동하는 것을 볼 수 있습니다.

List<String> immutableStrings =
        List.of("one", "two", "three", "four", "five");
List<String> strings = new ArrayList<>(immutableStrings);
Predicate<String> isOddLength = s -> s.length() % 2 == 0;
strings.removeIf(isOddLength);
System.out.println("strings = " + strings);

이 코드를 실행하면 다음과 같은 결과가 생성됩니다.

strings = [one, two, three]

이 예에서는 지적할 만한 몇 가지 사항이 있습니다.

보시다시피, RemoveIf()를 호출하면 이 Collection이 변경됩니다.
따라서 List.of() 팩토리 메소드에 의해 생성된 것과 같은 불변 Collection에 대해 RemoveIf()를 호출하면 안 됩니다. 변경할 수 없는 Collection에서 요소를 제거할 수 없기 때문에 그렇게 하면 Exception 발생합니다.
Arrays.asList()는 배열처럼 동작하는 Collection을 생성합니다. 기존 요소를 변경할 수 있지만 이 팩토리 메서드에서 반환된 목록에서 요소를 추가하거나 제거할 수는 없습니다. 따라서 이 목록에서 RemoveIf()를 호출해도 작동하지 않습니다.

Function<T, R>을 사용하여 개체를 다른 개체에 매핑

Function<T, R> 구현 및 사용

네 번째 인터페이스는 Function<T, R> 인터페이스입니다. 함수의 추상 메소드는 T 유형의 객체를 취하고 해당 객체를 다른 유형 U로 변환하여 반환합니다. 이 인터페이스에는 기본 메소드와 정적 메소드도 있습니다.

@FunctionalInterface
public interface Function<T, R> {

    R apply(U u);

    // default and static methods removed
}

Function<T, R>은 Stream API에서 Object를 다른 Object에 매핑하는 데 사용됩니다. 이에 대해서는 나중에 다룰 주제입니다. Predicate는 부울을 반환하는 특수한 유형의 함수로 볼 수 있습니다.

특화된 Function<T, R> 사용

이것은 문자열을 가져와 해당 문자열의 길이를 반환하는 함수의 예입니다.

Function<String, Integer> toLength = s -> s.length();
String word = ...; // any kind of word will do
int length = toLength.apply(word);

여기서도 박싱 및 언박싱 작업이 실제로 수행되는 모습을 볼 수 있습니다. 먼저 length() 메서드는 int를 반환합니다. 함수가 정수를 반환하므로 이 정수는 박스형으로 표시됩니다. 그러나 결과는 int 유형의 가변 길이에 할당되므로 Integer는 이 변수에 저장되도록 unboxing됩니다.

애플리케이션에서 성능이 문제가 되지 않는다면 이 박싱 및 언박싱은 실제로 큰 문제가 아닙니다. 문제가 된다면 아마도 이 박싱 및 언박싱을 피하고 싶을 것입니다.

JDK는 Function<T, R> 인터페이스의 특수 버전을 갖춘 솔루션을 제공합니다. 이 인터페이스 세트는 입력 인수 유형과 반환 유형 모두에 대해 특수 Function<T, R>가 정의되기 때문에 Supplier, Consumer<T> 또는 Predicate 범주에서 본 것보다 더 복잡합니다.

입력 인수와 출력 모두 네 가지 유형을 가질 수 있습니다.

a parameterized type T;
an int;
a long;
a double.

API 디자인에는 미묘함이 있기 때문에 여기서 끝나지 않습니다. Function<T, R>를 확장하는 UnaryOperator<T>라는 특별한 인터페이스가 있습니다. 이 단항 연산자 개념은 주어진 유형의 인수를 취하고 동일한 유형의 결과를 반환하는 함수의 이름을 지정하는 데 사용됩니다. 단항 연산자는 여러분이 기대하는 바로 그 것입니다. 모든 고전 수학 연산자는 UnaryOperator<T>로 모델링할 수 있습니다(제곱근, 모든 삼각 연산자, 로그 및 지수).

다음은 java.util.function 패키지에서 찾을 수 있는 16가지 특수 유형의 함수입니다.

이러한 인터페이스의 모든 추상 메소드는 동일한 규칙을 따릅니다. 즉, 해당 함수의 반환된 유형을 따라 이름이 지정됩니다. 그들의 이름은 다음과 같습니다:

일반 유형 T를 반환하는 함수에 대한 apply()
applyAsInt() 기본 유형 int를 반환하는 경우
applyAsLong() 오랫동안
더블의 경우 applyAsDouble()

단항 연산자를 목록에 전달

UnaryOperator<T>를 사용하여 목록의 요소를 변환할 수 있습니다. 왜 기본 Function이 아닌 UnaryOperator<T>가 필요한지 궁금할 수 있습니다. 대답은 실제로 매우 간단합니다. 일단 선언되면 목록 유형을 변경할 수 없습니다. 따라서 적용한 함수는 목록의 요소를 변경할 수 있지만 해당 유형은 변경할 수 없습니다.

이 단항 연산자를 사용하는 메서드는 이를 replacementAll() 메서드에 전달합니다. 예는 다음과 같습니다.

List<String> strings = Arrays.asList("one", "two", "three");
UnaryOperator<String> toUpperCase = word -> word.toUpperCase();
strings.replaceAll(toUpperCase);
System.out.println(strings);

이 코드를 실행하면 다음이 표시됩니다.

[ONE, TWO, THREE]

이번에는 Arrays.asList() 패턴으로 생성된 목록을 사용했습니다. 실제로 해당 목록에 요소를 추가하거나 제거할 필요가 없습니다. 이 코드는 각 요소를 하나씩 수정하며, 이는 이 특정 목록에서 가능합니다.

BiFunction을 사용하여 두 요소 매핑

Consumer 및 Predicate의 경우 함수에는 이중 함수라는 두 가지 인수를 사용하는 버전도 있습니다. 동일하게 BiFunction<T, U, R>이 있습니다. 여기서 T와 U는 인수이고 R은 반환된 유형입니다. 인터페이스는 다음과 같습니다.

@FunctionalInterface
public interface BiFunction<T, U, R> {

    R apply(T t, U u);

    // default methods removed
}

람다 표현식을 사용하여 BiFunction를 만들 수 있습니다.

BiFunction<String, String, Integer> findWordInSentence =
    (word, sentence) -> sentence.indexOf(word);

UnaryOperator<T> 인터페이스에는 BiFunction<T, U, R>을 확장하는 BinaryOperator<T>라는 두 개의 인수가 있는 형제 인터페이스도 있습니다. 예상한 대로 네 가지 기본 산술 연산은 BinaryOperator를 사용하여 모델링할 수 있습니다.

BiFunction의 가능한 모든 특수 버전의 하위 집합이 JDK에 추가되었습니다.

IntBinaryOperator, LongBinaryOperator 및 DoubleBinaryOperator
ToIntBiFunction<T>, ToLongBiFunction<T> 및 ToDoubleBiFunction<T>

Functional Interface의 네 가지 범주 요약

java.util.function 패키지는 이제 Java의 핵심입니다. Collections Framework 또는 Stream API에서 사용할 모든 람다 표현식이 해당 패키지의 인터페이스 중 하나를 구현하기 때문입니다.
보시다시피 이 패키지에는 많은 인터페이스가 포함되어 있어 인터페이스를 찾는 것이 까다로울 수 있습니다.

먼저, 기억해야 할 것은 인터페이스에는 4가지 범주가 있다는 것입니다.

Supplier: 어떤 주장도 받아들이지 말고, 무언가를 반환하십시오
Consumer: 인수를 받고 아무것도 반환하지 않음
Predicates: 인수를 취하고 부울을 반환합니다.
Fucntion: 인수를 취하고, 무언가를 반환합니다.

둘째: 일부 인터페이스에는 하나가 아닌 두 개의 인수를 취하는 버전이 있습니다.

the biconsumers
the bipredicates
the bifunctions

셋째: 일부 인터페이스에는 박싱 및 언박싱을 방지하기 위해 추가된 특수 버전이 있습니다. 다 나열하기에는 너무 많습니다. 그들은 그들이 취하는 유형의 이름을 따서 명명되었습니다. 예: IntPredicate 또는 ToLongFunction<T>에서와 같이 반환되는 유형입니다. IntToDoubleFunction 두 가지 모두의 이름을 따서 명명될 수 있습니다.

마지막으로 모든 유형이 동일한 경우를 위한 Function<T, R> 및 BiFunction<T, U, R>의 확장(UnaryOperator<T> 및 BinaryOperator<T>)이 있으며 기본 유형에 대한 특수 버전이 있습니다.

람다 표현식 사용 (Using Lambdas Expressions in Your Application) - part 1/2

환영전사 — Tue, 12 Sep 2023 16:04:03 +0900

https://dev.java/learn/lambdas/functional-interfaces/ 번역하여 제공

Java SE 8에 람다 표현식이 도입되면서 JDK API가 대대적으로 변경되었습니다. Generic 도입 후 JDK 5보다 lamdbas 도입 후 JDK 8에서 더 많은 클래스가 업데이트되었습니다.

Functional interface의 매우 간단한 정의 덕분에 기존의 많은 인터페이스를 수정하지 않고도 기능적으로 사용할 수 있게 되었습니다. 기존 코드도 마찬가지입니다. Java SE 8 이전에 작성된 애플리케이션에 인터페이스가 있는 경우 해당 인터페이스를 건드리지 않고도 작동할 수 있으므로 람다를 사용하여 구현할 수 있습니다.

java.util.function 패키지 발견

JDK 8에는 애플리케이션에서 사용할 수 있는 Functional interface가 포함된 java.util.function이라는 새로운 패키지도 도입되었습니다. 이러한 Functional interface는 JDK API, 특히 Collections Framework 및 Stream API에서도 많이 사용됩니다. 이 패키지는 java.base 모듈에 있습니다.

인터페이스가 40개가 조금 넘으므로 이 패키지는 처음에는 조금 무섭게 보일 수 있습니다. 이는 4개의 주요 인터페이스를 중심으로 구성되어 있는 것으로 나타났습니다. 그것들을 이해하면 다른 모든 것을 이해하는 열쇠가 됩니다.

Supplier<T>를 사용하여 개체 생성 또는 제공

Supplier<T> 인터페이스 구현

첫 번째 인터페이스는 Supplier<T> 인터페이스입니다. 간단히 말해서 공급자는 인수를 사용하지 않고 개체를 반환합니다.

Supplier 인터페이스를 구현하는 람다는 어떤 인수도 취하지 않고 객체를 반환한다고 말해야 합니다. 혼란스럽지 않은 한 바로가기를 만들면 기억하기가 더 쉬워집니다.

이 인터페이스는 정말 간단합니다. 기본 메소드나 정적 메소드가 없고 일반 get() 메소드만 있습니다. 이 인터페이스는 다음과 같습니다.

@FunctionalInterface
public interface Supplier<T> {

    T get();
}

다음 람다는 이 인터페이스를 구현한 것입니다.

Supplier<String> supplier = () -> "Hello Duke!";`

이 람다 식은 단순히 Hello Duke!를 반환합니다. 문자열. 호출될 때마다 새 객체를 반환하는 Supplier를 작성할 수도 있습니다.

Random random = new Random(314L);
Supplier<Integer> newRandom = () -> random.nextInt(10);

for (int index = 0; index < 5; index++) {
    System.out.println(newRandom.get() + " ");
}

이 Supplier의 get() 메서드를 호출하면 random.nextInt()가 호출되고 임의의 정수가 생성됩니다. 이 난수 생성기의 시드는 값 314L로 고정되어 있으므로 다음과 같은 난수 정수가 생성되는 것을 볼 수 있습니다.

이 람다는 바깥쪽 범위(random)에서 변수를 캡처하여 이 변수를 효과적으로 최종 변수로 만듭니다.

Supplier<T> 사용
이전 예에서 newRandom를 사용하여 난수를 생성한 방법에 유의하세요.

for (int index = 0; index < 5; index++) {
    System.out.println(newRandom.get() + " ");
}

Supplier 인터페이스의 get() 메서드를 호출하면 람다가 호출됩니다.

Specialized Supplier 활용

람다 표현식은 애플리케이션에서 데이터를 처리하는 데 사용됩니다. 그래서 JDK에서는 람다 표현식을 얼마나 빨리 실행할 수 있는지가 중요합니다. 절약할 수 있는 모든 CPU 주기는 절약해야 합니다. 왜냐하면 이는 실제 애플리케이션에서 중요한 최적화를 나타내기 때문입니다.

이 원칙에 따라 JDK API는 또한 Manufacturer<T> 인터페이스의 전문화되고 최적화된 버전을 제공합니다.

두 번째 예제에서는 Random.nextInt() 메서드가 int를 반환하는 Integer 유형을 제공한다는 점을 눈치챘을 것입니다. 따라서 작성한 코드에는 내부적으로 두 가지 일이 발생합니다.

Random.nextInt()에 의해 반환된 int는 먼저 자동 박싱 메커니즘에 의해 Integer로 박싱됩니다.
이 정수는 자동 언박싱 메커니즘에 의해 nextRandom 변수에 할당될 때 언박싱됩니다.

자동 박싱은 int 값을 Integer 객체에 직접 할당할 수 있는 메커니즘입니다.

int i = 12;
Integer integer = i;

내부적으로는 해당 값을 래핑하는 객체가 생성됩니다.

자동 언박싱은 그 반대입니다. Integer 내의 값을 풀어서 Integer를 int 값에 할당할 수 있습니다.

Integer integer = Integer.valueOf(12);
int i = integer;

본 싱/언박싱은 무료로 제공되지 않습니다. 대부분의 경우 이 비용은 데이터베이스나 원격 서비스에서 데이터를 가져오는 등 애플리케이션이 수행하는 다른 작업에 비해 적습니다. 그러나 어떤 경우에는 이 비용이 용납되지 않을 수 있으므로 지불을 피해야 합니다.

좋은 소식은 JDK가 IntSupplier 인터페이스를 갖춘 솔루션을 제공한다는 것입니다. 이 인터페이스는 다음과 같습니다.

@FunctionalInterface
public interface IntSupplier {

    int getAsInt();
}

이 인터페이스를 구현하기 위해 정확히 동일한 코드를 사용할 수 있습니다.

Random random = new Random(314L);
IntSupplier newRandom = () -> random.nextInt();

애플리케이션 코드에 대한 유일한 수정 사항은 get() 대신 getAsInt()를 호출해야 한다는 것입니다.

for (int i = 0; i < 5; i++) {
    int nextRandom = newRandom.getAsInt();
    System.out.println("next random = " + nextRandom);
}

이 코드를 실행한 결과는 동일하지만 이번에는 박싱/언박싱이 발생하지 않았습니다. 이 코드는 이전 코드보다 성능이 더 좋습니다.

JDK는 응용 프로그램에서 불필요한 boxing/unboxing을 피하기 위해 IntSupplier, BooleanSupplier, LongSupplier 및 DoubleSupplier라는 네 가지 specialized supplier를 제공합니다.

기본 유형을 처리하기 위해 이러한 특수 버전의 기능적 인터페이스를 더 많이 볼 수 있습니다. 추상 메서드에 대한 간단한 명명 규칙이 있습니다. 기본 추상 메서드(Supplier의 경우 get())의 이름을 취하고 여기에 반환된 유형을 추가합니다. 따라서 Supplier 인터페이스의 경우 getAsBoolean(), getAsInt(), getAsLong() 및 getAsDouble()이 있습니다.

Consumer<T>를 사용하여 객체 소비

소비자 구현 및 사용
두 번째 인터페이스는 Consumer<T> 인터페이스입니다. Consumer는 Supplier와 반대되는 역할을 합니다. 즉, 인수를 취하고 아무것도 반환하지 않습니다.

인터페이스는 조금 더 복잡합니다. 이 튜토리얼의 뒷부분에서 다룰 기본 메소드가 있습니다. Abstract method에 집중해 보겠습니다.

@FunctionalInterface
public interface Consumer<T> {

    void accept(T t);

    // default methods removed
}

이미 소비자를 구현했습니다.

Consumer<String> printer = s -> System.out.println(s);

이 소비자를 사용하여 이전 예제를 업데이트할 수 있습니다.

for (int i = 0; i < 5; i++) {
    int nextRandom = newRandom.getAsInt();
    printer.accept("next random = " + nextRandom);
}

Specialized Consumer 사용

정수를 인쇄해야 한다고 가정해 보겠습니다. 그런 다음 다음 소비자를 작성할 수 있습니다.

Consumer<Integer> printer = i -> System.out.println(i);`

그러면 공급업체 예와 동일한 자동 박싱 문제에 직면할 수 있습니다. 성능 측면에서 이 박싱/언박싱이 애플리케이션에서 허용됩니까?

그렇지 않은 경우에도 걱정하지 마십시오. JDK에서는 IntConsumer, LongConsumer 및 DoubleConsumer라는 세 가지 특수 Consumer를 사용할 수 있습니다. 이 세 Consumer의 추상 메소드는 Supplier와 동일한 규칙을 따르며, 반환된 유형은 항상 void이므로 모두 accept라는 이름이 지정됩니다.

BiConsumer로 두 요소 소비하기
그런 다음 JDK는 BiConsumer<T, U> 인터페이스라고 하는 하나의 인수 대신 두 개의 인수를 사용하는 Consumer<T> 인터페이스의 또 다른 변형을 추가합니다. 이 인터페이스는 다음과 같습니다.

@FunctionalInterface
public interface BiConsumer<T, U> {

    void accept(T t, U u);

    // default methods removed
}

다음은 BiConsumer의 예입니다.

BiConsumer<Random, Integer> randomNumberPrinter =
        (random, number) -> {
            for (int i = 0; i < number; i++) {
                System.out.println("next random = " + random.nextInt());
            }
        };

이 이중 소비자를 사용하여 이전 예제를 다르게 작성할 수 있습니다.

randomNumberPrinter.accept(new Random(314L), 5));

기본 유형을 처리하는 BiConsumer<T, U> 인터페이스에는 ObjIntConsumer<T>, ObjLongConsumer<T> 및 ObjDoubleConsumer<T>라는 세 가지 특수 버전이 있습니다.

Consumer를 Iterable에 전달하기
이 튜토리얼의 다른 부분에서 다루는 몇 가지 중요한 메소드가 컬렉션 프레임워크의 인터페이스에 추가되었습니다. 그 중 하나는 Consumer<T>를 인수로 취하며 매우 유용합니다: Iterable.forEach() 메서드입니다. 다음은 어디에서나 볼 수 있는 간단한 예입니다.

List<String> strings = ...; // really any list of any kind of objects
Consumer<String> printer = s -> System.out.println(s);
strings.forEach(printer);

이 마지막 코드 줄은 소비자를 목록의 모든 개체에 적용합니다. 여기서는 콘솔에 하나씩 간단히 인쇄합니다. 나중에 이 소비자를 작성하는 다른 방법을 살펴보겠습니다.

이 forEach() 메서드는 Iterable의 모든 요소에 대한 내부 반복에 액세스하는 방법을 노출하여 이러한 각 요소에 대해 수행해야 하는 작업을 전달합니다. 이는 이를 수행하는 매우 강력한 방법이며 코드를 더 읽기 쉽게 만듭니다.

첫 번째 람다 표현식 작성 (Writing Your First Lambda Expression)

환영전사 — Tue, 12 Sep 2023 14:41:36 +0900

https://dev.java/learn/lambdas/first-lambdas/ 번역하여 포스팀합니다.

2014년 Java SE 8에서는 람다 표현식 개념이 도입되었습니다. Java SE 8이 출시되기 전을 기억하신다면 아마도 Anonymous class 개념을 기억하실 것입니다. 그리고 람다 표현식이 일부 정확한 경우 Anonymous class의 인스턴스를 작성하는 또 다른 간단한 방법이라는 것을 들어보셨을 것입니다.

그 시절을 기억하지 못한다면 Anonymous class에 대해 듣거나 읽어본 적이 있을 것이며 아마도 이 모호한 구문이 두려울 것입니다.

좋은 소식은 람다 식을 작성하는 방법을 이해하기 위해 Anonymous class을 거칠 필요가 없다는 것입니다. 또한 많은 경우 Java 언어에 람다가 추가되어 Anonymous class가 더 이상 필요하지 않습니다.

람다 식을 작성하면 다음 세 단계를 이해하게 됩니다.

작성하려는 람다 표현식의 유형 식별
구현에 적합한 Method 찾기
이 Method을 구현합니다.

이것이 정말로 전부입니다. 이 세 단계를 자세히 살펴보겠습니다.

람다 표현식의 유형 식별

Java 언어의 Type은 컴파일 타임에 인식됩니다. 따라서 람다 표현식의 Type을 찾는 것은 항상 가능합니다. 변수 Type, 필드 Type, 메소드 매개변수 Type 또는 메소드의 반환 Type일 수 있습니다.

람다 식의 Type에는 제한이 있습니다. 함수형 인터페이스여야 합니다. 따라서 기능적 인터페이스를 구현하지 않는 Anonymous class는 람다 식으로 작성할 수 없습니다.

기능적 인터페이스가 무엇인지에 대한 완전한 정의는 약간 복잡합니다. 이 시점에서 알아야 할 것은 기능적 인터페이스는 추상 메서드가 하나만 있는 인터페이스라는 것입니다.

Java SE 8부터 인터페이스에서 concrete method가 허용된다는 점을 알아야 합니다. instance method일 수 있으며, 이 경우 default method라고 하며 static method일 수 있습니다. 이러한 메서드는 abstract method가 아니기 때문에 포함되지 않습니다.

인터페이스가 작동하게 하려면 인터페이스에 @FunctionalInterface 주석을 추가해야 합니까?

아니, 그렇지 않습니다. 이 Annotation은 인터페이스가 실제로 작동하는지 확인하는 데 도움이 됩니다. 기능적 인터페이스가 아닌 유형에 이 Annotation을 넣으면 컴파일러에서 오류가 발생합니다.

Functional Interface의 예
JDK API에서 가져온 몇 가지 예를 살펴보겠습니다. 방금 소스 코드에서 주석을 제거했습니다.

@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

Runnable 인터페이스는 abstract method가 하나만 있기 때문에 실제로 Functional Interface입니다. @FunctionalInterface 주석이 도우미로 추가되었지만 필요하지 않습니다.

@FunctionalInterface
public interface Consumer<T> {

    void accept(T t);

    default Consumer<T> andThen(Consumer<? super T> after) {
        // the body of this method has been removed
    }
}

Consumer<T> 인터페이스도 Functional Interface입니다. 하나의 abstract method와 하나의 default method가 있지만 카운트되지 않습니다. 다시 한번 말하지만, @FunctionalInterface 주석은 필요하지 않습니다.

@FunctionalInterface
public interface Predicate<T> {

    boolean test(T t);

    default Predicate<T> and(Predicate<? super T> other) {
        // the body of this method has been removed
    }

    default Predicate<T> negate() {
        // the body of this method has been removed
    }

    default Predicate<T> or(Predicate<? super T> other) {
        // the body of this method has been removed
    }

    static <T> Predicate<T> isEqual(Object targetRef) {
        // the body of this method has been removed
    }

    static <T> Predicate<T> not(Predicate<? super T> target) {
        // the body of this method has been removed
    }
}

Predicate<T> 인터페이스는 조금 더 복잡하지만 여전히 Functional Interface입니다.

하나의 추상 메소드가 있습니다
포함되지 않는 세개의 default method이 있습니다.
카운트하지 않는 두개 static method가 있습니다.

구현에 적합한 Method 찾기

이 시점에서 작성해야 하는 람다 표현식의 유형을 식별했으며 좋은 소식은 가장 어려운 부분을 완료했다는 것입니다. 나머지는 매우 기계적이고 수행하기 쉽습니다.

람다 식은 이 기능적 인터페이스의 유일한 추상 메서드를 구현한 것입니다. 따라서 구현할 올바른 Method을 찾는 것은 단지 이 Method을 찾는 문제일 뿐입니다.

잠시 시간을 내어 이전 단락의 세 가지 예를 살펴보세요.

Runnable 인터페이스의 경우 다음과 같습니다.

public abstract void run();

Predicate 인터페이스의 경우 다음과 같습니다.

boolean test(T t);

Consumer<T> 인터페이스의 경우 다음과 같습니다.

void accept(T t);

람다 표현식을 사용하여 올바른 메서드 구현

Predicate<String>을 구현하는 첫 번째 람다 표현식 작성
이제 마지막 부분입니다: 람다 자체를 작성합니다. 이해해야 할 것은 작성 중인 람다 표현식이 찾은 추상 메서드의 구현이라는 것입니다. 람다 표현식 구문을 사용하면 다음을 수행할 수 있습니다. 람다 식 구문을 사용하면 이 구현을 코드에 효과적으로 인라인할 수 있습니다.

이 구문은 세 가지 요소로 구성됩니다.

매개변수 블록
화살표를 묘사한 작은 ASCII 아트 조각: ->. Java는 굵은 화살표(=>)가 아닌 빈약한 화살표(->)를 사용합니다.
메소드의 본문인 코드 블록입니다.

이에 대한 예를 살펴보겠습니다. 정확히 3개의 문자로 이루어진 문자열에 대해 true를 반환하는 Predicate의 인스턴스가 필요하다고 가정해 보겠습니다.

람다 식의 유형은 Predicate입니다.
구현해야 할 방법은 boolean test(String s)입니다.

그런 다음 메소드 서명의 간단한 복사/붙여넣기인 매개변수 블록을 작성합니다: (String s).
그런 다음 빈약한 화살표(->)를 추가합니다.
그리고 메서드의 본문입니다. 결과는 다음과 같아야 합니다.

Predicate<String> predicate =
    (String s) -> {
        return s.length() == 3;
    };

구문 단순화
이 구문은 사용자가 작성할 필요가 없도록 많은 것을 추측할 수 있는 컴파일러 덕분에 단순화될 수 있습니다.

첫째, 컴파일러는 Predicate 인터페이스의 추상 메소드를 구현하고 있다는 것을 알고 있으며 이 메소드가 문자열을 인수로 사용한다는 것을 알고 있습니다. 따라서 (String s)는 (s)로 단순화될 수 있습니다. 이 경우 인수가 하나만 있는 경우 괄호를 제거하여 한 단계 더 나아갈 수도 있습니다. 그러면 인수 블록은 s가 됩니다. 인수가 두 개 이상이거나 인수가 없는 경우 괄호를 유지해야 합니다.

둘째, 메서드 본문에는 코드 한 줄만 있습니다. 이 경우 중괄호나 return 키워드가 필요하지 않습니다.

따라서 최종 구문은 실제로 다음과 같습니다.

Predicate<String> predicate = s -> s.length() == 3;

이것이 첫 번째 모범 사례로 이어집니다. 람다를 짧게 유지하여 간단하고 읽기 쉬운 한 줄의 코드가 되도록 하세요.

Consumer<String> 구현
어떤 시점에서 사람들은 지름길을 택하고 싶은 유혹을 받을 수도 있습니다. 개발자가 "Consumer는 객체를 가져오고 아무것도 반환하지 않습니다"라고 말하는 것을 듣게 될 것입니다. 또는 "문자열에 정확히 3개의 문자가 있으면 조건자는 참입니다." 대부분의 경우 람다 식, 람다 식에서 구현하는 추상 메서드, 이 메서드를 보유하는 기능적 인터페이스 간에 혼동이 있습니다.

그러나 기능적 인터페이스, 추상 메서드 및 이를 구현하는 람다 식은 서로 밀접하게 연결되어 있으므로 실제로 이러한 방식이 완전히 의미가 있습니다. 따라서 모호함으로 이어지지 않는 한 괜찮습니다.

문자열을 사용하고 System.out에 인쇄하는 람다를 작성해 보겠습니다. 구문은 다음과 같습니다.

Consumer<String> print = s -> System.out.println(s);

여기서 우리는 람다 표현식의 단순화된 버전을 직접 작성했습니다.

Runnable 구현
Runnable을 구현하면 void run() 구현이 작성됩니다. 이 인수 블록은 비어 있으므로 괄호로 묶어서 작성해야 합니다. 기억하세요: 인수가 하나인 경우에만 괄호를 생략할 수 있습니다. 여기서는 인수가 0입니다.

이제 실행 중임을 알려주는 실행 파일을 작성해 보겠습니다.

Runnable runnable = () -> System.out.println("I am running");

람다 표현식 호출

이전 Predicate 예제로 돌아가서 이 조건자가 메서드에 정의되었다고 가정해 보겠습니다. 주어진 문자열의 길이가 실제로 3인지 테스트하는 데 어떻게 사용할 수 있습니까?

글쎄, 람다를 작성하는 데 사용한 구문에도 불구하고 이 람다는 인터페이스 Predicate의 인스턴스라는 점을 명심해야 합니다. 이 인터페이스는 문자열을 가져와 부울을 반환하는 test()라는 메서드를 정의합니다.

이를 메소드로 작성해 보겠습니다.

List<String> retainStringsOfLength3(List<String> strings) {

    Predicate<String> predicate = s -> s.length() == 3;
    List<String> stringsOfLength3 = new ArrayList<>();
    for (String s: strings) {
        if (predicate.test(s)) {
            stringsOfLength3.add(s);
        }
    }
    return stringsOfLength3;
}

이전 예에서와 마찬가지로 조건자를 어떻게 정의했는지 살펴보세요. Predicate 인터페이스는 이 메서드 boolean test(String)를 정의하므로 Predicate 유형의 변수를 통해 Predicate에 정의된 메서드를 호출하는 것이 완벽하게 적법합니다. 이 조건자 변수는 메서드를 정의하는 것처럼 보이지 않기 때문에 처음에는 혼란스러워 보일 수 있습니다.

이 코드를 작성하는 훨씬 더 좋은 방법이 있으니 이 튜토리얼의 뒷부분에서 살펴보겠습니다.

따라서 람다를 작성할 때마다 이 람다에서 구현하는 인터페이스에 정의된 모든 메서드를 호출할 수 있습니다. 추상 메소드를 호출하면 람다 자체의 코드가 호출됩니다. 왜냐하면 이 람다는 해당 메소드의 구현이기 때문입니다. 기본 메소드를 호출하면 인터페이스에 작성된 코드가 호출됩니다. 람다가 기본 메서드를 재정의할 수 있는 방법은 없습니다.

Local Value 캡처링

익숙해지면 람다 작성이 매우 자연스러워집니다. 이는 Collections Framework, Stream API 및 JDK의 다른 많은 것들에 매우 잘 통합되어 있습니다. Java SE 8부터 람다는 어디에나 최고의 기능을 제공합니다.

람다 사용에는 제약이 있으며, 컴파일 타임 오류가 발생하는 경우가 있습니다.

다음 코드를 고려해 보겠습니다.

int calculateTotalPrice(List<Product> products) {

    int totalPrice = 0;
    Consumer<Product> consumer =
        product -> totalPrice += product.getPrice();
    for (Product product: products) {
        consumer.accept(product);
    }
}

이 코드가 괜찮아 보이더라도 컴파일하려고 하면 이 Consumer 구현에서 totalPrice를 사용할 때 다음과 같은 오류가 발생합니다.

Variable used in lambda expression should be final or effectively final

그 이유는 다음과 같습니다. 람다는 본문 외부에 정의된 변수를 수정할 수 없습니다. final, 즉 불변인 한 읽을 수 있습니다. 변수에 액세스하는 이 프로세스를 캡처라고 합니다. 람다는 변수를 캡처할 수 없으며 값만 캡처할 수 있습니다. final 변수는 실제로 값입니다.

오류 메시지는 변수가 최종일 수 있음을 알려주며 이는 Java 언어의 고전적인 개념입니다. 또한 변수가 사실상 final 일 수 있음을 알려줍니다. 이 개념은 Java SE 8에서 도입되었습니다. final 변수를 명시적으로 선언하지 않더라도 컴파일러가 이를 수행할 수 있습니다. 이 변수가 람다에서 읽혀지고 수정되지 않은 것으로 확인되면 final 선언이 멋지게 추가됩니다. 물론 이는 컴파일된 코드에서 수행되며 컴파일러는 소스 코드를 수정하지 않습니다. 이러한 변수를 final이라고 부르지는 않습니다. 사실상 final 변수라고 불립니다. 이것은 매우 유용한 기능입니다.

람다 직렬화

람다 표현식은 직렬화할 수 있도록 구축되었습니다.

람다 표현식을 직렬화하는 이유는 무엇입니까? 람다 표현식은 필드에 저장될 수 있으며 이 필드는 생성자 또는 setter 메서드를 통해 액세스될 수 있습니다. 그런 다음 런타임에 개체 상태를 인식하지 못한 채 람다 표현식이 있을 수 있습니다.

따라서 기존 직렬화 가능 클래스와의 역호환성을 유지하기 위해 람다 식을 직렬화하는 것이 가능합니다.

JMeter Test Plan

환영전사 — Thu, 7 Sep 2023 16:22:13 +0900

JMeter에서 Test Plan은 성능 테스트 시나리오의 컨테이너 역할을 하는 기본 구성 요소입니다. 이는 본질적으로 성능 테스트를 위한 청사진으로, 테스트의 구조, 설정 및 논리를 간략하게 설명합니다.

다음은 JMeter 테스트 계획과 주요 구성 요소에 대한 개요입니다.

Test Plan:
- JMeter 테스트 스크립트의 최상위 요소는 "Test Plan"입니다. 성능 테스트를 구성하는 모든 요소와 구성 요소에 대한 기본 컨테이너 역할을 합니다.
Thread Group:
- Test Plan 내에서 "Thread Group" 요소는 가상 사용자(스레드)의 특성과 요청 실행 방법을 정의하는 곳입니다. 스레드 개수, 램프업 시간, 반복횟수와 같은 세부 정보를 지정합니다.
Controllers:
- Controller는 스레드 그룹 내 요청의 순서와 흐름을 결정하는 요소입니다.
  Common controllers include:
  - HTTP Request Defaults: Sets default values for HTTP requests within the thread group.
  - Recording Controller: Groups requests generated during recording.
  - Transaction Controller: Groups requests into transactions for measuring response times.
  - Loop Controller: Specifies how many times a child element should be executed.
  - If Controller: Allows conditional execution of child elements.
  - While Controller: Repeats execution of child elements while a condition is true.
  - Random Controller: Randomly selects child elements for execution.
  - Switch Controller: Routes requests based on a condition.
Samplers:
- Sampler는 대상 서버에 요청을 보내는 일을 담당합니다.
  Common samplers include:
  - HTTP Request: Sends HTTP or HTTPS requests to a web server.
  - FTP Request: Performs FTP operations.
  - JDBC Request: Sends SQL queries to a database.
  - TCP Sampler: Sends custom TCP requests.
  - SMTP Sampler: Sends emails.
  - SOAP/XML-RPC Request: Sends SOAP or XML-RPC requests.
Listeners:
- Listener는 테스트 결과를 수집하고 표시하는 데 사용되는 요소입니다. 응답 시간, 오류율 및 기타 측정항목에 대한 정보를 제공합니다.
  Common listeners include:
  - View Results Tree: Displays results in a tree-like structure.
  - Summary Report: Provides a summary of test results.
  - Aggregate Report: Generates an aggregate report with statistics.
  - Graphs (e.g., Response Times Over Time): Displays test data graphically.
  - CSV Output: Writes results to a CSV file.
  - Assertion Results: Shows the outcome of assertion checks.
Timers:
- Timer를 사용하면 요청이나 스레드 간에 지연을 도입할 수 있습니다. 이를 통해 현실적인 사용자 행동을 시뮬레이션할 수 있습니다.
  Common timers include:
  - Constant Timer: Adds a fixed delay between requests.
  - Uniform Random Timer: Introduces random delays within a specified range.
  - Gaussian Random Timer: Adds delays following a Gaussian distribution.
Assertions:
- Assertions은 서버 응답이 특정 기준을 충족하는지 또는 예상되는 콘텐츠를 포함하는지 확인하는 데 사용됩니다. Assertions 실패하면 테스트에서 요청을 실패로 표시할 수 있습니다.
  Common assertions include:
  - Response Assertion: Checks the response text against patterns.
  - Duration Assertion: Verifies that the response time is within a specified range.
  - XML Assertion: Validates XML responses.
  - JSON Assertion: Validates JSON responses.
Configuration Elements:
- Configuration elements를 사용하여 변수, 데이터 소스를 설정하거나 다른 테스트 요소의 동작을 제어할 수 있습니다. 예로는 CSV 데이터 세트 구성 및 사용자 정의 변수가 있습니다.
Pre-Processors and Post-Processors:
- 이러한 요소를 사용하면 요청을 전송하기 전에 수정하거나 요청을 받은 후 응답을 처리할 수 있습니다. 예에는 정규식 추출기 및 JSON 경로 포스트프로세서가 포함됩니다.
Test Fragments:
- Test fragments는 여러 Test Plan에 포함될 수 있는 재사용 가능한 구성 요소입니다..

JMeter 테스트 계획을 생성하려면 일반적으로 스레드 그룹을 추가하고, 샘플러를 구성하고, 결과를 캡처하기 위한 리스너를 추가하고, 테스트 목표에 따라 설정을 조정하는 것부터 시작합니다. 그런 다음 필요에 따라 컨트롤러, 타이머 및 기타 요소를 추가하여 실제 사용자 동작 및 로드 시나리오를 시뮬레이션하여 테스트 계획을 세밀하게 조정할 수 있습니다. 마지막으로 테스트 계획을 실행하여 정의된 조건에서 애플리케이션의 성능을 측정합니다.

Apache JMeter(https://jmeter.apache.org)

환영전사 — Thu, 7 Sep 2023 14:31:14 +0900

Apache JMeter는 애플리케이션의 로드 테스트, 성능 테스트 및 기능 테스트를 위해 설계된 널리 사용되는 오픈 소스 소프트웨어 도구입니다. 원래 Apache Software Foundation에서 개발되었으며 Java로 작성되었습니다. JMeter는 확장성이 뛰어나며 다양한 유형의 애플리케이션과 서비스를 테스트하기 위한 광범위한 기능을 제공합니다. JMeter의 몇 가지 주요 측면은 다음과 같습니다.

성능 시험:

JMeter는 주로 여러 사용자 또는 가상 사용자를 시뮬레이션하여 다양한 로드에서 애플리케이션이나 서비스가 어떻게 작동하는지 평가하는 성능 테스트에 사용됩니다. 이는 애플리케이션의 병목 현상과 성능 문제를 식별하는 데 도움이 될 수 있습니다.

부하 테스트:

부하 테스트에는 애플리케이션에 지정된 부하(동시 사용자, 초당 요청 수 등)를 적용하여 해당 부하에서의 성능과 안정성을 평가하는 작업이 포함됩니다.

기능 테스트:

JMeter는 애플리케이션의 기능이 예상대로 작동하는지 확인하는 기능 테스트에도 사용할 수 있습니다.

프로토콜 지원:

JMeter는 HTTP, HTTPS, FTP, JDBC, LDAP, SOAP, JMS 등을 포함한 광범위한 프로토콜을 지원합니다. 따라서 웹 애플리케이션, 데이터베이스, 웹 서비스 및 기타 유형의 서비스를 테스트하는 데 적합합니다.

스크립팅 및 테스트 시나리오:

JMeter의 테스트 시나리오는 스레드 그룹, 샘플러(요청용), 로직 컨트롤러(흐름 제어용) 및 리스너(결과 보고용)와 같은 요소의 조합을 사용하여 생성됩니다.
테스트를 기록하거나, 수동으로 스크립팅하거나, 외부 소스에서 가져올 수 있습니다.

매개변수화:

JMeter를 사용하면 테스트를 매개변수화하여 변수와 CSV 파일을 사용하여 요청에 다양한 데이터를 제공할 수 있습니다.

Assertions:

응답의 정확성을 확인하기 위해 어설션을 추가할 수 있습니다. JMeter는 다양한 내장 주장을 제공하며 이를 통해 사용자 정의 주장을 생성할 수 있습니다.

보고 및 분석:

JMeter는 그래프, 테이블 및 요약 보고서를 포함하여 테스트 결과를 분석하기 위한 다양한 리스너 및 보고 도구를 제공합니다. 다양한 형식으로 보고서를 생성하고 내보낼 수도 있습니다.

분산 테스트:

JMeter는 분산 테스트를 지원하므로 보다 현실적인 테스트 시나리오를 위해 여러 컴퓨터에 로드를 분산할 수 있습니다.

플러그인 및 확장:

JMeter는 특정 사용 사례에 맞게 기능을 확장할 수 있는 풍부한 플러그인 및 확장 에코시스템을 갖추고 있습니다. 이 플러그인은 추가 프로토콜부터 고급 보고까지 모든 것을 다룹니다.

확장성:

JMeter는 복잡한 테스트 요구 사항을 충족하기 위해 스크립팅(예: Beanshell, JavaScript), 사용자 정의 샘플러 및 기타 메커니즘을 통해 확장될 수 있습니다.

오픈 소스 및 커뮤니티 지원:

JMeter는 오픈 소스입니다. 즉, 무료로 사용할 수 있으며 지원, 문서 및 추가 플러그인을 제공하는 사용자 및 기여자로 구성된 활발한 커뮤니티가 있습니다.

Cross-Platform:

JMeter는 Cross-Platform이며 Windows, macOS, Linux를 포함한 다양한 운영 체제에서 사용할 수 있습니다.
JMeter는 개발자, 테스터 및 품질 보증 전문가가 애플리케이션과 서비스의 성능, 안정성 및 기능을 보장하기 위해 사용하는 다목적 도구입니다. 사용자 친화적인 인터페이스와 강력한 기능으로 인해 광범위한 테스트 시나리오에서 널리 사용됩니다.

오사카에서 반드시 먹어야 하는 음식

환영전사 — Sun, 23 Jul 2023 19:27:40 +0900

일본 요리의 중심지인 오사카는 다양하고 맛있는 음식으로 미식가들을 즐겁게 하는 도시입니다. 길거리 음식부터 파인 다이닝까지 모든 미각을 만족시킬 무언가가 있습니다. 기억에 남을 미식 여행을 약속하는 오사카의 음식과 레스토랑을 소개합니다.

타코야키 - 아이즈야(あいづや): 아이즈야는 활기찬 도톤보리 지역에 위치한 사랑받는 타코야키 전문점입니다. 문어로 속을 채운 맛있는 볼에 타코야키 소스, 마요네즈, 가다랑어포 플레이크, 해초를 얹어 완벽하게 조리했습니다.

아이즈야 매장

타코야키

오코노미야키 - 미즈노(みづの): 도톤보리에 위치한 미즈노는 오코노미야키 전문점입니다. 그들의 맛있고 풍미있는 팬케이크는 다양한 충전재로 만들어지고 철판 그릴에서 요리됩니다. Mizuno는 여러 세대에 걸쳐 군침이 도는 오코노미야키를 제공하고 있습니다.

도톤보리 미즈노 매장

오코노미야키

쿠시카츠 다루마(串カツだるま): 도톤보리와 신세카이 근처에 위치한 쿠시카츠 다루마는 쿠시카츠 애호가라면 꼭 방문해야 할 곳입니다. 이 레스토랑은 고기, 해산물, 야채를 포함한 다양한 꼬치 튀김을 특별한 소스에 담근 것을 제공합니다.

쿠시카츠 다루마 도토보리점

꼬치 튀김

마츠자카큐 야키니쿠 M (松阪牛焼肉 M): 프리미엄 야키니쿠 경험을 원하시면 마츠자카큐 야키니쿠 M으로 가십시오. 최상급 마쓰사카 쇠고기를 전문으로 취급하므로 완벽하게 조리된 최고급 부위를 맛볼 수 있습니다.

마츠자카큐 야끼니쿠 M

야끼니쿠

잇푸도 난바(一風堂難波): 라면 애호가라면 번화한 난바 지역에 위치한 잇푸도 난바를 놓쳐서는 안 됩니다. Ippudo는 진하고 풍미가 풍부한 돈코츠(돼지 뼈) 국물로 유명하며 만족스러운 라면 한 그릇을 제공합니다.

잇푸도 난바점

잇푸도 라멘

Endo Sushi(えんどう寿司): 중앙 도매 시장(Kuromon Ichiba)에 위치한 Endo Sushi는 일본 요리 예술의 진정한 맛을 제공하는 신선하고 맛있는 스시로 유명합니다.

엔도 스시

엔도 스시 메뉴

오사카에서는 레스토랑뿐만 아니라 도톤보리 및 구로몬 이치바와 같은 번화한 길거리 음식 장면에서도 맛있는 음식을 찾을 수 있습니다. 이 활기찬 지역을 탐험하면 더 많은 숨겨진 보석과 지역 명소를 찾을 수 있습니다.

식도락가이든 단순히 맛있는 음식을 즐기는 사람이든 오사카의 음식 풍경은 오래도록 기억에 남을 것입니다. 그러니 풍미에 빠지고 맛을 음미하고 이 놀라운 도시의 미식의 경이로움에 빠져보세요.