AI 프로젝트 PM이 만나는 여덟 개의 암초

모델과 인프라만 챙기다 놓치기 쉬운 데이터 준비의 여덟 함정을, 프로젝트 진행 순서를 따라 짚어 봅니다.

AI 프로젝트 킥오프 회의를 떠올려 보겠습니다. 어떤 모델을 쓸지, 파운데이션 모델을 그대로 가져올지 파인튜닝할지, GPU는 몇 장이나 확보해야 하는지를 두고 열띤 논의가 오갑니다. 화이트보드가 아키텍처 도식으로 빼곡히 채워질 무렵 누군가 조심스레 묻습니다. "그런데 학습 데이터는요?" 그러면 대개 이런 답이 돌아옵니다. "데이터야 사내에 쌓여 있으니 나중에 정리하면 됩니다." 회의는 다시 모델과 인프라 이야기로 돌아갑니다.

이 장면에는 항해의 비유가 잘 들어맞습니다. 좋은 배를 고르고 빠른 항로를 그리는 일은 물론 중요합니다. 해도가 틀렸거나 식수와 식량이 부실하면 아무리 훌륭한 배도 목적지에 닿지 못합니다. 그러니 많은 전문가들이 모여서 항해 준비에 열정을 쏟습니다.

그러나 AI 프로젝트에서 배를 멈춰 세우는 것은 대개 수면 위의 장비가 아닙니다. 수면 아래 보이지 않는 곳에 잠긴 것, 바로 데이터라는 암초입니다. 이번 글에서는 프로젝트를 지휘하는 PM의 시점에서, 항해 중 만나기 쉬운 대표적인 암초 여덟 개를 프로젝트 진행 순서대로 짚어 보겠습니다.

PM이 데이터에서 눈을 떼면 안 되는 이유

AI 프로젝트가 좌초하는 지점을 되짚어 보면 원인은 알고리즘의 정교함보다 데이터에 있는 경우가 훨씬 많습니다. 모델은 오픈소스와 상용 API로 상향평준화됐고 인프라도 클라우드로 손쉽게 빌리는 시대입니다. 남은 변수는 결국 "그 모델에 무엇을 먹일 것인가"입니다. 데이터가 부실하면 아무리 좋은 모델도 부실한 결과를 냅니다.

문제는 데이터 준비가 그저 데이터 팀만의 몫으로 넘겨진다는 점입니다. PM은 일정과 예산, 리스크를 관장하지만 데이터는 기술 이슈로 분류해 위임하기 쉽습니다. 그러나 데이터 준비가 어긋나는 순간 곧바로 일정 지연, 예산 초과, 결과물에 대한 신뢰 붕괴로 이어집니다. 다시 말해 데이터 준비는 기술 과제이기 이전에 프로젝트 관리 과제이고, 이 모든 것은 PM의 책임 영역입니다.

AI 프로젝트에서 데이터를 찾고 정제하고 다듬는 데 공수의 상당 부분이 쓰인다는 것은 익히 알려져 있습니다. 정확한 비율은 프로젝트마다 다르겠지만, 실제 현장에서는 데이터 확보와 정리에 예상보다 몇 배의 시간이 드는 경우를 자주 봅니다. 그러니 PM이 데이터에서 눈을 떼는 순간 프로젝트의 가장 큰 리스크를 방치하는 셈입니다.

암초 1 — "데이터는 있습니다"의 함정

가장 먼저 만나는 암초는 언어의 함정입니다. "데이터는 있습니다"라는 말과 "지금 이 프로젝트에서 접근하고 활용할 수 있습니다"라는 말 사이에는 매우 큰 간극이 있습니다. 데이터가 어딘가에 저장돼 있다는 사실은, 그것을 실제로 손에 쥘 수 있다는 뜻이 결코 아닙니다.

그 사이를 가로막는 장애물은 여러 겹입니다. 접근 권한이 다른 부서에 묶여 있거나, 개인정보·보안 등급 때문에 원본을 그대로 쓸 수 없거나, 데이터가 특정 팀의 소유물처럼 관리되어 반출 협의부터 필요할 수 있습니다. 물리적 위치가 폐쇄망 안이라 파이프라인을 새로 뚫어야 하거나 포맷이 분석에 맞지 않아 변환이 선행돼야 하는 경우도 흔합니다.

여기서 PM이 취할 처방은 분명합니다. 킥오프 직후 '데이터 확보 실사'를 별도의 액션 아이템으로 세워야 합니다. 존재 여부를 확인하는 데 그치지 말고 실제 접근 경로를 끝까지 밟아 봐야 합니다. 샘플 몇 건을 받아 보는 것과 운영 데이터 전량을 정기적으로 받아 오는 것은 전혀 다른 일이기 때문입니다. 이 점검을 초반에 마치면 착공한 뒤 "데이터를 아직 못 받아서 대기 중"이라는 지연 사고를 미리 막게 됩니다.

