Skip to content
Published on

맞춤형에서 플랫폼으로: FDE 작업을 제품화하기

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

들어가며 — 한 고객에서 모든 고객으로

앞선 두 글에서 우리는 포워드 배포 엔지니어(FDE)가 무엇인지, 그리고 버리는 프로토타입으로 한 고객을 어떻게 아하 모먼트까지 데려가는지를 이야기했습니다. 이번 글은 그다음 질문을 다룹니다. 한 고객을 위해 만든 맞춤 작업을, 어떻게 모든 고객을 위한 플랫폼으로 키울 것인가?

이것은 FDE 조직의 존재 이유이자, 가장 어려운 도전입니다. 잘못하면 회사는 고객 수만큼의 서로 다른 코드 뭉치를 짊어진 컨설팅 회사가 되어 버립니다. 잘하면, 현장에서 길어 올린 통찰이 회사의 핵심 제품이 됩니다. 실제로 많은 훌륭한 B2B 제품이 바로 이 경로로 태어났습니다.

FDE와 프로덕트의 피드백 루프

FDE의 진짜 가치는 코드가 아니라 정보에 있습니다. FDE는 회사에서 고객의 현실을 가장 깊이 아는 사람입니다. 어떤 문제가 반복되는지, 어떤 데이터가 실제로 존재하는지, 고객이 무엇에서 감동하고 무엇에서 좌절하는지 — 이 모든 것이 FDE의 머릿속과 손끝에 쌓입니다.

건강한 조직에서는 이 정보가 프로덕트 팀으로 흐릅니다.

  • FDE → 프로덕트: "다섯 고객이 전부 이 기능을 손으로 짜 달라고 했다. 이건 제품이 되어야 한다."
  • 프로덕트 → FDE: "그 기능을 이렇게 일반화해 만들었다. 다음 고객에는 맞춤 대신 이걸 써 보라."

이 루프가 돌면, FDE는 매번 바닥부터 만들 필요가 줄고, 프로덕트는 상상이 아니라 현장의 증거로 로드맵을 세웁니다. 반대로 이 루프가 끊기면, FDE는 영원히 같은 것을 반복해 만들고, 프로덕트는 실제 수요와 동떨어진 기능을 짓습니다.

N개의 고객에서 패턴을 발견하기

제품화의 출발점은 패턴 인식입니다. 한 고객의 요청은 그저 요청이지만, 여러 고객에게서 반복되는 요청은 신호입니다.

FDE가 패턴을 포착하는 감각은 이런 질문에서 나옵니다.

  • 서로 다른 고객에게 같은 코드를 복사-붙여넣기하고 있지 않은가?
  • 고객마다 이름만 다를 뿐, 본질적으로 똑같은 흐름을 다시 만들고 있지 않은가?
  • 여러 고객이 말은 다르게 하지만 사실 같은 문제를 겪고 있지 않은가?

세 번째가 특히 중요합니다. 고객 A는 "계약서 리스크 점검"을 원하고, 고객 B는 "벤더 문서 검토"를 원한다고 말하지만, 밑을 보면 둘 다 "긴 문서에서 특정 조건을 찾아 표시하기"라는 같은 뼈대일 수 있습니다. 표면의 어휘가 아니라 아래의 구조를 보는 눈, 그게 제품화의 첫걸음입니다.

설정과 추상화로 뽑아내기

패턴을 발견했다면, 다음은 그 패턴을 변하는 부분과 변하지 않는 부분으로 나누는 일입니다. 변하지 않는 부분은 엔진(제품)이 되고, 변하는 부분은 설정(config)으로 빠집니다.

계약서 조항 추출을 예로 들어 봅시다. 고객마다 다른 것은 "어떤 조항을 찾는가", "어떤 카테고리로 분류하는가", "어떤 형식으로 내보내는가" 정도입니다. 추출한다는 행위 자체, 모델을 부르고 결과를 파싱하는 뼈대는 모두 같습니다.

