기술 속도의 힘

[힘힘]

기술 속도의 힘

2024년 3월 7일| 회견

에 의해토마스 딜레이트

공유하다

인쇄

구하다

Hivemind Technologies의 CEO는 혁신을 위한 소프트웨어 개발 속도를 높이는 데 중요한 단계를 설명합니다.

가장 인기 있는 통찰력

1. 생성적 AI 재설정: 2024년에 잠재력을 가치로 전환하기 위한 재배선
2. 생성적 AI가 은행의 위험 및 규정 준수 관리에 어떻게 도움이 되는지
3. 생성 AI의 경제적 잠재력: 차세대 생산성 개척지
4. 이사회 이사직의 복잡성 증가
5. 친절하다는 것은 멋진 일이다: 직장에서의 공감의 가치

베를린에 본사를 둔 소프트웨어 엔지니어링 기업인 Hivemind Technologies의 CEO인 Erik Schmiegelow에 따르면, 거북이와 토끼라는 오래된 속담에도 불구하고 , 디지털 혁신에 있어 느리고 꾸준한 것은 경주에서 승리하지 못한다고 합니다. Hivemind의 접근 방식은 가정을 검증하고 프로세스 위험을 제거하기 위해 소규모 증분 릴리스를 통한 빠른 소프트웨어 제공에 중점을 둡니다. Schmiegelow는 McKinsey 파트너 Thomas Delaet과의 토론에서 Hivemind의 속도에 대한 접근 방식을 위험 감소를 위한 혁신의 주요 기준으로 설명하고, 퍼블릭 클라우드의 장단점, 생성 AI(gen AI)가 개발자 생산성에 미치는 영향을 설명합니다. 다음은 해당 대화에서 편집된 하이라이트입니다.

속도로 가치를 전달하다

Thomas Delaet: 속도를 혁신의 주요 가치 동인으로 보는 이유는 무엇입니까?

Erik Schmiegelow: 속도는 매우 중요합니다. 특히 매우 복잡한 환경에서 작업할 때는 더욱 그렇습니다. 반대로 그린필드 프로젝트를 살펴보면 매우 간단합니다. 당신은 깨끗한 슬레이트를 가지고 있으며 기본적으로 다른 부서나 시스템의 위험이나 간섭이 거의 없이 시스템을 설계할 수 있습니다.

현대 IT의 모습은 그렇지 않습니다. 신규 프로젝트가 있는 경우는 거의 없으며 대부분의 경우 가능한 한 많은 피드백을 수집해야 합니다. 통합 중단점과 문제를 가능한 한 빨리 노출해야 합니다. 이를 통해 변경 사항을 계획하고 적응할 수 있기 때문입니다. 반대로 속도가 중요한 이유도 바로 이것이기 때문입니다.

사용자에 대한 소규모 증분 릴리스의 지속적인 흐름을 설정함으로써 모든 가정을 검증할 수 있습니다. 확인할 수 없는 사항에 대해서는 최대한 미리 계획을 세우기보다는 문제를 노출하고 즉시 처리할 수 있습니다. 그렇기 때문에 속도는 소프트웨어 제공 프로젝트의 위험을 제거하는 데 매우 중요한 도구입니다.

완료하는 데 수년이 걸리는 대규모 공공 부문 프로젝트가 있는 경우가 많으며, 소프트웨어가 최종적으로 사용자에게 출시되면 문제가 나타나기 시작합니다. 그리고 이러한 접근 방식의 문제점은 문제를 예상하고 검증하지 않은 기능을 계획하는 데 많은 시간을 낭비한다는 것입니다.

보안을 최우선으로 생각

Thomas Delaet: 위험 증가에 대한 우려 때문에 일부 기업에서는 이러한 속도 주장을 확신하지 못하는 것 같습니다. 두 번째 반론은 지속적인 소프트웨어 흐름을 통합하는 더 넓은 생태계 내의 여러 당사자에게 내재된 문제와 관련이 있습니다. 그렇다면 위험과 통합의 관점에서 속도를 어떻게 주장할 수 있을까요?

Erik Schmiegelow: 보안에 대한 논의부터 시작하겠습니다. 특히 규제 대상 산업에서는 보안에 대한 논의가 중요하기 때문입니다. 보안에 대한 전통적인 접근 방식은 본질적으로 침투 테스트, 보안 평가, 코드 검토 등을 통해 시스템에 대한 대규모 일회성 감사를 수행하는 것입니다. 이는 일반적으로 릴리스가 거의 없는 모놀리식 레거시 시스템에서 꽤 잘 작동하는 것입니다.

