AI를 잘 쓰는 사람은 왜 직접 고치지 않을까

“AI가 혼자 하면 척척 끝내는 회계 결산을, 사람이 끼어들면 오히려 망친다.”

조금 억울하고 기분 나쁜 이야기다. 우리가 AI보다 멍청하다는 뜻일까? 아니다. 비유하자면 자율주행이 가능한 스포츠카를 사놓고, 조수석 사람이 불안하다는 이유로 운전대를 계속 잡아당기는 상황이다. 운전자가 누구인지, 어떤 순간에 개입해야 하는지 정해져 있지 않으면 속도도 안전도 잃는다.

원문에 등장하는 ‘AI 단독 20번 만점, 회계사와 협업하면 15배 느려짐’이라는 구체적인 비교는 원연구를 확인하지 못했다. 그러나 문제의식 자체는 실재한다. Mercor의 APEX-Accounting 평가에서 12명의 초급 공인회계사와 최상위 AI를 비교한 결과, 일정한 범위의 명확한 과제에서는 AI가 더 좋은 성능을 보였다. 이는 회계사 전체의 역량이나 복잡한 실무 전체를 평가한 결과가 아니다.

2026년의 최상위 AI는 단순히 질문에 대답하는 챗봇이 아니다. 자료를 읽고, 계획을 세우고, 도구를 실행하고, 다시 검사하는 에이전트(Agent) 기능을 갖추기 시작했다. 클로드 계열은 장문 문서 및 코딩 업무, OpenAI 계열은 추론과 도구 활용, 제미나이 계열은 멀티모달 자료를 활용하는 작업에서 각기 다른 강점을 보여 준다. 그렇다고 수만 페이지를 빠짐없이 기억하거나, 며칠짜리 일을 항상 오류 없이 끝내는 ‘완전 자율 직원’이 된 것은 아니다. 컨텍스트 한도, 파일 접근 권한, 실행 시간과 검증 능력은 제품과 요금제, 작업 환경에 따라 달라진다.

정작 중요한 변화는 모델 이름이 아니라 사람이 일을 맡기는 방식이다.

1. 사람이 끼어들수록 일이 꼬이는 습관 세 가지

첫째, AI에게 생각하는 순서까지 일일이 가르친다

과거에는 “1단계는 이렇게, 2단계는 저렇게”라고 잘게 나눠야 답이 나았다. 지금도 계산 절차나 법정 프로세스처럼 반드시 따라야 할 단계는 지정해야 한다. 그러나 기획과 분석처럼 다양한 접근이 가능한 업무에서 인간의 임의적인 사고 순서를 강요하면 더 나은 해결 경로를 막을 수 있다.

“이런 순서로 생각해”보다 “최종 목표는 이것, 반드시 지켜야 하는 조건은 이것, 통과해야 할 검사는 이것”이 유용한 경우가 많다.

둘째, 자료를 아껴서 조금씩 준다

원본 100페이지가 있는데 인간이 3페이지로 요약해 주면 AI는 이미 잘려 나간 정보부터 복원해야 한다. 계약서의 예외 조항, 회계 주석, 경쟁사 발표 자료의 단서가 그 과정에서 사라진다.

가능하면 출처가 명확한 원본을 제공하고 파일별 역할을 설명하자. 다만 큰 파일을 무조건 한꺼번에 투입하는 것도 정답은 아니다. 입력 용량을 넘거나 핵심 정보가 묻힐 수 있으므로, 파일 목록과 인덱스를 먼저 만들고 관련 원문을 단계적으로 읽게 하는 방식이 더 정확할 때도 있다. 민감정보는 접근 권한부터 점검해야 한다.

셋째, 중간 결과물에 직접 손을 댄다

요리사인 AI가 재료와 분량을 계산해 요리하는데, 옆에서 맛을 보고 냄비마다 소금을 붓는 상황과 비슷하다. 특히 AI가 동시에 편집하는 엑셀 파일이나 코드에 사람이 개입하면 버전 충돌과 정합성 문제가 생길 수 있다.

다만 직접 수정 자체가 잘못은 아니다. 중요한 건 수정 책임자가 누구인지 명확히 하고, 수정 이후 관련 수식과 테스트를 다시 검증하는 일이다. 사람의 판단이 필요한 문장과 숫자는 얼마든지 수정할 수 있다. 다만 수정된 파일을 AI가 이전 상태로 착각하지 않도록 변경사항을 알려 줘야 한다.

2. 결과물을 붙잡고 씨름하지 말고, 작업 지시서를 개선하라

