방구석 스티브 잡스의 대량 양성: 코딩 문법보다 무서운 '도메인 지식'의 역습

방구석 스티브 잡스의 대량 양성: 코딩 문법보다 무서운 '도메인 지식'의 역습

 

Introduction

요즘 IT 업계에서 가장 묘하게 웃기고, 동시에 약간 서늘한 장면은 미팅룸에서 벌어집니다. 예전에는 개발자가 노트북을 살짝 닫고 팔짱을 낀 뒤 “그건 아키텍처 구조상 어렵습니다”라고 말하면 회의실 공기가 정리됐습니다. 기획자는 “아, 그렇군요”라고 말하며 요구사항 문서를 조용히 접었고, 현업 담당자는 “역시 개발은 어렵구나”라는 표정으로 커피를 마셨습니다. 그런데 이제 판이 바뀌었습니다. 기획자가 조용히 챗GPT나 Cursor 같은 AI 도구를 켭니다. 요구사항을 입력합니다. 잠깐의 로딩 후 화면에 코드가 나옵니다. 그리고 개발자를 향해 아주 해맑게 말합니다. “음? AI는 된다고 하는데요?”

이 한 문장에는 시대 변화의 모든 쓴맛과 단맛이 들어 있습니다. 밤새 C++, Java, Python을 공부하며 기술 스택을 쌓던 개발자에게는 살짝 억울한 현실입니다. 반대로 말만 번지르르하다는 오해를 받던 기획자, PM, 현업 담당자, 도메인 전문가에게는 마침내 “내가 알고 있는 업무 지식이 진짜 제품을 움직이는 힘이었다”는 짜릿한 순간입니다. 코딩 노예의 시대가 저물고, 프롬프트 마스터의 시대가 열렸다는 농담이 더 이상 완전한 농담만은 아닌 셈입니다.

핵심은 개발자가 필요 없어졌다는 말이 아닙니다. “코드를 칠 줄 아는 사람”보다 “무엇을 만들어야 하는지 알고, 그 판단을 AI와 시스템에 정확히 전달할 줄 아는 사람”의 가치가 폭등했다는 말입니다.

이 글은 도메인 전문가의 부상과 개발의 축소라는 주제를 조금 과장되게, 그러나 현실감 있게 풀어봅니다. 회사 미팅룸에서 벌어지는 권력 이동, AI가 개발 생태계를 바꾼 방식, 앞으로 채용 시장과 교육 방식이 어떻게 달라질지까지 살펴보겠습니다. 웃으며 읽다가 갑자기 리트코드를 닫고 회계학 원론 책을 검색하게 될 수도 있습니다. 마음의 준비를 해두십시오.

프롤로그: “코딩은 AI가 할게, 넌 기획을 해라”의 시대

개발자의 전통적 자부심은 꽤 오랫동안 “나는 기계와 대화할 수 있다”에서 나왔습니다. 이상한 에러 메시지를 해석하고, 세미콜론 하나 때문에 무너진 빌드를 복구하고, 아무도 이해하지 못하는 로그를 보며 고개를 끄덕이는 사람. 그 신비로운 존재가 바로 개발자였습니다. 현업 담당자가 “버튼 하나만 추가하면 되는 거 아닌가요?”라고 묻는 순간, 개발자는 깊은 한숨과 함께 데이터베이스 스키마, API 계약, 레거시 의존성, 배포 파이프라인을 설명했습니다. 설명이 끝나면 모두가 피곤해졌고, 요구사항은 다음 분기로 밀렸습니다.

하지만 생성형 AI와 에이전트형 AI 도구가 등장하면서 “코드를 작성할 수 있음”이라는 능력의 희소성이 빠르게 낮아졌습니다. 물론 AI가 항상 맞는 코드를 주는 것은 아닙니다. 오히려 자신감 넘치는 헛소리를 코드 형태로 제출하는 경우도 많습니다. 그런데도 중요한 변화는 이미 일어났습니다. 비개발자가 “일단 돌아가는 듯 보이는 결과물”을 직접 만들 수 있게 됐다는 점입니다. 그 결과 회의실의 심리적 권력이 흔들립니다. 예전에는 개발자가 “불가능”이라고 선언하면 논의가 멈췄지만, 이제는 누군가가 “제가 어제 밤에 AI로 프로토타입 만들어봤는데요”라고 말하며 화면을 공유합니다.

