로봇 소프트웨어의 기본 구조

로봇을 처음 만들 때 많은 사람은 코드를 이렇게 상상합니다. 센서를 읽고, 조건문을 쓰고, 모터를 돌리면 끝. 실제로 아주 작은 프로젝트는 정말 그렇게 시작할 수 있습니다. 하지만 로봇을 조금만 제대로 만들어 보려 하면 금방 느끼게 됩니다. 로봇 코드는 그냥 한 번 실행하고 끝나는 스크립트가 아니라, 계속 주변을 보고, 계속 판단하고, 계속 움직임을 조정해야 하는 시스템이라는 사실을 말입니다.

웹 페이지 버튼 하나를 누르는 프로그램은 잠깐 멈칫해도 큰일이 나지 않습니다. 하지만 로봇이 벽 앞에서 잠깐 멈칫하면 부딪힐 수 있습니다. 바퀴 속도가 조금씩 어긋나면 직진한다고 생각했는데 점점 한쪽으로 휘어집니다. 카메라가 사람을 찾았는데 모터가 늦게 반응하면, 로봇은 이미 지나간 사람을 뒤늦게 따라가게 됩니다.

그래서 로봇 소프트웨어를 이해할 때는 한 가지 감각이 중요합니다. 로봇은 늘 현재 진행형으로 움직인다는 감각입니다. 지금 이 순간 센서를 읽고, 지금 이 순간 상태를 판단하고, 지금 이 순간 행동을 정해야 합니다.

이 장에서는 로봇 소프트웨어의 가장 기본적인 구조를 차근차근 살펴보겠습니다. 센서 입력, 상태 판단, 액추에이터 출력으로 이어지는 기본 루프를 이해하고, 여기에 상태 머신, 피드백 제어, PID 같은 핵심 개념이 왜 붙는지 쉽게 익혀보겠습니다.

로봇 소프트웨어는 결국 입력, 판단, 출력이다

아무리 복잡한 로봇이라도 아주 단순하게 보면 세 단계로 나눌 수 있습니다.

• 입력: 센서나 사용자 명령으로 현재 상황을 받는다

• 판단: 지금 무슨 상태인지 계산하고 무엇을 할지 결정한다

• 출력: 모터, 서보, LED, 스피커 같은 장치에 명령을 보낸다

이 구조는 작은 장애물 회피 로봇에도 들어 있고, 카메라로 사물을 인식하는 AI 로봇에도 들어 있으며, 나중에 배울 ROS 2 기반 로봇에도 그대로 들어 있습니다. 겉모습이 달라 보여도, 속에서는 계속 이 순환이 반복됩니다.

예를 들어 앞에 장애물이 있는지 피하는 작은 이동 로봇을 생각해 봅시다. 초음파 센서가 거리를 읽습니다. 소프트웨어는 "앞이 너무 가까운가?"를 판단합니다. 가까우면 모터를 멈추고 왼쪽 또는 오른쪽으로 돌라고 명령합니다. 그러고 나면 다시 센서를 읽고, 다시 판단하고, 다시 움직입니다.

이 과정을 문장으로 쓰면 단순해 보이지만, 실제 로봇에서는 이것이 초당 수십 번, 많게는 수백 번 반복됩니다. 즉 로봇은 생각보다 바쁘게 살고 있습니다.

기본 루프: 로봇은 멈추지 않고 계속 돈다

로봇 프로그램의 가장 기본 형태는 보통 루프입니다. 시작할 때 한 번만 하는 준비 작업이 있고, 그다음에는 같은 흐름을 계속 반복합니다.

초기화
반복:
  센서 읽기
  상태 추정
  규칙 또는 알고리즘으로 판단
  액추에이터 명령 출력
  짧게 대기 또는 다음 주기로 이동

이 구조가 중요한 이유는 로봇이 세상을 한 번 보고 끝내는 존재가 아니기 때문입니다. 방금 전에는 길이 비어 있었어도 지금은 사람이 지나갈 수 있습니다. 방금 전에는 바닥이 평평했어도 지금은 문턱 앞에 있을 수 있습니다. 방금 전에는 물체가 컵처럼 보였어도 카메라 각도가 바뀌면 책으로 보일 수도 있습니다.

로봇은 그래서 늘 최신 상태를 다시 확인해야 합니다. 한 번 판단했다고 끝이 아니라, 계속 수정해야 합니다. 이 반복 구조가 바로 로봇 소프트웨어의 심장입니다.

