[개안뽑] ⑰왜 서로 대화 안 해요? 왜 서로 업무 공유 안 해요?

Picture

Member for

4 months

Real name

Keith Lee

Bio

Head of GIAI Korea
Professor of AI/Data Science @ SIAI

Input

2023-12-20 18:30

업무 협업 방식이 상명하복식인 한국 사회에서 협업은 명령 복종
토론식인 서양 사회에서 협업은 대화와 소통, 직급과 경험보다 해당 사건에 대한 지식
전문가가 있는 것이 아니라, 해당 사건의 전문가가 되는 것이 핵심
한국식 프로젝트 구성은 결국 PM의 역량에 전적으로 의지할 수밖에 없는 구조

대기업 공채 시스템이 돌아가는 한국과 일본에만 있는 문화로, 대기업에서 '동기'라는 시스템이 있다. 어떤 부서에 배정되건 상관없이 '동기'들이면 처음 입사할 때부터 합숙 훈련을 같이 받기도 하고, 심지어는 계열사가 달라도 '동기'라면서 한 대기업 집단에 다니면 서로 같은 집단의 소속이라고 묶어서 생각한다.

속칭 '기술직'에 해당하는 경우들은 어떻게 될지 잘 모르겠지만, 적어도 내 주변에 대기업 간 친구들은 이른바 '순환보직'을 돈다. 2년 간 어떤 업무를 하고, 그 업무가 적응된다 싶은 시점이 되면 다른 부서로 보내는 방식이다. 이건 국내 대기업들은 말할 것도 없고, 한국은행, 금감원 같은 금융권 공사를 간 친구들 사정도 크게 다르지 않다. 어느 날은 금융통화위원회 밑에서 매월 둘째주 목요일을 혐오하고, 매일 밤을 새며 i-Banker들과 비슷한 라이프를 살다가, 얼마 지나지 않아서 보면 부산 지사로 발령나서 어린이 유치원들에 '경제 교육'을 해주며 한 2년을 보내고, 또 그러다 서울 지사로 돌아와서는 외환 담당 부서에서 일한다.

외국계 증권사로 첫 직장을 시작했던 나는 저런 시스템이 여전히 어색하다. 전문성이 하나도 안 쌓이잖아? 나는 IBD만 하겠다며 다른 직군은 면접을 보러가지도 않았고, 기적같이 취직하고 나니 다른 외국계 증권사의 IBD팀에 있는 선배들이 술을 사주시며 업무 이야기를 엄청 했던 반면, 같은 회사의 다른 부서에 있는 선배들은 그냥 길 가다가 인사만 하는 사이로 지냈다. 그렇다고 내가 다른 팀이 무슨 일을 하는지 몰랐던 것도 아니다. 내 전문성은 IBD고, 다른 팀이 뭘 하는지 알아서 대화하는데 별 어려움이 없이 일을 할 수 있었다.

업무 협업 시스템의 붕괴는 서비스 수준의 저하를 낳는다

한국 사정이 그러니까, 난 직원들을 뽑아놓으면 자기들끼리 '동기'라는 감정으로, 혹은 최소한 기본적인 의사소통은 하면서 업무 협업을 할 줄 알았다. 근데, 전혀 아니더라.

저 팀이 무슨 일을 하는지 내가 알게 뭐냐는 태도인 사람들 투성이고, 기껏해야 '소문'을 듣는 수준이지, 서로 업무 내용을 공유해서 효율적으로 업무가 진행되는 경우는 극히 드물었다. 이건 일반 기업들 뿐만 아니라 정부 기관들에서도 자주 볼 수 있는 내용으로, OTT 관련해서 문화체육관광부에서 뭔가 정책을 만든다고 하는데, 그 정책 중에 OTT 발전을 위한 콘텐츠 펀드 내용이 있길래 우리나라 정부가 어쩐 일이냐 싶어서 기재부 있는 친구한테 제대로 예산 배정되고 진행되는거 맞냐고 물어봤다. 근데 그 친구는 과기부에서 올라온 거 말하냐, 중기부에서 올라온 거 말하냐고 묻지, 문체부에서 서류 올라온건 모른다고 그랬고, 그렇게 8월에 예산 심의가 한참 진행되고 나더니 11월 말이나 되어서야 예산이 중복 배정 됐다며 재조정해야된다는 부산을 떨더라.

