도메인 전문성이 AI 시대의 핵심 경쟁력입니다. Agentic AI가 코드 생산을 자동화하면서 이제 진짜 병목은 “만들 수 있는가”가 아니라 “맞는지 판별할 수 있는가”로 이동했고, 이 글에서는 그 의미와 직군별 실전 활용법을 함께 풀어드립니다.
도메인 전문성이 AI 시대의 유일한 해자가 된 이유, 알고 계셨나요?
안녕하세요! “AI가 내 일자리를 빼앗을까?”라는 질문, 저도 솔직히 꽤 오래 고민했거든요 😮 그런데 최근 GeekNews에서 아주 인상적인 아티클을 발견했어요. Bret Horsting이라는 개발자가 쓴 “Domain Expertise Has Always Been the Real Moat”인데, 읽으면서 관점이 완전히 바뀌었습니다. 코딩 실력보다 현장에서 10년 구르며 쌓은 도메인 감각이 AI 시대에 오히려 더 빛난다는 이야기거든요.
GeekNews 커뮤니티 반응도 뜨거웠어요. xguru 님은 “소프트웨어 개발 자체도 하나의 도메인이고 그걸 잘하는 것도 전문 기술”이라며 날카로운 반론을 제기했고, devpain 님은 “암묵지가 결국 프롬프트로 조금씩 넘어가는 상황”이라고 짚었죠. 그래서 원문을 끝까지 다 읽고 제 관점으로 정리해봤습니다.
📌 목차
- Agentic AI란? 일반인 눈높이로 설명
- 소프트웨어 개발에서 진짜 어려운 부분
- 두 유형의 인재 비교: 도메인 전문가 vs 제너럴리스트
- 직군별 실전 프롬프트 3가지
- 비대칭 붕괴: 왜 엔지니어의 경로만 사라졌나
- 숙련 엔지니어를 위한 베팅 방향
- 이런 분들께 적극 추천합니다
- 자주 묻는 질문 (FAQ)
1. Agentic AI란? 일반인 눈높이로 설명
먼저 이 글의 핵심 개념인 Agentic AI를 짚고 넘어갈게요. 일반적인 AI가 “질문하면 대답해주는” 수동적 도구였다면, Agentic AI는 한 발 더 나아가 스스로 판단하고, 계획을 세우고, 실제로 행동까지 하는 AI를 말해요. Claude Code, GitHub Copilot Workspace, Devin 같은 도구들이 여기에 해당합니다.
① 기존 AI vs Agentic AI — 무엇이 다른가
기존 ChatGPT 같은 AI는 “이 코드 어떻게 짜요?”라고 물으면 대답만 줍니다. 반면 Agentic AI는 “급여 시스템 만들어줘”라고 하면 스스로 파일을 만들고, 코드를 작성하고, 테스트까지 돌린 후 결과를 보고합니다. 사람이 요청만 하면 AI가 여러 단계를 자율적으로 수행하는 거예요. 이게 Bret의 글에서 말하는 “모델 구축과 소프트웨어 생산 사이의 연결을 끊었다”는 표현의 의미입니다.
💡 실제 활용 시나리오 예시:
보험사 운영팀 직원이 “이 계약 데이터로 갱신 알림 자동화 스크립트 만들어줘”라고 Agentic AI에 요청하면, AI가 코드 작성 → 테스트 → 파일 저장까지 10분 만에 완료합니다. 예전이라면 개발팀 티켓을 올리고 2~3일 기다려야 했던 일이죠.
② 병목의 이동 — “만들 수 있는가”에서 “맞는지 아는가”로
Bret이 핵심을 이렇게 요약합니다: Agentic AI는 핵심 제약을 “만들 수 있는가(can you build it?)”에서 “맞는지 판별할 수 있는가(can you tell if it’s right?)”로 옮겼다고요. 코드 생산이 더 이상 병목이 아닌 세상에서, 진짜 병목은 출력의 정확성을 검증하는 능력이 됩니다. 그리고 그 능력은 바로 도메인 전문성에서 나옵니다.
💡 실제 활용 시나리오 예시:
물류 배차 담당자 A씨는 코딩을 전혀 모르지만 Agentic AI에 배차 규칙을 설명해 3시간 만에 스케줄 자동화 도구를 만들었습니다. AI가 생성한 스케줄 중 특정 기사가 법정 근무시간을 초과했다는 걸 즉시 발견한 건 10년 경력의 A씨였습니다.
2. 소프트웨어 개발에서 진짜 어려운 부분
Bret은 원문에서 이렇게 말합니다: “The hard part of writing software has never been the writing.” 코드를 타이핑하는 행위 자체는 어렵지 않았다는 거예요. 진짜 어려운 건 그 전 단계, 즉 현실 세계의 복잡한 규칙을 머릿속에 모델로 세우는 것이었습니다. 코드는 그 이해를 옮겨 적은 전사(transcription)였을 뿐이에요.
1) 급여 시스템 사례 — 코드 전에 알아야 할 것들
저자가 직접 경험한 예시가 생생합니다. 급여 시스템을 만들기 전에 이해해야 했던 것들: 압류 공제(garnishment), 세전 공제의 우선순위, 급여 기간이 임금률 변경 시점에 걸쳤을 때 어떻게 처리하는지. 이 모든 게 법과 규제에 묶인 도메인 지식이었어요. 개발자가 이 지식 없이 코드를 짰다면? 기술적으로 완벽하지만 법적으로 틀린 시스템이 탄생했겠죠.
💡 실제 활용 시나리오 예시:
HR 스타트업 개발자가 급여 계산 모듈을 Agentic AI로 구현했습니다. 코드는 컴파일되고 테스트도 통과했지만, 3개월 후 특정 주의 최저임금 규정을 반영하지 않은 계산 오류가 감사에서 발견됐습니다. AI는 기술적으로 완벽한 코드를 썼지만, 무엇이 맞는지는 몰랐던 거죠.
2) 대중교통 앱 사례 — GTFS 피드의 세계
또 다른 사례도 흥미로워요. 대중교통 앱 개발 전에 저자가 배워야 했던 것들: GTFS 피드가 무엇인지, trip과 route가 왜 다른지, 정시 출발 버스가 어떻게 여전히 “틀린” 정보를 줄 수 있는지. 이건 API 문서를 읽는다고 알 수 있는 게 아니에요. 수백 번 대중교통을 타보거나 운행 시스템을 관리해본 사람만이 아는 종류의 지식이죠.
💡 실제 활용 시나리오 예시:
교통 앱 스타트업이 Agentic AI로 실시간 도착 알림 기능을 구현했습니다. 코드는 완벽히 작동했지만, 버스 기사 출신 QA 담당자가 “명목상 정시인 버스가 실제론 5분 지연된 케이스”를 즉시 짚어냈어요. 10년 운행 경험 없이는 생각조차 못 하는 엣지케이스였습니다.
3. 두 유형의 인재 비교: 도메인 전문가 vs 제너럴리스트
원문의 핵심은 두 유형의 인재를 대비시키는 부분이에요. 이 이분법은 단순한 비교가 아니라, AI 시대에 각자의 강점과 약점이 어떻게 재편되는지를 보여주는 프레임입니다.
| 구분 | 도메인 전문가 | 제너럴리스트 엔지니어 |
|---|---|---|
| 강점 | Ground truth 보유, 출력 정확성 즉시 판별 | 시스템 설계, 신뢰성, 아키텍처 검증 |
| 약점 | 코드 읽기·작성 불가 | 도메인 정확성 검증 불가(오라클 없음) |
| AI 이후 변화 | 약점이 Agentic AI로 보완됨 ✅ | 핵심 강점(코딩)의 가치가 하락함 ⚠️ |
!["도메인]("https://images.unsplash.com/photo-1454165804606-c3d57bc86b40?w=800&auto=format&fit=crop&q=60" "\"도메인")
① 도메인 전문가 — Ground Truth를 가진 사람
물류 배차 담당자, 임상 코더, 보험계리사. 이들은 스택 트레이스를 못 읽고, 해시맵과 리스트의 차이도 설명 못 합니다. 하지만 AI가 생성한 스케줄을 보고 “이 기사는 이 근무를 법적으로 할 수 없어요”를 0.1초 만에 알아챕니다. 10년간 입력과 출력 속에서 살아온 암묵지(tacit knowledge)가 있기 때문이에요. Bret은 이걸 “AI가 줄 수 없는 ground truth”라고 불렀어요. 부족했던 코드 생산 능력을 Agentic AI가 정확히 보완해줬습니다.
💡 실제 활용 시나리오 예시:
임상 코더 15년 경력의 B씨가 Agentic AI로 만든 의료 청구 자동화 시스템을 검수했습니다. AI가 생성한 코드 중 “이 시술 코드 조합은 건강보험에서 동시 청구 불가”라는 규정 위반을 발견, 수정 전 잠재적 환수 규모가 수억 원에 달했습니다.
② 제너럴리스트 엔지니어 — 오라클이 없는 사람
강력한 제너럴리스트 엔지니어는 무엇이든 설계하고 새벽 2시에도 시스템이 무너지지 않게 할 줄 압니다. 하지만 임상 코딩 도메인에 투입되면 그럴듯해 보이는 오답과 정답을 구분하지 못해요. Bret의 표현이 정확합니다: “엔지니어에게는 오라클(oracle)이 없다.” 소프트웨어가 잘 만들어졌는지는 검증해도, 도메인 기준의 정확성은 검증 못 합니다. 정확성이 그가 머릿속에 갖지 못한 도메인으로 정의되기 때문이에요.
💡 실제 활용 시나리오 예시:
핀테크 스타트업의 시니어 백엔드 엔지니어가 Agentic AI와 함께 펀드 정산 모듈을 개발했습니다. CI/CD 파이프라인은 완벽하고 유닛 테스트도 통과했지만, 펀드 회계 도메인 지식 부족으로 “기준가 산정 시 T+1 결제일 처리” 오류가 3개월 후에야 발견됐습니다.
4. 직군별 실전 프롬프트 3가지
이제 가장 실용적인 부분입니다. 도메인 전문성을 가진 분들이 Agentic AI와 협업할 때 바로 쓸 수 있는 프롬프트를 직군별로 정리했어요. 핵심 원칙은 하나입니다: 내 도메인 규칙을 AI에게 먼저 명시하라. AI에게 “무엇이 맞는지”의 기준을 내가 직접 제공해야만 출력을 신뢰할 수 있습니다.
1) 데이터 사이언티스트 — 도메인 규칙 주입 프롬프트
데이터 분석 결과의 의미는 숫자가 아니라 비즈니스 맥락에서 나옵니다. “분석해줘”가 아니라, 이 분야에서 “정상”과 “이상”을 구분하는 기준을 먼저 알려줘야 해요. 도메인 규칙 없는 AI 분석은 통계적으로 맞지만 비즈니스적으로 틀린 결과를 낼 수 있습니다.
당신은 [산업명] 데이터 분석 전문가입니다.
아래 도메인 규칙을 분석의 기준으로 반드시 적용하세요.
[도메인 규칙 예시 - 의료 청구 분석]
1. 동일 환자·동일 날짜에 외래 진료 코드 99213과 99214는 동시 청구 불가
2. 수술 후 90일 이내 동일 부위 재수술은 글로벌 피리어드(Global Period) 적용
3. 본인부담금 면제 기록 없이 청구금액 100% 환급 건은 즉시 플래그 처리
4. 고령 환자(75세 이상)의 특정 시술은 사전 승인 코드 확인 필수
위 규칙을 기반으로 첨부 데이터셋의 이상 청구 패턴을 찾아주세요.
- 각 이상 케이스에 위반된 규칙 번호를 명시할 것
- 잠재적 환수 금액을 추정할 것
- 위반 건수 상위 10개 케이스를 테이블로 정리할 것💡 실제 활용 시나리오 예시:
의료비 심사 전문가 C씨가 이 프롬프트로 월 15만 건의 청구 데이터를 전수 분석했습니다. 기존 샘플링 심사 방식 대비 이상 청구 적발률이 3.2배 향상됐고, 월 평균 2.3%의 이상 청구를 사전 차단하는 성과를 냈습니다.
2) 블로거 — 도메인 인사이트 주입 프롬프트
블로거에게도 도메인 전문성은 핵심이에요. AI가 쓴 글이 기술적으로 유창해도, 그 분야의 뉘앙스와 독자 감수성을 모르면 신뢰를 잃습니다. 내 경험과 관점을 프롬프트에 먼저 심어두면, AI가 뼈대를 잡고 나는 도메인 정확성을 검증하는 분업이 가능합니다.
나는 [분야] 블로거로 [N년] 경력이 있습니다.
아래는 내가 직접 경험한 도메인 인사이트입니다. 반드시 이 맥락을 반영하세요.
[도메인 인사이트 - IT 블로그 예시]
- 한국 개발자 커뮤니티에서 "바이브 코딩"은 부정적 뉘앙스를 포함함
- GeekNews 독자는 영문 원문 링크를 직접 확인하는 비율이 높음
- 기술 트렌드 글은 수치·사례 없으면 신뢰도 낮게 평가됨
- "다양한", "살펴보겠습니다" 같은 표현은 피하고 직접적으로 서술
위 맥락을 반영해 [주제]로 블로그 초안을 작성해주세요.
아래 항목은 내가 직접 검토·수정합니다:
- 최신 수치의 정확성 확인 필요 [FACT_CHECK]
- 내 개인 경험 삽입 포인트 [PERSONAL_STORY_HERE]
- 한국 독자에게 생소한 문화적 맥락 [LOCALIZE_HERE]💡 실제 활용 시나리오 예시:
IT 블로거 D씨가 이 방식으로 주 3회 발행 체제를 유지합니다. AI가 초안을 잡으면 7년 개발 경험에서 나온 사례와 뉘앙스를 더해 완성하죠. 단순 AI 생성 글 대비 독자 평균 체류시간이 2.1배 높다고 해요. 블로그 자동화에 관심 있다면 AI 에이전트 시대, 직군별 실전 프롬프트 가이드도 참고해보세요.
3) 물류·운영 도메인 전문가 — 규칙 기반 검증 프롬프트
물류 배차, 임상 코딩, 보험계리처럼 법·규제·운영 규칙이 촘촘한 분야에서는 프롬프트에 규칙을 명문화하는 것이 핵심입니다. AI가 규칙을 받아 코드나 스케줄을 생성하고, 전문가는 출력이 그 규칙을 정말 따랐는지를 최종 검증합니다.
아래는 우리 회사 배차 운영 규칙입니다 (근로기준법 + 사내 규정 기준).
이 규칙을 모두 충족하는 내일 배차 스케줄을 작성해주세요.
[필수 제약 조건]
1. 기사 1명의 1일 최대 운전 가능 시간: 11시간
2. 연속 운전 4시간 후 최소 30분 휴식 필수
3. 전날 퇴근 후 다음날 출근까지 최소 8시간 인터벌
4. 5톤 이상 특수차량은 해당 면허 보유 기사만 배정
5. 수도권 특정 구간: 오전 7-9시, 오후 6-8시 통행 제한
기사 목록: [첨부]
배송지 목록: [첨부]
출력 형식:
- 각 기사별 배차 스케줄 (시간 포함)
- 제약 위반 건 발생 시 위반된 규칙 번호와 이유 명시
- 배송 완료율 추정치 포함💡 실제 활용 시나리오 예시:
20년 경력의 물류 배차 팀장 E씨가 이 프롬프트를 활용한 결과, 배차 계획 수립 시간이 기존 4시간에서 40분으로 단축됐습니다. AI는 수학적 최적화를, E씨는 “이 기사는 오늘 컨디션이 안 좋아서 장거리 배제” 같은 현장 판단을 담당합니다.
5. 비대칭 붕괴: 왜 엔지니어의 경로만 사라졌나
이 글에서 가장 날카롭다고 느낀 부분이에요. Bret은 이걸 “비대칭(asymmetry)”이라고 부릅니다. Agentic AI가 두 경로 중 딱 한쪽만 무너뜨렸거든요. 이게 왜 중요한지 잘 생각해보면, 커리어 전략이 완전히 달라집니다.
① 엔지니어의 경로 — 이제 저렴해진 강점
예전에는 엔지니어에게 도메인 전문가에게 없던 경로가 있었습니다. 전문가를 따라다니고, 명세서를 읽고, 운영 환경에서 실수를 겪으면서 도메인 모델을 천천히 습득하는 길이었어요. 이 경로가 많은 분야에서 커리어 사다리 그 자체였죠. 하지만 AI가 코드 생산을 저렴하게 만들면서, 엔지니어의 핵심 강점이었던 기계적 코딩 능력의 가치가 극적으로 하락했습니다.
💡 실제 활용 시나리오 예시:
코딩 부트캠프 6개월 수료생이 Agentic AI로 시니어가 2주 걸릴 기능을 3일 만에 구현했습니다. 단, 코드의 도메인 정확성 검증은 여전히 10년 경력의 도메인 전문가가 담당했습니다. 기술 격차보다 도메인 지식 격차가 더 결정적이었던 셈입니다.
② 도메인 전문가의 경로 — 프롬프트로 대체 불가
반면 도메인 전문가가 코딩을 배우는 길은? Agentic AI가 그 장벽을 대폭 낮췄습니다. 코딩을 몰라도 Agentic AI와 대화하며 소프트웨어를 만들 수 있게 됐거든요. 하지만 더 중요한 포인트가 있어요. Bret이 강조하듯 “수천 건의 급여를 정산해본 사람의 암묵지를 담은 스킬 파일은 존재하지 않는다”는 것. 최고 수준 전문가의 지식이 AI 모델에 일부 내장되어 있어도, 현장 특수성·엣지 케이스·규제 변경에 즉시 적응하는 능력은 살아있는 전문가만의 영역입니다.
💡 실제 활용 시나리오 예시:
보험계리사 F씨는 코딩 능력은 없지만 자신이 설계한 리스크 모델의 수식과 규정을 AI에 입력했습니다. AI가 Python 코드로 구현하면 F씨가 결과값의 도메인 정확성을 검증하는 방식으로, 혼자서 중소 보험사용 리스크 분석 도구를 완성했습니다.
6. 숙련 엔지니어를 위한 베팅 방향
향후 몇 년을 고민하는 숙련 엔지니어라면, 특정 산업·금융 상품·규제 체계·물리적 프로세스 중 하나를 골라 도메인 전문성을 쌓아야합니다. 마치 과거에 새 프로그래밍 언어나 프레임워크를 배우듯이. 이게 에이전트가 대신해줄 수 없는 부분이자, 이제 가장 큰 가치를 지닌 부분입니다.
① 두 계층을 모두 검증하는 인재 — 진짜 희소 자원
원문에서 “가장 가치 있는 사람”은 이렇게 정의됩니다: 생성된 코드가 견고한지 알고, 동시에 그 코드가 내놓는 답이 맞는지도 아는 사람. “기사는 11시간을 초과할 수 없다”는 규칙을 알기에 그걸 검증하는 테스트를 작성할 수 있고, 그 테스트가 의미 있음을 판별할 수 있는 사람이에요. 에이전트는 전사(transcription)를 담당하고, 이 사람은 두 번의 판단(judging, twice)을 담당합니다.
💡 실제 활용 시나리오 예시:
의료 IT 10년 경력의 엔지니어 G씨는 개발 실력에 의료 청구 규정 전문 지식을 더해, 코드 품질과 도메인 정확성을 동시에 검증하는 컨설턴트로 전향했습니다. 시장에서 이 두 역할을 동시에 할 수 있는 사람이 극히 드물어 시간당 단가가 3배 이상 뛰었습니다.
② 소프트웨어 자체도 도메인이다 💡
“소프트웨어 개발 자체도 하나의 도메인이고 그걸 잘하는 것도 전문 기술”이라는 관점이죠. 분산 시스템, CAP 정리, 캐시 무효화 전략 같은 소프트웨어 엔지니어링 도메인 지식은 여전히 희소하고 가치 있습니다. 핵심은 AI가 대체하는 부분(기계적 코딩)과 대체 못 하는 부분(시스템 설계 판단 + 도메인 정확성 검증)을 명확히 구분하는 거예요.
💡 실제 활용 시나리오 예시:
분산 시스템 전문가 H씨는 Agentic AI가 생성한 마이크로서비스 아키텍처를 검토합니다. 기능적으로 완벽한 코드라도 “이 서비스 경계 설계는 네트워크 파티션 발생 시 데이터 일관성을 보장 못 한다”는 판단은 소프트웨어 도메인 전문성에서 나옵니다.
7. 이런 분들께 적극 추천합니다
- AI 시대에 자신의 커리어 방향을 고민 중인 3~10년 차 개발자
- 코딩 없이 업무 자동화 도구를 직접 만들어보고 싶은 도메인 전문가 (의료·물류·금융·법무 분야)
- Agentic AI 도구(Claude Code, Cursor 등)를 실무 팀에 도입하려는 팀 리드 및 엔지니어링 매니저
- AI가 생성한 분석 결과의 도메인 정합성을 검증해야 하는 데이터 사이언티스트
- “AI가 내 일자리를 빼앗는다”는 불안보다 구체적 대응 전략이 필요한 IT 종사자
8. 자주 묻는 질문 (FAQ)
Q. 코딩을 전혀 모르는 도메인 전문가도 Agentic AI를 바로 활용할 수 있나요?
A. 완전히 바로 쓰기는 어렵지만 진입 장벽은 생각보다 낮습니다. Claude Code나 Cursor 같은 도구로 간단한 데이터 변환 작업부터 시작해보세요. 핵심은 코딩 문법을 배우는 게 아니라 도메인 규칙을 AI에게 명확하게 전달하는 능력입니다. 위에 제시한 프롬프트 템플릿을 복붙해서 자신의 규칙으로 채워보는 것만으로도 충분한 시작점이 됩니다.
Q. AI가 더 발전하면 도메인 전문성도 결국 대체되지 않을까요?
A. devpain 님이 지적한 것처럼 “암묵지가 프롬프트로 조금씩 넘어가는” 건 실제로 일어나고 있습니다. 단, 두 가지를 구분해야 해요. 이미 표준화·문서화된 도메인 지식은 AI가 흡수합니다. 하지만 현장 특수성, 규제 변경에 즉시 적응하는 능력, 엣지 케이스 감각은 당분간 사람의 영역입니다. 실패 비용이 높은 분야(의료·법무·금융)일수록 이 격차는 더 오래 유지됩니다.
Q. 엔지니어로서 어떤 도메인을 새로 공부해야 할지 어떻게 선택하나요?
A. Bret의 조언은 단순합니다: 산업·금융 상품·규제 체계·물리적 프로세스 중 하나를 고르라고요. 선택 기준 세 가지를 추천드려요. ① 이미 접점이 있는 분야 (전 직장, 가족 업종, 관심 산업), ② 규제가 복잡하고 실수 비용이 큰 분야, ③ 디지털 전환이 아직 덜 된 분야. 프로그래밍 언어 배우듯 6~12개월 깊이 파고들면 충분한 기초가 됩니다.
✍️ 글을 마치며
Bret의 글이 울림 있는 이유는 단순한 “AI 시대 생존법”이 아니라 소프트웨어 개발의 본질을 다시 묻기 때문이에요. 코드는 항상 도메인 이해의 전사(transcription)였고, AI가 그 전사 과정을 자동화한 지금, 진짜 가치는 “무엇을 전사할지 아는 것”으로 더 선명하게 드러났습니다. 도메인 전문성은 AI 이전에도 해자였고, AI 이후에는 더 강력한 해자가 됐어요.
저는 블로그 운영이라는 제 도메인에 더 깊이 투자하는 것부터 시작할 것 같아요. SEO 규칙, 독자 반응 패턴, 한국 IT 커뮤니티의 감수성 — 이건 AI에게 주입할 수 있지만, 경험 없이는 제대로 주입조차 못 하니까요.
여러분은 어떤 부분이 가장 인상적이셨나요? 지금 어떤 도메인을 더 깊이 파고들 계획이신지 댓글로 자유롭게 의견 남겨주세요! 😊