원본 전체 내용(임베드): week3/transcripts/3주차-1교시-강의기록.html
원본 전체 내용(임베드): week3/docs/w3-practice1.html
원본 전체 내용(임베드): week3/docs/w3-concept-mindset.html
원본 전체 내용(임베드): week3/docs/w3-agents.html
원본 전체 내용(임베드): week4/docs/w4-overview.html
원본 전체 내용(임베드): week4/transcripts/4주차-1교시-강의기록.html
원본 전체 내용(임베드): week4/docs/w4-concept-habit.html
원본 전체 내용(임베드): week4/docs/w4-practice1.html
원본 전체 내용(임베드): week4/docs/w4-prompt-markdown.html
원본 전체 내용(임베드): week4/docs/w4-concept-limits.html
원본 전체 내용(임베드): week4/docs/w4-concept-team.html
원본 전체 내용(임베드): week4/docs/w4-practice-refs.html
↑↓ 이동 · Enter 이동 · Esc 닫기
AX 스터디 — 자율 실습 템플릿
이 템플릿은 수업을 각자 자기 손으로 교안 대시보드까지 만들어 보는 실습 꾸러미입니다. 수업 녹음을 글로 옮기고(전사), 그 전사를 근거로 교안을 집필하고, 빌드해서 지금 보고 있는 것과 같은 단일 HTML 대시보드를 만드는 것까지가 한 바퀴입니다.
3주차로 시작해 4주차(마지막 회차)까지 같은 방식으로 만들었습니다. 왼쪽 위 3주 / 4주 버튼으로 회차를 바꿔 볼 수 있습니다.
개발 경험이 없어도 괜찮습니다. 직접 코드를 짜는 게 아니라 내 Claude Code에게 무엇을 만들지 설명하고, 결과를 검수하는 일이 실습의 본체입니다.
이 템플릿으로 하는 일
수업 녹음 → 전사 텍스트 → 교안 파셜 집필 → 빌드 한 줄로 index.html 생성 → 진행자에게 전달. 완성본은 진행자가 아카이브에 게시합니다.
한눈에
지금 이 화면이 여러분이 만들 결과물입니다. 처음 받았을 때 왼쪽 메뉴에는 개요와 3주차 개요 두 칸밖에 없었습니다.
전사를 넣고 교안을 한 편씩 쓸 때마다 메뉴가 한 줄씩 늘어나고, 마지막에 index.html 하나로 합쳐집니다. 편집하는 것은 언제나 원본 파셜이고, index.html 은 빌드로만 만듭니다.
①다섯 단계 흐름
순서대로 한 칸씩만 진행하면 됩니다. 앞 단계의 산출물이 다음 단계의 입력이 됩니다.
입력
수업 녹음 파일 — 내 기기로 녹음한 수업
→
중간 산출물
전사 텍스트와 그것을 근거로 쓴 교안 파셜 HTML
→
최종 산출물
빌드로 합쳐진 index.html — 자기완결 단일 페이지
1단계녹음 — 수업을 소리로 남긴다
수업을 녹음합니다. 파일은 회차 폴더의 audio/(예: week4/audio/) 에 두면 정리가 쉽습니다. 녹음이 없으면 다음 단계로 넘어갈 재료가 없으니, 이 단계가 사실상 전부의 출발점입니다.
2단계전사 — 소리를 글로 옮긴다
가장 간단한 길은 Clova Note 같은 전사 서비스에 녹음을 올리고, 나온 텍스트를 회차 폴더의 transcripts/ 에 넣는 것입니다. 원한다면 tools/transcribe.py 로 직접 전사해도 됩니다(화자 분리 포함). 어느 쪽이든 결과는 텍스트 파일 한 개면 충분합니다.
3단계집필 — 전사를 교안으로 바꾼다
내 Claude Code(구독 로그인)에 이 폴더를 열고, 전사를 근거로 교안 파셜 HTML을 씁니다. 파셜은 회차 폴더의 docs/ 아래에 주제 하나당 파일 하나로 만듭니다. 규칙은 docs/문서-제작-가이드.md 에 정리돼 있습니다. 전사에 실제로 있는 내용만 쓰는 것이 원칙입니다.
4단계빌드 — 파셜을 한 페이지로 합친다
터미널에서 python3 tools/build_dashboard.py 를 실행하면 index.html 이 새로 만들어집니다. 브라우저로 열어 메뉴 이동·모바일 폭·오탈자를 눈으로 확인합니다.
5단계전달 — 진행자에게 완성본을 넘긴다
완성된 폴더(또는 index.html)를 진행자에게 전달하면, 진행자가 아카이브에 게시합니다. 게시는 참가자가 직접 하지 않습니다.
②폴더 구조 — 무엇을 어디에 두나
손대는 곳은 사실상 전사 폴더와 파셜 폴더 두 군데입니다. 나머지는 도구와 참고 자료입니다.
경로
무엇이 들어가나
내가 손대나
week3/ · week4/
회차별 폴더 — 아래 세 칸이 그 안에 들어간다
예 — 회차마다 하나씩
weekN/audio/
수업 녹음 파일
예 — 녹음을 넣는다
weekN/transcripts/
전사 텍스트와 강의기록 파셜
예 — 전사 결과를 넣는다
weekN/docs/
교안 파셜 HTML
예 — 여기에 집필한다
docs/
템플릿 소개(이 문서) · 제작 가이드 · 표지 이미지
필요하면
tools/
전사 도구 · 대시보드 빌더 · 셸
뷰를 추가할 때만
references/
스타일 기준 문서 — 파셜을 쓸 때 그대로 참고
아니오 — 읽기용
index.html
빌드 산출물
아니오 — 손편집 금지
index.html 을 직접 고치면 다음 빌드에서 통째로 덮어써집니다. 고칠 곳은 항상 원본 파셜입니다.
③빌드 한 줄
파셜을 하나 쓸 때마다, 혹은 고칠 때마다 아래 한 줄만 다시 실행하면 됩니다.
python3 tools/build_dashboard.py
빌드는 각 파셜의 <style> 과 본문을 뽑아 대시보드 안에 격리된 영역으로 심습니다. 그래서 파셜끼리 스타일이 섞이지 않고, 파셜은 각자 자기 스타일을 다 갖고 있어야 합니다. 파셜에 넣은 <script> 는 빌드가 제거하므로, 동작이 필요한 기능을 파셜에 의존하지 마세요.
원칙 1
있는 내용만
전사에 실제로 있는 말만 교안에 올립니다. 추측으로 채우지 않기 — 비어 있으면 비워 두는 편이 낫습니다.
원칙 2
회색조 + 파랑 하나
색은 회색 계열에 파랑 한 가지만 씁니다. 새 색을 늘리지 않는 것이 화면을 편하게 만드는 가장 쉬운 방법입니다.
원칙 3
덜 복잡하게
화려하게가 아니라 덜 복잡하게. 짧은 문단, 한 번에 한 단계, 좁은 화면에서도 가로로 넘치지 않게.
④시작하기 전에 알아 둘 것
이 폴더의 .env 에는 전사 등에 쓰는 공유 API 키가 들어 있습니다. 사내 실습용으로 함께 넣어 둔 것이니 외부에 공유하지 마세요.
녹음과 전사에는 동료들의 목소리와 이름이 담깁니다. 교안에 옮길 때는 사적인 잡담·개인에 대한 평가는 빼고, 배울 내용 중심으로 정리해 주세요.
막히면 Claude Code에게 그대로 물어보는 것이 가장 빠릅니다. "이 전사로 개요 파셜을 써 줘", "빌드가 실패하는데 원인을 찾아 줘" 처럼 하고 싶은 결과를 말하면 됩니다. 각 회차의 개요 화면에 새 뷰를 추가하는 절차가 정리돼 있습니다.
3주차 개요 — 이번 주 다섯 단계와 1교시에서 정리한 것
1주차에는 AI로 무엇이 가능한지 경험했고, 2주차에는 그것을 직접 만들어 봤습니다. 3주차는 그 둘을 일상과 업무에 통합하고, AI가 내놓은 결과를 판단하는 눈을 기르는 주간입니다.
지금 이 저장소에는 1교시 전사만 들어와 있습니다. 아래 문서 네 개는 1교시 전사를 근거로 쓴 것이고, 2교시 이후는 전사가 아직 없어 비어 있습니다.
3주차 목표
배운 것을 일상·업무에 통합하고, 결과를 판단하는 눈을 기릅니다. 도착점은 내가 자리에 없어도 작업이 계속 진행되게 만드는 것입니다.
1교시에서 실제로 다룬 것
과제 회고 — 동현 님의 프로덕트 시안과 주리 님의 설명 스크립트·음성을 화면에 띄워 놓고, 결과물보다 만드는 과정을 되짚고 점수를 매겼습니다.
1주차 세 원칙 재확인 — 기존 방식 내려놓기 · 매일 클로드 코드 쓰기 · 호들갑에 말리지 않기. 그중 "내려놓기"가 조직에서 실제로 얼마나 어려운지도 이야기했습니다.
내려놓기와 보는 눈 — 시키고 결과만 받으면 판단력이 떨어진다는 지적, 그리고 판단 기준을 늘리는 방법.
오픈클로 개념과 실습 준비 — 오픈클로와 클로드 코드의 차이, 봇 여러 개를 운영하는 방식, 크론 스케줄링을 개념 수준으로 소개하고, 마지막에 스터디 아카이브를 내려받아 이번 주 교안을 직접 만드는 실습으로 넘어갔습니다.
①1주차 → 2주차 → 3주차
진행자가 3주차를 안내하면서 세 주를 이렇게 정리했습니다. 3주차에는 앞의 두 주에서 경험한 것과 만들어 본 것을 함께 씁니다.
1주차
AI 시대에 무엇을 할 수 있는지 경험한다
→
2주차
내가 실제로 할 수 있는 것을 직접 만들어 본다
→
3주차
일상·업무에 통합하고, 지금 트렌드에 맞게 보는 눈을 기른다
전사 1교시 55분 구간에서 진행자가 직접 세 주를 나눠 설명한 내용입니다.
②이번 주 다섯 단계 — 교안덱에 예고된 순서
수업에서 띄운 교안덱 2장에 이번 주 순서가 다섯 단계로 적혀 있습니다. 1교시는 세 번째 단계까지 진행했고, 네 번째는 개념 설명까지, 다섯 번째는 예고만 했습니다.
파랑 = 1교시에서 실제로 진행한 단계, 회색 = 아직 남은 단계. 아래줄은 교안덱 2장에 적혀 있는 도착점입니다.
STEP 1과제 회고
1교시에서 진행. 두 사람의 결과물을 화면에 띄워 놓고, 어디서 막혔고 무엇을 다시 시켰는지 순서대로 되짚었습니다. 자세한 내용은 과제 회고 문서에 있습니다.
STEP 21주차 되돌아보기
1교시에서 진행. 1주차에 정한 세 원칙(기존 방식 내려놓기 · 매일 클로드 코드 · 호들갑에 말리지 않기)을 참가자에게 다시 물어보고 확인했습니다. 정리한 문서는 내려놓기와 보는 눈입니다.
STEP 3내려놓기 · 보는 눈
1교시에서 진행. 기존 방식을 내려놓기가 왜 어려운지, 그리고 AI에게 시키고 결과만 받으면 판단 기준이 늘지 않는다는 이야기를 다뤘습니다. 정리한 문서는 내려놓기와 보는 눈입니다.
STEP 4오픈클로 · 슬랙봇
1교시에는 개념까지. 오픈클로와 클로드 코드가 어떻게 나뉘는지, 봇을 여러 개 만들어 역할을 나누는 방식, 크론으로 정해진 시각에 돌리는 방식을 설명했습니다. 설치와 슬랙 연결은 나중에 간단히 한 번 해 보겠다고 예고만 했습니다(전사 02:06 구간). 정리한 문서는 오픈클로와 에이전트입니다.
STEP 5LLM Wiki
1교시에는 예고만. LLM Wiki는 마지막에 한 번 해 보겠다고만 말했습니다(전사 02:07 구간). 정리한 문서는 아직 없습니다.
오픈클로와 클로드 코드의 차이, 봇 여러 개 운영, 크론 스케줄링입니다. 터미널 밖에서 작업을 돌리는 구조가 궁금할 때 보면 됩니다.
⑤1교시에서 나온 말
아래 세 문장은 1교시 전사에 나온 그대로입니다. 인용 아래에 실무에서 무슨 뜻인지 한 줄로 적었습니다.
"쥔 것을 놓아야만 됩니다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 됩니다. 내가 쥐고 있는 것을 내려놓을 수 있어야 다른 걸 쥘 수 있어요."
진행자 — 1시간 57분 구간
실무로 옮기면 이렇습니다. 쓰던 작업 방식을 그대로 유지한 채로는 새 방식을 시작하기 어렵습니다. 1주차 원칙 01이 "기존 방식 내려놓기"인 이유입니다(교안덱 4장). 1교시에서는 이 원칙이 조직 안에서 실제로 지키기 어렵다는 이야기도 함께 나왔습니다.
"시키고, 그다음 그냥 실행만 시키고 끝나 버리면 진짜 바보가 된다고 느껴요. 얘가 어떤 걸 해 놓으면 왜 그렇게 해 놨는지 물어본다든지 — 그런 보는 눈을 키워 놓는 게 중요합니다."
진행자 — 1시간 58분 구간
결과를 받고 바로 끝내지 말고, 왜 그렇게 만들었는지 되물어 설명을 받으라는 뜻입니다. 진행자는 이어서 의사결정을 잘하려면 판단 기준의 개수를 늘려야 한다고 말했고, 그 기준은 직접 시켜 보고 결과가 달라지는 것을 겪으면서 하나씩 늘어난다고 설명했습니다.
"내가 해야 하는 것을 앞단에서는 배경, 마지막에는 질문, 이런 식으로 정리하니까 말할 때 구조를 그리는 게 조금씩 생긴 것 같습니다."
주리 님 — 과제 회고 중
스킬이 만든 대본을 같은 순서로 반복해 쓰다 보니, 그 순서가 본인이 설명할 때도 남았다는 회고입니다. 자세한 과정은 과제 회고에 있습니다.
⑥이번 주에 각자 해야 하는 것
1교시 처음과 마지막에 진행자가 참가자에게 직접 지시한 것이 세 가지입니다. 이 저장소는 그중 세 번째를 하는 자리입니다.
01수업을 각자 녹음해 전사 텍스트를 확보한다
수업 시작 직후 진행자가 녹음·전사 앱을 켰는지 확인하면서 "오늘 켜셔야 제가 그 교안 만드는 거 같이 해보면서 갈 겁니다. 없으시면 안 나와요. 제 거 전달 안 해드릴 거예요. 직접 만드셔야 됩니다."라고 말했습니다(전사 00:03 구간). 진행자가 만든 교안은 전달되지 않고, 각자 자기 전사로 만듭니다. 수업이 끝날 때는 녹음을 종료하라고 다시 안내했습니다(02:10 구간).
02스터디 아카이브를 받아 풀고 터미널에서 클로드 코드를 켠다
진행자가 슬랙에 공유한 스터디 아카이브를 내려받아, 깃으로 관리하는 자기 로컬 폴더에 넣고 압축을 풉니다. 그다음 터미널을 하나 켜서 그 폴더로 이동한 뒤 클로드 코드를 실행합니다(전사 02:07~02:10 구간).
cd .. # 한 단계 밖으로 나온다
cd study-archive # 받아서 푼 폴더로 들어간다
claude # 클로드 코드를 켠다
03전사를 원자료로 파셜을 쓰고 빌드한다
확보한 전사를 근거로 교안 파셜을 쓰고 빌드해 index.html 을 만듭니다. 손대는 파일과 순서는 아래 ⑦절에 정리해 두었습니다.
⑦2·3교시 전사가 들어오면 할 일
문서를 하나 늘릴 때 손대는 곳은 늘 같습니다 — 파셜 작성 → 셸 등록 → EMBED 등록 → 빌드. 앞의 ⑥절 03에서 말한 작업이 이것이고, 2·3교시 전사가 들어왔을 때도 같은 순서입니다.
1파셜 작성
week3/docs/ 또는 week3/transcripts/ 에 자기완결 HTML 파일을 하나 만듭니다. <script> 는 넣지 않습니다(빌드가 제거합니다).
2셸 등록
tools/dashboard_shell.html 에 뷰 섹션 한 줄과 왼쪽 메뉴 링크 한 줄을 추가합니다.
3EMBED 등록
tools/build_dashboard.py 의 EMBED 목록에 뷰 ID → 파일 경로 한 줄을 추가합니다.
4빌드
python3 tools/build_dashboard.py 를 실행하고 index.html 을 열어 확인합니다. 메뉴에 새 칸이 보이면 성공입니다.
뷰 ID w3-lecture2 가 세 곳에 똑같이 들어갑니다 — 섹션 id · EMBED 주석 · EMBED 목록의 키. 한 곳이라도 다르면 빌드가 "셸에 마커 없음"이라고 알려 줍니다.
파셜을 고쳤는데 화면이 그대로라면 빌드를 다시 돌리지 않은 것입니다. index.html 은 빌드로만 갱신됩니다.
전사에 없는 내용을 상상해서 채우지 마세요. 원본 전사 *.txt 는 고치지 않습니다. 기억나는 것이 있으면 week3/docs/ 아래에 별도 메모 파일을 만들어 적어 두고, 전사에서 근거를 찾은 뒤에 본문에 넣습니다.
3주차 1교시 강의기록 — 2주차 과제 회고에서 3주차 방향까지
2026년 8월 2일 오전 10시 25분에 시작해 2시간 11분 동안 진행한 3주차 1교시입니다. 2주차 과제 두 건을 함께 열어 보며 회고하고, 3주차에 무엇을 하는지 안내한 뒤, 기존 방식을 내려놓는 것과 판단 기준을 늘리는 것까지 다뤘습니다.
이 문서는 말이 오간 시간 순서대로 정리한 기록입니다. 주제별로 정리한 문서는 따로 있습니다. 과제 두 건만 모아 본 1교시 과제 회고, 내려놓기와 보는 눈만 모아 본 내려놓기와 보는 눈, 오픈클로·봇 이야기를 모아 본 오픈클로와 에이전트입니다.
이 기록의 원자료
2026-08-02 3주차 1교시 녹음의 전사 텍스트 한 건입니다. 사적인 대화, 사내 조직·인물에 관한 이야기, 특정 개인에 대한 평가는 대외 공개 기준에 따라 제외했습니다. 참가자는 스터디 안에서 부르는 호칭까지만 적었고, 진행자 이름은 적지 않았습니다.
1교시 핵심
시작은 "내가 무슨 과제를 냈는지 설명해 보라"였습니다. 결과부터 말하면 듣는 사람이 이해하지 못하고, 목적 → 그 과정에서 무엇이 있었고 → 그래서 이렇게 해 보기로 했다 순서로 말해야 이해된다는 것을 확인했고, 같은 규칙을 AI에게 요청할 때도 그대로 적용했습니다.
과제 두 건을 함께 열어 봤습니다. 동현 님의 부모님 음식점 홍보 웹사이트 시안은 9.5점, 주리 님의 리뷰 설명 준비 스킬은 9점으로 평가됐습니다. 두 건 모두 지적 사항은 같았습니다 — 만들어진 결과물을 끝까지 열어 보지 않았거나, 듣는 사람에게 결과물을 먼저 보여 주지 않았다는 것입니다.
3주차 목표는 내가 자리에 없을 때도 작업이 진행되게 만드는 것이고, 그 앞에 두 가지가 필요하다고 정리했습니다. 기존 방식을 내려놓는 것, 그리고 결과를 받고 끝내지 않고 판단 기준을 늘리는 것입니다.
2시간 11분이 어떤 순서로 진행됐는지 먼저 한 장으로 보겠습니다. 각 구간의 가로 폭이 실제 소요 시간입니다.
파랑으로 표시한 ⑥⑦은 교안덱 STEP 3(내려놓기 · 보는 눈)에 해당하는 구간입니다. 덱이 이번 주 메인으로 적은 것은 에이전트(STEP 4)입니다. ⑤가 48분으로 가장 길지만 점선으로 표시한 이유는, 이 구간이 사내 조직·인물 이야기라 대부분 제외했기 때문입니다(아래 ⑤ 참고).
①과제를 어떻게 설명하는가 (00:00–00:09)
수업은 과제 결과를 보는 것으로 시작하지 않았습니다. 진행자가 두 참가자에게 "내가 무슨 과제를 냈는지, 주리 님도 이해할 수 있게 설명해 보라"고 하고 생각할 시간 1분을 준 것이 첫 장면입니다.
동현 님이 먼저 답했습니다. "피그마 MCP를 연결해서 원하는 사이트를 만들어 보아라", "UI 레퍼런스도 활용하고 레퍼런스를 잘 모으라" 같은 지시 내용 위주였습니다. 진행자는 여기서 말하는 순서를 정정했습니다.
이렇게 할 때는 프롬프트를 그대로 읊을 필요가 없습니다. 목적이 무엇이었고, 그 과정에서 무엇이 있었고, 그래서 이렇게 한번 해 보기로 했습니다 — 이렇게 얘기하는 게 정석입니다.
진행자 · 1교시 00:01 구간
그리고 진행자가 2주차 과제의 목적을 직접 다시 정리했습니다. 지금까지 배운 연결점(MCP, 레퍼런스를 활용하는 방법, Codex CLI로 이미지를 뽑는 것)을 통틀어 자기 목적에 맞게 써 보는 것이 과제였습니다. Figma MCP로 먼저 시안을 내고, 그 과정에서 UI 레퍼런스를 참고하고, Codex CLI로 이미지를 뽑아, 그것을 조합해 자기가 만들고 싶은 결과물을 Figma 시안으로 옮기는 것입니다. 결과물이 부족해도 괜찮다고 한 이유는 일단 시도를 해 봐야 하기 때문이라고 했습니다.
주리 님의 과제 설명은 순서가 달랐습니다. 팀에서 기획자로 리뷰할 때 전체 맥락을 구조적으로 설명한 다음 팀원이 그려지게끔 설명해야 하는데 그 부분이 부족하고 빼먹는 일이 있어서, 그동안 리뷰한 기록을 Claude에 넣어 자동화하든 스킬을 만들든 쉽게 설명할 수 있는 산출물을 만드는 것이 과제였다고 말했습니다. 방법은 상관없고, 대본을 구조적으로 만들고 TTS 음성까지 나오게 하는 것이 조건이었습니다.
진행자는 이 설명을 두고 "어떤 배경에서 하게 되는지를 이해되게끔 설명했다"고 평가했고, 곧바로 이 규칙이 사람에게만 해당하는 게 아니라고 덧붙였습니다.
AI한테도 그렇게 설명을 잘해야 됩니다. 맥락을 쏙 다 빼놓고 설명하면, 내가 어떤 목적과 목표를 가지고 있고 무엇을 만들어 줘야 하는지 잘 모르니까요. 모호할수록 결과는 잘 안 나옵니다.
진행자 · 1교시 00:09 구간
이 구간에서 이번 주 진행 방식도 예고됐습니다. 이번 주 스터디는 각자 교안을 직접 만들면서 진행하고, 진행자가 만든 교안을 그대로 전달하지 않습니다. 그래서 참가자 각자가 오늘 수업을 녹음해 두어야 합니다. 이 문서 자체가 그 녹음을 원자료로 만든 결과물입니다.
②과제 리뷰 — 부모님 음식점 홍보 웹사이트 (00:09–00:33)
동현 님이 화면을 띄우고 직접 설명했습니다. 시작은 만들고 싶은 사이트가 떠오르지 않던 상황이었습니다. 배우자가 "어머니 가게 웹사이트를 만들어 드리라"고 했고, 어머니도 홍보용으로 그런 것이 있으면 좋겠다고 하던 참이라 주제가 정해졌습니다.
순서
무엇을 요청했는가
어떻게 됐는가
1
가게가 나왔던 지역 맛집 방송 영상을 찾아 달라고 요청
영상을 찾아 이미지를 캡처하고 방송에 나온 워딩을 정리해 줌
2
정리한 재료로 Figma 시안 요청
처음 나온 결과가 기대하던 것과 달랐음
3
UI 레퍼런스 사이트를 참고하게 하려 했음
잘 안 됨. 동현 님이 밝힌 이유는 "제가 딱 뭘 찝어 줘서 하질 않았으니까"
4
대신 다른 음식점 사이트를 검색해 레퍼런스로 받아 다시 요청
이때부터 결과가 원하는 방향으로 나옴
5
워딩은 장인정신이 느껴지는 방향으로 요청
워딩이 그 톤으로 나옴
6
사진 화질이 낮아 고화질로 다시 뽑아 달라고 요청, Codex도 함께 사용
토큰 한계가 있어 일부 이미지만 고화질로 나왔고, 영상 캡처라 한계가 남았음
7
한 페이지에 다 나오는 느낌이 아쉬워 HTML 사이트도 따로 제작
HTML을 보면서 대화하듯 계속 수정함
주리 님이 색을 지정해 준 것인지 묻자, 동현 님은 시안에 나온 초록·네이비가 가게 실제 인테리어 색과 같다고 답했습니다. 그리고 동현 님은 한 번에 다 넣지는 않았다고 덧붙였습니다. "이것 좀 넣어 보고, 이것도 넣고" 하며 대화하듯 진행했다는 것입니다.
이미 만들어져 있었는데 커버만 보고 있었던 장면
진행자가 Figma 파일 왼쪽 페이지 목록을 눌러 보라고 했습니다. 페이지가 여러 개 있었고 데스크톱 화면과 모바일 화면, 그리고 파운데이션과 컴포넌트까지 만들어져 있었습니다. 동현 님은 그때까지 커버 한 장만 보고 있었습니다. Figma 연동을 요청했지만 커버만 나온 줄 알고 HTML 쪽으로 넘어갔던 것입니다.
그게 중요한 게 아니라, 일단 결과는 만들어져 있는데 그걸 했느냐 안 했느냐가 중요한 겁니다.
진행자 · 1교시 00:16 구간
결과물을 끝까지 열어 확인하지 않으면, 이미 만들어진 것도 쓰지 못한 채로 남습니다. 동현 님은 "클로드한테 안 보인다고 말했으면 알려 줬을 텐데"라고 덧붙였습니다.
왜 파운데이션·컴포넌트까지 나왔는가
주리 님이 "이건 시키신 적 없느냐"고 묻자 원인이 드러났습니다. 동현 님은 에이전트에 UI·UX 전문 웹 에이전시 스쿼드 페르소나를 주고 기획자·디자이너·개발자를 모두 넣어 뒀습니다. 그리고 레퍼런스에서 요소를 하나하나 추출해 참고하게 하고, 100점 만점에 95점이 나올 때까지 점수 평가를 반복하게 했습니다. 디자인 시스템 개념을 몰랐지만, 디자이너 역할을 맡은 에이전트가 그 작업을 한 것입니다.
진행자가 그 자리에서 디자인 시스템을 설명했습니다. 색·타이포그래피·컴포넌트를 하나씩 토큰으로 만들고 규칙을 정해 두는 것이고, 디자인과 개발과 프로덕트가 함께 일하기 위해 그것을 문서로 정리해 둔 것이 디자인 시스템이라고 했습니다. 색을 먼저 뽑고 컴포넌트를 만들고 그 위에 들어가는 UI 구조를 잡아 올라가는 방식을 바텀업이라고 부릅니다. 시안에는 그 색 값이 실제로 그대로 쓰여 있었습니다.
평가 9.5점
진행자는 10점 만점에 9.5점으로 평가했고, 이유로 세 가지를 들었습니다. 첫째는 과제 범위인 Figma 시안에서 멈추지 않고 "거기다 한 단계 더 나아가서 HTML까지 뽑았다"는 것입니다. 둘째는 동현 님이 말한 "과제로 끝나는 게 아니라 진짜 해 주고 싶어서"라는 실제 목적입니다. 하고 싶은 것을 제대로 찾으면 동기가 생기고 알아서 찾아서 하게 된다는 것이 진행자의 설명이었습니다. 셋째는 영상 프레임 분석 스킬 과제도 함께 했다는 점입니다. 재미있는 쪽만 하고 원래 해야 할 과제를 빼먹었다면 점수를 낮게 줬을 것이라고 했습니다.
동현 님은 채점 뒤 한 줄 평에서 1주차와 2주차에 배운 것을 최대한 다 써 보려 했다고 말했습니다. 영상을 프레임으로 쪼개 분석하는 방법도 이 사이트 작업 안에서 써 봤다고 했습니다.
보완 지시는 하나였습니다. 작업을 끝낸 그 세션에서, 다음에 다시 쓸 스킬로 구조화해 두라는 것입니다. 주리 님이 "세션을 닫았으면 어떻게 하느냐"고 묻자 진행자는 닫았어도 resume 으로 다시 찾아갈 수 있고, 세션을 찾기 어려우면 Claude에 세션 ID를 찾아 달라고 하면 된다고 답했습니다. 두 과제의 방법과 지적을 한자리에 모아 본 것은 1교시 과제 회고에 있습니다.
이 자리에서 동현 님이 "사이트에서 개발자 도구로 하면 모바일이 안 보이느냐"고 물었고, 진행자가 크롬 개발자 도구로 모바일 크기를 확인하는 조작도 같이 알려 줬습니다. 눌러야 할 순서는 1교시 과제 회고에 정리해 뒀습니다.
③과제 리뷰 — 리뷰 설명을 준비하는 스킬 (00:33–00:55)
주리 님 차례입니다. 과제는 "리뷰할 때 쉽게 설명할 수 있는 산출물을 만들어라, 방법은 상관없고 대본은 구조적으로 만들고 TTS까지 붙여라"였습니다. 만든 것은 이지 익스플레인이라는 스킬입니다. 리뷰할 목업이나 기획 문서, 그리고 지난 리뷰 전사를 넣으면 말할 대본 + TTS 음성 + 확인용 화면이 나옵니다.
대본은 다섯 단계로 고정돼 있었습니다. 여기까지 온 이야기, 전체 그림, 하나씩 세부 설명, 듣는 사람 관점, 예상 질문 순서입니다. 각 단계가 왜 필요한지는 1교시 과제 회고에 표로 정리했습니다.
준비 과정이 특이했습니다. 스킬을 만들기 전에, 그동안 진행한 리뷰의 전사 파일을 약 8시간 분량으로 넣고 이렇게 요청했습니다. "다른 세션이나 메모에 있는 걸 보지 말고, 이 전사만 보고 내 리뷰의 문제점이 무엇인지, 내가 말할 때 어떤 버릇이 있고 무엇을 고쳐야 하는지 먼저 짚어 달라." 짚힌 것은 세 가지였습니다. 배경 없이 세부부터 들어간다는 것, 지난주 이후 무엇이 바뀌었는지 빼먹는다는 것, "뭔가"·"같아요" 같은 표현을 반복해서 쓴다는 것입니다. 그 세 가지를 그대로 스킬 규칙으로 넣었습니다.
시행착오도 있었습니다. Claude가 이 스킬을 "회의가 끝난 뒤 팀에 공유하는 문서를 만드는 것"으로 이해해 그 방향으로 만들어 줬습니다. 그래서 리뷰 전 준비와 리뷰 후 회고에 쓰는 도구라는 맥락을 다시 넣어야 했습니다. 주리 님은 이 지점에서 "정말 맥락을 많이 빼먹었구나"라고 생각했다고 말했습니다.
쓰는 방식은 이렇습니다. 리뷰하는 날, 왼쪽에는 설명해야 하는 문서를 띄우고 오른쪽에는 스킬이 만들어 준 확인용 화면을 띄웁니다. 왼쪽을 보고 오른쪽을 보며 설명을 연습합니다. 리뷰가 끝난 뒤 그 녹취를 다시 넣으면 회고 문서가 나오고, 그것으로 다음 리뷰를 준비합니다. 시연을 보던 진행자는 출근할 때 한 번 듣고 스크럼에 들어가는 식으로도 쓸 수 있겠다고 덧붙였습니다.
진행자 피드백
좋게 본 부분은 세 가지였습니다. 대본을 눈으로 읽는 것과 음성으로 듣는 것은 완전히 다르다는 것, 자기 목소리를 직접 듣는 일은 힘든데 AI가 대신 듣고 짚어 준다는 것, 그리고 스피치나 자기개발 쪽으로도 쓸 수 있겠다는 것입니다. 동현 님도 영업에서 고객사에 설명할 때 같은 어려움이 있다며, 이 방식이면 고칠 방법까지 받아 볼 수 있겠다고 했습니다.
지적은 두 가지였습니다. 첫째는 설명 순서입니다.
이럴 때는 차라리 결과물을 먼저 보여 주고 난 뒤에 하나씩 설명하셨으면 잘 이해가 됐을 겁니다. 저도 듣는 입장에서 배경을 쏙 빼놓고 나는 모른다 생각했을 때, 그래서 무엇을 하려고 했는지 집중이 잘 안 됐습니다. 그런데 결과물을 보여 주니 딱 이해가 됐거든요.
진행자 · 1교시 00:50 구간
①에서 나온 것과 같은 지적입니다. 듣는 사람에게는 배경이 없으므로, 결과물을 먼저 보여 주고 그다음 과정을 설명해야 "이 결과물이 나오려고 이런 걸 했구나"가 이해된다는 것입니다.
둘째는 결과물 자체였습니다. 진행자는 나온 대본이 실제로 쉬운 설명이 됐는지는 아직 잘 모르겠다고 했습니다. 다듬으면 될 것 같고 지금은 해 봤다는 게 중요하다는 말을 함께 했습니다.
주리 님이 마지막으로 덧붙인 것이 하나 있습니다. Claude가 문서를 만들 때 쓰는 추상적인 표현("엽니다", "닫습니다", "돕니다", "사슬" 같은 표현)이 기획 문서에서는 무슨 말인지 알기 어려운 때가 많다는 것입니다. 그래서 추상 표현을 줄이는 문체 검사 스킬을 따로 만들어 뒀고, 이번 대본에도 아직 그런 표현이 남아 있어 그 스킬을 함께 발전시키겠다고 했습니다. 평가는 9점이었습니다.
진행자가 과제를 설명하는 정석이라고 한 순서는 무엇입니까?
해설 — ① 구간(00:01)에서 진행자는 "프롬프트를 그대로 읊을 필요가 없다, 목적이 무엇이었고 그 과정에서 무엇이 있었고 그래서 이렇게 한번 해 보기로 했습니다 — 이렇게 얘기하는 게 정석"이라고 했습니다. ③ 구간에서도 같은 지적이 다시 나왔습니다. 그때는 결과물을 먼저 보여 준 다음 과정을 설명하라는 쪽이었고, 설명을 생략하라는 뜻은 아니었습니다.
④3주차에 무엇을 하는가 (00:55–01:03)
과제 회고를 마치고 진행자가 이번 주 계획을 설명했습니다. 먼저 주차별로 무엇이 달랐는지를 정리했습니다.
주차
그 주에 한 것
1주차
AI 시대에 어떤 것들을 할 수 있는지 경험했다
2주차
내가 실제로 할 수 있는 것을 직접 만들어 봤다
3주차
지금 흐름에 맞게 해야 할 것들과 본인의 보는 눈을 기른다. 일상과 업무에 어떻게 더 잘 통합할지에 초점을 맞춘다
이번 주에 실제로 다룰 것은 오픈클로 설치(30분 안에 끝낸다. 설치 자체가 중요한 게 아니라고 분명히 했습니다), 슬랙봇, 여러 봇에 역할을 주고 서로 논의시키기, 크론(스케줄링), 그리고 AI가 필요한 자료를 잘 찾아가게 만드는 것입니다.
동현 님이 "오픈클로랑 Claude Code는 무슨 차이냐"고 물었고, 주리 님도 설치는 해 봤지만 아직 헷갈린다고 해서 진행자가 답했습니다.
Claude Code가 엔진이고, 겉에서 그 엔진을 감싸 봇 역할을 하게 해 주는 것이 오픈클로입니다. 아침마다 무엇을 해 달라고 해 두면 알아서 처리해 줍니다.
진행자 · 1교시 00:57 구간
진행자는 자기 봇 3개(워키·리아·루나)를 운영하고 있다고 했습니다. 필요한 링크를 봇에게 보내 두고 "이해하고 있어라"고 하면 봇이 그 링크를 분석해 두었다가 나중에 물었을 때 설명해 준다는 것, 봇 둘을 붙여 서로 논의하고 평가하게 하면 그 과정에서 학습하는 구조가 된다는 것을 예로 들었습니다.
이어서 1주차의 세 원칙을 다시 확인했습니다. 진행자가 "세 가지가 뭐라고 했죠"라고 묻고 참가자가 답하는 식이었고, 확인된 것은 기존 방식 내려놓기, 매일 Claude Code로 업무를 시작하기, 호들갑에 말리지 않기입니다. 이 세 원칙은 교안덱 4장에 그대로 예고돼 있고, "3주차에 다시 꺼내는 이유"도 함께 적혀 있습니다. 에이전트를 여러 개 돌리려면 손이 먼저 비어 있어야 한다는 것입니다. 세 원칙을 교안덱 문구와 대조해 정리한 것은 내려놓기와 보는 눈 ①절에 있습니다.
진행자는 교안덱을 처음부터 끝까지 넘기며 이번 주에 무엇을 할지 다 보여 줬습니다. "이번 주에 뭘 할 건지 다 보여 줘야 그다음에 뭘 하겠구나 하고 인지가 되니까"가 이유였습니다. 교안덱의 그림에 대해서는 "Codex를 썼으면 이미지를 뽑아 줬을 텐데 이건 Claude가 SVG로 그냥 만든 것 같다"고 했고, 원칙 카드에 "호들갑"이 들어가 있는 것을 보고 "난 안 적었는데 말을 이해했나 보다"라고 했습니다.
교안덱 STEP
교안덱에 적힌 내용
STEP 1
과제 회고 — 과정을 나눈다
STEP 2
1주차 되돌아보기 — 세 원칙 재확인
STEP 3
내려놓기 · 보는 눈 — 판단 기준 세우기
STEP 4
오픈클로 · 슬랙봇 — 설치부터 완성까지
STEP 5
LLM Wiki — "AI가 찾아가는 길"
교안덱 2장에 예고된 오늘의 순서입니다. 도착점은 "터미널 → 챗 플랫폼 → 노트북 없이도"로 적혀 있습니다. 이 구간에서 나온 오픈클로·슬랙봇·크론 이야기는 오픈클로와 에이전트에 도구별로 정리해 뒀습니다.
⑤조직에서 AI 전환이 부딪히는 것 (01:03–01:51)
이 구간은 사내 조직·인물에 관한 이야기가 대부분이라 대외 공개 기준에 따라 대부분 제외했습니다. 아래에는 조직에서 AI 전환을 시도할 때 일반적으로 부딪히는 부분만 중립적으로 남깁니다. 특정 인물·회사·금액·직책은 적지 않았습니다.
이야기는 ④에서 나온 원칙 "기존 방식을 내려놓는다"가 실제로는 굉장히 어렵다는 말에서 시작됐습니다. 기존 업무를 그대로 하면서 새 도구를 같이 쓰는 동안 업무가 산만해진다고 참가자가 자기 상황으로 이야기했고, 진행자는 과도기에는 원래 그렇다고 답했습니다. 여기서 일반화해 남길 수 있는 것은 다섯 가지입니다.
01과도기에는 업무가 산만해진다
기존 방식으로 하던 일이 계속 들어오는 상태에서 새 도구를 같이 쓰면 한쪽에 집중하기 어렵습니다.
02팀에서 혼자 바꾸려 하면 힘들다
다 같이 하든지, 아니면 하지 않든지라는 말이 나왔습니다.
03반감의 원인은 두 가지다
새로 배워야 한다는 부담, 그리고 무엇을 할 수 있는지 몰라 필요성을 못 느끼는 것입니다.
04알려 주는 사람과 시간, 그리고 성과가 필요하다
옆에서 알려 주면 화면 하나만 보면 되니 오히려 편하다는 이야기가 나왔고, 익숙해져 성과가 보이기까지는 몇 달이 걸립니다.
긴 이야기를 마치며 진행자가 ④에서 말한 원칙을 다시 꺼냈습니다. "이 많은 얘기를 했지만 결국 쥔 것을 놓아야 한다"는 것입니다. 그러면서 자기가 멘토링에서 선물받은 책이 한비자였다고 하고, 그 책에서 가져온 표현을 소개했습니다.
결국에는 쥔 것을 놓아야만 됩니다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 됩니다. 내가 쥐고 있는 것을 내려놓을 수 있어야 다른 것을 쥘 수 있습니다. 영향력을 키우려면 자기가 내려놓을 줄도 알아야 하고, 지금 시대에는 더 그렇습니다.
진행자 · 1교시 01:56 구간
이 말이 실무에서 무엇을 뜻하는지 평이하게 옮기면 이렇습니다. 지금까지 쓰던 도구와 작업 순서를 그대로 두고 새 도구를 하나 더 추가하는 방식으로는 바뀌지 않습니다. ⑤에서 나온 "업무가 산만해진다"는 것도 두 방식을 동시에 유지하고 있기 때문입니다.
진행자는 앞서 ④ 구간에서도 같은 이야기를 다른 예로 들었습니다. 손에 무언가를 들고 있으면 그 자리에 다른 것을 놓을 수 없다는 것입니다. 교안덱 5장에도 같은 예가 세 가지로 예고돼 있고, 각각이 실무에서 무엇을 뜻하는지는 내려놓기와 보는 눈 ②절에 표로 정리했습니다.
⑦보는 눈 — 판단 기준을 늘린다 (01:58–02:01)
내려놓기 이야기에 이어 진행자가 경고 하나를 꺼냈습니다.
AI를 많이 쓰다 보면 주리 님도 요새 많이 느낄 텐데, 점점 내가 바보가 된다는 느낌이 듭니다. 그 느낌이 두 달 세 달 지나면 옵니다. 얘한테 시키고 그다음 그냥 실행만 시키고 끝나 버리면 진짜 그렇게 됩니다.
진행자 · 1교시 01:58 구간
주리 님도 "진짜 바보 되고 있다"고 답했습니다. 진행자가 이어서 제시한 대안은 세 가지입니다.
대안 01왜 그렇게 나왔는지 물어본다
결과를 받고 끝내지 않고 이유를 설명해 달라고 합니다. ②의 Figma 결과나 디자인 시스템도 물어보면 설명해 줍니다.
대안 02다음에 무엇을 할지 스스로 제시한다
Claude는 작업이 끝나면 다음에 무엇을 하면 좋을지 제시해 줍니다. 사람도 그렇게 하는 쪽을 관리자가 좋아한다고 했습니다.
대안 03판단 기준의 수를 늘린다
동현 님이 이번에 "이렇게 했을 때 결과가 달라지는구나"를 느낀 것이 기준 하나가 늘어난 것입니다.
일하는 방식도 함께 바뀝니다. 예전에는 하나에 몰입해서 일했다면, 이제는 여러 개를 병렬로 시켜 놓고 자기가 판단하면서 집중할 것 몇 가지에 집중하는 쪽이 성과가 난다고 했습니다. 교안덱 6장에도 같은 내용이 예고돼 있습니다. "실행만 하고 멈추면 바보가 된다", "AI를 쓰더라도 보고 판단하는 힘은 내가 기른다"입니다. 세 대안을 교안덱 6장 항목과 맞춰 정리한 것은 내려놓기와 보는 눈 ⑤⑥절에 있습니다.
⑧규칙이 병목이 될 때 · 오래 도는 작업 (02:01–02:07)
이어서 최근 흐름 이야기가 나왔습니다. 1년 전 모델과 지금 모델을 비교하면 격차가 크고, 앞으로 더 커질 것이라고 했습니다. 그러면서 하네스에 대한 지적이 나왔습니다.
지금 만들어 놓은 하네스 자체가 병목이라는 이야기가 나옵니다. 모델이 더 잘하게 됐는데 절대 규칙이라고 만들어 놓은 것들이 오히려 방해가 되어 결과에 영향을 끼친다는 것입니다. 다만 있는 건 있으면서, 걷어낼 건 걷어내야 합니다.
진행자 · 1교시 02:02 구간
규칙 전체를 없애라는 말이 아니라, 유지할 것과 걷어낼 것을 구분하라는 것입니다.
오래 도는 작업 이야기도 나왔습니다. 진행자 팀에서 60여 시간짜리 학습을 금요일부터 월요일까지 돌린 사례입니다. 그냥 두면 끝까지 가지 않고 중간중간 확인해서 맞는지 승인해 줘야 한다는 것이 요지였습니다. 확인 지점을 어디에 두는지는 오픈클로와 에이전트 ⑤절에 정리했습니다.
지금 흐름은 하나가 아니라 여러 개를 함께 쓰는 쪽이고, 에이전트 그래프가 그 예로 나왔습니다. 봇을 여러 개 만들어 서로 토론하게 하고 그 결과를 받는 방식으로, 사람이 일하는 방식과 같습니다. 다만 봇끼리 주고받는 데는 제한을 걸어 둡니다. 주리 님이 "한 봇이 다른 봇에게 도움을 요청했는데 대답을 안 해 줬다"고 하자, 진행자는 대답해 주는 대상이 지정돼 있어서라고 답했습니다. 너무 자주 주고받으면 그 양이 늘어나서 제한을 뒀다는 설명이었습니다.
같이 나온 이야기 — 고맙다는 표현과 토큰
주리 님이 봇에게 고맙다고 말한다고 하자 진행자는 고맙다는 표현도 토큰을 더 쓴다고 답했습니다. 다만 그렇게 주고받은 것이 사용자 단위로 계속 누적되어 그 사람의 성향을 따라간다고 했습니다. 봇도 설정을 어떻게 해 주고 어떻게 피드백을 주느냐에 따라 결과가 달라지므로, 처음부터 잘되지 않는 것은 계속 피드백을 주며 맞춰 가야 한다는 것입니다.
⑨이번 주 실습 준비 (02:07–02:11)
진행자가 오늘의 목표를 한 문장으로 정리했습니다. 2주차보다 한 단계 더 나아가서, 내가 자리에 없을 때도 작업이 진행되게 만드는 것입니다. 밤사이에도 계속 진행되게 해 두는 것을 예로 들었습니다.
그다음 실습 준비 절차를 안내했습니다.
1스터디 아카이브를 다운로드한다
진행자가 슬랙에 공유해 둔 스터디 아카이브를 각자 받습니다.
2로컬에서 코드를 관리하는 위치에 넣고 압축을 푼다
깃 같은 것으로 관리하는 자기 로컬 폴더 안에 넣고 압축을 풉니다.
3터미널을 하나 더 열고 그 폴더로 이동해 Claude Code를 켠다
이미 다른 폴더 안에 들어가 있다면 cd .. 로 한 단계 밖으로 나온 뒤 스터디 아카이브 폴더로 이동합니다.
cd ..
cd study-archive
claude
이번 주 실습은 각자 교안을 직접 만드는 것이라, 이 녹음이 그 원자료가 됩니다. 1교시는 진행자가 참가자에게 녹음을 종료해 달라고 요청하며 끝났습니다.
이어서 볼 문서
이 문서는 시간 순서대로 정리한 기록입니다. 같은 내용을 주제별로 정리한 문서가 세 개 더 있습니다.
3주차 1교시는 2주차 과제 2건을 화면에 띄워 놓고 같이 보는 것으로 시작했습니다. 동현 님은 부모님 음식점 홍보 웹사이트를, 주리 님은 리뷰 설명을 준비하는 스킬을 만들어 왔습니다.
이 문서는 두 결과물을 어떤 순서로 만들었고, 무엇이 효과가 있었고, 어디서 지적을 받았는지로 다시 정리한 것입니다. 시간순 기록은 1교시 강의기록에 있습니다.
이 시간의 초점
교안덱 3장은 과제 회고를 “결과가 아니라 과정”으로 적어 두고, 확인할 것을 세 가지로 나눴습니다. 어디서 막혔나 · 무엇을 내려놓았나 · 다음엔 무엇을 바꾸나. 그래서 이 자리에서 오간 말은 대부분 그 결과가 나오기까지 무엇을 어떻게 시켰는지에 대한 질문이었습니다.
두 과제 한눈에
과제 ① 부모님 음식점 홍보 웹사이트(동현 님) — 2주차까지 배운 MCP · 레퍼런스 활용 · Codex CLI 이미지를 한 작업에 함께 쓰고, Figma MCP로 시안을 만든 뒤 HTML 사이트까지 확장했습니다. 평가 10점 만점에 9.5점.
과제 ② 리뷰 설명을 준비하는 스킬(주리 님) — 목업·기획 문서와 지난 리뷰 전사를 넣으면 설명 대본과 TTS 음성, 확인용 화면이 나오는 이지 익스플레인 스킬을 만들었습니다. 평가 10점 만점에 9점.
두 과제에서 반복해서 나온 지적은 하나였습니다. 맥락을 얼마나 빼고 시켰는가, 그리고 나온 결과물을 끝까지 확인했는가.
①과제를 설명하는 순서 — 목적 → 과정 → 결과
수업은 두 사람이 각자 “이번 과제가 무엇이었는지”를 먼저 설명하는 순서로 진행했습니다. 진행자는 설명이 짧게 끝나자 바로 순서를 정정했습니다.
“목적이 무엇이었고, 그 과정에서 뭐가 있었고, 그래서 이렇게 한번 해 보기로 했습니다 — 이렇게 얘기하는 게 정석입니다.”
진행자 · 1교시 도입부
① 목적
무엇을 위해 하는 작업인가. 과제 ①은 부모님 가게 홍보용 사이트, 과제 ②는 팀 리뷰에서 할 설명 준비였습니다.
→
② 그 과정에서 있었던 것
무엇을 시도했고 어디서 막혔는가. 첫 결과가 기대와 달랐던 지점, 맥락을 다시 넣어야 했던 지점을 말합니다.
→
③ 그래서 이렇게 해 봤다
그래서 실제로 만든 결과물. 시안·사이트·스킬처럼 열어서 보여 줄 수 있는 것입니다.
이 순서를 지켜야 하는 이유는 사람에게 설명할 때나 AI에게 지시할 때나 같습니다. 배경을 빼고 요구만 말하면 듣는 쪽이 무엇을 원하는지 알 수 없습니다.
“맥락 쏙 다 빼놓고 그렇게 설명하면, 내가 뭘 바라는 목적을 가지고 있고 뭘 만들어 줘야 되는지 잘 모르니까. 모호할수록 결과는 잘 안 나오니까.”
진행자 · 과제 설명 순서를 짚으며
같은 지적이 과제 ①에도 한 번 더 나왔습니다. 동현 님은 페르소나 부여와 점수 기준 같은 방법을 실제로 썼는데 과제 설명에서는 빼놓았고, 진행자는 “그런 건 과제 설명할 때 같이 얘기해야지”라고 했습니다. 쓴 방법을 말하지 않으면 결과만 남고 재현할 방법이 전달되지 않습니다.
②과제 ① — 부모님 음식점 홍보 웹사이트 (동현 님)
진행자가 정리한 과제의 목적은 “여러 도구의 연결점을 자기 목적에 맞게 한 번에 써 보는 것”이었습니다. 2주차까지 배운 MCP, 레퍼런스 활용, Codex CLI 이미지 생성을 한 작업 안에서 조합하고, 그 결과를 Figma MCP로 시안까지 옮겨 보는 것입니다.
교안덱 3장 왼쪽 그림을 전사에서 오간 순서에 맞춰 다시 그린 것입니다. 덱에는 재료가 MCP · 에이전트 · 레퍼런스로 적혀 있고, codex 이미지는 Figma MCP 다음 산출물 자리에 있으며, HTML 사이트는 없습니다. 덱의 확인 질문은 “기준을 먼저 정했는가”입니다.
진행 단계
01목적 정하기
만들고 싶은 사이트가 떠오르지 않던 차에 가족의 제안으로 어머니 가게 홍보 사이트를 정했습니다. 어머니도 홍보용으로 있으면 좋겠다고 말한 적이 있었습니다.
02방송 영상에서 이미지·워딩 확보
가게가 지역 맛집 방송에 두 번 나갔던 것을 떠올려, 클로드에게 그 영상을 먼저 찾게 했습니다. 영상에서 이미지를 캡처하고 방송에 나온 워딩 중 쓸 만한 것을 정리하게 했습니다.
03첫 결과가 기대와 다름
Figma MCP로 처음 나온 시안이 생각하던 결과물이 아니었습니다. UI 레퍼런스 사이트를 쓰려 했지만 잘 반영되지 않았고, 본인 표현으로는 “딱 뭘 찝어 주지 않았기 때문”이었습니다.
04레퍼런스 다시 잡기
참고할 사이트를 직접 검색해 달라고 해서 막국수 사이트를 레퍼런스로 받고, 그 구성에 맞춰 다시 만들게 했습니다.
05톤·색 맞추기
워딩은 장인정신이 느껴지는 방향으로 요청했습니다. 색은 따로 지정하지 않았는데도 가게 실제 인테리어와 같은 초록·네이비 계열이 나왔습니다.
06화질 보완 · Codex CLI 이미지
방송 캡처 화질이 낮아 고화질로 다시 캡처하게 하고, AI 생성 이미지 대신 Codex CLI로도 이미지를 만들어 함께 썼습니다. 한 번에 다 넣지 않고 대화하듯 나눠서 요청했습니다. 다만 토큰 한계와 영상 원본의 한계가 있어 HTML 쪽 사진은 화질이 낮고 잘린 부분이 남았습니다.
07HTML 사이트로 확장
시안이 한 페이지처럼 보이는 것이 아쉬워 HTML 사이트 형태로도 만들었습니다. 과제 범위 밖이었지만 진행자는 “자기 시간 내서 더 시도한 것”으로 좋게 평가했습니다.
효과가 있었던 방법 세 가지
역할 지정
에이전시 스쿼드 페르소나
“UI·UX 전문 웹 에이전시의 스쿼드를 구성해서 기획자·디자이너·개발자를 다 넣어라”라고 지시했습니다. 디자인 시스템을 시키지 않았는데도 파운데이션·컴포넌트가 나온 것은 이 지시의 결과로 보였습니다.
참고 방식
레퍼런스 요소 추출
레퍼런스를 통째로 “참고해라”라고 하는 대신, 레퍼런스 안의 요소를 하나씩 추출해 참고하라고 지시했습니다. 사이트를 직접 골라 준 뒤부터 결과가 달라졌습니다.
반복 기준
100점 만점 95점
“100점 만점에 95점이 되도록 돌려라”라는 점수 기준을 걸어 스스로 평가하고 다시 만들게 했습니다. 수업에서는 레퍼런스를 직접 골라 주고 점수 기준을 건 덕분에 이미지도 더 신경 써서 나온 것 같다는 평가가 나왔습니다.
놓친 것 — 결과물을 끝까지 열어 보지 않았다
화면을 같이 열어 보니 Figma 파일에는 커버 말고도 데스크톱·모바일 화면과 파운데이션·컴포넌트 페이지가 이미 만들어져 있었습니다. 동현 님은 그중 커버만 보고 “결과가 이것뿐”이라고 판단해, 나머지는 HTML 쪽에서 다시 작업했습니다.
“커버만 보고… 솔직히 몰랐어요, 이렇게까지 나온 줄.”
동현 님 · Figma 파일을 다시 열어 보며
진행자는 “결과는 만들어져 있는데, 본인이 그걸 했느냐 안 했느냐가 중요하다”고 짚었습니다. 그 자리에서는 “클로드에게 ‘안 보인다’고 말했으면 알려 줬을 것”이라는 말도 나왔습니다. 만들어진 것을 확인하지 않으면 이미 나와 있는 결과물도 쓰지 못합니다.
평가 9.5점. 진행자는 결과물을 보고 “어떤 과정을 거쳤는지 느껴진다, 시간을 많이 쏟았을 것 같다”고 했습니다. 동현 님이 “과제로 끝나는 게 아니라 진짜 해주고 싶어서”라고 답하자, 진행자는 하고 싶은 일을 찾으면 스스로 더 하게 된다는 점을 짚었습니다.
같이 한 과제 — 영상 프레임 분석 스킬
2주차 과제는 홍보 웹사이트 한 건이 아니었습니다. 진행자는 과제 설명을 들은 뒤 영상을 분석해 이미지로 잘라 내고 그 안에 무슨 내용이 나오는지 보게 하는 것도 해 봤는지 물었고, 동현 님은 그것도 했다고 답했습니다.
동현 님이 말한 방법은 이렇습니다. 가족이 “이런 게 있는데 만들면 어떨 것 같으냐”고 보여 준 영상을 프레임 단위 이미지로 쪼개 어떻게 만든 것인지 확인하고, 거기에 리서치 결과를 더해 도안을 만드는 데까지 썼습니다.
같은 방법을 부모님 음식점 사이트 작업 안에서도 그대로 썼습니다. 한 줄 평에서 동현 님은 “영상을 프레임별로 쪼개는 것도 이 사이트 안에서 해 봤다”고 말했습니다. 진행자는 해야 할 과제를 빼놓고 더 재미있는 쪽만 했다면 점수가 박했을 것이라며, 이 과제까지 한 점을 9.5점을 준 이유 중 하나로 들었습니다.
다음 액션
작업을 끝낸 세션에서 스킬로 남기기. 진행자는 이 작업을 끝낸 세션에 그대로 “다음에 또 이런 작업을 할 테니, 지금까지 한 것 중 이어지는 것을 대상으로 스킬을 구조화해 만들어 달라”고 요청하라고 했습니다. 세션을 닫았더라도 resume으로 다시 찾을 수 있고, 찾기 어려우면 클로드에게 해당 세션 아이디를 찾아 달라고 하면 됩니다.
③과제 ② — 리뷰 설명을 준비하는 스킬 (주리 님)
과제는 진행자가 냈고, 주리 님이 그 배경과 목적을 직접 설명했습니다. 팀에서 기획자로 리뷰할 때 전체 맥락을 구조적으로 설명한 다음 세부로 들어가야 하는데 그 부분이 부족하고 빼먹는다는 문제였습니다. 그동안 리뷰한 기록을 클로드에 넣어, 자동화든 스킬이든 방법은 상관없이 쉽게 설명할 수 있는 산출물을 만드는 것이 과제였고, 그 안에 TTS 음성과 구조화된 대본이 포함돼야 했습니다.
교안덱 3장 오른쪽 그림은 “설명할 것(머릿속)”에서 “구조화 스크립트”를 거쳐 “음성”으로 가는 세 칸짜리 순서도입니다. 위 그림은 거기에 주리 님이 실제로 넣은 자료와 나온 결과물을 더해 그린 것입니다. 덱의 확인 질문은 “청중이 들을 수 있는가”입니다. 리뷰하는 날에는 왼쪽에 설명할 문서, 오른쪽에 확인용 화면을 띄워 놓고 설명을 연습합니다.
대본 5단 구조
단계
무엇을 쓰는가
왜 이 단계가 필요한가
1. 여기까지 온 이야기
지난 리뷰에서 어떤 논의가 있었고 무엇이 반영됐는지
듣는 사람은 지난주 이후 무엇이 바뀌었는지 모릅니다. 본인이 자주 빼먹던 부분입니다.
2. 전체 그림
오늘 할 리뷰가 몇 가지이고 서로 어떻게 연결되는지
배경 없이 세부부터 들어가면 “지금 무슨 얘기 중이냐”는 반응이 나옵니다.
3. 하나씩
건별 결론 · 왜 그렇게 했는지 · 예시
전체 그림을 본 뒤에 세부를 들어야 이해됩니다.
4. 듣는 사람 입장
이 문서로 무엇이 달라지는지
과제의 목적 자체가 듣는 사람에게 그려지게끔 설명하는 것이었습니다.
5. 질문
어떤 질문이 나올 수 있는지
리뷰 자리에서 나올 질문을 미리 적어 둡니다.
준비에서 잘한 것 — 볼 범위를 좁혀 준 것
스킬을 만들기 전에 약 8시간 분량의 리뷰 전사를 넣고, 다른 세션이나 메모에 있는 내용은 보지 말고 이 전사만 놓고 내 리뷰의 문제점과 말버릇, 고쳐야 할 점을 먼저 짚어 달라고 요청했습니다. 이 방식으로 자주 쓰는 말버릇이 정리됐고, 그 결과를 스킬 규칙에 넣었습니다.
진행자는 자기 목소리를 직접 들으며 문제를 찾는 일이 힘들다는 점을 들어, 사람이 다 들어 보고 확인할 필요가 없다는 것을 이 방식의 장점으로 짚었습니다. 동현 님도 영업에서 설명할 때 자기 말버릇을 인지하고도 고치는 방법을 몰랐다며, 같은 방식을 쓸 수 있겠다고 했습니다.
시행착오 — 목적이 다른 문서로 방향이 잡혔다
과제의 목적은 리뷰에서 할 설명을 미리 준비하는 것이었는데, 클로드는 이것을 회의가 끝난 뒤 팀에 공유하는 문서로 이해하고 그 방향으로 만들었습니다. 그래서 “회의 결과를 팀에 설명할 때가 아니라, 앞으로 리뷰가 있을 때나 리뷰 후 회고할 때 쓰는 것”이라고 목적을 다시 넣어야 했습니다.
또 “개발자에게 설명할 것”이라고만 말하고 듣는 사람이 이 주제를 미리 아는지는 말하지 않아, 방향이 계속 어긋나고 같은 이야기를 반복하는 대본이 나왔습니다. 점수가 오르지 않은 원인도 여기에 있었습니다.
“여기서도 정말 맥락을 많이 빼먹었구나라고 생각하면서 과제를 진행했고…”
주리 님 · 목적을 다시 넣은 뒤
스킬을 리뷰 전후로 이어서 쓰는 방법
리뷰 전에는 이번에 설명할 목업 문서와 지난 리뷰 녹취를 넣어 리뷰 대본을 만듭니다. 리뷰를 진행하면서 녹취한 것을 다시 같은 스킬에 넣으면 회고 문서가 나오고, 그 회고 문서가 다음 리뷰 준비의 입력이 됩니다. 수업에서는 실제 음성 예시도 함께 재생해 확인했습니다.
음성을 들어 본 뒤 주리 님은 대본을 눈으로 읽는 것과 듣는 것이 확실히 다르다고 했고, 진행자도 팟캐스트를 듣듯 들으면 이해가 잘 된다고 했습니다.
평가 9점 + 지적. 진행자는 결과물 정리는 잘돼 있다고 보면서도, 설명 순서를 지적했습니다. “차라리 결과물을 먼저 보여 주고 난 뒤에 하나씩 설명했으면 잘 이해가 됐을 것”이라며, 듣는 입장에서는 결과물을 보기 전까지 무엇을 하려 했는지 집중이 되지 않았다고 했습니다. 스크립트와 음성만 만들면 되는 과제였는데 준비 과정까지 만들어 온 점은 좋게 평가했습니다.
다음 액션
문체 검사 스킬과 함께 발전시키기. 주리 님은 클로드가 문서를 쓸 때 “엽니다 · 닫습니다 · 돕니다” 같은 추상적인 표현을 자주 써서 기획 문서에서 무슨 뜻인지 알기 어려울 때가 많다며, 그런 표현을 줄이는 스킬을 따로 만들어 두었다고 했습니다. 이번 대본에도 그런 표현이 남아 있어, 문체 검사 스킬과 이지 익스플레인 스킬을 함께 발전시키겠다고 정리했습니다. 진행자는 “결과는 한번 만들어 봤으니 다듬는 건 본인 몫”이라며 피드백을 몇 번 주면서 만들 것을 권했습니다.
④두 과제에서 공통으로 나온 것
만든 것은 달랐지만 잘된 지점과 막힌 지점은 겹쳤습니다.
항목
과제 ① 홍보 웹사이트
과제 ② 리뷰 설명 스킬
여기서 배울 것
목적을 어디서 가져왔나
가족의 제안에서 시작해, 실제로 부모님께 만들어 드리고 싶은 일이 됐습니다.
팀 리뷰에서 맥락을 구조적으로 설명하지 못한다는 본인 문제에서 출발했습니다.
스스로 하고 싶은 일이면 시키지 않아도 더 찾아서 합니다.
맥락을 어떻게 줬나
에이전시 스쿼드 페르소나 + 참고할 사이트 지정 + 방송 영상 지정
8시간 리뷰 전사 + “다른 자료 말고 이 전사만 보라”는 범위 지정
참고할 것과 보지 말 것을 함께 정해 줍니다.
무엇을 반복했나
100점 만점 95점 기준으로 점수를 매겨 다시 만들게 했습니다.
대본 점수가 오르지 않을 때마다 빠진 맥락을 채워 다시 요청했습니다.
한 번에 끝내지 않고 대화하듯 나눠서 요청합니다.
어디서 막혔나
첫 시안이 기대와 달랐고, 만들어진 페이지를 커버만 보고 지나쳤습니다.
목적이 “회의 후 공유 문서”로 잘못 잡혀 방향을 다시 잡아야 했습니다.
결과물을 끝까지 열어 보고, 목적 문장을 먼저 확인합니다.
받은 점수
10점 만점에 9.5점. 과제 범위 안에 있던 영상 프레임 분석 스킬까지 한 점도 함께 반영됐습니다.
10점 만점에 9점
점수보다 감점 이유가 다음 액션이 됩니다.
다음 액션
작업을 끝낸 세션에서 스킬로 구조화해 남기기
문체 검사 스킬과 함께 발전시키기
이번 작업의 방법을 다음 작업의 입력으로 남깁니다.
⑤다음에 같은 작업을 할 때 — 체크리스트
두 과제에서 나온 방법과 지적을 순서대로 옮긴 것입니다.
01목적을 한 문장으로 먼저 적는다
무엇을 위해 하는 작업인지 적고 시작합니다. 과제 ②처럼 이 문장이 없으면 다른 목적의 결과물이 나옵니다.
02참고할 것과 보지 말 것을 같이 지정한다
참고 사이트를 직접 골라 주고, 볼 자료의 범위도 “이것만 보라”로 좁혀 줍니다. 열어만 두면 잘 반영되지 않습니다.
03역할을 정해 준다
기획자·디자이너·개발자처럼 맡을 역할을 지정합니다. 시키지 않은 산출물이 그 역할에서 나오기도 합니다.
04점수 기준을 걸어 반복시킨다
“100점 만점에 95점” 같은 기준을 정해 스스로 평가하고 다시 만들게 합니다.
05결과물을 끝까지 열어 본다
커버·첫 화면만 보고 판단하지 않습니다. 확인하지 않으면 이미 만들어진 것도 쓰지 못합니다. 안 보이면 안 보인다고 말하면 됩니다. 웹 화면을 만들었다면 데스크톱뿐 아니라 모바일 크기까지 봅니다.
만든 화면을 모바일 크기로 확인하는 법
확인할 화면을 크롬에서 엽니다.
맥에서는 커맨드 + 옵션 + I 를 누릅니다. 단축키 대신 크롬 메뉴에서 도구를 누른 다음 개발자 도구를 눌러도 됩니다.
열린 화면 위쪽에서 기기 목록을 펼치고 아이폰처럼 볼 기기를 고르면, 그 크기에 맞춰 화면이 표시됩니다.
1교시에서는 이 방법을 몰라 모바일 화면을 확인하지 못한 채 넘어간 상황이 나왔습니다. 순서만 알면 만든 자리에서 바로 확인할 수 있습니다.
06끝낸 세션에서 스킬로 남긴다
작업을 마친 그 세션에서 지금까지 한 것을 스킬로 구조화해 달라고 요청합니다. 다음에 같은 작업을 할 때 맥락을 처음부터 다시 넣지 않아도 됩니다.
07설명할 때는 결과물부터 보여 준다
결과물을 먼저 보여 준 뒤 과정을 설명합니다. 듣는 사람은 그때부터 “이걸 만들려고 저걸 했구나”로 따라옵니다.
동현 님이 Figma 파일 안의 파운데이션·컴포넌트 페이지를 과제에 쓰지 못한 원인은 무엇이었습니까?
해설 — 수업에서 파일을 다시 열어 보니 데스크톱·모바일 화면과 파운데이션·컴포넌트 페이지가 이미 만들어져 있었습니다. 동현 님은 “커버만 보고”, “이렇게까지 나온 줄 몰랐다”고 답했습니다.
두 과제에서 지적받은 지점은 같았습니다. 맥락을 얼마나 넣어 시켰는지, 그리고 나온 결과를 끝까지 확인했는지입니다.
이어서 볼 문서 — 1교시에 오간 말을 시간순으로 보려면 1교시 강의기록, 이 회고 뒤에 이어진 “내려놓기와 보는 눈” 이야기는 내려놓기와 보는 눈에서 다룹니다.
내려놓기와 보는 눈 — 에이전트로 넘어가기 전에 정리한 것
3주차 교안덱 표지에 적힌 제목은 “에이전트 — 쥔 것을 놓고, 보는 눈을 기른다”입니다. 1교시에서 가장 오래 이야기한 주제도 이 두 가지였습니다.
진행자가 1교시에 예고한 순서는 기존 방식을 내려놓는 것 → 보는 눈을 기르는 방법 → 오픈클로·슬랙봇 붙이기 → AI가 잘 찾아가게 만들기였습니다. 이 문서는 그중 앞의 두 가지를 정리했습니다.
1교시에서 먼저 정리한 것
에이전트를 여러 개 돌리는 방법으로 들어가기 전에, 지금 쓰던 방식을 그만두는 일과 결과를 받아 들고 판단하는 일을 먼저 정리했습니다. 도구 설치는 그다음 순서입니다.
이 문서 핵심
내려놓기는 기존 업무 방식과 도구를 그대로 두고 새 방식을 하나 더 추가하는 상태를 말하지 않습니다. 기존 방식을 그만 쓰고 새 방식으로 바꾼다는 뜻이고, 그래서 실제로는 어렵습니다.
보는 눈은 결과를 받은 다음에 하는 일입니다. 시키고 받고 끝내면 두세 달 뒤에 스스로 판단하지 않게 되고, 왜 그렇게 됐는지 묻고 다음 스텝을 정하면 판단 기준이 하나씩 늘어납니다.
둘을 합치면 3주차 목표가 됩니다. 여러 개를 병렬로 시켜 놓되, 하려는 것은 내가 명확하게 안다.
①1주차 세 원칙 다시 보기
1교시 중반에 진행자가 “1주차에 세 가지 중요하다고 했죠”라고 물었습니다. 참가자가 먼저 꺼낸 것은 호들갑에 휘둘리지 않는다였고, 진행자가 내려놓는다와 매일 쓴다를 이어서 확인했습니다. 참가자는 마지막을 “하는 걸 믿고 일단 해본다”로 정리했습니다.
원칙 01
기존 방식 내려놓기
교안덱 4장 문구는 “업무 방식은 일단 내려놓는다”입니다. 전사에서는 진행자가 “다 내려놓고”로 첫 번째 원칙을 확인했습니다.
교안덱 문구는 “호들갑 떨지 않고 중심을 잡는다”입니다. 참가자가 세 원칙 중 가장 먼저 떠올린 항목이 이것이었습니다.
“에이전트를 여러 개 돌리려면, 손이 먼저 비어 있어야 한다”
교안덱 4장 — 3주차에 세 원칙을 다시 꺼낸 이유
실제로 하는 일로 옮기면 이렇습니다. 에이전트 여러 개에 일을 나눠 맡기려면, 지금 사람이 직접 하고 있는 작업을 먼저 그만두어야 합니다. 그 작업을 사람이 계속 하고 있으면 에이전트에게 넘길 일이 남지 않습니다.
②“내려놓는다”가 실제로 뜻하는 것
1교시에서 진행자는 “내려놓는다”를 두 가지 예로 설명했습니다.
“내가 음료수 하나를 들고 있잖아요. 들고 있으면 여기서 하나 더 쥐기 쉽지 않잖아요. 그래서 이걸 내려놔야 다른 걸 쥘 수 있는 거예요.”
1교시 · 진행자가 손에 든 음료를 들어 보이며 (제품명은 일반 표현으로 바꿨습니다)
실무로 옮기면, 한 사람이 동시에 유지할 수 있는 업무 방식의 수가 정해져 있다는 말입니다. 새 방식을 제대로 쓰려면 기존 방식 하나를 정리해야 합니다.
“쥔 것을 놓아야만 된다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 된다. 내가 쥐고 있는 것을 내려놓을 수 있어야 다른 걸 쥘 수 있다.”
1교시 · 진행자가 소개한 한비자 이야기
이 인용에서 가져갈 실무 의미는 하나입니다. 다룰 수 있는 범위를 넓히려면 지금 하고 있는 것 중 일부를 끝내야 합니다. 진행자는 “지금 시대에 더 그렇다”고 덧붙였습니다.
교안덱 5장 표현
슬라이드 요약
1교시에서 말한 실무 의미
꽃이 지고 → 열매가 된다
져야 맺힌다
지금 하던 작업을 끝내야 다음 결과가 나온다
강이 마르고 → 바다가 된다
말라야 넓어진다
쓰던 방식을 줄여야 다룰 수 있는 범위가 늘어난다
손을 비우면 → 다른 것을 쥔다
비워야 쥔다
사람이 직접 하던 일을 그만두어야 에이전트에 맡길 수 있다
왼쪽 두 열은 교안덱 5장에 그대로 적힌 표현이고, 오른쪽 열은 1교시 설명을 실무 문장으로 옮긴 것입니다.
원칙을 확인하는 것과 실제로 바꾸는 것은 다릅니다. 1교시에서 한 참가자가 지난 3주를 이렇게 회고했습니다.
“다 세팅이 되면 좋은데, 기존에 해 놓은 것들이 있잖아요. 그걸 안 하게 되면 업무에 지장이 갑니다. 계속 들어오는 일은 있고, 쓰던 프로그램에 데이터가 있고, 해 오던 방식이 있는데, 이걸 완전히 내려놓는 게 산만해지고 머리가 아프더라고요. 원칙이라는 게 실제로는 되게 어렵구나 싶었습니다.”
1교시 · 참가자 회고
두 방식을 함께 쓰는 동안에는 작업이 나뉘고 집중이 끊깁니다. 진행자는 이 기간을 과도기라고 불렀고, 익숙해져서 성과가 나기까지 몇 달은 걸린다고 말했습니다.
그래도 결국 바뀐다고 본 근거로는, 지금 스프레드시트를 다루지 못하면 취업이 어려운 것처럼 이 방식도 기본 요건이 될 것이라는 이야기가 1교시에 나왔습니다.
③조직에서 부딪히는 것 — 일반화된 교훈만
이 대목은 1교시에서 약 50분간 이어진 대화입니다. 사내 사정과 개인 평가가 대부분이라 대외 공개 기준에 따라 개인·조직·금액을 특정할 수 있는 내용은 모두 제외하고, 어느 조직에나 해당하는 교훈과 조건만 남겼습니다.
01혼자 바꾸려 하면 오래 가기 어렵다
한 사람만 새 방식으로 일하면 나머지 업무는 예전 방식 그대로 남습니다. 1교시 결론은 같이 하거나, 하지 않거나였습니다.
02반감은 익숙하지 않은 데서 온다
터미널 화면을 처음 보면 어렵게 느껴집니다. 1교시에서 어려운 이유로 든 것은 안 해 봤기 때문이었고, 한 화면만 보면 되니 익숙해지면 웹보다 편해진다는 이야기가 이어졌습니다.
03옆에서 알려 주는 사람이 있어야 넘어간다
혼자 익히기는 어렵습니다. 옆에서 화면을 같이 보며 한 번 해 보면 넘어가는 지점이 많다는 것이 1교시 진행자의 답이었습니다.
04필요성은 무엇을 할 수 있는지 알아야 생긴다
관심이 없는 이유로 내가 뭘 할 수 있는지 모르니까가 나왔습니다. 그래서 결과를 공유해도 필요성으로 연결되지 않는 경우가 있습니다.
05성과가 보여야 수용된다
도입을 먼저 설득하기는 어렵고, 팀에 기여하는 결과가 나온 다음에 받아들여집니다. 구독료를 내는 것 자체가 첫 허들이고, 가치를 느껴야 지출이 됩니다.
06조직 차원에서는 도입·교육·평가가 함께 가야 한다
1교시에서 조직 차원의 조건으로 나온 것은 네 가지입니다. 조직 전체에 도구를 설치하고, 사용법을 알려 주는 자리를 열고, 정해진 기간 동안 실제로 쓰게 하고, 쓴 결과를 성과 평가에 반영하는 것입니다. 네 가지가 모두 진행돼야 전환이 될까 말까 하다는 것이 1교시 판단이었습니다. 01~05가 개인이 부딪히는 것이라면, 이 항목은 조직이 해야 하는 것입니다.
④보는 눈 — 실행만 시키면 판단력이 줄어든다
여기서부터 3주차의 두 번째 주제입니다. 진행자는 경고를 먼저 했습니다.
“AI를 많이 쓰다 보면 점점 내가 바보가 된다는 느낌이 들거든요. 그 느낌이 두 달, 세 달 지나면 옵니다.”
1교시 · 진행자
“진짜 저 바보 되고 있어요.”
1교시 · 참가자
진행자가 두 경우를 나눈 기준은 결과를 받은 다음에 무엇을 하느냐입니다.
“이걸 써서 더 잘 아는 것을 가지고 판단하는 능력을 키운다고 생각해야지, 시키고 실행만 시키고 끝나 버리면 진짜 바보가 된다고 느껴요.”
1교시 · 진행자
위쪽은 교안덱 6장 왼쪽의 경고 그림과 같은 구조입니다. 아래쪽 세 번째 칸의 “이유를 묻는다”는 1교시 표현으로 왜 그렇게 됐는지 물어본다입니다.
⑤판단 기준을 늘리는 세 가지
1교시 후반(전사 01:58~02:01 구간)에 진행자가 한 번에 이어서 말한 내용을 세 가지로 나눠 정리했습니다. 진행자가 “세 가지”라고 세어 제시한 것은 아닙니다.
교안덱 6장 오른쪽에도 세 항목(다음 스텝 · 판단 기준 · 일하는 법)이 적혀 있습니다. 아래 방법 02·03이 그중 다음 스텝·판단 기준에 해당하고, 방법 01은 교안덱에는 없고 1교시 발언에만 나옵니다. 교안덱의 일하는 법은 다음 ⑥절에서 다룹니다.
방법 01
왜 그렇게 만들었는지 물어본다
결과물을 받으면 이유를 물어봅니다. 1교시에서는 피그마로 만든 시안과 디자인 시스템을 예로 들었습니다. 내가 그 개념을 몰라도 설명을 요청하면 이해할 수 있고, 그 직군이 어떻게 일하는지도 알게 됩니다.
방법 02
다음 스텝을 스스로 제시한다
클로드는 작업을 끝내면 다음에 할 것을 함께 제안합니다. 진행자는 사람도 그렇게 제시하는 쪽이 관리자에게 좋은 평가를 받는다고 말했습니다. 시킨 것을 해 온 다음에 “그다음에는 이런 걸 해도 될지”를 덧붙이는 것입니다.
방법 03
기준의 수를 늘린다
의사결정의 결과는 내가 가진 판단 기준의 수에 따라 달라집니다. 이번 과제처럼 “이렇게 했더니 결과가 달라진다”를 확인할 때마다 기준이 하나씩 늘고, 그것이 보는 눈이 됩니다.
⑥일하는 방식 — 하나 몰입에서 병렬로
판단 기준이 늘면 일하는 방식도 바뀝니다. 1교시 표현은 이렇습니다. 예전에는 하나에 몰입해서 일했고, 이제는 여러 개를 병렬로 시켜 놓고 내가 판단하면서 몇 가지에 집중합니다.
예전
하나에 몰입 — 한 작업을 시작해 끝낼 때까지 그 작업만 진행
→
지금
여러 개를 병렬로 지시 — 에이전트 여러 개에 각각 작업을 맡김
→
사람이 하는 일
결과를 보고 판단 — 되는 것과 안 되는 것을 정하고, 집중할 몇 가지를 고름
오래 걸리는 작업이 실제로 어떻게 진행되는지, 1교시에서 사례가 나왔습니다.
금요일부터 월요일까지 60여 시간짜리 학습 작업을 돌린 사례입니다. 참가자는 “69시간쯤”으로 기억했고 진행자는 “60몇 시간”이라고 말했습니다. 요지는 시간이 아닙니다. 그냥 두면 끝까지 가지 않고, 중간중간 확인해서 맞는지 승인해 줘야 끝까지 진행됩니다. 사람이 항상 붙어 있을 수는 없으니, 결과를 받아 보고 되는 것과 안 되는 것을 판단해 주는 지점을 사람이 가집니다.
교안덱 6장 아래에는 이 대목의 결론이 한 줄로 적혀 있습니다. “결국 하려는 것을 명확하게 아는 것.” 진행자도 1교시에서 같은 말을 했습니다. “하려는 거 내가 명확하게 이해하는 게 중요해요.”
⑦규칙이 병목이 될 때 — 하네스
1교시 후반에 모델 성능 이야기가 나왔습니다. 1년 전 모델과 지금을 비교하면 차이가 크고 앞으로 더 좋아진다는 것이 전제입니다. 그래서 최근에는 하네스를 걷어낸다는 이야기가 나옵니다.
“지금 만들어 놓은 하네스 자체가 병목이다. 근데 있는 건 있으면서, 걷어낼 건 걷어내야 돼.”
1교시 · 진행자
이유는 단순합니다. 모델이 더 잘하게 되는데, 사람이 절대 규칙으로 만들어 둔 것들이 오히려 결과를 방해한다는 이야기가 나온다는 것입니다. 1교시에서 나온 판단은 하나입니다. 유지할 것은 두고, 걷어낼 것만 걷어낸다.
1교시에서 이 이야기가 나온 순서
잘하는 사람과 아닌 사람의 격차가 점점 커진다는 이야기
1년 전 모델과 지금 모델의 성능 차이
지금 트렌드는 하네스를 걷어내는 것이라는 이야기
지금 만들어 둔 하네스 자체가 병목이라는 말
있는 것은 두고, 걷어낼 것만 걷어낸다는 판단
그런 트렌드만 따라가면 된다는 정리
전사에는 하네스를 무엇으로 만들었는지에 대한 구체적인 목록은 나오지 않습니다.
⑧오늘 이후 세 줄
교안덱 마지막 장에 3주차 정리가 세 줄로 적혀 있습니다. 아래 카드의 제목이 교안덱 문장이고, 설명은 1교시에서 그 문장이 어떤 뜻으로 쓰였는지입니다.
01
병렬로 굴리되, 목적은 명확하게
여러 개를 동시에 시켜도 하려는 것은 내가 명확하게 안다는 뜻입니다. 1교시 표현으로는 “하려는 거 내가 명확하게 이해하는 게 중요하다”입니다.
02
실행하고 멈추지 말고 다음 스텝 검토
결과를 받은 다음에 왜 그렇게 됐는지 묻고, 다음에 할 것을 정합니다. 이 문서 ④·⑤절에서 정리한 내용입니다.
03
이번 주엔 내 봇에게 시켜보기
2교시 이후에 설치하는 오픈클로·슬랙봇으로 직접 시켜 봅니다. 설치 자체가 목표는 아니고, 시켜 보고 결과를 판단하는 데까지 가는 것이 과제입니다.
1교시에서 “시키고 실행만 시키고 끝낸다”의 문제로 말한 것은 무엇입니까?
해설 — 진행자는 “그 느낌이 두 달, 세 달 지나면 온다”고 말했고, 결과를 받은 다음에 이유를 묻고 다음 스텝을 정하는 사람만 판단 기준이 늘어난다고 이어서 설명했습니다.
에이전트를 여러 개 두고 실제로 어떻게 쓰는지는 오픈클로와 에이전트에서 이어집니다. 1교시 전체 순서와 앞뒤 맥락은 1교시 강의기록에 있습니다.
오픈클로와 에이전트 — 이번 주에 무엇이 달라지는가
1교시 후반부에서 진행자는 이번 주에 할 것을 먼저 한 번 다 설명했습니다. 1주차에는 AI 시대에 무엇을 할 수 있는지 경험했고, 2주차에는 내가 실제로 할 수 있는 것을 직접 해 봤고, 3주차에는 그것을 업무와 일상에 어떻게 더 잘 활용할지에 초점을 맞춥니다.
그 중심에 오픈클로와 에이전트가 있습니다. 지금까지는 터미널이나 웹 화면 앞에 앉아 있어야 Claude Code 에 일을 시킬 수 있었는데, 오픈클로를 붙이면 슬랙·디스코드 챗 창에서 같은 작업을 시킬 수 있습니다.
1교시에서 예고한 것
이번 주 메인 주제는 에이전트입니다. 오픈클로로 봇을 만들어 챗 창에서 부르고, 봇을 여러 개 두어 서로 논의하게 하고, 주기적으로 반복하는 스케줄링을 걸어 내가 자리에 없을 때도 작업이 진행되게 만드는 것까지가 이번 주의 범위입니다.
한 문단 정리
Claude Code 가 실제로 일을 하는 엔진입니다. 오픈클로는 챗 창에서 받은 말을 Claude Code 에 전달하고, Claude Code 가 만든 결과를 다시 챗 창에 답으로 보냅니다. 그래서 하는 일 자체는 같고, 달라지는 것은 부르는 자리입니다.
봇은 원하는 만큼 만들 수 있고 각 봇에 역할을 지정할 수 있습니다. 여러 봇이 서로 논의하고 평가하면서 결과를 만드는 구조를 에이전트 그래프라고 부릅니다.
주기적으로 반복하는 스케줄링(크론)을 걸어 두면 아침마다 정해진 일을 하게 만들 수 있습니다. 다만 오래 실행되는 작업은 중간에 들어가 확인하고 승인해 줘야 끝까지 진행됩니다.
1교시에서는 오픈클로가 무엇이고 왜 쓰는지까지만 이야기했습니다. 설치와 슬랙봇 연결은 이어지는 실습입니다. 이 문서에서 전사가 아니라 수업에서 띄운 교안덱 슬라이드를 근거로 한 대목은 “교안덱 예고”라고 표시했습니다.
①Claude Code 와 오픈클로는 무엇이 다른가
참가자 질문이 그대로 나왔습니다. “오픈클로랑 Claude Code 랑 뭐가 다른가요.” 설치까지 해 봤는데도 아직 헷갈린다는 말이 이어졌습니다.
“Claude Code 가 엔진이고, 그 겉에서 장치 역할을 하는, 봇의 역할을 다 해 주는 게 오픈클로입니다. 그래서 봇한테 아침마다 뭐 해 달라고 해 두면 알아서 자동으로 다 해 줍니다.”
진행자 — 1교시, 두 도구의 차이를 묻는 질문에
실행은 Claude Code 가 합니다. 오픈클로는 그 실행을 챗 창에서 부를 수 있게 하고, 정해 둔 시간에 Claude Code 를 자동으로 실행시킵니다.
항목
Claude Code
오픈클로
어디서 부르나
터미널·웹 화면 앞에서 직접
슬랙·디스코드 같은 챗 창에서 (교안덱 7장)
무엇을 하나
실제로 일을 하는 엔진
챗 창의 말을 Claude Code 에 전달하고 결과를 답으로 보낸다
몇 개를 두나
세션마다 창을 열어서 쓴다
봇을 원하는 만큼 만들고 역할을 각각 지정한다
언제 실행되나
내가 창을 열어 시킬 때
아침마다 하는 일·주기적 수집을 스케줄링으로 지정
맥락은 어디 남나
이어지는 실습에서 확인
봇에게 보내 둔 링크와 대화가 그 봇의 맥락으로 모인다
1교시 전사에서 확인되는 것만 채웠습니다. “이어지는 실습에서 확인”이라고 남긴 칸은 설치를 직접 해 본 다음에 채웁니다.
②부르는 자리가 바뀐다
교안덱 예고 — 교안덱 7장이 이번 주에 달라지는 것을 한 장으로 보여 줍니다. 지금은 터미널이나 웹에서, 노트북 앞에 있어야 시킬 수 있습니다. 오픈클로를 붙이면 슬랙·디스코드 챗 창에서 부를 수 있어 노트북이 없어도 같은 작업을 시킬 수 있습니다.
왼쪽이 지금까지의 방식, 오른쪽이 오픈클로를 붙였을 때입니다. 하는 일은 같고 부르는 화면만 바뀝니다.
전사에도 같은 이야기가 나옵니다. 진행자는 페스티벌에 가 있던 날에도 작업을 시켜 두었다고 했습니다. 또 보다가 필요한 링크가 있으면 봇에게 보내 두고 “이해하고 있어라”라고 말해 둔다고 했습니다. 그러면 봇이 그 링크를 분석해 두었다가, 나중에 “그때 그거 뭐였지” 하고 물으면 설명해 줍니다.
카카오톡으로 자기 자신에게 링크를 보내 두는 대신 봇에게 보내는 방식입니다. 보내 둔 링크를 내가 다시 열어 보지 않아도, 봇은 그 내용을 분석해 두었다가 나중에 답할 수 있습니다.
③봇을 여러 개 두면 무엇이 되나
진행자는 봇 3개(워키·리아·루나)를 운영한다고 했습니다. Claude 는 세션마다 창을 열어서 쓰지만, 오픈클로에서는 봇을 원하는 만큼 만들고 각 봇의 역할을 지정할 수 있습니다.
봇 하나에게만 시키면 그 봇이 파악한 만큼만 나옵니다. 두 봇에게 함께 시키면 서로 논의하고 서로 평가하면서 결과를 만듭니다. 진행자는 여러 봇을 함께 실행해 토론하게 하는 방식을 에이전트 그래프라고 부르며 요즘 트렌드라고 했습니다.
사람이 각 봇의 역할을 지정하고, 봇들이 서로 논의한 결과를 받아 봅니다. 사람이 팀으로 일하는 방식을 그대로 옮긴 구성입니다.
봇끼리의 소통에는 제한을 겁니다. 진행자의 봇은 대답할 대상이 지정돼 있어서, 다른 봇이 도움을 요청해도 응답하지 않습니다.
한 참가자가 자기 봇이 루나에게 도움을 요청했는데 답이 오지 않았다고 말했습니다. 진행자는 그 이유를 봇끼리 주고받는 양이 계속 늘어나기 때문이라고 설명했습니다.
봇도 처음부터 잘하지는 않는다 — 전사에서
진행자는 봇을 어떻게 알려 주고, 어떻게 설정하고, 어떻게 다루느냐에 따라 결과가 달라진다고 했습니다. 처음에 준비 없이 시켜 보면 안 되는 채로 끝납니다. 계속 피드백을 주면 사람을 대할 때와 똑같이 봇에도 자기 맥락이 모여서, 나중에 필요한 것을 시켰을 때 알아서 처리해 줍니다.
④주기적으로 돌린다 — 크론
우리가 항상 기기 앞에 있을 수는 없습니다. 그래서 봇을 잘 구축해 둔 다음에는 주기적으로 반복하는 스케줄링을 걸어 둡니다. 개발에서는 이것을 크론(cron)이라고 부릅니다.
아침마다 정해진 일을 하게 만드는 식입니다. 진행자는 자료를 주기적으로 수집하는 것도 같은 방식으로 시켜 둔다고 했습니다.
전사에서 크론이라는 말이 처음 나왔을 때 참가자가 “클론이 아니고요?”라고 되물었습니다. 크론은 정해진 시간에 반복 실행을 뜻하는 개발 용어입니다.
⑤오래 실행되는 작업에는 확인 지점이 필요하다
주말 동안 60여 시간을 학습시킨 사례가 나왔습니다. 금요일부터 월요일까지 계속 실행했습니다.
“그게 그냥 되는 게 아니라 중간중간 들어가서 체크하고, 맞는지 오케이 해 주고, 그 정도는 해 줘야 합니다. 알아서 하다 보면 알아서 안 되거든요.”
진행자 — 1교시, 60여 시간 학습 사례를 설명하며
완전 자동이 아닙니다. 결과를 받아 보고 이건 되는 것, 이건 안 되는 것이라고 사람이 판단해 줘야 오랜 시간이 걸리는 작업도 끝까지 진행됩니다. 신경을 써 줘야 하는데 내가 항상 자리에 있을 수는 없으니, 앞의 ②·④에서 본 챗 창 호출과 스케줄링이 필요해집니다.
⑥오픈클로 구조
교안덱 예고 — 이 절은 교안덱 8장과 10장을 근거로 합니다. 1교시 전사에는 기반 파일 이름까지 나오지 않습니다. 실제 구성은 이어지는 설치 실습에서 다룹니다.
01
게이트웨이
챗에서 온 말을 받는 자리. 항상 켜져 있습니다.
→
02
에이전트
Claude Code 와 연결된, 실제로 일을 하는 실행부입니다.
→
03
워크스페이스
봇의 기반 파일. 누구인지와 무엇을 기억하는지를 정합니다.
SOULIDENTITYMEMORYHEARTBEATTOOLS
①에서 말한 엔진이 02 에이전트이고, 봇 역할을 해 주는 오픈클로가 01 게이트웨이와 03 워크스페이스입니다.
교안덱 10장은 새 봇을 빈 상태에서 만들지 않고, 이미 운영 중인 봇(워키)에게서 구조를 물려받는 방식을 예고합니다. 물려받는 것은 세 가지입니다.
memory · knowledge · templates · contacts. 정리해 둔 것을 다시 꺼내 씁니다.
03
동료봇 소통 룰
NO_REPLY · 오너 우선 · 끼어들기 · 턴 제한. 다른 봇이 보낸 요청에는 답하지 않고, 오너인 사람이 부르면 답합니다.
③에서 본 “다른 봇의 요청에는 답하지 않는다”가 세 번째 항목인 동료봇 소통 룰에 해당합니다. 전사에서는 그 이유를 “주고받는 양이 계속 늘어나서”라고 설명했습니다.
⑦이어지는 실습에서 할 것
교안덱 예고 — 교안덱 9장이 설치 실습을 네 단계로 예고합니다. 전사에서 진행자는 설치를 1교시 뒤로 미뤄 두었고(“이거는 뒤에 하면 되겠고 나중에 슬랙도 설치하는 것도 간단하게”), 30분 안에 끝낼 것이라고 했습니다.
설치 자체가 목적은 아니라고도 했습니다. 주리 님은 이미 진행자와 함께 슬랙봇을 만들어 업로드해 본 적이 있고, 설치 절차를 하나씩 밟는 것은 진행자 팀에 필요했던 과정이지 참가자에게 필요한 것은 아니라고 했습니다. 지난 오픈클로 워크샵처럼 2~3시간 동안 하나하나 설치하지는 않습니다.
STEP 1가이드 문서를 새 세션에 붙인다
Claude Code 새 세션에 가이드 문서를 붙입니다. 체크리스트가 표시되면 “1번부터” 한 마디만 합니다. 세션이 끊기면 다시 붙여 넣습니다.
STEP 2설치하고 게이트웨이를 띄운다
런타임 → 오픈클로 → Claude Code 순서로 설치합니다. 처음에는 최소 구성으로만 하고 채널·스킬은 나중에 합니다. 안정 버전이 아니면 업데이트부터 합니다.
STEP 3슬랙 앱을 만들고 토큰을 연결한다
매니페스트로 앱을 만들고 소켓 모드를 켭니다. 토큰 두 개는 시크릿 파일에만 넣습니다. 채널 설정과 플러그인 활성화를 둘 다 합니다.
STEP 4기반 파일로 정체성을 정하고 동작을 확인한다
나 · 영혼 · 규칙 세 파일로 정체성을 정합니다. 재시작하고 채널 목록을 확인한 다음, 슬랙에서 이름을 불러 답을 받으면 완료입니다.
⚠ 교안덱에 주의로 표시된 세 가지 — 버전을 먼저 확인합니다 · 토큰은 문서 밖에 둡니다 · 자동 수리 명령은 쓰지 않습니다.
⑧LLM Wiki
진행자는 오늘 할 순서를 내려놓기 · 보는 눈 · 오픈클로와 슬랙봇 활용 · AI 가 잘 찾아가게끔 하는 것까지로 먼저 말했습니다. 마지막 항목이 이 절의 LLM Wiki 입니다.
1교시 마지막에 LLM Wiki 이야기가 짧게 나왔습니다. AI 가 이해하도록 문서를 잘라 두는 청킹 같은 처리를 하되, 우리는 개념만 알면 되고 실제 처리는 AI 가 알아서 하게 하면 된다는 설명이었습니다.
교안덱 예고 — 교안덱 11장은 이것을 세 단계로 예고합니다. 흩어져 있는 지식을 한곳에 정리해 넣어 두면, 봇이 먼저 그곳을 찾아보고 근거를 들어 답합니다.
01 모으기
흩어진 문서를 정리해서 위키에 넣습니다.
→
02 찾기
질문을 받으면 봇이 위키를 먼저 찾아봅니다.
→
03 답하기
찾은 내용을 근거로 들고 답합니다.
⑨이번 주의 도착점
교안덱 예고 — 교안덱 2장 아래쪽에 이번 주 도착점이 적혀 있습니다.
지금
터미널 — 화면 앞에 앉아서 시킨다
→
이번 주
챗 플랫폼 — 슬랙·디스코드에서 부른다
→
그래서
노트북이 없어도 같은 작업을 시킨다
→
도착점
비서처럼 시킨다 — 역할을 정해 두고 맡긴다
“오늘의 목표는 결국 2주차보다 한 단계 더 나아가서, 내가 없는 자리에서도 하게끔, 밤새도록 돌게끔 하는 겁니다.”
진행자 — 1교시 마무리, 오늘의 목표를 정리하며
진행자는 이번 주에 할 것을 먼저 한 번 다 보여 주는 이유도 말했습니다. 무엇을 할지 알고 있어야 “그다음에 뭘 하겠구나” 하고 스스로 인지하게 된다는 것입니다.
진행자가 설명한 Claude Code 와 오픈클로의 관계로 맞는 것은?
해설 — 1교시에서 진행자는 “Claude Code 가 엔진이고, 그 겉에서 봇의 역할을 해 주는 게 오픈클로”라고 답했습니다. 그래서 하는 일 자체는 같고, 챗 창에서 부를 수 있게 되는 것이 오픈클로가 더해 주는 부분입니다.
이어지는 문서 — 이번 주 원칙인 내려놓기와 보는 눈은 내려놓기와 보는 눈에서, 이 대화가 나온 앞뒤 순서는 1교시 강의기록에서 이어집니다.
4주차 개요 — 마지막 회차에서 정리한 것
4주차는 마지막 회차입니다. 새 도구를 하나 더 배우는 자리가 아니라, 한 달 동안 무엇이 바뀌었는지 확인하고 다음 달에도 계속할 수 있는 절차와 태도를 정리하는 자리였습니다.
진행자는 회차 초반에 이번 시간을 "1주차에 던져 둔 것을 회수하는 시간"이라고 말했습니다. 그래서 1주차에 정한 세 가지 원칙을 다시 확인하는 것으로 시작합니다.
이 저장소에는 1교시 전사만 들어와 있습니다. 아래 문서 일곱 개는 모두 1교시(2시간 14분) 전사를 근거로 썼습니다.
4주차에 다룬 것
한 달 동안 실제로 만든 결과물을 확인하고, AI가 대체하기 힘든 것이 무엇인지 정리하고, 혼자 일할 때와 함께 일할 때의 태도를 이야기했습니다.
1교시에서 실제로 다룬 것
1주차 세 가지 원칙 재확인 — 내려놓는다 · 매일 Claude Code를 쓴다 · 이해가 안 돼도 일단 따라 한다. 이어서 21일이라는 기간이 왜 중요한지 설명했습니다.
한 달 회고 — 참가자가 한 달 동안 업무에 AI를 써서 만든 결과물을 화면에 띄워 놓고, 어떻게 만들었고 어떤 피드백을 받았는지 되짚었습니다.
프롬프트 기법 — 마크다운의 코드블록과 제목으로 명령과 데이터를 나누는 방법.
AI가 대체하기 힘든 것 — 사람과 사람이 만나서 하는 일, 방향 설정과 책임, 마음을 얻는 일, 육감.
태도 — 스스로 한계를 긋지 않는 것, 그리고 함께 일할 때의 신뢰·배려·개방.
레퍼런스를 판단 근거까지 모으기 — 진행자가 실제로 작업 중인 화면을 띄워 놓고 방식을 설명했습니다.
①1주차 → 4주차
3주차까지는 무엇을 할 수 있는지 경험하고, 직접 만들고, 업무에 통합하는 순서였습니다. 마지막 회차는 그 한 달을 확인하고 이어 갈 방법을 정하는 자리였습니다.
1주차
AI로 무엇을 할 수 있는지 경험한다
→
2주차
할 수 있는 것을 직접 만들어 본다
→
3주차
일상·업무에 통합하고 판단하는 눈을 기른다
→
4주차
한 달을 확인하고 계속할 방법과 태도를 정리한다
1~3주차 구분은 3주차에 진행자가 직접 나눠 설명한 내용이고, 4주차 항목은 이번 회차 전사에서 정리한 것입니다.
②이번 회차 주제 지도
2시간 14분에서 나온 이야기를 성격에 따라 셋으로 나눴습니다. 되돌아보기는 한 달을 확인하는 부분, 방법은 바로 따라 할 수 있는 작업 방식, 태도는 도구와 무관하게 남는 부분입니다.
회색 = 이번 회차에서 다룬 세 갈래, 파랑 = 진행자가 마지막에 정리한 도착점입니다.
③교시별 정리 상태
지금 어디까지 정리됐는지만 표로 적었습니다. 4주차는 1교시 하나로 진행됐습니다.
교시
다룬 것
정리한 문서
상태
1교시
세 가지 원칙과 21일 · 한 달 회고 · 마크다운 프롬프트 · 대체하기 힘든 것 · 팀과 협업 태도 · 레퍼런스 모으기
레퍼런스를 이미지로만 두지 않고 판단 근거까지 함께 정리하는 방식입니다. 전문 분야가 아닌 일을 판단해야 할 때 보면 됩니다.
⑤마지막 회차에서 나온 말
아래 세 문장은 1교시 전사에 나온 말을 정리체로만 다듬은 것입니다. 인용 아래에 실무에서 무슨 뜻인지 한 줄로 적었습니다.
"계획과 절차를 그대로 지켜 가면서 3주 동안 매일 반복하면, 그걸 인지해서 사고가 바뀝니다. 그러고 나면 세 달 동안 할 수 있는 습관이 생기고, 세 달을 하고 나면 3년 동안 할 수 있습니다."
진행자 — 8분 31초 구간
순서가 반대라는 점이 핵심입니다. 생각이 먼저 바뀌어서 습관이 되는 게 아니라, 정해 둔 절차를 그대로 반복하다 보면 생각이 따라 바뀝니다. 자세한 설명은 세 가지 원칙과 21일에 있습니다.
"자기가 한계를 스스로 긋지 않는 게 중요합니다. 이건 안 될 거야, 하고 아예 그렇게 생각해 버리면 그 뒤로 이어 가기가 쉽지 않아요."
진행자 — 53분 2초 구간
진행자가 매 회차 되는 것을 하나씩 보여 준 이유이기도 합니다. 되는 걸 알아야 시도하기 때문입니다. 자세한 내용은 대체하기 힘든 것에 있습니다.
"태도의 차이라는 게 이겁니다. 해 봤냐고, 한번 시도라도 해 봤냐고."
진행자 — 2시간 9분 48초 구간
도구를 아는 것과 실제로 해 보는 것 사이의 간격을 말한 대목입니다. 같은 도구를 줘도 한 단계 더 해 보는 사람과 그렇지 않은 사람의 결과가 갈린다는 이야기가 회차 내내 반복됐습니다.
⑥한 달을 마치고 남는 것
마지막 회차에서 진행자가 강조한 것은 도구 사용법이 아니라 계속할 수 있는 상태였습니다. 한 달을 마친 시점에서 각자 확인할 것을 세 가지로 정리하면 아래와 같습니다.
01매일 하는 자리를 남겨 둔다
한 참가자는 한 달 동안 하루도 빠뜨리지 않았고, 업무 시간에 하기 어려워 퇴근 후에 했다고 말했습니다. 중요한 건 날짜가 아니라 반복 횟수라는 것이 진행자의 설명입니다.
02결과물을 실제로 내놓아 본다
이번 회차의 회고는 전부 실제 업무 결과물을 놓고 진행됐습니다. 만들어서 내놓은 순간부터 주변의 평가가 달라진다는 이야기가 함께 나왔습니다.
03한 차례 더 물어본다
이해되지 않는 자료를 받았을 때 "내가 이해할 수 있게 설명해 줘"라고 한 번 더 요청하는 것. 대부분은 이 한 단계를 하지 않는다는 지적이 있었습니다.
이 문서들은 모두 1교시 전사에 실제로 있는 내용만으로 썼습니다. 대외 공개를 전제로 하여 개인 이름과 소속, 사업 수치, 특정 인물에 대한 평가는 넣지 않았습니다.
1교시 강의기록 — 마지막 회차에서 오간 이야기
4주차는 이 스터디의 마지막 회차입니다. 1교시는 2시간 14분 동안 이어졌고, 진행자 1명과 참가자 2명이 참여했습니다.
다른 문서가 주제별로 정리한 것과 달리, 이 문서는 세션이 어떤 순서로 진행됐는지를 시간 순으로 적었습니다. 각 항목에 녹음 구간을 함께 표시했습니다.
이 회차의 성격
새 도구를 설치하는 시간이 아니라, 한 달 동안 무엇이 달라졌는지 확인하고 태도를 정리하는 시간이었습니다. 각자 이번 주에 AI를 어떻게 썼는지 공유하고, 만든 결과물을 화면에 띄워 놓고 피드백을 주고받았습니다.
한 회차 요약
앞부분은 한 달을 되돌아보는 시간이었습니다. 1주차에 정한 세 원칙을 다시 확인하고, 팀원들과 1:1로 대화해 본 회고와 이번 주 AI 활용 사례를 나눴습니다.
가운데는 결과물을 놓고 하는 피드백이었습니다. 실제로 만든 하반기 전략 보고서를 함께 보면서, 잘된 점과 고칠 점을 화면을 가리키며 짚었습니다.
뒷부분은 태도였습니다. 스스로 한계를 긋지 않는 것, 팀의 직무 경계가 줄어드는 것, 신뢰와 배려와 개방, AI가 대체하기 힘든 것, 그리고 리소스를 어디에 쓸지 정하려면 무엇을 그만둘지부터 정해야 한다는 이야기로 마무리했습니다.
①세션 순서 한눈에 보기
아래 표가 1교시 전체 순서입니다. 시간 표시는 녹음 기준이고, 주제가 서로 이어지는 구간은 시간이 겹칩니다.
구간
주제
한 줄 요약
00:05 ~ 00:10
마지막 회차의 시작
1주차에 정한 세 가지 원칙을 다시 확인했습니다.
00:10 ~ 00:23
한 달을 돌아보며
팀원들과 1:1로 대화해 본 회고와 그에 대한 피드백입니다.
00:22 ~ 00:34
이번 주에 AI를 어떻게 썼나
자동화, 문서 작성, 전략 보고서 사례를 각자 공유했습니다.
00:27 ~ 00:30
마크다운 기법
명령과 자료를 나눠서 적는 방법을 설명했습니다.
00:30 ~ 00:40
알아듣게 되는 변화
전에는 이해하지 못하던 기술 설명이 들리기 시작한 경험입니다.
00:41 ~ 00:53
전략 보고서 피드백
실제로 만든 보고서를 화면에 띄워 놓고 함께 봤습니다.
00:53 ~ 01:01
스스로 한계를 긋지 않기
태도에 관한 첫 번째 주제입니다.
00:54 ~ 01:02
팀의 직무 경계가 줄어든다
직무별로 나뉘어 있던 경계에 대한 이야기입니다.
01:02 ~ 01:13
신뢰 · 배려 · 개방
함께 일할 때 필요한 태도를 순서대로 정리했습니다.
01:13 ~ 01:15
AI가 대체하기 힘든 것
방향 설정, 책임, 사람의 마음 세 가지를 꼽았습니다.
01:23 ~ 01:50
레퍼런스를 판단 근거까지 정리
하반기에 하려는 작업을 화면으로 보여 주며 설명했습니다.
01:50 ~ 01:57
조직에서 AX가 잘 안 되는 이유
개인이 부딪히는 것과 조직이 해야 하는 것을 짚었습니다.
02:07 ~ 02:13
리소스를 어디에 쓸 것인가
무엇을 그만둘지 정하는 이야기로 마무리했습니다.
②마지막 회차의 시작 — 세 원칙 다시 확인
00:05:41 ~ 00:09:51
진행자가 먼저 물었습니다. “마지막 주차니까, 1주차에 꼭 지켜야 한다고 한 세 가지가 뭐였죠?” 참가자가 첫 번째로 내려놓는다를 꺼냈고, 나머지 둘을 함께 맞춰 갔습니다.
원칙 01
내려놓는다
쓰던 방식을 그대로 두지 않고 그만두는 것입니다. 진행자는 “내려놓고 일단 시키는 대로 한다”로 다시 확인했습니다.
원칙 02
매일 Claude Code
참가자가 두 번째로 떠올린 항목입니다. 진행자는 매일 아침 Claude Code로 시작하라고 다시 말했습니다.
원칙 03
이해가 안 돼도 일단 따라 한다
진행자 표현으로는 “이해가 안 돼도 일단 따라한다”입니다. 뜻을 다 알고 시작하지 않아도 된다는 것입니다.
한 참가자는 한 달 동안 하루도 빼먹지 않았다고 답했습니다. 업무 시간에는 하기 어려워서 퇴근한 뒤에 최대한 많이 했다고 덧붙였습니다.
진행자는 왜 한 달로 잡는지도 설명했습니다. 한 달 과정에서 첫 주와 마지막 주를 빼면 실제로 손을 움직이는 기간이 21일이 되고, 습관이 만들어지는 데 필요한 것도 그 정도의 반복 횟수라는 것입니다. 습관이 되는 쪽은 생각을 바꾸는 방향이 아니라 계획과 절차를 정해 놓고 그대로 매일 반복하는 방향이라고 했습니다. 3주를 이어 가면 세 달을 할 수 있게 되고, 세 달을 하면 3년을 할 수 있다고 봤습니다.
③한 달을 돌아보며 — 1:1 대화를 해 본 회고
00:10:44 ~ 00:23:00
진행자가 한 참가자에게 과제였던 팀원들과의 1:1 대화를 해 보니 어땠는지 물었습니다. 참가자는 이렇게 정리했습니다.
“하고 나니까 생각보다 우리가 둘이서 얘기를 해 보지 않았구나를 많이 느꼈어요. 그렇게 긴 시간 1:1로 얘기해 본 적이 한 번도 없었던 거예요. 업무 쪽으로만 바라보고 있었구나 하는 생각도 들었고, 사람들끼리 제대로 소통한 게 오랜만이었던 것 같아요.”
1교시 · 참가자 회고
처음 시작할 때는 어색했지만 하다 보니 대화가 이어졌고, 커피챗이나 1:1을 왜 하는지 알겠다는 말도 나왔습니다. 자주는 못 하더라도 종종 다시 하자는 이야기가 팀원들 사이에서 나왔다고 했습니다.
진행자는 좋았던 점과 함께 요청하는 방식에 대한 피드백을 줬습니다.
진행자가 자기 팀원에게 지키는 기준은 주말이나 저녁 시간에 하자고 먼저 정해서 요청하지 않는 것입니다. 그 시간에는 상대의 업무 밖 일상이 있기 때문입니다. 이번 요청은 평일에 시간을 잡을 여지가 있었는데도 주말과 금요일 저녁으로 넘어갔고, 진행자는 그 점을 배려가 부족했던 부분으로 짚었습니다. 정리하면 상대 일정을 먼저 확인하고 요청하는 것이 배려라는 이야기입니다.
사정이 있어 어렵다면 그 사정을 설명하고 다른 시간을 제안하는 방식도 있다고 진행자는 덧붙였습니다. 참가자도 밀린 일정에 쫓기며 하고 싶지는 않았다고 답했고, 한 사람당 한 시간 이상 여유 있게 이야기하고 싶었다고 말했습니다.
④이번 주에 AI를 어떻게 썼나
00:22:55 ~ 00:34:34
진행자는 한 참가자에게는 과제를 따로 주지 않았다고 밝혔습니다. 하고 있는 것을 보니 필요하지 않다고 판단해서였습니다. 이어서 각자 이번 주에 AI를 어떻게 썼는지 이야기했습니다.
“이 세션을 자주 하는 게 사실 AI 도구를 사용하는 것보다는 생각하는 방식에 좀 더 가깝잖아요. 그러니까 그게 자연스럽게 묻어나는 거죠.”
1교시 · 진행자
사례 01읽을 것을 먼저 정리해 주는 자동화
팀에서 쓰는 봇에 자동화를 여러 개 붙였습니다. 아티클을 먼저 보내 주고 요약해 주는 것, 업무와 연결되는 부분을 따로 정리해 주는 것입니다.
사례 02업무일지가 다음 날 아침 제안으로 이어짐
예전에는 스킬을 써서 마크다운 파일로 남기는 정도였습니다. 지금은 그날의 Claude Code 세션을 읽고 다음 날 아침에 개선할 점과 프롬프트를 이렇게 쓰면 좋겠다는 제안이 정리돼 나옵니다.
사례 03병렬 에이전트가 쓴 프롬프트를 열어 보기
서브에이전트와 병렬 에이전트를 시키면 메인 Claude Code가 각 에이전트에게 보낸 프롬프트를 볼 수 있습니다. 참가자는 그것이 진행자가 직접 쓰는 방식과 거의 비슷하다고 했습니다. 맥락을 길게 설명하고 필요한 것을 적는 형태입니다.
사례 04지원사업 신청 서류를 문서로 작성
다른 참가자의 사례입니다. 직접 손댄 부분 없이 Claude가 문서를 만들었고, 한 번 정도 고쳐서 보냈는데 그대로 승인됐습니다. 여기서 문서 작성 방식을 바꿀 수 있겠다는 생각이 들었다고 말했습니다.
사례 05하반기 전략 보고서 만들기
가장 하기 싫어하던 발표 자료 작업입니다. 처음으로 에세이처럼 길게 쓴 세션이었고, 참고 링크·담당 지역·기간·목표를 맥락으로 넣고 에이전트 팀도 꾸리고 디자인 템플릿도 줬습니다. 컨텍스트를 두 번 compact할 정도로 긴 작업이었습니다.
진행자는 1년 전만 해도 Claude가 프롬프트를 어떻게 쓰는지가 화면에 그대로 보였는데 요새는 안쪽에서 처리돼 잘 보이지 않는다고 했습니다. 안쪽을 열어 보면 지금도 어떻게 하고 있는지 확인할 수 있습니다.
⑤마크다운으로 명령과 자료를 나누기
00:27:18 ~ 00:30:29
참가자가 “# 표시와 구간을 끊는 표시는 무슨 차이냐”고 물으면서 나온 설명입니다. 진행자는 에이전트가 읽는 마크다운 파일이 위계 구조라고 먼저 짚었습니다. 제목이 있고, 순서대로 들어가는 항목이 있고, 구분 지점이 있습니다.
표기
무엇을 뜻하는가
왜 나눠서 쓰는가
# 로 시작하는 줄
제목입니다. 마크다운의 제목 표기입니다.
위에 넣은 내용과 아래에 적는 내용을 구분해 줍니다.
백틱 세 개로 감싼 구간
스크립트나 코드처럼 그대로 가져온 자료를 넣는 구간입니다.
이 구간은 붙여 넣은 자료라는 것을 AI가 구분해서 읽습니다.
진행자의 설명은 이랬습니다. 전부 이어서 적어도 AI가 이해는 하지만, 내가 내리는 명령과 그 안에 넣은 자료가 섞여 있으면 명확하지 않을 수 있습니다. 그래서 자료 구간을 끊어 두고 그 아래에 설명을 적으면, 위는 넣은 자료이고 아래는 내 설명이라는 것이 구분됩니다.
참가자는 그동안 구간을 끊는 표시만 써 왔다고 했습니다. 사진을 넣고 끊고, 설명하고 또 끊는 식입니다. 진행자는 그렇게 해도 되고 그렇게까지 끊지 않아도 상관없다고 답했습니다. 이런 것은 규칙이 아니라 프롬프트 기법이고, 간단히 몇 번 써 보면 감이 온다고 했습니다.
⑥알아듣게 되는 변화
00:30:47 ~ 00:40:41
한 참가자가 이번 주에 가장 인상 깊었던 경험으로 꼽은 것은 업무 결과가 아니라 대화가 통했던 순간이었습니다. 외부 미팅이 끝난 뒤 상대 회사 임원과 커피를 마시며 1:1 형식으로 이야기를 나눴는데, 이 스터디에서 들은 내용을 꺼낼 수 있었습니다.
“그분이 만든 작업 환경을 보여 주셨는데, 옛날의 저였으면 하나도 이해 못 할 내용이거든요. 근데 보는데 말이 오고 갔어요. 보는 눈이 살짝 생겼구나 싶었습니다.”
1교시 · 참가자
상대는 일반인 눈높이로 설명하는 편이 아니어서 전에는 말이 들어오지 않았다고 합니다. 이번에는 화면을 보고 “이건 스킬 형식 아니냐”고 물을 수 있었고, 터미널을 켜지 않고도 쓸 수 있게 만든 Claude Code 같다는 인상을 받았다고 했습니다. 파싱이나 청킹 같은 단어도 예를 들어 가며 설명할 수 있었습니다.
진행자는 여기에 한 줄을 더했습니다. 그걸 이해하고 남에게 설명할 수 있다는 것이 큰 힘인데, 쉬운 일도 아니다는 것입니다.
같은 구간에서 참가자는 배운 것을 계속 적용해 나가면 어디서 일하든 자기 몫을 할 수 있겠다는 생각을 했다고 말했고, 진행자는 결과로 나와야 한다는 단서를 달았습니다. 이 스터디를 계기로 팀의 협업 도구를 슬랙으로 옮긴 것도 이 대목에서 나왔습니다. 회의도 별도 화상회의 도구 대신 슬랙에서 하기로 했고, 통화 기록을 슬랙이 자체 요약해 준다는 점을 설명해 결정을 바꿨다고 했습니다.
⑦만든 전략 보고서를 함께 보며
00:41:44 ~ 00:53:02
진행자가 결과를 보여 달라고 했고, 참가자는 창피하다며 망설였습니다. 진행자의 답은 이랬습니다.
“다듬지 않은 그걸 보고 피드백 받고 해야 돼요. 창피한 그 시기가 지나야 합니다.”
1교시 · 진행자
화면에 띄운 것은 두 가지 버전이었습니다. 하나는 참가자가 직접 구성한 것이고, 다른 하나는 진행자가 쓰는 제안서 형식을 적용한 것입니다. 내용은 같고 순서만 달랐습니다. 두 번째 버전은 발표에 쓰지 않았고, 가지고 있는 자료로 형식만 적용하면 되는지 확인한 결과였습니다.
피드백 01맥락을 많이 넣었다
참고 자료와 배경, 기간과 목표를 미리 설명한 것을 진행자가 먼저 짚었습니다. 목차와 요약을 앞에 두고 수치로 시작하는 구성도 받는 사람이 좋아할 형태라고 했습니다.
피드백 02위계가 잡혀 있고 설명하기 쉽다
항목 사이의 연결이 정리돼 있어 보기 편하고 설명하기도 편하다는 평가였습니다. 진행자는 AI 세션을 듣고 Claude Code로 만든 첫 발표 자료라는 점을 함께 짚었습니다.
피드백 03글꼴이 일부에만 적용됐고 시각화가 없다
Pretendard로 지정한 부분과 그렇지 않은 부분이 섞여 있었습니다.
피드백 04AI스러운 부분은 빼는 편이 낫다
참가자는 보고할 때 Claude Code로 만들었다고 먼저 밝히고, 부족하거나 AI스러워 보이는 부분이 있을 수 있다고 양해를 구했다고 했습니다. 진행자는 오히려 AI스럽지 않고 다듬지 않은 느낌이었다고 답한 뒤, 화면에서 몇 군데를 가리키며 이런 것이 AI스러운 표현이니 빼는 편이 낫다고 짚었습니다.
참가자는 잘 만들었는지 판단할 기준을 아직 모르겠고, 시간이 더 있었으면 더 다듬고 싶었다고 말했습니다. 진행자의 정리는 이렇습니다. 예쁘게 만드는 것이 중요한 게 아니라 받는 사람에게 잘 전달되면 됩니다.
⑧스스로 한계를 긋지 않는 태도
00:53:02 ~ 01:01:51
여기서부터 태도 이야기입니다. 진행자가 첫 번째로 꺼낸 것은 자기가 자기 한계를 미리 정해 버리지 않는 것이었습니다.
“이건 안 될 거야, 차라리 내가 하는 게 더 빠르지. 이렇게 애초에 그냥 한계를 그어 버리는 거죠. 자기가 여기까지야 하고 끊어 놓으면 그 뒤로 이어 가기가 쉽지 않아요.”
1교시 · 진행자
진행자는 매 회차에 결과를 하나씩 보여 주는 이유도 여기에 있다고 했습니다. 무엇이 되는지 알아야 시도한다는 것입니다. 전문가가 아니어도 몇 차례 물어보면 확인할 수 있고, 1년 전에는 어려웠지만 지금은 웬만하면 가능하다고 했습니다.
태도 01
기준선을 스스로 낮추지 않는다
제안만 하고 멈추지 않고 실제로 만들어 낸 순간부터 평가가 하나씩 들어옵니다. 사람들이 저렇게까지 하는구나를 알게 된다는 것입니다.
태도 02
한 차례 더 해 본다
진행자는 한 팀원이 자주 하는 말인 “AI는 기세다”를 인용했습니다. 한 번 더 해 보면 되는데 대부분은 하지 않는다는 뜻으로 썼습니다.
태도 03
받은 자료를 한 번 더 되묻는다
어려운 자료를 받았을 때 “내가 이해할 수 있게 설명해 달라”고 한 번 더 요청하면 이해할 수 있는 형태로 나옵니다. 그 한 번을 하는지가 차이입니다.
⑨팀의 직무 경계가 줄어든다
00:54:16 ~ 01:02:17
진행자가 질문을 던졌습니다. “회사는 왜 팀을 만들까요?” 참가자의 답은 혼자서는 안 되니까였습니다. 에이전트에 각각 직무를 맡기듯, 잘하는 것이 서로 다르니 균형을 맞춘다는 설명이었습니다.
전통적인 구성
기획자 · 디자이너 · 개발자가 각자 역할을 맡아 한 팀을 이룹니다. 영업과 마케팅도 같은 방식입니다.
→
경계가 있던 때
진행자 팀도 AI를 다루기 전에는 이 경계가 뚜렷했고 초반에 갈등이 많았습니다. 오해를 풀어 주는 데 시간이 들었습니다.
→
6개월 뒤
모두가 AI 쓰는 것을 이해하게 되자 경계가 줄어들어도 괜찮겠다는 것을 팀이 받아들이기 시작했습니다.
진행자가 정리한 팀의 정의는 이렇습니다. 불완전한 사람들이 모여 서로 보완하면서, 팀이 가진 목표를 결과로 만드는 것입니다. 리더의 역할은 방향을 정해 주고 부족한 부분을 보완해 원하는 결과를 가져가는 것입니다.
경계가 줄어든 예로 참가자가 든 것이 있습니다. 발표 자료를 만들면서 디자이너 팀원에게 물어봤더니, 화면 비율만 적기보다 가로세로 픽셀 수치를 직접 지정하는 편이 정확하다고 알려 줬습니다. 비율만 주면 AI가 모호하게 처리할 수 있기 때문입니다. 진행자는 이렇게 경계가 줄어들면 한 사람이 다룰 수 있는 범위가 넓어진다고 보고, 팀 회의 초기부터 그 이야기를 해 왔다고 했습니다. 처음에는 다들 이상하게 받아들였지만 지금은 될 수도 있겠다는 반응이 나온다고 합니다.
⑩신뢰 · 배려 · 개방
01:02:17 ~ 01:13:06
진행자는 AI를 잘 쓰는 것만으로는 되지 않고, 사람과 함께 일하는 방식이 같이 중요하다고 했습니다. 순서는 이렇게 정리됐습니다.
1단계
신뢰
함께 일하려면 가장 먼저 필요한 것. 요청을 다듬어 전달하는 작은 행동에서 시작됩니다.
→
2단계
배려
꼭 해야 하는 일은 아닌데 상대 입장을 생각해 한 번 더 확인하는 것. 기준이 명확해야 합니다.
→
3단계
개방
신뢰가 생긴 다음 단계. 진행자가 태도를 이야기할 때 마지막에 두는 항목입니다.
배려의 예로 진행자가 든 것은 이날 세션이었습니다. 참가자가 몇 시 기차를 타야 하는지 미리 확인하고 오전 9시에 시작한 것입니다.
친분과 위계가 있더라도 더 잘 챙겨야 신뢰가 생긴다는 것이 진행자의 기준이었습니다. 팀원 한 명 한 명을 챙기고 위에서 오는 요청을 리더가 먼저 정리해 주면 팀 안에 안정감이 생기고, 자기 평판보다 팀이 잘 돌아가는 쪽을 우선한다고 했습니다.
“별거 아닌 것 같아도 한 번 더 손을 대서 다듬어 전달하면 그 사람에 대한 진정성이 느껴져요. 그때부터 신뢰가 쌓입니다. 저도 경영진에게 넘길 때 대충 안 넘겨요. 다 검토하고 넘깁니다.”
1교시 · 진행자
참가자도 같은 경험을 이야기했습니다. 예전에 슬랙으로 고객 의견을 다른 팀에 전달할 때, 그 팀이 이해할 수 있게 설명하려고 하나 남기는 데도 시간을 들였습니다. 그렇게 한 것을 상대가 알아주더라는 것입니다.
⑪AI가 대체하기 힘든 것
01:13:21 ~ 01:14:52
진행자가 이날의 큰 질문 중 하나를 꺼냈습니다. 세션 앞부분(00:25:14)에서도 같은 질문이 나왔고, 그때 답은 사람과 사람이 만나서 해야 하는 일이었습니다. 뒤에서 세 가지로 정리됐습니다.
01
방향 설정
무엇을 할지 정하는 일입니다. 진행자가 가장 먼저 꼽았습니다.
02
책임
참가자는 책임은 역할이라고 정리했습니다. 책임질 사람이 책임진다는 것입니다.
03
사람의 마음을 얻는 것
감정이 들어가는 영역입니다. 참가자는 오감 외에 육감이 있다고 봤습니다. 눈치나 어색함을 알아채는 것입니다.
진행자도 여기에 동의했습니다. 시각·청각·후각은 센서로 다룰 수 있게 됐고 촉각도 터치 센서로 처리할 수 있는데, 육감은 아직 다른 것 같다는 것입니다. 사람을 만나서 하는 일이 남아 있는 이유로 이 대목이 나왔습니다.
⑫레퍼런스를 판단 근거까지 정리해 두기
01:23:11 ~ 01:49:47
진행자가 화면을 띄워 하반기에 하려는 작업을 설명했습니다. 앞에서 이야기한 한계를 긋지 않는 태도와 이어지는 대목이라고 먼저 밝혔습니다. 목표는 의사결정에 쓸 수 있는 기준을 시스템으로 만드는 것입니다.
국내외 서비스 화면 레퍼런스가 모여 있는 사이트들이 있습니다. 진행자가 짚은 것은 이미지를 모으는 것만으로는 부족하다는 점이었습니다.
위 줄과 아래 줄의 차이는 왜 그 레이아웃인지가 자료에 적혀 있는지 하나입니다. 진행자는 디자이너들도 준비할 때 화면을 캡처해 모으지만, 그 자료에는 판단 근거가 들어 있지 않다고 짚었습니다.
정리한 결과는 Obsidian에 위키 형태로 넣고 있습니다. 원래는 카테고리만 나눠 두었는데, 이번에는 이미지마다 어떤 구조와 레이아웃을 쓰는지를 적어 두고 있습니다. 이미지를 읽어 설명으로 바꾸는 데는 Codex와 VLM을 썼습니다. 사진만 가지고 있으면 AI가 검색해도 판단하지 못하기 때문입니다. 잘 만들어져 공개된 디자인 시스템은 웹페이지나 디자인 파일로 공개돼 있어, 그것과 비교하면 감이 아니라 근거로 화면 구성을 정할 수 있습니다.
진행자가 덧붙인 경고가 있습니다. 내가 잘 아는 분야라고 해서 그것이 정답이라고 생각하면 위험합니다. 다른 곳이 그렇게 만든 데에도 이유가 있는데, 그것을 보지 않고 자기 기준으로만 판단하게 된다는 것입니다. 초기에 잘못한 의사결정이 나중에 부채로 돌아온다는 이야기도 함께 나왔습니다.
설득하는 방법에 대한 이야기도 이어졌습니다. 말로만 하면 이상적인 이야기로 들리고, 결과를 만들어 보여 주면 그때부터 판단이 시작된다는 것입니다. 참가자는 도구가 다 주어져 있어도 이걸 수십 시간 들여 전부 정리하겠다고 생각하는 사람은 드물다고 했습니다.
참가자가 단계를 나눠 정리한 대목입니다. 레퍼런스를 ① 보고 참고하는 단계 → ② 여러 개를 조합해 화면을 만들어 보는 단계 → ③ 전부 정리해 판단 근거까지 구조로 만드는 단계가 있고, 이번 작업은 마지막 단계라는 것입니다. 진행자의 정리는 이렇습니다. 이게 된다는 것을 한 번 보면 사고가 열리고, 모아 놓은 자료를 어떻게 가공해야 하는지가 보이기 시작합니다.
⑬조직에서 AX가 잘 안 되는 이유
01:50:18 ~ 01:57:20
화면을 보던 중에 나온 질문이었습니다. 도구도 있고 데이터도 있는데 왜 잘 안 되느냐는 것입니다. 이날 나온 답을 항목으로 정리하면 이렇습니다.
01결핍이 없으면 바꾸지 않는다
참가자가 먼저 꺼낸 답입니다. 지금 방식으로도 실적이 나오고 있으면 바꿀 이유가 생기지 않습니다. 고객사들도 아직 AI를 크게 신뢰하지 않는 상태라는 이야기가 이어졌습니다.
02직접 해 보지 않으면 인식이 바뀌지 않는다
된다는 것을 말로 듣고 화면으로 봐도, 직접 체험하고 해 보려는 의지가 없으면 전환은 일어나지 않습니다. 진행자는 이것을 첫 번째 이유로 꼽았습니다.
03개인이 부담하는 허들이 있다
구독 비용을 개인이 내고 주말 시간을 들여 배워야 하는 상태면, 회사가 “좋네” 하고 반응해도 실제로 하는 사람은 늘지 않습니다. 여기서부터 허들이라는 표현이 나왔습니다.
04탑다운만으로는 되지 않는다
이번에 결정이 된 것도 팀이 이미 AX를 하고 있었기 때문이고, 완전한 탑다운 방식이었다면 어려웠을 것이라는 판단이 나왔습니다.
05잘하고 있는 팀에 관심과 지원이 가야 한다
참가자의 지적입니다. 전사적으로 AX를 하고 싶다면 가장 잘하고 있는 팀에 지원을 하고, 어떻게 일하는지 관심을 갖고 보고, 이렇게 해 보자고 제안하는 것이 필요한데 그게 없다는 것입니다. 결과만 보고 일하는 방식은 보지 않는 상태에 대한 이야기였습니다.
이 대목은 누구 한 사람의 문제라기보다 그런 문화가 형성돼 있지 않은 것이라는 정리로 마무리됐습니다.
⑭리소스를 어디에 쓸 것인가
02:07:19 ~ 02:12:54
마지막 주제입니다. 진행자는 하반기에 자기 팀 제품에만 집중하고 다른 AI 도구는 더 만들지 않겠다고 정했다고 밝혔습니다. 여기저기서 필요하다고 해서 만든 도구가 서너 개 더 있는데, 만들어도 실제로 쓰지 않는다는 것이 이유였습니다.
“이런 거 만드는 데도 노력이 많이 들어가요, 리소스가. 근데 저희 팀은 필요 없거든요. 쓰실 거면 이제 다 Claude Code 쓰시든지.”
1교시 · 진행자
요청이 하나씩 들어오면 정작 자기가 해야 할 역할을 못 하게 됩니다. 한 팀원이 “하반기에 할 것들이 태스크별로 정리돼 있으면 팀원들이 미리 보고 이해할 텐데 그게 준비돼 있지 않아 아쉽다”고 말했는데, 그것이 자기가 할 역할이라고 진행자는 답했습니다.
참가자도 같은 방향으로 말했습니다. 다른 팀을 위해 도구를 만들어 주던 것은 원래 호의로 하던 일이니 그만두는 것이 맞다고 봤습니다. 다만 되는지 안 되는지 판단이 필요한 것까지 전부 AI에게 물어볼 수는 없으니 그 부분은 함께 결정하기로 했고, 자기가 먼저 만들어 보고 부족한 부분만 요청하면 시간이 덜 든다는 방식도 제안했습니다. 품질은 떨어지겠지만 일단 결과가 나오는 것이 중요하다는 것입니다.
“그래서 태도의 차이라는 거예요. 해 봤냐고. 한번 시도라도 해 봤냐고. 안 해 봤잖아요.”
1교시 · 진행자
잘하는 사람에게 맡기면 빨리 나오고 품질도 좋습니다. 하지만 맡기는 동안 그 사람은 자기 일을 못 합니다. 언제까지 맡길 것인지를 정하는 것이 이날 마지막 질문이었습니다.
이 문서는 1교시 전체 순서를 따라 적은 기록입니다. 사내 사정과 개인에 관한 대화, 세션 중간의 잡담은 대외 공개 기준에 따라 제외했고, 남은 것은 어느 조직에나 해당하는 내용과 방법론입니다. 각 주제의 자세한 내용은 4주차 주제별 문서에서 이어집니다.
세 가지 원칙과 21일
4주차는 마지막 회차입니다. 1교시 앞부분에서 진행자가 먼저 물은 것은 “마지막 주차니까, 1주차에 꼭 지켜야 한다고 한 세 가지가 뭐였죠?”였습니다.
세 가지를 확인한 다음, 한 달 동안 실제로 어땠는지를 이야기하고, 왜 3주(21일)를 매일 반복해야 하는지를 설명했습니다. 이 문서는 1교시 앞부분(전사 05:41~09:51)을 정리한 것입니다.
마지막 회차를 여는 순서
진행자는 마지막 회차를 1주차에 정한 세 가지 원칙을 다시 확인하는 것부터 시작했습니다. 세 가지를 확인한 다음에 그날 주제로 넘어갔습니다.
이 문서 핵심
1주차에 정한 세 가지는 ① 내려놓는다 ② 매일 Claude Code를 쓴다 ③ 이해가 안 돼도 일단 따라 한다입니다.
21일에서 중요한 것은 날짜가 아니라 반복한 횟수입니다. 진행자가 나눈 두 가지 방향 중 습관이 되는 쪽은 계획과 절차를 먼저 정해 두고 3주 동안 매일 그대로 반복하는 쪽입니다. 사고는 그 반복의 결과로 바뀝니다.
3주를 매일 반복하면 인식이 바뀌고, 그다음에는 3개월, 그다음에는 3년 동안 할 수 있다는 것이 진행자의 설명이었습니다.
①세 가지 원칙 — 마지막 회차에서 다시 확인
세 가지는 진행자와 참가자가 번갈아 말하면서 확인했습니다. 참가자가 먼저 “내려놓는다”라고 답했고, 세 번째를 “받아들인다였나?”로 되묻자 진행자가 “이해가 안 돼도 일단 따라 한다”로 정정했습니다. 두 번째는 진행자가 “생각이 안 난다”고 하자 참가자가 “매일 Claude Code”라고 답했습니다.
원칙 01
내려놓는다
전사에서 진행자가 확인한 문장은 “내려놓고 일단 시키는 대로 한다”입니다. 마지막에 다시 한 번 “첫 번째가 뭐였죠?”로 되짚었습니다.
원칙 02
매일 Claude Code를 쓴다
참가자가 “매일 Claude Code”로 답했고, 진행자가 “매일 하자는 거”라고 확인했습니다. 뒤에서 “매일 아침에 Claude Code로 해라”로 다시 나옵니다.
원칙 03
이해가 안 돼도 일단 따라 한다
진행자 표현 그대로 “세 번째가 이해가 안 돼도 일단 따라한다”입니다. 마지막 정리에서도 “이해가 되든 안 되든 간에”로 반복했습니다.
원칙
1교시에서 나온 표현
먼저 말한 사람
① 내려놓는다
“내려놓고 일단 시키는 대로 한다”
참가자가 먼저 답하고 진행자가 확인
② 매일 Claude Code
“매일 하자는 거”
진행자가 기억하지 못하자 참가자가 답함
③ 이해가 안 돼도 따라 한다
“이해가 안 돼도 일단 따라한다”
참가자의 다른 답을 진행자가 정정
세 가지를 확인하는 데 대화가 여러 번 오갔습니다. 두 번째 원칙은 진행자가 “생각이 안 난다”고 했고, 참가자가 대신 답했습니다.
②한 달 동안 하루도 빼먹지 않았다
두 번째 원칙을 확인한 자리에서 “매일 하셨나요?”라는 질문이 나왔습니다. 답은 이랬습니다.
“한 번도 빼먹은 날은 없어요. 진짜 단 한 번도.”
1교시 · 한 참가자
같은 참가자는 바로 이어서 어떤 조건에서 매일 했는지를 말했습니다.
“솔직히 저한테는 일이거든요, Claude Code가. 그래서 업무 시간에 하기가 진짜 어려웠고, 그냥 퇴근하고 최대한 많이 했어요. 너무 피곤했어요.”
1교시 · 한 참가자
여기서 확인할 점은 두 가지입니다. 매일 쓴다는 원칙은 지켜졌습니다. 그리고 지켜진 시간대는 퇴근 후였습니다. 업무 시간에 쓰기는 어려웠다고 말했습니다.
③21일 — 날짜가 아니라 반복한 횟수
진행자는 인지심리학을 언급하면서 21일을 물었습니다. “21일이라는 시간이 되게 중요해요. 들어본 적 있어요?”
참가자가 내놓은 답은 “3주 정도 하니까”, “익숙해지는 데 걸린 시간이니까”였습니다. 진행자의 답은 조금 달랐습니다.
“이 일자라는 게 사실 중요한 건 아니거든요. 앞으로 이렇게 해야 되는구나 하고 인식하는 것 자체가, 21일 동안 매일 반복했을 때 되는 거예요. 그 횟수가 중요한 겁니다.”
1교시 · 진행자
즉 달력에서 21일이 지나는 것은 기준이 아닙니다. 같은 것을 몇 번 반복했는가가 기준이고, 매일 하면 21일 동안 그 횟수에 도달합니다.
④습관이 만들어지는 두 가지 방향
진행자는 사람이 습관을 만드는 방향을 두 가지로 나눴습니다. 하나는 사고를 먼저 바꾸는 방향이고, 다른 하나는 계획으로 절차를 만들어 그대로 하는 방향입니다. 그리고 습관이 되는 것은 후자라고 말했습니다.
두 방향의 차이는 사고가 바뀌는 시점입니다. 위쪽은 사고 변화가 맨 앞에 있고, 아래쪽은 반복한 다음에 옵니다. 진행자가 습관이 되는 쪽으로 지목한 것은 아래쪽입니다.
“계획과 절차를 그대로 지켜 가면서 3주 동안 매일매일 반복하면, 내가 그걸 인지해서 사고가 좀 바뀝니다.”
1교시 · 진행자
세 가지 원칙 중 ③ 이해가 안 돼도 일단 따라 한다가 여기에 연결됩니다. 정해 둔 절차를 그대로 반복하고 나서 이해가 오는 순서이기 때문입니다.
⑤3주 다음은 3개월, 그다음은 3년
진행자는 3주에서 끝내지 않고 그다음 단위를 이어서 말했습니다.
1단계
3주 매일 반복 — 계획과 절차를 정해 두고 21일 동안 매일 그대로 한다
→
2단계
3개월 — 3주를 매일 반복하면 3개월 동안 계속할 수 있는 습관이 생긴다
→
3단계
3년 — 3개월을 하고 나면 3년 동안 할 수 있다고 본다
진행자는 3주·3개월·3년 이야기 끝에 “이게 생각보다 중요합니다”라는 말을 붙였습니다.
⑥한 달 과정에서 21일이 어디인가
21일이 한 달 일정의 어디에 해당하는지도 설명했습니다. 한 달짜리 과정을 잡으면 첫 주는 주말이 끼는 주이고, 그다음 3주가 실제로 하는 기간입니다. 그 3주가 21일입니다.
첫 주
주말이 낀다 — 실제로 하는 기간으로 세지 않는다
→
그다음 3주
실제로 하는 기간 = 21일 — 이 3주 동안 매일 반복한다
정리는 두 문장이었습니다.
“무조건 따라서 해라. 그리고 매일 아침에 Claude Code로 해라.”
1교시 · 진행자
“내려놓고 그걸 무조건 해 봐라. 이해가 되든 안 되든 간에.”
1교시 · 진행자 — 첫 번째 원칙을 다시 확인하며
1교시에서 진행자가 “21일”의 핵심으로 말한 것은 무엇입니까?
해설 — 진행자는 “일자라는 게 사실 중요한 건 아니다”라고 말하고, 중요한 것은 반복한 횟수라고 했습니다. 습관이 되는 방향도 사고를 먼저 바꾸는 쪽이 아니라 계획과 절차를 정해 두고 그대로 반복하는 쪽이라고 정리했습니다.
이 문서는 4주차 1교시 앞부분(05:41~09:51)만 다룹니다. 같은 교시의 이어지는 내용과 앞뒤 순서는 1교시 강의기록에 있고, 세 가지 원칙 중 내려놓는다를 3주차에서 어떻게 설명했는지는 내려놓기와 보는 눈에 정리돼 있습니다.
한 달 회고 — 업무 결과물로 만들어 본 것
4주차 1교시 앞부분에서 진행자가 “이번 주에 AI를 써서 잘 활용해 본 것이 있느냐”고 물었고, 참가자 두 명이 이번 주 실제 업무에서 만든 결과물을 하나씩 이야기했습니다.
나온 것은 세 가지입니다. 개인 에이전트에 맡긴 자동화, 지원 사업 신청 서류, 하반기 전략 보고서입니다. 이 중 전략 보고서 이야기가 가장 길었고, 경영진 보고와 그 자리에서 받은 피드백까지 다뤘습니다. (근거: 4주차 1교시 전사 22:55~53:02)
이 회차에서 확인한 것
예전에는 한 줄씩 지시하는 방식이었고, 지금은 배경을 길게 적어 한 번에 맡기는 방식으로 바뀌었습니다. 그 결과물로 실제 서류를 제출했고, 발표 자료를 만들어 경영진에게 보고했습니다.
이 문서 핵심
자동화는 사람이 매번 지시하지 않아도 되는 일부터 맡겼습니다. 아티클 요약, 전날 작업 기록 점검, 업무일지 생성입니다.
프롬프트 쓰는 법은 메인 에이전트가 하위 에이전트에게 보낸 프롬프트를 직접 보면서 익혔습니다.
평소 가장 싫어하던 슬라이드 작업은 처음으로 에세이처럼 길게 배경을 써서 맡겼고, 컨텍스트를 두 번 compact 할 만큼 긴 세션이 됐습니다.
진행자의 결론은 한 줄입니다. 예쁘게 만드는 것이 목적이 아니라, 보는 사람에게 잘 전달되면 됩니다.
①개인 에이전트에 맡긴 자동화 세 가지
한 참가자는 이 세션을 하면서 개인 에이전트가 많이 개선돼, 사람이 매번 지시하지 않아도 되는 일을 여러 개 맡겼다고 말했습니다.
자동화 01
아티클을 먼저 받아 정리
에이전트가 아티클을 먼저 보내 줍니다. 요약과 함께 업무와 연결되는 부분의 인사이트까지 정리해 전달합니다.
자동화 02
다음 날 아침 개선점
그날 진행한 Claude Code 세션 기록을 읽고, 다음 날 아침에 개선하면 좋을 점과 프롬프트를 이렇게 쓰면 좋겠다는 제안을 전달합니다.
자동화 03
업무일지 생성
예전에는 스킬을 써서 마크다운 파일이 만들어지게 해 두는 정도였습니다. 지금은 에이전트가 업무일지까지 만듭니다.
지시하는 방식도 함께 바뀌었습니다. 예전에는 “한 줄 이렇게 해 줘”를 반복했고, 지금은 길게 쓰는 쪽으로 늘었다는 것이 참가자 표현입니다.
②하위 에이전트에게 보낸 프롬프트를 직접 봤다
서브에이전트나 병렬 에이전트에 일을 시키면, 메인 Claude Code가 하위 에이전트에게 어떤 프롬프트를 보냈는지 화면에서 볼 수 있습니다. 참가자는 그 프롬프트가 진행자가 쓰는 방식과 거의 같았다고 말했습니다.
“서브에이전트나 병렬 에이전트를 시키면 메인 Claude Code가 걔네한테 프롬프트를 어떻게 쳤는지도 볼 수 있어요. 근데 그게 진행자가 치는 거랑 거의 비슷해요. 길게 맥락 설명하고 뭐가 필요하고 이렇게 하는 거. 그런 것도 이 세션 하면서 배우고, 아 이렇게 치는구나 하고 봤습니다.”
4주차 1교시 · 참가자 (호칭은 역할 표현으로 바꿨습니다)
진행자는 1년쯤 전에는 이런 프롬프트가 화면에 그대로 보였다고 덧붙였습니다. 개발팀에서도 그 화면을 계속 보는 것이 실력이 느는 방법이라고 말해 왔는데, 요즘은 하위 단계로 들어가 있어 잘 보이지 않습니다. 그래도 안쪽을 열어 보면 지금 어떻게 하고 있는지 확인할 수 있습니다.
이어서 마크다운 이야기가 나왔습니다. 제목(#)으로 영역을 끊고, 코드 블록(```)으로 붙여 넣은 스크립트나 원본 데이터의 영역을 표시합니다. 내가 지시하는 문장과 붙여 넣은 자료가 섞여 있으면 명확하지 않기 때문입니다. 진행자는 이런 것을 프롬프트 기법이라고 부르며, 한 번 써 보면 바로 알게 되는 수준이라고 말했습니다.
③지원 사업 신청 서류 — 한 번 수정해 제출, 그대로 승인
다른 참가자는 업무 사례로 정부 지원 사업 신청 서류를 먼저 꺼냈습니다. 서류를 문서로 만드는 작업을 전부 맡겼고, 본인이 직접 손댄 부분은 거의 없었습니다.
“제가 건드린 건 없어요. 그 문서에서 그냥 다 Claude가 해 줬어요. 한 번 정도 수정하고 보냈고, 그게 바로 승인 나서 ‘잘만 쓰면 진짜 문서 혁신을 할 수 있겠다’ 싶었습니다.”
4주차 1교시 · 참가자
요청받은 스프레드시트 작업도 이 방식으로 만들었습니다. 그다음에 나온 것이 하반기 전략 보고서입니다.
④하반기 전략 보고서 — 가장 싫어하던 작업
이야기의 대부분은 하반기 전략 보고서였습니다. 참가자는 슬라이드 작업이 평소 가장 싫어하는 일이라고 먼저 말했습니다. 그런데 이번에는 처음으로 에세이처럼 길게 쓴 세션이 됐습니다.
링크를 주고 무엇을 이해해야 하는지 적고, 담당하게 된 지역과 그 배경, 언제부터 언제까지 어떤 방향으로 전략을 잡을 생각인지, 참고할 레퍼런스는 무엇인지까지 적었습니다. 참가자 표현으로는 “맥락을 많이 넣으려고 했다”입니다.
위 줄 네 가지는 참가자가 세션 시작 시점에 직접 적어 넣은 것입니다. 아래 줄은 그 뒤에 이어진 순서입니다.
세션이 길어진 만큼 부담도 있었습니다.
“컨텍스트를 두 번 compact 할 정도로 나름 되게 신경 쓴 세션이었는데 진짜 힘들었거든요. 생각보다. 아, 이거 그냥 감마 돌리고 내가 수정하는 게 쉬울 수도 있겠다 싶을 정도로.”
4주차 1교시 · 참가자
결과물을 고치려면 슬라이드 편집 도구가 따로 필요해서 그것도 구매했습니다. 참가자 표현으로는 “안 사면 수정하기가 너무 힘드니까” 어쩔 수 없이 산 것입니다.
구분
이번 전략 보고서 세션에서 한 일
맥락 작성
링크를 주고 무엇을 이해해야 하는지, 담당 지역과 배경, 기간과 전략 방향, 참고 레퍼런스까지 에세이처럼 길게 적었습니다.
에이전트
하나에만 지시하지 않고 에이전트 팀을 각각 꾸려 진행했습니다.
디자인
세션을 시작할 때 디자인 템플릿을 함께 제공했습니다.
세션 길이
컨텍스트를 두 번 compact 할 만큼 길어졌습니다.
도구
슬라이드를 수정하려면 편집 도구가 필요해 따로 구매했습니다.
⑤보고 결과 — 만든 자료로 경영진에게 보고했다
참가자는 이 자료로 실제 보고를 했습니다. 진행자가 결과를 보여 달라고 하자 처음에는 거절했습니다.
참가자 — “안 돼요. 너무 창피해서.” 진행자 — “창피한 그거를 지나야 돼요. 그 생 날것의 그걸 보고 피드백 받고 해야 돼요.”
4주차 1교시 · 자료를 화면에 띄우기 직전 대화
화면에 띄운 자료에는 목차와 요약이 있었고, 그다음에 무엇을 어떤 순서로 하겠다는 계획과 근거를 적어 두었습니다. 진행자는 “맥락을 많이 잘 넣으셨다”, “설득력 있게 하신 것 같다”고 평가했고, 위계가 잘 잡혀 있고 설명하기 쉽게 돼 있다는 점을 이유로 들었습니다.
보고 자리에서 받은 피드백도 긍정적이었습니다. 한 항목을 조금 더 해 달라는 요청 외에 다른 지적은 없었고, “쉽지 않았을 텐데 그렇게 포부를 잡은 것도 좋다”는 말을 들었습니다.
진행자는 이 결과물을 “AI 세션을 듣고 Claude Code를 써서 제대로 문서와 발표 자료를 만들어 본 첫 결과물”이라고 정리했습니다. 참가자는 같은 데이터로 다른 형식의 깔끔한 버전도 한 번 만들어 봤지만, 그것은 “이게 되나” 확인하려고 수정 없이 돌려 본 테스트였고 실제 발표는 앞의 자료로 했다고 밝혔습니다.
⑥“AI스러움”의 정체 — 미리 빼 달라고 요청한 것
참가자는 발표를 시작하기 전에 한 가지를 미리 밝혔습니다.
“Claude Code로 만들었다. 그래서 부족하게 느껴지거나 AI스러워 보이는 부분들은 있을 수 있다. 내가 아직 완벽하지 않아서. 근데 내가 업무를 하기 위해서 이렇게 만들었으니까 그런 부분은 양해를 구한다.”
4주차 1교시 · 참가자가 보고 전에 먼저 말한 내용
그런데 진행자가 자료를 보고 한 말은 반대였습니다. “오히려 AI스럽지 않았다”, “날것 같았다”입니다. 이유를 물어보니 참가자가 미리 요청해 둔 것이 있었습니다.
구분
이번 자료에서 있었던 일
미리 요청
진행자가 앞서 지적했던 특정 선 장식을 전부 빼 달라고 만들기 전에 요청했습니다.
결과
진행자가 받은 인상은 AI스럽지 않고 날것 같다였습니다.
판별 기준
많이 본 사람은 “그냥 AI로 찍어냈구나” 하는 느낌을 알아봅니다. 진행자는 그런 요소는 다 빼야 한다고 말했습니다.
남은 아쉬움
참가자는 잘 만들고 못 만들고의 기준을 모르겠다고 했고, 시간이 더 있었으면 더 다듬고 싶었다고 말했습니다.
이번 사례에서 “AI스러움”을 만든 것은 자주 반복되는 특정 시각 요소였습니다. 만들기 전에 그 요소를 빼 달라고 적어 두면 결과가 달라집니다.
⑦결론 — 예쁘게가 아니라 잘 전달되면 된다
기준을 모르겠다는 참가자의 말에 진행자가 답한 것이 이 대목의 결론입니다.
“결국에는 본사 입장에서 그게 잘 와닿고 보이는 거면 되죠. 그거 이쁘게 만든다고 그게 중요합니까. 어차피 잘 전달되면 되지.”
4주차 1교시 · 진행자
진행자가 이 자료를 괜찮다고 본 이유도 같은 기준이었습니다. 내용이 정리돼 있어 보기에 편하고 설명하기도 편했다는 것입니다. 판단 기준은 보고를 받는 쪽에 내용이 전달됐는지였습니다.
이 대목에서 나온 순서
진행자가 “이번 주에 AI를 써서 잘 활용해 본 것이 있느냐”고 질문
한 참가자 — 개인 에이전트 자동화(아티클 요약·다음 날 아침 개선점·업무일지)
같은 참가자 — 서브에이전트가 보낸 프롬프트를 직접 보며 쓰는 법을 익힌 경험
다른 참가자 — 지원 사업 신청 서류를 한 번 수정해 제출, 그대로 승인
같은 참가자 — 하반기 전략 보고서를 만든 과정(긴 맥락·에이전트 팀·디자인 템플릿·compact 2회)
자료를 화면에 띄우고 진행자가 평가, 경영진 보고 결과 공유
보고 전에 “Claude Code로 만들었다”고 미리 밝힌 이야기와 “AI스러움” 대화
진행자의 정리 — 잘 전달되면 된다
회사·제품·거래처 이름과 매출·계약 관련 수치는 대외 공개 기준에 따라 모두 제외했습니다.
참가자가 만든 전략 보고서가 “AI스럽지 않다”는 평을 받은 이유로 이 회차에서 말한 것은 무엇입니까?
해설 — 참가자는 만들기 전에 진행자가 앞서 지적했던 선 장식을 전부 빼 달라고 요청했습니다. 진행자는 많이 본 사람은 AI로 찍어낸 느낌을 알아본다고 하면서, 그런 요소는 빼야 한다고 말했습니다.
마크다운으로 명령과 데이터를 나눈다
프롬프트를 한 줄로 이어서 적으면 어디까지가 내가 시키는 말이고 어디부터가 붙여넣은 자료인지 표시가 남지 않습니다. 1교시에서 진행자가 설명한 방법은 마크다운 기호 두 개로 그 경계를 표시하는 것이었습니다.
기호는 두 가지입니다. 백틱 세 개로 감싸는 코드블록과, 샵으로 시작하는 제목입니다.
이 대화가 나온 자리
한 참가자가 백틱으로 묶는 것과 샵으로 끊는 것이 무슨 차이냐고 물으면서 시작된 대화입니다. 진행자가 두 기호가 각각 무엇을 표시하는지 답했고, 백틱을 키보드에서 어떻게 입력하는지까지 이어졌습니다.
이 문서 핵심
마크다운 파일의 제목 구조는 AI가 이해하기 좋은 방식입니다. 제목이 있으면 순서가 들어가고 구분 지점이 생깁니다.
코드블록은 “이 영역은 스크립트나 코드처럼 그대로 복사해 온 원본 데이터다”를 표시합니다. 제목은 영역을 끊어서 위쪽은 넣은 데이터, 아래쪽은 내가 설명하는 내용이라고 나눕니다.
나누는 이유는 하나입니다. 내가 내리는 명령과 그 안에 들어가는 데이터가 섞이면 명확하지 않습니다. AI가 어느 정도는 알아서 구분하겠지만, 섞여 있으면 정확도가 떨어집니다.
①에이전트가 만드는 마크다운 파일도 같은 구조다
이 이야기는 한 참가자의 실습 경험에서 시작됐습니다. 서브에이전트·병렬 에이전트에 일을 시키면 메인 Claude Code가 그 에이전트들에게 어떤 프롬프트를 썼는지 화면에서 볼 수 있는데, 그 방식이 진행자가 직접 쓰는 것과 거의 같았다는 것입니다. 맥락을 길게 설명하고 무엇이 필요한지 적는 방식입니다.
진행자는 1년 전 화면과 비교했습니다. 그때는 Claude가 작업을 하나씩 하면서 스스로 프롬프트를 쓰는 과정이 그대로 보였고, 개발팀에서도 그 화면을 계속 보는 것만으로 실력이 는다고 이야기했다고 합니다. 요즘은 그 과정이 화면에 바로 보이지 않지만, 열어 보면 어떻게 하고 있는지 확인할 수 있습니다.
열어서 확인할 수 있는 것 중 하나가 에이전트가 만드는 마크다운(.md) 파일의 생김새입니다. 진행자는 그것을 위계 구조라고 불렀습니다. AI가 이해를 잘하는 방식으로 에이전트가 스스로 바꿔서 내놓는 것이라는 설명입니다.
제목
샵으로 시작하는 줄 — 무엇에 대한 내용인지 이름을 붙인다
→
순서
제목이 있으니 앞뒤가 생긴다 — 어느 것이 먼저인지 표시된다
→
구분 지점
영역이 끊기는 자리 — 여기까지가 한 영역이라고 표시된다
진행자는 상황에 따라 쓰는 방법이 다르다고 덧붙였습니다. 제목을 붙여 이름을 다는 경우가 있고, 어떤 것은 묶어서 안에 넣는 경우가 있고, 그냥 끊어 줄 것은 끊는 경우가 있습니다. 이런 것을 프롬프트 기법이라고 불렀습니다.
②기호 두 개가 각각 표시하는 것
참가자의 질문은 “백틱으로 묶는 것과 샵으로 끊는 것이 무슨 차이냐”였습니다. 진행자의 답을 표로 정리하면 이렇습니다.
표기
이 표시가 뜻하는 것
1교시 진행자 설명
코드블록 백틱 3개로 감싼 영역
이 영역 안은 그대로 복사해 온 원본 데이터다. 스크립트를 다 넣거나 코드를 다 넣을 때 쓴다.
“이 영역이 그냥 복붙해 왔구나, 그 정도의 데이터를 그냥 다 넣은 거구나라고 이해할 수 있도록 블록 영역을 잡아 주는 것”
제목 # 샵으로 시작하는 줄
여기서 영역이 끊긴다. 위쪽은 넣은 데이터, 아래쪽은 내가 설명하는 내용이다.
“이 영역을 끊어서 내가 밑에 할 말을 적으면, 위에 있는 이 데이터를 넣은 거고 이 밑에는 내가 설명하는 거라고 끊어 줄 수 있다”
두 기호는 하는 일이 다릅니다. 코드블록은 안에 든 것의 종류를 표시하고, 제목은 영역과 영역 사이의 경계를 표시합니다.
③섞어 쓴 프롬프트와 나눠 쓴 프롬프트
같은 요청을 두 가지로 적어 보면 차이가 바로 보입니다. 아래 두 예시는 1교시에서 설명한 규칙을 그대로 적용해 만든 것입니다.
아래 줄의 파란 칸이 내가 쓴 문장, 회색 칸이 붙여넣은 데이터입니다. 기호가 그 경계를 표시합니다.
❌ 섞어 쓴 경우 명령과 데이터가 구분 표시 없이 이어져 있다
아래 설정 파일 확인해 줘 {"name": "report", "retry": 3, "timeout": 30} retry를 5로
올리고 나머지 항목은 그대로 둬 어느 줄을 바꿨는지도 알려 줘
✅ 나눠 쓴 경우 제목으로 영역을 끊고, 데이터는 코드블록 안에 넣는다
# 요청
아래 설정에서 retry 값을 5로 올려 주세요.
어느 줄을 바꿨는지 함께 알려 주세요.
# 데이터
```
{
"name": "report",
"retry": 3,
"timeout": 30
}
```
# 참고
나머지 항목은 그대로 두세요.
나눠 쓴 예시에서 # 줄이 영역을 끊고, 백틱 세 개 사이의 내용이 “붙여넣은 원본 데이터”로 표시됩니다. 마지막 # 참고는 데이터 아래에 내가 덧붙이는 설명입니다.
④왜 나누는가
진행자가 든 이유는 한 가지입니다.
“이게 막 다 적는다고 해서 AI도 이해를 하고 구분을 하긴 하겠지만, 내가 명령 내리는 것과 이 안에 들어가는 게 좀 섞여 있으면 명확하지 않을 수가 있거든요.”
1교시 · 진행자
다 이어서 적어도 AI가 어느 정도는 알아서 구분합니다. 그래도 명령과 데이터가 섞여 있으면 무엇을 시킨 것인지 명확하지 않아, 결과가 요청과 어긋날 여지가 남습니다. 기호로 경계를 표시해 두면 그 여지가 줄어듭니다.
표시 01
이 영역은 원본 데이터
백틱 세 개로 감싸 두면 “그대로 복사해 온 자료”라고 표시됩니다. 스크립트나 코드를 통째로 넣을 때 쓰는 방법입니다.
표시 02
여기서 영역이 끝난다
샵으로 제목을 달면 그 줄에서 영역이 끊깁니다. 위는 넣은 데이터, 아래는 내 설명으로 나뉩니다.
진행자는 마크다운 문서뿐 아니라 코드를 넣을 때도 이 표시를 많이 쓴다고 했습니다. 코드블록으로 감싸 두면 그 안의 내용이 어떤 종류인지도 함께 전달되고, 그렇게 해야 AI가 잘 이해한다는 설명이었습니다.
⑤입력 방법과 끊는 정도
실습 중에 나온 질문 두 가지입니다. 하나는 백틱을 키보드에서 어떻게 입력하느냐였습니다.
백틱(`)은 숫자 1 옆 키에 있습니다(물결 ~이 같이 새겨진 키). 코드블록은 이 기호를 세 번 연속으로 입력해 시작하고, 데이터를 넣은 다음 다시 세 번 입력해 닫습니다.
다른 하나는 얼마나 자주 끊어야 하느냐였습니다. 한 참가자는 자기가 쓰던 방식을 이렇게 말했습니다.
“저는 끊는 것만 했거든요. 사진 넣고 끊고, 설명하고 또 끊고, 다른 사진 넣고 끊고, 이렇게요.”
1교시 · 참가자
“그렇게 해도 돼요. 그렇게까지 안 끊어도 상관없어요.”
1교시 · 진행자
정해진 개수는 없습니다. 항목마다 전부 끊어도 되고, 그 정도로 잘게 나누지 않아도 됩니다. 기준은 명령과 데이터가 섞이지 않는가 하나입니다.
진행자는 이런 규칙이 몇 가지 더 있고 그것을 프롬프트 기법이라고 부른다고 했습니다. 외워서 시작할 필요는 없고, 간단하게 한 번 써 보면 알게 되는 종류라는 것이 1교시의 정리였습니다.
AI가 대체하기 힘든 것, 한계를 긋지 않는 태도
4주차는 마지막 회차입니다. 1교시에서 진행자가 다룰 순서를 정리하면서 태도에 관한 두 가지를 함께 넣었습니다. 하나는 AI가 대체하기 힘든 일이 무엇인가, 다른 하나는 스스로 한계를 긋지 않는 것입니다.
앞의 질문은 진행자가 꺼낸 것이 아닙니다. 참가자가 예전에 진행자에게 먼저 물었던 질문이고, 마지막 회차에서 그 답을 다시 정리했습니다.
마지막 회차에서 정리한 두 가지
AI가 대체하기 힘든 일이 무엇인지 확인하고, 이어서 자기 한계를 미리 정해 두지 않는 태도를 이야기했습니다. 두 가지 모두 도구 사용법이 아니라 태도에 대한 내용입니다.
이 문서 핵심
1교시에서 대체하기 힘든 것으로 나온 항목은 다섯 가지입니다. 사람과 사람이 만나서 해야 하는 일, 방향을 설정하는 일, 책임지는 일, 사람의 마음을 얻는 일, 그리고 육감입니다.
같은 1교시에서 태도로 나온 것은 하나입니다. “이건 안 될 거야”라고 미리 정해 버리면 그다음으로 넘어가기 어렵습니다. 되는 것을 알아야 시도하고, 전문가가 아니어도 몇 차례 물어보면 검증할 수 있습니다.
두 가지를 합치면 이렇게 됩니다. 사람이 계속 맡아야 할 일이 남아 있고, 그 일을 맡으려면 자기가 할 수 있는 범위를 미리 좁혀 두지 않아야 합니다.
①AI가 대체하기 힘든 것
1교시 초반, 진행자가 이번 회차에 다룰 것을 정리하면서 이 주제를 꺼냈습니다. 원래 참가자가 진행자에게 물었던 질문입니다.
“AI가 대체하기 힘든 게 어떤 게 있을까요? 그때 제가 뭐라고 했는지 기억나세요?”
1교시 · 진행자가 예전 질문을 다시 꺼내며
참가자가 기억해 낸 답은 “사람과 사람의 커뮤니케이션”이었습니다. 진행자가 그 답을 받아 정리한 문장은 이렇습니다.
“맞아요. 사람과 사람이 만나서 해야 될 것들을 대체하기 힘들다는 거. 그게 중요해요. 업무는 업무대로 할 수 있는데, 대체하기 힘든 것들이 많으니까.”
1교시 · 진행자
업무 자체는 AI로 처리할 수 있다는 것을 전제로 두고, 그래도 대체하기 힘든 것들이 많다고 말한 답입니다.
1교시 끝 무렵에 다시 나온 두 항목
1교시가 끝날 무렵, 진행자가 아직 보여 주지 않은 마지막 장이 있다는 것을 확인하고 그 내용을 읽었습니다. 거기 적혀 있던 것은 두 가지였습니다.
“AI가 대체하기 힘든 것. 방향 설정하는 거. 그리고 책임지는 거.”
1교시 · 진행자가 자료 마지막 장을 읽으며
참가자는 여기에 하나를 더 붙였습니다. 아래 세 카드가 이 대화에서 나온 항목입니다.
항목 01
방향을 설정하는 일
자료 마지막 장의 첫 항목입니다. 진행자는 앞서 리더 역할을 설명하면서도 목표를 줄 수 있도록 방향을 설정하고 보완하는 일이라고 말했습니다.
항목 02
책임지는 일
두 번째 항목입니다. 참가자는 “책임지는 건 자기 역할이고, 책임질 사람이 누구든 책임져야 한다”고 받았습니다.
항목 03
사람의 마음을 얻는 일
참가자가 더한 항목입니다. 사람의 감정이 들어가고 느껴지는 부분이라 대체하기 힘들다는 것이었습니다.
육감 — 센서로 만들어지지 않는 부분
사람의 마음을 얻는 일에서 대화가 육감으로 넘어갔습니다.
“사람이 오감이 있다고 하는데, 저는 하나 더 있다고 생각하는 게 육감이거든요. 촉 이런 거. 쎄함 이런 거 알아듣고 안 하는 것들.”
1교시 · 참가자
진행자는 “육감이 제일 중요하다”, “말로 표현하기가 애매한 식스센스”라고 받았습니다. 참가자는 눈치라고 부를 수도 있겠다고 덧붙였습니다.
이어서 감각별로 어디까지 만들어졌는지 확인했습니다. 시각·청각·후각은 이미 되고 촉각도 터치 센서로 되는데, 육감은 다르다는 정리입니다.
1교시 대화에서 언급된 감각만 적었습니다. 미각은 나오지 않았습니다. 육감은 참가자 표현으로 “딱 봐도 쎄함이 느껴지는 것”, 그래서 알아듣고 하지 않는 판단입니다.
참가자는 이 대목을 이렇게 마무리했습니다. 육감은 아직 대체하기 어렵고, 그래도 사람과 만나면서 일을 해야 하니 필요하다는 것입니다. 1교시 초반에 나온 “사람과 사람이 만나서 해야 될 것들”과 같은 내용으로 다시 정리된 부분입니다.
1교시에서 이 항목들이 나온 순서
참가자가 예전에 진행자에게 “AI가 대체하기 힘든 게 무엇이냐”고 물었던 일을 진행자가 다시 꺼냄
참가자가 그때 답을 “사람과 사람의 커뮤니케이션”으로 기억해 냄
진행자가 “사람과 사람이 만나서 해야 될 것들”로 정리
1교시 끝 무렵, 자료 마지막 장의 두 항목(방향 설정 · 책임)을 읽음
참가자가 “사람의 마음을 얻는 일”을 더함
오감과 육감 이야기로 넘어가, 감각별로 센서가 어디까지 나왔는지 확인
전사에는 이 항목들을 어떤 기준으로 골랐는지에 대한 설명은 나오지 않습니다.
진행자는 1교시 순서를 정리하면서 이 주제를 “태도적인 것”과 함께 넣었습니다. 대체하기 힘든 일이 남아 있다는 것은 사람이 계속 맡아야 할 일이 있다는 뜻입니다. 그 일을 실제로 맡으려면 자기가 할 수 있는 범위를 미리 좁혀 두지 않아야 합니다. 아래 ②가 그 이야기입니다.
②스스로 한계를 긋지 않는 태도
1교시 중반, 참가자가 만든 자료를 함께 본 뒤 진행자가 다음 주제를 이렇게 열었습니다.
“다음에 얘기할 거는 태도적인 거예요. 자기가 한계를 스스로 긋지 않는 게 중요합니다. 이게 무슨 의미인가. ‘이건 안 될 거야’, 설령 지금은 기술력 때문에 안 될 수 있을지언정 그렇게 아예 생각해 버리는 거.”
1교시 · 진행자
참가자가 어떤 경우가 그런 것인지 물었고, 진행자는 자기 한계를 정해 두면 무슨 일이 생기는지로 답했습니다.
“스스로 자기가 한계를 딱 끊어놓고 ‘나는 여기까지야’ 해버린 거는, 그 뒤로 이어가기가 쉽지가 않아요.”
1교시 · 진행자
진행자가 든 상황은, 잘 모르는 분야의 질문을 받았을 때 “이건 내가 알 게 아니다”라고 정해 버리고 다른 사람에게 물으러 가는 경우입니다. 진행자의 판단은 하나였습니다. 1차적으로는 자기가 다 해서 알 수 있고, 그렇게 할 수 있다는 것을 아는 것이 중요하다는 것입니다.
1교시에서 나온 다섯 가지
진행자가 이어서 말한 내용을 항목별로 나눠 정리했습니다. 진행자가 “다섯 가지”라고 세어 제시한 것은 아닙니다.
01되는 걸 알아야 시도한다
원하면 만들 수 있다는 것을 알아야 시도할 수 있습니다. 진행자가 “이렇게 할 수 있다”를 하나씩 먼저 보여 준 이유가 이것입니다. 되는 것을 본 다음에야 자기도 해 보게 된다는 설명이었습니다.
02전문가가 아니어도 몇 차례 물어보면 검증할 수 있다
내가 그 분야 전문가가 아니어도 몇 차례 물어보면 검증이 됩니다. 진행자는 1년 전까지만 해도 이게 어려웠지만 지금은 웬만하면 검증할 수 있다고 덧붙였습니다.
03자기 자존을 낮추지 않는다
진행자가 “여기가 가장 중요하다”고 말한 항목입니다. 스스로 커트라인을 만들지 말고, 자기 자존을 낮추지 말라는 것입니다. 제안에 그치지 않고 실제로 만들어 낸 순간부터 주변의 평가가 들어오기 시작합니다 — “저렇게까지 하는구나”를 사람들이 알게 된다는 표현이었습니다.
04한 차례 더 해 본다 — “AI는 기세”
진행자가 같이 일하는 동료가 자주 하는 말이라고 소개했습니다. 진행자가 붙인 뜻은 이렇습니다. 한 차례 더 해 보면 되는데, 대부분 하지 않습니다. 원래 쓰던 뜻과는 조금 다르다는 단서를 함께 달았습니다.
05이해되지 않으면 한 번 더 물어본다
진행자가 참가자에게 자료를 전달할 때, 받은 사람이 “내가 이해할 수 있도록 조금만 설명해 줘”라고 한 번 더 요청했다면 이해할 수 있는 형태로 다시 만들어 줬을 것이라고 말했습니다. 어떻게 해서 그렇게 되는지도 물어보면 알려 줍니다. 누가 알려 주지 않으면 모르는 것들이니, 한 번 더 물어보는 노력이 필요하다는 것입니다.
05를 순서로 옮기면 이렇게 됩니다. 받은 자료가 이해되지 않을 때 그대로 두지 않고, 자료를 준 쪽에 한 번 더 요청하는 것입니다.
받는다
정리된 자료를 그대로 받는다 — 읽어도 무슨 말인지 모르는 부분이 있다
→
한 번 더 요청한다
“내가 이해할 수 있도록 조금만 설명해 줘” 또는 “어떻게 해서 이게 되는 거냐”고 한 번 더 묻는다
→
다시 받는다
내가 이해할 수 있는 형태로 다시 만들어 준다 — 진행자가 “이해할 수 있게끔 더 만들어서 해줄 거예요”라고 말한 부분
미리 정해 버리기 쉬운 상황
왼쪽은 1교시 대화에 나온 상황이고, 오른쪽은 그때 진행자가 말한 대응입니다.
상황
1교시에서 말한 대응
지금 기술로는 안 될 것 같다
지금 안 될 수 있어도 “이건 안 될 거야”라고 아예 정해 두지 않는다
내가 아는 분야가 아니다
1차적으로 자기가 해 보면 알 수 있다. 그렇게 할 수 있다는 것을 아는 게 중요하다
내가 전문가가 아니다
몇 차례 물어보면 검증할 수 있다. 1년 전과 달라진 부분이다
내 수준이 부족한 것 같다
자기 자존을 낮추지 않는다. 실제로 만들어 낸 순간부터 주변의 평가가 들어오기 시작한다
받은 자료가 이해되지 않는다
“내가 이해할 수 있도록 조금만 설명해 줘”라고 한 번 더 요청한다
다섯 줄 모두 1교시 발언을 정리체로 옮긴 것입니다. 전사에 없는 항목은 넣지 않았습니다.
1교시에서 진행자가 “여기가 가장 중요하다”고 말한 항목은 무엇입니까?
해설 — 진행자는 “여기가 가장 중요한데, 아까 제가 커트라인을 만들면 안 된다고 그랬잖아요. 자기의 자존을 낮추면 안 돼요”라고 말했고, 실제로 만들어 낸 순간부터 주변의 평가가 달라진다고 이어서 설명했습니다.
마지막 회차의 두 가지를 한 문장으로 정리하면 이렇습니다. 사람과 사람이 만나서 하는 일, 방향과 책임, 육감은 남아 있고, 그 일을 맡으려면 “이건 안 될 거야”와 “나는 여기까지야”를 미리 정해 두지 않아야 합니다.
경계가 허물어진 팀, 신뢰·배려·개방
4주차 1교시 중반에 진행자가 “회사는 왜 팀을 만들어 주는가”를 물었습니다. 그 질문에서 시작해, 팀 안의 역할 구분이 6개월 동안 어떻게 바뀌었는지와 함께 일할 때의 태도까지 이어졌습니다.
앞부분은 팀이라는 단위가 무엇인지, 뒷부분은 신뢰 → 배려 → 개방 순서로 이어지는 태도입니다. 이 문서는 그 두 부분을 정리했습니다.
이 대목이 나온 자리
진행자가 정리한 전제는 이렇습니다. AI를 잘 쓰는 것만으로 일이 되지는 않고, 사람끼리 일하는 방식이 함께 중요하다. 그래서 도구 이야기 중간에 팀과 태도를 한 번 짚었습니다.
이 문서 핵심
1부 — 팀의 경계. 전통적인 팀은 기획·디자인·개발로 역할이 나뉘어 있습니다. AI를 다루기 전까지 이 구분이 뚜렷했고, 구분 때문에 초반에 갈등이 많았습니다. 약 6개월이 지나 팀 전원이 AI 쓰는 법을 어느 정도 이해하자, 경계가 허물어져도 괜찮겠다고 받아들이게 됐습니다.
2부 — 함께 일할 때의 태도. 순서가 있습니다. 먼저 신뢰가 생겨야 하고, 그러려면 배려의 기준이 명확해야 합니다. 상대에게도 자기 업무와 일정이 있으니 요청하기 전에 확인할 것이 있습니다. 일을 넘길 때 그대로 던지지 않고 한 번 더 확인해서 다듬어 전달하면 진정성이 전해집니다. 그다음 단계가 개방입니다.
①질문 — 회사는 왜 팀을 만들어 주는가
진행자는 팀의 정의를 먼저 말하지 않고 질문부터 했습니다. “원래 팀이라는 게 뭐라고 생각하시나요? 회사에 왜 팀을 이렇게 만들어 줄까?”
“혼자서는 안 되니까요. 누구는 이걸 잘하고 누구는 저걸 잘하고, 이걸 못하는 사람은 저걸 잘하니까, 서로 밸런스를 맞추는 거죠.”
1교시 · 한 참가자의 답
같은 참가자가 덧붙인 비교가 있습니다. 에이전트에 각 직무를 맡기는 것과 같다는 것입니다. 에이전트마다 맡길 일을 나누듯이, 사람도 잘하는 것이 서로 달라서 나눠 맡는다는 이야기입니다.
②전통적인 구성 — 역할이 나뉘어 있다
진행자가 예로 든 것은 제품을 하나 만드는 팀입니다. 기획자가 있고, 디자이너가 있고, 개발자가 있습니다. 전체를 총괄하는 PM은 설명에서 뺐습니다. 각각 맡은 역할이 있고, 그렇게 한 팀을 만듭니다.
다른 조직도 같은 구조라고 봤습니다. 영업 팀이 있고 마케팅 팀이 있습니다. 마케터가 전략을 정하고, 영업에서 그에 맞춰 고객과 만나 실행합니다. 진행자는 마케터가 하는 이 역할은 아직 기술이 잘 해내지 못하는 편이라고 덧붙였습니다.
③6개월 — 경계가 허물어져도 괜찮겠다
진행자가 자기 팀을 예로 들었습니다. AI를 잘 다루기 전까지는 이 역할 구분이 매우 뚜렷했고, 그 구분 때문에 팀원들이 초반에 힘들었을 것이라고 봤습니다. 안에서 갈등도 많았고, 오해를 바로잡는 데 진행자 본인도 시간을 많이 썼다고 말했습니다.
시점
팀 안에서 있었던 일
역할 경계에 대한 인식
초반
역할 구분이 뚜렷했고 갈등이 많았다. 오해를 바로잡는 데 시간이 들었다.
기획·디자인·개발의 구분이 분명했다
약 6개월 뒤
팀 전원이 AI 쓰는 법을 어느 정도 이해하게 됐다.
경계가 허물어져도 괜찮겠다고 조금씩 받아들였다
“한 6개월 지나고 이제 전부 다 AI를 어느 정도 쓸 줄 이해하니까, 이 경계가 좀 허물어져도 괜찮겠다는 걸 이제 조금은 이해하는 것 같아요.”
1교시 · 진행자
위아래 모두 같은 세 역할입니다. 역할의 종류는 그대로이고, 그 사이 구분만 옅어졌습니다.
④팀의 정의와 리더의 역할
진행자가 이어서 정리한 팀의 정의입니다.
“팀이라는 건 원래 불완전한 사람들끼리 모여서 서로 보완을 하면서, 각 팀이 가지고 있는 목표를 결과로 만드는 겁니다.”
1교시 · 진행자
이어서 리더의 역할을 세 가지로 정리했습니다.
리더 역할 01
방향을 설정한다
팀원이 목표를 가질 수 있도록 방향을 정해 줍니다. 진행자가 리더 역할의 첫 번째로 든 것입니다.
리더 역할 02
부족한 부분을 보완한다
팀은 불완전한 사람들이 모인 곳이라는 전제에서 나옵니다. 팀원이 부족한 부분을 보완하는 것이 리더가 하는 일입니다.
리더 역할 03
원하는 결과를 만든다
팀이 가진 목표를 결과로 만드는 데까지가 리더의 역할이라고 정리했습니다.
⑤앞으로 — 한 사람이 할 수 있는 범위
경계 이야기의 결론은 전망이었습니다. 역할 구분이 옅어지면서 한 사람이 할 수 있는 일의 범위가 넓어진다는 것입니다.
진행자는 처음 팀 회의를 할 때부터 이 이야기를 해 왔다고 말했습니다. 연말쯤이면 팀원 한 사람이 혼자서도 그만큼 해낼 수 있게 된다는 이야기입니다. 처음에는 팀에서 이상적인 이야기로 받아들였지만, 올해 하반기에 팀이 얻은 것들이 뒷받침되면 실제로 될 수도 있다고 봤습니다. 팀원에게 “이런 게 되겠느냐, 그렇게 느껴지느냐”고 물었을 때 “될 수도 있겠다”는 답이 나왔다고 합니다.
전제가 하나 붙어 있습니다. 진행자의 표현은 “그게 설계가 되면”입니다. 저절로 그렇게 되는 것이 아니라, 그렇게 일할 수 있도록 미리 짜 두어야 가능하다는 단서입니다.
⑥태도의 순서 — 신뢰 · 배려 · 개방
여기서부터 2부입니다. 진행자가 태도를 말할 때 쓴 순서는 이렇습니다. 신뢰를 먼저 만들고, 함께 일하려면 배려가 있어야 하고, 그다음 단계가 개방입니다.
1단계
신뢰
먼저 만들어야 하는 것. 이것이 없으면 다음으로 넘어가지 않는다
→
2단계
배려
함께 일하려면 필요한 것. 기준이 명확해야 한다
→
3단계
개방
신뢰를 만들고 난 뒤에 오는 다음 단계
1교시에서 개방이 구체적으로 무엇을 뜻하는지는 설명되지 않았습니다. 순서만 “신뢰 다음이 개방”으로 제시됐습니다.
⑦배려의 기준을 명확하게
진행자가 배려를 설명한 문장은 짧습니다.
“배려가 이런 거예요. 자기가 꼭 해야 되는 건 아닌데, 상대방 입장을 생각해서 좀 더 얘기를 해 본다든지 하는 거.”
1교시 · 진행자
그러면서 “배려의 기준도 명확해야 된다”고 정리했습니다. 1교시 대화에서 그 기준으로 나온 것을 정리하면 아래와 같습니다.
01요청하기 전에 상대의 일정을 먼저 확인한다
상대에게도 그날의 일정이 있습니다. 언제 시작하고 언제 끝나는지를 먼저 확인하고 나서 시간을 정하는 것이 배려에 해당한다는 예가 나왔습니다.
02받는 쪽에도 자기 업무가 있다
그 자리에서는 해 주겠다고 답하기 쉽습니다. 그런데 받는 팀에도 원래 하던 일이 있어서, 업무가 많아진 상황에 일이 더해지면 부담이 됩니다.
03맡기는 쪽 의도와 무관하게 스트레스로 남는다
맡기는 사람은 부담을 줄 마음이 아니었더라도, 받는 쪽에는 해야만 하는 일이 하나 더 생깁니다. 진행자는 그런 상황이 받는 쪽에 스트레스로 남았다고 말했습니다.
04위계와 친한 정도가 있어도, 더 잘 해 줘야 한다
사람마다 위계가 있고 친한 정도도 다릅니다. 그런 차이가 있어도 더 잘 해 줘야 신뢰가 생기고, “내 사람”이라는 느낌이 든다는 것이 진행자의 정리였습니다.
05팀원을 한 명씩 살피고, 위에서 오는 이야기를 걸러 준다
진행자는 팀원을 한 명 한 명 챙기려 하고, 윗선에서 내려오는 이야기를 대신 받아 낸다고 말했습니다. 그래서 팀원들이 “무슨 일이 있어도 막아 줄 것”이라고 여기게 되고, 팀 안에 안정감이 생깁니다.
이 항목들의 결론으로 진행자가 한 말이 있습니다. 자기 평판보다 팀 안이 잘 돌아가는 것이 낫다.
⑧다듬어서 전달한다 — 신뢰가 생기는 지점
1교시에서 가장 구체적으로 설명한 것은 일을 넘기는 방식입니다. 받은 그대로 던지지 않는 것입니다.
같은 요청이라도 받는 쪽에 남는 인상은 두 가지로 나뉩니다. 그대로 넘기면 떠넘겼다는 인상이 남습니다. 한 번 더 확인해서 왜 필요한지와 자기 팀 사정을 정리해 보내면 제대로 부탁했다는 인상이 남습니다.
넘기는 방식
보내는 쪽이 한 일
받는 쪽에 남는 것
그대로 넘긴다
받은 내용을 확인 없이 그대로 전달
떠넘겼다는 인상
다듬어 넘긴다
한 번 더 확인하고, 왜 필요한지와 자기 팀 사정을 함께 적어 전달
제대로 부탁했다는 인상 · 진정성이 전해진다
“별거 아닌 것 같아도, 한 번 더 액션을 취해서 뭔가 다듬어서 전달해 주면 그 사람에 대한 진정성이 느껴져요. 그때부터 신뢰라는 게 쌓여요.”
1교시 · 진행자
이 방식은 받는 사람의 위치와 무관하게 같습니다. 진행자는 경영진에게 넘길 때도 다 검토하고 넘긴다고 말했습니다.
참가자가 든 사례도 있습니다. 상대가 이해하기 쉽게 정리해서 전달하려는 노력은 받는 쪽에서 느껴진다는 것입니다.
“고객 의견 하나를 Slack에 남기는 데도 시간을 쏟고 정성을 들였어요. 받는 팀이 최대한 이해할 수 있게 쓰려고요. 그런데 그걸 알아주더라고요. 느껴진다고.”
1교시 · 한 참가자
정리하면 이렇습니다. 상대가 이해할 수 있게 정리하는 데 쓴 시간은 받는 쪽에서 느껴집니다. 거기서 신뢰가 생기고, 신뢰가 생긴 다음이 개방입니다.
받는 쪽에서 할 수 있는 것도 하나 나왔습니다. 자료를 받았을 때 “내가 이해할 수 있게 조금만 설명해 달라”고 한 번 더 요청하는 것입니다. 그러면 보낸 쪽에서 이해할 수 있게 다시 정리해 줍니다. 원래 누가 알려 주지 않으면 모르는 것이니, 한 번 더 물어보는 편이 낫다는 이야기였습니다.
1교시에서 이 이야기가 나온 순서
스스로 한계를 긋지 않는 태도 이야기에서 팀 이야기로 넘어감
“회사에 왜 팀을 만들어 줄까” 질문 — 참가자가 “혼자서는 안 되니까”로 답함
전통적인 구성(기획·디자인·개발)과 영업·마케팅 팀의 예
자기 팀에서 역할 경계 때문에 초반에 갈등이 많았다는 회고
약 6개월 뒤 전원이 AI를 어느 정도 이해하면서 경계가 허물어져도 괜찮겠다고 받아들임
팀의 정의와 리더의 역할(방향 설정 · 보완 · 결과)
한 사람이 할 수 있는 범위가 넓어진다는 전망
AI만으로 되는 것이 아니라 사람끼리 일하는 방식도 중요하다는 전환
배려의 기준 — 상대 일정, 상대 업무량, 위계가 있어도 더 잘 해 주는 것
신뢰 다음이 개방이라는 순서 제시
다듬어서 전달하면 진정성이 전해지고 신뢰가 생긴다는 마무리
전사에서 이 구간은 54분경부터 1시간 13분경까지입니다.
1교시에서 팀 안의 역할 경계가 허물어져도 괜찮겠다고 받아들이게 된 계기로 말한 것은 무엇입니까?
해설 — 진행자는 AI를 잘 다루기 전까지 역할 구분이 매우 뚜렷했고 그 때문에 초반에 갈등이 많았다고 회고한 뒤, 약 6개월이 지나 전원이 AI 쓰는 법을 어느 정도 이해하자 경계가 허물어져도 괜찮겠다는 것을 조금씩 받아들이게 됐다고 말했습니다. 역할의 종류는 그대로이고 그 사이 구분만 옅어진 것입니다.
이 문서를 한 문장으로: 역할 경계는 팀 전원이 AI를 다룰 줄 알게 되면서 옅어졌고, 그렇게 일하려면 신뢰 · 배려 · 개방이 순서대로 필요하다.
레퍼런스를 판단 근거까지 모으기
1교시 후반(전사 01:23~01:50 구간)에 진행자가 화면을 공유하며 시연한 작업 방식입니다. 시작은 질문 하나였습니다. “UI 레퍼런스를 이만큼 가지고 있으면, 무엇을 할 수 있을까요.”
이 문서는 어떤 자료를 어디서 가져왔는지가 아니라, 전문성이 없는 사람이 어떻게 의사결정을 할 수 있게 되는가만 정리했습니다.
시연에서 확인한 것
이미지만 저장해 두면 참고 자료에서 끝납니다. 이미지마다 “이 화면은 왜 이 구조인가, 레이아웃을 왜 이렇게 짰는가”를 함께 적어 두면, 그때부터 의사결정에 쓸 수 있는 자료가 됩니다.
이 문서 핵심
같은 이미지를 모아도 결과가 달라지는 조건은 하나입니다. 판단 근거를 함께 적어 두었는가.
카테고리만 붙여 둔 자료는 AI가 검색해도 판단하지 못합니다. 왜 이 구조인지가 함께 적혀 있으면, 서비스를 만들 때 결정해야 하는 항목에서 전문성이 없어도 어떤 UI·UX가 적절한지 판단하고 근거를 댈 수 있습니다.
진행자가 강조한 것은 도구가 아니라 발상입니다. 같은 도구를 줘도 이걸 전부 모아서 판단 근거까지 정리하겠다고 생각하는 사람은 드물다는 것이 시연의 결론이었습니다.
①출발점 질문 — “다 가지고 있으면 뭘 할 수 있나”
진행자가 화면에 띄운 것은 국내·해외 서비스의 UI 레퍼런스가 대량으로 모여 있는 자료였습니다. 그리고 참가자들에게 물었습니다.
“이런 게 다 가지고 있다는 게 어떤 의미인가. 뭘 할 수 있을까요. 이걸 다 가지고 있으면요.”
1교시 · 진행자
한 참가자가 먼저 내놓은 답은 “참고”였습니다. 시안을 만들 때 보고 참고한다는 뜻입니다. 진행자는 그 답이 맞지만 거기서 멈춘다고 했습니다.
“근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요.”
1교시 · 진행자
이 시연이 나온 맥락은 “의사결정을 해 줄 수 있는 시스템을 만든다”는 하반기 계획 이야기였습니다. 그래서 질문의 초점도 “자료가 많다”가 아니라 “이 자료로 결정을 할 수 있느냐”에 있었습니다.
②이미지만 있을 때의 한계
이 대목에서 한 참가자가 “원래 이런 거 준비할 때 디자이너들이 다 캡처한다”고 말했습니다. 여기에 대한 진행자의 답이 이 문서에서 가장 중요합니다.
“그거는 사실 자료만 들어가 있는 거지, 왜 이 레이아웃 구조를 해야 되는지 의사결정에 들어가 있는 데이터는 들어가 있지 않잖아요.”
1교시 · 진행자
진행자는 지금 모아 둔 자료의 상태를 “그냥 카테고리만 짓는 거”라고 말했습니다. 형식에 맞는 분류만 붙여 두는 수준이라는 뜻입니다.
그래서 나중에 AI가 그 자료를 검색해도 문제가 생깁니다. 사진만 있으면 그 화면이 왜 그렇게 생겼는지를 판단하지 못합니다.
두 줄의 출발점은 같습니다. 두 번째 칸에서 무엇을 함께 적어 두었는가가 이후 단계를 바꿉니다.
③판단 근거를 함께 적어 둔다
진행자가 바꾼 지점은 하나입니다. 이미지마다 어떤 구조인지, 어떤 레이아웃인지, 왜 이 화면이 이렇게 되어 있는지를 함께 적어 둡니다.
정리한 결과는 Obsidian에 저장하고 있다고 했습니다. 원래는 위키 형태가 아니었는데 이번에 위키 형태로 바꿔서, 사진마다 설명을 붙여 계속 넣는 중이라고 설명했습니다.
비교 항목
이미지만 저장
판단 근거까지 저장
붙어 있는 정보
형식에 맞는 카테고리
구조·레이아웃과 그렇게 만든 이유
AI가 검색했을 때
판단하지 못함
판단 근거로 사용
쓸 수 있는 범위
참고 자료
의사결정 자료
사람에게 필요한 것
그 분야 전문성
무엇을 결정할지에 대한 질문
가운데 열은 전사에서 “그냥 카테고리만 짓는 거”로 표현된 상태이고, 오른쪽 열이 시연에서 보여 준 상태입니다.
④모으는 데 드는 실제 노력
이 방식의 어려움은 발상이 아니라 수집과 정리에 드는 시간에 있습니다. 진행자가 설명한 순서는 이렇습니다.
01
API로 받아 오기 — 자료를 한 번에 받아 오는 방법을 먼저 씁니다. 다만 한 번에 다 받아지지 않는 구간이 남습니다.
→
02
화면에서 하나씩 모으기 — 남은 것은 페이지를 열어 하나씩 모읍니다. 모은 다음에는 사람이 정리하는 작업이 따로 붙습니다.
→
03
VLM으로 다시 정리 — 모아 둔 화면을 모델에 다시 넣어, 어떤 구조인지 설명을 붙입니다.
한 번에 끝나는 작업이 아닙니다. 받아 오고, 남은 것은 다시 모으고, 정리하고, 또 정리하는 단계가 이어집니다. 진행자도 “이걸 가져오는 데 드는 노력”을 따로 언급했습니다. 이 문서에서 가져갈 것은 도구 이름이 아니라 판단 근거를 붙이는 작업에 그만큼의 공이 든다는 사실입니다.
⑤모아 두면 무엇이 가능한가
진행자가 말한 결과는 세 가지였습니다.
결과 01
전문성 없이 의사결정
서비스를 만들 때 결정해야 하는 항목이 나오면, 그 분야 전문성이 없어도 어떤 UI·UX가 적절한지 판단할 수 있습니다.
결과 02
근거를 댈 수 있다
“이 항목에서는 왜 이걸 결정해야 하는가”에 대해 실제 사례와 그 사례의 이유를 들어 설명할 수 있습니다.
결과 03
화면 구조를 만들어 낸다
정리해 둔 레퍼런스를 근거로 삼아 Codex에 이미지를 넘겨 UI 구조를 만들어 내는 데까지 이어집니다.
이 대목에서 한 참가자가 스스로 단계를 세어 정리했습니다. 레퍼런스를 쓰는 방식에는 단계가 있고, 시연에서 본 것은 그중 마지막 단계라는 이야기였습니다.
단계
하는 일
결과물
1단계
레퍼런스를 보고 그 부분을 참고한다
참고 자료
2단계
여러 개를 조합해 화면을 만들어 본다
시안
최종 단계
전부 모으고 판단 근거까지 정리해 구조를 만든다
의사결정 자료
1·2단계와 “최종 단계”는 한 참가자가 직접 세어 말한 구분입니다. 그 사이의 3·4단계가 무엇인지는 전사에 나오지 않습니다.
진행자는 이것이 특히 UX 업무에서 쓸모가 크다고 했습니다. 지금은 사람이 레퍼런스를 하나씩 보면서 판단하고 있는데, 판단 근거가 함께 정리돼 있으면 결정에 필요한 자료를 바로 꺼내 조합할 수 있기 때문입니다.
⑥응용 — 디자인 시스템을 다시 만들 때
같은 방식을 자기 제품에 적용한 예로 진행자가 든 것이 디자인 시스템 재정비입니다.
01잘 만들어진 공개 사례를 모은다
웹페이지로 공개된 것도 있고, Figma로 공개해 둔 디자인 시스템도 있습니다. 접근할 수 있는 공개 자료를 대상으로 삼습니다.
02그쪽이 어떤 의사결정을 했는지 함께 정리한다
모양만 모으지 않고, 왜 그렇게 정했는지를 같이 정리합니다. ③절에서 이미지에 판단 근거를 붙인 것과 같은 작업입니다.
03지금 쓰는 것과 비교한다
정리한 사례와 현재 쓰고 있는 디자인 시스템을 나란히 놓고 비교합니다. 어디가 다른지, 왜 다른지가 이때 나옵니다.
04감이 아니라 근거로 결정한다
진행자 표현으로는 “감으로 하지 않고 의사결정할 수 있는 것들을 다 가지고 한다”입니다. 결정할 항목이 생길 때마다 정리해 둔 자료를 꺼내 함께 결정합니다.
디자인 시스템을 다시 만들자는 이야기가 나온 배경에는 초기 의사결정과 기술 부채 대화가 있었습니다. 한 참가자의 정리는 이렇습니다.
“초기에 잘못된 의사결정을 한 게 이렇게까지 부채가 돼서 돌아오는구나 싶어요. 그리고 그것 때문에 쓰는 쪽에서도 불편해하고 어려워하고.”
1교시 · 참가자
구체적으로 나온 증상은 UI를 하나 바꾸려 해도 반영하지 못하는 상태였습니다. 새로 만들어 둔 것이 있어도 기존 구조와 맞지 않아 적용이 되지 않는다는 이야기였습니다.
같은 대화에서 나온 다른 참가자의 정리입니다. 내가 잘 아는 분야라고 해서 그것이 정답이라고 생각하는 것이 위험하다는 것입니다. 그렇게 되면 기존 레퍼런스를 무시하게 되는데, 남들이 그렇게 만든 데에도 이유가 있습니다. 그 이유를 확인하지 않고 “디자인이 별로다”로 끝내면, 판단 근거는 하나도 늘지 않습니다.
⑦한 단계 더 생각한 사람만 여기까지 온다
진행자가 시연 끝에 가장 오래 말한 것은 방법이 아니라 발상이었습니다.
“이걸 준다고 해서, 누가 이걸 다 가져와서 의사결정한 다음에 그걸 만든다고 생각을 하겠어요. 한 단계 더 생각해 보면 될 수 있는 것들이 있어요.”
1교시 · 진행자
그리고 한 번 보면 달라진다고 했습니다.
“이게 되는구나를 봤잖아요. 그럼 자기도 사고가 열리는 거거든요. 이런 걸 모아 놨을 때 자료를 어떻게 가공했어야 되는가, 그런 시야가 보이는 게 중요해요.”
1교시 · 진행자
같은 맥락에서 나온 말이 “한계가 있다고 생각하지 말고 좀 더 물어보면 그런 게 나온다”입니다. 이 태도는 대체하기 힘든 것에서 같은 회차의 다른 대목과 함께 다룹니다.
1교시에서 이 시연이 진행된 순서
“의사결정을 해 줄 수 있는 시스템을 만든다”는 계획 설명
국내·해외 UI 레퍼런스 자료를 화면에 띄우고 “뭘 할 수 있을까요” 질문
참가자 답 “참고” → “이미지만 있으면 레퍼런스 참고밖에 안 된다”
이미지마다 구조·레이아웃과 그 이유를 붙여 둔다는 설명
받아 오고 화면에서 모으고 VLM으로 다시 정리하는 수집 과정 설명
Obsidian에 위키 형태로 정리해 넣고 있는 화면 공유
디자이너 캡처와의 차이 — 의사결정 데이터가 있는가
초기 의사결정과 부채 대화, 이어서 디자인 시스템을 다시 만들 때의 응용
“한 단계 더 생각해 보면 된다 · 보면 사고가 열린다” 정리
⑧내 업무로 옮겨 본다면
시연은 UI 레퍼런스였지만, 확인할 것은 업무 종류와 상관없이 같습니다. 지금 모아 둔 자료에 판단 근거가 붙어 있는지만 보면 됩니다.
확인 01
지금 무엇을 모아 두었나
캡처 폴더, 북마크, 참고 문서처럼 이미 모아 둔 것을 먼저 찾습니다. 대부분 자료 자체는 있습니다.
확인 02
붙어 있는 게 분류뿐인가
파일 이름과 폴더 분류만 있다면 ②절의 상태입니다. 왜 이렇게 만들었는지가 어디에도 적혀 있지 않은 것입니다.
확인 03
한 건에 근거를 적어 본다
한 건을 골라 구조·이유·쓸 만한 지점을 몇 줄로 적습니다. 그 상태로 검색해서 결정에 쓸 수 있는지 확인합니다.
이 방식이 자기 업무에서 되는지 확인하는 기준도 하나입니다. 그 자료를 근거로 결정을 내리고, 왜 그렇게 정했는지 설명할 수 있는가. 설명이 되면 판단 근거가 붙은 것이고, 안 되면 아직 참고 자료입니다.
1교시 시연에서 “이미지만 가지고 있으면” 어떤 한계가 있다고 말했습니까?
해설 — 진행자는 “이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 된다”고 말했고, 사진만 있으면 AI가 검색해도 그 화면이 왜 그 구조인지 판단하지 못한다고 이어서 설명했습니다. 그래서 이미지마다 판단 근거를 함께 적어 두는 작업이 필요합니다.
이 문서는 4주차 1교시 후반(01:23~01:50)의 시연 부분만 다룹니다. 같은 교시의 앞뒤 순서는 1교시 강의기록에 있고, “한계를 긋지 않는다”는 태도는 대체하기 힘든 것에서 이어집니다.
{"about":"ax 스터디 — 자율 실습 템플릿 이 템플릿은 수업을 각자 자기 손으로 교안 대시보드까지 만들어 보는 실습 꾸러미 입니다. 수업 녹음을 글로 옮기고(전사), 그 전사를 근거로 교안을 집필하고, 빌드해서 지금 보고 있는 것과 같은 단일 html 대시보드를 만드는 것까지가 한 바퀴입니다. 3주차로 시작해 4주차(마지막 회차)까지 같은 방식으로 만들었습니다. 왼쪽 위 3주 / 4주 버튼으로 회차를 바꿔 볼 수 있습니다. 개발 경험이 없어도 괜찮습니다. 직접 코드를 짜는 게 아니라 내 claude code에게 무엇을 만들지 설명하고, 결과를 검수하는 일 이 실습의 본체입니다. 이 템플릿으로 하는 일 수업 녹음 → 전사 텍스트 → 교안 파셜 집필 → 빌드 한 줄로 index.html 생성 → 진행자에게 전달. 완성본은 진행자가 아카이브에 게시합니다. 한눈에 지금 이 화면이 여러분이 만들 결과물 입니다. 처음 받았을 때 왼쪽 메뉴에는 개요 와 3주차 개요 두 칸밖에 없었습니다. 전사를 넣고 교안을 한 편씩 쓸 때마다 메뉴가 한 줄씩 늘어나고, 마지막에 index.html 하나로 합쳐집니다. 편집하는 것은 언제나 원본 파셜이고, index.html 은 빌드로만 만듭니다. ① 다섯 단계 흐름 순서대로 한 칸씩만 진행하면 됩니다. 앞 단계의 산출물이 다음 단계의 입력이 됩니다. 입력 수업 녹음 파일 — 내 기기로 녹음한 수업 → 중간 산출물 전사 텍스트 와 그것을 근거로 쓴 교안 파셜 html → 최종 산출물 빌드로 합쳐진 index.html — 자기완결 단일 페이지 1단계 녹음 — 수업을 소리로 남긴다 수업을 녹음합니다. 파일은 회차 폴더의 audio/ (예: week4/audio/ ) 에 두면 정리가 쉽습니다. 녹음이 없으면 다음 단계로 넘어갈 재료가 없으니, 이 단계가 사실상 전부의 출발점 입니다. 2단계 전사 — 소리를 글로 옮긴다 가장 간단한 길은 clova note 같은 전사 서비스에 녹음을 올리고, 나온 텍스트를 회차 폴더의 transcripts/ 에 넣는 것입니다. 원한다면 tools/transcribe.py 로 직접 전사해도 됩니다(화자 분리 포함). 어느 쪽이든 결과는 텍스트 파일 한 개 면 충분합니다. 3단계 집필 — 전사를 교안으로 바꾼다 내 claude code(구독 로그인)에 이 폴더를 열고, 전사를 근거로 교안 파셜 html 을 씁니다. 파셜은 회차 폴더의 docs/ 아래에 주제 하나당 파일 하나 로 만듭니다. 규칙은 docs/문서-제작-가이드.md 에 정리돼 있습니다. 전사에 실제로 있는 내용만 쓰는 것이 원칙입니다. 4단계 빌드 — 파셜을 한 페이지로 합친다 터미널에서 python3 tools/build_dashboard.py 를 실행하면 index.html 이 새로 만들어집니다. 브라우저로 열어 메뉴 이동·모바일 폭·오탈자 를 눈으로 확인합니다.","w3-overview":"3주차 개요 — 이번 주 다섯 단계와 1교시에서 정리한 것 1주차에는 ai로 무엇이 가능한지 경험했고, 2주차에는 그것을 직접 만들어 봤습니다. 3주차는 그 둘을 일상과 업무에 통합 하고, ai가 내놓은 결과를 판단하는 눈 을 기르는 주간입니다. 지금 이 저장소에는 1교시 전사만 들어와 있습니다. 아래 문서 네 개는 1교시 전사를 근거로 쓴 것이고, 2교시 이후는 전사가 아직 없어 비어 있습니다. 3주차 목표 배운 것을 일상·업무에 통합하고, 결과를 판단하는 눈 을 기릅니다. 도착점은 내가 자리에 없어도 작업이 계속 진행되게 만드는 것입니다. 1교시에서 실제로 다룬 것 과제 회고 — 동현 님의 프로덕트 시안과 주리 님의 설명 스크립트·음성을 화면에 띄워 놓고, 결과물보다 만드는 과정 을 되짚고 점수를 매겼습니다. 1주차 세 원칙 재확인 — 기존 방식 내려놓기 · 매일 클로드 코드 쓰기 · 호들갑에 말리지 않기. 그중 \"내려놓기\"가 조직에서 실제로 얼마나 어려운지도 이야기했습니다. 내려놓기와 보는 눈 — 시키고 결과만 받으면 판단력이 떨어진다는 지적, 그리고 판단 기준을 늘리는 방법. 오픈클로 개념과 실습 준비 — 오픈클로 와 클로드 코드의 차이, 봇 여러 개를 운영하는 방식, 크론 스케줄링을 개념 수준으로 소개하고, 마지막에 스터디 아카이브를 내려받아 이번 주 교안을 직접 만드는 실습 으로 넘어갔습니다. ① 1주차 → 2주차 → 3주차 진행자가 3주차를 안내하면서 세 주를 이렇게 정리했습니다. 3주차에는 앞의 두 주에서 경험한 것과 만들어 본 것을 함께 씁니다. 1주차 ai 시대에 무엇을 할 수 있는지 경험한다 → 2주차 내가 실제로 할 수 있는 것을 직접 만들어 본다 → 3주차 일상·업무에 통합 하고, 지금 트렌드에 맞게 보는 눈 을 기른다 전사 1교시 55분 구간에서 진행자가 직접 세 주를 나눠 설명한 내용입니다. ② 이번 주 다섯 단계 — 교안덱에 예고된 순서 수업에서 띄운 교안덱 2장에 이번 주 순서가 다섯 단계로 적혀 있습니다. 1교시는 세 번째 단계까지 진행했고, 네 번째는 개념 설명까지, 다섯 번째는 예고만 했습니다. 파랑 = 1교시에서 실제로 진행한 단계, 회색 = 아직 남은 단계. 아래줄은 교안덱 2장에 적혀 있는 도착점입니다. step 1 과제 회고 1교시에서 진행. 두 사람의 결과물을 화면에 띄워 놓고, 어디서 막혔고 무엇을 다시 시켰는지 순서대로 되짚었습니다. 자세한 내용은 과제 회고 문서에 있습니다. step 2 1주차 되돌아보기 1교시에서 진행. 1주차에 정한 세 원칙(기존 방식 내려놓기 · 매일 클로드 코드 · 호들갑에 말리지 않기)을 참가자에게 다시 물어보고 확인했습니다. 정리한 문서는 내려놓기와 보는 눈 입니다. step 3 내려놓기 · 보는 눈 1교시에서 진행. 기존 방식을 내려놓기가 왜 어려운지, 그리고 ai에게 시키고 결과만 ","w3-lecture1":"3주차 1교시 강의기록 — 2주차 과제 회고에서 3주차 방향까지 2026년 8월 2일 오전 10시 25분에 시작해 2시간 11분 동안 진행한 3주차 1교시입니다. 2주차 과제 두 건을 함께 열어 보며 회고하고, 3주차에 무엇을 하는지 안내한 뒤, 기존 방식을 내려놓는 것과 판단 기준을 늘리는 것까지 다뤘습니다. 이 문서는 말이 오간 시간 순서대로 정리한 기록입니다. 주제별로 정리한 문서는 따로 있습니다. 과제 두 건만 모아 본 1교시 과제 회고 , 내려놓기와 보는 눈만 모아 본 내려놓기와 보는 눈 , 오픈클로·봇 이야기를 모아 본 오픈클로와 에이전트 입니다. 이 기록의 원자료 2026-08-02 3주차 1교시 녹음의 전사 텍스트 한 건 입니다. 사적인 대화, 사내 조직·인물에 관한 이야기, 특정 개인에 대한 평가는 대외 공개 기준에 따라 제외 했습니다. 참가자는 스터디 안에서 부르는 호칭까지만 적었고, 진행자 이름은 적지 않았습니다. 1교시 핵심 시작은 \"내가 무슨 과제를 냈는지 설명해 보라\" 였습니다. 결과부터 말하면 듣는 사람이 이해하지 못하고, 목적 → 그 과정에서 무엇이 있었고 → 그래서 이렇게 해 보기로 했다 순서로 말해야 이해된다는 것을 확인했고, 같은 규칙을 ai에게 요청할 때도 그대로 적용했습니다. 과제 두 건을 함께 열어 봤습니다. 동현 님의 부모님 음식점 홍보 웹사이트 시안은 9.5점 , 주리 님의 리뷰 설명 준비 스킬은 9점 으로 평가됐습니다. 두 건 모두 지적 사항은 같았습니다 — 만들어진 결과물을 끝까지 열어 보지 않았거나, 듣는 사람에게 결과물을 먼저 보여 주지 않았다는 것입니다. 3주차 목표는 내가 자리에 없을 때도 작업이 진행되게 만드는 것 이고, 그 앞에 두 가지가 필요하다고 정리했습니다. 기존 방식을 내려놓는 것, 그리고 결과를 받고 끝내지 않고 판단 기준을 늘리는 것입니다. 2시간 11분이 어떤 순서로 진행됐는지 먼저 한 장으로 보겠습니다. 각 구간의 가로 폭이 실제 소요 시간입니다. 파랑으로 표시한 ⑥⑦은 교안덱 step 3(내려놓기 · 보는 눈)에 해당하는 구간입니다. 덱이 이번 주 메인으로 적은 것은 에이전트(step 4)입니다. ⑤가 48분으로 가장 길지만 점선으로 표시한 이유는, 이 구간이 사내 조직·인물 이야기라 대부분 제외했기 때문입니다( 아래 ⑤ 참고 ). ① 과제를 어떻게 설명하는가 (00:00–00:09) 수업은 과제 결과를 보는 것으로 시작하지 않았습니다. 진행자가 두 참가자에게 \"내가 무슨 과제를 냈는지, 주리 님도 이해할 수 있게 설명해 보라\" 고 하고 생각할 시간 1분을 준 것이 첫 장면입니다. 동현 님이 먼저 답했습니다. \"피그마 mcp를 연결해서 원하는 사이트를 만들어 보아라\", \"ui 레퍼런스도 활용하고 레퍼런스를 잘 모으라\" 같은 지시 내용 위주 였습니다. 진행자는 여기서 말하는 순서를 정정했습니","w3-practice1":"1교시 과제 회고 — 두 결과물을 만든 방법과 받은 피드백 3주차 1교시는 2주차 과제 2건을 화면에 띄워 놓고 같이 보는 것으로 시작했습니다. 동현 님은 부모님 음식점 홍보 웹사이트 를, 주리 님은 리뷰 설명을 준비하는 스킬 을 만들어 왔습니다. 이 문서는 두 결과물을 어떤 순서로 만들었고, 무엇이 효과가 있었고, 어디서 지적을 받았는지 로 다시 정리한 것입니다. 시간순 기록은 1교시 강의기록 에 있습니다. 이 시간의 초점 교안덱 3장은 과제 회고를 “결과가 아니라 과정” 으로 적어 두고, 확인할 것을 세 가지로 나눴습니다. 어디서 막혔나 · 무엇을 내려놓았나 · 다음엔 무엇을 바꾸나. 그래서 이 자리에서 오간 말은 대부분 그 결과가 나오기까지 무엇을 어떻게 시켰는지 에 대한 질문이었습니다. 두 과제 한눈에 과제 ① 부모님 음식점 홍보 웹사이트(동현 님) — 2주차까지 배운 mcp · 레퍼런스 활용 · codex cli 이미지를 한 작업에 함께 쓰고, figma mcp로 시안을 만든 뒤 html 사이트까지 확장했습니다. 평가 10점 만점에 9.5점 . 과제 ② 리뷰 설명을 준비하는 스킬(주리 님) — 목업·기획 문서와 지난 리뷰 전사를 넣으면 설명 대본과 tts 음성, 확인용 화면이 나오는 이지 익스플레인 스킬 을 만들었습니다. 평가 10점 만점에 9점 . 두 과제에서 반복해서 나온 지적은 하나였습니다. 맥락을 얼마나 빼고 시켰는가, 그리고 나온 결과물을 끝까지 확인했는가. ① 과제를 설명하는 순서 — 목적 → 과정 → 결과 수업은 두 사람이 각자 “이번 과제가 무엇이었는지”를 먼저 설명하는 순서로 진행했습니다. 진행자는 설명이 짧게 끝나자 바로 순서를 정정했습니다. “목적이 무엇이었고, 그 과정에서 뭐가 있었고, 그래서 이렇게 한번 해 보기로 했습니다 — 이렇게 얘기하는 게 정석입니다.” 진행자 · 1교시 도입부 ① 목적 무엇을 위해 하는 작업인가. 과제 ①은 부모님 가게 홍보용 사이트, 과제 ②는 팀 리뷰에서 할 설명 준비였습니다. → ② 그 과정에서 있었던 것 무엇을 시도했고 어디서 막혔는가. 첫 결과가 기대와 달랐던 지점, 맥락을 다시 넣어야 했던 지점을 말합니다. → ③ 그래서 이렇게 해 봤다 그래서 실제로 만든 결과물. 시안·사이트·스킬처럼 열어서 보여 줄 수 있는 것입니다. 이 순서를 지켜야 하는 이유는 사람에게 설명할 때나 ai에게 지시할 때나 같습니다. 배경을 빼고 요구만 말하면 듣는 쪽이 무엇을 원하는지 알 수 없습니다. “맥락 쏙 다 빼놓고 그렇게 설명하면, 내가 뭘 바라는 목적을 가지고 있고 뭘 만들어 줘야 되는지 잘 모르니까. 모호할수록 결과는 잘 안 나오니까.” 진행자 · 과제 설명 순서를 짚으며 같은 지적이 과제 ①에도 한 번 더 나왔습니다. 동현 님은 페르소나 부여와 점수 기준 같은 방법을 실제로 썼는데 과제 설명에서는 빼놓았고, ","w3-concept-mindset":"내려놓기와 보는 눈 — 에이전트로 넘어가기 전에 정리한 것 3주차 교안덱 표지에 적힌 제목은 “에이전트 — 쥔 것을 놓고, 보는 눈을 기른다” 입니다. 1교시에서 가장 오래 이야기한 주제도 이 두 가지였습니다. 진행자가 1교시에 예고한 순서는 기존 방식을 내려놓는 것 → 보는 눈을 기르는 방법 → 오픈클로·슬랙봇 붙이기 → ai가 잘 찾아가게 만들기 였습니다. 이 문서는 그중 앞의 두 가지를 정리했습니다. 1교시에서 먼저 정리한 것 에이전트를 여러 개 돌리는 방법으로 들어가기 전에, 지금 쓰던 방식을 그만두는 일 과 결과를 받아 들고 판단하는 일 을 먼저 정리했습니다. 도구 설치는 그다음 순서입니다. 이 문서 핵심 내려놓기 는 기존 업무 방식과 도구를 그대로 두고 새 방식을 하나 더 추가하는 상태를 말하지 않습니다. 기존 방식을 그만 쓰고 새 방식으로 바꾼다는 뜻이고, 그래서 실제로는 어렵습니다. 보는 눈 은 결과를 받은 다음에 하는 일입니다. 시키고 받고 끝내면 두세 달 뒤에 스스로 판단하지 않게 되고, 왜 그렇게 됐는지 묻고 다음 스텝을 정하면 판단 기준이 하나씩 늘어납니다. 둘을 합치면 3주차 목표가 됩니다. 여러 개를 병렬로 시켜 놓되, 하려는 것은 내가 명확하게 안다. ① 1주차 세 원칙 다시 보기 1교시 중반에 진행자가 “1주차에 세 가지 중요하다고 했죠”라고 물었습니다. 참가자가 먼저 꺼낸 것은 호들갑에 휘둘리지 않는다 였고, 진행자가 내려놓는다 와 매일 쓴다 를 이어서 확인했습니다. 참가자는 마지막을 “하는 걸 믿고 일단 해본다”로 정리했습니다. 원칙 01 기존 방식 내려놓기 교안덱 4장 문구는 “업무 방식은 일단 내려놓는다” 입니다. 전사에서는 진행자가 “다 내려놓고”로 첫 번째 원칙을 확인했습니다. 원칙 02 매일 클로드 코드 교안덱 문구는 “업무 시작 = 터미널, 클로드 코드부터” 입니다. 전사에서는 “매일매일 이거 쓰고”로 확인했습니다. 원칙 03 호들갑에 말리지 않기 교안덱 문구는 “호들갑 떨지 않고 중심을 잡는다” 입니다. 참가자가 세 원칙 중 가장 먼저 떠올린 항목이 이것이었습니다. “에이전트를 여러 개 돌리려면, 손이 먼저 비어 있어야 한다” 교안덱 4장 — 3주차에 세 원칙을 다시 꺼낸 이유 실제로 하는 일로 옮기면 이렇습니다. 에이전트 여러 개에 일을 나눠 맡기려면, 지금 사람이 직접 하고 있는 작업을 먼저 그만두어야 합니다. 그 작업을 사람이 계속 하고 있으면 에이전트에게 넘길 일이 남지 않습니다. ② “내려놓는다”가 실제로 뜻하는 것 1교시에서 진행자는 “내려놓는다”를 두 가지 예로 설명했습니다. “내가 음료수 하나를 들고 있잖아요. 들고 있으면 여기서 하나 더 쥐기 쉽지 않잖아요. 그래서 이걸 내려놔야 다른 걸 쥘 수 있는 거예요.” 1교시 · 진행자가 손에 든 음료를 들어 보이며 (제품명은 일반 표현으로 바꿨습니다) 실무로","w3-agents":"오픈클로와 에이전트 — 이번 주에 무엇이 달라지는가 1교시 후반부에서 진행자는 이번 주에 할 것을 먼저 한 번 다 설명 했습니다. 1주차에는 ai 시대에 무엇을 할 수 있는지 경험했고, 2주차에는 내가 실제로 할 수 있는 것을 직접 해 봤고, 3주차에는 그것을 업무와 일상에 어떻게 더 잘 활용할지에 초점을 맞춥니다. 그 중심에 오픈클로 와 에이전트 가 있습니다. 지금까지는 터미널이나 웹 화면 앞에 앉아 있어야 claude code 에 일을 시킬 수 있었는데, 오픈클로를 붙이면 슬랙·디스코드 챗 창에서 같은 작업을 시킬 수 있습니다. 1교시에서 예고한 것 이번 주 메인 주제는 에이전트 입니다. 오픈클로로 봇을 만들어 챗 창에서 부르고, 봇을 여러 개 두어 서로 논의하게 하고, 주기적으로 반복하는 스케줄링을 걸어 내가 자리에 없을 때도 작업이 진행되게 만드는 것까지가 이번 주의 범위입니다. 한 문단 정리 claude code 가 실제로 일을 하는 엔진 입니다. 오픈클로는 챗 창에서 받은 말을 claude code 에 전달하고, claude code 가 만든 결과를 다시 챗 창에 답으로 보냅니다. 그래서 하는 일 자체는 같고, 달라지는 것은 부르는 자리입니다. 봇은 원하는 만큼 만들 수 있고 각 봇에 역할을 지정할 수 있습니다. 여러 봇이 서로 논의하고 평가하면서 결과를 만드는 구조를 에이전트 그래프 라고 부릅니다. 주기적으로 반복하는 스케줄링(크론)을 걸어 두면 아침마다 정해진 일을 하게 만들 수 있습니다. 다만 오래 실행되는 작업은 중간에 들어가 확인하고 승인해 줘야 끝까지 진행됩니다. 1교시에서는 오픈클로가 무엇이고 왜 쓰는지까지 만 이야기했습니다. 설치와 슬랙봇 연결은 이어지는 실습 입니다. 이 문서에서 전사가 아니라 수업에서 띄운 교안덱 슬라이드를 근거로 한 대목은 “교안덱 예고” 라고 표시했습니다. ① claude code 와 오픈클로는 무엇이 다른가 참가자 질문이 그대로 나왔습니다. “오픈클로랑 claude code 랑 뭐가 다른가요.” 설치까지 해 봤는데도 아직 헷갈린다는 말이 이어졌습니다. “claude code 가 엔진이고, 그 겉에서 장치 역할을 하는, 봇의 역할을 다 해 주는 게 오픈클로입니다. 그래서 봇한테 아침마다 뭐 해 달라고 해 두면 알아서 자동으로 다 해 줍니다.” 진행자 — 1교시, 두 도구의 차이를 묻는 질문에 실행은 claude code 가 합니다. 오픈클로는 그 실행을 챗 창에서 부를 수 있게 하고, 정해 둔 시간에 claude code 를 자동으로 실행시킵니다. 항목 claude code 오픈클로 어디서 부르나 터미널·웹 화면 앞에서 직접 슬랙·디스코드 같은 챗 창에서 (교안덱 7장) 무엇을 하나 실제로 일을 하는 엔진 챗 창의 말을 claude code 에 전달하고 결과를 답으로 보낸다 몇 개를 두나 세션마다 창을 열어서 쓴다","w4-overview":"4주차 개요 — 마지막 회차에서 정리한 것 4주차는 마지막 회차 입니다. 새 도구를 하나 더 배우는 자리가 아니라, 한 달 동안 무엇이 바뀌었는지 확인하고 다음 달에도 계속할 수 있는 절차와 태도 를 정리하는 자리였습니다. 진행자는 회차 초반에 이번 시간을 \"1주차에 던져 둔 것을 회수하는 시간\" 이라고 말했습니다. 그래서 1주차에 정한 세 가지 원칙을 다시 확인하는 것으로 시작합니다. 이 저장소에는 1교시 전사만 들어와 있습니다. 아래 문서 일곱 개는 모두 1교시(2시간 14분) 전사를 근거로 썼습니다. 4주차에 다룬 것 한 달 동안 실제로 만든 결과물을 확인하고, ai가 대체하기 힘든 것 이 무엇인지 정리하고, 혼자 일할 때와 함께 일할 때의 태도 를 이야기했습니다. 1교시에서 실제로 다룬 것 1주차 세 가지 원칙 재확인 — 내려놓는다 · 매일 claude code를 쓴다 · 이해가 안 돼도 일단 따라 한다. 이어서 21일이라는 기간이 왜 중요한지 설명했습니다. 한 달 회고 — 참가자가 한 달 동안 업무에 ai를 써서 만든 결과물을 화면에 띄워 놓고, 어떻게 만들었고 어떤 피드백을 받았는지 되짚었습니다. 프롬프트 기법 — 마크다운의 코드블록과 제목으로 명령과 데이터를 나누는 방법. ai가 대체하기 힘든 것 — 사람과 사람이 만나서 하는 일, 방향 설정과 책임, 마음을 얻는 일, 육감. 태도 — 스스로 한계를 긋지 않는 것, 그리고 함께 일할 때의 신뢰·배려·개방. 레퍼런스를 판단 근거까지 모으기 — 진행자가 실제로 작업 중인 화면을 띄워 놓고 방식을 설명했습니다. ① 1주차 → 4주차 3주차까지는 무엇을 할 수 있는지 경험하고, 직접 만들고, 업무에 통합하는 순서였습니다. 마지막 회차는 그 한 달을 확인하고 이어 갈 방법을 정하는 자리였습니다. 1주차 ai로 무엇을 할 수 있는지 경험한다 → 2주차 할 수 있는 것을 직접 만들어 본다 → 3주차 일상·업무에 통합 하고 판단하는 눈을 기른다 → 4주차 한 달을 확인하고 계속할 방법과 태도 를 정리한다 1~3주차 구분은 3주차에 진행자가 직접 나눠 설명한 내용이고, 4주차 항목은 이번 회차 전사에서 정리한 것입니다. ② 이번 회차 주제 지도 2시간 14분에서 나온 이야기를 성격에 따라 셋으로 나눴습니다. 되돌아보기 는 한 달을 확인하는 부분, 방법 은 바로 따라 할 수 있는 작업 방식, 태도 는 도구와 무관하게 남는 부분입니다. 회색 = 이번 회차에서 다룬 세 갈래, 파랑 = 진행자가 마지막에 정리한 도착점입니다. ③ 교시별 정리 상태 지금 어디까지 정리됐는지만 표로 적었습니다. 4주차는 1교시 하나로 진행됐습니다. 교시 다룬 것 정리한 문서 상태 1교시 세 가지 원칙과 21일 · 한 달 회고 · 마크다운 프롬프트 · 대체하기 힘든 것 · 팀과 협업 태도 · 레퍼런스 모으기 강의기록 외 6편 정리 완료 원자료는 ","w4-lecture1":"1교시 강의기록 — 마지막 회차에서 오간 이야기 4주차는 이 스터디의 마지막 회차입니다. 1교시는 2시간 14분 동안 이어졌고, 진행자 1명과 참가자 2명이 참여했습니다. 다른 문서가 주제별로 정리한 것과 달리, 이 문서는 세션이 어떤 순서로 진행됐는지 를 시간 순으로 적었습니다. 각 항목에 녹음 구간을 함께 표시했습니다. 이 회차의 성격 새 도구를 설치하는 시간이 아니라, 한 달 동안 무엇이 달라졌는지 확인하고 태도를 정리하는 시간 이었습니다. 각자 이번 주에 ai를 어떻게 썼는지 공유하고, 만든 결과물을 화면에 띄워 놓고 피드백을 주고받았습니다. 한 회차 요약 앞부분은 한 달을 되돌아보는 시간 이었습니다. 1주차에 정한 세 원칙을 다시 확인하고, 팀원들과 1:1로 대화해 본 회고와 이번 주 ai 활용 사례를 나눴습니다. 가운데는 결과물을 놓고 하는 피드백 이었습니다. 실제로 만든 하반기 전략 보고서를 함께 보면서, 잘된 점과 고칠 점을 화면을 가리키며 짚었습니다. 뒷부분은 태도 였습니다. 스스로 한계를 긋지 않는 것, 팀의 직무 경계가 줄어드는 것, 신뢰와 배려와 개방, ai가 대체하기 힘든 것, 그리고 리소스를 어디에 쓸지 정하려면 무엇을 그만둘지부터 정해야 한다 는 이야기로 마무리했습니다. ① 세션 순서 한눈에 보기 아래 표가 1교시 전체 순서입니다. 시간 표시는 녹음 기준이고, 주제가 서로 이어지는 구간은 시간이 겹칩니다. 구간 주제 한 줄 요약 00:05 ~ 00:10 마지막 회차의 시작 1주차에 정한 세 가지 원칙을 다시 확인했습니다. 00:10 ~ 00:23 한 달을 돌아보며 팀원들과 1:1로 대화해 본 회고와 그에 대한 피드백입니다. 00:22 ~ 00:34 이번 주에 ai를 어떻게 썼나 자동화, 문서 작성, 전략 보고서 사례를 각자 공유했습니다. 00:27 ~ 00:30 마크다운 기법 명령과 자료를 나눠서 적는 방법을 설명했습니다. 00:30 ~ 00:40 알아듣게 되는 변화 전에는 이해하지 못하던 기술 설명이 들리기 시작한 경험입니다. 00:41 ~ 00:53 전략 보고서 피드백 실제로 만든 보고서를 화면에 띄워 놓고 함께 봤습니다. 00:53 ~ 01:01 스스로 한계를 긋지 않기 태도에 관한 첫 번째 주제입니다. 00:54 ~ 01:02 팀의 직무 경계가 줄어든다 직무별로 나뉘어 있던 경계에 대한 이야기입니다. 01:02 ~ 01:13 신뢰 · 배려 · 개방 함께 일할 때 필요한 태도를 순서대로 정리했습니다. 01:13 ~ 01:15 ai가 대체하기 힘든 것 방향 설정, 책임, 사람의 마음 세 가지를 꼽았습니다. 01:23 ~ 01:50 레퍼런스를 판단 근거까지 정리 하반기에 하려는 작업을 화면으로 보여 주며 설명했습니다. 01:50 ~ 01:57 조직에서 ax가 잘 안 되는 이유 개인이 부딪히는 것과 조직이 해야 하는 것을 짚었습니다. ","w4-concept-habit":"세 가지 원칙과 21일 4주차는 마지막 회차입니다. 1교시 앞부분에서 진행자가 먼저 물은 것은 “마지막 주차니까, 1주차에 꼭 지켜야 한다고 한 세 가지가 뭐였죠?” 였습니다. 세 가지를 확인한 다음, 한 달 동안 실제로 어땠는지를 이야기하고, 왜 3주(21일)를 매일 반복해야 하는지 를 설명했습니다. 이 문서는 1교시 앞부분(전사 05:41~09:51)을 정리한 것입니다. 마지막 회차를 여는 순서 진행자는 마지막 회차를 1주차에 정한 세 가지 원칙을 다시 확인하는 것 부터 시작했습니다. 세 가지를 확인한 다음에 그날 주제로 넘어갔습니다. 이 문서 핵심 1주차에 정한 세 가지는 ① 내려놓는다 ② 매일 claude code를 쓴다 ③ 이해가 안 돼도 일단 따라 한다 입니다. 21일에서 중요한 것은 날짜가 아니라 반복한 횟수 입니다. 진행자가 나눈 두 가지 방향 중 습관이 되는 쪽은 계획과 절차를 먼저 정해 두고 3주 동안 매일 그대로 반복하는 쪽 입니다. 사고는 그 반복의 결과로 바뀝니다. 3주를 매일 반복하면 인식이 바뀌고, 그다음에는 3개월, 그다음에는 3년 동안 할 수 있다는 것이 진행자의 설명이었습니다. ① 세 가지 원칙 — 마지막 회차에서 다시 확인 세 가지는 진행자와 참가자가 번갈아 말하면서 확인했습니다. 참가자가 먼저 “내려놓는다”라고 답했고, 세 번째를 “받아들인다였나?”로 되묻자 진행자가 “이해가 안 돼도 일단 따라 한다”로 정정했습니다. 두 번째는 진행자가 “생각이 안 난다”고 하자 참가자가 “매일 claude code”라고 답했습니다. 원칙 01 내려놓는다 전사에서 진행자가 확인한 문장은 “내려놓고 일단 시키는 대로 한다” 입니다. 마지막에 다시 한 번 “첫 번째가 뭐였죠?”로 되짚었습니다. 원칙 02 매일 claude code를 쓴다 참가자가 “매일 claude code” 로 답했고, 진행자가 “매일 하자는 거” 라고 확인했습니다. 뒤에서 “매일 아침에 claude code로 해라” 로 다시 나옵니다. 원칙 03 이해가 안 돼도 일단 따라 한다 진행자 표현 그대로 “세 번째가 이해가 안 돼도 일단 따라한다” 입니다. 마지막 정리에서도 “이해가 되든 안 되든 간에” 로 반복했습니다. 원칙 1교시에서 나온 표현 먼저 말한 사람 ① 내려놓는다 “내려놓고 일단 시키는 대로 한다” 참가자가 먼저 답하고 진행자가 확인 ② 매일 claude code “매일 하자는 거” 진행자가 기억하지 못하자 참가자가 답함 ③ 이해가 안 돼도 따라 한다 “이해가 안 돼도 일단 따라한다” 참가자의 다른 답을 진행자가 정정 세 가지를 확인하는 데 대화가 여러 번 오갔습니다. 두 번째 원칙은 진행자가 “생각이 안 난다”고 했고, 참가자가 대신 답했습니다. ② 한 달 동안 하루도 빼먹지 않았다 두 번째 원칙을 확인한 자리에서 “매일 하셨나요?”라는 질문이 나왔습니다. 답은 이랬","w4-practice1":"한 달 회고 — 업무 결과물로 만들어 본 것 4주차 1교시 앞부분에서 진행자가 “이번 주에 ai를 써서 잘 활용해 본 것이 있느냐” 고 물었고, 참가자 두 명이 이번 주 실제 업무에서 만든 결과물을 하나씩 이야기했습니다. 나온 것은 세 가지입니다. 개인 에이전트에 맡긴 자동화, 지원 사업 신청 서류, 하반기 전략 보고서입니다. 이 중 전략 보고서 이야기가 가장 길었고, 경영진 보고와 그 자리에서 받은 피드백까지 다뤘습니다. (근거: 4주차 1교시 전사 22:55~53:02 ) 이 회차에서 확인한 것 예전에는 한 줄씩 지시하는 방식 이었고, 지금은 배경을 길게 적어 한 번에 맡기는 방식 으로 바뀌었습니다. 그 결과물로 실제 서류를 제출했고, 발표 자료를 만들어 경영진에게 보고했습니다. 이 문서 핵심 자동화는 사람이 매번 지시하지 않아도 되는 일 부터 맡겼습니다. 아티클 요약, 전날 작업 기록 점검, 업무일지 생성입니다. 프롬프트 쓰는 법은 메인 에이전트가 하위 에이전트에게 보낸 프롬프트를 직접 보면서 익혔습니다. 평소 가장 싫어하던 슬라이드 작업은 처음으로 에세이처럼 길게 배경을 써서 맡겼고, 컨텍스트를 두 번 compact 할 만큼 긴 세션이 됐습니다. 진행자의 결론은 한 줄입니다. 예쁘게 만드는 것이 목적이 아니라, 보는 사람에게 잘 전달되면 됩니다. ① 개인 에이전트에 맡긴 자동화 세 가지 한 참가자는 이 세션을 하면서 개인 에이전트가 많이 개선돼, 사람이 매번 지시하지 않아도 되는 일을 여러 개 맡겼다고 말했습니다. 자동화 01 아티클을 먼저 받아 정리 에이전트가 아티클을 먼저 보내 줍니다. 요약과 함께 업무와 연결되는 부분의 인사이트 까지 정리해 전달합니다. 자동화 02 다음 날 아침 개선점 그날 진행한 claude code 세션 기록을 읽고 , 다음 날 아침에 개선하면 좋을 점과 프롬프트를 이렇게 쓰면 좋겠다는 제안을 전달합니다. 자동화 03 업무일지 생성 예전에는 스킬을 써서 마크다운 파일이 만들어지게 해 두는 정도였습니다. 지금은 에이전트가 업무일지까지 만듭니다. 지시하는 방식도 함께 바뀌었습니다. 예전에는 “한 줄 이렇게 해 줘”를 반복했고, 지금은 길게 쓰는 쪽 으로 늘었다는 것이 참가자 표현입니다. ② 하위 에이전트에게 보낸 프롬프트를 직접 봤다 서브에이전트 나 병렬 에이전트에 일을 시키면, 메인 claude code가 하위 에이전트에게 어떤 프롬프트를 보냈는지 화면에서 볼 수 있습니다. 참가자는 그 프롬프트가 진행자가 쓰는 방식과 거의 같았다 고 말했습니다. “서브에이전트나 병렬 에이전트를 시키면 메인 claude code가 걔네한테 프롬프트를 어떻게 쳤는지도 볼 수 있어요. 근데 그게 진행자가 치는 거랑 거의 비슷해요. 길게 맥락 설명하고 뭐가 필요하고 이렇게 하는 거. 그런 것도 이 세션 하면서 배우고, 아 이렇게 치는구나 하고 봤습니다.","w4-prompt-markdown":"마크다운으로 명령과 데이터를 나눈다 프롬프트를 한 줄로 이어서 적으면 어디까지가 내가 시키는 말이고 어디부터가 붙여넣은 자료인지 표시가 남지 않습니다. 1교시에서 진행자가 설명한 방법은 마크다운 기호 두 개 로 그 경계를 표시하는 것이었습니다. 기호는 두 가지입니다. 백틱 세 개로 감싸는 코드블록 과, 샵으로 시작하는 제목 입니다. 이 대화가 나온 자리 한 참가자가 백틱으로 묶는 것과 샵으로 끊는 것이 무슨 차이냐 고 물으면서 시작된 대화입니다. 진행자가 두 기호가 각각 무엇을 표시하는지 답했고, 백틱을 키보드에서 어떻게 입력하는지까지 이어졌습니다. 이 문서 핵심 마크다운 파일의 제목 구조는 ai가 이해하기 좋은 방식 입니다. 제목이 있으면 순서가 들어가고 구분 지점이 생깁니다. 코드블록 은 “이 영역은 스크립트나 코드처럼 그대로 복사해 온 원본 데이터다”를 표시합니다. 제목 은 영역을 끊어서 위쪽은 넣은 데이터, 아래쪽은 내가 설명하는 내용이라고 나눕니다. 나누는 이유는 하나입니다. 내가 내리는 명령과 그 안에 들어가는 데이터가 섞이면 명확하지 않습니다. ai가 어느 정도는 알아서 구분하겠지만, 섞여 있으면 정확도가 떨어집니다. ① 에이전트가 만드는 마크다운 파일도 같은 구조다 이 이야기는 한 참가자의 실습 경험에서 시작됐습니다. 서브에이전트·병렬 에이전트 에 일을 시키면 메인 claude code가 그 에이전트들에게 어떤 프롬프트를 썼는지 화면에서 볼 수 있는데, 그 방식이 진행자가 직접 쓰는 것과 거의 같았다는 것입니다. 맥락을 길게 설명하고 무엇이 필요한지 적는 방식입니다. 진행자는 1년 전 화면과 비교했습니다. 그때는 claude가 작업을 하나씩 하면서 스스로 프롬프트를 쓰는 과정이 그대로 보였고, 개발팀에서도 그 화면을 계속 보는 것만으로 실력이 는다고 이야기했다고 합니다. 요즘은 그 과정이 화면에 바로 보이지 않지만, 열어 보면 어떻게 하고 있는지 확인할 수 있습니다. 열어서 확인할 수 있는 것 중 하나가 에이전트가 만드는 마크다운( .md ) 파일의 생김새 입니다. 진행자는 그것을 위계 구조 라고 불렀습니다. ai가 이해를 잘하는 방식으로 에이전트가 스스로 바꿔서 내놓는 것이라는 설명입니다. 제목 샵으로 시작하는 줄 — 무엇에 대한 내용인지 이름을 붙인다 → 순서 제목이 있으니 앞뒤가 생긴다 — 어느 것이 먼저인지 표시된다 → 구분 지점 영역이 끊기는 자리 — 여기까지가 한 영역이라고 표시된다 진행자는 상황에 따라 쓰는 방법이 다르다고 덧붙였습니다. 제목을 붙여 이름을 다는 경우가 있고, 어떤 것은 묶어서 안에 넣는 경우가 있고, 그냥 끊어 줄 것은 끊는 경우가 있습니다. 이런 것을 프롬프트 기법 이라고 불렀습니다. ② 기호 두 개가 각각 표시하는 것 참가자의 질문은 “백틱으로 묶는 것과 샵으로 끊는 것이 무슨 차이냐”였습니다. 진행자의 답을 표로","w4-concept-limits":"ai가 대체하기 힘든 것, 한계를 긋지 않는 태도 4주차는 마지막 회차입니다. 1교시에서 진행자가 다룰 순서를 정리하면서 태도에 관한 두 가지 를 함께 넣었습니다. 하나는 ai가 대체하기 힘든 일이 무엇인가 , 다른 하나는 스스로 한계를 긋지 않는 것 입니다. 앞의 질문은 진행자가 꺼낸 것이 아닙니다. 참가자가 예전에 진행자에게 먼저 물었던 질문이고, 마지막 회차에서 그 답을 다시 정리했습니다. 마지막 회차에서 정리한 두 가지 ai가 대체하기 힘든 일 이 무엇인지 확인하고, 이어서 자기 한계를 미리 정해 두지 않는 태도 를 이야기했습니다. 두 가지 모두 도구 사용법이 아니라 태도에 대한 내용입니다. 이 문서 핵심 1교시에서 대체하기 힘든 것 으로 나온 항목은 다섯 가지입니다. 사람과 사람이 만나서 해야 하는 일, 방향을 설정하는 일, 책임지는 일, 사람의 마음을 얻는 일, 그리고 육감입니다. 같은 1교시에서 태도 로 나온 것은 하나입니다. “이건 안 될 거야”라고 미리 정해 버리면 그다음으로 넘어가기 어렵습니다. 되는 것을 알아야 시도하고, 전문가가 아니어도 몇 차례 물어보면 검증할 수 있습니다. 두 가지를 합치면 이렇게 됩니다. 사람이 계속 맡아야 할 일이 남아 있고, 그 일을 맡으려면 자기가 할 수 있는 범위를 미리 좁혀 두지 않아야 합니다. ① ai가 대체하기 힘든 것 1교시 초반, 진행자가 이번 회차에 다룰 것을 정리하면서 이 주제를 꺼냈습니다. 원래 참가자가 진행자에게 물었던 질문입니다. “ai가 대체하기 힘든 게 어떤 게 있을까요? 그때 제가 뭐라고 했는지 기억나세요?” 1교시 · 진행자가 예전 질문을 다시 꺼내며 참가자가 기억해 낸 답은 “사람과 사람의 커뮤니케이션” 이었습니다. 진행자가 그 답을 받아 정리한 문장은 이렇습니다. “맞아요. 사람과 사람이 만나서 해야 될 것들을 대체하기 힘들다는 거. 그게 중요해요. 업무는 업무대로 할 수 있는데, 대체하기 힘든 것들이 많으니까.” 1교시 · 진행자 업무 자체는 ai로 처리할 수 있다는 것을 전제로 두고, 그래도 대체하기 힘든 것들이 많다고 말한 답입니다. 1교시 끝 무렵에 다시 나온 두 항목 1교시가 끝날 무렵, 진행자가 아직 보여 주지 않은 마지막 장이 있다는 것을 확인하고 그 내용을 읽었습니다. 거기 적혀 있던 것은 두 가지였습니다. “ai가 대체하기 힘든 것. 방향 설정하는 거. 그리고 책임지는 거.” 1교시 · 진행자가 자료 마지막 장을 읽으며 참가자는 여기에 하나를 더 붙였습니다. 아래 세 카드가 이 대화에서 나온 항목입니다. 항목 01 방향을 설정하는 일 자료 마지막 장의 첫 항목입니다. 진행자는 앞서 리더 역할을 설명하면서도 목표를 줄 수 있도록 방향을 설정하고 보완하는 일 이라고 말했습니다. 항목 02 책임지는 일 두 번째 항목입니다. 참가자는 “책임지는 건 자기 역할이고, 책임질 사람","w4-concept-team":"경계가 허물어진 팀, 신뢰·배려·개방 4주차 1교시 중반에 진행자가 “회사는 왜 팀을 만들어 주는가” 를 물었습니다. 그 질문에서 시작해, 팀 안의 역할 구분이 6개월 동안 어떻게 바뀌었는지와 함께 일할 때의 태도까지 이어졌습니다. 앞부분은 팀이라는 단위 가 무엇인지, 뒷부분은 신뢰 → 배려 → 개방 순서로 이어지는 태도입니다. 이 문서는 그 두 부분을 정리했습니다. 이 대목이 나온 자리 진행자가 정리한 전제는 이렇습니다. ai를 잘 쓰는 것만으로 일이 되지는 않고, 사람끼리 일하는 방식이 함께 중요하다. 그래서 도구 이야기 중간에 팀과 태도를 한 번 짚었습니다. 이 문서 핵심 1부 — 팀의 경계. 전통적인 팀은 기획·디자인·개발로 역할이 나뉘어 있습니다. ai를 다루기 전까지 이 구분이 뚜렷했고, 구분 때문에 초반에 갈등이 많았습니다. 약 6개월이 지나 팀 전원이 ai 쓰는 법을 어느 정도 이해하자, 경계가 허물어져도 괜찮겠다 고 받아들이게 됐습니다. 2부 — 함께 일할 때의 태도. 순서가 있습니다. 먼저 신뢰가 생겨야 하고, 그러려면 배려의 기준 이 명확해야 합니다. 상대에게도 자기 업무와 일정이 있으니 요청하기 전에 확인할 것이 있습니다. 일을 넘길 때 그대로 던지지 않고 한 번 더 확인해서 다듬어 전달하면 진정성이 전해집니다. 그다음 단계가 개방입니다. ① 질문 — 회사는 왜 팀을 만들어 주는가 진행자는 팀의 정의를 먼저 말하지 않고 질문부터 했습니다. “원래 팀이라는 게 뭐라고 생각하시나요? 회사에 왜 팀을 이렇게 만들어 줄까?” “혼자서는 안 되니까요. 누구는 이걸 잘하고 누구는 저걸 잘하고, 이걸 못하는 사람은 저걸 잘하니까, 서로 밸런스를 맞추는 거죠.” 1교시 · 한 참가자의 답 같은 참가자가 덧붙인 비교가 있습니다. 에이전트에 각 직무를 맡기는 것과 같다 는 것입니다. 에이전트마다 맡길 일을 나누듯이, 사람도 잘하는 것이 서로 달라서 나눠 맡는다는 이야기입니다. ② 전통적인 구성 — 역할이 나뉘어 있다 진행자가 예로 든 것은 제품을 하나 만드는 팀입니다. 기획자가 있고, 디자이너가 있고, 개발자가 있습니다. 전체를 총괄하는 pm은 설명에서 뺐습니다. 각각 맡은 역할이 있고, 그렇게 한 팀을 만듭니다. 다른 조직도 같은 구조라고 봤습니다. 영업 팀이 있고 마케팅 팀이 있습니다. 마케터가 전략을 정하고, 영업에서 그에 맞춰 고객과 만나 실행합니다. 진행자는 마케터가 하는 이 역할은 아직 기술이 잘 해내지 못하는 편 이라고 덧붙였습니다. ③ 6개월 — 경계가 허물어져도 괜찮겠다 진행자가 자기 팀을 예로 들었습니다. ai를 잘 다루기 전까지는 이 역할 구분이 매우 뚜렷했고, 그 구분 때문에 팀원들이 초반에 힘들었을 것이라고 봤습니다. 안에서 갈등도 많았고, 오해를 바로잡는 데 진행자 본인도 시간을 많이 썼다고 말했습니다. 시점 팀 안에서 있었던 일 역","w4-practice-refs":"레퍼런스를 판단 근거까지 모으기 1교시 후반(전사 01:23~01:50 구간)에 진행자가 화면을 공유하며 시연한 작업 방식입니다. 시작은 질문 하나였습니다. “ui 레퍼런스를 이만큼 가지고 있으면, 무엇을 할 수 있을까요.” 이 문서는 어떤 자료를 어디서 가져왔는지가 아니라, 전문성이 없는 사람이 어떻게 의사결정을 할 수 있게 되는가 만 정리했습니다. 시연에서 확인한 것 이미지만 저장해 두면 참고 자료에서 끝납니다 . 이미지마다 “이 화면은 왜 이 구조인가, 레이아웃을 왜 이렇게 짰는가”를 함께 적어 두면, 그때부터 의사결정에 쓸 수 있는 자료 가 됩니다. 이 문서 핵심 같은 이미지를 모아도 결과가 달라지는 조건은 하나입니다. 판단 근거를 함께 적어 두었는가. 카테고리만 붙여 둔 자료는 ai가 검색해도 판단하지 못합니다. 왜 이 구조인지가 함께 적혀 있으면, 서비스를 만들 때 결정해야 하는 항목에서 전문성이 없어도 어떤 ui·ux가 적절한지 판단하고 근거를 댈 수 있습니다. 진행자가 강조한 것은 도구가 아니라 발상입니다. 같은 도구를 줘도 이걸 전부 모아서 판단 근거까지 정리하겠다 고 생각하는 사람은 드물다는 것이 시연의 결론이었습니다. ① 출발점 질문 — “다 가지고 있으면 뭘 할 수 있나” 진행자가 화면에 띄운 것은 국내·해외 서비스의 ui 레퍼런스가 대량으로 모여 있는 자료였습니다. 그리고 참가자들에게 물었습니다. “이런 게 다 가지고 있다는 게 어떤 의미인가. 뭘 할 수 있을까요. 이걸 다 가지고 있으면요.” 1교시 · 진행자 한 참가자가 먼저 내놓은 답은 “참고” 였습니다. 시안을 만들 때 보고 참고한다는 뜻입니다. 진행자는 그 답이 맞지만 거기서 멈춘다고 했습니다. “근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요.” 1교시 · 진행자 이 시연이 나온 맥락은 “의사결정을 해 줄 수 있는 시스템을 만든다” 는 하반기 계획 이야기였습니다. 그래서 질문의 초점도 “자료가 많다”가 아니라 “ 이 자료로 결정을 할 수 있느냐 ”에 있었습니다. ② 이미지만 있을 때의 한계 이 대목에서 한 참가자가 “원래 이런 거 준비할 때 디자이너들이 다 캡처한다”고 말했습니다. 여기에 대한 진행자의 답이 이 문서에서 가장 중요합니다. “그거는 사실 자료만 들어가 있는 거지, 왜 이 레이아웃 구조를 해야 되는지 의사결정에 들어가 있는 데이터는 들어가 있지 않잖아요.” 1교시 · 진행자 진행자는 지금 모아 둔 자료의 상태를 “그냥 카테고리만 짓는 거” 라고 말했습니다. 형식에 맞는 분류만 붙여 두는 수준이라는 뜻입니다. 그래서 나중에 ai가 그 자료를 검색해도 문제가 생깁니다. 사진만 있으면 그 화면이 왜 그렇게 생겼는지를 판단하지 못합니다. 두 줄의 출발점은 같습니다. 두 번째 칸에서 무엇을 함께 적어 두었는가 가 이후 단계를 바꿉니다. ③ 판단 근거를 함께 "}
