인사. 오늘은 오전은 세미나, 오후는 강의와 실습입니다. 오전은 제가 설명하고 화면으로 보여 드리는 시간이고, 오후에 처음부터 직접 써 봅니다.

[설명할 것] - 오전은 세미나, 오후는 강의와 실습 - 대상: 동남권기계연구본부 연구원·시험원 [대본] 안녕하십니까. 오늘 Claude Code 활용 교육을 맡은 이철로입니다. 오전은 제가 설명하고 화면으로 보여 드리는 세미나이고, 오후에는 각자 PC에서 처음부터 직접 써 봅니다.

기구 설계와 시험을 10년 했던 사람이라 시험 데이터와 보고서 일이 어떤지 압니다. 지금은 AI 서비스를 직접 만들고, 기업·기관에 AI 교육을 설계합니다. 오늘 2부에서 보여 드릴 플러그인들은 제가 연구·개발 일을 하면서 반복되는 부분을 묶어 공개한 것입니다.

[설명할 것] - R&D 메카니컬 엔지니어 10년 경력 — 시험 데이터·보고서 업무를 겪어 봄 - 지금은 AI 서비스 개발과 AI 교육 설계 - gptaku-plugins는 2부에서 연구개발용 조합으로 소개 [대본] 저는 기구 설계와 시험을 10년 했던 사람입니다. 그래서 시험 데이터를 정리하고 보고서를 쓰는 일이 얼마나 손이 많이 가는지 압니다. 지금은 AI 기반 서비스를 직접 만들고, 기업과 기관의 AI 교육을 설계합니다. 2부에서 보여 드릴 플러그인들은 제가 연구·개발 일을 하면서 반복되는 부분을 묶어 공개한 것입니다. 오늘은 이 경험을 바탕으로 연구·시험 업무에 바로 옮길 수 있는 방법 위주로 말씀드리겠습니다.

오전은 세미나입니다. 왜 써야 하는지, 어떻게 돌아가는지, 그래서 연구·시험 업무에 어떻게 쓰는지, 장비와 하드웨어 쪽에서는 어떤 것들이 나오고 있는지를 보여 드립니다. 오후는 강의와 실습입니다. 실습 2부터는 /lab2~/lab4 스킬로 시작합니다. 빈 폴더에서 처음 맡겨 보고, 인터뷰와 내 공개 자료 10개 이내로 연구 워크스페이스를 만들고, 그 공간에서 주제 하나를 논문·공고 적합도·기획서까지 이어 간 뒤, 스킬과 기록 자동 실행으로 계속 쓰게 만듭니다. 처음 쓰는 분은 강사 자료로 따라 하고, 써 본 분은 내 자료로 합니다. 시각은 진도를 보고 맞춥니다. 쉬는 시간은 오전 한 번, 오후는 흐름을 보고 정합니다.

[설명할 것] - 오전 네 블록: 왜·어떻게 돌아가나·어떻게 쓰나·장비와 하드웨어 - 오후 실습 2부터는 /lab2~/lab4 스킬로 시작 - 처음 쓰는 분은 강사 자료로, 써 본 분은 내 공개 자료로 - 진행 시각은 진도를 보고 맞추고, 쉬는 시간은 현장에서 안내 [대본] 오늘 하루 흐름을 먼저 보겠습니다. 오전에는 왜 써야 하는지, 어떻게 돌아가는지, 연구·시험 업무에 어떻게 쓰는지, 그리고 장비와 하드웨어 쪽에서 어떤 것들이 나오고 있는지를 보여 드립니다. 오후에는 빈 폴더에서 처음 맡겨 보고, 인터뷰와 내 공개 자료로 연구 워크스페이스를 만든 뒤, 주제 하나를 논문과 공고 적합도, 기획서까지 이어 갑니다. 마지막에는 스킬과 기록 자동 실행으로 계속 쓰는 방법을 다룹니다. 처음 쓰시는 분은 제 자료로 따라 하시면 되고, 써 보신 분은 본인 공개 자료로 하시면 됩니다. 진행 시각은 진도를 보면서 맞추겠습니다. 시작하기 전에 몇 가지 여쭤보겠습니다.

시작하기 전에 손 한번 들어 볼게요. 업무에 AI 쓰고 계신 분 계세요? ChatGPT든 사내 도구든 상관없습니다. (손 든 분들을 보고) 네, 감사합니다.

[설명할 것] - 손들기 1/3: 업무에 AI를 쓰는지 - ChatGPT든 사내 도구든 상관없음 [대본] 업무에 AI를 쓰고 계신 분, 손 한번 들어 주시겠습니까? ChatGPT든 사내 도구든 상관없습니다. 네, 감사합니다.

Claude Code를 한 번이라도 써 보신 분 손 들어 주세요. 데스크톱 앱, 터미널, VS Code 어디서든 괜찮습니다. 처음 쓰는 분 기준으로 진행하고, 써 보신 분께는 실습마다 더 해 볼 거리를 드립니다.

[설명할 것] - 손들기 2/3: Claude Code 사용 경험 - 데스크톱 앱·터미널·VS Code 어디서든 해당 - 처음 쓰는 분 기준으로 진행, 써 본 분께는 실습마다 더 해 볼 거리 [대본] Claude Code를 한 번이라도 써 보신 분 손 들어 주세요. 데스크톱 앱이든 터미널이든 VS Code든 괜찮습니다. 오늘은 처음 쓰시는 분을 기준으로 진행하고, 써 보신 분께는 실습마다 더 해 볼 거리를 드리겠습니다.

마지막으로, Claude Code로 내 업무에 쓰는 프로그램이나 스킬을 직접 만들어서 쓰고 계신 분 계세요? 보조강사: 세 질문에 손 든 인원을 세어 교육 일지에 적고, 처음 쓰는 분 자리를 표시해 둡니다.

[설명할 것] - 손들기 3/3: 내 업무용 프로그램이나 스킬을 만들어 쓰는지 - 보조강사가 세 질문 응답 수와 처음 쓰는 분 자리를 기록 [대본] 마지막으로, Claude Code로 내 업무에 쓰는 프로그램이나 스킬을 직접 만들어 쓰고 계신 분 계십니까? 답해 주셔서 감사합니다. 오후 실습 지원에 참고하겠습니다.

[설명할 것] - 1부: 무엇이고, 어떻게 동작하고, 왜 쓰며, 무엇을 할 수 있는지 - 채팅 AI와의 차이부터 시작 [대본] 1부에서는 Claude Code가 무엇이고 어떻게 동작하는지부터 보겠습니다. 왜 써야 하는지와 무엇을 할 수 있는지도 함께 짚겠습니다.

채팅 AI는 질문에 답을 씁니다. 자료는 대화창에 붙여 넣거나 올리고, 계산은 대화창 안에서 하고, 결과는 채팅 안에 남습니다. 새 대화마다 다시 설명합니다. Claude Code는 요청한 일을 끝까지 해 냅니다. 작업 폴더의 파일을 직접 열고, 내 PC에서 코드를 실행해 결과를 확인하고, 결과를 파일로 폴더에 남깁니다. 폴더의 규칙 파일(CLAUDE.md)을 매번 먼저 읽습니다. 어디서 쓰나: 데스크톱 앱, 터미널, VS Code 같은 편집기에서 같은 Claude 계정으로 씁니다. 오늘 실습은 데스크톱 앱 화면으로 안내합니다. "에이전트"는 여기서 한 번만 정의합니다: 스스로 파일을 열고, 프로그램을 실행하고, 결과를 보고 다시 고치는 AI입니다.