그러나 그것은 더 이상 우리가 살고 있는 세상이 아닙니다. 일반적으로, 특히 규제된 환경에서 시스템 환경은 함께 작동하는 다양한 구성 요소의 조합입니다. 이는 기존의 단일 지점 및 체인 끝 감사 프로세스가 모든 잠재적 문제를 다루지는 않는다는 것을 의미합니다.

SecDevOps(보안, 개발, 운영)라고 하는 접근 방식을 통해 보안 고려 사항과 보안 측면을 빠른 제공 프로세스에 통합해야 합니다. 특히 “DevOps” 앞에 “Sec”을 배치했습니다. 이는 설계상 보안의 중요성을 강화하기 때문입니다. 이는 빠른 전달 프로세스의 필수적인 부분으로, 전달의 각 단계에는 자체 보안 검사, 보안 감사 및 애플리케이션의 프로세스와 아키텍처에 반영된 설계 고려 사항이 있습니다. 우리는 보안이 DevOps와 긴밀하게 결합되어 있는지 확인하기 위해 지속적인 테스트와 자동화에 크게 의존하고 있습니다. 왜냐하면 발생할 수 있는 취약점의 양이 기존 단일 감사에서 다룰 수 있는 것보다 훨씬 더 많기 때문입니다.

이 접근 방식은 기업이 배송이 끝날 때 최종 감사를 수행하기로 선택한 경우에도 애플리케이션 보안을 크게 향상시키고 공격 각도와 지연 또는 배송 중단의 위험을 줄입니다. 보안 전문가로서 SecDevOps 모델을 수용하면 애플리케이션과 애플리케이션 작동 방식을 훨씬 더 잘 이해할 수 있습니다.

SecDevOps는 경쟁 우위를 제공합니다. 자동화 및 테스트 덕분에 팀은 취약점을 더 빨리 인식할 수 있을 뿐만 아니라 수정 사항을 더 빠르게 제공할 수도 있습니다.

재편성 및 앞서 나가기: 디지털 및 AI 리더는 나머지를 뒤처지고 있습니다.

기사를 읽다

더 나은 소프트웨어 제공을 위한 조직 문제 극복

Thomas Delaet: 브라운필드 상황을 살펴보면 일반적으로 어떤 종류의 문제가 소프트웨어 제공을 비효율적으로 만드는가?

Erik Schmiegelow: 팀과 제품 개발 사이는 물론 팀과 팀이 운영되는 환경 사이에도 단절이 발생하는 경우가 많습니다. 사일로화된 개발 프로세스에는 심각한 문제가 있습니다.

이로 인해 제품 소유자가 울타리 너머로 무언가를 개발자에게 넘겨주고, 개발자는 자신의 일을 한 다음 품질 보증 부서에 넘겨주고, 개발자는 그것을 이해하려고 노력하며, 뭔가를 잡을 수도 있고 못 잡을 수도 있고, 운영자에게 넘겨주는 상황으로 이어집니다. , 누가 그것을 생산에 투입했는지. 울타리 너머로 물건을 던지는 것 외에는 어떤 소통도 없고 피드백도 없습니다. 따라서 실제로 시장에 출시되고 고객이 사용하기 전까지는 무슨 일이 일어나고 있는지 아무도 알 수 없습니다. 이는 실제 문제입니다. 조직 매트릭스를 제외하고는 누구도 서비스를 제공하지 않는 이러한 사일로화된 접근 방식을 가질 필요는 없습니다.

또 다른 일반적인 문제는 결정이 영향을 받지 않을 때 발생합니다. 단위가 스택이나 특정 프로세스에 대해 결정하지만 궁극적으로 이를 구현해야 하는 단위는 아니라고 가정해 보겠습니다. 누구도 그 결정의 타당성에 대해 의문을 제기할 수 없습니다. 왜냐하면 결정은 완전히 분리되어 있고 모든 사람은 큰 기계의 톱니바퀴일 뿐이며 아무도 큰 그림을 볼 수 없기 때문입니다.

