By Mark 직무 경계의 급격한 해체는 최근 엔터프라이즈 엔지니어링 조직이 겪고 있는 가장 혼란스러운 변화 중 하나입니다. AI 도구와 개발 자동화 파이프라인이 보편화되면서, 기술 도입 초기(1단계)의 거버넌스 문제를 넘어 2단계 확산기에서는 전문가와 비전문가, 그리고 운영과 개발 사이의 직무 경계가 모호해지는 현상이 가속화되고 있습니다. 조직이 “누구나 코딩할 수 있는 시대”라는 명분을 앞세워 각 직군 본연의 도메인 깊이를 무시한 채 비현실적인 스킬셋을 요구하면서, 현장 엔지니어들이 느끼는 정체성 혼란과 시스템 피로도는 한계에 도달했습니다.
얼마 전 옆 부서인 데이터베이스 관리(DBA) 팀의 채용 공고를 보다가 헛웃음이 나왔습니다. 공고의 필수 자격 요건 상단에 굵은 글씨로 적혀 있더군요.
Python, Go 기반 백엔드 애플리케이션 개발 경험 필수, CI/CD 파이프라인 구축 및 IaC 도구 활용 가능자.
전통적으로 트랜잭션 격리 수준을 조정하고, 스키마 락(Lock) 경합을 제어하며, 비상 복구(Disaster Recovery) 시나리오를 설계하던 DBA 포지션에 DBA 스킬은 물론 풀스택 개발자에 준하는 코딩 능력을 요구하고 있었습니다. 알고 보니 최근 반년 동안 적임자를 단 한 명도 뽑지 못해 팀 전체가 결원 상태로 야간 온콜(On-call)을 버티고 있었습니다.
왜 이런 기형적인 상황이 벌어졌을까요? 개발 생산성 지상주의와 AI 어시스턴트 도입의 물결 속에서, 경영진과 개발 부서가 비개발/운영 직군에까지 무리한 확장을 강요했기 때문입니다. 이로 인해 베테랑 운영 인력들은 조직을 이탈하고, 남겨진 시스템의 안정성은 밑바닥부터 흔들리고 있습니다.
비단 DBA만의 문제가 아닙니다. 보안 엔지니어인 저 역시 최근 데이터 엔지니어링, 데이터 사이언스, 그리고 AI 엔지니어의 영역까지 넘나들며 시스템을 만지고 있습니다. 스킬셋의 확장이 엔지니어 개인에게는 무기가 될 수 있지만, 조직 차원에서는 심각한 직무 인플레이션과 직무 경계 붕괴를 낳고 있습니다. 이 현상의 기술적 원인과 조직적 파장을 현장 엔지니어의 시각에서 짚어보겠습니다.
AI 시대라 생긴 재미있는 현상 시리즈
1단계. 도입 초기 (무지·맹신과 오남용)
- 1화 | 유출 & 비용: 개인정보 감별사가 된 AI — 무분별한 데이터 주입과 비용 폭탄
- 2화 | 불신: 베테랑의 연차보다 강력한 ‘AI 피셜’ — 전문가 조언을 밀어낸 AI 맹신과 신뢰 균열
2단계. 확산기 (역할 파괴와 공헌도 갈등)
- 3화 | 착각: 관리자의 바이브코딩 망상 — 실무 난이도 과소평가와 섣부른 직접 코딩
- 4화 | 혼돈: DBA 채용공고에 코딩이 들어간 이유 — 전 직군 개발 요구와 직무 경계 붕괴
- 5화 | 폄하: “AI가 짰는데 넌 뭐 했어?” — 디버깅과 설계 기여도를 지우는 성과 평가 왜곡
3단계. 심화 및 말기 (기술 부채 폭발과 통제 상실)
- 6화 | 배신: 당신이 알던 그 AI가 아닙니다 — 컨텍스트 한계와 비결정론이 부른 최종 파국
- 7화 | 부채: 기획자의 코딩, 그리고 쌓이는 빚 — 아키텍처 없는 양산이 부른 거대한 기술 부채
- 8화 | 방심: 취약점? AI로 갈아 끼우면 그만? — 의존성 이해 부재가 부른 대형 보안 사고
목차
2단계. 확산기: 직무 경계 침범과 인플레이션의 전조
소프트웨어 개발 문화가 클라우드 네이티브로 완전히 전환되고 GitOps 기반의 지속적 통합/지속적 배포(CI/CD)가 표준으로 자리 잡으면서, 운영 조직에 대한 개발 조직의 입김은 그 어느 때보다 강해졌습니다. 여기에 “AI를 쓰면 비전공자도 코딩한다”는 환상이 기름을 부었습니다.
“DB 변경도 코드처럼 배포하자”는 요구의 명암
발단은 데이터베이스 변경 관리(Database Change Management)의 현대화 요구였습니다. 개발팀 입장에서는 애플리케이션 코드를 깃허브(GitHub)에 푸시하면 CI/CD 파이프라인을 타고 컨테이너가 빌드되어 쿠버네티스(Kubernetes) 클러스터에 배포되는데, 유독 DB 스키마 마이그레이션(DDL)과 데이터 패치(DML) 단계에서 배포 병목이 발생한다고 느낀 것입니다.
- 개발팀의 요구: “우리 배포 파이프라인에 Liquibase나 Flyway 같은 마이그레이션 도구를 붙이고, 변경 스크립트 검증과 실행을 완전히 자동화하는 내부 오케스트레이션 프로그램을 DBA가 직접 짜서 CI/CD에 연동해 달라.”
- 경영진의 시선: “요즘 AI 코딩 도구도 많은데, DBA도 파이썬이나 고(Go)로 내부 툴링(Internal Tooling) 정도는 직접 개발해서 셀프서비스 포털을 만들어야 생산성이 오르는 것 아닌가?”
취지는 그럴듯해 보입니다. 데이터베이스 배포 자동화는 지속 가능한 시스템을 위한 필수 과제처럼 들립니다. 하지만 이 요구 뒤에는 데이터베이스 운영이라는 영역이 가진 물리적 위험성에 대한 무지가 깔려 있었습니다.
아키텍처 충돌: 무중단 파이프라인의 환상과 락 경합의 현실
애플리케이션은 무상태(Stateless) 아키텍처를 지향하기 때문에 컨테이너가 죽으면 다시 띄우면 되고, 배포가 꼬이면 카나리(Canary) 롤백을 치면 그만입니다. 그러나 데이터베이스는 상태(Stateful)의 정점에 있는 시스템입니다.
1. DDL 실행 시 발생하는 메타데이터 락(Metadata Lock)의 공포
전문 DBA가 스키마 변경 요청을 받았을 때 가장 먼저 하는 일은 단순히 SQL 문법을 검사하는 것이 아닙니다.
- 수억 건의 레코드가 적재된 파티션 테이블에 인덱스를 추가할 때, 이 작업이 테이블 스페이스에 미칠 I/O 부하를 계산합니다.
- ALTER TABLE 명령어가 실행되는 찰나의 순간에 발생하는 메타데이터 락(MDL)이 롱 러닝 트랜잭션(Long-running Transaction)과 얽혀 후속 쿼리들을 줄줄이 대기열(Queue)에 묶어버리지 않는지 커넥션 풀 상태를 점검합니다.
- 필요하다면
pt-online-schema-change나gh-ost같은 온라인 스키마 변경 도구를 동원해 복제 지연(Replication Lag)을 모니터링하며 새벽 시간대에 수작업으로 트래픽을 관찰합니다.
2. CI/CD 파이프라인 만능주의가 불러온 대형 장애
개발팀과 관리자가 밀어붙인 자동화 파이프라인은 이 섬세한 위험 제어를 ‘코드 자동 실행’으로 치환해 버렸습니다.
[ 개발팀이 꿈꾼 이상적인 GitOps DB 파이프라인 ]
PR 생성 (DDL 스크립트)
→ CI 린트(Lint) 통과
→ 승인 버튼 클릭
→ 배포 파이프라인이 프로덕션 DB에 즉시 실행현실은 참담했습니다. 자동화 도구는 SQL 구문이 문법에 맞는지(Syntax Check)는 검증해주지만, 현재 DB 인스턴스의 버퍼 풀 히트율(Buffer Pool Hit Ratio)이나 슬레이브 노드의 복제 딜레이 상태를 종합적으로 판단하지 못합니다.
피크 타임 직전에 머지된 PR 하나가 테이블 전체에 배타적 락(Exclusive Lock)을 걸어버렸고, 순식간에 WAS의 커넥션 풀이 고갈되며 전사 서비스가 마비되는 대형 장애가 터졌습니다. 장애 회고 회의에서 개발팀은 “파이프라인이 정상적으로 스크립트를 밀어 넣었는데 왜 DB가 죽었는지 모르겠다”고 발을 뺐고, 책임의 화살은 고스란히 DBA들에게 쏟아졌습니다.
프로그래밍 압박과 대량 퇴사: 직무 경계 해체가 부른 운영 붕괴
이 장애 이후 내려진 경영진의 처방은 더 황당했습니다. “자동화 파이프라인의 예외 처리가 부족했으니, DBA 팀이 직접 백엔드 API를 개발해서 배포 전후의 복잡한 헬스체크와 자동 롤백을 수행하는 인하우스 DB 변경 플랫폼을 만들어라”는 지시였습니다.
직무 정체성의 강제 변환과 이탈
DBA들에게 본업인 쿼리 튜닝, 스토리지 엔진 최적화, 백업 검증 외에 ‘풀스택 백엔드 프로그래머’의 R&R이 얹어졌습니다.
- 스프링 부트(Spring Boot)나 패스트API(FastAPI)로 사내 승인 시스템을 만들고,
- 웹훅(Webhook)을 받아 슬랙 봇을 띄우며,
- 프론트엔드 화면까지 직접 붙여 셀프서비스 도구를 구현하라는 압박이 매주 스프린트 회의마다 이어졌습니다.
전통적인 DBA들은 극심한 피로감과 정체성 혼란에 시달렸습니다. 수십 년간 갈고닦은 데이터베이스 내부 구조(Internals) 지식은 “자동화를 못 하는 구시대적 기술” 취급을 받았고, 하루 종일 익숙하지 않은 파이썬 문법과 도커(Docker) 빌드 에러를 잡느라 본연의 DB 모니터링 업무는 뒷전으로 밀렸습니다.
결과는 베테랑 인력들의 연쇄 퇴사였습니다. 팀의 중심을 잡던 시니어 DBA들이 줄줄이 회사를 떠났습니다. 그들이 나가자마자 사내 시스템은 심각한 운영 공백에 직면했습니다. 주기적인 인덱스 조각화(Fragmentation) 정리, 슬로우 쿼리 튜닝, 장애 발생 시 시점 복구(Point-in-Time Recovery) 테스트 등 시스템의 생명을 연장하던 필수 작업들이 일제히 올스톱되었습니다.
6개월째 공석인 채용 공고: 직무 인플레이션의 부메랑
핵심 인력들이 이탈하자 다급해진 회사는 채용 공고를 올렸습니다. 하지만 그 공고의 내용은 기존의 문제를 해결하기는커녕 더욱 심화시키고 있었습니다.
[ 현실과 타협하지 못한 DBA 채용 공고 ]
* 주요 업무:
- 전사 대규모 RDBMS/NoSQL 아키텍처 설계 및 튜닝
- 데이터베이스 배포 자동화 파이프라인 개발 및 운영
- 사내 DB 셀프서비스 포털 백엔드 API 개발 (Python/Go)
* 자격 요건:
- 대용량 트래픽 환경의 DBA 경력 5년 이상
- 웹 애플리케이션 개발 및 마이크로서비스 아키텍처(MSA) 경험자
- CI/CD 파이프라인(GitLab, ArgoCD 등) 직접 구축 경험자시장에 존재하지 않는 ‘유니콘’을 찾는 오류
이 채용 공고가 6개월 동안 단 한 명의 적임자도 찾지 못한 이유는 명백합니다.
- 상충되는 커리어 경로: 고도의 데이터베이스 엔지니어링 역량을 갖추기 위해 10년 넘게 커널과 락 메커니즘을 파고든 엔지니어는 굳이 백엔드 웹 애플리케이션 개발에 매달리지 않습니다. 반대로 Go나 Python으로 능숙하게 마이크로서비스와 파이프라인을 구축하는 뛰어난 백엔드 엔지니어는 데이터베이스 인터널스에 인생을 걸지 않습니다.
- 비현실적인 처우: 시장에서 두 가지 영역을 모두 최상위 수준으로 다루는 인재는 소위 ‘유니콘’입니다. 천문학적인 연봉을 줘야 모셔올 수 있는 스펙입니다. 그러나 회사는 일반 시니어 DBA 연봉 테이블을 제시하며 두 배의 역할을 요구하고 있습니다.
- 직무 인플레이션의 함정: “AI 시대니까 누구나 코딩하고, 누구나 인프라를 본다”는 막연한 기대감이 채용 시장의 요구 스펙을 비정상적으로 부풀려 놓았습니다. 그 결과 회사는 아무도 뽑지 못한 채 기존 시스템을 방치하고 있고, 구직자들은 비현실적인 요구 조건 앞에 지원 자체를 포기하고 있습니다.
전 직군 개발 요구의 시대: 보안 엔지니어의 개인적 고백
솔직히 고백하자면, 이 직무 경계의 붕괴는 저 자신에게도 현재진행형인 고민입니다.
저는 조직 내에서 보안 엔지니어라는 직함을 달고 일하고 있습니다. 하지만 제 일주일 업무 로그를 뜯어보면 보안에만 머물러 있지 않습니다.
- 사내 대규모 시스템 로그에서 이상 징후를 탐지하기 위해 아파치 카프카(Kafka)와 스파크(Spark) 파이프라인을 직접 만지는 데이터 엔지니어 역할을 수행합니다.
- 탐지 모델의 피처(Feature)를 엔지니어링하고 노이즈를 거르기 위해 판다스(Pandas)와 머신러닝 라이브러리를 돌리며 데이터 사이언티스트의 영역을 침범합니다.
- 최근에는 사내 지식 베이스와 연동된 RAG 시스템의 보안 취약점을 점검하고 방어하기 위해 임베딩 모델과 벡터 데이터베이스를 직접 세팅하는 AI 엔지니어의 일까지 도맡아 하고 있습니다.
멀티 플레이어의 유용함과 전문성의 희석
엔지니어 개인이 다양한 도메인을 넓게 이해하고 직접 구현할 수 있다는 것은 분명 강력한 무기입니다. 특히 AI 코딩 어시스턴트의 발전 덕분에 비전문 분야의 보일러플레이트 코드를 짜거나 인프라 템플릿을 만드는 진입 장벽이 극적으로 낮아진 것은 사실입니다. 저 역시 AI의 도움을 받아 데이터 파이프라인 스크립트를 작성할 때의 압도적인 속도감에 놀라곤 합니다.
하지만 이 확장이 조직 전체의 기본 전제로 깔리는 순간 치명적인 부작용이 발생합니다.
- 얕은 전문성의 범람: 모든 것을 조금씩 할 줄 알지만, 시스템이 극한의 부하에 직면했을 때 커널 레벨이나 스토리지 엔진 레벨에서 근본 원인을 파헤치는 ‘송곳 같은 깊이’는 사라집니다.
- 직무 피로도와 번아웃: 보안 위협을 방어하고 컴플라이언스를 챙기는 본업만으로도 벅찬 상황에서, 데이터 파이프라인의 레이턴시를 튜닝하고 AI 모델의 서빙 성능까지 신경 써야 하는 멀티태스킹은 엔지니어를 빠르게 소진시킵니다.
- 조직적 책임의 실종: 모두가 개발을 하고 모두가 운영을 건드리다 보니, 정작 데이터 무결성이 깨지거나 보안 사고가 터졌을 때 “그 파이프라인은 누가 최종 책임자인가?”라는 질문에 아무도 명확한 답을 내놓지 못합니다.
지속 가능한 엔지니어링: 직무 경계의 건강한 복원
전 직군에 코딩과 자동화를 요구하는 유행 추종형 직무 확장은 이제 멈춰야 합니다. 기술 조직이 건강한 생산성과 시스템 안정성을 되찾기 위해서는 무너진 직무 경계를 다시 올바르게 세워야 합니다.
[ 건강한 엔지니어링 협업 모델 ]
+--------------------------------------------------------+
| 플랫폼 엔지니어링 팀 (Platform Engineering) |
| - CI/CD 파이프라인, 공통 개발 프레임워크, 셀프서비스 포털 구축 |
+--------------------------------------------------------+
│ 도구 및 인프라 제공
┌───────────────────────┴───────────────────────┐
▼ ▼
+--------------------------+ +--------------------------+
| 도메인 전문가 (DBA) | | 도메인 전문가 (보안) |
| - 트랜잭션 무결성, 락 제어 | | - 위협 모델링, 거버넌스 통제 |
| - 스토리지 엔진 및 성능 튜닝 | | - 취약점 분석 및 보안 감사 |
+--------------------------+ +--------------------------+
1. 도메인 전문성과 툴링 역량의 분리
DBA에게 웹 애플리케이션 개발을 요구할 것이 아니라, 플랫폼 엔지니어링(Platform Engineering) 팀이 DBA가 정의한 검증 룰셋(Policy as Code)을 수용할 수 있는 파이프라인 뼈대를 만들어 주어야 합니다. DBA는 데이터의 무결성과 복구 시나리오라는 본질적인 전문성에 집중하고, 프로그래밍은 그 도메인 지식을 코드로 표준화하는 협업 체계로 풀어야 합니다.
2. 채용 공고의 거품 걷어내기
채용 공고에서 유행하는 모든 키워드를 나열하는 직무 인플레이션을 걷어내야 합니다. 진짜 필요한 역량이 ‘무중단 대규모 데이터베이스 운영’인지, 아니면 ‘사내 자동화 도구 개발’인지 우선순위를 명확히 분리해야 합니다. 존재하지도 않는 가상의 올라운더를 찾느라 팀 전체를 결원 상태로 방치하는 것은 경영진의 명백한 직무유기입니다.
3. T자형 인재에 대한 올바른 정의
T자형 인재란 ‘모든 것을 개발할 수 있는 사람’을 뜻하지 않습니다. 자신의 도메인에 수직적인 깊은 뿌리(Vertical Depth)를 확고히 내린 상태에서, 인접 직군과 소통할 수 있는 수준의 수평적 시야(Horizontal Breadth)를 갖춘 사람을 의미합니다. AI 도구는 그 수평적 소통과 가벼운 구현을 보조하는 수단이어야지, 본인의 수직적 전문성을 대체하거나 다른 직군의 본업을 통째로 떠안는 구실이 되어서는 안 됩니다.
기술의 만능주의가 남긴 상처
소프트웨어 개발의 역사는 언제나 추상화와 자동화의 역사였습니다. 도구가 발전할수록 사람이 하는 일은 편해져야 마땅합니다. 하지만 지금의 엔터프라이즈 환경은 AI와 자동화라는 도구의 등장을 빌미로, 개별 엔지니어에게 감당하기 힘든 다중 직무의 짐을 지우고 있습니다.
DBA 채용 공고에 코딩 필수 요건이 박히고 6개월 동안 공석이 이어지는 현실은, 기술의 진보가 가져온 축복이 아니라 직무 경계에 대한 몰이해가 낳은 기형적인 참사입니다. 모든 직군이 코딩을 하고 모든 직군이 인프라를 만질 수 있다는 환상을 걷어내지 않는다면, 조직은 조만간 그 어떤 시스템도 깊이 있게 책임지지 못하는 기술적 파산 상태에 직면하게 될 것입니다. 다음 화에서는 “AI가 코딩해 줬는데 너는 한 게 뭐냐”라며 실무자의 보이지 않는 설계와 디버깅 노력을 깎아내리는 성과 평가의 왜곡 현상을 짚어보겠습니다.