AI VIDEO BRIEFING
맞춤형 AI 솔루션 개발 전 과정 — 요구사항 발굴, 2주 스프린트, 배포와 운영까지
50건 넘는 기업용 AI 프로젝트를 수행한 개발사 대표가 과제 발굴과 정확도 기대치 조율, 2주 스프린트 견적과 제안서 구성, 표준화된 파이썬 스택, 배포와 보안, 운영 중 모니터링까지 실제 작업 방식을 그대로 공개한다.

핵심 메시지
쉽게 이해하기
네덜란드에서 AI 개발사를 운영하는 데이브 에벨라르는 지난 2년간 50건이 넘는 기업용 맞춤 AI 프로젝트를 수행한 경험을 바탕으로, 고객 발굴부터 실제 배포까지의 전 과정을 공개했다. 그는 모델은 계속 좋아지는데도 대부분의 생성형 AI 파일럿이 측정 가능한 성과를 내지 못한다고 지적한다. 원인은 모델의 한계가 아니라 어떤 과제를 골랐고 어떻게 실행했는지에 있다는 것이 그의 진단이다.
첫 단계는 45분 정도의 발굴 상담이다. 이때 고객이 원한다고 말하는 것과 실제 문제를 구분하는 일이 가장 중요하다. 그는 LLM이 등장한 직후 고객이 이미 답을 정해 온 요구를 그대로 받았다가 범위가 지나치게 크거나 투자 대비 효과가 불분명해 어려움을 겪은 경험을 털어놓는다. 큰 문제 하나에 매달리기보다 직원의 업무를 하루만 따라가 보면 AI 없이 단순 자동화로 해결되는 숨은 반복 작업이 드러난다고 덧붙인다.
정확도에 대한 기대치 조율은 그가 가장 강조하는 부분이다. 첫 구현은 보통 70~80%, 반복 개선을 거치면 90% 수준에 도달하는데, 결정론적인 전통 소프트웨어에 익숙한 고객은 처음부터 99%를 기대하기 쉽다. 그래서 오류가 났을 때 사람이 이어받을 수 있는지, 실패를 판정할 기준이 있는지, 틀렸을 때 피해가 큰 업무인지를 먼저 따진다. 고객 문의 처리처럼 80%를 자동화하고 판단이 어려운 20%를 사람에게 넘기는 구조가 좋은 예다.
실행 방식은 2주 스프린트다. 첫 이틀은 프로젝트 골격과 아키텍처, 사흘째부터 여드레까지 핵심 개발과 품질 개선, 마지막 며칠은 테스트와 시연에 쓴다. 제안서에는 문제 정의, 해결 방안과 범위 경계, 포함되지 않는 항목, 성공 기준, 일정과 가격, 그리고 인프라·API 같은 운영 비용까지 적는다. 첫 결과물은 성능 달성 여부를 검증하는 개념 증명인지, 실제로 가치를 내는 최소 기능 제품인지 반드시 구분해 알린다.
기술 스택은 파이썬 기반으로 완전히 표준화되어 있다. FastAPI, Celery, PostgreSQL, Redis를 묶은 자체 백엔드 저장소를 프로젝트마다 그대로 복제해 쓰고, 폴더와 파일 구조까지 동일하게 유지한다. 배포는 컨테이너 이미지를 깃허브에서 CI/CD로 헤츠너 가상 서버에 내려 실행하고, 리버스 프록시로 도메인과 HTTPS를 붙인다. 기본적으로 모든 접속을 차단한 뒤 필요한 IP만 허용하며, LLM 호출 추적에는 랭퓨즈, 오류 감지에는 센트리를 붙여 문제가 생기면 슬랙으로 알림을 받는다.
주요 인사이트
- 표준화가 곧 속도다. 매 프로젝트를 같은 저장소 구조에서 시작하기 때문에 AI 코딩 도구가 엉뚱한 곳에 코드를 만들어도 즉시 알아채고 되돌릴 수 있다.
- 그는 인원을 늘려 회사를 키우는 대신 소수 인원과 AI 도구로 3년 전보다 5~10배의 산출을 낸다고 말한다. 사람을 채용해 규모를 키우는 구간에서는 수익이 줄고 스트레스가 급증한다는 것이 그의 경험이다.
- AI로 개발 속도가 빨라졌지만 가격은 그대로 유지하고, 대신 더 많은 프로젝트를 소화하고 더 많은 가치를 전달하는 방식을 택했다. 시간 단위 과금 관행이 아직 시장에 남아 있는 지금이 과도기라는 판단이다.
- 스프린트 사이의 공백이 현금 흐름의 최대 위험이다. 납품 후 고객사가 내부 검토에 들어가면 다음 스프린트까지 몇 주가 걸리므로, 다른 프로젝트를 미리 파이프라인에 두어 대비한다.
- AI는 매달 바뀌지만 프로세스와 핵심 스택은 바뀌지 않아야 한다. 실제로 운영 중인 고객 시스템은 모델만 교체하며 2년째 그대로 돌아가고 있다.
자주 묻는 질문
개념 증명(PoC)과 MVP는 어떻게 구분하나요?
개념 증명은 현재 AI 기술로 목표 지표를 달성할 수 있는지 확인하는 단계로, 보통 로컬 데모와 보고서가 결과물이며 그 자체로는 가치를 만들지 않습니다. 반면 MVP는 실제로 배포해 가치를 내는 최소 기능 제품을 목표로 합니다.
정확도 기대치는 어떻게 관리하나요?
첫 구현은 대체로 70~80%, 반복 개선 후 90% 수준이라는 점을 처음부터 명확히 알리고, 한 번에 완성하는 프로젝트가 아니라 반복 개발이라는 틀로 설명합니다. 고객이 피드백을 주기 쉬운 경로를 만들어 그 내용을 다시 개발에 반영합니다.
배포와 모니터링은 어떤 도구로 하나요?
깃허브에 올린 코드를 CI/CD로 헤츠너의 가상 서버에 내려 도커로 실행하고, 리버스 프록시로 도메인과 HTTPS를 붙입니다. 운영 단계에서는 랭퓨즈로 LLM 호출 과정을 추적하고 센트리로 오류를 잡아 슬랙 알림으로 받습니다.
어떤 유형의 프로젝트를 주로 맡나요?
문서 처리, 콘텐츠 생성, 고객 지원, 사내 지식 도우미, 데이터 추출의 다섯 가지 범주로 대부분 정리된다고 말합니다. 이 유형들이 지난 2년간 반복해서 들어온 요청이었습니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