여기서 업무 방식이 달라진다. 사람이 모든 단계에 참여하는 In-the-Loop 방식에서, AI의 작업을 바깥에서 감독하며 특정 승인 지점에만 참여하는 On-the-Loop 방식으로 이동하는 것이다. 흔히 작업을 실행시키는 규칙, 도구, 테스트, 권한의 묶음을 하네스(Harness) 라고 부른다.

핵심은 ‘사람은 아무것도 검토하지 말라’가 아니다. 사람이 어디에 개입하면 가장 큰 가치를 만드는지 다시 설계하자는 것이다.

3. 실제로 이렇게 써보자 - 도구별 활용 매뉴얼

① ChatGPT와 클로드 웹·앱 - 글쓰기, 리서치, 기획

끝없는 말싸움 대신 새 출발. AI가 쓴 보고서가 마음에 들지 않는데 “아니, 그게 아니고”라는 대답만 계속 붙이면 낡은 지시와 잘못된 초안이 뒤섞이기 쉽다. 대화가 꼬였을 때는 최초 요청을 수정할 수 있는 제품에서는 그 기능을 이용하고, 아니라면 새 대화에서 목표와 조건을 깔끔하게 다시 제시하자. 항상 새 대화가 좋은 것은 아니다. 장기간 축적된 중요한 맥락이 있다면 요약해서 함께 옮겨야 한다.

검수도 다른 AI에 맡겨 교차 검증. 가령 클로드가 작성한 보고서를 ChatGPT에 넣고 이렇게 요청한다.

“너는 깐깐한 편집장이자 감사관이다. 아래 글에서 사실과 의견의 혼동, 숫자 불일치, 논리적 비약 중 가장 심각한 세 가지를 골라라. 각각 원문 인용, 문제가 되는 이유, 확인할 1차 자료를 함께 제시하라. 확인하지 못한 것은 추정이라고 표시하라.”

AI 두 개가 같은 잘못된 자료를 믿으면 둘 다 틀릴 수 있다. 그러므로 AI끼리 교차 검증하고, 사람은 출처가 있는 핵심 주장과 고위험 결론을 최종 확인하는 조합이 좋다.

② 클로드 코워크 - 내 컴퓨터 파일과 문서 정리

폴더 격리, 각방 쓰기. 원본이 담긴 재료 폴더와 새로운 결과물을 저장할 완성 폴더를 나누자. 읽기 권한과 쓰기 권한을 구분할 수 있다면 원본 폴더는 읽기 전용으로 설정한다. AI가 작업 중인 파일을 사람이 동시에 편집하지 않고, 결과는 다른 이름으로 저장하게 한다. 어떤 도구든 실제 파일 접근 범위와 실행 승인 설정을 먼저 확인해야 한다.

100개를 한 번에 맡기지 말고 1개를 승인하라. “일단 첫 번째 파일 하나만 처리하고 결과 샘플과 계획서를 보여줘.” 샘플을 확인한 다음 “승인한다. 나머지 99개는 같은 기준으로 처리하되, 원본 수정이나 외부 전송, 삭제가 필요하면 멈춰서 물어봐”라고 지시한다. 오류 파일은 건너뛰되 예외 목록을 남기게 할 수 있다. 다만 작업이 실제로 끝까지 자동 실행되는지는 사용 중인 도구의 실행시간 및 승인 정책에 달려 있다.

③ 클로드 코드와 코덱스 - 코딩을 몰라도 앱과 웹을 만드는 법

소스코드보다 명세를 먼저. Claude Code의 CLAUDE.md, 별도 SPEC.md, Codex 등에서 쓰는 프로젝트 지침 파일에는 제품 목표, 폴더 구조, 코딩 규칙, 테스트 명령, 수정 금지 대상을 적어 둔다. Anthropic도 CLAUDE.md를 프로젝트의 지속 지침으로 설명한다. 다만 이것이 ‘소스코드 수정 절대 금지’를 뜻하지는 않는다. 개발자가 코드를 수정했다면 AI에 변경 내용을 알려 주고 버전 관리로 충돌을 방지하면 된다.

추측보다 날것의 에러 로그. 로그인 오류가 나면 “내 생각엔 버튼 변수가 틀렸어”라고 먼저 단정하기보다 에러 메시지, 재현 방법, 기대했던 동작, 실제 동작을 함께 준다. API 키, 개인정보, 접근 토큰은 지운 후 공유한다.

자동 테스트를 먼저 만들고 AI가 고치게 한다. “이 기능의 성공 조건을 정의하고, 자동화 가능한 테스트를 작성한 다음, 테스트를 실행하며 오류를 수정해.” 이 방식은 TDD(Test-Driven Development)에 가깝다. 하지만 테스트 100% 통과가 ‘완벽한 제품’이라는 뜻은 아니다. 잘못 만든 테스트는 잘못된 프로그램에도 초록불을 켠다. 보안, 실제 사용자 흐름, 접근성은 별도 확인이 필요하다.

