write-post

name	write-post
description	DEVLOG 생성부터 AI 활용 사례 게시글 작성까지 한 번에 진행합니다. AI 코딩 도구의 대화 세션을 자동으로 파싱하여 개발 로그를 만들고, 비개발자 대상 사례글까지 작성합니다.

AI 활용 사례 게시글 작성

DEVLOG 생성부터 사례 게시글 작성까지 한 번에 진행합니다.

---

Phase 1: DEVLOG 생성

사용 가능한 모든 AI 코딩 도구의 세션을 프로젝트 단위로 스캔하고, 통합 개발 로그 문서를 자동 생성합니다.

프로젝트 세션 스캔 (Project Session Scan)

스킬 실행 시 아래 모든 도구의 세션 경로를 스캔하여 현재 프로젝트와 매칭되는 세션을 수집합니다:

1. Claude Code: ~/.claude/projects/ 에서 현재 프로젝트 경로와 매칭되는 폴더 탐색
2. OpenCode: MCP session_list 또는 ~/.local/share/opencode/storage/에서 directory 필드로 매칭
3. Antigravity: ~/.gemini/antigravity/brain/에서 아티팩트 내 프로젝트 경로 매칭
4. Codex CLI: ~/.codex/sessions/에서 세션 파일 내 작업 디렉토리 매칭
5. Gemini CLI: ~/.gemini/tmp/에서 프로젝트 해시 매칭

스캔 결과 처리:

• 매칭되는 세션이 있는 도구들의 목록을 사용자에게 보여주기: "다음 도구에서 세션을 찾았습니다: Claude Code (3개 세션), OpenCode (2개 세션)"
• 매칭되는 세션이 하나도 없으면: "현재 프로젝트와 매칭되는 세션을 찾을 수 없습니다. 프로젝트 경로를 확인해주세요."
• 특정 도구의 세션 경로가 존재하지 않으면 해당 도구는 건너뜀 (에러 표시 X)

파싱 사전 검증 (필수)

세션 파일을 대량 파싱하기 전에 반드시 다음 사전 검증을 수행하세요:

1. 셸 환경 확인: 첫 번째 명령 실행 전 echo $SHELL 또는 echo $0으로 현재 셸 확인. Windows에서 Git Bash가 기본이므로 Unix 명령어(ls, cat, grep) 사용.

2. 파일 1개 샘플링: 전체 파싱 전에 대상 파일 1개를 먼저 읽어 구조 확인. JSONL의 경우 첫 줄을 파싱하여 필드명(type, content 등)과 값(user/assistant — human/ai 아님)을 검증.

3. 경로 표기법 통일:

   환경	경로 형식	예시
   Git Bash 셸	/c/Users/...	ls /c/Users/name/.claude/
   Python 스크립트	C:/Users/...	glob.glob('C:/Users/name/.claude/**')
   PowerShell/CMD	C:\Users\...	dir C:\Users\name\.claude\

   Python에서는 항상 os.path.expanduser('~') 또는 C:/ 형식 사용.

4. 인코딩 설정: Python 실행 시 PYTHONIOENCODING=utf-8 환경변수 설정. Windows 기본 인코딩(cp949)으로 인한 UnicodeEncodeError 방지.

5. 에이전트 위임 전 검증: 백그라운드 에이전트에게 파싱 로직을 위임할 때, 위 1-4 검증을 완료한 로직만 전달. 검증되지 않은 가정(필드명, 경로 형식)을 에이전트에게 넘기지 마세요.

출력 포맷 (반드시 이 형식으로 생성)

# {프로젝트명} - 개발 로그

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

---

## YYYY-MM-DD (Day N)

### 1. 작업 제목 (간결하게)

사용자가 입력한 원문 그대로

**{해당 작업의 도구명} 작업:**
- 수행한 작업 설명
- `파일경로` - 파일 설명
- 생성/수정된 파일들 bullet point로 나열

---

### 2. 다음 작업 제목

사용자 요청

