Guide on philipjkim

Hugo 로 바둑판 도해 그리기 Part 2: 이미지 65장을 표기로 옮기기

Wed, 12 Aug 2026 13:21:01 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1 에서 바둑판 도해를 그리는 goban shortcode 를 만들었습니다. ASCII 로 쓰고 SVG 로 렌더링하는 방식입니다.

만들고 나니 다른 시리즈가 눈에 들어왔습니다. 9x9 바둑 교재 리뷰 4편에 PNG 이미지로 된 도해가 65장 있었습니다. 이걸 전부 표기로 옮기기로 했습니다.

Part 2 는 그 작업의 기록입니다. 결론부터 적으면 작업의 90%는 shortcode 와 무관한 일 이었고, 나머지 10% 에서 렌더링은 멀쩡한데 내용만 틀리는 종류의 버그를 하나 만났습니다.

Hugo 로 바둑판 도해 그리기 Part 1: 왜 shortcode 였나

Wed, 12 Aug 2026 13:18:52 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

이 블로그에 바둑 입문 시리즈를 쓰다가 벽에 부딪혔습니다. 바둑 글에는 바둑판 그림이 필요한데, 그릴 방법이 마땅치 않았습니다.

결국 goban 이라는 이름의 Hugo shortcode 를 직접 만들었습니다. 본문에는 이렇게 쓰고,

{{< goban caption="빈 삼각형" >}}
 a b c d e
 1 . X . . .
 2 X O * . .
 3 . . . . .
{{< /goban >}}

렌더링은 SVG 바둑판으로 나가는 방식입니다. 실제 결과는 이렇습니다.

바둑 가이드 Pt.2: 죽지 않는 법 — 잇기, 두 눈, 그리고 패

Tue, 11 Aug 2026 10:14:12 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Pt.1 에서는 규칙과 예절, 그리고 단수와 축을 다뤘습니다. 요약하면 상대 돌을 잡는 법 이었습니다.

이번 편은 정확히 그 반대편입니다. 질문은 하나뿐입니다.

내 돌은 어떻게 죽지 않는가?

입문자가 첫 판을 끝까지 두지 못하는 이유는 대개 이 질문에 답을 못 해서입니다. 잡는 법만 알면 공격은 할 수 있지만, 내가 쌓아 올린 돌이 왜 통째로 사라지는지는 알 수 없습니다.

그리고 답의 핵심은 규칙책의 아주 짧은 예외 조항 하나에 걸려 있습니다. 한국기원 바둑규칙 제4조입니다.

렉시오 CPU 플레이어 만들기 Part 7: 코드 없이 보는 easy 봇과 hard 봇의 차이

Mon, 10 Aug 2026 09:10:46 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 누구를 위한 것인가

Part 1 부터 Part 6 까지는 비트마스크, 동적 계획법, 평가 함수, 확률 모델 같은 이야기로 채워져 있습니다. 렉시오를 좋아하지만 개발자는 아닌 분에게는 읽을 이유가 없는 글입니다.

이번 편은 그 여섯 편의 결론만 을 코드와 수식 없이 옮긴 것입니다. 렉시오 규칙을 아는 분이라면 누구나 읽을 수 있습니다. 다루는 것은 셋입니다.

두 CPU 는 각각 무엇을 보고 수를 고르는가
둘을 어떻게 겨루게 했고, 결과가 어땠는가
그 결과로 무엇은 말할 수 있고, 무엇은 여전히 말할 수 없는가

세 번째가 이 글에서 가장 중요합니다. 숫자를 보여 주는 글은 많지만, 그 숫자가 무엇을 증명하지 못 하는지까지 적는 글은 드뭅니다.

달무티 vs 렉시오 Part 3: 인원, 운, 정치, 그리고 무엇을 살 것인가

Thu, 06 Aug 2026 14:37:49 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 두 게임의 목적과 구조를, Part 2에서 전략과 점수 체계를 봤습니다. 마지막 편에서는 실제로 테이블에 앉았을 때 부딪히는 것들을 다룹니다. 몇 명이 모였는가, 운이 어떻게 작동하는가, 사람 사이의 정치가 어디서 발생하는가, 그리고 결국 무엇을 살 것인가입니다.

1. 인원수에 따른 경험

달무티: 사람이 많을수록 살아난다

공식 룰북은 달무티를 4~8명 에서 지원하며, 특히 5~8명에서 가장 좋다 고 적습니다. 4명으로도 할 수 있고 9명 이상으로도 할 수 있다고 덧붙입니다.

달무티 vs 렉시오 Part 2: 강한 패, 혁명, 그리고 점수

Thu, 06 Aug 2026 14:34:56 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 달무티와 렉시오가 무엇을 재미로 삼는지, 구성물과 조합과 리드권이 어떻게 다른지 봤습니다. Part 2 에서는 실제로 판을 굴릴 때 부딪히는 문제들을 다룹니다. 강한 패를 언제 쓸 것인가, 광대는 어디에 붙일 것인가, 한 판의 결과가 다음 판에 어떻게 이어지는가, 그리고 점수는 어떻게 계산되는가입니다.

규칙 서술은 Part 1 과 마찬가지로 달무티 공식 룰북 과 렉시오 공식 홈페이지의 게임방법·기본전략 페이지 를 근거로 합니다.

달무티 vs 렉시오 Part 1: 같은 클라이밍 게임, 다른 목적

Thu, 06 Aug 2026 14:31:17 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

사촌인데 닮지 않았다

달무티(The Great Dalmuti)와 렉시오(Lexio)는 모두 클라이밍 게임 입니다. 앞사람이 낸 것과 같은 장수의 더 강한 조합으로 받아 올라가고, 손에 든 카드나 타일을 먼저 비우는 쪽이 이깁니다. 클라이밍 게임 전반을 정리한 글에서 다뤘듯 둘은 같은 뿌리에서 갈라진 사촌입니다.

두 게임은 다음 원리를 공유합니다.

약한 조합은 리드권이 있을 때 처리합니다.
강한 조합은 리드권을 되찾는 데 사용합니다.
같은 숫자가 여러 장 모인 패가 유리합니다.
상대의 남은 카드 수를 관찰해야 합니다.
낼 수 있다고 해서 무조건 내는 것이 정답은 아닙니다.
패스는 그 트릭에서의 탈락이 아닙니다. 두 게임 모두 패스한 뒤에도 자기 차례가 다시 오면 낼 수 있습니다. 달무티 공식 룰북은 이를 명시적으로 규정하고 있습니다.

겉으로 보면 렉시오가 달무티에 포커 족보를 얹은 복잡한 버전처럼 보이기도 합니다. 그러나 실제로 플레이해 보면 두 게임이 만들어 내는 경험은 상당히 다릅니다.

에어컨이 있는 집에 제습기가 꼭 필요할까: 서울 13개월 온습도 데이터로 따져보기

Tue, 28 Jul 2026 10:08:00 +0900

이 글은 Claude Opus 5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

장마철마다 반복되는 논쟁이 있습니다. 한쪽에서는 “에어컨 틀면 습도 다 잡히는데 제습기를 왜 사냐"고 하고, 다른 쪽에서는 “제습기 없이 여름을 나는 건 곰팡이를 키우겠다는 얘기"라고 합니다.

두 주장 모두 부분적으로 맞고, 부분적으로 틀립니다. 문제는 이 논쟁이 대부분 체감과 경험담으로만 오간다는 점입니다. 그래서 2025년 7월 1일부터 2026년 7월 27일까지, 서울의 시간별 기온·습도 데이터 9,408시간분 을 직접 받아 다음을 숫자로 따져봤습니다.

대부호부터 렉시오까지: 클라이밍 카드게임의 세계와 전략

Mon, 27 Jul 2026 09:38:43 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

손패를 먼저 비우는 자가 이긴다

카드게임에는 여러 갈래가 있습니다. 포커처럼 좋은 조합을 만들어 겨루는 게임, 브리지나 스페이드처럼 정해진 수의 트릭을 따내는 게임, 그리고 손에 든 카드를 가장 먼저 다 털어내는 것이 목표인 게임이 있습니다. 마지막 유형을 보드게임 용어로 셰딩 게임(shedding game) 이라 부르고, 그중에서도 “이전 사람이 낸 것보다 더 센 조합을 내야만 한다"는 규칙을 가진 하위 갈래를 클라이밍 게임(climbing game) 이라고 부릅니다. 국내에서는 가장 널리 알려진 게임의 이름을 따 대부호류(大富豪類) 라고 뭉뚱그려 부르는 경우가 많은데, 엄밀히 말하면 대부호는 클라이밍 게임의 여러 갈래 중 하나입니다.

Marp: Markdown으로 발표 슬라이드를 만들고 Git으로 관리하기

Thu, 23 Jul 2026 13:03:11 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

발표 자료를 만들 때마다 PowerPoint나 Keynote를 열면서 “코드는 Git으로 관리하는데 슬라이드는 왜 바이너리 파일로 주고받아야 하지?“라는 생각을 해본 개발자라면, 이 글이 도움이 될 것입니다. 이미 README와 기술 문서를 Markdown으로 쓰고 있다면, 슬라이드도 같은 방식으로 만들 수 있습니다. 이 글에서는 Marp (Markdown Presentation Ecosystem)을 소개합니다.

Marp란 무엇인가

Marp은 Markdown 파일을 발표 슬라이드로 변환해주는 오픈소스 도구 모음입니다. 핵심 아이디어는 단순합니다:

HTTP REST(JSON) vs. gRPC(Protocol Buffers): 언제 무엇을 쓸까

Thu, 16 Jul 2026 17:33:09 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

백엔드 서버를 설계할 때 거의 항상 마주치는 갈림길이 있습니다. “이 API 를 JSON 기반 HTTP REST 로 열까, 아니면 gRPC 로 열까?” 하는 질문입니다. 팀 컨벤션에 따라 별생각 없이 한쪽으로 정해지는 경우도 많지만, 두 방식은 성능·개발 경험·운영 부담·클라이언트 호환성 등 여러 축에서 뚜렷하게 다른 트레이드오프를 가집니다.

이 글은 웹 백엔드를 다루는 중급 이상 개발자를 대상으로, 두 방식의 작동 원리와 장단점을 정리하고 “어떤 상황에서 무엇을 고르는 것이 합리적인지” 를 구체적인 예시와 함께 설명합니다. 결론부터 말하면 “무조건 하나가 낫다"는 답은 없으며, 통신의 상대가 누구인지(외부 클라이언트 vs. 내부 서비스) 가 선택의 가장 강력한 기준이 됩니다.

넨도로이드 완전 가이드 Part 3: 입문자를 위한 실전 가이드

Tue, 14 Jul 2026 14:33:30 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 넨도로이드의 탄생을, Part 2에서 인기의 분기점과 커뮤니티 문화를 살펴봤습니다. 마지막 이번 글은 “그래서 나도 하나 사보고 싶다” 는 분을 위한 실전 가이드입니다. 구조와 특징부터 가격, 구매, 보관, 짝퉁 주의까지 순서대로 정리하겠습니다.

넨도로이드의 구조와 특징

넨도로이드는 기본적으로 머리·어깨·팔·다리·허리·손목 에 규격화된 관절이 있는 조립형 피규어입니다. 기본 크기는 약 10cm, 소재는 ABS·PVC 플라스틱입니다.

핵심 특징은 교체와 조합 입니다.

표정 교체: 기본 표정 외에 2~3종의 얼굴 파츠가 기본 구성으로 들어와, 상황에 맞는 표정을 골라 끼울 수 있습니다. 굿스마일 전체 라인업의 표정 파츠는 5,000종이 넘는다고 합니다.
포즈 연출: 팔·다리 파츠를 바꾸거나(굽힌 다리 등), 소품·이펙트 파츠를 조합해 다양한 장면을 연출할 수 있습니다.
호환성: 부품 치수가 표준화되어 있어 다른 넨도로이드와 파츠를 바꿔 끼울 수 있습니다. Part 2에서 다룬 “규격화"의 실질적 혜택이지요.

가동 방식에는 두 갈래가 있습니다.

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

Wed, 24 Jun 2026 10:15:25 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서 언어와 문법을, Part 2에서 표준 라이브러리를 다뤘습니다. 시리즈의 마지막인 Part 3은 동시성·런타임·툴체인·운영 입니다. 코드 한 줄의 변화라기보다, “서비스를 어떻게 돌리고 어떻게 검증하느냐"에 가까운 영역입니다.

이 영역의 변화는 특히 컨테이너/쿠버네티스 환경에서 Go 서비스를 운영하는 팀에게 의미가 큽니다. 2021년에는 서드파티 라이브러리나 수작업으로 메우던 빈틈을, 이제 표준 런타임이 채워 줍니다.

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

context 는 1.7부터 있었지만, 실무에서 반복되던 몇 가지 패턴을 표준으로 흡수한 것은 1.21입니다.

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

Wed, 24 Jun 2026 10:13:33 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 제네릭, 이터레이터, 빌트인 등 언어와 문법 레벨의 변화를 다뤘습니다. Part 2는 일상 코드에서 가장 손이 자주 가는 표준 라이브러리 의 레시피입니다.

2021~22년의 Go 표준 라이브러리는 의외로 빈약했습니다. 슬라이스에서 원소를 찾으려면 for 루프를 직접 돌렸고, 맵의 키를 모으려면 손으로 슬라이스를 채웠으며, 정렬은 sort.Slice 에 비교 함수를 넘겼습니다. 구조적 로깅을 하려면 logrus, zap 같은 서드파티가 사실상 필수였고, HTTP 라우팅에서 메서드와 경로 파라미터를 다루려면 gorilla/mux 를 깔았습니다.

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

Wed, 24 Jun 2026 10:11:05 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 5년 동안 Go에 무슨 일이 있었나

2021~22년에 Go로 서비스를 짜던 시절을 떠올려 봅니다. 그때 우리가 쓰던 버전은 대략 Go 1.16~1.18 언저리였습니다. 제네릭이 없거나(1.18 이전), 갓 도입되어 아직 손에 익지 않았고, interface{} 와 sort.Slice, for _, v := range xs { v := v; ... } 같은 관용구가 일상이었습니다.

그로부터 8개의 메이저 릴리스(1.19부터 1.26까지)가 지났습니다. 2026년 6월 현재 stable 버전은 2026년 2월에 나온 Go 1.26 입니다. 이 5년 사이에 언어 자체, 표준 라이브러리, 런타임, 툴체인이 모두 크게 달라졌습니다. 문제는 코드베이스가 그만큼 따라가지 못한다는 점입니다. 많은 프로덕션 코드가 여전히 “그때 그렇게 짜던 방식"으로 멈춰 있습니다.

게임 디자인과 랜덤성의 수학 Part 3: 게임이론과 시뮬레이션으로 밸런스를 검증하기

Tue, 23 Jun 2026 14:01:04 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편에서 랜덤성의 역할과 실패 사례를, 2편에서 확률 분포의 수학을 다뤘습니다. 완결편인 3편에서는 무대를 옮깁니다. 지금까지의 무작위성이 “주사위” 였다면, 이번엔 상대가 있는 무작위성 — 즉 게임이론(game theory) 입니다. 그리고 그렇게 설계한 밸런스가 실제로 작동하는지 검증하는, 현대 스튜디오의 시뮬레이션 기반 검증 테크트리 를 정리합니다.

핵심 질문 두 개를 미리 던져 두겠습니다. “왜 최적의 가위바위보 플레이는 무작위화를 강제 하는가?” 그리고 “수백만 판을 사람이 할 수 없다면, 밸런스는 어떻게 검증하는가?”

게임 디자인과 랜덤성의 수학 Part 2: 확률 분포로 드랍률·가챠·천장 설계하기

Tue, 23 Jun 2026 13:57:54 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편에서는 거시적인 관점에서 게임 속 랜덤성의 역할과 실패 사례, 그리고 통제된 무작위성의 도구 상자를 개념 수준으로 훑었습니다. 2편에서는 그 도구들의 수학적 속살 을 직접 펼쳐 봅니다. 확률 분포가 게임의 드랍률·가챠·천장 시스템을 어떻게 결정하는지, 실제 수식과 계산 예제로 분해하겠습니다.

