일반적으로, 난 모든 걸 문제 관점으로 확인한다.
- 그래서 이 사람이 이 문제를 해결 가능한 사람인가?
- 그래서 할 수 있는가 없는가?
- 약속과 신뢰, 보고 체계를 잘 지키는가?
마치 사람과 사람이 아닌, 로봇과 로봇으로 본다.
"돈 받고 일하는거면 문제에 집중해야지."
그렇게 믿지 못하는 사람이 있으면, 끝까지 파고들어 그 문제를 대신 해결해 버린다.
문제는 깊게 간섭하면 해결할 수 있다. 그런데 사람은 아니다.
- 문제는 생물이 아니기에, 파고 든다고 "진짜 문제가 되는 원인"과 그 "영향 범위"가 능동적으로 무언가를 하려 하지는 않는다.
- 그래서 마음껏 파고들어도 문제가 없다.
- 사람은 생물이기에, 문제가 되는 원인을 숨기려 하고, 기존 문제를 다른 책임으로 옮긴다.
- 이는 문제 해결을 늦추고, 더 큰 비효율을 만든다.
명백히, 난 지금 지나친 간섭을 하고 있다.
이는 최근 내 입력과, 주변인의 출력이 증명한다.
- 협업 신뢰가 무너지고 있다는 증거 및 대응이 두 종류 이상 발견되었다.
- 즉시 에스컬레이션, 결정 떠넘기기 또한 여러번 반복되었다.
- 내부 구조와 의사결정 동기가 상대방이 모를만한 내용으로 응답하는 것으로 은닉되고 있다.
- 가볍게 제안한 내용이 주변인에게 검사/검토까지 해야 한다는 압박을 주고 있었다.
간섭 받는 것을 누구보다 싫어하던 내가 타인에게 가장 깊게 간섭한다는 건 꽤 마음 아픈 사실로 다가왔다.
일을 재밌게 하는 건 좋은데, 이기적으로 "나만" 재밌게 하고 있었다.
일을 하는 과정을 기분 좋게 만들었어야 했는데, 아쉽다.
관점을 바꿔 생각해보기 - 좋은 시스템이란 무엇인가?
현재의 나의 행동은 마치 마이크로 매니징과 유사하다.
물론, 마이크로 매니징은 좋은 시스템이 아니다.
- 리더가 갖는 부하가 지나치게 커진다.
- "내가 이렇게 대단하다"라는 착각에 빠트리고, 조직 전체의 상한선을 리더가 막는다.
- 부하 직원의 성장을 막는다.
그렇다면, 좋은 시스템은 무엇인가?
- 적절한 Input으로 타당한 Output이 보장되는 시스템
- 그 안에서 발생한 병목이나 문제점을 조기에 파악할 수 있는 시스템
다시 말해, 과정은 시스템에서 크게 중요하지 않다.
- 중요한 건 Input과 Output이지, 그 중간과정은 중요하지 않다.
- 전부 사람이 how를 검증할거면, 혼자 다 하면 된다.
- 위에서 원하는 것 또한, 주어진 리소스를 활용해 이 Output을 낼 수 있는가이다.
- 사소한 디테일 따위는 굳이 알 필요가 없다.
- 다만, 내가 뭐가 중요한 디테일이고, 뭐가 중요하지 않은 디테일인지 구분하지 못하는 것이 문제다.
중요한 불안만을 걸러서 남겨야 하는데,
지식의 저주로 모든 부분이 기존에 하지 않았던 기술적 결정이라고 판단했고,
그래서 모든 결정을 중요한 결정이라 생각했다.
그 부분에 있어서 좀 아쉬움이 나타났다.
근데 왜 나는 마이크로 매니징과 같은 행동을 하게 되는 것인가?
예상 가능한 중간 과정에서, 예상 가능한 Input과 Output이 나오기 때문에, 중간 과정에 관여하고 싶어지는 것이다.
이는 다음 불안함에 기인한다.
- 지금 나조차 그 Input과 Output이 어느정도로 정교한 지 모르는데, 어떻게 Input과 Output만으로 검사할 수 있는가?
- 지금 중간 병목이 발생했다고? 이게 병목이 발생하면 문제가 어디까지 커지는거지? 나도 확신할 수 없는데?
그렇게 다음과 같은 결론에 도달한다.
- 내가 중간 과정에 개입하면서, Input과 Output의 정교함을 확인하고, 문제 크기와 그 여파를 함께 이해하면서 진행해야겠다!
두려움에 질려, 문제를 효율적으로 풀지 못하고 목소리만 커졌다.
즉, 문제의 본질적인 원인은 "직접 해보지 않으면 정교한 문제의 크기, 그리고 Input과 Output을 알 수 없다"는 생각에 기인한다.
이를 해결하려면, 다음 두 가지가 가능해야 한다.
- 굳이 직접 하지 않아도 빠른 속도로 정교한 Input과 Output을 구성할 수 있어야 한다.
- 해당 문제가 잘못됐을 때, 퍼지게 되는 영향 범위를 정확하게 알고 있어야 한다.
그렇다면, 어떻게 하면 빠르게 중간 과정을 이해하고,
- 예상하지 못한 Input로 인한 문제 상황 체크
- 예상하지 못한 Output으로 이뤄지는 영향 범위 체크
를 수행할 수 있을까?
마이크로 매니징의 일반론 - 좋은 보고 vs 나쁜 보고
- 좋은 보고 - 리스크 보고
- 현재 상태: 계획 대비 진행률 60%
- 완료한 것: API 명세 초안 완료, 테스트 케이스 12개 작성
- 남은 것: 예외 처리, 성능 테스트
- 리스크: 외부 결제 모듈 응답 스펙 미확정
- 의사결정 요청: A안/B안 중 우선순위 결정 필요
- 이게 좋은 보고가 되는 이유: 어떻게 진행되는지 이미 안다. 입출력만 확인. 즉시 관여해야 하는 병목 제공받기
- 나쁜 보고 - 진행 상황 공유
- 문서 작성 중
- 코드 검토 중
- 회의 예정
- 테스트 예정
- 이게 나쁜 보고가 되는 이유: 아직도 여기야? 왜?
팀원 입장에서 마이크로매니징을 피하려면, "리스크 보고"가 제때 이루어져야 한다.
마이크로 매니징을 피하기 위해선, 양쪽의 노력이 필요하다.
현재 나의 지나친 간섭은 어떻게 해결해야 하는가?
마이크로매니징의 사례 속에서, 몇가지 인사이트를 얻을 수 있었다.
기준을 두번 잡는 건, 비효율이 아니다.
- 상대방과 별도로 문제를 내가 직접 빠르게 재해석해야 한다.
- 이게 작업을 두번 하는 것 같아 비효율 같지만, 아이러니하게도 가장 효율적인 방법이다.
- 내가 기존 사용하던 AI 프로세스같이, 가장 나에게 맞춘 형태로 요구사항을 이해해야 한다.
- 이를 외부에 공개하지 않은 채로 각각 Input과 Output을 가지고 있어야, 보다 정교한 결과물이 나온다.
- 두 개의 99%짜리 통과율을 가진 기준이 있다면, (단순히 생각해봤을 때) 98%의 통과율을 갖는 기준이 되고, 2%의 오류를 찾을 수 있다.
- 이게 상급자가 지시사항을 가능한 모호하면서 가능한 명확하게 주려는 이유이다.
- 과거에 이미 풀렸던 문제도, 다시 푼다면 다른 Input/Output 기준을 가질 수 있다.
- 하던 대로가 아닌 매번 새로운 기준, 다른 기준을 원하는 이유이기도 하다.
그럼 이미 잘못된 상황은 어떻게 풀어야 하는가?
- 결국은 모두 로봇이 아니라 사람이다.
- 공감이 되지 않으면, 내러티브를 만들 수 없다.
- 단순 감사합니다/화이팅입니다는 아무런 공감을 이끌어낼 수 없다.
- 상대방을 제대로 깊게 이해하려면, 먼저 공감해야 한다.
- 일만 좋아하지 말고, 사람을 좋아할 줄 알아야 한다.
- 마치 사랑 많이 받고 자란 사람처럼 주변에 관심을 많이 가져야 한다.
- 가벼운 취미 많이 만들기
- 이것저것 많이 접해서, 가볍게 시작할 수 있는 사람처럼 다가가기 쉽게 하기
- 주의
- 들을 때 눈썹에 감정이 드러나고 있다.
- 이게 잘 듣고 있다는 신호로 쓰일 수도 있지만, 부정적 감정이 눈썹에 드러나면 좋을 건 없다.
- 고쳤다 생각했는데, 다시 재발함. 주의 필요.
이해되지 않으면, 충분히 들어야 한다.
- 이 문제가 대비가 됐냐고 묻기 전에 문제가 될 수 있는 영향범위를 산정해야 한다.
- 문제에 대한 해결 방법은 상대방의 영역이다.
- 문제가 아닌 시스템을 관리해야 한다.
상대방이 직접 이야기하기 전까진, 그냥 들어라.
- 현재 문제를 가장 깊게 이해하고 있는 것은 당사자이다.
- 강조하지만, 이 문제가 대비가 됐냐고 묻기 전에 문제가 될 수 있는 영향범위를 산정해야 한다.
- 문제에 대한 해결 방법은 상대방의 영역이다.
- 문제가 아닌 시스템을 관리해야 한다.
- 공감은 그저 듣는 것에서 시작한다.해결책의 제시는, 문제가 될 수 있는 영향범위가 완전히 산정됐을 때 가능하다.
- 그때가 비로소 제대로된 해결책을 제시할 수 있는 시점이다.
- 그 전까진, "이 방법을 시도해 봤냐"라는 것을 묻는 것이 아닌, "이 문제가 어디까지 영향을 끼치는가"를 물어야 한다.
- 그때야 비로소, 풀 필요 있는 문제와 풀 필요 없는 문제가 나뉘어지고, 중요도에 따른 해결책을 선택할 수 있다.
그렇다면 어떻게 문제를 감지해야 하는가? 상대방이 이야기하지 않으면 알 방법이 없다!
- 그래서 중요한게 시스템화이다.
- "사람을 감시하는 구조"가 아닌, "문제가 자연스럽게 드러나는 구조"를 만들어야 한다.
- 중간 산출물을 대폭 쪼개고, 데이터를 주기적으로 확인할 수 있는 구조를 만들어 두어야 한다.
"데이터 기반으로 소통"의 의미 - 통제, 방임, 그리고 시스템화
본 글은 데이터 기반으로 의사소통을 하는 방법을 다루는 글이 아닙니다.데이터 기반으로 의사소통을 하는 전략의 이점을 개발자 관점에서 분석한 글입니다.실제로 자신의 직무에서 데이터 기
dev.go-gradually.me
문제는 집착하듯 접근해서 밤낮을 지새우면 해결할 수 있는데,
사람은 그렇지 않다.
이를 효율적으로 해결하려면, Input과 Output을 항상 명시하고 생각하자.
'개인적 공간 > 독서와 사색' 카테고리의 다른 글
| 절차적 계획과 항목형 계획의 적용 (0) | 2026.03.28 |
|---|---|
| 확신과 성장 (0) | 2026.03.21 |
| 어떻게 일해야 하는가? (feat. 직관) (0) | 2026.03.17 |
| 사내정치 (0) | 2026.03.05 |
| “너 정말, **핵심**을 찔렀어.” (2) | 2026.03.03 |