AI 로봇 튜터

로봇이 선생님이 되는 순간

지금까지 우리는 로봇에게 명령을 내리고, 로봇이 그 명령을 해석하고, 스킬을 실행하고, 실패하면 다시 계획하는 구조를 만들어 왔다. "빨간 컵을 집어 오른쪽에 놓아줘", "회의실 앞으로 가줘", "잠깐, 멈춰!" 같은 명령은 모두 로봇이 해야 할 일을 향해 있었다.

이번 장에서는 시선을 조금 바꿔 보자. 로봇이 작업만 수행하는 것이 아니라, 자신이 무엇을 하고 있는지 설명한다면 어떨까? 카메라가 무엇을 보았는지, 로봇팔이 어디로 움직였는지, 왜 경로 계획이 실패했는지, 그리퍼가 왜 물체를 놓쳤는지 학습자에게 차근차근 알려 준다면 어떨까?

이때 로봇은 단순한 기계가 아니라 실험실 조교가 된다. 학습자가 코드를 고치고, 센서값을 확인하고, 파라미터를 바꾸며 실험하는 동안 로봇은 옆에서 이렇게 말할 수 있다.

"현재 목표는 빨간 컵을 집는 것입니다. 객체 검출 모델은 컵을 0.82 신뢰도로 찾았습니다. 하지만 깊이값이 일부 누락되어 3D 위치 추정이 불안정합니다. 먼저 깊이 카메라 화면에서 컵 주변 픽셀이 비어 있는지 확인해 보세요."

이것이 AI 로봇 튜터의 출발점이다. AI 로봇 튜터는 로봇을 대신 조종해 주는 존재가 아니다. 학습자가 로봇 시스템을 이해하고, 실패 원인을 찾고, 다음 실험을 설계하도록 돕는 교육용 에이전트다.

AI 로봇 튜터의 세 가지 역할

교육용 로봇 튜터를 설계할 때 가장 중요한 질문은 "로봇이 무엇을 가르칠 것인가?"가 아니다. 더 중요한 질문은 "학습자가 막혔을 때 로봇이 어떤 방식으로 도울 것인가?"이다.

지능형 튜터링 시스템과 로봇 튜터 연구에서는 개인화, 실시간 피드백, 상호작용, 학습자 참여가 중요한 요소로 다루어진다. 소프트웨어 기반 지능형 튜터는 학습자의 수행 데이터를 분석해 난이도와 설명을 조절하는 데 강점이 있고, 로봇 튜터는 물리적 존재감과 사회적 상호작용을 통해 몰입을 높이는 데 강점이 있다¹. 우리가 만들 AI 로봇 튜터는 이 두 흐름을 로봇공학 실험 환경에 맞게 결합한다.

이 책에서 다루는 로봇 튜터는 크게 세 가지 역할을 가진다.

• 설명자: 로봇의 현재 목표, 실행 중인 스킬, 센서 입력, 판단 결과를 학습자가 이해할 수 있는 말로 풀어 준다.

• 진단자: 실험이 실패했을 때 객체 미검출, 좌표 변환 오차, 경로 계획 실패, 파지 실패 같은 원인 후보를 구분한다.

• 피드백 제공자: 학습자의 수준에 맞춰 힌트, 질문, 오류 분석, 다음 실험 제안을 제공한다.

여기서 중요한 점은 튜터가 정답을 바로 던져 주지 않는다는 것이다. 좋은 튜터는 학습자가 스스로 문제를 좁혀 갈 수 있도록 돕는다. "코드를 이렇게 바꾸세요"라고 말하기 전에, "지금 확인해야 할 값은 무엇일까요?"라고 묻는다. "좌표 변환이 틀렸습니다"라고 단정하기 전에, "카메라 좌표와 로봇 베이스 좌표의 축 방향이 일치하는지 확인해 봅시다"라고 안내한다.

로봇 튜터는 친절한 해설자이면서, 동시에 실험을 엄격하게 기록하는 관찰자여야 한다.

상태 설명: 로봇의 속마음을 자연어로 바꾸기

로봇 실험을 처음 하는 학습자가 가장 답답해하는 순간은 로봇이 멈췄을 때다. 화면에는 로그가 빠르게 지나가고, RViz에는 좌표축과 경로가 보이며, 터미널에는 알 수 없는 경고가 쌓인다. 로봇은 분명 무언가를 알고 있는 것 같지만, 사람에게는 아무 말도 하지 않는다.

AI 로봇 튜터의 첫 번째 기능은 이 침묵을 깨는 것이다. 로봇 내부의 여러 상태를 하나로 묶어 "현재 상황 설명"을 만들어야 한다.

상태 설명에는 적어도 다음 정보가 들어간다.

• 현재 목표: 사용자의 명령 또는 과제 목표

• 실행 중인 스킬: detect_object, move_to, pick, place, navigate_to, stop 등

• 로봇 몸 상태: 관절 각도, 엔드 이펙터 좌표, 그리퍼 열림 정도, 속도 제한 상태

• 센서 상태: 카메라 이미지, 객체 검출 결과, 깊이값, 거리 센서, 충돌 센서

• 최근 이벤트: 성공한 단계, 실패한 단계, 재시도 횟수, 마지막 오류 메시지

• 안전 상태: 정지 여부, 충돌 위험, 작업 공간 이탈 여부, 사람 개입 필요 여부

이 정보는 원래 각각 다른 곳에 흩어져 있다. 관절 상태는 /joint_states에서 오고, 카메라 이미지는 이미지 토픽에서 오며, 객체 검출 결과는 비전 노드가 만든다. MoveIt2의 계획 결과는 액션 응답에 있고, 디스패처의 실행 상태는 별도 상태 머신에 있다. 튜터는 이 조각들을 모아 사람이 읽을 수 있는 한 문단으로 바꾼다.

예를 들어 원시 상태가 다음과 같다고 해 보자.

