AI@GSB: Ben Tossell, Founder of Ben''s Bites

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Ben’s Bites 창업자 벤 토셀은 AI 에이전트에 자신의 맥락과 취향을 전달하고 작은 제작을 반복하며, 비개발자도 아이디어를 구현하는 방법을 보여준다.

📌 핵심 요점

1. 에이전트 활용의 출발점은 맥락과 행동 규칙이다. 토셀은 AGENTS.md와 별도 참고 파일에 선호·업무 정보·기억을 나누어 담고, 질문을 곧바로 수정 요청으로 해석하지 않도록 지침을 둔다. 처음에는 에이전트 하나로 시작하고 필요할 때 역할을 분리한다.
2. 원하는 결과는 여러 시안을 비교하면서 발견한다. 구별되는 세 가지 프로토타입을 요청하고, 수정이 빗나가면 음성·스크린샷·영상·주석으로 대상을 구체화한다. AI의 제안에는 선택 이유와 대안의 장단점을 묻는다.
3. 작은 실험과 기능 포기가 제작을 지속하게 한다. 개인 사이트·게임·데이터 시각화처럼 관심 있는 작업을 빠르게 만들고, 효용이 낮은 기능이나 맞지 않는 방향은 버린다. 모든 실험을 출시할 필요는 없으며, 제작 과정에서 얻은 학습도 성과로 본다.
4. 반복되는 제작 방식은 지침과 스킬로 축적한다. 프로토타이핑·URL 배포 같은 작업을 재사용하고, 북마크에서 얻은 질문을 다시 제작으로 연결한다. 토셀이 설명하는 소프트웨어 팩토리는 개별 결과물을 넘어 이런 제작 시스템 자체를 구성하는 접근이다.
5. 개인 에이전트의 확산에는 통제권과 실제 효용이 중요하다. 토셀은 기억과 입력 맥락을 직접 확인하고 수정하기를 원한다. 활용 실패를 사용자 역량 탓으로 돌리기보다, 공급자가 유용한 사용법과 기대에 맞는 경험을 제공해야 한다고 본다.

🧩 배경과 문제 정의

• 벤 토셀은 직접 코딩하지 않으면서 AI로 아이디어를 구현하고 공개한다. 기술적 숙련의 경계가 유동적으로 바뀌는 상황에서, 작은 실험과 놀이를 통해 자신에게 맞는 제작 방식을 찾는다.
• 에이전트가 원하는 결과를 내려면 사용자 선호, 작업 맥락, 도구와 지침이 필요하다. 과도한 설명이나 질문을 변경 요청으로 오해하는 행동도 지침으로 조정할 대상이다.
• 처음부터 원하는 결과를 정확히 정의하기는 어렵다. 여러 시안을 직접 비교하고, 구체적인 피드백을 주고, 불필요한 기능을 버리면서 공개 가능한 결과로 좁혀 간다.

🕒 시간순 섹션별 상세정리

1. 챗봇과 에이전트를 가르는 도구 사용과 반복 판단

• 챗봇은 모델과 대화를 주고받는 형태이고, 에이전트는 웹 검색이나 Gmail·캘린더 연결 같은 도구를 사용한다. 토셀의 구분에 따르면 오늘날 익숙한 AI 도구 상당수가 이미 에이전트 방식으로 작동한다 [02:31]
• 에이전트는 주어진 맥락과 사용 가능한 도구를 확인하고, 작업을 끝낼 정보가 충분한지 판단한다. 부족하면 도구 사용과 정보 확인을 반복한다 [02:56]

2. 에이전트 지침으로 대화 방식과 행동 범위를 조정하기

• 에이전트 지침은 작업 맥락을 파악할 때 먼저 확인하는 정보다. ChatGPT·Claude에서는 설정에 입력하고, Codex·Claude Code 같은 도구에서는 로컬 파일로 관리한다 [03:49]
• 장황한 답변을 줄이기 위해 “ADHD가 있는 사람에게 말하듯 이야기하라”는 지침을 사용한다. 가입 버튼을 더 눈에 띄게 해야 하는지 물었을 때 곧바로 수정하는 일을 막으려고, 질문은 변경 요청이 아니라 답변 요청이라는 규칙도 둔다 [04:55]

3. 개인 에이전트의 역할과 기억을 파일로 구성하기