**{해당 작업의 도구명} 작업:**
- 작업 내용

---

## 커밋 히스토리

| 날짜 | 커밋 | 설명 |
|------|------|------|
| MM/DD | `해시` | 커밋 메시지 |

---

## 기술 스택

- **Frontend**: 사용된 기술
- **Backend**: 사용된 기술
- **Deployment**: 배포 환경

---

## 주요 기능

1. **기능명**
   - 세부 설명

멀티 도구 참고: 여러 도구의 세션이 수집된 경우, 각 작업 섹션의 **{도구명} 작업:** 헤더에 해당 작업을 수행한 실제 도구명이 표시됩니다. 같은 날짜에 여러 도구를 사용한 경우 도구별로 구분하여 기록합니다.

실행 방법

기존 DEVLOG가 있는 경우

프로젝트에 DEVLOG.md 또는 DEVLOG_*.md 파일이 있으면, 사용자에게 선택지를 제시:

기존 DEVLOG가 있습니다. 어떻게 진행할까요?

1. 기존 DEVLOG.md에 이어쓰기 (추천 — 마지막 기록: {마지막 날짜})
2. 새 DEVLOG 생성 (DEVLOG_{제목슬러그}.md — 세션별 파일 분리)
3. 처음부터 다시 생성 (기존 파일 덮어쓰기 — 모든 세션 재스캔)

선택별 동작:

• 1. 이어쓰기: 기존 파일의 마지막 날짜/작업 번호 확인 → 그 이후 세션만 파싱 → 이어서 추가 (Day/작업 번호 연속, 커밋 히스토리도 추가분만)
• 2. 새 파일: 사용자에게 제목 슬러그를 물어 DEVLOG_{슬러그}.md 생성 (예: DEVLOG_인증모듈.md). 모든 세션 파싱하여 새 파일에 작성
• 3. 덮어쓰기: "기존 내용이 사라집니다. 정말 덮어쓸까요?" 확인 후, 모든 세션을 재스캔하여 기존 파일 교체

기존 DEVLOG가 없는 경우 (첫 실행)

1. 모든 감지된 도구의 세션 파일을 전체 파싱
2. DEVLOG.md 파일을 새로 생성

도구별 세션 파싱 가이드

1. Claude Code

• 프로젝트 매칭: ~/.claude/projects/ 폴더에서 현재 프로젝트의 절대경로를 -로 치환한 폴더명 탐색. 예: /Users/dahye/DEV/my-app → ~/.claude/projects/-Users-dahye-DEV-my-app/
• 세션 위치: ~/.claude/projects/{프로젝트경로를-로치환}/ 폴더
• 파일 형식: .jsonl 파일들 (agent-*.jsonl 제외)
• 파싱 방법: type: 'user' → 사용자 요청, type: 'assistant' → Claude 응답

Windows 참고:

• Claude Code는 Windows에서 Git Bash를 셸로 사용합니다. process.platform이 win32로 보고되더라도 bash 문법을 사용하세요 (CMD/PowerShell 문법 사용 금지).
• 프로젝트 경로 매칭: Windows에서의 폴더명 패턴이 다를 수 있습니다. 매칭이 안 되면 ls ~/.claude/projects/ 실행 후 현재 프로젝트에 해당하는 폴더를 직접 찾으세요.
• Python으로 파싱할 때: Git Bash 경로(/c/Users/...) 대신 Python 네이티브 경로(C:/Users/...) 사용. PYTHONIOENCODING=utf-8 환경변수 필수.

Claude Code 기획 Q&A 추출 (AskUserQuestion 도구)

Claude Code에서 기획 모드(Prometheus 등)가 사용자에게 선택지를 제시할 때 AskUserQuestion 도구를 사용합니다. 이 도구의 질문과 사용자 응답은 JSONL 파일 안에 인라인으로 저장되므로 별도 보충 스캔이 필요 없습니다. 단, 기존 파싱 로직에서 이 도구를 인식하도록 해야 합니다.

