어제 잠을 자다가 깨버려서 트위터를 보는데, Outsider님께서 사내 프레임워크에 대해 쓰신 글이 타임라인에 있었습니다. 읽다보니 참 여러가지 생각이 들었는데, 그냥 흘려보내긴 아까운 것 같아서 글로 남겨보려고 합니다.

사내 프레임워크는 무엇인가?.

업종에 따라 없기도 하기 때문에 잘 모르는 분이 계실 수도 있을 것 같아서 간단히 소개합니다.

사내 프레임워크는 말 그대로 회사 내에서만 쓰는 프레임워크입니다. 회사에서 반복적으로 쓰이는 작업에서 생산성 향상을 위해 개발됩니다. 직업교육을 아무리 받아도 회사에 가서 더 배워야 하는 원인 1위를 차지하고 있는 요소입니다. 회사 내에서 필요한 것들을 뭉쳐서 만들게 되는데, 이것이 방치되면 훗날 레거시가 됩니다.

사내 프레임워크는 왜 탄생하는가?.

저는 웹 개발자니까 웹으로 예를 들겠습니다. 웹 사이트를 개발하다보면 반복적으로 하게 되는 작업들이 있습니다. 웹 사이트를 바닥부터 만든다고 생각해봅시다. 그렇다면 PHP로는 대략 이런 식으로 시작하게 되겠죠.¹

<?php
$config = read_config();
$instance = new PDO($config['db']);

사이트를 100개 만든다면, 이런 작업을 100번 하게 될 것입니다. 이걸 매번 타이핑하는 것은 매우 귀찮은 일입니다.

더군다나, 웹 사이트의 경우에는 대부분 게시판이나 쇼핑몰 같은 기능이 필요합니다. 대부분의 게시판이나 쇼핑몰은 회원 시스템을 요구하게 되죠. 따라서 서로 얽힌 기능들이 서로간의 의존성을 가진 상태의 코드가 매번 필요해집니다.

이걸 매번 개발하는 것은 너무나도 실용성 면에서 나쁩니다. 그리고 그 결과 이러한 작업들을 하나로 뭉뚱그려서 하나의 틀(frame)위에서 동작하는 프로그램, 프레임워크(framework)가 만들어지게 됩니다.

사내 프레임워크는 나빠진다.

사실 여기까지는 매우 자연스러운 흐름입니다. 하지만 여기엔 맹점이 존재합니다.

이제까지 100여곳의 쇼핑몰을 만들었고, 반복 작업이 싫어서 이것을 하나의 프레임워크로 만들어서 쇼핑몰 이란 문제에 대한 솔루션으로 쓰고자 한다고 칩시다. 그러면 보통 100여곳은 새로 만들어진 프레임워크로 커버가 가능할 것입니다. 만들어진 기능에 한해서는 프레임워크 내장 기능으로 인한 기능 추가가 용이하다던가, 개발성이 향상될 수도 있습니다.

하지만 개발이라는 것은 언제나 같은 명세가 아닙니다. 똑같은 회원 가입 시스템을 만든다고 해도 어디는 성과 이름을 나눠서 받을 것이고, 어딘가는 실명 인증을 해야만 하고, 어딘가는 외국어 이름을 받거나 아예 이름을 받지 않을 수도 있습니다. 이 모든 케이스를 사내 프레임워크에 넣을 것인가요?

사실 넣을 수도 있습니다. 하지만 보통 넣다보면 급하게 만들게 되는 경우가 대부분이고, 그마저도 땜질 수준이 되기 쉽상입니다. 점점 기능이 비대해지기는 하지만 아무도 관리를 제대로 하지 않기 때문에 기능의 정상 작동이 보장되지 않습니다.

그리고 이렇게 쑤셔넣은 기능들은 쉽사리 바꾸기 쉽지 않습니다. 왜냐하면 예전 소스들을 다 고쳐야하는 상황이 올 수 있기 때문입니다.² 이러한 부담은 결국 회사 입장에서도 부담이기 때문에 프레임워크를 고치기보다는, 해당 케이스에서만 쓸 수 있는 임시 변통을 쓰게 됩니다. 예외를 위해 if 구문으로 도배된 비대 함수가 만들어지거나, 아니면 그냥 서비스마다 형태는 엇비슷하지만 사실 다르게 개조된 프레임워크 소스를 쓰게 됩니다.

프레임워크를 만든 당초의 취지는 어디론가 사라지고 나쁨만이 남습니다.

사내 프레임워크의 죄.

이런 질문을 받을 수도 있겠군요.

