Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 스킬 목록은 문을 열어 줄 뿐이다
요구사항 발굴 — 요청한 것 vs 진짜 필요한 것
도메인을 공유 모델로 만들기 — 핵심 행위
지저분하고, 에어갭이며, 레거시인 환경에 통합하기
데모, 이해관계자, 그리고 기대 관리
언제 아니오라고 말할까 — 과잉 설계 피하기
성공은 실제로 어떻게 측정되나 — 짠 코드가 아니라 채택
정직한 부분 — 다리로 서 있기
마치며
참고 자료

들어가며 — 스킬 목록은 문을 열어 줄 뿐이다

앞선 글은 Forward Deployed Engineer에게 필요한 지식 — 리눅스·네트워크·쿠버네티스·DB·API 통합·보안 — 을 지도로 정리하고, 그 도메인들의 진행률을 추적하는 인터랙티브 체크리스트를 함께 붙였습니다. 그 지도는 문을 열어 줍니다. 하지만 고객사 건물 안에 들어간 뒤 실제로 무엇을 하는지에 대해서는 거의 아무 말도 하지 않습니다. 그건 다른, 더 낯선 크래프트입니다.

Palantir은 이 역할을 대비로 설명합니다. 일반 엔지니어가 "one capability, many customers"를 만든다면, FDSE — 사내 이름으로 "Delta" — 는 "one customer, many capabilities"를 만들며, 기존 플랫폼이 고객의 가장 어려운 문제를 풀도록 "embeds directly with our customers"합니다. 스킬 목록은 Delta가 무엇을 아는지를 말합니다. 크래프트는 Delta가 한 고객과 몇 달에 걸쳐, 그들의 혼돈을 작동하는 무언가로 바꾸기 위해 하는 일입니다. 그 대부분은 여섯 가지 움직임으로 이루어집니다.

고객이 ASK 한 것
   |
   |   요구사항 발굴   (진짜 통증을 파고든다)
   v
고객이 NEED 하는 것
   |
   |   공유 도메인 모델   (양쪽이 함께 가리키는 계약)
   v
당신이 BUILD 한 것  -- demo -->  피드백   (모델이 틀렸다; 반복)
   |
   |   나머지엔 아니오   (목표를 움직이는 것만 짓는다)
   v
ADOPTION   (당신이 떠난 뒤에도 쓴다)  =  유일한 점수

위에서 아래로 읽으면 그 루프가 곧 이 일입니다. 여섯 가지 움직임으로 이름 붙이면 이렇습니다.

요구사항 발굴 — 요청을 뚫고 그 아래 통증까지 파고든다.
도메인 모델링 — 고객의 현실을 양쪽이 함께 가리킬 수 있는 공유 모델로 바꾼다.
통합 — 그 모델을, 데이터가 문서와 절대 맞지 않는 지저분하고 에어갭이며 레거시인 시스템에 연결한다.
데모 — 작동하는 데모를 세일즈용 소품이 아니라 일차 피드백 도구로 다룬다.
아니오라고 말하기 — 목표를 움직이는 것만 짓고 나머지는 거절한다.
채택을 향한 최적화 — 유일한 점수는 당신이 떠난 뒤에도 그들이 쓰는가이다.

이 글의 나머지는 이것들을 하나씩 다룹니다.

요구사항 발굴 — 요청한 것 vs 진짜 필요한 것

명시된 요청이 진짜 요청인 경우는 거의 없습니다. 그것은 고객이 이미 절반쯤 스스로 진단해 압축해 놓은 통증의 결과물이고, 그 진단은 자주 틀립니다. 이 간극은 끊임없이 나타납니다.

대시보드를 요청하지만, 필요한 것은 더 빨리 내려지는 결정이다.
**"엑셀로 내보내기"**를 요청하지만, 필요한 것은 자정마다 두 시스템을 손으로 대조하는 일을 멈추는 것이다.
더 빠른 리포트를 요청하지만, 필요한 것은 다시 확인하지 않고도 그 숫자를 믿는 것이다.

FDE의 첫 일은 발굴입니다 — 요청을 뚫고 그 아래 통증까지 파고드는 것.

