전방 배치 (Forward Deployment): 역할, 신화 그리고 전설

1년 조금 넘게 전, 저는 '포워드 디플로이먼트(forward deployment)'라는 용어를 만든 회사에서 10년 동안 이 업무를 해온 누군가와 1시간 동안 통화를 했습니다. 지난 12개월 동안, 저는 여러 형태로 사람들과 협력하며 그들의 포워드 디플로이먼트 엔진을 구축하는 과정을 지켜봤습니다. 하지만 여전히 포워드 디플로이먼트가 무엇을 포함하는지 제대로 설명해주는 콘텐츠는 없다고 느낍니다.

친구에게 그 유명한 '발견(discovery) 프로세스'가 실제로 어떻게 작동하는지 물었을 때, 답변은 거의 당황스러울 정도로 물리적이었습니다. 적어도 표면적인 수준에서만 볼 때는 그랬습니다. 비행기 타고 현장에 도착합니다. 이틀 동안 문제와 관련된 모든 사람을 만납니다. ERP 관리자가 구매 주문서에 대한 이론 수업을 해줍니다. 그런 다음 그들은 당신을 작업 현장으로 데려가서 이론이 놓치는 부분이 무엇인지 직접 보여줍니다. 그리고 나서 3주 동안 하루에 한 가지 질문을 하면서 데이터를 연결합니다. 공식이 있냐고 물었더니, 공식은 바로 '아는 사람'과 최대한 많은 시간을 보내는 것이라고 말했습니다. 10년이 지난 지금도 그 부분은 변하지 않았습니다.

하지만 더 깊이 들어가지 않으면 이는 오해를 불러일으킬 수 있습니다. 맞습니다, 그들은 고객과 많은 시간을 보냅니다. 하지만 좋은 포워드 디플로이먼트 엔진은 사전에 모델을 구축합니다. 뛰어난 배포 엔지니어와 배포 전략가들은 모든 것을 이해하지는 못할 것이라는 점을 인지하지만, 매우 빠르게 무언가를 만들고 고객과 함께 반복(iterate)합니다. 첫 번째 워크플로우는 즉각적인 목표입니다. 온톨로지(Ontologies)는 이 도구를 점차 운영 체제로 확장하는 방법으로 사용됩니다. 좋은 포워드 디플로이먼트 엔진이 빛나는 점은, 많은 맥락이 팀, 즉 주제 전문가(SME)로부터 나오며, 그들이 고객을 처음 만나기도 전에 이미 상당 부분을 하나로 엮어낸다는 사실에 있습니다. 이 부분은 시간이 지남에 따라 개선되어 왔으며, 어떤 엔진은 성장하고 어떤 엔진은 그렇지 못한 진정한 이유입니다.

저는 즉시 두 가지 생각이 들었습니다. 좋은 포워드 디플로이먼트가 무엇인지 관심을 기울이지 않았다면 아마 여러분도 같은 생각을 하셨을 테니, 계속 읽어보시길 권합니다.

첫 번째 생각은, 고객의 워크플로우에 대해 전혀 모를 때는 어떻게 해야 할까?였습니다. 아마 많은 인터뷰로 시작해야겠죠? 친구는 아니라고 말했습니다. 아무도 인터뷰를 좋아하지 않기 때문이죠. 대신 그는 한 가지 이야기를 들려주었습니다. 그의 팀은 한 물류 회사를 위해 라우팅 엔진(routing engine)을 구축한 적이 있습니다. 그 회사에서 디스패처(Dispatcher)는 수동 판단과 지도, 거리, 매립지 위치, 기타 운영상의 제약 조건을 보고 매일의 티켓을 운전기사나 노선에 할당했습니다. 친구는 디스패처에게 추천을 제공하는 도구를 만들었지만, 첫 번째 문제는 디스패처들이 종종 직관에 기반하여 추천을 거부했고, 그 이유를 명확히 설명하지 못한다는 점이었습니다. 이를 해결하기 위해 그의 팀은 가능한 모든 할당 순열(permutation)을 표면화해야 했고, 그 가시성을 활용하여 인간의 결정을 시뮬레이션 결과와 비교했습니다. 이는 누군가가 모든 순열을 화면에 매핑한 최초의 사례였으며, 따라서 사람들이 직관에 기반한 결정이 대규모 데이터에 의해 뒷받침되는지 되돌아볼 수 있는 첫 번째 기회였습니다. 이를 통해 물류 회사 팀은 워크플로우 자체를 감사(audit)하고, 프로세스 로직이 실제로 올바른지 이해하며, 디지털 트윈(digital twin)을 개선하여 실제 비즈니스 운영 방식과 더 잘 일치하도록 할 수 있었습니다. 또한 그들은 이 과정을 즐겼는데, 인터뷰처럼 느껴지지 않았고 오히려 처음으로 퍼즐의 모든 조각을 하나의 판에서 볼 수 있었기 때문입니다.

다음 생각은, 에이전트(agents)의 추가가 몇 년 전과 비교하여 오늘날 전체 프로세스를 어떻게 바꾸는가였습니다. 친구의 답변은 간단히 말해 에이전트를 사용하면 훨씬 더 빠르게 개발할 수 있고, 부족한 지식(tribal knowledge) 계층에 더 많은 맥락을 확보할 수 있지만, 그것은 퍼즐의 일부일 뿐이라는 것이었습니다. 그는 이 파일럿(pilot)과 관련된 FDE 모델의 마법 같은 비법(magic sauce)은 아인슈타인급이 아니라며 말했습니다. 어떤 경우에는, 심지어 지금도 파일럿을 진행하는 동안, 그들은 단순히 단계와 결과를 듣고, 동사를 매핑(verb-mapping)하며, 고객에게 그들의 전담 엔지니어가 될 5명의 팀을 제공합니다. 이 엔지니어들은 모든 것을 코드화(codify)하고, 그러면 그들은 사라질 수 있으며 고객은 계속해서 솔루션을 사용할 수 있습니다. 에이전트는 고객 시스템 전반에서 더 많은 맥락과 부족한 지식을 통합하는 것을 더 쉽게 만들어 코드화 프로세스를 가속화하고 심화시키는 데 도움을 줍니다. 에이전트는 직접적인 사용자 피드백을 넘어, 이메일, 영업 프로세스 변경, Salesforce와 같은 시스템의 상태 변경, 그리고 시간이 지남에 따라 조직이 어떻게 작동해왔는지에 대한 다른 흔적들, 즉 역사적 및 운영적 맥락을 끌어오는 방법이 되었습니다. 이는 고객 워크플로우를 더 풍부하게 모델링하고, 파편화된 지식 소스를 연결하며, 디지털 트윈을 통해 비즈니스를 표현할 뿐만 아니라 사람들이 현재 수동으로 내리는 결정을 자동화하거나 지원하는 시스템을 구축하는 것을 더 쉽게 만듭니다.