내가 백엔드 개발하고 있으면 분명히 프론트에서 DB구조를 어떻게 쓸지를 전달해줘야 하고, 반대로 프론트가 어떤 식으로 작업하고 있는지 알아야 더 효율적으로 DB구성을 할 수 있는데, 최소한 자주 불러올 것 같은 데이터에 대해 Key값이라도 다르게 배정할 수 있는데, 이런 식의 대화를 제대로 진행하는 걸 거의 본 적이 없다. 개발 팀장이라는 사람에게 이걸 시키면 나가서 시간 때우는 대화나 하고, 즉석에서 둘이 대화해서 문제를 해결하도록 정보 교환, 사고 방식 조정을 못 해주더라.

정부의 중복 예산 배정과 마찬가지로, 개발팀이 이렇게 돌아가면 결국에는 나중에 다 만들어놓고 다시 뜯어고칠 일 투성이가 된다.

이런 문제를 해결해볼려고 뭐 하고 있다는 걸 Slack 같은 채팅창에 열심히 쓰라고 하면, 아무도 안 읽는다. 읽질 않으니 결국 아무도 안 쓸려고 하고, 답답한 마음에 나 혼자서 이건 왜 이렇게 됐냐, 저건 왜 저렇게 따로 놀고 있냐며 목청을 높이게 될 뿐이다.

답답해 하고 있으니까 자기들끼리 대화해서 문제를 풀려는게 아니라 '기획자'를 뽑아야 한단다. 애들이 대표한테는 무서워서 말을 못 한단다.

모두가 기획자인 시스템 vs. PM이 기획자인 시스템

실리콘 밸리의 모든 회사가, 미국 동부의 모든 회사가 이후 서술하는 방식으로 작동하지는 않겠지만, 대체로 서부식, 동부식이라고 불리는 프로젝트 진행 방식이 있다. 서부식은 기획자가 없고, 모두가 기획자다. 자기가 하는 일이 다른 사람에게 영향을 주는 것을 알고 채팅창이 굉장히 활성화되어 있다. 누가 뭘 한다고 그러면 그게 자기 작업에 어떤 영향을 주는지 정리해서 설명해주고, 둘이 같이 나가서 결합 해결책을 찾다가 다른 사람까지 그 문제에 휩싸이는 경우도 있다.

반대로 동부식은 한국 대기업, 에이전시 문화와 유사하게 특정한 프로젝트 '기획서'가 있고, 그 기획서대로 최대한 빠른 속도로 만든다. 모든 보고는 총괄 기획자인 PM 한 사람에게 몰리고, 그 PM이 대부분의 중요한 의사 결정을 다 한다. 프로젝트가 제때 결과물을 못 뽑고, 시간은 맞아도 결과물이 엉망이면 PM이 모든 책임을 다 진다.

나는 권위주의를 매우 싫어하고, 기획서를 완벽하게 뽑을 수 있을만큼 IT프로젝트 역량이 없는 사람이라 한국식, 혹은 미국 동부식 시스템을 쓸 능력도 없고, 쓰고 싶지도 않다. 나는 모든 사람과 서부식으로 일을 하고 싶다. 내가 모르는 부분을 그들이 지적하면 '죄송합니다, 제가 몰랐네요' 같은 표현을 쓰며 배우는 작업의 일부라고 생각한다.

자기가 능력이 부족해서 계속 못 다니겠다며 그만둔 직원 하나가 "실리콘 밸리식이라는게 이런 방식이라는 걸 좀 느꼈다"는 평가를 쓴 적이 있는데, "잘하면 엄청나게 칭찬해주고, 계속 채팅창에 정보가 올라오니까 열심히 읽어야하고, 사람들의 수준도 다 높고, 다른 사람 하는 걸 보면서 배우고, 큰 틀에서 뭘 해야한다는 정보가 주어진 상태에서 직접 찾아서 일을 해야하는 자율성 높은 구조"라는 표현을 썼었다. 단지 그 자율성 높은 구조에서 자기가 일을 잘 하기가 너무 힘들단다.

사실 내 성격이 이런 스타일이어서가 아니라, 그간 공부를 하면서 이게 맞다는 확신이 들었기 때문에 회사 운영을 이렇게 한다. 석사 시절에는 자기가 노벨상 받는게 확정됐지만 수업 중이라 아직 통보를 못 받은 상태인 교수님이 수업 노트 중 한 장에 대한 학생의 지적을 듣고는 "아직 답변이 불충분할 수밖에 없는 점을 양해해달라, 대신 내년에 다시 오면 그 때는 꼭 답을 찾을 수 있을 것 같다"는 표현을 쓰는 경우도 봤고, 박사 시절에는 이름만 들어도 입이 벌어지는 교수님들이 다른 박사 졸업생의 논문 발표를 성심껏 들으면서 그런 노벨상급 교수들끼리 저 논문을 어떻게 고쳐야겠냐고 함께 토론하는걸 수도 없이 많이 봤었다. 심지어 그 학생이 대화에 끼어들어 즉석에서 답을 내놓으니 자기가 모르는걸 배웠다고 교수들 몇 명이서 입을 모아 칭찬도 하더라.

