Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2025-07-24 13:27:57
Size: 11260
Editor: 정수
Comment:
Revision 6 as of 2025-07-24 16:37:50
Size: 10545
Editor: 정수
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
복잡한 소프트웨어 문제를 해결하거나 새로운 기능을 구현할 때, 또는 버그를 추적할 때. 불확실성이 높고 여러 가능성이 존재하는 상황에서 어떻게 접근해야 할지 막막할 때. 복잡한 문제나 큰 시스템을 다룰 때. 어디서부터 시작해야 할지 막막하거나, 변경이 미칠 영향을 예측하기 어려운 상황. 새로운 기술을 배우거나 기존 코드를 이해해야 할 때.
Line 9: Line 9:
'''두 요리사의 이야기'''

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

첫 번째 요리사 알렉스는 야심이 컸다. "완전히 새로운 파스타를 만들어보자!" 그는 면도 직접 만들고, 소스도 새로 개발하고, 치즈도 특별한 것을 사용하고, 허브도 독특한 조합으로 넣기로 했다. 3시간 동안 열심히 요리한 결과, 이상한 맛의 음식이 나왔다. 손님들은 고개를 저었다. 하지만 알렉스는 무엇이 잘못되었는지 알 수 없었다. 면 때문일까? 소스 때문일까? 치즈 때문일까? 처음부터 다시 시작해야 했다.

두 번째 요리사 베타는 다르게 접근했다. 먼저 검증된 기본 파스타를 만들어 맛을 확인했다. 그 다음 소스만 조금 바꿔서 다시 맛을 보았다. "좋아, 이건 괜찮네." 그리고 치즈를 한 종류만 바꿔서 또 맛을 보았다. 각 단계마다 작은 접시에 조금씩 만들어서 확인했다. 만약 어떤 변경이 맛을 망쳤다면, 바로 이전 단계로 돌아갔다. 2시간 후, 손님들이 "이 파스타 정말 맛있네요!"라고 말하는 요리가 완성되었다.

개발자들도 마찬가지다. 복잡한 기능을 한 번에 모두 구현하려다가 알렉스처럼 실패하거나, 베타처럼 작은 단계로 나누어 성공하거나. 차이는 접근 방법에 있다.
'''실험이라는 개념 자체가 없다'''

대부분의 사람들은 프로그래밍을 할 때 **실험**이라는 개념을 아예 가지고 있지 않다. 그들의 접근 방식은 다음과 같다:

1. **계획 → 구현 → 완성** : 머릿속으로 전체를 설계하고, 한번에 구현하려 한다
2. **추측 → 수정 → 기대** : "아마 이렇게 하면 될 것이다"라고 추측하고 수정한 뒤 되기를 기대한다
3. **검색 → 복붙 → 시도** : 스택오버플로에서 답을 찾아 복사하고 작동하기를 바란다

이런 접근법의 문제점:
- **피드백이 늦다** : 전체를 다 만들고 나서야 작동하는지 안 하는지 안다
- **실패 비용이 크다** : 잘못되면 처음부터 다시 해야 한다
- **학습이 일어나지 않는다** : 왜 작동하는지 작동하지 않는지 이해하지 못한다
- **복잡성에 압도된다** : 큰 문제 앞에서 어디서부터 손을 대야 할지 모른다

'''진짜 문제: 큰 덩어리에서 작은 부분을 떼어내지 못함'''

핵심 문제는 **큰 복합체에서 관심 있는 작은 부분을 분리해내는 능력**이 없다는 것이다.

- 300줄짜리 함수를 보면서 "어디서부터 손을 대야 할까?" 막막해한다
- 버그가 있을 때 "전체 시스템이 복잡해서..." 라며 포기한다
- 새로운 라이브러리를 사용할 때 전체 문서를 다 읽으려 한다
Line 20: Line 32:
'''작은 실험실을 만들어라'''

