TinyExperiment

TinyExperiment.pdf

The Story 1: Complex Regex (Programming)

한 주니어 개발자가 기존 코드에 있는 복잡한 정규표현식을 수정해야 하는 상황에 처했다.  /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$/  그는 정규표현식 전체를 한꺼번에 이해하려고 끙끙대며 1시간을 보냈다. 하지만 시니어는 다르게 접근했다. 그는 정규표현식을 부분별로 나누어(Detachment), 아주 작은 테스트 함수에 하나씩 넣어보았다(Experiment-able). "먼저 소문자만 체크해보자. 그다음엔 숫자만." 15분 만에 그는 복잡한 패턴의 정규표현식을 완벽하게 파악하고 안전하게 수정했다.

The Story 2: The Baker's Test (Ordinary Life)

민수와 하나는 친구의 결혼식 답례품으로 줄 '초콜릿 쿠키' 200개를 굽기로 했다.

민수의 방식 (The Big Batch): 민수는 레시피를 믿고 200개 분량의 반죽을 한꺼번에 만들었다. "레시피대로 했으니 당연히 맛있겠지?" 그는 거대한 오븐에 쿠키들을 가득 넣고 구웠다. 하지만 오븐에서 나온 쿠키들은 너무 딱딱했고 지나치게 달았다. 200개의 쿠키는 모두 쓰레기통으로 향했고, 민수는 재료비와 시간을 모두 날렸다.

하나의 방식 (The Tiny Experiment): 하나는 반죽을 한 숟가락만 떼어내어 작은 오븐에 딱 2개만 먼저 구워보았다.

  1. 분리: 전체 양이 아닌 한 조각만 먼저 굽는다.

  2. 관찰: 구워진 쿠키를 먹어보니 속이 덜 익고 설탕이 너무 많았다.

  3. 조정: 설탕을 줄이고 오븐 온도를 10도 높였다.

하나는 세 번의 '작은 실험' 끝에 완벽한 맛과 식감을 찾아냈고, 그제야 200개의 쿠키를 자신 있게 구워냈다. 큰 실패의 위험을 작은 실험으로 미리 차단한 것이다.

Context

거대한 시스템 앞에서 큰 시스템을 바로 건드려야 하는 상황. 복잡한 곳에서부터 접근해야 할지 막막하거나, 무언가 건드릴 때마다 고장나기 쉽거나, 새로운 기능을 짜거나 기존 코드를 고쳐야 할 때.

Problem

성급함이라는 거대한 장애물

대부분의 프로그래머들은 큰 것을 전체를 한번에 다루려는 습관에 빠져 있다. 전통적인 접근은 세 단계를 따른다. 첫째로 기획 후 작업 후 완성이라는 순서를 가진다. 머릿속으로 전체를 상상하고, 한번에 구현하려 한다. 둘째로 실행 후 기도 후 결과를 기다린다. "아마 이렇게 하면 될 것이다"라고 추정하고 프로그램이 잘 되기를 기대한다. 셋째로 검증 후 디버그 후 재시도를 반복한다. 실제상황에서만 문제를 찾고 해결하기를 반복한다.

하지만 이런 습관방식은 심각한 문제들을 만든다. 피드백이 늦다. 전체에 대해 무엇이 잘못된 것인지 어떻게 작동하는지 잘 모르는데도 추진한다. 실수 비용이 크다. 잘못되면 처음부터 다시 해야 한다. 학습이 일어나지 않는다. 왜 작동하는지 작동하지 않는지 메커니즘을 놓친다. 창의성이 막힌다. 큰 것이 앞에 서있으면 압도되어 어떤 길로 가야 할지 모른다.

실제 문제는 큰 것들에 대해 우리 대부분이 가지고 있는 잘못된 접근 방식이다. 다시 정리하면 큰 전체 시스템에서 작은 작동 가능한 부분들을 분리해내는 능력이 부족하다는 점이다. 300줄짜리 함수를 보면서 "복잡한 것에서부터 어떤 길로 갈까?" 고민한다. 새로운 것이 많은데 "전체 시스템을 이해해서..." 라고 접근한다. 새로운 라이브러리를 배울 때 전체 문서를 다 읽으려 한다.

Solution

TinyExperiment의 3단계 사이클

1단계: 작은 부분 분리하기 (Detachment)

큰 전체 시스템에서 독립적이고 작은 부분만 떼어낸다. 이것이 TinyExperiment의 핵심 시작점이다. 전체 시스템이 아니라 극히 작고 특별한 특정 기능만 분리한다.

분리를 위한 구체적인 전략들이 있다. 함수 단위 분리에서는 300줄 함수에서 10줄짜리 핵심 기능만 먼저 빼서 만든다. 데이터 단위 분리에서는 데이터베이스 시스템에서 작은 3-4개의 레코드를 만들어 준비한다. 처리과정 단위 분리에서는 100단계 중에서 한 가지 결과를 내는 1단계만 먼저 한다. 의존성 단위 분리에서는 전체 시스템에서 이 작은 기능이 외부로부터 독립적으로 작동하게 한다.

2단계: 실험 가능하게 만들기 (Make it Experiment-able)

분리한 부분을 빠르게 실험하고 결과를 볼 수 있는 환경을 만들어라. 이 단계에서 밑바닥 창의성이 필요하다. 작은 기능이 혼자서도 돌아가도록 하는, 실제 상황에서 떨어진 최소한의 작은 환경을 만든다.