입력: 센서 데이터는 현실 그 자체가 아니다

입력 단계에서 로봇은 카메라, 거리 센서, IMU, 엔코더, 버튼, 마이크 같은 장치로부터 데이터를 받습니다. 여기서 초보자가 자주 놓치는 점이 하나 있습니다. 센서 데이터는 현실 그 자체가 아니라, 현실을 거칠게 번역한 값이라는 점입니다.

초음파 센서는 가끔 엉뚱한 거리를 줄 수 있습니다. 카메라는 빛이 바뀌면 전혀 다른 장면처럼 보일 수 있습니다. IMU는 시간이 지날수록 조금씩 오차가 쌓입니다. 엔코더는 바퀴가 헛돌면 실제 이동 거리와 어긋날 수 있습니다.

즉 입력 단계는 "값을 받는다"에서 끝나지 않습니다. 보통은 값이 말이 되는지 확인하고, 너무 튀는 값은 무시하고, 여러 센서 값을 조합해서 좀 더 믿을 만한 상태를 만들어야 합니다.

예를 들어 초음파 센서가 한 번 3cm를 읽었다고 해서 바로 급정지하면, 로봇은 허공에 놀라서 멈추는 겁쟁이가 될 수 있습니다. 반대로 너무 오래 평균만 내면 진짜 벽을 늦게 알아챌 수 있습니다. 그래서 로봇 개발은 단순히 센서를 붙이는 일보다, 센서 값을 어떻게 해석할지 정하는 일이 더 중요해집니다.

판단: 조건문에서 시작해 상태 추정으로 간다

판단 단계는 로봇 소프트웨어의 중심입니다. 센서 값을 읽었다면, 이제 그 값이 무슨 뜻인지 해석해야 합니다.

초보 단계에서는 보통 조건문으로 시작합니다.

"앞 거리가 20cm보다 작으면 멈춘다." "사람 얼굴이 보이면 따라간다." "배터리가 낮으면 충전 상태로 들어간다."

이런 규칙은 아주 좋은 출발점입니다. 로봇은 처음부터 똑똑할 필요가 없습니다. 오히려 명확한 규칙 몇 개로 시작하는 편이 디버깅하기 쉽습니다.

하지만 프로젝트가 조금 커지면 조건문만으로는 점점 관리가 어려워집니다. 왜냐하면 로봇은 하나의 숫자만 보고 행동하지 않고, 지금 어떤 상태에 있는지까지 함께 고려해야 하기 때문입니다.

예를 들어 같은 "앞에 물체가 보인다"라는 입력도 상황에 따라 의미가 달라집니다. 순찰 중일 때는 피해야 할 장애물일 수 있고, 물체 집기 모드에서는 목표 물체일 수 있으며, 충전 도크를 찾는 중이라면 오히려 가까이 가야 할 대상일 수 있습니다.

즉 로봇은 입력만 보는 것이 아니라, 입력과 현재 상태를 함께 봐야 합니다.

출력: 행동은 명령 한 줄이 아니라 물리 세계의 변화다

출력 단계에서는 판단 결과를 실제 하드웨어에 전달합니다. 바퀴 로봇이라면 모터 속도를 바꾸고, 로봇팔이라면 관절 각도를 보내고, 데스크 로봇이라면 LED 표정이나 스피커 음성을 출력할 수 있습니다.

여기서 중요한 점은 출력이 화면 속 결과가 아니라는 것입니다. 콘솔에 문자열을 찍는 프로그램은 잘못되면 다시 실행하면 됩니다. 하지만 로봇은 잘못된 명령 하나로 책상 아래로 떨어질 수도 있고, 벽에 박을 수도 있고, 팔이 이상한 방향으로 꺾일 수도 있습니다.

그래서 출력 명령에는 늘 조심성이 필요합니다. 속도 제한, 각도 제한, 긴급 정지, 타임아웃 같은 안전 장치가 자주 함께 들어갑니다. 좋은 로봇 코드는 "움직일 수 있다"보다 "위험하게 움직이지 않게 한다"를 먼저 생각합니다.

한 번에 다 하지 말고, 주기를 나눠 생각하자