감지 방법: JSONL 파싱 시 type: "assistant" 메시지의 content 배열에서 type == "tool_use" AND name == "AskUserQuestion" 항목을 찾습니다.

질문 추출 (assistant 메시지 내 tool_use):

{
  "type": "tool_use",
  "id": "toolu_...",
  "name": "AskUserQuestion",
  "input": {
    "questions": [
      {
        "question": "어떤 기능을 포함할까요?",
        "header": "기능 선택",
        "options": [
          { "label": "기능A", "description": "설명..." },
          { "label": "기능B", "description": "설명..." }
        ],
        "multiSelect": false
      }
    ]
  }
}

응답 추출 (다음 user 메시지의 tool_result):

{
  "type": "user",
  "message": {
    "role": "user",
    "content": [
      {
        "type": "tool_result",
        "content": "User has answered your questions: \"어떤 기능을 포함할까요?\"=\"기능A\"...",
        "tool_use_id": "toolu_..."
      }
    ]
  },
  "toolUseResult": {
    "questions": [...],
    "answers": {
      "어떤 기능을 포함할까요?": "기능A"
    }
  }
}

추출 우선순위:

1. toolUseResult.answers — 질문→답변 매핑이 구조화되어 있어 가장 정확
2. tool_result.content — "Q"="A" 형식의 문자열. toolUseResult가 없을 때 폴백

DEVLOG 반영 방법:

• 기획 Q&A는 별도 섹션 또는 작업 흐름 내에 대화형으로 기록
• 질문은 코드블록으로, 사용자 선택은 인라인 또는 불릿으로 표시
• 선택지 전체 목록과 사용자가 고른 항목을 구분하여 보여주면 기획 의도가 명확해짐

적용 시점:

• Claude Code JSONL 파싱 중 AskUserQuestion 도구 호출이 감지된 경우
• 기획 세션(feature 선정, 기술 스택 결정, 이름 선정 등)이 DEVLOG의 핵심 내용인 경우

2. OpenCode

• 프로젝트 매칭: MCP session_list 사용 시 현재 프로젝트 세션 자동 필터링. Raw 파싱 시 ses_*.json의 directory 필드가 현재 프로젝트 경로와 일치하는지 확인.
• 1차 방법 (MCP 도구 사용 - 권장):
  • session_list → 현재 프로젝트의 세션 목록 조회
  • session_read(session_id) → 세션 메시지 읽기 (role, content 포함)
  • session_search(query) → 키워드로 세션 내 검색
• 2차 방법 (MCP 도구 없을 때 - Raw 파일 파싱):
  • 세션 위치: ~/.local/share/opencode/storage/
  • 프로젝트 매칭: storage/session/{project-hash}/ 폴더 내 ses_*.json의 directory 필드 확인
  • 메시지 구조: message/ses_*/msg_*.json (role 필드) → part/msg_*/prt_*.json (text 필드)
  • Windows: %USERPROFILE%\.local\share\opencode\storage\

Windows: %USERPROFILE%\.local\share\opencode\storage\ 경로 사용. Python에서는 os.path.expanduser('~') 활용.

OpenCode Question 도구 응답 추출 (필수 보충 단계)

문제: session_read MCP는 [tool: question]이라고만 표시하고, 실제로 어떤 질문이 제시되었는지와 사용자가 어떤 선택지를 골랐는지를 노출하지 않습니다. 특히 Prometheus(기획) 에이전트 세션에서는 질문-응답(Q&A) 흐름이 기획 과정의 핵심이므로 반드시 추출해야 합니다.

3단계 저장소 구조 이해:

Session (ses_*.json)          ← session_list/session_read로 접근 가능
  └── Message (msg_*.json)    ← session_read로 일부 접근 가능
       └── Part (prt_*.json)  ← MCP로 접근 불가, Raw 파일만 접근 가능

추출 방법:

1차 방법 (MCP session_read)으로 세션을 읽은 후, [tool: question]이 감지되면 반드시 아래 보충 스캔을 수행:

