무게중심이 ‘프롬프트’에서 ‘감독·검수’로 넘어갔다
2026년 들어 업무용 AI 논의의 성격이 분명히 바뀌었다. 2023~2024년만 해도 화두는 “프롬프트를 어떻게 잘 쓰느냐”였다. 지금은 AI가 리서치→초안→코드→검증까지 여러 단계를 스스로 이어 붙이고, 사람은 그 사슬의 결과를 검수·승인하는 쪽으로 축이 이동했다. Claude Fable 5 같은 새 모델 세대를 두고 ‘지시하는 시대에서 감독하는 시대로’라는 표현이 나오는 이유다. 핵심은 인터페이스의 변화가 아니라 ‘사람이 개입하는 지점’이 입력단(명령)에서 출력단(검토)으로 옮겨갔다는 데 있다.
이 이동은 곧 직무 역량의 재정의로 이어진다. 프롬프트 문장력이 아니라, AI가 그럴듯하게 써낸 결과에서 사실 오류·논리 비약·환각을 골라내는 판별력이 경쟁력이 된다. 지금 점검할 것은 세 가지다. (1) AI에 열어줄 작업 범위와 권한을 어디까지로 잠갔는가 — 읽기만 허용인지, 파일 수정·외부 전송까지 허용인지. (2) 결과를 누가·어떤 기준으로 검수하는지 절차가 문서화돼 있는가. (3) 잘못된 산출물이 나갔을 때 되돌리는 롤백·책임 경로가 있는가. 흔한 오해는 ‘감독 시대=사람이 편해진다’는 기대다. 실제로는 검토·판단이라는 새 노동이 얹히므로, AI를 많이 쓰는 팀일수록 리뷰 병목이 새 성과 제약이 된다.
프롬프트는 ‘맥락·하네스·루프’ 세 축으로 확장된다
단발성 한 문장으로 원하는 결과를 뽑던 시기는 지났다. 실무에서 프롬프트는 세 축으로 벌어진다. 첫째 맥락(context)은 배경·규칙·자료를 함께 주는 것이고, 둘째 하네스(harness)는 AI가 도구를 호출하고 여러 단계를 실행하도록 감싸는 실행 구조이며, 셋째 루프(loop)는 결과를 스스로 검증하고 반복 개선하는 순환이다. ‘한 문장 잘 쓰기’에서 ‘작업 환경 전체를 설계하기’로 초점이 옮겨간 셈이다.
왜 중요한가. 업무가 복잡할수록 단일 지시의 재현성이 급격히 떨어지기 때문이다. 같은 프롬프트로 열 번 돌리면 결과가 제각각인 작업일수록, 맥락으로 회사 양식·용어를 고정하고 하네스로 데이터 조회·표 생성 단계를 연결하고 루프로 초안을 자체 점검하게 묶어야 품질이 안정된다. 체크포인트는 이렇다. ①두 번 이상 반복되는 작업이면 프롬프트 한 줄이 아니라 절차·규칙을 파일로 고정하라. ②AI가 외부 도구를 호출한다면 허용 범위를 화이트리스트로 명시하라. ③자동 루프에는 반드시 ‘최대 반복 횟수’와 ‘사람 검수 지점’을 함께 넣어라. 대표적 함정은 루프를 종료 조건 없이 돌리는 것으로, 이 경우 오류와 연산 비용이 동시에 누적되며 ‘스스로 고친다’는 기대와 정반대의 결과를 낳는다.
설정 파일 한 줄이 결과를 망친다: CLAUDE.md의 교훈
맥락을 고정하는 대표 수단이 프로젝트 설정 파일이다. Claude의 CLAUDE.md처럼 AI에 항상 적용할 규칙을 적어두는 파일이 여기 해당한다. 역설적이게도 이 파일이 잘못 쓰이면 성능을 끌어올리기는커녕 떨어뜨린다는 지적이 이어진다. 현장에서 반복 지목되는 실패 유형은 네 가지로 압축된다. ①지시가 장황해 핵심 규칙이 잡음에 묻히는 경우, ②”간결하게 써라”와 “모든 근거를 상세히 달라”처럼 서로 충돌하는 규칙이 공존하는 경우, ③실제로는 지켜지지 않는데 심리적 안심용으로 쌓아두는 규칙, ④도구·구조가 바뀌었는데 옛 규칙을 방치한 경우다. 결론은 ‘규칙은 많을수록 좋다’가 명백히 틀렸다는 것이다.
적용은 오히려 단순하다. ①정말 매번 지켜야 할 규칙만 남기고, 한 항목이 한 화면을 넘기면 쪼개거나 지운다. ②분기마다 모순·중복 규칙을 솎아내는 점검을 일정에 넣는다. ③규칙마다 ‘왜 필요한지’ 한 줄을 붙여, 나중에 남이 봐도 삭제 가능 여부를 판단하게 한다. ④폴더 구조나 빌드 도구가 바뀌면 설정도 같은 커밋에서 갱신한다. 초보자가 가장 자주 하는 오해는 ‘한 번 잘 써두면 끝’이라는 생각이다. 설정 파일은 코드처럼 낡는 자산이라, 방치되는 순간 눈에 보이지 않는 품질 저하의 원인이 된다. ‘지시가 무시됐다’며 모델을 탓하기 전에, 그 지시가 다른 규칙과 충돌하거나 이미 유효기간이 지난 건 아닌지부터 봐야 한다.
‘무제한 AI’의 종료와 비용 설계의 부상
운영 관점에서 가장 체감되는 변화는 비용이다. 앤트로픽이 클로드 에이전트의 과금 방식을 조정하면서 ‘사실상 무제한처럼 쓰던’ 시기가 저물고 있다는 분석이 나온다. AI가 여러 단계를 자동으로 잇는 에이전트 방식은 편의만큼 내부 연산을 많이 소모하는데, 한 번의 요청이 실제로는 수십 번의 모델 호출로 풀리기 때문이다. 그 부담이 요금 구조에 반영되기 시작했다는 것은, 개인·팀에게 ‘쓰는 만큼 청구되는’ 전제 위에서 워크플로를 다시 짜라는 신호다.
비용 관리의 출발점은 ‘자동화의 편의’와 ‘연산 소모’가 대체로 비례한다는 사실을 인정하는 것이다. 체크포인트는 이렇다. ①작업을 ‘사람이 할 일 / AI에 맡길 일’로 나누되 기준을 감이 아니라 반복 빈도·오류 허용도·건당 예상 비용으로 삼는다. ②반복 루프와 대량 자동화에는 최대 반복 횟수, 월 사용량 알림 같은 상한을 반드시 건다. ③작업을 계층화해 초안·분류처럼 값싼 단계는 경량 모델(예: Haiku급)에, 최종 판단·복잡한 추론만 고성능 모델에 배분한다. 함정은 ‘자동화하면 무조건 이득’이라는 가정이다. 통제되지 않은 자동 반복은 한밤중에 수백 회 재시도를 돌려 예상 밖 청구서를 만들 수 있어, 사전 상한 설정은 선택이 아니라 기본 옵션이 됐다.
기업 도입은 이미 진행형: 삼성전자 멀티모델이 시사하는 것
이 변화들은 이론이 아니라 대기업 현장에서 이미 굴러가고 있다. 삼성전자가 제미나이(Gemini)·클로드(Claude) 등 외부 AI를 업무에 활용하며 혁신 속도를 낸다는 소식은, 도입 방향이 ‘한 벤더로 통일’이 아니라 ‘작업 성격에 따라 모델을 골라 쓰는’ 멀티모델 전략으로 가고 있음을 보여준다. 코드에는 이 모델, 문서 요약에는 저 모델 식으로 강점에 맞춰 배치하고, 동시에 특정 공급사 정책 변화에 통째로 흔들리지 않도록 위험을 분산하는 것이다.
다만 외부 AI 활용에는 함께 봐야 할 리스크가 세 가지다. 첫째 보안·데이터 — 사내 기밀·개인정보가 외부 모델 입력창에 들어가지 않도록 ‘넣어도 되는 데이터’의 경계를 먼저 긋는다. 둘째 품질·책임 — AI 결과를 그대로 반출하지 않고, 누가 최종 서명하는지 책임자를 지정한다. 셋째 종속성 — 한 모델의 요금·정책이 바뀌어도 업무가 멈추지 않도록 대체 경로를 준비한다. 그래서 도입을 검토하는 조직의 올바른 순서는 ‘무엇을 자동화할까’가 아니라 ‘어떤 데이터까지 넣어도 되는가, 결과는 누가 책임지는가’를 먼저 정하는 것이다. 6개월~2년 관점에서 승부를 가르는 변수는 화려한 기능 도입이 아니라, 맥락 설계·검수 체계·비용 통제라는 지루하지만 결정적인 운영 역량일 가능성이 크다.
자주 묻는 질문
CLAUDE.md 같은 AI 설정 파일은 규칙을 많이 적을수록 좋은가요?
아닙니다. 지시가 장황하거나, 서로 충돌하거나(‘간결하게’와 ‘상세히’의 공존), 실제로 안 지켜지는 규칙이 쌓이거나, 구조가 바뀌었는데 옛 규칙이 남으면 오히려 성능을 떨어뜨립니다. 매번 지켜야 할 규칙만 남기고, 각 규칙에 ‘왜 필요한지’를 붙이며, 도구·폴더 구조가 바뀌면 같은 커밋에서 갱신하는 유지보수가 핵심입니다. ‘한 번 잘 써두면 끝’이 가장 흔한 오해입니다.
‘AI를 감독하는 시대’라는 말은 사람이 더 편해진다는 뜻인가요?
오히려 반대에 가깝습니다. AI가 여러 단계를 스스로 잇는 만큼, 사람에게는 사실 오류·논리 비약·환각을 걸러내는 검수·판단이라는 새 노동이 얹힙니다. AI를 많이 쓰는 팀일수록 ‘리뷰 병목’이 새로운 성과 제약이 되므로, 작업 범위·권한을 미리 잠그고 검수 담당자·절차·롤백 경로를 갖추는 것이 실무 역량이 됩니다.
클로드 에이전트 과금 전환이 개인·팀에 실제로 어떤 영향을 주나요?
에이전트 방식은 한 번의 요청이 내부적으로 수십 번의 모델 호출로 풀려 연산을 많이 소모하고, 이 부담이 요금에 반영되는 흐름입니다. ‘쓰는 만큼 청구된다’를 전제로, 자동 반복에 최대 횟수·사용량 알림 같은 상한을 걸고, 값싼 단계는 경량 모델에 최종 판단만 고성능 모델에 배분하는 계층화가 필요합니다. 상한이 없으면 야간 재시도 폭주 같은 예상 밖 청구가 생길 수 있습니다.
기업이 외부 AI를 도입할 때 가장 먼저 봐야 할 것은 무엇인가요?
기능이 아니라 세 가지 리스크입니다. ①어떤 데이터까지 외부 모델에 넣어도 되는지 경계 설정, ②AI 결과를 검수할 절차와 최종 책임자 지정, ③한 모델의 요금·정책이 바뀌어도 업무가 멈추지 않게 할 대체 경로입니다. 삼성전자처럼 작업 성격에 따라 여러 모델을 병행하는 멀티모델 전략은 특정 공급사 종속성을 낮추는 대표적 방법입니다.