Skip to content
←

Split View: PoC는 왜 프로덕션에 못 가는가 — 성공 기준, 보안 검토, 인수인계

✨ Learn with Quiz
|

PoC는 왜 프로덕션에 못 가는가 — 성공 기준, 보안 검토, 인수인계

PoC의 무덤 — 죽는 이유들

FDE의 일 중에서 가장 허무한 장면은 기술적으로 성공한 PoC가 조용히 사라지는 순간입니다. 데모에서 박수를 받았고, 담당자도 만족했는데, 석 달 뒤에 물어보면 아무 일도 일어나지 않았습니다. 부검을 해 보면 사인은 대체로 다섯 가지 중 하나입니다.

  • 성공 기준이 없었다. 끝났는데 성공인지 아무도 판정할 수 없으면, 결정은 무기한 연기됩니다.
  • 챔피언이 없었다. 데모에 감탄한 사람은 많아도 예산 회의에서 싸워 줄 한 사람이 없으면 다음 단계가 없습니다.
  • 보안 검토를 마지막에 시작했다. 기술 검증이 끝난 뒤에야 보안팀이 등장하면, 검토 기간이 그대로 모멘텀을 죽입니다.
  • PoC 환경과 프로덕션의 격차를 늦게 발견했다. 더미 데이터, 우회된 권한, 한 대짜리 서버로 증명한 것은 프로덕션의 증명이 아닙니다.
  • 예산 사이클과 어긋났다. 결정권자의 예산 일정과 무관하게 끝난 PoC는 다음 회계 연도까지 냉동됩니다.

다섯 개 모두 코드의 문제가 아니라는 점이 핵심입니다. PoC에서 프로덕션까지의 구간은 엔지니어링 실력이 아니라 운영 설계에서 갈립니다. 그리고 이 구간에서 FDE의 역할은 두 겹입니다. 코드를 쓰는 엔지니어인 동시에, 성공 기준과 일정과 이해관계자를 관리하는 사실상의 프로젝트 매니저입니다. 둘 중 후자를 자기 일이 아니라고 여기는 순간, 위의 다섯 사인 중 하나가 예약됩니다. 아래 네 개의 장은 그 후자의 일을 순서대로 다룹니다.

시작 전에 성공 기준을 문서로

성공 기준 문서는 PoC를 시작하기 전에, 고객과 함께, 한 페이지로 씁니다. 숫자, 기간, 판정자가 셋 다 들어가야 기준이고, 하나라도 빠지면 감상입니다.

[PoC 성공 기준 — 구성한 예시]
목표     : 상담원의 문서 검색-첫 응답 시간을 40% 단축
측정     : 상담 100건 표본에서 검색-첫 응답 시간을 2주간 측정
기준선   : 현행 평균 90초 (시작 전 1주간 사전 측정으로 합의)
판정     : 54초 이하면 성공. 판정자는 고객측 콜센터 운영팀장
실패 조건: 재검색률이 15%를 넘으면 속도와 무관하게 실패로 판정
다음 단계: 성공 시 4주 안에 파일럿 확대 범위와 예산 논의를 시작

이 문서에서 가장 값진 줄은 실패 조건입니다. 실패 조건을 미리 적어 둔 PoC는 실패해도 신뢰를 남깁니다. 무엇이 안 되는지를 정확히 알게 됐기 때문입니다. 반대로 실패 조건이 없는 PoC는 성공해도 의심을 남깁니다. 그리고 마지막 줄, 성공하면 무엇이 일어나는지의 약속이 있어야 PoC가 결정으로 이어집니다.

보안 검토, 권한, 데이터 경계

보안 검토는 PoC의 마지막 관문이 아니라 첫 주의 일정입니다. 첫 주에 고객 보안팀과 30분 미팅을 잡고 세 가지를 합의합니다.

첫째, 데이터 경계. 고객 데이터가 어디까지 이동하는가. 외부 API로 나가는가, 나간다면 어떤 필드가 나가는가. 로그에 무엇이 남는가. 모델 학습에 쓰이는가. 이 질문들에 대한 답을 그림 한 장으로 그려 합의하면, 나중에 나올 반대의 대부분이 미리 소화됩니다. 둘째, 권한. PoC용 계정은 최소 권한으로, 만료일을 박아서 받습니다. 편의상 받은 관리자 권한은 나중에 보안 감사에서 PoC 전체의 신뢰를 깎는 증거물이 됩니다. 셋째, 검토 일정 자체의 합의. 프로덕션 전환에 어떤 심사가 필요하고 통상 몇 주가 걸리는지를 첫 주에 물어 두면, 마지막 주의 서프라이즈가 사라집니다.