이 변화는 개발자를 몰아내는 장면이라기보다, 개발자가 독점하던 첫 번째 관문이 무너지는 장면에 가깝습니다. 과거에는 아이디어가 코드로 바뀌기 전까지 반드시 개발자의 손을 거쳐야 했습니다. 이제는 아이디어가 대략적인 프로토타입으로 바뀌는 길이 훨씬 짧아졌습니다. 그래서 도메인 전문가의 질문이 날카로울수록 AI가 내놓는 초안도 더 쓸모 있어집니다. 반대로 도메인을 모르는 개발자가 문법과 프레임워크만 믿고 만든 코드는 겉보기에는 멀쩡해도 업무 현장에서는 “이건 정산일 기준을 전혀 모르고 만든 기능인데요?”라는 평가를 받을 수 있습니다.

Topic 1: 눈물겨운 현실 세계의 변화

과거의 미팅룸: 개발자의 철벽 수비

과거의 미팅룸은 일종의 의식과 같았습니다. 기획자가 조심스럽게 요구사항을 말합니다. “고객 등급에 따라 할인율을 다르게 보여주고, 특정 캠페인 기간에는 쿠폰도 중복 적용되면 좋겠습니다.” 개발자는 눈을 가늘게 뜹니다. 잠시 침묵이 흐릅니다. 그리고 낮은 목소리로 말합니다. “그거 지금 구조에서는 어렵습니다. 공수 3개월은 봐야 합니다.” 이 순간 회의실의 주도권은 개발자에게 넘어갑니다. 기획자는 요구사항을 줄이고, 현업 담당자는 예외 케이스를 포기하고, PM은 일정표에 빨간색을 칠합니다.

개발자의 말이 항상 핑계였다는 뜻은 아닙니다. 실제로 복잡한 시스템에서는 작은 버튼 하나도 인증, 권한, 데이터 정합성, 성능, 장애 대응, 배포 일정과 연결됩니다. 문제는 이 복잡성이 종종 “논의를 끝내는 권력”으로 작동했다는 점입니다. 현업 담당자는 코드베이스를 볼 수 없고, 아키텍처를 평가할 수 없으니 개발자의 판단을 믿을 수밖에 없었습니다. 그래서 개발자는 업무 언어를 몰라도 어느 정도 버틸 수 있었고, 도메인 전문가는 기술 언어를 모르면 늘 한 발 뒤에 서야 했습니다.

현재의 미팅룸: “AI는 된다고 하는데요?”

이제 회의실의 풍경은 조금 다릅니다. 기획자는 개발자에게 말하기 전에 먼저 AI에게 말합니다. “보험 청구 업무에서 고객이 진단서 이미지를 업로드하면, OCR 결과를 검수 화면에 보여주고, 심사자가 승인하면 지급 심사 큐로 넘기는 간단한 프로토타입을 만들어줘.” 몇 초 뒤 화면에는 React 컴포넌트, API 라우트, 샘플 JSON, 검수 상태값이 줄줄이 나옵니다. 물론 이 코드는 보안도 부족하고, 예외 처리도 허술하고, 실제 OCR 품질도 검증되지 않았을 수 있습니다. 하지만 미팅룸에서는 이미 충분히 강력한 무기가 됩니다. 눈에 보이는 프로토타입은 추상적인 요구사항보다 설득력이 큽니다.

개발자는 이제 단순히 “안 됩니다”라고 말하기 어려워졌습니다. 대신 “AI가 만든 코드는 인증 흐름이 없고, 파일 업로드 크기 제한도 없고, 개인정보 마스킹도 없고, 운영 로그도 없습니다”라고 설명해야 합니다. 이 설명은 과거보다 더 구체적이어야 합니다. 막연한 불가능 선언은 힘을 잃고, 검증 가능한 리스크 목록이 필요해졌습니다. 개발자의 역할이 “문을 닫는 사람”에서 “위험을 식별하고 구조를 정리하는 사람”으로 이동한 것입니다.

