객체 지향 프로그래밍(OOP)이란?
OOP는 전세계에서 가장 널리 쓰이는(하지만 가장 사랑받지는 못하는) 개발 패러다임입니다. 컴퓨터에게 문제 해결을 시키는 더 효과적이고 효율적인 방법을 고민하는 과정에서 만들어졌지요. 그렇다 보니, OOP는 비단 개발할 때 뿐 아니라 일터에서 만나는 다양한 문제 상황에서도 유용하게 차용될 수 있습니다.
오늘은 OOP의 핵심 요소들을 ‘문제 해결 요령’이라는 별명으로 풀어 설명해보겠습니다. 이런 요소들이 팀 리더로 성장하는 분들께 특히 도움이 많이 될 것 같습니다.
OOP의 4대 요소는 Encapsulation, Abstraction, Inheritance, Polymorphism입니다. 이런 어려운 표현도 모르셔도 괜찮습니다. 아래에서 자세히 설명드릴게요 :)
Encapsulation = 믿고 위임하기
Encapsulation은 ‘믿고 위임하기’입니다. 일련의 과정을 묶어서, 다른 사람에게 위임한 후, 디테일에 대해서는 관여하지 않는 것입니다. 사실 현대를 살아가는 모든 사람이 경험하고 있는 일반적인 현상이죠. 우리가 우유를 마시고 싶을 때 “직접” 젖소를 키우고 젖을 짜지 않는 것은, 우유를 생산하는 과정이 Encapsulate 되어 있기 때문입니다. 우유 회사가 그 작업을 맡고 있죠.
회사에서 Encapsulation은 어떻게 일어날까요? 여러분이 하는 일을 잘게 쪼갠 다음에, 정말 쉬운 것부터 순차적으로 다른 사람에게 위임하면 됩니다. 위임을 하고 나면, 위임한 사람은 한 차원 높은 일을 진행할 수 있게 됩니다. 한 단계 높은 차원에서 일을 바라볼 수가 있게 되지요.
디어를 처음 시작했을 때는 창업 멤버들이 대부분의 실무를 직접 했습니다. 화면 기획, 사업자 등록, 사무실 계약, 슬랙 채널 개설, 도메인 구입, 킥보드 조립, 킥보드 수리, 배터리 교체, CS 등등… 고객들께서 카카오톡 채널로 메시지를 보내면 제가 직접 답장을 하던 기억이 새록새록하네요 :)
회사가 성장하려면 리더는 지금 자기가 하고 있는 일을 최대한 빨리, 잘 위임해야 합니다. 자잘한 일들을 묶어서 위임하고 나면 그것보다 조금 더 중요하고 큰 일을 할 수 있게 되고, 그 일을 묶고 나면 더 중요하고 큰 일을 할 수 있게 됩니다. 아래는 사업 초기 제가 했던 일들을 myTasks라는 이름으로 보여주는 코드입니다. 모든 일을 직접 하는 모습입니다.
예를 들어 사업자 등록은 관할 부처 방문부터 문서 스캔 및 저장까지 이어지는 세부적인 업무로 구성되는데, 이 일을 모두 제가 직접 처리했던 것이죠. 아래는 Encapsulate 되지 않은 업무 방식입니다.
// Not Encapsulated
const myTasks = () => {
// 사업자 등록
visitRegistrationOffice();
submitDocuments();
locateOffice();
checkRegistrationCode();
scanAndSaveTheDocument();
// 사무실 계약
callRealtyOffice();
tourLocations();
takePicturesAndNotes();
pickTheBestOne();
}아래 코드는 제가 했던 각각의 업무를 누군가에게 위임한 후, 한층 간결해진 모습입니다.
const myTasks = () => {
// 사업자 등록
registerBusiness();
// 사무실 계약
getAnOffice();
}위쪽 코드에 있었던 세부 작업들은 일을 위임 받은 각각의 함수가 알아서 잘 처리해주고 있습니다.
// 사업자 등록
const registerBusiness() => {
visitRegistrationOffice();
submitDocuments();
locateOffice();
checkRegistrationCode();
scanAndSaveTheDocument();
}
// 사무실 계약
const getAnOffice() => {
callRealtyOffice();
tourLocations();
takePicturesAndNotes();
pickTheBestOne();
}따라서 저는(즉 myTasks에서는) 위의 두 개 함수만 불러오면 되는 것이죠.
이런 방식으로 일을 하면, 큰 규모의 일을 더 많이 추진할 수 있게 됩니다. 초반에는 사업자 등록, 사무실 계약, 배터리 교체를 하는 데에 제가 100시간을 써야 했다면, 이제는 누군가 그 일을 대신 해주기 때문에 5시간만 써도 됩니다. 일을 처리하는 데 들어가는 시간이 1/20으로 줄어든 것입니다. 제가 일을 20배 더 잘하는 것은 불가능하지만, 일에 들어가는 시간을 1/20으로 줄이는 것은 이런 식으로 가능합니다.
OOP에 비유하지 않더라도 위임의 중요성은 얼마든지 강조할 수 있습니다. William Thorndike의 현금의 재발견이나, 제가 가장 좋아하는 책 중 하나인 호암자전, 실리콘 밸리의 필독서로 알려진 Andy Grove의 High Output Management 등을 보면 위임의 방법과 효과가 잘 나타나 있습니다.
한편 어떤 일은 사람에게 위임하는 것보다, 컴퓨터에게 위임할 때 훨씬 효과가 강력합니다.
매일 엑셀에서 1,000개의 단어를 찾아 1,000개의 새로운 단어로 바꾸어야 하는 상황을 상상해보세요. 2초에 한 번씩 찾기-바꾸기를 실행한다고 해도 매일 30분이 걸립니다. 영상에 나온 것처럼 VBA를 이용하면 단 1초로 그 시간이 줄어들고요 :)
개발자든 아니든, 직군과 상관 없이 필요한 상황에서 SQL이나 Python, NodeJS, AWS Lambda, Google Apps Script, Airtable API, Tally 등을 이용해서 업무를 자동화할 수 있습니다. 처음이 낯설지, 한 번 해보고 나면 업무가 편해지는 재미에 푹 빠질 거예요!
Abstraction = 개념 짓기
Abstraction은 우리말로 추상화라고 하는데, 이 개념은 오늘날까지도 명료하게 해석되지 않는 경향이 있는 것 같습니다. 특히 Encapsulation과 혼동한 해석이 많습니다. 저는 추상화를 말 그대로 ‘추상적 개념으로 변환하기’라고 해석하는데, 이 말을 좀 더 쉽게 풀어보면 ‘개념 짓기’가 됩니다.
Abstraction = 추상화 = 개념 짓기
일을 하다 보면 각기 다른 부서라고 하더라도 공통적으로, 반복적으로 경험하게 되는 어떤 상황들이 있습니다. 이런 상황에 이름(개념)을 부여하면 여러모로 대응이 편해집니다.
개념을 짓는 것은 두 가지 장점을 띱니다. 첫째는 위에 쓴 것처럼 설명이 간결해진다는 것인데요, 사실은 개념 짓기의 둘째 효과가 훨씬 강력합니다. 개념 짓기의 둘째 효과는 개념들을 떼었다 붙였다 하면서 다양한 조합, 조립이 가능하다는 점입니다.
복잡한 개념이 한 단어로 축약되어 표현되는 모습이 가장 많이 등장하는 곳, 병원을 예로 들어볼게요.
큰 병원에서 어려운 의학 용어가 자주 등장하는 것도, 각각의 용어가 표현하는 신체 현상이 너무나 복잡하기 때문에 의사들끼리 약속을 한 것입니다. ‘몸이 뜨거운 상태에서 땀이 안 나는 현상을 AAA라고 하자’ 이렇게요. 그리고 ‘몸이 뜨거웠다 차가웠다 반복하면 BBB라고 하자’ 이렇게요.
이렇게 통용되는 개념, 즉 추상화된 개념이 지어지고 나면, “1번 환자가 AAA와 BBB 상태를 모두 갖고 있습니다.”라고 표현할 수 있게 됩니다. 그러면 AAA일 때 적절한 처방, BBB일 때 적절한 처방을 빠르게 살펴볼 수 있겠죠. 반면 추상화되지 않은 병원에서는 “1번 환자가 몸이 뜨거웠다 차가웠다 하는데 뜨거울 때도 땀이 안 납니다.”라고 표현해야 합니다. 이렇게 추상화가 덜 된 방식으로 소통을 하면 복잡한 일을 처리할 때 오해나 오류가 생길 여지가 큽니다.
Inheritance, Polymorphism = 상황에 맞는 가이드라인
Inheritance는 2번에서 우리가 추상화한 개념을 복제하는 것인데요, 복제하는 과정에서 상황에 맞게 특징을 덧붙이는 것입니다. 예를 들어 손님이 올 때마다 디어를 소개하는 방식(설명하자면 매우 길고 복잡한)을 ‘디어 소개 양식’이라는 추상적인 개념에 담았다고 해볼게요. 여기까지는 추상화가 잘 된 편이라고 할 수 있습니다. 이조차도 안 되어 있다면 매번 주먹구구식으로 회사를 설명해야 해서 비효율적일 것입니다.
그런데 이 ‘디어 소개 양식’을 활용하는 상황이 매우 다양하다 보니, 상황마다 조금씩 변형할 필요가 있을 것입니다. 신입 사원이 왔을 때, 외부 업체와 제휴를 할 때, 투자자에게 회사를 소개할 때, 채용 설명회를 할 때 등등.
이 때마다 중구난방으로 변형을 하기보단, ’디어 소개 양식_신입 사원 버전', ‘디어 소개 양식_제휴 버전', ‘디어 소개 양식_IR 버전' 같이 여러 가지로 뻗어나가는 방식을 취하면 추상적인 개념의 관리와 활용이 더 편해집니다.
상황에 따라 개념을 다양한 버전으로 복제하는 것을 Inheritance라고 한다면, 개념을 복제하지 않고 하나의 개념으로 유지한 상태에서 상황에 맞게 일을 처리하게 하는 것을 Polymorphism이라고 합니다.
프로그래밍에서는 중요한 차이를 띠지만 현실에서는 Inheritance나 Polymorphism 모두 “상황에 맞는 가이드라인" 또는 “예외 처리", “융통성 있는 변형" 같은 표현으로 대체할 수 있습니다.
(출처: InfoBrother)
마치며
이렇게 OOP의 네 가지 요소가 일터에서는 어떻게 활용될 수 있을지 제 생각을 써보았는데요, 개발을 해보지 않았어도 위임과 개념 짓기의 힘을 아는 리더가 있는가 하면, 객체지향프로그래밍을 오랫동안 해온 사람이라도 막상 삶의 문제를 해결할 때는 그 요소들을 적용하지 못하는 경우가 있습니다.
업무 현장에 기술을 도입할 때, 생산성 향상은 빼놓을 수 없는 주안점입니다. 아이러니하게도 생산성에 대한 고민이 선행된 기업은 기술 도입 없이도 기술 기업만큼 생산성이 높고, 그렇지 않은 기업은 기술을 아무리 많이 도입해도 생산성이 낮습니다.
OOP는 프로그래밍 개념임에도 불구하고, 자사의 생산성을 측정해볼 수 있는 좋은 프레임워크입니다.
독자들 중 인사 담당자 혹은 경영자가 계시다면, OOP에 비추어 자사의 업무 방식이나 조직 구조를 살펴보시기를 추천드립니다.