“그렇게 되면 뭐가 나쁜데요?”

사내 프레임워크는 갈수록 죄를 짓게 됩니다. 개발자를 위해 만든다면서 개발자를 더 힘들게 만듭니다.

보통 사내 프레임워크는 문서화, 테스팅이 잘 안됩니다. 빨리 상품을 만들어서 넘겨야하는 입장에서 프레임워크로 중복작업을 줄이는 것이 목적이기 때문에 문서화 같은 사후를 위한 부분들은 보통 뒷전으로 밀려나게 되기 때문입니다. 처음 만들 때 문서화를 잘 했더라도 추후에 기능을 추가 할 때는 (급하기 때문에) 못할 가능성이 높습니다. 테스팅도 마찬가지입니다. 아예 테스팅을 하지 않거나, 초기에 개발된 기능들만 테스트 대상에 들어있을 뿐이게 됩니다.

이렇게 된 상태에서 누군가 유지보수를 위해 투입되면 무슨 일이 벌어질까요? 문서가 없거나 도움이 안되는 상황이기때문에 결국은 프레임워크 소스를 뜯어보게 됩니다. 시간을 줄이기 위해 존재했던 프레임워크가 시간을 더 잡아먹기 시작합니다. 그리고는 ad-hoc한 동작들을 위해 프레임워크에 무언가 덧대여지는 경우도 허다해집니다. 프레임워크가 더 나빠집니다.

그래도 사내 프레임워크의 발전(?)과정을 계속 겪어온 사원들에겐 양반입니다. 신입사원의 경우는 어떨까요? 처음부터 모든 동작을 이해하기 위해 소스를 다 뜯어봐야 합니다. 열심히 읽은 복잡한 메소드의 구현이 사실은 지금은 별로 안 쓰이는 부분일 수도 있습니다. 신입 교육의 난이도 및 시간을 증가시킵니다.

은탄환은 없다.

이 문제는 사실 첫 단추를 잘못 끼웠기 때문에 발생합니다.

모든 문제를 해결해주는 은탄환은 존재하지 않습니다.

개발을 하려면 적재적소에 적당한 소스를 넣어야 합니다. 하지만 사내 프레임워크의 최종 목표는 은탄환이라는 불가능한 꿈이기 때문에 언제나 점점 나빠집니다.

이 문제는 두 가지 문제 의식을 가져야 탈출이 가능한데, 첫째로는 무조건 덧대여 만드는 게 빠르다는 의식을 버리는 것이고, 둘째로는 프로그램이 녹이 슨다는 사실을 인정해야 하는 부분입니다.

누더기.

녹이 슨다는 부분에 대해서는 글을 인용했는데, 덧대어 만드는 쪽은 어떤지 적어봅니다.

덧대어 만든다는 것은 사실 프로그램의 본 취지에서 벗어난 기능을 추가하는 경우일 수 있습니다. 가령 환율 계산기를 만들었는데, 국가명을 번역하는 기능을 추가로 넣어야 한다면 그 것은 프로그램의 본 취지를 벗어난 기능일 가능성이 큽니다. 그렇게 덧대고 덧대고 또 덧대서 만들어진 프로그램은 공룡이 아니라 누더기일 뿐입니다.

멋진 옷이 필요한데, 누더기를 기반으로 땜질을 하는게 빠를까요? 아니면 처음부터 만드는게 빠를까요?

탈출구는?.

오픈 소스로 배포해서 고인 물이 아닌 흐르는 물이 되게 하는 것은 훌륭한 대안입니다. 하지만 사내 프레임워크가 만들어지는 경우엔 대부분 소스를 공개할 수 없는 경우가 많을 것입니다. 그 소스만 있으면 누구나 사업을 똑같이 할 수 있다던가 하는 문제점이 직면하겠죠.

이 문제를 해결하려면 결국 내부적으로라도 오픈 소스처럼 더욱 명확하게 문서화를 하고, 더욱 꼼꼼히 테스팅과 CI를 하며, 필요에 따라 리팩토링을 해서 스스로 정화가 되게끔 해야합니다. 하지만 이것은 사내 프레임워크를 만드는 흐름과는 반대되는 움직임입니다.

저 개인적으로는 보다 나은 생산성을 위한 투자라고 생각하면 어떨까 생각하지만, 이러한 투자를 싫어하는 회사도 많을 것입니다. 무엇이 절대적으로 옳다고는 말할 수 없지만, 답을 내야하는 문제라는 것은 명확합니다.

제가 할 수 있는 말은 구글의 Code of Conduct로 유명한 이 한마디가 아닐까 싶습니다.