1. 대상 Part 파일 탐색: ~/.local/share/opencode/storage/part/msg_*/prt_*.json 경로에서 해당 세션의 메시지에 속하는 Part 파일들을 탐색
2. Question 도구 Part 필터링: Part JSON에서 다음 조건을 만족하는 파일 선별:
   • type == "tool" (도구 호출 Part)
   • tool == "question" (Question 도구)
3. 질문 내용 추출: state.input.questions 배열에서 각 질문의 question, options[].label, options[].description 추출
4. 사용자 응답 추출: state.output 문자열에서 사용자 답변 파싱. 형식: User has answered your questions: "질문1"="답변1", "질문2"="답변2"

Part JSON 구조 예시:

{
  "id": "prt_...",
  "type": "tool",
  "tool": "question",
  "state": {
    "status": "completed",
    "input": {
      "questions": [
        {
          "question": "어떤 기능을 포함할까요?",
          "header": "기능 선택",
          "multiple": true,
          "options": [
            { "label": "기능A", "description": "설명..." },
            { "label": "기능B", "description": "설명..." }
          ]
        }
      ]
    },
    "output": "User has answered your questions: \"어떤 기능을 포함할까요?\"=\"기능A, 기능B\""
  }
}

DEVLOG 반영 방법:

• 기획 Q&A는 별도 섹션 또는 작업 흐름 내에 대화형으로 기록
• 질문은 코드블록으로, 사용자 선택은 인라인 또는 불릿으로 표시
• 선택지 전체 목록과 사용자가 고른 항목을 구분하여 보여주면 기획 의도가 명확해짐

적용 시점:

• OpenCode 세션이 감지될 때마다 (특히 Prometheus/planning 에이전트 세션)
• session_read 결과에 [tool: question]이 1개 이상 포함된 경우
• 기획 과정(feature 선정, 기술 스택 결정, 이름 선정 등)이 DEVLOG의 핵심 내용인 경우

3. Codex CLI

• 프로젝트 매칭 (best-effort): JSONL 파일 내 cwd 또는 working_directory 필드가 현재 프로젝트 경로와 일치하는지 확인. 해당 필드가 없으면 사용자에게 "이 세션이 현재 프로젝트의 것인가요?" 질문.
• 세션 위치: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
• 파일 형식: JSONL (사용자 메시지, AI 응답, 도구 호출, 파일 변경 포함)
• 탐색 방법: 날짜별 폴더 구조이므로 최신 날짜부터 역순 탐색
• Windows: %USERPROFILE%\.codex\sessions\

Windows: %USERPROFILE%\.codex\sessions\ 경로 사용.

4. Gemini CLI

• 프로젝트 매칭 (best-effort): ~/.gemini/tmp/ 하위 해시 디렉토리들의 채팅 파일 내에서 현재 프로젝트 경로가 언급되는지 확인. 매칭이 불확실하면 사용자에게 확인 질문.
• 자동 저장: ~/.gemini/tmp/<project_hash>/chats/
• 수동 저장: ~/.gemini/tmp/<project_hash>/checkpoints/ (/chat save <tag>)
• 파일 형식: JSON (role: user/model, parts: content)
• Windows: %USERPROFILE%\.gemini\tmp\

Windows: %USERPROFILE%\.gemini\tmp\ 경로 사용.

5. Antigravity