• 개인 에이전트는 하나가 모든 일을 맡는 방식과 업무별로 나누는 방식으로 구성할 수 있다. 토셀의 ‘Bites’는 하나의 에이전트를 쓰며, Bites 폴더의 AGENTS.md에 기본 지침을 둔다 [06:08]
• 업무별로 나누면 비서실장·마케팅·재무 등의 폴더마다 직무, 성격, 대화 방식을 지정할 수 있다. 기억처럼 보이는 정보도 별도의 memory.md 같은 파일에 기록되어 다시 읽히는 구조다 [06:50]

4. 정확한 수정은 타이핑하고 복잡한 맥락은 말로 전달하기

• 새 작업의 첫 요청이나 지침의 특정 문장 수정처럼 원하는 내용이 명확하면 타이핑한다. 아이디어 탐색이나 여러 버그에 대한 피드백처럼 맥락이 많으면 음성을 텍스트로 바꿔 전달한다 [09:07]
• 말하다가 생각을 바꾸거나 앞선 내용을 되짚는 과정도 에이전트에 유용한 맥락이 될 수 있다. 생각 사이의 연결과 아직 정리되지 않은 문제를 추론할 단서가 생기기 때문이다 [09:50]

5. 작업 성격에 따라 앱과 모델을 선택하기

• 토셀은 업무상 여러 앱과 모델을 자주 바꾸지만, 그 방식을 모두에게 권하지는 않는다. bb는 Codex·ChatGPT·Claude 등 여러 에이전트를 대화형 인터페이스에서 사용할 수 있는 앱이다 [10:18]
• 투자한 회사인 Factory의 Droid에서는 오픈소스·Claude·OpenAI 모델을 사용할 수 있다. 비개발자인 자신에게는 모델을 잘 활용하도록 구성된 도구가 구현 방식에 대한 부담을 덜어 준다 [10:45]

6. 스킬도 지침이며 입력 내용을 이해해야 결과를 통제할 수 있다

• 스킬은 특정 작업을 위한 지침 파일이다. 글쓰기 스킬의 예로는 작성자의 실제 목소리 보존, 최소한의 수정, 불필요한 문장 제거 같은 규칙이 있다 [11:47]
• 설명 수준과 말투는 여러 지침을 시험하며 자신에게 맞춰야 한다. 에이전트 구성도 처음에는 하나로 시작하고, 특정 업무를 분리할 필요가 생기면 나누는 방식을 권한다 [12:48]

7. 탐색·제작·수정·공개를 반복하며 작업 방식을 축적하기

• 다른 사람의 결과물을 참고하고 조합한 뒤 만들고, 다듬고, 공개한다. 여러 작업에서 반복해서 요구한 설명 방식이나 시각화 요청은 기본 에이전트 지침으로 올릴 후보가 된다 [14:06]
• 과거 기기 사이트에서는 OpenAI의 Astra로 생성한 기기 이미지 50개에, 시대별 웹 버튼을 보여 주는 다른 사이트의 시각적 표현과 상호작용을 결합했다 [14:58]

8. 공개 데이터 탐색을 지방정부 지출 지도로 확장하기

• Riley Waltz의 샌프란시스코 주차 단속 관련 사이트에서 영감을 받아, 영국에서 수집할 수 있는 실시간 공개 데이터를 에이전트에 물었다. 식당·계획 허가 신청 등 여러 후보 가운데 지방정부 지출 데이터를 선택했다 [16:33]
• 영국 지방정부는 월별 실제 지출을 공개해야 하지만, 토셀은 실제 이행에는 여지를 남겼다. 이 데이터를 Apple Maps 기반 탐색 사이트로 만들었고, 화면에는 최근 12개월간 Amazon 지출이 850만 파운드로 나타났다 [17:03]

9. 질문으로 목표를 좁히고 AI의 제안에 반론 제기하기

• 목표가 불분명할 때는 Matt Pocock의 ‘Grill Me’처럼 질문을 하나씩 받아 서로의 이해를 맞추는 방식을 활용한다. 다만 약 36개 질문까지 이어진 경험이 부담스러워, 자신에게 필요한 수준으로 지침을 단순화했다 [18:11]
• AI가 사용자에게 지나치게 동조할 수 있으므로 “왜 이 방식인가”, “다른 방법은 왜 아닌가”, “장단점과 절충점은 무엇인가”를 계속 묻는다. 기술적 기초 질문도 상대의 평가를 걱정하지 않고 던질 수 있다 [18:58]

