Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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

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

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

왜 버리는 프로토타입인가

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

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

  • 이 문제에 이 기술이 정말로 통하는가?
  • 고객의 데이터는 우리가 가정한 만큼 깨끗한가, 아니면 지옥인가?
  • 고객이 진짜로 원하는 게 우리가 상상한 그것이 맞는가?
  • 이 방향으로 6개월을 투자할 가치가 있는가?

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

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

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

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

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

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

  • 시간을 못 박는다: "이틀 안에 결론을 낸다." 스파이크는 무한정 늘어지면 안 됩니다.
  • 질문을 명확히 한다: "이게 되나 안 되나"라는 예/아니오 질문을 세웁니다.
  • 결과는 지식이다: 성공하면 자신감을, 실패하면 방향 전환을 얻습니다. 둘 다 이득입니다.

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

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

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

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

  • 부채임을 기록한다: 지름길을 탄 자리에 표시를 남깁니다. 프로토타입을 발표할 때도 "이 부분은 데모용 임시 처리"라고 솔직히 밝힙니다.
  • 핵심 로직과 임시 처리를 분리한다: 진짜 가치를 증명하는 핵심 부분(예: 추출 로직)은 나름 신경 쓰고, 주변부(인증, 저장, UI)는 과감히 대충 합니다.
  • 되돌릴 수 있게 둔다: 나중에 이 지름길을 걷어내야 할 때 어디를 손대야 하는지 명확하게 남겨 둡니다.

언제 하드코딩할 것인가

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

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

  • 인증/권한: 데모에서 로그인 흐름은 대개 가치가 아닙니다. 그냥 토큰 하나를 박아 둡니다.
  • 설정값: 고객사 이름, 임계값, 카테고리 목록 등은 일단 코드에 박습니다. 나중에 설정으로 뺍니다.
  • 주변 통합: 아직 붙이지 않은 외부 시스템은 가짜 응답으로 흉내 냅니다.

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

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

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

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

  • 고객의 데이터로 시연한다: 우리 샘플 데이터로 아무리 잘 돌아가도 고객은 남 얘기로 듣습니다. 고객 자기 데이터가 움직이는 순간, 그제야 자기 일이 됩니다.
  • 가장 인상적인 한 흐름만 완성한다: 열 가지 기능을 어설프게 보여 주기보다, 하나의 "와우" 흐름을 매끄럽게 완성합니다. 데모는 넓이가 아니라 깊이입니다.
  • 첫 30초에 승부를 건다: 고객의 주의력은 짧습니다. 로그인, 설정, 온보딩으로 시간을 끌지 말고, 열자마자 핵심 가치를 보여 줍니다.
  • 실제 결과를 보여 준다: 목업 화면이 아니라 진짜 계산된 결과여야 합니다. 고객은 진짜와 가짜를 귀신같이 구별합니다.

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

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

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

  • 데모임을 분명히 한다: "이건 가치를 보여 드리기 위한 프로토타입이고, 뒤에는 임시 처리가 많습니다"라고 먼저 말합니다.
  • 프로덕션까지의 남은 일을 보여 준다: 데모 뒤에 필요한 진짜 작업(에러 처리, 규모 확장, 보안, 통합)의 목록을 함께 제시합니다.
  • "빙산"의 비유를 쓴다: 데모는 물 위로 드러난 빙산의 꼭대기이고, 프로덕션은 물 아래 거대한 몸통이라고 설명합니다.

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

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

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

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

  • 핵심 로직은 살리고, 껍데기는 갈아 끼운다: 프로토타입에서 진짜로 검증된 것은 핵심 가치 로직(추출·매칭·계산)입니다. 이 부분은 잘 다듬어 살리고, 하드코딩했던 인증·저장·UI·통합은 제대로 다시 짭니다.
  • 의도적 부채를 하나씩 갚는다: 앞서 남겨 둔 부채 표시를 지도 삼아, 임시 처리를 정식 구현으로 하나씩 교체합니다.
  • 프로토타입을 명세서로 쓴다: 프로토타입 자체가 "고객이 원하는 것"의 가장 정확한 명세입니다. 다시 쓰더라도, 이 살아 있는 명세를 기준 삼습니다.
  • 경계를 다시 긋는다: 어디까지가 이 고객만의 맞춤이고, 어디부터가 제품에 넣을 일반 기능인지 이때 판단합니다. (이 주제는 다음 글에서 깊게 다룹니다.)

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

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

  • 데모가 몇 주째 늘어진다: 며칠이어야 할 프로토타입이 몇 주가 되면, 그건 이미 프로토타입이 아니라 방향 없는 프로덕션입니다.
  • 버릴 코드에 애착이 생긴다: "이거 잘 짰는데 아깝다"는 마음이 들면 위험 신호입니다. 프로토타입은 버릴 수 있어야 자유롭습니다.
  • 가짜 데이터로만 잘 돈다: 고객의 진짜 데이터에서 무너진다면, 아직 위험을 검증하지 못한 것입니다.
  • 아무도 아하를 느끼지 못한다: 데모를 봐도 고객이 시큰둥하다면, 문제나 가치 가설 자체가 틀렸을 수 있습니다.

마치며

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

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

참고 자료

Discuss on Twitter • View on GitHub