Size: 15581
Comment:
|
Size: 10545
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: |
'''실험 가능한 환경을 먼저 만들어라''' 체계적인 요리사의 핵심은 단순했다. 큰 변화를 한번에 시도하는 대신, 각 변경이 어떤 영향을 주는지 확인하고, 실패해도 쉽게 되돌아갈 수 있게 준비하는 것이었다. 프로그래밍에서도 이와 같은 "작은 실험"을 만들 수 있다. 새로운 기능을 구현할 때, 버그를 찾을 때, 코드를 개선하려 할 때 이 접근법을 사용하라. '''울타리를 쳐서 실험 영역을 격리하라''' 큰 문제에서 특정한 부분만을 분리해내어 그 부분에만 집중할 수 있는 "울타리"를 만들어라. 울타리 안에서는 자유롭게, 빠르게, 안전하게 다양한 실험을 할 수 있어야 한다. 이것이 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의 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"); |
Line 54: | Line 63: |
이렇게 해서 **거의 모든 작업에서, 어떤 상황에서도 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(); |
**복잡한 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'}`); |
Line 105: | Line 134: |
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 - 중간 결과를 바로 확인할 수 있는 로그 출력 - 변화를 확인할 수 있는 버전 관리 - 빠른 실행이 가능한 테스트 코드 **고급 도구들:** - 핫 리로드 개발 환경 - 인터랙티브 디버거 - 성능 프로파일러 - 시각화 도구 하지만 가장 중요한 것은 도구 자체가 아니라 도구를 활용하는 마음가짐이다. "빠르게 확인하고, 빠르게 배우고, 빠르게 조정한다"는 체계적인 요리사의 철학이 핵심이다. |
// 각 부분별로 실험 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 204: | Line 234: |
TinyExperiment를 숙련화하면 복잡한 문제 앞에서도 당황하지 않게 된다. 큰 규모 문제 해결도 이루어낼 수 있고, 복잡한 시스템도 작은 부분부터 차근차근 이해할 수 있다는 것을 안다. 실수를 두려워하지 않게 되고, 실험을 통한 학습이 매우 자연스러워진다. 가장 중요한 변화는 시스템과 대화하는 방법을 안다는 점이다. 코드에서 뭔가하고, 반응을 보고, 다시 실험하는 순환이 자연스러워진다. 이것이 진정한 프로그래머의 기본기다. |
TinyExperiment를 체화하면: - **복잡성에 압도되지 않는다**: 큰 문제도 작은 실험들의 연속으로 본다 - **학습 속도가 빨라진다**: 빠른 피드백으로 깊은 이해를 얻는다 - **자신감이 생긴다**: 실패를 두려워하지 않고 시도한다 - **문제 해결력이 향상된다**: 체계적인 실험 방법을 가진다 가장 중요한 변화는 **"실험하는 프로그래머"**가 되는 것이다. 추측하고 기대하는 대신, 실험하고 학습한다. |
Line 210: | Line 246: |
* '''활용:''' [[DesignThroughTest]], [[DetectiveWork]] - 설계와 디버깅에서의 실험 | * '''활용:''' [[DesignThroughTest]], [[DetectiveWork]] - 설계와 디버깅에서의 실험 |
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를 체화하면:
- **복잡성에 압도되지 않는다**: 큰 문제도 작은 실험들의 연속으로 본다 - **학습 속도가 빨라진다**: 빠른 피드백으로 깊은 이해를 얻는다 - **자신감이 생긴다**: 실패를 두려워하지 않고 시도한다 - **문제 해결력이 향상된다**: 체계적인 실험 방법을 가진다
가장 중요한 변화는 **"실험하는 프로그래머"**가 되는 것이다. 추측하고 기대하는 대신, 실험하고 학습한다.
Related Patterns
* 연관: BabySteps, GreenRefuge - 작은 단계와 안전한 되돌림 * 활용: DesignThroughTest, DetectiveWork - 설계와 디버깅에서의 실험 * 보완: TightLoop, AtomicCommit - 빠른 피드백과 작은 변경
See Also
* 추론법 - 가설을 세우고 검증하는 사고 방법 * Kent Beck의 "Test Driven Development" - 작은 테스트로 시작하기 * Gary Klein의 "Sources of Power" - 전문가의 직관적 사고 패턴