시안은 클로드디자인, 사이트개발은 클로드코드, 수집은 어사이드, 올리기는 감자봇

📝 한줄 요약

인스타와 블로그에 흩어진 이유식 레시피를 한 사이트에 모으고 싶어서, 비개발자인 제가 Claude 디자인으로 시안을 만들고, Claude Code로 레시피 사이트 "집밥"을 짓고, AI 비서 "감자"에게 링크만 주면 사진까지 순서대로 올리게 했어요. 인스타 좋아요 글은 어사이드 브라우저에 내장된 에이전트 "사사"가 URL과 본문을 시트로 정리하고 레시피인지 아닌지까지 표시해 주면, 감자가 '레시피'만 골라 올리는 분업으로 하루 10개씩 자동으로 쌓이고 있어요.

바쁘시면 이것만 읽어도 돼요:

• 사용한 도구와 목표: Claude 디자인(시안) + Claude Code(사이트) + OpenClaw/Claude 비서 "감자"(레시피 올리기) + 어사이드 브라우저의 에이전트 "사사"(인스타 좋아요 정리). 흩어진 레시피를 링크만으로 한 사이트에 정리

• 핵심 방법: 일을 나눠서 맡겼어요. 시안은 Claude 디자인, 사이트는 Claude Code, 좋아요 목록 읽기는 사사, 사이트에 올리기는 감자. 사사와 감자 사이의 약속은 구글 시트의 "열"로 정했어요

• 막혔던 곳: 사이트를 짓는 동안 사용량 한도로 세 번 멈췄고, 비밀 열쇠가 채팅창에 두 번 노출됐고, 사사가 좋아요 글을 읽다가 인스타 접속 제한(429)에 걸렸어요

• 인상적이었던 순간: ① 사이트 코드를 쓴 AI 옆에 검토하는 AI를 세 겹으로 붙였더니 사람이 놓칠 오류를 계속 잡았어요 ② 사사가 접속 제한을 만나자 즉시 멈추고, 확인된 것만 저장하고, 나머지 결정은 저에게 넘겼어요 ③ 사사가 AI끼리 나눠 한 분류에서 개수는 맞는데 내용이 어긋난 곳을 스스로 찾아냈어요

• 확장성: 시트에 URL만 추가하면 감자가 알아서 처리해요. 다른 사이트·다른 주제로도 같은 구조를 쓸 수 있어요

• 배운 교훈: AI에게 "빨리 많이"보다 하루 10개 같은 숫자 한도와 "막히면 멈추고 알려줘"를 정해 주는 게 오래 가요

🎯 이런 분들께 도움돼요

• 인스타·블로그에 저장만 해두고 정리 못 한 레시피(또는 글)가 쌓여 있는 분

• 개발을 모르지만 내 취향의 사이트를 직접 만들어 보고 싶은 분

• AI 비서에게 반복 작업을 맡기고 싶은데 어디까지 시켜도 되는지 감이 안 오는 분

• AI 여러 개를 어떻게 나눠 써야 하는지 궁금한 분

😫 문제 상황 (Before)

이유식 레시피를 인스타, 네이버 블로그 등 여기저기서 찾아 저장해 뒀어요. 그런데 저장만 해두면 정작 필요할 때 못 찾아요. 한군데에 모으고 싶었지만, 글마다 재료와 순서를 읽고 사진까지 옮기는 건 손으로 하기엔 너무 귀찮고 힘들겠더라고요.

인스타는 더 심했어요. 마음에 드는 레시피에 좋아요만 눌러 두고 필요할 때 찾아봤는데, 뭘 눌렀는지도 까먹고, 찾는 것도 힘들었어요. 좋아요를 몇 개 눌렀는지조차 몰랐는데, 나중에 사사가 세어 보니 2025년 이후 글만 581개였고 목록은 2019년까지 이어져 있었어요.

그래서 이런 걸 바랐어요.

• 레시피 URL을 AI에게 던지면 정리해서 제 사이트에 올려주기

• 사진은 조리 순서에 맞춰 본문 중간중간에 넣기

• 쌓여 있는 인스타 좋아요 레시피도 알아서 하나씩 처리하기

🛠️ 사용한 도구

• Claude 디자인: 사이트 시안(화면 디자인)을 만드는 데 썼어요

• Claude Code: 시안을 받아 "집밥" 사이트를 실제로 만들고 배포했어요

• OpenClaw + Claude(Sonnet 5.5) = AI 비서 "감자": 슬랙으로 대화하면서 레시피를 읽고 정리해서 사이트에 올려요

• 어사이드 브라우저: 브라우저 안에 AI 에이전트가 들어 있는 브라우저예요. 지피터스에서 지아코모님이 알려주셔서 알게 됐고, 안에 있는 에이전트에게 "사사"라는 이름을 지어 줬어요. 사사는 인스타에서 제 좋아요 목록을 보고 글의 URL과 본문을 구글 시트에 정리해 줘요

• 구글 시트: 사사와 감자가 일을 주고받는 창구예요

• 특이사항: 저는 개발자가 아니라서 터미널 명령어는 AI가 알려주는 대로 따라 했어요

