TinyExperiment

Context

복잡한 프로젝트에서 문제를 해결하거나 새로운 기능을 구현할 때, 또는 버그를 찾고자 할 때. 불확실성이 높고 여러 가능성이 존재하는 상황에서 무엇 먼저해야 할지 모르는 경우.

Problem

두 가지 요리사의 이야기

어떤 레스토랑에 두 명의 요리사가 있었다. 둘 다 새로운 파스타 요리를 만들라는 임무를 받았다.

첫 번째 요리사는 모험적인 성격이었다. "완벽한 새로운 파스타를 만들겠어!" 특별한 면도 새로 만들고, 소스도 완전 새롭게 하고, 치즈 특유의 맛도 새로 만들고, 향신료도 특별한 것들로만 쓰기로 했다. 3시간 동안 심혈을 기울여 요리를 완성했지만, 이상한 맛이 나와서 먹을 수가 없었다. 손님들은 고개를 절레절레 흔들었다. 무엇이 모험적인 요리사는 어디서 잘못되었는지 알 수 없었다. 면을 잘못했나? 소스를 잘못했나? 치즈를 잘못했나? 처음부터 다시 만들어야 했다.

두 번째 요리사는 체계적인 다른 방식을 선택했다. 먼저 기본적인 기본 파스타를 만들어 맛을 확인했다. 그 다음 소스를 조금 바꿔서 다시 맛을 봤다. "좋다, 이게 맞다." 그리고 치즈 한 종류만 바꿔서 또 맛을 봤다. 각 단계마다 맛이 좋은지 나쁜지 확인했다. 만약 한 변경사항이 맛이 없다면, 바로 이전 단계로 돌아갔다. 2시간 후, 손님들이 "이 파스타 정말 맛있네요!"라고 극찬하는 요리가 완성되었다.

프로그래머들도 마찬가지다. 복잡한 문제를 한 번에 모든 요소를 바꿔려다가 모험적인 요리사처럼 실패하거나, 체계적인 요리사처럼 작은 단계로 차근차근 실험하거나. 차이는 매우 명확히 있다.

Solution

실험 가능한 환경을 먼저 만들어라

체계적인 요리사의 핵심은 단순했다. 큰 변화를 한번에 시도하는 대신, 각 변경이 어떤 영향을 주는지 확인하고, 실패해도 쉽게 되돌아갈 수 있게 준비하는 것이었다.

프로그래밍에서도 이와 같은 "작은 실험"을 만들 수 있다. 새로운 기능을 구현할 때, 버그를 찾을 때, 코드를 개선하려 할 때 이 접근법을 사용하라.

울타리를 쳐서 실험 영역을 격리하라

큰 문제에서 특정한 부분만을 분리해내어 그 부분에만 집중할 수 있는 "울타리"를 만들어라. 울타리 안에서는 자유롭게, 빠르게, 안전하게 다양한 실험을 할 수 있어야 한다. 이것이 TinyExperiment의 핵심이다.

체계적인 요리사는 "전체 요리"가 아니라 "이 소스" 또는 "이 치즈"처럼 구체적인 부분에만 집중했다. 프로그래머도 "전체 시스템"이 아니라 "이 함수" 또는 "이 데이터 변환"처럼 구체적으로 범위를 한정하라.

실험 가능한 환경을 창의적으로 구축하라

이것이 TinyExperiment를 단순한 PDCA 사이클과 구별하는 핵심이다. **실험 가능한 환경을 만드는 것 자체가 훈련된 창의성을 요구한다.**

실제 사례: 구글 앱스 스크립트 테스팅 환경

한 페어 프로그래밍 세션에서 친구가 구글 폼 설문조사 데이터로부터 분석 보고서 PDF를 생성하는 구글 앱스 스크립트를 만들고 있었다. 하지만 스파게티 코드 때문에 속도가 느려지고 있었고 리팩토링이 필요했다.

문제는 구글 앱스 스크립트에는 제대로 된 유닛 테스트 환경이 없다는 것이었다. 물론 있을 수도 있지만, 1시간이라는 제한된 시간에는 그것을 찾고 설정할 여유가 없었다.

