21. 로봇 프로젝트 기획하기: 문제, 사용자, 작업 정의

멋진 로봇보다 잘 쓰이는 로봇이 오래 남는다

로봇 프로젝트를 시작할 때 가장 먼저 떠오르는 질문은 보통 이렇습니다.

"바퀴형으로 할까?" "로봇팔을 달까?" "카메라를 몇 개 붙일까?"

그런데 실제로 끝까지 가는 프로젝트는 대개 다른 질문에서 출발합니다.

"무슨 문제를 해결하려는 걸까?"

이 차이는 생각보다 큽니다. 기능에서 출발한 로봇은 데모 영상에서는 멋져 보이지만, 실제 생활에 들어오면 금방 자리를 잃습니다. 반대로 문제에서 출발한 로봇은 처음엔 덜 화려해 보여도 자주 쓰이고, 고쳐 가며 오래 살아남습니다. 개인 개발자에게 중요한 것은 박람회용 시제품이 아니라 내 방, 내 작업실, 내 사무실에서 실제로 도움이 되는 도구입니다.

로봇은 소프트웨어보다 더 냉정합니다. 앱은 조금 불편해도 그냥 실행하면 되지만, 로봇은 공간을 차지하고 충전이 필요하고 때로는 소음도 냅니다. 그러니 "있으면 멋진 물건" 정도로는 버티기 어렵습니다. 자리를 차지할 만큼, 유지할 만큼, 다시 켜고 싶을 만큼 분명한 이유가 있어야 합니다.

좋은 기획은 그래서 언제나 무엇을 만들까보다 왜 만들어야 할까를 먼저 묻습니다.

문제를 먼저 정의해야 하는 이유

개인 로봇 프로젝트가 실패하는 흔한 패턴은 비슷합니다. 카메라를 붙이고, 음성 명령을 넣고, LLM도 연결하고, 자율주행까지 시도합니다. 기술적으로는 풍성한데 정작 사용 장면이 흐릿합니다. 결국 테스트할 때만 켜고, 평소에는 책상 한쪽에서 먼지를 모으게 됩니다.

이런 일이 생기는 이유는 로봇이 해결해야 할 문제가 너무 넓거나 애매하기 때문입니다. 예를 들어 "집안일을 도와주는 로봇"은 멋진 목표 같지만 실제로는 너무 큽니다. 어떤 집안일인지, 누가 쓰는지, 하루 중 언제 쓰는지, 실패하면 어떤 일이 생기는지 전부 다 다릅니다. 반면 "퇴근 전에 작업실 창문이 닫혔는지 확인해 알려 주는 로봇"은 작지만 선명합니다.

문제가 선명하면 그다음 선택도 쉬워집니다. 이동이 필요한지, 고정형 카메라로 충분한지, 완전자동이 필요한지, 사람이 마지막 확인만 하면 되는지가 자연스럽게 따라옵니다. 반대로 문제가 흐리면 하드웨어와 소프트웨어가 계속 흔들립니다. 바퀴를 달았다가 빼고, 로봇팔을 넣었다가 포기하고, 카메라 위치를 바꾸다 지칩니다.

로봇 기획의 핵심은 기술을 뽐내는 것이 아니라, 불편을 정확히 겨냥하는 것입니다.

좋은 문제는 작고 자주 반복된다

개인 개발자가 다루기 좋은 문제는 대개 공통점이 있습니다. 거대하지 않고, 반복적이며, 성공과 실패를 비교적 쉽게 판단할 수 있다는 점입니다.

좋은 문제는 보통 이런 성격을 가집니다.

• 자주 발생한다.

• 사람이 할 수는 있지만 귀찮다.

• 반복 순서가 비슷하다.

• 놓치면 불편하거나 손해가 생긴다.

• 자동화 범위를 좁게 자를 수 있다.

예를 들어 "책상을 항상 깔끔하게 유지하기"는 추상적입니다. 하지만 "퇴근 전에 컵, 인두, 배터리 충전기 위치를 확인해 주기"는 훨씬 좋습니다. "작업실 재고를 관리하기"보다 "매일 저녁 필라멘트 보관함 사진을 찍어 부족한 칸을 표시하기"가 더 좋습니다. "촬영을 편하게 하기"보다 "혼자 촬영할 때 얼굴이 프레임 밖으로 벗어나지 않게 카메라 각도를 조정하기"가 더 좋습니다.

