TinyExperiment

Context

복잡한 소프트웨어 문제를 해결하거나 새로운 기능을 구현할 때, 또는 버그를 추적할 때. 불확실성이 높고 여러 가능성이 존재하는 상황에서 어떻게 접근해야 할지 막막할 때.

Problem

큰 변경의 함정

주니어 개발자들이 자주 빠지는 함정이 있다. "이 기능을 구현하려면 A도 바꾸고, B도 수정하고, C도 새로 만들어야 해"라고 생각하며 한 번에 많은 것을 바꾸려 한다.

결과는 참혹하다. 2시간 후 코드는 엉망이 되고, 어디서 문제가 생겼는지 알 수 없다. 원래 상태로 되돌리기도 어렵다. 머릿속 추측만으로는 복잡한 시스템의 동작을 정확히 예측할 수 없고, 긴 피드백 루프는 학습을 늦추며 잘못된 방향으로 오래 가게 만든다.

요리사의 실수

경험 없는 요리사가 새로운 요리를 만들 때를 생각해보자. 레시피를 보고 "설탕 대신 꿀을 넣고, 소금도 줄이고, 향신료도 바꿔보자"며 한 번에 여러 변경을 시도한다. 결과적으로 맛없는 요리가 나오지만, 무엇 때문에 실패했는지 알 수 없다. 설탕 때문인가? 소금 때문인가? 향신료 때문인가?

Solution

작은 실험의 힘

아주 작은 가설을 세우고 빠르게 검증할 수 있는 환경을 만들어라. 마치 과학자가 실험실에서 하나의 변수만 바꿔가며 실험하는 것처럼.

1단계: 명확한 가설 세우기

막연한 "아마 이럴 것이다"가 아니라 구체적인 가설을 세워라.

나쁜 예: "이 코드가 느린 것 같다" 좋은 예: "이 반복문에서 데이터베이스 조회가 N번 발생해서 느릴 것이다"

2단계: 최소 실험 설계

가설을 검증할 수 있는 가장 작은 실험을 만들어라.

예시: 데이터베이스 조회 가설을 검증하려면 - 로그를 추가해서 실제 쿼리 횟수 확인 - 작은 데이터셋으로 테스트 - 쿼리 실행 시간 측정

3단계: 안전망 구축

실패해도 쉽게 되돌아갈 수 있는 안전망을 준비하라.

- git commit으로 현재 상태 저장 - 브랜치 생성해서 실험 - 테스트 코드로 기존 기능 보호 - 백업 데이터 준비

4단계: 빠른 피드백 루프

결과를 즉시 확인할 수 있는 환경을 만들어라.

- 자동화된 테스트 실행 - 핫 리로드 개발 환경 - 실시간 로그 모니터링 - 간단한 확인 스크립트

5단계: 격리된 환경

다른 요소들의 영향을 받지 않도록 격리하라.

- 테스트용 데이터베이스 사용 - 모의 객체(mock)로 외부 의존성 제거 - 개발 전용 환경에서 실험 - 한 번에 하나의 변수만 변경

6단계: 가추법 활용

관찰된 현상에서 가능한 원인을 추론하고 다시 검증하라.

현상: "API 응답이 느리다" 가능한 원인들: - 데이터베이스 쿼리가 느림 → 쿼리 실행 계획 확인 - 네트워크 지연 → 로컬 테스트로 비교 - 메모리 부족 → 메모리 사용량 모니터링

Detailed Examples

예시 1: 새로운 기능 구현

상황: 사용자 프로필 페이지에 '좋아요' 기능 추가

잘못된 접근: - 데이터베이스 스키마 변경 - API 엔드포인트 추가 - 프론트엔드 UI 구현 - 알림 기능 추가 - 권한 검증 로직 추가 모든 것을 한 번에 구현 → 3일 후 동작하지 않음

TinyExperiment 접근: 1. 가설: "좋아요 데이터를 저장할 수 있다"

• - 임시 테이블 생성 - 간단한 INSERT/SELECT 쿼리 테스트 - 5분 만에 검증 완료

2. 가설: "API로 좋아요 데이터를 주고받을 수 있다"

• - 기본적인 POST/GET 엔드포인트만 구현 - Postman으로 테스트 - 10분 만에 검증 완료

3. 가설: "프론트엔드에서 API를 호출할 수 있다"

• - 단순한 버튼과 AJAX 호출만 구현 - UI는 나중에 다듬기 - 15분 만에 검증 완료

각 단계가 성공한 후 다음 단계로 진행. 실패하면 원인을 정확히 알 수 있음.

예시 2: 버그 디버깅

상황: "로그인 후 대시보드가 가끔 안 보인다"는 신고

