아키텍처는 트레이드오프의 기술이다
28개 언어로도 제공
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 4/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 가역성 테스트 · 다음: 오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라.
이 모듈이 답하는 질문: 여러 해법이 모두 통할 수 있을 때, 아키텍트는 어떻게 고르고 그 선택을 어떻게 설명할까요?
아키텍처가 그저 정답을 찾아내는 일이라면 훨씬 쉬울 것입니다. 플랫폼을 배우고, 패턴을 배우고, 한계를 배우고, 맞는 것을 고르면 끝.
실제 아키텍처는 그렇게 돌아가지 않습니다. 어려운 결정은 보통 분명히 좋은 해법과 분명히 나쁜 해법 사이에 있지 않습니다. 통할 수 있는 여러 해법 사이에 있고, 각각 장단점이 있으며 각각 아키텍처를 조금씩 다른 방향으로 끌고 갑니다. 아키텍트가 회의 테이블에 앉을 자격을 얻는 곳이 바로 거기입니다.
문제를 푸는 많은 방법
섹션 제목: “문제를 푸는 많은 방법 ”아키텍트를 가르칠 때 이 예시를 여러 형태로 자주 써 왔습니다.
Salesforce에서는 문제를 푸는 방법이 많을 수 있습니다. 가끔 숫자를 붙여 열 가지라고 말하지만, 그건 비유이지 셈이 아닙니다. 선택지 중 상당수는 처음부터 문제가 있습니다. 플랫폼 제약에 부딪히거나, 핵심 요구사항을 놓치거나, 받아들일 수 없는 보안이나 성능 문제를 만듭니다. 그런 것은 금방 제쳐 둘 수 있습니다. 다른 일부는 오늘은 작동하지만 데이터가 커지면 문제가 생깁니다. 기술적으로는 돌아가지만, 이미 오리라고 알고 있는 성장을 견디지 못합니다.
남는 것은 앞으로의 요구를 감당할 수 있는 소수의 선택지이고, 이제 흥미로워집니다. 각각이 작동하고, 확장되고, 요구사항을 충족할 수 있습니다. 그렇다면 무엇이 정답일까요? 어쩌면 전부입니다. 아키텍트의 일은 그 차이를 이해하는 것입니다.
선택 목록처럼 단순한 것조차 오늘은 작동하고 데이터가 커지면 문제가 생길 수 있습니다. 선택 목록은 사용자에게 편합니다. 하지만 값이 어디서 오는지, 몇 개까지 될 수 있는지 물어보십시오. 선택 목록은 값이 대략 20개 미만일 때 가장 잘 작동합니다. 미국 주처럼 가끔 50개까지 가고, 국가처럼 드물게 100개를 넘기기도 하는데, 그러면 다루기 불편해집니다. 그러니 모든 선택 목록에 대해 상한을 알아 두십시오. 그리고 선택 목록 값을 바꾸는 것은 데이터 변경이 아니라 메타데이터 변경입니다.
대신 조회 관계를 쓰면 사용자 인터페이스가 조금 복잡해집니다. 하지만 목록은 상한 없이 계속 늘어날 수 있고, 새 값이 연동을 통해 들어올 수도 있습니다. 그것은 사용성과의 트레이드오프입니다. 그것이 균형입니다.
최적은 완벽이 아니다
섹션 제목: “최적은 완벽이 아니다 ”저는 최적이라는 말을 조심해서 씁니다. 최적의 아키텍처란 개별 결정 하나하나가 완벽한 아키텍처가 아닙니다. 그런 아키텍처는 아마 존재하지 않을 겁니다. 전체 해법이 균형 잡힌 아키텍처입니다.
해법 A는 성능이 가장 좋지만 비싸고 유지보수가 어렵다고 해 봅시다. 해법 B는 비용이 적고 운영이 쉽지만 성능을 일부 포기합니다. 해법 C는 미래에 더 유연하지만 오늘 복잡성을 더합니다. 무엇이 최적일까요? 그 사실들만으로는 답할 수 없습니다. 비즈니스, 요구사항, 우선순위를 알아야 하고, 어떤 제약이 진짜이고 어떤 것이 선호인지 알아야 합니다. 아키텍처는 맥락에 따라 달라집니다. 그래서 한 고객에게 옳았던 패턴이 다음 고객에게는 완전히 틀릴 수 있습니다.
그리고 데이터 아키텍트로서 당신의 일은 이런 결정들의 균형을 잡는 것입니다. 그중 수십 개는 혼자서, 또는 팀과 함께 내리게 됩니다. 그게 어떤 결정인지 알고, 어떤 결정이 비용, 일정, 기능에 더 큰 영향을 줘서 핵심 의사결정권자에게 올라가야 하는지 아십시오.
최적이 아닌 결정이 최적의 아키텍처의 일부일 수 있다
섹션 제목: “최적이 아닌 결정이 최적의 아키텍처의 일부일 수 있다 ”이 장에서 가장 중요한 생각 중 하나입니다. 저는 때때로 아키텍처의 한 부분에서 알면서 최적이 아닌 결정을 내립니다. 그것이 전체 해법을 더 낫게 만들기 때문입니다.
중복을 없애면 불필요한 연동 복잡성이 생기니까 소량의 데이터를 중복시킬 수도 있습니다. 이론적으로 더 깔끔한 모델이 보고와 일상 사용을 훨씬 어렵게 만드니까 더 단순한 데이터 모델을 고를 수도 있습니다. 대안이 조직이 아직 운영할 준비가 안 된 인프라를 더하니까 약간의 성능 비용을 받아들일 수도 있습니다.
그중 하나만 따로 떼어 보면 최적이 아니라고 말할 겁니다. 맞습니다. 하지만 아키텍처는 각 구성 요소를 따로 최적화하는 것이 아니라 시스템을 최적화하는 것입니다. 국소적으로 최적이 아닌 결정도 전체적으로 최적인 아키텍처의 일부일 수 있습니다. 우리가 하는 트레이드오프를 이해하고 있다면요. 위험한 것은 트레이드오프를 하고 있다는 사실조차 모른 채 하는 것입니다.
무엇을 내주는지 알라
섹션 제목: “무엇을 내주는지 알라 ”누군가 “이게 최고의 해법입니다”라고 말할 때마다 제 다음 질문은 **“무엇에서 최고인가요?”**입니다. 가장 빠른가요? 가장 싼가요? 가장 단순한가요? 가장 확장성 있고, 가장 안전하고, 가장 유연한가요? 운영하기 가장 쉽고, 가장 빨리 제공되고, 전문 기술에 가장 덜 의존하나요? 거의 언제나 답이 “최고”가 아닌 다른 차원이 있습니다. 그것이 트레이드오프입니다. 저는 무엇을 얻는지 알고 싶고, 무엇을 포기하는지도 알고 싶습니다.
대량의 기업 데이터에 대한 두 가지 선택지를 보십시오. 하나는 데이터를 Salesforce에 복사합니다. 그러면 Salesforce 기본 기능을 쓰기 쉬워지지만, 이제 우리는 그것을 옮기고, 저장하고, 동기화하고, 또 하나의 사본을 보호하고, 지연을 감당해야 합니다. 다른 하나는 데이터를 제자리에 두고 필요할 때 접근합니다. 중복은 일부 없앴지만, 이제 가용성, 쿼리 성능, 네트워크 의존성, 원격 시스템의 역량이 더 중요해집니다. 어느 설명도 무엇을 골라야 하는지 말해 주지 않습니다. 어떤 질문을 던져야 하는지 말해 줍니다.
요구사항은 다 같지 않다
섹션 제목: “요구사항은 다 같지 않다 ”트레이드오프는 모든 요구사항의 무게가 같지 않다는 것도 보게 만듭니다.
누군가 “데이터가 즉시 사용 가능해야 합니다”라고 말합니다. 좋습니다, 즉시란 무엇을 뜻하나요? 1초, 10초, 1분? 그리고 왜죠? 초 단위가 중요한 사기 탐지일 수도 있습니다. 그냥 누군가 야간 적재를 기다리기 싫은 것일 수도 있습니다. 둘은 매우 다른 요구사항이고, 아키텍트는 우리가 어느 쪽인지 알게 될 때까지 계속 묻습니다.
저는 질문을 견디는 요구사항을 좋아합니다. 얼마나, 몇 개나, 얼마나 빨리, 얼마나 자주, 누구를 위해, 그리고 하지 않으면 어떻게 되는가? “빠르게”는 아키텍처 요구사항이 아닙니다. “고객 정보 갱신의 95퍼센트가 30초 안에 서비스 상담원에게 보여야 한다”는 그에 훨씬 가깝습니다. 이제 트레이드오프를 평가할 수 있습니다.
제약이 답을 바꾼다
섹션 제목: “제약이 답을 바꾼다 ”때로는 아키텍처가 기술에 전혀 제약받지 않습니다. 돈, 사람, 시간, 라이선스, 조직의 성숙도에 제약받습니다.
기술적으로는 훌륭하지만 회사에 없는 운영팀을 필요로 하는 아키텍처는 좋은 아키텍처가 아닙니다. 문제를 우아하게 풀지만 고객이 사지 않을 라이선스를 요구하는 기능도 해법이 아닙니다. 그리고 완벽한 3개년 혁신은 8주 안에 출시해야 하는 회사에 도움이 되지 않습니다.
그렇다고 마감 때문에 좋은 아키텍처를 포기한다는 뜻은 아닙니다. 무엇을 타협하는지, 왜 하는지, 어떤 결과를 받아들이는지 이해하고, 가능하면 오늘의 타협에서 내일의 아키텍처로 어떻게 갈지 이해한다는 뜻입니다.
아키텍트에게는 “최적”의 그림이 필요하다
섹션 제목: “아키텍트에게는 “최적”의 그림이 필요하다 ”흥미로운 긴장이 있습니다. 저는 완벽한 정답이 하나만 있는 경우가 드물다고 말하면서, 동시에 최적의 해법이 어떤 모습인지 머릿속에 그림을 갖고 다니기를 바랍니다. 둘은 모순이 아닙니다. 기준점이 필요합니다.
데이터 모델을 볼 때 저는 불필요한 제약 없이 요구사항에 맞춰 최적화할 수 있다면 무엇을 만들지 알고 싶습니다. 그런 다음 실제 제약이 우리를 그 설계에서 밀어낼 때(모델 일부를 평평하게 하고, 일부 데이터를 중복시키고, 연동을 미루고, 임시 수작업 프로세스를 받아들일 때), 저는 무작위로 타협하는 것이 아닙니다. 최적에서 어느 방향으로, 왜 멀어지는지 압니다. 그것이 아키텍처의 기술이고, 그 감각에는 연습이 필요합니다.
그려라
섹션 제목: “그려라 ”트레이드오프를 이해하는 가장 좋은 방법 중 하나는 그것을 그려 보는 것입니다. 아키텍처 다이어그램은 슬라이드 장식이 아니라 생각의 도구입니다. 두 접근 중에서 고른다면 둘 다 그리십시오. 데이터는 어디에 있고, 어디로 이동하는가? 누가 소유하는가? 경계는 어디이고, 보안은 어디서 시행되는가? 무언가 실패하면 어떻게 되고, 볼륨이 커지면 무엇이 바뀌는가?
다이어그램은 모호함을 드러내게 만들고, 모두에게 가리킬 수 있는 같은 그림을 줍니다.
한 공공 유틸리티 기업과의 프로젝트에서 그것이 얼마나 중요한지 배웠습니다. 검토를 거듭할 때마다 같은 개념을 다시 설명하고 대화를 원래 설계로 되돌리고 있는 저를 발견했습니다. 그래서 회의 진행 방식을 바꿨습니다. 모든 검토를 화면에 데이터 모델을 띄우고 시작했습니다. 모든 필드가 나오는 상세 모델이 아니라 요약 모델이었습니다. 계정에는 연락처가 있고, 이 레코드에는 하위 레코드가 있고, 작업은 여기에 매달린다. 회의실에는 주로 경영진이 있었고, 몇 분이면 충분했습니다.
회의마다 같은 사람들이었기 때문에 그 다이어그램이 우리의 공통 언어가 되었습니다. 사람들이 다이어그램의 이름을 쓰기 시작했습니다. 반복되던 질문이 줄었고 회의가 훨씬 수월해졌습니다. 저는 이것을 회의에 닻 내리기라고 부릅니다. 매번 보여 준 단순한 다이어그램 하나가 만드는 데 든 비용보다 훨씬 큰 가치가 있었습니다.
목표는 예술적 완벽함이 아닙니다. 엔지니어를 위한 상세 다이어그램일 때도 있고, 경영진을 위한 상자 다섯 개와 화살표 여섯 개일 때도 있습니다. 목표는 명확성입니다.
트레이드오프를 설명하라
섹션 제목: “트레이드오프를 설명하라 ”좋은 아키텍트는 순서대로 펼쳐 놓습니다. 우리가 검토한 선택지는 이것이고, 각각이 주는 것은 이것이고, 각각의 비용은 이것이고, 제가 추천하는 선택지는 이것이고, 그 이유는 이것입니다.
추천이 트레이드오프 다음에 온다는 점에 주목하십시오. 저는 아키텍처가 “전에 해 봤으니 믿으세요”가 되기를 원하지 않습니다. 경험은 엄청나게 중요합니다. 패턴을 더 빨리 알아보고 문제를 더 일찍 보게 해 줍니다. 하지만 경험은 추론을 개선해야지, 추론을 대신해서는 안 됩니다. 우리의 일은 아키텍처를 이해하는 데서 그치지 않습니다. 조직이 결정을 이해하도록 돕는 것입니다. 특히 최종 결정을 내리는 사람이 아키텍트가 아닐 때요.
Think Correct. Think Fast.
섹션 제목: “Think Correct. Think Fast.”모든 선택지를 분석할 3주가 늘 주어지지는 않습니다. 때로는 3분입니다. 회의 중에 요구사항이 바뀌고, 누군가 몰랐던 제약을 말하고, 경영진이 “내년에 유럽에서도 필요하면요?”라고 묻습니다.
저는 Think Correct. Think Fast.(올바르게 생각하라. 빠르게 생각하라.)라는 말을 써 왔습니다. 속도는 생각을 건너뛰는 데서 오지 않습니다. 그 순간이 오기 전에 충분히 생각해 둔 데서 옵니다. 패턴을 익혔고, 플랫폼을 알고, 실패를 봤고, 어떤 질문을 던져야 하고 어떤 결정이 되돌리기 어려운지 압니다. 그래서 이 과정 내내 시나리오를 다룹니다. 더 많은 결정을 분석할수록 다음 결정의 모양을 더 빨리 알아봅니다.
양식 입력이 필요한 고객이 있었습니다. 그런데 양식이 많았고, 질문은 시간이 지나며 바뀔 수 있었습니다. 저는 곧바로 설문 데이터 모델이 필요하다는 것을 알아봤습니다. 과정 후반에 다시 다룰 패턴입니다. 패턴과 해법을 알아봤기에, 눈앞의 요구사항만이 아니라 앞으로 올 요구사항까지 다루는 더 완전한 데이터 모델을 가져올 수 있었습니다.
아키텍처는 균형이다
섹션 제목: “아키텍처는 균형이다 ”데이터 아키텍처를 더 깊이 들어가면, 제가 단순한 규칙을 주기를 거부하는 선택들을 만나게 될 겁니다. 정규화할까, 평평하게 할까? 데이터를 복사할까, 연합할까? 동기일까, 비동기일까? 표준 개체일까, 사용자 정의일까? 보관할까, 온라인에 둘까?
원칙도, 패턴도, 한계도 있고, 때로는 분명히 틀린 답도 있습니다. 하지만 종종 아키텍트의 일은 이 시스템, 이 비즈니스, 이 순간에 맞는 균형을 찾는 것입니다.
최적이 어떤 모습인지 아십시오. 제약을 이해하십시오. 실현 가능한 선택지를 찾으십시오. 트레이드오프를 드러내십시오. 그리고 결정하십시오.
그것은 우유부단이 아닙니다. 그것이 아키텍처입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 어떤 선택지가 실현 가능하고, 어떤 것이 지금 틀렸거나 1년 뒤에 나빠질지.
- 실현 가능한 각 선택지가 무엇을 얻고 무엇을 포기하는지, 질문을 견디는 요구사항에 비추어.
- 어떤 제약이 진짜이고 어떤 것이 선호일 뿐인지.
- 트레이드오프를 펼쳐 놓은 뒤 어떤 선택지를 추천하고 어떻게 설명할지.