- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며: 가장 바쁜 사람이 가장 인정받지 못할 때
- 1. 임팩트란 무엇인가
- 2. 중요한 일 vs 긴급한 일
- 3. 노력 대비 효과를 따지는 프레임워크
- 4. 하지 않을 일을 정하는 용기
- 5. 로컬 최적화의 함정
- 6. 임팩트를 측정하고 소통하기
- 7. 임팩트 큰 일을 먼저 찾아내는 법
- 8. 임팩트를 잘못 다루는 안티패턴
- 9. 사례: 우선순위를 바꿔 분기를 살린 팀
- 10. 균형 — 임팩트가 전부는 아니다
- 11. 실전 체크리스트
- 12. 임팩트를 습관으로 — 주간 리추얼
- 마치며
- 참고 자료
들어가며: 가장 바쁜 사람이 가장 인정받지 못할 때
두 명의 엔지니어가 있습니다.
A는 늘 바쁩니다. 슬랙 알림에 즉각 반응하고, 모든 회의에 참석하고, 들어오는 모든 버그를 처리합니다. 하루가 꽉 차 있고, 야근도 잦습니다. 누가 봐도 열심히 일합니다.
B는 어딘가 여유로워 보입니다. 어떤 요청은 정중히 거절하고, 어떤 회의는 빠지고, 하루의 큰 덩어리를 한 가지 일에 씁니다. 그런데 분기 말, 팀의 핵심 지표를 끌어올린 것은 B가 만든 기능이었습니다.
연말 평가에서 더 높은 평가를 받는 쪽은 보통 B입니다. 그리고 A는 억울해합니다. "나는 B보다 훨씬 많이 일했는데."
차이는 노력의 양이 아니라 방향입니다. A는 들어오는 일을 처리했고, B는 가장 큰 차이를 만들 일을 골라서 했습니다. 이 글은 그 "고르는 기술", 곧 임팩트로 우선순위를 정하는 법에 관한 것입니다.
"바쁜 것으로는 충분하지 않다. 개미도 바쁘다. 문제는 무엇으로 바쁜가이다." — Henry David Thoreau
1. 임팩트란 무엇인가
먼저 정의가 필요합니다. 임팩트는 "내가 한 일의 양"이 아니라 **"내 일이 만들어낸 결과의 크기"**입니다.
임팩트 = 결과의 크기 × 그 결과의 중요도
[작업량]과 [임팩트]는 다르다.
- 코드 1,000줄을 썼다 → 작업량
- 그 코드가 결제 실패율을 20% 낮췄다 → 임팩트
여기서 흔한 착각이 하나 있습니다. 노력과 임팩트를 동일시하는 것입니다. 우리는 고생한 만큼 결과가 나오기를 바라지만, 세상은 그렇게 공평하지 않습니다. 며칠을 갈아 넣은 리팩터링이 아무도 쓰지 않는 코드를 정리한 것일 수도 있고, 30분짜리 설정 변경이 수천 명의 사용자 경험을 바꿀 수도 있습니다.
임팩트를 따지는 첫걸음은 "이 일을 끝내면 무엇이 달라지는가?"를 묻는 것입니다. 답이 잘 떠오르지 않는다면, 그 일의 임팩트는 작을 가능성이 높습니다.
2. 중요한 일 vs 긴급한 일
드와이트 아이젠하워가 남긴 유명한 구분이 있습니다. "중요한 일은 좀처럼 긴급하지 않고, 긴급한 일은 좀처럼 중요하지 않다."
이를 2×2 매트릭스로 그리면 이렇습니다.
긴급함 긴급하지 않음
┌──────────────────┬──────────────────┐
중요함 │ Q1 위기/장애 │ Q2 전략/예방 │
│ 즉시 처리 │ ★ 여기에 투자 │
├──────────────────┼──────────────────┤
중요하지 │ Q3 잡음/방해 │ Q4 시간낭비 │
않음 │ 위임·축소 │ 제거 │
└──────────────────┴──────────────────┘
대부분의 사람은 Q1(긴급+중요)과 Q3(긴급+안 중요)에 끌려다닙니다. 긴급함은 즉각적인 자극을 주기 때문입니다. 알림이 울리고, 누가 부르고, 마감이 코앞입니다.
그러나 임팩트가 가장 크게 쌓이는 곳은 **Q2(중요하지만 긴급하지 않은)**입니다. 기술 부채를 줄이는 일, 자동화, 문서화, 더 나은 아키텍처 설계, 동료 멘토링 같은 것들. 이들은 오늘 안 해도 아무도 뭐라 하지 않지만, 쌓이면 판을 바꿉니다. 임팩트로 일하는 사람은 의식적으로 Q2에 시간을 떼어 둡니다.
3. 노력 대비 효과를 따지는 프레임워크
"중요하다"는 느낌만으로는 부족합니다. 여러 일 중 무엇을 먼저 할지 정하려면, 효과와 비용을 같은 자로 재야 합니다. 두 가지 널리 쓰이는 점수 모델을 봅시다.
3.1 ICE 스코어
빠르게 가늠할 때 좋은 모델입니다.
ICE = Impact(효과) × Confidence(확신) × Ease(쉬움)
각 항목을 1~10으로 매긴다.
- Impact: 성공하면 결과가 얼마나 큰가
- Confidence: 그 효과가 날 거라고 얼마나 확신하는가
- Ease: 얼마나 쉽게/빠르게 할 수 있는가
예를 들어 두 작업을 비교해 봅시다.
| 작업 | Impact | Confidence | Ease | ICE |
|---|---|---|---|---|
| 결제 재시도 로직 추가 | 9 | 8 | 7 | 504 |
| 관리자 페이지 UI 개편 | 5 | 7 | 3 | 105 |
직관적으로는 "UI 개편이 더 눈에 띄고 멋져 보여서" 끌릴 수 있지만, 점수는 결제 재시도 쪽을 가리킵니다. 적은 노력으로 큰 효과를 내기 때문입니다.
3.2 RICE 스코어
더 정교하게, 영향을 받는 규모(Reach)까지 넣은 모델입니다.
RICE = (Reach × Impact × Confidence) / Effort
- Reach: 일정 기간 동안 영향받는 사용자 수
- Impact: 1명당 효과의 크기(예: 3=큼, 1=보통, 0.5=작음)
- Confidence: 확신 정도(% 또는 0~1)
- Effort: 드는 노력(사람-개월 등)
RICE의 미덕은 Effort를 분모에 둔다는 점입니다. 즉 같은 효과라면 적은 노력으로 내는 일이 항상 이깁니다. 이것이 "지렛대(leverage)"의 핵심입니다. 임팩트가 큰 사람은 더 열심히 미는 사람이 아니라, 같은 힘으로 더 큰 바위를 움직일 지렛목을 찾는 사람입니다.
주의: 이 점수들은 정답이 아니라 대화의 도구입니다. 숫자를 맹신하지 말고, 팀이 함께 매기면서 가정을 드러내는 데 쓰는 것이 좋습니다.
4. 하지 않을 일을 정하는 용기
우선순위를 정한다는 것은 무엇을 먼저 할지 정하는 것이 아닙니다. 더 본질적으로는 무엇을 하지 않을지 정하는 것입니다.
"전략의 본질은 무엇을 하지 않을지 정하는 것이다."
— Michael Porter
모든 일을 다 하려는 순간, 우선순위는 사라집니다. 모든 것이 1순위라면 아무것도 1순위가 아닙니다. 그래서 임팩트로 일하는 사람은 "안 할 일 목록(not-to-do list)"을 의식적으로 관리합니다.
거절은 기술입니다. 무례하게 "안 합니다"가 아니라, 이유와 대안을 곁들여 거절합니다.
나쁜 예: "그건 제 일이 아니에요."
좋은 예: "지금 결제 이슈에 집중하고 있어서, 그 작업은 이번 주에 어려울 것 같아요.
다음 주에 다시 보거나, 더 급하시면 우선순위를 같이 조정해볼까요?
지금 결제 일을 멈추고 그걸 먼저 하는 게 팀에 더 나은지 함께 판단해보면 좋겠어요."
이렇게 하면 거절이 협상이 됩니다. 무엇을 포기하고 무엇을 얻을지 상대와 함께 따지는 것이죠.
5. 로컬 최적화의 함정
임팩트를 잘못 보면 빠지는 대표적 함정이 **로컬 최적화(local optimization)**입니다. 내 눈앞의 작은 영역만 최적화하느라, 전체로 보면 오히려 손해가 나는 경우입니다.
[로컬 최적화 예시]
내 모듈의 응답 속도를 200ms → 50ms로 개선했다. (뿌듯하다)
그러나 이 모듈은 전체 요청의 0.1%에서만 쓰인다.
사용자가 체감하는 변화는 사실상 0.
반면 가장 많이 쓰이는 모듈이 800ms인데 아무도 손대지 않았다.
여기를 200ms만 줄여도 전체 체감 속도가 확 달라진다.
로컬 최적화에 빠지는 이유는, 내가 통제할 수 있는 작은 영역이 더 안전하고 즐겁게 느껴지기 때문입니다. 큰 문제는 복잡하고 남들과 엮여 있어 불편합니다. 그래서 우리는 무의식적으로 쉽고 작은 일로 도망칩니다.
이를 피하려면 한 단계 위에서 봐야 합니다. "내 일이 시스템 전체, 팀 전체, 회사 전체의 목표에 얼마나 기여하는가?"를 늘 물어야 합니다. 가장 빠른 부품을 만드는 것보다, 가장 느린 병목을 찾는 것이 임팩트가 큽니다.
6. 임팩트를 측정하고 소통하기
6.1 측정 — 시작 전에 지표를 정하라
임팩트를 입증하려면, 일을 시작하기 전에 "무엇으로 성공을 잴 것인가"를 정해야 합니다. 끝나고 나서 지표를 찾으면 늦습니다.
[일 시작 전 정해둘 것]
목표 지표: 결제 성공률
현재 값(baseline): 94.2%
목표 값: 97% 이상
측정 방법: 결제 시도 대비 성공 로그, 주간 집계
이렇게 baseline을 먼저 기록해 두면, 나중에 "이만큼 좋아졌다"를 숫자로 말할 수 있습니다.
6.2 소통 — 한 일이 아니라 만든 결과를 말하라
임팩트는 만드는 것만큼이나 보이게 하는 것이 중요합니다. 묵묵히 큰일을 해도 아무도 모르면, 조직 차원에서는 그 일이 "없었던" 것과 비슷해집니다. 자기 자랑이 아니라, 팀이 무엇이 효과 있었는지 학습하게 만드는 일이기도 합니다.
핵심은 활동이 아니라 결과로 말하는 것입니다.
약한 표현(활동 중심):
"결제 모듈을 리팩터링하고 재시도 로직을 추가했습니다."
강한 표현(결과 중심):
"결제 재시도 로직을 추가해 결제 성공률을 94.2% → 97.5%로 올렸습니다.
월 약 3,000건의 실패 결제를 회복하는 효과입니다."
같은 일이지만 두 번째가 훨씬 강합니다. 결과와 그 비즈니스적 의미를 함께 보여주기 때문입니다.
7. 임팩트 큰 일을 먼저 찾아내는 법
지금까지는 "이미 들어온 일 중 무엇을 먼저 할까"를 다뤘습니다. 그러나 진짜 임팩트가 큰 사람은 한 단계 더 나아갑니다. 아무도 시키지 않은, 그러나 가장 큰 차이를 낼 일을 먼저 발견하는 것입니다. 주어진 일을 잘 고르는 것을 넘어, 해야 할 일을 스스로 찾아내는 단계입니다.
그런 일을 찾는 몇 가지 신호가 있습니다.
[고임팩트 작업의 신호들]
1. 반복되는 고통 : 같은 불평/장애/수작업이 자꾸 반복된다
2. 모두가 피하는 일 : 중요하지만 귀찮고 복잡해 아무도 안 건드린다
3. 큰 병목 : 한 군데가 막혀 여러 사람이 기다린다
4. 조용한 손실 : 눈에 안 띄지만 매일 새는 비용(느린 빌드, 잦은 오류)
5. 곧 올 변화 : 다가오는 성장/규제/마이그레이션에 대한 준비 부족
특히 2번이 보석입니다. "중요하지만 아무도 안 하는 일"은 경쟁이 없습니다. 모두가 쉽고 눈에 띄는 일로 몰릴 때, 어렵고 미뤄진 핵심 문제를 집어 드는 사람이 가장 큰 임팩트를 가져갑니다. 더러운 일을 자처하는 것이 종종 가장 빠른 성장 경로인 이유입니다.
이런 일을 찾으려면 시야를 넓혀야 합니다. 내 티켓만 보지 말고, 팀 전체가 어디서 가장 자주 막히는지, 어떤 지표가 가장 정체되어 있는지, 사람들이 어떤 불평을 가장 자주 하는지 관찰합니다. 임팩트는 종종 코드가 아니라 대화 속에, 회고 노트 속에, 반복되는 한숨 속에 숨어 있습니다.
8. 임팩트를 잘못 다루는 안티패턴
임팩트를 추구하다가 오히려 길을 잃는 전형적인 패턴들입니다.
- 임팩트 헌팅(impact hunting): 화려하고 평가에 잘 보일 일만 골라 하고, 덜 빛나지만 꼭 필요한 유지보수는 회피하는 것. 팀의 신뢰를 갉아먹습니다. 임팩트는 자기 PR을 위한 것이 아니라 팀과 제품을 위한 것입니다.
- 숫자에 대한 집착: 측정 가능한 것만 중요하다고 여기는 함정. 멘토링, 문서화, 분위기처럼 숫자로 안 잡히는 큰 임팩트를 놓칩니다.
- 남의 임팩트 가로채기: 다른 사람이 80%를 한 일에 마지막에 숟가락을 얹고 공을 차지하는 것. 단기적으로 이득 같지만 장기적으로 평판을 잃습니다.
- 영원한 분석 마비: 무엇이 가장 임팩트가 큰지 따지느라 정작 아무것도 시작하지 못하는 것. 우선순위 정하기 자체가 목적이 되어버린 경우입니다. 70%만 확신해도 시작하는 편이 100%를 기다리다 멈추는 것보다 낫습니다.
좋은 임팩트 추구는 정직합니다. 잘 보이는 일이 아니라 정말 중요한 일을, 내 공이 아니라 팀의 결과를 향합니다.
9. 사례: 우선순위를 바꿔 분기를 살린 팀
한 스타트업의 작은 팀이 신규 기능 다섯 개를 동시에 진행하고 있었습니다. 모두 "중요해 보이는" 일이었고, 다섯 갈래로 흩어진 팀은 어느 것도 제대로 끝내지 못한 채 분기 중반을 맞았습니다.
리드가 멈추고 다 같이 RICE 점수를 매겼습니다. 결과는 분명했습니다. 다섯 중 하나(온보딩 개선)가 나머지 넷을 합친 것보다 높은 점수를 받았습니다. 가장 많은 신규 사용자가 거쳐가는 지점이었기 때문입니다.
팀은 과감히 결정했습니다. 나머지 넷 중 둘은 보류, 둘은 폐기. 모든 인원을 온보딩 하나에 모았습니다. 3주 뒤 신규 사용자 활성화율이 31% 올랐고, 그것이 그 분기 회사 전체의 최대 성과가 되었습니다.
흥미로운 점은, 폐기한 기능들도 결코 나쁜 아이디어가 아니었다는 것입니다. 단지 지금, 이 자원으로는 온보딩이 더 큰 임팩트를 냈을 뿐입니다. 우선순위는 좋고 나쁨이 아니라 순서의 문제입니다.
10. 균형 — 임팩트가 전부는 아니다
여기까지 읽고 "그럼 임팩트 점수 낮은 일은 다 무시하라는 거냐"고 묻는다면, 그렇지 않습니다. 균형이 필요합니다.
- 숫자로 안 잡히는 임팩트도 있다. 동료를 돕는 일, 신뢰를 쌓는 일, 분위기를 좋게 만드는 일은 RICE에 안 들어가지만 장기적으로 큰 임팩트를 냅니다.
- 점수는 가정 위에 서 있다. Impact나 Confidence는 추정치입니다. 틀릴 수 있으므로 맹신하지 말고 주기적으로 다시 봅니다.
- 임팩트가 작아도 해야 할 일이 있다. 보안 패치, 규정 준수, 위생적 유지보수는 임팩트 점수와 무관하게 해야 합니다.
- 모든 것을 최적화하려다 지친다. 우선순위를 정하는 것 자체도 비용입니다. 사소한 결정에까지 RICE를 들이대면 그게 또 다른 비효율입니다.
요컨대 프레임워크는 사고를 돕는 도구이지, 사고를 대신하는 기계가 아닙니다.
11. 실전 체크리스트
새로운 일을 시작하거나 우선순위를 다시 정할 때:
- 이 일을 끝내면 구체적으로 무엇이 달라지는가?
- 효과 대비 노력은? (ICE/RICE로 거칠게라도 매겨봤는가)
- 이건 중요한 일인가, 단지 긴급한 일인가?
- Q2(중요+안 긴급)에 매주 시간을 떼어 두었는가?
- 지금 하지 않기로 한 일은 무엇인가?
- 로컬 최적화에 빠져 있지는 않은가? (전체 병목은 다른 곳인가)
- 시작 전에 성공 지표와 baseline을 기록했는가?
- 끝난 뒤 결과를 활동이 아니라 임팩트로 소통했는가?
12. 임팩트를 습관으로 — 주간 리추얼
임팩트로 우선순위를 정하는 것은 한 번의 결심이 아니라 반복되는 습관일 때 힘을 냅니다. 매주 돌아오는 짧은 리추얼 하나가 즉흥적인 분주함으로부터 여러분을 지켜줍니다.
[월요일 15분 우선순위 리추얼]
1. 펼치기 : 이번 주 할 수 있는 일을 다 적는다(머릿속을 비운다)
2. 점수내기 : 각 항목에 거친 ICE/RICE를 매긴다
3. 자르기 : 상위 2~3개에 동그라미, 나머지는 "안 할 일"로 보낸다
4. 보호하기 : 상위 항목을 위한 집중 시간을 캘린더에 미리 잡는다
5. 선언하기 : 매니저/팀에 "이번 주 나는 이것에 집중한다"를 공유한다
5번이 의외로 중요합니다. 무엇에 집중할지 공개적으로 선언하면, 두 가지가 생깁니다. 첫째, 스스로 약속을 지키게 됩니다. 둘째, 주변이 여러분의 우선순위를 알게 되어 불필요한 인터럽트가 줄어듭니다.
그리고 금요일에는 5분만 돌아봅니다. "이번 주 가장 큰 임팩트를 낸 일은 무엇이었나? 다음 주에 더 키울 부분은?" 이 짧은 회고가 쌓이면, 임팩트를 보는 눈 자체가 날카로워집니다. 처음에는 점수를 매기는 게 어색하지만, 몇 주만 지나면 어떤 일을 보는 순간 그 임팩트가 직관적으로 보이기 시작합니다.
결국 프레임워크의 목적은 프레임워크를 졸업하는 것입니다. ICE 계산이 몸에 배면, 더 이상 표를 그리지 않아도 "이건 노력 대비 효과가 크다"가 즉각 느껴집니다. 그때 여러분은 도구를 넘어 감각을 갖게 된 것입니다.
마치며
우리는 종종 바쁨을 성실함으로 착각합니다. 하지만 조직이 진짜 보상하는 것은 들인 시간이 아니라 만들어낸 변화입니다.
임팩트로 우선순위를 정한다는 것은 차갑게 계산만 하라는 뜻이 아닙니다. 오히려 내 한정된 시간과 에너지를 가장 의미 있는 곳에 쓰겠다는, 자기 일에 대한 존중에 가깝습니다. 무엇을 하지 않을지 정하는 용기, 큰 그림을 보는 시야, 결과를 정직하게 측정하고 나누는 습관 — 이 세 가지가 모이면, 같은 시간을 일하고도 전혀 다른 궤적을 그리게 됩니다.
가장 바쁜 사람이 되지 마십시오. 가장 큰 차이를 만드는 사람이 되십시오.
참고 자료
- Stephen R. Covey, The 7 Habits of Highly Effective People (중요-긴급 매트릭스)
- Greg McKeown, Essentialism (덜 하되 더 잘하기)
- Intercom — RICE 우선순위 프레임워크 (intercom.com 블로그)
- Sean Ellis & GrowthHackers — ICE 스코어링
- Will Larson, lethain.com — leverage와 엔지니어링 임팩트
- Andrew Grove, High Output Management (산출과 지렛대)