이 글을 관통하는 단 하나의 관점을 미리 못 박아 두겠습니다. 좋은 무작위 설계란 결국 “기댓값 E[X]는 고정한 채, 분산 Var(X)을 조작하는 일” 입니다. 평균 보상은 그대로 두고 변동성만 깎는 것 — 이 한 문장이 PRD·천장·셔플백·2RN 을 모두 꿰뚫습니다.

게임 디자인과 랜덤성의 수학 Part 1: 랜덤성은 왜 게임의 심장이자 지뢰밭인가

Tue, 23 Jun 2026 13:26:50 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

주사위를 굴리고, 카드를 섞고, 전리품 상자를 여는 순간. 우리가 게임에서 가장 짜릿하거나 가장 분통 터지는 경험을 하는 거의 모든 장면에는 랜덤성(randomness) 이 숨어 있습니다. 그런데 이 랜덤성은 단순히 “난수 생성기를 호출하는 코드 한 줄"이 아닙니다. 잘못 다루면 수백만 명이 등을 돌리고, 잘 다루면 같은 게임을 수천 시간 반복하게 만드는, 게임 디자인에서 가장 미묘하고 위험한 영역입니다.

이 글은 게임 디자인과 랜덤성의 수학 3부작의 1편입니다. 이번 편에서는 거시적인 관점에서 다음을 다룹니다.

한여름 제철 스시 재료: 오마카세에서 만나는 고급 어종 6선

Wed, 17 Jun 2026 09:57:08 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

지난 글 봄부터 초여름 제철 스시 재료 에서 봄~초여름(3~7월) 어종을 다루었다면, 이번에는 본격적인 무더위가 찾아오는 한여름(6월 중순~9월 초) 으로 넘어가 보겠습니다. 수온이 가장 높이 오르는 이 시기는 흰살생선에게는 산란을 마치고 살을 회복하며 기름을 올리는 계절이고, 장어류에게는 일 년 중 가장 빛나는 전성기입니다.

여름 오마카세는 무겁고 기름진 겨울의 미식과는 결이 다릅니다. 더위에 지친 입맛을 살리는 청량함, 단단한 식감, 그리고 불향과 데침(湯引き)으로 끌어올린 향 이 주인공이 됩니다. 한국의 하이엔드 스시야에서 이 계절에 실제로 만날 수 있는 여름 제철 어종 여섯 가지를 정리해 보았습니다.

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 3: 무엇이, 어떻게 다른가

Tue, 09 Jun 2026 09:48:52 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 코믹스(만화) 원작 5선을, Part 2에서는 라이트노벨 원작 5선을 살펴봤습니다. 양쪽 진영의 대표 선수들을 모두 만나봤으니, 이제 본격적으로 둘을 나란히 놓고 비교할 차례입니다.

이 글에서는 만화 원작과 라노벨 원작 애니메이션이 제작 방식, 장르, 페이싱, 작화, 흥행 측면에서 어떻게 다른지를 하나씩 뜯어보겠습니다. 단순히 “뭐가 더 낫다"는 우열 가리기가 아니라, 출발점이 다른 두 매체가 애니메이션이라는 결승선에 어떻게 도달하는지를 보는 작업입니다.

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 2: 라이트노벨이 열어젖힌 이세계

Tue, 09 Jun 2026 09:47:11 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 만화가 낳은 괴물들 — 코믹스 원작 애니메이션 5선을 살펴봤습니다. 진격의 거인부터 스파이 패밀리까지, 비주얼이 강하고 장르가 다양한 작품들이었습니다.

이번 Part 2에서는 진영을 바꿉니다. 이번 주인공은 라이트노벨(라노벨) 입니다. 만화가 그림에서 출발한다면 라노벨은 글에서 출발하고, 이 출발점의 차이가 전혀 다른 풍경을 만들어냅니다. 한 가지 미리 말씀드리면, 이번 5선에는 유독 “이세계"라는 단어가 자주 등장할 겁니다. 왜 그런지는 작품들을 보면 자연스럽게 이해되실 겁니다.

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 1: 만화가 낳은 괴물들

Tue, 09 Jun 2026 09:45:20 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 원작이 만화냐 라노벨이냐, 그게 뭐가 중요한가요?

애니메이션을 한두 시즌쯤 보다 보면 이상한 패턴이 눈에 들어오기 시작합니다. 어떤 애니는 1화부터 작화가 미쳐 돌아가고 액션이 시원시원한데, 어떤 애니는 캐릭터들이 방 안에 둘러앉아 끝없이 수다를 떨고 주인공의 머릿속 독백이 한참 이어집니다. 둘 다 재미있을 수 있지만, 분명히 결이 다릅니다.

이 차이를 만드는 가장 큰 변수 중 하나가 바로 “원작이 무엇이냐” 입니다. 대부분의 인기 TV 애니메이션은 오리지널 기획이 아니라 원작이 따로 있고, 그 원작은 십중팔구 둘 중 하나입니다. 만화(코믹스) 거나 라이트노벨 이거나.

개발자를 위한 Discord 완전정복 Part 3: Discord를 원격 Control Plane으로

Fri, 05 Jun 2026 18:09:28 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 Discord의 역사를, Part 2에서 개발자에게 풀린 무료 기능들을 살펴봤습니다. 마지막 Part 3에서는 이 기능들을 조합해 Discord를 원격 control plane(제어 평면) 으로 쓰는 실전 활용법을 다룹니다.

핵심 아이디어는 단순합니다. Discord 봇은 어디서나 접근 가능한 양방향 메시지 채널입니다. 폰에서도, PC에서도 같은 채널에 메시지를 보낼 수 있습니다. 그렇다면 그 메시지를 받아 내 서버에서 명령을 실행하거나, 장기 실행 작업을 조종하거나, AI 에이전트를 지휘할 수 있지 않을까요? 바로 이 발상이 최근 개발자 사이에서 뜨거운 “Discord를 control plane으로” 패턴입니다.

개발자를 위한 Discord 완전정복 Part 2: 공짜로 풀어준 대인배 기능들

Fri, 05 Jun 2026 18:07:55 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 Discord가 어떻게 태어나 성장했고 어떤 결정으로 지금의 모습이 되었는지를 살펴봤습니다. 이번 Part 2에서는 개발자 입장에서 Discord가 얼마나 대인배인지 를 이야기합니다.

결론부터 말하면, API·봇·Webhook·Gateway·Interactions·OAuth2·임베드·CDN 첨부·음성 채널·스레드·포럼 채널이 전부 무료입니다. 서버 크기 제한도 없습니다. 흔히 보이는 유료 구독 Nitro는 개인 사용자(엔드유저) 대상이지 개발자 기능이 아닙니다. 봇을 만들고 운영하는 데 Discord에 내는 비용은 0원이며, 드는 비용이 있다면 봇을 돌릴 본인 호스팅 비용뿐입니다.

개발자를 위한 Discord 완전정복 Part 1: 탄생, 성장, 그리고 결정적 순간들

Fri, 05 Jun 2026 18:05:49 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

개발자라면 한 번쯤은 Discord 서버에 들어가 본 적이 있을 것입니다. 오픈소스 프로젝트의 커뮤니티, 사내 봇 알림 채널, 혹은 그냥 친구들과 게임하며 떠드는 음성 채널까지. 어느새 Discord는 개발자 생태계의 기본 인프라 중 하나가 되었습니다.

이 시리즈는 Discord라는 서비스를 개발자의 시선으로 뜯어봅니다. 3부작으로 구성했습니다.

Part 1 (이 글): Discord가 어떤 니즈에서 태어났고, 어떻게 성장했으며, 서비스를 지금의 모습으로 만든 결정적 의사결정들을 살펴봅니다. 마지막엔 개발자가 특히 주목할 만한 엔지니어링 의사결정(Elixir, Go→Rust, Cassandra→ScyllaDB)을 다룹니다.
Part 2: Webhook, 봇, 슬래시 커맨드 같은 Discord의 개발자 친화적이고 대인배스러운 무료 기능들을 실전 관점에서 정리합니다.
Part 3: Discord를 원격 control plane으로 활용하는 방법 — AI 코딩 에이전트 원격 제어, ChatOps, 홈랩 모니터링 등 — 과 그 best practice를 다룹니다.

그럼 1편을 시작합니다.

훌라(Hula) 완전정복 Part 2: 전투훌라 실전 전략

Thu, 04 Jun 2026 16:35:50 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“기술을 익히기 전에, 손은 눈보다 빨라야 돼.”

Part 1에서 훌라의 유래와 규칙, 그리고 전투훌라의 핵심을 익히셨습니다. 이제 규칙은 알았으니 문제는 “어떻게 이기느냐” 입니다. 카드를 받아 들고 멍하니 있다가 남의 땡큐에 차례를 다 빼앗기는 호구가 될 것인가, 아니면 버려진 카드를 세어 가며 판을 읽는 타짜가 될 것인가. 이 글이 그 갈림길의 이정표가 되어 드리겠습니다.

다시 한번 단서를 답니다. 아래 전략은 확립된 룰에 기반한 정석과 커뮤니티에서 통용되는 휴리스틱(경험칙) 이 섞여 있습니다. 수치로 된 팁(“첫 턴 스톱은 35점 이하” 같은)은 절대 공식이 아니라 “대체로 그렇다더라” 수준의 경험칙이니, 참고만 하시고 본인 감각으로 보정하시길 바랍니다.

훌라(Hula) 완전정복 Part 1: 유래부터 규칙, 전투훌라까지

Thu, 04 Jun 2026 16:33:16 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“이 패가 단풍이야, 단풍.”

영화 〈타짜〉의 명대사를 빌려왔지만, 오늘 다룰 게임은 화투가 아닙니다. 트럼프 카드 한 벌이면 충분한, 그런데도 의외로 정식 룰을 아는 사람이 드문 게임. 바로 훌라(Hula) 입니다.

명절에 친척들이 모이면 한쪽에서 “훌라 한 판?” 소리가 나오는데, 막상 끼려고 하면 “넌 룰 모르니까 옆에서 보고 있어” 라는 말을 듣기 십상입니다. 이 글은 바로 그런 분들을 위한 것입니다. 훌라를 한 번도 해본 적 없는 분도 이 글 두 편만 읽으면 다음 명절엔 당당히 패를 받을 수 있도록, Part 1에서는 유래와 규칙을, Part 2에서는 전투훌라 전략을 다루겠습니다.

MLB 매니아를 위한 KBO 입문 가이드 Part 3: 통산 기록과 KBO만의 "대첩" 밈

Mon, 01 Jun 2026 13:02:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 리그 구조와 룰을, Part 2에서는 2024~2025 두 시즌의 흐름을 살펴봤습니다. 마지막 Part 3에서는 KBO 입문자가 가장 헷갈리는(그리고 가장 재미있어하는) 두 가지를 다룹니다.

통산 기록 비교: KBO와 MLB의 숫자를 나란히 놓고 비교
“대첩"이라는 자학 어법: KBO 팬덤의 가장 독특한 밈 문화

통산 기록 비교: 숫자의 스케일

MLB와 KBO는 리그 역사(MLB 1903년 / KBO 1982년)와 경기 수가 다르기 때문에 단순 비교에는 한계가 있습니다. 다만 각 부문 1위의 숫자가 갖는 의미와 그 기록을 만든 선수의 이야기는 두 리그를 이해하는 좋은 지표입니다.

MLB 매니아를 위한 KBO 입문 가이드 Part 2: 2024~2025 시즌으로 보는 두 리그의 흐름

Mon, 01 Jun 2026 13:01:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 KBO와 MLB의 구조적 차이와 룰, 응원 문화를 살펴봤습니다. Part 2에서는 2024~2025 두 시즌의 흐름을 통해 두 리그의 현재 모습을 비교해보겠습니다. 결론부터 말씀드리면 같은 야구지만 흐름은 꽤 다릅니다.

2024 시즌: 두 리그 모두 우승팀이 압도적이었다

MLB 2024: 다저스 vs 양키스, 21세기 첫 클래식 매치업

MLB 2024년의 하이라이트는 단연 월드시리즈였습니다. LA 다저스가 양키스를 4승 1패로 꺾고 통산 8번째 우승을 차지했는데, 다저스와 양키스가 월드시리즈에서 만난 것은 1981년 이후 43년 만이었습니다(Wikipedia: 2024 World Series). 시리즈 MVP는 다저스의 프레디 프리먼이 수상했고, 그는 1~4차전 첫 타석에서 모두 홈런을 친 월드시리즈 최초의 4경기 연속 홈런 기록을 세웠습니다.

MLB 매니아를 위한 KBO 입문 가이드 Part 1: 리그 구조와 룰, 문화의 차이

Mon, 01 Jun 2026 13:00:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 왜 지금 KBO인가

MLB를 오래 본 팬에게 KBO는 종종 “수준 낮은 더블 A 야구"로 치부되어 왔습니다. 솔직히 말씀드리면 평균적인 경기 수준은 여전히 MLB와 격차가 있습니다. 그러나 2024년 KBO 리그가 사상 최초로 단일 시즌 1,000만 관중을 돌파(KBO 보도자료, 2024-09-15) 한 데서 알 수 있듯, 한국 프로야구는 단순히 경기력만으로 설명할 수 없는 고유의 매력을 갖춘 콘텐츠가 되었습니다.

이 시리즈는 MLB는 익숙하지만 KBO는 잘 모르는 야구 팬을 위해 세 편으로 나누어 다음을 정리합니다.

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

Thu, 28 May 2026 19:03:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1 에서는 2026년 5월 기준 de-facto 가 된 spec 문서들의 지형도와 best practices 를 정리했습니다. 2편에서는 가상의 Go + Templ + HTMX 기반 To-Do 앱 gotodo 를 새로 부트스트래핑한다고 가정하고, 각 문서를 실제로 어떻게 채우는지 발췌 형태로 따라갑니다.

가상 프로젝트: `gotodo`

스택은 다음과 같습니다.

Go 1.23 — 표준 라이브러리 중심
templ — Go 네이티브 SSR 템플릿 (type-safe)
HTMX 2.0 — 클라이언트 JS 최소화
SQLite + modernc.org/sqlite — CGO 없는 순수 Go 드라이버

목표는 단순합니다. 할 일 추가/완료/삭제만 되는 SSR 미니멀 앱. 1인 로컬 사용을 가정합니다.

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 1: AGENTS.md 와 spec 문서 지형도

Thu, 28 May 2026 19:02:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: README 한 장으로 안 되는 시대

신규 서비스를 위한 git repo 를 막 만들었다고 합시다. 2년 전이라면 README.md 한 장에 빌드 명령과 디렉터리 구조를 적고, 나머지는 코드와 머릿속에서 합의된 관행으로 굴러갔습니다. 새 팀원이 들어오면 옆 자리 동료가 30분쯤 설명해 주고, 그걸로 충분했습니다.

지금은 그 “옆 자리 동료” 역할의 절반 이상을 Claude Code, Codex CLI, Gemini CLI, Cursor 같은 에이전트가 맡고 있습니다. 그런데 에이전트는 옆 자리에 앉지 않습니다. 매 세션마다 처음 합류한 신입처럼 repo 에 들어와서, 우리가 적어 둔 텍스트만 읽고 일을 시작합니다. 에이전트에게 “이 프로젝트는 이런 곳이고, 이런 규칙으로 일한다” 를 전달하는 문서가 부실하면, 에이전트가 만드는 결과물의 품질은 운에 좌우됩니다.

Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계

Wed, 20 May 2026 16:58:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서 개요와 설치를, 2편 에서 핵심 워크플로우를, 3편 에서 품질 보증 스킬을 다뤘습니다. 마지막 4편에서는 실전에서 가장 자주 부딪히는 질문에 답합니다.

“이거 그냥 두면 알아서 다 해주는 건가요, 아니면 매번 /superpowers:xxx 로 호출해야 하나요?”

답은 “대부분 자동이지만, 의도적으로 명시 호출해야 더 잘 작동하는 케이스가 있다” 입니다. 이 글에서는 두 모드의 비교 분석, 트러블슈팅, 커스터마이즈 방법, 그리고 Java/Go 백엔드 개발 현장에서의 실용 팁과 한계를 정리합니다.

Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬 — TDD, Systematic Debugging, Verification, Code Review

