누구나 실수를 한다.
더 나아가 누구나 버그를 만든다.
구글도, MS도, 애플도 넷플릭스도 아마존도 버그를 만든다.
버그 없는 소프트웨어는 존재하지 않는다.
사용자 입장으로 가정하면, 정말로 버그 없는 소프트웨어는 존재 할 수 없다.
조금은 억울한 이야기는 하드웨어 오류로 인한 버그마저 소프트웨어에 대한 불신으로 이어질 수 있고, 사용자에겐 그것은 어떤 티어의 문제였건 간에 버그다. 불편한 사용성, 하드웨어 fault로 인한 오류, 네트워크 응답 속도로 인한 오류마저 버그로 간주 될 수 있기 때문이다.
위 상황마저, 개발자가 커버해야 된다는 얘기냐고? 오히려 그 반대에 가깝다.
소프트웨어 기업이라면 개발자의 실수가 어떻게 받아들여 지느냐에 따라 그 기업의 성장력에 차이를 낸다.
과감해야 할 때와 그렇지 않아야 할 때, 많은 코스트를 들여서라도 새로운 시도를 해야 할 때, 보수적으로 접근해야 할 때를 엄격히 구분하고, 그에 대한 판단과 책임은 회사가 져야 한다.
개인이 지나치게 부족한 역량과, 지나친 월권으로 안정성을 해치고 있는 케이스는 물론 개인의 책임이다. 이 사람이 변화에 적절한 상태인지, 얼마나 합리적인 결론을 낼 수 있는지에 대한 판단은 회사의 몫이다.
대다수의 과감한 시도로 인한 리스크마저 개인이 떠안아야 한다면, 어느 누구 과감한 선택과 도전을 하려 할까?
새로운 시도, 노력없이 성장 할 수 있는 소프트웨어는 없다. 심지어 보수적인 선택으로 기존 기술을 선택한다 하더라도, 안정성은 보장 할 수 없다.
심지어 코드 한 줄 작성 안하고 운용하는 소프트웨어라 할지라도, 그에 대한 대처가 되어있지 않은 환경에선 사고가 날 가능성은 존재한다. 심지어 그 확률마저 꽤나 높다. 변화를 기피하는 보수적인 선택이 안정성에 대한 해결책이라 여기는 분들 입장에선 슬픈 이야기겠지만 말이다.
결국엔 얼마나 변화와 안정성, 디테일간의 밸런스를 맞출 수 있느냐에 문제다.
그 과정에서 한번에 완벽하게 변화할 순 없기에 그 과정을 두려워하지 않게 만들어주어야 한다.
두려움을 느낀다면, 마지못한 도전을 할 것이고, 가능한한 보수적인 접근으로 적은 실수를 혹은 실수를 하지 않게끔 행동 할 것이다.
당연하게도 그 과정에서 얻는 경험과 통찰 등 실수로 인해 얻을 수 있는 소득은 줄어들 것이다.
실패로, 실수로 인해 배우는 것은 너무나도 크다.
실패를 적게 한 사람은 실패로부터 배우는 방법마저 모른다.
그 방법을 알 수 있게, 더 많은 걸 실패로 부터 배울 수 있게 지원해야 하며, 과감함 속에서 성장하고, 그 성장을 밑바탕으로 삼을 수 있는 고민과 문화를 만들어야 한다.
발전하고 싶다면 말이다.