잘못된 접근: 코드를 훑어보며 "아마 세션 문제일 것이다" 추측하고 세션 관련 코드를 모두 수정

TinyExperiment 접근: 1. 가설: "재현 가능한 조건이 있다"

• - 다양한 브라우저, 사용자로 테스트 - 재현 조건 발견: "IE에서만 발생"

2. 가설: "특정 브라우저의 문제다"

• - 콘솔 로그 확인 - 네트워크 탭에서 요청 확인

  - JavaScript 오류 발견

3. 가설: "이 JavaScript 오류가 원인이다"

• - console.log 추가해서 실행 경로 추적 - 특정 함수에서 오류 발생 확인

4. 가설: "이 함수의 이 부분이 문제다"

• - 최소한의 수정으로 오류 해결 - 테스트로 검증

예시 3: 성능 개선

상황: "페이지 로딩이 너무 느려요"

TinyExperiment 접근: 1. 측정부터: 브라우저 개발자 도구로 정확한 로딩 시간 확인 2. 가설 1: "이미지가 너무 크다" → 이미지 최적화 후 측정 3. 가설 2: "JavaScript 파일이 크다" → 번들 크기 분석 4. 가설 3: "데이터베이스 쿼리가 느리다" → 쿼리 실행 시간 측정

각 개선 후 실제 측정치로 효과 확인.

요리사의 지혜 (은유)

훌륭한 요리사는 새로운 요리를 개발할 때 이렇게 한다:

1. 기본 레시피로 시작 - 검증된 방법부터 2. 한 번에 하나만 바꾸기 - 설탕량만 조정, 다른 것은 그대로 3. 맛을 보며 조정 - 변경 후 즉시 결과 확인 4. 기록 남기기 - 무엇을 바꿨는지, 결과가 어땠는지 5. 실패해도 괜찮은 환경 - 작은 양으로 실험, 큰 파티 음식은 나중에

프로그래밍도 마찬가지다. 경험 많은 개발자는 작은 실험을 통해 점진적으로 시스템을 이해하고 개선한다.

Common Anti-Patterns (피해야 할 것들)

"Big Bang" 개발

- 한 번에 많은 기능을 구현하려고 함 - 실패 시 원인을 찾기 어려움 - 되돌리기 어려움

"추측 기반" 디버깅

- 현상을 제대로 관찰하지 않고 추측으로 수정 - 한 번에 여러 부분을 수정 - 실제 원인과 다른 곳을 수정

"완벽주의" 함정

- 실험 환경을 너무 완벽하게 만들려고 함 - 실험보다 환경 구축에 더 많은 시간 소모 - 간단한 실험으로도 충분한 상황에서 과도한 준비

Tools and Techniques

개발 환경 도구

- Hot reload: 코드 변경 시 즉시 반영 - REPL: 작은 코드 조각을 즉시 실행 - 디버거: 단계별 실행과 상태 확인 - 로깅: 실행 경로와 변수 값 추적

테스팅 도구

- Unit tests: 작은 단위의 동작 검증 - Test fixtures: 일관된 테스트 환경 - Mock objects: 외부 의존성 제거 - Test doubles: 복잡한 객체의 간단한 대체재

프로파일링 도구

- 성능 측정: 실행 시간, 메모리 사용량 - 데이터베이스 쿼리 분석: 실행 계획, 인덱스 사용 - 네트워크 모니터링: 요청/응답 시간, 데이터 크기

Resulting Context

TinyExperiment를 습관화하면:

- 불확실성이 줄어든다 - 추측 대신 확실한 지식 축적 - 학습이 가속화된다 - 빠른 피드백으로 경험 축적 - 실패 비용이 낮아진다 - 작은 실패로 큰 실패 방지 - 자신감이 향상된다 - 복잡한 문제도 작은 단위로 분해하여 해결 - 시스템 이해가 깊어진다 - 점진적 탐색으로 전체 그림 파악 - 팀 협업이 개선된다 - 명확한 가설과 결과로 소통

Related Patterns

* Enables: BabyStep, UseAbduction, HereAndNowDebugging * Used by: TddIsDesignActivity, PiecemealGrowthCenterFirst * Complements: ShortFeedbackCycle, MicroCommit * Conflicts with: BigBangDevelopment, GuessBasedDebugging

See Also

* 가추법 - 관찰에서 가설을 도출하는 사고 방식 * Kent Beck의 "Test Driven Development" - 작은 테스트로 설계하기 * Gary Klein의 "Sources of Power" - 전문가의 직관과 가설 검증 * 과학적 방법론 - 가설-실험-검증의 순환

CategoryPattern