그래서 이 역할은 컨설팅이 아닙니다. The Pragmatic Engineer는 선을 깔끔하게 긋습니다 — 컨설턴트는 "one-off recommendations"를 내놓고 떠나지만, FDE는 고객과 오래 함께 일하며 결과를 소유합니다. 진단을 남에게 넘기고 떠날 수 없습니다. 그 안에서 삽니다. 발굴 작업은 구체적이고 화려하지 않습니다 — 실제로 그 일을 하는 사람 곁에 앉고, 그들의 실제 프로세스를 그리고, 어디서 가치가 새는지 지켜보는 것. Palantir의 엔지니어들은 "talking to customers, who know the subject matter best"에 진짜 시간을 쓴다고 말합니다.

그리고 지반은 계속 움직입니다. OpenAI의 Colin Jarvis가 (The Pragmatic Engineer를 통해) 말했듯, 스코핑 단계에서 고객이 묘사한 것은 종종 "doesn't match the data/system reality on the ground"입니다. 그러므로 발굴은 짓기 전에 끝내는 단계가 아닙니다. 프로젝트 내내 계속되고, 모든 데모가 새로운 발굴입니다.

도메인을 공유 모델로 만들기 — 핵심 행위

여기가 이 일 전체를 정의하는 움직임이자, 스킬 목록이 가르쳐 줄 수 없는 부분입니다. 진짜 통증을 알아낸 뒤, 당신은 고객의 지저분한 현실을 명시적 모델로 바꿔야 합니다 — 그들 비즈니스의 실제 명사와 동사, 엔티티와 그 사이의 관계 — 양쪽이 함께 가리키고 함께 논쟁할 수 있는 것으로. Palantir은 일상 업무를 "designing, writing and testing workflows"라고 표현하는데, 모든 워크플로 밑에는 "고객의 세계가 무엇인가"에 대한 모델이 깔려 있습니다.

이 모델이 곧 계약입니다. "필요한 것"과 "짓는 것" 사이에 정확히 놓여, 그 둘을 모두 읽을 수 있게 만듭니다. 당신과 고객의 이해가 어긋날 때, 당신은 모델로 걸어가 손가락으로 가리킬 수 있어야 합니다 — 이 엔티티, 이 관계, 여기서 우리의 이해가 갈라진다고. 모델이 없으면 의견을 주고받을 뿐이고, 모델이 있으면 공유된 산출물을 디버깅하는 것입니다. 우연이 아니게도, Palantir이 두 역할로 공식화한 분업이 바로 이것입니다 — 문제와 모델을 소유하는 Deployment Strategist, 소프트웨어를 소유하는 FDSE. 다만 OpenAI와 Anthropic에서는 한 명의 FDE가 그 둘을 함께 집니다.

이 모델을 제대로 잡는 것이 FDE가 하는 일 중 레버리지가 가장 큰 일이고, 별도로 다룰 만큼 깊습니다. 이 시리즈의 다음 글은 이 모델을 형식화하는 것 — 소프트웨어가 추론할 수 있는 *온톨로지(ontology)*로 바꾸는 것 — 을 다루고, 그다음 글은 그 모델 위에서 Graph RAG로 검색하는 것을 다룹니다. 지금은 원칙만 붙잡으면 됩니다. 모델은 코드보다 먼저 오고, 틀린 모델을 아무리 아름답게 구현해도 여전히 틀린 것입니다.

지저분하고, 에어갭이며, 레거시인 환경에 통합하기

여기서 앞선 준비기의 지식 지도가 실제로 쓰입니다. 다만 크래프트는 그린필드 엔지니어링과 다릅니다 — 환경이 구체적이고 반복적인 방식으로 당신과 싸우기 때문입니다.