그와의 통화 내용 중 일부를 옮겨봅니다.

그래서, 우리가 시작하는 방식은 항상 가치 실현 속도(speed to value)에 초점을 맞추는 것입니다. 우리가 항상 절차적인 접근 방식을 따르는 것은 아닙니다. 예를 들어, '좋아, 온톨로지를 만들자. 그 다음 그 위에 애플리케이션을 만들자. 그런 다음 사용자에게 가자' 같은 방식은 아닙니다. 어떤 측면에서는 그 방식을 따르기도 하지만, 다른 측면에서는 그냥 고객에게 묻습니다. '지금 우리가 구축해 드릴 수 있는 가장 큰 가치는 무엇인가요?' 또는 '지금 당장 가장 큰 영향을 드릴 수 있는 것은 무엇인가요? 비즈니스에서 어떤 문제가 있고, 우리가 해결할 수 있다고 생각하는 문제를 설명해 주세요.'

고객이 공유하면, 우리는 거의 화이트보드로 가서 '좋아, 그럼 온톨로지 버전 1을 대충 만들고, 애플리케이션 버전 1도 일주일 안에 만들어서 테스트해보자'고 말합니다. 마치 스타트업을 운영하는 방식과 매우 비슷합니다. 종종 우리는 고객이 어떤 사용 사례에 대한 아이디어를 가지고 오더라도, 이야기하는 과정에서 우리가 해결할 수 있는 완전히 다른 잠재적 사용 사례를 발견합니다. 그리고 고객이 다른 것을 필요로 한다고 생각했더라도, 우리는 그냥 그것을 구축합니다. 결국, 우리는 그들이 해결해야 할 가장 큰 문제가 무엇인지에 맞추려고 노력합니다.

우리는 그것을 위해 빠르게 무언가를 만들고, 온톨로지 측면에서 5개의 객체(object)를 구축할 것입니다. 예를 들어 꽤 복잡할 수 있는 ERP 시스템과 관련된 작업을 한다면, 통합을 완료한 후에도 일주일에 한두 번씩 그 ERP 전문가에게 1시간짜리 잼 세션(jam session)이나 30분짜리 애드혹(ad hoc) 미팅을 요청합니다. 그리고 그곳에서 우리의 가치를 입증한 후에야 두 번째, 세 번째, 네 번째 사용 사례를 찾아 나서서, 결국에는 그들의 회사 전체를 위한 엔터프라이즈 OS(Enterprise OS)를 구축할 수 있는 지점에 도달합니다.

우리는 보통 현장 방문(on-site) 형태로 이 작업을 수행합니다. 그냥 비행기 타고 가서 '좋아요, 이틀만 시간을 주세요'라고 말합니다. 관련된 모든 이해관계자들을 함께 만나거나 1:1로 만납니다. 많은 경우 사람들이 바쁠 때는, 그들 옆에 앉아서 그들의 영업 프로세스나 고객 상호 작용 방식을 이해하려고 노력합니다. 우리는 그들의 관점에서 무슨 일이 일어나고 있는지 이해하려고 노력하며, 고객과의 시간을 단축하려고 하지 않습니다. 실제로 우리는 그 시간을 더 많이 활용하는 쪽으로 기울이고 있으며, 이것은 10년 동안 변하지 않은 부분입니다. 때로는 고객과 함께 몇 주 전체를 보내기도 합니다. 우리는 발견(discovery) 단계에서 우리의 플랫폼을 완전히 자동화하는 방식으로부터 벗어나려고 한 적이 없습니다.

논의의 핵심 아이디어는 코드화(codification)가 방대한 문서화를 통해서가 아니라 반복(iteration)을 통해 이루어진다는 것이었습니다. 팀은 데이터 통합, 운영 맥락, 주제 전문가(SME)의 의견을 사용하여 조직이 실제로 어떻게 기능하는지 표현하는 회사의 "디지털 트윈(digital twin)"을 코드로 직접 구축합니다. 하지만 데이터 모델만으로는 충분하지 않습니다. 더 어렵고 가치 있는 계층은 비즈니스 로직(business logic), 즉 개입이 중요한 부분, 어떤 조치를 권장해야 하는지, 숙련된 운영자가 실제로 어떻게 결정을 내리는지에 대한 이해입니다. 이 모든 것은 단순히 정보를 표면화하는 것뿐만 아니라 사용자가 트레이드오프(tradeoff)를 평가하고, 워크플로우를 검증하며, 궁극적으로 의사 결정 지원을 제품 자체에 인코딩(encoding)하도록 돕는 것입니다.

이후 대화는 이 작업이 처음부터 깊은 도메인 전문가가 포함되어 있어야 하는 것은 아니라는 점에 대해 더 깊이 파고들었습니다. 핵심은 포워드 배포 엔지니어가 익숙하지 않은 환경에 들어가 빠르게 배우고, 유용한 시스템을 신속하게 구축함으로써 신뢰를 쌓을 수 있어야 한다는 것입니다. 초기 계약은 종종 짧은 부트 캠프(boot camp)로 시작되며, 사전 구축된 프로토타입(prototype)과 샘플 데이터로 지원되어, 신속하게 가치를 입증하고 더 깊은 배포를 진행할 권리를 얻도록 설계되었습니다. 거기서부터 관계는 단일 사용 사례에서 고객을 위한 더 광범위한 운영 체제로 확장될 수 있으며, 장기적인 목표는 팀이 결국 물러나더라도 고객이 솔루션을 계속 사용할 수 있도록 워크플로우를 효과적으로 코드화하는 것입니다.

이것은 현재 구축되고 있는 새로운 벤처(venture)에 매우 적합한 플레이북(playbook)입니다. 이것이 바로 포워드 디플로이먼트입니다. 그 외의 모든 것은 아마 장식일 뿐입니다.

복리의 법칙

포워드 디플로이먼트는 비용이 많이 들고, 매출 총이익에 나타나는 속도가 느리며, 깔끔한 계획을 세우기 어렵습니다. 창업자들은 이를 느끼고 그 노력이 얻는 결과에 부합하는지 의문을 갖기 시작합니다. 그러다 결국 어떤 리더가 "우리는 2배의 노력을 들이고 2배의 결과를 얻고 있다"고 말하게 됩니다.