작은 문제를 얕보면 안 됩니다. 개인 로봇은 세상을 한 번에 바꾸지 못해도, 하루의 흐름을 조금 바꿀 수는 있습니다. 그리고 실제로는 그 작은 변화가 가장 큰 만족을 줍니다. 매일 반복되는 불편 하나를 없애면 로봇은 더 이상 장난감이 아니라 생활 도구가 됩니다.

사용자는 누구인가

문제를 정의했다면 다음 질문은 사용자입니다. 많은 개인 프로젝트가 여기서 한 번 더 흔들립니다. "내가 쓰는 로봇인데 사용자 정의가 왜 필요하지?"라고 생각하기 쉽기 때문입니다. 하지만 혼자 쓰는 로봇이라도 사용자 관점은 꼭 필요합니다.

왜냐하면 개발자와 사용자는 같은 사람일 수도 있지만, 같은 사고방식을 갖지는 않기 때문입니다. 개발자는 성능과 구조를 봅니다. 사용자는 귀찮음과 편리함을 봅니다. 개발자는 로그를 읽고 재시작하는 것을 당연하게 여기지만, 사용자는 버튼 하나 더 누르는 것도 번거롭게 느낍니다.

사용자를 정의할 때는 거창한 시장 조사보다 먼저, 실제 사용하는 사람의 하루를 그려 보면 됩니다. 다음 질문이 도움이 됩니다.

이 사람은 어디에서 로봇을 쓰는가? 무엇이 가장 귀찮은가? 언제 가장 바쁜가? 실수하면 어떤 문제가 생기는가? 기술에 익숙한가? 매번 앱을 열 수 있는가? 로봇이 느려도 괜찮은가, 아니면 즉각 반응해야 하는가?

예를 들어 같은 "순찰 로봇"이라도 사용자에 따라 완전히 달라집니다. 혼자 일하는 작업실 운영자는 퇴근 전 상태 점검이 중요할 수 있습니다. 작은 매장 운영자는 개점 전 이상 여부를 빨리 확인하는 것이 중요할 수 있습니다. 집에서 쓰는 사용자는 소음과 크기를 더 민감하게 볼 수 있습니다.

사용자를 잘 정의하면 불필요한 기능이 빠집니다. 그리고 이 과정에서 자주 깨닫게 됩니다. 내가 만들고 싶은 로봇과, 사용자가 진짜 필요로 하는 로봇은 조금 다를 수 있다는 사실을 말입니다.

사용자를 한 문장으로 써 보기

사용자 정의는 길고 복잡할 필요가 없습니다. 오히려 한 문장으로 또렷하게 써 보는 것이 좋습니다.

예를 들면 이런 식입니다.

• 퇴근 직전 작업실 상태를 빠르게 확인하고 싶은 1인 메이커

• 혼자 제품 촬영을 하면서 카메라 프레이밍을 자주 놓치는 소규모 창작자

• 책상 위 위험 물건을 자꾸 잊어버리는 하드웨어 개발자

• 매일 같은 선반의 재고 부족 여부만 확인하면 되는 소형 판매자

이 한 문장은 놀랍도록 많은 것을 결정합니다. 작업 빈도, 반응 속도, 설치 위치, 인터페이스, 허용 가능한 실패 수준이 모두 여기서 뻗어나옵니다. 사용자가 바뀌면 로봇도 바뀝니다.

작업은 기능이 아니라 행동 단위로 정의해야 한다

기획 단계에서 특히 자주 하는 실수는 작업을 기능 이름으로 써 버리는 것입니다. 예를 들어 "객체 인식", "음성 제어", "자율주행", "로봇팔 집기" 같은 말들입니다. 하지만 이것들은 기술 항목이지, 사용자가 원하는 작업 자체는 아닙니다.