해결책: **매우 간단한 테스팅 환경을 직접 만들었다.** console.log를 사용해 true/false 또는 pass/fail을 테스트케이스 이름과 함께 출력하는 것이다.

많은 사람들이 print문을 사용한다. 하지만 소수만이 이것을 assertion 형태로 활용한다. 임의의 값을 출력하면 기준을 만족하는지 판단하기 어렵다. 하지만 단순히 true/false나 pass/fail을 테스트케이스 이름과 함께 출력하면, 어떤 테스트케이스가 성공했는지 실패했는지 즉시 알 수 있다.

function testDataTransformation() {
  console.log("테스트: 날짜 파싱", parseDate("2024-01-15") === "2024/01/15" ? "PASS" : "FAIL");
  console.log("테스트: 빈 데이터 처리", handleEmptyData("") === null ? "PASS" : "FAIL");
  console.log("테스트: 계산 로직", calculateScore([1,2,3]) === 6 ? "PASS" : "FAIL");
}

이렇게 해서 **거의 모든 작업에서, 어떤 상황에서도 TinyExperiment 환경을 만들 수 있다.** 핵심은 기존 도구의 한계에 굴복하지 않고, 창의적으로 실험 환경을 구축하는 것이다.

구체적인 가설을 세워라

체계적인 요리사는 "이 소스가 더 나을 것이다"라는 구체적인 가설을 세우고 실험했다. 프로그래머도 "이 함수가 느린 것이다"가 아니라 "이 반복문에서 데이터베이스를 N번 호출해서 느린 것이다"처럼 구체적으로 하라.

빠른 피드백 루프를 만들어라

체계적인 요리사는 각 단계마다 바로 맛을 봤다. 완성된 전체 요리가 아니라 작은 부분만 실험할 수 있게 했다. 프로그래머도 git 브랜치를 잘 활용한다. 새로운 시도를 위한 브랜치를 만들고, 실패하면 쉽게 되돌아간다. 테스트 코드도 전체 시스템을 실행하지 않아도 확인하는데 필요한 부분만 한다.

찔러보고 반응을 관찰하라

이것이 TinyExperiment의 핵심 리듬이다. 작은 변화를 주고(찔러보고), 시스템의 반응을 관찰하고, 그 결과에서 학습하고, 전략을 조정하고, 다시 찔러본다. 이는 일종의 PDCA 사이클이지만, **실험 가능한 환경을 만드는 데 훨씬 더 많은 에너지를 투입한다는 점**이 다르다.

한 번에 하나씩만 바꿔라

체계적인 요리사의 가장 중요한 원칙이다. 소스를 바꿀 때는 다른 것은 그대로 두고 소스만 바꿨다. 그래야 결과가 좋아졌는지 나빠졌는지 소스 때문이라는 걸 확실히 알 수 있었다. 프로그래머도 한 번에 하나의 변수만 바꿔야 한다. 함수를 최적화할 때 동시에 데이터베이스 스키마까지 바꾸면, 어떤 것이 진짜 효과가 있었는지 알 수 없다.

Examples

주니어 개발자 민호의 첫 번째 버그 해결

민호는 "로그인 후 메뉴버튼이 보이지 않는다"는 버그 리포트를 받았다. 처음엔 막막 했다. 로그인 시스템도 복잡하고, 메뉴버튼도 여러 컴포넌트와 연결되어 있었다.

선배개발자 수진이 조언을 해주었다. "체계적인 요리사처럼 해봐. 큰 문제 대신 작은 부분만 울타리 쳐서 보자."

민호는 먼저 "이 버그를 재현할 수 있나?"라는 질문부터 시작했다. 자신의 로컬 환경에서 직접 로그인해보니 문제없이 작동했다. 그런데다 다른 브라우저에서 시도해보니까 Internet Explorer에서만 문제가 발생했다.

"IE에서만 발생한다"는 새로운 정보로 민호는 범위를 더욱 좁혔다. "JavaScript 오류가 있을 것이다." 개발자 도구를 열어보니 실제로 오류 메시지가 있었다. 특정 함수에서 undefined 오류가 발생하고 있었다.