{
  "goal": "빨간 컵을 집어 오른쪽 상자에 놓기",
  "current_skill": "pick",
  "detected_object": {
    "label": "red cup",
    "confidence": 0.82,
    "center_pixel": [412, 238],
    "depth_valid_ratio": 0.61
  },
  "end_effector_pose": {
    "x": 0.42,
    "y": -0.11,
    "z": 0.18
  },
  "gripper": {
    "width": 0.075,
    "force": 2.1
  },
  "last_error": "lift_failed"
}

튜터는 이것을 다음처럼 바꿀 수 있다.

"현재 로봇은 빨간 컵을 집어 오른쪽 상자에 놓는 작업을 수행 중입니다. 지금 단계는 pick입니다. 카메라는 빨간 컵을 0.82 신뢰도로 찾았지만, 컵 주변 깊이값 중 유효한 비율이 0.61로 낮습니다. 로봇팔은 컵 위치로 접근했고 그리퍼를 닫았지만, 들어 올리는 단계에서 실패했습니다. 가능한 원인은 파지 위치가 컵 중심에서 벗어났거나, 깊이 추정 오차 때문에 그리퍼가 컵을 충분히 잡지 못한 것입니다."

이 한 문단은 학습자에게 큰 차이를 만든다. 로그만 보면 "lift_failed"라는 단어 하나만 보이지만, 상태 설명을 보면 무엇을 확인해야 할지 보인다.

센서 품질까지 설명해야 한다

로봇 AI에서 센서는 눈과 귀에 해당한다. 센서가 흔들리면 인식이 흔들리고, 인식이 흔들리면 계획도 흔들린다. 로봇 시스템, 특히 머신러닝과 AI가 들어간 로봇 시스템의 성능은 센서가 제공하는 데이터 품질에 크게 의존한다².

그래서 튜터는 "컵을 찾았습니다"에서 멈추면 안 된다. "얼마나 확실하게 찾았는지", "어떤 값이 불안정한지", "무엇이 누락되었는지"까지 설명해야 한다.

초보자는 객체 검출 결과에 바운딩 박스가 보이면 로봇이 물체를 정확히 안다고 생각하기 쉽다. 하지만 실제 로봇에서는 그렇지 않다. 바운딩 박스가 컵을 감싸고 있어도 깊이 카메라가 컵의 반짝이는 표면을 잘 읽지 못할 수 있다. 카메라가 흔들리면 중심 픽셀이 프레임마다 조금씩 튈 수 있다. 조명이 바뀌면 빨간 컵의 색이 어둡게 보일 수 있다. 물체가 겹쳐 있으면 세그멘테이션 마스크가 컵과 배경을 함께 포함할 수 있다.

따라서 상태 설명에는 인식 결과와 함께 품질 지표가 들어가야 한다. 예를 들어 객체 검출 신뢰도, 깊이값 유효 비율, 최근 10프레임 동안의 위치 흔들림, 마스크 면적 변화, 카메라 프레임 지연 시간을 함께 보여 줄 수 있다.

튜터의 설명도 이렇게 달라진다.

"컵은 검출되었지만, 중심 위치가 최근 10프레임 동안 약 18픽셀 흔들렸습니다. 이 상태에서 바로 집기 자세를 만들면 로봇 좌표가 몇 센티미터 정도 달라질 수 있습니다. 카메라 고정 상태와 조명을 먼저 확인해 보세요."

이 설명은 단순한 오류 메시지가 아니다. 학습자가 로봇 비전의 본질을 이해하도록 돕는 수업이다. AI 모델이 결과를 냈다고 해서 그 결과가 곧바로 물리 세계의 정확한 좌표가 되는 것은 아니라는 사실을 자연스럽게 배우게 된다.

시간순 실험 리포트 만들기

두 번째 핵심 기능은 실험 리포트다. 실험 리포트는 로봇이 "무엇을 보았고, 어디로 움직였으며, 왜 멈췄는지"를 시간순으로 정리한 기록이다.

로봇 실험은 한 번 실행하고 끝나는 일이 거의 없다. 학습자는 같은 작업을 여러 번 실행하고, 파라미터를 조금씩 바꾸고, 카메라 위치를 조정하고, 보상 함수나 검출 임계값을 고친다. 그런데 기록이 남지 않으면 무엇이 좋아졌고 무엇이 나빠졌는지 알기 어렵다.

좋은 실험 리포트는 영상, 센서값, 로봇 상태, 로그를 하나의 이야기로 엮는다. 예를 들어 Pick and Place 실험이 실패했다면 리포트는 다음과 같은 흐름을 가져야 한다.

1. 사용자가 "빨간 컵을 오른쪽 상자에 놓아줘"라고 명령했다.

2. LLM 플래너가 detect_object, pick, place 순서의 작업 계획을 만들었다.

3. 카메라는 빨간 컵 후보 2개를 찾았고, 가장 가까운 후보를 선택했다.

4. 깊이값을 이용해 컵 중심의 3D 좌표를 계산했다.

5. 카메라 좌표를 로봇 베이스 좌표로 변환했다.

6. MoveIt2가 접근 경로를 계획했고, 충돌 없이 실행했다.

7. 그리퍼가 닫혔지만 힘 센서 변화가 작았다.

8. 들어 올린 뒤 컵 위치가 변하지 않아 빈 파지로 판정했다.

9. 실패 원인은 파지 위치 오차 또는 그리퍼 폭 설정 문제로 추정된다.

이런 리포트는 학습자가 실험을 복기하는 데 매우 유용하다. 특히 팀 프로젝트에서는 "왜 실패했는지"를 두고 서로 다른 추측을 하기 쉽다. 한 사람은 객체 검출 문제라고 생각하고, 다른 사람은 경로 계획 문제라고 생각한다. 리포트가 있으면 논쟁이 데이터 중심으로 바뀐다.

"검출 신뢰도는 충분했지만, 깊이 유효 비율이 낮았다."

