글을 시작하며
이 글을 쓰게 된 이유는 다음과 같습니다
모든 개발자들은 학습에 목마른 사람 그리고 새로운 기술을 배우고 싶고
또한 그것을 사용하고 싶은 사람 임을 가정하고 이 글을 시작해 보고자 합니다.
이글은 저의 개인적인 의견이 담긴 글이며 혹시나 틀린점이 있다면 언제든지 지적 해주시면 감사하겠습니다.
개발자는 왜 새로운 기술을 사랑할까?
개발자들은 왜 항상 새로운 기술에 목말라하고 왜 항상 새로운 기술을 써보고 싶어 할까요?
저의 주관적인 생각으로는 개발자들은 학습에 목마르고 새로운 기술을 써보고 싶어 하는 성향을 가졌다고 생각합니다.
저 또한 그렇습니다.
그렇다면 개발은 무엇일까요?
개발이란?
"소프트웨어 개발의 목표는 효율적이고 반복 가능하며 안전한 방식으로 사용자 요구와 비즈니스 목표를 충족하는 제품"
정의 내에서 제가 한 생각은 개발에서 가장 중요한 것은 도덕적인 범주 내에서 안전하게 작동한다.
그리고 사용자의 요구 그리고 비즈니스의 목표에 충족하는 것이라고 생각합니다.
사용자의 요구 그리고 비즈니스의 목표 두 가지의 목표로 분리하고 아래의 글을 쓰며 두 가지에 대해서 이야기하겠습니다.
실제로 있었던 사례 하나
일례로 싸피에서 약 6주간 간단한 프로젝트를 진행해 본 적이 있었습니다.
같은 팀원 분께서 코드를 계속 고치시는데 상당히 오랜 시간이 소요되어서 여쭤본 적이 있었습니다.
그도 그럴 것이 test 코드도 문제가 없고 빌드도 문제가 없어서 아무 문제가 없는데 왜 그러신지 여쭤보았습니다.
deprecated된 함수여서 바꾸어야 한다고 이야기를 하셨었습니다.
실제로 저희 프로젝트에 떴었던 이미지 입니다
deprecated란 기대하는데로 작동은 할 수 있으나 곧 사라질 예정인 코드를 의미 하는데요.
바꾸시는 이유에 대해서 조금더 대화를 해보았습니다.
기술 부채를 이유로 꼽으시며 코드를 고쳐야한다고 이야기 하셨습니다.
그것이 이글을 쓰게 하는데 시작점이 되었습니다.
기술 부채란?
본격적으로 이야기 하기전에 기술 부채에 대해서 설명하겠습니다.
소프트웨어 개발에서 장기적인 고품질 솔루션 대신, 당장의 빠른 납기나 쉬운 구현을 위해 단기적이고 제한적인 임시 방편을 선택함으로써 향후 추가적인 재작업 비용과 위험을 부담하게 되는 현상을 의미 합니다. 1992년 와드 커닝햄이 처음 사용한 비유로, 당장의 빠른 개발이라는 '대출'을 통해 나중에 '이자'를 포함한 더 많은 수정 작업을 해야 하는 상황을 말합니다.
"한컴 테크 발췌"
이처럼 기술 부채란 재작업 비용과 위험을 부담하게 되기 때문에 사실 장기적으로 보면 좋은 개발 방법은 아닙니다.
하지만 이러한 기술 부채가 꼭 나쁘기만 한것 일까요?
잠시 deprecated된 함수 이야기를 계속 하겠습니다.
곧 사라질 코드이기에 사용하는건 올바르지 않다고 여길 수 있으나
이것을 고치기 위해서는 두가지가 필요합니다.
첫 번째는 그 코드를 고치기 위해서 학습을 해야 하는 학습 비용
두 번째는 그 코드를 고치기 위해서 개선하는 데 시간을 써야 하는 개선 비용
개선에는 그 코드를 고치는 것뿐만 아니라 그 코드를 고쳐서 발생하는 side effect까지 고려해야 합니다.
상황을 정리해 보겠습니다.
여기서 저희 팀원 분께서는 나중에 이 코드가 작동하지 않았을 때의 기술 부채를 걱정하신 것이고
저의 의견 속에는 학습 비용 및 개선 비용 이 기술들을 사용하기 위해서 팀 혹은 개인이 사용해야 하는 시간을 이야기한 것입니다.
아까 가장 처음에 이야기드린 것처럼 프로그램에서 가장 중요한 것은 안전하게 반복 작업을 하는 것
이는 당장 써야 할 코드에 기술 부채에 비해서 팀은 학습 비용 그리고 개선 비용까지 지불한 것입니다.
6주 내의 프로젝트 내에서 기술 부채를 가지고 개발을 할지?
혹은 학습 비용이나 개선비용까지 지불을 할지는 프로젝트의 목적에 따라 달라질 수 있습니다.
하지만 6주 내 동안 진행하는 프로젝트의 목적은 무엇일까요?
프로젝트 시작 전 많은 개발자들은 처음에 생각합니다. 깔끔한 코드, 최신 기술, 깔끔한 git commit
하지만 6주 동안 프로젝트를 진행하면서 가장 목표로 삼아야 하는 것은 프로젝트의 완성도입니다.
하지만 이로 인해 핵심 기능이 부재하다면 핵심 기능이 부재함으로써 오는 기회비용에 대한 손실이 더 크다고 판단됩니다.
방향성 자체가 틀린 것은 아니고 무엇을 더 중점을 두느냐의 차이라고 생각합니다.
그렇다면 무조건 옛날 기술만 써야 할까요?
그런 것은 아닙니다.
적정 기술이라는 개념이 있습니다.
적정 기술이란?
고사양·고비용 대신, 사용자의 환경(저사양 기기, 느린 인터넷, IT 문해력 등)과 문화적 배경에 맞춰 지속 가능하고 저렴하게 실제적인 문제를 해결하는 기술을 의미합니다.
저희가 서버를 배포할 때 쿠팡이나 아마존 같은 큰 기업과 똑같은 수준의 서버를 만들어서 배포를 하지 않습니다.
그렇듯이 코드도 완벽에 가까운 코드를 만들면 좋겠지만 적정 선을 두어서 개발 속도를 유지할 필요가 있다고 생각합니다.
실제로 예로든 프로젝트에서 저희는 올바르게 적정 기술의 수준을 설정하지 못했고
큰 줄기로 보았을 때 두 가지의 기능이 목표였지만 그중 하나만 개발할 수 있었습니다.
이점이 아직도 두고두고 아쉽습니다.
마찬가지입니다.
비즈니스의 입장에서도 기술을 개선하지 않는 이유는 학습 비용 그리고 개선 비용이 기술 부채를 아득히 초월하는 경우가 있습니다.
비즈니스적인 관점에서 보았을 때 시장은 항상 변화하고 우리를 기다려주지 않습니다.
적절한 타이밍의 배포가 주요하며 이는 기술 부채를 감수하고도 서비스를 배포하고 고객의 피드백을 받는 것이
출시가 늦어진 서비스 보다 훨씬 값진 데이터를 제공하기 때문입니다.
결국 개발이란 한정된 자원 속에서 최적의 가치를 만들 내는 과정이라고 생각합니다.
완벽한 코드 보다 한정된 자원 속에서 최적의 가치를 만들어 내는 것이 더 좋은 개발자라고 생각합니다.