제레미 프리먼, Allstacks의 공동 창립자 및 CTO – 인터뷰 시리즈

제레미 프리먼, Allstacks의 공동 창립자이자 CTO는 소프트웨어 엔지니어, 기술 아키텍트, 그리고 기업가로서 소프트웨어 개발, 하드웨어 엔지니어링, 기계 학습, 그리고 제품 혁신에 걸친 경력을 가지고 있습니다. 2017년 Allstacks를 공동 창립한 이후, 그는 회사의 핵심 플랫폼의 아키텍처와 개발을 이끌며, 예측 분석과 AI 기반 예측을 통해 소프트웨어 전달 관리를 변革하는 데 기여했습니다. Allstacks 이전에, 프리먼은 Ravioli Labs와 CertiRx에서 리더십 역할을 맡았으며, 소프트웨어 엔지니어링, 연구, 반대조작 기술, 그리고 제품 개발에 참여했습니다. 그의 초기 경력에서, 그는 스타트업, 엔터프라이즈 기술 회사, 그리고 학계에서 경험을积累했으며, 웨이크 테크니컬 커뮤니티 칼리지에서 웹 개발을 가르쳤습니다. 그의 기술 배경은 임베디드 시스템, 하드웨어 설계, 대규모 소프트웨어 플랫폼, 기계 학습, 그리고 엔지니어링 리더십을 포함하며, 데이터 기반 제품을 구축하여 조직이 소프트웨어 전달 결과를 개선하는 데 도움을 주는 고유한 관점을 제공합니다.

Allstacks는 소프트웨어 엔지니어링 인텔리전스와 가치 흐름 관리 플랫폼으로, 조직이 소프트웨어 개발의 예측 가능성과 효율성을 개선하는 데 도움을 줍니다. 이 플랫폼은 프로젝트 관리, 소스 제어, 배포 시스템을 포함한 소프트웨어 개발 수명주기에서 사용되는 도구에서 데이터를 통합한 다음, 위험을 식별하고 전달 결과를 예측하며 실행 가능한 통찰력을 제공하기 위해 AI와 기계 학습을 적용합니다. 엔지니어링과 제품 리더들에게 프로젝트 건강, 팀 성과, 개발 동향에 대한 가시성을 제공함으로써, Allstacks는 조직이 더 나은 결정을 내리고 전달 불확실성을 줄이며 엔지니어링 노력을 비즈니스 목표와 더 잘 맞추는 데 도움을 줍니다. 이 기술은 기업들이 직관에 의존하는 계획을 넘어서서 실시간 운영 데이터를 사용하여 소프트웨어 전달 성능과 전략적 실행을 개선하는 데 도움을 주도록 설계되었습니다.

소프트웨어 개발 데이터에 기계 학습을 적용하는 연구 및 엔지니어링 팀을 이끈 경험과 Allstacks를 2017년에 공동 창립한 경험을 고려할 때, 어떤 구체적인 간격이나 반복되는 문제를 관찰하여 회사를 설립하도록 동기를 부여받았나요?

우리가 Allstacks를 시작했을 때, 우리는 고객 발견에 많은 시간을 투자했으며, 나타난 패턴은 일관적이었습니다. 회사마다 엄청난 양의 데이터가 있었지만 실제로 무슨 일이 일어나고 있는지에 대해 아무도 알지 못했습니다. 소프트웨어를 전달하는 것은 예측할 수 없었습니다.

명확하게 된 것은 이것이 보고 문제나 통합 문제가 아니라는 것이었습니다. 이것은 관계 문제였습니다. 무언가가 위험에 처해 있는지 여부를 알기 위해서는 작업 항목이 분기와 어떻게 연결되는지, 분기가 PR과 어떻게 연결되는지, PR이 스프린트 목표와 어떻게 연결되는지, 스프린트 목표가 비즈니스 이니셔티브와 어떻게 연결되는지 알아야 합니다. 그 그래프는 표준 도구 체인에서 기본적으로 존재하지 않습니다. 그것을 구축해야 합니다. 그리고 그것을 잘 구축하는 것은 근본적으로 추론 문제입니다. 여기서 기계 학습 배경이 직접적으로 유용해집니다.