PoC 코드가 숨기고 있는 부채

PoC 코드는 빠르게 증명하기 위해 의도적으로 빚을 냅니다. 문제는 그 빚이 보이지 않는 채로 프로덕션 결정의 근거가 된다는 것입니다. 전환을 논의하는 시점에는 부채 목록을 명시적으로 꺼내야 합니다.

  • 설정 파일에 박힌 자격 증명 — 비밀 관리 체계로 이전해야 합니다.
  • 에러 처리 부재 — 행복 경로만 검증된 코드는 첫 장애에서 무너집니다.
  • 단일 인스턴스 — 재시작, 스케일, 배포 전략이 전부 미정입니다.
  • 모니터링 부재 — 프로덕션에서는 죽어도 아무도 모릅니다.
  • 우회된 인증 — PoC에서 꺼 둔 SSO 연동이 전환 작업의 절반인 경우가 흔합니다.

이 목록을 고객 앞에서 먼저 꺼내는 것이 FDE의 정직성이고, 동시에 전환 견적의 근거입니다. "데모는 됐는데 프로덕션은 왜 석 달이 걸리나요"라는 질문에 대한 답이 이 목록입니다. 단, 부채 목록은 위협이 아니라 견적의 언어로 말해야 합니다. 이 다섯 개를 갚는 데 몇 주가 필요하다는 문장은 고객에게 비용이 아니라 계획으로 들리고, 목록이 구체적일수록 전환 예산의 승인은 빨라집니다.

인수인계 문서 — 떠나는 날을 위해

FDE의 성공 조건은 특이합니다. 내가 없어도 굴러가야 성공입니다. 상주가 끝나는 날 시스템이 같이 멈춘다면, 그것은 배포가 아니라 대여였던 셈입니다. 그래서 인수인계 문서는 마지막 주가 아니라 프로젝트 중반부터 쌓아야 합니다.

[인수인계 문서 목차 — 구성한 예시]
1. 시스템 개요   — 아키텍처 그림 한 장과 데이터 흐름
2. 운영 절차     — 시작, 중지, 배포, 백업, 복구
3. 장애 런북     — 자주 나는 증상별 첫 30분의 행동
4. 권한과 연락처 — 계정 목록, 승인자, 에스컬레이션 경로
5. 알려진 한계   — 안 되는 것, 미해결 이슈, 임시 조치 목록
6. 확장 로드맵   — 다음 단계로 논의된 것과 보류된 것

이 중 고객이 가장 자주 다시 여는 문서는 장애 런북입니다. FDE 엔지니어 키우기 RPG의 인수인계 롤이 런북 있는 미션에서만 플레이되도록 설계된 것도 같은 이유입니다. 런북이 없는 시스템은 넘길 수 없는 시스템입니다. 문서를 넘기는 날에는 문서만 넘기지 말고, 고객 엔지니어가 런북대로 장애 시나리오 하나를 직접 처리해 보는 리허설까지 하는 것이 완결입니다.

직접 연습하기

PoC 운영의 감각은 압박 속의 의사결정 연습으로 길러집니다.

  • FDE 엔지니어 키우기 RPG — 프리세일즈 PoC 롤은 제한 시간 안에 성공 기준을 만족시켜야 하고, 인수인계 롤은 런북이 있어야 시작됩니다. 이 글의 두 축을 그대로 게임 규칙으로 만든 것입니다.
  • FDE 커리큘럼 로드맵 — 보안, 데이터 파이프라인 등 전환 작업에 필요한 도메인을 체크리스트로 점검합니다.

FDE 완전 가이드 시리즈

Why PoCs Never Reach Production — Success Criteria, Security Review, Handover

The PoC Graveyard — How They Die

The most deflating scene in FDE work is a technically successful PoC disappearing in silence. The demo got applause, the point of contact was satisfied — and three months later, nothing has happened. Run the autopsy and the cause of death is usually one of five.

  • There were no success criteria. If nobody can rule it a success when it ends, the decision gets postponed indefinitely.
  • There was no champion. Plenty of people admired the demo, but without one person who will fight for it in the budget meeting, there is no next step.
  • The security review started last. When the security team first appears after technical validation ends, the review period kills the momentum outright.
  • The gap between PoC and production surfaced late. What was proven on dummy data, bypassed permissions, and a single server is not proof about production.
  • It missed the budget cycle. A PoC that ends out of sync with the decision-maker's budget calendar gets frozen until the next fiscal year.

