기본 콘텐츠로 건너뛰기

조직과 문화의 개선에 Bottom Up은 불가능하다.

조직과 회사를 개선하는 방법에는 크게는 2가지 접근법이 있습니다.

하나는  Buttom Up이고 하나는 Top Down 입니다.

근래에는 2가지를 섞은 샌드위치 형이나 다른 접근방법도 있긴 하지만 대체로 보면 위 2가지가 가장 큰 접근법입니다.

저는 2가지 접근법 중 상향식 접근방법은 불가능하다고 생각하는 입장입니다.

상향식이란 가장 말단 조직 또는 구성원들로부터 풀뿌리식으로 성과를 내고 그 성과과 전사적으로 펴저냐가는 방식이라고 볼 수 있습니다.

애자일 진영에서 가장 선호하는 방식중의 하나이고 실제로도 많이 시도되는 방식중의 하나입니다.

하지만 전 이 방법의 성공 가능성에 대해 회의적입니다.

조직과 회사가 작고 말단 직원으로부터 회사의 경영층까지의 의사소통 구조가 단순하다면 분명 가능할 수 있는 방식입니다.

하지만 조직이 조금만 더 커지고 의사결정이 복잡해 질 수록 이 방법의 성공률은 극도록 저하됩니다.

특히 회사가 작은 중소기업에서 급격한 성장세를 구가하는 단계에 접어들게 되면 성공률은 더욱더 떨어지게 됩니다.

이유인즉슨.. 회사는 이윤을 목적으로 하는 집단이기 때문입니다.

이윤을 목적으로 한다는 것은 최소한의 투자로 최대한의 이익을 얻어야 한다는 것입니다.

최소한의 투자를 한다는 것은 리스크가 최소로 관리되어야 한다는 것입니다.

리스크가 최소로 관리되어야 한다는 것은 검증된 방법 즉, 안전한 것에만 투자하게 된다는 것입니다.

문제는 이러한 순환고리가 고착화 될 경우 회사는 경직되고 처음의 그 에너지는 많은 손상을 입게 된다는 것입니다.

문제가 커지고 더 이상 방치할 수 없는 단계에 이르게 되면 그 때에서야 조직은 변화에 대한 필요를 인식하고 변화하기 위한 노력을 하게 됩니다.

하지만 우리가 흔히 신념, 가치관, 정책이라고 부르는 것은 쉽게 바뀌지 않게 됩니다.

안전한 것, 리스크가 적은 방법만을 우선시하던 조직 문화는 그렇게 쉽게 바뀌지 않습니다.

이러한 문화는 회사의 신념, 가치관, 정책에 배치되는 다른 신념, 가치관, 정책을 받아들이기 힘들게 만듭니다.

즉, 밑에서부터 시도되는 무수한 변화의 의지가 회사의 신념, 가치과, 정책과 배치된다면 그 변화의 의지는 받아들여질 수 없습니다.

우리는 흔히 안전하게 파일럿 프로젝트 또는 태스크 포스 팀을 구성해서 검증해 보고 효과와 효율이 검증된 경우 전사로 확장한다는 상향식 방법에 대해 큰 거부감이 없습니다.

하지만 이것은 너의 아이디어가 훌륭하기만 하다면 회사가 전폭적으로 지원해 주고 밀어줄께 라는 약속이 얼마나 덧없는 약속이고 지켜질 수 없는 약속인인지 알고 있다면 상향식도 마찬가지라는 것을 알 수 있을 것입니다.

조직과 회사에서 구성원은 영원한 을이면서 영원한 약자일 수밖에 없습니다.

그들이 진정 조직과 회사에서 의사 결정을 이루고 힘을 발휘하는 경우는 찾아보기 힘듭니다.

그런 의미에서 회사라는 조직에서 민주주의는 허상에 불과하다고도 할 수 있을 것입니다.