Wed, 20 May 2026 16:57:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서 Superpowers 의 개요와 설치를, 2편 에서 핵심 워크플로우를 다뤘습니다. 3편은 그 워크플로우 안에서 작동하면서 에이전트의 합리화와 빠져나갈 구멍을 차단 하는 품질 보증 스킬들을 자세히 들여다봅니다.

이 스킬들은 모두 “Iron Law” 라는 이름의 명문화된 규칙을 갖고 있다는 공통점이 있습니다. 그리고 각 스킬의 문서 안에는 “Red Flags” 표 가 들어 있어, 에이전트가 빠져나가려 할 때 흔히 하는 합리화의 패턴들을 그대로 박아두었습니다. 이게 결과적으로 모델의 행동을 바꿉니다.

Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우 — Brainstorming부터 Subagent-driven Development까지

Wed, 20 May 2026 16:56:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서는 Superpowers 가 무엇이고 어떻게 자동 트리거되는지를 다뤘습니다. 2편은 가장 핵심이라고 할 수 있는 개발 워크플로우 전체 를 깊게 들여다봅니다.

전체 흐름은 다음과 같습니다.

flowchart LR
 A[brainstorming] --> B[using-git-worktrees]
 B --> C[writing-plans]
 C --> D{독립 태스크?}
 D -->|yes| E[subagent-driven-development]
 D -->|no/사람 체크포인트 선호| F[executing-plans]
 E --> G[finishing-a-development-branch]
 F --> G

 style A fill:#90EE90,color:#000000
 style B fill:#87CEEB,color:#000000
 style C fill:#FFD700,color:#000000
 style D fill:#FFB6C1,color:#000000
 style E fill:#DDA0DD,color:#000000
 style F fill:#DDA0DD,color:#000000
 style G fill:#FFA07A,color:#000000

이 글에서는 각 스킬이 실제로 무엇을 하는지, 그리고 Go 기반 백엔드 서비스에 새 API 엔드포인트를 추가 하는 시나리오를 따라가며 흐름을 체험해 봅니다.

Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학

Wed, 20 May 2026 16:55:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Claude Code, Codex CLI, Cursor 등 코딩 에이전트(coding agent)를 매일 쓰는 백엔드 개발자라면 한 번쯤은 이런 경험이 있을 겁니다. “간단한 기능 하나만 추가해줘” 라고 했더니, 요구사항 정리 없이 코드를 우다다 쏟아내다가 절반쯤에서 길을 잃고, 테스트도 빠진 채 “완료했습니다” 라고 보고하는 경우 말입니다. 모델은 똑똑한데, 작업 방식이 들쭉날쭉해서 결과의 품질이 운에 좌우됩니다.

Jesse Vincent 가 만든 Superpowers 는 바로 이 지점을 노린 플러그인입니다. 모델을 더 똑똑하게 만드는 게 아니라, 모델이 언제, 어떤 순서로, 어떤 규율로 일해야 하는지를 강제하는 “방법론(methodology)” 자체를 플러그인 형태로 주입합니다.

봄부터 초여름 제철 스시 재료: 오마카세에서 만나는 고급 어종 7선

Mon, 13 Apr 2026 14:22:18 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

봄부터 초여름(3~7월) 사이는 바닷물이 서서히 따뜻해지며 다양한 어종들이 산란기를 앞두고 살을 찌우거나, 반대로 산란을 마치고 새로운 먹이 활동을 시작하는 역동적인 시기입니다. 한국의 남해·제주 앞바다와 일본 연안에서 잡히는 생선 중, 하이엔드 스시 오마카세에서 이타마에(板前)가 자신의 기량을 드러내기 위해 즐겨 사용하는 고급 어종 7가지를 정리해 보았습니다.

이전 글에서 다루었던 ‘나마자케(生酒)‘와 ‘일반 사케’의 특성 을 염두에 두고 페어링을 살펴보시면 더욱 흥미로우실 겁니다.

크로스플랫폼 To-Do 앱 만들기 Part 4: UI 다듬기와 빌드/배포

Wed, 01 Apr 2026 09:12:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 목차

Part 1: Flutter 소개와 개발 환경 설정
Part 2: 기본 UI 구성과 상태 관리
Part 3: 로컬 저장소 연동과 CRUD 완성
Part 4: UI 다듬기와 빌드/배포 (이번 글)

Part 3 회고

Part 3까지 진행하면서 할 일의 추가, 수정, 삭제, 완료 토글 기능과 로컬 저장소 연동까지 모두 구현했습니다. 기능적으로는 완성된 상태이지만, 실제로 사용자에게 배포하려면 몇 가지 더 다듬어야 할 부분이 있습니다.

크로스플랫폼 To-Do 앱 만들기 Part 3: 상태 관리와 로컬 데이터 저장

Wed, 01 Apr 2026 09:11:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 2에서는 Flutter 위젯을 활용해 To-Do 앱의 UI를 구성했습니다. 할 일을 추가하고, 완료 처리하고, 삭제하는 기본 기능까지 구현했는데요. 한 가지 치명적인 문제가 있었습니다. 앱을 종료했다가 다시 실행하면 모든 데이터가 사라진다 는 점입니다.

setState로 관리하던 List<Todo> 는 메모리에만 존재하기 때문입니다. 이번 Part 3에서는 Riverpod 을 사용한 상태 관리 리팩토링과 sqflite 를 이용한 로컬 데이터 영구 저장을 구현합니다.

1. setState의 한계

Part 2에서 사용한 setState는 간단한 프로토타입에는 충분하지만, 앱 규모가 커지면 여러 문제가 생깁니다.

크로스플랫폼 To-Do 앱 만들기 Part 2: Flutter 기초와 UI 구현

Wed, 01 Apr 2026 09:10:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서 Flutter SDK 설치, 에디터 설정, 에뮬레이터 구성 등 개발 환경을 갖추었습니다. 이제 본격적으로 코드를 작성할 차례입니다.

이번 Part 2에서는 Dart 언어의 핵심 문법을 빠르게 훑어본 뒤, Flutter의 위젯 시스템을 이해하고, 실제로 동작하는 To-Do 리스트 앱의 UI를 구현합니다. 이 글을 따라 하면 할 일을 추가하고, 완료 표시하고, 삭제하는 기본 기능이 모두 갖춰진 앱을 만들 수 있습니다.

크로스플랫폼 To-Do 앱 만들기 Part 1: 프레임워크 선택과 개발 환경 설정

Wed, 01 Apr 2026 09:09:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 소개

이 시리즈에서는 Flutter 를 사용하여 크로스플랫폼 To-Do 앱을 처음부터 끝까지 만들어 봅니다. 하나의 코드베이스로 Android, iOS, 그리고 웹까지 동작하는 앱을 완성하는 것이 목표입니다.

시리즈는 총 4개의 파트로 구성됩니다.

Part 1 (이번 글) : 프레임워크 선택과 개발 환경 설정
Part 2: UI 구성과 기본 기능 구현
Part 3: 상태 관리와 로컬 데이터 저장
Part 4: 마무리, 테스트, 빌드 및 배포

각 파트는 실습 중심으로 진행됩니다. 따라해 보시면서 자연스럽게 Flutter 개발의 흐름을 익히실 수 있습니다.

Push Your Luck 게임 디자인 가이드 Part 2: 수학적 최적화와 게임 이론

Mon, 30 Mar 2026 13:38:35 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 Push Your Luck 메카닉의 구조와 실제 사례를 살펴보았습니다. 이번 Part 2에서는 수학적 프레임워크를 기반으로 최적의 파라미터를 도출하고, 게임 이론을 적용하는 방안을 다룹니다.

수학적 프레임워크: 최적 중단 문제

기본 모델 정의

변수를 정의합니다.

p: 매일 도전 과제의 성공 확률 (0 < p < 1)
n: 현재 콤보 수 (연속 성공 횟수)
R(n): 콤보 n에서 Stop했을 때 받는 리워드
V(n): 콤보 n에서 최적 전략 을 따랐을 때의 기대값

플레이어가 콤보 n에서 내리는 결정은 다음과 같습니다.

Push Your Luck 게임 디자인 가이드 Part 1: 메카닉 분석과 실제 사례

Mon, 30 Mar 2026 13:37:35 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

다음과 같은 게임을 상상해 봅시다.

매일 하나의 도전 과제가 주어집니다. 성공률은 평균 N%입니다. 연속으로 성공할 때마다 콤보가 쌓이고, 콤보가 높을수록 받을 수 있는 리워드가 커집니다. 플레이어는 매일 두 가지 선택지 앞에 놓입니다.

Go: 내일 도전을 이어가서 더 큰 리워드를 노린다

Stop: 현재 콤보로 리워드를 수령하고, 내일부터 0콤보로 다시 시작한다

단, 도전에 실패하면 콤보는 0으로 리셋되고 아무 리워드도 받지 못합니다.

Fantasy Baseball(MLB) 완전 가이드: 리그 형식부터 선수 운영 노하우까지

Thu, 26 Mar 2026 14:37:51 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Fantasy Baseball이란?

Fantasy Baseball은 실제 MLB 선수들의 경기 성적을 기반으로 가상의 팀을 구성하고 다른 참가자들과 경쟁하는 게임입니다. 참가자(매니저)는 드래프트를 통해 선수를 선발하고, 시즌 동안 선수를 교체·트레이드하며 최고의 성적을 목표로 팀을 운영합니다.

MLB의 긴 시즌(162경기)은 Fantasy Sports에 매우 적합합니다. 매일 경기가 있어 꾸준한 관리가 필요하고, 표본이 크기 때문에 운보다 실력이 결과에 더 많이 반영됩니다.

이 글에서는 Yahoo Fantasy Sports(YFS) 를 기준으로 설명하지만, ESPN이나 Fantrax 등 다른 플랫폼에서도 기본 개념은 대부분 동일합니다.

아키하바라 집중 분석: 7개 키워드로 읽는 도쿄의 전자·서브컬처 성지

Mon, 23 Mar 2026 13:59:09 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

도쿄 치요다구에 위치한 아키하바라(秋葉原) 는 전 세계적으로 “전자상가"와 “오타쿠의 성지"로 알려져 있습니다. 하지만 이 동네의 정체성은 70년이 넘는 시간 동안 끊임없이 변해왔습니다. 전후 라디오 부품 암시장에서 시작해, 가전 거리를 거쳐, 애니메이션·게임·아이돌 문화의 중심지로 탈바꿈했고, 지금은 대규모 재개발을 앞두고 있습니다.

이 글에서는 7개의 키워드 를 축으로 아키하바라의 역사, 현재, 그리고 관광지로서의 매력을 사실 자료에 기반해 정리합니다.

아키하바라 약사(略史)

아키하바라의 역사를 이해하면 각 키워드가 왜 이 거리와 연결되는지 자연스럽게 보입니다.

브롬톤 자전거: 역사, 특징, 그리고 왜 브롬톤이어야 하는가

Wed, 18 Mar 2026 14:49:12 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

브롬톤, 그 이름의 무게

접이식 자전거 시장에는 수많은 브랜드가 존재한다. 다혼(Dahon), 턴(Tern), 버디(Birdy), 미니벨로 계열까지 선택지는 넓다. 그런데도 “접이식 자전거"라는 단어를 들었을 때 많은 사람들이 가장 먼저 떠올리는 이름이 있다. 바로 브롬톤(Brompton) 이다.

브롬톤은 단순한 접이식 자전거가 아니다. 반세기에 가까운 역사를 가진, 영국 제조업의 자존심이자, “접이식 자전거란 이런 것이다"라는 기준을 세운 자전거다. 이 글에서는 브롬톤의 역사부터 특징, 장단점, 그리고 왜 다른 접이식 자전거가 아닌 브롬톤이어야 하는지를 깊이 있게 다뤄본다.

NLH 스타팅 핸드 가이드 Part 3: 핸드 예시, 멀티웨이 팟, 3bet 전략

Thu, 12 Mar 2026 12:26:21 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 핸드 등급 분류를, Part 2에서 포지션별 레인지와 벳 사이즈 대응을 다뤘습니다. 이번 마지막 Part에서는 구체적인 핸드 예시, 멀티웨이 팟 조정, 3bet 팟 전략, 그리고 상황별 스타일 전환을 다룹니다.

구체적인 핸드 예시: 포지션별 결정

예시 1: AKo (티어 2)

오프수트 에이스킹. 프리미엄에 가까운 강한 핸드지만, 수티드가 아니므로 플러시 가능성이 없습니다.

포지션	TAG	LAG
BTN	오픈 레이즈	오픈 레이즈
CO	오픈 레이즈	오픈 레이즈
MP	오픈 레이즈	오픈 레이즈
UTG	오픈 레이즈	오픈 레이즈
BB vs BTN 오픈	3bet	3bet
SB vs CO 오픈	3bet	3bet
vs 3bet (IP)	콜 또는 4bet	4bet
vs 3bet (OOP)	4bet 또는 콜	4bet

두 스타일 모두 어떤 포지션에서든 플레이합니다. 차이는 3bet을 받았을 때 나타나는데, TAG는 콜도 혼합하지만 LAG는 4bet을 더 선호합니다. AKo는 콜보다 4bet이 나은 경우가 많습니다 — 에퀴티가 높고, 상대의 약한 핸드를 폴드시키는 가치가 있기 때문입니다.

NLH 스타팅 핸드 가이드 Part 2: TAG/LAG 포지션별 레인지와 벳 사이즈 대응

Thu, 12 Mar 2026 12:26:18 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 TAG/LAG 스타일의 차이와 5단계 핸드 등급 분류를 다뤘습니다. 이번 Part 2에서는 각 스타일별로 포지션에 따른 구체적인 레인지, 벳 사이즈, 그리고 선 플레이어의 오픈 사이즈에 따른 대응 방법을 정리합니다.

TAG 스타일: 포지션별 스타팅 핸드 레인지

TAG - BTN (Button)

버튼은 최고의 포지션입니다. TAG도 여기서는 상대적으로 넓게 플레이합니다.

오픈 레이즈 레인지 (VPIP ~22-25%):

티어	핸드	액션
티어 1	AA, KK, QQ, AKs	레이즈 (2.5~3x)
티어 2	JJ, TT, AKo, AQs, AJs, KQs	레이즈
티어 3	99, 88, AQo, ATs, KJs, QJs, JTs, AJo, KQo	레이즈
티어 4	77, 66, A9s~A2s, KTs, QTs, T9s, 98s, 87s	레이즈
티어 5	55~22 (선택적)	레이즈 또는 폴드

vs 오픈 레이즈 (CO가 오픈):

NLH 스타팅 핸드 가이드 Part 1: TAG/LAG 스타일과 핸드 등급 분류

Thu, 12 Mar 2026 12:26:15 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

노 리밋 홀덤에서 프리플랍 핸드 선택은 장기 수익의 토대입니다. 아무리 포스트플랍을 잘해도, 잘못된 핸드로 팟에 참여하면 결국 손실이 누적됩니다. 반대로, 올바른 핸드 선택만으로도 초중급 테이블에서는 충분히 수익을 낼 수 있습니다.

이 시리즈에서는 플레이 스타일(TAG/LAG) 과 포지션(SB/BB/UTG/MP/CO/BTN) 에 따른 스타팅 핸드 선택을 체계적으로 정리합니다. 핸드 등급 분류부터 벳 사이즈에 따른 대응, 구체적인 예시까지 실전에서 바로 적용할 수 있는 가이드를 제공합니다.

웹서비스 내부 구조 아키텍처 가이드 Part 2: EDA, VSA, Modular Monolith

Thu, 12 Mar 2026 10:07:30 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 Layered Architecture, Ports & Adapters 계열(Hexagonal/Onion/Clean), CQRS를 다뤘습니다. Part 2에서는 나머지 세 아키텍처와 전체 비교를 다룹니다.

4. Event-Driven Architecture (EDA)

개요

Event-Driven Architecture는 시스템 구성 요소 간의 통신을 이벤트를 통해 수행 하는 설계 패턴입니다. 컴포넌트가 서로 직접 호출하는 대신, “무언가가 발생했다"는 사실을 이벤트로 발행하면, 관심 있는 컴포넌트가 이를 구독하여 반응합니다.