"경로 계획은 성공했지만, 실제 파지 후 그리퍼 힘 변화가 거의 없었다."

"좌표 변환 후 목표 위치가 컵 중심보다 y축으로 3.2cm 치우쳐 있었다."

이렇게 말할 수 있게 되면 학습자는 로봇을 감으로 다루지 않는다. 실험을 읽고, 비교하고, 개선한다.

리포트 생성 파이프라인

실험 리포트는 LLM에게 로그 전체를 통째로 던진다고 자동으로 좋아지지 않는다. 먼저 로봇 로그를 교육적으로 의미 있는 사건 단위로 정리해야 한다.

기본 구조는 다음과 같다.

센서/상태 수집기
  → 이벤트 추출기
  → 실험 타임라인 생성기
  → 원인 후보 분석기
  → LLM 리포트 생성기
  → 학습자용 요약/교사용 상세 리포트

센서/상태 수집기는 ROS2 토픽과 액션 결과를 기록한다. 카메라 이미지, 객체 검출 결과, 깊이값, 관절 상태, 엔드 이펙터 위치, 그리퍼 상태, 경로 계획 결과, 안전 컨트롤러 이벤트를 시간과 함께 저장한다.

이벤트 추출기는 원시 로그에서 의미 있는 순간을 찾는다. 예를 들어 "객체 검출 성공", "목표 자세 생성", "경로 계획 실패", "그리퍼 닫힘", "리프트 실패", "사용자 정지 명령" 같은 이벤트다.

타임라인 생성기는 이벤트를 순서대로 묶는다. 로봇 실험에서는 0.1초 단위의 데이터가 많지만, 학습자에게 필요한 것은 모든 숫자가 아니다. 중요한 전환점이다. 튜터는 데이터의 바다에서 학습 순간을 찾아야 한다.

원인 후보 분석기는 실패 단계에 따라 가능한 원인을 좁힌다. 객체 검출 단계에서 실패했다면 카메라, 조명, 모델 임계값을 본다. 좌표 변환 이후 목표 위치가 이상하다면 캘리브레이션과 프레임 이름을 본다. 그리퍼가 닫혔는데 물체가 들리지 않았다면 파지 후보, 그리퍼 폭, 접근 방향, 물체 재질을 본다.

마지막으로 LLM 리포트 생성기는 이 구조화된 정보를 자연어로 바꾼다. 중요한 것은 LLM이 멋진 문장을 쓰는 것이 아니라, 근거 있는 설명을 하는 것이다. 따라서 프롬프트에는 원시 추측보다 구조화된 상태와 이벤트를 넣어야 한다.

예를 들어 LLM에게 다음과 같이 요청할 수 있다.

너는 로봇공학 실험 튜터다.
아래 타임라인과 센서 품질 정보를 바탕으로
학습자에게 실험 결과를 설명하라.

규칙:
- 확인된 사실과 추정 원인을 구분한다.
- 실패 원인은 최대 3개까지만 제시한다.
- 다음에 확인할 센서값과 재실행할 스킬을 제안한다.
- 학습자 수준이 beginner이면 전문 용어 뒤에 짧은 설명을 붙인다.

이런 규칙을 두면 튜터의 설명이 과장되거나 산만해지는 것을 줄일 수 있다.

막힌 학습자를 위한 단계적 힌트

교육용 튜터가 가장 조심해야 할 실수는 너무 빨리 답을 주는 것이다. 학습자가 pick() 함수가 실패했다고 말했을 때 튜터가 바로 "gripper_width를 0.06으로 바꾸세요"라고 답하면 당장은 문제가 해결될 수 있다. 하지만 학습자는 왜 그 값을 바꿔야 하는지 배우지 못한다.

좋은 튜터는 원인 후보를 단계적으로 제시한다. 먼저 관찰할 사실을 알려 주고, 그다음 가능한 원인을 좁히고, 마지막에 수정할 파라미터나 재실행할 스킬을 제안한다.

예를 들어 학습자가 "컵이 안 집혀요"라고 묻는다고 해 보자. 튜터는 이렇게 답할 수 있다.

"먼저 실패가 어느 단계에서 발생했는지 나누어 봅시다. 컵을 못 찾은 것인지, 컵 위치를 잘못 계산한 것인지, 로봇팔 경로가 만들어지지 않은 것인지, 아니면 그리퍼가 닫혔지만 컵을 놓친 것인지 확인해야 합니다."

그다음 튜터는 질문을 이어 간다.

"객체 검출 결과에서 컵의 confidence 값은 얼마였나요?"

"깊이 이미지에서 컵 중심 픽셀의 depth 값이 유효한가요?"

"카메라 좌표를 로봇 좌표로 변환한 뒤, RViz에서 목표 pose가 실제 컵 위에 표시되나요?"

"그리퍼가 닫힌 뒤 force 값이나 finger width 변화가 있었나요?"

이 질문들은 학습자를 귀찮게 하려는 것이 아니다. 로봇 문제를 디버깅하는 사고방식을 가르치는 것이다. 로봇 실패는 하나의 원인으로 설명되지 않는 경우가 많다. 센서, 좌표계, 경로 계획, 제어, 물체 물성, 안전 제한이 함께 얽힌다. 튜터는 그 복잡함을 학습자가 견딜 수 있는 순서로 풀어 주어야 한다.

실패 유형별 진단 카드

실제 구현에서는 실패 유형별로 "진단 카드"를 만들어 두면 좋다. 진단 카드는 특정 실패가 발생했을 때 확인할 값, 가능한 원인, 권장 조치를 정리한 작은 지식 단위다.

튜터는 이 카드를 그대로 읽어 주지 않아도 된다. 학습자 수준에 맞게 풀어서 설명하면 된다.