🔧 작업 과정

디자인 먼저, 사이트는 다른 AI에게 - 역할을 나누다

시작은 감자에게 이렇게 말한 거였어요.

레시피 기록을 위한 업무를 시작해보자! 레시피등록은 우리가 직접 웹앱을 만들고 거기다 등록을 하려고 해. 내가 너한테 레시피url을 주면 너가 그걸 보고 그 웹에 정리해서 올리는 방식으로 할려고 해. 페이지 디자인은 클로드디자인통해 해왔어. 어떤거같아? 할 수 있겠어?

감자는 디자인 파일을 열어 보고는 "주소만 있으면 구경만 되고, 글을 올리려면 사이트에 레시피를 받는 문(API)과 열쇠(토큰)가 있어야 한다"고 쉬운 말로 설명해 줬어요. 그리고 사이트를 짓는 건 Claude Code에게, 올리는 건 감자가 맡는 게 낫다며 Claude Code에게 줄 부탁 글을 써 줬어요.

에잇... 내가 그대로 복붙할 수 있게 완성된 프롬프트를 줘.

중간에 감자가 "고칠 부분만" 알려줬을 때, 저는 비개발자라 그걸 어디에 끼워 넣어야 할지 몰랐어요. "그대로 복붙할 수 있는 완성본"을 달라고 했더니 그 뒤로는 통째로 붙일 수 있는 글을 줬어요. 사이트 이름은 "집밥", 사진은 조리 순서에 맞춰 본문 중간에 넣는다는 규칙도 이때 정했어요.

"멈춰. 내가 디자인파일을 만들어왔어" - Claude Code에게 시안을 넘기다

Claude Code를 열고 처음에는 이렇게 말했어요.

안녕. recipe 폴더 하위에 집밥 레시피를 등록하는 웹페이지를 만들거야

Claude Code가 "먼저 요구사항을 정리하겠다"며 질문을 시작하길래 바로 끊었어요.

멈춰. 내가 디자인파일을 만들어왔어

다운로드 폴더에 있는 "집밥 레시피 웹페이지 시안.zip"을 풀어서, 그 안의 design_handoff_jipbap 폴더를 디자인 명세로 삼아 "집밥" 웹사이트를 개발해줘.

Claude Code는 시안 압축파일을 풀어 설명서와 화면 캡처를 읽고, 사이트를 어떻게 지을지 세 가지 안을 비교해서 하나를 추천했어요. 이유가 "비전공자가 운영하려면 들어가 볼 사이트 수가 적을수록 좋다"였어요. 사이트, 글 저장소, 사진 저장소를 Vercel 한 곳에서 다 관리하는 안이었고, 처음 나오는 용어는 괄호로 한 줄씩 풀어 줬어요.

그다음이 인상적이었어요. 바로 코드를 쓰지 않고 설계 문서를 먼저 쓰고, 다른 AI 검토자에게 점검을 받았어요. 1차 검토에서 빈틈 7가지가 나왔고, 2차에서는 "명세대로면 로그아웃 버튼을 구현할 수 없는 모순"까지 잡혔어요. 이어서 27개 작업으로 쪼갠 구현 계획을 쓰고 또 검토를 받았어요. 저는 이 대목에서 한 줄만 말했어요.

잘했겠지... 진행해

작업 하나마다 구현하는 AI → 설계대로 만들었는지 보는 AI → 코드 품질을 보는 AI 순서로 세 번씩 거쳤어요. 이 과정에서 AI 검토자가 사람이 놓치기 쉬운 걸 계속 잡아 냈어요. 예를 들어 키보드 ESC로 창을 닫는 동작이 계획서에서 빠져 있었는데, Claude Code가 "이건 계획 수립 단계의 실수입니다"라고 인정하고 계획서까지 같이 고쳤어요. 비밀번호를 비교하는 방식이 시간 차이로 추측당할 수 있다는 지적도 마지막 종합 검토에서 나와서 고쳤고요. 반대로 1인 사이트에는 과하다고 판단한 지적은 이유를 적고 접었어요.

가입과 연결은 사람 손으로 - 막히던 곳들

AI가 대신 못 하는 일은 제가 했어요. 가입, 화면 승인, 터미널 명령 몇 번이요. 여기서 비개발자답게 막혔어요.

postgres 없는데

화면에서 이름이 Neon으로 바뀌어 있었어요. 이름이 달라서 못 찾았던 거예요. 다음에는 연결 주소가 로컬에 안 내려와서 이렇게 막혔어요.

database url 오른쪽 점3개 눌렀는데 edit 없는데?

Claude Code가 "스토어 페이지에서 연결 문자열을 복사해서 채팅에 붙여 달라"고 해서, 저는 데이터베이스 연결 문자열과 사진 저장소 키를 채팅에 그대로 붙여 넣었어요. 지금 생각하면 이게 첫 번째 노출이에요.

사용량 한도로 세 번 멈췄다 이어갔어요. 한 번은 반쯤 만들어진 작업을 Claude Code가 깨끗이 되돌리고 그 작업을 처음부터 다시 했어요.

