Skip to content

Latest commit

 

History

History
713 lines (526 loc) · 27.3 KB

File metadata and controls

713 lines (526 loc) · 27.3 KB

바이브 코딩으로 딥러닝 연구하기

AI 코딩 어시스턴트(Claude Code)와 서버리스 인프라(AWS SageMaker Spot)를 활용하여, 최소한의 비용과 노력으로 딥러닝 최적화 가설을 수립하고 검증하는 실전 튜토리얼.

이 튜토리얼은 Topology-Efficient Deep Learning 프로젝트의 실제 수행 이력을 기반으로 작성되었습니다. 아이디어 메모 하나에서 시작해, 하루 만에 3개 트랙의 코드베이스를 생성하고, SageMaker Spot으로 실험을 수행하여 가설을 검증한 전 과정을 다룹니다. 총 비용은 $0.40이었습니다.


목차

  1. 이 튜토리얼의 대상
  2. 전체 워크플로우 개요
  3. Phase 1: 아이디어 → 문서 + 코드베이스
  4. Phase 2: 코드에서 사람이 검증할 것
  5. Phase 3: 실험 프로토콜 수립
  6. Phase 4: 서버리스 인프라 구축
  7. Phase 5: 실험 실행 및 결과 분석
  8. Phase 6: 개념 학습과 문서화
  9. 바이브 코딩의 리스크와 한계
  10. 핵심 교훈: 실패도 성과다
  11. 비용 요약
  12. 자신의 연구에 적용하기

1. 이 튜토리얼의 대상

  • 딥러닝에 관심은 있지만 연구 경험이 적은 개발자
  • 논문 아이디어를 빠르게 검증하고 싶은 주니어 연구자
  • GPU 서버 없이 실험하고 싶은 개인 연구자
  • AI 코딩 도구를 연구에 활용하고 싶은 실무자

전제 조건: Python 기본 문법, CLI 사용법, AWS 계정(프리티어 포함)


2. 전체 워크플로우 개요

graph LR
    A[아이디어 메모] -->|프롬프트 1| B[문서 + 코드베이스]
    B -->|사람| C[코드 검증]
    C -->|프롬프트 2| D[실험 프로토콜]
    D -->|프롬프트 3| E[서버리스 인프라]
    E -->|프롬프트 4| F[실험 실행]
    F -->|프롬프트 5| G[결과 분석 + 리뷰]
    G -->|프롬프트 6| H[학습 문서화]
Loading
Phase 소요 시간 산출물 인프라 비용
아이디어 → 문서 + 코드 ~1시간 PRD, README, 40개 파일 (3000+ LOC) -
코드 검증 ~30분 (사람이 직접 수행) -
실험 프로토콜 ~20분 protocol.md -
인프라 구축 ~30분 SageMaker/ECS 설정 -
실험 실행 ~2.5시간 23개 실험 결과 $0.40
결과 분석 ~30분 결과 리포트 + 과학적 리뷰 -
학습 문서화 수시 Q&A 문서 -

비용 참고: 위 표의 인프라 비용은 SageMaker Spot 사용료만 표시합니다. AI 코딩 어시스턴트(Claude Code 등) API 비용은 별도이며, 이 프로젝트에서는 측정하지 않았습니다. 사용량에 따라 다르지만, 이 규모의 프로젝트에서 $5-20 수준으로 추정됩니다.


3. Phase 1: 아이디어 → 문서 + 코드베이스

실제 이력: 이 프로젝트에서는 단일 프롬프트 하나로 PRD, README, configs, 전체 소스코드(40개 파일, 3000+ LOC)가 한 번에 생성되었습니다. Git 커밋 9f54619에서 확인할 수 있습니다.

3.1 시작점: 아이디어 메모 작성

모든 연구는 "이거 되지 않을까?"라는 질문에서 시작합니다. 이 프로젝트의 시작점은 ideation.md라는 아이디어 메모였습니다.

아이디어 메모에 포함해야 할 것:

# 제목: [연구 주제]

## 핵심 가설 한 문장으로 검증 가능한 형태로 작성

## 실험 트랙 (여러 접근법이 있다면)

  • Track A: [방법 1] → [도메인]
  • Track B: [방법 2] → [도메인]

