Lv.1 입문RDBMS(범용)

2026.04.1918분 읽기Lv.1 입문

시리즈DA? DBA? DBE? — 직군 이해하기 · 파트 2/4시리즈 허브 보기

DA? DBA? DBE? — Part 2: 실무 비교 (현장에서는 어떻게 다른가)

Part 1에서 정리한 DA·DBA·DBE의 정의는 현장에서 그대로 격자에 맞춰지지 않습니다. 이번 글에서는 **대기업·금융**, **스타트업·클라우드 네이티브**, **SI·프로젝트** 같은 환경별로 역할이 어떻게 갈라지거나 한 사람에게 몰리는지 보고, 하루 업무 흐름으로 세 직군의 리듬을 비교합니다. 쿼리 튜닝 책임, 설계와 운영 사이의 괴리, 경영진의 기대와 현실 사이의 간극처럼 자주 터지는 갈등을 짚은 뒤, 협업이 잘 되는 팀의 공통 조건을 정리합니다. 다음 Part 3에서는 커리어 로드맵을 이어갑니다.

시리즈 구성

Part 1 — 개념 정리: DA / DBA / DBE, 각각 뭐 하는 사람인가?

Part 2 — 실무 비교: 실제 현장에서의 차이 (현재 편)

Part 3 — 커리어 로드맵: 어떻게 시작하고, 어디까지 성장할 수 있나? (연재 예정)

Part 4 — 2026년 현재: AI·클라우드와 이 직군들의 자리 (연재 예정)

1. 들어가며 — 교과서와 현장 사이

Part 1에서 DA·DBA·DBE가 각각 무엇을 하는 사람인지 개념을 정리했습니다.

현실은 교과서처럼 깔끔하게 나뉘지 않습니다. 현장 DBA 글에서 자주 등장하는 말이 있습니다.

"DBA로 입사했는데 R&R이 명확하지 않은 곳이 너무 많았습니다."

— RastaLion.dev, 현직 DBA 블로그

같은 "DBA"라는 직함이라도 대기업·금융권·스타트업·SI에 따라 하루가 달라집니다. Part 2에서는 그 차이를 조직 유형·일과·갈등 포인트로 나누어 봅니다.

2. 회사 규모·유형별로 역할은 어떻게 달라지나

대기업·금융권

세 직군이 가장 뚜렷하게 나뉘는 편입니다. 오랜 기간 DBA 포지션이 유지된 조직은 회사에 맞는 역할 정의가 이미 있는 경우가 많습니다. DA는 데이터 모델링과 표준화에 가깝고, DBA는 운영·튜닝·백업·장애 대응에 집중하며, 설계나 엔진 설치·유지보수 일부는 외부 업체가 맡는 구조도 흔합니다.

Oracle 중심 환경이 오래 유지된 조직에서는 이런 분업이 전통적으로 강했습니다. 분업이 분명한 만큼 한 역할만 오래 맡으면 시야가 좁아질 수 있다는 트레이드오프도 있습니다.

스타트업·클라우드 네이티브

규모가 작거나 DB 조직이 나중에 생기면 R&R과 정책을 스스로 정해야 하는 경우가 많습니다. DA·DBA·DBE의 이름은 있어도 실제로는 한 사람이 모델링부터 쿼리 튜닝, 모니터링·배포 자동화까지 맡는 일이 생깁니다.

클라우드 매니지드 서비스를 쓰면 인프라·패치 일부가 벤더 쪽으로 넘어가고, 설계·구축·개선 업무 비중이 상대적으로 커지는 경향이 있다는 관찰도 있습니다. 다만 온프레미스와 규제 산업에서는 패치·보안·업그레이드·장애 대응이 여전히 중심인 곳이 많습니다.

SI·프로젝트 환경

프로젝트마다 역할이 다시 짜입니다. DA 비중이 크고, 초기에 데이터 모델과 표준이 핵심 산출물이 되는 경우가 많습니다. SI를 오래 하면 DA에 가까운 일이 쌓이지만, 일반 서비스 운영 조직으로 옮기면 설계는 개발 조직 중심으로 돌아가 DA 전용 역할이 줄어드는 식으로 환경에 따라 체감 역할이 바뀝니다.

프로젝트가 끝나면 유지보수 조직으로 넘어가거나 다음 프로젝트로 이동하는 구조라, 장기 운영만 담당하는 DBA와는 성장 경로와 스트레스 패턴이 다릅니다.

3. 하루의 업무 흐름: DA vs DBA vs DBE

말보다 일과를 나란히 두면 차이가 드러납니다. 아래 블록은 실행용 코드가 아니라, 역할별 리듬을 보여주는 설명용 text 예시입니다.

DA의 하루 (예시)

09:00  기획 미팅 — 신규 기능 요구사항 정리
10:30  ERD 작성 — 엔티티·관계 정의
13:00  개발 리뷰 — 모델링 초안 검토
15:00  데이터 표준 문서 업데이트(네이밍, 코드값)
16:30  DBA와 협의 — 물리 설계·인덱스 방향
17:30  메타데이터 시스템 반영

미팅과 문서·모델링 도구 비중이 큽니다. ERWin, 데이터 모델러, PlantUML 등 조직 표준에 맞는 툴을 씁니다.

DBA의 하루 (예시)

08:30  야간 배치·슬로우 쿼리 로그 확인
09:00  DDL 요청 처리 — 테이블·인덱스
10:30  장애·락 이슈 원인 분석
13:30  쿼리 튜닝 요청 — 실행 계획 검토
15:00  백업·복구 점검
16:30  용량·성능 보고
17:30  배포 스크립트 검토

