• 

• ★★★☆☆ 2026-03-07~08 1장의 글로벌 대기업(MS, 아마존 등)의 성공 사례는 좀 뻔한 감이 있어 조금은 지루했다(최근 대량 해고까지 겹쳐서 더 그런 생각이 든다). 그러나 그 뒤에 이어지는 각 장은 내용의 수준은 각자 다르게 받아들일 수 있어도, 최소한 직접 해보고 부딪혀서 성과를 만들었다는 생각은 충분히 할 수 있을만큼 충실히 작성했다고 생각한다. 이 책에서 가장 중요한 부분은 여기 같이 올려둔 세 페이지에서 드러난다고 본다. 도구도 중요하지만 더 중요한 건 문화고, 도구 이전에 사람이 받아들여야 하며, 반복적인 성공의 경험을 해야 한다는 점이다.

• 
• 
• 

과거 일했던 회사 중 한 군데는 비즈니스 부서와 개발 부서간의 업무 협조가 매우 어려웠다. 비즈니스 부서는 개인별로 서로 다르게 업무 협조 요청을 했고(대면, 전화, 슬랙, 이메일 등), 개발자는 서로 다른 비즈니스 부서원의 서로 다른 방식의 업무 협조 요청만으로도 버거운데다가 각 업무의 중요도를 알 수 없어(업무 요청을 하는 사람은 대개 자신의 업무가 가장 중요하게 마련이다), 일을 효율적으로 하기 어려웠으며 열심히 일을 해도 좋은 소리를 못 듣는 경우도 허다했다. 개발 부서를 담당했던 나는 업무 협조 요청 방식과 거기서 발생하는 어려움을 듣고 이슈 트래커 도입이 필요하다고 생각했다. 업무 중요도를 비즈니스 부서에서 결정해서 통일된 방식으로 전달하면, 개발자는 하나의 경로로 중요도에 따라 정렬된 요청 사항을 처리하면 효율적으로 일을 처리하면서 업무 외의 쓸데없는 부담을 줄이고, 비즈니스 부서도 더 중요한 업무가 먼저 처리될 것이란 순진한 생각을 했다.

이 방식을 도입하는 건 생각보다 훨씬 어려웠다. 가장 먼저 돌아온 반응은 ‘우리가 왜?’였다. 자신들이 편한 방식으로 요청하고 기다리면 된다고 생각한 비즈니스 부서에서는 변화를 거부했다. 이 방식을 적용하면 대략 언제 업무가 처리될지, 중요한 업무를 먼저 확인하고 진행한다는 걸 모두가 한 눈에 볼 수 있다는 장점은 그들에게 바로 먹히는 설득이 아니었다. 무엇보다 최고 의사결정권자가 필요성을 공감하지 않으면서, 수직적인 문화가 강한 비즈니스 부서에서는 움직일 생각을 하지 않았다. 그러면서도 당연하다는 듯이 일처리가 느리니 좀 더 빠르게 처리할 수 있는 방법을 생각해달라고 했다. 알아서, 개발 부서에서 자체적으로.

다른 더 좋은 방법이 있으면 생각해서 알려달라고 했다. 몇 가지 이야기를 하는 사람들도 있었다. 그러나 그 방식들은 대부분 누군가에게 의존하는, 비즈니스 부서건 개발 부서건 전담 인원이 필요한 방법이었다. 구조적으로 특정 인원에게 부담이 가서 시간이 지나면 결국 부담을 느끼는 사람이 스트레스를 받고 다른 업무로 전환을 요청하거나 퇴사를 하게 될 방법이었다. 1년에 걸쳐 설득도 하고 말다툼도 하며, 이게 이렇게 어려울 일인가? 하는 생각과 함께 드디어 도입을 관철시켰다. 개발 부서의 만족도는 당연히 올라갈 거라고 생각했고, 비즈니스 부서의 만족도도 예상보다 더 높았다.

AI 도구 도입과 함께 생산성이 실제로 증가했는지 연구/조사 결과를 보면 각 주체마다 정도는 다르지만 생산성이 향상되었다고 답한 경우가 훨씬 적다. 각론으로 들어가면 모두 다를 수 있지만 총론에서 보면 비슷할 거라고 예상한다. 도구를 무작정 던져주고, 바로 큰 성공을 바라는 경우는 아마 99% 실패. 이 책은 그렇게 하지 말라고 설득하고 보여준다. 도구는 중요하다. 똑같이 운전할 줄 알면 더 성능좋은 엔진의 차를 운전해야 더 빨리 간다. 하지만 더 중요한 건 문화다. 이걸 아는 사람이 실행해야 성공할 가능성이 높아진다.