혁신의 중심의 실리콘밸리 대기업을 가다

실리콘밸리 대기업으로의 이직

아마존이 악명 높은 회사 문화, 강도 높은 업무 환경, 엉망진창인 새 팀 구성 등 안 좋은 점도 많았지만 3년 반 정도 근무를 하면서 다수의 프로젝트들에 참여하고 중간에 승진도 한번 하면서 개인적으론 소프트웨어 엔지니어 커리어에서 튼튼한 기초를 다져준 회사인 것만은 분명하다. 

효율적인 시스템 속에서 대기업이 어떻게 성장할 수 있는지 몸소 경험할 수 있는 좋은 시간들이었다. 

하지만 3년 차쯤 되자 새로운 배움 보단 반복되는 시스템 속에서 정체기가 찾아왔다. 

개인적으로 변화가 필요한 시점이었다. 

사실 평균 근속 기간이 2년도 채 안 되는 아마존에서 3년 반이면 꽤 오래 근무 한 축에 속했다.

이직을 고민하면서 이것저것 생각을 해보다가 그동안 시애틀에 위치한 아마존에서 근무를 하면서 메인 스트림인 실리콘밸리와는 조금 거리가 있다는 게 항상 아쉬웠는데 다음 직장은 실리콘밸리인 베이 에어리어로 돌아가서 다시 실리콘밸리를 제대로 배워보자고 마음을 먹고 준비를 시작했다. 

두 번째 이직이 되는 이번 준비는 스타트업에서 아마존으로 이직을 할 때보다 사실 훨씬 수월했다. 

경력도 4-5년쯤 쌓이고 아마존을 다니면서 인터뷰를 하는 입장이 돼서 다수의 인터뷰들을 하다가 보니 어떻게 하면 인터뷰를 잘 볼 수 있을지 노하우도 나름 생기고 무엇보다 여유가 생겼다. 

물론 이직을 준비하는 과정은 전과 마찬가지로 회사와 팀에는 철저히 비밀에 부쳐야 했다. 

혹여나 이직을 준비하다가 잘 안 풀릴 경우를 대비해서 현재 하고 있는 일에는 최대한 영향을 안 끼칠 수 있도록 하면서 가까운 지인들을 제외하곤 내가 이직을 준비하고 있는지 조차 낌새를 못 채게 몰래 진행했다.

최악의 경우엔 현재 다니고 있는 회사를 계속 다니면 되는 거라 큰 부담 없이 이직을 준비할 수 있었던 것도 이직을 준비하는데 심적으로 도움이 됐다. 
아마존에서 4-5년의 경력이 이력서에 들어가니 이제는 회사도 골라서 인터뷰를 볼 수 있을 정도가 되었다. 

전화 인터뷰는 어렵지 않게 통과할 수 있었고 원하는 회사 두세 군데에서 온사이트 인터뷰까지 갈 수 있었다.

물론 온사이트 인터뷰는 전화 인터뷰처럼 호락호락 하진 않았다. 

인터뷰 준비도 몇 달 동안 충분한 시간을 가지고 준비를 했지만 역시나 어렵고 긴장이 되었다.

다행히도 최종적으로 목표로 했던 실리콘밸리에 위치한 혁신의 중심이 되는 A사로부터 오퍼를 받을 수 있었다. 
아마존에서 A사로 이직을 할 때 과정은 아주 자연스러웠다.

기본적으로 회사도 언제든 직원을 내보낼 수 있고 직원도 언제든지 회사를 조건 없이 나갈 수 있는 관계인 것도 있었고 회사의 규모가 크고 직원들이 워낙 회사에 새로 들어오고 또 나가는 게 빈번하다 보니 직원이 퇴사하고 다른 회사로 이직을 하는 게 마치 일상 인양 이직의 과정이 굉장히 부드럽게 이루어졌다. 

A사에서 온 오퍼 레터에 최종적으로 사인을 하고 나서 매니저에게 보고를 하니 고맙게도 매니저는 회사에 남게 하기 위해 카운터 오퍼를 제안했지만 정중히 거절하고 퇴사의 과정을 진행했다. 

