요즘 채용 공고에서 가장 자주 보이는 직함 중 하나가 '포워드 디플로이드 엔지니어(FDE, 고객 현장에 직접 들어가 문제를 풀면서 제품을 만들어 내는 엔지니어)'입니다. 오픈AI도, 로보틱스 회사도, 방산 스타트업도 이 사람을 찾고 있어요. 그런데 이 직군을 만들어 낸 팔란티어 안에서조차, 오랫동안 "그거 그냥 용역을 리브랜딩한 거 아니냐"는 말을 들어야 했던 자리이기도 합니다.
이번에 소개할 인터뷰는 그 자리를 13년째 지켜 온 악샤이 크리슈나스와미(Akshay Krishnaswamy) 팔란티어 수석 아키텍트와, 같은 회사에서 FDE로 커리어를 시작한 에린 프라이스-라이트(Erin Price-Wright) a16z 제너럴 파트너의 대화입니다. 이 방식이 정확히 무엇인지, 어떤 회사가 따라 해도 되는지, 그리고 대부분이 어디서 실패하는지를 다룹니다.
이상한 데이터를 만지던 사람이 팔란티어로 간 이유
Q. 팔란티어, 그리고 FDE라는 일에 처음 끌린 이유가 뭐였나요?
제 이상한 경력을 유일하게 가치 있게 봐 준 회사가 팔란티어였어요. 저는 원래 생명의료공학을 전공했습니다. 팔란티어에 있는 많은 사람들처럼 저도 좀 희한한 배경을 갖고 들어온 셈이에요.
이미지 출처 : Akshay Krishnaswamy의 링크드인 캡처
그때 제가 하고 싶었던 건 뇌-컴퓨터 인터페이스(뇌에서 나오는 전기 신호를 읽어서 기계를 조작하는 기술)였습니다. 요즘은 이게 오히려 유행하는 분야가 됐죠. 그런데 학부생 연구실에서 그 일이 실제로 어떤 모습이었냐면, 온갖 이상한 신호 처리와 데이터 정리 작업이었어요. 지저분하기 짝이 없는 신경 데이터를 어떻게든 말이 되는 형태로 바꿔 놓는 일이었습니다.
솔직히 그때는 이 경험이 나중에 어디에 어떻게 연결될지 저도 잘 몰랐습니다. 대학원에 갈 생각은 없었고, 그래서 실리콘밸리로 갔어요. 2012년이었으니까 그루폰이나 우버 같은 소비자 서비스가 한창 뜨던 시기였습니다. 그런 흐름 속에서 '이상한 데이터를 정리해 본 경험'에 큰 가치를 느끼는 회사는 거의 없었어요. 그런데 팔란티어는 달랐습니다. 사실상 유일했어요.
Q. 그때 팔란티어에는 어떤 사람들이 있었나요?
물리학, 대테러, 컴퓨터공학처럼 서로 접점이 없어 보이는 배경을 가진 사람들이 모여 있었습니다. 좀 이상하지만 흥미로운 집단이었어요. 당시에는 아주 특정한 방산 임무들에 집중하고 있었습니다.
그런데 동시에 다들 이 기술이 다른 데도 쓰일 수 있지 않을까를 계속 생각하고 있었어요. 글로벌 헬스라든가, 금융이라든가, 그 밖의 산업들 말이죠. 눈앞에 놓인 임무는 아주 좁은데, 그 임무를 푸는 방식은 훨씬 넓게 쓰이길 바라는 상태였던 겁니다.
Q. 13년이 지났는데, 그때 보셨던 게 지금도 남아 있나요?
남아 있습니다. 저는 이 회사의 공식이 여전히 꽤 단순하다고 생각해요. 흥미로운 사람들, 야심 찬 문제, 야심 찬 기술. 이 세 가지입니다. 이 세 가지 조합은 그때나 지금이나 거의 그대로예요.
결과에서 거꾸로 짚어 만드는 소프트웨어
Q. 지금은 오픈AI부터 로보틱스, 방산까지 다들 FDE를 찾습니다. 이 유행을 어떻게 보세요?
솔직히 좀 웃깁니다. 에린도 아마 비슷하게 느낄 텐데, 아주 오랫동안 이건 가장 미운 오리 새끼였거든요. "너희는 그냥 용역을 리브랜딩한 거 아니냐", "정부랑 일하는 거잖아", "도대체 뭘 하는 거냐" 같은 말을 계속 들었습니다.
이미지 출처 : deploy.co
그런데 이제는 이 방식이 만들어 내는 결과물의 형태 자체가 다르다는 인정이 생긴 것 같아요. 소프트웨어든 하드웨어든, 이렇게 만든 것과 저렇게 만든 것은 다르게 생겼다는 걸 사람들이 받아들이기 시작한 겁니다.
Q. 그러면 13년을 해 오신 입장에서 FDE란 무엇이고, 무엇이 아닌가요?
FDE는 결과에서 거꾸로 짚어 가며 제품을 만들어 내는 방식이지, 계약서에 적힌 항목을 납품하는 일이 아닙니다.
제 표현으로는 역전파(back propagation, 인공신경망이 결과의 오차를 거꾸로 되짚어 가면서 내부를 고쳐 나가는 학습 방식)로 짓는 거예요. 어떤 면에서는 신념에 기댄 제품 개발이기도 합니다. 시작 시점에 팔 수 있는 제품이 존재하지 않는다는 걸 전제로 깔고 가거든요.
이미지 출처 : 나노바나나 제작
대신 결과를 먼저 놓고 거기에 급진적으로 방향을 맞춰요. 그 결과가 도로변에 묻힌 폭탄을 찾아내는 일일 수도 있고, 석유 엔지니어의 업무를 돕는 일일 수도 있습니다. 그리고 이렇게 묻습니다. 이 특정한 결과를 만들어 내려면 우리가 뭘 만들어야 하는가. 그다음에 거기서 거꾸로, 일반화가 가능한 형태로 되짚어 올라갑니다.
Q. 신념에 기댄다는 게 어떤 의미인가요?
증거가 아니라 믿음으로 시작할 수밖에 없는 구간이 있다는 뜻입니다. 보통의 제품 개발은 이미 존재하는 무언가를 개선하는 데서 출발하잖아요. 이 방식은 그 출발점 자체가 없어요. 그러니까 "이 결과를 만들어 낼 수 있다"는 판단 하나로 움직이기 시작하는 겁니다.
Q. 일반적인 소프트웨어 회사 구조와 비교하면, 어디가 뒤집힌 건가요?
판단의 무게중심이 본사가 아니라 현장에 있다는 점입니다. 일반적인 구조를 보면 실리콘밸리에 코어 팀이 있어요. 제가 농담 삼아 '사제들'이라고 부르는 사람들인데, 이들이 물건을 만듭니다. 그리고 현장에는 솔루션 엔지니어나 영업 담당자가 있죠. 이들도 어느 정도 재량은 있지만, 실제로 하는 일은 "사내 위키 문서 읽고 그대로 구현해라"에 가깝습니다.
FDE는 정확히 그 반대입니다. 현장에서 뭐가 통하는지를 직접 알아내야 해요. 그 문제에 대한 해법이 회사에 아직 없으니까요. 그리고 알아낸 다음에 그걸 어떻게 일반화할지를 찾아냅니다.
Q. 그렇게 특수한 상황과 일반적인 제품 사이를 오가는 게 실제로 어떻게 굴러가나요?
끝없이 반복되는 변증법(서로 반대되는 두 질문을 계속 부딪혀 가며 답을 찾아 나가는 방식) 같은 거예요. 이 특정 상황에서 어떻게 작동하게 만들까, 그리고 그걸 어떻게 일반화할까. 이 두 질문을 계속 왔다 갔다 합니다.
에린도 알겠지만 이건 파도처럼 옵니다. 한 번씩 지날 때마다 마찰이 생겨요. 현장에서 만든 것과 이미 만들어 놓은 제품이 서로 안 맞는 지점이 나오고, 그 마찰을 어떻게 조정할지를 두고 계속 씨름하게 됩니다. 그 과정이 반복되면서 네트워크가 만들어지는 거죠.
그래서 정리하면, 거꾸로 그리고 귀납적으로 만들되 범용적 쓸모를 염두에 두고 만드는 일입니다.
현장의 흉터가 없으면 제품을 만들 자격이 없다
Q. 지금은 아닐 텐데, 제가 입사할 때만 해도 팔란티어에는 개발자로 바로 들어올 수 없었어요. 최소 6개월에서 1년은 현장 로테이션을 돌아야 했죠.
맞아요. 그리고 나중에 제품 조직으로 간 사람들도 전부 FDE 출신이었습니다. 에린도 FDE를 하고 나서 제품 쪽 일을 했잖아요. 제품 리드였던 사람이든 누구든, 거기 있던 사람은 다 FDE를 거쳤어요.
이미지 출처 : Vinoo Ganesh, vinoo.io
Q. 그 로테이션을 거치지 않으면 왜 안 되는 건가요?
현장에서 얻은 흉터가 없으면 코어 제품 일을 할 자격이 없다고 보기 때문입니다. 신뢰가 생기지 않거든요. 현장에서 무엇이 실제로 부서지는지를 몸으로 겪어 본 사람과, 문서로만 읽은 사람은 같은 문제를 봐도 다른 판단을 하니까요.
솔루션 아키텍트와는 인센티브부터 다르다
Q. 그러면 FDE는 솔루션 아키텍트나 필드 PM과 어떻게 다른가요?
가장 먼저 떠오르는 차이는 인센티브 구조입니다. 전부는 아니지만 그런 역할들은 대개 시간 단위로 과금되거나, 계약 산출물에 아주 강하게 묶여 있어요. 무엇을 몇 개 만들어 준다는 게 미리 정해져 있고, 그걸 채우면 일이 끝나는 구조입니다.
반면 저희는 선언적인 형태의 임무 범위를 받습니다. 예를 들면 "유정 검토 프로세스를 더 낫게 만들 방법을 찾아라", "에어버스 A350 생산 증대를 도와라" 같은 식이에요. 그 안을 어떻게 채울지는 알려주지 않습니다. 계약 자체도 고객이 그 결과에 도달할 수 있도록 설계하고, 필요한 만큼 빈칸을 우리가 채워 넣는 구조로 만들어요. 무엇을 만들지가 아니라 어디에 도달할지를 계약에 적는 셈입니다.
Q. 두 번째 차이는요?
두 번째는 무엇을 할 권한이 있느냐입니다. 그 사람의 직무 정의가 매출을 관리하는 것인가, 아니면 제품을 앞으로 밀고 나가는 것인가.
저희 CTO인 샴 생커(FDE라는 역할을 처음 구상한 팔란티어 13번째 직원)가 자주 하는 농담이 있어요. FDE의 일은 고통을 흡수해서 제품으로 뱉어내는 것이라고요. 현장에서 받은 온갖 압박과 요구를 다 받아 낸 다음, 그걸 개인의 고생으로 끝내지 않고 제품의 형태로 내놓는다는 뜻입니다.
Q. 사내 이메일에서 그 문장을 여러 번 봤어요. 그렇게 두 가지를 동시에 짊어지는 게 힘들지는 않나요?
가끔은 터무니없고 불가능하게 느껴집니다. 나는 이 고객을, 이 결과를 반드시 성공시켜야 하는데, 진짜 상위 목표는 다음번에 제품이 더 잘 돌아가게 만드는 것이거든요. 두 개의 야심이 층층이 얹혀 있는 상태예요.
그런데 그게 이 일을 다른 일과 구분해 주는 지점이라고 생각합니다. "저는 그냥 이 계정을 담당하면서 일하고 있습니다"라고 말하는 것과는 완전히 다른 상태니까요.
고통을 견디는 능력이 곧 해자다
Q. 그러면 어떤 사람이 이 일에서 잘 버티나요?
솔직히 현장에 넣어 보기 전까지는 알 수 없다는 게 제 답입니다. 여기엔 약간의 인식론적 겸손, 그러니까 내가 다 알 수는 없다는 인정이 필요해요. 사람을 미리 골라내는 완벽한 기준이 있다고 말하고 싶지 않습니다.
그래도 굳이 말하자면, FDE 집단은 하이브 마인드(여러 사람이 하나의 지능처럼 붙어서 움직이는 상태)처럼 작동하는 편입니다. 그래서 이런 질문들이 남아요. 아주 느슨한 선언적 지시만 받고도 현장에서 성공하는 법을 스스로 찾아낼 수 있는가. 이미 나와 있는 제품에 대해 코어 개발 팀에 건설적으로, 때로는 날카롭게 반박할 수 있는가. 현장의 고통과 반복, 그리고 코어 팀과의 협업이 뒤섞인 이 합주에 들어올 수 있는가.
Q. 그 일이 실제로는 얼마나 지저분한가요?
굉장히 지저분합니다. 하드 스킬도 당연히 필요해요. 이 데이터 시스템에 연결할 수 있는가, 애플리케이션을 계속 고쳐 나갈 수 있는가. 그런데 거기에 더해서, IT 담당자한테 혼날 수 있는가 같은 게 실제 업무 능력에 들어갑니다. 그리고 그걸 한 번이 아니라 여러 번 반복할 수 있느냐가 중요해요.
Q. 고객에게 몇 시간씩 혼나는 걸 견디는 능력도 진짜 자질 아닌가요?
고통 감내력은 아주 큰 항목이에요. 그리고 그 고통이 해자(경쟁자가 쉽게 넘어오지 못하게 막아 주는 방어벽)입니다.
다만 여기에 갈림길이 있습니다. 고통은 사람을 자기 안의 못난 쪽으로 끌고 내려갈 수도 있거든요. 짜증과 원망으로 끝나 버릴 수 있다는 뜻이에요. 그게 '이걸 더 낫게 만들고 싶다'는 마음으로 번역되느냐가 핵심입니다.
지난 13년을 돌아보면, 서류상으로는 훌륭한 FDE가 됐을 사람들이 많았습니다. 그런데 현장에 내보내기 전에는 정말 알 수 없어요. 반대로 놀라게 하는 사람들도 있습니다. 이력서만 봐서는 예상하지 못했던 방식으로 헌신적인 사람들이 나옵니다.
Q. 그래도 눈에 띄는 유형이 있다면요?
두어 가지가 있습니다. 하나는 분야를 가로지른 사람들이에요. 원래 물리학을 하다가 이걸 하고 싶어졌다든가, 전기공학을 하다가 넘어왔다든가 하는 경우죠. 이 영역에서 일하고 싶은 이유, 혹은 이 고객의 결과를 만들어 내고 싶은 이유가 따로 있는 사람들입니다.
그리고 이 사람들에게는 공통점이 하나 더 있어요. 자기가 원래 갔을 법한 평범한 경로 대신 왜 이 길을 택했는지에 대한 의견을 갖고 있습니다.
Q. 그 의견이라는 게 구체적으로 어떤 형태인가요?
증명해 보이겠다는 오기 같은 겁니다. '이 결과는 반드시 일어나야 하고, 그걸 내가 해낼 수 있다는 걸 세상과 나 자신에게 증명해야 한다'는 감각이요. 고대 그리스어로 튜모스(thumos, 플라톤이 영혼의 한 부분으로 꼽은 것. 욕구와 달리 인정받으려는 데서 나오는 기개)라고 하는, 기개나 격정에 가까운 것이 있는 거예요.
이미지 출처 : 나노바나나 제작
그냥 "좋은 일이니까 하고, 체크박스 채우면 되지" 정도라면 어렵습니다. 머릿속에 박힌 가시가 없는 사람은 매일 나와서 그런 일들을 해내고 거기에 매몰되지 않기가 힘들어요.
엉망이었던 면접이 오히려 합격 신호였다
Q. 제가 입사할 무렵 팔란티어가 많이 뽑던 유형 중 하나가 대학원 중퇴자였어요. 저도 거기 속했고요.
기술적으로 뭔가를 깊게 파고들다가 학계의 속도에 질려 버린 사람들이죠. 제가 면접에서 자주 만났던 유형 중 하나예요.
저는 팔란티어에 들어간 이유가 공동창업자인 스티븐 코헨과 한 면접 때문이라고 농담하곤 해요. 그가 저에게 왜 대학원에 가지 않았느냐고 물었는데, 그 답이 판단을 뒤집은 지점이었던 것 같습니다. 나머지 답변들은 그냥 그랬을 텐데, 그 질문에서 "대학원을 안 갔다고, 흥미롭네" 하는 반응이 나왔거든요.
Q. 저는 면접 때 면접관과 언쟁을 벌였어요. 그 사람이 문제의 전제를 잘못 깔았다고 생각해서 싸웠고, 나오면서 '나는 절대 못 붙겠다'고 생각했죠. 그런 게 오히려 신호였을까요?
아주 흔한 경험입니다. 저희끼리 하는 농담이 있어요. 지금은 채용 팀이 아주 훌륭하지만, 초기에는 엔지니어들이 직접 채용을 했거든요. 그래서 채용 과정에서 엉망인 경험을 하지 않았다면 그건 진짜 팔란티어 면접이 아니었다는 말이 있었습니다.
면접 중에 어떤 긴장 지점도 없었고 '내가 망쳤다'는 생각도 들지 않았다면, 그건 오히려 붙지 않을 신호에 가까웠어요.
이미지 출처 : Reddit
중요한 건 사람이 아니라 동사다
Q. 이 모델을 시도해 보려는 창업자는 팀을 어떻게 짜야 할까요?
특히 초기에는 집중이 정말 중요합니다. 저희도 상용 제품인 파운드리(팔란티어가 민간 기업용으로 만든 데이터 분석 플랫폼) 초기에 그걸 겪었어요.
여러 개의 특공대 팀을 만들어서 각자 조금씩 다른 고객 결과를 좇게 하고 싶은 유혹이 생깁니다. 아까 말한 거꾸로 짚어 가는 방식으로 복잡한 최적화를 여러 갈래로 동시에 돌려 보고 싶은 거죠. 그런데 초기에 그렇게 하면 그 결과들을 하나로 응집시키는 게 감당이 안 됩니다.
그래서 스파르타식으로 좁히는 편이 낫습니다. FDE 팀은 사실상 제품 팀의 연장이라고 보는 거예요. 둘이 거의 같은 것이라고 놓는 겁니다.
Q. 그 구분이 없다는 게 실제로는 어떤 의미인가요?
'포워드 디플로이드 엔지니어'라는 사람보다 '포워드 디플로이드 엔지니어링'이라는 동사가 중요하다는 뜻입니다. 특정 직군을 뽑는 게 아니라, 우리는 제품을 이런 방식으로 만들겠다고 약속하는 거예요.
초기 고담(팔란티어가 정부·정보기관용으로 만든 첫 제품)이 그랬습니다. 이게 우리가 고담을 만드는 방식이었어요. 물론 걸려 넘어지는 것도 많았고, 수정하고 바꿔야 할 것도 많았습니다. 그런데 거기에 '현장 조직'과 '제품 조직'이라는 딱딱한 구분은 없었어요. 이 제품을 만들려면 우리가 이렇게 움직여야 한다, 그뿐이었죠.
Q. 그러면 창업자가 스스로에게 먼저 던져야 할 질문은 뭘까요?
이 제품을 만드는 데 이 방식이 맞느냐는 질문입니다. 항상 맞는 건 아니에요.
다만 아주 구체적이고 기술적이고 세밀한 맥락에서 일한다면, 포워드 디플로이드 엔지니어링은 '우리가 그 환경을 계속 제대로 읽어 내겠고, 그 자리에 있겠고, 결과에 책임지겠다'고 선언하는 방법이 됩니다. 그리고 그 말은 때때로 개발자들도 현장에 함께 나간다는 뜻이에요. 사람을 어디에 배치하느냐의 문제가 아니라 그 방식 자체에 대한 약속이니까요.
자율성에는 반드시 비용이 따른다
Q. 그런데 이렇게 주도성이 강한 엔지니어들이 감독 없이 고객의 비즈니스 결과를 알아서 책임지는 구조잖아요. 조직 차원에서 책임은 어떻게 관리하나요?
좋은 지적입니다. 젊었을 때의 저라면 평평한 조직이 위계 조직보다 무조건 낫다고 말했을 거예요. 농담 삼아 말하면 균사(버섯 뿌리처럼 사방으로 뻗으며 서로 얽히는 그물망)처럼 연결된 조직이요.
그런데 지금 제가 깨달은 건, 그게 매우 강력하긴 하지만 어디까지나 하나의 선택이라는 겁니다. 인생에서 무엇을 하든 반드시 치러야 할 비용이 있으니까요.
Q. 그 비용이 구체적으로 어떻게 나타나나요?
세상을 계속 하나로 꿰어 맞추는 일이 끝나지 않습니다. 자율성이 높은 사람들이 여기저기서 각자 움직이면 다른 방식으로는 얻을 수 없는 우연한 발견과 속도가 생겨요. 그건 분명한 이득입니다. 대신 저희 표현으로는 계속 온톨로지화(흩어져 있는 것들을 하나의 공통된 세계 모델로 정리하는 일)를 해야 합니다.
문제도 생깁니다. 저쪽에 있는 사람이 하는 일이 이쪽 사람이 하는 일과 어긋나 있는 경우가 나와요. 그러면 이걸 지금 화해시킬지 나중에 할지를 판단해야 합니다. 게다가 사람들이 뭘 할지를 위에서 지시할 수도 없으니, 결국 사람들이 벌여 놓은 일을 나중에 정리하고 통합하는 작업이 계속 따라붙습니다.
Q. 제가 제품개발 조직에 있을 때는 그 정리 작업이 일의 전부처럼 느껴졌어요. 여기에 정답이 있나요?
없습니다. 여기에 과학은 없다고 생각해요. 다만 자율성을 허용하기로 했다면 그 대가를 치르겠다는 약속이 계속 있어야 합니다.
그 대가라는 게 뭐냐면, 사람들과 따로 시간을 쓰는 일이고, 원래대로라면 생기지 않았을 연결을 억지로 붙여 주는 일이에요. 카프 박사(알렉스 카프, 팔란티어 CEO)가 맨 위에서 하는 일도 상당 부분 그겁니다. 어느 그룹이 뭘 하고 있고, 누가 이걸 하고 있고, 이걸 어떻게 이어 붙일 것인가.
접시를 여러 개 돌리고 있는데, 그 접시가 또 다른 사람이 돌리는 접시와 겹쳐 있는 상태가 계속되는 거죠.
제품이 쌓일수록 야심을 줄이지 않는 법
Q. 10년 전에는 파운드리라는 제품 자체가 없어서 현장에서 고객과 함께 만들어야 했습니다. 지금은 제품도 있고 고객도 훨씬 많은데, 그 사이에 FDE 모델은 어떻게 달라졌나요?
제품이 쌓일수록 "이제 예전만큼 FDE를 안 해도 된다"는 변명, 혹은 진통제 같은 게 생깁니다. 데이터 통합 솔루션이 있고, 온톨로지 빌더가 있고, 애플리케이션 빌더가 있으니까요. 예전에는 맨손으로 해야 했던 일들이 이제 도구로 해결되니까 자연스럽게 그런 생각이 듭니다. 가만히 두면 그쪽으로 흘러가요.
본문에서 말한 데이터 통합, 온톨로지, 애플리케이션 빌더가 01번부터 12번까지 쌓여 있다.
이미지 출처 : @hyperindexed, X
그런데 저는 그게 퇴행적인 결과라고 봅니다. 야심의 최전선을 계속 밀어내지 않게 되니까요.
예전에 어느 IT 담당자가 저에게 이런 말을 한 적이 있어요. "당신들은 눈이 배보다 큽니다." 감당할 수 있는 것보다 욕심이 앞선다는 뜻이었죠. 저는 저희가 앞으로도 계속 그랬으면 좋겠습니다.
Q. 그러면 새로 들어온 사람들에게는 뭘 이해시켜야 하나요?
제품이 많아졌다는 게 다 지어졌다는 뜻도 아니고, 안주해도 된다는 뜻도 아니라는 걸 이해시켜야 합니다. 오히려 그만큼 더 큰 지렛대를 손에 쥐었다는 뜻이에요.
이제 저희에게는 개발자 플랫폼이 있습니다. 예전 같으면 엄청난 시간을 들여야 했을 일들을, 지금은 아주 적은 추가 노력으로 해낼 수 있는 방법이 여러 갈래로 있어요. 그러니 우리에게 주어진 임무는 예전과 같거나 오히려 더 커야 합니다. 지금의 기술 플랫폼은 그 임무를 하지 않아도 되는 핑계가 아니라, 그 임무를 해내기 위한 지렛대여야 하니까요.
컨설팅 회사가 되지 않으려면
Q. 이 모델을 하다 보면 컨설팅 회사가 되어 버릴 거라는 두려움이 있잖아요. 제품 회사의 혼은 어떻게 지키나요?
말도 안 되는 목표를 계속 떠맡는 것이 그 방법 중 하나입니다.
지난 실적 발표에서 카프 박사가 대규모로 성장하면서 영업 인원은 거의 그대로 유지하겠다고 말했어요. 내부에서는 다들 '그걸 어떻게 하지?' 하는 반응이었습니다. 그런데 지금까지 모든 게 그런 식으로 굴러왔다는 걸 우리 스스로 알고 있어요. 일단 크게 선언하고, 그다음에 방법을 찾아내는 겁니다.
고객과 있을 때도 마찬가지예요. 이걸 해내겠다, 이건 크고 대단한 일이다, 다만 이게 어떻게 맞춰질지는 나도 아직 정확히 모르겠다. 이런 식이죠.
Q. 그 상태를 계속 유지하는 게 왜 중요한가요?
우리가 건설적인 방식으로 늘 감당 가능한 선보다 한 발 앞서 나가 있다고 느끼는 한, 그 상태 자체가 규율을 강제하기 때문입니다. 실행에서도, 제품 개발에서도, 채용에서도요.
반대로 가속 페달에서 발을 떼고 파도가 저절로 꺾이도록 두는 날이 온다면, 그때부터 뭔가 달라질 겁니다. 저는 그날이 오지 않기를 바라고 있어요.
Q. 그런데 1년에 수천만 달러를 내는 고객이 맞춤 기능을 요청합니다. 어디까지가 결과를 위한 일이고, 어디부터가 선을 넘는 건가요?
모든 경우에 통하는 깔끔한 답은 없다고 생각합니다. 다만 플랫폼의 부품이 많아지면서 그 질문에 답하는 방법이 늘어난 건 확실해요.
첫 번째는 플랫폼의 새로운 부분을 아예 만들어야 하는 경우입니다. 만들 가치가 있고 만들 이유가 있는 요청이라면 그렇게 합니다.
두 번째는 커스텀으로 만들되, 플랫폼에 새로 생긴 연결 지점을 활용해서 맞춤 애플리케이션이나 맞춤 연동을 만드는 경우예요.
세 번째는 파트너사를 쓰는 경우입니다. 파트너가 맞춤 연동을 만들고, 그쪽 팀을 교육해서 우리에게 장기적으로 유지보수를 의존하지 않게 만드는 방식이죠.
이 중에 무엇을 택할지는 여전히 과학보다는 감각의 영역입니다. 지금도 이 질문에 빠르고 간단한 답이 있다고 말한다면 그건 거짓말일 거예요.
이 모델이 실패하는 지점
Q. 마지막으로, 이 방식을 이제 막 시도해 보려는 사람들이 알아 둬야 할 실패 모드가 있다면요?
먼저 조직 전체가 이 방식을 지탱하도록 만들어져 있는지를 봐야 합니다. 아니면 그냥 곁가지이거나 브랜딩용인지를요.
후자라면 기대했던 열매를 얻지 못할 겁니다. 동시에 이 방식이 당연히 몰고 오는 난기류도 감당하지 못할 거고요. 이득은 못 얻고 비용만 치르게 되는 셈이죠.
Q. 그다음으로 생각해 볼 건 뭘까요?
이 방식이 작동하려면 여러 유형의 사람들을 함께 지휘해야 한다는 점입니다.
구현을 하는 사람들이 있고, 팔란티어 안에서 잘 언급되지는 않지만 관계를 관리해 주는 전략적 파트너십 쪽 사람들이 있어요. 그리고 이 모든 걸 하나로 꿰는 제품 리드가 있습니다. 이 사람들이 전부 포워드 디플로이드 과정의 일부여야 해요.
그런 공유된 팀이 없으면 세계 최고의 FDE를 데려다 놓아도 소용이 없습니다. 애초에 문제에 접근할 통로를 얻지 못하고, 결과를 내기 위해 건설적으로 규칙을 좀 깨야 할 때 그걸 막아 줄 보호막도 없거든요.
Q. 고객 쪽에서도, 회사 안쪽에서도 위에서 덮어 주는 엄호가 필요하다는 말씀이군요.
정확합니다. 그리고 그런 건 있을 때는 있는 줄도 모르고 지나가다가, 없어지면 아주 분명해집니다.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 12기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요