암초 2 — 지반조사 없이 착공하기

건물을 올리기 전에는 지반을 조사합니다. 땅속에 무엇이 있는지 모른 채 설계도를 그리고 기둥을 세우면 착공 후에 예상치 못한 암반이나 지하수를 만나 공사를 되돌려야 합니다. AI 프로젝트에서 이 지반조사에 해당하는 것이 데이터 프로파일링입니다.

두 번째 암초는 데이터의 실제 모습을 모른 채 설계부터 시작할 때 만납니다. 데이터의 양은 학습에 충분한지, 클래스 분포는 한쪽으로 심하게 쏠려 있지 않은지, 결측값과 이상치는 얼마나 되는지, 갱신 주기는 어떻게 되는지를 확인하지 않으면 이후의 모든 판단이 모래 위에 놓입니다. 특히 분포 편향은 모델 성능을 근본에서 좌우하는데도 늦게 발견되기 십상입니다.

전통적인 SI 프로젝트는 요건을 먼저 확정하고 개발로 넘어가는 순서가 자연스러웠습니다. AI 프로젝트는 다릅니다. 데이터를 먼저 확인해야 합니다. 데이터가 무엇을 할 수 있는지를 봐야 목표를 현실적으로 세울 수 있습니다. 따라서 PM은 초기 단계에 데이터 프로파일링을 필수 산출물로 넣어야 합니다. 규모가 작더라도 실제 운영 데이터로 해야 합니다. 잘 정돈된 예시 데이터만 보고 지반이 단단하다고 믿으면 나중에 이 암초를 다시 만나게 됩니다.

암초 3 — 정의 합의 없이 출항하기

세 번째 암초는 눈에 잘 띄지 않아 더 위험합니다. 같은 단어를 서로 다른 뜻으로 쓰는 일입니다. '고객', '매출', '이탈' 같은 익숙한 용어일수록 부서마다 정의가 미묘하게 다르고 그 차이가 라벨과 타깃 변수를 조용히 오염시킵니다.

가령 '활성 고객'을 세는 방법을 생각해 보겠습니다. 마케팅팀은 최근 30일 안에 한 번이라도 접속한 사용자를 활성으로 봅니다. 영업팀은 같은 기간에 실제 결제가 발생한 사용자만 활성으로 셉니다. 데이터팀은 로그인 없이 API 호출만 있어도 활성으로 집계합니다. 쿼리로 옮기면 WHERE last_login >= ...와 WHERE last_payment >= ...의 차이에 불과하지만, 이 한 줄이 만들어 내는 라벨은 서로 다른 모델을 낳습니다. 세 팀이 각자 '활성 고객 이탈 예측'을 만들면 세 개의 다른 진실이 생기는 셈입니다.

PM 입장에서는 데이터 표준사전을 합의하는 절차를 학습 데이터 확정 이전의 단계로 둬야 합니다. 핵심 지표와 용어의 정의를 문서로 확정하고 이해관계 부서의 확인을 받아야 합니다. 이 지점은 데이터 거버넌스가 왜 존재하는지를 잘 보여 줍니다. 데이터에 일관된 의미를 부여하는 일은 관료적 절차가 아니라, 여러 팀이 같은 배를 타고 같은 목적지를 향하게 만드는 항해의 기본입니다.

암초 4 — 품질을 막바지에 확인하는 습관

품질 점검을 뒤로 미루는 습관이 네 번째 암초입니다. 정합성이 맞지 않는 관계, 여기저기 뚫린 결측, 표준화되지 않은 코드값을 모델 학습 직전에야 발견하면 되돌리는 비용이 급격히 커집니다. 파이프라인 전체를 다시 손봐야 하고 이미 진행한 피처 엔지니어링도 재검토해야 하기 때문입니다.

코드값 불일치는 특히 흔한 골칫거리입니다. 같은 '완료' 상태를 어떤 테이블은 1로, 어떤 테이블은 Y로, 또 다른 테이블은 DONE으로 기록합니다. 하나의 STATUS 컬럼 안에 이 값들이 뒤섞여 있으면 모델은 같은 의미를 세 가지 다른 신호로 학습합니다. 사람 눈에는 뻔한 오류지만 대량 데이터 속에서는 모델의 성능을 갉아먹습니다.

해답은 품질 점검을 '개발이 끝난 뒤의 검수'에서 '파이프라인 위의 상시 게이트'로 앞당기는 것입니다. 데이터가 들어올 때마다 정합성과 코드값을 자동으로 검증하게 만들어 두면 문제를 값이 싼 초기에 잡아냅니다.

