그러다 우연히 방문한 교보문고에서 아무런 이유 없이 이끌려 집어 들게 된 책이 바로 서울대학교 나민애 교수의 『책 읽고 글쓰기』였습니다. 노션 서재 데이터베이스에 가볍게 기록을 남기며, 이 책을 계기로 책을 읽고 글을 쓴다는 행위의 깊이를 다시 한번 고민해 보게 되었습니다.

노션에 기록해 둔 간단한 독서 메타데이터. 2026년 5월 23일부터 25일까지 사흘에 걸쳐 완독했고, 별점은 4점을 주었습니다.

• 책 제목 : 책 읽고 글쓰기 (서울대 나민애 교수의 몹시 친절한 서평 가이드)
• 저자 : 나민애
• 출판사 : 서울문화사
• 출판일 : 2020년 03월 30일

1. 독후감 vs 서평, 무엇이 다를까?

이 책을 읽기 전까지 저는 책을 읽고 쓰는 모든 종류의 글은 결국 ‘비슷한 범주’에 속하는 것이 아닐까 생각했습니다. 하지만 저자는 대학 내에서 진행하는 실제 ‘서평 특강’을 중계하듯, 이 둘의 개념을 아주 명료하게 정리해 줍니다.

• 독후감 (Book Report): 책을 읽고 난 뒤 떠오르는 나만의 ‘느낌과 감상(주관적 영역)’을 자유롭게 풀어내는 글. 그동안 우리가 학교나 일상에서 손쉽게 써오던 대부분의 글이 여기에 해당합니다.
• 서평 (Book Review): 책을 단순히 소개하는 데 그치지 않고, 객관적인 기준을 바탕으로 책을 ‘평가(비판적 영역)’하는 글. 감상보다는 논리적이고 객관적인 성격이 짙습니다.

이 정의를 직면하고 나니, 그동안 제가 써왔던 많은 글들이 서평이라기보다는 지극히 주관적인 감상문에 가까웠음을 깨닫게 되었습니다. 책의 가치와 의의를 짚어내는 ‘평가자’로서의 관점을 장착하는 것, 그것이 서평 쓰기의 첫걸음이었습니다.

2. 가장 인상 깊었던 대목: ‘서평 템플릿’의 힘

책을 읽으며 개인적으로 가장 흥미롭고 와닿았던 부분은 ‘한눈에 보는 블로그 서평의 전체 구조(템플릿)’였습니다.

책에서 제안하는 블로그 서평 제목의 구체적인 예시들.

서평을 어떻게 구성해야 할지 막막한 독자들을 위해 저자는 아주 명확한 구조적 가이드를 제공합니다.

[블로그 서평의 핵심 템플릿 구조]

1. 제목 (책 제목, 저자, 출판 연도 + 키워드)
2. 간략한 책 소개 (책의 핵심 정보와 주제 요약)
3. 전체의 의의 (이 책이 지닌 가치와 필요성)
4. 중요 대목 1, 2, 3 (기억해야 할 핵심 내용 요약 및 분석)
5. 나만의 해석과 평가 (책의 장단점 및 마무리 감상)

템플릿이 중요한 이유는 단순히 글을 쉽게 쓰기 위함만이 아닙니다. 글을 쓰는 사람과 읽는 사람 사이에 ‘약속된 구조적 정보’를 형성해 주기 때문입니다.

보고서를 작성할 때나 주관식 시험 답안을 기술할 때 일정한 형식을 갖추면 정보의 전달력이 비약적으로 상승하듯, 서평 또한 템플릿을 갖출 때 독자가 ‘아, 이 부분에서는 이런 맥락이 나오고 본문 요약은 여길 보면 되겠구나!’ 하고 직관적으로 정보를 흡수할 수 있게 됩니다.

저자는 이를 돕기 위해 다양한 실제 사례를 나란히 보여주며, 어떤 서평이 좋은 구성인지 혹은 어떤 점이 아쉬운지를 일대일 첨삭 지도하듯이 설명해 줍니다. 덕분에 서평을 처음 쓰는 초보자들도 글쓰기의 ‘안정적인 저점’을 확보할 수 있도록 이끌어 줍니다.

3. 이 책에 대한 비판적 평가 (서평의 서평)

책의 가르침에 따르면 좋은 서평에는 ‘느낀 점’뿐만 아니라 논리적인 ‘비판적 읽기’가 반드시 포함되어야 합니다. 그렇다면 나민애 교수의 이 책을 서평의 관점에서 비판적으로 본다면 어떨까요?

사실 실용서의 목적으로 바라보았을 때, 이 책에 대한 비판적인 요소를 굳이 끄집어내기는 어렵습니다.

왜냐하면 책을 덮고 난 뒤에 ‘나도 바로 서평을 한 편 써볼 수 있겠는데?’ 하는 자신감과 구체적인 방법론을 완벽하게 쥐어주었기 때문입니다. 자신이 알고 싶어 하는 정보를 친절하고 충분하게 제공하며 가이드라인 역할을 100% 해냈다는 점에서, 실용적인 튜토리얼북으로서 지녀야 할 제 기능을 아주 훌륭히 완수하고 있는 책입니다.

마무리하며

단순히 책을 읽고 머릿속으로만 간직하는 독서와, 나만의 논리로 구조를 세워 기록으로 남기는 서평 쓰기는 완전히 다른 차원의 공부임을 깨달았습니다.

글쓰기가 늘 어렵고 서평이라는 장르에 막막함을 느끼셨던 분들이라면, 서울대 나민애 교수의 친절한 템플릿과 안내를 따라 첫 한 줄을 시작해 보시는 것을 적극 추천해 드립니다. 저 역시 앞으로 제 블로그에 남길 도서 후기들은 이번에 배운 템플릿을 토대로 좀 더 완성도 높은 객관적인 ‘서평’으로 채워나가 보려 합니다.

처음에는 꽤 전형적인 수제 RAG(Retrieval-Augmented Generation) 구조였다. 문서를 직접 읽고, 적당한 크기로 나누고, 임베딩을 만들고, Vectorize에 넣고, 질문이 들어오면 관련 문서를 찾아 LLM에 넘기는 방식이다.

그 구조도 충분히 의미 있었다. 직접 만들어보니 RAG가 어떻게 움직이는지 몸으로 이해할 수 있었다. 하지만 운영 관점에서 보면 손이 많이 갔다.

• 문서 청킹 기준을 계속 조정해야 한다.
• 임베딩과 검색 로직을 직접 관리해야 한다.
• 검색 결과를 다시 프롬프트 문맥으로 조립해야 한다.
• 응답 품질이 흔들리면 어느 단계가 문제인지 계속 추적해야 한다.

그러던 중 Cloudflare가 제공하는 AI Search를 살펴보게 됐다. 문서를 넣고, 검색하고, 필요한 경우 챗봇 응답까지 이어가는 흐름을 Cloudflare 쪽에서 더 높은 수준의 기능으로 제공하고 있었다.

그래서 오늘은 기존 수제 RAG 기반 챗봇을 걷어내고, Cloudflare AI Search 기반 챗봇으로 옮겨봤다.

내가 직접 엮던 RAG 파이프라인을 Cloudflare AI Search 중심 구조로 단순화해봤다.

왜 갈아타고 싶었나

수제 RAG의 장점은 명확하다. 구조를 내가 통제할 수 있다. 어느 모델로 임베딩할지, 청크를 얼마나 크게 자를지, 검색 결과를 몇 개 가져올지, 프롬프트를 어떻게 만들지 전부 직접 정할 수 있다.

하지만 작은 개인 위키를 계속 키워가는 입장에서는 그 자유도가 곧 운영 부담이 되기도 한다.

내가 원하는 것은 검색 엔진 자체를 만드는 것이 아니라, 내 문서를 바탕으로 질문에 잘 답하는 위키 챗봇이다. 그렇다면 문서 인덱싱, 하이브리드 검색, 검색 결과 정렬 같은 기반 기능은 플랫폼에 맡기고, 나는 위키 경험을 다듬는 쪽에 집중하는 편이 낫다.

Cloudflare AI Search가 매력적으로 보였던 이유가 바로 이 지점이었다.

공식 문서 기준으로 AI Search는 자연어 질의로 관련 결과를 찾거나 AI 생성 응답을 받을 수 있는 검색 기능을 제공한다. REST API는 OpenAI 호환 messages 형식을 사용하고, 검색 API와 챗 completions API를 나눠 쓸 수 있다.

Items API로 문서 넣기

첫 번째 작업은 위키 문서를 AI Search에 넣는 것이었다.

기존에는 파이썬 스크립트에서 문서를 직접 청킹하고, 임베딩 API를 호출하고, Vectorize에 넣었다. 이제는 AI Search의 Items API에 문서를 넣는 방식으로 바꿨다.

예시는 이런 느낌이다. 실제 계정 ID나 토큰은 절대 코드에 직접 남기지 않고 환경변수로 다루는 것이 맞다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import os
import requests

account_id = os.environ["CLOUDFLARE_ACCOUNT_ID"]
api_token = os.environ["CLOUDFLARE_API_TOKEN"]
instance_id = "my-wiki-search"

url = (
    f"https://api.cloudflare.com/client/v4/accounts/{account_id}"
    f"/ai-search/instances/{instance_id}/items"
)

payload = {
    "key": "sample-doc",
    "text": "# 문서 제목\n\n위키 문서 본문...",
    "metadata": {
        "title": "문서 제목",
        "path": "/docs/sample-doc/"
    }
}