초보자에게는 "TF 프레임"이라는 말보다 "카메라가 보는 좌표와 로봇팔이 움직이는 좌표를 연결하는 변환 정보"라고 설명하는 편이 낫다. 중급자에게는 base_link → camera_link → camera_color_optical_frame의 TF 체인을 확인하라고 말할 수 있다. 고급자에게는 캘리브레이션 잔차, 변환 행렬, 오차 분포를 비교하게 할 수 있다.

같은 실패라도 학습자에게 주는 피드백은 달라져야 한다.

학습자 수준에 따라 설명 바꾸기

AI 로봇 튜터는 모든 사람에게 같은 답을 주면 안 된다. 처음 로봇팔을 만지는 학생과 ROS2 패키지를 직접 작성하는 개발자는 필요한 설명이 다르다.

학습자 모델은 복잡하게 시작할 필요가 없다. 처음에는 세 가지 수준이면 충분하다.

• beginner: 용어 설명과 관찰 순서를 자세히 제공한다.

• intermediate: 확인할 토픽, 파라미터, 시각화 방법을 함께 제시한다.

• advanced: 로그 분석, 오차 모델, 실험 설계, 개선 가설을 요구한다.

예를 들어 같은 "좌표 변환 오차"에 대해서도 설명은 이렇게 달라질 수 있다.

beginner에게는 이렇게 말한다.

"카메라는 컵의 위치를 카메라 기준으로 계산합니다. 하지만 로봇팔은 자기 베이스 기준으로 움직입니다. 두 기준이 정확히 연결되지 않으면 로봇팔이 컵 옆으로 갈 수 있습니다. RViz에서 목표점이 컵 위에 있는지 먼저 확인해 보세요."

intermediate에게는 이렇게 말한다.

"검출된 컵 중심을 camera_color_optical_frame에서 base_link로 변환한 pose를 RViz에 marker로 표시해 보세요. 실제 컵 위치와 일정한 방향으로 어긋난다면 hand-eye calibration 또는 static transform 값을 의심할 수 있습니다."

advanced에게는 이렇게 말한다.

"10개 이상의 기준점을 사용해 변환 후 위치 오차의 평균과 표준편차를 계산해 보세요. 오차가 특정 축으로 편향되어 있으면 translation 보정이 필요하고, 작업 공간 가장자리에서 오차가 커지면 rotation 또는 카메라 내부 파라미터 문제를 함께 확인해야 합니다."

이처럼 튜터는 같은 정보를 다른 깊이로 전달한다. 이것이 개인화된 교육이다.

최근 교육용 로봇 연구에서는 감정 인식, 기억 기반 개인화, 제스처 같은 요소를 결합해 학습자의 참여를 높이려는 시도도 이루어지고 있다³. 우리가 만드는 로봇 튜터가 반드시 사람처럼 감정을 가져야 하는 것은 아니다. 하지만 학습자의 이전 실험 기록을 기억하고, 반복해서 틀리는 부분을 알아차리고, 답답해하는 상황에서 설명 방식을 바꾸는 기능은 충분히 현실적이고 유용하다.

튜터의 메모리: 이전 실험을 기억하기

로봇 튜터가 정말 유용해지는 순간은 "방금 실험"뿐 아니라 "지난번 실험"까지 기억할 때다.

학습자가 어제는 객체 검출 임계값을 너무 높게 잡아서 컵을 못 찾았고, 오늘은 좌표 변환은 성공했지만 파지점이 어긋났다고 해 보자. 튜터가 이 흐름을 기억하면 더 좋은 피드백을 줄 수 있다.

"지난 실험에서는 컵이 검출되지 않는 문제가 있었지만, 이번에는 검출 confidence가 0.86으로 개선되었습니다. 현재 실패는 인식보다는 파지 후보 생성 단계에 더 가까워 보입니다. 이번에는 grasp pose와 실제 컵 중심의 차이를 확인해 봅시다."

이런 피드백은 학습자에게 성취감을 준다. 모든 실패가 똑같은 실패가 아니라는 것을 알게 한다. 이전보다 나아진 부분과 아직 남은 문제를 구분해 주기 때문이다.

튜터 메모리는 다음 정보를 저장할 수 있다.

• 학습자가 수행한 과제와 실험 횟수

• 각 실험의 성공 여부와 실패 단계

• 자주 발생한 오류 유형

• 학습자가 수정한 파라미터

• 이전 피드백과 다음 실험 제안

• 학습자 수준과 선호하는 설명 방식

물론 메모리는 조심해서 다뤄야 한다. 교육 데이터에는 학습자의 수행 기록이 들어가므로 개인정보와 평가 정보가 섞일 수 있다. 튜터링 시스템 연구에서도 AI 편향, 데이터 프라이버시, 공정한 접근성 같은 윤리 문제가 중요한 쟁점으로 다루어진다⁴. 따라서 학습자 기록은 필요한 범위에서만 저장하고, 누가 볼 수 있는지 명확히 하며, 가능하면 익명화된 실험 데이터와 개인 평가 데이터를 분리해야 한다.

교육용 데모를 스킬과 평가 기준에 연결하기

AI 로봇 튜터는 말만 잘해서는 부족하다. 교육용 과제를 로봇 에이전트의 스킬, 센서 데이터, 평가 기준과 연결해야 한다.

예를 들어 "Pick and Place 과제"를 생각해 보자. 과제 설명은 간단하다.

"카메라로 빨간 컵을 인식하고, 로봇팔로 집어 오른쪽 상자에 놓으세요."

하지만 튜터가 관리하는 학습 목표는 더 세밀하다. 이 과제에는 객체 인식, 3D 위치 추정, 좌표 변환, 경로 계획, 그리퍼 제어, 실패 감지가 모두 들어 있다. 따라서 평가도 단순히 성공/실패로 끝나면 안 된다.

튜터는 다음과 같은 학습 결과를 기록할 수 있다.