다시 해라...

너 작업중인데 내가 실수로 화면을 닫아버렸네. 미안. 다시 해라

화면을 실수로 닫았을 땐 Claude Code가 "작업은 끊기지 않고 끝까지 완료됐어요"라고 확인해 줬어요. 작업을 작게 쪼개 둔 덕에 끊겨도 이어붙기가 쉬웠어요.

마무리 질문은 개발 용어 선택지라 알아듣지 못했어요.

그래서 뭐 어쩌라구?

사이트는 이미 배포돼 동작 중이고, 그 질문은 코드를 어디에 보관할지에 대한 거라고 쉽게 다시 설명해 줬어요. 코드 보관 방식에 대해 Claude Code가 "GitHub를 안 쓰시니까 로컬에서 합치겠다"고 짐작해서 말하길래 이렇게 되받았어요.

내가 깃헙을 왜 안써? 다시 알아봐

확인해 보니 GitHub에 이미 로그인되어 있었고, Claude Code가 "제가 틀렸네요"라며 비공개 저장소를 만들어 코드를 보관했어요. 직접 배포하고 틀린 비밀번호는 거절 → 맞는 비밀번호는 통과 → 테스트 레시피 등록 → 삭제 순서로 확인한 뒤에야 끝났어요.

"조회는 공개" - 두 AI의 의견이 갈렸을 때

사이트를 짓기 시작한 첫날 밤에 Claude Code가 이렇게 물었어요. 처음 부탁 글에는 "조회도 로그인한 사람만"이라고 적혀 있었는데, 제가 "비밀번호는 왜 필요해?"라고 되묻자 공개했을 때와 잠갔을 때의 차이를 설명해 줬고, 저는 "조회만 공개, 쓰기는 비밀번호로 보호"를 골랐어요.

그런데 이튿날 감자가 이 사실을 몰랐어요. 사이트가 완성돼 감자에게 연결하자, 감자는 "조회가 로그인 없이 열리는 건 보안 구멍 같다, 막아 달라"고 했어요. 저는 그 말을 Claude Code에게 그대로 전했어요.

Claude Code는 "잠깐, 이건 전에 저희가 직접 정하셨던 것과 달라요"라며 첫날 밤의 선택을 기억해 냈어요. 바꾸면 사람이 볼 때도 매번 로그인해야 하고, 사진 주소를 막으면 사진이 화면에 바로 안 뜨는 큰 변경이라는 것도 설명했고요. 저는 "아 그래? 오키 알겠어. 감자한테 뭐라고 말할까?"라고 하고, 답을 그대로 감자에게 옮겼어요.

그 부분은 의도된 설계야. 집밥 사이트는 "조회는 누구나 공개, 등록/수정/삭제만 비밀번호(또는 토큰)로 보호"하기로 정했어. 보안 구멍이 아니라 일부러 그렇게 만든 거야.

서로 대화하지 않는 두 AI의 의견이 갈렸을 때, 제가 전달자가 되어 결정 기록을 가진 쪽으로 정리하면 됐어요.

비밀 열쇠가 채팅창에 두 번 올라온 날

Claude Code가 감자에게 보낼 안내문을 만들어 줬어요. 사이트 주소, "등록·수정·삭제·사진 업로드는 API로 직접 호출", 열쇠는 이렇게 쓰라는 설명, 그리고 설명서를 붙여넣을 자리까지 들어 있는 완성형 메시지였어요.

감자에게 이 사이트 사용법을 알려줘야해. 뭐라고 말하면 되지?

문제는 이 안내문 안에 열쇠 값이 그대로 들어 있었다는 거예요. 저는 그걸 슬랙에 그대로 붙였고, 열쇠가 노출됐으니 새로 발급받으라는 말이 나왔어요.

아오 그 토큰 슬랙에 그대로 보냈더니 토큰 유출됐다고 너한테 새로 발급받으래. 새토큰 줘

Claude Code는 옛 열쇠를 모든 곳에서 지우고 새 열쇠로 바꿔 다시 배포했고, 옛 열쇠는 거부되고 새 열쇠는 통과하는 것까지 직접 확인했어요. 그런데 이번에도 새 열쇠를 채팅창에 그대로 출력했어요. 그래서 저는 터미널에서 입력이 화면에 보이지 않는 방식으로 열쇠를 감자 쪽에 넣었어요. 처음엔 안 보이니 붙여넣기가 됐는지 몰라 헷갈렸는데(실제로 값이 비어 있었어요), 감자가 길이를 확인하는 줄을 붙여 줘서 제대로 들어간 걸 확인했어요. 이후로 감자는 이 값을 파일이나 채팅에 쓰지 않아요.

첫 레시피 - 사진 12장을 순서대로

[네이버 블로그 주소]
이걸로 레시피등록해봐. 설명서는 그렇게 고쳐