로봇 소프트웨어를 처음 짤 때 흔한 실수는 모든 일을 한 루프에 몰아넣는 것입니다. 센서 읽기, 카메라 처리, 음성 인식, 모터 제어, 로그 저장, 화면 출력, 네트워크 통신을 한 덩어리로 돌리면 처음엔 편해 보입니다. 그런데 어느 순간 카메라 처리 때문에 모터 반응이 늦고, 로그 저장 때문에 센서 읽기가 끊기고, 음성 인식 때문에 주행이 덜컹거리기 시작합니다.

로봇은 보통 해야 할 일의 속도가 서로 다릅니다. 예를 들어 바퀴 속도 제어는 아주 빠르게 돌아야 하지만, 배터리 표시를 업데이트하는 일은 그렇게 자주 할 필요가 없습니다. 사람 얼굴을 찾는 카메라 모델도 매 밀리초마다 돌릴 필요는 없습니다.

그래서 실전에서는 일을 층으로 나눠 생각하는 습관이 중요합니다.

• 빠른 루프: 모터 제어, 엔코더 읽기, 자세 보정

• 중간 루프: 장애물 판단, 경로 수정, 상태 업데이트

• 느린 루프: 화면 표시, 로그 저장, 네트워크 전송, 음성 응답

이렇게 나누면 왜 어떤 기능은 아두이노 같은 MCU가 맡고, 어떤 기능은 라즈베리파이나 Jetson 같은 보드가 맡는지 감이 생깁니다. 이전 장에서 하드웨어 두뇌를 역할로 나눴다면, 이번 장에서는 소프트웨어도 똑같이 역할과 속도로 나뉜다는 사실을 보는 셈입니다.

이벤트 기반: 모든 일을 계속 확인하지 않아도 된다

기본 루프는 중요하지만, 모든 상황을 루프에서 매번 검사할 필요는 없습니다. 어떤 일은 특정 사건이 생겼을 때만 처리하는 편이 자연스럽습니다. 이것이 이벤트 기반 방식입니다.

예를 들어 버튼이 눌렸을 때만 녹화를 시작하고, 음성 명령이 들어왔을 때만 명령 해석을 하고, 충전기에 연결됐을 때만 충전 모드로 바꾸는 일은 이벤트처럼 다루기 좋습니다.

루프 기반과 이벤트 기반은 서로 경쟁 관계가 아닙니다. 보통 로봇은 둘을 섞어 씁니다. 바퀴 제어나 센서 감시는 계속 도는 루프에 넣고, 버튼 입력이나 네트워크 메시지 수신은 이벤트로 처리하는 식입니다.

쉽게 말해 루프는 심장 박동이고, 이벤트는 갑자기 울리는 벨소리입니다. 심장은 계속 뛰어야 하지만, 벨소리가 났을 때는 그에 맞는 반응을 별도로 해야 합니다.

상태 머신: 로봇이 지금 무엇을 하는지 잊지 않게 만드는 방법

로봇 소프트웨어가 조금만 복잡해져도 반드시 필요한 개념이 상태 머신입니다. 이름은 어려워 보이지만 생각은 단순합니다. 로봇이 아무 때나 아무 행동이나 하는 것이 아니라, 지금 어떤 상태인지에 따라 가능한 행동이 달라지도록 만드는 구조입니다.

예를 들어 순찰 로봇을 만든다고 해봅시다. 이 로봇은 대략 다음 상태를 가질 수 있습니다.

• 대기 상태

• 순찰 상태

• 장애물 회피 상태

• 목표 확인 상태

• 배터리 부족 상태

• 충전 상태

이 구조가 없으면 코드가 금방 엉킵니다. 순찰 중인데 배터리가 낮아졌을 때, 사람을 봤을 때, 장애물이 나타났을 때, 충전 도크가 보였을 때를 조건문으로 끝없이 이어 붙여야 하기 때문입니다.

반면 상태 머신을 쓰면 생각이 정리됩니다. 지금 순찰 상태라면 장애물을 만나면 회피 상태로 전환합니다. 회피가 끝나면 다시 순찰로 돌아갑니다. 배터리가 일정 수준 아래로 떨어지면 충전 상태로 넘어갑니다. 충전이 끝나면 대기 상태로 전환합니다.

이렇게 하면 로봇의 행동이 이야기처럼 읽히기 시작합니다. 그리고 디버깅도 쉬워집니다. "왜 지금 멈췄지?"라는 질문에 "충전 상태로 잘못 들어갔네"처럼 대답할 수 있기 때문입니다.

상태 머신이 특히 빛나는 장면

상태 머신은 다음 같은 상황에서 특히 유용합니다.