작업은 로봇이 실제로 해야 하는 행동 흐름으로 정의해야 합니다. 예를 들어 "객체 인식" 대신 "컵이 책상 왼쪽에 있는지 확인한다"가 되어야 합니다. "자율주행" 대신 "충전 스테이션에서 선반 A 앞으로 이동한다"가 되어야 합니다. "음성 제어" 대신 "사용자가 '순찰 시작'이라고 말하면 점검 루틴을 시작한다"가 되어야 합니다.

이 차이는 중요합니다. 기술 이름으로 정의하면 로봇은 점점 복잡해지고, 행동으로 정의하면 설계가 구체화됩니다.

좋은 작업 정의는 보통 이렇게 씁니다.

누가, 언제, 무엇을, 어떤 순서로, 어느 정도 정확도로 해야 하는가

예를 들어 "작업실 창문 점검 로봇"의 작업은 다음처럼 표현할 수 있습니다.

사용자가 퇴근 모드를 시작하면 로봇은 창문 쪽 카메라를 켜고, 창문 잠금 레버 상태를 확인하고, 열림이 의심되면 사진과 함께 알림을 보낸다.

이 문장은 그 자체로 매우 많은 설계 정보를 담고 있습니다. 이벤트는 퇴근 모드 시작, 입력은 카메라, 판단 기준은 잠금 레버 상태, 출력은 알림과 사진입니다. 이미 절반은 설계가 끝난 셈입니다.

작업을 쪼개면 어려운 로봇도 쉬워진다

처음에는 하나의 작업처럼 보이던 것도 자세히 보면 여러 단계로 나뉩니다. 그리고 이 분해 과정이 바로 기획의 핵심입니다.

예를 들어 "재고를 확인한다"는 작업은 실제로는 다음처럼 나뉩니다.

• 선반 위치를 찾는다.

• 카메라 각도를 맞춘다.

• 사진을 찍는다.

• 어떤 칸이 비었는지 판단한다.

• 결과를 저장한다.

• 부족한 항목만 요약해 보낸다.

이렇게 나누면 갑자기 현실적인 질문들이 생깁니다. 정말 자율주행이 필요한가? 아니면 고정형 카메라와 서보 회전만으로 충분한가? AI 모델이 꼭 필요한가? 아니면 빈 칸 감지만 해도 되는가? 즉시 알림이 필요한가? 아니면 하루 한 번 리포트면 되는가?

로봇 프로젝트는 대개 이 단계에서 훨씬 가벼워집니다. 처음엔 엄청난 시스템처럼 보였지만, 실제로는 작은 동작 몇 개의 조합일 때가 많기 때문입니다.

반복 작업을 찾는 가장 쉬운 방법

좋은 로봇 아이디어는 머릿속 상상보다 생활 기록에서 잘 나옵니다. 며칠만 관찰해도 자동화 후보가 보이기 시작합니다.

가장 쉬운 방법은 불편한 순간을 적는 것입니다. "오늘도 이걸 확인하러 두 번 걸어갔다", "또 깜빡했다", "혼자 해서 불편했다", "사진만 있었어도 됐는데", "매번 같은 동작을 반복했다" 같은 순간을 메모해 두면 됩니다.

특히 다음 표현이 들어가는 작업은 자동화 후보일 가능성이 큽니다.

• 매일 확인한다

• 자꾸 깜빡한다

• 굳이 사람이 해야 하나 싶다

• 실수하면 손해가 난다

• 규칙은 단순한데 귀찮다

이 메모를 쌓다 보면 멋진 아이디어보다 더 강한 것이 생깁니다. 실제 불편 목록입니다. 이 목록은 로봇 기획의 금맥에 가깝습니다. 재미는 덜 화려해 보여도, 성공 확률은 훨씬 높습니다.

운영 환경을 빼먹으면 로봇은 현실에서 넘어진다

문제와 사용자를 정했더라도 로봇은 아직 종이 위에만 존재합니다. 현실에 내려놓으려면 운영 환경을 정의해야 합니다.

운영 환경은 단순히 "집에서 쓴다" 수준이 아닙니다. 로봇이 어디서 움직이고, 무엇을 보고, 어떤 방해를 받고, 무엇과 부딪힐 수 있는지까지 포함합니다. 같은 기능이라도 환경이 바뀌면 난이도와 설계가 크게 달라집니다.