• 현재 스킬이 Antigravity 내부에서 실행되는 경우 (1차 방법 — 권장):
  • Antigravity 에이전트는 과거 대화를 자체 검색할 수 있습니다
  • "이 프로젝트에서 진행한 과거 대화들을 검색해줘", "지난주에 작업한 내용을 찾아줘" 등으로 과거 세션을 직접 참조
  • 역할 분리 (필수): 검색 결과에서 사용자가 보낸 메시지(요청, 질문, 지시)와 에이전트 응답(작업 설명, 코드, 결과)을 분리하여 반환
    • 사용자 메시지 → DEVLOG의 코드블록 (원문 그대로)
    • 에이전트 응답 → 핵심 작업 내용만 요약하여 불릿 포인트로 정리 (전문 출력 금지)
    • 날짜 정보도 함께 추출 (Day N 그룹핑에 필요)
  • 제외 대상: AI 응답 전문(verbatim), 도구 호출 결과/실행 로그, 에이전트가 사용자에게 묻는 확인 질문
  • 역할 구분 불명확 시: 질문/요청/지시 형태의 문장만 사용자 요청으로 추출
  • brain/ 폴더의 마크다운 아티팩트는 작업 맥락 파악용 참고자료로만 활용 (AI 생성 요약이므로 DEVLOG의 사용자 요청 원문 소스로는 사용하지 않음)
  • 이 방식은 .pb 암호화 파일의 내용까지 접근 가능하므로 가장 완전한 대화 기록을 얻을 수 있습니다
