6장 - AI 프로젝트 전략

6장. AI 프로젝트 전략

알고리즘을 이해하는 것도 중요하지만, 진정으로 성능을 끌어올리는 것은 팀의 효율적인 개발 프로세스다. 하이퍼파라미터는 어떻게 조정하고, 데이터는 어떻게 수집하며, 처음 시도가 실패했을 때 다음에 무엇을 하는가 — 이 의사결정 능력이 생산성에서 문자 그대로 10배 차이를 만든다. — Andrew Ng

6.1 속도가 곧 경쟁력이다

Andrew Ng은 유명 기업의 좋은 팀이 1년 걸린 프로젝트를, 더 숙련된 팀이 한 달 만에 완수하는 것을 여러 번 목격했다고 한다. ML 프로젝트에서 이 차이는 과장이 아니다.

보통 2년마다 하나의 프로젝트를 경험하므로, 10년이 지나야 겨우 10개의 프로젝트 경험이 쌓인다. 이 강의는 실제 프로젝트와 유사한 단순화된 예시를 여러 개 빠르게 경험하게 하여, 그 학습 곡선을 가속하는 것이 목표다.

2배 느리면 얼마나 손해인가

경쟁자가 매번 내가 1일 걸리는 작업에 2일을 쓴다면:

성능 ↑
│    ● 우리 팀
│   ╱
│  ╱     ● 경쟁자
│ ╱     ╱
│╱     ╱
└──────────── 시간 →

같은 시점에 성능 격차가 크다. 고객이 보는 것은 "그 시점의 성능"이다. 2배 속도 차이는 하루 차이가 아니라, 시장에서의 압도적 성능 우위로 번역된다.

6.2 사례 1: 음성 기반 스마트 램프 — "Robert, turn on"

제품 개요

Wi-Fi 연결이나 스마트폰 설정 없이, 전원만 꽂으면 음성으로 제어할 수 있는 램프를 만든다. 사용자는 "Robert, turn on"이라고 말하면 램프가 켜진다. 소형 IC 칩 위에서 동작해야 한다.

접근 순서

어떤 아키텍처를 선택하든, 가장 중요한 것은 빠르게 무언가를 만들어보는 것이다.

문헌 조사: 웨이크 워드(wake word) / 트리거 워드(trigger word) 탐지에 대한 논문, 블로그, 오픈소스 검색
핵심 발견: 범용 음성 인식은 에지 디바이스에 무겁지만, 단일 구문 탐지는 작은 신경망으로 가능
데이터 수집: 인터넷에 "Robert, turn on"을 말하는 데이터셋은 없다 — 직접 수집해야 한다

문헌 조사 팁

논문 읽기의 효율적인 방법:

비효율적: 논문 1을 처음부터 끝까지 → 논문 2를 처음부터 끝까지 → ...
효율적: 여러 논문/블로그/레포를 빠르게 훑어보고(skim) → 가장 중요한 것만 깊이 읽기 → 추가 참고 문헌 발견 → 반복

완전히 읽는 자료는 소수에 불과하다. 넓게 훑어보는 것이 핵심이다.

전문가에게 물어라

자신의 작업을 먼저 한 후, 논문 저자나 관련 교수에게 정중한 이메일을 보내면 10분짜리 대화가 몇 주의 삽질을 절약해준다. 많은 연구자들은 당신이 스스로 노력한 흔적을 보면 기꺼이 도와준다.

데이터 수집

캠퍼스를 돌며 사람들에게 허락을 구하고 "Robert, turn on"을 녹음한다. 하루 만에 수십~수백 개의 샘플을 모을 수 있다. 프라이버시와 동의는 필수다.

합성 데이터(TTS)는 효과가 있지만, 보통 첫 번째로 시도할 데이터 소스는 아니다. 이유:

음성 다양성이 제한적이다 (몇 가지 목소리만 지원)
조정할 하이퍼파라미터가 너무 많다
합성 데이터의 편향을 알기 어렵다

자율 주행 분야에서 비디오 게임 속 차량 이미지를 사용하려 했으나, 대부분의 게임에는 단 20종의 차량만 존재했다. 실제 세계의 풍부함에 비하면 턱없이 부족하다.

6.3 데이터 불균형과 해결

문제 발생

100개의 오디오 클립에서 3초 윈도우를 잘라 3,000개의 이진 분류 훈련 데이터를 만들었다. 훈련 결과 97% 정확도 — 하지만 항상 0을 출력하고 있었다. print(0)과 동일한 거대 신경망이다.

