AI 시대의 데이터 아키텍트

🌐 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)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정의 첫 번째 장인 데이터 아키텍트처럼 생각하기의 모듈 7/7. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 도구를 알라: 아홉 가지 질문 · 다음: 다음 장: 데이터 모델링

이 모듈이 답하는 질문: AI는 데이터 아키텍트에게 무엇을 바꾸고, 무엇을 바꾸지 않을까요?

AI는 아키텍처를 바꿉니다. 하지만 사람들이 처음 생각하는 방식은 아닐지도 모릅니다.

이 장이 어디서 시작했는지 떠올려 보십시오. 저는 경력의 대부분을 빌더로 보냈습니다. 그 시간 대부분 동안 소프트웨어를 만드는 것은 비쌌습니다. 전문 기술을 가진 사람들이 필요했고, 코드를 쓰고, 연동을 만들고, 애플리케이션을 만들고, 테스트하는 데 모두 시간이 걸렸습니다. 아이디어를 실험하는 것조차 의미 있는 투자였습니다. AI가 그 방정식을 바꾸고 있습니다. 오늘 저는 원하는 것을 설명하면 AI가 데이터 모델, Apex, Flow, Lightning 컴포넌트, 연동, 테스트, 문서를 놀라울 만큼 빠르게 생성하게 할 수 있고, 내일은 그보다 더 많은 일을 할 것입니다.

그러니 이렇게 묻는 것도 당연합니다. AI가 만드는 일의 그토록 많은 부분을 할 수 있다면, 아키텍트는 어떻게 될까? 제 답은 아키텍처가 덜 중요해지는 게 아니라 더 중요해진다는 것입니다.

AI는 로켓 부스터다

저는 강연에서 이 비유를 써 왔습니다.

AI는 로켓 부스터다. 아키텍처는 유도 장치다.

AI는 엄청난 가속을 줍니다. 애플리케이션, 데이터 모델, 연동, 테스트, 문서를 그 어느 때보다 빠르게 생성할 수 있습니다. 하지만 로켓 부스터는 로켓이 어디로 갈지 정하지 않습니다. 추력을 공급할 뿐입니다. 경로를 정하고 도중에 수정하는 것은 유도 장치입니다.

제대로 된 유도 없이 추력만 늘리면 도움이 되지 않습니다. 잘못된 목적지에 더 빨리 데려다줄 뿐입니다. 아키텍트의 일은 모든 것을 늦추는 것이 아니라, 우리가 올바른 방향으로 가속하고 있는지 확인하는 것입니다.

AI로 생성한 이미지입니다.

예전보다 열 배 빠르게 애플리케이션을 만드는 AI 도구를 상상해 보십시오. 올바른 애플리케이션이라면 훌륭합니다. 하지만 데이터 모델이 틀렸다면, 또는 표준 개체를 잘못 골랐다면, 마스터 데이터가 있어야 할 곳을 오해했다면, 설계가 오늘의 볼륨에서는 작동하지만 0이 하나 더 붙으면 무너진다면? AI는 실수를 없애지 않았습니다. 실수를 더 빨리 만들도록 도왔고, 누군가 알아차리기 전에 그 위에 훨씬 더 많은 것을 쌓게 했습니다.

값싼 구현은 가치를 옮긴다

구현이 비쌀 때는 자연히 구현에 관심이 쏠립니다. 누가 만들 수 있는지, 얼마나 걸릴지, 애초에 작동하게 만들 수 있는지. 구현이 싸질수록 다른 질문이 더 중요해집니다. 무엇을 만들어야 하는가? 그것은 아키텍처의 질문입니다.

AI는 개체 스무 개를 생성할 수 있지만, 다섯 개면 되는지는 데이터 아키텍트가 정합니다. AI는 연동을 생성할 수 있지만, 데이터를 복사해야 하는지는 아키텍트가 정합니다. AI는 몇 초 만에 필드를 만들 수 있지만, 그 필드에 분명한 의미와 소유자와 존재 이유가 있는지는 아키텍트가 묻습니다. AI는 우리가 요청한 것을 만들기에, 우리가 무엇을 요청하는지의 품질이 그 어느 때보다 중요합니다.

생성은 판단이 아니다

AI는 선택지를 생성하는 데 아주 능하고, 그것은 엄청나게 유용합니다. 저는 AI에게 무언가를 모델링하는 세 가지 방법을, 트레이드오프를, 아키텍처에 대한 반론을, 레코드 1억 건에서 무슨 일이 일어나는지나 설계가 어디서 실패할 수 있는지를, 또는 Salesforce가 기록 시스템이 아닌 대안을 묻습니다. 저는 아키텍트들이 이렇게 하기를 바랍니다.