이런 평가 기준을 두면 학생은 자신이 어떤 부분을 배웠는지 알 수 있다. "로봇이 컵을 못 집었다"가 아니라 "객체 인식은 좋아졌지만 좌표 변환 오차가 아직 크다"라고 말할 수 있다.

튜터는 과제를 다음 단계로 확장할 수도 있다. 처음에는 색이 뚜렷한 컵 하나만 놓고, 그다음에는 비슷한 물체 여러 개를 놓는다. 이후에는 조명을 바꾸고, 컵 위치를 바꾸고, 일부를 가린다. 마지막에는 자연어 명령으로 "가장 가까운 컵을 조심히 집어서 노트북 오른쪽에 놓아줘" 같은 조건부 작업을 수행하게 한다.

튜터는 각 단계에서 학습자의 부담을 조절한다. 처음에는 성공 경험을 주고, 점차 현실의 복잡함을 추가한다.

실험 데이터는 다음 수업의 재료가 된다

로봇 실험에서 실패 로그는 버려야 할 쓰레기가 아니다. 오히려 가장 좋은 학습 자료다. 로봇은 왜 실패했는지 보여 줄 때 가장 많은 것을 가르친다.

최근 로봇 AI 개발에서는 실제 로봇을 대규모로 운영하면서 원격 시연, 실패 교정, 평가 피드백을 수집하고 이를 다시 모델 개선에 활용하는 흐름이 중요해지고 있다. Tutor Intelligence의 DF1 사례는 100대 로봇을 이용해 실제 환경의 조작 데이터를 모으고, 사람의 개입과 피드백을 통해 로봇 정책을 개선하는 데이터 공장 접근을 보여 준다⁵. 이 사례가 우리에게 주는 메시지는 분명하다. 반복 실험 기록은 단순한 로그가 아니라 로봇이 배우고 사람이 이해하는 기반 데이터다.

교육용 로봇 튜터도 같은 원리를 작게 적용할 수 있다. 한 학생의 실험 로그는 그 학생의 피드백 재료가 된다. 여러 학생의 익명화된 실패 사례는 다음 수업의 예제가 된다. 한 학기 동안 쌓인 Pick and Place 실패 데이터는 "좌표 변환 오차가 클 때 나타나는 패턴", "깊이 센서가 불안정할 때의 영상", "그리퍼 폭이 맞지 않을 때의 힘 변화"를 비교하는 학습 자료가 된다.

예를 들어 튜터는 다음과 같은 실패 사례 라이브러리를 만들 수 있다.

case_001_object_not_detected_low_light
case_002_depth_missing_reflective_cup
case_003_tf_error_y_axis_flipped
case_004_motion_plan_failed_joint_limit
case_005_empty_grasp_wrong_gripper_width
case_006_place_failed_box_pose_shifted

학습자는 자신의 실패와 과거 사례를 비교할 수 있다.

"내 실험은 case_003과 비슷하네요. RViz에서 목표점이 실제 컵의 반대쪽에 찍혔어요."

"내 경우는 case_005와 달라요. 그리퍼 폭은 줄었는데 컵이 미끄러졌으니 마찰이나 접근 방향 문제일 수 있겠어요."

이렇게 되면 실패는 좌절이 아니라 분류하고 분석할 대상이 된다. 로봇 튜터는 실패를 학습 가능한 형태로 바꾸는 번역기다.

AI 로봇 튜터 아키텍처

이제 전체 구조를 정리해 보자. AI 로봇 튜터는 기존 로봇 에이전트 위에 교육 레이어를 얹은 형태로 만들 수 있다.

사용자/학습자
   ↓ 질문, 명령, 실험 요청
튜터 인터페이스
   ↓
학습자 모델 ───────┐
   ↓                │
상태 설명기          │
   ↑                │
로봇 상태 수집기      │
   ↑                │
ROS2 토픽/액션/로그   │
   ↓                │
이벤트 타임라인 생성기 │
   ↓                │
실패 진단기 ─────────┘
   ↓
LLM 설명 생성기
   ↓
힌트, 질문, 리포트, 다음 실험 제안

여기서 LLM은 모든 것을 직접 판단하는 두뇌가 아니다. LLM은 구조화된 로봇 상태와 진단 결과를 학습자가 이해할 수 있는 언어로 바꾸는 설명 생성기다. 실제 판단의 중요한 부분은 여전히 검증 가능한 데이터와 규칙에 기반해야 한다.

예를 들어 "경로 계획 실패"는 LLM이 상상해서 만드는 것이 아니라 MoveIt2 액션 결과에서 확인해야 한다. "객체 검출 신뢰도 낮음"은 비전 모델 출력에서 가져와야 한다. "그리퍼가 물체를 잡지 못함"은 그리퍼 폭, 힘 센서, 리프트 후 물체 위치 변화로 판단해야 한다.

LLM이 잘하는 일은 이 사실들을 연결해 설명하는 것이다.

"경로 계획은 성공했지만 파지가 실패했습니다. 따라서 이번 문제는 로봇팔이 목표 위치까지 가지 못한 문제가 아니라, 목표 위치에서 물체를 안정적으로 잡지 못한 문제에 가깝습니다."

이런 문장은 초보자에게 매우 중요하다. 실패의 범위를 줄여 주기 때문이다.

튜터 인터페이스 설계

튜터는 터미널에만 있으면 안 된다. 교육용으로 쓰려면 학습자가 한눈에 현재 상황을 볼 수 있어야 한다.

간단한 대시보드는 다음 영역으로 구성할 수 있다.

• 현재 목표와 실행 중인 스킬

• 카메라 화면과 객체 검출/세그멘테이션 오버레이

• 엔드 이펙터 위치와 목표 pose 시각화

• 센서 품질 지표와 최근 오류

• 튜터의 자연어 설명과 힌트

• 실험 시작, 일시정지, 재실행, 리포트 생성 버튼

학습자가 "왜 멈췄어?"라고 질문하면 튜터는 가장 최근 실패 이벤트를 기준으로 답한다.

