기존 write-post는 유지하고 결론 우선 사례글 흐름만 보완한 방법

한줄 요약

AI 코딩 도구로 작업한 기록을 DEVLOG나 사례글로 옮기면, 날짜순으로 정리된 로그는 작업 재현에는 좋지만 처음 읽는 사람이 결과와 판단 기준을 빠르게 잡기에는 불편할 수 있습니다. 그래서 기존 write-post의 세션 수집·파싱 흐름은 유지하고, 소스 선택·글 유형 판정·결론 우선 구조·문체·다이어그램 규칙을 별도 write-post-mod로 보완했습니다.

핵심은 원본을 통째로 고쳐 쓰지 않은 데 있습니다. 세션을 가져오는 책임과, 가져온 기록을 읽기 쉬운 글로 바꾸는 책임을 분리했습니다.

Hermes 쪽에서는 기존 write-post에 Hermes 세션을 스캔하고 Hermes 환경의 세션을 파싱하는 가이드를 더했습니다. Claude Code에서 만든 write-post-mod는 이 세션 기록을 어떤 구조와 문체로 보여줄지 정하는 역할을 맡습니다.

세션 수집 기능과 글쓰기 규칙을 분리하면, 원본 기능을 훼손하지 않고 확장할 수 있습니다.

이런 분들께 도움될 것 같아요

• AI 코딩 도구로 한 작업을 DEVLOG나 사례글로 정리하려는 분

• 기존 스킬은 유지하면서, 글의 구조와 문체만 보완하고 싶은 분

• 날짜순 로그에서 결과와 판단 기준을 더 빨리 보여주고 싶은 분

왜 기존 로그만으로는 부족했나

기존 write-post는 AI 코딩 도구의 세션을 프로젝트 단위로 찾아 작업 기록을 모으고, 이를 DEVLOG와 사례글로 연결하는 흐름을 제공합니다. 세션 파일의 형식과 도구별 질문·응답을 파싱하는 규칙도 포함돼 있어, 기록을 수집하는 기반으로 쓸 수 있습니다.

다만 날짜별 Day N 구조는 작업한 순서를 남기는 데에는 맞아도, 사례글을 처음 읽는 사람에게는 결과가 무엇인지, 왜 그런 판단을 했는지가 뒤로 밀릴 수 있습니다. 같은 형식이 모든 사례에 맞지도 않습니다. 무엇을 만들었는지 보여줘야 하는 글, 여러 대안을 비교한 글, 자동화 효과를 보여줘야 하는 글은 중심에 둘 정보가 다릅니다.

그래서 원본의 세션 수집 기능은 보존하고, 글을 쓰기 전에 사례의 성격을 고르는 흐름을 별도 스킬로 만들었습니다.

사용한 도구와 역할

write-post는 세션을 모으고 파싱하는 기반을 맡고, write-post-mod는 그 결과를 DEVLOG와 사례글로 정리하는 규칙을 맡습니다. Hermes write-post에는 Hermes 세션 스캔과 Hermes 환경의 세션 파싱 가이드가 추가돼, Claude Code 밖의 기록도 같은 흐름으로 가져올 수 있게 했습니다.

Claude Code용 공개 write-post와 Hermes의 write-post, write-post-mod의 수정·추가 내용을 사례글로 정리하고 싶다.

처음에는 Hermes에 설치된 변형 스킬이라는 식으로 설명했지만, 제작 주체와 역할이 섞여 있었습니다. 문서를 다시 보며 Claude Code 보완 스킬과 Hermes 세션 처리 확장을 분리했습니다.

write-post-mod는 Claude Code에서 기존 write-post를 보완하기 위해 따로 만든 스킬이다. Hermes write-post에는 Hermes 세션 스캔과 파싱 가이드가 추가됐다.

이 구분이 사례글의 구조도 결정했습니다. write-post-mod는 세션을 수집하는 도구가 아니라, 수집된 기록을 읽기 쉬운 글로 바꾸는 규칙이라는 점을 중심에 놓았습니다.

작업 과정

전체 흐름은 세션을 가져오는 단계와, 그 기록을 글로 바꾸는 단계를 분리하는 방식입니다.

[Image blocked: 원본·보완 스킬·Hermes 세션 처리 흐름]

