솔직히 말해봅시다.
PM이나 개발 리더 자리에 앉아 있는 분들, 매일 아침 거울 보며 무슨 생각 하십니까? "내가 이걸 다 챙길 수 있을까?" 아니면 "저 멍청한 김 대리가 또 사고 치진 않을까?" 하는 불안감 아니던가요.
저도 삼성전자 무선사업부 시절, S-Health 기획하면서 똑같았습니다. 윗분들은 "혁신"을 외치는데, 실무는 스파게티 코드로 엉켜있는 레거시 청산하느라 바빴으니까요.
흔히들 빌 게이츠(BillG)를 '마이크로매니징의 화신'으로 기억합니다. 개발자 뒤에 서서 모니터 삿대질하는 공포의 CEO 이미지 말입니다.
그런데 최근 스티븐 시노프스키(전 MS 윈도우 총괄)가 공개한 'Hardcore Software' 아카이브를 뜯어보니, 우리가 알던 전설은 반은 맞고 반은 틀렸습니다.
특히 90년대 초반, MS가 폭발적으로 성장하던 그 시기 BillG의 관리 방식은 지금의 C-Level이나 시니어 개발자들이 뼈저리게 참고해야 할 '생존 매뉴얼'에 가깝습니다.
이건 교과서에는 안 나오는, 철저히 실무적인 관점에서 본 BillG의 '진짜' 매니지먼트 기술입니다.
--> 팩트 1: 물리적으로 마이크로매니징이 불가능했다.
당시 MS의 상황을 봅시다. 8비트 베이직에서 16비트 도스(DOS)로, 그리고 다시 Win32 시대로 넘어가는 격변기였습니다.
운영체제, 개발 도구(Language), 네트워크, 애플리케이션(Excel, Word)까지. 이 모든 걸 빌 게이츠 혼자서 코드 리뷰하고 승인한다? 불가능합니다.
그랬다간 MS는 병목(Bottleneck) 현상으로 진작에 망했을 겁니다.
BillG가 선택한 건 '중앙집중형 허브'가 아니라 '권한 위임'이었습니다. 그는 모든 제품의 스펙을 결정하는 대신, 각 제품 그룹의 리더(Product Leader)들과 깊은 수준의 '기술 전략 대화'를 나누는 데 집중했습니다.
즉, "이 버튼 색깔 왜 이래?"가 아니라 "너네 아키텍처가 윈도우 API 전략이랑 정렬(Align)되어 있어?"를 물었던 겁니다.
--> 팩트 2: 하드웨어를 버리고 '개방형 플랫폼'에 올인했다.
이게 진짜 소름 돋는 지점입니다.
당시 IBM이나 애플은 수직 계열화(Vertical Integration)에 목숨 걸었습니다. 하드웨어부터 OS, 앱까지 다 자기들이 만들어야 직성이 풀리는 구조였죠.
하지만 BillG는 냉정했습니다.
"하드웨어? 그건 마진도 박하고 재고 관리하다 골머리 썩는 일이야. 남들이 하게 둬."
그는 인텔 기반의 범용 PC 위에 윈도우라는 OS를 올리고, 그 API를 전면 개방하는 전략을 취했습니다.
이건 단순한 기술적 선택이 아닙니다. 비즈니스 모델 자체를 '소프트웨어 확장성'에 둔 겁니다.
덕분에 MS는 수십 개의 독점 하드웨어 플랫폼에 맞춰 일일이 포팅하는 삽질을 멈추고, 윈도우 생태계 확장에만 리소스를 집중할 수 있었습니다.
지금 우리 회사들을 보세요. 뭐 좀 된다 싶으면 이것저것 다 직접 하겠다고 덤비다가, 결국 유지보수 비용 감당 못 해서 프로젝트 드랍시키는 경우가 얼마나 많습니까?
--> 팩트 3: 1991년 5월, 이메일 한 통으로 정렬하다.
시노프스키가 언급한 1991년 5월의 "Challenges and Strategy" 메모는 전설적입니다.
BillG는 이 문서를 통해 회사의 모든 제품이 'Windows'라는 하나의 북극성을 향해 가야 함을 못 박았습니다.
복잡한 플랫폼 선택지 앞에서 갈팡질팡하던 개발팀들에게 명확한 가이드라인을 던진 겁니다.
"너희 앱이 윈도우 최신 API를 쓰고 있는가?"
"레거시 윈도우 버전에서도 돌아가는가?"
이런 질문들은 개발자를 괴롭히기 위한 게 아니었습니다. 회사의 거대한 배가 산으로 가지 않게 만드는 '추상화된 통제'였습니다.
개발자 여러분, 혹시 팀장이 "그냥 일단 개발해"라고 하나요? 그건 직무 유기입니다.
진짜 리더라면 BillG처럼 구체적인 기술 로드맵과 우선순위를 문서화해서 던져줘야 합니다. 그래야 실무자들이 쓸데없는 고민 없이 코딩에만 집중할 수 있습니다.
결론: 당신은 스티브 잡스가 아니다.
우리는 흔히 스티브 잡스 식의 '픽셀 하나까지 챙기는 완벽주의'를 동경합니다. 하지만 그건 잡스니까 가능한 거고, 제품 라인업이 단순했기에 가능한 전략이었습니다.
당신이 관리하는 서비스가 MSA로 쪼개져 있고, 하루에도 수십 번 배포가 일어나는 환경이라면? BillG의 방식을 따라야 합니다.
- 모든 걸 직접 챙기려 하지 마십시오. (병목이 됩니다.)
- 코드 레벨의 간섭보다 '아키텍처'와 '비즈니스 전략'의 정렬을 확인하십시오.
- 하드웨어(물리적 제약) 같은 짐은 버리고, 소프트웨어적 확장성에 집중하십시오.
저도 주니어 시절엔 제가 짠 코드가 세상의 전부인 줄 알았습니다. 하지만 PM이 되고 리더가 되어보니 알겠습니다.
진짜 실력은 내가 코드를 얼마나 잘 짜느냐가 아니라, 팀원들이 엉뚱한 짓 안 하고 한 방향으로 달리게 만드느냐에 달려 있다는 것을요.
오늘 회의 들어가서 팀원들 쪼기 전에 스스로에게 물어보세요.
"나는 지금 BillG처럼 전략을 말하고 있는가, 아니면 그냥 잔소리를 하고 있는가?"