우리의 목표는 처음부터 개인 개발자가 기능 X에서 더 빠르게 만들도록 하는 것이 아니었습니다. 그것은 전체 조직을 더 좋게 만드는 것이었습니다. 엔지니어링 노력을 비즈니스 결과와 어떻게 맞추나요? 엔지니어링이 비즈니스에真正로 서비스를 제공하는 방법은 무엇인가요? 그것을 알기 위해서는 데이터 관계에 대한 더好的 이해가 필요합니다. 그것은 거의 모든 제품 결정에 영향을 미쳤습니다.

Allstacks는 전체 소프트웨어 개발 수명주기에서 데이터를 분석합니다. 전달 위험을 조기에 식별할 때 가장 예측 가능한 신호 또는 패턴은 무엇인가요?

나는 단 하나의 지표 세트가 좋고 나쁨을 예측한다고 생각하지 않습니다. 다만 다른 단계와 유형의 조직에 대한 패턴이 있습니다. 더 유용한 것은 엔지니어링 조직이 개선의 시즌을 거친다는 것을 인식하는 것입니다. 이 달에는 데이터베이스 성능입니다. 다음 달에는 팀 간의 커뮤니케이션입니다. 그러면 “PR을 닫을 수 없는 이유는 무엇인가?”입니다. 그런 다음 관찰 가능성입니다. 엔지니어링 리더로서, 당신은 신호에 둘러싸여 있습니다. 일부는 진단적입니다. 일부는 모니터링용입니다. 그리고 많은 것이 그냥 노이즈입니다.

도움이 되는 것은 실제로 보이는 문제에서 시작하는 것입니다. 아니라 지표를 개선하고 싶은 것입니다. “왜 지난 해보다 덜 전달하는 것 같아?”라고 묻는다면, đó는 올바른 시작점입니다. 그 다음에, 나는 세 가지 유형의 지표가 필요하다고 생각합니다. 첫째, 문제가 실제인지 어떻게 알 수 있나요? (예를 들어, 개발자당 PR 수를 시간에 따라 계산합니다.) 둘째, 어떤 변경을 하고 있으며 그것을 따라 어떻게 추적하고 있나요? (예를 들어, AI PR 리뷰어를 채택하는 경우입니다.) 셋째, 이 문제가 비즈니스에 얼마나 중요한가요? 직감적으로 코드를 20% 少으로 전달하는 것 같을 수 있지만, 실제 이야기는 QA가 이제 3배 더 오래 걸린다는 것입니다. 당신은 세 가지 렌즈가 필요합니다.

기술, 에너지, 헬스케어 등 다양한 산업에서 일해온 경험을 고려할 때, 소프트웨어 전달의 도전은 이러한 산업 간에 어떻게 다르며, 어떻게 Allstacks 플랫폼을 형성했나요?

나는 비순수 기술 부문에서의 경험을 매우 중요하게 생각합니다. SaaS 회사에서는 소프트웨어 자체가 목표라는 생각에 쉽게 빠질 수 있습니다. 비즈니스에서 소프트웨어를 직접 판매하지 않는 경우, ваш의 역할은 더 분명해집니다. 기술은 비즈니스에 지원하는 데 있습니다. 나는 종종 농담으로, 비즈니스에서는 내가 처리하지 않아도 된다고 생각할 것입니다.

그 관점은 실제로 유용합니다. 그것은 우리가 이 산업에서 하는 모든 것을 상황에 둡니다. 그리고 많은 기술 논쟁을 다시 제자리로 돌려놓습니다. 비즈니스에서는 파이썬을 사용하거나 Go를 사용하는지 관심 없습니다. 리팩토링에 사이클을 투자하는 것은 실제로 돌아올 곳이 아닙니다.