구분	과거의 권력	현재의 권력	웃픈 장면
요구사항 검토	개발자가 가능 여부를 선언	기획자가 AI 프로토타입으로 반격	“공수 3개월” 옆에 “AI 5분”이 적힘
초기 구현	주니어 개발자가 보일러플레이트 작성	AI가 화면, API, 샘플 데이터를 생성	주니어가 코드보다 프롬프트 리뷰를 받음
검증 역할	QA와 개발자가 기능 오류 확인	개발자가 AI 코드의 숨은 결함을 감별	“안 된다”를 증명하려고 밤새 디버깅함
업무 판단	요구사항 문서에 의존	도메인 전문가가 로직의 맞고 틀림을 결정	코드는 맞는데 업무가 틀린 비극 발생

역전된 상황: 개발자는 AI 코드 감별사가 된다

개발자의 새로운 고통은 AI가 만든 코드가 완전히 틀린 것도, 완전히 맞는 것도 아니라는 데 있습니다. 얼핏 보면 그럴듯합니다. 파일 구조도 있어 보이고, 함수명도 멀쩡하고, 주석은 오히려 인간보다 친절합니다. 그런데 자세히 보면 트랜잭션 경계가 없거나, 동시성 문제가 숨어 있거나, 금액 계산에서 반올림 규칙을 잘못 적용합니다. 특히 금융, 의료, 물류, 세무, 제조처럼 도메인 규칙이 중요한 시스템에서는 “돌아가는 코드”와 “맞는 코드” 사이의 간극이 엄청납니다.

그래서 개발자는 이제 AI가 짠 코드를 보고 “이건 왜 위험한가”를 설명해야 합니다. 이는 단순한 코드 리뷰보다 어렵습니다. AI 코드의 문제를 찾으려면 기술 지식뿐 아니라 업무 문맥도 알아야 합니다. 예를 들어 물류 시스템에서 출고 가능 재고를 계산할 때 예약 재고, 보류 재고, 반품 예정 재고, 창고 이동 중 재고를 어떻게 다룰지 모르면 아무리 깔끔한 코드를 봐도 결함을 놓칩니다. 결국 개발자가 살아남으려면 도메인 전문가를 이기려 하기보다, 도메인 전문가의 언어를 이해하고 시스템 구조로 번역하는 사람이 되어야 합니다.

Topic 2: AI가 바꾼 개발 생태계

코딩 문법은 더 이상 권력이 아니다

한때 개발자의 입문 장벽은 문법이었습니다. 괄호를 닫지 않으면 에러가 났고, 세미콜론 하나 때문에 밤을 새웠고, 환경 변수 하나가 빠져서 빌드가 실패했습니다. Stack Overflow 검색 능력은 거의 생존 기술이었습니다. 그런데 AI 도구는 이 장벽을 빠르게 낮췄습니다. 이제 “Python으로 CSV 파일을 읽어서 고객 등급별 매출 합계를 계산해줘”라고 말하면, AI는 대체로 그럴듯한 코드를 줍니다. “React로 검색 필터와 페이지네이션이 있는 목록 화면을 만들어줘”라고 하면 컴포넌트 초안도 나옵니다.

문법의 권력이 약해졌다는 것은 개발이 쉬워졌다는 뜻이기도 하지만, 동시에 개발자의 차별화 포인트가 달라졌다는 뜻입니다. 단순히 “나는 문법을 안다”는 강점은 점점 약해집니다. 이제 중요한 것은 요구사항을 검증 가능한 형태로 쪼개는 능력, 잘못된 AI 출력을 빠르게 의심하는 능력, 운영 환경에서 터질 문제를 미리 보는 능력, 그리고 도메인 규칙을 코드 구조에 녹이는 능력입니다. 말하자면 코딩이 사라지는 것이 아니라, 코딩의 중심이 타이핑에서 판단으로 이동하고 있습니다.

진짜 중요한 것: 어떤 비즈니스 문제를 해결할 것인가

AI가 코드를 대량으로 만들어내기 시작하면, 조직은 곧 이상한 질문과 마주합니다. “코드는 많은데 왜 제품은 여전히 애매하지?” 이유는 간단합니다. 코드가 많아졌다고 문제 정의가 좋아지는 것은 아니기 때문입니다. 오히려 잘못 정의된 문제는 AI 덕분에 더 빠르게, 더 그럴듯하게, 더 넓은 범위로 구현될 수 있습니다. 이것이 진짜 무서운 부분입니다. 예전에는 잘못된 요구사항도 개발 공수 때문에 어느 정도 속도가 제한됐습니다. 이제는 잘못된 방향으로도 매우 빠르게 달릴 수 있습니다.