[설명할 것] - 웹 채팅은 답과 코드가 대화창에, Claude Code는 결과가 내 폴더에 파일로 남음 - 오른쪽은 2026-10-13 실제 실행 기록, 왼쪽은 일반적인 웹 채팅 흐름을 옮겨 그린 것 - 에이전트 정의: 스스로 파일을 열고, 실행하고, 결과를 보고 다시 고치는 AI - 폴더의 규칙 파일(CLAUDE.md)을 매번 먼저 읽음 [대본] 같은 요청을 두 방식에 넣으면 어떻게 다른지 보시겠습니다. 웹 채팅에서는 코드를 받아도 실행하고 저장하는 일은 제가 해야 하고, 결과는 대화창에 남습니다. Claude Code는 파일을 받고, 코드를 내 PC에서 실행하고, 그래프까지 파일로 폴더에 남깁니다. 오른쪽 화면은 실제 실행 기록에서 옮긴 것입니다. 오늘 '에이전트'라는 말은 이렇게 정의하겠습니다. 스스로 파일을 열고, 프로그램을 실행하고, 결과를 보고 다시 고치는 AI입니다. 그리고 Claude Code는 작업 폴더에 있는 규칙 파일, CLAUDE.md를 매번 먼저 읽습니다. 데스크톱 앱, 터미널, 편집기 어디서든 같은 계정으로 쓰고, 오늘 실습은 데스크톱 앱 화면으로 안내합니다.

에이전트 루프를 먼저 설명합니다. 채팅 AI는 한 번 답하고 끝나지만, Claude Code는 요청을 받으면 계획을 세우고, 파일을 읽거나 명령을 실행하고, 결과를 보고 틀리면 고쳐서 다시 실행합니다. 일이 끝날 때까지 이 고리를 스스로 돕니다. 쓰는 도구는 네 가지입니다. 파일 읽기·검색은 묻지 않고, 파일 만들기·고치기와 명령 실행은 Manual 모드에서 매번 묻습니다. 웹 검색도 설정에 따라 묻습니다. 승인 창에는 무엇을 하려는지가 그대로 나옵니다. 읽어 보고 허용하거나 거절합니다. 거절하면 다른 방법을 찾거나 이유를 묻습니다.

[설명할 것] - 계획 → 실행 → 확인 → 고치기를 일이 끝날 때까지 반복 - 실제 기록: scipy 설치 실패 뒤 numpy로 방법을 바꿔 완료 - 파일 읽기·검색은 묻지 않고, 수정과 명령 실행은 Manual 모드에서 매번 물음 - 승인 창의 내용을 읽고 허용하거나 거절 [대본] 채팅 AI는 한 번 답하고 끝나지만, Claude Code는 요청을 받으면 계획을 세우고, 실행하고, 결과를 보고 틀리면 고쳐서 다시 실행합니다. 이 고리를 일이 끝날 때까지 스스로 돕니다. 오른쪽 아래가 실제로 고치기가 일어난 기록입니다. scipy라는 패키지가 없어서 설치를 두 번 시도했는데 같은 오류가 났고, 그러자 scipy 없이 numpy로 직접 봉우리를 찾는 방식으로 바꿔서 끝냈습니다. 쓰는 도구는 파일 읽기, 파일 만들기와 고치기, 명령 실행, 웹 검색입니다. 읽기는 묻지 않지만, 파일을 바꾸거나 명령을 실행할 때는 Manual 모드에서 매번 승인 창이 뜹니다. 승인 창에는 무엇을 하려는지가 그대로 나오니 읽어 보고 허용하거나 거절하시면 됩니다.

현장 재실행 대신 실제 사전 실행 결과를 보여 줍니다. 원 요청: https://zenodo.org/records/6813857 에서 Waveforms Point05.tdms를 받아 어떤 시험 기록인지 먼저 알려 주고, 힘과 가속도를 CSV로 바꾼 뒤 시간이력과 주파수 스펙트럼 그래프를 그려 줘. 먼저 계획을 보여 줘. 실행 결과: 32,768점, 약 8,533Hz, 3.84초, 최대 가속도 41.55g, 가장 큰 봉우리 588.5Hz. scipy 설치 실패 뒤 numpy로 수정했습니다. 근거: _lab-archive/rehearsal-r4-tdms-20261013/. 오후 실습 1은 같은 순서를 논문 통계로 실습합니다.

[설명할 것] - 현장 재실행이 아니라 2026-10-13 사전 실행 결과 - 결과: 32,768점, 약 8,533Hz, 3.84초, 최대 가속도 41.55g, 가장 큰 봉우리 588.5Hz - 단일 측정의 봉우리 값을 확정 공진 주파수로 소개하지 않음 - 공개 데이터: Zenodo 6813857, CC BY 4.0 [대본] 이 장은 현장에서 다시 돌린 것이 아니라, 미리 실제로 돌려 둔 결과입니다. 공개 데이터 주소와 요청 한 줄만 줬습니다. 알루미늄 판을 해머로 친 기록인데, 어떤 시험 기록인지 먼저 설명하고, 힘과 가속도를 CSV로 바꾼 뒤 시간이력과 스펙트럼 그래프를 그려 달라고 했습니다. 결과는 채널당 32,768점, 약 8,533Hz로 3.84초 분량이었고, 최대 가속도는 41.55g, 가장 큰 봉우리는 588.5Hz로 나왔습니다. 다만 이 봉우리 값은 측정 하나에서 나온 것이라 확정된 공진 주파수로 보시면 안 됩니다. 앞 장에서 본 scipy 오류와 numpy 수정이 바로 이 실행에서 나온 것입니다. 오후 실습 1에서는 같은 순서를 논문 통계로 직접 해 보시게 됩니다.

생성 일러스트. 모든 채팅 AI가 파일 저장을 못 한다는 뜻이 아닙니다. 여러 채널에서 작업할 때 기록과 자료가 분산되는 문제를 설명합니다.

[설명할 것] - 메일·메신저·드라이브·AI 채팅에 같은 업무 자료가 흩어짐 - 생성 일러스트 - 모든 채팅 AI가 파일 저장을 못 한다는 뜻은 아님 [대본] 그럼 왜 작업 공간이 따로 필요한지 보겠습니다. 실제 업무를 하다 보면 같은 일의 자료가 메일, 메신저, 드라이브, AI 채팅에 따로 남습니다. 그러면 새 대화를 열 때마다 다시 설명하고, 자료를 다시 올리고, 지난 답을 다시 찾게 됩니다. 채팅 AI가 파일을 전혀 못 다룬다는 말씀이 아닙니다. 여러 채널에서 일하면 기록과 자료가 나뉜다는 문제를 말씀드리는 것입니다.

기관 자료는 승인된 환경에서만 사용합니다. 오늘은 공개 자료와 가상 프로필을 씁니다.

[설명할 것] - 내 논문·측정 파일·분석 코드·보고서 양식을 기준으로 작업 - 근거 없는 칸은 비워 두고 모르는 칸은 남김 - 기관 자료는 승인된 환경에서만, 오늘은 공개 자료와 가상 프로필 [대본] 작업 공간을 두면 내가 쌓아 온 자료를 기준으로 일을 시킬 수 있습니다. 논문과 보고서는 방법과 수치, 한계를 원문 위치와 함께 정리하게 하고, 측정 파일은 형식과 단위부터 확인한 뒤 계산과 그래프로 바꾸게 합니다. 기존 분석 코드는 고치고 다른 방법으로 검산하게 할 수 있습니다. 보고서 양식에 맞춰 초안을 쓰게 할 때는 근거가 없는 칸을 채우지 말고 남겨 두게 하는 것이 중요합니다. 온라인 조사도 하지만, 내 자료와 기준, 제약을 먼저 읽게 하는 것이 순서입니다. 다만 기관 자료는 승인된 환경에서만 씁니다. 오늘은 공개 자료와 가상 프로필만 사용합니다.

근거: research-planner/CLAUDE.md 실물. 플러그인은 처음 쓰는 사람이 쉽게 쓰도록 공개한 명령·스킬 묶음입니다. 자세한 설치와 사용은 오후 실습 2·2-B·3에서 합니다.