예를 들어 책상 위 로봇은 공간이 좁지만 조명이 비교적 일정하고 이동 범위가 제한됩니다. 반면 작업실 순찰 로봇은 바닥 상태, 장애물, 사람의 이동, 무선 네트워크, 충전 위치까지 고려해야 합니다. 매장 보조 로봇은 더 나아가 고객 동선과 안전 거리도 중요해집니다.

운영 환경을 볼 때는 다음 요소를 함께 보는 것이 좋습니다.

• 공간 크기와 이동 경로

• 조명 변화와 카메라 시야

• 소음과 음성 인식 가능성

• 바닥 상태와 문턱, 경사

• 사람, 반려동물, 의자, 케이블 같은 변수

• 전원과 충전 방식

• 와이파이, 블루투스, 로컬 네트워크 안정성

이 항목은 단순한 체크리스트가 아닙니다. 로봇의 가능 범위를 정하는 경계선입니다. 많은 프로젝트가 알고리즘이 아니라 환경 이해 부족 때문에 실패합니다. 로봇은 코드만으로 사는 존재가 아니라, 공간 속에서 사는 기계이기 때문입니다.

같은 문제라도 환경이 다르면 로봇도 달라진다

예를 들어 "촬영 보조 로봇"을 만든다고 해 봅시다. 집 책상에서 쓰는 경우라면 팬-틸트 카메라와 얼굴 추적으로 충분할 수 있습니다. 하지만 작업실에서 제품 촬영용으로 쓴다면 슬라이더, 조명 연동, 마커 기반 위치 복원이 더 중요할 수 있습니다. 카페에서 쓰는 경우라면 소음 때문에 음성 명령이 사실상 무용지물일 수 있습니다.

즉, 기능은 비슷해 보여도 환경이 달라지면 정답이 달라집니다. 그래서 기획 단계에서는 멋진 기능 목록보다 먼저, 로봇이 살게 될 장소를 상상해야 합니다. 가능하면 상상이 아니라 사진을 찍고 치수를 재고, 실제 동선을 걸어 보는 편이 더 좋습니다.

로봇 기획은 머리보다 발로 하는 일이 많습니다.

성공 기준이 없으면 끝나지 않는 프로젝트가 된다

개인 프로젝트가 길어질수록 흔한 문제가 하나 있습니다. 어디까지 만들면 완료인지 모른다는 점입니다. 이때 필요한 것이 성공 기준입니다.

성공 기준은 꼭 거창한 수치일 필요는 없습니다. 하지만 최소한 "이 정도면 쓸 만하다"는 선은 있어야 합니다. 그래야 프로젝트가 영원히 기능 추가만 하다가 끝나지 않습니다.

성공 기준은 다음처럼 정할 수 있습니다.

• 퇴근 점검 로봇이 1분 안에 창문 상태를 알려 줄 것

• 촬영 보조 로봇이 사용자의 얼굴을 프레임 안에 90퍼센트 이상 유지할 것

• 재고 확인 로봇이 지정된 선반 6칸을 매일 같은 시간에 촬영할 것

• 책상 알림 로봇이 위험 물건 방치 상황을 3가지 이상 구분할 것

이 기준의 좋은 점은 완벽을 강요하지 않는다는 것입니다. 로봇은 처음부터 모든 상황을 처리할 필요가 없습니다. 대신 어떤 범위에서 유용한지 분명해야 합니다. 개인 개발자에게 완벽보다 중요한 것은 반복 가능성과 유지 가능성입니다.

자동화 수준을 먼저 정해야 한다

로봇 기획에서 또 하나 중요한 결정은 자동화 수준입니다. 많은 사람이 무의식적으로 완전자동을 떠올리지만, 실제로는 반자동이 더 좋은 출발점인 경우가 많습니다.

자동화 수준은 대략 세 단계로 생각할 수 있습니다.

• 사람이 시작하고 로봇이 대부분 수행하는 방식

• 로봇이 수행하되 중간 확인을 사람에게 요청하는 방식

• 로봇이 스스로 감지하고 판단하고 완료까지 하는 방식

