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 완전 가이드 시리즈