39단계제2편 결과물 발표: 주소 하나로 시작한다

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 60분 · 난이도 ★★☆ 실무 · 화면 확인 2026.09.27

이 단계를 마치면

• 발표에서 배포된 주소를 청중의 휴대폰으로 열게 하고, 중요한 동작을 실제로 보여 줄 수 있습니다.
• 동료의 결과물을 네 가지 기준으로 평가하고, 만든 쪽과 검토한 쪽이 누구였는지 물을 수 있습니다.
• 도구를 넘길 때 주소와 함께 저장소, CLAUDE.md와 AGENTS.md, 핵심 프롬프트, 교차 검토 기록을 묶어 넘길 수 있습니다.

발표 첫 화면에 슬라이드 대신 주소 하나가 떠 있습니다. 발표자가 말합니다. "지금 휴대폰을 꺼내 이 주소를 열어 보세요." 제2편의 발표는 이렇게 시작합니다.

이 단계로 제2편을 마무리합니다. 발표할 것은 20단계에서 동그라미를 친 바로 그 도구입니다. 제3부에서 Claude Code로 만들어 배포했고, 제4부에서 Codex로 기능을 넓히고 두 에이전트가 서로 검토하게 했습니다. 이제 그 도구에는 GitHub에 쌓인 기록과 남이 여는 주소, CLAUDE.md와 AGENTS.md라는 규칙 파일 두 개, 그리고 리뷰 지적마다 판단을 남긴 PR이 있습니다.

발표의 중심은 주소다. 과정을 설명하기 전에 결과부터 엽니다. 슬라이드에 화면 캡처를 붙이는 발표는 이 발표에 맞지 않습니다. 캡처는 내 노트북에서 된 것을 보여 줄 뿐, 남이 여는 주소에서도 된다는 것까지 보여 주지 못합니다. 발표를 시작하면 먼저 주소를 화면에 띄우고, 같은 주소를 청중에게 보내 각자 휴대폰으로 열게 합니다. 그 순간 청중 모두가 첫 사용자가 됩니다.

제2편에서 정말 보여 줘야 할 결과물은 판단의 과정입니다. 그래서 마지막 "한 사건"을 빼먹지 않습니다. 되돌린 커밋, 배포에서 막혀 로그를 읽은 일, 완료 보고를 믿지 않고 휴대폰에서 다시 확인한 일, Codex 리뷰의 지적을 화면에서 재현해 받아들이거나 반박한 일, 두 에이전트의 의견이 갈려 사람이 정한 일 같은 이야기입니다. 제4부 과제로 만든 교차 검토 비교표가 있다면 그대로 꺼내 보여 주면 됩니다. "누가 만들었고, 누가 봤고, 사람은 무엇을 판단했는가"에 답하는 데 이보다 좋은 자료는 없습니다.

평가 기준. 듣는 사람은 평가자가 됩니다. 과정 전체의 합격 기준을 그대로 씁니다. 다른 사람이 이 결과물을 받아 다음 주에 그대로 쓸 수 있습니까? 이 질문을 쪼개면 네 가지가 됩니다.

발표 전 준비. 발표 전날 30단계의 확인 절차를 한 번 더 밟습니다. 배포 목록의 마지막 배포가 준비됨인지, 본 주소가 최신인지, 제4부에서 합친 PR이 본 주소에 들어가 있는지, 휴대폰 데이터로도 열리는지 봅니다. 발표장 와이파이에서 주소가 열리는지도 미리 확인해 둡시다. 발표 도중 주소가 안 열리면 당황하지 말고 28단계의 순서를 그 자리에서 밟습니다. 브랜치, 캐시, 로그. 그 장면 자체가 좋은 발표 재료가 됩니다.

넘기기. 발표가 끝나면 도구를 실제로 팀에 넘깁니다. 이때 주소만 달랑 보내서는 안 됩니다. 저장소 주소, CLAUDE.md와 AGENTS.md, 이 도구를 만들 때 쓴 핵심 프롬프트, 그리고 교차 검토 기록을 함께 보냅니다. 그래야 받은 사람이 같은 방식으로 고쳐 가며 쓸 수 있습니다. 규칙 파일이 두 개 있으니 받은 사람이 Claude Code를 쓰든 Codex를 쓰든 같은 규칙에서 출발합니다. 저장소가 개인 계정에 있다면, 사내 도구로 계속 쓸 경우 회사 조직으로 옮기는 일정도 함께 정합니다.