다만 균형이 필요합니다. 착공 전에 완벽한 품질을 요구하는 것은 과욕입니다. 세상에 흠 없는 데이터는 없습니다. 중요한 것은 이 프로젝트의 용도에 비추어 '충분한 품질'이 어디까지인지를 정의해 두는 일입니다.

암초 5 — 데이터 준비 공수에 대한 과소평가

다섯 번째 암초는 순수하게 PM의 고유 영역에서 벌어집니다. WBS(Work Breakdown Structure)와 간트 차트를 그릴 때, 앞에서 살펴본 그 많은 데이터 작업이 '데이터 준비'라는 한 줄로 뭉뚱그려집니다. 실사, 프로파일링, 정의 합의, 품질 점검, 변환과 적재가 모두 그 한 줄 안에 숨습니다.

이렇게 뭉뚱그려진 일정은 프로젝트 후반에 대가를 치릅니다. 데이터 작업은 눈에 보이지 않게 지연되다가 프로젝트 후반에 모델 학습과 겹치면서 일정을 한꺼번에 무너뜨립니다. 야근이 특정 시기에 몰리는 스파이크가 나타나는 것도 이 때문입니다.

데이터 준비는 독립된 워크스트림으로 분리하는 편이 낫습니다. 확보·정제·표준화·검증을 각각의 태스크로 쪼개 일정에 명시하고 불확실성이 큰 만큼 버퍼를 확보합니다. 여기에 데이터 담당자를 명시적으로 배정해 책임 소재를 분명히 합니다. 준비 과정을 일정 위에 드러내 놓는 것만으로도 후반의 일정 붕괴는 상당히 완화됩니다. 보이지 않는 일은 관리할 수 없기 때문입니다.

암초 6 — 관계와 맥락의 실종

데이터를 준비한다고 하면 흔히 넓은 테이블을 만들고 피처를 채워 넣는 작업을 떠올립니다. 여섯 번째 암초는 바로 여기에 숨어 있습니다. 조금 더 근본적인 문제입니다. 이렇게 납작하고 넓게 펴는 과정에서 데이터가 원래 품고 있던 관계와 맥락이 사라집니다.

현실의 데이터는 서로 얽혀 있습니다. 고객과 주문, 상품과 카테고리, 계좌와 거래는 각각 의미 있는 관계로 연결돼 있고 그 안에는 도메인 규칙이 녹아 있습니다. 이 관계와 규칙을 버리고 개별 컬럼만 나열하면 모델은 데이터를 얕게 학습합니다. 왜 이 값들이 함께 나타나는지, 어떤 조합이 도메인상 불가능한지를 알 수 없기 때문입니다.

PM은 데이터 모델과 관계 정의를 준비 산출물에 포함시키고 도메인 전문가 인터뷰를 일정에 넣어야 합니다. 최근 그래프DB와 온톨로지가 다시 주목받는 이유도 여기에 있습니다. 데이터 사이의 관계와 맥락이라는 '의미'를 구조로 담아내려는 시도이기 때문입니다. 이렇게 관계까지 정돈된 데이터는 모델이 개별 사실을 넘어 그 사실들이 놓인 지형까지 학습하도록 돕습니다.

암초 7 — 파일럿의 '깨끗한 데이터' 착시

일곱 번째 암초는 PM이 위험 신호를 성공 신호로 오독하게 만든다는 점에서 더욱 위험합니다. POC 단계에서는 잘 정제된 샘플로 모델을 돌립니다. 결과가 훌륭하게 나오고 회의실은 낙관으로 가득 찹니다. 그런데 막상 운영 데이터에 붙이면 성능이 무너집니다.

이유는 단순합니다. 파일럿에 쓴 데이터는 사람이 손으로 골라 다듬은, 현실에 없는 이상적인 데이터였기 때문입니다. 운영 환경의 데이터는 결측과 이상치, 형식 오류, 뒤늦게 도착하는 지연 데이터로 지저분합니다. 제한된 환경에서 순항하던 배가 실제 바다의 파도를 만나 휘청이는 셈입니다. 프로젝트 현장에서 이렇게 파일럿 성공에 취했다가 운영 이관에서 발이 묶이는 경우가 빈번합니다.

POC 단계부터 지저분한 실제 데이터를 의도적으로 일부 섞어야 합니다. 성공 기준 자체도 정제된 샘플이 아니라 운영 데이터 기준으로 세워야 합니다. 파일럿은 잘 되는 모습을 확인하는 자리가 아닙니다. 실제 항해에서 견딜 수 있는지를 가늠하는 자리입니다. 이 관점을 초기에 못 박아 두면 파일럿의 성공이 착시가 아니라 진짜 신호가 됩니다.

암초 8 — 리니지와 재현성 미확보