여기서 도메인 지식의 가치가 폭등합니다. 금융 상품의 정산 로직이 맞는지, 의료 데이터 입력 흐름이 실제 간호사의 동선과 맞는지, 물류 배차 알고리즘이 현장 기사들의 휴게 시간과 맞는지, 마케팅 캠페인 조건이 고객 세그먼트와 충돌하지 않는지 판단하는 능력은 AI가 쉽게 대체하지 못합니다. AI는 일반적인 패턴을 잘 압축하지만, 특정 회사의 운영 관행, 규제 해석, 예외 처리 문화, 현장 암묵지까지 자동으로 알지는 못합니다. 그 지점을 아는 사람이 프로젝트의 방향타를 잡게 됩니다.

AI 시대의 요구사항 예시

AI에게 일을 잘 시키는 도메인 전문가는 단순히 “만들어줘”라고 말하지 않습니다. 맥락, 규칙, 예외, 검증 기준을 함께 줍니다. 아래는 개발자와 도메인 전문가가 함께 다듬을 수 있는 요구사항 명세의 예시입니다.

feature: campaign_discount_preview
domain: ecommerce_marketing
goal: 고객 등급과 캠페인 조건에 따라 결제 전 예상 할인액을 보여준다.
rules:
  - vip_customer_discount: 10%
  - new_customer_coupon: fixed_5000_krw
  - campaign_period: 2026-08-01_to_2026-08-15
  - duplicate_policy: vip_discount_and_coupon_can_stack
  - exclusion:
      - already_discounted_clearance_items
      - corporate_bulk_orders
validation_cases:
  - case: VIP 고객이 신규 쿠폰을 함께 사용하는 경우
    expected: 등급 할인 후 쿠폰 차감
  - case: 행사 제외 상품만 장바구니에 있는 경우
    expected: 할인액 0원 및 제외 사유 표시
  - case: 캠페인 종료 후 접근하는 경우
    expected: 기본 등급 할인만 적용
operational_notes:
  - 모든 금액 계산은 원 단위 절사
  - 관리자 화면에서 캠페인 기간 변경 가능
  - 할인 계산 로그는 CS 문의 대응을 위해 90일 보관

이런 명세는 단순한 코딩 요청이 아닙니다. 업무 판단을 코드로 옮기기 위한 계약서에 가깝습니다. AI는 이 계약서를 기반으로 훨씬 나은 초안을 만들 수 있고, 개발자는 이 초안이 실제 시스템에 들어가도 되는지 판단할 수 있습니다. 여기서 중요한 사람은 “세미콜론을 잘 찍는 사람”이 아니라 “중복 할인 정책의 의도를 아는 사람”입니다.

개발의 축소: 보일러플레이트는 줄고, 판단의 무게는 커진다

AI가 가장 먼저 줄이는 영역은 반복적인 보일러플레이트입니다. CRUD 화면, 기본 API 연동, 데이터 변환, 테스트 초안, 문서 초안, 마이그레이션 스크립트 같은 작업은 이미 큰 영향을 받고 있습니다. 과거에는 수십 명의 주니어 개발자가 여러 달 동안 나눠서 하던 작업을 이제 소수 인원이 AI 도구와 함께 빠르게 처리할 수 있습니다. 그래서 개발팀의 규모가 무조건 커야 한다는 믿음은 약해지고, 대신 작지만 강한 팀이 도메인 전문가와 밀착해서 일하는 형태가 늘어날 가능성이 큽니다.

하지만 개발이 축소된다는 말은 모든 개발 일이 사라진다는 뜻이 아닙니다. 사라지는 것은 “생각 없이 찍어내는 코드”에 가깝습니다. 남는 것은 훨씬 까다롭습니다. 시스템 경계 설계, 데이터 모델링, 보안, 성능, 장애 대응, 레거시 통합, 배포 자동화, 관측 가능성, 비용 최적화 같은 영역은 여전히 깊은 전문성이 필요합니다. 오히려 AI가 코드를 더 많이 만들수록, 그 코드를 품질 있게 통제할 수 있는 시니어 개발자의 중요성은 더 커집니다. 아이러니하게도 중간 지대의 애매한 개발자에게는 가장 추운 겨울이 오고, 진짜 고수에게는 더 비싼 봄이 올 수 있습니다.

