Lab 01: 결과물 후보와 업무 기준 카드 만들기

• AI로 남기고 싶은 결과물 후보를 정합니다.
• 결과물을 사용할 사람과 현재 수작업 흐름을 적습니다.
• 좋은 결과의 기준과 예외 상황을 업무 기준 카드로 정리합니다.
• 예시 실습을 따라 한 뒤, 내 업무에 적용할 개인 과제를 완성합니다.

핵심 질문: 내가 AI로 무엇을 남길 것인가?

먼저 실제 운영 사례로 결과물 후보를 살펴봅니다.

교육 콘텐츠를 만들기 전에는 준비 단계가 필요합니다. AI, 소프트웨어 개발, 업무 자동화처럼 변화가 빠른 주제에서는 글, 영상, 논문, SNS, 제품 업데이트가 계속 쏟아집니다. 모든 자료를 처음부터 끝까지 읽고 볼 수는 없습니다.

그래서 먼저 흥미로워 보이는 글 링크나 영상 링크를 모읍니다. 그다음 각각을 읽거나 보고 들으며, 교육에 활용할 만한 핵심만 정리합니다. 필요하면 시각화 도표나 이미지 아이디어도 함께 남깁니다. 이렇게 쌓인 후보들은 바로 강의안이 되지는 않지만, 나중에 특정 주제를 설명할 때 교육 콘텐츠로 확장할 수 있는 재료가 됩니다.

수동으로 하면 흐름은 대략 이렇게 됩니다.

1. 여러 채널에서 흥미로운 자료를 발견합니다.
2. 링크를 따로 저장합니다.
3. 자료를 읽거나 영상을 봅니다.
4. 핵심 주장, 활용 포인트, 교육 연결 가능성을 적습니다.
5. TLDR, 카테고리, 키워드, 이미지 아이디어를 정리합니다.
6. 콘텐츠 후보 저장소에 쌓아둡니다.
7. 필요할 때 후보를 꺼내 교육 콘텐츠로 확장합니다.

이 흐름을 결과물 관점으로 바꾸면 “링크를 넣으면 교육 콘텐츠 후보를 정리해 저장하는 워크플로우”가 됩니다. 자동화한 부분은 자료를 발견하는 감각 자체가 아니라, 수집한 자료를 읽고 핵심만 요약해 콘텐츠 후보로 적재하는 반복 구간입니다.

구조는 단순하게 표현하면 Slack -> AI Agent -> Notion 입니다.

Slack에 링크를 올리고 bot을 호출하면 다음 흐름이 실행됩니다.

1. 자료를 읽습니다.
2. TLDR과 섹션 구조를 만듭니다.
3. 이미지가 들어갈 자리를 잡습니다.
4. Notion DB 페이지를 만듭니다.
5. Slack 스레드에 결과를 보고합니다.

이 예시에서 중요한 것은 AI가 요약을 대신한다는 점만이 아닙니다. 사람이 이미 알고 있던 좋은 결과물의 조건을 워크플로우로 옮겼다는 점입니다.

실제 구현은 하나의 큰 프롬프트가 아니라 작은 모듈의 연결로 구성됩니다.

그리고 이 연결에는 신뢰성을 지키는 한 가지 원칙이 있습니다. AI에게 프롬프트만 던져 자유롭게 답하게 하면, 매번 형식과 품질이 달라져 믿고 쓰기 어렵습니다. 그래서 이 워크플로우는 두 가지를 지킵니다. 첫째, AI가 만드는 결과물마저 정해진 JSON 구조로 받습니다. 자유로운 글이 아니라 정해진 칸을 채우게 하는 것입니다. 둘째, 그 외 단계는 최대한 코드와 CLI로 처리합니다. 자료 수집, 검증, 저장, 이미지, 보고는 사람이 정한 규칙대로 매번 똑같이 실행됩니다. 정리하면 AI가 판단하는 구간은 좁게 두고, 그 입력과 출력을 구조화된 데이터로 고정한 뒤, 나머지 넓은 영역을 코드가 책임지는 방식입니다. 아래 표에서 각 단계가 어느 쪽에 속하는지 보면, LLM이 담당하는 구간이 생각보다 좁다는 것을 알 수 있습니다.

일곱 단계 중 AI가 판단하는 단계는 콘텐츠 후보 계획 하나뿐입니다. 나머지 여섯 단계는 사람이 정한 규칙대로 코드와 CLI가 매번 똑같이 실행합니다. 그래서 AI가 흔들려도 워크플로우 전체는 예측 가능한 상태를 유지합니다.

