AI 워크플로 검증과 비용 관리

이 장에서 배울 것

AI를 업무에 도입하면 처음에는 속도가 눈에 띄게 빨라진다. 보고서 초안이 몇 분 만에 나오고, 코드 수정안도 금방 만들어진다. 하지만 실무에서 진짜 차이는 그다음에 난다. AI가 만든 결과를 어떻게 검증하고, 비용을 어떻게 통제하느냐가 성과를 결정한다.

이 장에서는 AI 산출물을 검증하는 기준을 세우고, 코딩 에이전트를 안전하게 운영하는 원칙을 정리한다. 또한 토큰 비용뿐 아니라 재시도, 검색, 도구 호출, 에이전트 실행 시간까지 포함해 업무 단위로 비용을 관리하는 방법을 배운다.

왜 이 주제가 중요한가

AI 결과물은 빠르지만 항상 맞지는 않다. 틀린 출처를 그럴듯하게 만들 수 있고, 테스트를 실행하지 않았는데도 "정상 동작합니다"라고 말할 수 있다. 최신 정보가 필요한 질문에 오래된 내용을 답할 수도 있다. 코딩 에이전트라면 더 조심해야 한다. 파일을 읽고 수정하며, 쉘 명령을 실행하고, 저장소 상태를 바꿀 수 있기 때문이다.

그래서 AI 워크플로의 목표는 "한 번에 정답을 받기"가 아니다. 목표는 검증 가능한 작업 흐름을 만드는 것이다. 좋은 워크플로는 누가 보아도 다음을 확인할 수 있어야 한다.

• 무엇을 요청했는가

• 어떤 자료를 사용했는가

• 어떤 결과가 나왔는가

• 무엇으로 검증했는가

• 검증하지 못한 부분은 무엇인가

• 비용과 시간이 얼마나 들었는가

이 기록이 없으면 AI 사용은 개인의 감에 의존한다. 기록이 있으면 팀의 운영 방식이 된다.

핵심 개념 설명

검증 기준을 다섯 가지로 나누기

AI 산출물은 다음 다섯 기준으로 확인한다.

예를 들어 시장 조사 보고서를 만들었다면 사실성과 출처가 중요하다. Gemini의 Search grounding처럼 모델 출력을 확인 가능한 검색 결과에 연결하는 방식은 환각을 줄이고 출처 확인을 쉽게 만드는 데 도움이 된다.¹ 사내 문서나 내부 지식베이스가 중요한 업무라면 RAG도 활용할 수 있다. RAG는 Retrieval-Augmented Generation의 줄임말로, AI가 답하기 전에 관련 문서를 검색해 그 내용을 근거로 답하게 하는 방식이다. 반대로 내부 코드 리팩터링이라면 실행 가능성과 보안·권한이 더 중요하다. 테스트가 통과했는지, 변경 범위가 과하지 않은지, 민감한 설정 파일을 건드리지 않았는지 봐야 한다.

검증 루프 만들기

검증 루프는 복잡하지 않아도 된다. 다음 네 칸만 남겨도 충분하다.

1. 입력 명세: 요청 목적, 요구사항, 금지사항

2. 사용 자료: 파일, 링크, 내부 문서, 검색 결과

3. 실행 결과: 생성된 문서, 코드 diff, 테스트 결과, 화면 캡처

4. 검증자와 판단: 본인 또는 동료가 확인한 항목, 통과/보류/실패

코딩 에이전트 작업에서는 여기에 두 가지를 더한다.

• 실행한 명령어: npm test, npm run build, pytest 등

• 변경 단위: 커밋, PR, diff 링크

이렇게 남기면 "AI가 했습니다"가 아니라 "이 입력으로 작업했고, 이 테스트로 확인했습니다"라고 말할 수 있다.

환각을 업무 실패 유형으로 보기

환각은 단순히 문장이 틀린 문제가 아니다. 실무에서는 다음 형태로 나타난다.

• 오래된 법규나 가격 정보를 최신 정보처럼 말함

• 존재하지 않는 논문, 기사, API 문서를 출처로 제시함

• 테스트를 실행하지 않았는데 성공했다고 말함

• 프로젝트 컨벤션을 무시하고 새로운 구조를 만들어냄

• 보안상 금지된 파일이나 환경 변수를 읽으려 함

• 오류 로그 일부만 보고 원인을 단정함