베타 요리사의 지혜는 단순했다. 큰 변화를 작은 실험들로 나누고, 각 실험의 결과를 즉시 확인하고, 실패해도 쉽게 되돌아갈 수 있게 준비하는 것이었다.

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

'''명확한 가설부터 시작하라'''

베타가 "이 소스가 더 맛있을 것이다"라는 구체적인 가설을 세웠듯이, 개발에서도 명확한 가설을 세워야 한다. "이 함수가 느릴 것이다"가 아니라 "이 반복문에서 데이터베이스를 N번 호출해서 느릴 것이다"처럼 구체적으로 말이다.

'''안전한 실험 환경을 구축하라'''

베타는 작은 접시에 조금씩 만들어서 실험했다. 만약 망쳐도 전체 요리가 아니라 작은 부분만 버리면 되었다. 개발에서는 git 브랜치가 이 역할을 한다. 새로운 시도를 할 때마다 브랜치를 만들고, 실패하면 쉽게 되돌아간다. 테스트 코드는 기존 기능이 망가지지 않았는지 확인하는 안전망 역할을 한다.

'''즉시 피드백을 받아라'''

베타는 각 단계마다 맛을 보았다. 3시간 후에 맛을 보는 게 아니라 5분마다 맛을 확인했다. 개발에서도 마찬가지다. 코드를 100줄 짠 후에 테스트하는 게 아니라, 5줄 짤 때마다 실행해보고 확인한다. 자동화된 테스트, 핫 리로드, 간단한 print문까지 모든 것이 즉시 피드백을 주는 도구가 된다.

'''한 번에 하나씩만 바꿔라'''

베타의 가장 중요한 원칙이다. 소스를 바꿀 때는 다른 것은 그대로 두고 소스만 바꿨다. 그래서 결과가 나빠지면 소스 때문이라는 걸 확실히 알 수 있었다. 개발에서도 한 번에 하나의 변수만 바꿔야 한다. 함수를 수정할 때 동시에 데이터베이스 스키마까지 바꾸면, 문제가 생겼을 때 원인을 찾기 어렵다.

== Examples ==

'''신입 개발자 준호의 첫 번째 버그 수정'''

준호는 "로그인 후 대시보드가 가끔 안 보인다"는 버그 리포트를 받았다. 처음에는 겁이 났다. 로그인 시스템은 복잡하고, 대시보드도 여러 컴포넌트로 이루어져 있었다.

시니어 개발자 민지가 조언했다. "베타 요리사처럼 해봐. 한 번에 모든 걸 고치려 하지 말고, 작은 실험부터 시작해."

준호는 먼저 "이 버그를 재현할 수 있을까?"라는 가설을 세웠다. 자신의 로컬 환경에서 여러 번 로그인해봤지만 문제가 없었다. 그러다가 다른 브라우저로 시도해봤더니 Internet Explorer에서만 문제가 발생했다.

"IE에서만 발생한다"는 새로운 정보를 얻은 준호는 다음 가설을 세웠다. "JavaScript 에러가 있을 것이다." 브라우저 콘솔을 열어보니 과연 에러 메시지가 있었다. 특정 함수에서 undefined 에러가 발생하고 있었다.

이제 "이 함수의 이 변수가 undefined이다"라는 구체적인 가설이 생겼다. console.log를 몇 줄 추가해서 변수의 값을 확인해봤더니, IE에서는 특정 API가 지원되지 않아서 undefined가 되고 있었다.

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

'''경력 5년 차 수진의 성능 개선 프로젝트'''

수진은 "페이지 로딩이 너무 느리다"는 요청을 받았다. 경험이 있는 그녀도 처음에는 막막했다. 성능 문제는 여러 원인이 복합적으로 작용할 수 있기 때문이다.

하지만 수진은 베타 요리사의 방법을 알고 있었다. 먼저 현재 상황을 정확히 측정했다. 브라우저 개발자 도구를 열고 실제 로딩 시간을 확인했다. 8초가 걸리고 있었다.