[설명할 것] - research-planner: 강사가 만든 연구 기획 워크스페이스 - 규칙(CLAUDE.md)·판단 기준·작업 순서·계산 스크립트·자료와 기록을 한 폴더에 - /onboarding 인터뷰에 답하고 내 자료는 00-inbox/에 - 설치와 사용은 오후 실습 2·2-B·3에서 [대본] 제가 실제로 쓰는 작업 공간을 하나 보여 드리겠습니다. research-planner라는 연구 기획 워크스페이스입니다. 규칙은 CLAUDE.md에, 판단 기준은 frameworks 폴더에, 작업 순서는 명령 폴더에, 계산과 검사는 스크립트 폴더에, 자료와 기록은 따로 둡니다. 이렇게 하면 Claude Code가 이 폴더를 열 때마다 같은 규칙과 순서로 일을 시작합니다. 오후에는 이 폴더를 각자 PC에 받아 /onboarding 인터뷰에 답하고, 내 자료를 00-inbox에 넣어서 내 것으로 만듭니다. 자세한 설치와 사용은 오후 실습에서 함께 하겠습니다.

생성 일러스트와 설명용 예시입니다. 기간별 성능 향상을 보장하지 않습니다. 모델이 대화만으로 재학습되는 것이 아니라 저장한 자료와 규칙을 다음 작업에서 다시 읽는 구조입니다.

[설명할 것] - 생성 일러스트와 설명용 예시 — 기간별 성능 향상을 보장하지 않음 - 모델이 재학습되는 것이 아니라, 저장한 자료와 규칙을 다음 작업에서 다시 읽는 구조 - 처음엔 잘못 이해한 점을 고치고, 반복 요청과 기준을 쌓아 감 [대본] 이런 작업 공간은 처음부터 완벽하지 않습니다. 처음에는 내 자료와 양식을 넣고, 잘못 이해한 점을 고쳐 나갑니다. 쓰다 보면 자주 하는 요청과 고친 코드, 판단 기준이 쌓이고, 검증한 결과가 다음 작업의 출발점이 됩니다. 여기서 오해하시면 안 되는 점이 있습니다. 모델이 대화만으로 다시 학습되는 것이 아닙니다. 폴더에 저장한 자료와 규칙을 다음 작업에서 다시 읽기 때문에 맞아지는 것입니다. 화면의 기간 구분도 설명용 예시이고, 그만큼 좋아진다는 보장은 아닙니다.

생성 일러스트. 세컨브레인 킷의 캡처·저장·검색·상태·주입·규칙 층을 비개발자용으로 단순화한 개념도. 오후에는 전체 킷 설치가 아니라 실습 4에서 /wrap 기록, 세션 종료 때 자동으로 쌓이는 대기열, 예약 실행, 새 세션의 기록 읽기를 해 봅니다.

[설명할 것] - 기록 → 찾기 → 확정 → 다음 세션에서 읽기 - 검증한 사실과 미확인을 구분해 남김 - 생성 일러스트, 세컨브레인 킷을 단순화한 개념도 - 오후 실습 4는 전체 킷 설치가 아니라 /wrap 기록·대기열·예약 실행·새 세션 읽기 [대본] 앞 장의 축적이 실제로 일어나려면 기록을 다음 작업에서 다시 읽게 만들어야 합니다. 무엇을 했고 무엇이 남았는지 기록하고, 이번 작업에 필요한 자료만 찾고, 검증한 사실과 아직 확인하지 않은 것을 나눠 둡니다. 그러면 다음 세션은 지난 결정과 다음 할 일부터 시작할 수 있습니다. 이 그림은 제가 쓰는 기록 도구를 처음 쓰시는 분 눈높이로 단순하게 그린 것입니다. 오후 실습 4에서는 이 전체를 설치하는 것이 아니라, /wrap으로 기록을 남기고 새 세션이 그 기록을 읽는지 확인하는 부분을 직접 해 봅니다. 세션 종료 때 자동으로 쌓이는 대기열과 예약 실행도 함께 봅니다.

[설명할 것] - 2부: 연구 업무를 맡긴 실제 결과와 바로 쓸 수 있는 플러그인 조합 - 외부 사례는 저자 보고와 재현 여부를 구분해 소개 [대본] 2부에서는 연구 업무를 에이전트에 맡긴 실제 결과를 보고, 오후에 바로 쓸 수 있는 플러그인 조합을 소개하겠습니다.

기존 조사 문서에 확보된 외부 연구 사례만 사용합니다. 앞 사례는 Claude Code, 뒤 사례는 ChatGPT-4 사용 사례이며 같은 제품으로 뭉뚱그리지 않습니다. 장비별 상세와 위험 사례는 3부에서 설명합니다.

[설명할 것] - RIKEN은 Claude Code, NREL은 ChatGPT-4 사례 — 같은 제품으로 묶지 않음 - 저자 보고이며 강의에서 재현하지 않음 - 실험 조건과 검증은 연구자가 맡음 [대본] 연구자들이 AI로 가장 먼저 만들고 있는 것은 반복하던 분석과 계측 프로그램입니다. RIKEN 연구자는 Claude Code로 LabVIEW 현미경 앱을 Python으로 다시 만들었고, 이동 한계는 사람이 정했습니다. NREL에서는 ChatGPT-4로 소스미터 제어 코드와 화면을 만들었고, 실험 설계와 결과 검증은 연구자가 맡았습니다. 두 사례는 쓴 도구가 다르니 같은 제품 사례로 보시면 안 됩니다. 둘 다 본인과 저자가 보고한 내용이고 저희가 재현하지는 않았습니다. 공통점은 프로그램은 AI와 만들되 조건과 검증은 연구자가 쥐고 있다는 것입니다. 장비 쪽 상세 사례는 3부에서 더 보겠습니다.

[설명할 것] - 코드: 파싱·계산·합격 규칙 적용 / AI: 요구사항 추출·대조표·서술 초안 / 사람: 모든 판정과 서명 - 측정하지 않은 값은 추정해 채우지 않고 '미측정'으로 남김 - 보고서 수치는 실제 실행한 계산 출력과 일치, 문장 속 숫자를 손으로 고치지 않음 [대본] 측정 후 작업은 계산, 서술, 판정을 나눠 맡기는 것이 좋습니다. 원시 데이터 파싱이나 스펙트럼 계산, 합격·불합격 규칙 적용은 코드가 합니다. 시험계획서에서 요구사항을 뽑고, 측정 증거와 대조표를 만들고, 보고서 서술 초안을 쓰고 빠진 증거를 찾는 일은 AI가 합니다. 모든 판정과 보고서 서명, 기준 해석은 사람이 합니다. 여기에 규칙 두 가지를 더합니다. 측정하지 않은 값은 추정해서 채우지 않고 '미측정'으로 남깁니다. 보고서의 모든 수치는 실제로 실행한 계산 출력과 같아야 하고, 문장 속 숫자를 손으로 고치지 않습니다.

근거: seminar-flow-60min.md D절. 과거 시연 기록입니다. 수집·검사는 Python 코드, 자격·계획서 작성은 워크스페이스 명령, 조사는 에이전트가 수행했습니다. 과거 실행에 지금 소개하는 특정 플러그인이 모두 쓰였다고 단정하지 않습니다.

[설명할 것] - 2026-08-04 KBSI 세미나용 과거 시연 기록 — 38건은 현재 모집 공고 수가 아님 - 가상 프로필로 실제 공고를 판정해 통과 1건 - 형식 통과 ≠ 사실 확인: 법령 오독과 비용 계산 모순이 나옴 - 과거 실행에 오늘 소개하는 플러그인이 모두 쓰였다고 단정하지 않음 [대본] 이 장은 예전에 KBSI 세미나에서 보여 드린 시연 기록입니다. 접수 중이거나 예정인 공고 38건을 모으고, 가상 프로필로 자격을 판정했더니 통과가 1건이었습니다. 이 숫자는 그때 기록이고 지금 모집 중인 공고 수가 아닙니다. 수집과 검사는 Python 코드가, 자격 판정과 계획서 작성은 워크스페이스 명령이, 조사는 에이전트가 맡았습니다. 여기서 꼭 보셔야 할 것은 아래 분홍 상자입니다. 형식 검사를 통과한 문서에서도 법령을 잘못 읽은 곳과 비용 계산이 서로 맞지 않는 곳이 나왔습니다. 검사 코드는 형식을 확인하고, 원문과 사실은 사람이 확인해야 합니다. 오후에 공고 적합도를 돌려 보면 대부분 부적합이나 부분으로 나오는데, 그것도 같은 맥락으로 보시면 됩니다.

