효율이라는 이기심

효율적이라고 추구하는 개발자의 비효율

"이건 비효율적인데요"

개발자들과 대화를 나누다 보면 종종 듣게 되는 말이다. 효율과 비효율을 따질 때면 그 논리는 아주 설득력 있게 들리고, "비효율적"이라는 말 한마디에 해당 작업이 불필요한 것처럼 느껴지기도 한다. 효율적으로 일해야 한다는 신념이 강해지는 순간이다.

하지만 우리는 무엇이 진정으로 비효율적인 것인지, 그리고 비효율적인 일은 반드시 피해야만 하는지 고민해 볼 필요가 있다.

기획과 개발의 병목 문제

프로젝트가 시작되었지만 기획서가 아직 완성되지 않은 상황을 생각해 보자. 많은 개발자가 이런 환경을 좋아하지 않을 것이다. 왜냐하면 명확한 요구사항이 정의되지 않으면, 일의 범위를 예측하기 어렵기 때문이다.

예를 들어, 우리가 개발해야 할 스펙이 10개라고 가정해 보자. 만약 완성된 기획서가 있다면 우리는 정확히 무엇을 해야 하는지 알고 시작할 수 있다.. 이렇게 되면 개발 일정과 필요한 자원을 예측할 수 있고, 업무를 효율적으로 진행할 수 있다.

하지만 프로젝트를 진행하다 보면 기획 작업이 병목이 되는 경우가 종종 발생한다. 극단적인 예로, 개발자는 10명인데 기획자는 2명뿐이라면 어떨까요? 만약 기획서 하나를 작성하는 데 1달이 걸린다면, 마지막 기획서가 완성되는 데만 2.5개월이 걸립니다. 이때까지 개발자들은 기다려야만 할까?

비효율적인 일의 선택과 가치

여기서 질문이 해보자. 기획이 모두 준비되기까지 기다리는 것이 정말 효율적일까요? 개발자들이 비효율적이라도 먼저 일을 시작하는 것이 전체 일정에 미치는 영향은 어떨까?

예를 들어, 기획이 늦어져도 개발을 미리 시작한다면 첫 기획서가 나온 시점부터 개발된 코드가 일부 준비되어 있을 수 있다. 물론, 이 과정에서 일부 코드는 수정되거나 폐기될 수도 있지만, 미리 작업한 덕분에 전체 일정을 조금이라도 단축할 수 있다면 그것도 가치 있는 비효율 아닐까?

계산 예시:
기획서가 2.5개월 뒤에 완성된다고 할 때, 개발자들이 미리 작업을 시작해 일부 완성도를 높인다면, 최종 개발 일정은 0.1개월이라도 단축될 수 있습니다. 비록 리소스는 더 들었지만, 그로 인해 전체 일정이 줄어든다면 그 또한 프로젝트의 성공에 기여할 수 있다.

개인의 효율 vs. 전체의 효율

모든 개발자는 효율적으로 일하고 싶어 한다. 이는 당연한 욕구이다. 그러나 프로젝트의 성공을 위해 때로는 비효율적인 일도 감수해야 하는 상황이 생긴다. 개인의 효율이 우선이 아니라, 팀과 프로젝트의 전체 효율이 더 중요할 때가 있다.

만약 프로젝트 일정이 촉박하다면, 개인의 효율을 희생하더라도 팀 전체가 함께 움직여야 한다. 반면에 일정에 여유가 있다면 효율성을 극대화하는 것이 더 좋은 선택이 될 수 있다. 중요한 것은 개인과 전체의 효율 사이에서 상황에 맞는 선택을 내리는 것이다.

비효율 속에서도 배울 수 있는 가치

비효율적으로 보이는 일도 때로는 새로운 기회를 제공한다. 미리 작업을 시작하면서 예상치 못한 문제를 발견하거나 새로운 아이디어를 얻을 수 있다. 또한 비효율적인 과정 속에서 팀원 간 협업 방식이 개선되거나 업무의 흐름이 최적화될 수 있다.

예를 들어, "모듈화 적용"이라는 목표를 세운 주니어 개발자가 예상치 못한 반대에 부딪혀 어려움을 겪는 상황을 생각해 보자. 이런 비효율적인 과정 속에서 그는 기술뿐만 아니라 협업과 설득의 중요성도 배우게 된다.

---

효율은 강력한 도구이지만, 언제나 최우선의 가치가 되어서는 안 됩니다. 프로젝트의 성공을 위해서는 개인의 효율과 팀의 효율을 균형 있게 추구해야 한다. 때로는 비효율적인 선택이 더 나은 결과를 가져오기도  다.

개발자는 상황에 따라 비효율을 감수할 용기와 효율을 극대화할 지혜를 동시에 가져야 한다. 중요한 것은 언제 효율을 추구하고, 언제 비효율을 받아들일지에 대한 유연한 사고이다. 이 유연함이야말로 팀과 프로젝트의 성공을 이끄는 열쇠가 될 것이고, 더 나은 개발자로의 성장으로 이어질 것이다.