첫 번째 가설: "이미지 파일이 너무 클 것이다." 네트워크 탭을 보니 5MB짜리 이미지들이 여러 개 있었다. 이미지를 압축하고 다시 측정했다. 5초로 줄어들었다. 좋은 시작이었다.

두 번째 가설: "JavaScript 파일이 클 것이다." 번들 분석기로 확인해보니 사용하지 않는 라이브러리들이 포함되어 있었다. 불필요한 것들을 제거하고 측정했다. 3초로 더 줄어들었다.

세 번째 가설: "데이터베이스 쿼리가 느릴 것이다." 서버 로그를 보니 N+1 쿼리 문제가 있었다. 쿼리를 최적화하고 측정했다. 1.5초까지 줄어들었다.

각 단계마다 실제 측정치로 개선 효과를 확인했기 때문에, 어떤 최적화가 얼마나 효과적인지 정확히 알 수 있었다. 만약 한 번에 모든 것을 바꿨다면, 어떤 변경이 진짜 효과가 있었는지 알 수 없었을 것이다.

== The Wisdom of Small Steps ==

'''왜 작은 단계가 더 빠를까?'''

역설적이게도, 작은 단계로 나누는 것이 결국 더 빠르다. 큰 변경을 한 번에 시도하다가 실패하면, 처음부터 다시 시작해야 한다. 하지만 작은 단계로 나누면 실패해도 바로 이전 단계로만 돌아가면 된다.

마치 산을 오를 때와 같다. 정상을 향해 일직선으로 가려다가 절벽을 만나면 다시 처음부터 시작해야 한다. 하지만 지그재그로 안전한 길을 찾아가면, 조금 더 돌아가더라도 결국 정상에 더 빨리 도착한다.

'''실패는 정보다'''

베타 요리사에게 실패한 실험은 낭비가 아니었다. "이 조합은 맛이 없다"는 중요한 정보였다. 개발에서도 마찬가지다. "이 방법은 작동하지 않는다"는 것을 빨리 알면, 다른 방법을 시도할 수 있다.

중요한 것은 실패의 비용을 낮추는 것이다. 작은 실험에서 실패하면 5분을 잃는다. 큰 변경에서 실패하면 5일을 잃는다.

'''시스템과 친해지기'''

작은 실험을 반복하다 보면, 시스템과 친해진다. 어떤 부분이 민감한지, 어떤 변경이 위험한지, 어떤 패턴이 잘 작동하는지 자연스럽게 알게 된다. 이런 직관은 큰 변경을 한 번에 시도해서는 얻을 수 없다.

베타 요리사가 재료들의 특성을 하나씩 이해해가듯이, 개발자도 코드베이스의 특성을 작은 실험을 통해 이해해간다.

== Common Pitfalls ==

'''완벽한 실험 환경의 함정'''

어떤 개발자들은 실험을 시작하기 전에 완벽한 환경을 만들려고 한다. 모든 테스트를 작성하고, 모든 도구를 설정하고, 모든 문서를 읽고 나서야 실험을 시작한다. 하지만 이는 본말이 전도된 것이다.

베타 요리사는 작은 접시와 기본 재료만 있으면 바로 실험을 시작했다. 완벽한 주방 설비를 기다리지 않았다. 개발에서도 마찬가지다. 간단한 print문이나 로그만 있어도 충분히 실험할 수 있다.

'''추측의 늪'''

"아마 이것 때문일 것이다"라는 추측에 빠지는 것도 위험하다. 추측은 가설의 출발점이 될 수 있지만, 검증 없이는 의미가 없다. 베타 요리사도 "이 소스가 더 맛있을 것 같다"고 생각했지만, 반드시 맛을 보고 확인했다.

== Tools for Your Laboratory ==

실험실에는 도구가 필요하다. 베타 요리사에게 작은 접시와 맛보기용 스푼이 있었듯이, 개발자에게도 실험을 돕는 도구들이 있다.