하지만 선택지를 생성하는 것과 그것을 판단하는 것은 다른 일입니다. AI는 선택지 A와 B가 각각 무엇을 주는지 말해 줄 수 있습니다. 그래도 누군가는 어떤 장점이 중요한지, 어떤 제약이 진짜인지, 어떤 위험이 받아들일 만한지, 언제 어떤 답이 기술적으로는 그럴듯하지만 이 조직에는 틀린지 알 만큼 비즈니스를 이해해야 합니다. 그것이 판단이고, 그것이 아키텍처입니다.

제 일에서 그것이 어떻게 나타나는지 말씀드리겠습니다. 지난 1년 사이 저는 코드 대부분을 직접 쓰지 않게 되었습니다. AI에게 세부 사항을 주고 화면과 백엔드 코드를 생성해 달라고 하면, 놀라울 만큼 잘합니다.

하지만 AI는 한 발 물러서서 더 깊이 분석하지 않습니다. 데이터 모델이나 설계에 결함이 있어도 문제 삼지 않습니다. 이미 있는 것을 전제로 받아들이고 그 위에 빠르고 능숙하게 짓습니다. “이걸 추가하기 전에, 지금 있는 모델을 바꿔 볼 만할 수도 있어요”라고 멈춰서 말하는 일은 드뭅니다. 이미 있는 것을 보고 다음 것을 그 위에 지을 수 있는지만이 아니라 그것이 옳은지 묻는 것은 여전히 아키텍트의 일입니다. AI가 가정에 의문을 제기하기를 원한다면, 그렇게 해 달라고 요청해야 합니다.

가역성 테스트는 여전히 유효하다

모듈 3의 질문으로 돌아가십시오. 이 결정을 되돌리기가 얼마나 어려울까? AI는 소프트웨어를 생성하고 바꾸는 비용을 바꿉니다. 현실을 바꾸는 비용은 바꾸지 않습니다. 레코드 1억 건이 적재되면, 그것은 존재합니다. 시스템 열두 개가 식별자 하나에 의존하면, 그 의존성은 존재합니다. 고객이 프로세스를 쓰거나 분석이 필드의 의미에 의존하게 되면, 그것을 바꾸는 데는 결과가 따릅니다. 그리고 데이터가 공유되지 말아야 할 곳에 공유되고 나면, 새 코드를 아무리 써도 되돌릴 수 없습니다.

되돌릴 수 없는 것은 여전히 되돌릴 수 없습니다.

에이전트는 새로운 종류의 데이터 소비자다

예전에는 두 종류의 소비자를 위해 데이터를 설계했습니다. 사람과 소프트웨어입니다. 사람은 레코드를 읽고, 보고서나 연동이나 애플리케이션은 데이터를 읽습니다. 이제 세 번째가 있습니다. 에이전트입니다. 에이전트는 데이터를 가져오고, 해석하고, 다른 정보와 결합하고, 결정하고, 행동할 수 있으며, 때로는 그 사이에 사람이 전혀 없습니다.

그만큼 위험이 커집니다. 필드가 무엇을 의미하는지, 누가 소유하는지, 얼마나 최신이고 믿을 만한지, 민감한지, 에이전트가 볼 수 있고 봐야 하는지, 두 출처가 다를 때 어떻게 되는지. 예전에는 이런 것이 문서였습니다. 이제는 지능형 시스템이 비즈니스를 이해하는 방식입니다.

그리고 AI가 읽는다고 나쁜 데이터가 똑똑해지지는 않습니다. 쓰레기가 들어가면 쓰레기가 나온다는 원칙은 여전합니다. 중복된 고객, 불분명한 소유권, 일관되지 않은 식별자, 충돌하는 기록 시스템은 에이전트를 연결한다고 사라지지 않습니다. 결과가 더 잘 보일 뿐입니다. 사람은 필드를 보고 3년 동안 아무도 갱신하지 않았다는 걸 압니다. 에이전트에게는 그런 조직의 지식이 없고, 다른 모두가 조용히 믿지 않던 데이터를 근거로 자신 있게 행동할 수 있습니다. 데이터 아키텍처는 AI 아키텍처의 일부가 됩니다.

스키마 난립을 경계하라

AI는 무언가를 만드는 것도 믿기 힘들 만큼 쉽게 만듭니다. 개체가 하나 더, 필드가 여섯 개 더, 자동화가 하나 더 필요하다고요? 생성하면 됩니다. 결정 하나하나는 싸 보이지만, 모듈 3의 아키텍처 중력을 기억하십시오. 그 개체와 필드에는 의존성(자동화, 연동, 보고서, 에이전트)이 모여들고, 곧 아무도 설계하지 않은 데이터 모델이 생깁니다. 그냥 자라난 것입니다.

