기술 부채와 오버 엔지니어링을 줄이는 방법

소프트웨어 개발자는 해결해야 할 문제를 정확하게 정의하고, 다양한 솔루션을 검토한 후, 현재 상황(규모, 자원, 비즈니스)에 적절한 엔지니어링 수준을 의사 결정을 해야합니다. 애플리케이션 구현 기술 (라이브러리, 프레임워크, 도구 및 프로세스), 인터페이스 (API 및 게시된 계약), 의존성 (구성 요소 결합), 시스템 (아키텍처 패턴) 및 비기능적 요구 사항 (보안, 고가용성 및 내결함성) 등 다양합니다.

하지만, 현실에서는 장기적으로 더 나은 방식 보다는 대신 쉬운(제한된) 솔루션을 채택할 수 밖에 없고, 향후에 추가적인 리팩토링이 일어날 수 있습니다. 이를 소위 기술 부채 (Technical Debt)라고 부릅니다. 기술 부채는 소프트웨어 개발 초기의 피봇 단계에서 많이 만들어지며, 제품이 성숙한 단계로 나아가는 동안 디자인 개선 노력을 통해 줄여 나가야 합니다.

기술 부채 중에는 오히려 지금 필요한 것 보다 더 과하게 만드는 오버엔지니어링(Over Engineering)도 있습니다. 밖에서 뜬다는 기술이나 대형 IT 기업들의 자사 방법론을 맹목적으로 수용하는 경우도 있구요. 외부에서 영입된 의욕이 넘치는 사람이 독단적인 결정을 하기도 합니다.

저도 호기심이 많은 개발자라서 근 20년간 Ajax, HTML5, 오픈 API, 마이크로서비스, 카오스 엔지니어링 같이 비교적 새로운 기술 개념을 꾸준히 소개해 왔습니다. 새로운 기술 주제를 설명할 때, 탄생 배경과 동기 그리고 풀려는 문제를 설명하고자 꾸준히 노력하지만, 소위 남귤북지(南橘北枳) – 즉, ‘남쪽 땅의 귤나무를 북쪽에 옮겨 심으면 탱자나무로 변한다’라는 사자성어와 같이 전혀 다르게 이해하거나 적용하는 경우도 많이 보았습니다.

그렇기 때문에, 누군가 “요즘 OOO가 뜨고 있데요. 우리도 도입해봐요.”라고 말한다면, 일단 마음으로 의심부터 하세요. 다만, 무턱대고 “그거 오버엔지니어링 아니에요?”라고 말하지는 마세요. 기술에 대해 허심탄회한 토론을 하며 꾸준히 배우려는 소통을 막는 것은 바람직하지 않으니까요.

그렇다면, 개발 조직의 구성원들과 아키텍처 시스템 디자인을 할 때, 합리적인 의사 결정을 통해 기술 부채와 오버엔지니어링의 위험을 피하기 위해 어떻게 해야 할까요?

1. 기술 의사 결정 과정을 기록하세요.

만약, 여러분의 회사에서 다음과 같은 패턴을 보인다면, 기술 부채가 계속 쌓이면서 오버 엔지니어링이 일어날 가능성이 높습니다.

• 해결할 문제와 솔루션에 대한 충분한 검토없이 기술 도입을 결정한다.
• 잘못된 선택이나 변화에 대한 두려움 때문에 필요한 결정을 하지 않는다.
• 의사 결정 과정이 투명하지도 추적되지도 않아 중복된 논의가 계속 된다.

의외로 의사 결정이 투명하지도 기록하지도 않는 회사가 많습니다. 이를 해결하는 것이 바로 ‘아키텍처 결정 기록 (Architectural Decision Records, ADR)’ 프로세스 입니다. ADR은 소프트웨어 아키텍처에 필요한 구성 요소에 대한 의사 결정, 동기 및 맥락 및 그리고 결과에 대해 설명하는 간단한 문서입니다. 기업 규모와 관계 없이 개발팀이 꾸려져 있다면 반드시 있어야 합니다. 이를 통해 동일한 기술 주제에 대한 반복적인 토론을 방지하고, 기존 직원 혹은 신규 입사자에게 기술 도입 과정을 효과적으로 전달할 수 있습니다.

