12부 68장. 실패 사례를 모아 시스템을 고치는 법

AI를 쓰다 보면 이상한 순간을 자주 만난다. 분명 같은 방식으로 시켰는데 어제는 잘되던 일이 오늘은 어긋난다. 보고서 요약은 멀쩡했는데 숫자를 하나 바꾸자 논리가 흔들리고, 코드 생성은 빨랐는데 테스트 단계에서 무너진다. 많은 사람은 이때 그 한 건만 급히 고친다. 프롬프트를 조금 바꾸고, 문장을 하나 덧붙이고, 다시 실행해서 통과하면 끝낸다.

문제는 그 방식으로는 시스템이 거의 나아지지 않는다는 점이다. 오늘 만난 실패가 내일 다른 모습으로 다시 돌아오기 때문이다. 잘 되는 AI 시스템은 성공 사례만 많이 가진 시스템이 아니다. 실패 사례를 모으고, 분류하고, 다시는 같은 구멍에 빠지지 않도록 구조를 바꾸는 시스템이다.

이번 장의 핵심은 간단하다. 실패를 사고 보고서처럼 다루라는 것이다. 한 번 불편했던 일을 그냥 넘기지 말고, 기록하고, 패턴으로 묶고, 수정하고, 다시 검증하라. 그러면 실패는 비용이 아니라 자산이 된다.

실패는 고장이 아니라 신호다

실패를 보는 관점을 먼저 바꿔야 한다. 많은 사람은 실패를 "AI가 멍청하다"로 정리한다. 하지만 실전에서는 그 말이 거의 도움이 되지 않는다. 왜 틀렸는지, 어떤 조건에서 틀렸는지, 사람의 개입이 어디서 늦었는지, 평가 기준이 없었는지 같은 질문으로 내려가야 한다.

예를 들어 AI가 회의록을 정리했는데 중요한 결정 사항을 빠뜨렸다고 해보자. 이때 원인은 하나가 아닐 수 있다. 원본 대화가 너무 길었을 수도 있고, 결정 사항을 표시하는 규칙이 없었을 수도 있고, 출력 형식에 "결정/미정/담당자/기한" 같은 칸이 없었을 수도 있다. 같은 실패처럼 보여도 실제 원인은 컨텍스트 부족, 지시 부족, 형식 부족, 검수 부재로 각각 다를 수 있다.

즉 실패는 단순한 결과가 아니라 구조를 보여 주는 신호다. 이 신호를 모으면, 어디를 고쳐야 전체 성능이 오르는지 보이기 시작한다.

한 건을 고치는 것과 시스템을 고치는 것은 다르다

실무에서 가장 흔한 함정은 "이번 것만 해결"하는 태도다. 당장 급하니 그렇게 할 수밖에 없을 때도 있다. 하지만 늘 그 방식만 쓰면 팀과 개인의 AI 사용 능력은 쌓이지 않는다.

한 건을 고치는 방식은 이런 흐름이다. 실패한다. 문장을 조금 바꾼다. 다시 돌린다. 통과한다. 끝낸다. 이 방식은 빠르지만 기억이 남지 않는다.

시스템을 고치는 방식은 다르다. 실패한다. 실패 조건을 기록한다. 원인을 가설로 세운다. 재발 방지 장치를 만든다. 같은 종류의 작업 전체에 적용한다. 다음에 비슷한 문제가 왔을 때 자동으로 더 잘 처리된다.

둘의 차이는 아주 크다. 전자는 소모전이고, 후자는 자산 축적이다.

실패 사례는 어떻게 기록해야 하는가

실패 기록은 길고 복잡할 필요가 없다. 오히려 짧고 일정해야 한다. 중요한 것은 나중에 다시 봤을 때 비교할 수 있어야 한다는 점이다.

최소한 다음 정도는 남겨 두는 것이 좋다.

• 작업 이름: 무엇을 하려던 작업이었는가

• 입력 조건: 어떤 자료와 지시를 넣었는가

• 실패 결과: 무엇이 기대와 달랐는가

• 영향도: 단순 불편인지, 치명적 오류인지

