운영 중인 AI 에이전트 절반은 GPU 비용이 붙은 if문입니다

AI 요약

눈에 띄는 기술을 먼저 고른 뒤 문제에 맞추는 ‘이력서용 AI 엔지니어링’은 데모에서는 그럴듯해도 운영 환경에서 지연 시간, 토큰 비용, 디버깅 부담을 키웁니다. 저자는 AI를 쓸 수 있는지보다, 같은 일을 안정적으로 해내는 가장 단순한 방법이 AI인지 먼저 따져야 한다고 말합니다.

형식이 정해진 값은 정규식으로

청구서 번호가 INV-와 숫자 여덟 자리로 고정돼 있는데도 이메일마다 LLM에 번호 추출을 맡기는 사례를 듭니다. 모델이 대부분 맞히더라도 일부는 번호 형식을 바꾸거나 구매 주문 번호를 고릅니다. 정규식으로 먼저 찾으면 결과가 결정적이고 테스트하기 쉬우며 비용도 사실상 들지 않습니다. 정규식에서 결과를 찾지 못한 경우에만 모델로 넘기면 됩니다.

사실 조회는 SQL로

특정 고객의 최근 30일 미결제 주문을 찾는 질문은 의미를 해석하는 작업이 아니라 조건에 맞는 데이터를 조회하는 일입니다. 이 내용을 벡터 검색으로 처리하면 관련도가 높은 일부 문서만 가져와 전체 주문을 빠뜨릴 수 있습니다. 고객 번호, 상태, 생성 시각을 SQL 조건으로 지정하면 결과가 정확하고 완전하며 감사하기 쉽습니다. 벡터 검색은 항의 내용과 비슷한 문의를 찾는 것처럼 의미를 비교할 때 쓰는 편이 맞습니다.

열거할 수 있는 흐름은 조건문으로

엔터프라이즈 고객의 결제 문제는 계정 관리팀으로 보내고, 버그는 티켓을 만들며, 나머지는 FAQ를 안내하는 지원 흐름을 예로 듭니다. 분기 네 개로 표현되는 로직에 도구 사용, 계획 수립, 메모리를 갖춘 자율 에이전트를 붙이면 라우팅이 확률적으로 바뀌고 반복 실행에 빠질 수 있습니다. 왜 특정 티켓이 잘못된 팀으로 갔는지도 설명하기 어려워집니다. 화이트보드에 흐름을 그릴 수 있다면 매 요청마다 에이전트가 그 로직을 다시 찾아내게 할 이유가 적습니다.

AI는 기본값이 아니라 필요한 곳에

저자는 입력이 구조화돼 있거나 출력 형식이 고정돼 있다면 파싱·정규식·스키마 검증부터 시작하라고 제안합니다. 사실을 묻는 질문에는 SQL을, 의미를 비교하는 작업에는 임베딩을 쓰고, 분기 로직을 열거할 수 있다면 직접 작성하는 방식입니다. 오류가 조용히 잘못된 데이터로 남는 상황이라면 결정성이 특히 중요합니다. 프레임워크를 추가하기 전에는 시간이 지난 뒤 누가 유지보수하고 업그레이드하며 장애를 디버깅할지도 살펴야 합니다. AI를 쓰지 말자는 뜻은 아닙니다. 비정형 텍스트, 모호한 유사도 비교, 생성처럼 실제로 모호성이 있는 작업에 의도적으로 적용하자는 주장입니다.

dev.to 반응

• @ingosteinke — 전통적인 방식으로 코딩하는 걸 지루하다고 보지 않습니다. 정규식을 예로 들면 규칙적이고 간결하지만 상당히 복잡하기도 합니다. 구체적인 예시와 코드 조각을 고맙게 생각합니다. 글의 접근은 ‘AI를 최소한으로 쓰자’는 원칙과 검증된 여러 UNIX 철학에 공감합니다. 한 가지 일을 잘하는 단순한 도구 하나를 선호하고, 불필요한 권한을 주지 않으며, 과도하게 설계하지 않는 방식입니다. 제가 보는 가장 과한 구성은 요즘의 에이전트 하네스 데모들입니다. 에이전트 파일에 원하는 사항을 적고 AI가 요구사항대로 코드를 고치길 바라며, 매 반복마다 테스트와 린터를 돌립니다. 결국 사람이 결과를 검토하고 수정하며 규칙을 다듬어야 합니다. 이 방식이 규모를 키우기 전에 직접 코드를 작성했다면 같은 시간에 더 안전하게 끝냈을 수도 있습니다.
  • @cyclopt_dimitrisk — 맞습니다. 정규식 자체가 분명 하나의 기술입니다. 그런 에이전트 기반 코드 생성 반복은 10분 걸릴 일을 자동화하느라 10시간을 쓰는 전형적인 사례입니다. 실제 엔지니어링 대신 평범한 코드를 위한 대규모 QA와 디버깅 과정으로 바뀝니다. 때로는 그냥 앉아서 코드를 작성하는 편이 프로덕션까지 더 빠르고 안전하게 가는 길입니다.

원문: dev.to / 번역·요약: Trawling