오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라.
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 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 5/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 아키텍처는 트레이드오프의 기술이다 · 다음: 도구를 알라: 아홉 가지 질문
이 모듈이 답하는 질문: 오늘의 요구사항을 위해 설계하면서 동시에 성장과 실패를 어떻게 계획할까요?
아키텍처에서 가장 저지르기 쉬운 실수 중 하나는 눈앞의 요구사항만을 위해 설계하는 것입니다. 프로젝트가 있고, 백로그가 있고, 요구사항이 있습니다. 그것을 충족하는 무언가를 만듭니다. 작동하고, 우리는 승리를 선언합니다. 6개월 뒤 비즈니스가 바뀌거나, 데이터가 늘거나, 다른 사업부가 쓰고 싶어 하거나, 회사를 인수하거나, 새 시스템을 연동해야 하거나, 아무도 대비하지 않은 무언가가 실패합니다.
아키텍트라면 어느 것에도 놀라서는 안 됩니다. 앞으로 일어날 모든 일을 예측할 수는 없지만, 무언가는 일어난다는 것을 알고 설계할 수는 있습니다. 그래서 저는 아키텍처를 세 렌즈로 봅니다.
오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라.
세 가지가 모두 필요합니다.
오늘을 위해 만들라
섹션 제목: “오늘을 위해 만들라 ”아키텍처는 우리가 실제로 가진 문제에서 시작합니다. 당연하게 들리지만, 아키텍트는 단기적 사고와 정반대의 실수를 할 수 있습니다. 과잉 설계입니다. 회사를 열두 개 인수하고, 고객이 10억 명이 되고, 40개국으로 진출하고, 모든 시스템에 실시간 연동이 필요해지면 어떡하죠? 그럴 수도 있습니다. 하지만 그것이 현실적인 가능성입니까, 아니면 문제를 지어내고 있는 겁니까? 아키텍처는 상상할 수 있는 가장 정교한 시스템을 만드는 일이 아닙니다. 적절한 시스템을 만드는 일입니다.
그러니 오늘에서 시작하십시오. 비즈니스에 필요한 것, 실제 볼륨과 사용자와 트랜잭션, 데이터가 얼마나 자주 바뀌고 얼마나 빨리 이동해야 하는지, 누가 접근해야 하는지, 데이터가 어디서 와서 어디로 가는지. 그리고 무엇보다 왜? 이 답들이 설계할 구체적인 무언가를 줍니다.
암묵적 요구사항을 찾아라
섹션 제목: “암묵적 요구사항을 찾아라 ”주어진 요구사항이 반드시 가진 요구사항의 전부는 아닙니다. 거의 언제나 암묵적 요구사항이 있습니다.
비즈니스가 “고객 데이터가 Salesforce에 있어야 합니다”라고 말합니다. 좋습니다. 그러면 누군가 그 데이터를 소유하고 얼마나 최신이어야 하는지 정해야 합니다. 원천 시스템이 다운되면 어떻게 되는지, 동기화가 실패하면 어떻게 알아차릴지, Salesforce와 원천이 다를 때 어느 쪽이 이기는지 알아야 합니다. 보존 기간, 접근 모델, 민감한 필드에 대한 결정, 잘못된 데이터를 고칠 방법이 필요합니다.
그중 어느 것도 사용자 스토리에 없었습니다. 그래도 전부 아키텍처입니다. 아키텍트가 된다는 것의 큰 부분은 아직 아무도 묻지 않은 질문을 알아보는 법을 배우는 것입니다.
숫자를 알라
섹션 제목: “숫자를 알라 ”저는 아키텍트들에게 끊임없이 수치화하라고 요구합니다. 데이터가 많다고 말하지 말고, 얼마나 많은지 말하십시오. 1만, 1,000만, 1억, 10억? 모두 매우 다른 아키텍처입니다. 연동이 자주 돈다고 말하지 마십시오. 매시간인가요, 매분인가요, 초당 천 번인가요? 빠르게 성장하고 있다고 말하지 마십시오. 얼마나 빨리요?
더 나은 숫자가 없을 때 제 기준은 연 30퍼센트 성장입니다. 예측이 아니라 강제 장치입니다. 누군가 오늘 레코드가 1,000만 건이라고 하면, 저는 논의가 1,000만에서 멈추기를 원하지 않습니다. 연 30퍼센트면 내년에 약 1,300만, 그다음 해에 1,700만, 그다음 해에는 약 2,200만입니다. 이제 설계를 이야기해 봅시다. 비즈니스가 30퍼센트는 터무니없다고 하면 좋습니다. 실제 숫자를 주십시오. 요점은 성장을 아키텍처 논의의 일부로 만드는 것입니다.
저는 이것을 스티브의 0의 개수(Steve’s Number of Zeros)라고 부릅니다. 0 하나가 더 붙으면 아키텍처가 완전히 바뀔 수 있습니다. 1만, 10만, 100만, 1,000만, 1억. 기능은 바뀌지 않았고 요구사항도 바뀌지 않았을 수 있지만, 아키텍처는 바뀔 수 있습니다.
모듈 1의 예약을 기억하십니까? 실제 숫자를 붙여 봅시다. 지점 1,200곳 이상, 지점당 하루 예약 100건, 주 6일, 연간 약 305일. 첫해에 3,600만 건이 넘는 예약입니다. 방문마다 레코드가 두 개 생기니 7,300만 건이 넘는 레코드입니다. 이제 연 30퍼센트씩 늘면서 5년치 이력을 보관하면 레코드가 6억 5,000만 건을 넘습니다. 같은 기능, 같은 요구사항. 0이 두어 개 더 붙고, 아키텍처는 전혀 달라집니다.
내일을 계획하라
섹션 제목: “내일을 계획하라 ”오늘을 이해하고 나면 저는 앞을 봅니다. 무엇이 바뀔 가능성이 상당히 높은가? 볼륨도 그 일부지만, 내일은 단지 더 많음이 아닙니다. 다름일 수도 있습니다. 더 많은 제품, 사업부, 국가. 다른 개인정보 보호 요건. 새 채널과 연동. 합병이나 인수. 새 마스터 데이터 전략이나 분석 플랫폼. 사람만을 위해 설계된 정보를 소비하는 AI 에이전트.
그래서 저는 아키텍처가 끊임없는 변경이 아니라 추가를 통해 성장할 수 있는지에 그토록 신경 씁니다. 비즈니스가 제품을 추가하면 모델이 받아낼 수 있나요? 다른 시스템이 데이터를 필요로 하면 깔끔하게 노출할 수 있나요? 볼륨이 급증하면 갈 곳이 있나요? 비즈니스 구조가 바뀌면 데이터 모델을 뜯어고쳐야 하나요? 미래를 완벽히 예측하려는 게 아닙니다. 스스로를 구석에 몰아넣지 않으려는 것입니다.
내일을 오늘 만들지 마라
섹션 제목: “내일을 오늘 만들지 마라 ”여기엔 균형이 있습니다. 내일을 계획한다는 것이 내일의 시스템을 오늘 만든다는 뜻은 아닙니다. 지금 레코드가 10만 건이고 5년 뒤 1억 건이 될 수도 있다고 해서, 1억 건짜리 아키텍처를 지금 만들라는 뜻이 아닙니다. 아직 필요 없는 비용과 복잡성을 가져올 수 있습니다.
제가 답을 원하는 질문은 이것입니다. 오늘의 아키텍처가 내일의 아키텍처로 진화할 수 있는가? 앞길이 분명한 채로 단순하게 시작할 수 있다면, 몇 년 일찍 복잡성 비용을 치르는 것보다 나은 경우가 많습니다. 위험은 작게 시작하는 데 있지 않습니다. 위험은 갈 곳이 없는 곳에서 시작하는 데 있습니다.
실패를 계획하라
섹션 제목: “실패를 계획하라 ”이제 아무도 이야기하고 싶어 하지 않는 부분입니다. 무언가는 실패합니다. 저는 모든 구성 요소가 영원히 가용하고, 모든 연동이 성공하고, 모든 사용자가 완벽한 데이터를 입력하고, 모든 외부 시스템이 문서대로 정확히 동작하는 시스템을 설계해 본 적이 없습니다. 그러니 그런 시스템을 설계하지 마십시오.
무엇이 실패할 수 있는지 묻고, 그다음 실패하면 어떻게 되는지 물으십시오. 연동이 시간 초과됩니다. API가 요청을 거부합니다. 야간 적재가 80만 건을 처리하다 20만 건에서 실패합니다. 원천 시스템이 다운됩니다. 사용자가 잘못된 데이터를 입력합니다. 외부 식별자가 두 번 나타납니다. 상류 시스템이 필드 이름은 그대로 두고 값의 형식을 바꿉니다. 한 시스템에서는 프로세스가 성공하고 다른 시스템에서는 실패합니다. 이건 특이한 예외 상황이 아닙니다. 이것이 운영 환경의 모습입니다.
부분적인 성공도 이해해야 할 실패다
섹션 제목: “부분적인 성공도 이해해야 할 실패다 ”부분적인 실패는 데이터 아키텍처에서 특히 위험합니다. 100만 건의 레코드를 옮기는데 프로세스가 완료되었다고 보고한다고 상상해 보십시오. 좋습니다. 그런데 100만 건이 도착했나요, 99만 9,997건이 도착했나요, 그리고 빠진 세 건은 무엇인가요? 어쩌면 20만 건이 실패했을 수도, 일부가 두 번 생성되었을 수도, 모두 도착했지만 일부 필드가 변환에 실패했을 수도 있습니다.
“작업 완료”는 데이터가 정확하다와 같은 말이 아닙니다. 데이터 아키텍트는 대사(reconciliation)를 생각합니다. 무엇이 일어났어야 하는지, 실제로 무엇이 일어났는지, 그 차이를 어떻게 알 수 있을까? 그리고 그것에 대해 무엇을 할까?
시스템이 복잡해질 때 제가 하는 방법은 이렇습니다. 레코드는 A에서 B로, 왼쪽에서 오른쪽으로 갑니다. 그러면 B가 무언가를 돌려보냅니다. 받아서 저장한 레코드마다 확인을요. 이제 A는 보낸 것과 확인된 것을 비교할 수 있습니다. 모든 레코드에 확인이 있으면 실행은 성공한 것입니다. 확인이 하나라도 빠졌다면, 작업 상태가 뭐라고 하든 성공하지 못한 것이고, 우리는 어떤 레코드를 쫓아가야 하는지 정확히 압니다. 재시도하거나, 사람에게 넘기거나, 경고를 올리거나.
우아하게 실패하라
섹션 제목: “우아하게 실패하라 ”실패가 일어나면 저는 시스템이 다음에 무엇을 하는지 알고 싶습니다. 재시도하는지, 자동으로 하는지 아닌지. 같은 트랜잭션이 두 번 처리되면 어떻게 되는지. 실패한 레코드는 어디로 가는지, 좋은 레코드는 나쁜 레코드를 지나 계속 흘러가는지. 누가 어떤 정보와 함께 경고를 받고, 실패를 어떻게 다시 처리하는지. 그리고 사용자는 무언가 잘못됐다는 것을 어떻게 알게 되는지.
그리고 무엇보다 문제를 더 키우지 않고 복구할 수 있는가? 중복 데이터를 만드는 재시도 전략은 별로 좋은 복구 전략이 아닙니다. 좋은 아키텍처는 실패를 전제하고 되돌아올 길을 줍니다.
중요한 것을 모니터링하라
섹션 제목: “중요한 것을 모니터링하라 ”모니터링 없이 실패를 계획하는 것은 진짜 계획이 아닙니다. 새벽 2시에 연동이 실패했는데 사흘 뒤 고객이 전화할 때까지 아무도 몰랐다면, 우리에겐 운영 아키텍처가 없었던 것입니다. 희망이 있었을 뿐입니다.
무엇이 관찰 가능해야 하는지 정하십시오. 프로세스가 실행되었는가, 얼마나 걸렸는가, 레코드가 몇 건 처리되었고, 몇 건이 성공하고 실패했는가? 볼륨이 갑자기 평소와 다른가? 백로그가 쌓이고 있나, 오류가 늘고 있나? 아키텍처는 배포가 성공했을 때 끝나지 않습니다. 누군가는 내일 이 시스템을 운영해야 하고, 그것도 설계의 일부입니다.
세 방향 모두로 생각하라
섹션 제목: “세 방향 모두로 생각하라 ”이 과정의 나머지 내내 세 렌즈를 계속 적용하십시오. 데이터 모델을 설계할 때: 오늘 작동하는가, 내일 성장할 수 있는가, 데이터가 틀리거나 불완전하면 어떻게 되는가? 연동: 오늘의 데이터를 옮기는가, 내일의 볼륨과 시스템을 감당하는가, 한쪽이 다운되면 어떻게 되는가? 대용량 데이터: 오늘 무엇이 있고, 숫자는 어디로 가고 있으며, 큰 작업이 일부만 성공하면 어떻게 복구하는가?
기술은 장마다 바뀝니다. 질문은 바뀌지 않습니다.
아키텍처는 시간 속에 존재한다
섹션 제목: “아키텍처는 시간 속에 존재한다 ”개발자는 때로 요구사항을 보고 “작동하나?”라고 물을 수 있습니다. 아키텍트는 더 많이 물어야 합니다. 오늘 작동하는가, 내일도 여전히 작동할까, 그리고 전혀 작동하지 않으면 어떻게 되는가? 이 세 질문이 우리를 구현 너머, 시스템의 생애 속으로 데려갑니다.
모든 미래의 요구사항을 예측하거나 모든 실패를 막지는 못할 것입니다. 그게 목표가 아닙니다. 목표는 오늘 아는 것에 적절한 무언가를 만들고, 내일 갈 곳을 남겨 두고, 현실이 협조하지 않을 때를 위한 계획을 갖는 것입니다.
오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라. 이 세 렌즈를 몇 번이고 다시 쓰겠습니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 실제 볼륨과 성장은 얼마이며, 어떤 숫자가 설계를 바꿀지.
- 비즈니스가 아직 말하지 않은 암묵적 요구사항은 무엇인지.
- 내일의 시스템을 오늘 만들지 않고도 오늘의 설계가 내일의 설계로 어떻게 진화할 수 있는지.
- 무언가 실패하면 어떻게 되는지: 복구, 대사, 모니터링.