예를 들어, “왜, RDB가 아니라 NoSQL을 선택했는지, 왜 구현 방법으로 Amazon DynamoDB를 선택했는지”, “왜 쿠버네티스를 선택했는지, 왜 운영 방법으로 Amazon EKS를 선택했는지”, “왜, API의 도메인 범위를 이렇게 나누었는지” 등등 각 의사 결정 사항을 ADR 문서로 저장합니다. ADR 문서는 다양한 모범 템플릿이 존재하는데, 보통 ‘문제에 대한 정의’, ‘의사 결정에 대한 동기 및 맥락’, ‘최종 결정 사항’, ‘예상 결과’, ‘결정 참여자’ 등의 항목을 짧더라도 구체적으로 담아야 합니다.

각 ADR 문서는 상황에 따라 새로운 의사 결정으로 변경될 수 있기 때문에, 마치 프로그램 코드와 같이 지속적으로 업데이트해야 합니다. 따라서, 이슈/티켓 시스템 보다는 소스 콘트롤을 이용해서 ADR 템플릿에 따라 마크다운으로 작성한 후, 지속적으로 변경관리를 하는 것이 좋습니다. ADR의 주체는 팀장이 아니라 모든 개발자입니다. 마치 소스 코드처럼 누구나 ADR 문서를 만들고, 동료 리뷰를 받는 과정을 거치는 것이 좋습니다.

더 자세한 것은 AWS ADR 가이드라인, ADR GitHub 리포지터리 등을 참고하시기 바랍니다. ADR을 도입하고 적용하는데 필요한 각종 템플릿, 예제, 개발자 도구 등을 제공하고 있습니다.

2. 해결하려는 문제를 정확히 파악하세요.

ADR에서도 언급했지만 기술 의사 결정을 내릴 때 가장 먼저해야 하는 것은 우리가 가진 문제가 무엇인지 정의하는 것입니다. 각 회사마다 비지니스가 다르고, 구현 기술이 다르고, 보유하고 있는 인력과 자원이 다릅니다. 따라서, 직접 만들어 보지 않는 이상 딱 들어맞는 기술을 찾는다는 건 사실상 미신에 가깝습니다.

우리가 문제를 정확히 정의해야 하는 이유는 모든 SW 기술과 도구는 해결하려는 특정한 문제와 배경, 구현 동기가 있기 때문입니다. 예를 들어, NoSQL이라는 기술은 아마존이 만든 Dynamo라는 장바구니 시스템에 쓰는 DB 기술에서 나왔습니다. Amazon DynamoDB 10주년 기념글에 따르면, 2004년 연말 쇼핑 시즌 동안 아마존 닷컴의 장애가 있었습니다. 대부분의 데이터베이스 시스템은 읽기가 95%이고 변경이나 삭제가 5% 정도 되기 때문에 관계형 데이터베이스(RDB)로도 충분하지만, 아마존닷컴의 장바구니는 그 반대로 쓰기가 많았기(Write-heavy) 때문에 장애가 날 수 밖에 없었죠.

당시 한 20대 인턴은 이 문제를 해결하기 위해, Dynamo라는 비관계형 키 값 데이터베이스를 만들고 장바구니에 쇼핑 아이템을 효율적으로 추가 혹은 변경해야 하는 문제를 풀 수 있었습니다. 그 이후, 많은 오픈 소스 기반 NoSQL 솔루션이 탄생하였고, 웹 2.0 붐과 아울러 쓰기 수요가 많은 소셜 네트워크 서비스 등에서 앞다투어 도입을 하기 시작했습니다.

그러다 보니, 다른 방식으로 현재 문제를 충분히 풀 수 있는데도 불구하고, 무턱대고 NoSQL 저장소를 사용하는 경우도 많이 보았습니다. 예를 들어, 매일 발생하는 대량 로그 처럼 일회적인 쓰기 사용량은 높다고 해서 NoSQL을 선택하는 경우인데요. 쓰기 이후에도 읽기나 분석 요구가 많기 때문에 간단한 파일 저장소나 Elasticsearch 같은 다른 솔루션을 고려할 필요가 있습니다. 망치를 손에 들면 모두 못으로 보이게 마련이기 때문에 조심해야 합니다.

