brunch

You can make anything
by writing

C.S.Lewis

by 신현묵 Sep 03. 2018

코드(Code)가 쓰레기가 되었다면...

과연 누구의 책임일까요? 개발자 책임일까요?

소프트웨어 품질에 대한 책임을 가지는 것은 개발 총괄을 누가 하고 있느냐고 질문하는 것과 똑같습니다. 

좀 더 쉽게 설명드리면, 개발자나 개발업무에 대한 일정이나 요구사항 수집부터 프로세스에 대한 '권한'을 누가 가지고 있는지에 대해서 확인해야 합니다.


아이러니하지만, 개발 총괄인 CTO가 이런 업무에 대한 권한을 모두 가지고 있는 회사는 매우 적다는 것을 이야기드리고 싶습니다. 대부분은 영업이나 대표의 '선택'이나 '결정'에 의해서 좌지우지되는 경우가 빈번합니다.


물론, 그런 상황을 방어해야 하는 것이 CTO나 개발 총괄, 개발팀장의 역할이기는 하지만, 대부분의 기업에서 이들이 가진 힘이나 권한은 매우 미약합니다. 개발자의 이야기를 비개발자에게 풀어낸다는 것은 정말 어려운 일이기 때문이죠.


코드(Code)가 쓰레기가 되고, 레거시가 되고... 통제가 어려운 상황으로 흘러간다는 것은 그런 의사결정을 진행한 대표나 중요 의사결정 과정에서 '급하다', '긴급'을 외치던 비즈니스 총괄의 책임이 매우 무겁다고 하겠습니다. 물론, 최종 의사결정 과정에서 결정한 '대표이사'의 책임이겠죠.


대부분 코드(Code)가 쓰레기가 되지 않는 IT회사의 특징은 CTO의 권한이 상당히 강합니다. 물론, 그런 강한 권한을 줄 수 있는 비즈니스 모델이 탄탄하고, 서비스당 객단가가 높은 경우에만 가능하다는 것은 정말 역설 저인 답변이 될 것입니다.


코드가 쓰레기가 된 책임은 '대표이사'가 책임져야 합니다.


대부분의 개발자들은 쓰레기 코드를 만드는 것을 좋아하지 않습니다. 하지만, 쓰레기 코드를 만들도록 종용하고, 의사 결정하고, 그런 상황을 만드는 것은 대부분의 주요 의사결정권자들입니다. 그리고, 개발자들은 그런 환경에 자포자기를 하게 되죠.


간혹, 이런 이야기는 제 주변의 회사에서도 나오는 경우가 빈번합니다만, 그런 이야기를 푸념처럼 이야기하는 대표이사에게 직접적으로 그런 이야기를 예전부터 했음에도 불구하고, 해당 대표이사는 자신의 의사결정에 대한 잘못된 판단에 대해서는 반성하지 않고, 개발자에 대한 푸념이나 욕, 투덜거림을 반복합니다.


안타깝지만, 그 회사의 코드 품질이나 실질적인 개발 총괄을 대표이사가 직접 했음에도 불구하고 말이죠.


잘못된 의사결정을 통해서 코드가 나빠진 것인데...


그런 대표이사들의 특징은 '실력 좋은 개발자'는 '잘못된 의사결정 과정'을 감안한 상태에서도 코딩을 잘해야 한다는 말도 안 되는 논리로 이야기를 하는 경우를 자주 보게 됩니다.


물론, 그런 대표이사들과는 거리를 두고, 더 이상 업무나 개발에 대한 이야기를 하지 않습니다.


최소한, 제가 알고 있는 대부분의 개발자들은 '코드'에 대한 자부심까지는 아니더라도, 최대한 버그 없고, 깔끔하며, 문제없는 코드를 만들고 싶어 합니다.


개발자를 신뢰하는 것만큼, 코드는 신뢰도 높은 코드로 표현됩니다. 물론, 그 정도를 어떻게 판단하느냐고 묻는다면, 믿을만한 개발 총괄이나 CTO를 초빙하라고 조언합니다. 그리고, 모든 소스코드를 고품질로 만들지 말고, 적정선을 유지해달라고 요구하면 가능하다고 조언하고 싶습니다.


대부분의 코드는 과도 품질이거나 고품질, 고성능일 필요가 없습니다.


불명확한 요구사항에 의해서 코드가 쓰레기가 되어가는 모습은 제 주변에서도 별로 어렵지 않게 찾게 됩니다. 안타까운 일이죠. 최소한 저는 그렇게 하지 않으려고 애를 씁니다만, 가끔 어쩔 수 없이 대표나 비개발자 C레벨과 의사소통이 불가능한 수준에 도달한다면 어쩔 수 없는 일이 되게 됩니다.


결론은 동일합니다.


쓰레기 같은 코드를 만드는 것은 '대표 의사'의 의지입니다.
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari