엔지니어의 리더십: 엔지니어링 원칙과 조직 설계

작성자:

영국과 러시아 해외연구소장 시절, 현지 엔지니어들로부터 가장 많이 받은 질문이 있습니다.

“엔지니어에서 매니지먼트 트랙으로 옮긴 이유가 무엇인가요?”

생각해보면, 국내 기업 문화에서는 엔지니어가 경력이 쌓이고 매니저가 되는 것을 비교적 자연스럽게 보는 편입니다. 제 경우도 소프트웨어 엔지니어로 입사를 해서, 파트장, 랩장 등 관리자 트랙을 거쳐서 연구소장까지 되었습니다. 하지만 해외, 특히 서구권에서는 기술 전문가 트랙과 매니지먼트 트랙이 비교적 선명하게 나뉘어 있었고, 뛰어난 엔지니어가 끝까지 엔지니어로 남는 걸 더 자연스럽게 받아들이는 것 같았습니다. 그런 관점에서 보면, 저의 경우는 매니지먼트로의 이동이 승진이라기보다 다른 길을 선택한 것으로 비춰졌다고 볼 수 있습니다. 그래서 “왜 그 길을 택했느냐”는 질문이 자연스럽게 따라왔습니다.

이 질문에는 한 가지 전제가 깔려 있습니다. 엔지니어와 매니저는 근본적으로 하는 일이 다르다는 전제입니다. 저도 처음에는 막연하게 그렇게 생각했습니다. 그런데 실제로 매니지먼트를 해 보니, 두 일이 본질적으로 크게 다르지 않다는 것을 알게 되었습니다. 더 정확히 말하면, 소프트웨어 아키텍트로 익힌 엔지니어링 원칙이 조직 운영 의사결정에 그대로 작동했습니다.

흥미로운 것은, 이 둘이 닮았다는 관찰이 제 개인적 경험에 그치지 않는다는 점입니다. 소프트웨어 공학과 조직 이론은 지난 수십 년 동안 서로를 비추는 거울처럼 발전해 왔습니다. 이 글에서는 그 유사성과 차이점을 관련 이론과 실제 사례를 중심으로 정리해 보겠습니다.

참고로, 이 글은 제 경험을 바탕으로 하기 때문에 여기서 말하는 엔지니어는 대부분 소프트웨어 엔지니어를 가리킵니다.

목 차

관리의 본질 — 주어진 리소스로 미션을 완수하는 일

소프트웨어 엔지니어와 매니저가 하는 일을 한 문장으로 정의하면, “주어진 리소스로 주어진 미션을 완수하는 일”입니다. 이 정의는 두 직무 모두에 정확히 들어맞습니다. 다만, 다루는 리소스의 종류가 다를 뿐, 구조는 동일합니다.

이렇게 놓고 보면 두 직무의 사고 단위가 매우 유사하다는 것을 알 수 있습니다. 차이는 다루는 대상의 물리적 성격이지, 사고 방식이 아닙니다.

조직을 설계의 대상으로 본다는 발상 자체는 새롭지 않습니다. 조직 설계 이론의 대표적 틀인 갤브레이스(Jay Galbraith)의 스타 모델(Star Model)은 조직을 전략, 구조, 프로세스, 보상, 인력이라는 다섯 요소의 정렬 문제로 봅니다. 갤브레이스가 강조한 핵심 명제 하나는 “조직 설계는 단순히 구조의 문제가 아니며, 다른 전략은 다른 조직을 요구한다”는 것입니다. 엔지니어가 시스템을 여러 관심사에 대한 정렬 문제로 다루는 것과 정확히 같은 사고입니다.

기능 요구사항 vs. 비기능 요구사항

소프트웨어의 아키텍처를 결정하는 데 가장 중요한 기준은 기능 요구사항(Functional Requirements)이 아니고, 비기능 요구사항(Non-Functional Requirements)입니다.

  • 성능이 중요하면 → 캐싱 레이어, 비동기 처리 구조
  • 가용성이 중요하면 → 이중화, 장애 격리 구조
  • 확장성이 필요하면 → 모듈화, 느슨한 결합
  • 보안이 중요하면 → 계층 분리, 권한 경계

기능이 동일한 시스템을 만들더라도 비기능 요구사항의 우선순위에 따라 전혀 다른 구조의 시스템이 나옵니다.

조직도 마찬가지입니다.

  • 리소스 제약(예산, 인력 풀)
  • 미션의 중요도와 긴급도
  • 의사결정 속도 요구
  • 리스크 허용 수준
  • 인재 육성의 시간 축