플러그인 정본: github.com/fivetaku/gptaku_plugins, _research/gptaku-plugins-rnd.md. 도구 기획 뒤 goaljaby·pumasi 같은 후속 도구도 가능하지만 본편은 참가자가 직접 쓰는 세 가지에 집중합니다.

[설명할 것] - 조사·공고·코드·도구 기획·스킬·교차 검토의 여섯 가지 조합 - 각 작업이 남기는 파일을 확인하는 것이 핵심 - 오후에 내 자료로 워크스페이스를 만들어 직접 사용 [대본] 오후에 직접 써 볼 조합을 표로 정리했습니다. 자료 읽기와 조사, 공고 찾기와 적합도, 분석 코드 고치기, 도구 기획, 반복 업무를 스킬로 묶기, 결과 교차 검토까지 여섯 가지입니다. 오른쪽 칸이 중요합니다. 각 작업이 끝나면 문헌표, 판정표, 기획 문서처럼 무엇이 파일로 남는지를 보시면 됩니다. 플러그인 이름보다 남은 파일과 근거를 확인하는 습관이 오후 실습에서도 계속 이어집니다. 오후에는 내 자료로 워크스페이스를 만들고 이 조합으로 논문부터 공고 적합도, 기획서까지 해 봅니다.

시연은 예시 프로필(가상 관심 주제 연구자)로 /scenario 결과 파일을 엽니다. 라이브로 돌리면 몇 분 걸리므로 미리 돌린 결과를 보여 주고, 시간이 남으면 /paper 를 라이브로 시작합니다. 실제 자기 연구로 쓸 때는 기관 AI 규정을 먼저 확인하고, 비공개 항목은 프로필에 [비공개]로 표시하라고 안내합니다.

[설명할 것] - 한 폴더에 담아 두면 명령 이름을 몰라도 됨 — 평소처럼 말하면 Claude Code가 맞는 명령을 골라 실행 - 명령마다 '이럴 때 쓴다'는 설명이 붙어 있어서 가능. 순서를 정확히 정하고 싶을 때만 /lit 처럼 직접 부름 - 강사 PC 확인(10-15): 논문 찾아 줘 → /lit, 시장 있어? → /market, 다음에 뭐 연구하지? → /scenario, 오늘 여기까지 → /wrap - 공고 검색·적합도·계획서 검사는 /grant, /proposal 로. 증빙 없는 보유는 검사 스크립트가 잡음 - 폴더 신뢰를 허용하면 플러그인 6개 자동 등록. /scenario 는 예시 프로필로 미리 돌린 결과를 보여 줌 [대본] 앞의 조합을 한 폴더에 담은 것이 research-planner입니다. 화면에 명령 이름이 보이지만, 이걸 외워서 차례로 치셔야 하는 건 아닙니다. 명령마다 '이럴 때 쓴다'는 설명이 붙어 있어서, 평소처럼 '이 주제 논문 찾아 줘', '시장 있어?', '다음에 뭐 연구하지?'라고 말하면 Claude Code가 알아서 맞는 명령을 꺼내 씁니다. 오늘 아침 제 PC에서 이렇게 말로만 요청해 봤더니 선행연구, 시장 조사, 주제 비교, 기록 정리 명령이 각각 알아서 실행됐습니다. 순서를 정확히 정하고 싶을 때만 명령 이름을 직접 부르시면 됩니다. 앞에서 본 research-lab의 공고 검색과 적합도 판정, 계획서 검사도 /grant와 /proposal로 옮겨 왔고, 증빙 없이 '보유'라고 적으면 검사 스크립트가 잡습니다. 폴더를 열 때 신뢰 창에서 허용하면 플러그인 여섯 개도 자동으로 등록됩니다. 주제 판단 결과는 예시 프로필로 미리 돌려 둔 파일을 열어 보여 드리겠습니다.

네트워크·로그·모델 다운로드 등 전체 경로까지 기관이 승인해야 합니다. 로컬 LLM 단독으로 비식별화 완료를 판정하지 않습니다. 오늘은 공개·가상 자료만 사용합니다.

[설명할 것] - 자료를 넣기 전에 기관의 AI 사용 지침부터 확인 - 로컬 모델은 보조 수단 — 민감 정보를 놓칠 수 있고, 거쳤다고 외부 전송이 허용되지 않음 - 반출할 수 없는 자료는 외부 AI에 넣지 않음 - 그림은 설계 예시이며 자동 익명화를 보장하지 않음 [대본] 자료를 AI에 넣기 전에는 기관의 사용 지침부터 확인하셔야 합니다. 그림은 내부 자료를 분류하고, 내부에서 민감 정보 후보를 찾고, 사람이 검토해 승인한 것만 승인된 AI로 보내는 흐름입니다. 이것은 적용을 검토해 볼 설계 예시이지, 이렇게 하면 자동으로 익명화된다는 뜻이 아닙니다. 로컬 모델은 보조 수단일 뿐이어서 민감 정보를 놓칠 수 있고, 로컬 모델을 거쳤다고 외부 전송이 허용되는 것도 아닙니다. 네트워크와 로그, 모델 다운로드까지 전체 경로를 기관이 승인해야 합니다. 반출할 수 없는 자료는 외부 AI에 넣지 않고 승인된 내부 환경에서만 다룹니다. 오늘은 공개 자료와 가상 자료만 씁니다.

생성 일러스트. API·SDK가 없는 장비도 있습니다. 통신 기능과 라이선스부터 확인합니다. MCP는 모델과 외부 도구를 연결하는 규약이며 그 자체가 안전장치는 아닙니다.

[설명할 것] - 전: 제조사 프로그램 기능에 맞춰 일함 / 후: 공개 매뉴얼·SDK로 필요한 기능을 만듦 - API·SDK가 없는 장비도 있으니 통신 기능과 라이선스부터 확인 - MCP는 연결 규약이지 그 자체로 안전장치가 아님 - 생성 일러스트 [대본] 지금까지는 제조사 프로그램이 제공하는 기능에 맞춰 일하고, 없는 기능은 기다리거나 손으로 처리했습니다. 이제는 공개된 매뉴얼과 SDK를 AI와 함께 읽고, 내 측정 순서와 기록, 보고서 양식에 맞는 프로그램을 직접 만드는 쪽으로 옮겨 갈 수 있습니다. 다만 모든 장비에 API나 SDK가 있는 것은 아니니 통신 기능과 라이선스부터 확인하셔야 합니다. AI가 장비를 직접 다루게 할 때는 MCP 같은 도구 통로로 연결합니다. MCP는 모델과 외부 도구를 잇는 규약일 뿐 그 자체가 안전장치는 아니라서, 허용할 명령과 범위는 따로 제한해야 합니다.

