스프링 프레임워크를 사용하는 프로젝트에서 흔히 나타나는 안티 패턴이 있다. ‘빈약한 도메인 모델’. 들어 본 적 있나? 잠깐, 어디서 고약한 코드스멜이 나는 것 같다. 혹시 xxxVO 혹은 xxxDTO 와 같은 이름으로 상태(클래스의 필드)와 getter, setter만을 가진 수많은 클래스들이 있는가? 단지 C언어의 구조체 처럼 사용되기만 하는 이 녀석들이 바로 빈약한 도메인 모델이다. 말 그대로 빈약하다. 의도적으로 설계된 것이 아니라면 이것이 유지 보수를 힘들게 할 수 있다. 이들은 행동하지 않는다. 다른 객체들과 절대 협력하지 않는다. 그럴 거면 getter와 setter도 별로 의미가 없지 않을까? 그냥 모든 필드를 외부에 공개하고 아예 구조체로 활용하는 게 낫다. 이제 XXXService 라는 이름을 가진 클래스들을 한번 살펴보라. 혹시 그들이 엄청나게 많은 메서드를 가진 채로 모든 비즈니스 로직을 담당하는가? 원래 빈약한 녀석들이 해야 할 일까지 모두 떠안은 채, 심각한 스트레스에 시달리고 있는 모습이 보이는가? 변수와 메서드의 이름을 이해하기 어렵고, 게다가 메서드의 길이가 엄청나게 길다고? 이런.. 만약 그렇다면 위로의 말을 전한다. 유지 보수가 매우 힘든 프로젝트일 게 뻔하기 때문이다. 만약 필자가 왜 이런 말을 하는 지 전혀 감이 안 온다면 당신은 이미 코드스멜(👈 click!!)에 중독된 상태다.

아는 만큼만 보인다

많은 스프링 강의에서 객체 지향적인 설계에 대한 부분은 제대로 설명하지 않는다. 아마도 프레임워크 사용 방법에 초점이 맞춰져 있기 때문인 것 같다. 그래서 우리는 강의에서 배운 대로 VO와 Service, DAO 등의 클래스를 만든다. Service에서 DAO가 가져온 VO의 상태 값을 Getter로 꺼내거나 Setter로 할당한다. 모든 비즈니스 로직은 Service 안에 구현한다. 이런 식이라면 아마 테스트 코드는 없을 거다. 테스트하기 쉬운 코드가 아니다. 테스트를 중요하게 생각한다면, 코드 품질을 신경 쓴다면 이런 식의 코드는 작성되지 않았을 테다. 그래도 프로젝트는 잘만 굴러간다고? 정말 그럴까? 우리는 언제나 더 나은 것을 갈망해야 한다.

필자는 위에서 말한 안티 패턴대로 구현하는 게 좋은 건 줄 알았다. 강의에서 그렇게 배웠으니까. 그리고 일터에서도 그렇게 하고 있으니까. 그러면 되는 줄 알았다. 그런데 코드 품질에 대한 강의, 책을 접하면 접할수록 머리를 몽둥이로 두드려 맞는 것 같았다. 내가 악취에 중독되어 가고 있었다는 사실이 충격적으로 다가왔다. 그 때 나는 “아는 것이 힘이고, 아는 만큼만 보인다” 라는 말을 뼛속 깊이 새겼다.

우리는 항상 자신이 어떤 상황에 놓여있는 지 파악하고 더 나아지기 위해 노력해야 한다. 만약 내가 아무 생각 없이 순응하며 살았다면 ‘현실은 원래 이런 건가 보다’ 하면서 지금도 빈약한 도메인 모델을 만들어 내고 있을 게 분명하다. 우리는 자기도 모르게 좋지 않은 무언가에 휩쓸리지 않도록 늘 생각하고 경계해야 한다. 모른다는 사실을 모르는 게 가장 위험하다. 이제는 바뀌어야 한다. 꾸준히 공부하고 깨어있는 시야를 가져야 한다.

코드스멜 중독을 피하는 방법

만약 자신이 코드스멜에 중독되었다는 사실을 깨달았다면 어떻게 해야 할까? 혹시 올바른 방향으로 가르치고 코칭해줄 수 있는 사람이 주변에 있는가? 당신은 축복 받은 사람이다. 그들로부터 상황에 맞는 적절한 조언을 받아라. 하지만 축복 받은 사람은 소수에 불과하다. 나를 포함하여 축복 받지 못한 여러분에게 이 글이 도움이 되기를 바란다.