response = requests.put(
    url,
    headers={
        "Authorization": f"Bearer {api_token}",
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=30
)

response.raise_for_status()

이 방식의 장점은 단순하다. 문서를 검색 가능한 항목으로 넣는 책임을 AI Search 쪽에 맡길 수 있다. 수제 RAG에서 내가 직접 붙잡고 있던 많은 단계가 줄어든다.

바인딩 대신 REST API로 우회

처음에는 Workers 또는 Pages Functions에서 바인딩을 통해 AI Search를 호출하려고 했다.

Cloudflare 문서를 보면 ai_search 또는 ai_search_namespaces 바인딩을 설정해 런타임에서 env.AI_SEARCH 형태로 접근할 수 있다. 이 방식이 가장 깔끔해 보였다.

다만 실제 작업 중에는 베타 기능 특유의 불안정함과 설정 이슈가 있었다. 대시보드에서 바인딩을 추가하는 흐름이 매끄럽지 않았고, 당장 챗봇을 완성하는 데 시간이 더 걸릴 것 같았다.

그래서 방향을 바꿨다.

이번에는 Workers에서 Cloudflare AI Search REST API를 직접 호출하는 구조로 갔다. 바인딩보다 조금 더 노출적으로 보일 수는 있지만, HTTP 요청으로 동작을 확인할 수 있어서 디버깅은 오히려 쉬웠다.

인증 오류의 핵심은 Run 권한이었다

가장 시간을 많이 쓴 부분은 인증이었다.

토큰을 만들고, API를 호출했는데 검색 단계에서 계속 인증 오류가 났다. 이상한 점은 엔진이나 인스턴스 조회는 되는데, 실제 검색만 실패한다는 것이었다.

나중에 원인을 찾고 보니 권한이 부족했다.

Cloudflare AI Search REST API는 토큰에 AI Search:Edit와 AI Search:Run 권한이 필요하다. 문서를 넣고 설정을 바꾸는 권한과, 실제 검색 엔진을 실행하는 권한이 분리되어 있는 것이다.

이건 꽤 좋은 보안 모델이다. 다만 처음 만났을 때는 헷갈리기 쉽다.

정리하면 API 토큰에는 최소한 이런 식의 권한이 필요했다.

1
2
Account > AI Search:Edit
Account > AI Search:Run

Edit만 있으면 관리 작업 일부는 될 수 있지만, 검색 실행에서 막힐 수 있다. 나처럼 “조회는 되는데 검색만 안 된다”는 상황을 만나면 가장 먼저 Run 권한을 확인하는 게 좋다.

results가 아니라 chunks일 수 있다

인증을 해결하고 나니 다음 문제는 응답 구조였다.

로컬 테스트에서는 결과 배열을 results라고 생각하고 코드를 짰다. 그런데 실제 Workers 환경에서 받은 응답은 chunks 배열 쪽을 봐야 했다. 메타데이터도 내가 예상한 위치와 다르게 한 겹 안쪽에 들어 있었다.

그래서 파싱 코드를 조금 더 방어적으로 바꿨다.

1
2
3
4
5
6
7
8
9
10
11
12
const searchResults =
  searchData.result?.chunks ??
  searchData.result?.results ??
  [];

const contextText = searchResults.map((result) => {
  const metadata = result.item?.metadata ?? result.metadata ?? {};
  const title = metadata.title ?? "문서";
  const text = result.text ?? result.content?.text ?? "";

  return `[출처: ${title}]\n${text}`;
}).join("\n\n");

베타 API나 빠르게 바뀌는 플랫폼 기능을 붙일 때는 이런 안전망이 도움이 된다. 응답 구조 하나가 달라졌다고 챗봇 전체가 “문서를 찾을 수 없다”고 말하면, 사용자 입장에서는 기능이 아예 죽은 것처럼 보이기 때문이다.

직접 관리하던 RAG 단계가 줄어드는 대신, 권한과 응답 구조를 정확히 이해하는 일이 중요해졌다.

검색 결과 수 제한으로 LLM 과식을 막기

마지막으로 잡은 문제는 문맥 길이였다.

AI Search의 검색 품질이 좋아지니 오히려 너무 많은 후보 문서가 들어왔다. 관련 청크를 많이 가져오는 것은 검색 관점에서는 좋아 보이지만, 그걸 전부 LLM 프롬프트에 넣으면 문제가 생긴다.

문맥이 길어지면 응답이 느려지고, 비용이 늘고, 모델이 핵심 문서를 놓치기도 한다. 심하면 답변 생성이 비어 보이거나 품질이 급격히 흔들릴 수 있다.

그래서 검색 단계에서 상위 결과 수를 제한했다. 예전 RAG 코드에서 말하던 topK 조정과 같은 목적이다. 최신 AI Search API 기준으로는 검색 옵션의 max_num_results 같은 값을 통해 가져올 결과 수를 줄이는 방식으로 이해하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const response = await fetch(searchUrl, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${apiToken}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    messages: [
      { role: "user", content: query }
    ],
    ai_search_options: {
      retrieval: {
        max_num_results: 3
      }
    }
  })
});

핵심은 단순하다. RAG 챗봇은 많이 찾는 것보다 답변에 쓸 만큼만 정확히 찾는 것이 중요하다.

이번에는 상위 3개 정도로 제한하니 응답이 훨씬 안정적으로 돌아왔다. 위키 챗봇 입장에서는 관련 문서 50개를 억지로 읽는 것보다, 가장 관련 있는 문서 몇 개를 제대로 읽고 답하는 편이 낫다.

바뀐 뒤의 느낌

전환하고 나니 구조가 꽤 가벼워졌다.

예전에는 내가 직접 붙들고 있던 부분이 많았다.

• 문서 청킹
• 임베딩 생성
• 벡터 저장
• 벡터 검색
• 검색 결과 조립
• LLM 프롬프트 구성

AI Search로 옮기면서 이 중 상당 부분을 플랫폼 기능에 맡길 수 있게 됐다. 물론 완전히 신경 쓸 일이 사라진 것은 아니다. API 권한, 응답 포맷, 검색 결과 개수, 모델 문맥 길이는 여전히 직접 보고 조정해야 한다.

그래도 방향은 분명하다.

내가 만들고 싶은 것은 검색 엔진 연구 프로젝트가 아니라, 계속 쓰고 싶은 개인 지식관리 위키다. 그런 관점에서 Cloudflare AI Search는 수제 RAG의 많은 부담을 줄여주는 좋은 선택지로 보인다.

오늘의 교훈

이번 전환에서 얻은 교훈은 세 가지다.

1. AI Search REST API 토큰에는 Edit와 Run 권한을 모두 넣자.
2. 응답 배열이 results인지 chunks인지 방어적으로 처리하자.
3. LLM에 넘기는 검색 결과는 max_num_results처럼 결과 수 제한 옵션으로 줄이자.

그리고 하나 더.

베타 기능은 문서를 읽는 시간보다 직접 부딪혀 보는 시간이 더 길 수 있다. 그래도 한 번 뚫고 나면 얻는 것이 있다. 수제 RAG로 구조를 이해했고, AI Search로 운영 부담을 줄였다. 두 단계를 모두 거치니 이제 내가 어떤 부분을 직접 만들고, 어떤 부분을 플랫폼에 맡겨야 하는지 감이 더 선명해졌다.

앞으로 이 위키는 단순히 “검색되는 문서 모음”이 아니라, 내가 쌓은 문서를 바탕으로 답하고 정리해주는 LLM 기반 지식관리 도구에 더 가까워질 것 같다.

참고한 공식 문서

• Cloudflare AI Search REST API
• Cloudflare AI Search Items
• Cloudflare AI Search Namespaces
• Cloudflare AI Search API Reference

처음에는 단순했다. 흩어진 문서를 MkDocs로 정리하고, GitHub와 연동해서 변경 이력을 남기는 정도면 충분하다고 생각했다. 문서를 마크다운으로 쓰고, 정적 사이트로 배포하고, 필요할 때 검색해서 보는 구조다. 이 정도만 해도 개인 지식관리 도구로는 꽤 쓸 만했다.

그런데 문서가 쌓이기 시작하니 욕심이 생겼다.

내가 문서를 찾아 읽는 위키가 아니라, 위키가 내 문서를 이해하고 다시 설명해주는 구조를 만들 수 있지 않을까?

오늘은 그 방향으로 꽤 큰 진전을 만들었다. Google Antigravity의 Gemini 3 Flash 모델과 함께 구조를 잡고 구현을 이어가면서, 정적인 MkDocs 위키를 Cloudflare 기반의 서버리스 AI 위키로 확장해봤다.

정적인 문서 묶음이 아니라, 질문하고 학습시키는 개인 지식 베이스를 만들고 싶었다.

처음 출발은 MkDocs였다

MkDocs는 문서형 위키를 만들기에 부담이 적다. 마크다운으로 문서를 작성하고, 폴더 구조만 잘 잡으면 그대로 읽기 좋은 사이트가 된다.

처음에는 이 장점에 집중했다.

• 문서를 마크다운으로 정리한다.
• GitHub에 올려 변경 이력을 남긴다.
• MkDocs로 정적 사이트를 만든다.
• 필요할 때 검색하고 찾아본다.

여기까지는 흔히 말하는 문서화 작업이다. 하지만 내가 만들고 싶었던 것은 단순한 문서 저장소에서 한 걸음 더 나간 형태였다.

문서가 늘어나면 사람은 두 가지 문제를 만난다. 첫째, 어디에 무엇이 있는지 기억하기 어렵다. 둘째, 검색으로 문서를 찾더라도 다시 읽고 해석하는 시간이 든다.

