DevOps로 임베디드 소프트웨어 과제 극복하기

DevOps는 더 많은 애플리케이션과 새로운 기능을 더 짧은 시간에 제공해야 하는 임베디드 소프트웨어 시장 수요를 충족하는 최선의 방법으로 여겨집니다.

임베디드 기기 소프트웨어 개발에 완벽한 폭풍이 불어오고 있습니다. 5G 같은 새로운 연결 옵션으로 혁신적인 커넥티드 기기 애플리케이션이 가능해지면서 임베디드 기기가 확산되고 있으며, 새로운 분석 및 AI 기능을 활용하는 용도도 확대되고 있습니다. 동시에 진화하는 사이버 공격 대응 같은 기기 수명주기 요구사항으로 소프트웨어 변경을 신속하게 생성하고 배포해야 합니다.

이러한 상황은 개발 및 운영 인력에 새로운 요구를 제기합니다. 점점 더 DevOps가 더 많은 애플리케이션과 새로운 기능을 더 짧은 시간에 제공해야 하는 시장 수요를 충족하는 최선의 방법으로 간주됩니다. RTInsights는 최근 Wind River의 제품 관리 수석 디렉터 그레이엄 모프(Graham Morphew)와 만나 임베디드 기기 소프트웨어 개발의 과제, 기존 환경과 임베디드 기기의 DevOps 차이점 등을 논의했습니다.

다음은 대화 요약입니다.

RTInsights: 임베디드 기기의 DevOps는 소프트웨어 개발을 위한 기존 DevOps 접근 방식과 어떻게 다릅니까?

모프: IT 기업 기반 환경의 기존 DevOps를 보면, 어디서나 실행되는 환경이 있습니다. 클라우드의 인텔 서버나 인텔 PC에서 실행됩니다. 임베디드는 완전히 다릅니다. 최종 실행 환경은 보통 개발에 사용하는 아키텍처와 다릅니다. 최종 하드웨어의 다양성과 배포 방식 때문에 과제가 더 많습니다. 예를 들어 클라우드용 소프트웨어를 만들면 Google Cloud, Azure, AWS 환경에서 돌아간다는 것을 압니다. 하지만 임베디드 소프트웨어를 만들면 배포 환경 선택이 거의 무한하며, 기기가 원격지에 있을 수도 있습니다.

소프트웨어를 생각하는 방식과 이것이 DevOps 구현 과제로 어떻게 이어지는지 많은 차이가 있습니다.

전용 하드웨어, 크로스 컴파일, 크로스 디버깅, 메모리 풋프린트, 보안 문제를 다뤄야 합니다. 클라우드 환경처럼 손끝에서 거의 무제한 리소스를 쓸 수 없습니다. 염두에 둬야 할 '실행의 섬'이 있습니다. 보안도 걱정해야 합니다. 기기의 물리적 보안을 반드시 통제하는 것은 아닙니다. 기기 물리적 변조를 감안해야 할 수도 있습니다.

또 다른 과제는 이러한 기기에서 데이터를 수집하기가 더 어렵다는 점입니다. DevOps 환경에서는 지속적인 피드백 루프를 원합니다. 개발이 통제된 서버에서 이뤄지면 쉽습니다. 하지만 기기 이야기를 하면 원격으로 분산되어 있고 항상 온라인 상태가 아닐 수 있습니다. 기존 DevOps와 임베디드 소프트웨어 DevOps를 비교할 때 많은 다른 문제가 작용합니다.

RTInsights: 왜 임베디드 기기 커뮤니티가 DevOps로 이동할까요? 왜 매력적으로 변하고 있으며, 시장에서 무엇이 이를 이끄나요?

모프: 임베디드 소프트웨어에는 더 빈번한 업데이트와 더 높은 품질에 대한 수요가 커지고 있습니다. 거기에 도달하려면 자동화가 과정을 돕는 큰 역할을 합니다. 자동화는 DevOps와 임베디드 소프트웨어의 미래에서 큰 역할을 할 것입니다. 10~20년 전으로 돌아가면 하드웨어가 기기 역량을 주도하는 데 초점이 맞춰져 있었습니다. 이제 기기 공급업체 간 차별화 기술의 훨씬 많은 부분이 소프트웨어입니다.

기업들을 임베디드 시스템용 DevOps로 밀어붙이는 또 다른 요인은 Wind River에서 자주 보는 소프트웨어 개발 인구 통계의 변화입니다.

