들어가며

피플웨어라는 책에 이런 문장이 나온다. “우리 업무에서 주요 문제는 본질적으로 기술적인 문제가 아니라 사회적인 문제다.” 즉 대다수의 프로젝트 실패는 기술이 아닌 사람 때문에 실패 했다는 것이다. 언뜻 이 명제는 그럴듯해 보인다. 세상에 나온 기술에 문제가 있어서 개발하지 못한 기억은 나 스스로도 전혀 없다.

그러다 문득 프로젝트의 실패 라는 것이 무엇인지 의문이 들었다. 내가 프로젝트의 실패를 겪은 적이 있나? 무엇이 프로젝트의 실패인가. 나는 항상 문제 투성이의 프로젝트를 해왔다고 막연히 생각했는데, 공식적으로 실패한 기억이 없었다.

실패한 프로젝트가 없다

내가 일해오면서 대외적으로 ‘우리 프로젝트는 실패 했습니다’ 라고 프로젝트의 리더나 관리자들이 이야기 한 적은 단 한번도 없었다. SI를 할 때는 적기에 납품을 하면 성공이라고 했고, 운영 프로젝트는 연말이 되면 올해도 다들 고생했다 정도로 마무리가 되곤 했다.

그러나 나의 인식 속에 수많은 프로젝트의 상태는 대부분 병들어 있었다. 간헐적으로 CPU 점유율 폭발 현상이 지속되는데 10년, 20년 경력의 개발자들도 이유를 모르고 껐다 켜기로 수습하기에 바쁘다던지, 워크플로우나 업무의 책임 주체 및 명확성이 없고 업무 분배 문제까지 더해져 줄퇴사가 이어지는 프로젝트도 있었다. 어찌되었던 남은 개발자들이 남은 문제를 수습하고 기한을 지켜냈지만 나에게는 기한은 성공의 기준이 될 수는 없었던 것 같다.

물론 회사 간의 계약이 달린 프로젝트 이거나 사내의 인사 고과나 승진 문제로 인해 프로젝트의 실패를 선언하는 것은 무척이나 어렵다. 더군다나 실패라는 단어가 주는 뉘앙스 떄문에 이 단어를 감정적으로 받아들이는 것도 전혀 이상하지 않다.

성공으로 포장하는 것의 문제

보다 집중해보고 싶은 것은, ‘실패로 느껴지는 프로젝트를 성공했다고 이야기 하는 것에 무슨 문제가 있는가’ 이다. 내가 생각하기에는 성공으로 포장된 경험은 문제 삼지 않는 것이 가장 큰 문제인 것 같다. 어쨌든 결과가 성공이니까 과정에서의 잡음은 성공으로 향해 가는 길의 난관 정도로 여겨지고, 이를 이겨낸 서사만이 윤색되어 남는다. 그 결과 프로젝트가 치른 비용은 개인의 고생이나 일시적인 잡음으로 축소된다.

만약 실패로 규정했다면, 무엇 때문에 실패했고 다시 반복하지 않기 위해서 어때야 하는가를 물었을 것이다. 나아가 ‘무엇’에 실패 했는지를 정하게 되는 것 또한 같이 정해진다. 앞서 언급했던 ‘기한 내 납품한 SI 프로젝트’가 ‘프로젝트 인원의 줄퇴사’라는 이유로 실패했다고 이야기 한다면, 프로젝트의 납기 뿐 아니라 참여하는 인원의 상태를 면밀히 살피고, 사기를 살피고, 프로젝트의 방향성과 업무 로드를 구성원이 잘 따라오는 것 또한 성공의 요건이 되는 것이다.

그렇게 되면 이어, 납기 내에 3명이서 할 일을 1명이서 끝냈다는 것이 영웅담이 아닌 실패담으로 읽히고, 그 문제를 반복하지 않을 수 있는 방법을 고민하게 된다. 결국 실패라고 부르는 것 자체가 중요한 것이 아니라, 과거를 통해 무엇을 배우고 개선하고 반복하지 않을 것인지를 배우는 것이 중요한 것이라 하겠다. (실패라고 하는 것이 싫다면 ‘더 잘할 수 있었던 것은 무엇일지 생각해보자’는 식으로 접근할 수 있다.)

빠질 수 있는 함정

그렇다고 실패를 반추하는 작업이 늘 정답을 보장하지는 않는다. 자칫하면 또 다른 함정에 빠지기 쉽다.

특히 과거 문제의 스냅샷을 해결책 자체로 오해하면 안된다. 예를들어 사람들이 관리자에게 불만을 이야기 할 창구가 없어서 퇴사로 이어졌다는 분석이 있었다고 해보자. 그리고 다음에는 ‘사람들은 불만을 이야기 하기 편하게 1:1 미팅을 해볼 수 있을 것 같다’고 정리를 했다. 문제는 이걸 다음에 곧이 곧대로 ‘1:1 미팅을 반드시 진행하고, 이걸 했다는 기록을 남길 것’으로 문제를 해결하려 하면 안된다는 것이다.

보다 메타적으로 ‘커뮤니케이션의 문제’ 자체를 바라봐야 함을 인지하고, 프로젝트 구성원이 받아들일 수 있는 작은 단계로 시작을 해보는 것이 더 맞는 방향일 것이다. 커피 마시러 가는 10분 새에 비공식적으로 일이 어떤지 물어볼 수도 있고, 몇 명을 그룹으로 만나도 된다. 중요한 건 소통 자체의 문제를 해결하는 것이니까.

마치며

요새 박소령님의 『실패를 통과하는 일』과 한기용 님의 『실패는 나침반이다』 라는 책을 읽고 있다. 이런 이유로 아마 나의 실패 라는 것에 생각이 미친 것도 같다. 특히 퍼블리의 시작과 끝을 한 편의 영화같이 보여주는 것 같은 『실패를 통과하는 일』을 보며 나도 이 정도의 자기 성찰은 있어야 하지 않을까 싶었다. 그러나 막상 나 스스로 어떤 시간을 뼈저린 실패로 규정하고, 되풀이 하지 않겠다고 깊게 고민해 본 적은 많지 않은 것 같다.

실패라고 부르는 것은 가장 속이기 쉬운 자기 자신으로부터 솔직해야 하기 때문에 어렵다. ‘무엇을 배웠는가’를 묻는 것은 실패의 낙인 보다는 쉬울 수 있다. 개발자로 일하며 마주한 무수한 사고들 덕에 분명 몸이 기억하는 되풀이하지 말아야 할 실수들이 있다. 다만 이 기회에 어정쩡한 성공 속에 감춰진 배움을 좀 더 찾아보아야 겠다.