2010년, 필자는 해고됐다. 그럴 만했다. 필자가 틀린 것은 아니었지만, 해고당할 만했다. 모순되는 상황이었지만, 이 속도에 흥미로운 교훈이 있다.

필자는 한때 실리콘밸리에서 명성을 떨치던 회사에서 개발팀을 관리하고 있었다. 이 회사는 전성기를 지나 쇠퇴하고 있었지만, 개발팀은 여전히 뛰어났다. 우리가 개발하던 제품은 한때 인기를 끌었던 소프트웨어 개발 도구였지만, 점차 시장에서 잊혀지고 있었다. 우리가 코어팀이라고 부르던 우리 경영진은 훌륭한 사람들이었고, 필자는 그 일을 즐기고 있었다.

우리가 개발하던 제품은 하나의 대형 설치 파일로 구성된 모놀리식 구조였다. 전체를 한 번에 빌드하고 배포해야 했으며, 연 1회 정도 릴리스했다. 개발은 새로운 기능 추가와 버그 수정에 집중됐고, 이는 정기적인 대규모 릴리스를 목표로 진행됐다. 하지만, 컴파일러, 런타임 라이브러리, 시각적 프레임워크, 통합 개발 환경(IDE) 등 복잡한 구성 요소를 포함하고 있어, 모든 것을 통합해 빌드하는 것은 결코 쉬운 일이 아니었다.

제품을 시장에서 경쟁력 있게 유지하기 위해서는 플랫폼 전환이 필수적이었다. 처음에는 Win16에서 Win32로 전환했고, 이후 리눅스 진출을 시도했으며, 최신 윈도우 버전과 Win64로의 소규모 전환도 있었다. 제품이 크고 복잡했기 때문에 이런 플랫폼 전환은 쉽게 이루어지지 않았다.

개발팀과 QA팀은 경험이 풍부했고, 제품의 새로운 버전을 출시하기 위해 필요한 사항과 플랫폼 전환에 추가로 필요한 노력을 잘 알고 있었다.

오해의 씨앗

이 기업이 겸손해진 계기 중 하나는, 더 작은 데이터베이스 도구 개발 회사에 인수되어 새로운 고위 경영진이 들어온 것이었다. 과정은 비교적 정상적으로 진행되었고, 중간 관리진은 새로운 경영진에 조심스럽게 낙관적인 태도를 보이며 적응해 나갔다. 우리는 새로운 질서에 통합되기 위해 최선을 다했다.

SQL/데이터베이스 개발 도구와 일반적인 소프트웨어 개발 도구는 겉보기에는 유사하지만, 우리 제품은 새로운 모회사 제품보다 한층 더 깊고 복잡했다. 이런 불일치는 통합에 어려움을 초래했다. SQL 통합 개발 환경과 프로그래밍 IDE는 겉보기에는 비슷해 보이지만, 우리의 제품은 기본 프레임워크, 라이브러리, 컴파일러 등에서 SQL 파서와 편집기보다 훨씬 더 복잡했다.

이런 차이는 새로운 경영진이 이해하기 어려운 부분이었다. 그래서 우리의 도구를 리눅스와 맥 OS로 동시에 크로스 플랫폼화하기로 결정했을 때, 새로운 경영진은 이런 플랫폼 전환의 도전과 어려움을 제대로 이해하지 못하는 듯했다.

코어팀은 두 플랫폼을 지원하기 위해 필요한 사항을 검토했고, 현재 인력 수준을 고려할 때 각 플랫폼당 약 18개월이 걸릴 것으로 추정했다. 우리는 프로젝트를 전방위적으로 추진하고 인력을 추가 채용해 이 주기를 단축할 수 있는 계획을 제안했다. 이 과정에서 브룩스의 법칙(늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다)을 피하기 위해 최선을 다했다.

그러나 이 시점에서 상황이 다소 복잡해지기 시작했다. 고위 경영진은 두 플랫폼으로의 마이그레이션에 3년이 걸린다는 개념에 충격을 받았다. 개발팀이 ‘일을 미루고 있’거나 ‘하기 싫어서 과장하고 있다’는 태도를 보였다. 그래서 두 플랫폼 모두를 6개월 안에 완료하라는 기한을 설정했다.