그래서 위키 안에 AI 기능을 넣어보기로 했다.

Cloudflare Pages에서 가능성을 봤다

처음 Cloudflare Pages를 볼 때는 정적 사이트 배포 서비스라는 인상이 강했다. MkDocs 결과물을 올리기에는 딱 좋지만, 그 이상을 하려면 별도 서버가 필요하지 않을까 싶었다.

그런데 살펴보니 Cloudflare 생태계 안에서 생각보다 많은 것을 할 수 있었다.

• Pages로 정적 위키를 배포한다.
• Pages Functions 또는 Workers로 서버리스 API를 붙인다.
• Workers AI로 LLM 추론을 호출한다.
• Vectorize로 문서 임베딩을 저장하고 검색한다.
• D1으로 학습 상태, 피드백, 메타데이터를 저장한다.
• AI Gateway로 요청을 관찰하고 캐싱한다.

즉, 별도의 서버를 직접 띄우지 않아도 정적 문서 사이트 위에 AI 기능을 얹을 수 있었다. 특히 무료 한도 안에서 실험을 시작할 수 있다는 점이 좋았다. 개인 위키처럼 작게 시작하는 프로젝트에는 이 진입 장벽이 꽤 중요하다.

단순 챗봇이 아니라 위키에 붙은 LLM

이번 작업에서 좋았던 점은 AI를 별도의 챗봇으로만 보지 않았다는 것이다.

보통 LLM 기능을 붙인다고 하면 오른쪽 아래에 채팅창을 하나 만드는 장면을 먼저 떠올린다. 물론 그것도 유용하다. 하지만 위키에 붙은 LLM은 조금 다르게 설계할 수 있다.

예를 들면 이런 기능이다.

• 문서 상단에서 AI가 핵심 내용을 3줄로 요약한다.
• 사용자가 특정 문서를 “학습 완료” 상태로 만들 수 있다.
• 학습된 문서는 벡터 검색 대상이 된다.
• 질문이 들어오면 관련 문서를 먼저 찾고, 그 문맥을 바탕으로 답한다.
• 도전과제처럼 문서 정리 진행률을 보여줘서 계속 정리하고 싶게 만든다.

이렇게 만들면 AI는 그냥 대화 상대가 아니라, 위키 안에서 문서의 맥락을 이어주는 기능이 된다. 내가 쌓아둔 문서를 더 잘 쓰게 해주는 인터페이스가 되는 셈이다.

MkDocs 위키에 Cloudflare의 서버리스 기능을 붙이면 RAG 기반 지식관리 도구로 확장할 수 있다.

RAG까지 구현해보니 감이 왔다

오늘 특히 인상적이었던 부분은 RAG 처리였다.

문서를 그대로 LLM에 모두 넣는 방식은 오래 가지 못한다. 문서가 늘어나면 비용도 커지고, 응답도 느려지고, 모델이 어느 문서를 참고해야 하는지도 흐려진다.

그래서 문서를 임베딩하고, 질문이 들어오면 관련 문서 조각을 먼저 찾고, 그 결과를 LLM에 넘기는 구조가 필요하다.

이번에는 Cloudflare Vectorize를 벡터 저장소로 두고, Workers AI의 Llama 3.1 8B 모델을 활용해 답변을 생성하는 흐름을 만들었다. Gemini 3 Flash는 구현을 함께 설계하고 코드를 다듬는 조력자 역할을 했다. 예상보다 충분히 빠르게 구조를 잡을 수 있었다.

내가 체감한 핵심 흐름은 이렇다.

1. MkDocs 문서를 읽는다.
2. 문서 내용을 적절한 단위로 나눈다.
3. 임베딩 모델로 벡터를 만든다.
4. Vectorize에 저장한다.
5. 질문이 들어오면 관련 벡터를 검색한다.
6. 검색된 문맥을 LLM에 넘겨 답변을 만든다.

이 흐름이 붙는 순간 위키는 단순 검색 페이지가 아니라 “내 문서를 근거로 답하는 시스템”에 가까워진다.

도전과제를 넣은 이유

이번 위키에는 도전과제도 넣어두었다.

문서 10개, 30개, 50개처럼 정리 목표를 보이게 하고, 특정 주제 문서를 채우면 달성 상태가 표시되도록 했다. 겉으로 보면 장난스러운 기능처럼 보일 수도 있지만, 지식관리에서는 이런 장치가 꽤 중요하다.

문서 정리는 늘 해야 한다는 것을 알지만, 막상 하려면 재미가 없다. 그래서 진행률이 보이고, 달성 상태가 남고, “조금 더 채워볼까?”라는 마음이 생기게 만드는 것이 필요하다.

LLM Wiki는 결국 기술만의 문제가 아니다. 사람이 계속 쓰게 만드는 구조가 있어야 한다.

오늘의 가장 큰 발견

오늘의 가장 큰 발견은 Cloudflare가 단순한 정적 사이트 배포 플랫폼으로만 보이지 않기 시작했다는 점이다.

Pages로 배포하고, Functions로 API를 만들고, Workers AI로 모델을 호출하고, Vectorize와 D1을 붙이면 작은 규모의 AI 애플리케이션을 꽤 빠르게 만들 수 있다. 특히 개인 프로젝트나 내부 지식관리 실험처럼 시작 규모가 작은 작업에는 이 구성이 잘 맞는다.

예전 같으면 이런 기능을 만들기 위해 서버를 띄우고, 데이터베이스를 만들고, 벡터 DB를 따로 붙이고, 모델 API를 연결하고, 배포 파이프라인을 챙겨야 했다. 지금은 그 많은 요소를 하나의 플랫폼 안에서 실험해볼 수 있다.

물론 아직 갈 길은 있다. PDF나 이미지까지 학습시키는 문제, 답변 품질을 평가하는 피드백 시스템, 문서 변경 시 자동 재학습하는 구조도 더 다듬어야 한다.

그래도 오늘 만든 결과만으로도 방향은 분명해졌다.

앞으로 계속 만들고 싶은 것

나는 앞으로도 이 개인 위키를 계속 키워가려고 한다.

목표는 거창한 범용 챗봇이 아니다. 내가 정리한 문서를 더 잘 찾고, 더 빨리 이해하고, 필요한 순간에 다시 꺼내 쓸 수 있는 지식관리 도구를 만드는 것이다.

LLM은 꼭 채팅창 안에만 있을 필요가 없다. 문서 위키 안에 들어가면, 요약자가 되고, 검색 도우미가 되고, 학습 상태를 관리하는 조력자가 되고, 내가 쌓아둔 지식의 연결선을 다시 그려주는 도구가 될 수 있다.

오늘 작업을 해보니 이런 생각이 들었다.

LLM Wiki는 생각보다 해볼 만하다. 그리고 작게 시작해도 충분히 재미있다.

정적 문서 사이트로 시작해서, AI 요약과 RAG 답변까지 붙여보는 과정은 꽤 좋은 실험이었다. 앞으로 이 위키가 단순한 문서 모음이 아니라, 내가 계속 함께 키워가는 개인 지식 베이스가 되었으면 한다.

참고한 공식 문서

• Cloudflare Pages Functions
• Cloudflare Workers AI bindings
• Cloudflare Vectorize
• Cloudflare D1
• Cloudflare AI Gateway

주소도 바뀌었다.

• 기존 주소: https://kerogrammer.github.io
• 새 주소: https://kerogrammer.pages.dev

겉으로 보기에는 단순히 호스팅 위치만 바꾼 것처럼 보이지만, 내 입장에서는 꽤 중요한 운영 방식의 변화였다. 핵심은 이것이다.

블로그 소스는 계속 GitHub에서 관리하되, 저장소는 private로 돌리고, 실제 배포된 결과물만 Cloudflare Pages에 공개한다.

소스 저장소와 공개 사이트를 분리하고 싶었다.

왜 GitHub Pages에서 옮겼나

GitHub Pages는 정말 편하다. 저장소 이름을 username.github.io로 만들고, Jekyll 블로그를 올리면 거의 바로 웹사이트가 된다. 나도 그 편리함 때문에 지금까지 GitHub Pages를 잘 써왔다.

그런데 블로그를 계속 운영하다 보니 한 가지가 걸렸다.

소스 저장소가 public이어야 한다는 점이다.

물론 공개 블로그니까 최종 HTML, CSS, 이미지, 글은 누구나 보는 것이 맞다. 하지만 저장소에는 최종 결과물 말고도 운영 과정의 흔적이 남는다. 예를 들면 이런 것들이다.

• 글 초안과 작성 중인 파일
• 자동화 워크플로우
• 블로그 운영 규칙과 실험 흔적
• 아직 정리되지 않은 작업 파일
• 배포 전 구조와 내부 관리 방식

블로그를 공개하는 것과, 블로그를 만드는 과정 전체를 공개하는 것은 조금 다르다.

나는 글은 공개하고 싶지만, 운영 과정과 소스 관리 방식까지 항상 공개해야 한다고 생각하지는 않는다. 그래서 이번에 방향을 바꿨다.

목표

이번 이전의 목표는 분명했다.

1. 소스 관리는 계속 GitHub에서 한다.
2. GitHub 저장소는 private로 바꾼다.
3. Cloudflare Pages가 private 저장소를 읽어서 빌드한다.
4. 방문자는 Cloudflare에 배포된 정적 결과물만 본다.
5. 검색엔진에는 새 주소와 sitemap을 다시 알려준다.