// reference/AGENTS.md
{
  "title_ko": string,
  "author": string,
  "category": string,
  "keywords": string[],
  "summary_ko": string,
  "tldr_bullets": string[5],
  "sections": Array<{
    "h1": string,
    "image_placeholders": string[],
    "toggle_title": string,
    "bullets": string[]
  }>
}

// code/bin/notion_apply.mjs
await notionRequest(notionKey, 'PATCH', `/pages/${pageId}`, {
  properties: {
    Title: buildPropValue(props.Title, titleKo),
    Summary: buildPropValue(props.Summary, summaryKo),
    Author: buildPropValue(props.Author, author),
    Category: buildPropValue(props.Category, category),
    Keywords: buildPropValue(props.Keywords, keywords),
    URL: buildPropValue(props.URL, url),
  }
});

// code/bin/notion_apply.mjs
const blocks = [];
blocks.push(callout('TL;DR'));
for (const b of tldr) blocks.push(bullet(b));
blocks.push(divider());

for (let i = 0; i < sections.length; i++) {
  const s = sections[i] || {};
  const h1 = String(s.h1 || '').trim() || `섹션 ${i + 1}`;
  blocks.push(heading1(h1));

  const imgs = Array.isArray(s.image_placeholders)
    ? s.image_placeholders.map(String).map(x => x.trim()).filter(Boolean)
    : [];

  if (imageUsed < IMAGE_MAX) {
    const chosen = cleanImageConcept(imgs[0], h1, i, imageUsed);
    blocks.push(paragraph(`[이미지 플레이스홀더] ${chosen}`));
    imageUsed++;
  }

  const toggleTitle = String(s.toggle_title || '자세히 보기').trim();
  blocks.push(toggle(toggleTitle));
}

// code/bin/notion_apply.mjs
const childBlocks = [];
childBlocks.push(heading2('핵심 포인트'));

const b = tm.bullets.length
  ? tm.bullets.slice(0, 12)
  : [
      '핵심 주장/근거를 요약합니다.',
      '적용 시 고려할 리스크/제약을 정리합니다.',
      '실무 적용 시 체크리스트를 제공합니다.'
    ];

for (const it of b) childBlocks.push(bullet(it));

개별 실습에서는 같은 구조를 각자의 관심 분야를 위한 트렌드 수집 노트 만들기로 옮겨봅니다.

이번 실습의 목표는 단순합니다. URL 하나를 입력으로 받아 AI 에이전트가 먼저 트렌드 수집 JSON으로 구조화하고, 그 JSON을 다시 Markdown 트렌드 노트로 바꿉니다.

흐름은 다음과 같습니다.

압축을 풀면 다음 파일을 사용합니다.

1단계: URL 입력 메모 작성

templates/url-note.template.md를 복사해 url-note.md를 만듭니다. 관심 있는 글이나 영상 링크를 하나 넣고, 공유 대상과 흥미로운 이유를 적습니다. 여기서 공유 대상은 팀원이 될 수도 있고, 나중에 다시 볼 미래의 내가 될 수도 있습니다.

브라우징이 가능한 에이전트라면 URL만으로 시작할 수 있습니다. 브라우징이 어려운 환경이라면 자료의 핵심 부분을 함께 붙여넣습니다.

2단계: JSON 구조화

사용하는 에이전트에게 prompts/step1-url-to-json.md를 전달합니다. 함께 전달할 파일은 url-note.md와 templates/trend-card.template.json입니다.

에이전트의 출력은 설명문이 아니라 JSON이어야 합니다. 결과를 trend-card.json으로 저장합니다.

확인할 점은 다음과 같습니다.

• tldr가 정확히 5개인가
• 저자와 요청자가 구분되어 있는가
• 트렌드 신호와 내 업무와의 관련성이 들어 있는가
• 활용 관점이 들어 있는가
• 시각화 아이디어가 들어 있는가
• 사람이 확인할 질문이 review_questions에 남아 있는가

3단계: Markdown 변환

이번에는 에이전트에게 prompts/step2-json-to-markdown.md를 전달합니다. 함께 전달할 파일은 trend-card.json과 templates/trend-note.template.md입니다.

결과는 trend-note.md로 저장합니다. 이 파일은 뒤에서 LLM-Wiki/00-inbox/trend-note.md로 옮겨 Lab 02에서 확장할 트렌드 수집 노트가 됩니다.

선택 사항으로 아래 명령을 실행해 JSON에서 Markdown으로 바뀌는 과정을 확인할 수 있습니다.

node scripts/json-to-markdown.sample.mjs trend-card.json > trend-note.md