이 말이 포워드 디플로이먼트가 올바른 모델이 아니라는 것을 암시한다면, 특정 산업에서는 위험 신호입니다. 저도 창업자였던 입장에서 창업자의 조바심을 이해하지만, 순진함과 조바심 사이에는 얇은 선이 있습니다. 포워드 디플로이먼트 엔진이 더 잘 맞는 비즈니스의 경우, 곱셈으로 이 계산을 하는 사람은 그 일을 제대로 이해하지 못한 것입니다. 만약 2배의 노력이 2배의 결과를 가져온다면, 당신은 컨설턴트를 고용하여 엔지니어인 척 꾸민 것입니다. 당신은 수익에 발맞춰 인력을 계속 늘려야 할 것이고, 마진은 결코 개선되지 않을 것이며, 당신이 구축한 것의 정직한 이름은 코드를 납품하거나 지원을 제공하는 인력 파견 회사입니다. 자신이 무엇을 구축하고 있는지 명확히 하지 못한 사람들은 거의 항상 평범한 결과를 얻으며, 특히 이러한 혼란은 당신에게 불리하게 작용합니다.

포워드 디플로이먼트는 수학이 휘어질 때만 의미가 있습니다. 첫 번째 배포는 엉성하고, 수작업 투성이이며, 경제적으로 방어가 불가능해도 괜찮습니다. 그것의 임무는 가르치는 것입니다. 두 번째 배포는 더 저렴해야 합니다. 첫 번째 배포가 템플릿, 통합, 문서화된 패턴, 플랫폼 조각을 남겨놓았기 때문입니다. 열 번째 배포쯤 되면, 첫 번째 팀이 수동으로 했던 작업의 대부분은 설정(configuration)을 통해 이루어져야 하며, 인간은 한 단계 위로 올라가서 1년 전에는 고객의 눈에도 존재하지 않았던 문제를 해결해야 합니다. 첫 달과 n번째 달 사이의 그 거리는 복리(compounding)이며, 그 곡선이 바로 당신이 포워드 배포 팀에 자금을 지원할 때 실제로 사는 것입니다. 복리가 핵심입니다. 복리 효과를 내지 못하는 엔진을 가지고 스스로를 포워드 디플로이드(forward deployed)라고 부르는 것은 단순히 어리석은 일입니다.

소프트웨어 엔지니어(SWE)와 포워드 디플로이드 엔지니어(FDE)의 주요 차이점은 SWE가 코드를 작성하여 유지보수하거나, 지원하거나, 로드맵에 있는 기능을 구축하는 데 보내는 시간 대비 FDE가 로드맵에 없는 경우가 많지만 고객 가치를 창출하는 것을 발견하고, 배포하며, 패턴이 여러 고객에게서 반복되기 시작하면 제품으로 전달하는 데 보내는 시간의 양에 있습니다.

모두가 사용하지만 거의 아무도 의미하지 않는 단어

이 아이디어에는 특정한 기원이 있습니다. 20년 전, 한 창업자는 훌륭한 프랑스 레스토랑이 왜 훌륭한지 궁금해하다가 웨이터에게서 답을 찾았습니다. 훌륭한 레스토랑에서 웨이터는 주방의 일부입니다. 따라서 그들이 추천할 때는 주방이 말하는 것입니다. Palantir는 이 엔지니어링 버전을 구축하고 그 역할에 군사적 이름을 붙였습니다. 고객이 군대였기 때문입니다. 그 이름은 현장 업무에 합당한 위상을 부여했고, 당연한 것이었습니다. 보수가 너무 좋았기 때문에 20년이 지난 지금도 모든 사람이 그 이름을 원하지만, 얼마나 많은 사람이 그 일을 이해하는지는 확신할 수 없습니다.

어떤 면에서 포워드 디플로이드 팀은 창업자가 0-1 단계에서 해야 하는 일을 해야 합니다. 당신은 종종 허영 지표를 높이는 것이 아니라 고객이 비즈니스를 진정으로 성장시키는 데 도움이 될 수 있는 것을 무엇을 출시할 수 있을지 발견하고 있습니다. 이것은 제 친구와의 대화에서 나온 또 다른 실제 사례입니다. 그의 팀은 생산량을 약 10배 늘리기를 원하는 EV 충전기 제조업체에 고용되었습니다. 그것이 브리핑이었습니다. 결과가 무엇이었을지 짐작할 수 있나요? 확실히 전략 문서는 아니었습니다. 회사의 목표는 표면적으로 간단했습니다: EV 충전기 생산량을 10배 늘리는 것. 포워드 디플로이드 팀이 실제로 한 일은 현장에 가서 비즈니스의 여러 계층에서 운영을 배우는 것이었습니다. 그들은 ERP 담당자와 시간을 보내며 기록 시스템, 구매 주문서, 작업 지시, 공급 및 수요를 이해했습니다. 그런 다음 작업 현장으로 가서 생산이 실제로 어떻게 이루어지는지 확인했습니다. 동시에 그들은 임원진과 대화하여 문제의 전략적 버전을 이해했습니다. 최전선 작업자가 잘못되었거나 긴급하다고 말하는 것이 리더십이 가장 중요한 제약 조건으로 보는 것과 항상 완벽하게 일치하지는 않기 때문입니다. 따라서 작업은 회의에서 말한 대로 새로운 생산 라인을 직접 구축하는 것이 아니었습니다. 그것은 작업의 디지털 트윈을 구축한 다음, 예를 들어 중요한 부품 부족, 구매 주문 시기, 안전 재고 및 기타 운영 결정과 같은 문제와 관련하여 소프트웨어가 워크플로우에 개입할 수 있는 지점을 식별하는 것이었습니다. 설명된 결과는 위험을 더 일찍 표면화하고 조치를 권장할 수 있는 시스템이지, 제조 자체에 대한 물리적 변화는 아니었습니다. 이것이 제가 전직 창업자들이 뛰어난 포워드 디플로이드 인력이 될 수 있다고 말할 때 의미하는 바를 설명해주길 바랍니다.