실험 환경을 만드는 몇 가지 예들이 있다. 작은 테스트 스크립트 만들기는 단위테스트와는 다른 환경이다: 

function testDataParsing() {
  console.log("날짜 파싱:", parseDate("2024-01-15") === "2024/01/15" ? "PASS" : "FAIL");
  console.log("빈 데이터:", handleEmpty("") === null ? "PASS" : "FAIL");  
  console.log("숫자 변환:", toNumber("123") === 123 ? "PASS" : "FAIL");
}

외부 API 호출 테스트는 다음과 같이 한다: 

// 실제 API 대신 가짜 데이터로 테스트
const mockData = { users: [{ id: 1, name: "test" }] };
console.log("활성화 필터링:", filterActiveUsers(mockData));

데이터베이스 작업 시뮬레이션은 이렇게 한다: 

// 전체 DB 대신 작은 테스트 데이터로
const testRows = [
  { id: 1, status: 'active', score: 85 },
  { id: 2, status: 'inactive', score: 92 }
];
console.log("상태 필터:", filterByStatus(testRows, 'active'));

3단계: 실험 휠 돌리기 (Flying the Experiment Wheel)

작고 빠른 반복으로 계속 학습하라. 이제 찔러보고 → 관찰 → 배우기 → 조정 → 다시 찔러보기 사이클을 빠르게 돌린다.

실험 휠의 각 단계는 명확한 목적을 가진다. Poke (찔러보기)에서는 작은 변경을 가한다. Observe (관찰)에서는 시스템의 반응을 본다. Learn (학습)에서는 왜 그런 결과가 나오는지 추론한다. Adjust (조정)에서는 다음 변경을 위해 접근을 수정한다.

The Learning Laboratory

왜 이런 작은 반복이 최고의 학습 환경인가? TinyExperiment의 진짜 목적은 학습이다. 작고 빠른 반복을 통해서 깊이를 이해하게 한다.

삼각측량 피드백이 일어난다. 변경과 그 결과 사이에 직접적인 연결을 볼 수 있다. 잘못된 변경이 어떤 결과를 가져오는지 바로 수정할 수 있다. "왜?"라는 질문에 대한 답이 바로 보인다.

안전한 실패가 가능하다. 작은 범위의 실패 비용만 있다 (몇 초만 피드백을 기다리면 됨). 망해도 큰 영향을 끼치지 않고 안전하게 시도한다. 실패에서 학습할 수 있다.

창조의 경험을 얻는다. 표준으로 정해진 것이 아니라 직접 발견하는 기쁨을 느낀다. "정답"이 아니라 "왜"를 안다. 창의적 해결방법을 발견할 수 있는 기회가 온다.

Real Examples

예제 1: 복잡한 정규표현식 이해하기

상단 'Story 1'의 사례와 같이 복잡한 패턴을 분리하여 개별적으로 검증함으로써 신속하고 정확하게 원리를 파악한 사례.

예제 2: 성능 문제 찾기

로딩 과정을 단계별로 console.time()으로 측정하여 8초 중 5초가 걸리는 특정 데이터 처리 지점을 발견하고 최적화한 사례.

예제 3: 새로운 API 배우기

100페이지 문서를 다 읽는 대신, curl이나 Postman으로 API 하나만 직접 호출해보며 요청과 응답 구조를 2시간 만에 파악한 사례.

Common Anti-Patterns

첫 번째 안티패턴은 전체를 이해하려는 욕구다. "전체를 다 이해하고 나서 시작해야 한다"는 생각 때문에 시작도 영원히 하지 못한다. 해결책은 시작해야 할 최소한만 분리해서 시작하는 것이다.

두 번째 안티패턴은 완벽한 환경을 기다리기다. "실제로 제대로 된 테스트 인프라에서 해봐야지"라고 생각해서 환경 구축에서만 시간을 소모한다. console.log를 활용해서라도 바로 시작하는 것이 낫다.

세 번째 안티패턴은 한번에 너무 많이 바꾸기다. "이것도 고치고 저것도 고치고..."라고 접근하면 어떤 변경이 효과를 가져왔는지 모르게 된다. 한 번에 하나씩만 바꾸는 것이 원칙이다.

The Experiment Mindset

TinyExperiment를 체화하면 평소에 이런 질문들이 자연스럽게 떠오른다:

이런 질문들이 습관이 되면, 거대한 것이 앞에 와도 상황에서 멈추지 않는다. 항상 "작은 시작점이 어디일까"를 찾는 사고방식을 자연스럽게 갖게 된다.

Tools and Techniques

실험 환경을 위해 활용하는 도구들이 여러 있다. REPL은 즉석 인터랙티브 환경이다. console.log/print는 가장 기본적이면서도 강력한 실험과 디버깅 도구이다. 단위 테스트는 작은 부분을 격리해서 실험하는 방법이다. git stash/branch는 실험을 안전한 별도 공간에서 하기 위한 것이다. 샌드박스는 코드 온라인 실험환경을 활용하는 것이다. 프로파일러는 성능 실험을 위한 도구이다.

Resulting Context

TinyExperiment를 체화하면 창의성이 막히지 않고 학습 속도가 빨라지며 실패에 대한 두려움이 사라집니다. 가장 중요한 변화는 "탐구하는 프로그래머"가 되는 것입니다.

Connection to Other Patterns

CategoryPatternLanguage CategoryProgramming CategoryLearning CategoryAgile

TinyExperiment (last edited 2025-12-30 10:00:26 by 정수)