정의
데이터 아키텍트(Data Architect)는 조직의 데이터를 어떤 구조로 만들고, 저장하고, 연결하고, 관리할지 설계하는 역할이다.
쉽게 말해 데이터가 흩어지지 않고 비즈니스 목적에 맞게 잘 흐르도록 "데이터의 설계도"를 만드는 사람이다. 여기서 설계도는 단순히 저장소나 테이블 구조만 뜻하지 않는다. 데이터가 수집되고, 변환되고, 저장되고, 배포되고, 리포트·분석·AI/ML 서비스에서 소비되는 전체 흐름을 포함한다.1
데이터 아키텍트는 비즈니스 전략과 데이터 요구사항을 연결한다. 예를 들어 "고객을 더 잘 이해하고 싶다"는 요구를 고객 식별 기준, 고객 마스터, 행동 데이터, 구매 데이터, 분석용 데이터 마트 같은 구조로 바꾸는 역할이다. 데이터베이스, 데이터 웨어하우스, 데이터 레이크, 레이크하우스, 분석 플랫폼, 데이터 거버넌스까지 넓게 다룬다.
주요 역할과 책임
비즈니스 요구사항을 데이터 관점에서 해석
전사 데이터 구조와 흐름 설계
데이터 생명주기 관점에서 수집·저장·처리·활용·폐기 흐름 설계
개념적·논리적·물리적 데이터 모델 설계
데이터 표준, 명명 규칙, 메타데이터 관리 기준 수립
데이터 계보(lineage), 데이터 카탈로그, 메타데이터 운영 기준 수립
데이터 품질 규칙과 단일 진실 공급원(SSOT, Single Source of Truth) 기준 정의
데이터 품질, 보안, 접근 권한, 개인정보 보호, 규제 준수, 거버넌스 정책 설계
데이터 저장소 선택 및 구조 설계
클라우드 데이터 웨어하우스, 데이터 레이크, 레이크하우스, 실시간 스트리밍 구조 검토
데이터 통합 방식 설계
AI/ML, 분석, 리포팅에서 재사용 가능한 데이터 구조 설계
데이터 엔지니어, DBA, 개발자, 분석가, 데이터 거버넌스 담당자와 협업
신규 시스템 도입 시 기존 데이터 구조와의 정합성 검토
데이터 중복, 불일치, 사일로 문제 해결
데이터 아키텍트는 단순히 테이블을 설계하는 사람이 아니라, 조직 전체의 데이터 자산이 장기적으로 활용될 수 있도록 구조와 원칙을 잡는 역할에 가깝다.
필요한 역량
데이터 모델링 능력
개념 모델, 논리 모델, 물리 모델을 설계할 수 있어야 한다.
개념 모델은 업무에서 중요한 대상과 관계를 큰 그림으로 잡고, 논리 모델은 속성·관계·규칙을 더 구체화하며, 물리 모델은 실제 DB나 플랫폼에 맞게 구현 구조를 정한다.
엔터티, 속성, 관계, 정규화, 비정규화 개념을 이해해야 한다.
도메인 모델, Kimball 차원 모델링, Data Vault 같은 접근법을 상황에 맞게 판단할 수 있으면 좋다.
데이터베이스와 현대 데이터 플랫폼 이해
RDBMS, NoSQL, 분산 저장소, 클라우드 데이터베이스의 특징을 알아야 한다.
데이터 웨어하우스, 데이터 레이크, 레이크하우스, 스트리밍 플랫폼의 차이를 이해해야 한다.
Kafka 같은 스트리밍 기술, dbt·Airflow·Spark 같은 도구가 어떤 역할을 하는지 알면 설계와 협업이 쉬워진다.
성능, 확장성, 안정성, 비용 관점에서 저장 구조를 판단할 수 있어야 한다.
SQL 및 데이터 처리 지식
SQL을 통해 데이터 구조와 품질을 검증할 수 있어야 한다.
ETL/ELT, 배치 처리, 스트리밍 처리 개념을 이해해야 한다.
비즈니스 이해력
업무 프로세스를 데이터 구조로 변환할 수 있어야 한다.
현업의 요구를 단순 요청이 아니라 데이터 요구사항으로 재정의할 수 있어야 한다.
데이터 거버넌스 역량
데이터 표준, 품질, 보안, 개인정보 보호, 권한 관리 기준을 설계할 수 있어야 한다.
데이터 소유자, 데이터 스튜어드, 책임 체계, 승인 절차를 데이터 구조와 함께 고려해야 한다.
데이터 카탈로그, 메타데이터, 데이터 계보를 통해 데이터가 어디서 왔고 어떻게 바뀌었는지 추적할 수 있게 해야 한다.
데이터 거버넌스는 품질, 신뢰, 규제 준수, AI 준비도를 함께 받쳐 주는 기반으로 볼 수 있다.2
커뮤니케이션 능력
현업, 개발자, 엔지니어, 경영진과 모두 대화할 수 있어야 한다.
기술적 내용을 비기술 사용자에게 쉽게 설명할 수 있어야 한다.
아키텍처 사고
현재 문제만 해결하는 것이 아니라 장기적인 확장성, 유지보수성, 재사용성을 고려해야 한다.
중앙집중형 아키텍처와 도메인 중심·분산형 아키텍처의 장단점을 판단할 수 있어야 한다.
표준화가 필요한 영역과 각 도메인의 자율성을 허용할 영역을 구분해야 한다.
유사 직무와의 차이
| 구분 | 핵심 관심사 | 주요 역할 |
|---|---|---|
| 데이터 아키텍트 | 데이터 구조와 원칙 | 전사 데이터 모델, 표준, 흐름, 거버넌스 설계 |
| 데이터 엔지니어 | 데이터 파이프라인 구현 | 수집, 적재, 변환, 자동화, 데이터 플랫폼 운영 |
| DBA | 데이터베이스 운영 안정성 | DB 성능 튜닝, 백업, 복구, 권한, 장애 대응 |
| 데이터 거버넌스 담당자 | 데이터 사용 원칙과 책임 체계 | 정책, 역할, 품질 관리, 데이터 소유권, 규제 준수 관리 |
| 데이터 모델러 | 특정 도메인의 데이터 구조 | ERD, 논리 모델, 물리 모델, 관계와 속성 상세 설계 |
| 솔루션 아키텍트 | 전체 시스템 솔루션 | 애플리케이션, 인프라, 보안, 데이터 포함 전체 구조 설계 |
| 엔터프라이즈 아키텍트 | 전사 IT와 비즈니스 아키텍처 정렬 | 비즈니스, 애플리케이션, 데이터, 기술 아키텍처의 큰 방향 관리 |
데이터 아키텍트는 "데이터를 어떻게 정의하고 연결할 것인가"에 집중한다.
데이터 엔지니어는 "그 데이터를 어떻게 수집하고 처리할 것인가"에 집중한다.
DBA는 "데이터베이스를 어떻게 안정적으로 운영할 것인가"에 집중한다.
솔루션 아키텍트는 데이터뿐 아니라 애플리케이션, 인프라, 네트워크, 보안까지 포함한 전체 시스템 구조를 본다.
데이터 아키텍트는 데이터 엔지니어의 상위 호환이라기보다 관심사가 다르다. 데이터 엔지니어가 파이프라인과 플랫폼을 실제로 구현하고 운영하는 데 더 집중한다면, 데이터 아키텍트는 어떤 데이터 구조와 원칙으로 갈지, 무엇을 표준으로 삼을지, 어떤 의사결정 기준을 적용할지에 더 집중한다.3
산출물 예시
전사 데이터 아키텍처 문서
개념 데이터 모델
논리 데이터 모델
물리 데이터 모델
ERD
데이터 흐름도
데이터 표준 정의서
데이터 사전
메타데이터 관리 문서
데이터 카탈로그 운영 기준
데이터 계보 정의서
데이터 품질 기준서
데이터 품질 규칙서
데이터 거버넌스 정책
데이터 보안 및 접근 권한 설계서
데이터 접근 제어 매트릭스
데이터 통합 아키텍처 문서
데이터 플랫폼 아키텍처 다이어그램
데이터 저장소 선정 기준 문서
마스터 데이터 관리 설계서
AI/ML 데이터 요구사항 정의서
데이터 이행 및 마이그레이션 계획서
아키텍처 의사결정 기록(ADR)
커리어 준비 방법
SQL을 먼저 탄탄히 익힌다.
데이터 구조를 이해하려면 SQL은 기본이다.
조회뿐 아니라 조인, 집계, 서브쿼리, 인덱스, 실행 계획까지 익히는 것이 좋다.
데이터 모델링을 학습한다.
ERD 작성, 정규화, 관계 설계, 키 설계, 도메인 설계가 중요하다.
단순 예제보다 실제 업무 도메인을 모델링해 보는 연습이 필요하다.
운영계 모델과 분석계 모델을 나누어 설계해 보면 실무 감각을 키우기 좋다.
Kimball 차원 모델링, Data Vault, 데이터 메시, 데이터 패브릭, 레이크하우스 같은 개념을 비교해 보면 어떤 상황에 어떤 구조가 맞는지 판단하는 데 도움이 된다.
데이터베이스와 저장소의 차이를 이해한다.
RDBMS, NoSQL, 데이터 웨어하우스, 데이터 레이크의 장단점을 비교할 수 있어야 한다.
데이터 엔지니어링 흐름을 익힌다.
ETL/ELT, Airflow, Spark, Kafka, dbt, 클라우드 데이터 플랫폼 같은 개념을 알면 협업이 쉬워진다.
비즈니스 도메인 지식을 쌓는다.
금융, 커머스, 제조, 헬스케어 등 산업마다 데이터 구조가 다르다.
좋은 데이터 아키텍트는 기술만이 아니라 업무 맥락을 이해한다.
문서화 능력을 기른다.
아키텍트의 핵심 산출물은 문서와 설계안이다.
구조를 명확하게 표현하고, 의사결정 근거를 남기는 습관이 중요하다.
DAMA-DMBOK, CDMP, TOGAF 같은 프레임워크나 자격은 데이터 관리와 아키텍처를 체계적으로 정리하는 데 도움이 될 수 있다. 다만 자격 자체가 필수라기보다 실무 경험과 함께 보완적으로 활용하는 것이 좋다.4
작은 프로젝트부터 설계해 본다.
쇼핑몰 주문 시스템
회원·결제·배송 데이터 모델
로그 분석용 데이터 마트
고객 마스터 데이터 구조
운영계 주문 DB와 분석계 매출 데이터 마트를 분리한 구조
대시보드마다 매출 지표가 다르게 나오는 상황을 가정한 지표 정의와 SSOT 설계
고객 주소, 상품명, 주문 상태 같은 데이터 품질 문제를 찾아 규칙으로 정리하는 실습
이런 주제로 직접 ERD, 데이터 흐름도, 품질 규칙서, 지표 정의서를 만들어 보면 좋다.
현대 데이터 아키텍트가 특히 신경 써야 할 점
데이터 사일로 해소
부서별 시스템에 데이터가 갇히면 같은 고객, 같은 상품, 같은 매출을 서로 다르게 해석하게 된다.
데이터 아키텍트는 시스템 간 연결 방식과 공통 기준을 설계해 데이터가 조직 전체에서 재사용되도록 해야 한다.
일관된 지표 정의와 SSOT
"매출", "활성 고객", "이탈", "재구매" 같은 지표는 조직마다 해석이 달라지기 쉽다.
핵심 지표는 정의, 계산식, 기준 테이블, 갱신 주기를 명확히 정해야 한다.
데이터 품질과 신뢰성
좋은 아키텍처라도 데이터가 부정확하면 분석과 AI 결과를 믿기 어렵다.
정확성, 완전성, 일관성, 적시성 같은 품질 기준을 설계 단계에서 함께 넣어야 한다.
개인정보 보호와 접근 통제
민감 정보는 수집 단계부터 저장, 처리, 공유, 폐기까지 보호 기준이 필요하다.
역할별 접근 권한, 마스킹, 암호화, 감사 로그 같은 기준을 데이터 구조와 함께 설계해야 한다.
AI 시대의 데이터 준비도
AI/ML 프로젝트는 학습 데이터의 품질, 계보, 편향, 사용 권한이 중요하다.
데이터 아키텍트는 모델을 만들기 전에 신뢰할 수 있는 데이터 기반이 있는지 확인해야 한다.
비용과 성능의 균형
모든 데이터를 무조건 빠르게, 오래, 많이 저장하면 비용이 커진다.
사용 빈도, 보관 기간, 성능 요구사항에 따라 저장소와 처리 방식을 다르게 설계해야 한다.
조직에서 데이터 아키텍트가 필요한 순간
대시보드마다 매출·고객 수가 다르게 나올 때
시스템이 늘어나 데이터 중복과 불일치가 커질 때
데이터 웨어하우스, 데이터 레이크, 레이크하우스를 새로 설계할 때
AI/ML 프로젝트를 시작했지만 학습 데이터 품질과 계보가 불명확할 때
보안, 개인정보, 규제 준수 요구가 강해질 때
신규 서비스가 기존 고객·상품·주문 데이터와 어떻게 연결되어야 할지 불명확할 때
여러 부서가 같은 데이터를 서로 다른 이름과 기준으로 관리할 때
정리
데이터 아키텍트는 조직의 데이터가 일관성 있고 확장 가능하게 관리되도록 설계하는 역할이다.
데이터 엔지니어가 파이프라인을 만들고, DBA가 데이터베이스를 운영하며, 솔루션 아키텍트가 전체 시스템을 설계한다면, 데이터 아키텍트는 그중에서도 데이터의 구조, 의미, 흐름, 품질에 집중한다.
이 직무를 준비하려면 SQL, 데이터 모델링, 데이터베이스, 데이터 엔지니어링, 거버넌스, 비즈니스 이해를 함께 키워야 한다.
문의 : promptcore.kr
다음 노트 주제 제안
데이터 아키텍트와 데이터 엔지니어의 실무 차이
데이터 모델링 기초: 개념 모델, 논리 모델, 물리 모델
데이터 거버넌스와 데이터 품질 관리
참고한 자료
1IBM, What is a data architecture?
2DATAVERSITY, How to Learn Data Governance in Six Months
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.