두 가지 기준 법칙: 어떤 코딩 아이디어에 시간을 쓸지 골라내는 아주 작은 시스템

모든 개발자는 이 느낌을 안다. 노트도, 백로그도, 머릿속도 아이디어로 넘쳐난다.

성가신 반복 작업을 자동화하는 스크립트
사이드 프로젝트에 넣어보고 싶은 새 기능
하면 확실히 코드가 깨끗해질 것 같은 리팩터링
어쩌면 대박이 될지도 모르는 과감한 실험

문제는 아이디어가 부족해서가 아니다.

진짜 문제는 어떤 아이디어에 시간을 쓸 가치가 있는지를 고르는 일이다.

여기서 등장하는 것이 두 가지 기준(Threshold) 법칙이다. 이 작은 시스템은 아이디어를 빠르게 거르도록 도와줘서, 진짜 중요한 것에 시간을 쓰게 하고 나머지에 대해 쓸데없이 고민하는 일을 멈추게 해준다.

핵심 개념: 두 개의 기준선, 하나의 단순한 결정

대부분의 우선순위 조언은 임팩트(영향력) vs. 노력(에포트) 관점에서 생각하라고 말한다. 유용하긴 하지만, 막연하다. 두 가지 기준 법칙은 이걸 좀 더 구체적인 형태로 만든다.

당신은 두 개의 분명한 기준선을 만든다:

임팩트 기준선(Impact threshold) – 아이디어가 진지하게 시간과 에너지를 쏟을 만한 최소한의 영향력은 어디까지인가?
노력 기준선(Effort threshold) – 임팩트가 낮은 아이디어에 쓸 수 있는 최대 노력은 어느 정도인가?

그리고 이 두 기준에 비춰 보았을 때, 다음 두 부류의 아이디어만 실행한다:

임팩트가 아주 큰 아이디어 – 어느 정도 큰 노력이 들어가더라도 할 만한 것들
노력이 아주 적게 드는 아이디어 – 임팩트가 다소 작더라도 금방 해볼 수 있는 것들

이상적으로는 임팩트는 높고 노력은 적은 아이디어가 최고지만, 그런 건 드물다. 그걸 전제로 계획을 세우면 안 된다.

나머지 아이디어는 보류(park) 하거나 버린다(drop).

임팩트–노력 축을 시각적인 대시보드로 만들기

이걸 더 구체적으로 만들려면, 간단한 임팩트–노력 매트릭스(Impact–Effort Matrix) 를 사용하면 된다. 2x2 격자를 그리거나, 디지털 보드로 만들어도 좋다.

X축: 노력(Effort, 낮음 → 높음)
Y축: 임팩트(Impact, 낮음 → 높음)

각 사분면(Quadrant)에 라벨을 붙인다:

임팩트 높음 / 노력 낮음 → 바로 실행
임팩트 높음 / 노력 높음 → 일정에 넣고, 계획하고, 시간을 보호
임팩트 낮음 / 노력 낮음 → 노력 기준선 이하면 틈날 때 기회적으로 실행
임팩트 낮음 / 노력 높음 → 가차 없이 버리기

여기서 임팩트 기준선은 수평선이다. 이 선보다 임팩트가 낮은 아이디어는 정말 싸게(거의 공짜에 가깝게) 할 수 있을 때만 의미가 있다.

노력 기준선은 수직선이다. 이 선보다 더 많은 노력이 든다면, 그만한 상당한 임팩트가 있어야 정당화된다.

새로운 아이디어가 떠오를 때마다, 매트릭스에 빠르게 찍어본다:

임팩트 높음 / 노력 낮음에 떨어진다면 → 다음에 할 일로 바로 가져온다.
임팩트 높음 / 노력 높음이라면 → 프로젝트 블록으로 잡아 캘린더에 일정으로 넣는다.
임팩트 낮음 / 노력 낮음이라면 → 정말 작고 여유가 있을 때만 한다.
임팩트 낮음 / 노력 높음이라면 → 과감히 “안 한다”고 결정한다.

이 매트릭스는 아이디어를 분류(triage)하는 시각적 대시보드가 된다.

아이디어 분류를 위한 2분 규칙

우선순위에서 가장 큰 함정은 잘못 고르는 것이 아니다. 아예 결정을 안 하는 것이다.