정리하면, GitHub는 작업 공간이고 Cloudflare Pages는 공개 무대가 되는 구조다.

Cloudflare Pages 프로젝트 만들기

Cloudflare에서 Pages 프로젝트 이름은 kerogrammer로 만들었다. 그래서 최종 주소는 아래처럼 정해졌다.

1
https://kerogrammer.pages.dev

이 블로그는 Jekyll 기반이라 Cloudflare Pages의 빌드 설정은 이렇게 잡았다.

1
2
3
4
Production branch: main
Framework preset: Jekyll
Build command: bundle exec jekyll build
Build output directory: _site

환경변수는 아래처럼 넣었다.

1
2
3
JEKYLL_ENV=production
RUBY_VERSION=3.4.8
BUNDLE_WITHOUT=development:test

처음에는 jekyll build를 쓸지 bundle exec jekyll build를 쓸지 고민했다. Cloudflare 안내에서는 jekyll build가 추천처럼 보이기도 했지만, 이 저장소는 Gemfile과 Gemfile.lock으로 Jekyll과 테마 버전을 관리하고 있다.

그래서 저장소에 잠긴 gem 조합을 그대로 쓰도록 bundle exec jekyll build를 선택했다.

중간에 만난 빌드 오류

한 번에 끝나지는 않았다.

처음 배포에서는 Ruby 설치와 gem 설치까지는 잘 됐는데, 실제 Jekyll 빌드에서 html-proofer 관련 오류가 났다.

원인은 간단했다.

Cloudflare가 의존성을 설치할 때 development와 test 그룹을 제외했는데, bundle exec jekyll build 실행 시점에서는 그 제외 설정을 제대로 이어받지 못했다. html-proofer는 배포용이 아니라 테스트용 gem인데, Bundler가 Gemfile.lock을 보면서 이 gem을 찾다가 실패한 것이다.

해결은 BUNDLE_WITHOUT 환경변수를 명시하는 것이었다.

1
BUNDLE_WITHOUT=development:test

이 값을 넣고 다시 배포하니 Jekyll 빌드가 정상적으로 진행됐다.

실제로는 몇 번 되돌아가며 설정을 고쳤지만, 큰 흐름은 이렇다.

블로그 설정도 새 주소로 변경

Cloudflare Pages 배포가 된 것만으로 끝은 아니었다.

Jekyll 블로그 안에는 사이트의 공식 URL이 들어간다. 이 값은 canonical URL, sitemap, feed, SEO 메타데이터에 영향을 준다. 그래서 _config.yml의 url 값을 새 주소로 바꿨다.

1
url: 'https://kerogrammer.pages.dev'

README 안에 있던 블로그 링크도 새 주소로 바꿨다.

그리고 기존 GitHub Pages 배포 워크플로우는 더 이상 필요하지 않으므로 비활성화했다. Cloudflare Pages가 GitHub 저장소를 보고 직접 빌드하기 때문에, GitHub Actions에서 Pages 배포를 또 할 이유가 없어졌다.

SEO는 다시 등록했다

주소가 바뀌면 검색엔진에도 새 주소를 알려야 한다.

Google Search Console에서는 처음에 도메인 소유권 확인 화면이 나왔다. 그런데 kerogrammer.pages.dev는 내가 직접 소유한 루트 도메인이 아니다. Cloudflare가 제공하는 pages.dev의 하위 주소라서 DNS TXT 레코드를 직접 넣을 수 없다.

그래서 도메인 속성이 아니라 URL 접두어 속성으로 등록했다.

1
https://kerogrammer.pages.dev/

Google Analytics 연결로 소유권 확인이 완료됐고, 그 다음 sitemap을 제출했다.

1
https://kerogrammer.pages.dev/sitemap.xml

robots.txt도 확인했다.

1
https://kerogrammer.pages.dev/robots.txt

둘 다 정상적으로 열렸으니, 검색엔진이 새 주소를 읽어갈 기본 준비는 끝난 셈이다.

GitHub 저장소를 private로 바꾸다

마지막으로 GitHub 저장소를 private로 바꿨다.

이후 https://kerogrammer.github.io/에 접속해보니 404가 나왔다. GitHub Pages 쪽 공개 사이트는 내려갔고, 저장소 소스도 더 이상 외부에서 볼 수 없는 상태가 됐다.

이제 방문자가 보는 블로그는 Cloudflare Pages에 배포된 결과물이다. 반면 글을 작성하고, 이미지를 추가하고, 설정을 고치는 실제 작업 공간은 private GitHub 저장소 안에 남는다.

내가 원했던 구조가 정확히 이거였다.

옮겨보니 느낀 점

이번 이전은 거창한 인프라 작업은 아니었다. 하지만 개인 블로그 운영 방식에서는 꽤 의미 있는 변화였다.

GitHub Pages는 시작하기 좋고 단순하다. 특히 공개 저장소 기반의 기술 블로그라면 여전히 좋은 선택이다.

다만 시간이 지나면서 블로그가 단순한 결과물 저장소가 아니라, 글쓰기 실험과 자동화, 운영 규칙이 섞인 작업 공간이 되기 시작했다. 그러면 소스 저장소 전체를 public으로 유지하는 것이 조금 부담스러워질 수 있다.

Cloudflare Pages로 옮기면서 이 경계가 정리됐다.

• 공개할 것: 완성된 블로그
• 숨길 것: 작업 과정과 소스 저장소
• 계속 유지할 것: GitHub 기반 소스 관리
• 새로 맡길 것: Cloudflare Pages 배포

결국 이번 이전은 호스팅 서비스를 바꾼 일이기도 하지만, 더 정확히는 블로그의 공개 범위를 다시 정한 일이었다.

앞으로도 글은 계속 공개하되, 만드는 과정은 조금 더 편하게 다룰 수 있을 것 같다.

지난 시즌 28의 씁쓸했던 마무리와 아쉬움을 뒤로하고, 드디어 듄 임페리움 소규모 전투 시즌 29가 새롭게 막을 올렸습니다. 다시 게임 1로 돌아가 첫 단추를 꿰는 마음으로 참전하였습니다.

🎲 게임 1: 독특한 모디파이어와 접합 보너스

시즌 29의 첫 번째 매치는 독특한 규칙과 강력한 카드 점수 버프의 조합으로 이루어져 있었습니다.

이번 게임의 핵심은 두 가지였습니다. 첫째는 덱을 무겁게 만들더라도 버프된 ‘스파이스는 흘러야 한다’ 카드를 경쟁적으로 선점하는 것, 둘째는 틀레이락스 연구를 적극적으로 활용해 카드를 계속해서 접합 처리하여 순위표 점수를 복사하는 것이었습니다.

👑 지도자 선택: 안정감의 헬레나 리체스

이번 대결의 전장은 변수가 가득한 만큼, 덱 빌딩을 유연하게 조율할 수 있는 안정적인 지도자인 “헬레나 리체스”를 선택했습니다.

이번 판에서 제가 상대해야 할 AI 지도자들은 아래와 같이 호전적이고 견제가 까다로운 라인업이었습니다.

• 폴 아트레이드 (Paul Atreides)
• 멤non 소르발드 백작 (Count Memnon Thorvald)
• 하코넨 남작 (Baron Harkonnen)

특히 하코넨 남작과 폴 아트레이드의 몰아치는 전투력 공세를 버텨내면서, 제 페이스를 잃지 않고 점수를 쌓아가는 것이 관건이었습니다.

⚔ 게임 진행: 팽팽한 견제와 극적인 승리

게임 초반부터 AI들은 공격적으로 병력을 모으며 영토 분쟁과 물량 공세를 펼쳤습니다. 저는 헬레나 리체스의 인장 능력을 극대화하여 임페리움 열의 고급 카드들을 안전하게 선점하였고, 동시에 틀레이락스 기술 카드를 모아 ‘접합(Graft)’ 콤보를 차근차근 쌓아 나갔습니다.

전투력 싸움에서는 하코넨 남작의 막강한 물량에 다소 밀리기도 했지만, 중요 길목에서 콤보 카드를 적절하게 터트려 주며 승점을 지켜냈습니다. 특히 게임 후반부에 ‘스파이스는 흘러야 한다’ 카드를 획득하며 승점 격차를 좁혔고, 결국 마지막 라운드까지 살얼음판 승부를 이어갔습니다.

🏆 최종 결과: 스파이스 우위로 거둔 극적인 1위!

모든 라운드가 끝난 뒤 최종 승점은 동률을 기록했지만, 듄의 가장 원초적인 자원인 스파이스 보유량 우위를 통해 극적으로 1위를 쟁취해 낼 수 있었습니다!

이번 판의 순위표 보너스 점수(Skirmish Points) 결산은 아래와 같았습니다.

최종적으로 소규모 전투 순위표 점수 27점을 획득하였습니다.

이 활약을 바탕으로 시즌 29 첫 게임을 전체 129위라는 아주 나쁘지 않은 랭킹으로 상쾌하게 출발하게 되었습니다.

📈 게임 소감 및 앞으로의 목표

하지만 조급해하지 않고 실버 등급 수성만으로도 저에게는 충분히 값진 목표라고 생각합니다. 시작이 좋은 만큼 남은 시즌 29의 매치들도 차근차근 제 페이스를 유지하며 즐겨보겠습니다.

다음 게임 2 후기로 찾아오겠습니다. 우주는 넓고, 스파이스는 계속 흘러야 하니까요! 🏜️

처음에는 900등대까지 밀리기도 했고, 중반에는 400~500등대에서 오르내렸고, 후반에는 300등대까지 치고 올라갔다. 마지막 게임 10에서 크게 미끄러지면서 아쉬움도 있었지만, 그래도 최종적으로는 388등으로 시즌을 마무리했다.

한 가지 의아했던 점은 업로드한 결과 이미지가 왜인지 시즌 29 결과처럼 표시되어 있었다는 것이다. 아마 시즌 28 정산 이후 다음 시즌 화면으로 넘어가는 과정에서 UI가 그렇게 보였던 것 같은데, 어쨌든 내가 정리하고 싶은 것은 명확하다. 이번 글은 시즌 28 전체 회고다.

게임 1부터 게임 10까지, 각 판에서 어떤 선택을 했고, 어떤 흐름이 있었고, 무엇이 아쉬웠는지를 한 번에 정리해 본다.

시즌 28 최종 결과

• 최종 순위: 388등
• 최종 누적 점수: 234점
• 총 게임 수: 10게임
• 핵심 지도자: 헬레나 리체스
• 시즌 최고 단일 점수: 게임 8, 44점
• 가장 아쉬운 게임: 게임 10
• 가장 짜릿했던 게임: 게임 3, 게임 7, 게임 9

이번 시즌을 한 줄로 정리하면 이렇다.

초반에는 흔들렸고, 중반에는 감을 잡았고, 후반에는 폭발했지만, 마지막에는 다시 듄답게 좌절했다.

시즌 28 점수와 순위 변화

이번 시즌의 흐름은 숫자로 보면 더 선명하다. 게임 2 종료 후에는 930등까지 밀렸지만, 이후 꾸준히 회복했고 게임 9 종료 기준으로는 332등까지 올라갔다. 다만 마지막 게임 10 이후 최종 정산에서 388등으로 마무리되었다.

게임별 획득 점수만 보면 게임 8의 44점이 압도적인 하이라이트다. 반대로 게임 2의 6점과 게임 10의 15점은 시즌 전체 순위를 끌어올리는 데 아쉬운 구간이었다.

순위 그래프는 위로 갈수록 좋은 순위가 되도록 표현했다. 게임 2에서 바닥을 찍은 뒤 게임 3부터 반등했고, 게임 8과 게임 9에서 가장 좋은 흐름을 만들었다. 마지막 게임 직후 기록은 367등이었지만, 최종 정산 기준으로는 388등으로 확정된 것으로 보인다.

※ 게임 6의 경우 기존 포스팅에는 게임 점수 28점과 누적 119점이 함께 기록되어 있다. 위 표는 포스팅별 기록 화면을 기준으로 정리했다.

게임 1 - 3의 규칙은 끝내 넘지 못했다

게임 1 기록

시즌 28의 첫 게임은 헬레나 리체스로 시작했다. 규칙 모디파이어는 “낭비하지 말라”였고, 핵심은 3의 규칙과 실험 시도였다.

결과는 3등. 소규모 전투 점수는 15점, 종료 직후 랭킹은 694등이었다.

첫 게임치고 아주 나쁜 출발은 아니었지만, 핵심 모디파이어였던 3의 규칙을 제대로 살리지 못했다. 실험 시도 점수는 챙겼지만, 자원 3종 보유 조건을 맞추는 감각이 부족했다.

지금 돌이켜보면 게임 1은 시즌 28 전체의 예고편 같았다. 규칙을 이해하는 것과 실제로 점수화하는 것은 완전히 다른 문제였다.

게임 2 - 익스와 모디파이어 사이에서 방황하다

게임 2 기록

게임 2에서는 아먼드 에카드 대공을 선택했다. 모디파이어는 하역 효과와 프레멘 유대감이 중심이었다.

하지만 익스 확장이 들어오면서 판단이 흔들렸다. 상품 운송을 무시할 수 없고, 그렇다고 순위표 점수 조건을 포기할 수도 없었다.

결과적으로 게임 2는 방향성이 애매했다. 3등 보상 5점에 친족 1점만 더해 6점을 얻었고, 시즌 누적은 21점, 랭킹은 930등까지 떨어졌다.

시즌 초반부터 꽤 큰 타격이었다. 게임 2는 “모디파이어를 의식하되, 기본 승리 플랜을 잃으면 안 된다”는 교훈을 남겼다.

게임 3 - 언더독의 반란과 짜릿한 역전승

게임 3 기록

게임 3에서 다시 헬레나 리체스로 돌아왔다. 그리고 이 선택은 제대로 적중했다.

이번 판은 언더독과 몰입 상태 모디파이어가 핵심이었다. 병력이 적은 상태에서 교전을 이기면 추가 점수를 얻는 구조였고, 후반부에 이를 살릴 수 있는 전투 운영이 중요했다.

10라운드 마지막 승부가 특히 인상적이었다. 황제 팩션 동맹, 베네 게세리트 영향력 복구, 책략 카드, “스파이스는 흘러야 한다” 구매까지 한 번에 터뜨리며 역전승을 만들어냈다.

소규모 전투 점수는 25점. 1위 보상 20점에 모디파이어 점수를 더했고, 전체 랭킹도 719등까지 회복했다.

게임 3은 시즌 28의 첫 번째 전환점이었다. “이번 시즌도 해볼 만하다”는 감각을 준 판이었다.

게임 4 - 헬레나 리체스 전술 승리

게임 4 기록

게임 4 역시 헬레나 리체스를 선택했다. 규칙 모디파이어는 “점거 계획”이었고, 순위표 점수는 우주 항행 길드 카드와 프레멘 유대감이 중심이었다.

이 판에서는 틀레이락스 카드와 덱 압축, 후반 전투 폭발력이 잘 맞아떨어졌다. 초반에는 무리하지 않고 내정을 다졌고, 중반부터 틀레이락스 카드와 책략 카드로 힘을 모았다.

특히 9라운드와 10라운드의 전투력이 압권이었다. 9라운드에는 전투력 26, 10라운드에는 전투력 28로 압도했다.

정규 게임 결과는 13승점 1위. 소규모 전투 점수는 22점으로, 시즌 누적은 68점, 순위는 543등까지 올라갔다.

게임 4는 헬레나 리체스의 장점을 제대로 느낀 판이었다. 시장 관리, 덱 압축, 후반 폭발력. 이 세 가지가 맞물리면 얼마나 강력한지 보여줬다.

게임 5 - 우주 정치학이 가른 7라운드 승부

게임 5 기록

게임 5에서는 드물게 레토 아트레이드 공작을 선택했다. 이번 판의 핵심은 “우주 정치학”이었다.

팩션 동맹을 맺을 때 솔라리를 추가로 얻는 구조였고, 레토의 인장 반지 능력은 팩션 영향력 확보에 강점이 있었다. 이 선택은 꽤 좋았다.

게임은 생각보다 짧고 강렬했다. 레토의 영향력 운영이 제대로 먹히면서 12승점 1위를 달성했다.

소규모 전투 점수는 21점, 시즌 누적은 89점, 랭킹은 494위까지 올라갔다.

게임 5는 “지도자 선택을 모디파이어에 맞추는 것”의 중요성을 다시 확인한 판이었다. 헬레나가 편하고 강하지만, 특정 조건에서는 레토처럼 확실한 장점이 있는 지도자가 더 잘 맞을 수 있다.

게임 6 - 황제를 등지고 우주를 항해하다

게임 6 기록

게임 6에서는 다시 헬레나 리체스를 선택했다. 이 판은 우주 항행 길드 메타와 덱 압축이 중요했다.

제목처럼, 황제 쪽을 무리하게 파기보다는 길드와 덱 운영에 집중했다. 헬레나의 시장 관리 능력으로 필요한 카드를 확보하고, 불필요한 카드는 걷어내며 엔진을 정리했다.

결과는 매우 좋았다. 게임 점수로는 28점을 획득했고, 시즌 랭킹은 449위에 안착했다.

게임 6부터는 확실히 플레이 감각이 올라왔다. 초반 두 게임에서 흔들렸던 것과 달리, 어떤 모디파이어를 챙겨야 하고 어느 시점에 승부를 걸어야 하는지 점점 선명해졌다.

게임 7 - 10점 동점 접전, 스파이스로 승리

게임 7 기록

게임 7은 시즌 28에서 가장 긴장감 있었던 판 중 하나다. 불멸 확장이 들어왔고, 모디파이어는 틀레이락스 카드 획득과 덱 셔플이 중심이었다.

지도자는 역시 헬레나 리체스. 하지만 이 판은 쉽게 풀리지 않았다. 세 번의 기회 끝에 겨우 1등을 잡았고, 마지막에는 10점 3인 동점 상황이 벌어졌다.

승부를 가른 것은 스파이스였다. 동점자 처리에서 스파이스 우위로 1등을 확정했다.

게임 7 종료 기준 시즌 누적 점수는 146점, 랭킹은 401등이었다. 상위 400등 안쪽이 눈앞에 보이는 위치였다.

게임 7은 “듄 임페리움은 끝날 때까지 끝난 게 아니다”라는 말을 그대로 보여준 판이었다.

게임 8 - 44점, 시즌 최고 점수 경신

게임 8 기록

게임 8은 시즌 28 최고의 판이었다. 최종 점수는 무려 44점.

규칙 모디파이어는 영원한 전쟁. 게임 종료 조건이 10점이 아니라 12점으로 올라가면서 전체 호흡이 길어졌다.

순위표 점수는 두 가지였다.