이 글의 전제가 Kafka/RabbitMQ 같은 메시지 브로커를 포함하는 환경이므로, EDA를 내부 구조 패턴으로 다루는 것은 매우 자연스럽습니다. 메시지 브로커가 있다는 것 자체가 이미 이벤트 기반 통신의 인프라를 갖추고 있다는 뜻이기 때문입니다.

웹서비스 내부 구조 아키텍처 가이드 Part 1: Layered, Ports & Adapters, CQRS

Thu, 12 Mar 2026 10:07:29 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 웹서비스를 전제로 합니다. 구체적으로는 HTML/CSS/JS 프런트엔드, REST/gRPC 기반 백엔드, RDB/Redis/NoSQL 저장소, Kafka/RabbitMQ 같은 메시지 브로커가 있는 환경을 상정합니다.

비교 대상은 “배포 아키텍처"가 아닙니다. 마이크로서비스냐 모놀리스냐의 문제가 아니라, 애플리케이션 내부 코드를 어떻게 나누고, 의존성을 어느 방향으로 흐르게 하며, 변경을 어떤 단위로 흡수할 것인가 에 관한 내부 구조 아키텍처입니다. Microsoft도 논리적 계층(layer)과 물리적 계층(tier)을 구분하며, 논리적 계층 분리가 반드시 별도 서버 분리를 의미하지는 않는다고 설명합니다.

오마하 스타팅 핸드 가이드 Part 3: 핸드 예시, 멀티웨이 팟, 3bet 전략

Wed, 11 Mar 2026 14:11:21 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 핸드 등급 분류를, Part 2에서 포지션별 레인지를 다뤘습니다. 이번 마지막 Part에서는 구체적인 핸드 예시, 멀티웨이 팟 조정, 3bet 팟 전략, 그리고 상황별 스타일 전환을 다룹니다.

구체적인 핸드 예시: 포지션별 결정

예시 1: `A♠K♠Q♥J♣` (티어 2)

싱글 수티드 하이 런다운. 넛 스트레이트와 넛 플러시 가능성이 모두 있는 강한 핸드입니다.

포지션	TAG	LAG
BTN	오픈 레이즈	오픈 레이즈
CO	오픈 레이즈	오픈 레이즈
MP	오픈 레이즈	오픈 레이즈
UTG	오픈 레이즈	오픈 레이즈
BB vs BTN 오픈	3bet 또는 콜	3bet
SB vs CO 오픈	3bet	3bet

두 스타일 모두 어떤 포지션에서든 플레이하는 핸드입니다. 차이는 BB에서 나타나는데, TAG는 콜도 혼합하지만 LAG는 밸류 3bet을 선호합니다.

오마하 스타팅 핸드 가이드 Part 2: TAG/LAG 포지션별 스타팅 핸드 레인지

Wed, 11 Mar 2026 14:11:18 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 TAG/LAG 스타일의 차이와 5단계 핸드 등급 분류를 다뤘습니다. 이번 Part 2에서는 각 스타일별로 포지션에 따른 구체적인 레인지와 베팅 사이즈를 정리합니다.

TAG 스타일: 포지션별 스타팅 핸드 레인지

TAG - BTN (Button)

버튼은 최고의 포지션입니다. TAG도 여기서는 상대적으로 넓게 플레이합니다.

오픈 레이즈 레인지 (VPIP ~22-25%):

티어	핸드	액션
티어 1	모든 프리미엄	레이즈 (3-3.5x)
티어 2	모든 강한 핸드	레이즈
티어 3	대부분	레이즈
티어 4	선택적	림퍼 있으면 레이즈, 아니면 폴드
티어 5	없음	폴드

vs 오픈 레이즈 (CO가 오픈):

오마하 스타팅 핸드 가이드 Part 1: TAG/LAG 스타일과 핸드 등급 분류

Wed, 11 Mar 2026 14:11:15 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

오마하에서 프리플랍은 홀덤보다 더 중요합니다. 4장의 카드가 만들어내는 조합의 차이가 포스트플랍 전체를 좌우하기 때문입니다. 잘못된 핸드로 팟에 들어가면 아무리 포스트플랍을 잘해도 장기적으로 손실입니다.

이 시리즈에서는 플레이 스타일(TAG/LAG) 과 포지션(SB/BB/CO/BTN) 에 따른 스타팅 핸드 선택을 체계적으로 정리합니다. 핸드 등급 분류부터 구체적인 베팅 전략까지, 실전에서 바로 적용할 수 있는 가이드를 제공합니다.

Part 1 (이 글): TAG/LAG 스타일과 핸드 등급 분류
Part 2: TAG/LAG 포지션별 스타팅 핸드 레인지
Part 3: 핸드 예시, 멀티웨이 팟, 3bet 팟 전략

플레이 스타일: TAG vs LAG

TAG (Tight-Aggressive)

TAG는 “타이트하게 선택하고, 선택한 핸드는 공격적으로” 플레이하는 스타일입니다.

WELC ver. 2026 Part 5: 의존성 깨기 기법 카탈로그

Wed, 04 Mar 2026 10:03:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

원서 Chapter 25는 25가지 의존성 깨기(Dependency-Breaking) 기법을 카탈로그 형태로 제시합니다. 각 기법은 “테스트 하네스에 코드를 넣기 위해 의존성을 어떻게 끊을 것인가"라는 질문에 대한 구체적인 답입니다.

다만 일부 기법은 C/C++ 전용이거나, 현대 Java에서는 불필요합니다. Link Substitution, Text Redefinition, Replace Function with Function Pointer 같은 기법이 대표적입니다. 이 파트에서는 2026년 현재 Java 개발에서 특히 유용한 핵심 기법들을 선별하여 정리합니다.

WELC ver. 2026 Part 4: 대규모 코드 문제 다루기

Wed, 04 Mar 2026 10:03:51 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 시스템에서 가장 자주 마주치는 문제는 규모의 문제입니다. 한 클래스가 수천 줄, 한 메서드가 수백 줄인 코드는 현업에서 흔히 발견됩니다. 이런 코드는 읽기 어렵고, 테스트하기 어렵고, 변경하면 예상치 못한 곳에서 장애가 발생합니다.

이번 글에서는 Michael Feathers의 Working Effectively with Legacy Code 14~22장을 바탕으로, 대규모 코드 문제를 다루는 전략을 JDK 25 기준의 modern Java 코드로 살펴봅니다. SOLID 원칙 중 SRP, ISP, OCP의 실전 적용이 핵심입니다.

WELC ver. 2026 Part 3: 테스트 하네스에 코드 넣기

Wed, 04 Mar 2026 10:03:50 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 코드를 변경하려면 먼저 테스트를 작성해야 합니다. 하지만 테스트를 작성하려면 코드의 의존성을 깨야 합니다. 의존성을 깨려면 코드를 변경해야 하는데, 변경의 안전성을 보장해줄 테스트가 아직 없습니다.

이것이 Feathers가 말하는 “레거시 코드의 딜레마"입니다.

In legacy code, the weights work against us. We have to pull out a piece to work with because we can’t easily test it in place. — Michael Feathers, Working Effectively with Legacy Code (2004)

WELC ver. 2026 Part 2: 안전한 코드 변경 패턴 — Sprout와 Wrap

Wed, 04 Mar 2026 10:03:49 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

Part 1에서 다룬 Legacy Code Change Algorithm의 5단계 중, 이번 글은 “변경 및 리팩터링” 단계에 해당하는 실전 패턴들을 다룹니다. Michael Feathers의 Working Effectively with Legacy Code 6~8장에 등장하는 핵심 기법입니다.

레거시 코드에 기능을 추가해야 하는데 시간이 없을 때, 기존 코드를 전면 리팩터링하는 것은 현실적이지 않습니다. 이때 사용할 수 있는 4가지 패턴이 있습니다.

패턴	핵심 아이디어
Sprout Method	새 기능을 별도 메서드로 추출
Sprout Class	새 기능을 별도 클래스로 분리
Wrap Method	기존 메서드를 감싸서 전후 동작 추가
Wrap Class	Decorator 패턴으로 기존 클래스를 감싸기

이 4가지 패턴의 공통점은 기존 코드를 가능한 한 건드리지 않으면서 새 기능을 추가한다는 것입니다.

WELC ver. 2026 Part 1: 레거시 코드의 정의와 변경의 역학

Wed, 04 Mar 2026 10:03:48 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 소개

2004년 Michael Feathers가 출판한 Working Effectively with Legacy Code (a.k.a. WELC)는 레거시 코드를 안전하게 변경하는 기법들을 체계적으로 정리한 명저입니다. 출판된 지 20년이 넘었지만, 이 책이 제시하는 원칙과 알고리즘은 여전히 유효합니다. 코드베이스가 노후화되는 속도보다 개발자가 이 책을 읽는 속도가 느린 것이 문제일 뿐입니다.

원서의 예제는 Java 1.4/5, C++, C 시대의 코드입니다. 이 시리즈에서는 JDK 25 (2025년 9월 GA, LTS) 기준의 modern Java로 핵심 기법들을 재현합니다. Sealed class, record, text block, pattern matching 등 최신 언어 기능을 적극 활용하여, 원서의 기법이 오늘날 어떤 형태로 적용되는지 보여드리겠습니다.

완벽한 균형의 미학: 현악 4중주(String Quartet)

Thu, 26 Feb 2026 10:25:45 +0900

클래식 음악의 수많은 장르 중에서도 ‘현악 4중주(String Quartet)’ 는 작곡가들의 가장 내밀하고 철학적인 사유가 담기는 그릇으로 평가받습니다. 화려한 오케스트라의 웅장함과는 다른, 네 대의 현악기가 만들어내는 치밀하고 완벽한 대화의 세계를 알아봅니다.

1. 현악 4중주가 탄생하게 된 배경

현악 4중주의 역사는 18세기 고전주의 시대로 거슬러 올라갑니다. 바로크 시대에는 건반 악기(하프시코드 등)가 저음을 받쳐주는 ‘통주저음(Basso Continuo)’ 중심의 음악이 주를 이루었습니다.

현악 4중주의 형태를 확립하여 ‘현악 4중주의 아버지’ 라 불리는 인물은 조셉 하이든(Joseph Haydn) 입니다. 1750년대, 하이든이 퓌른베르크 남작의 저택에 초대받았을 때 연주할 수 있는 인원이 바이올린 2명, 비올라 1명, 첼로 1명뿐이었습니다. 하이든은 이 네 명만을 위한 곡을 우연히 작곡하게 되었고, 건반 악기의 도움 없이 네 대의 현악기만으로 완벽한 화성을 만들어낼 수 있다는 것을 깨달았습니다. 이후 모차르트와 베토벤을 거치며 현악 4중주는 클래식 음악의 가장 중요한 실내악 형식으로 자리 잡았습니다.

스트라토캐스터 스트링 게이지 가이드

Mon, 09 Feb 2026 10:54:27 +0900

이 글은 Gemini 3 Pro 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

스트라토캐스터(Stratocaster)는 부품 하나하나가 유기적으로 연결된 ‘살아있는’ 악기입니다. 그중에서도 스트링 게이지(String Gauge)의 변화는 가장 저렴하면서도 기타의 성향을 극적으로 바꾸는 튜닝입니다.

단순히 “손이 아프다/안 아프다"를 넘어, 게이지별 톤의 물리학적 변화와 그에 따른 싱크로나이즈드 트레몰로 브릿지 세팅법, 그리고 하드웨어 셋업의 핵심을 정리했습니다.

1. 게이지별 톤 & 연주감 심층 분석

스트링이 굵어질수록 질량(Mass) 이 증가하여, 같은 음정(Pitch)을 내기 위해 더 강한 장력(Tension) 이 필요합니다. 이는 픽업의 자기장 안에서 진동하는 금속의 양과 운동 에너지가 달라짐을 의미합니다.

Java to Go: #5. 프로젝트 구조와 생태계

Wed, 21 Jan 2026 12:28:40 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

지금까지 Go의 철학, 문법, 에러 처리, 동시성을 살펴봤다. 이제 실제 프로젝트를 시작하는 데 필요한 것들을 다룬다. Maven/Gradle에서 Go Modules로, JUnit에서 testing 패키지로, Spring에서 Go 라이브러리 조합으로 전환하는 방법을 알아보자.

1. Go Modules 기초

go.mod와 go.sum

Go 1.11부터 도입된 Go Modules가 공식 의존성 관리 시스템이다.

# 새 모듈 초기화
mkdir myproject && cd myproject
go mod init github.com/username/myproject

생성된 go.mod:

module github.com/username/myproject

go 1.21

의존성을 추가하면:

Java to Go: #4. 동시성: Goroutine과 Channel

Wed, 21 Jan 2026 12:28:36 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go의 동시성 모델은 Java와 근본적으로 다르다. Thread, synchronized, ExecutorService에 익숙한 개발자라면 처음엔 낯설겠지만, Go의 방식이 얼마나 우아한지 금방 알게 될 것이다. “공유 메모리로 통신하지 말고, 통신으로 메모리를 공유하라"는 Go의 철학을 이해해보자.

1. Goroutine: 경량 스레드

go 키워드 하나로 시작하는 동시성

Java에서 새 스레드를 만들려면:

new Thread(() -> {
 System.out.println("Hello from thread");
}).start();

// 또는 ExecutorService
ExecutorService executor = Executors.newFixedThreadPool(10);
executor.submit(() -> {
 System.out.println("Hello from thread pool");
});

Go에서는 go 키워드 하나면 된다:

Java to Go: #3. 에러 처리와 Null 안전성

Wed, 21 Jan 2026 12:28:33 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java 개발자가 Go를 배울 때 가장 큰 패러다임 전환이 필요한 부분이 에러 처리다. try-catch에 익숙한 우리에게 if err != nil의 반복은 처음엔 원시적으로 느껴진다. 하지만 이 방식에는 명확한 철학이 있다. 이번 편에서 그 철학을 이해하고, Go 방식의 에러 처리에 익숙해져 보자.

1. Java의 Exception vs Go의 error

근본적인 차이

Java: 예외는 “특별한 상황"이다. 정상 흐름과 분리되어 throw/catch로 처리된다.

Java to Go: #2. 문법 전환 가이드: Java 코드를 Go로 옮기기

Wed, 21 Jan 2026 12:28:30 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 Go의 철학과 언제 Go를 선택해야 하는지 살펴봤다. 이제 실제 코드 레벨에서 Java와 Go가 어떻게 다른지 1:1로 비교해보자. Java 문법에 익숙한 개발자가 Go 코드를 읽고 쓸 수 있도록 핵심 차이점을 정리한다.

1. 변수 선언과 타입 시스템

기본 변수 선언

Java:

String name = "Alice";
int age = 30;
final double PI = 3.14159;

Go:

var name string = "Alice"
var age int = 30
const PI = 3.14159

Go에서는 타입이 변수명 뒤에 온다. 처음엔 어색하지만, 복잡한 타입 선언에서는 오히려 읽기 쉽다.

Java to Go: #1. Go 첫인상: 철학과 패러다임의 차이

Wed, 21 Jan 2026 12:28:27 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java를 수년간 써온 개발자가 Go를 처음 접하면 당혹스럽다. “왜 이렇게 만들었지?“라는 생각이 끊이지 않는다. 이 글에서는 Go의 설계 철학을 이해하고, Java에서 Go로의 전환이 언제 적절한지 판단할 수 있는 기준을 제시한다.

1. Go의 설계 철학: “Less is more”

Go는 2009년 Google에서 Robert Griesemer, Rob Pike, Ken Thompson이 만들었다. 세 사람 모두 수십 년 경력의 시스템 프로그래머로, C++의 복잡성에 지쳐 있었다. Go의 탄생 배경 자체가 “복잡함에 대한 반발"이다.

Go to Rust: #10. 프로젝트 관리와 실전 패턴

Mon, 19 Jan 2026 16:10:08 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 마지막 섹션에서는 실제 Rust 프로젝트를 구성하고 관리하는 방법을 학습합니다. Cargo 심화, 모듈 시스템, 테스트, 그리고 Go 코드를 Rust로 포팅할 때 유용한 패턴들을 다룹니다.

10.1 Cargo 심화

