그록봇·클로드 코드·챗GPT로 AI 비서 자비스를 만들었습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

그록봇·클로드 코드·챗GPT로 만든 AI 비서 자비스는 요청·실행·기획을 연결했지만, 안정적인 운영에는 사람의 승인과 결과 검증, 감시 체계 보완이 필요했다.

📌 핵심 요점

1. 여러 AI를 따로 쓰면 사람이 결과를 복사하고 맥락을 다시 설명하는 전달 업무를 떠안는다. 제작자는 요청부터 결과 회수까지 이어지는 구조로 이 문제를 줄이려 했다.
2. 그록봇은 요청과 진행 상황을 전달하는 비서실, 클로드 코드는 실행을 총괄하는 본부, 챗GPT는 기획을 검토하는 전략 기획실을 맡았다. 오르카와 어사이드는 각각 실행 환경과 브라우저 제어를 지원하는 도구다.
3. 본부가 비서실 화면을 조작하는 대신 그록봇이 본부 터미널에 요청을 넣고 출력을 읽도록 통신 방향을 바꿨다. 제한적인 메시지 왕복과 사람의 승인 중계는 확인됐다.
4. 본부와 챗GPT는 앞선 답변을 검토하며 후속 질문을 이어갔다. 다만 수집 과정에서 코드 블록이 누락돼 원문 저장과 스크린샷 대조가 필요했고, 본부의 설명도 실제 기록에 맞춰 정정했다.
5. 제작자는 전체 업무 경로와 재촉 없는 1차 완성본 보고를 확인했다고 설명했다. 그러나 감시 조기 종료와 승인 요청 누락이 있었으며, 자동 작업자 선정이나 장시간 무인 운영까지 입증한 것은 아니다.

🧩 배경과 문제 정의

여러 AI 도구를 쓰면서 제작자가 맡게 된 일은 결과 복사, 맥락 재설명, 진행 확인과 재전달이었다. 각 도구의 능력과 별개로 업무 인계가 연결되지 않아 사람이 계속 중간 전달자가 되는 문제가 생겼다.

목표는 한곳에 요청하면 필요한 도구로 일을 넘기고, 판단이 필요한 순간에는 사람에게 묻고, 마지막 결과를 다시 가져오는 흐름을 만드는 것이다. 이를 위해 AI 역할 셋과 지원 도구 둘을 조직처럼 구성하고, 부분 기능의 성공과 전체 업무의 완주를 구분해 평가했다. 영상 제작 자체를 시험 업무로 삼았으며, 녹화·원문 기록으로 확인한 내용과 기록이 부족한 설명을 구분하려 했다.

🕒 시간순 섹션별 상세정리

1. AI를 늘려도 줄지 않는 전달 업무

• 제작자는 AI 사이에서 신부름하는 상황을 바꾸기 위해 비서실·본부·전략 기획실을 구성했다. 영상의 음성도 자신의 목소리를 학습한 AI 음성이며, 자비스의 능력은 일곱 가지 평가 항목으로 시험하겠다고 밝혔다. [00:47]
• 기획, 코딩, 브라우저 확인이 도구별로 나뉘면서 결과 복사와 맥락 재설명이 반복됐다. 문제는 여러 AI를 쓰는 사실보다 서로 따로 일하는 구조에 있었다. [01:38]
• 원하는 흐름은 한곳에서 요청을 받고, 필요한 도구에 일을 나누고, 막히면 질문한 뒤 결과를 가져오는 것이다. 사람이 매번 업무를 이어 붙이는 부담을 줄이는 것이 출발점이었다. [01:55]

2. 세 가지 AI 역할과 두 가지 지원 도구

• 그록봇을 본부로 둘 가능성도 검토했지만, 장기 맥락과 복잡한 개발 총괄에 대한 의문이 있었다. 기존에 개발과 실행을 맡아온 클로드 코드를 본부로, 그록봇을 비서실로 정했다. [02:38]
• 챗GPT는 기획을 함께 검토하는 전략 기획실을 맡는다. 요청과 진행 상황 전달, 실행 관리, 기획 검토를 서로 다른 역할로 구분했다. [02:43]
• 오르카는 터미널과 에이전트를 다루는 실행 환경이고 어사이드는 브라우저 제어 도구다. 구성 전체를 AI 다섯 개로 설명하지 않고, AI 역할 셋과 지원 도구 둘로 구분했다. [02:59]

