AI가 자기 잘못을 정확히 설명해도, 작업은 따로 복구해야 했다

5월, AI와 과제 아카이브를 정리하던 중이었습니다. 문제를 재구성한 설명과 작업 결과물은 남아 있는데, 그 바탕이 된 원본 자료를 모아 두는 폴더가 보이지 않았습니다. 이유를 묻자 AI는 폴더 이름 철자를 고친 일과, 별도 원본이 확인된 과제에만 그 폴더를 만든 기준을 설명했습니다.

설명은 눈앞의 폴더 구조와 잘 맞았습니다. 하지만 작업이 만들어진 순서와는 맞지 않았습니다. 재구성한 결과가 있다면 그것을 만든 입력도 어딘가에 있었을 가능성이 높았습니다. 결과물에서 거꾸로 자료를 찾아보게 하자 한 과제에서 재구성의 바탕으로 볼 수 있는 원본 이미지가 나왔습니다. 전체 과제를 같은 방식으로 다시 보니 세 곳의 분류도 더 고쳐졌습니다.

이 정정 과정을 작업 문서의 원칙으로 남기는 동안 AI는 다시 다른 곳으로 갔습니다. 더 근본적으로 보라고 하자, 현재 과제에서 무엇을 놓쳤는지 보는 대신 출처를 섣불리 확정하면 안 된다는 더 큰 문서화 일반론을 끌어왔습니다. 그 일반론이 어디서 나왔는지 다시 묻고 나서야, AI는 실제 자료보다 자신이 익숙하게 쓰던 문서화 프레임을 너무 강하게 적용했다고 답했습니다.

저는 이 과정에서 AI가 두 번 어긋났다고 느꼈습니다. 처음에 AI는 보이는 폴더를 탐색 범위로 삼고 결과에서 입력을 역추적하지 않았습니다. 그다음에는 더 근본적으로 보라는 요청을, 방금 자신의 탐색과 분류가 결과에 어떻게 개입했는지 보라는 뜻이 아니라 더 추상적인 이론을 말하라는 뜻으로 읽었습니다.

AI는 문제를 설명하고 있었지만, 정작 자신은 문제 밖의 해설자로 남아 있었습니다.

이 사건에서 ai-self-check라는 skill을 만들었습니다. 필요할 때 불러 쓰는 짧은 작업 지침으로, 당시에는 같은 대화 안에서 작업하던 AI가 멈춰 자신의 판단을 다시 보게 하는 내용이었습니다. 그 뒤 여러 번 써 보면서 질문은 “어떻게 멈춰 세울까”에서 다른 곳으로 옮겨 갔습니다.

AI가 오류의 원인을 정확히 설명했을 때, 실제로 무엇이 고쳐졌다고 볼 수 있을까요?

답을 고친 자리보다 답을 만든 자리를 봤다

첫 버전의 self-check는 직전 답변만 반대로 고치는 대신, 그 답을 만든 탐색 범위부터 전제, 사용자 정정에 대한 반응까지를 같은 AI가 다시 보게 했습니다. “AI는 보통 이렇다”는 설명보다 “이번 작업에서 내가 무엇을 했는가”를 먼저 보고, 원인을 말한 뒤에는 원래 해결하려던 작업으로 돌아가게 했습니다.

아카이브 사례에서 바뀌어야 할 것은 원본 자료가 없다에 가까웠던 결론만이 아니었습니다. 결과물이 남아 있는데도 입력을 거슬러 찾지 않은 탐색 종료 조건이 문제였습니다. 그래서 한 과제의 폴더를 더 여는 데서 끝내지 않고, 재구성 결과가 있는 다른 과제까지 같은 방식으로 다시 찾아 분류를 고쳤습니다.

이후 저는 답이 바뀌었다는 말보다 답을 만든 어느 위치가 움직였는지 봤습니다. 지금 정리하면 보던 위치는 다섯입니다.

• 문제 정의 — 무엇을 해결한다고 보는가.
• 전제 — 당연하다고 둔 조건은 무엇인가.
• 입력 범위 — 어디까지 자료를 봤는가.
• 작업 순서 — 무엇을 먼저 하기로 했는가.
• 다음 행동 — 설명 직후 실제로 무엇을 했는가.

고치기 전후 대화를 나란히 놓기만 해도 어느 위치가 움직였는지 볼 수 있었습니다. 아카이브에서는 입력 범위가 한 폴더에서 결과물이 남은 전체 과제로 넓어졌고, 다음 행동도 한 건 수정에서 같은 조건의 재탐색으로 달라졌습니다.