네이버 블로그는 일반적으로 읽어서는 사진 주소가 안 나왔어요. 감자는 모바일 페이지를 직접 받아서 숨어 있던 사진 12개를 찾아냈어요. 그걸 한 장으로 붙여 순서를 눈으로 확인한 다음, 정리본(제목·카테고리·재료·8단계 조리법·사진 위치)을 먼저 저에게 보여줬어요. 제가 OK 하자 사진을 한 장씩 올리고 조리 순서대로 본문에 넣어서 첫 레시피 "소고기감자 떡갈비"가 사이트에 올라갔어요.

"사진 지우는 기능이 없어?" - AI의 말을 되받았더니 사이트가 고쳐졌다

음 왜 그렇게 설계했지? 레시피를 삭제한다는건 그 레시피가 더이상 필요없단뜻인데.. 사진 지워도되잖아. 아니야?

감자가 "사진은 올라가면 지울 방법이 없어서 정리본을 먼저 보여준다"고 해서 의문이 생겼어요. 레시피를 지우면 그 사진도 지우는 게 맞잖아요. 감자도 "빠뜨린 기능에 가깝다"고 인정했고, 저는 Claude Code에게 이렇게 물었어요.

지금 레시피를 삭제해도 사진은 저장소에 남아서 삭제가 안된다며? 사실이야? 저장소에 있는거까지 지우려면 내가 직접 들어가서 지워야한다는게 진짜야?

Claude Code는 감자의 말을 그대로 믿지 않고 먼저 실제 코드를 열어 확인한 뒤 "사실입니다. 처음 만들 때부터 범위 밖으로 남겨둔 부분이에요"라고 답했어요. 그다음 감자가 써 준 요청문을 붙였어요.

레시피를 삭제할 때 그 레시피의 본문과 썸네일에 쓰인 사진도 사진 저장소에서 같이 지워줘. 단 다른 레시피가 같은 사진 주소를 쓰고 있으면 그 사진은 남겨줘. 레시피를 수정해서 본문에서 빠진 사진도 같은 방식으로 지워줘. 그리고 지금 저장소에 있지만 어떤 레시피에도 안 쓰이는 사진을 찾아서 지우는 정리 방법도 알려줘. 끝나면 API.md의 사진 삭제 관련 주의 문구도 고쳐줘. 바꾸고나서는 바뀐 API.md를 다시 알려줘.

구현 뒤 품질 검토에서 "삭제와 수정이 동시에 겹치면 이론상 문제가 생길 수 있다"는 지적이 나와 고쳤고, 안 쓰는 사진을 지우는 정리 도구는 기본이 "미리보기만"이라 실제로 지우려면 따로 옵션을 붙여야 하게 만들었어요. 배포하고 미리보기를 돌려 보니 안 쓰는 사진은 0개였어요. AI가 한 말이라고 그대로 받아들이지 않고 "그게 맞나?" 하고 물어본 게 사이트를 더 좋게 만들었어요.

인스타의 벽 - "그럴 거면 내가 하고 말지"

두 번째 레시피는 인스타였어요. 이번엔 영상(릴스)이라 감자가 가져올 수 있는 건 작은 영상 표지 한 장뿐이었어요.

에헤이... 내가 일을 안하려고 너한테 시킨건데 나한테 캡처를 시키면 안되지. 2번으로 하자.

감자가 "직접 캡처해 주세요"를 선택지로 내밀길래 이렇게 답하고 표지를 썸네일로 쓰기로 했어요. 진짜 벽은 그다음이었어요. 쌓여 있는 인스타 좋아요 레시피를 하나씩 올리자고 했더니, 로그인 없이는 글도 사진도 거의 안 보였어요.

감자야 내가 그 슬라이드를 하나하나 캡처해서 슬랙에 올릴거면 그냥 내가 레시피 정리해서 사이트에 올리고말지..... 말이 되니 그게.... 근데 메타가 api가 된다는데??? 확인 좀 해봐

감자는 조사해서 인스타 공식 API는 내 계정 글만 읽을 수 있고 남의 글을 읽으려면 심사까지 필요해서 현실적이지 않다고 정리해 줬어요. 대신 제 컴퓨터의 로그인 상태를 기억하는 작은 파일(쿠키)을 내려받기 도구에 주는 방법을 제안했어요. 쿠키 파일은 본인만 읽을 수 있게 보관하고, 제 다운로드 폴더에 있던 원본은 제가 지웠어요. 감자가 알려준 파일 이름이 틀려서 명령이 실패한 적도 있는데, 감자는 이름을 확인하지 않고 알려준 자기 실수라고 인정하고 그 뒤로는 안내하기 전에 먼저 확인하는 걸 규칙으로 적어 뒀어요.

어사이드 브라우저의 "사사"가 나선 이유

여기서 어사이드 브라우저가 중요한 역할을 해요. 감자는 인스타에 로그인되어 있지 않아서 "내가 좋아요 누른 글 목록"을 스스로 볼 수 없었어요. 반면 어사이드 브라우저 안의 에이전트 사사는 제가 열어 둔 인스타 탭에서 좋아요 목록을 볼 수 있었어요. 저는 사사에게 이렇게 물어봤어요.

