ShortLeash

주니어 개발자들을 위한 패턴 언어 - 추측의 꼬리가 길어지기 전에 빠르게 확인하여 미궁을 탈출하는 법

The Story: The Long Chain of Assumptions vs. The Quick Snap

두 명의 개발자, 민수와 하나가 '데이터가 간헐적으로 깨지는 버그'를 조사하고 있다.

민수의 추리 (The Long Leash): 민수는 자리에 앉아 코드와 로그를 뚫어지게 쳐다보며 거대한 가설을 세웠다. "음, A 모듈에서 데이터를 보낼 때 네트워크 타임아웃이 나고, 그게 B 데이터베이스의 트랜잭션 롤백과 겹치면서, C 캐시 서버의 인덱스가 꼬이는 거 아닐까? 아, 그러려면 D 설정 파일의 타임아웃 값도 확인해야겠네." 민수는 1시간 동안 이 복잡한 추론 사슬을 머릿속으로 조립했다. 하지만 그 사슬의 첫 번째 고리(네트워크 타임아웃)가 틀렸다면 나머지 1시간의 고민은 모두 쓰레기가 된다. 민수는 추측의 끈(Leash)을 너무 길게 늘어뜨렸다.

하나의 추리 (The Short Leash): 하나는 가설을 세우자마자 끈을 잡아당겼다. "네트워크 문제라고? 그럼 먼저 A 모듈에서 에러가 나는지부터 확인하자." 하나는 2분 만에 A 모듈의 로그를 확인했고, 네트워크는 정상임을 알아냈다. "네트워크는 아니네. 그럼 다음은 데이터베이스인가?" 하나는 추측의 사슬이 두 마디 이상 길어지기 전에 매번 확인을 거쳤다. 그녀는 짧은 확인을 반복하며 15분 만에 진짜 원인을 찾아냈다.

Context

버그를 잡고 있거나(DetectiveWork), 복잡한 시스템의 동작 방식을 파악 중이다. 몇 가지 단서를 찾았고, 머릿속에서 "왜 이런 일이 벌어지는지"에 대한 시나리오가 써지기 시작한다.

일상적인 상황:

• "아마 이럴 거야"라는 생각을 바탕으로 수만 줄의 코드를 읽어 내려간다.
• 하나의 가설 위에 다른 가설을 쌓아 올리며 복잡한 소설을 쓴다.
• 한참을 고민한 뒤에야 "아, 아까 그 가정이 틀렸었네"라며 허탈해한다.
• 원인을 찾기도 전에 거대한 수정 계획을 세운다.

당신은 지금 추측의 끈을 너무 길게 풀어서, 버그라는 사냥감을 놓치고 길을 잃었다.

Problem

확인되지 않은 가설을 바탕으로 추론을 길게 이어가면 불확실성이 기하급수적으로 증폭된다.

• 불확실성의 복리: 가설 A가 맞을 확률이 70%고, 그 위에서 세운 가설 B가 맞을 확률이 70%라면, 두 가설이 모두 맞을 확률은 49%로 떨어진다. 사슬이 길어질수록 진실에서 멀어진다.

• 시간 낭비: 틀린 가정 위에서 보낸 시간은 아무런 가치가 없다.

• 인지적 매몰: 복잡한 가설을 세우고 나면, 그 가설이 틀렸다는 증거가 나와도 그것을 부정하고 싶어진다.

Solution

가설을 세웠다면, 다음 가설로 넘어가기 전에 "가장 빠르고 직접적인 방법"으로 그 가설을 즉시 검증하라.

추측의 끈(Leash)을 짧게 쥐고, 수시로 잡아당겨 확인해야 한다.

Principle 1: Smallest Jump (최소한의 점프)

한 번에 한 단계만 추측하라.

• "A 때문에 B가 되고 결국 C가 될 거야"라고 생각하지 마라.
• "A가 범인인가?"를 먼저 확인하라. 맞다면 그 다음 단계를 고민하라.

