러버덕 노트: 키보드를 치기 전에 어려운 문제를 푸는 초저기술 시스템

대부분의 개발자는 러버덕 디버깅(rubber duck debugging) 이야기를 한 번쯤은 들어봤을 겁니다. 자기 코드 한 줄 한 줄을 고무 오리(혹은 아무 물건)에게 설명하다 보면, 설명 도중에 그동안 놓쳤던 버그가 갑자기 눈에 들어오는 방식이죠.

“러버덕 노트”는 이 아이디어를 그대로 가져와서 생각 정리용 초경량 시스템으로 확장한 것입니다. 코드를 다 짠 뒤에만 오리에게 설명하는 대신, 코드를 쓰기 전부터 오리와 함께 작업합니다. 그리고 그 과정을 종이 위에 남깁니다.

겉으로 보면 너무 단순해서 별 의미 없어 보일 수 있습니다. 하지만 바로 그게 포인트입니다. 저기술(low-tech), 고레버리지(high‑leverage). 값싼 공책 한 권과 펜 하나만으로도, 어려운 문제를 대하는 방식이 달라지고, 쓸데없는 소모를 줄이며, 더 명확하고 견고한 코드를 쓰도록 도와줍니다.

이 글에서는 러버덕 노트가 무엇인지, 어떻게 작동하는지, 그리고 이를 일상적인 개발 습관으로 만드는 방법을 살펴보겠습니다.

러버덕 디버깅에서 러버덕 ‘생각법’으로

러버덕 디버깅은 아주 단순한 사실에 기반합니다. 자기가 하는 일을 일상 언어로 설명하면, 자신의 이해에 있는 빈 구멍이 드러난다는 것이죠.

예를 들어 이렇게 시작할 수 있습니다.

“자, 오리야, 이 함수는 파일을 읽고, JSON을 파싱해서, 사용자 리스트를 반환하는 거야…”

그렇게 중간쯤 설명하다가, 빈 파일을 처리하지 못한다는 사실을 깨닫거나, 데이터 포맷을 잘못 이해했다는 걸 알거나, 엣지 케이스를 완전히 잊고 있었다는 걸 눈치채기도 합니다.

러버덕 노트는 이 연습을 두 가지 방향으로 확장합니다.

코드를 짠 뒤가 아니라, 짜기 전에 자신의 생각을 설명한다.
말로만 하지 않고, 반드시 글로 쓴다.

글로 쓰면 속도가 약간 느려집니다. 그런데 그 ‘느려짐’ 덕분에 잘못된 전제를 발견할 여유가 생깁니다. 막연히 그렇겠지 하고 느끼던 것 대신, 내가 이 문제에 대해 정확히 무엇을 믿고 있는지를 명시적으로 결정해야만 하죠.

러버덕 노트란 무엇인가?

가장 단순하게 말하면, 러버덕 노트는 다음과 같습니다.

문제를 풀 때에만 전용으로 사용하는 종이 공책(또는 A4, 메모지)
호기심은 많지만 코드베이스와 도메인 지식은 전혀 없는 오리에게 설명하듯, 계획·제약·사고 과정을 풀어서 적는 공간
무엇을 시도했고, 왜 그렇게 했으며, 결과가 어땠는지를 기록하는 진행 로그

여기서 쓰는 건 감정 일기가 아닙니다. 생각의 흐름을 기록하는 일지에 가깝습니다.

지금 내가 풀려는 문제는 무엇인가?
내가 확실히 알고 있는 건 무엇인가?
내가 검증 없이 가정하고 있는 것은 무엇인가?
언제 “끝났다”고 말할 수 있는가?
지금 당장 할 수 있는 가장 작은 다음 단계는 무엇인가?

이 노트는 일종의 **저기술 인지 보조도구(cognitive aid)**가 됩니다. 컴파일도 안 되고, 클라우드 동기화도 안 되지만, 일을 하는 동안 뇌를 쓰는 방식을 깊이 바꿔 줍니다.