사사야. 인스타그램에 내가 "좋아요"누른 글 중에 요리레시피의 URL만 구글스프레드시트에 쫙 모아서 보고싶어. 내가 인스타그램 탭을 열어놓긴했는데, 그렇게 작업하긴 좀 어려울까? 만약 요리레시피의 URL만 정리하는게 어렵다면, 모든 글의 URL와 본문을 스프레드시트에 적고, 그 스프레드시트에서 레시피가 포함된 글만 발라내서 봐도 될거같아. 더 좋은 방법이 있을까? 어떻게 해야할까?

"시켰다"기보다 "이렇게 하면 어려울까? 더 좋은 방법 있어?" 하고 물어본 거예요. 사사의 답이 좋았어요.

• "해볼 만합니다. 원본 목록을 남기고 레시피 글만 필터로 보는 방식을 추천해요. 처음부터 레시피 URL만 뽑으면 애매한 글을 놓쳐도 나중에 확인하기 어려워요."

• 레시피가 영상이나 이미지 안에만 있으면 본문만으로는 판별하기 어렵다는 한계도 먼저 말했어요.

• 바로 전체를 하지 않고 최근 글 10개로 시험부터 해 보자고 했고, 읽기만 하고 좋아요는 취소하지 않겠다고 약속했어요.

사사는 열을 네 개(주소, 본문, 레시피 여부, 요리명)로 제안했는데, 제가 필요 없다고 했어요.

난 그 글의 url과, 그 url이 레시피인지 아닌지 구분할 수 있는 용도의 본문글이 필요할 뿐이야. 댓글이나 좋아요수같은건 필요없어.

사사는 "제가 구성을 너무 늘렸네요"라며 주소와 본문 두 열로 줄였어요. 이 시트가 나중에 감자가 읽는 시트가 됐어요.

접속 제한(429) - 사사가 멈추는 방법

좋아요 목록은 스크롤할수록 끝없이 이어졌어요. 이미 2019년 글까지 내려갔길래 제가 범위를 줄였어요.

2025년글까지만 봐. 2024년글부터는 스크랩할 필요 없어

사사는 대상을 2025년 이후 581개로 확정했는데, 그 1분 뒤 인스타가 "요청이 너무 많다(429)" 화면을 띄웠어요. 사사는 글을 빨리 읽으려고 AI 보조 담당자를 최대 4명 동시에 띄워 같은 계정으로 읽고 있었어요. 사사 자신의 메모에는 "동시 조회가 유발한 것으로 의심되지만 확정은 아니다"라고 남았어요. 글이 너무 많아서라기보다 여러 명이 동시에 빠르게 읽은 게 원인으로 의심돼요.

이때 사사가 한 행동이 인상적이었어요.

1. 더 요청하면 제한이 길어질 수 있다며 읽기를 즉시 멈추고 저에게 알렸어요

2. 보조 담당자 모두에게 "새 요청 금지, 지금까지 읽은 것만 저장하고 종료"를 전달했어요

3. 확인이 끝난 376개만 시트에 저장하고 원문과 하나하나 대조했어요

4. 나머지 205개는 제가 결정할 때까지 건드리지 않겠다고 약속했어요

됐어 그럼 일단 중단해. 더 진행이 필요할지 여기서 일을 멈출지는 현재까지의 작업물을 보고 내가 결정할게.

사사는 이 일에서 얻은 교훈을 자기 메모에도 적어 뒀어요. "같은 로그인 계정에 병렬로 빠르게 읽지 않는다. 429가 보이면 새 읽기를 멈추고 성공·실패·미처리를 나눠 기록한다. 실패한 본문을 빈 본문으로 처리하지 않는다."

나중에 시트의 첫 링크가 어사이드에서만 안 열린 적도 있어요. 같은 주소가 일반 크롬에서는 열렸는데, 사사는 먼저 "제가 URL이 정상이라고 단정한 건 성급했어요"라고 인정하고 셀의 표시 주소, 실제 연결 주소, 수집 기록을 대조해 셋 다 맞다는 걸 확인했어요. 오타나 삭제라고 단정하지 않고, 정확한 원인은 모른다고 못 박았어요. 이후 10월 11일에 두 번 실행해 봤는데 429 없이 정상이어서 접속 제한은 풀린 것으로 확인됐어요(풀린 정확한 시각은 몰라요).

레시피냐 기타냐 - AI가 AI의 실수를 잡다

시트에 376개를 저장한 뒤 사사에게 한 번 더 시켰어요.

구글시트에 등록한 애들 본문 분석해서 레시피인지/아닌지(기타) C열에 적어

사사는 시작하기 전에 분류 기준부터 확인받았어요. 본문 글자만 보고 판단하고(이미지나 영상 속 내용은 추측하지 않기), 재료·분량·조리 과정이 있거나 레시피 모음을 소개하면 레시피, 제품 광고나 맛집, 육아 조언처럼 조리법이 없으면 기타로 하겠다고요. 저는 "응!"이라고만 했어요.

