# Egoless 엔지니어링 > Clean Markdown view of GeekNews topic #18096. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=18096](https://news.hada.io/topic?id=18096) - GeekNews Markdown: [https://news.hada.io/topic/18096.md](https://news.hada.io/topic/18096.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2024-12-04T10:35:50+09:00 - Updated: 2024-12-04T10:35:50+09:00 - Original source: [egoless.engineering](https://egoless.engineering) - Points: 30 - Comments: 7 ## Summary 기술 업계에서는 이고와 파벌주의가 팀워크를 방해하며, 이는 비효율적인 조직 구조와 업무 분업의 문제로 이어질 수 있습니다. 성공적인 엔지니어링 팀은 이러한 문제를 해결하기 위해 역할과 작업의 혼동을 피하고, 협력과 공감을 통해 경계를 허물며, 모든 팀원이 다양한 업무에 참여하도록 장려합니다. 또한, 팀원들에게 여유 시간을 제공하고, 협력을 촉진하는 문화를 조성하여 조직의 효율성을 높이는 것이 중요합니다. ## Topic Body ### 이고를 배제한 엔지니어링: 교훈과 통찰 #### 서론 - 기술 업계에서 이고와 지역주의(파벌주의)는 팀워크를 방해하는 주된 요소로 작용함 - 엔지니어링 팀을 더 효율적이고 협력적으로 만드는 방법을 고민하며 얻은 통찰을 공유 #### 책임 분배의 딜레마 - 직원이 두 명만 있어도 업무 분배는 필수적임 - 그러나 분배 방식은 즉각적이며 장기적인 영향을 미칠 수 있음 - 많은 기업이 이러한 문제를 깊이 고민하지 않음 #### 컴퓨터 과학의 현실 - 많은 컴퓨터 과학자는 자신이 수학적 추상 작업과 관련된 학문에 발을 들였다는 사실을 나중에 깨달음 - 이 초기 충격으로 인해 대부분의 경력을 컴퓨터 외의 분야에는 배운 내용을 적용하지 않으려는 태도를 보임 - 업무 환경을 기술적 접근만큼 깊이 고민한다면 개선될 가능성이 있음 #### 조직에서의 병폐와 경험 - 성공적인 회사도 조직 병폐를 피하기 어렵고, 이를 통해 배울 수 있음 - 초기 경력을 보낸 한 스타트업 사례: - 회사가 작은 초기 단계임에도 불구하고 이미 지나치게 관료화된 구조를 채택 - 웹 요청 속도를 높이겠다는 잘못된 이론으로 "파이썬 미들레이어"를 추가 - 결과적으로 더 많은 네트워크 홉이 발생해 성능이 저하됨 - 하나의 기능을 출시하려면 여러 역할 간의 복잡한 협력이 필요 - 데이터베이스 작업자는 DDL 작성 및 저장 프로시저 개발 - 파이썬 개발자는 비효율적인 미들레이어 작업 - PHP 개발자는 프론트엔드 코드 작성 - 이러한 분업 구조로 인해 두 해 동안 신규 기능을 전혀 출시하지 못함 - 결과 - 비효율적 구조와 워크플로우의 결과로 전 직원이 해고됨 - 난 아님. 불만 제기로 살아남음 #### 대규모 회사에서의 역할 분화 문제 - **배경**: 1,000명 이상의 직원을 보유한 B2B 제품 회사에서 근무 - 초기에 역할이 명확히 나뉜 기능별 팀(Feature Teams)과 공용 서비스 팀(운영, DBA 등) 구조를 운영 - 초기에는 일반적인 구조처럼 보였음 - 시간이 지나면서 역할이 과도하게 분화되며 비효율성이 증가 - "Release Manager"라는 새로운 역할을 추가해 릴리스를 관리 - 역할 추가의 이유가 명확하지 않고, 점점 복잡해지는 조직 구조 - **문제 사례**: - 프론트엔드 엔지니어는 프론트엔드 작업만, 백엔드 엔지니어는 백엔드 작업만 수행하도록 제한 - 이러한 분리는 생존 가능했지만, 보안 팀이 모든 보안 작업을 전담하도록 한 정책은 심각한 문제를 초래 - **결과**: 역할을 작업과 동일시하면서 조직 효율성을 저해하게 됨 - 팀 간 협력 부족과 업무 중복이 발생 ### 분산된 제품 포트폴리오와 감독 구조의 부재 - 주로 네이티브 클라이언트 애플리케이션을 개발하는 회사에서 근무 - 초기에는 성공적인 주력 클라이언트 애플리케이션이 있었지만, 2020년대에는 분산되고 일관성 없는 프로젝트들이 병렬적으로 진행됨 - 제품 포트폴리오 관리의 문제점 - 전체 제품에 대한 감독 구조가 약함 - 기술 스택이나 의사결정에서 제품 간 조율이 전혀 이루어지지 않음 - 각 제품 팀은 독립적으로 CEO에게 보고하며, CEO는 조정 노력을 기울이지 않음 - 공용 운영 기능 구축 시도 - 운영 그룹이 아키텍처 결정 과정에 관여하지 않아 어려움이 발생 - 운영 팀은 과거에 개발 팀이 사용했던 수백 개의 서비스 관리에 바빠 중요한 의사결정에 참여할 시간이 부족 - 이는 조직적 비효율성의 전형적인 사례로 볼 수 있음 ### [조직 문제 패턴 일반화 하기] #### 패턴 1: 역할과 작업의 혼동 - 새로운 업무를 위해 새로운 직무 설명을 만드는 경향이 있음 - 예: AI 관련 업무를 기존 엔지니어가 처리할 수 있음에도 불구하고, AI 엔지니어라는 새로운 역할을 신설 - 이는 조직 내 갈등을 유발하며, 기존 팀원의 동기를 약화시킬 수 있음 - 이러한 과도한 역할 분리는 불필요한 관료주의를 초래 #### 패턴 2: DevOps 혁명의 불완전한 분포 - 많은 회사가 "DevOps를 구현했다"고 주장하지만, 실제로는 분업과 갈등이 여전히 존재 - 운영팀과 개발팀, 혹은 SRE와 개발팀 간의 명확한 경계는 협력을 저해 - DevOps의 본래 목적은 협력과 공감을 통한 경계 허물기지만, 현실에서는 드물게 실현됨 #### 패턴 3: 엄격한 업무 분업의 한계 - 업무를 세분화하고 전문화하는 것이 리더에게는 당연해 보일 수 있음 - 예: AI 업무는 AI 전문가, 운영 업무는 운영 담당자에게 전담 - 하지만 이러한 구조는 병목 현상을 야기 - 추가된 엔지니어가 새로운 작업을 생성해 속도를 높이려 하지만, 결과적으로 분석 대기 시간이 비선형적으로 증가 - 데이터 과학자나 분석 리소스가 한계에 도달하면 전체 프로세스가 느려짐 #### 패턴 4: 잘못된 조직 구조는 추가 작업을 초래 - 조직 경계가 명확하지 않거나 잘못 설정되면 불필요한 작업량이 증가 - 예: 보안 팀이 모든 보안 문제를 담당하며, 보안 티켓 큐가 생김 - 개발 팀은 보안을 고려하지 않으면서 작업을 진행, 결과적으로 보안 작업이 늘어남 - 이는 단기적으로는 무시될 수 있지만, 장기적으로 심각한 문제로 발전 #### 패턴 5: 인간의 고질적인 편견 - 자신의 역할을 과대평가하고 타인의 역할을 과소평가하는 경향 - 일부는 서버 작업이 "기술적이지 않다"고 잘못 판단 - 반대로, 제품 작업이 덜 기술적이라고 여기는 경우도 흔함 - 이러한 태도는 팀 간 신뢰를 약화시키고 협력을 저해 - "뛰어난 독단적 인물"은 시스템적 관점에서 실질적인 가치를 제공하지 못함 - 리더와 조직은 이러한 태도를 "똑똑하다"거나 "가치 있다"고 잘못 평가하는 경우가 많음 ### [파벌주의와 이고] - 파벌주의(Parochialism)와 이고(Ego)는 조직 내 주요 비효율성의 원인 - **파벌주의**: 타인의 영역을 침범하지 않으려는 태도나 호기심 부족 - **이고**: 업무에 대한 자부심으로 긍정적 영향을 줄 수도 있지만, 영역 지키기나 타인의 능력을 과소평가하는 부정적 영향으로 나타날 수 있음 - 이러한 본능적인 행동들은 공감 부족을 야기하고 협력을 저해 ### 더 나은 사례: 성공적인 엔지니어링 팀의 경험 - 과거 한 스타트업에서 수평적으로 분리된 "영지(fiefdom)" 구조를 단순화하고 더 작은 팀으로 재편 - DevOps를 진지하게 도입한 리더들이 장벽을 허물고 협력을 촉진 - 약 2년간의 "창의적 파괴"를 통해 모든 팀원이 다양한 업무에 참여 - 결과적으로 인프라 안정성과 소프트웨어 출시 역량 회복 - 조직 재편 후 엔지니어링 팀이 시간과 자율성을 확보 - 이를 바탕으로 팀의 추가 역량을 어떻게 활용할지 논의 #### 제안 1: 대규모 리팩터링 (Proposition 1: Boil the Ocean) - 종종 팀들은 여유 자원을 사용해 싫어하는 부분을 전면적으로 리팩터링 - 하지만 이는 이미 시도된 방법으로 인기가 없었음 #### 제안 2: "자기 과시" 활동 (Proposition 2: Dress Like Big Dorks) - 팀의 유휴 시간을 사용해 팀 문화를 강조하는 상품 제작 등 시도 - 그러나 이것은 주요 전략으로는 적합하지 않았음 - 결정적 사건: 디자이너의 빌드 오류 - 한밤중 디자이너가 빌드를 깨뜨렸고, 팀은 이를 복구해야 했음 - 처음에는 디자이너와 코더 간의 역할을 더 명확히 나누자는 의견이 제기 - 그러나 팀의 한 사람이 디자이너에게 배포 키를 직접 제공하는 과감한 결정을 내림 - 결과: - 디자이너가 코드 작업에 참여하며 협업 수준이 향상 - 팀은 모니터링, 테스트 스위트 등을 구축해 안전한 작업 환경 조성 - 작업 효율성과 생산성이 크게 개선 #### 제안 3: 다른 팀의 역량 강화 (Proposition 3: Empower Everybody Else) - 팀의 여유 자원을 활용해 다른 팀을 지원하고 역량을 강화하는 전략 채택 - 기술적, 비기술적 팀 모두에 적용 - 조직 전반의 협력을 촉진하고 효과적인 실행으로 연결 #### 실천 의지 - 디자이너 사례 이후 다양한 그룹과 협력하며 비슷한 성공을 경험 - 팀의 자유 시간과 조직적 권한을 활용해 각 팀이 효과적으로 협력할 수 있도록 지원 - 성공적인 실행은 전사적 협력과 공감이 기반이었음 ### [성공적인 실행의 느낌] - **전문가 vs. 소유자** - 팀은 도메인 전문가를 두되, 특정 작업이나 도메인의 "소유자"를 두지 않음 - **보안 사례**: 보안팀이 모든 문제를 처리하는 대신, 팀 전체가 보안을 책임지고 보안팀은 팀원들의 역량을 향상시키는 역할 - 다른 분야에서도 이 모델이 적용되었어야 했지만, 대부분의 팀은 실현하지 못함 - **실패 사례** - 프론트엔드와 백엔드 엔지니어를 철저히 분리 - 협력 부족으로 인해 GraphQL 같은 불필요한 복잡성을 초래 - 특정 역할의 전문가는 필요하지만, "프론트엔드"와 "백엔드"로 직함을 나누는 것은 비효율적 - **핵심 원칙**: - "도메인 전문가, 소유자는 아님" - 전문가가 자신의 업무 외에도 다른 팀원을 도울 시간을 확보하도록 유도 #### 프로액티브한 협업 촉진 - **여유 시간 제공** - 전체적인 팀워크를 유지하기 위해 팀원들에게 여유 시간을 부여 - 단순히 자연스러운 협력을 기다리지 않고, 의도적으로 시스템에 활력을 불어넣음 - **심리적 안전과 인그룹 확장** - 사람들은 자신이 속한 그룹에서 심리적 안전감을 느끼며 실험하거나 새로운 것을 배움 - 팀원들의 "인그룹"을 확장하기 위해 시간과 자원을 투자 - **부트캠프**: 다른 팀에서 강제로 근무하게 하여 협업 기회 제공 - **해커톤**: 비슷한 효과를 내는 이벤트로 활용 #### 의도적인 팀 가치 - **팀의 철학과 원칙 정립** - 코드 리뷰, 부트캠프, 해커톤 등 다양한 활동의 높은 목표를 명확히 정의 - 엘리트주의는 독이라고 선언 - 모든 구성원이 "필요한 일을 직접 처리"하는 문화를 조성 - **상호 신뢰와 개선 기대** - 다른 사람의 작업물을 다룰 때 항상 더 나은 상태로 남기겠다는 강한 기대 설정 - 이러한 문화는 팀원들이 기꺼이 협력하도록 유도 ### 마무리 생각 - **기술 업계의 문제: 엘리트주의와 독단적 리더십** - 겸손이 결여된 독단적 리더는 팀의 협력을 저해하고 불필요한 잔혹함을 조장 - 기술 업계는 종종 이러한 독단적 리더를 유용한 존재로 착각하지만, 이는 기생적이고 해로운 현상 - 타인을 존중하는 행동이 급진적이어야 할 이유가 없지만, 현실적으로 그렇지 않음 - **협력이 더 나은 결과를 가져옴** - 협력은 결과를 개선하고, 독단적 리더가 없는 삶은 더 나아짐 - 파벌주의와 이고를 없애기 위한 노력이 필요 - **권한 부여의 중요성** - 팀원들이 호기심을 가지고 협력하도록 격려하려면 리더의 허가와 지지가 필요 - 예: 배포 작업을 SRE가 아닌 개발자가 직접 처리하도록 변경 - 초기에는 개발자의 실수에 대한 우려가 있었지만, 대부분의 개발자가 문제를 스스로 해결하며 성공적이었음 - 제품 엔지니어들이 스스로 문제를 처리하고자 하는 태도를 보여줌 - **시스템에 여유(slack) 제공** - 부트캠프나 해커톤 같은 프로그램은 지속적인 헌신이 필요 - 이러한 프로그램은 시스템의 여유가 없으면 사라지기 쉬움 - 우리는 컴퓨터를 100%로 가동하지 않지만, 스스로에게는 그렇게 하려는 경향이 있음 - **가치와 보상의 중요성** - 리더는 협력과 호기심을 보상하고 이를 팀 문화로 정착시켜야 함 - CEO들은 종종 긍정적인 프로그램(부트캠프, 해커톤)을 없애려 하지만, 부정적인 프로그램(의무적 코드 리뷰)을 없애려는 노력은 부족함 - "고통"이 결과를 가져온다는 잘못된 믿음은 버려야 함 - 고통은 결과의 대리 지표로 적합하지 않으며, 협력과 신뢰가 더 나은 성과를 가져옴 ## Comments ### Comment 32060 - Author: jhj0517 - Created: 2024-12-05T20:42:06+09:00 - Points: 1 > 팀원들이 호기심을 가지고 협력하도록 격려하려면 리더의 허가와 지지가 필요 꼭 본인의 영역이 아닌 팀원의 영역에 호기심을 갖도록 격려하는 것이 중요한 것 같습니다! ### Comment 32053 - Author: yongbam - Created: 2024-12-05T13:11:35+09:00 - Points: 1 현실은...! ### Comment 32048 - Author: clastneo - Created: 2024-12-05T10:55:42+09:00 - Points: 1 매일같이 진척 쪼아대는 웨자일 스타트업에서는 불가능한 구조군요.. 모든 실무진이 입사 초기의 흥미를 계속 유지할 수 있어야 하는데, 그런 측면에 대한 지원이 보통은 없거나 부족하더라고요. ### Comment 32034 - Author: eyelove - Created: 2024-12-04T16:12:19+09:00 - Points: 1 구구절절 맞는말이네요.. 하지만 현실은..................ㅠㅠ ### Comment 32032 - Author: silveris23 - Created: 2024-12-04T13:41:15+09:00 - Points: 1 진짜 좋은글 같네요! ### Comment 32025 - Author: kandk - Created: 2024-12-04T12:07:21+09:00 - Points: 1 좋은글입니다. ### Comment 32023 - Author: neo - Created: 2024-12-04T10:35:51+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=42311069) - 소프트웨어 개발에서 프로그래머의 자아를 배제하는 것이 중요하다는 의견이 있음. 팀워크를 통해 소프트웨어 제품을 팀의 성과로 보는 것이 바람직함. - 그러나 인간의 자아는 자연스러운 것이며, 이를 완전히 배제하기 어려움. - 효과적인 시스템은 인간의 기본적인 특성을 인정하고 그 안에서 작동해야 함. - 개발 경력에서 얻은 교훈으로, 불필요한 프로세스를 추가하지 말고, 모든 역할에서 제품의 소유권을 요구하며, 반응적인 결정을 피하고, 팀 간의 협력을 장려해야 한다고 조언함. - 최고의 팀은 전체 스택을 소유하는 피자 팀과 필요할 때 조언을 제공하는 전문가들로 구성됨. - 모든 사람이 온콜 상태일 때 문제를 신속하게 해결할 수 있음. - 과거에는 작업이 너무 복잡하고 전문적이어서 이러한 접근이 흔하지 않았음. - 스포츠 메타포는 기술 분야에서 인기가 없지만, 스포츠 팀의 역학은 좋은 비즈니스 팀과 유사하다는 의견이 있음. - 조직의 성공은 각 구성원이 그룹의 필요를 충족시키기 위해 이타적으로 행동하는 데 달려 있음. - 이타심은 에너지와 생산성을 소모하는 기생적 요소임. - 연민은 이타심의 치료제이며, 도덕적 나침반의 방향을 맞추는 데 도움을 줌. - 의도적인 팀 가치 설정의 중요성을 강조함. - 모든 사람이 어떤 작업도 수행할 수 있어야 하며, 환경을 개선하는 것이 중요함. - 성장 부서에서 일하면서, 처음에는 매니저가 모든 커밋을 검토하고 병합했지만, 나중에 자신이 직접 프로덕션에 배포할 수 있는 권한이 있었음을 깨달음. - 도메인 전문가가 도메인 소유자보다 선호되며, 지나치게 명시적인 전문화는 문제를 일으킬 수 있음. - 그러나 모든 사람이 자율성을 가질 수 있는 것은 아니며, 이는 팀의 기술 수준과 동기 부여에 따라 달라짐. - 대규모 프로젝트에서는 더 많은 프로세스와 가드레일이 필요할 수 있음.