"로봇은 place 단계로 넘어가기 전에 멈췄습니다. pick 단계에서 컵을 들어 올린 뒤 카메라 검증을 수행했는데, 컵이 원래 위치에 그대로 남아 있어 집기 실패로 판단했습니다. 현재 추천하는 확인 순서는 그리퍼 폭, grasp pose, 깊이값입니다."

학습자가 "다음에는 뭘 바꿔야 해?"라고 묻는다면 튜터는 바로 정답을 주기보다 선택지를 제시한다.

"세 가지 실험을 제안합니다. 첫째, 같은 검출 결과로 grasp 후보를 2cm 안쪽으로 이동해 봅니다. 둘째, 그리퍼 닫힘 폭을 현재보다 1cm 줄여 봅니다. 셋째, 컵 중심 대신 세그멘테이션 마스크의 상단 영역을 피해서 옆면을 잡는 후보를 사용해 봅니다. 한 번에 하나씩 바꾸면 어떤 요인이 영향을 주었는지 더 잘 알 수 있습니다."

이 답변에는 로봇공학 실험의 중요한 원칙이 들어 있다. 한 번에 너무 많은 것을 바꾸지 말라는 것이다. 튜터는 단지 로봇을 설명하는 것이 아니라 실험 방법을 가르친다.

구현 예시: 상태 설명 생성기

상태 설명 생성기는 복잡해 보이지만, 처음에는 간단한 규칙 기반 요약으로 시작할 수 있다. 중요한 것은 모든 정보를 LLM에게 바로 넘기기 전에 핵심 상태를 정리하는 것이다.

class RobotStateNarrator:
    def summarize(self, state):
        lines = []

        lines.append(f"현재 목표는 '{state.goal}'입니다.")
        lines.append(f"실행 중인 스킬은 {state.current_skill}입니다.")

        if state.object_detection is not None:
            det = state.object_detection
            lines.append(
                f"카메라는 {det.label}을 신뢰도 {det.confidence:.2f}로 검출했습니다."
            )
            if det.confidence < 0.6:
                lines.append("검출 신뢰도가 낮아 물체 인식 결과가 불안정할 수 있습니다.")

        if state.depth_valid_ratio is not None:
            ratio = state.depth_valid_ratio
            lines.append(f"물체 주변 깊이 유효 비율은 {ratio:.2f}입니다.")
            if ratio < 0.7:
                lines.append("깊이값 누락이 많아 3D 위치 추정 오차가 커질 수 있습니다.")

        if state.last_error:
            lines.append(f"최근 실패 원인은 {state.last_error}로 기록되었습니다.")

        return " ".join(lines)

이 코드는 완성된 튜터가 아니다. 하지만 출발점으로는 충분하다. 여기서 만든 요약을 LLM에게 전달하면 더 자연스러운 설명, 학습자 수준별 힌트, 다음 실험 제안으로 확장할 수 있다.

핵심은 "LLM이 모든 로그를 읽고 알아서 판단하겠지"라고 기대하지 않는 것이다. 로봇 시스템에서는 판단 근거를 명확히 남겨야 한다. 상태 설명기는 그 근거를 정리하는 중간층이다.

구현 예시: 실패 진단기

실패 진단기는 원인 후보를 단계적으로 좁히는 역할을 한다. 처음부터 복잡한 머신러닝 모델을 만들 필요는 없다. 실패 단계별 규칙으로 충분히 유용한 튜터를 만들 수 있다.

def diagnose_failure(event):
    if event.stage == "detect_object":
        return {
            "likely_causes": [
                "객체가 카메라 시야 밖에 있음",
                "검출 임계값이 너무 높음",
                "조명 또는 가림으로 특징이 약해짐"
            ],
            "check": [
                "카메라 원본 이미지",
                "검출 confidence",
                "객체 클래스 이름",
                "조명과 물체 가림 여부"
            ],
            "next_actions": [
                "detect_object 재실행",
                "confidence threshold 낮추기",
                "카메라 각도 조정"
            ]
        }

    if event.stage == "transform_pose":
        return {
            "likely_causes": [
                "카메라-로봇 캘리브레이션 오차",
                "TF 프레임 이름 오류",
                "축 방향 해석 오류"
            ],
            "check": [
                "TF tree",
                "RViz marker 위치",
                "기준점 변환 오차"
            ],
            "next_actions": [
                "static transform 확인",
                "기준점 재측정",
                "목표 pose 시각화"
            ]
        }

    if event.stage == "pick":
        return {
            "likely_causes": [
                "grasp pose가 물체 중심에서 벗어남",
                "그리퍼 폭이 물체 크기와 맞지 않음",
                "접근 방향이 물체 형상과 맞지 않음"
            ],
            "check": [
                "grasp pose",
                "gripper width",
                "force sensor",
                "lift 후 물체 위치"
            ],
            "next_actions": [
                "다른 grasp 후보 선택",
                "그리퍼 폭 조정",
                "접근 방향 변경"
            ]
        }

이런 구조를 만들면 튜터는 매번 완전히 새로운 답변을 생성하지 않아도 된다. 검증된 진단 카드 위에서 자연어 설명만 조절하면 된다. 이것은 안전 측면에서도 좋다. 튜터가 엉뚱한 조치를 제안할 가능성을 줄일 수 있기 때문이다.

튜터가 해도 되는 일과 하면 안 되는 일

AI 로봇 튜터는 학습자를 돕지만, 실제 로봇을 마음대로 움직이면 안 된다. 교육 환경에서는 특히 안전과 책임이 중요하다.

튜터가 해도 되는 일은 다음과 같다.

• 현재 상태를 설명한다.

• 실패 원인 후보를 제시한다.

• 확인할 센서값과 로그를 안내한다.

• 안전한 범위의 파라미터 변경을 제안한다.

• 실험 리포트를 작성한다.

• 다음 과제나 복습 자료를 추천한다.