퇴사 전 2주간의 시간 동안 그동안 하던 프로젝트를 정리하고 다른 동료에게 인수인계를 하는 시간을 가질 수 있었다.

마지막 날에 회사 랩탑과 배지를 반납하면서 아마존에서의 직장 생활을 마무리하였다. 

노장 회사 = 늙은 회사

나의 3번째 직장이 된 A사는 실리콘밸리의 위치한 미국의 대표적인 테크 기업이다. 

실리콘밸리에서 첫 직장이었던 스타트업에서 안 좋은 기억이 있었지만 이번엔 스타트업이 아닌 대기업, 그중에서도 혁신을 이끌고 있는 A사로의 이직을 하게 돼서 기대가 남달랐다. 

실리콘밸리에서의 첫 도전은 아무것도 모르는 상태에서 만난 하드코어 스타트업에 된통 당했다면 이번엔 몇 년간 실력을 갈고닦아서 새로 도전하는 기분이었다. 

A사는 한때 파산 위기도 극복하고 산전수전을 다 겪은 42년 차가 된 미국의 대표적인 백전노장의 기업이고 이젠 혁신하면 가장 먼저 떠오르는 회사일 정도로 미국에서도 대표적인 회사이고 특히 스마트폰의 대중화를 이끌면서 새로운 전성기를 맞고 있다. 

때문에 A사로의 입사 전부터 기대감에 잔뜩 부풀어 있었다.

회사 근무 환경도 다른 회사들보다 앞서 나가고 혁신적인 문화 속에서 빠르게 변하는 테크산업의 중심에 서 있을 거라고 단순히 생각을 하고 있었다. 

하지만 나의 기대는 초반부터 완전히 무너졌다 

기대가 컸던 탓인지 오히려 내가 갖고 있었던 기대와는 정반대로 회사 내부에선 굉장히 느리고 오히려 시대에 한참 뒤처진 문화와 개발 환경을 가지고 있었다.

새로 들어오는 직원들에 대한 교육이나 그를 위한 프로그램도 안 갖춰져 있었고 신입 직원을 도와주는 역할 (new hire buddy)로 팀 멤버 중 한 명 지정해주긴 하는데 나의 경우에는 그마저도 다른 도시에서 원격으로 일을 하고 있는 직원을 지정해줘서 보기도 힘들었다. 

보통 처음 램프 업(Ramp-up) 기간 동안 문서들을 통해서 필요한 지식을 얻고 일을 배우는데 문제는 오래된 문서들이 많았고 제대로 된 문서를 찾기가 힘들었다. 

그나마 있는 문서들은 업데이트가 잘 안 돼 있었고 보는 사람이 알아서 걸러가면서 필요한 부분만 찾아서 보고 또 찾은 정보가 아직도 유효한지를 일일이 확인해야 했다. 

그게 아니면 담당자나 그 분야를 잘 알만한 직원들을 일일이 찾아다니면서 직접 물어봐야 했다. 

효율성에선 당연히 최악이었다. 

특히나 신입 직원들에겐 누가 담당자인지 누구한테 물어봐야 하는지를 찾는 일도 힘들었다. 

전반적으로 업무들이 완전 구구 주먹 식이 었다. 

이 회사가 그 혁신의 중심에 있는 A사가 맞는지 의심이 들 지경이었다. 

소프트웨어 개발 환경도 딱히 다를 건 없었다.

온라인 서비스/소프트웨어를 개발하고 있는 부서에서 일을 하게 됐는데 이제는 A사 외에는 거의 아무도 안 쓰는 한때는 오픈소스였다가 닫아 버려서 이젠 업데이트도 거의 안 되는 프로그래밍 계에선 고대의 유물 같은 오래된 프로그래밍 언어를 바탕으로 아직도 많은 소프트웨어 유지/개발이 이루어지고 있었다.

대기업들이 워낙 덩치가 커서 변화에 느리고 오래된 시스템과 레거시 코드(Legacy Code)를 유지하는 건 어쩔 수 없기는 하지만 A사도 크게 다를 바는 없었다.

오히려 이 점에선 아마존에 비해서도 한참 뒤처졌다. 