위의 정부 중복 예산 배정 사건과 마찬가지로, 아무리 똑똑한 인간이라도 모든 정보를 다 갖추고 있을 수 없고, 다른 사람의 관점을 들으면서 내 생각은 꾸준히 진화한다. 최소한 난 그게 상식인 세상을 살았는데, 한국와서 일을 시켜보면, 누군가에게 평가를 던져보면, 자기를 비난한다고 생각하고 나에게 온갖 욕을 퍼붓고, 심한 경우에는 음해하고 정보를 왜곡해서 내 인생을 삭제해버리는 분들도 나타났다. 결국 그들의 거짓말과 음해에 맞대응하다보니 나도 사람이 악에 받친 인간이 되어 버리더라.

기획자를 뽑아야 되는게 아니라, 너네끼리 대화를 해라고

디자이너 2명에게 일을 시키면서, 한 명은 광고용 배너를 만들고, 다른 한 명에게는 배너가 들어갈 웹페이지 공간을 디자인해라고 시켜봤다. 둘이 전혀 대화를 안 하고, 심지어 그 웹사이트를 한번도 제대로 들어가보질 않으니, 뭘 해야되는지, 무슨 말인지 이해가 안 된다며, 나한테 뭘 만들어라고 구체적으로 지시를 달란다.

근데, 한 명에게 이야기하는 중에 다른 한 명은 안 듣고 있다. 그래서 A에게 설명이 끝난 후에 B에게 말을 하면서 아까 A에게 말을 했던 내용을 다시 설명해야하고, B의 의견을 받아 수정이 되고 나면 다시 A에게 찾아가서 또 설명을 해야 한다. 아니, 너네 둘이서 날 귀담아 듣고, 셋이서 업무 지시가 아니라 토론을 했으면 내가 그렇게 재설명, 재지시를 할 필요가 없었잖아? 근데 왜 너네 둘은 심지어 같은 업무군에 있는데 서로 듣질 않는거지? 혹시 싸웠니?

처음에는 서로 친해지도록 뭔가 더 해야겠다고 생각했었는데, 내가 가장 극혐하는 한국식 회식 문화를 해 봐도 둘이 대화하지 않는 것은 전혀 바뀌지 않더라. 그저 없던 대화 주제가 생기거나, 회사 욕을 하는 것에 그친다.

난 이사님, 부장님과 술 한잔을 하는 날이면 사무실에서 말을 못 했던 몇몇 업무 이야기들을 하고, 지시를 받고, 수면 아래에서 몰래 해야되는 일들을 그렇게 뒤처리로 했었는데, 평소에 사무실에서도 다른 팀원들과 공유되도록 뭘 하고 있다, 다음 프로젝트에 뭐가 필요할 것 같아서 미리 무슨 대응을 하는 중이다 같은 이야기들을 끊임없이 공유했었다. 심지어 그 직원 중 한 명이 내가 인생에서 다시는 보고 싶지 않은 '수드라'급으로 대하는 사람이었건만.

SKP 출신 개발자들이 영어권 6개월 부트캠프 출신들보다 못한 이유

지난 몇 년간 한국에서 개발자들을 뽑아보면서 이제 나는 확신을 갖고 말할 수 있게 됐다. SKP 출신의 한국 최고급 개발자들이 영어권의 비전공자 출신 6개월 부트캠프 교육 받은 개발자보다 개개인의 역량이 프로젝트 시작 시점에는 더 뛰어났을 것이다. 그런데 프로젝트 종료 시점에 영어권 초짜 개발자들이 최소한 해당 프로젝트의 전반적인 부분에 대한 이해도는 훨씬 더 뛰어났을 것이라고 자신있게 이야기 할 수 있다.

전체 개발 능력은 더 뛰어나지만 개별 프로젝트 특화된 전문 지식은 오히려 모자란 상황, 프로젝트의 자기 부분에 대한 지식은 더 뛰어나지만 프로젝트 전체 흐름에 대한 지식은 오히려 모자란 상황이 몇 달 동안의 업무 방식 때문에 심화되었을 것이기 때문이다.