자기 자신과 끝없는 논쟁에 빠지지 않으려면, 2분 규칙을 써라:

어떤 아이디어에 대해 2분 안에 합리적인 결정을 내릴 수 있겠다 싶으면, 즉시 결정한다.

의미하는 바는 간단하다:

2분 안에 임팩트(대략), 노력(대략)을 추정한다.
매트릭스에 찍는다.
기준선을 적용한다.
그리고 결정한다: 한다(Do), 일정에 넣는다(Schedule), 보류한다(Park), 버린다(Drop).

어떤 아이디어가 임팩트는 낮고 노력은 많이 드는 쪽으로 명확히 보인다면, 죄책감 없이 버린다. 임팩트가 크고 노력도 감당할 만하다면, 전용 시간을 잡아 일정에 넣는다. 작고, 시도해도 쉽게 되돌릴 수 있는 것이라면, 일단 해보는 쪽으로 기울어도 좋다.

목표는 완벽한 정확도가 아니다. 목표는, 절대 진지하게 하지도 않을 “언젠가 할지도” 아이템들로 가득 찬 백로그를 피하는 것이다.

되돌릴 수 있는지 따지는 필터: 싼 실험에 편향 걸기

어떤 아이디어는 위험하다. 프로덕션을 망칠 위험이 있어서가 아니라, 시간을 엄청 잡아먹고 끝에 가서 별 성과가 없을 수 있어서 위험하다.

이럴 때 도움이 되는 게 되돌릴 수 있는지(Reversibility) 필터다.

어떤 아이디어를 시도하는 비용이 싸고, 쉽게 되돌릴 수 있다면, 빠른 실험 쪽으로 편향을 둔다.

실제 상황에서는 이렇게 보일 수 있다:

리팩터링 실험을 위해 별도 Git 브랜치를 하나 파서 진행한다.
풀 시스템을 만들기보다 작은 프로토타입 스크립트를 먼저 작성한다.
기능 전체를 구현하기보다, Feature Flag 뒤에 최소한의 버전(MVP)을 붙여서 테스트한다.

스스로에게 이렇게 물어본다:

이 아이디어의 핵심을 1–2시간 안에 테스트해볼 수 있는가?
실패해도 그냥 통째로 버리고 원상복귀할 수 있게 격리할 수 있는가?

둘 다 “그렇다”라면, 이 아이디어는 전체 버전이 크더라도 매트릭스에서 ‘노력 낮음’ 쪽으로 더 가깝게 볼 수 있다.

이렇게 하면, 거대한 프로젝트에 인생을 갈아 넣지 않고도 실험의 갯수와 속도를 늘릴 수 있다.

시간을 보호하기: 20% 룰에서 가져오기

구글 같은 회사들은 엔지니어에게 자율 프로젝트를 할 수 있도록 **“20% 시간(20% time)”**이라는 개념을 도입해 유명해졌다.

이 아이디어를 개인 단위에서도 그대로 가져올 수 있다.

한 주 중 일부를 고정된, 보호된 시간 블록으로 잡아서, 기준선을 통과한 업사이드가 큰 코딩 실험만을 위해 쓴다.

예를 들면:

주 1회 오후 시간 한 블록 (예: 금요일 1–5시)
또는 주 2회 딥 워크(Deep Work) 블록 (예: 화/목 오전)

이 시간에는 이런 것들만 한다:

임팩트는 크고, 노력이 합리적이라서 이미 일정에 올려 둔 아이디어
기준선을 통과한 되돌리기 쉬운 실험들

버그 픽스, 사소한 정리, 이메일/메신저 확인은 금지. 이 시간은 의도적인 실험을 위한 전용 차선이다.

이런 작은 실험들이 가끔 엄청난 결과로 이어진다. AdSense나 Google News 같은 것도 원래는 사이드 프로젝트나 내부 실험에서 시작됐다.

차이는 하나다. 그런 아이디어들에는 **실제로 시도해 볼 수 있는 ‘보호된 차선’**이 있었다는 것.

직관에만 기대는 방식 대신, 아주 작은 의사결정 시스템 갖추기

많은 개발자는 보통 이런 식으로 결정한다:

“이거 좀 멋져 보이는데, 한번 해볼까.”
“이거 짜증 나는데, 언젠가 고쳐야겠다.”
“이번 주말에 새 프레임워크 좀 만져볼까.”

