[삽질] 이렇게 일하니 항상 삽질할 수 밖에...

지난 주엔 몇몇 지인들과 맥주를 하면서 그 동안의 스트레스를 풀었죠. 이번에는 술자리에서 나눈 얘길 바탕으로 예전 부터 하고 싶었던 얘길 풀어놓을까 합니다.

Will은 S/W 펌웨어를 개발하는 부서에서 일하고 있습니다.

제품의 특성상 소비자의 불만이나 요구 사항이 즉각적으로 회사 게시판이나 인터넷에 올라오게 되고, 필요에 따라서는 이러한 요구 사항을 급히 반영해서 새 펌웨어를 내놓기도 합니다.

문제는 여기서 시작합니다.

업체간 경쟁이 치열해지다 보니 (이 바닥이 대부분 그렇듯이) 제품 출시는 항상 시간에 쫓기게 되고, 펌웨어는 항상 미완성인체로 출시되는게 다반사입니다.

거기 까진 괜찮습니다. S/W는 언제라도 업데이트를 내면 되고, 이런 저런 이유로 인해 약간의 버그는 항상 존재합니다.

하지만, 처음부터 제품 기획없이, 그리고 아무 계획없이 개발을 시작하다 보니 어느 순간 내일 무슨 일을 할 지 모르는 사태가 발생합니다.

업무는 보통 그때 그때 발생하는 이슈를 처리하는 식으로 진행되고, 결국 장기적으로 뭘 할 수 있는 여유가 전혀없어지게 되는 무계획의 악순환이 되어 버립니다.

얼핏 생각해보면 중요한 문제가 터지고, 바로 처리해야할 만큼 우선순위가 높다면 그것부터 처리하는게 맞는 것 같기도 합니다만, 애초부터 무계획 속에서 시작된 일이다보니 이러한 일이 얼마나 더 발생할 지 전혀 감을 잡을 수가 없지요.

이상적인 경우라면,

1. 제품 기획부터 철저하게 계획한다. 무엇을 만들어 누구를 타겟으로 할지, 어떤 기능을 포함할지, 회사 구성원 모두(또는 다수)가 공감할 수 있는 계획을 세운다.
2. 설계 단계부터 요구사항과 개발의 범위를 대략적으로라도 세우고 이를 문서화한다. 즉 왜 이런 기능을 포함하는지에 대한 근거를 남겨둔다. 물론 일하다 보면 변경될 수 있다. 그때그때 계획이 변경되면 이에따른 시간 계획도 새로 세워야 한다.
3. 구현을 시작하면서 집중할 수 있도록 가능한 외부 인터럽트는 줄인다. 또는 최소화하면서 중간중간 정해진 마일스톤을 찍을 수 있도록 한다.
4. 이 후 구현을 거쳐 출시전에 철저한 테스트가 선행되어야 한다.
5. 출시되고 나면 주기적인 S/W 업데이트로 발생하는 버그를 해결해 나간다.
   

위에서 말한 내용들은 전혀 새로운 것이 아닙니다. 마구잡이식 개발로 좀 더 빨리 가시적인 성과를 낼수는 있을지 몰라도, 결국 지금처럼 터지는 문제를 해결하는데 훨씬 더 많은 시간을 소모하게 되는걸 왜 모르는지...