• 추정 원인: 왜 그런 일이 생겼다고 보는가

• 임시 해결책: 그 자리에서 어떻게 수습했는가

• 영구 개선안: 다음부터 무엇을 바꿔야 하는가

핵심은 "결과가 나빴다"에서 멈추지 않는 것이다. 실패는 반드시 조건과 연결되어야 한다. 그래야 나중에 비슷한 실패를 묶을 수 있다.

예를 들어 이런 식이다.

작업: 긴 회의 녹취 요약
입력 조건: 2시간 분량 녹취, 요약 요청만 있음
실패 결과: 실행 항목은 잘 뽑았지만 반대 의견과 미결 사항을 누락함
영향도: 중간. 후속 회의 준비에 혼선 발생
추정 원인: 결정과 논의 중인 항목을 구분하는 지시가 없음
임시 해결책: "결정/미정/쟁점" 세 구획으로 다시 요약 요청
영구 개선안: 회의록 템플릿에 필수 섹션 추가, 검수 체크리스트에 미결 항목 포함

이렇게 남기면, 나중에 회의록 작업 전반을 개선할 수 있다.

실패를 모을 때는 개별 사건보다 패턴이 중요하다

실패 기록이 몇 건 쌓이면, 그때부터는 사건 하나하나보다 반복되는 패턴을 보는 눈이 중요해진다. 시스템 개선은 패턴을 찾아낼 때 시작된다.

실전에서 자주 보이는 실패 패턴은 대체로 몇 갈래로 묶인다.

• 목표가 모호해서 엉뚱한 방향으로 잘 가는 경우

• 입력 자료가 부족하거나 너무 많아서 핵심을 놓치는 경우

• 출력 형식이 없어 결과가 들쭉날쭉한 경우

• 평가 기준이 없어 통과와 실패를 구분하지 못하는 경우

• 사람 검토 지점이 없어 작은 오류가 그대로 배포되는 경우

• 작업은 맞지만 모델 선택이 맞지 않는 경우

• 한 번의 대화에 너무 많은 단계를 우겨 넣은 경우

이 분류의 좋은 점은 "AI가 이상했다"를 "어느 층에서 문제가 났는가"로 바꿔 준다는 데 있다. 문제의 층이 보이면 고칠 곳도 보인다.

실패를 분류하는 네 개의 층

실패를 다루기 쉬운 방식으로 정리하면 네 개의 층으로 나눌 수 있다.

1. 지시의 실패

목표가 अस्पष्ट하거나 제약이 약해서 생기는 문제다. 예를 들어 "좋게 정리해 줘" 같은 말은 사람끼리는 그럭저럭 통하지만 AI에게는 너무 넓다. 결과가 흔들리는 이유가 여기에 있을 수 있다.

이 층의 개선은 비교적 단순하다. 목표를 더 구체화하고, 입력의 범위를 지정하고, 출력 형식을 고정하고, 평가 기준을 붙이면 된다.

2. 컨텍스트의 실패

필요한 정보가 없거나, 반대로 너무 많아서 중요한 것이 묻히는 경우다. 자주 생기지만 의외로 잘 못 잡아낸다. 사람은 머릿속 배경지식으로 빈칸을 메우지만 AI는 그렇지 못하다.

이 층의 개선은 자료를 더 넣는 것이 아니라, 더 잘 정리해 넣는 것이다. 핵심 정보, 배경 정보, 참고 자료를 구분하고 우선순위를 주어야 한다.

3. 워크플로의 실패

한 번에 끝내려는 설계 때문에 생기는 문제다. 조사, 비교, 초안, 검토, 수정이 필요한 작업을 단일 프롬프트로 해결하려 하면 품질이 불안정해진다.

이 층의 개선은 작업을 단계로 나누는 것이다. 탐색 단계와 결정 단계를 분리하고, 중간 점검을 넣고, 사람이 승인해야 다음 단계로 넘어가게 만들면 실패율이 줄어든다.

4. 운영의 실패

