LabHub

블로그

FDE 플레이북: 버리는 프로토타입으로 이기기

2026-06-30 · 16 분 읽기 · #engineering#prototyping#fde

한국어English日本語中文

들어가며 — 슬라이드가 아니라 돌아가는 것

포워드 배포 엔지니어(FDE)의 세계에서 가장 강력한 무기는 잘 만든 발표 자료가 아닙니다. 고객의 진짜 데이터 위에서 실제로 돌아가는 프로토타입입니다. 백 장짜리 제안서보다, 고객이 자기 데이터가 화면에서 움직이는 걸 보는 3분이 더 큰 설득력을 가집니다.

그리고 이 프로토타입의 핵심 특징은 하나입니다. 버릴 것을 전제로 만든다. 프로덕션 코드처럼 정성 들여 다듬는 게 아니라, 가치를 증명하기 위한 목적으로만 빠르게 조립하고, 증명이 끝나면 미련 없이 버립니다. 이 글은 그 "버리는 프로토타입"으로 어떻게 이기는지에 대한 플레이북입니다.

왜 버리는 프로토타입인가

전통적인 엔지니어링 감각으로 보면 이 접근은 낭비처럼 보입니다. 어차피 버릴 걸 왜 만드나? 답은 명확합니다. 프로토타입의 목적은 코드를 남기는 게 아니라, 배움과 확신을 남기는 것이기 때문입니다.

며칠간의 프로토타입 하나가 답해 주는 질문들을 생각해 보세요.

이 질문들에 대한 답은 문서를 아무리 읽어도 나오지 않습니다. 오직 실제로 만들어 봐야 나옵니다. 그리고 답을 얻고 나면, 그 조잡한 코드 자체는 이미 소임을 다한 것입니다.

스파이크: 위험을 먼저 걷어낸다

애자일 세계에는 스파이크(spike)라는 개념이 있습니다. 불확실성이 가장 큰 부분을 먼저 찔러 보는, 시간 제한을 둔 탐색적 작업입니다. FDE의 프로토타입은 본질적으로 거대한 스파이크입니다.

핵심은 가장 위험한 가정을 맨 먼저 검증하는 것입니다. 프로젝트가 실패한다면 어디서 실패할까? 그 지점을 먼저 공략합니다.

예를 들어 "고객의 PDF 계약서 10만 건에서 특정 조항을 추출한다"는 프로젝트라면, 가장 큰 위험은 UI도 인증도 아닙니다. 모델이 그 지저분한 실제 PDF에서 조항을 제대로 뽑아내는가입니다. 그러니 UI는 나중이고, 며칠 안에 진짜 PDF 몇 백 건에 모델을 돌려 정확도를 확인하는 게 먼저입니다. 그게 안 되면 나머지는 의미가 없으니까요.

스파이크의 규칙은 단순합니다.

의도적 기술 부채: 빌리되, 기록하라

버리는 프로토타입에서는 기술 부채가 죄가 아니라 전략입니다. 다만 의도적이어야 합니다.

"나쁜 부채"는 자기도 모르게 쌓이는 부채입니다. "좋은 부채"는 눈 뜨고 빌리는 부채입니다. "지금은 속도가 중요하니 여기서 지름길을 탄다. 나중에 프로덕션에서는 이렇게 제대로 할 것이다"라고 스스로 알고 빌리는 것이죠.

의도적 기술 부채를 다루는 원칙은 이렇습니다.

언제 하드코딩할 것인가

프로토타입에서 하드코딩은 부끄러운 일이 아니라 강력한 기법입니다. 문제는 "어디를" 하드코딩하느냐입니다.

원칙은 이렇습니다. 증명하려는 가치의 바깥에 있는 모든 것은 하드코딩 후보다.

반대로, 절대 하드코딩하면 안 되는 것이 있습니다. 바로 데모의 심장, 즉 증명하려는 그 가치입니다. 조항 추출 데모에서 추출 결과를 미리 손으로 넣어 두면, 그건 데모가 아니라 사기입니다. 고객이 즉석에서 자기 문서를 던졌을 때 진짜로 작동해야, 그 순간이 아하 모먼트가 됩니다.

아래는 이 감각을 코드로 표현한 예시입니다. 진짜 가치(추출)는 실제로 돌리고, 나머지는 뻔뻔하게 하드코딩합니다.