계획이 있어도 장애 한 건에 하루가 바뀌기 쉽습니다. 상시 대응 가능성을 전제로 한 역할입니다.

DBE의 하루 (예시)

09:00  마이그레이션·배포 스크립트 개발
11:00  샤딩·파티션 전략 검토
13:30  모니터링·알림 파이프라인 개선
15:00  신규 서비스 DB 아키텍처 리뷰
16:30  레플리케이션 지연 알림 버그 수정
17:30  코드 리뷰

개발 업무와 가장 가깝습니다. 코드·리뷰·자동화 비중이 큽니다.

4. 세 직군 사이에서 자주 생기는 갈등

쿼리 튜닝은 누구 책임인가

개발자는 느린 SQL을 DBA에게 넘기고, DBA는 SQL 구조 자체가 문제라고 보는 장면이 반복됩니다. 복잡한 SQL은 튜닝만으로 한계가 있는 경우가 많습니다.

현실적인 나눔은 이렇게 가져가는 편이 많습니다. 작성 책임은 개발, 실행 계획·인덱스·운영 측면 튜닝은 DBA, 그리고 양쪽 모두 기본적인 SQL·실행 계획 이해를 갖추는 것입니다. 튜닝을 DBA만의 영역으로 두기 어려워진 환경도 많습니다.

DA의 설계와 운영 현실이 어긋날 때

DA가 설계한 논리 모델이 운영 조건에서 구현하기 부담스러울 수 있고, 반대로 DBA가 운영 편의만으로 스키마를 바꿔 정합성 논의가 흔들리기도 합니다. 설계 관점과 운영 관점을 초기에 맞춰 두지 않으면 나중에 비용이 커집니다.

경영진과 실무의 기대 차이

조용히 잘 돌아가는 동안 DBA의 가치가 드러나지 않다가, 장애 때 비로소 부각되는 패턴도 있습니다. 클라우드와 자동화가 늘수록 "DB는 개발자도 한다"는 인식과 실제 필요 역량 사이의 간극이 벌어질 수 있습니다. 이는 단순히 한쪽이 틀렸다기보다 가시성과 지표 설계의 문제에 가깝습니다.

5. 협업이 잘 되는 팀의 공통점

역할 문서화: 운영·구축·설계 경계, 온프레미스·클라우드, 주력 DB에 따라 무엇이 팀 안에서 해결되고 무엇이 외부인지를 초기에 적어 두는 것이 갈등을 줄입니다.

상호 언어 정렬: DA는 비즈니스와 개발 사이, DBA는 인프라와 애플리케이션 사이, DBE는 개발 프로세스와 DB 제약을 동시에 말할 수 있어야 합니다.

개발 조직의 기본 DB 소양: 모니터링 항목을 정하고 툴을 붙일 때도 부하·운영 관점이 필요합니다. DB는 결국 팀 전체의 관심사로 두는 편이 안전합니다.

6. 환경별 역할 패턴 한눈에 보기

규모·유형별로 역할이 갈라지는지, 한 덩어리로 겹치는지를 흐름으로 보면 다음과 같습니다.

아래 표는 같은 내용을 표 형태로 요약한 것입니다.

환경	역할 분리	DBA에 가까운 일상	DA·DBE 쪽 경향
대기업·금융	비교적 뚜렷	장애·백업·패치·규정 준수	DA 전담·DBE는 과제별
스타트업·클라우드	자주 혼합	매니지드+자동화·설계까지 겸임	DBE 성격의 자동화 비중↑
SI·프로젝트	프로젝트마다 재편	구축·전환·단기 튜닝	DA 모델링 비중↑, 종료 후 유지보수로 이동

표는 경향일 뿐이며, 같은 유형 안에서도 팀 규모·레거시·규제 때문에 실제 그림은 달라집니다.

7. 마치며 — Part 2 요약

세 직군의 경계는 조직 규모·산업·레거시에 따라 유동적입니다.
스타트업일수록 역할이 겹치고, 대기업·금융일수록 분업이 뚜렷한 편입니다.
자주 터지는 갈등은 쿼리·성능 책임, 설계와 운영의 간극, 역할 가시성 주변에 모입니다.
협업은 R&R을 글로 고정하고, 서로의 제약을 언어로 맞추는 일에서부터 시작합니다.

다음 Part 3에서는 각 직군으로 어떻게 들어가고, 어디까지 성장할 수 있는지 커리어 경로를 구체적으로 정리합니다.

참고 자료

문서·규범 (주장 보조)

Microsoft Learn — 쿼리 튜닝 권장 사항 (SQL Server) — 실행 계획·튜닝 대화의 제품 문서 기준.
Oracle Help Center — Database Administrator (19c) — DBA 업무를 제품 가이드 관점에서 엮을 때의 참고 출발점.
AWS — 공동 책임 모델 — 매니지드 서비스에서 벤더·고객 역할 경계를 설명할 때 자주 인용되는 프레임.
DAMA International — Body of Knowledge (DMBOK) — DA·데이터 관리 역할을 체계화할 때 널리 쓰는 참조.
Google — Site Reliability Engineering Workbook · 데이터 처리 파이프라인 — 파이프라인·운영 자동화 맥락에서의 엔지니어링 참고.

추가 읽을거리

DBA 혹은 DB팀의 R&R을 정의할 때 — RastaLion.dev
DBA 입장에서 바라보는 데이터베이스 직군 이야기 — RastaLion.dev
최근 이직을 준비하면서 DBA로 느낀 것들 — RastaLion.dev
DBA 직업군의 질이 떨어지고 있다 — Voyager of Linux
현직 DBA 질문받습니다 — 리멤버 커뮤니티
쿼리 튜닝 실무(Feat. MS-SQL) — velog