그러나 모든 산업에서 일관된 것은 조각난 문제입니다. 산업에 관계없이 모든 엔지니어링 조직은 도구에 걸쳐 데이터가 산재해 있으며, 그 사이의 연결 고리가 제한적입니다. 세부 사항은 다르지만, 규제된 산업은 계획 주기가 더 길고 요구 사항에 대한 불확실성에 대한 허용 오차가 낮습니다. 높은 속도 기술 샵은 숨겨진 부채를 더 빠르게 축적합니다. 그러나 핵심 실패 모드는 동일합니다. 팀은 무엇이 배포되었는지 말할 수 있지만, 왜 무언가가 미끄러졌는지, 무엇이 비용이었는지, 그리고 문제가 발생하기 전에 위험이 어디에 보였는지 추적할 수 없습니다. 그것이 플랫폼을 구축하는 데 어떻게 형성했는지입니다.

코딩 자체를 가속화하면서 다른 곳에서 약점을 노출하는 AI의 성장에 대한 이야기가 있습니다. 요구 사항, 계획, 사양 준비가 실제로 병목 현상이 되는 이유는 무엇인가요?

우리는 매일 이것을 보는 것입니다. 좋은 에이전트와 固体한 하네스 주변에서, 당신은 아이디어에서, 때로는 고객의 입에서 직접 프로덕션으로 몇 시간 내에 이동할 수 있습니다.

그 변화가 इतन도重大한 이유 중 하나는 피드백 루프의 변화입니다. Copilot 스타일의 도구에서, 인간은 모든 제안에 대해 루프에 있습니다. 에이전트는 완성을 제안합니다. 당신은 그것을 수락하거나 거부합니다. 그것이 잘못된 경우, 당신은 빠르게 잡습니다. 나쁨 제안의 블래스트 반경은 코드 한 줄입니다. 에이전트 코딩은 다르게 작동합니다. 당신은 에이전트에게 목표를 주고, 그것은 작업을 분해하고, 다단계 계획을 실행하고, 작동하는 모듈을 전달합니다. 인간은 출력을 검토합니다. 스펙이 잘못된 경우, 에이전트는 잘못된 스펙에 따라 전체 구현을 구축하고, 당신은 검토에서 그것을 발견합니다.

그것은 순수한 업사이드로 들릴 수 있습니다. 하지만 당신이 이전의 레이턴시가 실제로 무엇을 했는지 인식할 때까지. 레이턴시는 실제 목적을 servicio했습니다. 여러 라운드의 스마트한 사람들이 검토하고, 계획하고, 테스트하고, 아이디어를 작업하여 더好的 시스템을 생산했습니다.

현재의 유혹은 그것을 모두 우회하고 싶은 것입니다. 하지만 에이전트와 하네스는 아직 전체 SDLC에 준비가 되지 않았습니다. 속도는 실제입니다. 품질 게이트키핑이 이전의 더 느린 단계에서 발생한 것은 없습니다.

많은 조직은 여전히 낡은 지표를 사용하여 생산성을 측정합니다. AI 기반 개발 환경에서 생산성에 대해 리더들이 근본적으로 잘못 이해하는 것은 무엇인가요?

사람들은 이 주제에 대해 상당히 성숙했습니다. 측정은 실제로 중요한 것들로 이동했으며, 프레임워크는 더 정교해졌습니다. AI는 모든 것을 뒤엎습니다.

전통적인 소프트웨어 개발은 개발자가 코드를 작성할 수 있는 속도에 의해 근본적으로 제한되었습니다. 그것은 비즈니스와 기본 기술의 요구 사항을 충족하는 코드입니다. 그 비용은 거의 0에 접근합니다. 우리는 개발자로서 에이전트를 관리하는 것으로 이동하고 있습니다. 그 모델은 개발자-시간이나 생성된 토큰과 같은 것에 기반한 생산성 측정 접근 방식과는 완전히 다른 것을 필요로 합니다.

현재 지표의 일부 위험은 실제로 일어나는 것을 숨깁니다. 선임 엔지니어는 에이전트 도구를 사용하여 자신의 우위를 누적합니다. 그들은 코드베이스 컨텍스트와 에이전트 출력을 조종하고 실패를 잡을 수 있는 판단력을 가지고 있습니다. 초기 경력 엔지니어는 동일한 코드 볼륨을 생성하지만, 에이전트 출력을 완전히 평가할 수 없는 경우 더 많은 시간을 감사에 보냅니다. 집계 속도는 괜찮을 수 있습니다. 선임 엔지니어와 초기 경력 엔지니어 간의 격차는 표준 대시보드 어디에도 나타나지 않습니다. 올바른 질문은 “얼마나 빠르게 가고 있는가”가 아니라 “우리가 무엇을 배포했는지”입니다.

