고객 중심 엔지니어링을 통한 AI 혁신 촉진

고객 백워드 엔지니어링(customer-back engineering)은 Amazon의 "Working Backwards" 방법론에서 영감을 받은 제품 개발 접근법으로, 기술 스택이나 기존 인프라에서 출발하는 전통적 방식과 정반대로 동작한다. 구체적으로는 PRFAQ(가상의 보도자료와 FAQ)를 먼저 작성해 고객이 실제로 마주할 문제와 그 해결 결과를 정의한 뒤, 이로부터 역산해 필요한 ML 모델·데이터 파이프라인·서빙 인프라를 설계한다. AI 영역에서 특히 중요한 이유는 LLM·RAG·에이전트 같은 화려한 기술 스택이 먼저 자리잡으면 "망치를 든 채 못을 찾는" 안티패턴에 빠지기 쉽기 때문이다. McKinsey가 지적한 "디지털 투자 가치의 1/3 미만 회수" 문제는 곧 PoC 단계에서 모델 정확도나 벤치마크 점수만 쫓다가 실사용 시 고객 워크플로우와 정합되지 않아 폐기되는 AI 프로젝트의 전형적 실패 패턴을 의미한다.

엔지니어 관점에서 이 방식은 아키텍처 의사결정의 우선순위를 근본적으로 뒤바꾼다. 예컨대 사내 문서 Q&A 시스템을 만들 때, "어떤 벡터 DB와 임베딩 모델을 쓸까"가 아니라 "고객이 답변을 5초 안에 받아야 하는가, 출처 인용이 필수인가, 오답 허용도는 얼마인가"를 먼저 정의한 뒤 거기서 SLO를 도출하고 그에 맞춰 retrieval 전략·재랭킹·캐싱 레이어를 거꾸로 설계하게 된다. 이는 마이크로서비스 분리 단위, 관측 가능성(observability) 메트릭 설계, A/B 테스트 인프라 구성에까지 영향을 미친다. 특히 AI 시스템은 결정론적이지 않기 때문에, 고객이 "신뢰할 수 없다"고 느끼는 경계가 어디인지를 사전에 정의해두지 않으면 모델 교체·프롬프트 튜닝·평가셋 구성 모두 방향성을 잃는다. 결과적으로 평가(eval) 체계가 단순한 정확도 지표가 아니라 고객 여정 단계별 만족도와 직결된 라이브 메트릭으로 재편된다.

한국 개발자들이 당장 적용할 수 있는 액션은 세 가지다. 첫째, 새로운 AI 기능을 기획할 때 Jira 티켓이나 기술 스펙 문서 대신 "출시 후 고객이 어떤 후기를 쓸지"를 1페이지 PRFAQ로 먼저 작성해 팀 내 정렬을 맞추는 것이다. 둘째, 평가 데이터셋을 모델 개발 후가 아니라 개발 전에 도메인 전문가 및 실제 사용자 인터뷰를 통해 구축하고, 이를 CI 파이프라인에 통합해 매 배포마다 회귀 테스트를 돌리는 구조를 만들어야 한다. 셋째, "기술적으로 가능한 것"과 "고객이 실제로 필요로 하는 것"을 분리해 트래킹하는 백로그 관리가 필요하다. 특히 LangChain·LlamaIndex 같은 프레임워크나 최신 모델을 도입하기 전에, 그것이 고객 문제의 어느 지점을 해결하는지 명시적으로 매핑하지 못한다면 도입을 보류하는 게 낫다. 결국 AI 시대의 엔지니어링 역량은 PyTorch 코드를 더 잘 짜는 능력보다, 고객의 모호한 니즈를 측정 가능한 시스템 요구사항으로 번역하는 능력에서 갈리게 된다.