모듈성은 소프트웨어 개발의 진정한 기술이다

인공지능 시대의 소프트웨어 공학

Jun 28. 2025

<모던 소프트웨어 엔지니어링>의 9장 <모듈성: 분리와 재조합을 위한 기준>에서 밑줄 친 내용을 토대로 생각을 정리한 글입니다.

모듈성(Modularity)에 대한 다양한 정의

첫 번째 밑줄 친 내용은 모듈성에 대한 정의입니다.

모듈성(modularity)은 "시스템의 컴포넌트를 분리하고 재조합할 수 있는 특성으로, 종종 유연성과 다양한 사용이라는 이점을 제공한다."

위키피디아에 정의된 모듈성(Modularity) 페이지도 찾아봅니다. 그리고 크롬 번역한 내용을 인용합니다.

모듈성은 시스템 구성 요소를 분리하고 재결합할 수 있는 정도를 나타내며 , 종종 유연성과 다양성이라는 이점을 제공합니다. 모듈성 개념은 주로 시스템을 다양한 수준의 상호 의존성과 독립성으로 나누어 복잡성을 줄이고 "각 부분의 복잡성을 추상화와 인터페이스 뒤에 숨김 "으로써 사용됩니다.

기술 분야에 대한 모듈성 정의는 따로 있습니다. 그중 소프트웨어 설계에 있어 모듈성에 대한 정의입니다.

소프트웨어 설계에서 모듈성이란 복잡한 소프트웨어를 구현 및 유지 관리 목적으로 관리할 수 있도록 하는 "소프트웨어 설계"의 논리적 분할을 의미합니다. 분할 논리는 관련 기능, 구현 고려 사항, 데이터 링크 또는 기타 기준을 기반으로 할 수 있습니다.

모듈식 프로그래밍 정의도 있습니다.

모듈식 프로그래밍에서 모듈성이란 소프트웨어 패키지의 각 부분을 구획화하고 상호 연관시키는 것을 말합니다.

모듈화: 다시 쓰는 동시에 유연성을 줄 수 있나?

올봄에 스스로 모듈화에 대해 연구하며 쓴 글 <모듈화: 다시 쓰는 동시에 유연성을 줄 수 있나?>도 있습니다. '다시 쓰는 동시에 유연성을 줄 수 있냐?'는 질문은 모듈화의 두 가지 이점을 잘 묶은 표현으로 위키피디아 모듈성 정의와 교차 사용해도 의미 손실이 크게 없을 듯합니다.

그리고 서로 다른 맥락에서 추출한 다음 두 이미지의 연관성도 분명하게 포착됩니다. 컴포넌트의 아주 단순한 규정이 효과를 발휘하는 측면이 소프트웨어를 벗어나 선박을 이용한 물류업에서도 그대로 보였습니다.

그리고 이는 바로 복잡도를 줄여주는 'Out-of-box 기능 제공 방식과 설계 결정의 은닉'을 자유롭게 활용할 수 있다는 점을 내포한 것이기도 합니다.

모듈성은 소프트웨어 개발의 진정한 기술이다

이 책에서도 그러한 내용을 그대로 찾을 수 있습니다.

모듈성은 우리가 만드는 시스템의 복잡성을 관리하는 데 있어 매우 중요하다. 현대적인 소프트웨어 시스템은 방대하고 복잡하며 종종 정말 정교하다. 대부분의 현대적인 시스템은 모든 세부 사항을 머릿속에 담기 위한 인간의 능력을 뛰어넘는다. 이런 복잡성에 대처하려면 우리가 구축하는 시스템을 더 작고 이해하기 쉬운 조각, 즉 시스템의 다른 곳에서 일어나는 일에 대해 너무 걱정하지 않고 집중할 수 있는 조각으로 나눠야만 한다. 이는 항상 사실이며, 다시 말하지만 이는 다양한 세부 수준에서 작동하는 일종의 프랙탈 아이디어다.

이는 항상 사실이라는 저자의 말은 앞선 항만의 컨테이너 선적 이미지 속에서도 드러납니다. 그리고, 인공지능 기술을 선도하는 기업이 에이전트라는 일종의 모듈 표준과 이들의 소통을 돕는 프로토콜을 만드는 일에서도 고스란히 드러나죠.

와... 그리고 전율을 느끼게 하는 문구가 등장했습니다.

나는 이것이 소프트웨어 개발의 진정한 기술이라고 생각한다. 이런 특성은 자신의 분야에 통달한 전문가가 작성한 코드와 갓 입문한 초보자가 작성한 코드를 가장 크게 구분하는 요소다.

바로 오늘 패널로 참여하는 SpringCamp 2025 행사에서 받은 질문에 덧붙이면 좋을 문구라는 생각이 들었기 때문입니다. 묘한 인연이라는 생각에 전율을 느낀 것이죠.

