# 엔지니어링의 인간적 측면 마스터하기: Apple, Palantir, Slack에서 배운 리더십 교훈

> Clean Markdown view of GeekNews topic #20707. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20707](https://news.hada.io/topic?id=20707)
- GeekNews Markdown: [https://news.hada.io/topic/20707.md](https://news.hada.io/topic/20707.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-05-05T11:01:02+09:00
- Updated: 2025-05-05T11:01:02+09:00
- Original source: [review.firstround.com](https://review.firstround.com/engineering-lessons-apple-palantir-slack/)
- Points: 47
- Comments: 6

## Summary

경험이 풍부한 기술 리더는 **사람 중심 조직 운영**과 **협업 문화**의 중요성을 강조하며, 효과적인 조직 구조와 리더십 역량을 구체적으로 제시합니다. **창의성과 자율성**을 장려하는 업무 환경 조성, **활발한 논쟁 유도**, **투명한 의사결정 프로세스 구축**이 성공적인 팀의 핵심이라고 말합니다. **제품팀과 엔지니어의 관계 강화**를 위해 '왜(why)'를 공유하고, 각자의 동기와 맥락을 이해하는 리더십이 중요하다고 강조합니다. 결국 성공적인 기술 조직은 **인간적 이해**와 **유연한 리더십**을 통해 뛰어난 결과를 만드는 것이 가능함을 보여줍니다.

## Topic Body

- Apple의 엔지니어링 리더 **Michael Lopp**은 제품을 빠르게 만들 수 있는 시대일수록 **사람 중심의 운영과 판단력**이 중요하다고 강조  
  - “누가 결정을 내리고, 그 결정을 어떻게 실행하는가?”가 진정한 엔지니어링의 본질임  
  - 코드 작성 능력보다, **사람 중심 조직과 리더십**이 조직 성과를 좌우  
- 그는 Borland, Netscape, Palantir, Slack등 다양한 환경에서 얻은 경험을 바탕으로, **조직 구조, 협업 문화, 리더십 핵심 역량**을 구체적으로 제시  
- 기술 리더십보다는 **조직 운영, 사람 간 협업, 인간 이해**에 초점을 둠   
- 이 인터뷰는 단순한 기술 논의가 아닌, **지속가능하고 효과적인 엔지니어링 조직 설계**에 집중하며 제품팀과의 관계, 사람 중심 역량, 좋은 리더의 조건 등을 **창업자와 기술 리더에게 실질적인 조언 형태로 제시**  
  
### 엔지니어 조직의 구조를 어떻게 설계할 것인가  
  
- 각기 다른 산업에서도 공통된 성공 요소로 **엔지니어링에 대한 신뢰, 빠른 성장, 스마트한 인재 확보**를 꼽음  
- 이를 바탕으로 성공적인 엔지니어 조직을 설계하기 위한 세 가지 실천 팁을 제안  
  
#### Tip #1: “Wolf Time”을 장려하라  
  
- 엔지니어의 시간을 **71% 실질 업무 / 29% 자유 창작 시간**으로 분할  
- 29%는 “측정 불가능하고 설명 불필요한 시간”으로, 창의성과 자발성이 자라나는 공간  
- Palantir에서 공식화 시도는 실패 → **형식화보다 비공식적 권장과 소통이 효과적**  
- 예: 매주 금요일 비공식 아이디어 공유 시간 제안  
  > “이 시간이 허용된다는 걸 팀원들이 인지하지 않으면, 회의 사이에 몰래 하게 되고 아무 것도 자라나지 않는다”  
  
#### Tip #2: 논쟁은 정기적일수록 좋다  
  
- 훌륭한 제품은 **엔지니어링, 디자인, 제품** 세 분야의 협력에서 탄생  
- 이 협업은 종종 갈등을 수반하지만, 바로 그 논쟁이 **제품 품질을 높이는 핵심**  
- “디자인 문제냐, 제품 문제냐, 기능 이해 문제냐”를 놓고 **팀 내 논쟁이 활발해야** 한다  
- 리더는 **상향식뿐 아니라 하향식으로도 의견 도전을 장려**해야 함  
- 창업자와 직원 간 논쟁이 회사의 방향을 바꾸는 순간이 종종 존재  
  
#### Tip #3: 확장 가능한 운영 시스템을 구축하라  
  
- **좋은 판단력 + 운영력**이 확장성 있는 제품의 기반  
- 판단력이란 단순 결과가 아닌, **"왜 그렇게 결정했는가"를 설명할 수 있는 능력**  
- 책임(Accountability)의 의미는 **"보고할 수 있는 이야기"를 갖는 것**  
- 소수의 판단력이 **전체 시스템으로 확장되기 위해선 명확한 프로세스 필요**  
- 채용 프로세스만 봐도 운영 품질이 드러남 (응답 속도, 일정 명확성 등)  
- 스타트업이라는 핑계로 프로세스를 무시하지 말 것 → **회사를 짓는 것은 곧 운영을 짓는 일**  
  
### 엔지니어링과 제품 팀 간의 관계를 어떻게 강화할 것인가  
  
- 제품팀과 엔지니어링팀의 **긴장과 오해**는 오래된 이야기지만,   
  **질 높은 제품을 확장 가능하게 만들기 위해선 이 관계를 잘 다듬는 것이 필수**임  
  - **나쁜 PM**은 엔지니어가 제품에 **주인의식 없이 따르도록 만들고**,  
  - **좋은 PM**은 엔지니어가 **"왜 이걸 만드는지"를 충분히 이해하도록 도와줌**  
- Lopp은 엔지니어를 **"어떻게(how)"의 사람**, PM을 **"왜(why)"의 사람**으로 정의  
  - 제품팀은 **고객의 이야기를 전하고**, **어떻게 만들지는 엔지니어와 디자이너에게 위임**해야 함  
- **핵심은 "왜"를 공유하는 것**  
  > **PM이 아닌 엔지니어에게 "왜 이 기능을 만드는가?"를 직접 물어보라**  
  - 대답이 "PM이 시켜서요"면 분노  
  - 진짜 문제는 제품팀의 판단이 틀렸기보다는, **엔지니어가 맥락을 이해하지 못한 것**  
    > "엔지니어는 손으로 제품을 만드는 사람이다. 그들이 ‘왜 이걸 만드는가’를 이해하지 못한 채 일하는 조직은 실패한다"  
  - 왜 Slack에는 차단 기능이 없냐는 질문에 Stewart는 **“정보는 모두에게 보이는 것이 중요하다”** 는 철학을 명확히 설명함  
    - **기능이 아닌 비전의 문제**라는 관점 공유  
- 좋은 제품 매니저는 **각 기능이나 아이디어를 제품 전체 비전 안에 맥락화해 전달**할 수 있어야 함  
  - 그게 바로 모든 사람이 집중해야 할 **‘why’의 일부**  
  
### 훌륭한 리더는 어떤 사람인가?  
- [진정한 엔지니어링 리더십](https://review.firstround.com/this-is-what-impactful-engineering-leadership-looks-like/)은 단순한 기술적 역량을 넘어서는 것  
- **“결국 리더십은 사람을 다루는 기술”**  
- # 리더십 특성 #1: 유연성(Malleability)을 갖추고 있다  
  - 리더는 다양한 성향의 사람들과 일하며, 그에 맞춰 **자신의 스타일을 조정**할 수 있어야 함  
  - Pinterest와 Slack에서 전혀 다른 방식으로 팀을 이끌었던 본인의 경험을 예시로 들며 강조  
  - 신규 매니저에게는 항상 같은 질문: _“피드백을 받고 나서 당신은 무엇을 바꾸었는가?”_  
  - 팀 구성 역시 고정된 기준보다, 실제 함께 일하며 드러나는 **강점과 약점을 기반으로 재조직**  
  - 이를 위해 그는 **6개월마다 리오거나이징**을 실행함  
- # 리더십 특성 #2: 스토리텔링 능력이 뛰어나다  
  - **마이크로매니지먼트**에 강한 거부감을 표함: "엔지니어에게 지시하는 것만큼 짜증나는 일은 없다"  
  - 대신, 리더는 **"상자(Box)와 수프(Soup)"** 을 제공해야 함  
    - **상자**: 아이디어와 맥락을 채워 넣은 공간  
    - **국물**: 구성원이 자유롭게 마시거나 조합할 수 있는 정보의 기반  
  - 지시 대신 **영감을 주는 이야기**를 제공하면, 구성원이 스스로 판단하고 성장함  
  - 일부 구성원은 “그냥 뭘 해야 하는지 말해줘요”라고 말하지만, 그조차도 결국 **자기 방식대로 해석함**  
  > 리더의 역할은 수프를 주는 것. 마실지, 뭘 넣을지는 그들의 선택이다.  
- # 리더십 특성 #3: 구성원의 동기와 목표를 이해한다  
  - 리더는 팀원 개개인이 **무엇을 통해 성장하고 동기부여되는지** 알고 있어야 함  
  - 한 예시: 기술 도전이 삶의 원동력인 엔지니어에게는 **끊임없는 문제 해결 기회**를 제공  
  - 또 다른 예시: Palantir의 어시스턴트는 **보상 중심 동기**를 명확히 밝힘 → 명확한 관리 가능  
  - 핵심은 각 사람의 “**단 하나의 핵심 동기**”를 파악하고, 그것에 지속적으로 투자하는 것  
  - 이를 위해선 **호기심(curiosity)** 과 **끊임없는 “왜?” 질문**이 필수  
  > 리더는 구성원이 스스로도 모르는 동기를 발견하고 성장 기회를 만들어야 한다.  
   
### 결론: 성공하는 엔지니어링의 본질은 인간 이해  
  
- **성공적인 엔지니어링 조직은 원활하게 작동하는 인간 역학(Human Dynamics)에 달려 있음**  
  - 훌륭한 제품은 **뛰어난 개인이 아닌, 잘 협업하는 사람들의 집합**에서 탄생함  
  - 리더의 역할은 **조직을 구성하는 사람들에게 힘을 실어주는 것**에서 출발  
- “**엔지니어링 팀은 복잡하고도 멋진 인간들의 거대한 직물(tapestry)** ”  
  - 이 직물의 구조와 흐름을 이해하려는 노력이, **제품의 가치가 조직 전체를 통해 효과적으로 전달되도록 만드는 열쇠**임  
> "사람들이 어떻게 상호작용하는지 이해하려는 동기를 가질 때, 당신의 회사는 제품의 가치를 규모 있게 전달할 준비가 되는 것이다."

## Comments



### Comment 38460

- Author: xguru
- Created: 2025-05-11T12:02:13+09:00
- Points: 1

Michael Lopp 이 운영하는 기술 리더들을 위한 슬랙이 있습니다.   
[RLS - Rands Leadership Slack](https://randsinrepose.com/welcome-to-rands-leadership-slack/)   
관심 있으신 분들은 한번 들어가 보시기 바랍니다. 현재 36000명이 넘게 참여하는 거대 슬랙입니다.  
가입을 위해서는 위 링크에 내용을 잘 읽고 Lopp에게 이메일을 보내면 됩니다.   
이름/직업/왜 가입하고 싶은지/어디서 RLS에 대해 들었는지/자신의 링크드인 이나 트위터등 계정

### Comment 38197

- Author: techiemann
- Created: 2025-05-06T09:12:38+09:00
- Points: 1

비싼 엔지니어를 사왔으면 펜대 굴리는 주제에 엔지니어를 LLM 취급하며 물건 뚝딱거리는 도라에몽 한테 명령 내리 듯 사소한 것 까지 이래라 저래라 하지말고 자기 비전만 공유하고 그걸 구현하는 공학적 접근 방식이야 말로 그 사람 전문분야이니 알아서 하게하라는 거군요  
  
가만히 들어보니 우리나라 시골에 전원주택 짓거나 혹은 구축 아파트 리모델링 하겠다는 사람들이 업자나 시공사 설계사랑 투닥거리는 실랑이질의 흐름이 머릿속에 떠오르는 건 왤까요

### Comment 38293

- Author: nemorize
- Created: 2025-05-07T18:51:40+09:00
- Points: 1
- Parent comment: 38197
- Depth: 1

후자의 케이스는 조금 다른 맥락이지 않을까요?  
  
전원주택이나 구축 아파트 리모델링은  
우선 비즈니스보단 로망 실현에 가까운 영역인데다가,  
건설/리모델링 업체에 믿고 맡겼다 뒤통수 맡는 일이 이상하게 참 많이도 일어나다보니...

### Comment 38500

- Author: groge
- Created: 2025-05-12T12:47:30+09:00
- Points: 1
- Parent comment: 38293
- Depth: 2

주인이 직접 만들지 않고 누군가에게 시킨다면 똑같은 상황이 될 것 같아요.  
아무리 잘 설명해줘도 오해가 있고, 아무리 꼼꼼히 챙겼다고 해도 미처 생각지 못한 영역이 존재하더라고요.  
주인이 말해주지 않은 부분을 일일이 물어보며 만들면 시간이 많이 들어가고 답답하니, 전문가가 알아서 처리하는 부분이 상당히 많은데, 그 부분이 다 실랑이 거리인 것 같아요.  
그나저나 SI 업체에 뒤통수를 많이 안맞아보신 것 같아 부럽습니다.

### Comment 38183

- Author: nicewook
- Created: 2025-05-05T16:15:20+09:00
- Points: 2

최근 읽은 모던 소프트웨어 엔지니어링도 떠오릅니다. 개발 자체가 아닌 팀, 조직에 대해서도 이야기를 하거든요.

### Comment 38178

- Author: haejuk99
- Created: 2025-05-05T12:33:20+09:00
- Points: 4

엔지니어링 리더십에 여러가지 의견과 방법들이 있지만 본질은 구성원에 대한 이해를 바탕으로 한다는 것은 모두 동일한 거 같습니다. 구성원에 대해 이해를 한다는 것이 말은 쉽지만, 서로간의 피드백을 통해 리더와 구성원간의 공감을 바탕으로 신뢰가 쌓여야 하는 부분인 거 같습니다. 한번에 만들어 지는 것은 아닌 거 같네요. 생각해 볼 수 있는 좋은 내용 감사합니다.