• 탐험: 에이전트를 보낸 유니크 게임판 공간마다 +1점
• 시치의 친구: 획득한 프레멘 카드마다 +1점

이 조건은 헬레나 리체스와 궁합이 좋았다. 헬레나의 시장 관리 능력으로 프레멘 카드를 찾고, 장기전이 된 틈을 타서 다양한 액션 칸을 방문했다.

정규 게임도 12점으로 1위를 차지했고, 정산 결과가 압도적이었다.

• 1위 보상: +20
• 탐험: +17
• 시치의 친구: +7
• 총점: 44점

게임 8 종료 후 시즌 누적은 190점, 랭킹은 347위까지 상승했다.

이번 시즌 전체에서 가장 완성도 높은 판이었다. 모디파이어 이해, 지도자 선택, 장기전 운영, 점수화까지 모든 것이 잘 맞았다.

게임 9 - 일촉즉발의 승부, 29점으로 1위

게임 9 기록

게임 9도 좋은 흐름을 이어갔다. 이번 판은 물 자원 소비와 우주 항행 길드 카드가 핵심이었다.

모디파이어는 다음과 같았다.

• 수문 개방: 사용한 물 1개당 +1점
• 항해사: 획득한 우주 항행 길드 카드 1장당 +1점

초반에는 전략적으로 2등을 가져가며 자원을 챙겼고, 중반에는 소드마스터와 원로회 의석을 확보하며 기반을 다졌다.

가장 재미있었던 장면은 8라운드였다. 내가 1등을 하면 게임이 너무 빨리 끝날 수 있는 상황이라, 일부러 1등을 피하고 라운드를 더 끌고 갔다. 순위표 점수를 더 쌓기 위한 선택이었다.

마지막 10라운드는 일촉즉발이었다. 나와 리체스 백작이 9점 동점이었고, 하코넨과 레토도 추격 중이었다. 결국 전투력 20을 쏟아부으며 1등을 확정했고, “계획 속의 계획”과 “시장 독점”까지 발동하며 마무리했다.

최종 점수는 29점.

• 1위 보상: +20
• 수문 개방: +7
• 항해사: +2
• 총점: 29점

게임 9 종료 기준 시즌 누적은 219점, 전체 순위는 332등이었다. 이때까지만 해도 시즌 마무리가 꽤 아름다울 줄 알았다.

게임 10 - 마지막 게임, 역대급 난이도에 좌절

게임 10 기록

그리고 마지막 게임 10. 시즌 28의 대미를 장식할 판이었지만, 결과적으로는 가장 아쉬운 게임이 되었다.

규칙 모디파이어는 게릴라전. 공개 턴 중 교전에서 병력 하나를 퇴각시킬 수 있는 규칙이었다.

순위표 점수는 다음과 같았다.

• 언더독: 상대가 나보다 많은 유닛을 보유했지만 내가 이긴 교전마다 +3점
• 표본 획득: 틀레이락스 카드를 획득하는 데 사용한 표본마다 +1점

이론상으로는 언더독을 잘 활용하면 고득점을 낼 수 있는 판이었다. 하지만 실제로는 AI들이 너무 강했다.

총 3번의 도전을 했고, 결과는 다음과 같았다.

• 1차 시도: 12점, 3위
• 2차 시도: 15점, 4위
• 3차 시도: 6점, 4위

가장 높은 점수였던 2차 시도의 15점이 최종 반영되었다. 하지만 그마저도 표본 획득 점수에 의존한 결과였고, 핵심이었던 언더독은 거의 살리지 못했다.

AI들은 게릴라전 규칙을 너무 잘 활용했다. 내가 병력을 빼면 바로 빈틈을 치고 들어왔고, 오히려 AI들이 언더독 상황을 만들어내는 장면도 나왔다.

결국 게임 10에서는 15점을 추가해 시즌 누적 234점으로 마무리했다. 게임 직후 순위는 367등이었지만, 최종 정산 과정에서 388등으로 확정된 것으로 보인다.

마지막 게임은 분명 아쉬웠다. 하지만 듄 임페리움다운 마무리이기도 했다. 끝까지 마음대로 되지 않는 게임. 그래서 다시 하게 되는 게임.

시즌 28을 돌아보며

시즌 28은 내 듄 임페리움 디지털 소규모 전투 기록 중에서도 꽤 기억에 남을 시즌이었다.

초반에는 모디파이어 해석이 흔들렸다. 게임 1에서는 3의 규칙을 살리지 못했고, 게임 2에서는 익스 확장과 순위표 점수 사이에서 방향을 잃었다.

하지만 게임 3부터 감을 잡기 시작했다. 헬레나 리체스를 중심으로 시장 관리와 덱 압축, 후반 전투 폭발력을 활용하는 방식이 안정적으로 자리 잡았다.

게임 4, 6, 7은 헬레나 운영의 숙련도가 올라가는 과정이었다. 게임 5에서는 레토를 선택해 지도자 선택의 폭을 넓혔다. 게임 8은 이번 시즌의 하이라이트였다. 게임 9는 승리 타이밍을 조절하는 재미가 있었다. 게임 10은 마지막까지 방심할 수 없다는 교훈을 남겼다.

이번 시즌에서 가장 크게 느낀 점은 세 가지다.

첫째, 소규모 전투는 정규 게임 1등만으로 끝나지 않는다. 1등 보상 20점은 중요하지만, 상위권으로 가려면 모디파이어 점수를 얼마나 챙기느냐가 훨씬 중요하다.

둘째, 헬레나 리체스는 여전히 강하다. 시장 관리 능력은 거의 모든 모디파이어에서 유연하게 대응할 수 있게 해준다. 특히 특정 카드 유형을 모아야 하는 판에서는 압도적인 안정감을 준다.

셋째, 고득점을 위해서는 때로는 빨리 이기지 않아야 한다. 게임 8과 게임 9에서 특히 그랬다. 게임을 끝낼 수 있다고 바로 끝내는 것이 아니라, 순위표 점수를 더 쌓을 수 있는 시간을 확보하는 것이 중요했다.

아쉬움도 있지만, 만족스러운 시즌

최종 388등. 숫자만 보면 엄청난 상위권이라고 말하기는 어렵지만, 시즌 초반 930등까지 떨어졌던 것을 생각하면 꽤 괜찮은 마무리다.

특히 게임 8에서 44점을 기록한 것은 오래 기억에 남을 것 같다. 반대로 게임 10에서 언더독을 한 번도 제대로 살리지 못한 것은 계속 아쉬움으로 남는다.

하지만 이게 듄 임페리움이다. 계산대로 흘러가는 듯하다가도, AI의 한 수와 카드 한 장, 전투 하나 때문에 모든 계획이 흔들린다.

시즌 28은 나에게 그런 감각을 다시 알려준 시즌이었다.

다음 시즌에서는 조금 더 초반부터 안정적으로 점수를 쌓고 싶다. 특히 게임 1~2에서 방향을 잃지 않고, 모디파이어별 핵심 점수 루트를 더 빠르게 파악하는 것이 목표다.

시즌 28은 388등으로 마무리. 아쉽지만, 충분히 재미있었고, 꽤 많이 배운 시즌이었다.

다음 시즌에도 스파이스는 계속 흘러야 한다. 🏜️

매 시즌마다 총 10번의 게임 기회가 주어집니다. 이번 듄 임페리움 소규모 전투 시즌 28도 이제 마지막 게임만이 남았고, “유종의 미”를 거두기 위해 전의를 불태우며 참전하였습니다.

🎲 게임 10: 익숙하지만 까다로운 규칙들

이번 게임 10의 설정은 예전에 한 번씩 겪어봤던 것들이었지만, 막상 다시 마주하니 결코 만만치 않은 조합이었습니다.

규칙과 순위표 내용 모두 예전에 해본 것들이었는데, 그때마다 기억을 되살려 전략을 짜는 건 쉽지 않다는 생각이 듭니다. 이번 게임 역시 만만치 않겠다는 직감이 들었고, 고득점을 위해서는 결국 ‘언더독’을 얼마나 잘 활용하느냐에 승패가 달렸다고 판단했습니다. 병력 수가 적은 상태에서 1등을 차지하려면 강력한 계책 카드나 공개 턴에 전투력을 폭발적으로 올려주는 카드가 필수적인 상황이었습니다.

👑 지도자 선택: 안정감의 헬레나 리체스

어느 지도자도 특별히 우세해 보이지 않는 까다로운 조건 속에서, 저의 선택은 안정적인 플레이가 가능한 “헬레나 리체스”였습니다.

전투력을 올려주는 카드를 적재적소에 확보하기 위해서는 인장 카드의 효과로 카드 선택의 여유를 가질 수 있는 지도자가 유리할 것이라고 생각했기 때문입니다.

💥 처참하게 무너진 3번의 도전

총 3번의 도전 기회가 있었지만… 그 결과는 그야말로 처참했습니다.

1차 시도: 12점 (3위)

첫 번째 시도에서는 12점으로 3위를 기록했습니다. 야심 차게 언더독을 노려봤으나 단 한 번도 성공하지 못했고, 표본 획득으로 +7점을 챙기는 데 만족해야 했습니다.

2차 시도: 15점 (4위)

두 번째 시도는 가장 높은 점수인 15점을 냈지만, 어이없게도 등수는 4등이었습니다. 이 점수마저도 표본 획득 점수(+15)로 영혼까지 끌어모은 결과였습니다. 이번에도 언더독은 모두 실패로 돌아갔습니다.

3차 시도: 6점 (4위)