10. 서로 다른 시안으로 원하는 결과를 발견하기

• 원하는 결과는 실제로 보고 클릭해 봐야 분명해지는 경우가 많다. 맞지 않는 프로젝트는 버리고, 기기 사이트에서도 세 가지 시안 가운데 C를 선택해 발전시켰다 [19:57]
• 여러 버전을 늘 원하기 때문에, 목업과 프로토타입에는 구별되는 정적 시안을 여러 개 만들라는 규칙을 기본 지침에 넣었다. 매번 세 가지 결과를 비교하면서 방향을 선택한다 [20:17]

11. 수정이 빗나가면 화면과 주석으로 맥락 보강하기

• 짧은 텍스트 수정 요청을 에이전트가 이해하지 못하면 스크린샷과 음성 설명을 추가한다. 그래도 부족하면 화면을 가리키며 설명한 녹화 영상을 주어 대상과 문제를 구체화한다 [22:06]
• 간격처럼 말로 표현하기 어려운 문제는 스크린샷을 tldraw 같은 화이트보드 앱에 넣고 직접 표시한다. 주석은 무엇이 잘못됐고 어느 위치를 고쳐야 하는지 전달하는 추가 맥락이 된다 [22:32]

12. 창의적 변형과 여러 에이전트의 결과를 비교하기

• 순위표의 여러 시안이 마음에 들지 않아 시상대 방향을 고른 뒤 더 창의적인 결과를 요구했다. 그 과정에서 나온 경주 형태는 직접 보기 전에는 떠올리지 못했던 선택지였다 [23:15]
• 같은 프롬프트를 여러 에이전트에 보내 서로 다른 결과를 비교하고, 마음에 드는 방향을 골라 발전시키기도 한다 [23:36]

13. 구조는 시각화하고 효용이 낮은 기능은 버리기

• 지방정부 지출 지도처럼 기술적으로 복잡한 결과물은 데이터가 어디서 오고 어디에 저장되는지 시각화해 이해한다. 각 지방정부 웹사이트에서 에이전트가 데이터를 수집해 데이터베이스로 모으는 흐름을 그림으로 확인했다 [24:20]
• 기기 사이트에 기기별 소리를 넣으려 했지만, 사용량 한도에 가까워진 시점에 약 19개 소리를 찾은 뒤 중단했다. 특별한 사용자를 위해 만드는 프로젝트도 아닌 만큼 끝없이 완성도를 높일 필요는 없다고 판단했다 [24:56]

14. 프로토타입을 URL로 공개해 여러 기기에서 확인하기

• 로컬 컴퓨터에서 실행하는 웹사이트를 공유하려면 파일을 서버에 호스팅하고 URL로 제공하는 배포 과정이 필요하다 [25:53]
• 토셀은 자신이 투자한 무료 도구 here.now의 스킬을 이용한다. 프로토타입을 만들면 이 스킬로 공개하라는 지침을 넣어 항상 접근 가능한 URL을 확보한다 [26:14]

15. 반복 갱신은 자동화하고 실행 환경을 구분하기

• 정기적으로 정보가 갱신되어야 한다면 자동화를 요청한다. 자신의 이메일은 노트북을 사용하는 동안 매시간 지침과 프롬프트를 실행해 라벨을 붙이고 보관하며, 답장은 작성하지 않는다 [27:02]
• 집의 Mac Mini나 가상 머신·가상 서버를 실행 환경으로 사용할 수 있다. ChatGPT·Claude 등의 내장 클라우드 자동화 기능을 이용하면 노트북을 닫은 뒤에도 작업을 계속 실행할 수 있다 [27:29]

16. 개인 사이트 개편에 탐색과 반복 수정 적용하기

• 기존 개인 사이트는 터미널처럼 생긴 에이전트 형태였지만, 다른 사람들의 운영체제 같은 개인 사이트를 보고 새로 만들기로 했다. 새 방향은 에이전트 앱 형태의 사이트였다 [28:40]
• 처음 받은 세 버전은 테마만 달라서 지침을 수정했다. 작은 글씨를 제거하고 요소를 옮기도록 화면에 주석을 달며 결과를 다듬었다 [29:05]

17. 기능 확장이 끝없는 제작으로 이어질 위험 인식하기

