개발자는 사라지지 않는다 — AI가 모르는 도메인이 있고, 그걸 이해시키는 게 당신 일이다
개발자 커뮤니티에 비관론이 퍼지고 있다.
"AI가 코드를 다 짜주는데 개발자가 필요하냐", "주니어 채용이 줄었다", "10년 후엔 개발자라는 직종이 없어진다" — 이런 얘기가 반복된다. 틀린 말은 아니다. 반복적인 CRUD 작업, 보일러플레이트 생성, 간단한 API 연동 수준의 코딩은 실제로 AI가 빠르게 잠식하고 있다. 그 부분에서 비관론은 근거가 있다.
근데 비관론이 전제하는 그림 — AI가 도메인을 이해하고 알아서 설계하고 책임까지 진다는 그림 — 에는 구멍이 있다.
크고 조용한 구멍이.
"도메인을 이해하는 AI"라는 말의 모순
AI가 도메인을 이해한다는 말은 반은 맞고 반은 틀리다.
주식 거래 앱을 만들어달라고 하면 AI는 꽤 그럴싸하게 만들어낸다. 종목 검색, 매수/매도 주문, 잔고 조회, 수익률 차트 — 주식 거래 앱이 갖춰야 할 기능들을 AI는 알고 있다. 학습 데이터에 증권 앱 관련 코드와 문서가 수없이 들어가 있으니까. 이 수준에서 "도메인 이해"는 맞는 말이다.
근데 키움증권을 만들어달라고 하면 얘기가 달라진다.
키움은 주식 거래 앱이지만, 동시에 키움증권이다. 키움에는 주식 거래라는 범용 도메인 위에 키움만의 레이어가 올라가 있다. 위탁 수수료 체계, 신용거래 담보 비율 산정 방식, 종목별 거래 정지 조건 처리 로직, 반대매매 발동 기준, 금융감독원 보고 체계와의 연동 방식 — 이건 주식 거래 앱 도메인이 아니다. 키움증권이 30년 가까이 금융 당국과 부딪히면서 쌓아온 비즈니스 규칙이다. 돈과 규제가 동시에 엮이는 영역이라 실수 하나가 민원이 되고, 민원이 쌓이면 제재가 된다. 그 긴장감 속에서 만들어진 룰들이다.
AI는 이걸 모른다.
학습 데이터에 없으니까. 키움 내부 정책 문서가 공개된 적 없고, 반대매매 로직이 오픈소스에 올라간 적 없다. AI가 아무리 뛰어나도 키움증권의 도메인은 키움 안에 있는 사람만 안다.
이게 단순한 예외처럼 들릴 수 있다. 근데 생각해보면 모든 회사가 키움증권이다.
쿠팡은 쇼핑몰이지만 쿠팡이다. 쿠팡의 배송 우선순위 알고리즘, 로켓배송 재고 관리 규칙, 반품 정책의 예외 케이스 처리 방식 — AI는 이커머스 도메인은 알아도 쿠팡 도메인은 모른다.
토스는 핀테크 앱이지만 토스다. 송금 한도 산정 방식, 사기 거래 탐지 임계값, 신용 점수 연동 정책 — AI는 핀테크 도메인은 알아도 토스 도메인은 모른다.
당신 회사도 마찬가지다. 규모가 크든 작든, 그 회사가 굴러가는 방식 — 예외 처리의 예외, 레거시 시스템과의 묵시적 계약, 특정 고객군에 적용되는 비공식 룰 — 은 코드베이스 어딘가에 박혀 있고, 문서화된 적 없고, 그 회사 오래 다닌 사람 머릿속에 있다. 키움증권이든 동네 스타트업이든 구조는 같다.
AI는 그걸 모른다. 알려주지 않으면 영원히 모른다.
그럼 누가 알려주냐
여기서 개발자의 역할이 재정의된다.
코드를 직접 짜는 비중이 줄어드는 건 맞다. 근데 그 빈자리를 채우는 게 AI가 아니라, AI에게 무엇을 어떻게 알려줄지를 설계하는 사람이다.
구체적으로 어떤 작업이냐.
AI에게 작업을 시키기 전에 이 회사, 이 서비스, 이 기능이 어떻게 작동해야 하는지를 명문화하는 작업이다. 요구사항 문서가 아니라 더 깊은 레이어 — 이 시스템이 절대 어겨선 안 되는 규칙이 뭔지, 어디서 어디까지가 이 컴포넌트의 책임인지, 두 모듈이 충돌할 때 어느 쪽이 우선인지. 이걸 정의하지 않으면 AI는 매번 다른 판단을 내린다. 일관성이 없어지고, 고칠수록 다른 곳이 깨진다.
SSOT(Single Source of Truth)라고 부르는 개념이 여기서 중요해진다. AI가 참조할 수 있는 단일 진실의 원천. 코드가 아니라 그 코드가 따라야 하는 원칙과 제약을 기록한 문서. ADR(Architecture Decision Record), 도메인 용어 사전, 불변식 목록 — 이런 것들이 AI에게 조직의 도메인을 이해시키는 인터페이스가 된다.
이 작업을 누가 하느냐. 코드를 짜던 개발자가 한다.
아니, 더 정확히는 — 코드를 짤 줄 알면서 동시에 도메인을 읽을 수 있는 사람이 한다. 비즈니스 요구사항이 코드 레벨에서 어떻게 구현되는지를 양방향으로 번역할 수 있는 사람. 이 번역 능력이 앞으로 개발자의 핵심 자산이 된다.
코드 작성이 상품화된다는 말의 의미
"코딩은 상품화된다"는 말이 맞다. 이미 되고 있다.
문제는 이 말을 "개발자가 필요 없어진다"로 곧바로 연결하는 데 있다. 코드 작성이 상품화되는 건 코드 작성이 저수준 작업이 된다는 뜻이지, 소프트웨어를 만드는 전체 과정이 자동화된다는 뜻이 아니다.
인쇄기가 발명됐을 때 필경사는 사라졌다. 근데 작가는 사라지지 않았다. 오히려 더 많아졌다. 생산 비용이 내려가면서 콘텐츠 자체의 수요가 폭발했기 때문이다. 코드 생성 비용이 내려가면 소프트웨어 수요가 늘어나고, 그 소프트웨어가 제대로 작동하게 만드는 사람의 수요는 줄지 않는다.
달라지는 건 그 사람이 하루의 어디에 시간을 쓰느냐다.
지금은 개발자가 시간의 상당 부분을 코드 작성에 쓴다. 앞으로는 그 비중이 줄고, 대신 AI가 코드를 잘 짜도록 컨텍스트를 설계하고 관리하는 작업에 더 많은 시간을 쓰게 된다. 이게 나쁜 변화인지, 아니면 오히려 개발자가 본래 해야 할 일에 집중하게 되는 건지는 관점의 문제다.
개인적으로는 후자에 가깝다고 본다.
코드를 타이핑하는 게 개발의 본질이 아니다. 문제를 이해하고, 구조를 설계하고, 제약을 정의하는 게 본질이다. AI가 타이핑을 대신해주면서 그 본질에 더 집중할 수 있게 됐다는 해석도 가능하다.
비관론이 놓치는 것
개발자 비관론이 전제하는 그림은 이렇다. AI가 점점 똑똑해져서 어느 순간 개발자가 하는 모든 걸 대체한다.
근데 그 그림엔 조직 특화 도메인이 없다. AI가 학습할 수 없는 내부 지식, 문서화되지 않은 비즈니스 규칙, 레거시와의 암묵적 계약 — 이것들은 AI가 아무리 발전해도 스스로 알 수 없다. 누군가 알려줘야 한다.
알려주는 방법도 단순하지 않다. 그냥 요구사항 문서 던져주는 게 아니라, AI가 일관되게 참조할 수 있는 형태로 구조화해야 한다. 컨텍스트 윈도우 한계 안에서 핵심 제약이 항상 포함되도록 관리해야 한다. 모델이 바뀌거나 프로젝트가 길어지면 컨텍스트가 희석되는 문제를 막아야 한다.
이게 기술적인 문제다. 그리고 지금 이 문제를 제대로 다루는 개발자가 많지 않다.
비관론이 맞는 부분은 분명히 있다. 코드만 짜는 사람의 자리는 줄어든다. AI가 그걸 더 빠르고 싸게 하니까. 근데 그게 개발자 전체의 이야기가 아니다. 코드 작성이 역할의 전부였던 사람에게만 해당하는 이야기다.
무게 중심이 이동하고 있다.
코드 작성에서 설계로. 구현에서 제약 정의로. 타이핑에서 도메인을 AI가 이해할 수 있는 형태로 번역하는 작업으로.
이 이동을 위기로 보는 사람과 기회로 보는 사람이 갈린다. 어느 쪽이 맞는지는 아직 모른다. 근데 확실한 건, 도메인을 모르는 AI가 조직 안에서 제대로 작동하려면 그 도메인을 이해하고 전달할 수 있는 사람이 반드시 필요하다는 거다.
그 사람이 개발자가 아니면 누구겠냐.
댓글
댓글 쓰기