사사는 376개를 4구간으로 나눠 AI 담당자 4명에게 동시에 분류시켰어요. 결과를 검토하다가 중요한 걸 발견했어요. 분류의 근거 문장이 해당 행이 아니라 다른 행의 본문에서 나온 경우가 있었어요. 행 수와 중복을 보는 검사는 통과했는데, "근거 문장이 그 행의 본문에 실제로 있는지" 대조해 보니 드러난 거예요. 사사는 기존 분류를 믿지 않고 그 구간을 원본부터 다시 분류했어요. 결과는 레시피 186개, 기타 190개였어요. 개수가 맞는다고 내용이 맞는 건 아니라는 걸 AI가 스스로 보여 준 순간이었어요.

이 시트를 감자에게 건넸어요.

집밥사이트 업데이트하자. [구글 시트 주소] 여기 들어가보면 내가 좋아요눌렀던 인스타그램 레시피URL이 나와있어. 여기 나와있는 애들 하나씩 레시피 정리해서 올리는거야.

그래서 일이 이렇게 나뉘었어요.

둘은 서로 직접 대화하지 않아요. 시트의 열로 일을 넘겨요. 앞쪽 열(주소·본문·분류)은 사사가 채운 것이고, 뒤쪽 열(상태·올린 레시피·처리일)은 감자가 채우는 칸이에요. 사사는 좋아요 목록을 읽고 분류하는 일, 감자는 글을 분석해서 사이트에 올리는 일로 서로 못 하는 부분을 채워 줬어요.

"정리본 없이 바로 올려" - 믿고 맡기기

첫 시험으로 올린 모음글(면요리 6개)이 잘 올라간 걸 보고 감자에게 이렇게 말했어요.

정리본도 나 보여줄 필요 없어 그냥 사이트에 바로 올려. 올리다가 뭔가 이슈 발생했을때만 나한테 말해줘.

처음엔 감자가 정리본을 먼저 보여주고 OK를 받았는데, 신뢰가 쌓이니 "바로 올리고 문제가 있을 때만 말해"로 바뀐 거예요. 사사가 겪은 접속 제한 이야기를 감자에게도 해 줬더니 감자도 속도를 확 낮췄어요.

참고로 내가 어사이드 브라우저에서 인스타 좋아요누른 url 수집하면서 저 구글시트만들다가 접속제한먹었거든? 그니까 조심히..천천히.. 작업하도록 해.

글 사이에 30~70초씩 쉬고, 로그인 요구나 제한 경고가 뜨면 즉시 멈추고 알리고, 인스타에서 글을 받은 횟수를 기록해 두는 규칙이 이렇게 생겼어요.

하루 10개, 사진은 꼭 - 속도를 숫자로 정하다

작업하다가 AI 사용 한도에 걸려 감자가 멈췄어요. 감자는 비용을 줄이려고 "영상 글은 사진 없이 글만 올리자" 같은 안을 냈지만, 저는 이렇게 정했어요.

1,2는 어쩔 수 없어.. 사진이 필요해. 단 진행속도만 좀 조절하자. 하루 10개씩 진행해. 그리고 어사이드 브라우저가 매일 10시에 해당 시트에 url을 추가하기로 했어. 지금 약 180개가 남았으니 쌓인거 처리하는데에 18일이 걸릴거고, 18일 후에는 새롭게 등록된걸 처리할 수 있겠네.

"사진은 포기 못 한다, 대신 속도를 줄인다"는 결정이었어요. 하루 10개라는 숫자가 있으니 감자도, 저도 마음이 편해졌어요. 한 가지 오해도 있었어요. 감자는 "어사이드가 10시에 넣으니 오전 10:30에 시작하자"고 생각했는데, 제 말은 밤 10시였어요.

아 어사이드는 밤 10시에 일을 할거야. 너 말대로 오전,오후 나눠서 진행하도록 해. 만약 해당 시간에 컴퓨터가 안켜져있었다면 그 다음턴에 한꺼번에 하려고 하지 말고 해당 턴에 정해진 갯수만 진행해. 매일 새로 들어오는 레시피는 0~2개정도야. 너가 걱정할 정도의 양은 아니니까 걱정하지마. 업무목록에 적어두도록해.

그래서 사사는 밤, 감자는 낮(10:30·15:30)으로 시간이 겹치지 않게 됐고, 감자는 "컴퓨터가 꺼져 있었으면 그 몫은 건너뛰고 몰아서 하지 않는다"는 규칙을 갖게 됐어요.

새 좋아요만, 매일 저녁 10시에 - 사용자가 설계를 단순하게 만든 순간

접속 제한 뒤에 사사에게 이렇게 물어봤어요. 앞으로 좋아요를 더 누르면 이어서 해 줄 수 있냐고요.

음 아냐. 내가 다음에 좋아요 몇개 더 누른다음에 똑같은 작업을 요청하면 이어서 해줄 수 있어? 추가로 좋아요누른 url을 구글에 업데이트해주는거야.

사사는 처음에 "기존 URL과 전부 대조해서 중복을 빼야 한다"고 복잡하게 설명했어요. 그래서 제가 되물었어요.

어차피 "최신순"으로 조회하면 내가 가장 최근에 누른 url이 가장 상단에 뜰텐데 기존URL과 대조하는 작업이 필요해?

