한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.
한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다.
개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.
코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다.
하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.
고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.
개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다. 필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다.
회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다.
그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다.
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다.
기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다.
원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다.
대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다.
실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다.
대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다.
소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.
이 글은 ZDNet Korea에 기고한 칼럼입니다.