출력은 괜찮아 보여도 실제 사용 과정에서 사고가 나는 경우다. 로그가 남지 않거나, 실패 사례가 공유되지 않거나, 누가 언제 검토하는지 정해져 있지 않으면 같은 문제가 반복된다.

이 층의 개선은 도구보다 운영 규칙이 중요하다. 실패 기록 방식, 검토 책임, 재현 절차, 배포 전 체크 같은 운영 장치가 필요하다.

실패 로그는 감상이 아니라 재현 가능한 정보여야 한다

좋은 실패 로그에는 공통점이 있다. 다시 실행해 볼 수 있다는 점이다. "이상하게 별로였다"는 기록은 읽고 나면 남는 것이 없다. 반면 "어떤 입력에서 어떤 결과가 나왔고, 무엇이 문제였는가"가 남아 있으면 재현도 가능하고 수정 효과도 확인할 수 있다.

그래서 실패 기록에는 가능하면 다음 요소가 포함되어야 한다.

• 원본 입력 또는 입력의 요약

• 사용한 프롬프트나 지시 구조

• 실제 출력의 문제 부분

• 기대 출력의 기준

• 재현 조건과 빈도

여기서 중요한 것은 완벽한 기록이 아니라 비교 가능한 기록이다. 조금 부족하더라도 형식이 일정하면 훨씬 쓸모가 커진다.

실패 사례를 쌓을수록 체크리스트가 좋아진다

앞 장에서 체크리스트의 중요성을 다뤘다면, 이번 장에서는 그 체크리스트가 어디서 오는지 연결해 볼 수 있다. 좋은 체크리스트는 머리에서 뚝 떨어지지 않는다. 대부분 실패 사례의 응축본이다.

예를 들어 이런 실패가 반복되었다고 해보자. 보고서 요약에서 숫자를 바꾸거나, 날짜를 잘못 읽거나, 근거 없는 확신 표현을 넣는 문제가 자주 나온다. 그러면 검수 체크리스트에 자연스럽게 이런 항목이 추가된다.

• 숫자와 날짜가 원문과 일치하는가

• 추정과 사실이 구분되어 있는가

• 근거 없는 단정 표현이 들어가 있지 않은가

• 누락되면 안 되는 핵심 항목이 빠지지 않았는가

이 순간 실패는 단순한 실수가 아니라 검사 장치의 재료가 된다. 그리고 체크리스트가 좋아질수록 사람의 검토 품질도 일정해진다.

실패는 템플릿과 규칙으로 굳혀야 한다

실패를 발견했는데 다음 작업에서 또 같은 방식으로 시작한다면, 사실상 아무것도 고친 것이 아니다. 실패 사례는 반드시 템플릿, 기본 프롬프트, 운영 규칙, 평가 항목 가운데 하나로 굳혀야 한다.

예를 들어 회의록 작업에서 액션 아이템 누락이 잦았다면, 그다음부터는 기본 출력 형식 자체를 바꿔야 한다. "요약해 줘"가 아니라 "핵심 논점, 결정 사항, 미결 사항, 담당자, 기한"이 기본 구조가 되어야 한다.

코드 작업에서 테스트 누락이 반복되었다면, 기본 규칙을 "코드 제안 후 테스트 전략 제시"로 바꿔야 한다. 리서치 작업에서 출처 품질 문제가 반복되었다면, 출처 요건을 미리 명시해야 한다.

즉 실패는 기억 속 반성이 아니라 작업의 기본값을 바꾸는 재료가 되어야 한다.

우선순위는 빈도와 비용으로 정한다

실패 사례를 모으다 보면 곧 목록이 길어진다. 이때 모든 문제를 다 고치려 하면 오히려 시스템이 무거워진다. 그래서 우선순위가 필요하다.

보통은 두 가지를 보면 된다. 얼마나 자주 일어나는가, 그리고 일어났을 때 얼마나 비싼가다.

자주 일어나지만 피해가 작은 실패가 있다. 예를 들어 문체가 일정하지 않은 문제다. 반대로 자주는 아니지만 한번 터지면 큰 사고가 나는 실패가 있다. 예를 들어 계약서 요약에서 예외 조항을 누락하는 문제다. 둘 다 중요하지만 대응 방식은 다르다.