더욱 "이 함수가 왜 값이 undefined이다"라는 구체적인 질문을 만들었다. console.log를 몇 개 추가해서 값들을 확인해보니, IE에서는 특정 API가 지원되지 않아서 undefined가 되고 있었다.

문제를 정확히 파악한 민호는 간단한 브라우저 호환성 체크 코드를 추가했다. 테스트해보니 문제가 해결되었다. 전체 과정은 1시간밖에 걸리지 않았다. 만약 처음부터 "아마 전체 시스템 문제일 것이다"라고 추측하고 모든 연관 코드를 다 뒤졌다면, 하루가 걸릴 수도 있었다.

구글 앱스 스크립트 리팩토링 사례 (상세)

페어 프로그래밍 파트너는 300줄짜리 구글 앱스 스크립트를 가지고 있었다. 설문조사 데이터를 받아서 복잡한 분석을 하고 PDF 보고서를 생성하는 코드였다. 문제는 모든 로직이 하나의 거대한 함수에 뒤섞여 있어서 수정할 때마다 다른 부분이 깨졌다.

**1단계: 실험 환경 구축** 일반적인 유닛테스트 프레임워크를 사용할 수 없는 상황이었다. 대신 매우 간단한 테스트 환경을 만들었다:

function runTests() {
  console.log("=== 데이터 파싱 테스트 ===");
  testDataParsing();
  console.log("=== 계산 로직 테스트 ===");
  testCalculationLogic();
  console.log("=== PDF 생성 테스트 ===");
  testPdfGeneration();
}

function testDataParsing() {
  var sampleData = [["이름", "점수"], ["김철수", "85"], ["이영희", "92"]];
  var result = parseFormData(sampleData);
  console.log("파싱 결과 확인:", result.length === 2 ? "PASS" : "FAIL");
  console.log("첫 번째 항목:", result[0].name === "김철수" ? "PASS" : "FAIL");
}

**2단계: 울타리 치기** 전체 300줄을 한번에 리팩토링하는 대신, 가장 명확한 부분부터 분리했다: - 데이터 파싱 로직만 별도 함수로 분리 - 계산 로직만 별도 함수로 분리 - PDF 생성 로직만 별도 함수로 분리

**3단계: 하나씩 실험** 각 함수를 분리할 때마다 테스트를 실행해서 기존 기능이 깨지지 않았는지 확인했다. 문제가 발생하면 즉시 이전 상태로 되돌렸다.

**결과:** 1시간 만에 300줄의 스파게티 코드가 10개의 작은 함수로 깔끔하게 분리되었다. 각 함수는 10-20줄 정도였고, 각각 명확한 책임을 가지고 있었다. 가장 중요한 것은 **실험 환경을 먼저 구축했기 때문에 자신있게 리팩토링할 수 있었다**는 점이다.

The Art of Creating Experiment-able Environments

왜 실험 환경을 만드는 것이 그렇게 중요한가?

TinyExperiment와 일반적인 PDCA의 차이는 여기에 있다. PDCA는 "계획-실행-확인-조치"의 사이클에 집중한다. 하지만 TinyExperiment는 **"확인"을 쉽고 빠르고 안전하게 할 수 있는 환경을 구축하는 것**에 더 많은 에너지를 투입한다.

마치 과학자가 실험실을 먼저 세팅하고 실험을 시작하는 것처럼, 프로그래머도 "실험실"을 먼저 만들어야 한다.

훈련된 창의성의 필요

실험 환경을 만드는 것은 단순한 기술적 작업이 아니다. **훈련된 창의성**이 필요하다:

- 기존 도구의 한계를 인식하고 - 현재 상황에서 가능한 최선의 대안을 찾고 - 최소한의 노력으로 최대한의 실험 가능성을 만들어내는 것

구글 앱스 스크립트 사례에서 "console.log를 assertion으로 사용하기"는 이런 창의성의 예시다. 완벽하지 않지만, 주어진 제약 조건에서 가능한 최선의 실험 환경이었다.

다양한 실험 환경 구축 기법

**1. REPL 활용하기** - 언어별 인터랙티브 셸 사용 - 작은 코드 조각을 즉시실행하며 테스트