양성 예제 대 음성 예제의 비율이 약 1:30으로 심하게 불균형하다.

경험적 기준

불균형 비율	대응
1:2 ~ 1:10	대부분의 신경망이 잘 처리한다
1:10 이상	균형 조정이 필요하다

해결 방법들

양성 예제 복제(duplication): 가장 단순하고 효과적
양성 예제에 높은 가중치 부여: 손실 함수에서 양성 오류에 더 큰 패널티
음성 예제 축소: 가능하지만, 음성 데이터의 다양성이 줄어드는 부작용
양성 구간 확장: "Robert, turn on"이 끝난 직후 100ms → 500ms~1초로 확장. 양성 예제의 다양성이 증가 (실제로 사용한 방법)

6.4 과적합과 합성 데이터

훈련 95% / 개발 30% — 과적합

불균형 문제를 해결한 후 새로운 문제가 등장한다. 훈련 세트에서는 잘 작동하지만 개발 세트에서 성능이 떨어진다. 전형적인 **과적합(overfitting)**이다.

오디오 합성 데이터의 핵심 기법

소리는 **중첩 원리(superposition property)**를 따른다. 두 오디오 파형을 더하면, 두 소리가 동시에 나는 것처럼 들린다.

배경 소음 (커피숍, 에어컨, 고속도로 등)
+ 깨끗한 음성 "Robert, turn on"
= 배경 소음 속에서 "Robert, turn on"을 말하는 양성 예제

주의할 점: - 양성 음성만 합성하면 음성 활동 탐지기(VAD)가 된다 — 어떤 소리든 있으면 양성이므로, "Robert, turn on"이 아니라 "아무 말"을 탐지하게 된다 - 해결: "cardinal", "weather" 같은 다른 단어의 깨끗한 녹음도 합성하여 음성 예제를 풍부하게 만든다

훈련 vs 테스트 분포 불일치

학계에서는 훈련 세트와 테스트 세트의 분포가 같다고 가정한다 (이론이 깔끔해지므로). 하지만 실무에서는 거의 항상 다르다.

훈련 세트: 합성 데이터, 다양한 소스에서 수집
테스트 세트: 실제 사용자의 자연스러운 데이터

테스트 메트릭이 사용자 경험을 정확히 반영하려면, 테스트 세트에는 실제 데이터를 넣어야 한다.

테스트 세트 없이 개발하기

상용 시스템을 빠르게 만드는 것이 목표라면, 테스트 세트 없이 훈련 세트 + 개발 세트만으로 진행할 수 있다. 개발 세트에 직접 튜닝하는 것이다. 논문을 쓰려면 편향 없는 테스트 세트가 필요하지만, 제품 출시가 목표라면 이 트레이드오프를 의식적으로 선택할 수 있다.

6.5 ML 개발의 디버깅 사이클

ML 프로젝트는 소프트웨어 개발보다 디버깅에 가깝다. 전통적인 소프트웨어는 스펙을 짜고 구현하면 대체로 동작하지만, ML은 "다음에 무엇이 잘못될지 예측할 수 없다."

이상적인 일일 리듬

밤:    훈련 작업 실행 (4시간)
아침:  결과 확인, 오류 분석
오후:  코드 수정, 데이터 수집
저녁:  새 훈련 작업 실행 → 반복

하루에 하나의 문제를 해결할 수 있다면 매우 좋은 속도다. 이 리듬을 유지하는 훈련된 팀과, "뭘 할지 회의하고, 인프라가 다운되고, 내일 데이터를 보자"는 팀의 차이는 극적이다.

훈련 시간에 따른 리듬 변화

훈련 시간	워크플로우
10분	훈련 → 커피 → 결과 확인 → 수정 → 반복. 병목은 분석 속도
4시간	밤에 훈련, 아침에 분석. 하루 1사이클
3주	체크포인트를 모니터링하며 병렬로 여러 작업 실행. 며칠 후 학습률이 명백히 잘못되면 중단 가능
1.5개월	대형 모델 훈련. 이전 작업 분석과 다음 작업 준비를 병렬로 진행

프로젝트가 성장하면서 데이터와 모델이 커지면, 반복 주기가 10분 → 4시간 → 3주로 늘어나는 경험을 하게 된다.

6.6 사례 2: AI 딥 리서처 파이프라인