오늘날의 직무 경험(설명이 아닌)을 살펴보면, 고객 시스템 내에서 프로덕션 코드를 작성하고, 출시 후 지원까지 포함하여 발생하는 모든 일에 대한 책임을 지는 엔지니어들을 찾을 수 있습니다. 나머지는 더 좋은 명함을 가진 세일즈 엔지니어(데모로 평가받는)와, 유행이기 때문에 이 단어를 빌려온 일부 내부 자동화 역할들입니다. 포워드 디플로이먼트가 무엇인지에 대한 인접한 혼란은 더 심각합니다. 수백 건의 도메인 인터뷰를 통해 전문가 네트워크를 운영하는 것은 연구이지만, 그것은 포워드 디플로이먼트가 아닙니다. 사모펀드가 회사를 인수합병하고 혁신 팀을 보내는 것은 유용하고 때로는 훌륭하지만, 반드시 포워드 디플로이먼트는 아닙니다. 제가 이렇게 말하는 이유는 이 두 가지 활동 중 어느 쪽도 제가 '업무 마감(work-closure)'이라고 부르는 것을 소유하지 않기 때문입니다.

업무 마감은 이 전체 분야가 측정되는 단위입니다. 출시된 기능이 아닙니다. 해결된 티켓이 아닙니다. 고객 업무의 한 조각을, 지속적인 걱정에서 아무도 더 이상 생각하지 않는 상태로 처음부터 끝까지 수행하는 것입니다. 계약 서명은 여기서 혼동되는 직업들 사이의 경계선입니다. 세일즈 엔지니어는 계약 서명까지 작업합니다. 포워드 디플로이드 팀은 계약 서명부터 시작합니다. 무언가가 작동해야 한다는 데 동의하는 것과 실제로 작동하는 것은 다르기 때문입니다. 그 사람이 할당량(quota)을 가지고 있다면, 당신은 영업을 보고 있는 것입니다. 그 사람이 출시 후 3개월이 지나도 고객의 로그에 남아 있다면, 당신은 포워드 디플로이먼트를 보고 있는 것입니다. 마케팅 제품을 판매하는 회사는 계약을 체결하고, 배포 및 설정을 위해 세일즈 엔지니어를 보낼 것입니다. 진정한 FDE는 제품이 지원하는 어떤 워크플로우도 해당 고객에게 도움이 되지 않을 것이라는 결론에 도달할 수 있으며, 완전히 새로운 것이 수익 또는 비용에 직접적인 영향을 미칠 것이고, 그런 다음 그들은 그 워크플로우를 구축합니다. 이는 'Mom's test'(책을 읽어보세요)에 능숙하고, 고객이 당신의 기능이 아닌 더 나은 비즈니스를 하는 방법에 관심이 있다는 것을 이해하며, 당신의 제품이 무엇을 할 수 있는지 이해하고, 고객과 실제 워크플로우에서 반복할 수 있도록 빠른 속도로 출시하는 능력이 필요합니다.

그래서 여기 제가 벽에 붙이고 싶은 정의가 있습니다. 포워드 디플로이먼트는 당신이 출시한 것과 고객이 필요로 했던 것 사이의 거리 위에 서서, 그 거리를 당신의 손으로, 그들의 세계 안에서, 다음 번에는 당신의 제품이 혼자서 그 거리를 좁힐 수 있도록 가르치는 방식으로 줄이는 것입니다.

그 문장의 후반부에서 거의 모든 사람이 실패합니다.

이것이 갑자기 모든 곳에 등장하는 이유

70년 동안 소프트웨어는 사람들이 일하는 것을 도왔습니다. 이제는 소프트웨어가 일을 시작하고 있습니다. 이는 숨겨진 가정을 뒤집습니다. 도구는 천천히 채택되어도 괜찮습니다. 노동자는 그럴 수 없습니다. 결과물(outcomes)을 좌석(seats) 대신 판매하는 순간, 누군가는 당신의 데모 환경과 전혀 다른 회사 내에서 그 결과물을 실현해야 합니다.

모델은 지난 2년 사이 어느 순간 더 이상 제약 조건이 아니게 되었습니다. 배포가 제약 조건이 되었습니다. 엔터프라이즈 AI 파일럿에 대한 가장 많이 인용된 연구에 따르면 약 20개 중 19개가 측정 가능한 P&L 영향을 전혀 내지 못했으며, 그 원인은 거의 항상 모델 품질이 아닙니다. 그것은 워크플로우를 배우지 못한 소프트웨어입니다. 문서화된 프로세스는 4단계입니다. 실제 프로세스는 9단계이며, 누락된 5단계는 한 여성의 기억, 그녀가 몇 년 전에 만든 개인 추적기, 그리고 그녀가 다른 건물에 있는 다른 여성과 주고받는 호의 속에 살아 있습니다. 오래된 산업에서는 작업이 당신의 엔지니어가 태어나기도 전에 설치된 시스템을 통해 실행되며, 가장자리는 팩스와 전화 통화로 간신히 연결되어 있습니다. 어느 것도 API가 없습니다. 유전에서는 누군가가 귀를 굴착 장비에 대고 소리가 걱정해야 할 무언가를 나타내는지 평가합니다. 인도에서 미국으로 오징어를 운반하는 배에서, 런던에 정차하는 동안, 요금과 가격은 직감, 제한된 기상 데이터, 그리고 시각적으로 보이는 재고 품질에 기반하여 결정됩니다. 부족한 지식(Tribal knowledge)은 모든 회사의 하중을 지탱하는 계층이며, 아무도 이를 위한 SDK를 출시한 적이 없습니다. 지난 10년간의 산업 플랫폼의 무덤은 수십억 달러의 비용으로 이 교훈을 가르쳤습니다. 혁신은 아키텍처에서 죽지 않습니다. 채택(adoption)에서 죽습니다.

자본이 이를 주목했습니다. Microsoft는 전문가를 고객 내부에 배치하는 데 25억 달러와 6,000명의 인력을 투입했습니다. AWS는 몇 주 앞서 같은 아이디어에 10억 달러를 투입했습니다. OpenAI와 Anthropic은 각각 세계에서 가장 큰 투자자 중 일부의 지원을 받는 전담 배포 회사를 설립했습니다. 이것을 유행이라고 부를 수도 있습니다. 이 규모의 자본은 거의 의상(장식)이 아닙니다. 연구소들은 자체 파이프라인에 가격을 매겼고, 구매자에게 지능(intelligence)이 부족한 적은 없다는 것을 발견했습니다. 구매자에게 부족했던 것은 일할 손(hands)이었습니다. 실패는 마지막 마일(last mile)에 있으며, 마지막 마일이 바로 해자(moat)가 파이는 곳입니다. LLM에 대한 공격적인 연구가 현재의 수준에 도달하는 데 10년이 걸렸습니다. 이러한 모델이 워크플로우와 인간의 의사 결정 프레임워크에 대한 이해를 갖추게 하려면 훨씬 더 많은 시간이 필요할 수도 있습니다.

왜 비즈니스 전문가가 팀에 필요한가

