뜻밖의 상황에 등장한 '제어 역전'이 주는 지적 자극
묻고 따져서 개념을 만들고 실행하는 디지털 전환
회사 동료와 화상 미팅을 하는데 뜻밖의 단어를 낯선 상황에 쓰고 있는 점이 인상 깊었습니다. 제 생각이 당시 대화 주제와 거리가 멀어 속으로 생각할 뿐 말을 하지는 않았는데요. 그 생각을 꺼내어 쓰는 글입니다.
낯선 상황에서 듣게 된 익숙한 용어 '제어 역전'
동료가 불안에 갇혀 있는 또 다른 동료에게 탈출구를 제안한 일이 대화의 주제였습니다. 날짜가 정해져 있는 비즈니스 행사를 앞두고 주어진 시간에 할 일이 너무 많아 어쩔 줄 몰라하는 상황으로 이해했습니다. 이에 대해 저와 대화한 동료는 불안의 초점이 되는 일을 대화를 통해 밝혀 냈습니다. 동료의 이타적 행동이 효과를 발휘한 것이죠. 그러고 나서 2, 3일 안에 그걸 해결할 수 있는 최소한의 기능을 만들어 본 다음에 나머지 일을 챙기면 어떻겠냐는 제안으로 2시간 상대와 화상 통화를 한 이야기를 들려준 것이죠. 훌륭한 리드란 생각이 들었고, 병목 업무를 다루는 비법을 담은 책 <The Goal>의 응용처럼 느껴졌습니다.
한편, 동료는 대화 상대였던 다른 동료의 불안을 두고 그 근본적 원인을 상대가 일을 받아들이는 태도에서 찾았습니다. 그리고 둘의 협력 과정에서 상대에게 그 방법을 알려 주고 싶어 하는 이타적 욕망이 느껴졌습니다. 그는 자신이 알려 주고 싶은 노하우를 '제어의 역전'이라고 말했습니다. 제어의 역전 혹은 IoC(Inversion of Control)의 통상적 의미와는 많이 다른 쓰임이었지만, 다행히 둘 사이에서는 통용되는 말이었던 것입니다.
일단 둘이서만 이해할 수 있는 의미를 벗어나기 위해 위키피디아의 IoC 페이지를 찾아 크롬 번역한 내용을 인용합니다.
소프트웨어 엔지니어링에서 제어 역전(IoC)은 컴퓨터 프로그램의 사용자 지정 부분이 외부 소스(예: 프레임워크)로부터 제어 흐름을 받는 설계 원칙입니다. "역전"이라는 용어는 역사적으로 중요한 의미를 지닙니다. <중략> 제어 역전은 GUI 환경의 등장 이후 애플리케이션 개발 프레임워크에서 널리 사용되어 왔으며
GUI의 등장이 가져온 상호작용 증가와 스프링의 IoC
인용문의 마지막 문장을 보니 저도 모르던 내용입니다. 저는 2004년 대규모 차세대 프로젝트에 스프링을 첫 도입한 용기와 열망으로 로드 존슨(스프링 개발자)이 쓴 책과 소스 코드 그리고 코드 수정 기록(subversion revison)을 접했습니다. 그중 특히 소스코드와 꼼꼼한 주석과 함께 쌓인 수정 이력은 저에게 일종의 바이블이었습니다. 그리하여 존경하는 마음으로 무모한 도전을 할 수 있게 해 주었죠.
2009년 컨퍼런스에서 만나 함께 찍은 사진[1]아무튼 그렇게 배운 Inversion of Control은 일반적으로는 개발자 자신이 짠 코드에서 제어 흐름을 관장하는 일을 ‘역전시켜’ 프레임워크에 맡기는 설계 패턴입니다. 스프링 프레임워크는 그렇게 개발자가 맡긴 제어를 일종의 프로세스와 검증된 코드의 템플릿을 통해 안전하게 해소해 주는 강력한 라이브러리 역할을 스무 해 넘게 다수의 응용 프로그램 속에서 수행하고 있습니다.
하지만, 위키피디아 뜻을 보니 IoC 개념 자체는 GUI 때 등장한 것이네요. 스프링의 IoC 컨테이너(혹은 프레임워크) 역할과 GUI가 가져온 IoC 사이의 공통점을 찾아보면 '인터페이스 기반 프로그래밍'이 특징으로 보입니다.
핵심은 상호작용이죠. GUI의 경우 사용자와의 상호작용입니다. 옛날에는 천공 카드 같은 형태로 뭔가를 입력하고 한참 기다리는 식이었다면, GUI는 즉각적으로 사용자 명령에 반응합니다. 상호작용 빈도가 급격히 올라가는 것이죠. 이때 버튼을 누르거나 클릭을 하면 사용자의 이벤트에 의해 프로그램이 선택되고 실행되는 방식도 IoC 개념으로 이해할 수 있네요. 스프링이 급부상하는 시대적 배경도 하이퍼링크로 연결된 HTML 문서에서 상호작용이 폭발하는 이른바 ‘web 2.0’으로 가는 도중이었음을 떠올리면 또 다른 영감을 받기도 합니다.
프레임워크의 진정한 힘은 무엇인가?
하지만, 스프링의 IoC의 '인터페이스 기반 프로그래밍'은 UI에 대한 기법이 아니었습니다. 기술적 선택이 다양할 때 공통의 인터페이스와 템플릿을 재사용할 수 있게 IoC 컨테이너를 만든 것이 핵심 가치였죠. 이를 위해 자바에서 정의된 객체 지향 프레임워크의 산물인 인터페이스(Inteface) 타입을 적극적으로 쓰는 것으로 GoF에서 제안한 디자인 패턴의 활용으로 볼 수도 있습니다.
하지만, 그것과 동료가 말한 제어의 역전은 완벽하게 무관한 이야기였습니다. 동료는 다른 회사 직원과 함께 일하는 중이었는데요. 그 직원은 회사에서 마이크로 매지니먼트 받는 중이었기 때문에 주어진 과제와 자신의 아이디어를 어떻게 연결할지 방법을 몰라 불안해하는 중이었습니다. 동료가 해법을 주면서 진단하기를 제어의 역전을 스스로 하도록 도와야 본질적인 해결책이 생긴다 믿었습니다.
짐작하기에 동료는 스스로 자신의 일과를 통제할 수 있는 기준을 외부에 주어지는 요구와 구분할 수 있어야 한다고 믿는 듯합니다. 그리고, 우리 회사에서 제가 활용하는 업무 통제와 정렬의 틀에 그가 몸에 배어 있어서 그렇게 말했을 수도 있고요. 우리 회사는 목표와 완료 기준은 명확하게 명문화하고, 실무적 수행은 실행자가 주도권을 갖도록 위임하는 방식을 창업할 때부터 견지해 왔습니다. 그 협업 방식에도 어쩌면 IoC와 닮은 면이 있는 듯합니다.
프레임워크를 통해 Data-driven 조직을 구축하기
그와 동시에 프레임워크의 진정한 힘을 새롭게 깨닫는 느낌을 받았습니다. 생각이 여기에 미치자 마치 기다렸다는 듯이 떠오르는 두 가지 사건이 있었습니다. 하나는 우연히 링크드인에서 발견한 그림입니다. 그림을 임의로 해석해 보면, 1촌 님은 Slack을 통해 내외부 메시지 통합을 하는 방식을 취했던 맥락을 v1으로 지칭합니다.
그런데 이를 개편하여 v2를 만들 때는 Slack이 아닌 AI로 통합을 한다고 표현합니다. RAG 같은 방법을 활용하면 할 수 있는 일처럼 보였습니다. 그렇게 추정하고 1촌의 글을 더 살펴보다가 SOT(Source of Truth)라는 내용을 봤습니다. 직관적으로는 짐작과 부합했지만 엉뚱한 추정을 피하기 위해 퍼플렉시티에게 질문을 했습니다.
와~ 소통이 어려운 지식 노동 환경에서의 협업의 길을 놓는데, 마치 과거 SAP가 ERP의 뼈대가 된 것처럼 LLM이 그 역할을 할 수 있다는 '유레카'가 떠오릅니다. 짧게 설명할 수 없어서 이에 대해서는 다시 생각을 정리해서 써 보기로 합니다.
두 번째는 프레임워크를 코드 수준이 아니라 프로세스 혁신 도구로 인식할 수 있었습니다. 정작 프레임워크 개발 실무할 때는 모르던 재해석입니다. 코드 수준의 정교한 프로세스 구축은 인공지능이 대세인 시대에 다시 한번 재해석할 수 있다는 생각이 들었습니다. 거기에 더하야 지난여름 전자정부 프레임워크 사업 자문에 참석했던 일이 떠올랐습니다. 당시는 뾰족하게 할 말이 많지 않았는데 쓸만한 말이 이제야 떠올랐습니다. 이 역시 이제 막 떠오른 일종의 유레카라 새로운 글로 생각을 정리해 보기로 하겠습니다.
주석
[1] 2006년에도 컨퍼런스에서 로드 존슨을 봤지만, 영어 컴플렉스로 다가가 말을 걸지 못했습니다. 그에 대한 후회에 3년 후에 그에게 대시해서 사진을 찍게 했죠.