• 다음 날에는 에이전트 앱 형태의 사이트라는 아이디어 전체가 마음에 들지 않았다. 실제 에이전트와 여러 숨은 기능을 넣으려는 욕심이 사이트의 복잡성을 크게 늘리고 있었다 [29:52]
• 반려견 캐릭터 같은 요소와 각종 설정을 계속 확장하면 수많은 시간과 몇 주를 쓰고도 끝내지 못할 것이라고 판단했다 [29:59]

18. 간단한 스케치로 사이트를 다시 만들고 배포 설정을 위임한다

• 개인 사이트의 구성을 캔버스에 간단히 그린 뒤, 기존 사이트를 폐기하고 스케치에 맞춰 다시 만들도록 에이전트에 요청했다. 완성한 사이트는 몇 주간 사용하며 공개했다. [30:28]
• 도메인과 here-now 스킬을 이용한 게시 환경을 연결하는 과정에서 문제가 생기자, 에이전트가 Chrome을 조작해 설정을 처리하도록 했다. Vercel에 있는 도메인의 연결 작업은 약 20분 뒤 끝났다. [31:04]

19. 관심 있는 사람과 작업을 모아 자신만의 취향을 만든다

• 학습의 기준은 관심 있는 사람·프로젝트·표현 방식을 모은 ‘취향 라이브러리’다. 시각적인 UI 상호작용, 재미있는 소규모 제작물, 실시간 데이터와 데이터 탐색이 반복적으로 끌리는 주제다. [34:16]
• 개발자들이 무엇을 하는지 이해하고 자신의 관심사에 적용한 뒤, 이를 독자에게 풀어 주는 ‘기술 번역자’ 역할을 지향한다. 다른 사람의 제작물을 저장하고 자신만의 변형을 만드는 방식도 여기에 포함된다. [34:51]

20. 북마크의 변화에서 학습 주제를 찾고 제작 시스템으로 확장한다

• 직접 만든 도구로 Twitter 북마크를 모아 용어와 관심사의 변화를 살핀다. 에이전트가 반복 실행하며 토큰을 사용하는 ‘Ralph loops’에 대한 관심은 줄고, 개발자들 사이에서 ‘software factories’라는 표현이 늘어나는 흐름을 포착했다. [36:16]
• 그가 이해하는 소프트웨어 팩토리는 결과물 하나를 만드는 일을 넘어, 제작 시스템 자체를 구축하는 방식이다. 강의 페이지라면 컴포넌트 제작법, 자신의 문체, 음성 메모에서 제작 사례와 수업의 핵심 내용을 추출하는 방법 등을 지침으로 구성해 에이전트가 계속 개선하도록 한다. [37:03]

21. 반복되는 취향과 제작 경험을 에이전트 지침에 반영한다

• 계속 끌리는 작업을 살피면 앞으로 만들 것의 방향도 드러난다. 개인 홈페이지에 쌓이는 간단하고 상호작용적인 하위 페이지들이 그에게는 그런 방향이며, 작은 단일 목적 사이트를 더 만들 생각이다. [38:09]
• 기존의 ‘여러 목업을 만들라’는 지침은 테마만 조금씩 다른 결과를 냈다. Linear 출신 디자이너의 강의에서 얻은 프로토타이핑 스킬을 지침에 반영한 뒤에는 시안의 품질이 좋아졌다. [38:55]

22. 개인의 작은 불편과 놀이도 도구 제작의 출발점이 된다

• Kindle로 읽고 싶은 책이 전자책으로 나오지 않자, 구매한 책의 마지막 장을 넘기는 모습을 촬영해 에이전트에 전달했다. 이를 페이지 넘김이나 무한 스크롤로 읽을 수 있는 사이트로 만들었다. [40:00]
• 아이들과 비행기를 타기 전에는 공룡 달리기 형태의 게임을 만들었다. 동물을 바꾸거나 파티 모자를 씌우는 기능을 넣었고, 아이들이 잠시 조용히 지내는 데 도움이 됐다. [40:24]

23. 기술 용어와 개인 데이터를 시각적으로 탐색한다

• 에이전트가 사용하는 기술 용어를 이해하기 위해 AI 이미지와 관련 단어를 결합한 사이트를 만들었다. 디자인 용어와 테마를 탐색하는 유사한 실험도 진행했다. [41:48]
• 생활비·육아·자동차·쇼핑 등의 지출을 커피 잔으로 환산해 보여주는 시각화를 만들었다. 일반적인 대시보드와 다른 방식으로 데이터를 경험하려는 시도다. [42:16]