엔지니어가 필요한 이유는 격차가 코드로, 고객의 인프라에서, 고객의 엣지 케이스(edge case)에 대응하여, 보통 며칠 내에 해결되기 때문입니다. 사용자들이 아침에 설명하는 것이 분기(quarters)가 아닌 며칠 내에 그들 앞에서 실행되어야 합니다. 그 속도가 3년짜리 혁신 프로그램이 슬라이드 라이브러리를 생산하는 것을 지켜본 사람들과 신뢰를 구축하는 방법입니다.

비즈니스 전문가가 필요한 이유는 배포에서 가장 어려운 문제는 기술적인 것이 아니며, 그 반대인 척 하는 것이 기술 팀이 실패하는 방식이기 때문입니다. 누군가는 자동화하기 전에 실제 작업이 무엇인지 알아내야 합니다. 누군가는 20개의 에스컬레이션 중 어떤 3개가 중요한지, 누구의 워크플로우가 실제 병목 현상인지, 어떤 임원의 침묵이 채택을 망칠지, 그리고 어떤 결과가 전체 계약을 정당화할지 결정해야 합니다. 누군가는 고객이 언제 망설이고 있고, 언제 정중하게 말을 하는지 읽는 데 능숙해야 합니다. 누군가는 엔터프라이즈 AI에서 가장 섬세한 인터페이스, 즉 오늘날 제품이 할 수 있는 일과 6개월 후에는 불가피할 것이라고 판매한 것 사이의 인터페이스를 운영해야 합니다. 저는 배포 전략가(deployment strategist)를 회사의 선물환 데스크(futures desk)라고 생각합니다. 그들은 제품이 될 것(what the product will become)을, 관계가 견딜 수 있는 가격에 판매하고, 그 포지션이 결코 채무 불이행(default)되지 않도록 합니다. 높은 판가의 계약은 그 데스크에서 승리하며, 그것 없이는 폭발합니다.

실패 모드는 당신이 어떤 역할을 놓치고 있는지 알려줍니다. 제품이 고객의 환경에서 실행되지 않거나 제품이 제품 내부에만 존재하는 워크플로우만 지원하는 시나리오로 인해 계약이 지연된다면, 당신은 엔지니어가 부족한 것입니다. 엔지니어가 요청된 기능을 출시하느라 바쁘지만 수익은 그만큼 증가하지 않거나, FDE가 100번 이상의 통화를 했지만 계약된 수익이 여전히 실현된 수익보다 한 자릿수 높거나, 시스템을 개선하지 않는 맞춤형 워크플로우의 사일로(silo)가 존재한다면, 당신은 전략가가 부족한 것입니다.

최고의 팀에서는 두 역할이 흐려지며, 그 흐릿함이 바로 핵심입니다. 엔지니어는 비즈니스 감각을 키우고, 전략가는 스키마(schema)를 읽는 법을 배우며, 그 결과 회사가 고용할 수 있는 것 중 창업자에 가장 가까운 인재가 탄생합니다. 포워드 디플로이먼트는 모든 창업자가 조직도가 그것을 숨기기 전까지 수년간 하는 일입니다. 고객의 엉망진창 속에 앉아, 가진 모든 것을 동원하여 작업을 마무리하고, 배운 것을 통해 제품을 다시 그리는 것입니다. 이 역할은 다른 사람의 자본 테이블(cap table)에서 보내는 창업자의 일주일과 같습니다. 또한 이것이 바로 이러한 팀들이 빅테크를 당황하게 할 정도의 비율로 창업자를 배출하는 이유이기도 합니다. FDE 팀을 운영한다면, 첫날부터 승계 계획을 세워 준비해야 합니다. 10년 후에 회사를 구축할 창업자들은 모두 과거에 FDE였을 가능성이 높기 때문입니다. 그 과거는 바로 오늘날 펼쳐지고 있습니다.

실제로 가지고 있는지 확인하는 방법

스냅샷으로 포워드 디플로이드 팀을 판단할 수는 없습니다. 왜냐하면 어떤 날이든 훌륭한 팀과 가짜 팀은 똑같이 보이기 때문입니다. 똑똑한 사람들이 고객에게 날아가서 영웅적인 배포를 하는 모습 말입니다. 다섯 가지 확인 사항이 이를 드러냅니다.

#1 고객당 노력. 작년에 5명의 고객을 서비스하고 올해도 5명의 고객을 서비스하는 팀은 아무것도 복리화하지 않고 있습니다. 이제 15명을 서비스하는 팀은 현장에서 배운 것을 흡수하는 제품을 키우고 있는 것입니다. 모든 고객과 함께, 내부적으로 당신의 팀은 주제 전문가를 개발해야 합니다.

#2 작업의 참신함. 네 번째 배포가 세 번째 배포를 반복한다면, 아무도 현장에서 플랫폼으로 이어지는 파이프라인을 소유하지 않은 것입니다. 누군가는 계정 전반에 걸쳐 반복을 찾는 일을 맡아야 합니다. 반복은 스스로 쓰여지는 로드맵이기 때문입니다.

#3 세그먼트 내 두 번째 배포의 형태. 열 번째 고객에게 첫 번째 고객과 같은 비용이 든다면, 당신은 제품을 확장하는 것이 아니라 프로젝트를 프랜차이즈화하는 것입니다.

#4 보고 라인. 제품 또는 엔지니어링 내에 있으면 루프가 닫힐 수 있습니다. 영업 또는 서비스 사일로 내에 있으면, 학습은 아무도 읽지 않는 출장 보고서에 남겨지고, 팀은 조용히 마진이 됩니다.

#5 고객의 자체 점수판. 활동은 쇼입니다. 사용량 수치는 화려해 보일 수 있지만, 하류(downstream)에서는 아무것도 개선되지 않을 수 있습니다. CFO의 검토를 견딜 수 있는 유일한 측정은 고객이 작성에 도움을 주고, 그들의 데이터에 대한 그들의 결과물에 대해 작업을 평가하며, 첫 주에 구축되어 공개적으로 추적되는 평가입니다. 그 옆에 한 가지 인간적인 테스트를 유지하십시오. 당신의 제품과 전혀 상관없는 일이 그들의 비즈니스에서 발생했을 때, 그들이 가장 먼저 당신에게 전화를 합니까? 만들어진 모든 대시보드는 그 전화 통화를 근사화하려는 시도입니다.

