AI 자동화 병목은 모델이 아니라 도메인 지식이다

지난 3개월간 AI 자동화 실패담을 보면 "GPT-4가 이걸 못 알아들어요", "Claude가 이 부분에서 헷갈려요"라는 말이 많더라고요. 저도 처음엔 모델 성능 탓을 했어요. 하지만 블로그 자동발행 파이프라인을 돌리면서 깨달았습니다 — 진짜 병목은 모델이 아니라 제가 그 도메인을 얼마나 아는지였어요. 온실 재배와 구직 플랫폼을 만든 두 사례를 보니 확신이 섰습니다.

터미널도 모르던 사람이 온실 전체를 자동화한 이유

Reddit에서 본 사례입니다. 비기술자가 Claude로 고구마 온실 재배를 자동화했어요. 토양 센서 하네스, 날씨 API 연동, 스프레드시트 집계, cron 스케줄러까지 붙였다고 하더라고요. 출처: What I Built with Claude — sweet potatoes. 출발점은 터미널도 낯설었던 사람이었습니다.

이 사람이 성공한 건 Claude가 특별히 똑똑해서가 아니에요. 재배 도메인을 이미 알았기 때문이죠. 어느 시점에 물을 줘야 하는지, 온도가 몇 도 넘으면 위험한지, 생육 단계마다 어떤 데이터를 봐야 하는지 — 이런 걸 알아야 센서를 어디에 어떻게 붙일지 물어볼 수 있거든요. AI는 "센서 연결하는 코드"는 짜주지만 "이 작물에 왜 이 센서가 필요한지"는 안 알려줍니다.

제가 직접 겪은 것도 비슷해요. 이 블로그 파이프라인에는 결정론 게이트가 16종 있습니다. 한국어 AI-티 탐지, 인용 출처 세탁 방지, 내부 중복 검사 같은 거요. 이걸 설계할 때 LLM 성능은 별로 중요하지 않았어요. 대신 "한국어 AI 글은 어떤 패턴으로 티가 나는지", "출처 없는 통계를 어떻게 숨기는지" 같은 도메인 지식이 전부였습니다. 제가 그 패턴을 모르면 아무리 좋은 모델을 써도 못 막아요.

4개월 만에 구직 플랫폼을 만든 사람의 공통점

또 다른 사례는 구직 플랫폼입니다. 배우자가 Indeed에서 해고당한 뒤 약 4개월간 채용공고 크롤러와 Workday, Greenhouse, Lever 같은 ATS 폼 자동 입력 기능을 만들었어요. 출처: Indeed laid off my pregnant wife, so I built a job search competitor with Claude. 실사용 가능한 수준까지 간 거죠.

여기서도 핵심은 도메인이었어요. 각 ATS 플랫폼의 폼 구조가 어떻게 다른지, 어떤 필드가 필수고 어떤 게 선택인지, 제출 후 어느 단계에서 검증이 도는지 — 이런 걸 알아야 자동화 지점을 찾을 수 있거든요. Claude가 "폼 자동 입력 코드"는 짜주지만 "Workday는 이 단계에서 CSRF 토큰을 갱신한다"는 안 알려줍니다. 직접 써본 사람만 압니다.

저는 Reddit RSS 수집 스크립트를 만들 때 이걸 체감했어요. Reddit이 데이터센터 IP에서 JSON 엔드포인트를 403으로 막는다는 걸 알아야 RSS Atom 피드로 우회할 생각을 하죠. 이건 LLM이 가르쳐주는 게 아니라 제가 직접 막혀봐야 아는 겁니다. 도메인 지식 없이 "Reddit 크롤링 코드 짜줘"만 하면 첫 실행에서 바로 막힙니다.

모델 성능이 중요하지 않다는 건 아니지 않나요?

