이번 설날에 지금까지 진행하였던 프로젝트를 정리하면서 기술부채에 대한 생각이 들었다.
현직 또는 예비 개발자라면 한번 정도는 들어 보았을 기술 부채에 대해 간단하게 설명하자면,
기술적으로 해결되어야 할 문제들을 뒤로 미루고, 비즈니스 문제를 해결하는 시점을 당기는 행위
8퍼센트 CTO이신 이호성님의 글에서 가져온 말이다. 무슨 말인지 대부분 쉽게 짐작을 하실 수 있을 것이다.
나도 아직 신입 개발자이긴 하지만 지금까지 다녔던 회사에서는 이러한 느낌을 너무 자주 느낄수 있었다.
프로젝트를 진행하려고 하면 갑자기 다른 프로젝트에 헬프를 주러 가야하고, 서류를 작성하려고 하면 심부름 같은 잡무가 들어와서 흐름이 방해되고....
약 1년간 생산성 있게 진행해 본 경험은 별로 없었던 것 같다.
지금와서 이야기 하는 것이지만 내가 진행 한 프로젝트는 그나마 팀원들 끼리 단위 테스트는 물론 일부러 에러도 내보고 예외 상황이나 기능적 문제에 대해 많은 커뮤니케이션을 통해 큰 문제는 없도록 진행되었지만, 회사 내부 다른 프로젝트의 경우에는 문서도 작성이 안되어 있는 경우, 테스팅의 부재, 협업의 부재 등으로 인해 프로젝트 막바지에 와서 밤을 새는 경우를 자주 보았던 거 같다.
위 상황을 요악하자면 개발단계에서 제대로 개발을 하지 않으면 그 부분이 빚이 되는데 이게 그 당시에 조금 힘이 들어도 해결하면 문제가 없지만 나중에 해결하려고 보면 그 부분의 빚이 이자가 붙어서 더 많은 노력과 힘이 들어간다는 것을 알 수 있다.
사실 회사 사정에서 보면 이해는 가는 이야기이긴 하다. 대표입장에서는 개발 시간을 최대한 줄여서 소프트웨어나 프로젝트를 완료하는 것이 생산성이 되기 때문에 어떤 의미로 보면 눈 앞의 보이는 기간이 중요하다. 그렇기에 큰 문제가 없다면 얼렁뚱땅 만들어서 내 보내는 것이 회사 이익에 도움을 준다고 생각하는 사람들이 좀 있는거 같다.
하지만 프로젝트를 한번 하고 끝낸다면 백번 천번 양보해서 그렇다 치지만!! 그게 아니라 대부분의 사업(프로젝트)은 고도화도 진행을 할 것이고, 유지보수 또는 하자보수를 진행 할 것인데, 그것을 개발한 인력이 꼭 투입된다는 보장은 없다.
다행히 그 프로젝트를 진행했던 개발자라면 그나마 진행하겠지만, 처음 들어가는 사람이나 신입 개발자의 경우에는 그렇지가 않을 것이다. 그들은 서류 또는 코드에 남겨져 있는 내용을 기반으로 프로젝트를 진행 할 것인데, 만약 그 내용이 없거나 문제가 있다면 그 프로젝트를 이해하고 문제를 해결하고 기능을 개선하는데 더 많은 시간을 투자해야 할 것이다. 이는 곧 생산성으로 이어지고 생산성이 저하되면 그만큼 회사 이익에는 빨간불이 켜진다고 생각한다.
나 또한 이번에 프로젝트를 정리하면서 얼마나 내가 생산성 있게 진행했는지 복기하는 시간이 되어 정말 좋았던 거 같고, 비록 1년을 못 채우고 퇴사를 결심하게 되었지만 왜 내가 퇴사를 결심했는지에 대한 마음을 다시 잡을 수 있게 되어 좋은 시간이었다고 생각한다.
이번년도에는 나 또한 부족한 부분을 많이 메꾸고 더 배워서 생산성 있는 개발자가 되었으면 하는 바램이고 그렇게 되도록 더 노력할 것이다.