Note that none of the five is a code problem. The stretch from PoC to production is decided by operational design, not engineering skill. And along this stretch the FDE role is two-layered: the engineer writing the code, and at the same time the de facto project manager tending success criteria, schedule, and stakeholders. The moment you decide the second layer is not your job, one of the five causes of death above gets reserved in your name. The four chapters below take that second layer in order.

Write the Success Criteria Before You Start

The success criteria document is written before the PoC starts, together with the customer, on one page. It needs all three of a number, a period, and a judge — missing any one, it is sentiment, not criteria.

[PoC success criteria — constructed example]
Goal      : cut agent document-search-to-first-response time by 40%
Measure   : search-to-first-response time over a 100-case sample, 2 weeks
Baseline  : current average 90s (agreed via 1 week of pre-measurement)
Judgment  : success at 54s or below; judge is the customer call-center ops lead
Failure   : if re-search rate exceeds 15%, ruled a failure regardless of speed
Next step : on success, scope and budget talks for pilot expansion within 4 weeks

The most valuable line here is the failure condition. A PoC with failure conditions written in advance leaves trust behind even when it fails, because everyone learned precisely what does not work. A PoC without them leaves suspicion behind even when it succeeds. And the last line — the promise of what happens on success — is what turns a PoC into a decision.

Security Review, Permissions, Data Boundary

The security review is not the final gate of a PoC; it is a week-one calendar item. Book 30 minutes with the customer's security team in the first week and agree on three things.

First, the data boundary. How far does customer data travel? Does it leave through an external API, and if so, which fields? What remains in logs? Is any of it used for model training? Draw the answers into a single diagram and agree on it, and most of the objections that would have arrived later get digested in advance. Second, permissions. PoC accounts are requested at least privilege, with an expiry date stamped on. The admin rights accepted for convenience become, in a later security audit, the exhibit that discounts the whole PoC. Third, agreement on the review timeline itself. Ask in week one which reviews a production transition requires and how many weeks they usually take, and the final-week surprise disappears.

The Debt Hiding Inside PoC Code

PoC code borrows deliberately in order to prove quickly. The problem is that the debt stays invisible while becoming the basis of a production decision. By the time transition is discussed, the debt list must be put on the table explicitly.

  • Credentials baked into config files — must migrate to a secrets-management system.
  • No error handling — code validated only on the happy path collapses at its first incident.
  • A single instance — restart, scaling, and deployment strategy are all undecided.
  • No monitoring — in production it can die with nobody noticing.
  • Bypassed auth — the SSO integration switched off during the PoC is often half of the transition work.

Raising this list in front of the customer first is FDE honesty, and simultaneously the basis of the transition estimate. It is also the answer to "the demo worked, so why does production take three months?" One caution: speak the debt list in the language of estimates, not threats. "Paying off these five items takes this many weeks" sounds to a customer like a plan rather than a cost, and the more concrete the list, the faster the transition budget gets approved.

The Handover Document — for the Day You Leave

The FDE success condition is peculiar: it only counts as success if it runs without you. If the system stops on the day the residency ends, what happened was a rental, not a deployment. That is why the handover document is built from mid-project, not in the final week.

[Handover document outline — constructed example]
1. System overview   — one architecture diagram and the data flow
2. Operations        — start, stop, deploy, backup, restore
3. Incident runbook  — the first 30 minutes for each frequent symptom
4. Access & contacts — account list, approvers, escalation path
5. Known limits      — what does not work, open issues, temporary fixes
6. Growth roadmap    — what was discussed as next steps, what was deferred

The document customers reopen most often is the incident runbook. It is for the same reason that the Handover role in the FDE Career RPG is designed to be playable only on missions that have a runbook: a system without one is a system that cannot be handed over. And on handover day, do not hand over only the document — completion is a rehearsal where a customer engineer works through one incident scenario by the runbook, hands on keys.

Practice by Doing

The feel of PoC operations is trained by decision-making under pressure.

  • FDE Career RPG — the Pre-sales PoC role must satisfy success criteria inside a time limit, and the Handover role only starts when a runbook exists. The two axes of this post, turned into game rules.
  • FDE Curriculum Roadmap — check the domains a transition depends on, security and data pipelines included, as a checklist.

FDE Complete Guide series