닫힌 망. 에어갭 구역, 사설 레지스트리, 사내 프록시가 예외가 아니라 기본값이다.
거짓말하는 데이터. 진짜 데이터는 아무도 완전히 이해하지 못하는 레거시 시스템에 살고, 문서와 절대 일치하지 않는다.
물려받은 규모. Palantir의 한 엔지니어는 문제의 형태를 대략 이렇게 요약한다 — 비즈니스가 멈추면 안 되는 워크플로에 데이터를 공급하는 테라바이트급 파이프라인을 어떻게 짓고 유지하는가.
모든 단계의 관문. 고객사 보안팀은 우회할 장애물이 아니라 통과해야 할 관문이며 — 당신이 얼마나 빨리 반복할 수 있는지에 대한 실제 제약이다.

여기서의 크래프트는 조정(reconciliation)입니다 — 한 손엔 깨끗한 도메인 모델을, 다른 손엔 실제의 더러운 바이트를 들고, 어느 쪽도 틀렸다고 우기지 않으면서 그 간극을 좁히는 것. 좋은 FDE들의 방식에서 빌려 온 유용한 규율 하나는, 먼저 합성 데이터로 프로토타입해 해법의 형태를 증명하고 — 그다음에야 진짜 소스에 연결하는 것입니다. 놀라움은 늘 거기 숨어 있습니다. 앞 절의 모델이 이것을 견딜 만하게 만듭니다 — 바이트가 당신의 이해와 모순될 때, 당신에게는 "뭔가 어긋났다"는 막연한 느낌이 아니라 고쳐야 할 명시적 대상이 있습니다.

데모, 이해관계자, 그리고 기대 관리

데모는 세일즈용 소품이 아닙니다. FDE에게 데모는 일차 피드백 도구입니다 — 당신의 요구사항 발굴이 틀렸음을 발견하는 가장 빠르고 값싼 방법. Palantir은 좋은 버전을 "rapid cycle between creating solutions and seeing them in action", 즉 고객과 손을 맞잡고 반복하는 것이라 표현합니다. 고객의 마음을 바꾸거나 당신이 그들의 마음을 오해했음을 드러내는 데모는, 코드를 버리더라도 제 몫을 다한 것입니다. 이 "버리는 프로토타입" 방식의 구체적 메커니즘은 버리는 프로토타입 플레이북에서 따로 다뤘습니다.

틀리기 쉬운 크래프트 포인트가 둘 있습니다. 첫째, 방 안에는 이해관계자가 한 명이 아닙니다 — 여럿이고, 자주 갈라져 있으며, 각자 성공을 다르게 잽니다. 그 방을 붙잡는 것 — 이견을 소리 내어 이름 붙이고, 가장 큰 목소리를 위해 조용히 짓는 대신 결정으로 몰고 가는 것 — 이 일의 일부입니다. 둘째, 너무 매끈한 데모를 경계하십시오. 완성된 것처럼 보이는 데모는 당신이 아직 벌지 못한 약속을 만듭니다 — 무엇이 진짜이고, 무엇이 가짜이며, 무엇이 남았는지 이음매를 보여 주는 것이 기대를 정직하게 유지하고, 어려운 부분이 닥쳤을 때 신뢰를 지킵니다.

언제 아니오라고 말할까 — 과잉 설계 피하기

"one customer, many capabilities"는 설명이지 허가증이 아닙니다. 고객이 요청하는 모든 기능을 지으려는 순간 그것은 함정이 됩니다. 당신이 임베드돼 있기 때문에, 그들이 성공하길 바라기 때문에, 예라고 말하는 것이 봉사처럼 느껴지기 때문에 — 과잉 설계는 FDE의 기본 실패 모드입니다. 당신이 추가하는 모든 기능은, 결국 당신이 떠날 환경에서 당신이 유지보수해야 할 하나입니다.

규율은 고객의 실제 목표를 움직이는 것만 짓고 나머지엔 아니오라고 말하는 것입니다 — 분명하게, 일찍, 이유를 붙여서. The Pragmatic Engineer는 이를 직접 지목합니다 — FDE는 고객 성공과 제품 사이의 다리이고, 다리는 경쟁하는 요구들에 우선순위를 매기고 아니오라고 말해야 합니다. Anthropic의 FDE 공고도 다른 각도에서 같은 곳을 가리킵니다 — 미션은 "codify repeatable deployment patterns"하고 인사이트를 제품으로 되돌리는 것. 즉 일회성 맞춤보다 일반화되는 것을 택하라는 뜻입니다. 맞춤은 당신의 퇴장에서 살아남지 못하니까요.