반대로 튜터가 조심해야 할 일도 있다. 예를 들어 사용자의 확인 없이 로봇팔을 갑자기 움직이거나, 안전 제한을 낮추라고 권하거나, 검증되지 않은 코드를 바로 실행하면 안 된다. 특히 LLM이 생성한 제안은 실행 전에 정책 검증기와 안전 컨트롤러를 거쳐야 한다.

좋은 원칙은 간단하다.

튜터는 먼저 설명하고, 그다음 제안하며, 실행은 사용자의 승인과 안전 검사를 거쳐야 한다.

예를 들어 튜터가 "그리퍼 폭을 0.05m로 줄여 재시도해 보세요"라고 제안했다면, 실제 실행 전에는 다음 조건을 확인해야 한다. 그 값이 로봇 하드웨어 허용 범위 안에 있는지, 물체 크기와 크게 충돌하지 않는지, 현재 사람이 작업 공간 안에 있지 않은지 확인해야 한다.

교육용이라도 로봇은 물리 세계에서 움직인다. 설명은 부드럽게 하되, 실행은 엄격하게 해야 한다.

하나의 수업 예시: 컵 집기 실험

이제 AI 로봇 튜터가 실제 수업에서 어떻게 동작하는지 살펴보자.

학습자가 과제를 시작한다.

"빨간 컵을 집어서 오른쪽 상자에 놓기 실험을 시작할게."

튜터가 응답한다.

"좋습니다. 이번 실험의 학습 목표는 객체 검출 결과를 3D 좌표로 변환하고, 로봇팔의 pick and place 동작과 연결하는 것입니다. 실험 중에는 검출 신뢰도, 깊이 유효 비율, 좌표 변환 오차, 집기 성공 여부를 기록하겠습니다."

로봇이 실행을 시작한다. 카메라가 컵을 찾고, 로봇팔이 접근한다. 하지만 첫 번째 시도에서 컵을 놓친다.

학습자가 묻는다.

"왜 실패했어?"

튜터가 답한다.

"실패는 pick 단계에서 발생했습니다. 객체 검출은 성공했고 confidence는 0.88이었습니다. 경로 계획도 성공했습니다. 하지만 그리퍼가 닫힌 뒤 force 변화가 작았고, 들어 올린 후 컵이 원래 위치에 남아 있었습니다. 따라서 이번 실패는 객체 인식이나 경로 계획보다는 파지 위치 또는 그리퍼 폭 문제일 가능성이 큽니다."

학습자가 다시 묻는다.

"뭘 확인하면 돼?"

튜터는 바로 답을 주지 않고 순서를 제시한다.

"첫째, RViz에서 grasp pose가 컵 중심을 통과하는지 확인해 보세요. 둘째, 그리퍼가 닫히기 전 폭이 컵 지름보다 충분히 넓었는지 확인하세요. 셋째, 닫힌 뒤 finger width가 예상보다 많이 줄었는지 확인하세요. 이 세 가지 중 하나만 먼저 확인해도 원인을 좁힐 수 있습니다."

학습자가 RViz를 확인하고 말한다.

"목표가 컵보다 조금 왼쪽에 찍혀 있어."

튜터가 다음 힌트를 준다.

"그렇다면 grasp 후보 생성 또는 좌표 변환 오차를 의심할 수 있습니다. 같은 컵 위치에서 detect_object를 5번 반복 실행해 중심 좌표가 얼마나 흔들리는지 확인해 보세요. 중심이 안정적인데 목표 pose만 일정하게 왼쪽으로 밀리면 카메라-로봇 변환 보정이 필요할 수 있습니다."

이 대화에서 튜터는 단순히 "캘리브레이션을 고치세요"라고 말하지 않았다. 학습자가 어떤 관찰을 통해 그 결론에 도달해야 하는지 안내했다. 이것이 교육용 튜터의 핵심이다.

교사용 대시보드와 학습 분석

AI 로봇 튜터는 학생만 돕는 것이 아니다. 교사나 연구실 운영자에게도 유용하다. 여러 명의 학습자가 같은 과제를 수행하면, 교사는 누가 어디서 막히는지 한눈에 보기 어렵다. 튜터가 실험 로그를 구조화하면 학습 현황을 더 잘 파악할 수 있다.

교사용 대시보드는 다음 정보를 보여 줄 수 있다.

• 과제별 평균 성공률

• 가장 많이 발생한 실패 단계

• 학생별 재시도 횟수와 개선 추세

• 센서 품질 문제 발생 빈도

• 파라미터 변경과 성공률의 관계

• 자주 묻는 질문과 튜터 응답 기록

예를 들어 한 반의 학생 대부분이 좌표 변환 단계에서 실패한다면, 그 수업에서는 캘리브레이션과 TF 개념을 다시 설명해야 한다. 반대로 객체 검출은 잘되지만 파지가 자주 실패한다면, 그리퍼 접근 방향과 물체 형상에 대한 실습을 추가하는 편이 좋다.

이렇게 튜터는 개별 학습자를 돕는 동시에 수업 자체를 개선하는 도구가 된다.

실패 사례 비교 과제

AI 로봇 튜터를 활용하면 재미있는 교육 과제를 만들 수 있다. 단순히 "성공시키기"가 아니라 "실패를 설명하기"를 과제로 만들 수 있다.

예를 들어 학생에게 세 개의 실험 로그를 제공한다.

• 실험 A: 객체 검출 confidence가 낮고, 컵이 배경과 섞여 있다.

• 실험 B: 객체 검출은 안정적이지만 목표 pose가 실제 컵보다 오른쪽에 있다.

• 실험 C: 목표 pose와 경로 계획은 정상인데 그리퍼가 컵을 놓친다.

학생은 각 실험의 실패 원인을 분류하고, 확인할 센서값과 수정할 파라미터를 제안한다. 튜터는 학생의 답변을 평가한다.