그리고 지금 모든 곳에 존재하는 어두운 패턴(dark pattern)을 조심하십시오. 일부 회사에서 포워드 디플로이드 팀은 학습 엔진이 아니라 은폐자(concealer)입니다. 제품이 제대로 작동하지 않아서, 모든 간격에 사람이 배치됩니다. 사람들이 영웅적이기 때문에, 간격은 결코 로드맵에 도달하지 않습니다. 간격이 로드맵에 도달하지 않기 때문에, 제품은 결코 개선되지 않고, 사람들은 결코 떠날 수 없습니다. 제품 부서는 현장이 계속 흡수하고 있기 때문에 압박을 느끼지 못합니다. 현장은 계정을 구하기에는 너무 바빠서 아무것도 기록하지 않습니다. 고객이 실제로 서비스를 받고 있기 때문에 송장은 계속 발행됩니다. 기계는 균형을 이루고 있으며, 그 균형이 바로 문제입니다. 회사들은 수년간 그 안에서 살아가며, 고객 수만큼 빠르게 현장 인력을 늘리고 그것을 포워드 디플로이먼트라고 부릅니다. 그것은 아닙니다. 그것은 제품의 부재이며, 월별로 청구되는 것입니다. 또한 이것이 이러한 자리에 있는 많은 재능 있는 사람들이 자신이 실패하고 있다고 느끼는 이유이기도 합니다. 그들은 복리화를 위해 고용되었지만, 은폐를 위해 배치되었습니다.

각 단계별 모습

초기 단계에서는 고용하지 말고, 직접 그 역할을 수행하라. 창업자들이야말로 현장 전개팀(field team)이며, 부족한 이해를 위임하는 것이 가장 나쁜 선택이다. 직접 이틀 일정의 출장을 떠나라. 디스패처(dispatcher)와 함께 앉아 있어라. 마침내 채용할 때는, 고객과 당신 사이에 끼어드는 사람이 아닌, 업무 마감을 더 빠르게 만들어줄 사람을 고용하라.

성장 단계에서 현장 전개는 오해받기 쉽다. 외부에서 보면 속도가 느려진 것처럼 보이기 때문이다. 이사회는 엔지니어들이 단일 고객사에 몇 주씩 머무는 동안 경쟁사들은 매주 새로운 기능을 발표하는 모습을 지켜본다. 회계 처리는 상황을 더 악화시킨다. 현장 전개 비용은 매출원가(cost of revenue)로 분류되지만, 그 작업은 R&D처럼 행동하기 때문에, 더 잘 배울수록 재무상태표는 더 나빠 보인다. 어느 한쪽으로 거짓말하지 않고 두 가지 진실을 동시에 붙잡아라. 장부상으로는 비용이다. 전략적으로는 연구개발이다. 해결책은 스토리가 아니라, 연구가 성과를 내도록 강제하는 안전장치(guardrails)다. 모든 참여(engagement)에는 시간 제한을 두어라. 각각을 단일한 비즈니스 성과에 연결하라. 분기별로 수확하라. 즉, 분기마다 현장에서 수작업으로 구축한 무언가가 플랫폼이 자체적으로 처리하는 무언가가 되어야 한다. '나중에 제품화하자'는 말은 이 단계에서 회사를 망치는 문장이다. '나중'에는 책임자가 없기 때문이다.

규모가 커지면 질문의 형태가 바뀐다. 수백만 달러를 지불하는 수백 명의 고객이 있고, 이미 솔루션 컨설턴트, 구현 팀, 관리 서비스, 영업 담당자, 고객 성공 매니저가 있다. 이 단계의 리더들은 현장 전개 팀이 어디에 위치해야 할지 진정으로 모르기 때문에, 4차 지원 티어로 덧붙여져 티켓 볼륨에 압사당한다. 정답은 모든 기존 기능이 플레이북을 운영하며, 현장 전개 팀은 플레이북이 존재하지 않는 곳에만 존재해야 한다는 것이다. 가장 야심 찬 10개의 계정. 새로운 수직 시장. 업계 전체가 자동화할 수 없다고 말하지만, 당신이 독특하게 자동화할 수 있다고 느끼는 워크플로우. 이 팀은 제품 부서에 보고하고, 스스로의 필요성을 없애는 것을 목표로 하며, 해결된 모든 패턴을 플레이북을 운영하는 팀들에게 넘겨줌으로써 플레이북이 지속되도록 한다. 우버(Uber)의 버전은 여기서 교훈을 준다. 그들은 AI에 가장 능숙한 엔지니어들을 재무, 법무, 지원 부서의 도메인 전문가와 짝지어 주었고, 각 페어에게 2주를 주었으며, 발표하는 대신 워크플로우를 소유한 사람과 함께 구축하도록 요구했다. 이틀은 그림자처럼 따라다니며, 하루는 목표를 선택하고, 10일째에는 라이브로 전환했다. 16개의 포드(pod)가 2개월 만에 16개의 기능을 재설계했고, 이틀이 걸리던 보고서가 이제는 10분 만에 완료된다. 자동화의 단위는 결코 작업(task)이 아니었다. 그것은 워크플로우(workflow)이며, 워크플로우는 그 안에 직접 들어간 사람에게만 모습을 드러낸다.

같은 직무, 업계에 따라 다른 모습

국방 및 정부 분야에서 존재 자체가 제품이다. 보안 허가, 분리된 네트워크, 노트북을 반출할 수 없는 방. 의료 분야에서 직무는 워크플로우 고고학(workflow archaeology)이다. 실제 프로세스는 20년 된 시스템 위에서 돌아가며, 팩스와 전화 트리가 여전히 예외 사항을 처리하고, 모든 시설마다 각자의 기록되지 않은 변형을 운영한다. 무언가 표준화되어 있다고 가정하는 팀은 1년을 낭비한다. 금융 서비스 분야에서 고객은 규정 준수 하의 판단력을 구매하며, 인도물은 종종 규제 기관이 읽을 수 있는 평가서이고, 가장 깊은 불안은 데이터 유출이 아니라 판단력 유출, 즉 최고 인력의 의사결정 패턴이 다른 회사의 모델로 흘러가는 것이다. 제조 및 물류 분야에서 진실은 현장에 존재하며 제약은 물리적이기 때문에, 발견(discovery)은 화상으로 이루어질 수 없고 시스템은 구식이며, 시각적으로 복잡하고 종종 클라우드와 연결되지 않는다. 소비재 비즈니스에서 루프는 분기 대신 며칠 단위로 돌아가며, 부족한 기술은 취향(taste), 즉 브랜드의 목소리가 어떤지, 기계가 언제 말을 멈춰야 하는지 아는 것이다. 그리고 가장 새로운 영역은 바로 당신 자신의 회사다. 동일한 포드가 재무, 법무, 지원 부서에 배치된다. AI가 할 수 있는 것과 당신의 조직이 실제로 하는 것 사이의 격차는 같은 건물 안에 있기 때문이다.