왜 넘기기까지가 발표일까요. 만든 사람만 고칠 수 있는 도구는 만든 사람이 휴가를 가거나 부서를 옮기면 멈춥니다. 20단계 첫머리에서 본 엑셀 파일의 운명 그대로입니다. 주소만 받은 사람은 쓸 수는 있어도 고칠 수는 없습니다. 저장소와 규칙 파일, 핵심 프롬프트를 함께 받은 사람은 Claude Code나 Codex를 켜고 "규칙 파일을 읽고 이 문구를 바꿔 줘"라고 말하는 데서 바로 시작할 수 있습니다. 제2편에서 코드를 가르치지 않고 규칙을 정하고 기록하는 법을 익힌 까닭이 여기서 드러납니다.

흔한 오해와 실제

발표를 준비하는 수강생들이 자주 빠지는 생각이 있습니다.

"기능이 많아야 좋은 발표다." 청중은 기능 목록을 기억하지 못합니다. 자기 휴대폰에서 직접 눌러 본 한 동작을 기억합니다. 기능이 다섯 개라면 가장 중요한 하나만 보여 주고, 나머지는 "이런 것도 있다"며 짧게 넘어갑니다.

"평가에서 흠이 나오면 발표가 실패한 것이다." 이 시간은 애초에 흠을 찾으려고 모인 시간입니다. 발표자 혼자서는 자기 도구를 처음 쓰는 사람의 눈으로 볼 수 없습니다. 청중 여럿이 동시에 열어 보는 이 순간이 도구가 받을 수 있는 가장 값싼 검사입니다. 흠이 나오면 받아 적고, 어디를 고칠지까지 말하면 됩니다.

"발표가 끝나면 과제도 끝이다." 제2편의 합격 기준은 동료가 다음 주에 그대로 쓰는가입니다. 발표 당일에는 그 질문의 절반만 답할 수 있습니다. 나머지 절반은 넘기고 한 주가 지나야 보입니다.

청중과 도구에 따라 바꾸는 법

발표 순서는 같아도 청중에 따라 무게를 달리 둡니다. 청중이 같은 과정의 수강생이라면 "한 사건"에 시간을 가장 많이 씁니다. 다들 비슷한 막힘을 겪었기 때문에, 어떻게 판단했는지가 가장 쓸모 있는 이야기입니다. 청중이 임원이나 부서장이라면 "한 문장"과 "안전한가"에 무게를 둡니다. 누가 쓰는지, 무엇이 들어가지 않는지, 누가 만들고 누가 검토했는지, 틀리면 어떻게 되돌리는지를 먼저 말합니다. 청중이 실제로 쓸 팀원이라면 "한 동작"을 모두가 직접 해 보는 데 시간을 쓰고, 막히는 사람 옆으로 가서 어디서 멈췄는지 봅니다. 그 시간이 곧 사용자 시험입니다.

도구에 따라서도 달라집니다. 로그인이 필요하거나 회사망 안에서만 열리게 해 둔 도구라면 청중이 각자 여는 순서를 그대로 밟을 수 없습니다. 이럴 때 억지로 공개하지는 않습니다. 발표용 연습 계정이나 가공한 자료를 담은 미리보기를 따로 준비하되, 그것이 본 주소와 같은 코드에서 나온 것인지 배포 목록에서 확인해 둡니다. 청중이 열지 못한 부분은 오히려 "안전한가" 기준에서 점수가 됩니다. 왜 막아 두었는지 한 문장으로 설명하면 됩니다.

현장 장면