ALT

한국어로 게시물을 작성하는 과정을 보여주는 다이어그램

세션을 모으는 일과 글을 쓰는 일을 나눴습니다

원본 write-post는 여러 AI 코딩 도구의 세션을 찾고, 도구마다 다른 저장 형식을 파싱하는 역할을 합니다. 이 부분은 경로·인코딩·질문 도구의 응답 형식처럼 환경에 영향을 많이 받습니다.

반면 write-post-mod는 세션을 파싱한 결과나 사용자가 직접 지정한 파일을 받아, 어떤 글로 쓸지 정합니다. 소스가 이미 지정돼 있으면 자동 스캔을 생략하고, 스캔한 세션을 쓸 때만 원본의 수집 흐름을 사용합니다.

이렇게 나누면 파서가 바뀌어도 글의 문체 규칙을 건드릴 필요가 없고, 글쓰기 방식이 바뀌어도 세션 파서를 다시 만들 필요가 없습니다.

날짜순 로그를 다섯 가지 글 구조로 바꿨습니다

write-post-mod의 중심은 모든 작업을 하나의 DEVLOG 형식에 넣지 않는 것입니다. 결론이 무엇인지 먼저 보고, 그 결론에 맞는 글 구조를 선택합니다.

[Image blocked: 작업 기록의 글 유형 선택 흐름]

ALT

한국어 흐름도

문제 해결형은 결론과 원인, 다음 판단을 앞에 둡니다. 순차 구축형은 결과물과 단계별 완료 기준을 중심에 둡니다. 비교·선택형은 후보와 선택 기준을, 자동화·업무개선형은 Before/After 효과를, 운영 회고형은 운영 기간과 실제 문제를 중심으로 씁니다.

이 분류는 제목을 정하기 전에도 필요합니다. 원래 목표가 무엇이었는지, 선택이 처음부터 정해진 일이었는지, 실패한 대상은 버린 것인지 역할을 바꾼 것인지가 정리되지 않으면 제목과 결과 표, 마무리가 서로 다른 이야기를 할 수 있습니다.

같은 기록을 두 형식으로 써봤습니다

차이는 규칙 설명만으로는 잘 보이지 않아서, 같은 사실을 write-post와 write-post-mod 형식으로 각각 축약해 작성해 봤습니다. 입력으로 사용한 사실은 다음 네 가지입니다.

• 공개 write-post를 기준점으로 삼았다.

• write-post-mod에는 소스 선택, 다섯 유형 판정, 결론 우선 구조, 비식별·문체·다이어그램 규칙을 추가했다.

• Hermes write-post에는 Hermes 세션 스캔과 세션 파싱 가이드를 추가했다.

• 세션 수집·파싱과 글의 편집 규칙은 역할을 분리했다.

소스에 신뢰할 수 있는 날짜가 없으므로, 아래 write-post 축약본에서는 원래의 날짜별 Day N 표기를 임의로 만들지 않았습니다. 비교의 대상은 세션 파서의 실행 결과가 아니라, 같은 기록을 어떤 순서와 표현으로 보여주는지입니다.

write-post 방식으로 작성한 축약본

# write-post 확장 - 개발 로그

AI 코딩 도구와 함께 진행한 개발 작업 기록입니다.

---

### 1. write-post와 write-post-mod의 역할 정리

```
공개 write-post와 Hermes의 write-post, write-post-mod의 수정·추가 내용을 사례글로 정리하고 싶다.
```

**Claude Code 작업:**
- 공개 `write-post`를 기준점으로 확인
- `write-post-mod`에 소스 선택, 글 유형 판정, 결론 우선 구조를 추가
- AI 응답 전문 비노출, 비식별 처리, 문체, Mermaid 규칙을 추가

---

### 2. Hermes 세션 처리 범위 추가

```
Hermes write-post에는 Hermes 세션 스캔과 파싱 가이드가 추가됐다.
```

**Hermes 작업:**
- Hermes 세션 스캔 가이드 추가
- Hermes 환경의 세션 파싱 가이드 추가
- 세션 수집 기능과 글쓰기 규칙의 역할 분리

---

## 기술 스택

- **문서 형식**: Markdown
- **다이어그램**: Mermaid