[설명할 것] - 24장 이야기를 설계 도구로 넓힘: 장비뿐 아니라 CAD도 공개 API로 반복 작업을 맡김 - AutoLISP·SolidWorks API·iLogic·NX Open·CATIA VBA 모두 텍스트 코드라 AI가 초안을 잘 짬 - CAD API는 방대해서 AI가 없는 함수를 지어내기도 함 — 실행하고 에러를 보여 주며 고치는 반복이 기본 - 매크로 기록으로 한 번 조작한 코드를 AI에게 주면 반복문으로 바꾸기 쉬움. 원본이 아니라 사본 폴더에서 실행 - 지원 범위는 버전·라이선스마다 다름(예: AutoCAD LT의 LISP). 질문이 오면 쓰는 버전부터 확인 [대본] 장비 이야기만이 아닙니다. 설계 도구도 같습니다. 도면 수십 장의 레이어를 정리하거나 표제란을 고치거나, 치수만 바꾼 부품을 여러 개 만드는 일을 손으로 해 보신 분이 많을 겁니다. AutoCAD는 AutoLISP, SolidWorks는 API와 VBA 매크로, Inventor는 iLogic, NX와 CATIA도 각자 자동화 수단을 공개하고 있습니다. 이 코드들은 모두 텍스트라서 AI가 초안을 잘 짭니다. CAD를 켜지 않고 Python으로 DXF 도면을 바로 처리하는 방법도 있습니다. 다만 CAD API는 함수가 아주 많아서 AI가 없는 함수를 지어내기도 합니다. 그래서 순서가 중요합니다. 매크로 기록으로 한 번 조작해 코드를 얻고, AI에게 그걸 반복문으로 바꿔 달라고 하고, 원본이 아닌 사본 폴더에서 돌려 보고, 에러가 나면 그 에러를 그대로 보여 주며 고치게 합니다. 지원 범위는 버전과 라이선스마다 다르니 쓰시는 버전부터 확인하시면 됩니다.

여러분 장비가 어느 쪽인지 먼저 확인하는 것이 출발점입니다. 이 부 끝에 나눠 드리는 체크리스트 1번 문항이 이것입니다.

[설명할 것] - RS-232·USB·TCP/IP(LAN)·제조사 API·SDK의 네 가지 방식 - 계측 제어기의 원격 제어는 유료 옵션이거나 명령 명세가 비공개인 경우가 많음 - 내 장비가 어느 방식인지가 출발점 — 3부 끝 체크리스트 1번 문항 [대본] 시험·계측 장비는 대개 이 네 가지 방식 가운데 하나로 PC와 통신합니다. 구형 계측기는 시리얼, 오실로스코프나 멀티미터는 USB, LAN 계측기는 IP 주소와 포트, 계측 제어기나 DAQ 소프트웨어는 제조사 API나 SDK인 경우가 많습니다. 오른쪽 칸처럼 Python에서는 대부분 PyVISA나 제조사 패키지로 부를 수 있습니다. 주의하실 점은 계측 제어기의 원격 제어가 유료 옵션이거나 명령 명세가 공개되지 않은 경우가 많다는 것입니다. 그래서 내 장비가 어떤 인터페이스를 제공하는지, 라이선스가 있는지를 먼저 확인하는 것이 출발점입니다. 이 내용은 나눠 드리는 체크리스트 1번 문항과 같습니다.

계측 제어기와 전공 해설 대신 범용 수집·자동화 두 사례만 소개합니다.

[설명할 것] - LDAQ: 서로 다른 장비의 데이터 수집을 Python 패키지 하나로 - 브리스톨대: 기존 제어 프로그램을 거쳐 반복 시험·기록 자동화, 실행 전 한계값 확인 - 공개 코드와 저자 설명 기준, 실장비로 재현하지 않음 - 달라진 것은 연결 원리가 아니라 AI와 함께 만들 수 있다는 점 [대본] 사실 공개 API로 수집과 시험을 자동화하는 일은 AI 이전에도 연구실에서 해 왔습니다. 류블랴나대의 LDAQ는 DAQ, Arduino, 열화상 카메라처럼 서로 다른 장비의 데이터 수집을 Python 패키지 하나로 묶었습니다. 브리스톨대 사례는 Python에서 기존 Instron 제어 프로그램을 거쳐 반복 시험과 측정 기록을 자동화했고, 실행 전에 한계값을 따로 확인합니다. 두 사례 모두 공개 코드와 저자 설명을 기준으로 소개하는 것이고, 저희가 실장비로 재현하지는 않았습니다. 연결하는 원리는 그때와 같습니다. 달라진 것은 이런 프로그램을 이제 AI와 함께 만들 수 있다는 점입니다.

네 사례 모두 상한과 검토는 사람이 정했다는 점을 짚습니다. 몽유 사례는 잠시 뒤 질문과 안전 운용 4요건으로 이어집니다.

[설명할 것] - 네 사례 모두 상한과 검토는 사람이 정함 - 모두 당사자·저자 보고이며 재현하지 않음 — 베이항대 82.3%도 저자 보고 - NREL은 Claude Code가 아니라 ChatGPT-4 사례 - 주의 사례: AFM 에이전트의 지시하지 않은 위험한 탐침 이동(Nature Communications 2025) [대본] 이제는 Claude Code 같은 에이전트가 그런 프로그램을 같이 만듭니다. RIKEN 연구원은 현미경 앱을 Python으로 다시 만들었고, 정밀 계측 개인 사용자는 GPIB 계측기 여섯 대의 제어·기록·교정 프로그램을 만들었습니다. NREL은 ChatGPT-4로 소스미터 제어 코드를 만들었고, 베이항대는 시험 의도를 말로 받아 SCPI 코드를 만드는 다중 에이전트에서 저자 보고 기준 82.3%의 실행 성공률을 냈습니다. 표의 오른쪽 칸을 보시면 네 사례 모두 상한과 검토는 사람이 정했습니다. 모두 당사자나 저자가 보고한 내용이고 재현한 것은 아닙니다. 아래 주의 사례도 꼭 보십시오. 원자간력현미경을 조작한 에이전트가 지시하지 않은 위험한 탐침 이동을 했고, 저자들은 이를 '몽유'라고 불렀습니다. 그래서 잠시 뒤 안전 운용 네 가지 요건으로 이어집니다.

제조사 발표만으로 기관 장비의 지원·승인을 가정하지 않습니다. OPC 저장소 정확한 주소는 기존 조사 링크와 대조합니다.

[설명할 것] - Keysight·Tektronix가 AI 요청을 계측기 명령으로 잇는 공개 사례를 냄 - OPC Foundation이 OPC UA와 AI 도구를 잇는 MCP 서버를 공개 - 제조사 발표만으로 기관 장비의 지원·승인을 가정하지 않음 - Tektronix 영상은 원본 링크로 열림(인터넷 필요) [대본] 장비 제조사 쪽에서도 AI가 계측기를 다룰 수 있는 연결 도구를 내놓고 있습니다. Keysight와 Tektronix의 공개 사례는 AI 요청을 계측기 명령으로 바꿔 줍니다. Tektronix 공식 영상은 링크를 누르면 원본으로 열립니다. 산업용 통신 규약인 OPC UA 쪽에서도 OPC Foundation이 AI 도구와 잇는 MCP 서버를 공개했습니다. 다만 제조사가 이런 도구를 발표했다고 해서 우리 기관 장비가 지원되거나 사용이 승인됐다고 보시면 안 됩니다. 도구가 연결된다는 것과 안전하게 운용한다는 것은 별개이니, 쓰더라도 읽기 전용부터 시작하십시오.

[설명할 것] - 에이전트 → MCP 서버(도구 목록) → 드라이버(상한 검사·기록) → 장비 제어기(인터락) - MCP 연결에서도 별도 터미널·네트워크 접근 권한을 함께 제한해야 함 - 읽기는 바로, 장비를 움직이는 명령은 매번 확인 창 - MCP 대신 CLI 도구로 만들어도 됨 [대본] MCP를 쓰면 에이전트가 쓸 수 있는 도구 목록을 장비 쪽에서 정해 줄 수 있습니다. Claude Code가 도구를 고르면, MCP 서버는 상태 조회, 측정값 읽기, 레벨 설정, 비상 정지처럼 공개한 도구만 받아 줍니다. 그 아래 드라이버가 명령을 변환하면서 상한을 검사하고 기록을 남기고, 맨 아래 장비 제어기가 자체 상한을 지키고, 물리 비상 정지 버튼이 있습니다. 다만 MCP만 막아서는 부족하고, 에이전트의 별도 터미널이나 네트워크 접근 권한도 함께 제한해야 합니다. 도구마다 승인을 거치게 할 수 있어서, 읽기는 바로 하고 장비를 움직이는 명령은 매번 확인 창이 뜨게 설정합니다. MCP 대신 명령줄 도구로 만들어도 같은 원리로 쓸 수 있습니다.