자체 조직되고 제품 사양 및 소유권부터 배송까지 전체 가치 사슬을 제어하는 ​​빠른 배송 팀이 도움이 될 수 있습니다. 그들은 사용자와 시장으로부터 최대한의 피드백을 얻으면서 사물을 실행하고 배포하는 방법에 대한 결정을 내릴 수 있습니다. 간섭을 줄이면 조직 내 다른 부서와의 마찰도 효과적으로 방지할 수 있습니다. 왜냐하면 조직은 작업 흐름에 미치는 영향을 반드시 검증하지 않고 팀에 무언가를 부과하는 경향이 있기 때문입니다.

우리의 경험에 따르면 이러한 모든 문제의 원인은 일반적으로 목적에 맞지 않는 특정 구조를 가진 조직입니다. 일반적으로 그 뒤에 역사적인 발전이 있기 때문입니다. 특히 꽤 오랫동안 존재해 온 기존 회사의 경우 더욱 그렇습니다. 디지털 시대 이전에 설계되었습니다.

종이 기반 프로세스가 완벽한 예입니다. 디지털 혁신 이니셔티브가 왜 그렇게 어려운가요? 본질적으로 비즈니스 프로세스는 여전히 모든 것이 종이에 기록된 것처럼 설계되어 있기 때문입니다. 특히 정부 기관과 상호 작용할 때 디지털화 접근 방식은 기본적으로 종이 양식을 이메일로 보낼 수 있는 PDF로 변환하는 것입니다. 이는 운영 환경이나 사용자에 대한 영향을 고려하지 않기 때문에 전혀 의미가 없습니다.

퍼블릭 클라우드의 장점과 단점

Thomas Delaet: 소프트웨어 제공 방식의 변화를 고려한다면 퍼블릭 클라우드는 어떤 역할을 합니까?

Erik Schmiegelow: 온프레미스로 이동할지, 퍼블릭 클라우드로 이동할지 평가하는 조직은 인프라 실행의 비용 측면을 포괄적으로 살펴봐야 합니다. OpenShift 및 Kubernetes와 같은 기능을 사용하여 리소스 활용을 간소화하여 비용을 절감하더라도 인프라 및 하드웨어에 절약할 수 있는 비용은 시스템 운영자에게 지출됩니다. 순수한 온프레미스 시나리오를 사용하면 퍼블릭 클라우드 운영 시간을 절약할 수 있지만 결국 하드웨어에 더 많은 비용을 지출하게 될 수 있습니다.

애플리케이션 마이그레이션을 통한 절감 효과가 항상 확실한 것은 아닙니다. 예를 들어 리프트 앤 시프트 접근 방식에서는 퍼블릭 클라우드 사용의 이점이 최소화됩니다. 기본적으로 관리형 데이터베이스로 마이그레이션하여 운영 오버헤드를 줄이고 백업을 내장할 수 있으므로 데이터베이스와 같은 항목에 대한 비용을 절약할 수 있지만 그렇지 않으면 비용 이점이 제한됩니다.

그렇기 때문에 클라우드 마이그레이션 프로젝트에서는 항상 레거시 애플리케이션을 개선하여 클라우드 네이티브 서비스의 이점을 활용하거나 레거시 애플리케이션을 퍼블릭 클라우드의 탄력성과 자동 확장 기능을 활용하는 새로운 구현과 통합해야 합니다. 이를 위해서는 담당 팀에도 일부 변경이 필요합니다. 클라우드 네이티브 애플리케이션 개발에는 빠른 제공 접근 방식과 애플리케이션 설계 전환이 필요합니다.

그렇지 않으면 새 애플리케이션을 마이그레이션하고 다시 작성하더라도 레거시 환경의 접근 방식에 익숙한 팀을 사용하게 되며 결국 이전과 동일한 아키텍처로 새 애플리케이션을 구축하게 됩니다. 이렇게 하면 클라우드 네이티브 환경에서 얻을 수 있는 실행 속도와 유연성 측면에서 모든 이점이 무효화됩니다.

진화하는 AI 사용 사례

Thomas Delaet: 개발자 생산성을 중심으로 개발되는 Gen AI 사용 사례가 우리가 논의한 모든 것에 어떻게 도움이 될 수 있습니까? 비용 대비 가장 큰 효과를 볼 수 있는 곳은 어디입니까?