처음부터 세 번째를 목표로 잡으면 기술 난이도도 높아지고, 실패했을 때 위험도 커집니다. 반면 첫 번째나 두 번째 방식은 훨씬 빠르게 가치 검증이 가능합니다. 예를 들어 사용자가 "재고 확인 시작" 버튼만 눌러도 충분하다면, 굳이 완전 자동 스케줄링부터 만들 필요는 없습니다. 이상 상황 후보를 로봇이 찾고 최종 판정만 사용자가 하게 해도 실제로는 큰 도움이 됩니다.

로봇 기획에서 중요한 것은 자동화의 순도보다 사용성입니다. 덜 자동이어도 잘 쓰이면 좋은 제품입니다.

문제를 좁히는 질문

기획이 흐려질 때는 문제를 더 잘게 잘라야 합니다. 이때 도움이 되는 질문이 있습니다.

이 문제는 하루에 몇 번 발생하는가? 실패했을 때 불편함은 어느 정도인가? 사람은 지금 어떻게 해결하고 있는가? 로봇이 꼭 움직여야 하는가? 사진 한 장이면 충분한가? 음성은 정말 필요한가? LLM이 꼭 들어가야 하는가? 한 가지 상황만 먼저 해결할 수는 없는가?

이 질문에 답하다 보면 놀라울 정도로 많은 기능이 빠집니다. 그리고 그 빠진 기능 대부분은 사실 처음부터 없어도 됐던 것들입니다. 기획의 실력은 많이 넣는 데서 드러나지 않습니다. 꼭 필요한 것만 남기는 데서 드러납니다.

실패하는 기획의 전형적인 신호

로봇 프로젝트를 오래 보다 보면, 시작부터 불안한 기획은 비슷한 냄새가 납니다. 다음과 같은 신호가 보이면 한 번 멈춰서 다시 정의하는 편이 좋습니다.

• 사용자가 누구인지 한 문장으로 설명할 수 없다.

• 로봇이 언제 쓰이는지 모호하다.

• 성공했을 때 무엇이 좋아지는지 말하기 어렵다.

• 기능 목록은 긴데 실제 사용 장면이 흐리다.

• 이동, 집기, 대화, 인식이 모두 들어가지만 우선순위가 없다.

• 실패했을 때 사람이 어떻게 개입할지 정해져 있지 않다.

이런 기획은 기술적으로는 흥미로워도 끝까지 가기 어렵습니다. 로봇은 소프트웨어보다 훨씬 많은 현실 제약을 받기 때문입니다. 그래서 좋은 기획은 보통 더 소박해 보입니다. 하지만 그 소박함이 실제 성공의 조건인 경우가 많습니다.

기획은 문장 세 개로 시작해도 된다

개인 개발자는 기획이라는 말을 들으면 갑자기 문서를 잘 써야 할 것 같고, 표와 템플릿을 잔뜩 만들어야 할 것처럼 느끼기도 합니다. 하지만 첫 단계는 그렇게 무겁지 않아도 됩니다. 다음 세 문장만 제대로 써도 프로젝트 방향은 크게 선명해집니다.

첫째, 누구의 어떤 불편을 줄이려는가. 둘째, 로봇이 반복해서 수행할 일은 무엇인가. 셋째, 어떤 환경에서 어느 정도 수준으로 동작하면 성공인가.

예를 들어 이렇게 쓸 수 있습니다.

혼자 작업하는 메이커가 퇴근 전 작업실 상태를 확인하는 불편을 줄이기 위해, 로봇은 창문과 인두 전원 상태를 촬영하고 이상 여부를 알려 준다. 이 로봇은 작업실 내부의 고정된 두 지점을 1분 안에 확인할 수 있으면 성공이다.

이 정도만 써도 엄청난 차이가 납니다. 이제 이 프로젝트는 더 이상 "뭔가 똑똑한 순찰 로봇"이 아닙니다. 사용자와 문제와 작업과 성공 기준이 있는 실제 프로젝트가 됩니다.

예시: 책상 안전 점검 로봇 기획하기

조금 더 감을 잡기 위해 하나의 예시를 끝까지 짧게 따라가 봅시다.