• 다른 도구에서 Antigravity 세션을 파싱하는 경우 (2차 방법 — 외부 접근):
  • 프로젝트 매칭: ~/.gemini/antigravity/code_tracker/active/ 에서 현재 프로젝트명이 포함된 디렉토리 탐색. 또는 brain/*/task.md.resolved 파일 내 file:/// 링크에서 현재 프로젝트 경로 매칭. 매칭된 conversation-id의 아티팩트만 파싱.
  • 세션 위치: ~/.gemini/antigravity/brain/<conversation-id>/
  • 파싱 대상: 마크다운 아티팩트 (이미지 등 바이너리 제외)
  • 우선순위: walkthrough.md → implementation_plan.md → task.md 순으로 탐색
  • 버전 관리: .resolved, .resolved.N 파일 중 가장 최신 버전 사용
  • 주의: conversations/ 폴더의 .pb 파일은 암호화되어 있어 읽기 불가 — 이 방법에서는 brain/ 마크다운만 활용 가능
  • 사용자 요청 역추론: brain/ 아티팩트는 모두 AI 생성 문서이므로 사용자 원문이 없음. 아티팩트의 작업 내용에서 사용자가 어떤 요청을 했을지 역으로 추론하여, [추정] 표시와 함께 코드블록에 기록. 예: walkthrough.md에 "인증 모듈 구현" 내용이 있으면 → DEVLOG에 [추정] 인증 모듈을 구현해줘로 기록. 이는 2차 방법에서만 적용되는 워크어라운드이며, 원문 접근이 가능한 1차 방법에서는 불필요.

정리 규칙

1. 공통 필터링:

   • Claude Code: <ide_opened_file> 등 IDE 메타데이터 제외
   • OpenCode: [search-mode], <session-context> 등 시스템 메시지 제외
   • Codex CLI: 토큰 사용 통계, 내부 도구 호출 세부사항 제외
   • Gemini CLI: 도구 실행 로그 제외
   • Antigravity: .metadata.json, .resolved 파일 자체는 제외 (본문만 파싱)
   • Antigravity (1차 방법): AI 응답 전문 제외 — 에이전트 작업 내용은 핵심만 요약하여 불릿 포인트로 정리
   • 매우 짧은 응답(50자 미만)은 제외

2. 구조화:

   • 날짜별로 그룹핑 (Day 1, Day 2...)
   • 여러 도구의 세션을 날짜순으로 병합
   • 같은 날짜에 여러 도구를 사용한 경우 도구별로 구분하여 기록
   • 각 작업 섹션의 **{도구명} 작업:** 헤더에 해당 도구의 실제 이름 표시
   • 관련 작업끼리 하나의 섹션으로 묶기
   • 사용자 요청은 코드블록으로, AI 작업은 bullet point로

3. 사용자 요청 정리 규칙 (중요):

   • 모든 의미있는 사용자 요청을 빠짐없이 포함
   • 짧은 질문이라도 맥락이 있으면 맥락과 함께 기록
   • 연속된 대화는 하나의 섹션으로 묶되, 핵심 요청들은 모두 포함
   • 에러/문제 해결 과정도 상세히 기록 (어떤 에러 → 어떻게 해결)
   • 예시 - 맥락 없이 질문만 (X): 근데 일부만 되고 다 안채워지는데 이유가 뭐야?
   • 예시 - 맥락과 함께 (O): [Airtable 필드 자동 업데이트 중] 근데 일부만 되고 다 안채워지는데 이유가 뭐야? 개선해

4. 마지막에 추가:

   • git log --oneline으로 커밋 히스토리 테이블 생성
   • 사용된 기술 스택 정리
   • 구현된 주요 기능 요약

---

Phase 2: DEVLOG 확인

DEVLOG.md 생성이 완료되면:

1. 사용자에게 "DEVLOG 확인하셨나요? 수정할 부분 있으면 말씀해주세요" 질문
2. 수정 요청이 있으면 반영
3. 사용자가 확인 완료하면 Phase 3로 진행

수정 요청 예시

사용자가 요청할 수 있는 수정 유형:

표현 다듬기

• 내 요청 순화: "이거 왜 안돼 ㅡㅡ" → "특정 상황에서 오류가 발생했다"
• AI 작업 비개발자화: "API 라우트 생성" → "서버와 통신하는 경로 설정"

구조 변경

• 그룹핑 변경: 날짜별(Day 1, Day 2) → 작업 범위별(데이터 연동, UI 구현)
• 작업 합치기: 잡다한 설정 5개 → "초기 환경 설정" 하나로

내용 보강

• 맥락 추가: "대시보드 만들어줘" → "매주 3시간씩 수동으로 하던 리포트를 자동화하고 싶어서 대시보드를 요청했다"
• 배운점 추가: "Claude가 컴포넌트를 분리해서 만들었는데, 이렇게 하면 나중에 재사용이 쉽다는 걸 알게 됐다"
• 에러 해결 상세화: "안됨" → "환경변수 설정이 빠져서 발생한 문제였고, .env 파일 추가로 해결"

제외 요청

• 민감한 내용: 회사명, API 키 관련 작업, 실수 커밋 등 제외

---

Phase 3: AI 활용 사례 게시글 작성

DEVLOG.md를 기반으로 비개발자 대상 AI 활용 사례 게시글을 작성합니다.

주의: Phase 3은 사용자와의 대화형 프로세스입니다.

• Phase 3의 각 단계(맥락 질문, 제목 선정, 피드백)를 todo/task 목록에 등록하지 마세요
• 매 단계마다 사용자 답변이 필요하므로 자동 진행이 불가합니다
• todo 기반 자동 진행 훅이 반복 발동되는 것을 방지하기 위함입니다

프로세스

1단계: DEVLOG 분석

• DEVLOG.md 파일을 읽고 전체 작업 흐름 파악
• 주요 작업, 사용한 도구, 결과물 정리
• 사용자에게 파악한 내용 요약해서 확인받기

2단계: 맥락 질문 (한 번에 하나씩)

다음 항목들에 대해 한 번에 하나씩 질문하며 충분한 맥락 수집:

배경 (Before)

• 문제 상황 + 시작 계기: 뭐가 불편했고, 왜 이 작업을 시작했나요? (구체적인 상황, 소요 시간, 더 이상 미룰 수 없었던 이유)

과정 (During)

• 작업 하이라이트: DEVLOG에 기록된 작업들 중 특히 강조하고 싶은 작업이 있나요?
• 인상적인 순간: AI와 협업하면서 "오!" 했던 순간이 있나요?
• 막혔던 부분: 작업 중 어려웠던 순간이 있나요? (AI가 잘 못 이해한 것 / 내가 뭘 요청해야 할지 몰랐던 것 / 어떻게 해결했는지)

결과 (After)

• 결과 임팩트: 결과물로 인해 구체적으로 뭐가 달라졌나요? (시간 절약, 효율 등)

공유 (For Readers)

• 타겟 독자: 이 글을 읽을 사람들은 누구인가요? (직군, 상황 등)
• 핵심 팁: 다른 사람에게 꼭 알려주고 싶은 AI 활용 팁이 있나요?
• 향후 계획: 이 결과물을 더 발전시킬 계획이 있나요?

질문 규칙:

• 반드시 한 번에 하나씩만 질문
• 각 질문 시 DEVLOG 기반 추천 답변 3개 내외 제시
• 사용자가 "응", "그거로 해" 등으로 간단히 수락 가능
• 답변이 모호하면 꼬리질문 (역시 하나씩)
• 향후 계획이 없다고 하면 2-3가지 제안해서 시야 넓혀주기

3단계: 제목 선정

초안 작성 직전, 후킹 가능한 제목 3-4개를 추천하고 사용자에게 선택받기:

제목 추천 기준:

• 비개발자가 클릭하고 싶은 제목
• 구체적인 임팩트 포함 (시간, 숫자 등)
• 결과물이나 도구를 명확하게
• "~했다", "~만들었다" 같은 완료형 표현

예시:

제목 추천드려요. 어떤 게 좋을까요?

1. "비개발자가 Claude Code로 오전 2시간 만에 매출 대시보드를 만들었다"
2. "스프레드시트 노가다 끝! AI로 3,500개 데이터 자동 분류한 후기"
3. "개발자 없이 Airtable 대시보드 만든 비개발자의 AI 협업기"
4. (직접 입력하기)

사용자가 선택하거나 수정 요청하면 반영

4단계: 초안 작성

아래 템플릿에 맞춰 AI_CASE_STUDY.md 파일로 작성

5단계: 피드백 및 수정

• 초안 작성 후 사용자에게 수정할 부분 질문
• 피드백 반영하여 최종 수정

---

게시글 템플릿 및 작성 가이드

목차

• 게시글 템플릿
• 작성 시 주의사항
• 마무리 안내

---

게시글 템플릿

# [사용한 도구] 제목 - 임팩트 포함

## 📝 한줄 요약
(뭘 했고, 어떤 효과가 있었는지 1-2문장)

**바쁘시면 이것만 읽어도 돼요:**
- 사용한 도구와 목표 (예: OpenCode로 ~~~ 자동화 구축, 수동 N분 → N분)
- 과정 중 깨달은 점 (예: 1개 처리와 배치 처리는 다른 전략 필요)
- 핵심 해결 방법 (예: API 없이 브라우저 자동화로 해결)
- 특별히 인상적이었던 순간 (예: AI가 엣지 케이스를 먼저 감지)
- 확장성/재사용성 (예: 다른 서비스도 파일 하나만 추가하면 확장 가능)
- 배운 교훈 (예: AI 멈춰있으면 그냥 물어보기)

## 🎯 이런 분들께 도움돼요
- 타겟 독자 1
- 타겟 독자 2
- 타겟 독자 3

## 😫 문제 상황 (Before)
(기존에 어떤 불편함이 있었는지, 구체적인 상황 묘사)
(시간/노력이 얼마나 들었는지)
(이 작업을 시작하게 된 구체적인 계기, 왜 더 이상 미룰 수 없었는지)

## 🛠️ 사용한 도구
- **도구명**: (예: Claude Code, OpenCode — 여러 도구 사용 시 모두 나열)
- **모델**: (예: Claude Opus 4.5)
- **특이사항**: (있다면)

---

## 🔧 작업 과정

DEVLOG 기반으로 실제 작업 순서대로 **스토리텔링** 형식으로 풀어씁니다.
딱딱한 "상황-요청-결과" 구조 대신, 자연스럽게 읽히는 이야기처럼 작성합니다.

### [작업 제목] - 임팩트나 느낌을 담은 소제목

(왜 이 작업을 하게 됐는지 상황 설명으로 시작)

(어떻게 요청했는지 자연스럽게 연결)

실제 사용자 질문/요청

(AI가 뭘 했는지, 결과가 어땠는지 이어서 서술)

(이 과정에서 느낀 점이나 인사이트)

---

### [다음 작업 제목]

(이전 결과를 보고 뭐가 더 필요했는지로 시작)

사용자 요청

(결과와 느낀 점)

---

### (필요한 만큼 반복 - 각 섹션은 하나의 에피소드처럼)

---

## ✅ 결과 (After)

### Before vs After
| 항목 | Before | After |
|------|--------|-------|
| 소요 시간 | | |
| 기타 | | |

### 결과물
(스크린샷, 링크 등)

## 💬 이 과정에서 배운 AI 활용 팁

### 효과적이었던 것
1. 팁 1
2. 팁 2

### 이렇게 하면 안 돼요
1. 주의점 1
2. 주의점 2

## 🌍 다른 업무에 적용한다면?
(이 경험을 다른 상황에 적용할 수 있는 아이디어)

## 🚀 앞으로의 계획
(이 결과물을 어떻게 발전시킬 예정인지)
(또는 이번 경험을 바탕으로 도전해보고 싶은 것)

## 📋 재사용 가능한 프롬프트

### 프롬프트 1: (용도)
> 프롬프트 내용
> [수정할 부분]은 본인 상황에 맞게 변경하세요

### 프롬프트 2: (용도)
> 프롬프트 내용

---

작성 시 주의사항

1. 소스코드 제외: 비개발자 대상이므로 프로그래밍 코드(소스코드, 설정 파일, 명령어 등) 사용 금지
2. 사용자 질문은 코드블럭으로: 실제 사용자가 AI에게 보낸 질문/요청은 코드블럭(```)으로 표시. 가독성이 훨씬 좋음
3. 재사용 프롬프트는 인용문으로: 마지막 "재사용 가능한 프롬프트" 섹션의 템플릿은 인용문(>)으로 포함
4. 스크린샷 권장: 결과물, Before/After는 시각적으로 보여주기
5. 구체적 숫자: "많이 절약" 대신 "주 2시간 절약" 같이 구체적으로
6. 실패 사례도 포함: 막혔던 부분과 해결 과정이 오히려 더 도움됨
7. 복붙 가능한 프롬프트: 독자가 바로 사용할 수 있게 템플릿화
8. 스토리텔링으로 작성: 딱딱한 "상황-요청-결과" 나열이 아닌, 자연스럽게 읽히는 이야기처럼
9. 작업 과정은 DEVLOG 기반: DEVLOG의 실제 작업 순서와 맥락을 살려서 에피소드처럼 구성
10. AI 작업 내용은 구체적으로: "코드 작성" 대신 "SDK 설치하고, API 라우트 만들고, 데이터 불러오는 로직까지" 처럼 서술형으로
11. 헤딩2(##)에는 이모지 필수: 각 섹션 제목 앞에 적절한 이모지 추가 (📝, 🎯, 😫, 💡, 🛠️, 🔧, ✅, 💬, 🌍, 🚀, 📋 등)

---

마무리 안내

이미지 추천

글 작성이 완료되면, 독자 이해를 돕기 위해 최소 3개 이미지를 추천:

1. 어떤 섹션에 어떤 이미지가 들어가면 좋을지 (Before/After, 작업 화면, 결과물 등)
2. 섹션 이름으로 안내 (코드 라인 번호 X)

예시:

추천 이미지:

• "문제 상황" 섹션: 기존 방식의 불편함을 보여주는 스크린샷
• "AI와 협업한 과정" 섹션: AI와 대화하며 작업하는 터미널 화면
• "결과" 섹션: 완성된 결과물 전체 화면

게시판 업로드 안내

📋 게시판에 올리는 방법:

1. AI_CASE_STUDY.md 파일에서 마우스 우클릭 → "미리보기 열기" (또는 Cmd+Shift+V)
2. 미리보기 화면에서 Cmd+A로 전체 선택
3. 게시판 작성 화면에 Cmd+V로 붙여넣기
4. 추천된 위치에 이미지 추가
5. 게시!