AI 워크플로우라고 하면 특별한 도구나 자동화 묶음을 먼저 떠올리기 쉽습니다. 하지만 중요한 것은 새로운 도구 이름을 많이 아는 것이 아닙니다. 내가 하려는 영역에서 무엇이 필요하고, 무엇을 결과물로 남겨야 하며, 어떤 순서로 판단하고 처리해야 하는지를 설명 가능한 구조로 만드는 것입니다.

기술 요소도 물론 필요합니다. 도구 호출, API 연결, 자동 실행, 상태 관리, 실패 처리, 훅, Skill 같은 요소가 실제 워크플로우를 움직이게 합니다. 다만 이 요소들은 본질이라기보다 실행 장치에 가깝습니다. 업무의 입력, 과정, 기준, 결과물이 정리되어 있어야 이런 장치들이 의미 있게 작동합니다.

그래서 AI 워크플로우를 찾는다는 말은, 마법 같은 완성품을 찾아다닌다는 뜻이 아닙니다. 내가 이미 하고 있는 일을 에이전트가 따라할 수 있는 구조로 바꾸는 일에 가깝습니다.

이번 Lab에서 확인한 것도 단순히 파일 3개를 만드는 절차가 아닙니다. 입력을 어떤 형식으로 받을지, 중간 결과를 어떤 구조로 남길지, 최종 결과물을 어떤 형태로 만들지 정하는 과정입니다.

입력 형식, 처리 순서, 템플릿, 검증 기준, 출력 형식이 정리되면 에이전트는 같은 작업을 반복해서 수행할 수 있습니다. 현대적인 에이전트 워크플로우에서는 이렇게 재사용 가능한 작업 단위를 Skill로 다룹니다. Skill은 특별한 기능 이름이 아니라, 사람이 매번 설명하던 업무 방식과 판단 기준을 에이전트가 따라할 수 있도록 묶어 둔 구조입니다.

이번 실습에서 Skill의 재료가 되는 요소는 다음과 같습니다.

실습 1에서는 URL을 JSON으로 구조화하고 Markdown으로 변환하는 작은 워크플로우를 경험했습니다. 이제 같은 관점을 내 업무나 관심사로 옮깁니다.

목표는 거대한 자동화를 설계하는 것이 아닙니다. 이번 워크숍에서 끝까지 가져갈 작은 결과물 후보 하나를 고르고, 그 결과물을 만들기 위한 기준을 설명 가능한 형태로 남기는 것입니다.

압축을 풀면 다음 파일을 사용합니다.

my-project는 템플릿에 들어 있는 시작용 폴더 이름입니다. Lab 02에서 본인의 프로젝트 이름으로 바꾸고, 그 프로젝트의 작업 기억을 쌓기 시작합니다.

기본 구조는 다음처럼 단순하게 시작합니다.

LLM-Wiki/
├── 00-start-here.md
├── 00-inbox/
├── 10-projects/
│   └── my-project/
└── 90-archive/

Obsidian에서 Open folder as vault를 선택하고 LLM-Wiki 폴더를 엽니다. 먼저 00-start-here.md를 열어 주요 노트가 [[wikilink]]로 연결되어 있는지 확인합니다. Graph view와 Backlinks에서 업무 후보, 기준 카드, 지식 카드가 어떻게 연결되는지도 확인할 수 있습니다. 실습 1에서 만든 trend-note.md는 00-inbox/trend-note.md에 옮겨 둡니다. 이 노트는 Lab 02에서 지식 카드, 진행 로그, 워크플로우 카드로 확장됩니다.

같은 LLM-Wiki 폴더는 두 가지 방식으로 다룹니다. Obsidian은 사람이 읽고 탐색하는 프론트엔드이고, Kiro, Claude Code, Codex 같은 AI 에이전트 환경은 같은 Markdown 파일을 읽고 수정하는 백엔드 작업 환경에 가깝습니다. 두 화면이 다른 데이터를 보는 것이 아니라, 같은 폴더를 서로 다른 방식으로 다루는 것입니다.

1단계: 결과물 후보 3개 적기

먼저 반복해서 하게 되는 일 중에서 결과물로 남길 수 있는 후보를 3개 적습니다. 처음에는 넓게 적어도 괜찮지만, 문장은 가능한 한 산출물 중심으로 씁니다.

00-inbox/workflow-candidates.md에 아래 항목을 후보별로 작성합니다. 이 파일은 [[00-start-here]], [[10-projects/my-project/work-criteria-card]], [[10-projects/my-project/decision-log]]와 연결되도록 만들어져 있습니다.

