아키텍트처럼 생각하기
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 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 1/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 장 개요 · 다음: 데이터 모델은 뼈대다
이 모듈이 답하는 질문: 만드는 것과 아키텍처를 설계하는 것은 무엇이 다르며, 아키텍트는 실제로 무엇을 할까요?
제 경력의 대부분 동안 저는 만드는 사람, 빌더였습니다.
개발자로 시작했습니다. Salesforce로 옮기기 전에는 Java와 .NET으로 일했고, 오랜 세월 시스템을 설계하고, 코드를 쓰고, 플랫폼을 연동하고, 아키텍트를 가르치고, 아키텍처를 검토해 왔습니다.
하지만 그 길에서 배운 가장 중요한 교훈 중 하나는 훌륭한 빌더가 되는 것과 훌륭한 아키텍트가 되는 것이 늘 같은 일은 아니라는 것입니다.
빌더는 이렇게 묻습니다.
이걸 어떻게 만들지?
아키텍트는 다른 질문들을 던져야 합니다.
이걸 만들어야 할까?
왜 이런 방식으로 만들고 있지?
대안은 무엇일까?
이게 커지면 어떻게 될까?
이게 실패하면 어떻게 될까?
그리고 오늘 내리는 결정 중에서, 3년 뒤에 더 깊이 생각해 볼 걸 하고 후회할 결정은 무엇일까?
예약을 받는 리테일 기업의 프로젝트에 참여했던 기억이 납니다. 저는 물었습니다. 매장당 하루 예약이 몇 건입니까? 그다음엔, 매장이 몇 개입니까? 그리고 일주일에 며칠 영업합니까? 금세 첫해에만 예약이 수백만 건이 되리라는 걸 깨달았습니다. 아키텍트가 프로젝트를 시작할 때 던지는 질문이 바로 이런 것입니다.
이 사고의 전환이야말로 이 과정이 진짜로 다루는 내용입니다.
설계도를 쥔 사람
섹션 제목: “설계도를 쥔 사람 ”아키텍트를 가르칠 때 이 비유를 여러 번 써 왔습니다.
건설 현장을 떠올려 보십시오. 콘크리트를 붓고, 전기를 배선하고, 배관을 설치하고, 벽체를 세우고, 그 밖에도 수십 가지 전문 작업을 하는 사람들이 있습니다. 그들은 자기 일에 아주 능숙해야 합니다.
하지만 누군가는 설계도를 쥐고 있어야 합니다.
그 사람은 모든 조각이 어떻게 맞물리는지 이해해야 합니다. 프로젝트의 한 부분에서 일어나는 일이 다른 곳에 문제를 만들 때 그것을 알아차려야 합니다.
그것이 아키텍처입니다.
기술 분야에서 우리는 가끔 아키텍트가 그저 가장 많이 아는 사람이라고 착각합니다. 그게 핵심은 아닙니다. 플랫폼을 아는 것은 중요합니다. 기술적 깊이도 필요합니다. 하지만 아키텍처는 상식 퀴즈 대회가 아닙니다.
아키텍트의 일은 좋은 결정을 내리고(때로는 불완전한 정보와 상충하는 요구사항 속에서), 그 결정의 결과를 이해하는 것입니다.
그건 전혀 다른 기술입니다.
요구사항을 그냥 받아들이지 말라
섹션 제목: “요구사항을 그냥 받아들이지 말라 ”제가 아키텍트들이 가장 먼저 기르기를 바라는 습관 중 하나는 단순합니다.
왜냐고 물으십시오.
누군가 이렇게 말합니다.
개체가 하나 더 필요해요.
왜요?
이 필드를 계정에 복사해야 해요.
왜요?
이 데이터를 전부 Salesforce에 저장해야 해요.
왜요?
까다롭게 굴라는 뜻이 아닙니다. 제안된 해법을 곧바로 구현하는 대신 실제 비즈니스 요구사항을 이해하라는 뜻입니다.
요구사항은 종종 설계로 위장한 채 도착합니다.
“새 사용자 정의 개체가 필요하다”는 꼭 요구사항이 아닙니다. 실제 요구사항은 “이 정보를 따로 추적해야 한다”일 수 있습니다. 둘은 같은 것이 아닙니다.
진짜 요구사항을 이해하고 나면 대안을 탐색할 수 있습니다. 어쩌면 새 개체가 정확한 답일 수도 있습니다. 어쩌면 그 정보는 이미 있는 어딘가에 속할 수도 있습니다. 어쩌면 Salesforce가 그 데이터를 아예 소유하지 말아야 할 수도 있습니다.
아키텍트는 비즈니스에 필요한 것과 그것을 제공하는 하나의 제안된 방법을 분리해야 합니다.
영업 애플리케이션을 만들던 중이었는데, 고객에게는 여러 단계의 승인이 있었고 각각 승인자와 날짜가 있었습니다. 처음 요청은 승인자 2와 승인자 3을 각각 날짜와 함께 기회의 필드로 추가해 달라는 것이었습니다. 더 파고들어 보니 승인이 두세 건보다 많아질 수 있었습니다. 그래서 승인을 하위 개체로 옮겼습니다. 요청은 필드를 더 달라는 것이었고, 요구사항은 승인이 몇 건이 되든 모든 승인을 추적하는 것이었습니다.
요구사항 너머를 생각하기
섹션 제목: “요구사항 너머를 생각하기 ”왜냐고 묻는 데서 두 가지 습관이 나오며, 각각 이 장 뒤쪽에 자기 모듈이 있습니다.
보통 답은 하나가 아닙니다. Salesforce는 문제를 푸는 방법을 많이 주고, 그중 일부는 거의 즉시 틀린 것으로 드러납니다. 작동하는 것들 사이에서 고르는 것이 트레이드오프의 기술입니다(모듈 4).
그리고 주어진 요구사항이 가진 요구사항의 전부는 아닙니다. 아무도 “야간 적재가 절반만 성공해도 이게 작동하게 해 주세요”라고 말하지 않지만, 그래도 그것은 요구사항입니다. 저는 모든 설계를 세 렌즈로 봅니다. 오늘을 위해 만들라, 내일을 계획하라, 실패를 계획하라(모듈 5).
건물 설계를 의뢰하는 사람을 생각해 보십시오. 화재경보기나 스프링클러를 달아 달라고, 지진에도 건물이 버티게 해 달라고 요청하지 않습니다. 말하지 않아도 일의 일부라고 기대합니다. 우리 세계도 똑같습니다. 아무도 우아한 오류 처리나 로그, 무언가 실패했을 때 복구할 방법을 요청하지 않습니다. 그런 시스템 중 무엇이 설계에 들어가야 하는지 알고 그것을 넣는 것은 아키텍트의 몫입니다.
추론을 드러내라
섹션 제목: “추론을 드러내라 ”아키텍트는 회의실에 들어와 “이렇게 하겠습니다”라고 선언만 해서는 안 됩니다.
당신의 일에는 왜를 설명하는 것도 포함됩니다. 저는 이해관계자들이 우리가 검토한 대안과 그에 따른 트레이드오프를 이해하기를 바랍니다. 경영진에게 40쪽짜리 설계 문서를 건네라는 뜻이 아닙니다. 같은 아키텍처를 개발자에게, 비즈니스에, 경영진에게 설명할 수 있어야 한다는 뜻입니다. 같은 결정에 대한 서로 다른 대화입니다.
그 방법은 건설 현장에서 설계도를 쥔 사람처럼 명확한 설계도와 지시를 갖추는 것입니다. 데이터 아키텍트에게 가장 중요한 설계도 중 하나가 데이터 모델입니다.
어떤 결정이 왜 내려졌는지 아무도 모른다면, 결국 누군가 그것을 되돌릴 가능성이 큽니다. 그리고 그 사람에게는 충분히 합리적인 이유가 있을 수도 있습니다. 원래 결정을 아무도 설명해 준 적이 없으니까요.
아키텍트가 모든 것을 만들 필요는 없다
섹션 제목: “아키텍트가 모든 것을 만들 필요는 없다 ”어려울 수 있는 전환이 하나 더 있습니다. 특히 개발을 거쳐 아키텍처로 온 사람들에게 그렇습니다.
모든 것을 직접 만들 필요는 없습니다.
저는 지금도 사물이 아주 기술적인 수준에서 어떻게 작동하는지 이해하는 것을 좋아하고, 그 기반은 중요합니다. 하지만 아키텍트가 되면 책임이 자신의 구현보다 커집니다. 모든 것을 직접 만들 필요는 없습니다. 실제로 만드는 사람들에게 올바른 방향과 올바른 기준을 주는 법을 알아야 합니다. 즉 그들의 일을 이끌 만큼, 제안된 구현이 아키텍처적 문제를 만들 때 알아볼 만큼, 세부와 큰 그림 사이를 오갈 만큼 이해해야 합니다.
때로는 쿼리나 API나 데이터 모델 깊숙이 들어가야 합니다.
때로는 한 발 물러서서 애초에 이 일을 해야 하는지 물어야 합니다.
그리고 점점 더, 만드는 주체가 사람만은 아니게 됩니다. AI와 함께라면 아키텍트는 개체, 코드, 화면을 생성하는 도구와 직접 일하게 될 수 있습니다. 그러면 방향, 기준, 지침은 AI에게 가고, 그것을 잘 주는 일은 점점 더 아키텍트의 책임이 됩니다. 이 이야기는 모듈 7에서 다시 다룹니다.
그것이 빌더에서 아키텍트로 가는 여정의 일부입니다.
당신의 일은 결정하는 것이다
섹션 제목: “당신의 일은 결정하는 것이다 ”결국 아키텍처는 결정에 관한 것입니다.
어떤 결정은 바꾸기 쉽습니다. 어떤 결정은 그렇지 않습니다.
페이지 레이아웃은 바꿀 수 있습니다. 레이블은 이름을 바꿀 수 있습니다.
하지만 근본적인 데이터 모델을 잘못 고르거나, 수십 개 시스템이 의존하기 시작하는 식별자를 공개하거나, 핵심 데이터의 마스터 사본을 엉뚱한 곳에 두면, 마음을 바꾸는 비용이 훨씬 커집니다.
그런 것이 아키텍처적인 결정입니다. 그리고 이 과정이 집중하는 것이 바로 그런 결정입니다.
데이터 아키텍트로서 당신은 정보가 어떻게 구조화되는지, 어디에 있는지, 어떻게 성장하는지, 어떻게 이동하는지, 누가 접근할 수 있는지, 그리고 나머지 기업이 그것을 어떻게 이해하는지에 대해 결정하게 됩니다.
기술은 중요합니다.
하지만 Salesforce의 모든 기능을 아는 것이 목표는 아닙니다.
목표는 어떤 도구를 쓸지, 언제 쓸지, 무엇을 포기하는지, 그다음에 무슨 일이 일어나는지 아는 판단력을 기르는 것입니다.
그것이 아키텍트처럼 생각하는 것입니다.
이제 우리는 데이터 아키텍트처럼 생각하기 시작할 수 있습니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 어떤 요청이 진짜 요구사항인지, 아니면 그것을 위한 하나의 제안된 설계인지.
- 무엇이든 만들기 전에 던질 질문: 해야 하는가, 왜 이 방식인가, 달리 무엇을 할 수 있는가, 커지거나 실패하면 어떻게 되는가.
- 어떤 결정이 아키텍트의 몫이고, 어떤 결정이 만드는 사람들의 몫인지. 그리고 만드는 쪽(사람이든 AI든)에게 어떤 방향과 기준을 줄지.
- 개발자, 비즈니스, 경영진이 각자 이해하도록 결정을 설명하는 방법.