당연히 애자일 소프트웨어 개발 프로세스 (Agile Software Development) 따윈 안중에도 없었고 온라인 서비스 개발조차 하드웨어 혹은 OS 개발 사이클에 맞춰서 폭포수 모델 (Waterfall Model) 방식에 맞춰 1년 주기로 소프트웨어 서비스 개발을 하고 있었다.

* 애자일 개발 프로세스 (Agile Software Development)는 소프트웨어 개발 프로세스로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다.

* 폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌는데 이 모델은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이르는 게 특징이다.  

하지만 이보다 더 큰 문제는 회사 문화 자체가 새로운 것을 받아들이는 데에 굉장히 인색하다는 점에 있었다. 

솔직히 이 점에서 개인적으로 가장 놀랐다. 

혁신의 중심에 서서 새로운 것을 탄생시키고 개발하는 회사에서 오히려 외부에서 들어오는 새로운 것을 잘 받아들이지 않는다는 점이 굉장히 아이러니했다. 

전반적인 인식이 이미 잘 작동되고 있는 건 건드리기 싫어하고 새로운 기능을 더하고 서비스 개발을 하는 것에만 중점을 두면서 시스템 자체에 변화를 주는 것을 꺼려하는 듯했다.

그리고 이미 기존 시스템과 개발 프로세스에 익숙해져 버린 시니어 직원들이 새로운 방식과 개발 프로세스를 배우고 적용하는 데에 인색해하다 보니 회사 전반적으로 영향을 주고 있었고 편한 방식에 안주해 있다 보니 변화에 대처하는 속도가 점점 느려지면서 그에 따른 비효율적인 부분이 굉장히 많이 생기고 있었다.

특히나 요즘처럼 변화가 빠르고 새로운 기술과 프로세스가 쏟아져 나오고 있는 시대에는 이런 식으로는 점점 뒤처지는 건 당연한 수순이었다. 

외부에서 보기엔 새로운 제품을 만들고 스마트폰 시장을 리드하고 있을진 몰라도 회사 내부에선 점차 시대에 뒤처지고 있다는 게 직접적으로 느껴졌다. 

또한 비밀이 많은 A사의 문화도 이러한 분위기를 만드는데 한몫하고 있었다. 

대부분의 프로젝트들이 회사 내에서도 비밀리에 진행이 되는데 비밀 유지를 위한 노력이 지금의 폐쇄적이고 단절된 기업 문화를 만들어 내고 있었다. 

특히나 소프트웨어 개발에서 이런 폐쇄적인 문화는 최악이다.

지식 공유의 통로가 막혀 있으니 회사 내에서 심지어 부서 내에서도 공유 자체가 잘 안되고 비밀 유지를 위해서 소프트웨어 개발의 핵심인 팀워크와 협동을 버려야 돼서 개발 프로세스도 굉장히 비효율적일 수밖에 없었다. 
칸막이가 있는 큐비클 오피스였던 아마존과는 다르게 A사에선 개인 오피스가 주어졌는데 개인적으론 개인 오피스가 생겨서 좋았지만 문제는 벽과 문으로 단절된 근무 공간이 폐쇄적인 회사 환경에 한몫하고 있었다. 

A사에 입사하고 처음 몇 달 동안 회사 와서 아무도 안 만나고 혼자서 일 하다가 퇴근했던 적도 많았을 정도로 직원들끼리 왕래가 적었다.

이대로 A사가 예전 방식을 고수한다면 10년 뒤에도 과연 혁신의 중심에 서 있을 수 있을까 라는 의구심이 강하게 들었다.

그래도 뒤늦게나마 변화의 바람이 조금씩 불기 시작했지만 아직도 받아들이는 게 한참 느렸고 기본적으로 새로운 것을 받아들이게 인색한 직원들의 인식의 변화가 시급해 보였다. 

전형적으로 시대에 뒤쳐진 노장 기업들에서 나타나는 안 좋은 현상들이 혁신의 선두에 선 회사에서도 보인다는 것이 아이러니하면서도 안타까웠다. 

상황이 이렇다 보니 A사가 전반적으로 시대에 점차 뒤처지고 있는 느낌을 지울 수가 없었다. 