마지막 여덟 번째 암초는 프로젝트가 잘 굴러갈 때는 보이지 않다가 문제가 터지는 순간 수면 위로 떠오릅니다. 누군가 "이 예측 숫자는 어디서 나온 거죠?"라고 물었을 때, 데이터의 출처와 변환 이력을 대지 못하면 결과물 전체에 대한 신뢰가 흔들립니다.

이것은 데이터 흐름, 곧 리니지(lineage)의 문제입니다. 원본 데이터가 어디서 와서 어떤 변환을 거쳐 학습 데이터가 됐는지를 추적할 수 없다면 감사 요청에 대응할 수 없고 모델을 재학습하려 해도 같은 조건을 재현하지 못합니다. 규제 산업에서는 이것이 단순한 불편이 아니라 규정 위반이 될 수 있습니다. PM 입장에서 리니지는 거창한 아키텍처 이야기이기 전에, 프로젝트 위험 등록부에 반드시 올려야 할 항목입니다.

따라서 데이터 흐름을 기록으로 남기는 것을 프로젝트의 정식 산출물로 정의해야 합니다. 어떤 소스에서 어떤 변환을 거쳤는지를 남겨 두는 습관 하나가, 나중에 감사와 재학습, 책임 소명 상황에서 프로젝트를 지켜 줍니다.

여덟 암초를 게이트별 점검표로

여덟 개의 암초와 그에 대한 해결 방법을 단계별로 배치해 두면 실무에서 놓치지 않습니다. 각 단계를 넘어갈 때 해당 항목을 점검하고 산출물이 나왔는지 확인하는 방식입니다. 아래 표는 여덟 개의 암초를 프로젝트 진행 순서에 맞춰 재배열한 것입니다.

표를 채우는 것 자체가 목적은 아닙니다. 지금 진행 중인 프로젝트에 대입해 스스로 물어 보는 것이 핵심입니다.

• 우리 프로젝트의 학습 데이터를 지금 당장, 정식 경로로 받아 올 수 있습니까?
• '고객', '매출' 같은 핵심 용어의 정의를 관련 부서가 같은 뜻으로 쓰고 있습니까?
• WBS에서 데이터 준비가 한 줄로 뭉뚱그려져 있지는 않습니까?
• 파일럿의 성공 기준은 정제된 샘플입니까, 운영 데이터입니까?
• 결과 숫자의 출처와 변환 이력을 지금 설명할 수 있습니까?

이 중 답이 막히는 항목이 있다면 바로 그곳에 숨겨진 암초가 있습니다.

준비를 일회성 비용이 아니라 자산으로 남기기

암초를 피하는 데는 분명히 공수가 듭니다. 게다가 데이터 준비는 이번 프로젝트만을 위한 일회성 비용처럼 여겨지기 쉽습니다. 하지만 관점을 바꾸면 이야기가 달라집니다. 한 번 확인한 데이터 접근 경로, 한 번 합의한 정의 사전, 한 번 그려 둔 데이터 모델과 리니지 기록은 이 프로젝트가 끝나도 사라지지 않습니다.

그러나 여덟 암초를 하나씩 넘는 과정이 사실은 우리 조직의 데이터를 이 상태로 끌어올리는 과정이기도 합니다. 이번 항해에서 그린 해도는 다음 항해의 출발선이 됩니다. 두 번째 AI 프로젝트는 첫 번째보다 훨씬 빠르게 출항합니다.

물론 이것을 "처음부터 모든 데이터를 완벽하게 준비하자"로 읽으면 곤란합니다. 그것은 또 하나의 함정입니다. 끝없는 준비에 매달려 정작 출항하지 못하는 배도 목적지에 닿지 못하기는 마찬가지이기 때문입니다.

배를 멈추는 암초는 보이지 않는 수면 아래에 있습니다

처음의 킥오프 회의로 돌아가 보겠습니다. 그 자리에서 가장 뜨겁게 논의된 것은 모델과 GPU, 수면 위의 장비였습니다. 그러나 정작 배를 멈춰 세우는 것은 대개 수면 아래 잠긴 여덟 개의 암초, 데이터였습니다. 존재하지만 못 쓰는 데이터, 조사 없이 시작한 설계, 어긋난 정의, 미룬 품질 점검, 과소평가된 공수, 사라진 맥락, 파일럿의 착시, 그리고 추적할 수 없는 출처가 그것입니다.

데이터 준비는 데이터 팀에 넘길 기술 과제이기 전에, 일정과 리스크와 품질을 관리하는 PM 자신의 항해 계획입니다. 이번 항해를 무사히 마칠 만큼 충분히 준비됐는지를 용도에 비추어 판단하는 감각, 그것이 좋은 선장의 조건입니다. 그리고 그렇게 판단하며 정돈해 둔 데이터는 이번 항해로 끝나지 않습니다. 다음 항해에서 펼쳐 볼 해도로 남아 조직이 더 먼 바다로 나아가는 밑천이 됩니다.