디지털 세상에서 왜 굳이 종이인가?

우리는 보통 키보드부터 두드리고 싶어 합니다. 어쨌든 “진짜 일”은 에디터 안에서 일어나는 것처럼 느껴지니까요.

하지만 꼭 그렇지는 않습니다.

에디터를 켜자마자 코드를 치기 시작하면, 사실상 세 가지 일을 동시에 하고 있는 셈입니다.

진짜 문제가 무엇인지 규정하고,
그 문제를 풀 수 있는 설계를 생각하고,
그 설계를 구체적인 코드로 번역합니다.

이건 뇌에 상당한 부담을 줍니다. 그래서 이런 일이 벌어집니다.

파일과 탭 사이를 왔다 갔다 하며 시간을 보낸다.
같은 함수와 로직을 자꾸 갈아엎는다.
바쁘게 움직인 것 같은데, 실제로는 크게 진전이 없다.

반대로, 생각을 종이 위에서 먼저 하는 방식은 이 작업들을 분리합니다.

먼저, 문제를 명료하게 정의한다.
그다음, 해결책의 윤곽을 설계한다.
그리고 나서야 구현에 들어간다.

이렇게 하면 컨텍스트 전환이 줄고, 즉흥적인 반쪽짜리 실험이 줄어들며, 결과적으로는 디버깅이 더 빨라지고 구현이 더 깔끔해지는 경우가 많습니다.

문제를 논문 읽듯 대하라

도움이 되는 비유 하나. 새로운 작업을 시작할 때마다, 연구 논문을 읽는 것처럼 접근해 보세요. 코드를 보기 전에, 최소한 세 가지는 분명히 알고 싶을 겁니다.

초록(Abstract) – 우리가 이루려는 목표는 무엇인가?
노트에 한두 문장으로 적습니다.

“목표: 사용자가 이메일로 5분 이내에 안전하고 신뢰성 있게 비밀번호를 재설정할 수 있게 한다.”
서론(Introduction) – 현재 맥락과 제약 조건은 무엇인가?
다음을 적어 봅니다.
- 기존 시스템의 동작
- 관련된 의존성(서비스, 라이브러리, 인프라 등)
- 제약 사항(성능, 보안, 호환성, 마감일 등)
예시:

“이미 사용자 이메일은 저장되어 있지만, 토큰 시스템은 없음. 기존 SMTP 제공업체를 그대로 사용해야 함. 이메일이 등록되어 있는지 여부가 외부에 드러나면 안 됨.”
결과(Results) – 무엇을 만족해야 ‘성공’이라고 할 수 있는가?
성공 상태를 구체적으로 정의합니다.

“유효한 이메일을 입력하면 2분 이내에 재설정 링크를 받는다. 링크는 1회용이며 15분 뒤 만료된다. 잘못된 이메일이나 가입되지 않은 이메일을 넣어도 응답 메시지는 항상 동일한 일반 문구로 보낸다.”

이 세 가지를 종이에 적어 두면, 작업의 기준점이 생깁니다. 그러면 엉뚱한 사이드 퀘스트로 빠지거나, 실제 요구와 맞지 않는 과도한 설계를 할 가능성이 줄어듭니다.

러버덕 노트 활용 방법: 단계별 가이드

지금 당장 적용할 수 있는 간단한 워크플로를 소개합니다.

1. 문제마다 새 페이지를 연다

페이지 맨 위에 다음을 적습니다.

날짜
짧은 문제 이름 (예: “비밀번호 재설정 플로우”)
한 문장짜리 목표 (앞서 말한 ‘초록’)

이렇게 하면 이 페이지가 오로지 이 문제 하나만을 위한 공간이라는 경계가 생깁니다.

2. 오리에게 문제를 설명한다

일상적인 한국어(또는 본인이 가장 편한 언어)로 다음을 적어 봅니다.

