2023-09-22 @이영훈
로봇 플랫폼을 만들면서 얻은 로봇 플랫폼 개발 원칙
•
로봇 플랫폼은 우리가 익숙한 플랫폼(쇼핑몰 쿠팡, 메신저 라인, SNS 인스타그램)과 다른 측면들이 있습니다
2년 동안 3번의 시스템(진짜 많이 만들었다 고생 많았어...)을 만들면서 로봇 플랫폼이라는 특수성을 고려한 제가 생각한 개발 원칙을 정리해보았습니다
제가 도출한 다음 원칙들은 플로틱이 성장하면서 계속 변할 것이고 모든 문제를 다 해결할 수 없습니다
우리를 둘러싸고 있는 것들
이 다람쥐도 주위 환경에 영향을 받는데, 나도 마찬가지로 주위 환경에 영향을 받겠지…
우리 솔루션은 다음의 환경을 고려하여 개발하고 있습니다
•
B2B 비즈니스 모델
•
우리는 기업이고 특히 빠른 성장을 추구하는 스타트업
•
IoT는 IoT답게 개발해야함. 즉, 로봇 플랫폼은 로봇 플랫폼답게 개발해야함
◦
익숙한 플랫폼(쇼핑몰 쿠팡, 메신저 라인, SNS 인스타그램)과 다른 접근 방식으로 개발해야함
이 3가지 환경 요소를 하나씩 살펴보겠습니다
1. B2B 비즈니스 모델
•
고객사마다 다른 경험과 다양한 물류센터 환경을 가지고 있습니다
◦
우리 솔루션이 높은 시장 지배력을 기반으로 de facto standard(사실상의 표준)가 되거나
◦
다양한 고객의 니즈를 우리가 맞추거나
•
고객마다 요구하는 솔루션이 대동소이 
◦
(비즈니스 관점) 대동에 초첨. 비슷하니까 우리 솔루션 그대로 쓸 수 있지 않을까?
◦
(개발 관점) 소이에 초점. 다른 부분 때문에 다른 솔루션이고, 향후에도 이 쪽 방향으로 요구사항이 계속 들어온다는 것을 경험적으로 앎
▪
산소(O)를 팔고 있는데 수소(H) 한 스푼 추가하면 산소와 비슷한 게 아니라 완전 다른 존재인 물(H2O)이 탄생
•
B2B의 B는 대기업이 협상 주인공인 경우가 많습니다
◦
대기업이 협상 주인공인 이유 (1차적인 생각)
▪
우리 솔루션을 지불할 경제적 역량이 높다
▪
많은 물동량을 처리하고 있기에 효율을 개선했을 때 효과가 크다
◦
[대기업 입장을 생각해보기] 대기업은 전통적인 개발 문화를 가지고 있고, 의사결정권자의 정치적인 입장을 고려하여야 합니다
▪
변화를 꾀했을 때 얻는 것보다 잃을 것이 많기 때문에 (우리가 보기엔 비효율적이라도 그들의 입장이 되었을 때 저라도 그렇게 했을 것)
▪
On-Premise (서버랙) > Cloud (AWS)
2. 우리는 기업이고 특히 빠른 성장을 추구하는 스타트업
•
기업과 공기업의 차이 - Risk taking
◦
기업은 Risk 감수하더라도 성장을 위해서 도전
◦
공기업은 국민을 볼모로 Risk를 감수하기보다는 안정을 추구
•
특히, 더 빠른 성장을 추구하는 스타트업은
◦
단기간에 더 높은 성과를 만들어내기 위해 노력
◦
변화와 기회를 잘 포착하고 이용해야함
위의 요소들은 일정의 변경을 만들고 짧은 개발 일정을 요구함
3. 로봇 플랫폼은 로봇 플랫폼답게 개발해야함
익숙한 플랫폼(쇼핑몰 쿠팡, 메신저 라인, SNS 인스타그램)과 다른 접근 방식으로 개발해야합니다
1차원적으로 생각해보면,
•
[메신저 라인] 하나의 작업 (메시지 보내기) - 수행시간 50ms 이내
•
[로봇] 하나의 작업 (이동하기) - 수행시간 1분 이내
1.
로봇의 작업이 실패할 확률이 더 큽니다
•
수행시간이 더 긴 작업이 실패할 확률이 높습니다
•
텍스트 메시지를 보낼 때보다 사진, 동영상을 보낼 때 실패할 확률이 높은 것을 비교해서 생각해시면 편합니다
•
그래서 재시작(자동 복구) 기능이 필요합니다
2.
로봇의 작업(이동하기)을 위한 프로세스가 복잡한데 내부의 모든 걸 알수는 없습니다
•
로봇에게 이동 명령을 통해서 움직이려면 네비게이션 등 내부 로직은 알기 힘듭니다
•
라인으로 메시지 보낼 때, 문자 encoding은 어떻게 하고, 이미지는 어떤 형식으로 압축할 지 등은 관심없고 알아서 잘 (알잘딱깔센)해서 기능을 사용하는 것과 비슷합니다
•
로봇 내부 로직을 신경 쓸 필요가 없게 추상화
•
복잡한 시스템 관리를 단순화
3.
다양한 종류의 IoT [다양한 형태의 로봇, 심지어 드론과 지게차]를 같은 시스템으로 컨트롤할 수 있도록 설계해야함
•
로봇의 버전이 변하더라도 같은 명령어를 사용해야 한다 (Clody, Flody)
•
같은 명령으로 로봇과 드론에게 A-01-01 로 이동시킬 수 있어야 한다
•
높은 호환성과 이식성
설계 원칙
5가지 원칙들로 숲처럼 사람들에게 감동을 주는 솔루션을 만들면 좋겠습니다
위의 3가지 환경을 2년 동안 경험하면서 도출한 설계 원칙입니다
1. 선언형 개발 방식(Declarative) > 명령형 개발 방식(Imperative)
•
[명령형] 로봇에게 작업을 Picking 작업을 할당할 때,
◦
오른쪽으로 10m를 4m/s로 가고, 코너돌 때 속도는 1m/s로 설정하고 다시 앞으로 20m 이동하고….
◦
(명령이 너무 복잡하고, 만약에 중간에 사람이 길막하면 다시 이동 명령을 내려야함)
•
[선언형] 로봇에게 작업을 Picking 작업을 할당할 때,
◦
A-01-01로 이동해줘
◦
(끝!)
•
다양한 IoT기기에 적용 가능
◦
[로봇, 선언형] A-01-01로 이동해줘
▪
로봇: 네비게이션 켜고 바퀴 굴리면서 스스로 잘 도착함
◦
[드론, 선언형] A-01-01로 이동해줘
▪
드론: 날개 펴고 날아가면서 스스로 잘 도착함
•
복잡한 시스템 관리의 단순화
•
자동 복구 기능 구현이 쉬움
•
복잡한 IoT의 내부 로직을 추상화 가능
•
선언형 개발 방식의 일환으로 Device Shadow 기능
•
다양한 IoT를 동일한 명령으로 제어 가능
2. MSA(Micro Service Architecture)로 개발하면 좋음
•
대동소이. 고객사마다 사실상 다른 시스템을 요구함
Core 서비스 로직은 그대로 두고, 고객사 별로 요구하는 기능이나 인터페이스만 추가 개발하기
3. On-Premise를 고려하여 기술 스택 선택하기
대기업과 일 할 때는 대기업의 개발 룰을 따라주자. (로마에 가면, 로마법을 따르기)
이식성이 높은 소프트웨어 또는 상업적으로 사용 가능한 오픈소스를 사용하기
•
(사례) AWS의 IoT Core를 사용하지 않고 Kafka(오픈소스)를 사용하여 플랫폼과 로봇 간의 통신하기
4. 한 번에 2개 이상의 기술을 도입하지 않기
•
시간이 충분할 것이라 판단하고 2개 이상 기술을 동시에 진행하기 보다
•
회사의 빠른 성장 속도를 고려하여, 한 번에 한 개의 기술을 도입한다
•
두 개 동시에 병렬로 진행하면 둘 다 진행 진행중에 Holding하고 고객사 PoC 하느라 바쁠 수 있습니다
5. 테스트코드를 작성하기
로봇을 관리하고 명령을 내리는 기능은 다양한 기능들의 종합 결정체
•
다양한 기능들이 있기 때문에 실패 지점이 많음
1.0 x 1.0 x 1.0 x 1.0 x 1.0 x 1.0 x 1.0 = 1.0
이 중에서 하나라도 1.0 밑으로 떨어지면 정상적으로 동작하지 않음
•
기능을 추가 개발할 때, 다른 기능을 정말로 건드리지 않고 개발할 수 있을까?
다른 기능을 하나도 건드리지 않고 개발 가능한 것은 상상속의 이야기임
◦
우리는 로봇이라는 누구도 가보지 않은 길을 가고 있기 때문에 기획이 완벽할수도 없고
◦
사용자들은 각자만의 로봇 사용법이 머릿속에 있어서 다양한 요구 사항이 있기 때문
◦
기능을 추가/수정할 때 현재 기능이 예상대로 잘 동작하는 지 확인하기 위해서, 다른 기능을 건드리지 않았는 지 테스트코드를 작성해야합니다
조선왕조실록처럼 오래도록 가치있는 원칙이 되었으면 좋겠습니다