마지막 3차 시도는 처참한 6점(4위)으로 마무리되었습니다. 표본 획득 +6점이 전부였고, 언더독은 결국 단 한 번도 성공하지 못했습니다.

😱 역대급 AI 난이도와 연속된 ‘억까’

이번 게임에서 AI들의 플레이는 정말… 혀를 내두를 정도로 강력했습니다. “게릴라전” 규칙으로 인해 교전에서 병력 1개를 퇴각시킬 수 있었는데, 제가 틈을 노려 병력을 퇴각시키면 AI 지도자들이 귀신같이 그 빈자리에 병력을 왕창 집어넣거나, 오히려 본인들이 보란 듯이 언더독을 시전해버리는 상황에 속수무책으로 당했습니다. 이른바 ‘억까’의 연속이었습니다.

물론 패가 제대로 풀리지 않았다는 핑계도 대보고 싶지만, 냉정하게 말해서 이번 게임은 제가 철저히 밀렸고 못했습니다. 유종의 미를 거두려던 저의 야심 찬 계획은 완전히 물거품이 되어버렸네요. ㅠ

📉 아쉬운 결산, 그리고 시즌 28의 마무리

처음부터 모디파이어 조합이 까다롭다고 생각해서 챗GPT에게 공략의 방향성을 물어보기도 했습니다. 하지만 실제 게임에서는 매 라운드, 매 턴마다 수많은 변수가 발생하고 그 순간의 선택이 모든 것을 좌우합니다.

보통 운이 따라주면 3라운드쯤에 소드마스터와 원로회 의석을 확보해서 일찍부터 스노우볼을 굴리는 것이 정석입니다. 하지만 이번 게임 10에서는 5~6라운드나 되어서야 간신히 소드마스터와 원로회를 얻다 보니 턴당 행동 수가 너무 적었고, 고비용의 강력한 카드를 획득할 기회마저 줄어든 것이 치명적인 패인이었습니다. 일부러 늦게 들어간 것은 아니었고, 스파이스를 솔라리로 바꾸는 액션 칸을 AI 지도자들이 계속 먼저 치고 들어오는 바람에 손을 쓸 수가 없었습니다. 돌이켜보면 어떻게든 제가 한 턴이라도 더 빨리 자리를 선점했어야만 했나 하는 아쉬움이 남습니다.

결국 소규모 전투 시즌 28의 마지막 게임 10에서 15점을 추가하며, 이번 시즌 저의 총 누적 점수는 234점으로 마무리되었습니다. 현재 기준으로 순위는 367등인데, 전 세계 유저들의 시즌 마감이 모두 끝나면 어쩌면 400등 밖으로 밀려날 수도 있겠다는 불안감이 드네요. 하… 끝까지 안심할 수가 없습니다.

이로써 듄 임페리움 소규모 전투 시즌 28의 모든 게임 일정이 마무리되었습니다. 최종 결산이 이루어지고 순위가 확정되면 다시 한번 블로그에 포스팅을 올릴 예정입니다. 다음 포스팅에서는 이번 시즌 동안 치렀던 10번의 게임을 되돌아보며, 시즌 28 전체에 대한 총평과 감상을 남겨보도록 하겠습니다.

이번 시즌도 고생 많으셨습니다! 🏜️

시즌 중반까지 4~500등 대에 머무르며 고전했지만, 후반부에 접어들며 게임의 감을 제대로 잡아가고 있습니다. 이번 게임 9에서는 물 자원과 길드 카드를 영리하게 활용하여, 마지막 10라운드의 숨 막히는 동점 상황에서 극적인 역전 1위를 달성했습니다. 실버 등급 마무리가 가시권에 들어온 이번 게임의 기록을 남깁니다.

물 자원 소비와 길드 전략이 핵심이었던 게임 9. 헬레나 리체스로 당당히 1위를 차지했습니다.

💧 물과 우주를 지배하는 자

이번 게임 9는 물 자원의 활용과 우주 항행 길드의 영향력이 승패를 가르는 독특한 조건 속에서 시작되었습니다.

물 자원을 사용할 때마다 점수를 얻고, 우주 항행 길드 카드도 점수가 되기 때문에 이 두 가지를 염두에 두고 전략을 짜야 했습니다. 이런 운영 중심의 판에서는 안정적인 시장 관리가 가능한 “헬레나 리체스”가 최고의 선택이었습니다.

⚔️ 전략적 2등 전략과 엔진 빌딩

초반 라운드는 다들 전투에 진심인 모습이었습니다.

• 1라운드 (드러난 교전): 전투력 6을 투자해 2등으로 솔라리 3원을 획득했습니다. AI 하코넨 남작은 무려 전투력 9를 쏟아붓는 괴력을 보여주었습니다.
• 2라운드 (권모술수): 전투에 참여하지 않고 내실을 다졌습니다. 레토 공작이 1등을 차지했습니다.
• 3라운드 (추악한 의도): 소드마스터를 빠르게 확보했고, 전투에서는 리체스 백작이 1등을 가져갔습니다. 저는 2등으로 ‘물 자원’을 얻었는데, 평소라면 무리해서 들어가지 않았겠지만 물 소비가 순위표 점수가 되기 때문에 전략적으로 2등을 노렸습니다.

4라운드 (은행 습격)에서는 모두가 솔라리를 보상으로 받는 꿀 같은 기회가 왔습니다. 여기서 계책 카드 “계획 속의 계획”(3 영향력 이상인 팩션 트랙이 4개 이상이면 종료 단계에서 승점 2점)을 얻게 되면서 전체적인 게임의 청사진이 그려졌습니다. 길드 카드를 살지 고민하다가, 팩션 영향력 확보를 위해 특정 팩션을 2단계 올려주는 “파워 플레이”를 선택하고 2등 보상으로 4 솔라리를 받아 원로회 자금을 마련했습니다.

이후 5라운드 (저장고 습격), 6라운드 (혼란수습) 모두 아쉽게 2등을 기록했습니다. 1등을 노려볼 만도 했지만 하코넨 남작이 8까지 전투력을 올리는 등 AI들의 전투 의지가 엄청났습니다.

🎭 8라운드의 숨 고르기, 1등을 피하라!

7라운드에서 마침내 1등을 차지하며 후반전의 기선을 제압했습니다. 그리고 대망의 8라운드 (카르타그 대전투)가 밝았습니다.

당시 점수 상황은 나 8점, 하코넨 6점, 리체스 5점, 레토 3점으로 제가 압도적으로 유리했습니다. 그런데 8라운드 1등 보상이 무려 승점 2점이었습니다! 만약 제가 1등을 해버리면 10점이 되어 게임이 너무 일찍 끝나버립니다. 물 소비와 길드 카드 확보로 스코어를 더 올려야 하는 저로서는 절대 1등을 해서는 안 되는 상황이었습니다.

그래서 1등을 레토 공작에게 양보하고 3등이라도 챙기려 병력을 살짝 넣었는데… 다들 급했는지 병력을 어마어마하게 투입했습니다. 레토 공작 25, 하코넨 남작 16, 리체스 백작 15! 저는 전투력 3으로 구경만 했지만, 라운드를 지속시키려는 저의 목적은 완벽하게 달성되었습니다.

🔥 10라운드, 일촉즉발의 승부

9라운드를 지나 대망의 마지막 10라운드가 시작되었습니다. 그런데 10라운드의 1등 보상이 승점이 아닌 팩션 영향력 2칸 상승이었습니다. 자칫하면 제가 가진 “계획 속의 계획” 계책 카드의 조건이 무너지거나, 다른 AI가 동맹을 빼앗아 갈 수도 있는 위험한 상황이었습니다.

점수 상황 역시 일촉즉발이었습니다. 나 9점 vs 리체스 9점 (동점) / 하코넨 8점 / 레토 7점.

결과는? 전투력 20으로 왕창 때려 넣으며 당당히 1등을 차지했습니다! 여기에 “계획 속의 계획”과 “시장 독점” 계책 카드까지 모두 발동하며 완벽한 피날레를 장식했습니다.

정규 게임 최종 결과는 나 13점, 리체스 백작 10점, 하코넨 남작 8점(스파이스 우위), 레토 공작 8점이 되었습니다.

🏆 소규모 전투 스코어 정산

이어진 스코어 정산에서도 목표했던 바를 쏠쏠하게 달성했습니다.

총 29점을 획득했습니다! 사용한 물 한 개당 1점씩 7점, 길드 카드로 2점을 챙기며 준수한 성적을 거뒀습니다.

🥈 실버 마무리를 향하여

현재 기준으로 시즌 누적 점수 219점, 전체 순위는 332등입니다.

시즌 중반까지 400~500등 대에 머물렀던 것을 생각하면, 후반부에 보여주고 있는 퍼포먼스는 매우 고무적입니다. 이대로라면 이번 시즌은 무난하게 실버 등급으로 마무리할 수 있을 것 같습니다. 남은 게임들도 끝까지 집중해서 멋진 마무리를 지어보겠습니다. 🏜️

• 책 제목 : 클로드 코드 완벽 가이드
• 저자 : 최지호(코드팩토리)
• 출판사 : 골든래빗(주)
• 발간일 : 2025년 09월 01일

클로드 코드 완벽 가이드 표지

책을 읽게 된 배경과 목적