개별 결정 하나하나만 보면, 직관도 괜찮을 수 있다. 하지만 이게 몇 달, 몇 년 쌓이면 결과는 이렇기 쉽다:

아무도 안 쓰는, 반쯤만 만들어진 툴들
고생은 심하게 했는데 실제 성과는 거의 없는 과도한 개선
시작하기엔 너무 커 보인다는 이유로 방치된, 임팩트 큰 아이디어들

여기서 중요한 건, 작지만 일관된 의사결정 시스템이 이런 패턴을 이긴다는 점이다. 거창할 필요도 없다.

임팩트–노력 매트릭스를 대시보드로 쓰고
두 가지 기준선(최소 임팩트, 최대 허용 노력)을 정하고
2분 규칙으로 빠르게 결정하고
되돌릴 수 있는지 필터로 작고 싼 실험 쪽으로 편향을 두고
기준을 통과한 아이디어에게 매주 보호된 시간을 배정한다.

이 작은 구조만 있어도 쓸데없는 고민이 줄어들고, 언젠가 크게 터질 수도 있는 실험을 실제로 끝까지 밀어붙일 확률이 훨씬 높아진다.

15분 안에 하는 실전 세팅

두 가지 기준 법칙은, 약간의 마찰만 감수하면 오늘 바로 적용할 수 있다.

매트릭스를 만든다
- 화이트보드, Notion 보드, Trello, 또는 문서에 2x2 표를 하나 만들어도 된다.
- 각 사분면에 임팩트/노력 기준으로 라벨을 붙인다.
기준선을 정의한다 (대략이면 충분하다)
- 임팩트 기준선: “나/팀/사용자의 반복적인 고통을 눈에 띄게 줄여준다면, 할 가치가 있다.”
- 노력 기준선: “1–2일 이상 걸린다면, 분명히 임팩트가 높아야 한다.”
현재 가지고 있는 아이디어 리스트를 몽땅 매트릭스로 옮긴다
- 각 아이디어마다, 직감적으로 임팩트/노력이 높은지 낮은지만 빠르게 정한다.
- 고민하지 말고, 여기서도 2분 규칙을 지킨다.
결과에 따라 행동한다
- 임팩트 높음 / 노력 낮음 → 1–2개를 골라 바로 다음 작업으로 한다.
- 임팩트 높음 / 노력 높음 → 캘린더에 프로젝트 블록으로 잡는다.
- 임팩트 낮음 / 노력 낮음 → 아주 작거나 재미있을 때만 골라서 한다.
- 임팩트 낮음 / 노력 높음 → 삭제하거나 아카이브로 보내 버린다.
실험 전용 시간을 블록으로 잡는다
- “20% 시간”에 해당하는 반복 일정(recurrence)을 캘린더에 만든다.
- 이 시간에는 기준을 통과한 아이디어만 올려둔다.

이 가벼운 분류 작업을 주 1회, 혹은 아이디어 리스트가 시끄러워졌을 때마다 반복하면 된다.

결론: 옳은 일을 하기 쉽게 만드는 시스템

다음에 뭘 코딩할지 결정하는 데, 거대한 생산성 시스템이 꼭 필요한 것은 아니다.

두 가지 기준 법칙을 쓰면, 당신은:

임팩트가 크거나, 노력이 아주 적게 드는 일(가장 좋기는 둘 다)을 중심에 두고
임팩트–노력 매트릭스를 단순하고 직관적인 가이드로 삼고
2분 규칙으로 결정을 질질 끌지 않고
되돌릴 수 있는지 필터로 값싼 실험을 우선시하고
가장 가능성이 큰 아이디어에 꾸준한 전용 시간을 배정할 수 있다.

결과적으로 얻는 것은 단순히 더 나은 우선순위가 아니라, 관성(momemtum) 이다.

실험을 더 많이 내보내게 되고, 막다른 길에 이르는 데 쓰는 시간은 줄어든다. 그리고 가장 업사이드가 큰 아이디어들이 노트 속에서만 영원히 잠들지 않고, 실제 세상에 등장할 기회를 얻게 된다.

시작은 작게 해도 된다. 매트릭스를 대충 그린다. 기준선을 정한다. 그리고 당장 떠오르는 아이디어 다섯 개만 먼저 분류해 본다. 이 정도면, 이 작은 시스템이 돌아가기 시작하기에 충분하다.