윤 과장의 발표는 주소 하나로 시작했습니다. 화면에 주소를 띄우고 같은 주소를 수강생 단톡방에 올렸습니다. "영업 사원이 외근을 마친 직후 휴대폰으로 방문 업종·지역, 만난 사람의 직함, 다음 약속을 적는 방문 일지입니다." 수강생들이 각자 휴대폰으로 주소를 열었습니다. 윤 과장은 기록 한 건을 적고, 브라우저를 닫았다 다시 열어 기록이 그대로 남아 있는 것을 보여 줬습니다. 청중도 똑같이 해 봤습니다. 이어서 도구가 거쳐 온 길을 한 문장으로 덧붙였습니다. "제3부에서 Claude Code로 만들었고, 제4부에서 Codex로 기능을 넓히면서 두 에이전트가 서로 검토했습니다." "한 사건"으로는 30단계의 일을 꺼냈습니다. 완료 보고를 믿고 단톡방에 올렸다가 다음 날 기록이 사라졌던 일, 되돌려도 통과하던 테스트 이야기였습니다.

평가 시간에 한 수강생이 손을 들었습니다. "내려받은 표를 열어 보니 작성자 이름이 전부 나오는데요?" 화면에는 성만 보이게 해 두었지만, 나중에 붙인 내려받기 기능에서 그 규칙이 빠진 것입니다. CLAUDE.md와 AGENTS.md의 공통 규칙에는 "화면에 사람 이름은 성만 보여 준다"라고 적혀 있었습니다. "화면에"라는 세 글자 때문에 내려받는 표는 규칙 밖에 놓여 있었습니다. 제4부에서 내려받는 표에 항목을 늘린 PR은 Codex 리뷰와 Claude Code의 검토를 모두 거쳤지만, 어느 쪽도 이 점을 지적하지 않았습니다. 둘 다 같은 규칙 문장을 기준으로 봤으니, 규칙에 빠진 곳은 두 에이전트 모두 보지 못한 것입니다. 교차 검토가 잡지 못한 흠을 청중이 잡은 셈이었습니다.

윤 과장은 그 자리에서 두 규칙 파일의 문장을 똑같이 "화면과 내려받는 파일 모두 사람 이름은 성만 쓴다"로 고치겠다고 적었습니다. 꼭 지켜져야 하는 규칙이니, 29단계에서 배운 훅으로 검사하게 하는 일도 다음 주 과제로 적었습니다. 발표가 끝난 뒤 윤 과장은 팀장에게 주소, 저장소 주소, CLAUDE.md와 AGENTS.md, 핵심 프롬프트 세 개, 교차 검토 비교표를 한 메시지로 보냈습니다. 팀장은 저장소를 회사 조직으로 옮기는 일을 IT팀에 요청하겠다고 답했습니다.

진짜 시험은 한 주 뒤였습니다. 윤 과장은 먼저 두 파일의 규칙 문장을 고치고, 내려받는 표의 작성자 항목에 성만 나오는지 Claude Code에게 확인 순서를 받아 직접 내려받아 열어 봤습니다. 성만 나왔습니다. 그다음 인수인계를 받은 같은 팀 김 대리에게 부탁했습니다. "제 도움 없이 입력 항목 이름 하나만 바꿔서 올려 봐 주세요." 김 대리는 영업본부에서 받은 ChatGPT 계정만 있었기 때문에 Codex를 켰습니다. AGENTS.md를 읽은 Codex에게 넘겨받은 핵심 프롬프트 하나를 고쳐 넣어 "다음 약속" 항목을 "다음 방문 예정일"로 바꾸게 했습니다. 커밋하고 푸시한 뒤에는 자기 휴대폰으로 같은 주소를 열어 바뀐 것을 확인했습니다. 무엇보다 반가운 것은 그동안 김 대리가 윤 과장에게 한 번도 묻지 않았다는 점이었습니다.

흠이 하나 남았습니다. 김 대리가 바꾼 항목 이름 때문에 예전 기록의 "다음 약속" 값이 표에서 비어 있었습니다. 30단계에서 겪은 저장 위치 이름 문제와 같은 종류였습니다. 김 대리는 그 커밋을 되돌리지 않고, 화면에 보이는 이름만 바꾸고 저장하는 이름은 그대로 두도록 다시 고치게 했습니다. 윤 과장은 이 일을 CLAUDE.md와 AGENTS.md의 "하지 말 것" 항목에 같은 문장으로 적었습니다. "저장하는 이름은 바꾸지 않는다. 바꿔야 하면 예전 기록을 옮기는 방법을 먼저 계획으로 받는다." 훅으로 이름 규칙을 검사하는 일과 저장소를 회사 조직으로 옮기는 일은 아직 남아 있습니다. 둘 다 날짜를 붙여 과제 목록에 올려 두었습니다.