# demo_extractor.py — 데모용 프로토타입 (버릴 코드)

# [하드코딩 OK] 데모의 가치가 아닌 것들
DEMO_CUSTOMER = "acme-corp"
FAKE_AUTH_TOKEN = "demo-token-do-not-ship"
TARGET_CLAUSE_TYPES = ["indemnification", "termination", "liability"]

def get_current_user():
    # [의도적 부채] 데모에서는 인증을 흉내만 낸다. 프로덕션에서는 진짜 OAuth로 교체.
    return {"org": DEMO_CUSTOMER, "token": FAKE_AUTH_TOKEN}

def extract_clauses(pdf_text: str) -> list[dict]:
    # [진짜 가치] 여기만큼은 실제로 동작해야 한다. 절대 하드코딩 금지.
    # 고객이 즉석에서 던진 문서에도 진짜로 작동하는 것이 데모의 핵심.
    prompt = build_extraction_prompt(pdf_text, TARGET_CLAUSE_TYPES)
    response = call_llm(prompt)
    return parse_clauses(response)

def save_results(results: list[dict]) -> None:
    # [의도적 부채] 데모에서는 그냥 로컬 JSON. 프로덕션에서는 DB로 교체.
    import json, pathlib
    pathlib.Path("demo_output.json").write_text(json.dumps(results, indent=2))

아하 모먼트까지 최단 거리로

FDE 프로토타이핑의 목표는 단 하나로 수렴합니다. 고객을 아하 모먼트까지 최대한 빨리 데려가는 것. 아하 모먼트란, 고객이 "아, 이게 우리 문제를 이렇게 풀어 주는구나"를 머리가 아니라 눈으로 이해하는 순간입니다.

이 거리를 줄이는 몇 가지 원칙이 있습니다.

기대치 관리: 데모는 데모라고 말하라

버리는 프로토타입의 가장 큰 위험은 기술이 아니라 오해입니다. 데모가 너무 매끄러우면, 고객(그리고 때로는 내부 영업)은 "거의 다 됐네요, 다음 주에 배포할 수 있죠?"라고 생각해 버립니다. 며칠짜리 데모와 프로덕션 사이에는 몇 달의 거리가 있는데도 말입니다.

그래서 기대치 관리는 프로토타이핑의 필수 절반입니다.

이걸 제대로 하면, 데모의 감동을 유지하면서도 비현실적인 일정 압박을 피할 수 있습니다.

프로토타입에서 프로덕션으로

데모가 성공하고 계약이 진행되면, 이제 진짜 질문이 옵니다. 이 프로토타입 코드를 어떻게 프로덕션으로 만들 것인가?

여기서 흔한 실수 두 가지가 있습니다. 하나는 프로토타입을 그대로 프로덕션으로 밀어 넣는 것이고(임시 처리가 그대로 남아 폭탄이 됩니다), 다른 하나는 처음부터 전부 다시 쓰는 것입니다(배운 것을 버립니다). 좋은 답은 대개 그 사이에 있습니다.

안티패턴: 이럴 때는 멈춰라

버리는 프로토타입도 잘못 쓰면 독이 됩니다. 다음 신호가 보이면 접근을 재점검해야 합니다.

마치며

FDE의 프로토타이핑은 "대충 만든다"가 아니라 "무엇을 대충 만들지 정확히 안다"는 기술입니다. 가장 위험한 가정을 스파이크로 먼저 찌르고, 가치의 바깥은 뻔뻔하게 하드코딩하고, 고객을 자기 데이터의 아하 모먼트로 최단 거리로 데려가고, 데모는 데모라고 정직하게 말하고, 검증된 핵심만 프로덕션으로 승격시킵니다.

버리는 프로토타입의 역설은, 버릴 것을 만들었기에 오히려 가장 값진 것 — 확신과 방향과 고객의 신뢰 — 을 남긴다는 점입니다. 다음 글에서는 이렇게 한 고객을 위해 만든 것이 어떻게 모든 고객을 위한 플랫폼으로 자라나는지를 이야기합니다.

참고 자료

원문 보기: https://www.youngju.dev/blog/2026-06-30-fde-throwaway-prototypes

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다