같은 미션을 수행하더라도 이 비기능 요구사항에 따라 조직 구조는 달라져야 합니다. 그래서 “정답 조직도”는 없습니다. 컨텍스트에 맞는 조직도가 있을 뿐입니다.

이러한 관점은 조직 이론에서 이미 정리되어 있습니다. 갤브레이스가 1973년 저서 『복잡한 조직의 설계』에서 발전시킨 상황적합 이론(Contingency Theory)의 핵심 명제가 바로 “조직하는 데 하나의 정답은 없다(no best way to organize)”는 것입니다. 최적의 형태는 조직이 처한 내부와 외부 상황에 달려 있다는 관점입니다. 아키텍트가 “정답 아키텍처는 없다, 트레이드오프만 있다”고 말하는 것과 정확히 같은 이야기를 조직 이론은 반세기 전부터 해 온 셈입니다.

이 관점에서 보면 조직 개편은 유행이나 정치가 아닙니다. 비기능 요구사항 변화에 대한 구조적 응답입니다.

엔지니어링 원칙의 작동 방식

조직과 시스템이 같은 구조를 갖는다는 것은 새로운 통찰이 아닙니다. 1968년 멜빈 콘웨이(Melvin Conway)가 관찰한 Conway’s Law는 “시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 닮은 설계를 내놓는다”는 명제로, 시스템과 조직이 서로를 정의하는 관계라는 뜻입니다.

흥미로운 것은 그 역방향입니다. 『팀 토폴로지(Team Topologies)』(2019)는 이 명제를 뒤집어 “우리 조직 구조 때문에 우리가 보지 못하는 더 나은 설계가 있는 것은 아닌가”를 묻습니다. 좋은 시스템을 원하면 조직부터 그렇게 설계해야 한다는 것입니다.

조직과 시스템이 닮는다면, 시스템을 다루는 사고 도구도 조직에 그대로 쓸 수 있습니다. 엔지니어가 구조를 다룰 때 거치는 판단은 크게 세 가지로 나뉩니다.

  • 분해 — 무엇을 어떻게 쪼갤 것인가. 단일 책임 원칙, 관심사 분리가 여기에 해당합니다.
  • 연결 — 쪼갠 것을 어떻게 이을 것인가. 인터페이스 정의, 추상화, 위임이 여기에 해당합니다.
  • 선택 — 여러 대안 중 무엇을 고를 것인가. 트레이드오프 판단이 여기에 해당합니다.

이 세 가지는 엔지니어가 코드를 다룰 때만 쓰는 것이 아닙니다. 조직을 다룰 때도 똑같이 작동합니다. 이제 실제 사례 세 가지를 보겠습니다. 세 사례 모두, 사람 문제로 보이던 것이 사실은 구조 문제였던 경우입니다.

사례 1. 책임이 섞인 팀 — 분해

책임을 어떻게 나눌 것인가의 문제였습니다.

영국연구소장 시절, A와 B 두 주제를 모두 커버해야 하는 팀이 있었습니다. 그래서 시니어 팀장 한 명 아래에 여러 하부 조직을 둘 수밖에 없는 구조였고, 팀장 역할의 후임도 만들 수 없는 상태였습니다.

이걸 아키텍트의 눈으로 보면 진단이 명확합니다.

한 모듈이 두 개의 책임(concern)을 갖고 있는 상태입니다. 단일 책임 원칙(Single Responsibility Principle) 위반입니다. 로버트 마틴(Robert C. Martin)이 정식화한 이 원칙은 “하나의 모듈은 하나의 변경 이유만 가져야 한다”로 요약됩니다. 두 가지 큰 주제를 동시에 안고 있던 그 팀은 변경 이유도 둘이었고, 그만큼 결합도(coupling)는 높고 응집도(cohesion)는 낮았습니다.

시니어 팀장은 리팩토링이 필요한 코드에 어쩔 수 없이 덧붙인 우회 로직과 같았습니다. 구조 문제를 사람으로 메우고 있었던 셈입니다. 후임을 키울 수 없는 이유도 여기서 나옵니다. 책임 경계가 모호하면 주니어가 책임지고 가져갈 영역이 없습니다. 자기 영역이 없으면 성장 경로도 없습니다.