24. 정교한 사례를 재현하며 표현 방식과 제작 과정을 익힌다

• The Pudding의 시각화 사례는 픽셀 단위의 배치뿐 아니라 애니메이션과 움직임까지 재현하고, 결과를 점검하도록 에이전트에 요청했다. 이후 데이터셋을 바꿔 미국인 160명의 하루 활동이 시간에 따라 이동하는 모습을 시각화했다. 개인적인 관심과 학습을 위한 실험이라는 설명이다. [43:34]
• 강연의 단계별 설명과 개별 제작 사례는 stanford.bensbites.com에서 무료로 해석할 수 있다. 여러 작업을 섞고 변형하며 자신이 좋아하는 방향을 찾는 과정 자체가 제작 역량을 쌓는 방법이다. [44:17]

25. 아이디어에 걸린 부담을 낮추고 작은 실행을 반복한다

• 아이디어가 쌓이고 자신이 실행의 병목이 되는 문제를 완전히 해결하지는 못했다. 대신 처음부터 미래의 회사가 될 아이디어에 매달리기보다 빠르게 만들 수 있는 작은 작업부터 시작하도록 권한다. [45:54]
• 프로그래밍을 9개월 배워 만든 서비스에는 감정적으로 깊이 투자하게 되지만, 두 시간 만에 만든 서비스는 반응이 없으면 버리고 다음 것을 시도하기 쉽다. 아이디어의 무게를 줄여 실행과 검증을 반복하는 것이 핵심이다. [46:43]

26. 데이터 수집에는 기존 도구·API·브라우저 조작을 조합한다

• Twitter 수집에는 플랫폼의 제한이 강화되기 전에 확보한 도구를 계속 사용한다. 현재는 새로 이용할 수 없는 도구지만 자신에게는 작동하며, 실제 사용자처럼 Twitter를 이용하는 방식이라고 보여준다. [48:08]
• 북마크와 DM 등을 찾는 Twitter MCP나 여러 API도 선택지로 든다. Twitter MCP의 비용은 매우 저렴하다고 생각하지만, LinkedIn 관련 작업은 직접 하지 않는다. [48:39]

27. 팔리지 않던 제작물에서 제작법을 가르치는 사업이 나왔다

• Product Hunt에서 일하던 시절에는 Webflow·Zapier·Airtable을 조합해 구인 게시판과 디렉터리 등을 만들었다. 약 50개를 출시했지만 아무도 돈을 내지 않았고, 대신 비개발자가 어떻게 만들었는지 묻는 사람이 계속 생겼다. [50:07]
• 자신의 아이디어를 구현하는 화면을 녹화하고, 완성된 서비스 대신 튜토리얼 이용권을 판매했다. 이것이 노코드 교육 사이트 Makerpad로 이어졌다. [50:26]

28. 공통 스킬을 로컬에 두고 여러 에이전트에서 사용한다

• 스킬과 에이전트 지침은 로컬의 공통 폴더에 전역 설치해 여러 에이전트가 읽도록 한다. 주로 쓰는 것은 서너 개이며, 프로토타이핑과 URL 배포 스킬의 비중이 크다. [51:57]
• 사용하는 스킬은 다른 에이전트로 옮기기 복잡한 종류가 아니다. Claude에 설치한 스킬을 다른 환경에서도 쓰고 싶으면, 그 에이전트에 기존 스킬을 읽을 수 있도록 설정해 달라고 요청한다. [52:22]

29. 개인 실험과 유료 서비스의 위험을 구분하고 모델로 점검한다

• 현재 작업 대부분은 사람들이 비용을 내고 의존하는 프로덕션 소프트웨어를 목표로 하지 않는다. 그런 서비스를 만든다면 보안과 신뢰성을 더 진지하게 다뤄야 한다고 보며, 강의 사이트에는 인증·로그인·결제를 넣을 계획이다. [52:58]
• 시스템을 어느 정도 이해하면서, 새 모델이 나올 때마다 사이트의 허점이나 인증 우회·데이터베이스 침입 가능성을 검토하도록 하는 접근을 취한다. Cursor의 ‘Thermonuclear Code Quality Review’라는 이름의 스킬도 점검 수단으로 언급한다. [53:36]

30. 개인 에이전트의 기억을 직접 확인하고 수정할 통제권을 원한다