작업 유형	AI 대체 가능성	사람이 여전히 중요한 이유
기본 CRUD 화면	높음	권한, 예외 상태, 사용 흐름은 업무 맥락이 필요함
API 연동 초안	높음	실패 재시도, 멱등성, 장애 격리는 사람이 설계해야 함
정산/심사/배차 로직	중간	도메인 규칙과 예외 해석이 핵심임
아키텍처와 운영 설계	낮음	장기 비용, 장애 영향, 조직 역량을 함께 판단해야 함

Topic 3: 우리가 맞이할 미래

개발자 채용 공고의 대격변

앞으로 채용 공고는 조금 이상해질 수 있습니다. “Java 5년 이상, React 숙련자 우대”라는 문구 옆에 “보험 청구/회계 결산/병원 원무/국제 물류 도메인 경험 우대”가 점점 굵은 글씨로 올라올 것입니다. 더 나아가 “AI 도구를 활용한 업무 자동화 경험”, “프롬프트 기반 프로토타이핑 경험”, “비즈니스 규칙을 명세화하여 개발팀과 협업한 경험” 같은 항목이 등장할 수 있습니다. 개발자 채용인데 면접관이 갑자기 “매출채권과 미수금의 차이를 설명해보세요”라고 물으면, 그날은 집에 가서 알고리즘 문제 대신 회계 유튜브를 켜야 합니다.

현업 담당자에게도 변화가 옵니다. 예전에는 “나는 개발을 몰라서”라는 말이 어느 정도 방패가 됐습니다. 이제는 그 방패가 얇아집니다. AI 도구를 사용하면 업무 담당자도 간단한 자동화, 데이터 분석, 프로토타입 제작을 시도할 수 있습니다. 그래서 도메인 전문가는 더 이상 요구사항을 말로만 던지는 사람이 아니라, 문제를 구조화하고 AI와 개발자가 이해할 수 있는 형태로 전달하는 사람이어야 합니다. 말만 번지르르한 기획자는 여전히 위험합니다. 다만 이제 그 위험은 회의록에서 끝나지 않고, AI가 생성한 그럴듯한 엉터리 프로토타입으로 실제화될 수 있습니다.

‘말’이 곧 ‘코드’가 되는 세상

미래의 코딩 교육은 파이썬 문법만 가르치지 않을 가능성이 큽니다. 오히려 “내 생각을 AI에게 오해 없이 전달하는 법”, “요구사항을 검증 가능한 조건으로 쪼개는 법”, “예외 케이스를 빠짐없이 질문하는 법”, “업무 규칙을 테스트 케이스로 바꾸는 법”이 중요해질 것입니다. 조금 과장하면 국어, 논리학, 업무 분석, 시스템 사고가 개발 교육의 중심으로 들어옵니다. 문과생들이 “우리가 드디어 세상을 지배한다!”라고 외치는 장면이 머릿속에 떠오릅니다. 물론 이 문장 뒤에는 개발자가 조용히 “그래도 배포는 누가 하는데요”라고 중얼거리는 자막이 붙습니다.

말이 곧 코드가 되는 시대에는 말의 품질이 코드의 품질을 좌우합니다. 모호한 말은 모호한 코드를 만들고, 빠진 예외는 빠진 버그가 됩니다. “적당히 빠르게 처리해줘”라는 요청은 성능 기준이 될 수 없습니다. “영업일 기준 2일 이내, 단 공휴일과 시스템 점검일 제외”처럼 말해야 시스템이 움직입니다. 도메인 전문가의 언어가 정교해질수록 AI와 개발팀의 산출물도 좋아집니다.

최후의 승자는 누구인가

그렇다면 개발자는 완전히 사라질까요? 아닙니다. 오히려 진짜 개발자는 더 무서운 존재가 됩니다. AI가 생성한 코드가 여러 팀을 거쳐 운영에 들어가고, 어느 날 새벽 2시에 정산 배치가 멈추고, 고객 포인트가 두 번 적립되고, 로그는 산처럼 쌓였는데 원인은 보이지 않는 순간이 옵니다. 그때 필요한 사람은 “버튼 색상을 바꿔줘” 수준의 코드 작성자가 아니라, 시스템 전체를 머릿속에 그리며 병목과 데이터 흐름과 장애 전파를 추적할 수 있는 시니어 아키텍처 개발자입니다.