지금 뭐가 고장 났거나, 빠져 있거나, 모호한가?
우리가 원하는 이상적인 동작은 무엇인가?
이게 전체 시스템/프로덕트 안에서 어떤 맥락을 가지는가?

오리가 똑똑하긴 하지만, 당신의 코드베이스도, 회사 도메인도 전혀 모른다고 상상하세요. 가능하면 전문용어를 줄이고, 써야 한다면 간단히 풀어서 적습니다.

3. ‘아는 것’과 ‘가정하는 것’을 나눈다

두 개의 컬럼 또는 불릿 리스트를 만듭니다.

Known(사실): 로그, 테스트 실패, 유저 리포트 등 확인된 정보
Assumed(가정): 사실일 것 같지만, 아직 직접 확인하지 않은 것들

그다음, 가정들 중에서 우선적으로 검증해야 할 것 몇 개에 표시를 합니다. 이 단계만 잘해도, 엉뚱한 가설에 몇 시간을 날리는 일을 크게 줄일 수 있습니다.

4. 문제를 더 작은 단계로 쪼갠다

이제 거대한 뒤엉킨 문제를, 연속된 작은 질문/작업들로 나눕니다. 예를 들어:

버그를 로컬에서 재현한다.
어느 API 엔드포인트가 실제로 실패하는지 확인한다.
요청/응답 페이로드를 살펴본다.
최소한의 failing test(실패하는 테스트)를 추가한다.

지금 단계에서 상세 코드를 쓰려는 게 아닙니다. 조사/구현 계획을 세우는 겁니다.

5. 가능한 접근법을 스케치한다

1~3개의 후보 솔루션을 적어 봅니다. 각 접근법마다 오리에게 짧게 피치하듯 설명합니다.

핵심 아이디어는 무엇인가?
왜 이 방법이 통할 것 같은가?
어떤 트레이드오프(장단점, 리스크)가 있는가?

예를 들면:

“접근 A: 비밀번호 재설정 토큰용 새 테이블을 추가한다. 장점: 책임과 데이터가 분리되어 명확하다. 단점: 마이그레이션 필요, 관리해야 할 요소가 늘어난다.”

이렇게 설명하는 과정에서, ‘당연히 이게 답이지’라고 생각했던 솔루션이 사실은 취약하거나 지나치게 복잡하다는 게 드러나기도 합니다.

6. 다음에 할 구체적인 행동 하나를 정한다

이론만 쌓다가 길을 잃지 않도록, 계획 단계의 끝에서는 반드시 다음에 할 일 한 가지를 정합니다.

예:

“버그를 재현하는 failing test를 먼저 작성한다.”
“에러 직전에 페이로드를 로그로 찍어 본다.”
“접근 A를 작은, 독립된 함수 하나로 프로토타입해 본다.”

이제서야 키보드를 잡고 IDE나 에디터로 넘어갑니다.

7. 무엇을 시도했고, 무슨 일이 일어났는지 기록한다

작업을 진행하면서, 주기적으로 노트로 돌아옵니다.

방금 무엇을 시도했는지
예상 밖의 동작이나 테스트 결과는 무엇이었는지
막힌 접근은 과감히 지우거나 ‘dead end’라고 표시하기

이렇게 하면 사고 과정의 히스토리가 쌓입니다. 회의, 메신저, 다른 작업 등으로 끊겼다가 돌아와도, 노트가 곧 당신의 기억과 컨텍스트가 되어 줍니다.

눈에 보이는 진전: 페이지와 스트릭이 주는 동기부여

러버덕 노트의 부수 효과 하나는, 진전을 눈으로 볼 수 있게 해 준다는 점입니다.

페이지가 한 장씩 차곡차곡 채워진다는 건 곧, 당신이 다음을 했다는 증거입니다.

문제를 명료하게 정의했다.
제약을 고려했다.
여러 아이디어를 실제로 테스트해 봤다.

이를 기반으로 다음과 같은 것들을 추적해 볼 수 있습니다.