두 개의 뚜렷한 진영이 있습니다. 전통적인 임베디드 소프트웨어 개발자와 다른 소프트웨어 도메인에서 지능형 기기 분야로 들어오는 신입 졸업생 또는 개발자들입니다. 전통 개발자들은 연령대가 높고 다수가 은퇴합니다. 저처럼 대학 졸업 후 하드웨어 매뉴얼을 보고 레지스터를 프로그래밍하던 시기에 시장에 진입한 사람들이 있습니다. 요즘 대학 과정에서는 그런 것에 많은 시간을 쓰지 않습니다.

이제 대학생인 아들이 있습니다. 그는 Python으로 프로그래밍합니다. C를 처음 배웠는데 큰 눈뜨는 경험이었습니다. Python은 훨씬 높은 수준의 추상화를 제공합니다.

DevOps는 애플리케이션 환경과 기기 소프트웨어 개발자에게 친숙한 환경을 만들고자 하는 바람 사이의 장애물을 극복하는 데 도움이 될 수 있습니다. 이것이 필요한 이유는 기기를 만드는 기업들이 새로운 소프트웨어 개발 인재를 확보하는 데 어려움을 겪기 때문입니다.

최근 인턴으로 채용한 누군가와 이야기했는데, 그의 많은 동급생들이 실리콘밸리로 가서 Facebook, Google, Apple, Tesla 같은 기업에서 일하고 싶어 한다고 했습니다. 산업용이나 항공우주 및 방위 분야 기업들에게는 들어와서 기초적인 C 환경으로 임베디드 기기를 프로그래밍할 소프트웨어 인재를 끌어들이는 것이 더 큰 도전일 수 있습니다.

이를 극복하기 위해 일부 기업은 새로운 세대 소프트웨어 개발자에게 익숙한 환경을 제공하는 것이 도움이 된다고 생각합니다. 그것이 Wind River가 Visual Studio Code 환경을 채택하는 이유 중 하나입니다. Visual Studio Code는 시장에 나온 이후 급속히 인기를 얻은 환경입니다. 우리가 대화한 신입 졸업생 관점의 모든 사람이 VS Code에 매우 익숙하며, Eclipse 같은 구형 환경 경험은 적습니다. 그래서 때로는 이미 청중이 있는 곳에 가야 합니다.

RTInsights: 기업들이 DevOps 솔루션을 도입하려 할 때 어떤 문제가 있습니까? 임베디드 기기 영역과 다른 도메인의 주요 과제는 무엇입니까?

모프: 가장 큰 과제는 기업 내부에서 일어나야 하는 문화적 변화입니다. 이것은 반드시 임베디드 특유의 과제는 아닙니다. 일부 소프트웨어 개발 관행에 더 깊이 뿌리박혀 있습니다.

소규모 팀이 있고, 많은 경우 개인이 매우 구체적인 작업을 합니다. 수년간 편안해하던 영역에서 벗어나야 하는 수준의 협업과 협력이 DevOps에는 필요합니다. "모두가 함께 일한다"고 말해야 합니다.

임베디드용 DevOps의 Ops 부분은 과제입니다. 클라우드용 기존 DevOps 환경에서는 Ops가 꽤 표준적입니다. 웹사이트를 운영하거나 클라우드 기반 인터페이스를 통해 무언가를 하는 애플리케이션을 개발합니다. 임베디드 이야기를 하면 현장의 기기이고, 그 기기가 하는 일은 회사별로 구체적입니다. 많은 경우 기기 제조사가 기기를 운영하는 회사가 아닙니다. 장비 제조사가 대형 전기 회사나 대형 제조사에 장비를 판매할 수 있습니다. 그 회사들이 기기를 운영합니다. 때로는 장비 제조사의 지원이 있지만, 클라우드 기반 솔루션에서 볼 수 있는 완전히 닫힌 루프는 아닙니다.

도구 세트 호환성 문제도 있습니다. 공통 개발 환경을 갖는 것이 때로 저항에 부딪힙니다. 그래서 다시 이러한 시스템을 구현하는 데 필요한 문화적, 경영적 지원 문제로 돌아갑니다.

그리고 다시 하드웨어 문제입니다. 임베디드 시장에서 흔한 주제입니다. DevOps를 현실로 만드는 데 필요한 자동화 환경을 구축할 만큼 충분한 하드웨어를 어떻게 확보하나요? 이는 지속적인 과제입니다. 일반적으로 성공한 고객들은 하드웨어와 시뮬레이션을 혼합하여 테스트 프로세스를 확장합니다.

RTInsights: DevOps 전환을 더 쉽게 만드는 도구가 있습니까?