카메라에서 읽은 숫자에는 오독 가능성이 있습니다. 공식 API나 센서 데이터가 있으면 먼저 활용하고 사진으로 주변 맥락을 보완합니다. 센서를 붙였다는 사실만으로 시뮬레이터가 되는 것은 아닙니다.

[설명할 것] - 시뮬레이터는 필수가 아님 — 먼저 현재 상태를 읽음 - 사진·화면에서 읽은 숫자는 오독 가능성이 있음 — 공식 API·센서 데이터를 먼저 쓰고 사진으로 보완 - 값의 단위·측정 시각·누락 여부를 먼저 확인 - 센서를 붙였다는 사실만으로 시뮬레이터가 되지 않음 [대본] 장비에 AI를 붙인다고 하면 시뮬레이터부터 떠올리시는 경우가 많은데, 필수는 아닙니다. 먼저 현재 상태를 읽는 것부터 시작합니다. 방법은 두 가지입니다. 사진이나 화면에서 표시창 숫자, 계기 바늘, 경고등을 읽는 방법과, 센서나 장비 API에서 값을 직접 받는 방법입니다. 카메라로 읽은 숫자는 잘못 읽을 수 있으니, 공식 API나 센서 데이터가 있으면 그것을 먼저 쓰고 사진은 주변 맥락을 보완하는 데 씁니다. 어느 쪽이든 값의 단위와 측정 시각, 빠진 값이 없는지를 먼저 확인합니다. 그리고 센서를 붙였다고 해서 그것이 곧 시뮬레이터가 되는 것은 아닙니다.

일반적인 시스템 설계 설명이며 구축 완료 사례가 아닙니다. 센서 수집과 디지털 트윈은 같은 말이 아닙니다. 실시간 상태와 모델을 연결하고 유효 범위를 검증해야 합니다. 빠른 제어와 하드웨어 안전은 모델 추론과 분리합니다.

[설명할 것] - 일반적인 시스템 설계 설명이며 구축 완료 사례가 아님 - 상태 조회·알림·이상 후보 찾기는 시뮬레이터 없이 시작 가능 - 예측을 조작 근거로 쓰려면 실측과 대조해 모델 오차 확인, 예측 성공이 안전을 보장하지 않음 - 센서 수집과 디지털 트윈은 같은 말이 아님 [대본] 반면 '이 값을 바꾸면 어떻게 될까'를 예측하려면 물리식이나 경험식, 시뮬레이터 같은 모델이 더 필요합니다. 이 그림은 일반적인 설계 설명이고, 어딘가에 구축이 끝난 사례는 아닙니다. 기록, 점검, 이상 후보 찾기는 완전한 시뮬레이터 없이도 시작할 수 있습니다. 하지만 예측 결과를 장비 조작의 근거로 쓰려면 실측과 대조해서 모델 오차를 먼저 확인해야 합니다. 예측이 맞았다고 실제 안전이 보장되는 것은 아닙니다. 센서로 값을 모으는 것과 디지털 트윈은 같은 말이 아니고, 빠른 제어와 하드웨어 안전은 모델 추론과 분리해 둡니다.

질문 정답(③)을 여기서 설명합니다. 상한은 제어기와 드라이버, 승인은 Claude Code 권한 창, 기록은 로그와 훅입니다.

[설명할 것] - 1 동작 전 사람 승인, 2 동작 상한값 제한, 3 비상 정지와 중단, 4 명령과 결과 기록 - 상한과 정지는 에이전트가 고칠 수 없는 드라이버와 제어기에 둠 - 승인은 Claude Code 권한 창, 기록은 드라이버 로그와 훅 - 기관 장비의 운용 안전수칙을 대신하지 않음 - 비상 정지는 물리 버튼이 반드시 있어야 함. 소프트웨어 정지 도구는 그 위에 더하는 것 [대본] 장비를 에이전트에 연결할 때는 이 네 가지를 기본 요건으로 둡니다. 장비를 움직이는 명령은 사람이 확인한 뒤에만 보내고, 움직임과 출력에는 상한을 두고, 이상이 보이면 즉시 멈추고, 누가 언제 무엇을 보냈는지 기록합니다. 여기서 핵심은 어디서 지키느냐입니다. 상한과 정지는 에이전트가 고칠 수 없는 장비 제어기와 드라이버 코드에 두고, 승인과 기록을 그 위에 더합니다. 승인은 Claude Code 권한 창에서, 기록은 드라이버 로그와 훅에서 남깁니다. 비상 정지는 장비 옆의 물리 버튼이 반드시 있어야 합니다. 소프트웨어로 부르는 정지는 그 위에 더하는 것이고, 승인 없이 부를 수 있어야 합니다. 이 네 가지는 기관 장비의 운용 안전수칙을 대신하지 않습니다. 가상 장비로 이 네 가지를 확인하는 것은 오후 더 해 보기에서 선택으로 해 볼 수 있습니다.

[설명할 것] - 매뉴얼·연결 정보 확보 → 필요한 명령만 드라이버 → 모의·읽기 전용 시험 → 상한·승인·이력 → MCP나 CLI로 등록 - 명령마다 매뉴얼 쪽수를 주석으로 달게 함 - 오래된 제조사 예제는 매뉴얼을 주고 현행 라이브러리로 다시 짜게 할 수 있음 [대본] 장비 기능을 에이전트 도구로 만드는 일반 절차는 다섯 단계입니다. 먼저 프로그래밍 매뉴얼과 연결 정보를 확보합니다. 다음으로 필요한 명령만 골라 에이전트에게 드라이버를 짜게 하는데, 명령마다 매뉴얼 쪽수를 주석으로 달게 하면 나중에 확인하기 쉽습니다. 그다음 가상 장비나 조회 명령으로만 먼저 돌려 보고, 동작 명령에 상한과 사람 승인, 명령 기록을 넣습니다. 검증이 끝난 드라이버를 MCP 서버나 명령줄 도구로 감싸서 다시 쓰게 합니다. 써 보신 분께 한 가지 덧붙이면, 제조사 공식 예제가 오래됐을 때 매뉴얼을 주고 현행 라이브러리로 다시 짜게 하는 것도 같은 절차이고, 이때 docs-guide로 공식 문서를 함께 확인하게 하시면 됩니다.

[설명할 것] - 원격 제어 방식·라이선스·명령 명세·데모 모드·데이터 형식·상한과 정지 위치·네트워크·먼저 자동화할 일 - 개인용 체크리스트 — 작성 내용은 외부 AI에 입력하지 않음 - 오후 실습은 장비 정보 없이 공개 주제로 진행 - 1~4번이 채워진 분은 더 해 보기에서 모의 장비 드라이버에 읽기 명령 추가 [대본] 이 체크리스트는 가져가서 쓰시는 용도입니다. 원격 제어 지원 여부, 라이선스, 명령 명세, 데모 모드, 데이터 파일 형식, 상한이 설정된 위치와 물리 비상 정지 버튼의 위치, 네트워크 연결, 그리고 먼저 자동화하고 싶은 일 하나까지 여덟 가지를 확인합니다. 여기에 적는 내용은 기관 장비 정보이므로 외부 AI에는 입력하지 않습니다. 오후 실습은 장비 정보 없이 공개 주제로 진행합니다. 1번부터 4번까지 채워진 분은 오후 더 해 보기에서 모의 장비 드라이버에 읽기 명령을 하나 더해 보셔도 좋습니다. 기관에 돌아가 내 장비로 같은 절차를 밟으실 때 이 표를 출발점으로 쓰시면 됩니다.

