[번역] 프레임워크에 묶이다

현우

Mar 4, 202612d ago

Category

Empty

레퍼런스

https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBound.html

프레임워크는 강력한 도구다. 프레임워크 없이는 우리는 길을 잃고 말 것이다. 하지만 프레임워크를 쓰는 데에는 대가가 따른다.

Rails, Spring, JSF, Hibernate 같은 것들을 떠올려 보라. 이런 프레임워크의 도움 없이 웹 시스템을 작성한다면 어떤 모습일까? 생각만 해도 암담하다. 사소하고 귀찮은 세부사항들을 끝없이 처리해야 할 것이다. 마치 돌칼과 곰가죽만 가지고 기억 회로(mnemonic memory circuit)를 만들겠다고 덤비는 것과 같을 테니[1].

그래서 우리는 프레임워크가 약속하는 모든 이점을 기대하며, 기꺼이 우리의 코드를 그 프레임워크에 결합(couple)시킨다. 그리고 많은 프로그래머들이 우리보다 먼저 저질렀던 실수를 똑같이 반복한다. 우리는 스스로를 프레임워크에 묶어버린다.

프레임워크를 사용한다는 것은 상당한 수준의 헌신을 요구한다. 프레임워크를 코드에 받아들이는 순간, 프레임워크가 관리하는 세부사항들에 대한 통제권을 당신은 내려놓게 된다. 물론 이는 좋아 보인다. 그리고 대개는 실제로도 좋다. 하지만 모퉁이를 돌면 함정이 기다리고 있다. 그리고 그 함정은 다가오기 전까지 잘 보이지 않는다. 정신 차려보면 당신은 온갖 부자연스러운 짓을 하고 있다. 프레임워크의 베이스 클래스를 상속하고, 제어 흐름의 더 많은 부분을 내어주고, 프레임워크의 관례와 버릇, 고약한 특이점(idiosyncrasies)에 점점 더 깊이 고개를 숙이고 있는 것이다.

그런데도 당신이 프레임워크에 엄청나게 헌신했음에도, 프레임워크는 당신에게 어떤 상호적 헌신도 하지 않는다. 그 프레임워크는 저자가 기분 내키는 방향으로 얼마든지 진화할 자유가 있다. 그리고 실제로 그렇게 되면, 당신은 충직한 강아지처럼 그 뒤를 따라갈 수밖에 없다는 사실을 깨닫게 된다.

프레임워크에 묶이는 일은 소프트웨어 팀에서 너무 흔하게 벌어진다. 팀은 넘치는 열정으로 시작하며 자발적으로 코드를 프레임워크에 결합시킨다. 하지만 훨씬 나중에, 프로젝트가 성숙해져 갈수록 그 프레임워크가 점점 더 발목을 잡는다는 사실을 알게 된다.

놀랄 일도 아니다. 프레임워크는 사람들이 자신들이 가진 특정 문제를 해결하기 위해 만든 것이다. 그 문제들은 당신의 문제와 비슷할 수도 있다. 하지만 그 문제는 당신의 문제가 아니다. 당신에게는 당신만의 문제가 있다. 당신의 문제와 프레임워크가 해결하려는 문제가 겹치는 범위에서는, 프레임워크가 엄청난 도움이 될 수 있다. 반대로 당신의 문제와 프레임워크의 문제(혹은 철학)가 충돌하는 범위에서는, 프레임워크는 엄청난 장애물이 될 수 있다.

프레임워크 저자들

프레임워크는 사람이 만든다는 사실을 기억하라. 그리고 사람에게는 각자의 의도가 있다. 그 의도 중 하나는 당신이 자신의 프레임워크를 사용하게 만드는 것이다. 과거에 프레임워크를 만들었던 저자로서 말하자면, 내 프레임워크를 사용하는 사람이 많을수록 나는 내 자신에 대해 더 기분이 좋았다. 내 자존감의 많은 부분이 내 프레임워크가 받아들여지는 것과 엮여 있었다.

프레임워크 저자들을 심리 분석까지 깊게 하고 싶진 않다. 프레임워크 저자들이 나쁜 사람이라는 뜻도 아니다. 사실 대체로 그들은 영웅들이다. 많은 이들이 이타적으로 자신의 코드를 오픈소스 커뮤니티에 공개한다. 이런 사람들이 없었다면 우리의 프로그래밍 삶은 훨씬 덜 즐겁고 덜 생산적이었을 것이다.

내가 저자 이야기를 꺼낸 이유는, 프레임워크 저자와 사용자 사이 관계가 어떤 메커니즘으로 돌아가는지 이해하는 데 도움이 되기 때문이다.

프레임워크 저자들은 당신을 "우리 편"으로 끌어들이기 위해 아주 많은 노력을 한다. 논문을 쓰고, 발표를 하고, 예제를 제공한다. 그리고 당신이 자신의 코드에 더 단단히, 더 단단히 결합하도록 보여준다. 강하게 묶였을 때 얻는 이점들을 시연한다. 그들은 자신의 코드가 당신에게 도움이 될 거라고 확신하며, 당신도 그렇게 믿게 만들기 위해 열심히 노력한다.

그건 지극히 정상적이고, 전혀 부정직한 일도 아니다. 그들은 당신이 자기 편에 들어오길 원한다.

하지만 당신이 일단 "우리 편"이 되면, 그들의 당신에 대한 관심은 조금 달라질 수도 있다. 아래는 유명한 한 프레임워크 저자가 사용자들의 어떤 걱정에 대해 본인이 어떻게 생각하는지 보여주는 사진이다. (R 등급)

적당한 거리(Arm's Length)

수년 동안 나는 프레임워크에 대해 건강한 수준의 회의감을 갖게 되었다. 프레임워크가 매우 유용하고 엄청난 시간을 절약해준다는 사실을 인정하면서도, 거기에는 비용이 따른다는 사실도 안다. 그리고 때로는 그 비용이 정말 크게 불어나기도 한다.

그래서 내 전략은 Spring, Hibernate, Rails 같은 프레임워크를 적당한 거리에 두는 것이다. 아키텍처 경계 뒤에 두는 방식으로 말이다. 그렇게 하면 프레임워크가 주는 이점은 대부분 누릴 수 있고, 동시에 필요하다면 아주 냉정하게(framework를) 이용할 수도 있다.

하지만 나는 그 프레임워크들이 너무 가까이 오게 두지 않는다. 나는 그들에게 내 자율성을 한 점도 내주지 않는다. 그들의 코드 촉수가 내 시스템의 고수준 정책(high level policy)과 뒤섞이도록 허용하지 않는다. 프레임워크는 주변부 하위시스템(peripheral subsystem)에는 닿아도 된다. 하지만 핵심 비즈니스 로직에서는 멀리 떨어져 있어야 한다. 내 시스템의 고수준 정책은 결코 프레임워크에 의해 건드려져서는 안 된다.

[1] 스타 트렉: The City on the Edge of Forever, Harlan Ellison, 1967

[2] Apology: https://gist.github.com/unclebob/2abcce451bafeab421f2

悠悠

Subscribe to '悠悠自適'

Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to '悠悠自適'!