지난 주엔 몇몇 지인들과 맥주를 하면서 그 동안의 스트레스를 풀었죠. 이번에는 술자리에서 나눈 얘길 바탕으로 예전 부터 하고 싶었던 얘길 풀어놓을까 합니다.
Will은 S/W 펌웨어를 개발하는 부서에서 일하고 있습니다.
제품의 특성상 소비자의 불만이나 요구 사항이 즉각적으로 회사 게시판이나 인터넷에 올라오게 되고, 필요에 따라서는 이러한 요구 사항을 급히 반영해서 새 펌웨어를 내놓기도 합니다.
문제는 여기서 시작합니다.
문제는 여기서 시작합니다.
업체간 경쟁이 치열해지다 보니 (이 바닥이 대부분 그렇듯이) 제품 출시는 항상 시간에 쫓기게 되고, 펌웨어는 항상 미완성인체로 출시되는게 다반사입니다.
거기 까진 괜찮습니다. S/W는 언제라도 업데이트를 내면 되고, 이런 저런 이유로 인해 약간의 버그는 항상 존재합니다.
거기 까진 괜찮습니다. S/W는 언제라도 업데이트를 내면 되고, 이런 저런 이유로 인해 약간의 버그는 항상 존재합니다.
하지만, 처음부터 제품 기획없이, 그리고 아무 계획없이 개발을 시작하다 보니 어느 순간 내일 무슨 일을 할 지 모르는 사태가 발생합니다.
업무는 보통 그때 그때 발생하는 이슈를 처리하는 식으로 진행되고, 결국 장기적으로 뭘 할 수 있는 여유가 전혀없어지게 되는 무계획의 악순환이 되어 버립니다.
얼핏 생각해보면 중요한 문제가 터지고, 바로 처리해야할 만큼 우선순위가 높다면 그것부터 처리하는게 맞는 것 같기도 합니다만, 애초부터 무계획 속에서 시작된 일이다보니 이러한 일이 얼마나 더 발생할 지 전혀 감을 잡을 수가 없지요.
이상적인 경우라면,
- 제품 기획부터 철저하게 계획한다. 무엇을 만들어 누구를 타겟으로 할지, 어떤 기능을 포함할지, 회사 구성원 모두(또는 다수)가 공감할 수 있는 계획을 세운다.
- 설계 단계부터 요구사항과 개발의 범위를 대략적으로라도 세우고 이를 문서화한다. 즉 왜 이런 기능을 포함하는지에 대한 근거를 남겨둔다. 물론 일하다 보면 변경될 수 있다. 그때그때 계획이 변경되면 이에따른 시간 계획도 새로 세워야 한다.
- 구현을 시작하면서 집중할 수 있도록 가능한 외부 인터럽트는 줄인다. 또는 최소화하면서 중간중간 정해진 마일스톤을 찍을 수 있도록 한다.
- 이 후 구현을 거쳐 출시전에 철저한 테스트가 선행되어야 한다.
- 출시되고 나면 주기적인 S/W 업데이트로 발생하는 버그를 해결해 나간다.
위에서 말한 내용들은 전혀 새로운 것이 아닙니다. 마구잡이식 개발로 좀 더 빨리 가시적인 성과를 낼수는 있을지 몰라도, 결국 지금처럼 터지는 문제를 해결하는데 훨씬 더 많은 시간을 소모하게 되는걸 왜 모르는지...