혁신의 선두에 선 혁신적이지 않은 회사

혁신의 중심에 있는 A사는 입사 전까지만 해도 다른 회사들보다 더 철저하고 제대로 된 시스템을 갖추고 모든 면에서 완벽을 추구할 것 같은 회사 이미지였다.

하지만 막상 입사를 하고 본 회사 내부의 모습은 오히려 내 예상과는 정반대였다.

사실 A사는 근간이 하드웨어 제조업이기 때문에 내가 속했던 소프트웨어/서비스 분야에서는 아직 황무지에 가까울 정도로 완벽과도 거리가 한참 멀었다.

일단 가장 단적인 예로 소프트웨어 개발의 기본이 되는 문서화가 하나도 안 돼 있었다.

비밀 유지를 위한 폐쇄적인 개발 문화/환경 때문인지 몰라도 소프트웨어 개발에 관련된 문서들이 제대로 갖춰져 있지 않았다. 

소프트웨어 개발을 하는 데 있어서 문서의 부제는 상당히 큰 문제였다.

지식 공유가 문서가 아닌 사람과 사람을 통해서 이루어져야 했고 모르는 게 있으면 문서를 찾아서 알아내는 게 아니라 그걸 가장 잘 알고 있는 직원을 찾아가서 일일이 물어봐가면서 배워야 했다.

당연히 효율성면에서 엄청나게 떨어졌다. 

새로 엔지니어가 들어오면 기본적인 트레이닝 프로세스도 안 갖춰져 있고 다른 사람들에게 물어서 알아서 배워나가거나 코드를 보면서 혼자서 터득해야 했다.

말 그대로 몸으로 직접 부딪히면서 배워야 하는 구식 방식이었다.

회사 시스템이 이러다 보니 A사에서 오래 일한 사람들에게 지식 쏠림이 생겨서 회사 시니어 직원들이 하나하나 전수를 해 줘야지만 지식이 다른 이들에게 공유되고 있었다.

예상할 수 있듯이 더 안 좋은 점은 지식을 독점하고 있는 시니어 직원이 나갔을 경우이다. 

지식 공유가 완전히 되지 않은 상태에서 지식을 독점하고 있던 직원이 회사를 떠나버리면 그 지식은 직원과 함께 영영 사라져 버린다.

소프트웨어 엔지니어로써 문서화 문제보다 더 당황했던 건 코드의 테스트들이 하나도 없었던 것이었다.

가장 기본적인 유닛 테스트 (unit test) 마저 하나도 없었다.