그러니 맞춤 코드를 이렇게 바꿉니다. 고객별 차이를 코드가 아니라 선언적 설정으로 밀어냅니다.

# customers/acme.yaml — 고객별 설정 (변하는 부분)
customer: acme-corp
clause_types:
  - indemnification
  - termination
  - liability
output_format: csv
risk_threshold: 0.7
notify_channel: "acme-legal-slack"

# customers/globex.yaml — 다른 고객, 같은 엔진
customer: globex-inc
clause_types:
  - data_privacy
  - auto_renewal
output_format: json
risk_threshold: 0.5
notify_channel: "globex-procurement-email"

엔진은 이 설정을 읽어 동작하는, 고객에 무관한 하나의 코드입니다.

# engine.py — 모든 고객이 공유하는 엔진 (변하지 않는 부분)
def run_extraction(config: dict, documents: list[str]) -> list[dict]:
    results = []
    for doc in documents:
        clauses = extract_clauses(doc, config["clause_types"])
        flagged = [c for c in clauses if c["risk"] >= config["risk_threshold"]]
        results.extend(flagged)
    export(results, fmt=config["output_format"])
    notify(config["notify_channel"], summary=summarize(results))
    return results

이제 새 고객이 오면 코드를 새로 짜는 게 아니라 YAML 한 장을 추가합니다. 맞춤 작업이 제품의 설정으로 승격된 것입니다. 이것이 "맞춤형에서 플랫폼으로"의 구체적인 모습입니다.

삼진 규칙: 언제 일반화하지 말아야 하는가

여기서 가장 흔한 실수는 너무 일찍 일반화하는 것입니다. 첫 고객의 요청을 보자마자 "이건 분명 모두가 원할 거야"라며 거창한 추상화를 짓기 시작합니다. 그리고 대개 그 추상화는 틀립니다. 두 번째 고객은 첫 번째와 미묘하게 다른 것을 원하고, 성급하게 지은 추상화는 오히려 발목을 잡습니다.

그래서 오래된 지혜가 있습니다. **삼진 규칙(rule of three)**입니다.

  • 첫 번째: 그냥 만든다. 이 고객만을 위해, 맞춤으로.
  • 두 번째: 비슷한 걸 또 만든다. 하지만 아직 일반화하지 않는다. 대신 두 사례의 공통점과 차이점을 관찰한다.
  • 세 번째: 세 번째로 같은 패턴이 나타나면, 이제 추상화한다. 세 개의 실제 사례가 있으니, 무엇이 진짜 공통이고 무엇이 고객별 변주인지 근거를 갖고 안다.

삼진 규칙의 핵심은 추상화를 데이터에 근거해 짓는다는 것입니다. 하나의 사례로 상상해서 짓는 추상화는 도박이고, 세 개의 사례로 관찰해서 짓는 추상화는 설계입니다. 두 번 복사-붙여넣기하는 약간의 중복은, 잘못된 추상화라는 큰 빚보다 훨씬 쌉니다.

"중복은 잘못된 추상화보다 훨씬 싸다." — 이 격언은 FDE의 제품화 판단에서 특히 무겁게 울립니다.

빨리 만드는 것과 모두를 위해 짓는 것의 긴장

FDE 조직의 심장부에는 근본적인 긴장이 있습니다.

  • 한편에는 눈앞의 고객이 있습니다. 이번 분기에 계약을 성사시키려면 지금 당장 이 고객의 문제를 풀어야 합니다. 속도가 전부입니다.
  • 다른 한편에는 미래의 모든 고객이 있습니다. 매번 맞춤으로 짜면 회사는 확장되지 않습니다. 재사용 가능한 제품을 지어야 합니다.