Principle 2: Fail Fast, Verify Faster (빠른 실패, 더 빠른 확인)

가설을 증명하는 것보다 **반증(Falsify)**하는 것이 더 빠를 때가 많다.

• "이게 문제라면, 여기서 이 로그가 찍혀야 해."
• 로그를 찍었는데 안 찍힌다? 그럼 그 가설은 즉시 버려라. 끈을 바로 잡아당겨라.

Principle 3: No Reasoning without Evidence (증거 없는 추론 금지)

눈으로 확인한 사실(Evidence)만이 다음 추론의 발판이 될 수 있다.

• PresentMoment에서 배운 대로, 실행 결과(Fact)를 확인하기 전까지는 모든 것이 소설임을 명심하라.

Principle 4: Use Tiny Experiments (실험 활용)

TinyExperiment를 사용하여 가설을 확인하라.

• 코드를 고치기 힘들다면, 특정 변수 값을 강제로 바꿔서(Mocking) 현상이 사라지는지 확인하는 것도 좋은 방법이다.

Real Examples

Example 1: The Config Mystery

"설정 파일이 안 읽히는 것 같아요. 그래서 DB 연결이 안 되고, 커넥션 풀이 꽉 차서..." Short Leash: "설정 파일 경로를 출력(Print)해봐." -> 10초 만에 오타 발견. 그 뒤의 복잡한 커넥션 풀 추론은 필요 없어짐.

Example 2: The API Lag

"외부 API가 느려서 우리 서버 스레드가 부족해지는 것 같아요." Short Leash: "그 API 호출 부분만 주석 처리하고 가짜 응답을 리턴하게 해봐. 그래도 서버가 느려?"

• -> "어, 그래도 느리네요?" -> "그럼 외부 API 문제가 아니네. 다른 데를 보자."

Common Pitfalls

"I'm 99% sure" (99% 확실해요)

이 생각이 가장 위험하다. 99% 확실한 것도 1초 만에 확인할 수 있다면 확인하라. 버그는 항상 그 1%의 예외에서 나온다.

Professional Pride (전문가적 자존심)

"이 정도는 코드만 봐도 알지." 숙련된 탐정일수록 자신의 직관을 믿지 않고 증거를 찾는다.

Analysis Paralysis (분석 마비)

확인하기가 귀찮아서 머릿속으로만 계속 시나리오를 돌리는 것. 움직여라. 로그 한 줄 찍는 것이 1시간의 고민보다 가치 있다.

Connection to Other Patterns

• DetectiveWork - ShortLeash는 수사의 효율을 높이는 핵심 기술이다. 효율성

• TinyExperiment - 짧은 끈을 확인하기 위한 구체적인 수단이다. 도구

• PresentMoment - 지금 일어나는 사실에 집중해야 끈을 짧게 유지할 수 있다. 기반

• TightLoop - 환경이 갖춰져 있어야 끈을 자주 잡아당길 수 있다. 전제 조건

Signs of Success

• 디버깅 중에 "아, 이게 아니었네"라고 깨닫는 시점이 매우 빨라진다.
• 가설을 검증할 때마다 불확실성이 눈에 띄게 줄어든다.
• 팀원들과 대화할 때 "이러이러할 것 같아요"보다 "확인해보니 이렇습니다"라고 말하게 된다.
• 복잡한 추론 없이도 버그의 실체에 빠르게 접근한다.

The Ultimate Insight

추측은 멀리 갈수록 길을 잃는다. 확인은 자주 할수록 목적지에 가까워진다.

사냥개를 멀리 풀어놓으면 사냥개가 무엇을 쫓는지 알 수 없다. 짧은 끈으로 사냥개를 통제하며 함께 걸어가라. 진실은 멀리 있지 않다. 바로 당신의 다음 확인(Verification) 속에 있다.

CategoryPatternLanguage CategoryProgramming CategoryDebugging CategoryProblemSolving