세 번 고쳐도 안 되면 판을 다시 보자. 같은 오류를 세 번 반복한다면 무한 수정보다 마지막 정상 버전의 커밋으로 돌아갈지를 검토하자. git reset 같은 파괴적 명령은 미커밋 변경을 지울 수 있으므로 백업 또는 새 브랜치를 만든 뒤 진행한다. 요구사항을 더 작은 단위로 나눠 다시 시도하는 편이 낫다.

4. 복사해서 바로 쓰는 작업 지시서 세 가지

아래에서 대괄호 부분만 자신의 업무에 맞게 바꿔 사용할 수 있다. ‘무한 반복’이나 ‘완벽’ 같은 비현실적인 명령 대신 검증 기준과 중단 조건을 넣었다.

지시서 ① 직장인용 - 기획서, 보고서, 데이터 분석

[최종 목표]
첨부한 원본 자료를 바탕으로 [이번 분기 신사업 출시 기획서 / 경쟁사 재무 비교 보고서] 최종본을 작성해 줘.

[금지 규칙]
원본에 없는 수치나 인용을 지어내지 마. 모르는 내용은 [확인 필요]라고 표시해. “혁신적인”, “다양한 시너지” 같은 추상적인 표현 대신 수치, 근거, 실행 방안을 써. 중요한 주장마다 해당 원본이나 링크를 연결해.

[자가 검증]
제출 전에 논리적 비약, 숫자 불일치, 빠진 반론을 스스로 점검하고 수정해. 검증하지 못한 항목은 숨기지 말고 최종본 끝에 별도로 알려줘. 본문과 함께 핵심 확인 사항 세 가지를 제출해.

지시서 ② 클로드 코워크용 - 폴더와 대량 문서 처리

[작업 환경]
[재료 폴더]의 파일은 읽기만 하고 수정하거나 삭제하지 마. 결과는 [완성 폴더]에 새로운 파일로 저장해. 파일 이름과 처리 성공 여부를 목록으로 남겨.

[1단계 : 샘플 승인]
먼저 파일 한 개만 [원하는 정리 또는 요약] 방식으로 처리하고, 결과 샘플과 전체 처리 계획을 보여줘. 내가 승인할 때까지 나머지 파일은 처리하지 마.

[2단계 : 일괄 처리]
승인 후에는 같은 기준으로 나머지를 처리해. 해석이 모호하거나 깨진 파일은 임의로 고치지 말고 건너뛰어 예외사항_보고서.md에 기록해. 원본 수정, 삭제, 외부 전송, 결제, 권한 변경이 필요하면 반드시 내 승인을 다시 받아.

[완료 조건]
처리 개수, 성공과 실패 개수, 결과 폴더, 주요 예외를 요약해서 보고해.

지시서 ③ 바이브 코딩용 - 자율 코딩과 테스트

[역할과 목표]
나는 요구사항과 승인 기준을 제공한다. 구현, 테스트 실행, 오류 수정은 가능한 범위에서 네가 수행해. 목표 기능은 [구현할 기능]이다.

[계획]
먼저 변경할 파일과 의존성, 예상 위험, 테스트 방법을 짧게 제시해. 기존 정상 동작을 보존하고 변경 전 복구 가능한 상태를 확보해.

[테스트 선행]
기능의 완료 조건을 테스트 가능한 문장으로 정리하고 단위 테스트 및 필요한 통합 테스트를 작성해. 그다음 기능을 구현해.

[자율 수정]
테스트 실행과 오류 수정은 최대 [3회] 반복해. 매번 실제 로그에 근거해 수정하며 테스트를 삭제하거나 검증 기준을 약화시켜 통과시키지 마. 같은 문제가 반복되거나 권한, 데이터 삭제, 보안 문제가 생기면 즉시 중단하고 원인과 선택지를 보고해.

[완료 보고]
변경한 파일, 테스트 실행 결과, 미해결 위험, 실제로 검증하지 못한 항목을 구분해서 제출해. “모두 완벽”이라는 표현은 쓰지 마.

5. 마지막 퍼즐 - 사람은 무엇으로 돈을 벌 것인가