기준 게시물이 사라지거나 내가 좋아요를 취소해서 목록에서 사라지는 경우, 그 직전에 있는 url이 새로운 기준점이 되니까 문제없지않아?

사사는 "제가 설명을 너무 크게 잡았습니다"라며 받아들였어요. 맨 위에서부터 지난번 맨 위 글을 만날 때까지만 보면 된다는 방식으로 정리됐어요. 비개발자의 질문이 AI의 복잡한 설계를 단순하게 만든 장면이에요. 이어서 제가 반복 작업으로 설정할 수 있냐고 물었어요.

이거 혹시 반복업무로 설정할 수 있어? 내가 번번히 요청하긴 좀 귀찮을거같은데. 매일 저녁 10시에 진행한다던가.

사사는 설정하기 전에 범위를 요약해서 승인을 받았어요. 최신순 신규만, 이전 기준 글을 만나면 중단, 2025년 이후만, 기존 행과 205개는 건드리지 않기, 접속 제한이 보이면 반복 접속 없이 보고하기였어요. 그리고 제가 마지막으로 이렇게 물었어요.

오키. 근데 내일 10시에 컴퓨터 안켜져있으면 어떻게 되니?

사사는 어사이드 공식 안내를 찾아본 뒤 "다시 켰을 때 놓친 예약을 바로 실행하는지는 안내에 없어 보장할 수 없다"고 솔직하게 답했어요. 대신 "다음 정상 실행 때 마지막 성공 기준 이후의 신규를 한꺼번에 처리하라"고 지침에 넣어 뒀어요.

실제로 돌았냐고요? 네, 돌았어요. 다만 완벽하지는 않았어요. 설정한 다음 날 10월 10일 밤에는 어사이드가 꺼져 있어서 돌지 못했고, 10월 11일 아침에 어사이드를 켜자 바로 실행돼 새 좋아요 1건을 시트에 추가했어요(그날 밤에도 한 번 더 돌았는데 새 글은 없었어요). 컴퓨터가 켜져 있는 시간을 골라서 설정하면 되는 줄 알았는데, 예약 작업은 컴퓨터가 꺼져 있으면 못 돌아요. 이게 감자와 설계가 다른 점이에요. 사사는 "켜지면 밀린 걸 따라잡게", 감자는 "꺼졌던 몫은 몰아서 하지 않게" 했어요. 인스타 부담을 줄이려는 쪽은 몰아서 하지 않는 쪽이었어요.

자동으로 돌기 시작한 첫날

정해진 시간이 되면 감자가 알아서 작업 안내판을 읽고, 시트에서 할 일을 가져와 처리해요. 첫 가동에서 글 4개를 처리해 레시피 13개가 올라갔어요. 한우 유아식 모음 글은 영상 장면을 보고 요리 5개를 골라 요리마다 사진을 붙였고, 한 장에 요리 4개가 같이 있던 이미지는 요리별로 잘라서 올렸어요. 한 글은 캡션과 영상 자막 모두에 재료와 분량이 없어서 "건너뜀"이라고 시트에 적고 넘어갔어요. 문제가 없으니 저에게는 아무 연락도 오지 않았고요.

✅ 결과 (After)

Before vs After

결과물

• 10월 11일 기준 집밥에 레시피 26개 (한그릇 11·반찬 6·간식 4·밥 4·국 1)가 올라가 있어요

• 시트에서 아직 처리 안 한 레시피 글은 175줄이 남아서, 하루 10개 한도로 약 18일이 더 걸려요

• 접속 제한 때문에 시트에 못 담은 205개는 일부러 건드리지 않았어요

• 복권 이벤트 티켓 이미지 보관에도 집밥의 사진 저장소를 그대로 재활용했어요

• 집밥 사이트 화면 (게시할 때 캡처를 넣어요)

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 일을 쪼개서 각자 잘하는 쪽에 맡기기: 시안은 Claude 디자인, 사이트는 Claude Code, 좋아요 읽기는 사사, 올리기는 감자. 한 AI에게 다 시키지 않았어요

2. AI 옆에 검토하는 AI 붙이기: Claude Code는 작업마다 "만드는 AI → 설계대로인지 보는 AI → 품질 보는 AI"를 거쳤고, 사람이 놓칠 오류를 계속 잡았어요

3. 구글 시트를 약속 창구로 쓰기: 열을 나눠 "여긴 사사, 여긴 감자"로 정해 두면 서로 말을 주고받지 않아도 일이 이어져요

4. 속도는 숫자로 정하기: "천천히"보다 "하루 10개, 글 사이 30~70초"처럼 숫자로 정하니 AI도 저도 불안하지 않았어요

5. AI에게 "막히면 멈추고 알려줘"를 시키기: 사사는 429를 만나자 즉시 멈추고, 확인된 것만 저장하고, 남은 건 사람에게 결정을 넘겼어요

6. 개수가 맞아도 내용을 검사하기: 분류 결과를 "개수"만 보지 않고 "근거가 그 행에 진짜 있는지"까지 보게 하니 어긋난 곳이 드러났어요

