AI는 코드를 짜지만 도메인은 모른다 — 코드보다 중요한 도메인 이해

개발자는 사라지지 않는다 — 이 말이 점점 변명처럼 들리는 이유가 있다.

반대편의 문장이 더 자극적이기 때문이다.

“AI가 코드를 다 짜준다.”
“주니어는 끝났다.”
“몇 년 안에 개발자는 없어질 직업이다.”

이건 단순한 공포 마케팅이 아니다. 실제로 맞는 부분이 있다. CRUD, 보일러플레이트, 반복적인 API 연동 — 이런 건 이미 상당 부분 AI가 가져갔다. 직접 써본 사람은 안다. 예전 같으면 30분 걸리던 작업이 3분 만에 끝난다.

그래서 사람들은 자연스럽게 다음 단계로 넘어간다.

코드도 짜고 → 구조도 잡고 → 설계도 하고 →
그럼 결국 개발자 필요 없지 않나?

여기서 한 단계가 빠진다.
그 빠진 한 단계 때문에 결론이 틀어진다.

---

AI가 도메인을 이해한다는 말, 어디까지 맞는가

주식 거래 앱을 만들어달라고 하면, 요즘 모델은 꽤 괜찮은 결과를 낸다.

// 대충 이런 구조는 거의 틀리지 않는다
type Order = {
  symbol: string;
  quantity: number;
  price: number;
  type: 'market' | 'limit';
};

function placeOrder(order: Order) {
  // validation
  // send to exchange
}

종목 검색, 주문, 체결, 잔고 — 기능 구성 자체는 정확하다.
이건 어렵지 않다. 이미 세상에 있는 패턴이니까.

여기까지 보면 “도메인을 이해한다”는 말이 맞다.

근데 질문을 바꾸면 바로 깨진다.

“키움증권처럼 만들어줘.”

이 순간부터 AI는 모른다.

---

키움증권이 어려운 이유는 기술이 아니라 규칙이다

키움증권의 핵심은 UI도 아니고, API도 아니다.
규칙이다.

• 신용거래 담보비율 계산 방식
• 반대매매 발동 기준
• 종목별 거래 제한 조건
• 위탁 수수료 구조
• 특정 이벤트 시 주문 제한 로직

이건 “주식 앱 기능”이 아니다.
금융 규제 + 내부 정책 + 운영 경험이 합쳐진 결과다.

예를 들어 이런 식이다.

function canForceSell(account: Account): boolean {
  if (account.collateralRatio < 140) return true;
  if (account.marginType === 'credit' && account.riskScore > 0.8) return true;
  if (account.hasDelayedSettlement) return false; // 예외
  return false;
}

이 로직이 왜 이렇게 생겼는지 AI는 모른다.
그리고 이 조건 하나 틀리면 실제로 돈이 움직인다.

AI는 여기서 두 가지 중 하나를 한다.

1. 가장 일반적인 금융 로직을 가져온다
2. 그럴듯하게 지어낸다

둘 다 틀릴 가능성이 높다.

왜냐하면 이건 공개된 도메인이 아니기 때문이다.

---

모든 회사는 자기만의 “비공개 도메인”을 갖고 있다

이걸 키움 사례로만 보면 특수해 보이는데, 전혀 아니다.

쿠팡을 보면 더 명확하다.

AI는 이커머스를 안다.
상품, 장바구니, 결제, 배송.

근데 쿠팡은 이게 아니다.

• 어떤 상품을 어떤 물류센터에 배치하는가
• 재고를 언제 어떻게 이동시키는가
• 반품 요청이 들어왔을 때 자동 승인 vs 수동 검토 기준
• 배송 지연 시 보상 정책

이건 코드 문제가 아니라 운영 정책이다.

토스도 똑같다.

• 송금 한도 산정 방식
• 사기 거래 탐지 threshold
• 특정 사용자 그룹 예외 처리

이건 ML 모델보다 위에 있는 규칙이다.

그리고 이건 외부에 없다.

---

여기서 진짜 문제가 시작된다

AI는 “장르”는 안다.
“회사”는 모른다.

이 차이가 실제 개발에서는 치명적이다.