이 형식은 요청 원문과 수행 내용을 시간순 작업 단위로 남기기에 적합합니다. 다만 첫 화면에서 독자가 “그래서 무엇이 달라졌는지”를 파악하려면 두 작업 항목을 모두 읽어야 합니다.

write-post-mod 방식으로 작성한 축약본

# 기존 write-post는 유지하고 결론 우선 사례글 흐름만 보완한 방법

공개 `write-post`의 세션 수집·파싱 흐름은 유지하고, 읽는 사람이 결과와 판단 기준을 먼저 볼 수 있도록 별도 보완 규칙을 만들었다.

---

# 한눈에 보기

| | 내용 |
|---|---|
| 목표 | 기존 수집 기능을 유지하면서 사례글 구조를 보완한다. |
| 결과물 | 소스 선택, 다섯 유형 판정, 결론 우선 구조를 담은 `write-post-mod`. |
| Hermes 확장 | Hermes `write-post`에 Hermes 세션 스캔·파싱 가이드를 추가. |
| 핵심 판단 | 세션 수집·파싱과 글쓰기 규칙을 분리한다. |

---

# 결론

## 결론 1. 수집 기능은 원본에 남겼다
세션 스캔과 도구별 파싱을 다시 구현하지 않아, 수집 규칙과 편집 규칙의 수정 범위를 분리했다.

## 결론 2. 날짜순 기록은 다섯 유형의 글 구조로 바꿨다
문제 해결·구축·비교·자동화·운영 회고 중 결과에 맞는 구조를 먼저 고른다.

## 결론 3. Hermes에서는 세션 입력 범위를 넓혔다
Hermes 세션 스캔과 파싱 가이드를 추가해, Hermes 기록도 같은 문서 흐름의 입력으로 다룬다.

이 형식은 첫 화면에서 결과물, 역할 분리, Hermes 확장을 먼저 보여주고, 이후에 필요한 사람만 각 판단의 근거로 내려가게 합니다. 원문의 사용자 요청은 공개 글에서는 그대로 복사하지 않고, 의도와 정보량을 유지해 인용문으로 다듬습니다.

비교 결과, 두 형식 중 하나가 항상 낫다는 뜻은 아닙니다. 작업 재현과 세부 요청 보존이 목적이면 write-post의 시간순 기록이 맞고, 사례글에서 결과와 판단을 빠르게 전달해야 하면 write-post-mod의 결론 우선 구조가 맞습니다.

공개용 글에 남길 것과 뺄 것을 정했습니다

사례글에는 AI 응답 전문을 넣지 않고, 결과를 바꾼 실제 요청을 정리해 인용합니다. 다만 실제로 보내지 않은 요청을 새로 만들거나, 당시의 질문을 더 전문적으로 보이게 바꾸지는 않습니다.

날짜, 장비·부품 모델명, 도구명, 회사명·계정·키처럼 공개에 필요하지 않은 정보는 기본적으로 제거하거나 일반화합니다. 반대로 기술 명령어·로그·파라미터는 DEVLOG에서는 재현 가치가 있으므로 남길 수 있습니다.

문체도 나눴습니다. 본문에서는 과장 형용사와 훈계조 표현을 줄이고, 제목과 소제목에서는 독자가 얻을 결과가 드러나게 합니다. 다이어그램은 산문을 박스에 다시 옮기는 용도가 아니라, 여러 단계의 흐름이나 분기 기준을 한 화면에 모을 필요가 있을 때만 넣습니다.

공개용 문서에서는 작성자 식별자와 사용자 홈 경로를 남기지 말아야 한다.

이 요청을 반영하면서, 스킬의 실제 위치를 그대로 적는 대신 ~/.claude/...나 일반화된 스킬 디렉터리 표현으로 바꾸는 기준도 정리했습니다.

그래서 남은 게 뭐냐면

남은 것은 또 하나의 세션 파서가 아니라, 기록을 판단 가능한 글로 바꾸는 편집 흐름입니다.

• 세션을 자동으로 스캔할지, 사용자가 지정한 파일을 읽을지 먼저 나눕니다.

• 사례의 결과를 다섯 유형 중 하나로 분류합니다.

• 유형과 전제를 사용자에게 확인한 뒤에 문서 구조를 확정합니다.