코드를 즉시 실행해볼 수 있는 REPL, 변경사항을 바로 확인할 수 있는 핫 리로드, 중간 결과를 확인할 수 있는 디버거, 기존 기능을 보호하는 테스트 코드. 이 모든 것들이 당신의 실험실을 구성하는 도구들이다.

중요한 것은 도구 자체가 아니라 도구를 사용하는 마음가짐이다. "빨리 확인하고, 빨리 배우고, 빨리 조정한다"는 베타 요리사의 철학 말이다.
'''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의 진짜 목적은 **학습**이다. 빠른 실험 반복은 다음을 가능하게 한다:

**1. 즉각적인 피드백**
- 추측을 몇 초 안에 검증할 수 있다
- 잘못된 가정을 빨리 발견하고 수정한다
- "왜?"에 대한 답을 즉시 얻는다

**2. 안전한 실패**
- 실패 비용이 거의 없다 (몇 초면 되돌릴 수 있음)
- 실패를 두려워하지 않고 과감하게 시도한다
- 실패에서 학습할 수 있다

**3. 깊은 이해**
- 표면적인 지식이 아니라 내부 원리를 이해한다
- "어떻게"가 아니라 "왜"를 안다
- 비슷한 문제에 응용할 수 있는 통찰을 얻는다

== Real Examples ==

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

**상황**: 기존 코드에 있는 복잡한 정규표현식을 수정해야 함
{{{
/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$/
}}}

**전형적인 접근**: 정규표현식 문서를 읽고 전체를 이해하려 시도

**TinyExperiment 접근**:

1. **분리**: 정규표현식을 부분별로 나눔
2. **실험 환경**: 간단한 테스트 함수 생성
{{{
function testRegexPart(pattern, testString) {
  const regex = new RegExp(pattern);
  console.log(`"${testString}" -> ${regex.test(testString) ? 'MATCH' : 'NO MATCH'}`);
}

// 각 부분별로 실험
testRegexPart('(?=.*[a-z])', 'Hello123!'); // 소문자 포함 확인
testRegexPart('(?=.*[A-Z])', 'Hello123!'); // 대문자 포함 확인
testRegexPart('(?=.*\\d)', 'Hello123!'); // 숫자 포함 확인
}}}

3. **학습**: 각 부분이 무엇을 하는지 실험으로 이해
4. **조정**: 필요한 부분만 수정

**결과**: 15분만에 복잡한 정규표현식의 구조를 완전히 이해

=== 예시 2: 성능 병목 찾기 ===

**상황**: 페이지 로딩이 8초나 걸리는 문제

**전형적인 접근**: 프로파일러로 전체 분석하려 시도

**TinyExperiment 접근**:

1. **분리**: 로딩 과정을 단계별로 나눔
{{{
console.time('데이터 로딩');
const data = await fetchData();
console.timeEnd('데이터 로딩'); // 2초

console.time('데이터 가공');
const processed = processData(data);
console.timeEnd('데이터 가공'); // 5초 <- 병목 발견!

console.time('렌더링');
renderData(processed);
console.timeEnd('렌더링'); // 1초
}}}

2. **실험 환경**: 데이터 가공 부분만 분리해서 테스트
3. **학습**: N+1 쿼리 문제 발견
4. **조정**: 배치 처리로 변경

**결과**: 8초 → 1.5초로 성능 개선

=== 예시 3: 새로운 API 익히기 ===

**상황**: 복잡한 REST API 문서 100페이지

**전형적인 접근**: 문서를 처음부터 끝까지 읽으려 시도

**TinyExperiment 접근**:

1. **분리**: 가장 간단한 API 하나만 선택
2. **실험 환경**: curl이나 Postman으로 바로 호출
{{{
curl -X GET "https://api.example.com/users/1" -H "Authorization: Bearer token"
}}}

3. **학습**: 응답 구조 파악, 인증 방식 이해
4. **조정**: 다음 실험할 API 선택

**결과**: 2시간만에 API의 핵심 패턴 파악, 실제 개발 시작 가능

== Common Anti-Patterns ==

=== 1. 전체 이해하려는 강박 ===
- **증상**: "전체를 다 이해하고 나서 시작해야 해"
- **문제**: 영원히 시작하지 못함
- **해결**: 이해해야 할 최소한만 분리해서 실험

=== 2. 완벽한 환경 기다리기 ===
- **증상**: "제대로 된 테스트 프레임워크부터 세팅하자"
- **문제**: 환경 구축에만 시간 소모
- **해결**: console.log라도 활용해서 즉시 시작

=== 3. 한번에 너무 많이 바꾸기 ===
- **증상**: "이것도 고치고 저것도 고치고..."
- **문제**: 어떤 변경이 효과가 있었는지 모름
- **해결**: 한 번에 하나씩만 변경

== The Experiment Mindset ==

TinyExperiment를 체화하면 다음과 같은 사고방식이 자연스러워진다:

**"이걸 어떻게 작게 쪼갤 수 있을까?"**
**"이 부분만 따로 실험해볼 수 있을까?"**
**"5분 안에 결과를 확인할 수 있을까?"**
**"실패해도 쉽게 되돌릴 수 있을까?"**

이런 질문들이 습관이 되면, 복잡한 문제 앞에서도 당황하지 않는다. 항상 "작은 실험부터 시작하자"는 접근법이 자연스러워진다.

== Tools and Techniques ==

**빠른 실험을 위한 도구들:**
- **REPL**: 언어별 인터랙티브 셸
- **console.log/print**: 가장 기본적이지만 강력한 관찰 도구
- **단위 테스트**: 작은 부분을 격리해서 실험
- **git stash/branch**: 안전한 실험을 위한 버전 관리
- **디버거**: 코드 실행 과정을 관찰
- **프로파일러**: 성능 병목을 관찰

**핵심은 도구가 아니라 마음가짐**이다. 어떤 환경에서든 실험할 방법을 찾아내는 창의성이 중요하다.
Line 113: Line 234:
TinyExperiment를 습관화하면 복잡한 문제 앞에서도 당황하지 않게 된다. 큰 산도 작은 돌들로 이루어져 있고, 복잡한 시스템도 작은 부분들로 나누어 이해할 수 있다는 것을 안다. 실패를 두려워하지 않게 되고, 오히려 실패에서 배우는 것에 익숙해진다.

가장 중요한 것은, 시스템과 대화하는 법을 배우게 된다는 것이다. 코드에게 질문하고, 답을 듣고, 다시 질문하는 순환이 자연스러워진다. 이것이 진정한 프로그래밍의 시작이다.

TinyExperiment를 체화하면:

- **복잡성에 압도되지 않는다**: 큰 문제도 작은 실험들의 연속으로 본다
- **학습 속도가 빨라진다**: 빠른 피드백으로 깊은 이해를 얻는다
- **자신감이 생긴다**: 실패를 두려워하지 않고 시도한다
- **문제 해결력이 향상된다**: 체계적인 실험 방법을 가진다

가장 중요한 변화는 **"실험하는 프로그래머"**가 되는 것이다. 추측하고 기대하는 대신, 실험하고 학습한다.
Line 118: Line 245:
* '''Enables:''' [[BabyStep]], [[UseAbduction]], [[HereAndNowDebugging]]
* '''Used by:''' [[TddIsDesignActivity]], [[PiecemealGrowthCenterFirst]]
* '''Complements:''' [[ShortFeedbackCycle]], [[MicroCommit]]
* '''연관:''' [[BabySteps]], [[GreenRefuge]] - 작은 단계와 안전한 되돌림
* '''활용:''' [[DesignThroughTest]], [[DetectiveWork]] - 설계와 디버깅에서의 실험
* '''보완:''' [[TightLoop]], [[AtomicCommit]] - 빠른 피드백과 작은 변경
Line 123: Line 250:
* [[추법]] - 관찰에서 가설을 도출하는 사고 방
* Kent Beck의 "Test Driven Development" - 작은 테스트로 설계하기
* Gary Klein의 "Sources of Power" - 전문가의 직관 가설 검증
* [[추법]] - 가설을 세우고 검증하는 사고 방
* Kent Beck의 "Test Driven Development" - 작은 테스트로 시작하기
* Gary Klein의 "Sources of Power" - 전문가의 직관 사고 패턴

TinyExperiment

Context

복잡한 문제나 큰 시스템을 다룰 때. 어디서부터 시작해야 할지 막막하거나, 변경이 미칠 영향을 예측하기 어려운 상황. 새로운 기술을 배우거나 기존 코드를 이해해야 할 때.

Problem

실험이라는 개념 자체가 없다

대부분의 사람들은 프로그래밍을 할 때 **실험**이라는 개념을 아예 가지고 있지 않다. 그들의 접근 방식은 다음과 같다:

1. **계획 → 구현 → 완성** : 머릿속으로 전체를 설계하고, 한번에 구현하려 한다 2. **추측 → 수정 → 기대** : "아마 이렇게 하면 될 것이다"라고 추측하고 수정한 뒤 되기를 기대한다 3. **검색 → 복붙 → 시도** : 스택오버플로에서 답을 찾아 복사하고 작동하기를 바란다

이런 접근법의 문제점: - **피드백이 늦다** : 전체를 다 만들고 나서야 작동하는지 안 하는지 안다 - **실패 비용이 크다** : 잘못되면 처음부터 다시 해야 한다 - **학습이 일어나지 않는다** : 왜 작동하는지 작동하지 않는지 이해하지 못한다 - **복잡성에 압도된다** : 큰 문제 앞에서 어디서부터 손을 대야 할지 모른다

진짜 문제: 큰 덩어리에서 작은 부분을 떼어내지 못함

핵심 문제는 **큰 복합체에서 관심 있는 작은 부분을 분리해내는 능력**이 없다는 것이다.

- 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의 진짜 목적은 **학습**이다. 빠른 실험 반복은 다음을 가능하게 한다:

**1. 즉각적인 피드백** - 추측을 몇 초 안에 검증할 수 있다 - 잘못된 가정을 빨리 발견하고 수정한다 - "왜?"에 대한 답을 즉시 얻는다

**2. 안전한 실패** - 실패 비용이 거의 없다 (몇 초면 되돌릴 수 있음) - 실패를 두려워하지 않고 과감하게 시도한다 - 실패에서 학습할 수 있다

**3. 깊은 이해** - 표면적인 지식이 아니라 내부 원리를 이해한다 - "어떻게"가 아니라 "왜"를 안다 - 비슷한 문제에 응용할 수 있는 통찰을 얻는다

Real Examples

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

**상황**: 기존 코드에 있는 복잡한 정규표현식을 수정해야 함

/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$/

**전형적인 접근**: 정규표현식 문서를 읽고 전체를 이해하려 시도

**TinyExperiment 접근**:

1. **분리**: 정규표현식을 부분별로 나눔 2. **실험 환경**: 간단한 테스트 함수 생성

function testRegexPart(pattern, testString) {
  const regex = new RegExp(pattern);
  console.log(`"${testString}" -> ${regex.test(testString) ? 'MATCH' : 'NO MATCH'}`);
}

// 각 부분별로 실험
testRegexPart('(?=.*[a-z])', 'Hello123!');  // 소문자 포함 확인
testRegexPart('(?=.*[A-Z])', 'Hello123!');  // 대문자 포함 확인  
testRegexPart('(?=.*\\d)', 'Hello123!');    // 숫자 포함 확인

3. **학습**: 각 부분이 무엇을 하는지 실험으로 이해 4. **조정**: 필요한 부분만 수정

**결과**: 15분만에 복잡한 정규표현식의 구조를 완전히 이해

예시 2: 성능 병목 찾기

**상황**: 페이지 로딩이 8초나 걸리는 문제

**전형적인 접근**: 프로파일러로 전체 분석하려 시도

**TinyExperiment 접근**:

1. **분리**: 로딩 과정을 단계별로 나눔

console.time('데이터 로딩');
const data = await fetchData();
console.timeEnd('데이터 로딩'); // 2초

console.time('데이터 가공');  
const processed = processData(data);
console.timeEnd('데이터 가공'); // 5초 <- 병목 발견!

console.time('렌더링');
renderData(processed);
console.timeEnd('렌더링'); // 1초

2. **실험 환경**: 데이터 가공 부분만 분리해서 테스트 3. **학습**: N+1 쿼리 문제 발견 4. **조정**: 배치 처리로 변경

**결과**: 8초 → 1.5초로 성능 개선

예시 3: 새로운 API 익히기

**상황**: 복잡한 REST API 문서 100페이지

**전형적인 접근**: 문서를 처음부터 끝까지 읽으려 시도

**TinyExperiment 접근**:

1. **분리**: 가장 간단한 API 하나만 선택 2. **실험 환경**: curl이나 Postman으로 바로 호출

curl -X GET "https://api.example.com/users/1" -H "Authorization: Bearer token"

3. **학습**: 응답 구조 파악, 인증 방식 이해 4. **조정**: 다음 실험할 API 선택

**결과**: 2시간만에 API의 핵심 패턴 파악, 실제 개발 시작 가능

Common Anti-Patterns

1. 전체 이해하려는 강박

- **증상**: "전체를 다 이해하고 나서 시작해야 해" - **문제**: 영원히 시작하지 못함 - **해결**: 이해해야 할 최소한만 분리해서 실험

2. 완벽한 환경 기다리기

- **증상**: "제대로 된 테스트 프레임워크부터 세팅하자" - **문제**: 환경 구축에만 시간 소모 - **해결**: console.log라도 활용해서 즉시 시작

3. 한번에 너무 많이 바꾸기

- **증상**: "이것도 고치고 저것도 고치고..." - **문제**: 어떤 변경이 효과가 있었는지 모름 - **해결**: 한 번에 하나씩만 변경

The Experiment Mindset

TinyExperiment를 체화하면 다음과 같은 사고방식이 자연스러워진다:

**"이걸 어떻게 작게 쪼갤 수 있을까?"** **"이 부분만 따로 실험해볼 수 있을까?"** **"5분 안에 결과를 확인할 수 있을까?"** **"실패해도 쉽게 되돌릴 수 있을까?"**

이런 질문들이 습관이 되면, 복잡한 문제 앞에서도 당황하지 않는다. 항상 "작은 실험부터 시작하자"는 접근법이 자연스러워진다.

Tools and Techniques

**빠른 실험을 위한 도구들:** - **REPL**: 언어별 인터랙티브 셸 - **console.log/print**: 가장 기본적이지만 강력한 관찰 도구 - **단위 테스트**: 작은 부분을 격리해서 실험 - **git stash/branch**: 안전한 실험을 위한 버전 관리 - **디버거**: 코드 실행 과정을 관찰 - **프로파일러**: 성능 병목을 관찰

**핵심은 도구가 아니라 마음가짐**이다. 어떤 환경에서든 실험할 방법을 찾아내는 창의성이 중요하다.

Resulting Context

TinyExperiment를 체화하면:

- **복잡성에 압도되지 않는다**: 큰 문제도 작은 실험들의 연속으로 본다 - **학습 속도가 빨라진다**: 빠른 피드백으로 깊은 이해를 얻는다 - **자신감이 생긴다**: 실패를 두려워하지 않고 시도한다 - **문제 해결력이 향상된다**: 체계적인 실험 방법을 가진다

가장 중요한 변화는 **"실험하는 프로그래머"**가 되는 것이다. 추측하고 기대하는 대신, 실험하고 학습한다.

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

See Also

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


CategoryPattern

TinyExperiment (last edited 2025-07-24 23:12:45 by 정수)