우리는 아직 산업 컨센서스에 도달하지 못했습니다. 하지만 품질과 리워크 率를 추적하는 팀은, 처리량과 채택만 추적하는 팀보다 더 잘 위치해 있을 것입니다.

플랫폼은 프로젝트 관리 시스템 및 코드 저장소와 같은 도구에서 데이터를 연결합니다. 이러한 분산된 데이터 소스를 통일하는 것이 얼마나 중요한가요? 그리고 조직이 이를 하지 못할 때 무슨 일이 발생하나요?

Allstacks는 컨텍스트 그래프를 구축하기 시작한 이후부터 이 분야에서 성공을 거두었습니다. 우리는 데이터를 모두 연결하는 것이 고객이 실제로 묻는 질문에 답변하는 데 필요하다는 것을 인식했습니다.

그 연결이 없으면, 엔지니어링 데이터에서 작동하는 AI는 부분적인 그림만 볼 수 있습니다. 프로젝트 관리 시스템에서 분석할 수 있고, 코드 저장소에서 분석할 수 있습니다. 하지만 세 가지 도구에 걸친 차단된 종속성을 통해 전달 지연을 추적할 수 없습니다. 그 관계는 데이터 레이어에 존재하지 않습니다.浅い 분석을 얻을 수 있을 뿐이며, 잘못된 추천을 받을 수 있습니다. 모델 품질은 이를 해결하지 못합니다. 원시 API 통합에 가장 능숙한 모델을 올려도, 실제 문제의 원인을 놓칠 수 있습니다. 쓰레기가 들어가면 쓰레기가 나옵니다.

개발 워크플로에 에이전트가 더 많이 내장됨에 따라, 잘 준비된 엔지니어링 조직과 준비가 안 된 조직은 어떻게 다를까요?

아이러니하게도, 그것은 여름 인턴을 받아오는 것과 크게 다르지 않습니다. 당신은 강한 자동화된 테스트 스위트, 문서화, 성숙한 CI/CD 파이프라인, 그리고 팀에 신뢰할 수 있는但未학습된 개발자를 추가할 때 넣는 가드레일이 필요합니다.

또한 중요하지만 사람들이 간과하는 것은 기본 사항을 다시 검토하는 것입니다. 에이전트 규칙, AGENTS.MD 파일입니다. 당신은 첫 번째 패스를 잘할 수 있지만, 새로운 방식으로 배송하고 에이전트 출력을 교육하는 방법을 잊기 쉽습니다. 에이전트가 커밋 전에 테스트를 실행하도록 가르치는 것은 인간의 리마인더가 필요하지 않습니다.

엔지니어링 노력을 비즈니스 결과와 어떻게 연결할 수 있나요?

나는 두 가지 주요 실패 모드를 보았습니다. 첫 번째는 제품과 엔지니어링 팀을 짝지어하지 않는 회사입니다. 많은 팀 구조는 레거시이며 오래 전부터 존재했습니다. 한 팀은 세 가지 다른 제품을 소유할 수 있으며 다른 팀은 네 가지 제품을 소유할 수 있습니다. 엔지니어링 투자는 주로 헤드카운트에 달려 있습니다. 팀이 제품과 일치하지 않으면 비즈니스 기대와 현실이 어떻게 달라지는지 보는 것이 매우 어렵습니다.

두 번째 실패 모드는 모든 엔지니어링 작업을 계산하지 않는 것입니다. 비즈니스-不可視 엔지니어링 작업의巨大한 범주가 있습니다. 내 любим한 예는 패키지를 업데이트하는 것입니다. 비기술 비즈니스 리더는 그 값을 이해하거나 왜 그것이 지속적이고 예측할 수 없는지 이해하기 위해 어려움을 겪을 수 있습니다. 하지만 그들은 투자 카테고리를 이해할 수 있습니다. “임계 보안 업그레이드”라고 프레임을 설정하고, 평균적으로 얼마나 많은 용량을消費하는지 보여주면, 그들은 함께 일할 수 있는 언어를 사용할 수 있습니다.