실무에서는 다음처럼 정리하면 판단이 쉬워진다.

이 표를 머릿속에 두면, 실패를 볼 때 감정이 아니라 운영 관점으로 판단할 수 있다.

원인 분석은 사람 탓이나 모델 탓으로 끝내지 말 것

실패가 생기면 가장 쉬운 결론은 둘 중 하나다. "사용자가 못 썼다" 혹은 "모델이 별로다." 물론 정말 그럴 때도 있다. 하지만 그렇게 끝내면 개선은 멈춘다.

원인 분석에서는 더 세분화된 질문이 필요하다.

• 이 실패는 특정 입력 길이에서만 나타나는가

• 특정 작업 유형에서만 심해지는가

• 출력 형식을 고정하면 줄어드는가

• 중간 검토를 넣으면 막을 수 있는가

• 더 나은 모델이 필요한 문제인가, 아니면 설계의 문제인가

• 사람 검토가 너무 늦게 들어오는 것은 아닌가

좋은 원인 분석은 दोष를 정하는 과정이 아니라 통제 가능한 변수를 찾는 과정이다. 그래야 수정이 가능하다.

실패에서 개선안으로 넘어가는 다섯 가지 질문

실패를 기록한 다음에는 반드시 "그래서 뭘 바꿀 것인가"로 넘어가야 한다. 그때 도움이 되는 질문이 있다.

첫째, 이 실패는 지시를 바꾸면 줄어드는가?
둘째, 컨텍스트를 정리하면 해결되는가?
셋째, 작업 단계를 나누면 예방되는가?
넷째, 평가와 검수 지점을 추가하면 막을 수 있는가?
다섯째, 아예 다른 모델이나 도구가 더 적합한가?

이 다섯 질문은 매우 실용적이다. 실패를 추상적인 불만에서 구체적인 개선안으로 옮겨 준다.

실패 사례를 팀 자산으로 바꾸는 법

개인이 혼자 AI를 쓰는 경우에도 실패 기록은 중요하지만, 팀에서 일할 때는 가치가 훨씬 커진다. 한 사람이 겪은 실패를 다른 사람이 다시 겪지 않게 만들 수 있기 때문이다.

이를 위해서는 실패 사례가 개인 메모장에만 갇히지 않아야 한다. 팀 차원의 공통 저장소가 필요하다. 형식은 거창할 필요가 없다. 문서 하나여도 좋고, 표 하나여도 좋다. 중요한 것은 모두가 같은 방식으로 보고, 같은 방식으로 추가하고, 같은 방식으로 고친다는 점이다.

팀에서 특히 유용한 방식은 실패 사례를 다음 세 가지 산출물로 연결하는 것이다.

• 공통 프롬프트 템플릿 개선

• 공통 체크리스트 업데이트

• 작업별 운영 규칙 정리

이렇게 해 두면 팀 전체의 평균 실력이 올라간다. 잘하는 한 사람이 버티는 구조가 아니라, 시스템이 사람을 도와주는 구조가 된다.

작은 실패를 무시하면 큰 실패의 예고를 놓친다

많은 조직이 큰 사고가 나야 움직인다. 하지만 AI 시스템에서는 작은 실패가 큰 실패의 전조인 경우가 많다. 사소한 누락, 애매한 문장, 들쭉날쭉한 형식은 그냥 귀찮은 문제가 아니다. 평가 기준이 약하고 운영 장치가 약하다는 신호일 수 있다.

예를 들어 초반에는 문체만 조금 흔들리던 시스템이, 나중에는 요약 기준 자체가 흔들릴 수 있다. 처음에는 링크 제목을 하나 빼먹던 리서치 봇이, 나중에는 핵심 출처의 맥락을 잘못 전달할 수 있다. 작은 실패를 꾸준히 기록하는 습관은 이런 악화를 초기에 잡아낸다.

그러니 실패 로그를 쓰는 일은 사후 처리만이 아니다. 예방 정비에 가깝다.

실패를 자산으로 만드는 개선 루프

