지난 이야기, 그리고 오늘의 질문
지난 2화에서 ‘휴먼 인 더 루프’라는 개념이 단순히 사람이 끼어드는 것이 아니라, 사람의 판단이 시스템을 더 똑똑하게 만드는 순환 구조라는 이야기를 했습니다. 오늘은 그 개념이 실제 현장에서 어떻게 갈리는지, 제가 직접 목격한 풍경을 펼쳐보겠습니다.
금융IT 현장에서 20년을 버티다 보면 다양한 팀을 만납니다. 같은 도구를 쓰고, 같은 예산을 받고, 심지어 같은 벤더의 솔루션을 도입했는데도 결과가 극명하게 갈리는 경우를 숱하게 봤습니다. AI 도입 이후에는 그 격차가 더 빠르게, 더 크게 벌어지고 있습니다.
그래서 오늘의 질문은 이겁니다.
“같은 AI를 줬는데 왜 어떤 팀은 날아가고, 어떤 팀은 주저앉는가?”
결론부터 말씀드리면, 결정적 차이는 피드백 루프(Feedback Loop)의 존재 여부였습니다. 기술력도, 예산도, 인원수도 아닙니다. AI의 출력물을 받아서 어떻게 되돌려주느냐, 그 순환이 있느냐 없느냐가 전부였습니다.
두 팀의 이야기: 같은 도구, 정반대의 결과
A팀 — “AI가 해주니까 편하네”
몇 해 전, 한 금융사의 고객 응대 부서에서 AI 기반 자동 응답 시스템을 도입했습니다. 도입 초기 성과는 화려했습니다. 응답 시간이 절반으로 줄었고, 단순 문의 처리율이 80%를 넘겼습니다. 경영진은 만족했고, 팀원들도 “이제 좀 쉬겠다”며 안도했습니다.
그런데 3개월쯤 지나자 이상한 일이 벌어졌습니다.
- 고객 불만이 오히려 도입 전보다 15% 증가했습니다
- AI가 잘못 안내한 건을 사람이 뒤늦게 수습하는 패턴이 반복됐습니다
- “AI가 이렇게 답했는데요”라며 항의하는 고객이 늘었습니다
- 팀원들은 AI 출력을 거의 검토하지 않고 그대로 내보내고 있었습니다
무슨 일이 벌어진 걸까요? A팀은 AI를 ‘자판기’처럼 사용하고 있었습니다. 입력을 넣으면 출력이 나오고, 그걸 그대로 고객에게 전달했습니다. AI가 틀려도 “원래 AI가 그렇지” 하며 넘어갔습니다. AI의 실수에서 아무것도 배우지 않았고, AI도 아무것도 개선되지 않았습니다.
B팀 — “AI가 틀린 부분, 기록해 둘게”
비슷한 시기에 다른 금융사의 유사한 부서에서도 거의 동일한 솔루션을 도입했습니다. 기술 스택도 비슷했고, 팀 규모도 엇비슷했습니다.
차이는 딱 하나였습니다. B팀에는 “AI 출력 리뷰 시트”라는 게 있었습니다.
거창한 게 아닙니다. 스프레드시트 하나였습니다. AI가 내놓은 답변 중에서 사람이 수정한 건을 기록하는 용도였습니다. 매주 금요일 오후, 30분짜리 미팅에서 그 시트를 훑어보며 세 가지를 확인했습니다.
- 이번 주에 AI가 자주 틀린 유형은 무엇인가?
- 그중 프롬프트나 설정을 바꿔서 고칠 수 있는 건 무엇인가?
- 사람이 직접 처리해야 할 영역으로 분류할 건 무엇인가?
6개월 후 결과는 놀라웠습니다. B팀의 AI 정확도는 도입 초기 대비 34% 향상됐습니다. 고객 만족도는 도입 전보다 높아졌고, 팀원들의 업무 만족도도 올라갔습니다. 같은 도구, 같은 예산, 같은 기간인데 말입니다.
피드백 루프란 정확히 무엇인가
피드백 루프라는 말이 거창하게 들릴 수 있지만, 본질은 단순합니다.
AI가 출력을 내놓으면 → 사람이 검토하고 → 수정 사항을 다시 AI에게 반영하는 순환 구조.
이걸 좀 더 구체적으로 풀어보겠습니다.
1단계: AI 출력 (Generation)
AI가 어떤 작업을 수행하고 결과물을 내놓습니다. 텍스트 생성이든, 데이터 분류든, 코드 작성이든 상관없습니다. 이 단계에서 AI는 자기가 가진 학습 데이터와 맥락을 바탕으로 최선의 추측을 합니다. 핵심은 ‘추측’이라는 점입니다. 아무리 뛰어난 AI라도 출력은 확률적 추정이지, 확정된 정답이 아닙니다.
2단계: 사람의 검토 (Evaluation)
사람이 AI의 출력물을 살펴봅니다. 여기서 “살펴본다”는 말의 무게가 중요합니다. 그냥 눈으로 흘겨보는 게 아니라, 맞는지 틀린지, 틀렸다면 왜 틀렸는지, 어떻게 고쳐야 하는지를 판단하는 과정입니다.
이 단계에서 사람의 도메인 전문성이 빛을 발합니다. AI는 “이 대출 상품의 중도상환수수료가 없습니다”라고 답할 수 있지만, 금융 현장을 아는 사람은 “3년 이내 상환 시에는 수수료가 있다”는 예외를 압니다. 이런 판단은 데이터에 명시적으로 기록되지 않은 경우가 많아서, AI가 스스로 학습하기 어렵습니다.
3단계: 수정 반영 (Correction & Integration)
사람이 수정한 내용을 시스템에 되돌려줍니다. 이 방법은 다양합니다.
- 프롬프트를 수정해서 AI가 같은 실수를 반복하지 않게 만들기
- 참조 데이터베이스를 업데이트해서 AI의 검색 범위를 교정하기
- 특정 유형의 질문은 AI 대신 사람에게 라우팅하는 규칙 추가하기
- AI 출력에 후처리 필터를 달아서 특정 패턴의 오류를 자동 차단하기
이 세 단계가 끊김 없이 반복되는 것, 그것이 피드백 루프입니다. 한 번 돌 때마다 AI 시스템 전체가 조금씩 나아집니다. 이걸 멈추면 AI는 도입 첫날의 성능에서 영원히 정체됩니다.
피드백 루프가 없는 팀에서 벌어지는 일
피드백 루프가 없다는 건, 2단계와 3단계가 빠져 있다는 뜻입니다. AI가 출력을 내놓으면 그대로 쓰거나, 사람이 수정은 하되 그 수정 내역이 시스템에 반영되지 않는 상태입니다.
이런 팀에서 시간이 지나면 예외 없이 나타나는 증상들이 있습니다.
증상 1: “AI 불신” 확산
AI가 틀리는 건 자연스러운 일입니다. 문제는 같은 유형의 실수가 계속 반복될 때입니다. “지난달에도 이거 틀렸잖아, 아직도 못 고쳤어?” 이런 말이 팀 내에서 나오기 시작하면, AI에 대한 신뢰가 빠르게 무너집니다.
신뢰가 무너지면 두 가지 중 하나가 벌어집니다. AI를 아예 안 쓰거나, 쓰면서도 결과를 전부 처음부터 다시 만듭니다. 어느 쪽이든 AI 도입 비용은 매몰됩니다.
증상 2: “수동 보정의 늪”
AI 출력을 매번 사람이 고치는데, 그 수정 사항이 시스템에 반영되지 않으면 어떻게 될까요? 다음 번에도 같은 걸 고쳐야 합니다. 그다음에도. 그다다음에도.
제가 실제로 본 사례입니다. 한 팀에서 AI가 생성한 보고서 초안을 매주 사람이 수정하고 있었는데, 같은 항목의 같은 오류를 6개월 동안 매주 고치고 있었습니다. 프롬프트 한 줄만 바꾸면 해결될 문제를 말입니다.
1화에서 “AI 도입했더니 더 바빠졌다”고 했던 이야기, 기억나시죠? 그 바쁨의 상당 부분이 바로 이 수동 보정의 늪에서 비롯됩니다.
증상 3: “책임 공백”
“AI가 그렇게 했는데요?”
이 말이 팀 내에서 자연스럽게 통용되기 시작하면 위험 신호입니다. AI의 출력에 대한 책임이 사람에게도, AI에게도 없는 공백 상태가 됩니다. 금융 분야에서 이 공백은 곧 사고로 이어집니다. 잘못된 금리 안내, 부정확한 세금 계산, 엉뚱한 상품 추천 — 전부 실제로 일어난 일들입니다.
잘 돌아가는 피드백 루프의 실제 모습
그렇다면 피드백 루프를 잘 운영하는 팀은 구체적으로 무엇이 다를까요? 제가 여러 팀을 관찰하면서 정리한 공통 패턴 다섯 가지를 공유합니다.
패턴 1: 수정 기록을 남긴다
앞서 B팀의 “AI 출력 리뷰 시트”를 언급했습니다. 이것의 핵심은 수정 사실 자체를 데이터로 만드는 것입니다.
기록할 내용은 간단합니다.
- AI가 뭘 출력했는가
- 사람이 어떻게 고쳤는가
- 왜 고쳤는가 (한 줄이면 충분)
이 세 가지를 기록하는 것만으로 엄청난 변화가 일어납니다. 왜냐하면 패턴이 보이기 시작하니까요. “아, AI가 유독 이 유형에서 자꾸 틀리는구나” — 이 발견이 개선의 시작점입니다.
도구는 상관없습니다. 스프레드시트도 좋고, 노션이도 좋고, 심지어 종이 노트도 됩니다. 중요한 건 기록하는 행위 자체입니다.
패턴 2: 주기적으로 리뷰한다
기록만 하고 안 보면 소용없습니다. 잘하는 팀은 정해진 주기로 수정 기록을 리뷰합니다.
주간 리뷰가 가장 흔한 패턴입니다. 30분이면 충분합니다. 이 리뷰에서 하는 일은 딱 두 가지입니다.
- 분류: 이번 주 수정 건을 유형별로 묶는다
- 조치 결정: 각 유형에 대해 “프롬프트 수정 / 데이터 보강 / 사람 처리 전환 / 현행 유지” 중 하나를 정한다
중요한 건 모든 수정을 반영하려 들지 않는 것입니다. 빈도가 높고, 고치기 쉽고, 영향이 큰 것부터 하나씩 해결합니다. 주당 1~2건만 개선해도 한 달이면 체감이 됩니다.
패턴 3: 프롬프트를 버전 관리한다
AI를 잘 쓰는 팀에서 가장 인상적이었던 점은, 프롬프트를 코드처럼 관리한다는 것이었습니다.
프롬프트를 바꿀 때마다 날짜와 변경 이유를 기록합니다. “v2.3: 중도상환수수료 예외 조건 명시 — 5월 2주차 리뷰 반영”처럼 말입니다. 이렇게 하면 두 가지가 가능해집니다.
- 변경 후 성능이 나빠지면 이전 버전으로 즉시 롤백할 수 있습니다
- 어떤 변경이 어떤 개선을 가져왔는지 인과관계를 추적할 수 있습니다
프롬프트 엔지니어링이라는 거창한 말을 쓸 필요도 없습니다. 그냥 “뭘 바꿨고, 왜 바꿨고, 결과가 어땠는지” 적는 겁니다.
패턴 4: AI의 한계를 명시적으로 정의한다
잘 돌아가는 팀은 AI가 무엇을 못하는지를 아주 구체적으로 알고 있습니다. “AI는 완벽하지 않다”는 막연한 인식이 아니라, “우리 AI는 이러이러한 유형의 질문에서 정확도가 60% 미만이다”는 수준의 구체적 지식입니다.
이 지식이 있으면 두 가지를 할 수 있습니다.
- 해당 유형의 질문이 들어오면 자동으로 사람에게 라우팅합니다
- AI가 대신 처리하더라도 반드시 사람의 검증을 거치는 프로세스를 만듭니다
이것이 2화에서 이야기한 ‘휴먼 인 더 루프’의 실전 적용입니다. AI의 한계 지점에 사람을 배치하는 것. 그리고 그 한계 지점은 피드백 루프를 통해서만 정확히 파악할 수 있습니다.
패턴 5: 개선 성과를 측정하고 공유한다
피드백 루프가 돌면서 AI가 나아지고 있다는 걸 숫자로 보여주는 것, 이게 루프를 지속시키는 연료입니다.
“지난달 대비 AI 수정 건수가 23% 줄었습니다.”
“이번 주 프롬프트 개선 후 특정 유형 정확도가 72%에서 89%로 올랐습니다.”
이런 숫자가 팀 내에서 공유되면, 수정 기록을 남기고 리뷰에 참여하는 행위에 의미가 부여됩니다. “내가 기록한 수정 사항이 실제로 AI를 개선시켰구나.” 이 성취감이 루프를 지속시킵니다.
반대로, 아무리 열심히 기록하고 리뷰해도 개선이 안 된다면? 그건 루프 자체를 점검할 때입니다. 기록이 부정확한 건지, 조치가 엉뚱한 건지, 아니면 해당 영역은 AI보다 사람이 하는 게 맞는 건지 다시 따져봐야 합니다.
챗봇 8년 차의 고백: 나도 처음엔 몰랐다
여기서 개인적인 이야기를 조금 하겠습니다.
저는 챗봇 운영을 8년째 하고 있습니다. 처음 챗봇을 도입했을 때, 저도 A팀과 똑같았습니다. 챗봇이 답변을 잘못 내놓으면 시나리오를 고치고, 또 잘못 내놓으면 또 고치고. 그때그때 땜질하는 식이었습니다.
전환점은 수정 로그를 분석하기 시작한 순간이었습니다. 3개월치 수정 기록을 모아서 살펴봤더니, 전체 오류의 60%가 단 세 가지 패턴에서 나오고 있었습니다. 세 가지. 수백 건의 수정을 했지만 근본 원인은 겨우 세 개였던 겁니다.
그 세 가지를 집중적으로 해결했더니, 수정 빈도가 반 토막났습니다. 남는 시간에 더 복잡한 시나리오를 개선할 수 있게 됐고, 챗봇의 전체적인 품질이 눈에 띄게 올라갔습니다.
이때 깨달았습니다. AI를 잘 쓴다는 건, AI를 잘 만든다는 게 아니라 AI를 잘 관찰한다는 것이구나. 그리고 그 관찰을 시스템적으로 반복할 수 있게 만드는 것, 그게 피드백 루프구나.
피드백 루프를 시작하는 가장 쉬운 방법
“그래서 우리 팀은 뭐부터 하면 되나요?”
이 질문을 정말 많이 받습니다. 대답은 늘 같습니다.
오늘부터 AI가 틀린 걸 적으세요.
그게 전부입니다. 처음부터 거창한 시스템을 만들 필요 없습니다. 메모장에 적어도 됩니다. 핵심은 “AI 출력 → 사람 검토 → 기록”이라는 최소한의 루프를 돌리기 시작하는 것입니다.
제가 추천하는 4주 로드맵을 공유합니다.
1주차: 기록만 한다
AI를 쓸 때마다 수정한 내용을 메모합니다. 형식 없이, 부담 없이. “AI가 A라고 했는데 B로 고침” 정도면 충분합니다. 이 주의 목표는 기록하는 습관을 만드는 것입니다.
2주차: 분류한다
1주차에 모은 기록을 훑어봅니다. 비슷한 유형끼리 묶어봅니다. “사실 오류”, “톤 불일치”, “맥락 누락”, “포맷 문제” 등 자기 팀에 맞는 분류를 만들면 됩니다. 이 주의 목표는 패턴을 발견하는 것입니다.
3주차: 하나만 고친다
가장 빈도가 높은 유형 하나를 골라서 대응합니다. 프롬프트를 수정하든, 참조 자료를 추가하든, 해당 유형만 사람이 처리하도록 바꾸든 방법은 자유입니다. 이 주의 목표는 루프를 한 바퀴 완성하는 것입니다.
4주차: 효과를 확인한다
3주차의 조치가 효과가 있었는지 수정 기록으로 확인합니다. 해당 유형의 수정 빈도가 줄었으면 성공입니다. 안 줄었으면 조치를 수정합니다. 이 주의 목표는 루프의 효과를 체감하는 것입니다.
이 4주가 지나면, 팀은 스스로 루프를 돌릴 수 있는 근육이 생깁니다. 이후부터는 주기를 정하고, 도구를 고도화하고, 범위를 넓혀가면 됩니다.
흔한 반론, 그리고 현실적인 답
“그거 할 시간이 없어요”
가장 많이 듣는 말입니다. 그리고 가장 아이러니한 말이기도 합니다.
피드백 루프가 없어서 AI가 같은 실수를 반복하고, 그걸 매번 사람이 수동으로 고치느라 바쁜 건데, “바빠서 피드백 루프를 못 만든다”고 하는 겁니다. 피드백 루프를 안 돌리기 때문에 바쁜 것입니다.
처음에 하루 10분만 투자해 보세요. AI가 틀린 거 적는 데 10분이면 됩니다. 그 10분이 한 달 후에는 매일 30분의 수동 보정 시간을 아껴줄 겁니다.
“우리 팀에는 AI 전문가가 없어요”
피드백 루프를 돌리는 데 AI 전문가는 필요 없습니다. 필요한 건 도메인 전문가입니다. 자기 업무를 잘 아는 사람이면 됩니다.
AI가 대출 상담 답변을 잘못 내놓았을 때, 그게 왜 잘못인지 판단할 수 있는 사람은 AI 전문가가 아니라 대출 상담을 해본 사람입니다. 프롬프트를 수정하는 것도 “이런 경우에는 이렇게 답해야 해”라는 업무 지식을 문장으로 옮기는 것일 뿐, 코딩이 아닙니다.
“경영진이 관심이 없어요”
4주 로드맵을 조용히 실행한 뒤, 숫자를 보여주세요. “AI 수정 건수가 4주 만에 30% 줄었습니다. 주당 절감 시간은 약 N시간입니다.” 이 숫자 앞에서 관심 없는 경영진은 없습니다.
허락을 구하지 말고, 결과를 보여주세요. 피드백 루프의 좋은 점은 시작하는 데 허가가 필요 없다는 겁니다. 메모장 하나면 충분하니까요.
피드백 루프의 진짜 가치: AI가 아니라 팀이 성장한다
여기까지 읽으셨다면 한 가지 의문이 드실 수 있습니다.
“결국 피드백 루프는 AI를 개선하기 위한 거잖아. AI가 충분히 똑똑해지면 필요 없어지는 거 아닌가?”
이건 정말 좋은 질문인데, 제 대답은 “아니오”입니다.
피드백 루프를 통해 진짜로 성장하는 건 AI가 아니라 팀입니다.
수정 기록을 남기면서 팀원들은 자신의 업무 기준을 명확히 하게 됩니다. “이건 왜 틀린 거지?” 라는 질문에 답하려면, 무엇이 맞는지를 먼저 정의해야 하니까요. 이 과정에서 그동안 암묵적으로만 존재했던 업무 규칙과 판단 기준이 명시적으로 문서화됩니다.
리뷰를 하면서 팀원들은 서로의 판단 기준을 맞춰갑니다. “나는 이걸 오류로 봤는데, 너는 괜찮다고 봤네?” 이런 대화가 자연스럽게 일어나고, 팀 차원의 품질 기준이 통일됩니다.
프롬프트를 개선하면서 팀원들은 자기 업무를 구조화하는 능력이 올라갑니다. AI에게 일을 잘 시키려면 일 자체를 잘 정의해야 하니까요. 이 능력은 AI가 없어져도 유효한, 본질적인 직무 역량입니다.
결국 피드백 루프는 “AI를 통해 팀이 자기 일을 더 깊이 이해하는 과정”입니다. AI는 거울이고, 피드백 루프는 그 거울을 제대로 들여다보는 행위입니다.
마무리: 단 하나의 차이
오늘 이야기를 요약하겠습니다.
AI를 잘 쓰는 팀과 못 쓰는 팀의 결정적 차이는 피드백 루프의 유무입니다.
- AI 출력을 그대로 쓰는 팀은 정체합니다
- AI 출력을 고치기만 하고 기록하지 않는 팀은 소모됩니다
- AI 출력을 고치고, 기록하고, 반영하는 팀은 성장합니다
기술력의 차이가 아닙니다. 예산의 차이가 아닙니다. 인원수의 차이가 아닙니다. “AI의 실수에서 배우는가?” 이 한 가지 질문에 대한 답이 모든 걸 갈랐습니다.
다음 4화에서는 이 피드백 루프의 2단계, 즉 사람의 검토 부분을 깊이 파고듭니다. AI 출력을 볼 때 무엇을 봐야 하고, 무엇을 놓치기 쉬운지 — “AI 결과물, 어디를 먼저 봐야 할까”라는 주제로 찾아뵙겠습니다. 검토의 기술이 곧 피드백 루프의 품질을 결정하니까요.
🗒️ 이번 주 한 줄 노트
“AI를 잘 쓴다는 건 AI를 잘 관찰한다는 것이다. 관찰을 시스템으로 만드는 순간, 팀 전체가 달라진다.”
※ 이 글은 특정 기업이나 조직의 입장이 아닌, 필자 개인의 경험과 견해를 바탕으로 작성되었습니다. 모든 사례는 익명 처리 및 일반화되었습니다.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.
◀ 이전 2화 (다음 차수는 아직 게시되지 않았습니다)