처음 떠오른 아이디어는 이렇습니다.

"책상을 정리해 주는 AI 로봇을 만들고 싶다."

멋지지만 너무 넓습니다. 이 문장을 기획 가능한 형태로 줄여 보겠습니다.

문제는 무엇일까요. 책상 전체가 어질러진다는 사실 자체보다 더 아픈 지점이 있습니다. 납땜 인두나 배터리 충전기 같은 물건을 켠 채 두고 퇴근하는 실수입니다. 그러면 문제는 "책상 정리"가 아니라 "퇴근 전 위험 물건 점검 누락"이 됩니다.

사용자는 누구일까요. 전자 작업을 혼자 하는 하드웨어 개발자 또는 메이커입니다.

작업은 무엇일까요. 사용자가 퇴근 버튼을 누르면 로봇이 책상 위 두세 구역을 카메라로 확인하고, 인두 전원 LED와 충전 상태를 보고, 이상이 있으면 음성과 메시지로 알려 주는 것입니다.

환경은 어떨까요. 좁은 책상 위, 비교적 고정된 조명, 카메라 시야가 확보된 위치입니다. 이동은 필요 없고 팬-틸트 카메라만으로도 충분할 수 있습니다.

성공 기준은 무엇일까요. 지정된 세 물건을 30초 안에 확인하고, 위험 상황을 놓치지 않는 것입니다.

이제 이 프로젝트는 훨씬 현실적입니다. 바퀴도 필요 없고, 로봇팔도 필요 없고, 대형 모델도 꼭 필요하지 않을 수 있습니다. 처음 생각보다 덜 화려하지만, 실제로는 훨씬 더 만들기 쉽고 쓸모 있습니다.

기획이 좋은 프로젝트는 확장이 자연스럽다

문제를 잘 정의한 로봇은 처음부터 크지 않아도 됩니다. 오히려 첫 버전이 작을수록 좋습니다. 중요한 것은 다음 단계로 자연스럽게 확장될 수 있느냐입니다.

예를 들어 책상 안전 점검 로봇이 첫 버전에서 인두 전원만 확인한다면, 다음에는 충전기 상태를 추가할 수 있습니다. 그다음에는 퇴근 체크리스트를 음성으로 읽어 줄 수 있습니다. 더 나아가면 책상 위 특정 물건 위치까지 점검할 수 있습니다.

좋은 기획은 이렇게 자랍니다. 처음부터 모든 것을 하려고 하지 않고, 핵심 문제 하나를 확실히 해결한 뒤 주변 문제로 넓혀 갑니다. 반대로 처음부터 모든 문제를 한꺼번에 잡으려는 기획은 출발은 화려하지만 확장 전에 무너지는 일이 많습니다.

결국 로봇 기획은 생활을 해석하는 일이다

로봇을 잘 기획한다는 것은 대단한 기술 용어를 많이 아는 일이 아닙니다. 생활 속에서 반복되는 불편을 발견하고, 그것을 작고 분명한 작업으로 번역하는 일에 가깝습니다. 사용자가 누구인지, 로봇이 무엇을 해야 하는지, 어디에서 동작하는지, 어느 정도면 성공인지가 선명해지면 그다음 하드웨어와 소프트웨어 선택은 훨씬 쉬워집니다.

개인 개발자에게 이 습관은 특히 중요합니다. 시간도 예산도 공간도 한정되어 있기 때문입니다. 그래서 더더욱 "뭘 만들까"보다 "왜 필요할까"를 먼저 물어야 합니다. 이 질문을 건너뛰지 않는 사람은 작은 로봇을 만들어도 끝까지 갑니다.

잘 만든 로봇은 처음 봤을 때 감탄을 부르는 기계가 아닐 수도 있습니다. 대신 어느 날부터 자연스럽게 매일 쓰이기 시작하는 도구일 가능성이 큽니다. 그리고 개인 로봇 프로젝트의 진짜 출발점은 바로 거기입니다.

문제를 먼저 보고, 사용자를 떠올리고, 작업을 분명히 자르는 것. 그 세 가지가 정리되면 로봇은 비로소 기술 덩어리에서 제품의 씨앗으로 바뀝니다.