개발자의 실수... 대부분, 누적된 선택의 이자!

대부분 기술적 부채에 대한 이자.

비즈니스 프로세스가 빠르게 움직이면서 DevOps는 너무도 당연하고, 만들어진 서비스가 빠르게 배포되면서 서비스 품질의 이슈나 버그, 사소한 실수들이 중첩되면서 발생되는 일을 빈번하게 만나게 되는 것이 현재의 개발방식이다.

대부분 긴급하게 코딩하면서 제대로 된 주석을 달아두지 못하거나, 급한 일정이 지나간 이후에 리팩터링이나 코드 수정을 하지 못한 내용들이 대부분 기술적 부채로 남게 된다.

이러한 기술적 부채들은 꼼꼼하고 앞뒤를 잘 따지는 개발자들로 하여금, 자괴감이 들 수 있는 실수를 일으키거나 문제 발생 이후에 자신의 실수를 빠르게 인지하게 한다.

아이러니하지만, 이러한 기술적 부채의 대부분의 책임은 개발 관리자나 개발 프로세스의 문제들이지, 개발자들의 책임은 아니다.

소프트웨어의 품질은 기본 규칙을 지키면서 구축되는 것이고, 그 어느 것 하나라도 생략되면 분명, 기술적 부채로써 언젠가의 사고나 업무의 속도를 저하시키는 환경으로 분명 돌아온다.

이러한 재앙을 빠르게 반응하고 문제 해결이 효과적으로 되려면, 개발자와 각 비즈니스 부서의 담당자들 간의 신뢰가 풍부하게 존재한다면, 이 반응은 빠른 해프닝으로 끝날 수 있지만, 서로 신뢰하지 못하는 상황에서는 가혹한 분노와 비난 등이 난무할 수 있다.

.

.

.

개발자들의 실수는 대부분 프로세스의 문제들이며, 그 실수의 대부분은 긴급하게 일을 떨군 대표나 기술 책임자의 책임이다. 그것을 인지하고, 책임지는 자세로 개발자들을 독려하고, 관련 유관 부서들의 부서원들에게 개발자의 신뢰를 잃지 않게 하는 것이 핵심이다.

서비스는 비 온 뒤에 더 단단하게 굳어지는 것처럼, 실수를 해결하고, 문제를 넘어서는 것으로 더 의미 있는 서비스로 변해갈 것이다.

개발자의 실수...

한발 뒤로 물러서서, 근본적인 원인을 찾으면 됩니다.

대부분, 관리자나 대표의 잘못된 선택인 경우라는 것을 잊지 마시기를...