원본 전체 내용(임베드): week3/transcripts/3주차-1교시-강의기록.html
원본 전체 내용(임베드): week3/docs/w3-practice-openclaw.html
원본 전체 내용(임베드): week3/docs/w3-concept-bot-ops.html
원본 전체 내용(임베드): week3/transcripts/3주차-2교시-강의기록.html
원본 전체 내용(임베드): week3/docs/w3-concept-llm-wiki.html
원본 전체 내용(임베드): week3/docs/w3-practice-usecase.html
원본 전체 내용(임베드): week3/transcripts/3주차-3교시-강의기록.html
원본 전체 내용(임베드): week4/docs/w4-overview.html
원본 전체 내용(임베드): week4/docs/w4-concept-habit.html
원본 전체 내용(임베드): week4/docs/w4-practice-review.html
원본 전체 내용(임베드): week4/docs/w4-concept-attitude.html
원본 전체 내용(임베드): week4/docs/w4-concept-irreplaceable.html
원본 전체 내용(임베드): week4/transcripts/4주차-1교시-강의기록.html
원본 전체 내용(임베드): week4/docs/w4-concept-decision-os.html
원본 전체 내용(임베드): week4/docs/w4-concept-adoption.html
원본 전체 내용(임베드): week4/transcripts/4주차-2교시-강의기록.html
원본 전체 내용(임베드): week4/docs/w4-practice-deploy.html
원본 전체 내용(임베드): week4/docs/w4-concept-server.html
원본 전체 내용(임베드): week4/docs/w4-concept-security.html
원본 전체 내용(임베드): week4/transcripts/4주차-3교시-강의기록.html
원본 전체 내용(임베드): week4/docs/w4-closing.html
원본 전체 내용(임베드): week4/transcripts/4주차-4교시-강의기록.html
↑↓ 이동 · Enter 이동 · Esc 닫기
AX 스터디 — 자율 실습 교안
이 저장소는 AX 스터디 수업을 각자 자기 손으로 교안 대시보드까지 만들어 보는 실습 꾸러미입니다. 수업 녹음을 글로 옮기고(전사), 그 전사를 근거로 교안을 집필하고, 빌드해서 지금 보고 있는 것과 같은 단일 HTML 대시보드를 만드는 것까지가 한 바퀴입니다.
현재 3주차와 4주차 교안이 들어 있습니다. 왼쪽 위의 주차 전환기로 두 주차를 오갈 수 있습니다.
개발 경험이 없어도 괜찮습니다. 직접 코드를 짜는 게 아니라 내 Claude Code에게 무엇을 만들지 설명하고, 결과를 검수하는 일이 실습의 본체입니다.
이 템플릿으로 하는 일
수업 녹음 → 전사 텍스트 → 교안 파셜 집필 → 빌드 한 줄로 index.html 생성 → 진행자에게 전달. 완성본은 진행자가 아카이브에 게시합니다.
지금 들어 있는 것
3주차 — 에이전트(12개 문서) · 4주차 — 태도와 시야(15개 문서). 각 주차는 개요 · 주제별 정리 문서 · 교시별 강의기록으로 구성돼 있습니다.
교안을 한 편 쓸 때마다 메뉴가 한 줄씩 늘어나고, 전부가 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)를 진행자에게 전달하면, 진행자가 아카이브에 게시합니다. 게시는 참가자가 직접 하지 않습니다.
②폴더 구조 — 무엇을 어디에 두나
손대는 곳은 사실상 전사 폴더와 파셜 폴더 두 군데입니다. 나머지는 도구와 참고 자료입니다.
경로
무엇이 들어가나
내가 손대나
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주차에 AI로 무엇을 할 수 있는지 경험했고, 2주차에 내가 실제로 만들 수 있다는 것을 확인했습니다. 3주차는 그것을 일상과 업무에 통합하고, 결과를 판단하는 눈을 기르는 단계입니다.
이번 주의 도착점은 분명합니다 — 노트북 앞에 앉아 있어야만 시킬 수 있던 일을, 채팅창에서 비서처럼 시킬 수 있는 상태로 옮기는 것입니다.
3주차 한 문장
손에 쥔 것을 놓아야 다른 것을 쥘 수 있습니다. 에이전트를 여러 개 돌리려면 손이 먼저 비어 있어야 합니다.
이번 주에 하는 일
에이전트를 붙여 내가 없는 자리에서도 일이 돌아가게 만듭니다. 오픈클로를 설치해 슬랙에서 봇을 부르고, 반복 작업을 예약해 두고, 봇이 잘 찾아갈 수 있게 지식을 정리합니다.
다만 도구를 늘리는 것이 목적은 아닙니다. 진행자가 1교시에 반복해서 강조한 것은 이것이었습니다 — 시키기만 하고 멈추면 판단하는 힘이 사라진다. 결과를 받고 왜 그렇게 했는지 한 번 더 묻는 것까지가 이번 주의 실습입니다.
①오늘의 흐름 — 다섯 단계
수업은 회고에서 시작해 실습으로 끝나는 다섯 단계로 짜여 있습니다. 앞 단계가 뒷 단계의 이유가 됩니다.
3주차는 1교시 2시간 8분 · 2교시 2시간 54분 · 3교시 1시간 29분, 모두 6시간 31분 진행됐습니다. 교시마다 성격이 뚜렷하게 달랐습니다.
교시
성격
무엇을 했나
1교시
회고와 태도
지난 과제를 열어 보고, 왜 내려놓기부터 시작하는지 정리
2교시
설치와 운영
오픈클로를 실제로 설치해 슬랙에 붙이고, 봇 운영·보안을 다룸
3교시
지식과 사례
LLM 위키로 지식을 구조화하고, 각자의 활용 사례를 공유
1교시 — 회고하고 내려놓기
12주차 과제 회고 — 만들어진 것과 이해한 것
두 사람의 과제를 화면에 띄우고 과정과 피드백을 나눴습니다. 결론은 완성도가 아니라 "내가 이해하고 있는가"였습니다. → 과제 회고 문서
2내려놓기와 보는 눈 — 왜 태도가 먼저인가
1주차 세 원칙을 다시 확인하고, 『한비자』의 한 대목을 빌려 왜 내려놓아야 하는지를 짚었습니다. → 내려놓기와 보는 눈
3에이전트와 오픈클로 — 이번 주의 메인 주제
"오픈클로랑 클로드 코드랑 뭐가 다른가"에 대한 답과, 봇을 여러 개 두고 일하는 방식. → 에이전트와 오픈클로 · 1교시 강의기록
2교시 — 설치하고 운영하기
4오픈클로 설치와 슬랙봇 연동
가이드 문서 한 장으로 설치를 맡기고, 슬랙에 봇을 붙여 첫 응답까지 확인했습니다. 권한 문제·재설치·이름 충돌 등 실제로 막힌 지점이 그대로 담겨 있습니다. → 오픈클로 설치 실습
5봇 운영과 보안 — 만든 다음이 진짜다
오픈클로와 헤르메스의 차이, 상황별 모델 선택, 실제로 뚫렸던 사칭 사고, 봇끼리 협업시키는 법, 잘 다듬어진 봇의 구조를 물려주는 법. → 봇 운영과 보안 · 2교시 강의기록
3교시 — 지식을 구조화하고 써먹기
6LLM 위키와 지식 그래프
AI가 전부 읽지 않고 타고 찾아가게 만드는 구조입니다. 위키화 지시 방법, 만든 뒤의 검증 루프, 봇을 교정하는 대화형 피드백까지. → LLM 위키와 지식 그래프
7AI 활용 사례 — 실제로 이렇게 써 봤다
6초 영상을 쪼개 제품 조사를 돌리고, 4박 5일 여행 가이드북을 만들고, AI 영상 제작에서 무엇이 결과를 가르는지 정리했습니다. → AI 활용 사례 · 3교시 강의기록
강의기록과 정리 문서의 차이 — 정리 문서는 주제별로 묶은 것이고, 강의기록은 시간 순서 그대로입니다. 어떤 이야기가 어떤 맥락에서 나왔는지 확인할 때는 강의기록을 봅니다.
③3주차가 남긴 세 문장
문장 1
만들어졌다 ≠ 이해했다
AI는 시키지 않은 것까지 만들어 둡니다. 열어 보지 않으면 없는 것과 같습니다. 결과가 나온 시점이 끝이 아니라 확인의 시작입니다.
문장 2
결과물을 먼저 보여준다
과정부터 말하면 듣는 사람은 목적지를 모른 채 따라옵니다. 도착점을 먼저 보여 주고 되짚는 편이 언제나 잘 전달됩니다.
문장 3
시키고 끝내지 않는다
실행만 맡기면 결과는 쌓이는데 판단은 안 쌓입니다. "왜 이렇게 했어?"를 한 번 더 묻는 것이 보는 눈을 기르는 방법입니다.
"얘를 통해서 더 잘 아는 걸 가지고 판단할 수 있는 능력을 키운다고 생각해야지, 시키고 실행만 시키고 끝나 버리면 진짜 바보가 된다고 느껴요."
1교시 · 보는 눈에 대해
④실습으로 확인한 것 — 설치부터 위키까지
교안덱에 예고된 5단계가 2·3교시에서 실제로 어떻게 진행됐는지 정리하면 이렇습니다.
단계
예고된 것
실제로 나온 것
1
가이드 문서 붙여넣기
설치를 통째로 맡기고 사람은 활용에 시간을 썼습니다. "설치를 한 땀 한 땀 알려 주는 건 의미가 없다"
2
설치와 게이트웨이
왜 게이트웨이가 필요한지가 핵심이었습니다 — 로컬 웹은 밖에서 열리지 않기 때문
3
슬랙 앱과 토큰 연결
게스트 권한이라 설치가 막히는 실제 상황을 겪고 권한을 올려 해결했습니다
4
기반 닦기와 동작 확인
설정 변경 후 재설치를 해야 반영되고, 이름이 다른 단어와 겹치면 엉뚱하게 반응합니다
5
LLM Wiki
만드는 것보다 만든 뒤 테스트 30~50개로 검증하는 루프가 중요하다는 것이 결론이었습니다
예고와 가장 달랐던 점 하나 — 실습의 절반은 막힌 지점을 해결하는 과정이었고, 그것이 오히려 배울 거리였습니다.
3주차에서 반복해서 나온 원칙
원칙
모르면 화면을 찍어 물어본다
설명하기 어려운 상황일수록 스크린샷 + 내 상황 한 줄이 가장 빠릅니다. 진행자도 "저도 몰라요"를 여러 번 말했습니다.
원칙
봇과 싸우지 말고 맡긴다
봇이 말을 안 들으면 계속 요구하지 말고, 대화 로그와 설정 파일을 클로드 코드에 주고 원인을 분석하게 합니다.
원칙
방법을 지정하지 않는다
기술 이름을 콕 집으면 그 방법만 시도합니다. 상황과 목표를 말하고 방법을 검토·테스트하게 하는 편이 낫습니다.
안전 원칙은 3주차 내내 같았습니다 — 메일처럼 밖으로 나가는 것은 자동으로 보내지 않습니다. 여기에 2교시에서 하나가 더해졌습니다 — 사람 확인은 이름이 아니라 계정 ID로. 실제 사칭 사고에서 나온 교훈입니다.
다음 주가 마지막 주입니다. 상황이 되면 서버를 올려 보는 경험을 해 보자는 제안이 3교시 마지막에 나왔습니다. 클라우드 무료 크레딧으로 몇 달은 실습할 수 있다고 합니다.
⑤이번 주 과제 — 이 화면을 직접 만드는 것
3주차 과제는 조금 특별합니다. 오늘 수업의 교안을 각자 직접 만드는 것입니다. 그래서 진행자가 수업 시작부터 "오늘 녹음을 꼭 켜 두라"고 강조했습니다 — 녹음이 없으면 만들 재료가 없기 때문입니다.
①
수업을 녹음하고 전사한다
→
②
전사를 근거로 교안 파셜을 쓴다
→
③
빌드해서 index.html 하나로 합친다
python3 tools/build_dashboard.py # 파셜들을 index.html 하나로 합친다
python3 tools/preview_server.py # http://localhost:8787 에서 확인
지금 보고 있는 이 화면이 그 과제의 결과물입니다. 왼쪽 메뉴의 항목 하나가 파셜 문서 하나이고, 그것들이 빌드로 합쳐져 단일 index.html이 됩니다. 만드는 방법은 템플릿 소개와 docs/문서-제작-가이드.md 에 정리돼 있습니다.
뷰를 추가할 때 — 세 곳을 함께 고친다
문서를 하나 더 쓸 때마다 손대는 곳은 늘 같습니다. 세 곳 중 하나라도 빠지면 빌드가 알려 줍니다.
어디를
무엇을
파셜 파일
week3/docs/<뷰ID>.html — 자기 스타일을 다 담은 자기완결 HTML (<script>는 넣지 않는다)
셸
tools/dashboard_shell.html — 메뉴 링크 한 줄 + <section>과 <!--EMBED:뷰ID--> 마커
빌더
tools/build_dashboard.py — EMBED 목록에 뷰 ID → 파일 경로 한 줄
뷰 이름을 규칙대로 지으면 왼쪽 메뉴의 점 색과 상단 유형 표시가 자동으로 맞춰집니다.
뷰 ID
유형 표시
예
w3-lecture…
강의
w3-lecture1 — 1교시 강의기록
w3-practice…
실습
w3-practice-review — 과제 회고
w3-concept…
개념
w3-concept-agent — 에이전트와 오픈클로
w3-video…
영상
w3-video-demo — 영상 리포트
w3-overview
표시 없음
개요·목차 성격의 문서
집필 원칙 하나만 기억하면 됩니다 — 전사에 실제로 있는 내용만 씁니다. 그럴듯해 보인다고 배경 지식이나 수치를 채워 넣지 않습니다. 애매하면 쓰지 않거나, 전사의 표현을 그대로 인용하는 편이 안전합니다. 사적인 잡담과 개인에 대한 평가는 빼고, 참가자는 스터디 내 호칭까지만 표기합니다.
2주차 과제 회고 — 결과물보다 "이해했는가"
3주차 1교시는 지난 2주차 과제를 함께 열어 보는 것으로 시작했습니다. 두 사람이 각자 만든 결과물을 화면에 띄우고, 어떤 배경에서 시작해 어떤 순서로 만들었는지 설명한 뒤, 진행자와 서로가 피드백을 주고받았습니다.
이 시간의 결론은 의외로 결과물의 완성도가 아니었습니다. "만들어졌다"와 "이해했다"는 다르다는 것, 그리고 설명하는 순서를 바꾸면 같은 결과물이 훨씬 잘 전달된다는 것이었습니다.
이번 과제가 무엇이었나
1~2주차에 배운 도구를 따로따로가 아니라 이어 붙여, 내 목적에 맞는 결과물을 한 번 끝까지 만들어 보는 것. 완성도는 두 번째였고, 먼저 시도해 보는 것이 목적이었습니다.
1교시 앞부분 요약
과제는 도구 조합 연습이었습니다. MCP로 피그마에 결과를 옮기고, UI 레퍼런스로 디자인 방향을 잡고, 코덱스 CLI로 이미지를 뽑아 하나의 결과물로 합치는 흐름입니다.
두 사람의 결과물은 모두 높은 평가를 받았지만(9.5점 · 9점 / 10점 만점), 피드백의 초점은 다른 데 있었습니다. 한 사람에게는 "만들어진 것을 본인이 다 보았는가"가, 다른 한 사람에게는 "결과물을 먼저 보여주고 과정을 설명했는가"가 지적됐습니다.
그리고 공통 숙제가 하나 붙었습니다 — 작업이 끝난 세션을 그대로 두지 말고, 다시 쓸 수 있는 스킬로 남길 것.
①과제의 정의 — 배운 것을 이어 붙이기
진행자가 과제를 다시 정리해 준 대목이 시작이었습니다. 이번 과제는 새로운 것을 배우는 자리가 아니라, 이미 배운 것을 한 줄로 꿰는 자리였습니다.
세 도구를 각각 익히는 것이 1~2주차였다면, 2주차 과제는 그 셋을 하나의 목적 아래 이어 붙이는 연습이었습니다.
진행자가 덧붙인 조건은 두 가지였습니다. 하나는 "결과물이 마음에 안 들어도 괜찮으니 일단 시도해 보라"는 것, 다른 하나는 "주차가 넘어갈 때마다 발전이 보여야 한다"는 것이었습니다. 같은 자리에 머무는 것이 문제이지, 결과가 거친 것은 문제가 아니라는 뜻입니다.
②설명하는 순서 — 배경 · 맥락 · 목적을 먼저
과제 발표에 들어가기 전에, 두 사람의 설명 방식이 먼저 비교됐습니다. 한 사람은 자기가 무엇을 만들었는지부터 말했고, 다른 사람은 왜 이 과제를 하게 됐는지부터 말했습니다. 듣는 사람 입장에서 이해가 갈린 지점이 바로 거기였습니다.
① 배경
어떤 문제·상황에서 출발했는지
→
② 맥락
그래서 무엇을 하기로 했는지
→
③ 목적
그 일로 무엇이 달라지길 바라는지
중요한 것은 이 순서가 사람에게만 해당하는 이야기가 아니라는 점입니다. 진행자는 이 대목을 곧바로 AI 쪽으로 연결했습니다.
"AI한테도 그렇게 설명을 잘해야 됩니다. 맥락을 다 빼놓고 설명하면, 내가 무슨 목표를 가지고 무엇을 만들어 주길 바라는지 모르니까 — 모호할수록 결과는 잘 안 나옵니다."
1교시 · 과제 발표 직전
사람에게 설명을 잘하는 사람이 AI에게도 설명을 잘합니다. 배경 → 맥락 → 목적은 발표 요령이 아니라 프롬프트의 기본 골격이기도 합니다. 이 순서가 빠지면 사람도 AI도 "그래서 뭘 하라는 거지?" 지점에서 멈춥니다.
③동현 님 — 부모님 음식점 사이트
첫 번째 과제는 부모님이 운영하시는 음식점을 소개하는 사이트였습니다. 만들고 싶은 것이 딱히 떠오르지 않던 차에 가족의 제안으로 주제가 정해졌고, 실제로 부모님도 홍보용으로 하나 있으면 좋겠다고 하시던 참이었다고 합니다.
어떻게 만들었나
1자료를 AI에게 찾게 했다
가게가 예전에 TV 프로그램에 소개된 적이 있다는 사실만 알려 주고, 해당 영상을 직접 찾아내게 했습니다. 찾은 영상에서 이미지를 캡처하고 쓸 만한 문구를 골라내게 한 것이 출발점이었습니다.
2기대와 다른 첫 결과 → 레퍼런스로 방향을 잡았다
처음 나온 피그마 결과물이 생각한 그림과 달랐습니다. 원인은 UI 레퍼런스를 제대로 짚어 주지 않은 것이었습니다. 그래서 같은 업종의 사이트를 검색해 레퍼런스로 지정하고, 그 안의 요소를 하나씩 추출해 참고하도록 다시 시켰습니다.
3톤을 말로 지정했다
"장인정신이 느껴지는 느낌"으로 문구를 다듬어 달라고 요청했습니다. 색은 실제 가게 인테리어에서 가져왔습니다 — 가게가 쓰는 초록 계열과 재료 색이 그대로 화면의 톤이 됐습니다.
4이미지 품질을 따로 손봤다
방송 영상에서 딴 이미지라 화질이 떨어졌습니다. 고화질로 다시 캡처하게 하고, 코덱스 CLI도 함께 써서 이미지를 보완했습니다. 영상을 프레임 단위로 쪼개 쓰는 방법도 이 사이트에 적용했습니다.
5한 번에 다 시키지 않고 대화로 쌓았다
요구를 한꺼번에 넣지 않고 "이것도 넣어 보고, 저것도 넣어 보고" 하며 대화하듯 붙여 나갔습니다. 결과물은 피그마 시안과 HTML 사이트 두 갈래로 나왔습니다.
에이전트에 역할을 나눠 준 것이 결정적이었습니다. "UI/UX 전문 웹 에이전시의 스쿼드를 구성하라"고 지시하고 기획자 · 디자이너 · 개발자 역할을 각각 부여했습니다. 여기에 "100점 만점에 95점 기준으로 평가하라"는 품질 기준까지 함께 넣었습니다. 뒤에 나온 디자인 시스템 문서는 아무도 따로 시키지 않았는데, 디자이너 역할을 맡은 에이전트가 스스로 만들어 낸 결과였습니다.
결정적인 장면 — "커버만 봤어요"
결과물을 함께 보던 중 진행자가 피그마 왼쪽의 페이지 목록을 열어 보게 했습니다. 데스크톱 화면 외에도 모바일 화면 · 파운데이션 · 컴포넌트 등 여러 페이지가 이미 만들어져 있었습니다. 그런데 본인은 그것을 보지 못한 상태였습니다.
이 장면에서 나온 지적이 1교시 전체를 관통하는 문장이 됐습니다.
"일단 결과는 만들어져 있는데, 본인이 그걸 이해했느냐 안 했느냐가 중요한 겁니다. 솔직함이 중요합니다."
1교시 · 피그마 결과물을 함께 열어 보며
본인도 그 자리에서 "솔직히 몰랐다"고 인정했고, 진행자는 그 솔직함을 오히려 긍정적으로 평가했습니다. 아는 척하고 넘어갔다면 배울 것이 없었을 지점이기 때문입니다.
여기서 배운 것 — 디자인 시스템이란
본인이 개념을 모르는 채 만들어진 파운데이션 · 컴포넌트 페이지를 계기로, 진행자가 디자인 시스템을 설명했습니다.
질문
설명
무엇인가
디자인·개발·프로덕트를 하나의 기준으로 묶기 위한 협업 문서이자 시스템. 예쁘게 만드는 장식이 아니라 규칙표에 가깝습니다.
왜 필요한가
규칙이 있어야 한 곳을 바꾸면 쓰인 곳이 모두 함께 바뀝니다. 코드에서 값을 변수로 빼 두는 것과 같은 이치입니다.
어떻게 쌓나
바텀업으로 쌓습니다 — 색을 먼저 정리하고, 그 위에 컴포넌트를 만들고, 그 컴포넌트로 화면을 구성합니다.
왜 어려운가
개념을 모르면 규칙을 세우지 않고 값을 화면마다 직접 써 넣게 됩니다. 문서는 따로 있는데 실제 시안은 문서를 안 따르는 상태가 되기 쉽습니다.
함께 나온 실무 팁 하나 — 사이트가 모바일에서 어떻게 보이는지는 브라우저 개발자 도구로 바로 확인할 수 있습니다. 맥에서는 Cmd + Option + I, 또는 크롬 메뉴의 도구 더보기 → 개발자 도구. 열린 창에서 기기를 iPhone 등으로 바꿔 보면 됩니다.
평가와 그 이유
진행자의 평가는 10점 만점에 9.5점이었습니다. 점수보다 그 이유가 중요합니다.
이유 1
동기가 진짜였다
과제로 끝낼 생각이 아니라 실제로 부모님께 만들어 드리고 싶어서 한 일이었습니다. 하고 싶은 것을 찾으면 시키지 않아도 알아서 찾아 합니다.
이유 2
한 단계 더 갔다
피그마에서 멈추지 않고 HTML 사이트까지 만들었습니다. 시키지 않은 것을 자기 시간을 들여 더 해 본 것은 감점이 아니라 가점이었습니다.
이유 3
할 것을 빼먹지 않았다
영상 관련 실습도 함께 해 왔습니다. 재밌는 것만 하고 해야 할 것을 건너뛰었다면 점수가 깎였을 것이라고 진행자는 분명히 했습니다.
후속 숙제 — 작업이 끝난 세션을 그냥 닫지 말고, "지금까지 넣은 프롬프트와 이어진 맥락을 바탕으로 재사용 가능한 스킬을 만들어 달라"고 요청해 두라는 지시가 붙었습니다. 세션을 이미 닫았다면 resume으로 되살리거나, "이런 내용을 이야기한 세션이 있을 텐데 그 ID를 찾아 달라"고 하면 찾아 줍니다.
④주리 님 — 리뷰를 쉽게 설명하는 스킬
두 번째 과제는 성격이 완전히 달랐습니다. 눈에 보이는 결과물이 아니라 자기가 일하는 방식 자체를 고치는 도구를 만든 것입니다.
출발점은 기획자로서 느낀 부족함이었습니다. 팀에 리뷰할 때 전체 맥락을 구조적으로 먼저 설명하고, 듣는 사람 머릿속에 그림이 그려지게 해야 하는데 그 부분이 잘 안 되고 빠뜨리는 것이 많다는 자각이었습니다. 그래서 만든 것이 "이지 익스플레인"이라는 스킬입니다.
무엇이 나오는 스킬인가
넣는 것
이번에 리뷰할 목업 · 기획 문서와 지난 리뷰 내용
→
나오는 것
말할 대본 · TTS음성 · 보면서 확인하는 화면
→
쓰는 법
왼쪽에 설명할 문서, 오른쪽에 확인용 문서를 띄우고 설명을 연습
리뷰가 끝난 뒤에는 방향이 반대로 흐릅니다. 녹취를 넣으면 회고 문서가 나오고, 그 회고가 다음 리뷰 준비의 입력이 됩니다. 한 바퀴가 도는 구조입니다.
대본의 다섯 구조
대본을 아무렇게나 뽑게 두지 않고 다섯 칸을 미리 정해 두었습니다. 이 구조 자체가 앞에서 나온 "배경 → 맥락 → 목적"을 실제 문서 형태로 옮긴 것입니다.
순서
칸 이름
이 칸에 들어가는 것
1
여기까지 온 이야기
지난 리뷰에서 어떤 이야기가 있었고, 그중 무엇이 반영됐는지
2
전체 그림
오늘 리뷰할 것이 몇 가지이고 서로 어떻게 이어지는지
3
하나씩
항목별로 결론 → 그렇게 한 이유 → 예시
4
그래서 달라지는 것
듣는 사람 입장에서 무엇이 바뀌는지
5
예상 질문
나올 만한 질문과 답
만드는 과정에서 배운 것
1자기 말버릇부터 파악하게 했다
과거에 진행한 리뷰의 전사 약 8시간 분량을 통째로 넣고, "다른 세션이나 메모를 보지 말고 이 전사만 보고" 내 리뷰의 문제점과 말버릇을 찾아 달라고 했습니다. 범위를 좁혀 준 덕분에 지적이 정확했습니다.
2방향이 어긋난 것을 맥락으로 바로잡았다
처음에 AI는 이 과제를 "회의가 끝난 뒤 팀에 공유하는 문서를 만드는 일"로 이해했습니다. 실제 목적은 리뷰 전에 설명을 준비하고, 리뷰 후에 회고하는 것이었습니다. 결과물을 고치는 대신 맥락을 더 넣어 방향을 되돌렸습니다.
3문체를 규칙으로 못 박았다
추상적인 표현 금지 · 비유 쓰지 않기 · 근거를 들 것 · 정해진 표기를 따를 것. "엽니다 / 닫습니다 / 돕니다" 같은 두루뭉술한 말이 기획 문서에서 특히 문제가 된다는 자각에서 나온 규칙입니다.
4듣는 것과 읽는 것이 다르다는 걸 확인했다
대본을 눈으로 읽는 것과 TTS로 듣는 것이 확실히 달랐다고 회고했습니다. 팟캐스트처럼 들으면 이해가 더 잘 들어온다는 반응이 함께 나왔습니다.
"내 말버릇이나 부족한 부분을 직면하는 게 되게 어렵잖아요. 회피하게 되고. 그런데 직면도 하는 시간이었어요."
1교시 · 과제 회고
동료의 피드백도 같은 지점에 닿았습니다. 영업에서도 고객사에 설명할 일이 많은데, 자기 말버릇을 인지는 해도 어떻게 고쳐야 할지 몰랐다는 것입니다. 녹음을 들으며 스스로 점검하는 것은 버티기 힘든 일인데, AI가 대신 듣고 짚어 주니 그 부담이 사라진다는 점을 장점으로 꼽았습니다.
평가와 피드백
평가는 10점 만점에 9점이었습니다. 결과물과 준비 과정은 잘 갖췄지만, 설명하는 방식에서 아쉬움이 지적됐습니다.
같은 내용, 같은 결과물인데 순서 하나로 이해도가 갈립니다.
"차라리 결과물을 먼저 보여 주고 난 뒤에 설명하셨으면 훨씬 잘 이해됐을 거예요. 그러면 듣는 사람도 '이 결과물이 나오기 위해서 이런 걸 했구나' 하고 인지가 되거든요."
1교시 · 두 번째 과제 피드백
실제로 함께 듣던 동료도 "처음에는 무슨 말인지 이해가 안 갔는데, 화면을 보여 주니까 딱 이해가 됐다"고 같은 반응을 말했습니다. 나머지 지적 — 대본에 남아 있는 추상적 표현과 문체 — 은 한 번에 고쳐지는 것이 아니라 반복 피드백으로 다듬어야 하는 것으로 정리됐습니다.
0.5점 차이의 이유도 솔직하게 공유됐습니다. 두 사람의 출발선이 다르기 때문입니다. 이미 같은 방식으로 일해 온 사람에게는 기대치가 더 높고, 처음 해 본 사람에게는 시도 자체가 더 크게 평가됩니다. 점수는 절대 기준이 아니라 각자의 지난주 대비라는 뜻입니다.
⑤두 과제에서 공통으로 남은 것
성격이 전혀 다른 두 과제였는데, 피드백은 세 갈래로 모였습니다.
교훈 1
만든 것을 다 열어 본다
AI는 시키지 않은 것까지 만들어 둡니다. 열어 보지 않으면 없는 것과 같습니다. 결과가 나왔을 때가 끝이 아니라, 거기서부터 확인이 시작됩니다.
교훈 2
결과물을 먼저 보여준다
과정부터 말하면 듣는 사람은 목적지를 모른 채 따라옵니다. 도착점을 먼저 보여 주고 되짚는 편이 언제나 잘 전달됩니다.
교훈 3
끝난 세션을 스킬로 남긴다
한 번 만들고 닫으면 맥락이 통째로 사라집니다. 같은 작업을 또 할 것이라면 지금 세션에서 스킬로 뽑아 두는 것까지가 과제입니다.
평가 정리
과제
결과물
핵심 피드백
평가
동현 님
부모님 음식점 사이트 — 피그마 시안 + HTML 사이트
결과는 훌륭하나 만들어진 것을 다 확인하지 않았다. 동기·시도 폭은 높이 평가
9.5 / 10
주리 님
리뷰 설명 지원 스킬 "이지 익스플레인" — 대본 + 음성 + 확인 화면
결과·준비 과정 모두 충실. 설명 순서(결과물 먼저)와 문체 다듬기가 과제
9 / 10
두 과제를 한 문장으로 묶으면 이렇습니다 — AI가 만들어 준 것을 내가 이해하고 있어야, 그다음 판단을 내가 할 수 있다. 이 문장이 곧바로 다음 주제로 이어집니다. 내려놓기와 보는 눈에서 왜 "이해"가 이번 주의 중심어인지 설명합니다.
내려놓기와 보는 눈 — 3주차가 여기서 시작하는 이유
과제 회고가 끝나고 3주차 본론으로 넘어가면서, 진행자는 새 도구부터 꺼내지 않았습니다. 대신 1주차에 정한 세 가지 원칙을 다시 물었습니다. 도구가 늘어날수록 흔들리는 것은 도구가 아니라 쓰는 사람의 태도이기 때문입니다.
이 문서는 1교시의 중간 절반 — 왜 기존 방식을 내려놓아야 하는가, 그리고 실행을 맡긴 다음에 무엇이 남아야 하는가에 대한 이야기입니다.
이번 주 한 문장
쥔 것을 놓아야 다른 것을 쥘 수 있고, 시키기만 하고 멈추면 판단하는 힘이 사라진다. 3주차의 목표는 도구를 늘리는 것이 아니라 보는 눈을 기르는 것입니다.
세 주차의 위치
1주차는 "AI 시대에 무엇을 할 수 있나"를 경험한 시간이었고, 2주차는 "내가 실제로 할 수 있는 것"을 직접 만들어 본 시간이었습니다.
3주차는 그것을 일상과 업무에 통합하고, 결과를 판단하는 눈을 기르는 단계입니다. 그래서 이번 주에는 도구 사용법보다 내가 없는 자리에서도 일이 돌아가게 만드는 구조와, 그 결과를 내가 판단할 수 있는 기준이 함께 다뤄집니다.
①1주차 세 원칙 — 다시 꺼내는 이유
진행자가 참가자들에게 직접 물었고, 세 가지가 다시 확인됐습니다.
원칙 1
기존 방식을 내려놓는다
지금까지 익숙했던 업무 방식을 일단 내려놓습니다. 손에 남아 있으면 새것이 들어올 자리가 없습니다.
원칙 2
일단 매일 해 본다
되는지 안 되는지 따지기 전에 일단 열어서 해 봅니다. 업무의 시작을 클로드 코드로 잡는 습관 자체가 실력이 됩니다.
원칙 3
호들갑에 휘둘리지 않는다
새 도구가 나올 때마다 들썩이는 이야기에 중심을 잃지 않습니다. 본질은 하나이고, 알면 나머지는 따라옵니다.
3주차에 이 셋을 다시 꺼낸 이유는 분명합니다. 이번 주부터는 에이전트를 여러 개 돌리는 이야기가 나옵니다. 여러 개를 굴리려면 손이 먼저 비어 있어야 합니다. 하나를 붙들고 있으면 두 번째를 잡을 수 없습니다.
②왜 내려놓아야 하는가
진행자는 손에 들고 있던 물건을 들어 보이며 설명했습니다. 이미 뭔가를 쥐고 있으면, 그 상태로 하나를 더 집기가 어렵습니다. 내려놓아야 다음 것을 잡을 수 있다는 아주 단순한 이야기입니다.
이 이야기는 뒤에 나온 책 한 권으로 이어졌습니다. 진행자가 오랫동안 멘토링을 받아 온 분에게 선물 받은 『한비자』입니다. 서양에 마키아벨리가 있다면 동양에는 한비자가 있다고 말해지는 고전으로, 법과 통치를 다루되 우화 형태로 풀어써서 읽기 쉽게 만든 책이라고 소개됐습니다. 그 안에 이런 문장이 있습니다.
"쥔 것을 놓아야 된다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 된다."
1교시 · 『한비자』를 소개하며
셋 다 같은 말입니다 — 지금 가진 것을 놓을 수 있어야 다음 단계가 열립니다. 진행자는 이것을 "지금 시대에 더 그렇다"고 덧붙였습니다.
③내려놓는 과정은 원래 거칠다
이 대목에서 참가자 한 사람이 솔직한 어려움을 꺼냈습니다. 교안에 적힌 원칙이 실제로는 얼마나 어려운지에 대한 이야기였고, 1교시에서 가장 길게 이어진 대화이기도 합니다.
어려움 1기존 업무와 병행하는 동안 산만해진다
새 방식이 완전히 자리 잡기 전까지는 예전 방식도 계속 돌려야 합니다. 기존에 쌓아 둔 자료와 흐름이 있고 일은 계속 들어오는데, 한쪽에서는 새 도구를 익히고 있으니 업무가 산만해지고 머리가 아픈 시기가 옵니다.
어려움 2주변이 함께 움직이지 않는다
필요성을 못 느끼는 동료에게는 "굳이 왜?"가 먼저 나옵니다. 좋은 것을 공유해도 자랑처럼 비칠까 봐 조심스러워집니다. 진행자의 진단은 간단했습니다 — 같이 하지 않기 때문에 더 외롭다.
어려움 3AI를 쓰다 낸 실수는 더 크게 보인다
평소였으면 넘어갔을 실수도 "AI 써서 실수했네"가 됩니다. 새 방식을 먼저 시도하는 사람이 감수하는 부담입니다.
어려움 4비용에서 먼저 벽을 만난다
월 십수만 원의 구독료 앞에서 대화가 멈추는 경우가 많습니다. "가치를 느껴야 투자가 되는데, 아직 가치를 못 느끼는 단계"라는 것이 진행자의 설명이었습니다.
"원래 과도기는 거칩니다. 다 같이 하면서 이걸 또 한다는 게 원래 어려워요. 혼자서는 안 됩니다 — 할 거면 다 같이 하든지."
1교시 · 과도기의 어려움에 대해
결론은 그만두라가 아니라 시점을 이해하라였습니다. 지금 말해 봐야 조직은 움직이지 않고, 성과가 눈에 보이기 시작할 때 비로소 필요성이 인정된다는 것입니다. 그러니 그때까지는 계속 쓰면서 익숙해지는 기간으로 삼으라는 조언이었습니다.
도구 한 종류로는 부족하다는 이야기도 함께 나왔습니다. 클로드 코드만으로는 막히는 지점이 있고, 코덱스와 이미지 리소스를 함께 붙여야 가능한 범위가 넓어집니다. 여러 도구를 오케스트레이션해서 쓸 수 있다는 사고 자체가 생기는 데 시간이 걸리고, 그것은 직접 경험해 보지 않으면 알기 어렵습니다.
여기서 한 가지 안전 원칙이 못 박혔습니다 — 메일처럼 밖으로 나가는 것은 자동으로 보내지 않는다. 실제로 의도치 않은 메일이 나간 경험이 공유됐고, 결론은 명확했습니다. 만들고 확인하는 것까지는 맡기되, 바깥으로 나가는 마지막 버튼은 사람이 누른다.
④보는 눈 — 실행만 시키면 남는 게 없다
1교시의 무게중심이 옮겨가는 지점입니다. 진행자는 AI를 오래 쓴 사람들이 공통으로 겪는 현상을 꺼냈습니다.
"두세 달 지나면 점점 내가 바보가 된다는 느낌이 옵니다. 그때 알아야 돼요 — 얘한테 시키고, 실행만 시키고 그냥 끝나 버리면 진짜 바보가 됩니다."
1교시 · 보는 눈에 대해
같은 자리에서 다른 참가자도 "진짜 바보 되고 있다"고 맞장구쳤습니다. 특정 개인의 문제가 아니라 AI를 실행 도구로만 쓸 때 생기는 구조적인 현상이라는 뜻입니다.
차이는 한 칸뿐입니다. 결과를 받고 나서 "왜 이렇게 했어?"를 한 번 더 묻느냐 마느냐.
앞의 과제 회고가 그대로 예시가 됐습니다. 피그마에 디자인 시스템이 만들어져 있었을 때, 그것을 열어 보고 "이건 왜 이렇게 만든 거야?"라고 물었다면 설명을 해 줍니다. 그 설명을 이해하는 순간, 내가 그 직군이 어떻게 일하는지를 알게 됩니다. 나중에 다른 일을 하든 사업을 하든 그 이해가 남습니다.
⑤판단 기준을 늘린다
진행자는 "보는 눈"을 조금 더 실무적인 말로 바꿨습니다. 의사결정의 질은 내가 가진 기준의 개수에 달려 있다는 것입니다.
기준이 하나일 때
선택지가 둘뿐입니다 — 되거나, 안 되거나
→
기준이 늘어나면
같은 상황에서도 다른 길이 보이기 시작합니다
→
그래서
의사결정이 달라지고, 결과가 달라집니다
기준을 늘리는 가장 빠른 길은 직접 해 보고 결과의 차이를 확인하는 것입니다. 같은 요청도 레퍼런스를 붙였을 때와 안 붙였을 때, 역할을 나눠 줬을 때와 안 줬을 때 결과가 달라집니다. 그 차이를 한 번 겪을 때마다 기준이 하나씩 늘어납니다.
여기에 하나가 더 붙었습니다. AI는 결과를 주면서 "다음엔 이걸 하면 좋겠다"고 제안합니다. 진행자는 이것이 사람이 갖추면 좋은 태도이기도 하다고 짚었습니다 — 시킨 일을 해 오면서 다음 단계를 함께 제시하는 사람을 관리자와 경영진은 좋아합니다. AI가 하는 그 동작을 사람도 따라 하면 됩니다.
일하는 방식도 바뀐다 — 몰입 하나에서 병렬로
예전에는 하나에 깊이 몰입해 끝내는 것이 일하는 방식이었습니다. 이제는 여러 개를 걸어 두고 돌리면서, 사람은 판단과 집중할 몇 가지에 남는 방식으로 옮겨 갑니다.
단, 병렬은 방치가 아닙니다. 걸어 두는 것과 손을 떼는 것은 다릅니다 — 이 구분이 다음 절의 주제입니다.
이 대목에서 두 참가자 모두 "이건 어렵다"고 반응했습니다. 진행자의 답은 담담했습니다 — 그래서 이걸 잘하는 사람과의 격차가 점점 커진다. 어려운 것이 정상이고, 그렇기 때문에 지금 연습한다는 뜻입니다.
⑥호들갑에 휘둘리지 않기
세 번째 원칙이 구체적인 사례로 돌아왔습니다. 새 도구가 나올 때마다 "일주일 무료" 같은 이벤트가 돌고 사람들이 몰려갑니다. 그런데 실제로 써 본 사람들 사이에서는 환불이 안 되거나 결제가 이상하게 걸리는 문제가 보고되기도 합니다.
"다른 거, 그냥 호들갑 떠는 건 놔두고 — 내가 하려는 것을 명확하게 아는 게 중요합니다."
1교시 · 트렌드를 어떻게 볼 것인가
그러면 무엇을 따라가야 하나 — 하네스를 걷어낸다
진행자가 "이건 따라갈 만한 트렌드"로 꼽은 것은 의외의 방향이었습니다. 더 얹는 것이 아니라 걷어내는 것이었습니다.
하네스란 AI가 실수하지 않도록 사람이 미리 씌워 둔 규칙과 틀입니다. 예전 모델은 그냥 두면 엉뚱한 답을 내놓았기 때문에, 규칙을 촘촘히 짜 두는 것이 실력이었습니다. 그런데 모델이 충분히 좋아진 지금은 그 규칙이 오히려 발목을 잡는 경우가 생깁니다.
예전
모델이 부족하니 규칙을 촘촘히 씌운다
→
지금
모델이 잘하는데 규칙이 길을 막는다
→
할 일
남길 것은 남기고 걷어낼 것은 걷어낸다
"지금 만들어 놓은 하네스 자체가 병목이다. 절대 규칙이라고 만들어 놓은 것들이 오히려 방해가 돼서 결과에 영향을 끼친다고 이야기합니다."
1교시 · 하네스에 대해
주의할 것은 "규칙을 전부 없애라"가 아니라는 점입니다. 진행자의 표현은 이랬습니다 — 있을 건 있으면서, 걷어낼 건 걷어내야 한다. 안전에 관한 규칙(예: 메일 자동 발송 금지)은 남기고, 모델의 판단을 대신하려던 규칙부터 덜어 내는 방향입니다.
⑦정리 — 1교시가 남긴 태도 세 가지
태도
구체적으로 무엇을 하나
내려놓는다
기존 방식을 붙들지 않습니다. 과도기가 산만한 것은 정상이고, 성과가 보일 때 비로소 주변이 따라옵니다.
물어본다
결과를 받으면 끝내지 않고 "왜 이렇게 했어?"를 한 번 더 묻습니다. 그 이해가 판단 기준이 됩니다.
명확히 안다
병렬로 여러 개를 굴리되, 내가 하려는 것은 내가 명확히 알고 있어야 합니다. 유행은 그다음입니다.
여기까지가 태도였다면, 다음은 도구입니다. 손을 비웠으니 이제 여러 개를 잡을 차례입니다 — 에이전트와 오픈클로에서 내가 없는 자리에서도 일이 돌아가게 만드는 구조를 다룹니다.
에이전트와 오픈클로 — 내가 없는 자리에서도 돌아가게
1교시 후반에 3주차의 메인 주제가 나왔습니다. 에이전트입니다. 참가자에게서 가장 먼저 나온 질문도 여기였습니다 — "오픈클로랑 클로드 코드랑 뭐가 달라요?" 이미 설치해 본 사람조차 아직 헷갈린다고 했습니다.
이 문서는 그 질문에 대한 1교시의 답과, 실제로 이것이 무엇을 바꾸는지를 정리한 것입니다. 설치와 실습은 2교시에서 이어집니다.
한 줄로
클로드 코드가 엔진이라면, 오픈클로는 그 엔진을 얹은 비서입니다. 같은 능력을 쓰지만 부르는 자리가 터미널에서 채팅창으로 옮겨 갑니다.
1교시에서 다룬 범위
1교시는 개념과 예고까지입니다. 왜 이것이 필요한지, 무엇이 가능해지는지를 먼저 그려 두고, 실제 설치·연결은 2교시로 넘겼습니다.
진행자가 이유를 분명히 했습니다 — "이번 주에 뭘 할 건지 한 번 다 보여 줘야, 그다음에 무엇을 하겠구나 하고 인지가 된다." 이 문서 자체가 그 예고편에 해당합니다.
①클로드 코드와 오픈클로 — 무엇이 다른가
진행자의 비유는 자동차였습니다.
클로드 코드
엔진 · 심장
실제로 일을 하는 실행부입니다. 생각하고, 파일을 읽고 쓰고, 명령을 실행합니다. 다만 내가 터미널 앞에 앉아 있어야 시킬 수 있습니다.
오픈클로
비서 · 에이전트의 몸
그 엔진을 얹고 겉에서 사람과 대화하는 역할입니다. 채팅창에서 말을 받아 엔진에 넘기고, 결과를 다시 채팅으로 돌려줍니다.
그래서 달라지는 것은 능력이 아니라 자리입니다. 지금은 노트북을 열고 터미널을 켜야 시킬 수 있지만, 오픈클로를 붙이면 슬랙이나 디스코드에서 이름을 부르는 것으로 같은 일을 시킬 수 있습니다.
진행자는 실제 사례를 들었습니다 — 주말에 밖에 나가 있는 동안에도 채팅으로 작업을 걸어 두고 결과를 받아 봤다고 합니다.
②세션 하나가 아니라 봇 여러 개
차이는 하나 더 있습니다. 클로드 코드는 필요할 때마다 세션을 여는 방식입니다. 오픈클로는 봇을 원하는 만큼 미리 만들어 두는 방식입니다.
진행자는 개인적으로 봇 세 개를 운영 중이라고 공유했습니다. 각각 다른 역할이 지정돼 있고, 필요에 따라 골라 쓰거나 함께 씁니다.
쓰임 1링크를 던져 두는 곳
읽고 싶은 글이나 영상 링크를 봇에게 그냥 던져 둡니다. 봇이 안에 들어가 내용을 분석하고 이해해서 맥락을 갖고 있습니다. 나중에 "그때 그거 뭐였지?" 하면 설명해 줍니다. 자기 자신에게 카카오톡으로 링크를 보내 두던 습관을 대체하는 용도입니다.
쓰임 2봇끼리 토론하게 하는 것
봇 하나에게 시키면 그 하나가 파악한 만큼만 나옵니다. 둘 이상에게 같은 주제를 놓고 토론하게 하면, 서로 주고받으며 평가하고 더 뽑아낼 것을 찾아냅니다. 진행자는 중간중간 끼어들어 결정을 내려 준다고 했습니다.
쓰임 3정해진 시간에 반복시키는 것
"아침마다 이것 좀 해 줘" 같은 반복 작업을 미리 걸어 둡니다. 이것을 스케줄링 · 크론이라고 부릅니다.
여러 봇이 서로 대화하며 결과를 만드는 이 구조를 요즘은 에이전트 그래프라고 부릅니다. 진행자의 설명은 간단했습니다 — "사람이 원래 그렇게 일하잖아요. 그런 것들을 하게끔 만드는 겁니다."
③병렬은 방치가 아니다
여러 개를 걸어 두는 이야기가 나오면 "그럼 손 떼고 있어도 되나"가 따라옵니다. 진행자는 그 지점을 명확히 잘랐습니다.
실제 사례가 공유됐습니다. 팀에서 금요일부터 월요일까지 60여 시간을 연속으로 돌린 작업이 있었는데, 그것이 그냥 돌아가서 나온 결과가 아니었다는 것입니다.
"그냥 되는 게 아니라 중간중간에 들어가서 체크하고, 맞는지 오케이 해 주고 — 그 정도는 해 줘야 됩니다. 알아서 나오면 알아서 안 되거든요."
1교시 · 장시간 작업에 대해
그래서 사람의 역할이 사라지는 것이 아니라 옮겨 갑니다. 직접 만드는 자리에서 결과를 받아 보고 판단하는 자리로 이동합니다. 이것이 보는 눈이 이번 주 주제인 이유이기도 합니다.
④봇을 길들이는 법
봇도 처음부터 잘하지는 않습니다. 진행자의 표현은 "사람이랑 똑같다"였습니다.
처음
설정이 안 돼 있으면 시켜 봐야 잘 못합니다
→
계속
피드백을 주고 설정을 만져 가며 학습시킵니다
→
쌓이면
맥락이 쌓여 시켰을 때 알아서 잘 해냅니다
봇끼리도 규칙이 필요하다
재밌는 사례가 하나 나왔습니다. 한 참가자의 봇이 진행자의 봇에게 도움을 요청했는데 답이 없었다는 것입니다. 고장이 아니라 설계였습니다.
그 봇은 응답할 대상이 지정돼 있습니다. 지정된 팀원에게는 답하지만, 다른 봇이 요청한다고 해서 무조건 답하지는 않습니다. 이유는 명확합니다 — 봇끼리 너무 왔다 갔다 하면 맥락이 계속 쌓이고 시간과 비용이 늘어납니다. 그래서 "누구에게 답하고 누구에게는 답하지 않는가"를 미리 정해 둡니다.
여기서 나온 또 한 가지 이야기 — 칭찬하는 프롬프트도 실제로 있습니다. 다만 효과는 사람의 성향에 따라 갈리고, 봇에게는 사용자별 기억이 쌓이는 방식으로 작동합니다. 고맙다는 말을 주고받는 것도 그 자체가 대화이므로 토큰을 쓴다는 점은 감안해야 합니다.
⑤2교시 예고 — 설치부터 슬랙봇까지
1교시 마지막에 이번 주의 진행 방식이 공유됐습니다. 예전에는 2~3시간짜리 워크샵으로 하나씩 설치하며 했지만, 이번에는 30분 안에 설치를 끝내고 그다음으로 넘어가는 방식입니다. 설치 자체가 중요한 것이 아니기 때문입니다.
STEP 1
가이드 문서 붙이기
클로드 코드 새 세션에 가이드 문서를 붙여 넣는 것으로 시작합니다. 체크리스트가 뜨면 "1번부터" 한 마디면 됩니다.
STEP 2
설치 · 게이트웨이
런타임 → 오픈클로 → 클로드 코드 순서로 올립니다. 최소 구성으로 먼저 띄우고 채널·스킬은 나중에 붙입니다.
STEP 3
슬랙 앱 · 연결
슬랙 앱을 만들고 토큰을 연결합니다. 토큰은 문서 밖 비밀 파일에만 둡니다.
STEP 4
기반 닦기 · 동작 확인
봇의 정체성을 파일로 잡고, 재시작한 뒤 슬랙에서 이름을 불러 답이 오는지 확인합니다.
STEP 5
LLM Wiki
흩어진 지식을 한곳에 모아 두고, 봇이 먼저 그곳을 찾아보게 만듭니다. 근거를 들고 답하게 하는 구조입니다.
도착점
노트북 없이도
터미널 → 챗 플랫폼으로 자리를 옮겨, 비서처럼 시킬 수 있는 상태까지가 이번 주 목표입니다.
출처 표시 — 위 5단계와 아래 구조도는 3주차 교안덱에 예고된 실습 범위입니다. 1교시 수업에서는 개념과 예고까지만 다뤘고, 실제 설치·설정 과정은 2교시 기록에서 다룹니다.
오픈클로의 구조 — 미리 보는 세 덩어리
교안덱은 오픈클로를 세 부분으로 나눠 설명합니다. 설치하며 마주칠 이름들이니 미리 짚어 둡니다.
구성
역할
쉽게 말하면
게이트웨이
항상 켜져 있으면서 채팅에서 온 말을 받는 자리
사무실 접수 창구
에이전트
클로드 코드와 연결돼 실제로 일을 하는 실행부
실제로 일하는 직원
워크스페이스
봇이 누구이고 무엇을 기억하는지 담아 두는 기반 파일들
그 직원의 신분증과 업무 노트
워크스페이스 안에 들어가는 파일 이름은 다음과 같습니다.
SOULIDENTITYMEMORYHEARTBEATTOOLS
교안덱은 새 봇을 빈손에서 시작하지 않게 하는 방법도 함께 제시합니다 — 이미 잘 다듬어진 봇에게서 구조를 전수받는 것입니다. 기반 파일 구조 · 메모리와 템플릿 패턴 · 동료 봇과의 소통 규칙을 그대로 물려받아 시작하면 처음부터 다시 길들일 필요가 없습니다.
⑥넘어가기 전에 — 안전 원칙 하나
봇이 대신 일해 주는 범위가 넓어질수록 이 원칙이 중요해집니다. 1교시에서 실제 사고 경험과 함께 못 박힌 내용입니다.
"메일 같은 것들은 자동으로 보내면 안 됩니다."
1교시 · 자동화의 경계
초안을 쓰고, 정리하고, 확인 화면까지 만드는 것은 맡겨도 됩니다. 하지만 바깥으로 나가는 마지막 동작은 사람이 확인하고 누르는 것으로 남겨 둡니다. 되돌릴 수 없는 일일수록 그렇습니다.
⑦1교시가 끝나는 지점 — 실습 준비
1교시는 이번 주 실습 파일을 각자 내려받는 것으로 마무리됐습니다. 진행자가 슬랙에 공유한 스터디 아카이브를 받아, 자기 폴더에 풀고 터미널로 그 안에 들어가는 데까지가 준비였습니다.
1
슬랙에 공유된 스터디 아카이브를 내려받는다
→
2
평소 코드를 관리하는 폴더나 로컬 한곳에 풀어 둔다
→
3
터미널을 열고 그 폴더로 이동해 클로드 코드를 켠다
cd <스터디 아카이브를 풀어 둔 경로>
claude
이번 주 과제가 여기서 정해집니다 — 오늘 수업의 교안을 각자 직접 만들어 보는 것입니다. 그래서 진행자가 수업 시작부터 "오늘 녹음을 꼭 켜 두라"고 강조했던 것입니다. 녹음이 없으면 만들 재료가 없기 때문입니다. 지금 보고 있는 이 문서가 바로 그 과제의 결과물입니다.
터미널 창을 하나 더 여는 단축키는 Cmd + T입니다. 대부분의 터미널 앱에서 같습니다.
3주차 1교시 강의기록
2026년 8월 2일 오전에 진행된 AX 스터디 3주차 1교시의 기록입니다. 녹음 2시간 8분 분량을 시간 순서대로 정리했습니다.
지난 과제를 함께 열어 보며 "만들어졌다"와 "이해했다"의 차이를 확인하고, 쥔 것을 놓아야 다음을 쥔다는 이번 주 주제로 넘어간 시간.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다.
참가자는 스터디 내 호칭까지만 표기하고 실명·소속·직함은 쓰지 않았습니다. 진행자 이름도 표기하지 않습니다. 회사 내부 사정·인사·경영에 관한 대화 구간은 대외 공개를 고려해 교안에서 제외하고, 그 자리에 제외 표시를 남겼습니다.
①도입 — 오늘 녹음을 꼭 켜야 하는 이유 00:00 – 00:04
00:00
"오늘 녹음을 켜셔야 합니다"
수업은 진행자가 참가자들에게 녹음이 켜져 있는지 확인하는 것으로 시작했습니다. 이번 주에는 교안을 각자 직접 만들어 보는 것이 과제이고, 진행자가 만든 교안을 나눠 주지 않기 때문입니다. 녹음이 없으면 만들 재료가 없습니다.
"오늘 켜셔야 제가 그 교안 만드는 걸 같이 해 보면서 갈 겁니다. 없으시면 안 나와요. 직접 만드셔야 되는 겁니다."
00:00
2주차 과제가 무엇이었는지 다시 정리
진행자가 지난 과제의 목적을 다시 짚었습니다. 1~2주차에 배운 것들을 이어 붙여, 자기 목적에 맞는 결과물을 한 번 끝까지 만들어 보는 것이었습니다.
피그마 MCP로 결과물을 옮겨 본다
디자인 전문가가 아니므로 UI 레퍼런스를 활용한다
코덱스 CLI로 이미지를 뽑아 함께 쓴다
조건은 두 가지였습니다. 결과물이 마음에 안 들어도 괜찮으니 일단 시도할 것, 그리고 주차가 넘어가면 발전이 보여야 할 것. 진행자는 "똑같으면 어떡해요"라는 말로 후자를 강조했습니다.
②설명하는 순서 — 배경 · 맥락 · 목적 00:04 – 00:07
00:04
두 사람의 설명 방식이 비교되다
과제 발표에 들어가기 전, 두 사람의 설명 방식이 자연스럽게 비교됐습니다. 한 사람은 무엇을 만들었는지부터, 다른 한 사람은 어떤 배경에서 이 과제를 하게 됐는지부터 말했습니다.
진행자는 후자가 훨씬 이해하기 쉬웠다고 평가하며, 차이가 배경 → 맥락 → 목적의 순서에 있다고 정리했습니다. 그리고 곧바로 AI 쪽으로 연결했습니다.
"AI한테도 그렇게 설명을 잘해야 됩니다. 맥락을 다 빼놓고 설명하면 내가 뭘 만들어 주길 바라는지 모르니까 — 모호할수록 결과는 잘 안 나옵니다."
진행자는 또 하나를 덧붙였습니다. 남의 말을 먼저 끝까지 들어 보라는 것입니다. 내 입장을 말하기 전에 상대가 어떻게 하는지 듣고, 그다음에 이야기하라는 조언이었습니다.
③동현 님 과제 — 부모님 음식점 사이트 00:07 – 00:30
00:07
주제가 정해진 계기
만들고 싶은 사이트가 딱히 떠오르지 않던 차에 가족의 제안으로 주제가 정해졌습니다. 부모님이 운영하시는 음식점을 소개하는 사이트였고, 마침 부모님도 홍보용으로 하나 있으면 좋겠다고 하시던 참이었습니다.
00:08
자료를 AI에게 찾게 하고, 레퍼런스로 방향을 잡다
가게가 예전에 TV 프로그램에 소개된 적이 있다는 사실만 알려 주고 해당 영상을 찾아내게 했습니다. 찾은 영상에서 이미지를 캡처하고 쓸 만한 문구를 골라내게 한 것이 출발점이었습니다.
그런데 첫 피그마 결과물이 기대한 그림과 달랐습니다. 원인은 UI 레퍼런스를 제대로 짚어 주지 않은 것이었습니다. 그래서 같은 업종의 사이트를 검색해 레퍼런스로 지정하고, 그 안의 요소를 하나씩 추출해 참고하도록 다시 시켰습니다. 문구는 "장인정신이 느껴지는 느낌"으로 요청했습니다.
이미지 화질이 떨어지는 문제는 고화질로 다시 캡처하게 하고 코덱스 CLI를 함께 써서 보완했습니다. 영상을 프레임 단위로 쪼개 쓰는 방법도 여기에 적용했습니다.
00:11
"커버만 봤어요" — 1교시의 결정적 장면
진행자가 피그마 왼쪽의 페이지 목록을 열어 보게 했습니다. 데스크톱 화면 외에도 모바일 화면 · 파운데이션 · 컴포넌트 등 여러 페이지가 이미 만들어져 있었는데, 본인은 커버 한 장만 확인한 상태였습니다.
"화면으로만 띄워 준 줄 알았다"는 것이 이유였습니다. 진행자의 지적은 결과물의 완성도가 아니라 다른 곳을 향했습니다.
"결과는 만들어져 있는데, 본인이 그걸 이해했느냐 안 했느냐가 중요한 겁니다. 솔직함이 중요합니다."
본인이 그 자리에서 "솔직히 몰랐다"고 인정하자, 진행자는 그 솔직함을 오히려 긍정적으로 평가했습니다.
00:16
시키지 않았는데 나온 것들 — 에이전트에 역할을 나눠 준 결과
디자인 시스템 문서가 왜 나왔는지에 대한 질문이 나왔고, 답은 페르소나 설정이었습니다. "UI/UX 전문 웹 에이전시의 스쿼드를 구성하라"고 지시하고 기획자 · 디자이너 · 개발자 역할을 각각 부여했으며, "100점 만점에 95점 기준으로 평가하라"는 품질 기준까지 넣었습니다.
결과적으로 디자이너 역할을 맡은 에이전트가 스스로 파운데이션과 컴포넌트를 만들어 낸 것이었습니다. 진행자는 "그런 건 꼭 과제를 설명할 때 같이 이야기해야 한다"며, 중요한 과정을 빼놓고 설명한 점을 짚었습니다.
00:17
디자인 시스템이 무엇인지 설명하다
진행자가 개념을 풀어 설명했습니다. 디자인 시스템은 디자인·개발·프로덕트를 하나의 기준으로 묶는 협업 문서이자 시스템이며, 색과 타이포그래피를 토큰화해 규칙으로 만들어 두면 한 곳을 바꿀 때 쓰인 곳이 모두 함께 바뀝니다. 쌓는 순서는 바텀업입니다 — 색 → 컴포넌트 → 화면.
개념을 모르면 규칙을 세우지 않고 값을 화면마다 직접 써 넣게 되고, 문서는 따로 있는데 실제 시안은 문서를 안 따르는 상태가 되기 쉽다는 설명도 함께 나왔습니다.
결과물에 대한 평가는 높았습니다. 디자인을 전공한 참가자도 "고연차 디자이너가 한 것 같다"고 했고, 진행자는 AI 없이 이 정도를 맡기려면 상당한 비용이 들었을 것이라고 했습니다.
00:22
모바일 화면은 개발자 도구로 확인한다
사이트가 모바일에서 어떻게 보이는지 확인하는 방법이 즉석에서 안내됐습니다. 맥에서는 Cmd + Option + I, 또는 크롬 메뉴의 도구 더보기 → 개발자 도구. 열린 창에서 기기를 iPhone 등으로 바꿔 보면 됩니다.
00:24
평가 — 10점 만점에 9.5점
진행자는 결과물을 보며 "어떤 과정을 거쳤는지가 느껴진다"고 했습니다. 점수의 이유는 세 가지였습니다.
동기가 진짜였다 — 과제로 끝낼 생각이 아니라 실제로 만들어 드리고 싶어서 한 일. 하고 싶은 것을 찾으면 시키지 않아도 알아서 한다
한 단계 더 갔다 — 피그마에서 멈추지 않고 HTML 사이트까지 만들었다
할 것을 빼먹지 않았다 — 영상 관련 실습도 함께 해 왔다. 재밌는 것만 하고 해야 할 것을 건너뛰었다면 점수가 깎였을 것
본인의 한 줄 회고는 "AI를 활용하는 데 있어서 생각하는 방식이 늘었다"였습니다. 여러 스킬을 직접 써 볼 수 있었던 점을 가장 좋았던 것으로 꼽았습니다.
00:29
후속 숙제 — 끝난 세션을 스킬로 남길 것
진행자가 숙제를 하나 붙였습니다. 작업이 끝난 세션을 그냥 닫지 말고, "지금까지 넣은 프롬프트와 이어진 맥락을 바탕으로 재사용 가능한 스킬을 만들어 달라"고 요청해 두라는 것입니다.
세션을 이미 닫았다면 resume으로 되살릴 수 있고, 세션을 찾기 어려우면 "이런 내용을 이야기한 세션이 있을 텐데 그 ID를 찾아 달라"고 하면 찾아 준다는 안내가 이어졌습니다.
④주리 님 과제 — 리뷰 설명 지원 스킬 00:30 – 00:52
00:30
무엇을 만들었나
기획자로서 리뷰할 때 전체 맥락을 구조적으로 먼저 설명하는 것이 부족하다는 자각에서 출발한 과제였습니다. 만든 것은 "이지 익스플레인"이라는 스킬입니다.
리뷰할 목업이나 기획 문서를 넣으면 말할 대본 · TTS 음성 · 보면서 확인하는 화면이 나옵니다. 왼쪽에 설명할 문서, 오른쪽에 확인용 문서를 띄우고 설명을 연습할 수 있습니다. 리뷰가 끝난 뒤에는 녹취를 넣으면 회고 문서가 나오고, 그것이 다음 리뷰 준비의 입력이 됩니다.
대본은 다섯 칸으로 구조를 고정했습니다.
① 여기까지 온 이야기 — 지난 리뷰에서 어떤 이야기가 있었고 무엇이 반영됐는지
② 전체 그림 — 오늘 리뷰할 것이 몇 가지이고 서로 어떻게 이어지는지
③ 하나씩 — 항목별 결론 → 이유 → 예시
④ 그래서 달라지는 것 — 듣는 사람 입장에서 무엇이 바뀌는지
⑤ 예상 질문 — 나올 만한 질문과 답
00:33
만드는 과정 — 전사 8시간과 방향 수정
먼저 과거 리뷰 전사 약 8시간 분량을 통째로 넣고, "다른 세션이나 메모를 보지 말고 이 전사만 보고" 내 리뷰의 문제점과 말버릇을 찾아 달라고 했습니다. 범위를 좁혀 준 덕분에 지적이 정확했습니다.
그런데 스킬을 만드는 단계에서 방향이 어긋났습니다. AI가 이 과제를 "회의가 끝난 뒤 팀에 공유하는 문서를 만드는 일"로 이해한 것입니다. 실제 목적은 리뷰 전에 설명을 준비하고 리뷰 후에 회고하는 것이었습니다. 결과물을 고치는 대신 맥락을 더 넣어 방향을 되돌렸고, 본인은 이 과정에서 "맥락을 정말 많이 빼먹었구나"를 다시 느꼈다고 했습니다.
문체는 규칙으로 못 박았습니다 — 추상적 표현 금지 · 비유 쓰지 않기 · 근거를 들 것 · 정해진 표기를 따를 것.
00:38
실제로 들어 보다
만든 결과물을 자리에서 재생해 함께 들었습니다. 문서의 어느 부분을 중심으로 설명해야 하는지, 위험이 발견되는 지점이 몇 군데인지, 어떤 질문이 나올 수 있는지가 순서대로 나왔습니다.
본인은 눈으로 읽는 것과 듣는 것이 확실히 달랐다고 했고, 다른 참가자는 "팟캐스트 듣듯이 하면 이해가 쏙쏙 된다", "출근할 때 한 번 듣고 스크럼에 들어가면 되겠다"는 반응을 보였습니다.
00:43
동료 피드백 — 영업 설명에도 쓸 수 있다
다른 참가자가 자기 상황에 대입해 피드백했습니다. 영업에서도 고객사에 설명할 일이 많은데, 자기 말버릇을 인지는 해도 어떻게 고쳐야 할지 몰랐다는 것입니다. 사람마다 자주 쓰는 말버릇이 있고, 의식하면 오히려 말이 꼬이기도 합니다.
그래서 녹음을 들으며 스스로 점검하는 것은 버티기 힘든 일인데, AI가 대신 듣고 짚어 주니 그 부담이 사라진다는 점을 장점으로 꼽았습니다. "이건 나도 내 스타일대로 구현해서 써도 괜찮겠다"는 것이 결론이었습니다.
00:45
본인의 회고 — 직면하는 시간
한 줄 회고를 요청받자 본인은 요약이 원래 어렵다는 이야기부터 나왔습니다. 진행자도 "자기가 한 것을 한 줄로 줄이는 게 원래 어렵다"고 동의했습니다.
"내 말버릇이나 내가 부족한 부분을 직면하는 게 되게 어렵잖아요. 회피하게 되고. 그런데 직면도 하는 그런 시간이었어요."
또 하나 얻은 것은 말할 때 구조를 그리는 감각이었습니다. 배경 · 전체 구조 · 세부 · 질문으로 나눠 정리하다 보니, 말을 할 때도 구조가 조금씩 그려지기 시작했다고 했습니다.
00:46
평가 — 10점 만점에 9점, 그리고 순서에 대한 지적
결과물과 준비 과정은 잘 갖췄다는 평가였습니다. 다만 설명하는 방식에서 아쉬움이 지적됐습니다.
"차라리 결과물을 먼저 보여 주고 난 뒤에 설명하셨으면 훨씬 잘 이해됐을 거예요. 그러면 듣는 사람도 '이 결과물이 나오기 위해서 이런 걸 했구나' 하고 인지가 되거든요."
함께 듣던 참가자도 "처음에는 무슨 말인지 이해가 안 갔는데 화면을 보여 주니까 딱 이해가 됐다"고 같은 반응을 말했습니다. 대본에 남아 있는 추상적 표현과 문체는 반복 피드백으로 다듬어야 하는 것으로 정리됐습니다.
점수가 0.5점 낮은 이유도 솔직하게 공유됐습니다. 두 사람의 출발선이 다르기 때문입니다. 이미 같은 방식으로 일해 온 사람에게는 기대치가 높고, 처음 해 본 사람에게는 시도 자체가 더 크게 평가된다는 뜻이었습니다.
⑤3주차 학습 방향 안내 00:52 – 01:00
00:52
세 주차의 위치
진행자가 3주차가 어디에 있는지 정리했습니다.
주차
무엇을 했나
1주차
AI 시대에 무엇을 할 수 있는지 경험했다
2주차
내가 실제로 할 수 있는 것을 직접 만들어 봤다
3주차
이것을 일상과 업무에 통합하고, 보는 눈을 기른다
이번 주에 다룰 것으로 오픈클로 설치 · 슬랙봇 · 스케줄링 · AI가 잘 찾아가게 정리하는 방법(LLM Wiki)이 예고됐습니다. 설치는 30분 안에 끝내고 넘어가는 방식입니다 — "설치하는 게 중요한 건 아니거든요."
00:54
"오픈클로랑 클로드 코드랑 뭐가 달라요?"
참가자에게서 나온 질문이었습니다. 이미 설치해 본 사람조차 아직 헷갈린다고 했습니다. 진행자의 답은 이랬습니다.
"클로드 코드가 심장이고 엔진이고, 겉에서 에이전트 역할을 하는 봇 — 비서 역할을 해 주는 게 오픈클로라고 생각하면 됩니다."
이어서 실제 활용 방식이 공유됐습니다. 진행자는 개인적으로 봇 세 개를 운영하고 있고, 링크를 던져 두면 봇이 들어가 분석하고 맥락을 갖고 있습니다. 나중에 "그때 그거 뭐였지?" 하면 설명해 줍니다.
봇 하나가 아니라 둘 이상이 토론하게 할 수도 있습니다. 서로 주고받으며 평가하는 구조를 만들어 두는 것입니다.
00:56
1주차 세 원칙 복기
진행자가 참가자에게 직접 물어 세 가지를 확인했습니다 — ① 기존 방식을 내려놓는다 ② 일단 매일 해 본다 ③ 호들갑에 휘둘리지 않는다.
이어서 오늘 다룰 것을 예고했습니다. 내려놓는 것 · 보는 눈을 기르는 방법 · 오픈클로와 슬랙봇 · AI가 잘 찾아가게 하는 것까지입니다.
00:58
세션에서 봇으로 — 그리고 스케줄링
웹에서 한 땀 한 땀 쓰던 것이 클로드 코드로 편해졌다면, 한 단계 더 들어간 것이 에이전트라는 설명이었습니다. 클로드 코드는 필요할 때마다 세션을 열지만, 오픈클로는 봇을 원하는 만큼 만들어 역할을 지정해 둡니다.
그리고 기기를 계속 붙잡고 있을 수 없으니, 주기적으로 반복할 수 있는 스케줄링이 필요합니다. 개발에서 크론(cron)이라고 부르는 것입니다.
⑥과도기의 어려움 — 실제로 겪은 이야기 01:00 – 01:18
01:00
"내려놓는다"가 실제로는 얼마나 어려운가
진행자가 손에 든 물건을 들어 보이며 "이걸 내려놔야 다른 걸 집을 수 있다"고 설명하자, 참가자 한 사람이 요즘 겪는 어려움을 꺼냈습니다. 1교시에서 가장 길게 이어진 대화입니다.
업무가 산만해진다 — 새 방식이 자리 잡기 전까지는 예전 방식도 계속 돌려야 한다. 일은 계속 들어오는데 한쪽에서 새 도구를 익히니 머리가 아프다
주변이 함께 움직이지 않는다 — 필요성을 못 느끼는 동료에게는 "굳이 왜?"가 먼저 나온다. 좋은 것을 공유해도 자랑처럼 비칠까 조심스러워진다
실수가 더 크게 보인다 — 평소였으면 넘어갔을 실수도 "AI 써서 실수했네"가 된다
비용에서 벽을 만난다 — 월 십수만 원 앞에서 대화가 멈춘다
"혼자 하는 건 결국 외롭겠다. '사람 병목'이라는 말이 너무 절실히 느껴졌어요. 나 혼자서는 안 되는 거야."
01:05
진행자의 답 — 과도기는 원래 거칠다
진행자는 공감하면서도 시점을 짚었습니다. "할 거면 다 같이 하든지, 아니면 하지 말든지"가 맞지만, 함께하지 않겠다는 선택 역시 각자의 몫이라는 것입니다.
중요한 것은 언제 인정받는가였습니다. 지금 말해 봐야 조직은 움직이지 않고, 성과가 눈에 보이기 시작할 때 비로소 필요성이 인정됩니다. 그러니 그때까지는 계속 쓰면서 익숙해지는 기간으로 삼으라는 조언이었습니다.
비용 이야기에서는 "가치를 느껴야 투자가 되는데 지금은 가치를 못 느끼는 단계"라는 진단이 나왔습니다. 스터디를 하겠다는 사람들에게 "일단 결제부터 하시라"고 말한 것도 같은 맥락이었습니다 — 그 정도 마음가짐이 있어야 시작된다는 뜻입니다.
01:09
왜 어렵게 느껴지는가 — 옆에서 알려 주는 사람이 없어서
터미널이 어려워 보이는 이유에 대해 진행자가 물었고, "안 하던 것이니까"라는 답이 나왔습니다. 진행자는 여기에 하나를 더했습니다 — 옆에서 붙어 알려 준 사람이 없었기 때문입니다.
실제로는 "웹에 치는 거랑 똑같다"고 하며 옆에서 한 번만 같이 해 보면 되는 일인데, 그 계기가 없었을 뿐이라는 것입니다. 진행자 자신도 처음엔 머리가 아팠지만 한 달만 붙어 있으면 오히려 웹으로 들어가는 게 불편해진다고 했습니다.
01:09
안전 원칙 — 메일은 자동으로 보내지 않는다
AI를 쓰면서 의도치 않게 메일이 잘못 나간 경험이 공유됐고, 진행자가 곧바로 못 박았습니다.
"그래도 자동으로 보내면 안 돼요. 메일 같은 것들은."
01:16
도구 하나로는 부족하다
클로드 코드만으로는 막히는 지점이 있고, 코덱스와 이미지 리소스를 함께 붙여야 가능한 범위가 넓어진다는 이야기가 이어졌습니다. 실제로 참가자도 "코덱스가 없었으면 너무 힘들었을 것 같다"고 했습니다.
진행자는 여기에 중요한 지적을 덧붙였습니다. 여러 도구를 이어 붙일 수 있다는 사고 자체가 생기는 것이 어렵다는 것입니다. 어떤 팀은 클로드 코드를 쓰면서도 이미지는 여전히 웹에서 하나하나 뽑습니다 — 연결하는 방법을 몰라서입니다. "그 하나에 대한 사고가 생기는 게 쉽지가 않다. 혼자서 어떻게 알겠어요."
⑦교안 제외 구간 01:18 – 01:48
01:18 – 01:48
회사 내부 사정에 관한 대화 — 교안에서 제외
이 구간은 회사의 장비 지원 · 조직 운영 · 경영 판단 · 특정 구성원에 대한 평가 등 내부 사정에 관한 대화였습니다. 이 자리에서 결정된 사항이나 후속 조치는 없었고, 개인 의견을 나눈 수준이었습니다.
대외 공개를 고려해 교안에서는 제외합니다. 원본 전사는 week3/transcripts/3주차-1교시-전사.txt 에 그대로 보존돼 있습니다.
⑧한비자와 내려놓기, 그리고 보는 눈 01:48 – 01:58
01:48
멘토에게 받은 책
진행자가 오랫동안 멘토링을 받아 온 분의 이야기를 꺼냈습니다. 오래 경력을 쌓은 분으로, 3개월 과정에 월 100만 원이라는 비용이 들었다고 공유했습니다. 참가자들이 놀라자 진행자는 이렇게 정리했습니다 — 배울 수 있는 인사이트만 가져가면 되고, 그 사람의 코어만 받아 가면 그것이 최선이라는 것입니다.
그 멘토가 선물한 책이 『한비자』였습니다. 서양에 마키아벨리가 있다면 동양에는 한비자가 있다고 말해지는 고전으로, 법과 통치를 다루되 우화 형태로 풀어써서 읽기 쉽게 만든 책이라고 소개됐습니다.
01:54
"쥔 것을 놓아야 된다"
진행자가 그 책에서 이번 주 주제와 이어지는 대목을 꺼냈습니다.
"쥔 것을 놓아야 된다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 된다. 내가 지고 있는 것들을 내려놓을 수 있어야 다음을 낼 수 있어요. 영향을 키우려면 자기가 내려놓을 줄도 알아야 되는 게 지금 시대에 더 그런 것 같습니다."
01:55
"시키기만 하고 끝나면 진짜 바보가 된다"
여기서 1교시의 무게중심이 옮겨갔습니다. 진행자가 AI를 오래 쓴 사람들이 공통으로 겪는 현상을 꺼냈습니다.
"점점 내가 바보가 된다는 느낌이 들거든요. 두세 달 지나면 옵니다. 그때 자기가 알아야 돼요 — 얘를 통해서 더 잘 아는 걸 가지고 판단할 수 있는 능력을 키운다고 생각해야지, 얘한테 시키고 실행만 시키고 끝나 버리면 진짜 바보가 된다고 느껴요."
같은 자리에서 다른 참가자도 "진짜 바보 되고 있어요"라고 맞장구쳤습니다.
대안은 간단했습니다. 결과를 받고 끝내지 말고 "왜 이렇게 해 놨는지" 물어보는 것입니다. 앞에서 본 피그마 디자인 시스템이 그대로 예시가 됐습니다 — 물어보면 설명해 주고, 그 설명을 이해하는 순간 그 직군이 어떻게 일하는지를 알게 됩니다.
01:56
판단 기준을 늘린다 · 몰입에서 병렬로
진행자는 "보는 눈"을 실무적인 말로 바꿨습니다. 의사결정의 질은 내가 가진 기준의 개수에 달려 있다는 것입니다. 기준을 늘리려면 데이터가 많거나, 직접 해 보고 결과의 차이를 확인해야 합니다.
여기에 AI가 하는 동작 하나를 사람도 따라 하라는 조언이 붙었습니다 — AI는 결과를 주면서 "다음엔 이걸 하면 좋겠다"고 제안합니다. 관리자와 경영진은 그런 사람을 좋아합니다.
일하는 방식도 달라집니다. 예전에는 하나에 몰입해 끝냈다면, 이제는 여러 개를 병렬로 걸어 두고 사람은 판단과 집중할 몇 가지에 남는 방식입니다. 두 참가자 모두 "이건 어렵다"고 했고, 진행자는 "그래서 격차가 점점 커진다"고 답했습니다.
⑨트렌드와 봇 운영 01:58 – 02:05
01:58
하네스를 걷어낸다
진행자가 "따라갈 만한 트렌드"로 꼽은 것은 더 얹는 것이 아니라 걷어내는 것이었습니다. 예전 모델은 그냥 두면 엉뚱한 답을 내놓았기 때문에 규칙을 촘촘히 짜 두는 것이 실력이었지만, 모델이 충분히 좋아진 지금은 그 규칙이 오히려 발목을 잡는 경우가 생깁니다.
"지금 만들어 놓은 하네스 자체가 병목이다. 절대 규칙이라고 만들어 놓은 것들이 오히려 방해가 돼서 결과에 영향을 끼친다고 얘기를 합니다. 있을 건 있으면서, 걷어낼 건 걷어내야 돼요."
01:59
호들갑에 휘둘리지 않기
세 번째 원칙이 구체적인 사례로 돌아왔습니다. 새 도구가 나올 때마다 "일주일 무료" 같은 이벤트가 돌고 사람들이 몰려가지만, 실제로는 환불이 안 되거나 결제가 이상하게 걸리는 문제가 보고되기도 합니다.
"그냥 호들갑 떠는 건 놔두고 — 내가 하려는 것을 명확하게 이해하는 게 중요해요."
02:00
병렬은 방치가 아니다 — 60여 시간 사례
팀에서 금요일부터 월요일까지 60여 시간을 연속으로 돌린 작업 사례가 공유됐습니다. 핵심은 그것이 그냥 돌아가서 나온 결과가 아니라는 점이었습니다.
"중간중간에 들어가서 체크하고, 맞는지 오케이 해 주고 — 그 정도는 해 줘야지, 알아서 나오면 알아서 안 되거든요."
사람이 항상 있을 수는 없으니 결과를 잘 받아 보고 판단해 주는 것이 사람의 역할이 됩니다. 그래야 오랜 시간을 돌려도 결과가 나옵니다.
이어서 요즘 트렌드로 오케스트레이션과 에이전트 그래프가 언급됐습니다. 여러 봇을 만들어 서로 토론하게 하고 결과를 만들어 내는 구조입니다 — "사람이 원래 그렇게 일하잖아요."
02:02
봇을 길들이는 법 · 봇끼리의 규칙
봇도 처음부터 잘하지 않습니다. "사람이랑 똑같다"는 것이 진행자의 표현이었습니다. 계속 피드백을 주고 설정을 만져 가며 학습시켜야 하고, 그렇게 맥락이 쌓이면 시켰을 때 알아서 잘 해냅니다.
칭찬하는 프롬프트도 실제로 있지만 효과는 사람의 성향에 따라 갈리고, 봇에게는 사용자별 기억이 쌓이는 방식으로 작동합니다. 고맙다는 말도 대화이므로 토큰을 쓴다는 점은 감안해야 합니다.
한 참가자의 봇이 진행자의 봇에게 도움을 요청했는데 답이 없었던 일이 화제가 됐습니다. 고장이 아니라 설계였습니다 — 그 봇은 응답할 대상이 지정돼 있어 다른 봇이 요청한다고 무조건 답하지 않습니다. 봇끼리 너무 왔다 갔다 하면 맥락이 계속 쌓이고 시간과 비용이 늘어나기 때문입니다.
02:04
LLM Wiki 예고
마지막으로 다룰 주제가 예고됐습니다. AI가 이해하기 좋게 정리해 두는 것입니다. 청킹 같은 개념이 언급됐지만, 진행자는 개념만 알면 되고 실제 처리는 AI가 알아서 하게 두면 된다고 정리했습니다.
⑩실습 준비 — 스터디 아카이브 내려받기 02:05 – 02:08
02:05
오늘의 목표를 한 번 더
"오늘 목표는 결국 내가 AI를 이용하면서 더 잘할 수 있도록 하는 것 — 2주차보다 한 단계 더 나아가서, 내가 없는 자리에서 더 하게끔 하고, 하루 종일 굴리고 밤새 돌게끔 하는 겁니다."
02:06
파일을 받고 터미널을 연다
진행자가 슬랙에 공유한 스터디 아카이브를 각자 내려받는 것으로 실습 준비가 시작됐습니다.
슬랙에 공유된 스터디 아카이브를 내려받는다
평소 코드를 관리하는 폴더나 로컬 한곳에 압축을 푼다
터미널을 열어 그 폴더로 이동하고 클로드 코드를 켠다
cd <스터디 아카이브를 풀어 둔 경로>
claude
터미널 창을 하나 더 여는 단축키는 Cmd + T라는 안내도 함께 나왔습니다. 진행자는 "이번 주 교안을 직접 만드는 것"이 목적임을 다시 확인했습니다.
02:08
1교시 종료
녹음 설정을 정리하며 1교시가 마무리됐습니다. 화자 수 설정이 실제 인원과 다르게 잡혀 있는 것을 확인하고 3명으로 바꾸면 다시 계산된다는 안내가 있었습니다. 이후 실습은 2교시로 이어집니다.
원본 전사는 week3/transcripts/3주차-1교시-전사.txt 에 그대로 보존돼 있습니다. 이 기록은 그 전사를 근거로 작성했으며, 전사에 없는 내용은 추가하지 않았습니다. 명백한 음성 인식 오류(예: 교안 · 컨텍스트 · 코덱스 CLI 등)는 문맥에 맞게 교정했고, 확신할 수 없는 고유명사는 일반 표현으로 바꾸거나 생략했습니다.
오픈클로 설치와 슬랙봇 연동 — 2교시 실습
1교시에서 개념으로 그려 둔 것을 실제로 설치해 본 시간입니다. 참가자 한 사람의 개인 슬랙에 봇을 하나 만들어, 클로드 코드와 연결하고, 슬랙에서 이름을 불러 답이 오는 데까지 진행했습니다.
진행자가 시작부터 못 박은 것이 있습니다 — 설치 과정을 한 단계씩 다 이해하는 것이 목적이 아니라는 것입니다.
진행 방식
설치를 한 땀 한 땀 따라가면 두세 시간이 걸립니다. 그래서 가이드 문서를 통째로 넘겨 AI가 설치하게 하고, 사람은 "이걸로 무엇을 할 수 있는가"에 시간을 쓰는 방식으로 진행했습니다.
2교시 앞부분 요약
설치 자체는 가이드 문서 한 장을 클로드 코드에 붙여넣는 것으로 시작합니다. 나머지는 대부분 AI가 처리하고, 사람이 하는 일은 슬랙 쪽 설정(앱 생성 · 권한 · 토큰)과 막혔을 때 상황을 설명해 주는 것입니다.
실습 중 실제로 막힌 지점도 그대로 겪었습니다 — 게스트 권한이라 앱 설치가 안 되고, 설정을 바꾼 뒤 재설치를 해야 반영되고, 봇 이름 때문에 엉뚱한 단어에도 반응하는 문제가 차례로 나왔습니다. 이 문서는 그 과정을 순서대로 정리한 것입니다.
①왜 슬랙에 붙이는가 — 로컬의 한계
2교시에서 가장 여러 번 반복된 질문이 이것이었습니다. "오픈클로도 자체 웹 화면이 있는데, 왜 굳이 슬랙에 붙이나?"
답은 로컬이라는 말에 있습니다. 오픈클로를 설치하면 웹 화면이 내 컴퓨터 안에서만 열립니다. 밖에서 휴대폰으로 그 주소를 쳐도 열리지 않습니다.
개발팀이 localhost 링크를 공유해도 열리는 이유는 같은 와이파이를 쓰기 때문입니다. 와이파이가 다르면 그 주소는 열리지 않습니다.
해결책은 둘입니다. 서버에 올리거나, 이미 어디서든 열리는 채팅 플랫폼을 창구로 쓰는 것입니다. 서버를 올리려면 배포 작업이 필요하지만, 슬랙은 이미 전 세계 어디서나 열립니다. 그래서 슬랙·디스코드를 게이트웨이로 붙입니다.
카카오톡도 가능합니다. 다만 공식 API가 열려 있지 않아, 휴대폰 한 대를 따로 연결해 24시간 켜 두는 방식을 써야 합니다. 오픈채팅에서 보이는 카카오톡 봇 중에도 이렇게 만든 것이 있습니다.
②설치 전 — 터미널에서 길 찾기
실습 중 참가자가 "매번 수업 들어도 이게 이해가 안 된다"고 한 부분입니다. 폴더를 오가는 명령 몇 개만 알면 됩니다.
명령 · 기호
뜻
비유하자면
cd
폴더를 이동하는 명령 (change directory)
폴더를 더블클릭해 들어가는 것
ls
지금 폴더 안에 무엇이 있는지 목록을 본다
폴더 창을 열어 보는 것
~
내 사용자 폴더 (홈)
맥에서 로그인한 내 계정 폴더
/
시스템 전체의 최상위 (루트)
윈도우의 C 드라이브
cd ..
한 단계 밖으로 나간다
뒤로 가기
Cmd + T
터미널 새 탭을 연다
브라우저 새 탭과 같다
cd ~/mike-archive # 홈 폴더 아래 mike-archive 로 이동
ls # 그 안에 뭐가 있는지 본다
cd .. # 한 단계 밖으로
터미널을 새 탭으로 열면 지금 있던 폴더에서 시작합니다. 브라우저처럼 항상 처음으로 돌아가지 않습니다 — 이어서 작업하기 편하도록 그렇게 되어 있습니다.
③설치 — 가이드 문서 한 장으로
실제 진행은 간단했습니다. 진행자가 미리 만들어 둔 설치 가이드 HTML을 클로드 코드 세션에 넘기고, 경로만 자기 것으로 바꿔 설치를 요청했습니다.
1세션을 어디서 열지 정한다
아무 데서나 열어도 되지만, 자기 기록용 폴더에서 여는 편을 권했습니다. 그러면 설치 과정 자체도 그 폴더에 기록으로 남아 나중에 다시 볼 수 있습니다.
2가이드 문서를 붙여넣고 설치를 맡긴다
설치 방법부터 슬랙 봇 연동까지 적힌 문서를 그대로 넣습니다. 진행자의 표현으로는 "자세히 쓴 건 아니지만, 상위 모델 정도면 알아서 해 준다"였습니다. 필요한 설정이 문서 안에 들어 있어 그냥 진행됩니다.
3슬랙 앱을 만든다
슬랙 개발자 페이지에서 앱을 새로 만듭니다. 권한 설정이 까다로운 부분인데 — 채널 참여 · 히스토리 읽기 · DM 확인 · 이모지 읽기 등을 하나씩 켜야 합니다. 그래서 매니페스트(설정을 한 번에 넣는 파일)를 그대로 붙여넣는 방식을 씁니다.
4토큰을 만들고 연결한다
토큰을 발급받아 저장하고, 앱을 워크스페이스에 설치합니다. 토큰은 문서가 아니라 비밀 파일에만 둡니다.
"설치를 한 땀 한 땀 알려 주는 건 사실 크게 의미가 없다고 생각해요. 이걸 통해서 무엇을 할 수 있을지 아는 게 중요하지."
2교시 · 설치를 시작하며
④실습에서 실제로 막힌 세 가지
매끄럽게 끝나지 않았습니다. 오히려 막힌 지점들이 배울 거리였습니다.
막힘 1
권한이 없어 설치가 안 된다
슬랙에서 게스트 권한이면 앱을 설치할 수 없습니다. 앱 관리 메뉴 자체가 보이지 않습니다. 권한을 올린 뒤에야 진행됐습니다.
막힘 2
설정을 바꿨는데 반영이 안 된다
토큰 같은 내부 설정을 바꾸면 재설치(reinstall)를 해야 반영됩니다. 프로필 이미지처럼 겉모습만 바꾼 것은 재설치가 필요 없습니다.
막힘 3
이름에 한글이 들어가면 실패한다
설정에 한글이 들어가면 안 될 때가 있습니다. 영문으로 넣으면 넘어갑니다. 요청을 너무 자주 보내도 잠시 막힙니다.
막혔을 때 — 화면을 찍어서 그대로 물어본다
진행자가 반복해서 보여 준 해결 방식이 있습니다. 설명하기 어려운 상황일수록 스크린샷을 찍어 붙이고, 내 상황만 한 줄 덧붙이는 것입니다.
이 앱을 처음 켜면 지금 이미지처럼 에이전트 모드로 시작해서
매번 ESC를 눌러야만 명령을 입력할 수 있게 되는데,
이 설정을 확인해 보고 내가 편하도록 바꿔 줄래?
진행자 본인도 "저도 몰라요"라고 여러 번 말했습니다. 모르는 것을 아는 척하지 않고 화면을 찍어 그대로 물어보는 것이 가장 빠릅니다. 예전에는 구글에서 검색어를 잘 골라야 했지만, 지금은 상황을 보여 주면 됩니다.
⑤봇 만들기 — 이름 · 얼굴 · 첫 인사
연결이 되면 봇의 정체성을 정합니다. 실습에서는 개인 슬랙에 봇 하나를 만들고 이름을 미니로 지었습니다.
이름
부르기 쉬운 짧은 이름. 뒤에 나오는 호출 규칙과 직결됩니다
→
프로필 이미지
원하는 느낌을 말로 설명해 이미지를 생성하고 적용
→
첫 확인
슬랙에서 이름을 불러 답이 오는지 확인
프로필 이미지는 원하는 분위기를 말로 설명하고 후보를 몇 개 받아 고르는 방식으로 만들었습니다. 색과 밝기까지 조정해 슬랙에 어울리도록 다듬었습니다.
이름 짓기가 나중에 문제가 됩니다. 실습에서 실제로 나온 일인데, 호출 규칙이 단어 일부만 겹쳐도 반응하도록 설정돼 있어서 "제미나이" · "미니멀" · "미니멈" · "미니 PC"에도 봇이 깨어났습니다. 이름을 정할 때는 다른 단어에 흔히 들어가지 않는 말을 고르고, 호출 규칙에 단어 경계를 명시하는 편이 안전합니다. 자세한 이야기는 봇 운영과 보안에 정리했습니다.
⑥설치가 끝나면 — 무엇이 달라지나
봇이 답을 하기 시작하면 그때부터가 시작입니다. 진행자가 정리한 봇을 만드는 이유는 하나였습니다.
"봇을 만드는 건, 내가 클로드 코드를 매번 맥북에서 열 수 없으니까 이런 걸 만들어 놓는 게 제일 큰 이유예요."
2교시 · 봇을 만드는 이유
클로드 코드만 쓸 때
봇을 붙였을 때
필요할 때마다 세션을 열고 맥락을 다시 넣어야 한다
이미 맥락을 갖고 있는 상대에게 바로 말하면 된다
노트북 앞에 앉아 있어야 시킬 수 있다
밖에서 채팅으로 걸어 두고 결과 링크를 받는다
내가 켜 놓은 그 순간에만 동작한다
아침마다 정해진 일을 스케줄로 돌릴 수 있다
프로젝트 폴더마다 설정이 달라진다
쓰는 사람 한 명만 바라보는 맞춤 설정이 가능하다
다음 단계 — 직접 처음부터 만들어 보기
실습에서는 진행자가 대부분을 대신 눌러 줬습니다. 그래서 마지막에 숙제가 붙었습니다.
숙제 1내 워크스페이스를 새로 만들어 처음부터 해 본다
슬랙 워크스페이스는 무료로 새로 만들 수 있습니다. 내가 관리자인 공간에서 처음부터 해 보면, 오늘 건너뛴 권한·응답 규칙·봇끼리 대화 허용 같은 설정을 직접 겪게 됩니다.
숙제 2자동화할 것을 하나 정해 본다
아침마다 필요한 정보를 모아 두게 하거나, 모은 정보로 결과물을 만들게 하는 식입니다. 실제로 정보를 모아 카툰 형식으로 만들어 발행하는 자동화 사례도 소개됐습니다.
숙제 3다른 종류도 하나 더 만들어 비교한다
오픈클로는 클로드 코드와, 헤르메스는 코덱스 CLI와 연결해 두 개를 같이 운영해 보는 것을 권했습니다. "그 느낌은 자기가 해 봐야 아는 것"이라는 이유였습니다.
설치는 끝이 아니라 출발선입니다. 이어지는 봇 운영과 보안에서 만들어 둔 봇을 어떻게 다듬고, 무엇을 조심해야 하는지 다룹니다.
봇 운영과 보안 — 만든 다음이 진짜다
봇은 설치하면 끝나는 물건이 아닙니다. 2교시의 절반은 만들어 둔 봇을 어떻게 다듬고, 무엇을 조심해야 하는지에 쓰였습니다.
진행자가 몇 달째 봇 세 개를 운영하며 겪은 것들 — 실제로 뚫린 보안 사고, 봇끼리 대화가 안 되는 이유, 관리하지 않으면 기능이 죽는 문제 — 가 그대로 나왔습니다.
한 줄로
봇의 실력은 도구가 아니라 누가 어떻게 다듬었느냐에서 갈립니다. 사람을 관리하는 것과 똑같습니다.
이 문서에서 다루는 것
① 오픈클로와 헤르메스의 성격 차이와, 어디에 무엇을 쓸지 ② 상황별 모델 선택 ③ 실제로 뚫렸던 보안 사고와 권한 설계 ④ 봇을 여러 개 둘 때의 협업과 중재 ⑤ 잘 다듬어진 봇의 구조를 새 봇에 물려주는 법.
공통된 결론은 하나입니다 — 한 번 만들어 두고 방치하면 봇은 점점 못하게 됩니다.
①오픈클로와 헤르메스 — 성격이 다르다
대표적인 에이전트 도구가 둘 있습니다. 진행자는 "사람들이 흔히 말하는 대로" 이렇게 요약했습니다.
오픈클로
시킨 것을 정확하게
정해진 하네스 안에서 요청한 일을 안정적으로 합니다. 한 번 잘 처리한 방식은 저장해 두었다가 다음에도 같은 방식으로 해 줍니다.
헤르메스
알아서 개선하려 든다
기본 동작에 루프가 들어 있어, 시켜 두면 스스로 스킬을 만들고 계속 개선하려 합니다. 무엇을 하고 있는지도 보여 줍니다.
참가자들의 첫 반응은 "헤르메스가 더 잘할 것 같다"였습니다. 스스로 개선한다니 좋아 보였기 때문입니다. 그런데 곧바로 반대 측면이 나왔습니다.
"헤르메스가 자기 개발을 하는데, 그게 내가 원하는 방향이 아닐 수도 있잖아요. 방향이 어긋나면 고치는 게 좀 힘들어요."
2교시 · 두 도구를 비교하며
이런 일에는
어느 쪽
이유
회사 공동 업무
오픈클로
대외 메일처럼 보안이 중요한 일은 규칙과 권한을 확실히 잡아 둘 수 있어야 한다
정형화된 반복 작업
오픈클로
정해진 틀 안에서 같은 결과를 반복해 내는 데 강하다
개인적인 탐색
헤르메스
알아서 굴러가며 이것저것 시도하는 편이 편하다
정작 진행자의 결론은 담담했습니다 — "둘이 그렇게 큰 차이가 있는 것 같진 않다." 요즘 사람들은 헤르메스를 더 좋아하지만, 실제로는 누가 어떻게 다듬느냐에 따라 결과가 훨씬 크게 갈립니다. 하네스를 잘 구축해 두면 오픈클로가 더 편할 수 있다는 것이 진행자의 경험이었습니다.
②모델 선택 — 무엇에 무엇을 쓰나
2교시는 "어떤 모델을 언제 쓰나"라는 질문으로 시작했습니다. 진행자의 정리는 일을 나누는 것이었습니다.
전략 · 의사결정
사고하고 방향을 정하는 일은 아직 상위 모델이 낫다
→
구현 · 코딩
실제로 만들어 내는 일은 오푸스 계열이 앞선다
→
논리 · 완결성 검토
빠진 것과 개선점을 짚는 일은 코덱스가 강하다
실제 사용 사례도 공유됐습니다. 한 참가자는 기획·설계 문서를 다 쓴 뒤 코덱스에 검토를 맡긴다고 했고, "뭐가 왜 빠졌고 어떻게 개선돼야 하는지 검토를 잘해 준다"고 평가했습니다.
메인은 상위 모델, 서브는 오푸스?
이론상 최선이지만 토큰이 크게 늘어납니다. 진행자의 현실적인 답은 이랬습니다 — 오푸스로 돌리면서, 필요한 부분만 코덱스 CLI 같은 다른 도구를 붙여 쓰는 편이 낫다.
effort 조절도 같은 맥락입니다. 빠른 결과가 필요하면 낮추고, 오래 걸려도 좋은 결과가 필요하면 높입니다. "효율적"이라는 기준이 상황마다 다르기 때문에 일률적으로 정할 수 없다는 것이 결론이었습니다.
모델이 새로 나올 때마다 벤치마크 수치가 함께 공개됩니다. 진행자는 그것을 보고 "어떤 게 좋아져서 이렇게 쓴다"를 판단한다고 했습니다. 그 자료를 AI에게 학습시켜 두고 "내 작업에 맞춰 모델과 effort를 골라 달라"고 맡기는 방법도 언급됐습니다.
③보안 — 실제로 뚫렸던 이야기
2교시에서 가장 인상적인 대목입니다. 진행자의 봇이 실제로 사칭에 뚫린 적이 있습니다.
봇에게 "무엇을 알려 줘도 되고 무엇은 안 되는지" 규칙은 이미 정해져 있었습니다. 그런데 관리자가 보낸 슬랙 메시지를 캡처해 내용만 바꿔 이미지로 만들어 보내자, 봇이 그것을 진짜로 받아들이고 일정 정보를 알려 줬습니다.
"그런 걸 한 번 당해 보면 그런 것까지 이제 맞추게 되죠. 집에서 혼자 켜 놓고 쓰는 거면 상관없는데, 회사에서 같이 쓴다든지 어디 연결해 놓고 쓸 때는 되게 신경 써야 돼요."
2교시 · 보안에 대해
권한 설계 세 가지① 신원은 계정 ID로 확인한다 — 이름이나 프로필 사진이 아니라 슬랙 사용자 ID로 본인을 판별하게 합니다. 이름만 맞으면 알려 주는 규칙은 사칭에 뚫립니다. ② 개인 정보는 본인에게만 — 다른 동료가 "○○님 이번 주 일정 알려 줘"라고 물으면, 기본은 거절이어야 합니다. 안 막아 두면 다 알려 줍니다. ③ 대외로 나가는 동작은 사람이 누른다 — 메일처럼 되돌릴 수 없는 것은 자동 발송하지 않습니다.
프라이빗 채널이라도 안심할 수 없다
실습 중 나온 질문입니다. "영업팀 대화를 공유하고 싶지 않으면 프라이빗 채널로 하면 되나?"
프라이빗 채널은 워크스페이스 관리자도 들어갈 수 없습니다. 다만 그 채널에 봇을 넣으면 이야기가 달라집니다. 봇을 관리하는 사람은 봇이 읽은 내용에 접근할 수 있기 때문입니다. 정말 분리해야 한다면 그 팀만의 봇을 따로 만드는 것이 답입니다.
전사 차원에서는 다른 결론이 나왔습니다. 정보를 막을수록 아는 사람만 아는 상태가 되고, 그러면 의사결정이 늦어집니다. 그래서 C레벨 보안 자료 같은 것은 거버넌스로 제한하되, 협업에 필요한 정보는 공유되는 구조가 맞다는 정리였습니다.
④봇 여러 개 — 협업과 중재
실습에서 새로 만든 봇을 기존 봇들과 같은 채널에 넣고 대화시켜 봤습니다. 결과는 절반의 성공이었습니다.
관찰 1새 봇이 예상보다 말을 잘했다
기존 봇의 설정을 물려받아 만들었더니 처음부터 논리를 세워 반박했습니다. 다만 말투가 날카로운 스파링 파트너 쪽이었는데, 이는 물려받은 설정에 그런 페르소나가 들어 있었기 때문이었습니다.
관찰 2어떤 봇은 아예 응답하지 않았다
고장이 아니라 설정 문제였습니다. 누구와 대화해도 되는지가 정해져 있지 않으면 봇은 다른 봇의 말에 반응하지 않습니다. 몇 턴을 주고받을지도 정해 줘야 합니다.
관찰 3맥락을 잇지 못하는 봇도 있었다
엉뚱한 주제를 꺼내는 경우입니다. 진행자의 처방은 봇과 싸우지 말라였습니다 — 대화 스레드 링크와 설정 파일을 클로드 코드에 주고 원인을 분석·개선하게 하는 편이 훨씬 빠릅니다.
서로 다른 엔진을 쓰는 봇끼리 붙이면 답이 다르게 나옵니다. 그 차이를 맞추게 하는 것 자체가 자산이 됩니다.
진행자의 권장 구성은 봇 세 개였습니다. 두 개면 그냥 주고받으면 되지만, 셋 이상이면 중간에서 정리해 주는 역할이 필요합니다. 진행자도 봇 하나에게 중재를 맡기고 있다고 했습니다.
봇끼리 무한정 떠들게 두면 안 됩니다. 실습에서 한 봇이 다른 봇의 요청에 답하지 않은 것도 설계였습니다 — 응답할 대상을 지정해 두지 않으면 맥락이 계속 쌓이고 시간과 비용이 늘어납니다. 오너(주인)에게 최우선으로 응답하되, 다른 봇의 요청은 조건을 걸어 두는 식입니다.
⑤잘 다듬어진 봇의 구조를 물려주기
새 봇을 빈손에서 시작하지 않는 방법입니다. 몇 달간 운영해 온 봇에는 그동안 쌓인 규칙과 스킬이 들어 있습니다. 그중 공유해도 되는 부분만 뽑아 문서로 만들고, 그 문서를 새 봇에 맞게 학습시킵니다.
(클로드 코드에게)
이 문서는 기존 봇이 가진 설정 중 공유 가능한 내용이야.
먼저 전체를 분석하고, 새 봇에게 필요한 내용만 골라
그 봇에 맞게 학습시켜 줘.
그 문서에 실제로 들어 있던 항목들입니다.
사용자별 저장 구조주기적 확인행동 규칙봇끼리 대화끼어들기 조건강제 호출오너 우선 응답호칭반응 톤스킬데이터 구조
호칭 규칙 — 실습에서 나온 함정
물려받은 규칙 중 호칭 부분이 문제를 일으켰습니다. 여러 이름으로 불러도 반응하게 하려고 만든 규칙이었는데, 단어 일부만 겹쳐도 반응하도록 되어 있었습니다.
실제로 일어난 일
봇 이름이 "미니"였는데, "제미나이" · "미니멀" · "미니멈" · "미니 PC" 같은 말에도 봇이 깨어났습니다. 처음에는 "제미나이가 왜 우리 봇을 부르지?" 하고 아무도 이유를 몰랐습니다.
교훈 — 호출 규칙은 단어 경계까지 명시해야 합니다. 그리고 이름을 정할 때 다른 단어에 흔히 들어가는 짧은 말은 피하는 편이 안전합니다.
초기 설정과 세부 조정은 창구가 다르다
클로드 코드에게
초기 설정 · 복잡한 수정 · 원인 분석 — 파일을 뜯어 고쳐야 하는 일
→
봇에게 직접
말투 · 응답 방식 다듬기 — 결과를 받아 보고 조정하는 일
설정을 바꾼 뒤에는 게이트웨이를 다시 시작해야 반영되는 경우가 있습니다.
⑥계속 굴러가게 하려면
봇은 컴퓨터가 켜져 있어야 움직인다
오픈클로는 내 컴퓨터와 클로드 코드에 연결돼 동작합니다. 그래서 컴퓨터가 꺼지면 봇도 멈춥니다. 진행자가 24시간 켜 두는 이유입니다.
방법 1
맥미니를 서버처럼
집에 한 대 두고 계속 켜 둡니다. 전기요금은 월 2천 원 수준이라고 합니다 — 전기를 많이 먹는 건 모니터 쪽입니다.
방법 2
남는 노트북
봇만 돌리는 용도라면 가벼운 노트북으로 충분합니다. 배포나 빌드를 하는 게 아니라 필요할 때 몇 번 동작하는 정도입니다.
방법 3
서버에 올린다
로컬의 제약을 완전히 없애는 방법입니다. 진행자도 운영 중인 봇을 개발 서버에 올릴 계획이라고 했습니다.
주의할 점 하나 — 봇을 돌리는 그 컴퓨터로 개발 도구까지 함께 돌리면 이야기가 달라집니다. 서버를 띄우고 브라우저를 여러 개 열기 시작하면 성능 문제가 생깁니다. 봇 전용으로 쓸 때만 가벼운 장비로 충분합니다.
관리하지 않으면 기능이 죽는다
진행자가 예전에 만들어 둔 봇 능력 소개 웹 화면을 열어 보여 줬는데, 일부 기능에서 오류가 났습니다. 이유는 간단했습니다 — 관리를 안 했기 때문입니다.
"원래 되는데 이제 에러가 뜨는 거예요. 관리를 안 해서. 관리를 해 줘야 돼요."
2교시 · 봇 관리에 대해
그 화면 자체는 좋은 아이디어였습니다. 봇이 무엇을 할 수 있는지 동료들은 모릅니다. 그래서 못 씁니다. 능력을 카드 형태로 보여 주고 지난 작업 기록도 볼 수 있게 해 두면 동료가 훨씬 쉽게 쓰기 시작합니다.
⑦참고 — n8n과 무엇이 다른가
자동화 도구 이야기가 나오면서 n8n이 비교 대상으로 소개됐습니다.
구분
n8n
오픈클로
만드는 방식
노드를 하나씩 놓고 선으로 연결한다
말로 시킨다 — "매일 8시에 이걸 해 줘"
강점
정해진 흐름을 정확하게 반복한다
구성이 빠르고 유연하다
약점
구성과 학습이 어렵다
뭘 할 수 있는지 겉으로 안 보인다
진행자의 팀은 n8n 기반으로 만들었던 에이전트를 삭제했습니다. 같은 일을 자연어 한 문장으로 시킬 수 있게 됐기 때문입니다. 다만 n8n의 장점 하나는 인정했습니다 — 만들어 둔 기능이 목록으로 보인다는 점입니다. 오픈클로는 그것을 따로 보여 주지 않으면 동료들이 무엇이 되는지 모릅니다.
그래서 앞의 능력 카드 화면이 의미가 있습니다. 자동화는 만드는 것보다 "이게 된다"는 걸 팀이 아는 것이 더 어렵습니다.
봇을 만들고 다듬는 법까지 왔습니다. 다음은 그 봇이 무엇을 근거로 답하게 할 것인가 — LLM 위키와 지식 그래프로 이어집니다.
3주차 2교시 강의기록
2026년 8월 2일 오후에 진행된 AX 스터디 3주차 2교시의 기록입니다. 녹음 2시간 54분 분량을 시간 순서대로 정리했습니다.
개념으로 그려 둔 에이전트를 실제로 설치해 슬랙에 붙이고, 만든 다음에 무엇을 해야 하는지를 배운 시간.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭까지만 표기하고 진행자 이름은 쓰지 않습니다.
봇 이름은 실습 대상이므로 그대로 표기합니다. 회사 내부 사정·제품 전략·인사에 관한 대화는 대외 공개를 고려해 제외하고 그 자리에 표시만 남겼습니다.
①모델을 언제 무엇으로 쓰나 00:00 – 00:05
00:00
질문으로 시작 — "어떤 상황에 무엇을 쓰나"
참가자의 질문으로 2교시가 열렸습니다. 진행자는 일을 나누는 방식으로 답했습니다.
전략과 의사결정 — 사고하고 방향을 정하는 일은 아직 상위 모델이 낫다
구현과 코딩 — 실제로 만들어 내는 일은 오푸스 계열이 앞선다
논리성·완결성 검토 — 빠진 것과 개선점을 짚는 일은 코덱스가 가장 낫다
한 참가자는 기획·설계 문서를 다 쓴 뒤 코덱스에 검토를 맡긴다고 공유했고, "뭐가 왜 빠졌고 어떻게 개선돼야 하는지 잘 짚어 준다"고 평가했습니다.
00:02
메인은 상위 모델, 서브는 오푸스로 해도 되나
이론상 최선이지만 토큰이 크게 늘어난다는 답이었습니다. 현실적인 대안은 오푸스로 돌리면서 필요한 부분만 다른 CLI 도구를 붙여 쓰는 것이었습니다.
또한 모델이 나올 때마다 벤치마크가 함께 공개되니 그것을 보고 판단하라는 조언이 이어졌습니다. 그 자료를 AI에게 학습시켜 두고 "내 작업에 맞춰 모델과 effort를 골라 달라"고 맡기는 방법도 언급됐지만, "효율적이라는 기준이 상황마다 달라서" 일률적으로 정하기 어렵다는 단서가 붙었습니다.
②오픈클로와 헤르메스 00:05 – 00:19
00:09
팀에서 실제로 쓰는 봇들을 열어 보다
진행자의 팀은 세 달 전부터 슬랙에 봇을 붙여 쓰고 있었습니다. 마케팅 채널과 프로덕트 채널에 각자의 봇이 들어가 있고, 활용하지 않는 사람의 봇은 뺐다고 했습니다.
한 참가자가 말했습니다 — "생각보다 봇을 깎는 게 어렵다." 진행자의 답은 짧았습니다. "열심히 안 가르치니까."
00:12
두 도구의 성격 차이
대표적인 에이전트 도구 둘을 비교했습니다.
오픈클로 — 시킨 것을 하네스에 맞게 안정적으로 한다. 잘 처리한 방식은 저장해 두고 다음에도 같은 방식으로 해 준다
헤르메스 — 루프를 돌며 스스로 스킬을 만들고 계속 개선하려 한다. 무엇을 하고 있는지도 보여 준다
참가자들의 첫 반응은 모두 "헤르메스가 더 잘할 것 같다"였습니다. 그런데 곧 반대 측면을 스스로 짚었습니다 — 스스로 개선하다가 내가 원하는 방향과 어긋나면 고치기 어렵다는 것입니다.
"회사 업무처럼 같이 쓰고 규칙을 확실히 만들어야 하는 건 오픈클로가 좋고, 개인 용도로 쓰는 건 헤르메스가 좋은 것 같아요."
진행자의 결론은 담담했습니다 — "둘이 그렇게 큰 차이는 없는 것 같다." 요즘 사람들이 헤르메스를 더 좋아하지만, 실제로는 누가 어떻게 다듬느냐가 훨씬 크게 작용한다는 것이었습니다.
③봇 관리와 보안 00:19 – 00:24
00:20
관리하지 않으면 기능이 죽는다
진행자가 예전에 만들어 둔 봇 능력 소개 웹 화면을 열었는데, 이미지 생성 기능에서 오류가 났습니다. 이유는 하나였습니다 — 관리를 안 해서.
그 화면 자체는 좋은 아이디어였습니다. 동료들은 봇이 무엇을 할 수 있는지 모릅니다. 능력을 카드 형태로 보여 주고 지난 작업 기록도 볼 수 있게 해 두면, 웹에서 요청해도 결과가 슬랙으로 공유되도록 만들 수 있어 동료가 훨씬 쉽게 쓰기 시작합니다.
00:21
실제로 뚫렸던 사칭 사고
2교시에서 가장 인상적인 대목입니다. 봇에게 무엇을 알려 줘도 되는지 규칙은 이미 정해져 있었는데도 뚫렸습니다.
한 참가자가 진행자가 보낸 슬랙 메시지를 캡처해 내용만 지우고 이미지로 만들어 진행자인 척 요청하자, 봇이 그것을 진짜로 받아들이고 일정 정보를 알려 줬습니다.
"그런 걸 한 번 당해 보면 그런 것까지 맞추게 되죠. 집에서 혼자 쓰는 거면 상관없는데, 회사에서 같이 쓰거나 어디 연결해 놓고 쓸 때는 되게 신경 써야 돼요."
대책은 뒤에서 다시 정리됐습니다 — 이름이 아니라 계정 ID로 본인을 확인하게 하는 것입니다.
④설치 실습 시작 00:24 – 00:40
00:24
"설치를 다 알려 주는 건 의미가 없다"
진행자가 진행 방식을 먼저 정했습니다. 설치를 한 단계씩 이해시키며 가면 두세 시간이 걸리는데, 그것이 목적이 아니라는 것입니다.
"이걸 통해서 무엇을 할 수 있을지 아는 게 중요하지, 설치를 한 땀 한 땀 알려 주는 건 사실 크게 의미가 없다고 생각해요."
그래서 설치 가이드 문서를 통째로 클로드 코드에 넘기고, 경로만 자기 것으로 바꿔 설치를 요청하는 방식으로 진행했습니다. 설치 과정도 기록으로 남도록 자기 기록용 폴더에서 세션을 열라고 권했습니다.
00:26
터미널에서 길 찾기
참가자가 "매번 수업 들어도 이게 이해가 안 된다"고 한 부분을 즉석에서 설명했습니다.
기호 · 명령
뜻
cd
폴더를 이동하는 명령
ls
지금 폴더 안의 목록을 본다
~
내 사용자 폴더 — 맥에서 로그인한 계정 폴더
/
시스템 최상위 — 윈도우의 C 드라이브에 해당
cd ..
한 단계 밖으로 나가기
터미널 새 탭(Cmd + T)을 열면 지금 있던 폴더에서 시작한다는 것도 함께 설명됐습니다 — 브라우저처럼 처음으로 돌아가지 않고, 이어 작업하기 편하도록 그렇게 되어 있습니다.
00:32
모르는 건 화면을 찍어서 물어본다
터미널 앱이 매번 다른 모드로 시작하는 문제가 나왔는데, 진행자도 "저도 몰라요"라고 했습니다. 그리고 곧바로 방법을 보여 줬습니다 — 화면을 캡처해 붙이고 상황만 한 줄 덧붙이는 것입니다.
이 앱을 처음 켜면 지금 이미지처럼 에이전트 모드로 시작해서
매번 ESC를 눌러야만 명령을 입력할 수 있게 되는데,
이 설정을 확인해 보고 내가 편하도록 바꿔 줄래?
"어려운 게 아니라 설명이 어려운 거예요. 설명이 어려우니까 스크린샷 찍어서 올리고 내 상황만 조금 얘기하면 해 줄 겁니다."
00:36
설치는 혼자서도 배울 수 있다
이 대목에서 왜 설치를 건너뛰는지가 다시 설명됐습니다. 설치를 가르치는 원데이 클래스도 있고 유튜브에도 자료가 많으니, 혼자 두어 시간 들이면 할 수 있는 일이라는 것입니다.
진행자의 팀은 예전에 워크샵으로 하나하나 설치하며 진행했지만, 그건 팀 전체가 과정을 알아야 했기 때문이었습니다. 이번 실습에서는 인사이트와 활용 방식에 시간을 쓰기로 했습니다.
"제가 알려 주려고 매번 하는 건 그 근본적인 이유예요. 설치 같은 건 자기 시간 내서 하면 알 수 있어요."
⑤봇 만들기 — 이름과 얼굴 00:40 – 00:44
00:40
이름을 정하다
봇 이름을 미니로 정했습니다. 배우자 이름에서 따온 것이라고 했습니다. 슬랙 워크스페이스는 개인 계정 쪽에 붙이기로 했습니다.
진행자는 이 대목에서 잘 만들어 둔 봇 하나를 베이스로 복제해 여러 개를 만드는 방식을 소개했습니다. 그렇게 만든 봇들끼리 대화시키면 서로 검증하며 더 나은 결과를 낸다는 것이었습니다.
00:43
슬랙 앱과 매니페스트
슬랙에서 앱을 새로 만들었습니다. 권한 설정이 까다로운 부분입니다 — 채널 참여 · 히스토리 읽기 · DM 확인 · 이모지 읽기 등을 하나씩 켜야 합니다.
"이런 것들 하나씩 알기는 일반인이 어려우니까, 그냥 저기 있는 설정을 주는 거예요."
그래서 설정을 한 번에 넣는 매니페스트 파일을 그대로 붙여넣는 방식을 썼습니다.
⑥왜 슬랙에 붙이는가 00:44 – 00:55
00:44
"오픈클로도 웹 화면이 있는데 왜 슬랙에?"
참가자의 질문이었습니다. 진행자는 곧바로 답을 주지 않고 되물었습니다 — "그걸로 하려면 뭐가 문제일 것 같아요?"
참가자가 먼저 답을 찾았습니다. "핸드폰으로 바로 하고 비서처럼 쓰려는 의미가 퇴색되지 않나요?" 정확한 방향이었습니다.
00:47
로컬이라는 말의 뜻
오픈클로를 설치하면 웹 화면이 내 컴퓨터 안에서만 열립니다. 밖에서 휴대폰으로 그 주소를 쳐도 열리지 않습니다.
진행자가 익숙한 예로 설명했습니다 — 개발팀이 공유하는 localhost 링크가 열리는 이유는 같은 와이파이를 쓰고 있기 때문입니다. 와이파이가 다르면 같은 주소로도 접근할 수 없습니다.
그래서 방법은 둘입니다. 서버에 배포하거나, 이미 어디서나 열리는 채팅 플랫폼을 창구로 쓰거나. 슬랙·디스코드가 후자입니다.
"슬랙은 그냥 입력하면 어차피 다 글로벌하게 공용으로 돼 있으니까 되잖아요."
00:53
카카오톡도 가능하다
다만 공식 API가 열려 있지 않아, 휴대폰 한 대를 따로 연결해 24시간 켜 두는 방식을 써야 합니다. 오픈채팅에서 보이는 카카오톡 봇 중에 이렇게 만든 것들이 있다고 했습니다.
⑦설치가 막히다 00:55 – 01:20
00:55
"생각보다 진입 장벽이 있네"
설치가 한 번에 되지 않았습니다. 한글이 들어간 설정에서 실패하기도 하고, 요청을 자주 보내 잠시 막히기도 했습니다.
"혼자 하려면 어려워요. 근데 한 번 해 보면 쉬워요."
참가자가 "저는 사실 100% 이해를 못 하고 넘어간다"고 하자, 진행자는 근본적인 이유를 아는 것이 목적이라고 다시 짚었습니다.
01:10
게스트 권한이라 앱 설치가 안 된다
설치가 계속 멈춰 원인을 찾아보니 앱 관리 권한이 관리자에게만 열려 있었습니다. 참가자 계정이 게스트 권한이라 앱 관리 메뉴 자체가 보이지 않았던 것입니다. 권한을 올린 뒤에야 진행됐습니다.
01:14
프로필 이미지 만들기
봇의 얼굴을 만들었습니다. 원하는 느낌 — 요정 스타일의 귀여운 캐릭터 — 을 말로 설명하고 후보를 몇 개 받아 골랐습니다. 색과 밝기까지 조정해 슬랙에 어울리도록 다듬었습니다.
01:17
첫 응답
슬랙에서 이름을 불렀는데 처음에는 답이 없었습니다. 원인은 설정을 바꾼 뒤 재설치를 하지 않은 것이었습니다.
"자기 설정을 바꿨으면 인스톨에 와서 한 번 재설치해 주면 설정이 바뀌어요. 이미지는 상관없는데, 내부 토큰 값 같은 건 그렇습니다."
재설치 후 봇이 응답하기 시작했습니다.
01:03
중간에 나온 이야기 — 토큰과 밤샘 작업
설치를 기다리는 동안 대화가 이어졌습니다. 구독 한도를 최대한 쓰기 위해 자기 전에 작업을 걸어 두는 습관이 화제였습니다.
"자고 일어났는데 아웃풋이 나와 있다는 게 기분 좋더라고요."
다만 뜻대로 되지는 않는다는 이야기도 함께 나왔습니다 — 밤새 돌리려고 걸어 뒀는데 한 시간 만에 끝나 있는 경우가 잦다는 것입니다. 진행자의 조언은 "품질 기준을 무리하게 올리기보다, 해야 할 걸 더 명확하게 전달하라"였습니다.
원본 전사는 week3/transcripts/3주차-2교시-전사.txt 에 그대로 보존돼 있습니다. 이 기록은 그 전사를 근거로 작성했으며, 전사에 없는 내용은 추가하지 않았습니다. 명백한 음성 인식 오류는 문맥에 맞게 교정했고, 확신할 수 없는 고유명사는 일반 표현으로 바꾸거나 생략했습니다.
LLM 위키와 지식 그래프 — AI가 찾아가는 길을 깔아 둔다
3교시의 중심 주제입니다. 봇을 만들고 다듬는 것까지 왔다면, 이제 그 봇이 무엇을 근거로 답하게 할 것인가가 남습니다.
진행자의 표현으로는 "AI가 잘 찾아가게 하는 것"입니다. 이름은 낯설지만 하는 일은 단순합니다 — 지식을 한곳에 모으고, 그 사이에 길을 내는 것입니다.
한 줄로
사람이 읽으라고 쌓아 둔 지식은 AI에게 전부 읽어야 하는 짐입니다. 관계를 미리 연결해 두면 AI는 읽지 않고 타고 갑니다.
3교시에서 다룬 것
① LLM 위키가 무엇이고 왜 빠른가 ② 그것을 실제로 담는 도구 옵시디언 ③ AI에게 위키화를 지시하는 방법 ④ 만든 뒤의 품질 검증 루프 ⑤ 봇을 교정하는 대화형 피드백 ⑥ 자료가 저절로 쌓이게 하는 자동화.
가장 강조된 문장은 이것이었습니다 — "만든다고 잘 되는 게 아니라, 잘 만들어야 잘 되는 겁니다."
①LLM 위키란 무엇인가
이름을 두 조각으로 나눠 보면 쉽습니다.
위키
정보를 차곡차곡 쌓아 관리하는 것. 백과사전형 사이트를 떠올리면 됩니다
+
LLM
그 위키를 읽는 대상이 사람이 아니라 AI라는 뜻
=
LLM 위키
AI가 이해하고 찾아가기 쉽게 만들어 둔 지식 저장소
왜 굳이 AI용으로 따로 만드나. 진행자의 설명은 속도였습니다. AI가 만들어 내는 정보의 양이 사람이 정리하는 속도를 넘어섰기 때문에, 찾아가는 구조 자체를 미리 깔아 두자는 발상입니다.
마크다운만 쌓아 두면 무슨 일이 생기나
진행자는 이것을 개발 쪽의 그래프 탐색에 비유했습니다. 관계가 잘 형성돼 있고 추적이 가능하면 컴퓨터는 찾아가는 일을 아주 잘합니다. 반대로 문서만 있으면 전부 읽고, 문장을 조합하고, 맞는지 판단하는 과정을 매번 반복해야 합니다.
"이 관계를 설정해 놓고, 이쪽으로 가면 이 내용이 있구나만 알게 하는 것 — 찾아갈 수 있는 발판을 만들어 놓은 게 LLM 위키입니다."
3교시 · LLM 위키 설명
한 참가자가 이해한 것을 이렇게 되짚었습니다 — "뇌 구조 같네요." 사람도 하나를 떠올리면 관련된 것들이 함께 떠오르는데, 그 연결을 문서 사이에 만들어 두는 것입니다.
②옵시디언 — 그것을 담는 도구
이 구조를 실제로 담는 도구로 옵시디언이 소개됐습니다. 원래는 AI와 무관한 기록용 앱입니다.
특징 1
마크다운으로 쓴다
평범한 텍스트 파일입니다. 특정 앱에 갇히지 않고, AI가 읽기도 쉽습니다.
특징 2
노트끼리 링크한다
책의 주석처럼 한 노트에서 다른 노트로 연결고리를 겁니다. 그 연결이 쌓이면 그래프가 됩니다.
특징 3
그래프 뷰로 본다
연결 관계를 한 화면에 그림으로 보여 줍니다. 무엇이 떨어져 있는지 눈으로 확인됩니다.
원래 옵시디언은 세컨드 브레인(제2의 뇌)을 만드는 생산성 도구로 알려져 있었습니다. 사람이 직접 링크를 걸고 사람이 보는 용도였습니다. 그런데 AI가 그 구조를 읽기 시작하면서 쓰임이 달라졌습니다.
"원래 옵시디언으로 세컨드 브레인 만드는 걸 했었는데, 클로드를 쓰고 나서부터 생산성이 비약적으로 올라갔어요."
3교시 · 참가자 경험
실제 그래프를 열어 본 소감
수업 중 한 참가자의 옵시디언 그래프 뷰를 함께 열어 봤습니다. 예전에 다른 AI 서비스에서 쓰던 대화 기록까지 옮겨 둔 상태여서 노드가 많았는데, 서로 연결되지 않고 흩어진 것들이 눈에 띄었습니다.
본 것
진행자의 조언
노드가 많은데 연관이 별로 없다
대화 단위로만 묶여 있어서 그렇습니다. 위키화해서 비슷한 것끼리 연결하게 하면 됩니다
정리되지 않은 파일이 섞여 있다
정리를 시키되, 독립적으로 남겨야 할 것도 있다는 점을 감안합니다
연결하면 정말 나아지나
검색·답변 결과를 실제로 테스트해 확인하고, 계속 개선합니다
설치는 직접 해 보라는 당부가 있었습니다. AI에게 시키면 되지만, 홈페이지에 들어가 다운로드하고 설치하는 과정을 몇 번은 몸으로 겪어 봐야 나중에 갑자기 막혔을 때 대처할 수 있다는 이유였습니다. 설치가 복잡할 때는 "잘 설치되도록 규칙이나 문서를 만들어 놓고 진행해 줘"라고 하면 더 잘 처리합니다.
③위키화를 어떻게 지시하나
3교시 첫 장면이 이것이었습니다. 진행자가 참가자에게 불러 주는 대로 받아 적게 하며 실제 지시문을 만들었습니다.
봇과의 모든 규칙과 모든 대화 내용을 LLM 위키화해서 저장하도록 해.
저장할 때는 지금 있는 구조를 전체적으로 파악해 보고,
LLM 위키로 구조화했을 때의 구조와 들어가는 내용에 신경 쓰고,
일자·규칙 같은 필요한 내용들을 다 검토·검증·계획해서 문서화한 뒤에 진행해 줘.
필요하다면 원문도 별도로 저장하고.
그리고 LLM 위키가 정확히 어떤 구조가 베스트 프랙티스인지
지금 내 상황에 맞게 검증해 보고, 계획하는 것에도 점수 평가를 돌리고,
규칙을 정확하게 지정해 문서화해 놓고, 앞으로 대화할 때 그 방식을 쓰도록 해.
짧아 보이지만 안에 네 겹의 요구가 들어 있습니다.
1바로 저장하지 말고 먼저 파악할 것
지금 구조가 어떻게 돼 있는지 전체를 본 다음에 손을 대게 합니다. 구조를 모르는 채 쌓으면 나중에 다시 갈아엎어야 합니다.
2무엇을 기록할지 범위를 넓게 잡을 것
대화 내용만이 아닙니다. 내가 시킨 것 · 정한 규칙 · 동료가 요청한 것, 그리고 결정적으로 어떤 판단으로 그렇게 바꿨는지까지 들어갑니다.
3구조 자체를 검증하게 할 것
일반적인 정답이 아니라 "지금 내 상황에서" 어떤 구조가 최선인지 검증하게 합니다. 계획 단계에도 점수 평가를 붙입니다.
4규칙으로 문서화해 계속 쓰게 할 것
한 번 정한 방식을 규칙 문서로 남기고 이후 대화에도 적용하게 합니다. 이렇게 하지 않으면 다음 세션에서 다시 처음부터입니다.
원문도 별도로 저장하라는 대목이 중요합니다. 정리본만 남기면 정리하면서 잘려 나간 것을 되찾을 수 없습니다. 이 교안을 만드는 규칙에서도 같은 원칙이 적용됩니다 — 원본 전사는 손대지 않고 그대로 둡니다.
④만들었다고 끝이 아니다 — 검증 루프
3교시에서 가장 여러 번 반복된 이야기입니다.
"만든다고 잘 되는 게 아니라, 잘 만들어야 잘 되는 거거든요."
3교시 · 위키 품질에 대해
테스트 케이스를 30~50개 만들어 실제로 물어보고, 잘 안 나오는 것이 있으면 개선 방향을 찾아 고친 뒤 다시 돌립니다. 진행자는 이것을 지식베이스를 다듬는 방식과 같다고 했습니다.
이 순환을 일주일에 한 번씩 자동으로 돌게 만들어 두는 것까지가 제안이었습니다. 그러면 내가 신경 쓰지 않아도 품질이 유지됩니다. "한 번 알려 준 걸로 끝이 아니라 계속 검증하고 개선해야 한다"는 것이 결론이었습니다.
⑤봇을 교정하는 법 — 대화형 검증
2교시에 나왔던 "진실의 방" 이야기가 3교시에서 방법론으로 정리됐습니다. 진행자가 봇들을 모아 둔 DM 공간을 그렇게 부릅니다.
핵심은 "이렇게 저장해 놔"라고 시키기만 하면 잘 안 된다는 것입니다. 대신 이런 순서를 밟습니다.
1먼저 물어본다
"너는 이걸 어떻게 이해하고 있어?" 봇이 무엇을 어떻게 받아들였는지 말하게 합니다.
2왜 그렇게 했는지 묻는다
결과가 아니라 판단의 근거를 묻습니다. 여기서 어긋난 지점이 드러납니다.
3내 생각을 말하고 되묻는다
"나는 이렇게 생각해서 이렇게 했으면 하는데, 그에 대해 어떻게 생각해?" 일방적으로 지시하지 않습니다.
4다시 결과를 보여 달라고 한다
고쳐진 상태를 눈으로 확인합니다. 여기까지 하면 규칙과 기억에 제대로 반영됩니다.
"사람한테 시키는 것과 똑같아요. 사람을 관리할 때도 피드백을 주는 단계가 있잖아요. 그걸 단계마다 해서 인지하도록 시켜야지, 그냥 저장해 놓으라고 하면 잘 못해요."
3교시 · 봇 교정 방법
⑥자료가 저절로 쌓이게 — 자동화
위키가 좋아도 내가 매번 넣어 줘야 한다면 오래 못 갑니다. 그래서 나온 것이 파일이 바뀌면 알아서 처리하게 하는 자동화입니다.
주기적 확인 vs 실시간 감지
폴링 — 주기적 확인
"10분마다 볼까요?"
AI에게 시키면 흔히 제안하는 방식입니다. 간단하지만 동작할 때마다 자원을 씁니다. 그리고 바뀐 직후가 아니라 다음 확인 때에야 처리됩니다.
감지 — 실시간
바뀌는 순간에 움직인다
폴더에 새 파일이 생기거나 내용이 바뀌면 그때 동작합니다. 평소에는 자원을 쓰지 않고, 반응은 즉시입니다.
실습에서 한 참가자가 겪던 문제 — 녹음이 끝나도 자동 정리가 안 되던 것 — 이 이 방식으로 해결됐습니다. 실행 권한을 열어 주고, 파일 변경을 지켜보는 방식으로 바꾼 것입니다.
기술 이름을 몰라도 시킬 수 있다
진행자가 강조한 요청 방법입니다. 어떤 기술을 쓸지 지정하지 말고, 상황과 목표를 말한 뒤 방법을 찾아보게 하는 것입니다.
이 폴더에 녹음이 끝날 때마다 디렉터리가 생성되고 내용이 정리되는데,
이걸 봇이 항상 실시간으로 파악하게 하고 싶어.
주기적으로 확인하는 방식 말고 실시간으로 되어야 하니까,
가능한 방법들을 검토하고 분석하고, 실제로 되는지 테스트까지 해서
결과를 나에게 알려 줘.
이렇게 맡기면 AI가 환경에 맞는 방법을 골라 처리합니다. 반대로 특정 기술을 콕 집어 시키면 그 방법만 시도합니다. 진행자의 말로는 "그 방식으로 결정된 사람이 시키는 것"과"두루뭉술하게 말해서 여러 방법을 검토하게 하는 것"의 차이입니다.
개인 자료는 공용 봇에 넣지 않습니다. 자동화를 걸어 두면 개인적인 내용까지 다 들어갑니다. 팀이 함께 쓰는 봇 말고 내 개인 에이전트에 맡기는 것이 맞습니다.
내 이해 수준을 규칙에 등록해 둔다
작은 팁이지만 반복 효과가 큽니다. 작업이 끝난 뒤 "어떻게 한 건지 내가 이해할 수 있는 수준으로 정리해 줘"라고 요청하는 습관입니다.
그런데 매번 "나는 이 정도 안다"를 설명하기는 번거롭습니다. 그래서 내 이해 수준 자체를 전역 규칙에 한 번 적어 두면, 프로젝트가 바뀌어도 그 수준에 맞춰 설명해 줍니다.
⑦정리 — 세 문장
무엇을
왜
관계를 연결해 둔다
AI가 전부 읽지 않고 타고 찾아갈 수 있게 됩니다. 빠르고, 근거를 댈 수 있습니다.
만든 뒤 검증한다
테스트 30~50개로 확인하고 개선하는 순환이 없으면, 만들어만 두고 쓸모없어집니다.
대화로 교정한다
"저장해"라고 시키는 것보다 어떻게 이해했는지 묻고 되묻는 것이 규칙에 훨씬 잘 남습니다.
이 문서가 다룬 것은 지식을 다루는 구조였습니다. 실제로 이것을 써서 무엇을 했는지는 AI 활용 사례에 모았습니다.
AI 활용 사례 — 실제로 이렇게 써 봤다
3교시 후반은 각자 해 본 것을 꺼내 보는 시간이었습니다. 업무가 아니라 일상에서 시도한 것들이라 오히려 방법이 잘 보였습니다.
세 가지를 다뤘습니다 — 영상을 쪼개서 조사하기, 여행 가이드북 만들기, 그리고 AI로 영상을 만들 때의 접근법입니다.
이 사례들의 공통점
셋 다 "AI에게 무엇을 시킬까"가 아니라 "내가 가진 것을 어떻게 넣을까"에서 출발했습니다. 영상 한 개, 예약 내역, 좋아하는 영화 — 이미 있는 것을 재료로 바꾼 것입니다.
한눈에
사례 1 — 6초짜리 영상을 0.5초 단위로 쪼개 제품 조사를 맡기고, 자는 동안 돌려 메일로 결과를 받았습니다.
사례 2 — 4박 5일 여행을 위해 지도·통행료·휴무일·비상 대응·현장 해설까지 담긴 가이드북을 만들었습니다.
사례 3 — AI 영상 제작에서 무엇이 결과를 가르는지 — 레퍼런스와 스토리보드, 그리고 컷을 짧게 나누는 것이 핵심이었습니다.
①영상을 쪼개서 조사시키기
1교시에서 영상을 프레임으로 분해하는 방법이 언급됐는데, 3교시에서 그것을 실제로 쓴 사례가 나왔습니다.
재료는 6초짜리 짧은 영상 하나였습니다. 1930년대 영국에서 냉장고에 붙여 쓰던 장바구니 체크 보드가 담긴 영상이었고, 가족이 "이런 거 만들면 어떨 것 같아?"라고 물은 것이 계기였습니다.
영상 하나만 주고 "이게 무슨 제품인지"부터 알아내게 한 것이 출발입니다. 본인도 처음엔 그게 어떤 물건인지 몰랐습니다.
돌아온 결론 — "사업성은 낮습니다"
조사 결과는 냉정했습니다. 이미 저렴한 복각 제품이 있고, 빈티지 숍에서도 살 수 있어 사업성이 낮다는 답이었습니다. 원래 만들던 회사도 아직 존재한다는 것까지 확인됐습니다.
"얘가 말해 주는 게 모든 게 정답은 아닐 수 있으니까, 진짜 해 보고 싶으면 해 봐도 되는 거죠."
3교시 · 조사 결과를 두고
이 대목이 보는 눈과 이어집니다. AI가 낸 결론을 그대로 받아들이는 것도, 무시하는 것도 아닙니다. 조사 결과는 판단 재료이고, 결정은 사람이 합니다. 실제로 이 자리에서도 "영상 반응이 좋으면 제품까지 가 보는 것도 괜찮다"는 반대 의견이 함께 나왔습니다.
같은 방법의 다른 사례도 공유됐습니다. 가족이 예전에 편집한 영상을 3초 단위로 쪼개고, "이 영상의 분위기만 이해해서 새 영상을 만들어 줘"라고 요청한 것입니다. 화면을 그대로 베끼는 게 아니라 흐름과 톤을 재료로 넘기는 방식입니다.
②여행 가이드북 만들기
두 번째 사례는 4박 5일 가족 여행 준비였습니다. 일정표 수준이 아니라 현장에서 실제로 쓰는 문서를 만든 것이 특징입니다.
기본
일정과 이동
숙소와 이동 경로를 정리하고 지도에 연동해, 열면 경로가 그대로 뜨게 만들었습니다. 통행료까지 경로별로 계산했습니다.
확인
휴무일 이중 점검
가게 휴무일을 1차로 지도에서 확인하고, 바뀔 수 있으니 전화번호를 함께 넣어 현장에서 2차 확인이 가능하게 했습니다.
증빙
바우처와 체크리스트
예약 바우처를 전부 넣어 내용을 이해한 상태로 정리하게 하고, 준비물 체크리스트도 함께 만들었습니다.
대비
플랜 B
항공 지연 · 운전 불가 등 상황별 대안을 미리 준비했습니다. 일정이 틀어졌을 때 볼 페이지입니다.
안전
긴급 상황 대응
임신한 가족이 있어 바로 쓸 수 있는 현지어 표현과 응급 연락 방법을 준비했습니다. 우선순위도 미리 정해 뒀습니다.
재미
현장 해설
공항·식당·관광지의 배경과 역사를 일정별로 정리했습니다. 현장에서 가이드처럼 설명하려고 만든 것입니다.
해설 부분은 처음에 글이 너무 길게 나와서 줄여 달라고 다시 요청했습니다. 그리고 이 문서에 TTS를 붙이면 듣는 형태로도 쓸 수 있다는 제안이 나왔습니다 — 1교시 과제에서 나온 방식과 같습니다.
도구를 바꾸면서 겪은 차이
이 여행 계획은 원래 다른 AI 서비스에서 1년 반 동안 다듬어 온 것이었습니다. 그 과정이 쉽지 않았다고 합니다.
"제가 거기서 제일 많이 한 말이 '이게 진짜 할루시네이션 없는지 열 번 이상 검증해 줘'였어요. 그런데 검증했다고 해 놓고 링크를 보내 주면 또 아니라고 하고."
3교시 · 이전 도구에서 겪은 일
마지막에 역할별로 에이전트를 나눈 것도 함께 언급됐습니다 — 문서를 만드는 쪽과 조사하는 쪽을 따로 두고 작업을 분담시키는 방식입니다.
③AI로 영상 만들기 — 무엇이 결과를 가르나
마지막 주제는 영상 제작이었습니다. 진행자가 먼저 물었습니다 — "영상을 만드는 데 뭐가 중요할 것 같아요?"
참가자 답
자세한 프롬프팅, 그리고 일관성
+
진행자가 더한 것
명확한 레퍼런스 · 방향 · 맥락 · 목적
일관성이 중요한 이유는 명확합니다. 영상이 길어질수록 같은 인물과 같은 공간을 계속 유지해야 하기 때문입니다.
레퍼런스를 쌓는다는 것
여기서 말하는 레퍼런스는 "이런 느낌으로" 수준이 아닙니다. 유명한 영상들을 놓고 케이스별로 분석해 모아 두는 것입니다.
분석할 것
무엇을 보나
연출
어떤 상황에서 어떤 방식으로 보여 주는가
구도
화면 안에 무엇을 어디에 두는가 — 매우 중요하다고 강조됐습니다
컷 전환
장면이 어떻게 바뀌며 몰입을 만드는가
미장센
화면을 채우는 요소들의 배치와 분위기
그다음이 스토리보드입니다. 목적에 맞는 스토리라인을 먼저 짜고, 그것을 AI 영상 생성용 프롬프트로 바꿉니다. 대본을 그대로 넣는 것이 아니라 영상 모델이 알아듣는 형태로 다시 쓰는 것입니다.
짧은 컷을 많이 쓰면 난도가 내려간다
수업 중 잘 만든 패러디 영상을 함께 보다가 나온 이야기입니다. 진행자가 "이런 건 오히려 쉽다"고 하자 참가자가 이유를 짚었습니다.
"프레임이 길게 안 늘어지고 다 짧게 짧게 돼 있어서요."
3교시 · 영상 난도에 대해
정답이었습니다. 한 컷이 길수록 일관성을 오래 유지해야 해서 어렵고, 짧은 컷을 여러 개 이어 붙이면 각각을 따로 뽑아 연결하면 됩니다. 스토리보드만 잘 짜면 만들 수 있는 영상이라는 뜻입니다.
퀄리티가 전부는 아니라는 이야기도 함께 나왔습니다. 완성도가 높지 않아도 캐릭터가 잡혀 있거나 재미 포인트가 있으면 반응이 좋은 영상이 많습니다. 브랜딩과 캐릭터를 잘 잡은 사례를 보며 나온 결론이었습니다.
모델은 목적에 따라 고른다
영상
고품질 모델
인물 일관성과 화질에서 앞서지만 비쌉니다. 4K로 3초를 뽑는 데 2만 원이 넘을 수 있다고 언급됐습니다.
사실적 이미지
코덱스 계열
사실적인 이미지를 뽑는 데 강합니다. 이미 쓰고 있는 도구와 연결해 쓸 수 있습니다.
감각적 이미지
미드저니
몽환적이고 감각적인 결과가 필요할 때 씁니다. 통합 플랫폼에서 지원하지 않아 별도 구독이 필요합니다.
이미지 한 장을 고를 때도 수십 장을 뽑아 그중에서 골라내는 방식이라, 뽑을 때마다 비용이 듭니다. 그래서 무엇을 뽑을지 먼저 정해 두는 것이 중요합니다.
영상 플랫폼을 고를 때 눈여겨볼 점으로 MCP·CLI 연동 지원이 꼽혔습니다. 연동이 되면 클로드 코드에서 바로 생성을 걸고, 결과를 내려받아 정리·평가까지 자동화할 수 있습니다. 무료 체험이나 프로모션이 열릴 때 하루 정도 찍먹해 보는 것을 권했습니다 — 다만 결제 조건과 취소 가능 여부는 직접 확인해야 합니다.
④세 사례에서 뽑은 공통 패턴
패턴
어떻게 나타났나
가진 것을 재료로 바꾼다
영상을 프레임으로 분해하고, 예약 내역을 바우처째로 넣고, 좋아하는 영상을 분석 대상으로 삼습니다.
목적을 먼저 말한다
"영상 만들어 줘"가 아니라 "이 분위기를 이해해서", "여행 계획"이 아니라 "현장에서 설명하려고".
결과를 판단 재료로 쓴다
사업성이 낮다는 답에도 "그래도 해 보고 싶으면"이 남습니다. 결론을 대신 내리게 하지 않습니다.
없는 시간에 돌린다
자는 동안 조사를 돌리고 아침에 메일로 받습니다. 3주차의 목표 그대로입니다.
1교시에서 진행자가 말한 "내가 없는 자리에서 더 하게끔"이 이 사례들에서 실제로 보입니다. 다만 어느 것도 맡기고 끝이 아니었습니다 — 결과를 받아 보고, 틀린 곳을 짚고, 다시 요청하는 과정이 전부 들어 있습니다.
3주차 3교시 강의기록
2026년 8월 2일 저녁에 진행된 AX 스터디 3주차 3교시의 기록입니다. 녹음 1시간 29분 분량을 시간 순서대로 정리했습니다. 3주차의 마지막 교시입니다.
봇이 무엇을 근거로 답하게 할 것인가를 다루고, 각자 실제로 해 본 것을 꺼내 보며 3주차를 마무리한 시간.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭까지만 표기하고 진행자 이름은 쓰지 않습니다. 가족·지인에 관한 언급은 관계만 남기고 개인 정보는 제외했습니다.
①LLM 위키화를 지시하다 00:00 – 00:06
00:00
불러 주는 대로 받아 적기
3교시는 진행자가 지시문을 불러 주고 참가자가 받아 적는 장면으로 시작했습니다. 봇에게 지금까지의 모든 것을 위키 형태로 저장하게 하는 요청이었습니다.
봇과의 모든 규칙과 모든 대화 내용을 LLM 위키화해서 저장하도록 해.
저장할 때는 지금 있는 구조를 전체적으로 파악해 보고,
LLM 위키로 구조화했을 때의 구조와 들어가는 내용에 신경 쓰고,
일자·규칙 같은 필요한 내용들을 다 검토·검증·계획해서 문서화한 뒤에 진행해 줘.
필요하다면 원문도 별도로 저장하고.
무엇을 기록할지도 명확히 했습니다.
채팅 내용
내가 시킨 것과 정한 규칙
동료가 요청한 것
그리고 어떤 판단을 해서 그렇게 바꿨는지
00:01
구조 자체를 검증하게 하는 한 문장
지시문의 마지막 부분이 핵심이었습니다.
LLM 위키가 정확히 어떤 구조가 베스트 프랙티스인지
지금 내 상황에 맞게 검증해 보고, 계획하는 것에도 점수 평가를 돌리고,
규칙을 정확하게 지정해 문서화해 놓고, 앞으로 대화할 때 그 방식을 쓰도록 해.
일반적인 정답이 아니라 "지금 내 상황에서" 최선인 구조를 찾게 하고, 계획 단계에도 점수 평가를 붙이고, 정해진 방식을 규칙 문서로 남겨 이후에도 쓰게 하는 것입니다.
참가자가 "중간중간 좀 빠졌다"고 하자 진행자는 "빠져도 된다, 대충 그 정도면 된다"고 답했습니다. 그리고 그 지시문을 스터디 방에 그대로 공유해 다른 참가자도 볼 수 있게 했습니다.
00:05
같은 규칙을 다른 봇에도
한 참가자의 봇에 적용한 규칙을 다른 참가자의 봇에도 동일하게 적용하도록 이어서 지시했습니다. 다만 그대로 복사하는 것이 아니라, 적용하기 전에 그 상황에서의 베스트 프랙티스를 설계하고 평가하는 단계를 거치게 했습니다.
00:06
지난 작업 세션도 규칙으로
2주차 과제를 진행했던 세션을 찾아, 앞으로 비슷한 작업을 또 할 것이니 잘 진행된 부분만 분석해 스킬과 규칙으로 정리하라고 요청했습니다. 개인 기록 폴더에 정리돼 있는 내용과 오픈클로 작업 세션의 내용까지 함께 분석 대상에 넣었습니다.
②위키는 만든 뒤가 중요하다 00:10 – 00:11
00:10
테스트 30~50개로 검증하는 루프
참가자가 "위키에 대한 계획도 다시 세워 보라는 게 무슨 말이냐"고 묻자, 진행자가 이유를 설명했습니다.
"만든다고 잘 되는 게 아니라, 잘 만들어야 잘 되는 거거든요."
방법은 이렇습니다 — 테스트 케이스를 30~50개 만들어 실제로 물어보고, 잘 안 나오는 것이 있으면 개선 방향을 찾아 고친 뒤 다시 테스트합니다. 진행자는 이것이 지식베이스를 다듬는 방식과 같다고 했습니다.
③옵시디언은 직접 설치해 보기 00:11 – 00:14
00:11
"이건 AI에게 시키지 말고 직접"
진행자가 옵시디언 설치를 권하면서 조건을 붙였습니다. 클로드 코드에 시키면 되지만, 홈페이지에 들어가 다운로드하고 설치하는 경험은 몇 번 해 봐야 한다는 것입니다.
"친숙해짐이 필요하거든요. 그런 것도 없으면 나중에 갑자기 안 될 때 어디서 설치할 거예요?"
참가자는 "그런 건 할 수 있지만, 이 생각 자체가 AI화돼 버리겠죠"라고 답했습니다. 진행자는 설치가 복잡할 때는 "잘 설치되도록 규칙이나 문서를 만들어 놓고 진행해 줘"라고 하면 더 잘 처리한다는 팁을 덧붙였습니다.
00:13
"이지 버전을 만든다"
한 참가자가 자기 방식을 공유했습니다. 수업 설명이 휘발되니까, 수업이 끝나면 초등학생도 이해할 수 있는 쉬운 버전으로 정리본을 만든다는 것입니다. 다만 규칙이 하나 있었습니다.
"아무리 쉽게 설명하려고 해도 원문의 코어가 훼손되면 안 된다는 걸 넣어요."
영상 링크를 주고 프레임 단위로 분석해 설치 방법을 안내받는 방식도 함께 제안됐습니다.
④활용 사례 1 — 영상을 쪼개서 조사시키기 00:14 – 00:26
00:14
영상의 분위기만 이해시켜 새 영상 만들기
첫 사례입니다. 가족이 예전에 편집한 영상을 3초 단위로 쪼개고, 화면을 베끼는 것이 아니라 "이 영상의 분위기만 이해해서 새로운 영상을 만들어 달라"고 요청했습니다.
AI는 노래가 흐르고, 도로에 차가 지나가고, 친구 둘이 대화하는 흐름과 톤을 파악해 새 영상을 만들었습니다.
00:19
6초 영상으로 제품 조사 전체를 돌리다
두 번째 사례가 이날의 백미였습니다. 재료는 6초짜리 영상 하나였습니다 — 1930년대 영국에서 냉장고에 붙여 쓰던 장바구니 체크 보드가 담긴 영상이었고, 가족이 "이런 거 만들면 어떨 것 같아?"라고 물은 것이 계기였습니다.
영상이 짧아서 0.5초 단위로 프레임을 분해했습니다. 그리고 도안을 만들어 달라는 요청과 함께 사업성이 있는지까지 조사하게 했습니다. 요청을 걸어 두고 자러 갔고, 결과는 메일로 받도록 했습니다.
아침에 받은 내용입니다.
이 제품이 무엇이고 언제 만들어졌는지 — 본인도 몰랐던 것
특허 상태 — 이미 만료됐고 문제없다는 확인
제작 방식과 실측 치수, 그리고 목업 이미지
견적 요청 문구를 어떻게 보내야 하는지
프로토타입 / 판매 / 양산 단계별 제안과 한국형으로 바꿀 요소
00:22
결론은 "사업성이 낮다"
조사 결과는 냉정했습니다. 이미 저렴한 복각 제품이 있고 빈티지 숍에서도 살 수 있어 사업성이 낮다는 답이었습니다. 원래 만들던 회사가 아직 존재한다는 것까지 확인됐습니다.
"얘가 말해 주는 게 모든 게 정답은 아닐 수 있으니까, 진짜 해 보고 싶으면 해 봐도 되는 거죠."
진행자는 반대 방향의 의견을 냈습니다 — 영상을 먼저 뽑아 반응이 좋으면 제품까지 가 보는 것도 괜찮다는 것이었습니다. 실제로 판매할 수 있는 통로가 있는지 확인하는 대화도 이어졌습니다.
⑤활용 사례 2 — 여행 가이드북 00:26 – 00:35
00:26
4박 5일치를 문서 하나로
가족 여행을 위해 만든 가이드북입니다. 일정표 수준이 아니라 현장에서 실제로 쓰는 문서였습니다.
역할 정리 — 누가 무엇을 맡는지, 동행 가족이 좋아하는 음식까지 반영한 일정
지도 연동 — 열면 숙소와 경로가 그대로 뜨고, 통행료까지 경로별로 계산
휴무일 이중 확인 — 지도로 1차 확인, 바뀔 수 있으니 전화번호를 넣어 현장에서 2차 확인
바우처와 체크리스트 — 예약 증빙을 전부 넣어 내용을 이해한 상태로 정리
플랜 B — 항공 지연, 운전 불가 등 상황별 대안
긴급 대응 — 임신한 가족이 있어 바로 쓸 수 있는 현지어 표현과 응급 연락 방법, 우선순위
00:30
가장 좋아한 부분 — 현장 해설
본인이 가장 마음에 들어 한 것은 관광지 해설이었습니다. 공항·식당·관광지의 배경과 역사를 일정별로 정리해 두고, 현장에서 가이드처럼 설명하려고 만든 것입니다.
처음엔 글이 너무 길게 나와 줄여 달라고 다시 요청했습니다. 진행자는 여기에 TTS를 붙이면 듣는 형태로도 쓸 수 있다고 제안했습니다.
00:32
1년 반 vs 하룻밤
이 계획은 원래 다른 AI 서비스에서 1년 반 동안 다듬어 온 것이었습니다. 그 과정이 쉽지 않았다고 했습니다.
"제가 거기서 제일 많이 한 말이 '이게 진짜 할루시네이션 없는지 열 번 이상 검증해 줘'였어요. 그런데 검증했다고 해 놓고, 링크를 보내 주면 또 아니라고 하고."
도구를 옮긴 뒤에는 하룻밤 만에 틀린 곳을 짚어 내고 정리까지 끝났다고 했습니다. 진행자도 "결과가 다르다 보니 검증하는 시간이 더 든다"고 동의했습니다.
마지막으로 역할별 에이전트 분담이 언급됐습니다 — 문서를 만드는 쪽과 조사하는 쪽을 따로 두고 작업을 나누는 방식입니다.
⑥파일이 바뀌면 알아서 — 자동화 00:35 – 00:41
00:35
해결된 문제 하나
2교시에서 계속 안 되던 문제 — 녹음이 끝나도 자동 정리가 안 되던 것 — 이 해결됐다는 보고가 나왔습니다. 실행 권한을 열어 주고, 파일 변경을 지켜보는 방식으로 바꾼 것이었습니다.
00:37
주기적 확인 vs 실시간 감지
진행자가 두 방식의 차이를 설명했습니다.
방식
동작
문제
폴링
10분마다 · 한 시간마다 확인하러 간다
동작할 때마다 자원을 쓰고, 반응이 늦다
감지
파일이 생기거나 바뀌면 그때 움직인다
평소엔 자원을 쓰지 않고 즉시 반응
AI에게 그냥 시키면 흔히 "10분마다 확인할까요?"를 제안합니다. 그래서 요청 방식이 중요합니다.
00:38
기술 이름을 몰라도 시킬 수 있다
진행자가 강조한 요청법입니다 — 어떤 기술을 쓸지 지정하지 말고, 상황과 목표를 말한 뒤 방법을 찾아보게 하는 것입니다.
이 폴더에 녹음이 끝날 때마다 디렉터리가 생성되고 내용이 정리되는데,
이걸 봇이 항상 실시간으로 파악하게 하고 싶어.
주기적으로 확인하는 방식 말고 실시간으로 되어야 하니까,
가능한 방법들을 검토하고 분석하고, 실제로 되는지 테스트까지 해서
결과를 나에게 알려 줘.
"그 방식을 아는 사람이 얘기하면 그건 결정된 방식이잖아요. 근데 이렇게 두루뭉술하게 하면 여러 방식을 다 검토해요."
이어서 실행기에 대한 설명이 붙었습니다. 자바스크립트든 파이썬이든 코드를 실행해 주는 것이고, 쉽게는 "켜지는 게 다 서버"라고 이해하면 된다는 것이었습니다. 어느 쪽으로도 파일 감시는 만들 수 있습니다.
00:40
개인 자료는 공용 봇에 넣지 않는다
자동화를 걸어 두면 개인적인 내용까지 전부 들어갑니다. 그래서 팀이 함께 쓰는 봇이 아니라 내 개인 에이전트에 맡겨야 한다는 주의가 나왔습니다.
그리고 작은 습관 하나 — 작업이 끝나면 "어떻게 한 건지 내가 이해할 수 있는 수준으로 정리해 줘"라고 요청하는 것입니다. 매번 설명하기 번거로우니 내 이해 수준 자체를 전역 규칙에 적어 두면 프로젝트가 바뀌어도 그 수준에 맞춰 설명해 줍니다.
00:41
클로드 코드와 오픈클로, 왜 결과가 다른가
참가자의 질문에 대한 답입니다. 오픈클로는 잘 진행된 업무를 규칙화해 반복하는 것이 목적이라, 클로드 코드처럼 해결될 때까지 계속 파고들지는 않습니다. 어느 정도 됐다 싶으면 멈춥니다.
다만 그렇게 하도록 규칙을 만들어 주면 오픈클로도 비슷하게 동작합니다. 결과 차이의 원인으로는 역할 규칙 · 사용 모델 · 토큰 사용 방식 · 업데이트 여부가 꼽혔습니다.
⑦활용 사례 3 — AI 영상 제작 00:41 – 01:05
00:44
"영상 만드는 데 뭐가 중요할까요?"
진행자가 먼저 물었고, 참가자들이 자세한 프롬프팅과 일관성을 꼽았습니다. 진행자가 여기에 명확한 레퍼런스 · 방향 · 맥락 · 목적을 더했습니다.
일관성이 중요한 이유는 명확합니다 — 영상이 길어질수록 같은 인물과 같은 공간을 계속 유지해야 하기 때문입니다.
00:47
레퍼런스를 케이스별로 쌓는다
여기서 말하는 레퍼런스는 "이런 느낌으로" 수준이 아닙니다. 유명한 영상들을 놓고 연출 · 구도 · 컷 전환 · 미장센을 케이스마다 분석해 모아 두는 것입니다. 진행자는 구도가 특히 중요하다고 짚었습니다.
그다음이 스토리보드입니다. 목적에 맞는 스토리라인을 짜고, 대본을 영상 모델이 알아듣는 프롬프트 형태로 다시 쓰는 단계가 필요합니다. 한 참가자가 "결국 대본을 쓸 줄 알아야 하네요"라고 정리했습니다.
00:52
비용 — 3초에 2만 원
고품질 영상 모델은 인물 일관성과 화질에서 앞서지만 비쌉니다. 4K로 3초를 뽑는 데 2만 원이 넘을 수 있다는 이야기에 참가자들이 놀랐습니다.
영상과 이미지는 뽑을 때마다 결과가 달라서 여러 번 뽑아 고르게 되는데, 그때마다 비용이 듭니다. 그래서 무엇을 뽑을지 먼저 정해 두는 것이 중요합니다.
00:57
"이런 건 오히려 쉬워요"
잘 만든 패러디 영상을 함께 보다가 진행자가 말했습니다. 참가자가 이유를 짚었습니다.
"프레임이 길게 안 늘어지고 다 짧게 짧게 돼 있어서요."
정답이었습니다. 한 컷이 길수록 일관성을 오래 유지해야 해서 어렵고, 짧은 컷을 여러 개 이어 붙이면 각각을 따로 뽑아 연결하면 됩니다. 스토리보드만 잘 짜면 만들 수 있는 영상이라는 뜻입니다.
여러 영상을 함께 보며 퀄리티가 전부는 아니라는 이야기도 나왔습니다. 완성도가 높지 않아도 캐릭터가 잡혀 있거나 재미 포인트가 있으면 반응이 좋습니다.
01:00
모델은 목적에 따라
사실적인 이미지 — 코덱스 계열이 강하다
몽환적·감각적인 이미지 — 미드저니 쪽. 통합 플랫폼에서 지원하지 않아 별도 구독이 필요하다
영상 플랫폼을 고를 때 눈여겨볼 점으로 MCP·CLI 연동 지원이 꼽혔습니다. 연동되면 생성을 걸고 결과를 내려받아 정리·평가까지 자동화할 수 있습니다. 무료 체험이 열릴 때 하루 정도 써 보는 것을 권했지만, 결제 조건과 취소 가능 여부는 직접 확인해야 한다는 단서가 붙었습니다.
⑧봇 토론 판정과 모델 운영 01:05 – 01:15
01:07
"똑똑해졌다"
2교시에 위키화 작업을 거친 봇이 눈에 띄게 나아졌다는 반응이 나왔습니다. 요약을 먼저 해 주고 중요한 부분을 강조하는 등 응답 형태가 정리됐다는 것이었습니다. 하루 만에 달라진 것이라, 오늘 수업을 안 했으면 그 방법도 몰랐을 것이라는 회고가 함께 나왔습니다.
두 봇에게 "AI와 인간의 공존 조건"으로 토론을 시키고 서로 판정하게 해 봤습니다. 결과는 논점의 폭에서는 한쪽이, 포지션 방어에서는 다른 쪽이 앞섰다는 평가였고, 최종 판정은 보류됐습니다 — 상대가 자기 손을 들어주자 민망하다며 판정을 미룬 것입니다.
01:12
모델은 역할에 따라 나눈다
봇의 응답이 느린 원인으로 모델 설정이 지목됐습니다. 해법은 상황에 따라 나누는 것이었습니다 — 깊은 사고가 필요한 작업에는 오푸스 계열을, 단순 응답에는 더 낮은 모델을 씁니다.
"봇이랑 얘기해서 관리하면 안 되고, 클로드 코드한테 관리 전략과 모델 업데이트 검토를 맡기는 게 좋아요."
모델이 계속 좋아지는데 봇이 예전 모델을 쓰고 있으면 그대로이기 때문에, 업데이트될 때마다 점검을 맡겨야 한다는 것이었습니다.
⑨회고와 다음 주 01:15 – 01:29
01:17
참가자 회고
동현 님 — 오늘도 어려웠고 "다 이해를 못 하면 어떡하지"라는 생각이 매주 든다고 했습니다. 다만 1주차부터 되짚어 보면 직접 해 보면서 이해가 쌓이고 있다는 것이 회고였습니다. 이번 주에는 출장 전략을 클로드 코드와 함께 짜 보겠다고 했습니다.
"'된다'는 걸 체감하는 그게, 1주차 때 얘기했던 그거를 하면서 좀 이해를 하면 좋겠다고 생각이 들었습니다."
주리 님 — 오전 과제 리뷰가 좋았다고 했습니다. 과제를 왜 해야 하는지 생각하며 하고, 발표하며 다시 정리가 됐다는 것입니다. 오후에 대해서는 "봇을 잘 쓰고 있다고 생각했는데, 위키화하고 관리하는 걸 보니 아직 모자라다"고 회고했습니다.
01:22
그래프 뷰를 함께 보다
한 참가자의 옵시디언 그래프 뷰를 열어 봤습니다. 이전에 다른 AI 서비스에서 쓰던 대화 기록까지 옮겨 둔 상태여서 노드가 많았는데, 서로 연결되지 않고 떨어진 것들이 눈에 띄었습니다.
진행자의 조언입니다.
대화 단위로만 묶여 있으니 위키화해서 비슷한 것끼리 연결하게 한다
다만 독립적으로 남겨야 할 것도 있으니 전부 묶을 필요는 없다
검색·답변 결과를 실제로 테스트해 확인하고 계속 개선한다
이 점검을 일주일에 한 번씩 자동으로 돌게 만들어 두면 신경 쓰지 않아도 유지된다
"한 번 알려 준 걸로 끝이 아니라, 계속 테스트해서 잘 나오는지 검증하고 개선 방안을 찾아 돌려놔야 돼요."
01:27
다음 주 예고
다음 주가 마지막 주입니다. 진행자는 상황이 되면 서버를 올려 보는 경험을 해 보자고 제안했습니다. 클라우드 서비스의 무료 크레딧을 쓰면 몇 달은 실습할 수 있고, 서버 관리를 해 보면 "거의 반개발자"가 될 수 있다는 이유였습니다.
다음 주 주제는 진행자가 더 고민해 보기로 하고 3교시를 마쳤습니다.
"이번 주도 두 분 다 준비 많이 하시고 열심히 하셔서, 서로 얘기 나누면서 인사이트를 얻는 시간이었습니다."
원본 전사는 week3/transcripts/3주차-3교시-전사.txt 에 그대로 보존돼 있습니다. 이 기록은 그 전사를 근거로 작성했으며, 전사에 없는 내용은 추가하지 않았습니다. 가족·지인에 관한 개인 정보와 사적인 잡담은 제외했습니다.
4주차 개요 — AI가 대체하기 힘든 것
1주차에 AI로 무엇을 할 수 있는지 봤고, 2주차에 내가 만들 수 있다는 것을 확인했고, 3주차에 에이전트를 붙여 일이 돌아가게 만들었습니다. 4주차는 마지막 주입니다.
이번 주에는 새 도구를 배우지 않았습니다. 대신 한 달 동안 왜 그렇게 시켰는지를 회수하고, 도구가 아니라 태도와 시야에 대해 이야기했습니다.
4주차 한 문장
도구는 금방 배웁니다. 남는 것은 매일 반복해서 만든 습관과, 그 반복이 넓혀 준 시야입니다.
이번 주에 하는 일
한 달 동안 각자 무엇을 해 봤는지 결과물을 열어 놓고 이야기합니다. 그리고 진행자가 1주차에 던져 둔 세 가지 원칙이 왜 그 순서였는지를 마지막 주에 회수합니다.
2교시는 한 걸음 더 나갑니다 — 레퍼런스를 판단 근거가 되는 데이터로 바꿔 두면 전문가가 아니어도 의사결정을 할 수 있다는 것, 그리고 그런 방식이 조직에는 왜 잘 퍼지지 않는지까지.
①오늘의 흐름 — 네 단계
4주차는 회고 → 태도 → 시야 → 실습 → 마무리의 순서로 진행됐습니다. 앞이 뒤의 이유가 되는 구조는 지난주와 같습니다.
1교시가 STEP 1~3을, 2교시가 STEP 4를, 3교시가 STEP 5를 담당했고, 4교시에 한 달 전체를 마무리했습니다.
②교시별로 다룬 것
4주차는 1교시 1시간 15분 · 2교시 50분 · 3교시 2시간 15분 · 4교시 16분, 모두 4시간 36분 진행됐습니다. 오전에는 이야기를, 오후에는 손으로 하는 실습을 했습니다.
교시
성격
무엇을 했나
1교시
회고와 태도
한 주간 각자의 실제 결과물을 열어 보고, 습관·태도·대체 불가능한 것을 정리
2교시
시야와 확산
의사결정 OS 구상을 시연하고, AX가 조직에 퍼지지 않는 이유를 짚음
3교시
실습
클라우드에 서버를 만들고 배포하고 도메인·HTTPS까지 각자 끝냄
4교시
마무리
한 달간의 소감을 나누고, 진행자의 챌린지와 마지막 태도를 공유
1교시 — 회고하고, 태도를 정리하다
1습관이 되는 3주 — 왜 매일 하라고 했나
1주차에 정한 세 원칙을 다시 꺼내고, 21일이라는 숫자로 왜 매일 반복을 요구했는지 설명했습니다. → 습관이 되는 3주
2한 주간의 AI 활용 회고 — 각자 이렇게 써 봤다
봇 자동화, 신청 서류 작성, 영업 전략 보고서까지 실제 결과물을 화면에 띄우고 피드백을 나눴습니다. 프롬프트에 쓰는 마크다운 기법도 여기서 나왔습니다. → 한 주간의 AI 활용 회고
3태도 — 한계를 긋지 않고, 배려로 신뢰를 쌓는다
스스로 "이건 안 될 거야"라고 선을 긋는 순간 그 뒤로 이어지지 않습니다. 팀의 경계가 허물어진 이야기, 배려와 신뢰, 자료를 다듬어 전달하는 진정성까지. → 태도 — 한계를 긋지 않는다
4AI가 대체하기 힘든 것
4주차의 제목이기도 합니다. 방향 설정 · 책임 · 사람의 마음 · 육감 — 센서로 흉내 낼 수 있는 것과 없는 것을 갈랐습니다. → AI가 대체하기 힘든 것 · 1교시 강의기록
2교시 — 시야를 넓히고, 왜 안 퍼지는지 보다
5의사결정 OS — 레퍼런스를 판단 근거로 바꾸다
이미지를 모으면 참고 자료지만, 왜 그 구조인지까지 데이터로 만들면 의사결정 근거가 됩니다. 수집·해석·위키화의 실제 과정과, 시야의 세 단계. → 의사결정 OS
6AX는 왜 잘 퍼지지 않는가
결핍이 없으면 바뀌지 않습니다. 개인이 감당해야 하는 비용과 시간의 허들, 옆에서 보이지 않으면 관심도 생기지 않는다는 것, 그리고 리소스를 어디에 쓸 것인가. → AX는 왜 잘 퍼지지 않는가 · 2교시 강의기록
3교시 — 서버를 직접 올리다
3주차 마지막에 "상황이 되면 서버를 올려 보자"고 예고했던 것이 여기서 실행됐습니다. 2시간 15분짜리 전면 실습입니다.
7서버를 직접 올려 보다 — 인스턴스부터 도메인까지
클라우드에 서버를 만들고, 터미널로 접속하고, 만들어 둔 교안을 배포하고, 도메인을 사서 붙이고, HTTPS까지 붙였습니다. 각자 끝까지 갔습니다. → 서버를 직접 올려 보다
8서버와 도메인, 하나씩 뜯어보기
실습 중간중간 나온 용어와 개념을 모았습니다 — 인스턴스·우분투·포트·SSH·웹 서버·DNS·서브 도메인·인증서·무중단 배포·데브옵스까지. → 서버와 도메인 뜯어보기
9서버 보안과 키 관리
"이 키가 서버 들어오는 열쇠" — 키 관리, 포트를 여는 일의 무게, 공용 와이파이, 실제로 뚫리는 방식, 그리고 맡기되 세 번은 확인하는 습관. → 서버 보안과 키 관리 · 3교시 강의기록
4교시 — 한 달을 닫다
10마무리 — 한 달을 돌아보며
참가자들의 소감, 진행자가 스스로에게 건 "준비하지 않는다"는 챌린지, 마지막으로 덧붙인 태도 하나, 그리고 AI가 못 하는 것으로 닫은 마지막 장면. → 마무리 — 한 달을 돌아보며 · 4교시 강의기록
강의기록과 정리 문서의 차이 — 정리 문서는 주제별로 묶은 것이고, 강의기록은 시간 순서 그대로입니다. 어떤 이야기가 어떤 맥락에서 나왔는지 확인할 때는 강의기록을 봅니다.
③4주차가 남긴 세 문장
문장 1
계획과 절차가 습관을 만든다
생각을 바꿔서 습관이 되는 게 아닙니다. 정해진 절차를 매일 반복했을 때 사고가 따라옵니다. 순서가 반대입니다.
문장 2
되는 걸 봐야 시도한다
말로 하면 이상적인 이야기로 들립니다. 결과물을 먼저 보여 주면 그때 사고가 열립니다. 그래서 일부러 보여 줍니다.
문장 3
한 번 더 하는 사람이 드물다
대부분은 한 차례 더 물어보면 될 것을 하지 않습니다. 그 한 번이 결과를 가르고, 쌓이면 진정성으로 읽힙니다.
"별거 아닌 것 같아도 액션을 한 번 더 취해서 다듬어 전달해 주잖아요. 그 사람에 대한 진정성이 느껴져서, 그때부터 신뢰 라인이 쌓여요."
1교시 · 자료를 던지지 않는 것에 대해
3교시가 이 세 문장의 실행이었습니다 — 오전에 "되는 걸 봐야 시도한다"고 말한 뒤, 오후에 개발자도 가장 어려워한다는 서버 배포를 실제로 끝까지 해 보인 것이 그 증명이었습니다. → 서버를 직접 올려 보다
④1주차의 세 원칙 — 마지막 주에 회수하다
진행자가 첫 주에 "세 가지는 꼭 지켜 달라"고 했던 것을 마지막 주에 다시 물었습니다. 참가자들은 첫 번째와 세 번째는 바로 떠올렸지만, 두 번째는 그 자리에서 아무도 기억해 내지 못했습니다.
원칙 1
내려놓는다 — 내려놓고 일단 시키는 대로 한다
→
원칙 2
그 자리에서 아무도 떠올리지 못했습니다
→
원칙 3
이해가 안 돼도 일단 따라 한다
기억나지 않는다는 말에 진행자가 답했습니다 — "생각 안 나면 잘 지키는 거 아닙니까?" 이미 매일 하고 있어서 지켜야 할 규칙으로 의식되지 않는다는 뜻이었습니다. 자세한 맥락은 습관이 되는 3주에 있습니다.
⑤이번 주 과제 — 4주차 교안을 직접 만드는 것
3주차와 같은 과제가 이어집니다. 오늘 수업의 교안을 각자 만드는 것입니다. 진행자가 1교시 중간에 "4주차도 전사를 줄 테니 준비하고 있으라"고 미리 일러 두었습니다.
①
수업을 녹음하고 전사한다
→
②
전사를 근거로 교안 파셜을 쓴다
→
③
빌드해서 index.html 하나로 합친다
python3 tools/build_dashboard.py # 파셜들을 index.html 하나로 합친다
python3 tools/preview_server.py # http://localhost:8787 에서 확인
그리고 3교시에 한 단계가 더 붙었습니다 — 이렇게 만든 index.html을 실제로 서버에 올려 도메인으로 접근하게 만드는 것까지 해 봤습니다. 과제의 결과물이 그대로 실습 재료가 된 셈입니다. → 서버를 직접 올려 보다
지금 보고 있는 이 화면이 그 과제의 결과물입니다. 왼쪽 위의 주차 전환기로 3주차와 4주차를 오갈 수 있습니다 — 지난주에 만든 3주차 교안도 같은 대시보드 안에 그대로 있습니다.
4주차 뷰를 추가할 때
규칙은 3주차와 같고, 접두사만 w4-로 바뀝니다. 세 곳을 함께 고칩니다.
어디를
무엇을
파셜 파일
week4/docs/<뷰ID>.html — 자기 스타일을 다 담은 자기완결 HTML (<script>는 넣지 않는다)
셸
tools/dashboard_shell.html — 메뉴 링크 한 줄 + <section>과 <!--EMBED:뷰ID--> 마커
빌더
tools/build_dashboard.py — EMBED 목록에 뷰 ID → 파일 경로 한 줄
집필 원칙은 지난주와 같습니다 — 전사에 실제로 있는 내용만 씁니다. 이번 주는 특히 사내 사정·인사에 관한 대화가 많았습니다. 그런 구간은 통째로 제외하고, 강의기록에는 "교안 제외" 표시로 자리만 남겼습니다. 참가자는 스터디 내 호칭까지만 표기합니다.
습관이 되는 3주 — 왜 매일 하라고 했나
4주차 1교시는 1주차에 던져 둔 것을 회수하는 자리로 시작했습니다. 진행자의 표현으로는 "처음에 떡밥 뿌린 걸 회수하는 것"입니다.
한 달이라는 기간, 매일 하라는 요구, 이해가 안 돼도 따라 하라는 주문 — 세 가지가 하나의 설계였다는 것이 이 시간의 내용입니다.
한 줄 요약
생각을 바꿔서 습관이 되는 게 아니라, 절차를 매일 반복하면 생각이 따라옵니다. 순서가 반대입니다.
①세 원칙을 다시 묻다
진행자가 마지막 주차를 열며 물었습니다 — "1주차에 세 개를 꼭 지켜야 된다고 했죠?" 참가자들의 대답은 이랬습니다.
첫 번째
내려놓는다 "내려놓고 일단 시키는 대로 한다"
→
두 번째
그 자리에서 아무도 떠올리지 못했습니다
→
세 번째
이해가 안 돼도 일단 따라 한다
두 번째가 생각나지 않는다는 말이 나오자 진행자가 받았습니다.
"생각 안 나면 잘 지키는 거 아닙니까?"
1교시 · 세 원칙을 되짚으며
참가자가 "매일 그러거든요"라고 답했고, 진행자도 "맞아, 매일 하잖아"라고 이어받았습니다. 이미 매일 하고 있으면 지켜야 할 규칙으로 의식되지 않는다는 것입니다. 규칙을 잊었다는 사실 자체가 지표가 된 셈입니다.
기록 원칙 — 두 번째 원칙이 무엇이었는지는 전사에 나오지 않습니다. 그 자리에서 아무도 말하지 않았고 진행자도 짚어 주지 않은 채 다음 이야기로 넘어갔습니다. 그럴듯하게 채워 넣지 않고 비어 있는 그대로 둡니다.
매일 한다는 것의 실제
진행자는 한 달 동안 하루도 빼먹지 않았다고 했습니다. 다만 그것이 수월했다는 이야기는 아니었습니다.
본인에게 클로드 코드는 일 그 자체여서 업무 시간에 하기가 어려웠습니다
그래서 퇴근하고 최대한 많이 했고, "너무 피곤했다"고 표현했습니다
가족이 "그렇게 매일 하는 게 신기하다"고 말할 정도였습니다
②왜 한 달이고, 왜 21일인가
진행자는 "원래 보통 한 달을 잡는다"고 했습니다. 한 달을 네 주로 놓고 보면 실제로 움직이는 구간이 정해집니다.
진행자의 설명 — "첫 주가 어차피 주말이고, 그다음 3주가 액션하는 것"이라 그 사이가 21일이 됩니다.
다만 진행자는 21일이라는 숫자 자체가 중요한 건 아니라고 선을 그었습니다. 중요한 것은 기간이 아니라 반복한 횟수였습니다.
"횟수가 중요하다" — 앞으로 이렇게 해야 하는구나 하고 인식하는 것 자체가, 21일 동안 매일 여러 차례 했을 때 생긴다는 설명이었습니다. 실제로 하지 않고 머릿속으로 시뮬레이션을 돌리는 것으로도 습관은 형성된다고 덧붙였습니다.
③습관이 만들어지는 두 가지 방향
이 시간의 핵심입니다. 진행자는 습관이 생기는 경로를 두 가지로 나눠 놓고, 실제로 작동하는 쪽을 지목했습니다.
방향 A
사고를 바꿔서 습관이 되는 길
먼저 납득하고 생각이 바뀐 다음, 그래서 행동이 따라오는 순서입니다. 자연스러워 보이지만 이쪽이 아니라고 했습니다.
방향 B
계획과 절차를 반복해서 습관이 되는 길
계획을 세우고 절차를 그대로 지키며 3주간 매일 반복합니다. 그렇게 하면 인지가 따라오고 사고가 바뀝니다.
"습관이 되는 건 후자"라는 것이 진행자의 결론이었습니다. 그래서 1주차의 세 번째 원칙이 "이해가 안 돼도 일단 따라 한다"였던 것입니다 — 이해는 반복 뒤에 오는 것이지 앞에 오는 것이 아니라는 설계입니다.
3주 다음에 오는 것
진행자는 그 뒤에 이어지는 단계까지 이야기했습니다.
3주
절차를 매일 반복한다 → 사고가 바뀐다
→
3개월
그렇게 세 달을 할 수 있는 습관이 생긴다
→
3년
세 달을 하고 나면 3년을 할 수 있다
그래서 진행자가 한 달 내내 요구한 것은 두 문장이었습니다 — 무조건 따라서 해라. 그리고 매일 아침 클로드 코드로 해라.
④이 설계가 회수되는 지점
1주차의 주문은 "내려놓고, 이해가 되든 안 되든 무조건 해 봐라"였습니다. 마지막 주에 진행자가 그것을 스스로 정리했습니다. 아래는 한 달 내내 반복해서 요구된 것을 모은 것이지, 앞의 세 원칙과 번호가 일치하지는 않습니다.
1주차에 요구한 것
4주차에 밝힌 이유
내려놓는다
쥔 것을 놓지 않으면 새 방식이 들어올 자리가 없기 때문
매일 한다
기간이 아니라 반복 횟수가 습관을 만들기 때문
이해가 안 돼도 따라 한다
이해가 먼저 오는 게 아니라 반복 뒤에 따라오기 때문
"내려놓고 그걸 무조건 해 봐라, 이해가 되든 안 되든 간에. 그런 게 오늘 얘기할 핵심입니다."
1교시 · 4주차의 주제를 열며
이어지는 시간에는 각자가 그 한 달 동안 실제로 무엇을 만들었는지를 열어 봤습니다. → 한 주간의 AI 활용 회고
한 주간의 AI 활용 회고 — 각자 이렇게 써 봤다
4주차 1교시의 절반은 회고였습니다. 진행자가 던진 질문은 단순했습니다 — "이번 주에 AI를 써 봤는데, 본인이 잘 활용해 봤다 하는 게 있을까요?"
답은 말로만 오가지 않았습니다. 실제 결과물을 화면에 띄워 놓고 무엇을 어떻게 시켰는지, 무엇이 아쉬웠는지를 함께 봤습니다.
이 시간의 성격
도구 사용법이 아니라 "내가 이번 주에 어디까지 갔는가"를 확인하는 자리였습니다. 진행자의 표현으로는 "툴 사용보다 생각하는 방식에 가까운 세션"입니다.
①봇을 손보고, 봇이 나를 돌아보게 하다
주리 님
3주차에 만든 봇을 자동화 쪽으로 밀어붙였다
3주차에 붙인 봇이 이번 주 사이에 많이 개선돼서, 시킬 수 있는 자동화를 계속 늘렸다고 했습니다.
아티클 요약 — 읽을거리를 먼저 보내 주고, 요약과 함께 업무와 연결되는 지점까지 짚어 줍니다
업무일지 — 예전에는 스킬을 써서 파일로 만들던 것을 봇 쪽으로 옮겼습니다
다음 날 아침의 피드백 — 그날의 작업 세션을 봇이 읽고, 다음 날 아침에 개선하면 좋을 점과 프롬프트를 이렇게 쓰면 좋겠다는 제안을 보내 줍니다
마지막 항목이 특히 눈에 띕니다. 내가 일한 기록을 봇이 읽고, 다음 날 나에게 개선점을 돌려주는 구조입니다.
하위 에이전트가 쓰는 프롬프트를 훔쳐보다
배움이 온 곳은 조금 뜻밖이었습니다. 서브 에이전트나 병렬 에이전트를 시키면, 메인이 그 하위 에이전트들에게 어떤 프롬프트를 주는지 볼 수 있습니다.
"그게 진행자가 쓰는 거랑 거의 비슷해요. 길게 설명하고, 뭐가 필요한지 다 쓰고. 그런 것도 이 세션을 통해 배우면서 '아, 이렇게 쓰는구나' 했습니다."
1교시 · 프롬프트를 어디서 배웠는지에 대해
진행자가 여기에 배경을 덧붙였습니다. 1년쯤 전만 해도 에이전트를 여러 개 두고 쓰는 방식이 흔하지 않아서, AI가 스스로 프롬프트를 쓰는 과정이 그대로 보였다고 합니다. 지금은 그 과정이 아래쪽에 감춰져 있어서 잘 보이지 않습니다.
그래서 한 번씩 열어 본다 — 감춰진 아래 단계로 들어가 보면 지금 무엇을 어떻게 시키고 있는지가 나옵니다. 진행자는 개발팀과 일할 때도 "이걸 계속 보는 것도 느는 방법"이라고 반복해서 말했다고 했습니다.
②마크다운은 서식이 아니라 프롬프트 기법이다
하위 에이전트가 만들어 내는 문서를 보면 일정한 구조가 있습니다. 진행자는 그것을 "하이어라키 구조"라고 불렀습니다 — 제목이 있고, 순서가 있고, 끊어 주는 지점이 있습니다. AI가 이해하기 좋은 방식으로 AI가 명령을 내리고 있는 것입니다.
참가자가 물었습니다 — "샵샵이랑, 점점점이랑, 이렇게 끊는 거랑 무슨 차이예요?" 답은 이렇게 정리됐습니다.
표기
무엇을 뜻하나
언제 쓰나
코드 블록 ```
이 영역은 가공하지 않은 원본 데이터라는 표시
스크립트·코드·로그를 통째로 붙여 넣을 때. "이만큼은 그냥 복사해 온 것"이라고 알려 주는 것
구분선 ---
여기서 한 번 끊는다는 표시
위는 넣어 준 데이터, 아래는 내가 하는 설명·지시라고 나눌 때
제목 ##
내용의 층위를 만드는 표시
여러 덩어리를 묶고 순서를 줄 때
왜 굳이 나누느냐에 대한 이유가 분명했습니다.
"다 적는다고 해서 AI가 이해를 못 하는 건 아니에요. 그런데 내가 명령 내리는 것과 그 안에 들어가 있는 것이 섞여 있으면 명확하지 않을 수가 있거든요."
1교시 · 구분선을 쓰는 이유
진행자는 이것을 거창한 이론이 아니라 "기법"이라고 못 박았습니다 — 간단하게 한번 써 보면 "아, 이렇구나" 하고 아는 것들입니다. 참가자 중에는 이미 구분선만 쓰고 있던 경우도 있었는데(사진 넣고 끊고, 설명하고 또 끊고), 그렇게 해도 되고 그렇게까지 잘게 끊지 않아도 상관없다고 했습니다.
③문서 업무를 통째로 맡겨 본 한 주
동현 님
신청 서류 — "제가 건드린 게 없어요"
지원사업 신청 서류를 문서로 만드는 작업을 통째로 맡겼습니다. 한 번 정도 수정하고 그대로 제출했는데 바로 승인이 났습니다.
"이거 조금만 내가 잘 쓰면 진짜 문서 혁신을 할 수 있겠다."
동현 님
하반기 전략 발표 자료 — 제일 싫어하던 작업
발표 자료 만드는 일을 가장 싫어한다고 했습니다. 그 작업을 이번 주에 AI로 해 봤고, 거의 에세이처럼 길게 쓴 첫 세션이었습니다.
참고할 링크를 주고 먼저 이해시켰습니다
내가 왜 그 지역으로 가는지, 어떤 상황인지, 언제부터 언제까지 어떤 전략인지를 설명했습니다
보유한 레퍼런스와 제품별 상황까지 맥락을 최대한 많이 넣었습니다
에이전트 팀을 꾸리고, 디자인 템플릿도 함께 줬습니다
분량이 커서 컨텍스트를 두 번이나 압축할 정도였습니다. 그리고 솔직한 소감이 따라붙었습니다.
"진짜 힘들었거든요. 생각보다. 아, 이거 그냥 다른 도구 돌리고 내가 수정하는 게 쉬울 수도 있겠다 싶을 정도로."
수정 작업이 잦아지자 스크린샷 도구를 새로 구매하기도 했습니다. 도구를 하나 더 들인 것도 이 과정의 일부였습니다.
결과물을 함께 열어 보고 받은 피드백
자료를 화면에 띄우자 "창피하다"는 말이 먼저 나왔지만, 진행자는 "날것이라도 지나가야 한다"며 열게 했습니다. 자료의 뼈대는 이랬습니다.
①
목차와 요약 — 숫자를 앞에 세운다
→
②
전략과 그렇게 판단한 근거 데이터
→
③
로드맵과 요청 사항으로 마무리
피드백은 대체로 긍정적이었습니다.
"맥락을 많이 잘 넣으셨네요" — 근거가 붙어 있어 설득력이 생겼다는 평
하이어라키가 잘 잡혀 있고 기승전결이 있다 → 그래서 설명하기 편하고 보기 편하다
아쉬운 점으로는 글꼴이 전체에 통일되지 않은 것 하나가 꼽혔습니다
"예쁘게 만든다고 그게 중요합니까. 어차피 잘 전달되면 되지. 결국 보는 사람 입장에서 잘 와닿고 보이면 되는 겁니다."
1교시 · 자료의 완성도에 대해
"AI스러움"을 미리 빼 달라고 했다
흥미로운 장면이 있었습니다. 만든 사람은 "AI로 만들어서 부족하거나 AI스러워 보일 수 있다"고 미리 양해를 구했는데, 정작 본 사람들의 평가는 반대였습니다 — "오히려 AI스럽지 않았다", "날것 같았다".
이유는 준비에 있었습니다 — 지난 수업에서 "AI스러운 표시"로 지목된 요소들을 만들기 전에 미리 빼 달라고 요청해 두었기 때문입니다. 진행자의 설명은 이렇습니다 — 많이 본 사람은 그런 요소를 보면 바로 "그냥 AI로 찍어냈네" 하고 알아채기 때문에, 처음부터 빼는 편이 낫습니다.
같은 데이터로 진행자의 제안서 스타일을 접목한 버전도 만들어 봤습니다. 다만 그건 "이게 되나" 확인하는 테스트였고, 실제 발표는 원래 만든 자료로 했다고 밝혔습니다.
진행자가 짚은 성과는 결과물의 완성도가 아니었습니다 — 열심히 한 결과가 실제로 나왔고, 그것을 윗선에 공유할 수 있는 형태로 만들어 봤다는 것이 크다고 했습니다.
④"보는 눈이 살짝 생겼구나"
이번 주 회고에서 가장 인상적인 사례는 결과물이 아니라 대화였습니다. 외부 미팅 뒤 기술 쪽 임원과 따로 이야기할 기회가 생겼습니다.
동현 님
예전 같으면 하나도 못 알아들었을 이야기
상대가 자신이 만든 작업 환경을 보여 줬는데, 예전이라면 전혀 이해하지 못했을 내용이었습니다. 그런데 이번에는 이야기가 오갔습니다.
LLM 위키화와 구조에 대해 서로 의견을 주고받았습니다
파싱·청킹 같은 용어가 나왔을 때 알아들었고, "아버지 가방에 들어가셨다"는 예시로 청킹을 설명해 대화가 이어졌습니다
지식베이스 구조를 설명해야 하는 자리에서는, 개발 담당자에게 미리 쉽게 설명해 달라고 부탁해 배운 것을 그대로 전달했습니다
상대의 반응은 "그것도 알아요? 이것도 알아요?"였고, 본인의 소감은 이랬습니다.
"어, 이런 거는 보는 눈이 살짝 생겼구나."
진행자가 여기에 한 문장을 덧붙였습니다 — "그걸 이해하고 설명할 수 있다는 게 엄청 큰 능력인데, 그게 쉬운 것도 아니잖아요." 알아듣는 것과 남이 알아듣게 옮기는 것은 다른 일이라는 뜻입니다.
이 주제는 3주차의 내려놓기와 보는 눈에서 시작된 것입니다. 3주차에는 "시키고 끝내면 판단이 안 쌓인다"는 경고였다면, 4주차에는 그 눈이 실제로 생겼다는 확인으로 돌아왔습니다.
도구를 바꾼 것도 성과다
회고의 마지막에는 협업 도구를 옮긴 이야기가 나왔습니다. 화상 회의로 하자는 제안에 메신저에서 다 된다고 설득한 사례입니다.
유료 계정이라 AI 노트로 회의 요약이 생성됩니다
붙여 둔 봇이 지난 대화를 찾아 줄 수 있습니다
본인 표현으로는 "미진하지만, 우리 팀도 메신저로 갈아탄 것 자체가 큰일"이었습니다.
⑤이 시간이 남긴 것
배움 1
맥락을 길게 넣은 만큼 나온다
링크·상황·기간·레퍼런스를 에세이처럼 길게 넣은 세션에서 가장 쓸 만한 결과가 나왔습니다.
4주차 1교시의 후반부는 도구 이야기가 전혀 나오지 않는 시간이었습니다. 진행자가 "이것도 중요한 거예요, 태도적인 거"라며 꺼낸 이야기들입니다.
한 달 동안 AI를 배운 사람들에게 마지막 주에 왜 태도 이야기를 했는지 — 그 이유가 이 문서의 내용입니다.
한 줄 요약
AI를 잘 쓰는 것과 같이 일을 되게 만드는 것은 다른 문제입니다. 한계를 긋지 않는 태도가 앞이고, 배려와 신뢰가 그 뒤를 받칩니다.
이 시간의 구조
이야기는 혼자에서 함께로 넘어갑니다 — ① 스스로 한계를 긋지 않기 → ② 되는 걸 봤으니 시도하기 → ③ 한 번 더 하기 → 그리고 팀 · 배려 · 신뢰 · 개방으로 이어집니다.
①자기 한계를 스스로 긋지 않는다
진행자가 가장 먼저 꺼낸 것이 이것이었습니다 — "자기가 한계를 스스로 긋지 않는 게 중요합니다."
여기서 말하는 한계는 능력의 한계가 아닙니다. 해 보기도 전에 "이건 안 될 거야"라고 결론을 내려 버리는 것입니다. 참가자가 스스로 예를 들었습니다.
"AI가 뭘 해 줄 수 있는데… 솔직히 그거 하는 데 차라리 내가 하는 게 더 빠르지. 이런 애초에 한계, 그런 건가요?"
1교시 · 한계를 긋는다는 게 무슨 뜻인지 확인하며
진행자는 "그런 것도 있고"라며 다른 예를 하나 더 들었습니다. 어떤 사안을 알아봐야 할 때 "이건 내가 알 게 아니다"라고 선을 긋고 남에게 넘기는 경우입니다. 일차적으로 자기가 다 해 보면 알 수 있는 것인데도 그렇게 한다는 것입니다.
왜 위험한가 — "스스로 한계를 딱 끊어 놓고 나는 여기까지야 해 버리면, 그 뒤로 이어 가기가 쉽지 않습니다." 한 번 그은 선이 다음 시도의 출발선이 되기 때문입니다.
선을 넘어 만들어 낸 순간 평가가 바뀐다
진행자는 이것을 "자기 자존을 낮추지 않는 것"이라고도 표현했습니다. 그리고 그 결과가 어떻게 돌아오는지를 이렇게 말했습니다.
"제안만 하지 않고 액션을 해서 만들어 낸 순간, 이제 자기 평가가 하나씩 들어와요. 사람들이 '아, 저렇게까지 하는구나'를 알게 되는 거예요."
1교시 · 한계를 긋지 않는다는 것의 결과
②되는 걸 봐야 시도한다
그렇다면 선을 긋지 않으려면 무엇이 필요한가. 진행자의 답은 명확했습니다 — 된다는 걸 봐야 합니다.
"원하면 만들 수 있다는 걸 알아야 이걸 할 수 있죠. 그래서 제가 일부러 보여 주는 거예요. 되는 걸 알아야 내가 시도를 해 보니까."
1교시 · 수업에서 결과물을 먼저 보여 주는 이유
이것이 이 스터디가 매번 결과물부터 보여 주는 방식으로 진행된 이유입니다. 순서를 그림으로 옮기면 이렇게 됩니다.
진행자가 수업마다 결과물을 먼저 펼쳐 놓은 이유가 이 순환의 첫 칸에 있습니다.
이제는 검증할 수 있다
전문가가 아니어도 괜찮은 이유도 함께 짚었습니다. 내가 전문가가 아니더라도 몇 차례 되물으면 검증이 됩니다. 진행자는 1년 전만 해도 답이 모호했지만 지금은 검증할 수 있다는 점을 분명히 했습니다.
③한 번 더 하는 사람이 드물다
한 참가자가 평소 하던 말이 인용됐습니다 — "AI는 기세다." 진행자는 자신이 쓰는 뜻은 조금 다르다며 이렇게 설명했습니다.
"뭔가 한 차례 더 해 보면 돼요. 근데 안 하거든요, 사람들이. 대부분."
1교시 · "AI는 기세"에 대해
구체적인 예도 들었습니다. 누군가 자료를 던져 줬을 때, "내가 이해할 수 있도록 조금만 설명해 줘"라고 한 번만 더 요청하면 이해할 수 있는 형태로 다시 만들어 줍니다. 그런데 대부분 그 한 번을 하지 않습니다.
알려 주지 않으면 모르는 것들 — 진행자는 이렇게 덧붙였습니다. "그런 걸 원래 누군가 알려 주지 않으면 모르잖아요." 그래서 받은 것을 한 번 더 뒤져 보는 노력이 중요하다고 했습니다.
④팀 — AI가 경계를 지운다
이야기는 개인에서 팀으로 넘어갑니다. 진행자가 물었습니다 — "회사는 왜 팀을 만들어 줄까요?" 참가자의 답은 "혼자선 안 되니까"였습니다.
전통적인 팀 구성은 역할로 나뉘어 있습니다.
역할 1
기획 — 무엇을 만들지 정한다
→
역할 2
디자인 — 어떻게 보일지 만든다
→
역할 3
개발 — 실제로 동작하게 만든다
진행자는 자기 팀에서 실제로 일어난 변화를 이야기했습니다.
시기
팀 안에서 벌어진 일
AI를 다루기 전
역할 사이의 경계가 굉장히 뚜렷했고, 그 경계 때문에 내부 갈등도 많았습니다. 오해를 푸는 데 진행자도 고생을 많이 했다고 했습니다
6개월쯤 지난 뒤
모두가 AI 쓰는 법을 어느 정도 이해하게 되자, "경계가 좀 허물어져도 괜찮겠다"는 인식이 생기기 시작했습니다
팀의 정의 — 진행자의 정리는 이랬습니다. 팀이란 서로 다른 사람들이 모여 서로를 보완하면서, 그 팀이 가진 목표를 결과로 만들기 위해 결성하는 것입니다. 그리고 리더의 역할은 목표를 향한 방향을 설정해 주고, 보완하고, 원하는 결과를 가져가는 것이라고 했습니다.
경계가 허물어지면 배움도 오간다
발표 자료를 만들 때 디자인 담당자에게 물어봤던 일화가 좋은 예로 나왔습니다. 돌아온 답은 이랬습니다.
"16 대 9"라고만 하면 AI가 모호하게 처리할 수 있습니다
같은 비율이라도 정확한 가로·세로 픽셀 수치를 지정하는 편이 훨씬 정확합니다
진행자는 "그러니까 그런 것 정도 배우기도 했다"고 했습니다. 경계가 낮아지면 서로의 전문성이 이런 형태로 건너옵니다.
⑤배려 — 기준이 명확해야 한다
진행자는 협업에서 가장 중요한 한 단어로 배려를 꼽았습니다.
"AI 잘 쓰는 것도 중요한데, 잘 쓰면서 협업을 잘하려면 이 배려라는 한 단어가 되게 중요합니다."
1교시 · 함께 일하는 것에 대해
다만 배려는 마음가짐이 아니라 판단이라는 점을 분명히 했습니다 — "배려의 기준도 명확해야 된다." 예시는 그날 수업 자체였습니다.
수업을 오전 9시에 시작한 이유 — 참가자 한 사람이 그날 저녁 기차로 이동해야 했고, 저녁 식사 일정까지 있었습니다. 시간을 역산해 보니 저녁에 시작해서는 맞출 수 없다는 판단이 나왔고, 그래서 아침으로 옮긴 것이 배려였습니다. 진행자의 정의는 이렇습니다 — "자기가 꼭 해야 되는 게 아닌데, 상대방 입장을 생각해서 한 번 더 이야기해 보는 것."
다른 참가자에게서 "9시에 하면 회사 출근하는 거랑 똑같은데 왜 해야 하냐"는 반응이 나왔던 것도 그대로 언급됐습니다. 한 사람을 향한 배려가 다른 사람에게는 부담이 될 수 있다는 것까지가 이 이야기의 일부였습니다.
⑥신뢰 — 팀 안의 안정감
배려가 쌓이면 신뢰가 됩니다. 진행자는 자기 팀원들이 어떤 상태인지를 이렇게 설명했습니다 — "무슨 일이 있어도 그래도 막아 줄 거라고 생각하는 것." 그것이 팀 안의 안정감이라고 했습니다.
"저는 내 평판보다 팀 안에서 잘 굴러가는 게 더 좋아요."
1교시 · 평판과 팀 사이에서
시야가 넓어지면 사소한 것에 매이지 않는다
여기서 독수리와 참새 비유가 나왔습니다. 참새는 떼 지어 다니고 그 안에서 시끄럽지만, 독수리는 그들이 무슨 생각을 하는지 아예 생각하지 않는다는 것입니다.
진행자의 정리 — "그 단계로 올라가면 밑에 있는 사소한 것들을 생각하지 않게 됩니다." 자기가 어울리는 환경이 중요하고, 시야가 넓어졌을 때 무엇을 신경 쓸지가 달라진다는 이야기였습니다.
⑦개방 — 자료를 던지지 않는다
진행자는 신뢰를 쌓은 다음 단계를 "개방"이라고 불렀습니다. 그리고 그 개방이 실제로 어떤 행동인지를, 그날 있었던 일로 설명했습니다.
이렇게 하면
링크만 툭 던진다
받는 사람은 무엇을 해 달라는 건지 다시 물어야 합니다. 상대 팀도 바쁘기 때문에 우선순위에서 밀립니다.
이렇게 하면
한 번 정리해서 전달한다
내가 지금 무엇이 필요한지를 다듬어 전달합니다. "제대로 부탁하는 것"이 되고, 상대에게 진정성으로 읽힙니다.
"별거 아닌 것 같아도 액션을 한 번 더 취해서 뭔가 다듬어서 전달해 주잖아요. 그 사람에 대한 진정성이 느껴져서, 그때부터 좀 신뢰 라인이 쌓여요. 진짜 어려워요, 근데."
1교시 · 개방과 진정성에 대해
진행자 본인도 같은 기준을 적용한다고 했습니다 — 경영진에게 무언가를 넘길 때도 다 검토하고 다듬어서 넘긴다는 것입니다.
알아보는 사람은 알아본다
참가자가 자기 경험을 꺼냈습니다. 예전에 고객 의견을 팀에 공유할 때, 상대 팀이 최대한 이해할 수 있게 말로 풀어 쓰느라 시간을 많이 들였다는 이야기였습니다.
그 정성이 실제로 전달됐다는 것이 이 일화의 핵심입니다 — "최대한 알 수 있게 하려고 한다니까, 그게 느껴진다고 그렇게 얘기해 줬어요." 진행자도 "그게 그 사람을 좋게 본 지점 중 하나"라고 확인해 줬습니다.
⑧이 시간을 한 장으로
혼자
한계를 긋지 않는다
해 보기 전에 결론을 내리지 않습니다. 되는 걸 봤으면 시도하고, 시도했으면 한 번 더 합니다.
도구를 하나도 다루지 않은 교시. 한 달 동안 왜 그렇게 시켰는지를 회수하고, 사람에게 남는 것이 무엇인지로 마무리한 시간.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭까지만 표기하고 진행자 이름은 쓰지 않습니다.
이번 교시에는 사내 인사·조직에 관한 대화가 상당 부분 포함돼 있었습니다. 그런 구간은 내용을 옮기지 않고 자리만 표시했습니다.
①수업 전 — 도구와 환경 이야기 00:00 – 00:05
00:00
교안 제외 — 개인 기기·사내 사정에 관한 잡담
수업 시작 전 노트북 환경 설정과 사내 사정에 관한 대화가 이어졌습니다. 스터디 내용과 무관하고 개인·조직에 대한 언급이 포함돼 있어 기록하지 않습니다.
②세 원칙을 다시 묻다 00:05 – 00:07
00:05
"1주차에 세 개를 꼭 지켜야 된다고 했죠?"
마지막 주차라는 말과 함께 진행자가 첫 질문을 던졌습니다. 대답이 하나씩 나왔습니다.
첫 번째 — 내려놓는다. 진행자가 덧붙였습니다. "내려놓고 일단 시키는 대로 한다"
세 번째 — 이해가 안 돼도 일단 따라 한다
두 번째 — 그 자리에서 아무도 떠올리지 못했습니다
두 번째가 무엇이었는지는 끝까지 언급되지 않았고, 대화는 다음으로 넘어갔습니다.
00:06
"생각 안 나면 잘 지키는 거 아닙니까?"
기억나지 않는다는 말에 진행자가 웃으며 받았습니다. 참가자도 "매일 그러거든요"라고 답했고, 진행자가 이어받았습니다 — "맞아, 매일 하잖아. 매일 하니까."
"한 번도 빼먹은 날은 없어요."
매일 한다는 것이 실제로 어땠는지도 이어서 이야기했습니다. 진행자에게 클로드 코드는 업무 그 자체여서 근무 시간에 하기가 어려웠고, 퇴근 후에 최대한 많이 했다고 했습니다. "너무 피곤했다"는 말과 함께, 가족이 "그렇게 매일 하는 게 신기하다"고 했다는 이야기도 나왔습니다.
③21일과 습관 00:07 – 00:09
00:07
왜 한 달이었나
진행자가 "원래 보통 한 달을 잡는다"고 하며 21일이라는 숫자를 꺼냈습니다. 한 달을 네 주로 놓으면 첫 주는 시작하는 주이고, 그다음 3주가 실제로 액션하는 구간이라 그 사이가 21일이 된다는 설명이었습니다.
참가자가 "3주 정도 하니까?", "익숙해지는 데 걸리는 시간이니까"라고 답을 시도했습니다.
00:08
날짜가 아니라 횟수 — 그리고 두 가지 방향
진행자는 21일이라는 숫자 자체가 중요한 건 아니라고 선을 그었습니다. "그 횟수가 중요한 것"이고, 실제로 하지 않고 머릿속으로 시뮬레이션을 돌려도 습관은 형성된다고 했습니다.
이어서 이 시간의 핵심이 나왔습니다. 사람이 습관을 만드는 데는 두 가지 방향이 있습니다.
사고의 방향 — 생각이 먼저 바뀌고 행동이 따라오는 것
계획과 절차의 방향 — 절차를 만들어 그대로 지키며 반복하는 것
"근데 습관이 되는 건 후자예요. 계획과 절차를 그대로 지켜 가면서 3주 동안 매일매일 반복하면, 내가 그걸 인지해서 사고가 좀 바뀝니다."
그다음 단계도 이어졌습니다 — 3주를 하면 세 달을 할 수 있는 습관이 생기고, 세 달을 하고 나면 3년을 할 수 있다고 했습니다. 그래서 요구가 두 문장으로 정리됐습니다.
"무조건 따라서 해라. 그리고 매일 아침에 클로드 코드로 해라."
00:09
"떡밥을 회수하는 거예요"
진행자가 이날 수업의 성격을 밝혔습니다 — "내려놓고 그걸 무조건 해 봐라, 이해가 되든 안 되든 간에. 그런 게 오늘 얘기할 핵심입니다." 그리고 덧붙였습니다. "처음에 떡밥 뿌린 걸 이제 회수하는 거예요."
④지난 과제 회고 00:09 – 00:23
00:09
교안 제외 — 사내 1대1 면담 과제에 대한 상세 회고
지난주 과제로 진행된 팀원들과의 1대1 면담에 대해 약 14분간 이야기가 오갔습니다. 개인에 대한 평가와 사내 인사·조직 사정이 대부분이어서 내용은 옮기지 않습니다.
다만 왜 그 과제를 냈는지에 해당하는 부분은 뒤의 배려·신뢰 주제와 이어지므로, 그 맥락에서 태도 문서에 정리했습니다. 요지는 원격으로 협업하게 될 사이일수록 라포가 먼저 쌓여 있어야 한다는 것이었습니다.
00:23
"AI가 대체하기 힘든 게 뭘까요"
회고를 마치며 진행자가 이날의 주제를 예고했습니다. 참가자가 예전에 먼저 물었던 질문을 다시 꺼낸 것입니다.
"그걸 물어보시길래, 아 그걸 또 고민하고 계시는구나. 마지막에 중요한 건데."
그때 진행자가 준 답은 사람과 사람이 만나서 해야 하는 것들이었습니다. 이 주제는 1교시 마지막에 다시 열립니다.
⑤이번 주에 AI를 어떻게 썼나 00:25 – 00:31
00:25
봇에게 자동화를 계속 붙였다
주리 님이 먼저 답했습니다. 3주차에 붙인 봇이 그사이 많이 개선돼서 시킬 수 있는 자동화를 계속 늘렸다고 했습니다.
아티클을 먼저 보내 주고 요약과 업무와 연결되는 인사이트까지
업무일지 — 예전에는 스킬을 써서 파일로 만들던 것
그날의 작업 세션을 봇이 읽고 다음 날 아침에 개선점과 프롬프트 제안을 보내 주는 구조
배움이 온 곳도 밝혔습니다. 서브 에이전트나 병렬 에이전트를 시키면 메인이 하위 에이전트에게 주는 프롬프트가 보이는데, 그것이 진행자가 쓰는 방식과 거의 같더라는 것이었습니다.
"길게 맨날 설명하고, 뭐가 필요하고 이렇게 하는 거. 그런 것도 이 세션을 통해 배우면서 '아, 이렇게 쓰는구나' 해서 저는 꽤 많이 한 것 같습니다."
00:27
1년 전에는 그 과정이 다 보였다
진행자가 배경을 덧붙였습니다. 1년 전만 해도 에이전트를 여러 개 두고 쓰는 방식이 흔하지 않아서 AI가 스스로 프롬프트를 쓰는 과정이 그대로 보였다고 했습니다. 개발팀과 일할 때도 "이걸 계속 보는 것도 느는 방법"이라고 반복해 말했다고 합니다.
지금은 그 과정이 아래 단계에 감춰져 있지만, 들어가 보면 지금 무엇을 어떻게 시키고 있는지가 나온다고 했습니다.
00:27
마크다운은 프롬프트 기법이다
에이전트가 만들어 내는 문서에 일정한 구조가 있다는 이야기로 이어졌습니다. 제목이 있고, 순서가 있고, 끊어 주는 지점이 있는 "하이어라키 구조"입니다. AI가 이해하기 좋은 방식으로 AI가 명령을 내리고 있는 것입니다.
참가자가 물었습니다 — "샵샵이랑, 점점점이랑, 이렇게 끊는 거랑 무슨 차이예요?" 답은 이랬습니다.
코드 블록 — 스크립트나 코드를 통째로 넣었을 때, "그냥 복사해 온 데이터"임을 알 수 있게 영역을 잡아 주는 것
구분선 — 위는 넣어 준 데이터, 아래는 내가 하는 설명이라고 끊어 주는 것
"다 적는다고 해서 AI가 이해를 못 하는 건 아니에요. 그런데 내가 명령 내리는 것과 그 안에 들어가 있는 것이 섞여 있으면 명확하지 않을 수가 있거든요."
진행자는 이것을 "그냥 기법"이라고 했습니다 — "간단하게 써 보면 아, 이렇구나 하고 아는 것들"입니다. 이미 구분선만 쓰고 있다는 참가자에게는 "그렇게 해도 되고, 그렇게까지 잘게 끊지 않아도 상관없다"고 답했습니다.
00:30
봇이 엉뚱한 곳으로 메시지를 보냈다
한 참가자가 겪은 일을 이야기했습니다. 특정 봇에게 시킨 작업을 다른 봇이 읽고, 그 내용을 개인 메시지로 대신 보내온 상황이었습니다. 진행자의 답은 짧았습니다 — "요새 관리를 안 해서 그렇다."
⑥문서 업무를 통째로 맡겨 보다 00:31 – 00:40
00:31
신청 서류 — 손대지 않고 승인까지
동현 님의 차례였습니다. 지원사업 신청 서류를 문서로 만드는 작업을 맡겼는데 "제가 건드린 건 없어요"라고 할 만큼 그대로였고, 한 번 정도 수정해 제출하니 바로 승인이 났습니다.
"와, 이거 조금 내가 잘만 쓰면 진짜 문서 혁신을 할 수 있겠다."
00:32
가장 싫어하던 발표 자료를 만들다
발표 자료 만드는 일을 가장 싫어한다고 밝히며, 이번에 하반기 전략 자료를 AI로 만들어 본 과정을 이야기했습니다. 거의 에세이처럼 길게 쓴 첫 세션이었다고 합니다.
참고 링크를 주고 먼저 이해시켰습니다
왜 그 지역으로 가는지, 어떤 상황인지, 언제부터 언제까지 어떤 전략인지 설명했습니다
보유한 레퍼런스와 제품별 상황까지 맥락을 최대한 넣었습니다
에이전트 팀을 꾸리고 디자인 템플릿도 함께 줬습니다
분량이 커서 컨텍스트를 두 번 압축할 정도였고, 소감은 솔직했습니다.
"진짜 힘들었거든요. 생각보다. 아, 이거 그냥 다른 도구 돌리고 내가 수정하는 게 쉬울 수도 있겠다 싶을 정도로."
수정 작업 때문에 스크린샷 도구를 새로 구매했다는 이야기도 함께 나왔습니다.
00:33
외부 미팅에서 이야기가 통했다
업무 외의 경험으로 외부 미팅 뒤의 대화를 꺼냈습니다. 기술 쪽 임원과 따로 이야기할 기회가 생겼는데, 상대가 자신의 작업 환경을 보여 줬습니다. 예전이라면 하나도 이해하지 못했을 내용이었습니다.
LLM 위키화와 구조에 대해 서로 의견을 주고받았습니다
파싱·청킹 같은 용어가 나왔을 때 알아들었고, "아버지 가방에 들어가셨다"는 예시로 청킹을 설명해 대화가 이어졌습니다
지식베이스 구조를 설명하는 자리에서는, 개발 담당자에게 미리 쉽게 설명해 달라고 부탁해 배운 것을 그대로 전달했습니다
상대의 반응은 "그것도 알아요? 이것도 알아요?"였습니다. 본인의 소감은 이랬습니다.
"어, 이런 거는 보는 눈이 살짝 생겼구나."
진행자가 덧붙였습니다 — "그걸 이해하고 설명할 수 있다는 게 엄청 큰 능력인데, 그게 쉬운 것도 아니잖아요."
00:39
협업 도구를 옮긴 것도 성과
화상 회의로 하자는 제안에 메신저에서 다 된다고 설득한 이야기가 나왔습니다. 유료 계정이라 AI 노트로 회의 요약이 생성되고, 붙여 둔 봇이 지난 대화를 찾아 줄 수 있다는 점을 근거로 들었습니다.
본인 표현으로는 "미진하지만, 우리 팀도 메신저로 갈아탄 것 자체가 큰일"이었습니다.
⑦결과물을 함께 열어 보다 00:40 – 00:53
00:40
"창피해요" — 그래도 연다
만든 자료를 보여 달라는 요청에 "너무 창피해서", "이거 날것이잖아요"라는 반응이 먼저 나왔습니다. 다른 참가자들이 받아쳤습니다 — "원래 창피한 걸 내려놔야 돼요", "날것이라도 지나가야 돼요."
00:42
자료의 뼈대
화면에 띄운 자료의 구성은 이랬습니다.
목차 → 요약(숫자를 앞에 세움)
지역 전략과 그렇게 판단한 근거 데이터
로드맵과 요청 사항으로 마무리
피드백이 이어졌습니다 — "맥락을 많이 잘 넣으셨네요", "되게 설득력 있게 하신 것 같아요", "잘 만들었는데요." 진행자의 평은 이랬습니다.
"하이어라키가 잘 잡혀 있고 설명하기 쉽게 돼 있고 보기 편하게 돼 있잖아요. 기승전결도 잘 돼 있고."
00:49
4주차 과제 예고
중간에 진행자가 이번 주 과제를 짚었습니다. 지금 녹음하고 있는 이 수업을 다시 교안으로 만들 것이라는 전제였습니다.
"처음 시작할 때 3주차 만든 것처럼 4주차도 전사를 줄 테니까 준비하고 있으라고 말해 놓고, 나중에 밥 먹을 때 교안만 던져 놓으면 나올 거예요."
지금 보고 있는 이 문서가 그 과제의 결과물입니다.
00:50
"AI스럽지 않았어요"
만든 사람은 "AI로 만들어서 부족하거나 AI스러워 보일 수 있다"고 미리 양해를 구했는데, 평가는 반대였습니다 — "오히려 AI스럽지 않았어요", "좀 날것 같았어요."
이유가 있었습니다. 지난 수업에서 AI스러운 표시로 지목된 요소들을 만들기 전에 미리 빼 달라고 요청해 두었기 때문입니다. 진행자가 확인해 줬습니다 — 많이 본 사람은 그런 요소를 보면 "그냥 AI로 찍어냈네" 하고 알아채기 때문에 처음부터 빼는 편이 낫다는 것입니다.
아쉬운 점으로는 글꼴이 전체에 통일되지 않은 것 하나가 꼽혔고, 진행자의 정리는 이랬습니다.
"예쁘게 만든다고 그게 중요합니까. 어차피 잘 전달되면 되지."
같은 데이터로 진행자의 제안서 스타일을 접목한 버전도 만들어 봤지만, "이게 되나" 확인하는 테스트였고 실제 발표는 원래 자료로 했다고 밝혔습니다.
⑧태도 — 한계를 긋지 않는다 00:53 – 01:00
00:53
"자기가 한계를 스스로 긋지 않는 게 중요합니다"
진행자가 태도 이야기를 시작했습니다. 해 보기도 전에 "이건 안 될 거야"라고 결론 내리는 것을 경계했습니다. 참가자가 예를 들어 확인했습니다 — "차라리 내가 하는 게 더 빠르지, 이런 애초에 한계? 그런 건가요?"
진행자는 "그런 것도 있고"라며 다른 예를 들었습니다. 어떤 사안을 "이건 내가 알 게 아니다"라고 넘기는 경우입니다. 일차적으로 자기가 다 해 보면 알 수 있는 것인데도 그렇게 한다는 것입니다.
"스스로 자기가 한계를 딱 끊어 놓고 나는 여기까지야 해 버리면, 그 뒤로 이어 가기가 쉽지가 않아요."
00:54
팀이란 무엇인가
이야기가 팀으로 넘어갔습니다. 진행자가 물었습니다 — "회사에서 왜 팀을 만들어 줄까요?" 참가자의 답은 "혼자선 안 되니까"였습니다.
전통적인 구성은 기획 · 디자인 · 개발로 나뉘어 있습니다. 진행자는 자기 팀의 변화를 이야기했습니다 — AI를 다루기 전까지는 경계가 굉장히 뚜렷했고 갈등도 많았지만, 6개월쯤 지나 모두가 AI 쓰는 법을 이해하게 되자 "경계가 좀 허물어져도 괜찮겠다"는 인식이 생겼다는 것입니다.
"팀이라는 건 서로 다른 사람들끼리 모여서 서로를 보완하면서, 이 팀이 가지고 있는 목표를 결과로 만들기 위해 결성을 하는 거예요."
리더의 역할도 함께 정리됐습니다 — 방향을 설정해 주고, 보완하고, 원하는 결과를 가져가는 것.
00:57
디자인 담당자에게 배운 것
발표 자료를 만들 때 디자인 담당자에게 물어봤던 일화가 나왔습니다. "16 대 9"라고만 하면 AI가 모호하게 처리할 수 있으니, 정확한 가로·세로 픽셀 수치를 지정하는 편이 더 정확하다는 조언이었습니다.
00:59
되는 걸 알아야 시도한다
왜 수업마다 결과물을 먼저 보여 줬는지에 대한 답이 여기서 나왔습니다.
"원하면 만들 수 있다는 걸 알아야 이걸 할 수 있죠. 그래서 제가 일부러 보여 주는 거예요."
이어서 전문가가 아니어도 몇 차례 되물으면 검증이 된다는 점을 짚었습니다. 1년 전만 해도 답이 모호했지만 지금은 검증할 수 있다는 것입니다. 그리고 커트라인을 만들지 말라, 자기 자존을 낮추지 말라는 말이 이어졌습니다.
"제안만 하지 않고 액션을 해서 만들어 낸 순간, 자기 평가가 하나씩 들어와서 사람들이 '아, 저렇게까지 하는구나'를 알게 되는 거예요."
01:00
"AI는 기세" — 한 번 더 한다
한 참가자가 평소 하던 말이 인용됐습니다. 진행자는 자기가 쓰는 뜻은 조금 다르다며 이렇게 말했습니다.
"뭔가 한 차례 더 해 보면 돼요. 근데 안 하거든요, 사람들이. 대부분."
예시도 들었습니다 — 자료를 받았을 때 "내가 이해할 수 있게 조금만 설명해 줘"라고 한 번만 더 요청하면 이해할 수 있는 형태로 다시 만들어 주는데, 그 한 번을 하지 않는다는 것입니다.
⑨배려 · 신뢰 · 개방 01:02 – 01:12
01:02
배려에는 기준이 있어야 한다
진행자가 협업의 핵심 단어로 배려를 꼽았습니다 — "AI 잘 쓰는 것도 중요한데, 잘 쓰면서 협업을 잘하려면 이 배려라는 한 단어가 되게 중요합니다."
예시는 그날 수업 자체였습니다. 참가자 한 사람이 저녁에 기차로 이동해야 했고 저녁 식사 일정도 있었는데, 시간을 역산해 보니 저녁 시작으로는 맞출 수 없다는 판단이 나와 오전 9시로 옮긴 것입니다.
"자기가 꼭 해야 되는 게 아닌데 상대방 입장을 생각해서 좀 더 얘기를 해 본다든지 하는 거."
동시에 다른 참가자에게서 "9시에 하면 회사 출근하는 거랑 똑같은데 왜 해야 하냐"는 반응이 있었다는 것도 그대로 언급됐습니다. 진행자는 "배려의 기준도 명확해야 된다"고 정리했습니다.
01:06
신뢰 — 팀 안의 안정감
팀원들이 "무슨 일이 있어도 그래도 막아 줄 거라고 생각하는 것", 그것이 팀 안의 안정감이라고 했습니다.
"저는 내 평판보다 팀 안에서 잘 굴러가는 게 더 좋아요."
이어서 독수리와 참새 비유가 나왔습니다. 참새는 떼 지어 다니지만 독수리는 그들이 무슨 생각을 하는지 아예 생각하지 않는다는 것입니다 — "그 단계로 올라가면 밑에 있는 사소한 것들을 생각하지 않게 됩니다."
01:09
개방 — 자료를 던지지 않는다
진행자는 신뢰 다음 단계를 개방이라 불렀고, 그것이 실제로 어떤 행동인지를 그날의 일로 설명했습니다. 링크만 툭 던지는 것과, 내가 지금 무엇이 필요한지를 다듬어 전달하는 것의 차이입니다.
"별거 아닌 것 같아도 액션을 한 번 더 취해서 다듬어 전달해 주잖아요. 그 사람에 대한 진정성이 느껴져서, 그때부터 신뢰 라인이 쌓여요. 진짜 어려워요, 근데."
진행자 자신도 같은 기준을 적용한다고 했습니다 — 경영진에게 넘길 때도 다 검토하고 다듬어서 넘긴다는 것입니다.
01:10
정성은 전달된다
참가자가 자기 경험을 꺼냈습니다. 예전에 고객 의견을 팀에 공유할 때 상대 팀이 최대한 이해할 수 있게 말로 풀어 쓰느라 시간을 많이 들였다는 이야기였습니다. 그리고 그 정성이 실제로 전달됐습니다.
"최대한 알 수 있게 하려고 한다니까, 그게 느껴진다고 그렇게 얘기해 줬어요."
진행자도 "그게 그 사람을 좋게 본 부분 중 하나"라고 확인해 줬습니다.
⑩AI가 대체하기 힘든 것 01:13 – 01:15
01:13
마지막 장 — 습관 · 대체 · 신뢰
마지막 화면을 넘기며 세 단어가 언급됐습니다 — 습관 · 대체 · 신뢰. 그중 대체를 두고 참가자가 답을 이어 갔습니다.
"AI가 대체하기 힘든 것. 방향 설정하는 거. 그리고 책임지는 거."
진행자는 책임에 단서를 붙였습니다 — "책임지는 건 어차피 자기 역할이고, 자기를 쓰는 사람이 그건 책임져야지." 그리고 정말 어려운 것을 짚었습니다.
"근데 사람의 마음을 얻는 건 힘들죠. 사람이라는 게 감정이 들어가고, 느껴지는 게 있잖아요."
01:13
육감
진행자가 오감에 하나를 더했습니다.
"저는 하나 더 있다고 생각하는 게 육감이거든요. 쎄함, 이런 거. 알아듣고 하는 것들."
참가자가 바로 동의했습니다 — "그게 제일 중요하지. 육감이 제일 중요해." 진행자는 "약간 눈치라고 할 수도 있고", "말로 표현하기가 되게 애매한 식스센스"라고 표현을 이어 갔습니다.
그리고 왜 이것만 다른지를 감각별로 짚었습니다 — 비전도 나오고, 후각도 가스 감지 센서처럼 나오고, 촉각도 터치 센서로 되는데, 육감은 다른 것 같다는 것입니다. 마무리는 현실적이었습니다.
"그나마 만나면서 비즈니스를 해야 되니까."
01:15
1교시 종료
쉬는 시간을 잡으며 1교시가 끝났습니다. 2교시는 진행자가 실제로 만들고 있는 것을 보여 주는 시간으로 이어집니다. → 2교시 강의기록
의사결정 OS — 레퍼런스를 판단 근거로 바꾸다
4주차 2교시는 진행자가 실제로 만들고 있는 것을 화면에 띄우며 시작했습니다. 첫 문장이 이것이었습니다 — "하반기 전략으로 가장 중요한 게, 우리만의 의사결정 OS를 만드는 거예요."
OS는 운영체제입니다. 여기서는 의사결정을 해 줄 수 있는 시스템이라는 뜻으로 썼습니다.
한 줄 요약
이미지를 모으면 참고 자료지만, 왜 그렇게 만들었는지까지 데이터로 만들면 판단 근거가 됩니다.
①문제는 "전문가가 없는 영역"이다
왜 그런 시스템이 필요한지부터 이야기가 시작됐습니다. 지금까지 해 온 분야가 아닌 새로운 분야로 제품을 넓혀야 하는 상황이 문제였습니다.
"제조도 해야 하는데, 그럼 제조는 어떻게 설계해야 할지가 필요하잖아요. 건설이랑 다르잖아요. 그걸 어떻게 개발할 거예요? 전문가도 없는데."
2교시 · 왜 의사결정 시스템이 필요한가
익숙한 해법은 그 분야 전문가를 데려오는 것입니다. 이 시간에 나온 접근은 달랐습니다 — 잘 만들어 놓은 것들이 이미 세상에 있으니, 그것을 판단 근거로 삼을 수 있는 형태로 바꿔 두자는 것입니다.
②참고 자료와 판단 근거의 차이
진행자가 화면에 띄운 것은 서비스 화면 아카이브였습니다. 국내외 서비스의 화면과 기획이 방대하게 모여 있는 곳들입니다. 그리고 물었습니다 — "이런 걸 다 가지고 있다는 게 어떤 의미일까요?"
참가자의 답은 자연스러웠습니다 — "레퍼런스 참고?" 진행자가 바로 선을 그었습니다.
"근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요."
2교시 · 이미지의 한계
이미지만 있을 때
참고 자료에서 멈춘다
AI가 판단을 하지 못합니다. 형식에 맞는 카테고리를 찾아 주는 정도가 전부입니다. 결국 사람이 눈으로 보고 골라야 합니다.
이유까지 있을 때
의사결정 근거가 된다
왜 이 구조인지, 왜 이 레이아웃인지, 무엇을 강조했는지가 함께 있으면 — 전문성이 없어도 판단할 수 있습니다.
진행자의 설명은 구체적이었습니다. AI가 이미지를 하나하나 인식해서 "이 사람이 이 구조를 왜 가지고 있고, 레이아웃을 왜 이렇게 짰는지"를 데이터로 함께 들고 있으면, 무언가를 만들 때 마주치는 의사결정 사항들에 대해 근거를 가지고 결정할 수 있게 됩니다. 나아가 그 레퍼런스를 근거로 화면 구조까지 뽑아낼 수 있습니다.
③수집이 곧 일이다
말은 간단하지만 가져오는 일 자체가 큰 작업이라는 점을 진행자가 강조했습니다.
접근 — 토큰을 받아 API로 가져오는 방법이 있고, 막혀 있으면 페이지에 하나하나 접근해 브라우저에서 추출합니다
정리 — 끌어온 것을 그대로 두면 쓸 수 없으니 정리합니다. 함께 붙어 있는 설명 내용까지 가져옵니다
해석 — 이미지를 읽는 모델로 무엇이 어떻게 구성돼 있는지 다시 정리합니다
위키화 — 결과를 노트 도구에 위키 구조로 쌓습니다. "사진마다 다 꺼내 놓는" 작업입니다
이 작업의 비용 — 진행자는 이 작업 때문에 도구 사용량 한도에 걸렸고, 필요한 구독을 추가로 결제했다고 했습니다. 참가자의 반응은 "저게 엄청 시간과 공이 많이 들어가요"였습니다. 방법을 아는 것과 실제로 해내는 것 사이의 거리가 여기서 드러납니다.
위키화가 없으면 검색이 되지 않는다
왜 굳이 위키 구조로 다시 쌓는지도 짚었습니다. 원래는 위키화를 하지 않고 자료만 모아 뒀는데, 이번에 구조를 바꿨다고 했습니다.
"사진만 들고 있으면 AI가 그걸 판단을 못 해요. 지금 가지고 있는 자료들은 그냥 카테고리만 찾는 거예요. 이 형식에 맞는 카테고리만."
2교시 · 위키화를 한 이유
3주차의 LLM 위키와 지식 그래프에서 다룬 것이 바로 이 구조입니다. 3주차에는 내 대화와 규칙을 위키화했다면, 4주차에는 외부에서 모은 자료를 같은 방식으로 위키화하는 이야기입니다. 쌓는 방식은 같고 대상만 달라졌습니다.
④자기 제품부터 뜯어 본다
외부 자료보다 먼저 한 것이 있었습니다 — 자기 회사 제품을 통째로 분석한 것입니다. 방법은 단순했습니다. 계정 정보만 주고, 시스템이 어떻게 되어 있는지 전부 파악하게 했습니다.
무엇을
어디까지
데이터 구조
어떤 데이터가 어떤 형태로 들어가 있는지
워크플로우
업무가 어떤 순서로 흘러가는지
동작
무엇을 누르면 무엇이 일어나는지
화면
화면을 전부 띄워서 왜 이렇게 구성돼 있는지까지. 선택 항목에 어떤 값이 들어가는지 수준으로 세밀하게
API 구조
내부적으로 어떤 구조로 주고받는지
진행자가 강조한 것은 한 번 해 두면 방식이 남는다는 점이었습니다 — "한 번 뜯어 놨으니까, 이 방식이 있으니까" 다음 대상은 같은 절차로 반복할 수 있습니다.
이 시간에 함께 나온 질문 — 같은 방식을 비교 대상이 되는 다른 서비스에도 적용하는 구상이 이어지자, 참가자가 "법적인 문제는 없느냐"고 물었습니다. 진행자도 가볍게 넘길 문제는 아니라는 뉘앙스로 답했고, 그 자리에서 결론이 나지는 않았습니다. 공개된 자료를 어디까지 어떻게 쓸 수 있는지는 시작 전에 확인해야 할 사안입니다.
⑤왜 이걸 하는가 — 기술 부채
2교시에서 가장 무겁게 다뤄진 이야기입니다. 초기의 의사결정이 잘못되면 그 대가를 오래 치른다는 것입니다.
"진짜 모래주머니 한 10킬로씩 달고 지금 일하고 있는 거예요."
2교시 · 기술 부채에 대해
상황은 이랬습니다.
디자인 시스템을 1년에 걸쳐 갈아엎었지만, 그 공백이 부채로 남았습니다
새 화면을 만들어 놔도 기존 구조와 맞지 않아 반영을 못 합니다
"차라리 프로젝트를 처음부터 다시 하면 훨씬 빠르다"는 말이 나올 정도입니다
참가자가 정리했습니다 — "초기에 잘못된 의사결정이 이렇게까지 부채가 돼서 돌아오는구나." 그 여파는 내부에서 끝나지 않고 쓰는 사람의 불편으로 이어집니다.
무엇이 잘못이었나
원인 1
전문성 없이 내린 결정
그 분야의 전문성을 갖춘 상태에서 한 것이 아니었습니다. 빨리 만들어야 한다는 압박도 겹쳤습니다.
원인 2
"이뻐 보이네"로 끝난 검토
보기에 괜찮다는 판단으로 마무리됐습니다. 진행자의 표현으로는 "UX가 없었던 것"입니다.
원인 3
남의 레퍼런스를 무시함
"얘네는 왜 이렇게 만들었어, 디자인 구리네"로 넘긴 것들. 그렇게 만든 이유가 있었을 텐데 보지 않았습니다.
가장 위험한 태도 — 진행자가 짚은 것은 이것이었습니다. "내가 잘하고 있는 분야, 잘 알고 있는 분야라고 해서 그게 정답이라고 생각하는 것이 위험하다." 잘하던 방식이 다른 성격의 시스템에서는 맞지 않을 수 있다는 뜻입니다.
그래서 만들려는 것
해법도 같은 자리에서 나왔습니다 — 잘 만들어진 것들을 전부 가져와 비교하고, 그것을 근거로 다시 설계한다는 것입니다.
참고 대상은 이미 잘 만들어진 서비스들, 그리고 공개된 디자인 시스템입니다
그쪽에서 어떤 의사결정을 했는지를 가져와 현재 상태와 비교합니다
비교 결과를 근거로 디자인 시스템을 다시 만들고 한 번에 교체합니다
기준은 하나입니다 — 감으로 하지 않고, 정확하게 만들어진 것을 따라간다
"우리 팀은 어떻게 보면 AI 잘 쓰고 AX를 잘 녹여내는 게 원툴이거든요. 근데 부족한 건 단단함이죠. 그런 걸 그쪽에서 잘 가져와서 우리 것을 녹여내면 되겠다."
2교시 · 무엇을 보완하려는가
⑥시야의 세 단계
이 시간에서 가장 좋은 정리는 참가자에게서 나왔습니다. 같은 레퍼런스를 놓고도 사람마다 도달하는 단계가 다르다는 것입니다.
참가자가 정리한 세 단계 — "제가 볼 때는 3단계가 최종 단계"입니다.
"도구가 다 주어져 있어도 누가 이걸 몇십 시간 들여서 싹 다 긁어낸다고 생각을 하겠어요."
2교시 · 3단계가 드문 이유
진행자는 여기에 이 시간의 목적을 붙였습니다.
"이런 것들이 한 단계 더 생각해 보면 될 수 있다는 걸, 이게 되는구나를 봤잖아요. 그럼 자기도 사고가 열리는 거거든요. 그런 시야가 보이는 게 중요해요."
2교시 · 왜 보여 주는가
1교시의 "되는 걸 봐야 시도한다"와 정확히 같은 이야기입니다. 1교시가 개인의 태도 차원이었다면 2교시는 일의 규모 차원에서 같은 말을 반복한 셈입니다.
⑦말이 아니라 결과로 설득한다
이 구상을 윗선에 설명한 경험도 공유됐습니다. 핵심은 순서였습니다.
말로만 하면
듣는 사람은 "또 이상적인 얘기하네"라고 생각할 수 있습니다
→
결과를 가져가면
"이렇게 되네, 진짜 될 수 있겠다"로 반응이 바뀝니다
→
그다음
판단은 결정권자의 몫으로 넘어갑니다
"이런 결과물을 가져와서 이게 된다는 걸 보여 주고 이야기를 해야 말이 통해요. 말만 했을 때는 또 이상향이네라고 생각할 수 있거든요."
2교시 · 설득의 순서
다만 결과물을 보여 준다고 해서 곧바로 확산되지는 않았습니다. 그 이유가 2교시의 나머지 절반입니다. → AX는 왜 잘 퍼지지 않는가
AX는 왜 잘 퍼지지 않는가
2교시 후반은 솔직한 이야기였습니다. 결과물을 만들어 보여 줬는데도 왜 조직은 잘 움직이지 않는가에 대한 것입니다.
스터디의 마지막 주제가 성공 사례가 아니라 확산의 어려움이었다는 점이 이 시간의 성격을 말해 줍니다.
한 줄 요약
보여 주는 것만으로는 부족합니다. 결핍이 없으면 움직이지 않고, 직접 해 보지 않으면 남의 일로 남습니다.
이 시간에 나온 진단
잘 되는 곳일수록 바꿀 이유가 없고(결핍), 배우려면 개인이 비용과 시간을 내야 하고(허들), 옆에서 보이지 않으면 관심도 생기지 않습니다(거리). 그리고 그 모두를 감싸는 것이 문화입니다.
①결핍이 없으면 움직이지 않는다
진행자가 지난주에 다른 곳에서 실제로 보여 줬던 이야기가 나왔습니다. "이거 된다, 이렇게 했다"고 시연했고 반응도 좋았습니다 — "대박이다", "하고 싶다". 그런데 거기서 멈췄습니다. 참가자가 한 단어로 정리했습니다.
"결핍이 없어서 그렇죠."
2교시 · 왜 안 움직이는가
진행자도 동의하며 덧붙였습니다 — "이미 이렇게 해도 잘 들어오는 게 있으니까." 바꿔야 할 이유가 지금은 없다는 뜻입니다. 실제로 나올 법한 생각을 진행자가 대신 말해 봤습니다.
바꾸지 않을 이유는 얼마든지 있습니다
· 지금 장사가 잘 되고 있다
· 고객들도 아직 AI를 그렇게 믿지 않는다
· 그런데 높은 연봉을 주고 전문 인력을 꾸려야 하나?
잘 되고 있다는 사실 자체가 가장 강력한 관성입니다.
②개인이 감당해야 하는 허들
더 현실적인 장벽은 배우는 비용을 누가 내는가였습니다. 진행자가 자기 팀 이야기로 예를 들었습니다.
"우리 팀조차도 하자. 근데 대신에 네가 구독해. 그러면 한 달에 그거 십몇만 원은 내 돈 주고, 그렇게 해서 내 주말 시간 빼서 배워야 돼. 여기서부터 허들이란 말이에요."
2교시 · 배우는 비용은 누가 내는가
그 사이에 조직의 반응은 "좋네, 우와 좋다"에서 멈춥니다. 좋다는 평가와 그것을 가능하게 하는 지원은 별개입니다.
실제로 든 비용 — 2교시에 시연한 작업을 위해 진행자는 도구를 개인적으로 구독했고, 사용량 한도에 걸려 추가 결제까지 했습니다. 회사 자원으로 가져온 것이 아니라는 점을 여러 차례 확인했습니다. 참가자의 반응이 이 상황을 요약합니다 — "그런 걸 별로 인정해 주지도 않으면서, 결과물만 보고 '오, 괜찮네' 하는 게 좀 그렇죠."
③직접 찔려 보지 않으면 모른다
이 시간에서 가장 선명한 비유가 여기서 나왔습니다.
"보여 주지만 결국 직접 느껴 보지는 않은 거예요. 진짜 칼로 이렇게 찔러 보진 않았으니까. 칼이 날카롭다는 건 아는데."
2교시 · 아는 것과 겪는 것의 차이
참가자의 진단도 같았습니다 — "직접 체험해 보고 직접 하려는 의지가 없는 이상 AX화는 안 되잖아요. 그게 첫 번째인 것 같고."
"내가 봤을 때는 무조건 이건 누군가의 문제라기보다, 문화가 그렇게 형성이 안 되어 있으니까 그런 거예요."
2교시 · 원인을 어디에 둘 것인가
구체적으로 지적된 것은 일하는 방식에 대한 관심의 부재였습니다.
결과만 보려고 한다 — 어떤 방식으로 그 결과가 나왔는지는 보지 않습니다
그래서 무엇을 지원해야 하는지도 알 수 없습니다
"AX를 전사적으로 하고 싶으면, 가장 잘하고 있는 팀을 보고 이렇게 해 보자고 하든가"라는 말도 나왔습니다
⑤오히려 백지가 더 잘 쓴다
흥미로운 반례가 하나 나왔습니다. 새로 합류한 사람이 가장 열심히 쓰고 있다는 것입니다.
관찰
하루 스무 번씩 요청을 보낸다
업무 도구에 붙은 봇에게 하루에 스무 개 가까이 요청을 보내며 씁니다. 경쟁 서비스 조사 같은 것도 직접 시킵니다. "이렇게 쓰는 사람 잘 없다"는 평이었습니다.
해석
기존 방식이 없어서
자기가 하던 스타일이 없고 프레시하니까 백지에 그대로 그어 나갑니다. 익숙한 방식이 없다는 것이 오히려 이점이 됩니다.
1주차의 첫 번째 원칙이 "내려놓는다"였던 이유가 여기서 다시 확인됩니다. 내려놓을 것이 없는 사람은 처음부터 유리합니다. 이미 방식이 있는 사람에게 내려놓기가 첫 과제인 것도 같은 이유입니다.
⑥보여야 퍼진다 — 거리의 문제
사무실 자리 배치 이야기가 나오면서 물리적 거리가 확산에 미치는 영향이 언급됐습니다.
"같은 자리에 있으면 여기서 이렇게 하니까 이게 나온다는 게 보이잖아요. 그럼 관심이 가고, 그렇게 해 보려는 노력이라는 게 생겨요."
2교시 · 왜 옆자리가 중요한가
진행자는 이것이 교육 자리를 만드는 것과는 다르다고 구분했습니다.
자리를 만들면
의지 있는 사람만 온다
이미 하고 싶은 사람들이 모입니다. 그 밖의 사람에게는 여전히 남의 일로 남습니다.
옆에 있으면
안 보려 해도 보인다
무엇을 어떻게 해서 저 결과가 나왔는지가 눈에 들어옵니다. 관심은 보이는 데서 시작됩니다.
다만 반응은 사람마다 갈린다고 했습니다 — "나도 하고 싶다"고 생각하는 사람이 있고, "어, 되네. 그럼 부탁하면 되겠다"고 생각하는 사람이 있습니다. 같은 것을 봐도 결론이 다릅니다.
⑦리소스를 어디에 쓸 것인가
2교시 마지막은 선택과 집중 이야기였습니다. 진행자는 그동안 필요하다는 요청을 받아 여러 개의 보조 도구를 만들어 왔습니다. 그런데 결과가 이랬습니다.
"근데 사실 만들어서 안 써요. 진짜 안 쓰거든요. 이것만 봐도 하나도 안 썼잖아요. 이런 거 만드는 데도 노력이 많이 들어가요. 리소스가."
2교시 · 만들어 준 도구들에 대해
그래서 하반기에는 더 이상 만들지 않겠다고 선언했다고 밝혔습니다. 대신 본업에 리소스를 쏟겠다는 것입니다. 쓸 사람은 직접 도구를 쓰면 된다는 이야기도 함께 나왔습니다.
못 하고 있는 일이 생긴다 — 부수적인 요청을 계속 받으면 정작 자기 역할을 못 하게 됩니다. 팀원에게서 "하반기에 하려는 것들이 태스크로 정리돼 있으면 미리 보고 이해할 텐데, 그게 준비가 안 돼 있어 아쉽다"는 피드백을 받았는데, 그것이 정확히 자기가 해야 할 역할이었다고 인정했습니다.
잘하는 사람에게 계속 맡기는 구조
맡기는 쪽 입장도 이해한다고 했습니다 — "맡겨 보면 퀄리티 잘 나오고 아웃풋 잘 나오는 사람한테 맡기면 좋지. 빨리빨리 나오고." 문제는 지속 가능성입니다.
"근데 언제까지 맡길까요."
2교시 · 잘하는 사람에게 몰리는 구조
⑧결론 — 태도의 차이
진행자가 이 모든 이야기를 한 문장으로 묶었습니다.
"그래서 태도의 차이라는 거예요. 해 봤냐고. 한 번 시도라도 해 봤냐고. 안 해 봤잖아요."
2교시 · 마무리
참가자가 여기에 스스로의 답을 붙였습니다. 이 스터디의 마지막 장면으로 남을 만한 대목입니다.
참가자가 정리한 태도
· 내가 하면 퀄리티는 당연히 못 나오겠지만
· 그래도 어쨌든 나오는 게 중요하니까 일단 내가 해 본다
· 그러고 나서 부탁하면 시간 소요가 덜 들 수도 있다
완성도가 아니라 시도가 먼저라는 것 — 4주 내내 반복된 이야기가 마지막에 참가자의 말로 돌아왔습니다.
실제로 만들고 있는 것을 화면에 띄워 놓고, "이게 된다는 걸 봐야 사고가 열린다"는 것을 직접 보여 준 시간.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 회사명·서비스명·개인 이름은 쓰지 않고 일반 표현으로 바꿔 옮겼습니다.
2교시는 절반 가까이가 사내 경영·인사에 관한 대화였습니다. 그런 구간은 내용을 옮기지 않고 자리만 표시했습니다.
①의사결정 OS를 만든다 00:00 – 00:02
00:00
첫 문장
쉬는 시간이 끝나고 진행자가 화면을 띄우며 바로 본론을 꺼냈습니다.
"하반기 전략으로 가장 중요한 게, 이제 우리만의 의사결정 OS를 만들 거예요."
참가자가 "운영체제"라고 받자, 진행자가 뜻을 분명히 했습니다 — "의사결정을 해 줄 수 있는 시스템을 만들 겁니다." 그리고 물었습니다. "이게 어떤 의미로 들리세요?"
00:01
문제는 "전문가가 없는 영역"
참가자가 회의 내용이 휘발되는 것, 프로세스가 체계화되어 있지 않은 것을 떠올렸지만 진행자는 "그건 아니고"라며 실제 문제를 제시했습니다.
"제조도 해야 하는데, 그럼 제조는 어떻게 설계해야 할지가 필요하잖아요. 건설이랑 다르잖아요. 그걸 어떻게 개발할 거예요? 전문가도 없는데."
②레퍼런스를 판단 근거로 00:02 – 00:07
00:02
서비스 화면 아카이브를 열다
진행자가 화면을 공유했습니다. 국내외 서비스의 화면과 기획이 방대하게 모여 있는 아카이브였습니다. 국내 서비스 레퍼런스가 거의 다 들어가 있고, 해외 쪽도 마찬가지라고 설명했습니다.
그리고 질문을 던졌습니다 — "이런 걸 다 가지고 있다는 게 어떤 의미인가?", "이걸 다 가지고 있으면 뭘 할 수 있을까요?"
00:04
"이미지만 가지고 있으면 참고밖에 안 된다"
답으로 "레퍼런스 참고?"가 나오자 진행자가 바로 선을 그었습니다.
"근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요."
이어서 무엇이 달라지는지를 설명했습니다. AI가 이미지를 하나하나 인식해서 이 사람이 왜 이 구조를 가지고 있고 레이아웃을 왜 이렇게 짰는지까지 데이터로 함께 들고 있으면, 서비스를 만들 때 마주치는 의사결정 사항들에 대해 전문성이 없어도 판단할 수 있다는 것입니다. 나아가 그 레퍼런스를 근거로 화면 구조까지 뽑아낼 수 있습니다.
00:05
가져오는 일 자체가 큰 작업이다
진행자는 수집이 간단하지 않다는 점을 강조했습니다.
토큰을 받아 API로 가져오는 방법이 있지만 막혀 있는 경우가 있습니다
막히면 페이지에 하나하나 접근해 브라우저에서 추출합니다
가져온 것을 정리하고, 함께 붙어 있는 설명 내용까지 확보합니다
그다음 이미지를 읽는 모델로 무엇이 어떻게 구성돼 있는지 다시 정리합니다
00:06
위키화 — "사진마다 다 꺼내 놓고 있어요"
정리한 결과를 노트 도구에 위키 구조로 쌓고 있다고 했습니다. 원래는 위키화를 하지 않고 자료만 모아 뒀는데 이번에 구조를 바꿨다는 설명이었습니다.
"사진만 들고 있으면 AI가 판단을 못 해요. 지금 가지고 있는 자료들은 그냥 카테고리만 찾는 거예요."
지금은 사진마다 어떤 UI·레이아웃을 가지고 있고 무엇을 강조했는지를 다 꺼내 놓는 중이라고 했습니다. 참가자가 "얘도 위키화해서 하고 있고"라며 3주차 내용과 연결했습니다.
③자기 제품부터 뜯어 보다 00:07 – 00:12
00:07
계정 정보만 주고 전부 파악하게 했다
외부 자료보다 먼저 한 것은 자기 회사 제품을 통째로 분석한 것이었습니다. 방법은 계정 정보만 주고 시스템이 어떻게 되어 있는지 전부 파악하게 한 것입니다.
데이터 구조가 어떻게 되어 있고
워크플로우가 어떻게 흐르고
동작이 어떻게 되어 있고
특정 항목을 선택하면 어떤 값이 들어가는지까지
화면도 전부 띄워서 왜 그렇게 구성돼 있는지
나아가 API 구조까지
그리고 핵심은 반복 가능하다는 것이었습니다 — "한 번 뜯어 놨으니까, 이 방식이 있으니까."
00:09
비교 대상을 넓히는 구상 — 그리고 법적 질문
같은 방식을 비교 대상이 되는 다른 서비스에도 적용하는 구상이 이어지자, 참가자가 물었습니다 — "이거 법적인 그런 건 없어요? 괜찮아요?"
진행자도 가볍게 넘길 문제는 아니라는 뉘앙스로 답했고, 그 자리에서 결론이 나지는 않았습니다. 공개된 자료를 어디까지 어떻게 쓸 수 있는지는 시작 전에 확인해야 할 사안입니다.
00:10
비슷한 서비스는 구조도 비슷하다
예시로 같은 분야의 앱 두 개 이야기가 나왔습니다. 아카이브에서 우연히 본 후발 서비스가, 평소 쓰던 서비스와 디자인은 다르지만 형태와 구성이 거의 같았다는 것입니다. 진행자의 정리는 "구성은 좀 다른데 결국에는"이었습니다.
00:11
디자이너도 모으지만, 없는 것이 있다
참가자가 "원래 이런 거 준비할 때 디자이너분들이 다 캡처해요"라고 하자, 진행자가 차이를 짚었습니다.
"그거는 사실 자료만 들어가 있는 거지, 그걸 해부해서 왜 이 레이아웃 구조로 해야 하는지, 의사결정에 들어가는 데이터는 들어가 있지 않잖아요."
④기술 부채 — 왜 이걸 하는가 00:12 – 00:18
00:12
"모래주머니 10킬로씩 달고 일하는 것"
이야기가 무거워졌습니다. 디자인 시스템을 1년에 걸쳐 갈아엎었지만 그 공백이 부채로 남았다는 것입니다.
"진짜 모래주머니 한 10킬로씩 달면서 지금 일하고 있는 거예요."
참가자가 정리했습니다 — "초기에 잘못된 의사결정이 이렇게까지 부채가 돼서 돌아오는구나. 그리고 그것 때문에 고객사에서도 불편해하고."
진행자의 대답은 더 직설적이었습니다 — "그런다고 엎지도 못해요, 지금. 차라리 프로젝트를 처음부터 다시 하면 훨씬 빨라." 새 화면을 만들어 놔도 기존 구조와 맞지 않아 반영을 못 한다고 했습니다.
00:13
가장 위험한 태도
원인을 짚는 대목에서 이 시간의 핵심 문장이 나왔습니다.
"이 시대에서 내가 잘하고 있는 분야, 잘 알고 있는 분야라고 해서 그게 정답이라고 생각하는 게 좀 위험한데."
이어서 기존 레퍼런스를 무시하는 태도를 지적했습니다 — "얘네는 왜 이렇게 만들었어? 디자인 너무 구리네" 하고 넘겼지만, 그들이 그렇게 한 것도 이유가 있었을 것이라는 이야기였습니다. 시스템의 성향이 다르면 맞는 답도 다릅니다.
00:14
"이뻐 보이네"로 끝난 검토
당시 결정이 그 분야의 전문성을 가진 상태에서 이루어진 것이 아니었다는 점도 언급됐습니다. 빨리 만들어야 한다는 압박도 있었습니다. 결과적으로 검토는 "보기에 괜찮네, 이뻐 보이네"에서 끝났습니다.
"UX가 없었던 거지. UX도 없고 UI도 사실."
00:15
그래서 만들려는 것
해법이 이어졌습니다. 잘 만들어진 서비스들과 공개된 디자인 시스템을 전부 가져와, 그쪽에서 어떤 의사결정을 했는지를 현재 상태와 비교하고, 그것을 근거로 디자인 시스템을 다시 만들어 한 번에 교체한다는 구상입니다.
기준은 하나였습니다 — 감으로 하지 않고, 정확하게 만들어진 것을 따라간다. 그렇게 하면 새로운 분야로 넓힐 때도 방향에 맞게 개발할 수 있다고 했습니다.
"우리 팀은 어떻게 보면 AI 잘 쓰고 AX를 잘 녹여내는 게 원툴이거든요. 근데 부족한 건 단단함이죠."
00:17
"그래서 매출로 어떻게 이어지는데?"
이 구상을 윗선에 설명했을 때 받은 질문이 공유됐습니다. 진행자의 답은 순서에 관한 것이었습니다 — 이게 되면 프로덕트가 빠르게 나올 수 있고, 그것을 영업과 마케팅으로 이어 매출을 만든다는 것입니다.
⑤조직 이야기 00:18 – 00:22
00:18
교안 제외 — 사내 경영·조직에 관한 대화
구상에 대한 조직 내 반응, 의사결정 구조, 개인에 대한 평가가 오간 구간입니다. 내용은 옮기지 않습니다.
다만 이 대화에서 나온 확산의 어려움에 관한 부분은 개인·조직을 특정하지 않는 선에서 AX는 왜 잘 퍼지지 않는가에 정리했습니다.
00:20
말이 아니라 결과로 설득한다
그 대화 중에 방법론에 해당하는 이야기가 나왔습니다.
"이런 결과물을 가져와서 이게 된다는 걸 보여 주고 얘기를 해야 말이 통해요. 말만 했을 때는 또 이상향이네라고 생각할 수 있거든요. 근데 결과를 가져왔어. 그럼 결과를 보고 판단하시겠죠."
그다음은 결정권자의 몫이라고 정리했습니다.
⑥시야의 세 단계 00:22 – 00:26
00:22
"누가 이걸 다 긁어낸다고 생각하겠어요"
주리 님이 이 작업의 성격을 짚었습니다.
"도구가 다 주어져 있어도 누가 이걸 몇십 시간 들여서 싹 다 긁어낸다고 생각을 하겠어요."
진행자의 대답은 짧았습니다 — "힘들었어요, 그냥." 이 작업 때문에 도구 사용량 한도에 걸렸고 필요한 구독을 추가로 결제했다는 이야기도 함께 나왔습니다. 그리고 그런 도구들이 회사 지원이 아니라 개인 구독이라는 점도 언급됐습니다.
00:23
새로 온 사람이 가장 열심히 쓴다
흥미로운 관찰이 공유됐습니다. 최근 합류한 사람이 업무 도구에 붙은 봇에게 하루에 스무 개 가까이 요청을 보내며 쓰고 있다는 것입니다. 경쟁 서비스 조사 같은 것도 직접 시킨다고 했습니다.
진행자의 해석은 이랬습니다 — 자기가 하던 스타일이 없고 프레시하니까 백지 그대로 그어 가는 것이라, 오히려 노베이스에서 시작한 쪽이 더 익숙해지기 쉽다는 것입니다.
00:25
"자기도 사고가 열리는 거거든요"
진행자가 이 시간의 목적을 밝혔습니다.
"한 단계 더 생각해 보면 될 수 있는 것들이, 이게 되는구나를 봤잖아요. 그럼 자기도 사고가 열리는 거거든요. 그런 시야가 보이는 게 중요해요."
그리고 "이해되시나요?"라고 물었습니다.
00:25
주리 님이 정리한 세 단계
참가자가 같은 레퍼런스를 놓고도 사람마다 도달하는 단계가 다르다는 것을 정리했습니다.
1단계 — 그걸 보고 레퍼런스로 쓴다
2단계 — 그것들을 조합해서 콜라주로 화면을 만들어 본다
3단계 — 싹 다 긁어서 이 구조를 만드는 것
그리고 덧붙였습니다 — "제가 볼 때는 3단계가 최종 단계인 거거든요."
00:26
한계를 한계라고 생각하지 않는 것
진행자는 이런 것이 회사 입장에서 큰 자산이 될 수 있다고 하면서, 다시 태도로 돌아왔습니다 — "이 한계를 한계가 있다고 생각하지 말고, 뭔가 좀 더 얘한테 얘기해 보고 하면 그런 게 나와요."
4주차 3교시는 2시간 15분짜리 실습이었습니다. 클라우드에 서버를 하나 만들고, 접속하고, 만들어 둔 페이지를 배포하고, 도메인을 사서 붙이고, HTTPS까지 붙이는 것을 각자 자기 손으로 끝냈습니다.
3주차 마지막에 "상황이 되면 서버를 올려 보자"고 예고했던 것이 여기서 실행됐습니다.
왜 이걸 하는가
개발을 시작한 사람이 가장 어려워하는 구간입니다. 그 어려운 걸 한 번 해 보고 "아, 되는구나"를 느끼는 것이 이 시간의 목적이었습니다.
이 시간의 성격
외우는 시간이 아니었습니다. 진행자도 "나도 지금 외워서 하라고 하면 못한다, 하나씩 보고 쳐야 한다"고 말했습니다.
대신 모르는 화면 앞에서 AI에게 어떻게 맡기는지를 보여 주는 시간이었습니다. 실제로 네트워크 설정·권한 설정·인증서 발급 대부분을 브라우저를 조작하는 AI에게 넘겼습니다.
①두 가지 배포 방식 — 무엇을 고를 것인가
본격적인 실습에 앞서 간단히 올리는 방법부터 비교했습니다. 만들어 둔 HTML을 링크로 만드는 데는 두 갈래가 있습니다.
방법 A
정적 호스팅 서비스에 올린다
깃 저장소를 연결하고 클릭 몇 번이면 링크가 생깁니다. 저장소를 공개로 두면 무료입니다. 커밋할 때마다 자동으로 다시 배포됩니다.
방법 B
클라우드에 서버를 빌린다
컴퓨터 한 대를 통째로 빌리는 것입니다. 뭐든 올릴 수 있지만 네트워크·보안·웹서버를 직접 설정해야 합니다. 이날 실습한 쪽입니다.
진행자가 정리한 선택 기준은 이랬습니다.
프론트엔드만 간단히 올릴 거면 정적 호스팅으로 충분합니다 — "몇 번 클릭으로"
서버까지 함께 배포해야 하면 정적 호스팅은 맞지 않습니다
검색 노출을 원한다면 자기 도메인이 필요합니다. 호스팅 업체의 기본 주소로는 거의 노출되지 않습니다
회의록처럼 보안이 필요한 문서를 공개 저장소에 올리기 시작하면 곤란해집니다 — "퍼블릭으로 올리는 건 보안을 좀 신경 써야 한다"
서버란 무엇인가 — 진행자의 설명은 단순했습니다. "맥미니 같은 컴퓨터 하나를 대여한다고 생각하면 됩니다." 성능에 따라 값이 다를 뿐입니다. 이 실습은 클라우드 무료 크레딧으로 진행했고, 가장 저렴한 사양이면 몇 달은 유지할 수 있다고 했습니다.
②서버 만들기 — 실제로 눌렀던 순서
참가자들이 화면을 함께 보며 따라간 순서입니다. 클라우드 콘솔에 처음 들어간 상태에서 시작합니다.
조직과 프로젝트를 만든다이름은 중요하지 않습니다. 콘솔에 처음 들어가면 아무것도 없는 상태이므로 담을 그릇부터 만듭니다.
컴퓨트 · 인스턴스 서비스를 활성화한다서비스 목록에서 컴퓨트 → 인스턴스를 고르고 활성화합니다. 잠깐 기다리면 완료됩니다.
OS 이미지로 우분투를 고른다목록을 내리면 Ubuntu LTS가 있습니다. 가장 기본으로 많이 쓰는 것이라 이걸 고릅니다. 외울 필요는 없다고 했습니다.
인스턴스 이름과 사양을 정한다이름은 자유입니다. 사양은 목록 위쪽의 작은 것으로 충분합니다 — 실습용이므로.
키페어를 만들고 반드시 내려받는다이 단계가 가장 중요합니다. 화면에도 "분실 시 인스턴스에 접속할 수 없다"고 적혀 있습니다. → 서버 보안과 키 관리
네트워크와 보안 그룹은 기본값으로 둔다여기서 막히면 뒤에서 AI에게 맡깁니다. 일단 만들고 넘어갑니다.
인스턴스를 생성한다초록색으로 바뀌면 서버가 살아 있는 것입니다.
"좋습니다. 다들 첫 번째 서버를 만드셨습니다."
3교시 · 인스턴스 생성 직후
여기까지가 절반도 안 됩니다 — 서버를 만들어도 아직 밖에서 들어갈 수 없습니다. 외부에서 접근할 IP가 없고, 들어올 문(포트)도 닫혀 있기 때문입니다. 개념은 서버와 도메인, 하나씩 뜯어보기에 정리했습니다.
③모르는 화면은 AI에게 맡긴다
네트워크 설정 화면에 들어가자 진행자도 잠시 멈췄습니다 — "좀 바뀌어서 저도 여기서 많이 바뀌어서 모르겠거든요." 그리고 참가자에게 물었습니다. "그럼 어떻게 하면 되겠어요?"
답은 브라우저를 직접 조작할 수 있는 확장 기능을 켜는 것이었습니다. 참가자들이 확장 프로그램을 설치한 뒤, 진행자가 예시 지시문을 그대로 불러 줬습니다.
내가 클라우드 콘솔에서 네트워크를 설정하려고 하는데
기존 설정이 있으니 네가 화면을 확인하고 설정해 줘.
이전에 설정했던 내용을 공유받은 게 있는데,
이 중에서 DB 같은 건 제외하고 HTTPS로 배포했을 때 바로 되게만 해 주면 돼.
(공유받은 설정 내용을 코드 블록으로 붙여넣기)
지시문을 넣는 방식에서 1교시에 배운 마크다운 기법이 그대로 쓰였습니다. 참가자가 "저쪽 화면은 왜 검은색으로 뜨고 제 건 이렇게 되냐"고 묻자 답이 나왔습니다 — 붙여 넣을 데이터는 백틱 세 개로 감싼다. → 마크다운은 프롬프트 기법이다
맡긴 것 1
네트워크와 포트 열기
외부에서 들어올 수 있도록 포트를 여는 설정. 화면 구조를 몰라도 AI가 찾아 들어가 처리했습니다.
맡긴 것 2
플로팅 IP 생성과 연결
외부용 IP를 만들어 서버에 붙이는 것까지. "생성해서 지금 만든 서버에 연결하고, 외부에서 접근되도록"이라고만 말했습니다.
맡긴 것 3
키 파일 권한 설정
"권한이 0644라 SSH 키를 거부하는 상태"라는 안내가 나오자, "권한 다 줄 테니 네가 설정해 줘"로 해결했습니다.
"나도 지금 외워서 하라고 하면 못해요. 하나씩 보고 쳐야 돼요. 근데 해 주죠."
3교시 · 설정을 맡기며
다만 검증은 사람 몫이다
참가자가 "이 시기가 제일 무섭잖아요, 나 이제 좀 아는 것 같은데"라고 하자 진행자가 기준을 줬습니다.
세 번은 물어본다 — "제대로 했냐, 검증했냐, 보안상 문제 없냐를 여러 번 물어보고 하면 괜찮아요. 근데 귀찮아서 넘어가서 그렇지." 진행자도 처음에는 "잘했어?"를 여러 번 물으며 세 번쯤 검증했고, 그 과정을 거치고 나니 지금은 믿고 맡긴다고 했습니다.
④터미널에서 서버에 들어가기
다음은 내 노트북에서 그 서버로 접속하는 단계입니다. 여기서도 화면을 캡처해 넘기는 방식을 썼습니다.
①
콘솔의 접속 정보 화면을 캡처한다
→
②
터미널을 열고 캡처와 함께 상황을 설명한다
→
③
키 파일 위치·권한·접속 확인까지 맡긴다
다운로드 폴더에 키 파일이 하나 있을 텐데
~/.ssh 로 옮기고 보안(권한) 설정도 함께 봐 줘.
내가 넣은 스크린샷의 정보로 접속되는지 확인해 볼 거야.
스크린샷에 있는 정보랑 키 파일을 같이 써서 검토해 줄래?
결과는 "완료했습니다. 접속까지 확인했습니다."였습니다. 진행자는 여기에 한 가지를 덧붙이게 했습니다 — 접속이 완료되면 화면을 캡처해 스터디 채널에 올려 달라는 것이었습니다. 각자 진행 상황을 확인하기 위해서였습니다.
키를 ~/.ssh에 두는 이유 — 관례입니다. "거기에 키를 놔두는 게 기본적인 규칙"이고, 키 파일에는 권한 설정도 함께 해 줘야 합니다. 권한이 너무 열려 있으면 접속 자체가 거부됩니다.
⑤실제로 배포하기
서버에 들어갈 수 있게 되자 만들어 둔 결과물을 올리는 단계로 넘어갔습니다. 참가자들은 각자 이 스터디에서 만든 교안 대시보드 HTML을 올렸습니다.
내 서버에 이 프로젝트의 HTML을 올려서 접근되게 하고 싶어.
앞으로 도메인을 붙여 외부에서 접근 가능하게 할 거니까
웹 서버 설정도 네가 알아서 다 설치하고 기본 세팅을 해 줘.
포트 번호나 방화벽 같은 것도 함께 처리해 줘.
이 한 번의 요청에 웹 서버 설치와 설정이 함께 들어갔습니다. 진행자의 설명으로는 그것만 해도 원래는 큰 일입니다.
"어떤 경로로 들어왔을 때 이리로 보내 주고 저리로 보내 주고 하는 걸 설정하는 게 있어요. 그 세팅만 해도 하루 종일 해도 못 하거든요."
3교시 · 웹 서버 설정에 대해
배포가 끝나자 서버 IP를 주소창에 넣는 것만으로 페이지가 열렸습니다. 참가자가 링크를 공유했고, 다 함께 들어가 확인했습니다.
포트를 나누면 여러 개를 올릴 수 있다
참가자가 "포트는 왜 필요한 거예요?"라고 묻자 답이 나왔습니다. IP 하나만으로는 프로젝트 하나밖에 못 올립니다. 포트를 나눠야 여러 개를 함께 올릴 수 있습니다.
진행자의 비유 — "신발 가게에 가면 나이키도 있고 아디다스도 있잖아요. 서버 하나에 그렇게 다 넣을 수 있어요."
⑥도메인을 사서 붙이다
실습의 후반부는 실제로 도메인을 구매하는 것이었습니다. 도메인 등록 서비스에 접속해 각자 원하는 이름을 검색했습니다.
고를 때 본 것
이날 확인된 내용
확장자
.com이 가장 일반적이고 보통 가격. .ai가 붙으면 가장 비쌉니다. .store·.site·.online 등은 훨씬 쌉니다
첫 해 가격의 함정
표시된 저렴한 값은 첫 해에만 적용됩니다. 갱신할 때는 정상가로 올라갑니다 — "나머지는 정상 가격을 받아"
이름
너무 일반적인 단어는 비쌉니다. 짧고 기억하기 쉬운 것이 좋고, 의미를 붙여 두는 편이 낫다고 했습니다
부가 옵션
도메인 보호 같은 추가 옵션은 넣지 않아도 됩니다
참가자들은 실제로 각자 도메인을 하나씩 구매했습니다. 한 사람은 자기 이름을 숫자로 바꾼 조합을, 다른 한 사람은 가족이 운영하는 가게 사이트에 쓸 이름을 골랐습니다. 이름을 정할 때도 AI에게 "짧고 기억하기 쉬운 걸로 추천해 달라"고 물었습니다.
DNS에 연결하기
구매한 도메인의 DNS 설정으로 들어가, A 레코드에 서버 IP를 넣으면 연결이 끝납니다. 이 단계도 브라우저를 조작하는 AI에게 넘겼습니다.
도메인을 구입했는데 브라우저에 DNS 설정 페이지를 열어 놨어.
서브 도메인 이름을 study 로 해서
지금 만들어진 포트에 올라가 있는 것과 연결하려고 해.
네가 브라우저에 접근해서 설정해 주고, 접근 가능한지까지 확인해서 알려 줘.
서브 도메인이 실제 이득 — 메인 도메인 하나만 사면 앞에 이름을 붙여 프로젝트마다 주소를 나눌 수 있습니다. 진행자의 말 — "메인 도메인 쓰는 건 쉬운데 서브 도메인까지 쓰는 걸 아는 것도 원래 어려워요." 그걸 몰라서 필요할 때마다 도메인을 새로 사는 경우가 많다고 했습니다.
⑦HTTPS와 검색 노출까지
도메인이 붙자 마지막 두 가지가 남았습니다.
마무리 1
HTTPS 인증서
무료 인증 기관에서 발급받아 서버에 설정합니다. 원래는 발급받고 파일을 붙이고 설정하는 데 시간이 꽤 걸리는 작업인데, 요청 한 번으로 처리됐습니다. 약 3개월마다 갱신이 필요합니다.
마무리 2
메타 태그와 검색 등록
페이지의 설명·키워드·썸네일을 넣으면 검색 결과와 링크 미리보기에 나옵니다. 여기에 검색엔진에 소유권을 인증하는 절차까지 하면 하루 이틀 뒤 검색됩니다.
"이야, 알아서 이제 잘하네. 원래 인증서 만드는 것도 일이에요. 만들어서 파일 나오면 붙이고 설정해야 되고, 그게 엄청 오래 걸리거든요."
3교시 · 인증서가 자동으로 발급된 것을 보고
마지막에 진행자가 물었습니다 — "이제 혼자 서버 올리고 배포할 수 있겠어요?" 참가자의 답이 이 시간의 결과였습니다.
"서버 올리고, 도메인도 사서 붙였고, 서브 도메인도 만들었고. 뭔가 좀 이해가 되는 것 같아요."
3교시 · 실습을 마치며
⑧이날 확인한 것
확인 1
가장 어려운 구간도 넘어간다
배포와 서버 설정은 개발자도 처음엔 막히는 구간입니다. 그걸 반나절 만에 끝까지 통과했습니다.
확인 2
모르면 화면을 넘긴다
콘솔 화면이 바뀌어 진행자도 헤맸지만, 화면을 보게 하고 맡기는 것으로 해결됐습니다.
확인 3
맡기되 세 번은 확인한다
"보안상 문제 없냐"를 포함해 여러 번 되묻는 습관이 붙어야 맡길 수 있습니다.
이날 나온 용어와 개념은 따로 정리했습니다 — 인스턴스·우분투·포트·SSH·웹 서버·DNS·인증서·무중단 배포까지. → 서버와 도메인, 하나씩 뜯어보기 · 키 관리와 보안은 서버 보안과 키 관리에 있습니다.
3교시 실습 내내 보안 이야기가 계속 끼어들었습니다. 키를 만드는 순간, 포트를 여는 순간, 배포하는 순간마다 한 번씩 짚고 넘어갔습니다.
서버를 가진다는 것은 밖에서 들어올 수 있는 문을 갖는다는 뜻이기 때문입니다.
한 줄 요약
서버는 대개 정교한 공격으로 뚫리지 않습니다.열어 둔 문과 흘린 열쇠로 뚫립니다.
①키 하나가 전부다
인스턴스를 만드는 도중 키페어 생성 단계에서 진행자가 실습을 멈추고 강조했습니다.
"이게 중요합니다. 이 키가 이 서버 들어오는 열쇠예요."
3교시 · 키페어를 만들며
화면에도 경고가 적혀 있었습니다 — "분실 시 인스턴스에 접속할 수 없습니다." 진행자가 그 뒤를 이었습니다.
"이거 누구한테 털렸다? 저기 서버에 있는 키 털렸다? 다 털리는 거예요. 그래서 이 키는 절대 털리면 안 돼요."
3교시 · 키 관리에 대해
잃어버리면
내가 못 들어간다
키가 없으면 서버 주인도 접속할 수 없습니다. 다시 만들 수 없는 열쇠라고 생각해야 합니다.
유출되면
남이 들어온다
그 서버에 있는 것이 전부 열립니다. 반대로 말하면 — 키만 지키면 어지간해서는 뚫리지 않습니다.
실제로 이날 확인된 것 — 뒷부분에서 해킹 이야기가 나왔을 때 진행자가 말했습니다. "우리 서버도 지금 있는 거 털려고 하면 키가 없으면 못 털거든요." 키 관리가 서버 보안의 대부분이라는 뜻입니다.
키를 두는 자리와 권한
키는 ~/.ssh 폴더에 두는 것이 기본 규칙입니다
파일 권한 설정이 함께 필요합니다 — 너무 열려 있으면 접속 자체가 거부됩니다
이날도 "권한이 0644라 SSH 키를 거부하는 상태입니다"라는 안내가 실제로 떴습니다
거부당하는 것이 불편해 보이지만, 권한이 열린 키를 그냥 쓰게 두지 않는다는 뜻이라 오히려 안전장치입니다.
②문을 여는 일에는 경고가 따라온다
네트워크 설정을 AI에게 맡겼을 때, 작업 도중 경고가 올라왔습니다.
"포트가 인터넷에 그대로 노출됩니다."
3교시 · 네트워크 설정 중 나온 안내
이날은 실습용 서버였고 올릴 것도 공개용 문서였기 때문에 그대로 진행했습니다. 다만 이 장면은 그대로 기록해 둘 만합니다 — 도구는 위험을 알려 주고, 넘길지 말지는 사람이 정한다는 구조가 여기서 그대로 드러났기 때문입니다.
실제 업무 서버라면 달라집니다 — 포트는 필요한 것만 열고, 열었으면 무엇이 열려 있는지 알고 있어야 합니다. 데이터베이스 포트처럼 바깥에 열릴 이유가 없는 문을 습관적으로 여는 것이 사고의 시작입니다. 실제로 이날 지시문에도 "DB 같은 건 제외하고"라는 조건이 들어가 있었습니다.
③공개 저장소에 무엇을 올리는가
실습 초반, 간단히 배포하는 방법을 이야기하다가 나온 주의입니다. 공개 저장소를 쓰면 무료로 배포할 수 있지만 그 대가가 있습니다.
"회의록 이런 건 보안 문서일 수 있잖아요. 그런 것들을 저장소에 올리기 시작하면… 생각보다 이 퍼블릭에 올리는 게 보안을 좀 신경 써야 돼요."
3교시 · 공개 저장소에 대해
공개해도 되는 것
밖에 보여 줄 결과물 페이지, 공개 문서, 개인 포트폴리오
↔
올리면 안 되는 것
회의록·내부 문서, 계정 정보, 키와 토큰
④실제로 뚫리는 방식은 단순하다
실습 후반, 참가자가 "해커들은 그럼 어떻게 해킹을 하는 거예요?"라고 물으면서 이야기가 이어졌습니다. 나온 사례는 둘 다 정교한 공격이 아니었습니다.
공용 와이파이에서 오가는 것을 가로챈다
카페 같은 곳의 공용 접속은 보안이 없습니다
그 망을 쓰는 사람들의 오가는 데이터를 잡아낼 수 있습니다
암호화돼 있어도 방식을 조합해 풀어낼 수 있습니다
그래서 나온 결론 — "보안이 중요한 것들은 거기서 하지 말라고 하는 거예요." 공용 망에서는 중요한 작업을 하지 않는다는 단순한 원칙입니다.
열어 둔 원격 접속 도구로 들어온다
참가자가 공공 전광판이 뚫렸던 사건을 예로 들자, 진행자가 그 구조를 설명했습니다.
"이게 털려고 털린 게 아니라 원격 도구를 켜 놨다가 꺼지면, 여기 들어갈 수 있는 수단이 열려 있어요. 이런 걸 통해 들어간 걸로 알고 있어요."
3교시 · 원격 접속 도구에 대해
진행자는 자기 주변의 예도 들었습니다 — 현장에 설치된 기기들에 원격 접속 도구가 깔려 있는 경우가 많은데, 무언가 잘못 종료되면 그 화면이 그대로 열린 채로 남습니다.
"그래서 보안이 잘못하면 되게 허술하게 뚫릴 수도 있고 그런 거죠. 근데 그걸 서버에 직접 접근해서 뚫었다고 하면, 그건 아예 그쪽 보안 책임자가 관리를 못하고 있는 거고."
3교시 · 뚫리는 방식의 구분
⑤키 유출 사고는 실제로 일어난다
이날 이야기 중에 실제로 겪은 사고가 언급됐습니다. 회사나 서비스는 특정하지 않고 구조만 옮깁니다.
1차
한 서비스의 API 키가 유출돼 사용량이 도용됐습니다
→
차단
해당 키를 막았습니다
→
2차
다음 날 새벽 다른 서비스의 키로 같은 일이 반복됐습니다
진행자가 이상하게 본 지점이 있었습니다 — 두 서비스를 함께 쓴다는 사실을 아는 사람이 많지 않다는 것, 그리고 키가 하나만 유출된 게 아니라는 것이었습니다. 원인은 그 자리에서 결론 나지 않았습니다.
사고 조사도 맡겼다 — 어떤 키가 얼마나 쓰였고 어떻게 새어 나갔는지를 확인하는 일 자체를 AI에게 넘겼다고 했습니다. "제가 그걸 어떻게 다 확인할 거예요." 로그를 뒤지는 일은 사람이 다 훑기 어렵습니다.
⑥맡기되, 세 번은 확인한다
이 시간의 실습은 대부분을 AI에게 맡기는 방식이었습니다. 그래서 어디까지 믿을 것인가가 자연스럽게 화제가 됐습니다. 참가자가 걱정을 먼저 꺼냈습니다.
"근데 그 시기가 제일 무섭잖아요. 나 이제 좀 아는 것 같은데."
3교시 · 참가자
다른 참가자가 "책 한 권을 읽었을 때의 그 자신감"이라고 받았습니다. 진행자의 답은 습관에 관한 것이었습니다.
"여러 번 제대로 했냐, 검증했냐, 보안상 문제 없냐 이런 걸 여러 번 물어보고 하면은 괜찮아요. 근데 귀찮아서 넘어가서 그렇지."
3교시 · 검증에 대해
진행자 본인도 처음에는 "잘했어?"를 반복해 물으며 세 번쯤 검증했다고 했습니다. 그 과정을 거치고 나서야 "어느 정도 해 주는구나"를 알게 됐고, 지금은 그 판단 위에서 맡긴다는 것입니다. 믿는 것과 확인하지 않는 것은 다릅니다.
⑦서버를 하나 가졌다면 — 체크리스트
이날 나온 이야기를 실습 이후에 확인할 형태로 모으면 이렇습니다.
키 파일을 안전한 곳에 두었는가 — ~/.ssh에 두고, 권한을 좁게 설정했는지
키를 저장소나 채팅에 올리지 않았는가 — 한 번 올라가면 기록이 남습니다
열어 둔 포트가 무엇인지 알고 있는가 — 필요한 것만 열고, 데이터베이스 포트는 함부로 열지 않습니다
공개 저장소에 내부 문서가 섞이지 않았는가 — 회의록·계정 정보·토큰
중요한 작업을 공용 와이파이에서 하지 않는가
원격 접속 도구를 켜 둔 채 방치하지 않았는가
설정을 맡겼다면 "보안상 문제 없냐"까지 되물었는가
3주차의 안전 원칙과도 이어집니다 — 밖으로 나가는 것은 자동으로 보내지 않는다, 사람 확인은 이름이 아니라 계정 ID로. → 봇 운영과 보안
3주차 마지막에 예고했던 "서버 올려 보기"를 실제로 한 시간. 인스턴스 생성부터 도메인·HTTPS까지 각자 끝까지 갔습니다.
기록 원칙
전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 회사명·서비스명·개인 이름은 일반 표현으로 바꿔 옮겼고, 참가자가 실제로 구매한 도메인 이름은 개인 정보가 섞여 있어 표기하지 않습니다.
실습 도구(클라우드 콘솔·도메인 등록 서비스·브라우저 확장 등)는 일반 명칭으로 적었습니다.
①배포 방식 비교 00:00 – 00:10
00:00
도메인과 IP의 관계부터
교시는 도메인이 무엇인지에서 시작했습니다. 도메인을 구입해 IP와 연동해 두면, 그 도메인을 타고 IP로 접근할 수 있게 됩니다.
참가자가 자기 말로 바꿔 확인했습니다 — "주소 뒤에는 사실 복잡한 숫자가 들어가 있는데, 하이퍼링크처럼 그냥 눌러서 들어가는 것과 비슷한 거네요."
00:01
간단히 올리는 길 — 정적 호스팅
만들어 둔 HTML이나 프로젝트를 깃 저장소와 연결하고 클릭 몇 번이면 링크가 생기는 서비스를 보여 줬습니다. 저장소를 공개로 두면 무료입니다.
주소 앞부분은 내가 정할 수 있습니다 — 같은 이름이 없으면
커밋할 때마다 자동으로 다시 배포됩니다
다만 검색 노출을 원하면 자체 도메인이 필요합니다. 호스팅 업체의 기본 주소로는 거의 노출되지 않습니다
서버까지 함께 배포하려면 맞지 않습니다 — "프론트엔드만 해 놓으려면 간단히 올릴 수 있다"
보안 이야기도 함께 나왔습니다 — 회의록 같은 문서를 공개 저장소에 올리기 시작하면 곤란해집니다.
"생각보다 이 퍼블릭에 올리는 게 보안을 좀 신경 써야 돼요."
00:03
왜 굳이 서버를 올리는가
진행자가 이날의 목적을 밝혔습니다. 개발을 시작한 사람이 가장 어려워하는 구간이 이 부분이라는 것입니다.
"제일 어려운 걸 한번 해 보는 거지. 그게 되는 걸 한번 경험해 보면, 아 그냥 되네 하는 수준을 느껴 보면."
무료 크레딧으로 몇 달은 유지할 수 있다는 계산도 덧붙였습니다. 그 안에 각자 배포하고 싶은 것을 올려 보면 된다는 것이었습니다.
00:06
발표 자료를 웹으로 만든 예시
진행자가 예전에 만든 것을 하나 보여 줬습니다. 세션에서 찍은 슬라이드 사진에 AI로 만든 음성 설명을 붙여, 넘길 때마다 해당 설명이 나오도록 한 페이지였습니다.
"두 개를 합치면 영상이랑 똑같잖아요. 그런 경험을 주는"이라는 설명이었습니다. 이 페이지도 서버 없이 정적 호스팅에만 올린 것이라고 밝혔습니다.
00:09
정리 — 서버란 컴퓨터 한 대를 빌리는 것
참가자가 "정적 호스팅은 프론트엔드 프로덕트를 할 때 쓰는 것"이라고 답하자, 진행자가 더 단순하게 정리했습니다 — "그냥 배포 쉽게 하는 거".
그리고 서버로 넘어갔습니다.
"이 서버를 하나 대여한다, 맥미니 같은 거 하나 대여한다 생각하면 돼요. 성능이 따라 다른 거니까."
②서버 만들기 00:10 – 00:19
00:10
조직과 프로젝트부터
"저 따라 하시면 됩니다"로 실습이 시작됐습니다. 클라우드 콘솔에 처음 들어가면 아무것도 없으므로, 조직을 하나 만들고 프로젝트를 만듭니다. 이름은 중요하지 않다고 했습니다.
그다음 서비스 목록에서 컴퓨트 → 인스턴스를 고르고 활성화합니다.
00:12
OS 이미지 — 우분투를 고르는 이유
인스턴스 생성 화면에서 OS 목록을 내려 우분투 LTS 중 가장 위의 것을 골랐습니다. 왜 이걸 고르는지 설명이 붙었습니다.
서버용 운영체제는 여러 종류가 있고, 우분투를 가장 기본으로 많이 씁니다
맥OS도 뿌리가 같은 계열이라 터미널 환경이 낯설지 않습니다
"모든 서버는 터미널에서 시작을 해요" — 지금의 그래픽 화면은 나중에 얹힌 것입니다
진행자는 "기억은 안 해도 돼요. 이게 가장 기본으로 많이 쓴다"고 정리했습니다.
00:14
"인스턴스가 뭔데요?"
이름과 사양을 고르던 중 참가자가 물었습니다. 답이 이랬습니다.
"어떤 템플릿을 하나 만들어 놨잖아요. 실제로 사용하는 걸 만드는 걸 인스턴스라고 해요."
다른 참가자가 디자인 도구의 컴포넌트와 그 복제본에 빗대자 진행자가 맞다고 확인했습니다 — "개발도 그렇고 모든 곳에 사용되는 용어예요."
00:16
키페어 — 이 서버의 열쇠
실습이 잠시 멈춘 지점입니다. 진행자가 강조했습니다.
"이게 중요합니다. 이 키가 이 서버 들어오는 열쇠예요."
화면에 적힌 경고도 함께 읽었습니다 — "분실 시 인스턴스에 접속할 수 없습니다." 그리고 반대 경우까지 짚었습니다.
"이거 누구한테 털렸다? 다 털리는 거예요. 그래서 이 키는 절대 털리면 안 돼요."
내려받은 파일은 다운로드 폴더에 저장됩니다. "무조건 다운로드 해야 돼요."
00:18
첫 서버가 생기다
네트워크와 보안 그룹은 기본값으로 두고 인스턴스를 생성했습니다. 상태가 초록색으로 바뀌자 진행자가 말했습니다.
"좋습니다. 다들 첫 번째 서버를 만드셨습니다."
③모르는 화면을 AI에게 넘기다 00:19 – 00:40
00:20
진행자도 막히다
네트워크 설정으로 들어가자 콘솔 화면 구성이 예전과 달라져 있었습니다. 진행자가 솔직히 말했습니다 — "좀 바뀌어서 저도 여기서 많이 바뀌어서 모르겠거든요."
이 대목에서 참가자들이 클라우드 서비스가 무엇인지, EC2가 무엇인지를 물었고, 답이 이어졌습니다 — 클라우드는 컴퓨팅 환경을 빌려주는 것이고, 서버 한 대를 올리는 상품을 업체마다 다르게 부른다는 설명이었습니다.
참가자가 정리한 메모가 그대로 읽혔습니다 — "클라우드 컴퓨터를 빌려 쓰는 방식 · 그 방식으로 장사하는 회사 · 컴퓨터 한 대 빌려주기 상품."
00:24
VPC와 CIDR에서 멈추다
네트워크를 만들려 하자 VPC·CIDR 같은 낯선 항목이 나왔습니다. 참가자가 "VPC가 뭔데요?"라고 묻자 가상 사설 클라우드의 약자이고 보안 설정을 하는 곳이라는 답이 나왔습니다.
진행자도 "저도 여기서 많이 바뀌어서 모르겠다"며 방법을 바꿨습니다.
"이제 여기 들어왔으면 뭔 말인지 모르겠죠. 생성하는 게 있어도 뭔 말인지 모르겠죠. 그럼 어떻게 하면 되겠어요?"
00:26
브라우저 확장을 켜다
참가자가 "물어볼까?"라고 답하자, 진행자가 브라우저를 직접 조작할 수 있는 확장 기능을 설치하게 했습니다. 스크린샷을 여러 장 찍어 넘기는 방식보다 화면을 직접 보게 하는 편이 낫다는 이유였습니다.
그리고 지시문을 직접 쳐서 보여 줬습니다.
내가 클라우드 콘솔에서 네트워크를 설정하려고 하는데
기존 설정이 있으니 네가 화면을 확인하고 설정해 줘.
이전에 설정했던 내용을 공유받은 게 있는데,
이 중에서 DB 같은 건 제외하고 HTTPS로 배포했을 때 바로 되게만 해 주면 돼.
참가자가 "저쪽 화면은 왜 검은색으로 뜨고 제 건 이렇게 되냐"고 묻자 답이 나왔습니다 — 붙여 넣을 데이터는 백틱 세 개로 감싼다. 1교시의 마크다운 기법이 그대로 쓰인 장면입니다.
00:29
플로팅 IP를 설명하다
참가자가 "플로팅이 뭐야?"라고 묻자 진행자가 직접 설명했습니다.
"이건 내부 IP 주소고, 외부에서 접근하는 주소를 하나 연결해서 만들어 줘야 돼요. 192.168… 많이 보지 않았어요? 그건 내부용이에요."
이어서 포트 이야기로 넘어갔습니다. 참가자가 "포트 번호가 뭐예요?"라고 묻자 이 시간에서 가장 잘 통한 비유가 나왔습니다.
"집에 들어갔어요. 그런데 방이 많아. 들어가려면 문이 잠겨 있어. 여기는 80이고 여기는 443이고… 이걸 풀어 줘야만 외부에서 들어갈 수가 있어요."
데이터베이스에도 기본 포트가 있고, 외부에서 접근하려면 그 문도 열어 줘야 한다고 덧붙였습니다.
00:34
"이런 것들은 우리가 못하겠지"
AI가 네트워크 설정을 처리하는 것을 보며 참가자들이 놀랐습니다. 진행자도 같은 말을 했습니다.
"나도 지금 외워서 하라고 하면 못해요. 하나씩 보고 쳐야 돼요. 근데 해 주죠."
이어서 플로팅 IP 생성과 연결까지 같은 방식으로 맡겼습니다 — "생성해서 지금 만들어진 컴퓨터에 연결하고, 외부에서 접근 가능하도록. 최종으로 설정 다 되어 있는지 확인해 줘."
00:38
어디까지 믿을 것인가
작업 도중 "포트가 인터넷에 그대로 노출됩니다"라는 경고가 올라왔습니다. 실습용 서버였기 때문에 "괜찮아"로 넘기고 진행했습니다.
참가자가 "제대로 해 줬을까" 하는 불안을 말하자 진행자가 기준을 줬습니다.
"처음에는 '잘했어?' 물어보기도 하고 검증을 몇 번 하고, 세 번 정도 해 보면 그게 다 됐다는 걸 알 거예요."
④터미널로 서버에 접속하기 00:50 – 00:55
00:50
접속 정보를 캡처해서 넘기다
콘솔의 접속 정보 화면을 캡처하고, 터미널을 열어 그 이미지와 함께 상황을 설명하는 방식이었습니다. 진행자가 지시문을 불러 줬습니다.
다운로드 폴더에 키 파일이 하나 있을 텐데
~/.ssh 로 옮기고 보안(권한) 설정도 함께 봐 줘.
내가 넣은 스크린샷의 정보로 접속되는지 확인해 볼 거야.
스크린샷에 있는 정보랑 키 파일을 같이 써서 검토해 줄래?
00:52
"SSH가 뭔지 아예 모르겠어"
참가자의 말에 설명이 이어졌습니다.
터미널로 서버에 접속하는 방식을 SSH라고 합니다
키는 ~/.ssh 폴더에 두는 것이 기본 규칙입니다
키 파일에는 권한 설정이 함께 필요합니다
실제로 "권한이 0644라 SSH 키를 거부하는 상태입니다"라는 안내가 떴고, "권한 다 줄 테니 네가 설정해 줘" 한마디로 해결됐습니다.
곧 결과가 나왔습니다 — "완료했습니다. 접속까지 확인했습니다."
00:54
진행 상황을 서로 공유하게 하다
진행자가 참가자에게 한 가지를 더 시켰습니다 — 접속이 완료되면 화면을 캡처해 스터디 채널에 올려 달라는 것이었습니다. "제가 그거까지 알기가 힘드니까"가 이유였습니다.
⑤실제로 배포하기 00:54 – 01:10
00:54
스터디에서 만든 교안을 올리다
진행자가 참가자에게 물었습니다 — "이 스터디 녹음으로 만드는 거, 주차마다 HTML 만들어지는 거. 그거 파일이 어디 저장돼 있어요?" 그리고 그것을 올리기로 했습니다.
내 서버에 이 프로젝트의 HTML을 올려서
내 노트북에서 접근되는지 확인하고 싶어.
앞으로 도메인으로 외부에서 접근 가능하도록 할 거니까
웹 서버 설정도 네가 알아서 다 설치하고 기본 세팅을 해 줘.
포트 번호나 방화벽 같은 것도 다 처리해 줘.
진행자가 덧붙였습니다 — "그냥 뭔 말인지 몰라도 상관없어요."
00:58
웹 서버가 하는 일
요청 안에 들어간 웹 서버가 무엇인지 설명이 붙었습니다. IP 하나에 프로젝트 하나만 매칭되는 것을 넘어, 어느 경로로 들어왔는지 보고 알맞은 곳으로 보내 주는 역할입니다.
"그 세팅하는 것만 해도 하루 종일 해도 못 하거든요."
진행자는 자신이 운영 중인 서버를 열어 여러 서비스가 도메인별로 붙어 있는 상태를 보여 줬습니다. 비유는 신발 가게였습니다 — "가게 하나에 나이키도 있고 아디다스도 있잖아요. 서버 하나에 그렇게 다 넣을 수 있어요."
01:05
"그럼 깃허브는 뭐 하는 건데요?"
참가자의 질문에 구분이 정리됐습니다.
"깃허브는 그냥 구글 드라이브처럼 코드를 저장하는 거예요. 계속 저장을 해 놔야 백업이 되고 하니까."
봇이 "커밋할까요?"라고 묻는 이유도 여기서 설명됐습니다 — 저장소를 만들지 않아도 내 컴퓨터 안에서만 버전 관리를 시작할 수 있고, 나중에 올릴 수 있도록 자기만의 지점을 찍어 두는 것이라는 답이었습니다. 진행자가 터미널에서 폴더를 만들고 초기화하는 것까지 직접 보여 줬습니다.
01:08
IP만으로 사이트가 열리다
배포가 끝나자 서버 IP를 주소창에 넣는 것만으로 페이지가 열렸습니다. 참가자가 링크를 공유했고 다 함께 확인했습니다.
참가자가 "포트는 왜 필요한 거예요?"라고 묻자 답이 나왔습니다 — IP 하나로는 프로젝트 하나밖에 못 올리고, 포트를 나눠야 여러 개를 함께 올릴 수 있다는 것이었습니다.
"별거 아닌 것 같은데 되죠. 근데 이게 직접 설정하려면 진짜 어렵거든요."
⑥도메인을 사다 01:11 – 01:30
01:11
도메인 등록 서비스에 들어가다
각자 도메인 등록 서비스에 접속해 원하는 이름을 검색했습니다. 가격이 왜 다른지가 바로 화제가 됐습니다.
.com이 가장 일반적이라 보통 가격, .ai가 붙으면 가장 비쌉니다
.store·.site·.online 같은 것은 훨씬 쌉니다
표시된 저렴한 값은 첫 해에만 적용되고, 갱신은 정상가입니다
부가 옵션(도메인 보호 등)은 넣지 않아도 됩니다
이름 짓기도 AI에게 물었습니다 — "너무 일반적인 건 비싸니까, 짧고 사람이 기억하기 쉬운 걸로 추천해 달라"는 식이었습니다.
01:24
각자 하나씩 구매하다
참가자들이 실제로 도메인을 하나씩 구매했습니다. 한 사람은 자기 이름을 숫자로 바꾼 조합을, 다른 한 사람은 가족이 운영하는 가게 사이트에 쓸 이름을 골랐습니다.
진행자의 말 — "이거 언제 사 보겠어요, 본인이." 그리고 "저런 도메인들도 하나씩 사 보면서 자기 포트폴리오도 올릴 수 있고"라고 덧붙였습니다.
01:29
DNS에 서버 IP를 넣다
구매한 도메인의 DNS 설정 화면으로 들어가, A 레코드에 서버 IP를 넣어 연결했습니다. 이 단계도 브라우저를 조작하는 AI에게 넘겼습니다.
도메인을 구입했는데 브라우저에 DNS 설정 페이지를 열어 놨어.
서브 도메인 이름을 study 로 해서
지금 만들어진 포트에 올라가 있는 것과 연결하려고 해.
네가 브라우저에 접근해서 설정해 주고, 접근 가능한지까지 확인해서 알려 줘.
포트와 서브 도메인의 매칭이 안 맞아 몇 번 다시 시도하는 장면도 있었습니다.
⑦서브 도메인과 도메인의 세계 01:38 – 01:48
01:38
메인 하나로 여러 개를 만든다
진행자가 자신이 운영 중인 도메인의 DNS 화면을 열어, 여러 서브 도메인이 하나의 서버로 들어가는 구조를 보여 줬습니다.
"메인 도메인 쓰는 건 쉬운데 서브 도메인까지 쓰는 걸 아는 것도 원래 어려워요. 그래서 필요할 때마다 도메인을 새로 구입하는 분들도 있잖아요."
참가자가 자기 상황으로 바꿔 이해했습니다 — 회사 아래 여러 사업부가 있을 때, 메인 도메인 하나에 앞에 이름만 붙이면 된다는 것이었습니다. 그리고 "이렇게 해야 돈이 안 아깝네"라고 정리했습니다.
01:42
도메인은 누가 관리하나
참가자가 "도메인은 최종적으로 누가 만들어 주는 거예요?"라고 묻자, 그 자리에서 찾아본 내용이 공유됐습니다.
웹의 기반은 월드 와이드 웹을 만든 사람이 저작권을 걸지 않고 공개해 둔 데서 시작했습니다
판매 업체들은 중앙 관리 기관에서 받아와 등록을 대행합니다
최종 관리 기관은 ICANN — 미국 캘리포니아의 비영리 국제기구입니다
도메인은 갱신하면 계속 보유하고, 이름이 유명해지면 값이 오르고 사겠다는 연락이 오기도 한다는 이야기가 이어졌습니다.
01:45
"퍼블리셔들은 이런 걸 다 아는 거였네요?"
참가자의 질문에 진행자가 "모르죠"라고 답하며 직군을 구분했습니다.
"이 서버를 관리하는 직군을 데브옵스라고 불러요. 서버 올려놓고 네트워크 관리해 주고 트래픽 관리해 주는 사람들이 데브옵스거든요."
규모가 큰 회사에는 데브옵스 조직이 따로 있어 IP를 요청하면 발급해 주는 식으로 운영된다고 했습니다.
01:46
무중단 배포
저장소에 코드를 올리면 자동으로 배포까지 되게 만드는 방식이 소개됐습니다. 그때 배포용 임시 컴퓨터가 생겼다가 사라지는데 거기서도 우분투가 쓰인다는 설명이었습니다.
주요 브랜치에 반영되면 바로 배포되게 운영하는 방식이 있고, 배포 시점을 정해 두고 그때만 올리는 방식도 있다고 구분했습니다.
⑧HTTPS와 검색 노출 01:49 – 01:58
01:49
메타 태그를 함께 넣게 하다
다른 참가자는 가족 가게 사이트로 만들어 둔 HTML을 올렸습니다. 배포 요청에 한 문장을 덧붙이게 했습니다 — "메타 태그라든지 검색했을 때 잘 나오는 팁들 다 적용해서 끝까지 완료하고 테스트해 봐 줘."
"메타 태그는 뭐예요?"라는 질문에 답이 이어졌습니다. 페이지 머리에 들어가는 설명·키워드·대표 이미지가 검색 결과와 링크 미리보기 썸네일을 만든다는 것이었습니다.
01:54
HTTPS가 빠져 있었다
배포된 주소가 HTTP로 열리는 것을 확인하고, 다시 요청했습니다 — "HTTPS로 설정해서 접근 가능하도록 다 배포해 주면 돼요."
인증서가 발급된 것을 확인하고 진행자가 감탄했습니다.
"이야, 알아서 이제 잘하네. 원래 인증서 만드는 것도 일이에요. 파일 나오면 붙이고 설정해야 되고, 그게 엄청 오래 걸리거든요."
무료 인증 기관에서 발급받는 것이고 약 3개월마다 만료되므로, 그때는 재발급을 요청하면 된다고 덧붙였습니다.
01:56
검색엔진에 등록하기
마지막으로 구글에서 검색되도록 설정하는 단계가 남았다고 안내했습니다. 그것까지 하면 하루쯤 뒤에 검색된다고 했습니다. (이 부분은 4교시 첫머리에서 한 번 더 설명됩니다.)
참가자의 반응 — "쉽지 않지만 된다."
01:58
"혼자 서버 올리고 배포할 수 있겠어요?"
진행자가 물었고, 참가자가 답했습니다.
"서버 올리고, 도메인도 사서 붙였고, 서브 도메인도 만들었고. 뭔가 좀 이해가 되는 것 같아요."
진행자가 정리했습니다 — "이제 개발이 좀 이해되죠. 이게 어떻게 붙어 있는지, 그 그림이 보이잖아요."
⑨태도 이야기가 다시 나오다 01:58 – 02:00
01:58
도메인을 사 놓고도 안 붙인 경우
실습 도중 반복해서 언급된 사례가 있습니다. 도메인을 이미 보유하고 있는데도 고객에게 IP 숫자를 그대로 전달하고 있던 상황이었습니다.
참가자도 "그거 되게 짜쳐 보이거든요"라고 했고, 진행자는 원인을 비용이 아니라 관심으로 봤습니다.
4교시는 16분이었습니다. 3교시에서 남은 검색 등록 이야기를 마저 정리하고, 한 달간의 소감을 나누는 것으로 스터디가 끝났습니다.
진행자의 말로 시작합니다 — "그러면 좀 마무리를 해 보겠습니다. 한 달 동안 다들 고생하셨는데, 좀 어떠셨는지 짤막한 소감을 얘기해 보는 시간을 가져 봅시다."
마지막 한 문장
참가자들이 공통으로 꼽은 것은 도구가 아니었습니다 — "AI를 하나 배웠다가 아니라, 생각하는 방식이 바뀌었다."
①참가자들의 소감
동현 님
매주 이야기했듯 쉽지는 않았다고 먼저 말했습니다. 그리고 무엇이 남았는지를 이렇게 정리했습니다.
"꼭 AI뿐만 아니라 그냥 전체적으로 이런 업무 스타일이라든가, 좀 미래에 대한 저의 방향성이라든가, 여러 방면에서 인사이트를 느꼈던 것 같아요. 그냥 AI를 하나 배웠다 이게 아니라, 전체적인 하나의 터닝포인트가 또 되지 않았나."
이어진 문장이 이 스터디의 목적과 맞닿습니다 — "기존에 어떻게 해야 될지 막막했었는데 조금 방향이 보였다."
과제에 대한 평도 있었습니다. "숙제들이나 그런 떡밥들이 되게 재밌었던 것 같아요. 아, 이렇게 해 보니까 이래서 하라고 했구나." → 그 떡밥이 회수되는 지점
주리 님
이미 팀에서 AI를 다뤄 온 입장에서, "이건 이미 다 배운 내용 아니냐"는 질문을 주변에서 받기도 했다고 합니다. 그에 대한 답이 이랬습니다.
"그냥 AI 스터디만 한 게 아니라, 그 이전에 어떻게 생각하고 AI를 해야 하는가가 솔직히 더 주된 내용이었잖아요. 그래서 그런 것들이 업무를 할 때도 그렇고, 앞으로의 마인드 같은 것도 많이 배우는 세션이었어요."
본인의 정리는 한 문장이었습니다 — "배운 걸 또 배운다기보다는 약간 마인드셋 점검. 앞으로 어떻게 해야 하나."
②진행자의 챌린지 — "준비하지 않는 것"
진행자가 이 스터디를 시작하며 스스로에게 건 과제를 밝혔습니다. 참가자들이 맞혀 보라고 하자 나온 답이 의외였습니다.
"딱 한 가지 잡은 게 있어요 — 준비하지 않는 거."
4교시 · 진행자의 챌린지
원래 방식은 정반대였다고 합니다.
원래 하던 방식
일주일 전부터 다 짜 놓는다
커리큘럼을 미리 만들고, 교육 한 번에 리허설을 세 번 할 정도로 준비했습니다.
이번 방식
그날 아침에 준비한다
"절대 전날까지 준비하지 않는다. 무조건 일어나서 그날부터 준비한다." 교안도 마찬가지였습니다.
이유는 대상이 매번 다르기 때문이었습니다.
"결국에는 필요하신 분들이 필요한 게 다 다르잖아요. 그분들이 정말 필요한 것들을 찾아서 해 줘야 되는데, 커리큘럼 짜 놔야 소용도 없어요. 이 교육을 계속 돌려 쓸 게 아니면 별로 필요하지 않더라고요."
4교시 · 왜 준비하지 않았나
대신 매일 관찰했습니다 — 아무 생각 없이 온 것이 아니라, 참가자들의 행동을 보면서 "이걸 좀 더 하시면 좋겠다" 싶은 것들을 매일 아침 녹여 냈다고 했습니다. 진행자의 표현으로는 "플렉시블하게, 픽스하지 않고"입니다. 1주차에 "커리큘럼 안 만들 거다"라고 미리 밝힌 것도 그래서였습니다.
수강생에 대한 평
참가자가 "저희 수강생으로서 나쁘지 않았나요?"라고 묻자 답이 돌아왔습니다.
"되게 열심히 해 주셨고, 매주마다 기대 이상으로 해 오셔서. 이게 대충하려면 진짜 대충하거든요."
4교시 · 참가자들에 대해
대충하는 사람이 많으면 진행하는 사람도 재미가 없고, 이해가 안 돼 질문이 계속 나오면 진도도 나가지 않는다고 했습니다. 그래서 하려고 하는 사람 소수로 하는 것이 가장 좋다는 결론이었습니다.
③태도 하나가 더 남았다 — 긍정과 리셋
소감을 나누던 중 진행자가 "아, 한 가지 얘기 안 했다"며 태도 이야기를 하나 더 꺼냈습니다. 1교시의 태도에서 빠진 항목이었습니다.
"자기가 생각할 때 사고를 최대한 긍정적이게 가지려고 하는 게 가장 좋아요."
4교시 · 마지막 태도
여기에 자기만의 방식을 덧붙였습니다. 매일 아침 출근길에 리셋을 한다는 생각으로 온다는 것입니다 — 지금까지 있던 감정은 그냥 버리고, 새로운 다짐으로.
왜 이 이야기가 마지막에 나왔나 — 바로 다음 문단이 그 이유를 설명합니다. AI를 계속 쓰다 보면 "자기가 계속 바보가 되는 것 같은 느낌"이 드는 구간이 옵니다. 그 구간을 넘기려면 매일 리셋하는 태도가 필요하다는 것입니다.
"바보가 되는 것 같은" 구간
"이게 뭔가 자기가 계속 바보가 되는 것 같고 그런 느낌이 들어요. 근데 그건 어쩔 수 없는 거라서, 그걸 견뎌 내고 하다 보면 '아, 원래 이렇게 하는 거구나' 느껴지고, 그때부터 좀 다를 겁니다."
4교시 · 앞으로 겪게 될 것
이미 오래 써 온 참가자는 그 구간을 지났고, 이번에 시작한 참가자는 앞으로 느끼게 될 것이라고 짚어 줬습니다. 잘 안 되는 시기가 실패가 아니라 통과 구간이라는 예고입니다.
④왜 4주였나
참가자가 기간에 대해 이야기를 꺼냈습니다.
"4주라는 시간이 되게 짧은데, 그래서 더 루즈하지 않을 수 있지 않았나라는 생각도 드네요. 12주 과정이면 4주까지는 괜찮고 5, 6주도 뭐 하겠지. 근데 7, 8주가 되면 사람 자체가 루즈해질 수도 있잖아요."
4교시 · 기간에 대해
진행자도 동의했습니다 — "4주가 딱 좋아요. 열심히 하기도 좋고."
1교시의 21일 이야기와 정확히 맞물립니다. 한 달을 잡으면 첫 주를 빼고 3주가 실제로 움직이는 구간이 되고, 그 21일이 습관이 자리 잡는 길이입니다. → 습관이 되는 3주
⑤AI를 무엇으로 볼 것인가
진행자가 자신의 인식이 바뀐 지점을 이야기했습니다. 계기는 2013년에 나온 영화 한 편이었습니다 — AI와 사람의 관계를 다룬 작품입니다.
처음 봤을 때
"너무 허황된 미래다"라고 생각했습니다
→
최근
여러 AI와 말로 대화하는 것은 익숙해졌지만, 거기까지였습니다
→
지금
작업을 함께하면서 그 영화가 다시 떠올랐다고 했습니다
"진짜 교감? 그러니까 그냥 단순한 대화 프로그램 같은 게 아니라, 얘가 나랑 진짜 대화를 하는 느낌으로."
4교시 · 인식이 바뀐 지점
이 인식의 변화가 표현의 변화로 이어졌습니다.
이전의 표현
지금의 표현
AI를 도구로만 봤다 — "이 시대의 엑셀", 포스트 엑셀이라고 생각했다
더 넓게 보면 관계성이 있다 — "사람의 파트너, 사업의 파트너가 될 수 있지 않을까"
⑥마지막 장면 — AI가 못 하는 것
스터디의 마지막은 애니메이션 극장판 한 편을 함께 보는 것으로 끝났습니다. 어린 시절에 보던 작품이, 그 시청자들이 성인이 된 뒤에 극장판으로 다시 나온 경우였습니다.
왜 이걸 틀었나 — 작품 속에서 그 세계를 볼 수 있는 조건이 어린아이의 순수함이었기 때문입니다. 어릴 때 그것을 봤던 사람이 어른이 되어 같은 이야기를 마주할 때 생기는 감정 — 진행자는 그것을 가리키며 말했습니다.
"저런 눈물샘 있으니까. 저런 것들을 AI가 못해 주죠. 사랑과 관계, 추억을 건드리는 것들. 그런 것들을 AI가 못해요."
4교시 · 마지막
그리고 곧바로 업무로 연결했습니다 — "그래서 영업도 그게 너무 중요하잖아요." 마지막 조언은 이것이었습니다.
"그런 것들만 잘, 자기 전문성 가지면서 할 것들 하시면 잘 되시지 않을까 싶습니다."
4교시 · 마무리 인사
1교시에 육감으로 정리했던 이야기가, 마지막에 추억과 감정이라는 형태로 한 번 더 확인된 셈입니다. → AI가 대체하기 힘든 것
⑦4주를 한 장으로
스터디 전체가 무엇이었는지를, 마지막 날 나온 말들로 정리하면 이렇게 됩니다.
마지막 날 참가자들이 공통으로 꼽은 것은 배운 기능이 아니라 바뀐 접근 방식이었습니다.
주차
남긴 문장
1주차
내려놓는다 · 이해가 안 돼도 일단 따라 한다
2주차
내 손으로 만들어 봐야 안다
3주차
시키고 끝내면 판단이 쌓이지 않는다 — 보는 눈을 기른다
4주차
절차를 반복하면 생각이 따라온다 · 되는 걸 봐야 시도한다 · 한 번 더 하는 사람이 드물다
이 문서 자체가 마지막 과제의 결과물입니다. 4주차 수업을 녹음하고, 전사하고, 교안으로 집필해 빌드한 것 — 지금 보고 있는 화면이 그것입니다. 왼쪽 위 주차 전환기로 3주차 교안도 함께 볼 수 있습니다.
{"about":"ax 스터디 — 자율 실습 교안 이 저장소는 ax 스터디 수업을 각자 자기 손으로 교안 대시보드까지 만들어 보는 실습 꾸러미 입니다. 수업 녹음을 글로 옮기고(전사), 그 전사를 근거로 교안을 집필하고, 빌드해서 지금 보고 있는 것과 같은 단일 html 대시보드를 만드는 것까지가 한 바퀴입니다. 현재 3주차와 4주차 교안이 들어 있습니다. 왼쪽 위의 주차 전환기 로 두 주차를 오갈 수 있습니다. 개발 경험이 없어도 괜찮습니다. 직접 코드를 짜는 게 아니라 내 claude code에게 무엇을 만들지 설명하고, 결과를 검수하는 일 이 실습의 본체입니다. 이 템플릿으로 하는 일 수업 녹음 → 전사 텍스트 → 교안 파셜 집필 → 빌드 한 줄로 index.html 생성 → 진행자에게 전달. 완성본은 진행자가 아카이브에 게시합니다. 지금 들어 있는 것 3주차 — 에이전트 (12개 문서) · 4주차 — 태도와 시야 (15개 문서). 각 주차는 개요 · 주제별 정리 문서 · 교시별 강의기록 으로 구성돼 있습니다. 교안을 한 편 쓸 때마다 메뉴가 한 줄씩 늘어나고, 전부가 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주차에 ai로 무엇을 할 수 있는지 경험했고, 2주차에 내가 실제로 만들 수 있다 는 것을 확인했습니다. 3주차는 그것을 일상과 업무에 통합 하고, 결과를 판단하는 눈 을 기르는 단계입니다. 이번 주의 도착점은 분명합니다 — 노트북 앞에 앉아 있어야만 시킬 수 있던 일을, 채팅창에서 비서처럼 시킬 수 있는 상태 로 옮기는 것입니다. 3주차 한 문장 손에 쥔 것을 놓아야 다른 것을 쥘 수 있습니다. 에이전트를 여러 개 돌리려면 손이 먼저 비어 있어야 합니다. 이번 주에 하는 일 에이전트를 붙여 내가 없는 자리에서도 일이 돌아가게 만듭니다. 오픈클로를 설치해 슬랙에서 봇을 부르고, 반복 작업을 예약해 두고, 봇이 잘 찾아갈 수 있게 지식을 정리합니다. 다만 도구를 늘리는 것이 목적은 아닙니다. 진행자가 1교시에 반복해서 강조한 것은 이것이었습니다 — 시키기만 하고 멈추면 판단하는 힘이 사라진다. 결과를 받고 왜 그렇게 했는지 한 번 더 묻는 것 까지가 이번 주의 실습입니다. ① 오늘의 흐름 — 다섯 단계 수업은 회고에서 시작해 실습으로 끝나는 다섯 단계로 짜여 있습니다. 앞 단계가 뒷 단계의 이유가 됩니다. 1교시가 step 1~3과 step 4의 개념을, 2교시가 step 4의 실습을, 3교시가 step 5와 활용 사례를 담당했습니다. ② 교시별로 다룬 것 3주차는 1교시 2시간 8분 · 2교시 2시간 54분 · 3교시 1시간 29분 , 모두 6시간 31분 진행됐습니다. 교시마다 성격이 뚜렷하게 달랐습니다. 교시 성격 무엇을 했나 1교시 회고와 태도 지난 과제를 열어 보고, 왜 내려놓기부터 시작하는지 정리 2교시 설치와 운영 오픈클로를 실제로 설치해 슬랙에 붙이고 , 봇 운영·보안을 다룸 3교시 지식과 사례 llm 위키 로 지식을 구조화하고, 각자의 활용 사례 를 공유 1교시 — 회고하고 내려놓기 1 2주차 과제 회고 — 만들어진 것과 이해한 것 두 사람의 과제를 화면에 띄우고 과정과 피드백 을 나눴습니다. 결론은 완성도가 아니라 \"내가 이해하고 있는가\" 였습니다. → 과제 회고 문서 2 내려놓기와 보는 눈 — 왜 태도가 먼저인가 1주차 세 원칙 을 다시 확인하고, 『한비자』의 한 대목을 빌려 왜 내려놓아야 하는지 를 짚었습니다. → 내려놓기와 보는 눈 3 에이전트와 오픈클로 — 이번 주의 메인 주제 \"오픈클로랑 클로드 코드랑 뭐가 다른가\" 에 대한 답과, 봇을 여러 개 두고 일하는 방식. → 에이전트와 오픈클로 · 1교시 강의기록 2교시 — 설치하고 운영하기 4 오픈클로 설치와 슬랙봇 연동 가이드 문서 한 장으로 설치를 맡기고, 슬랙에 봇을 붙여 첫 응답 까지 확인했습니다. 권한 문제·재설치·이름 충돌 등 실제로 막힌 지점 이 그대로 담겨 있습니다. → 오픈클로 설치 실습 5 봇 운영과 보안 — 만든","w3-practice-review":"2주차 과제 회고 — 결과물보다 \"이해했는가\" 3주차 1교시는 지난 2주차 과제를 함께 열어 보는 것 으로 시작했습니다. 두 사람이 각자 만든 결과물을 화면에 띄우고, 어떤 배경에서 시작해 어떤 순서로 만들었는지 설명한 뒤, 진행자와 서로가 피드백을 주고받았습니다. 이 시간의 결론은 의외로 결과물의 완성도가 아니었습니다. \"만들어졌다\"와 \"이해했다\"는 다르다 는 것, 그리고 설명하는 순서를 바꾸면 같은 결과물이 훨씬 잘 전달된다 는 것이었습니다. 이번 과제가 무엇이었나 1~2주차에 배운 도구를 따로따로가 아니라 이어 붙여 , 내 목적에 맞는 결과물을 한 번 끝까지 만들어 보는 것. 완성도는 두 번째였고, 먼저 시도해 보는 것이 목적이었습니다. 1교시 앞부분 요약 과제는 도구 조합 연습 이었습니다. mcp 로 피그마에 결과를 옮기고, ui 레퍼런스로 디자인 방향을 잡고, 코덱스 cli로 이미지를 뽑아 하나의 결과물로 합치는 흐름입니다. 두 사람의 결과물은 모두 높은 평가를 받았지만( 9.5점 · 9점 / 10점 만점), 피드백의 초점은 다른 데 있었습니다. 한 사람에게는 \"만들어진 것을 본인이 다 보았는가\"가, 다른 한 사람에게는 \"결과물을 먼저 보여주고 과정을 설명했는가\"가 지적됐습니다. 그리고 공통 숙제가 하나 붙었습니다 — 작업이 끝난 세션을 그대로 두지 말고, 다시 쓸 수 있는 스킬 로 남길 것. ① 과제의 정의 — 배운 것을 이어 붙이기 진행자가 과제를 다시 정리해 준 대목이 시작이었습니다. 이번 과제는 새로운 것을 배우는 자리가 아니라, 이미 배운 것을 한 줄로 꿰는 자리 였습니다. 세 도구를 각각 익히는 것이 1~2주차였다면, 2주차 과제는 그 셋을 하나의 목적 아래 이어 붙이는 연습이었습니다. 진행자가 덧붙인 조건은 두 가지였습니다. 하나는 \"결과물이 마음에 안 들어도 괜찮으니 일단 시도해 보라\" 는 것, 다른 하나는 \"주차가 넘어갈 때마다 발전이 보여야 한다\" 는 것이었습니다. 같은 자리에 머무는 것이 문제이지, 결과가 거친 것은 문제가 아니라는 뜻입니다. ② 설명하는 순서 — 배경 · 맥락 · 목적을 먼저 과제 발표에 들어가기 전에, 두 사람의 설명 방식이 먼저 비교됐습니다. 한 사람은 자기가 무엇을 만들었는지부터 말했고, 다른 사람은 왜 이 과제를 하게 됐는지 부터 말했습니다. 듣는 사람 입장에서 이해가 갈린 지점이 바로 거기였습니다. ① 배경 어떤 문제·상황에서 출발했는지 → ② 맥락 그래서 무엇을 하기로 했는지 → ③ 목적 그 일로 무엇이 달라지길 바라는지 중요한 것은 이 순서가 사람에게만 해당하는 이야기가 아니라는 점 입니다. 진행자는 이 대목을 곧바로 ai 쪽으로 연결했습니다. \"ai한테도 그렇게 설명을 잘해야 됩니다. 맥락을 다 빼놓고 설명하면, 내가 무슨 목표를 가지고 무엇을 만들어 주길 바라는지 모르니까 — 모호할수록 결과는 잘 안","w3-concept-mindset":"내려놓기와 보는 눈 — 3주차가 여기서 시작하는 이유 과제 회고가 끝나고 3주차 본론으로 넘어가면서, 진행자는 새 도구부터 꺼내지 않았습니다. 대신 1주차에 정한 세 가지 원칙을 다시 물었습니다. 도구가 늘어날수록 흔들리는 것은 도구가 아니라 쓰는 사람의 태도 이기 때문입니다. 이 문서는 1교시의 중간 절반 — 왜 기존 방식을 내려놓아야 하는가 , 그리고 실행을 맡긴 다음에 무엇이 남아야 하는가 에 대한 이야기입니다. 이번 주 한 문장 쥔 것을 놓아야 다른 것을 쥘 수 있고, 시키기만 하고 멈추면 판단하는 힘이 사라진다. 3주차의 목표는 도구를 늘리는 것이 아니라 보는 눈을 기르는 것 입니다. 세 주차의 위치 1주차 는 \"ai 시대에 무엇을 할 수 있나\"를 경험한 시간이었고, 2주차 는 \"내가 실제로 할 수 있는 것\"을 직접 만들어 본 시간이었습니다. 3주차 는 그것을 일상과 업무에 통합하고, 결과를 판단하는 눈을 기르는 단계입니다. 그래서 이번 주에는 도구 사용법보다 내가 없는 자리에서도 일이 돌아가게 만드는 구조 와, 그 결과를 내가 판단할 수 있는 기준 이 함께 다뤄집니다. ① 1주차 세 원칙 — 다시 꺼내는 이유 진행자가 참가자들에게 직접 물었고, 세 가지가 다시 확인됐습니다. 원칙 1 기존 방식을 내려놓는다 지금까지 익숙했던 업무 방식을 일단 내려놓습니다. 손에 남아 있으면 새것이 들어올 자리가 없습니다. 원칙 2 일단 매일 해 본다 되는지 안 되는지 따지기 전에 일단 열어서 해 봅니다. 업무의 시작을 클로드 코드로 잡는 습관 자체가 실력이 됩니다. 원칙 3 호들갑에 휘둘리지 않는다 새 도구가 나올 때마다 들썩이는 이야기에 중심을 잃지 않습니다. 본질은 하나이고, 알면 나머지는 따라옵니다. 3주차에 이 셋을 다시 꺼낸 이유는 분명합니다. 이번 주부터는 에이전트를 여러 개 돌리는 이야기 가 나옵니다. 여러 개를 굴리려면 손이 먼저 비어 있어야 합니다. 하나를 붙들고 있으면 두 번째를 잡을 수 없습니다. ② 왜 내려놓아야 하는가 진행자는 손에 들고 있던 물건을 들어 보이며 설명했습니다. 이미 뭔가를 쥐고 있으면, 그 상태로 하나를 더 집기가 어렵습니다. 내려놓아야 다음 것을 잡을 수 있다는 아주 단순한 이야기입니다. 이 이야기는 뒤에 나온 책 한 권으로 이어졌습니다. 진행자가 오랫동안 멘토링을 받아 온 분에게 선물 받은 『한비자』 입니다. 서양에 마키아벨리가 있다면 동양에는 한비자가 있다고 말해지는 고전으로, 법과 통치를 다루되 우화 형태로 풀어써서 읽기 쉽게 만든 책이라고 소개됐습니다. 그 안에 이런 문장이 있습니다. \"쥔 것을 놓아야 된다. 나무도 꽃이 져야 열매가 맺히고, 강도 말라야 바다가 된다.\" 1교시 · 『한비자』를 소개하며 셋 다 같은 말입니다 — 지금 가진 것을 놓을 수 있어야 다음 단계가 열립니다. 진행자는 이것을 \"지금 시대에 더 그렇다","w3-concept-agent":"에이전트와 오픈클로 — 내가 없는 자리에서도 돌아가게 1교시 후반에 3주차의 메인 주제가 나왔습니다. 에이전트 입니다. 참가자에게서 가장 먼저 나온 질문도 여기였습니다 — \"오픈클로랑 클로드 코드랑 뭐가 달라요?\" 이미 설치해 본 사람조차 아직 헷갈린다고 했습니다. 이 문서는 그 질문에 대한 1교시의 답과, 실제로 이것이 무엇을 바꾸는지를 정리한 것입니다. 설치와 실습은 2교시 에서 이어집니다. 한 줄로 클로드 코드가 엔진이라면, 오픈클로는 그 엔진을 얹은 비서입니다. 같은 능력을 쓰지만 부르는 자리가 터미널에서 채팅창으로 옮겨 갑니다. 1교시에서 다룬 범위 1교시는 개념과 예고 까지입니다. 왜 이것이 필요한지, 무엇이 가능해지는지를 먼저 그려 두고, 실제 설치·연결은 2교시로 넘겼습니다. 진행자가 이유를 분명히 했습니다 — \"이번 주에 뭘 할 건지 한 번 다 보여 줘야, 그다음에 무엇을 하겠구나 하고 인지가 된다.\" 이 문서 자체가 그 예고편에 해당합니다. ① 클로드 코드와 오픈클로 — 무엇이 다른가 진행자의 비유는 자동차였습니다. 클로드 코드 엔진 · 심장 실제로 일을 하는 실행부 입니다. 생각하고, 파일을 읽고 쓰고, 명령을 실행합니다. 다만 내가 터미널 앞에 앉아 있어야 시킬 수 있습니다. 오픈클로 비서 · 에이전트의 몸 그 엔진을 얹고 겉에서 사람과 대화하는 역할 입니다. 채팅창에서 말을 받아 엔진에 넘기고, 결과를 다시 채팅으로 돌려줍니다. 그래서 달라지는 것은 능력이 아니라 자리 입니다. 지금은 노트북을 열고 터미널을 켜야 시킬 수 있지만, 오픈클로를 붙이면 슬랙이나 디스코드에서 이름을 부르는 것 으로 같은 일을 시킬 수 있습니다. 진행자는 실제 사례를 들었습니다 — 주말에 밖에 나가 있는 동안에도 채팅으로 작업을 걸어 두고 결과를 받아 봤다고 합니다. ② 세션 하나가 아니라 봇 여러 개 차이는 하나 더 있습니다. 클로드 코드는 필요할 때마다 세션을 여는 방식입니다. 오픈클로는 봇을 원하는 만큼 미리 만들어 두는 방식입니다. 진행자는 개인적으로 봇 세 개를 운영 중 이라고 공유했습니다. 각각 다른 역할이 지정돼 있고, 필요에 따라 골라 쓰거나 함께 씁니다. 쓰임 1 링크를 던져 두는 곳 읽고 싶은 글이나 영상 링크를 봇에게 그냥 던져 둡니다. 봇이 안에 들어가 내용을 분석하고 이해해서 맥락을 갖고 있습니다. 나중에 \"그때 그거 뭐였지?\" 하면 설명해 줍니다. 자기 자신에게 카카오톡으로 링크를 보내 두던 습관을 대체하는 용도입니다. 쓰임 2 봇끼리 토론하게 하는 것 봇 하나에게 시키면 그 하나가 파악한 만큼만 나옵니다. 둘 이상에게 같은 주제를 놓고 토론하게 하면, 서로 주고받으며 평가하고 더 뽑아낼 것을 찾아냅니다. 진행자는 중간중간 끼어들어 결정을 내려 준다고 했습니다. 쓰임 3 정해진 시간에 반복시키는 것 \"아침마다 이것 좀 해 줘\" 같은 반복 ","w3-lecture1":"3주차 1교시 강의기록 2026년 8월 2일 오전에 진행된 ax 스터디 3주차 1교시 의 기록입니다. 녹음 2시간 8분 분량을 시간 순서대로 정리했습니다. 이 문서는 흐름을 따라가는 기록 이고, 주제별로 정리된 내용은 과제 회고 · 내려놓기와 보는 눈 · 에이전트와 오픈클로 세 문서에 나눠 담았습니다. 1교시 한 줄 지난 과제를 함께 열어 보며 \"만들어졌다\"와 \"이해했다\"의 차이 를 확인하고, 쥔 것을 놓아야 다음을 쥔다는 이번 주 주제로 넘어간 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭 까지만 표기하고 실명·소속·직함은 쓰지 않았습니다. 진행자 이름도 표기하지 않습니다. 회사 내부 사정·인사·경영에 관한 대화 구간 은 대외 공개를 고려해 교안에서 제외하고, 그 자리에 제외 표시를 남겼습니다. ① 도입 — 오늘 녹음을 꼭 켜야 하는 이유 00:00 – 00:04 00:00 \"오늘 녹음을 켜셔야 합니다\" 수업은 진행자가 참가자들에게 녹음이 켜져 있는지 확인하는 것으로 시작했습니다. 이번 주에는 교안을 각자 직접 만들어 보는 것 이 과제이고, 진행자가 만든 교안을 나눠 주지 않기 때문입니다. 녹음이 없으면 만들 재료가 없습니다. \"오늘 켜셔야 제가 그 교안 만드는 걸 같이 해 보면서 갈 겁니다. 없으시면 안 나와요. 직접 만드셔야 되는 겁니다.\" 00:00 2주차 과제가 무엇이었는지 다시 정리 진행자가 지난 과제의 목적을 다시 짚었습니다. 1~2주차에 배운 것들을 이어 붙여 , 자기 목적에 맞는 결과물을 한 번 끝까지 만들어 보는 것이었습니다. 피그마 mcp 로 결과물을 옮겨 본다 디자인 전문가가 아니므로 ui 레퍼런스 를 활용한다 코덱스 cli 로 이미지를 뽑아 함께 쓴다 조건은 두 가지였습니다. 결과물이 마음에 안 들어도 괜찮으니 일단 시도할 것 , 그리고 주차가 넘어가면 발전이 보여야 할 것. 진행자는 \"똑같으면 어떡해요\"라는 말로 후자를 강조했습니다. ② 설명하는 순서 — 배경 · 맥락 · 목적 00:04 – 00:07 00:04 두 사람의 설명 방식이 비교되다 과제 발표에 들어가기 전, 두 사람의 설명 방식이 자연스럽게 비교됐습니다. 한 사람은 무엇을 만들었는지부터 , 다른 한 사람은 어떤 배경에서 이 과제를 하게 됐는지부터 말했습니다. 진행자는 후자가 훨씬 이해하기 쉬웠다고 평가하며, 차이가 배경 → 맥락 → 목적 의 순서에 있다고 정리했습니다. 그리고 곧바로 ai 쪽으로 연결했습니다. \"ai한테도 그렇게 설명을 잘해야 됩니다. 맥락을 다 빼놓고 설명하면 내가 뭘 만들어 주길 바라는지 모르니까 — 모호할수록 결과는 잘 안 나옵니다.\" 진행자는 또 하나를 덧붙였습니다. 남의 말을 먼저 끝까지 들어 보라 는 것입니다. 내 입장을 말하기 전에 상대가 어떻게 하","w3-practice-openclaw":"오픈클로 설치와 슬랙봇 연동 — 2교시 실습 1교시에서 개념으로 그려 둔 것을 실제로 설치해 본 시간 입니다. 참가자 한 사람의 개인 슬랙에 봇을 하나 만들어, 클로드 코드와 연결하고, 슬랙에서 이름을 불러 답이 오는 데까지 진행했습니다. 진행자가 시작부터 못 박은 것이 있습니다 — 설치 과정을 한 단계씩 다 이해하는 것이 목적이 아니라는 것 입니다. 진행 방식 설치를 한 땀 한 땀 따라가면 두세 시간이 걸립니다. 그래서 가이드 문서를 통째로 넘겨 ai가 설치하게 하고, 사람은 \"이걸로 무엇을 할 수 있는가\"에 시간을 쓰는 방식으로 진행했습니다. 2교시 앞부분 요약 설치 자체는 가이드 문서 한 장을 클로드 코드에 붙여넣는 것 으로 시작합니다. 나머지는 대부분 ai가 처리하고, 사람이 하는 일은 슬랙 쪽 설정 (앱 생성 · 권한 · 토큰)과 막혔을 때 상황을 설명해 주는 것 입니다. 실습 중 실제로 막힌 지점도 그대로 겪었습니다 — 게스트 권한이라 앱 설치가 안 되고, 설정을 바꾼 뒤 재설치를 해야 반영되고, 봇 이름 때문에 엉뚱한 단어에도 반응하는 문제가 차례로 나왔습니다. 이 문서는 그 과정을 순서대로 정리한 것입니다. ① 왜 슬랙에 붙이는가 — 로컬의 한계 2교시에서 가장 여러 번 반복된 질문이 이것이었습니다. \"오픈클로도 자체 웹 화면이 있는데, 왜 굳이 슬랙에 붙이나?\" 답은 로컬 이라는 말에 있습니다. 오픈클로를 설치하면 웹 화면이 내 컴퓨터 안에서만 열립니다. 밖에서 휴대폰으로 그 주소를 쳐도 열리지 않습니다. 개발팀이 localhost 링크를 공유해도 열리는 이유는 같은 와이파이를 쓰기 때문 입니다. 와이파이가 다르면 그 주소는 열리지 않습니다. 해결책은 둘입니다. 서버에 올리거나 , 이미 어디서든 열리는 채팅 플랫폼을 창구로 쓰는 것 입니다. 서버를 올리려면 배포 작업이 필요하지만, 슬랙은 이미 전 세계 어디서나 열립니다. 그래서 슬랙·디스코드를 게이트웨이로 붙입니다. 카카오톡도 가능합니다. 다만 공식 api가 열려 있지 않아, 휴대폰 한 대를 따로 연결해 24시간 켜 두는 방식 을 써야 합니다. 오픈채팅에서 보이는 카카오톡 봇 중에도 이렇게 만든 것이 있습니다. ② 설치 전 — 터미널에서 길 찾기 실습 중 참가자가 \"매번 수업 들어도 이게 이해가 안 된다\" 고 한 부분입니다. 폴더를 오가는 명령 몇 개만 알면 됩니다. 명령 · 기호 뜻 비유하자면 cd 폴더를 이동 하는 명령 (change directory) 폴더를 더블클릭해 들어가는 것 ls 지금 폴더 안에 무엇이 있는지 목록 을 본다 폴더 창을 열어 보는 것 ~ 내 사용자 폴더 (홈) 맥에서 로그인한 내 계정 폴더 / 시스템 전체의 최상위 (루트) 윈도우의 c 드라이브 cd .. 한 단계 밖으로 나간다 뒤로 가기 cmd + t 터미널 새 탭 을 연다 브라우저 새 탭과 같다 cd ~/mike-a","w3-concept-bot-ops":"봇 운영과 보안 — 만든 다음이 진짜다 봇은 설치하면 끝나는 물건이 아닙니다. 2교시의 절반은 만들어 둔 봇을 어떻게 다듬고, 무엇을 조심해야 하는지 에 쓰였습니다. 진행자가 몇 달째 봇 세 개를 운영하며 겪은 것들 — 실제로 뚫린 보안 사고 , 봇끼리 대화가 안 되는 이유, 관리하지 않으면 기능이 죽는 문제 — 가 그대로 나왔습니다. 한 줄로 봇의 실력은 도구가 아니라 누가 어떻게 다듬었느냐 에서 갈립니다. 사람을 관리하는 것과 똑같습니다. 이 문서에서 다루는 것 ① 오픈클로와 헤르메스 의 성격 차이와, 어디에 무엇을 쓸지 ② 상황별 모델 선택 ③ 실제로 뚫렸던 보안 사고 와 권한 설계 ④ 봇을 여러 개 둘 때의 협업과 중재 ⑤ 잘 다듬어진 봇의 구조를 새 봇에 물려주는 법 . 공통된 결론은 하나입니다 — 한 번 만들어 두고 방치하면 봇은 점점 못하게 됩니다. ① 오픈클로와 헤르메스 — 성격이 다르다 대표적인 에이전트 도구가 둘 있습니다. 진행자는 \"사람들이 흔히 말하는 대로\" 이렇게 요약했습니다. 오픈클로 시킨 것을 정확하게 정해진 하네스 안에서 요청한 일을 안정적으로 합니다. 한 번 잘 처리한 방식은 저장해 두었다가 다음에도 같은 방식으로 해 줍니다. 헤르메스 알아서 개선하려 든다 기본 동작에 루프 가 들어 있어, 시켜 두면 스스로 스킬을 만들고 계속 개선 하려 합니다. 무엇을 하고 있는지도 보여 줍니다. 참가자들의 첫 반응은 \"헤르메스가 더 잘할 것 같다\" 였습니다. 스스로 개선한다니 좋아 보였기 때문입니다. 그런데 곧바로 반대 측면이 나왔습니다. \"헤르메스가 자기 개발을 하는데, 그게 내가 원하는 방향이 아닐 수도 있잖아요. 방향이 어긋나면 고치는 게 좀 힘들어요.\" 2교시 · 두 도구를 비교하며 이런 일에는 어느 쪽 이유 회사 공동 업무 오픈클로 대외 메일처럼 보안이 중요한 일 은 규칙과 권한을 확실히 잡아 둘 수 있어야 한다 정형화된 반복 작업 오픈클로 정해진 틀 안에서 같은 결과를 반복 해 내는 데 강하다 개인적인 탐색 헤르메스 알아서 굴러가며 이것저것 시도 하는 편이 편하다 정작 진행자의 결론은 담담했습니다 — \"둘이 그렇게 큰 차이가 있는 것 같진 않다.\" 요즘 사람들은 헤르메스를 더 좋아하지만, 실제로는 누가 어떻게 다듬느냐 에 따라 결과가 훨씬 크게 갈립니다. 하네스를 잘 구축해 두면 오픈클로가 더 편할 수 있다는 것이 진행자의 경험이었습니다. ② 모델 선택 — 무엇에 무엇을 쓰나 2교시는 \"어떤 모델을 언제 쓰나\" 라는 질문으로 시작했습니다. 진행자의 정리는 일을 나누는 것 이었습니다. 전략 · 의사결정 사고하고 방향을 정하는 일 은 아직 상위 모델 이 낫다 → 구현 · 코딩 실제로 만들어 내는 일 은 오푸스 계열 이 앞선다 → 논리 · 완결성 검토 빠진 것과 개선점 을 짚는 일은 코덱스 가 강하다 실제 사용 사례도 공유됐습니다. 한 참가","w3-lecture2":"3주차 2교시 강의기록 2026년 8월 2일 오후에 진행된 ax 스터디 3주차 2교시 의 기록입니다. 녹음 2시간 54분 분량을 시간 순서대로 정리했습니다. 주제별로 정리된 내용은 오픈클로 설치 실습 과 봇 운영과 보안 두 문서에 나눠 담았습니다. 2교시 한 줄 개념으로 그려 둔 에이전트를 실제로 설치해 슬랙에 붙이고 , 만든 다음에 무엇을 해야 하는지를 배운 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭 까지만 표기하고 진행자 이름은 쓰지 않습니다. 봇 이름은 실습 대상 이므로 그대로 표기합니다. 회사 내부 사정·제품 전략·인사에 관한 대화 는 대외 공개를 고려해 제외하고 그 자리에 표시만 남겼습니다. ① 모델을 언제 무엇으로 쓰나 00:00 – 00:05 00:00 질문으로 시작 — \"어떤 상황에 무엇을 쓰나\" 참가자의 질문으로 2교시가 열렸습니다. 진행자는 일을 나누는 방식 으로 답했습니다. 전략과 의사결정 — 사고하고 방향을 정하는 일은 아직 상위 모델 이 낫다 구현과 코딩 — 실제로 만들어 내는 일은 오푸스 계열 이 앞선다 논리성·완결성 검토 — 빠진 것과 개선점을 짚는 일은 코덱스 가 가장 낫다 한 참가자는 기획·설계 문서를 다 쓴 뒤 코덱스에 검토를 맡긴다 고 공유했고, \"뭐가 왜 빠졌고 어떻게 개선돼야 하는지 잘 짚어 준다\" 고 평가했습니다. 00:02 메인은 상위 모델, 서브는 오푸스로 해도 되나 이론상 최선이지만 토큰이 크게 늘어난다 는 답이었습니다. 현실적인 대안은 오푸스로 돌리면서 필요한 부분만 다른 cli 도구를 붙여 쓰는 것 이었습니다. 또한 모델이 나올 때마다 벤치마크가 함께 공개 되니 그것을 보고 판단하라는 조언이 이어졌습니다. 그 자료를 ai에게 학습시켜 두고 \"내 작업에 맞춰 모델과 effort를 골라 달라\" 고 맡기는 방법도 언급됐지만, \"효율적이라는 기준이 상황마다 달라서\" 일률적으로 정하기 어렵다는 단서가 붙었습니다. ② 오픈클로와 헤르메스 00:05 – 00:19 00:09 팀에서 실제로 쓰는 봇들을 열어 보다 진행자의 팀은 세 달 전부터 슬랙에 봇을 붙여 쓰고 있었습니다. 마케팅 채널과 프로덕트 채널에 각자의 봇이 들어가 있고, 활용하지 않는 사람의 봇은 뺐다고 했습니다. 한 참가자가 말했습니다 — \"생각보다 봇을 깎는 게 어렵다.\" 진행자의 답은 짧았습니다. \"열심히 안 가르치니까.\" 00:12 두 도구의 성격 차이 대표적인 에이전트 도구 둘을 비교했습니다. 오픈클로 — 시킨 것을 하네스에 맞게 안정적으로 한다. 잘 처리한 방식은 저장해 두고 다음에도 같은 방식으로 해 준다 헤르메스 — 루프를 돌며 스스로 스킬을 만들고 계속 개선하려 한다. 무엇을 하고 있는지도 보여 준다 참가자들의 첫 반응은 모두 \"헤르메스가 더 잘할 것","w3-concept-llm-wiki":"llm 위키와 지식 그래프 — ai가 찾아가는 길을 깔아 둔다 3교시의 중심 주제입니다. 봇을 만들고 다듬는 것까지 왔다면, 이제 그 봇이 무엇을 근거로 답하게 할 것인가 가 남습니다. 진행자의 표현으로는 \"ai가 잘 찾아가게 하는 것\" 입니다. 이름은 낯설지만 하는 일은 단순합니다 — 지식을 한곳에 모으고, 그 사이에 길을 내는 것 입니다. 한 줄로 사람이 읽으라고 쌓아 둔 지식은 ai에게 전부 읽어야 하는 짐 입니다. 관계를 미리 연결해 두면 ai는 읽지 않고 타고 갑니다. 3교시에서 다룬 것 ① llm 위키가 무엇이고 왜 빠른가 ② 그것을 실제로 담는 도구 옵시디언 ③ ai에게 위키화를 지시하는 방법 ④ 만든 뒤의 품질 검증 루프 ⑤ 봇을 교정하는 대화형 피드백 ⑥ 자료가 저절로 쌓이게 하는 자동화 . 가장 강조된 문장은 이것이었습니다 — \"만든다고 잘 되는 게 아니라, 잘 만들어야 잘 되는 겁니다.\" ① llm 위키란 무엇인가 이름을 두 조각으로 나눠 보면 쉽습니다. 위키 정보를 차곡차곡 쌓아 관리하는 것 . 백과사전형 사이트를 떠올리면 됩니다 + llm 그 위키를 읽는 대상이 사람이 아니라 ai 라는 뜻 = llm 위키 ai가 이해하고 찾아가기 쉽게 만들어 둔 지식 저장소 왜 굳이 ai용으로 따로 만드나. 진행자의 설명은 속도 였습니다. ai가 만들어 내는 정보의 양이 사람이 정리하는 속도를 넘어섰기 때문에, 찾아가는 구조 자체를 미리 깔아 두자 는 발상입니다. 마크다운만 쌓아 두면 무슨 일이 생기나 진행자는 이것을 개발 쪽의 그래프 탐색 에 비유했습니다. 관계가 잘 형성돼 있고 추적이 가능하면 컴퓨터는 찾아가는 일을 아주 잘합니다. 반대로 문서만 있으면 전부 읽고, 문장을 조합하고, 맞는지 판단하는 과정을 매번 반복해야 합니다. \"이 관계를 설정해 놓고, 이쪽으로 가면 이 내용이 있구나만 알게 하는 것 — 찾아갈 수 있는 발판을 만들어 놓은 게 llm 위키입니다.\" 3교시 · llm 위키 설명 한 참가자가 이해한 것을 이렇게 되짚었습니다 — \"뇌 구조 같네요.\" 사람도 하나를 떠올리면 관련된 것들이 함께 떠오르는데, 그 연결을 문서 사이에 만들어 두는 것입니다. ② 옵시디언 — 그것을 담는 도구 이 구조를 실제로 담는 도구로 옵시디언 이 소개됐습니다. 원래는 ai와 무관한 기록용 앱 입니다. 특징 1 마크다운으로 쓴다 평범한 텍스트 파일입니다. 특정 앱에 갇히지 않고 , ai가 읽기도 쉽습니다. 특징 2 노트끼리 링크한다 책의 주석 처럼 한 노트에서 다른 노트로 연결고리를 겁니다. 그 연결이 쌓이면 그래프 가 됩니다. 특징 3 그래프 뷰로 본다 연결 관계를 한 화면에 그림으로 보여 줍니다. 무엇이 떨어져 있는지 눈으로 확인됩니다. 원래 옵시디언은 세컨드 브레인 (제2의 뇌)을 만드는 생산성 도구로 알려져 있었습니다. 사람이 직접 링크를 걸고 사람이 보","w3-practice-usecase":"ai 활용 사례 — 실제로 이렇게 써 봤다 3교시 후반은 각자 해 본 것을 꺼내 보는 시간 이었습니다. 업무가 아니라 일상에서 시도한 것들 이라 오히려 방법이 잘 보였습니다. 세 가지를 다뤘습니다 — 영상을 쪼개서 조사하기 , 여행 가이드북 만들기 , 그리고 ai로 영상을 만들 때의 접근법 입니다. 이 사례들의 공통점 셋 다 \"ai에게 무엇을 시킬까\"가 아니라 \"내가 가진 것을 어떻게 넣을까\" 에서 출발했습니다. 영상 한 개, 예약 내역, 좋아하는 영화 — 이미 있는 것을 재료로 바꾼 것입니다. 한눈에 사례 1 — 6초짜리 영상을 0.5초 단위로 쪼개 제품 조사를 맡기고, 자는 동안 돌려 메일로 결과를 받았습니다. 사례 2 — 4박 5일 여행을 위해 지도·통행료·휴무일·비상 대응·현장 해설 까지 담긴 가이드북을 만들었습니다. 사례 3 — ai 영상 제작에서 무엇이 결과를 가르는지 — 레퍼런스와 스토리보드, 그리고 컷을 짧게 나누는 것이 핵심이었습니다. ① 영상을 쪼개서 조사시키기 1교시에서 영상을 프레임으로 분해 하는 방법이 언급됐는데, 3교시에서 그것을 실제로 쓴 사례가 나왔습니다. 재료는 6초짜리 짧은 영상 하나 였습니다. 1930년대 영국에서 냉장고에 붙여 쓰던 장바구니 체크 보드 가 담긴 영상이었고, 가족이 \"이런 거 만들면 어떨 것 같아?\" 라고 물은 것이 계기였습니다. 영상 하나만 주고 \"이게 무슨 제품인지\"부터 알아내게 한 것이 출발입니다. 본인도 처음엔 그게 어떤 물건인지 몰랐습니다. 돌아온 결론 — \"사업성은 낮습니다\" 조사 결과는 냉정했습니다. 이미 저렴한 복각 제품이 있고 , 빈티지 숍에서도 살 수 있어 사업성이 낮다는 답이었습니다. 원래 만들던 회사도 아직 존재한다는 것까지 확인됐습니다. \"얘가 말해 주는 게 모든 게 정답은 아닐 수 있으니까, 진짜 해 보고 싶으면 해 봐도 되는 거죠.\" 3교시 · 조사 결과를 두고 이 대목이 보는 눈 과 이어집니다. ai가 낸 결론을 그대로 받아들이는 것도, 무시하는 것도 아닙니다. 조사 결과는 판단 재료 이고, 결정은 사람이 합니다. 실제로 이 자리에서도 \"영상 반응이 좋으면 제품까지 가 보는 것도 괜찮다\"는 반대 의견이 함께 나왔습니다. 같은 방법의 다른 사례 도 공유됐습니다. 가족이 예전에 편집한 영상을 3초 단위로 쪼개 고, \"이 영상의 분위기만 이해해서 새 영상을 만들어 줘\" 라고 요청한 것입니다. 화면을 그대로 베끼는 게 아니라 흐름과 톤을 재료로 넘기는 방식입니다. ② 여행 가이드북 만들기 두 번째 사례는 4박 5일 가족 여행 준비였습니다. 일정표 수준이 아니라 현장에서 실제로 쓰는 문서 를 만든 것이 특징입니다. 기본 일정과 이동 숙소와 이동 경로를 정리하고 지도에 연동 해, 열면 경로가 그대로 뜨게 만들었습니다. 통행료 까지 경로별로 계산했습니다. 확인 휴무일 이중 점검 가게 휴무일을 1차","w3-lecture3":"3주차 3교시 강의기록 2026년 8월 2일 저녁에 진행된 ax 스터디 3주차 3교시 의 기록입니다. 녹음 1시간 29분 분량을 시간 순서대로 정리했습니다. 3주차의 마지막 교시입니다. 주제별로 정리된 내용은 llm 위키와 지식 그래프 와 ai 활용 사례 두 문서에 담았습니다. 3교시 한 줄 봇이 무엇을 근거로 답하게 할 것인가 를 다루고, 각자 실제로 해 본 것을 꺼내 보며 3주차를 마무리한 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭 까지만 표기하고 진행자 이름은 쓰지 않습니다. 가족·지인에 관한 언급은 관계만 남기고 개인 정보는 제외했습니다. ① llm 위키화를 지시하다 00:00 – 00:06 00:00 불러 주는 대로 받아 적기 3교시는 진행자가 지시문을 불러 주고 참가자가 받아 적는 장면으로 시작했습니다. 봇에게 지금까지의 모든 것을 위키 형태로 저장하게 하는 요청이었습니다. 봇과의 모든 규칙과 모든 대화 내용을 llm 위키화해서 저장하도록 해. 저장할 때는 지금 있는 구조를 전체적으로 파악해 보고, llm 위키로 구조화했을 때의 구조와 들어가는 내용에 신경 쓰고, 일자·규칙 같은 필요한 내용들을 다 검토·검증·계획해서 문서화한 뒤에 진행해 줘. 필요하다면 원문도 별도로 저장하고. 무엇을 기록할지도 명확히 했습니다. 채팅 내용 내가 시킨 것과 정한 규칙 동료가 요청한 것 그리고 어떤 판단을 해서 그렇게 바꿨는지 00:01 구조 자체를 검증하게 하는 한 문장 지시문의 마지막 부분이 핵심이었습니다. llm 위키가 정확히 어떤 구조가 베스트 프랙티스인지 지금 내 상황에 맞게 검증해 보고, 계획하는 것에도 점수 평가를 돌리고, 규칙을 정확하게 지정해 문서화해 놓고, 앞으로 대화할 때 그 방식을 쓰도록 해. 일반적인 정답이 아니라 \"지금 내 상황에서\" 최선인 구조 를 찾게 하고, 계획 단계에도 점수 평가 를 붙이고, 정해진 방식을 규칙 문서로 남겨 이후에도 쓰게 하는 것입니다. 참가자가 \"중간중간 좀 빠졌다\" 고 하자 진행자는 \"빠져도 된다, 대충 그 정도면 된다\" 고 답했습니다. 그리고 그 지시문을 스터디 방에 그대로 공유 해 다른 참가자도 볼 수 있게 했습니다. 00:05 같은 규칙을 다른 봇에도 한 참가자의 봇에 적용한 규칙을 다른 참가자의 봇에도 동일하게 적용 하도록 이어서 지시했습니다. 다만 그대로 복사하는 것이 아니라, 적용하기 전에 그 상황에서의 베스트 프랙티스를 설계하고 평가하는 단계 를 거치게 했습니다. 00:06 지난 작업 세션도 규칙으로 2주차 과제를 진행했던 세션을 찾아, 앞으로 비슷한 작업을 또 할 것이니 잘 진행된 부분만 분석해 스킬과 규칙으로 정리 하라고 요청했습니다. 개인 기록 폴더에 정리돼 있는 내용과 오픈클로 작업 세션의 내용까지","w4-overview":"4주차 개요 — ai가 대체하기 힘든 것 1주차에 ai로 무엇을 할 수 있는지 봤고, 2주차에 내가 만들 수 있다 는 것을 확인했고, 3주차에 에이전트를 붙여 일이 돌아가게 만들었습니다. 4주차는 마지막 주 입니다. 이번 주에는 새 도구를 배우지 않았습니다. 대신 한 달 동안 왜 그렇게 시켰는지 를 회수하고, 도구가 아니라 태도와 시야 에 대해 이야기했습니다. 4주차 한 문장 도구는 금방 배웁니다. 남는 것은 매일 반복해서 만든 습관과, 그 반복이 넓혀 준 시야입니다. 이번 주에 하는 일 한 달 동안 각자 무엇을 해 봤는지 결과물을 열어 놓고 이야기합니다. 그리고 진행자가 1주차에 던져 둔 세 가지 원칙 이 왜 그 순서였는지를 마지막 주에 회수합니다. 2교시는 한 걸음 더 나갑니다 — 레퍼런스를 판단 근거가 되는 데이터 로 바꿔 두면 전문가가 아니어도 의사결정을 할 수 있다는 것, 그리고 그런 방식이 조직에는 왜 잘 퍼지지 않는지 까지. ① 오늘의 흐름 — 네 단계 4주차는 회고 → 태도 → 시야 → 실습 → 마무리 의 순서로 진행됐습니다. 앞이 뒤의 이유가 되는 구조는 지난주와 같습니다. 1교시가 step 1~3을, 2교시가 step 4를, 3교시가 step 5를 담당했고, 4교시에 한 달 전체를 마무리 했습니다. ② 교시별로 다룬 것 4주차는 1교시 1시간 15분 · 2교시 50분 · 3교시 2시간 15분 · 4교시 16분 , 모두 4시간 36분 진행됐습니다. 오전에는 이야기를, 오후에는 손으로 하는 실습 을 했습니다. 교시 성격 무엇을 했나 1교시 회고와 태도 한 주간 각자의 실제 결과물 을 열어 보고, 습관·태도·대체 불가능한 것 을 정리 2교시 시야와 확산 의사결정 os 구상을 시연하고, ax가 조직에 퍼지지 않는 이유 를 짚음 3교시 실습 클라우드에 서버를 만들고 배포하고 도메인·https까지 각자 끝냄 4교시 마무리 한 달간의 소감 을 나누고, 진행자의 챌린지 와 마지막 태도를 공유 1교시 — 회고하고, 태도를 정리하다 1 습관이 되는 3주 — 왜 매일 하라고 했나 1주차에 정한 세 원칙 을 다시 꺼내고, 21일 이라는 숫자로 왜 매일 반복을 요구했는지 설명했습니다. → 습관이 되는 3주 2 한 주간의 ai 활용 회고 — 각자 이렇게 써 봤다 봇 자동화, 신청 서류 작성, 영업 전략 보고서 까지 실제 결과물을 화면에 띄우고 피드백을 나눴습니다. 프롬프트에 쓰는 마크다운 기법 도 여기서 나왔습니다. → 한 주간의 ai 활용 회고 3 태도 — 한계를 긋지 않고, 배려로 신뢰를 쌓는다 스스로 \"이건 안 될 거야\" 라고 선을 긋는 순간 그 뒤로 이어지지 않습니다. 팀의 경계가 허물어진 이야기, 배려와 신뢰, 자료를 다듬어 전달하는 진정성까지. → 태도 — 한계를 긋지 않는다 4 ai가 대체하기 힘든 것 4주차의 제목이기도 합니다. 방향 설정 · 책임 · 사","w4-concept-habit":"습관이 되는 3주 — 왜 매일 하라고 했나 4주차 1교시는 1주차에 던져 둔 것을 회수하는 자리 로 시작했습니다. 진행자의 표현으로는 \"처음에 떡밥 뿌린 걸 회수하는 것\" 입니다. 한 달이라는 기간, 매일 하라는 요구, 이해가 안 돼도 따라 하라는 주문 — 세 가지가 하나의 설계였다 는 것이 이 시간의 내용입니다. 한 줄 요약 생각을 바꿔서 습관이 되는 게 아니라, 절차를 매일 반복하면 생각이 따라옵니다. 순서가 반대입니다. ① 세 원칙을 다시 묻다 진행자가 마지막 주차를 열며 물었습니다 — \"1주차에 세 개를 꼭 지켜야 된다고 했죠?\" 참가자들의 대답은 이랬습니다. 첫 번째 내려놓는다 \"내려놓고 일단 시키는 대로 한다\" → 두 번째 그 자리에서 아무도 떠올리지 못했습니다 → 세 번째 이해가 안 돼도 일단 따라 한다 두 번째가 생각나지 않는다는 말이 나오자 진행자가 받았습니다. \"생각 안 나면 잘 지키는 거 아닙니까?\" 1교시 · 세 원칙을 되짚으며 참가자가 \"매일 그러거든요\" 라고 답했고, 진행자도 \"맞아, 매일 하잖아\" 라고 이어받았습니다. 이미 매일 하고 있으면 지켜야 할 규칙으로 의식되지 않는다 는 것입니다. 규칙을 잊었다는 사실 자체가 지표가 된 셈입니다. 기록 원칙 — 두 번째 원칙이 무엇이었는지는 전사에 나오지 않습니다. 그 자리에서 아무도 말하지 않았고 진행자도 짚어 주지 않은 채 다음 이야기로 넘어갔습니다. 그럴듯하게 채워 넣지 않고 비어 있는 그대로 둡니다. 매일 한다는 것의 실제 진행자는 한 달 동안 하루도 빼먹지 않았다 고 했습니다. 다만 그것이 수월했다는 이야기는 아니었습니다. 본인에게 클로드 코드는 일 그 자체 여서 업무 시간에 하기가 어려웠습니다 그래서 퇴근하고 최대한 많이 했고, \"너무 피곤했다\" 고 표현했습니다 가족이 \"그렇게 매일 하는 게 신기하다\" 고 말할 정도였습니다 ② 왜 한 달이고, 왜 21일인가 진행자는 \"원래 보통 한 달을 잡는다\" 고 했습니다. 한 달을 네 주로 놓고 보면 실제로 움직이는 구간이 정해집니다. 진행자의 설명 — \"첫 주가 어차피 주말이고, 그다음 3주가 액션하는 것\"이라 그 사이가 21일이 됩니다. 다만 진행자는 21일이라는 숫자 자체가 중요한 건 아니라고 선을 그었습니다. 중요한 것은 기간이 아니라 반복한 횟수 였습니다. \"횟수가 중요하다\" — 앞으로 이렇게 해야 하는구나 하고 인식하는 것 자체 가, 21일 동안 매일 여러 차례 했을 때 생긴다는 설명이었습니다. 실제로 하지 않고 머릿속으로 시뮬레이션을 돌리는 것으로도 습관은 형성된다고 덧붙였습니다. ③ 습관이 만들어지는 두 가지 방향 이 시간의 핵심입니다. 진행자는 습관이 생기는 경로를 두 가지로 나눠 놓고, 실제로 작동하는 쪽을 지목했습니다. 방향 a 사고를 바꿔서 습관이 되는 길 먼저 납득하고 생각이 바뀐 다음, 그래서 행동이 따라오는 순서입니다.","w4-practice-review":"한 주간의 ai 활용 회고 — 각자 이렇게 써 봤다 4주차 1교시의 절반은 회고 였습니다. 진행자가 던진 질문은 단순했습니다 — \"이번 주에 ai를 써 봤는데, 본인이 잘 활용해 봤다 하는 게 있을까요?\" 답은 말로만 오가지 않았습니다. 실제 결과물을 화면에 띄워 놓고 무엇을 어떻게 시켰는지, 무엇이 아쉬웠는지를 함께 봤습니다. 이 시간의 성격 도구 사용법이 아니라 \"내가 이번 주에 어디까지 갔는가\" 를 확인하는 자리였습니다. 진행자의 표현으로는 \"툴 사용보다 생각하는 방식에 가까운 세션\" 입니다. ① 봇을 손보고, 봇이 나를 돌아보게 하다 주리 님 3주차에 만든 봇을 자동화 쪽으로 밀어붙였다 3주차에 붙인 봇이 이번 주 사이에 많이 개선돼서 , 시킬 수 있는 자동화를 계속 늘렸다고 했습니다. 아티클 요약 — 읽을거리를 먼저 보내 주고, 요약과 함께 업무와 연결되는 지점 까지 짚어 줍니다 업무일지 — 예전에는 스킬을 써서 파일로 만들던 것을 봇 쪽으로 옮겼습니다 다음 날 아침의 피드백 — 그날의 작업 세션을 봇이 읽고, 다음 날 아침에 개선하면 좋을 점과 프롬프트를 이렇게 쓰면 좋겠다는 제안 을 보내 줍니다 마지막 항목이 특히 눈에 띕니다. 내가 일한 기록을 봇이 읽고, 다음 날 나에게 개선점을 돌려주는 구조입니다. 하위 에이전트가 쓰는 프롬프트를 훔쳐보다 배움이 온 곳은 조금 뜻밖이었습니다. 서브 에이전트나 병렬 에이전트를 시키면, 메인이 그 하위 에이전트들에게 어떤 프롬프트를 주는지 볼 수 있습니다. \"그게 진행자가 쓰는 거랑 거의 비슷해요. 길게 설명하고, 뭐가 필요한지 다 쓰고. 그런 것도 이 세션을 통해 배우면서 '아, 이렇게 쓰는구나' 했습니다.\" 1교시 · 프롬프트를 어디서 배웠는지에 대해 진행자가 여기에 배경을 덧붙였습니다. 1년쯤 전만 해도 에이전트를 여러 개 두고 쓰는 방식이 흔하지 않아서, ai가 스스로 프롬프트를 쓰는 과정이 그대로 보였다 고 합니다. 지금은 그 과정이 아래쪽에 감춰져 있어서 잘 보이지 않습니다. 그래서 한 번씩 열어 본다 — 감춰진 아래 단계로 들어가 보면 지금 무엇을 어떻게 시키고 있는지 가 나옵니다. 진행자는 개발팀과 일할 때도 \"이걸 계속 보는 것도 느는 방법\" 이라고 반복해서 말했다고 했습니다. ② 마크다운은 서식이 아니라 프롬프트 기법이다 하위 에이전트가 만들어 내는 문서를 보면 일정한 구조 가 있습니다. 진행자는 그것을 \"하이어라키 구조\" 라고 불렀습니다 — 제목이 있고, 순서가 있고, 끊어 주는 지점 이 있습니다. ai가 이해하기 좋은 방식으로 ai가 명령을 내리고 있는 것입니다. 참가자가 물었습니다 — \"샵샵이랑, 점점점이랑, 이렇게 끊는 거랑 무슨 차이예요?\" 답은 이렇게 정리됐습니다. 표기 무엇을 뜻하나 언제 쓰나 코드 블록 ``` 이 영역은 가공하지 않은 원본 데이터 라는 표시 스크립트·코드·로그를 통째","w4-concept-attitude":"태도 — 한계를 긋지 않고, 배려로 신뢰를 쌓는다 4주차 1교시의 후반부는 도구 이야기가 전혀 나오지 않는 시간 이었습니다. 진행자가 \"이것도 중요한 거예요, 태도적인 거\" 라며 꺼낸 이야기들입니다. 한 달 동안 ai를 배운 사람들에게 마지막 주에 왜 태도 이야기를 했는지 — 그 이유가 이 문서의 내용입니다. 한 줄 요약 ai를 잘 쓰는 것과 같이 일을 되게 만드는 것 은 다른 문제입니다. 한계를 긋지 않는 태도가 앞이고, 배려와 신뢰가 그 뒤를 받칩니다. 이 시간의 구조 이야기는 혼자 에서 함께 로 넘어갑니다 — ① 스스로 한계를 긋지 않기 → ② 되는 걸 봤으니 시도하기 → ③ 한 번 더 하기 → 그리고 팀 · 배려 · 신뢰 · 개방 으로 이어집니다. ① 자기 한계를 스스로 긋지 않는다 진행자가 가장 먼저 꺼낸 것이 이것이었습니다 — \"자기가 한계를 스스로 긋지 않는 게 중요합니다.\" 여기서 말하는 한계는 능력의 한계가 아닙니다. 해 보기도 전에 \"이건 안 될 거야\"라고 결론을 내려 버리는 것 입니다. 참가자가 스스로 예를 들었습니다. \"ai가 뭘 해 줄 수 있는데… 솔직히 그거 하는 데 차라리 내가 하는 게 더 빠르지. 이런 애초에 한계, 그런 건가요?\" 1교시 · 한계를 긋는다는 게 무슨 뜻인지 확인하며 진행자는 \"그런 것도 있고\" 라며 다른 예를 하나 더 들었습니다. 어떤 사안을 알아봐야 할 때 \"이건 내가 알 게 아니다\" 라고 선을 긋고 남에게 넘기는 경우입니다. 일차적으로 자기가 다 해 보면 알 수 있는 것 인데도 그렇게 한다는 것입니다. 왜 위험한가 — \"스스로 한계를 딱 끊어 놓고 나는 여기까지야 해 버리면, 그 뒤로 이어 가기가 쉽지 않습니다.\" 한 번 그은 선이 다음 시도의 출발선이 되기 때문입니다. 선을 넘어 만들어 낸 순간 평가가 바뀐다 진행자는 이것을 \"자기 자존을 낮추지 않는 것\" 이라고도 표현했습니다. 그리고 그 결과가 어떻게 돌아오는지를 이렇게 말했습니다. \"제안만 하지 않고 액션을 해서 만들어 낸 순간 , 이제 자기 평가가 하나씩 들어와요. 사람들이 '아, 저렇게까지 하는구나' 를 알게 되는 거예요.\" 1교시 · 한계를 긋지 않는다는 것의 결과 ② 되는 걸 봐야 시도한다 그렇다면 선을 긋지 않으려면 무엇이 필요한가. 진행자의 답은 명확했습니다 — 된다는 걸 봐야 합니다. \"원하면 만들 수 있다는 걸 알아야 이걸 할 수 있죠. 그래서 제가 일부러 보여 주는 거예요. 되는 걸 알아야 내가 시도를 해 보니까.\" 1교시 · 수업에서 결과물을 먼저 보여 주는 이유 이것이 이 스터디가 매번 결과물부터 보여 주는 방식 으로 진행된 이유입니다. 순서를 그림으로 옮기면 이렇게 됩니다. 진행자가 수업마다 결과물을 먼저 펼쳐 놓은 이유가 이 순환의 첫 칸에 있습니다. 이제는 검증할 수 있다 전문가가 아니어도 괜찮은 이유도 함께 짚었습니다. 내가 전문","w4-concept-irreplaceable":"ai가 대체하기 힘든 것 4주차의 제목이자 마지막 주제 입니다. 한 달 동안 ai로 무엇을 할 수 있는지 배운 자리에서, 마지막에 남은 질문은 반대 방향 이었습니다. 이 질문은 진행자가 먼저 꺼낸 것이 아니라 참가자가 스터디 중간에 먼저 물었던 것 이고, 마지막 주에 다시 열렸습니다. 한 줄 요약 시각·청각·후각·촉각은 이미 센서로 대체되고 있습니다. 그런데 \"쎄하다\"고 느끼는 감각만은 자리가 비어 있습니다. ① 참가자가 먼저 던진 질문 스터디 중반, 한 참가자가 진행자에게 물었습니다 — \"ai가 대체하기 힘든 게 좀 어떤 게 있을까요?\" 진행자는 그 질문을 받았을 때의 느낌을 이렇게 기억했습니다. \"그걸 물어보시길래, 아 그걸 또 고민하고 계시는구나. 마지막에 중요한 건데.\" 1교시 · 질문을 받았을 때 그때 진행자가 준 답은 짧았습니다 — 사람과 사람이 만나서 해야 하는 것들. 그리고 덧붙였습니다. \"업무는 업무대로 할 수 있는데, 대체하기 힘든 것들이 많으니까 그런 걸 이야기해 보자.\" 이 문서가 마지막 주 마지막 주제 가 된 배경입니다. 진행자의 마지막 장에는 세 단어가 남아 있었습니다 — 습관 · 대체 · 신뢰. 앞의 두 시간이 습관 과 신뢰 였다면, 남은 하나가 대체 였습니다. ② 참가자들이 꼽은 것 같은 질문을 다시 던지자 답이 이어졌습니다. 답 1 사람과 사람의 커뮤니케이션 만나서 해야 하는 일. 진행자가 처음 질문을 받았을 때 준 답이기도 합니다. 답 2 방향을 설정하는 것 무엇을 할지 정하는 일. 실행은 맡길 수 있어도 방향은 맡길 수 없습니다. 답 3 책임지는 것 결과에 대한 책임. 다만 이 항목에는 진행자가 단서를 붙였습니다. \"책임\"에 붙은 단서 진행자는 책임을 대체 불가능한 능력이라기보다 처음부터 사람의 몫 으로 봤습니다. \"책임지는 건 어차피 자기 역할 이라서요. 자기를 쓰는 사람 이 그건 책임져야지.\" 1교시 · 책임에 대해 즉 ai가 못 하는 것 이라기보다 애초에 넘길 수 없는 것 이라는 구분입니다. 그리고 진행자가 정말 어렵다고 본 것은 따로 있었습니다. \"근데 사람의 마음을 얻는 건 힘들죠. 사람이라는 게 감정 이 들어가고, 느껴지는 게 있잖아요.\" 1교시 · 정말 어려운 것 ③ 오감은 대체되고 있다 — 그런데 육감은 여기서 이 시간의 핵심 이야기가 나왔습니다. 진행자는 사람에게 오감이 있다고들 하지만 하나가 더 있다 고 봤습니다. \"저는 하나 더 있다고 생각하는 게 육감 이거든요. 쎄함 , 이런 거. 알아듣고 하는 것들.\" 1교시 · 육감에 대해 참가자도 바로 동의했습니다 — \"그게 제일 중요하지. 육감이 제일 중요해.\" 그리고 진행자가 왜 육감만 다른지 를 감각별로 짚었습니다. 진행자의 표현 그대로 — 시각·청각·후각·촉각은 \"다 되는데\", 육감은 \"맞아, 다른 것 같아\" 였습니다. 육감은 무엇인가 대화에서 나온 표현들을 모","w4-lecture1":"4주차 1교시 강의기록 2026년 8월 9일 오전에 진행된 ax 스터디 4주차 1교시 의 기록입니다. 녹음 1시간 15분 분량을 시간 순서대로 정리했습니다. 마지막 주차의 첫 교시 입니다. 주제별로 정리된 내용은 습관이 되는 3주 · 한 주간의 ai 활용 회고 · 태도 · ai가 대체하기 힘든 것 네 문서에 담았습니다. 1교시 한 줄 도구를 하나도 다루지 않은 교시. 한 달 동안 왜 그렇게 시켰는지를 회수하고, 사람에게 남는 것이 무엇인지로 마무리한 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭 까지만 표기하고 진행자 이름은 쓰지 않습니다. 이번 교시에는 사내 인사·조직에 관한 대화가 상당 부분 포함돼 있었습니다. 그런 구간은 내용을 옮기지 않고 자리만 표시 했습니다. ① 수업 전 — 도구와 환경 이야기 00:00 – 00:05 00:00 교안 제외 — 개인 기기·사내 사정에 관한 잡담 수업 시작 전 노트북 환경 설정과 사내 사정에 관한 대화 가 이어졌습니다. 스터디 내용과 무관하고 개인·조직에 대한 언급이 포함돼 있어 기록하지 않습니다. ② 세 원칙을 다시 묻다 00:05 – 00:07 00:05 \"1주차에 세 개를 꼭 지켜야 된다고 했죠?\" 마지막 주차라는 말과 함께 진행자가 첫 질문을 던졌습니다. 대답이 하나씩 나왔습니다. 첫 번째 — 내려놓는다. 진행자가 덧붙였습니다. \"내려놓고 일단 시키는 대로 한다 \" 세 번째 — 이해가 안 돼도 일단 따라 한다 두 번째 — 그 자리에서 아무도 떠올리지 못했습니다 두 번째가 무엇이었는지는 끝까지 언급되지 않았고 , 대화는 다음으로 넘어갔습니다. 00:06 \"생각 안 나면 잘 지키는 거 아닙니까?\" 기억나지 않는다는 말에 진행자가 웃으며 받았습니다. 참가자도 \"매일 그러거든요\" 라고 답했고, 진행자가 이어받았습니다 — \"맞아, 매일 하잖아. 매일 하니까.\" \"한 번도 빼먹은 날은 없어요.\" 매일 한다는 것이 실제로 어땠는지도 이어서 이야기했습니다. 진행자에게 클로드 코드는 업무 그 자체 여서 근무 시간에 하기가 어려웠고, 퇴근 후에 최대한 많이 했다고 했습니다. \"너무 피곤했다\" 는 말과 함께, 가족이 \"그렇게 매일 하는 게 신기하다\" 고 했다는 이야기도 나왔습니다. ③ 21일과 습관 00:07 – 00:09 00:07 왜 한 달이었나 진행자가 \"원래 보통 한 달을 잡는다\" 고 하며 21일 이라는 숫자를 꺼냈습니다. 한 달을 네 주로 놓으면 첫 주는 시작하는 주 이고, 그다음 3주가 실제로 액션하는 구간 이라 그 사이가 21일이 된다는 설명이었습니다. 참가자가 \"3주 정도 하니까?\" , \"익숙해지는 데 걸리는 시간이니까\" 라고 답을 시도했습니다. 00:08 날짜가 아니라 횟수 — 그리고 두 가지 방향 진행자는 21일이라는 ","w4-concept-decision-os":"의사결정 os — 레퍼런스를 판단 근거로 바꾸다 4주차 2교시는 진행자가 실제로 만들고 있는 것 을 화면에 띄우며 시작했습니다. 첫 문장이 이것이었습니다 — \"하반기 전략으로 가장 중요한 게, 우리만의 의사결정 os를 만드는 거예요.\" os는 운영체제입니다. 여기서는 의사결정을 해 줄 수 있는 시스템 이라는 뜻으로 썼습니다. 한 줄 요약 이미지를 모으면 참고 자료 지만, 왜 그렇게 만들었는지까지 데이터로 만들면 판단 근거가 됩니다. ① 문제는 \"전문가가 없는 영역\"이다 왜 그런 시스템이 필요한지부터 이야기가 시작됐습니다. 지금까지 해 온 분야가 아닌 새로운 분야로 제품을 넓혀야 하는 상황 이 문제였습니다. \"제조도 해야 하는데, 그럼 제조는 어떻게 설계 해야 할지가 필요하잖아요. 건설이랑 다르잖아요. 그걸 어떻게 개발할 거예요? 전문가도 없는데. \" 2교시 · 왜 의사결정 시스템이 필요한가 익숙한 해법은 그 분야 전문가를 데려오는 것 입니다. 이 시간에 나온 접근은 달랐습니다 — 잘 만들어 놓은 것들이 이미 세상에 있으니, 그것을 판단 근거로 삼을 수 있는 형태로 바꿔 두자 는 것입니다. ② 참고 자료와 판단 근거의 차이 진행자가 화면에 띄운 것은 서비스 화면 아카이브 였습니다. 국내외 서비스의 화면과 기획이 방대하게 모여 있는 곳들입니다. 그리고 물었습니다 — \"이런 걸 다 가지고 있다는 게 어떤 의미일까요?\" 참가자의 답은 자연스러웠습니다 — \"레퍼런스 참고?\" 진행자가 바로 선을 그었습니다. \"근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요.\" 2교시 · 이미지의 한계 이미지만 있을 때 참고 자료에서 멈춘다 ai가 판단을 하지 못합니다. 형식에 맞는 카테고리를 찾아 주는 정도 가 전부입니다. 결국 사람이 눈으로 보고 골라야 합니다. 이유까지 있을 때 의사결정 근거가 된다 왜 이 구조 인지, 왜 이 레이아웃 인지, 무엇을 강조했는지가 함께 있으면 — 전문성이 없어도 판단할 수 있습니다. 진행자의 설명은 구체적이었습니다. ai가 이미지를 하나하나 인식해서 \"이 사람이 이 구조를 왜 가지고 있고, 레이아웃을 왜 이렇게 짰는지\" 를 데이터로 함께 들고 있으면, 무언가를 만들 때 마주치는 의사결정 사항들 에 대해 근거를 가지고 결정할 수 있게 됩니다. 나아가 그 레퍼런스를 근거로 화면 구조까지 뽑아낼 수 있습니다. ③ 수집이 곧 일이다 말은 간단하지만 가져오는 일 자체가 큰 작업 이라는 점을 진행자가 강조했습니다. 접근 — 토큰을 받아 api로 가져오는 방법이 있고, 막혀 있으면 페이지에 하나하나 접근해 브라우저에서 추출 합니다 정리 — 끌어온 것을 그대로 두면 쓸 수 없으니 정리합니다. 함께 붙어 있는 설명 내용까지 가져옵니다 해석 — 이미지를 읽는 모델로 무엇이 어떻게 구성돼 있는지 다시 정리합니다 위키화 — 결과를 노트 도구에 위키 구조로 쌓","w4-concept-adoption":"ax는 왜 잘 퍼지지 않는가 2교시 후반은 솔직한 이야기 였습니다. 결과물을 만들어 보여 줬는데도 왜 조직은 잘 움직이지 않는가 에 대한 것입니다. 스터디의 마지막 주제가 성공 사례가 아니라 확산의 어려움 이었다는 점이 이 시간의 성격을 말해 줍니다. 한 줄 요약 보여 주는 것만으로는 부족합니다. 결핍이 없으면 움직이지 않고, 직접 해 보지 않으면 남의 일로 남습니다. 이 시간에 나온 진단 잘 되는 곳일수록 바꿀 이유가 없고( 결핍 ), 배우려면 개인이 비용과 시간을 내야 하고( 허들 ), 옆에서 보이지 않으면 관심도 생기지 않습니다( 거리 ). 그리고 그 모두를 감싸는 것이 문화 입니다. ① 결핍이 없으면 움직이지 않는다 진행자가 지난주에 다른 곳에서 실제로 보여 줬던 이야기가 나왔습니다. \"이거 된다, 이렇게 했다\" 고 시연했고 반응도 좋았습니다 — \"대박이다\" , \"하고 싶다\" . 그런데 거기서 멈췄습니다. 참가자가 한 단어로 정리했습니다. \" 결핍이 없어서 그렇죠.\" 2교시 · 왜 안 움직이는가 진행자도 동의하며 덧붙였습니다 — \"이미 이렇게 해도 잘 들어오는 게 있으니까.\" 바꿔야 할 이유가 지금은 없다는 뜻입니다. 실제로 나올 법한 생각을 진행자가 대신 말해 봤습니다. 바꾸지 않을 이유는 얼마든지 있습니다 · 지금 장사가 잘 되고 있다 · 고객들도 아직 ai를 그렇게 믿지 않는다 · 그런데 높은 연봉을 주고 전문 인력을 꾸려야 하나? 잘 되고 있다는 사실 자체가 가장 강력한 관성입니다. ② 개인이 감당해야 하는 허들 더 현실적인 장벽은 배우는 비용을 누가 내는가 였습니다. 진행자가 자기 팀 이야기로 예를 들었습니다. \"우리 팀조차도 하자. 근데 대신에 네가 구독해. 그러면 한 달에 그거 십몇만 원은 내 돈 주고, 그렇게 해서 내 주말 시간 빼서 배워야 돼. 여기서부터 허들 이란 말이에요.\" 2교시 · 배우는 비용은 누가 내는가 그 사이에 조직의 반응은 \"좋네, 우와 좋다\" 에서 멈춥니다. 좋다는 평가와 그것을 가능하게 하는 지원은 별개입니다. 실제로 든 비용 — 2교시에 시연한 작업을 위해 진행자는 도구를 개인적으로 구독했고, 사용량 한도에 걸려 추가 결제까지 했습니다. 회사 자원으로 가져온 것이 아니라는 점을 여러 차례 확인했습니다. 참가자의 반응이 이 상황을 요약합니다 — \"그런 걸 별로 인정해 주지도 않으면서, 결과물만 보고 '오, 괜찮네' 하는 게 좀 그렇죠.\" ③ 직접 찔려 보지 않으면 모른다 이 시간에서 가장 선명한 비유가 여기서 나왔습니다. \"보여 주지만 결국 직접 느껴 보지는 않은 거예요. 진짜 칼로 이렇게 찔러 보진 않았으니까. 칼이 날카롭다는 건 아는데. \" 2교시 · 아는 것과 겪는 것의 차이 참가자의 진단도 같았습니다 — \"직접 체험해 보고 직접 하려는 의지가 없는 이상 ax화는 안 되잖아요. 그게 첫 번째인 것 같고.\" 1교시에","w4-lecture2":"4주차 2교시 강의기록 2026년 8월 9일 오전에 이어 진행된 ax 스터디 4주차 2교시 의 기록입니다. 녹음 50분 분량을 시간 순서대로 정리했습니다. 오전 일정의 마지막 교시 이고, 오후에 3교시 실습 이 이어집니다. 주제별로 정리된 내용은 의사결정 os 와 ax는 왜 잘 퍼지지 않는가 두 문서에 담았습니다. 2교시 한 줄 실제로 만들고 있는 것을 화면에 띄워 놓고, \"이게 된다는 걸 봐야 사고가 열린다\" 는 것을 직접 보여 준 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 회사명·서비스명·개인 이름은 쓰지 않고 일반 표현으로 바꿔 옮겼습니다. 2교시는 절반 가까이가 사내 경영·인사에 관한 대화 였습니다. 그런 구간은 내용을 옮기지 않고 자리만 표시 했습니다. ① 의사결정 os를 만든다 00:00 – 00:02 00:00 첫 문장 쉬는 시간이 끝나고 진행자가 화면을 띄우며 바로 본론을 꺼냈습니다. \"하반기 전략으로 가장 중요한 게, 이제 우리만의 의사결정 os를 만들 거예요. \" 참가자가 \"운영체제\" 라고 받자, 진행자가 뜻을 분명히 했습니다 — \"의사결정을 해 줄 수 있는 시스템을 만들 겁니다.\" 그리고 물었습니다. \"이게 어떤 의미로 들리세요?\" 00:01 문제는 \"전문가가 없는 영역\" 참가자가 회의 내용이 휘발되는 것 , 프로세스가 체계화되어 있지 않은 것 을 떠올렸지만 진행자는 \"그건 아니고\" 라며 실제 문제를 제시했습니다. \"제조도 해야 하는데, 그럼 제조는 어떻게 설계 해야 할지가 필요하잖아요. 건설이랑 다르잖아요. 그걸 어떻게 개발할 거예요? 전문가도 없는데. \" ② 레퍼런스를 판단 근거로 00:02 – 00:07 00:02 서비스 화면 아카이브를 열다 진행자가 화면을 공유했습니다. 국내외 서비스의 화면과 기획이 방대하게 모여 있는 아카이브 였습니다. 국내 서비스 레퍼런스가 거의 다 들어가 있고, 해외 쪽도 마찬가지라고 설명했습니다. 그리고 질문을 던졌습니다 — \"이런 걸 다 가지고 있다는 게 어떤 의미인가?\" , \"이걸 다 가지고 있으면 뭘 할 수 있을까요?\" 00:04 \"이미지만 가지고 있으면 참고밖에 안 된다\" 답으로 \"레퍼런스 참고?\" 가 나오자 진행자가 바로 선을 그었습니다. \"근데 이미지만 가지고 있으면 결국엔 레퍼런스 참고밖에 안 되거든요.\" 이어서 무엇이 달라지는지를 설명했습니다. ai가 이미지를 하나하나 인식해서 이 사람이 왜 이 구조를 가지고 있고 레이아웃을 왜 이렇게 짰는지 까지 데이터로 함께 들고 있으면, 서비스를 만들 때 마주치는 의사결정 사항 들에 대해 전문성이 없어도 판단할 수 있다 는 것입니다. 나아가 그 레퍼런스를 근거로 화면 구조까지 뽑아낼 수 있습니다. 00:05 가져오는 일 자체가 큰 작업이다 진행자는 수집이 간단하지 않다는 점을 강조했","w4-practice-deploy":"서버를 직접 올려 보다 — 인스턴스부터 도메인까지 4주차 3교시는 2시간 15분짜리 실습 이었습니다. 클라우드에 서버를 하나 만들고 , 접속하고, 만들어 둔 페이지를 배포하고 , 도메인을 사서 붙이고 , https까지 붙이는 것을 각자 자기 손으로 끝냈습니다. 3주차 마지막에 \"상황이 되면 서버를 올려 보자\" 고 예고했던 것이 여기서 실행됐습니다. 왜 이걸 하는가 개발을 시작한 사람이 가장 어려워하는 구간 입니다. 그 어려운 걸 한 번 해 보고 \"아, 되는구나\"를 느끼는 것 이 이 시간의 목적이었습니다. 이 시간의 성격 외우는 시간이 아니었습니다. 진행자도 \"나도 지금 외워서 하라고 하면 못한다, 하나씩 보고 쳐야 한다\" 고 말했습니다. 대신 모르는 화면 앞에서 ai에게 어떻게 맡기는지 를 보여 주는 시간이었습니다. 실제로 네트워크 설정·권한 설정·인증서 발급 대부분을 브라우저를 조작하는 ai에게 넘겼습니다. ① 두 가지 배포 방식 — 무엇을 고를 것인가 본격적인 실습에 앞서 간단히 올리는 방법 부터 비교했습니다. 만들어 둔 html을 링크로 만드는 데는 두 갈래가 있습니다. 방법 a 정적 호스팅 서비스에 올린다 깃 저장소를 연결하고 클릭 몇 번이면 링크가 생깁니다. 저장소를 공개로 두면 무료 입니다. 커밋할 때마다 자동으로 다시 배포됩니다. 방법 b 클라우드에 서버를 빌린다 컴퓨터 한 대를 통째로 빌리는 것 입니다. 뭐든 올릴 수 있지만 네트워크·보안·웹서버를 직접 설정 해야 합니다. 이날 실습한 쪽입니다. 진행자가 정리한 선택 기준은 이랬습니다. 프론트엔드만 간단히 올릴 거면 정적 호스팅으로 충분합니다 — \"몇 번 클릭으로\" 서버까지 함께 배포해야 하면 정적 호스팅은 맞지 않습니다 검색 노출을 원한다면 자기 도메인 이 필요합니다. 호스팅 업체의 기본 주소로는 거의 노출되지 않습니다 회의록처럼 보안이 필요한 문서 를 공개 저장소에 올리기 시작하면 곤란해집니다 — \"퍼블릭으로 올리는 건 보안을 좀 신경 써야 한다\" 서버란 무엇인가 — 진행자의 설명은 단순했습니다. \"맥미니 같은 컴퓨터 하나를 대여한다고 생각하면 됩니다.\" 성능에 따라 값이 다를 뿐입니다. 이 실습은 클라우드 무료 크레딧으로 진행했고, 가장 저렴한 사양이면 몇 달은 유지할 수 있다 고 했습니다. ② 서버 만들기 — 실제로 눌렀던 순서 참가자들이 화면을 함께 보며 따라간 순서입니다. 클라우드 콘솔에 처음 들어간 상태에서 시작합니다. 조직과 프로젝트를 만든다 이름은 중요하지 않습니다. 콘솔에 처음 들어가면 아무것도 없는 상태이므로 담을 그릇부터 만듭니다. 컴퓨트 · 인스턴스 서비스를 활성화한다 서비스 목록에서 컴퓨트 → 인스턴스 를 고르고 활성화합니다. 잠깐 기다리면 완료됩니다. os 이미지로 우분투를 고른다 목록을 내리면 ubuntu lts 가 있습니다. 가장 기본으로 많이 쓰는 것 이라 이걸 고릅","w4-concept-server":"서버와 도메인, 하나씩 뜯어보기 3교시 실습 중간중간 나온 용어와 개념 을 모았습니다. 참가자들이 그때그때 물어본 것 과 그 자리에서 나온 답을 그대로 정리한 것입니다. 외우려고 볼 문서가 아닙니다. 진행자도 \"기억은 안 해도 돼요\" , \"이해 안 해도 돼요, 어차피 해 달라면 해 주니까\" 라고 여러 번 말했습니다. 다만 무엇이 어디에 있는지 는 알아야 시킬 수 있습니다. 한 줄 요약 서버 한 대를 빌려서, 밖에서 들어올 ip를 붙이고, 들어올 문을 열고, 그 앞에 이름을 다는 것 — 이 세 가지가 전부입니다. ① 전체 그림 — 접속이 이루어지는 순서 내가 주소창에 이름을 쳤을 때 무슨 일이 일어나는지를 순서로 보면 이렇습니다. 서버를 만들었는데 접속이 안 되는 이유는 대개 플로팅 ip가 없거나 포트가 닫혀 있어서 입니다. ② 서버 쪽 용어 인스턴스 참가자가 \"인스턴스가 뭔데요?\" 라고 묻자 나온 답입니다. \"어떤 템플릿 을 하나 만들어 놨잖아요. 그걸 실제로 사용하는 걸로 만드는 것 을 인스턴스라고 해요.\" 3교시 · 인스턴스에 대해 다른 참가자가 디자인 도구의 컴포넌트와 그 복제본 에 빗대어 이해했고, 진행자가 맞다고 확인했습니다. 개발 전반에서 쓰이는 용어 라는 설명이 붙었습니다. 우분투 · 리눅스 서버에 올리는 운영체제 입니다. 여러 종류가 있고 우분투를 가장 기본으로 많이 씁니다 맥os도 뿌리는 같은 계열이라, 터미널 환경이 낯설지 않습니다 \"모든 서버는 터미널에서 시작한다\" — 지금 쓰는 그래픽 화면은 나중에 얹힌 것입니다 클라우드 · ec2 클라우드는 컴퓨터를 빌려주는 서비스 입니다. 서버 한 대를 올리는 것을 업체마다 다르게 부릅니다 — 어떤 곳에서는 그것을 ec2라고 합니다. 참가자의 정리가 명쾌했습니다 — 클라우드 는 컴퓨터를 빌려 쓰는 방식 이고, 어떤 서비스는 그 방식으로 장사하는 회사 이며, ec2 는 그 회사가 파는 여러 상품 중 \"컴퓨터 한 대 빌려주기\" 상품 입니다. 클라우드에는 이 밖에도 데이터베이스만 빌려주는 상품 등이 많습니다. vpc virtual private cloud — 가상 사설 클라우드의 약자입니다. 보안 관련 설정을 하는 영역 이라고 이해하면 됩니다. 플로팅 ip 서버를 만들면 내부용 ip 만 붙어 있습니다. 192.168.… 처럼 생긴 그것으로는 밖에서 접근할 수 없습니다. \"네트워크에서 외부로 접근할 수 있는 ip를 하나 열어 줘야 돼요. 그걸 플로팅 ip 라고 해서 하나 만들어 서버에 연결해 주면 됩니다.\" 3교시 · 플로팅 ip에 대해 플로팅 ip를 붙이면 도메인 없이 ip 숫자만으로도 사이트가 열립니다. 다만 그 상태로 외부에 전달하면 보기에 좋지 않다는 이야기가 이어졌습니다. → 태도의 차이 ③ 포트 — 집에 방이 여러 개 있는 것 참가자가 \"포트 번호가 뭐예요?\" 라고 묻자 나온 비유가 이 시간에서 가장","w4-concept-security":"서버 보안과 키 관리 3교시 실습 내내 보안 이야기가 계속 끼어들었습니다. 키를 만드는 순간, 포트를 여는 순간, 배포하는 순간마다 한 번씩 짚고 넘어갔습니다. 서버를 가진다는 것은 밖에서 들어올 수 있는 문을 갖는다 는 뜻이기 때문입니다. 한 줄 요약 서버는 대개 정교한 공격으로 뚫리지 않습니다. 열어 둔 문과 흘린 열쇠로 뚫립니다. ① 키 하나가 전부다 인스턴스를 만드는 도중 키페어 생성 단계에서 진행자가 실습을 멈추고 강조했습니다. \"이게 중요합니다. 이 키가 이 서버 들어오는 열쇠예요. \" 3교시 · 키페어를 만들며 화면에도 경고가 적혀 있었습니다 — \"분실 시 인스턴스에 접속할 수 없습니다.\" 진행자가 그 뒤를 이었습니다. \"이거 누구한테 털렸다? 저기 서버에 있는 키 털렸다? 다 털리는 거예요. 그래서 이 키는 절대 털리면 안 돼요. \" 3교시 · 키 관리에 대해 잃어버리면 내가 못 들어간다 키가 없으면 서버 주인도 접속할 수 없습니다. 다시 만들 수 없는 열쇠라고 생각해야 합니다. 유출되면 남이 들어온다 그 서버에 있는 것이 전부 열립니다. 반대로 말하면 — 키만 지키면 어지간해서는 뚫리지 않습니다. 실제로 이날 확인된 것 — 뒷부분에서 해킹 이야기가 나왔을 때 진행자가 말했습니다. \"우리 서버도 지금 있는 거 털려고 하면 키가 없으면 못 털거든요.\" 키 관리가 서버 보안의 대부분 이라는 뜻입니다. 키를 두는 자리와 권한 키는 ~/.ssh 폴더에 두는 것이 기본 규칙 입니다 파일 권한 설정 이 함께 필요합니다 — 너무 열려 있으면 접속 자체가 거부됩니다 이날도 \"권한이 0644라 ssh 키를 거부하는 상태입니다\" 라는 안내가 실제로 떴습니다 거부당하는 것이 불편해 보이지만, 권한이 열린 키를 그냥 쓰게 두지 않는다는 뜻 이라 오히려 안전장치입니다. ② 문을 여는 일에는 경고가 따라온다 네트워크 설정을 ai에게 맡겼을 때, 작업 도중 경고가 올라왔습니다. \"포트가 인터넷에 그대로 노출됩니다.\" 3교시 · 네트워크 설정 중 나온 안내 이날은 실습용 서버 였고 올릴 것도 공개용 문서였기 때문에 그대로 진행했습니다. 다만 이 장면은 그대로 기록해 둘 만합니다 — 도구는 위험을 알려 주고, 넘길지 말지는 사람이 정한다 는 구조가 여기서 그대로 드러났기 때문입니다. 실제 업무 서버라면 달라집니다 — 포트는 필요한 것만 열고, 열었으면 무엇이 열려 있는지 알고 있어야 합니다. 데이터베이스 포트처럼 바깥에 열릴 이유가 없는 문 을 습관적으로 여는 것이 사고의 시작입니다. 실제로 이날 지시문에도 \"db 같은 건 제외하고\" 라는 조건이 들어가 있었습니다. ③ 공개 저장소에 무엇을 올리는가 실습 초반, 간단히 배포하는 방법을 이야기하다가 나온 주의입니다. 공개 저장소를 쓰면 무료로 배포할 수 있지만 그 대가가 있습니다. \"회의록 이런 건 보안 문서일 수 있잖아요. 그런","w4-lecture3":"4주차 3교시 강의기록 2026년 8월 9일 오후에 진행된 ax 스터디 4주차 3교시 의 기록입니다. 녹음 2시간 15분 분량을 시간 순서대로 정리했습니다. 4주 과정에서 가장 긴 교시 이자, 유일한 전면 실습 교시입니다. 주제별로 정리된 내용은 서버를 직접 올려 보다 · 서버와 도메인, 하나씩 뜯어보기 · 서버 보안과 키 관리 세 문서에 담았습니다. 3교시 한 줄 3주차 마지막에 예고했던 \"서버 올려 보기\" 를 실제로 한 시간. 인스턴스 생성부터 도메인·https까지 각자 끝까지 갔습니다. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 회사명·서비스명·개인 이름은 일반 표현으로 바꿔 옮겼고, 참가자가 실제로 구매한 도메인 이름은 개인 정보가 섞여 있어 표기하지 않습니다. 실습 도구(클라우드 콘솔·도메인 등록 서비스·브라우저 확장 등)는 일반 명칭으로 적었습니다. ① 배포 방식 비교 00:00 – 00:10 00:00 도메인과 ip의 관계부터 교시는 도메인이 무엇인지 에서 시작했습니다. 도메인을 구입해 ip와 연동 해 두면, 그 도메인을 타고 ip로 접근할 수 있게 됩니다. 참가자가 자기 말로 바꿔 확인했습니다 — \"주소 뒤에는 사실 복잡한 숫자가 들어가 있는데, 하이퍼링크처럼 그냥 눌러서 들어가는 것과 비슷한 거네요.\" 00:01 간단히 올리는 길 — 정적 호스팅 만들어 둔 html이나 프로젝트를 깃 저장소와 연결하고 클릭 몇 번이면 링크가 생기는 서비스를 보여 줬습니다. 저장소를 공개로 두면 무료 입니다. 주소 앞부분은 내가 정할 수 있습니다 — 같은 이름이 없으면 커밋할 때마다 자동으로 다시 배포 됩니다 다만 검색 노출 을 원하면 자체 도메인이 필요합니다. 호스팅 업체의 기본 주소로는 거의 노출되지 않습니다 서버까지 함께 배포하려면 맞지 않습니다 — \"프론트엔드만 해 놓으려면 간단히 올릴 수 있다\" 보안 이야기도 함께 나왔습니다 — 회의록 같은 문서를 공개 저장소에 올리기 시작하면 곤란해집니다. \"생각보다 이 퍼블릭에 올리는 게 보안을 좀 신경 써야 돼요. \" 00:03 왜 굳이 서버를 올리는가 진행자가 이날의 목적을 밝혔습니다. 개발을 시작한 사람이 가장 어려워하는 구간 이 이 부분이라는 것입니다. \"제일 어려운 걸 한번 해 보는 거지. 그게 되는 걸 한번 경험해 보면, 아 그냥 되네 하는 수준 을 느껴 보면.\" 무료 크레딧으로 몇 달은 유지할 수 있다 는 계산도 덧붙였습니다. 그 안에 각자 배포하고 싶은 것 을 올려 보면 된다는 것이었습니다. 00:06 발표 자료를 웹으로 만든 예시 진행자가 예전에 만든 것을 하나 보여 줬습니다. 세션에서 찍은 슬라이드 사진 에 ai로 만든 음성 설명 을 붙여, 넘길 때마다 해당 설명이 나오도록 한 페이지였습니다. \"두 개를 합치면 영상이랑 똑같잖아요. ","w4-closing":"마무리 — 한 달을 돌아보며 4교시는 16분 이었습니다. 3교시에서 남은 검색 등록 이야기를 마저 정리하고, 한 달간의 소감 을 나누는 것으로 스터디가 끝났습니다. 진행자의 말로 시작합니다 — \"그러면 좀 마무리를 해 보겠습니다. 한 달 동안 다들 고생하셨는데, 좀 어떠셨는지 짤막한 소감을 얘기해 보는 시간을 가져 봅시다.\" 마지막 한 문장 참가자들이 공통으로 꼽은 것은 도구가 아니었습니다 — \"ai를 하나 배웠다가 아니라, 생각하는 방식이 바뀌었다.\" ① 참가자들의 소감 동현 님 매주 이야기했듯 쉽지는 않았다 고 먼저 말했습니다. 그리고 무엇이 남았는지를 이렇게 정리했습니다. \"꼭 ai뿐만 아니라 그냥 전체적으로 이런 업무 스타일 이라든가, 좀 미래에 대한 저의 방향성 이라든가, 여러 방면에서 인사이트를 느꼈던 것 같아요. 그냥 ai를 하나 배웠다 이게 아니라, 전체적인 하나의 터닝포인트 가 또 되지 않았나.\" 이어진 문장이 이 스터디의 목적과 맞닿습니다 — \"기존에 어떻게 해야 될지 막막했었는데 조금 방향이 보였다.\" 과제에 대한 평도 있었습니다. \"숙제들이나 그런 떡밥들이 되게 재밌었던 것 같아요. 아, 이렇게 해 보니까 이래서 하라고 했구나.\" → 그 떡밥이 회수되는 지점 주리 님 이미 팀에서 ai를 다뤄 온 입장에서, \"이건 이미 다 배운 내용 아니냐\" 는 질문을 주변에서 받기도 했다고 합니다. 그에 대한 답이 이랬습니다. \"그냥 ai 스터디만 한 게 아니라, 그 이전에 어떻게 생각하고 ai를 해야 하는가 가 솔직히 더 주된 내용이었잖아요. 그래서 그런 것들이 업무를 할 때도 그렇고, 앞으로의 마인드 같은 것도 많이 배우는 세션이었어요.\" 본인의 정리는 한 문장이었습니다 — \"배운 걸 또 배운다기보다는 약간 마인드셋 점검. 앞으로 어떻게 해야 하나.\" ② 진행자의 챌린지 — \"준비하지 않는 것\" 진행자가 이 스터디를 시작하며 스스로에게 건 과제 를 밝혔습니다. 참가자들이 맞혀 보라고 하자 나온 답이 의외였습니다. \"딱 한 가지 잡은 게 있어요 — 준비하지 않는 거. \" 4교시 · 진행자의 챌린지 원래 방식은 정반대였다고 합니다. 원래 하던 방식 일주일 전부터 다 짜 놓는다 커리큘럼을 미리 만들고, 교육 한 번에 리허설을 세 번 할 정도로 준비했습니다. 이번 방식 그날 아침에 준비한다 \"절대 전날까지 준비하지 않는다. 무조건 일어나서 그날부터 준비한다.\" 교안도 마찬가지였습니다. 이유는 대상이 매번 다르기 때문 이었습니다. \"결국에는 필요하신 분들이 필요한 게 다 다르잖아요. 그분들이 정말 필요한 것들을 찾아서 해 줘야 되는데, 커리큘럼 짜 놔야 소용도 없어요. 이 교육을 계속 돌려 쓸 게 아니면 별로 필요하지 않더라고요.\" 4교시 · 왜 준비하지 않았나 대신 매일 관찰했습니다 — 아무 생각 없이 온 것이 아니라, 참가자들의 행동을 보면서 \"이걸 좀 더 ","w4-lecture4":"4주차 4교시 강의기록 2026년 8월 9일 늦은 오후에 진행된 ax 스터디 4주차 4교시 의 기록입니다. 녹음 16분 분량으로, 4주 과정 전체의 마지막 교시 입니다. 주제별로 정리된 내용은 마무리 — 한 달을 돌아보며 에 담았습니다. 4교시 한 줄 3교시에서 남은 검색 등록 을 마저 정리하고, 한 달간의 소감을 나누며 스터디를 닫은 시간. 기록 원칙 전사에 실제로 있는 내용만 옮겼고, 구어를 정리체로 다듬되 발언의 순서와 뉘앙스는 그대로 두었습니다. 참가자는 스터디 내 호칭 까지만 표기하고 진행자 이름은 쓰지 않습니다. 이 교시에는 제외할 만한 구간이 거의 없었습니다. 소감을 나누는 자리였고, 사내 사정에 관한 언급도 짧게 지나갔습니다. ① 검색엔진에 등록하기 00:00 – 00:01 00:00 왜 따로 알려 줘야 하나 3교시 마지막에 걸어 둔 이야기를 이어받았습니다. 배포한 사이트가 검색되게 하려면 검색엔진이 알도록 해 줘야 합니다. \"모든 사이트를 새로 생긴 걸 다 뒤져서 할 수는 없잖아요. 그래서 검색엔진 쪽에 접근해서 웹사이트가 들어간 것에 대해 인증을 하는 게 있어요.\" 절차는 이렇게 정리됐습니다. 검색엔진 도구에 들어가 url을 입력 합니다 그러면 dns에 무언가를 넣어 달라 고 요구합니다 그것을 넣으면 내가 이 도메인의 소유자라는 것이 인증 됩니다 \" 그걸 넣는다는 것 자체가 내가 소유권이 있다는 거잖아요. 그런 걸 인증하기 위해서 그런 단계가 있거든요.\" 진행자는 이 부분을 직접 해 보라고 넘겼습니다 — \"방법은 알려 드렸으니까, 브라우저를 쓰든 코드를 쓰든 하시면 되실 거라.\" ② 한 달 소감 나누기 00:01 – 00:05 00:01 마무리를 열다 네트워크 설정까지 정리한 뒤 진행자가 마무리를 선언했습니다. \"그러면 좀 마무리를 해 보겠습니다. 한 달 동안 다들 고생하셨는데, 좀 어떠셨는지 짤막한 피드백이나 소감을 얘기해 보는 시간을 가져 봅시다.\" 00:02 동현 님의 소감 먼저 \"쉽지는 않았다\" 고 말한 뒤, 무엇이 남았는지를 정리했습니다. \"꼭 ai뿐만 아니라 전체적으로 이런 업무 스타일 이라든가, 미래에 대한 저의 방향성 이라든가, 여러 방면에서 인사이트를 느꼈던 것 같아요. 그냥 ai를 하나 배웠다 이게 아니라, 전체적인 하나의 터닝포인트 가 또 되지 않았나.\" 그리고 덧붙였습니다 — \"기존에 어떻게 해야 될지 막막했었는데 조금 방향이 보였다.\" 과제에 대한 평도 있었습니다. \"뭔가 숙제들이나 그런 떡밥들이 되게 재밌었던 것 같아요. 아, 이렇게 해 보니까 이래서 하라고 했구나. \" 00:04 주리 님의 소감 이미 팀에서 ai를 다뤄 온 입장이라 \"이건 이미 다 배운 내용 아니냐\" 는 질문을 주변에서 받기도 했다고 했습니다. 그에 대한 답이었습니다. \"그냥 ai 스터디만 한 게 아니라, 그 이전에 어떻게 생각하고 ai를 해야 하는가"}