아키텍트는 “이게 정말 필요한가?”라고 물을 수 있어야 합니다. 때로는 가장 가치 있는 결정이 무언가를 만들지 않는 것입니다. 좋은 아키텍처는 무엇을 넣느냐만큼 무엇을 빼느냐에 관한 것입니다.

인간의 검토는 의례가 아니다

인간 아키텍트가 AI가 생성한 데이터 모델을 검토해야 한다고 말할 때, “AI가 만들었고, Steve가 다이어그램을 5분 보고 승인했다”는 뜻이 아닙니다. 그건 감독이 아닙니다. 아키텍트는 모델을 이해해야 합니다. 왜 이 개체들인지, 왜 이 관계들인지, 어떤 대안이 검토되었는지, 키와 마스터 데이터는 어디에 있는지, 볼륨이 커지면 어떻게 되는지, 접근에 대한 함의는 무엇인지, 어떤 트레이드오프가 이루어졌는지. 거기에 답하지 못한다면 저는 그 아키텍처를 책임지는 게 아니라 도장만 찍은 것입니다. AI는 아키텍처에 기여하고, 이의를 제기하고, 문서화할 수 있지만, 인간 아키텍트는 그것을 변호할 수 있어야 합니다.

사실에 대해서도 마찬가지입니다. 저는 배우고 조사할 때 AI를 늘 쓰며, 제 원칙은 신뢰하되 검증하라입니다. 질문하고, 설명과 대안과 자기 답에 대한 반론을 요청하십시오. 그런 다음 아키텍처에 중요한 것이라면 링크를 따라가고, 문서를 읽고, 한계를 확인하고, 라이선스를 확인하고, 동작을 테스트하십시오. AI는 틀렸을 때 아주 그럴듯할 수 있고, 사실과 가정을 구분하는 일은 이제 일의 더 큰 부분이 되었습니다.

AI는 여정을 줄여 주지 않는다

아키텍트가 되는 것에 대해 이야기할 때 제가 쓰는 문장이 있습니다.

AI는 여정을 줄여 주지 않는다. 다만 모든 걸음을 더 의미 있게 만들 수 있다.

여전히 데이터, 보안, 연동, 플랫폼, 비즈니스를 이해해야 하고, 결정을 내리고 그 결과와 함께 사는 경험이 여전히 필요합니다. AI는 배움을 앞당기고, 아직 만나지 못한 시나리오를 보여 주고, 설명하고, 도전하고, 만드는 것을 돕고, 두 번째 눈이 되어 줄 수 있습니다. 전부 활용하십시오. 다만 답을 아는 AI를 답을 이해하는 당신과 혼동하지 마십시오.

아키텍트는 지휘한다

이 장은 설계도를 쥔 사람에서 시작했습니다. AI는 그 사람에게 놀라운 새 도구를 줍니다. 설계도의 일부를 그리고, 자재를 조사하고, 대안을 제안하고, 하중을 계산하고, 문서를 쓰고, 놓친 문제까지 찾아내는 조수입니다. 쓰십시오. 하지만 누군가는 여전히 건물 전체를 이해하고, 그것이 올바른 건물인지 묻고, 요구사항이 바뀌면 어떻게 되는지, 어떤 결정을 되돌리는 데 비용이 클지 알고, 결과에 책임져야 합니다.

그래서 이 과정의 마지막 단계 이름이 Direct(지휘)입니다. 당신이 모든 코드 줄을 쓰거나, 모든 Flow를 만들거나, 모든 개체를 만들지는 않을 수 있습니다. 그래도 누군가는 해법을 지휘해야 하고, 그것이 아키텍트입니다. AI는 아키텍처를 없애는 것이 아니라 아키텍트가 가치를 만드는 곳을 바꾸고 있습니다. 아키텍트가 되기에 놀라운 시대입니다.

아키텍트가 여기서 결정하는 것

• 만드는 것이 싸진 지금, 무엇을 만들 가치가 있는지: 어떤 개체, 필드, 연동이 제자리를 얻을 자격이 있는지.
• AI가 생성한 선택지 중 어떤 것이 이 비즈니스에 맞고, 어떤 것이 그럴듯하지만 틀렸는지.
• AI가 빠르게 지나쳐 버리는 결정 중 되돌리는 비용이 클 결정은 무엇인지.
• 에이전트가 무엇을 읽고 무엇을 근거로 행동해도 되는지, 그리고 그렇게 하기에 데이터가 충분히 좋고 잘 설명되어 있는지.
• AI가 준 사실 중 설계를 좌우하기 전에 검증해야 할 것은 무엇인지.

그것이 AI 시대에 아키텍트처럼 생각하는 것입니다.