"실험 A를 객체 미검출 문제로 본 것은 적절합니다. 다만 confidence뿐 아니라 조명과 마스크 품질도 함께 확인하면 더 좋습니다."

"실험 B에서 좌표 변환 오차를 의심한 것은 좋습니다. 추가로 RViz marker를 사용해 변환된 목표점을 시각화하라고 제안하면 더 완성도 높은 답변입니다."

"실험 C는 그리퍼 파지 실패에 가깝습니다. 경로 계획을 다시 조정하기 전에 gripper width와 force 변화를 먼저 확인하는 것이 좋습니다."

이런 과제는 로봇공학의 사고방식을 길러 준다. 성공한 데모보다 실패한 로그가 더 좋은 교재가 될 때가 많다.

로봇 튜터를 위한 데이터 형식

마지막으로 실험 데이터를 어떤 형식으로 저장할지 생각해 보자. 너무 복잡한 형식부터 시작하면 구현이 어려워진다. 처음에는 에피소드 단위 JSONL 파일이 좋다. 한 줄에 하나의 주요 이벤트를 기록하는 방식이다.

{"time": 0.0, "event": "episode_start", "goal": "red cup pick and place"}
{"time": 1.2, "event": "object_detected", "label": "red_cup", "confidence": 0.88, "pixel": [412, 238], "depth_valid_ratio": 0.76}
{"time": 1.8, "event": "pose_transformed", "frame_from": "camera_color_optical_frame", "frame_to": "base_link", "x": 0.42, "y": -0.11, "z": 0.04}
{"time": 2.5, "event": "motion_plan_success", "skill": "move_to_pregrasp", "planning_time": 0.42}
{"time": 4.0, "event": "gripper_closed", "width": 0.041, "force": 1.8}
{"time": 5.1, "event": "lift_failed", "object_moved": false, "reason": "empty_grasp"}

이런 데이터는 사람이 읽기에도 좋고, 나중에 분석하기에도 좋다. LLM 리포트 생성기에 넣기도 쉽다. 에피소드가 쌓이면 특정 실패 유형을 검색하거나, 성공한 실험과 실패한 실험을 비교하거나, 학습자별 개선 추세를 볼 수 있다.

더 발전시키면 이미지 파일, depth map, RViz 캡처, 실행 영상, 파라미터 스냅샷을 함께 저장할 수 있다. 중요한 것은 모든 데이터를 무작정 저장하는 것이 아니라, 나중에 학습과 피드백에 쓸 수 있도록 구조화하는 것이다.

작은 튜터에서 시작하라

AI 로봇 튜터를 처음부터 완벽하게 만들 필요는 없다. 오히려 작은 기능부터 시작하는 편이 좋다.

첫 번째 버전은 "현재 상태 설명기"만 있어도 충분하다. 로봇의 목표, 실행 중인 스킬, 마지막 오류, 센서 품질을 한 문단으로 설명하게 만들자.

두 번째 버전에서는 "실패 진단 카드"를 추가한다. 객체 미검출, 좌표 변환 오차, 경로 계획 실패, 파지 실패를 구분하고 확인할 값을 알려 주게 한다.

세 번째 버전에서는 "실험 리포트"를 만든다. 한 번의 실행을 시간순으로 요약하고, 성공/실패와 다음 실험 제안을 기록한다.

네 번째 버전에서는 "학습자 모델"을 추가한다. 초보자에게는 용어 설명을 붙이고, 중급자에게는 토픽과 파라미터를 알려 주며, 고급자에게는 오차 분석과 실험 설계를 요구한다.

다섯 번째 버전에서는 축적된 로그를 학습 자료로 재사용한다. 실패 사례 라이브러리를 만들고, 학생들이 자신의 실험과 비교하게 한다.

이렇게 단계적으로 만들면 AI 로봇 튜터는 단순한 챗봇이 아니라 로봇 실험실의 지식 축적 시스템이 된다.

로봇을 이해하는 가장 좋은 방법

로봇을 배우는 가장 좋은 방법은 로봇을 직접 움직여 보는 것이다. 하지만 그다음으로 중요한 것은 로봇이 왜 그렇게 움직였는지 이해하는 것이다.

AI 로봇 튜터는 그 사이를 이어 준다. 로봇의 센서 데이터와 실행 로그를 자연어 설명으로 바꾸고, 실패를 원인 후보로 나누고, 학습자의 수준에 맞춰 힌트를 제공한다. 그리고 반복 실험의 기록을 다음 학습과 모델 개선의 재료로 되돌린다.

앞으로의 로봇 교육은 단순히 "코드를 실행해 보세요"에서 끝나지 않을 것이다. 로봇은 자신이 본 것, 판단한 것, 실패한 것을 설명하게 될 것이다. 학생은 그 설명을 바탕으로 다시 실험하고, 로봇은 그 실험 기록을 바탕으로 더 나은 피드백을 제공할 것이다.

그때 로봇은 과제의 대상이면서 동시에 학습의 동료가 된다. 우리가 만든 AI 로봇 에이전트는 물체를 집고, 이동하고, 말로 응답하는 데서 멈추지 않는다. 이제는 학습자가 로봇을 더 깊이 이해하도록 돕는 튜터가 된다.

다음 장에서는 이 모든 흐름을 하나로 묶는다. 비전, 로봇팔, 이동, 음성, LLM, 안전 제어, 실험 로그를 정리해 나만의 AI 로봇 에이전트를 완성하는 단계로 나아간다.

참고

¹A systematic review of intelligent and robot tutoring systems: evolution, pedagogical design, and AI-driven classification

²How sensor data is powering AI in robotics

³Integrating emotional intelligence, memory architecture, and gestures to achieve empathetic humanoid robot interaction in an educational setting

⁴Artificial Intelligence in Intelligent Tutoring Robots: A Systematic Review and Design Guidelines

⁵Building a 100-Robot Data Factory Toward Factory-Ready AI