여기까지 읽으면 "그래도 모델이 너무 구리면 아무것도 못 하잖아요"라는 반론이 나올 겁니다. 맞아요. GPT-2 수준으로는 코드를 제대로 못 짜죠. 하지만 GPT-3.5 이상만 되면 기술 장벽은 이미 충분히 낮아졌어요. 요즘 병목은 모델이 아니라 "무엇을 만들지"를 정하는 쪽입니다.

"도메인 지식 없어도 AI가 다 알려주지 않나요?"라는 말도 있을 거예요. 실제로는 안 됩니다. AI는 일반론만 줘요. "온실 자동화에는 온도·습도·토양 센서가 필요합니다" 같은 거요. 하지만 "이 작물은 밤 온도가 15도 아래로 떨어지면 생육이 멈춘다"는 직접 키워본 사람만 알아요. 그걸 알아야 "15도 이하일 때 알림 보내는 로직 짜줘"라고 물어볼 수 있죠.

"기술 지식이 없으면 구현 단계에서 막히지 않나요?"도 흔한 반론이에요. 맞긴 한데, Claude 같은 코드 생성 모델이 그 벽을 많이 낮췄습니다. 터미널 명령어 모르던 사람도 cron 스케줄러를 돌려요. 하지만 "언제 돌릴지"는 도메인 지식이 정합니다. 기술은 도구고, 도메인은 목적이에요.

당신이 자동화하고 싶은 게 있다면

정리하면 이래요. AI 자동화가 막힐 때 모델을 바꾸기 전에 물어보세요 — 내가 이 도메인을 얼마나 아는가. 온실 재배를 자동화하려면 재배 지식이, 구직 플랫폼을 만들려면 ATS 구조 이해가, 블로그 게이트를 설계하려면 한국어 AI 글 패턴 관찰이 먼저입니다.

제 경험으로는 게이트 16종 중 13종이 도메인 지식 덩어리였어요. 4-gram MinHash 중복 검사, 한국어 휴머나이즈 패턴, 인용 출처 빈 URL 탐지 — 전부 "이런 식으로 품질이 무너진다"는 걸 직접 보고 막은 거예요. LLM은 그 지식을 코드로 바꿔줬을 뿐이죠.

당신이 AI로 자동화하고 싶은 게 있다면, 모델 API 문서를 읽기 전에 그 도메인 책을 먼저 읽어보세요. 그게 진짜 지름길입니다.

자주 묻는 질문

Q. 도메인 지식이 전혀 없는 분야를 자동화해야 한다면 어떻게 하나요?

A. 먼저 그 분야 실무자의 하루를 관찰하세요. 어떤 작업을 언제 왜 하는지 보면 자동화 지점이 보여요. 책은 원리만 주지만 관찰은 예외 케이스까지 알려줍니다.

Q. 도메인 전문가와 협업할 때 어떻게 소통하나요?

A. "이 단계에서 실패하면 어떻게 되나요?"를 반복해서 물어보세요. 전문가는 당연한 걸 안 말하거든요. 예외 상황과 실패 시나리오를 캐내야 자동화가 깨지지 않아요.

Q. AI에게 어디까지 맡기고 어디부터 직접 확인해야 하나요?

A. 도메인 규칙이 명확한 부분은 AI에게 맡기고, 예외가 많거나 비용이 큰 결정은 사람이 봐야 해요. 저는 게이트 16종 중 결정론 13종만 자동이고 검증자 5명은 사람 판단입니다.

Q. 자동화가 잘못된 방향으로 가고 있다는 신호는 무엇인가요?

A. 예외 처리가 본 로직보다 길어지거나, 같은 실패가 3번 반복되면 설계를 다시 봐야 해요. 도메인을 모르면 예외가 무한히 늘어납니다.

Q. 도메인 지식을 빠르게 쌓는 방법이 있나요?

A. 실패 사례를 먼저 보세요. 성공 사례는 일반론만 주지만 실패담엔 구체적인 함정이 나와요. 저는 AI 글 500편의 실패 패턴을 보고 게이트를 만들었습니다.