따라 하기

1. 발표 전날 배포 목록의 마지막 배포가 준비됨인지 보고, 주소를 휴대폰 데이터로 열어 중요한 동작을 끝까지 해 봅니다. 성공 기준: 휴대폰에서 동작이 끝까지 되고, 본 주소가 최신입니다.
2. 도구를 "누가, 언제, 무엇을 하려고 쓰는 도구"인지 한 문장으로 적습니다. 성공 기준: 소리 내어 읽었을 때 한 호흡에 끝납니다.
3. 발표에서 주소를 띄우고 청중에게 보내 각자 열게 한 뒤, 중요한 동작을 함께 해 봅니다. 성공 기준: 청중 대부분이 도움 없이 열고 동작까지 해 봅니다.
4. 되돌리거나 걸렸던 일 하나를 이야기합니다. 교차 검토에서 두 에이전트의 의견이 갈렸던 일이나 Codex 리뷰의 지적을 재현해 본 일도 좋습니다. 성공 기준: 무엇이 잘못됐고 어떻게 알아챘고 어떻게 고쳤는지가 들어 있습니다.
5. 동료의 결과물을 네 가지 기준으로 평가하고, 지적받은 것을 다음 주 과제 목록에 적습니다. 성공 기준: 기준마다 예·아니오와 근거가 있습니다.
6. 아래 프롬프트로 인수인계 자료를 만들어 도구를 넘깁니다. Claude Code와 Codex 어느 쪽에 넣어도 됩니다. Codex에 넣을 때는 CLAUDE.md를 AGENTS.md로 바꿔 읽으면 됩니다. 성공 기준: 받은 사람이 주소, 저장소, CLAUDE.md와 AGENTS.md, 핵심 프롬프트, 교차 검토 기록을 한 번에 받았습니다.
7. (선택) 넘기고 한 주 뒤, 받은 사람에게 Claude Code든 Codex든 편한 도구로 도움 없이 문구 하나를 고쳐 푸시하게 하고 옆에서 지켜보기만 합니다. 막힌 곳이 있으면 그 내용을 두 규칙 파일이나 인수인계 자료에 보탭니다. 성공 기준: 받은 사람이 만든 사람에게 묻지 않고 고친 내용을 자기 휴대폰의 같은 주소에서 확인했습니다.

복사해 쓰는 프롬프트

이 도구를 동료 [이름·역할]에게 넘기려고 해. 넘기기 전에 인수인계 자료를 만들어 줘.
- 이 도구가 무엇이고 누가 언제 쓰는지 세 줄
- 배포된 주소와 저장소 주소를 적을 곳
- 가장 중요한 동작과 그것을 휴대폰에서 확인하는 순서
- 자주 고칠 만한 것과 고치는 방법을 Claude Code에게 요청하는 문장 예시
- CLAUDE.md에 빠진 규칙이 있다면 추가 제안(고치지는 말고 제안만)
- 공개 주소와 내려받는 파일에 있으면 안 될 정보가 들어 있는지 점검한 결과
확인하지 못한 항목은 확인하지 못했다고 적어 줘.

막히면 이렇게

스스로 점검

• ☐ 캡처 대신 배포된 주소로 발표를 시작했고, 청중이 자기 휴대폰으로 열어 중요한 동작을 해 봤습니까?
• ☐ "한 사건"에서 누가 만들고 누가 검토했으며 사람이 무엇을 판단했는지 이야기했습니까?
• ☐ 도구를 넘길 때 주소, 저장소, CLAUDE.md와 AGENTS.md, 핵심 프롬프트, 교차 검토 기록을 함께 넘겼습니까?

기억할 것

• 발표 기준은 하나입니다. 동료가 다음 주에 그대로 쓸 수 있습니까?
• 발표는 주소를 여는 데서 시작하고, 넘길 때는 주소와 함께 저장소, 두 규칙 파일, 핵심 프롬프트, 교차 검토 기록을 넘깁니다.
• 교차 검토는 규칙 문장이 빠뜨린 곳까지 잡아 주지 않습니다. 청중의 눈이 그다음 검토입니다.