들어가며: "버튼을 파란색으로 바꿔주세요"
어느 금요일 오후, 매니저가 슬랙으로 메시지를 보냅니다. "결제 버튼을 파란색으로 바꿔줄 수 있을까요? 다음 주 월요일 데모 전에요."
여기서 두 종류의 엔지니어가 갈립니다.
첫 번째 엔지니어는 즉시 CSS를 수정하고, 색상 코드를 파란색으로 바꾸고, PR을 올립니다. 30분 만에 끝납니다. 효율적으로 보입니다.
두 번째 엔지니어는 한 가지를 더 묻습니다. "네, 가능합니다. 혹시 파란색으로 바꾸려는 이유가 따로 있을까요? 데모에서 강조하고 싶은 부분이 있다면 더 잘 맞는 방법을 제안드릴 수 있을 것 같아서요."
매니저가 답합니다. "아, 사실 지난 데모에서 고객이 결제 버튼을 못 찾겠다고 했거든요. 더 눈에 띄게 하고 싶어요."
이 순간 문제가 완전히 달라집니다. "버튼을 파란색으로"는 해결책이었지만, 진짜 문제는 "결제 버튼이 눈에 띄지 않는다"였습니다. 파란색은 오히려 우리 브랜드 배경색과 비슷해서 더 안 보일 수도 있습니다. 두 번째 엔지니어는 대비가 강한 색, 위치 조정, 약간의 그림자 같은 더 나은 선택지를 제안할 수 있습니다.
이 글은 "시키는 대로 일하지 말라"는 이야기가 아닙니다. 정확히 말하면 **요청의 표면이 아니라 그 뒤의 목적을 파악하고, 그 목적을 가장 잘 달성하는 방향으로 일하라**는 이야기입니다. 그리고 그것은 반항이 아니라, 매니저와 함께 더 좋은 결과를 만드는 협업의 기술입니다.
1. 모든 요청 뒤에는 의도가 있다
요청은 빙산의 일각입니다. 물 위로 드러난 "무엇을(what) 해달라"는 말 아래에는 "왜(why) 그게 필요한가"라는 훨씬 큰 덩어리가 잠겨 있습니다.
"버튼을 파란색으로" ← 표면(요청한 해결책)
───────────────────────────── 수면
"결제 버튼이 안 보인다" ← 문제
"데모에서 전환율을 보여야" ← 비즈니스 목표
"이번 분기 매출 압박" ← 더 큰 맥락
매니저가 해결책을 먼저 말하는 데에는 이유가 있습니다. 그들도 바쁘고, 머릿속에서 이미 "이렇게 하면 되겠지"라는 답을 한 번 내린 상태이기 때문입니다. 하지만 그 답은 매니저가 가진 정보와 시간 안에서 나온 임시 해법일 뿐입니다. 정작 그 영역을 매일 들여다보는 사람은 여러분입니다.
여기서 핵심은 태도입니다. "왜요?"라고 묻는 것은 따지는 것이 아니라, **더 잘 도와드리기 위해 맥락을 달라**는 신호여야 합니다. 같은 질문도 어조에 따라 완전히 다르게 들립니다.
- 나쁜 예: "이거 굳이 해야 돼요?" (저항으로 들림)
- 좋은 예: "이걸로 달성하려는 게 무엇인지 알려주시면, 제가 그 목표에 가장 잘 맞게 만들 수 있을 것 같아요." (협력으로 들림)
2. 정중하게 "왜"를 묻는 방법
"왜"를 묻는 것이 위험하게 느껴지는 이유는, 잘못 묻으면 무능하거나 비협조적으로 보일까 봐 두렵기 때문입니다. 그래서 질문에는 기술이 필요합니다.
2.1 의도를 먼저 밝혀라
질문 앞에 "왜 묻는지"를 붙이면 방어적인 반응이 사라집니다.
[목적 선언] + [질문]
"더 좋은 방법을 제안드리고 싶어서요 — 이 기능으로 해결하려는 사용자 문제가 뭘까요?"
"우선순위를 정확히 맞추고 싶어서요 — 이게 이번 주에 끝나야 하는 이유가 있을까요?"
"엉뚱한 걸 만들지 않으려고요 — 이 리포트를 누가, 어떤 결정에 쓰게 되나요?"
2.2 닫힌 질문이 아니라 열린 질문으로
"이거 꼭 파란색이어야 해요?"는 예/아니오로 끝나며 은근히 반대처럼 들립니다. 대신 맥락을 끌어내는 열린 질문을 씁니다.
- "이 변경으로 어떤 결과를 기대하세요?"
- "성공했다는 걸 어떻게 알 수 있을까요?"
- "이걸 보게 될 사람은 누구인가요?"
2.3 "받아 적은 뒤 되묻기"로 확인하라
들은 것을 자기 말로 다시 정리해서 확인하면, 오해를 초기에 잡고 매니저에게 "제대로 듣고 있다"는 신뢰를 줍니다.
"제가 이해한 게 맞는지 확인할게요. 고객이 데모에서 결제 버튼을 못 찾았고,
월요일 데모에서는 그게 명확히 보이길 원하신다 — 맞나요?
그렇다면 색만 바꾸기보다, 위치와 대비를 같이 손보는 걸 제안드리고 싶어요."
3. 더 나은 대안을 제시하기
"왜"를 파악했다면, 이제 단순 실행자에서 문제 해결자로 올라설 차례입니다. 다만 여기에는 흔한 함정이 있습니다. 자기 아이디어에 빠져 매니저의 원래 요청을 무시하는 것입니다.
좋은 대안 제시는 항상 **매니저의 목표를 인정하는 것**에서 출발합니다.
[목표 인정] → [원래 안의 한계] → [대안] → [트레이드오프] → [결정권 넘기기]
"결제 버튼이 눈에 띄어야 한다는 데 완전히 동의해요(목표 인정).
다만 파란색은 우리 배경과 비슷해서 오히려 묻힐 수 있어요(한계).
대비가 강한 주황색에 위치를 위로 올리면 더 확실히 보일 것 같습니다(대안).
대신 주황색은 우리 1차 브랜드 컬러는 아니라서, 데모용으로만 쓰고
나중에 디자인팀과 정식 컬러를 정하는 방법도 있어요(트레이드오프).
어떤 방향이 좋을까요?(결정권은 매니저에게)"
마지막 줄이 중요합니다. 대안을 강요하지 않고 결정권을 매니저에게 돌려주면, 여러분은 "내 말이 맞다"고 우기는 사람이 아니라 "선택지를 넓혀주는" 사람이 됩니다. 매니저가 끝내 원래 안을 고집해도 괜찮습니다. 여러분이 보지 못한 맥락(법무 요구, 경영진 약속 등)이 있을 수 있고, 무엇보다 책임은 매니저가 집니다. 의견을 충분히 말했다면, 결정에는 깔끔하게 따릅니다. 이것을 흔히 **"동의하지 않더라도 헌신하라(disagree and commit)"**고 부릅니다.
4. Upward Management — 매니저를 관리한다는 것
"매니저를 관리한다"는 말이 거슬릴 수 있습니다. 권한도 없는데 어떻게 윗사람을 관리하느냐고요. 하지만 여기서 관리는 통제가 아니라 **관계를 능동적으로 운영하는 것**을 뜻합니다. 매니저가 나를 잘 도울 수 있도록, 내가 먼저 정보를 주고 방향을 맞추는 일입니다.
4.1 매니저의 "사용 설명서"를 파악하라
사람마다 일하는 방식이 다릅니다. 매니저도 마찬가지입니다. 다음을 관찰하거나 직접 물어보세요.
| 항목 | 알아둘 것 |
| --- | --- |
| 소통 채널 | 슬랙 vs 이메일 vs 구두, 즉답 기대 여부 |
| 디테일 수준 | 요약만 원하는지, 세부까지 보고 싶어 하는지 |
| 의사결정 스타일 | 데이터 기반인지, 직관 기반인지 |
| 나쁜 소식 | 즉시 알리길 원하는지, 해결책과 함께 오길 원하는지 |
| 우선순위 | 무엇을 가장 중요하게 보는지 |
4.2 놀라게 하지 마라(No Surprises)
매니저가 가장 싫어하는 것은 나쁜 소식 그 자체가 아니라, **나쁜 소식을 뒤늦게, 다른 사람을 통해 듣는 것**입니다. 일정이 늦어질 것 같으면 마감 당일이 아니라 며칠 전에 알립니다.
나쁜 예 (마감일 당일):
"죄송해요, 오늘 못 끝낼 것 같아요."
좋은 예 (3일 전):
"진행 상황 공유드려요. API 연동에서 예상 못한 인증 이슈가 생겨서
기존 일정보다 이틀 정도 더 걸릴 것 같습니다. 두 가지 방법이 있어요:
(1) 인증 부분을 다음 스프린트로 미루고 나머지를 먼저 배포하거나,
(2) 일정을 이틀 늦추거나. 어떤 쪽을 선호하세요?"
후자는 단순한 보고가 아니라, 선택지를 정리해 매니저의 의사결정을 쉽게 만들어 줍니다. 이것이 신뢰를 쌓는 방식입니다.
5. 1:1 미팅을 제대로 쓰는 법
1:1은 매니저의 시간이 아니라 **여러분의 시간**입니다. 흔한 오해는 1:1을 단순 진행 보고로 채우는 것인데, 진행 상황은 슬랙이나 문서로도 전할 수 있습니다. 얼굴을 맞대는 30분은 더 깊은 대화에 써야 합니다.
미리 안건을 적어 가는 것만으로도 1:1의 질이 달라집니다.
[1:1 안건 템플릿]
1. 막힌 곳 / 도움 필요한 것
- X 결정에 매니저 의견이 필요합니다.
2. 정렬 확인
- 다음 분기 우선순위를 제가 이렇게 이해하고 있는데 맞나요?
3. 피드백 요청
- 지난 발표 어땠나요? 더 나아질 점이 있을까요?
4. 성장 / 커리어
- 시니어로 가려면 어떤 역량을 더 키워야 할까요?
5. 위로 전하는 정보
- 팀에서 Y 문제가 반복되는데, 매니저가 알아두면 좋을 것 같아요.
특히 4번(성장)과 3번(피드백 요청)은 미루기 쉽지만 가장 가치가 큽니다. 피드백은 기다리면 오지 않습니다. **먼저 구체적으로 요청해야** 쓸모 있는 답이 돌아옵니다. "저 어때요?"가 아니라 "지난 설계 리뷰에서 제 설명이 명확했나요? 더 설득력 있게 하려면요?"처럼.
6. 피드백을 주고받는 기술
6.1 피드백을 받을 때
방어는 본능입니다. 누군가 내 일에 대해 부정적인 말을 하면 심장이 빨라지고 변명이 먼저 튀어나옵니다. 하지만 그 순간 방어하면 상대는 다음부터 솔직한 피드백을 주지 않습니다.
- 먼저 듣는다. 반박하기 전에 끝까지 듣습니다.
- 구체화한다. "별로였다"는 막연한 말에는 "어느 부분이 그랬는지 예를 들어줄 수 있나요?"라고 되묻습니다.
- 감사한다. 동의하지 않더라도, 시간 들여 말해준 것에는 감사합니다.
- 나중에 판단한다. 즉석에서 다 받아들이거나 다 거부할 필요는 없습니다. "생각해보겠습니다"도 좋은 답입니다.
6.2 피드백을 줄 때(위로 향하는 피드백 포함)
매니저에게도 피드백을 줄 수 있습니다. 단, 방식이 중요합니다. SBI 모델(상황-행동-영향)이 유용합니다.
[상황 Situation] 지난 스프린트 회의에서
[행동 Behavior] 중간에 우선순위가 세 번 바뀌었는데
[영향 Impact] 팀이 무엇에 집중해야 할지 혼란스러워했어요.
→ 사람이 아니라 행동과 그 결과에 초점.
"당신은 변덕스럽다"(인격 공격) ❌
"우선순위가 자주 바뀌니 혼란스럽다"(행동·영향) ⭕
위로 향하는 피드백은 사적인 자리에서, 비난이 아니라 개선 제안의 형태로 전합니다. 좋은 매니저라면 환영하고, 그렇지 않더라도 시도 자체가 여러분의 주도성을 보여줍니다.
7. 균형 잡기 — 이것이 만능은 아니다
여기까지 읽고 "그럼 모든 요청에 일일이 왜냐고 물어야 하나"라고 생각했다면, 그건 과합니다. 균형이 필요합니다.
- **사소하고 명확한 일은 그냥 한다.** 오타 수정에 "이걸 왜 고치죠?"라고 묻는 건 시간 낭비입니다.
- **긴급할 때는 먼저 하고 나중에 묻는다.** 장애 상황에서 "근본 원인부터 토론하죠"는 부적절합니다. 불부터 끄고, 회고에서 왜를 논합니다.
- **신뢰 잔고를 본다.** 갓 입사했다면 먼저 충실히 실행해 신뢰를 쌓는 편이 낫습니다. 신뢰가 쌓이면 "왜"를 묻고 대안을 제시할 여지도 커집니다.
- **반복적인 패턴에 집중한다.** 한 번의 요청보다, 반복되는 비효율이나 방향 어긋남에 "왜"를 적용할 때 효과가 큽니다.
핵심은 "왜를 파악하라"가 "지시를 의심하라"가 아니라는 점입니다. 목적을 이해해야 더 잘 실행할 수 있다는, 지극히 실용적인 태도입니다.
8. 사례: 같은 요청, 다른 결과
한 데이터 엔지니어가 매니저에게 "매주 월요일 아침마다 매출 리포트를 엑셀로 보내달라"는 요청을 받았습니다.
그는 시키는 대로 매주 손으로 쿼리를 돌려 엑셀을 만들었습니다. 6주가 지나자 그 일이 부담스러웠습니다. 그제야 그는 물었습니다. "이 리포트를 매니저님이 직접 보세요, 아니면 누구에게 전달하세요?"
답은 뜻밖이었습니다. "팀 채널에 붙여서 다들 보게 하려고요." 그렇다면 굳이 엑셀일 필요도, 사람이 매주 만들 필요도 없었습니다. 그는 대시보드를 만들어 팀 채널에 자동으로 갱신되도록 했습니다. 매니저의 진짜 목표("팀이 매출을 늘 볼 수 있게")는 더 잘 달성되었고, 그의 월요일 아침은 자유로워졌습니다.
만약 첫 주에 "왜"를 물었다면 6주의 수작업은 없었을 것입니다. 목적을 묻는 30초가 수십 시간을 아낍니다.
9. 정렬 대화의 실제 — 처음부터 끝까지
이론을 한 편의 대화로 묶어 봅시다. 신입에 가까운 엔지니어 지민과 매니저 사이의 가상의 1:1입니다. 지민은 이번 글의 기법들을 하나씩 자연스럽게 씁니다.
매니저: 다음 스프린트에 검색 기능을 좀 빠르게 만들어줄 수 있을까요?
지민: 네, 가능해요. 더 잘 만들고 싶어서 한 가지만 여쭐게요 —
검색을 지금 우선순위로 올리게 된 계기가 있을까요? (의도부터 묻기)
매니저: 영업팀에서 고객들이 원하는 자료를 못 찾는다는 피드백이 계속 와요.
지민: 아, 그러면 핵심은 "원하는 자료를 빨리 찾게 하는 것"이군요.
제가 이해한 게 맞나요? (받아 적고 되묻기)
매니저: 맞아요.
지민: 그렇다면 풀 텍스트 검색을 처음부터 다 만드는 것보다,
우선 가장 많이 찾는 자료에 태그와 필터를 먼저 붙이는 게
더 빨리 효과를 낼 수도 있을 것 같아요.
검색은 그다음 단계로요. (목표 인정 → 대안 제시)
매니저: 오, 그 방법이 더 빠르겠네요. 근데 검색창이 있어야 보기 좋지 않나요?
지민: 맞는 지적이에요. 그러면 가벼운 검색창과 필터를 같이 1차로 내고,
반응을 본 뒤 본격 검색을 키우는 방향은 어떨까요?
대신 1차는 정확도가 완벽하진 않을 거예요. (트레이드오프)
어떤 쪽이 좋으세요? (결정권 넘기기)
매니저: 좋아요, 그렇게 가죠. 1차는 언제쯤 가능할까요?
지민: 금요일까지 1차를 내고, 다음 주 월요일 1:1에서 반응을 같이 볼게요.
혹시 늦어질 것 같으면 수요일에 미리 알려드릴게요. (기대치 관리)
이 대화에서 지민은 한 번도 "그건 안 돼요"라고 말하지 않았습니다. 그러나 처음 요청("검색 기능을 빠르게")과 최종 결과("필터 우선, 가벼운 검색창, 단계적 확장")는 꽤 다릅니다. 표면이 아니라 의도("자료를 빨리 찾게")를 붙잡았기 때문입니다.
이것이 이 글이 말하는 전부입니다. 반항하지 않으면서, 그러나 단순 실행자에 머무르지 않으면서, 매니저와 함께 더 나은 답으로 가는 길. 그 길의 모든 모퉁이에는 같은 질문이 서 있습니다. "이걸로 진짜 이루려는 게 뭐죠?"
10. 흔한 안티패턴 다섯 가지
지금까지의 이야기를 거꾸로 뒤집으면, 매니저와의 관계를 망치는 전형적인 실수 목록이 됩니다. 자신에게 해당하는 게 있는지 솔직하게 점검해 보세요.
9.1 묻지 않고 추측해서 만들기
가장 흔하고 비싼 실수입니다. "아마 이런 뜻이겠지" 하고 며칠을 들여 만들었는데, 정작 원하던 것과 전혀 다른 경우. 추측의 비용은 항상 질문의 비용보다 큽니다. 30초의 질문이 사흘의 헛수고를 막습니다.
9.2 모든 것에 토를 달기
반대의 함정입니다. 사소한 요청에까지 "왜요?"를 붙이면, 협력자가 아니라 걸림돌이 됩니다. 7장에서 말한 균형이 여기서 중요합니다. "왜"는 임팩트가 크거나 방향이 의심스러운 일에 아껴 씁니다.
9.3 동의해 놓고 뒤에서 딴말하기
회의에서는 고개를 끄덕이고, 자리에 와서는 "저건 말이 안 돼"라고 동료에게 투덜대는 것. 이것은 신뢰를 가장 빠르게 무너뜨립니다. 이견이 있다면 그 자리에서, 정중하게 말해야 합니다. 말할 타이밍을 놓쳤다면, 따로 찾아가 말합니다. 뒷담화는 답이 아닙니다.
9.4 나쁜 소식을 숨기기
일이 잘못되어 갈 때, 더 늦기 전에 알리는 대신 "어떻게든 혼자 해결해 보자"며 숨기는 것. 대부분 더 큰 사고로 번집니다. 매니저는 일찍 알수록 더 많이 도울 수 있습니다. 늦게 터진 폭탄은 도와줄 수도 없습니다.
9.5 결과가 아니라 노력만 보고하기
"정말 열심히 했어요"는 보고가 아닙니다. 매니저가 알아야 하는 것은 "그래서 무엇이 어떻게 되었는가"입니다. 노력은 입력이고, 매니저가 책임지는 것은 출력입니다. 늘 결과와 그 의미로 말하는 습관을 들입니다.
11. 정렬은 한 번이 아니라 습관이다
지금까지의 모든 기법은 사실 하나의 큰 습관으로 수렴합니다. **정렬(alignment)을 주기적으로 갱신하는 것**입니다.
오해는 정렬을 일회성 이벤트로 보는 것입니다. 프로젝트 시작할 때 한 번 맞추면 끝이라고요. 하지만 상황은 계속 변합니다. 시장이 바뀌고, 우선순위가 바뀌고, 매니저가 위에서 받는 압박도 바뀝니다. 한 달 전의 정렬이 오늘도 유효하다는 보장은 없습니다.
[정렬의 주기]
매일: 오늘 내가 하는 일이 합의된 방향과 맞는가? (혼자 5초 점검)
매주: 1:1에서 우선순위가 그대로인지 확인
분기: 더 큰 목표와 내 일이 정렬되어 있는지 재점검
이 습관이 몸에 배면, "왜를 파악하라"는 더 이상 의식적인 노력이 아니라 일하는 방식 그 자체가 됩니다. 매번 새로 묻지 않아도, 매니저의 목표와 맥락이 머릿속에 늘 살아 있게 됩니다. 그러면 같은 요청을 받아도 자동으로 "이게 그 목표에 어떻게 연결되지?"가 떠오릅니다.
그리고 시간이 지나면 흥미로운 일이 일어납니다. 매니저가 점점 더 큰 일을, 점점 더 적은 설명과 함께 맡기기 시작합니다. 왜냐하면 여러분이 표면이 아니라 의도를 보고 일한다는 걸 알기 때문입니다. 그것이 바로 신뢰가 자율로 바뀌는 순간이고, 시니어로 가는 길의 핵심입니다.
12. 실전 체크리스트
새 요청을 받았을 때 스스로에게 던지는 질문들입니다.
- [ ] 이 요청으로 매니저가 진짜 달성하려는 것은 무엇인가?
- [ ] 요청받은 해결책 말고 더 나은 방법이 있는가?
- [ ] 성공의 기준은 무엇이고, 누가 결과를 보게 되는가?
- [ ] 마감과 우선순위가 다른 일과 충돌하지 않는가?
- [ ] (대안이 있다면) 목표를 인정하고, 트레이드오프를 정리하고, 결정권을 넘겼는가?
- [ ] 일정 리스크가 있다면 미리(당일이 아니라) 공유했는가?
- [ ] 사소하거나 긴급한 일이라면, 캐묻지 말고 바로 실행하는 게 맞지 않은가?
마치며
"시키는 대로 하지 말라"는 말은 자칫 오만하게 들립니다. 하지만 진짜 뜻은 정반대입니다. 매니저를 더 잘 돕기 위해, 그가 말로 다 표현하지 못한 의도까지 헤아리려는 노력입니다.
좋은 협업은 명령과 복종이 아니라, 목적을 공유한 두 사람이 더 나은 답을 함께 찾아가는 과정입니다. 그 과정의 첫걸음은 언제나 같은 질문입니다. "우리가 이걸로 진짜 이루려는 게 뭐죠?"
그 질문을 정중하게, 그러나 빠뜨리지 않고 던질 수 있다면, 여러분은 단순히 일을 처리하는 사람이 아니라 함께 방향을 잡는 사람이 됩니다. 그리고 그 차이가 결국 신뢰를, 그리고 커리어를 만듭니다.
참고 자료
- Julie Zhuo, *The Making of a Manager* (관리와 1:1의 기본)
- Will Larson, lethain.com — "Managing up" 관련 글들
- StaffEng, staffeng.com — 시니어/스태프 엔지니어의 일하는 방식
- Harvard Business Review (hbr.org) — "Managing Your Boss" (John Gabarro & John Kotter)
- Kim Scott, *Radical Candor* (피드백을 주고받는 법)
- Amy Edmondson, *The Fearless Organization* (심리적 안전감과 솔직한 대화)
현재 단락 (1/149)
어느 금요일 오후, 매니저가 슬랙으로 메시지를 보냅니다. "결제 버튼을 파란색으로 바꿔줄 수 있을까요? 다음 주 월요일 데모 전에요."