지형이 전술을 결정하며, 전술은 협상 가능하지만 순서는 협상 불가능하다. 작업과 함께 앉아라. 작업을 마감하라. 제품에 피드백하라.

누가 이것을 실제로 잘하는가

발명가인 Palantir는 여전히 가장 깊은 버전을 운영하며, 모두가 잊는 세부 사항은 모델이 제품보다 먼저 탄생했다는 것이다. 초기에는 구성할 것이 아무것도 없었고, 단지 망가진 기관 내부에 충분히 오래 앉아 있으면 제품이 스스로 모습을 드러낼 것이라는 내기만 있었다. 그리고 그렇게 되었다. 오늘날 같은 회사는 더 짧고, 더 템플릿화된 참여를 운영하는데, 일단 제품이 존재하면 복리(compounding)가 신조이기 때문이다.

새로운 세대는 고객 서비스 에이전트 회사들에서 가장 쉽게 읽을 수 있다. Sierra는 현장 기능을 에이전트 엔지니어(agent engineers)로 운영하며, 루프는 의도적이다. 한 고객을 위해 문제를 해결하고, 작동한 것을 회사 내부에 전파한 다음, 승자들을 플랫폼으로 승격시켜 모든 고객이 물려받도록 한다. 그들의 엔지니어들이 수십 건의 배포를 통해 에이전트가 재시도를 멈추고 고객을 사람에게 넘겨야 하는 정확한 시점을 학습했을 때, 그 판단력은 재사용 가능한 컴포넌트가 되었다. 그런 다음 그들은 Ghostwriter를 구축했다. 통화 기록, SOP, 화이트보드 사진을 먹이로 삼아 구축 작업을 수행하는 에이전트이며, 에이전트가 직접 운영할 수 있도록 재설계된 플랫폼 위에서 실행된다. Sierra에 대한 투자는 대체로 그 배치된 팀들이 다른 누구도 보지 못한 워크플로우를 계속 발견할 것이라는 내기이다. Decagon은 시스템 접근 방식을 택하여, 배포에서 맞춤 제작될 이유가 없는 작업을 감사(audit)하고, 각 에이전트 뒤의 맞춤 엔지니어링을 80% 줄인 다음, 공개적으로 조용히 말했던 내용을 밝혔다. 즉, 제품이 아니라 딜리버리(delivery)가 해자(moat)가 되고 있다는 것이다. Ramp는 현장 팀에 전직 창업자들을 많이 배치하고, 첫 통화에서 장기 지원에 이르기까지 전체 고객 생애주기를 겨냥하며, 무엇보다도 한 가지 습관을 훈련한다. 구축하기 전에 요구사항에 의문을 제기하라. 명시된 요청은 보통 증상이지 질병이 아니기 때문이다.

일단 형태를 알게 되면, 모든 진지한 수직 시장에서 그것을 볼 수 있다. Harvey는 전직 변호사들을 로펌에 파견하며, 배치된 사람이 반드시 엔지니어일 필요는 없으며 오직 책임감만 있으면 된다는 것을 증명한다. 금융 분야에서 Rogo는 회사의 거의 절반을 전직 은행가들로 채워 그들이 나온 기관에 배치하는 반면, Hebbia는 엔지니어들을 세계 최대 자산운용사 내부의 마일리지 구축을 위해 파견한다. Abridge는 병원 시스템과 함께 배치 포드를 구성하고 있는데, 12,000명의 임상의에게 AI 필기 비서를 도입하는 것은 설치가 아니라 캠페인이기 때문이다. HappyRobot은 화물 중개인과 함께하고, Gecko Robotics는 해군 함선에 빌더를 배치하며, Applied Intuition은 세계 대부분의 대형 자동차 제조사 내부에 자리 잡고 있고, Cursor(SpaceX)는 당신의 엔지니어들이 이미 사랑하는 도구를 은행과 통신사에 연결하는 현장 전개 팀을 운영한다.

다른 형태, 하나의 물리 법칙. 현장이 공장에 먹이를 주지 않으면, 그것은 현장 전개가 아니다.

가장 강력한 반대 논거, 그것은 그럴 자격이 있으므로

이 전체 직업이 사과에 불과하다는 주장이 있다. 스스로 요리하는 주방을 팔았지만, 도착한 것은 이제 당신 집에 살며, 당신 급여 명단에 오르고, 공급업체 마크업이 붙었으며, 이사 날짜도 없는 셰프라는 것이다. 그 제안은 당신이 두 가지를 동시에 믿기를 요구한다. 기계가 당신의 요리를 대체할 만큼 뛰어나면서도, 상주하는 관리인이 필요할 만큼 무력하다는 것이다. 제품에 상주하는 인간이 필요하다면, 그 제품은 완성되지 않은 것이다.

이것을 진지하게 받아들여라. 많은 공급업체에게 이것은 단순히 사실이기 때문이다. 종을 구분하는 테스트는 이 기사가 계속 반복하는 것과 같다. 격차에 있는 인간이 영구적이라면, 비판은 옳으며, 당신은 패치를 임대하고 있는 것이다. 격차에 있는 인간이 복리 효과를 내며, 스스로의 필요성을 없애는 방식으로 작업을 마감한다면, 그 비판은 두 번째 배포에서 죽는다. 비판이 놓치는 것은 대부분의 작업이 결코 제품 마무리(product-finishing)가 아니었다는 점이다. 그것은 맥락 획득(context acquisition)이다. 문서화되지 않은 5단계, 디스패처의 말하지 않은 직관, 건물을 넘나드는 호의. 완성된 제품이 그것들을 포함하여 출시되는 일은 결코 없을 것이다. 그것들은 모든 회사마다 다르기 때문이다. 누군가는 그것들을 얻으러 가야 한다. 유일하게 중요한 질문은 그들이 가져온 것이 자산(asset)으로 축적되는지, 아니면 인보이스로 증발하는지이다.

이것이 향하는 방향

네 가지 변화가 이미 진행 중이다.

맥락이 자산이 된다. 배치된 팀이 각 고객사에서 실제로 구축하는 것은 그 회사가 어떻게 운영되는지에 대한 작동 모델이다. 온톨로지, 트윈, 누가 무엇을 왜 결정하는지에 대한 지도. 투자자들은 이것을 회사 두뇌(company brain)라고 부르기 시작했고, 그 이름이 붙어가는 이유는 모든 회사가 하나를 필요로 하게 될 것이기 때문이다. 사람들이 생각하는 것보다 더 많은 부분이 누군가 비행기를 타기 전에 부트스트래핑될 수 있다. 고객들은 지원 티켓, 통화 기록, 이메일, 에스컬레이션 스레드에서 끊임없이 자신들의 진실을 흘리기 때문이다. 거기서부터 시작하라. 그러나 가장 깊은 층, 즉 사람들이 말로 표현할 수 없는 지식은 여전히 현장에의 존재와 거울, 즉 내부자가 자신의 직관을 감사하여 논리로 전환할 때까지 돕는 도구를 필요로 한다. 그 지도를 가진 자가 계정을 보유하며, 이는 모든 CEO가 곧 모든 AI 공급업체에게 물어볼 질문을 제기한다. 나는 지능을 임대하고 있지만, 학습은 누가 소유하는가? 하나의 공유 모델이 시장의 모든 대출 기관으로부터 신용 판단을 흡수한다면, 풀 내 가장 예리한 인수자는 경쟁자들을 훈련시키면서 그 특권에 대한 대가를 지불하고 있는 셈이다. 모든 CFO가 실행할 수 있는 테스트가 있다. 내일 모델 공급업체를 서류상으로 바꾸고, 당신이 시스템에 가르친 모든 것이 함께 문을 나가는지 확인하라. 계약, 팀, 그리고 결국 회사들이 하나의 라인을 중심으로 재편성될 것으로 예상하라. 지능은 임대하고, 학습은 소유하라.

에이전트가 팀에 합류한다. 현장 전개 에이전트는 이미 초기 형태로 존재한다. 통합 작업의 오후를 몇 분으로 압축하는 온보딩 에이전트. 자신의 기록을 밤새 읽고 자신의 스킬 개선안을 제안하는 배포 에이전트. 이것이 인간의 역할에 어떤 영향을 미치는지 지켜보라. 모든 수동 개입은 더 이상 작업이 아닌 훈련 신호(training signal)가 되며, 팀의 직무는 역전된다. 배포를 직접 수행하는 것에서 배포를 수행하는 공장을 운영하는 것으로. 관리자가 사람을 관리하는 방식으로 인력을 배치하는 것. 관리자가 리뷰를 작성하는 방식으로 평가를 작성하는 것. 더 깊은 역전은 사용자가 누구인지에 있다. 제품들은 에이전트가 직접 운영할 수 있도록 재구축되고 있으며, 고객사에서의 첫 번째 발견 질문은 조용히 '당신 팀에 무엇이 필요합니까?'에서 '당신의 에이전트에 무엇이 필요합니까?'로 바뀌고 있다. 동일한 전환은 수익 측면에서도 일어나고 있다. 한 명의 사람이 에이전트 함대와 함께 예전에는 한 층의 사람들이 처리하던 파이프라인을 운영하며, 판매 후 소프트웨어는 도구에서 결과를 소유하는 서비스로 리브랜딩되고 있다. 오늘날의 유지 서비스(a service as a service), 내일의 확장 서비스(expansion as a service). 그리고 당신 고객의 에이전트가 당신의 에이전트와 협상을 시작할 때, 테이블 양쪽에 남은 인간들은 루프가 혼자서는 닫을 수 없는 두 가지 일, 즉 무엇을 원할 가치가 있는지 결정하는 것과 그것이 실제로 일어났음을 인증하는 것을 수행하게 될 것이다.

바닥이 무너진다. 몇 년 전에 500만 달러의 정예 엔지니어링이 필요했던 배포가 이제는 수십만 달러와 좋은 에이전트를 가진 예리한 제너럴리스트면 충분하며, 가격은 여전히 하락 중이다. 현장 전개는 포춘 500대 기업의 사치품에서 중견 시장 소프트웨어가 판매되는 방식으로 변화한다. 제약은 엔지니어링 공급에서 판단력 공급으로 바뀐다.

직함이 사라진다. 진지한 회사의 모든 엔지니어는 부분적으로 현장 전개자가 되고 있다. 백엔드 엔지니어는 고객 통화에 참여한다. 프로덕트 엔지니어는 통화 기록을 기반으로 출시한다. 곧 고객과 대면하는 시간의 비율만이 FDE(Field Deployment Engineer)와 소프트웨어 엔지니어의 유일한 차이가 될 것이며, 직함은 더 이상 그렇지 않은 척하지 않을 것이다. 이는 어떤 채용 공고에도 인쇄되지 않는 경고를 수반한다. 이 작업은 빌더를 외교관으로 전환시키며, 많은 뛰어난 엔지니어들이 낯선 사람들로 가득한 방이 그들을 지치게 하기 때문에 정확히 구축을 선택했다. 그들을 배치하지 않음으로써 내향형을 존중하고, 엔지니어링에 평범했던 엔지니어를 주차하는 장소로 이 역할을 절대 사용하지 않음으로써 그 역할을 존중하라. 그것은 정반대이다. 그것은 당신이 무언가를 창업하도록 믿고 맡길 사람들을 보내는 곳이다.

회사에서 가장 오래된 직무

용어를 걷어내면 현장 전개는 창업자의 원래 자세이며, 성장하여 그것을 잊을 만큼 커진 회사 내부에서 살아남은 것이다. 작업이 있는 곳에 앉아라. 작업을 마감하라. 배운 것이 당신이 구축하는 것을 바꾸도록 하라. 모든 지속 가능한 회사는 그것에 이름을 붙이기 전에 이것을 했다. 대부분의 회사는 그것을 감당할 여유가 생기는 날 그것을 중단한다.

따라서 진짜 질문은 현장 전개 엔지니어를 고용할지 여부가 결코 아니었다. 그것은 당신이 현실에 가장 가까운 사람들이 실제 권력을 가지고, 노력이 그 기울기(slope)로 평가되며, 현장에서 배운 어떤 것도 그곳에서 죽는 것을 허용하지 않는 회사를 운영할 의향이 있는지 여부이다. 그것을 구축하면, 직함은 스스로 해결된다.

당신의 팀이 고객이 그것에 대해 생각하는 것을 완전히 멈출 정도로 완전히 마감한 마지막 작업은 무엇인가? 고객이 제품 제품군에서 가치를 얻었기 때문이 아니라, 당신이 그들의 비즈니스 성장을 위해 그들이 필요하다는 것을 몰랐던 것들까지 구축할 것임을 알기 때문에 갱신한 마지막 시간은 언제였는가? 거기서부터 세어보기 시작하라.