**2. 가벼운 테스트 헬퍼 만들기** - assert 같은 간단한 검증 함수 - 결과를 쉽게 확인할 수 있는 출력 형식

**3. 샌드박스 환경 구축** - 메인 코드와 분리된 실험 공간 - 안전하게 실패할 수 있는 환경

**4. 빠른 피드백 도구** - 핫 리로드, 와치 모드 - 즉시 결과를 볼 수 있는 시각화

실험 환경의 품질 지표

좋은 실험 환경은 다음 특성을 가진다: - **빠름**: 실험에서 결과까지 몇 초 이내 - **안전함**: 실패해도 전체 시스템에 영향 없음 - **격리됨**: 다른 요소들의 간섭 최소화 - **관찰 가능함**: 결과를 명확하게 확인 가능

Common Pitfalls

완벽한 실험 환경을 기다림

많은 프로그래머들이 완벽한 실험하기 위해 완벽한 환경을 구축하려고 한다. 모든 테스트를 작성하고, 모든 도구를 설정하고, 모든 문서를 읽고 나서야 실험을 시작하려 한다. 하지만 이런 완벽주의는 실제로는 시간 낭비다.

체계적인 요리사는 바로 맛을 볼 수 있는 기본 셋업만 가지고 바로 실험을 시작했다. 완벽한 주방 시설을 기다리지 않았다. 프로그래머도 print문이나 로그만 있어도 충분히 실험할 수 있다.

추측만 하기

"아마 이게 문제일 것이다"라는 추측만 하고 실제로는 확인하지 않는 경우들이 많다. 추측은 실험의 시작점이 될 수 있지만, 그 자체로는 의미가 없다. 체계적인 요리사도 "이 소스가 더 나을 것 같다"고 생각했지만, 반드시 실제로 맛을 확인했다.

너무 큰 실험

한번에 너무 많은 것을 바꾸려고 하는 것도 흔한 실수다. "이 함수와 이 데이터베이스 쿼리와 이 UI를 동시에 개선해보자"는 식으로 접근하면, 결과가 좋아져도 나빠져도 무엇 때문인지 알 수 없다.

Tools for Your Laboratory

실험을 위한 도구들이 필요하다. 체계적인 요리사에게 맛을 볼 수 있는 숟가락이 있었듯이, 프로그래머에게도 실험을 위한 도구들이 있다.

**기본 도구들:** - 코드를 즉석에서 실행해볼 수 있는 REPL - 중간 결과를 바로 확인할 수 있는 로그 출력 - 변화를 확인할 수 있는 버전 관리 - 빠른 실행이 가능한 테스트 코드

**고급 도구들:** - 핫 리로드 개발 환경 - 인터랙티브 디버거 - 성능 프로파일러 - 시각화 도구

하지만 가장 중요한 것은 도구 자체가 아니라 도구를 활용하는 마음가짐이다. "빠르게 확인하고, 빠르게 배우고, 빠르게 조정한다"는 체계적인 요리사의 철학이 핵심이다.

Resulting Context

TinyExperiment를 숙련화하면 복잡한 문제 앞에서도 당황하지 않게 된다. 큰 규모 문제 해결도 이루어낼 수 있고, 복잡한 시스템도 작은 부분부터 차근차근 이해할 수 있다는 것을 안다. 실수를 두려워하지 않게 되고, 실험을 통한 학습이 매우 자연스러워진다.

가장 중요한 변화는 시스템과 대화하는 방법을 안다는 점이다. 코드에서 뭔가하고, 반응을 보고, 다시 실험하는 순환이 자연스러워진다. 이것이 진정한 프로그래머의 기본기다.

Related Patterns

* 연관: BabySteps, GreenRefuge - 작은 단계와 안전한 되돌림 * 활용: DesignThroughTest, DetectiveWork - 설계와 디버깅에서의 실험 * 보완: TightLoop, AtomicCommit - 빠른 피드백과 작은 변경

See Also

* 추론법 - 가설을 세우고 검증하는 사고 방법 * Kent Beck의 "Test Driven Development" - 작은 테스트로 시작하기 * Gary Klein의 "Sources of Power" - 전문가의 직관적 사고 패턴

CategoryPattern