• 영국에서는 Muse와 Dots를 사용할 수 없어 직접 경험하지 못했다. 다른 개인 에이전트 제품은 시험했지만, 에이전트가 기억하는 내용과 맥락을 통제하기 어렵다는 점에 불만이 있다. [54:27]
• 에이전트가 몇 주 전의 아이디어를 현재의 확정된 계획처럼 반복해서 다루면, 해당 내용을 맥락에서 제거할 수 있어야 한다. Instinct에는 자신에 대한 기억과 에이전트 지침 파일을 변경될 때마다 Google Drive에 동기화해 직접 확인하고 수정할 수 있도록 요청했다. [55:23]

31. 활용 실패를 사용자 역량 탓으로 돌리면 확산을 막는다

• AI 연구소가 원하는 결과를 얻지 못한 사용자에게 ‘스킬 문제’라고 반응하는 태도를 비판한다. 다른 사람이 모델에서 유용한 결과를 얻는 방법이 있다면, 공급자가 그 방법을 사용자에게 제시해야 한다는 입장이다. [58:09]
• 제품 담당자가 실제 이용자의 관점에서 충분히 생각하는지는 의문으로 남는다. 단순히 다른 요청을 해 보라고 요구하는 방식으로 사용자가 제품의 가치를 발견할 수 있을지는 불확실하다. [58:35]

32. 파일 기반 개인 에이전트와 대중용 인터페이스가 함께 발전할 수 있다

• 자신은 행동 방식과 사업·가족·여행별 참고 파일을 지정한 지침으로 이미 개인 에이전트를 구성한다. Dots의 전화·문자 같은 인터페이스는 매력적이지만, 당일 전화 시연은 작동하지 않았다고 덧붙인다. [59:21]
• Codex나 자신이 사용하는 다른 앱에 개인 폴더를 연결하는 방식은 맥락을 직접 통제할 수 있다는 장점이 있다. 다만 이는 자신이 기술적 세부에 깊이 들어가 있기 때문일 수 있으며, 대부분의 사람은 Grokbot·Instinct·Muse 같은 제품을 자신에게 맞게 활용할 것으로 예상한다. [59:47]

33. 새 모델의 사용 여유와 제작 유행의 반복

• Opus 5.5와 6.1 같은 새 모델은 이용 가능한 가격대에서 다시 사용량이 사실상 무제한처럼 느껴진다. 이전에도 이런 체감이 생겼다가 사라진 적이 있어, 비슷한 변화가 반복될 것으로 본다. [1:00:13]
• 새 모델이 나올 때마다 3D 세계나 게임 제작이 유행한다. 이런 실험이 개인이 가져다 쓸 수 있는 흥미로운 결과물로 발전하기를 기대하면서도, 소셜미디어의 반응을 얻기 위한 제작 역시 유효한 동기가 될 수 있다고 본다. [1:00:42]

34. 이메일 정리에서 시작하는 작은 생산성 자동화

• 생산성 개선의 출발점은 자신을 귀찮게 하는 일, 더 쉽게 하거나 즐겁게 하고 싶은 일, 다시는 하고 싶지 않은 일을 찾는 것이다. 토셀에게 이메일은 다른 사람이 자신의 할 일을 떠넘기는 것처럼 느껴지며, 필요한 것은 받은편지함의 정리다. [1:01:53]
• 이메일에 라벨을 붙이고 보관 처리하며, 자신이 발행한 것이 아닌 Substack 이메일은 보관하도록 규칙을 정한다. 원하는 동작을 설명하고 자동화를 설정하는 데 20분 정도를 쓰는 식으로 작은 일 하나를 맡기면, 다음으로 자동화할 일도 떠올릴 수 있다. [1:02:30]

35. 초보자의 첫 결과물로 적합한 개인 사이트

• 개인 사이트는 자신에 관한 정보를 담는 단순한 정적 사이트이므로 처음 만들기 쉽고 자유롭게 바꿀 수 있다. 에이전트와 함께 다른 사람의 사례를 참고하면서 마스코트처럼 작은 재미를 더할 여지도 있다. [1:03:56]
• 자기소개를 입력하거나 LinkedIn에서 정보를 가져와 기본 사이트를 만든 뒤, 레이아웃을 바꾸거나 다른 표현을 시도하면서 실험을 이어갈 수 있다. [1:04:10]

36. 제작을 놀이로 삼으며 맥락과 스킬의 한계 배우기