• 반복되는 상황
• 만들 결과물
• 사용할 사람
• 지금 불편한 점

좋은 후보는 구체적인 산출물로 표현됩니다.

• “회의 기록을 지식 카드와 결정 기록으로 정리하는 개인 위키”
• “팀 프로젝트 자료를 GitHub README와 PR 단위로 남기는 협업 기록”
• “자료 조사 링크를 팀 공유용 Markdown 초안으로 바꾸는 트렌드 수집 노트”
• “고객 문의를 유형, 원인, 다음 액션으로 분류한 검토 카드”

부족한 후보는 너무 추상적입니다.

• “AI를 잘 쓰기”
• “업무 자동화하기”
• “생산성 높이기”
• “자료 정리하기”

2단계: 하나를 선택하기

후보 3개 중 이번 워크숍에서 끝까지 가져갈 하나를 고릅니다. 가장 큰 문제보다, 지금 설명하고 검토할 수 있는 문제를 고르는 것이 좋습니다.

선택할 때는 00-inbox/workflow-candidates.md에서 각 후보를 아래 기준으로 검토합니다.

• 반복성: 이 일을 앞으로도 여러 번 하게 되는가
• 입력의 명확성: 무엇을 넣고 시작하는지 설명할 수 있는가
• 결과물의 명확성: 끝났을 때 무엇이 남아야 하는지 보이는가
• 검토 가능성: 좋은 결과와 부족한 결과를 구분할 수 있는가
• 실습 적합성: 오늘 작은 형태로 줄여서 다룰 수 있는가

이번 단계에서 완전 자동화 여부를 결정할 필요는 없습니다. 먼저 사람이 설명할 수 있는 구조를 만들고, 그 다음에 도구 호출, API, 훅, Skill 같은 기술 요소를 붙입니다.

3단계: 업무 기준 카드 작성하기

결과물 후보를 정했다면 좋은 결과의 기준을 적습니다. 도메인 전문성은 이 기준을 설명하는 데서 시작합니다. AI에게 일을 맡긴다는 것은 “잘해줘”라고 말하는 것이 아니라, 좋은 결과와 멈춰야 할 상황을 설명하는 일입니다.

선택한 후보는 템플릿 기준으로 10-projects/my-project/work-criteria-card.md에 정리합니다. 이후 Lab 02에서 my-project 폴더를 본인의 프로젝트 이름으로 바꿀 수 있습니다. 이 파일은 Lab 02와 Lab 03에서도 계속 확장합니다.

# 업무 기준 카드

## 결과물 이름
-

## 사용할 사람
-

## 목적
-

## 입력
-

## 처리 절차
1.
2.
3.

## 좋은 결과의 기준
-
-
-

## 예외와 중단 조건
-

## 기술 요소 후보
- 도구 호출:
- API 연결:
- 훅 또는 Skill:
- 저장 위치:

## 사람이 확인할 것
-

## 완료 기준
-

예시로는 다음처럼 시작할 수 있습니다.

# 업무 기준 카드: 링크를 팀 공유 Markdown 초안으로 만들기

## 목적
- 팀원이 읽고 다시 활용할 수 있는 콘텐츠 초안을 만든다.

## 사용할 사람
- 같은 팀원
- 나중에 같은 주제를 다시 다룰 나

## 입력
- 자료 URL
- 공유 대상
- 콘텐츠 형식 규칙

## 처리 절차
1. 원문 제목, 저자, 출처를 확인한다.
2. 핵심 주장과 근거를 분리한다.
3. TLDR과 활용 관점을 작성한다.
4. 검토 질문을 남긴다.

## 좋은 결과의 기준
- 자료 제목과 저자를 기록한다.
- TLDR은 5개 이내로 정리한다.
- 출처 링크를 남긴다.
- 이미지가 필요한 위치를 표시한다.

## 예외와 중단 조건
- 자료에 접근할 수 없으면 중단한다.
- 출처가 불명확하면 공유용 콘텐츠로 발행하지 않는다.

## 사람이 확인할 것
- 공유할 가치가 있는 자료인지
- 자료의 의도를 왜곡하지 않았는지

## 기술 요소 후보
- 도구 호출: URL 읽기, 파일 읽기
- API 연결: 나중에 Notion 또는 Slack 연동
- 훅 또는 Skill: 반복되는 변환 절차를 Skill로 정리
- 저장 위치: Obsidian 또는 GitHub 저장소

## 완료 기준
- 팀원이 읽을 수 있는 초안과 검토 메모가 남는다.