7. 처음엔 정리본을 먼저 보고, 믿음이 생기면 "바로 올려"로 바꾸기

8. AI의 말을 그대로 받지 않고 되묻기: 사진 삭제 기능은 제가 "왜 그렇게 설계했지?" 하고 물어서 사이트가 고쳐졌고, 사사의 복잡한 설계는 제 질문으로 단순해졌어요

9. 두 AI의 의견이 갈리면 결정 기록을 기준으로 정리하기: 제가 전달자가 되어 "전에 정한 것"으로 돌아가니 해결됐어요

10. AI마다 잘하는 걸 다르게 맡기기: 로그인된 브라우저에서 내 좋아요 목록을 읽는 건 브라우저 안의 에이전트(사사)가, 글을 분석해서 사이트에 올리는 건 감자가 맡았어요

이렇게 하면 안 돼요

1. 비밀 열쇠(토큰)나 데이터베이스 주소를 채팅창에 붙이지 마세요. 저는 두 번 붙였어요(AI가 달라고 해서 한 번, AI가 만든 안내문에 들어 있어서 한 번). 노출되면 새로 발급받고, 입력은 화면에 안 보이는 방식으로 하세요

2. "10시" 같은 모호한 시간을 그냥 쓰지 마세요. 오전인지 밤인지 적어 주세요. AI가 마음대로 가정해요

3. AI 여러 명이 같은 계정으로 동시에 빠르게 읽게 하지 마세요. 접속 제한의 가장 큰 원인으로 의심돼요

4. 예약 작업은 컴퓨터가 켜져 있어야 돌아요. 꺼져 있던 시간의 몫을 어떻게 할지 미리 정해 두세요

5. AI가 줄임말이나 개발 용어로 물으면 그냥 넘어가지 마세요. "그래서 뭐 어쩌라구?"라고 물으면 쉬운 말로 다시 설명해 줘요

6. 로그인 쿠키 같은 민감한 파일은 아무 데나 두지 마세요. 본인만 읽을 수 있게 보관하고 다운로드 폴더의 원본은 지우세요

7. AI의 짐작을 사실로 받아들이지 마세요. Claude Code가 "GitHub를 안 쓰시니까"라고 짐작했는데 틀렸어요

🌍 다른 업무에 적용한다면?

• 블로그·뉴스레터·유튜브에서 저장해 둔 글을 주제별 아카이브 사이트로 정리

• 쇼핑 후기, 독서 메모, 운동 기록처럼 "링크만 던지면 정리되는" 개인 자료실

• "모으는 에이전트(브라우저)"와 "정리하는 에이전트(비서)"를 시트로 연결하는 구조는 거의 어디에나 쓸 수 있어요

🚀 앞으로의 계획

• 남은 175줄을 하루 10개씩 처리하고, 그 뒤에는 사사가 올리는 새 글만 따라가기

• 접속 제한으로 시트에 못 담은 205개를 이어서 모을지는 아직 정하지 않았어요

• 집밥은 혼자 쓰는 레시피 모음 사이트로 계속 운영할 예정이에요. 더 키울 계획은 없고, 레시피를 모아 두고 필요할 때 꺼내 보는 용도로 충분해요

📋 재사용 가능한 프롬프트

프롬프트 1: AI에게 일을 쪼개서 맡길 때

나는 [만들고 싶은 것]을 만들려고 해. 화면 만들기는 [도구A]가, 글/데이터 올리기는 네가 맡을 거야. 네가 [무엇]을 올리려면 사이트가 어떤 기능(API)과 열쇠(토큰)를 갖춰야 하는지, [도구A]에게 줄 부탁 글을 그대로 복사해서 붙일 수 있게 완성본으로 써줘.

프롬프트 2: 반복 작업을 맡길 때 (규칙을 숫자로)

시트 [A열: URL, B열: 본문, C열: 분류]에서 C가 [레시피]이고 D가 비어 있는 줄을 골라 [사이트]에 올려줘. 올린 뒤 D~F열에 상태·올린 이름·날짜를 적어. 정리본은 보여주지 말고 문제가 있을 때만 나한테 말해. 글 사이에 [30~70초] 쉬고, 로그인을 요구하거나 제한 경고가 뜨면 즉시 멈추고 알려줘. 하루에 최대 [10]개까지만 하고, 컴퓨터가 꺼져 있어서 못 한 건 몰아서 하지 마.

프롬프트 3: 브라우저 에이전트에게 목록 정리를 시킬 때 (물어보는 식)

[사이트]의 [내 목록]에서 [원하는 것]만 구글 스프레드시트에 모아서 보고 싶어. 내가 [사이트] 탭을 열어 놨는데, 그렇게 작업하기 어려울까? 어렵다면 전부 적어 놓고 시트에서 걸러서 봐도 될 것 같아. 더 좋은 방법이 있을까? 먼저 10개로 시험해 보고, 막히면 멈추고 알려줘.

프롬프트 4: 지시가 이해 안 될 때

방금 [그 줄]이 무슨 뜻인지 이해가 안 가. 비유를 들어서 한 번 더 쉽게 설명해줘.