📚 해커와 화가
p.120
"비아웹은 단 3명이 개발했었다. 우리는 회사가 팔리기 원했는데, 단지 3명으로 이루어진 회사에 많은 비용을 지불할 투자자가 있을 리는 없으므로 나는 계속해서 더 많은 사람을 고용해야 한다는 압박을 느끼고 있었다. (해결책으로 우리는 실제로 더 많은 사람을 고용했는데, 그들이 할 일을 찾기 위해서 새로운 프로젝트에 착수해야 했다.)
적은 수의 프로그래머로 소프트웨어를 개발할 수 있다면, 그것이 절약해주는 것은 돈에 그치지 않는다. 프레드 브룩스 Fed Brooks가 '맨먼스 미신'에서 지적한 것처럼, 프로젝트에 사람을 더 많이 투입하는 것은 오히려 프로젝트의 진행 속도를 둔화시킨다. 개발자 사이에 연결할 수 있는 선의 수는 팀의 크기가 증가함에 따라서 기하급수적으로 늘어난다. 그들이 커질수록 그들은 소프트웨어가 어떻게 작동해야 하는지에 대한 논의에 더 많은 시간을 투입해야 하고, 미처 예상하지 못한 버그가 끊임없이 출현하는 것을 목격하게 된다. 다행스러운 것은, 이러한 경향이 반대 방향으로도 적용된다는 점이다. 그룹의 크기가 작아질수록, 소프트웨어 개발은 효율성이 기하급수적으로 높아진다. 나는 비아웹의 프로그래머가 실질적으로 회의에 참석하는 것을 본 적이 없다. 점심을 먹으러 걸어가는 동안 할 수 있는 이야기보다 더 많은 이야기를 모여서 해야 할 필요가 없었다."
회사에서 개발자를 많이 채용해야 한다는 말을 자주 듣는다.
하지만 뽑아서 무슨 일을 시킬건지 물어보면, 그때부터 생각하기 시작한다.
이건 뭔가 잘못됐다.
예를들어, 영업팀에서 도요타의 하이브리드 모델인 프리우스 한 대로 고객들을 만나고 있었다 하자. 조금씩 조금씩 이것 저것 다 해봤다. 그러다 '아 우리가 고객을 많이 만나면서도 경제적으로 이윤을 추구하려면 한 대로는 도저히 안되겠다' 한 대만 더 늘리자.'
이런 방식의 양적 확장은 필요하다.
하지만, 지금 프리우스 한 대로도 충분한데 좋은 회사들엔 영업용 차가 많더라 라는 얘기를 듣고 따라사는 건 옳지 않다.
절약해보고 최대의 효율을 내보려고 하는 최적화 마인드나 장인정신 사고방식을 보기가 점점 어려워 진다고나 할까.
돈으로 때우면 되지, 사람 더 뽑으면 되지, 더 많은 시간으로 때우면 되지
죄다 이런식이다.
이런 상황에서 점잖게 그러면 안된다고 말하는 내가 이상해지는 상황이다.