• 실제 요청은 필요한 범위에서 다듬어 인용하고, AI 응답 전문과 식별 가능한 정보는 제외합니다.

• 수정이 들어오면 같은 표현과 연결 문장을 문서 전체에서 다시 확인합니다.

원본 기능을 보존한 채 별도 스킬로 보완했기 때문에, 세션 수집·파싱 규칙과 글쓰기·편집 규칙을 독립적으로 다룰 수 있게 됐습니다.

결과 정리

결과적으로 세션을 수집하는 기준과 글을 편집하는 기준이 분리됐습니다. 원본을 버리지 않고 보완할 수 있었고, Hermes에서 다루는 세션 범위도 확장할 수 있었습니다.

AI를 이렇게 쓰니 좋았습니다

먼저 책임을 나누고, 그다음에 글의 구조를 고르게 했습니다.

AI에게 스킬을 확장해 달라고 요청할 때 기능 목록만 늘어놓으면, 수집·파싱·문체·공개 범위 같은 서로 다른 층위가 한 문서 안에서 섞일 수 있습니다. 이번에는 원본이 이미 맡는 일과 새로 필요한 일을 먼저 나눴습니다.

그다음 결과의 성격을 다섯 유형으로 판정하게 하니, 날짜순 로그를 그대로 옮기지 않고 독자가 처음에 봐야 할 내용을 선택할 수 있었습니다. 이 방식은 실제 세션 수집 기능을 건드리지 않고도 사례글의 읽는 순서를 바꿀 수 있다는 점에서 유용했습니다.

이건 하지 마세요

같은 역할을 하는 파서와 글쓰기 규칙을 여러 곳에 복제하지 않는 편이 낫습니다.

write-post-mod가 원본의 세션 스캔·도구별 파싱을 다시 구현하면, 원본의 저장 형식이나 환경별 경로가 바뀔 때 두 곳을 함께 고쳐야 합니다. 소스가 직접 지정됐는데도 자동 세션 스캔을 돌리면 관련 없는 기록을 찾는 시간이 늘어날 수도 있습니다.

또한 제목이나 도입부의 전제만 바꾸고 결과 표·마무리·다이어그램을 그대로 두면 같은 작업을 서로 다르게 설명하게 됩니다. 전제가 바뀌면 관련 문장을 함께 다시 확인하는 절차가 필요합니다.

앞으로의 계획

현재 규칙을 실제 사례글에 계속 적용하고, 사용 중에 나온 피드백은 write-post-mod에 반영할 계획입니다. 유형별 구조가 실제 사례에서 충분히 읽히는지 확인하면서, 필요한 경우 절 구성과 다이어그램 사용 기준을 조정합니다.

그대로 쓰셔도 되는 프롬프트

기존 스킬의 책임을 나누기

기존 스킬의 역할을 분석해 주세요. 세션 수집·파싱처럼 유지해야 할 기능과, 문서 구조·문체처럼 별도 보완할 기능을 나눠 주세요. 같은 기능을 새 스킬에 중복 구현하지 않도록 의존 관계도 함께 제안해 주세요.

사례글 유형 고르기

아래 작업 기록을 읽고, 문제 해결·순차 구축·비교 선택·자동화 업무개선·운영 회고 중 가장 적합한 글 구조를 하나 제안해 주세요. 원래 목표, 결정 순서, 결과를 한 문장으로 요약하고 확인이 필요한 전제도 함께 적어 주세요.

결론 우선 DEVLOG 만들기

이 작업 기록을 날짜순 나열 대신 결론 우선 DEVLOG로 정리해 주세요. 먼저 한눈에 보기와 핵심 시사점을 두고, 세부 내용은 각 결론의 근거로 연결해 주세요. 기록에 없는 동기·경력·시간은 추측하지 말아 주세요.

공개용 사례글 비식별 처리하기

이 DEVLOG를 공개용 사례글로 바꿔 주세요. AI 응답 전문, 작성자 식별자, 사용자 홈 경로, 계정·키·회사명은 제외하거나 일반화해 주세요. 실제로 보낸 요청만 의도와 정보량을 유지해 다듬어 인용하고, 사례에 없는 일반론은 추가하지 말아 주세요.