TinyExperiment

Context

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

Problem

두 요리사의 이야기

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

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

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

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

Solution

작은 실험실을 만들어라

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

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

명확한 가설부터 시작하라

베타가 "이 소스가 더 맛있을 것이다"라는 구체적인 가설을 세웠듯이, 개발에서도 명확한 가설을 세워야 한다. "이 함수가 느릴 것이다"가 아니라 "이 반복문에서 데이터베이스를 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, 변경사항을 바로 확인할 수 있는 핫 리로드, 중간 결과를 확인할 수 있는 디버거, 기존 기능을 보호하는 테스트 코드. 이 모든 것들이 당신의 실험실을 구성하는 도구들이다.

중요한 것은 도구 자체가 아니라 도구를 사용하는 마음가짐이다. "빨리 확인하고, 빨리 배우고, 빨리 조정한다"는 베타 요리사의 철학 말이다.

Resulting Context

TinyExperiment를 습관화하면 복잡한 문제 앞에서도 당황하지 않게 된다. 큰 산도 작은 돌들로 이루어져 있고, 복잡한 시스템도 작은 부분들로 나누어 이해할 수 있다는 것을 안다. 실패를 두려워하지 않게 되고, 오히려 실패에서 배우는 것에 익숙해진다.

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

Related Patterns

* Enables: BabyStep, UseAbduction, HereAndNowDebugging * Used by: TddIsDesignActivity, PiecemealGrowthCenterFirst * Complements: ShortFeedbackCycle, MicroCommit

See Also

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

CategoryPattern