개발자로서의 역할은 AI가 코딩 작업을 더 많이 맡길 때 어떻게 발전할까요?

솔직히, 나는有点 걱정합니다. 하지만 나는 스마트한 사람들이 그것을 해결할 것이라고 믿습니다.

私の懸念은 실제입니다. 신입 졸업생은 곧 코딩 에이전트가 없는 세계에서 코딩을 한 적이 없는 채로 직장에 입사할 것입니다. 교육이 그것에 따라 움직이고 있나요? 도구는 빠르게 움직이지만, 고등 교육은 항상 함께 움직이지 않습니다. 나는 또한 선임 엔지니어와 선임 제품 사람들의 구분이模糊해지는 것을 지켜보고 있습니다. 새로운 모델에서 가장 성공적인 실무자는 제품 생각에 깊이 관여하는 엔지니어입니다.

가치가 더 중요한 것은 판단력입니다. 에이전트가 해결할 수 있도록 문제를 정의하는 능력, 에이전트의 솔루션이 올바른지 평가하는 능력, 그리고 에이전트의 출력을 조종하는 능력입니다. 선임 엔지니어는 에이전트 출력을 조종할 수 있고, 에이전트의 실패를 잡을 수 있습니다. 초기 경력 엔지니어에 대한 관심은, 전통적인 방법으로 판단력을 구축하는 피드백 루프가 변경되고 있는 방식입니다.

앞으로 3~5년 동안 AI가 소프트웨어 개발 수명주기를 어떻게 재구성할까요? 그리고 회사들은 어디에서 가장 큰 경쟁 우위를 얻을 수 있을까요?

우리는 이전에 본 것과 같은 기능 경쟁을 볼 것입니다. 빌드 비용이 0에 접근함에 따라, 회사, 심지어 큰 회사도, 새로운 제약 조건에 직면합니다. 고객의 피드백을 검증하기 위해 충분한 양의 데이터를 수집하는 것입니다.

변화해야 하는 것은 구축해야 하는 바의 기준이 올라간다는 것입니다. 현재 대부분의 엔지니어링 조직에서 제약은 단순합니다. 5개의 최상위 우선순위, 아마도 2개의 전달된 것입니다. 에이전트를 사용하면 비율이 반대가 됩니다. 5개의 최상위, 10개의 다음, 그리고 20개의 아마도 목록이 있으며, 100개를 전달할 수 있습니다. 마지막 65개가 어떻게 잘못 구축되고 잘못 실행되는지에 대한 질문은 아직 아무도 완전히 답하지 못했습니다.

두 가지를 khá 확신합니다. 첫째, 엔지니어링 AI의 경쟁 우위는 모델 품질이 아니라 컨텍스트의 깊이와 폭에서 나옵니다. 모델은 표준이 됩니다. 모든 도구는 능력 있는 모델을 가지고 있을 것입니다. 주요 플랫폼을 구분하는 것은 그들이 당신의 특정 조직, 당신의 저장소, 팀 구조, 전달 기록, 배포 패턴을 얼마나 잘 이해하는지입니다. 시스템을 아는 도구는 시스템을 모르는 도구와 근본적으로 다른 답변을 생성할 것입니다. 둘째, 반응형에서 예방형으로의 전환입니다. 오늘날의 도구는 질문을 받았을 때 답변합니다. 몇 년 내에, 주요 도구는 지속적으로 관찰하고, 당신이 묻기 전에 위험을 표면화할 것입니다. 컨텍스트 레이어를 구축하는 조직은 우위를 누적하고 있습니다. 다음 세대의 도구는 품질-규모 문제를 해결해야 합니다. 그리고 그것을 먼저 해결하는 조직은 실제 우위를 가질 것입니다.

잘한 인터뷰에 감사드립니다. 더 많은 것을 배우고 싶은 독자는 Allstacks를 방문해야 합니다.