증폭되는 오해와 갈등

6개월 안에 두 개 플랫폼 전환을 수행하는 일은 도전 수준을 넘어서 말도 안 되는 일이었다. 그 시간 안에 하나의 플랫폼을 겨우 구동되는 미완성 버전으로 만들기도 어려웠다. 전혀 불가능한 일이었다.

필자는 이 요청에 극도로 불만이었다고만 말하겠다. 완전히 터무니없는 요구였다. 개발팀은 실패가 뻔한 과업을 위해 밤낮없이 주말까지 일하라는 요청을 받은 셈이었다. 우리가 마치 반항적이고 비협조적인 사람들인 양 취급받는 미묘한 뉘앙스는 도저히 참기 어려웠다.

그래서 입장을 분명히 밝히기 시작했다. 최대한 침착하게 대응하려고 했지만, 짜증이 묻어났을 것은 분명하다. 나는 팀이 ‘무의미한 죽음의 행진’에 휘말리는 것을 막기 위해 필사적으로 싸웠다. 해군 복무 시절, 팀을 돌보는 것이 나의 최우선 임무라는 것을 배웠기 때문이다.

하지만 필자의 항의는 별다른 공감을 얻지 못했다. 같은 이전 회사 출신이었던 필자의 직속 상사는 이 요청이 무리한 것임을 분명히 알고 있었지만, “어려운 일이긴 해도 해보는 수밖에 없다”고 말했다.

이것이 바로 몰락의 씨앗이었다. 필자는 이 과업이 불가능하다는 것을 알았고, “노력해보자”는 접근은 실패할 것이라는 것도 알고 있었다. 그러면, 명백히 실패할 것을 알면서 팀에게 그 일을 하라고 어떻게 지시할 수 있을까? 나는 그 질문에 매우 잘못된 방식으로 답했다.

관리자가 했어야 했던 일

필자는 완전히 잘못된 행동을 했다. 팀을 지키고 사람들을 보호하려는 마음에, 적어도 프로젝트에 동참하는 ‘척’이라도 하는 것을 포기했다. 조직의 일원이라는 태도조차 취하지 않았다. 개발자들에게 이 계획은 말도 안 된다며 아예 시도조차 하지 말라고 말했다. 경영진에게는 계속해서 이 계획은 터무니없고 팀이 절대 수행할 수 없다고 주장했다.

필자가 했어야 할 일은 무엇이었을까? 가장 어려운 부분이다. 필자는 매우 힘든 상황 속에서도 최선을 다했어야 했다. 양쪽을 모두 지지할 수 있는 중간 지점을 찾았어야 했다. 비현실적인 계획임을 알면서도 경영진을 지지하고, 동시에 불가능한 과업에 직면한 팀도 지지할 수 있는 방식을 모색했어야 했다. 그게 어려웠을까? 물론이다. 하지만 적어도 시도는 했어야 했다.

결국 미숙한 접근 방식은 해고로 이어졌다. 그 프로젝트가 터무니없는 일정 안에 완료되지 않을 거라고 내가 옳았는가? 맞다. 그러나 이 문제를 그렇게 강하게 밀어붙이다가 직장을 잃은 것이 옳았는가? 절대 아니었다.

이 이야기의 교훈은 무엇일까? 관리자의 일은 때로 매우 어렵고, 심지어 불가능할 때도 있다는 것이다. 때로는 옳음을 내려놓고 조직 전체의 필요를 나 자신보다 앞세워야 한다. 때로는 팀을 보호하는 것과 동시에 경영진의 일원으로 충실히 행동해야 한다. 위로도 관리하고 아래로도 관리할 줄 알아야 한다.

옳기만 해서는 충분하지 않다. 효과적인 것이 더 중요하다. 필자는 그 사실을 뼈저리게 배웠다.
dl-itworldkorea@foundryco.com