"실패한 장면을 자르지 않았다" — 서인수 강사의 AI 젯봇 시연을 듣고
작성자: 원샷(청강)
강의 요약
스터디장 서인수님이 26기 때 만든 "전격 제트 작전" 프로젝트가 화면 속 설명이 아니라 실제로 작동한다는 걸 라이브로 증명하는 자리였습니다.
"젯봇": 엔비디아 젯슨(5년 전 구형, GPU 약함) 기반 자율주행 로봇. 카메라 2개(라인 트래킹용 1개 + 객체 인식용 1개), 원래 GCP 서버가 담당하던 연산을 오늘 데모를 위해 로컬로 옮겨 왔습니다.
ESP32가 신호등에 내장돼 중앙 에이전트를 거치지 않고 독자적으로 LLM API를 호출할 수 있습니다 — "비가 오면 문 닫아줘" 같은 명령도 이 모듈 하나로 처리 가능.
라이브 데모: 휴대폰에 고양이 사진을 띄우고 "고양이 감지되면 파란불"이라고 명령. 첫 시도는 실패해 빨간불이 켜졌 고, 곧바로 재시도해서 성공했습니다. 이 실패 장면을 편집 없이 그대로 보여준 것 자체가 발표의 일부였습니다.
코덱스 API가 오픈라우터보다 체감상 느리고, 정확도도 "보편적으로 고양이라는 걸 인식한" 수준이지 정밀하지는 않다고 인수님 스스로 인정했습니다.
핵심 메시지: 비싼 장비 없이도 저가 하드웨어 + 외부 API 조합만으로 물리적 반응을 만들어낼 수 있다는 걸, 실패까지 포함해서 검증해 보여주는 것.
하려던 것
저는 로봇이나 하드웨어와는 거리가 먼 사람입니다. 그런데 이 발표를 신청한 이유는 딱 하나, "실패 장면을 그대로 보여준다"는 게 어떤 느낌인지 직접 보고 싶어서였습니다. 저는 결과물을 옵시디언에 저장할 때 늘 잘 정리된 최종본만 남기는 편이라, 실패했던 과정은 자연스럽게 사라졌습니다. 이 발표가 그 습관에 뭔가 말을 걸 것 같았습니다.
강의에서 인상 깊었던 것
"이 실패 장면을 편집 없이 그대로 노출한 것 자체가 발표의 일부였다"
처음 시도가 실패해서 빨간불이 켜진 순간, 인수님은 당황하지 않고 곧바로 재시도했습니다. 성공한 장면만 준비해서 보여줄 수도 있었을 텐데, 실패-재시도를 그대로 라이브로 노출한 게 오히려 "이게 진짜 작동한다"는 신뢰를 더 크게 만들었습니다.
"중앙 에이전트 없이도 각 장치가 스스로 판단해서 움직일 수 있다"
ESP32 하나가 신호등에 내장돼 헤르메스 같은 중앙 에이전트를 거치지 않고 자체적으로 LLM API를 호출한다는 점이 기술적으로 인 상 깊었습니다. 저는 제 작업 전체를 늘 "Claude Code를 열어야 뭐든 시작된다"는 전제로만 생각하고 있었는데, 이 구조는 그 전제 자체를 흔드는 이야기였습니다.
"헤르메스를 큰 맥미니나 비싼 거 안 써도, 작은 걸 골라서 외부 API가 있으면 이렇게 간편하게 만들 수 있다"
값비싼 장비가 아니라 저가 하드웨어와 외부 API 조합만으로도 충분하다는 실용적인 태도가 좋았습니다.
시행착오와 정정
이 강의 노트에는 화자나 파일명 오류는 없었습니다. 대신, 이 노트의 So What을 다시 검토하다가 제가 직접 겪은 시행착오가 하나 나왔습니다 — 어떤 의미에서는 이 강의가 말하는 "실패를 편집 없이 보여주기"를 저도 그대로 겪은 셈입니다.
믿었던 것: 처음 이 강의 노트의 So What을 쓸 때, "제가 최근에 만든 구글 Apps Script 자동화(플라우드 전사록을 구글드라이브로 자동으로 옮겨주는 장치)가 Claude Code를 켜지 않아도 스스로 도는 첫 번째 자동화"라고 적었습니다. ESP32가 중앙 에이전트 없이 스스로 판단한다는 강의 내용과 정확히 대응된다고 생각했기 때문입니다.
어떻게 틀렸다는 걸 알았는지: 그런데 실제로 구글드라이브의 해당 폴더를 직접 열어봤더니, 6월 16일에 "연결이 되나" 테스트로 만든 파일 딱 하나뿐이었고, 그 이후로 실제로 쓰인 적이 한 번도 없었습니다. 지금 진짜로 매번 작동하고 있는 건 이메일을 직접 열어서 읽는 방식이었고, 이건 결국 Claude Code를 켜야만 도는 방식이었습니다.
어떻게 고쳤는지: "이미 있다"고 믿었던 걸 So What에서 정정하고, 강의 노 트에도 정정 표시를 남겼습니다. 그리고 이 미완성 자동화를 마저 고칠지, 아니면 지금 잘 작동하는 방식을 그대로 쓸지 직접 판단해서 — 지금 방식이 이미 충분하다고 보고 더 손대지 않기로 결정했습니다.
나에게 적용해 보니
잘 하고 있는 것 — 결과물은 늘 옵시디언에 빠짐없이 저장해왔습니다. 이번 강의를 계기로 사례게시글에 "시행착오와 정정" 항목을 정식으로 넣기 시작했으니, 앞으로는 실패 과정도 자연스럽게 남을 것 같습니다.
고쳐야 할 것 — "이미 만들어뒀으니까 되고 있겠지"라고 확인 없이 믿는 습관이 있었습니다. Apps Script 사례에서 정확히 이 습관 때문에 틀린 판단을 했습니다.
오늘 바로 한 것 — 구글드라이브 폴더를 직접 열어 실제 상태를 확인했고, 강의 노트의 잘못된 전제를 정정했고, "사례게시글-강의" 스킬에 이번 발표의 핵심 원칙(실패-재시도 장면을 편집 없이 포함하기)을 정식 항목으로 반영했습니다.
오늘 배운 것
실패를 편집 없이 보여주는 것 자체가 신뢰를 만든다 — 성공한 장면만 골라 보여주는 것보다 훨씬 설득력이 있다
중앙 에이전트 없이도 각 장치가 스스로 판단하게 설계할 수 있다 — 모든 게 하나의 통로(제 경우 Claude Code)를 반드시 거칠 필요는 없다
비싼 장비 없이도 저가 하드웨어 + 외부 API 조합으로 충분히 증명 가능하다 — 완벽한 환경을 갖출 때까지 기다릴 필요가 없다
"이미 되어있다"고 믿지 말고 직접 열어서 확인해야 한다 — 제 Apps Script 시행착오가 정확히 이 교훈이었다
속도·정확도의 한계도 숨기지 않고 인정하는 게 오히려 신뢰를 만든다 — 인수님이 "정밀하지는 않다"고 스스로 인정한 태도
앞으로 해야 할 일
Apps Script 파이프라인은 폐기로 결정했으니 다시 되살리자고 먼저 꺼내지 않기
다음 사례게시글부터는 "잘 된 것"만 나열하지 말고 실패-재시도 장면을 최소 하나는 편집 없이 포함하기
"이미 되어 있다"고 가정하고 넘어가는 습관이 다른 자동화(다른 launchd 작업들)에도 숨어있지 않은지 한 번씩 점검해보기
마치며
"헤르메스를 큰 맥미니나 비싼 거 안 써도, 작은 걸 골라서 외부 API가 있으면 이렇게 간편하게 스마트홈 AI를 만들 수 있다."
이 발표를 준비하며 강사님이 로봇을 완벽하게 다듬어서 보여줄 수도 있었을 텐데, 그러지 않았습니다. 실패한 순간을 그대로 두고, 바로 옆에서 다시 시도해서 성공하는 과정까지 함께 보여줬습니다. 저도 이번 강의 노트를 정리하면서 제가 틀렸던 부분을 지우지 않고 그대로 남겨봤습니다. 완벽한 결과물보다, 틀렸다는 걸 알아채고 고치는 과정 자체가 더 남길 가치가 있다는 걸 이번에 배웠습니다.
관련
원본 강의노트: OT20260725-AI젯봇시연코덱스API-서인수