파이프라인 아키텍처

단일 신경망이 아닌 **여러 단계의 파이프라인(pipeline)**으로 구성된 시스템이다.

사용자 쿼리
    → [LLM] 검색어 생성
    → [웹 검색 엔진] 결과 반환
    → [LLM] 상위 페이지 선별 및 가져오기
    → [LLM] 보고서 작성
    → 최종 출력

초기 딥 리서처는 이러한 선형 파이프라인이었고, 현대의 에이전틱(agentic) 아키텍처는 자율적으로 추가 검색을 수행하고 반복하는 루프를 가진다.

어디에 집중할 것인가

파이프라인 시스템에서는 여러 구성 요소 중 어떤 것을 개선해야 하는지 결정하는 능력이 핵심이다. 가능한 문제점:

구성 요소	잠재적 문제
검색어 생성	쿼리 의도를 제대로 반영하지 못하는 검색어
웹 검색 엔진	최신 콘텐츠 부족, 특정 도메인에 약함
페이지 선별	nasa.gov 대신 bobsbackyardastronomyblog.com을 선택
보고서 작성	정보는 있는데 잘 정리하지 못함

흥미로운 관찰: 경험 많은 ML 전문가들에게 동일한 시스템을 보여주면, "다음에 무엇을 해야 하는가"에 대한 의견의 분산이 놀라울 만큼 작다. 체계적인 방법론이 존재한다는 증거다. 반면 경험이 적은 엔지니어들의 의견은 분산이 훨씬 크다.

6.7 오류 분석 (Error Analysis)

방법론

오류 분석은 AI가 인간보다 못하는 지점을 찾아 그 격차를 좁히는 수작업 프로세스다.

10~100개의 성능이 떨어지는 쿼리를 수집한다
스프레드시트에 쿼리별로 각 파이프라인 단계의 출력을 기록한다
각 단계에서 "인간이라면 다르게 했을 것"인 지점을 표시한다
문제가 집중되는 단계의 비율을 집계한다

예시

쿼리	검색어	웹 검색	페이지 선별	작성
블랙홀 최신 연구	OK	OK	bobsblog 선택 (NASA 누락)	OK
샌프란시스코 매매 vs 임대	OK	특정 블로거 누락	OK	OK
산타크루즈 주말 활동	OK	OK	관광 상업 사이트만 선택	OK

이 분석을 50개 쿼리에 대해 수행한 결과:

검색어 생성 문제: 20%
웹 검색 문제: 5%
페이지 선별 문제: 70%
작성 문제: 20%

(합이 100%를 넘을 수 있다 — 하나의 쿼리에서 여러 단계에 문제가 있을 수 있으므로)

결론: 페이지 선별에 집중해야 한다. 웹 검색 엔진을 바꾸는 데 6개월을 쓰면 전체 성능에 거의 영향이 없다.

오류 분석의 가치

3~4시간의 오류 분석이 잘못된 방향으로 가는 수 주를 절약한다. 이 과정을 당장은 하겠다고 동의하면서도, 실제로 하는 팀의 비율은 100%보다 훨씬 낮다. 이 수작업 프로세스를 체계적으로 수행하는 팀이 비약적으로 더 빠르게 성과를 내며, 그 차이는 2배가 아니라 10배 이상이다.

6.8 핵심 정리

원칙	설명
속도 우선	완벽한 아키텍처보다 빠르게 동작하는 프로토타입이 중요하다
문헌 조사 효율화	넓게 훑고 좁게 깊이 읽기. 전문가에게 묻기
실제 데이터 먼저	합성 데이터는 효과적이지만, 첫 번째 선택이 아니다
불균형 데이터	1:10까지는 보통 괜찮다. 그 이상이면 복제, 가중치, 구간 확장 등으로 대응
디버깅 사이클	밤에 훈련, 아침에 분석, 오후에 수정. 하루 한 문제 해결
오류 분석	스프레드시트로 파이프라인 각 단계를 수작업 검토. 3시간이 수 주를 절약
훈련/테스트 분포	실무에서는 거의 항상 다르다. 테스트 세트에는 실제 데이터를 넣는다

핵심 메시지: ML 프로젝트의 성공은 알고리즘 선택이 아니라, 체계적인 반복 프로세스의 규율에 달려 있다.

이전 장: 5장 - 심층 강화 학습 다음 장: 8장 - 에이전트, 프롬프트, RAG