답변의 문장은 대화 한 번으로 쉽게 바뀝니다. 반대 결론을 내놓거나 잘못을 인정하는 것도 어렵지 않습니다. 하지만 그 문장을 만든 위치가 그대로라면 다음 작업은 익숙한 방향으로 돌아갈 수 있습니다.

정확한 언어를 얻고도 구현 수단이 중심으로 돌아왔다

여행 자료를 읽고 근거를 붙여 답하는 제품을 만들던 때였습니다. 첫 기능을 논의하며 제가 확인하고 싶었던 것은 AI가 불완전한 자료에서 무엇을 확정하고 어디서 멈추는지였습니다. AI는 정해진 입력과 고정된 규칙으로 결과를 재현하는 데모를 먼저 제안했습니다. 검증하기 쉽고 민감정보와 환각 위험을 줄이기 쉬운 선택이었습니다.

그러나 그 데모에서는 제품이 실제로 다뤄야 할 불확실성이 바깥으로 밀려나 있었습니다. 어려운 부분은 AI를 쓰지 않고 정답 화면을 만드는 일이 아니었습니다. AI를 쓰면서도 근거가 없으면 답을 확정하지 못하게 하는 일이었습니다.

self-check를 요청하자 AI는 자신에게 불확실성을 통제 가능한 데모로 바꾸려는 충동이 있었다고 짚었습니다. 위험을 줄이기 위한 개발용 기준선과 실제 제품에서 확인해야 할 경로를 혼동했다고도 했습니다.

저는 그 분석을 좋다고 봤습니다. 데모가 왜 자꾸 제품의 중심을 대신하는지 느꼈던 불편에 정확한 언어가 생겼기 때문입니다. AI가 제가 가리킨 어긋남을 알아들었다는 느낌도 있었습니다.

그런데 설명 직후의 제안은 다시 통제 가능한 구현 구조로 길어졌습니다. 어떤 기준선을 두고, 어떤 추출 단계를 거치고, 어떤 상태를 거부할지 정리했습니다. 각각은 쓸 수 있는 구현 수단이었습니다. 문제는 방금 찾은 충동보다 그 수단들이 다시 제안의 중심이 됐다는 점이었습니다. 저는 구현 방식 하나를 빼라는 뜻이 아니라, 불확실성을 다루기보다 제거할 수 있는 문제로 바꾸려는 방향이 핵심이라고 다시 좁혀야 했습니다.

이 장면에서는 진단이 문제 정의를 바꿨습니다. 하지만 작업 순서와 다음 행동은 바꾸지 못했습니다. 여기서 세 가지가 갈라졌습니다.

• 원인을 정확히 말했는가.
• 바로 다음 제안이 달라졌는가.
• 비슷한 상황에서 같은 판단이 덜 돌아왔는가.

좋은 분석을 깎아내릴 필요는 없었습니다. 다만 분석을 잘했다는 이유만으로 작업이 복구됐다고 처리해서도 안 됐습니다.

별도 AI가 문제 정의를 다시 열었다

같은 대화를 이어 온 AI가 자기 판단을 다시 보면, 이미 택한 전제 안에서 더 정교한 해명을 만들 수 있었습니다. 별도 AI가 기존 대화의 해석에서 떨어져 문제 정의부터 다시 본 가장 이른 기록은 6월 중순입니다. 그 전에도 있었는지는 확인하지 못했습니다.

당시 주 작업 AI는 빈 곳이 많은 여행 자료와 뜻이 분명하지 않은 사용자 질문 사이에서 상황을 읽는 일을, 순서대로 처리할 pipeline 단계와 상태 label의 문제로 좁히고 있었습니다. 별도 AI는 질문을 다시 해석하고, 자료의 신뢰도와 부족한 정보를 비교한 뒤, 필요한 검색이나 재질문을 고르는 움직임이 빠졌다고 봤습니다. 같은 답을 다듬는 대신 무엇을 문제로 볼지부터 다시 연 것입니다.

6월의 한 분석 문서에서는 별도 AI가 문제를 더 좁혀 줬습니다. 작업 과정이 산출물에 샌다는 넓은 진단 대신, 문서가 결과와 상관없이 자신의 제작 과정을 본문 안에서 변호하고 있다는 문제였습니다. 그 관점은 좋았지만, 주 작업 AI가 이를 옮긴 설명은 어렵고 지나치게 길다고 다시 고치게 했습니다.