이런 의미에서 보면 우리는 회사에서 개인의 발전과 꿈을 이루는 것이 얼마나 어렵다는 것인지 쉽게 알 수 있습니다. 내가 꿈꾸고 내가 원하는 것이 회사의 신념과 정책, 가치관과 배치되는 입장에 놓여 있다면 그것이 아무리 옳은 방법일지라도 회사에서 받아들일 수 있도록 설득하는 것이 얼마나 어려운지 이해가 됩니다.

혹자는 회사에서 개인적인 성취를 꿈꾸지 말라고 합니다. 회사는 단순한 생계유지의 수단으로 생각하고 개인적인 성취는 다른 곳에서 이루라고 말합니다.

애자일 방법론과 같은 최근의 방법론이 많은 경우 도입되지 못하는 것도 이러한 측면이 있다고 생각합니다.

컨설턴트들도 상향식을 즐겨 사용합니다.

이유인즉, 안전하고 지속적인 수입을 보장하기 때문입니다. 또 고객이 원하는 경우도 그렇습니다.

결론적으로 상향식 방법은 크게 2가지 관점에서 성공하기 어렵습니다.

첫번째는 상향식 방법은 대체로 부분 최적화에 그치는 경향이 강합니다. 그러한 부분 최적화를 모아서 전체 최적화를 이룬다는 환상은 불가능합니다. 부분 최적화를 아무리 모아도 전체는 최적화 되지 않습니다.

두번째는 회사는 검증되지 않거나 리스크가 큰 즉, 회사의 신념과 가치관 정책에 위배되는 방법론을 무력화 시키거나 무효화 시키는데 상향식 접근법을 즐겨 사용한다는 것입니다.

조직이 진정으로 다시 한번 변혁을 일으키고 싶다면 상향식 보다는 하향식이 훨씬 더 큰 파급력을 지닙니다.

문제는 하향식의 경우 경영층이 잘못된 선택을 하게 된다면 돌이키기 힘들다는 점입니다.

그리고 하향식의 다른 문제점은 경영층이 바뀐다면 그 정책이 지속되지 못할 것이고 그 효과와 성과는 신기루처럼 사라져 버린다는 것입니다.

하지만 우리가 올바른 선택을 지속할 수 있다면 그 효과는 배가 될 것입니다.

그런 점에서 관리층과 경영층은 정말 열심히 공부를 해야 합니다.

관리가 무엇이고 경영이 무엇인지 잘 알고 있어야 할 필요가 있습니다.

회사는 지속 가능한 신념과 정책, 가치관에 많은 투자를 해야만 합니다.

이 세상에 프로젝트를 성공으로 이끌고 회사를 지속 가능하도록 유지하게 만드는 신비의 영약이나 은총알 같은 것은 없습니다.

때문에 우리는 충분히 좋은 선택을 해야 합니다.

여러분은 충분히 좋은 선택을 하기 위해 어떤 노력을 하고 계시나요?

댓글

  1. bottom up 개혁은 성공하기 힘들죠. 저도 컨설턴트이지만, 항상 Top-down 개혁을 주장합니다. 컨설턴트가 아무리 도와 준다고 해도 경영자의 통찰력이 가장 중요하더군요.

    답글삭제
  2. 애자일 진영에서 상향식을 선호한다는 것은 잘 모르겠네요.



    일반적으로 모든 기술의 라이프 싸이클 초기에는 얼리어댑터들(CEO, CTO가 얼리어댑터인 경우는 드물죠)이 먼저 도입을 하고 그 전파는 상향식으로 일어나는 경향이 있습니다(무어의 캐즘 이론). 애자일이 비교적 새롭기 때문에 그랬던 것 같고요.



    요즘은 애자일이 캐즘을 넘었다는 보고가 많아지고 있어서인지, 애자일을 하향식으로 적용했다는 사례도 점차 증가하고 있습니다. (대략 2005년이 분수령이었다고 봅니다)



    쓰신 글에 상당 부분 공감을 합니다. 상향식, 리스크가 큽니다. 하향식도 약간 언급하셨지만 상향식 만큼의 리스크가 존재한다고 봅니다.

    답글삭제
  3. 전 아직 경험이 없어서 그런지 상향식이 더 강력하지 않을까 싶습니다. (물론 부분최적화가 될수도 있겠지만..)

    사람 일인데 단정짓기에는 무리가 있지 않을까요?^^

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

