기본 콘텐츠로 건너뛰기

K 사 제약이론 컨설팅 후기

지난 한달동안 정말 오랜만에 제약이론의 처음부터 끝까지 컨설팅을 한 뜻깊고 힘든 시간을 가졌습니다.

보안 어쩌구 때문에 자세한 자료를 여기서 공유할 수는 없고, 제약이론을 오랜만에 현장에 적용해서 개선 목표를 도출하는 과정에서 느꼈던 점과 어려웠던 점을 기록으로 남겨볼까 합니다.

사실, 이번 컨설팅은 개선 방안을 도출하는 과제였고, 추후에 정말 수행에 대한 컨설팅이 진행되어서 개선의 효과까지 검증 될 수 있다면 좋을 것 같습니다.

우선 저희 회사는 공식적으로 제약이론 컨설팅을 수행하지 않습니다. 모두들 제약이론을 그다지 신뢰하고 있지 않고 좋게 생각하지도 않습니다.

다른 분들이 워낙 바쁘신 관계로 저 하나 달랑 이 사이트에 방치하신 기념으로 제 독단적 판단에 따라 제약이론 컨설팅을 진행하게 되었습니다. 덕분에 참 힘든 시간을 보냈습니다.

제가 이 사이트에 제약이론을 적용하기로 마음을 먹게 된 이유는 이 사이트가 지난 5년간 무던한 개선 노력에도 개선이 이루어지지 않고 있고, 조직원들이 그런 사실에 피로감과 무력감을 나타내고 있었기 때문입니다. 이런 사이트에는 제 개인적으로 제약이론이 최고의 처방이라고 생각하고 있습니다.

아래는 그런 전차로 제약이론 컨설팅을 하면서 느꼈던 점과 어려웠던 점입니다.

1. 고객의 경력이 너무 높아도 문제입니다. 이론적인 설명을 듣지 않으려고 하시더군요. 덕분에 실제 수행 과정에서 왜 이런 일을 하는지 이해가 부족하다보니 충돌이 좀 많았습니다. 결국에는 수행 과정에서 공감을 어느정도는 하지만 이해가 부족하다보니 확신이 부족해지는 결과가 되었습니다. 제약이론은 수행하는 사람의 확신이 가장 큰 원동력인데 좀 난감합니다.

2. UDE라는 문제점으로부터 CRT를 작성하는데 있어서 그 상세함을 어느정도까지 가져가야할지 정말 힘들었습니다. 시간은 짧고 상세하게 만들기는 힘들어서 조금 압축된 형태로 만들다보니 나중에 검토 과정에서 상세한 내용이 빠져서 인과관계를 잘못 추론하게 되거나 정말 심각한 문제인데 누락되어버리는 문제가 발생했습니다. 가능하다면 CRT는 상세하게 작성하는게 좋은 것 같습니다. 그리고 CRT의 작성에 좀 더 많은 시간을 투자하는게 더 좋겠다라는 생각이 들었습니다.

3. DE와 Injection을 구분하기가 힘들었습니다. FRT를 작성하는 과정에서 DE자체가 Injection 성격을 가지거나 DE 각각이 하나의 중간 목표 성격을 가지면서 Injection 간의 연계가 없이 너무 많은 Injection이 발생하는 문제가 생겼습니다. 수없이 도출된 Injection은 선행관계를 분석하면서 조금 정리가 되긴 했습니다.

4. 이 글을 읽으시는 분들도 제약이론을 모르시는 분들은 제가 쓰는 용어가 도데체 무슨 용어인지 전혀 모르실겁니다. 여기도 마찬가지로 교육 없이 진행하다보니 제약이론에서 사용되는 용어를 이곳에서 이해할 수 있는 용어로 변경해야하는데, 변경 자체도 어렵지만 변경을 시킨 후에 뜻이 변경되어 잘못 이해되는 경우가 있어서 정말 애를 먹고 있습니다.

예를 들면, 서술형 TO(전술적 목표)들을 이곳에서는 개선 방안으로 바꿔버리면서 개선 과제를 만든다고 각 TO들의 서술 관계를 무시하고 비슷한 성격의 TO를 묶어버리면서 선행관계가 어그러져서 오히려 알아보기 힘들어졌는데, 이곳에서는 그런건 별로 신경을 안쓰시더군요. 뭐, 이것도 제약이론을 정확히 이해하지 못해서 빚어진 일이긴 합니다.

5. 도출된 개선방안들이 이곳에서도 익히 알고 있는 사항들이다보니 뭐라고 해야할까요? 한방이 없는것이 이곳 사람들의 확신을 얻지 못하게 되는 결과가 되었습니다. 원래 제약이론은 마피아 오퍼라고는 하지만, 뭔가 획기적이고 신선한 개선책을 내놓기보다는 기존에 알고 있는 내용들을 토대로 제 3의 방안을 찾는 것인데, 이곳에서는 그런것보다는 뭔가 획기적이면서 참신한 제 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)'에 불과합니다. 정작 "이 워크플로우 자체가 과연 계속 존재해야 하는가?"라는 근본적인 질문은 던지지 못하고 있는 것이죠....