Cargo.toml 상세 설정

[package]
name = "myapp"
version = "0.1.0"
edition = "2021"
authors = ["Your Name <you@example.com>"]
description = "A sample Rust application"
license = "MIT"
repository = "https://github.com/you/myapp"
keywords = ["cli", "tool"]
categories = ["command-line-utilities"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

[dev-dependencies]
criterion = "0.5" # 벤치마크용

[build-dependencies]
cc = "1.0" # 빌드 스크립트용

[features]
default = ["json"]
json = ["serde_json"]
full = ["json", "yaml"]

[[bin]]
name = "myapp"
path = "src/main.rs"

[[bin]]
name = "mytool"
path = "src/bin/mytool.rs"

[profile.release]
opt-level = 3
lto = true

의존성 관리

[dependencies]
# 버전 지정
serde = "1.0" # ^1.0.0 (1.x.x)
serde = "=1.0.104" # 정확히 1.0.104
serde = ">=1.0, <2.0" # 범위

# Git 의존성
mylib = { git = "https://github.com/user/mylib" }
mylib = { git = "https://github.com/user/mylib", branch = "dev" }
mylib = { git = "https://github.com/user/mylib", tag = "v1.0.0" }
mylib = { git = "https://github.com/user/mylib", rev = "abc123" }

# 로컬 경로
mylib = { path = "../mylib" }

# 선택적 의존성
serde_json = { version = "1.0", optional = true }

# 피처 플래그
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

Go modules와 비교

# Go: go.mod
module github.com/user/myapp

go 1.21

require (
 github.com/gin-gonic/gin v1.9.0
 github.com/lib/pq v1.10.0
)

# Rust: Cargo.toml
[package]
name = "myapp"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.7"
sqlx = { version = "0.7", features = ["postgres"] }

측면	Go	Cargo
의존성 파일	go.mod	Cargo.toml
락 파일	go.sum	Cargo.lock
저장소	분산 (GitHub 등)	중앙 (crates.io)
버전 관리	Git 태그	SemVer

피처 플래그

[features]
default = ["std"]
std = []
alloc = []
json = ["serde", "serde_json"]
full = ["json", "yaml", "toml"]

// 조건부 컴파일
#[cfg(feature = "json")]
pub mod json {
 pub fn parse_json(s: &str) -> Value { /* ... */ }
}

#[cfg(feature = "std")]
use std::collections::HashMap;

#[cfg(not(feature = "std"))]
use alloc::collections::BTreeMap as HashMap;

10.2 모듈 시스템

파일 시스템과 모듈 구조

myapp/
├── Cargo.toml
└── src/
 ├── main.rs # 바이너리 루트
 ├── lib.rs # 라이브러리 루트
 ├── config.rs # config 모듈
 ├── utils/
 │ ├── mod.rs # utils 모듈
 │ ├── helpers.rs # utils::helpers
 │ └── format.rs # utils::format
 └── handlers/
 ├── mod.rs
 ├── user.rs
 └── post.rs

lib.rs:

Go to Rust: #9. 비동기 프로그래밍

Mon, 19 Jan 2026 16:09:59 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 async/await는 Go의 goroutine과 근본적으로 다른 접근 방식입니다. Go는 런타임이 모든 것을 관리하지만, Rust는 명시적인 비동기 모델을 사용합니다. 이 섹션에서는 Rust의 비동기 생태계와 Tokio 런타임을 학습합니다.

9.1 비동기의 필요성

동기 vs 비동기

동기 (Synchronous):

// 순차적 실행, 블로킹
fn fetch_data() -> Data {
 let response = http_get("https://api.example.com"); // 대기
 parse(response)
}

비동기 (Asynchronous):

// 대기 중 다른 작업 가능
async fn fetch_data() -> Data {
 let response = http_get("https://api.example.com").await; // 양보
 parse(response)
}

Go의 goroutine 모델

Go는 런타임이 내장되어 있어 동기 코드처럼 보이지만 비동기로 동작합니다:

Go to Rust: #8. 동시성 프로그래밍

Mon, 19 Jan 2026 16:09:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 “Fearless Concurrency"는 컴파일 타임에 데이터 레이스를 방지합니다. Go의 고루틴과 채널에 익숙하다면, Rust의 동시성 모델이 어떻게 다른지 이해하는 것이 중요합니다.

8.1 Rust의 동시성 철학

“Fearless Concurrency"란?

Go의 철학: “Don’t communicate by sharing memory; share memory by communicating.” Rust의 철학: “Fearless Concurrency through ownership.”

Go	Rust
런타임에 데이터 레이스 감지 (`-race`)	컴파일 타임에 데이터 레이스 방지
고루틴 + 채널 권장	소유권 + 타입 시스템으로 안전성 보장
공유 메모리도 가능 (주의 필요)	공유 메모리도 안전하게 사용 가능

데이터 레이스의 세 가지 조건

두 스레드가 같은 데이터에 접근
적어도 하나가 쓰기 작업
접근이 동기화되지 않음

Rust는 소유권 규칙으로 이를 컴파일 타임에 방지합니다:

Go to Rust: #7. 컬렉션과 이터레이터

Mon, 19 Jan 2026 16:09:42 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 컬렉션은 Go와 유사한 기능을 제공하지만, 소유권 시스템과 결합되어 더 안전합니다. 특히 이터레이터 시스템은 Go의 range보다 훨씬 강력하며, 함수형 프로그래밍 스타일을 지원합니다.

7.1 표준 컬렉션 개요

Go와 Rust 컬렉션 매핑

Go	Rust	설명
`[]T` (slice)	`Vec<T>`	동적 배열
`[N]T` (array)	`[T; N]`	고정 배열
`string`	`String`	소유된 문자열
`string` (리터럴)	`&str`	문자열 슬라이스
`map[K]V`	`HashMap<K, V>`	해시 맵
-	`HashSet<T>`	해시 셋
-	`BTreeMap<K, V>`	정렬된 맵
-	`BTreeSet<T>`	정렬된 셋
-	`VecDeque<T>`	양방향 큐
`container/list`	`LinkedList<T>`	이중 연결 리스트

7.2 Vec 심화

생성 방법들

// 빈 벡터
let v: Vec<i32> = Vec::new();

// vec! 매크로 (가장 흔함)
let v = vec![1, 2, 3, 4, 5];

// 같은 값으로 초기화
let v = vec![0; 10]; // [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

// 용량 미리 할당
let mut v = Vec::with_capacity(100);

// 이터레이터에서 수집
let v: Vec<i32> = (1..=5).collect();

// from_iter
let v = Vec::from_iter([1, 2, 3]);

기본 연산

let mut v = vec![1, 2, 3];

// 추가
v.push(4); // 끝에 추가
v.insert(0, 0); // 인덱스에 삽입: [0, 1, 2, 3, 4]

// 제거
let last = v.pop(); // 끝에서 제거, Option<T>
let removed = v.remove(0); // 인덱스에서 제거, T
v.retain(|&x| x > 2); // 조건에 맞는 것만 유지

// 접근
let first = v[0]; // 패닉 가능
let first = v.get(0); // Option<&T>
let first = v.first(); // Option<&T>
let last = v.last(); // Option<&T>

// 수정
v[0] = 10;
if let Some(first) = v.first_mut() {
 *first = 20;
}

Go의 append vs Rust의 push

// Go: append는 새 슬라이스 반환 가능
slice := []int{1, 2, 3}
slice = append(slice, 4) // 재할당 가능

// 용량 확인
cap(slice)

// Rust: push는 in-place 수정
let mut v = vec![1, 2, 3];
v.push(4); // v가 mut이어야 함

// 용량
v.capacity();
v.reserve(100); // 추가 용량 확보
v.shrink_to_fit(); // 불필요한 용량 해제

소유권과 Vec

let v = vec![String::from("a"), String::from("b")];

// 인덱스 접근은 빌림
let first: &String = &v[0]; // 불변 빌림

// for 루프는 소유권 이동 또는 빌림 선택 가능
for s in v { // v의 소유권 이동, s: String
 println!("{}", s);
}
// v는 더 이상 사용 불가

let v = vec![String::from("a"), String::from("b")];
for s in &v { // v 빌림, s: &String
 println!("{}", s);
}
// v 여전히 사용 가능

for s in &mut v { // 가변 빌림, s: &mut String
 s.push_str("!");
}

슬라이싱

let v = vec![1, 2, 3, 4, 5];

// 슬라이스 참조
let slice: &[i32] = &v[1..4]; // [2, 3, 4]
let slice: &[i32] = &v[..]; // 전체

// 가변 슬라이스
let mut v = vec![1, 2, 3, 4, 5];
let slice: &mut [i32] = &mut v[1..4];
slice[0] = 20; // v는 [1, 20, 3, 4, 5]

7.3 문자열 처리

String vs &str

// String: 힙에 할당된 소유 문자열
let owned: String = String::from("hello");
let owned: String = "hello".to_string();
let owned: String = "hello".to_owned();

// &str: 문자열 슬라이스 (빌림)
let borrowed: &str = "hello"; // 정적 문자열
let borrowed: &str = &owned; // String에서 빌림
let borrowed: &str = &owned[0..3]; // 부분 슬라이스

특성	`String`	`&str`
소유권	있음	없음 (빌림)
힙 할당	예	아니오
가변	가능	불가능
크기	가변	고정 (뷰)
함수 인자	소유권 필요시	대부분

UTF-8 인코딩

Rust 문자열은 항상 유효한 UTF-8입니다:

Go to Rust: #6. 에러 처리

Mon, 19 Jan 2026 16:09:35 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 에러 처리는 Go와 철학적으로 유사합니다. 두 언어 모두 예외(exception)를 사용하지 않고 명시적인 에러 반환을 선호합니다. 하지만 Rust는 타입 시스템을 통해 에러 처리를 강제하여, Go에서 흔히 발생하는 “에러 무시” 문제를 원천 차단합니다.

6.1 Rust의 에러 처리 철학

복구 가능한 에러 vs 복구 불가능한 에러

Rust는 에러를 두 가지로 구분합니다:

복구 가능한 에러 (Recoverable): Result<T, E>

파일을 찾을 수 없음
네트워크 연결 실패
잘못된 사용자 입력

복구 불가능한 에러 (Unrecoverable): panic!

Go to Rust: #5. 트레이트와 제네릭

Mon, 19 Jan 2026 09:56:15 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

트레이트(Trait)는 Rust의 다형성 메커니즘입니다. Go의 인터페이스와 비슷한 역할을 하지만, 구현 방식과 기능에서 큰 차이가 있습니다. 이 섹션에서는 트레이트와 제네릭을 Go와 비교하며 깊이 있게 학습합니다.

5.1 트레이트 기초

트레이트란?

트레이트는 타입이 구현해야 하는 메서드 집합을 정의합니다:

// 트레이트 정의
trait Summary {
 fn summarize(&self) -> String;
}

// 타입 정의
struct Article {
 title: String,
 author: String,
 content: String,
}

// 트레이트 구현
impl Summary for Article {
 fn summarize(&self) -> String {
 format!("{} by {}", self.title, self.author)
 }
}

Go interface vs Rust trait

가장 큰 차이: 암묵적 vs 명시적

Go to Rust: #4. 구조체, 열거형, 패턴 매칭

Mon, 19 Jan 2026 09:56:10 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust에서 데이터를 구조화하는 방법을 학습합니다. Go 개발자에게 구조체는 익숙하겠지만, Rust의 열거형(enum)은 Go의 const/iota보다 훨씬 강력하며, 패턴 매칭은 switch문을 완전히 새로운 수준으로 끌어올립니다.

4.1 구조체 (Struct)

구조체 정의와 인스턴스 생성

// 구조체 정의
struct User {
 username: String,
 email: String,
 sign_in_count: u64,
 active: bool,
}

// 인스턴스 생성
fn main() {
 let user = User {
 username: String::from("alice"),
 email: String::from("alice@example.com"),
 sign_in_count: 1,
 active: true,
 };
 
 // 필드 접근
 println!("Username: {}", user.username);
}

Go struct와의 문법 비교:

Go to Rust: #3. 소유권과 빌림 (Ownership & Borrowing)

Mon, 19 Jan 2026 09:56:03 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

소유권(Ownership)은 Rust의 가장 독특하고 중요한 개념입니다. Go의 가비지 컬렉션과 완전히 다른 접근 방식으로, 컴파일 타임에 메모리 안전성을 보장합니다. 이 섹션은 Rust 학습에서 가장 중요한 부분이므로 충분한 시간을 들여 이해하시기 바랍니다.

3.1 소유권이란 무엇인가?

메모리 관리의 세 가지 방식

프로그래밍 언어들은 메모리를 관리하는 방식이 다릅니다:

1. 가비지 컬렉션 (Go, Java, Python, JavaScript)

// Go: GC가 알아서 정리
func example() {
 slice := make([]int, 1000000)
 // 함수 종료 후 GC가 언젠가 정리
}

장점: 개발자가 메모리 관리 신경 안 써도 됨
단점: GC 일시 정지, 예측 불가능한 지연, 메모리 오버헤드

2. 수동 관리 (C, C++)

Go to Rust: #2. 기본 문법과 타입 시스템

Mon, 19 Jan 2026 09:55:56 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust의 기본 문법을 Go와 비교하며 학습합니다. Go 개발자에게 익숙한 개념들이 Rust에서 어떻게 표현되는지, 그리고 Rust만의 독특한 특징은 무엇인지 알아봅니다.

2.1 변수와 가변성

let vs var: 불변이 기본인 이유

Go에서는 변수가 기본적으로 가변(mutable)입니다:

// Go: 기본이 가변
x := 10
x = 20 // OK

Rust에서는 불변(immutable)이 기본입니다:

// Rust: 기본이 불변
let x = 10;
x = 20; // 컴파일 에러!

왜 불변이 기본일까요?

Go to Rust: #1. 시작하기 - Rust 소개와 환경 설정

Mon, 19 Jan 2026 09:55:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go 개발자로서 새로운 언어를 배우려면 먼저 그 언어가 왜 존재하는지, 어떤 문제를 해결하려고 하는지 이해하는 것이 중요합니다. 이 섹션에서는 Rust의 설계 철학을 Go와 비교하며 이해하고, 개발 환경을 설정한 뒤 첫 프로젝트를 생성해봅니다.

1.1 Rust는 왜 배워야 하는가?

Rust의 설계 철학

Rust는 Mozilla Research에서 시작되어 2015년에 1.0이 릴리스된 시스템 프로그래밍 언어입니다. Rust의 핵심 목표는 세 가지입니다:

안전성(Safety): 메모리 안전성을 컴파일 타임에 보장
속도(Speed): C/C++에 필적하는 성능
동시성(Concurrency): 데이터 레이스 없는 동시성 프로그래밍

Go도 비슷한 시기(2009년)에 등장했지만, 설계 목표가 다릅니다:

Go to Rust: #0. Overview

Mon, 19 Jan 2026 08:36:02 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

From Go to Rust: A Comprehensive Guide for Go Developers

Go 언어에 익숙한 개발자가 Rust를 체계적으로 학습할 수 있도록 구성된 가이드입니다. Go와의 비교를 통해 새로운 개념을 빠르게 이해하고, 실무에서 바로 적용할 수 있는 실용적인 내용을 담았습니다.

가이드의 특징

Go 개발자 관점: 모든 개념을 Go와 비교하여 설명, 익숙한 개념에서 출발
실용적 접근: 이론보다 실제 코드 예제 중심
점진적 난이도: 기초부터 고급까지 체계적 진행
실전 지향: 각 섹션에 Go ↔ Rust 코드 변환 예제 포함
함정 주의: Go 개발자가 흔히 하는 실수와 해결법 명시

섹션별 상세 목차

Section 1: 시작하기 - Rust 소개와 환경 설정

Rust의 설계 철학을 이해하고, Go와의 포지셔닝 차이를 명확히 합니다. 개발 환경을 설정하고 첫 프로젝트를 생성합니다.

Modern Worship & Pop Guitar – Technique Playbook

Fri, 16 Jan 2026 18:54:53 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1. 밴드에서 기타의 자리

1.1 주파수 대역의 이해

밴드에서 기타가 가장 잘 들리는 음역은 중·중상단이다.

줄	대역	충돌 대상
4~6번줄	저음	베이스와 충돌
1번줄	고음	보컬과 충돌
2·3번줄	중음	기타의 자리

1.2 가이드톤 철학

3도와 7도(가이드톤)가 자연스럽게 2·3번줄에 놓여 있기 때문에, 이 두 줄만으로도 코드의 성격이 전달된다.

Texas Hold'em 가이드: #21. 실전 핸드 리뷰 - 배운 것을 적용하기

Fri, 16 Jan 2026 18:45:57 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“핸드 리뷰는 거울이다. 자신의 플레이를 직시할 용기가 있어야 성장한다.”

시리즈의 마지막 편입니다. 지금까지 배운 모든 개념을 실전 핸드 리뷰를 통해 종합해보겠습니다. 핸드 리뷰는 포커 실력 향상의 가장 효과적인 방법이며, 이론을 실전으로 연결하는 다리입니다.

이번 편에서는 핸드 리뷰 방법론을 배우고, 실제 핸드 예시를 분석하며, 21편 전체를 총정리합니다.

핸드 리뷰 방법론

왜 핸드 리뷰가 중요한가

1. 실수 발견

무의식적 리크 파악
반복되는 패턴 인식

2. 이론 ↔ 실전 연결

Texas Hold'em 가이드: #20. 멘탈 게임과 장기적 성장

Fri, 16 Jan 2026 18:45:51 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“포커에서 가장 중요한 스킬은 카드를 읽는 것이 아니라 자신을 다스리는 것이다.”

지금까지 우리는 포커의 기술적인 면을 배웠습니다. 포지션, 핸드 선택, 베팅 전략, GTO… 하지만 이 모든 지식이 있어도 멘탈 게임이 받쳐주지 않으면 장기적으로 성공할 수 없습니다.

이번 편에서는 포커에서 가장 과소평가되지만 가장 중요한 요소인 멘탈 게임, 분산 관리, 뱅크롤 관리, 그리고 지속적인 성장 방법을 배워보겠습니다.

분산(Variance)의 현실

분산이란?

분산은 결과가 기대값 주변에서 얼마나 흩어지는지를 나타냅니다.

Texas Hold'em 가이드: #19. 토너먼트 전략 (下) - 파이널 테이블과 다양한 포맷

Fri, 16 Jan 2026 18:45:46 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“파이널 테이블은 모든 것이 걸린 무대다. 여기서 진정한 챔피언이 결정된다.”

토너먼트의 꽃은 파이널 테이블입니다. 수백, 수천 명 중 최후의 9명(또는 6명)에 올라 우승을 다투는 순간입니다. 또한 토너먼트에는 MTT 외에도 SNG, 스핀앤고, 위성 등 다양한 포맷이 있습니다.

이번 편에서는 파이널 테이블 전략과 다양한 토너먼트 포맷별 접근법을 배워보겠습니다.

파이널 테이블 전략

파이널 테이블의 특수성

1. 페이 점프가 크다

순위	프라이즈 (예시)	점프
9위	$1,000	-
8위	$1,200	+$200
7위	$1,500	+$300
6위	$2,000	+$500
5위	$2,800	+$800
4위	$4,000	+$1,200
3위	$6,000	+$2,000
2위	$10,000	+$4,000
1위	$18,000	+$8,000

순위가 올라갈수록 점프가 커짐

Texas Hold'em 가이드: #18. 토너먼트 전략 (上) - ICM과 단계별 전략

Fri, 16 Jan 2026 18:45:41 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“토너먼트에서 칩은 돈이 아니다. 칩의 가치는 상황에 따라 변한다.”

토너먼트 포커는 캐시게임과 근본적으로 다른 게임입니다. 캐시게임에서 칩은 곧 돈이지만, 토너먼트에서 칩은 프라이즈 풀의 지분을 나타내며, 그 가치는 상황에 따라 변합니다.

이번 편에서는 토너먼트 특유의 개념인 ICM과 단계별 전략을 배워보겠습니다.

캐시게임 vs 토너먼트: 근본적 차이

칩 가치의 차이

캐시게임:

1 칩 = $1 (또는 해당 금액)
항상 동일한 가치
cEV(Chip EV) = $EV

토너먼트:

Texas Hold'em 가이드: #17. GTO와 익스플로잇의 균형

Fri, 16 Jan 2026 18:45:36 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

“GTO는 방패이고, 익스플로잇은 창이다. 둘 다 능숙하게 다뤄야 전사가 된다.”

현대 포커에서 GTO(Game Theory Optimal) 는 피할 수 없는 개념이 되었습니다. 솔버가 보급되면서 “최적의 플레이"에 대한 기준이 생겼고, 이를 이해하지 못하면 상위 레벨에서 경쟁하기 어렵습니다.

하지만 동시에, 실제 테이블에서 GTO만 고집하면 돈을 테이블 위에 남겨두게 됩니다. 이번 편에서는 GTO의 본질을 이해하고, 언제 GTO를 따르고 언제 익스플로잇해야 하는지 배워보겠습니다.

Texas Hold'em 가이드: #16. 라이브 vs 온라인 - 플랫폼별 차이와 적응

Fri, 16 Jan 2026 18:21:55 +0900

“같은 포커지만 다른 게임이다. 둘 다 마스터하면 완전한 플레이어가 된다.”

온라인 포커와 라이브 포커는 같은 규칙을 따르지만, 실제 경험은 크게 다릅니다. 게임 속도, 상대 풀, 정보 수집 방법, 심지어 수익 구조까지 차이가 있습니다.

이번 편에서는 두 플랫폼의 핵심 차이점과 각각에 맞는 전략을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

게임 속도와 핸드 볼륨의 차이

속도 비교

플랫폼	시간당 핸드 수
라이브	25-35핸드
온라인 싱글 테이블	60-80핸드
온라인 2테이블	120-160핸드
온라인 4테이블	240-320핸드

온라인은 라이브보다 2-10배 빠릅니다

Texas Hold'em 가이드: #15. 헤즈업 플레이 - 1:1 대결의 기술

Fri, 16 Jan 2026 18:21:49 +0900

“헤즈업은 포커의 가장 순수한 형태다. 오직 당신과 상대, 그리고 카드뿐.”

헤즈업(Heads-Up)은 오직 두 명의 플레이어가 대결하는 포커입니다. 토너먼트 파이널, 캐시게임 숏핸디드, 또는 전용 헤즈업 테이블에서 경험할 수 있습니다. 헤즈업에서는 6-max나 풀링과는 완전히 다른 전략이 필요합니다.

이번 편에서는 헤즈업 특유의 원리와 전략을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

헤즈업이 다른 이유

블라인드 구조의 차이

6-max/풀링:

SB → BB 순서
버튼은 SB 왼쪽
프리플랍: SB 먼저 행동

헤즈업:

Texas Hold'em 가이드: #14. 딥스택 전략 - 100BB+ 플레이의 세계

Fri, 16 Jan 2026 18:21:44 +0900

“딥스택에서 진짜 포커가 시작된다. 모든 스트릿이 의미를 가진다.”

딥스택 포커는 100BB, 150BB, 심지어 200BB 이상의 스택으로 플레이하는 것을 말합니다. 캐시게임에서 흔하고, 토너먼트 초반에도 경험할 수 있습니다. 딥스택에서는 숏스택과 정반대의 원리가 작동합니다.

이번 편에서는 딥스택 특유의 전략과 사고방식을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

딥스택이 게임을 바꾸는 방식

높은 SPR

SPR 비교:

스택	오픈-콜 후 SPR
40BB	~5
100BB	~13
200BB	~27

높은 SPR의 의미:

Texas Hold'em 가이드: #13. 숏스택 전략 - 20-40BB 플레이의 특수성

Fri, 16 Jan 2026 18:21:15 +0900

“숏스택은 단순하다. 하지만 단순함 속에 정교함이 있다.”

토너먼트 중반 이후, 리바이 후, 또는 의도적으로 숏스택으로 플레이할 때 - 20-40BB 스택은 포커에서 자주 마주치는 상황입니다. 이 스택 깊이에서는 100BB 전략이 통하지 않습니다. 완전히 다른 접근이 필요합니다.

이번 편에서는 숏스택 특유의 전략과 의사결정 프레임워크를 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

숏스택의 정의와 특수성

스택 깊이 분류

스택 깊이	BB 수	특징
딥스택	150BB+	복잡한 포스트플랍, 스펙 핸드 가치
표준 스택	80-150BB	일반적인 전략 적용
미디엄 스택	40-80BB	조정 필요, 3-bet 팟 주의
숏스택	20-40BB	푸시/폴드 근접, 단순화
매우 숏	10-20BB	거의 푸시/폴드
데스퍼레이트	<10BB	순수 푸시/폴드

숏스택이 특별한 이유

1. SPR이 낮다

Texas Hold'em 가이드: #12. 멀티웨이 팟 전략 - 3명 이상일 때 달라지는 모든 것

Thu, 15 Jan 2026 07:16:59 +0900

“헤즈업에서 강한 핸드가 멀티웨이에서는 평범해진다.”

지금까지 우리가 다룬 대부분의 전략은 헤즈업(1:1) 상황을 기준으로 했습니다. 하지만 실제 포커에서는 3명 이상이 플랍을 보는 멀티웨이 팟이 자주 발생합니다. 특히 라이브 게임이나 낮은 스테이크 온라인에서는 매우 흔합니다.

멀티웨이 팟에서는 전략이 근본적으로 달라집니다. 이번 편에서는 그 차이점과 조정 방법을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

멀티웨이 팟의 근본적 특성

에퀴티 분배

헤즈업: 에퀴티가 두 명에게 분배 멀티웨이: 에퀴티가 여러 명에게 분배

Texas Hold'em 가이드: #11. 익스플로잇 전략 - 상대 유형별 조정

Thu, 15 Jan 2026 07:16:53 +0900

“GTO는 상대를 모를 때 쓰는 것이다. 상대를 알면 착취하라.”

지금까지 우리는 균형 잡힌(GTO에 가까운) 전략을 배웠습니다. 하지만 실제 포커 테이블에서 완벽하게 균형 잡힌 플레이어는 거의 없습니다. 대부분의 상대는 분명한 약점을 가지고 있고, 이를 착취(Exploit)하는 것이 수익의 핵심입니다.

이번 편에서는 상대 유형을 분류하고, 각 유형에 맞는 익스플로잇 전략을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

익스플로잇이란?

GTO vs 익스플로잇

GTO (Game Theory Optimal):

상대가 누구든 손해 보지 않는 전략
착취 불가능
상대 약점을 활용하지 않음

익스플로잇 (Exploitative):

Texas Hold'em 가이드: #10. 블러프의 기술

Thu, 15 Jan 2026 07:16:47 +0900

“블러프 없는 포커는 포커가 아니다. 하지만 블러프만 하는 것도 포커가 아니다.”

블러프는 포커의 꽃입니다. 약한 핸드로 상대를 폴드시키고 팟을 가져가는 쾌감은 포커의 가장 큰 매력 중 하나입니다. 하지만 무분별한 블러프는 파산의 지름길이기도 합니다.

이번 편에서는 블러프의 종류, 적절한 빈도, 그리고 좋은 블러프 스팟을 찾는 방법을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

블러프의 종류: 퓨어 블러프 vs 세미블러프

퓨어 블러프 (Pure Bluff)

정의: 쇼다운 밸류가 전혀 없는 핸드로 베팅하여 상대를 폴드시키려는 플레이

Texas Hold'em 가이드: #9. 핸드 리딩의 기초

Thu, 15 Jan 2026 07:16:42 +0900

“포커는 카드 게임이 아니라 사람 게임이다. 상대를 읽어라.”

핸드 리딩(Hand Reading)은 포커에서 가장 중요하면서도 가장 어려운 기술입니다. 상대의 정확한 두 장을 맞추는 것이 아니라, 상대가 가질 수 있는 핸드의 범위(레인지) 를 추론하고, 각 스트릿에서 그 레인지를 좁혀가는 과정입니다.

이번 편에서는 핸드 리딩의 기본 원리와 실전 적용법을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

핸드 리딩이란?

레인지 기반 사고

핸드 리딩 ≠ 상대 핸드 정확히 맞추기 핸드 리딩 = 상대가 가질 수 있는 핸드들의 범위 추론

Texas Hold'em 가이드: #8. 3-bet과 4-bet 전략

Thu, 15 Jan 2026 07:16:33 +0900

“3-bet은 단순한 레이즈가 아니다. 선전포고다.”

지금까지 우리는 오픈 레이즈와 콜, 그리고 포스트플랍 플레이를 다뤘습니다. 이제 한 단계 더 나아가 프리플랍 전쟁의 핵심인 3-bet과 4-bet 전략을 배워보겠습니다.

3-bet을 제대로 활용하면 더 많은 팟을 쟁취하고, 상대에게 어려운 결정을 강요할 수 있습니다. 반대로 3-bet에 제대로 대응하지 못하면 프리플랍에서부터 돈이 새어나갑니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

베팅 라운드 용어 정리

혼란을 피하기 위해 용어를 명확히 합시다.

용어	의미	예시
1-bet	블라인드 (강제 베팅)	BB가 1BB를 냄
2-bet	첫 번째 레이즈 (오픈)	UTG가 3BB로 레이즈
3-bet	두 번째 레이즈 (리레이즈)	BTN이 9BB로 리레이즈
4-bet	세 번째 레이즈	UTG가 24BB로 다시 레이즈
5-bet	네 번째 레이즈 (보통 올인)	BTN 올인

3-bet의 목적: 밸류, 블러프, 아이솔레이션

1. 밸류 3-bet

목적: 강한 핸드로 팟을 키워 더 많은 돈을 딸 준비

Texas Hold'em 가이드: #7. 리버 플레이 - 마지막 결정

Wed, 14 Jan 2026 11:15:02 +0900

“리버에서 모든 진실이 드러난다. 더 이상 숨을 곳은 없다.”

리버는 포커 핸드의 최종장입니다. 다섯 번째 커뮤니티 카드가 깔리고, 더 이상 나올 카드가 없습니다. 드로우의 희망도 없고, 역전의 기회도 없습니다. 지금 가진 핸드가 전부입니다.

리버에서의 결정은 순수하게 “이기고 있는가, 지고 있는가” 로 귀결됩니다. 이번 편에서는 리버에서 최선의 결정을 내리는 방법을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

리버의 특성

드로우가 사라진다

리버에서는 모든 드로우가 종결됩니다.

Texas Hold'em 가이드: #6. 턴 플레이 - 두 번째 배럴의 기술

Wed, 14 Jan 2026 11:14:55 +0900

“턴은 진실의 순간이다. 블러프인가, 밸류인가.”

플랍에서 C-bet을 했고, 상대가 콜했습니다. 이제 턴 카드가 깔리고, 당신은 중요한 결정 앞에 서 있습니다. 두 번째 배럴(Double Barrel) 을 쏠 것인가, 포기할 것인가?

턴은 포커에서 가장 복잡하고 중요한 스트릿입니다. 팟이 커지기 시작하고, 한 번의 실수가 스택의 상당 부분을 날릴 수 있습니다. 이번 편에서는 턴에서의 의사결정 프레임워크를 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

턴의 특수성: 팟이 커지고 SPR이 작아지는 지점

SPR (Stack-to-Pot Ratio)의 변화

SPR은 남은 스택을 현재 팟으로 나눈 값입니다. SPR이 낮을수록 올인 압박이 커집니다.

Texas Hold'em 가이드: #5. 플랍 플레이 (下) - 드로우와 메이드 핸드

Wed, 14 Jan 2026 11:14:48 +0900

“드로우는 가능성이고, 메이드 핸드는 현실이다. 둘 다 제대로 플레이해야 한다.”

플랍이 깔리면 당신의 핸드는 크게 두 가지 상태 중 하나입니다: 이미 완성된 메이드 핸드이거나, 아직 완성되지 않은 드로우입니다. 각각의 상황에서 어떻게 플레이해야 최대의 가치를 뽑거나 손실을 최소화할 수 있는지 알아보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

드로우의 세계

드로우의 종류

플러시 드로우 (Flush Draw)

같은 수트 4장, 1장 더 필요
아웃: 9개
플랍→리버 확률: ~35%

오픈엔드 스트레이트 드로우 (OESD)

Texas Hold'em 가이드: #4. 플랍 플레이 (上) - C-bet과 보드 텍스처

Wed, 14 Jan 2026 11:14:38 +0900

“플랍은 핸드의 운명이 결정되는 곳이다.”

프리플랍에서 좋은 결정을 내렸다면, 이제 진짜 포커가 시작됩니다. 플랍에서 5장의 커뮤니티 카드 중 3장이 공개되고, 당신의 핸드가 어떤 방향으로 갈지 대략적인 그림이 그려집니다.

이번 편에서는 플랍에서 가장 중요한 두 가지 개념인 보드 텍스처 읽기와 컨티뉴에이션 벳(C-bet) 에 대해 깊이 있게 다루겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

보드 텍스처란 무엇인가

보드 텍스처(Board Texture)는 플랍에 깔린 3장의 카드가 만들어내는 특성입니다. 같은 탑 페어라도 보드에 따라 가치가 완전히 달라집니다.

Texas Hold'em 가이드: #3. 팟 오즈와 임플라이드 오즈 - 콜의 수학

Tue, 13 Jan 2026 11:13:40 +0900

“포커는 수학 게임이다. 감으로 하면 감옥 간다.” - 포커 격언

포커에서 “콜할까, 폴드할까?“라는 질문에 답하려면 수학이 필요합니다. 직관이나 감으로도 플레이할 수 있지만, 장기적으로 수익을 내려면 팟 오즈(Pot Odds) 와 임플라이드 오즈(Implied Odds) 를 이해해야 합니다.

이번 편에서는 콜의 수학적 기초를 다지고, 이를 실전에 적용하는 방법을 배워보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

팟 오즈란 무엇인가

기본 개념

팟 오즈는 콜하기 위해 내야 하는 금액 대비 이길 경우 받을 수 있는 금액의 비율입니다.

Texas Hold'em 가이드: #2. 스타팅 핸드 - 프리플랍의 기술

Tue, 13 Jan 2026 11:13:31 +0900

“Fold pre.” - 인터넷 포커 밈이자 진지한 조언

포커에서 가장 많이 하는 결정은 무엇일까요? 바로 프리플랍에서 이 핸드를 플레이할 것인가, 폴드할 것인가입니다. 이 결정이 이후 모든 것의 시작점이 됩니다. 나쁜 핸드로 팟에 들어가면, 아무리 포스트플랍을 잘 플레이해도 손해를 줄이는 것이 최선입니다.

이번 편에서는 어떤 핸드를 플레이해야 하는지, 그리고 그 이유가 무엇인지 깊이 있게 살펴보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

핸드 선택의 기본 원리: 에퀴티 vs 플레이어빌리티

스타팅 핸드를 평가할 때 두 가지 핵심 요소가 있습니다.

Texas Hold'em 가이드: #1. 포지션 - 홀덤에서 가장 중요한 개념

Tue, 13 Jan 2026 11:13:22 +0900

“포지션이 핸드를 이긴다” - 포커 격언

Texas Hold’em을 처음 배울 때 대부분의 사람들은 핸드의 강도에 집중합니다. AA가 좋고, 72o가 나쁘다는 건 누구나 압니다. 하지만 중급 이상의 플레이어와 초보자를 가르는 가장 큰 차이는 포지션에 대한 이해입니다.

이 글에서는 왜 포지션이 홀덤에서 가장 중요한 개념인지, 그리고 이를 어떻게 활용해야 하는지 깊이 있게 다뤄보겠습니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

포지션이란 무엇인가

포지션은 단순히 “테이블에서 어디에 앉아 있는가"를 넘어서, 베팅 라운드에서 몇 번째로 행동하는가를 의미합니다.

Texas Hold'em 가이드: #0. Overview

Tue, 13 Jan 2026 11:13:14 +0900

Texas Hold’em (NLH) 가이드에 대한 전체 내용 요약입니다. 이후 총 20회에 걸쳐 다양한 지식과 팁을 제공할 예정입니다.

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1: 기초를 다시 본다 (3편)

#1. 포지션 - 홀덤에서 가장 중요한 개념

왜 버튼이 “가장 좋은 자리"인가: 정보의 비대칭성
얼리/미들/레이트 포지션별 플레이 철학
블라인드에서의 수비 전략
“포지션이 핸드를 이긴다"는 말의 진짜 의미
초보자가 포지션을 무시할 때 잃는 것들

#2. 스타팅 핸드 - 프리플랍의 기술

핸드 선택의 기본 원리: 에퀴티 vs 플레이어빌리티
포지션별 오픈 레인지 구성하기
프리미엄 핸드(AA, KK)부터 스펙 핸드(suited connectors)까지
림프의 유혹을 버려야 하는 이유
실전 프리플랍 차트 활용과 그 한계

#3. 팟 오즈와 임플라이드 오즈 - 콜의 수학

팟 오즈 계산법: 기초부터 확실하게
“2-4 룰"로 아웃 계산 빠르게 하기
임플라이드 오즈: 보이지 않는 가치를 계산하다
리버스 임플라이드 오즈: 드로우가 완성돼도 지는 상황
수학적 사고와 직관의 균형

Part 2: 포스트플랍의 세계 (4편)

#4. 플랍 플레이 (上) - C-bet과 보드 텍스처

보드 텍스처 분류: 드라이 vs 웻, 하이 vs 로우
C-bet의 목적: 밸류? 블러프? 아니면 둘 다?
언제 C-bet하고 언제 체크해야 하나
멀티웨이 팟에서의 C-bet 조정
상대의 C-bet에 대응하기: 콜, 레이즈, 폴드

#5. 플랍 플레이 (下) - 드로우와 메이드 핸드

플러시 드로우 플레이: 패시브 vs 어그레시브
오픈엔드 스트레이트 드로우의 가치
탑 페어의 함정: “좋은 핸드"와 “넛"의 차이
셋과 투 페어: 언제 슬로우플레이하고 언제 밸류벳하나
오버페어로 큰 팟을 만들 때의 위험

#6. 턴 플레이 - 두 번째 배럴의 기술

턴의 특수성: 팟이 커지고 SPR이 작아지는 지점
더블 배럴의 조건: 언제 계속 밀어붙이나
턴에서 포기해야 할 때를 아는 것
상대의 레인지가 턴에서 어떻게 변하는가
팟 컨트롤: 빅 핸드 없이 쇼다운 가기

#7. 리버 플레이 - 마지막 결정

리버 밸류벳 사이징: 최대 추출의 기술
씬 밸류벳: 마지날 핸드로 가치 뽑기
리버 블러프의 조건과 스토리텔링
블러프캐쳐로 콜할 때 고려할 것들
“모르면 체크” - 리버에서 살아남는 법

Part 3: 중급 전략 (5편)

#8. 3-bet과 4-bet 전략

3-bet의 목적: 밸류, 블러프, 아이솔레이션
포지션별 3-bet 레인지 구성하기
3-bet에 대응하기: 콜, 4-bet, 폴드 기준
라이트 4-bet과 올인 레인지
3-bet 팟의 포스트플랍 전략

#9. 핸드 리딩의 기초

프리플랍 액션으로 레인지 좁히기
플랍-턴-리버로 레인지 업데이트하기
상대가 “가질 수 없는” 핸드 찾기
베팅 사이징이 알려주는 정보
역방향 핸드 리딩: 내 핸드는 상대에게 어떻게 보이나

#10. 블러프의 기술

블러프의 종류: 퓨어 블러프 vs 세미블러프
블러프 빈도와 MDF(Minimum Defense Frequency)
좋은 블러프 스팟 찾기: 보드, 포지션, 히스토리
블로커를 활용한 블러프
오버블러프 vs 언더블러프: 당신은 어느 쪽인가

#11. 익스플로잇 전략 - 상대 유형별 조정

플레이어 유형 분류: TAG, LAG, 니트, 피쉬
타이트한 상대 익스플로잇하기
루즈한 상대 익스플로잇하기
어그레시브한 상대 다루기
HUD 스탯 읽는 법 (온라인)

#12. 멀티웨이 팟 전략 - 3명 이상일 때 달라지는 모든 것

멀티웨이 팟의 근본적 특성: 에퀴티 분배와 실현의 어려움
프리플랍: 멀티웨이에서 강해지는 핸드 vs 약해지는 핸드
포스트플랍 조정: C-bet 빈도 급감, 체크 레인지 확대
“샌드위치 효과” - 중간에 낀 플레이어의 고민
멀티웨이에서 블러프가 거의 불가능한 이유
넛 어드밴티지의 중요성 극대화

Part 4: 상황별 전략 (4편)

#13. 숏스택 전략 - 20-40BB 플레이의 특수성

숏스택의 정의와 왜 이 스택 깊이가 특별한가
SPR(Stack-to-Pot Ratio)의 이해와 활용
푸시/폴드 모드: 언제 올인 or 폴드만 해야 하나
숏스택 프리플랍 차트와 레인지 조정
숏스택으로 포스트플랍 플레이하기: 커밋 vs 폴드
의도적 숏스택 전략(SSS)의 장단점

#14. 딥스택 전략 - 100BB+ 플레이의 세계

딥스택이 게임을 바꾸는 방식: 임플라이드 오즈의 폭발
스펙 핸드의 가치 상승: suited connectors, small pairs
포지션의 중요성이 더욱 커지는 이유
딥스택 포스트플랍: 더 많은 스트릿, 더 복잡한 결정
팟 컨트롤의 기술: 100BB를 한 핸드에 잃지 않기
딥스택 블러프와 멀티 배럴 전략

#15. 헤즈업 플레이 - 1:1 대결의 기술

헤즈업이 다른 이유: 블라인드 구조와 포지션
헤즈업 레인지 대폭 확장: 거의 모든 핸드가 플레이 가능
어그레션의 중요성: 헤즈업에서 패시브는 죽음
상대 적응(Adaptation)의 핵심: 익스플로잇 사이클
헤즈업 포스트플랍: 더 얇은 밸류벳, 더 많은 블러프
SNG/토너먼트 헤즈업 vs 캐시게임 헤즈업

#16. 라이브 vs 온라인 - 플랫폼별 차이와 적응

게임 속도와 핸드 볼륨의 차이
라이브 텔(Tell) 읽기: 베팅 패턴, 타이밍, 물리적 신호
온라인 텔: 베팅 타이밍, 사이징 패턴, 자동 액션
플레이어 풀의 차이: 라이브가 일반적으로 더 소프트한 이유
멀티테이블링과 볼륨 플레이 (온라인)
라이브 게임 에티켓과 테이블 이미지 관리
뱅크롤 관리의 차이: 레이크, 팁, 이동 비용

Part 5: 고급 개념 (3편)

#17. GTO와 익스플로잇의 균형

GTO란 무엇인가: 착취 불가능한 전략
왜 GTO를 공부해야 하는가 (그리고 왜 맹신하면 안 되는가)
솔버 활용법: 무엇을 배우고 무엇을 버릴 것인가
GTO 기반 위에서 익스플로잇하기
낮은 스테이크에서 GTO가 필요한가?

#18. 토너먼트 전략 (上) - 캐시게임과 다른 점

ICM 기초: 칩 ≠ 돈
토너먼트 단계별 전략: 얼리/미들/레이트 스테이지
버블 플레이: 생존 vs 어큐뮬레이션
빅 스택 vs 숏 스택 다이내믹
앤티 구조가 플레이에 미치는 영향

#19. 토너먼트 전략 (下) - 파이널 테이블과 형식별 전략

파이널 테이블 다이내믹: 페이 점프와 ICM 압박
숏스택 푸시/폴드 차트와 실전 적용
MTT vs SNG vs 스핀앤고: 형식별 핵심 차이
위성 토너먼트(Satellite) 전략
딜 메이킹(Deal Making)의 기초

Part 6: 장기적 성장 (2편)

#20. 멘탈 게임과 장기적 성장

분산(Variance)의 이해: 실력과 결과의 괴리
틸트의 종류와 대처법
뱅크롤 관리: 스테이크 선택의 기준
공부하는 법: 핸드 리뷰, 코칭, 커뮤니티
포커를 장기적으로 즐기는 마인드셋

#21. 실전 핸드 리뷰 - 시리즈 총정리

핸드 리뷰 방법론: 어떻게 자신의 플레이를 분석할 것인가
프리플랍 실수 사례: 레인지 이탈, 포지션 무시
포스트플랍 실수 사례: 팟 컨트롤 실패, 밸류 미스
블러프 실수 사례: 스토리가 맞지 않는 블러프
폴드 실수 사례: 너무 쉽게 포기하거나 너무 집착하거나
시리즈 핵심 개념 총정리와 다음 단계

구조 설계 의도

파트	편수	핵심 목표
Part 1: 기초	3편	“알고 있다고 생각하는” 기초 개념을 제대로 정립. 포지션/핸드선택/수학 - 모든 것의 토대
Part 2: 포스트플랍	4편	스트릿별 의사결정 프레임워크. 각 스트릿의 고유한 특성과 전략을 깊이 있게
Part 3: 중급 전략	5편	상대와의 상호작용. 읽고, 블러프하고, 익스플로잇하고, 멀티웨이 상황 대응
Part 4: 상황별 전략	4편	스택 깊이, 플레이어 수, 플랫폼에 따른 전략 조정. 실전 적응력 강화
Part 5: 고급 개념	3편	GTO 이론과 토너먼트 특수 전략. 상위 레벨로의 도약
Part 6: 장기 성장	2편	멘탈 관리와 실전 핸드 분석. 지속 가능한 포커 라이프

시리즈 로드맵

[입문] ──────────────────────────────────────────────────────> [고급]

Part 1 Part 2 Part 3 Part 4 Part 5 Part 6
기초 개념 ─────> 스트릿별 ──────> 상대 읽기 ──> 상황 적응 ─────> 이론/MTT ──> 성장
(#1-3) 플레이 & 공격 (#13-16) (#17-19) (#20-21)
 (#4-7) (#8-12)

각 파트는 이전 파트의 개념을 기반으로 하며, 독자가 순서대로 읽으면 자연스럽게 실력이 쌓이도록 설계되었습니다.

9x9, 13x13, 19x19 바둑의 차이점 상세 분석

Mon, 13 Oct 2025 13:05:00 +0900

가이드 요청에 대한 gemini-2.5-pro 의 결과물입니다.

바둑은 바둑판의 크기에 따라 게임의 양상과 핵심 전략이 완전히 달라지는 독특한 특징을 가집니다. 핵심적인 차이를 한 문장으로 요약하자면 “바둑판이 커질수록 국지적인 전투(전술)의 중요성보다 전체적인 운영(전략)의 중요성이 기하급수적으로 커진다” 고 할 수 있습니다.

한눈에 보는 비교표

구분	9x9 바둑 (작은 전투)	13x13 바둑 (균형의 다리)	19x19 바둑 (대서사시)
게임의 본질	전술(수읽기) 중심의 단기전	전술과 초보적 전략의 조화	전략(운영) 중심의 장기전
평균 소요 시간	5분 ~ 15분	15분 ~ 30분	30분 ~ 수 시간
핵심 역량	정확한 수읽기 능력, 사활 감각	기본적인 행마, 공수의 균형 감각	대국관, 형세판단, 포석, 끝내기 등
첫 수의 가치	매우 큼 (중앙 ‘천원’이 강력)	큼 (주로 3-3, 4-4 등 귀 차지)	중요하지만, 전체 판에 미치는 영향은 적음
포석(초반) 단계	거의 없음 (두자마자 전투 시작)	간략하게 존재 (귀, 변 차지 후 바로 접전)	매우 길고 중요 (전체 판의 구상을 결정)
중반전의 양상	모든 수가 중앙 전투와 직결	귀와 변에서 시작된 전투가 중앙으로 확산	거대한 세력 다툼, 삭감, 침입 등 복잡함
끝내기 단계	매우 짧거나 거의 없음	어느 정도 중요하며, 승패에 영향	승패를 뒤집을 수 있을 만큼 매우 중요함
실수의 영향	치명적 (한 번의 실수로 즉시 패배 가능)	비교적 큼 (불리해지기 쉬움)	만회할 기회가 많음 (전략적 유연성)
추천 학습자	입문자, 수읽기 훈련이 필요한 중급자	입문자 졸업 후 초급자, 빠른 대국 선호자	바둑의 깊이를 배우려는 모든 학습자

1. 9x9 바둑 (속도와 수읽기의 세계)

9줄 바둑은 바둑의 핵심 규칙인 ‘돌의 사활’과 ‘따냄’을 배우기에 가장 이상적인 환경입니다. 바둑판이 좁아 모든 돌들이 서로의 영향권 안에 있기 때문에, 한 수 한 수가 즉각적인 전투로 이어집니다.

바둑 가이드: Pt.1. 바둑의 규칙과 예절, 돌 잡는 기술

Thu, 25 Sep 2025 15:52:10 +0900

이 글의 초안은 gemini-2.5-pro 로 작성되었고, 이후 Claude Opus 5 를 이용해 도해를 바둑판 그림으로 교체하고 내용을 보강했습니다.

서론

본 포스트는 바둑 입문의 첫 두 단계인 ‘바둑의 규칙과 예절’ 및 ‘돌 잡는 기술: 단수와 축’을 다룹니다. 바둑에 처음 입문하는 학습자가 가장 기본적인 원리를 명확하게 이해하고, 이를 통해 견고한 기반을 다질 수 있도록 하는 것을 목표로 합니다. 각 단계의 중요성을 설명하고, 학습 내용을 상세히 기술하며, 좌표를 붙인 바둑판 도해로 추상적인 개념을 구체화하여 설명합니다.

스타크래프트 II: 공허의 유산 - 프로토스 플레이 가이드

Wed, 24 Sep 2025 14:12:21 +0900

gemini-2.5-pro 에 연구 결과 요청한 결과물을 일부 수정했습니다.

1. 서론: 아이어를 위하여

본 포스트는 블리자드 엔터테인먼트의 실시간 전략 게임 스타크래프트 II: 공허의 유산을 플레이하는 유저들을 위한 프로토스 종족 심층 가이드입니다. 이 가이드의 목표는 프로토스라는 종족의 철학과 메커니즘을 깊이 있게 이해하고, 초보자부터 숙련자에 이르기까지 모든 수준의 플레이어가 실력을 한 단계 끌어올리는 데 필요한 지식과 전략을 체계적으로 제공하는 것입니다.[1]

프로토스는 고도로 발달한 기술력과 강력한 사이오닉 능력을 바탕으로 한 정예 종족입니다.[2, 3] 타 종족에 비해 소수의 유닛으로 구성되지만, 각 유닛의 강력한 능력치와 특수 기술을 활용하여 다수의 적을 압도하는 정교한 컨트롤의 묘미를 제공합니다. 강력한 후반 조합을 완성했을 때 전장을 지배하는 쾌감은 프로토스 플레이의 가장 큰 매력 중 하나입니다.[4, 5] 본 가이드를 통해 프로토스의 잠재력을 최대한 발휘하고 승리의 영광을 쟁취하는 길을 안내하고자 합니다.

스타크래프트 II: 공허의 유산 - 저그 플레이 가이드

Wed, 24 Sep 2025 13:24:10 +0900

gemini-2.5-pro 에 연구 결과 요청한 결과물을 일부 수정했습니다.

1. 서론: 군단의 정수

스타크래프트 II에서 저그는 단순한 종족이 아닌, 하나의 거대한 유기적 시스템입니다. 저그 플레이의 핵심 철학은 반응성(Reactivity), 확장(Expansion), 그리고 압도적인 생산력(Overwhelming Production) 이라는 세 가지 기둥 위에 세워져 있습니다.[1, 2, 3] 플레이어는 개별 유닛을 지휘하는 사령관이라기보다, 군단의 성장을 유도하고 외부 위협에 적응하도록 이끄는 ‘초월체’와 같은 역할을 수행해야 합니다.

저그 운영의 근본적인 난이도는 복잡한 유닛 컨트롤이 아닌, 불완전한 정보 속에서 내려야 하는 끊임없는 의사결정에 있습니다. 모든 생산의 기반이 되는 애벌레(Larva) 메커니즘은 플레이어에게 상시적인 딜레마를 안겨줍니다. 즉, 경제력(일벌레)을 강화할 것인가, 아니면 군사력(전투 유닛)을 확보할 것인가의 갈림길에 서게 됩니다. 테란이나 프로토스는 생산 건물과 일꾼 생산 건물이 분리되어 동시에 두 가지를 수행할 수 있지만, 저그는 애벌레라는 단일 자원을 공유합니다. 이는 일벌레에 투자한 애벌레 하나가 곧 전투 유닛 하나의 기회비용이 됨을 의미합니다. 따라서 저그 플레이어는 최소한의 정찰 정보에 기반하여 상대의 의도를 정확히 예측하고, 그에 맞춰 자원을 배분하는 고도의 위험 관리 능력을 요구받습니다. 과도한 일벌레 생산은 예측하지 못한 공격에 허무하게 무너지는 결과를 낳고, 섣부른 병력 생산은 상대의 경제력에 압도당하는 패배로 이어집니다.[1, 4]

스타크래프트 II: 공허의 유산 - 테란 플레이 가이드

Tue, 23 Sep 2025 15:36:20 +0900

gemini-2.5-pro 에 연구 결과 요청한 결과물을 일부 수정했습니다.

서론

본 포스트는 스타크래프트 II: 공허의 유산의 테란 종족을 플레이하고자 하는 모든 수준의 플레이어를 위한 포괄적인 가이드를 제공하는 것을 목적으로 합니다. 초보자를 위한 기본 개념부터 고급 플레이어를 위한 심층 전략까지, 테란 운영의 모든 측면을 체계적으로 분석하고 설명할 것입니다.

테란은 코프룰루 구역의 인간 세력으로, 뛰어난 적응력과 생존력을 바탕으로 한 유연한 전략 구사가 특징입니다.[1, 2] 프로토스의 발전된 기술이나 저그의 생물학적 강점 대신, 급조된 기술과 불굴의 정신력으로 척박한 우주 환경에 적응한 이 종족의 특성은 게임 내에서 다양한 유닛 조합과 전략적 유연성으로 나타납니다.[3] 본 포스트는 이러한 테란의 본질을 이해하고, 그 잠재력을 최대한 발휘할 수 있는 방법을 제시할 것입니다.

Game Guide for Sampyong Hi-Lo (a.k.a. PLS7: Pot Limit Sampyong - 7 or better)

Tue, 29 Jul 2025 13:46:52 +0900

Sampyong Hi-Lo (a.k.a. PLS7: Pot Limit Sampyong - 7 or better) is a new poker variant based on Pot-Limit Omaha Hi-Lo (PLO8), with modified rules to allow for a wider variety and more powerful hands to occur frequently.

1. Core Rules

Base Game: Pot-Limit Omaha Hi-Lo. Betting is limited to the pot size, and the pot is split between the highest (High) and lowest (Low) hands.
Hand Formation (Most Important Change):
- Each player receives 3 cards instead of 4. Five community cards are dealt on the board. (Total 8-card pool)
- Unlike Omaha’s ‘2 hole cards + 3 board cards’ rule, in Sampyong Hi-Lo, players can freely use any number (0-3) of their hole cards from the total 8-card pool to make the best 5-card High hand and Low hand.
Low Hand Rule: Adheres to the strengthened ‘7-or-better’ rule, which is stricter than standard Hi-Lo games. This means a Low hand must consist of five different cards ranked 7 or below to qualify. (The best possible Low hand is A, 2, 3, 4, 5)
Recommendation for 4 players or fewer: For 4 or fewer players, it is recommended to play Sampyong (PLS) focusing only on High hands, excluding the Low rule. In 2-3 player games, frequent Hi/Lo pot splits can make the game slow.

2. Additional Special Hands

These new special hands add more excitement to Sampyong Hi-Lo.

삼평 하이로우 (PLS7 - Pot Limit Sampyong 7 or better) 게임 가이드

Tue, 29 Jul 2025 13:46:52 +0900

삼평 하이로우(a.k.a. PLS7 : Pot Limit Sampyong - 7 or better)은 팟 리밋 오마하 하이-로우(PLO8)를 기반으로, 더 다양하고 강력한 핸드가 자주 나올 수 있도록 규칙을 변형한 새로운 방식의 포커 게임입니다.

1. 핵심 규칙

기본 게임: 팟 리밋 오마하 하이-로우 (Pot-Limit Omaha Hi-Lo). 베팅은 팟 크기만큼만 가능하며, 가장 높은 패(High)와 가장 낮은 패(Low)가 팟을 나누어 가집니다.
핸드 구성 방식 (가장 중요한 변경점):
- 각 플레이어는 4장이 아닌 3장의 카드를 받습니다. 보드에는 5장의 공통 카드가 깔립니다. (총 8장의 카드 풀)
- 오마하의 ‘핸드 2장 + 보드 3장’ 규칙과 달리, 삼평 하이로우에서는 총 8장의 카드 중 원하는 개수(0~3장)의 핸드 카드를 자유롭게 사용하여 최고의 5장짜리 하이(High) 핸드와 로우(Low) 핸드를 만듭니다.
로우 핸드 규칙: 하이-로우 게임의 표준 규칙보다 강화된 ‘7-or-better’ 를 따릅니다. 즉, 로우 핸드는 서로 다른 7 이하의 숫자 5장으로 구성되어야 성립됩니다. (가장 좋은 로우 핸드는 A, 2, 3, 4, 5)
플레이어가 4명 이하일 경우는 로우 룰을 제외하고 하이로만 겨루는 삼평(PLS)을 추천합니다. 2~3인 플레이에서 하이/로우 스플릿이 되는 경우가 자주 발생하면 게임이 루즈해질 수 있습니다.

2. 추가 특수 족보

삼평 하이로우의 재미를 더하는 새로운 특수 족보입니다.

번역글: King's Bounty 전략

Thu, 17 Jul 2025 10:49:03 +0900

원문: https://gamefaqs.gamespot.com/pc/577442-kings-bounty/faqs/7416 (Translated by Google Gemini)

이미지 출처: https://shot97retro.blogspot.com/2018/06/kings-bounty-in-depth-written-amiga.html

King’s Bounty 전략, (C) Chris Jones 2000

이름	KINGS BOUNTY
제작사	ELECTRONIC ARTS/NEW WORLD COMPUTING
장르	STRATEGY/RPG
연도	1990
난이도	EASY / NORMAL / HARD/ IMPOSSIBLE
플랫폼	SEGA MEGADRIVE(GENESIS) / PC DOS

1	기초
2	종족
3	유물
4	악당
5	일반 전술

1: 기초

시작: 게임을 시작할 때, 성 안의 모든 유닛은 잊고 캐릭터가 보호를 위해 얻을 수 있는 최대량의 파이크맨(Pikemen)만 생각하세요. 가장 가까운 마을로 가서 보트를 빌리세요. 이 보트를 타고 현재 대륙의 가장자리를 따라 이동하며 발견하는 모든 금을 농민들에게 주어 리더십으로 전환하세요. 가능한 한 빨리 다음 대륙으로 이동하려고 노력하세요.

Guide on philipjkim

Hugo 로 바둑판 도해 그리기 Part 2: 이미지 65장을 표기로 옮기기

들어가며

Hugo 로 바둑판 도해 그리기 Part 1: 왜 shortcode 였나

들어가며

바둑 가이드 Pt.2: 죽지 않는 법 — 잇기, 두 눈, 그리고 패

들어가며

렉시오 CPU 플레이어 만들기 Part 7: 코드 없이 보는 easy 봇과 hard 봇의 차이

이 글은 누구를 위한 것인가

달무티 vs 렉시오 Part 3: 인원, 운, 정치, 그리고 무엇을 살 것인가

1. 인원수에 따른 경험

달무티: 사람이 많을수록 살아난다

달무티 vs 렉시오 Part 2: 강한 패, 혁명, 그리고 점수

달무티 vs 렉시오 Part 1: 같은 클라이밍 게임, 다른 목적

사촌인데 닮지 않았다

에어컨이 있는 집에 제습기가 꼭 필요할까: 서울 13개월 온습도 데이터로 따져보기

들어가며

대부호부터 렉시오까지: 클라이밍 카드게임의 세계와 전략

손패를 먼저 비우는 자가 이긴다

Marp: Markdown으로 발표 슬라이드를 만들고 Git으로 관리하기

Marp란 무엇인가

HTTP REST(JSON) vs. gRPC(Protocol Buffers): 언제 무엇을 쓸까

넨도로이드 완전 가이드 Part 3: 입문자를 위한 실전 가이드

넨도로이드의 구조와 특징

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

들어가며

레시피 1: 수동 취소·타임아웃 관리 대신 context 신규 API (1.21)

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

들어가며

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

들어가며: 5년 동안 Go에 무슨 일이 있었나

게임 디자인과 랜덤성의 수학 Part 3: 게임이론과 시뮬레이션으로 밸런스를 검증하기

게임 디자인과 랜덤성의 수학 Part 2: 확률 분포로 드랍률·가챠·천장 설계하기

게임 디자인과 랜덤성의 수학 Part 1: 랜덤성은 왜 게임의 심장이자 지뢰밭인가

한여름 제철 스시 재료: 오마카세에서 만나는 고급 어종 6선

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 3: 무엇이, 어떻게 다른가

들어가며

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 2: 라이트노벨이 열어젖힌 이세계

들어가며

코믹스 원작 vs. 라이트노벨 원작 애니메이션 Part 1: 만화가 낳은 괴물들

들어가며: 원작이 만화냐 라노벨이냐, 그게 뭐가 중요한가요?

개발자를 위한 Discord 완전정복 Part 3: Discord를 원격 Control Plane으로

개발자를 위한 Discord 완전정복 Part 2: 공짜로 풀어준 대인배 기능들

개발자를 위한 Discord 완전정복 Part 1: 탄생, 성장, 그리고 결정적 순간들

훌라(Hula) 완전정복 Part 2: 전투훌라 실전 전략

훌라(Hula) 완전정복 Part 1: 유래부터 규칙, 전투훌라까지

MLB 매니아를 위한 KBO 입문 가이드 Part 3: 통산 기록과 KBO만의 "대첩" 밈

통산 기록 비교: 숫자의 스케일

MLB 매니아를 위한 KBO 입문 가이드 Part 2: 2024~2025 시즌으로 보는 두 리그의 흐름

2024 시즌: 두 리그 모두 우승팀이 압도적이었다

MLB 2024: 다저스 vs 양키스, 21세기 첫 클래식 매치업

MLB 매니아를 위한 KBO 입문 가이드 Part 1: 리그 구조와 룰, 문화의 차이

들어가며: 왜 지금 KBO인가

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

가상 프로젝트: gotodo

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 1: AGENTS.md 와 spec 문서 지형도

들어가며: README 한 장으로 안 되는 시대

Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계

Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬 — TDD, Systematic Debugging, Verification, Code Review

Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우 — Brainstorming부터 Subagent-driven Development까지

Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학

들어가며

봄부터 초여름 제철 스시 재료: 오마카세에서 만나는 고급 어종 7선

크로스플랫폼 To-Do 앱 만들기 Part 4: UI 다듬기와 빌드/배포

시리즈 목차

Part 3 회고

크로스플랫폼 To-Do 앱 만들기 Part 3: 상태 관리와 로컬 데이터 저장

들어가며

1. setState의 한계

크로스플랫폼 To-Do 앱 만들기 Part 2: Flutter 기초와 UI 구현

들어가며

크로스플랫폼 To-Do 앱 만들기 Part 1: 프레임워크 선택과 개발 환경 설정

시리즈 소개

Push Your Luck 게임 디자인 가이드 Part 2: 수학적 최적화와 게임 이론

수학적 프레임워크: 최적 중단 문제

기본 모델 정의

Push Your Luck 게임 디자인 가이드 Part 1: 메카닉 분석과 실제 사례

들어가며

Fantasy Baseball(MLB) 완전 가이드: 리그 형식부터 선수 운영 노하우까지

Fantasy Baseball이란?

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

가상 프로젝트: `gotodo`

예시 1: `A♠K♠Q♥J♣` (티어 2)