스위치봇 & 스위치봇 허브 미니 간단 사용기

제 블로그에 예전부터 오셨던 분들은 제가 사브작 사브작 홈 오토메이션을 어설프게 해온 것을 아실겁니다. 작년부터 너무 하고 싶었던 도어락 자동화에 도전해봤습니다. 우리 나라에 자체 서비스로 앱을 통해 도어락을 제어하는 제품은 꽤 있습니다. 게이트맨도 있고, 키위도 있고, 삼성도 있죠.. 그런데.. 전 그것보다 구글 어시스턴트를 지원하는 도어락이 필요했는데... 그런건 안만들더라구요.. 꼭 필요한건 아니지만 웬지 해보고 싶은데... 언제 제품이 출시될지도 몰라서.. 가능한 방법을 찾아보다가.. 스위치봇이라는 제품으로 도어락을 버튼을 꾹 누르는 방법을 찾아서 스위치봇이 직구가 아닌 국내에 출시되었길래 낼름 구매해서 도전해봤습니다. 스위치봇 제품에 대한 내용이나 구매는  https://www.wakers.shop/  에서 하시면 됩니다. 저는 스위치봇에 스위치봇을 구글 홈에 연결시키기 위해 스위치봇 허브 미니까지 구매했습니다. 스위치봇 허브 미니가 없으면 스위치봇을 외부에서 제어하거나 구글 홈에 연결할 수 없습니다. 그리고 제가 스위치봇 허브 미니를 구매한 이유 중 다른 하나는 이 제품이 RF 리모컨 기능이 지원됩니다. 집에 있는 모니터를 제어할 필요가 있어서 이참 저참으로 같이 구매했습니다. 제품 등록은 어렵지 않습니다. 여기서는 스위치봇 허브 미니에 RF 리모컨을 등록해서 구글 어시스턴트로 제어하는 방법을 소개해드릴까 합니다. 제가 스위치봇 허브 미니로 모니터를 제어하고 싶었던 부분은 컴퓨터에서 크롬캐스트로 외부 입력을 때에 따라 바꿔야 하는데.. 그때마다 리모컨을 찾는게 너무 불편해서였습니다.  어차피 리모컨은 외부 입력 바꿀 때 빼고는 쓸 일도 없는지라.. 매번 어디로 사라지면 정말 불편해서 이걸 자동화 하고 싶었습니다. 그런데, 처음에 스위치봇 허브 미니를 등록하고 여기에 리모컨을 등록하니.. 구글 홈에 등록된 리모컨이 자동으로 등록이 됩니다. 그런데, 등록된걸 확인해보니 전원 On/Off만 제어되는 것이고, 나머지 버튼은 구글 홈...

20년 차 테스터가 고른 최근 IT 소식: 기술의 속도, 그리고 사람의 자리

