코드보다 먼저 문제를 배포하라
Deploy the Problem Before the Code: What an FDE Actually Builds
A Forward Deployed Engineer does not ship code as the primary deliverable. The real output is a repeatable way of working that a customer can own after the engineer leaves. In a two-hour onsite with a bankruptcy lawyer, the goal was not "an AI app" but the removal of a recurring document-review bottleneck under strict privacy constraints. The strongest success signal was not a demo — it was the customer starting to build their own skills. This journal turns that pattern into a reusable Problem-to-Deployment Canvas.
핵심 주장: FDE의 산출물은 코드가 아니라 고객이 반복해서 사용할 수 있는 새로운 업무 방식이다. 코드는 그 방식을 실현하는 여러 도구 중 하나일 뿐이다.
현장 문제부터
한 파산 전문 변호사는 매달 12건 안팎의 사건에서 같은 문서검토를 반복하고 있었다. 문제는 세 겹이었다. 첫째, 반복 작업이 시간을 잡아먹는 병목이었다. 둘째, 다루는 자료가 극도로 민감한 개인정보였다. 셋째, 결론에는 반드시 법적 근거 확인이 필요했다. "AI를 써보자"는 막연한 요구였지, 어떤 모델이나 앱을 원한 것이 아니었다.
FDE의 첫 일은 코드가 아니라 마찰의 정의였다. "가장 복잡한 기술"이 아니라 "가장 선명한 사용자 마찰"을 고른다. 여기서 마찰은 반복 검토였고, 제약은 개인정보였다.
시스템 경계와 의사결정
2시간 온사이트에서 만든 것은 앱이 아니라 작업 흐름이었다.
- 로컬 마스킹 리더 — 원문은 고객 기기를 벗어나지 않는다. Python으로 개인정보를 마스킹해 검토용 패킷만 만든다.
- Codex 검토 패킷 생성 — 마스킹된 자료로 반복 검토 초안을 생성한다.
- 법령 MCP 근거 확인 — 모델의 기억이 아니라 실제 법령 데이터를 조회해 근거를 붙인다.
- 변호사 최종 판단 — 결정은 항상 사람이 내린다. 시스템은 초안과 근거만 제공한다.
여기서 기술 선택(어느 모델, 어느 언어)은 전체의 3분의 1도 되지 않았다. 나머지는 데이터 경계, 권한, 인간 판단 지점을 어디에 둘지에 대한 결정이었다.
실패 가능성과 안전장치
- 개인정보 유출 → 원문 비반출을 시스템 구조로 강제(업로드 자체를 없앰). "안전하게 업로드"가 아니라 "업로드 안 함".
- 모델 환각으로 잘못된 법적 근거 → 근거는 모델이 아니라 법령 MCP 조회 결과로만 채움.
- 자동화 과신 → 최종 판단은 변호사. 시스템은 결정권이 없다.
측정 지표
과장된 수치를 지어내지 않는다. 이 배포에서 본 실제 신호는 다음이었다.
- 반복 검토 1건을 만드는 데 걸리던 흐름이 온사이트 2시간 안에 동작하는 검토 패킷으로 전환됨.
- 가장 강한 성공 신호: 고객이 세션이 끝난 뒤 스스로 자기 skill과 루틴을 만들기 시작했다. 자립은 데모보다 강한 채택 지표다.
내 경험과의 연결
20년 넘게 디스플레이·반도체 제조 품질 현장에서 일하며 배운 것은, 좋은 해법은 "가장 앞선 기법"이 아니라 "현업이 다음 날에도 스스로 돌릴 수 있는 절차"라는 점이다. 6시그마도 TRIZ도 결국 반복 가능한 업무 방식을 남길 때만 조직에 뿌리내렸다. FDE도 같다. 데모는 하루 가지만, 인수인계 자산은 남는다.
재사용 패턴 — Problem-to-Deployment Canvas
- 사용자 — 누가 실제로 이 마찰을 겪는가
- 반복되는 마찰 — 무엇이 매번 시간을 먹는가
- 현재 우회 방법 — 지금은 어떻게 버티는가
- 최소 동작 시스템 — 흐름을 바꾸는 가장 작은 시스템
- 데이터·권한 경계 — 무엇이 어디를 벗어나면 안 되는가
- 인간 최종 판단 — 결정은 누가 내리는가
- 성공 지표 — 무엇으로 성공을 재는가
- 인수인계 자산 — 떠난 뒤 고객에게 무엇이 남는가
영어 면접 질문 3개
Q1. Walk me through a deployment where the hardest part was not the model.
답변 포인트: 변호사 사례 — 어려운 건 모델이 아니라 개인정보 경계와 인간 판단 지점 설계. STAR로 Situation→Task→Action→Result.
Q2. How do you decide what to build first for a customer?
답변 포인트: "가장 복잡한 기술"이 아니라 "가장 선명한 마찰"을 고른다. Problem-to-Deployment Canvas 1~4단계.
Q3. What does success look like beyond a working demo?
답변 포인트: 고객이 스스로 skill을 만들기 시작하는 자립 신호. 인수인계 자산이 남았는가.
출처
- Anthropic — Building effective agents (단순한 것부터, 복잡도는 필요할 때만)
- Anthropic — Claude Code best practices
- OpenAI — Separating signal from noise in coding evaluations
다음에 실제로 만들 것
고객 인터뷰 30분이면 채워지는 Problem-to-Deployment Canvas 웹 템플릿 — 8칸을 채우면 "최소 동작 시스템" 초안과 데이터 경계 체크리스트를 자동 제안.
관련 글: 지시는 채널로, 데이터는 기기에 · 새로운 풀스택