## 각 트랙별:

  • 가설 (구체적, 정량적)
  • 대상 태스크
  • 데이터
  • 모델 구성 (Baseline vs Proposed)
  • 성공 기준 (숫자로!)
  • Ablation 변수

## 실행 우선순위 ## 기술 스택

핵심은 검증 가능한 성공 기준을 미리 정하는 것입니다:

성공 기준 (좋은 예)

  • 성능 하락 ≤ 1%p (F1) + 추론시간 ≥ 30% 절감
  • 또는 동일 추론시간에서 성능 +1~2%p 개선

성공 기준 (나쁜 예)

  • 성능이 좋으면 성공 ← 모호함
  • 기존보다 빠르면 성공 ← 얼마나?

3.2 프롬프트: 아이디어 → PRD + README

아이디어 메모가 준비되면, AI에게 구조화된 프로젝트 문서를 생성하게 합니다.

@ideation.md 을 사용해서 PRD와 리드미 문서를 만들어줘.

이 한 줄의 프롬프트로 AI가 생성한 것:

산출물 내용
PRD.md 7개 섹션의 상세 요구사항 (가설, 트랙별 설계, 공정 비교 조건, ablation, 로드맵, 리스크)
README.md 프로젝트 구조, 설치법, 사용법, 평가 지표, 성공 기준
CLAUDE.md AI 어시스턴트를 위한 프로젝트 가이드
configs/*.yaml 실험 설정 파일 3개 (base + 트랙별)
src/ TDA 파이프라인, 모델 코드, 유틸리티 (3000+ LOC)
experiments/ 실험 스크립트
.claude/commands/ Q&A 학습용 커스텀 명령어

바이브 코딩의 핵심: 사람은 "무엇을"에 집중하고, AI가 "어떻게"를 담당합니다. 아이디어 메모 224줄이 PRD 252줄 + README 285줄 + 코드 3000줄로 확장되었습니다.

3.3 핵심 포인트: CLAUDE.md

CLAUDE.md는 AI 어시스턴트가 프로젝트 맥락을 이해하도록 돕는 파일입니다. 이후 세션에서 AI가 이 파일을 자동으로 읽어 프로젝트 상태, 아키텍처, 실행 방법을 파악합니다.

CLAUDE.md 필수 포함 사항

프로젝트 개요

  • 핵심 가설 한 문장

빌드 및 실행

  • 정확한 명령어 (복사-붙여넣기 가능하게)

아키텍처

  • 트랙별 상태 (완료/진행중/미시작)
  • 데이터 흐름도
  • 핵심 모듈 경로

실험 설정

  • 모델 선택지, 하이퍼파라미터

인프라

  • 비용 최적화 지침 (Spot 필수 등)

4. Phase 2: 코드에서 사람이 검증할 것

AI가 코드를 생성했다고 끝이 아닙니다. 이 단계를 건너뛰면 실험 결과 전체가 무효화될 수 있습니다.

4.1 생성된 코드 구조 확인

Phase 1에서 생성된 코드:

src/
├── tda/                          # TDA 파이프라인
│   ├── embeddings.py             # Takens, sliding window
│   ├── persistence.py            # ripser/gudhi 백엔드
│   └── vectorization.py          # landscape/image/stats
├── models/
│   ├── tda/ph_mlp.py             # PH → MLP (제안 모델)
│   ├── baselines/                # CNN, GRU, TCN
│   ├── simplicial/               # Track B용
│   └── tensor/tt_linear.py       # Track C용
├── data/ucr.py                   # 데이터 로더
└── utils/metrics.py              # 성능 + 효율 지표

4.2 AI가 잘 만든 것: 코드에 실험 철학 반영

패턴 1: 모든 모델에 공통 인터페이스

# 모든 모델이 구현하는 메서드
model.count_parameters() → int

# TTLinear은 추가로
model.compression_ratio() → float

이렇게 하면 "파라미터 수 대비 성능" 같은 공정 비교가 자동화됩니다.

패턴 2: 효율 지표 자동 측정

# 모델 성능만이 아니라 효율까지 한 번에
final_metrics = compute_metrics(y_true, y_pred, y_prob)     # F1, AUROC
eff_metrics = compute_efficiency_metrics(model, input_shape)  # params, latency, throughput

패턴 3: 결과 자동 저장 구조

results/track_a/{dataset}/{dataset}_{model}_seed{seed}/
├── metrics.json          # 성능 + 효율 지표
├── training_log.json     # 에폭별 기록
└── model.pt              # 가중치

4.3 필수 검증 체크리스트

검증 항목 왜 중요한가
데이터 로딩이 올바른가 레이블 인코딩 오류는 실험 전체를 무효화
공정 비교 조건이 코드에 반영되었는가 같은 optimizer, 같은 epochs, 같은 early stopping
시드 고정이 제대로 되는가 재현 불가능한 실험은 의미 없음
지표 계산이 올바른가 macro F1 vs weighted F1 혼동 주의
하이퍼파라미터가 하드코딩되어 있지 않은가 최적화 없이 고정값을 쓰면 공정 비교가 아님

4.4 이 프로젝트에서 검증이 부족했던 것

실험 완료 후 과학적 리뷰(track_a_scientific_review.md)에서 드러난 문제들:

문제 원인 영향
Takens 파라미터 고정 (τ=5, d=3) AI가 생성한 기본값을 그대로 사용 최적화 없이 불리한 조건에서 비교
Vectorization 방법 고정 Landscape만 사용, Image/Stats 미비교 Ablation 부족으로 결론의 범위 제한
서브샘플링 300 포인트 고정 데이터셋별 적응적 설정 미적용 긴 시계열에서 정보 손실 가중

교훈: AI가 프로토콜에 Ablation을 포함시켰지만, 실제 실행 단계에서 기본 설정만으로 진행했습니다. 프로토콜에 적힌 것이 코드에도 반영되었는지 반드시 확인하세요.


5. Phase 3: 실험 프로토콜 수립

5.1 왜 프로토콜이 필요한가

코드가 있어도 "어떤 순서로, 어떤 조합으로 실험할 것인가"는 별도 문서가 필요합니다. 이 프로젝트에서는 대화를 통해 experiments/track_a/protocol.md를 생성했습니다.

프로토콜 핵심 구성:

실험 프로토콜 체크리스트

  1. 데이터셋 선정 기준 (왜 이 데이터셋인가)
  2. 베이스라인 선정 근거 (왜 InceptionTime인가)
  3. 제안 모델 상세 (파이프라인 각 단계)
  4. 공정 비교 조건 (동일 optimizer, LR, epochs)
  5. 측정 지표 (성능 + 효율 + 복합)
  6. 통계 검증 방법 (시드 3개, 평균±표준편차)
  7. Ablation 우선순위 (순차 진행)
  8. 실패 시 대응 (조건부 결론 도출)

5.2 데이터셋 선정 전략

적은 비용으로 의미 있는 결과를 얻으려면, 다양성을 우선합니다:

데이터셋 길이 클래스 선정 이유
ECG200 96 2 짧은 길이, 이진 분류
FordA 500 2 중간 길이, 노이즈
ElectricDevices 96 7 다중 클래스
Wafer 152 2 불균형 데이터
UWaveGestureLibraryAll 945 8 긴 길이, 다중 클래스

5개 데이터셋으로 길이(96945), 클래스 수(28), 도메인(의료, 센서, 제조, 모션)을 커버합니다.

5.3 실패 기준을 미리 정의하기

프로토콜에서 가장 중요한 부분:

실패 시 대응

Track A가 5/5 데이터셋에서 성공하지 못할 경우:

  • 성공한 데이터셋 특성 분석
  • 조건부 결론 도출 ("이런 조건에서 유효")
  • Track B/C 진행 여부는 결과 보고 후 결정

실패를 미리 계획하면, 실패 자체가 유의미한 결과가 됩니다.


6. Phase 4: 서버리스 인프라 구축

6.1 왜 SageMaker Spot인가

선택지 비용 장점 단점
로컬 GPU 하드웨어 비용 즉시 사용 초기 투자 큼
EC2 On-Demand $0.53/hr 유연함 비쌈
SageMaker Spot $0.16/hr 자동 체크포인트, 70% 절감 Spot 중단 가능
Colab 무료~$10/월 접근성 세션 제한, 재현성 낮음

이 프로젝트에서는 23개 실험을 $0.40에 완료했습니다.

6.2 인프라 코드 생성

대화를 통해 AI가 다음 인프라 코드를 생성했습니다:

infrastructure/
├── sagemaker/
│   ├── train_sagemaker.py    # SageMaker 학습 스크립트
│   ├── run_benchmark.py      # 벤치마크 실행 (dry-run 지원)
│   ├── run_remaining.py      # 남은 실험 재실행
│   └── requirements.txt
└── ecs/
    ├── Dockerfile            # CPU 학습용 컨테이너
    ├── build_and_push.sh     # ECR 푸시
    └── task-definition.json  # Fargate 태스크

6.3 SageMaker 사전 설정

인프라 코드를 실행하기 전에 AWS 설정이 필요합니다:

# 1. AWS CLI 프로필 설정
aws configure --profile personal
# → Access Key, Secret Key, Region (ap-northeast-2) 입력

# 2. SageMaker IAM Role 생성 (Trust: sagemaker.amazonaws.com)
# 필요 정책: AmazonSageMakerFullAccess + S3 접근 권한

# 3. Spot Instance 서비스 한도 확인
# AWS Console → Service Quotas → SageMaker → ml.g4dn.xlarge 확인
# 기본 한도가 0인 경우 증가 요청 필요 (보통 1-2일 소요)

# 4. 데이터 준비
python scripts/download_ucr.py --datasets ECG200 FordA ElectricDevices Wafer

상세 IAM 설정은 infrastructure/sagemaker/README.md 참조

6.4 Dry Run으로 비용 확인 후 실행

# 1단계: 비용 확인 (실제 실행 없음)
python infrastructure/sagemaker/run_benchmark.py --all --dry-run

# 출력 예시:
# 총 30개 실험 (5 데이터셋 × 2 모델 × 3 시드)
# 예상 Spot 비용: ~$2-5

# 2단계: 실제 실행
python infrastructure/sagemaker/run_benchmark.py \
    --all \
    --role arn:aws:iam::ACCOUNT:role/SageMakerRole

6.4 비용 최적화 원칙

이 프로젝트에서 확립된 원칙들:

  1. Spot 인스턴스 필수: On-Demand 대비 70% 절감
  2. Dry run 먼저: 항상 --dry-run으로 비용 확인 후 실행
  3. 가장 작은 인스턴스: ml.g4dn.xlarge ($0.16/hr Spot)로 충분
  4. 병렬 실행: 30개 실험을 동시에 돌리면 시간 1/30, 비용 동일
  5. 자동 체크포인트: Spot 중단 시 이어서 실행

7. Phase 5: 실험 실행 및 결과 분석

7.1 배치 실행

실행 환경에 따라 두 가지 방법이 있습니다:

# 로컬 실행 (기본: 5 데이터셋 × 4 모델 × 3 시드 = 60개)
python experiments/track_a/run_experiments.py --all

# SageMaker 실행 (5 데이터셋 × 2 모델 × 3 시드 = 30개)
# 이 프로젝트에서는 ph_mlp과 inceptiontime만 SageMaker에서 실행
python infrastructure/sagemaker/run_benchmark.py --all --role <ARN>

# 특정 조합만 (로컬)
python experiments/track_a/run_experiments.py \
    --datasets ECG200 FordA \
    --models ph_mlp inceptiontime

# Ablation 포함 (로컬)
python experiments/track_a/run_experiments.py --ablation

7.2 결과: 가설이 기각되다

Dataset PH-MLP (F1) InceptionTime (F1) 차이
ECG200 0.755 ± 0.008 0.839 ± 0.100 -8.4%p
FordA 0.641 ± 0.013 0.930 ± 0.034 -28.9%p
ElectricDevices 0.330 ± 0.017 0.652 ± 0.010 -32.2%p
Wafer 0.833 ± 0.016 0.963 ± 0.039 -13.0%p
UWaveGesture (타임아웃) - -

성공 기준 "≤1%p 하락"에 대해 8~32%p 하락. 가설 기각.

7.3 결과 분석 자동화

AI에게 결과를 분석하고 과학적 리뷰를 작성하도록 요청하면:

  • results/track_a_results.md: Raw 데이터 + 데이터셋별 분석 + 결론
  • results/track_a_scientific_review.md: 문헌 맥락 + 원인 분석 + 후속 연구 제안

AI가 자동으로 수행하는 분석:

  1. 문헌 대비 검증: "이 결과가 기존 연구와 일관되는가?"
  2. 실패 원인 분석: 정보 병목, 계산 비용, 다중 클래스 한계
  3. 조건부 결론: "짧은 시계열 + 이진 분류에서만 PH 접근이 유망"
  4. 후속 연구 방향: Ablation 확장, 하이브리드 접근, Track B/C 전환

7.4 실패를 문서화하는 방법

이 프로젝트의 과학적 리뷰에서 사용된 평가 프레임워크:

가설 검증 평가

기준 목표 결과 판정
효율 시나리오 ≤1%p 하락 + ≥30% 속도 개선 8~32%p 하락 기각
성능 시나리오 동일 속도에서 +1~2%p 전 데이터셋 하락 기각

가설 실패의 근본 원인 (문헌 기반)

  1. 가설의 전제 오류: PH는 "요약"이 아닌 "위상적 관점 변환"
  2. 도메인 불일치: PH는 형상 분석에 강점, 시계열은 시간적 패턴이 핵심
  3. 방법론적 미성숙: 시계열에 PH 단독 적용보다 하이브리드 권장

그럼에도 기여한 것

  1. UCR 데이터셋에서 PH-MLP vs InceptionTime 최초의 정량적 벤치마크
  2. "PH 단독으로는 시계열 분류에 부적합"이라는 결론의 정량적 근거
  3. 재현 가능한 코드 + 실험 환경 공개

8. Phase 6: 개념 학습과 문서화

8.1 Q&A 시스템으로 학습하기

이 프로젝트는 연구 과정에서 모르는 개념을 즉시 학습하고 기록하는 시스템을 포함합니다.

# 개념 질문 → AI가 설명 + 자동 저장
/qa Persistence Landscape가 뭐야?

# 저장된 Q&A 목록 확인
/qa-list topology

# 모든 Q&A를 하나의 개념 사전으로 병합
/qa-merge

AI가 생성하는 Q&A 문서의 구조:

Q: Persistence Landscape가 뭐야?

A: "데이터의 산맥 그리기"

쉬운 비유 [일상적 비유로 핵심 개념 설명]

작동 원리 [단계별 설명 + ASCII 다이어그램]

이 프로젝트에서의 역할 [프로젝트 맥락에서의 의미]

다른 방법과 비교 [대안과의 장단점 비교 표]

더 알고 싶다면 (수학적 정의) [엄밀한 수학적 정의]

참고문헌 [원논문 인용]

8.2 학습과 연구의 선순환

graph LR
    A[실험 설계] -->|모르는 개념 발견| B[/qa로 학습]
    B -->|이해 깊어짐| C[더 나은 실험 설계]
    C -->|결과 분석| D[새로운 질문 발생]
    D --> B
Loading

실제 프로젝트에서 생성된 Q&A 문서들:

  • persistence-landscape.md: Vectorization 방법 이해 → Ablation 설계 개선
  • 추가 가능: Takens embedding 원리, Homology 차수의 의미, 등

9. 바이브 코딩의 리스크와 한계

이 프로젝트 자체가 바이브 코딩의 리스크를 보여주는 사례이기도 합니다.

9.1 이 프로젝트에서 발생한 문제들

문제 상세 결과
프로토콜과 실행의 괴리 Ablation(Vectorization 3종, Homology 차수, Embedding 파라미터)을 프로토콜에 설계했으나 실제로는 기본 설정만 실행 과학적 리뷰에서 "Ablation 부족"으로 3/5점
하이퍼파라미터 고정 AI가 Takens embedding을 τ=5, d=3으로 하드코딩. 데이터셋별 최적화 없음 불리한 조건에서 비교하여 성능 격차 과대 추정 가능
하이브리드 접근 미탐구 프로토콜에 "Hybrid (optional): CNN → PH → MLP" 설계가 있었으나 미구현 문헌에서 권장하는 방법을 검증하지 못함
통계적 검정 미수행 프로토콜에 "Paired t-test, p < 0.05"를 명시했으나 실제 p-value 미보고 통계적 엄밀성 부족

9.2 바이브 코딩의 구조적 리스크

1. "코드가 있으니 된 것 같은" 착각

AI가 Ablation 코드(run_experiments.py --ablation)까지 생성했기 때문에, 실행만 하면 될 것 같은 느낌을 줍니다. 하지만 코드의 존재와 실제 실행은 다릅니다. 프로토콜에 적힌 실험이 실제로 수행되었는지 체크리스트로 관리하세요.

2. AI가 만든 기본값의 함정

AI는 합리적인 기본값을 설정하지만, 그것이 최적값은 아닙니다. 이 프로젝트에서 τ=5, d=3은 "일반적으로 쓰이는 값"이었을 뿐, ECG200과 FordA(길이 500)에 동일한 값을 쓰는 것은 부적절합니다.

3. 적용 범위의 과대 추정

이 프로젝트의 $0.40 비용은 **소규모 데이터셋(UCR) + 경량 모델(MLP, InceptionTime)**이었기 때문입니다. 다음 경우 비용이 급증합니다:

시나리오 예상 비용
UCR 5개 × 경량 모델 2개 (이 프로젝트) ~$0.40
ImageNet subset × ResNet50 ~$10-50
전체 ImageNet × ViT-Large ~$100-500
LLM fine-tuning ~$500-5000

9.3 리스크 완화 체크리스트

  • 프로토콜의 모든 실험이 실제로 실행되었는가?
  • AI가 설정한 기본값이 데이터셋별로 적절한가?
  • 통계적 검정(t-test, p-value)이 수행되었는가?
  • 결론이 실험 범위를 넘어서 일반화하고 있지 않은가?
  • 비용 추정이 자신의 실험 규모에 맞는가?

10. 핵심 교훈: 실패도 성과다

10.1 이 프로젝트가 증명한 것

항목 전통적 방식 바이브 코딩 방식
코드베이스 구축 1-2주 ~1시간
인프라 설정 수일 ~30분
실험 비용 GPU 서버 유지비 $0.40
전체 소요 시간 수주 ~1일
가설 검증 완료 느림 빠른 실패, 빠른 학습

10.2 "부정적 결과"의 가치

이 프로젝트의 Track A는 가설이 기각되었습니다. 하지만:

  1. 최초의 정량적 벤치마크: UCR에서 PH-MLP vs InceptionTime 비교는 문헌에 없었음
  2. 조건부 결론: "짧은 시계열 + 이진 분류에서만 유망"이라는 방향 제시
  3. 재현 가능성: 코드, 데이터, 환경이 모두 공개되어 누구나 재현 가능
  4. 비용 효율성: $0.40으로 의미 있는 과학적 결론 도출

10.3 빠른 실패가 주는 이점

전통적 접근:
  2주 코딩 → 1주 실험 → 실패 발견 → 3주 낭비

바이브 코딩 접근:
  1시간 코딩 → 2시간 실험 → 실패 발견 → 즉시 Track B/C로 전환

11. 비용 요약

실제 발생 비용

항목 비용
완료된 실험 23개
중단된 실험 (타임아웃) 1개
총 Billable 시간 ~2.5시간
SageMaker Spot 비용 ~$0.40
인스턴스 타입 ml.g4dn.xlarge (T4 GPU)
시간당 비용 ~$0.16 (Spot)

비용 비교

방식 동일 실험 예상 비용
SageMaker On-Demand ~$1.30
EC2 On-Demand + 수동 관리 ~$1.30 + 관리 시간
SageMaker Spot ~$0.40
Colab Pro $10/월 (세션 제한 있음)
로컬 GPU (RTX 3090) 전기세 ~$0.10 + 하드웨어 감가

12. 자신의 연구에 적용하기

12.1 프롬프트 레시피

참고: Step 1과 Step 2는 실제 사용된 프롬프트입니다. Step 3~7은 대화 세션 로그가 남아있지 않아, 산출물(protocol.md, SageMaker 코드, 결과 리포트 등)에서 역추론하여 재구성한 것입니다. 실제 대화는 더 많은 반복과 수정을 포함했을 수 있습니다.

Step 1: 아이디어 → 프로젝트 구조화

@ideation.md 을 사용해서 PRD와 리드미 문서를 만들어줘.

ideation.md에 가설, 데이터, 모델, 성공 기준을 미리 작성해두세요.

Step 2: GitHub 프로젝트 등록

이 프로젝트를 github [org-name] org 에 등록해줘.

Step 3: 실험 프로토콜 작성

Track A의 실험 프로토콜을 작성해줘.
데이터셋 선정 기준, 베이스라인 근거, 공정 비교 조건,
통계 검증 방법, ablation 설계, 실패 시 대응을 포함해서.

Step 4: 서버리스 인프라 구축

SageMaker Managed Spot Training으로 이 실험을 실행할 수 있게
인프라 코드를 만들어줘. dry-run 지원, 비용 추정 포함.

Step 5: 실험 실행 + 결과 분석

Track A 전체 실험을 실행하고 결과를 분석해줘.
성공 기준 대비 결과, 데이터셋별 분석, 원인 분석, 후속 연구 방향을 포함해서.

Step 6: 과학적 리뷰

Track A 결과를 과학적으로 리뷰해줘.
문헌 맥락, 방법론 강점/한계, 가설 검증 평가, 기여점, 후속 연구 권장사항을 포함해서.

Step 7: 개념 학습

/qa [모르는 개념]

12.2 체크리스트: 시작 전 준비

  • 아이디어 메모 (ideation.md) 작성
    • 검증 가능한 가설 (정량적 성공 기준 포함)
    • 데이터셋 후보 (최소 3개, 다양성 확보)
    • 베이스라인 모델 선정 근거
    • 실패 시 대응 계획
  • AWS 계정 설정
    • SageMaker IAM Role 생성
    • S3 버킷 확인
    • Spot Instance 한도 확인
  • 로컬 환경
    • Python 3.10+, pip
    • AWS CLI 설정 (aws configure)
    • Claude Code 또는 유사 AI 코딩 도구

12.3 다른 연구 주제 예시

이 워크플로우는 딥러닝 최적화 외에도 다양한 연구에 적용 가능합니다:

연구 주제 가설 예시 베이스라인
Knowledge Distillation 작은 모델이 큰 모델의 90% 성능 달성 원본 모델
Data Augmentation 특정 augmentation이 F1 +2%p Augmentation 없음
Architecture Search 자동 탐색 모델이 수동 설계 대비 효율적 수동 설계 모델
Pruning/Quantization 50% 압축에서 성능 유지 원본 모델
Self-Supervised Learning 라벨 10%로 풀 라벨의 95% 성능 풀 라벨 학습

12.4 확장: 여러 가설을 저비용으로 탐색하기

이 프로젝트의 교훈을 일반화하면:

반복:
  1. 아이디어 메모 작성 (30분)
  2. AI로 코드베이스 생성 (1시간)
  3. SageMaker Spot으로 실험 ($1-5)
  4. 결과 분석 + 가설 검증 (30분)
  5. 실패 → 조건부 결론 기록 → 다음 가설로
     성공 → 확장 실험 → 논문화

소규모 데이터셋 + 경량 모델 조건에서 한 달에 5-10개 가설을 $10-50에 검증할 수 있습니다. 단, 이 비용은 UCR 같은 작은 데이터셋과 MLP/InceptionTime 수준의 모델을 전제로 합니다. ImageNet 규모나 Transformer 기반 실험은 9.2절의 비용 표를 참고하세요.


부록: 프로젝트 타임라인

이 프로젝트의 실제 git 커밋 이력:

시각 커밋 내용
01/18 15:13 9f54619 Initial commit: 40개 파일, 3000+ LOC
01/18 ~16:00 (세션 2) GitHub 등록
01/18 17:05~01/19 07:34 (세션 3) Track A 실험 실행, SageMaker 설정, 결과 분석
01/19 08:12 ec2df1d Track A 실험 완료: 23개 실험, 가설 기각
01/19 08:15 c075618 AWS 인프라 가이드라인 추가
01/19 09:34 6ae781b Dockerfile, Q&A 문서, SageMaker 이력
01/19 ~10:00 156fb05 Q&A 문서 재작성

아이디어에서 가설 검증까지 약 18시간 (대부분 SageMaker 실험 대기 시간).


참고 자료