20년 넘게 IT 업계에서 테스팅하고 강의하고 공부하고 여러 일을 해왔지만... 정말이지 단 하루도 편하게 쉴 틈을 주지 않는 세상입니다. 특히 최근 4~5년 동안 가속화된 AI의 물결은 기술의 스펙트럼뿐만 아니라 우리가 일하고, 협업하고, 조직을 이끄는 방식 전체를 뒤흔들고 있습니다. 이번 주에도 수많은 뉴스레터와 아티클을 훑어보았습니다. 그중에서도 기술의 화려함 뒤에 숨겨진 ‘사람, 조직, 그리고 커리어의 본질’을 찌르는 글 몇 개가 눈에 띄어 메모해 둡니다. 제 평소 생각과 맞닿아 있는 6가지 이야기입니다. --- 1. 인지부채(Cognitive Debt): 바이브 코딩 시대에 우리가 지게 되는 진짜 빚 (출처: ROBOCO - 인지부채: 바이브 코딩 시대의 새로운 부채 관리법 / 정도현 수석 컨설턴트 ) 요즘 커서(Cursor)나 클로드 코드(Claude Code) 같은 에이전트를 붙여 "이거 만들어줘" 하고 승인(Approve) 버튼만 누르면 눈 깜짝할 사이에 코드베이스가 완성되는 '바이브 코딩(Vibe Coding)'이 유행입니다. 그런데 속도는 엄청나게 빠른데, 정작 서비스에 장애가 나면 "AI가 짜서 잘 모르겠는데요?"라는 답이 나오는 이상한 현상이 벌어집니다. 정도현 컨설턴트는 이를 '인지부채(Cognitive Debt)'라고 정의합니다. 코드는 쌓이는데, 정작 인간의 시스템 이해도는 쌓이지 않는 격차죠. * Human-in-the-loop의 환상: AI가 초당 수백 줄을 뽑아내는데 사람이 일일이 검토한다? 결국 검토자는 병목이 되고, 시간 압박에 쫓겨 영혼 없이 승인 버튼만 누르게 됩니다. 40년 전 자동화 연구(Bainbridge, 1983)가 지적했듯, 자동화될수록 사람은 감시만 하다가 정작 개입해야 할 결정적 순간에 숙련도를 잃어버립니다. * 부채는 0으로 만드는 게 아니라 '관리'하는 것: AI가 만든 모든 코드를 사람이 외울 수는 없습니다. 핵심은 ...

우리는 AI로 '더 빠른 말'을 키우고 있는걸까요? 아니면 '자동차'를 만들고 있는걸까요?

20년 넘게 IT 현장에서 뒹굴거렸는데... 요즘처럼 "우리가 지금까지 당연하게 여겨온 일하는 방식의 본질"에 대해 근본적인 질문을 던지게 만드는 때가 없었던 것 같습니다. 최근 읽은 UX 관련 글 하나가 가슴을 쿵 치고 지나갔습니다. UX 및 디지털 트렌드를 다루는 블로그 ux4dotcom에 올라온 "Beyond Faster Horses — Why AI Challenges One of UX's Oldest Assumptions"라는 글입니다. (출처: ux4dotcom - Beyond Faster Horses — Why AI Challenges One of UX's Oldest Assumptions ) 혁신을 말할 때 늘 인용되는 헨리 포드의 유명한 말이 있습니다. "사람들에게 무엇을 원하느냐고 물었다면, 그들은 '더 빠른 말'이라고 답했을 것이다." 사람들은 자신이 경험해 본 범위 안에서만 미래를 상상합니다. 말만 탈 줄 아는 사람에게 자동차는 상상 밖의 범주(Mental Model)니까요. 저자는 그동안 UX(사용자 경험)라는 학문과 필드 자체가 '더 빠른 말을 만드는 일(기존 과업의 효율화)'에 집중해 왔다고 지적합니다. 사용자의 행동을 관찰하고, 마찰(Friction)을 줄이고, 화면을 간소화하고, 기존 워크플로우를 최적화해 주는 작업 말입니다. 실제로 주변을 봐도 우리가 AI를 쓰는 방식도 대부분 이 범주를 벗어나지 못하고 있습니다. 더 빠르게 이메일을 작성하고, 문서 요약을 3초 만에 끝내고, 프레젠테이션 장표나 일정표를 순식간에 만들어내는 일. 분명 유용하고 저 역시 매일 요기하게 쓰고 있지만, 이건 어디까지나 '기존에 인간이 하던 일의 프로세스를 흉내 내어 속도만 올린 것(Faster Horse)'에 불과합니다. 정작 "이 워크플로우 자체가 과연 계속 존재해야 하는가?"라는 근본적인 질문은 던지지 못하고 있는 것이죠....