[설명할 것] - 4부: 로봇에서 AI가 쓰이는 자리와 안전을 두는 자리 - 3부 장비 안전 요건과 같은 구조로 연결 [대본] 4부는 피지컬 AI입니다. 로봇에서는 AI가 어디에 쓰이고, 안전은 어디에 두는지를 보겠습니다.

[설명할 것] - LLM 이전 로봇 제어 네 가지: 티칭 펜던트로 가르치기, 로봇 언어·PLC로 순서 짜기, 센서 피드백 제어(PID), 인터락·펜스·물리 비상 정지 - 기계공학 청중이 아는 내용 — 제어공학·메카트로닉스 시간에 본 것 - 바뀐 것은 맨 위 '다음에 무엇을 할지' 고르는 일뿐. 제어와 안전은 그대로 아래에 남음 → 다음 장의 구조로 이어짐 [대본] LLM이 나오기 전에는 로봇을 어떻게 움직였는지부터 보겠습니다. 산업용 로봇은 티칭 펜던트로 위치를 하나씩 저장해 두고 그대로 반복했습니다. 용접, 도장, 조립 라인이 이 방식입니다. 작업 순서와 조건 분기, 예외 처리는 로봇 언어나 PLC 시퀀스로 사람이 직접 짰습니다. 그 아래에서는 센서 피드백으로 위치와 속도와 힘을 맞추는데, 제어공학 시간에 배운 PID가 여기서 쓰입니다. 맨 아래에는 인터락, 안전 펜스와 라이트 커튼, 물리 비상 정지 버튼이 있어서 프로그램과 상관없이 멈춥니다. LLM이 들어오면서 바뀐 것은 다음에 무엇을 할지를 사람이 미리 다 짜 두는 대신 AI가 상황을 보고 고르는 부분입니다. 제어와 안전은 그대로 아래에 남습니다. 다음 장이 그 구조입니다.

[설명할 것] - 로봇 업계 공식 자료의 공통 구조: 판단하는 AI(천천히) / 동작을 만드는 모델·코드(빠르게) / 모터 제어·인터락·물리 비상 정지(가장 빠르게) - 위에서 판단이 틀려도 맨 아래 제어·안전에서 멈춤 — 앞의 장비 4요건과 같은 생각 - Figure Helix, NVIDIA GR00T, Gemini Robotics, π0.6 공식 자료 기준. 성능 수치는 인용하지 않음 [대본] 로봇 회사들의 공식 자료를 보면 공통된 구조가 있습니다. 맨 위에서는 AI가 상황을 보고 다음에 할 일을 고릅니다. 이 판단은 비교적 천천히 이뤄집니다. 그 아래에서는 고른 일을 관절과 바퀴의 실제 움직임으로 바꾸는데, 이건 훨씬 빠르게 돌아야 합니다. 맨 아래에는 모터 제어, 인터락, 물리 비상 정지 버튼이 있습니다. 위에서 AI 판단이 틀려도 여기서 멈추게 하는 구조입니다. 네 회사 모두 멈추는 장치를 맨 아래 제어에 두고, 위의 AI도 정지를 부를 수 있게 했다고 설명합니다. 앞에서 본 장비 연결 네 가지 요건과 같은 생각입니다. 각 회사의 성능 수치는 일부러 인용하지 않았습니다.

영상은 인터넷으로 틉니다(1분 42초). 오전 1부의 Claude Code 동작 방식(계획 → 실행 → 확인)과 같은 구조라는 점을 짚습니다.

[설명할 것] - 계획 모델(ER)이 단계를 나누고 도구를 부름, 행동 모델(VLA)이 팔 움직임으로 바꿈, 제어기가 안전 장치 - 일반 개발자에게 API로 공개된 것은 계획 모델(ER)뿐 - 공식 문서: 로봇 주변의 안전한 환경 유지는 사용자 책임 - 1부의 계획 → 실행 → 확인 구조와 같음, 영상은 인터넷으로 열기 [대본] Gemini Robotics는 계획하는 모델과 움직이는 모델을 나눠 둡니다. 사람이 '내 지역 규칙대로 쓰레기를 나눠 줘'라고 하면, 계획 모델이 장면을 보고 단계를 나누고 필요하면 검색 같은 도구를 부릅니다. 행동 모델은 단계마다 받은 짧은 지시를 팔의 움직임으로 바꾸고, 로봇 제어기는 모터를 돌리면서 충돌 회피 같은 안전 장치를 지킵니다. 1부에서 본 Claude Code의 계획, 실행, 확인 구조와 같은 모양입니다. 일반 개발자에게 API로 공개된 것은 계획 모델뿐이고, 공식 문서에는 로봇 주변의 안전한 환경 유지는 사용자 책임이라고 적혀 있습니다. 영상은 이미지를 누르면 인터넷으로 열립니다.

[설명할 것] - 2025-03 Gemini Robotics → 2025-06 On-Device → 2025-09 1.5 → 2026-07 2 - 회사도 여러 손가락 정밀 작업과 동작 속도는 아직 개선이 필요하다고 적음 - 시연 데이터가 비싸 시뮬레이션·사람 영상으로 메우고, 시뮬레이션과 현실의 차이를 한계로 적음 - 영상은 이미지를 눌러 원본 링크로 열기 [대본] Gemini Robotics의 발전 흐름을 보겠습니다. 처음에는 종이접기와 책상 정리를 했고, 이어 네트워크 없이 로봇 안에서 도는 버전이 나왔고, 1.5에서는 한 로봇에서 배운 동작을 다른 로봇에 옮겼습니다. 2026년 7월 버전에서는 휴머노이드가 전신 동작으로 방을 정리하고 여러 로봇이 일을 나눠 완성합니다. 영상은 이미지를 누르면 원본으로 열립니다. 다만 회사 스스로도 여러 손가락으로 하는 정밀 작업은 아직 어렵고 속도도 개선이 필요하다고 적었습니다. 실제 시연 데이터가 비싸서 시뮬레이션과 사람 영상으로 메우는데, 시뮬레이션과 현실의 차이도 한계로 적혀 있습니다. 발전 속도와 함께 이런 한계 표기를 같이 보시면 좋겠습니다.

다음 5부 Jev도 같은 구조입니다: 코드가 정한 선택지 중 하나를 고릅니다.

[설명할 것] - Gemini가 부를 수 있던 도구는 GoTo·TakePicture·pickup·PutDown 네 개 - 걷기·길찾기·잡기는 Spot 기존 소프트웨어가 맡음 - Boston Dynamics: API에 있는 것 이상으로 Spot을 제어할 수 없음, 아직 실험 단계 - 시험 장비로 옮기면 도구 목록은 드라이버가 허용한 명령, 상한과 정지는 제어기 [대본] 이 사례는 AI가 로봇을 어디까지 움직일 수 있는지를 잘 보여 줍니다. Boston Dynamics가 Spot에 Gemini를 붙였을 때, Gemini가 부를 수 있던 도구는 이동, 사진 찍기, 집기, 내려놓기 네 개뿐이었습니다. 걷기와 길찾기, 잡기 동작은 Spot의 기존 소프트웨어가 맡았습니다. 회사는 Gemini가 API에 있는 것 이상으로 Spot을 제어할 수 없다고 적었고, 아직 실험 단계라고 밝혔습니다. 이것을 시험 장비로 옮기면, 도구 목록은 드라이버가 허용한 명령이고 상한과 정지는 제어기가 지키는 구조입니다. 3부에서 본 장비 연결 구조와 같습니다. 다음 5부의 Jev도 코드가 정한 선택지 중 하나를 고른다는 점에서 같은 구조입니다.

[설명할 것] - 5부: 모델은 선택지에서 고르고, 빠른 제어와 안전은 아래 계층이 맡음 - 영상은 공식·커뮤니티 데모 구분을 유지 [대본] 5부는 Jev입니다. 모델은 선택지에서 고르기만 하고, 빠른 제어와 안전은 아래 계층이 맡는 예를 보겠습니다.