책의 도움을 받아라

필자가 어떻게 분위기에 휩쓸리지 않고 코드스멜 중독에서 빠져나올 수 있었는지 눈치 챈 독자도 있을 것이다. 우리의 앞길을 밝혀줄 수 있는 것. 올바른 길로 인도해 줄 수 있는 멘토는 바로 책이다. 강의보다는 책을 우선적으로 읽을 것을 권한다. 책을 왜 읽는 지 이해가 안 된다면 이 글(👈 click!!)을 읽어보라. 우리는 놓여진 상황을 탓할 시간에 해결 방법을 찾아 실행하고 조금씩 더 나아져야 한다. 그러니 책을 읽어라. 그리고 실천하라. 객체 지향, 유닛 테스트, 리팩토링을 공부하라. 도메인 주도 설계(DDD), 테스트 주도 개발(TDD) 등에 대해서 공부하라. 구글에 검색해서 찾아보는 것에 그치지 말아라. 몇 백 페이지 분량의 긴 글 형식의 도서를 읽어라. 마음을 열고 공부하다 보면 좋은 코드 품질이 왜 중요한지 깨닫고 노력하게 될 것이다.

반드시 실천하라

읽는 것 만으로는 충분하지 않다. 배운 내용을 업무 중에 적용해 보아라. 그게 힘들면 개인 프로젝트라도 하면서 배운 것을 써먹어라. 스스로 실천하지 않으면 아무리 값진 조언도 소용 없다. 당장 써먹을 수 있는 것들 위주로 배워라. 그리고 반드시 실천하면서 내 것으로 만들어라. 써먹으려고 시간 들여 배우는 것 아닌가. 일단 먹어보라. 똥인지 된장인지 먹어보고 맛을 음미해보라. 직접 다양한 상황을 경험해 보고 느껴라. 그러면 책을 쓴 저자가 왜 이렇게 우리를 설득하려 하는지 제대로 이해할 수 있다.

노력해야 할 이유

이미 팀 전체가 코드스멜에 중독되어있을 수도 있다. 코드에서 나는 악취는 원래 그런 것. 늘 하던 대로 하다가 퇴근하면 되는 일상. 개발 조직으로서 이미 죽은 거나 다름 없다. 어째서 코드에서 악취가 나는데 치울 생각을 하지 않을까? 원래 사람이 그렇다. 더 나아지기 위한 행동은 귀찮고 힘들다. 의식적으로 노력하지 않으면 지속할 수 없다. 익숙한 것을 좋아한다. 그리고 익숙한 것은 점점 당연한 것이 된다. 주변에서 다들 그렇게 살아간다. 그 옆에 있는 사람도 그냥 그렇게 살게 된다. 변화를 경계한다. 죽은 조직은 그렇게 만들어진다. 이는 결코 코드스멜에만 해당되는 이야기가 아니다. 우리는 그것을 경계해야 한다.

우리가 조직에 변화의 물결을 만들어 보는 것은 어떨까? 그러기 위해서는 우리 자신부터 바뀌어야 한다. 스스로 잘 알지 못하면서 개선 의지가 없는 타인을 설득할 수는 없다. 솔선수범하면서 왜 이렇게 하는 게 좋은 지 확인 시켜주는 방법이 가장 설득력이 크다. 분위기에 휩쓸리지 말고 개인적으로 시간을 내서 공부하라. 끊임 없이 작은 목표를 세우고 성공 경험을 쌓아라. 꾸준히 갈고 닦으면서 내공을 쌓다 보면 팀을 변화시키기 위해 어떤 노력을 할 수 있는 지 알게 될 지도 모른다. 그러나 공부하지 않으면 조금의 가능성도 없다. 어떤 이유든 팀을 변화 시키는데 실패했다면 우리는 더 나은 조직으로 떠나는 선택을 하는 것도 가능하다. 그러나 공부하지 않으면 우리에게 어떠한 선택지도 주어지지 않는다. 이것이 우리가 노력해야 하는 이유다. 고독하고 쓸쓸하더라도 우리는 꾸준히 정진해야 한다.