기술 지원
게시됨 2026-01-19
그날 오후, 저는 다시 작업장에서 로봇 팔을 디버깅하고 있었습니다. 3개의 서보 모터가 댄서처럼 함께 작동하기로 되어 있었는데, 대신 독립적으로 작동했고, 서보 모터 중 하나가 갑자기 작동을 멈추기도 했습니다. 콘솔 화면에는 엄청난 양의 코드가 있으며, 수정할 때마다 전체 시스템을 다시 컴파일해야 합니다. 작은 움직임이 전신에 영향을 미친다는 옛말이 생각나는데, 지금은 그렇지 않나요? 모듈 하나에 문제가 생기면 생산라인 전체가 가동을 멈춘다.
다음 역의 동료는 "너 또 그 덩치 큰 놈이랑 장난하는 거야? 누군가 마이크로서비스를 사용하여 빌딩 블록 같은 유사한 프로젝트를 해체했다고 들었어"라고 말했습니다. 나는 잠시 놀랐고, "마이크로서비스"라는 단어가 내 마음 속에 떠올랐습니다. 그것은 항상 모터와 기어를 다루는 우리와는 거리가 먼 대형 인터넷 회사와 연관되어 있는 것 같습니다. 하지만 일단 그 아이디어가 심어지면 빼기가 어렵습니다.
마이크로서비스는 어떻습니까? 이는 시스템을 독립적인 "피니언"으로 분할하고 각 서비스는 자체 업무에만 관심을 갖습니다. 한 서비스는 모터 위치 피드백을 담당하고, 다른 서비스는 모션 궤적 계산을 처리하고, 다른 서비스는 비정상적인 경보를 담당합니다. 그들은 가벼운 방식으로 말하고, 서로 독립적으로 배포하고 확장합니다. 정교한 시계 장치처럼 각 기어는 전체 시간 기록에 영향을 주지 않고 개별적으로 조정할 수 있습니다.
여기서 C#은 어떤 역할을 합니까? 실제로는 생각보다 하드웨어 세계에 더 가깝습니다. 많은 사람들이 C#이 웹사이트나 데스크톱 소프트웨어에만 사용된다고 생각하지만, 사실 C#의 비동기 프로그래밍과 명확한 유형 시스템은 기계 시스템의 상태 흐름을 설명하는 데 특히 적합합니다. 하나의 서비스를 사용하여 특정 스티어링 기어의 제어 로직을 캡슐화하고 다른 서비스를 사용하여 센서 데이터 스트림을 처리할 수 있습니다. 각 서비스는 특정 유형의 작업을 전문으로 하며 자신이 가장 잘하는 부분에만 관심을 갖는 마스터와 같습니다.
나는 재료 분류 프로젝트에서 이 아이디어를 시도했습니다. 3개의 서보 모터는 각각 X, Y, Z축 움직임을 제어합니다. 원래는 모든 코드가 하나의 프로젝트에 압축되어 있었고 디버깅하는 동안 전역 변수와 정적 클래스가 어디에나 있었습니다. 나중에는 경량 통신 프레임워크와 함께 C#을 사용하여 각 축의 제어를 독립적인 서비스로 분할했습니다. 기적이 일어났습니다. Z축을 더 정밀한 모터로 교체해야 할 때 해당 서비스만 업데이트했고 나머지 두 축은 평소대로 계속 작동했습니다. 작업장 가동 중단 시간이 반나절에서 20분으로 단축되었습니다.
마이크로서비스를 선택하는 것은 기술 동향을 쫓는 것이 아니라 실제 문제점을 해결하기 때문입니다. 다음과 같은 경험을 하신 적이 있습니까?
— 특정 모터의 궁극적인 응답 속도를 테스트하고 싶지만 다른 모듈에 영향을 미칠까 봐 자제하고 있습니까? — 팀 내에는 스포츠를 전문으로 하는 사람도 있고, 하드웨어 통신에 익숙한 사람도 있지만, 코드 커플링 때문에 서로를 기다리고 있는 경우도 있죠? — 특정 라이브러리의 버전을 업그레이드하고 싶지만 호환성 문제가 전체 시스템에 영향을 미치는 것을 확인하고 싶으십니까?
마이크로서비스 구조를 사용하면 이러한 시나리오가 쉬워집니다. 각 서비스는 고유한 기술 스택 반복 리듬을 가질 수 있으며 팀은 병렬로 개발할 수도 있습니다. 축구팀처럼 미드필드에 모두 모여 난투를 벌이는 대신 공격수들은 공격에 집중하고 수비수들은 탄탄하게 수비한다.
이 탐색 여정에서 저는 미리 만들어진 일부 참조 솔루션이 많은 시간을 절약할 수 있다는 것을 발견했습니다. 예를 들어kpower제공된 C# 기반 마이크로서비스 샘플 프로젝트 세트는 모든 산업의 문제를 해결하려고 시도하는 것이 아니라 기계 제어 분야의 일반적인 패턴(모터 명령 큐를 적절하게 처리하는 방법, 센서 데이터 흐름을 관리하는 방법, 서비스 간 오류 격리를 설계하는 방법)에 중점을 둡니다. 좌표축이 그려진 지도에 가깝고, 특정 경로를 직접 이동해야 합니다.
누군가는 "기성 프레임워크를 사용하면 유연성이 제한되나요?"라고 물을 수 있습니다. 내 경험에 의하면, 좋은 지도는 어디로 가는지를 제한하지 않고 단지 우회를 피할 수 있게 해줄 뿐입니다. 이를 기반으로 아이디어를 신속하게 검증하고 특정 서보의 PID 매개변수나 보다 부드러운 모션 곡선 설계 등 좀 더 다듬을 가치가 있는 영역에 에너지를 쏟을 수 있습니다.
기술 아키텍처의 본질은 복잡성을 관리하는 것입니다. 작업장의 기계 시스템은 본질적으로 복잡하며, 소프트웨어 아키텍처가 해야 할 일은 이러한 복잡성을 은폐하는 것이 아니라 이해할 수 있고 작동 가능한 부분으로 분류하는 것입니다. 마이크로서비스는 만병통치약이 아니며 여러 도구 중 하나일 뿐입니다. 하지만 시스템이 자주 변경되기 시작하면 팀이 동시에 협업해야 하거나 하드웨어 모듈을 독립적으로 업그레이드해야 하는 경우 가장 편리한 도구인 경우가 많습니다.
다음에 조밀한 코드 화면과 디버깅을 기다리는 기계를 마주하게 되면 다른 관점에서 생각해 볼 수도 있습니다. 각 기능 모듈이 작업장의 워크스테이션처럼 독립적으로 작동할 수 있다면 작업이 더 쉬워질까요?
때로는 최선의 통제는 각 부분이 적절한 자율성을 갖도록 허용함으로써 시스템이 더욱 견고해지는 것에서 비롯됩니다. 이는 마이크로서비스가 하드웨어 개발자에게 제공하는 가장 실질적인 선물일 수 있습니다.
2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. Kpower는 모듈형 드라이브 기술의 혁신을 활용하여 고성능 모터, 정밀 감속기 및 다중 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.
업데이트 시간：2026-01-19