모프: 기업들이 이 혁명을 헤쳐나가도록 돕는 것 중 하나는 도구의 가용성입니다. 이들 중 다수는 오픈 소스이거나 무료 버전이 있습니다. 과거에는 소스 코드 관리(보통 Git 변형) 중심으로 통합되는 경우가 많았습니다. 이제 조직들은 매우 소스 코드 관리 중심적인 솔루션에서 솔루션 내에 점점 더 많은 DevOps 유형 도구를 포함하는 것으로 이동했습니다. 이것이 기업들의 전환을 돕습니다.

선택지가 많습니다. 때로는 선택지가 너무 많다고 주장할 수도 있습니다. 우리가 고객들이 지금 겪는 과제는, 네, 도구는 많은데, 어떻게 그것들을 나를 위해 작동하는 솔루션으로 모으느냐입니다.

오늘날 많은 기업들이 내부적으로 팀을 구성해 디지털 중심 개발 환경으로의 전환을 관리하는 프로젝트를 시작하고 있습니다. 우리는 다른 기술적 전환에서 본 것과 같은 전환이 임베디드 공간에서도 지금 일어나고 있는 것을 봅니다. 많은 경우 '우리를 위한 완벽한 시스템을 만들자, 우리의 필요에 맞게 맞춤화하자'는 매우 DIY 정신입니다. 그런 노력은 앞으로 그것들을 유지하는 데만 회사에서 점점 더 많은 자원을 빼갑니다. 그것이 반드시 그들이 투자하고 싶은 곳은 아닙니다. 그 접근 방식은 시간이 지나면서 사람들이 자신의 환경을 더 많이 유지보수해 줄 다른 회사를 찾는 방향으로 진화할 것입니다.

궁극적으로 기업들이 삶을 더 쉽게 만들 수 있는 또 다른 영역은 애플리케이션 개발과 그들이 실행 중인 소프트웨어 플랫폼 유지보수 사이에 명확한 분리를 두는 것입니다. 과거에는 작은 팀이 둘 다 했고, 애플리케이션과 플랫폼이 서로 합쳐져 있었습니다. 하지만 이제 소프트웨어를 모듈화하고 사람들이 가장 기술이 좋은 분야에서 일하게 하려면 그 명확한 분리가 필요합니다.

RTInsights: 임베디드 기기용 소프트웨어 개발과 테스트를 더 쉽게 만드는 솔루션의 산업 동인은 무엇입니까?

모프: IT와 OT 세계의 융합이 있습니다. 기기들이 인터넷에 연결됩니다. 이것이 기업들이 소프트웨어 제공 방식을 재검토하게 만드는 큰 동인입니다. 또한 기기의 소프트웨어 업데이트 능력과 관련된 규정 준수 요구사항이 있는 여러 산업이 있습니다. 의료 분야에서 볼 수 있는데, 이제 보안 취약점이 알려지면 기기를 업데이트할 수 있음을 증명해야 합니다. 이것은 생사가 걸린 시나리오일 수 있습니다. 그런 문제가 생기면 대처할 수 있음을 증명할 수 있어야 합니다.

그런 동인들이 기업들이 원격 업데이트 능력 측면에서 사용하는 프로세스를 재검토하게 만듭니다. 우리가 보는 것은 많은 대기업이 이러한 디지털 네이티브 신생 및 떠오르는 기업들의 위협을 느낀다는 것입니다. 이를 설명하는 용어까지 있습니다. '테슬라화(Teslafication)'라는 말을 듣습니다. 그들은 벽돌, 모르타르, 강철, 철 같은 하드웨어 연관 사고방식 대신 테슬라처럼 매우 소프트웨어 중심적인 비즈니스가 되어야 한다고 말합니다. 점점 더 그들이 만드는 것에서 실행되는 소프트웨어로 제품을 차별화해야 합니다.

팬데믹도 이 추세를 가속화했습니다. 소프트웨어 중심 인력의 대부분이 재택근무를 합니다. 많은 경우 상당수 직원이 이 상황이 끝나도 사무실로 복귀하지 않을 것입니다. 그것은 큰 변화입니다. 개발자들에게 그 상황을 생산적으로 만들기 위해 일하는 방식을 바꿀 필요가 있습니다. 그것은 과제입니다. 더 많은 협업 도구와 일이 처리되는 방식의 표준화가 어느 정도 필요하다고 외칩니다. 사람들이 대면으로 일하고 전통적인 방식으로 협업하지 않기 때문입니다.

