1. 제가 만든 소프트웨어에 구조가 없어요

같이 교육을 받았던 프런트엔드 엔지니어 J의 사례와 연결된 이야기를 해보려 한다. 이 분은 여러  커뮤니티 활동을 하시는 것으로 보였다. 그중 하나의 커뮤니티에서는 참가자들의 만남을 이어주는 여러 이벤트가 있었다. 이 분은 이 만남과 관련된 자동화에 기여하시고 있었다. 이 기능은 Typescript 짠 코드였는데, 당시는 관리자와 본인의 컴퓨터에서 자동화 스크립트로서 동작하였다.

물론 잘 동작하는 코드였지만, 이 코드를 "적절한 설계 없이" 만들었다고 생각하신 듯했다. 그래서, 공유해 준 고민은 "좋은 구조로 만들고 싶다"였다. 나는 이러한 상황을 "구조가 없음"이라고 이해했다. 우리의 이야기는 "이 부분을 어떻게 개선하는가"가 포인트였고, 원 포인트 세션 논의를 통해서 개선 방향을 잡았다. 세션을 하고 난 얼마 후 이야기 나눌 때에도 계속해서 그 방향으로 발전시키고 계셨다. 모듈화를 하였고, 데이터를 원격에서 가져오는 작업, 서버에 스크립트를 채팅 어플의 봇(bot)으로 올리는 계획을 세우고 있었다.

하지만, 이 글에서 이야기하고 싶은 주제는 위에서 이야기한 개선 방향은 아니다. 그것보다는 우선 "구조가 없음"이라는 부분에 대해서 이야기를 해보고 싶다. 왜냐하면 많은 사람들이 간과하지만 "모든 소프트웨어에는 구조가 있기" 때문이다. 여기서 이야기하는 소프트웨어 구조는 동작하는 소프트웨어가 가지고 있는 구조에 대한 것이다. 즉, 개발자가 요구 사항에 따라 고민하고 구현하면 구조는 발생한다. 물론, 객체 지향 프로그래밍(OOP), 디자인 패턴(Design Pattern)과 같은 경험 많은 사람들이 찾아낸 내용들을 포함하는 것이 조금 더 좋을 수 있다. 하지만, 우리가 처리해야 하는 기능을 잘 처리하고 있고 동작하고 있다면 이미 "구조"를 가지게 되는 것이다. 그렇다면, 정말 좋지 않은 구조라면 의미가 없는 것일까?

여기서는 많은 사람들이 좋지 않다고 하지만 실제로는 많이 존재하는 구조 한 가지를 살펴보자. 큰 진흙뭉치(Big Ball of Mud)라고 부르는 구조이다. 이 구조는 소프트웨어가 모듈의 구분 없이 한 덩어리로 되어 있는 경우이다. 위에서 이야기 한 사례의 경우, 소스 코드는 유틸리티 기능을 제외한 코드가 하나로 되어 있었다. 그러므로, 큰 진흙뭉치에 해당한다고 할 수 있겠다. 기능이 동작하게 하는 것이 먼저 여서기 우선 필요한 기능들을 모두 모아서 구현했을 가능성이 높다. 기간도 부족하고 요구 사항도 불분명했을 가능성도 높다. 아마도 구현한 사람 이외에는 문제점을 수정하기 어려워 매우 낮은 유지보수성(maintainability)을 가질 것이다. 또한, 기능을 추가하거나 확장하는 것이 매우 어려워 확장성(extensibility)이 낮을 것이다.

그렇다면, 이러한 구조에서는 단점만 존재할까? 아니다, 이 구조의 장점을 주장하는 사람도 있다. 우선 이와 같이 작은 대상에 유리할 것이다. 이미 잘 동작하고 있고 적은 노력으로 동작하는 소프트웨어를 만들었다. 만일 이 기능이 상용 소프트웨어였다면 회사에서는 이 기능을 구현한 사람을 가능한 계속 채용한 상태로 유지하려고 할 것이다. 즉, 우스개 소리 같지만 개발자 입장에서는 고용이 안정될 수 있을 것이다. 나도 관련된 실제 사례를 들은 적이 있다. 이 사례의 경우는 통신 소프트웨어였다. 일반적으로 통신 소프트웨어에서는 계층화 되어, 레이어 1, 2, 3와 같이 주로 구분을 하는데 HW를 다루는 레이어 1의 경우는 보통 펌웨어로 다루는 경우가 많다. 그러다 보니, 레이어 1은 효율성이 강조가 되고 가독성과 같은 품질 속성은 많이 무시되는 경향이 있다. 이 전체 소프트웨어 개선을 목표로 여러 개발자들이 개선 작업을 한 것을 전해 들었는데, 레이어 2까지는 리팩터링을 했지만, 결국 레이어 1은 손대지 못하였다고 한다. 이 때, 레이어 1 개발팀은 계속 유지되고 있다고 들었다.

나는 애자일리스트로서 동작하는 소프트웨어를 더 존중한다. 그러면서도, 여러 가지 구조에 대해서 장단점이 있다고 생각한다. 심지어 큰 진흙 뭉치에서도 위에서 이야기한 것 같기 배울 점이 있다는 부분이 있다. 우리는 현실에서는 선택해야 한다. 동작하는 소프트웨어를 위해서 말이다.