맞는 판정을 옮기며 다른 경로를 지웠다

하지만 다른 위치에서 문제를 봤다고 작업까지 저절로 바뀌지는 않았습니다. 7월, ‘AX 인재전쟁’ 해커톤을 준비하며 어떤 사용자 문제를 더 조사할지 정할 때였습니다. 자료는 넓게 모아 둔 상태였고, 문제 후보를 바로 고르는 대신 조사 순서를 먼저 합의했습니다.

• 출제 기업이 직접 밝힌 자료에 높은 비중을 두고, 회사가 중요하게 보는 방향을 잠정으로 잡는다.
• 그와 별도로, 공개 사용자 자료와 독립 자료에서 지금 남아 있는 사용자 문제와 자료의 빈 곳을 본다.
• 두 결과가 만나는 지점에서 다음 조사 질문을 고른다.

회사 자료의 높은 비중이 나쁜 편향인지 별도 AI에게 물었습니다. 회사의 과제에 답하려면 그 비중은 목적에 맞는다는 답이 돌아왔습니다. 외부 자료의 역할은 회사가 중요하게 보는 방향을 사용자 전체의 문제로 일반화하거나, 이미 해결된 문제를 다시 고르는 일을 막는 데 있었습니다.

문제는 주 작업 AI가 이 답을 적용하면서 생겼습니다. 합의했던 순서가 회사 방향을 먼저 정리하고 그 주변의 마찰만 확인하는 흐름으로 단순해졌고, 나란히 보기로 했던 사용자 문제의 독립 경로가 축소됐습니다. 제가 이전 합의와 더 넓은 대화를 다시 보라고 정정한 뒤, 두 번째 self-check가 이 축소를 찾았습니다. 첫 답의 핵심은 유지한 채, 축소됐던 독립 경로를 다시 열었습니다.

처음
  회사 방향 + 사용자 문제
  → 접점에서 다음 조사 질문

축소
  회사 방향
  → 주변의 미해결 마찰 확인

  사용자 문제
  → 독립 경로를 잃고 위 흐름에 종속

복구
  회사 방향 + 사용자 문제
  → 접점에서 다음 조사 질문

복구할 때 회사 자료의 비중이라는 전제는 그대로 뒀습니다. 대신 회사가 중요하게 보는 방향과 현재 남은 사용자 문제를 서로 다른 근거로 확인하도록 입력을 다시 열었습니다. 조사 순서도 두 결과의 접점에서 다음 질문을 고르는 방식으로 돌아왔습니다.

이 사건을 지나며 각자가 할 일이 분명해졌습니다. 별도 AI는 어디서 어긋났는지 후보를 냅니다. 주 작업 AI는 그 후보를 지금 하던 일에 옮깁니다. 저는 옮겨진 방향을 실제 문제와 대조하며 무엇을 남기고 무엇을 다시 바꿀지 좁힙니다.

첫 답은 복구 뒤에도 남았습니다. 문제가 생긴 곳은 그것을 적용하며 다른 쪽을 지운 주 작업 AI의 다음 움직임이었습니다. 별도 AI의 보고도, 그것을 옮긴 답도, 사용자의 정정도 각각 다음 판단에 쓰이는 재료였습니다.

언제 별도 AI를 부르고, 언제 부르지 않았나

7월의 다른 논의에서는 AI의 일단 전진하는 태도를 고치는 중에 AI가 다시 초안 작성과 실행으로 서둘렀습니다. 저는 작업을 멈추고 먼저 생각과 전후 차이를 보여 달라고 다시 좁혔습니다. 고치려던 움직임이 같은 대화 안에서 곧바로 돌아온 것입니다. 정정이 앞선 이해에 쌓이지 않는 짧은 핑퐁이었습니다.

별도 AI를 둔다고 처음부터 다른 시야가 생기는 것도 아니었습니다. 주 작업 AI가 점검 초점과 관련 원문 범위를 먼저 골라 넘기던 동안, 별도 AI는 이미 구성된 사건을 보고 있었습니다. 그래서 이후에는 정정을 일으킨 발화와 바로 앞 교환처럼 작은 원문에서 시작하고, 더 필요한 범위는 별도 AI가 직접 넓히도록 입력 방식을 바꿨습니다.

언제 부르지 않을지도 작은 장면에서 배웠습니다. 넓은 조사를 마친 뒤 기준을 미리 정하고 조사한 것은 아닌지 확인했을 때, 주 작업 AI는 이를 방향 정정으로 읽고 self-check를 열려 했습니다. 제가 “아냐 그냥 물어본거야”라고 하자 점검을 접고, 문제 선정 기준을 먼저 정한 것이 아니라 조사 방법만 정했다고 평범하게 설명했습니다.