RTInsights: 왜 빠른 소프트웨어 반복이 모든 산업에서 중요하고 경쟁력 있는 이점이 되었습니까? 그리고 그것이 자동화된 테스트의 필요성과 어떻게 관련됩니까?

모프: 워터폴 모델에서 더 애자일한 모델로 전환한 여러 프로젝트를 겪었습니다. 지속적인 테스트, 자동화된 테스트를 수행하는 능력이 종종 생산성 향상의 제한 요소입니다. 빠르게 달리면서 여전히 품질을 유지하려면 필수입니다. 이것은 디지털 트윈을 보유하면 많은 테스트를 수행할 수 있고, 대규모로 할 수 있는 특정 영역입니다.

임베디드에 DevOps가 적용 가능하게 된 큰 진전 중 하나는 임베디드 기기의 시뮬레이션을 가져와 클라우드 기반 환경에서 대규모로 사용하는 능력입니다. 그렇게 하면 백 개의 테스트를 동시에 실행할 수 있습니다. 클라우드 리소스만으로 제한됩니다. 그것은 많은 기업들이 겪고 있는 변화 중 하나이며 궁극적으로 매우 높게 평가하는 것입니다.

Wind River에서 수년 동안 시뮬레이션 사업을 해왔습니다. 일부 초기 도입자들은 자체 서버에서 대규모 시뮬레이션을 확장하며 많은 것을 했습니다. 하지만 클라우드로 옮기면 6개월마다 새 서버를 살 필요가 없습니다.

사용하는 하드웨어 유형과 양을 통제할 수 있습니다. 그때그때 필요한 것에 따라 다이얼 업하고 다운할 수 있습니다. 큰 하드웨어와 이를 유지하는 IT 팀의 자본 지출 대신 말입니다. 현재는 하이브리드 클라우드 환경 같은 균형을 봅니다. 일부 테스트는 온프레미스에서 로컬로, 일부는 퍼블릭 클라우드에서 수행됩니다.

RTInsights: 빠뜨린 다른 말씀하고 싶은 점이 있습니까?

모프: DevOps와 임베디드 소프트웨어 개발을 더 클라우드 네이티브, 클라우드 중심 환경으로 이동시키는 것에 대해 이야기할 때, 제가 제품 관리자로서 개인적으로 본 몇 가지 큰 변화가 있습니다.

그 중 하나는 협업입니다. Linux 빌드를 완료하려 했습니다. 저는 검증된 Linux 엔지니어는 아닙니다. 빌드가 올바르게 작동하게 하는 데 문제가 있었습니다. 이것을 하는 동안 우리 Linux 소프트웨어 아키텍트 중 한 명이 제가 여러 번 빌드에 실패한 것을 볼 수 있었습니다. 그는 인스턴트 메시징 앱으로 저에게 연락해 "이봐, 당신이 어려움을 겪는 것 같아서 봤더니, 설정만 바꾸면 될 것 같아. 내가 그냥 고쳐놨어요."라고 말했습니다.

내 PC에 소프트웨어가 설치된 다른 환경에서 개발했다면 아무도 내가 문제를 겪는 것을 몰랐을 것입니다. 내가 나가서 물어봐야 했을 겁니다. 또한 아마 같은 시나리오를 재현하지 못했을 겁니다. 아마 하루 종일 거기에 매달렸을 겁니다. 그리고 어느 정도 지나면 포기했을지도 모릅니다. 로컬로 설치할 필요 없는 소프트웨어에 빠르게 접근하고, 팀원들과 공통 샌드박스에서 놀 수 있는 능력은, 본질적으로 팀원들 사이에 이런 종류의 공유 자산을 갖는 것만으로도 일하는 방식을 어떻게 바꾸는지에 대해 제게 큰 눈뜨는 경험이었습니다.

RTInsights: 다른 것 있습니까?

모프: 그리 멀지 않은 미래에 기대하는 한 가지는 디지털 피드백 루프를 갖는 것입니다. 기기에서 데이터를 가져오고, 개발 환경에서 데이터를 가져와, 그것을 피드백하여 소프트웨어를 개선하는 것입니다. AI와 머신러닝도 여기에 작용합니다. 이 기기들에서 어떤 정보를 얻을 수 있습니까? 그것을 잠재적으로 대규모 클라우드, 빅데이터 모델이나 엔진으로 분석하고, 미래 소프트웨어 개발에 피드백할 수 있습니까? 그것은 전체 시스템을 최적화하는 데 도움이 될 수 있습니다.