따라서 "AI가 거짓말을 했다"에서 멈추면 안 된다. 어떤 검증 장치가 빠졌는지 봐야 한다. 출처 확인이 없었는가? 테스트 명령이 없었는가? 프로젝트 규칙 문서가 없었는가? 권한 경계가 없었는가? 실패를 이렇게 분석해야 다음 작업에서 같은 문제가 줄어든다.

코딩 에이전트 운영 원칙

Claude Code, Codex 같은 코딩 에이전트는 단순한 채팅 도구가 아니다. 터미널, 파일 시스템, 저장소와 연결되어 실제 작업을 수행한다. Anthropic의 Claude Code 가이드에서도 프로젝트 규칙 문서, 탐색→계획→코딩→커밋 흐름, 테스트 실행, 컨텍스트 관리 같은 패턴을 강조한다.²

실무에서는 다음 원칙을 기본값으로 둔다.

• 작업 전 범위 지정: "이 파일들만 읽고, 아직 수정하지 마."

• 읽기/쓰기 권한 분리: 조사 단계는 읽기 전용으로 진행한다.

• 작은 단위의 변경: 한 번에 대규모 수정 대신 작은 커밋으로 나눈다.

• 테스트 명령 실행: 변경 후 관련 테스트와 빌드를 실행한다.

• diff 리뷰: AI 설명보다 실제 변경 diff를 기준으로 판단한다.

• 파괴적 명령 금지: 삭제, 강제 푸시, 운영 DB 접근은 명시 승인 없이는 금지한다.

좋은 시작 문장은 다음과 같다.

아직 파일을 수정하지 말고, 관련 파일을 읽은 뒤 변경 계획만 제시해줘. 수정 범위, 예상 위험, 실행할 테스트 명령을 함께 써줘.

이 한 문장은 에이전트를 바로 실행자로 만들지 않고, 먼저 조사자와 설계자로 둔다.

쉬운 비유 또는 사례

AI 워크플로는 신입 직원에게 일을 맡기는 것과 비슷하다. 똑똑하고 빠르지만 회사의 암묵적 규칙은 모른다. "고객 보고서 만들어줘"라고만 하면 문체, 근거 수준, 보안 기준, 결재 양식을 추측한다. 반면 다음처럼 말하면 결과가 달라진다.

이 보고서는 임원용 1페이지 요약이다. 내부 매출 파일과 최근 검색 자료만 사용하라. 숫자는 출처를 표시하고, 추정은 추정이라고 써라. 마지막에 검증하지 못한 항목을 따로 적어라.

코딩도 같다.

결제 모듈을 고쳐줘.

보다,

payment-service의 환불 금액 계산 버그를 조사해줘. 먼저 관련 파일과 테스트를 찾아 요약하고, 수정 전 계획을 제시해줘. 구현 후 npm test -- payment를 실행하고 diff를 요약해줘.

가 훨씬 안전하다. AI의 성능 차이보다 일을 맡기는 구조의 차이가 결과 품질을 크게 바꾼다.

직접 해보는 실습

이번 실습은 한 주 동안 진행한다. 목표는 "AI를 얼마나 많이 썼는가"가 아니라 "AI 작업을 얼마나 검증 가능하게 남겼는가"를 확인하는 것이다.

AI 사용 로그 표 만들기

스프레드시트나 노션에 다음 열을 만든다.

작업 유형별로 모델을 나누기

한 주 동안 모든 일을 최고급 모델에 맡기지 않는다. 다음처럼 라우팅해본다.

• 초안 작성: 빠르고 저렴한 모델

• 최신 정보 확인: 검색 또는 grounding이 가능한 모델

• 긴 문서 분석: 긴 컨텍스트에 강한 모델

• 코드 수정: 코딩 에이전트 또는 코드 특화 모델

• 최종 리뷰: 더 신중한 모델 또는 사람 리뷰

비용 관리는 토큰 단가만 보는 일이 아니다. 긴 컨텍스트 유지, 반복 재시도, 검색 호출, 고급 모델 사용, 에이전트 실행 시간까지 함께 봐야 한다. Google도 Gemini API 비용 관리를 위해 프로젝트별 월간 지출 한도와 비용 대시보드 같은 기능을 제공한다고 설명한다.³ 핵심은 특정 제품 기능을 외우는 것이 아니라, 프로젝트·업무 단위로 비용을 볼 수 있어야 한다는 점이다.

회고문 작성하기

일주일 뒤 다음 질문에 답한다.

1. 가장 품질이 좋았던 작업은 무엇인가?