이 둘은 자주 충돌합니다. 지금 고객을 위한 가장 빠른 길은 하드코딩이지만, 모두를 위한 가장 좋은 길은 일반화이기 때문입니다. 성숙한 FDE와 조직은 이 긴장을 없애려 하지 않고, 의식적으로 관리합니다.

  • 먼저 고객을 이긴다, 그러나 흔적을 남긴다: 이번엔 맞춤으로 빠르게 풀되, "이건 세 번째 유사 사례다" 같은 신호를 프로덕트에 남깁니다.
  • 일반화는 프로덕트의 일로 넘긴다: FDE가 현장에서 매번 일반화까지 하려 들면 둘 다 못합니다. FDE는 패턴을 포착해 넘기고, 프로덕트가 그것을 제품으로 만듭니다.
  • 일회성과 반복을 구분한다: 어떤 고객의 요구는 정말로 그 고객만의 것입니다. 그런 건 일반화하지 않고 맞춤으로 두는 게 옳습니다. 모든 것을 제품화하려는 욕심이 오히려 제품을 망칩니다.

언제 일반화하지 말아야 하는가

삼진 규칙과 별개로, 처음부터 일반화가 답이 아닌 경우들이 있습니다.

  • 진짜로 그 고객만의 것일 때: 특정 규제, 특정 레거시 시스템, 특정 조직 구조에 묶인 요구는 남에게 재사용될 여지가 없습니다. 억지로 제품에 욱여넣으면 제품만 복잡해집니다.
  • 아직 패턴을 못 봤을 때: 사례가 하나뿐이면, 그것이 패턴인지 우연인지 알 수 없습니다. 기다립니다.
  • 핵심 가치가 아닐 때: 주변부의 사소한 편의 기능까지 전부 일반화할 필요는 없습니다. 제품의 중심 가치에 자원을 집중합니다.
  • 일반화 비용이 이득을 넘을 때: 유연한 추상화는 공짜가 아닙니다. 유지보수 부담, 복잡성, 그리고 잘못될 위험을 함께 삽니다. 두세 고객이면 그냥 두는 게 나을 수도 있습니다.

훌륭한 제품은 전방 배치에서 태어난다

이 모든 이야기의 결론은 하나로 모입니다. 많은 위대한 B2B 제품은 책상 위의 상상이 아니라, 고객 현장의 반복에서 태어났다.

패턴은 이렇습니다. FDE가 여러 고객에게서 같은 문제를 손으로 풀다가, 그 반복 속에서 진짜 수요를 발견합니다. 그 발견이 설정과 추상화를 거쳐 하나의 기능이 되고, 기능이 쌓여 제품이 되고, 제품이 셀프서비스가 되어 마침내 FDE 없이도 고객이 스스로 쓸 수 있게 됩니다. 그러면 FDE는 다음 미개척 문제로 이동합니다.

이 선순환이 바로 FDE 모델의 궁극적 목적입니다. FDE는 자신을 불필요하게 만드는 방향으로 일합니다. 오늘 손으로 하는 일이 내일의 제품 기능이 되고, 그 기능이 있어 다음 고객에게는 더 이상 손이 필요 없어지는 것. 한 고객을 구하는 일이 수천 고객을 위한 제품으로 자라나는 것.

마치며

맞춤형에서 플랫폼으로 가는 길은 자동으로 열리지 않습니다. FDE와 프로덕트 사이의 살아 있는 피드백 루프, 여러 고객에서 패턴을 읽는 눈, 변하는 것과 변하지 않는 것을 가르는 설계 감각, 성급한 일반화를 막는 삼진 규칙, 그리고 지금 고객과 미래 고객 사이의 긴장을 의식적으로 관리하는 성숙함이 필요합니다.

이 세 편의 글을 관통하는 하나의 메시지가 있다면 이것입니다. FDE는 고객의 최전선에서 진짜 문제를 풀고, 그 경험을 모두를 위한 제품으로 되돌려 주는 다리다. 버리는 프로토타입으로 한 고객을 이기고, 그 승리에서 배운 것을 플랫폼으로 키우는 것 — 그것이 전방 배치 엔지니어링이 소프트웨어를 만드는 방식입니다.

참고 자료

Discuss on Twitter • View on GitHub