실전에서는 다음 순서로 움직이면 좋다.

• 실패를 수집한다

• 재현 가능한 형태로 기록한다

• 비슷한 유형끼리 묶는다

• 빈도와 위험도로 우선순위를 정한다

• 프롬프트, 컨텍스트, 워크플로, 운영 규칙 중 어디를 바꿀지 결정한다

• 수정 후 같은 사례로 다시 테스트한다

• 통과한 개선은 템플릿과 체크리스트에 반영한다

이 흐름이 자리 잡으면, AI 활용 수준이 눈에 띄게 달라진다. 예전에는 문제가 생길 때마다 놀라고 급히 봉합했다면, 이제는 "이건 어떤 유형의 실패인가?"부터 묻게 된다. 바로 그 순간부터 사용자는 단순한 소비자가 아니라 시스템 운영자가 된다.

실전 예시: 요약 봇이 자꾸 중요한 예외를 빼먹는다면

하나의 사례로 전체 과정을 묶어 보자.

법무팀이 계약서 요약 봇을 쓰고 있는데, 일반 조항은 잘 요약하지만 예외 조항이나 단서 문구를 종종 놓친다고 하자. 처음에는 사람 검토로 막았지만, 같은 실수가 여러 번 반복된다.

이 문제를 시스템적으로 다루면 이렇게 간다.

먼저 실패 사례를 모은다. 어떤 계약서에서, 어떤 종류의 예외가, 어떤 방식으로 빠졌는지 기록한다. 다음으로 패턴을 본다. 알고 보니 예외 조항은 대개 문장 후반부의 단서 표현, 단락 사이의 연결 문구, 부정 표현 근처에서 빠진다.

그다음 개선안을 세운다. 출력 형식에 "일반 원칙"과 "예외/단서"를 분리해 넣고, 검수 체크리스트에 "단서 문구 누락 여부"를 추가한다. 필요하다면 먼저 조항을 구조화해서 뽑고, 그다음 요약하게 워크플로를 바꾼다.

마지막으로 이전 실패 사례들로 다시 테스트한다. 정말 예외 조항 누락이 줄었는지 확인한다. 이 검증이 끝나야 비로소 개선이라고 부를 수 있다.

중요한 점은, 처음의 실패 하나가 결국 템플릿 개선, 체크리스트 보강, 워크플로 개편으로 이어졌다는 것이다. 이것이 바로 실패를 자산으로 바꾸는 방식이다.

완벽한 시스템보다 계속 고쳐지는 시스템이 강하다

AI 시스템은 처음부터 완벽할 수 없다. 모델이 바뀌고, 업무가 바뀌고, 입력 데이터가 달라지기 때문이다. 그래서 진짜 강한 시스템은 실패가 없는 시스템이 아니다. 실패를 빨리 발견하고, 같은 실수를 덜 반복하고, 배운 것을 구조에 반영하는 시스템이다.

이 관점을 가지면 실패는 더 이상 창피한 것이 아니다. 오히려 시스템이 성숙해지는 재료가 된다. 오늘의 실패가 내일의 규칙이 되고, 다음 주의 체크리스트가 되고, 다음 달의 자동화 품질을 올린다.

문제 하나를 고치고 끝내는 사람은 늘 같은 자리에서 비슷한 문제와 싸운다. 반대로 실패를 모아 패턴화하고 시스템을 고치는 사람은 매번 조금씩 앞으로 간다. AI를 오래, 잘, 믿을 수 있게 쓰는 사람은 바로 후자다.

이번 장의 핵심

실패 사례는 불편했던 기억이 아니라 시스템 개선의 원재료다. 개별 실패를 그때그때 봉합하는 데서 멈추지 말고, 기록하고, 분류하고, 우선순위를 정하고, 템플릿과 체크리스트와 워크플로에 반영해야 한다. 그렇게 할 때 실패는 비용이 아니라 자산이 된다.

다음 장에서는 이렇게 쌓아 온 개선 습관을 바탕으로, 일상과 실무에서 믿고 사용할 수 있는 AI 활용 습관이 무엇인지 이어서 살펴보자.