AI 시대의 개발자는 양극화될 가능성이 큽니다. 한쪽에는 도메인을 이해하고 AI를 도구로 쓰는 비즈니스형 개발자, 다른 한쪽에는 깊은 시스템 전문성으로 AI 산출물을 검증하고 운영 안정성을 책임지는 고급 개발자가 있습니다. 그 사이에서 “문법은 아는데 업무도 모르고, 구조도 모르고, AI 검증도 잘 못하는” 애매한 포지션은 점점 좁아질 수 있습니다. 씁쓸하지만 현실적인 엔딩입니다. 중간 지대가 사라진다는 말은 사람을 비하하는 말이 아니라, 역량의 조합이 바뀐다는 신호입니다.

도메인 전문가와 개발자의 새로운 협업 방식

앞으로 좋은 팀은 도메인 전문가와 개발자를 대립시키지 않을 것입니다. 가장 강한 조합은 “업무를 깊게 아는 사람”과 “시스템의 한계와 가능성을 깊게 아는 사람”이 함께 AI를 부리는 구조입니다. 도메인 전문가는 AI에게 업무 규칙과 예외를 정확히 설명하고, 개발자는 AI가 만든 초안을 운영 가능한 구조로 다듬습니다. 기획자는 화면의 흐름과 사용자 의도를 조율하고, QA는 도메인 시나리오 중심의 테스트를 설계합니다. 모두가 조금씩 개발자가 되고, 모두가 조금씩 기획자가 되는 묘한 시대입니다.

이때 중요한 것은 역할의 자존심보다 산출물의 정확성입니다. 개발자가 “기획자가 만든 AI 코드라서 싫다”라고만 반응하면 팀은 느려집니다. 반대로 기획자가 “AI가 된다고 했으니 개발자는 그냥 붙이면 된다”라고 생각하면 제품은 위험해집니다. 양쪽 모두 틀렸습니다. AI가 만든 초안은 대화의 끝이 아니라 시작입니다. 프로토타입은 가능성을 보여주지만, 운영 시스템은 책임을 요구합니다.

AI 시대의 협업 원칙은 간단합니다. 도메인 전문가는 “무엇이 맞는지”를 더 정확히 말해야 하고, 개발자는 “무엇이 안전한지”를 더 구체적으로 증명해야 합니다.

실무 체크리스트

역할	AI 시대에 더 중요해지는 역량	오늘 바로 할 수 있는 연습
기획자/PM	요구사항을 테스트 가능한 조건으로 나누기	기능 설명마다 성공 조건과 실패 조건을 함께 쓰기
현업 담당자	암묵지를 명시적 규칙으로 표현하기	“원래 이렇게 해요”를 예외 케이스 표로 정리하기
주니어 개발자	AI 코드 읽기, 검증하기, 작은 단위로 테스트하기	AI가 만든 코드에 대해 반례 5개를 찾기
시니어 개발자	도메인 규칙을 아키텍처와 운영 정책에 연결하기	기능 요구사항을 장애 시나리오와 데이터 모델로 변환하기

에필로그: 결국 인간의 무기는 ‘무엇을 만들지 아는 것’

AI가 코드를 더 잘 쓰게 될수록, 인간에게 남는 질문은 더 본질적입니다. “어떻게 만들 것인가”도 중요하지만, 그보다 먼저 “무엇을 만들 것인가”, “왜 만들어야 하는가”, “누구의 어떤 문제를 해결하는가”를 알아야 합니다. 기술의 How가 약해진다는 뜻이 아닙니다. 다만 How만으로 버티던 시대가 끝나가고 있다는 뜻입니다. What과 Why를 모르는 How는 AI의 속도 앞에서 흔들립니다.

도메인 전문가는 이제 단순한 요구사항 전달자가 아닙니다. 제품의 방향을 정하고, 업무 규칙의 정합성을 판단하고, AI가 만든 결과물의 의미를 검증하는 핵심 플레이어입니다. 개발자도 단순한 코드 생산자가 아닙니다. AI가 만든 코드의 위험을 감별하고, 시스템 전체의 안정성을 책임지고, 도메인 지식을 실행 가능한 구조로 바꾸는 설계자입니다. 결국 승자는 기획자냐 개발자냐가 아니라, 도메인과 기술을 함께 이해하는 사람입니다.