3. 통신 방향을 바꾸고 사람의 승인을 연결

• 클로드 코드가 비서실 화면을 직접 조작하는 방식은 제작자의 경험상 비용과 안정성 면에서 불편했다. 당시 녹화나 로그는 없으며, 이후 그록봇이 본부 터미널에 요청을 넣고 출력을 읽는 방향으로 설계를 바꿨다. [03:57]
• 시험 메시지 왕복 한 차례와 영상 제작 중 승인 요청·답변 장면을 근거로 제한적인 통신을 확인했다. 이 단계만으로 업무 전체가 완주됐다고 보지는 않았다. [04:22]
• 본부가 판단이나 승인을 요청하면 그록봇이 사람에게 전달하고 답을 돌려주는 연결이 녹화됐다. 작업 에이전트 실행과 결과 회수는 별도 평가 대상으로 남겼다. [05:59]

4. 챗GPT와 후속 질문을 이어가며 기획 검토

• 클로드 코드는 어사이드로 챗GPT의 브라우저 화면을 다루며 실제 영상 기획을 협의했다. 대상 시청자, 이야기 구조, 과장으로 느껴질 지점을 질문했고, 실전 도전기와 업무 평가를 중심으로 구성하는 제안을 받았다. [06:46]
• 본부는 앞선 답변을 읽고 AI와 지원 도구의 구분, 통신 시행착오의 증거, 작업 분배와 자동 분배의 차이를 후속 질문에 반영했다. 답변을 받는 데서 그치지 않고 다음 질문을 만드는 과정을 보여줬다. [07:31]
• 본부의 과도한 설명을 실제 경험과 기록에 맞춰 정정하는 과정도 있었다. 연속 기획 협의는 확인했지만, 이를 모든 AI가 알아서 업무를 분배했다는 증거로 확대하지 않았다. [08:11]

5. 코드 블록 누락과 저장 실패를 기록으로 검증

• 새 문서를 수집할 때 화면 구조를 읽는 경로가 코드 블록 세 개의 대부분을 놓쳤고, 수정본에서도 문제가 반복됐다. 제작자는 챗GPT 답변 자체의 누락과 수집 경로의 누락을 구분했다. [08:46]
• 페이지 원문을 저장하고 코드 블록 안쪽까지 스크롤한 스크린샷 59장과 대조했다. 검수 에이전트가 전체 191줄의 일치와 불일치 0건을 확인했다고 설명했으며, 본부도 표본을 다시 확인했다. [09:05]
• 그록봇 창을 녹화하는 도구도 처음에는 저장에 실패했다. 점으로 시작하는 임시 파일 이름을 바꾸고 실제 저장까지 확인하면서, 완료 선언보다 확인 기록이 중요하다고 강조했다. [09:31]

6. 전체 업무 경로와 작업 에이전트의 평가 기준

• 최초 지시 순간은 촬영하지 못해 허락을 받고 과거 메시지를 다시 여는 과정을 녹화했다. 이는 사후 기록 확인이며 최초 전달 순간의 녹화나 발신자에 대한 기술적 인증은 아니라고 설명했다. [10:22]
• 전체 시험은 원래 요청, 오르카 터미널의 작업, 챗GPT와의 기획 협의, 본부 결과와 비서실 회수 내용의 대조, 사용자 도착 여부를 차례로 확인하는 방식으로 제시됐다. [10:47]
• 작업 에이전트는 세션 생성뿐 아니라 지시 전달과 결과 산출까지 확인해야 한다. 본부가 지시해 분배하는 것과 작업자를 자동 선정·배치하는 것은 다르며, 장시간 무인 운영도 이번 시험의 확인 범위에 포함되지 않았다. [11:13]

7. 비서실의 감시 실패와 수습 기간의 자비스