2. 가장 많이 재작업한 작업은 무엇인가?

3. 검증 없이 사용했다면 위험했을 결과는 무엇인가?

4. 반복해서 쓴 프롬프트는 무엇인가?

5. 체크리스트나 명령어로 재사용할 수 있는 작업은 무엇인가?

6. 다음 주에 줄일 비용은 무엇인가?

이 회고문이 다음 장의 자동화 포트폴리오 재료가 된다.

흔한 실수와 오류 분석

실수 1: AI 답변을 최종 결과로 착각한다

AI 답변은 초안이다. 최종 결과가 되려면 검증이 필요하다. 특히 숫자, 법규, 가격, 경쟁사 정보, 코드 동작은 반드시 별도 확인이 필요하다.

실수 2: 테스트 실행 여부를 묻지 않는다

코딩 에이전트가 "수정했습니다"라고 말해도 테스트를 실행하지 않았을 수 있다. 프롬프트에 "실행한 명령어와 결과를 보고하라"를 넣어야 한다.

실수 3: 큰 작업을 한 번에 맡긴다

한 번에 기능 전체를 맡기면 변경 범위가 커지고 리뷰가 어려워진다. 조사, 계획, 구현, 테스트, 리뷰로 나눈다.

실수 4: 컨텍스트를 계속 쌓아둔다

긴 대화는 편하지만 잡음이 많아진다. 작업이 바뀌면 새 대화를 시작하거나, 현재 결정 사항을 짧은 문서로 요약한 뒤 이어간다.

실수 5: 비용을 구독료만으로 본다

월 구독료만 보면 실제 비용을 놓친다. 실패한 재시도, 불필요한 검색, 긴 파일 전체 입력, 병렬 에이전트 실행도 비용이다.

요약

AI 실무의 핵심은 빠른 생성이 아니라 검증 가능한 운영이다. 산출물은 요구사항 충족, 사실성, 실행 가능성, 보안·권한, 비용 기준으로 확인한다. 최신 정보나 내부 문서 근거가 중요한 작업에서는 Search grounding이나 RAG처럼 외부 근거를 연결하는 방식을 활용하되, 최종 확인은 사람이 해야 한다. 코딩 에이전트는 파일과 쉘에 접근하므로 읽기/쓰기 권한을 나누고, 작은 커밋과 테스트 실행, diff 리뷰를 기본 원칙으로 삼아야 한다. 비용은 토큰 단가뿐 아니라 컨텍스트, 재시도, 도구 호출, 모델 선택, 실행 시간을 업무 단위로 기록해야 한다.

퀴즈

1. AI 산출물 검증 기준 다섯 가지는 무엇인가?

2. "테스트를 실행하지 않았는데 성공했다고 말함"은 어떤 유형의 실패인가?

3. 코딩 에이전트에게 큰 작업을 맡기기 전 가장 먼저 요청하면 좋은 것은 무엇인가?

4. 비용 관리에서 토큰 단가 외에 기록해야 할 항목을 세 가지 이상 써보라.

5. Search grounding이나 RAG가 필요한 작업과 필요하지 않은 작업을 각각 하나씩 예로 들어보라.

체크리스트

• 작업마다 입력 명세를 남겼다.

• 사용한 자료와 출처를 기록했다.

• AI 산출물을 요구사항 기준으로 확인했다.

• 최신 정보가 필요한 내용은 검색 또는 출처로 검증했다.

• 코드 변경은 diff로 리뷰했다.

• 관련 테스트나 빌드 명령을 실행했다.

• 민감 파일과 파괴적 명령에 대한 제한을 두었다.

• 재작업 횟수와 소요 시간을 기록했다.

• 고급 모델을 써야 할 단계와 저렴한 모델로 충분한 단계를 구분했다.

• 반복 작업을 프롬프트, 체크리스트, 명령어 후보로 정리했다.

다음 장 연결

다음 장에서는 지금까지 만든 프롬프트, 프로젝트 규칙, 검증 로그를 하나의 업무 자동화 포트폴리오로 묶는다. 목표는 "AI를 잘 써봤다"에서 끝나는 것이 아니다. 반복 가능한 자동화 사례를 정리해, 보고서 자동화, 코드 리뷰, 리서치 워크스페이스, 검증 체크리스트를 실제 성과물로 보여주는 것이다.

참고

¹Google Cloud grounding overview

²Anthropic Claude Code best practices

³Google AI Studio cost controls announcement