왜냐하면 우리가 만드는 건 장르가 아니라 회사 시스템이기 때문이다.

---

그래서 AI에게 일을 맡기면 이상한 일이 생긴다

초반엔 잘 된다.

• 컴포넌트 생성
• API 연결
• 테스트 코드 작성

여기까지는 빠르고 정확하다.

근데 조금만 깊어지면 이상해진다.

• 같은 요청인데 결과가 달라진다
• 이전에 정한 규칙을 무시한다
• 고치면 다른 데가 깨진다

이건 모델이 멍청해서가 아니다.

“기준이 없어서”다.

---

SSOT가 왜 갑자기 중요해졌는가

사람끼리 일할 때는 암묵적 합의가 통한다.

“이건 이렇게 처리하는 게 맞지”
“이 경우엔 예외야”

이게 AI랑 일하면 다 깨진다.

그래서 기준을 밖으로 꺼내야 한다.

예를 들어 이런 식이다.

# Payment Domain Rules

- 모든 결제는 idempotent 해야 한다
- 실패 후 재시도 시 동일 transactionId 사용
- 외부 PG 실패 시 3회 재시도 후 fallback
- 특정 고객 그룹은 수동 승인 필요

이게 없으면 AI는 매번 다른 선택을 한다.

이게 바로 SSOT다.

코드보다 위에 있는 “판단 기준”.

---

여기서 개발자의 역할이 바뀐다

예전에는 이렇게 생각했다.

개발자 = 코드를 잘 짜는 사람

지금은 다르다.

개발자 = 도메인을 코드로 번역하는 사람
→ 이제는
개발자 = 도메인을 “AI가 이해할 수 있게” 번역하는 사람

이 차이가 크다.

---

이걸 실제 작업으로 풀면 이런 일이다

1. 규칙을 정의한다
2. 그 규칙을 문서화한다
3. AI가 항상 참고하게 만든다
4. 컨텍스트가 깨지지 않게 유지한다

예를 들어:

// 잘못된 방식
"이거 쿠팡처럼 만들어줘"

// 필요한 방식
"다음 규칙을 기반으로 구현해:
1. 재고는 지역 우선 배치
2. VIP 고객은 항상 우선 배송
3. 반품은 자동 승인 조건 A, B, C 충족 시만"

차이는 단순하다.

“요구” vs “제약”

AI는 요구보다 제약에서 훨씬 안정적으로 동작한다.

---

코딩이 상품화된다는 말의 진짜 의미

코드는 점점 싸진다. 이건 맞다.

근데 “싸진다 = 필요 없다”는 아니다.

인쇄기 얘기를 굳이 안 해도 된다.

더 직관적인 예가 있다.

SQL.

SQL은 이미 상품화됐다.
그렇다고 데이터 엔지니어가 사라졌나?

아니다.

오히려 데이터 모델링, 스키마 설계, 파이프라인 설계가 더 중요해졌다.

코드도 같은 길로 간다.

---

그래서 무게 중심이 이동한다

• 타이핑 → 제약 정의
• 구현 → 구조 설계
• 코드 작성 → 컨텍스트 관리

이건 축소가 아니라 이동이다.

---

비관론이 맞는 부분도 있다

코드만 짜던 사람은 힘들어진다.

왜냐하면 그 부분은 이미 대체되고 있기 때문이다.

근데 그건 역할의 일부였지 전부가 아니었다.

---

핵심은 하나다

AI는 도메인을 모른다.
그리고 앞으로도 스스로 알 수 없다.

누군가는 알려줘야 한다.

---

그걸 할 수 있는 사람은 제한적이다

• 도메인을 이해하고
• 코드로 구현할 수 있고
• 그걸 다시 구조화해서 설명할 수 있는 사람

이건 그냥 개발자가 아니다.

“설계 가능한 개발자”다.

---

그래서 질문은 이렇게 바뀐다

개발자가 사라지냐?
→ 아니다.

어떤 개발자가 남느냐?
→ 도메인을 번역할 수 있는 개발자.

---

이걸 못 하면 위기다.
이걸 할 수 있으면 기회다.

둘 사이의 차이는 생각보다 크다.