해법은 조직을 둘로 분리하고, 각 조직에 젊은 팀장을 배치하는 것이었습니다.

  • 모듈 분리 = 책임 경계 명확화
  • 젊은 팀장 = 명확해진 책임 범위 안에서 ownership 확보
  • 시니어 리소스 = 더 상위 레이어로 재배치

사람 문제로 보이던 것이 실은 구조 문제였습니다. 구조를 고치니 인재 육성 문제까지 함께 풀렸습니다.

사례 2. 이름 규칙과 계층 구조 — 연결

흩어진 것을 어떻게 이을 것인가의 문제였습니다.

팀별로 이름을 정한 규칙이 다르고, 계층 구조의 깊이(depth)도 제각각인 조직이 있었습니다. 외부에서 조직도를 보면 헷갈렸고, 내부적으로도 팀 간 비교와 관리가 어려웠습니다. 이는 영국/러시아 모두에서 공통적으로 발견된 상황입니다.

이것도 아키텍트의 눈으로 보면 익숙한 패턴입니다.

동일 시스템 안에서 모듈마다 네이밍 컨벤션이 다른 상황과 같습니다. API 일관성 위반입니다. 계층의 깊이가 다르다는 것은 추상화 레벨(level of abstraction)이 맞지 않는다는 뜻입니다. 같은 호출 깊이에서 의미 단위가 서로 다르면, 그 인터페이스를 쓰는 쪽은 인지 부하를 겪습니다.

조직에서 그 인터페이스를 쓰는 쪽은 외부 조직, 경영진, 그리고 다른 팀입니다. 이들이 헷갈려한다는 것은 인터페이스 설계가 실패했다는 명확한 신호입니다.

해법은 이름 규칙을 통일하고 계층 깊이를 유사하게 맞추는 것이었습니다.

  • 이름 통일 = 일관된 API 컨벤션
  • 계층 구조 동일화 = 추상화 레벨 정렬

결과적으로 외부 가독성이 올라가고, 팀 간 비교와 관리가 쉬워졌으며, 리소스를 재배치할 때 마찰이 줄었습니다.

조직도는 외부를 향한 인터페이스입니다. 인터페이스 설계 원칙이 그대로 적용됩니다.

사례 3. 두 조직의 재구성 — 선택

업무를 묶는 방식이 여러 개 있을 때 어떻게 묶을지에 대한 문제였습니다.

서로 다른 두 조직의 규모가 제각각이라 관리 비용이 균일하지 않았습니다. 한쪽은 비대하고 한쪽은 빈약한 상태로, 관리 범위(span of control)도 맞지 않았습니다. 역시 영국/러시아에서 공통으로 발견한 상황입니다.

가장 흔하고, 쉬운 접근은 사람 수를 옮겨서 규모를 맞추는 것입니다. 그러나 이건 임시방편입니다. 모듈 크기가 제각각인 코드베이스에서 변수만 다른 모듈로 옮기는 것과 같습니다. 응집도가 낮아진 채로 크기만 맞추면, 다음 문제가 또 생깁니다.

진짜 해법은 태스크 단위 분석입니다. 모듈을 함수 단위로 분해해 의존성과 호출 관계를 파악하듯, 조직을 실제 수행 태스크 단위로 분해해 보는 것입니다.

해법은 두 조직의 모든 태스크를 분해한 뒤, 관련성이 높은 태스크끼리 묶어 재구성하는 것이었습니다.

  • 태스크 분해 = 함수 단위 분해
  • 관련성 분석 = 의존성과 호출 그래프 분석
  • 관련성 높은 것끼리 재배치 = 응집도 기준의 모듈 재구성

결과적으로 조직별 규모가 자연스럽게 균형을 찾았고, 관리 비용이 비슷해졌으며, 팀 내부 협업 효율이 올라갔습니다.

이것이 바로 조직 리팩토링입니다. 외부 동작(미션, 산출물)은 유지한 채 내부 구조를 더 응집도 높게 재배열한 것입니다. 코드 리팩토링과 동일한 원칙이, 동일한 이유로 작동합니다.

조직 개편을 “사람 재배치”로 보면 정치가 됩니다. “태스크 재배치”로 보면 엔지니어링이 됩니다.

하지만, 사람은 컴퓨팅 리소스가 아니다

여기까지만 보면 마치 매니징과 엔지니어링이 아예 같다는 인상을 받을 수 있습니다만, 현실은 그렇지 않습니다. 결정적으로, 컴퓨팅 리소스는 불만이 없습니다. 사람은 아닙니다.

  • CPU는 재배치해도 서운해하지 않습니다.
  • 모듈은 폐기(deprecated)해도 항의하지 않습니다.
  • 함수는 리팩토링의 의도를 납득할 필요가 없습니다.
  • 컴퓨팅 리소스는 마음을 다스릴 필요가 없지만, 사람은 아키텍트도 자기 마음부터 다스려야 합니다.