프로젝트는 어차피 갖고 있는 모든 개발 지식을 총 동원해서 완성되지 않는다. 해당 프로젝트 마다 적절한 지식이 있다. 무조건 '최신 코드', '검증된 코드'를 써야 되는게 아니라, 그 프로젝트에 적합한 코드를 써야 하고, 검증이 안 되었으면 자기들이 검증해서 쓰면 된다. 어차피 대부분은 하루 남짓 Waging server에서 테스트 돌려보면 되는 일이잖아?

근데 더 큰 문제는 '서로간 대화', '정보의 공유'에 있다는 것을 알게 됐다. 한국식, 일본식, 혹은 대기업식, 혹은 동부식의 가장 큰 장점이자 단점은 PM의 역량이 모든 것을 좌우한다는 것이다. 수학 모델을 빌려오면 Star Network 방식이다. 최상위에 있는 총괄 관리자, 혹은 독재자만 유능하면 효율성을 최대치로 뽑을 수 있다.

반대로 서부식 모델은 업무가 어디로 가는지 알 수 없이, 중구난방으로 돌아간다는 느낌을 받을 것이다. 우리 디자이너들도 지금 파비리서치 웹페이지를 만들면서 각각의 언론사 페이지들을 만들고, 이런저런 기능을 갖다 붙이는걸 대응하려니 너무 힘들다고, 일단 하나를 다 만들고 난 다음에 이야기하자며 나한테 거의 빌다시피 불평을 늘어놨다. 근데, 그렇게 내 고집을 따라가다가 완성 무렵에 구글 페이지 스피드에서 대부분 100점, 서버 미완성 상태에서도 서버 성능으로 90점을 훌쩍 넘기는, 한국에서 보기 드문 완성형 서비스가 나온걸 보고 나서야 내 방식의 장점을 이해하는 눈치더라. 한국식으로 진행했으면 네이버, 카카오 홈페이지들처럼 60점 받는 웹페이지를 '완성'해 놓고, 이걸 다시 100점으로 끌어올리기 위해 웹사이트를 뜯어고쳤어야 했다. 아마 단순히 몇 군데 고치는 수준이 아니라, 웹사이트를 처음부터 다시 만들어야 했을 것이다.

한국식 개발자 용어를 빌리면, '서부식' 방식은 서비스 개발과 운영 개발이 연결된 구조고, '동부식' 방식은 서비스 개발을 기획서대로 완성하고 나야 운영 개발을 시작하는 분리형 구조다. 분리형 구조는 운영 개발을 하면서 자칫 시스템 전체를 다시 만들어야 되는 사건도 생긴다. 반면 우리 회사 서버는 무슨 운영 개발을 추가한다고 갑자기 점수가 100점에서 50점으로 크게 뚝 떨어지는 일이 없는, 매우 안정적인 서비스를 하는 회사가 됐다. 서비스 개발 중간에 수 많은 내용들을 보완하면서 완성 시간이 좀 늦어지더라도 원하는 기능들을 다 추가할 수 있는 형태로 만들어졌기 때문이다.

작은 서버 하나로 성능 점수 99점을 받을 수 있고, 향후 대응에 유연하고, 근데 웹서비스 만든 사람은 개발자 교육을 한번도 받지 않았고, 교육을 서구식으로 해야한다고 반복적으로 주장하는 사람이 만든 웹사이트와, 국내의 고액 연봉을 요구하는 한국인 개발자들 수십, 때로는 수백 명이 장기간 투입되어서 만든 웹사이트, 심지어는 막대한 서버 비용까지 지불하고 있는 서비스 사이에 왜 이렇게 크게 완성도 차이가 나는지, 지난 2달 남짓의 노력으로 증명이 됐다고 말할 수 있지 않을까?

이렇게 서로 협력하는 대화를 계속 반복적으로 이어가야 예산 중복 배정 같은 쪽팔리는 사건도 터지지 않고, 6개월 부트캠프 출신 비전공자들보다 웹서비스 엉망으로 만드는 사건이 안 생긴다. 그런 사건을 겪고 싶지 않으면 PM이 삼라만상을 다 꿰뚫는 전지전능한 신이어야 한다. 근데 그런 신이 세상에 어딨나?

신이 없는데, 프로젝트 기간은 짧고, 그럼 서비스 개발이라는 것이 결국 아는 걸 따라하는 방식으로 밖에 돌아가지 않는다. 그저 전에 해봤던 프로젝트를 반복하면 다 아는 내용이니까 생각하지 않아도 되니, 베끼기 전문가들이 양산될 수밖에 없는 구조가 탄생하는 것이다.