이해를 확인하는 질문에 별도 AI는 필요하지 않았습니다. 첫 오해의 방향이 분명하면 주 작업 AI가 바로 고치면 됐습니다. 고친 뒤에도 같은 문제 정의나 입력 범위, 작업 순서가 돌아오거나 기존 대화에서 떨어져 원인을 볼 필요가 있을 때 다른 시야를 빌렸습니다. 같은 정정 표현이 몇 번 나왔는지보다, 앞선 이해가 실제 다음 답에 남아 있는지를 봤습니다.

이 변화가 별도 AI를 언제나 더 정확하거나 빠르게 만든 것은 아닙니다. 장기 재발이 줄었다고 말할 근거도 없습니다. 제가 바꾼 것은 두 가지였습니다. 기존 해석에서 떨어져 볼 입력을 마련했고, 별도 AI가 필요 없는 질문은 원래 대화로 돌려보냈습니다.

지금 돌아보면, 목적은 원래 작업으로 돌아가는 일이었다

앞의 장면들에서 저는 AI가 만든 진단을 그대로 받거나 전부 버리지 않았습니다. 불확실성을 통제 가능한 데모로 바꾸려 했다는 분석은 좋다고 봤고, 구현 수단이 다시 중심에 놓이자 핵심은 그것이 아니라고 좁혔습니다.

정확한 언어를 얻는 일 자체에도 가치가 있었습니다. 막연했던 불편이 반박하거나 보완할 수 있는 후보가 되면, 저는 어디까지 동의하고 어디서 다시 어긋났는지 말할 수 있었습니다. 여러 번 사용한 뒤 이 글을 쓰는 지금에서야, 제가 self-check를 언제나 완성된 정답을 들고 부른 것은 아니었다는 점도 선명해졌습니다.

이 이해를 5월의 최초 설계 의도로 소급하고 싶지는 않습니다. 처음 이 skill을 만들 때 분명했던 것은 AI가 자신의 탐색과 판단을 오류의 원인 안에 넣고, 메타 설명에서 끝내지 말고 원래 작업으로 돌아가야 한다는 것이었습니다. 사용자의 기준도 대화 중에 선명해질 수 있다는 층위는 AI와 계속 일하면서 뒤늦게 보이기 시작했습니다.

처음 제가 원했던 회복도 잘 정돈된 오류 보고서가 아니었습니다. AI가 대화의 흐름과 질문 상황을 다시 구성하고, 제가 가리킨 문제에 맞는 해결책으로 원래 하던 일을 이어 가는 것이었습니다. 지금의 self-check도 사용자의 어긋남 감각과 AI의 후보를 대조해 무엇을 보고 있었는지 다시 맞추고, 그 이해를 다음 행동으로 옮기는 데 가깝습니다.

그 이해가 이어졌는지는 다음 답에서 봅니다. 먼저 AI의 행동이 달라졌는지 확인합니다.

• 최근 AI 대화 하나를 다시 열어, AI가 “맞다”고 인정하거나 반대 결론을 내놓은 지점과 바로 다음 답을 찾습니다.
• 그 답이 하던 방식 그대로인지 봅니다. 같은 자료만 보는지, 같은 순서로 움직이는지, 전과 같은 종류의 제안을 내놓는지.
• 그대로라면 설명을 더 요구하는 대신 다음 요청 하나를 지정합니다. 앞의 세 장면처럼 닫았던 자료 하나를 다시 열게 하거나, 지워진 비교 하나를 복구하게 하거나, 구현 전에 확인하려던 불확실성을 다시 묻게 합니다.

다음 답이 그대로면 고쳐진 것은 설명뿐입니다. 그 상태로도 작업은 멈추지 않고 그럴듯하게 이어집니다. 그래서 저는 분석이 좋다고 말한 뒤에도 다음 답을 봅니다.

이 확인은 AI만을 향하지 않았습니다. 어긋났다는 감각은 먼저 있었지만, 그것을 설명할 기준은 처음부터 문장으로 있지 않았습니다. AI가 내놓은 진단을 맞다, 아니다로 가르다 보면 제가 보던 기준이 그제야 문장이 되기도 했습니다. 이제는 다음 답을 보면서, 무엇을 함께 보고 있었는지도 다시 맞춥니다.