• 과거 협의에서는 10초 간격 감시가 약 12분 만에 끝나 본부 작업보다 7분 먼저 중단됐다. 사용자가 재촉한 뒤 같은 미션 번호로 결과를 회수했다. [11:28]
• 이번 제작에서도 표식이 없다는 이유로 승인 요청을 놓쳤다. 점검 주기를 5분으로 설정하고 표식 없는 대기 상태도 알리도록 고친 뒤 승인 왕복과 재촉 없는 1차 완성본 보고가 이뤄졌다고 설명했지만, 휴대폰 대화는 녹화되지 않았다. [11:57]
• 마지막에는 요청 접수·실행 책임·결과 검증의 약속과 사람의 승인·판단을 핵심으로 정리했다. 한 번의 성공은 무인 운영의 증거가 아니며, 어디서 끊겼고 어떻게 회복했는지 확인해야 한다며 자비스를 수습 단계로 평가했다. [13:05]

🧾 결론

• 여러 AI를 연결하는 핵심은 도구 수보다 요청 접수, 실행 책임, 결과 검증의 역할을 분명히 정하는 데 있다.
• 완료 보고만으로 성공을 판단하기 어렵다. 실제 출력, 회수한 내용, 사용자에게 도착한 결과를 대조해야 한다.
• 사람은 승인과 최종 판단을 맡고, 시스템은 반복적인 전달을 담당하는 구성이 이번 실험의 지향점이다.
• 자비스는 운영을 계속 다듬어야 하는 단계다. 한 번의 성공보다 실패 지점과 회복 과정을 확인하는 일이 중요하다.

📈 투자·시사 포인트

• AI 도구의 가치는 개별 기능뿐 아니라 업무 인계에 드는 사람의 수고를 얼마나 줄이는지로도 평가할 필요가 있다.
• 브라우저 조작과 데이터 수집은 별도의 신뢰성 평가 대상이다. 답변이 정상이어도 수집 경로에서 내용이 빠질 수 있다.
• 승인 중계, 감시 지속, 결과 검증은 AI 비서의 실제 활용도를 좌우하는 운영 요소다.
• 영상은 특정 제품의 투자 가치나 정량적인 비용 절감 효과를 판단할 근거를 제공하지 않는다. 비용과 안정성에 관한 설명도 제작자의 경험 수준으로 해석해야 한다.

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

• 최초 요청을 보내는 순간은 녹화되지 않았다. 이후 원문 메시지를 다시 연 화면만으로 최초 발신자가 기술적으로 인증됐다고 볼 수 없다는 한계도 명시됐다.
• 제작자는 전체 경로와 1차 완성본 보고를 확인했다고 설명하지만, 휴대폰에서 오간 마지막 대화는 녹화로 남지 않았다. 화면으로 확인된 범위와 제작자의 설명을 구분해야 한다.
• 작업 에이전트의 세션 실행, 실제 지시 전달, 결과 회수는 각각 확인할 항목으로 제시됐다. 영상의 최종 설명만으로 이 항목들이 모두 검증됐다고 단정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 요청 접수, 실행 총괄, 기획 검토, 최종 승인 담당을 구분하고 각 역할의 입력과 출력이 무엇인지 정리한다.
• 최초 요청, 본부 작업, 기획 협의, 결과 회수, 사용자 도착을 하나의 업무 기록으로 연결해 확인한다.
• 브라우저에서 수집한 결과는 원문과 대조하고, 코드 블록처럼 누락이 발생한 영역은 내부 스크롤까지 점검한다.
• 표식이 없는 승인 대기와 작업이 길어지는 상황에서도 감시가 유지되는지 반복 시험한다.

❓ 열린 질문

• 작업이 감시 예상 시간보다 길어져도 비서실이 끝까지 기다리고 결과를 회수할 수 있을까?
• 표식이 없거나 출력 형식이 달라진 승인 요청도 안정적으로 감지할 수 있을까?
• 본부가 작업 에이전트에 지시한 뒤 결과를 검증하고 사용자에게 전달하는 과정은 어디까지 반복 재현됐을까?