일일 페이지 수: 오늘은 최소 한 페이지 이상 문제에 대해 써 봤는가?
문제별 스트릭: 같은 문제를 며칠 연속으로 전진시켰는가?

달력에 스트릭이 쌓이듯이, 노트의 페이지가 늘어나는 모습은 동기를 크게 북돋워 줍니다. ‘오늘 아무것도 못 한 것 같은데…’라는 날에도, 이전 페이지들을 넘겨 보면 사실은 꽤 많은 생각과 시도를 해 왔다는 것을 눈으로 확인할 수 있습니다.

왜 효과가 있는가: 느리게 해서 오히려 빨라지는 방법

러버덕 노트의 힘은 몇 가지 단순한 심리적 효과에서 나옵니다.

글로 쓰면 속도가 살짝 느려진다 → 그 틈에 논리의 허점과 정보의 빈칸이 보인다.
가상의 청자(오리)에게 설명하는 행위 → 애매한 부분을 대충 넘어갈 수 없으니, 표현을 명확히 해야 한다.
키보드와 물리적으로 분리된 상태 → “일단 뭐라도 쳐 보고 보자”는 충동을 줄이고, 이해하지 못한 채 코드를 두들기는 일을 막아 준다.
지속적인 글 기록 → 같은 사실을 여러 번 다시 파악하느라 시간을 낭비하지 않는다.

결과적으로, 앞단에 생각 시간을 조금 더 투자해서, 뒷단에 훨씬 더 많은 시간을 절약하게 됩니다. 무작정 찍어 보는 실험, 되풀이되는 리팩터링, “도대체 이게 예전에는 어떻게 돌아갔던 거지?” 같은 순간이 줄어듭니다.

오늘 당장 시작하는 법

특별한 노트나 진짜 고무 오리가 필요하지 않습니다. 시작을 위해 필요한 건:

아무 공책이나 스케치북(아니면 인덱스 카드도 좋습니다)
그리고 아주 단순한 규칙 하나: “새로운, 사소하지 않은 문제 = 먼저 노트 한 페이지”

일주일만 이렇게 실험해 보세요.

매일 의미 있는 버그나 기능 한 가지를 고른다.
코딩을 시작하기 전에 10–15분 정도 노트와 씨름한다.
문제를 설명하고, 가정을 적고, 대략적 계획을 스케치한다.
작업하면서 계속 노트를 참고하고 업데이트한다.

그러고 나서 스스로에게 물어보세요.

오늘 덜 헤맸는가?
내가 지금 뭘 하고 있는지, 전보다 더 분명하게 느껴졌는가?
디버깅 속도가 빨라지거나, 코드가 더 깔끔해졌는가?

대답이 **조금이라도 ‘그렇다’**라면, 계속할 이유는 충분합니다.

결론: 어려운 문제를 위한 아주 단순한 도구

러버덕 노트는 구성 요소만 보면 너무 단순합니다. 나, 펜 한 자루, 종이 몇 장, 그리고 상상의 오리.

하지만 단순함이 바로 핵심입니다. 머릿속에서만 빙글빙글 돌던 생각을 종이 위로 꺼내 적는 행위를 통해, 우리는 다음을 얻게 됩니다.

키보드를 치기 전에 문제를 선명하게 정의하고,
잘못된 전제를 초기에 바로잡으며,
거대한 문제를 작은 단계들로 나누고,
사고 과정과 진전 상황의 로그를 축적합니다.

수많은 복잡한 툴, 프레임워크, AI 어시스턴트가 넘쳐나는 시대에도, 이 저기술 시스템은 여전히 가장 신뢰도 높은 사고 도구 중 하나입니다. 더 또렷하게 생각하고, 더 좋은 코드를 쓰게 해 주는 방법이죠.

다음에 어려운 문제를 만나면, 에디터부터 열지 마세요. 먼저 노트를 여세요.

그리고 차분하게, 오리에게 하나씩 설명해 주세요.