• 순서가 있는 작업: 찾기 → 접근 → 집기 → 옮기기 → 놓기

• 모드가 분리된 작업: 수동 조종 모드와 자율 주행 모드

• 예외 처리가 많은 작업: 정상 동작, 오류 복구, 안전 정지

로봇팔 프로젝트에서도 상태 머신은 아주 잘 맞습니다. 목표를 찾고, 팔을 접근시키고, 그리퍼를 닫고, 들어 올리고, 지정 위치로 이동하고, 다시 놓는 흐름은 사실 상태 전환의 연속입니다. 나중에 다룰 음성 명령 로봇도 마찬가지입니다. 듣는 상태, 해석하는 상태, 실행하는 상태, 보고하는 상태가 구분되면 구조가 훨씬 또렷해집니다.

오픈 루프와 클로즈드 루프: 시켰다고 정말 그렇게 되었는가

이제 로봇 제어에서 아주 중요한 개념으로 넘어가 봅시다. 바로 피드백 제어입니다.

먼저 오픈 루프, 즉 개방 루프부터 생각해 보겠습니다. 오픈 루프는 말 그대로 결과를 확인하지 않고 명령만 보내는 방식입니다. 예를 들어 "모터를 1초 동안 돌려"라고 하고 끝내는 것입니다. 간단하고 구현도 쉽습니다.

하지만 현실에서는 문제가 생깁니다. 바닥 마찰이 다를 수 있고, 배터리 전압이 떨어질 수 있고, 한쪽 바퀴가 더 무거울 수도 있습니다. 그러면 같은 1초를 돌려도 이동 거리가 달라집니다.

이 문제를 해결하려면 결과를 다시 읽어야 합니다. 이것이 클로즈드 루프, 즉 폐루프 제어입니다. 목표 속도나 목표 위치를 정해 두고, 실제 값이 얼마나 다른지 계속 측정해서 명령을 수정합니다.

예를 들어 바퀴 속도를 초당 20cm로 유지하고 싶다면, 엔코더로 실제 속도를 읽고 목표와 비교합니다. 실제 속도가 느리면 출력을 조금 올리고, 너무 빠르면 줄입니다. 이 과정이 반복되면 로봇은 환경이 조금 바뀌어도 비슷한 성능을 유지할 수 있습니다.

쉽게 말해 오픈 루프는 "이 정도면 됐겠지"이고, 클로즈드 루프는 "실제로 됐는지 확인하고 고치자"입니다. 로봇이 현실 세계에서 믿을 만하게 움직이려면 결국 후자가 필요합니다.

피드백 제어를 일상 감각으로 이해하기

사람도 사실 피드백 제어를 늘 하고 있습니다. 컵에 물을 따를 때 손을 그냥 일정 속도로만 움직이지 않습니다. 물 높이를 눈으로 보면서 조금씩 속도를 조절합니다. 자전거를 탈 때도 몸이 기울어지는 것을 느끼고 핸들을 계속 수정합니다.

로봇도 같습니다. 원하는 방향으로 가고 싶은데 실제로는 오른쪽으로 조금 휘면, 센서가 그 오차를 보고 다시 보정해야 합니다. 이것이 피드백입니다.

즉 로봇 제어는 "명령을 잘 내리는 기술"이라기보다, "오차를 계속 줄여 나가는 기술"에 더 가깝습니다.

PID 제어: 가장 유명한 보정 공식

피드백 제어를 이야기하면 거의 반드시 등장하는 것이 PID 제어입니다. 이름은 거창하지만 핵심은 하나입니다. 목표와 실제의 차이, 즉 오차를 보고 출력을 얼마나 고칠지 계산하는 방법입니다.

PID는 세 가지 요소의 머리글자입니다.

• P: 현재 오차가 크면 그만큼 강하게 반응한다

• I: 오차가 오래 누적되면 조금씩 더 보정한다

• D: 오차가 얼마나 빠르게 변하는지 보고 과한 움직임을 줄인다

하나씩 쉽게 보겠습니다.

P: 지금 많이 틀렸으면 크게 고친다

비례 제어라고 부릅니다. 목표 속도가 10인데 실제 속도가 6이라면 오차는 4입니다. 오차가 크니 출력을 더 올립니다. 반대로 목표가 10인데 실제가 9.5라면 조금만 보정하면 됩니다.

P는 직관적이고 강력합니다. 오차가 크면 세게, 작으면 약하게 반응합니다. 대부분의 첫 제어 코드는 여기서 시작합니다.