첫째, 인간의 가치는 실무 노동에서 책임과 판단으로 옮겨간다. AI가 재무제표 초안을 몇 분 만에 만들어도 법적으로 책임지는 회계사나 회사의 최종 서명이 자동으로 대체되는 것은 아니다. 검증 근거를 남기고, 예외를 판단하고, 고객과 감독기관에 설명할 수 있는 능력에 새로운 프리미엄이 붙을 수 있다. 그렇다고 ‘도장만 찍으면 된다’는 뜻은 아니다. 전문직의 서명은 실질적 검토 의무를 포함한다.

둘째, AI 롤업(Roll-up)은 소프트웨어 판매보다 업무 방식 전체를 바꾸려는 전략이다. 투자자가 기존 회계, 법률, 전문서비스 회사를 인수한 뒤 AI를 조직 내부에 심어 반복 업무를 자동화하는 모델이다. 소프트웨어를 고객에게 팔 때보다 데이터, 프로세스, 교육, 가격 체계를 통째로 바꾸기 쉽다는 논리다. 실제로 2026년에는 AI 도입을 중심으로 기업가치를 높이려는 사모펀드 사례가 나타났고, AI 중심 법률사무소도 늘고 있다.

다만 원문의 ‘영업이익률 10%대가 50~70%로 폭발한다’는 수치는 검증된 산업 일반치가 아니다. 인수 비용, 규제, 오류 책임, 고객 확보 비용, 모델 사용료를 고려하면 수익성은 기업마다 크게 달라진다. AI로 비용을 줄이는 회사와 고객에게 더 많은 가치를 제공하는 회사도 구분해서 보아야 한다.

셋째, 개인도 ‘1인 AI 롤업 기업’처럼 일할 수 있다. 대단한 회사 인수가 필요한 것은 아니다. 자기 업무를 작은 파이프라인으로 재구성하면 된다.

목표 설정 → 원본과 권한 준비 → 샘플 승인 → AI 실행 → 자동 검증 → 사람의 핵심 검토 → 최종 승인.

여기서 사람은 할 일을 포기하지 않는다. 반복 작업에서 손을 떼고, 어디서 실수가 나면 치명적인지 판단하는 데 시간을 쓰는 것이다. 처음부터 마지막까지 모든 키보드를 직접 두드리는 사람이 아니라, 일이 끝나는 구조를 만드는 사람이 되는 것. AI 시대에 ‘혼자서 여러 사람 몫’에 가까워지는 방법은 아마 여기에 있을 것이다.

앞으로 무엇을 점검할까

• 완료까지 걸린 시간 : 첫 지시부터 실제 승인까지의 시간을 비교한다. AI의 초안 생성 속도만 재면 효과가 과장된다.
• 재작업률 : 제출 후 인간이 다시 수정한 건수와 시간을 센다. 속도가 빨라져도 재작업이 늘면 효율이 떨어진다.
• 근거 확인률 : 중요한 숫자와 인용이 원자료에 연결되는지 확인한다.
• 예외 처리율 : 모르는 것을 모른다고 보고하고 위험한 작업에서 멈추는지 본다.
• 실제 비용 : 구독료와 API 사용료, 검수 인건비, 오류 수정 비용까지 함께 계산한다.

FAQ

Q. AI가 작성한 글을 사람이 직접 고치면 안 되나요?

• 고쳐도 된다. 다만 고친 결과를 AI가 다시 사용할 때 변경된 버전이 무엇인지 명확히 전달해야 한다.
• 협업 파일이나 코드는 동시 편집과 버전 충돌을 특히 주의한다.

Q. 다른 AI에 검수시키면 팩트체크가 끝난 건가요?

• 아니다. 서로 다른 모델도 동일한 잘못된 출처를 인용할 수 있다.
• 큰 숫자, 법률, 투자 판단, 공개 발언은 원출처를 별도로 확인한다.

Q. 바이브 코딩에서는 테스트만 통과하면 배포해도 되나요?

• 아니다. 테스트의 품질, 사용자 흐름, 개인정보와 보안, 실제 운영 환경을 추가로 점검해야 한다.
• 배포와 데이터 삭제처럼 되돌리기 어려운 행동은 승인 단계를 둔다.

Q. 그럼 사람은 처음과 마지막에만 개입하면 되나요?

• 위험이 낮은 일괄 정리 업무에는 가능할 수 있다.
• 복잡한 회계 판단, 외부 발송, 자금 이동, 민감정보 처리에는 중간 승인과 전문가 검토가 필요하다.

Q. ‘1인 AI 기업’이 되면 실제로 100명 몫을 할 수 있나요?

• 100배 생산성은 보편적으로 입증된 수치가 아니라 비유에 가깝다.
• 자신이 반복하는 업무 한 개를 골라 시간, 오류, 비용을 전후 비교하는 것이 출발점이다.