토목 기술자는 어떤 다리도 똑같을 수는 없다고 주장할 수 있다. 그러나 다리에는 많은 공통된 특징이 있고, 다리를 만드는 데 사용되는 재료에도 공통된 특징이 있다. 다리를 만드는 일에는 잘 알려진 지식을 많이 사용하며, 잘 알려지지 않은 지식은 생각만큼 많지 않다.

필자는 토목 기술자가 아니며, 다리를 설계하고 만드는 훌륭한 토목 기술자를 존경할 뿐이다. 다만, 다리 건설과 소프트웨어 작성을 비교하고자 한다. 잘 작동하는 소프트웨어를 만드는 것은 어렵다. 소프트웨어 개발팀이 착수한 프로젝트는 지금까지 단 한 번도 성공한 적이 없다. 물론 프로젝트 사이에 유사점이 있는 것은 사실이지만, 모든 소프트웨어 프로젝트에는 고유한 뉘앙스와 요구사항, 그리고 알려지지 않은 미지의 것들이 많이 존재한다.

소프트웨어 개발은 다루기 어려운 역설들로 가득 차 있다고 말할 수도 있다. 여기 대표적인 4가지 역설을 소개한다.

얼마나 걸릴지 아무도 알 수 없지만, 고객은 완료 날짜를 요구한다

솔직히 말해서, 이것은 아마도 소프트웨어 개발팀이 직면한 가장 큰 과제일 것이다. 우리는 어떤 프로젝트가 얼마나 걸릴지 확신할 수 없다. 물론, 추정할 수는 있지만, 거의 항상 크게 빗나간다. 소요 시간을 과대평가하는 경우가 없지 않지만, 보통은 과소평가한다.

고객 입장에서는 수수께끼이자 큰 골칫거리다. 이 역설을 이해하지 못하면, 새 소프트웨어가 언제 완성될지 확실히 알 수 없다는 것을 이해하지 못한다. 그리고 당연히 약속대로 소프트웨어가 제공되지 않으면 실망한다.

개발팀은 스토리 포인트, 플래닝 포커, 그리고 모든 종류의 애자일 기법을 시도해 보지만, 호프스테더의 법칙을 벗어날 수 없는 것 같다. 호프스테더의 법칙을 계산에 반영했다 하더라도 항상 예상보다 오래 걸린다.

지체된 프로젝트에 개발자를 추가하면 더 늦어진다.

브룩스의 법칙으로 알려진 이 법칙은 일반인에게는 가장 이상한 역설일 것이다. 일반적으로, 치약 튜브를 채우는 월 할당량을 마감 기한까지 채우지 못할 것 같다면, 작업 인력을 추가해 마감 기한을 맞출 수 있다. 만약 집을 두 채 더 짓고 싶다면, 일반적으로 투입량(노동력과 재료)을 두 배로 늘려서 집을 두 채 더 지을 수 있다.

그러나 프레드 브룩스가 그의 저서 ‘맨먼스 미신(The Mythical Man Month)’에서 보여준 것처럼, “지체된 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다.” 매우 역설적이지만, 소프트웨어 개발에서는 법칙에 가까운 진실이다. 브룩스는 새로운 팀원이 복잡한 시스템의 맥락을 배우는 데 시간이 필요하고 커뮤니케이션 오버헤드를 증가하기 때문에 프로젝트에 즉시 기여할 수 없으므로 프로젝트 완료 시간이 길어지고 비용도 증가한다는 것을 보여줬다.

코딩 실력이 향상될수록 코딩할 필요가 줄어듭니다

소프트웨어 개발자로서 경험을 쌓는 데는 오랜 시간이 걸린다. 올바른 코딩 방법, 올바른 디자인 방법, 깔끔하고 유지 관리가 쉬운 소프트웨어를 작성하는 데 필요한 모든 규칙과 미묘한 차이 등을 배우는 것은 하루아침에 이루어지지 않는다.

그러나 경험을 쌓으면, 실제로 코드를 작성하는 양이 줄어들게 되는 관리자 직책에 배치되는 경우가 너무 많다. 코딩하는 대신, 디자인 회의에 참석하고 다른 사람이 작성한 코드를 검토하고 실무 개발자를 관리하게 된다. 때로는 코딩을 전혀 하지 않고 승진하기도 한다.

물론, 선임 개발자의 기여도가 줄어들지는 않는다. 프로젝트를 계획하고 후배 개발자를 멘토링하고 코딩 표준을 적용하고 모두가 좋은 코드를 작성하는 것이 얼마나 중요한지 깨닫는 등, 선임 개발자는 팀과 회사의 성공에 크게 기여한다. 그러나 결국 코드를 더 적게 작성하게 된다.

개발 플랫폼과 도구는 계속 좋아지지만, 소프트웨어 개발은 여전히 오래 걸린다

우리가 웹 애플리케이션을 구축하는 방식을 비교해 보자. 오늘날 리액트(React)나 아스트로(Astro), Next.js와 같은 놀랍도록 강력한 도구와 30년 전 CGI(Common Gateway Interface)를 사용해 데이터와 HTML을 처리했던 방식을 비교해 보면, 우리가 초창기보다 훨씬 더 발전했다는 것을 알 수 있다.

이렇게 도구는 점점 더 정교해지고 프로세서도 점점 더 빨라지고 있지만, 소프트웨어 개발은 결코 더 빨라지지 않는 것 같다. 작업은 항상 예상 시간뿐만 아니라 모든 CPU 사이클을 추월하는 것처럼 확장되는 것 같다.

사이트는 더 멋져 보이지만, 정말 더 생산적일까? 사이트가 더 빨리 실행되고 데이터를 더 잘 처리할까? 물론, 이런 새로운 프레임워크와 라이브러리는 많은 복잡성을 추상화한다(누가 jQuery 코드를 쓰고 싶겠는가?). 그러나 긴 빌드 파이프라인, 악몽 같은 환경 구성, 종속성 과부하와 같은 새로운 문제도 발생한다.

이런 역설이 존재한다고 해서 소프트웨어 개발이 절망적인 일이라는 의미는 아니다. 소프트웨어 개발자를 좌절시키거나 우울하게 만들기 위해 역설을 지적하는 것이 아니다. 역설적이게도, 이런 역설에도 불구하고 많은 소프트웨어 개발팀은 여전히 잘 작동하는 소프트웨어를 구축하고 출시한다.

필자는 이런 역설을 인식하고 이를 수용하고 처리해야 하며, 역설이 제시하는 함정과 움푹 패인 곳을 피해야 한다는 것을 강조하려는 것이다. 그 이상함과 혼란을 제거할 수는 없지만, 우리 소프트웨어 개발자는 예상하고 대처할 수는 있다. 우리의 임무는 그럼에도 불구하고 제품을 출시하는 것이다.

마지막으로 추가할할한 가지 역설적인 사실은 소프트웨어는 결코 완성되지 않는다는 것이다. 추가할 수 있는 기능이 항상 하나 이상 남아 있다. 다리를 건설하는 일은 적어도 작업이 완료되고 제품이 설계된 대로 작동하는지 여부는 분명히 알 수 있다.
dl-itworldkorea@foundryco.com