하지만 P만 쓰면 약간의 오차가 계속 남는 경우가 많습니다. 목표까지 거의 가지만 완전히 맞추지 못하는 느낌입니다.

I: 조금씩 남는 오차를 끝까지 밀어낸다

적분 제어라고 부릅니다. 말이 어렵지만 감각은 이렇습니다. 작은 오차라도 오랫동안 계속 남아 있으면, "이건 우연이 아니라 계속 틀리고 있는 것"이라고 보고 보정을 더하는 것입니다.

예를 들어 바퀴가 늘 살짝 느리게 돈다면 P만으로는 어정쩡하게 맞추고 끝날 수 있습니다. I는 그 작은 오차를 계속 쌓아 두었다가 출력을 더 밀어 올려, 결국 목표에 더 가까이 가게 합니다.

다만 I가 너무 강하면 로봇이 늦게 깨닫고 한꺼번에 과하게 반응할 수 있습니다. 그래서 튜닝이 중요합니다.

D: 너무 급하게 가는 것을 미리 누른다

미분 제어라고 부릅니다. 현재 오차 자체보다, 오차가 얼마나 빠르게 변하는지에 주목합니다. 쉽게 말해 "지금 너무 빠르게 목표를 향해 돌진하고 있네, 조금 브레이크를 걸자"에 가깝습니다.

이 요소는 흔들림을 줄이는 데 도움이 됩니다. 목표값 근처에서 왔다 갔다 떨리는 현상을 완화하는 데 자주 쓰입니다.

하지만 센서 값이 시끄럽고 들쭉날쭉하면 D가 예민하게 반응해 오히려 불안정해질 수 있습니다. 그래서 모든 프로젝트에서 D가 반드시 멋지게 작동하는 것은 아닙니다.

PID를 한 문장으로 이해하면

P는 지금 오차에 반응합니다. I는 오래된 오차를 기억합니다. D는 오차의 속도를 보고 미리 완급을 조절합니다.

이 세 가지를 잘 조합하면 로봇은 목표에 빠르게 다가가면서도, 너무 흔들리지 않고, 은근히 남는 오차도 줄일 수 있습니다.

물론 실제로는 완벽한 숫자가 저절로 나오지 않습니다. 로봇마다 무게가 다르고, 모터가 다르고, 바닥이 다르기 때문에 PID 값은 실험하며 맞춰야 합니다. 그래서 많은 개발자가 PID를 처음 만날 때 "공식"보다 "조절 감각"으로 배우게 됩니다.

PID는 어디에 쓰일까

PID는 생각보다 다양한 곳에 등장합니다. 꼭 거대한 산업용 시스템에서만 쓰는 것이 아닙니다.

• 바퀴 속도를 일정하게 유지하기

• 로봇이 직진하도록 좌우 바퀴 차이를 보정하기

• 라인 트레이서가 선 중앙을 따라가게 하기

• 로봇팔 관절을 목표 각도에 맞추기

• 짐벌이나 카메라 헤드를 부드럽게 안정화하기

예를 들어 라인 트레이서에서는 센서가 선의 중심에서 얼마나 벗어났는지 읽습니다. 그 오차를 기준으로 좌우 바퀴 속도를 조절하면 선을 따라가게 됩니다. 이때 너무 세게 꺾으면 지그재그로 흔들리고, 너무 약하면 선을 놓칩니다. 바로 이런 상황에서 PID가 유용합니다.

로봇 코드는 왜 실시간 시스템처럼 느껴져야 할까

엄밀한 의미의 실시간 시스템은 분야에 따라 더 엄격한 정의가 있습니다. 하지만 개인 개발자 관점에서 꼭 기억하면 좋은 것은 이것입니다. 로봇 코드는 타이밍이 결과를 바꾼다는 사실입니다.

센서 읽기가 늦으면 이미 늦은 판단을 하게 됩니다. 모터 출력 주기가 흔들리면 움직임도 흔들립니다. 안전 정지 조건을 늦게 확인하면 위험 상황을 놓칠 수 있습니다.

그래서 로봇 소프트웨어에서는 "무슨 계산을 하느냐"만큼 "언제 하느냐"도 중요합니다. 같은 코드라도 루프 주기가 불안정하면 전혀 다른 결과가 나올 수 있습니다.

이 감각을 익히면 초보자가 흔히 빠지는 함정을 피하기 쉬워집니다. 예를 들어 sleep()을 여기저기 넣어 두면 보기엔 단순하지만, 로봇은 그동안 세상을 못 보게 됩니다. 카메라 추론 하나가 너무 오래 걸리면, 제어 루프까지 같이 굶어 죽을 수 있습니다. 그래서 로봇 개발자는 점점 기능을 분리하고, 주기를 관리하고, 로그를 보고, 병목을 찾는 습관을 들이게 됩니다.

좋은 구조는 작은 로봇에서도 차이를 만든다

처음부터 거대한 프레임워크가 필요한 것은 아닙니다. 하지만 작은 프로젝트라도 구조를 조금만 신경 쓰면 훨씬 오래 갑니다.

예를 들어 다음처럼 나누면 좋습니다.

• 센서 읽기 함수

• 상태 계산 함수

• 제어 계산 함수

• 액추에이터 출력 함수

• 안전 검사 함수

이렇게 나누면 나중에 센서를 바꾸거나, 제어 방식을 PID로 바꾸거나, 모터 드라이버를 바꾸더라도 전체 코드를 갈아엎지 않아도 됩니다. 반대로 처음부터 모든 로직을 if 문 사이에 뒤섞어 넣으면, 프로젝트가 커질수록 수정이 무서워집니다.

초보자가 자주 하는 실수

로봇 소프트웨어를 처음 짤 때 자주 나오는 실수도 미리 알아두면 좋습니다.

첫째, 센서 값을 그대로 믿습니다. 한 번 읽은 값으로 바로 큰 결정을 내리면 오작동이 많아집니다.

둘째, 상태를 따로 두지 않고 조건문만 계속 붙입니다. 처음엔 되지만 금방 스파게티 코드가 됩니다.

셋째, 출력 명령을 너무 크게 줍니다. 빨리 움직이면 좋아 보이지만, 실제로는 더 흔들리고 더 위험해집니다.

넷째, 제어와 무거운 계산을 한 루프에 다 넣습니다. 카메라 처리 때문에 주행이 불안정해지는 전형적인 원인입니다.

다섯째, 로그를 남기지 않습니다. 로봇이 이상하게 움직였을 때 당시 센서 값, 상태, 출력 값을 모르면 원인을 찾기 어렵습니다.

이 장에서 꼭 가져가야 할 감각

지금까지 내용을 하나로 묶으면 이렇습니다. 로봇 소프트웨어는 "명령을 실행하는 프로그램"이 아니라, "상황을 계속 관찰하고 오차를 계속 줄여 가는 시스템"입니다.

입력은 현실을 완벽하게 알려주지 않습니다. 판단은 현재 상태를 함께 고려해야 합니다. 출력은 물리 세계를 바꾸기 때문에 안전이 중요합니다. 기본 루프는 계속 돌아야 하고, 이벤트는 필요한 순간 반응해야 하며, 상태 머신은 로봇의 행동을 정리해 줍니다. 그리고 피드백 제어와 PID는 로봇이 현실의 흔들림 속에서도 목표에 가깝게 움직이도록 도와줍니다.

이 감각이 생기면, 앞으로 만들 프로젝트들이 훨씬 덜 신비롭게 보이기 시작합니다. 장애물 회피 로봇도, 카메라 인식 로봇도, 음성 명령 로봇도 결국은 같은 원리 위에 서 있기 때문입니다.

정리

좋은 로봇 코드는 화려한 AI보다 먼저, 기본 루프가 안정적입니다. 센서를 읽고, 상태를 판단하고, 액추에이터를 움직이는 흐름이 분명해야 합니다. 그 위에 상태 머신이 얹히고, 피드백 제어가 들어가고, 필요하면 PID 같은 보정 기법이 붙습니다.

처음에는 단순한 규칙으로 시작해도 괜찮습니다. 중요한 것은 로봇을 스크립트처럼 보지 않고, 계속 반응하는 시스템으로 바라보는 시선을 갖는 것입니다. 그 시선이 생기면 이후의 모든 주제가 더 잘 연결됩니다.

다음 장에서는 이런 소프트웨어를 실제로 돌리기 위한 개발 환경을 살펴보겠습니다. Python과 C++, Arduino IDE, VS Code, Git, 리눅스 터미널, 원격 접속 같은 도구들이 왜 필요한지, 그리고 초보자가 어디에서 가장 자주 막히는지 하나씩 정리해 보겠습니다.