즉, 해결하려는 문제에 대해 정의를 내리고, 도입하려는 기술에 대한 동기와 맥락을 정확히 알아야만 올바른 의사 결정을 할 수 있습니다. 해당 기술이 나오게 된 맥락을 파악하려면, 만든 사람에게 물어보는게 가장 빠릅니다. 또는 그 사람이 쓴 책이나 강연, 혹은 논문을 찾아서 읽어 보는 것을 권장합니다.

3. 문제 해결 기술 후보를 선정하고 테스트 하세요.

우리에게 맞는 솔루션인 하나가 아닐 수 있습니다. 따라서, 몇 가지 후보를 선택하고 이를 테스트한 후, 나온 결과를 보고 선택해야 해야 합니다. 요즘에는 대부분 IT 기업들이 클라우드 컴퓨팅 활용이 보편화 되면서, 요구 사항에 맞는 솔루션들이 모듈화되어 나오는 경향이 있습니다. 손쉽게 사용해 볼 수 있는 클라우드 서비스가 늘어나면서 테스트해 볼 수 있는 기술 선택의 폭도 넓어졌습니다.

예를 들면, 회사 규모가 커지고 개발 배포 및 유지 관리 생산성이 높이기 위해 ‘쿠버네티스 (Kubernates) 기술’을 도입하는 것을 고려하고 있다면, 우선 컨테이너를 실행할 수 있는 다양한 선택지를 찾아봐야 합니다. 어떤 클라우드 전문가 분은 AWS에서 컨테이너를 돌릴 수 있는 옵션이 무려 17가지나 된다고 합니다.

즉, 서비스 규모에 따라서, 컨테이너의 실행 위치 및 방식, 아키텍처 방식(예: 마이크로서비스인 경우)에 따라서 정말 다양한 컨테이너 선택 후보가 존재합니다. 사용자가 수 천명도 안되는 소규모 서비스에 컨테이너를 운영하고 싶다면, Amazon Lightsail이나 AWS Fargate (ECS) 같은 서비스를 이용해도 되는데, 쿠버네티스 클러스터를 도입하는 오버 엔지니이링을 하면 안되겠죠.

데이터베이스의 경우, 애플리케이션 사용 사례를 중심으로 특정 요구 사항에 적합한 클라우드 DB가 많이 나와 있습니다. 예를 들어, 콘텐츠나 카탈로그 관리는 문서 DB인 Amazon Document DB, 소셜 네트워킹 서비스에는 그래프 DB인 Amazon Neptune, 그리고 은행 거래같은 원장 관리는 Amazon QLDB 같은 걸 쓰는 식이죠.

어떤 측면에서 보면, 다양한 클라우드 서비스와 레고 블럭 같은 손쉬운 구현 편의성 때문에 아키텍처 디자인이 더 쉬워진 측면도 있습니다. 원하는 기술 후보를 테스트를 하고, 결과에 따라 도입 여부에 대한 의사 결정을 더 빨리 할 수 있는 장점도 있습니다. 따라서, 기술 도입 판단 과정에서 클라우드를 기반으로 테스트를 해보는 것도 좋습니다.

마지막으로… 가끔 오버엔지니어링 처럼 보이는 것이 필요할 때도 있습니다. 예를 들어, 시스템 보안이나 개인 정보 보호 같은 영역은 법적인 규정 준수 문제들이 있기 때문에 현재 가지고 있는 것 보다 더 많은 고려가 필요합니다. 팀 내 기술 인력의 여유가 있고, 업무 일정에 영향이 없을 때는 다양한 기술에 대해 실험적인 프로토 타이핑을 하는 것도 좋습니다.

지금까지 시스템 아키텍처 설계 시, 기술 부채와 오버엔지니어링을 줄이는 모범 패턴을 알아보았는데요. 회사 내에서 기술 의사 결정 과정을 기록하는 프로세스를 꼭 만들고, 의사 결정할 때 마다 가지고 있는 문제를 정확히 파악하여 기술 후보를 선정하여 (가급적 클라우드 서비스를 활용하여 빠르게) 테스트하는 것을 권장합니다. 회사 마다 규모와 인력, 만드는 서비스가 다 다르지만, 이 정도의 의사 결정 문화만 잘 갖춘다면 더 좋은 서비스 아키텍처를 만들어 나갈 수 있을 것입니다.

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)