들어가며
오늘은 조금 원론적인 이야기를 해보려고 합니다. 그동안 안드로이드 개발자로 활동하면서 MVC부터 MVVM, MVI까지 다양한 아키텍처를 적용해볼 수 있었습니다. 각 아키텍처마다 고유한 장단점이 있었고, 저에게는 매우 소중한 경험이었습니다.
최근 버그 수정과 기능 개발 과정에서 여러 고민을 하던 중, 다시 한번 아키텍처에 대해 깊이 생각해보게 되었습니다. 이번 글에서는 개발자들이 흔히 말하는 아키텍처란 무엇인지, 그리고 정말 꼭 필요한 것인지에 대한 개인적인 생각을 정리해보겠습니다.
아키텍처, 정말 필요할까?
아키텍처는 결국 앱의 전체적인 뼈대와 같습니다. 하지만 이것이 항상 필요할까요?
조금 극단적으로 말하자면, 비즈니스 관점에서 아키텍처가 없어도 문제없는 경우가 있다고 생각합니다. 예를 들어보겠습니다.
앱의 규모가 크지 않고, 매출이 잘 나오며, 혼자 운영하는데 특별한 문제가 없다고 가정해봅시다. 앱의 변경사항이나 기획자, 대표의 요구사항도 많지 않습니다. 이런 상황에서 굳이 관심사가 분리되고 효율적인 아키텍처를 적용할 필요가 있을까요?
물론 적용해서 나쁠 것은 없지만, 제가 강조하고 싶은 가장 중요한 내용은 아키텍처를 목적 없이 무지성으로 적용하지 말자는 것입니다.
아키텍처의 진짜 목적
그렇다면 어떤 목적으로 아키텍처를 적용해야 할까요? 가장 큰 키워드는 바로 "유지보수"에 있습니다.
앞서 언급한 작은 앱이 성장했다고 상상해봅시다. 회사에 기획자와 디자이너가 늘어나고, 사업 구조가 다각화되면서 앱에 기능이 많아졌습니다. 그리고 개발자들도 점점 더 채용되었습니다.
앱의 코드가 늘어나는데 명확한 구조가 없다면 코드가 스파게티가 되겠죠. 예를 들어 어떤 기능에서는 뷰에서 처리하던 것을, 다른 기능에서는 네트워크 요청하는 곳에서 처리한다던지, 동일한 기능이 하나로 묶여서 관리되는 것이 아니라 여기저기서 덕지덕지 사용되는 상황이 발생합니다.
결국 어떻게 될까요? 전달받은 요구사항을 충분히 수행하지 못하거나, 하나의 기능을 처리하는 데 상당한 시간이 걸릴 것입니다. 그러다 보면 시장에서 속도가 뒤처져 도태되고, 기술력이 부족하다면 후발주자에게 따라잡히는 것은 시간문제입니다.
아키텍쳐의 필요성
이러한 문제를 해결하기 위해 아키텍처를 통해 앱을 설계해야 합니다. 보통 SOLID 원칙에 기반하여 아키텍처를 설계하게 되는데, 그렇게 되면 관심사가 충분히 분리되고 앱이 복잡하지 않게 각자 하나씩의 역할을 담당하며 변화와 확장에 유연해집니다.
이러한 역할 분담은 개발자들의 예측성을 높이게 됩니다. "이러한 기능 구현 요청이 들어왔으면 이쪽 레이어나 클래스에서 구현되겠구나"와 같이 말입니다. 그러면 코드 리뷰를 할 때도 이해도가 높아지고, 버그를 디버깅할 때도 속도가 빨라지며, 여러 개발자가 함께 일할 때도 충돌 확률이 낮아집니다.
규모가 커질수록 한 프로젝트에 추가되는 개발자가 많아질 텐데, 그들의 이해도를 높이고 문제가 생길 여지를 줄여야 할 것 입니다. 이러한 측면에서 아키텍쳐가 필요하게 되는것입니다.
사실 아키텍처라는 말이 건축에서 나온 것이니, 그렇게 생각해봅시다. 설계 도면 없이 덕지덕지 만들어놓은 건축물은 부실할 게 뻔하고 얼마 못 가서 무너질 것입니다.
소프트웨어도 마찬가지입니다. 적절하게 설계된 아키텍처는 앱의 안정성을 높이고 개발 속도를 빠르게 하는 기반이 될 것입니다.
아키텍처에 대한 흔한 오해들
첫 번째 오해: 구체적인 구현 코드가 있을 것이라는 생각
아키텍처에는 명확하고 구체적인 구현 코드가 있을 것이라고 생각하는 경우가 많습니다. 하지만 사실 아키텍처는 개념적인 부분이나 지침, 또는 철학에 가깝습니다. 조금은 추상적이라는 말입니다.
각 플랫폼이나 언어마다 세부사항은 달라질 수 있으며, 특히 같은 아키텍처를 사용하지만 회사 서비스의 특성에 따라서 많이 달라질 수 있는 것도 사실입니다.
아키텍처를 구현했을 때 코드에 대한 절대적인 정답은 없습니다. 다만 중요한 것은 해당 아키텍처를 공동으로 사용하는 팀 레벨에서 "명확한 개념과 룰"이 정립되어 있어야 한다는 점입니다. 어떠한 철학으로 아키텍처가 디자인되었는지 이해함으로써 프로젝트의 코드 설계 이해도가 높아질 수 있습니다.
두 번째 오해: 좋은 아키텍처를 적용하면 더 이상 변경이 없을 것이라는 생각
코드는 생명체와 같아서 요구사항으로 인해 새로운 코드가 추가되면 쑥쑥 자라납니다. 어떤 기능이 추가되었는지에 따라서 기존에 가져가던 룰과 철학을 다시 정립할 수도 있습니다.
예를 들어 기능 하나가 추가되는데, 그 기능이 들어가야 할 위치나 성격이 모호하다면 이를 아우를 수 있게 룰이나 철학에 약간의 수정을 통해 새로운 조정이 필요합니다. 정말 필요하다면 신규 아키텍쳐를 적용함으로써 전체적인 뼈대를 아예 수정해버릴 수도 있겠죠.
코드가 늘어나고 기능이 추가됨에 따라 아키텍처도 조금씩 변화를 거치면서 어떤 것이 가장 효율적이고 좋은 구조인가를 고민하면서 최적화하는 노력이 필요합니다.
세 번째 오해: 개발자는 아키텍처를 가장 우선시 해야한다는 생각
앞서 이야기한 것처럼 극단적으로 서비스가 잘되고 유지보수가 필요 없는 상황이라면 아키텍처 따위는 필요 없을지도 모릅니다. 하지만 우리는 개발자라는 역할을 가지고 있고, 이를 잘 수행하기 위해서 유지보수를 고려해야 하며, 이 때문에 아키텍처라는 개념을 도입해서 앱의 안정성과 성능을 챙겨야 합니다.
하지만 주객이 전도되어서 이러한 아키텍처를 종교처럼 떠받들고, 서비스나 유저가 우선되는 것이 아닌 코드나 구조, 운영 관점으로만 생각한다면 죽은 서비스가 되어버립니다. 애초에 회사의 프로덕트가 나온 이유를 생각해봅시다. 개발자로서 컨퍼런스에 발표하기 위해서가 아니라 유저에게 편의와 더 나은 서비스를 제공하려는 것이 목적이라고 생각합니다.
그리고 이론이 현실에 항상 알맞게 적용될수는 없습니다. 책에 적힌 이론과는 조금 다르고, 본인이 생각한 완벽한 설계와는 조금 떨어질지라도 유연하게 코드를 디자인 하여 요구사항을 만족시키는게 더 중요하다고 생각합니다.
물론 개발자라는 역할을 잘 수행하기 위해서는 이러한 부분을 잘 챙겨야 한다는 것은 이해하지만, 너무 극단적일 필요는 없습니다. 또한 개발자라는 역할이 반드시 개발만을 챙겨야 한다는 것도 오해 중 하나입니다. 기획자, 디자이너, 개발자가 맡은 역할을 조금씩 다를지라도 같은 회사의 구성원으로서 서비스를 더 나은 방향으로 발전시키는 것이 더 우선되어야 한다고 생각합니다.
마치며
마무리로, 최근에 테스트 코드 작성이나 서버드리븐 UI 등 필요에 의해서 MVI와 구글에서 추천하는 모던 앱 아키텍처가 아닌 클린 아키텍처를 적용하는 것에 대해서 고민하고 있습니다.
물론 클린 아키텍처를 적용하는 것은 표면적으로 좋은 것으로 보일 수 있으나, 마이그레이션하고 검증하는 과정이 매우 고통스러울 것입니다.
아키텍처를 변경함으로써 얻는 이익이 무엇이고, 현재보다 무엇이 좋아지는지 저조차도 이 고민을 깊게 한 다음 진행해야 할 것 같습니다. 그 시작으로 제가 생각하는 아키텍처의 개념에 대해서 정리해보고 싶었고, 이를 바탕으로 신규 아키텍처에 대한 장단점을 정리해볼 예정입니다.
여러분들도 단순히 "이게 좋다더라", "이걸 추천한다더라"보다는 어떤 점들이 좋고 내가 지금 필요하다고 생각하는 지점은 무엇이며, 신규 아키텍처가 어떤 부분을 해결해줄 수 있는지 고민해보고 접근, 적용해보면 많은 성장이 있을 것이라고 생각합니다.
아키텍처는 목적이 아닌 수단입니다. 더 나은 서비스와 유지보수를 위한 도구로서 현명하게 활용해보시기 바랍니다.