이 책은 안티그래비티 가이드보다 먼저 나온 책입니다. 발간일이 2025년 9월이니 사실 지금으로부터 1년도 채 안 된 책인데, AI 기술은 그새 또다시 업그레이드 되고 말았습니다. 이 책에서는 클로드 4에 대해서 이야기하는데, 지금은 클로드 4.5를 넘어서 클로드 4.7까지 나왔으니 말이죠. 뭐 모델 성능은 좀 차이가 있더라도 사용하는 방법론에 대해서는 큰 차이가 없어서 하루 날 잡아서 슬슬 읽어 내려갔습니다.

제가 이 책에서 원했던 내용은 “클로드 코드가 무엇인지”, “과연 안티그래비티하고 무엇이 다른 건지”, 그리고 “클로드 코드를 어떻게 쓰면 좋은 건지”에 대한 궁금증을 해소하는 것이었습니다.

클로드 코드의 진입 장벽: 구독 요금

일단 클로드 코드를 제대로 사용하려면 클로드 서비스를 구독해야 합니다. 저는 기존에 구독을 하지 않고 있었기 때문에 제대로 사용하려면 클로드 PRO나 MAX 요금제를 구독해야 하더군요. 지금 당장 필요한 서비스를 구현해야 하거나, 바이브 코딩이 절실히 필요한 상황은 아니라서 직접 실습하기보다는 전체적인 흐름만 주욱 살펴보았습니다.

사실 지금 당장 클로드 MAX 20으로 월 $200짜리 요금제를 쓰는 게 좀 부담스럽기도 했습니다. 물론 현재 ChatGPT Plus 요금제로도 충분히 잘 쓰고 있어서 그런 점도 작용했습니다.

주요 인사이트와 배운 점

내용은 기존 안티그래비티 책을 이미 읽어서 그런지, 예시 프로젝트를 통해 진행하는 흐름을 이해하는 데는 크게 어렵지 않았습니다. 책을 읽으며 새롭게 알게 된 주요 개념들은 다음과 같습니다.

1. CLAUDE.md와 AI 에이전트 지침

책에서 CLAUDE.md라는 개념에 대해 중요하게 이야기하는데, 이 부분은 현재 제가 사용하는 오픈클로와 어느 정도 비슷한 느낌이 들었습니다. AI 에이전트에게 프로젝트의 특성과 지침들을 미리 알려주는 가이드 역할을 한다는 점이 인상적이었습니다.

2. Playwright와 테스트 자동화

Playwright(플레이라이트) 서비스는 이번에 처음 접했는데, 테스트 자동화라는 개념에서 현재 제가 담당하고 있는 웹서비스의 품질 향상을 위해 꼭 필요할 것 같다는 생각이 들었습니다. E2E(End to End) 테스트라는 개념도 접할 수 있어 유익했습니다.

3. MCP(Model Context Protocol)의 가능성

MCP(Model Context Protocol) 개념은 향후 내부 AI 모델을 도입했을 때, 서비스 연동 측면에서 어떻게 활용할 수 있을지 방법을 찾아봐야겠다는 인사이트를 주었습니다. 특히 Context7이라는 주요 서비스들의 최신 설명을 모아둔 MCP가 있다는 것을 처음 알게 되어 흥미로웠습니다.

4. Supabase 연동의 익숙함

DB 연동 부분에서 Supabase(수파베이스)가 등장했는데, 안티그래비티 책에서 이미 경험했던 부분이라 익숙해서 다행이었습니다. 만약 이걸 처음 봤다면 좀 어려웠을 텐데, 한두 번 해본 경험이 있다 보니 ‘아, 이것도 프로젝트 생성하고 키 발급받아서 환경설정에 키 값 넣어주면 사용할 수 있고, DB 마이그레이션 SQL 작성해달라고 한 다음에 실행시키면 스키마가 만들어지겠구나’ 하는 그림이 머릿속에 바로 그려졌습니다.

마무리

클로드 코드를 현재 구독하고 있진 않지만 조만간 꼭 한번 써봐야겠다는 생각이 들었습니다. 일단은 최근 장만한 맥미니에 로컬 모델(qwen 3.5 9b, gemma e4b)도 한번 돌려보며 로컬 환경에서의 가능성도 테스트해볼 계획입니다.

AI의 발전 속도가 눈부신 만큼, 다양한 도구들의 특성을 파악하고 내게 맞는 툴을 적재적소에 활용하는 안목을 기르는 것이 중요해 보입니다.

게임 7에서 10점 3인 동점이라는 피말리는 접전을 겪었던 것이 엊그제 같은데, 이번 게임 8에서는 완전히 다른 양상이 펼쳐졌습니다. 시즌 28 역대 최고 점수인 44점을 기록하며 그야말로 무대를 지배했습니다. 헬레나 리체스와 함께한 이번 대승의 기록을 공유합니다.

게임 8의 압도적인 성과를 보여주는 대표 이미지. 무려 44점이라는 시즌 최고 점수를 달성했습니다.

📜 길고 긴 영원한 전쟁, 그리고 새로운 기회

이번 듄 임페리움 소규모 전투 시즌28 게임8의 전장은 평소보다 훨씬 길고 치열하게 설계되어 있었습니다. 익스(Ix) 확장이 포함된 이번 판의 핵심 변수는 단연 ‘영원한 전쟁’ 모디파이어였습니다.

보통 10점에서 끝나는 듄 임페리움의 템포가 12점으로 늘어났다는 것은 엄청난 차이를 만듭니다. 덱을 정비하고, 엔진을 굴리고, 더 많은 카드를 구매할 수 있는 충분한 시간이 주어지기 때문입니다.

저는 이 늘어난 호흡을 순위표 점수 모디파이어와 완벽하게 연계하기로 했습니다. “최대한 다양한 장소를 방문(탐험)하고, 프레멘 카드(시치의 친구)를 긁어모으자.” 게임의 목표 점수가 12점이라는 것은, 반대로 말하면 순위표 점수를 쌓을 시간이 그만큼 늘어났다는 뜻이기도 했습니다.

👑 유연함의 상징, 헬레나 리체스와의 재회

지도자는 또다시 헬레나 리체스를 선택했습니다. 시장(제국열)의 카드를 유동적으로 관리할 수 있는 그녀의 능력은, ‘프레멘 카드’를 찾아내어 구매해야 하는 이번 미션에 가장 완벽하게 부합했습니다.

초반부터 헬레나의 능력을 적극 활용해 불필요한 카드들을 제국열에서 지워버리고, 빈자리에 프레멘 카드가 등장하기를 기다렸습니다. 동시에 ‘탐험’ 점수를 위해 평소라면 잘 가지 않던 구석구석의 액션 칸들까지 부지런히 에이전트를 파견했습니다.

⚔️ 길어지는 전선, 밀고 당기는 전투

목표 점수가 12점이다 보니 게임판의 양상도 중반을 넘어 후반까지 매우 팽팽하게 이어졌습니다. 하코넨 남작과 멤논 소르발드 백작의 공세도 만만치 않았습니다.

특히 하코넨 남작은 ‘저장고 습격’ 전투 등에서 승리하며 끈질기게 점수를 따라붙었고, 저 역시 아라킨 대전투에서 19의 전투력으로 하코넨과 치열한 무승부를 기록하기도 했습니다.

하지만 전투에 모든 자원을 쏟아붓지 않았습니다. 저의 진짜 목적은 전투 승리 자체보다, 게임이 12점까지 길어지는 동안 ‘유니크 공간 방문’과 ‘프레멘 카드 수집’이라는 순위표 과제를 묵묵히 수행하는 것이었습니다.

🏆 전율의 스코어 정산, 44점 폭발!

막바지에 다다르며 경제적 패권 전투에서 압도적인 무력을 과시하며 승기를 잡았고, 결국 12점의 고지를 가장 먼저 밟으며 당당히 1등으로 게임을 마무리지었습니다.

하지만 진짜 승부는 정규 게임이 끝난 직후부터였습니다. 게임 내내 뿌려둔 씨앗들이 순위표 정산 화면에서 엄청난 결과로 되돌아왔습니다.

무려 44점. 소규모 전투에서 단일 게임으로 이렇게 높은 점수를 받아본 적이 있었나 싶을 정도의 대기록입니다.

총 17곳의 유니크 공간을 방문하여 17점을 추가로 쓸어 담았고, 헬레나의 능력으로 악착같이 모은 프레멘 카드가 7장으로 7점을 얹어주었습니다. ‘영원한 전쟁’으로 인해 턴 수가 많아진 점을 역이용하여, 게임판 구석구석을 누비고 덱을 불린 전략이 완벽하게 적중한 셈입니다.

📈 시즌 28 랭킹 중간 점검

이번 게임 8의 엄청난 선전 덕분에 시즌 누적 랭킹에서도 의미 있는 도약을 이루어냈습니다.

시즌 28 누적 결과 (게임 8 종료 기준)

• 누적 점수: 190점
• 이번 게임 점수: 44점 (개인 최고 기록)
• 시즌 랭킹: 347위

게임 7 직후 401위였던 순위가 단숨에 347위까지 수직 상승했습니다. 44점이라는 거대한 포인트 폭탄이 터지면서 상위권 경쟁에 확실하게 불을 붙였습니다.

특히 랭킹보드에 당당히 적힌 ‘게임 점수 44’라는 숫자가 정말 기분 좋게 만듭니다. 이번 시즌 28도 슬슬 후반부로 향해 가고 있는데, 오늘 보여준 이 엄청난 기세와 전략적 유연성을 남은 게임에서도 계속 이어가 최고 랭킹으로 시즌을 마무리하고 싶습니다.

다음 게임에서도 헬레나의 혜안, 그리고 끝없이 흐르는 스파이스와 함께 승리를 쟁취해 보겠습니다. 🏜️