객체에게 역할과 책임을 부여한다는 게 무슨 의미일까요?

그리고 다음 문구를 볼 때 10여 년 전에 만났던 수 만 라인의 코드를 떠올렸습니다.

설계에서 좋은 모듈성을 달성하려면 기술이 필요하지만, 내가 본 많은 코드에서 인식한 바에 따르면 사람들은 모듈화를 '잘못하는' 대신 전혀 시도하지' 않는다. 많은 코드가 마치 레시피처럼, 즉 수백 또는 수천 줄의 코드에 걸쳐 있는 메서드와 함수로 선형적인 일련의 단계를 모아놓은 듯이 작성되어 있다.

심지어 그 코드를 작성한 개발자들은 자신들의 경력이나 기술력(?)을 자랑하기까지 했습니다.

문제를 나누고 재구성하는 역량이 더 중요하다

그분들에게 전해주면 딱 좋았을 문구를 10년이 더 지난 후에 이 책에서 발견합니다.

언어의 구문을 아는 것만으로는 좋은 프로그래머는 고사하고 '프로그래머'가 되기에도 충분하지 않다. 'X라는 언어를 관용적으로 사용하는 것'은 고품질의 설계보다 덜 가치 있고 덜 중요하다. 'API Y의 난해한 세부 사항을 안다고 해서 더 나은 소프트웨어 개발자가 되는 것은 아니며, 그런 종류의 질문에 대한 답은 언제든지 찾아볼 수 있다! 뛰어난 프로그래머와 그렇지 못한 프로그래머를 구분하는 진정한 기술은 언어나 프레임워크에 국한되지 않는다. 이런 기술은 다른 곳에 존재한다.

그리고, '그런 종류의 질문에 대한 답은 언제든지 찾아볼 수 있다'는 말을 보며, 요즘IT에 최근 기고한 글 <인공지능 시대에도 개발자로 살아남기>를 떠올렸습니다. 난해한 로직이나 세부 사항을 아는 일은 이제 인공지능에 의해 대체될 수 있는 일이 될 가능성이 높습니다.

반면에 관심사를 구분하는 역량(Seperation of concerns)은 AI 에이전트로 모듈을 구성하는 시대에도 여전히 유효할 것입니다.

프로그래밍 패러다임, 언어 또는 도구에 관계없이 모듈성이 좋고 관심사가 잘 분리된 코드가 있다면 해결하려는 문제에 대해 더 많이 알게 되면서 더 좋아지고, 작업하기 더 쉽고, 테스트하기 더 쉽고, 수정하기 더 쉬워질 것이다.

당장 결과를 내는 데에 있어서 모듈성의 가치는 커 보이지 않을 수 있습니다.

진짜 문제는 복잡한 코드는 정의상 변경하기가 더 어렵다는 점이다. 즉 처음에 코드를 작성할 때 제대로 만들 수 있는 기회가 한 번밖에 없음을 의미한다. 또한 코드가 복잡하다면 생각하는 것만큼 코드를 잘 이해하지 못했을 가능성이 높으며, 실수가 숨어 있을 만한 곳도 훨씬 더 많다.

그런 이유로 시행착오를 통해서만 모듈성의 중요성을 느끼게 되는 측면도 있는 듯합니다. 물론, 저자 말대로 긴 경력을 'X라는 언어를 관용적으로 사용하는 것'으로 고스란히 채운 개발자도 종종 만나게 됩니다.

모듈성을 증폭 혹은 증강시켜 주는 무기들

저자는 TDD의 진정한 이점을 제대로 이해하고 정확하게 설명합니다.

테스트 주도 설계 접근 방식이 자동으로 훌륭한 설계를 만들어낸다는 뜻은 아니다. 테스트는 마술 지팡이가 아니다. 여전히 설계자의 기술과 경험에 의존한다. 훌륭한 소프트웨어 개발자는 형편없는 개발자보다 더 나은 결과물을 만들어 낼 수 있다. 테스트에서 설계를 이끌어 내는 것은 테스트 가능한 코드와 시스템을 만들도록 장려하므로 경험과 재능의 한계를 고려할 때 결과물이 향상된다. 비슷한 수준의 효과를 내는 우리가 보유하고 있는 다른 기술은 생각할 수 없다! 따라서 이 재능 증폭기talent amplifier는 우리가 수공예에서 공학으로 나아가기 위한 중요한 도구다.

거기에 더하여 TDD를 공학으로 나아가게 하는 중요한 도구라고 규정하고 '재능 증폭기talent amplifier'라는 별명을 붙입니다. 최근에 Kent Beck이 쓴 글에서 본 'Augmented Coding'이라는 표현을 떠올리게 합니다. 각기 다른 기술이고 등장 시점은 다르지만 개발자의 역량을 강화시켜 주는 도구들로 묶어 볼 수 있습니다.