성공은 실제로 어떻게 측정되나 — 짠 코드가 아니라 채택

위 움직임 중 어느 것도 산출량으로 채점되지 않습니다. The Pragmatic Engineer는 분명히 말합니다 — FDE는 "measure success in terms of impact on the customer's goal", 즉 배포한 코드 줄 수가 아니라 조립 라인에서 나오는 불량품이 줄었는가로 잽니다. Palantir의 엔지니어들도 보상을 같은 식으로 묘사합니다 — 소프트웨어가 고객의 의사결정에 미친 임팩트를 직접 눈으로 보는 것. 지표는 당신의 커밋 로그가 아니라 고객의 세계를 가리킵니다.

이것의 잔인하고 명료한 버전은 한 문장의 질문입니다 — 당신이 떠난 뒤에도 그들이 계속 썼는가? 아무도 열지 않는 아름다운 시스템은 실패이고, 누군가의 일상 업무에서 없으면 안 되는 존재가 된 하드코딩된 프로토타입은 성공입니다. 이 질문은 위쪽의 모든 것을 다시 규정합니다 — 발굴도, 공유 모델도, 데모도, 아니오라고 말하는 규율도 모두 채택을 위해 존재합니다. 제품 회사에는 두 번째 축도 있습니다 — 고객 안에서 배운 것이 제품이 됩니다. Anthropic은 문자 그대로 FDE에게 그 패턴을 Product·Engineering으로 되돌리라고 요구합니다. 최고의 FDE는 자신을 단순한 전달 수단이 아니라 로드맵의 센서로 만듭니다.

정직한 부분 — 다리로 서 있기

이 일의 어려운 부분은 기술이 아닙니다. 당신이 어느 쪽에도 온전히 속하지 못한다는 것입니다. 고객의 좌절을 당신 회사로 나르고, 당신 제품의 한계를 고객에게 나르며, 둘 다 여전히 참인 그 간극에 서 있습니다. 모호함은 예외가 아니라 기본값입니다 — Anthropic 공고는 "operate autonomously, thrive under ambiguity"할 사람을 대놓고 찾고, 모든 FDE 공고가 같은 말을 어떤 형태로든 반복합니다.

그리고 물리적 현실이 있습니다 — Palantir은 약 25%, Anthropic은 25–50%의 출장, 고객의 일정에 맞춰, 그들의 보안 경계 안에서, 자주 그것이 깨졌을 때 그들이 부를 유일한 이름으로. 이것은 어떤 사람에게는 에너지를 주고, 어떤 사람에게는 조용히 소모시킵니다. 서명하기 전에 자신이 어느 쪽인지 아는 편이 낫습니다. 이 크래프트는 정말로 드물고 빠르게 복리로 쌓입니다 — 다만 그 값은 스킬 목록이 결코 언급하지 않는, 두 조직 사이의 일종의 무주지(homelessness)로 치릅니다.

마치며

지식 지도는 당신을 유능하게 만듭니다. 크래프트 — 진짜 필요를 파고들고, 도메인을 양쪽이 가리킬 수 있는 것으로 모델링하고, 적대적 환경에 통합하고, 데모를 피드백으로 쓰고, 아니오라고 말하고, 채택을 향해 끈질기게 최적화하는 것 — 은 당신을 신뢰받게 만듭니다. 앞은 체크리스트이고, 뒤는 판단이며, 그것은 오직 지켜보는 고객 앞에서 일을 해 봐야 얻어집니다.

토대를 쌓는 중이라면 지식 지도와 그 체크리스트 도구에서 시작하십시오. 여기서부터 시리즈는 위의 가장 레버리지 큰 움직임으로 더 깊이 들어갑니다 — 다음 글은 도메인 모델을 온톨로지로 형식화하고, 그다음 글은 그 위에서 Graph RAG로 검색합니다. 코드는 애초에 어려운 부분이 아니었습니다. 고객의 세계가 실제로 무엇인지 정하는 것 — 그것이 크래프트입니다.