[설명할 것] - Jev(TypeSafe, 2026-09-15 공개)는 글을 쓰지 않고 코드가 정한 선택지 하나와 확률을 돌려줌 - 응답 약 70~500ms - 회사 스스로 숫자 세기·산술·날짜 비교에 약하다고 밝힘 - 그래서 제어기 위에서 빠르게 판단하는 자리에 놓임 [대본] Claude나 GPT 같은 대화형 모델은 문장을 써서 답하고, 중간 과정을 글로 따져 볼 수 있습니다. 대신 선택지 하나를 고르는 데도 시간이 걸립니다. Jev는 글을 쓰지 않습니다. 코드가 미리 정해 준 선택지 가운데 하나와 그 확률을 돌려주고, 응답은 약 70에서 500ms 사이입니다. 회사 스스로 숫자 세기, 산술, 날짜 비교에는 약하다고 밝혔습니다. 그래서 Jev는 제어기 위에서 빠르게 판단하는 자리에 놓입니다. 다음 영상들도 이 구조로 보시면 됩니다.

마리오 작성자 보고 성공률은 약 4번 중 1번입니다. Doom은 거리·각도 글을 받아 네 질문을 동시에, 마리오는 버튼 7개와 위험 질문으로 판단합니다. "장비 상태값을 글로 넘기고 다음 조작을 고른다"로 바로 옮겨 설명합니다. 영상의 한계 표기 자체가 교육 포인트입니다: 데모 영상을 볼 때는 누가 올렸는지, 몇 번 중 몇 번 되는지를 확인합니다.

[설명할 것] - Doom은 공식 데모, 슈퍼마리오는 커뮤니티 데모 - 마리오 작성자 보고 성공률은 약 4번 중 1번 - 데모 영상은 누가 올렸는지, 몇 번 중 몇 번 되는지를 확인 - 장비 상태값을 글로 넘기고 다음 조작을 고르는 구조로 옮겨 생각 [대본] 두 영상 모두 게임 상태를 글로 넘기면 Jev가 다음 조작을 고르는 구조입니다. Doom은 적과의 거리와 각도를 글로 받아 네 가지 질문에 동시에 답하는 공식 데모이고, 마리오는 버튼 일곱 개와 위험 여부를 판단하는 커뮤니티 데모입니다. 마리오는 작성자가 보고한 성공률이 약 네 번 중 한 번입니다. 이 점이 오히려 교육 포인트입니다. 데모 영상을 보실 때는 누가 올렸는지, 몇 번 중 몇 번 되는지를 꼭 확인하십시오. 게임 대신 장비 상태값을 글로 넘기고 다음 조작을 고르게 한다고 바꿔 생각하시면 됩니다. 영상은 누르면 원본으로 열립니다.

[설명할 것] - 비행 제어·안전은 코드(초당 약 500번), 전술 판단은 Jev(초당 약 2~3번) - 응답이 70~500ms 걸리는 모델에게 실시간 제어를 맡기지 않음 - MuJoCo 물리 시뮬레이션 데모, 주기 수치는 저자 보고 값이며 재측정하지 않음 [대본] 드론 영상은 판단과 제어를 나누는 구조를 수치로 보여 줍니다. 비행 제어와 안전은 코드가 초당 약 500번 돌리고, Jev는 '앞의 장애물을 비켜야 하나' 같은 판단만 초당 약 두세 번 합니다. 응답에 70에서 500ms가 걸리는 모델에게 실시간 제어를 맡기지 않는다는 뜻입니다. 판단 주기와 제어 주기는 수백 배 차이가 납니다. 이 영상은 MuJoCo 물리 시뮬레이션 데모이고, 주기 수치는 저자가 보고한 값으로 저희가 다시 재지는 않았습니다. 포스터를 누르면 영상이 열립니다.

[설명할 것] - 양팔 로봇: Jev가 다음 동작을 고르고 역기구학과 물리는 코드가 계산, MuJoCo 시뮬레이션 - 모델 비교 영상의 결정 시간·비용 수치는 게시자 화면 기준 - 둘 다 커뮤니티 데모, 저자 보고 [대본] 로봇 팔도 같은 구조입니다. 양팔 로봇은 '파란 블록을 빨간 상자에'라는 지시를 받으면 Jev가 미리 만든 동작 목록에서 다음 동작을 고르고, 역기구학과 물리 계산은 코드가 맡습니다. 이것도 MuJoCo 시뮬레이션입니다. 오른쪽은 같은 로봇 팔 과제를 Jev와 대화형 모델로 풀어 결정 시간과 비용을 비교한 게시자 영상인데, 수치는 게시자 화면 기준이라 따로 말씀드리지 않겠습니다. 두 영상 모두 커뮤니티 데모입니다. 영상은 원본 링크로 열립니다.

[설명할 것] - Claude Code: 파일 읽기·실행·결과를 파일로, 규칙과 절차를 담으면 워크스페이스 - 연구 업무: 계산은 코드, 서술은 AI, 판정은 사람, 다른 방법으로 검산 - 플러그인 조합으로 맡기고 결과를 파일로 남김 - 장비: 상한과 정지는 에이전트가 바꿀 수 없는 드라이버와 제어기에 [대본] 오전에 본 내용을 네 줄로 정리하겠습니다. Claude Code는 내 폴더의 파일을 읽고, 코드를 실행하고, 결과를 파일로 남기는 에이전트이고, 규칙과 절차를 폴더에 담으면 워크스페이스가 됩니다. 연구 업무에서는 계산은 코드에, 서술은 AI에, 판정은 사람에게 나눠 맡기고 다른 방법으로 검산합니다. 조사, 코드, 도구 기획, 스킬, 교차 검토는 플러그인 조합으로 맡기고 결과를 파일로 남깁니다. 장비는 제조사가 공개한 통신 방법으로 직접 프로그램을 만들 수 있지만, 상한은 에이전트가 바꿀 수 없는 드라이버와 제어기에 두고, 물리 비상 정지 버튼은 반드시 둡니다.

오후 실습 1은 빈 폴더에서 바로 시작하고, 실습 2부터는 /lab2~/lab4 스킬로 시작합니다. 처음 쓰는 분은 강사 자료로 따라 하고, 써 본 분은 자기 공개 자료(논문, 학회 발표, 공개 보고서) 10개 이내를 넣습니다. 기관 내부 자료는 넣지 않습니다. 오후 시작 시각과 쉬는 시간은 현장에서 안내합니다.

[설명할 것] - 실습 1은 빈 폴더에서 바로, 실습 2부터는 /lab2~/lab4 스킬로 시작 - 준비: kimm.axwith.com 안내 페이지, 앱 로그인 - 써 본 분은 내 공개 자료(논문·학회 발표·공개 보고서) 10개 이내, 기관 내부 자료는 넣지 않음 - 오후 시작과 쉬는 시간은 현장에서 안내 [대본] 오후에는 각자 PC에 연구 워크스페이스를 직접 세팅합니다. 실습 1은 빈 폴더에서 처음 맡겨 보고, 실습 2부터는 /lab2에서 /lab4까지 스킬로 시작합니다. 인터뷰와 내 자료로 워크스페이스를 만들고, 주제 하나로 논문과 공고 적합도, 기획서까지 간 뒤, 스킬과 기록 자동화로 계속 쓰는 방법을 해 봅니다. 준비하실 것은 실습 안내 페이지 kimm.axwith.com과 앱 로그인입니다. 써 보신 분은 본인의 공개 자료, 그러니까 논문이나 학회 발표, 공개 보고서를 10개 이내로 준비해 주십시오. 기관 내부 자료는 넣지 않습니다. 오후 시작과 쉬는 시간은 현장에서 안내드리겠습니다.

[설명할 것] - 질문 받기 - 오후는 실습 폴더 C:\work\kimm에서 이어짐 [대본] 오전 내용에 대해 궁금하신 점을 받겠습니다. 오후에는 실습 폴더 C:\work\kimm에서 이어 가겠습니다.