<출처: freepik> 코드 재사용성에 대하여프로젝트를 진행하다 보면 특정 코드를 재사용하는 것에 대해 논의할 때가 많다. 그런데 항상 명확한 결론을 내지 못하고 끝낸 적이 많다. 왜 그럴까? 코드 재사용에 대한 의사결정은 간단해 보이지만 사실 많은 고민이 필요한 일이기 때문이다. 코드 재사용에 대한 논의에서는 종종 다음과 같은 이야기들이 오고 간다. 코드를 재사용할 수 있도록 만들어야 다른 팀, 다른 서비스가 이점을 얻을 수 있고 중복 코드 문제를 피할 수 있다.코드를 재사용하려고 해서는 안 된다. 복제를 하는 것이 좋은 선택이다. 재사용하려고 하면 분기 로직이 추가되는 등 오히려 복잡하게 꼬일 수 있다.다른 팀이 코드를 재사용 할 수 있도록 새로운 서비스를 만들어야 한다.기존 라이브러리를 재사용해야 할까? 아니면 자체 코드를 만들어야 할까?인증 로직은 모든 서비스에 동일하게 적용된다. 모든 서비스에서 재사용될 수 있도록 API Gateway에 추가해야 할까? 아니면 프레임워크로 만들어야 할까? 논의에 참여하는 사람들은 재사용이 정말 필요한지에 대해서는 의문을 제기하지 않는다. 대부분 재사용을 어떻게 실현할 것인지에 대해서만 이야기한다. “그냥 Copy & Paste 방식으로 합시다.”라고 말하며 확신하는 모습도 보인다. 반면 재사용에 대해 안 좋은 경험이 있는 사람들은 재사용성의 위험에 초점을 두고 시도하는 것 자체를 의심하는 경우도 있다. 재사용이라는 단어가 얼마나 가볍게 사용되는지, 우리가 재사용 여부를 결정해야 하는 횟수 대비 그것에 대해 얼마나 적게 이해하고 있는지를 보며 놀랄 때가 많다. 재사용에 대한 논의가 제대로 진행되려면 어떻게 재사용할 것인가를 결정하기에 앞서, ‘재사용이 정말 필요한 것인가?’, ‘재사용이 시도될 가치가 있는가?’를 고민해야 한다. 이번 글을 통해 그동안 필자가 경험을 통해 얻은 코드 재사용성에 대한 생각을 공유하고자 한다. 재사용성이란?<출처: 본인> 먼저 재사용 컴포넌트는 재사용을 가능하게 만드는 구성 요소이고, 공개 메소드, 추상 클래스, 인터페이스, 라이브러리, 마이크로서비스 등이 될 수 있다. 클라이언트 컴포넌트는 재사용 가능한 컴포넌트를 사용하는 모든 코드 엔티티이다. 재사용 메커니즘은 컴포넌트를 재사용 할 수 있는 방법이다. 예를 들어 상호 간 통신을 위한 API 혹은 라이브러리를 의미한다. 재사용성은 특정 기능을 두 번 이상 사용할 수 있는 가능성이다. 간단한 개념이지만 기능의 목적, 호환성 등과 같은 고려 사항을 수반한다. 재사용 가능하면 다양한 상황, 환경에서 사용할 수 있다.재사용 가능성이 낮으면 다양한 상황, 환경에서 사용할 기회가 적어진다.재사용을 많이 할수록 더 많은 목적을 달성하는 데 사용할 수 있다.재사용 가능성이 낮으면 더 많은 목적을 달성하는 데 사용하기 어렵다. 여기서 목적이 중요하다. 어떤 기능은 모든 상황에서 유효하지 않을 수도 있고, 때로는 본래의 목적과 다르게 사용될 수도 있다. 결국 우리가 어떤 기능을 만들 때 그 기능을 사용할 수 있는 목적의 수는 재사용 가능성에 비례하며, 반대의 경우도 마찬가지라는 결론을 내릴 수 있다. 재사용성을 염두에 두고 설계할 수도, 아닐 수도 있다. 재사용이란?재사용은 처음에 설계된 것과 다른 목적으로 코드를 사용하는 것이다. 위에서 언급한 재사용성과의 구분은 다음과 같다. 재사용성: 기존 시스템에 추가적인 기능을 덧붙이거나 수정하여, 기존 시스템을 그대로 사용할 수 있는 능력재사용: 기존 시스템에 추가적인 기능을 덧붙이거나 수정하여, 기존 시스템을 사용하는 행위 재사용성은 재사용을 촉진하고 가능하게 하지만 실행을 보장하지 않는다. 또한 재사용을 촉진할 때 몇 가지 부정적인 영향이 나타날 수도 있다. 분석 및 설계 오버헤드사용자 및 비즈니스 분석가의 참여 증가IT 솔루션의 복잡성 증가플랫폼 및 인프라 요구 사항 증가비용 및 구현 시간 증가 거버넌스 복잡성관료주의 및 문화적 저항 증가IT 솔루션 수명 주기 및 복잡성 증가관리 도구에 대한 요구 사항 증가프로세스 및 복잡성 증가 이처럼 재사용이 간단한 개념으로 보일 수도 있지만 재사용성을 재사용으로 전환하는데 필요한 정책이나 기준이 없어, 섣불리 재사용을 시도했다가 실패할 가능성이 높다. 재사용에 실패하면 기존에 재사용성을 높여 개발한 부분이 매몰 비용으로 전환된다. 이것이 반복되다 보면 결국 외부와 소통하지 않아 침체되는 사일로(Silo) 전략에 빠지고 만다. 물론 재사용의 부정적인 영향도 배제할 순 없겠지만, 재사용성에서 재사용으로 가려면 어떻게 해야 할까? 다음 예시를 통해 알아보자. <출처: unsplash>펜이 놓인 책상 앞에 한 사람이 앉아있다. 이 사람은 서명 업무를 수행 중인 A다. 누군가 방으로 들어와 A에게 문서에 서명해달라고 요청한다. A는 펜을 들고 서명한 다음 문서를 건넨다. 한 시간 후, 다른 사람이 들어와 A에게 서명을 요청한다. A는 일부 내용을 수정한 뒤 서명한다. 이러한 업무는 이후에도 계속 반복된다. ~~ 중간 생략 ~~ 그러던 어느 날 A는 책상 서랍에서 인감을 발견하여 더 쉽게 문서에 서명할 수 있게 됐다. 그 이후 A는 펜을 치우고 책상 위에 인감을 올려두었다. 위의 예시를 보고 다음과 같은 질문을 할 수 있다. A는 인감이 그곳에 있다는 것을 알고 있었을까?A는 인감을 사용할 수 있었나?A가 인감을 사용할 수 있게된 이유는?A는 계속 인감을 사용했을까? 인감은 재사용성이 있다. 문서 종류에 상관없이 ‘서명’이라는 기능을 수행할 수 있기 때문이다. ‘인감’을 ‘재사용 가능한 기능’이라고 바꿔보자. 위 질문은 재사용 가능성이 있는 기능을 실제 재사용할 때, 우리가 고민해야 하는 것들이다. 재사용을 위해 위 질문들을 동일한 순서로 고려해보자. 1. A는 인감이 그곳에 있다는 것을 알고 있었을까?어떤 기능을 재사용하는 것이 옳은지, 아닌지를 논쟁하기에 앞서 어디서 찾을 수 있는지, 어떻게 사용할 수 있는지부터 알아야 한다. A씨의 경우 인감을 어디서 찾을 수 있는지, 인감이 서명을 대체할 수 있는지부터 알아야 한다는 것이다. 그렇지 못하면 다음과 같은 일이 발생한다. 재사용 가능한 기능이 있다는 것을 모른다면 사용하지 못할 것이다.재사용 가능한 기능을 어디서, 어떻게 찾을 수 있는지 모른다면 사용하지 못할 것이다.재사용 가능한 기능의 특성을 명확하게 파악할 수 없다면, 그 기능이 현재 요구사항을 충족하는지 알 수 없으므로 사용하기 힘들 것이다.재사용 가능한 기능에 접근하는 방법을 모른다면 사용하지 못할 것이다. 위와 같은 문제를 해결하기 위해선 어떻게 해야 할까?1) 기능 및 기술 문서가 위치하는 장소를 표준화한다.2) 다양한 유형의 기능들을 효과적으로 발견, 이해하는데 필요한 메타데이터를 표준화한다.3) 위에서 언급한 메타데이터를 업로드할 수 있는 공간을 설정하고, 이에 대한 검색이 가능하게 한 후, 연관된 링크를 제공한다. 2. A는 인감을 사용할 수 있었나?인감이 있었다는 것을 알았다면 사용할 수 있는 상태인지 확인해야 한다. 기능의 재사용을 촉진할 때 가장 위험한 것 중 하나는 사용 가능한 상태인지, 예상되는 수요에 준비되어 있는지이다. 특정 기능이 재사용 후보로 식별되었지만, 시간이 흐른 후에도 예상대로 작동할 거란 보장은 없다. 예를 들어, 인감이 닳아서 제 기능을 못할 수도 있다. 3. A가 인감을 사용할 수 있게 된 이유는?처음에는 책상 서랍에 인감이 있다는 사실을 몰랐기 때문에, 펜으로 서명할 수밖에 없었다. 어느 날 서랍에서 인감을 발견한 후 더 쉽게 서명할 수 있게 되었다. 4. A는 계속 인감을 사용했을까?A의 목적이 문서에 쉽게 서명하는 것이라면 인감을 사용하지 않을 이유가 없다. 만약 이유가 있다면 재사용 가능한 것을 재사용하지 못하게 하는 요인은 무엇일까? 결국 재사용은 선택의 문제다. A는 인감을 사용하지 않기로 결정할 수도 있다. 다만 펜을 이용한 서명보다 인감을 찍는 것이 더 쉽기 때문에 인감을 사용하기로 결정했다. 만약 문서마다 인감에 변화를 줘야 했다면, 그냥 펜으로 서명하는 것을 택할 수도 있다. 즉, 큰 변화 없이도 사용이 가능해야 재사용성을 촉진할 수 있다. 애플리케이션을 설계할 때 대부분 재사용 가능성을 높이는 방향으로 진행한다. 그리고 많은 곳에서 재사용 되길 바란다. 그러나 시간이 지나면서 여러 기능이 추가되어, 처음 목적과는 다르게 변화하다 보면 오히려 재사용 가능성이 낮아진다. 여기서 ‘불가지론’ 개념을 적용해 볼 수 있는데, 불가지론이란 인간이 알 수 없는 것이나 진위 여부를 확실히 알 수 없는 것에 대해 철학적으로 접근하는 것을 말한다. 이 개념을 적용하면 어떤 것이 불가지론적일수록 그것은 다양한 그룹과 호환되기 쉬워진다는 것이다. 예를 들어, 자바는 다양한 운영체제와 호환되기 때문에 매우 유용하게 사용될 수 있다. 비슷하게 망치는 다양한 못과 함께 사용할 수 있기 때문에 많은 사람들이 사용한다. 계산기도 마찬가지로 다양한 연산 작업과 함께 사용할 수 있다. 이러한 개념은 기능 설계에도 적용될 수 있다. 기능 설계가 불가지론적일수록 해당 제품이 다양한 목적과 호환될 가능성이 높아진다. 초기 목적이 불가지론적일수록 제품은 다양한 목적에 맞게 재사용될 수 있을 것이다. 따라서 제품의 재사용 가능성은 초기 설계의 불가지론적 성격에 비례한다는 것을 의미한다. 재사용의 경제성그렇다면 특정 상황에서 재사용 여부는 어떻게 결정할 수 있을까? 재사용이 좋은 선택인지 추정할 방법이 있을까? 재사용 여부를 결정하는데 유용한 방법은 경제적 측면에서 생각해 보는 것이다. 재사용 효용 = 재사용으로 인해 절약된 비용 - 재사용 비용재사용으로 인해 절약된 비용 = 재사용 가능한 컴포넌트를 사용하여 팀이나 개발자가 절감한 비용재사용 비용 = 담당팀이 재사용 가능한 기능을 만들고 유지 관리하는 비용 재사용 함으로써 절약할 수 있는 비용이 재사용 가능한 기능을 만들고 관리하는 비용보다 크다면 재사용 효용이 (+)이므로 재사용을 시도할 가치가 있다. 하지만 계산이 생각보다 쉽지 않다. 아래 요인들이 포함된 비용을 추정해야 하기 때문이다. 재사용 비용 요인재사용 가능한 클라이언트 수재사용 가능한 기능 변경 영향도재사용 가능한 기능 변경 빈도재사용 가능한 기능이 회사 전체에서 일관되게 작동될 것인지매뉴얼이 잘 되어 있는지인터페이스가 안정적인지 위의 요소들을 모두 고려하며 재사용 비용을 추정하긴 어려울 것이다. 그러나 경제성 관점에서 재사용 여부를 판단해 보는 것은 중요하고 실효성이 높다. 그래서 재사용 여부를 경제성 관점에서 판단하는 데 도움이 될 수 있는 시나리오를 소개한다. 시나리오 1. 경제성이 별로 없다우리가 만든 기능을 2~3명의 소수 사용자가 사용 중이다. 이 경우 재사용성을 위해 노력하는 것이 맞는지 고민될 것이다. 개인적인 만족도를 위해 재사용 가능한 기능을 만드는 것은 욕심이다. 쓸모없는 재사용 컴포넌트를 만드는 것은 일을 더 복잡하게 만들 수 있다. 시나리오 2. 경제성이 있는지 모르는 경우우리가 만든 기능을 20개 이상의 클라이언트가 사용한다. 인기가 많아져서 다른 프로젝트에서도 사용할 수 있도록 마이크로서비스로 제공할 것을 담당자가 제안했다. 재사용성을 염두에 두고 만들었지만, 시간이 지남에 따라 클라이언트의 요구사항도 늘어난다. 요구사항을 충족시키기 위한 분기가 추가되어서 유지 관리 및 통합 비용이 많이 드는 상황이다. 애초에 간단한 기능으로 클라이언트마다 개발했다면, 재사용 서비스의 전담팀을 유지하는 비용보다 전체 비용이 저렴하지 않았을까? 새로운 요건에 대해 클라이언트팀을 조정하는 시간 비용이나, 재사용성의 복잡성 때문에 발생하는 버그를 전담팀이 처리해야 하는 비용은 얼마일까? 시나리오 3. 경제성이 있다우리가 만든 기능이 재사용되며 많은 유지 관리가 필요하지 않다. 이 시나리오는 Win-Win 시나리오다. 1) 재사용 가능한 컴포넌트는 매우 안정적이기에 유지 관리에 많은 시간이 필요하지 않다. 2) 라이브러리 및 인터페이스 확장 매커니즘이 훌륭하여, 클라이언트가 새로운 것을 필요로 할 때마다 재사용 가능한 컴포넌트를 변경하지 않고도 대부분 사례를 충족한다. 3) 매뉴얼이 매우 잘되어 있기에, 사용 방법을 알기 위한 회의를 하지 않아도 된다. 스프링 프레임워크나 리액트의 경우, 전 세계적으로 많은 개발자가 사용하고 있지만 이를 개발하고 유지하는 그룹은 재사용하는 사람의 수보다 훨씬 적다. 마지막으로 재사용에 대한 최종 의사결정을 할 때, 다음 내용들을 잘 확인해보자. 재사용성을 고려해야 하는 경우리팩토링: 여러 곳에 중복된 코드가 있고, 중복을 피할 수 있는 추상화를 찾을 수 있다면 재사용 가능한 컴포넌트가 있는 것이다.재사용할 로직이 매우 복잡하고 전문화되어 있는지 확인한다. 예를 들어 암호화 기능을 각각 만드는 것은 좋은 생각은 아니다.비즈니스 로직이 자주 변경되고 변경될 때마다 여러 시스템을 변경해야 할 경우 재사용성을 의심해야 하는 경우재사용 가능한 컴포넌트가 제공하는 기능이 필요하지 않을 경우. “나중에 필요할 것 같다.”라는 막연한 생각은 지양한다.사용하고자 하는 클라이언트가 거의 없는 경우새롭게 만드는 것에 대한 공수가 많이 들지 않는 경우재사용 가능한 기능을 소유한 팀과 많은 커뮤니케이션을 해야 하는 경우해당 기능이 재사용 가능한지 알 수 없는 경우 지금까지 필자가 생각한 재사용성에 대해 살펴보았다. 하나 강조하고 싶은 것은 코드 재사용은 일반적으로 자주 얘기하는 것에 비해 가볍게 실행할 수 있는 개념은 아니라는 것이다. 그러니 조직 상황에 맞게 다양한 이해관계자들이 심사숙고하여 결정하는 것이 중요하다. 이번 글이 도움이 되길 바라며 글을 마친다. 글 주길재편집 김상현 객원 에디터 ©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