• 토셀에게 제작은 일보다 놀이에 가깝다. 떠오른 아이디어를 구현하고 탐색하며, 공개하지 않는 결과물도 제작 과정을 시험하고 에이전트가 무엇을 하는지 이해하는 학습 기회가 된다. [1:04:46]
• 제작 중인 강의 플랫폼에서는 새 세션을 시작할 때 에이전트가 많은 파일을 읽는다. 필요한 맥락을 얻고 있다는 점 때문에 크게 건드리기는 조심스럽지만, 읽어야 할 파일이 이렇게 많아야 하는지와 에이전트가 잘 작업하도록 프로젝트를 구성하는 방법을 더 이해할 필요가 있다고 본다. [1:05:25]

🧾 결론

• 비개발자의 제작 역량에는 목표를 좁히고 결과를 비교하며 피드백을 전달하는 능력이 포함된다. 토셀의 사례는 이 과정을 작은 실험으로 익히는 방법을 보여준다.
• 취향과 반복되는 요구를 짧고 이해 가능한 지침으로 남기면 다음 작업에 재사용할 수 있다. 설치한 스킬의 수보다 실제 입력 내용을 이해하는 것이 중요하다는 입장이다.
• 학습용 실험과 유료 서비스는 요구되는 검증 수준이 다르다. 토셀도 사용자가 비용을 내고 의존하는 서비스라면 보안과 신뢰성을 더 진지하게 다뤄야 한다고 구분한다.

📈 투자·시사 포인트

• 에이전트 제품을 평가할 때 모델 성능과 함께 맥락 관리, 기억 수정, 도구 연결, 실행 환경을 살펴볼 필요가 있다. 토셀의 활용 사례에서는 이 요소들이 실제 작업 방식에 영향을 준다.
• 사용자가 첫 효용을 경험하도록 돕는 제품 설계와 교육이 확산의 관찰 지점이다. 이메일 라벨 정리 같은 작은 작업에서 출발해 다음 자동화로 이어지는 경로가 제시된다.
• Makerpad 사례는 제작물에 대한 직접 수요와 제작법을 배우려는 수요가 다를 수 있음을 보여준다. 팔리지 않던 결과물에서 튜토리얼 사업이 나온 경험이며, 다른 사례의 수익성을 보장하지는 않는다.
• 처리량과 비용도 함께 확인해야 한다. 토셀은 지방정부 지출 지도에 약 90억 토큰을 썼다고 회고하며, 모델 가격 하락과 한도 확대는 전망으로 제시한다. 이 강연만으로 특정 기업의 투자 가치를 판단하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• 지방정부 지출 지도 제작에 사용했다는 약 90억 토큰과 활동 페이지의 연간 880억 토큰은 회고·화면 수치다. 집계 범위, 실제 결제 비용, 재시도 포함 여부는 제시되지 않는다.
• 지도에 표시된 최근 12개월 Amazon 지출 850만 파운드는 시연 당시 수치다. 지방정부별 공개 이행, 데이터 누락, 집계 기준과 최신성은 별도로 확인해야 한다.
• 앱·모델 선호와 제작 성과는 토셀의 개인적 경험이다. Factory와 here.now에는 투자 관계가 있다고 밝혔으며, 도구 소개를 독립적인 성능 비교로 해석하기는 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복해서 귀찮은 일 하나나 단순한 개인 사이트를 첫 과제로 정하고, 이번 작업에서 확인할 결과와 중단할 조건을 적는다.
• 에이전트 하나에 대화 방식·질문과 수정 요청의 구분·작업 범위를 담은 기본 지침을 제공하고, 세부 맥락은 별도 파일로 나눈다.
• 테마만 다른 결과를 피하도록 구조와 상호작용이 구별되는 시안 세 개를 요청하고, 선택한 이유와 버릴 요소를 기록한다.
• 수정이 빗나가면 화면에 직접 표시하거나 음성 설명을 추가하고, AI에 대안과 절충점을 설명하도록 요청한다.

❓ 열린 질문

• 일반 사용자는 에이전트의 기억과 지침을 어느 수준까지 직접 확인하고 수정하고 싶어 할까?
• 사용자가 무엇을 요청할지 모르는 문제는 제품 설계와 사용자 교육 사이에서 어떻게 해결해야 할까?
• 프로젝트가 커질 때 필요한 맥락을 유지하면서도 새 세션마다 읽는 파일과 지침의 양을 어떻게 줄일 수 있을까?