흥미롭게도, 단일 책임 원칙을 만든 로버트 마틴 자신도 이 지점을 짚었습니다. 그는 “아키텍처 변경의 이유는 결국 사람이다. 변경을 요청하는 것은 사람”이라고 말합니다. 모듈을 나누는 기준조차도 끝까지 따라가면 결국 사람에게 닿는다는 것입니다. 기술 원칙의 끝에 사람이 있다는 이 통찰은, 조직 운영에서는 출발점이 됩니다.

그래서 조직 운영에는 엔지니어링 원칙 위에 레이어가 하나 더 필요합니다. 구조적으로 옳은 결정과, 그 결정을 사람이 받아들일 수 있게 만드는 과정은 다른 문제입니다. “리팩토링이 필요하다”는 판단과 “지금 이 사람에게 어떻게 말할 것인가”는 별개의 영역입니다.

엔지니어가 매니저로 옮길 때 가장 크게 배워야 하는 것이 바로 이 지점입니다.

엔지니어링 원칙은 필요조건이지 충분조건이 아닙니다. 구조를 보는 눈을 갖되, 사람과 소통하는 법은 별도로 배워야 합니다. 좋은 엔지니어가 자동으로 좋은 매니저가 되지는 않는 이유입니다.

AX 시대의 조직 설계

이 관점은 AX 시대에 더 또렷해집니다. AI가 일하는 방식을 바꾸면서, 일을 태스크 단위로 분해하고 다시 묶는 능력, 즉 조직을 리팩토링하는 눈이 리더의 핵심 역량이 되고 있습니다. AI 도구가 들어오면 워크플로우가 바뀌고, 워크플로우가 바뀌면 그것을 담는 조직 구조도 바뀝니다. 워크플로우 재설계가 곧 조직 설계인 셈입니다. 조직이 낮고 넓어지는 흐름은 그 구조적 응답의 한 형태입니다. 이 부분은 지난 글 「AI시대: AI-native 조직구조는? 더 낮고 더 넓게」에서 자세히 다뤘고, 이때 인사와 조직 설계가 운영을 지원하는 역할에서 변화를 설계하는 역할로 옮겨가야 한다는 점은 「AI시대: 인사와 조직 설계, 무엇이 바뀌어야 하는가」에서 이어 다뤘습니다.

그런데 바로 여기서 앞 절의 이야기가 다시 등장합니다. AI는 구조를 분석하고, 태스크를 분해하고, 더 나은 배치를 제안하는 일은 점점 더 잘하게 될 것입니다. 그러나 그 결정을 사람이 받아들이게 만드는 일, 변화의 한가운데 선 사람을 설득하고 함께 움직이게 하는 일은 여전히 사람의 몫입니다. AI가 구조 설계를 거들수록, 사람을 다루는 능력의 상대적 가치는 오히려 올라갑니다. 미들 매니저의 역할이 정보 전달에서 워크플로우 설계로, 그리고 사람을 잇는 일로 옮겨가는 이유이기도 합니다. 이 변화는 지난 글 「AI시대: 중간 관리자가 중요하다」에서 다룬 바 있습니다.

맺음말

처음 질문으로 다시 돌아갑니다. “엔지니어에서 매니지먼트 트랙으로 옮긴 이유가 무엇인가요?”

지금이라면 “같은 일을 더 큰 단위로 하게 된 것”이라고 답할 것 같습니다. 다루는 리소스가 컴퓨팅에서 사람으로 바뀌었고, 설계의 대상이 소프트웨어에서 조직으로 바뀌었습니다. 같은 엔지니어링 원칙을 다른 대상에 적용한 것입니다. 다만 그 새로운 대상에는 엔지니어링으로 풀리지 않는 영역, 사람의 마음이라는 영역이 있습니다.

좋은 엔지니어는 좋은 매니저가 될 잠재력이 있습니다. 단, 자동으로 되는 건 아니고, 같은 원칙을 새 도메인에 의식적으로 적용하고, 그 위에 사람을 다루는 법을 새로 배울 때만 그렇습니다.

구조를 보는 눈은 가져가되, 사람 앞에서는 처음부터 다시 배워야 합니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기