차세대, 리팩토링 그리고 애자일
코로나19로 달라진 삶을 이야기하는데, 우리회사(베터코드 주식회사)의 상황과 내 삶 역시 많이 달라졌다. 나이탓인지 우리가 공동체의 생활을 한다는 사실을 점차 체감한다. 내 삶에 급격한 변화가 일어나는 3개월 남짓의 기간동안 겪은 일중에 공동체에 내놓아 함께 논의할 만한 내용이 있어 글을 쓴다.
서울에서의 영업 시작
코로나19로 인해 그간 북경에 상주하며 중국에서 SaaS 시장 진입을 노리던 일을 일단 중단하기로 했다. 일보 후퇴 후에 전진해야 하는 상황이 되었다. 일단, 가만히 있지 못하는 성미가 작용했다. 아직 중국 철수를 결정하기 전에 북경 복귀를 기다리던 중에 사회적 거리두기 때문에 조심스럽게 몇몇 기업에서 비슷한 고민을 하는 분들을 만났다. 대개는 서울을 떠나기 전인 5년 전 즈음까지 인연을 맺었던 분들이다. 그들과 나눈 주제는 다양했지만, 함께 나누는 이야기의 키워드는 '클라우드', 주로 리테일 부문의 'Digital Tranformation' 그리고 '리팩토링'이었다.
차세대란 표현을 싫어하시지만...
그 중에 아주 선명하게 나를 규정짓는 표현을 잊을 수 없다. 어떤 대기업의 IT 기획을 맡은 분과 대화를 하는데 나에게 이렇게 말을 꺼냈다.
차세대란 표현을 싫어하시지만...
자연스럽게 웃음이 났다. 그는 과거에 함께 일한 적인 없는 분이기에 내가 popit에 썼던 글을 읽어보셨구나 싶었다. popit에 내 글을 읽는 분들이 내가 차세대를 부정적으로 본다는 인상만 남을 수 있다는 것을 깨닫는 순간이기도 했다. 물론, 나는 차세대 프로젝트라는 방식에 대해서는 부정적이다. 조금 더 정확하게 말하자면, 비단 차세대 프로젝트만이 아니라 솔루션 도입으로 뭔가 해결하려는 태도 자체에 나는 회의적1)이다.
이 사건과 별개로 어제 우리회사 CTO님이 쓴 자료에서 이런 내용을 발견했다. 이 자료를 볼 때 받은 자극이 내가 이 글을 쓰는 직접적인 동기이기도 하다.
시스템도 continuous, agile한 변화에 적응을 할 수 있어야 한다.
내가 쓴 글이 아니었지만, 내 생각과 정확히 같다. 그리고, 내가 차세대에 부정적인 이유를 바로 저 문장으로 설명할 수 있다. 언젠가 내가 popit에 차세대 프로젝트 안할 수 있게 차세대 프로젝트 하기라고 쓴 일이 있다. 그 글에 인용한 그림은 DevOps 커뮤니티에서 차용한 것으로 과거에 필자가 수십억짜리 프로젝트의 당위성을 설명하기 위해 모기업 최고경영자 앞에서 직접 발표할 때 활용한 그림이다.
DevOps를 설명하는 이미지
당시 회사의 오너였던 그 분은 정확히 필자가 전하려던 말을 이해하셨다.
IT가 비즈니스랑 따로 노는 것이 아니라 지속적으로 대화를 해야 할 필요가 있다는 말인가요?
차세대를 논할 때 상황은 장기간 개선 노력을 하지 않아 시스템이 경직된 탓에 비즈니스에서 요구하는 변화를 즉시 받아주지 못하는 일 자체가 문제인데, 그것은 단번의 시스템 도입으로 해결할 수 없다. 솔루션 도입으로 문제를 단번에 해결한다는 착각은 우리나라 전산실이 외산 컴퓨터 도입으로 만들어졌고, 지속적으로 외산 솔루션 도입으로 문제를 해결해온 역사의 연장선이다. 낙후된 방법을 빨리 바꿔야 한다.
리팩토링 전문가
비슷한 시기에 다른 두 기업에서 나를 리팩토링 전문가라고 찾으셨다. 그들이 말하는 리팩토링은 마틴파울러의 리팩토링이 아니었다. 차세대의 반대되는 개념으로 시스템을 지속적으로 재구축하는 과정을 '리팩토링'이라고 칭했다. 출처가 어딘가 싶기는 했지만 말은 통했다. 놀라운 사실은 그분들이 나를 리팩토링 전문가라 하는 것이다. 중국에 있는 4년 동안은 popit에 글 쓴 것외에는 업계에서는 공백기라 할 수 있는데 어떤 연유인지 그랬다.
그래도 나는 그분들이 마이크로 서비스 도입이 목표가 아니고 리팩토링이 목표라고 설정한 점은 높이 평가했다. 마이크로 서비스는 어쨌든 솔루션 도입과 같은 식의 사고이고, 리팩토링은 문제를 풀어가는 과정에 가깝기 때문이다. 그리고 리팩토링이라는 말 안에 지속성을 내포하고 있다는 점에서 구조적 문제를 향했다는 점이 고무적이다.
이쯤에서 나는 최근 읽었던 김성한님의 프로덕트 오너 책에서 프로덕트 오너(PO)를 미니 CEO2)라고 지칭한 내용을 떠올린다. 한편 OKR 책에서 구글 사례를 보면 같은 역할을 프로덕트 매니져(PM)이라 쓰고 있다. PO와 PM이라는 표현은 IT를 별도 직군으로 두는 전통기업과는 다른 맥락에서 개발된 역할이다. 그럼에도 불구하고 이들 역할과 전통기업 경영자나 중간 관리자를 대비해보면 가장 큰 차이점은 바로 고객 지향성에 있다고 생각한다.
나는 리팩토링에 도전하는 분들에게 시스템과 비즈니스를 나누지 말고 묶은 후에 고객 가치로 구분되거나 고객 가치를 빠르게 전달하기 위한 덩어리로 나누라고 말씀드리고 싶다. 매우 모호한 접근이지만 그렇게 하면 그전에는 드러나지 않던 프로덕트(혹은 고객 가치라고 불러도 좋겠다)가 보일 수 있기 때문이다.
continuous, agile한 변화
앞서 말했지만 내가 이 글을 쓰는 직접 동기는 앞서 소개한 CTO님의 글이다.
시스템도 continuous, agile한 변화에 적응을 할 수 있어야 한다.
두 영어 단어가 함께 배치된 것이 매우 묘하다. 마치 미분과 적분 관계3)같기도 하다. 변화는 끊임없이 계속된다. 경영분야에서는 기존 기업이 수용하기 어려운 변화를 파괴적 변화라 묘사하기도 한다. 여기서 견뎌내려면 민첩해야 한다. 애자일은 소프트웨어 개발 방법이나 접근법으로 많이 쓰였지만, 기업 구성원이나 기업 자체의 민첩함을 지칭할 수도 있다. 지속적인 변화에 대처하려면 기업이 민첩하게 대응하고 변화한 환경에 적응해야 한다. 현대 기업 존속의 필수조건이다.
이렇게 끝맺으려니 무미건조한 인상이 들어서 예전 기억을 하나 더 꺼내본다. 꽤 오래전 대기업에서 애자일 기반으로 프로젝트를 할 때, 그 회사 중간 관리자 한 분이 나에게 매우 도전적인 어조로 이렇게 말했다.
POProduct Owner라고 하는 것이 종전에 내가 PLPart Leader로 하던 일과 다른 점이 없던데요?
그때 나는 명쾌하게 답을 하지 못했다. 지금은 답할 수 있을까? 도전에 보자. 핵심 키워드는 바로 주인의식Ownership이다. 문장으로 표현하기 전에 대기업 출신의 한 동료가 과거에 했던 말을 먼저 인용한다.
주인의식은 개소리다. 주인이 아닌데 어떻게 주인의식을 갖느냐?
나는 그 대답을 듣고 크게 웃었던 기억이 있다. 동료의 말은 대기업에서 주인의식을 강조하는 사람은 정직하지 못하다는 주장이다. 내 경험을 보면 대기업에 다니면서 주인의식을 갖는 분들이 없지는 않다. 다만, 그들이 주인으로 대접받는 경우는 아직 보지 못했다. 결론적으로 계층적 조직구조와 주인의식은 맞지 않는다.
하지만, 주인이냐 아니냐 하는 점보다 내가 관심을 갖는 부분은 일을 책임있게 하도록 위임을 해야 한다는 주장이다. 여기에서 다시 PO가 미니CEO 라고 묘사한 부분을 떠올리며 그 옛날 답하지 못한 질문에 대해 답을 할 수 있다.
PL에게는 회사에서 문제를 해결할 전권을 주지는 않잖아요? 하지만 PO는 그 프로덕트에 대해 전권을 위임받아 일합니다. (혹은 일할 수 있어야 합니다.)4)
결론
필자의 마지막 대답이 continuous, agile한 변화와 어떠한 연관 관계를 가질까? 나는 비즈니스와 IT문제를 떼어서 보는 것 자체에서 이미 변화에 대한 대응에 뒤쳐지는 구조적 문제라고 생각한다. 그러한 구조적 문제를 해결해나가야 한다. 그러기 위해서 고객 관점으로 비즈니스와 시스템을 묶어서 보는 프로덕트라는 개념을 수용하자고 주장한다. 물론, 판교에 있는 회사가 아니고 전통기업이라면 쉽지는 않다. 하지만, 기업이 살아남으려면 반드시 해야 한다.
그리고, 해당 프로덕트 책임자에게 전권을 위임하는 구조로 큰 조직을 분할해 나가야 한다. 사실, 전통 기업이 마이크로 서비스를 도입하는 이유로 합당한 목표는 이것 하나뿐이라 할 수 도 있다. 이 주장으로 나는 리팩토링과 다른 글의 연관성도 설명할 수 있다. 리팩토링의 목표는 결국 시스템뿐만 아니라 조직을 바꾸는 것으로 결론이 나야 성공할 수 있다.
마지막으로 결론에 내가 내린 답이 예전에 썼던 차세대 프로젝트 안할 수 있게 차세대 프로젝트 하기란 표현의 또다른 풀이이기도 한다. 수백억이나 수천억을 들인다면 목표는 다음 세대에도 생존하는 기업으로 바뀌어야 한다.
주석
[1] 글을 쓰는 순간 그런 생각이 왜 나는가 싶기도 한데, 어릴 때 공부를 잘하려고 공부법을 여러차례 바꿔봤지만 소용이 없던 기억이 난다. ㅠㅠ
[2] 미니 CEO란 표현의 기원이 어딘지 모르지만, 나는 김성한님의 책에서 그 표현을 처음 보았다.
[3] 필자는 수포자임을 밝힙니다.
[4] 설명이 너무 짧다고 여기는 분들이 있을까봐 아래에 조금 더 이야기를 풀어둡니다.
PO와 PL 대비에 대한 번외 이야기
PO는 "주인이니까" 자발적으로 문제를 정의한다. 제품 혹은 서비스가 어때야 하는지. 문제를 정의한다는 것이 꼭 컨설턴트처럼 한다거나 문서로 모두가 알 수 있게 규정하는 것은 아니다. 그건 대충 이런 예시로 나타난다.
- 열정어린 목소리로 의견을 말하고 내 얼굴을 보면서 간절한 표정으로 피드백을 기다린다
- 무뚝뚝한 개발자가 눈도 안마주치고 노트북만 보면 듣는데, 옆에 앉아서 설득을 시도한다
- 도통 모르는 말이 많다고 외부 스터디에 가서 열정적으로 묻고 기록한다
- 습관처럼 제품에 대해 기록하고, 말하고, 논쟁한다
반면 PL은 누군가 동기부여를 시켜줘야 하는 경우가 대부분이다. 빌어먹을 동기부여 말이다. :)
그들은 대체로 숙제를 푸는 사람이다. 문제를 내면 답을 맞추는 교육에 익숙해진 엘리트들이 많다. 그러니 이런 식으로 일하는 것은 당연하다. 입사 전까지 최소 12년 정도를 그러한 훈련을 받은 사람들이 PL로 성과를 잘 내는 경우가 많다.
답할 수 있다. PL은 보통 PMProject Manager라는 관리자의 부담중 일부를 위임한다. P는 Part의 약자이다. 결국 사전에 Part 즉 어떤 기능이나 해당 부분을 나눌 수 있어야 성립한다. 즉, 영역 분리가 전제되어 있고, 필연적으로 사전 계획과 맞닿아 있다.
무슨 말이냐면, 해당 파트가 일이 아주 적으면 PL을 둘리가 없지 않은가? 결국 아는 문제 중에 일부를 할당한다. 디테일은 PL이 책임질 수 있을지 몰라도 경계가 무너질 일은 흔하게 발생하지 않는다. 그래서, PL은 파트를 책임지는 것이지 PM처럼 프로젝트 전체를 자기 책임으로 갖을 필요는 없다.
그에 반해 PO는 말 그대로 제품의 주인이어야 한다. 프로젝트라는 형태를 띄건 말건 PO는 제품에 대한 총체적 결정권자가 되지 못하면 역할이나 용어를 잘못 쓰는 것이다. 물론 PO라는 정의가 절대적인 행동 양식이 있는 것은 아니다. 또다른 PM인 프로덕트 매니저Product Manager를 개입시키면 경계가 모호한 측면도 있다. 하지만, 여기서 내가 PO와 PL 구분이라는 오래된 마음속 질문을 꺼낸 이유는 바로 오너십을 갖고 있고, 결정권을 받은 관리자인가 아닌가를 문제로 설정하기 위함이다.