Erik Schmiegelow: 현재 Gen AI의 가장 좋은 응용 프로그램은 보조 코딩입니다. 모든 지루한 작업을 줄여 생산성을 향상시키기 때문입니다. 개발자의 전형적인 하루를 살펴보면 30%는 실제 코딩이고, 70%는 디버깅이며, 처음 30% 중 절반은 짜증나고 반복적이며 상용구적인 작업을 수행합니다. 생성적 AI는 해당 비트를 대폭 줄이고 연구 시간을 단축하여 더 많은 확실성을 제공함으로써 개발자 생산성을 크게 향상시킵니다. 곧 일반 LLM(대형 언어 모델)은 개발자가 자신의 요구 사항을 설명하고 모델이 테스트 자동화와 함께 애플리케이션에 대한 대부분의 구조 코드를 생성하도록 하는 생산적인 사용을 위한 대화형 코딩 세션을 지원할 수 있게 될 것입니다. 현재로서는 아직 거기까지 도달하지 못했습니다. 그렇더라도 이는 상대적으로 쉬운 결과이지만 여전히 팀의 경험과 생산성을 크게 향상시키고 있습니다.

Gen AI의 더 흥미로운 사용 사례는 검색 증강 생성(RAG)이라는 기술을 사용하여 엔터프라이즈 데이터 저장소와 쿼리 사용 사례를 결합하는 소프트 스팟에 있습니다. 이는 자연어 이해를 위한 LLM과 검색을 위한 벡터화된 데이터 저장소를 결합하여 모델의 환각 문제와 데이터 세트 교육 문제를 해결합니다. 이러한 방식으로 모델은 올바른 데이터에 초점을 맞추고 개인 정보 보호 문제를 해결하므로 더욱 정확해질 수 있습니다. RAG의 사용 사례는 다양합니다. 예를 들어 보험 산업을 생각해보십시오. 여기에는 구조화되지 않은 문서, 특히 정책 문서가 많이 있습니다. 그 중 다수는 디지털화되었지만 종이에서 유래되었습니다. 많은 사람이 PDF나 종이를 보고 종이에 적힌 내용을 다시 입력하지 않으면서 역분석이나 정책 재처리를 수행하는 것은 매우 어렵습니다.

생성적 AI는 구조화되지 않은 문서에서 필요한 속성을 추출하고 원하는 형식으로 렌더링함으로써 해당 프로세스를 대폭 개선할 수 있습니다. 이를 통해 오래되고 구조화되지 않은 정책 문서의 매우 귀중한 정보를 구조화된 문서로 변환하고 새로운 문서처럼 액세스할 수 있게 만들 수 있습니다. 그렇지 않으면 상당한 비용을 들여 많은 인간 상호 작용이 필요한 프로세스입니다.

생성 AI가 큰 영향을 미칠 수 있는 두 번째 영역은 "퍼지" 매칭과 관련된 모든 것입니다. 현재 비즈니스 프로세스를 살펴보면 다른 데이터 입력 작업을 검증, 확인 또는 실행하기 위해 필요한 인간 상호 작용으로 인해 기계 간 흐름이 중단되는 워크플로우가 상당히 많습니다. 기계는 전통적으로 LLM에 따라 완전히 바뀌는 텍스트를 평가하고 요약하는 데 매우 좋지 않습니다.

이러한 시나리오에서는 워크플로를 유지하면서 제안을 처리하기 위해 데이터 입력 담당자에게 의존하는 대신 엔터프라이즈 데이터 세트에 사전 훈련된 모델을 사용하여 처리량을 늘려 제안을 검토하는 범위를 줄임으로써 LLM의 기능을 활용할 수 있습니다. 모델별로. 완전히 자동화된 데이터 처리를 위해 모델이 충분히 훈련되고 감독되면 결국 수동 단계를 완전히 우회할 수 있습니다. 두 가지 모두 생성 AI를 기업에 적용할 때 가장 좋은 점입니다. 잠재적인 사용 사례 목록은 상당히 광범위하며, 특히 데이터 추출, 요약 및 일치가 비즈니스 프로세스의 중요한 부분인 경우가 가장 중요합니다.

저자 소개

Erik Schmiegelow 는 Hivemind Technologies의 CEO입니다. Thomas Delaet 는 McKinsey 브뤼셀 사무소의 파트너입니다.

인터뷰 대상자가 표현한 의견과 의견은 개인의 의견이며 McKinsey & Company의 의견, 정책 또는 입장을 대표하거나 반영하지 않으며 McKinsey & Company의 승인을 받지도 않습니다.