그러니까 개발자 여러분, 지금 당장 리트코드를 완전히 끊으라는 말은 아닙니다. 다만 리트코드 탭 옆에 회계학 원론, 마케팅 개론, 물류 운영, 의료 행정, 금융 상품 구조 같은 탭을 하나쯤 열어두는 것이 좋겠습니다. 그리고 기획자 여러분, “AI가 해줬어요”라는 말만으로 개발자를 압박하기보다, AI가 이해할 수 있을 만큼 업무를 정확히 설명하는 훈련을 시작해야 합니다. 살 길은 도메인에 있고, 오래 살아남을 길은 도메인과 기술의 결합에 있습니다.

Frequently Asked Questions

AI가 코딩을 해주면 개발자는 정말 필요 없어지나요?

필요 없어지기보다는 역할이 바뀝니다. 반복적인 코드 작성의 비중은 줄어들 수 있지만, 아키텍처 설계, 보안, 장애 대응, 성능, 데이터 정합성, 도메인 규칙 검증은 여전히 사람의 깊은 판단이 필요합니다.

도메인 전문자는 어떤 역량을 먼저 키워야 하나요?

업무 규칙을 명시적으로 설명하는 능력이 가장 중요합니다. 예외 케이스, 성공 조건, 실패 조건, 검증 데이터를 함께 정리하면 AI와 개발팀 모두에게 훨씬 쓸모 있는 요구사항을 전달할 수 있습니다.

주니어 개발자는 무엇을 준비해야 하나요?

문법 공부만으로는 부족합니다. AI가 만든 코드를 읽고 반례를 찾는 연습, 작은 테스트를 작성하는 습관, 특정 산업의 업무 흐름을 이해하는 공부가 함께 필요합니다.

기획자가 AI로 만든 프로토타입은 실무에 바로 써도 되나요?

대부분은 바로 쓰면 위험합니다. 프로토타입은 논의를 빠르게 만드는 도구이지 운영 품질을 보장하는 결과물이 아닙니다. 인증, 권한, 개인정보, 로그, 장애 처리, 비용, 데이터 정합성을 반드시 검토해야 합니다.

Key Takeaways

• AI는 코딩 문법의 진입장벽을 낮추지만, 문제 정의와 도메인 판단의 중요성은 더 키웁니다.
• 기획자와 현업 담당자는 요구사항을 더 구체적이고 검증 가능한 형태로 말해야 합니다.
• 개발자는 “안 된다”가 아니라 “어떤 위험이 있고 어떻게 줄일 수 있는지”를 설명해야 합니다.
• 반복적인 보일러플레이트 개발은 축소될 가능성이 크지만, 시니어 아키텍처와 운영 전문성의 가치는 더 커질 수 있습니다.
• 미래의 승자는 도메인 전문가와 개발자 중 하나가 아니라, 도메인과 기술을 함께 이해하고 AI를 제대로 부리는 사람입니다.

Conclusion

도메인 전문가의 부상과 개발의 축소는 개발자의 몰락 선언이 아닙니다. 오히려 개발이라는 일이 더 본질적인 방향으로 압축되는 과정입니다. 코드를 치는 속도보다 무엇을 만들지 아는 능력, 업무의 예외를 이해하는 능력, AI 결과물을 의심하고 검증하는 능력이 더 중요해지고 있습니다. 기획자와 현업 담당자는 더 강력한 도구를 얻었고, 개발자는 더 높은 수준의 판단을 요구받게 됐습니다.

웃기게 말하면 이제 회의실에서 가장 무서운 사람은 “제가 AI로 한번 만들어봤는데요”라고 말하는 도메인 전문가입니다. 더 무서운 사람은 그 코드를 보고 조용히 “이거 운영에 올리면 월말 정산 때 터집니다”라고 말할 수 있는 개발자입니다. 그리고 가장 강한 사람은 두 언어를 모두 이해하는 사람입니다. 기술만 파던 시대도, 말만 하던 시대도 끝나갑니다. 이제는 무엇을 만들지 알고, 왜 만들어야 하는지 설명하고, AI와 사람을 함께 움직일 수 있는 사람이 실세가 됩니다.

도메인 전문가 아님 코딩만 파던 개발자