* 유닛 테스트(unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 

그 이유를 들어보니 기본적으로 소프트웨어 개발 부서의 리더들이 유닛 테스트의 필요성을 못 느끼고 있었다.

테스트를 전담해서 하는 QA팀이 따로 있었고 애초에 유닛 테스트를 생략하고 개발하던 사이클에 개발자들이 익숙해져서 생략해도 되는 부분이라고 여기고 있었고 유닛 테스트를 만드는데 쓰는 시간을 새로운 기능 개발에 더 시간 투자를 하는 게 맞다고 여기고 있었다. 

통합 시험 (Integration Test)는 당연히 없었고 이런 기본적인 소프트웨어 자동화 테스트들의 부제를 QA 팀이 수동 테스트를 통해서 메우고 있었다.

* 통합 시험(Integration Test)은 유닛 테스트가  끝난 소프트웨어를 통합적으로 시험하는 방법이다. 유닛 테스트가 끝난 소프트웨어를 통합 구성한 후,  계획에 따라서 테스트를 수행한다. 

마치 하드웨어 디바이스 테스트를 하듯이...

소프트웨서 개발 사이클의 마지막이 QA 팀에서 수동 테스트였고 이를 통과한 후에야 프로덕션으로 릴리스가 될 수 있었다. 

당연히 소프트웨어 서비스들을 일일이 수동 하는 테스트에는 한계가 있었고 그에 따른 많은 고질적인 문제들을 달고 살았다.

환경이 이렇다 보니 시스템은 안정적이지 못했고 서비스들은 문제를 일으키기 일쑤였다.

그리고 이런 문제들은 고스란히 유저들에게 돌아갔다.

가만히 생각해보면 A사의 온라인 서비스들은 평판이 좋지 않은 게 많았는데 그 이유를 그제야 찾을 수 있었다. 

여기에 더해 더 큰 문제는 그나마 있는 QA 팀이 아주 솔직히 말해서 형편없었다.

엉터리 테스트를 하는 일도 종종 있었고 QA 팀 내에서 지식 공유도 안 되고 개발 속도에도 못 쫓아오고 있었다.

사실 소프트웨어 온라인 서비스 개발과는 안 맞는 구조였는데 옛날 방식을 고수하면서 단순히 QA 팀 그 자체를 유지를 하기 위해 옛날 방식을 고수하고 있는 듯 보였다. 

상황이 이러다 보니 결국 제대로 된 테스트 없이 릴리즈가 되는 경우도 종종 있었는데 어느 때부터인가 릴리즈 후에 유저의 반응을 살피기 위해서 트위터에 의존하고 있었다. 

트위터는 내가 속한 팀이 개발하는 온라인 서비스의 전 세계 유저들이 서로 정보 교환을 하는데 많이 사용하고 있었는데 유저들이 주로 문제점을 찾아서 서로 공유하고 있었기 때문에 가장 빨리 유저들의 반응을 살펴볼 수 있었다. 

유저 입장에선 A사 담당 부서에 직접 연락해서 문제점을 알리는 것보다 이렇게 공개적으로 트위터에다가 A사 회사명, 대표 등을 해쉬태그 해서 올리는 게 더 빨리 문제 해결이 된다는 걸 알고 있어서 문제만 생기면 트위터에 올렸다. 

이렇게 A사 온라인 서비스 팀과 유저들과 암묵적인 룰이 생기고 비공식적인 커뮤니케이션 채널이 생기게 된 것이다. (결국 나중엔 공식 트위터 계정이 생겼다.)

도대체 왜 실리콘밸리 대표적인 혁신 기업에서 이런 엉망인 프로세스로 소프트웨어 개발이 이루어지고 있는 걸까?

내가 생각했던 답은 회사의 근간에 있었다. 

A사는 컴퓨터 제조업으로 시작을 하였다. 

지금은 다양한 전자기기와 소프트웨어도 개발, 제작하고 있지만 그 뿌리는 하드웨어 제조업에 있었다. 

때문에 소프트웨어 개발에 최적화된 환경이 아니라 하드웨어 개발에 최적화된 환경에 온라인 소프트웨어 개발까지 하게 된 것이다. 

그러다가 보니 온라인 소프트웨어 개발은 적합하지 않은 프로세스들이 여기저기 자리 잡고 있었다. 

소프트웨어와 하드웨어의 개발은 여러 면에서 다르다. 

우선 소프트웨어는 하드웨어에 비해서 중간에 바꾸고 고치는 게 쉬워서 그에 드는 비용이 훨씬 적다. 

반면 하드웨어는 제조가 돼서 소비자에 손에 들어가는 순간 하드웨어 결함은 고치기가 쉽지가 않다. 

그래서 하드웨어 개발은 처음 버전부터 완벽하게끔 개발을 하기 위해서 소프트웨어 개발에 비해 테스트에 시간과 비용을 훨씬 많이 쓴다. 

물론 소프트웨어도 버그가 없이 최대한 완벽에 가깝게 개발을 하는 것을 추구 하지만 하드웨어와는 달리 출시 후에도 버그를 고치고 개선해 나갈 수가 있다는 점이 가장 큰 차이이다. 

그래서 개발 과정도 여러 번의 릴리즈를 거치면서 새로운 기능들도 더해지고 소프트웨어가 순차적으로 진화될 수가 있어서 간단한 기능만 가지고도 개발을 시작할 수 있고 중간에도 언제든지 그 방향을 바꿀 수가 있다. 

소프트웨어를 하드웨어 개발하듯이 워터폴 방식으로 개발을 진행하면 프로세스가 효율적이지 않고 중간에 생기는 변화에 대처하기가 쉽지가 않아지는 것이다.

하지만 A사에선 아직도 하드웨어 개발 방식에 소프트웨어 개발을 맞춰서 진행하고 있었다.

하드웨어 발표에 맞춰서 1년을 주기로 큰 프로젝트를 진행하고 예전 방식에서 못 벗어나고 있었다. 

A사에서 일을 하면 할수록 어떻게 이런 환경에서 전 세계를 놀라게 하는 혁신이 나올 수 있었나 의구심이 생기기까지 했다. 

그냥 단순히 오래된 회사이다 보니 이런 오래된 관습과 뒤쳐진 문화들은 고스란히 유지가 되고 있고 혁신은 기업 문화나 개발 환경이 아닌 다른 곳에서 나오는 게 아닌가 하는 생각마저 들었다. 

구구 주먹식 방식은 이뿐만이 아니었다. 

인사고과 직원 평가에서도 이런 구구 주먹식의 절차가 이뤄지고 있었다.

보통 회사가 정해준 원칙들을 기준으로 동료 평가도 이루어지고 스스로의 평가도 해서 매니저가 최종적으로 연말 인사고과 평가를 해주는데 A사에서 내 첫 매니저는 지나치게 솔직했던 것일까 정식 절차를 다 생략하고 바쁘다는 핑계로 그런 거 없어도 자신이 다 잘 알고 있다며 알아서 인사 평가를 주었다. 

물론 인사고과 평가를 잘해주긴 했지만 이런 식으로 모든 절차를 생략하고 인사고과가 이뤄진다는 사실이 놀라웠다. 

지켜지지 않는 비밀 아닌 비밀

A사는 비밀이 특히나 많은 회사였다.

그리고 회사 내 비밀유지가 다른 무엇보다 최우선이 되었다. 

회사 내에서 진행되는 프로젝트 하나부터 열까지 거의 모든 일이 비밀 프로젝트라고 봐도 될 정도였다.

심지어 같은 팀 동료들끼리도 서로 다른 프로젝트에 참여하게 되는 일도 종종 있었고 그런 경우에는 서로의 일에 대해 알지도 못하고 상의하는 것도  당연히 안 됐다. 

직원들은 어떤 프로젝트에 참여하고 있느냐에 따라서, 혹은 어떤 프로젝트의 기밀유지 협약 (Non-disclosure agreement)에 사인했느냐에 따라서 자신의 회사 배지로 들어갈 수 있는 건물이 달라지고 미팅이 달라진다. 

비밀 프로젝트 관련한 미팅은 그 건물 외에 장소에서도 하면 안 되고 비밀 프로젝트 내에서도 파트 별로 NDA가 따로 있어서 미팅에서도 미팅 내용에 관련된 프로젝트 NDA에 사인 안 한 사람들은 다 나가라고 할 정도로 비밀 유지에 심혈을 기울인다. 

* NDA (Non-disclosure agreement): 기밀유지 협약은 기업 간에 사업비밀을 공유하면서 사용을 제한할 때 체결하는 계약이다.

이런 비밀 중심의 사내 문화는 위화감을 조성하기도 하였다. 

회사 내의 본인의 레벨이 어느 건물에 들어갈 수 있고 어떤 미팅에 참여할 수 있느냐에 따라서 보이기도 한다. 

이런 비밀 중심의 문화는 그동안 A사의 많은 프로젝트들에서 전략적으로 잘 이용되고 있었고 그 효과도 그동안 충분히 있었지만 그로 인한 역효과로 회사 전반적인 문화에 영향을 끼쳤다.

회사 내에서 지식/정보 공유가 원활히 되지 못했고 엄격한 비밀 유지 규율 때문에 팀들 간 협업도 순탄치가 않았다. 

하드웨어 부서 같은 경우에는 하드웨어 디바이스에 들어가는 파트당 나뉘어서 내가 지금 하고 있는 프로젝트가 어느 디바이스에 언제 나가는지도 모르는 상태에서 프로젝트가 진행되는 경우가 많았다. 

새로운 디바이스가 발표가 되는 그날에서야 내가 그동안 했었던 프로젝트가 발표된 디바이스에 포함이 됐구나 하고 알 수 있을 정도였다.

직원들에게는 프로젝트에 필요한 최소한의 정보만 주어지고 각 부서 간 비밀 유지를 위해서 협업에는 크게 방해가 되고 프로젝트 진행에 많은 영향을 줬다. 

당연히 가족에게 이야기하는 것도 안 되다 보니 가족들도 내가 어떤 일을 하고 있는지 전혀 알지 못한다. 

상황이 이러다 보니 가족들과 대회를 나눌 때도, 지인들과 대화를 나눌 때도 실수로라도 말을 잘못할까 항상 조심하면서 다녀야 해서 불편한 게 이만저만이 아니었다. 

회사에선 이런 철저한 비밀 유지를 통해 새로운 프로덕트나 서비스가 나올 때마다 신제품 발표를 통해 고객들에게 서프라이즈를 주려고 한다. 

신제품 발표 마지막에 “One More Thing…” 의 문구로 사람들의 기대심과 함께 서프라이즈를 안겨주면서 유저들의 관심과 즐거움을 더해 주었다. 

하지만 안타깝게도 요즘엔 이런 서프라이즈는 이젠 옛이야기가 된 듯하다. 

이젠 잘 안 먹힌다.

아니, 잘 안 먹힌다기보다 회사 내에서 비밀 유지가 전혀 안 된다.

예전에는 내부 정보가 새어나가는 경우가 직원이 실수로 미발표 제품을 공공장소에 실수로 놔두고 오는 어리석은 실수로 사진이 유출되는 수준이었다면 이젠 발표 전에 자세한 다자인 사진들과 하드웨어 사양까지 거의 대부분의 정보가 유출된다.

최근 몇 년 간은 거의 100% 발표 전에 정보 유출이 됐다.

이유로는 내부적으로도 일단 많이 새고 디바이스를 자체를 예전처럼 미국 본사에서 만드는 게 아니라 중국이나 외부에서 대부분 만들어 오기 때문에 비밀 유지가 거의 안 된다.

그러다 보니 이젠 신제품을 깜짝 발표하려고 해도 기존의 깜짝 효과가 전혀 없다.

오히려 이미 유출이 되거나 잘못 알려진 정보에 의해 유저들을 기대하게 했다가 발표가 안 되면 반대로 실망감만 안겨준다.

회사의 내부 비밀 유지의 노력이 무색해지는 시기이다.

어쩔 때에는 회사 직원들도 밖으로 새 나간 정보로 다른 팀들의 신 제품 소식을 듣기도 한다. 

물론 비밀만 잘 지켜진다면 효과야 말할 수 없을 만큼 크겠지만 이제는 비밀을 지키기 위해 폐쇄적인 문화를 어느 정도 완화해서 변화를 받아들이고 시대 흐름에 맞게 변화할 때가 온 게 아닐까? 

실리콘밸리형 기업 꼰대 문화

A사는 탑다운 방식의 수직적 위계형 기업문화를 가지고 있는 전형적인, 그리고 대표적인 미국 대기업이다.

때문에 위에서 까라면 까야하는 식의 상명하복의 기업 꼰대(?) 문화도 가지고 있었는데 개인적으로는 실리콘밸리에서, 그것도 혁신의 중심이 되는 기업에서 꼰대 문화는 사실 상상도 못 했다.

A사에서 꼰대 문화를 느끼게 해 준 몇몇 에피소드들이 있었는데 한 번은 이런 일이 있었다. 

보통 큰 프로젝트가 진행이 되면 상무(VP) 급 되는 임원이 프로젝트 리뷰 미팅을 통해 프로젝트 진행 상황이나 전반적인 프로젝트 방향에 대해 보고를 받게 되는데, 이를 위해 여러 팀이 함께 중간보고 형식으로 발표하는 미팅을 하고 상무급 임원은 발표를 쭉 듣고 전체적인 프로젝트들의 관해 질문도 하고 피드백을 주거나 막히는 부분을 해결해주기도 한다.

한 번은 느지막이 미팅에 들어온 임원이 기분이 안 좋았는지 전반적으로 안 좋은 피드백만 쏟아내고 그중 한 프로젝트는 마무리 단계의 프로젝트를 대대적으로 수정해야 할 정도의 안 좋은 피드백을 주면서 미팅이 끝났다. 

그리고 한 달 뒤, 안 좋게 피드백을 받은 팀은 한 달 동안 임원의 피드백을 최대한 적용해서 수정한 프로젝트를 다시 발표하였는데 그 임원이 또 저건 왜 저렇게 했냐 트집을 잡기 시작했다.

문제는 트집을 잡는 부분이 한 달 전 자신이 피드백을 줘서 바꾸라고 했던 부분인데도 말이다.

그 임원 바로 밑에 있는 다른 임원이 '네가 지난번 미팅 때 저렇게 하라고 피드백을 주지 않았냐'라고 하니, '내가?? 진짜 내가 그랬어? 지금 보니까 별로네. 다시 바꿔!'라고 하면서 미팅이 끝났다.

물론 능력이 있어서 그 자리에 올라갔고 평소엔 날카로운 지적과 중요한 피드백을 많이 주는 임원이었지만 그날 그 모습은 실망스럽기 짝이 없었다.

무엇보다 의사소통이 이런 방식으로 밖에 안 되고 있다는 부분에서도 적지 않게 놀랐다.

제대로 된 피드백이 이루어지려면 충분한 시간을 가지고 양방향 대화가 이루어져야 하는데 짧은 시간에 이루어지는 리뷰 미팅이라 대부분 일방적인 지시에 가까운 피드백을 주고 있어서 이런 문제가 생기고 있었다.

더 큰 문제는 이런 피드백을 받은 담당자가 그대로 팀에 가져가서 팀원들에게 이를 적용할 것을 지시하는 데 있었다. 

전형적인 탑다운 방식의 수직적 의사소통의 안 좋은 예를 보여주는 에피소드였다. 

또 다른 한 에피소드로 내가 참여한 한 프로젝트가 진행될 때에는 이런 일도 있었다.

규모 꽤나 큰 프로젝트였고 여러 팀이 같이 오랫동안 프로젝트를 진행을 한 장기 프로젝트였는데 마지막까지 거의 다 와서 하루아침에 프로젝트가 엎어졌다.

여러 프로젝트들 중 핵심이 되는 프로젝트 하나가 기한을 못 맞춘 것이다.

물론 이런 상황은 프로젝트가 진행이 되면 비일비재한 일이지만 문제는 커뮤니케이션의 부제였다.

많은 팀들이 6개월 혹은 1년 동안 런치에 맞춰 밤낮으로 일을 해오다가 프로덕트 런치 하는 날이 거의 다 와서 하루아침에 일방적 통보를 받은 것이다.

이렇다 저렇다 설명도 없이 임원 미팅에서 최고위 간부가 미루기로 결정했다는 게 내가 들은 전부였다.

열과 성을 다해서 프로젝트에 참여했던 엔지니어들의 입장에선 그것만큼 허무한 일이 없었다.

커뮤니케이션 방식이 위에서 내려오는 일방적인 통보가 아닌 주기적으로 팀 간의 커뮤니케이션이나 최종 결정에 대한 충분한 설명과 추후의 계획에 대해 의사소통만 잘 이루어졌어도 이렇지는 않았을 텐데 회사의 폐쇄적인 문화나 프로젝트 진행 방식이 이런 식의 문제를 만들게 되는 것이다.

이래서 ‘위에서 까라면 까야지 우리가 어쩌겠어'라는 식의 대화가 A사에서도 흔하게 나오고 있었다.

흔히들 꼰대 문화를 우리나라 기업 문화를 비판할 때 많이 쓰여왔다.

한국에서 한국 기업을 비판하면서 가장 많이 들먹이는 게 꼰대 문화와 그와 상반된 실리콘밸리의 기업 문화를 비교하곤 했는데 정작 실리콘밸리 대표적인 기업이 이런 꼰대 문화를 가지고 있다니 사실 놀라웠다. 

하지만 다시 생각해보면 꼰대 기업 문화가 비단 한국 기업에만 있는 문화가 아니고 그리고 또 실리콘밸리라고 우리가 이상적이라고 생각하는 그런 기업 문화들만 자리 잡고 있는 것 또한 결코 아니라는 것을 보여주는 단적인 에피소드들이었다.